US20140289102A1 - Reputation integration into remittance delivery - Google Patents

Reputation integration into remittance delivery Download PDF

Info

Publication number
US20140289102A1
US20140289102A1 US14/223,796 US201414223796A US2014289102A1 US 20140289102 A1 US20140289102 A1 US 20140289102A1 US 201414223796 A US201414223796 A US 201414223796A US 2014289102 A1 US2014289102 A1 US 2014289102A1
Authority
US
United States
Prior art keywords
party
intermediary
value
transfer
fee
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US14/223,796
Inventor
Vishwanath Shastry
Kristen Ondeck
David Jesse
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PayPal Inc
Original Assignee
eBay Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by eBay Inc filed Critical eBay Inc
Priority to US14/223,796 priority Critical patent/US20140289102A1/en
Assigned to EBAY INC. reassignment EBAY INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: JESSE, DAVID, ONDECK, KRISTEN, SHASTRY, VISHWANATH
Publication of US20140289102A1 publication Critical patent/US20140289102A1/en
Assigned to PAYPAL, INC. reassignment PAYPAL, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: EBAY INC.
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0283Price estimation or determination

Definitions

  • the present application relates to a method and system for delivering a remittance from a first party to a third party through an intermediary party over networks.
  • FIG. 1 is an overview diagram illustrating a remittance delivery system having a client-server architecture configured for exchanging data over a network in accordance with an embodiment of the application;
  • FIG. 2 is a block diagram illustrating payment and remittance modules in accordance with an embodiment of the application
  • FIG. 3 is a high level entity-relationship diagram illustrating an embodiment of various tables maintained in a database
  • FIG. 4 is a chart illustrating data structure of a reputation table in accordance with an embodiment of the application.
  • FIG. 5 is a flowchart illustrating a method of determining an intermediary fee chargeable by an intermediary party, through which the remittance is transferred, in accordance with an embodiment of the application;
  • FIG. 6 is a flowchart illustrating a method of delivering a remittance from a first party to an account of a third party through an intermediary party in accordance with an embodiment of the application;
  • FIG. 7 is a flowchart illustrating a method of delivering a remittance from an account of a first party to an account of a third party through an intermediary party in accordance with another embodiment of the application.
  • FIG. 8 is a block diagram illustrating a machine in the example form of a computer system, within which a set of sequence of instructions for causing the machine to perform any one of the methodologies discussed herein may be executed.
  • Example methods and systems to deliver a remittance from a first party to a third party through an intermediary party are described.
  • numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be evident, however, to one skilled in the art that the embodiments of the invention may be practiced without these specific details.
  • remittance used in the following description denotes “a money transfer between any two patties”
  • the term “intermediary party” denotes “a franchisee designated by a first party and/or third party for a remittance”
  • the term “intermediary fee” denotes “the service charge by the intermediary party for the remittance transfer”.
  • FIG. 1 is an overview diagram illustrating a network system 100 having a client-server architecture configured tier exchanging data over a network 104 in accordance with an embodiment of the application.
  • a first party 101 may transfer a remittance to a third party 105 via an intermediary party 103 , and the intermediary party 103 may charge an intermediary fee which is determined based. on the reputation of the intermediary party 103 .
  • the intermediary fee is also determined based on the reputation and/or risk scores of the first party 101 and/or the third party 105 .
  • the network system 100 has a client-server architecture configured for exchanging data over a network.
  • the data may relate to various functions associated with the network system 100 , for example, transferring remittances online, determining reputation of an intermediary party, determining intermediary fee of the intermediary party.
  • the network architecture may vary and include another kind of architecture, for example, a peer machine in a peer-to-peer or distributed network environment.
  • a network-based marketplace (payment and remittance system) 160 provides a platform, where a first party 101 and/or a third party 105 can choose an intermediary party 103 as a franchisee to transfer remittance based on the reputation data/score as well as other factors, like the price, the location, business hours of the intermediary party 103 .
  • the network-based marketplace 160 forms a data exchange platform and provides, via a network 104 , server-side functionalities to one or more clients.
  • the one or more clients may utilize the network-based marketplace 160 to exchange data over the network 104 .
  • the data exchanged may include, but is not limited to, a fee schedule defined by the intermediary party 103 , reputation data of an intermediary party 103 (such as a total number of transactions conducted by the intermediary party 103 , a number of successful transactions conducted by the intermediary party 103 , a total value of transactions conducted by the intermediary party 103 over a predetermined amount of time, and feedback data received in connection with transactions conducted by the intermediary party 103 ), as well as reputation data and/or risk scores of a first party 101 and/or a third party 105 .
  • the network-based marketplace 160 includes an application program interface (API) server 114 and a web server 116 , which are coupled to an application server 118 , provide programmatic interface and web interface respectively to the application server 118 .
  • the application server 118 hosts payment and remittance modules 120 .
  • the application server 118 is coupled to one or more databases servers 124 that facilitate access to one or more databases 126 .
  • the API server 114 or the web server 116 may send, and receive data pertaining to the reputation of a merchant.
  • the API server 114 may send and receive data to and from an application running on another client machine, e.g., a client machine 110 or 112 .
  • the web server 116 may send and receive data to and from a webpage on a browser application, e.g., a web client 106 or 109 , operating on the client machine 110 or 112 .
  • the first party 101 may use a mobile device (e.g., a cell phone, not shown in FIG. 1 ) instead of a client machine 110 in FIG. 1 as an interface for communicating with the network-based marketplace 160 to initiate/complete the remittance transaction, as well as to update reputation data about the intermediary party 103 .
  • a mobile device e.g., a cell phone, not shown in FIG. 1
  • FIG. 2 is a block diagram illustrating payment and remittance modules in accordance with an embodiment of the application.
  • the payment and remittance modules 120 may provide a number of functions and services to users of the network-based marketplace 160 .
  • the payment and remittance modules 120 may include, but are not limited to, reputation determination module 200 , fee determination module 202 , value transfer module 204 , transfer confirmation module 206 , reputation update module 208 , feedback module 210 , dispute resolution applications 224 , fraud prevention applications 226 , and messaging applications 228 .
  • the payment network-based marketplace 160 includes a web interface 116 , a reputation determination module 200 , a fee determination module 202 , and a value transfer module 204 .
  • the web interface 116 receives a request to conduct a remittance transaction to transfer at least a portion of a first value from an account of a first party 101 to an account of a third party 105 via an intermediary party 103 .
  • the reputation determination module 200 accesses a database 126 via a database server 124 to obtain reputation data associated with the intermediary party 103 .
  • the reputation data about the intermediary party 103 is a number of transactions conducted by the intermediary party 103 . In another embodiment, the reputation data about the intermediary party 103 is a value of transactions conducted by the intermediary party 103 over a predetermined amount of time. In another embodiment, the reputation data about the intermediary party 103 is feedback data received in connection with transactions conducted by the intermediary party 103 from the first party 101 and/or the third party 105 . In another embodiment, the reputation data about the intermediary party 103 is a number of successful transactions conducted by intermediary party 103 .
  • the fee determination module 202 determines an intermediary fee chargeable by the intermediary party 103 for transferring the at least a portion of the first value to the third party 105 .
  • the reputation of an intermediary party 103 may affect the trust and preference of the users, as well as the service rate of the intermediary party 103 . For example, an intermediary party 103 having done more (e.g. 500 ) transactions successfully charges a higher (e.g. $10) withdrawal fee, while another intermediary party 103 having done less (e.g. 10) transactions successfully charges a lower (e.g. $2) withdrawal fee in order to build up its reputation.
  • the fee determination module 202 also takes a fee schedule defined by the intermediary party 103 as a factor (or input) to determine the intermediary fee chargeable by the intermediary party 103 for transferring the at least a portion of the first value to the third party 105 .
  • the fee determination module 202 also takes the reputation data and/or risk scores of the first party 103 and/or the third party 105 as a factor to determine an intermediary fee chargeable by the intermediary party 103 for transferring the at least a portion of the first value to the third party 105 .
  • the intermediary party 103 may choose to change the intermediary fee based on reputation data and/or risk scores of the first party 101 and/or the third party 105 . For example, the intermediary party 103 sees that the first party 101 has a history of routinely initiating chargebacks and/or requesting refunds on transactions, the intermediary party 103 may choose to accept the remittance transaction, but charge a higher intermediary fee to cover the risk of the remittance transaction.
  • the value transfer module 204 transfers the first value from the account of the first party 101 to the account of the intermediary party 103 .
  • the value transfer module 204 deducts the intermediary fee from the first value, and retains the intermediary fee in the account of the intermediary party 103 .
  • the value transfer module 204 credits the account of the intermediary party 103 with the intermediary fee, and debits the account of the first party 101 with the intermediary fee.
  • the network-based marketplace 160 further includes a transfer confirmation module 206 , coupled to the value transfer module 204 , to provide confirmation of the transfer of at least a portion of the first value to the third party 105 .
  • the value transfer module 204 credits the account of the intermediary party 103 with the intermediary fee responsive to receiving a confirmation from the transfer confirmation module 206 of the transfer of at least a portion of the first value to the third party 105 .
  • the transfer of at least a portion of the first value from the intermediary party 103 to the third party 105 can be a physical transfer of money.
  • the transfer confirmation module 206 receives a confirmation of the transfer of at least a portion of the first value to the third party 105 is received from the third party 105 . In another embodiment, the transfer confirmation module 206 receives confirmation of the transfer of at least a portion of the first value to the third party 105 is received from the intermediary party 103 .
  • the payment and remittance system 160 further includes a reputation update module 208 to update the reputation data associated with the intermediary party 103 based on the remittance transaction conducted.
  • the feedback module 208 may receive the feedback information from the first party 101 and/or the third party 105 .
  • the reputation update module 208 updates a count of remittance transactions conducted by the intermediary party 105 . In another embodiment, the reputation update module 208 , after determining that the remittance transaction has been successfully completed, updates a count of successful remittance transactions completed by the intermediary party 103 . In another embodiment, from a feedback module 210 , the reputation update module 208 receives feedback information regarding the remittance transaction from the first party 101 and/or the third party 105 and updates the reputation data based on the received feedback information.
  • the feedback module 210 uses the feedback provided by the first party 101 and/or the third party 105 about the intermediary party 103 to determine a new feedback value about the intermediary party 103 , and then the reputation module 208 updates the reputation value about the intermediary party 103 based on the new feedback value.
  • the one or more weighting functions may be applied among feedback indicators, such as negative, neutral, and positive, to produce a weighted value for the new feedback value, which is from either the first party 101 or the third party 105 . If the weighted value is less than zero, it would result in a negative impact on the existing feedback value, and if greater than zero, a positive impact.
  • the feedback module 210 would by default assume a neutral impact.
  • the reputation of the intermediary party 103 may suffer based on past transaction feedback. For example, the intermediary party's reputation may decline based on how many negative transactions the intermediary party has conducted.
  • the feedback module 210 may conduct a credit check to obtain feedback scores about an intermediary party 103 from a third party source, e.g. from a bank, a financial entity, or a commercial entity.
  • a third party source e.g. from a bank, a financial entity, or a commercial entity.
  • a messaging application 228 of the network-based marketplace 160 may be used to deliver messages among users of the network-based marketplace 160 .
  • the messages may be used by the payment and remittance system 160 , the first party 101 , the third party 105 , or the intermediary party 103 to communicate or exchange information.
  • the messaging application 228 may be used in conjunction with a dispute resolution application 224 to settle down disputes involved in remittance transactions among the first party 101 , the third party 105 , and the intermediary party 103 .
  • the messaging application 228 may be used in conjunction with a fraud prevention application 226 to prevent frauds, which might happen during the process of the remittance transaction.
  • FIG. 3 is a high level entity-relationship diagram illustrating one embodiment of various tables 300 that may be maintained in the database 226 shown in FIG. 1 . These tables 300 may be utilized by and support the payment and remittance modules 120 ,
  • a user table 302 may contain a record for each registered user of the network-based marketplace 160 , which may include an identifier, an address and financial instrument information pertaining to each registered user.
  • a user may operate as a first party 101 , a third party 105 , or an intermediary party 103 within the payment and remittance modules 120 .
  • a remittance history table 304 may contain a record for each remittance transaction performed via the network-based marketplace 160 during a certain period of time.
  • remittance history table 304 may contain a remittance transaction identifier, the identifier of each of the first party 101 , the third party 105 and the intermediary party 103 , dates showing when the first party 101 requests the remittance transaction and when the remittance transaction is completed, the value of the remittance transaction requested, and an attribute identifier of the remittance transaction.
  • a transaction table 310 may further contain more detailed information of each remittance transaction than the information maintained in remittance history table 304 .
  • the transaction table 310 may further contain the information about the intermediary fee charged by the intermediary party 103 .
  • an attribute table 312 may contain attribute identifier, and attributes of a transaction, e.g. indicating whether the intermediary fee is paid by the first party 101 or by the third party 105 .
  • a reputation table 306 may contain an identifier of the each intermediary party 103 , and reputation data of the each intermediary party 103 registered in of the network-based marketplace 160 .
  • a feedback table 308 may be utilized by the feedback module 210 to construct and maintain reputation information in the form of feedback values about the intermediary party 103 of the network-based marketplace 160 .
  • the feedback values about the intermediary party 103 in the feedback table 308 can be used to update the reputation values about the intermediary party 103 in the reputation table 306 .
  • FIG. 4 illustrates data structure of a reputation table 306 in accordance with an embodiment illustrated in FIG. 3 .
  • the fields or columns of the reputation table 306 shown in FIG. 4 include an identifier of the intermediary party 103 , a number of transactions conducted by the intermediary party 103 , a number of positive feedbacks from the first party 101 or the third party 105 , a number of negative feedbacks from the first party 101 or the third party 105 , and a total value successfully transferred by the intermediary party 103 .
  • FIG. 5 illustrates a method of determining an intermediary fee chargeable by an intermediary party, through which the remittance is transferred, in accordance with an embodiment of the application.
  • the application server 118 receives a request to deliver a remittance from a first party 101 to an account of a third party 105 through an intermediary party 103 .
  • the reputation determination module 200 access reputation data associated with the intermediary party 103 .
  • the reputation data associated with the intermediary party 103 is stored in database(s) 126 .
  • the reputation determination module 200 also access reputation data and/or risk scores of a first party 101 and/or a third party 105 stored in database(s) 126 or populated from other systems.
  • the reputation data associated with the intermediary party 103 includes a number of remittance transactions conducted by the intermediary party 103 . In another embodiment, the reputation data associated with the intermediary party 103 is based on a value of remittance transactions conducted by the intermediary party 103 over a predetermined amount of time. In another embodiment, the reputation data associated with the intermediary party 103 includes feedback data received in connection with remittance transactions conducted by the intermediary party 103 . In one embodiment, the feedback data is received from the first party 101 . In another embodiment, the feedback data is received from the third party 105 . In another embodiment, the reputation data associated with the intermediary party 103 includes a number of successful remittance transactions conducted by the intermediary party 103 .
  • the fee determination module 202 determines an intermediary fee chargeable by the intermediary party 103 based on the reputation data about the intermediary party 103 accessed at 504 .
  • the fee determination module 202 determines an intermediary fee chargeable by the intermediary party 103 for transferring the at least a portion of the first value to the third party 105 .
  • the fee determination module 202 also takes a fee schedule defined by the intermediary party 103 as a factor or an input to determine the intermediary fee chargeable by the intermediary party 103 for transferring the at least a portion of the first value to the third party 105 .
  • the fee determination module 202 also takes the reputation data and/or risk scores of the first party 103 and/or the third party 105 as a factor to determine an intermediary fee chargeable by the intermediary party 103 for transferring the at least a portion of the first value to the third party 105 .
  • the intermediary party 103 may choose to change the intermediary fee based on reputation data and/or risk scores of the first party 103 and/or the third party 105 .
  • the intermediary party 103 sees that the first party 101 has a history of routinely initiating chargebacks and/or requesting refunds on transactions, the intermediary party 103 may choose to accept the remittance transaction, but charge a higher intermediary fee to cover the risk of the remittance transaction.
  • FIG. 6 illustrates a method of delivering a remittance from a first party to an account of a third party through an intermediary party in accordance with an embodiment of the application.
  • the messaging application 228 receives a request to deliver a remittance from an account of a first party 101 to an account of a third party 105 through an intermediary party 103 .
  • the remittance is transferred from an account of the first party 101 to the account of the intermediary party 103 .
  • the remittance is transferred from the first party 101 in cash to the account of the intermediary party 103 .
  • the reputation determination module 200 accesses reputation data associated with the intermediary party 103 .
  • the reputation determination module 200 obtains the reputation data associated with the intermediary party 103 from a database 126 .
  • the fee determination module 202 determines an intermediary fee chargeable by the intermediary party 103 based on the reputation data accessed at 604 .
  • the value transfer module 204 transfers a first value from the first party 101 to the account of the intermediary party 103 .
  • the value transfer module 204 deducts the intermediary fee from the first value of the first party 101 to obtain a net value of the first value, and retains the intermediary fee in the account of the intermediary party 103 .
  • the value transfer module 204 transfers the net value of the first value from the account of the intermediary party 103 to the account of the third party 105 .
  • the transfer of the net value of the first value from the intermediary party 103 to the third party 105 is a physical transfer of money, i.e., person-to-person cash transfer.
  • the reputation update module 208 updates the reputation data associated with the intermediate party 103 .
  • the reputation update module 208 updates the number of remittance transactions conducted by the intermediary party 103 , and saves the number in the reputation table 306 shown in FIG. 4 .
  • the reputation update module 208 updates the count of successful remittance transactions completed by the intermediary party 103 , and saves the count in the reputation table 306 shown in FIG. 4 .
  • the reputation update module 208 receives feedback information in connection with the completed remittance transaction, updates the reputation data associated with the intermediary party 103 based on the received feedback information, and saves the reputation data in the reputation table 306 shown in FIG. 4 .
  • the feedback information is received from either the first party 101 or the third party 105 .
  • FIG. 7 illustrates a method of delivering a remittance from an account of a first party to an account of a third party through an intermediary party in accordance with another embodiment of the application.
  • the payment and remittance modules 120 receive a request to deliver a remittance from an account of a first party 101 to an account of a third party 105 through an intermediary party 103 .
  • the payment and remittance modules 120 access reputation data associated with the intermediary party 103 .
  • the reputation data associated with the intermediary party 103 is stored in database(s) 126 .
  • the payment and remittance modules 120 determine an intermediary fee chargeable by the intermediary party 103 based on the reputation data accessed. at 604 .
  • the payment and remittance modules 120 transfer a first value from the account of the first party 101 to the account of the intermediary party 103 .
  • the payment and remittance modules 120 transfer the first value from the account of the intermediary party 103 to the account of the third party 105 .
  • the payment and remittance modules 120 credit the account of the intermediary party 103 with the intermediary fee, and debit the account of the first party 101 with the intermediary fee.
  • the transfer confirmation module 206 receives a confirmation of the successful remittance transfer of the net value of the first value to the third party 105
  • the value transfer module 204 credits the account of the intermediary party 103 with the intermediary fee determined at 706 .
  • the payment and remittance modules 120 updates the reputation data associated with the intermediate party 103 .
  • the reputation update module 208 updates the count of remittance transactions conducted by the intermediary party 103 , and saves the count in the reputation table 306 shown in FIG. 4 .
  • the reputation update module 208 updates the count of successful remittance transactions completed by the intermediary party 103 , and saves the count in the reputation table 306 shown in FIG. 4 .
  • the reputation update module 208 receives feedback information in connection with the completed remittance transaction, updates the reputation data associated with the intermediary party 103 based on the received feedback information, and saves the reputation data in the reputation table 306 shown in FIG. 4 .
  • the feedback information is received from either the first party 101 or the third party 105 .
  • FIG. 8 is a block diagram illustrating a machine in the example form of a computer system 800 , within which a set of sequence of instructions for causing the machine to perform any one of the methodologies discussed herein may be executed.
  • the machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions that specify actions to be taken by that machine.
  • PC personal computer
  • PDA Personal Digital Assistant
  • STB set-top box
  • a cellular telephone a web appliance
  • network router switch or bridge
  • the example computer system 800 includes a processor 802 (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), a main memory 804 and a static memory 806 , which communicate with each other via a bus 808 .
  • processor 802 e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both
  • main memory 804 e.g., main memory 804
  • static memory 806 e.g.
  • the computer system 800 may further include a video display unit 810 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).
  • the computer system 800 also includes an alphanumeric input device 812 (e.g., a keyboard), a cursor control device 814 (e.g., a mouse), a disk drive unit 816 , a signal generation device 818 (e.g., a speaker) and a network interface device 820 .
  • a video display unit 810 e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)
  • the computer system 800 also includes an alphanumeric input device 812 (e.g., a keyboard), a cursor control device 814 (e.g., a mouse), a disk drive unit 816 , a signal generation device 818 (e.g., a speaker) and a network interface device 820 .
  • the disk drive unit 816 includes a machine-readable medium 822 on which is stored one or more sets of instructions (e.g., software 824 ) embodying any one or more of the methodologies or functions described herein.
  • the software 824 may also reside, completely or at least partially, within the main memory 804 and/or within the processor 802 during execution thereof by the computer system 800 , the main memory 804 and the processor 802 also constituting machine-readable media.
  • the software 824 may further be transmitted or received over a network 826 via the network interface device 820 .
  • machine-readable medium 822 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions.
  • the term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention.
  • the term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.

