SEND MONEY PLUG IN FOR WEB MAILS
In one example embodiment, a system and method is shown as including receiving an email address selection displayed as part of a screen widget, the screen widget included within the display of an interface associated with an Internet-utilizing application. Further, this method may, for example, include executing a plug in having a send money function, the plug in associated with the Internet-utilizing application, the send money function executed due, in part, to a signal received from an input device. The method may additionally include generating a payment request identifying a recipient of funds by the e-mail address selection.
Latest Patents:
The present application relates generally to the technical field of transaction algorithms and, in one specific example, the use of a transaction algorithm to verify a payment request.
BACKGROUNDPersons may be uniquely identified by their e-mail address. This e-mail address may be used as a location at which to receive a communication. This communication may be text based and may contain certain attachments or other vehicles to transmit information. In certain cases, financial information may be communicated.
Some example embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which:
Example methods and systems are disclosed to select an e-mail address as it may appear on the Interface for an Internet-utilizing application for the purpose of sending money to this address. In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of example embodiments. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.
In some example embodiments, a system and method is illustrated that allows a sender of funds to select an e-mail address, and to send funds to the owner of the e-mail address. A sender of funds may be a user of an Internet-utilizing application who desires to send funds to an owner of an e-mail address. Internet-utilizing applications may include any application (e.g., a Web browser, e-mail client, or Web-based e-mail) that can display executable Web links, in the form of, for example, e-mail addresses. These executable Web links may be executed via the use of some type of input device such as a mouse, light pen, keyboard, or other suitable input device.
Some example embodiments may include, the use of a plug in or other helper application that may be used in conjunction with a Internet-utilizing application. This plug in may utilize technologies including Asynchronous Javascript And eXtensible Markup Language (XML) (collectively referenced as AJAX), Dynamic Hyper Text Markup Language (DHTML), a Java Applet, Java Script, Visual Basic Script, XML, HTML, FLASH™, or some other suitable technology that allows an application to run within the context of another Internet utilizing application. Some example embodiments may include the use of a stand alone application in lieu of a plug in utilizing one or more of the above referenced technologies.
In one example embodiment, the plug in may generate a drop down menu or other suitable screen widget or object that may appear within the display for an Internet utilizing application. This drop down menu may then allow a sender of funds to select a recipient of funds identified through some type of unique identifier such as an email address. The implementation details of this selection process is more fully discussed below.
In one example embodiment, a cursor control device such as a mouse is used to select an e-mail address as it might appear in the interface for an Internet-utilizing application. The selection of this e-mail address may be through, for example, left clicking on the e-mail address (e.g., using the mouse to point to the email address and pressing a left button associated with the mouse). In some example embodiments, a mouse over action may be used to such that when a mouse pointer is placed into close proximity to an email address displayed with the Internet utilizing application, a drop down menu or other suitable screen object or widget will appear. Some other suitable way of putting the focus on the e-mail address may also be used. A right-click function may be used to display a drop-down menu and to select a send money function so as to generate a payment request to be sent over a network.
Some example embodiments may include receiving the payment request at a payment processor server and requesting additional information regarding the payment request. In some example cases, a payment processor server may be operated by a payment processor corporation such as PAYPAL™, VISA™, or MASTERCARD™. Additional information may include the amount of the payment, currency type information, payment purpose information, or other suitable information. Additionally, a determination may be made as to whether the sender of funds and the recipient of funds have an account with the payment processor, and more specifically the payment processor server. In some example embodiments, an account may be a set of data associated with a user, where this set of data uniquely identifies the user and various financial institution accounts that hold money. In certain cases, the recipient of funds may be prompted to set up an account with the payment processor. In other cases, however, the recipient may not be required to set up an account. Part of the set-up process, be it for the sender of funds or the recipient of funds, may be the designation of an account to be linked to by the payment processor account. Specifically, at account set-up time the sender of funds or recipient of funds, may be asked what Financial Institution (FI) accounts (e.g., the account or sender of funds account) are to be linked to, to supply funds to the payment processor account. These linked-to accounts may include checking accounts, saving accounts, debit card accounts, annuity accounts, savings accounts, or some other suitable type account.
In some example cases, once the payment processor accounts of the sender of funds and the recipient of funds are verified, funds may be transferred between a sender-of-funds account and a recipient-of-funds account. For example, funds may be transferred from a sender-of-funds account as it resides on a payment processor server, to a recipient-of-funds account as it resides on a payment processors server. Further, in another example embodiment, funds may be transferred from one FI account held by the sender of funds to another FI account held by the recipient of funds. In one example embodiment, funds may be accessed after a transfer has occurred.
Example SystemIn some example embodiments, the payment request 107 may be a data packet used to identify a sender of funds 101 and/or a recipient of funds 114. This payment request 107 may be encoded using any one of a number of network protocols such as, for example, the Transmission Control Protocol/IP (TCP/IP), or some other suitable protocol used to implement the Open Systems Interconnection (OSI) model or TCP/IP protocol stack model. The manner in which the sender of funds 101 and the recipient of funds 114 are identified may include an email address, phone number, or some other suitable way of uniquely identifying an individual.
In some example embodiments, the payment process server 109 may transmit a transaction information page 111 back across the network 108 to be displayed using the Internet utilizing application 112. This transaction information page 111 may, amongst other things, ask or request data relating to the amount to be sent to the particular e-mail address referenced in the payment request 107, and may ask other suitable information. In a further example embodiment, as will be more fully discussed below, cookie data may be retrieved from the Internet-utilizing application 112 such that the transaction information page 111 may be automatically filled in. In some example embodiments, the cookie data may be stored in some type of text based file (e.g., a cookie) containing information relating to, for example, account information for a particular sender of funds.
Some example embodiments may include the payment processor server 109 validating the recipient information and the availability of funds. Specifically, the payment processor server 109 may transmit a funds availability and account setup link page 113 across the network 108 to a recipient of funds 114. The recipient of funds 114 may be a single individual, or a plurality of individuals. Further, these individuals may be identified via a mailing list (e.g., a mail serve list) or other suitable list for identifying individuals utilizing a network. This recipient of funds 114 may use an Internet-utilizing application 112. As previously discussed, this Internet-utilizing application 112 may reside on any one of a number of devices 102. In certain example cases where the recipient of funds 114 does not have an account with the payment processor server 109, the recipient of funds 114 may have to execute an account setup link that is part of the funds availability and account setup link page 113. Once this account setup link is executed via an input device used in conjunction with the Internet-utilizing application 112, account setup information 115 may be transmitted across the network 108 to the payment processor server 109; thus, setting up an account for the recipient of funds 114 on the payment processor server 109. In some example embodiments, funds may be transferred from one account residing on the payment processor server 109 to a second account residing on the payment processor server 109. In other example embodiments, once the recipient of funds 114 sets up an account or already has an account created, the payment processor server 109 may transmit a funds transfer instruction 116 across the network 108 to a financial institution server 117. The financial institution server 117 may then actually transfer funds from the account held by the sender of funds 101 to the second account held by the recipient of funds 114.
Example InterfacesIn some example embodiments, an operation is executed to receive a payment request identifying a recipient of funds by an e-mail address. Further, an operation is executed to determine if the recipient of funds has an account and a sender of funds has an account. Moreover, an operation is executed to determine if funds exist in the sender of funds account to cover a payment request amount. In some example cases, an operation is executed to transfer funds to a recipient of funds account, where the sender of funds has funds to transfer that cover the payment request amount. The account is a payment processor account, in some example embodiments. Transferring funds may occur where valid sender transaction data, valid available funds data, and a valid recipient signal are provided. Some example embodiments may include executing an operation to request transaction information from the sender of funds, wherein the requested transaction information includes at least one of an amount of currency, a currency type, a payment purpose description, a linked account identifier, and a payment message. The transaction information may be stored in a cookie. In some example embodiments, an operation is executed to de-obscure the payment request using at least one of a symmetric encryption algorithm, an asymmetric encryption algorithm, or a hashing algorithm.
In some example embodiments, a selection input is generated through the execution of an operation 1301. This selection input may be, for example, input generated, in part, by some type of input/output device such as a mouse, light pen, keyboard, or other suitable input device. Further, when executed, an operation 1302 receives the selection input, which in this case is, for example, an e-mail address. A decisional operation 1303 may be executed to determine whether or not the syntax of the received e-mail address is correct. The correctness of this syntax may be dictated by the requirements of a grammar as defined by, for example, a standards body such as the World Wide Web Consortium (W3C), or as defined in certain Requests for Comments (RFCs). In cases where decisional operation 1303 evaluates to “false,” an operation 1304 is executed that generates an error message that puts, for example, the sender of funds 101 on notice that the e-mail address that they are attempting to send funds to is invalid syntactically. In cases where decisional operation 1303 evaluates to “true,” a further operation 1305 is executed.
This operation 1305 may format the selection input for a transmission, that is, operation 1305 may actually encode, wrap, or otherwise format the selected e-mail address for transmission across the network 108. This formatting may include, for example, the use of the Hyper Text Transfer Protocol Secure (HTTPS), Secure Sockets Layer (SSL), Secure Shell (SSH), and other suitable protocols to obscure the selection input. The HTTPS, SSL, SSH, and other suitable protocols may be used in conjunction with TCP/IP such that a session may be established between, for example, the one or more devices 102 and the payment processor server 109. During the session, a transaction information page 111 may be provided to the sender of finds 101. An operation 1306 may also be executed that transmits the formatted selection input as a payment request, such as payment request 107. The operation 1306, when executed, may apply further link layer and physical layer formatting.
In some example embodiments, the payment request 107 is then transmitted and received through the execution of an operation 1308. An operation 1309 may be executed that extracts a recipient identifier, such as an e-mail address, from the payment request 107. A decisional operation 1310 may be executed to determine whether or not the recipient identifier (e.g., e-mail address) is syntactically correct. In cases where a decisional operation 1310 evaluates to “false,” an operation 1312 is executed that generates an error message. In cases where a decisional operation 1310 evaluates to “true,” a further operation 1311 is executed that requests sender information. This request for sender information will be more fully discussed below, but may include, for example, validating that the sender of funds 101 in fact has an account with the payment processor server 109. Additionally, it may include verifying that funds are available to be sent by the sender of funds 101. Operation 1313 requests recipient information. This operation 1313 may be more fully discussed below, but may include, for example, determining whether or not the recipient of funds 114 has an account with a payment processor server 109, and what financial institution accounts may be linked to this account with the payment processor server 109 and other information. A decisional operation 1314 may be executed that determines whether or not funds exist for the transaction to move forward. In cases where a decisional operation 1314 evaluates to “false,” an operation 1315 may be executed that generates an error message instructing or otherwise informing the sender of funds 101 that sufficient funds do not exist to complete the transaction. In cases where a decisional operation 1314 evaluates to “true,” a further operation 1316 is executed that actually transfers funds to the recipient of funds 114. Operation 1317, in some example embodiments, acts to settle accounts such that the actual transfer of funds from an account held by the sender of funds 101 to an account held by the recipient of funds 114 may be reflected in the balances for each of the respective account holders.
In example cases where a decisional operation 1604 evaluates to “true,” a further operation 1607 is executed that retrieves obfuscation settings. This operation 1607 may also be executed upon the completion of the execution of the operation 1605. These obfuscation settings may be retrieved from, for example, a database 1606. The obfuscation settings may include settings relating to various types of encryption, hashing, or other suitable types of obfuscation. In certain example instances, a decisional operation 1608 is executed that determines whether or not the sender data is to be symmetrically encrypted. In example cases where a decisional operation 1608 evaluates to “true,” an operation 1609 is executed that asymmetrically encrypts the sender data using some type of public or even private key that uses an asymmetric encryption algorithm such as, for example, Rivest, Shamir and Adleman (RSA), or Diffie-Hellman. In example cases where a decisional operation 1608 evaluates to “false,” a further decisional operation 1610 is executed that determines whether or not the sender data is to be symmetrically encrypted. In example cases where a decisional operation 1610 evaluates to “true,” a further operation 1611 is executed that applies a symmetric encryption algorithm to the sender data. This symmetric encryption algorithm may be, for example, the Twofish algorithm, the Serpent algorithm, the Advanced Encryption Standard (AES) algorithm, or even the Blowfish algorithm, amongst other suitable symmetric encryption algorithms. In cases where a decisional operation 1610 evaluates to “false,” a further decisional operation 1612 is executed that may act to hash the sender data. In cases where a decisional operation 1612 evaluates to “true,” a further operation 1613 is executed that may, for example, hash the sender data using any one of a number of suitable hashing algorithms such as Message-Digest algorithm (MD5), Secure Hash Algorithm (SHA)-1, or some other suitable hashing algorithm. In cases where a decisional operation 1612 evaluates to “false,” a resulting formatted selection input 1614 is generated. In some example embodiments, sender data may be hashed, symmetrically encrypted, asymmetrically encrypted or may be modified using any one of a combination of these obfuscation techniques (e.g., asymmetric encryption, symmetric encryption, and/or hashing).
Decisional operation 2005 may be executed to determine whether or not the Internet-utilizing application 112 used by the sender of funds 101 contains cookie information or other types of digital information in its cache. This cookie information or other type of digital information may be used to provide information regarding the particular transaction that the sender of funds 101 seeks to engage. In example cases where a decisional operation 2005 evaluates to “false,” an operation 2006 is executed that transmits that transaction information page 111 to the sender of funds 101 to be viewed using the Internet-utilizing application 112. In example cases where a decisional operation 2005 evaluates to “true,” a further operation 2008 is executed that retrieves cookie data from the Internet-utilizing application's cache. This cookie data may be, for example, cookie data 2007. In certain example cases, an operation 2004 may be executed that, as previously illustrated, generates valid sender transaction data signal 2015 and sender transaction data 2011. In certain example cases, through the execution of the operation 2006, a further operation 2010 may be executed that receives the filled-in transaction information page 111 from the sender of funds 101. This filled-in transaction information page 111 may be a manually filled-in page 2009. Once this manually filled-in page 2009 is received, then the previously illustrated operation 2004 may be executed.
In some example embodiments, operations 2004, 2006, and 2007 when executed, may utilize HTTPS, SSL, SSH, and other suitable protocols to obscure the data inputted into the transaction information page 111, provided via the valid sender transaction data signal 2015, and sender transaction data 2011. The HTTPS, SSL, SSH, and other suitable protocols may be used in conjunction with a TCP/IP such that a session may be established between, for example, the one or more devices 102 and the payment processor server 109.
Some example embodiments may include the various databases being relational databases, or in some example cases On-Line Analytical Processing (OLAP) based databases. In the case of relational databases, various tables of data are created and data is inserted into, and/or selected from, these tables using a Structured Query Language (SQL) or some other database-query language known in the art. In the case of OLAP databases, one or more multi-dimensional cubes or hypercubes containing multidimensional data from which data is selected from or inserted into using a Multi-Dimensional Expression (MDX) language may be implemented. In the case of a database using tables and SQL, a database application such as, for example, MYSQL™, SQLSERVER™, Oracle 81™, 10G™, or some other suitable database application may be used to manage the data. In this, the case of a database using cubes and MDX, a database using Multidimensional Online Analytic Processing (MOLAP), Relational Online Analytic Processing (ROLAP), Hybrid Online Analytic Processing (HOLAP), or some other suitable database application may be used to manage the data. These tables or cubes made up of tables, in the case of, for example, ROLAP, are organized into a RDS or Object Relational Data Schema (ORDS), as is known in the art. These schemas may be normalized using certain normalization algorithms to avoid abnormalities such as non-additive joins and other problems. Additionally, these normalization algorithms may include Boyce-Codd Normal Form or some other normalization, optimization algorithm known in the art.
Some example embodiments may include a table 2507 that may be used to contain linked account data. This linked account data may relate to a particular financial institution account or other type of account that serves as the basis for supplying funds to a recipient of funds from a particular sender of funds. This linked account data may be, for example, a string, integer, or some other suitable data type. A table 2508 is also shown that contains an account ID. This account ID may serve to uniquely identify a particular sender of funds, recipient of funds, or other party that holds an account with the payment processor server 109. This account ID may be, for example, a string, integer, or other suitable data type. A table 2509 is also shown that contains various hashing algorithms. These hashing algorithms may be, for example, the previously illustrated SHA-1 algorithm, the MD5 algorithm, or some other suitable hashing algorithm. These hashing algorithms may be stored as, for example, a Binary Large Object (BLOB) or some other suitable data type. A table 2510 is shown that may contain a symmetric key. This symmetric key may be used in the symmetric encrypting or decrypting of particular sender data. A BLOB, integer, or some other suitable data type may be used to store this symmetric key information. A table 2511 is shown that contains asymmetric key information, where this asymmetric key information may be, for example, a private key or a public key. In certain cases, some type of unique identifier identifying the party or individual associated with the private key or public key may be stored within this table 2511. An integer, BLOB, or some other suitable data type may be used to store the symmetric key information into the table 2511. In some example embodiments, a table 2512 containing unique identifier information may be implemented. This unique identifier information may be used to uniquely distinguish a sender of funds or a recipient of funds or some other party holding an account with the payment processor server 109. Further, this unique identifier information, contained in the table 2512, may be used to uniquely identify any one of a number of the data entries stored the tables 2501 through 2511. This unique identifier may be, for example, an integer, float, or some other suitable data type.
A Three-Tier ArchitectureIn some example embodiments, a method is illustrated as implemented in a distributed or non-distributed software application designed under a three-tier architecture paradigm, whereby the various components of computer code that implement this method may be categorized as belonging to one or more of these three tiers. Some example embodiments may include a first tier as an interface (e.g., an interface tier) that is relatively free of application processing. Further, a second tier may be a logic tier that performs application processing in the form of logical/mathematical manipulations of data inputted through the interface level, and communicates the results of these logical/mathematical manipulations to the interface tier, and/or to a backend or storage tier. These logical/mathematical manipulations may relate to certain business rules or processes that govern the software application as a whole. A third storage tier may be a persistent storage medium or non-persistent storage medium. In some example cases, one or more of these tiers may be collapsed into another, resulting in a two-tier architecture or even a one-tier architecture. For example, the interface and logic tiers may be consolidated, or the logic and storage tiers may be consolidated, as in the case of a software application with an embedded database. This three-tier architecture may be implemented using one technology, or, as will be discussed below, a variety of technologies. This three-tier architecture, and the technologies through which it is implemented, may be executed on two or more computer systems organized in a server-client, peer-to-peer, or so some other suitable configuration. Further, these three tiers may be distributed between more than one computer system as various software components.
Component DesignSome example embodiments may include the above illustrated tiers, and the processes or operations that make them up, as being written as one or more software components. Common to many of these components is the ability to generate, use, and manipulate data. These components, and the functionality associated with each, may be used by client, server, or peer computer systems. These various components may be implemented by a computer system on an as-needed basis. These components may be written in an object-oriented computer language such that a component oriented, or object-oriented programming technique can be implemented using a Visual Component Library (VCL), Component Library for Cross Platform (CLX), Java Beans (JB), Java Enterprise Beans (EJB), Component Object Model (COM), Distributed Component Object Model (DCOM), or other suitable technique. These components may be linked to other components via various Application Programming interfaces (APIs), and then compiled into one complete server, client, and/or peer software application. Further, these APIs may be able to communicate through various distributed programming protocols as distributed computing components.
Distributed Computing Components and ProtocolsSome example embodiments may include remote procedure calls being used to implement one or more of the above illustrated components across a distributed programming environment as distributed computing components. For example, an interface component (e.g., an interface tier) may reside on a first computer system that is remotely located from a second computer system containing a logic component (e.g., a logic tier). These first and second computer systems may be configured in a server-client, peer-to-peer, or some other suitable configuration. These various components may be written using the above illustrated object-oriented programming techniques, and can be written in the same programming language or a different programming language. Various protocols may be implemented to enable these various components to communicate regardless of the programming language used to write these components. For example, a component written in C++ may be able to communicate with another component written in the Java programming language using a distributed computing protocol such as a Common Object Request Broker Architecture (CORBA), a Simple Object Access Protocol (SOAP), or some other suitable protocol. Some example embodiments may include the use of one or more of these protocols with the various protocols outlined in the OSI model, or TCP/IP protocol stack model for defining the protocols used by a network to transmit data.
A System of Transmission Between a Server and ClientSome example embodiments may use the OSI basic reference model or TCP/IP protocol stack model for defining the protocols used by a network to transmit data. In applying these models, a system of data transmission between a server and client, or between peer computer systems is illustrated as a series of roughly five layers comprising: an application layer, a transport layer, a network layer, a data link layer, and a physical layer. In the case of software having a three tier architecture, the various tiers (e.g., the interface, logic, and storage tiers) reside on the application layer of the TCP/IP protocol stack. In an example implementation using the TCP/IP protocol stack model, data from an application residing at the application layer is loaded into the data load field of a TCP segment residing at the transport layer. This TCP segment also contains port information for a recipient software application residing remotely. This TCP segment is loaded into the data load field of an IP datagram residing at the network layer. Next, this IP datagram is loaded into a frame residing at the data link layer. This frame is then encoded at the physical layer and the data transmitted over a network such as the Internet, Local Area Network (LAN), Wide Area Network (WAN), or some other suitable network. In some example cases, Internet refers to a network of networks. These networks may use a variety of protocols for the exchange of data, including the aforementioned TCP/IP, and additionally ATM, SNA, SDI, or some other suitable protocol. These networks may be organized within a variety of topologies (e.g., a star topology) or structures.
A Computer SystemThe example computer system 2600 includes a processor 2602 (e.g., a Central Processing Unit (CPU), a Graphics Processing Unit (GPU) or both), a main memory 2601 and a static memory 2606, which communicate with each other via a bus 2608. The computer system 2600 may further include a video display unit 2610 (e.g., a Liquid Crystal Display (LCD) or a Cathode Ray Tube (CRT)). The computer system 2600 also includes an alphanumeric input device 2617 (e.g., a keyboard), a User Interface (UI) cursor controller 2611 (e.g., a mouse), a disc drive unit 2616, a signal generation device 2656 (e.g., a speaker) and a network interface device (e.g., a transmitter) 2623.
The disc drive unit 2616 includes a machine-readable medium 2657 on which is stored one or more sets of instructions and data structures (e.g., software) embodying or utilized by any one or more of the methodologies or functions illustrated herein. The software may also reside, completely or at least partially, within the main memory 2601 and/or within the processor 2602 during execution thereof by the computer system 2600, the main memory 2601 and the processor 2602 also constituting machine-readable media.
The instructions 2621 may further be transmitted or received over a network 2626 via the network interface device 2623 using any one of a number of well-known transfer protocols (e.g., Hyper Text Transfer Protocol (HTTP), Session Initiation Protocol (SIP)).
In some example embodiments, a removable physical storage medium is shown to be a single medium, and the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the machine and that cause the machine to perform any of the one or more of the methodologies illustrated herein. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic medium, and carrier wave signals.
Marketplace ApplicationsIn some example embodiments, a system and method is shown that allows an individual to select a recipient e-mail address for the purpose of sending money to the recipient. In some respects e-mail addresses have supplanted physical addresses as a location to receive mail. Where physical payment instruments (e.g., checks) in the past may have been sent to a physical address for satisfaction of a debt, various payment processors now allow for e-mail addresses to serve as the basis to receive payments. Through using the system and method illustrated herein, e-mail addresses can be selected to receive monetary payments.
The Abstract of the Disclosure is provided to comply with 37 C.F.R. § 1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
Claims
1. A computer implemented method comprising:
- receiving an email address selection displayed as part of a screen widget, the screen widget included within the display of an interface associated with an Internet-utilizing application;
- executing a plug in having a send money function, the plug in associated with the Internet-utilizing application, the send money function executed due, in part, to a signal received from an input device; and
- generating a payment request identifying a recipient of funds by the e-mail address selection.
2. The computer implemented method of claim 1, further comprising generating transaction information relating to a sender of funds, wherein the transaction information includes at least one of an amount of currency, a currency type, a payment purpose description, a linked account identifier, and a payment message.
3. The computer implemented method of claim 2, wherein the transaction information is stored in a cookie.
4. The computer implemented method of claim 1, further comprising obscuring the payment request using at least one of a symmetric encryption algorithm, an asymmetric encryption algorithm, or a hashing algorithm.
5. A computer implemented method comprising:
- receiving an e-mail address displayed in an interface associated with an Internet-utilizing application using an input device;
- executing a plug-in engine, associated with the Internet-utilizing application, with a send money function; and
- generating, with the send money function, a payment request identifying a recipient of funds with the e-mail address.
6. The computer implemented method of claim 5, wherein the input device is a mouse.
7. The computer implemented method of claim 5, wherein the Internet-utilizing application includes at least one of a Web browser or e-mail client.
8. The computer implemented method of claim 5, further comprising selecting the send money function using a right-click function associated with a mouse.
9. The computer implemented method of claim 5, further comprising obscuring the payment request using an algorithm including at least one of a symmetric encryption algorithm, an asymmetric encryption algorithm, or a hashing algorithm.
10. The computer implemented method of claim 5, further comprising requesting a transaction information page that includes at least one of an amount of currency, a currency type, a payment purpose description, a linked account identifier, or a payment message.
11. A computer system comprising:
- a receiver to receive a payment request identifying a recipient of funds by an e-mail address, the payment request generated through the use of a screen widget, associated with an Internet-utilizing application, that contains a recipient identifier;
- a first determiner engine to determine whether the recipient of funds has an account and a sender of funds has an account;
- a second determiner engine to determine whether funds exist in the sender of funds account to cover a payment request amount; and
- a transfer engine to transfer funds to a recipient of funds account, where the sender of funds has funds to transfer that cover the payment request amount.
12. The computer system of claim 11, wherein the account is a payment processor account.
13. The computer system of claim 11, wherein transferring funds occurs where valid sender transaction data, valid available funds data, and a valid recipient signal are provided.
14. The computer system of claim 11, further comprising a transaction request engine to request transaction information from the sender of funds, wherein the requested transaction information includes at least one of an amount of currency, a currency type, a payment purpose description, a linked account identifier, or a payment message.
15. The computer system of claim 14, wherein the transaction information is stored in a cookie.
16. The computer system of claim 11, further comprising a de-obscuring engine to de-obscure the payment request using at least one of a symmetric encryption algorithm, an asymmetric encryption algorithm, or a hashing algorithm.
17. A computer system comprising:
- a selector to allow a selection of an e-mail address, displayed within a screen widget, included within the display of an interface associated with an Internet-utilizing application;
- a plug in to execute a send money function associated with the Internet-utilizing application, the send money function executed due, in part, to a signal from an input device; and
- a payment engine to generate a payment request identifying a recipient of funds by the e-mail address.
18. The computer system of claim 17, wherein the input device is a mouse.
19. The computer system of claim 17, wherein the Internet-utilizing application includes at least one of a Web browser or e-mail client.
20. The computer system of claim 17, wherein the selector that selects the send money function is performed using a right-click function associated with a mouse.
21. The computer system of claim 17, further comprising an obscuring engine that obscures the payment request using at least one of a symmetric encryption algorithm, an asymmetric encryption algorithm, or a hashing algorithm.
22. The computer system of claim 17, further comprising a request engine to request a transaction information page used to designate at least one of an amount of currency, a currency type, a payment purpose description, a linked account identifier, and a payment message.
23. A machine-readable medium comprising instructions, which when implemented by one or more machines cause the one or more machines to perform the following operations:
- receiving a payment request identifying a recipient of funds by an e-mail address, the payment request generated, in part, using a recipient identifier as displayed by a screen widget as part of an Internet-utilizing application;
- determining whether the recipient of funds has an account, and a sender of funds has an account;
- determining whether funds exist in the sender of funds account to cover a payment request amount; and
- transferring funds to a recipient of funds account, where the sender of funds has funds to transfer that cover the payment request amount.
Type: Application
Filed: Nov 15, 2007
Publication Date: May 21, 2009
Applicant:
Inventor: Deborah Yee-Ky Liu (Santa Clara, CA)
Application Number: 11/940,403
International Classification: G06Q 40/00 (20060101); H04L 9/32 (20060101);