WO2005081984A2 - Financial transactions with messaging and receipt charges - Google Patents
Financial transactions with messaging and receipt charges Download PDFInfo
- Publication number
- WO2005081984A2 WO2005081984A2 PCT/US2005/005791 US2005005791W WO2005081984A2 WO 2005081984 A2 WO2005081984 A2 WO 2005081984A2 US 2005005791 W US2005005791 W US 2005005791W WO 2005081984 A2 WO2005081984 A2 WO 2005081984A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- summa
- account
- message
- sender
- funds
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
- G07F17/16—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for devices exhibiting advertisements, announcements, pictures or the like
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/108—Remote banking, e.g. home banking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/14—Payment architectures specially adapted for billing systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/28—Pre-payment schemes, e.g. "pay before"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/403—Solvency checks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
- G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/12—Accounting
Definitions
- This invention relates generally to electronic messaging and, more particularly, to secure electronic messaging which assures the security of financial transactions and avoids the current difficulties experienced by users of electronic messaging for performing financial transactions.
- U.S. Patent No. 6,246,996 to Stein discloses a mechanism for a seller to bill a buyer through an intermediary's email system. The bill is forwarded to the buyer through an intermediary service's email system and when the buyer responds with authorization to pay the bill, the intermediary can process the transaction without conveying any account information to the seller.
- U.S. Patent No. 6,332,134 to Foster avoids disclosure of credit card information to merchants by providing for the customer to initiate an electronic message to the financial institution authorizing payment to a merchant identified in the message to the financial institution.
- the present invention achieves these ends by (a) integrating a secure messaging system into a electronically controlled financial account for each user that allows both the sending and receipt of funds as part of an email to another party using a similar email enabled financial account, (b) allowing a user to specify a schedule of receipt charges required to receive email from specific individuals, groups of individuals, or classes of businesses, and (c) collecting marketing information about the user's purchases made using this financial account, with the user's permission, so that it may be sold to marketers and thereby increase the income that the user will receive from receipt charges. None of these three features, individually or in combination, is presently known.
- Digital Identification refers to a legally binding electronic signature, a digital signature (DS), or an electronic confirmation of identity that may be in the form of an asynchronously encrypted, verifiable certificate of authority (CA) issued by a trusted third party, such as a bank or post office, that attests for the identity of the designated holder.
- Header refers to information associated with a Summa message (see definition below) that is not normally viewed by the receiver but is used by the servers and clients to process the message and balance the accounts.
- Network server refers to software and hardware employed by the service provider to collect and distribute information between Summa account (see definition below) clients.
- Receipt charge is the charge set by the receiver of a Summa message (see definition below) to be applied against the account of a sender and credited to the receiver as generally or specifically defined in the charge schedule.
- Receiver refers to the user of a Summa account (see definition below) who receives a Summa message (see definition below).
- Sender refers to the user who sends a Summa message (see definition below).
- Service provider refers to an entity that provides Summa accounts (see definition below) to a plurality of users through at least one Summa network server. Typically, the service provider may be a bank or other financial institution, an internet service provider, or another business offering or managing credits accessible to users through a Summa account (see definition below).
- Summa account refers to an electronically managed financial account that includes an integrated electronic messaging system or, conversely, an electronic messaging system that is integrated into the electronic management of one or more financial accounts.
- a Summa account may be composed of an electronic messaging system that includes the programming and authorizations necessary to credit or debit to one or more financial accounts.
- Summa client refers to the software resident on a user's machine for composing, sending, receiving, and reading a Summa message (see definition below) and accessing the associated financial account(s) and account records.
- Summa message refers to an electronic message containing information regarding a transfer of funds between Summa accounts and which may also include additional information, messages or attachments from the sender to the receiver.
- the Summa message may include electronic text, images, audio, video, or telephonic communications.
- User refers to any person or business entity with a Summa account on the network. A user may be either the receiver or sender of a Summa message. It was in light of the foregoing that the present invention was conceived and has now been reduced to practice.
- each Summa user prior to making a financial transfer, each Summa user must have established a financial account with his Summa service provider. This account must include either or both deposits of funds or a line of credit.
- the Summa client by which the user accesses and manages one or more Summa accounts, the user defines a schedule of receipt charges that senders must pay to the receiver as compensation for accepting delivery of their Summa messages.
- the sender's Summa account is debited the agreed upon charge(s) and the sender's account is credited the charge, minus any service fees that may be imposed by the service provider.
- this invention In addition to providing a technique for receivers to establish and collect message receipt charges, this invention also provides a secure manner of transferring other funds between any two Summa accounts. This facilitates internet purchases, micropayments, electronic invoicing and bill payment, and any other transfer of funds that user may require. Since this payment involves a transfer of funds directly between Summa accounts, there is no need to transmit credit card numbers or account numbers over the internet.
- the service providers can also track the types of purchases made and add this to the marketing database kept on each user. Collecting and making this data available increases the value of each user's market identity and thereby increases the income that users will be able to receive from receipt charges.
- a primary feature, then, of the present invention is the provision of a user-friendly financial transaction system using the Internet that will enjoy the confidence of its users.
- Another feature of the present invention is the provision of such a transaction system which offers a user greater control over the time he spends reviewing both expected and unexpected communications, greater value from information shared about his market identity, and greater convenience and security in the completion of financial transactions.
- Still another feature of the present invention is the provision of a transaction system which connects a secure messaging system to an electronically controlled financial account for each user that allows both the sending and receipt of funds as part of an email to another party using a similar Summa account, allows a user to specify a schedule of receipt charges required to receive email from specific individuals, groups of individuals, or classes of businesses, and collects marketing information about the user's purchases made using this financial account, with the user's permission, so that it may be sold to marketers and thereby increase the income that the user will receive from receipt charges.
- the present invention docs not use an email attachment of value but instead vaults beyond the promise to pay and Sunstcd ' s unaddressed task of collecting funds by providing a mechanism for initiating and completing an actual transaction or deposit of funds from one financial account to another. This occurs, and is integral to the definition of delivering a Summa message (that is. a financial transaction plus a message).
- Sundstcd docs not make any provision for using the promissory notes or tokens for any other purpose than its one time use as attached electronic postage, hi fact, he teaches that is necessary to prevent the reuse of it any token or electronic.
- Council fails to discover the advantage of creating a financial account into which funds can be deposited from the billed receipt charges and withdrawn to make purchases, pay bills, or pay other person's receipt charges. Council also fails to discover the advantages that arise from allowing users to create a schedule of different receipt charges according to specific sender or broader commercial classes. Instead, Council requires users to maintain a list of authorized senders and seeks to bill senders who are not on that list. In contrast, the present invention simplifies the relationship between all users in that any person with a Summa account, even those unknown to user, are automatically pre-authorized to send messages and does not require any billing process to collect payment of delivery charges.
- Council does not provide a mechanism for users to have accounts with different service providers, but would require the bills to all be paid to a single company that provides this service. Another concern is that Council requires the receiving user's computer to be programmed to detect an indication of the source of electronic mail and the ability to compare the source with a list of authorized senders. However, as described, the system of Council cannot prevent false headers. It has no means of determining if the indication of origin is genuine. By contrast, the system of the invention does not require the receiving person's computer to detect of the source of the email since the Summa network itself is designed to authenticate the identity of users. BRIEF DESCRIPTION OF THE DRAWINGS
- FIG. 1 is a block diagram showing the relationship between Summa users, network servers, and the databases associated with each user's Summa account, all according to the invention
- FIG. 2 is a spreadsheet that illustrates an example of the type of information maintained in the database associated with a user account according to the invention
- Fig. 3 illustrates a simple flow chart of a software subroutine used by the user, according to the invention, to set the schedule of charges to be demanded of those who wish to send messages to the user
- Fig. 4 illustrates a flow chart which is exemplary of a software subroutine used by the network server, according to the invention, to resolve handling a Summa message sent from one user serviced by one server to another user serviced by another server; and
- FIG. 5 is a block diagram similar to Fig 1 but with the financial accounts residing outside the Summa network database, according to the invention, illustrating how the ability to complete a funds transfer may be provided with authorization and access to electronically order transfers of funds to and from a user's financial account held an external financial institution.
- FIG. 1 illustrates the unique technique of the invention as it is achieved and controlled by the use of a computer network wherein network servers 32 and 38 exchange Summa messages through an electronic connection 36.
- network servers 32 and 38 exchange Summa messages through an electronic connection 36.
- FIG. 1 illustrates the unique technique of the invention as it is achieved and controlled by the use of a computer network wherein network servers 32 and 38 exchange Summa messages through an electronic connection 36.
- Summa client 25 which has settings to send and retrieve Summa messages for three account addresses, one for User 24, user24@snl, one for user 26, user26@snl, and one that is shared by both user 24 and user 26, joint@snl .
- users communicate with their assigned network server, 32 or 38.
- Summa client 21 is shown as connected to network server 32 via an internet connection 28. If user 20 sends a message addressed to user 22, network server 32 will store the message received from Summa client 21 in memory until it is retrieved by user 22's Summa client, 23.
- the exchange of messages between users that are serviced by different servers is only slightly more complex.
- the Summa network servers also maintain financial accounts and databases 34 and 40 for each user which include a schedule of charges to be charged against the accounts of senders and credited to each user on delivery and the means to debit or credit the financial accounts upon delivery of the Summa message.
- a general example of the charge schedule and consumer profile for user 20 is entered and stored in database 34, as shown in FIG. 2.
- each column represents a separate category of information.
- each column, 80 through 88 represents a discrete file. Other arrangements of the data will be obvious to those skilled in the art. As shown in FIG.
- each file is a label for the type of information stored in that file and the second row is a unique identifier for user 20, shown simply as "User20 ID" in this example, which is used to identify, link, and access the appropriate data for user 20 across the several files.
- a general information data file 80 is the memory location in which running totals of user 20's credits, debits, and service charges are maintained, along with other standard information such as passwords and the default receipt charge.
- a personal contacts list file 82 is a list of users known to user 20 for whom user 20 wishes to establish a receipt charge that is different from the default receipt charge. Any address identified as having a receipt charge equal to zero is tagged for the pass through list.
- a consumer profile list file 84 contains data regarding the consumer profile for user 20, for example, likes and dislikes, product preference, recent purchases, and demographic information.
- a commercial fee list file 86 contains the charge schedule defined by user 20 that should be applied against various types of commercial accounts.
- a "refused list" file 88 is a list of user addresses that user 20 wants to have automatically returned or discarded regardless of the maximum receipt charge they are willing to pay. At the time of establishing a new Summa account, or at such other times as the service provider or customer may wish to modify his account settings, the owner of the Summa address completes or amends an electronic form that establishes the basic charge schedule.
- FIG. 3 is a flow chart demonstrating the basic steps of a software subroutine by which a user would supply the information stored in the database illustrated in FIG. 2.
- the ordering of these steps is not crucial. Persons skilled in the art of computer programming will readily derive many variations on this procedure.
- the basic steps of this subroutine would set the user's default receipt charge, allow entry of specific charges to be applied against specific categories of commercial messages, and input of any additional information that may contribute to a consumer profile.
- the identification of persons who should have a receipt charge different than the default receipt charge and addresses that should be refused are additional modifications of the basic requirements. Specific addresses on these lists may be entered individually or uploaded in the form of the address book files commonly used by email programs.
- FIG. 4 is a basic flow chart that outlines major steps of a server subroutine that examines an incoming Summa message to a receiver and either (1) applies the appropriate charge to the sender's account, provides the credit to the receiver and delivers the Summa message to the receiver, or (2) returns the message to the sender with an appropriate message identifying the reason for refusal. The latter may occur if the sender is on the receiver's list of senders whose messages should always be refused, or if the sender does not have a Summa account or lacks sufficient funds in his account.
- a message will also be returned if the receiver receipt charge exceeds the maximum amount the sender has listed in the message as the amount he will agree to pay toward a receipt charge. For example, if the user has set a charge often cents for receipt of messages from financial newsletters but the sender of such a commercial message has sent the message out with a notice that he will only pay receipt charges up to seven cents per receiver, the sender will receive a notice back stating that the message was not delivered and identifying the appropriate charge that the sender must agree to pay before the message can be delivered. In this manner, senders of commercial broadcast messages can accurately control their costs and also determine what portion of a Summa list they are missing if they have set their maximum charge too low.
- the secure delivery of the message might require a request to send (RTS) from the sender's server and a permission to send (PTS) from the receiver's server. This step would provide for verification of charges and identities prior to transmission of the Summa message.
- RTS request to send
- PTS permission to send
- the RTS might also include a hash sum of the message that will be sent following receipt of the PTS.
- the receiver's server would allow the receiver's server to verify that the message received matched the one for which a PTS was granted. Once a PTS was received, the sender's server would place the funds being transferred into a temporary escrow account against the event that the message is not successfully delivered. Once the confirmation of delivery was received from the receiver's server, the escrowed funds would be credited to the receiving party.
- the transfer of funds is only finalized after the successful delivery of the message has been confirmed. Alternatively, in other circumstances it may be desirable to hold the message until the final transfer of funds has been confirmed. Which alternative is employed may be determined by the type of message or by the selected options of users.
- this process could be automated through one or more central clearinghouse servers 50 that would monitor, calculate, and process the periodic transfers required to put the net balances of each Summa service provider in proper order.
- the central clearinghouse 50 would also maintain the list of all network server addresses for all the Summa service providers and each transaction would begin with a query to the clearinghouse to find or confirm the address of the receiver's service provider.
- receiving servers could verify the integrity of sending servers through the clearinghouse. In this way, any attempt to initiate a Summa message and transaction through an unauthorized server is automatically thwarted.
- the messaging system is integrated with the electronic funds transfer and accounting system of a financial institution.
- the Summa transaction is completed using an external electronic component 42 for ordering a transfer of funds.
- an external electronic component 42 for ordering a transfer of funds.
- user 20 can provide his user ID and password to his Summa client 21 which can then be used by the user's server 32 to access and transfer funds through the intemet banking interface 42 for the selected bank account.
- a record of these transfers would still be kept in the Summa account database 34.
- the Summa messaging system is not actually integrated into the bank's financial accounting systems, sufficient access and control the financial account can be granted to the Summa system to complete the fund transfers required to serve the purposes of this invention.
- the user could sign an agreement allowing the provider of the Summa messaging service authorization to make automated clearing house (ACH) transfers to any of the user's existing accounts.
- the means of transferring funds 42 represents any means of electronic funds transfer, including but not limited to the ACH system, a credit card processing system, individually or in combination with a clearinghouse 50, through which the Summa network servers may coordinate the transfer of funds between financial accounts.
- the user's selected account routing number would be provided through the user's Summa client. Since ACH transactions are typically processed using batch files, it may not be necessary or advisable to create an ACH transfer order for each discrete Summa message.
- the network server would accumulate a daily transfer tally in the database 42 representing the sum of credits and debits to each Summa account. Rather than issue 23 ACH transactions for user 22, the network server would order one ACH transaction, a credit of $5.31, at the end of the day. This process not only reduces ACH transaction fees, it also reduces the number of financial transactions that need to be represented in a banking statement.
- this system is further simplified by directing all end of day Summa account credits into a central financial account owned by the service provider and directing all end of day Summa account debits out of the same central financial account.
- the user's bank statement would show only a single ACH transaction for each day representing the net Summa account credits or debits for that day.
- the details of each transaction could be accessed through the Summa account database, which in the case of the example above would show the detail of User 20 's ten outgoing Summa payments and thirteen incoming Summa payments.
- the service provider could wait to balance each user's account only when the net credit or debit exceeded a minimum amount, for example $20, which would be sufficient to justify the expense of an ACH transfer fee.
- a similar process may be used when accessing a line of credit, using for example, a credit card number.
- the shift in net balances may occur between the accounts of a single service provider who owns financial account in multiple financial institutions, 44 and 46, shown in Fig 5. To minimize transactions between 44 and 46, users might be required to have their own financial accounts controlled by their Summa account, at least the one that will receive and pay small amounts, at 44 or 46.
- User 22 may have selected bank 44 and User 30 bank 46, and both have Summa accounts managed by one service provider operating network servers 32 and 38. With the appropriate permissions from the Summa users, and by way of service provider's accounts at each bank, payments between 22 and 30 may be completed without any transfer of funds between banks. Instead, the funds paid out by 22 go into the service provider's account at 44 and out of the service provider's account at 46 into 30's account. In this way, at reduced cost, two in-bank transfers replace one between banks transfer. In this case, the net deposits in each bank remain unaffected, but the service providers' accounts at each bank are affected. This is easily managed by periodic ACH transfers between the service provider's own accounts at 44 and 46 which may be required only infrequently.
- This process may again be coordinated by a Summa clearinghouse, 50, which is implicitly included in electronic funds transfer means 42.
- users may be required to authorize the service provider to consolidate debits and credits in escrow accounts.
- the escrow accounts exist in the form of files stored on the network servers or clearinghouse servers 50.
- the network server can use the running-escrow account to verify sufficiency of funds available and to prevent an overdraft.
- the escrow may consist of two parts: pending transactions and completed transactions. Pending transactions involve those funds that are committed to be paid upon delivery of a Summa message that is in the delivery queue but has not yet been delivered—perhaps because the receiver has not yet downloaded his Summa messages.
- the network server can provide a Summa user with a real time balance of available funds.
- end of day batch files may be used to settle the net deposits held by financial institutions or service providers.
- the end of day batch settlement would include the cumulative confirmed debits and confirmed credits held in the escrow accounts. Any pending transactions would remain in the escrow account until delivery, cancellation, or refusal of the Summa message.
- Another important feature of the present invention is that, with the permission of users, the service providers can also track the types of purchases made and add this to the marketing database kept on each user. Additional marketing information may be collected by providing users opportunities to complete surveys.
- Demographic, purchasing, and survey data may be retained on the network server or communicated to a central clearinghouse or centralized data center that stores cumulative marketing data 50. Collecting and making this data available increases the value of each user's market identity and thereby increases the income that users will be able to receive from receipt charges.
- Traditionally for example, after a consumer has bought a product he will frequently receive additional product offers from the seller. In addition, his contact information and market profile may also be sold to other marketers, to the financial benefit of the seller, not the consumer.
- Summa purchases will also mark a consumer as a "hot prospect," the financial benefit of the enhanced market identity associated with being a buyer flows to the consumer who will receive his required receipt charge for any additional marketing offers delivered via a Summa message.
- the service provider could act as a broker for sale of marketing information and credit each Summa user with a payment each time a marketer purchased data, including mail addresses or telephone numbers, associated with the consumer.
- the essence of this invention is found in the linking of financial accounts through network servers wherein the financial accounts are controlled through a secure electronic messaging service that allows users to transfer funds and establish receipt charges.
- the maximum charge for example, is ten cents and the receiver's delivery charge for receipt of messages in that commercial category is five cents, only five cents would be charged against the sender's account and credited to the receiver.
- the receiver's receipt charge was twenty cents, the message would not be delivered and the sender would be notified of the higher charge for delivery.
- the header included an identification of the commercial category under which the sender's Summa message should be classified.
- a header element might identify the amount that will be charged to the receiver if he decides to respond to the message that he has just received.
- the receiver might be notified that he will not be charged anything if he responds to the sender with an inquiry for more information.
- the sender can set the charge for responding to an amount equal to the purchase price of the product offered to the receiver. In this way, the exchange of two Summa messages (the offer and the acceptance in response) can be use to complete a financial transaction.
- the response charge may be different than the normal receipt charge and may revert to the normal receipt charge after a specified period of time.
- the header could include an additional field identifying a full credit transfer amount that should be fully transferred to the receiver's Summa account. If so designated, this full credit transfer amount may be transferred even if the receiver's receipt charge is less than the designated full credit transfer amount. In this manner, the sender may transfer funds to any user of a Summa account in order to pay a bill, purchase a product, give a refund, send a monetary gift, or any other purpose for which funds are transferred.
- the header may include information identifying types of messages that should be displayed or processed in specific ways. In this example, message tagged as an invoice document type might be structured in such a way that the invoiced item numbers, description, quantity, per piece charge, and total charges can be automatically captured by the receivers accounting software.
- XML and XHTML are formatting languages that might be easily adapted for this purpose.
- the Summa client would recognize the invoice header and present the message to the user as an invoice with the options to either (1) pay the charge in full by authorizing a full credit transfer amount equal to the invoiced amount, or (2) pay a partial amount toward the invoice, or (3) respond with a message disputing the invoice.
- the response message could automatically include the invoice number and other information in a standard format that could automatically interpreted by the sender's accounting software to make proper adjustments to the account.
- a header for a contract document type might display with a "sign and send" button offering the receiver would digitally sign the document with a digital identification and return the signed document to the sender.
- each user's database FIG. 2
- additional features may also be employed in each user's database, FIG. 2, to provide further control over how many commercial messages, how much receipt income is desired, and to "pull" commercial messages when they are most needed.
- users could identify the maximum number of Summa messages they wish to receive from any particular commercial classification over the course of a week or a month. If for example, the user receives dozens of lawn fertilizer offers a week, and is indeed interested in these but simply overwhelmed by them, he might enter into a field of his charge schedule a limit on receipt of such message to no more than six per week.
- the network server could be instructed to put all such Summa messages into a queue every week and to deliver at the end of the week only those six who offered to pay the highest receipt charges.
- a user may set the minimum amount he desires to earn each week from receipt charges. If the desired amount is not met during the last hour, the network server would be instructed to accept the highest bidders who have authorized less than the receipt charge normally required by the user but have also chosen to leave their messages in a holding queue until such time as the receiver might be willing to accept them at their proffered rate.
- commercial advertisers may pre-authorize the delivery of messages to any Summa user who will subsequently match their selection criteria. For example, a marketer of cookbooks may preauthorize sending an ad immediately, or at a preset interval, perhaps one day, after a user has made a purchase of cooking supplies.
- Preauthorized Summa messages would also facilitate the ability of users to pull marketing information when they need it. For example, while users are not always interested in home mortgage rates, sometimes they are very interested in finding the best mortgage rate. Normally, to discourage receipt of mortgage information they might set a high receipt charge. When they want to get information from competitive companies, however, they could lower their receipt charge to a more reasonable level.
- the Summa client could provide a special document type that represents an "announcement of interest" (Al) or "bid request” that signifies a desire to receive information, bids, or quotes on the subject matter identified. In one alternative, this Al might be broadcast to all commercial Summa users who request delivery of AI's in their category of interest.
- the Al may be processed by a central server that matches the Al request to pre-authorized messages that commercial Summa users have prepared to respond to any matching Al request.
- the consumer and commercial user may set maximum delivery charges or receipt charges as best they deem.
- service providers might also apply additional charges.
- this invention also facilitates the use of multi-layered marketing efforts. For example, a company selling saunas might be willing to pay only five cents per potential customer in a "qualifying" mailing to a million people. The message would explain what the company was offering and promise an additional credit of $5 if the receiver, after reading this initial message was interested enough to "click here" and examine more of the company's materials.
- the user's Summa client Upon activating the "click here" link, the user's Summa client would automatically generate a request for more information to be sent to the sender. The sender would then respond with a second Summa message containing additional information, including perhaps a video clip attachment, and the promised full credit transfer amount of $5.
- the customer might be directed to click through to a special advertising page at the company's internet site which would display the sales pitch and afterwards provide the user with a form to fill out, including his Summa account information to which a Summa message providing the $5 credit would be sent.
- Ninth, another variation is to allow users to set receipt charges to a negative number. This signals a reverse payment, namely the receiver's authorization to pay the sender for each Summa message received.
- the transfer of messages between Summa clients and the Summa network servers, and between Summa network servers may include encryption, compression, requests to send, permissions to send, challenge and response, message hashes, certificates of authority, identity verification, and other techniques well known to computer security specialists. These techniques would be used individually or in combination to ensure that the identified sender did actually authorize the sending of funds and to ensure confidential delivery of the funds and message to the intended receiver. While the specialized Summa client would be required to generate Summa messages in accord to this secure protocol, the Summa client can also include programming to handle create, download, and read POP3/SMTP email.
- This backward compatible functionality allows Summa users to continue to receive POP3 email from persons on their pass through list who do not have Summa accounts and also to send SMTP messages to these same persons from their Summa client.
- the marketing data collected in the Summa Account Databases 34 and 40 is a valuable commodity for data mining, segregation, and selects that will identify subsets of Summa users that marketers would most wish to send their commercial offers.
- this marketing data can be made available either through each individual Summa network server or it can be collected into a centralized database from which marketers may extract data. The methods of compiling, searching, and distributing data from such a database are well known to those skilled in the art and require no additional elaboration here.
- HTML provides a mechanism to launch an email client to send a message to a predetermined address
- special web page programming can be devised for a hyperlink to launch a Summa message transferring a predetermined credit to a predetermined user.
- the buyer and seller would simply both need Summa accounts.
- Programming for a Summa hyperlink would launch a Summa message authorizing the payment to the seller, most probably including in the message information to the seller identifying the item being purchased.
- the buyer would confirm the purchase, most probably with a password, and the Summa transaction would be completed. If a shipping address were required, this could automatically be provided from the buyer's database.
- This method provides an easier means of completing Internet purchases without the need for filling out contact information and revealing a credit card numbers.
- a similar method could be employed for a micropayment system. For example, in order to gain access to web pages containing information of value, a special hyperlink displaying the cost of following the hyperlink would, when activated, simultaneously take user to the desired page and authorize a Summa payment of the few cents, or even fractions of cents, required. In this example, the user would probably set a maximum amount, say 5 cents, that he was willing to have paid without the need of a confirming the purchase with a password. In this way Summa account users could easily have access to web sites requiring micropayments for browsing of their content.
- a Dl may be provided by the sender with a contract bid, or with a filing and payment of taxes.
- the sender would simply choose the option of attaching the Dl to the Summa message and the receiver would be able to ses if any message had a Dl or not.
- senders might require a Dl from receivers prior to delivery of the Summa message. This is analogous to sending a registered mail or a legal notice wherein the receiver must sign for delivery or even produce a government or corporate ID.
- the sender of a Summa message may be provided with the option to condition delivery upon provision of a general or specific Dl.
- the task of supplying the Dl may be automated or semi-automatic.
- the receiver would electronically deposit one or more digital identifications in his Summa client or his network server so they would be ready to be used at any time.
- the sender may require either a digital signature and/or a confirmation of identity in the form of a specific CA prior to delivery the Summa message.
- the message would be put into a hold queue and the network server would send a request for the required Dl to the receiver's network server. If the receiver configured his end to automatically fill all Dl requests, the receiver's network server would automatically send the Dl to sender's network server.
- the sender or the sender's network server would use the issuing party's public key to confirm the authenticity of the CA. Upon confirming the identity of the receiver, the queued Summa message would then be released for delivery under the usual conditions.
- the Dl would only be provided when the receiver authorized delivery in each instance by manually confirming permission to provide the Dl by clicking on an appropriate button or icon. In this case, the receiver would not receive the original Summa message itself at this time, but only a notice of the request for the Dl, which might include the name of the requestor.
- the notice of the request for Dl prior to delivery of the queued message would be treated as a special document type that, upon display, would include buttons that allow for easy approval of the request.
- This request could also be treated as a separate Summa message for which the appropriate receipt charge would apply.
- a new type of credit or debit card issued by the service provider may be used as a token, or smart card, to authenticate a Summa transaction at a dedicated transaction terminal at the checkout lane of a retail establishment.
- the token might contain an encrypted CA that would be verified by the terminal, which may also provide for entry of a user's password.
- the terminal Upon confirmation of the sale by the user, the terminal would generate a Summa message that would pay for the purchase and upload a list of the user's purchases to the network server.
- the checkout terminal acts is simply a dedicated Summa client accessible to any user who identifies himself to the terminal with an appropriate encrypted token and password.
- Similar tokens may also be used as an additional security precaution whenever a user wants to access his Summa account from a networked device that the Summa network would recognize as not being one of his "normal" access points.
- This invention opens the way for a number of new methods and models for doing business.
- intemet service providers may be able to waive subscription fees for user in return for a service fee levied against their user's receipt charges or fund transfers.
- Tech support centers can use a Summa account to collect an advance payment for a request for help. Companies may set receipt charges for the Summa accounts of their employees, and thereby collect on the value of outsiders contacting their employees. This income would help to offset the cost of providing communication tools to employees and creates added value from their employees.
- Summa accounts can easily be programmed to satisfy many standard business practices. For example, Summa accounts can be multiplexed, that is several financial accounts can be linked to a single user's address.
- the user might use a single Summa client to retrieve all of his messages but when sending a Summa message the user would be allowed to choose from which of the multiple financial accounts available funds should be drawn to pay the receipt charge or other payment.
- the user addresses for multiple users, such as a husband and wife, could be linked to a joint financial account.
- the system can also be easily modified to require two or more users to authorize a payment. For example, an electronic Summa invoice might be sent to a company's accountant. Upon verifying the invoice, the accountant may then authorize the payment, but the message would not be sent directly to the receiver but would instead be automatically routed to "co-signer" for the account, the business owner.
- Summa message including the payment, would only be sent after the business owner confirmed it for delivery. Because all the Summa account records are in an electronic format, it is also obvious that this accounting information can be easily read or imported into accounting software. Alternatively, accounting software can be incorporated into the Summa client. Upon review of what is taught in this invention, it will be readily apparent to anyone skilled in the programming and accounting arts that any standard for handling multiple accounts, multiple signers, tracking of expenses and payments, collection of customer histories, et cetera, can be accomplished or mimicked through minor variations in the programming governing general or special purpose Summa accounts.
- the techniques disclosed by this invention produce the following advantages: they increase the value of a user's identity and time and provide the user with greater control over the type and quantity of electronic messages received; they correct the inherent weakness in the prior art which provided no practical means of regulating the quantity and quality of email messages received and no practical way of generating income for the user; • they reduce the impulse of users to keep their email addresses secret for fear of being inundated with unwanted email messages thereby promoting a ore public posting of addresses that will facilitate appropriate communication;
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Computer Security & Cryptography (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Entrepreneurship & Innovation (AREA)
- Game Theory and Decision Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Claims
Priority Applications (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
RU2006130680/09A RU2380754C2 (en) | 2004-02-26 | 2005-02-24 | Financial transactions with payment for message transmission and reception |
JP2007500953A JP5130039B2 (en) | 2004-02-26 | 2005-02-24 | Financial transactions with sending and receiving charges |
CA002557130A CA2557130A1 (en) | 2004-02-26 | 2005-02-24 | Financial transactions with messaging and receipt charges |
EP05723603A EP1721292A4 (en) | 2004-02-26 | 2005-02-24 | Financial transactions with messaging and receipt charges |
BRPI0507228-0A BRPI0507228A (en) | 2004-02-26 | 2005-02-24 | method of conducting financial transactions between summa accounts and system for conducting financial transactions between summa account users |
AU2005216212A AU2005216212A1 (en) | 2004-02-26 | 2005-02-24 | Financial transactions with messaging and receipt charges |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US54746204P | 2004-02-26 | 2004-02-26 | |
US60/547,462 | 2004-02-26 | ||
US11/063,076 | 2005-02-22 | ||
US11/063,076 US7873572B2 (en) | 2004-02-26 | 2005-02-22 | Financial transaction system with integrated electronic messaging, control of marketing data, and user defined charges for receiving messages |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2005081984A2 true WO2005081984A2 (en) | 2005-09-09 |
WO2005081984A3 WO2005081984A3 (en) | 2007-01-18 |
Family
ID=34889941
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2005/005791 WO2005081984A2 (en) | 2004-02-26 | 2005-02-24 | Financial transactions with messaging and receipt charges |
Country Status (9)
Country | Link |
---|---|
US (2) | US7873572B2 (en) |
EP (1) | EP1721292A4 (en) |
JP (2) | JP5130039B2 (en) |
CN (1) | CN102708483A (en) |
AU (1) | AU2005216212A1 (en) |
BR (1) | BRPI0507228A (en) |
CA (1) | CA2557130A1 (en) |
RU (1) | RU2380754C2 (en) |
WO (1) | WO2005081984A2 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008234648A (en) * | 2007-03-16 | 2008-10-02 | Shacom Com Inc | Financial loan method of voluntary interest rate and its system constituted in network and executed on financial loan platform by online |
EA016432B1 (en) * | 2010-04-16 | 2012-04-30 | "Газпромбанк" (Открытое Акционерное Общество) | Processing center and method of fund transfer in banking payment system |
Families Citing this family (99)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7376583B1 (en) | 1999-08-10 | 2008-05-20 | Gofigure, L.L.C. | Device for making a transaction via a communications link |
US6957259B1 (en) | 2001-06-25 | 2005-10-18 | Bellsouth Intellectual Property Corporation | System and method for regulating emails by maintaining, updating and comparing the profile information for the email source to the target email statistics |
US20050198174A1 (en) * | 2003-12-30 | 2005-09-08 | Loder Theodore C. | Economic solution to the spam problem |
US8346660B2 (en) * | 2004-02-26 | 2013-01-01 | David C. Reardon | System and method for two-way transfer of funds and electronic content between summa account users with gathering of behavioral metrics and management of multiple currencies and escrow accounts |
US7873572B2 (en) * | 2004-02-26 | 2011-01-18 | Reardon David C | Financial transaction system with integrated electronic messaging, control of marketing data, and user defined charges for receiving messages |
US8799164B2 (en) * | 2004-02-26 | 2014-08-05 | David C Reardon | Financial transaction system with integrated electronic messaging, control of marketing data, and user defined charges for receiving messages |
US20090119159A1 (en) * | 2007-10-31 | 2009-05-07 | David C. Reardon | System and Method for Transferring Funds to Recipients of Electronic Messages |
US8175938B2 (en) * | 2004-04-13 | 2012-05-08 | Ebay Inc. | Method and system for facilitating merchant-initiated online payments |
US8682784B2 (en) * | 2004-07-16 | 2014-03-25 | Ebay, Inc. | Method and system to process credit card payment transactions initiated by a merchant |
US11893089B1 (en) | 2004-07-27 | 2024-02-06 | Auctane, Inc. | Systems and methods for protecting content when using a general purpose user interface application |
US9728107B1 (en) | 2008-04-15 | 2017-08-08 | Stamps.Com Inc. | Systems and methods for protecting content when using a general purpose user interface application |
US20070038754A1 (en) * | 2005-08-12 | 2007-02-15 | Enrique Nunez | Open-innovation network |
US7925786B2 (en) * | 2005-09-16 | 2011-04-12 | Microsoft Corp. | Hosting of network-based services |
US8244812B2 (en) * | 2005-09-16 | 2012-08-14 | Microsoft Corporation | Outsourcing of email hosting services |
US7987251B2 (en) * | 2005-09-16 | 2011-07-26 | Microsoft Corporation | Validation of domain name control |
US8234340B2 (en) * | 2005-09-16 | 2012-07-31 | Microsoft Corporation | Outsourcing of instant messaging hosting services |
US8874477B2 (en) | 2005-10-04 | 2014-10-28 | Steven Mark Hoffberg | Multifactorial optimization system and method |
US8662384B2 (en) * | 2006-02-28 | 2014-03-04 | Google Inc. | Text message payment |
US10068220B2 (en) | 2006-10-11 | 2018-09-04 | Visa International Service Association | Systems and methods for brokered authentication express seller links |
CA2666262A1 (en) * | 2006-10-11 | 2008-04-17 | Visa International Service Association | Method and system for processing micropayment transactions |
US8671114B2 (en) * | 2006-11-30 | 2014-03-11 | Red Hat, Inc. | Search results weighted by real-time sharing activity |
US8612361B1 (en) | 2006-12-27 | 2013-12-17 | Stamps.Com Inc. | System and method for handling payment errors with respect to delivery services |
US8775331B1 (en) | 2006-12-27 | 2014-07-08 | Stamps.Com Inc | Postage metering with accumulated postage |
US20080281692A1 (en) * | 2007-05-10 | 2008-11-13 | Microsoft Corporation | Virtual Points Clearinghouse |
US9183305B2 (en) * | 2007-06-19 | 2015-11-10 | Red Hat, Inc. | Delegated search of content in accounts linked to social overlay system |
US8620803B1 (en) | 2007-07-26 | 2013-12-31 | United Services Automobile Association (Usaa) | Systems and methods for customized electronic funds distribution |
US8429045B1 (en) | 2007-07-31 | 2013-04-23 | United Services Automobile Association (Usaa) | System and method to provide an email account |
US8954367B2 (en) | 2007-08-23 | 2015-02-10 | Dside Technologies, Llc | System, method and computer program product for interfacing software engines |
US10657503B1 (en) | 2007-09-19 | 2020-05-19 | Capital One Services, Llc | System and method of providing a customer with method of making a payment to a third party using a remote dispensing machine |
US10373398B1 (en) | 2008-02-13 | 2019-08-06 | Stamps.Com Inc. | Systems and methods for distributed activation of postage |
US9978185B1 (en) | 2008-04-15 | 2018-05-22 | Stamps.Com Inc. | Systems and methods for activation of postage indicia at point of sale |
US9208620B1 (en) | 2008-04-15 | 2015-12-08 | Stamps.Com, Inc. | Systems and methods for payment of postage indicia after the point of generation |
US8799149B2 (en) * | 2008-04-16 | 2014-08-05 | Visa U.S.A. Inc. | Loyalty rewards optimization bill payables and receivables service |
US8187972B2 (en) * | 2008-07-01 | 2012-05-29 | Teledyne Scientific & Imaging, Llc | Through-substrate vias with polymer fill and method of fabricating same |
US20100042536A1 (en) * | 2008-08-15 | 2010-02-18 | Tim Thorson | System and method of transferring funds |
US9911246B1 (en) | 2008-12-24 | 2018-03-06 | Stamps.Com Inc. | Systems and methods utilizing gravity feed for postage metering |
US9235831B2 (en) | 2009-04-22 | 2016-01-12 | Gofigure Payments, Llc | Mobile payment systems and methods |
US20100293017A1 (en) * | 2009-05-18 | 2010-11-18 | Contenture, Inc. | Micropayment and website content control systems and methods |
US8965809B1 (en) * | 2009-05-21 | 2015-02-24 | Stamps.Com Inc. | Restricted printing of postage with layout constraints in a browser |
US20110191247A1 (en) * | 2010-01-29 | 2011-08-04 | Ben Dominguez | Authentication framework extension to verify identification information |
JP2013522753A (en) * | 2010-03-18 | 2013-06-13 | トランウォール・ホールディングス・リミテッド | Mobile communication device |
WO2011130251A1 (en) * | 2010-04-12 | 2011-10-20 | Visa International Service Association | Apparatuses, methods and systems for using a personalized data repository |
US20110270761A1 (en) * | 2010-04-30 | 2011-11-03 | Tobsc Inc. | Methods and apparatus for a financial document clearinghouse and secure delivery network |
US20120047014A1 (en) * | 2010-08-23 | 2012-02-23 | Yahoo! Inc. | Method and system for using email receipts for targeted advertising |
US10713634B1 (en) | 2011-05-18 | 2020-07-14 | Stamps.Com Inc. | Systems and methods using mobile communication handsets for providing postage |
US8543475B2 (en) * | 2011-06-27 | 2013-09-24 | Capital Confirmation, Inc. | System and method for obtaining automated third-party confirmations in receivables factoring |
US20130066674A1 (en) * | 2011-09-12 | 2013-03-14 | Microsoft Corporation | Marketplace for timely event data distribution |
US10846650B1 (en) | 2011-11-01 | 2020-11-24 | Stamps.Com Inc. | Perpetual value bearing shipping labels |
US9805329B1 (en) | 2012-01-24 | 2017-10-31 | Stamps.Com Inc. | Reusable shipping product |
US10922641B1 (en) | 2012-01-24 | 2021-02-16 | Stamps.Com Inc. | Systems and methods providing known shipper information for shipping indicia |
US8874671B2 (en) | 2012-02-10 | 2014-10-28 | Blackberry Limited | Electronic message metering and traffic management in a networked environment |
US20130232061A1 (en) * | 2012-03-01 | 2013-09-05 | Carmel - Haifa University Economic Corporation Ltd | Reducing unsolicited traffic in communication networks |
US8660866B1 (en) * | 2012-06-08 | 2014-02-25 | Atlas Financial Partners LLC | Methods and systems for administering life insurance products through classifying insured lives to allocate costs |
US9285981B1 (en) | 2012-07-16 | 2016-03-15 | Wickr Inc. | Discouraging screen capture |
US10198516B2 (en) * | 2012-08-02 | 2019-02-05 | Rule 14 | Real-time and adaptive data mining |
US10114899B2 (en) * | 2012-08-02 | 2018-10-30 | Rule 14 | Real-time and adaptive data mining |
US10108725B2 (en) * | 2012-08-02 | 2018-10-23 | Rule 14 | Real-time and adaptive data mining |
US20150262311A1 (en) * | 2012-10-12 | 2015-09-17 | Iou Concepts Inc. | System and method for network based account data management and data exchange |
US20140108233A1 (en) * | 2012-10-12 | 2014-04-17 | Mastercard International Inc. | Social payment method and apparatus |
US10074082B2 (en) | 2012-11-30 | 2018-09-11 | Walmart Apollo, Llc | Splitting a purchase among multiple parties using an electronic receipt after the transaction |
US10108951B2 (en) | 2012-11-30 | 2018-10-23 | Walmart Apollo, Llc | Splitting a purchase among multiple parties using an electronic receipt after the transaction |
US8732079B1 (en) * | 2012-12-10 | 2014-05-20 | Bank Of America Corporation | Cloud-based data augmentation |
US11861696B1 (en) | 2013-02-14 | 2024-01-02 | Capital Confirmation, Inc. | Systems and methods for obtaining accountant prepared financial statement confirmation |
US9402178B2 (en) * | 2013-02-21 | 2016-07-26 | Kamfu Wong | Paid instant message system and method for authenticating identities using a mobile telephone network |
US10607209B2 (en) * | 2013-03-15 | 2020-03-31 | TGALLISON Technologies, LLC | System and method for transferring payments and documents with a web-based management system |
US20140279229A1 (en) * | 2013-03-15 | 2014-09-18 | Auto Trader Corporation | Systems and methods for facilitating vehicle transactions |
US10102575B1 (en) * | 2013-06-24 | 2018-10-16 | Dividex Analytics, LLC | Securities claims identification, optimization and recovery system and methods |
US10652763B2 (en) * | 2013-06-25 | 2020-05-12 | Telintel Ltd. | Cellular phone message delivery testing system and method |
US10129260B1 (en) * | 2013-06-25 | 2018-11-13 | Wickr Inc. | Mutual privacy management |
US20140378071A1 (en) * | 2013-06-25 | 2014-12-25 | Mario Acosta | Cellular phone message delivery testing system and method |
US20150019320A1 (en) * | 2013-07-12 | 2015-01-15 | Qualcomm Incorporated | System and method for determining a default account in a mobile wallet while providing an incentive to establish a default account in the mobile wallet |
US9721225B1 (en) | 2013-10-16 | 2017-08-01 | Stamps.Com Inc. | Systems and methods facilitating shipping services rate resale |
JP6353537B2 (en) * | 2013-12-02 | 2018-07-04 | マスターカード インターナショナル インコーポレーテッド | Method and system for performing secure authentication of users and mobile devices without using a secure element |
US20150178696A1 (en) * | 2013-12-23 | 2015-06-25 | Cube, Co. | System and method for performing callbacks in an automated clearing house network |
US20170109822A1 (en) * | 2014-03-21 | 2017-04-20 | ITG Software Solutions, Inc | Network communication system for exchange trading |
US10417728B1 (en) | 2014-04-17 | 2019-09-17 | Stamps.Com Inc. | Single secure environment session generating multiple indicia |
US9584530B1 (en) | 2014-06-27 | 2017-02-28 | Wickr Inc. | In-band identity verification and man-in-the-middle defense |
US9342831B1 (en) | 2014-12-16 | 2016-05-17 | Facebook, Inc. | Facilitating same day payment transactions |
US9830603B2 (en) | 2015-03-20 | 2017-11-28 | Microsoft Technology Licensing, Llc | Digital identity and authorization for machines with replaceable parts |
US10607215B2 (en) * | 2015-09-30 | 2020-03-31 | Bank Of America Corporation | Account tokenization for virtual currency resources |
US10453059B2 (en) | 2015-09-30 | 2019-10-22 | Bank Of America Corporation | Non-intrusive geo-location determination associated with transaction authorization |
US9590956B1 (en) | 2015-12-18 | 2017-03-07 | Wickr Inc. | Decentralized authoritative messaging |
US10521754B2 (en) | 2016-03-08 | 2019-12-31 | Auctane, LLC | Concatenated shipping documentation processing spawning intelligent generation subprocesses |
US20170300896A1 (en) * | 2016-04-13 | 2017-10-19 | Paypal, Inc. | Omni-channel data processing using hierarchical vault data structures |
US9590958B1 (en) | 2016-04-14 | 2017-03-07 | Wickr Inc. | Secure file transfer |
US9596079B1 (en) | 2016-04-14 | 2017-03-14 | Wickr Inc. | Secure telecommunications |
EP3297242B1 (en) * | 2016-09-20 | 2018-09-05 | Deutsche Telekom AG | A system and a method for providing a user with an access to different services of service providers |
WO2018177503A1 (en) * | 2017-03-27 | 2018-10-04 | Swiss Reinsurance Company Ltd. | Adaptive, self-optimizing, leveraged capacity system and corresponding method thereof |
CN110809778A (en) * | 2018-03-30 | 2020-02-18 | 加藤宽之 | Stock price prediction support system and method |
TWI702540B (en) * | 2019-03-22 | 2020-08-21 | 鼎新電腦股份有限公司 | Load control method |
CN110443615B (en) * | 2019-08-13 | 2021-10-22 | 中国联合网络通信集团有限公司 | Block chain-based account management method and system |
KR102252859B1 (en) * | 2020-05-04 | 2021-05-14 | 윤성민 | Foreign currency exchange system and method thereof |
US11900457B2 (en) * | 2020-08-24 | 2024-02-13 | Leonid Chuzhoy | Methods for prediction and rating aggregation |
WO2022101866A1 (en) * | 2020-11-15 | 2022-05-19 | Financial & Risk Organisation Limited | User-defined matching |
US20220318906A1 (en) * | 2021-04-05 | 2022-10-06 | Pranil Ram | Interactive Grid-based Graphical Trading System with Smart Order Action |
CN113256116A (en) * | 2021-05-26 | 2021-08-13 | 陈新燊 | Transaction price reference index calculation method realized through computer |
US11930014B2 (en) | 2021-09-29 | 2024-03-12 | Bank Of America Corporation | Information security using multi-factor authorization |
US20230121239A1 (en) * | 2021-10-15 | 2023-04-20 | Tomer Karni | Systems and methods for dynamically determining the best respected moving average lines associated with a time series data set |
US20230412552A1 (en) * | 2022-06-16 | 2023-12-21 | Krier, Godfrey & Grassbaugh, Inc. | Messaging protocol to faciliate demand-based messaging |
Family Cites Families (88)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5870724A (en) * | 1989-12-08 | 1999-02-09 | Online Resources & Communications Corporation | Targeting advertising in a home retail banking delivery service |
US5220501A (en) | 1989-12-08 | 1993-06-15 | Online Resources, Ltd. | Method and system for remote delivery of retail banking services |
CA2059078C (en) | 1991-02-27 | 1995-10-03 | Alexander G. Fraser | Mediation of transactions by a communications system |
US5327486A (en) | 1993-03-22 | 1994-07-05 | Bell Communications Research, Inc. | Method and system for managing telecommunications such as telephone calls |
US5465206B1 (en) * | 1993-11-01 | 1998-04-21 | Visa Int Service Ass | Electronic bill pay system |
US5473671A (en) | 1994-03-11 | 1995-12-05 | At&T Corp. | Selective screening of incoming calls for cellular telephone systems |
US5826241A (en) * | 1994-09-16 | 1998-10-20 | First Virtual Holdings Incorporated | Computerized system for making payments and authenticating transactions over the internet |
US5740231A (en) | 1994-09-16 | 1998-04-14 | Octel Communications Corporation | Network-based multimedia communications and directory system and method of operation |
US5742905A (en) | 1994-09-19 | 1998-04-21 | Bell Communications Research, Inc. | Personal communications internetworking |
US5758257A (en) | 1994-11-29 | 1998-05-26 | Herz; Frederick | System and method for scheduling broadcast of and access to video programs and other data using customer profiles |
US5625680A (en) | 1995-02-07 | 1997-04-29 | At&T | Method and apparatus for prioritizing telephone calls |
US5708422A (en) * | 1995-05-31 | 1998-01-13 | At&T | Transaction authorization and alert system |
US5828737A (en) | 1995-10-24 | 1998-10-27 | Telefonaktiebolaget L M Ericsson | Communications service billing based on bandwidth use |
US6453327B1 (en) | 1996-06-10 | 2002-09-17 | Sun Microsystems, Inc. | Method and apparatus for identifying and discarding junk electronic mail |
US6005870A (en) | 1996-08-12 | 1999-12-21 | At&T Corp. | Method for called party control of telecommunications network services |
US6029150A (en) | 1996-10-04 | 2000-02-22 | Certco, Llc | Payment and transactions in electronic commerce system |
US5790790A (en) | 1996-10-24 | 1998-08-04 | Tumbleweed Software Corporation | Electronic document delivery system in which notification of said electronic document is sent to a recipient thereof |
CA2275574C (en) | 1996-12-20 | 2003-07-29 | Financial Services Technology Consortium | Method and system for processing electronic documents |
US7236969B1 (en) | 1999-07-08 | 2007-06-26 | Nortel Networks Limited | Associative search engine |
US6732154B1 (en) | 1997-03-18 | 2004-05-04 | Paratran Corporation | Distribution limiter for network messaging |
US5987606A (en) | 1997-03-19 | 1999-11-16 | Bascom Global Internet Services, Inc. | Method and system for content filtering information retrieved from an internet computer network |
US6061718A (en) | 1997-07-23 | 2000-05-09 | Ericsson Inc. | Electronic mail delivery system in wired or wireless communications system |
US5999967A (en) | 1997-08-17 | 1999-12-07 | Sundsted; Todd | Electronic mail filtering by electronic stamp |
US6199102B1 (en) | 1997-08-26 | 2001-03-06 | Christopher Alan Cobb | Method and system for filtering electronic messages |
US6233584B1 (en) | 1997-09-09 | 2001-05-15 | International Business Machines Corporation | Technique for providing a universal query for multiple different databases |
US5960411A (en) | 1997-09-12 | 1999-09-28 | Amazon.Com, Inc. | Method and system for placing a purchase order via a communications network |
US6393568B1 (en) | 1997-10-23 | 2002-05-21 | Entrust Technologies Limited | Encryption and decryption system and method with content analysis provision |
US6393465B2 (en) | 1997-11-25 | 2002-05-21 | Nixmail Corporation | Junk electronic mail detector and eliminator |
JP3087710B2 (en) | 1997-11-29 | 2000-09-11 | ブラザー工業株式会社 | Facsimile machine |
AU1907899A (en) | 1997-12-22 | 1999-07-12 | Accepted Marketing, Inc. | E-mail filter and method thereof |
US6023723A (en) | 1997-12-22 | 2000-02-08 | Accepted Marketing, Inc. | Method and system for filtering unwanted junk e-mail utilizing a plurality of filtering mechanisms |
US6047272A (en) | 1998-01-05 | 2000-04-04 | At&T Corp. | Sender-paid electronic messaging |
US6073167A (en) | 1998-03-18 | 2000-06-06 | Paratran Corporation | Distribution limiter for network messaging |
WO1999064964A1 (en) | 1998-06-08 | 1999-12-16 | Kaufman Consulting Services Ltd. | Method and system for retrieving relevant documents from a database |
US6253201B1 (en) | 1998-06-23 | 2001-06-26 | Philips Electronics North America Corporation | Scalable solution for image retrieval |
US6161130A (en) | 1998-06-23 | 2000-12-12 | Microsoft Corporation | Technique which utilizes a probabilistic classifier to detect "junk" e-mail by automatically updating a training and re-training the classifier based on the updated training set |
US6493007B1 (en) | 1998-07-15 | 2002-12-10 | Stephen Y. Pang | Method and device for removing junk e-mail messages |
US6112227A (en) | 1998-08-06 | 2000-08-29 | Heiner; Jeffrey Nelson | Filter-in method for reducing junk e-mail |
US6192114B1 (en) | 1998-09-02 | 2001-02-20 | Cbt Flint Partners | Method and apparatus for billing a fee to a party initiating an electronic mail communication when the party is not on an authorization list associated with the party to whom the communication is directed |
US6587550B2 (en) | 1998-09-02 | 2003-07-01 | Michael O. Council | Method and apparatus for enabling a fee to be charged to a party initiating an electronic mail communication when the party is not on an authorization list associated with the party to whom the communication is directed |
GB2343529B (en) | 1998-11-07 | 2003-06-11 | Ibm | Filtering incoming e-mail |
US6330550B1 (en) | 1998-12-30 | 2001-12-11 | Nortel Networks Limited | Cross-media notifications for e-commerce |
US6654787B1 (en) | 1998-12-31 | 2003-11-25 | Brightmail, Incorporated | Method and apparatus for filtering e-mail |
US6732149B1 (en) | 1999-04-09 | 2004-05-04 | International Business Machines Corporation | System and method for hindering undesired transmission or receipt of electronic messages |
AU4501600A (en) | 1999-04-30 | 2000-11-17 | X.Com Corporation | System and method for electronically exchanging value among distributed users |
US6393464B1 (en) | 1999-05-10 | 2002-05-21 | Unbound Communications, Inc. | Method for controlling the delivery of electronic mail messages |
US6253198B1 (en) | 1999-05-11 | 2001-06-26 | Search Mechanics, Inc. | Process for maintaining ongoing registration for pages on a given search engine |
EP1232431A4 (en) | 1999-09-01 | 2005-06-08 | Peter L Katsikas | System for eliminating unauthorized electronic mail |
US7853989B2 (en) | 2000-02-08 | 2010-12-14 | Katsikas Peter L | System for eliminating unauthorized electronic mail |
US6332134B1 (en) | 1999-11-01 | 2001-12-18 | Chuck Foster | Financial transaction system |
US7376587B1 (en) * | 2000-07-11 | 2008-05-20 | Western Union Financial Services, Inc. | Method for enabling transfer of funds through a computer network |
US7395241B1 (en) | 2000-01-19 | 2008-07-01 | Intuit Inc. | Consumer-directed financial transfers using automated clearinghouse networks |
US6438584B1 (en) | 2000-03-07 | 2002-08-20 | Letter Services, Inc. | Automatic generation of graphically-composed correspondence via a text email-interface |
KR20000036475A (en) * | 2000-03-16 | 2000-07-05 | 조도원 | E-mail service system |
JP3790676B2 (en) * | 2000-03-31 | 2006-06-28 | 富士通株式会社 | Value-added attached e-mail transmission device and value-added attached e-mail transmission / reception system |
US7269160B1 (en) | 2000-05-26 | 2007-09-11 | Buffalo International, Inc. | Voice over internet call center integration |
DK1356438T3 (en) | 2000-07-10 | 2014-09-22 | Paypal Inc | System and method for verifying a financial instrument |
JP2002041408A (en) * | 2000-07-21 | 2002-02-08 | Nikkei Business Publications Inc | Electronic mail system for direct advertisement |
JP2002099820A (en) * | 2000-09-25 | 2002-04-05 | Casio Comput Co Ltd | Method for advertisement, and method for advertisement service |
WO2002039356A1 (en) * | 2000-11-01 | 2002-05-16 | Mark Landesmann | System and method for granting deposit-contingent e-mailing rights |
CA2437726A1 (en) | 2001-02-15 | 2002-08-22 | Suffix Mail Inc. | E-mail messaging system |
US7249094B2 (en) | 2001-02-26 | 2007-07-24 | Paypal, Inc. | System and method for depicting on-line transactions |
US20020120582A1 (en) * | 2001-02-26 | 2002-08-29 | Stephen Elston | Method for establishing an electronic commerce account |
FR2825555B1 (en) | 2001-05-30 | 2004-03-12 | Nilcom | SHORT MESSAGE SYSTEM, ESPECIALLY PREPAID MESSAGES |
US20030009698A1 (en) | 2001-05-30 | 2003-01-09 | Cascadezone, Inc. | Spam avenger |
US20030023736A1 (en) | 2001-07-12 | 2003-01-30 | Kurt Abkemeier | Method and system for filtering messages |
US7191151B1 (en) | 2001-08-23 | 2007-03-13 | Paypal, Inc. | Instant availability of electronically transferred funds |
JP2003087440A (en) * | 2001-09-14 | 2003-03-20 | Nippon Shoko Kk | Advertisement mail communication method and advertisement mail communication system |
US20030080185A1 (en) * | 2001-10-26 | 2003-05-01 | Werther Ellen R. | Money transfer method and system |
US6697462B2 (en) | 2001-11-07 | 2004-02-24 | Vanguish, Inc. | System and method for discouraging communications considered undesirable by recipients |
JP2003157215A (en) * | 2001-11-20 | 2003-05-30 | Hitachi Ltd | System for controlling electronic mail reception |
KR101194730B1 (en) | 2002-02-14 | 2012-10-25 | 자차리 페신 | Apparatus and method of a distributed capital system |
JP2003256318A (en) * | 2002-02-27 | 2003-09-12 | Nec Corp | System, method, and program for distributing advertisement |
US7257530B2 (en) | 2002-02-27 | 2007-08-14 | Hongfeng Yin | Method and system of knowledge based search engine using text mining |
US20030220779A1 (en) | 2002-03-29 | 2003-11-27 | Ping Chen | Extracting semiconductor device model parameters |
US7257246B1 (en) * | 2002-05-07 | 2007-08-14 | Certegy Check Transaction Service, Inc. | Check cashing systems and methods |
JP2004013655A (en) * | 2002-06-10 | 2004-01-15 | Sony Ericsson Mobilecommunications Japan Inc | Electronic mail system, transmitting server, receiving server, and communication terminal device |
US7249060B2 (en) | 2002-08-12 | 2007-07-24 | Paybyclick Corporation | Systems and methods for distributing on-line content |
US20060041505A1 (en) * | 2002-10-11 | 2006-02-23 | 900Email Inc. | Fee-based message delivery system |
WO2005038623A2 (en) * | 2003-10-17 | 2005-04-28 | Nexxo Financial Corporation | Systems and methods for money sharing |
US20050177505A1 (en) * | 2003-11-24 | 2005-08-11 | Keeling John E. | System and method for registering a user with an electronic bill payment system |
US7873572B2 (en) | 2004-02-26 | 2011-01-18 | Reardon David C | Financial transaction system with integrated electronic messaging, control of marketing data, and user defined charges for receiving messages |
US20050192078A1 (en) | 2004-02-27 | 2005-09-01 | Sridhar Jawaharlal | SMS-based mobile lottery games |
US7472822B2 (en) | 2005-03-23 | 2009-01-06 | E2Interactive, Inc. | Delivery of value identifiers using short message service (SMS) |
US7533047B2 (en) | 2005-05-03 | 2009-05-12 | International Business Machines Corporation | Method and system for securing card payment transactions using a mobile communication device |
US8662384B2 (en) | 2006-02-28 | 2014-03-04 | Google Inc. | Text message payment |
US7415409B2 (en) | 2006-12-01 | 2008-08-19 | Coveo Solutions Inc. | Method to train the language model of a speech recognition system to convert and index voicemails on a search engine |
US7415460B1 (en) | 2007-12-10 | 2008-08-19 | International Business Machines Corporation | System and method to customize search engine results by picking documents |
-
2005
- 2005-02-22 US US11/063,076 patent/US7873572B2/en not_active Expired - Fee Related
- 2005-02-24 RU RU2006130680/09A patent/RU2380754C2/en not_active IP Right Cessation
- 2005-02-24 CN CN201210041215.9A patent/CN102708483A/en active Pending
- 2005-02-24 EP EP05723603A patent/EP1721292A4/en not_active Withdrawn
- 2005-02-24 CA CA002557130A patent/CA2557130A1/en not_active Abandoned
- 2005-02-24 BR BRPI0507228-0A patent/BRPI0507228A/en not_active IP Right Cessation
- 2005-02-24 WO PCT/US2005/005791 patent/WO2005081984A2/en active Search and Examination
- 2005-02-24 AU AU2005216212A patent/AU2005216212A1/en not_active Abandoned
- 2005-02-24 JP JP2007500953A patent/JP5130039B2/en not_active Expired - Fee Related
-
2010
- 2010-12-21 US US12/974,921 patent/US8352364B2/en active Active
-
2011
- 2011-09-16 JP JP2011202610A patent/JP2012022708A/en active Pending
Non-Patent Citations (1)
Title |
---|
See references of EP1721292A4 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008234648A (en) * | 2007-03-16 | 2008-10-02 | Shacom Com Inc | Financial loan method of voluntary interest rate and its system constituted in network and executed on financial loan platform by online |
EA016432B1 (en) * | 2010-04-16 | 2012-04-30 | "Газпромбанк" (Открытое Акционерное Общество) | Processing center and method of fund transfer in banking payment system |
Also Published As
Publication number | Publication date |
---|---|
RU2006130680A (en) | 2008-04-10 |
JP2007527064A (en) | 2007-09-20 |
EP1721292A4 (en) | 2008-03-19 |
US20110112966A1 (en) | 2011-05-12 |
RU2380754C2 (en) | 2010-01-27 |
US20050192899A1 (en) | 2005-09-01 |
JP2012022708A (en) | 2012-02-02 |
WO2005081984A3 (en) | 2007-01-18 |
CN102708483A (en) | 2012-10-03 |
JP5130039B2 (en) | 2013-01-30 |
EP1721292A2 (en) | 2006-11-15 |
US7873572B2 (en) | 2011-01-18 |
US8352364B2 (en) | 2013-01-08 |
AU2005216212A1 (en) | 2005-09-09 |
CA2557130A1 (en) | 2005-09-09 |
BRPI0507228A (en) | 2007-06-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7873572B2 (en) | Financial transaction system with integrated electronic messaging, control of marketing data, and user defined charges for receiving messages | |
US8799164B2 (en) | Financial transaction system with integrated electronic messaging, control of marketing data, and user defined charges for receiving messages | |
US20120284115A1 (en) | System and Method for Transferring Funds to Recipients of Electronic Messages | |
AU2001268692B2 (en) | Method and system for processing internet payments | |
US7249097B2 (en) | Method for ordering goods, services, and content over an internetwork using a virtual payment account | |
US8140432B2 (en) | Aggregated postal billing and payment methods and systems | |
US7487127B2 (en) | Merchant cash payment systems and methods | |
US20130297487A1 (en) | System and Method for Providing a Cash Advance | |
AU2001268692A1 (en) | Method and system for processing internet payments | |
CA2377706A1 (en) | Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account | |
US20040230524A1 (en) | Charity bundling site | |
WO1997019414A1 (en) | Computer network value payment system | |
KR20060009815A (en) | Micropayment processing method and system | |
ZA200607282B (en) | Financial transactions with messaging and receipt charges | |
AU750114B3 (en) | Commercial transaction system | |
AU752787B3 (en) | Authentication system for commercial transaction system | |
AU2002213641A1 (en) | Commercial transaction system | |
AU751645B3 (en) | Action dependent commercial transaction system | |
AU751637B3 (en) | Integrated transaction system | |
AU2005201214A1 (en) | Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2005216212 Country of ref document: AU |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2005723603 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 4771/DELNP/2006 Country of ref document: IN |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2557130 Country of ref document: CA |
|
WWE | Wipo information: entry into national phase |
Ref document number: 200580005759.8 Country of ref document: CN Ref document number: 2007500953 Country of ref document: JP |
|
ENP | Entry into the national phase |
Ref document number: 2005216212 Country of ref document: AU Date of ref document: 20050224 Kind code of ref document: A |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2006/07282 Country of ref document: ZA Ref document number: 200607282 Country of ref document: ZA |
|
WWP | Wipo information: published in national office |
Ref document number: 2005216212 Country of ref document: AU |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2006130680 Country of ref document: RU |
|
WWP | Wipo information: published in national office |
Ref document number: 2005723603 Country of ref document: EP |
|
ENP | Entry into the national phase |
Ref document number: PI0507228 Country of ref document: BR |
|
DPE1 | Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101) | ||
DPE1 | Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101) |