Abstract

One embodiment provides a method of delivering a remittance from a first party to a third party via an intermediary party, in which an intermediary fee is chargeable by the intermediary party. The method includes: receiving, at a payment system, a request to conduct a remittance transaction including a transfer of a first value from a first party to an account of an intermediary party, and by the intermediary party to transfer at least a portion of the first value to a third party; accessing reputation data associated with the intermediary party; and determining an intermediary fee chargeable by the intermediary party for the transfer of at least the portion of the first value to the third party, the determining of the intermediary fee being based on the reputation data. The reputation data can be information about the intermediary party, as well as the first party and/or the third party.

Description

    RELATED APPLICATION
  • This application is a continuation of U.S. patent application Ser. No. 11/642,030, filed Dec. 19, 2006, which is incorporated herein by reference in its entirety.
  • TECHNICAL FIELD
  • The present application relates to a method and system for delivering a remittance from a first party to a third party through an intermediary party over networks.
  • BACKGROUND
  • With the development of computer and network related technologies, more users communicate over networks and participate e-commerce transactions, e.g. selling/buying items, bidding on goods, or transferring money over networks, thus, the trust and reputation of the parties involved in e-commerce transactions have important impacts on the initiation and success of the e-commerce transactions.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • Some embodiments are illustrated by way of examples, and not by way of limitations, in the figures of the accompanying drawings in which:
  • FIG. 1 is an overview diagram illustrating a remittance delivery system having a client-server architecture configured for exchanging data over a network in accordance with an embodiment of the application;
  • FIG. 2 is a block diagram illustrating payment and remittance modules in accordance with an embodiment of the application;
  • FIG. 3 is a high level entity-relationship diagram illustrating an embodiment of various tables maintained in a database;
  • FIG. 4 is a chart illustrating data structure of a reputation table in accordance with an embodiment of the application;
  • FIG. 5 is a flowchart illustrating a method of determining an intermediary fee chargeable by an intermediary party, through which the remittance is transferred, in accordance with an embodiment of the application;
  • FIG. 6 is a flowchart illustrating a method of delivering a remittance from a first party to an account of a third party through an intermediary party in accordance with an embodiment of the application;
  • FIG. 7 is a flowchart illustrating a method of delivering a remittance from an account of a first party to an account of a third party through an intermediary party in accordance with another embodiment of the application; and
  • FIG. 8 is a block diagram illustrating a machine in the example form of a computer system, within which a set of sequence of instructions for causing the machine to perform any one of the methodologies discussed herein may be executed.
  • DETAILED DESCRIPTION
  • Example methods and systems to deliver a remittance from a first party to a third party through an intermediary party are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be evident, however, to one skilled in the art that the embodiments of the invention may be practiced without these specific details.
  • The term “remittance” used in the following description denotes “a money transfer between any two patties”, the term “intermediary party” denotes “a franchisee designated by a first party and/or third party for a remittance”, and the term “intermediary fee” denotes “the service charge by the intermediary party for the remittance transfer”.
  • FIG. 1 is an overview diagram illustrating a network system 100 having a client-server architecture configured tier exchanging data over a network 104 in accordance with an embodiment of the application.
  • In the embodiment, by virtue of the network system 100, a first party 101 may transfer a remittance to a third party 105 via an intermediary party 103, and the intermediary party 103 may charge an intermediary fee which is determined based. on the reputation of the intermediary party 103.
  • In another embodiment, the intermediary fee is also determined based on the reputation and/or risk scores of the first party 101 and/or the third party 105.
  • In some embodiments, the network system 100 has a client-server architecture configured for exchanging data over a network. The data may relate to various functions associated with the network system 100, for example, transferring remittances online, determining reputation of an intermediary party, determining intermediary fee of the intermediary party. Although illustrated herein as a client-server architecture for simplicity, in other embodiments the network architecture may vary and include another kind of architecture, for example, a peer machine in a peer-to-peer or distributed network environment.
  • In some embodiments, a network-based marketplace (payment and remittance system) 160 provides a platform, where a first party 101 and/or a third party 105 can choose an intermediary party 103 as a franchisee to transfer remittance based on the reputation data/score as well as other factors, like the price, the location, business hours of the intermediary party 103.
  • The network-based marketplace 160 forms a data exchange platform and provides, via a network 104, server-side functionalities to one or more clients. The one or more clients may utilize the network-based marketplace 160 to exchange data over the network 104. The data exchanged may include, but is not limited to, a fee schedule defined by the intermediary party 103, reputation data of an intermediary party 103 (such as a total number of transactions conducted by the intermediary party 103, a number of successful transactions conducted by the intermediary party 103, a total value of transactions conducted by the intermediary party 103 over a predetermined amount of time, and feedback data received in connection with transactions conducted by the intermediary party 103), as well as reputation data and/or risk scores of a first party 101 and/or a third party 105.
  • In some embodiments, the network-based marketplace 160 includes an application program interface (API) server 114 and a web server 116, which are coupled to an application server 118, provide programmatic interface and web interface respectively to the application server 118. In an embodiment, the application server 118 hosts payment and remittance modules 120. The application server 118 is coupled to one or more databases servers 124 that facilitate access to one or more databases 126.
  • In some embodiments, the API server 114 or the web server 116 may send, and receive data pertaining to the reputation of a merchant. In an embodiment, the API server 114 may send and receive data to and from an application running on another client machine, e.g., a client machine 110 or 112. The web server 116 may send and receive data to and from a webpage on a browser application, e.g., a web client 106 or 109, operating on the client machine 110 or 112. In another embodiment, the first party 101 may use a mobile device (e.g., a cell phone, not shown in FIG. 1) instead of a client machine 110 in FIG. 1 as an interface for communicating with the network-based marketplace 160 to initiate/complete the remittance transaction, as well as to update reputation data about the intermediary party 103.
  • FIG. 2 is a block diagram illustrating payment and remittance modules in accordance with an embodiment of the application.
  • In some embodiments, the payment and remittance modules 120 may provide a number of functions and services to users of the network-based marketplace 160. The payment and remittance modules 120 may include, but are not limited to, reputation determination module 200, fee determination module 202, value transfer module 204, transfer confirmation module 206, reputation update module 208, feedback module 210, dispute resolution applications 224, fraud prevention applications 226, and messaging applications 228.
  • In some embodiments, the payment network-based marketplace 160 includes a web interface 116, a reputation determination module 200, a fee determination module 202, and a value transfer module 204. The web interface 116 receives a request to conduct a remittance transaction to transfer at least a portion of a first value from an account of a first party 101 to an account of a third party 105 via an intermediary party 103. The reputation determination module 200 accesses a database 126 via a database server 124 to obtain reputation data associated with the intermediary party 103.
  • In an embodiment, the reputation data about the intermediary party 103 is a number of transactions conducted by the intermediary party 103. In another embodiment, the reputation data about the intermediary party 103 is a value of transactions conducted by the intermediary party 103 over a predetermined amount of time. In another embodiment, the reputation data about the intermediary party 103 is feedback data received in connection with transactions conducted by the intermediary party 103 from the first party 101 and/or the third party 105. In another embodiment, the reputation data about the intermediary party 103 is a number of successful transactions conducted by intermediary party 103.
  • In some embodiments, the fee determination module 202, based on the reputation data of the intermediary party 103, determines an intermediary fee chargeable by the intermediary party 103 for transferring the at least a portion of the first value to the third party 105. The reputation of an intermediary party 103, e.g., a franchisee, may affect the trust and preference of the users, as well as the service rate of the intermediary party 103. For example, an intermediary party 103 having done more (e.g. 500) transactions successfully charges a higher (e.g. $10) withdrawal fee, while another intermediary party 103 having done less (e.g. 10) transactions successfully charges a lower (e.g. $2) withdrawal fee in order to build up its reputation.
  • In an embodiment, the fee determination module 202 also takes a fee schedule defined by the intermediary party 103 as a factor (or input) to determine the intermediary fee chargeable by the intermediary party 103 for transferring the at least a portion of the first value to the third party 105.
  • In another embodiment, the fee determination module 202 also takes the reputation data and/or risk scores of the first party 103 and/or the third party 105 as a factor to determine an intermediary fee chargeable by the intermediary party 103 for transferring the at least a portion of the first value to the third party 105. The intermediary party 103 may choose to change the intermediary fee based on reputation data and/or risk scores of the first party 101 and/or the third party 105. For example, the intermediary party 103 sees that the first party 101 has a history of routinely initiating chargebacks and/or requesting refunds on transactions, the intermediary party 103 may choose to accept the remittance transaction, but charge a higher intermediary fee to cover the risk of the remittance transaction.
  • In some embodiments, the value transfer module 204 transfers the first value from the account of the first party 101 to the account of the intermediary party 103. in an embodiment, the value transfer module 204 deducts the intermediary fee from the first value, and retains the intermediary fee in the account of the intermediary party 103. In another embodiment, the value transfer module 204 credits the account of the intermediary party 103 with the intermediary fee, and debits the account of the first party 101 with the intermediary fee.
  • In some embodiments, the network-based marketplace 160 further includes a transfer confirmation module 206, coupled to the value transfer module 204, to provide confirmation of the transfer of at least a portion of the first value to the third party 105. The value transfer module 204 credits the account of the intermediary party 103 with the intermediary fee responsive to receiving a confirmation from the transfer confirmation module 206 of the transfer of at least a portion of the first value to the third party 105. The transfer of at least a portion of the first value from the intermediary party 103 to the third party 105, for example, can be a physical transfer of money.
  • In an embodiment, the transfer confirmation module 206 receives a confirmation of the transfer of at least a portion of the first value to the third party 105 is received from the third party 105. In another embodiment, the transfer confirmation module 206 receives confirmation of the transfer of at least a portion of the first value to the third party 105 is received from the intermediary party 103.
  • In some embodiments, the payment and remittance system 160 further includes a reputation update module 208 to update the reputation data associated with the intermediary party 103 based on the remittance transaction conducted. The feedback module 208 may receive the feedback information from the first party 101 and/or the third party 105.
  • In one embodiment, the reputation update module 208 updates a count of remittance transactions conducted by the intermediary party 105. In another embodiment, the reputation update module 208, after determining that the remittance transaction has been successfully completed, updates a count of successful remittance transactions completed by the intermediary party 103. In another embodiment, from a feedback module 210, the reputation update module 208 receives feedback information regarding the remittance transaction from the first party 101 and/or the third party 105 and updates the reputation data based on the received feedback information.
  • In some embodiments, in conjunction with one or more weighting functions and transaction attributes, the feedback module 210 uses the feedback provided by the first party 101 and/or the third party 105 about the intermediary party 103 to determine a new feedback value about the intermediary party 103, and then the reputation module 208 updates the reputation value about the intermediary party 103 based on the new feedback value. For example, the one or more weighting functions may be applied among feedback indicators, such as negative, neutral, and positive, to produce a weighted value for the new feedback value, which is from either the first party 101 or the third party 105. If the weighted value is less than zero, it would result in a negative impact on the existing feedback value, and if greater than zero, a positive impact. If the first party 101 or the third party 105 does not leave any feedback, the feedback module 210 would by default assume a neutral impact. The reputation of the intermediary party 103 may suffer based on past transaction feedback. For example, the intermediary party's reputation may decline based on how many negative transactions the intermediary party has conducted.
  • In other embodiments, the feedback module 210 may conduct a credit check to obtain feedback scores about an intermediary party 103 from a third party source, e.g. from a bank, a financial entity, or a commercial entity.
  • In some embodiments, a messaging application 228 of the network-based marketplace 160 may be used to deliver messages among users of the network-based marketplace 160. The messages may be used by the payment and remittance system 160, the first party 101, the third party 105, or the intermediary party 103 to communicate or exchange information.
  • In an embodiment, the messaging application 228 may be used in conjunction with a dispute resolution application 224 to settle down disputes involved in remittance transactions among the first party 101, the third party 105, and the intermediary party 103.
  • In another embodiment, the messaging application 228 may be used in conjunction with a fraud prevention application 226 to prevent frauds, which might happen during the process of the remittance transaction.
  • FIG. 3 is a high level entity-relationship diagram illustrating one embodiment of various tables 300 that may be maintained in the database 226 shown in FIG. 1. These tables 300 may be utilized by and support the payment and remittance modules 120,
  • In some embodiments, a user table 302 may contain a record for each registered user of the network-based marketplace 160, which may include an identifier, an address and financial instrument information pertaining to each registered user. For example, a user may operate as a first party 101, a third party 105, or an intermediary party 103 within the payment and remittance modules 120.
  • In some embodiments, a remittance history table 304 may contain a record for each remittance transaction performed via the network-based marketplace 160 during a certain period of time. For example, remittance history table 304 may contain a remittance transaction identifier, the identifier of each of the first party 101, the third party 105 and the intermediary party 103, dates showing when the first party 101 requests the remittance transaction and when the remittance transaction is completed, the value of the remittance transaction requested, and an attribute identifier of the remittance transaction.
  • In some embodiments, a transaction table 310 may further contain more detailed information of each remittance transaction than the information maintained in remittance history table 304. For example, the transaction table 310 may further contain the information about the intermediary fee charged by the intermediary party 103.
  • In some embodiments, an attribute table 312 may contain attribute identifier, and attributes of a transaction, e.g. indicating whether the intermediary fee is paid by the first party 101 or by the third party 105.
  • In some embodiments, a reputation table 306 may contain an identifier of the each intermediary party 103, and reputation data of the each intermediary party 103 registered in of the network-based marketplace 160.
  • In some embodiments, a feedback table 308 may be utilized by the feedback module 210 to construct and maintain reputation information in the form of feedback values about the intermediary party 103 of the network-based marketplace 160. For example, the feedback values about the intermediary party 103 in the feedback table 308 can be used to update the reputation values about the intermediary party 103 in the reputation table 306.
  • FIG. 4 illustrates data structure of a reputation table 306 in accordance with an embodiment illustrated in FIG. 3.
  • In some embodiments, the fields or columns of the reputation table 306 shown in FIG. 4 include an identifier of the intermediary party 103, a number of transactions conducted by the intermediary party 103, a number of positive feedbacks from the first party 101 or the third party 105, a number of negative feedbacks from the first party 101 or the third party 105, and a total value successfully transferred by the intermediary party 103.
  • FIG. 5 illustrates a method of determining an intermediary fee chargeable by an intermediary party, through which the remittance is transferred, in accordance with an embodiment of the application.
  • At 502 of the embodiment, via the web server 116, the application server 118 receives a request to deliver a remittance from a first party 101 to an account of a third party 105 through an intermediary party 103.
  • At 504, in some embodiments, the reputation determination module 200 access reputation data associated with the intermediary party 103. In an embodiment, the reputation data associated with the intermediary party 103 is stored in database(s) 126. In other embodiments, at 504, the reputation determination module 200 also access reputation data and/or risk scores of a first party 101 and/or a third party 105 stored in database(s) 126 or populated from other systems.
  • In an embodiment, the reputation data associated with the intermediary party 103 includes a number of remittance transactions conducted by the intermediary party 103. In another embodiment, the reputation data associated with the intermediary party 103 is based on a value of remittance transactions conducted by the intermediary party 103 over a predetermined amount of time. In another embodiment, the reputation data associated with the intermediary party 103 includes feedback data received in connection with remittance transactions conducted by the intermediary party 103. In one embodiment, the feedback data is received from the first party 101. In another embodiment, the feedback data is received from the third party 105. In another embodiment, the reputation data associated with the intermediary party 103 includes a number of successful remittance transactions conducted by the intermediary party 103.
  • Then, at 506, the fee determination module 202 determines an intermediary fee chargeable by the intermediary party 103 based on the reputation data about the intermediary party 103 accessed at 504.
  • In some embodiments, at 506, the fee determination module 202, based on the reputation data of the intermediary party 103, determines an intermediary fee chargeable by the intermediary party 103 for transferring the at least a portion of the first value to the third party 105.
  • In an embodiment, at 506, the fee determination module 202 also takes a fee schedule defined by the intermediary party 103 as a factor or an input to determine the intermediary fee chargeable by the intermediary party 103 for transferring the at least a portion of the first value to the third party 105.
  • In another embodiment, at 506, the fee determination module 202 also takes the reputation data and/or risk scores of the first party 103 and/or the third party 105 as a factor to determine an intermediary fee chargeable by the intermediary party 103 for transferring the at least a portion of the first value to the third party 105. The intermediary party 103 may choose to change the intermediary fee based on reputation data and/or risk scores of the first party 103 and/or the third party 105. For example, the intermediary party 103 sees that the first party 101 has a history of routinely initiating chargebacks and/or requesting refunds on transactions, the intermediary party 103 may choose to accept the remittance transaction, but charge a higher intermediary fee to cover the risk of the remittance transaction.
  • FIG. 6 illustrates a method of delivering a remittance from a first party to an account of a third party through an intermediary party in accordance with an embodiment of the application.
  • In the embodiment, at 602, the messaging application 228 receives a request to deliver a remittance from an account of a first party 101 to an account of a third party 105 through an intermediary party 103.
  • In an embodiment, at 602, the remittance is transferred from an account of the first party 101 to the account of the intermediary party 103.
  • In another embodiment, at 602, the remittance is transferred from the first party 101 in cash to the account of the intermediary party 103.
  • At 604 of the embodiment, the reputation determination module 200 accesses reputation data associated with the intermediary party 103. In an embodiment, the reputation determination module 200 obtains the reputation data associated with the intermediary party 103 from a database 126.
  • At 606, the fee determination module 202 determines an intermediary fee chargeable by the intermediary party 103 based on the reputation data accessed at 604.
  • At 608, the value transfer module 204 transfers a first value from the first party 101 to the account of the intermediary party 103.
  • At 610, the value transfer module 204 deducts the intermediary fee from the first value of the first party 101 to obtain a net value of the first value, and retains the intermediary fee in the account of the intermediary party 103.
  • At 612, in an embodiment, the value transfer module 204 transfers the net value of the first value from the account of the intermediary party 103 to the account of the third party 105. In another embodiment, the transfer of the net value of the first value from the intermediary party 103 to the third party 105 is a physical transfer of money, i.e., person-to-person cash transfer.
  • Then, at 614, the reputation update module 208 updates the reputation data associated with the intermediate party 103.
  • In an embodiment, after the remittance completed, the reputation update module 208 updates the number of remittance transactions conducted by the intermediary party 103, and saves the number in the reputation table 306 shown in FIG. 4.
  • In another embodiment, after the transfer confirmation module 206 confirming that the remittance transaction has been successfully completed, the reputation update module 208 updates the count of successful remittance transactions completed by the intermediary party 103, and saves the count in the reputation table 306 shown in FIG. 4.
  • In another embodiment, the reputation update module 208 receives feedback information in connection with the completed remittance transaction, updates the reputation data associated with the intermediary party 103 based on the received feedback information, and saves the reputation data in the reputation table 306 shown in FIG. 4. The feedback information is received from either the first party 101 or the third party 105.
  • FIG. 7 illustrates a method of delivering a remittance from an account of a first party to an account of a third party through an intermediary party in accordance with another embodiment of the application.
  • In the embodiment, at 702, the payment and remittance modules 120 receive a request to deliver a remittance from an account of a first party 101 to an account of a third party 105 through an intermediary party 103.
  • At 704, the payment and remittance modules 120 access reputation data associated with the intermediary party 103. In an embodiment, the reputation data associated with the intermediary party 103 is stored in database(s) 126.
  • At 706, the payment and remittance modules 120 determine an intermediary fee chargeable by the intermediary party 103 based on the reputation data accessed. at 604.
  • At 708, the payment and remittance modules 120 transfer a first value from the account of the first party 101 to the account of the intermediary party 103.
  • At 710, the payment and remittance modules 120 transfer the first value from the account of the intermediary party 103 to the account of the third party 105.
  • At 712, the payment and remittance modules 120 credit the account of the intermediary party 103 with the intermediary fee, and debit the account of the first party 101 with the intermediary fee. In an embodiment, after the transfer confirmation module 206 receives a confirmation of the successful remittance transfer of the net value of the first value to the third party 105, the value transfer module 204 credits the account of the intermediary party 103 with the intermediary fee determined at 706.
  • Then, at 714, the payment and remittance modules 120 updates the reputation data associated with the intermediate party 103.
  • In an embodiment, after the remittance completed, the reputation update module 208 updates the count of remittance transactions conducted by the intermediary party 103, and saves the count in the reputation table 306 shown in FIG. 4.
  • In another embodiment, after the transfer confirmation module 206 confirming that the remittance transaction has been successfully completed, the reputation update module 208 updates the count of successful remittance transactions completed by the intermediary party 103, and saves the count in the reputation table 306 shown in FIG. 4.
  • In another embodiment, the reputation update module 208 receives feedback information in connection with the completed remittance transaction, updates the reputation data associated with the intermediary party 103 based on the received feedback information, and saves the reputation data in the reputation table 306 shown in FIG. 4. The feedback information is received from either the first party 101 or the third party 105.
  • FIG. 8 is a block diagram illustrating a machine in the example form of a computer system 800, within which a set of sequence of instructions for causing the machine to perform any one of the methodologies discussed herein may be executed. In alternative embodiments, the machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set of instructions to perform any one or more of the methodologies discussed herein.
  • The example computer system 800 includes a processor 802 (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), a main memory 804 and a static memory 806, which communicate with each other via a bus 808.
  • The computer system 800 may further include a video display unit 810 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 800 also includes an alphanumeric input device 812 (e.g., a keyboard), a cursor control device 814 (e.g., a mouse), a disk drive unit 816, a signal generation device 818 (e.g., a speaker) and a network interface device 820.
  • The disk drive unit 816 includes a machine-readable medium 822 on which is stored one or more sets of instructions (e.g., software 824) embodying any one or more of the methodologies or functions described herein. The software 824 may also reside, completely or at least partially, within the main memory 804 and/or within the processor 802 during execution thereof by the computer system 800, the main memory 804 and the processor 802 also constituting machine-readable media.
  • The software 824 may further be transmitted or received over a network 826 via the network interface device 820.
  • While the machine-readable medium 822 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
  • Thus, methods and systems for remittance delivery from a first party to a third party through an intermediary party have been described. Although the present invention has been described with reference to specific embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims (20)

