Small amount paying/receiving system

• US 20040143532A1
• Filed: 01/14/2004
• Published: 07/22/2004
• Est. Priority Date: 01/15/2003
• Status: Abandoned Application

• Current Assignee: Lee Fung Chi
• Original Assignee: Lee Fung Chi
• Inventors: Lee, Raymond Wei Man
• Application Number:
  US10/756,252
• Publication Number:
  US 20040143532A1
• Time in Patent Office: Days
• US Class Current: 705/35
• CPC Class Codes: G06Q 20/00 Payment architectures, schemes or protocols apparatus for performing or posting payment transactions G07F7/08, G07F19/00; electronic cash registers G07G1/12
• CPC Class Codes: G06Q 20/29 characterised by micropayments
• CPC Class Codes: G06Q 20/385 using an alias or single-use codes
• CPC Class Codes: G06Q 40/00 Finance; Insurance; Tax strategies; Processing of corporate or income taxes

Abstract

Disclosed is a small amount paying/receiving system for network trading comprises a plurality of pseudo accounts for users to use, each account including a receiving frame and a paying frame for respectively recording the data of the user'"'"'s depositing, receiving and paying; a money center providing a substantial account corresponding to the respective pseudo accounts to deposit the money for the users; and a message center connecting with the money center. When receiving the message indicating that a first user want to make a trade with a second user and pay for the trade, the message center deducts the amount of the payment from the first user'"'"'s pseudo account in no time, notifies the second user to provide commodity or service in real time, records the incoming of the payment on the second user'"'"'s pseudo account after receiving the message indicating the receipt of the trading object from the first user, and notifies the money center to transfer the money from the substantial account to the second user'"'"'s predetermined bank account after a predetermined period of time.

Claims

1. A small amount paying/receiving system for network transaction comprising:

a plurality of pseudo accounts for users to perform transactions, and for recording data of paying and receiving items;

a money center providing a substantial account corresponding to each pseudo account, for storing money deposited by the user; and

a message center subtracting an amount of money from a buying party user'"'"'s pseudo account and notifying a selling party user to provide a transaction matter, after receiving a message that the buying part user determines to perform the transaction and authorizes to system to pay an amount of money, and notifying the money center to transfer the amount of money into a predetermined bank account set by the selling party user in a predetermined manner, after receiving a message from the buying part, user that the transaction is completed for a predetermined period of time.

2. The system as claimed in claim 1, wherein the pseudo account comprises at least a payment frame and a receiving frame respectively for recording the payment and receipt items, and the system has a function to determine to open or close the payment frame and receiving frame.

3. The system as claimed in claim 2, wherein the payment and receipt frames are respectively divided into frames of various currencies.

4. The system as claimed in claim 1, wherein the pseudo account has an upper limit for deposited money.

5. The system as claimed in claim 4, wherein the user can set a bank account corresponding to the pseudo account, and when the money amount presented on the pseudo exceeds the upper limit, the money center automatically transfers the exceeding portion of the money into the bank account.

6. The system as claimed in claim 4, wherein the money center forbids any money to be deposited into the substantial account if the money amount presented on the pseudo has achieved the upper limit.

7. The system as claimed in claim 1, wherein the user deposits money into the substantial account by remitting, transferring, or credit card payment, and the amount of deposited money is registered on the pseudo account.

8. The system as claimed in claim 1, further comprising a problematic money keeper such that if any problem happens before the amount of money is transferred into the predetermined bank account set by the selling party user, the amount of money is transferred from the money center to the problematic money keeper.

9. The system as claimed in claim 8, further comprising a bad debit keeper such that when the period of time that the amount of money remains in the problematic money keeper exceeds a predetermined period, the amount of money is transferred into the bad debit keeper.

10. The system as claimed in claim 1, wherein the message center adds the amount of money into the selling party user'"'"'s pseudo account after subtracts said amount of money from the buying party user'"'"'s pseudo account.

11. The system as claimed in claim 1, further comprising an optional classification limit mechanism such that if the buying party user performs a transaction with classification limit mechanism, the buying party user must obtain the approval of the classification limit mechanism.

12. The system as claimed in claim 1, further comprising a database for recording each payment/receipt item and other information of the transaction.

13. The system as claimed in claim 12, wherein the database has a stored procedure not changeable by manual operation, and each payment/receipt item is recorded through the stored procedure.

14. A small amount paying/receiving system for network transaction comprising:

a plurality of pseudo accounts for users to perform transactions, and for recording data of paying and receiving items;

a money center providing a substantial account corresponding to each pseudo account, for storing money deposited by the user; and

a message center for a selling party user to establish a receivable event, assigning an indication code for the receivable event, the indication code being provided to a buying party user, upon receiving a message indicating that the buying party user authorizes to pay the money for the receivable event, subtracting the amount of the money from the buying party user'"'"'s pseudo account and notifying the selling party user to provide transaction matter, after receiving the buying party user'"'"'s message indicating that the transaction is completed, notifying the money center to transfer the amount of money into a predetermined bank account set by the selling party user after a predetermined period of time in a predetermined manner.

15. The system as claimed in claim 14, wherein the pseudo account comprises a use-once pseudo account, which is not changeable, for the selling party user to apply for the buying party user to pay the money.

16. The system as claimed in claim 14, wherein the pseudo account comprises at least a payment frame and a receiving frame respectively for recording the payment and receipt items, and the system has a function to determine to open or close the payment frame and receiving frame.

17. The system as claimed in claim 16, wherein the payment and receipt frames are respectively divided into frames of various currencies.

18. The system as claimed in claim 14, further comprising a problematic money keeper such that if any problem happens before the amount of money is transferred into the predetermined bank account set by the selling party user, the amount of money is transferred from the money center to the problematic money keeper.

19. The system as claimed in claim 18, further comprising a bad debit keeper such that when the period of time that the amount of money remains in the problematic money keeper exceeds a predetermined period, the amount of money is transferred into the bad debit keeper.

20. The system as claimed in claim 14, further comprises an optional classification limit mechanism such that if the buying party user performs a transaction with classification limit mechanism, the buying party user must obtain the approval of the classification limit mechanism.

21. The system as claimed in claim 14, further comprising a database for recording each payment/receipt item and other information of the transaction.

22. The system as claimed in claim 21, wherein the database has a stored procedure not changeable by manual operation, and each payment/receipt item is recorded through the stored procedure.

23. A method for paying/receiving for network transaction, said method comprising steps of:

establishing transaction information for a transaction matter;

obtaining the transaction information;

establishing a receivable event based on the transaction information;

assigning an indication code to the receivable event;

obtaining the indication code; and

paying money of the receivable event with reference to the indication code.

24. The method as claimed in claim 23, further comprising a step of applying for a use-once pseudo account, which is not changeable, for paying the money.