Synchronization of Local Devices in Point-Of-Sale Environment

This application is a continuation of and claims priority to U.S. patent application Ser. No. 18/959,504, filed Nov. 25, 2024, which is a continuation of and claims priority to U.S. patent application Ser. No. 18/363,616, filed Aug. 1, 2023, and issued as U.S. Pat. No. 12,254,459 on Mar. 18, 2025, which is a continuation of and claims priority to U.S. patent application Ser. No. 17/334,382, filed May 28, 2021, and issued as U.S. Pat. No. 11,769,137 on Sep. 26, 2023, which is a continuation of and claims priority to U.S. patent application Ser. No. 14/858,974, filed Sep. 18, 2015, and issued as U.S. Pat. No. 11,023,878 on Jun. 1, 2021, which claims the benefit of U.S. Provisional Patent Application No. 62/171,713, filed Jun. 5, 2015, the entire contents of which are incorporated herein by reference.

Solutions exist to provide individuals with the ability to transfer money between one another electronically through, e.g., Automated Clearing House transfers, wire transfers, etc. Such solutions have also been implemented between a merchant and a user to enable payment transactions. However, creating accounts with one or more financial institutions and sharing such sensitive account information to enable money transfers may be both time-consuming and risky.

Embodiments of apparatuses, methods, and systems for transmitting payment proxy information are described herein. Traditionally, a customer provides a payment card, such as a credit card in a merchant associated card reader connected with a point-of-sale (POS) terminal, to process a transaction involving a product or service. In some cases, the customer or a sender requests for the financial account information of the merchant or recipient to furnish his or her account with funds and complete the transaction. In such exemplary scenarios, the merchant or a representative of the merchant has to be present in order to either furnish the financial account information or accept payments through the POS system. However, the merchant may not be comfortable divulging personal account information to every customer or sender. Additionally, the merchant may not find it economically or geographically feasible to establish a POS infrastructure at all locations, particularly at locations or businesses that are sparsely populated, pop-up or seasonal.

To this end, embodiments of the present subject matter provide apparatuses, methods and systems for transmitting payment proxy, which is indicative of the financial or bank account of the merchant/recipient. Using the payment proxy of the recipient, the customer or sender processes a transaction for a product or service via web-application, messaging application, a forum message, a social networking website or application, a third-party application, or a webpage with customized uniform resource locator (URL).

In some embodiments, a device, such as a payment object reader (e.g., a card reader configured to accept payments through a credit or debit card), payment beacon or a payment object reader configured as a payment beacon, operating on wired or wireless technologies, e.g., Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, Radio Frequency Identification (RFID), Near-Frequency Communication (NFC), etc., may persistently or on activation of the payment object reader, e.g., in response to a visual, audio or tactile input, send or receive payment related information like the payment proxy of the merchant. The payment proxy can have syntax of a monetary currency indicator preceding an alphanumeric character. A customer device, such as a mobile phone or a tablet, obtains the payment proxy via a Bluetooth receiver component, installed within the customer device. On receiving the payment proxy, the customer may access a portal (such as a web application, an application stored on the device, a forum, a website, etc.) and specify, with or without an explicit command, an intention to transfer a predefined amount to the customer, which can then be packaged as a payment request and sent to a payment processing system. The payment processing system receives the request through the portal. In one implementation, the payment processing system can optionally parse the payment proxy and apply a syntax matching algorithm to match the received payment proxy with registered entries in its database. The payment processing system can then communicate with a financial institution (e.g., an issuer or an acquirer) to determine details of the financial account associated with the payment proxy and process the transaction on receiving confirmation from the financial institution. In some embodiments, a merchant server can maintain a database including the information of financial accounts.

In some embodiments, the payment beacon is not in the same vicinity as the customer device. In such cases, a device in proximity to the customer device can serve as an intermediate device to store and carry the payment information to the beacon in proximity to the payment beacon, which then transfers the information to the payment beacon on behalf of the customer device.

Even though the description hereinafter is in terms of a customer and a merchant interacting for a product or service, the description can be extended to any two parties interacting in a financial transaction.

Embodiments of the methods and systems described can be installed in the context of a multi-functional point-of-sale system or as a beacon of data without a payment receiving means. In either of the scenarios, the customer may obtain payment related information related to the merchant prior to or during the time of transactions, making the entire transaction experience seamless and convenient, particularly at places where a merchant or a traditional point-of-sale system may be difficult to install. The embodiments described herein can be configured to operate in both real-time and offline modes and for direct and remote transactions. Furthermore, such embodiments are configured to operate on a variety of mobile devices, web applications, mobile applications, POS topologies, payment cards, computer networks, and environments.

Certain embodiments may be configured for use in standalone devices (e.g., PDAs, smartphones, laptops, PCs and/or the like). Other embodiments may be adapted for use in a first device (e.g., mobile phone, and/or the like), which may be connected to a second device (e.g., tablet computer and/or the like) via any type of connection (e.g., Bluetooth, USB, Wi-Fi, serial, parallel, RF, infrared, optical and/or the like) to exchange various types of data (e.g., raw signals, processed data, recorded data/signals and/or the like). In such embodiments, all or part of the data processing may happen on the first device, in other embodiments all or part of the data processing may happen on the second device. In some embodiments there maybe more than two devices connected and performing different functions and the connection between devices and processing may happen in stages at different times on different devices. Certain embodiments may be configured to work with various types of processors (e.g., ARM, Raspberry Pi and/or the like).

While aspects of the described subject matter can be implemented in any number of different systems, circuitries, environments, and/or configurations, the embodiments are described in the context of the following exemplary system(s) and configuration(s). The descriptions and details of well-known components are omitted for simplicity of the description. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the present subject matter. Furthermore, all examples recited herein are intended to be for illustrative purposes only to aid the reader in understanding the principles of the present subject matter and the concepts contributed by the inventor(s) to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the present subject matter, as well as specific examples thereof, are intended to encompass equivalents thereof.

It should also be appreciated by those skilled in the art that any block diagrams, steps, or sub-processes herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown. The order in which the methods are described are not intended to be construed as a limitation, and any number of the described method blocks can be deleted, moved, added, subdivided, combined, and/or modified in any order to implement the methods, or an alternative combination or sub-combinations. Also, while steps, sub-processes or blocks are at times shown as being performed in series, some steps, sub-processes or blocks can instead be performed in parallel, or can be performed at different times as will be recognized by a person of ordinary skill in the art. Further any specific numbers noted herein are only examples; alternative implementations can employ differing values or ranges. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof.

The following description provides specific details for a thorough understanding and enabling description of these embodiments. One skilled in the relevant art will understand, however, that the embodiments discussed herein may be practiced without many of these details. Likewise, one skilled in the relevant art will also understand that the embodiments can include many other features not described in detail herein. Additionally, some well-known structures or functions may not be shown or described in detail below, so as to avoid unnecessarily obscuring the relevant description. Some of the recurring terms are now defined.

The terms “connected” or “coupled” and related terms used throughout the description are used in an operational sense and are not necessarily limited to a direct physical connection or coupling. Thus, for example, two devices may be coupled directly, or via one or more intermediary media or devices. As another example, devices may be coupled in such a way that information can be passed there-between, while not sharing any physical connection with one another. Based on the disclosure provided herein, one of ordinary skill in the art will appreciate a variety of ways in which connection or coupling exists in accordance with the aforementioned definition.

The phrases “in some embodiments,” “according to some embodiments,” “in the embodiments shown,” “in other embodiments,” and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one implementation of the disclosed technology, and may be included in more than one implementation. In addition, such phrases do not necessarily refer to the same embodiments or different embodiments.

The term “communication network” may be any type of network known in the art, such as a local area network or a wide area network, such as the Internet, and may include a wireless network, such as a cellular network, a cloud network, a local wireless network, such as Wi-Fi and/or close-range wireless communications, such as Bluetooth and Bluetooth low energy, near field communications (NFC), a wired network, or any other such network, or any combination thereof. Accordingly, the network may include both wired and/or wireless communication technologies, including Bluetooth, Bluetooth low energy, Wi-Fi and cellular communication technologies like worldwide interoperability for microwave access (Wi-MAX), 3G, 4G, CDMA, digital subscriber line (DSL), etc., cloud computing technologies, as well as wired or fiber optic technologies. Additionally or alternatively, the communication network may be a mesh network. For example, in a wireless local area network (WLAN), network devices may be configured to receive and forward communications, which are ultimately destined for a different device. These types of networks are generically referred to as “mesh” networks, where network nodes may form a “mesh” of paths for which communications may travel to reach their destination. A mesh network is a network that employs one of two connection arrangements, full mesh topology or partial mesh topology. In the full mesh topology, each node is connected directly to each of the others. In the partial mesh topology, nodes are connected to only some, not all, of the other nodes. In connection with wireless networks, the term “mesh” is often used as a synonym for “ad hoc” or “mobile” network. As used herein, a wireless mesh network assumes a network that handles many-to-many connections and is capable of dynamically updating and optimizing these connections. The dynamic management of complex routing information, which likely includes information about external networks (e.g. the Internet and gateways to it), is considered in dynamic mesh protocols.

Wireless networks may use beacon transmissions to advertise the network's existence, as well as provide information about the network and capabilities associated with the network. Different kinds of beaconing mechanisms may be used, for example, one for infrastructure mode networks (also called basic service set (BSS) networks) and one for ad-hoc mode networks (also called independent basic service set (IBSS) networks). In infrastructure networks, access points (APs) are the entities responsible for generating beacons whereas in ad hoc networks, all network nodes (including user stations) participate in the generation of beacons. The ad hoc network beacons (referred to as IBSS beacons) are used to advertise the network (which consists of all the nodes) as a whole while the infrastructure network beacons (referred to as BSS beacons) are generated by an AP and meant to advertise the existence of only that individual AP. Components used for such communications can depend at least in part upon the type of network, the environment selected, or both. Protocols for communicating over such networks are well known and are not discussed herein in detail.

Additionally, as used herein, the term “payment card,” “payment object,” or “payment instrument” refers to a payment mechanism that includes a debit card, a credit card, a prepaid gift card, or the like, a smartcard that has an embedded integrated circuit chip (e.g., Europay-MasterCard-Visa (EMV) card), a proxy card, or any card that functions as a combination of any of these mechanisms. The term “proxy object” as used herein refers to a card that may or may not bear a card number/account number that appears to be that of a real credit or debit card account (i.e., it is in the correct format), but where that card/account number is actually only a proxy for the customer's real card/account number. Another type of payment object is a biometrically identifiable instrument, which may be initialized using a person's finger (e.g., for fingerprint recognition), face, iris or retina, heartbeat, etc. Alternatively, the payment object can be a software instrument or virtual instrument, such as a virtual wallet configured to initiate contactless payment transactions, e.g., a key fob, a mobile device having an RFID tag, etc. Other examples of payment object may also include a prepaid card, a gift card, a rewards card, a loyalty points card, a frequent flyer miles card, checks, cash, or in general, any kind of financial instrument that holds financial value or provides a promise to pay at a later time. Thus, a payment object transaction (also referred to as payment card transaction) may be any be a transaction where a merchant or a user swipes the user's credit card through a payment object reader in exchange for a product or service offered by the merchant.

The term “swipe” here refers to any manner of triggering a payment object reader to read data from a payment object, such as by dipping into, tapping, hovering, bringing in close contact or passing the payment object into or through a payment object reader.

The term “beacons” refer to devices that use direct radio signal communication to directly communicate information wirelessly to other devices using mid-range to short-range radio signal protocols. In other words, the wireless beacons can directly communicate using radio signals without interaction with any intermediary devices between the communicating devices. Furthermore, a device can communicate information using radio signals, e.g. a user identifier, to another device without the devices engaging in a pairing process that requires user input and without requiring explicit user authorization to communicate with another device. The direct radio signal communication functionality can be performed by any appropriate computing device, e.g. wristwatch, a mobile phone, a portable music player, a tablet computer, a laptop computer, a personal digital assistant, a smartphone, a keychain beacon, or another handheld or wearable mobile device to name a few examples. The radio signals emitted by the devices for such wireless communication can be part of any appropriate standard for mid-range to short-range radio communications having an operable range of at least 1 meter and up to about 50 meters, e.g., Bluetooth, Bluetooth 4.0, and BLE. Other techniques, such as geo-fencing or sensors using global positioning system (GPS), may also be used for location determination. The radio signals described in this specification can be any appropriate type of signal, e.g., a broadcast or advertiser signal that indicates presence of the device to nearby devices, or a connection signal that transmits data to a connected nearby device, to name a few examples. In this specification, a device can be said to be “nearby,” “neighboring” or “proximate” if the device is within the operable range for performing direct radio signal communication with another user device. The neighboring or intermediate device, in some cases, is structurally and operationally similar to the payment beacon device or the customer device. For example, the neighboring device is configured to store and transmit a payment proxy of its own to devices requesting such information.

The term “logging in” or “checking in” may thus refer to the customer's action through a user application to indicate availability to conduct a payment transaction or to communication by the customer device of such an indication to the beacon or to the POS terminal, as the context requires. In essence, checking in constitutes a consent by the user to conduct a card-less transaction with the merchant. This consent differs from actual authorization of the transaction, which the customer would provide, e.g., verbally, upon learning the amount of the transaction.

The term “cause” and variations thereof, as used throughout this description, refers to either direct causation or indirect causation. For example, a computer system can “cause” an action by sending a message to a second computer system that commands, requests or prompts the second computer system to perform the action. Any number of intermediary devices may examine and/or relay the message during this process. In this regard, a device can “cause” an action even though it may not be known to the device whether the action will ultimately be executed or completed.

The term “component,” “component” or “engine” refers broadly to general or specific-purpose hardware, software, or firmware (or any combination thereof) components. Components and engines are typically functional components that can generate useful data or other output using specified input(s). A component or engine may or may not be self-contained. Depending upon implementation-specific or other considerations, the components or engines may be centralized or functionally distributed. An application program (also called an “application”) may include one or more components and/or engines, or a component and/or engine can include one or more application programs.

Furthermore, for the purposes of interpreting this specification, the use of “or” herein means “and/or” unless stated otherwise. The use of “a” or “an” herein means “one or more” unless stated otherwise. The use of “comprise,” “comprises,” “comprising,” “include,” “includes,” and “including” are interchangeable and not intended to be limiting. Also, unless otherwise stated, the use of the terms such as “first,” “second,” “third,” “upper,” “lower,” and the like do not denote any spatial, sequential, or hierarchical order or importance, but are used to distinguish one element from another. It is to be appreciated that the use of the terms “and/or” and “at least one of”, for example, in the cases of “A and/or B” and “at least one of A and B”, is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of both options (A and B). As a further example, in the cases of “A, B, and/or C” and “at least one of A, B, and C”, such phrasing is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of the third listed option (C) only, or the selection of the first and the second listed options (A and B) only, or the selection of the first and third listed options (A and C) only, or the selection of the second and third listed options (B and C) only, or the selection of all three options (A and B and C). This may be extended, as readily apparent by one of ordinary skill in this and related arts, for as many items listed.

While certain devices, e.g., the payment object readers and POS terminals, are shown as including distinct components, this is merely for case of illustration and not intended as limiting. In various implementations, the payment object readers and POS terminals may be identical, similar or distinct. Moreover, the components shown and described for the payment object readers and POS terminals may be implemented as more components or as fewer components and functions described for the components may be redistributed depending on the details of the implementation. Additionally, in some implementation, there may be several, hundreds, thousands, hundreds of thousands, or more, of the payment object readers and the POS terminals. Further, in some implementations, configuration, structure, and operational characteristics of the payment object readers and/or POS terminals may vary from device to device. In general, payment object readers and the POS terminals can each be any appropriate device operable to send and receive data, requests, messages, electronic messages, text messages, alerts, notifications, pop-up messages, push notifications, or other types of information over the one or more networks or directly to each other.

The cash tagging or beacon payment technology introduced here can be embodied as special-purpose hardware (e.g., circuitry), as programmable circuitry appropriately programmed with software and/or firmware, or as a combination of special-purpose and programmable circuitry. Hence, embodiments may include a machine-readable medium having stored thereon instructions that may be used to cause one or more processors to perform the methods, variations of the methods, and other operations described here. The machine-readable medium may include, but is not limited to, floppy diskettes, optical discs, compact disc read-only memories (CD-ROMs), magneto-optical discs, read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), application-specific integrated circuits (ASICs), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions. Various embodiments will now be described in further detail with the help of one or more figures.

