Patent Application
20050114262
There are a large number of goods and services that in general are inaccessible to electronic payment techniques because of difficulties in creating, maintaining, utilizing the infrastructure required. In typical instances, these goods and services involve payment amounts that are small and location-specific, making it difficult for electronic payment techniques (such as credit cards) to be utilized. These same electronic payment techniques have gained wide acceptance in permanently connected networks such as the Internet, where the server computers that accept payment requests are connected to the infrastructure to authorize these payments via relatively-expensive but highly-reliable communications channels, as well as in retail environments where the expense of a POTS (Plain Old Telephone Service) line which provides a reliable communications channel to an authorization service can be justified.
However, there are a large number of goods and services for which neither of these options is viable from a cost perspective, examples of which are parking meters and vending machines, but where the benefits to the consumer from the convenience of electronic payment options would be vast. In addition, the provider of the goods and services would gain from the reduced reliance on cash as an added safeguard against fraud and theft, and the providers of the electronic payment methods would benefit from increased penetration into new markets. There is therefore a need for an improved method and system for processing payments for goods and services.
To enable processing of payments in the contexts described above, such as, without limitation, parking meters, vending machines, etc., the invention, in one embodiment, includes a method of processing payments using at least a portion of a network of data processing peers, the method including receiving, by a peer, a payment request from a user; the peer receiving the request then dynamically selects a peer belonging to the network, the selected peer being suitable for processing the payment request; the peer that receives the payment request from the user conveys information associated with the user and information associated with the payment to the selected peer; and, in response, the selected peer launches an attempt to debit an account associated with the user, based at least partially on the conveyed information.
According to one practice, the dynamic selection of a peer as the suitable peer is performed based on a metric. The metric include, without limitation, route length (measured, for example, in terms of physical distance, number of hops on the network, or other similar measure), route latency (data transfer or peer processing delays), data transmission speed, peer availability, cost overhead associated with a peer (for example, a peer may include a higher fee for implementing the payment processing than another peer), and a combination thereof.
According to one practice, the dynamic selection of a suitable peer includes sending, by the peer receiving the payment request from the user, of a ping—a discovery or exploratory signal or message—to one or more peers on the network with which the receiving peer is configured to communicate with. The ping message solicits a response regarding, among other things, availability or the pinged peer and capability of the pinged peer to process the payment request. In one aspect, in response to the pinging, the pinged peer determines whether a record exists of a prior request by the user. If a record exists, the pinged peer determines whether a characteristic of the record provides sufficient justification for the pinged peer to authorize the payment request, that is, response positively to the payment request.
According to one practice, if the pinged peer declines, for whatever reason, to process the payment request, the pinged peer attempts to locate an alternate peer on the network available, capable, and willing to process the payment request. If the pinged peer's attempt to locate the alternative peer is successful, the pinged peer responds to the receiving peer (the peer receiving the initial request from the user) the information, including the route, associated with the alternative peer. According to one embodiment, the peer receiving the initial request from the user selects itself as the suitable peer for processing the payment.
According to one aspect, the method includes alerting the user about success or failure of the attempting by the selected peer. In one practice, if the attempt by the selected peer to generate a charge against the user's account is successful, a good, a service, a privilege, or a right is granted to the user. In one embodiment, the selected peer reports to a monitoring peer on the network at least a portion of the conveyed information and information about success or failure of the attempt to generate the charge. In one aspect, the monitoring peer stores the reported information at a data storage repository.
According to one embodiment, the information to the selected peer is first relayed by one or more message-passing peers, acting as intermediary peers, before reaching the selected peer. In one practice, the selected peer attempts to locate a payment processing service, generally outside of the network but not necessarily so, available, capable, and willing to process execute a charge/debit against an account associated with the user. The account may belong to the user or it may belong to another party granting the user access/withdrawal privileges. Examples of payment processing services include, without limitation, a combination of a credit card processing center, a bank, or any other financial transaction clearinghouse.
According to various embodiments, the network of peers include parking meters, vending machines, utility meters at residential or other real estate properties, fuel pumps at fuel stations, etc. According to various embodiments, the network of peers may be interconnected by wired links, wireless links, or a combination thereof. The peers may communicate over public channels, or more typically, over private channels or secure channels. Various modalities for secure transmission of data may be employed by the methods and systems described herein; for example, authentication and encryption may be used to implement various embodiments of the invention.
In one embodiment, the invention is directed at a payment processing method using a network of data processing peers that includes a peer receiving a payment request from a user; the peer, based at least on cached (or otherwise stored) information about availability and service competency of the peers, selects a suitable peer on the network to process the payment request; the peer conveys the user's information and the payment information to the selected peer; and the selected peer attempts to debit an account associated with the user, based at least partially on the conveyed information. In one aspect, the methods and systems described herein update the stored information about the availability and competency of the peers when (or after) the selected peer responds to the payment request. In particular, the stored information is updated, according to one aspect, when a result is reached, positive or negative, regarding the payment request by the user. Other updating schemes, such as periodic updates, real-time updates, updates according to dynamically-generated schedules, etc. can be employed.
The updated information is used by the peer for future payment requests. By the competency of the peers what is meant includes whether they are capable and/or willing to perform a certain requested service. For example, if a particular peer has in the past denied a certain request type, then information is stored reflecting this fact for future reference. In one practice, the peer managing and/or referring to the stored information broadcasts the updated information to at least one other peer on the network, so the one other peer can make use of the updated information. In one practice, the stored information is updated to reflect an addition of a peer to the network. In another practice, the stored information is updated to reflect a deletion of a peer from the network. The deletion of the peer may be temporary (for example, while the peer is repaired after a failure), or it may be permanent. Similarly, addition of a peer may be temporary (for example, while the peer is substituting another peer on the network), or it may be permanent (for example, due to network expansion).
The following figures depict certain illustrative embodiments of the invention in which like reference numerals refer to like elements. These depicted embodiments are to be understood as illustrative of the invention and not as limiting in any way.
The present invention provides a method and system for purchasing of goods and services using electronic payment via a peer-to-peer network. This allows for dynamic and robust routing of a payment request when one or more of the peers in the network fail, are unable to process the payment request, or are otherwise not available. The user gains increased convenience by increasing the range of goods and services that accept electronic payment; the provider of the goods and services benefits from the increased ease with which their product can be purchased.
The systems and methods described herein may employ a number of devices, according to various embodiments. For example, a peer includes a data processing unit on the network (or equivalently, belonging to the network, or being of the network) and may be a device capable of participating in a data communication exchange, as a source of a message, a receiver of the message, or as a message transfer agent relaying the message between another set of peers.
A payment request terminal (PRT) is another device that is typically used by the systems and methods described herein to collect payment information from a user and forward the collected information to one or more peers on the network. The PRT can be connected to a peer using a wired or wireless communication channel. The PRT may include a user interface to interact with the user, instructing the user on steps to follow to make a payment request, and/or informing the user of the status of the request.
A purchase request peer (PRP) is another device used by the systems and methods described herein. Typically, a PRP includes a peer that collects payment and user information from the PRT and generates a payment request message to be broadcast (or somehow conveyed) to the other peers on the network.
A message-passing peer (MPP) is another device that may be used in various embodiments of the systems and methods described herein. An MPP typically includes a peer belonging to the network that relays the message between two or more other peers; in other words, an MPP serves the role of, among others, an intermediary peer relaying data between two or more other peers.
A payment-processing peer (PPP) is another device employed by the systems and methods described herein, typically to receive the payment request from a PRP. In response to the payment request, the PPP typically attempts to generate a charge, that is, debit an account associated with the user, by accessing a payment-processing service. In certain embodiments, the PPP authorizes a payment request (i.e., responds positively to the request), if it finds a prior record associated with the user indicating a healthy history of payment requests. This authorization may be issued by the PPP even without accessing a payment processing service; it may be based on information available to the PPP.
A purchase monitoring peer (PMP) includes a peer that the systems and methods described herein may optionally employ to monitor a payment request result and/or perform additional processing on the payment request. In certain embodiments, the PMP may archive the result or results of one or more payment requests associated with one or more users, for future reference or retrieval.
A subset of the peer types described above may be “smart” in that they may be configured (through preprogramming or by being equipped with an artificial intelligence capability or other methods known in the art) to robustly and dynamically determine a data communication route to any other peer in the network.
One embodiment provides a method and system for paying for goods and services via a network of self-organizing peers. The peers within the network may have different capabilities that are available to the providers of the goods and services. A user with an acceptable form of electronic payment makes a payment request via an appropriate PRT that is in communication with the network via a PRP. The PRP selects a suitable PPP on the network with the capability to generate a charge against the user's electronic payment modality, that is, the selected peer attempts to debit an account associated with the user or debit an account which the user is authorized to draw funds from.
The suitable peer may be determined by a number of different metrics; for example, and without limitation, route length, route latency, data transmission speed, peer availability, cost overhead associated with a peer, and a combination thereof, may be used in selecting a suitable peer on the network to process the payment request. In one embodiment, the closest PPP in terms of distance from the PRP is deemed as the suitable peer. The electronic payment information (such as account information and charge amount) is then forwarded to the PPP through the network via zero or more MPPs. In a typical embodiment, the user enters a unique identifier, such as a password or personal identification number (PIN) to identify himself or herself to the network. Other unique identifiers may be used in lieu or, or in addition to, a password or PIN. For example, and without limitation, a signature, a fingerprint, an iris scan, a retinal scan, voice, or any biometric signature may be employed in identifying the user.
Upon receiving the payment request, the PPP attempts to generate the charge, and then reports a result of the attempt to the PRP, as well as any PMP that may have requested a notification of such payment requests. As an example, such a PMP may serve as a storage repository that keeps track of requests, and their respective successes and failures, possibly for future reference and/or retrieval. In one embodiment, the PPP accesses a database of prior payment requests to determine if a prior payment request record exists of the user. If a record exists, the PPP then makes a determination as to whether the prior record provides sufficient grounds to authorize the current payment request by the user. For example, if the user has, on one or more previous occasions, submitted one or more successful payment requests, perhaps for an amount greater than the current request (but not necessarily so), then the PPP may authorize the current payment request, even without communicating with a payment processing service. In this fashion, the systems and methods described herein provide the user the ability to build a “credit” history associated with the network, gradually becoming more and more creditworthy as more and more payment requests by the user are successful. The ability of the network of peers to coordinate the processing of payments in this fashion is an aspect of the self-organization of the network and the peers belonging to the network.
Upon receiving the response, the PRP may return this information to the PRT that generated the original request. In addition, other actions may be taken, including providing the requested goods, services, privileges, and rights to the user if the response was positive, or displaying error information to the user if the response was negative or if the request could not be completed. An example of a privilege is, for example, when the user has requested time at a parking meter. Upon successful processing of the user's payment request, the user is granted the privilege of using a designated parking spot to park his or her vehicle for a predetermined length of time.
In one embodiment, the peer-to-peer network is created between geographically separated devices that accept payment in exchange for a specific good, service, privilege, right, or a combination thereof; without limitation and as mentioned earlier, one example of such a network is a network of parking meters. The peers within the network are interconnected using communication links; these links could be wireless or wired.
One embodiment of a wireless peer-to-peer network uses radio frequency signals for communication and includes self-organization. In an exemplary embodiment, self-organization refers to a peer sending another peer a message; the message may pass between zero or more intermediary peers (MPPs) belonging to the network, as determined by the network either in real-time or at predetermined intervals which may or may not be periodic; and there may be multiple routes between any two peers, where each route includes a sequence of other peers that can relay the message. The network includes peers that, according to various embodiments, may all directly or indirectly communicate with each other; however, in general, the ability to communicate does not translate into a requirement to communicate. In a typical embodiment, the majority of peers do not necessarily communicate directly to each of the other peers.
In addition, the network may include peers having distinct, overlapping or non-overlapping capabilities; for example, distinct peers may offer distinct services to other peers on the network. Moreover, a particular peer-to-peer network may be a sub-network of a larger system of peer-to-peer networks connected across a WAN, a LAN, or other data communication infrastructure known in the art. The data transfer protocols used by the peers may include any of the commonly-known protocols, such as TCP/IP. Data transfers between and among peers, as well as between any peer on the network and a device outside of the network may include encryption, secure socket layer (SSL) or other secure data tunneling, authentication, or any of the known security protocols known in the art.
In a specific embodiment, payment is accepted for a specified good or service; the price may be fixed in advance or dynamically generated. For example, if the user has a history of purchasing goods and/or services, the vendor of the goods and/or services may grant the user a discount or other benefit. When a user wishes to purchase the good or service, the user can choose to make a payment request using any of a number of acceptable electronic payment options. This payment request may include identifying account information and payment information. The request may also include a unique identifier associated with the user, such as a password or PIN, as mentioned previously.
The payment request is collected using a PRT, which may be any device with the ability to collect the payment request information from the user. In one embodiment the PRT is a credit card reader built into a retail vending machine, and the user presents a credit card to pay; in another embodiment the PRT could be a Bluetooth communications interface, and the user activates a Bluetooth-enabled wireless phone to pay. The PRT may be an integral part of a peer belonging to the network; that is, there may be a physically-wired connection or the PRT may occupy the same housing as the peer; one embodiment of this is a credit card reader built into a parking meter.
The PRP that receives the payment request from the PRT attempts to locate a PPP on the network with the capability to generate the requested charge against the user's account; the determination of the route may be done in real time or using cached information (such as a record from a previous request by the user). A message containing the payment request is generated and sent to the PPP through the network. The actual path that the message traverses (including the sequence of MPPs that relay the message) may differ from the determined route, depending on the design of, and conditions prevailing over, the peer-to-peer network. Another aspect of the self-organizing ability of the peers on the network is their ability to robustly and dynamically select a suitable peer for processing the payment and routing the user's information (along with payment information) to the selected peer.
The PPP attempts to generate the requested charge, and then sends a message to the PRP via zero or more MPPs (not necessarily using the same route through which the payment request arrived from the PRP to the PPP) with the result: acceptance of the specified amount or a rejection (possibly with a description of the error that occurred and other additional useful information). In addition, the PPP may notify zero or more PMPs about the result (for supervisory and/or archival purposes, for example).
When the PRP receives the return message, it provides this information to the PRT (if it is necessary) and the PRT may forward a message or confirmation data to the user. The PRT then may forward a message to other devices it may be in communication with that may then take action based on the results; such actions may include dispensing product (in a vending machine embodiment) or providing time (in a parking meter embodiment).
In one embodiment, the PRP chooses a PPP based at least partially on stored information about the availability and/or competency of the peers on the network. For example, and without limitation, the stored information may indicate that a particular peer has, for previous payment requests, denied requests of a certain type. Using this information, the PRP may decide to avoid requesting service from the PPP for that particular type. When, or after, a payment request is processed, successfully or unsuccessfully, the stored information may optionally be updated to reflect any new salient information regarding the availability and/or competency of the peers on the network. By competency, what is meant includes, for example, whether a particular peer is configured or willing to process a particular payment type. Updated information about the availability and/or competency of the peers may then be broadcast to one or more other peers on the network.
In one aspect, the information may be updated to include information about addition of a peer to the network, subtraction of a peer from the network, or both. The peer-to-peer network of the methods and systems described herein is, in one embodiment, scalable; that is to say, the network is configurable to have peers added to or subtracted from it. The stored information can readily reflect this, and be used by the PRP to process the payment request.
Turning to
In addition, specific peers may offer services to the network as a whole, such as a payment processing service 106 (which allows certain electronic payments to be processed). Peer 102 may request a payment using an electronic payment option accepted by 106 by sending an appropriate message to peer 104 (through peer 103); peer 104 may then access the payment processing service to fulfill the original payment request. In that instance, peer 102 is serving as a PRP, peer 103 as an MPP and peer 104 as a PPP. This payment processing service may require access to an external service provider, such as a credit card verification service over a telephone line. Other services may also be available through peers within the network, such as a post-processing service 108 available via peer 107. An example of such includes a storage service that tracks all failed payment requests (employing, for example, a database). Moreover, there is a wide variety of channels and encoding schemes that could be used to communicate between the various peers, and these need not be identical; a mix of wired and wireless devices could still form a peer-to-peer network. As mentioned previously, a variety of security systems may be employed to protect data transfer between and among the peers on the network, such as those described in Bruce Schneir, Applied Crytpography (Addison-Wesley 1996).
A specific embodiment of such a system is illustrated in
Turning to
Aspects of the behavior of the power port 203 may also be controlled by the control logic 201. Typically, the power port includes a gateway through which a peer receives power from a source, such as a power outlet or a power line. In one embodiment, the power port may be connected to a solar-powered battery to power the peer; an example of an application of this is a parking meter, for example, that can use solar energy to power itself.
The peer may be connected—via one or more communication channels—to, among other options, a payment request terminal (PRT) 204, an interface to a wide-area network (WAN) 205 such as the Internet, or a payment processing service 206. The PRT 204 includes, in an illustrative embodiment, a user interface that can be used to prompt the user for input, and for conveying information to the user. The user interface screen may optionally include a touch screen or other commercially available monitor, such as a liquid crystal display (LCD) or a cathode-ray tube CRT). The PRT 204 may optionally include a credit card reader, which the user can use to swipe his or her credit card as part of requesting payment processing from the peer-to-peer network. In one embodiment, the PRT 204 includes a keyboard or keypad or other similar input device to provide the user with a means of entering information into the network. In one embodiment, a data entry interface similar to that used in personal digital assistants, is used to allow the user to enter information. For security purposes, the PRT 204, may optionally include a fingerprint scanner, a signature reader, an iris or retinal scanner, or other security devices used for verifying the user's identity.
In step 308, the payment processing service returns a result to the PPP; this result may be an acceptance, indicating that the requested payment was successfully performed, or a rejection, indicating that the requested payment did not occur. The PPP then returns the result to the PRP in step 309. In step 310 the PRP returns the result to the PRT, which may then take action; in one embodiment, the PRT is a parking meter, and if the requested payment is successfully performed, the user is granted time on the meter.
Regardless of which approach is taken, in step 404 a peer receives a service discovery message, and checks to see if it offers the requested service. In step 405, the peer receiving the service discovery message does offer that service, so it sends a response to the discovering peer indicating that fact, and the discovering peer continues at step 412. In step 406, the peer that received the service discovery message does not offer the desired service, so it checks if it currently has a pre-determined route to the desired service in memory. If it does, the peer that received the service discovery message returns the route to the discovering peer in step 407, and the discovering peer continues at step 412. In an illustrative embodiment, this route includes a sequence of peer identification numbers and their communications channel information, with a peer disposed along the sequence (typically the last peer) designated as offering the desired service. In step 408, the peer that received the service discovery message checks to verify that the maximum route length has not been exceeded. If it has, in step 409 the peer that received the service discovery message returns a message to the discovering peer indicating that no acceptable route was found, and then the discovering peer continues at step 411. In step 410 the maximum route length has not been exceeded, and the peer that received the service discovery message increments the current route length and restarts the discovery process. In step 411, the discovering peer may choose to restart the discovery process with a larger maximum route length, or to perform some other action based on the unavailability of the desired service. In step 412, the discovering peer either relays the determined route to the peer that originated the service discovery message, or (if the service discovery message was originated at this peer) it stores the route. One skilled in the art would appreciate that there are a wide variety of additional optimizations that could be applied to this process, as well as other possible service discovery protocols that could be deployed, and that this is just one specific embodiment.
The contents of all references, patents and published patent applications cited throughout this Application, as well as their associated figures are hereby incorporated by reference in entirety.
Although the present invention has been described in terms of various illustrative embodiments, it is not intended that the invention be limited to these embodiments. Embodiments of the invention can be applied in many situations where geographically separated devices within reasonable proximity are interconnected using a communication medium. For example, one embodiment includes utility meters in a residential setting, which are interconnected with power lines; in one aspect, a homeowner can pre-purchase electricity from the meter with a credit card without needing to talk to a representative or to mail in a voucher.
Those skilled in the art will recognize, or be able to ascertain using no more than routine experimentation, many equivalents to the specific embodiments of the invention and the specific methods and practices associated with the systems and methods described herein. Accordingly, it will be understood that the invention is not to be limited to the embodiments, methods, and practices disclosed herein, but is to be understood from the following claims, which are to be interpreted as broadly as allowed under the law.
This application incorporates by reference in entirety, and claims priority to and benefit of, U.S. Provisional Patent Application No. 60/463,078, filed on Apr. 15, 2003.
| Number | Date | Country | |
|---|---|---|---|
| 60463078 | Apr 2003 | US |
