AU751645B3 - Action dependent commercial transaction system - Google Patents

Description

AUSTRALIA

Patents Act 1990 P/00/012 Regulation 3.2 Original Complete Specification Petty Patent Invention Title: ACTION DEPENDENT COMMERCIAL TRANSACTION SYSTEM The following statement is a full description of this invention, including the best method of performing known to me: ACTION DEPENDENT COMMERCIAL TRANSACTION SYSTEM The present invention relates to a commercial transaction system and, more particularly, to such a system suited for implementation across a network of computers of the type currently known as the Internet. More particularly it relates to such a system wherein the actions of users determine certain features of the system.

BACKGROUND

Accounting systems currently operate on the basis of duplication. In a typical commercial transaction one party can usually be categorized as a "buyer" and the other party to the transaction can usually be categorized as a "seller".

A commercial transaction typically will involve, initially, the placement of an order for the supply of goods or services followed by a bill or invoice which is supplied with the goods/services when they are supplied. The invoice is followed, according to credit terms, by payment or settlement of the transaction.

The buyer will monitor the fact that an order has been placed, will subsequently monitor the receipt of a bill or invoice and will ultimately record the payment or settlement of the transaction. Commonly this information will be stored by the buyer in a database in the form of an accounting package.

From the other side of the transaction the seller will record receipt of an order, will record its dispatch of a bill/invoice and will subsequently monitor and note receipt of payment/settlement. The seller will record this data in its database, which is also commonly of the form of an accounting package.

In theory the accounting package of the buyer will contain data in relation to the transaction which is a duplicate of the data contained in the accounting package of the seller for the same transaction. A checking arrangement in the form of a monthly statement or other summary of obligations incurred/payments received is often employed by both parties with a view to reconciling the data representing the transaction on the database of each party.

It can be observed that the duplication of record keeping thus described and which is characteristic of account record keeping employed by most organizations today is wasteful of resources, both human and computer.

Such systems tend to have relatively high costs per transaction recorded irrespective of the size or value of the transaction being recorded. Where the transaction involves, for example, micro payments (very small payments which can be on the order of fractions of a cent) the overhead of recording such transactions is disproportionately high.

It is an object of the present invention to overcome or ameliorate one or more of the abovementioned disadvantages.

BRIEF DESCRIPTION OF INVENTION Definitions In this specification "real time" refers to a system wherein interactions with the system by a user are perceived by the user to take effect instantaneously or within a very short time interval, typically in the 1-3 second range.

In this specification the term "persistent" refers to the characteristic of stored data to be retained in a consistent state representing data either before the start of a transaction or at the completion of a transaction and no other in between or indeterminate state.

In this specification "transaction" refers to an end result of a commercial interaction between at least a first and a second user. Where commodities are the subject of a commercial transaction the term "transaction" refers to a finalized or concluded trade in a specified commodity. In particular examples the commodities traded can be goods, services, shares, futures, commodities and the like.

28.Jun, 2002 23:01 Wallington Dummer I No.2372 P. 4 WALLINGTON DUMMER Transactions are stored according to ACID principles.

That is to say, the transaction has the characteristics of being atomic, consistent, isolated and durable (or persistent). In this instance each transaction is itself made up of a discrete number of steps, and each step itself is a transaction in itself.

Each transaction, in addition, has the characteristics of being secure, non-repudiatable, authenticated and persistent.

In this specification "definitive" in the context of a "definitive record" of a transaction describes a transaction which is agreed as legally binding and irrefutable by the users who are parties to that transaction. It would be expected that a "definitive record" would be sufficient evidence of a transaction to satisfy authorities such as tax authorities in the jurisdictions of interest in the transaction.

Accordingly, in one broad form of the invention there is provided a real-time transaction system to which a plurality of parties can subscribe; said system including a persistent store which contains a record of any given transaction between two or more of said parties; said record being a shared record between said two or more of said parties of said transaction; each of said parties being characterized by said system based on their role in said any given transctio.

A S. ECEIVED TIME 28. JUN. 22:58 PRINT TIME 29. JUN. 8:39 Preferably said record is a shared record of said transaction.

Preferably said shared record, by agreement of those of said parties who are subscribers to said system, is a definitive record of said transaction.

Preferably said transaction entails a purchase.

Preferably said transaction entails a sale.

Preferably said transaction comprises an ACID transaction.

Preferably each of said parties is characterized by a transaction.

Preferably a party is characterized as a buyer when the role of said party is as a buyer.

Preferably a party is characterized as a seller when the role of said party is as a seller.

Preferably said record is protected by a security regime.

Preferably said security regime is determined by a user of said system.

Preferably said security level is set by reference to the nature.of a connection established by an individual one of said parties for and only for a particular transaction.

Preferably said shared record can be accessed by each of said parties..

Preferably said party has access to only a part of said shared record.

Preferably said record to which a party has access is determined by the capacity in which said party acted in respect of data contained in said record.

In yet a further broad form of the invention there is provided a commercial transaction system to which a plurality of users can subscribe; said users agreeing to adopt a single common record as a definitive record of any given transaction between two or more of said users.

In yet a further broad form of the invention there is provided a real-time transaction system to which a plurality of parties can subscribe; said system including a persistent store which contains a single record of each and every transaction between two or more of said parties; said record being a shared record of said transaction.

Preferably said shared record, by agreement of those of said parties who are subscribers to said system, is a definitive record of said transaction between any said users so transacting.

Preferably said shared record can be accessed by each of said parties..

Preferably each said party has access to only a part of said shared record.

Preferably that part of said record to which a party has access is determined by the capacity in which said party acted in respect of data contained in said record.

Preferably each said transaction comprises a plurality of steps; said system integrating said plurality of steps.

Preferably said plurality of steps includes steps selected from deposit taking, ordering, billing and payment.

Preferably each step of said transaction comprises an ACID transaction.

Preferably each step of said transaction is Secure, Nonrepudiable, Authenticated and Persistent.

Preferably said parties conclude said steps of said transactions by interacting directly with said record of said transaction; and wherein said interacting does not require said parties to cause the transmission of data to other parties.

Preferably said transaction entails a purchase.

Preferably said transaction entails a sale.

Preferably the role of each of said parties in any given said transaction is determined by their action within said transaction.