1 FIG. 100 100 100 100 100 Turning now to the Figures,is a block diagram illustrating embodiments of a payment processing system (PPS) controllerconfigured to allow processing of payment transactions between entities, such as a merchant and a customer, or a sender and recipient of funds. In one embodiment, the PPS controllermay serve to aggregate, process, store, search, serve, identify, instruct, generate, match, and/or facilitate interactions with a computer through various technologies, and/or other related data. The PPS controllermay be used to collect data for later retrieval, analysis, and manipulation, which may be facilitated through an internal or external database. For example, the PPS controlleron receiving payment related information may complete the transaction, generate receipt as proof of the transaction, update inventory of the product after the transaction, and obtain data related to the customer involved in the transaction, such as transaction history, location data, and the like. The PPS controllercan be a customer device (for example, a mobile phone of a customer), a merchant device (for example, a point-of-sale terminal for processing payment transactions), and a payment beacon to send and receive static or dynamic information, for example, the payment proxy, transaction summary or receipt, either perpetually or on activation. The devices may have fewer or more components than defined here as will be clear by context.

102 102 102 104 104 100 105 UsersA, who may be customers, merchants, consumers, senders or recipients of funds, buyers, sellers, and/or other entities or systems, may engage information technology systems (e.g., computers, mobile devices, laptops, servers) to facilitate processing of information, such as transactional, financial, and so on. It should be noted that the term “server” as used throughout this application refers generally to a computer, other device, program, or combination thereof that processes and responds to the requests of remote users across a communications network. Servers serve their information to requesting “clients”B connected to the usersA. The term “client” or “customer device” as used herein refers generally to a computer, program, other device, user and/or combination thereof that is capable of processing and making requests and obtaining and processing any responses from servers across a communications network. Networksfacilitate the transfer of information from source points to destinations. The users (e.g., merchants) may directly interact with the PPS controller, e.g., via the user inputs devices.

100 106 108 102 106 106 100 100 102 110 106 110 104 106 100 106 100 102 106 100 106 100 106 100 In one implementation, the PPS controllercan be configured to receive a payment card or payment card information to process payment card transactions (i.e., those involving reading of a payment card physically provided by the customer at the merchant's location), as well as card-not-present (CNP) transactions (i.e., those where the instrument is not physically presented at the time that the payment is effected, e.g., through payment proxy), either through a card readeror by providing a graphical user interfaceto accept financial account information of the userA initiating the payment. A payment card transaction may be any transaction where a merchant or a customer uses a payment card to purchase a product or service offered by the merchant, for example, by swiping a user's credit card through a card readeror by providing the information through voice, text, or other wired or wireless data communication techniques. The term “swipe” here refers to any manner of triggering a card readerto read data from a payment card, such as by passing a card into or through a magnetic stripe card reader, optical scanner, smartcard (card with an embedded IC chip) reader (e.g., an EMV-compliant card reader or NFC enabled reader), radio frequency identification (RFID) reader, or the like. Such card readers may either be integrated within the PPS controller(as shown) or connected externally with the PPS controllerand/or client(s)B as peripheral devices. If the card readeris connected externally, the peripheral devicesmay be connected via wired or wireless communication networkand interact to each other through customized interfaces. In one implementation, the card readercan be connected to an audio plug of the PPS controller. If the card readeris integrated within the PPS controller, the one or more interfaces and components can be configured to accept payment data through various communication protocols. Accordingly, hardware implementation may include creation of slots, magnetic tracks, and rails with one or more sensors to facilitate a userA, e.g., a merchant, to detect and accept a payment card. In one implementation, the payment card and the peripheral devicesmay support the same technology for short-range (typically less than 100 meters) and/or low power wireless communication protocols and technologies, such as Bluetooth Low Energy (BLE), standard Bluetooth, WiFi, Near Field Communication (NFC) or Radio-Frequency Identification (RFID). According to the communication protocol preferred or implemented, the PPS controllermay require additional steps to configure the card readerto operate and work alongside the PPS controller. For example, a pairing component (described later) may be used to connect, synchronize, and pair the card readerand the PPS controllerto facilitate exchange of data obtained off the payment card.

The term “payment card’ or ‘payment object’ refers to a payment mechanism that includes a conventional debit card, a conventional credit card, a prepaid gift card, or the like, a smartcard that has an embedded integrated circuit chip (e.g., Europay-MasterCard-visa (EMV) card), a proxy card, or any card that functions as a combination of any of these mechanisms. The term “proxy card” as used herein refers to a card that may or may not have a card number/account number that appears to be that of a real credit or debit card account (i.e., it is in the correct format), but where that card/account number is actually only a proxy for the customer's real card/account number. The card/account number generally adheres to a naming standard set by the financial institution associated with or issuing the payment card. Other examples of payment card may also include a prepaid card, a gift card, a rewards card, a loyalty points card, a frequent flyer miles card, a check, cash, or any other kind of payment instrument that holds financial value or provides a promise to pay at a later time.

The payment card used in the example above is one type of a financial instrument. Other types of financial instruments, other than the payment card, can be used to initiate the transfer of funds. Another example of a financial instrument is a biometrically identifiable instrument, such as a person's finger (e.g., for fingerprint recognition), face, iris or retina, heartbeat, etc. Alternatively, a financial instrument can be a software instrument or virtual instrument, such as a virtual wallet, optionally embedded in a hardware device to enable contact or contactless payments.

100 112 114 112 116 118 120 118 118 110 102 104 112 In one implementation, the PPS controllermay be based on computer systems that may comprise, but are not limited to, PPS unitsand memory. Furthermore, PPS units can comprise hardware and/or software components, referred to as PPS units, which may comprise a central processing unit (“CPU(s)” and/or “processor(s) and/or microprocessor(s)” (these terms are used interchangeably))and an interface bus, which may be interconnected and/or communicating through a system buson one or more motherboard(s) having conductive and/or otherwise communicative pathways through which instructions (e.g., binary encoded signals) may travel to enable communications, operations, storage, etc. The interface busmay also include other interfaces or adapters specific to network, storage, peripherals, and input-output interface(s), through which data may pass into and out of a computer and which allow users to access and operate various system components. The interface busmay be connected to external units, such as peripheral devicesor client(s)B via communication network. Each of the PPS componentsis now described in detail.

116 The CPUmay incorporate various specialized processing units, such as, but not limited to: integrated system (bus) controllers, memory management control units, floating point units, and even specialized processing sub-units like graphics processing units, digital signal processing units, and/or the like. In various embodiments, the processor core may be a low-power/ultra-low power/low-cost microcontroller; examples include an Intel Processor like Intel Atom, Apple A4, Nvidia Tegra 2, Marvell Armada, Qualcomm Snapdragon, Samsung Hummingbird and Exynos, Texas Instruments OMAP and MSP microcontroller, ARM Holdings processor like the Cortex-A,-M-R, Series, or ARM series and/or the like processor(s). Should processing requirements dictate a greater amount speed and/or capacity, distributed processors (e.g., Distributed PPS), mainframe, multi-core, parallel, and/or super-computer architectures may similarly be employed. Alternatively, should deployment requirements dictate greater portability, smaller Personal Digital Assistants (PDAs) may be employed.

100 100 Depending on the particular implementation, features of the PPS controllermay be achieved by implementing a microcontroller, such as Freescale's Kinetis K21D; and/or the like. Also, to implement certain features of the PPS controller, some feature implementations may rely on embedded components, such as: Application-Specific Integrated Circuit (“ASIC”), Digital Signal Processing (“DSP”), Field Programmable Gate Array (“FPGA”), and/or the like embedded technology. Depending on the particular implementation, the embedded components may include software solutions, hardware solutions, and/or some combination of both hardware/software solutions.

118 122 124 126 128 118 Interface bus(ses)may accept, connect, and/or communicate to a number of interface adapters, although not necessarily in the form of adapter cards, such as but not limited to: input-output interfaces (I/O), storage interfaces, network interfaces, and/or the like. Optionally, cryptographic processor interfacesmay be connected to the interface bus.

124 130 130 Storage interfacesmay accept, communicate, and/or connect to a number of storage devices such as, but not limited to: storage devices, removable disc devices, and/or the like. Storage interfacesmay employ connection protocols such as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet Interface) ((Ultra) (Serial) ATA (PI)), (Enhanced) Integrated Drive Electronics ((E) IDE), fiber channel, Small Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like.

122 105 110 131 3 1 100 100 Input-Output interfaces (I/O)may accept, communicate, and/or connect to user input devices, peripheral devices, such as externally connected card readers, cryptographic processor devices, and/or the like. I/O may employ connection protocols such as, but not limited to: audio: analog, digital, monaural, RCA, stereo, and/or the like; data: Apple Desktop Bus (ADB), IEEE 1394a-b, serial, universal serial bus (USB); USB 2.0; USB.; USB Type C; Ethernet; infrared; joystick; keyboard; midi; optical; PC AT; PS/2; parallel; radio; video interface: Apple Desktop Connector (ADC), BNC, coaxial, component, composite, digital, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video, VGA, and/or the like; wireless transceivers: 802.11a/b/g/n/x; Bluetooth; cellular (e.g., code division multiple access (CDMA), high speed packet access (HSPA (+)), high-speed downlink packet access (HSDPA), global system for mobile communications (GSM), long term evolution (LTE), WiMax, Li-Fi etc.); and/or the like. In various embodiments, an audio or video display with a touch screen and driver may be included, the touch screen being based upon a variety of later-developed or current touch screen technology including resistive displays, capacitive displays, optical sensor displays, electromagnetic resonance, or the like. Additionally, touch screen display may include single touch or multiple-touch sensing capability. Any display technology may be used for the output display, such as a Liquid Crystal Display (LCD) or solid state device such as light-emitting diode (LED) or organic light-emitting diode (OLED), Plasma display, trans-reflective (Pixel Qi) display, electronic ink display (e.g. electrophoretic, electrowetting, interferometric modulating). In various embodiments, the resolution of such displays and the resolution of such touch sensors may be set based upon engineering or non-engineering factors (e.g. sales, marketing). In some embodiments, speakers and LED indicators can be used to present audio and visual identifiers of transaction and device status. In addition, buttons may be configured to power PPS controlleron or off, operate the controller or reset the controller.

100 In some embodiments of the PPS controller, image capture device may be included, which may further include a sensor, driver, lens and the like. The sensor may be based upon any later-developed or convention sensor technology, such as CMOS, CCD, or the like. Image recognition components may be provided to process the image data. For example, such components can support functionalities including, but not limited to, barcode detection, facial recognition, camera parameter control, etc.

126 126 104 104 100 102 102 126 100 Network interface(s)may be regarded as a specialized form of an input-output interface. One or more network interfacesmay be used to engage with various communications network types. For example, multiple network interfaces may be employed to allow for the communication over broadcast, multicast, and/or unicast networks. Through a communications network, the PPS controlleris accessible through remote clientsB (e.g., computers with web browsers) by usersA. Network interfacesmay employ connection protocols such as, but not limited to: direct connect, Ethernet (thick, thin, twisted pair 10/100/1000 Base T, and/or the like), Token Ring, wireless connection such as IEEE 802.11a-x, and/or the like. Should processing requirements dictate a greater amount speed and/or capacity, distributed network controllers (e.g., Distributed PPS), architectures may similarly be employed to pool, load balance, and/or otherwise increase the communicative bandwidth required by the PPS controller.

126 126 126 100 In some implementations, the network interfacesmay be communicatively coupled to hardware components, which facilitate detection of payment cards. For example, the network interfacesmay couple to a payment card slot or rail designed to accept payment cards through swipe or insertion or any other action. In another example, the network interfacesmay couple to one or more sensors included to detect presence of payment card or a tap of the payment card onto a surface of the PPS controller.

126 100 102 In various embodiments, the network interfacemay also support wireless data transfers between the PPS controllerand external sources, such as clientsB and cameras, or the like. Wireless protocols may include Wi-Fi (e.g. IEEE 802.11a/b/g/n, WiMax), Bluetooth or Bluetooth low energy (BLE); infrared, and the like, through BLE interface, WiFi interface, QR interface, NFC interface, EMV interface, cellular technology interface, and other interface(s), described subsequently.

132 132 132 132 According to one implementation, BLE interface (“BLE”)is configured to work on Bluetooth® or BLER protocol to facilitate communication with a BLE transceiver installed on other devices. In one implementation, BLE is intended for low-power and low-latency applications for wireless devices within a short range, such as up to about 50 meters. BLE interfacemay be used in applications requiring intermittent communications, smaller amounts of data transfer and bandwidths, and/or low duty cycles. BLE interfacecan be configured to use only a fraction of the power as compared to other interfaces. In many cases, BLE interfacemay be able to operate more than a year on the power source without charging.

132 106 102 102 100 100 106 102 132 100 132 BLE interfaceis capable of being paired with a peripheral device, such as card reader, a payment card, or a clientB associated with a userA, thus allowing the PPS controllerto (a) serve as a “beacon” and broadcast data and/or (b) become a relay point between the controllerand payment card, card readeror a clientB serving as a point of sale terminal for a merchant. The BLE interfaceallows the controllerwith BLE interfacecan be placed at merchant locations, museums, ski resorts, state parks, entertainment venues, parking garages, etc.

132 132 102 4 6 FIGS.- As defined herein, a beacon is a short range communication device having a known or fixed location that provides a signal that can be detected by mobile devices within proximity of the beacon. For example, BLE interfacecan transmit a radio frequency (RF) signal that includes its position coordinates (e.g., latitude, longitude), which can be detected by a mobile device. Alternatively, BLE interfacecan transmit other data, such as payment proxy related to the financial account information of the userB (explained with reference to).

100 100 102 102 100 PPS controlleras BLE beacon allows for constant, scheduled or random scanning of other Bluetooth peripherals and devices. In one implementation, a component, such as BLE interface component, within the PPS controllerand/or the clientB can be set to run in the background under a BLE protocol, persistently, intermittently or on activation monitoring for a significant change in location and/or presence of an appropriate BLE peripheral or beacon at a merchant or vendor location. BLE beacon also allows for persistent or intermittent transmission of data. For example, BLE beacon may persistently transmit or receive information related to payment proxy associated with the clientB or PPS controller.

102 100 100 100 106 124 132 100 When the owner or user of the clientB or payment card enters a store having PPS controlleras a point of sale terminal, he or she would get in the BLE network radius of the PPS controller. PPS controllerthen serves as a bidirectional conduit for the card readerto communicate with the CPUcollecting or handling the credit card transaction. Along with receiving transaction data or any other data by the BLE interface, the PPS controllermay also encrypt, decrypt, or store the data for future processing. It does these actions in addition to running the payment application itself, which may display items for sale, up-sell based on purchases, allow confirmation of purchases, application of coupons, the ability to provide feedback, etc.

100 102 132 100 110 In one implementation, the PPS controlleror the clientB may be connected to a BLE peripheral device having BLE interfacefunctionalities. In some implementations, the payment card may include a chip supporting BLE functionalities. A control logic unit (not shown) may also be included to bridge BLE interface either to ISO 7816 contact interface or ISO 14443 contactless interface to provide for autonomous bi-directional data transfer between paired devices. In one implementation, the controlleris capable of communicating using Bluetooth, and is thus able to pair with a peripheral deviceto obtain payment object information from a phone that at least has Bluetooth capabilities. In one implementation, a plurality of BLE peripheral devices may be connected via the BLE protocol, or other communication network, to form a mesh network. Such a mesh network may allow for transfer of data between the peripheral devices, even those that are more than the distance prescribed by the BLE protocol.

100 100 Similar to BLE beacons, data can be exchanged using other kind of RF beacons, infrared beacons, cellular communications (CDMA, GSM, LTE, etc.), beacons, pattern generation beacons, such as barcodes, Quick Response (QR) codes, or a radio frequency identifier (RFID) tag. QR code or NFC may have short range but high accuracy; WiFi or Bluetooth may have mid-range and medium accuracy; and cellular may have long-range but low accuracy. In some embodiments, the controllercan receive and permanently store payment information so that the controlleracts as a payment object that does not require a payment card or other payment object to be present.