1. A system for a network-based marketplace, the system comprising:
an interface to receive a request to conduct a remittance transaction, the remittance transaction including a transfer of a value from a first party to an account of an intermediary party, and a transfer of at least a portion of the value to a third party by the intermediary party; and
a reputation determination module to access reputation data associated with the intermediary party; and
a fee determination module to determine an intermediary fee chargeable by the intermediary party for the transfer of at least the portion of the first value to the third party based on the reputation data.
2. The system of claim 1, further comprising a value transfer module to transfer the value from an account of the first party to the account of the intermediary party, and to transfer at least the portion of the value to the third party.
3. The system of claim 2, wherein the value transfer module is to deduct the intermediary fee from the value, and to retain the intermediary fee in the account of the intermediary party.
4. The system of claim 2, wherein the value transfer module is to credit the account of the intermediary party with the intermediary fee.
5. The system of claim 2, wherein the value transfer module is to debit the account of the first part with the intermediary fee.
6. The system of claim 2, further comprising a transfer confirmation module, coupled to the value transfer module, to provide confirmation of the transfer of at least the portion of the value to the third party.
7. The system of claim 1, further comprising a reputation update module to update the reputation data associated with the intermediary party responsive to a completion of the remittance transaction.
8. The system of claim 7, wherein the transfer confirmation module is to receive a confirmation of the transfer of at least the portion of the value to the third party from the third party.
9. The system of claim 7, wherein the transfer confirmation mo is to receive a confirmation of the transfer of at least, the portion of the value to the third party from the intermediary party.
10. A method of delivering a remittance over a network, comprising:
receiving a request to conduct a remittance transaction, the remittance transaction including a transfer of a value from a first party to an account of an intermediary party, and a transfer of at least a portion of the value to a third party by the intermediacy party;
accessing, using one or more processors, reputation data associated with the intermediary party; and
determining an intermediary tee chargeable by the intermediary party for the transfer of at least the portion of the value to the third party, the determining of the intermediary fee being based upon the reputation data associated with the intermediary party.
11. The method of claim 10, wherein the reputation data associated with the intermediary party includes a value of remittance transactions previously conducted by the intermediary party over a predetermined amount of time.
12. The method of claim 11, wherein the more the value of remittance transactions previously conducted by the intermediary party over the predetermined amount of time, the more the intermediary fee.
13. The method of claim 10, wherein the reputation data associated with the intermediary party includes a number of successful transactions previously conducted by the intermediary party over a predetermined amount of time.
14. The method of claim 13, wherein the more the number of successful transactions previously conducted by the intermediary party over the predetermined amount of time, the more the intermediary fee.
15. The method of claim 10, wherein the reputation data associated with the intermediary party includes feedback data received from one or more first and/or third parties in connection with remittance transactions previously conducted by the intermediary party.
16. The method of claim 10, wherein the request is received by an interface of a server included in a payment system.
17. The method of claim 10, further comprising deducting the intermediary fee from the value, and retaining the intermediary fee in the account of the intermediary party.
18. The method of claim 10, further comprising crediting le account of the intermediary party with the intermediary fee with the intermediary fee responsive to confirmation of the transfer of at least the portion of the value to the third party.
19. The method of claim 10, further comprising debiting the account of the first party with the intermediary fee responsive to confirmation of the transfer of at least the portion of the value to the third party.
20. A machine readable medium embodying instructions, which when executed by a machine, cause the machine to perform a method including:
receiving a request to conduct a remittance transaction, the remittance transaction including a transfer of a value from a first party to an account of an intermediary party, and a transfer of at least a portion of the value to a third party by the intermediary party;
accessing reputation data associated with the intermediary party; and
determining an intermediary tee chargeable by the intermediary party for the transfer of at least the portion of the value to the third party, the determining of the intermediary fee being based upon the reputation data associated with the intermediary party.
US14/223,796 2006-12-19 2014-03-24 Reputation integration into remittance delivery Abandoned US20140289102A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/223,796 US20140289102A1 (en) 2006-12-19 2014-03-24 Reputation integration into remittance delivery

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/642,030 US8719154B2 (en) 2006-12-19 2006-12-19 Reputation integration into remittance delivery
US14/223,796 US20140289102A1 (en) 2006-12-19 2014-03-24 Reputation integration into remittance delivery

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/642,030 Continuation US8719154B2 (en) 2006-12-19 2006-12-19 Reputation integration into remittance delivery