Preferably said role of said party in any given said transaction is characterized as a buyer when said party acts as a buyer in said transaction.

Preferably said role of said party in any given said transaction is characterized as a seller when said party acts as a seller.

BRIEF DESCRIPTION OF DRAWINGS Embodiments of the present invention will now be described with reference to the accompanying drawings wherein: Fig. 1 is a block diagram of a commercial transaction system according to a first embodiment of the present invention; Fig. 2 is a block diagram of a commercial transaction system in accordance with a second preferred embodiment of the present invention; Fig. 3 is a block diagram of a form of implementation of the system of Fig. 2; Fig. 4 is a block diagram of a database implementation of the transaction record of the commercial transaction system of any one of Figs. i, 2 or 3; Fig, 5 is an interconnection diagram for the implementation of Fig. 4; Figs. 6A, 6B is a detailed interconnection diagram of an implementation based on the system of Fig. 4; Fig. 7 is a block diagram of an interaction between two users of the system of any one of Figs. 1 to 4; Fig. 8 is a block diagram of a unitary store structure which implements the persistent store of Fig. 7; Fig. 9 is a screen interface to the unitary store of Fig. 8; Fig. 10 is a screen interface of a customer statement summary for the system of Fig. 9; Fig. 11 is a vendor statement summary for the system of Fig. 9; Fig. 12 is a screen interface to a web shopping service for the system of Fig. 9; Fig. 13 is a block diagram of a commercial transaction system according to a further embodiment of the present invention wherein each step comprises an ACID transaction; Fig. 14 is a block diagram of the system of Fig. 13 and illustrating its relationship with a persistent store and deposit holders; Fig. 15 is a block diagram of the relationship between an account holder and a deposit holder with reference to the persistent store of Fig. 14; Fig. 16 is a flow diagram of a user defined levels of trust selection system; and Fig. 17 is a conceptual view of the system of Fig. 1.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS With reference, initially, to Fig. 1 there is illustrated a block diagram of a commercial transaction system 10 according to a first preferred embodiment of the present invention.

The system 10, in this instance, comprises a transaction record 11 which records information associated with a transaction 12 occurring between a first user 13 of the system 10 and a second user 14 of the system In this instance first user 13 is acting as a buyer/purchaser of goods/services in transaction 12. In this instance second user 14 is acting as a seller/vendor of goods/services in the transaction 12.

The transaction comprises the placement of an order by first user 13 on second user 14. At the time of supply of the goods/services (not shown) the second user 14 issues a bill or invoice 16 upon first user 13.

Subsequently first user 13 pays or settles invoice 16 by means of payment 17 in favour of second user 14.

Hence, transaction 12 is made up of order 15, bill 16 and payment 17 and, in this instance, information pertaining to order 15, bill 16 and payment 17 is recorded in transaction record 11.

It is to be understood that whilst the entire transaction is made up of steps 15, 16, 17, each of the steps comprising order 15, bill 16 and payment 17 is independent of any other of the steps 15, 16, 17 and are each stored independently in transaction record 11 in a persistent manner. In this instance each step 15, 16, 17 is also stored in ACID form.

Transaction record 11 is set up as a shared record to which both first user 13 and second user 14 have access.

In this instance, by the agreement of first user 13 and second user 14 as subscribers to commercial transaction system 10, the shared transaction record 11 is a definitive record of the transaction 12. The arrangement is such that there is no need from a commercial point of view for first user 13 or second user 14 to keep separate records of transaction 12.

Fig. 2 illustrates a second embodiment of a commercial transaction system In this instance, and as for the arrangement of Fig. 1, a transaction 22 between first user 23 and second user 24 comprises placement of an order 25 by first user 23 on second user 24 followed by the issue of an invoice 26 followed by payment 27 all of which are stored in transaction record 21.

In this instance payment 27 is effected by way of a funds source or pool 28 which is associated with and in electronic communication with transaction record 21.

With reference to Fig. 3 the pool 28 can take many forms including, in this instance, a debit facility 28A which can be subdivided by first user 23 into, for instance, one or more pools for account keeping purposed, and, similarly a second pool 28B in the form of a debit facility associated with second user 24. Like components of the system 20 are otherwise numbered as for the arrangement of Fig. 2.

As will be appreciated the systems thus far described, namely systems 10, 20 can be comprised of any number of users, hence the designation user 1 for first user 13, 23 and the designation user N for second user 14, 24 wherein N can be any integer value.

Fig. 4 is a block diagram of an implementation as a transaction record database or persistent store 30. The persistent store 30 can be implemented on a computer, for example a server computer (not shown) to which users may gain access via a computer network such as, for example, the international network of computers currently known as the Internet.

In this instance the commercial transaction system as described with reference to earlier embodiments, is implemented, in its most basic form as a plurality of software modules within persistent store 30. In this instance the persistent store 30 comprises a user account module 31 for a first user 32. The user 32 can access the user account module 31 by means of a connection 33 which may, for example, be implemented as a network connection via a personal computer 34 operated by user 32 and which is in communication via an Internet Service Provider (not shown) over the Internet to a'computer (not shown) which houses and runs software associated with transaction record persistent store 30 including user account module 31. In alternative forms connection 33 could be a direct dial up connection implemented over wire, radio, opto-electrical, satellite or other data communications link.

Associated with user account module 31 is statement account module Fig. 5 is a more detailed block diagram of the system of Fig. 4 and its manner of interaction with another user designated user N (or second user 24) together with a first pool 28A associated with first user 32 and together with a second pool 28B (designated pool N) also associated with first user 32.

In the instance of Fig. 5 first user 32 is connected via PC 34 to his/her user account 40 by means of a connection 41.

The arrangement is such that the connection can be associated with only one user account for the life of the connection.

The user account 40 is protected by a security policy 42, one example of an implementation of which is given elsewhere with reference to Fig. 16.

The user account 40 allows first user 32 to interact with at least one external account 43, first pool 28A, second pool 28B and to be associated with a first service 44 to which second user 24 subscribes.