134 134 106 116 145 116 172 145 116 145 145 116 145 110 100 145 145 145 116 145 145 In one example, an NFC interface(“NFC”) can allow for close range communication using standards such as ISO 18092, ISO 21481, TransferJet® protocol and in compliance with FIME certifications. Close range communication with the NFC interface may take place via magnetic field induction, allowing an NFC interface chipto communicate with other NFC devices or to retrieve information from tags having RFID circuitry via the NFC interface. In instances where it is desired to read an NFC enabled payment object, or an NFC enabled payment object is determined to be in proximity to the card reader, the CPUmay be configured to drive antennavia a driving circuit (not shown) to induce a magnetic field capable of being modulated by the NFC enabled payment object. From here, the modulated magnetic field signal may be converted into a digital signal that CPUcan interpret via the NFC component. On the other hand, when it is desired to transmit data via antenna, CPUmay be configured to disable the driving circuit and transmit data using the NFC protocol by instructing a NFC modulator (not shown) to modulate the magnetic field to which antennais operatively coupled. In some embodiments, there can be a switch within the NFC modulator to turn on or off the load applied to the antenna. The switch can be under the control of the CPU. In some embodiments the antennacan drift from a desired frequency (become detuned). This can be the result of a metal object being in the proximity of deviceor controller. The monitor circuit (not shown) can monitor the frequency of the antenna, and determine when the frequency of the antennahas drifted away from the desired frequency. When the it is determined that the NFC antennais out of tune, NFC antenna monitor circuit can work in concert with the CPUto vary one or parameters such as capacitance, voltage, or impendence of the antennato tune the NFC antenna.

136 100 1 2 3 116 136 116 114 100 218 126 In another example, an EMV interface(“EMV”) can allow the PPS controllerto accept Chip and PIN cards follow technical standards more formally known as EMV, after Europay, MasterCard and Visa (EMV). In one implementation, the EMV interface complies with EMV's Level, Leveland Levelcertifications. In some instances, CPUreceives payment data read by the EMV interfacevia the card contacts (not shown), or alternatively from a magnetic stripe reader reading payment data from a magnetic stripe card. The payment data received at the CPUis stored, either temporarily or permanently, in memoryof the controller. The payment data stored in memory can then be transmitted via the NFC antenna. The network interfacesmay work in conjunction with components explained later.

100 102 102 102 102 In other implementations, a plurality of beacon technologies may be used based on specific accuracy or power requirements. Such technologies may be combined based on weight or some other relationship. In yet another implementation, selections may be made based on user preference or availability of the beacon technology at that time. For example, the PPS controllermay be configured to provide and detect a plurality of beacons. For example, if a camera is on, a QR code on the clientB display may be read, for example to pair two payment devices. If only cellular is on, a modem may detect a femtocell may be nearby. The clientB, such as a merchant's register or point of sale terminal, may combine data from the multiple beacons and use such data for analysis of transactions over a course of time. For example, the customer deviceB may be configured to use Wi-Fi RSSI/RTT and BT RSSI/RTT measurements from a first beacon, QR code value from a second beacon, and WiFi RSSI and cellular measurements from a third beacon for accurately identifying and establishing secured connections with the customer deviceB.

100 The beacons can be dynamic with data and other beacon parameters changing as per environment or the type of device pairing with the PPS controller; in other implementations, the beacons can be static and displayed using LED displays, electronic displays, or the like, described with reference to I/O interface.

100 102 105 102 102 110 131 104 In one embodiment, the PPS controllermay also be connected to and/or communicate with entities such as, but not limited to: one or more users, for example usersA, associated with user input devices; one or more usersA through their respective customer devicesB; peripheral devices; an internal or external cryptographic processor device; and/or a communications network.

104 104 104 108 108 The networkcan include any combination of local area and/or wide area networks, using both wired and wireless communication systems. In some embodiments, the networkuses standard communications technologies and/or protocols. Thus, the networkcan include links using technologies such as Ethernet, 802.11, a Wi-Fi, a Bluetooth network; and/or the like worldwide interoperability for microwave access (WiMAX), 3G, 4G, CDMA, digital subscriber line (DSL), etc. Similarly, the networking protocols used on the networkmay include multiprotocol label switching (MPLS), transmission control protocol/Internet protocol (TCP/IP), hypertext transport protocol (HTTP), and/or file transfer protocol (FTP). Data exchanged over the networkcan be represented using technologies and/or formats including hypertext markup language (HTML) or extensible markup language (XML). In addition, all or some links can be encrypted using conventional encryption technologies such as secure sockets layer (SSL), transport layer security (TLS), and Internet Protocol security (IPsec). Additionally, the communication network may be a mesh network. For example, in a wireless local area network (WLAN), network devices may be configured to receive and forward communications which are ultimately destined for a different device. These types of networks are generically referred to as “mesh” networks, where network nodes may form a “mesh” of paths for which communications may travel to reach their destination. Wireless networks may use beacon transmissions to advertise the network's existence, as well as provide information about the network and capabilities associated with the network. Different kinds of beaconing mechanisms may be used, for example, one for infrastructure mode networks (also called basic service set (BSS) networks) and one for ad-hoc mode networks (also called independent basic service set (IBSS) networks). In infrastructure networks, access points (APs) are the entities responsible for generating beacons whereas in ad hoc networks, all network nodes (including user stations) participate in the generation of beacons. The ad hoc network beacons (referred to as IBSS beacons) are used to advertise the network (which consists of all the nodes) as a whole while the infrastructure network beacons (referred to as BSS beacons) are generated by an AP and meant to advertise the existence of only that individual AP.

138 138 120 100 Clockmay have a crystal oscillator that generates a base signal through the PPS controller's circuit pathways. The clockmay be coupled to the system busand various clock multipliers that increase or decrease the base operating frequency for other components interconnected in the PPS controller.

112 140 140 140 100 140 104 140 122 140 140 140 The PPS unitsmay also include a power source. The power sourcemay be of any form capable of powering small electronic circuit board devices such as the following power cells or batteries: alkaline, lithium hydride, lithium ion, lithium polymer, nickel cadmium, solar cells, and/or the like. Other types of AC or DC power sources may be used as well. The power sourceis connected to at least one of the interconnected subsequent components of the PPS controllerthereby providing an electric current to all subsequent components. In one example, the power sourceis connected to the system bus. In an alternative embodiment, an outside power sourceis provided through a connection across the I/Ointerface. For example, a USB connection can carry both data and power across the connection and is therefore a suitable source of power. To this end, coupled to power sourcemay be a USB micro interface (not shown) configured to receive a USB micro jack, although other types of connectors are anticipated. In certain embodiments, connection of a jack to USB micro interface can activate a switch within power sourceto override power supplied by the battery. This allows for battery power to be conserved for situations where external power cannot be provided. Furthermore, power sourcemay also include a battery charger to allow the battery to be charged when external power is supplied via USB micro interface.

140 100 140 116 100 100 100 In one implementation, the power sourcemay include a selector (not shown) to selectively power one or more units within the PPS controller. For example, the power sourcemay power the BLE network interface and BLE component and power the CPUonly on receiving a wake up signal, using an activation signal, triggered by a tactile, visual, or audio input. To this end, the PPS controllermay include wake-up electronics (not shown) configured to wake-up the PPS controllerfrom a low-power state to an active state in response to detection of a payment object. In some embodiments, wake-up electronics can also power down PPS controllerto a low-power state after a predetermined amount of time or after completion of a communication.

142 144 120 110 122 144 145 100 146 A cryptographic processorand/or transceivers (e.g., ICs)may be connected to the system bus. In another embodiment, the cryptographic processor and/or transceivers may be connected as either internal and/or external peripheral devicesvia the I/O interface bus. To this end, the transceiversmay be connected to antenna(s), thereby enabling wireless transmission and reception of various communication and/or sensor protocols. For example the antenna(s) may connect to a transceiver chip or a wireless microcontroller targeting Bluetooth applications, e.g., providing 802.11n, Bluetooth 4.2, Bluetooth 2.1+EDR, FM, GSM/EDGE/GPRS/2G/3G/HSDPA/HSUPA/LTE (4G) communications, global positioning system (GPS) thereby allowing PPS controllerto determine its location, for example. A separate GPS unit(also referred to as the location component) may be used to determine the location of a merchant or customer performing a payment transaction using a payment card. The GPS unit may work on any of the protocols mentioned above. The location information may be used to advertise location specific information to the user.

Furthermore, the communicative instructions may be stored and/or transmitted in batches (e.g., batches of instructions) as programs and/or data components to facilitate desired operations.

110 122 118 110 100 110 131 Peripheral devicesmay be connected and/or communicate to I/O interfaceand/or other facilities of the like such as network interfaces, storage interfaces, directly to the interface bus, system bus, the CPU, and/or the like. Peripheral devicesmay be external, internal and/or part of the PPS controller. Peripheral devicesmay include: antenna, audio devices (e.g., line-in, line-out, microphone input, speakers, etc.), cameras (e.g., still, video, webcam, etc.), dongles (e.g., for ensuring secure transactions with a digital signature, and/or the like), external processors (for added capabilities; e.g., crypto devices), force-feedback devices (e.g., vibrating motors), network interfaces, printers, scanners, storage devices, transceivers (e.g., cellular, GPS, etc.), video devices (e.g., goggles, monitors, etc.), video sources, visors, and/or the like.

106 100 A card reader, similar to card reader, may be connected to the PPS controlleras a peripheral device. The card reader may comprise user interfaces, such as, for example, a PC/SC EMV L1/L2/NFC certified Smart Card Reader, a keypad for PIN entry, such as key keypad, a display, such as the illustrated LCD display, etc., and electrical interfaces, an interface for back-up battery power, an interface for a display, a power interface, LED lights for indicating status of a transaction, a buzzer, etc. The card reader may be, for example, PCI v3 compliant and configured to facilitate the acceptance of credit/debit card payments.

110 100 146 100 Peripheral devicesmay also include sensors, devices, and subsystems can be coupled to network interface to facilitate multiple functionalities. For example, motion sensor, magnetic, light sensor, and proximity sensor can be coupled to network interface to facilitate orientation, detection, lighting, and proximity functions of the PPS controller, by analyzing any input, such as audio, visual, tactile, mechanical, electrical, magnetic, hydraulic, electromagnetic input, and the like. Location processor (e.g., GPS receiver similar to GPS) can be connected to the network interface to provide geo-positioning. Motion sensor can include one or more accelerometers configured to determine change of speed and direction of movement of the PPS controller. Magnetic sensors may detect presence or absence of a payment card and differentiate a payment card from other cards.

110 Peripheral devicesmay also include a camera subsystem and an optical sensor, e.g., a charged coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) optical sensor, can be utilized to facilitate camera functions, such as recording photographs and video clips.

110 Peripheral devicesmay also include an audio subsystem can be coupled to a speaker and a microphone to facilitate voice-enabled functions, such as voice recognition, voice replication, digital recording, and telephony functions. Audio subsystem can be configured to receive voice commands from the user.

110 Peripheral devicesmay also include an I/O subsystem that can include touch surface controller and/or other input controller(s). Touch surface controller can be coupled to a touch surface or pad. Touch surface and touch surface controller can, for example, detect contact and movement or break thereof using any of a plurality of touch sensitivity technologies, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with touch surface. Touch surface can include, for example, a touch screen.

Other input controller(s) can be coupled to other input/control devices, such as one or more buttons, rocker switches, thumb-wheel, infrared port, USB port, and/or a pointer device such as a stylus. The one or more buttons (not shown) can include an up/down button for volume control of speaker and/or microphone.

100 100 In one implementation, a pressing of the button for a first duration may disengage a lock of the touch surface; and a pressing of the button for a second duration that is longer than the first duration may turn power to PPS controlleron or off. The user may be able to customize a functionality of one or more of the buttons. The touch surface can, for example, also be used to implement virtual or soft buttons and/or a keyboard. The touch surface may also activate the PPS controller to actively relay information. At all other times, the PPS controllermay be dormant to conserve power.

105 110 User input devicesoften are a type of peripheral device(see below) and may include: card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, microphones, mouse (mice), remote controls, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors (e.g., accelerometers, ambient light, GPS, gyroscopes, proximity, etc.), styluses, and/or the like. The card readers, as mentioned before, may be configured to read a variety of payment cards. Such card readers may either be dongle like or puck style.

116 118 131 100 Cryptographic units such as, but not limited to, microcontrollers, processors, interfaces, and/or devicesmay be attached, and/or communicate with the PPS controller. Cryptographic units support the authentication of communications from interacting agents, as well as allowing for anonymous transactions. Cryptographic units may also be configured as part of the CPU.

105 110 100 100 It should be noted that although user input devicesand peripheral devicesmay be employed, the PPS controllermay be embodied as an embedded, dedicated, and/or monitor-less (i.e., headless) device(s), wherein access would be provided over a network interface connection. Additionally, part or all peripheral devices may be integrated within the PPS controller.

114 148 100 150 152 154 156 130 Memorymay further include, but is not limited to, one or more componentsthat include programs that supplement applications or functions performed by the PPS controller, database, operating system, random access memory (RAM), read only memory (ROM), and storage device, etc., into which data may be saved that serves, amongst other things, as repository for storing data pertinent to functioning of the components.

100 114 156 154 130 The PPS controllermay employ various forms of memory, such as ROM, RAM, and a storage device. Storage devices may include a drum; a (fixed and/or removable) magnetic disk drive; a magneto-optical drive; an optical drive (i.e., Blueray, CD ROM/RAM/Recordable (R)/ReWritable (RW), DVD R/RW, HD DVD R/RW etc.); an array of devices (e.g., Redundant Array of Independent Disks (RAID)); solid state memory devices (USB memory, solid state drives (SSD), etc.); other processor-readable storage mediums; and/or other devices of the like.

114 152 158 108 160 150 162 164 148 118 The memorymay contain a collection of program and/or database components and/or data such as, but not limited to: operating system component(s)(operating system); information server component(s)(information server); user interface component(s)(user interface); Web browser component(s)(Web browser); database(s); cryptographic server component(s)(cryptographic server); the pairing component(s); and/or the like (i.e., collectively a component collection). These PPS componentsmay be stored and accessed from the storage devices and/or from storage devices accessible through an interface bus.

152 100 The operating system componentis an executable program component facilitating the operation of the PPS controller. The operating system can facilitate access of I/O, network interfaces, peripheral devices, storage devices, and/or the like. In various embodiments, any number of current or future operating systems may be supported such as: any highly fault tolerant, scalable, portable, ROM-able, real-time, deterministic, multitasking and secure kernels systems, e.g., μC/OS-III, μC/OS-III, Apple Macintosh OS X (Server); Unix and Unix-like system distributions; Linux distributions; limited and/or less secure operating systems, e.g., AppleMacintoshOS, Microsoft Windows XP, Windows Server2003, Windows Server 2008, Windows Server2012, Windows Vista®, Windows 7, and Windows 8, Blackberry OS (e.g., Blackberry 10), Firefox OS, Sailfish OS, Tizen, Ubuntu Touch OS, Chrome OS, iPhone OS (e.g. iOS), WindowsMobile (e.g. Windows 10 Mobile), Google Android (e.g. Lollipop 5.1); and/or the like. In various embodiments of the present subject matter, the operating system may be a multi-threaded multi-tasking operating system. Accordingly, inputs and/or outputs from and to a display and inputs/or outputs to physical sensors may be processed in parallel processing threads. In other embodiments, such events or outputs may be processed serially, or the like. Inputs and outputs from other functional blocks may also be processed in parallel or serially, in other embodiments, such as image acquisition device and physical sensors.

152 100 113 100 The operating systemmay provide communications protocols that allow the PPS controllerto communicate with other entities through a communications network. Various communication protocols may be used by the PPS controlleras a subcarrier transport mechanism for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast, and/or the like.

158 The information servermay: support secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols; provide results in the form of Web pages to Web browsers; and allows for the manipulated generation of the Web pages through interaction with other program components.

