Recherche Images Maps Play YouTube Actualités Gmail Drive Plus »
Connexion
Les utilisateurs de lecteurs d'écran peuvent cliquer sur ce lien pour activer le mode d'accessibilité. Celui-ci propose les mêmes fonctionnalités principales, mais il est optimisé pour votre lecteur d'écran.

Brevets

  1. Recherche avancée dans les brevets
Numéro de publicationUS20060015454 A1
Type de publicationDemande
Numéro de demandeUS 11/149,977
Date de publication19 janv. 2006
Date de dépôt12 sept. 2005
Date de priorité9 juin 2004
Autre référence de publicationCA2568584A1, CA2569338A1, CA2569351A1, CN101027687A, CN101031905A, CN101385044A, EP1779308A2, EP1779308A4, EP1782255A2, EP1782255A4, EP1782259A2, EP1782259A4, US8560439, US20050278251, WO2005124635A2, WO2005124635A3, WO2005124639A2, WO2005124639A3, WO2005124640A2, WO2005124640A3
Numéro de publication11149977, 149977, US 2006/0015454 A1, US 2006/015454 A1, US 20060015454 A1, US 20060015454A1, US 2006015454 A1, US 2006015454A1, US-A1-20060015454, US-A1-2006015454, US2006/0015454A1, US2006/015454A1, US20060015454 A1, US20060015454A1, US2006015454 A1, US2006015454A1
InventeursDean Hahn-Carlson
Cessionnaire d'origineHahn-Carlson Dean W
Exporter la citationBiBTeX, EndNote, RefMan
Liens externes: USPTO, Cession USPTO, Espacenet
Distributor-based transaction processing arrangement and approach
US 20060015454 A1
Résumé
Transaction management for distributor-based transactions is facilitated. According to an example embodiment of the present invention, a transaction management approach involves the processing of transactions on behalf of clients using rules associated with a distributor sponsoring the clients into the transaction. The processing involves the implementation of rules, profiles and/or other stored data to facilitate various transaction functions, such as order acceptance, invoice approval, payment and settlement, and credit extension.
Images(4)
Previous page
Next page
Revendications(24)
1. An automated transaction processing system for processing transactions on behalf of a plurality of distributors that contract with a controller party implementing the automated transaction processing system, the system comprising:
a client-layer auditor configured and arranged to audit transactions between contracting parties according to different sets of transaction rules, each of the respective sets of transaction rules being defined as a function of a unique one of the plurality of distributors and a business relationship between the unique distributor and at least one of the contracting parties;
a client-layer payment processor configured and arranged to facilitate payment for each audited transaction as a function of the client-layer auditor's audit of the transaction;
a distributor-layer controller configured and arranged for controlling an implementation of the client-layer payment processor on behalf of each one of the plurality of distributors as a function of a business relationship between each distributor and the controller party; and
a distributor-layer payment processor configured and arranged to assess a fee against each distributor as a function of transactions processed on behalf of each distributor, and to facilitate a funds transfer as a function of the assessed fee.
2. The system of claim 1, wherein the client-layer payment processor is further configured and arranged to assess a fee for each transaction and to facilitate payment of that fee as a function of the transaction rules, the payment facilitated by at least one of a contracting party and a unique distributor for the transaction.
3. The system of claim 1, further comprising:
a data storage arrangement configured and arranged to store transaction rules provided by each distributor, the transaction rules including information by which transactions are processed.
4. The system of claim 1, wherein the client-layer payment processor is configured and arranged to audit transactions by associating transaction data with one of the contracting parties as a function of information in the transaction data and a user profile for the one of the contracting parties, and to provide a payment authorization as a function of the audit, wherein the client-layer payment processor is configured and arranged to facilitate payment for each audited transaction as a function of the payment authorization.
5. The system of claim 1, wherein the client-layer payment processor is configured and arranged to facilitate payment for each audited transaction between a buyer and a seller by extending credit to the buyer and paying the seller.
6. The system of claim 5, wherein the client-layer payment processor is configured and arranged to extend credit as a function of transaction rules set by the controller.
7. They system of claim 6, wherein the client-layer payment processor is configured and arranged to extend credit from a financial institution specified by the controller in the transaction rules.
8. The system of claim 1, wherein the client-layer payment processor is configured and arranged to facilitate payment for each audited transaction between a buyer and a seller by authorizing payment to the seller from a financial institution specified in a user profile for the buyer.
9. The system of claim 8, wherein the client-layer payment processor is configured and arranged to facilitate payment by authorizing the extension of credit to the buyer for making the payment to the seller.
10. The system of claim 1, wherein the client-layer auditor is configured and arranged to audit a transaction between a buyer and a seller as a function of a credit term relating to the buyer and transaction rules specified by the controller party, and further to underwrite a cash flow from the buyer to the seller on behalf of the controller party as a function of the audit.
11. The system of claim 1, wherein at least two of the client-layer auditor, the distributor-layer controller, the client-layer payment processor and the distributor-layer payment processor are implemented in a common transaction processor.
12. The system of claim 1, wherein the distributor-layer controller is configured and arranged for controlling the implementation of the different sets of transaction rules by authorizing users providing the transaction rules as a function of profile information for the users.
13. The system of claim 1, wherein the distributor-layer payment processor is configured and arranged to assess a fee against each distributor as a function of transaction rules specified by the controller party and the distributor.
14. The system of claim 1, wherein the distributor-layer controller is configured and arranged to control each distributor's access to the client-layer auditor for the distributor as a function of user profile information for the distributor.
15. The system of claim 1, wherein the distributor-layer controller is configured and arranged to control each contracting party's access to the client-layer auditor as a function of user profile information for the contracting party.
16. The system of claim 15, wherein the distributor-layer controller is configured and arranged to control each contracting party's access to the client-layer auditor as a function of user profile information provided by a distributor sponsoring the contracting party.
17. The system of claim 1, further comprising a user interface implemented by the unique distributor and adapted for interfacing with contracting parties specified by the unique distributor, wherein the user interface is adapted to facilitate contracting party access to the system as a function of profile information for the contracting party, and wherein the distributor-layer controller is configured and arranged to facilitate access to the system by any contracting party granted access to the distributor's user interface.
18. A fee-based distributed transaction processing system comprising:
a data storage arrangement including at least one distinct database and adapted to store business rules for a multitude of transactions involving distinct transaction parties including buyers, sellers and processing distributors, the processing distributors sponsoring at least one of a buyer and a seller for each transaction, the data storage arrangement also adapted to store user profiles for the transaction parties;
a transaction processing controller adapted to interact with the distinct transaction parties for receiving profile information specified by the transaction parties, to interact with the processing distributors for receiving the business rules as specified by each processing distributor, and to store the received profile information and business rules in the data storage arrangement;
an association engine configured and arranged, for each transaction, to receive and associate transaction payment data with a processing distributor as a function of stored profile information for parties to a transaction to which the transaction payment data applies;
an auditor engine configured and arranged, for each transaction, to audit payment of the received transaction payment data associated with a processing distributor as a function of business rules for the associated processing distributor;
a transaction payment processor configured and arranged to facilitate payment for each audited transaction as a function of the auditor engine's audit and profile information for at least one transaction party involved in the payment;
a fee payment processor configured and arranged, for each transaction, to assess a fee against the distributor sponsoring a transaction party for the transaction, and to facilitate payment for the assessed fee.
19. The system of claim 18, wherein at least one of the transaction processing controller, the association engine, the auditor engine, the transaction payment processor and the fee payment processor is a software-implemented function of a transaction processor arrangement.
20. The system of claim 18, wherein the transaction payment processor is configured and arranged to facilitate payment for each audited transaction by extending credit to facilitate payment to a seller for the transaction.
21. The system of claim 20, wherein the transaction payment processor is configured and arranged to facilitate payment for an audited transaction by extending credit to facilitate payment to a seller for the transaction using a credit rating of a distributor sponsoring the audited transaction.
22. The system of claim 20, wherein the transaction payment processor is configured and arranged to facilitate payment for an audited transaction by extending credit to facilitate payment to a seller for the transaction using a credit rating of a buyer participating in the audited transaction.
23. The system of claim 20, wherein the transaction payment processor is configured and arranged to facilitate payment for an audited transaction by extending credit to facilitate payment to a seller for the transaction using a credit rating of a seller participating in the audited transaction.
24. A method for processing transactions on behalf of a plurality of distributors that contract with a controller party, the method comprising:
auditing transactions between contracting parties according to different sets of transaction rules, each of the respective sets of transaction rules being defined as a function of a unique one of the plurality of distributors and a business relationship between the unique distributor and at least one of the contracting parties;
facilitating payment for each audited transaction as a function of the audit of the transaction and of a business relationship between each distributor and the controller party;
assessing a fee against each distributor as a function of transactions processed on behalf of each distributor; and
facilitating a funds transfer as a function of the assessed fee.
Description
    RELATED PATENT DOCUMENTS
  • [0001]
    This patent document claims priority under 35 U.S.C. §119 to U.S. Provisional Patent Application No. 60/578,375, entitled “Financial Transaction Processing System and Approach” and filed on Jun. 9, 2004.
  • FIELD OF THE INVENTION
  • [0002]
    The present invention is directed to communications and data processing and, more specifically, to processing transactions with distributor-client layer hierarchy and payment facilitation for multiple distributors.
  • BACKGROUND
  • [0003]
    Operational management of contractual and transactional interactions between buyers, sellers, financial institutions and others involved in the exchange of merchant offerings (e.g., goods and/or services) for purposes of commerce have typically been labor and time intensive. Generally, the processes of managing transactions between business entities have been unduly burdensome and inefficient.
  • [0004]
    Financial institutions and other transaction processing entities employ transaction processing parameters that are unique to each entity. In addition, these transaction processing parameters typically need to be kept separate (and confidential), relative to other financial institutions. Often, transaction processing is dependent upon these parameters, which are specific to a particular financial institution involved in financing the transaction. In this regard, transaction processing for portions of a transaction that are related to a financial institution has generally been limited to implementation by a processing engine or system employed by the financial institution participating in the transaction.
  • [0005]
    When a transaction reaches the payment step, financial institutions for different parties to the transaction must interact with each other. This interaction typically involves complex agreements and associations that facilitate the transfer of funds. At times, there can be delays in payment or disputes regarding terms of payment. In addition, this process is highly susceptible to error. Interaction complexity, delay and error, as well as a multitude of other characteristics of transaction payment can cost one or more parties to a transaction (including financial institutions) a significant amount of funds.
  • [0006]
    Most industries are quite competitive and any cost savings are therefore important. Administrative costs are targeted for reduction as no revenue is directly generated from administrative functions. However, administrative costs associated with commercial transactions have been difficult to reduce in the current business environment with widely diffused data.
  • [0007]
    The above and other difficulties in the management and coordination of transactions have presented administrative and cost challenges to business entities involved in various aspects of transactions, including financial institutions and others.
  • SUMMARY
  • [0008]
    The present invention is directed to overcoming the above-mentioned challenges and others related to the types of devices and applications discussed above and in other applications. The present invention is exemplified in a number of implementations and applications, some of which are summarized below.
  • [0009]
    According to an example embodiment of the present invention, transactions are managed using a multi-layer processing approach involving the automatic processing of client-based transactions with transaction processor-implemented functions involving an administrated processing system with a distributor layer of sponsoring entities, such as financial institutions, buyer sponsors and seller sponsors. Profile and/or contract information is stored in connection with a variety transactions and used to audit characteristics of the transactions and, where appropriate, facilitate financial characteristics of the transactions. Transaction processing fees are automatically assessed, with funds associated with the fees being selectively allocated for administration and distribution functions. In some applications, one or more parties to the transaction providing financing services also assesses fees, with these financing fees also being allocated as part of the transaction.
  • [0010]
    In another example embodiment, fees are automatically assessed as a function of various transaction characteristics and contractual-type agreements between transaction clients and distributors, and between each distributor and a system administrator. Funds from the assessed fees are automatically allocated to the system administrator, distributors and, where appropriate, transaction clients as relative to the contractual-type agreements.
  • [0011]
    According to another example embodiment of the present invention, an automated transaction processing system processes transactions on behalf of a plurality of distributors that contract with a controller party implementing the automated transaction processing system. The system includes client-layer functions including a client-layer auditor that audits transactions between contracting parties according to different sets of transaction rules. Each of the respective sets of transaction rules is defined as a function of a unique one of the plurality of distributors (e.g., defined with a distributor identification) and a business relationship (e.g., a contract) between the unique distributor and at least one of the contracting parties. A client-layer payment processor that facilitates payment for each audited transaction as a function of the client-layer auditor's audit of the transaction. That is, where the audit produces results upon which payment is to be authorized (e.g., the audit indicates that transaction conditions required for payment have been satisfied), the results can be used to authorize payment.
  • [0012]
    The system also includes distributor-layer functions including a distributor-layer controller that controls an implementation of the client-layer payment processor on behalf of each one of the plurality of distributors as a function of a business relationship (e.g., contract) between each distributor and the controller party. A distributor-layer payment processor assesses fees against each distributor for transactions processed on behalf of each distributor, and facilitates funds transfer to cover the assessed fee. Assessing fees against teach distributor involves, for example, assessing a fee against each transaction, with the fee being collected as directed by the distributor, which may involve the collection of a fee from a contracting party and/or from the facilitated payment.
  • [0013]
    The above summary of the present invention is not intended to describe each illustrated embodiment or every implementation of the present invention. The figures and detailed description that follow more particularly exemplify these embodiments.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0014]
    The invention may be more completely understood in consideration of the detailed description of various embodiments of the invention in connection with the accompanying drawings, in which:
  • [0015]
    FIG. 1 shows a transaction processing arrangement, according to an example embodiment of the present invention;
  • [0016]
    FIG. 2 shows an arrangement and approach for transaction management, according to another example embodiment of the present invention; and
  • [0017]
    FIG. 3 shows a flow diagram for transaction processing, according to another example embodiment of the present invention.
  • [0018]
    While the invention is amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not necessarily to limit the invention to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.
  • DETAILED DESCRIPTION
  • [0019]
    The present invention is believed to be applicable to a variety of different types of communications and financial process management approaches, and has been found to be particularly useful for applications involving the operational implementation and application of layered transaction processing rules and processes to transactions, payments and related aspects thereof. While the present invention is not necessarily limited to such approaches, various aspects of the invention may be appreciated through a discussion of various examples using these and other contexts.
  • [0020]
    According to an example embodiment of the present invention, a rules-based transaction approach is implemented with multiple distributor entities for automatically processing transactions for transaction parties. Each distributor facilitates transactions between transaction parties (e.g., buyers and/or sellers), where at least one of the transaction parties is a client of the distributor. A host processor manages transactions on behalf of each distributor, using transaction processing rules tailored to each distributor and, where appropriate, a particular transaction party, in processing that distributor's transactions. The host processor carries out processing aspects of transactions between two or more of the transaction parties as a function of the business rules for at least one distributor facilitating the transaction for a transaction party and, where appropriate, business rules for one or more of the transaction parties.
  • [0021]
    In some applications, the host processor carries out aspects of transactions between two or more transaction parties as a function of business rules for different distributors, where each of the different distributors facilitates transactions on behalf of at least one transaction party. In this regard, the host processor provides generally distinct financial processing functions for each distributor and, where appropriate, functions as a generally silent partner to the transaction, relative to each distributor's clients.
  • [0022]
    In another example embodiment of the present invention, a central transaction management system uses business rules (e.g., included in profile information) associated with distributors to process transactions between parties sponsored by the distributors. In some applications, the transaction parties are also sponsored by financial institution distributors, which facilitate the processing of financial aspects of transactions. Sponsoring, in this regard, may generally relate to an arrangement between a distributor and a client, wherein the client and distributor transact for processing aspects of transactions for merchant offerings (i.e., goods and/or services) between the client and another party. As relative to examples herein involving tiered transaction relationships, with a host processor operating transaction processing characteristics on behalf of a plurality of distributors, sponsored parties in that context refer to, e.g., clients of the distributors, the clients including transaction parties such as buyers and sellers as discussed above.
  • [0023]
    When the central transaction management system receives transaction information, the information is parsed for identifying characteristics that can be associated with sponsoring distributors. When these identifying characteristics match a particular distributor, the central transaction management system uses business rules for the distributor to process the financial transaction. In addition, when identifying characteristics for different parties to the transaction match different distributors, financial aspects of the transaction that are specific to each party are processed according to the each party's corresponding sponsoring distributor. Funds relating to the distributor are thus transferred according to the business rules associated with sponsoring distributor for each party and to the particular characteristics of the transaction.
  • [0024]
    In another implementation, the central transaction management system further uses business rules, associated with individual sponsored transaction parties, to process transactions involving the sponsored parties. Generally, each sponsoring distributor facilitates the gathering of business rules for the individual sponsored transaction parties, such as by directly soliciting the rules or by directing each party to supply business rules to the central transaction management system. Once the sponsored parties' business rules are established and made available to the central transaction management system (e.g., via storage local to and/or remote from the central transaction management system), transactions associated with a sponsored party are processed in accordance with those business rules.
  • [0025]
    When the central transaction management system receives transaction information, such as an invoice to be paid, that information is used to identify sponsoring distributors as well as the parties to the transaction. The transaction is then processed according to the business rules of the sponsoring distributors as well as the business rules of the sponsored parties to the transaction. These transaction party-specific business rules may be stored, for example, in a user profile that is accessible by the central transaction management system or separately under association with the specific sponsored transaction party to which the rules belong.
  • [0026]
    In some instances, the sponsoring distributor for a particular transaction party is identified as a function of the identity of the party and corresponding business rules for the party. For example, when a transaction party sets business rules to identify a particular sponsoring distributor, these business rules are implemented in selecting the sponsoring distributor. Correspondingly, the business rules for the distributor identified by the transaction party's business rules are used to process the transaction.
  • [0027]
    In other instances, two or more distributors specified by a particular party are included as participants in the transaction for one or more of a variety of functions. These specified distributors may include sponsoring and/or non-sponsoring distributors, and distributors of different types, such as transaction processing distributors and financial institutions. That is, a specified sponsoring distributor sponsors the particular party for management of transactions (via the central transaction management arrangement), where other specified distributors may be funds-providing institutions (e.g., banks), credit-issuing institutions, currency conversion institutions or others.
  • [0028]
    In applications involving multiple financial institutions for a common party, the central transaction management system interfaces with financial institutions in addition to each transaction party's sponsoring distributor. For instance, where a transaction party has primary banking functions with a non-sponsoring financial institution, a sponsoring financial institution, via the central transaction management system, facilitates the transaction by exchanging funds via the non-sponsoring financial institution. The sponsoring financial institution may further implement processing type fees via the central transaction management system, charged for facilitating the transaction.
  • [0029]
    In some instances, the central transaction management system interfaces directly with distributors that, from a hierarchical perspective, pass-through information received from one or more parties to the transaction. The central transaction management system uses transaction rules based on the transaction information received from a distributor. Effectively, the distributors use the central transaction management system to execute transaction-processing functions that are carried out using transaction-based rules specific to the particular distributor providing the transaction information.
  • [0030]
    In other instances, the central transaction management system is adapted to interface directly with parties to a transaction and to use transaction rules based on information received from one or more of the parties (i.e., without a sponsoring distributor). For example, a buyer or seller can interface with the central transaction management system using rules, implemented with the system, which are based on profile information for the particular buyer or seller. These parties may contract with a system administration entity, effectively acting as a sponsoring distributor in some regards, relative to the above discussion, to facilitate transactions in this manner.
  • [0031]
    In some implementations, the central transaction management system (or host processor as discussed earlier) works to keep separate the transaction rules for each distributor. Where appropriate, separate rules are also kept for transaction parties. Access to the transaction rules, and in general to the services of the central transaction management system, is restricted to the institution (or party) to which the rules belong. This restricted access approach may be implemented using, for example, encryption, passwords, tracking and other security-type measures typically implemented for data access and protection.
  • [0032]
    Business rules are stored using one or more of a variety of approaches. For example, a database accessible by a central transaction management system and having labels or other identifying characteristics that associate the business rules with a particular distributor can be used. This database can be physically local or remote to the central transaction management system, as long as the central transaction management system can access the database and control access to the database by other entities.
  • [0033]
    The administration processor (or the host processor) as discussed above can be implemented in a single location or across a variety of locations. Where appropriate, certain functionality of the central or host processor can be implemented at different accessible locations communicatively coupled to one another. In addition, functionality of the central or host processor can be implemented at various levels in transaction hierarchy, such as with a distributor or with transaction parties who are clients of and/or sponsored by distributors.
  • [0034]
    Turning now to the figures, FIG. 1 shows a transaction processing arrangement 100 including an administration processor 110 programmed to automatically process transaction information according to profiles corresponding to particular distributors, according to another example embodiment of the present invention. The administration processor 110 administratively controls transaction processor implementations for multiple processing distributors 120-N. The transaction processor implementations each carry out transaction processing services including financial services associated with transactions between transaction parties (i e., to facilitate payment for transactions).
  • [0035]
    Distributor profiles are stored for each processing distributor, with the administration processor 110 or with an accessible database 112, and used by the administration processor in carrying out transaction processing functions for the processing distributors. The database 112 is optionally coupled to (or part of) the administration processor 110 and further may include a plurality of data storage arrangements at different locations. The administration processor 110 maintains separate (and secure) storage for these profiles by restricting access to the profiles by the processing distributors (or others such as transaction parties). Typically, the distributor profiles and other programmed characteristics of the administration processor 110 implement rules associated with contracts between the processing distributors and an administration party 140 that operates the administration processor.
  • [0036]
    The administration processor 110 interacts with a multitude of client parties 130-i on behalf of the processing distributors 120-N, with interaction with each client party facilitated as a function of profiles and a transaction processor implementation for the particular processing distributor with which each client party is associated. That is, transaction data (e.g., transaction-based documents such as invoices or other financial documents) provided by clients of a particular processing distributor is automatically associated with the processing distributor. The association of transaction data (and thus clients) with a particular processing distributor may involve, for example, using identification information provided with the transaction data for directly identifying a processing distributor or for identifying the client party and in turn using information in the distributors for associating the identified client party with a processing distributor.
  • [0037]
    Each transaction processor implementation in the administration processor 110 can be tailored in function to the needs of a particular processing distributor for which the transaction processing implementation is administered. In this regard, a multitude of separate transaction processing functions are carried out in parallel with each other by the administration processor 110, with each transaction processing function generally distinct from other transaction processing functions. From a visual perspective, each of the client parties 130-i view transaction interaction with the administration processor as effective direct interaction with the processing distributor with which the client party is engaged in a contractual relationship for transaction processing services. Furthermore, where transaction processing services include financial services, financial aspects of transactions are implemented in a confidential and distinct manner, relative to other (non-transaction-party) processing distributors and their respective transaction processor implementations.
  • [0038]
    Using an example transaction between a buyer client party 130 and a seller client party i and where processing distributor 120 sponsors buyer client party 130, the administration processor 110 is transparent in transaction document exchange and other interaction between the client parties and the processing distributor 120. That is, interaction between clients and the transaction processor implementation for the processing distributor 120 is carried out in a manner as would be directly carried out with the processing distributor 120. All interactions in such a transaction are characterized by and carried out as a function of agreements between the administration party 140 and the processing distributor 120; further, these agreements (e.g., as characterized in the distributor profile for the processing distributor 120) contemplate specific transaction processing relationships between the processing distributor 120 and the buyer client party 130. In certain applications, the distributor profiles for the processing distributor 120 (or other processing distributors) include separate and specific profiles for each client of the particular processing distributor, with the specific client profiles used in the implementation of the transaction processor for the processing distributor.
  • [0039]
    Continuing with the example transaction in the previous paragraph, the transaction processor implementation for the processing distributor 120 facilitates payment from, or on behalf of, the buyer client party 130 to client party i. In some applications, the transaction processor implementation facilitates payment by paying the client party i and extending credit to the buyer client party 130. In other applications, the transaction processor implementation facilitates payment by interacting with a financial institution specified by the buyer client party 130 in its profile information. In still other applications, the transaction processor implementation facilitates payment at the direction of the processing distributor 120 (i.e., using information specified in its distributor profile).
  • [0040]
    Certain example embodiments involving the transaction processing arrangement 100 implement sub-distribution approaches, where one or more of the client parties 130-i distribute, or sponsor, involvement with the administration processor 110 to other clients. This approach may be applicable, for example, where a client of a particular processing distributor sponsors another transaction party for using the administration processor 110. For example, using an example where the client party 130 uses a transaction processor implementation for the processing distributor 130, client party 130 may sponsor other client parties into use of the transaction processor implementation where the other client parties are privy to a common contract with the client party 130. Such a situation may arise, for example, where client party 130 is a seller and sponsors a buyer client party into use of the transaction processor implementation for processing invoices related to the particular transaction. Another example involves an application where a particular client party acts as a processing distributor to one or more sub-client parties, e.g., where the sub-client parties enter into a transaction with each other. The examples discussed below in connection with FIG. 2 further exemplify applications where sub-distribution approaches are facilitated with a transaction processing system such as the system 100.
  • [0041]
    In addition to the above examples, each transaction processor implementation is selectively carried out in a variety of manners, tailored to specific processing distributors and/or generalized across different processing distributors. For general information regarding transaction processing approaches and for specific information regarding transaction processing implementations that carried out by the administration processor 110 in connection with various example embodiments, reference may be made to the following patent documents, each of which is fully incorporated herein by reference: U.S. Pat. No. 5,910,896, No. 6,571,149, No. 6,697,702 and No. 6,704,612, all to Hahn-Carlson; and U.S. patent application Ser. No. 10/436,878 (USBA.101PA).
  • [0042]
    In another example embodiment, the administration processor 110 maintains data for business rules and processed transactions over time for a variety of purposes, such as for generating reports, tracking compliance and for taking appropriate action where errors or non-compliance occurs. For example, when a particular transaction is processed or when business rules are changed, the central processor monitors associated information and stores and/or processes the monitored information for these purposes.
  • [0043]
    The user profiles and/or business rules discussed herein in connection with FIG. 1 above and otherwise may include a variety of information for use in transaction management and financial processing. For instance, in addition to the above-discussed approaches, a typical such profiles may include one or more of the following data: general ledger charts of accounts, identification of computer systems submitting contract or transaction data, customer lists, vendor lists, financial institution lists, contract and price approval policies, transactional approval policies, business rules, operational roles (e.g., defining what functions a user associated with that role can perform), organizational hierarchy (e.g., defining how much of a company's data a user associated with a particular organizational node can access), and individual users. Financial institution profiles may also include information further defining the business relationship with selected customers or other processing distributors and financial processing organizations from the financial institution's perspective.
  • [0044]
    In another example embodiment of the present invention, the administration processor 110 provides a user interface for each distributor and adapted for interfacing with contracting parties specified by the distributor. The administration processor 110, through the user interface, facilitates contracting party access to the system using profile information for the contracting party (e.g., user name and password as provided by the distributor), thus providing access to the administration processor 110 by any contracting party granted access by the distributor.
  • [0045]
    FIG. 2 shows an arrangement and approach 200 for transaction management among transaction parties in separate distributor and client layers, according to another example embodiment of the present invention. A transaction processing system 210 interfaces with a plurality of distributing institutions for facilitating transactions involving clients, on behalf of the distributing institutions. The transaction processing system 210 uses distributor data (and sometimes client data) stored in a database 220 for implementing rules for the transactions. These rules are used to process financial and other processing aspects of the transactions, relative to information received via distributors or directly from clients.
  • [0046]
    The hierarchical relationships generally shown in FIG. 2 among management, distributor, sub-distributor and client layers provide a conceptual view of the processing characteristics implemented by the transaction processing system 210, with clients and sub-distributors (seemingly, at least) interacting via distributors. However, in many applications, clients and/or sub-distributors communicate directly with the transaction processing system 210, which provides a transaction interface managed on behalf of each distributor via which the clients and/or sub-distributors are sponsored into the transaction processing system 210. In some applications, interaction with the transaction processing system 210 appears, to each user, relative to interaction directly with its distributor or sub-distributor, with virtual walls controllably implemented at the transaction processing system 210 to ensure confidentiality and integrity relative to data being processed.
  • [0047]
    Distributors in the distributor layer and/or sub-distributor layer distribute processing functions of the transaction processing system 210 to clients in the client layer. The distributors may, for example, distribute transaction functions such as those related to the automatic processing of orders, invoices, shipment documents and financial transfer and/or credit functions. Referring to FIG. 1 as an example, the function of the administration processor 110 can be implemented with the transaction processing system 210, with the separate transaction processor implementations shown respectively implemented for the different distributor and, where applicable, sub-distributor parties.
  • [0048]
    By way of example, distributors shown include transaction processing Distributors A and B respectively at nodes 232 and 234, and financial distributors Bank A and B respectively at nodes 230 and 236. Bank A (230 provides financial processing functions, via the transaction processing system 210, to clients 1-N. The transaction processing distributors 232 and 234 provide, via the transaction processing system 210, transaction processing functions respectively to sub-distributors 1-2, clients A-i and, via sub-distributors 1-2, sub-clients A, B, 1 and 2. Bank B (236) distributes processing functions to banks including sub-banks 1 and 2, which in turn provide financial processing functions for sub-clients C, D, 3, and 4. While not shown, one or both of the distributor 232 and bank 236 may provide services both to sub-distributor entities as well as client entities.
  • [0049]
    Generally, fees are associated with transaction processing functions carried out by the transaction processing system 210 on behalf of distributors and sub-distributors, either directly as part of the transactions (e.g., by assessing a fee related to the processing of payment for a transaction) or by charging a fee based on use or other non-transaction specific basis. The fees may be separately assessed to one or more of the distributors, sub-distributors, clients or sub-clients, depending upon the particular transaction and any arrangement with the parties to the transaction, as defined in profiles, contract information or other data stored in the database 220. In addition, a source for the fees can also be defined in profiles stored in the database 220, and used together with authorization information to draw the fees.
  • [0050]
    For example, where distributor B (234) contracts with client A to process transactions on that client's behalf, an agreement between distributor B and client A is implemented by the transaction processing system 210 to assess a fee for transaction services rendered to client A. This fee may be transaction finance-based (e.g., a percentage of a financial transfer related to the transaction), based on a flat-fee service or otherwise implemented. Distributor B further is assessed a fee by the transaction processing system 210 for the services rendered thereby. In some applications, the fees are assessed and paid separately. In other instances, the transaction processing system 210 assesses fees directly to client A, withholds a portion of those fees owed by distributor B to the transaction processing system 210 and pays a remaining portion of the fees to the distributor B. In still other instances, fees assessed to client A (and other clients sponsored by distributor B) are paid directly to distributor B with a separate fee assessment carried out for paying for processing functions provided for distributor B, as a function of contract terms between distributor B and the transaction processing system 210.
  • [0051]
    In some example embodiments, the transaction processing system 210 is further adapted to interact with financial institutions for payment and/or settlement functions relating to transactions involving clients sponsored by distributors. For example, where Sub-bank 1 sponsors sub-client C into a transaction as a buyer purchasing goods from sub-client D (e.g., sponsored directly by the bank or by association with a transaction involving sub-client C), payment is effected to sub-client D with associated settlement extracted from sub-client C. Financial institutions for sub-clients C and D are used for these purposes, with funds transfer either happening directly between the financial institutions or via the transaction processing system 210, which may hold back a particular fee for the transaction and/or provide credit via which payment is made to sub-client D's financial institution on behalf of sub-client C. Where credit is provided, credit extension fees are assessed where designated by profiles or other processing rules, in addition to transaction-based fees. Information specifying such financial institutions from which payment may be drawn is stored in the database 220 in connection with profile information (and/or business rules) relating to each transaction and/or parties to the transaction.
  • [0052]
    In some applications, credit is provided by the transaction processing system 210 using an underwriting approach. The transaction processing system 210 (e.g., using a client-layer type auditor such as an auditor engine 250 as discussed below) audits a transaction between buyer and seller clients as a function of a credit term relating to the buyer and transaction rules specified by the controller party. Using the audit, the transaction processing system 210 is underwrites a cash flow from the buyer to the seller on behalf of the a controller party (e.g., a distributor) as a function of the audit. Fees for the underwriting are added to those fees assessed by the transaction processing system 210 for facilitating the transaction.
  • [0053]
    In another set of example embodiments, the transaction processing system 210 is adapted to facilitate credit extension to clients and/or distributors. In some embodiments, the transaction processing system 210 extends the credit directly (acting as a credit issuing institution), providing funds for use in payment and/or settlement functions for transactions. In other embodiments, the transaction processing system 210 indirectly facilitates the provision of funds, e.g., using outside financial institutions specified by clients and/or distributors. Where the transaction processing system 210 extends credit to clients via financial distributors, the credit extension, tracking and other processing functions are carried out using profile information for the financial distributors (e.g., stored in the database 220).
  • [0054]
    In some applications, the transaction processing system 210 is configured for settling financial institution issues relating to fees and/or other transaction characteristics. When a buyer and seller enter into a transaction, the transaction processing system 210 calculates the amount of funds to be collected from the buyer's bank and remitted to the seller's bank (e.g., where one or both banks function in the distributor layer). These funds are used to fund the payment that the seller's bank will make to the seller for all transactions that achieve payable status within a particular payment period (e.g., a network day) for the transaction processing system 210.
  • [0055]
    Once the amount of funds to be collected are determined, the transaction processing system 210 further acts to facilitate the collection of these funds in one or more of a variety of manners. For instance, the transaction processing system 210 may simply make the amount of funds known to parties to the transaction using conventional communications methods. In other instances, the transaction processing system 210 actively facilitates collection of these funds, at both payment and settlement aspects of transactions, e.g., as discussed above.
  • [0056]
    In one example, an electronic payment demand is submitted on an interval (e.g., at least daily) to the buyer's bank for all net monies due either to the transaction processing system or to the seller's bank when the buyer's bank has net funds due. An electronic payment demand is also submitted on an interval to the seller's bank for all net monies due either to the transaction processing system or to the buyer's bank when the seller's bank has net funds due. In addition, an electronic payment notice is submitted on an interval (e.g., at least daily) to the buyer's bank for all net monies due to the buyer's bank. The net monies due are contemplated after subtraction of funds due to either the transaction processing system or the seller's bank when the buyer's bank has net funds due. An electronic payment notice is also submitted to the seller's bank for all net monies due to the seller's bank. Similarly as above, these net monies due are contemplated after subtraction of funds due to either the transaction processing system or the buyer's bank when the seller's bank has net funds due.
  • [0057]
    Access to information at the database 220 is controlled in one or more of a variety of manners, with information made available to users selectively and in a variety of formats, depending upon the implementation. Various examples using this general approach are discussed below.
  • [0058]
    In one example embodiment, each distributor has access to the transactions naming their clients. By enabling such access, each distributor institution is granted access to perform customer service functions related to transaction processing for their clients within the transaction processing system. In addition, each distributor can maintain an overview of their net position with each of their customers to whom they are providing processing functions and, in some applications, issuing credit.
  • [0059]
    Financial distributors issuing credit to either buyers or sellers can also specify where credit-related information is retrieved from for use in a transaction. For example, the location from which credit drawdown advice is to be delivered can be specified. In addition, credit-issuing financial institutions can specify whether the drawdown advice is to include transaction details or simply be the aggregate of the transaction details for the reporting period. For the latter case, the transaction processing system 210 can be specified to be used as the detailed subledger to support the credit usage. In this sense, the transaction processing system 210 functions much like conventional credit-issuing institutions (including credit card issuing institutions), with the credit issuer being provided summary or detail information.
  • [0060]
    A variety of security-related functions are implemented with the transaction processing system 210, depending upon the application and the desired level of security. For example, in some implementations, data flowing to the transaction processing system 210 from distributors and/or clients is encrypted using standard encryption technologies. Similarly, data flowing from the transaction processing system 210 to distributors and/or clients can also be encrypted using standard encryption technologies. Communications between any distributed computing devices and the transaction processing system 210 can also be encrypted using standard encryption technologies. For instance, where transaction functions for different distributors are carried out at physically different locations, communication between these system implementations and the transaction processing system 210 is encrypted.
  • [0061]
    In addition to security-related functions for transaction communications, access to data within the transaction processing system 210 can also be controlled using security measures. For instance, profiles stored in the database 220 may include security type information, such as password and/or encryption information that users accessing the transaction processing system 210 may employ.
  • [0062]
    In another example embodiment of the present invention, a fee-based distributed transaction processing system is implemented for processing transactions between buyers and sellers with a sponsoring processing distributor setting business rules (e.g., contract information) by which the transactions are processed. This system may be implemented, for example, in connection with the administration processor 100 in FIG. 1 and/or with the transaction processing system 210 in FIG. 2, discussed above. FIG. 2 shows an association engine 240, an auditor engine 250 a transaction payment processor 260 and a fee processor 270 that are selectively implemented in connection with similar functions described in the following approach with the fee-based system. In this regard, selective references are made below to FIG. 2.
  • [0063]
    The fee-based system includes a data storage arrangement having at least one distinct database, and in some applications two or more databases at distinct or common locations. The data storage arrangement stores business rules for a multitude of transactions involving distinct transaction parties including buyers, sellers and processing distributors, and also stores user profiles for the transaction parties. The processing distributors sponsor at least one of a buyer and a seller for each transaction. In this regard, the fee-based system implements transaction processing for sponsoring distributors, for transactions executed between a buyer and a seller.
  • [0064]
    A transaction processing controller (e.g., transaction processing system 210) interacts with the distinct transaction parties for receiving profile information specified by the transaction parties, e.g., with each transaction party providing information such as a funds source, authorization for extracting or otherwise transferring funds and, where appropriate, rules by which transactions can be audited for payment approval. The transaction processing controller also interacts with the processing distributors for receiving business rules as specified by each processing distributor, and store the received profile information and business rules in the data storage arrangement.
  • [0065]
    An association engine (e.g., association engine 240) receives and associates transaction payment data with a processing distributor as a function of stored profile information for parties to a transaction to which the transaction payment data applies. That is, when transaction payment data such as an electronic invoice is received, the association engine accesses the data storage arrangement to retrieve profile information that can be used to associate the electronic invoice with a particular transaction. That association is used to retrieve business rules applicable to the particular transaction.
  • [0066]
    An auditor engine (e.g., auditor engine 250) audits payment of the received transaction payment data using business rules retrieved from the data storage arrangement as associated with a processing distributor by the association engine. For example, where business rules specify that payment for a transaction is to be authorized when receipt of goods and/or services is acknowledged, the auditor engine may use such a receipt (e.g., received from a buyer party) together with the business rules to audit payment of the transaction.
  • [0067]
    A transaction payment processor (e.g., transaction payment processor 260) uses an audit result together with profile information for at least one party to the transaction to facilitate payment for each audited transaction. For example, where the audit result includes a payment authorization, profile information specifying a financial institution account from which to draw payment or from which to draw down a credit line is used as a source of funds, with authorization information specified in the profile information used to access the funds.
  • [0068]
    The system also includes a fee payment processor (e.g., fee processor 270) that assess a fee against the distributor sponsoring a transaction party for each transaction, and that facilitates payment for the assessed fee, e.g., in a manner similar to that discussed in connection with the facilitation of payment by the transaction payment processor above. In some applications, the fee is assessed directly against the distributor, and in other applications, the fee is assessed against one or more parties to each transaction. In addition, the amount of the fee may be set in accordance with an agreement between an operator of the system and the distributor against whom the fee is assessed, and/or assessed as a percentage of a financial amount of the transaction.
  • [0069]
    In some applications, the transaction payment processor extends credit for payment of the transaction on behalf of one or more transaction parties. For example, the credit rating of a distributor sponsoring a particular transaction is selectively used (as dictated by business rules) to extend credit on behalf of a particular buyer when facilitating payment to a seller. Similarly, the credit rating of a seller is selectively implemented for extending credit on behalf of a buyer, to that seller. In a more direct approach, the credit rating of a buyer is used to extend credit to that buyer, for payment to a seller for a particular transaction. One or more of these approaches are thus selectively implemented, as indicated in appropriate transaction profiles.
  • [0070]
    In connection with the above example fee-based system, one or more of the association engine 240, auditor engine 250, transaction payment processor 260 and fee processor 270 are selectively implemented in connection with similar functions described in connection with other embodiments discussed herein. For example, the auditor engine 250 is selectively implemented with a client-layer auditor functions for processing transactions between clients on behalf of a distributor. The transaction payment processor 260 is selectively implemented with client-layer and/or distributor-layer payment processing functions for facilitating payment and/or for assessing fees for such transactions. The transaction processing system 210, in connection with one or more of the auditor engine and transaction payment processor 260, is selectively implemented with distributor-layer controller functions.
  • [0071]
    FIG. 3 shows a flow diagram for transaction processing involving the association of a particular distributor with a transaction, according to another example embodiment of the present invention. At block 310, transaction data having transaction identification information is received from a client node, such as a client computer system or a distributor computer system (passing through client transaction information). The transaction identification information may include identification data that pertains, for example, to a particular client party to the transaction, to a distributor or to other identification information specific to the particular transaction to which it applies. At block 320, the transaction data is compared with distributor identification data. If no match between the transaction data and a distributor is found at block 330, a failure notice is returned to a sender of the transaction data at block 335, indicating that the transaction cannot be processed.
  • [0072]
    If a match between the transaction data and a distributor is found at block 330, transaction processing data corresponding to the match is loaded at block 340. In some instances, this loaded transaction processing information includes information exclusively provided by a distributor that is the subject of the match. In other instances, the loaded transaction processing data includes information for parties to the transaction in addition to the distributor that is the subject of the match (e.g., for specifying user preferences or profiles as discussed above). After the transaction processing data has been loaded, it is used to process the transaction data at block 350 for facilitating processing aspects of the transaction, such as by storing data, auditing invoices or approving payment.
  • [0073]
    While certain aspects of the present invention have been described with reference to several particular example embodiments, those skilled in the art will recognize that many changes may be made thereto without departing from the spirit and scope of the present invention, aspects of which are set forth in the following claims.
Citations de brevets
Brevet cité Date de dépôt Date de publication Déposant Titre
US4507778 *29 oct. 198226 mars 1985Fuji Xerox Co., Ltd.Digital transmission system
US4567359 *24 mai 198428 janv. 1986Lockwood Lawrence BAutomatic information, goods and services dispensing system
US4725719 *21 juil. 198616 févr. 1988First City National Bank Of AustinRestricted purpose, commercial, monetary regulation method
US4799156 *1 oct. 198617 janv. 1989Strategic Processing CorporationInteractive market management system
US4992940 *13 mars 198912 févr. 1991H-Renee, IncorporatedSystem and method for automated selection of equipment for purchase through input of user desired specifications
US4995112 *30 juin 198919 févr. 1991Kabushiki Kaisha ToshibaSecurity system
US4996662 *3 oct. 198326 févr. 1991Wang Laboratories, Inc.Method for generating document using tables storing pointers and indexes
US5008827 *16 déc. 198816 avr. 1991Pitney Bowes Inc.Central postage data communication network
US5285383 *15 oct. 19918 févr. 1994Plains Cotton Cooperative AssociationMethod for carrying out transactions of goods using electronic title
US5293310 *22 mai 19928 mars 1994Pitney Bowes Inc.Flexible method for applying customized rating adjustments to transaction charges
US5393963 *17 mars 199228 févr. 1995Company Chex, Inc.Check authorization system and process
US5483445 *21 oct. 19939 janv. 1996American Express TrsAutomated billing consolidation system and method
US5485369 *28 sept. 199316 janv. 1996Tandata CorporationLogistics system for automating tansportation of goods
US5500513 *11 mai 199419 mars 1996Visa InternationalAutomated purchasing control system
US5712990 *3 oct. 199127 janv. 1998International Technology Corporation Of CaliforniaEconomical automated process for averting physical dangers to people, wildlife or environment due to hazardous waste
US5717989 *13 oct. 199410 févr. 1998Full Service Trade System Ltd.Full service trade system
US5719771 *1 déc. 199517 févr. 1998Amsc Subsidiary CorporationSystem for mapping occurrences of conditions in a transport route
US5732400 *4 janv. 199524 mars 1998Citibank N.A.System and method for a risk-based purchase of goods
US5870719 *3 juil. 19969 févr. 1999Sun Microsystems, Inc.Platform-independent, usage-independent, and access-independent distributed quote configuraton system
US5892900 *30 août 19966 avr. 1999Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protection
US5893080 *25 juil. 19956 avr. 1999Bottomline Technologies, Inc.Disbursement system and method
US5896530 *18 janv. 199520 avr. 1999Sterling Software, Inc.Portable and dynamic distributed applications architecture
US5897645 *22 nov. 199627 avr. 1999Electronic Data Systems CorporationMethod and system for composing electronic data interchange information
US6012041 *28 févr. 19974 janv. 2000I.S.R. (Logistics) LimitedApparatus for the control of inventory
US6016477 *18 déc. 199718 janv. 2000International Business Machines CorporationMethod and apparatus for identifying applicable business rules
US6021202 *19 déc. 19971 févr. 2000Financial Services Technology ConsortiumMethod and system for processing electronic documents
US6026374 *30 mai 199615 févr. 2000International Business Machines CorporationSystem and method for generating trusted descriptions of information products
US6029140 *10 mai 199922 févr. 2000Micron Technology, Inc.On-time delivery, tracking and reporting
US6029150 *4 oct. 199622 févr. 2000Certco, LlcPayment and transactions in electronic commerce system
US6043819 *1 juil. 199728 mars 2000Digital Image Systems, CorpImage based document processing and information management system and apparatus
US6044362 *8 sept. 199728 mars 2000Neely; R. AlanElectronic invoicing and payment system
US6047268 *4 nov. 19974 avr. 2000A.T.&T. CorporationMethod and apparatus for billing for transactions conducted over the internet
US6055519 *11 oct. 199725 avr. 2000I2 Technologies, Inc.Framework for negotiation and tracking of sale of goods
US6169542 *14 déc. 19982 janv. 2001Gte Main Street IncorporatedMethod of delivering advertising through an interactive video distribution system
US6199046 *29 juil. 19976 mars 2001Adsura Pty Ltd.Method system and article of manufacture for performing real time currency conversion
US6204763 *22 mars 199920 mars 2001Jujitsu LimitedHousehold consumable item automatic replenishment system including intelligent refrigerator
US6209095 *31 août 199927 mars 2001Financial Services Technology ConsortiumMethod and system for processing electronic documents
US6223168 *30 déc. 199824 avr. 2001Bottomline Technologies, Inc.Automatic remittance delivery system
US6338044 *17 mars 19998 janv. 2002Loudeye Technologies, Inc.Personal digital content system
US6357042 *22 janv. 199912 mars 2002Anand SrinivasanMethod and apparatus for multiplexing separately-authored metadata for insertion into a video data stream
US6366829 *6 oct. 19982 avr. 2002J. P. Donmoyer, Inc.Bulk inventory network system (BINS)
US6381587 *2 avr. 199830 avr. 2002Citibank, N.A.Method and system for standardizing and reconciling invoices from vendors
US6505169 *26 janv. 20007 janv. 2003At&T Corp.Method for adaptive ad insertion in streaming multimedia content
US6505172 *22 mars 20007 janv. 2003Eplus Inc.Electronic sourcing system
US6507826 *29 janv. 199914 janv. 2003Koriel, Inc.Remote electronic invoice entry and validation system and method therefor
US6510383 *1 mars 200021 janv. 2003Arrivalstar, Inc.Vehicular route optimization system and method
US6510384 *15 nov. 200121 janv. 2003International Business Machines CorporationRoute search system and route search method
US6526443 *12 mai 199925 févr. 2003Sandia CorporationMethod and apparatus for managing transactions with connected computers
US6539360 *5 févr. 199925 mars 2003United Parcel Service Of America, Inc.Special handling processing in a package transportation system
US6673479 *15 mars 20016 janv. 2004Hydrogenics CorporationSystem and method for enabling the real time buying and selling of electricity generated by fuel cell powered vehicles
US6684384 *28 mars 199727 janv. 2004International Business Machines CorporationExtensible object oriented framework for general ledger
US6687713 *20 mars 20013 févr. 2004Groupthink Unlimited, Inc.Budget information, analysis, and projection system and method
US6697702 *10 mars 200024 févr. 2004U.S. BancorpShipment transaction system and an arrangement thereof
US6704612 *12 mai 19999 mars 2004U.S. BancorpTransaction validation system for auditing and method
US6721613 *30 mars 199913 avr. 2004Fujitsu LimitedJournal form managing method, transaction processing apparatus, and transaction record journal form
US6721715 *21 déc. 199813 avr. 2004Martin A. NemzowMethod and apparatus for localizing currency valuation independent of the original and objective currencies
US6850900 *19 juin 20001 févr. 2005Gary W. HareFull service secure commercial electronic marketplace
US6873963 *30 nov. 199929 mars 2005Daimlerchrysler CorporationShipment tracking analysis and reporting system (STARS)
US6873997 *4 août 200029 mars 2005Agile Software CorporationData management system and method for automatically propagating information to disparate information systems from a central location
US6879962 *15 sept. 199912 avr. 2005Joseph D. SmithLogistics system and method
US6882983 *5 févr. 200119 avr. 2005Notiva CorporationMethod and system for processing transactions
US6882986 *7 août 200019 avr. 2005TymetrixMethod for automatic processing of invoices
US6983278 *10 avr. 20023 janv. 2006Arena Solutions, Inc.System and method for access control and for supply chain management via a shared bill of material
US6988111 *29 nov. 200117 janv. 2006I2 Technologies Us, Inc.Mapping between part numbers that are based on different part numbering schemes
US6999943 *10 mars 200014 févr. 2006Doublecredit.Com, Inc.Routing methods and systems for increasing payment transaction volume and profitability
US7162458 *30 oct. 20009 janv. 2007Sky Technologies, LlcSystem and method for process mining
US7177836 *30 déc. 199913 févr. 2007First Data CorporationMethod and system for facilitating financial transactions between consumers over the internet
US7324976 *19 juil. 200429 janv. 2008Amazon Technologies, Inc.Automatic authorization of programmatic transactions
US7327952 *22 juil. 20055 févr. 2008Pentax CorporationStage apparatus and camera shake correction apparatus using the stage apparatus
US7340433 *27 juil. 20004 mars 2008Orbian Management LimitedSystem and method of transaction settlement using trade credit
US7346575 *7 janv. 200218 mars 2008First Data CorporationSystems and methods for selectively delaying financial transactions
US7475024 *13 déc. 20006 janv. 2009Microsoft CorporationSystem and method for distributing in real-time, inventory data acquired from in-store point of sale terminals
US7496519 *12 mai 200324 févr. 2009U.S. Bank National AssociationAutomated transaction processing system and approach
US7499875 *22 mai 20003 mars 2009Ebay Inc.Method and apparatus for facilitating online payment transactions in a network-based transaction facility using multiple payment instruments
US7660788 *19 sept. 20039 févr. 2010E2Open, Inc.Mapping part numbers and other identifiers
US7890395 *19 mai 200515 févr. 2011Turnberry Partners, LPMethod and system for processing tax pertaining to a goods and services transaction
US8103575 *27 mars 200624 janv. 2012Icap Services North America LlcSystem and method for use in auditing financial transactions
US8126785 *3 mai 200528 févr. 2012Syncada LlcAutomated transaction accounting processing engine and approach
US8392285 *22 déc. 20055 mars 2013Syncada LlcMulti-supplier transaction and payment programmed processing approach with at least one supplier
US20010049657 *3 janv. 20016 déc. 2001Wang Erh-Chiao C.Method, apparatus and system of merchandise hierarchical online ordering, billing and distribution
US20020007302 *16 janv. 200117 janv. 2002Work Bruce V.Method and apparatus for tracking vendor compliance with purchaser guidelines and related method for the commercial distribution of software and hardware implementing same
US20020016765 *10 juil. 20017 févr. 2002David SacksSystem and method for third-party payment processing
US20020026374 *1 mai 200128 févr. 2002Moneymaker Vincent B.Comprehensive third-party transactional processing and payment in an online environment
US20020032649 *11 avr. 200114 mars 2002Balamurugan SelvarajanHigh-security E-currency IDs for E-commerce transactions
US20020035488 *3 avr. 200121 mars 2002Anthony AquilaSystem and method of administering, tracking and managing of claims processing
US20020038277 *30 juil. 200128 mars 2002Yuan Frank S.Innovative financing method and system therefor
US20020038305 *29 nov. 200128 mars 2002Bottomline Technologies (De) Inc.Automated invoice receipt and management system
US20020040304 *1 oct. 20014 avr. 2002Subrao ShenoyMethods and systems for creating and managing capital asset business exchanges
US20020042782 *6 avr. 200111 avr. 2002International Business Machines CorporationSystem and method for generating a contract and conducting contractual activities under the contract
US20020046081 *5 oct. 200118 avr. 2002International Business Machines CorporationSystem and method for workflow control of contractual activities
US20020046125 *26 mars 200118 avr. 2002Charles SpeicherSystems and methods for correcting supply/demand imbalances in multi-tier exchanges
US20020046147 *6 mars 200118 avr. 2002Livesay Jeffrey A.Method and process for providing relevant data, comparing proposal alternatives, and reconciling proposals, invoices, and purchase orders with actual costs in a workflow process
US20020046169 *13 nov. 200118 avr. 2002Cardinalcommerce CorporationSecure and efficient payment processing system
US20020048369 *10 sept. 200125 avr. 2002Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protection
US20020049622 *26 avr. 200125 avr. 2002Lettich Anthony R.Vertical systems and methods for providing shipping and logistics services, operations and products to an industry
US20020184101 *2 mars 20015 déc. 2002Gidadhubli Rajiv RaghavendraraoMethod and apparatus for integrating with multiple application systems
US20030018563 *13 juil. 200123 janv. 2003Efficient Capital CorporationTrading and processing of commercial accounts receivable
US20040002903 *19 mai 20031 janv. 2004IprivacyElectronic purchase of goods over a communications network including physical delivery while securing private and personal information of the purchasing party
US20040010463 *12 mai 200315 janv. 2004Hahn-Carlson Dean W.Automated transaction processing system and approach
US20040039693 *11 juin 200326 févr. 2004First Data CorporationValue processing network and methods
US20050021363 *22 juil. 200427 janv. 2005Stimson Gregory F.Debit card per-transaction charitable contribution
Référencé par
Brevet citant Date de dépôt Date de publication Déposant Titre
US77253724 oct. 200725 mai 2010Syncada LlcTransaction payables processing system and approach
US8010450 *19 mai 200830 août 2011GE Corporate Finanical Services, Inc.Systems and methods for processing commercial financial transactions
US839228522 déc. 20055 mars 2013Syncada LlcMulti-supplier transaction and payment programmed processing approach with at least one supplier
US839681117 mars 200012 mars 2013Syncada LlcValidation approach for auditing a vendor-based transaction
US85604399 juin 200515 oct. 2013Syncada LlcTransaction processing with core and distributor processor implementations
US858926826 juin 200919 nov. 2013Syncada LlcFinancial institution-based transaction processing system and approach
US859509926 juin 200926 nov. 2013Syncada LlcFinancial institution-based transaction processing system and approach
US865011929 mars 201011 févr. 2014Syncada LlcOrder-resource fulfillment and management system and approach
US87128844 oct. 200729 avr. 2014Syncada LlcTransaction finance processing system and approach
US875133725 janv. 200810 juin 2014Syncada LlcInventory-based payment processing system and approach
US87622389 juin 200524 juin 2014Syncada LlcRecurring transaction processing system and approach
US882554925 juin 20092 sept. 2014Syncada LlcTransaction processing with core and distributor processor implementations
US9299049 *15 mars 201329 mars 2016Sap SeContract-based process integration
US20050283434 *9 juin 200522 déc. 2005Hahn-Carlson Dean WRecurring transaction processing system and approach
US20060167762 *22 déc. 200527 juil. 2006Hahn-Carlson Dean WMulti-supplier transaction and payment programmed processing approach with at least one supplier
US20080086396 *4 oct. 200710 avr. 2008Hahn-Carlson Dean WTransaction Finance Processing System and Approach
US20080086397 *4 oct. 200710 avr. 2008Hahn-Carlson Dean WTransaction Payables Processing System and Approach
US20080172314 *9 juin 200517 juil. 2008Hahn-Carlson Dean WFinancial institution-based transaction processing system and approach
US20090171727 *4 mars 20092 juil. 2009U.S. Bank National AssociationProcessing and management of transaction timing characteristics
US20090192922 *25 janv. 200830 juil. 2009Hahn-Carlson Dean WInventory-based payment processing system and approach
US20090265274 *26 juin 200922 oct. 2009U.S. Bank National AssociationAutomated Transaction Processing System and Approach with Currency Conversion
US20090287590 *26 juin 200919 nov. 2009U.S. Bank National AssociationMulti-Supplier Transaction and Payment Programmed Processing System and Approach
US20090287593 *19 mai 200819 nov. 2009Shauna Michelle PalmerSystems and methods for processing commercial financial transactions
US20090287598 *26 juin 200919 nov. 2009U.S. Bank National AssociationFinancial Institution-Based Transaction Processing System and Approach
US20100017315 *21 juil. 200921 janv. 2010Hahn-Carlson Dean WResource-allocation processing system and approach with adaptive-assessment processing
US20100070397 *21 juil. 200918 mars 2010Hahn-Carlson Dean WResource-allocation processing system and approach with resource pooling
US20100287630 *17 mars 201011 nov. 2010Vaxdesign Corp.Models for vaccine assessment
US20110004552 *15 sept. 20106 janv. 2011Visa U.S.A., Inc.Method and system for conducting a commercial transaction between a buyer and a seller
US20110029404 *24 mai 20103 févr. 2011Hahn-Carlson Dean WTransaction payables processing system and approach
US20140278814 *15 mars 201318 sept. 2014Sap AgContract-based process integration
Classifications
Classification aux États-Unis705/39
Classification internationaleG06Q40/00, G06Q20/00
Classification coopérativeG06Q40/02, G06Q40/00, G06Q20/02, G06Q20/10, G06Q20/12, G06Q30/06
Classification européenneG06Q40/02, G06Q20/02, G06Q20/10, G06Q30/06, G06Q20/12
Événements juridiques
DateCodeÉvénementDescription
8 sept. 2005ASAssignment
Owner name: U.S. BANCORP LICENSING, INC., MINNESOTA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HAHN-CARLSON, DEAN W.;REEL/FRAME:016752/0481
Effective date: 20050727
11 févr. 2008ASAssignment
Owner name: U.S. BANK NATIONAL ASSOCIATION, MINNESOTA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:U.S. BANCORP LICENSING, INC.;REEL/FRAME:020492/0862
Effective date: 20080211
Owner name: U.S. BANK NATIONAL ASSOCIATION,MINNESOTA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:U.S. BANCORP LICENSING, INC.;REEL/FRAME:020492/0862
Effective date: 20080211
18 sept. 2009ASAssignment
Owner name: SYNCADA LLC, MINNESOTA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:U.S. BANK NATIONAL ASSOCIATION;REEL/FRAME:023254/0091
Effective date: 20090701
Owner name: SYNCADA LLC,MINNESOTA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:U.S. BANK NATIONAL ASSOCIATION;REEL/FRAME:023254/0091
Effective date: 20090701