Figs. 6A, 6B comprise an interconnected block diagram of the modules of a software implementation of the arrangement of Fig. 5 and wherein there is at least one external account 43 and wherein modules are otherwise numbered as for the components of Fig. 5 where specific modules correspond to the arrangements of Fig. With reference to Fig. 7 there is illustrated a block diagram of a simpler system implemented in accordance with the arrangement of Fig. 1 and wherein the transaction environment occurs within a unitary store, in this instance in the form of a persistent store The persistent store 50 is accessible to first user account 51 of first user 52 via first connection 53 and first personal computer 54 or other Internet or network access device.

The persistent store 50 is also accessible to second user account 55 operated by second user 56 via second connection 57 and second personal computer 58 (or other Internet or network access device).

The persistent store 50 comprises a single store of all transactions into which a commercial transaction system enters into according to a further embodiment of the invention.

In this instance a transaction M is made up of first step 61 comprising a subscription step; a second step 62 comprising a presentation step and a third step 63 comprising a settlement step. In this instance each step is itself an ACID transaction. In addition the data transfer comprising each step will have the following characteristics: 1. The transfer will be secure; 2. The information represented by the data cannot be repudiated; 3. The data transfer is authenticated; and 4. The data and each change to the data will be retained in a persistent manner within persistent store With reference to Fig. 8 the unitary store in the form of persistent store 50 contains the record of each and every transaction entered into by all users and account holders, in this instance represented by an example of three separate interactions and comprising, in this instance, first interaction 64 entailing a transfer of $80 between a user designated A and a user designated B; a second interaction comprising the transfer of $200 from a user C to a user D; and a third interaction 66 comprising a transfer of $280 from user A to user D.

All of these interactions are stored in the unitary store comprising persistent store 50. However, access to the data comprising the interactions is restricted by filter means 67 by which any given user having access to the system is allowed to "see" only that data or portions of data to which they are entitled, for example by virtue of being a party to the relevant transaction.

So, in this instance, user A can "see" data relating to first interaction 64 and data relating to third interaction 66 because user A was a party to both of these interactions.

User B can "see" only first interaction 64 because user B was a party only to this interaction. Similar filtering occurs, as illustrated for users C and D.

Figs. 9 to 12 illustrate screen images of an Internet based implementation of the system of Fig. 7 wherein user 1 has user name "Smith" and user N has a user name "Paulash".

In this instance user 1 has access to two pools, the first one entitled "default" and the second entitled "expenses".

In this instance components are numbered where they correspond with the components of Fig. 5 but otherwise utilizing the persistent store 50 of Figs. 7 and 8.

Accounts can be segregated into "pools" and other accounting practices can be applied.

Fig. 9 shows the details from persistent store 50 to which first user 32 (user name "Smith") has access to as user A. User B entitled, in this instance, "Paulash" will have access to some of the data contained in this listing by virtue of his also being a party to at least some of the actions reflected in the history of all actions listed in Fig. 9.

Fig. 10 provides a listing of customer statements. Fig.

11 provides a listing of vendor statements. Fig. 12 illustrates a manner of interaction with vendor "Thirishop" via a browser page interaction over the Internet.

Transaction Guarantor With reference to Figs. 13, 14 and 15 a commercial transaction system 70 according to a further embodiment of the invention will now be described wherein the supporting financial intermediaries or institutions are introduced for the purpose of securing, holding and guaranteeing the sufficiency of funds for at least some transactions in which account holders/users enter into. In some jurisdictions such intermediaries are known as approved deposit-taking institutions (APIs) or deposit takers. Frequently such institutions or intermediaries are banks having the appropriate authority to hold funds on behalf of clients and clear such funds through other like-authorised intermediaries including, where necessary, appropriate Government authorities such as central banks and the like. In the description of the embodiment which follows the intermediary is termed a "deposit taker". It will be noted that the deposit takers are no longer central or an intermediary to the transaction between a buyer and a seller but, instead, adopt a parallel or observation role.

With particular reference to Fig. 14 the commercial transaction system 70 comprises a unitary store designated as and agreed by all users as the definitive record of all transactions conducted through the system 70, in this instance comprising persistent store 71.

In this instance a first account holder 72 acts in the capacity of a buyer whilst a second account holder 73 acts in the capacity of a seller. It is to be understood that any given account holder 72, 73 at any given time may act as either a buyer or a seller and they are only characterized as such according to the nature of their role in the transaction they enter into.

In this embodiment, should for example, account holder 72 initiate a buy transaction from account holder 73 then, with particular reference to Fig. 13, three distinct and separate groups of information will pass between account holder 72 and account holder 73 by way of persistent store 71. Again, it should be understood that information in the form of data does not flow contiguously from one account holder to another. The characteristic of the present system utilising persistent store 71 is that the first information grouping comprising subscription step 74 is implemented as causing information relating to a subscription transaction to be set in persistent store 71. Account holder 73, being the intended recipient of the subscription information, is thereby given access to the information in the persistent store 71 pertaining to the subscription.

Having confirmed the subscription information at subscription step 74 residing in persistent store 71, account holder 73 may then respond to the existence of the information in system store 71 by entering into a presentation step 75 thereby accepting the subscription 74.

Again, the presentation step 75 involves account holder 73, in its current capacity as seller, causing information to appear in persistent store 71 corresponding to an affirming presentation step 75. The account holder 73, in its current capacity as a buyer, will have access to that information in persistent store 71 and can ultimately affirm that presentation step 75 by entering into a settlement step 76.

Each of the steps 74, 75, 76 comprises an ACID step.

Together they constitute a completed transaction between account holder 72 acting as a buyer and account holder 73 acting as a seller. The entire record of the completed transaction resides in persistent store 71 as an agreed definitive record of the steps 74, 75, 76 with the result that there is no necessity for either account holder 72 or account holder 73 to retain a separate record elsewhere.

In practice, and with reference to Fig. 14, where a transaction or series of transactions involves the transfer of currency from one account holder to another it will frequently be the case that each account holder will have at its disposal a financial institution acting as a holder of funds and otherwise frequently acting, in effect, as a guarantor of ability to settle fund amounts up to a predetermined sum. In this instance account holder 72 retains deposit holder 77 in this. capacity whilst account holder 73 retains deposit taker 74 in a corresponding capacity. As will be observed from Fig. 14 the transaction represented by the steps 74, 75, 76 of Fig. 13 proceeds between account holder 72 and account holder 73 effectively independent of the existence of deposit takers 77, 78 with both account holders being bound by the record contained in persistent store 71. However, in this instance commercial transaction system 70 makes available relevant information within persistent store 71 relevant to the transaction of Fig. 13 to the respective deposit takers 77, 78 whereby, as appropriate, they can update their respective records.