Publications (1)

Publication Number Publication Date
US20140289102A1 true US20140289102A1 (en) 2014-09-25

Family

ID=39528715

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/642,030 Active US8719154B2 (en) 2006-12-19 2006-12-19 Reputation integration into remittance delivery
US14/223,796 Abandoned US20140289102A1 (en) 2006-12-19 2014-03-24 Reputation integration into remittance delivery

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/642,030 Active US8719154B2 (en) 2006-12-19 2006-12-19 Reputation integration into remittance delivery

Country Status (1)

Country Link
US (2) US8719154B2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016068939A1 (en) * 2014-10-28 2016-05-06 Intuit Inc. Managing money movement method involving a payment service system

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8620822B2 (en) * 2007-02-01 2013-12-31 Microsoft Corporation Reputation assessment via karma points
US20090299903A1 (en) * 2007-12-07 2009-12-03 Taiwan Pelican Express Co., Ltd. Non-Cash Cash-on-Delivery Method and System
US20090164374A1 (en) * 2007-12-21 2009-06-25 Ebay Inc. System and Methods for One Time Check Numbers
US20120101915A1 (en) * 2008-12-11 2012-04-26 Yanchao Fu Commission based sale on e-commerce
US20110320239A1 (en) * 2010-06-28 2011-12-29 International Business Machines Corporation Fault tolerant social networks for service organizations
US20130031009A1 (en) * 2011-07-28 2013-01-31 Apple Inc. Ad-hoc cash dispensing network
GB2512070A (en) * 2013-03-19 2014-09-24 Barclays Bank Plc Online payment transaction system
AU2017223238A1 (en) * 2016-02-22 2018-10-04 Tata Consultancy Services Limited System and method for complaint and reputation management in a multi-party data marketplace
US20230103398A1 (en) * 2021-10-04 2023-04-06 Ebay Inc. Security Deposits Using Tokenized Reputation Scores
US11748793B2 (en) 2021-10-04 2023-09-05 Ebay Inc. Transaction access control using tokenized reputation scores
US11922453B2 (en) * 2021-10-08 2024-03-05 Ebay Inc. Generating a tokenized reputation score

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040039692A1 (en) * 2000-09-15 2004-02-26 Hyperwallet Systems Inc. On-line payment system
US20040107129A1 (en) * 2002-01-16 2004-06-03 Manfred Langen Method and system and computer program with program code means, and computer program product for evaluating an electronic object for sale in a computer network

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8706618B2 (en) * 2005-09-29 2014-04-22 Ebay Inc. Release of funds based on criteria
US20020062280A1 (en) * 2000-11-21 2002-05-23 John Zachariassen System and method for transmitting goods, remuneration, and information
US20020138426A1 (en) * 2001-03-26 2002-09-26 Streamtrans, Inc. Concentration of electronic payments
JP2003058626A (en) * 2001-08-15 2003-02-28 Fuji Photo Film Co Ltd Consultant server and consultant method
US20070203852A1 (en) * 2006-02-24 2007-08-30 Microsoft Corporation Identity information including reputation information
US20070299920A1 (en) * 2006-06-27 2007-12-27 Crespo Arturo E Anonymous Email Address Management

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040039692A1 (en) * 2000-09-15 2004-02-26 Hyperwallet Systems Inc. On-line payment system
US20040107129A1 (en) * 2002-01-16 2004-06-03 Manfred Langen Method and system and computer program with program code means, and computer program product for evaluating an electronic object for sale in a computer network

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016068939A1 (en) * 2014-10-28 2016-05-06 Intuit Inc. Managing money movement method involving a payment service system