160 100 100 150 A Web browser componentis a stored program component that is executed by a CPU. The Web browser may be a hypertext viewing application such as Google Chrome or Macintosh Safari. Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and/or other mobile devices. Also, in place of a Web browser and information server, a combined application may be developed to perform similar operations of both. The combined application would similarly affect the obtaining and the provision of information to users, user agents, and/or the like from the PPS enabled nodes. The web browser may be coupled to a web server (not shown). In other implementations, the PPS controllermay host a website (hereinafter, “system website”) that includes one or more graphical user interfaces (GUIs) for organizing and presenting content to users. For example, through the system website, users create account logins to connect to their social identities (e.g., social profiles or social accounts), read content (e.g., messages, comments, posts), create or post content, communicate in real-time with other users (e.g., chat), and/or otherwise engage or interact with other users of the system website (e.g., “friends,” “followers,” “social contacts,” or other types of social network connections). In some embodiments, the user interactions on the system website lead to internal API communication, which involves the PPS controllermonitoring the user interactions for an indication of an intent to transfer money, sending, in response to such indication, requests (e.g., POST or GET requests) to the API of the server(s) to query the database(s), and displaying the data returned by the API of the server(s) as appropriate. The indication of the intent is determined may be based on an identification of a user input, e.g., a string of characters, that has a particular syntax, the syntax being a monetary indicator preceding one or more alphanumeric characters. The user input having the syntax operates as a trigger to send money to a payment proxy represented by the user input.

108 108 The user interfacemay allow for the display, execution, interaction, manipulation, and/or operation of program components and/or system facilities through textual and/or graphical facilities through one or more interaction interface elements, such as check boxes, cursors, menus, scrollers, and windows (collectively and commonly referred to as widgets) to facilitate the access, capabilities, operation, and display of data and computer hardware and operating system resources, and status. Graphical user interfaces (GUIs)may be used to provide a baseline and means of accessing and displaying information graphically to users. The user interface may also be a graphic user interface as provided by, with, and/or atop operating systems and/or operating environments such as already discussed.

162 116 142 128 131 162 128 100 A cryptographic server componentis a stored program component that is executed by a CPU, cryptographic processor, cryptographic processor interface, cryptographic processor device, and/or the like, to enable encryption schemes allowing for the secure transmission of information across a communications network to enable the PPS components to engage in secure transactions. The cryptographic serverfacilitates the secure accessing of resources on the PPS and facilitates the access of secured resources on remote systems; i.e., it may act as a client and/or server of secured resources. Cryptographic processor interfacescan allow for expedition of encryption and/or decryption requests by the cryptographic component. The cryptographic component allows for the encryption and/or decryption of provided data. The cryptographic component allows for both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or decryption. The cryptographic component may employ cryptographic techniques such as, but not limited to: digital certificates (e.g., X.509 authentication framework), digital signatures, dual signatures, enveloping, password access protection, public key management, and/or the like. The cryptographic component will facilitate numerous (encryption and/or decryption) security protocols such as, but not limited to: checksum, Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash operation), passwords, Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like. Employing such encryption security protocols, the PPS controllermay encrypt all incoming and/or outgoing communications.

150 150 The PPS database componentmay be a fault tolerant, relational, scalable, secure database, such as Oracle or Sybase. Alternatively, the PPS databasemay be implemented using various data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory and/or in structured files. In another alternative, an object-oriented database may be used. Also, the database may be implemented as a mix of data structures, objects, and relational structures.

150 150 150 150 102 102 100 150 a f a b c In one embodiment, the databaseincludes several data tables-. A payment proxy tableincludes fields such as, but not limited to: payment proxy, payment proxy financial account, payment proxy last used, payment proxy transaction history, payment proxy contact list, and/or the like. The payment proxy data table may receive, send and/or track incoming and outgoing payment proxies. A location data tableincludes fields such as, but not limited to: location of the PPS controller, location of clientsB, coupons at the location, distance between the clientB and the PPS controller, and/or the like. A transaction data tableincludes fields such as, but not limited to: transaction information, purchases made, purchase history, price of the product, and/or the like.

150 102 150 150 148 d e f A payment data tableincludes fields such as, but not limited to: payment data received from the userA, payment card information, amount charged to the payment card, manner of receiving payment card (swipe, tap, etc.), offline/online mode, etc. A sensor data tableincludes fields such as, but not limited to: payment card detected, payment card received, beacon activated, beacon deactivated, etc. The other data tablestores any other data generated by the PPS component(s). For example, routing tables for communicating in a mesh network.

150 In one embodiment, specific tables may be created when each of the components are executed. Furthermore, the tables may be stored temporarily or permanently in the database.

148 116 148 100 100 The PPS component(s)is a stored program component that is executed by the CPU. In one embodiment, the PPS componentincorporates any and/or all combinations of the aspects of the PPS controllerthat was discussed in the previous figures. As such, the PPS controlleraffects accessing, obtaining and the provision of information, services, transactions, and/or the like across various communications networks.

164 166 168 170 171 172 174 176 164 100 166 100 168 100 170 172 100 171 100 174 100 174 100 176 100 Examples of PPS components include, but are not limited to, pairing component(s), QR code component(s), transaction component(s), BLE interface component(s), EMV interface component, NFC interface component(s), address mapping component(s), and other component(s). The pairing componentmay facilitate pairing the PPS controllerwith one or more software applications and/or external devices, such as customer phones, customer laptops, keyboard, mouse, other point of sale terminals, processing servers, etc. The QR code componentmay allow and enable the PPS controllerto accept QR code as images for pairing hardware and/or software applications, and exchanging data and/or signals. The transaction componentmay allow and enable the PPS controllerto accept transaction data, e.g., from a debit card or credit card, and process or transfer the transaction data to an external server, such as a payment processing system and financial network system, to obtain financial account information of users to fulfill a transaction. The BLE interface component(s)and NFC interface component(s)may allow and enable the PPS controllerto pair hardware and/or software applications, and exchanging data and/or signals via Bluetooth, BLE, and NFC technologies. The EMV interface componentallows and enabled the PPS controllerto accept payments from chip and/or PIN cards. The address mapping component(s)may allow and enable the PPS controllerto map the payment proxies with financial accounts of merchants or customer profiles. The address mapping componentmay also allow the PPS controllerto generate a dynamic payment proxy based on a changing parameter, such as user profile, time of day, location, etc. The other component(s)may enable and allow processing of data/signals required by the PPS controller.

100 The structure and/or operation of any of the PPS controllercomponents may be combined, consolidated, and/or distributed in any number of ways to facilitate development and/or deployment. To this end, one may integrate the components into a common code base or in a facility that can dynamically load the components on demand in an integrated fashion. The components may be consolidated and/or distributed in countless variations through standard data processing and/or development techniques. Multiple instances of any one of the program components may be instantiated on a single node, and/or across numerous nodes to improve performance through load-balancing and/or data-processing techniques. Furthermore, single instances may also be distributed across multiple controllers and/or storage devices; e.g., databases.

If component collection components are discrete, separate, and/or external to one another, then communicating, obtaining, and/or providing data with and/or to other component components may be accomplished through inter-application data processing communication techniques such as, but not limited to: Application Program Interfaces (API) information passage; (distributed) Component Object Model ((D) COM), (Distributed) Object Linking and Embedding ((D) OLE), and/or the like), Common Object Request Broker Architecture (CORBA), SOAP, process pipes, shared files, and/or the like. Messages sent between discrete component components for inter-application communication or within memory spaces of a singular component for intra-application communication may be facilitated through the creation and parsing of a grammar. A grammar may be developed by using development tools such as lex, yacc, XML, and/or the like, which allow for grammar generation and parsing capabilities, which in turn may form the basis of communication messages within and between components. The grammar syntax itself may be presented as structured data that is interpreted and/or otherwise used to generate the parsing mechanism. Also, once the parsing mechanism is generated and/or instantiated, it itself may process and/or parse structured data such as, but not limited to: character (e.g., tab) delineated text, HTML, structured text streams, XML, and/or the like structured data. In another embodiment, inter-application data processing protocols themselves may have integrated and/or readily available parsers (e.g., SOAP, and/or like parsers) that may be employed to parse (e.g., communications) data. Further, the parsing grammar may be used beyond message parsing, but may also be used to parse: databases, data collections, data stores, structured data, and/or the like. Again, the desired configuration will depend upon the context, environment, and requirements of system deployment.