Fig. 15 illustrates the access that deposit takers 77, 78 have to those portions of the record contained in persistent store 71 relating to the transaction and relevant to its capacity as guarantor in respect of funds available to account holder 72. A corresponding arrangement applies in respect of account holder 73 and deposit holder 78 and also using the same data record contained in persistent store 71.

With reference to Fig. 9 certain kinds of transactions involving payment of moneys between parties can be tagged by tag 81 whereby the paying party has the value of a particular transaction effectively placed in escrow because the transaction has already been recorded in favour of the party to whom the money is to be paid. For example pending fulfillment by, for instance, a third party approved by the other two parties.

Transaction Security Elements of security such as required for security policy 42 in respect of Fig. 5 will now be described with reference to Fig. 16.

On initiation of a link with a user as set out in Step A the system can initially query the user as in Step B for answers to trust test criteria as outlined in Step C, in this instance chosen from one or more of: i. Computer ID ii. Password and length of password iii. Physiological ID Following identification of the trust test criteria that the user wishes to elect the system then prompts for a transaction threshold value to be applied to that level of trust test criteria, in this instance, as outlined in Step D, selected from a choice of: i. $100 ii. $500 iii. $1000 iv. other specify In this manner a user is made responsible for selecting trust test criteria and the transaction threshold values to which those particular trust test criteria will apply.

In more complex arrangements the user can specify different trust test criteria for different transaction threshold values or other actions.

This user defined levels of trust arrangement is in keeping with the nature of the transaction system described in previous embodiments wherein a flow-on consequence of users of the system accepting a single shared record as an agreed record of relevant transactions is that responsibility for those transactions resides squarely with the users. That is, once a transaction is entered into, the user is bound by the common record and has no recourse to a third party to step in and vary or set aside the transaction.

With reference to Fig. 17 the system of Fig. 1 is illustrated as a conceptual view.

In this instance a transaction is composed of an order or buy step 80 followed by a bill step 81 followed by a pay step 82. The buy step 80 is initiated by a user or party acting in the capacity of a buyer. The bill step .81 is activated or initiated by a user or party acting in the capacity of a seller as a response to the buying step. The entire transaction 83 comprising steps 80, 81, 82 must happen in serial fashion.. This is illustrated conceptually by bar 84 which must pass through order slot 80A, then bill slot 81A followed by pay slot 82A for transaction 83 to be completed.

For each step 80, 81, 82 to be completed a rotation of the relevant step component must take place (signifying completion of the step) in order to align the slot of that step with the slot of the next step so that bar 84 may pass through to the next step.

In this arrangement the later steps cannot take place until the previous step has been completed.

In a typical transaction a user will log on according to current security level. The user then creates and customizes a new level of security according to criteria set by that user. The user then applies that level of security to one or more activities including but not limited to authorizing transactions of specific levels of value.

The system allows the integration of deposit taking, order subscription, bill presentment, payment settlement, order fulfillment and accounting into a single, open participation system.

Any financial institution can participate as a deposit taker provided they have jurisdictional authority and agree to appropriate terms and conditions.

Any entity can participate as a buyer provided they agree to the appropriate terms and conditions. Any entity can participate as a seller.

It is possible for an entity to participate simultaneously as a buyer and as a seller.

Transactions are conducted not by transmission, but by updating the relevant portion of a single shared record.

It is to be emphasized that the system is designed to engender trust. Hence, a buyer always initiates a sale by making an order. A seller can only respond. A seller cannot initiate a transaction. The seller is empowered only to offer a commodity such as a product or service.

Summary Some characteristics of the system according to one or more of the previously described embodiments include the following: i. The system includes user defined levels of trust.

ii. All actions on money within the system are implemented as transfers. It follows, in this instance, that there is only one transfer model for transfers.

iii. Money or other commodity is preserved during each and every transfer.

iv. Access to the shared record of a transaction is selective according to inter alia, the capacity in which a given party is involved in any given transaction.

Disintermediation v. Third parties such as financial institutions, whilst, in some embodiments, performing an important function in terms of guarantee of funds, are, nonetheless, not directly in the link between a first user and a second user of the system.

Third parties such as financial institutions effectively adopt an observing or auditing role rather than being directly involved in a serial link between a first user and a second user. It follows that, in at least some embodiments, a transaction, for example, can be settled instantaneously rather than in the case (e.g.

cheque transaction) where a bank or other financial institution is involved and through which clearing must take place resulting, typically in overnight delays in recording and/or settling such transactions. In this role, the financial institution or bank is not involved in intermediation.

The financial institution agrees to be bound by the transaction but acts as an observer merely receives updates on the account situation.

Example 1 A commercial transaction system in accordance with one or more of the previously described embodiments will now be described with reference to the appendices wherein the exemplary system is entitled the "Thiri Internet Payment System" or "TIPS" for short.

Appendix A is entitled "UML Use Cases for Core System Functionality of the Thiri Internet Payment System".

Appendix B is entitled "Core Requirements for TIPS" and comprises a specification in respect of which the system of Appendix A complies.

The above describes only some embodiments of the present invention and modifications, obvious to those skilled in the art, can be made thereto without departing from the scope and spirit of the present invention.

EDITORIAL NOTE NO.48003/01 The following pages contain Appendix A (1-13) and Appendix B (1-37).

The claims are to follow.

APPENDIX

A

Thom Larner Page 1 Thor Lamr Pae 117 August, 2000 UMVL Use Cases for Core System Functionality of the Thiri Internet Payment System (TIPS) Initial version C:\WINDOWS\TEMP\Use Cases for Core System Functionality.doc Thom Larner Page 2 17 August, 2000 Document Amendment History Version Date Notes Initial 2 6 "t May, 2000 Initial Version created 3r July, 2000 Updated to reflect changed in requirements C:\WINDOWS\TEMP\Use Cases for Core System Functionality.doc Thorn Lamner Page 3 17 August, 2000 Table of Contents: 1 PURPOSE OF THIS DOCUMENT 4 2 LOG ONTO TIPS/AUTHENTICATE A 3 AUTHORIZE A TRANSFER TO A 6 4 MOVE FUNDS INTO 9 MOVE FUNDS OUT OF 6 TRANSFER MONEY BETWEEN POOLS 11 7 CREATE A 12 C:\WINDOWS\TEMP\Use Cases for Core System Functionality.doc Thorn Larner Page 4 17 August, 2000 1 Purpose of this Document The purpose of this document is to provide UML style Use Cases for each of the scenarios that comprise the core functional requirements of TIPS.

Many features are deliberately left out of this document because they are not considered to be part of the first release. Such features include: 1. Creation/Deletion of a User Account.

2. Specifying authentication measures other than the usual username/password pair.

3. Changing the currency that represents the balance of a Pool.

4. Specifying security policies on User Accounts and Pools.

Specifying rules for payment of statements.

These features will be incorporated into future releases of TIPS.

The main features to be included in the first release of TIPS are: 1. Logging onto TIPS.

2. Authorizing payment of a statement from a vendor.

3. Moving funds into and out of TIPS.

4. Creating a new Pool.

Transferring funds between Pools.

C:\WINDOWS\TEMP\USe Cases for Core System Functionality.doc Thom Larner Page 5 17 August, 2000 2 Log onto TIPS/Authenticate a User ("___Supply Authentication Material Registe ed User Authenticate User Establish Level of Confidence Authenti tion System Notes: The User will supply some authentication material to TIPS, such as a name/password pair, a smartcard/PIN pair, or something similar. TIPS will then authorize the User to establish a connection to their User Account.

A level of confidence for the session will be established, and may be subject to security restrictions that the user has placed on their own User Account. For example, if the User simply supplies a username/password pair, the User may be restricted in the amount they may spend without supplying additional authentication material, such as a smart-card/pin pair.

C:\WINDOWS\TEMP\Use Cases for Core System Functionality.doc Thom Larner Page 6 17 August, 2000 3 Authorize a Transfer to a Vendor Update Accounts Account System Notes: This Use Case is divided into three scenarios.

The first scenario depicts the situation where the purchaser has not previously authorized the vendor to issue a Statement to them. In this case, the following steps are followed: 1. The user acting as the purchaser requests a Statement from the user acting as the vendor.

2. The vendor issues a Statement with the appropriate Transactions on it to the purchaser, who immediately receives the Statement.

3. The purchaser manually authorizes payment of the Statement, and the vendor immediately receives the funds.

C:\WINDOWS\TEMP\Use Cases for Core System Functionality.doc Thornm Larner Page 7 17 August, 2000 SMove Funds Into Pool Authorize Transfer Move Funds Purchaser Between Pools 0 /Add Transactions to Statementstem 7"Receive Update Accounts System Notes: The second scenario depicts the situation where the purchaser has previously received a Statement from the vendor (Statements are never deleted), but has not authorized payments to be made automatically. In this scenario, the following steps must be performed: 1. The vendor must add the appropriate Transactions to the previously existing Statement.

2. The user must manually authorize payment of the new Transactions (outstanding balance on the Statement). The vendor will immediately receive the funds.

Note that the above scenario (and the next one) allows for the situation where aggregated payments are required. The vendor may add many Transactions to the Statement before the purchaser authorizes payment.

For example, a user logs onto a newspaper web-site, and agrees to pay $0.10AUD for each article that she chooses to read. If this is the first time the user has received a Statement from the newspaper, then a new Statement will be created when the newspaper charges the first Transaction of $0.1OAUD to the user. If the user already has a Statement from the newspaper from prior visits, then Transactions are simply appended to the existing Statement. The Transactions continue to be charged to the user whilst they read their selected newspaper articles. At the end of the session, or week, or month, the user may authorize payment of the unpaid Transactions listed on the Statement from the newspaper. The unpaid Transactions will appear as an outstanding balance, just like on a normal paper bill. Full payment will reduce the outstanding balance to $O.OOAUD.

This scheme will work for any amount of money, including amounts less than $0.01.

C:\WINDOWS\TEMP\Use Cases for Core System Functionality.doc Thom Lamner Page 8 17 August, 2000 Accounts System Notes: This scenario depicts the situation where the purchaser has authorized the vendor to issue a Statement to them, and has also authorized automatic payment of the Statement. In this scenario, only one step must be performed: 1. The vendor must add the appropriate Transactions to the previously existing Statement. At this point, the payment of the new Transactions is automatically and immediately approved and the vendor will immediately receive the funds.

C:\WINDOWS\TEMP\Use Cases for Core System Functionality.doc Thom Lamer Page 9 17 August, 2000 4 Move Funds into TIPS Request Transfer From External Account Registe ed User Supply Funds: xternal Account Update Accounts Account System Notes: The source of funds is one external account nominated by the user. The user may not transfer funds from any account they have not already nominated (with the possible exception of credit cards).

TIPS should use existing protocols and conventions for connecting to the external account and performing the transfer.

C:\WINDOWS\TEMP\Use Cases for Core System Functionality.doc Thom Larner Page 10 17 August, 2000 Move Funds out of TIPS Request Transfer To External Account Registe ed User Receive Funds xternal Account Update Accounts Accouystem System Notes: This Use Case is very similar to the previous Use Case ("Transfer Funds Into TIPS"). This Use Case is essentially the reverse process.

C:\WINDOWS\TEMP\Use Cases for Core System Functionality.doc Thom Larner Page 11 17 August, 2000 6 Transfer Money Between Pools "Request Transfer Between Pools Registe ed User Update Accounts Account System Notes: Users may transfer money between Pools as they require.

This kind of transfer does not follow the previous transfer model given because it would unnecessarily complicate the situation.

The user must not be able to transfer funds to a Pool that does not belong to them, or one that they have already deleted.

C:\WINDOWS\TEMP\Use Cases for Core System Functionality.doc Thorn Lamer Page 12 17 August, 2000 7 Create a Pool Request New Pool Creation Registe ed User Create Pool Account System Notes: Users shall be able to create Pools associated with their User Account.

Users may create as many Pools as they like.

C:\WINDOWS\TEMP\Use Cases for Core System Functionality.doc Thom Larner Page 13 Thor Lamr Pae 1317 August, 2000 C:\WINDOWS\TEMP\Use Cases for Core System Functional itydoc APPENDIX

B

Thom Larner Page 1 Thor Lamr Pae 117 August, 2000 Core Requirements for

TIPS

Initial version C:\WINDOWS\TEMP\Core Requirements Specification.doc Thornm Larner Page 2 17 August, 2000 Document Amendment History Version Date Notes Initial 30' n May, 2000 Initial Version created t n July, 2000 Revised after several design sessions altered requirements.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thorn Larner Pg 7Ags,20 Page 3 17 August, 2000 Table-of Contents: 1 OVERVIEW OF CORE SYSTEM FUNCTIONALITY 2 IMPLEMENTATION PRINCIPLES 6 3 CORE FUNCTIONAL 7 3.1 ACCOUNTS 7 3.1.1 Create a User 7 3.1.1.1 TIPS Must Establish at Least Lowest Level of Confidence in 7 3.1.1.2 Notification of the User Account Creation Process Outcome 7 3.1.2 Destroy a User Account 8 3.1.2.1 TIPS Must Maintain Records of all Destroyed User Accounts 8 3.1.3 Link an External Account to a User Account 9 3.1.3.1 Notification of Linking Process Outcome 9 3.1.4 Each User Account Must Have at Least One External 3. 1.5 Users may Specify Security Policies for their User 11 3.1.5.1 Security Policies may be 11 3.1.6 Level of Confidence 12 3.1.6.1 Minimum Level of 12 3.1.6.2 Highest Level of Confidence has Administrative User 12 3.1.7 Administrative User 13 3.2 14 3.2.1 Create aService 14 3.2.1.1 Notification of the Service Creation Process 14 3.2.2 Destroy a Service 3.2.3 A User May Specify Payment Options for a Service 16 3.2.4 A User May Subscribe to a Service Offered by Another 17 3.2.5 Each User Has A Default Service 18 3.2.5.1 The Default Service May be Modified 18 3.2.5.2 The Default Service May Not be 18 3.3 POOLS 19 3.3.1 Create a Pool 19 3.3.1.1 Notification of the Pool Creation Process Outcome 19 3.3.1.2 Users May Own Multiple Pools 19 3.3.1.3 Users May Own Zero Pools 19 3.3.2 Destroy a Pool 3.3.3 Pools Must Contain Only One Kind of 21 3.3.3.1 Different Pools May Have Different Security Policies 22 3.3.3.2 There Must be a Default Security Policy 22 3.3.3.3 Security Policies may be 22 3.4 23 3.4.1 All Transfers Within the System Shall Follow the Same 23 3.4.2 Transfers Must Preserve ACID Properties 24 3.4.3 Money is Preserved During all Transfers 3.4.4 Users Must be Notified of Transfer Success or Failure 26 3.4.5 Transfers Shall Appear Transparent to Users Errorl Bookmark not defined.

3.4.6 Users May Automate Statement Payment Approval by Source of Statement 29 3.4.7 Users May Transfer Funds Between Their Own Pools 3.4.8 Users May Transfer Funds to Their User Account From an External Account 31 3.4.9 Users May Transfer Funds out of the System to an External 32 3.4.10 Users May Transfer Funds From One Currency to Another I...33 3.4.10.1 Current Exchange Rates must be Visible During Currency 33 EXTERNAL ENTITIES 34 C:\WIN DOWS\TEMP\Core Requirements Specification. .doc Thom Larner Page 4 17 August, 2000 3.5.1 TIPS Shall Allow External 34 3.5.2 Connections are Associated with a User 3.5.3 Connections Cannot Change User Account Association 36 3.5.4 Operations are Limited to a Particular User Account 37 C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Larner Page 5 17 August, 2000 1 Overview of Core System Functionality This section briefly describes the functionality that is considered to be "core" for TIPS.

1. User Accounts -are the fundamental unit in the system. All Transactions is TIPS are associated with two User Accounts (payer and payee).

A User Account is owned by one User. That User may define rules which allow other TIPS Users to access their User Account.

An internal account is an account created and owned by TIPS. An external account is an account created and owned by another system.

A User Account has a jurisdiction, which directly affects the actions that may be performed on that User Account.

2. Services Services are offered from User Accounts. A User can subscribe to a Service offered by another User. Normally, a buyer will subscribe to a service offered by a seller. Services specify payment options. When a User subscribes to a Service, they are really requesting (or authorizing) the User offering the Service to send them one or more charges.

3. Pools a Pool is a balance of funds in some currency. A Pool is owned a User Account. Users may create and destroy Pools associated with their User Account.

4. Users are entities that carry out actions within TIPS. A User may be either human or computer.

Transfers a transfer is a movement of money from one User's Pool to another User's Pool. Money may be transferred between User Pools, or between User Accounts and external accounts (such as bank accounts, credit cards, etc.).

6. Money money is held in User Accounts and Pools. Money is used for transfers.

Money is always preserved during transfers.

7. External Entities TIPS must be able to communicate with external entities such as bank systems, other applications, vendor systems, etc.

All other aspects are considered to be external to the system. This approach is more fully explained in the next section "Implementation Principles".

External factors are factors which are deemed to not affect the core operation of TIPS. The most important external factors are: 1. Authentication recognizing Users and granting them specific privileges.

2. User views what the User is presented with when they wish to view their User Account.

3. Interest Rewards payments made to Users of TIPS.

4. Taxes Fees different jurisdictions will apply different taxes and fees.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Larner Page 6 17 August, 2000 Periodic Payments periodically sending a Statement to a User Account.

6. Delivery of Goods.

7. Repayments and Adjustments for example, refunds.

2 Implementation Principles This section describes some of the guiding principles to be used when designing and implementing TIPS.

1. The core of TIPS will rarely change. Wherever possible, rules should be expressed as data rather than code.

2. All actions on money within the system are implemented as transfers. There will only be one model for transfers in order to simplify the transaction engine.

3. All User Accounts and Users are "equal". There is no internal notion of "vendor" or "purchaser". This allows greater flexibility with User Accounts.

4. Exact details of transfers (such as which machine the different accounts are kept on) are to be hidden from the accounts involved. That is, during a transfer, a User does not have to name the machine on which machine the recipient of the invoice holds their account.

User Account and Pool details are to be hidden from all parties involved in a transfer. This is to protect Users from receiving unwanted Statements on their User Account.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Larner Page 7 17 August, 2000 3 Core Functional Requirements This section details the functional requirements of the core of TIPS.

3.1 Accounts 3.1.1 Create a User Account TIPS shall allow a new User to request the creation of a User Account 3.1.1.1 TIPS Must Establish at Least Lowest Level of Confidence in Applicant The applicant shall supply sufficient authentication material such that TIPS may establish at least the lowest level of confidence in the new User.

If the User cannot supply such material, then the User Account creation process shall fail.

The User shall also supply information about an external account that can be used to obtain an opening balance for the User. This is to satisfy requirement 3.1.4.

3.1.1.2 Notification of the User Account Creation Process Outcome The User must receive notification of the success or otherwise of the User Account creation process.

If the account creation process fails, the User should be given a reason.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thorn Lamer Page 8 17 August, 2000 3.1.2 Destroy a User Account Registered Users may destroy their own User Account.

Users may not destroy any other User Account except their own.

The User Account must have a zero balance in order for it to be destroyed.

3.1.2.1 TIPS Must Maintain Records of all Destroyed User Accounts TIPS must maintain a record of the User Account and all transactions on that User Account.

User Account data must never be lost by TIPS.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Larner Page 9 17 August, 2000 3.1.3 Link an External Account to a User Account Registered Users shall be able to request that an external User Account be linked to their User Account.

The User shall supply the details of the external account, and provide TIPS with appropriate authority to withdraw from and deposit to the external account.

3.1.3.1 Notification of Linking Process Outcome The User shall receive notification of the success or otherwise of the linking process. If the linking process fails, then the User should be given a reason.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Lamer Page 10 17 August, 2000 3.1.4 Each User Account Must Have at Least One External Account At all times, every User Account must be linked to at least one external account. It is an error for a User Account to be linked to zero external accounts.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thornm Larner Page 11 17 August, 2000 3.1.5 Users may Specify Security Policies for their User Account TIPS shall allow Users to specify a set of security restrictions that apply to their User Account, known as a security policy. For example, a User may wish to specify that any entity logged in using their identity does not have permission to authorize a transfer over the amount of unless they are logged in from a particular machine (probably the User's home machine), or provide a certain level of authentication.

TIPS shall provide a flexible scheme for specifying security policies.

3.1.5.1 Security Policies may be Overridden TIPS shall, by default, allow Users to override these security policies via extra authentication measures. This is to prevent legitimate User lock-out.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thor Larner Page 12 17 August, 2000 3.1.6 Level of Confidence TIPS shall establish a level of confidence in each User. The level of confidence indicates the extent to which TIPS believes that an entity logged on with that identity is a legitimate User.

A User may adjust the level of confidence TIPS assigns them on a per-session basis by providing extra authentication materials (eg. smart cards, answering personal questions, biometrics, etc.).

A User may adjust their level of confidence by supplying extra authentication material to TIPS.

3.1.6.1 Minimum Level of Confidence TIPS shall define a minimum level of confidence, which is the same level of confidence required to create a User Account. Any new User must supply authentication material to provide at least this level of confidence (see requirement 3.1.1) 3.1.6.2 Highest Level of Confidence has Administrative User Privileges The highest level of trust shall correspond to a "super User" who has permissions to make changes to TIPS by adjusting system parameters.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Larner Page 13 17 August, 2000 3.1.7 Administrative User Account At all times within TIPS there shall be at least one User Account that has super-User privileges.

Multiple administrative User Accounts may exist.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thornm Larner Page 14 17 August, 2000 3.2 Services 3.2.1 Create a Service TIPS shall allow Users to request the creation of a Service to be associated with their User Account.

The User must be notified of the success or otherwise of the Service creation process.

3.2.1.1 Notification of the Service Creation Process Outcome The User must receive notification of the success or otherwise of the Service creation process.

If the Service process fails, the User should be given a reason.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Larner Page 15 17 August, 2000 3.2.2 Destroy a Service A User may destroy a Service that is associated with their User Account.

Users may only destroy Services associated with their User Account. It is an error to allow a User to delete any other Service.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thorn Larner Page 16 17 August, 2000 3.2.3 A User May Specify Payment Options for a Service A User shall be able to modify a Service associated with their User Account to specify particular payment options.

TIPS shall provide the User with a flexible means of specifying payment options. Such options shall include whether or not the User will allow other Users to subscribe to the service in an anonymous fashion.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thornm Larner Page 17 17 August, 2000 3.2.4 A User May Subscribe to a Service Offered by Another User Any User may subscribe to a Service offered by another User. This will allow the subscribing User to Transfer money to the User offering the Service.

3.2.4.1 A User May Subscribe to a Service Anonymously TIPS shall allow Users to subscribe to a Service anonymously, i.e. with none of their details being exposed to the User offering the Service.

3.2.4.2 Users May Disallow Anonymous Service Subscriptions A User may elect to refuse to allow other Users to subscribe to one of their Services anonymously.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thornm Larner Page 18 17 August, 2000 3.2.5 Each User Has A Default Service Each User Account offers a default Service.

3.2.5.1 The Default Service May be Modified The User may modify the default Service associated with their User Account.

3.2.5.2 The Default Service May Not be Deleted The User may not delete the default Service associated with their User Account.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Lamer Page 19 17 August, 2000 3.3 Pools 3.3.1 Create a Pool TIPS shall allow Users to request the creation of a Pool to be associated with their User Account.

3.3.1.1 Notification of the Pool Creation Process Outcome The User must receive notification of the success or otherwise of the Pool creation process. If the Pool creation process fails, then the User should be given a reason.

3.3.1.2 Users May Own Multiple Pools TIPS shall allow Users to own as many Pools as they wish.

3.3.1.3 Users May Own Zero Pools Users may own zero Pools if they wish.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Larner Page 20 17 August, 2000 3.3.2 Destroy a Pool Users may destroy a Pool that they own.

Users may not destroy Pools other than those Pools they own.

The Pool must have a zero balance before it may be destroyed.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Larner Page 21 17 August, 2000 3.3.3 Pools Must Contain Only One Kind of Currency A single Pool must only contain a balance in one kind of currency.

Multiple Pools must be used for User Accounts with balances in multiple currencies.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Lamner Page 22 17 August, 2000 3.3.4 Users May Specify a Security Policy for a Pool TIPS shall allow Users to specify a security policy that applies to a Pool owned by them. A User may not modify the security policy of any Pool not belonging to them.

For example, a User may wish to specify that any entity logged onto the system using their identity only has access to a single Pool for the purposes of performing transfers unless extra authentication is supplied (via a smart card perhaps). This would implement the notion of a "purse", which will limit the User's liability in the case that another person steals their login and password.

3.3.4.1 Different Pools May Have Different Security Policies A security policy created by a User is individual to a single Pool. This allows different Pools to have different security policies.

3.3.4.2 There Must be a Default Security Policy TIPS must provide a default security policy for each Pool.

This default security policy is applied when the Pool is created, and may be modified by the User at a later time.

The User may choose to revert to the default security policy on any time on any Pool that they own.

3.3.4.3 Security Policies may be Overridden TIPS shall, by default, allow Users to override these security policies via extra authentication measures. This is to prevent legitimate User lock-out.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Larner Page 23 17 August, 2000 3.4 Transfers 3.4.1 All Transfers Within the System Shall Follow the Same Model All kinds of Transfers (except transfers between Pools) within the system shall follow the same Transfer model. This requirement will simplify the design and implementation of the Thiri Payment Engine.

All transfers (excepting transfers between Pools) shall be implemented the following steps: 1. The payer shall send a request for a Statement to the User Account they wish to pay by subscribing to a Service offered by the payee.

2. The payee (recipient of funds) shall send a Statement the payer (source of funds) detailing the appropriate Transactions.

3. The payer shall receive the Statement.

4. The payer shall authorize the payment of the Statement.

The payee shall receive the funds paid by the payer.

In many cases, most of these steps can be automated.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Larner Page 24 17 August, 2000 3.4.2 Transfers Must Preserve ACID Properties All transfers within TIPS must preserve the ACID transaction properties.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Larner Page 25 17 August, 2000 3.4.3 Money is Preserved During all Transfers Money within the system is preserved during any kind of transfer.

It is an error for money to be created or lost during a transfer.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Larner Page 26 17 August, 2000 3.4.4 Users Must be Notified of Transfer Success or Failure In all cases, and for all kinds of transfers, Users must be notified of the success or otherwise of a transfer.

In the case of failure, the User must be given a reason.

C:\WINDOWS\TEMP\Core-Requirements Specification.doc Thom Larner Page 27 17 August, 2000 3.4.5 TIPS Shall Hide Account Details From Both Users in a Transfer TIPS must hide particular details of each of the Users involved in a Transfer. Such details include the Pool from which funds are going to be withdrawn and deposited.

Each User must not be able to gain access to such details.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thornm Larner Page 28 17 August, 2000 3.4.6 TIPS Shall Allow Anonymous Transfers TIPS shall allow Users to remain anonymous for the purpose of Transfers.

In this case, the buyer's details shall be completely hidden from the seller. The seller shall not be able to gain access to the buyer's details.

C:\WIN DOWS\TEMP\Core.Requirements Specification.doc Thom Larner Page 29 17 August, 2000 3.4.7 Users May Automate Statement Payment Approval by Source of Statement Users may configure their User Account to automatically approve the payment of Statements based on the source of the Statement. The payment may be taken from their main account of one of their Pools.

This can be used to implement periodic payments. If a vendor can periodically and automatically send a Statement, then the entire transfer can be conducted automatically.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Lamer Page 30 17 August, 2000 3.4.8 Users May Transfer Funds Between Their Own Pools Users may transfer funds between Pools that they own within their own account.

This is the only kind of transfer that does not have to satisfy requirement 3.4.1.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thornm Larner Page 31 17 August, 2000 3.4.9 Users May Transfer Funds to Their User Account From an External Account Users may request the transfer of funds from an external account (for example their bank account, credit card, etc.) to their User Account.

The external account must already be associated with the User Account, and TIPS must have the appropriate authority to draw from the external account.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thorn Lamer Page 32 17 August, 2000 3.4.10 Users May Transfer Funds out of the System to an External Account Users may request the transfer of funds from their internal account to some external account (for example, their bank account, credit card, etc.).

The external account must already be associated with the internal account.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thornm Larner Page 33 17 August, 2000 3.4.11 Users May Transfer Funds From One Currency to Another Users may convert all or part of their funds from one kind of currency to another by transferring all or part of their funds from one Pool to another Pool with a currency conversion request.

3.4.11.1 Current Exchange Rates must be Visible During Currency Conversions Users must be able to see the current relevant exchange rate for the currency conversion they have requested.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thom Larner Page 34 17 August, 2000 External Entities 3.5.1 TIPS Shall Allow External Connections The system shall allow external entities to establish a connection to TIPS.

C:\WINDOWS\TEMP\Core Requirements Specification.doc Thornm Larner Page 35 17 August, 2000 3.5.2 Connections are Associated with a User Account Each connection to TIPS is associated with a particular User Account.

C:\WINDOWS\TEMP\Core Requirements Specification.doc EDITORIAL NOTE NO.48003/01 Appendix B page 36 is missing.

Thorn Lamer Page 37 17 August, 2000 3.5.4 Operations are Limited to a Particular User Account During the life of the connection, the external entity may only make requests regarding the User Account with which the connection is associated. All other operations are forbidden.

C:\WINDOWS\TEMP\Core Requirements Specification.doc

Claims (1)

1. 28.Jun. 2002 23:01 Wallington Dummer No.2372 P. WALLINGTON DUMMER 29 The claims defining the invention are as follows: 1. A real-time transaction system to which a plurality of parties can subscribe; said system including a persistent store which contains a record of any given transaction between two or more of said parties; said record being a shared record between said two or more of said parties of said transaction; each of said parties being characterized by said system based on their role in said any given transaction. 2. The system of Claim 1 wherein said record is a shared record of said transaction; said record shared between said two or more of said parties. 3. The transaction system of Claim 1 or Claim 2 wherein said shared record, by agreement of those of said parties who are subscribers to said system, is a definitive record of said transaction. Dated: 28 June 2002 THIRI PTY LTD By its Patent Attorneys WALLINGTON-DUMMER RECE-IVED TIME 28. JUN. 22:58 PRINT TIME 29. JUN. 8 3