EP1483713A2 - Apparatus and method of a distributed capital system - Google Patents

Apparatus and method of a distributed capital system

Info

Publication number
EP1483713A2
EP1483713A2 EP03716029A EP03716029A EP1483713A2 EP 1483713 A2 EP1483713 A2 EP 1483713A2 EP 03716029 A EP03716029 A EP 03716029A EP 03716029 A EP03716029 A EP 03716029A EP 1483713 A2 EP1483713 A2 EP 1483713A2
Authority
EP
European Patent Office
Prior art keywords
user
financial
fransaction
transaction
party
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.)
Ceased
Application number
EP03716029A
Other languages
German (de)
French (fr)
Other versions
EP1483713A4 (en
Inventor
Zachary Pessin
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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to EP11174447A priority Critical patent/EP2400453A1/en
Publication of EP1483713A2 publication Critical patent/EP1483713A2/en
Publication of EP1483713A4 publication Critical patent/EP1483713A4/en
Ceased legal-status Critical Current

Links

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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • 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
    • 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
    • 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
    • G06Q20/102Bill distribution or payments
    • 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/38Payment protocols; Details thereof
    • G06Q20/381Currency conversion
    • 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/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • G06Q20/4016Transaction verification involving fraud or risk level assessment in transaction processing
    • 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/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403Solvency checks
    • 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/06Buying, selling or leasing transactions
    • G06Q30/08Auctions
    • 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03Credit; Loans; Processing thereof
    • 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06Asset management; Financial planning or analysis

Definitions

  • the present invention relates generally to an apparatus and method of an automated distributed finance or capital system which can perform a plurality of financial transactions over a global computerized network.
  • the present invention relates to an apparatus and method of an automated distributed capital system which can perform a plurality of financial transactions over a global computerized network.
  • the distributed capital system (DCS) of the present invention can manage transactions that fall under two broad categories: Traditional (Individual), and Collaborative (Multiparty). These two categories cover the transaction spectrum, and the DCS of the present invention detailed herein covers the assembly, testing, execution, and management of transaction events (such as bill payment, foreign currency exchange etc.), which are unique.
  • the DCS of the present invention handles, among other transactions: bill payment structuring, management, and execution; invoicing structuring, management and execution; funds transfer initiation and management; distributed (dispersed) funds transfer (DFT) initiation and management, including repatriation of funds without international transfer; direct exchange of fungible units, whether symmetric (i.e., parties on each side of transaction hold equivalent value, to be exchanged in full with opposite counte ⁇ arty) or asymmetric (parties on each side of transaction hold different value amounts) - specifically curcencies, between parties worldwide (without intermediary brokers or 3 rd party financial institutions); automated foreign exchange market; programmed credit card payment scheduling; avoidance of the payment of ATM fees worldwide; on-line purchasing transactions in different currencies without requiring traditional currency-exchange transaction; a consumer credit and direct lending system; a distributed credit-rating system; a syndication system that handles micro-to-massive amounts from unlimited participants; and programmed speculative investing individually or in collaboration with others.
  • DFT distributed funds transfer
  • aspects of the present invention relate to an automated distributed capital system that can perform a plurality of financial transactions over a computer network, such as the Internet.
  • the distributed capital system (DCS) of the present invention manages any type of financial transaction between any number of parties. Therefore, for example, if a party desires to execute a financial transaction for a certain monetary or exchange value and the first counter-party cannot execute the transaction for the full monetary or exchange value, the DCS of the present invention automatically obtains additional counter-parties until the transaction can be fully executed. Accordingly, as long as there is enough value distributed among the various parties on the network, the DCS of the present invention can execute financial transactions for any value.
  • the party initiating the financial transaction can choose the counter-parties or the DCS of the present invention can automatically obtain those counter-parties.
  • the counter-parties can be located anywhere on the network. Therefore, if the network is for example the Internet, methods and systems consistent with the present invention are not limited to geographical boundaries.
  • the DCS of the present invention can execute transactions between parties in various countries, and automatically exchange the respective exchange currencies.
  • the distributed capital system allows any number of parties to collaboratively transact any amount of value with any number of counter-parties, arranging for independently market-driven rates and terms and handling the transfer of value. This is performed without, for example, an intermediary such as a broker. Since there can be any number of parties and counter-parties, the DCS can execute financial transactions involving, for example, a single party and a single counter-party (traditional simple), a single party executing several traditional simple transactions at the same time (traditional compound), a single party and multiple counter-parties (collaborative simple), and multiple parties and multiple counterparties (collaborative compound).
  • a method in a data processing system having a program is provided.
  • the data processing system is connected to at least one of a plurality of remote data processing systems via a network.
  • the method comprises the steps performed by the program of: receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; obtaining real-time financial information relating to the financial transaction; and confirming that the financial transaction can be executed with at least one party.
  • a method in a data processing system having a program is provided.
  • the data processing system is connected to at least one of a plurality of remote data processing systems via a network.
  • the method comprises the steps performed by the program of: receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; obtaining real-time financial information relating to the financial transaction; determining a monetary or exchange value of the financial transaction; determining whether the at least one party that will execute the financial transaction for the monetary or exchange value; and confirming that the financial transaction can be executed with additional parties to the at least one party until a total monetary or exchange value for which the parties will execute the financial transaction is equal to the determined monetary or exchange value of the financial transaction responsive to the identified at least one party not executing the financial transaction for the monetary or exchange value.
  • a computer-readable medium containing instractions that cause a data processing system to perform a method is provided.
  • the data processing system is connected to at least one of a plurality of remote data processing systems via a network.
  • the method comprises the steps performed by the program of: receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; obtaining real-time financial information relating to the financial transaction; and confirming that the financial transaction can be executed with at least one party.
  • a computer-readable medium containing instructions that cause a data processing system to perform a method is provided.
  • the data processing system is connected to at least one of a plurality of remote data processing systems via a network.
  • the method comprises the steps performed by the program of: receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; obtaining real-time financial information relating to the financial transaction; determining a monetary or exchange value of the financial transaction; determining whether the at least one party that will execute the financial transaction for the monetary or exchange value; and confirming that the financial transaction can be executed with additional parties to the at least one party until a total monetary or exchange value for which the parties will execute the financial transaction is equal to the determined monetary or exchange value of the financial transaction responsive to the identified at least one party not executing the financial transaction for the monetary or exchange value.
  • a data processing system connected to at least one of a plurality of remote data processing systems via a network.
  • the data processing system comprises: means for receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; means for obtaining real-time financial information relating to the financial transaction; and means for confirming that the financial transaction can be executed with at least one party.
  • a data processing system connected to at least one of a plurality of remote data processing systems via a network.
  • the data processing system comprises: means for receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; means for obtaining real-time financial information relating to the financial transaction; means for determining a monetary or exchange value of the financial transaction; means for determining whether the at least one party that will execute the financial transaction for the monetary or exchange value; and means for confirming that the financial transaction can be executed with additional parties to the at least one party until a total monetary or exchange value for which the parties will execute the financial transaction is equal to the determined monetary or exchange value of the financial transaction responsive to the identified at least one party not executing the financial transaction for the monetary or exchange value.
  • a data processing system connected to at least one of a plurality of remote data processing systems via a network.
  • the data processing system comprises: a memory comprising a program that receives from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems, obtains real-time financial information relating to the financial transaction, and confirms that the financial transaction can be executed with at least one party; and a processing unit that rans the program.
  • a data processing system connected to at least one of a plurality of remote data processing systems via a network.
  • the data processing system comprises: a memory comprising a program that receives from a user a request to execute at least one financial fransaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems, obtains real-time financial information relating to the financial transaction, determines a monetary or exchange value of the financial transaction, determines whether the at least one party that will execute the financial transaction for the monetary or exchange value, and confirms that the financial transaction can be executed with additional parties to the at least one party until a total monetary or exchange value for which the parties will execute the financial transaction is equal to the determined monetary or exchange value of the financial transaction responsive to the identified at least one party not executing the financial transaction for the monetary or exchange value; and a processing unit that runs the program.
  • a computer-readable memory device encoded with a program having a data structure is provided.
  • the program is run by a processor in a data processing system connected to at least one of a plurality of remote data processing systems via a network.
  • the data structure has a plurality of entries, each entry comprising: a first storage area that stores a monetary or exchange value of a financial transaction; and a plurality of second storage areas that each store an identity of a party to the financial transaction and an amount for which the party will execute the financial fransaction, the program confirming additional parties and amounts for which the additional eligible parties will execute the financial transaction until a total amount for which the parties will execute the financial transaction is equal to the monetary or exchange value.
  • FIG. 1 is a schematic diagram showing a client-server environment, according to one embodiment consistent with the present invention.
  • FIG. 2 is a schematic diagram showing a distributed network environment, according to one embodiment consistent with the present invention.
  • FIG. 3 is a schematic diagram showing more detail of the client and the server in a client-server environment, according to one embodiment consistent with the present invention.
  • FIG. 4 is a diagram showing a balanced request with single mean by the Spread- Vector Resolution program module in fulfilling a financial transaction, according to one embodiment consistent with the present invention.
  • FIG. 5 is a diagram showing a balanced request with multiple means by the Spread- Vector Resolution program module for fulfilling a financial transaction, according to one embodiment consistent with the present invention.
  • FIG. 6 is a diagram showing an asymmetric matching being processed by the
  • Spread- Vector Resolution program module for fulfilling a financial transaction, according to one embodiment consistent with the present invention.
  • FIG. 7A is a diagram showing an all-seek opposite-side match being processed by the Spread- Vector Resolution program module for fulfilling a financial transaction, according to one embodiment consistent with the present invention.
  • FIG. 7B is a diagram showing a capital infusion into the system to be made available to the Spread-Vector Resolution program module, according to one embodiment consistent with the present invention.
  • FIGS. 8A and 8B show Spread- Vector Netting according to one embodiment consistent with the present invention.
  • FIG. 9 shows the function of the Code Division Multiple Transaction program module according to one embodiment consistent with the present invention.
  • FIG. 10 shows the function of the Code Division Multiple Transaction program module according to one embodiment consistent with the present invention.
  • FIG. 12 is a screen shot of the Transaction Workpad of the user interface according to one embodiment consistent with the present invention.
  • FIG. 13 is a screen shot of the Transaction Workpad of the user interface according to one embodiment consistent with the present invention.
  • FIG. 14 is a screen shot of an unassembled Traditional Simple transaction on the Transaction Workpad of the user interface according to one embodiment consistent with the present invention.
  • FIG. 15 is a screen shot of an assembled Traditional Simple transaction on the
  • FIG. 16 is a screen shot of a transaction syntax approved Traditional Simple transaction according to one embodiment consistent with the present invention.
  • FIG. 17 is a screen shot of a real-time simulated execution data attendant to a Traditional Simple transaction, according to one embodiment consistent with the present invention.
  • FIG. 18 is a screen shot of an assembled Traditional Compound transaction according to one embodiment consistent with the present invention.
  • FIG. 19 is a screen shot of an assembled Collaborative Simple transaction according to one embodiment consistent with the present invention.
  • FIG. 20 is a flowchart of a method of conducting a Collaborative Compound fransaction according to one embodiment consistent with the present invention.
  • FIG. 21 A is a table showing a macro ledger kept by the Code Division Multiple Transaction program module in a Collaborative Compound transaction according to one embodiment consistent with the present invention.
  • FIG. 2 IB is a diagram showing the parties to a Collaborative Compound transaction being processed by the Spread- Vector Resolution program module, according to one embodiment consistent with the present invention.
  • FIG. 21C is a table showing a macro ledger empirically reduced, which is kept by the Code Division Multiple Transaction program module in a Collaborative Compound transaction according to one embodiment consistent with the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • Methods and systems consistent with the present invention makes possible automated distributed financial services available over a global computerized network.
  • the system of the present invention allows individuals to collaboratively lend (any particulate amount) to any person or company and arrange for independently market-driven rates and terms, and then also allowing the system to handle repayment distributions.
  • a distributed capital system converts currencies without a broker, at any amount desired, and matches counte ⁇ arties for equities, bond or other fungible-instrument trades faster and cheaper than traditional methods.
  • the distributed capital system consistent with the present invention includes the concepts of scalability, network-effect, and open community.
  • Methods and systems consistent with the present invention include an expansive system designed to support network collaborative fransaction services. Since this collaborative format is more sophisticated and requires more system architecture than conventional systems, current transaction structures (one-to-one commerce relationships) are enabled as a subset of the functionality of the collaborative embodiment of the present invention.
  • the present invention may be carried out in a client-server environment (see FIG. 1), or may be carried out in a distributed environment, where only client computers are utilized (see FIG. 2).
  • a particular operation or service may be performed either at the client or the server, at the edge of a network or at center, or both. Therefore, at either the client or the server, or both, corresponding programs for a desired operation/service are available.
  • every node on the network has a set of closest neighbors, and each node shares its awareness-universe with its neighbors.
  • a query can be autonomously related back to the requesting party.
  • the present invention terms this an "awareness propagation".
  • the operations of the present invention can be provided solely by client computers as shown in FIG. 2.
  • At least one client computer may preferably be used to practice the methods and systems consistent with the present invention.
  • At least one client and at least one server are each connected to a network (see FIG. 1), such as a Local Area Network (LAN), Wide Area Network (WAN), and/or the Internet, over a communication link.
  • a network such as a Local Area Network (LAN), Wide Area Network (WAN), and/or the Internet
  • the steps in the methods consistent with the present invention are carried out at the client or at the server, or at both, the server, if used, being accessible by the client over, for example, the Internet, using a browser application or the like.
  • the client shown in FIGS. 1-3 may be a personal computer, a mobile terminal, such as a mobile computing device, a mobile phone, or a mobile data organizer, operated by the user in accessing the financial services remote from the client (i.e., at the server).
  • a mobile terminal such as a mobile computing device, a mobile phone, or a mobile data organizer, operated by the user in accessing the financial services remote from the client (i.e., at the server).
  • the client computer 10 typically includes a processor 11 as a client data processing means or mechanism, the processor 11 including a central processing unit (CPU) 12 and an input/output (I/O) interface 13, a memory 14 with program 15 having a data structure 16, all connected by a bus 17, as well as an input device or means 18, a display 19, and may also include a secondary storage device 20.
  • the bus 17 may be internal to the client 10 and may include an adapter to a keyboard or input device 18, or may include external connections.
  • the data structure 16 may include a plurality of entries, each entry including at least a first storage area that stores a monetary or exchange value of a financial transaction, and a plurality of second storage areas that each store an identity of a party to the financial transaction and an amount for which the party will execute the financial transaction., the program confirming additional parties and amounts for which the additional eligible parties will execute the financial fransaction until a total amount for which the parties will execute the financial transaction is equal to the monetary or exchange value.
  • the data structure can also have alternative embodiments including that associated with the match codes or other stored information as one of ordinary skill in the art would appreciate from the following descriptions.
  • the client 10 is connected to other clients 10 or servers 30 via a communication link 21 as a client communication means or mechanism, using a communication end port specified by an address or a port, and the communication link may include a mobile communication link, a switched circuit communication link, or may involve a network of data processing devices such as a LAN, WAN, the Internet, or combinations thereof.
  • the communication link 21 may be an adapter unit capable to execute various communications protocols in order to establish and maintain communication with the server 30.
  • the communication link 21 may be constituted by a specialized piece of hardware or may be realized by a general CPU executing conesponding program instructions.
  • the communication link 21 may be at least partially included in the processor 11 executing conesponding program instractions.
  • the processor 11 at the client 10 may be internal or external thereto, and executes a program 15 adapted to predetermined operations.
  • the processor 11 has access to the memory 14 in which may be stored at least one sequence of code instructions comprising the program 15 and the data structure 16 for performing predetermined operations.
  • the memory 14 and program 15 may be located within the client 10 or external thereto.
  • the program 15 can include a separate program code for performing a desired operation or service, or be part of a module of a larger program providing the service.
  • the program 15 may also include a plurality of modules performing sub-operations of a service, as described further below.
  • processor 11 may be adapted to access and/or execute a plurality of programs 15 corresponding to a plurality of services/operations.
  • An operation or service rendered by the program 15 may be, for example, supporting the user interface, performing e-mail applications, setting up financial transactions, etc.
  • the input mans 18 of the client 10 may include standard input devices such as a keyboard, mouse, or a speech processing means.
  • the storage device 20 stores at least one data file, such as text files, data files, image, audio, video files etc., in providing a particular service for a user.
  • the data storage device as storage means 20 may be for example, a database, including a distributed database connected via a network 22, for example.
  • the storage device 20 may be connected to the server 30 and/or the client 10, either directly or through a communication network, such as a LAN or WAN.
  • An intemal storage device, such as 20, or an external storage device 23 is optional, and data may also be received via, for example, a network 22, and directly processed.
  • the server 30 would include a processor 24, having a CPU 25 which is a server data processing means or mechanism and an I/O interface 26, but may also be constituted by a distributed CPU 25 including a plurality of individual processors 24 on one or a plurality of machines.
  • the processor 24 of the server 30 may be a general data processing unit, but preferably a data processing unit with large resources, i.e., high processing capabilities and a large memory for storing large amounts of data.
  • the server 30 also includes a memory 27 with program 28 having a data structure 29, all connected by a bus 31.
  • the bus 31 or similar connection line can also consist of external connections, if the server 30 is constituted by a distributed system.
  • the server processor 24 may have access to a storage device (i.e., storage device 32) for storing preferably large numbers of programs for providing various services to the users, i.e., for performing various financial operations as desired by users operating clients 10.
  • the data structure 29 may include a plurality of entries, each entry including at least a first storage area that stores a monetary or exchange value of a financial transaction, and a plurality of second storage areas that each store an identity of a party to the financial transaction and an amount for which the party will execute the financial transaction., the program confirming additional parties and amounts for which the additional eligible parties will execute the financial transaction until a total amount for which the parties will execute the financial transaction is equal to the monetary or exchange value.
  • the data structure can also have alternative embodiments including that associated with the match codes or other stored information as one of ordinary skill in the art would appreciate from the following descriptions.
  • the server 30 may be a single unit or may be a distributed system of a plurality of servers 30 or data processing units, and may be shared by multiple users in direct or indirect connection to each other.
  • the server 30 performs at least one server program 28 for a desired operation, which is required in serving a request from the client 10.
  • the communication link 33 from the server 30 is preferably adapted to communicate with a plurality of clients 10.
  • the server program 28 may relate to providing a number of operations related to providing financial services to a user, such as allowing a user to assemble a financial transaction, to test a proposed financial transaction, to ensure that each fransaction request is codestamped with a unique transaction number and tracked securely through the financial system, etc.
  • a user selection means including selection buttons, in a menu, dialog box, or a roll-down window of an interface provided at the client, and the user may input commands through a keyboard or the like.
  • the selection means may be constituted by a dedicated piece of hardware or its functions may be executed by code instructions executed on the client processor, involving a display unit for displaying a selection window and a keyboard for entering a selection, for example.
  • Program Modules One embodiment of the program (at least either 15 or 28 or both) of the present invention includes four major program modules: Vector- flow Topography (VfT), Code-Division Multiple Transaction (CDMX), Spread Vector Resolution (SVR), and Matrix Quartermaster (MaQs). Each program module is independently capable of supporting various new financial services, and can be used individually in other applications; but connected together, working in tandem and with other program modules further described below, they create the distributed capital system platform consistent with the present invention.
  • VfT Vector- flow Topography
  • CDX Code-Division Multiple Transaction
  • SVR Spread Vector Resolution
  • the features and processing operations of the four major program modules may be realized by dedicated hardware, or may be realized as programs including code instructions executed on data processing units. It is further possible that parts of the above sequence of operations are carried out in hardware, whereas other of the above processing operations are carried out using software.
  • the following program modules consistent with the present invention may be run by the parent program of the distributed capital system architecture, and can be part of a client-server environment, or part of a distributed platform of client computers.
  • VfT Vector-flow Topography Program Module
  • the Vector-flow Topography (VfT) program module runs the user interface and enables the streamlined construction, testing, and management of transactions of all types.
  • the VfT module allows a user to rapidly construct financial fransactions with visual objects arranged and connected on an on-screen Transaction Workpad, and then test the proposed flow of instruments and funds, payments, debits, account balances, etc. prior to execution.
  • the VfT program module also receives and displays various data, confirmation, and other indications to the user following a transaction or at any other time after initial entering of transaction specifics into the system.
  • the VfT program module will allow the user to easily access the history of all executions and testings of the constructed transactions, which information is to be tracked by the CDMX program module, see below). In this way, the user may review any and all details of any of his/her transaction events at any time.
  • the VfT program module While capable of assembling and executing simple transactions like bill- payment, etc., the VfT program module also handles sophisticated, complex, or so- called “compound” transactions, where "compound” is defined as constituting multiple, or compounded, interim steps or transactions to achieve the desired commercial result of position.
  • the VfT program module's "drag and drop” capability allows compound transactions to be easily assembled, tested and executed.
  • the CDMX program module runs the tracking and accounting which makes the distributed capital system of the present invention possible.
  • the CDMX program module handles two types of data simultaneously (financial and communications) securely and privately, preserving and using the relationship between the two dimensions, but nonetheless retaining complete separation, confidentiality, and anonymity of the transmissions.
  • the CDMX program module thus employs both a communications protocol and a transaction protocol, and monitors and matches precise data requirements, allowing random-party connections to be achieved (which is handled by the algorithms in the SVR program module, see below) completely random parties according to a macro sense of counte ⁇ arty matching.
  • the CDMX program interfaces with the multiple-mean matching engine (the SVR module - see below) to complete the random-party matching, attaching appropriately devised tracking codes to the amounts in the DCS of the present invention. Even when the financial vectors are broken up into different, smaller components, or whether they are recombined later, the CDMX program module keeps track of all the components as they go through the system within a zero-sum accounting environment.
  • the multiple-mean matching engine the SVR module - see below
  • the CDMX program module will track four types or categories of user- programmed transactions: Real Time, Passive, Fixed, and Installment.
  • Real-time means instantaneous processing, whether at execution of the transaction request or when set times have expired;
  • Passive means that the user does not determine the timing or amount of the processing, and the system executes the request at random and/or optimal times before the user indicated time limit expires;
  • Fixed means the user has indicated a set of requirements for execution, and that the transaction will not occur unless triggered by the requirements being met;
  • Installment consists of combinations of the other three types (can be the same transaction taking place at predetermined times, for example), and when entered into the system are disaggregated into the smaller component transactions, each tagged with a special parent code linking all installments to the overall parent transaction.
  • CDMX Code Division Multiple Access
  • the protocols for CDMX module were designed so that the program can unwind and trace backward to the originating account, any transaction, regardless of whether it is a Traditional Simple event, or a Collaborative Compound event
  • the CDMX program module allows the CDMX ledgers of the program, or even a very small subset of distributed clients/servers/servents, to reconstruct the dispersion post facto, achieving a rewinding review of the funds transfer networks, to determine the details (i.e., what, how, how much, who, etc.) of any Distributed Capital System transaction.
  • DFT Distributed Funds Transfer
  • the information that the CDMX program module records, will be preserved in encrypted form even at distributed clients/servers/servents, unavailable to anyone except by a deliberate act by the system monitors, such as due to official legal action like a subpoena, etc.
  • the CDMX program module may also contain a built-in function that resides on the distributed devices, that automatically sends archived CDMX data for reconciliation, to a centralized collection monitoring server, etc.
  • the CDMX program module of the present invention executes the following functions: a) Codestamping, b) Codecycling, and c) Codematch Aggregation.
  • Codestamping and Codematch Aggregation sub-programs have procedural relationships with the Matrix Quartermaster module (further described below), and the Codecycling sub-program executes an iterative process that involves repetitive exchanges with the Spread Vector Resolution program module (further described below).
  • Codestamping occurs whenever any NEW activity is initiated. All transaction event requests that enter the system are codestamped using the Codestamping sub-program, and the program assigns a unique transaction number that will be the parent code that relates the requested transaction to the user who entered it. This unique fransaction number is inclusive of some unique identifier of the person or account initiating the fransaction, as well as a coding unique to the fransaction.
  • the program may duplicate the fransaction number (since there is more than one participant in a transaction (i.e., counte ⁇ arties)), but the parent codestamps will each be unique since any transaction number will have a unique user-account identifier attached to it.
  • the program also executes a Codecycling function, that tags matched pairs in a Collaborative fransaction, each time the SVR program module (see below) completes (resolves) a counte ⁇ arty match. If Codecycling is required for the type of transaction requested, the Codecycling program module will create several additional child-codes to track each of the component amounts that are allocated and directed according to the Spread-Vector Resolution (SVR) program module, which are traceable to the parent transaction. The recording may be preserved in encrypted form by the program.
  • SVR Spread-Vector Resolution
  • the program also executes a Codematch Aggregation function whereby the CDMX program module aggregates all available transaction amounts for a single user or account, in order to net the amounts or optimize activity before passing the data to the Matrix Quartermaster (MaQs) program module for execution.
  • a Codematch Aggregation function whereby the CDMX program module aggregates all available transaction amounts for a single user or account, in order to net the amounts or optimize activity before passing the data to the Matrix Quartermaster (MaQs) program module for execution.
  • the SVR program module takes an input of multidimensional (i.e., vector) objects, and automatically isolates each dimensional quantity, processing them independently before execution occurs.
  • multidimensional i.e., vector
  • the advantage of isolating dimensional quantities before processing, is that efficiency in each dimension may be captured more fully, rather than just capture the efficiency available or accessible at the intersection of multiple dimensions treated together. In other words, the SVR module can get at efficiency that is otherwise locked up in the complexity of constrained (i.e., multidimensional) objects.
  • the SVR program module can isolate each dimensional value, and process them separately. In practice, this means that it executes the inclusion of completely unrelated parties together in the same netting summations. It is a matching utility, including various algorithms, that achieve efficiency in assigning counte ⁇ arty matches.
  • the SVR program module handles digital representations of financial vectors (i.e., which can be combined and manipulated mathematically yielding for example condensed or combined vectors that resolve all commitments of the component vectors), intaking them, outputting this information to a system (described below) which can account for everything accurately, and then execute the resolved vectors.
  • the SVR program module is designed specifically to operate where counte ⁇ arties in a Collaborative Compound transaction (see below), are not equally balanced, i.e., when there is an unequal balance of value between the two sides of a fransaction environment. In these asymmetric situations, the SVR program module processes fransactions without delay, resolving the asymmetry via vector-flow particulation. As is described in greater detail below, SVR matching allows the zero- sum "market-mechanism" of large liquid markets with theoretically large numbers of participants to be brought to limited-participant transaction environments.
  • the SVR program module executes a netting function, funds fransfer algorithms, currency exchange algorithms, consolidated accounting algorithms, loan syndication, and ATM-sharing, etc. (further described below). Algorithms Used in SVR Program Module
  • FIG. 4 one potential algorithm used by the SVR program module for filling a Collaborative Compound transaction (see below for detailed description) is shown in FIG. 4, where there are counte ⁇ arties requesting exchanges of yen to dollars, and dollars to yen.
  • the Nearside denotes a reference used to explain the exchange process of this potential algorithm.
  • Nearside is a pre-process state. Since every exchange is composed of a currency pair, the Oppside is the reference to the requests in the target (counte ⁇ arty) currency which will be used to execute exchange fransactions. Thus, optimal efficiency occurs when the total number of Oppside requests required to fill a nearside request is minimized.
  • the program prioritizes exchanges on this basis. Note that active-seeking class amounts are preferably filled with a single Oppside amount.
  • the SVR program module will automatically classify the amounts to be exchanged as active-seeking, when the amount is below an arithmetic mean, for example, or passive-fill, if the amount is above the arithmetic mean.
  • this arithmetic mean constantly changes as the program recalculates the arithmetic mean depending on the amounts of vectors/funds flowing through the system.
  • requests are characterized by the SVR program as realtime requests at or near the time they are actually processed. Since there will be a population of passive requests, which come from user-programmed transactions that don't have single-point fixed time (i.e., on some date) or event-triggered execution specifics (i.e., when the Dow Jones index reaches 10,000, for example) , but rather time-period limit specifics (i.e. by some date), an active reclassification requested by the program may call upon this storehouse of passive transactions, to convert some or all to real time, processing them to bring liquidity to the system, and attempt to create a seamless progression of moderated volatiltiy (i.e., consistent liquidity).
  • moderated volatiltiy i.e., consistent liquidity
  • the program may have multiple means and provide a volume-average separator to distinguish between the two means (see FIG. 5). For example, when the volume of the transactions increases enough to activate a preset trigger, the program will accommodate this increased vector flow by creating a new parallel channel to process the volume. The trigger bifurcates the volume into sections, each one acting like the previous single-divider program function (see FIG. 4). When the larger vectors in the upper half as shown are resolved and the matches occur, remainders will drop into the lower half, and as the volume decreases, a preset trigger is tripped and the program will remove the separator, returning the program function to its original single-divider state. Active-seeking amounts will target passive-fill amounts in the respective target currency.
  • the matching of a request to exchange currency can be matched using several algorithms - with the active-seeking transaction on the Oppside being matched from a passive-fill fransaction on the Nearside, or vice-versa, or by a staggered linear match, or an angled Nearside all seek opposite-side match (see FIG.
  • This imbalance may be in reference to trans-currency events, or domestic events that are structured as directional coutne ⁇ arty matching, or any number of other situations where one side of a fransaction type is more abundant than the other.
  • the SVR program module will take an inflow of self-selected vectors, the self-selection guaranteeing that all vectors have at least one variable which is the same. For example, in domestic Distributed Funds Transfers, the currency is the same for all vectors, and it is the direction variable that is match-paired. In cunency exchanges, direction is not important and so the match-pair basis is the currency-pair. In the event of this kind of disparity, the system will process as much as it can, which means until all available vectors on one side have been processed, leaving the imbalance in an empirical state with zero available vectors on the opposite side (see FIGS. 6 and 7A).
  • the program of the system could be preset to direct the remaining one-sided vector-flow toward more fraditional channels where liquidity can be provided by an interbroker for example, and the owners of those vectors can get their transactions fulfilled (i.e., a capital infusion from fraditional channels - see FIG. 7A). In this way, the user may not recognize the switch of liquidity pools, from system participants to third-party big-bank interbroker/trader. Accounting Netting
  • S VN Transaction Spread- Vector Netting
  • Distributed Direct Exchange is a multi-party compaction, and is possible when any party, anywhere, is transacting.
  • the SVR program module when executing the SVN function can handle any and all transaction sizes, individual or institutional. A much larger number of participants is possible than with conventional netting.
  • SVN multiple parties are always populating the spread-net, , and cross-liabilities and linked settlement are not necessary.
  • Conventional netting demands both a fixed number of participating parties, as well as a fixed time period over which to net.
  • Spread-netting requires neither of these. Complexity is not likely correlated to the number of parties, and risk is likely to be inversely corcelated to the number of parties.
  • a liability circle (which is defined as a number of debtors in a circular arrangement such that remittance of payment to fulfill the debt obligation may halt as each debtor in the circle waits to be paid) in SVN
  • the program nets as is described under CPN, but instead of maintaining the vector relationships as is, the program redirects any vectors necessary such that the net result in/out for each Party is the same absolute value that it was prior to netting (see FIGS. 8A and 8B).
  • Matrix Quartermaster (aka the Distributed Banking Lending Credit (DBLO) Program Module
  • the Matrix Quartermaster (MaQs) program module is the negotiating manager that takes conclusive aggregate transaction information as an input, converts that information to execution instructions, and then initiates the execution of the transactions over whatever infrastructure is required, and uses whatever protocols that already exist, and deals with multiple accounts and systems to ensure that all parties' transactions are achieved.
  • the MaQs program module works with the CDMX program module or similar tracking-modules , to activate the execution of capital movement.
  • the MaQs program module carries out the instructions over existing infrastracture.
  • the MaQs program module holds or inco ⁇ orates various API's that allow it to interact with the rest of the financial and banking world.
  • the MaQs program module packages the execute commands assembled by the Vft program module and the user-account information provided by the CMDX program module, into proper and formal execution instractions according to the infrastructure being used to carry out the fransaction. Since multiple infrastructure networks may be used, the MaQs program module is able to package transaction commands into a variety of formatted execution instructions.
  • the MaQs program module executes the transactions that are created, programmed, resolved, or otherwise in the distributed financial system of the present invention.
  • the MaQs program module is the link to the greater network of markets, product and service providers, and of course, customer accounts at banks and all other relevant entities (such as utility companies, insurance companies, etc.).
  • the MaQs program module will take capital vectors out of the system and supply capital vectors into the system.
  • the program includes bridges between the present system and other systems in the market (i.e., stock market funds, New York Stock Exchange etc.), such that the program will be able to pass data retrieved from accounts and markets through to the system for display and manipulation. No new secure-system infrastructure required.
  • Bank Multiplexer API i.e., Stock market funds, New York Stock Exchange etc.
  • the Bank Multiplexer program for example, reads the identifier codes on each processed transaction amount, and franslates these into various financial network instructions, for example direct-deposit and direct-debit instructions to be sent to the bank accounts registered with the system. It is possible that when passive requests enter the system, an additional code will direct the program to draw down these programmed transaction amounts at different times, and deposit them into a system-owned account, for use in the investment engine until needed to execute the programmed fransaction (see further below).
  • the program which runs the investment engine, will employ the aggregated funds as needed, at the end of which it will remit the original exchange-matched amounts to the appropriate end-user counte ⁇ arty accounts, retaining the profits in the system account for further use.
  • CDMT Code Division Multiple Transaction
  • Program Module Code-Division Multiple Access is a telecommunications technology specifically designed to maintain the interlinked connection (i.e., a voice/data fransmission) between single source-sink pairs interlaced with lots of others, for the specific pu ⁇ ose of increasing bandwidth over the same communications infrastructure.
  • CDMT Code-Division Multiple Transaction
  • CDMA Code-Division Multiple Transaction
  • CDMT Code-Division Multiple Transaction
  • the program utilizing the CDMX and SVR program modules, working together, can link, switch links, and add new links on either counte ⁇ ary side, to a multiplicity of random counte ⁇ arties, who are otherwise unrelated and may remain anonymous if desired.
  • Every counte ⁇ arty pair must consist of a balance of value or the transaction cannot be considered valid, and in practice, won't occur.
  • the program via the CDMX program module makes it possible for example, for anonymous buyers and sellers to be automatically matched simply based upon price (i.e., when there are a multitude of buyers and sellers at the same price, the system will automatically code-divide the incoming trade-requests such that the zero-sum can be spread to a non-symmetric number of counte ⁇ arties) (see FIG. 10).
  • five sellers of US dollars who are also buyers of Japanese yen
  • are served by just three counte ⁇ arties see FIGS. 9-10). There is no need for any of the counte ⁇ arties to know or be aware of one another.
  • a participant must sign up as a system member.
  • the participant would simply have to have an e-mail account in order to go through a standard opt-in procedure, initiating the usemame and password at the website, for example, and having that website take basic user information in order to create an account file, then sending the opt-in verification request to the supplied e-mail address.
  • the user account Upon verification the user account would become active and the user could either download a distributed client application, and then go about inputting various account and financial data to give the new distributed capital account access clearance to any 3 r party accounts the user wanted to be able to manipulate from within the distributed capital account, or, the user could feed the same kind of information to a centralized server for the same pu ⁇ ose.
  • the user may not be provided with complete access to the system at sign-up, but rather, may have to proceed through staging, with minimal functionality available to the user upon initial signup (such as the ability to execute fraditional simple fransactions, and limited traditional compound transactions), but additional more powerful tools (i.e., collaborative fransactions) becoming available through demonstration of awareness of, familiarity with, and or adherence to, financial regulations, risk profiles, investment structures, tax rules, etc., perhaps via online seminars and tests, according to the number and value of transactions executed, and proof of sophisticated investor status, etc.
  • additional more powerful tools i.e., collaborative fransactions
  • the present system would support multiple access passwords and user-clearance levels, such that for example a CFO would have Master privileges and full functionality over the Co ⁇ orate system account, and therefore the greatest freedom to manipulate and manage assets of the co ⁇ oration, while the lower- level finance personnel may have access to the same accounts for visibility reasons, but without the Master privileges to manipulate or manage.
  • This approach means bringing the very advanced art of challenge-ramp design so visible in video-games, to financial services provision.
  • a challenge- ramp that inco ⁇ orates educational or problem-solving interaction, as well as typical user statistic hurdles, it is possible to create an interactive environment built around financial services.
  • the credit rating system may drive a classification system, in much the same way that in role-playing games, greater powers or strength (such as a more powerful sword, or greater wizardry spells) accrue to users who accumulate certain artifacts or techniques along their journey.
  • the present system may classify users according to Financial Skill, Capital (or Asset) Power, etc., as well as credit or Integrity.
  • Financial Skill Capital (or Asset) Power, etc.
  • Another alternative for initial signup is that an official agency could verify the user, which would require an official identify and other personal information such as a social security number.
  • a personal account aggregating service uses an assistant that travels with the user to each financial account website, which can capture the login and password information, to make it available to the user at the personal aggregating service account.
  • All existing systems to date involve accounts that are managed by the user, and accessed by the user. In no known instance do users of these systems grant access and send such access privilege to other users.
  • the present invention does intentionally however enable this multiparty access and granting of access to fransaction events. For example, in collaborative transactions, account access or even single transaction access, is received by users who have been granted such participation privilege, and it becomes available to the user with no specific action required of that user. Of course the user has the right to refuse the granted privilege, but gaining access privilege was something that occurred at the instigation of other system users. While it is expected that various financial service providers increase functionality and grant access to that functionality within the users' existing accounts, nowhere is there a financial services platform that is designed to facilitate system users interacting with each other as collaborating participants, granting permissions to each others accounts and transactions.
  • the methods and systems consistent with the present invention encompass four major types of financial transactions: Traditional Simple, Traditional Compound, Collaborative Simple, and Collaborative Compound, which will be described generally below, before being further described in more detail.
  • Traditional Transactions Traditional Simple Presently, financial services are predominantly pursued in the context of one- to-one relationships between the financial service provider and the customer or client.
  • One-to-one commercial relationships, and the transaction events that occur in their context, are fairly straightforward: There is usually one seller/provider, one buyer/user, and one form of purchase currency or credit, all arranged in a simple, linear equation such as: buyer purchases goods from seller, or, user pays credit-card company.
  • the present invention is designed to support network collaborative transaction services that leverage the real network-advantage of multiple connected systems, users, providers, customers, buyers, sellers, etc.
  • Traditional Simple transactions can be easily performed using this distributed financial system, since the user using the present invention is provided the omniscient perspective of being able to see and manipulate the involvement of all accounts in his/her transaction universe, whereas current methods and systems place the user at the node perspective of just one of the participants of the transactions, such as at a credit-card website, or a bank website, etc.
  • a user can manage, integrate, and program several Traditional Simple transactions at the same time. For example, the user can manage and integrate the user's Credit Card bills along with the user's Home Loan, Utility bills, Stocks, Bonds, online purchases, and anything else that involves a transaction the user wishes to make.
  • a Traditional Compound fransaction could include obtaining a new home-equity loan, and using the loan to pay credit card bills and an auto-loan, or a child's college tuition.
  • vendor billing can be performed next to freasury management (i.e., currency management, credit hedging), or revenue sfreams etc., all within the same interface.
  • freasury management i.e., currency management, credit hedging
  • revenue sfreams etc. all within the same interface.
  • Traditional Compound transactions allow users to build the inte ⁇ lay between their various financial arrangements, receivables and liabilities (cash-flow management, etc.) and obligations, and schedule as well as test transactions to assess the results as they impact the whole, not just a single account or relationship.
  • the senior party responsible for, in this case, an invoice can orchestrate various triggers along the process of invoice handling, and allow disparate users in various divisions (for example, the co ⁇ orate mailroom), to approve of receipt of goods and quality of goods (i.e., correct invoiced part numbers and fitness of goods according to shipping roster), while another group or division (the specific team using the goods) approves of the accuracy (i.e., the correct part as required for the project), etc., before the accounting department is released to remit payment.
  • This confrol can be implemented throughout the co ⁇ orate stracture, allowing the ente ⁇ rise to have much greater and faster data on the financial state of the company.
  • the user can set the parameters of the integrated transactions (i.e., stocks to be sold when they reach a certain value, or stocks to be sold at a certain time or day etc.).
  • the transactions can be automatically and remotely set, and the user notified when the transaction takes place, as well as have access to summary information detailing the component fransaction results, as well as the overall compound transaction results.
  • One embodiment of the present invention may be loosely defined as the existence of networked or collaborative options in the realm of financial activity. This is uniquely different from existing financial, banking, and commerce activities.
  • the existing paradigm for these activities (generally inclusive of Commerce) is almost exclusively a stracture that orients relationships in a singular, linear Customer- Provider arrangement.
  • collaborative activities are mutually oriented and inclusive of more than a single relationship; where all parties can be simultaneously Customers AND Providers.
  • Collaborative transactions which are designed to be supported by methods and systems consistent with the present invention, include a multitude of parties and a diversity of forms of currency and/or credit.
  • Collaborative transactions include transitive (or spread-vector) actions, which means that the fransaction equations can be complex as the net-zeroing of credits and debits, receivables and liabilities, etc., are treated on a global level amongst all participants in the network universe, rather than only between directly related parties as in Traditional fransactions.
  • the distributed capital system of the present invention has a greater awareness of the transaction universe than any single participant, it can actively and intelligently optimize the logistics of transaction, for example, theoretically computing the transitive shuffle of liability across thousands of participants such that the total volume of actual funds movement in the universe may decrease for the same volume of paid liabilities in the universe, as receiver and obligor parties can be matched according to the accounts and institutions being used to remit or accept payments - thus, for example, allowing funds movement to be handled as an internal banking execution (where obligor and receiver can be identified and at least partially matched at the same institution, even though these individual participants may have no connection at all to each other), with no net funds, or reduced net finances exiting that bank and going out into interbank fransfer networks such as ACH or CHIPS, ,etc.
  • interbank fransfer networks such as ACH or CHIPS, ,etc.
  • the present invention brings this guaranteed global-zeroing mechanism to a variety of transaction situations which would never have the critical mass or stracture (i.e., securitization, etc.) to function (i.e., achieve liquidity, etc.) as markets. Cunently, global-level zeroing is evident only in liquid markets active with a theoretically large number of participants, that trade securitized or commoditized items.
  • the present invention brings this global level zeroing mechanism to limited- participant transaction environments Using transitive actions achieved with the program called SVR program module, as described above, any number of transactions involving as few as two participating entities can now have access to a system that will net-zero responsibilities across all participating entities.
  • Fungibility facilitates transitive resolution. What this means is that, for example, if party A owes party B some amount X, and party B owes party C some amount X, all three parties' transactions roles and responsibilities can be satisfied with a single payment X that party A remits to party C.
  • a distributed capital system will find and execute this transitive scenario regardless of whether Party A, B, and C know each other, or even are aware of each other - to the same effect that buyers and sellers of public equities do not know and do not care who the counte ⁇ arties are to their fransactions.
  • the Spread-Vector Resolution program module in treating the fransaction universe as a flow-based model, achieves "resolution" of non-matching amounts, by sfringing together follow- on counte ⁇ arty matches of those parties' partial or full liability or receivable amounts, in never-ending fashion.
  • Mutual Funds are a good example of how a distributed capital system may improve customer-service provision to investors; however, currently mutual funds follow both the traditional one-to-one relationship paradigm, and the static freatment of fransactions.
  • a distributed capital system would allow a great deal more service and value to be returned to the customer, by providing, for example, constant visibility on the state of the fund, and perhaps even other investors real-time actions relevant thereto.
  • Collaborative Compound fransaction both sides of the fransaction are considering themselves to be customers (and in a context where doing so makes them both providers as well). The customers may not have any direct awareness of each other, and the distributed capital system of the present invention is simply using the Collaborative Compound embodiment to make the fransaction more efficient or less costly or both, etc.
  • a user's company may require British Pounds for certain activities. In a fraditional manner, the user would go to a bank either physically or online, etc., to arrange for a certain amount of capital to be converted from US$ to GB£.
  • Both users are customers, and the financial institutions can provide them both with services in the traditional manner.
  • both users could arrange to transact with each other, or automatically and anonymously be matched with each other, to mutually serve each other's needs in the distributed capital system of the present invention, so becoming providers at the same time as being customers.
  • the users could utilize the distributed capital system of the present invention to request an exchange of currency.
  • the program of the distributed capital system of the present invention uses a vector-flow algorithm to resolve the problem of exact matching of the funds requested by both users/parties, allowing the parties to transact to the full amount possible, and then taking any remainder amount (if for example, one user required more US$ than the other party could provide), and having a different "customer" fulfill that partial amount, leaving that customer's remainder filled by another, successive customer on the opposite side of that transaction.
  • Timing of Transactions Note that in discussing these four embodiments of types of transactions, the user can indicate whether they wish instantaneous processing (typically desired for a bill payment, or investment-grade request), or they wish to set a time for the fransaction to take place (i.e., a later date, for installment bill payment etc.), or an event-triggered transaction to take place (such as a certain stock-price, or even random variables for which data users may wish to use, for example the ambient air temperature in Las Vegas, or the score of the Green Bay Packers game, etc.).
  • the first transaction is designated by the system as a real-time or immediate type of request, the next as a passive request, and the final as a fixed request. In the latter system, the funds in the fransaction may be available to the investment engine of the present system (see Investment Engine below).
  • a Traditional Simple transaction is familiar to most online users, and involves only the customer and a provider, and a simple financial transaction such as the payment of a bill. Accordingly, once the user has logged into the system, and has been through the log-in process in step SI 00 (see FIG. 11 A) and the authentication process in step
  • step SI 02 the program opens a blank display screen in step SI 02, similar to the screen which opens when a word processing program is opened, with Transaction Options shown on the display screen.
  • step SI 03 the program provides a pull-down menu listing the possible fransactions available to the user, or perhaps a dialog window, options palette, or toolbar or any similar presentation of custom designed Transactions the user has set up in his/her account, (i.e., Existing Transaction 1, Existing Transaction 2, Build New Transaction, etc.).
  • step SI 04 the program will open a blank Transaction Workpad on the display screen (see FIG. 12).
  • step SI 06 the program will provide a pull-down menu in step SI 06 which includes "Toolbars”.
  • step SI 07 the program will provide a list of transaction options from which the user can choose.
  • Toolbars can be a list of options including “My Banks”, “My Credit Cards”, “My Communications”, “My Utilities”, “My Insurance”, “My Loans” etc., as well as a selection entitled “Transaction Objects” (see FIG. 13).
  • Toolbars be replaced with a more appropriate name, such as "Transaction Entities”, or some other such designation which communicates most effectively with users.
  • the user may wish to pay a gas bill, which is a simple transaction involving two parties (three entities) - the user and the gas company being the parties (the user, the gas company, and the fransaction action between them being the three entities).
  • a gas bill which is a simple transaction involving two parties (three entities) - the user and the gas company being the parties (the user, the gas company, and the fransaction action between them being the three entities).
  • the user may choose "Transaction Objects", and left-click on that option, whereby the program, in step SI 07 will receive the command and display a working area adjacent to the Transaction Workpad (see FIG. 14), labeled
  • Convert Currency Buy, Sell, Lend, Borrow, and Currency Hedge, etc.
  • the objects While resident in this Transaction Object toolbar or palette, the objects will be inert. When any of them are dragged onto the Transaction Workpad, they become active objects, the building block entities of a fransaction that the user will assemble.
  • the user may choose "My Banks” from the "Toolbars” menu, whereby the program will receive the command and display another labeled section adjacent the Transaction Workpad, which shows icons which refer to different banks accounts pre-registered by the user.
  • the accounts and fransaction actions are preferably shown as icons on the display, the accounts and transaction actions may be available in a pull-down menu, table, grid, or the like.
  • the fransactions may be assembled by the movement of the Transaction Objects icons or placeholder representations (such as text names, or the like, etc.) using a mouse, or by command functions on the keyboard or the display, or by voice actuation etc., which are specific to handling those entities.
  • the following description will relate to the use of icons manipulated using a mouse, one of ordinary skill in the art will be aware that use of command functions on the keyboard, or display, or by voice actuation, etc., can also be instituted to perform the commands or initiate the fransactions.
  • the user may choose "My Utilities" from the "Toolbars” menu, whereby the program will display a labeled section adjacent the "My Banks” and “Transaction Objects” areas, whereby a number of icons depicting the "Gas Company”, “Water Company”, “Electric Company” etc., will appear in the "My Utilities” section.
  • the parties to the transaction, and the transaction action chosen to act between them must by placed in the Transaction Workpad area, arranged in the relationship desired to be executed as a fransaction .
  • the user may place the cursor over the "My Bank Account” icon (may be specific to a particular bank account at a particular bank, as registered by the user), and using the mouse, may left-click the cursor, holding, moving or dragging the icon "My Bank Account” over onto the blank Transaction Workpad section, depositing the icon there. Dragging from the original location does not remove it from the original location, but rather creates a copy as the cursor moves the clicked- on object away from the original.
  • the program in step S108 receives the transaction entity in the Transaction Workpad section, as the user proceeds to assemble a transaction.
  • the program using the VfT program module, in step SI 09, receives this action as a command to obtain real-time information on the status of the user's bank account (i.e., account number, balance in checking, savings, etc.).
  • the VfT program module executes this command, telling the CDMX program module which user is sending this request, and for which entity, and the CDMX program module accesses the secure "Account Registry” which maintains records of all user-registered accounts, and collects the proper and formal identifying, as well as access-authorizing data, for these accounts.
  • the system can be configured to request the required user passwords as they are needed, and not store any user passwords. Proceeding, in addition to being stored, this access is timestamped and assigned a transaction code by the CDMX program module, before handling this retrieved information to the MaQs program module which executes the request to retrieve information from the real world entity external to the system.
  • step S109 the program queries the user's bank over the Internet and over any secure financial networks necessary to obtain the information.
  • this request is sent from the client to another client or the server, and the client or server to whom the request is sent, performs the query to the bank.
  • the bank queried may also be part of the present system, such that the request is easily handled
  • the user may choose an option -
  • step S 110 the MaQs program module receives the information from the bank at the server, at which point the program passes the retrieved information back to the CDMX program module, including as well, any general system-status or network information that may be provided as a result of issuing a request over that network.
  • the CDMX program module then filters the information it receives in order to pass back to the VfT program module, only the requested information, and thus the real-time status of the user's bank account is provided to the client computer which displays it for the user in step SI 11, on the screen next to the icon or available under a pull-down menu, table, other window, or the like.
  • this query can be performed securely and results are retrieved almost instantaneously, as would a user receive, for example, when attempting to retrieve cash from an ATM machine. Further, since existing secure networks are used, no new physical infrastructure is necessary to perform this query and receive the information.
  • the program can obtain real-time and other information regarding the "Gas Company” (i.e., account name and number, customer service telephone, amount due, past amounts paid, etc.).
  • the user can also perform the same steps to choose a Transaction Object from the "Transaction Objects" section.
  • "Capital Asset Vector” would be an appropriate financial transaction action to place between and connect "My Bank Account” and "Gas Company”.
  • the user may attach the "Capital Asset Vector” between the two entities (i.e., "My Bank Account” and "Gas Company”) in order to make the fransaction a completely assembled fransaction (i.e., payment of the gas bill from the user's bank account) which the program can receive in step SI 13 (see FIG. 15).
  • the "Capital Asset Vector" Transaction Object is attached to both the "My Bank Account” entity and the "Gas Company” entity icons, no transactions take place, execution cannot occur, and a mouseover or other "Properties” check on any of the entities on the Transaction Workpad will produce no display or evidence of results or confirmation for this fransaction.
  • the program in step SI 14, will check the assembly of every transaction to make sure at least the syntax of the assembled transaction is feasible (although it cannot check and avert all user-errors in amounts and selected entities, etc.), before allowing the user to initiate execution (see FIG. 16). Likewise, the program will require the user to set and confirm both the direction of the "Capital Asset Vector"(so that a payment is sent to the Gas Company, rather than a remittance request (ie a refund request or bill presentment from the user to the Gas Co.)), as well as the amount of the capital vector, prior to the assembled fransaction becoming available for execution via user- initiation. In order to assemble a transaction, the user can then left-click on the tail of the
  • the fransaction is fully assembled and becomes an active transaction, having passed the system's transaction- syntax feasibility check and awaiting user-setting and confirmation of transaction object Criticals.
  • a mouseover or other similar "properties" request action available as user-centered design may dictate, of the Capital Asset Vector by the user, will initiate the program to display information detailing the characteristics of that Capital Asset Vector.
  • the program will provide an indication of previous transaction activity using that specific Capital Asset Vector (i.e., payment from specific user- Bank Account, to Gas Co.), and further details may be accessible as user-centered design dictates may be the optimal method of display, referenced by the program as the Transaction History.
  • specific Capital Asset Vector i.e., payment from specific user- Bank Account, to Gas Co.
  • the user may select this option and the program will access a database to provide a display showing previous transactions made between these two specific entities (remitting entity, and receiving entity), including, transaction amounts, dates, etc.
  • the assembled transaction cannot proceed to transition to "available for execution" status until the fransaction object Criticals (i.e., Vector Criticals in this Gas Co. example) are set and confirmed by the user.
  • the assembled transaction will fransition to a state of availability for initiation at the user's discretion.
  • the program may show this transition by changes in the display or presentation, including audio, visual, animation, or changes in state such as brightness, color, shape, dimensionality, placement, or the like.
  • the user may double-click, or right-click, etc., on the Capital Asset Vector, whereby the program, in step SI 15, will open a menu on the display screen, which includes various options, one option being "Vector Criticals".
  • Other Criticals may include such things as currency type (i.e., among possible currencies accepted by the target entity), date of payment, and the option to automatically remit multiple vectors or payments, at different dates, triggered by different external events (i.e., such as confirmation of direct-deposit of paycheck, cunency-exchange target, or the like), etc.
  • the user may set a vector-specific password or, alternatively, set the vector to use the user's system login password, to protect access to this vector's Criticals; this setting may also be confrolled globally by the program, such that all fransaction objects require a password in order to view or change object Criticals.
  • the user may elect for a more secure option of setting this vector or all fransaction entities such that each transaction entity to be accessed will require the user to enter passwords at the time of execution, rather than having the program of the system maintain this private information on file.
  • the user is provided by the program with the option of setting the timing of the transaction under Criticals.
  • the transaction can take place immediately, in real-time, or if the timing of the fransaction is not specified or a later date specified, the fransaction will be set to passive-fill upon execution, which means that the funds may be drawn down from the user's bank account but may be diverted to an investment engine of the system prior to the date where it is to be filled (see Investment Engine below).
  • the program closes the Criticals interface in step
  • SI 17 whereupon the transaction's assembly is complete enough to be executed.
  • the user may wish to save the transaction at this point.
  • the user may save the transaction at any stage, whether the fransaction is completely assembled and feasible, or otherwise, just as one might save and close a text document at any interim stage, and come back to it at a later date for editing or completion, etc.
  • the user should click on "File” in the drop-down menus, and choose “Save”, or may perform this function on the keyboard or the like, whereby the program will provide a dialog box requesting that the user name the Transaction to be saved.
  • the user then enters a Filename (i.e., Regular Gas Co. Payment), and presses "Save", whereby the program, will save the Transaction in step SI 18, and if requested by the user in the future, will make the Transaction available in a drop-down menu or other window of "Transactions", under "Recent”, as may be dictated as optimal for making these files easily available to the user.
  • the user may create and save any number of fransactions, available for re-use or review, editing, adjusting, etc., at any time.
  • the "Test this Transaction” button and the "Prepare for Execution” button mentioned below may change from being dimmed, greyed, dimensionally flat, or the like, to being bright, colored, having dimensional relief and shadow, or the like, to communicate to the user that the button function has transitioned from an inactive or unavailable state to an active or available state.
  • the program will make available a "Test this transaction” button, placed such that the user correctly associates this button with the fransaction concerned and not with any other fransaction or activity in the system, that allows the user to simulate execution of the fransaction prior to actually executing the real thing.
  • the VfT program module receives this action as a command to initiate a check on all entities in the assembled transaction via the MaQs program module, to determine viability (technical, financial, etc.) as well as to process a simulated accounting of all fransaction amounts and resulting changes in all entities, for presentation to user. Note that no capital actually moves during a test.
  • the system can provide a predictive awareness of the user's finances, for the user to make and manage decisions across the range of all user financial activities the user chooses to handle via the system.
  • the program of the system may provide customized decision-analysis and support to the user, based on historical and statistical resources.
  • the VfT program module executes the test command, telling the CDMX program module which user is sending this request, and for which entities, and the CDMX program module accesses the secure "Account Registry” database which maintains records of all user-registered accounts, and collects the proper and formal identifying as well as access-authorizing data for these accounts.
  • the CDMX program module timestamps and assigns this access a transaction code, marked with an indication that it is for Testing (simulation) pu ⁇ oses, before handling this retrieved information to the MaQs program module which executes the request to retrieve information from the real-world entities (which are identified in the transaction via the assembled entity icons) external to the system.
  • the program queries the user's accounts at the relevant real-world entities over the Internet and or over any secure financial networks necessary and available, to obtain the requested information.
  • the request is sent from the client to the server, and the server performs the queries to the external entities.
  • the program directs a query to instigate a background check to verify that the Gas Company system is up and ranning (capable of receiving remitted transaction amounts), determine the required transaction cunency, current fransaction processing time (i.e., real-time, 18 minutes, 2 hours, 4 days, or other timer period, etc.), or the like. Further, in the same step, a similar check is performed of the Bank to verify balance (ensure that the funds are available), that the Bank transaction system is up and ranning (capable of sending transaction amounts), etc.
  • the program receives the information from the various entity accounts, at which point the MaQs program module passes the retrieved information as well as any general system-status or network information updates that may have come as a result of issuing a request over those networks, back to the CDMX program module.
  • the CDMX program module then timestamps, codes, and stores all the received information, again marking the code in such a way that it can be distinguished as a Test. Then the CDMX program module filters the information it receives in order to pass back to the VfT program module only the requested information.
  • the realtime simulated execution data attendant to the user's fransaction is provided to the client by the program which displays it for the user in step S 120, on the screen next to the entity icons or makes it available under a pull-down menu or the like (see FIG. 17).
  • the graphic properties of the entire screen interface and display of a fransaction under Test proceedings, and under actual Execution proceedings may change such that they will be distinguishable, using such differences as brightness, color, dimensionality, size, placement, and the like to readily communicate to the user which proceeding is actually underway and being managed.
  • the program will automatically check that the funds are available at the user's Bank and also that the Gas Company's account is available to accept the transaction. For example, if the user's Bank Account has uncollected funds, or the Gas Company's account is off-line, then the fransaction will not be able to take place, and the program will notify the user in a message in a dialog box, which will pop up or otherwise appear on the display stating that the fransaction cannot take place. The user has the option of retrying the transaction immediately or can program the fransaction to take place at a later time, or cancel the fransaction etc.
  • the user when using the "Test” option, the user will see a visual representation by the program using the VfT program module, of the simulated fransaction.
  • the program may display a money-bag icon on top of the "My Bank Account” icon, which will grow in size; with text characters denoted amounts, which are attached to the money bag icon, increasing in amount until the exact amount set by the user is obtained.
  • the program may, for example, cause to be displayed, a small accounting box attached to the "My Bank Account” icon, which will show the cunent balance at the user's Bank, and in second row a rolling amount, increasingly negative (red), equivalent to the debt equivalent of the positive money-bag increase.
  • the program will cause the vector amount to blink twice within the bag and remain, or some similar indication to communicate completion.
  • the program will display a cylinder icon, for example, over the Gas Company icon, with an attached text indicator of the cunent account balance. If an amount is owed, this text will be negative and red, and the cylinder icon will be empty and its border will be red. If there is no amount cunently indicated as owed, a dollar amount in black will be displayed (i.e., $0.00) and the cylinder icon will be empty, and the border will be black. If the Gas Company account is currently holding a credit amount greater than the invoiced amount, that credit amount will show in green text, and the cylinder icon border will be green, and the cylinder icon will show a small amount of green volume.
  • the program will move Materials from one entity to another, such that the money-bag icon begins to shrink while at same time the Capital Asset Vector, will , for example, show an increase in size moving through it (i.e., as if something large were moving through a pipe, temporarily stretching its diameter as it moved along the length of the pipe).
  • the program will display, for example, the cylinder icon over the Gas Company icon slowly filling up as the transaction progresses (i.e., as if water were filling up inside it), with the text attached to the cylinder icon, numerically indicating the capital influx shown on the cylinder icon.
  • the program will display, for example, a second row of text attached to the cylinder icon which remains at the final amount, and a third row of text which will appear showing the accounting of the transaction (i.e., the net result, either a dollar amount in black (i.e., $0.00) showing the balance paid and the transaction complete with no funds owed, any remaining outstanding balance in (negative red), or credit (ove ⁇ ay) in green text.
  • the program will also display, for example, text attached to the "My Bank Account” icon, showing an accounting of the transaction, with the funds removed from the balance of the bank account.
  • the "Test” feature was described using a particular type of icons, any type of icon can be used, and any type of indicator showing a removal of funds from the user's Bank account to the Gas Company can be used. Accordingly, the description of the user interface which displays the movement of the funds in the fransaction, is for the user's benefit while the program tests the availability of the funds in the Bank Account, and the ability of the Bank to transfer the funds, and the ability of the Gas Company to accept the fransaction, etc.
  • step S 121 the user will be prompted with transaction options via a dialog box, to either "Run Test Again”, “Edit Transaction”, or "Save Transaction".
  • the user may select "Save Transaction", and the program will save the Transaction for subsequent execution or future retrieval, review, editing, and or execution, etc.
  • alert notices of fransaction activation may be sent by the program to the user's designated e-mail account, which notice may include a URL to a secure system webpage, with an interface first requiring the system login and password, then assuming successful user-login, the program will provide a display of fransaction specifics, form windows to take input of required passwords, and provide confirmation check boxes or the like, as well as "Prepare for Execution” and "Execute Transaction” buttons.
  • the program will record transaction specifics and results to the saved transaction files as described elsewhere, available to the user at the next login to the system, updateable automatically to the local-client (i.e., user's PC) the next time the user logs into the system from that (PC) client.
  • the local-client i.e., user's PC
  • the user may click on the button at the bottom of the Transaction Workpad, called "Text Summary of Transaction", whereby the program will display a Test Transaction Summary including all the relevant details of the user's Bank Account, the unique code which the CDMX program module assigned to the Test Transaction, which code may be modified in part at the time of execution to show that the code was tested, and then actually executed (for example, the code may consist of numbers and letters, with one letter "T” indicating "test", and upon execution an "E” may be added to the code.
  • the CDMX program module may easily distinguish, and the user may easily understand, whether a transaction being reviewed was executed, tested, or both, the Transaction amount, the timing chosen by the Vector Criticals, etc, as well as the details about the Gas Company's bill, payment, etc.
  • the user may print this if desired.
  • the user may also print text summaries for either or both the tested transaction, and or the executed fransaction.
  • the summary of the executed fransaction will contain all necessary information and tracking codes to stand as a receipt of transaction, which information shall be sufficient to prove payment was initiated. Since the CDMX program module tracks all fransactions and the entities which are involved in them, the user-printed text summary provided by the program, which includes transaction codes, shall be able to identify the exact fransaction details to the customer service professionals at the real world receiving entities. Since fransactions will be executed over traditional and existing secure payment networks
  • the receiving entity may not care what 3 rd Party (i.e., the system of the present invention) initiated a payment and will simply record the payment along with all others received through the same infrastructure, thus making it easily retrievable for review should the consumer wish to address the customer service departments of receiving entities which were Vector Destination Entities in the system-initiated fransaction, and discuss specific transaction details such as amounts and timing of payments, etc.
  • 3 rd Party i.e., the system of the present invention
  • the user may click on the "Prepare for Execution" button on the bottom of the Transaction Workpad.
  • the program in step SI 22, will cause the Transaction Workpad to shrink, for example, withdrawing to the upper left side of the display screen, and showing only the Transaction entities and the vector connecting them, but in much smaller form.
  • the program will display the Transaction Name as saved by the user, and below the Transaction Name, an accounting ledger or Transaction History, for example in downward-to-current chronological order, showing all historical Transactions (if there are any) made using this particular assembled fransaction and vector.
  • the program will show a final accounting entry showing the date and amount of the present Transaction, as "About to be Transacted".
  • the program will display a "Lock in this Transaction” button at the bottom of the display screen, and the user may then click on this button.
  • the program Upon pressing the "Lock in this Transaction” button, the program will display a vertical rectangular window, for example, which will show dimmed components of the Transaction, including a list of items that need to be checked and verified in all necessary aspects (i.e., sufficient funds in the user's Bank Account, the availability of the Gas Company system online, etc.).
  • the program will then proceed through the checklist of items to be checked and verified, with each item lighting up upon review by the program (i.e., the item will turn red if there is a problem, or green if the fransaction can proceed).
  • the program will display a "Transaction Locked In and Ready to Go” message or the like, as well as a confirmation icon, in step S123, and the program will then activate a displayed "Execute this fransaction" button that is associated with the Transaction Workpad on which the fransaction lies, or the like.
  • Placement of the button on the display should be such that the user conectly associates this button with the fransaction concerned, and does not confuse it with any other fransaction or activity in the system. (This button would have transitioned to a state of active availability for use at the user's discretion. This fransition may be recognizable in changes that include such things as audio, visual, animation, or state changes in brightness, color, shape, dimensionality, placement, and the like).
  • step SI 24 The user may then click on the "Execute this Transaction” button, and the program, in step SI 24, will clear the contents of the vertical rectangular window and will display a new list of execution items for the Transaction as well as a vertical progress-downward highlighted bar.
  • the program in step SI 24, will clear the contents of the vertical rectangular window and will display a new list of execution items for the Transaction as well as a vertical progress-downward highlighted bar.
  • the completed item will turn green, for example, and get a checkmark to its left, for example, and the progress bar will continue downward on the list.
  • the program will access a pre-determined set of instractions of items to be verified, depending on the transaction type, object-entity (i.e. remit, request, buy, sell, etc.), and party-entity (i.e., Bank, Insurance Company, Utility, etc.) involved.
  • object-entity i.e. remit, request, buy, sell, etc.
  • party-entity i.e., Bank, Insurance Company, Utility, etc.
  • the shrunk fransaction and vector assembly will repeat the graphic display described in the test, in conjunction with each actual proceeding step in the execution process.
  • the Execution process rans "Release Partitioned Amount”
  • the moneybag as described during the Test procedure will begin to drain and move through the vector, etc.
  • the program also provides a unique Transaction Number to the Transaction which Number can be tracked by all the parties to the Transaction (i.e., Bank, User, Gas Company).
  • the program Upon completion of the Transaction and the assignment of the Transaction Number, the program, in step S125, will display a Comprehensive Transaction Record which will include a diagram of the vector Transaction, all account details, institutional contact information, and the specific official transaction-system time- stamp data, as well as the Transaction Number.
  • the user may then print out the Comprehensive Transaction Record for the user's records, or simply save digital copies locally or on the server (network records would automatically be kept according to banking regulations.).
  • the user may also export transaction specifics to any major financial accounting software (such as Quicken T ivi)- Conversely, it is envisioned that major financial accounting software will have the capability to execute the Transactions enabled by the present invention from within such applications, with all summary data being returned directly to the financial software's logs, etc.
  • the saved Transaction becomes a template for future transactions, whereby the user can reopen the saved Transaction and perform another vectored fransaction at a future date, needing only to confirm the Criticals, and execute.
  • copies of existing saved transactions may be made, in order to rapidly edit these into new fransactions which are similar to the original. An example of this may be if the user wishes to create a second "Payment to Gas Co.” fransaction assembly, but with a different remittance entity in place of the original Bank account.
  • the user would first click once on the existing saved transaction file icon, then, going to the "File" pull-down menu, select "Duplicate Transaction File", where the program will produce a carbon copy of the existing saved fransaction, its name automatically adjusting to reflect that it is not the original, but a carbon copy. The user may then double-click this carbon copy, and the program will allow the user to edit, replace, and adjust any or all of the entities.
  • the benefit to the user in doing this is that all settings for entities in the carbon copy will remain the same as they were in the original (although they could be changed at the user's discretion), so that, for example, the Vector direction would already be properly set as required to make the remittance to the Gas Co.
  • the distributed finance system consistent with the present invention is a third-party platform, a user can maintain a single account, and via the same account and login system, monitor any number of diverse accounts, whether bank accounts, credit card accounts, utility bills, various loans, investment portfolios, etc., and build, test, and execute transactions from any or all of them as desired using empirical fransaction party- entities and fransaction object-entities as described in part herein.
  • a Traditional Compound financial transaction can be assembled, tested, and executed, similar ot the Traditional Simple fransaction.
  • the Traditional Compound Transaction involves two entities which are not normally connected in traditional financial systems. Since the Traditional Compound Transaction can take many various forms, three examples will be described. Further, since the user interface has been described in detail with respect to the Traditional Simple transaction, the user interface will not be described in detail hereafter.
  • the user may then continue with the same process as described in the Traditional Simple Transaction. For example, the user may wish to choose “My Stocks", and by mouseovering the "My Stocks" icon, the program may access the user's account and obtain and display any real time data related to the account. In one example consistent with the methods and systems of the present invention, the user may chose "My Stocks", and “My Auto Loan” - the cunent auto- loan in question having, for example, 18 months of payments left to make.
  • the user may now build a fransaction using these two icons and a Transaction Object icon - "Sell" - to sell whatever stocks the user wishes, and then user a Capital Asset Vector to direct the liquid capital to pay out the Auto Loan in full - as a single programmed fransaction, with everything recorded and managed by the distributed finance program of the present invention.
  • the user may assemble the transaction, test it, modify it, and then execute it as one transaction.
  • the user may assemble the transaction, test it, modify it, and then execute it as one transaction.
  • the MaQs program module will take care of communicating with the marketplace and executing the commands that are stractured using the VfT program module and coded using the CDMX program module.
  • the VfT program module will keep a viewable record of all fransactions, updated by info ⁇ nation fed from the MaQs program module and the CDMX program module.
  • the VfT program module will save the fransactions and make them available for review and fracking pu ⁇ oses, to analyze amounts, counte ⁇ arty account numbers, times, etc.
  • the user may choose an option such as “Query”, and may choose from a number of options such as “Loan”, “Insurance”, etc.
  • the user may choose “Loan”, at which point the program will prompt the user to enter various loan parameters (i.e., "Set Loan Parameters” option).
  • the program will query the marketplace (i.e., banks, credit card companies, etc.), or the distributed capital system community (to invite a multitude of lenders to participate in syndicating a loan), for loans of the user's specifications, and return real-time information on interest rates, credit data, etc.
  • the user may do so, and may do so on-line, either with a single counte ⁇ arty such as a bank (which would constitute a Traditional Simple fransaction), in the traditional manner, or with a multitude of lenders, in syndicate fashion, automatically orchestrated by the present program of the invention (which would constituted a Collaborative Simple fransaction).
  • this initial activity is in this example hereafter linked to successive transaction activity, and becomes a component of a Traditional Compound transaction.
  • the transaction types are not restricted to being used only as independent transaction types, but may be combined to achieve whatever streamlined result the users can come up with..
  • the user may then deploy the loan funds to pay off the user's credit cards or child's college loan, etc., for example.
  • the Transaction is similar to the Traditional Simple transactions in that the user brings up the "My Loan” icon, the “My Credit Cards” icon, and “My College Loan” icon, connects them with a "Transaction Object” such as "Capital Asset Vector", and uses the loan funds to pay off the credit card and college loan bills (see FIG. 18).
  • the user may program speculative activity, where as in Example 1, the user wishes to "Sell" stocks, but only at a particular price.
  • the program will provide the user with an option to set the parameters of the sale (as in Example 2, where Loan Parameters are set). Since the stock price can be obtained in real-time by the program and displayed for the user, the user will know if the stock price is lower than the price at which the user wishes to sell.
  • the program can provide the user with options to sell the stocks when the price the user wants is achieved, with the program testing the transaction in the marketplace at any interval, in realt-time, as programmed by the user, or to sell the stocks at a particular time or date, whatever the price of the stocks is at that time, etc. (i.e., "Set Sale Parameters" function is provided as part of the menu, similar to that of "Set Loan Parameters").
  • the program also inco ⁇ orates functions like frailing-stop-loss monitors such that users could preset the system to invest in certain financial instruments at a certain triggered event, and have the system automatically exit the investment, delivering profits back to the user's bank account accordingly, should the exit-trigger be tripped.
  • the user may program any type of speculative (or non- speculative) activity which can take place at a future time, according to the parameters set by the user.
  • the program upon automatic execution of the Transaction when the parameters are met upon the "Test", the program can automatically_(or upon request by the user) notify the user that the programmed Transaction has occuned, by providing a message to the user when the user logs in, or an e-mail to the user on the user's computer, or to his mobile telephone, pager, or mobile organizer, etc.
  • the Transaction can be performed remotely, securely, and automatically through the distributed finance system of the present invention.
  • the user may set up an investment opportunity or other fund-raising activity, which is extended to other system users.
  • the "investment opportunity" is set up by the user on the Transaction Workpad, similar to what is described in the Traditional Simple Transaction example, except that this type of fransaction is offered to a predetermined number of users, or otherwise defined or constrained such as with a ceiling amount of desired investment funds (for example, for raising money to donate to a charity, or inviting others to invest in co ⁇ orate securities).
  • the user can then use the menu options, for example, to create the list of users
  • the distinction of the type of user participating in this kind of transaction may be visibly displayed on the user interface, perhaps with the named, specifically invited parties represented with a square object (FIG 19), and parties unnamed but qualified per preset constraints represented with circles (FIG 19).
  • the CDMX module of the program will provide a unique parent transaction number for the offering, and then for each invitee user name a child code; also, CDMX will generate unique offering transaction invitee passwords for distribution to each invitee listed.
  • the user can access the menu and pull down Options, where the user can adjust various constraints on the fransaction, for example a time limit on the acceptance and/or participation in the transaction (i.e., 30 days).
  • the program will automatically notify those users' system accounts, such that the next time those users log into their accounts, they will see notice of the offering opportunity, perhaps in the form of a blinking icon, etc.
  • the system Upon acknowledging, with a mouse-click for example, the notice of invitation to participate in the opportunity, the system will request input of the specific offering fransaction password. If the user does not have this password, the offering will not be accessible.
  • the invitees will receive their individual offering- specific passwords either via e-mail, (or by phone, post, etc.) In this way, the user owner of the transaction would have to mistakenly identify an invitee TWICE in order for the wrong person to accidentally gain access to a fransaction that was not intended for him or her (once in identifying the said invitee to the system, and once again in communicating with the invitee, presumably by sending e-mail with the specific offering fransaction password to the same wrong person.
  • the user will be given access to the "investment opportunity" by the system, via for example, during mouseover, or by right clicking on the mouse to pull up a menu, or dialog box, or the like.
  • the transaction details will be provided in real-time by the program, and the program will provide all information to the user (i.e., amount requested, date requested, other investors, amounts other investors have provided, etc.).
  • the invitee may then be reviewed to the "investment" fransaction details.
  • the program will delete the icon from the Transaction Workpad screen and in one example, provide the invitee with a means to send a comment to the offering party.
  • the user may also exit the transaction without accepting or declining in the even the user wishes to review the transaction again at a later date.
  • the user can click "accept”, for example, and can then proceed to set up a fransaction similar to that of the Traditional Simple transaction, where, for example, the user accesses a bank account to remove money to pay an entity - in this case, the "investment opportunity”.
  • the user can Test the fransaction and Save it. Further, the user can set up a payment scheme to pay into the "investment opportunity", similar to the way that the user would set up a payment of a bill from a store using funds from his bank account or mutual funds account etc., which may include set or variable amounts remitted at regular or random intervals. Once the full amount is paid into the "investment opportunity", the program will close or make unavailable the icon, and the user will have a fransaction record of the amount paid into the "investment opportunity" similar to that obtained when a bill is paid.
  • This investment opportunity transaction event may not be re-usable in terms of investing again at a later date, however that fransaction file may remain on the invitees client and be updated with real time information about the investment asset. In this way, even a one-time transaction event may be updated with real time information.
  • two system users may wish to collaborate in a purchase on-line.
  • the purchase will require a number of different amounts of funds from each one or multiple of the two users banks accounts, credit cards, etc., to remit to the third person selling the item.
  • the seller does not need a special account to receive collaborative transactions, since the program can direct, via the MaQs program module, payments to existing accounts via existing infrastracture.
  • the fransaction is built much like in Example 1 , where a "purchase opportunity" can be built where a first user can invite the second user to pay into the "purchase opportunity” until collaboratively the purchase amount is reached. At that point, the first user can "invite” the seller to sell. To achieve this the first user will have the "purchase opportunity" automatically be sent to the seller via the program of the system, and then separately notify the seller either via e-mail, verbally, etc. of the specific opportunity password.
  • Example 1 can be used one step further, with a foreign currency exchange component.
  • the "investment opportunity" identified as icon 1 on the Transaction Workpad
  • icons 2-5 potential participants, identified as icons 2-5.
  • the user can set up a foreign exchange component (identified as the vertical bar between icon 1 and the user (large bank account icon at left), where any one of the entities to the transaction can supply funds in one cunency to have it automatically converted into another cunency.
  • Collaborative Compound This transaction is the most sophisticated of the four embodiments, and the one for which the system was primarily designed. In Collaborative Compound transactions, millions of users, for example, can be united in their pursuit of their financial goals. As stated previously, in Collaborative fransactions, both sides of a transaction are considering themselves to be customers, and in doing so, fulfill each others' provider roles. Often the customers have no direct awareness of each other, and the present invention is simply using the Collaborative Compound embodiment to make the transaction more efficient or less costly or both.
  • the program utilizes all the major program modules, such as the VfT, SVR, CDMX, and MaQs program modules.
  • Example 1 Thus, in one example consistent with the present invention, and as previously described briefly with respect to Collaborative Compound fransactions, a user's company may require British Pounds for certain activities. The user will access the system website and build a "Change Cunency" transaction in step S200 of FIG. 20, on the Transaction Workpad, using the steps to assemble the fransaction using the VfT program module, as described, for example under the Traditional Simple transaction. Once the user has built the transaction, the user can test, and execute the fransaction if desired, as has been previously described.
  • the program When tested, the program will query, using the CDMX program module and the MaQs program module, to obtain real-time market currency rates in step S201, country, or counte ⁇ arty data, if the user has indicated that he cares to know such info, and it is available, to present the user with the information such that the user can make the determination of whether the user would like to execute the fransaction.
  • the user will be able to program the transaction such that the program can keep querying the marketplace at scheduled intervals until the cunency reaches a certain exchange value, or the user can program the fransaction to occur on a certain day, etc., as has been described previously with respect to other simpler fransactions.
  • the scheduled transaction is designated a passive-fill or passive type transaction by the program by default, unless indicated by the user to be performed immediately (i.e., real-time), or by event trigger, which is the fixed type.
  • step S202 the program will invoke the CDMX program module to codestamp or assign a unique transaction number (i.e., parent code) in step S203 to track the fransaction through the system.
  • the program will preserve the recorded information regarding the fransaction in encrypted form using the CDMX program module, and confirmation data is passed back to the VfT program module by the program in step S204, which provides this information to the user via the user interface.
  • the program invokes the MaQs program module, and the SVR program module to execute the transaction.
  • the SVR program module will match counte ⁇ arties to achieve the desired fransaction in step S206.
  • the transaction vectors are separated according to direction and amount type (e.g., cunency pair) and ranked by value.
  • the SVR program module then proceeds to cross-match according to the varying algorithms described previously.
  • an amount is originally classified by the program as active-seeking, the program will seek to fulfill the request with a single counte ⁇ arty match amount. Further, if an amount is originally classified by the program as passive-seeking, then it will be reduced by active-seeking amounts until it falls below the mean and is reclassified to become an active-seeking amount itself, after which it is filled and the fransaction is completed.
  • the matching of a request to exchange dollars for British pounds, and a request by another user to exchange British pounds for dollars can be matched using at least one of several algorithms. Regardless of what algorithm the program uses for the exchange (and this algorithm is programmable), the SVR program module will always produce counte ⁇ arty match-pairs.
  • the program will match a request for British pounds by the user with a matching request for U.S. dollars by another user holding British pounds. If there is a larger amount on one side than the other, and there is a non-zero remainder left on either side after a match is made, then the program matches the remainders on another pass through the system. For example, as a large fransaction passes through the system, the SVR program module will break up the fransaction amount into a number of pieces, and match each one to a different counte ⁇ arty in successive transaction passes through the system.
  • the CDMX program module will be invoked to codecycle and track the individual parties (tag the match pairs) through the counte ⁇ arty matching resolution (vector-spreading) process in step S207, and to create several additional child-codes to track the different or successive pieces of the transaction through the matching process, and make the transaction pieces traceable to the parent fransaction, until all remainder amounts are matched or resolved.
  • Each of these codes are logged in an accounting tracking ledger by the CDMX program module, and sent to accumulate in the Codematch Aggregator (further described below) in step S208. After the matches are made, the CDMX program module will reassemble the transaction pieces, prior to payment execution, such that the end result is the accomplishment of the desired transaction.
  • the program invokes the Codematch Aggregator function of the CDMX program module for collection (aggregation of same-user transacted amounts), and netting (amounts are netted) in step S209, before the program invokes the MaQs program module to execute the funds fransfer instractions from the user's account to the appropriate user-destination account, which sum equals the full, originally intended transaction, performed over the existing financial systems infrastracture.
  • the Codematch Aggregator program may, according to programmed setting, wait to activate the Bank Multiplexer program so that the fransfer of funds to the user account can be batched in step S210.
  • the CDMX program module will log the confirmation and fracking information of the executed transaction.
  • SDEX real-time, immediate fransfer
  • CDEX fixed and passive-fill
  • user accounts may be initially remitted to a system-owned account (see Investment Engine below), for holding, during and after the time counte ⁇ arty matches are resolved by the SVR program module, until the precise user -indicated fransaction takes place.
  • the system may at its own programmed discretion, draw down funds immediately for holding in the base cunency, or convert and hold in the target cunency, until the user's prescheduled transaction comes due and calls for the funds.
  • the program notifies the user of the completion of the transaction, and the deposit of the target currency to their account, and the debit of the conesponding amount in their currency, plus any fees from their own account, via messages within their login account, e-mail, or by phone, cell phone, fax, or any other medium desired. Fees debited for the fransaction are channeled to the system-owned account by the program, as profits.
  • Example 2 As shown in a second example consistent with the present invention , in FIG.
  • the CSFB's -44 amount is an active-seeker, which the program cross-matches to the CSFB +120 in FIG. 2 IB, creating a 44 zero-sum pair, and leaving a system remainder of CSFB +76 (see FIGS. 21 A and 21C).
  • the program active-seeks the JP +32 to create a 32 zero-sum pair (see FIG. 21 A), leaving JP -88 in the system, which the program immediately matches with the active-seeker Bob +12, creating a 12 zero-sum pair and leaving a JP -76 in the system (see FIG. 21C).
  • the program creates for the CSFB +76 and JP -76, the final zero- sum pair for the period, leaving the system empty (confirming the zero-sum for the universe) (see FIG. 21C).
  • the Macro Ledger zero-sum pairs are listed in FIGS. 21 A and 21C, and when a zero-sum pair has the same counte ⁇ arty on both sides, it can be eliminated by the program, producing the empirically reduced Macro-Ledger of FIG. 21C.
  • the empirical Macro Ledger of FIG. 21C displays the most efficient capital vectors (amounts and directions). If all the amounts were transfened independent of netting, 164 units of capital would move. If single party netting is used, 100 units of capital move (88 from JP to CSFB, 12 from CSFB to Bob). If Spread- Vector netting is used, only 88 units move (as indicated in the macro empirical ledger below - JP moves 12 to Bob, and 76 to CSFB).
  • Example 3 In another example consistent with the present invention, on a larger scale, instead of a single user changing funds into British pounds, a country, like the United States, could pay the United Nations US$4 million in back dues, converted to Euros, for example, to be deposited in a Geneva bank account. The present system can execute such a compound transaction and match the individuals and business in Europe (that hold Euros and are seeking Dollars) with the request for Euros by the U.S., to resolve a perfect collaborative match among thousands or millions of unknown counte ⁇ arties. The present system's efficacy is not limited strictly to cunencies, but to anything that may be treated as a fungible instrument of trade.
  • the system described herein cannot avert liquidity crises, however the program can give early warning of such things given daily volumes monitoring, etc., and due to the fact that the transactions can be programmed and scheduled (passive-fill), some degree of moderation may result as the system could be programmed to execute pre-scheduled passive-fills during periods of slackening liquidity.
  • DFT Distributed Funds Transfer
  • Example 4 In another example of a Collaborative Compound fransaction consistent with the present invention, an exchange of capital funds can be made between two companies, self-selecting each other, or randomly matched, which have capital management needs that are complementary to each other. If for example, an American company wishes to repatriate RMB profits earned in China, back to the US (as US Dollars), there are likely to be restrictions on transferring funds out of China. And if a US company wishes to have a supply of US Dollars converted to RMB for the sake of new investment in China, there are likely to be restrictions on bringing in new capital.
  • the SVR program module executing a Distributed Funds Transfer process, could, given proper settings of target bank accounts, simply resolve a vector schedule that comprised of two domestic transfers, one in each the US and China, to each the opposite company's accounts from the local company's account. At face value this would appear to be two independent, unrelated domestic movements of funds, but as a macro event would amount to the two companies swapping their hard cunencies via a distributed system. In this way, the two companies could each achieve their objectives to move money across an international boundary, but without the difficulties, notice, cost, and possible restriction on international capital movements.
  • the program will prompt the user to wait until a system-suggested date, or to cancel the transaction for a later time. Once the fransaction can be executed, the funds are drawn from the bank accounts of both parties to the transaction, and the program will fill the requests and remit the amounts in the target currency to the users' bank accounts.
  • the program - via the CDMX and MaQs program modules - will aggregate distributed capital flows through a revolving door holding account, with funds being used to temporarily hold risk-free or low-risk investments.
  • the passive transaction type is the default type, and is characterized by the user indicating that the transaction must occur by a certain date. This means that any time up until that date may be constraed as a date which is acceptable to initiate, execute the fransaction, and use the capital. Accordingly, the system can pull the funds of a passive-fill transaction, and hold those funds in the account for short-term investments. Further, for certain immediate fransactions, such as cunency exchange, the system may charge a fee premium.
  • the program i.e., the MaQs program module
  • the program may remove the user's funds immediately from his account and move the funds to a holding account within the system, and the funds - along with other funds from other temporarily held accounts - may be invested in money market accounts, or savings accounts at traditional financial institutions, etc., which have low or zero risk (because the funds must be returned to the owners or sent along the way to finishing the transactions they started out completing), even if the owners have given their approval for investments.
  • the program automatically pulls market data and checks what types of financial instruments are available within the necessary risk parameters, and determines the opportunity cost of capital for each choice (i.e., cost of entry, exit, and capital requirements).
  • the program then checks the rate of capital vector flow and egress into/out of the system and the rate, as well as the rate of capital vector flow into the codematching system, and determines the "optimal" capital exercise option which provides the best return for the required system liquidity level (i.e., rate of capital drawdown by the Bank Multiplexing function, and the system desired rate as called for by the Codematch Aggregator function).
  • the program waits for matches to occur, then the program remits the funds where they need to go, albeit form a source account that is owned by the system, and not the original user's account. Individual accounts may be used to generate this investment directive, or a percentage of the aggregate of capital flowing through the system can be used. The user may know or not know that the money is being used for investments.
  • the profits engendered by the investments can either be returned to the user by the program, if the user so directs (i.e., the user can set up a transaction to take place at a later date, authorizing the funds to be removed immediately and placed in a money market account until the transaction takes place, with the profit being returned to the user while the initial fransaction amount moves forward to be executed); or the profits can be directed by the user to be, perhaps aggregated, and used for philanthropic pu ⁇ oses.
  • the system profits can also be reinvested automatically, to aggregate funds for capital purchases to update the system, or for philanthropic pu ⁇ oses at a later date etc.
  • particulate tax-credits can be automatically issued back to each source by the program, and further, the program can grant allocation votes commensurate to each particulate amount. Allocation votes allow each participant to have a democratic say in how the philanthropic funds are to be used, with available options orchestrated by professional philanthropic experts. Further, the present system could issue tax credits, based on a weighted average from the record logs, from its philanthropic activity back to the users as a benefit for the capital they allowed the system to use.
  • the MaQs program module periodically automatically checks the system to ensure that there is enough liquidity to readily facilitate the proper functioning of the system. If the system is severely asymmetrical (based on the arithmetic mean, or the like, or a fluctuation of more than 10 percent, for example, variation with the Oppside) the program will automatically use new capital by opening itself to fraditional banking channels such as JP Morgan, which may be interested in a new source of business, or in the event that the owners of the system wish to put some of its own capital, system profits could be used (i.e. invested in the operations of the business) This capital infusion would be transparent to the users, and codematching would continue without stopping with any unmatched requests simply passing through the system over and over until filled.
  • JP Morgan fraditional banking channels
  • the system in addition to a philanthropic motivation for the aggregated funds or profits engendered in the above operations, the system would encompass more-sophisticated functions which can become entire systems onto themselves.
  • the program could offer a credit service operation, extending credit to a system user, group, small business, or even large co ⁇ oration, and issuing credit and/or ATM cards, similar to what banks offer presently (in this case, since the system is tied into the user's accounts, it can easily perform a credit rating on the user when the user requests a credit card or credit line or loan); or the credit rating could be generated on a distributed basis as explained below.
  • This credit rating may be generated in conjunction with the CDMX program tracing function of actual payments, rather than relying on 3 rd party credit bureaus such as Equifax, et al.
  • the credit ratings may follow that of EbayTM, whereby account usage would be the
  • the basis for the user credit rating could also proceed a number of other ways, including being based upon some mathematical equation that takes an existing credit score input to arrive at a non-zero initial rating for each user.
  • the initial credit-score input could be a formal credit-bureau score, or an adapted one based on the submitted record(s) of a user's credit card usage, manipulated by the program via some algorithm, to arrive at a range or a specific number, which would be the initial credit rating that the user could then use to begin participating in the collaborative environment.
  • the system could offer a direct-lending system where users of the system can rate and lend/bonow from other system users (whether individuals or co ⁇ orations), as well as from the system itself if the system should have accounts activated for that pu ⁇ ose.
  • a user can offer funds to other remote users (which may be used in Africa for example) at a defined interest rate and payment schedule, and bonowers can bonow money at a certain interest rate and payment schedule, and the bonowers/lenders need not be aware of each other since the program automatically debits the accounts of the borrowers and credits the accounts of the lenders at the scheduled times and will even automatically execute cunency conversions to repatriate loan repayments.
  • microlending Another example is microlending.
  • the microlending model architected by the Grameen Bank Project uses a peer-to-peer network-effect, albeit offline, and on a very small and local scale.
  • microlending can be facilitated on a global-local scale, making it possible for individuals to easily and swiftly direct their own capital flows toward any comer of the planet they choose.
  • collaborative object model of the present system supporting the same network-effect peer-relationships (i.e., self-selecting committed individuals)
  • the potential to bring unprecedented speed and fluidity to involvement, commitment, and funds flow to humanitarian efforts, rescue efforts, emergency efforts, etc. is within reach.
  • the user can select "Pay with The system" as the payment option.
  • the system screen will be selected, and the program will prompt the user for his login and password (a specific password for only on-line purchases can be set up as well).
  • the user can confirm his purchase at the Transaction Workpad screen, and using the system-merchant identification code, and any other identification code (such as for the item being purchased, or the purchase order number), can exchange currency as in the above Collaborative Compound fransaction.
  • the CDMX and MaQs program modules will track the purchase and execute the fransaction, and fransfer the target cunency funds to the merchant account, and debit the user's account of funds.
  • the program will notify the merchant that the funds have been provided and that the transaction is complete, and will also notify the user of the debit of funds from his account.
  • non-native ATM cards can use any ATM machine in any bank-domain and not utilize Plus or Cirrus or other similar networks (which would incur fees).
  • Quantified Access means granting a temporary and quantified amount of access to deduct funds in a bank account not owned or associated or linked or in anyway associated with the ATM card which draws down the funds.
  • the permission granted to the ATM card is such that any bank or any bank's ATM will recognize the
  • the process is as follows, a user goes to an ATM machine which is not native to the domain that his or her ATM card can use fee-free. This may be in any cunency domain as well - it does not matter- since the system can execute the exchange transaction as required, which process is explained in detail below.
  • the user inserts a card, it is validated as a valid card by the ATM computer, where the computer checks for validation that the given ATM card is connected with a valid bank account at a real bank in the world.
  • the user is usually prompted with a screen that indicates that there will be a charge of $1.50 or some similar amount for the fransaction if it is not a free transaction for a native bank user.
  • the system may be set by the users, to frack activity on accounts registered therein. If users have set their accounts to be responsive in this way, then, as soon as the user approves the potential fee charge for ATM usage on the ATM screen, the system program will be notified of the pending bank deduction for the ATM withdrawal, and will take over the fransaction, not allowing the banks to proceed.
  • the program will halt the proceeding at the banks, not allowing a deduction at the home bank, nor allowing cash-dispersal from the ATM.
  • the program then moves funds from the user's account using the bank multiplexer program module, to any account X within the ATM domain that is being used for the cunent transaction, similar to what may occur given the willingness of any owner of such account X within such domain, to lend funds to quantified access for the user to withdraw.
  • the CDMX program module updates the tracking logs accordingly.
  • the bank which owns the ATM is sent information by the program indicating that the non-native ATM card that was read at the ATM, has native-level quantified access to account X. Funds are immediately dispersed from account X, leaving its balance in the original state (logs will show an instantaneous deposit and withdrawal of the same amount), and no fees are charged because the bank recognizes it as a native-ATM card withdrawal.
  • quantified access means that permission is provided by the program to deduct certain defined and limited amounts of funds from an account that the user does not normally have access to, such that the bank will recognize the ATM as a native account.
  • the ATM card is temporarily and for a quantified amount only, being recognized as an ATM card linked to account X.
  • any generic account at the Bank should work, which means that if the system opens and maintains a bank account in any and all bank-domains, then it could simply use its own bank accounts and grant quantified access that way, essentially offering all the system users a shared account, thus bypassing ATM fees in any and all domains, anywhere worldwide.
  • the present system can make any conventional funds fransfer a distributed funds transfer, dispersed to a thousand different directions in small amounts, shifted via transitive resolution and collected at the destination as smaller-amount transfers that would converge to sum to the original amount.
  • the SVR program module could do this such that the dispersion pattern is undetectable, which implies certain security or safety inherent in the system since external observation of the transfers would not yield any insight into the method of dispersion..
  • a funds fransfer, or elecfronic funds fransfer is the intentional targeted movement of funds over a network, from point A to point B.
  • a distributed funds transfer is a method for using existing funds transfer networks, to the effect that a macro zero-sum awareness of the funds-flow universe allows for a vector polarization of funds-flow toward and away from two chosen points (i.e., the sender and receiver) such that the net at each the sender and receiver is fulfilled according to the directions of the original intended fransfer, WITHOUT funds moving directly from the sender to the receiver.
  • a remote entity R makes it known to the network certain information regarding the desire and intention to move funds from some point A near itself to some point B remote from itself in the physical, geographic world, some entity S may be considering a desire and intention to move funds from some point F near itself to some point G remote from itself in the physical, geographic world.
  • funds transfers are pursued each independently, in complete vacuum from any other fransfer being carried out over the funds transfer networks.
  • the program can watch via awareness propagation, for near-to-far and far-to-near funds fransfer notices, and using preset algorithms at all participating clients, servers and servents, the program can achieve for example, a redirection of funds such that the total summed distance of all funds movement was minimized.
  • This may for example, mean that instead of moving funds the long haul from A->B, and also the long haul from F- G, that two smaller transfers F- B, and A- G lower system-wide risk by reducing total amount of capital per time at risk, and fulfills the obligations of all parties.
  • the program first receives the user's command to send funds, via some funds fransfer network. Then, the program of the system client/server/servent discovers via awareness propagation, an intended funds transfer targeting its own institution or one nearby. The client/server/servent of the present system identifies direct communication pathway to that remote client/server/servent, and opens communications. The two clients/servers/servents trade information about their intended fransfer vectors, recording locally the net vector position intended at each target (recall a vector is a 2-dimensional entity, in this case containing amount information, and direction information).
  • Optimal is defined as the most efficient vector or vectors as computed in the context and extent of the period-awareness vector-universe.
  • the present system brings the same relentless reroute-until-delivery-is- achieved reliability to fungible instrument fransfer, as TCP/IP brought to communications via the Internet.
  • Transaction vectors will be encrypted while in the system, providing complete privacy to all users of the system. However, vector amounts, directions, and identities may be decrypted separately at the order of legal authorities.
  • the present invention's program may provide filters that recognize and alert system administrators to potential laundering type or tax evasion type activities.

Abstract

Methods, systems, and articles of manufacture consistent with the present invention provide for conducting financial transactions over a network (22). A user (10) requests to execute at least one financial transaction with at least one of a number of parties, each of the parties corresponding to a data processing system on the network (22). Real-time financial information relating to the financial transaction is obtained, and the user can test and confirm that the financial transaction with the at least one party can take place prior to execution of the financial transaction.

Description

APPARATUS AND METHOD OF A DISTRIBUTED CAPITAL
SYSTEM
The present invention relates generally to an apparatus and method of an automated distributed finance or capital system which can perform a plurality of financial transactions over a global computerized network.
BACKGROUND OF THE INVENTION In financial services, geography is a formidable barrier, especially when the geographic distance (time-difference) is compounded by currency, legal, and political domain differences. Despite all the claims of future horizons and full systemization of the world economy, straight through processing and streamlined operations, there is still no organization delivering an architecture specifically designed to handle integrated global financial services.
SUMMARY OF THE INVENTION The present invention relates to an apparatus and method of an automated distributed capital system which can perform a plurality of financial transactions over a global computerized network. In particular, the distributed capital system (DCS) of the present invention can manage transactions that fall under two broad categories: Traditional (Individual), and Collaborative (Multiparty). These two categories cover the transaction spectrum, and the DCS of the present invention detailed herein covers the assembly, testing, execution, and management of transaction events (such as bill payment, foreign currency exchange etc.), which are unique.
Specifically, the DCS of the present invention handles, among other transactions: bill payment structuring, management, and execution; invoicing structuring, management and execution; funds transfer initiation and management; distributed (dispersed) funds transfer (DFT) initiation and management, including repatriation of funds without international transfer; direct exchange of fungible units, whether symmetric (i.e., parties on each side of transaction hold equivalent value, to be exchanged in full with opposite counteφarty) or asymmetric (parties on each side of transaction hold different value amounts) - specifically curcencies, between parties worldwide (without intermediary brokers or 3rd party financial institutions); automated foreign exchange market; programmed credit card payment scheduling; avoidance of the payment of ATM fees worldwide; on-line purchasing transactions in different currencies without requiring traditional currency-exchange transaction; a consumer credit and direct lending system; a distributed credit-rating system; a syndication system that handles micro-to-massive amounts from unlimited participants; and programmed speculative investing individually or in collaboration with others. Specifically, aspects of the present invention relate to an automated distributed capital system that can perform a plurality of financial transactions over a computer network, such as the Internet. The distributed capital system (DCS) of the present invention manages any type of financial transaction between any number of parties. Therefore, for example, if a party desires to execute a financial transaction for a certain monetary or exchange value and the first counter-party cannot execute the transaction for the full monetary or exchange value, the DCS of the present invention automatically obtains additional counter-parties until the transaction can be fully executed. Accordingly, as long as there is enough value distributed among the various parties on the network, the DCS of the present invention can execute financial transactions for any value.
The party initiating the financial transaction can choose the counter-parties or the DCS of the present invention can automatically obtain those counter-parties.
Further, the counter-parties can be located anywhere on the network. Therefore, if the network is for example the Internet, methods and systems consistent with the present invention are not limited to geographical boundaries. The DCS of the present invention can execute transactions between parties in various countries, and automatically exchange the respective exchange currencies.
Accordingly, the distributed capital system allows any number of parties to collaboratively transact any amount of value with any number of counter-parties, arranging for independently market-driven rates and terms and handling the transfer of value. This is performed without, for example, an intermediary such as a broker. Since there can be any number of parties and counter-parties, the DCS can execute financial transactions involving, for example, a single party and a single counter-party (traditional simple), a single party executing several traditional simple transactions at the same time (traditional compound), a single party and multiple counter-parties (collaborative simple), and multiple parties and multiple counterparties (collaborative compound).
In accordance with methods consistent with the present invention, a method in a data processing system having a program is provided. The data processing system is connected to at least one of a plurality of remote data processing systems via a network. The method comprises the steps performed by the program of: receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; obtaining real-time financial information relating to the financial transaction; and confirming that the financial transaction can be executed with at least one party.
In accordance with methods consistent with the present invention, a method in a data processing system having a program is provided. The data processing system is connected to at least one of a plurality of remote data processing systems via a network. The method comprises the steps performed by the program of: receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; obtaining real-time financial information relating to the financial transaction; determining a monetary or exchange value of the financial transaction; determining whether the at least one party that will execute the financial transaction for the monetary or exchange value; and confirming that the financial transaction can be executed with additional parties to the at least one party until a total monetary or exchange value for which the parties will execute the financial transaction is equal to the determined monetary or exchange value of the financial transaction responsive to the identified at least one party not executing the financial transaction for the monetary or exchange value. In accordance with articles of manufacture consistent with the present invention, a computer-readable medium containing instractions that cause a data processing system to perform a method is provided. The data processing system is connected to at least one of a plurality of remote data processing systems via a network. The method comprises the steps performed by the program of: receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; obtaining real-time financial information relating to the financial transaction; and confirming that the financial transaction can be executed with at least one party. In accordance with articles of manufacture consistent with the present invention, a computer-readable medium containing instructions that cause a data processing system to perform a method is provided. The data processing system is connected to at least one of a plurality of remote data processing systems via a network. The method comprises the steps performed by the program of: receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; obtaining real-time financial information relating to the financial transaction; determining a monetary or exchange value of the financial transaction; determining whether the at least one party that will execute the financial transaction for the monetary or exchange value; and confirming that the financial transaction can be executed with additional parties to the at least one party until a total monetary or exchange value for which the parties will execute the financial transaction is equal to the determined monetary or exchange value of the financial transaction responsive to the identified at least one party not executing the financial transaction for the monetary or exchange value.
In accordance with systems consistent with the present invention, a data processing system connected to at least one of a plurality of remote data processing systems via a network is provided. The data processing system comprises: means for receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; means for obtaining real-time financial information relating to the financial transaction; and means for confirming that the financial transaction can be executed with at least one party.
In accordance with systems consistent with the present invention, a data processing system connected to at least one of a plurality of remote data processing systems via a network is provided. The data processing system comprises: means for receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; means for obtaining real-time financial information relating to the financial transaction; means for determining a monetary or exchange value of the financial transaction; means for determining whether the at least one party that will execute the financial transaction for the monetary or exchange value; and means for confirming that the financial transaction can be executed with additional parties to the at least one party until a total monetary or exchange value for which the parties will execute the financial transaction is equal to the determined monetary or exchange value of the financial transaction responsive to the identified at least one party not executing the financial transaction for the monetary or exchange value.
In accordance with systems consistent with the present invention, a data processing system connected to at least one of a plurality of remote data processing systems via a network is provided. The data processing system comprises: a memory comprising a program that receives from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems, obtains real-time financial information relating to the financial transaction, and confirms that the financial transaction can be executed with at least one party; and a processing unit that rans the program.
In accordance with systems consistent with the present invention, a data processing system connected to at least one of a plurality of remote data processing systems via a network is provided. The data processing system comprises: a memory comprising a program that receives from a user a request to execute at least one financial fransaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems, obtains real-time financial information relating to the financial transaction, determines a monetary or exchange value of the financial transaction, determines whether the at least one party that will execute the financial transaction for the monetary or exchange value, and confirms that the financial transaction can be executed with additional parties to the at least one party until a total monetary or exchange value for which the parties will execute the financial transaction is equal to the determined monetary or exchange value of the financial transaction responsive to the identified at least one party not executing the financial transaction for the monetary or exchange value; and a processing unit that runs the program. In accordance with articles of manufacture consistent with the present invention, a computer-readable memory device encoded with a program having a data structure is provided. The program is run by a processor in a data processing system connected to at least one of a plurality of remote data processing systems via a network. The data structure has a plurality of entries, each entry comprising: a first storage area that stores a monetary or exchange value of a financial transaction; and a plurality of second storage areas that each store an identity of a party to the financial transaction and an amount for which the party will execute the financial fransaction, the program confirming additional parties and amounts for which the additional eligible parties will execute the financial transaction until a total amount for which the parties will execute the financial transaction is equal to the monetary or exchange value. There has thus been outlined, some features consistent with the present invention in order that the detailed description thereof that follows may be better understood, and in order that the present contribution to the art may be better appreciated. There are, of course, additional features consistent with the present invention that will be described below and which will form the subject matter of the claims appended hereto.
In this respect, before explaining at least one embodiment consistent with the present invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. Methods and apparatuses consistent with the present invention are capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein, as well as the abstract included below, are for the puφose of description and should not be regarded as limiting.
As such, those skilled in the art will appreciate that the conception upon which this disclosure is based may readily be utilized as a basis for the designing of other structures, methods and systems for carrying out the several puφoses of the present invention. It is important, therefore, that the claims be regarded as including such equivalent constructions insofar as they do not depart from the spirit and scope of the methods and apparatuses consistent with the present invention. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a schematic diagram showing a client-server environment, according to one embodiment consistent with the present invention.
FIG. 2 is a schematic diagram showing a distributed network environment, according to one embodiment consistent with the present invention.
FIG. 3 is a schematic diagram showing more detail of the client and the server in a client-server environment, according to one embodiment consistent with the present invention.
FIG. 4 is a diagram showing a balanced request with single mean by the Spread- Vector Resolution program module in fulfilling a financial transaction, according to one embodiment consistent with the present invention.
FIG. 5 is a diagram showing a balanced request with multiple means by the Spread- Vector Resolution program module for fulfilling a financial transaction, according to one embodiment consistent with the present invention. FIG. 6 is a diagram showing an asymmetric matching being processed by the
Spread- Vector Resolution program module for fulfilling a financial transaction, according to one embodiment consistent with the present invention.
FIG. 7A is a diagram showing an all-seek opposite-side match being processed by the Spread- Vector Resolution program module for fulfilling a financial transaction, according to one embodiment consistent with the present invention. FIG. 7B is a diagram showing a capital infusion into the system to be made available to the Spread-Vector Resolution program module, according to one embodiment consistent with the present invention.
FIGS. 8A and 8B show Spread- Vector Netting according to one embodiment consistent with the present invention.
FIG. 9 shows the function of the Code Division Multiple Transaction program module according to one embodiment consistent with the present invention.
FIG. 10 shows the function of the Code Division Multiple Transaction program module according to one embodiment consistent with the present invention. FIGS. 11A and 11B depict a flowchart which shows the operation of the
Traditional Simple transaction according to one embodiment consistent with the present invention.
FIG. 12 is a screen shot of the Transaction Workpad of the user interface according to one embodiment consistent with the present invention. FIG. 13 is a screen shot of the Transaction Workpad of the user interface according to one embodiment consistent with the present invention.
FIG. 14 is a screen shot of an unassembled Traditional Simple transaction on the Transaction Workpad of the user interface according to one embodiment consistent with the present invention. FIG. 15 is a screen shot of an assembled Traditional Simple transaction on the
Transaction Workpad of the user interface according to one embodiment consistent with the present invention. FIG. 16 is a screen shot of a transaction syntax approved Traditional Simple transaction according to one embodiment consistent with the present invention.
FIG. 17 is a screen shot of a real-time simulated execution data attendant to a Traditional Simple transaction, according to one embodiment consistent with the present invention.
FIG. 18 is a screen shot of an assembled Traditional Compound transaction according to one embodiment consistent with the present invention.
FIG. 19 is a screen shot of an assembled Collaborative Simple transaction according to one embodiment consistent with the present invention. FIG. 20 is a flowchart of a method of conducting a Collaborative Compound fransaction according to one embodiment consistent with the present invention.
FIG. 21 A is a table showing a macro ledger kept by the Code Division Multiple Transaction program module in a Collaborative Compound transaction according to one embodiment consistent with the present invention. FIG. 2 IB is a diagram showing the parties to a Collaborative Compound transaction being processed by the Spread- Vector Resolution program module, according to one embodiment consistent with the present invention.
FIG. 21C is a table showing a macro ledger empirically reduced, which is kept by the Code Division Multiple Transaction program module in a Collaborative Compound transaction according to one embodiment consistent with the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Methods and systems consistent with the present invention makes possible automated distributed financial services available over a global computerized network. Among other things, the system of the present invention allows individuals to collaboratively lend (any particulate amount) to any person or company and arrange for independently market-driven rates and terms, and then also allowing the system to handle repayment distributions. A distributed capital system converts currencies without a broker, at any amount desired, and matches counteφarties for equities, bond or other fungible-instrument trades faster and cheaper than traditional methods. The distributed capital system consistent with the present invention includes the concepts of scalability, network-effect, and open community.
Methods and systems consistent with the present invention include an expansive system designed to support network collaborative fransaction services. Since this collaborative format is more sophisticated and requires more system architecture than conventional systems, current transaction structures (one-to-one commerce relationships) are enabled as a subset of the functionality of the collaborative embodiment of the present invention.
System Architecture
One embodiment of the present invention is now discussed with reference to the Figures which depicts a financial system suitable for practicing methods and systems consistent with the present invention. The present invention may be carried out in a client-server environment (see FIG. 1), or may be carried out in a distributed environment, where only client computers are utilized (see FIG. 2). Thus, in the present invention, a particular operation or service may be performed either at the client or the server, at the edge of a network or at center, or both. Therefore, at either the client or the server, or both, corresponding programs for a desired operation/service are available. In the present invention, even though a pair of corresponding programs at the client and the server, respectively, perform the same operations from the viewpoint of the user, they may execute different operations internal to the systems, including having operations performed completely at client computers in a distributed financial network, as shown in FIG. 2.
More particularly, in the distributed financial network of the present invention, every node on the network has a set of closest neighbors, and each node shares its awareness-universe with its neighbors. Thus, a query can be autonomously related back to the requesting party. The present invention terms this an "awareness propagation". Thus, the operations of the present invention can be provided solely by client computers as shown in FIG. 2.
However, at least one client computer, and perhaps, at least one server computer, may preferably be used to practice the methods and systems consistent with the present invention.
In the client-server environment, at least one client and at least one server are each connected to a network (see FIG. 1), such as a Local Area Network (LAN), Wide Area Network (WAN), and/or the Internet, over a communication link. The steps in the methods consistent with the present invention, are carried out at the client or at the server, or at both, the server, if used, being accessible by the client over, for example, the Internet, using a browser application or the like. Specifically, the client shown in FIGS. 1-3, may be a personal computer, a mobile terminal, such as a mobile computing device, a mobile phone, or a mobile data organizer, operated by the user in accessing the financial services remote from the client (i.e., at the server). Even though only two clients are shown in Fig. 1, one of ordinary skill in the art would be aware that there may be a plurality of similar clients connected to other clients or servers.
The client computer 10, as shown in FIG. 3, typically includes a processor 11 as a client data processing means or mechanism, the processor 11 including a central processing unit (CPU) 12 and an input/output (I/O) interface 13, a memory 14 with program 15 having a data structure 16, all connected by a bus 17, as well as an input device or means 18, a display 19, and may also include a secondary storage device 20. The bus 17 may be internal to the client 10 and may include an adapter to a keyboard or input device 18, or may include external connections.
The data structure 16 may include a plurality of entries, each entry including at least a first storage area that stores a monetary or exchange value of a financial transaction, and a plurality of second storage areas that each store an identity of a party to the financial transaction and an amount for which the party will execute the financial transaction., the program confirming additional parties and amounts for which the additional eligible parties will execute the financial fransaction until a total amount for which the parties will execute the financial transaction is equal to the monetary or exchange value. The data structure can also have alternative embodiments including that associated with the match codes or other stored information as one of ordinary skill in the art would appreciate from the following descriptions.
In methods and systems consistent with the present invention, the client 10 is connected to other clients 10 or servers 30 via a communication link 21 as a client communication means or mechanism, using a communication end port specified by an address or a port, and the communication link may include a mobile communication link, a switched circuit communication link, or may involve a network of data processing devices such as a LAN, WAN, the Internet, or combinations thereof. The communication link 21 may be an adapter unit capable to execute various communications protocols in order to establish and maintain communication with the server 30. The communication link 21 may be constituted by a specialized piece of hardware or may be realized by a general CPU executing conesponding program instructions. The communication link 21 may be at least partially included in the processor 11 executing conesponding program instractions.
The processor 11 at the client 10 may be internal or external thereto, and executes a program 15 adapted to predetermined operations. The processor 11 has access to the memory 14 in which may be stored at least one sequence of code instructions comprising the program 15 and the data structure 16 for performing predetermined operations. The memory 14 and program 15 may be located within the client 10 or external thereto.
The program 15 can include a separate program code for performing a desired operation or service, or be part of a module of a larger program providing the service. The program 15 may also include a plurality of modules performing sub-operations of a service, as described further below.
It is understood that the processor 11 may be adapted to access and/or execute a plurality of programs 15 corresponding to a plurality of services/operations.
An operation or service rendered by the program 15 may be, for example, supporting the user interface, performing e-mail applications, setting up financial transactions, etc.
The input mans 18 of the client 10 may include standard input devices such as a keyboard, mouse, or a speech processing means.
The storage device 20 stores at least one data file, such as text files, data files, image, audio, video files etc., in providing a particular service for a user. The data storage device as storage means 20, may be for example, a database, including a distributed database connected via a network 22, for example. The storage device 20 may be connected to the server 30 and/or the client 10, either directly or through a communication network, such as a LAN or WAN. An intemal storage device, such as 20, or an external storage device 23 is optional, and data may also be received via, for example, a network 22, and directly processed. If a server 30 is used in a non-distributed environment, the server 30 would include a processor 24, having a CPU 25 which is a server data processing means or mechanism and an I/O interface 26, but may also be constituted by a distributed CPU 25 including a plurality of individual processors 24 on one or a plurality of machines. The processor 24 of the server 30 may be a general data processing unit, but preferably a data processing unit with large resources, i.e., high processing capabilities and a large memory for storing large amounts of data.
The server 30 also includes a memory 27 with program 28 having a data structure 29, all connected by a bus 31. The bus 31 or similar connection line can also consist of external connections, if the server 30 is constituted by a distributed system. The server processor 24 may have access to a storage device (i.e., storage device 32) for storing preferably large numbers of programs for providing various services to the users, i.e., for performing various financial operations as desired by users operating clients 10. The data structure 29 may include a plurality of entries, each entry including at least a first storage area that stores a monetary or exchange value of a financial transaction, and a plurality of second storage areas that each store an identity of a party to the financial transaction and an amount for which the party will execute the financial transaction., the program confirming additional parties and amounts for which the additional eligible parties will execute the financial transaction until a total amount for which the parties will execute the financial transaction is equal to the monetary or exchange value. The data structure can also have alternative embodiments including that associated with the match codes or other stored information as one of ordinary skill in the art would appreciate from the following descriptions.
The server 30 may be a single unit or may be a distributed system of a plurality of servers 30 or data processing units, and may be shared by multiple users in direct or indirect connection to each other. The server 30 performs at least one server program 28 for a desired operation, which is required in serving a request from the client 10.
The communication link 33 from the server 30 is preferably adapted to communicate with a plurality of clients 10.
The server program 28 may relate to providing a number of operations related to providing financial services to a user, such as allowing a user to assemble a financial transaction, to test a proposed financial transaction, to ensure that each fransaction request is codestamped with a unique transaction number and tracked securely through the financial system, etc.
Note that at times the system of the present invention is described as performing a certain function. However, one of ordinary skill in the art would know that the program is what is performing the function rather than the entity of the system itself. Although aspects of one implementation of the present invention are depicted as being stored in memory, one skilled in the art will appreciate that all or part of systems and methods consistent with the present invention may be stored on or read from other computer-readable media, such as secondary storage devices, like hard disks, floppy disks, and CD-ROM, a carrier wave received from a network such as the Internet, or other forms of ROM or RAM either currently known or later developed. Further although specific components of the system have been described, one skilled in the art will appreciate that a system suitable for use with the methods and systems consistent with the present invention may contain additional or different components. It is noted that the above-described features and processing operations may be realized by dedicated hardware or may be realized as programs including code instructions executed on data processing units. It is further possible that parts of the above sequence of operations are carried out in hardware, whereas other of the above processing operations are carried out using software.
Further, methods and systems consistent with the present invention are carried out by providing a user selection means, including selection buttons, in a menu, dialog box, or a roll-down window of an interface provided at the client, and the user may input commands through a keyboard or the like. The selection means may be constituted by a dedicated piece of hardware or its functions may be executed by code instructions executed on the client processor, involving a display unit for displaying a selection window and a keyboard for entering a selection, for example. Program Modules One embodiment of the program (at least either 15 or 28 or both) of the present invention includes four major program modules: Vector- flow Topography (VfT), Code-Division Multiple Transaction (CDMX), Spread Vector Resolution (SVR), and Matrix Quartermaster (MaQs). Each program module is independently capable of supporting various new financial services, and can be used individually in other applications; but connected together, working in tandem and with other program modules further described below, they create the distributed capital system platform consistent with the present invention.
However, one of ordinary skill in the art would know that there may be additional modules or programs that could be used to achieve the features of the present invention, or that the program modules could be combined into a single program for the same puφose. Further, the features and processing operations of the four major program modules may be realized by dedicated hardware, or may be realized as programs including code instructions executed on data processing units. It is further possible that parts of the above sequence of operations are carried out in hardware, whereas other of the above processing operations are carried out using software. As stated above, the following program modules consistent with the present invention, may be run by the parent program of the distributed capital system architecture, and can be part of a client-server environment, or part of a distributed platform of client computers.
1) Vector-flow Topography Program Module The Vector-flow Topography (VfT) program module runs the user interface and enables the streamlined construction, testing, and management of transactions of all types. The VfT module allows a user to rapidly construct financial fransactions with visual objects arranged and connected on an on-screen Transaction Workpad, and then test the proposed flow of instruments and funds, payments, debits, account balances, etc. prior to execution. The VfT program module also receives and displays various data, confirmation, and other indications to the user following a transaction or at any other time after initial entering of transaction specifics into the system.
Thus, users can construct and save fransaction events, and reuse them as often as desired. The VfT program module will allow the user to easily access the history of all executions and testings of the constructed transactions, which information is to be tracked by the CDMX program module, see below). In this way, the user may review any and all details of any of his/her transaction events at any time.
While capable of assembling and executing simple transactions like bill- payment, etc., the VfT program module also handles sophisticated, complex, or so- called "compound" transactions, where "compound" is defined as constituting multiple, or compounded, interim steps or transactions to achieve the desired commercial result of position. The VfT program module's "drag and drop" capability allows compound transactions to be easily assembled, tested and executed.
2) Code-Division Multiple Transaction (CDMX) Program Module
The CDMX program module runs the tracking and accounting which makes the distributed capital system of the present invention possible. The CDMX program module handles two types of data simultaneously (financial and communications) securely and privately, preserving and using the relationship between the two dimensions, but nonetheless retaining complete separation, confidentiality, and anonymity of the transmissions. The CDMX program module thus employs both a communications protocol and a transaction protocol, and monitors and matches precise data requirements, allowing random-party connections to be achieved (which is handled by the algorithms in the SVR program module, see below) completely random parties according to a macro sense of counteφarty matching. The CDMX program interfaces with the multiple-mean matching engine (the SVR module - see below) to complete the random-party matching, attaching appropriately devised tracking codes to the amounts in the DCS of the present invention. Even when the financial vectors are broken up into different, smaller components, or whether they are recombined later, the CDMX program module keeps track of all the components as they go through the system within a zero-sum accounting environment.
The CDMX program module will track four types or categories of user- programmed transactions: Real Time, Passive, Fixed, and Installment. Real-time means instantaneous processing, whether at execution of the transaction request or when set times have expired; Passive means that the user does not determine the timing or amount of the processing, and the system executes the request at random and/or optimal times before the user indicated time limit expires; Fixed means the user has indicated a set of requirements for execution, and that the transaction will not occur unless triggered by the requirements being met; and Installment consists of combinations of the other three types (can be the same transaction taking place at predetermined times, for example), and when entered into the system are disaggregated into the smaller component transactions, each tagged with a special parent code linking all installments to the overall parent transaction.
The protocols for CDMX module were designed so that the program can unwind and trace backward to the originating account, any transaction, regardless of whether it is a Traditional Simple event, or a Collaborative Compound event
(described in more detail below), with every transaction detail preserved and recorded by the CDMX module ledgers in the appropriate databases. Even in a distributed environment, where Distributed Funds Transfer (DFT) transactions are abundant and intended target accounts are not immediately visible, the CDMX program module allows the CDMX ledgers of the program, or even a very small subset of distributed clients/servers/servents, to reconstruct the dispersion post facto, achieving a rewinding review of the funds transfer networks, to determine the details (i.e., what, how, how much, who, etc.) of any Distributed Capital System transaction.
The information that the CDMX program module records, will be preserved in encrypted form even at distributed clients/servers/servents, unavailable to anyone except by a deliberate act by the system monitors, such as due to official legal action like a subpoena, etc. The CDMX program module may also contain a built-in function that resides on the distributed devices, that automatically sends archived CDMX data for reconciliation, to a centralized collection monitoring server, etc. The CDMX program module of the present invention executes the following functions: a) Codestamping, b) Codecycling, and c) Codematch Aggregation. Note that the Codestamping and Codematch Aggregation sub-programs have procedural relationships with the Matrix Quartermaster module (further described below), and the Codecycling sub-program executes an iterative process that involves repetitive exchanges with the Spread Vector Resolution program module (further described below).
With respect to Codestamping, Codestamping occurs whenever any NEW activity is initiated. All transaction event requests that enter the system are codestamped using the Codestamping sub-program, and the program assigns a unique transaction number that will be the parent code that relates the requested transaction to the user who entered it. This unique fransaction number is inclusive of some unique identifier of the person or account initiating the fransaction, as well as a coding unique to the fransaction.
Note that in Collaborative fransaction events (described below), the program may duplicate the fransaction number (since there is more than one participant in a transaction (i.e., counteφarties)), but the parent codestamps will each be unique since any transaction number will have a unique user-account identifier attached to it.
The program also executes a Codecycling function, that tags matched pairs in a Collaborative fransaction, each time the SVR program module (see below) completes (resolves) a counteφarty match. If Codecycling is required for the type of transaction requested, the Codecycling program module will create several additional child-codes to track each of the component amounts that are allocated and directed according to the Spread-Vector Resolution (SVR) program module, which are traceable to the parent transaction. The recording may be preserved in encrypted form by the program.
The program also executes a Codematch Aggregation function whereby the CDMX program module aggregates all available transaction amounts for a single user or account, in order to net the amounts or optimize activity before passing the data to the Matrix Quartermaster (MaQs) program module for execution.
Note that Codecycling is not necessary to handle either of the Traditional Simple or Traditional Compound (further described below) transaction types.
3) Spread- Vector Resolution (SVR) Module The SVR program module takes an input of multidimensional (i.e., vector) objects, and automatically isolates each dimensional quantity, processing them independently before execution occurs. The advantage of isolating dimensional quantities before processing, is that efficiency in each dimension may be captured more fully, rather than just capture the efficiency available or accessible at the intersection of multiple dimensions treated together. In other words, the SVR module can get at efficiency that is otherwise locked up in the complexity of constrained (i.e., multidimensional) objects.
Thus, conventionally two payments from two unconnected users, cannot be treated together, because the single dimension of the payment amount is complicated by the other dimensional variables of those payments, such as identity of Payor and
Payee, which make the two payments as multidimensional objects quite unrelated to each other. The SVR program module however, can isolate each dimensional value, and process them separately. In practice, this means that it executes the inclusion of completely unrelated parties together in the same netting summations. It is a matching utility, including various algorithms, that achieve efficiency in assigning counteφarty matches. The SVR program module handles digital representations of financial vectors (i.e., which can be combined and manipulated mathematically yielding for example condensed or combined vectors that resolve all commitments of the component vectors), intaking them, outputting this information to a system (described below) which can account for everything accurately, and then execute the resolved vectors. The SVR program module is designed specifically to operate where counteφarties in a Collaborative Compound transaction (see below), are not equally balanced, i.e., when there is an unequal balance of value between the two sides of a fransaction environment. In these asymmetric situations, the SVR program module processes fransactions without delay, resolving the asymmetry via vector-flow particulation. As is described in greater detail below, SVR matching allows the zero- sum "market-mechanism" of large liquid markets with theoretically large numbers of participants to be brought to limited-participant transaction environments. Although on a per-transaction level non-zero-sum accounting may instantaneously be evident, the macro vector flow freatment of the system transaction universe will adhere to zero-sum principles and as successive flow is processed, all prior fransactions will come into zero-sum compliance, thus there should be an exact matching by the program, leaving no amounts resident on either side. The CDMX program module keeps a macro ledger which is complete when there are no remaining values in the system to be matched in a given period.
In this way, the SVR program module executes a netting function, funds fransfer algorithms, currency exchange algorithms, consolidated accounting algorithms, loan syndication, and ATM-sharing, etc. (further described below). Algorithms Used in SVR Program Module
In detail, one potential algorithm used by the SVR program module for filling a Collaborative Compound transaction (see below for detailed description) is shown in FIG. 4, where there are counteφarties requesting exchanges of yen to dollars, and dollars to yen.
In FIG. 4, the Nearside denotes a reference used to explain the exchange process of this potential algorithm. Nearside is a pre-process state. Since every exchange is composed of a currency pair, the Oppside is the reference to the requests in the target (counteφarty) currency which will be used to execute exchange fransactions. Thus, optimal efficiency occurs when the total number of Oppside requests required to fill a nearside request is minimized. The program prioritizes exchanges on this basis. Note that active-seeking class amounts are preferably filled with a single Oppside amount.
Thus, upon entry into the system, the SVR program module will automatically classify the amounts to be exchanged as active-seeking, when the amount is below an arithmetic mean, for example, or passive-fill, if the amount is above the arithmetic mean. Note that this arithmetic mean constantly changes as the program recalculates the arithmetic mean depending on the amounts of vectors/funds flowing through the system.
Note that all requests are characterized by the SVR program as realtime requests at or near the time they are actually processed. Since there will be a population of passive requests, which come from user-programmed transactions that don't have single-point fixed time (i.e., on some date) or event-triggered execution specifics (i.e., when the Dow Jones index reaches 10,000, for example) , but rather time-period limit specifics (i.e. by some date), an active reclassification requested by the program may call upon this storehouse of passive transactions, to convert some or all to real time, processing them to bring liquidity to the system, and attempt to create a seamless progression of moderated volatiltiy (i.e., consistent liquidity).
Further, in some cases, the program may have multiple means and provide a volume-average separator to distinguish between the two means (see FIG. 5). For example, when the volume of the transactions increases enough to activate a preset trigger, the program will accommodate this increased vector flow by creating a new parallel channel to process the volume. The trigger bifurcates the volume into sections, each one acting like the previous single-divider program function (see FIG. 4). When the larger vectors in the upper half as shown are resolved and the matches occur, remainders will drop into the lower half, and as the volume decreases, a preset trigger is tripped and the program will remove the separator, returning the program function to its original single-divider state. Active-seeking amounts will target passive-fill amounts in the respective target currency. No two potentially matchable requests can actively seek each other. If an amount is originally classified by the program as active-seeking, the program will seek to fulfill the request with a single counteφarty match amount (see FIG. 4). If an amount is originally classified by the program as passive-seeking, then it will be reduced by active-seeking amounts until it falls below the mean and is reclassified to become an active-seeking amount itself, after which it is filled and the fransaction is completed.
Thus, the matching of a request to exchange currency can be matched using several algorithms - with the active-seeking transaction on the Oppside being matched from a passive-fill fransaction on the Nearside, or vice-versa, or by a staggered linear match, or an angled Nearside all seek opposite-side match (see FIG.
7A).
In normal activity of markets and trade, sometimes there occurs a disparity in the vector flow. Just as there are instances everyday where sellers are offering something at some price E but the abundance of buyers are only willing to pay a much lower price D, the lack of liquidity visible to the system from direct participants may be represented as a pair of triangles , with one side much larger than the other, indicating a large volume of vectors available (i.e., "sellers") with too few counteφarties (i.e., "buyers") on the other side.
This imbalance may be in reference to trans-currency events, or domestic events that are structured as directional coutneφarty matching, or any number of other situations where one side of a fransaction type is more abundant than the other. The SVR program module will take an inflow of self-selected vectors, the self-selection guaranteeing that all vectors have at least one variable which is the same. For example, in domestic Distributed Funds Transfers, the currency is the same for all vectors, and it is the direction variable that is match-paired. In cunency exchanges, direction is not important and so the match-pair basis is the currency-pair. In the event of this kind of disparity, the system will process as much as it can, which means until all available vectors on one side have been processed, leaving the imbalance in an empirical state with zero available vectors on the opposite side (see FIGS. 6 and 7A).
When this happens, it could be due to a macro-world liquidity crunch, or more likely, it could be due to a small user-population (at least when the system is still being introduced and there simply aren't enough people signed up to ensure that liquidity won't be an issue). In this event, the program of the system could be preset to direct the remaining one-sided vector-flow toward more fraditional channels where liquidity can be provided by an interbroker for example, and the owners of those vectors can get their transactions fulfilled (i.e., a capital infusion from fraditional channels - see FIG. 7A). In this way, the user may not recognize the switch of liquidity pools, from system participants to third-party big-bank interbroker/trader. Accounting Netting
In the context of coφoraet enteφrises, for example, which entities have transactions and financial relationships with many counteφarties, when an enteφrise has a multitude of transactions during a set period of time, there will likely be liabilities (negative) and receivables (positive), and often there will be positive and negative transactions with a same counteφarty. Rather than net the same-party transactions to get a single result for that one relationship , the SVR program will defer the specific netting process, and instead, sums all parties' period-negative and period-positive values (across all parties that the enteφrise has to deal with). Thus, direct same-party netting is preferably bypassed in favor of setting the stage for macro spread-netting amongst all parties in the transaction universe. Transaction Spread- Vector Netting (S VN) Spread- Vector Netting or Distributed Direct Exchange, is a multi-party compaction, and is possible when any party, anywhere, is transacting. The SVR program module when executing the SVN function, can handle any and all transaction sizes, individual or institutional. A much larger number of participants is possible than with conventional netting. In SVN, multiple parties are always populating the spread-net, , and cross-liabilities and linked settlement are not necessary. Conventional netting demands both a fixed number of participating parties, as well as a fixed time period over which to net. Spread-netting requires neither of these. Complexity is not likely correlated to the number of parties, and risk is likely to be inversely corcelated to the number of parties.
To spread-net out a liability circle (which is defined as a number of debtors in a circular arrangement such that remittance of payment to fulfill the debt obligation may halt as each debtor in the circle waits to be paid) in SVN, the program nets as is described under CPN, but instead of maintaining the vector relationships as is, the program redirects any vectors necessary such that the net result in/out for each Party is the same absolute value that it was prior to netting (see FIGS. 8A and 8B). In tracing the transactional directions of Party D owes Party A, and Party C owes Party D, after spread-netting, the program allows Party D to compensate Party C and Party B - a complete opposite of the transactional direction for the former, and a completely new relation for the latter. Spread-netting appears to deliver more than a 50% improvement in risk-reduction over conventional netting. Thus, the total transacted is 34, with the netted physical settlement being 8, and the reduction in amount at risk being 26/34=76%.
4) Matrix Quartermaster (MaQs) (aka the Distributed Banking Lending Credit (DBLO) Program Module
The Matrix Quartermaster (MaQs) program module is the negotiating manager that takes conclusive aggregate transaction information as an input, converts that information to execution instructions, and then initiates the execution of the transactions over whatever infrastructure is required, and uses whatever protocols that already exist, and deals with multiple accounts and systems to ensure that all parties' transactions are achieved. The MaQs program module works with the CDMX program module or similar tracking-modules , to activate the execution of capital movement. The MaQs program module carries out the instructions over existing infrastracture. The MaQs program module holds or incoφorates various API's that allow it to interact with the rest of the financial and banking world. This includes a vast range of entities, including, for example, the American Clearing House, the Federal Reserve Fedwire system, ECN's such as Archipelago, Instinet, and Island, Credit Card companies, banks, utilities companies' accounts, Web Merchants, etc.
The MaQs program module packages the execute commands assembled by the Vft program module and the user-account information provided by the CMDX program module, into proper and formal execution instractions according to the infrastructure being used to carry out the fransaction. Since multiple infrastructure networks may be used, the MaQs program module is able to package transaction commands into a variety of formatted execution instructions.
Thus, the MaQs program module executes the transactions that are created, programmed, resolved, or otherwise in the distributed financial system of the present invention. The MaQs program module is the link to the greater network of markets, product and service providers, and of course, customer accounts at banks and all other relevant entities (such as utility companies, insurance companies, etc.). In the event that the system has its own accounts involved in operations (as may be necessary to implement certain functions or services, such as ATM Sharing or the Investment Engine, see below), the MaQs program module will take capital vectors out of the system and supply capital vectors into the system. The program includes bridges between the present system and other systems in the market (i.e., stock market funds, New York Stock Exchange etc.), such that the program will be able to pass data retrieved from accounts and markets through to the system for display and manipulation. No new secure-system infrastructure required. Bank Multiplexer API
The following describes an example of one kind of API that may be component to the MaQs program module. Instructions or market data-feed which enter the system and instructions which are executed and handled for distribution to the user bank accounts, are handled by the Bank Multiplexer program. "Multiplexer" is used here to indicate that the same API may in practice be used duplicatively to simultaneously connect to more than one account or institution. Note that the program of the present system does not handle transactions exclusively in serial order, but rather, will execute multiple fransactions at the same time. .
The Bank Multiplexer program for example, reads the identifier codes on each processed transaction amount, and franslates these into various financial network instructions, for example direct-deposit and direct-debit instructions to be sent to the bank accounts registered with the system. It is possible that when passive requests enter the system, an additional code will direct the program to draw down these programmed transaction amounts at different times, and deposit them into a system-owned account, for use in the investment engine until needed to execute the programmed fransaction (see further below). The program, which runs the investment engine, will employ the aggregated funds as needed, at the end of which it will remit the original exchange-matched amounts to the appropriate end-user counteφarty accounts, retaining the profits in the system account for further use. 4) Code Division Multiple Transaction (CDMT) Program Module Code-Division Multiple Access is a telecommunications technology specifically designed to maintain the interlinked connection (i.e., a voice/data fransmission) between single source-sink pairs interlaced with lots of others, for the specific puφose of increasing bandwidth over the same communications infrastructure. Code-Division Multiple Transaction (CDMT), working in conjunction with Spread Vector Resolution, does not concern telecommunications bandwidth provision, but rather the matching of fungible-trade counteφarties, and furthermore, is distinguished by the fact that it does not fix the counteφarties on each end of transactions for the entire duration of a transaction (unlike CDMA which can only take a set input, delivered to a set output for the entire duration of a connected session, eg., a phone call, cannot and does not randomly switch between unknown parties during the middle of a call). In fact the two technologies CDMX and SVR working together can link, switch links, and add new links on either counteφary side to a multiplicity of random counteφarties, who are otherwise unrelated and may remain anonymous if desired.
However, the Code-Division Multiple Transaction (CDMT) program module of the present invention, working in conjunction with SVR program module, does not concern telecommunications bandwidth provision, but rather executes the matching of fungible-trade counteφarties, and furthermore, is distinguished by the fact that it does not fix the counteφarties on each end of transactions for the entire duration of a transaction (see FIG. 10).
In fact, the program utilizing the CDMX and SVR program modules, working together, can link, switch links, and add new links on either counteφary side, to a multiplicity of random counteφarties, who are otherwise unrelated and may remain anonymous if desired.
Because financial transactions are conducted in a zero-sum framework, every counteφarty pair must consist of a balance of value or the transaction cannot be considered valid, and in practice, won't occur. The program via the CDMX program module, makes it possible for example, for anonymous buyers and sellers to be automatically matched simply based upon price (i.e., when there are a multitude of buyers and sellers at the same price, the system will automatically code-divide the incoming trade-requests such that the zero-sum can be spread to a non-symmetric number of counteφarties) (see FIG. 10). Hence, five sellers of US dollars (who are also buyers of Japanese yen), are served by just three counteφarties (see FIGS. 9-10). There is no need for any of the counteφarties to know or be aware of one another.
Sign-up
First, a participant must sign up as a system member. In general, to sign up an create an account with the system of the present invention, the participant would simply have to have an e-mail account in order to go through a standard opt-in procedure, initiating the usemame and password at the website, for example, and having that website take basic user information in order to create an account file, then sending the opt-in verification request to the supplied e-mail address.
Upon verification the user account would become active and the user could either download a distributed client application, and then go about inputting various account and financial data to give the new distributed capital account access clearance to any 3r party accounts the user wanted to be able to manipulate from within the distributed capital account, or, the user could feed the same kind of information to a centralized server for the same puφose.
However, the user may not be provided with complete access to the system at sign-up, but rather, may have to proceed through staging, with minimal functionality available to the user upon initial signup (such as the ability to execute fraditional simple fransactions, and limited traditional compound transactions), but additional more powerful tools (i.e., collaborative fransactions) becoming available through demonstration of awareness of, familiarity with, and or adherence to, financial regulations, risk profiles, investment structures, tax rules, etc., perhaps via online seminars and tests, according to the number and value of transactions executed, and proof of sophisticated investor status, etc.
For Enteφrise applications, the present system would support multiple access passwords and user-clearance levels, such that for example a CFO would have Master privileges and full functionality over the Coφorate system account, and therefore the greatest freedom to manipulate and manage assets of the coφoration, while the lower- level finance personnel may have access to the same accounts for visibility reasons, but without the Master privileges to manipulate or manage.
This approach means bringing the very advanced art of challenge-ramp design so visible in video-games, to financial services provision. By integrating a challenge- ramp that incoφorates educational or problem-solving interaction, as well as typical user statistic hurdles, it is possible to create an interactive environment built around financial services.
The credit rating system explained further below, may drive a classification system, in much the same way that in role-playing games, greater powers or strength (such as a more powerful sword, or greater wizardry spells) accrue to users who accumulate certain artifacts or techniques along their journey. Thus, the present system may classify users according to Financial Skill, Capital (or Asset) Power, etc., as well as credit or Integrity. As the population of users increases, there could be categorical rankings available to the population for reference; so that as the broad community matures, the reputation of users would take on the significance of credit scores or Moody's™ ratings, etc.; however, with the power of the credit rating management being squarely in the hands of the users and the community, not a
secretive 3rd party organization such as Equifax™, et al.
Another alternative for initial signup, is that an official agency could verify the user, which would require an official identify and other personal information such as a social security number.
System Registry Once the user becomes a member of financial system of the present invention, the user will be able to register his accounts, such as bank accounts, utilities accounts, credit card accounts etc., which he wants to have available for inclusion in transactions he may want to build, test, and/or execute. Various different methods of loading financial account data and access into the present system are possible. For example, a personal account aggregating service uses an assistant that travels with the user to each financial account website, which can capture the login and password information, to make it available to the user at the personal aggregating service account. All existing systems to date involve accounts that are managed by the user, and accessed by the user. In no known instance do users of these systems grant access and send such access privilege to other users. The present invention does intentionally however enable this multiparty access and granting of access to fransaction events. For example, in collaborative transactions, account access or even single transaction access, is received by users who have been granted such participation privilege, and it becomes available to the user with no specific action required of that user. Of course the user has the right to refuse the granted privilege, but gaining access privilege was something that occurred at the instigation of other system users. While it is expected that various financial service providers increase functionality and grant access to that functionality within the users' existing accounts, nowhere is there a financial services platform that is designed to facilitate system users interacting with each other as collaborating participants, granting permissions to each others accounts and transactions.
Financial Transactions Types - Four Major Embodiments
The methods and systems consistent with the present invention encompass four major types of financial transactions: Traditional Simple, Traditional Compound, Collaborative Simple, and Collaborative Compound, which will be described generally below, before being further described in more detail. Traditional Transactions Traditional Simple Presently, financial services are predominantly pursued in the context of one- to-one relationships between the financial service provider and the customer or client. One-to-one commercial relationships, and the transaction events that occur in their context, are fairly straightforward: There is usually one seller/provider, one buyer/user, and one form of purchase currency or credit, all arranged in a simple, linear equation such as: buyer purchases goods from seller, or, user pays credit-card company.
These financial interactions and the services that support them are what the system of the present invention designates as Traditional Simple fransaction events. Examples of Traditional Simple transactions (see Drawing 1 below) would be the purchase of stocks from a broker, or logging onto a website and making a purchase, or paying a credit card bill, etc. The essential relationship between a Customer and Provider has not changed even though the on-line aspect of the fransaction has made it theoretically easier and faster. In fact, single users connecting to financial services, one company at a time, fail to use the real network-advantage of a global computerized network such as the Internet.
Although the present invention is designed to support network collaborative transaction services that leverage the real network-advantage of multiple connected systems, users, providers, customers, buyers, sellers, etc., Traditional Simple transactions can be easily performed using this distributed financial system, since the user using the present invention is provided the omniscient perspective of being able to see and manipulate the involvement of all accounts in his/her transaction universe, whereas current methods and systems place the user at the node perspective of just one of the participants of the transactions, such as at a credit-card website, or a bank website, etc.
Traditional.Simple transaction
customer provider
ΨW ^ lit
Drawing 1 Traditional Compound
In a Traditional Compound transaction (see Drawing 2 below), a user can manage, integrate, and program several Traditional Simple transactions at the same time. For example, the user can manage and integrate the user's Credit Card bills along with the user's Home Loan, Utility bills, Stocks, Bonds, online purchases, and anything else that involves a transaction the user wishes to make. A Traditional Compound fransaction could include obtaining a new home-equity loan, and using the loan to pay credit card bills and an auto-loan, or a child's college tuition. Currently, there is only one way to take care of these kinds of decisions: they must be executed one at a time, and the user must gather data from various sources, then have the background and skill to understand how to compute and then achieve the various optimal financial situations via an ordered combination of a multitude of one-to-one individual fransactions, which complexity is discouraging to most consumers. To clarify, in this situation where the user of various financial services wishes to avail him- or herself of a multitude of available services (or check to see if s/he should) in a combined or integrated fashion, such as consolidating a bunch of debts held by various 3rd parties, there is no existing automated support service that can facilitate a user in assembling a clear and straightforward financial execution strategy for his or her own specific situation. Because users of financial services have no way of getting support for the Traditional Compound transactions that they need to execute in order to manage their many commitments and responsibilities, users are left to try and artificially assemble compound transactions by arranging and timing a series of coordinated Traditional Simple transactions. Some existing services can aggregate multiple accounts' information in one place and interface, but no existing system lets the user manage, integrate, and program the interaction of multiple accounts. The present invention however, enables this. For business users, the user can assess the inteφlay between the various financial activities and responsibilities of the company, and can for example, make salary payments, vendor payments, refinance, obtain loans, etc., automating where prudent, and capturing unprecedented data (which amounts to visibility of the coφoration's financial status) that enables better decision-making. Thus, vendor billing can be performed next to freasury management (i.e., currency management, credit hedging), or revenue sfreams etc., all within the same interface. Traditional Compound transactions allow users to build the inteφlay between their various financial arrangements, receivables and liabilities (cash-flow management, etc.) and obligations, and schedule as well as test transactions to assess the results as they impact the whole, not just a single account or relationship.
For example, larger enteφrises tend to have separate groups, each that authorize, receive, and pay for coφorate purchases. This separation makes for delays in processing the approval both in purchasing as well as payment as the disparate groups must rely on repeated communication in order to assemble the aggregate information necessary to reach approval. Traditional Compound fransactions can be assembled to streamline this invoicing process with each division or group logging in or using e-mail to advance or trigger the progression through the process toward a final approval and remittance order issued and managed by the coφorate financial department. In the same way that simple systems now allow alerts to be set for some variables, resulting with an e-mail or other notice sent to the user, the senior party responsible for, in this case, an invoice, can orchestrate various triggers along the process of invoice handling, and allow disparate users in various divisions (for example, the coφorate mailroom), to approve of receipt of goods and quality of goods (i.e., correct invoiced part numbers and fitness of goods according to shipping roster), while another group or division (the specific team using the goods) approves of the accuracy (i.e., the correct part as required for the project), etc., before the accounting department is released to remit payment. This confrol can be implemented throughout the coφorate stracture, allowing the enteφrise to have much greater and faster data on the financial state of the company.
In addition, the user can set the parameters of the integrated transactions (i.e., stocks to be sold when they reach a certain value, or stocks to be sold at a certain time or day etc.). Thus, the transactions can be automatically and remotely set, and the user notified when the transaction takes place, as well as have access to summary information detailing the component fransaction results, as well as the overall compound transaction results.
Traditional.Compound transaction provider
Drawing 2
Collaborative Transactions
One embodiment of the present invention may be loosely defined as the existence of networked or collaborative options in the realm of financial activity. This is uniquely different from existing financial, banking, and commerce activities. The existing paradigm for these activities (generally inclusive of Commerce) is almost exclusively a stracture that orients relationships in a singular, linear Customer- Provider arrangement. However, collaborative activities are mutually oriented and inclusive of more than a single relationship; where all parties can be simultaneously Customers AND Providers. Collaborative transactions, which are designed to be supported by methods and systems consistent with the present invention, include a multitude of parties and a diversity of forms of currency and/or credit. Collaborative transactions include transitive (or spread-vector) actions, which means that the fransaction equations can be complex as the net-zeroing of credits and debits, receivables and liabilities, etc., are treated on a global level amongst all participants in the network universe, rather than only between directly related parties as in Traditional fransactions.
This means that because the distributed capital system of the present invention has a greater awareness of the transaction universe than any single participant, it can actively and intelligently optimize the logistics of transaction, for example, theoretically computing the transitive shuffle of liability across thousands of participants such that the total volume of actual funds movement in the universe may decrease for the same volume of paid liabilities in the universe, as receiver and obligor parties can be matched according to the accounts and institutions being used to remit or accept payments - thus, for example, allowing funds movement to be handled as an internal banking execution (where obligor and receiver can be identified and at least partially matched at the same institution, even though these individual participants may have no connection at all to each other), with no net funds, or reduced net fiinds exiting that bank and going out into interbank fransfer networks such as ACH or CHIPS, ,etc.
An approachable way to try and visualize Collaborative Transactions, would be to examine a specific reality of stock markets. Buyers and Sellers rarely know each other, but because the instraments being traded are fungible, one party's sold instruments can become any party's bought instraments regardless of proximity or awareness. The participants whose instraments change hands from Party A to Party B do not care and do not need to care who the counteφarties are; they only need be concerned that their transaction net-zeros locally - the market mechanism itself takes care of the net-zeroing on the global level across all fransactions and between all participants. The present invention brings this guaranteed global-zeroing mechanism to a variety of transaction situations which would never have the critical mass or stracture (i.e., securitization, etc.) to function (i.e., achieve liquidity, etc.) as markets. Cunently, global-level zeroing is evident only in liquid markets active with a theoretically large number of participants, that trade securitized or commoditized items. The present invention brings this global level zeroing mechanism to limited- participant transaction environments Using transitive actions achieved with the program called SVR program module, as described above, any number of transactions involving as few as two participating entities can now have access to a system that will net-zero responsibilities across all participating entities. Realize of course that a two entity fransaction, or multiple fransactions between two entities, can very easily be netted, so a sophisticated network technology may not be needed to resolve the zeroing amongst the parties; but the present invention could nonetheless manage this two-entity fransaction environment. When there are three or more parties, however, it is not intuitively easy to resolve the global net-zero, and this is where the present invention becomes most useful and most valuable, bringing efficiencies in terms of total capital at risk, total economic capital deployed, alacrity of fransaction, etc. In participating in this open market, all participants are simultaneously both
Customers AND Providers. In this case, where all participants demonstrate Customer AND Provider characteristics, the transaction type would qualify as Collaborative Compound, the most sophisticated and expansive fransaction type (i.e., a stock market is only one example of a Collaborative Compound transaction).
Fungibility facilitates transitive resolution. What this means is that, for example, if party A owes party B some amount X, and party B owes party C some amount X, all three parties' transactions roles and responsibilities can be satisfied with a single payment X that party A remits to party C. A distributed capital system will find and execute this transitive scenario regardless of whether Party A, B, and C know each other, or even are aware of each other - to the same effect that buyers and sellers of public equities do not know and do not care who the counteφarties are to their fransactions. It is not important who is the current Purchaser or Seller in collaborative transactions, but rather, the issue is making sure that the liabilities and receivables are all fulfilled, and the correct parties get credited for having fulfilled the liabilities they were specifically responsible for, while the correct receiving parties actually get what they are owed. Since it is unlikely in the universe of fransactions that random participants will arrive at liabilities of the exact same amount X as presupposed in the example above, the distributed capital system has a method and system for dealing with amounts that do not match (i.e., that are asymmetric). As stated above, the Spread-Vector Resolution program module, in treating the fransaction universe as a flow-based model, achieves "resolution" of non-matching amounts, by sfringing together follow- on counteφarty matches of those parties' partial or full liability or receivable amounts, in never-ending fashion. Collaborative Simple
In a Collaborative Simple fransaction (see Drawing 3), two or more parties independently elect to participate in the same opportunity. In a simple example, this would include a small entrepreneur making a private-investment opportunity available to a select group of investors. Currently a scenario such as this one would be pursued as a collection of one-to-one relationships, with the entrepreneur being party to each one independent of others (despite the pooled-asset aggregation of invested funds in the coφoration).
Mutual Funds are a good example of how a distributed capital system may improve customer-service provision to investors; however, currently mutual funds follow both the traditional one-to-one relationship paradigm, and the static freatment of fransactions. A distributed capital system however, would allow a great deal more service and value to be returned to the customer, by providing, for example, constant visibility on the state of the fund, and perhaps even other investors real-time actions relevant thereto.
For example, two friends lending a third money - where all lending parties are "customers" of the "investment opportunity" provided the third friend who offers to pay them back with interest. Another example, is a Church which raises money from its congregation in donations, money from a bank(s) in the form of loans, whereby the loans, the donations, the payments with interest, etc. could be managed by the distributed finance system of the present invention, and at a cheaper cost than if the Church did all the fransactions between each member of the congregation, as well as a number of banks.
Employee-owned coφorations and public coφorations that want to allow a greater number of investors to participate, for example, in senior instruments (debt) such as syndication of credit lines, etc., would be users of Collaborative Simple fransactions.
Collaboraϋve.Simple transaction customer
system
Drawing 3
Collaborative Compound
Another embodiment consistent with the methods and system of the present invention, is the Collaborative Compound fransaction (see Drawing 4). In the
Collaborative Compound fransaction, both sides of the fransaction are considering themselves to be customers (and in a context where doing so makes them both providers as well). The customers may not have any direct awareness of each other, and the distributed capital system of the present invention is simply using the Collaborative Compound embodiment to make the fransaction more efficient or less costly or both, etc. In an example of a Collaborative Compound Transaction, a user's company may require British Pounds for certain activities. In a fraditional manner, the user would go to a bank either physically or online, etc., to arrange for a certain amount of capital to be converted from US$ to GB£.
When a second user, unrelated to the first, somewhere in the world, requires U.S. dollars for certain company activities, traditionally, the user would in similar fashion, go to a bank or other financial institution etc. physically, or online, etc., and arrange for a certain amount of capital to be converted from GB£ to US$.
Both users are customers, and the financial institutions can provide them both with services in the traditional manner. However, both users could arrange to transact with each other, or automatically and anonymously be matched with each other, to mutually serve each other's needs in the distributed capital system of the present invention, so becoming providers at the same time as being customers.
In particular, the users could utilize the distributed capital system of the present invention to request an exchange of currency. The program of the distributed capital system of the present invention uses a vector-flow algorithm to resolve the problem of exact matching of the funds requested by both users/parties, allowing the parties to transact to the full amount possible, and then taking any remainder amount (if for example, one user required more US$ than the other party could provide), and having a different "customer" fulfill that partial amount, leaving that customer's remainder filled by another, successive customer on the opposite side of that transaction. This is a flow-based freatment of transaction, rather than the predominant static treatment which forces an assumption that all fransactions must be met in full by a single counteφarty (such as, in the example where the Bank fulfills the exact amount of desired currency conversion). This type of Collaborative Compound transaction can take place regardless of the amounts involved - whether small or massive - thus, perhaps contributing to a moderation of volatility across regional and national economies around the globe since liquidity would theoretically increase as fees drop due to the removal of 3rd party intermediaries, resulting in less friction .(and hence less latency, that causes economic sfraint, and hardship) between economic (cunency, policy, sovereignty etc.) domains.
Collaborative.Compound transaction
Drawing 4
Timing of Transactions Note that in discussing these four embodiments of types of transactions, the user can indicate whether they wish instantaneous processing (typically desired for a bill payment, or investment-grade request), or they wish to set a time for the fransaction to take place (i.e., a later date, for installment bill payment etc.), or an event-triggered transaction to take place (such as a certain stock-price, or even random variables for which data users may wish to use, for example the ambient air temperature in Las Vegas, or the score of the Green Bay Packers game, etc.). The first transaction is designated by the system as a real-time or immediate type of request, the next as a passive request, and the final as a fixed request. In the latter system, the funds in the fransaction may be available to the investment engine of the present system (see Investment Engine below). Traditional Simple Transaction
One embodiment consistent with the methods and systems of the present invention is the Traditional Simple financial transaction, which will now be described in more detail. Although only the Traditional Simple fransaction will be described herebelow, it should be noted that all the following different types of fransactions may utilize the user interface of the present system. Thus, the user interface as described with respect to the Traditional Simple transaction, will not be described again in detail with respect to the other fransactions. As stated above, a Traditional Simple transaction is familiar to most online users, and involves only the customer and a provider, and a simple financial transaction such as the payment of a bill. Accordingly, once the user has logged into the system, and has been through the log-in process in step SI 00 (see FIG. 11 A) and the authentication process in step
S101, the program opens a blank display screen in step SI 02, similar to the screen which opens when a word processing program is opened, with Transaction Options shown on the display screen.
The user then uses his mouse to place the cursor on "File" and left clicks the mouse, at which point, in step SI 03, the program provides a pull-down menu listing the possible fransactions available to the user, or perhaps a dialog window, options palette, or toolbar or any similar presentation of custom designed Transactions the user has set up in his/her account, (i.e., Existing Transaction 1, Existing Transaction 2, Build New Transaction, etc.).
Note that although activities will be described as being performed with the action of a mouse using a cursor on the appropriate selections, and right-clicking or left-clicking to initiate an activity, one of ordinary skill in the art will realize that these actions can be performed by command functions on the keyboard or by voice actuation or other similar methods, and that the consistent advancement of "ordinary skill" in the realm of interface design will continually realize better ways to present the same and increasing amounts of information.
Further, although various operations and transactions will be described using discrete steps and with a specific terminology, one of ordinary skill in the art would know that the transactions could be achieved in varying ways and using different terminology or steps, and using variations of the methods described below. Assuming this is a new or first fransaction, once at the "File" menu, the user can choose "New Transaction" if the transaction is determined as a new one in step SI 04, by left-clicking on that option, whereby in step SI 05, the program will open a blank Transaction Workpad on the display screen (see FIG. 12). Once the user is at the basic blank Transaction Workpad display, the user can move his cursor to the heading "View", left-click on that option, wherein the program will provide a pull-down menu in step SI 06 which includes "Toolbars".
The user then can left-click on "Toolbars" or follow to the right of "Toolbars" causing a sub-menu to drop-down, whereby in step SI 07, the program will provide a list of transaction options from which the user can choose.
Under "Toolbars", for example, can be a list of options including "My Banks", "My Credit Cards", "My Communications", "My Utilities", "My Insurance", "My Loans" etc., as well as a selection entitled "Transaction Objects" (see FIG. 13).
One of ordinary skill in the art will recognize that design factors may dictate that "Toolbars" be replaced with a more appropriate name, such as "Transaction Entities", or some other such designation which communicates most effectively with users.
In this example of a Traditional Simple transaction, the user may wish to pay a gas bill, which is a simple transaction involving two parties (three entities) - the user and the gas company being the parties (the user, the gas company, and the fransaction action between them being the three entities). Thus, the user may choose "Transaction Objects", and left-click on that option, whereby the program, in step SI 07 will receive the command and display a working area adjacent to the Transaction Workpad (see FIG. 14), labeled
"Transaction Objects", and in which are disposed a number of icons representing various financial fransaction actions.
For example, the icons may represent financial transaction-actions such as, Capital Asset Vector (payment, or more accurately, a general movement of capital = "Move Funds"), Convert Currency, Buy, Sell, Lend, Borrow, and Currency Hedge, etc. While resident in this Transaction Object toolbar or palette, the objects will be inert. When any of them are dragged onto the Transaction Workpad, they become active objects, the building block entities of a fransaction that the user will assemble.
Once active (i.e., once on the Transaction Pad), either via mouseover, mouse button click (right or left), or some other interface-design dictated user-friendly access, the user may see "Properties" information relevant to that entity. Note "objects" is a subset of "entities". Thus "transaction object" is a term specific to fransaction actions, whereas "entity" is used to identify both the parties to a transaction as well as the actions between them.
In the case of a "New Transaction", "object entities" will not display
"properties" information other than general functional-feasibility, system status type information, because the transaction is new and the action within this specific fransaction has not been used yet, and does not have a history of use that would create a record to display. The active "party entities" placed on the "Transaction Workpad" for the sake of assembling a "New Transaction", however, will reveal an abundance of "properties" information precisely because these "entities" are involved in a variety of transactions beyond the cunent New Transaction that is being assembled. The user may configure the presentation of this properties information according to what is most important to each user.
Within the "Transaction Objects" toolbar, there will be a "Search for New Objects" button, which will allow the user to periodically query the system for recent additions to the "Transaction Objects" toolbar, and so add further functionality to user-created and user-managed fransactions. However, the program will provide new "Transaction Objects" which will automatically appear in the "Transaction Objects" toolbar in conjunction with periodic updates provided by the system, or, in conjunction with pre-requisite factors having been achieved (such as attending an online investor education seminar or training program, or a set period or quantified or qualified usage of the product and service). Some of these new "Transaction Objects" may require approval or special access (such as sophisticated-investor status, etc.) in order to receive from the system.
Next, the user may choose "My Banks" from the "Toolbars" menu, whereby the program will receive the command and display another labeled section adjacent the Transaction Workpad, which shows icons which refer to different banks accounts pre-registered by the user.
Note that although in the present invention, the accounts and fransaction actions are preferably shown as icons on the display, the accounts and transaction actions may be available in a pull-down menu, table, grid, or the like. The fransactions may be assembled by the movement of the Transaction Objects icons or placeholder representations (such as text names, or the like, etc.) using a mouse, or by command functions on the keyboard or the display, or by voice actuation etc., which are specific to handling those entities. Although the following description will relate to the use of icons manipulated using a mouse, one of ordinary skill in the art will be aware that use of command functions on the keyboard, or display, or by voice actuation, etc., can also be instituted to perform the commands or initiate the fransactions. Finally, the user may choose "My Utilities" from the "Toolbars" menu, whereby the program will display a labeled section adjacent the "My Banks" and "Transaction Objects" areas, whereby a number of icons depicting the "Gas Company", "Water Company", "Electric Company" etc., will appear in the "My Utilities" section. In order to perform a financial fransaction, the parties to the transaction, and the transaction action chosen to act between them, must by placed in the Transaction Workpad area, arranged in the relationship desired to be executed as a fransaction .
Accordingly, the user may place the cursor over the "My Bank Account" icon (may be specific to a particular bank account at a particular bank, as registered by the user), and using the mouse, may left-click the cursor, holding, moving or dragging the icon "My Bank Account" over onto the blank Transaction Workpad section, depositing the icon there. Dragging from the original location does not remove it from the original location, but rather creates a copy as the cursor moves the clicked- on object away from the original. Thus, the program in step S108, receives the transaction entity in the Transaction Workpad section, as the user proceeds to assemble a transaction. When the user mouseovers or otherwise executes an action that calls for
"properties" information in relation to the "My Bank Account" icon within the Transaction Workpad section, the program, using the VfT program module, in step SI 09, receives this action as a command to obtain real-time information on the status of the user's bank account (i.e., account number, balance in checking, savings, etc.). The VfT program module executes this command, telling the CDMX program module which user is sending this request, and for which entity, and the CDMX program module accesses the secure "Account Registry" which maintains records of all user-registered accounts, and collects the proper and formal identifying, as well as access-authorizing data, for these accounts. Alternatively, the system can be configured to request the required user passwords as they are needed, and not store any user passwords. Proceeding, in addition to being stored, this access is timestamped and assigned a transaction code by the CDMX program module, before handling this retrieved information to the MaQs program module which executes the request to retrieve information from the real world entity external to the system.
Accordingly, in step S109, the program queries the user's bank over the Internet and over any secure financial networks necessary to obtain the information. Note that this request is sent from the client to another client or the server, and the client or server to whom the request is sent, performs the query to the bank. (However, note that the bank queried may also be part of the present system, such that the request is easily handled In one more sophisticated transaction option, the user may choose an option -
"Scan All Accounts for Updates" - whereby the program scans all the user's pre- registered accounts and provides real-time data related to each account to the user, advising the user of any new bills, changes in balances to mutual funds or bank accounts etc.). In step S 110, the MaQs program module receives the information from the bank at the server, at which point the program passes the retrieved information back to the CDMX program module, including as well, any general system-status or network information that may be provided as a result of issuing a request over that network. The program via the CDMX program module, then timestampes, codes and stores all the received information. The CDMX program module then filters the information it receives in order to pass back to the VfT program module, only the requested information, and thus the real-time status of the user's bank account is provided to the client computer which displays it for the user in step SI 11, on the screen next to the icon or available under a pull-down menu, table, other window, or the like.
Note that since the user has pre-registered his bank account with the system, this query can be performed securely and results are retrieved almost instantaneously, as would a user receive, for example, when attempting to retrieve cash from an ATM machine. Further, since existing secure networks are used, no new physical infrastructure is necessary to perform this query and receive the information.
The user now can perform the same steps with respect to the "Gas Company" icon, holding and dragging the "Gas Company" icon over to the Transaction
Workpad, and by performing a mouseover or the like at the "Gas Company" icon, the program can obtain real-time and other information regarding the "Gas Company" (i.e., account name and number, customer service telephone, amount due, past amounts paid, etc.). The user can also perform the same steps to choose a Transaction Object from the "Transaction Objects" section. In this case, "Capital Asset Vector" would be an appropriate financial transaction action to place between and connect "My Bank Account" and "Gas Company". Thus, after the "Capital Asset Vector" has been retrieved from the "Transaction Objects" section and received by the program in the Transaction Workpad section, in step SI 12 (see FIGS. 1 IB and 14), the user must now initiate and may confirm initiation of the financial transaction if s/he wishes it to actually execute.
Accordingly, the user may attach the "Capital Asset Vector" between the two entities (i.e., "My Bank Account" and "Gas Company") in order to make the fransaction a completely assembled fransaction (i.e., payment of the gas bill from the user's bank account) which the program can receive in step SI 13 (see FIG. 15). Note that until the "Capital Asset Vector" Transaction Object is attached to both the "My Bank Account" entity and the "Gas Company" entity icons, no transactions take place, execution cannot occur, and a mouseover or other "Properties" check on any of the entities on the Transaction Workpad will produce no display or evidence of results or confirmation for this fransaction. The program, in step SI 14, will check the assembly of every transaction to make sure at least the syntax of the assembled transaction is feasible (although it cannot check and avert all user-errors in amounts and selected entities, etc.), before allowing the user to initiate execution (see FIG. 16). Likewise, the program will require the user to set and confirm both the direction of the "Capital Asset Vector"(so that a payment is sent to the Gas Company, rather than a remittance request (ie a refund request or bill presentment from the user to the Gas Co.)), as well as the amount of the capital vector, prior to the assembled fransaction becoming available for execution via user- initiation. In order to assemble a transaction, the user can then left-click on the tail of the
"Capital Asset Vector" icon and hold and drag it onto the "My Bank Account" icon, where it will attach with a "snap". In addition, the program may change the border of the "My Bank Account" icon to make it thicken or change color, etc., to show the attachment was successful. The "snap" feature would be familiar to a user who can use a "Draw" application and attach anows to various objects.
The user can then left-click on the head of the "Capital Asset Vector" and hold and drag it onto the "Gas Company" icon, where it will also attach with a "snap", and result in the program making a thickened border or the like, in whatever user-centered design is chosen to communicates a successful connection.
Note that although the above steps are described in order of placement of the movement of funds from one entity in payment of another entity, one of ordinary skill in the art will be aware that these steps can be performed in any order, and the entities can be placed in any order on the Transaction Workpad, connected either immediately after each placement, or after all the entities are placed on the Transaction Workpad, etc.
Once the connection is made between the three entities (i.e., "My Bank Account", "Capital Asset Vector" and "Gas Company"), the fransaction is fully assembled and becomes an active transaction, having passed the system's transaction- syntax feasibility check and awaiting user-setting and confirmation of transaction object Criticals.
Once fully assembled, a mouseover or other similar "properties" request action, available as user-centered design may dictate, of the Capital Asset Vector by the user, will initiate the program to display information detailing the characteristics of that Capital Asset Vector. This includes, for example, the Vector Source Entity (i.e., the user's Bank, including the institution name, account number from which funds will be withdrawn, etc.); Vector Destination Entity (i.e., the user's Gas Company, including institution name, target account number, etc.); Transaction
System or Network (ACH, PayPal™, e-Checking, etc.) most likely to be used at time
of execution, Network or System status, if execution were to proceed at current time, etc. Also, in the case of existing assembled fransactions which have been used in the past, (i.e., paying last month's Gas bill would be the same fransaction entities and assembly orientation as this month's bill fransaction and vector, with only the timing and amount to change), the program will provide an indication of previous transaction activity using that specific Capital Asset Vector (i.e., payment from specific user- Bank Account, to Gas Co.), and further details may be accessible as user-centered design dictates may be the optimal method of display, referenced by the program as the Transaction History.
Note that if several different remitting entities at different times are used to pay the Gas Co., there will be a multitude of assembled Transactions, each with its own uniquely defined Capital Asset Vector, each saved as a separate file which the user may open at any time to use again (i.e., if the user has multiple bank accounts and credit card accounts, etc., and prefers at one instance to remit from Account 1 and at another instance from a credit card account, etc., the user will choose to open the saved transaction file according to method of remittance desired). Whereupon if the user wishes to see in one place the details of all activity involving the particular Gas Co. account, s/he may simply access the Gas Co. account history in the "Properties" of any one of the "payment to Gas Co." fransaction files, as the program updates the Gas Co. record in all of them according to activity on the Gas Co. account, regardless of which remitting account sends payment.
If the user wishes to view the "Transaction History" for a specific Capital Asset Vector within one of these "payment to Gas Co." transaction files, the user may select this option and the program will access a database to provide a display showing previous transactions made between these two specific entities (remitting entity, and receiving entity), including, transaction amounts, dates, etc.
The assembled transaction cannot proceed to transition to "available for execution" status until the fransaction object Criticals (i.e., Vector Criticals in this Gas Co. example) are set and confirmed by the user. Upon setting and confirming the fransaction object Criticals, (in the case of a Capital Asset Vector these would be called Vector Criticals) the assembled transaction will fransition to a state of availability for initiation at the user's discretion. The program may show this transition by changes in the display or presentation, including audio, visual, animation, or changes in state such as brightness, color, shape, dimensionality, placement, or the like.
The user may double-click, or right-click, etc., on the Capital Asset Vector, whereby the program, in step SI 15, will open a menu on the display screen, which includes various options, one option being "Vector Criticals".
For Capital Asset Vector fransaction objects, a minimum of two Criticals must be set and confirmed by the user. Other Criticals may be left as defaults or unset. The two mandatory Criticals for Capital Asset Vectors are: l)Direction, which entails Vector Source assignment (= determination of remitting entity), and Vector Destination assignment (=determination of receiving entity), and 2) Amount, which is the user-desired amount to be remitted. When the Capital Asset Vector is snap- attached to entities in the transaction assembly stage, the program allows these entities to become available in the Criticals interface, for selection as either Vector Source or Vector Destination selection. If the user does not choose to set the Vector Timing for the fransaction, the program will allow this setting to default to immediate execution of the transaction upon pressing the "Execute this transaction" button, as technical feasibility permits.
Other Criticals may include such things as currency type (i.e., among possible currencies accepted by the target entity), date of payment, and the option to automatically remit multiple vectors or payments, at different dates, triggered by different external events (i.e., such as confirmation of direct-deposit of paycheck, cunency-exchange target, or the like), etc. The user may set a vector-specific password or, alternatively, set the vector to use the user's system login password, to protect access to this vector's Criticals; this setting may also be confrolled globally by the program, such that all fransaction objects require a password in order to view or change object Criticals. For more sophisticated options in performing this fransaction, the user may elect for a more secure option of setting this vector or all fransaction entities such that each transaction entity to be accessed will require the user to enter passwords at the time of execution, rather than having the program of the system maintain this private information on file. Note that the user is provided by the program with the option of setting the timing of the transaction under Criticals. The transaction can take place immediately, in real-time, or if the timing of the fransaction is not specified or a later date specified, the fransaction will be set to passive-fill upon execution, which means that the funds may be drawn down from the user's bank account but may be diverted to an investment engine of the system prior to the date where it is to be filled (see Investment Engine below). After setting the Criticals, the program closes the Criticals interface in step
SI 17, whereupon the transaction's assembly is complete enough to be executed. The user may wish to save the transaction at this point. The user may save the transaction at any stage, whether the fransaction is completely assembled and feasible, or otherwise, just as one might save and close a text document at any interim stage, and come back to it at a later date for editing or completion, etc.
To save the transaction, the user should click on "File" in the drop-down menus, and choose "Save", or may perform this function on the keyboard or the like, whereby the program will provide a dialog box requesting that the user name the Transaction to be saved. The user then enters a Filename (i.e., Regular Gas Co. Payment), and presses "Save", whereby the program, will save the Transaction in step SI 18, and if requested by the user in the future, will make the Transaction available in a drop-down menu or other window of "Transactions", under "Recent", as may be dictated as optimal for making these files easily available to the user. The user may create and save any number of fransactions, available for re-use or review, editing, adjusting, etc., at any time.
Note that when the fransaction is syntactically feasible, the "Test this Transaction" button and the "Prepare for Execution" button mentioned below may change from being dimmed, greyed, dimensionally flat, or the like, to being bright, colored, having dimensional relief and shadow, or the like, to communicate to the user that the button function has transitioned from an inactive or unavailable state to an active or available state. At the point the user has finished assembling and confirming the transaction such that it is feasible, the program will make available a "Test this transaction" button, placed such that the user correctly associates this button with the fransaction concerned and not with any other fransaction or activity in the system, that allows the user to simulate execution of the fransaction prior to actually executing the real thing. When the user clicks on the "Test this transaction", the VfT program module, in step SI 19, receives this action as a command to initiate a check on all entities in the assembled transaction via the MaQs program module, to determine viability (technical, financial, etc.) as well as to process a simulated accounting of all fransaction amounts and resulting changes in all entities, for presentation to user. Note that no capital actually moves during a test.
In this way the system can provide a predictive awareness of the user's finances, for the user to make and manage decisions across the range of all user financial activities the user chooses to handle via the system. In one embodiment, the program of the system may provide customized decision-analysis and support to the user, based on historical and statistical resources.
Thus, the VfT program module executes the test command, telling the CDMX program module which user is sending this request, and for which entities, and the CDMX program module accesses the secure "Account Registry" database which maintains records of all user-registered accounts, and collects the proper and formal identifying as well as access-authorizing data for these accounts. In addition to being stored, the CDMX program module timestamps and assigns this access a transaction code, marked with an indication that it is for Testing (simulation) puφoses, before handling this retrieved information to the MaQs program module which executes the request to retrieve information from the real-world entities (which are identified in the transaction via the assembled entity icons) external to the system.
Accordingly, as part of the testing step, the program queries the user's accounts at the relevant real-world entities over the Internet and or over any secure financial networks necessary and available, to obtain the requested information. Note that in a client-server environment, for example, the request is sent from the client to the server, and the server performs the queries to the external entities.
As part of the testing step, the program directs a query to instigate a background check to verify that the Gas Company system is up and ranning (capable of receiving remitted transaction amounts), determine the required transaction cunency, current fransaction processing time (i.e., real-time, 18 minutes, 2 hours, 4 days, or other timer period, etc.), or the like. Further, in the same step, a similar check is performed of the Bank to verify balance (ensure that the funds are available), that the Bank transaction system is up and ranning (capable of sending transaction amounts), etc. The program receives the information from the various entity accounts, at which point the MaQs program module passes the retrieved information as well as any general system-status or network information updates that may have come as a result of issuing a request over those networks, back to the CDMX program module. The CDMX program module then timestamps, codes, and stores all the received information, again marking the code in such a way that it can be distinguished as a Test. Then the CDMX program module filters the information it receives in order to pass back to the VfT program module only the requested information. Thus, the realtime simulated execution data attendant to the user's fransaction is provided to the client by the program which displays it for the user in step S 120, on the screen next to the entity icons or makes it available under a pull-down menu or the like (see FIG. 17).
In addition to common messaging and warning dialogs, windows, alerts and the like, the graphic properties of the entire screen interface and display of a fransaction under Test proceedings, and under actual Execution proceedings, may change such that they will be distinguishable, using such differences as brightness, color, dimensionality, size, placement, and the like to readily communicate to the user which proceeding is actually underway and being managed.
An example of how the user can test the payment function is as follows: For example, by using the "Test" function, the program will automatically check that the funds are available at the user's Bank and also that the Gas Company's account is available to accept the transaction. For example, if the user's Bank Account has uncollected funds, or the Gas Company's account is off-line, then the fransaction will not be able to take place, and the program will notify the user in a message in a dialog box, which will pop up or otherwise appear on the display stating that the fransaction cannot take place. The user has the option of retrying the transaction immediately or can program the fransaction to take place at a later time, or cancel the fransaction etc.
Specifically, when using the "Test" option, the user will see a visual representation by the program using the VfT program module, of the simulated fransaction. For example, the program may display a money-bag icon on top of the "My Bank Account" icon, which will grow in size; with text characters denoted amounts, which are attached to the money bag icon, increasing in amount until the exact amount set by the user is obtained.
At the same time, the program may, for example, cause to be displayed, a small accounting box attached to the "My Bank Account" icon, which will show the cunent balance at the user's Bank, and in second row a rolling amount, increasingly negative (red), equivalent to the debt equivalent of the positive money-bag increase.
Once the vector amount as set by user is reached, the program will cause the vector amount to blink twice within the bag and remain, or some similar indication to communicate completion.
Next, the program will display a cylinder icon, for example, over the Gas Company icon, with an attached text indicator of the cunent account balance. If an amount is owed, this text will be negative and red, and the cylinder icon will be empty and its border will be red. If there is no amount cunently indicated as owed, a dollar amount in black will be displayed (i.e., $0.00) and the cylinder icon will be empty, and the border will be black. If the Gas Company account is currently holding a credit amount greater than the invoiced amount, that credit amount will show in green text, and the cylinder icon border will be green, and the cylinder icon will show a small amount of green volume.
During the test, the program will move fiinds from one entity to another, such that the money-bag icon begins to shrink while at same time the Capital Asset Vector, will , for example, show an increase in size moving through it (i.e., as if something large were moving through a pipe, temporarily stretching its diameter as it moved along the length of the pipe).
Then, the program will display, for example, the cylinder icon over the Gas Company icon slowly filling up as the transaction progresses (i.e., as if water were filling up inside it), with the text attached to the cylinder icon, numerically indicating the capital influx shown on the cylinder icon. When the transacted amount has completed movement from one entity to another, the program will display, for example, a second row of text attached to the cylinder icon which remains at the final amount, and a third row of text which will appear showing the accounting of the transaction (i.e., the net result, either a dollar amount in black (i.e., $0.00) showing the balance paid and the transaction complete with no funds owed, any remaining outstanding balance in (negative red), or credit (oveφay) in green text. The program will also display, for example, text attached to the "My Bank Account" icon, showing an accounting of the transaction, with the funds removed from the balance of the bank account.
Note that although the "Test" feature was described using a particular type of icons, any type of icon can be used, and any type of indicator showing a removal of funds from the user's Bank account to the Gas Company can be used. Accordingly, the description of the user interface which displays the movement of the funds in the fransaction, is for the user's benefit while the program tests the availability of the funds in the Bank Account, and the ability of the Bank to transfer the funds, and the ability of the Gas Company to accept the fransaction, etc.
After the test is completed, the program, in step S 121, the user will be prompted with transaction options via a dialog box, to either "Run Test Again", "Edit Transaction", or "Save Transaction".
In this example, the user may select "Save Transaction", and the program will save the Transaction for subsequent execution or future retrieval, review, editing, and or execution, etc.
In the case of later-date or multiple auto-timed payments, alert notices of fransaction activation may be sent by the program to the user's designated e-mail account, which notice may include a URL to a secure system webpage, with an interface first requiring the system login and password, then assuming successful user-login, the program will provide a display of fransaction specifics, form windows to take input of required passwords, and provide confirmation check boxes or the like, as well as "Prepare for Execution" and "Execute Transaction" buttons. The program will record transaction specifics and results to the saved transaction files as described elsewhere, available to the user at the next login to the system, updateable automatically to the local-client (i.e., user's PC) the next time the user logs into the system from that (PC) client.
When the user would like to review the details of the Transaction just tested, the user may click on the button at the bottom of the Transaction Workpad, called "Text Summary of Transaction", whereby the program will display a Test Transaction Summary including all the relevant details of the user's Bank Account, the unique code which the CDMX program module assigned to the Test Transaction, which code may be modified in part at the time of execution to show that the code was tested, and then actually executed (for example, the code may consist of numbers and letters, with one letter "T" indicating "test", and upon execution an "E" may be added to the code. In this way , the CDMX program module may easily distinguish, and the user may easily understand, whether a transaction being reviewed was executed, tested, or both, the Transaction amount, the timing chosen by the Vector Criticals, etc, as well as the details about the Gas Company's bill, payment, etc.
The user may print this if desired. The user may also print text summaries for either or both the tested transaction, and or the executed fransaction. The summary of the executed fransaction will contain all necessary information and tracking codes to stand as a receipt of transaction, which information shall be sufficient to prove payment was initiated. Since the CDMX program module tracks all fransactions and the entities which are involved in them, the user-printed text summary provided by the program, which includes transaction codes, shall be able to identify the exact fransaction details to the customer service professionals at the real world receiving entities. Since fransactions will be executed over traditional and existing secure payment networks
(such as ACH, PayPal™, etc.), these receiving entities are already capable of
receiving the system-initiated transactions. So it is possible that the receiving entity may not care what 3rd Party (i.e., the system of the present invention) initiated a payment and will simply record the payment along with all others received through the same infrastructure, thus making it easily retrievable for review should the consumer wish to address the customer service departments of receiving entities which were Vector Destination Entities in the system-initiated fransaction, and discuss specific transaction details such as amounts and timing of payments, etc.
Now, if the test was successful and the simulated results satisfactory such that the user would like to execute the Transaction, the user may click on the "Prepare for Execution" button on the bottom of the Transaction Workpad. The program, in step SI 22, will cause the Transaction Workpad to shrink, for example, withdrawing to the upper left side of the display screen, and showing only the Transaction entities and the vector connecting them, but in much smaller form. Below this window, the program will display the Transaction Name as saved by the user, and below the Transaction Name, an accounting ledger or Transaction History, for example in downward-to-current chronological order, showing all historical Transactions (if there are any) made using this particular assembled fransaction and vector.
Below this window, the program will show a final accounting entry showing the date and amount of the present Transaction, as "About to be Transacted". The program will display a "Lock in this Transaction" button at the bottom of the display screen, and the user may then click on this button. Upon pressing the "Lock in this Transaction" button, the program will display a vertical rectangular window, for example, which will show dimmed components of the Transaction, including a list of items that need to be checked and verified in all necessary aspects (i.e., sufficient funds in the user's Bank Account, the availability of the Gas Company system online, etc.).
The program will then proceed through the checklist of items to be checked and verified, with each item lighting up upon review by the program (i.e., the item will turn red if there is a problem, or green if the fransaction can proceed). Once the program has checked and verified all aspects of the Transaction as positive, the program will display a "Transaction Locked In and Ready to Go" message or the like, as well as a confirmation icon, in step S123, and the program will then activate a displayed "Execute this fransaction" button that is associated with the Transaction Workpad on which the fransaction lies, or the like. Placement of the button on the display should be such that the user conectly associates this button with the fransaction concerned, and does not confuse it with any other fransaction or activity in the system. (This button would have transitioned to a state of active availability for use at the user's discretion. This fransition may be recognizable in changes that include such things as audio, visual, animation, or state changes in brightness, color, shape, dimensionality, placement, and the like).
The user may then click on the "Execute this Transaction" button, and the program, in step SI 24, will clear the contents of the vertical rectangular window and will display a new list of execution items for the Transaction as well as a vertical progress-downward highlighted bar. As each item (such as "Send Pre-Notification of Transaction to Gas Company System", "Partition Set Amount from User Bank Account", "Release Partitioned Amount", "Confirm Receipt by Gas Company", etc.) is performed and verified by the program, the completed item will turn green, for example, and get a checkmark to its left, for example, and the progress bar will continue downward on the list. Note that for each Transaction Entity chosen, the program will access a pre-determined set of instractions of items to be verified, depending on the transaction type, object-entity (i.e. remit, request, buy, sell, etc.), and party-entity (i.e., Bank, Insurance Company, Utility, etc.) involved.
During Execution, the shrunk fransaction and vector assembly will repeat the graphic display described in the test, in conjunction with each actual proceeding step in the execution process. Thus, for example, when the Execution process rans "Release Partitioned Amount", the moneybag as described during the Test procedure, will begin to drain and move through the vector, etc. The program also provides a unique Transaction Number to the Transaction which Number can be tracked by all the parties to the Transaction (i.e., Bank, User, Gas Company).
Upon completion of the Transaction and the assignment of the Transaction Number, the program, in step S125, will display a Comprehensive Transaction Record which will include a diagram of the vector Transaction, all account details, institutional contact information, and the specific official transaction-system time- stamp data, as well as the Transaction Number.
The user may then print out the Comprehensive Transaction Record for the user's records, or simply save digital copies locally or on the server (network records would automatically be kept according to banking regulations.). The user may also export transaction specifics to any major financial accounting software (such as QuickenTivi)- Conversely, it is envisioned that major financial accounting software will have the capability to execute the Transactions enabled by the present invention from within such applications, with all summary data being returned directly to the financial software's logs, etc.
The saved Transaction becomes a template for future transactions, whereby the user can reopen the saved Transaction and perform another vectored fransaction at a future date, needing only to confirm the Criticals, and execute. Likewise, copies of existing saved transactions may be made, in order to rapidly edit these into new fransactions which are similar to the original. An example of this may be if the user wishes to create a second "Payment to Gas Co." fransaction assembly, but with a different remittance entity in place of the original Bank account. The user would first click once on the existing saved transaction file icon, then, going to the "File" pull-down menu, select "Duplicate Transaction File", where the program will produce a carbon copy of the existing saved fransaction, its name automatically adjusting to reflect that it is not the original, but a carbon copy. The user may then double-click this carbon copy, and the program will allow the user to edit, replace, and adjust any or all of the entities. The benefit to the user in doing this is that all settings for entities in the carbon copy will remain the same as they were in the original (although they could be changed at the user's discretion), so that, for example, the Vector direction would already be properly set as required to make the remittance to the Gas Co.
Note that although the Transaction is described as being tested prior to execution, the user can set up a Transaction and then proceed straight to execution, thereby skipping the Test function.
Although the Traditional Simple Transaction uses only a small portion of the full capability of the distributed finance system consistent with the present invention, it is likely that this function is one of the most readily available to users at the cunent time. Because the distributed finance system consistent with the present invention is a third-party platform, a user can maintain a single account, and via the same account and login system, monitor any number of diverse accounts, whether bank accounts, credit card accounts, utility bills, various loans, investment portfolios, etc., and build, test, and execute transactions from any or all of them as desired using empirical fransaction party- entities and fransaction object-entities as described in part herein.
Traditional Compound Transaction
In one embodiment consistent with the present invention, a Traditional Compound financial transaction can be assembled, tested, and executed, similar ot the Traditional Simple fransaction. Essentially, as stated above, the Traditional Compound Transaction involves two entities which are not normally connected in traditional financial systems. Since the Traditional Compound Transaction can take many various forms, three examples will be described. Further, since the user interface has been described in detail with respect to the Traditional Simple transaction, the user interface will not be described in detail hereafter.
Example 1
Once the user has logged in, been authenticated, and has brought up a "New Transaction", and is at the blank Transaction Workpad as described above in the Traditional Simple Transaction, the user may then continue with the same process as described in the Traditional Simple Transaction. For example, the user may wish to choose "My Stocks", and by mouseovering the "My Stocks" icon, the program may access the user's account and obtain and display any real time data related to the account. In one example consistent with the methods and systems of the present invention, the user may chose "My Stocks", and "My Auto Loan" - the cunent auto- loan in question having, for example, 18 months of payments left to make. The user may now build a fransaction using these two icons and a Transaction Object icon - "Sell" - to sell whatever stocks the user wishes, and then user a Capital Asset Vector to direct the liquid capital to pay out the Auto Loan in full - as a single programmed fransaction, with everything recorded and managed by the distributed finance program of the present invention.
As with the Traditional Simple Transaction, the user may assemble the transaction, test it, modify it, and then execute it as one transaction. Thus, there is no need to have interbroker or intersticial parties involved in the financial transaction.
Note that the MaQs program module will take care of communicating with the marketplace and executing the commands that are stractured using the VfT program module and coded using the CDMX program module. The VfT program module will keep a viewable record of all fransactions, updated by infoπnation fed from the MaQs program module and the CDMX program module. Also, the VfT program module will save the fransactions and make them available for review and fracking puφoses, to analyze amounts, counteφarty account numbers, times, etc.
Example 2
In another example consistent with the methods and systems of the present invention, under the "New Transaction" menu, the user may choose an option such as "Query", and may choose from a number of options such as "Loan", "Insurance", etc. In this case, the user may choose "Loan", at which point the program will prompt the user to enter various loan parameters (i.e., "Set Loan Parameters" option). Once the user enters the parameters, the program will query the marketplace (i.e., banks, credit card companies, etc.), or the distributed capital system community (to invite a multitude of lenders to participate in syndicating a loan), for loans of the user's specifications, and return real-time information on interest rates, credit data, etc. If the user decides to apply for a loan, the user may do so, and may do so on-line, either with a single counteφarty such as a bank (which would constitute a Traditional Simple fransaction), in the traditional manner, or with a multitude of lenders, in syndicate fashion, automatically orchestrated by the present program of the invention (which would constituted a Collaborative Simple fransaction). Regardless of which approach is used to secure the loan, this initial activity is in this example hereafter linked to successive transaction activity, and becomes a component of a Traditional Compound transaction. In this way, the transaction types are not restricted to being used only as independent transaction types, but may be combined to achieve whatever streamlined result the users can come up with..
Assuming that the user is granted a loan on-line, for example, and has funds available at the bank or credit union etc., the user may then deploy the loan funds to pay off the user's credit cards or child's college loan, etc., for example. The Transaction is similar to the Traditional Simple transactions in that the user brings up the "My Loan" icon, the "My Credit Cards" icon, and "My College Loan" icon, connects them with a "Transaction Object" such as "Capital Asset Vector", and uses the loan funds to pay off the credit card and college loan bills (see FIG. 18).
Note that funds can be split from the Loan using more than one "Capital Asset Vector". The program can be directed to execute the emanating Capital Asset Vectors simultaneously, or in series. Testing and execution requests could be instituted for all the pending Transactions at one time.
Further, one of ordinary skill in the art would recognize that this type of Transaction can be accomplished between any entity which is interacting with a number of different targets (i.e., an employer paying his employees their salaries, etc.).
Example 3
In yet another example consistent with the methods and systems of the present invention, the user may program speculative activity, where as in Example 1, the user wishes to "Sell" stocks, but only at a particular price. The program will provide the user with an option to set the parameters of the sale (as in Example 2, where Loan Parameters are set). Since the stock price can be obtained in real-time by the program and displayed for the user, the user will know if the stock price is lower than the price at which the user wishes to sell. Accordingly, the program can provide the user with options to sell the stocks when the price the user wants is achieved, with the program testing the transaction in the marketplace at any interval, in realt-time, as programmed by the user, or to sell the stocks at a particular time or date, whatever the price of the stocks is at that time, etc. (i.e., "Set Sale Parameters" function is provided as part of the menu, similar to that of "Set Loan Parameters").
The program also incoφorates functions like frailing-stop-loss monitors such that users could preset the system to invest in certain financial instruments at a certain triggered event, and have the system automatically exit the investment, delivering profits back to the user's bank account accordingly, should the exit-trigger be tripped.
Accordingly, the user may program any type of speculative (or non- speculative) activity which can take place at a future time, according to the parameters set by the user.
In addition, the program, upon automatic execution of the Transaction when the parameters are met upon the "Test", the program can automatically_(or upon request by the user) notify the user that the programmed Transaction has occuned, by providing a message to the user when the user logs in, or an e-mail to the user on the user's computer, or to his mobile telephone, pager, or mobile organizer, etc.
Thus, the Transaction can be performed remotely, securely, and automatically through the distributed finance system of the present invention.
Collaborative Simple Transaction
The difference between the Traditional Compound Transaction and the Collaborative Simple transaction is that the former makes it possible for a single customer to manipulate multiple single-user accounts and fransactions together in one place, whereas the latter creates the possibility of multiple customers participating in the same account and/or transaction. Methods and systems consistent with one embodiment of the Collaborative Simple Transaction is described below. Note as described above in Example 2 of Traditional Compound fransaction, that the transaction types can be combined as users see fit to create extended transactions that achieve their needs. Example 1
In an example of a Collaborative Simple transaction, the user may set up an investment opportunity or other fund-raising activity, which is extended to other system users. The "investment opportunity" is set up by the user on the Transaction Workpad, similar to what is described in the Traditional Simple Transaction example, except that this type of fransaction is offered to a predetermined number of users, or otherwise defined or constrained such as with a ceiling amount of desired investment funds (for example, for raising money to donate to a charity, or inviting others to invest in coφorate securities). The user can then use the menu options, for example, to create the list of users
("invitees") to whom the user would like to send the "opportunity" , or in another example, to choose variable constraints and offer access to the opportunity, to any user who meets the preset constraints. The distinction of the type of user participating in this kind of transaction may be visibly displayed on the user interface, perhaps with the named, specifically invited parties represented with a square object (FIG 19), and parties unnamed but qualified per preset constraints represented with circles (FIG 19). The CDMX module of the program will provide a unique parent transaction number for the offering, and then for each invitee user name a child code; also, CDMX will generate unique offering transaction invitee passwords for distribution to each invitee listed. In addition, the user can access the menu and pull down Options, where the user can adjust various constraints on the fransaction, for example a time limit on the acceptance and/or participation in the transaction (i.e., 30 days).
Once the invitees are confirmed by the user, the program will automatically notify those users' system accounts, such that the next time those users log into their accounts, they will see notice of the offering opportunity, perhaps in the form of a blinking icon, etc. Upon acknowledging, with a mouse-click for example, the notice of invitation to participate in the opportunity, the system will request input of the specific offering fransaction password. If the user does not have this password, the offering will not be accessible. The invitees will receive their individual offering- specific passwords either via e-mail, (or by phone, post, etc.) In this way, the user owner of the transaction would have to mistakenly identify an invitee TWICE in order for the wrong person to accidentally gain access to a fransaction that was not intended for him or her (once in identifying the said invitee to the system, and once again in communicating with the invitee, presumably by sending e-mail with the specific offering fransaction password to the same wrong person.
In the case where the right invitee is notified of the offering successfully by the system, but the wrong person receives the offering specific fransaction password, even if that person has a system account and logs in, there will be no notice of the offering invitation, and so the password will be useless. Conversely, if the system- identified invitee is mistaken and the wrong person receives invitation notice of the offering fransaction, that user will not have the necessary password to access the opportunity. In this way the system is designed to be secure, and to limit by design inadvertent, unintended, and even undesired financial interaction.
If access is achieved via the conect system account being notified with the subsequent conect specific invitee offering password being inputted, the user will be given access to the "investment opportunity" by the system, via for example, during mouseover, or by right clicking on the mouse to pull up a menu, or dialog box, or the like. The transaction details will be provided in real-time by the program, and the program will provide all information to the user (i.e., amount requested, date requested, other investors, amounts other investors have provided, etc.). After review of the "investment" fransaction details, the invitee may then
"accept" or "decline" the "offer" of the "investment opportunity". If the invitee declines the offer, then the program will delete the icon from the Transaction Workpad screen and in one example, provide the invitee with a means to send a comment to the offering party. The user may also exit the transaction without accepting or declining in the even the user wishes to review the transaction again at a later date.
If the user wishes to accept the transaction, the user can click "accept", for example, and can then proceed to set up a fransaction similar to that of the Traditional Simple transaction, where, for example, the user accesses a bank account to remove money to pay an entity - in this case, the "investment opportunity".
As with the Traditional Simple fransaction, the user can Test the fransaction and Save it. Further, the user can set up a payment scheme to pay into the "investment opportunity", similar to the way that the user would set up a payment of a bill from a store using funds from his bank account or mutual funds account etc., which may include set or variable amounts remitted at regular or random intervals. Once the full amount is paid into the "investment opportunity", the program will close or make unavailable the icon, and the user will have a fransaction record of the amount paid into the "investment opportunity" similar to that obtained when a bill is paid. This investment opportunity transaction event may not be re-usable in terms of investing again at a later date, however that fransaction file may remain on the invitees client and be updated with real time information about the investment asset. In this way, even a one-time transaction event may be updated with real time information.
Example 2
In another example consistent with the present invention, two system users may wish to collaborate in a purchase on-line. The purchase will require a number of different amounts of funds from each one or multiple of the two users banks accounts, credit cards, etc., to remit to the third person selling the item.
However, unlike e-cunency systems, the seller does not need a special account to receive collaborative transactions, since the program can direct, via the MaQs program module, payments to existing accounts via existing infrastracture. The fransaction is built much like in Example 1 , where a "purchase opportunity" can be built where a first user can invite the second user to pay into the "purchase opportunity" until collaboratively the purchase amount is reached. At that point, the first user can "invite" the seller to sell. To achieve this the first user will have the "purchase opportunity" automatically be sent to the seller via the program of the system, and then separately notify the seller either via e-mail, verbally, etc. of the specific opportunity password. Note that to participate in this kind of fransaction users must have a system account (otherwise the double-secure approach to authenticating participants is difficult to achieve). The CDMX module of the program will follow each transaction to ensure that they are conducted securely. Example 3 In another embodiment consistent with the present invention, Example 1 can be used one step further, with a foreign currency exchange component. For example, as shown in FIG. 19, the "investment opportunity", identified as icon 1 on the Transaction Workpad, can be sent out to four potential participants, identified as icons 2-5. The user can set up a foreign exchange component (identified as the vertical bar between icon 1 and the user (large bank account icon at left), where any one of the entities to the transaction can supply funds in one cunency to have it automatically converted into another cunency. Here is another example of different transaction types combined to perform a single larger fransaction. For cunency exchange capability, see below in the Collaborative Compound example. Collaborative Compound This transaction is the most sophisticated of the four embodiments, and the one for which the system was primarily designed. In Collaborative Compound transactions, millions of users, for example, can be united in their pursuit of their financial goals. As stated previously, in Collaborative fransactions, both sides of a transaction are considering themselves to be customers, and in doing so, fulfill each others' provider roles. Often the customers have no direct awareness of each other, and the present invention is simply using the Collaborative Compound embodiment to make the transaction more efficient or less costly or both.
There are no currently fransactions today which follow this model, thus the following example is illustrative of a Collaborative Compound transaction.
The Collaborative Compound transaction consistent with the present invention is described in more detail hereinbelow. In Collaborative Compound transactions, the program utilizes all the major program modules, such as the VfT, SVR, CDMX, and MaQs program modules.
Further, although the first example provided below involves an exchange of cunency, note that this can be accomplished in any of the different fransaction types - from Traditional Simple to the present Collaborative Compound. For example, a Traditional Simple fransaction involving payment of a bill can be conducted by paying an entity in France in French Francs (or Euros) for an item, and exchanging U.S. Dollars for the Francs (or Euroes). Thus, cunency exchange is not the sole province of the Collaborative Compound example.
Example 1 Thus, in one example consistent with the present invention, and as previously described briefly with respect to Collaborative Compound fransactions, a user's company may require British Pounds for certain activities. The user will access the system website and build a "Change Cunency" transaction in step S200 of FIG. 20, on the Transaction Workpad, using the steps to assemble the fransaction using the VfT program module, as described, for example under the Traditional Simple transaction. Once the user has built the transaction, the user can test, and execute the fransaction if desired, as has been previously described.
When tested, the program will query, using the CDMX program module and the MaQs program module, to obtain real-time market currency rates in step S201, country, or counteφarty data, if the user has indicated that he cares to know such info, and it is available, to present the user with the information such that the user can make the determination of whether the user would like to execute the fransaction.
If the cunency exchange rate is not what is desired by the user (i.e., the cost of British pounds is too high), the user will be able to program the transaction such that the program can keep querying the marketplace at scheduled intervals until the cunency reaches a certain exchange value, or the user can program the fransaction to occur on a certain day, etc., as has been described previously with respect to other simpler fransactions. The scheduled transaction is designated a passive-fill or passive type transaction by the program by default, unless indicated by the user to be performed immediately (i.e., real-time), or by event trigger, which is the fixed type. If the user decides to execute the transaction in real-time in step S202, the program will invoke the CDMX program module to codestamp or assign a unique transaction number (i.e., parent code) in step S203 to track the fransaction through the system. The program will preserve the recorded information regarding the fransaction in encrypted form using the CDMX program module, and confirmation data is passed back to the VfT program module by the program in step S204, which provides this information to the user via the user interface. Note that in a real-time designated transaction, funds would not be removed from the user's accounts in step S205 upon execution of the request, but after fulfilling the request (i.e., matching of counteφarties or assignment of match codes as described below), such that execution instractions to the relevant account(s) could be sent immediately (i.e., instractions are not possible until match-pairing is resolved).
Once the program has codestamped the request, the program invokes the MaQs program module, and the SVR program module to execute the transaction. Once the MaQs and the SVR modules of the program are invoked, using one of the major algorithms, such as an arithmetic mean or an algorithmically calculated separator, the SVR program module will match counteφarties to achieve the desired fransaction in step S206. In particular, the transaction vectors are separated according to direction and amount type (e.g., cunency pair) and ranked by value. The SVR program module then proceeds to cross-match according to the varying algorithms described previously.
As stated previously, if an amount is originally classified by the program as active-seeking, the program will seek to fulfill the request with a single counteφarty match amount. Further, if an amount is originally classified by the program as passive-seeking, then it will be reduced by active-seeking amounts until it falls below the mean and is reclassified to become an active-seeking amount itself, after which it is filled and the fransaction is completed.
Thus, the matching of a request to exchange dollars for British pounds, and a request by another user to exchange British pounds for dollars, can be matched using at least one of several algorithms. Regardless of what algorithm the program uses for the exchange (and this algorithm is programmable), the SVR program module will always produce counteφarty match-pairs.
The program will match a request for British pounds by the user with a matching request for U.S. dollars by another user holding British pounds. If there is a larger amount on one side than the other, and there is a non-zero remainder left on either side after a match is made, then the program matches the remainders on another pass through the system. For example, as a large fransaction passes through the system, the SVR program module will break up the fransaction amount into a number of pieces, and match each one to a different counteφarty in successive transaction passes through the system.
The CDMX program module will be invoked to codecycle and track the individual parties (tag the match pairs) through the counteφarty matching resolution (vector-spreading) process in step S207, and to create several additional child-codes to track the different or successive pieces of the transaction through the matching process, and make the transaction pieces traceable to the parent fransaction, until all remainder amounts are matched or resolved. Each of these codes are logged in an accounting tracking ledger by the CDMX program module, and sent to accumulate in the Codematch Aggregator (further described below) in step S208. After the matches are made, the CDMX program module will reassemble the transaction pieces, prior to payment execution, such that the end result is the accomplishment of the desired transaction. Note that the system does not handle each fransaction to completion, in strict serial fashion, but will push successive fransaction requests into the mix, or interlace the fransactions, even while a cunent fransaction is still in the midst of being fulfilled. Since the SVR program module handles multiple fransactions simultaneously, the matched pairs will have a multitude of counteφarties. Thus, the program invokes the Codematch Aggregator function of the CDMX program module for collection (aggregation of same-user transacted amounts), and netting (amounts are netted) in step S209, before the program invokes the MaQs program module to execute the funds fransfer instractions from the user's account to the appropriate user-destination account, which sum equals the full, originally intended transaction, performed over the existing financial systems infrastracture. Thus, the Codematch Aggregator program, may, according to programmed setting, wait to activate the Bank Multiplexer program so that the fransfer of funds to the user account can be batched in step S210. The CDMX program module will log the confirmation and fracking information of the executed transaction. In SDEX (real-time, immediate fransfer) transactions, instructions will be executed to user accounts after counteφarty matches are already executed. In CDEX (fixed and passive-fill) transactions, user accounts may be initially remitted to a system-owned account (see Investment Engine below), for holding, during and after the time counteφarty matches are resolved by the SVR program module, until the precise user -indicated fransaction takes place. In the event that the transactions involve currency conversion, and are not designated as speculative by the owners of such transactions, the system may at its own programmed discretion, draw down funds immediately for holding in the base cunency, or convert and hold in the target cunency, until the user's prescheduled transaction comes due and calls for the funds.
As stated with the Traditional Simple transaction, the program notifies the user of the completion of the transaction, and the deposit of the target currency to their account, and the debit of the conesponding amount in their currency, plus any fees from their own account, via messages within their login account, e-mail, or by phone, cell phone, fax, or any other medium desired. Fees debited for the fransaction are channeled to the system-owned account by the program, as profits. Example 2 As shown in a second example consistent with the present invention , in FIG.
21 A, the CSFB's -44 amount is an active-seeker, which the program cross-matches to the CSFB +120 in FIG. 2 IB, creating a 44 zero-sum pair, and leaving a system remainder of CSFB +76 (see FIGS. 21 A and 21C).
The program active-seeks the JP +32 to create a 32 zero-sum pair (see FIG. 21 A), leaving JP -88 in the system, which the program immediately matches with the active-seeker Bob +12, creating a 12 zero-sum pair and leaving a JP -76 in the system (see FIG. 21C). The program creates for the CSFB +76 and JP -76, the final zero- sum pair for the period, leaving the system empty (confirming the zero-sum for the universe) (see FIG. 21C).
Thus, the Macro Ledger zero-sum pairs are listed in FIGS. 21 A and 21C, and when a zero-sum pair has the same counteφarty on both sides, it can be eliminated by the program, producing the empirically reduced Macro-Ledger of FIG. 21C. The empirical Macro Ledger of FIG. 21C displays the most efficient capital vectors (amounts and directions). If all the amounts were transfened independent of netting, 164 units of capital would move. If single party netting is used, 100 units of capital move (88 from JP to CSFB, 12 from CSFB to Bob). If Spread- Vector netting is used, only 88 units move (as indicated in the macro empirical ledger below - JP moves 12 to Bob, and 76 to CSFB). This minimum capital movement still satisfies the net ledger account for each party in the universe (by summing the values in each of the individual ledgers for CSFB, JP, and Bob). Example 3 In another example consistent with the present invention, on a larger scale, instead of a single user changing funds into British pounds, a country, like the United States, could pay the United Nations US$4 million in back dues, converted to Euros, for example, to be deposited in a Geneva bank account. The present system can execute such a compound transaction and match the individuals and business in Europe (that hold Euros and are seeking Dollars) with the request for Euros by the U.S., to resolve a perfect collaborative match among thousands or millions of unknown counteφarties. The present system's efficacy is not limited strictly to cunencies, but to anything that may be treated as a fungible instrument of trade.
Note that if the system does not have enough resident liquidity to meet the needs of a currency exchange, or any transaction, the program can automatically check the marketplace and channel conversion requests to traditional banks to meet the requests. This capital infusion would be transparent to the users, excepting the pass-through of any traditional-market fees that would result. It is conceivable, in the event of a liquidity crisis, for conversion requests to not be met, and likewise, that the general marketplace as well would not have anyone willing to supply a target cunency.
In other words, the system described herein cannot avert liquidity crises, however the program can give early warning of such things given daily volumes monitoring, etc., and due to the fact that the transactions can be programmed and scheduled (passive-fill), some degree of moderation may result as the system could be programmed to execute pre-scheduled passive-fills during periods of slackening liquidity.
Furthermore, due the fact that Distributed Funds Transfer (DFT)(described below) is enabled by this system, a very early warning of mass-market worldwide liquidity crises may result since the system is capable of bypassing regulations that stem from the politics of capital flight (which create a drag on the free flow of capital), and system personnel may notice more clearly, the initial localized liquidity crises that would occur from people frying to export capital from a country, and not being able to use the system's DFT function because of the lack of parties demanding the would-be capital-exporters' base currency, and not because of regulatory restriction, etc.
Example 4 In another example of a Collaborative Compound fransaction consistent with the present invention, an exchange of capital funds can be made between two companies, self-selecting each other, or randomly matched, which have capital management needs that are complementary to each other. If for example, an American company wishes to repatriate RMB profits earned in China, back to the US (as US Dollars), there are likely to be restrictions on transferring funds out of China. And if a US company wishes to have a supply of US Dollars converted to RMB for the sake of new investment in China, there are likely to be restrictions on bringing in new capital.
The SVR program module, executing a Distributed Funds Transfer process, could, given proper settings of target bank accounts, simply resolve a vector schedule that comprised of two domestic transfers, one in each the US and China, to each the opposite company's accounts from the local company's account. At face value this would appear to be two independent, unrelated domestic movements of funds, but as a macro event would amount to the two companies swapping their hard cunencies via a distributed system. In this way, the two companies could each achieve their objectives to move money across an international boundary, but without the difficulties, notice, cost, and possible restriction on international capital movements. If the immediate request date cannot be met or the amount of funds filled for some reason, the program will prompt the user to wait until a system-suggested date, or to cancel the transaction for a later time. Once the fransaction can be executed, the funds are drawn from the bank accounts of both parties to the transaction, and the program will fill the requests and remit the amounts in the target currency to the users' bank accounts.
Investment Engine for Profit and Philanthropy
In one embodiment consistent with the present invention, at the user's direction, or, for passive-fill request types, the program - via the CDMX and MaQs program modules - will aggregate distributed capital flows through a revolving door holding account, with funds being used to temporarily hold risk-free or low-risk investments.
As stated above, the passive transaction type is the default type, and is characterized by the user indicating that the transaction must occur by a certain date. This means that any time up until that date may be constraed as a date which is acceptable to initiate, execute the fransaction, and use the capital. Accordingly, the system can pull the funds of a passive-fill transaction, and hold those funds in the account for short-term investments. Further, for certain immediate fransactions, such as cunency exchange, the system may charge a fee premium. Specifically, as stated above in the Collaborative Compound transaction, when the user initiates a passive request cunency exchange fransaction, for example, the program (i.e., the MaQs program module) may remove the user's funds immediately from his account and move the funds to a holding account within the system, and the funds - along with other funds from other temporarily held accounts - may be invested in money market accounts, or savings accounts at traditional financial institutions, etc., which have low or zero risk (because the funds must be returned to the owners or sent along the way to finishing the transactions they started out completing), even if the owners have given their approval for investments.
The program automatically pulls market data and checks what types of financial instruments are available within the necessary risk parameters, and determines the opportunity cost of capital for each choice (i.e., cost of entry, exit, and capital requirements). The program then checks the rate of capital vector flow and egress into/out of the system and the rate, as well as the rate of capital vector flow into the codematching system, and determines the "optimal" capital exercise option which provides the best return for the required system liquidity level (i.e., rate of capital drawdown by the Bank Multiplexing function, and the system desired rate as called for by the Codematch Aggregator function).
Among the types of zero or nearly zero risk options which generate very small returns on an individual scale, but when multiplied by millions and millions of times over a year, for example, would aggregate to significant amounts of generated income, are: aggregated funds into a bank account held by the system for overnight interest income; purchase of secured loan portfolios of AAA ratings; purchase of U.S. Treasuries with leverage, selling them for cash, putting the cash into a bank account for interest income; purchase of U.S. Treasuries with leverage, selling them for cash, and lending the cash to a AAA rated coφoration; and buying U.S. Treasuries with leverage, lending to a Hedge Fund overnight or longer, etc
When the counteφarty matches are scheduled to take place, or when the due dates are coming due on and execution instractions will soon call this diverted capital, the program waits for matches to occur, then the program remits the funds where they need to go, albeit form a source account that is owned by the system, and not the original user's account. Individual accounts may be used to generate this investment directive, or a percentage of the aggregate of capital flowing through the system can be used. The user may know or not know that the money is being used for investments.
Note that when the system requires capital return to complete a user fransaction, instead of unwinding the investments in place, made by previously diverted funds, the program will divert newer incoming capital to fill the user transaction. When the investments are returned to the system, they are also available as new capital to fulfill transactions.
The profits engendered by the investments can either be returned to the user by the program, if the user so directs (i.e., the user can set up a transaction to take place at a later date, authorizing the funds to be removed immediately and placed in a money market account until the transaction takes place, with the profit being returned to the user while the initial fransaction amount moves forward to be executed); or the profits can be directed by the user to be, perhaps aggregated, and used for philanthropic puφoses. The system profits can also be reinvested automatically, to aggregate funds for capital purchases to update the system, or for philanthropic puφoses at a later date etc.
Because the program tracks and executes everything, investments could be held indefinitely, with new incoming distributed source funds being deflected by the program to pay for prior source purchases, and this deflection (shifting) of funds does not increase systemic risk, because 1) most purchases are made online with a credit card, and 2) the present system can easily require pre-allocation of usable funds into a one-way account.
Once disfributed-source funds are used to generate profits for philanthropic reasons, particulate tax-credits can be automatically issued back to each source by the program, and further, the program can grant allocation votes commensurate to each particulate amount. Allocation votes allow each participant to have a democratic say in how the philanthropic funds are to be used, with available options orchestrated by professional philanthropic experts. Further, the present system could issue tax credits, based on a weighted average from the record logs, from its philanthropic activity back to the users as a benefit for the capital they allowed the system to use.
Thus, other financial services in the investment arena, can be offered to the users. Further, if the user does not wish to use his own money in taking advantage of the investment opportunities, the user can perhaps borrow money from a financial institution to partake of the investment opportunities.
Capital Infusion In one embodiment consistent with the present invention, as stated above, the MaQs program module periodically automatically checks the system to ensure that there is enough liquidity to readily facilitate the proper functioning of the system. If the system is severely asymmetrical (based on the arithmetic mean, or the like, or a fluctuation of more than 10 percent, for example, variation with the Oppside) the program will automatically use new capital by opening itself to fraditional banking channels such as JP Morgan, which may be interested in a new source of business, or in the event that the owners of the system wish to put some of its own capital, system profits could be used (i.e. invested in the operations of the business) This capital infusion would be transparent to the users, and codematching would continue without stopping with any unmatched requests simply passing through the system over and over until filled.
Credit Operation
In another embodiment consistent with the present invention, in addition to a philanthropic motivation for the aggregated funds or profits engendered in the above operations, the system would encompass more-sophisticated functions which can become entire systems onto themselves.
For example, the program could offer a credit service operation, extending credit to a system user, group, small business, or even large coφoration, and issuing credit and/or ATM cards, similar to what banks offer presently (in this case, since the system is tied into the user's accounts, it can easily perform a credit rating on the user when the user requests a credit card or credit line or loan); or the credit rating could be generated on a distributed basis as explained below. This credit rating may be generated in conjunction with the CDMX program tracing function of actual payments, rather than relying on 3rd party credit bureaus such as Equifax, et al.
To get users started with a system-determined credit rating, the evolution of
the credit ratings may follow that of Ebay™, whereby account usage would be the
primary factor in communicating the user-rating. However, the basis for the user credit rating could also proceed a number of other ways, including being based upon some mathematical equation that takes an existing credit score input to arrive at a non-zero initial rating for each user.. The initial credit-score input could be a formal credit-bureau score, or an adapted one based on the submitted record(s) of a user's credit card usage, manipulated by the program via some algorithm, to arrive at a range or a specific number, which would be the initial credit rating that the user could then use to begin participating in the collaborative environment. Lending and Microlending In another embodiment consistent with the present invention, the system could offer a direct-lending system where users of the system can rate and lend/bonow from other system users (whether individuals or coφorations), as well as from the system itself if the system should have accounts activated for that puφose.
In the direct-lending system, a user can offer funds to other remote users (which may be used in Africa for example) at a defined interest rate and payment schedule, and bonowers can bonow money at a certain interest rate and payment schedule, and the bonowers/lenders need not be aware of each other since the program automatically debits the accounts of the borrowers and credits the accounts of the lenders at the scheduled times and will even automatically execute cunency conversions to repatriate loan repayments.
Another example is microlending. The microlending model architected by the Grameen Bank Project uses a peer-to-peer network-effect, albeit offline, and on a very small and local scale.
With the collaborative functionality of the present invention described herein, microlending can be facilitated on a global-local scale, making it possible for individuals to easily and swiftly direct their own capital flows toward any comer of the planet they choose. With the collaborative object model of the present system supporting the same network-effect peer-relationships (i.e., self-selecting committed individuals), the potential to bring unprecedented speed and fluidity to involvement, commitment, and funds flow to humanitarian efforts, rescue efforts, emergency efforts, etc. is within reach. Thus, while Grameen Economics deals with micro amounts offline (even if funds are collected from donors online, the distributions of the donations happens offline, distributed by a governing organization), the system described herein would support collaborative transactions and direct disbursement at any amount level, whether micro, or massive, allowing users to lean on personal relationships, reputation, and integrity to win participants (i.e., peers) in the bonowing or investing opportunities they offer; and then interact with each lender/investor directly or as a group. In the communal-direct approach to bonowing and lending of the present invention, the CDMX program module will be fracking everything, and "success points" could be awarded to all participants for aligning themselves with a successful credit fransaction, thus becoming an incentive. The accumulation of these points, displayed in the user interface by the program, would amount to a distributed credit- rating system, or more broadly, a distributed integrity rating, whereby the network of participants could begin to make assessments about the credit-worthiness of a stranger, based upon previous record.
This would pave the way for users, companies, etc. to charge higher interest rates for money lent (i.e., high-quality lenders or investors known for being involved in successful transactions can charge a premium because their participation in a deal often provides a psychological element that facilitates further participation by others, and ultimately success for the fransaction), and lower bonowing rates (reliable bonowers will have a superb record of payment, and will enjoy excellent credit, hence lower rates for borrowing). Additionally, the integrity premium enjoyed by honest and reliable participants in the community (system), may also include advantaged or preferential access or offering ability for investment etc. that others with lower integrity ratings would not have access to. Universal On-line Purchasing In another embodiment consistent with the present invention, fraditional online purchases can be made (i.e., Traditional Simple fransactions), where the user can utilize the option of paying with the system either as a direct debit from a user account (i.e., bank, sale of stocks etc., which is set up like any of the previously described fransactions), or a system loan (as previously described), or the system credit card. These transactions can be carried out in real-time, or at a programmed time, which allows the user flexibility in making his purchases. However, in some cases, currency is an issue where one user is in the U.S., for example, and wishes to purchase an item in another country which is listed in a foreign cunency. Using the present invention, when making a purchase, the user may utilize the system to pay for the item, thereby authorizing the system to pay for the item in the target currency and deduct the user's account for the corresponding U.S. cunency.
Specifically, after shopping on-line, at the checkout screen on the merchant's website, the user can select "Pay with The system" as the payment option. The system screen will be selected, and the program will prompt the user for his login and password (a specific password for only on-line purchases can be set up as well). The user can confirm his purchase at the Transaction Workpad screen, and using the system-merchant identification code, and any other identification code (such as for the item being purchased, or the purchase order number), can exchange currency as in the above Collaborative Compound fransaction. The CDMX and MaQs program modules will track the purchase and execute the fransaction, and fransfer the target cunency funds to the merchant account, and debit the user's account of funds. The program will notify the merchant that the funds have been provided and that the transaction is complete, and will also notify the user of the debit of funds from his account.
ATM Sharing
In another embodiment consistent with the present invention, using a concept called Quantified Access, non-native ATM cards can use any ATM machine in any bank-domain and not utilize Plus or Cirrus or other similar networks (which would incur fees).
Quantified Access means granting a temporary and quantified amount of access to deduct funds in a bank account not owned or associated or linked or in anyway associated with the ATM card which draws down the funds. The permission granted to the ATM card is such that any bank or any bank's ATM will recognize the
ATM card as native.
It is conceivable that this can proceed without user permission (i.e., the instantaneous use of their accounts for temporary insertion of funds which are drawn down immediately, hence leaving the account in its original state). However, regulatory issues may require that he system users indicate permission for using their accounts for this puφose.
The process is as follows, a user goes to an ATM machine which is not native to the domain that his or her ATM card can use fee-free. This may be in any cunency domain as well - it does not matter- since the system can execute the exchange transaction as required, which process is explained in detail below. The user inserts a card, it is validated as a valid card by the ATM computer, where the computer checks for validation that the given ATM card is connected with a valid bank account at a real bank in the world.
Once validated, the user is usually prompted with a screen that indicates that there will be a charge of $1.50 or some similar amount for the fransaction if it is not a free transaction for a native bank user.
Since software programs like Intuit's Quicken™ and other accounting
software for end-consumers is already capable of downloading bank-account data over a network, it is conceivable that this account monitoring may proceed in real- time. Thus, the system may be set by the users, to frack activity on accounts registered therein. If users have set their accounts to be responsive in this way, then, as soon as the user approves the potential fee charge for ATM usage on the ATM screen, the system program will be notified of the pending bank deduction for the ATM withdrawal, and will take over the fransaction, not allowing the banks to proceed.
First, without canceling the user-session at the ATM, the program will halt the proceeding at the banks, not allowing a deduction at the home bank, nor allowing cash-dispersal from the ATM.
The program then moves funds from the user's account using the bank multiplexer program module, to any account X within the ATM domain that is being used for the cunent transaction, similar to what may occur given the willingness of any owner of such account X within such domain, to lend funds to quantified access for the user to withdraw. The CDMX program module updates the tracking logs accordingly. At the same time, the bank which owns the ATM is sent information by the program indicating that the non-native ATM card that was read at the ATM, has native-level quantified access to account X. Funds are immediately dispersed from account X, leaving its balance in the original state (logs will show an instantaneous deposit and withdrawal of the same amount), and no fees are charged because the bank recognizes it as a native-ATM card withdrawal.
Thus, quantified access means that permission is provided by the program to deduct certain defined and limited amounts of funds from an account that the user does not normally have access to, such that the bank will recognize the ATM as a native account. In other words, the ATM card is temporarily and for a quantified amount only, being recognized as an ATM card linked to account X.
Now, since the cash dispensed at the ATM is not really physically taken from user accounts, and is just deducted electronically, it may not be necessary to actually have the system move funds into any X account; any generic account at the Bank should work, which means that if the system opens and maintains a bank account in any and all bank-domains, then it could simply use its own bank accounts and grant quantified access that way, essentially offering all the system users a shared account, thus bypassing ATM fees in any and all domains, anywhere worldwide. Distributed Funds Transfer In another embodiment consistent with the present invention, the present system can make any conventional funds fransfer a distributed funds transfer, dispersed to a thousand different directions in small amounts, shifted via transitive resolution and collected at the destination as smaller-amount transfers that would converge to sum to the original amount. The SVR program module could do this such that the dispersion pattern is undetectable, which implies certain security or safety inherent in the system since external observation of the transfers would not yield any insight into the method of dispersion..
First, to offer a definition, a funds fransfer, or elecfronic funds fransfer (EFT) is the intentional targeted movement of funds over a network, from point A to point B.
A distributed funds transfer (DFT) is a method for using existing funds transfer networks, to the effect that a macro zero-sum awareness of the funds-flow universe allows for a vector polarization of funds-flow toward and away from two chosen points (i.e., the sender and receiver) such that the net at each the sender and receiver is fulfilled according to the directions of the original intended fransfer, WITHOUT funds moving directly from the sender to the receiver.
Since communications fransmission speeds over global interconnected networks approach instantaneous, it is possible for awareness propagation to provide nearby clients, servers, and servents with information about what is being experienced and what is visible to remote clients, servers, and servents. Note that in a network that operates at these speeds, "near" may include "global". Since the present invention uses existing infrastracture (which is subject to existing regulations) to execute funds fransfer, the funds transfer is very difficult to predict and frack externally.
This means that at the instant a (physically or geographically) remote entity R makes it known to the network certain information regarding the desire and intention to move funds from some point A near itself to some point B remote from itself in the physical, geographic world, some entity S may be considering a desire and intention to move funds from some point F near itself to some point G remote from itself in the physical, geographic world. In today's world, funds transfers are pursued each independently, in complete vacuum from any other fransfer being carried out over the funds transfer networks. Only in the event of "netting" (which is a computational approach to reducing total capital movement between two parties by summing all in and out transfers to the same party over a fixed period of time, to achieve a "net" amount that can be sent at the end of the period), are multiple transfers considered with reference to other transfers.
With the system of the present invention, given risk-definition guidelines for each participant in the system-network, the program can watch via awareness propagation, for near-to-far and far-to-near funds fransfer notices, and using preset algorithms at all participating clients, servers and servents, the program can achieve for example, a redirection of funds such that the total summed distance of all funds movement was minimized. This may for example, mean that instead of moving funds the long haul from A->B, and also the long haul from F- G, that two smaller transfers F- B, and A- G lower system-wide risk by reducing total amount of capital per time at risk, and fulfills the obligations of all parties.
In the present example, where A- B, F- G switch counteφarties to reduce total capital travel, this is only feasible where the two intended transfers are equal. This parity (symmetric) condition stands as a threshold to critical mass, which explains why such a system does not exist today. The present invention solves this parity condition by entertaining all vectors in the universe, and more importantly, successive vectors in the universe. Since funds transfer networks experience a volume that is constantly rising, it is reasonably reliable to assume that successive vectors will come. The present invention is a unique system for managing fungible fransactions that treats the transactions as vectors that are part of a vector field, or flow, theoretically assumed to be peφetual.
Specifically, as discussed below, the program first receives the user's command to send funds, via some funds fransfer network. Then, the program of the system client/server/servent discovers via awareness propagation, an intended funds transfer targeting its own institution or one nearby. The client/server/servent of the present system identifies direct communication pathway to that remote client/server/servent, and opens communications. The two clients/servers/servents trade information about their intended fransfer vectors, recording locally the net vector position intended at each target (recall a vector is a 2-dimensional entity, in this case containing amount information, and direction information). (Note: this now means that banking information can be completely redundantly dispersed, and to a large extent anonymously, or at least in encrypted form, to the extent that it would be virtually impossible to eradicate and destroy financial records; natural disaster, or tenor aimed at eliminating assets in the name of equalizing all people would become an exfremely remote threat to modem society). The two clients/servers/servents recursively compute optimal fransfer directions for any included intended vectors in a given defined period of time. Note that "recursively" assumes a constant interaction with a changing network population of intended fransfer vectors (i.e., that awareness propagation is bringing every participating client/server/servent new information about new intended transfer vectors) that can now be included in the distributed fransfer optimization process.
"Optimal" is defined as the most efficient vector or vectors as computed in the context and extent of the period-awareness vector-universe.
Thus, in a Period.Distributed (or Dispersed) Funds Transfer, because the program can achieve delivery of funds from a specific account A to a specific intended target account B without directly transferring funds from A to B, the DFT becomes an incredible tool for almost all high-value transfer agents, who are worried that their transfer lines may be compromised by hackers, terrorists, natural disaster, etc.
When periodicity concludes, optimized distributed transfers are executed by the program. Some net vector conditions remain unfilled, or only partially filled; and the successive period includes awareness of these unfilled and partially filled vector conditions. Various preset rales of the program hold that older incomplete net vector conditions will be filled first, thus bringing completion to each successive wave of uncompleted and unfilled transactions.
Thus, the present system brings the same relentless reroute-until-delivery-is- achieved reliability to fungible instrument fransfer, as TCP/IP brought to communications via the Internet.
Security and Privacy Issues
Transaction vectors will be encrypted while in the system, providing complete privacy to all users of the system. However, vector amounts, directions, and identities may be decrypted separately at the order of legal authorities. The present invention's program may provide filters that recognize and alert system administrators to potential laundering type or tax evasion type activities.
It should be emphasized that the above-described embodiments of the invention are merely possible examples of implementations set forth for a clear understanding of the principles of the invention. Variations and modifications may be made to the above-described embodiments of the invention without departing from the spirit and principles of the invention. All such modifications and variations are intended to be included herein within the scope of the invention and protected by the following claims.

Claims

What is claimed is:
1. A method in a data processing system having a program, the data processing system connected to at least one of a plurality of remote data processing systems via a network, the method comprising the steps performed by the program of: receiving from a user a request to execute at least one financial fransaction with at least one of a plurality of parties, each of the parties conesponding to one of the data processing systems; obtaining real-time financial information relating to the financial fransaction; and confirming that the financial transaction can be executed with at least one party.
2. The method of claim 1 , further comprising: receiving from the user the identity of the at least one party to execute the financial fransaction.
3. The method of claim 1, wherein the step of confirming that the financial fransaction can be executed comprises: sending a notice of the financial fransaction to the parties; and receiving a confirmation from each party that can execute the financial fransaction.
4. The method of claim 1 , further comprising: testing the financial transaction.
5. The method of claim 4, wherein the step of testing the financial transaction comprises: determining a monetary value of the financial fransaction; determining whether the user is a payor or a payee in the financial transaction; determining whether the user has the monetary value in an account of the user responsive to the user being the payor; determining whether the at least on party has the monetary value to execute the fransaction responsive to the user being the payee; determining whether the user is authorized to execute the transaction; determining whether the at least one party is authorized to execute the fransaction; identifying to the user that the financial fransaction is authorized responsive to the user having the monetary value when the user is the payor, the at least one party having the monetary value when the user is the payee, the user being authorized, and the at least one party being authorized; and identifying to the user that the financial transaction is not authorized responsive to at least one of the user not having the monetary value when the user is the payor, the at least one party not having the monetary value when the user is the payee, the user not being authorized, and the at least one party not being authorized.
6. The method of claim 1, further comprising: executing the financial fransaction.
7. The method of claim 6, wherein the step of executing the financial transaction comprises: determining a monetary value of the financial fransaction; determining whether the user is a payor or a payee in the financial transaction; when the user is the payor, effecting transfer of the monetary value from an account of the user to an account of the at least one party; and when the user is the payee, effecting fransfer of the monetary value from the account of the at least one party to the account of the user.
8. The method of claim 6, further comprising: confirming that the financial transaction has been executed.
9. The method of claim 1 , further comprising: saving information about the financial fransaction to a storage device.
10. The method of claim 1, further comprising: saving information about the financial transaction as a template to a storage device for future financial transactions.
11. The method of claim 1 , further comprising: providing a summary of the financial fransaction to the user.
12. The method of claim 1, further comprising: assigning a unique fransaction number to the financial transaction.
13. The method of claim 1, wherein the bank account is selected from the group consisting of a checking account, a savings account, and a money market account.
14. The method of claim 1, wherein the financial fransaction is selected from the group consisting of an equity transfer, a commodity transfer, a utility payment, a sale of goods, a sale of services, and an auction.
15. The method of claim 1 , wherein the user comprises a plurality of users.
16. The method of claim 1 , wherein the data processing system and the remote data processing systems are connected via a secure network.
17. The method of claim 1 , wherein the data processing system and the remote data processing systems are connected via the Internet.
18. The method of claim 1 , further comprising: determining whether the user is a payor or a payee in the financial transaction; determining the national cunency of the user; determining the national cunency of the party; exchanging the national cunency of the user to the national cunency of the party responsive to the user being a payor; and exchanging the national cunency of the party to the national cunency of the user responsive to the user being a payee.
19. The method of claim 1, further comprising: prior to receiving a request for the financial fransaction, receiving a login input from the user to login; and authenticating the user responsive to receiving the login input.
20. The method of claim 1, further comprising: receiving an input from the user of a monetary value of the financial fransaction.
21. The method of claim 1 , further comprising: receiving an input from the user of a type of the financial fransaction.
22. The method of claim 1, further comprising: receiving an input from the user identifying whether the user is a payor or a payee to the financial transaction.
23. The method of claim 1, further comprising: receiving an input from the user identifying a predetermined time at which to execute the transaction.
24. The method of claim 1, further comprising: determining a monetary value of the financial transaction; and determining whether the at least one party that will execute the financial transaction for the monetary value; and confirming that the financial transaction can be executed with additional parties to the at least one party until a total monetary value for which the parties will execute the financial transaction is equal to the determined monetary value of the financial fransaction responsive to the identified at least one party not executing the financial fransaction for the monetary value.
25. The method of claim 1, wherein the user requests to execute a plurality of financial transactions, each financial transaction being executed a different party, all of the financial fransactions being executed such that a monetary value equal to the user's interest in each financial fransactions is withdrawn from or deposited to an account of the user.
26. A method in a data processing system having a program, the data processing system connected to at least one of a plurality of remote data processing systems via a network, the method comprising the steps performed by the program of: receiving from a user a request to execute at least one financial fransaction with at least one of a plurality of parties, each of the parties conesponding to one of the data processing systems; obtaining real-time financial information relating to the financial fransaction; determining a monetary value of the financial fransaction; determining whether the at least one party that will execute the financial fransaction for the monetary value; and confirming that the financial fransaction can be executed with additional parties to the at least one party until a total monetary value for which the parties will execute the financial transaction is equal to the determined monetary value of the financial transaction responsive to the identified at least one party not executing the financial transaction for the monetary value.
27. A computer-readable medium containing instractions that cause a data processing system to perform a method, the data processing system being connected to at least one of a plurality of remote data processing systems via a network, the method comprising the steps performed by the program of: receiving from a user a request to execute at least one financial fransaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; obtaining real-time financial information relating to the financial fransaction; and confirming that the financial fransaction can be executed with at least one party.
28. The computer-readable medium of claim 27, further comprising: receiving from the user the identity of the at least one party to execute the financial transaction.
29. The computer-readable medium of claim 27, wherein the step of confirming that the financial fransaction can be executed comprises: sending a notice of the financial transaction to the parties; and receiving a confirmation from each party that can execute the financial fransaction.
30. The computer-readable medium of claim 27, further comprising: testing the financial fransaction.
31. The computer-readable medium of claim 30, wherein the step of testing the financial transaction comprises: determining a monetary value of the financial transaction; determining whether the user is a payor or a payee in the financial fransaction; determining whether the user has the monetary value in an account of the user responsive to the user being the payor; determining whether the at least on party has the monetary value to execute the fransaction responsive to the user being the payee; determining whether the user is authorized to execute the fransaction; determining whether the at least one party is authorized to execute the transaction; identifying to the user that the financial transaction is authorized responsive to the user having the monetary value when the user is the payor, the at least one party having the monetary value when the user is the payee, the user being authorized, and the at least one party being authorized; and identifying to the user that the financial transaction is not authorized responsive to at least one of the user not having the monetary value when the user is the payor, the at least one party not having the monetary value when the user is the payee, the user not being authorized, and the at least one party not being authorized.
32. The computer-readable medium of claim 27, further comprising: executing the financial transaction.
33. The computer-readable medium of claim 32, wherein the step of executing the financial fransaction comprises: determining a monetary value of the financial fransaction; determining whether the user is a payor or a payee in the financial fransaction; when the user is the payor, effecting transfer of the monetary value from an account of the user to an account of the at least one party; and when the user is the payee, effecting transfer of the monetary value from the account of the at least one party to the account of the user.
34. The computer-readable medium of claim 32, further comprising: confirming that the financial transaction has been executed.
35. The computer-readable medium of claim 27, further comprising: saving information about the financial fransaction to a storage device.
36. The computer-readable medium of claim 27, further comprising: saving information about the financial fransaction as a template to a storage device for future financial fransactions.
37. The computer-readable medium of claim 27, further comprising: providing a summary of the financial transaction to the user.
38. The computer-readable medium of claim 27, further comprising: assigning a unique transaction number to the financial fransaction.
39. The computer-readable medium of claim 27, wherein the bank account is selected from the group consisting of a checking account, a savings account, and a money market account.
40. The computer-readable medium of claim 27, wherein the financial fransaction is selected from the group consisting of an equity fransfer, a commodity transfer, a utility payment, a sale of goods, a sale of services, and an auction.
41. The computer-readable medium of claim 27, wherein the user comprises a plurality of users.
42. The computer-readable medium of claim 27, wherein the data processing system and the remote data processing systems are connected via a secure network.
43. The computer-readable medium of claim 27, wherein the data processing system and the remote data processing systems are connected via the Internet.
44. The computer-readable medium of claim 27, further comprising: determining whether the user is a payor or a payee in the financial transaction; determining the national currency of the user; determining the national currency of the party; exchanging the national cunency of the user to the national cunency of the party responsive to the user being a payor; and exchanging the national cunency of the party to the national currency of the user responsive to the user being a payee.
45. The computer-readable medium of claim 27, further comprising: prior to receiving a request for the financial fransaction, receiving a login input from the user to login; and authenticating the user responsive to receiving the login input.
46. The computer-readable medium of claim 27, further comprising: receiving an input from the user of a monetary value of the financial ■ fransaction.
47. The computer-readable medium of claim 27, further comprising: receiving an input from the user of a type of the financial fransaction.
48. The computer-readable medium of claim 27, further comprising: receiving an input from the user identifying whether the user is a payor or a payee to the financial transaction.
49. The computer-readable medium of claim 27, further comprising: receiving an input from the user identifying a predetermined time at which to execute the fransaction.
50. The computer-readable medium of claim 27, further comprising: determining a monetary value of the financial fransaction; and determining whether the at least one party that will execute the financial transaction for the monetary value; and confirming that the financial fransaction can be executed with additional parties to the at least one party until a total monetary value for which the parties will execute the financial fransaction is equal to the determined monetary value of the financial transaction responsive to the identified at least one party not executing the financial transaction for the monetary value.
51. The computer-readable medium of claim 27, wherein the user requests to execute a plurality of financial fransactions, each financial transaction being executed a different party, all of the financial fransactions being executed such that a monetary value equal to the user's interest in each financial fransactions is withdrawn from or deposited to an account of the user.
52. A computer-readable medium containing instractions that cause a data processing system to perform a method, the data processing system being connected to at least one of a plurality of remote data processing systems via a network, the method comprising the steps performed by the program of: receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties conesponding to one of the data processing systems; obtaining real-time financial information relating to the financial transaction; determining a monetary value of the financial fransaction; determining whether the at least one party that will execute the financial fransaction for the monetary value; and confirming that the financial fransaction can be executed with additional parties to the at least one party until a total monetary value for which the parties will execute the financial transaction is equal to the determined monetary value of the financial fransaction responsive to the identified at least one party not executing the financial fransaction for the monetary value.
53. A data processing system connected to at least one of a plurality of remote data processing systems via a network, the data processing system comprising: means for receiving from a user a request to execute at least one financial fransaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; means for obtaining real-time financial information relating to the financial fransaction; and means for confirming that the financial transaction can be executed with at least one party.
54. A data processing system connected to at least one of a plurality of remote data processing systems via a network, the data processing system comprising: means for receiving from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties corresponding to one of the data processing systems; means for obtaining real-time financial information relating to the financial transaction; means for determining a monetary value of the financial fransaction; means for determining whether the at least one party that will execute the financial transaction for the monetary value; and means for confirming that the financial transaction can be executed with additional parties to the at least one party until a total monetary value for which the parties will execute the financial transaction is equal to the determined monetary value of the financial transaction responsive to the identified at least one party not executing the financial transaction for the monetary value.
55. A data processing system connected to at least one of a plurality of remote data processing systems via a network, the data processing system comprising: a memory comprising a program that receives from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties conesponding to one of the data processing systems, obtains real-time financial information relating to the financial fransaction, and confirms that the financial fransaction can be executed with at least one party; and a processing unit that rans the program.
56. A data processing system connected to at least one of a plurality of remote data processing systems via a network, the data processing system comprising: a memory comprising a program that receives from a user a request to execute at least one financial transaction with at least one of a plurality of parties, each of the parties conesponding to one of the data processing systems, obtains real-time financial information relating to the financial fransaction, determines a monetary value of the financial fransaction, determines whether the at least one party that will execute the financial transaction for the monetary value, and confirms that the financial transaction can be executed with additional parties to the at least one party until a total monetary value for which the parties will execute the financial fransaction is equal to the determined monetary value of the financial fransaction responsive to the identified at least one party not executing the financial fransaction for the monetary value; and a processing unit that runs the program.
57. A computer-readable memory device encoded with a program having a data stracture, the program run by a processor in a data processing system connected to at least one of a plurality of remote data processing systems via a network, the data stracture having a plurality of entries, each entry comprising: a first storage area that stores a monetary value of a financial transaction; and a plurality of second storage areas that each store an identity of a party to the financial transaction and an amount for which the party will execute the financial transaction, the program confirming additional parties and amounts for which the additional eligible parties will execute the financial fransaction until a total amount for which the parties will execute the financial fransaction is equal to the monetary value.
58. A method of conducting financial transactions over a computerized network, comprising: receiving a request for a financial fransaction from a user; obtaining real-time financial information on the user's account; and confirming that said financial fransaction can be executed.
59. The method according to claim 58, further comprising: testing said financial fransaction with said real-time financial information prior to confirming that said financial fransaction can take place.
60. The method according to claim 58, further comprising: performing said financial transaction.
61. The method according to claim 60, further comprising: saving said financial transaction.
62. The method according to claim 58, further comprising: obtaining real-time information on the user's account prior to initiating any financial fransaction.
63. The method according to claim 61, wherein said financial fransaction is saved as a template for future financial fransactions.
64. The method according to claim 63, further comprising: providing a comprehensive transaction summary to the user.
65. The method according to claim 58, further comprising: assigning a unique fransaction number to said financial transaction.
66. The method according to claim 59, wherein said testing step can be observed on a display, and said real-time information is provided on said display.
EP03716029A 2002-02-14 2003-02-14 Apparatus and method of a distributed capital system Ceased EP1483713A4 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP11174447A EP2400453A1 (en) 2002-02-14 2003-02-14 Apparatus and method of a distributed captial system

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US35614802P 2002-02-14 2002-02-14
US356148P 2002-02-14
US43979703P 2003-01-14 2003-01-14
US439797P 2003-01-14
PCT/US2003/004424 WO2003069444A2 (en) 2002-02-14 2003-02-14 Apparatus and method of a distributed capital system

Publications (2)

Publication Number Publication Date
EP1483713A2 true EP1483713A2 (en) 2004-12-08
EP1483713A4 EP1483713A4 (en) 2005-04-06

Family

ID=27737522

Family Applications (2)

Application Number Title Priority Date Filing Date
EP03716029A Ceased EP1483713A4 (en) 2002-02-14 2003-02-14 Apparatus and method of a distributed capital system
EP11174447A Withdrawn EP2400453A1 (en) 2002-02-14 2003-02-14 Apparatus and method of a distributed captial system

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP11174447A Withdrawn EP2400453A1 (en) 2002-02-14 2003-02-14 Apparatus and method of a distributed captial system

Country Status (10)

Country Link
US (6) US7590595B2 (en)
EP (2) EP1483713A4 (en)
JP (5) JP2005518011A (en)
KR (4) KR101194730B1 (en)
CN (2) CN102496107A (en)
AU (1) AU2003219756B2 (en)
BR (1) BRPI0307674A2 (en)
CA (1) CA2476646A1 (en)
MX (1) MXPA04007821A (en)
WO (1) WO2003069444A2 (en)

Families Citing this family (162)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7587363B2 (en) * 2000-11-06 2009-09-08 Jpmorgan Chase Bank, N.A. System and method for optimized funding of electronic transactions
US8285641B2 (en) 2000-11-06 2012-10-09 Jpmorgan Chase Bank, N.A. System and method for selectable funding of electronic transactions
US20040027379A1 (en) * 2002-08-08 2004-02-12 Hong Huey Anna Onon Integrated visual development system for creating computer-implemented dialog scripts
US20040177258A1 (en) * 2003-03-03 2004-09-09 Ong Peng T. Secure object for convenient identification
US20050027638A1 (en) * 2003-07-30 2005-02-03 Cannan Ng Highly automated system for managing hedge funds
US20050055304A1 (en) * 2003-09-10 2005-03-10 Lutnick Howard W. Trading application program interface
US8527381B2 (en) * 2003-12-05 2013-09-03 Bank Of America Corporation System and method for authorizing third-party transactions for an account at a financial institution on behalf of the account holder
US7873572B2 (en) * 2004-02-26 2011-01-18 Reardon David C Financial transaction system with integrated electronic messaging, control of marketing data, and user defined charges for receiving messages
US8346660B2 (en) * 2004-02-26 2013-01-01 David C. Reardon System and method for two-way transfer of funds and electronic content between summa account users with gathering of behavioral metrics and management of multiple currencies and escrow accounts
US8799164B2 (en) 2004-02-26 2014-08-05 David C Reardon Financial transaction system with integrated electronic messaging, control of marketing data, and user defined charges for receiving messages
US20090119159A1 (en) * 2007-10-31 2009-05-07 David C. Reardon System and Method for Transferring Funds to Recipients of Electronic Messages
US7693776B2 (en) 2004-07-09 2010-04-06 Ebs Group Limited Automated trading systems
US8682757B2 (en) * 2004-08-25 2014-03-25 American Express Travel Related Services Company, Inc. Method and apparatus for processing financial transactions subject to different financing terms
US8407140B2 (en) * 2004-10-29 2013-03-26 Wells Fargo Bank, N.A. Global remittance platform
US8156029B2 (en) * 2005-02-24 2012-04-10 Michael Gregory Szydlo Process for verifiably communicating risk characteristics of an investment portfolio
US20070112662A1 (en) * 2005-11-12 2007-05-17 Prem Kumar Profiling the investment style of institutional investors
US20070118432A1 (en) * 2005-11-21 2007-05-24 Vijay Vazirani Systems and methods for optimizing revenue in search engine auctions
US7904356B1 (en) * 2006-01-10 2011-03-08 Intuit Inc. Icon based data management
US8892467B1 (en) * 2006-01-27 2014-11-18 Guardian Life Insurance Company Of America Interactive systems and methods for supporting financial planning related activities
WO2007139867A2 (en) * 2006-05-26 2007-12-06 Total System Services, Inc. Credit account management
WO2008036340A2 (en) * 2006-09-20 2008-03-27 Town North Bank, N.A. Financial institution leveraging and organization process
AU2007307688B2 (en) 2006-10-11 2011-06-23 Visa International Service Association Method and system for processing micropayment transactions
US10068220B2 (en) 2006-10-11 2018-09-04 Visa International Service Association Systems and methods for brokered authentication express seller links
US7886230B2 (en) * 2006-12-04 2011-02-08 Premark Feg L.L.C. Scale with automatic offline indication and related method
US8959516B2 (en) 2007-07-30 2015-02-17 International Business Machines Corporation Methods and systems for coordinated financial transactions in distributed and parallel environments
US8898669B2 (en) * 2007-07-30 2014-11-25 International Business Machines Corporation Methods and systems for coordinated transactions
US20080301046A1 (en) * 2007-08-10 2008-12-04 Christian John Martinez Methods and systems for making a payment and/or a donation via a network, such as the Internet, using a drag and drop user interface
KR20090022914A (en) * 2007-08-31 2009-03-04 삼성전자주식회사 Communication apparatus having information management function and method thereof
US7792748B1 (en) * 2007-09-19 2010-09-07 Capital One Financial Corporation Method and system for performing a financial transaction using a user interface
US20090076941A1 (en) * 2007-09-19 2009-03-19 Schneierson Daniel H Transaction Payment Instrument
US10402897B1 (en) * 2007-12-12 2019-09-03 Capital One Services, Llc Method and system for redirecting a financial transaction
US20090164346A1 (en) * 2007-12-19 2009-06-25 Reinhold Loevenich Fund Transfers Using Multiple Accounts
US10540712B2 (en) 2008-02-08 2020-01-21 The Pnc Financial Services Group, Inc. User interface with controller for selectively redistributing funds between accounts
US20090248574A1 (en) * 2008-03-28 2009-10-01 Leung Florence F L Peer-to-peer currency exchange and associated systems and methods
US8401938B1 (en) 2008-05-12 2013-03-19 The Pnc Financial Services Group, Inc. Transferring funds between parties' financial accounts
US8751385B1 (en) 2008-05-15 2014-06-10 The Pnc Financial Services Group, Inc. Financial email
US20090288012A1 (en) 2008-05-18 2009-11-19 Zetawire Inc. Secured Electronic Transaction System
US20090313166A1 (en) * 2008-06-13 2009-12-17 Mcnab Cornelius Method and system for facilitating fundraising via a communication network
US20100017413A1 (en) * 2008-07-17 2010-01-21 Ian Edward James Systems and methods for transferring value
US20100049643A1 (en) * 2008-08-19 2010-02-25 Bank Of America Online billpay memo data
US20100049642A1 (en) * 2008-08-19 2010-02-25 Bank Of America Online billpay attachments
US8447669B2 (en) 2008-08-26 2013-05-21 Visa U.S.A. Inc. System and method for implementing financial assistance programs
US8628008B1 (en) * 2008-10-16 2014-01-14 Wells Fargo Bank, N.A. System and method for card customization
US7827108B2 (en) * 2008-11-21 2010-11-02 Visa U.S.A. Inc. System and method of validating a relationship between a user and a user account at a financial institution
US8965798B1 (en) 2009-01-30 2015-02-24 The Pnc Financial Services Group, Inc. Requesting reimbursement for transactions
US10891037B1 (en) 2009-01-30 2021-01-12 The Pnc Financial Services Group, Inc. User interfaces and system including same
US8589269B1 (en) 2009-03-26 2013-11-19 Timothy B. Bendel System and method for funding companies
US8630931B2 (en) 2009-03-26 2014-01-14 Timothy B. Bendel System and method for funding companies
US10387140B2 (en) 2009-07-23 2019-08-20 S3G Technology Llc Modification of terminal and service provider machines using an update server machine
US8280788B2 (en) 2009-10-29 2012-10-02 Visa International Service Association Peer-to-peer and group financial management systems and methods
US8676639B2 (en) 2009-10-29 2014-03-18 Visa International Service Association System and method for promotion processing and authorization
US8121923B1 (en) 2010-03-11 2012-02-21 Ruccolo Michael A Automated fulfilling of currency exchange requests over a computer network
US8791949B1 (en) 2010-04-06 2014-07-29 The Pnc Financial Services Group, Inc. Investment management marketing tool
US8780115B1 (en) 2010-04-06 2014-07-15 The Pnc Financial Services Group, Inc. Investment management marketing tool
US8417614B1 (en) 2010-07-02 2013-04-09 The Pnc Financial Services Group, Inc. Investor personality tool
US11475523B1 (en) 2010-07-02 2022-10-18 The Pnc Financial Services Group, Inc. Investor retirement lifestyle planning tool
US8423444B1 (en) 2010-07-02 2013-04-16 The Pnc Financial Services Group, Inc. Investor personality tool
US11475524B1 (en) 2010-07-02 2022-10-18 The Pnc Financial Services Group, Inc. Investor retirement lifestyle planning tool
AU2011316955B2 (en) 2010-10-20 2016-12-01 Playspan Inc. Flexible monetization service apparatuses, methods and systems
WO2012097108A1 (en) * 2011-01-11 2012-07-19 Visa International Service Association Universal value exchange apparatuses, methods and systems
WO2012106655A2 (en) 2011-02-05 2012-08-09 Visa International Service Association Merchant-consumer bridging platform apparatuses, methods and systems
WO2012109628A2 (en) 2011-02-10 2012-08-16 Visa International Service Assocation Electronic coupon issuance and redemption apparatuses, methods and systems
US10586227B2 (en) 2011-02-16 2020-03-10 Visa International Service Association Snap mobile payment apparatuses, methods and systems
CN103765453B (en) 2011-02-16 2018-08-14 维萨国际服务协会 Snap mobile payment device, method and system
BR112013021057A2 (en) 2011-02-22 2020-11-10 Visa International Service Association universal electronic payment devices, methods and systems
US8374940B1 (en) 2011-02-28 2013-02-12 The Pnc Financial Services Group, Inc. Wealth allocation analysis tools
US9852470B1 (en) 2011-02-28 2017-12-26 The Pnc Financial Services Group, Inc. Time period analysis tools for wealth management transactions
US8321316B1 (en) 2011-02-28 2012-11-27 The Pnc Financial Services Group, Inc. Income analysis tools for wealth management
AU2012223415B2 (en) 2011-02-28 2017-05-18 Visa International Service Association Secure anonymous transaction apparatuses, methods and systems
US9665908B1 (en) 2011-02-28 2017-05-30 The Pnc Financial Services Group, Inc. Net worth analysis tools
WO2012122060A1 (en) 2011-03-04 2012-09-13 Visa International Service Association Cloud service facilitator apparatuses, methods and systems
US10733570B1 (en) 2011-04-19 2020-08-04 The Pnc Financial Services Group, Inc. Facilitating employee career development
US9646291B2 (en) 2011-05-11 2017-05-09 Visa International Service Association Electronic receipt manager apparatuses, methods and systems
CN103797500A (en) 2011-06-03 2014-05-14 维萨国际服务协会 Virtual wallet card selection apparatuses, methods and systems
US9582598B2 (en) 2011-07-05 2017-02-28 Visa International Service Association Hybrid applications utilizing distributed models and views apparatuses, methods and systems
US9355393B2 (en) 2011-08-18 2016-05-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US10121129B2 (en) 2011-07-05 2018-11-06 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
US10438176B2 (en) 2011-07-17 2019-10-08 Visa International Service Association Multiple merchant payment processor platform apparatuses, methods and systems
US10242358B2 (en) 2011-08-18 2019-03-26 Visa International Service Association Remote decoupled application persistent state apparatuses, methods and systems
US9710807B2 (en) 2011-08-18 2017-07-18 Visa International Service Association Third-party value added wallet features and interfaces apparatuses, methods and systems
US10318941B2 (en) 2011-12-13 2019-06-11 Visa International Service Association Payment platform interface widget generation apparatuses, methods and systems
US10825001B2 (en) 2011-08-18 2020-11-03 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US9117225B2 (en) 2011-09-16 2015-08-25 Visa International Service Association Apparatuses, methods and systems for transforming user infrastructure requests inputs to infrastructure design product and infrastructure allocation outputs
US10223730B2 (en) 2011-09-23 2019-03-05 Visa International Service Association E-wallet store injection search apparatuses, methods and systems
US9953378B2 (en) 2012-04-27 2018-04-24 Visa International Service Association Social checkout widget generation and integration apparatuses, methods and systems
WO2013090611A2 (en) 2011-12-13 2013-06-20 Visa International Service Association Dynamic widget generator apparatuses, methods and systems
US10223710B2 (en) 2013-01-04 2019-03-05 Visa International Service Association Wearable intelligent vision device apparatuses, methods and systems
US11308227B2 (en) 2012-01-09 2022-04-19 Visa International Service Association Secure dynamic page content and layouts apparatuses, methods and systems
US10262148B2 (en) 2012-01-09 2019-04-16 Visa International Service Association Secure dynamic page content and layouts apparatuses, methods and systems
US10169812B1 (en) 2012-01-20 2019-01-01 The Pnc Financial Services Group, Inc. Providing financial account information to users
AU2013214801B2 (en) 2012-02-02 2018-06-21 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems
US20150178840A1 (en) * 2012-04-11 2015-06-25 Integral Development Corp. Systems and related techniques for fairnetting and distribution of electronic trades
US20150127517A1 (en) * 2012-04-11 2015-05-07 Integral Development Corp. Methods and apparatus for facilitating fairnetting and distribution of currency trades
CA2819936C (en) * 2012-06-27 2020-12-29 Moneris Solutions Corporation Secure payment system
USD743432S1 (en) * 2013-03-05 2015-11-17 Yandex Europe Ag Graphical display device with vehicle navigator progress bar graphical user interface
CN103368790B (en) * 2013-06-21 2016-03-23 冯轶 A kind of performance delays monitoring method for electronic trading system and system thereof
US9443268B1 (en) 2013-08-16 2016-09-13 Consumerinfo.Com, Inc. Bill payment and reporting
US10325314B1 (en) 2013-11-15 2019-06-18 Consumerinfo.Com, Inc. Payment reporting systems
US20150149344A1 (en) * 2013-11-26 2015-05-28 International Business Machines Corporation Synchronous split payment transaction management
US9665721B2 (en) * 2014-04-23 2017-05-30 NSS Labs, Inc. Threat and defense evasion modeling system and method
US9525690B2 (en) * 2014-05-27 2016-12-20 Bank Of Ozarks Securely integrating third-party applications with banking systems
CN107077665A (en) * 2014-07-31 2017-08-18 环球有限责任公司 method and system for electronic transaction
JP1529316S (en) 2014-12-17 2015-07-21
USD767398S1 (en) 2014-12-18 2016-09-27 Hisamitsu Pharmaceutical Co., Ltd. Package
USD769121S1 (en) 2014-12-22 2016-10-18 Hisamitsu Pharmaceutical Co., Inc. Package
CN104537554B (en) * 2014-12-28 2018-02-13 武汉度马科技有限公司 It is a kind of to be used to realize the system and method that equipment is leased by stages
US11216468B2 (en) 2015-02-08 2022-01-04 Visa International Service Association Converged merchant processing apparatuses, methods and systems
US11023968B2 (en) * 2015-03-05 2021-06-01 Goldman Sachs & Co. LLC Systems and methods for updating a distributed ledger based on partial validations of transactions
JP1537113S (en) 2015-04-22 2015-11-02
USD775964S1 (en) 2015-04-22 2017-01-10 Hisamitsu Pharmaceutical Co., Inc. Packing box
US11176527B2 (en) * 2015-04-28 2021-11-16 Ncr Corporation Cross-network action approval
US20170018029A1 (en) * 2015-07-16 2017-01-19 Moneygram International, Inc. Systems and methods for utilizing a money transfer network to facilitate lending
JP6923946B2 (en) * 2015-12-21 2021-08-25 コチャバ インコーポレイテッドKochava Inc. Self-regulating trading systems, their methods, programs, data processing device systems, computer readable storage media systems, computer program products and computer program products
CN106952085B (en) * 2016-01-06 2021-06-25 创新先进技术有限公司 Method and device for data storage and service processing
US11295293B2 (en) * 2016-01-07 2022-04-05 Worldpay, Llc Point of interaction device emulation for payment transaction simulation
USD801185S1 (en) 2016-05-18 2017-10-31 Hisamitsu Pharmaceuticals Co., Inc. Packing box
BR112018076673B1 (en) * 2016-06-23 2022-07-19 Centurion Dk A/S SYSTEM TO FACILITATE REAL-TIME TRANSACTIONS
CN106131490A (en) * 2016-07-18 2016-11-16 四川君逸易视科技有限公司 Intelligent finance system based on intelligent video analysis technology
CN107767130A (en) * 2016-08-23 2018-03-06 中兴通讯股份有限公司 Pay system of selection and device
US10277488B2 (en) 2016-09-09 2019-04-30 International Business Machines Corporation System and method for management and recovery of multi-service web transactions
SG11201903337YA (en) * 2016-10-28 2019-05-30 Jpmorgan Chase Bank Na Application of distributed ledgers for network payments as financial exchange settlement and reconciliation
US10656792B2 (en) * 2016-11-11 2020-05-19 The Toronto-Dominion Bank Data-aggregation graphical user interfaces
US20210118054A1 (en) * 2016-12-01 2021-04-22 Trovata, Inc. Resource exchange system
GB2557237B (en) * 2016-12-01 2022-05-11 Crane Payment Innovations Ltd Method and apparatus for money item processing
US20210117889A1 (en) * 2016-12-01 2021-04-22 Trovata, Inc. Co-operative resource pooling system
US11907321B2 (en) 2019-10-18 2024-02-20 Trovata, Inc. Operator settings for natural language search and filtering on a web service platform for distributed server systems and clients
US10636087B1 (en) 2017-03-07 2020-04-28 Wells Fargo Bank, N.A. Customized graphical user interface for managing multiple user accounts
US20180276744A1 (en) * 2017-03-21 2018-09-27 Bank Of America Corporation Multicomputer Digital Data Processing to Provide Access and Process Control
CN107194810B (en) * 2017-05-15 2020-08-04 嘉实远见科技(北京)有限公司 Asset configuration system and method of operation
US10810546B2 (en) * 2017-10-02 2020-10-20 R3 Ltd. Settling obligations via netting transactions
JP7305627B2 (en) * 2017-10-04 2023-07-10 アルゴランド,インコーポレイテッド Declarative smart contract
US20210271681A1 (en) * 2017-10-05 2021-09-02 Baton Systems, Inc. Analysis of data streams consumed by high-throughput data ingestion and partitioned across permissioned database storage
US20190179681A1 (en) * 2017-12-12 2019-06-13 Atalaya Capital Management LP Systems and methods for providing an interactive map of an event driven funding path for affecting a directed event
US11182852B1 (en) * 2017-12-20 2021-11-23 Chicago Mercantile Exchange Inc. Exchange computing system including a reference rate generation unit
US10659217B2 (en) 2018-01-05 2020-05-19 Bank Of America Corporation Blockchain-based automated user matching
CN111771315A (en) * 2018-01-18 2020-10-13 伊顿智能动力有限公司 System and method for managing energy distribution using distributed ledgers
US20190244289A1 (en) * 2018-02-08 2019-08-08 2Bc Innovations, Llc Asset utilization optimization communication system and components thereof
CN108711043A (en) * 2018-05-22 2018-10-26 拉卡拉支付股份有限公司 A kind of fund keeps accounts method, apparatus, electronic equipment and computer-readable medium
CN109191110B (en) * 2018-07-27 2023-05-23 创新先进技术有限公司 Post-payment transaction data processing method, device, processing equipment and server
US10410190B1 (en) 2018-07-31 2019-09-10 Morgan Stanley Services Group Inc. Network of computing nodes and a method of operating the computing nodes to effectuate real-time bank account-to-bank account money transfer
US20200074541A1 (en) 2018-09-05 2020-03-05 Consumerinfo.Com, Inc. Generation of data structures based on categories of matched data items
CN112740242A (en) * 2018-09-24 2021-04-30 松下知识产权经营株式会社 Community definition space
CN109636586B (en) * 2018-11-29 2020-08-28 中国人民银行清算总中心 Distributed internet bank system and control method
US11132692B2 (en) 2019-03-08 2021-09-28 International Business Machines Corporation Shared voting for accounting
CN111754342A (en) * 2019-03-26 2020-10-09 众安信息技术服务有限公司 Method, system and device for obtaining block chain encrypted currency circulation speed
US11295334B2 (en) 2019-04-30 2022-04-05 Bank Of America Corporation Batch transaction multiplexing engine
CN110245928B (en) * 2019-05-29 2021-01-29 创新先进技术有限公司 Method, system and equipment for acquiring signing key element information of bank card
US11188980B1 (en) * 2019-06-17 2021-11-30 Wells Fargo Bank, N.A. Display and control of building purchase cash flow
US11042932B1 (en) * 2019-06-24 2021-06-22 Square, Inc. Intelligent use of surplus account funds
US11853921B2 (en) 2019-06-24 2023-12-26 Block, Inc. Predicting capital needs
CN110349001A (en) * 2019-06-29 2019-10-18 上海淇毓信息科技有限公司 Financial service comes operated control method, device and electronic equipment
CN110533532A (en) * 2019-07-17 2019-12-03 平安科技(深圳)有限公司 A kind of exchange method of calibration, device and the storage medium of finance data
CN110363619A (en) * 2019-08-06 2019-10-22 北京你财富计算机科技有限公司 A kind of autocontrol method of platform operation cycle of activity, device and system
EP3772718A1 (en) * 2019-08-08 2021-02-10 Vocalink Limited Data processing apparatus and method
US11315139B2 (en) 2019-09-13 2022-04-26 Capital One Services, Llc Systems and methods for overpayment handling
JP6689441B1 (en) * 2019-11-01 2020-04-28 エヌ・ティ・ティ・コミュニケーションズ株式会社 Electronic money management system and electronic money management method
CN111340546A (en) * 2020-02-25 2020-06-26 中信银行股份有限公司 Method, device, computer equipment and readable storage medium for improving marketing efficiency of banking business
CN111598692B (en) * 2020-04-30 2021-12-07 腾讯科技(深圳)有限公司 Electronic resource conversion method, electronic resource conversion device, computer equipment and storage medium
CN111600721B (en) * 2020-05-26 2023-06-16 牛津(海南)区块链研究院有限公司 Asset management system, method and device based on multi-person voting mechanism
US11625712B2 (en) * 2021-02-10 2023-04-11 Worldpay, Llc Systems and methods for executing electronic transactions and tokenizations with distributed settlement platform
US20230010678A1 (en) * 2021-07-07 2023-01-12 Affirm, Inc. Method and Apparatus for Facilitating Financial Transactions Backed by Crypto Assets
US20230133354A1 (en) * 2021-11-01 2023-05-04 American Express Travel Related Services Company, Inc. Predictive and customizable round up platform

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999057665A1 (en) * 1998-05-05 1999-11-11 The Clearing House Service Company L.L.C. System and method for intraday netting payment finality
US6023686A (en) * 1996-02-20 2000-02-08 Health Hero Network Method for conducting an on-line bidding session with bid pooling
EP1074928A2 (en) * 1999-07-30 2001-02-07 Crossmar, INC. Methods and systems for electronic order routing (Cors)
US6311170B1 (en) * 1996-12-04 2001-10-30 Mark C. Embrey Method and apparatus for making payments and delivering payment information

Family Cites Families (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3573747A (en) * 1969-02-24 1971-04-06 Institutional Networks Corp Instinet communication system for effectuating the sale or exchange of fungible properties between subscribers
US4774664A (en) * 1985-07-01 1988-09-27 Chrysler First Information Technologies Inc. Financial data processing system and method
US5644727A (en) * 1987-04-15 1997-07-01 Proprietary Financial Products, Inc. System for the operation and management of one or more financial accounts through the use of a digital communication and computation system for exchange, investment and borrowing
DE3833940A1 (en) * 1988-09-22 1990-04-05 Siemens Ag METHOD FOR RE-SYNCHRONIZING A SWITCH CENTER IN A TELECOMMUNICATION NETWORK
US5168446A (en) * 1989-05-23 1992-12-01 Telerate Systems Incorporated System for conducting and processing spot commodity transactions
AU656542B2 (en) 1990-10-01 1995-02-09 Thomas A. Bush Transactional processing system
US5504894A (en) * 1992-04-30 1996-04-02 International Business Machines Corporation Workload manager for achieving transaction class response time goals in a multiprocessing system
US5864679A (en) * 1993-09-06 1999-01-26 Kabushiki Kaisha Toshiba Transaction routing in a multiple processor system using an extracted transaction feature parameter and transaction historical data
JP3354667B2 (en) 1993-10-22 2002-12-09 株式会社エヌ・ティ・ティ・データ Communication method for giving transaction execution request to transaction processing system
US5704045A (en) 1995-01-09 1997-12-30 King; Douglas L. System and method of risk transfer and risk diversification including means to assure with assurance of timely payment and segregation of the interests of capital
US5703344A (en) * 1995-06-30 1997-12-30 Visa International Service Association Electronic funds confirmation at point of transaction
WO1997003408A1 (en) * 1995-07-07 1997-01-30 Ian Kenneth Shepherd Methods and apparatus relating to the formulation and trading of investment contracts
WO1997039415A2 (en) * 1996-04-12 1997-10-23 Citibank, N.A. Inside money
US6195647B1 (en) 1996-09-26 2001-02-27 The Nasdaq Stock Market, Inc. On-line transaction processing system for security trading
US5966699A (en) * 1996-10-11 1999-10-12 Zandi; Richard System and method for conducting loan auction over computer network
JP3413076B2 (en) 1997-03-18 2003-06-03 株式会社東芝 Central market system and electronic market system
US5940812A (en) * 1997-08-19 1999-08-17 Loanmarket Resources, L.L.C. Apparatus and method for automatically matching a best available loan to a potential borrower via global telecommunications network
US7742966B2 (en) * 1998-10-24 2010-06-22 Marketcore.Com, Inc. Efficient market for financial products
JP2000200377A (en) * 1999-01-07 2000-07-18 Sanyo Electric Co Ltd Device for depositing money in card
US6957191B1 (en) * 1999-02-05 2005-10-18 Babcock & Brown Lp Automated financial scenario modeling and analysis tool having an intelligent graphical user interface
NZ514263A (en) 1999-02-24 2003-05-30 Min Ho Cha Automatic purchasing and selling of stock based on user specified trading conditions
WO2001033522A1 (en) 1999-11-05 2001-05-10 American Express Travel Related Services Company, Inc. Systems and methods for facilitating commercial transactions between parties residing at remote locations
US20010032163A1 (en) * 1999-12-06 2001-10-18 Michael Fertik Method and apparatus for open market trading
US7376587B1 (en) * 2000-07-11 2008-05-20 Western Union Financial Services, Inc. Method for enabling transfer of funds through a computer network
US7395241B1 (en) * 2000-01-19 2008-07-01 Intuit Inc. Consumer-directed financial transfers using automated clearinghouse networks
JP2001216403A (en) * 2000-02-04 2001-08-10 Hiroshi Shirakawa Auction system and auction method
KR100297976B1 (en) * 2000-02-16 2001-11-03 정창희 System and method for issuing cyber payment means marked with business identification information and processsing transaction with the cyber payment means on the computer network
KR20000036545A (en) * 2000-03-21 2000-07-05 김종식 network based-foreign coin exchange system and method
US7599879B2 (en) 2000-03-24 2009-10-06 Jpmorgan Chase Bank, National Association Syndication loan administration and processing system
US20010037284A1 (en) * 2000-03-27 2001-11-01 Finkelstein Ephraim Brian Negotiated right exchange system and method
JP2001357210A (en) * 2000-04-03 2001-12-26 Masato Doujo Stock exchange system
JPWO2001084408A1 (en) * 2000-04-27 2004-01-08 インベストリア株式会社 Joint purchase method, joint purchase system, payment ability guarantee method and guarantee system
US20030069986A1 (en) * 2000-05-23 2003-04-10 Lori Petrone Electronic marketplace system and method using optimization techniques
JP2001357231A (en) * 2000-06-12 2001-12-26 Nec Corp Dealing mediating method, data processing method, trader terminal device, and information storage medium
JP2001357214A (en) 2000-06-12 2001-12-26 Ntt Comware Corp Method and system for remittance of virtual bank and recording medium with the same method programmed
JP2001357434A (en) 2000-06-16 2001-12-26 Oki Software Kk Transferring method, money inputting method and transaction device using the methods
US7024386B1 (en) * 2000-06-23 2006-04-04 Ebs Group Limited Credit handling in an anonymous trading system
JP2002007725A (en) 2000-06-26 2002-01-11 Suruga Bank Ltd Cooperative bank system with associated nonbank company in internet environment
JP2002024734A (en) 2000-07-04 2002-01-25 Super Line:Kk Amount offset facility using computer, amount offset method using computer, and amount offset device
US8452704B2 (en) * 2000-07-11 2013-05-28 Citicorp Credit Services, Inc. Method and system for on-line payments
US7249098B2 (en) * 2000-07-11 2007-07-24 First Data Corporation Subscription-based payment
EP1312012A4 (en) 2000-07-11 2006-09-06 First Data Corp Wide area network person-to-person payment
AU2001277877A1 (en) 2000-07-14 2002-01-30 American Management Systems, Inc. Digital loan application
WO2002006921A2 (en) * 2000-07-18 2002-01-24 Lerner Julie A System and method for physicals commodity trading
JP2002041798A (en) * 2000-07-28 2002-02-08 Nec Planning Research Ltd Stock dealing method
US7035820B2 (en) * 2000-08-10 2006-04-25 The Debt Exchange, Inc. Systems and methods for trading and originating financial products using a computer network
US20030046218A1 (en) * 2000-10-05 2003-03-06 Albanese Bernard J. System and method for protecting positions in volatile markets
US8285641B2 (en) * 2000-11-06 2012-10-09 Jpmorgan Chase Bank, N.A. System and method for selectable funding of electronic transactions
US20020055886A1 (en) * 2000-11-08 2002-05-09 Converge, Inc. System and method for maintaining and utilizing component cross reference data in an exchange system
US8234204B2 (en) * 2000-11-13 2012-07-31 Goldman, Sachs & Co. Method and system for matching short trading positions with long trading positions
US20020103660A1 (en) * 2000-11-30 2002-08-01 Kurt Cramon Generic transaction server
US6993507B2 (en) * 2000-12-14 2006-01-31 Pacific Payment Systems, Inc. Bar coded bill payment system and method
US20020111886A1 (en) * 2001-02-12 2002-08-15 Chenevich William L. Payment management
US6823340B1 (en) * 2001-03-30 2004-11-23 E2Open Llc Private collaborative planning in a many-to-many hub
US7610228B2 (en) * 2001-06-29 2009-10-27 International Business Machines Corporation Automated service level management in financial terms
US20030078850A1 (en) * 2001-09-05 2003-04-24 Eric Hartman Electronic marketplace system and method using a support vector machine

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023686A (en) * 1996-02-20 2000-02-08 Health Hero Network Method for conducting an on-line bidding session with bid pooling
US6311170B1 (en) * 1996-12-04 2001-10-30 Mark C. Embrey Method and apparatus for making payments and delivering payment information
WO1999057665A1 (en) * 1998-05-05 1999-11-11 The Clearing House Service Company L.L.C. System and method for intraday netting payment finality
EP1074928A2 (en) * 1999-07-30 2001-02-07 Crossmar, INC. Methods and systems for electronic order routing (Cors)

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
No Search *
See also references of WO03069444A2 *

Also Published As

Publication number Publication date
US20100145876A1 (en) 2010-06-10
US9830656B2 (en) 2017-11-28
KR20110114686A (en) 2011-10-19
AU2003219756A1 (en) 2003-09-04
US10643279B2 (en) 2020-05-05
AU2003219756B2 (en) 2010-03-11
KR20100114508A (en) 2010-10-25
JP5505897B2 (en) 2014-05-28
JP2013117982A (en) 2013-06-13
WO2003069444A3 (en) 2004-03-25
KR101194732B1 (en) 2012-10-25
JP2014059901A (en) 2014-04-03
MXPA04007821A (en) 2005-04-19
US20150193879A1 (en) 2015-07-09
US20200286174A1 (en) 2020-09-10
US20120259763A1 (en) 2012-10-11
KR101194730B1 (en) 2012-10-25
JP2009266235A (en) 2009-11-12
WO2003069444A2 (en) 2003-08-21
US8224744B2 (en) 2012-07-17
JP6294056B2 (en) 2018-03-14
BRPI0307674A2 (en) 2016-11-08
CN1647087A (en) 2005-07-27
EP2400453A1 (en) 2011-12-28
US7590595B2 (en) 2009-09-15
KR20040097128A (en) 2004-11-17
US9020851B2 (en) 2015-04-28
US20180068389A1 (en) 2018-03-08
WO2003069444A9 (en) 2004-06-03
KR101098356B1 (en) 2011-12-26
JP2005518011A (en) 2005-06-16
KR20110110366A (en) 2011-10-06
KR101123330B1 (en) 2012-03-23
JP2015228244A (en) 2015-12-17
US20030182230A1 (en) 2003-09-25
CA2476646A1 (en) 2003-08-21
CN102496107A (en) 2012-06-13
EP1483713A4 (en) 2005-04-06

Similar Documents

Publication Publication Date Title
US20200286174A1 (en) Apparatus and method of a distributed capital system
JP2005518011A5 (en)
Shahrokhi E‐finance: status, innovations, resources and future challenges
US20110166996A1 (en) Method of capturing interest on the value of transferred monetary rights managed on an internet-based monetary rights transfer network
JPH11501423A (en) Computer system for managing overdraft-protected client financial accounts
Ankenbrand A STRUCTURE FOR EVALUATING THE POTENTIAL OF BLOCKCHAIN USE CASES IN FINANCE.
JP5255984B2 (en) Exchange exchange margin trading system and foreign currency denominated settlement conversion method
Alfafa et al. Accounting issue in cryptocurrency investment: Islamic perspective
Scraping Scaled Agile Framework (SAFe)
US20120221426A1 (en) Marketplace auction system and method for purchasing meetings and events
권연아 et al. Paypal in the E-payment Industry
Alam et al. IT in Islamic Banks
Tiwari E-Banking in Commodity Market and its Opportunities and Threats
WO2007047824A2 (en) Contract system

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040920

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO

A4 Supplementary search report drawn up and despatched

Effective date: 20050218

17Q First examination report despatched

Effective date: 20090709

DAC Divisional application: reference to earlier application (deleted)
REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20170929