Also Published As

Publication number Publication date
US20080147540A1 (en) 2008-06-19
US8719154B2 (en) 2014-05-06

Similar Documents

Publication Publication Date Title
US8719154B2 (en) Reputation integration into remittance delivery
US8504450B2 (en) Mobile remittances/payments
US8051007B2 (en) Method and system to facilitate a payment in satisfaction of accumulated micropayment commitments to a vendor
US20160155103A1 (en) Utilizing an electronic payment system to implement rebate programs
US7451134B2 (en) Method and apparatus for facilitating data management over a network
US8682784B2 (en) Method and system to process credit card payment transactions initiated by a merchant
US8423461B2 (en) Advanced payment management system
US10922694B2 (en) Automatic teller machine (ATM) electronic push requests
US20140180849A1 (en) Methods and systems for conducting transactions
US20190318354A1 (en) Secure electronic billing with real-time funds availability
US8655780B2 (en) Person-to-person payments: contextual spending
US20190378182A1 (en) Secure electronic billing with real-time funds availability
US20120005054A1 (en) Fees and foreign currency exchange calculation
WO2006019368A2 (en) Method and system to process credit card payment transactions initiated by a merchant
AU2012369168B2 (en) Mobile money order
AU2012200569B2 (en) Payment using funds pushing
US20210374726A1 (en) Systems and methods for facilitating network messaging
KR100847710B1 (en) Facilitating micropayments between a plurality of parties
US20150039503A1 (en) Mobile remittances/payments

Legal Events

Date Code Title Description
AS Assignment

Owner name: EBAY INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SHASTRY, VISHWANATH;ONDECK, KRISTEN;JESSE, DAVID;REEL/FRAME:032511/0592

Effective date: 20061218

AS Assignment

Owner name: PAYPAL, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EBAY INC.;REEL/FRAME:036171/0144

Effective date: 20150717

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION