CLAIMS

1.

An electronic transaction support system for supporting transactions of property between ones of a defined group of users, each with a user identifier, the system comprising: (a) a registry comprising a database of records in which each record supports one transaction and comprises a plurality of fields in which users can be named, each record reflecting the rights and obligations of the named users in relation to the property underlying the transaction, wherein each record inclues at least one field in which one of the users is named to signify that user's dominion over the record and exclusive entitlement to pass that dominion to another of the users, said at least one field including a holder field; (b) a message handling unit arrange to receive messages transmitted from the users, the messages including the user identifier of the transmitting user and a registry instruction, wherein creation, maintenance and deactivation of the database records are performed responsive to registry instructions contained in user messages; and (c) a registry maintenance unit connecte to the message handling unit so as to receive registry instructions and the associated user identifiers, the registry maintenance unit being responsive to registry instructions according to a closed group of instruction types, each registry instruction being actioned by the registry maintenance unit conditional on a test performed to establish conformity of the registry instruction with a set of rules specific to the instruction type concerne, the sets of rules reflecting a book of rules to which all users of the system are bound to adhere by a common contractual arrangement, and which strictly defines the users'rights and obligations in relation to the property underlying the transaction.

2.

A system according to claim 1, wherein the set of rules of at least one instruction type specifies that the user identifier of the transmitting user shall correspond to a user named in said at least one field and one further field of the record, whereby some of said rights and obligations in relation to the property underlying the transaction are derived from a single user having coincident roles defined by being named in two fields of the record.

3.

A system according to claim 1 or 2, said at least one field consisting of the holder field and a pledgee holder fiel, wherein the sets of rules for the respective registry instruction types collectively ensure that a user shall be named in one, and only one, of the holder field and the pledgee holder field.

4.

A system according to any one of the preceding claims, each record further including: a toorder party field in which one of the users may be named, but which may have no named user; and a consignee field in which one of the users may be named, but which may have no named user; wherein the sets of rules for all the respective registry instruction types have in common that they allow no more than one of the toorder party field and the consignee field simultaneously to have a named user. A system according to any one of the preceding claims, wherein each record further inclues: an originator field in which one of the users is named in each active record; and a shipper field in which one of the users is named in each active record ; wherein, among the instruction types, there is an instruction type for creating a new record, the set of rules for the create record instruction type stipulating that a user shall be named in each of the originator field, the shipper field and the holder field, and that the user named in the originator field shall correspond with the user identifier of the transmitting user. 6. A system according to claim 5 when appende to claim 3, wherein the set of rules for the create record instruction type stipulates that a new record shall have no named user in the pledgee holder field.

5.	7 A system according to claim 5 or 6, wherein the sets of rules for all the respective registry instruction types have in common that they do not allow the user named in the oriainator field to be change.

6.

8 A system according to claim 5,6 or 7,, when appende to claim 4. wherein the set of rules for the create record instruction type stipulates that a create record instruction shall contain one and only one of (i) a user identifier for naming in the consignee field, (ii) a user identifier for naming in the toorder party field, and (iii) an indication that no user is to be named in both the consignee field and the toorder party field.

7.

A system according to claim 5,6,7 or 8, when appende to claim 4, wherein the set of rules for the create record instruction type stipulates that the user specified for naming in the holder field shall not correspond to a user specified for naming in either the consignee field or the toorder party field.

8.

A system according to any one of claims 5 to 9, the registry maintenance unit being further configure so that, when a create record instruction is actioned by the registry maintenance unit, the message handling unit is caused to send a message to the user named in the holder field of the created record signifying that user's dominion over the record, and to send a further message to the user named in the shipper field.

9.

A system according to any one of the preceding claims, wherein, among the instruction types, there is at least one instruction type for changing the user named in the holder field, thereby to change dominion over the record, wherein the set of rules for the name holder instruction type stipulates that the user identifier of the transmitting user shall correspond to a user currently named in said at least one field.

10.	A system according to claim 11 when appende to claim 3, wherein the set of rules for the name holder instruction type stipulates that the user identifier of the transmitting user shall correspond to the user currently named in one of the holder field and the pledgee holder field.

11.

A system according to claim 12, wherein, among the instruction types, there is at least one instruction type r^or changing the user named in the pledgee holder field, thereby to change dominion over the record, wherein the set of rules for the name pledgee holder instruction type stipulates that the user identifier of the transmitting user shall correspond to the user currently named in one of the holder field and the pledgee holder fiel.

12.

A system according to claim 13, when appende to claim 4, wherein the set of rules for the name pledgee holder instruction type further stipulates that: (a) the consignee field shall have no existing named user: (b) the user identifier of the transmitting user shall not correspond to the user specified to become the pledgee holder in the instruction; and (c) actioning of the instruction shall not result in correspondence between the user named in the pledgee holder field and the user named in the toorder party field.

13.

A system according to claim 13 or 14, the registry maintenance unit being configure to cause a message to be sent from the message handling unit to the user named in the holder field or pledgee holder field after actioning of a name holder instruction or name pledgee holder instruction respectively, notifying the user that dominion over the record have passed to him.

14.

A system according to any one of the preceding claims, wherein each record further inclues an associated history filev the registre maintenance unit being configure to action at least some types of registry instruction by writing data relating to registre instruction requests to the history file of the record concerne, thereby to maintain an audit trail of actions requested on that record, there being no registry instruction types that allow history files to be accessed by users of the system.

15.

A system according to claim 4 when appende to claim 3, or any one of claims 5 to 16 when appende to claims 3 and 4, wherein the sets of rules for all the respective registry instruction types additionally have in common that they: (a) allow no more than one of the pledgee holder field and the consignee field simultaneously to have a named user; and (b) prevent a record adopting a state in which a user named in the pledgee holder field corresponds to a user named in the toorder party field.

16.

A system according to claim 17, wherein each record further inclues an associated endorsement chain file in which is stored a time ordered list of users who have been contracting parties to the record, the endorsement chain file being maintained by the registry maintenance unit, wherein a contracting party is defined as including a user who is named simultaneously in (a) the holder field and the consignee field of a record, and (b) the holder field and the toorder party field of a record.

17.	A system according to claim 18, wherein, each time the record changes state so as to create a new contracting party, the registry maintenance unit is configure to cause the message handling unit to send a copy of the endorsement chain to the user who is the new contracting party.

18.

A system according to any one of the preceding claims, the registry instructions including a business refusal instruction type for revoking an immediately previous registry instruction that resulted in a change of the user named in said at least one field, signifying a change in dominion over the record. the registry maintenance unit being configure to action a business refusal instruction by changing the record back to its immediately previous state, wherein the set of rules for the business refusal instruction type stipulates that: (a) the user identifier of the transmitting user shall correspond to the user named in said at least one field; and (b) the business refusa instruction shall be received within a defined period of time from the immediately previous registry instruction.

19.

A system according to claim 20, when appende to claim 4, wherein the set of rules for the business refusal instruction type further stipulates that: (c) the user identifier of the transmitting user shall correspond to the user named in the holder fiel, (d) the user identifier of the transmitting user shall correspond to the user named in one of the toorder party field and the consignee field.

20.

A system according to claim 20 or 21, wherein the registry maintenance unit is configure so that, following actioning of a business refusal instruction by the registry maintenance unit, a message is caused to be sent from the message handling unit to the user named in said at least one field after actioning of the business refusal instruction, notifying that dominion over the record has reverted to him following refusal of the user named in the holder field by the immediately previous instruction to accept dominion over the record.

21.	A system according to claim 22 when appende to claim 18, wherein the registry maintenance unit is configure to action a business refusal instruction by reversing any change in the endorsement chain file that resulted from the immediately previous registry instruction.

22.	A system according to any one of claims 20 to 23, wherein the defined period of time for carrying out a business refusal instruction is a fixed period of time of approximately 24 hours.

23.

A system according to claims 3 and 4, or any one of claims 5 to 24 when appende thereto, the registry instructions including an instruction type for naming a user in the toorder party field, the set of rules for the name toorder party instruction type stipulating that: (a) the consignee field shall have no existing named user; (b) the user identifier of the transmitting user shall correspond to the user named in the holder field or the pledgee holder field; and (c) actioning of the instruction shall not result in correspondence between the user named in the pledgee holder field and the user named in the toorder party field.

24.

A system according to claims 3 and 4, or any one of claims 5 to 25 when appende thereto, the registry instructions including an instruction type for naming a user in the consignee field to signify nontransferability of the record, the set of rules for the name consignee instruction type stipulating that: (a) the consignee field shall having no existing named user; (b) the user identifier of the transmitting user shall correspond to the user named in the holder field or in the pledgee holder field; and (c) the toorder party field shall either have no named user or the named user specified in the holder field.

25.

A system according to claim 4, or any one of claims 5 to 26 when appende thereto, the registry instructions including an instruction type for blank endorsing a record by removing the user specified in the toorder party field thereof, the set of rules for the blank endorse instruction type stipulating that: (a) the user identifier of the transmitting user shall correspond to the user named in the holder field; and (b) the user identifier of the transmitting user shall correspond to the user named in the toorder party field.

26.

A system according to claims 3 and 4, or any one of claims 5 to 27 when appende thereto, the registre instructions including an instruction type for enforcing a pledge over a record by (i) naming the user specified in the pledgee holder field as the user specified in the toorder part. and (ii) deleting the user specified in the pledgee holder field and naming that user instead in the holder field, the set of rules for the enforce pledge instruction type stipulating that the user identifier of the transmitting user shall correspond to the user named in the pledgee holder field.

27.

A system according to any one of claims 5 to 10, or any one of claims 11 to 28 when appende thereto, the registry instructions including an instruction type for switching from electronic support of a transaction by the system to conventional paper based supporting of the transaction outside the system, the set of rules for a switchtopaper instruction stipulating that the user identifier of the transmitting user shall correspond to the user named in said at least one field; the registry management unit being configure to action a switchtopaper instruction by deactivating the record concerne, and causing a message to be sent from the message handling unit to the user named in the originator field requiring creation of a paper document based on the contents of the deactivated record which are included as part of the message.

28.

A system according to claim 4, or any one of claims 5 to 29 when appende thereto, each record further including a surrender party field in which one of the users may be named, but which may have no named user, the registry instructions including an instruction type for surrendering the record to signify disposition of the property underlying the transaction, the registry maintenance unit being configure to action a surrender record instruction by deactivating the record, the set of rules for the surrender record instruction type stipulating that the user identifier of the transmitting user shall correspond to (a) the user named in the holder field and (b) the user named in one of the toorder party field and the consignee field.

29.

A system according to claim 30, the registry maintenance unit being further configure so that. when a message is actioned that inclues a registry instruction of the surrender type, the registry maintenance unit causes the message handling unit to send a message to the user named in the originator field, and to any user named in the surrender party field, indicating that the record has been deactivated.

30.

A system according to claim 30 or 31 when appende to claim 29, the registry management unit being configured to action a switchtopaper instruction by causing a message to be sent from the message handling unit to the user named in the originator field, and to any user named in the surrender party field.

31.

A system according to any one of claims 5 to 10, or any one of claims 11 to 3 when appende thereto, the registry instructions including further instruction types for requesting amendment, granting amendment, and denying amendment of a record, wherein the set of rules for the request amendment instruction type stipulates that the user identifier of the transmitting user shall correspond to the user named in said at least one field; the registry maintenance unit being configure to action a request amendment instruction by allocating an amendment identifier to the request amendment instruction and storing that amendment identifier, and by causing the message handling unit to send a message to the user named in the originator field of the record, the message including the request amendment instruction together with the amendment identifier allocated thereto; and wherein the set of rules for grant and deny amendment instruction types each stipulate that the user identifier of the transmitting user shall correspond to the user named in the originator field, and that the message containing the instruction shall include an amendment identifier corresponding to the amendment identifier stored for the record concerne.

32.

A system according to claim 33, each record further includiny an amendment pending field for indicating whether or not a request amendment instruction is pending, the registry maintenance unit being configure to set the amendment pending field responsive to a request amendment instruction and to unset the amendment pending field responsive to a orant or deny amendment instruction, wherein the registry maintenance unit is configure to prevent changes to the record while the amendment pending field is set.

33.

A system according to claim 33 or 34, the registry maintenance unit being configure to action a deny amendment instruction by sending a message to the user who issued the request amendment instruction indicating that the user named in the originator field has issued a deny amendment instruction responsive to the request amendment instruction.

34.

A system according to claim 33,34 or 35, wherein, a grant amendment instruction is actioned by the registry maintenance unit, depending on content of the grant amendment instruction. to result in one of the following: (a) multiple existing records being merged by their deactivation and creation of a single new record; (b) a single existing record being split into multiple records by deactivation of the single existing record and creation of multiple new records; (c) maintenance of a single existing record; and (d) deactivation of a single existing record and creation of another single record.

35.

A recording medium on which is stored a title registry database for supporting transactions of property between ones of a defined group of users, each with a user identifier. the title registry database comprising a plurality of records, each for supporting one transaction, each record comprising a plurality of fields in which users can be named, each record reflecting the rights and obligations of the named users in relation to the property underlying the transaction, wherein each record inclues at least one field in which one of the users is named to signify that user's dominion over the record and exclusive entitlement to pass that dominion to another of the users, said at least one field including a holder field.

36.

3 8. A server for supporting transactions between a plurality of registered users each shaving a user identifier, the server comprising a database comprising a plurality of records each signifying a bill of lading and including a record identifier, wherein the database records have a structure including a field for specifying the user identifier of a holder shaving possession rights over the database record, including sole rights among the registered users for naming another registered user in the holder field and/or any registered user in at least one further field of the database record. A serveur according to claim 38, wherein the server is configure so that, when one registered user, who is the user entered in the holder field of a record, names another registered user in a database field of that record, the server initiates notification of the newly named registered user to that effect.

37.

40 A server according to claim 39, wherein, when the newly named registered user is entered into a field signifying being a party to the transaction, the server is responsive to a business refusal instruction in respect of the naming of the newly named registered user for an amount of time known to the registered users and/or until such time as the server receives another command from the newly named registered user in respect of the record concerne.