2 FIG.A 1 FIG. 200 202 204 202 204 206 208 206 208 206 202 204 208 204 208 204 208 210 106 212 212 210 is a payment network illustrating movement of data and/or funds between one or more entities, according to an embodiment of the present subject matter. In one implementation, the payment networkmay include: one or more merchants; one or more computing device(s)associated with the merchants(“merchant computing device”); customers(also referred to as “user” or “consumer”); and one or more computing device(s)associated with the customers(“customer computing device”). The customersand merchantsinteract with each other via their respective computing devices to purchase one or more products or services. The merchant computing deviceor customer computing devicecan be, for example, a point-of-sale terminal, a desktop computer, a hand-held device, a network computer, a laptop, tablet or other portable computer, a mobile phone, a landline phone, or any other form of processing device. In one implementation, the devicesandmay be implemented with components and components as described in. As such, the devicesandmay include or be associated with a card reader(integrated card reader or an external card reader, for example similar to card reader), which is configured to receive a payment object, such as payment card, or payment card information to process payment card transactions (i.e., those involving reading of a payment cardphysically provided by the customer at the merchant's location), as well as card-not-present (CNP) transactions (i.e., those where the instrument is not physically presented at the time that the payment is effected). The differentiation between “present” and “not-present” payment cards is that the likelihood of fraud against “not-present” payment card transactions is higher, and accordingly, interchange fee for “not-present” is higher than those levied for “present” payment card transactions. Additionally, the card readercan process both contact and contactless payment transactions. The processing of payment cards physically presented at a merchant's location is discussed first.

204 208 212 204 212 212 A payment card transaction may be any transaction where a merchantor a customeruses a payment cardto purchase a product or service offered by the merchant. The term “payment card’ or “payment object” refers to a payment mechanism that includes a conventional debit card, a conventional credit card, a prepaid gift card, or the like, a smartcard that has an embedded integrate circuit chip (e.g., Europay-MasterCard-visa (EMV) card), a proxy card, or any card that functions as a combination of any of these mechanisms. The term “proxy card” as used herein refers to a card that may or may not bear a card number/account number that appears to be that of a real credit or debit card account (i.e., it is in the correct format), but where that card/account number is actually only a proxy for the customer's real card/account number. Additionally, the payment card used in the example above is a specific type of a financial instrument. Other types of financial instruments, other than the payment card, can be used to initiate the transfer of funds. For example, a payment proxy having a syntax of a monetary indicator followed by alphanumeric data, where the proxy represents the financial account or is registered to the financial account in the payment processing system. Another type of payment object is a biometrically identifiable instrument, which may be initialized using a person's finger (e.g., for fingerprint recognition), face, iris or retina, heartbeat, etc. Alternatively, a financial instrument can be a software instrument or virtual instrument, such as a virtual wallet. Other examples of payment cardmay also include a prepaid card, a gift card, a rewards card, a loyalty points card, a frequent flyer miles card, a check, cash, or any other kind of payment instrument that holds financial value or provides a promise to pay at a later time. Payment cardmay also include an electronic device configured to initiate contactless payment transactions, e.g., a key fob, a mobile device (such as a mobile device having an NFC tag).

212 202 204 In one implementation, the payment cardand/or the devicesandmay support the same technology for short-range (typically less than 100 meters) and/or low power wireless communication, such as Bluetooth Low Energy (BLE), standard Bluetooth, WiFi, Near Field Communication (NFC) or Radio-Frequency Identification (RFID).

202 206 212 210 210 212 212 210 210 202 206 204 214 202 206 216 2 FIG.B To enable a payment card transaction, the merchantor the customerswipes the customer's payment cardthrough a card readerto extract relevant payment transaction data, i.e., information required for processing payment transactions, including, but not limited to, debit account information, credit cardholders name, credit card number, expiration date and card verification value (CVV), digital permanent account number (PAN), etc. The term “swipe” here refers to any manner of triggering a card readerto read data from a payment card, such as by dipping into, tapping, bringing in close contact or passing a cardinto or through a card reader, such as a magnetic stripe card reader, optical scanner, smartcard (card with an embedded IC chip) reader (e.g., an EMV-compliant card reader or NFC enabled reader), radio frequency identification (RFID) reader, Bluetooth-enabled reader, or the like. Even though the description herein relates to a card readerconfigured to accept and read payment cards with financial information stored thereon, it will be understood that financial information may be stored within any other kind of payment device, which can include, for example, a key fob, a mobile device (such as a mobile device having an NFC tag), or a digital wallet. In addition to card swipe, some payment card transactions may require the merchantor the customerto manually enter all or a portion of the payment transaction data, for example a debit card account number. To this end, the computing devices, for example merchant computing device, may include one or more mobile payment applications or application program interfaces (APIs)having a graphical user interface component to allow a merchantor customerto enter payment transaction data. Additionally or alternatively, a separate keypadmay be provided for the user to enter the personal identification number (PIN) associated with the debit card. This is discussed in detail with reference to.

206 204 202 202 In addition to the payment transaction data pertaining to the customer, the merchant computing devicemay also obtain or extract payment transaction data pertaining to the merchantsor the merchant's financial accounts to which the funds have to be transferred; such information may include a merchant identification number, merchant financial account information, identification number associated with the requesting computing device, etc.

202 206 202 Optionally, in one implementation, the payment transaction data (read, entered, and/or received in any other way from the merchantsand/or the customers) may be secured using payment token(s). A payment token replaces the real payment transaction data with static or dynamically changing numbers that map to the real payment transaction data. The payment token may be combined with a dynamic cryptogram that prevents the token from being reused. In another implementation, the payment transaction data may be tokenized such that before dispatching to an external entity the payment transaction data is replaced with a random set of characters structured in a format similar to the original payment transaction data, but having no relationship to the original payment information. Alternatively or additionally, the payment transaction data can be encrypted using Triple Data Encryption Algorithm (commonly known as Triple DES), Advanced Encryption Standard (AES), or other encryption techniques. In one example, payment transaction data corresponding to a transaction may be packaged into a fund transfer request. In another example, the merchantstores and packages a plurality of transactions into a single fund transfer request.

204 202 212 218 220 218 218 220 224 224 220 224 202 202 218 224 226 226 218 226 226 228 228 228 206 228 212 212 220 218 204 208 220 228 226 228 204 The merchant computing devicemay send the fund transfer request having the secured or unsecured payment transaction data (e.g., the cardholders name, credit card number, expiration date and card verification value (CVV)) obtained from the merchantand/or the payment cardto a computer systemof a payment processing service (hereinafter “payment processing system” or “PPS 218”) via a communications network. The payment processing systemcan be a cloud computing environment, a virtualized computing environment, a computer cluster, or any combination thereof. The PPScan analyze the fund transfer request based on a plurality of rules stored in a knowledge databasebefore sending the fund transfer request to a computer systemof the PPS' acquirer or merchant's acquirer (hereinafter “acquirer”). For example, one of the rules in the knowledge basemay be determining whether the request is in a certain format or whether the request when run against a risk machine yields a safe score. In one implementation, the acquireris a bank or financial institution that processes payments (e.g., credit or debit card payments) and may assume risk on behalf of a merchantor a plurality of merchantsaggregated by and represented under PPS. The acquirersends the fund transfer request to the computer systemof a card payment network (e.g., Visa, MasterCard, Discover or American Express) (hereinafter “card payment network”) to determine whether the transaction is authorized or deficient in any other way. In some implementations, PPSmay serve as an acquirer and connect directly with the card payment network. The card payment networkforwards the data to the computer systemof the issuing bank (hereinafter to “issuer”). The issueris a bank or financial institution that offered a financial account (e.g., credit or debit card account) to the customer. The issuermakes a determination as to whether the customer's payment cardis valid and whether the payment cardhas the capacity to absorb the relevant charge associated with the payment transaction. Each of the aforementioned computer systems can include one or more distinct physical computers and/or other processing devices which, in the case of multiple devices, can be connected to each other through one or more wired and/or wireless networks. All of the aforementioned devices are coupled to each other through the communications network, including the Internet, intranet, a cellular network, a local area network, a wide area network, or any other such network, or combination thereof. Protocols and components for communicating over such a network are well known and is not discussed herein. Furthermore, PPS, the merchant computing device, and the customer computing devicecan also communicate over the communications networkusing wired or wireless connections, and combinations thereof. If the payment transaction is approved by the issuerand/or the card payment network, a payment authorization message is communicated from the issuerto the merchant computing devicevia a path opposite of that described above.

218 204 208 218 224 226 228 Responsive to the approval, PPSmay be programmed to collect, collate, and store the payment transaction data. Besides the computing devicesand, PPScan collect the payment transaction data from various other entities, such as the acquirer, the card payment network, and the issuer. Therefore, the payment transaction data can include, e.g., an amount of the payment transaction, the method of payment, an identification of the associated financial account, an identity of the merchant, and item-level information. The item-level information relates to the goods or services involved in the payment transaction. The item-level information can include names, identification numbers, prices, tax, discounts and other price adjustments, and/or descriptions of the goods or services. For example, item-level information of a purchase in a coffeehouse can include information such as tea latte and blueberry muffin (i.e., names), SKU102 and SKU 231 (i.e., stock-keeping unit numbers), $2.99 and $3.49 (i.e., prices).

218 206 218 204 208 214 206 206 Using an interactive payment service, the PPScan display the collated payment transaction data to the customerin a variety of ways. For example, the PPScan generate an interactive digital receipt based on the payment transaction data and send the interactive digital receipt to the computing deviceorin the form of a cell phone message, an electronic mail message, a webpage, a push notification, or a user interface within the mobile payment applicationas proof of purchase for the customer. In one implementation, the customercan interact with the interactive digital receipt for performing various tasks, such as confirming the total amount, adjusting tip amount, entering feedback, applying promotional discount, etc.

206 212 208 204 204 202 212 202 218 202 224 228 226 In an embodiment of a card-not-present transaction, customermay place an online order by transmitting the data of the payment card, such as credit card or payment proxy, from the customer computing deviceto merchant computing devicevia any one of a number of communication media (e.g., phone call, fax, mail, email, web, or in general, any method where the payment card is not physically presented and the customer's identity cannot be verified with the signature on the payment card). In one example, the merchant computing devicecan include, e.g., a web server for receiving the online order information. The computing devicecan then send the payment transaction data to the acquirerassociated with the merchantor the PPSthat aggregates a plurality of merchants. The acquirer, the issuer, and the card payment networkcomplete the transaction in a way similar to the card-present-transaction.

2 FIG.A 2 FIG.B 224 226 228 212 210 204 204 212 218 108 204 In some embodiments, fewer systems than those shown inmay be implemented. For example the acquirer, the card payment network, and the issuer, can be a single entity. Therefore, once the payment cardswipes through a card readerof the merchant computing device, the devicesends the payment transaction data along with the data of the payment cardto the single entity via the PPS. The single entity analyzes the data and authorizes the payment transaction; the authorization is then reported back to the payment processing systemand/or the device. Such an implementation may be based on the type of card payment network, e.g., American Express. In some embodiments, the payment card may be a debit card and the transaction may involve entry of a PIN or a digital PAN.provides an exemplary architecture for such transactions.

2 FIG.B 2 FIG.A 206 202 is a payment network illustrating movement of data and funds between one or more entities, according to another embodiment of the present subject matter. In cases where the payment card is a debit card, the flow described inmay apply, for example when the debit card is implemented like a credit card, i.e., without requiring a PIN-based password to authorize transactions. But in some cases, the payment card transaction may need entry of a PIN number to authorize a request for transfer of funds between a customerand a merchant. Such an environment is now explained with the help of an exemplary scenario.

206 212 202 216 204 204 208 202 202 218 218 228 228 202 218 228 218 204 In the example scenario, the customerswipes the debit cardon a merchant's computing deviceand identifies the transaction as a debit transaction, for example through selection of “debit” on the PIN padof the merchant computing device. Following input of a PIN number associated with the debit card, the payment transaction data obtained during the swipe action along with the PIN is saved. Additionally, the payment transaction data (e.g., the amount of funds to be transferred, recipient account information, etc.) may be entered through an application program interface (API) installed on deviceor. In order to protect the PIN number and the payment transaction data from accidental or malicious disclosure, hardware-based encryption can be applied within the merchant computing devicesthat accept such PIN-based debit cards. The received cardholder's PIN number may be encrypted and securely stored within an Encrypted PIN Block (EPB) along with the payment transaction data. In one example, payment transaction data corresponding to a transaction and encrypted PIN may be packaged into a fund transfer request. In another example, the merchantstores and packages data corresponding to a plurality of transactions into a single fund transfer request or batch. The fund transfer request may be sent to a payment processing system, such as payment processing system, for storage and processing. In one implementation, the payment processing systemmay send the fund transfer request to customer's card issuerfor authorization. The customer's issuermay approve or decline the transaction, and route the response back to the merchantor the PPSthrough the same channel. On receiving a “decline message” from the customer's issuer, the PPSmay generate a message for display on the merchant computing deviceto let the customer know the fund transfer request has been declined.

228 218 228 232 230 202 206 218 202 206 In contrast, on receiving an “authorization-and-capture” message from the issuer, the PPSmay initiate the fund transfer between a customer financial account and the merchant financial account via a for-the-benefit-of (F/B/O) account. The FBO account may be created and managed at the customer's issuer, merchant's issuer, or another financial institution different from the customer's or merchant's issuer using the FBO component. Furthermore, the FBO account may be connected to an entity different from the merchantand the customer, such as the PPS. The initiation of fund transfer between the merchantand the customervia the FBO account may occur as soon as the authorization-and-capture message is received. In another implementation, the initiation of fund transfer may occur irrespective of whether an authorization-and-capture message is received. Further, the customer may schedule fund transfers in batch mode and/or offline mode to enable a plurality of fund transfer requests to get authorized via a single authorization-and-capture message.

234 234 226 232 232 202 204 202 218 230 228 236 218 2 FIG.A In one implementation, the fund transfer is effected through an electronic fund transfer (EFT) network, for example, Accel-Exchange, Shazam, NYCE, PULSE, Star, Interlink, Maestro, etc. In case of a non-PIN based transaction, the EFT networkmay be replaced by a card payment network(as shown in). In one implementation, the funds and the fund transfer request move from the FBO account to a merchant's issuer. Once the deposit reaches the merchant issuer, the merchantmay receive notification of the deposit on the merchant computing device. The merchantmay also be notified in a variety of other ways, e.g., phone call, text message, push notification, pop-up message. Meanwhile, PPSreplenishes the FBO account via FBO componentwith funds sent by customer's issuer. Optionally, in one implementation, a settlement account may be associated with the FBO account that may have predetermined amount of funds stored thereon. The settlement account may be furnished with funds from time to time through a settlement componentto reduce risk associated with customer defaulting on fund transfers made by PPS.

206 200 200 208 204 In some implementations, the transactions may be performed or initiated offline. For example, a customermay perform the transaction without availability of a communications networkto process the charge completely or after one of the parties connects to a communication network. The payment architecture may, thus, allow the user to initiate the charge and obtain the product/service based on past transactions, an enabled offline flag in the user device, etc. The transaction can get completely processed when either the customer deviceor the merchant devicecomes online.

3 FIG. is a block diagram illustrating network-based environment of fund transfer between a sender (e.g., a customer) and a recipient (e.g., a merchant) using exemplary tagging methods and systems described hereinafter, according to an embodiment of the present subject matter. Embodiments are disclosed for facilitating transfer of funds, for example in the form of cash, credits, miles or points, between a sender and a recipient by use of a tagging mechanism (“cash tagging technology”). As used here, the term “tagging” refers to a marking of an alphanumeric character or a string of alphanumeric characters to identify it (i.e., the character or string) for treatment in a specified way. The term “alphanumeric character” refers to a symbol that can be a number (i.e., numeric), a letter (i.e., alphabetic), or a combination thereof.

In one implementation, a set of alphanumeric characters is “tagged” in response to detection of a syntax, for example, a monetary currency indicator prefixing or suffixing the alphanumeric characters. Thus, the monetary currency indicator operates as a tagging mechanism that indicates to a computer system to treat the inputs following the indicator as a request from or intent of the sender to transfer funds, where detection of a syntax (e.g., by parsing), which includes an alphanumeric character tagged by a monetary currency indicator, executes, causes or triggers a transfer of funds. As used here, the term “parsing” refers to a process of analyzing a string of alphanumeric characters and/or symbols, either in a natural language or in a computer language.

In one example, a sender may enter a communication message “I support $redcross with $10” on a messaging platform, a web application, a forum website, or on a landing page, or a web address identified by a uniform resource locator. Communication message can be, for example, forum messages text messages, user-to-user chat messages, or group chat (room) messages that may or may not be in natural language.

The term “messaging application,” as used here, refers to any messaging application that enables communication between users (e.g., sender and recipient of a message) over a wired or wireless communications network. The messaging application can be employed by a service provider that delivers a communication service to users, e.g., chat capability. The messaging application can include, for example, an API, or a text messaging application for communication between phones (e.g., conventional mobile telephones or smartphones), or a cross-platform instant messaging application for smartphones and phones that use the Internet for communication. Within a messaging application context, a user can indicate an intent to transfer money by specifying a payment proxy in a TO field of, e.g., a message, that the user inputs within the messaging application. For example, the user enters into the TO field “$redcross.” In another example, the user enters into the TO field “$aaron.” Once the user enters a payment proxy, or input, into the TO field, the user can enter a message in a body of the message, e.g., “Here is $10,” and send the message. In various embodiments, the message can be a text message, a chat message, an email message, or indeed any other type of message that is capable of being exchanged between computing devices. Although this specification may employ text messages as an example, it is to be understood that the payment proxy technology may employ any of these types of messages.

The term “landing page” or “uniform resource locator (URL)” as used here, refers to a virtual location identified by a personalized location address that is dedicated to collect payments on behalf of a recipient associated with the personalized location address. The personalized location address can include the payment proxy discussed above. In some embodiments, the landing page is identified by a uniform resource locator (URL) that includes a payment proxy, where the URL is accessible through a web browser application installed on a customer device of the sender. For example, the URL is www . . . com/$charityName. In another example, the URL is www . . . com/$alex. In some embodiments, the landing page is identified by a graphical user interface (GUI) of a mobile payment application installed on a customer device of the sender. For example, the GUI of the mobile payment application is dedicated to $charityName, where there can be multiple GUIs each dedicated to a different payment proxy.

The term “forum,” as used here, refers to a media channel (e.g., a social networking website, a microblog, a blog, etc.) that enables user interaction and engagement through comments, posts, and/or messages. The forum can be employed by a service provider to provide various services to users of the forum, e.g., create messages, post comments, interact with one another, etc. Within a forum context, a user can indicate an intent to transfer money by specifying a payment proxy in a message that the user submits, e.g., “posts,” on a particular forum, where that payment proxy carries the syntax of the monetary indicator preceding one or more alphanumeric characters. For example, the user posts a message “I support $funnyguy311 with $10.” The monetary indicator can correspond to various currencies, e.g., dollar ($), euro (€), pound (£), yuan (¥), etc. Although use of the dollar monetary indicator ($) is used herein, it is to be understood that any currency symbol could equally be used.

2 2 FIGS.A andB 304 Briefly described, the cash tagging technology enables a sender, who desires to send funds to a recipient using a communication message, to specify the amount by providing, in the message, a first input having one or more alphanumeric characters and a monetary currency indicator prefixing or suffixing the alphanumeric characters. In some embodiments, the sender includes, in the message to the recipient, a second input that contains an alphabetic character and the monetary currency indicator prefixing that alphabetic character. The second input operates as a payment proxy that identifies the recipient. In one example, the payment proxy can be the monetary indicator preceding multiple alphabetic characters, e.g., $aaron. In another example, the payment proxy can be the monetary indicator preceding multiple alphabetic and numeric characters, e.g., $aaron 123. The payment proxy is indicative of the financial account of the recipient. Once the financial accounts of the sender and recipient are identified, the fund transfer methods described incan be utilized. The payment proxy can be provided or advertised to the senderin a variety of ways, all of which are described in subsequent paragraphs.

300 302 304 306 308 309 310 312 314 302 306 204 208 To implement the cash tagging technology, an exemplary system is described herein. According to one implementation, the environmentincludes a sender devicebelonging to a sender, a recipient devicebelonging to a recipient, a payment beacon, a payment processing system(“PPS 310”), and a financial system, all of which are connected via a communications network. The devicesandmay be similar in construction and operation to devicesand.

310 316 318 310 320 150 310 1 FIG. The PPS, in one implementation, can be one or more server computers or work stationsand an Application Programming Interface API(“API 318”) that are employed by a payment service for facilitating movement or transfer of monetary funds between individual users by use of a tagging mechanism. The PPSmay also be equipped with or coupled to a database(e.g., databasesdiscussed with reference to), which can include one or more hard drives, a centralized or distributed data cluster, a cloud-storage service provider, or other suitable storage systems suitable for storing digital data, the sender or recipient account profiles, payment card information, transaction history, and/or for storing computer program instructions that facilitate the cash tagging technology. In some embodiments, PPScan work in coordination with one or more other server computers (e.g., a web server of an online social networking service, a server of an instant messaging service, or any other server of a communication service) to facilitate the cash tagging technology.

312 312 312 310 310 304 308 The financial systemcan be one or more server computers or work stations that are employed by one or more financial services for processing a request for transfer of monetary funds. The financial systemcan include a card payment network where a sender bank account and a recipient bank account are created. The financial systemcan work in coordination with the PPSto process requests from the PPSto transfer funds between financial accounts of, e.g., the senderand the recipient.

304 306 314 304 304 314 322 324 304 322 324 322 324 304 304 322 304 324 The sender deviceor recipient devicecan be any processing device capable of receiving user input as well as transmitting and/or receiving data via the network. In some embodiments, the sender devicecan be a conventional computer system (e.g., a desktop or a laptop computer) or a mobile device having computer functionality (e.g., a tablet device, a smartphone, or a conventional mobile phone (not shown)). The sender devicecan be configured to communicate via the networkwith the Web serverand/or the application server. In some embodiments, the sender devicecan retrieve or send information to the Web serverand/or the application server, and run one or more applications with customized content retrieved from the Web serveror the application server. For example, the sender devicecan execute a browser application to enable interaction between the sender deviceand the Web server(e.g., to access a social networking website), or can execute a customized client to enable interaction between the sender deviceand the application server(e.g., to access a messaging application).

308 306 308 304 302 306 304 308 308 306 308 309 308 302 309 302 309 309 In one implementation, the recipientcan transmit, “broadcast” or otherwise display, via a recipient device, the payment proxy information “payment proxy” of the recipientor recipient's financial account, which can be seen by the sendervia a sender device. The recipient devicecan display the recipient's payment proxy using, for example, internally located static or dynamic payment beacon, for example, BLE beacon(s), QR code(s), e-Ink electronic paper display, RFID(s), NFC tags, LCD display(s), etc. The sender, who wishes to send money to the recipient, e.g., as support for the recipient, can establish a communication channel or connection (or pair) to the recipient device, and then capture and use the displayed payment proxy to send money. In another implementation, the recipientmay install one or more payment beacon devicesfor transmitting payment related information, such as payment proxy. Thus, instead of pairing to the recipient device, the sender devicecan be paired to the payment beaconclosest to the sender device. The payment beacon devicemay be a low-complexity, low-power device that transmits payment proxies within a certain geographical area. Furthermore, a plurality of payment beacon devicesmay be used to create a mesh network of related beacons and thus, provide a wider area of geographical coverage as compared to a single beacon.

306 309 In one example, the recipient deviceor the payment beacon, as the case may be, transmits payment proxy of the merchant/recipient, in the form, for example “$gymXYZ” around the entrance of a gym. For example, this may be for a day pass at a specific gym.

304 309 306 304 308 308 304 308 308 The sender or a customerreceives the payment proxy being transmitted by a payment beaconor a recipient device, and opens a web-application, messaging application, a forum or a landing page to initiate payment for a product or a service. The exemplary methods and systems detect the sender's intent to send money, e.g., $10, to “$gymXYZ” tagged with monetary indicator “$” and initiate the transfer of money upon identification of a recipient's financial account associated with a payment proxy “$gym XYZ.” In another example, a sender, Alex connected to “$alex” may create a text message “Here's the $10 for the day pass.” through a mobile application and send to a recipient gymXYZ connected to “$gymXYZ.” The sendermay not have any personal relationship with the recipient, and as such, may not know a phone number, an email address, or any other personal contact information of the recipient. However, the sendercan send money to the recipientby specifying, in the message, the payment proxy associated with the recipient.

322 318 318 316 316 318 316 318 316 322 316 322 316 In one implementation, the Web servermonitors user messages on the system website for any particular message that includes a user input having the syntax of the monetary indicator preceding the alphanumeric characters, and forwards a request to the APIthat includes, e.g., the message and an identifier associated with a creator of the message (i.e., the user), for the APIand/or the serverto process the money transfer. In such an example, the serverreceives the message via the APIand can parse the message for a payment proxy (i.e., the user input having the syntax) to identify a recipient associated with the payment proxy. Upon identifying the recipient and an associated recipient financial account, the serverinitiates a money transfer to that recipient. In some embodiments, the API(e.g., instructed by the server) can also send back, in a response to the Web server, appropriate data for display to the user. For example, the data is an HTML string that displays a confirmation message with a link for prompting the user to confirm his/her intent to transfer money to the recipient associated with the payment proxy. In some embodiments, the serversends a confirmation message to user using information included in the request received from the web server, e.g., an identifier associated with the user. For example, the identifier can be an email address of the user, and the server(e.g., via an email server) sends an email message to the user's email address.

322 318 316 320 318 316 In some embodiments, the user interactions on the system website lead to internal API communication, which involves the Web servermonitoring the user interactions for an indication of an intent to transfer money, sending, in response to such indication, requests (e.g., POST or GET requests) to the APIof the server(s)to query the database(s), and displaying the data returned by the APIof the server(s)as appropriate. The indication of the intent is determined based on an identification of a user input, e.g., a string of characters, that has a particular syntax, the syntax being a monetary indicator preceding one or more alphanumeric characters. The user input having the syntax operates as a trigger to send money to a payment proxy represented by the user input.

310 312 310 310 310 To complete payment transactions, the payment processing systemcan communicate with one or more financial networks. In some embodiments, the payment processing systemcan communicate with the computer system of a debit card payment network, e.g., STAR or PULSE. In some embodiments, the payment processing systemcan communicate with the computer system of a credit card payment network, e.g., Visa® or MasterCard®. The computer system of the card payment network can communicate, in turn, with the computer system of a sender card issuer, e.g., a bank, and a computer system of a recipient card issuer, e.g., a same or different bank. The sender card issuer and the recipient card issuer can transfer money, e.g., over a debit payment network, in response to a request to transfer money from the payment processing system.

310 310 310 310 2 2 FIGS.A andB In some embodiments, the payment processing systemcan communicate with a computer system of an Automated Clearing House (ACH) network. The computer system of the ACH network can communicate with a sender bank account and a recipient bank account. The sender bank account and the recipient bank account can transfer money, e.g., using the ACH network, in response to a request to transfer money from the payment processing system. In other embodiments, there can also be computer systems of other entities, e.g. the card acquirer, between the payment processing systemand the card issuers, and between the payment processing systemand the bank accounts. Additional payment flows are described in.

4 FIG.A 1 FIG. 3 FIG. 400 402 402 1 402 2 402 3 404 402 406 402 100 402 309 402 406 408 402 402 406 402 406 404 406 406 404 402 402 408 404 is block diagramA of an exemplary scenario for transmitting payment proxy to neighboring devices, according to an implementation of present subject matter. In an exemplary scenario, a payment object reader(such as-,-, and-) is communicatively coupled to a host device, e.g., through a local area network, e.g., Wi-Fi, Bluetooth, or BLE, etc. The payment object readeris capable of receiving payment information from a customerthrough one or more payment objects, such as a magnetic-stripe payment card, an NFC card, and an EMV card, or a virtual hardware or software wallet. In one implementation, the payment object readermay be similar to the PPS controllerdescribed in. In another implementation, the payment object readermay be a payment beacondescribed in. Thus, the payment object readercan server as a beacon and transmit payment related information to the customersand/or merchantsbased on one or more communication protocols, such as BLE, RFID, etc. The payment object reader, interchangeably referred to as payment beacon, can be paired with a customer deviceA, e.g., in accordance with the Bluetooth communication protocol. In other implementations, the payment object readeris automatically connected to the customer deviceA based on predefined rules, such as location or identity of the customer device itself. In some implementations, where a plurality of payment object readersare present, the customer deviceA may be presented with a list of available beacons in a predefined area, the beacons being arranged in order of distance from the customer, or signal strength, or in order of the alphabetical names. A user device can also check in by communicating directly with the host deviceor payment beacon, e.g. by providing a BLE token to, e.g., the payment beacon. “Checking in” may thus refer to the customer's action through a user application to indicate availability to conduct a payment transaction, request for payment proxy of the merchant, or communication by the user device of such an indication to the payment processing system or to the host device, as the context requires.

408 402 408 406 Checking in with a merchantallows a merchant application installed on the payment beaconto display an option to charge the user's financial account using a cardless payment transaction via the payment proxy of the merchantor the user. In essence, checking in constitutes a consent by the user to conduct a cardless transaction with the merchant. This consent differs from actual authorization of the transaction, which the user would provide, e.g., verbally, upon learning the amount of the transaction.

404 402 402 402 408 406 402 1 416 402 3 Checking in can also constitute a consent by the user to have radio signal strength of a user device in possession of the user to be measured by the host deviceand by other user devices that are nearby or that have also checked in with the payment beacon. Checking in can also constitute a consent by the user that the payment beaconcan cause the user's device to measure and report the radio signal strength of the payment beaconand other user devices that are nearby or that have also checked in with the merchant. For example, the customer deviceA can measure the radio signal strength being emitted by the payment beacon-, and the customer device associated with customercan measure the radio signal strength emitted from payment beacon-. Similarly, each other customer device can measure the radio signal strength emitted from each other payment beacon, or vice versa.

402 404 406 416 404 404 404 404 402 404 405 The payment beaconcan also query other stationary merchant devices, e.g., host device, for measurements of the radio signal strength emitted by the customer deviceA,A, and so on. The host devicecan also query the customer devices for measurements of the radio signal strength emitted by other customer devices, other merchant devices, and other fixed location beacons. For example, the fixed location beacon can be a fixed BLE device that emits a signal having a unique identifier. The host devicecan then determine a distance of each customer device from the host deviceand the beacon using the obtained measurements of radio signal strength. The host devicecan use the distances to rank the user devices by distance and pair a beaconto a neighboring customer device. Once paired, the beacon can transmit payment proxy for the customer to initiate payments using an application stored or accessed via the customer device. The customer device sends the payment request to the host deviceor directly to the payment processing system.

404 405 402 406 408 404 404 408 405 407 409 104 404 402 The host deviceis capable of processing the transaction via the payment processing systembased on the information received from the payment object readerby causing funds to be transferred from a financial account of the customerto a financial account of a merchantassociated with the host device. The host device, for example a register operated by a merchant, may be connected to a payment processing systemand acquirer/issuerthrough the data communication network(e.g., similar to communication network) to allow transfer of payment information from one entity to another. The host devicemay not necessarily process the transaction as soon as the transaction is performed or when the information is received from the payment object reader. Additionally, a plurality of transactions may be processed in batch at a later time.

402 In some implementations, the payment object readermay include a hybrid interface having a “swipe” slot for receiving magnetic stripe-type cards, “dip” slot for EMV or chip-type cards, and components for interfacing with payment objects operating on Bluetooth, Bluetooth LTE, Wi-Fi, Li-Fi, NFC, mesh network, GPS, and other wireless technologies. In some embodiments, a single component can support capabilities of reading data from a variety of payment objects.

400 In other implementations, the payment object readermay serve as a wireless beacon. Wireless beacon refers to a personal user device that continuously or repeatedly emits mid-range to short-range radio signals that can communicate information wirelessly to other devices. The radio signals emitted by the wireless beacon can be part of any appropriate standard for mid-range to short-range radio communications having an operable range of at least one meter and up to about 50 meters, e.g., Bluetooth, Bluetooth 4.0, and Bluetooth Low Energy (BLE). The radio signals described herein can be any appropriate type of signal, e.g., a broadcast signal that indicates presence of the device to nearby devices, a pairing signal that requests automatic pairing with a nearby device, or a connection signal that transmits data to a connected nearby device, to name a few examples. The wireless beacon can be part of a wristwatch, a mobile phone, a portable music player, a tablet computer, a laptop computer, a personal digital assistant, a smartphone, a keychain beacon, or another handheld or wearable mobile device.

402 402 402 402 402 402 402 402 406 402 1 3 FIGS.- In one implementation, the payment object readercan communicate information, e.g., payment related data, such as payment proxy of the merchant's host device or the payment object reader or both, to another device using an automatic pairing process, e.g., without the devices engaging in a pairing process that requires user input and without requiring explicit user authorization to communicate with another device. The payment object readermay release such payment related data into a predefined network, geographical area or to a selected network of users either persistently or on activation by a user initiated trigger to sensors. This payment proxy may be used by the user to make a payment to a merchant who is associated with the payment object reader, as described in. The payment object readermay be powered in multiple ways, for example using solar batteries, allowing for the payment object readerto be placed at locations requiring minimal supervision and/or for an extended period of time. There may be locations e.g., national parks, ski resorts, gas stations along freeways, etc., where it may not be feasible to install a traditional point-of-sale system due to geographical, terrain, size or economic constraints. There may also be temporary events, such as concerts or plays, where a traditional point-of-sale system may not be a practical solution. The payment object readermay be installed at least at such exemplary locations while keeping the establishment costs and efforts at bay. For example, the payment object readercan be attached to trees at a national park. The payment object readermay optionally include an optical output device to indicate the signal strength of connection between the customer deviceassociated with a customer and the payment object reader.

402 402 402 308 406 402 402 402 Consider a restaurant set-up where patrons are served on different tables. Each table may be provided with a payment object reader. The payment object readermay transmit a unique payment proxy specific to the table. For example, the payment object readermay be transmitting “$Pizzashop_Tablel” or a payment proxy customized by the merchant/recipientaccording to the name on the reservation “$Pizzashop_alex.” At the end of meal, the customermay communicatively couple to the payment object readerto obtain the payment proxy to initiate payment. Optionally, the payment proxy may automatically populate in an application on a customer device or the payment object readerin response to a user indication to make payment. In another implementation, a frequently visiting patron may not need to pair the device every time he or she visits and the same payment proxy may be used for payment after meal. Once the payment proxy is obtained, the customer may use methods and systems described above to cause fund transfer. A confirmation may be sent to the customer via the host device after the transaction is processed and the payment object readermay be reset before seating the next patron.

402 402 408 In another example scenario, consider a state park. To enter the state park and buy a state park entrance, the user may open a payment application, including but not limited to: a messaging application installed on the user device, a web application, a personalized URL, etc. The payment application may allow the user to enter in the “TO” field a payment proxy, email address, phone number, or any other kind of identifier identifying the merchant or the entity to which payment is being made. A payment object readerinstalled at the entrance of the state park may be broadcasting the relevant payment information. So, the payment object readermay be transmitting payment proxy “$californiastatepark” in an area defined by the BLE standards. The user devicethrough its Bluetooth transceiver sees the broadcasted payment information. Such information can be captured and presented to the user on a messaging application, say in the form of list along with the most recent payment proxies with whom the user has interacted in the past.

402 In another embodiment, a quick response (QR) code can also be displayed via an output display device associated with or included within the payment object reader. The user captures an image of the QR code, such as by taking a picture of the code or scanning the code using a camera on a mobile phone or any device that can capture an image. The QR code may include embedded thereon payment proxy or other payment information to enable the user to purchase and pay for a desired product or service, such as park entrance. The QR code can then be decoded or processed, such as by software in the phone. A QR code reader/decoder software may be installed on the user device. The type of display can vary depending on the content of the QR code. For example, the user may be directed to a web page of the merchant selling the product or the establishment managing the facility or providing services, where the user can obtain more details about the product and/or service. The display may also show a more detailed description of the service and additional options for a user to purchase. For example, in an amusement park, the user may using the QR code access the park's website to view various packages, select a package and pay for the desired package using the payment proxy embedded in the QR code.

In other implementations, the user may enter the payment proxy into a messaging application described above. The user may obtain such information from a static or digital display, for example an electrophoretic ink display. The user may also obtain the payment proxy by tapping on the surface of an NFC-enabled payment object reader.

In another scenario, the merchant may push its payment proxy onto a specific device, say based on its distance to a customer device. For example, if the a mobile device is close to merchant's register, the merchant may push the payment proxy, amount owed, and transaction receipt onto the closest mobile device.

In yet another scenario, a merchant may provide a requested product faster than a transaction takes to complete or about the same time it takes to complete a transaction. This may be particularly helpful with EMV transactions that may be associated with slower transaction times. In one implementation, the customer may request a desired product or service by providing a payment proxy associated to their financial account. This solution removes friction from the transaction experience. The customer can leave the point of sale and can complete the transaction at their own pace. Likewise, a merchant can enter the product requested into a register application and select a payment proxy without having to wait for the transaction to get processed completely. For example, consider a coffee store environment managed by Joe and Bob. Joe and Bob can both provide two individual iced coffees in the amount of time it takes for one payment transaction, such as EMV transaction, to occur. Amy, who is under-caffeinated, approaches a Joe and Bob's point-of-sale system manned by Joe and requests an iced coffee. Through Bluetooth mesh-networking technology, Amy's payment proxy appears on Joe and Bob's application in a list of nearby people having payment proxies. Joe adds an iced coffee to the current order and asks Amy for her payment proxy. Joe can also select the payment proxy from available addresses and Amy is free to go.

Joe's selection of Amy's payment proxy immediately sends a request for funds to Amy's messaging application, email client or directly to the financial institution where Amy has an account. Amy steps away and, by fulfilling the request in her mobile device (either by responding to a push notification or entering a PIN code or clicking on a confirmation link), she completes the transaction while Joe begins to take the next order. Once Amy has completed the transaction a notification is made to Joe and Bob's registers. Bob, sees this notification with the order details and grabs Amy's iced coffee. Bob calls Amy's name and hands her the coffee as the next customer's transaction completes just in time for Bob to grab another coffee. In this manner, by splitting the transaction between two people while adding transactions to a pipeline, the overall transaction time is considerably reduced. This can also be applied in Concerts/Festivals where merchandise like shirts, water bottles, etc., are very quick to hand out but are slowed down because in-person transactions take long.

While the description above relates to specific technologies for transfer of payment information, such as payment proxy, it will be understood that the description can be extended to cover other technologies, such as NFC tags, RFID tags, etc.

4 FIG.B 1 FIG. 402 2 402 2 402 3 illustrates an exemplary scenario for implementing an embodiment for transmitting payment proxy. In one implementation, a plurality of payment object readers (interchangeably referred to as payment beacons)-,-,-, such as the PPS controller described inmay be installed in a vehicle parking garage. The parking location can be identified to the user by a location number posted on a parking meter pole or other fixed object at the parking location. Each parking location, such as a single-space stall or a meter number or a parking lot, is associated with a unique location number in a database of the parking payment system such that the system can determine a geographic location for assignment to the user by matching the location number given by the user with a predetermined geographic location stored in the database for that location number. Furthermore, each parking location can be served by one or several readers. Each reader can dispatch payment information specific to the parking location. Thus, when the user pays for the parking session, the parking payment system determines the user's parking location, which is associated with a geographic location or the parking address, and utilizes the geographic location information to process parking related payments. Determining the user's parking location inherently determines the payment reader corresponding to the user.

402 3 3 402 For example, if a readeris installed at row A, spot, may transmit a payment proxy “$parkingA3.” The user's vehicle parked at A-may receive such information, on a messaging application, as a list of suggestions amongst other payment proxies pertaining to other readers. Alternatively, the payment beaconsmay show up as a list of available nodes when the Bluetooth option is selected on the customer device. The “To” field may be automatically populated with the payment proxy information based on the user's geographical location. The geographical location may also be used to confirm user's selection of parking location from amongst a list of suggested entries.

406 416 426 406 416 426 416 2 416 416 For example, users,andmay be associated with a customer device, such as customer deviceA,A, andA, respectively. The userparks a vehicle at A-location and opens an application (third-party/forum/customized website) for payment. The usermay be asked to register or sign-in with a parking payment system (or related application) by using user's personal identifying information, e.g., a contact number (handheld or in-vehicle) or other means of making contact with the user, and optionally, payment proxy information associated with his account. The application also provides service terms that permit collection of location data related to the parking payments. After registration or signing-in, the usercan pay for parking using a parking location by initiating communication with the parking payment system and providing information on the parking location and amount of time to be purchased. The amount of time purchased establishes the duration of time for which the vehicle may remain legally parked. The duration is also referred to as the parking session. In some cases, the parking session may be open-ended and closes only after the vehicle has left the location.

In some cases, the payment beacon may serve as a payment meter, or be associated with a parking meter where the parking session starts when a Bluetooth channel is established or when a sensor (not shown) detects when a vehicle is parked in a parking location. The payment beacon in this case includes a radio transceiver (not shown) for communicating with a parking payment system. As noted, that transceiver can comprise a cell telephone transceiver. Operation of the payment beacon includes transmitting radio signals to, and receiving radio signals from, the parking payment system. Alternatively, the communications between the beacon and the parking payment system can take place over Internet or Wi-Fi communications, cell phone data networks, voice communications links, email or text messaging, SMS protocols, and the like, so long as parking location and user identification data can be transmitted by the meter to the parking payment system for payment authorization, alerts and notifications can be delivered to the user.

416 402 2 402 2 416 The customer deviceA receives the payment proxy transmitted by the nearest payment beacon or its transceiver (payment beacon-, in this case). An associated with the parking payment system shows a list of available payment proxies, including the one transmitted by payment beacon-. In one embodiment, the application gets automatically populated with the received payment proxy of the beacon. Optionally, the usermay choose the payment beacon from amongst the list of beacons in the area. For example, the user chooses the nearest beacon, the location indicating the beacon most likely to be associated with the user's parking location. The payment to a payment proxy indicates payment for a parking location. The user sends the message generated through the application to the parking payment system.

416 Once approved or once the transaction goes through, visual or audio indicators, like light-emitting diodes on the payment beacon may be configured to light up in a specific way to indicate confirmation of payment to the parking security and/or user. The customer device uses cell phone communications to pay for the parking. Other forms of mobile communication can be accommodated, such as WiFi or Internet-based communications among the user and/or the payment beacon device, payment meter, and the parking payment system, such that a user who wants to utilize a parking location initiates communication with the parking payment system (or an application thereof) and provides identification of a parking location and authorizes payment for using the parking location for a specific duration of time (i.e., for a parking session). The technique may be applied to both single-space and multiple space parking. It should be understood that reference to single-space and multiple space parking is a reference to the fidelity of location identification that automatically occurs with payment. That is, if a parking space is located within a parking lot containing many parking spaces, then it may be that the only geographic location information for persons parking at the lot will be a location associated with the lot as a whole. That is, all vehicles parked in the parking lot may be assigned the same geographic location. Alternatively, each parking space in the lot may be identified with a particular geographic location, which is assigned to the user at the time of making payment for the parking session, in accordance with the discussion herein. Parking locations that are single-space locations will be assumed in this discussion, but it should be understood that the principles described herein can be applied to both single-space and multiple space parking. Examples of single-space parking include on-street, single-stall parking spaces.

416 402 2 416 402 2 416 In some cases, the parking time may be extended even though the customer deviceA may not be within the short range network of the payment beacon-. The customer deviceA may already have information related to payment proxy associated with the beacon-, which the useruses on an application of the parking payment system to make additional parking payments. Alternatively, parking payment system may maintain a map associating beacons to parking spots. The user may use information known about the parking spot to determine beacon, and consequently the payment proxy, to make payments for parking.

5 FIG. 5 FIG. 500 100 500 502 516 illustrates an exemplary method for processing one or more payment transactions between a merchant and a customer, according to an embodiment of the present subject matter. The processcan be performed by one or more components, devices, or components such as, but not limited to, the customer devices, the Web server, the application server, the payment processing system, merchant device or POS terminal such as PPS controller, or payment beacon or other component or device. As illustrated in, the processincludes a set of operations from blockto block.

500 502 The processstarts with the operation at block, where the customer opens an application or an interface to initiate a payment transaction. The interface may be a customized interface designed for a specific purpose. For example, at the state park entrance, the user may be asked to open a specific application or website customized for state parks. Alternatively, the customer may access an application installed on the customer device and controlled by the payment processing system.

504 At block, the customer may request a payment proxy from a payment beacon device in response to a payment transaction or to start a payment transaction for a product or service. For example, the customer may activate or engage with the payment beacon device via a software application and/or by providing an audio/video/tactile input with or without the customer device. The customer may switch a button or tap the surface of the payment beacon device to activate the payment beacon to emit a payment proxy. The payment proxy may have a syntax, the syntax including a monetary currency indicator preceding an alphanumeric character. The customer device may then connect, or pair, via Bluetooth protocol, to the payment beacon device to receive the payment proxy. The manner in which the payment proxy is received or the format of data, such as payment proxy, encryption, etc., may vary based on the communication protocols and merchant-customer preferences. Furthermore, the payment proxy may be customized based on the customer requesting the information. In some implementations, the customer may be given the option of a number of payment proxies, for example corresponding to a number of active payment beacon devices, for example as a list and the customer may choose one amongst others.

506 508 507 508 506 The operation at blockdetermines whether a communication component is active on the customer device to receive data from peripheral devices, like the selected payment beacon. For example, the communication component may be a Bluetooth, NFC or Wi-Fi component, configured to receive the payment proxy through communication technologies, such as Bluetooth, RFID, and Wi-Fi respectively. If the determination is “Yes”, the flow proceeds to block. If the determination is “No”, a notification or error message may be sent to the customer to change communication settings on the customer device at block. Alternatively, the communication component may be active but the signal strength may not be strong enough or may be spotty. To this end, a notification may be sent to the customer to change the communication network preference. Thus, the customer device may receive a message requesting a switch from Wi-Fi to Bluetooth for the purposes of receiving the payment proxy. Once the customer makes the selections at blockand the customer input is received to enable the means of communication to receive the payment proxy, the flow returns towhere it is confirmed whether the communication component is active or has been activated successfully.

510 The operation at blockreceives the payment proxy from the payment beacon via one or more preferred or selected communication protocols. For example, the customer may select BLE as a preferred power-saving method to receive payment proxy.

512 On receiving the payment proxy, the operation at blockaccesses a messaging application, a web application, a forum, a customized web application via a unique URL, etc., to generate a message. The message may optionally include a “To” field and a “Body” field. The customer populates the “To” field with the received payment proxy, and may or may not enter content in the body field. The customer may optionally specify a transaction amount in the body field or any other field provided for that purpose. The transaction amount relates to the cost of the product or service. In some embodiments, a message may be generated with prepopulated fields with “To” and “From” information derived from the sender and recipient's payment proxies.

514 512 The operation at blockincludes establishing one or more communication channels with a payment processing system. The customer submits the message of fund transfer generated at blockto the payment processing system, which parses the payment proxy to identify the merchant associated with the payment proxy in the message. The parsing may be based on a stored association between the payment proxy and the merchant, where the stored association may have been established in a registration of the payment proxy with the payment processing system. Such messages may be parsed through the bridge mechanism into appropriate grammar. Entries made into supplied fields may be tagged as having been entered into the particular fields, and parsed as such. The entered terms are then passed along with the field tags, which act to instruct the parser to generate queries directed to appropriate tables and/or fields. In one embodiment, the parser may generate queries in standard query language (SQL) by instantiating a search string with the proper join/select commands based on the tagged text entries, wherein the resulting command is provided over the bridge mechanism to the payment processing system as a query. Upon generating query results from the query, the results are passed over the bridge mechanism, and may be parsed for formatting and generation of new results. Such new results, all determined to be potential identities of merchants, may then be sent to a financial network to process the transaction.

516 514 516 The operation at blockidentifies a financial account, e.g., a debit card account, that is associated with the customer based on the identity of merchant determined at block. The financial account information can be determined based on a stored association between the merchant identity and the financial account, where the stored association is established in a previous transaction (e.g., account registration or a past money transfer). The operation at blockmay be executed by a payment processing system that determines the account associated with the merchant and initiates a transfer of funds indicative of the money transfer amount from a financial account of the customer to a financial account of the merchant to fulfill a payment transaction. In one implementation, the payment processing system can request customer's account information to furnish the fund transfer request. Accordingly, a confirmation message may be sent to the customer and/or merchant confirming successful payment.

6 FIG. 6 FIG. 600 600 100 600 602 614 is a flowchart illustrating an example processof exchanging payment information between a merchant and a customer. The processcan be performed by one or more components, devices, or components such as, but not limited to, the customer devices, the Web server, the application server, the payment processing system, merchant device or point-of-sale (POS) terminal such as PPS controller, or payment beacon or other components or devices. As illustrated in, the processincludes a set of operations from blockto block.

600 602 604 606 606 608 The processstarts with the operation at block. A customer purchases or requests a product and/or service from the merchant. At block, the merchant via a mobile device or POS terminal generates an intermediary transaction summary detailing the product or service requested by the client. For example, the transaction summary includes description of the product or service requested, the price or cost of the product or service, and in case of multiple items, the total amount the customer owes to the merchant, including other costs such as taxes, customs, etc. The operation at blockidentifies the customer device associated with the customer through a customer identifier. Examples of customer identifier include name of the customer, name of the customer device, such as a Bluetooth network ID, payment proxy associated with the customer device, a phone number, an email address, distance between the customer device and the POS terminal, and the like. In some embodiments, the operation at blockis carried out by a receiver component of the POS terminal by connecting with a transmitter component of the customer device. In some embodiments where only one customer device is available in a network, the customer device may be determined or selected without any customer identifier or customer input. In such cases, the flow may skip processing at block.

608 The operation at blockestablishes a communication channel between a payment beacon component of the POS terminal and the receiver component of the customer device, based at least on the client identifier. For example, the communication channel may be based on a variety of communication protocols, such as Bluetooth, Bluetooth Low Energy, RFID, Wi-Fi, NFC, etc. These protocols may be set in the order of preference, such that the unavailability of one network may automatically trigger activation of another protocol. Thus, if Wi-Fi is unavailable, the communication channel may be established using Bluetooth or BLE protocols.

610 612 608 At block, it is determined whether a successful communication is established. In some cases, success may be determined by sending test data on the communication channel and receiving a “set-up complete” flag at the end of set-up. A confirmation message or notification may be sent by and at either or both devices, namely merchant terminal and customer device, indicating successful communication channel set-up. Alternatively, the customer may confirm that a communication channel was successfully established and the flow transitions to block. If set-up fails, the method re-attempts using the operation flow at stepor sends and error to the merchant via the merchant device or point of sale terminal.

612 612 At block, the payment proxy associated with the merchant device, which the client can use for payment of transactions, is transmitted via the established communication channel and preferred or selected communication protocol. The operation at blockrelates to exchanging data via the established communication link or channel. For example, the POS terminal may transmit information to assist the customer to make payments. Thus, the POS terminal or a representative payment beacon device or component may transmit one or more payment proxies relevant to the transaction. The payment proxy, in one implementation, relates to a financial account of the merchant or the merchant's business. In one example, the payment proxy may have a syntax of a monetary indicator preceding or suffixing an alphanumeric character. The POS terminal, through the payment beacon device or component, may also transmit the transaction receipt onto the customer device.

5 FIG. From here, the operation may flow to a customer device where the customer completes the transaction by utilizing the payment proxy for payment. This is explained in. Thus, in one implementation, the customer may enter the payment proxy in a messaging application/forum/website/third-party application and send the request a payment processing system. The payment processing system parses the payment proxy to determine a financial account of the merchant based on a stored association between the payment proxy and the financial account, where the stored association may be established in a previous transaction (e.g., account registration or a past money transfer). The payment processing system then completes the transaction by transferring funds from the customer's financial account to the merchant's financial account. Accordingly, a confirmation link is sent from the payment processing system to the customer device or merchant device or both.

614 At block, the POS terminal receives a confirmation link to confirm transfer of the total amount owed to the merchant from a financial account of the customer to the financial account of the merchant. In some embodiments, the confirmation message is sent to the merchant by using a merchant identifier (e.g., email address).

7 FIG.A 702 702 704 1 704 1 704 1 706 704 704 1 704 704 708 704 1 704 is an exemplary scenario where a number of beacons interact with each other to transmit information to a requesting customer device through a mesh network, according to an implementation of the present subject matter. As shown, a customerwith access to a customer deviceA interacts with a payment beacon-in its vicinity. For example, a customer purchases or requests a product and/or service at a neighboring point-of-sale terminal or through a payment reader or beacon connected thereto. For example, consider a parking garage or a state park where the customer requests for initiation of a parking session by tapping or otherwise interacting with the payment beacon (hereinafter referred to “neighboring beacon.”) In other embodiments, the payment beacon-activates on detecting, through sensor arrangement, a parked car at a parking location. In cases where the neighboring payment beacon-is not associated with the merchant, the neighboring payment beacon can establish a mesh networkwith a remote payment beacon-M (assuming there are N payment beacons from-, . . .-M, . . .-N) associated with the merchantthrough several payment beacons in between the neighboring beacon-and the remote beacon-M.

704 1 704 704 1 704 1 704 1 704 704 2 704 3 704 1 704 1 702 702 704 702 2 704 1 702 704 704 704 1 The superimposing dotted circles indicate which beacons can communicate with each other. To use a neighboring beacon-for purposes of data acquisition from a remote beacon-M, the customer uses a user interface on the customer device or the beacon-and makes such an indication. The neighboring beacon-discovers paths from the neighboring beacon-to the desired remote beacon-M, or another neighboring beacon. In one implementation, the path passes through several beacons, e.g., through-and-. The neighboring beacon-may choose a path of least “hops” and establishes a communication channel between the remote beacon and the neighboring beacon, or the customer device. In this case, the neighboring beacon-connects the customerand his deviceA with the beacon-M through beacon-. For this, the neighboring beacon-or the customer deviceA detects the location of the remote beacon-M through other available wireless or wired communication technologies working in conjunction with location determination technologies. For example, the remote beacon-M can transmit its location information using an internal GPS unit and Wi-Fi connection. Based on the distance, the neighboring beacon-can determine several routing paths, one of which is selected based on user preferences or parameters, such as costs, time, energy, etc., associated with the routing path.

704 702 710 704 714 702 The beacon-M then sends the payment proxy, and other such information through the selected “routing path” (shown by arrows). The customerthen uses the payment proxy to submit a payment request for a product or service to a payment processing system. In some cases where beacon-M is a POS terminal or is connected to the POS terminal, the customer deviceA can channel the payment request through the routing path.

704 1 704 1 704 704 702 704 In some implementations, the neighboring beacon-is only aware of the beacons in its vicinity and has no knowledge of the eventual destination node. As such, the neighboring beacon-cannot pre-design or select routing paths since the routing paths are dynamically changing and/or unavailable to that beacon. The neighboring beacon passes on the request or other such data to its neighbor until the merchant beacon-M is reached through, for example, an ad-hoc routing method. Again, the merchant beacon-M may be one-hop or several hops away. But, as long as a routing table, which is on-demand or constantly updated, exists with the beacons or the customer device, the customer deviceA can connect to the merchant beacon-M.

702 704 702 The term “hop” refers to the number of intermediate beacons or devices the routing path includes before the customer device and the desired remote beacon are connected. Accordingly, the routing path, i.e., the communication channel between the customer deviceA and a remote beacon-M can be a one-hop routing path or a multi-hop routing path based on whether there is one or several intermediate beacons between the customer deviceA, respectively.

While one-hop routing paths can be used, they suffer from problems such as low coverage area and being overloaded. One solution to this is the use of wireless mesh networks (“WMN”). Mesh networking is a way to route data, voice, video, and instructions between beacons (or nodes) of the network separated by several beacons. It allows for continuous connections and reconfiguration around broken or blocked paths by “hopping” from beacon to beacon until the destination is reached. Furthermore, Mesh Networking is particularly suited to wireless networks, where the connections can't be predicted in the same way as a wired network. Wireless mesh networking is mesh networking implemented over a wireless packet radio. It caters to mobile nodes, instant network growth and unpredictable variations in reception and coverage.

Mesh networks differ from other networks in that the component parts can all connect to each other via multiple hops, and they generally are not mobile. Thus each beacon in a mesh network can communicate with other nodes in its immediate neighborhood. Thus, a routing path can be a wireless co-operative communication infrastructure between a massive amounts of individual wireless transceivers (i.e. a wireless mesh) that have Ethernet-type capabilities.

This type of infrastructure is decentralized (with no central server) providing a relatively inexpensive, very reliable, and resilient system as each beacon need only transmit as far as the next node. Beacons thus act as repeaters to transmit data from nearby beacons to peers that would otherwise be too far away to reach, resulting in a network that can span large distances without wired cable in between, especially over rough or difficult terrain. Mesh networks are also extremely reliable, as each beacon is connected to several other beacons. When one beacon drops out of the network, due to hardware failure or any other reason, its neighbors can find another routing path in an ad-hoc manner. Extra capacity can be installed by simply adding more beacons.

Mesh networking operates on a principle similar to the way packets travel around the wired Internet-data hops from one device to another until it reaches a given destination. Dynamic routing capabilities included in each device within the network allow this to happen. To implement such dynamic routing capabilities, each device needs to communicate its routing information to every device it connects with, “almost in real time”. Each device then determines what to do with the data it receives, either pass it on to the next device or keep it. Each beacon within the network must have a unique identity called a network address to facilitate peer-to-peer communication among the nodes. Due to the irregular and spontaneous nature of IP mesh network topology the address assignment becomes a non-trivial issue. To address this issue each mesh point in an 802.11 mesh networks use a MAC address allocated by the manufacture of the device. The Institute of Electrical and Electronic Engineers (“IEEE”) 802.11 standard identifies services that must be provided by a distribution system. A distribution system, be it wireless or wired, is the fundamental part of a network as it is the mechanism by which one access point communicates with another to exchange frames, forward frames to follow mobile stations from one location to another, and to exchange frames with wired networks.

The routing path can be computed using one or more algorithms such as Ad-Hoc Mesh Routing (AHMR), Ad-hoc On-Demand Distance Vector Routing (AODV), Destination-Sequenced Distance Vector protocol (DSDV), Temporally-Ordered Routing Algorithm (TORA), Associativity Based Routing (ABR) and Dynamic Source Routing (DSR).

Most ad-hoc routing algorithms can be divided into one of two categories, namely, table driven algorithms, and source-initiated on-demand driven algorithms. Table driven algorithms are characterized by an attempt to maintain network-wide, consistent, and up-to-date information about the network and the routes from one node to any other node in the network. These algorithms are often associated with a constant propagation of routing information that is routine or triggered by topology changes. This information must be propagated to all nodes, which results in the algorithm incurring substantial amounts of overhead and network traffic. However, because a consistent view is constantly being updated on every node, there is little latency associated with sending initial packets, and routes are always defined. The result of constantly maintaining views of the network topology is accuracy which is a function of the size of the network. However, these algorithms do not scale well, and the level of network overhead increases drastically with the size of the network. Thus, these algorithms have poor scalability characteristics.

Also, available are source-initiated on-demand driven algorithms that build routes on demand, and when a source node requests. There is no need to maintain a consistent view of global network state on each component node, and as such, there is substantially less overhead necessary. However, there is a cost associated with the first query when a route to a specific destination is requested. Furthermore, this cost is incurred on every query to establish a route, which often occurs in association with a broken route. However, the substantially lower level of network overhead resulting from not having to keep a consistent view of the entire network topology on every node allows this class of algorithms to scale better than Table-Driven algorithms. However, these algorithms scale in proportion to the average length of routes. Thus, as length increases, overhead quickly increases.

In some embodiments, the methods and systems may describe the neighboring devices as intermediate devices and beacons that merely receive and send information; it will be understood that each of the neighboring devices may be associated with a respective payment proxy of a unique merchant or customer. As a result, the neighboring device can transmit the payment proxy in a manner similar to the merchant beacon.

7 FIG.B 750 750 100 is a flowchart illustrating an example processof processing wireless payments between a merchant and a customer, or transferring funds between a sender and a recipient through a mesh of payment beacons or readers. The processcan be performed by one or more components, devices, or components such as, but not limited to, the customer devices, the Web server, the application server, the payment processing system, merchant device or point-of-sale (POS) terminal such as PPS controller, or payment beacon or other components or devices.

7 FIG.B 7 FIG.A 750 752 766 750 752 712 702 702 704 1 704 4 704 704 704 714 708 As illustrated in, the processincludes a set of operations from blockto block. The components shown inhave been used for case of explanation. The processstarts with the operation at block, where a location componentwithin a customer deviceA of a customer, discovers all neighboring beacons, e.g., beacons-and-, and the location of the beacon-of-interest-M. For example, the beacon-of-interest-M transmits its location through a combination of GPS and wireless technologies to all neighboring beacons and the customer devices. The merchant beacon-M may also update a central routing table as and when its location changes. The neighboring beacons and the customer device can access the central routing table. The assumption is that the beacon of interest to the customer, in other words, the beacon or POS terminalassociated with the merchant(hereinafter referred to as the merchant beacon) is a single or multiple hops or access points away.

754 712 704 702 712 704 702 704 702 756 704 702 702 758 At block, the location componentdetermines a routing path between the merchant beacon-M and the customer deviceA. More specifically, the location componentdetermines whether the merchant beacon-M is one hop away from the customer deviceA. If the determination yields a “Yes,” i.e., if there are one or less than one neighboring beacons between the merchant beacon-M and the customer deviceA, the three (or two as the case may be) devices are connected by a one-hop routing path at block. However, if there are multiple beacons (or other such entities) between the merchant beacon-M and the customer deviceA, the customer deviceA determines several multi-hop routing paths at block. The multi-hop routing path includes a number of neighboring payment beacon devices proximate to the customer device. The methods and systems to find the most efficient routing path (where efficiency may be based on time, energy, or user-defined parameter) are not discussed herein in detail. Some methods may use the omnidirectional radio-wave propagation property of the beacons. The result is a set of algorithms that intelligently adapt routing paths for energy efficiency and reliability.

760 702 704 1 702 702 702 At block, the customer deviceA selects (either through signal strength determination or by user selection) a neighboring payment beacon, or the closest beacon as defined by the routing path(s). For example, based on a preferred routing path, the method includes activation of neighboring payment beacon-in proximity to the customereither automatically or in response to sensing an activity, e.g., a voice or touch activation by a customer. Additionally, the customer deviceA submits a request for payment proxy to the selected beacon, optionally providing a preference of the routing path.

762 704 2 704 1 704 2 704 3 704 1 704 702 704 At block, the selected beacon communicates with the next beacon, for example, beacon-, as dictated by the routing path. The beacons-,-,-, . . .-(M-), etc., keep creating communication channels or pathways until merchant beacon-M is reached. The selected beacons forward the payment request from the customer deviceA to the merchant beacon-M through the newly established routing path.

764 704 702 704 At block, the merchant beacon-M parses the request and sends its payment proxy (that may or may not be encoded and may also include additional information such as transaction summary with dollar amount associated with the requested service or product) back to the customer deviceA. The merchant beacon-M uses the previously established routing path, or any other that may be more time or energy efficient.

766 702 512 514 516 At block, the customer deviceA receives the payment proxy and optionally, other payment information, to complete the payment transaction. From here, the operation may flow to the customer device where the customer completes the transaction by utilizing the payment proxy for payment. This is explained in blocks,and. Briefly described, in one implementation, the customer may enter the payment proxy in a messaging application/forum/website/third-party application and send the request a payment processing system. The payment processing system parses the payment proxy to determine a financial account of the merchant based on a stored association between the payment proxy and the financial account, where the stored association may be established in a previous transaction (e.g., account registration or a past money transfer). The payment processing system then completes the transaction by transferring funds from the customer's financial account to the merchant's financial account. Accordingly, a confirmation link is sent from the payment processing system to the customer device or merchant device or both.

704 710 702 702 710 714 710 713 104 714 702 In some embodiments, the merchant beacon-M or a POS terminalconnected thereto can process the transaction on behalf of the customer. In this case, the customersends his payment proxy to the POS terminalvia the established routing path. The POS terminalthen generates a message or a payment request on behalf of the customer and submits to the PPSvia network(similar to network). The POS terminalmay send a confirmation request and/or notification of successful/unsuccessful payment transaction through to the customervia the established routing path.

7 FIG.C 780 is a flowchart illustrating an example processof processing wireless payments between a merchant and a customer, or transferring funds between a sender and a recipient through a mesh of payment beacons or readers implementing ad-hoc routing algorithms. The ad-hoc routing algorithms include, for example, Ad-Hoc Mesh Routing (AHMR), Ad-hoc On-Demand Distance Vector Routing (AODV), Destination-Sequenced Distance Vector protocol (DSDV), Temporally-Ordered Routing Algorithm (TORA), Associativity Based Routing (ABR) and Dynamic Source Routing (DSR).

780 100 The processcan be performed by one or more components, devices, or components such as, but not limited to, the customer devices, the Web server, the application server, the payment processing system, merchant device or point-of-sale (POS) terminal such as PPS controller, or payment beacon or other components or devices.

7 FIG.C 7 FIG.A 780 782 792 As illustrated in, the processincludes a set of operations from blockto block. The components shown inhave been used for ease of explanation. The assumption is that the destination node (e.g., merchant beacon) is one or multiple hops or access points away from the source node (e.g., customer device). The source node hops over intermediate node(s) to reach the destination node. Each of the devices have access to a routing table which is either stored locally or on an external server. The routing table includes the routing information to all the destination nodes in the wireless local area mesh network. The data packets are forwarded from the source node to the destination node by the intermediate nodes based on the routing tables along the path. To maintain the valid routes and to avoid the routing loops due to the link/node failure and network topology changes, each node periodically transmits route updates and/or broadcasts the updates immediately when significant new information is available.

780 782 712 702 702 704 1 704 4 702 704 1 702 702 The processstarts with the operation at block, where a location componentwithin a customer deviceA of a customer, discovers all neighboring beacons (intermediate nodes), e.g., beacons-and-, that lie in the communication range of the customer deviceA. Alternatively and as shown, any beacon, e.g.,-may detect any device, e.g., the customer deviceA (and its location) that enters its communication range, e.g., either automatically or in response to sensing an activity, e.g., a voice or touch activation by a customer. The nodes (source, destination and/or the intermediate) can periodically or on activation send beacons (e.g., HELLO messages) to their neighbors. A node receiving a beacon from a neighbor, updates the route lifetime associated with that neighbor in its routing table. If a node fails to receive a beacon from a neighbor for a given lifetime then the link to that neighbor is broken and the routing information for this neighbor is updated in its routing table.

784 704 1 702 704 1 702 704 1 At block, the beacon-establishes a communication channel with the customer deviceA in accordance with, for example, short-range communication protocols. This comprises as one hop. The beacon-also receives a route request (RREQ) message, which may include the source node address and any other additional information, e.g., address of the destination node, preferred route cost, etc. Additionally, the customer deviceA includes in the RREQ, a request for obtaining payment proxy. Optionally, at this step, the beacon-may calculate a metric, such as the route cost between the node from which it received RREQ message and itself and then establishes a reverse route to this originator in its routing table.

786 704 1 At block, the beacon-accesses the routing table, which is stored locally or on an external server, to determine information relating to the next beacon or node. The next beacon is selected based on the speed, load, reliability, or latency of any particular hop or even link cost.

788 704 1 704 1 At block, using the routing table, the beacon-establishes another communication channel or extends the existing communication channel with the next beacon. The beacon-propagates the RREQ message onto the next node along with updated metrics.

704 2 704 1 704 2 704 3 704 1 704 702 704 For example, the selected beacon communicates with the next beacon, for example, beacon-, as dictated by the routing table. The beacons-,-,-, . . .-(M-), etc., keep creating communication links until merchant beacon-M is reached. The selected beacons forward the RREQ from the customer deviceA to the merchant beacon-M through the newly established routing path.

790 704 702 704 At block, the merchant beacon-M parses the request and sends its payment proxy (that may or may not be encoded and may also include additional information such as transaction summary with dollar amount associated with the requested service or product) back to the customer deviceA. The merchant beacon-M uses the previously established routing path, or any other that may be more time or energy efficient.

792 702 512 514 516 At block, the customer deviceA receives the payment proxy and optionally, other payment information, to complete the payment transaction. From here, the operation may flow to the customer device where the customer completes the transaction by utilizing the payment proxy for payment. This is explained in blocks,and. Briefly described, in one implementation, the customer may enter the payment proxy in a messaging application/forum/website/third-party application/social networking tools, and send the request a payment processing system. The payment processing system parses the payment proxy to determine a financial account of the merchant based on a stored association between the payment proxy and the financial account, where the stored association may be established in a previous transaction (e.g., account registration or a past money transfer). The payment processing system then completes the transaction by transferring funds from the customer's financial account to the merchant's financial account. Accordingly, a confirmation link is sent from the payment processing system to the customer device or merchant device or both.

704 710 702 702 710 710 710 702 In some embodiments, the merchant beacon-M or a POS terminalconnected thereto can process the transaction on behalf of the customer. In this case, the customersends his payment proxy to the POS terminalvia the established routing path. The POS terminalthen generates a message or a payment request on behalf of the customer and submits to the PPS. The POS terminalmay send a confirmation request and/or notification of successful/unsuccessful payment transaction through to the customervia the established routing path.

Some nodes want to join the wireless local area mesh network only as the source node or destination node, i.e., not forwarding the traffic originated from other nodes. A node can be configured as a non-forwarding node by the administrator or is determined to be a non-forwarding node based on certain policies. For example, one such policy is that if the energy in the battery of the node is less than a threshold, the node will become a non-forwarding node. A non-forwarding mesh node sends the RREQ message when it wants to transmit packets. It replies to the route request message only if it is the destination node in the received RREQ message. The non-forwarding node does not reply to the RREQ if it is not the destination node in the RREQ message. By so doing, there is no route using it as an intermediate node.

If a link breaks, the Route Error (RERR) message is sent to the affected source nodes of the active paths. The upstream node of the broken link, i.e. the node near the source, initiates the RERR message. Before sending the RERR message, it also marks the damaged routes invalid, sets the metric of the damaged routes to infinite, and increments the destination sequence numbers of the unreachable destinations due to this link failure in the routing table. The RERR message contains a list of all the unreachable destinations due to this link failure and their incremented sequence numbers. It broadcasts the RERR message to its one or more upstream neighbors. For a multi-interface node, it sends the RERR message on the interfaces with the routes using this failed link. When a neighbor receives a RERR message from its downstream node, it checks whether it has a route to use this downstream neighbor to the listed destinations. If so, it marks these routes as invalid and sets the metric of these routes to infinite. It then propagates the RERR message to its upstream nodes. When a source node receives the RERR message, it re-initiates the route discovery. If a node receives a data packet with a destination MAC address that does not have an active/valid route, the node creates a RERR message for the destination node and sends the RERR message to its upstream neighbors, t is necessary to support the quality of service (QoS) in WLAN mesh networks, e.g. for multimedia and video applications. To support the QoS, the QoS requirements, for example, maximum delay and minimum bandwidth requirements for data can be carried in the optional fields of an extended RREQ message. To respond or forward a RREQ message with QoS extensions, a node must be able to satisfy the QoS constraints. Otherwise, it discards this QoS RREQ message.

7 FIG.C It should be noted that in another instance what are currently in, source and destination nodes may be intermediate nodes in the instance that other nodes become source and destination nodes.

500 600 750 780 Regarding the processes,,, and, while the various steps, blocks or sub-processes are presented in a given order, alternative embodiments can perform routines having steps, or employ systems having steps, blocks or sub-processes, in a different order, and some steps, sub-processes or blocks can be deleted, moved, added, subdivided, combined, and/or modified to provide alternative or sub-combinations. Each of these steps, blocks or sub-processes can be implemented in a variety of different ways. Also, while steps, sub-processes or blocks are at times shown as being performed in series, some steps, sub-processes or blocks can instead be performed in parallel, or can be performed at different times as will be recognized by a person of ordinary skill in the art. Further, any specific numbers noted herein are only examples; alternative implementations can employ differing values or ranges.