Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION 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/00—Commerce
  • G06Q30/06—Buying, selling or leasing transactions

Definitions

• the invention relates to a computer system for supporting commercial transactions, more especially but not exclusively a computer system for supporting trade of goods by shipping, wherein shipping will be understood to include transit of goods in ocean going vessels, air-freight, rail-freight and road haulage, for example.
• a Bill of Lading is a document used in connection with shipment of goods from a seller (or other party causing a shipment) to a buyer (or other receiving party) via a carrier.
• the Bill of Lading is generated by the carrier when the seller gives over the goods to the carrier for shipment from a dispatch port to a destination port.
• the Bill of Lading includes an inventory of the goods received by the carrier and a verification by the carrier of the good condition of the goods.
• the Bill of Lading also includes a contract between the carrier and the seller that includes an undertaking by the carrier only to hand over the goods at the destination port to someone who produces the Bill of Lading.
• the Bill of Lading After generation by the carrier, the Bill of Lading is initially in the possession of the seller. While the goods are in transit with the carrier, the Bill of Lading passes from the seller to the buyer, often via various intermediaries such as the seller's bank and the buyer ' s bank. Ultimately, the Bill of Lading becomes exhausted when presented to the carrier at the destination port in exchange for the goods.
• the goods are handed over to the carrier at the dispatch port.
• the carrier generates a Bill of Lading and certifies the goods to be complete and in good order.
• the seller takes the Bill of Lading and gives it to his bank.
• the seller's bank may then credit the seller's account with the sales amount associated with the goods, if a letter of credit and bill of exchange are also present for the transaction.
• the seller ' s bank then sends the Bill of Lading to the buyer ' s bank.
• the buyer ' s bank now in receipt of the Bill of Lading credits the seller ' s bank by the sales amount and debits the buyer's account by the sales amount.
• the buyer ' s bank then sends the Bill of Lading to the buyer, who is then in possession of the Bill of Lading and thus able to pick up the goods from the carrier at the destination port.
• the handling of the Bill of Lading by the various parties is often affected by the existence and terms of other documents involved in the transaction, but these collateral documents are not described here for the sake of brevity.
• the Bill of Lading is not itself a payment instrument, the corresponding payment instrument often takes the form of a Bill of Exchange or Draft. Again, the nature and role of these documents are not described here.
• the Bill of Lading may be a non-negotiable (i.e. non-transferable) instrument, in which the designated buyer cannot be changed.
• the carrier is bound only to hand over the goods at the destination port to the buyer stated in the Bill of Lading at the time of its generation by the carrier at the dispatch port.
• the designated buyer of a non-negotiable Bill of Lading is referred to as a consignee.
• the non- negotiable Bill of Lading is referred to as a Straight Bill of Lading.
• the Bill of Lading it is also widespread practice for the Bill of Lading to be a negotiable instrument, in which case the designated buyer can be changed during transit of the goods. In such cases, the designated buyer may in fact not be the ultimate recipient of the goods, but is merely an intermediate endorsee of the Bill of Lading.
• the endorsee of a negotiable Bill of Lading is referred to as the To Order Party.
• the To Order Party When the Bill of Lading is generated by the carrier, it already specifies whether the Bill of Lading is negotiable or not. If the Bill of Lading is negotiable when generated, the carrier will know that the To Order Party, i.e. the designated buyer, may change in transit. Clearly, if the Bill of Lading is generated as a negotiable Bill of Lading and the buyer is changed in transit, then the carrier will give up the goods at the destination port to whoever produces the Bill of Lading.
• Bills of Lading are not endorse Bills of Lading to banks, for example, and thus, banks do not become To Order Parties even though they receive, hold and pass on the Bill of Lading.
• Banks generally rely only on physical possession of the Bill of Lading to secure their position in relation to other parties involved in the transaction.
• a negotiable Bill of Lading may also be negotiated the person who physically possesses it (its bearer), if it is endorsed in blank. Such a Bill of Lading has no To Order Party while blank endorsed.
• the To Order Party may later be added at some stage prior to the goods being picked up from the carrier at the destination port.
• the Bill of Lading may pass through a party who makes no change to the Bill of Lading and thus relies solely on physical possession of the Bill of Lading to establish or secure his interests.
• This has the advantage that confidentiality is retained since a party such as an intermediary bank will remain unknown in the transactional history of the Bill of Lading, since there is no evidence on the Bill of Lading to trace back previous holders of the Bill of Lading unless they were entered at some stage as the To Order Party.
• the conventional Bill of Lading transaction system relies extensively on undocumented physical possession of the Bill of Lading. Moreover, it is common for there to be divergence between the apparent legal chain of endorsement on the goods in transit, as evidenced by the Bill of Lading, and the real chain of constructive possession of the goods through possession of the Bill of Lading.
• the conventional Bill of Lading system is thus reliant on the uniqueness of a Bill of Lading. There must only be one Bill of Lading, since the whole system is based on the passing of rights with the Bill of Lading, i.e. with a unique document specific to one transit of the goods that are specified in the inventory part of the Bill of Lading.
• Bills of Lading may be accepted as security for loans or mortgages which could thus be fraudulently obtained. It is thus possible for multiple loans, for example, to be obtained using a single consignment of goods as security.
• Another malpractice is forgery of the Bill of Lading. If a Bill of Lading is forged, then the carrier may hand over the goods at the destination port to a person who produces the forged Bill of Lading together with bogus identity impersonating a representative of the consignee or To Order Party. Scope for forgery arises when information on the nature of a shipment can be obtained by the forger, for example by obtaining a photocopy of the Bill of Lading. In the case of ocean transit by ships, the minimum transit time may be several weeks, in which case a forger has considerable time to complete the forgery.
• a centralized database system accessed by system users over a network through a message handling unit.
• the database forms a registry recording the entitlements of the users, who are a defined group, to perform prescribed actions in relation to electronically created records.
• the electronically created records represent a strictly defined series of rights and obligations in relation to underlying property.
• the users become entitled by virtue of their designation to prescribed roles by a previously entitled user. Designation of a user to a prescribed role in a record takes place by means of a system user sending an electronic instruction to the database, these electronic instructions being referred to as registry instructions or title registry instructions.
• the database performs according to a common contractual arrangement entered in to by all users.
• the intending user is required to enter into a service contract with the system service provider in which the intending user undertakes to agree to and abide by a defined set of rules. That is. each User agrees, as a condition of becoming a User of the System, to be bound by the provisions of the rules.
• the rules, codified in a rule book, together with the service contract provide the legal framework underpinning and enabling the functioning of the database system as a support system for transactions in property.
• each transaction record in the central database goes through a complete life cycle of creation, change and exhaustion, entirely under the control of the users.
• the integrity of the central database can be maintained wholly automatically by the system approving or rejecting user instructions received with e-mail or other messages solely on the basis of their conformity to the closed set of logical rules defined in the rulebook. Since every user has agreed to be contractually bound by the rulebook. user actions in the form of electronic instructions to create, change and exhaust electronic records are contractually binding on all affected users, provided only that the instructions themselves conform to the rulebook. Moreover, the legal significance of the transaction record contents and changes thereto also follows automatically from the common contractual arrangement.
• the central database can thus be maintained in a wholly automated manner by the service provider through checking instruction conformity against the agreed rules and notifying affected parties, also as defined in the common contractual arrangement. Further, the changing functions and significances of a bill of lading take effect automatically, through the changes to the transaction record, solely under user initiation. No subjective assessment is required of the contents of any individual record held in the central database, i.e. there exists no human system supervisor or administrator roles for the day-to-day processing of the transaction records.
• Each individual electronic record is created in the database by a user who belongs to a defined group of users.
• a record is created by means of a registry instruction sent by an instructing user concerning specific property rights, such property rights being vested in the instructing user.
• Each record may be created, in accordance with the instructing user ' s instructions, to be capable of complete transferability to other users or limited transferability to other specified users.
• Each record has one holder who is a user of the system.
• Holdership is defined by the presence of a user identifier of the holder/user in a field of the record.
• the holder has exclusive dominion over the record and exclusive entitlement to pass the status of holder to another user. Passing the holder status is achieved by the current holder/user sending a registry instruction instructing that another specified user be substituted in the holder field of the record concerned.
• Each electronic record can be converted into a physical documentary record
• the right to dispose or direct the disposition of the underlying property is conditional on a single user being designated to prescribed coincident roles and the user so designated communicating a registry instruction to the user which had created the record. Thereafter, transactions relating to that record are complete and no further designations are permitted and the record is terminated.
• Each electronic record has associated therewith, in addition to specific audit trail kept in the database, an endorsement chain recording the legally significant passage of rights and obligations.
• the endorsement chain is distributed together with a message from the database to the new designee. according to its role as designated user.
• Each electronic record is capable of being modified by the user which created the record in accordance with a registry instruction previously sent by the holder of the record.
• the user that created the record is entitled to modify, decline to modify or create a new electronic record or records based on prescribed rules.
• Each electronic record is capable of being temporarily suspended as a result of prescribed registry instructions sent by the holder of the record.
• a system of moving of moving originals in paper form inevitably takes time as the documents move from Holder to Holder in different countries and often different continents. In some instances, particularly where a shipment is traded many times (e.g., oil and dry bulk cargoes) it is rare that the original document is available at the port of discharge. A complex system of letters of indemnity, which bring a new set of problems, has grown up to try and circumvent this problem. In addition to risk mitigation, improving the speed enables those involved in international trade to be more certain of being able to get the goods and to reduce inventory.
• Much of the information contained in a bill of lading is repeated in collateral documents. The potential for error in completing collateral documents and the bill of lading is high and a high proportion of documents have to be returned for amendment. Electronic documents reduce the risk of mis-keying as the same information is re-used in completing the documents. (3)
• the use of a central database enables electronic records to be made
• Figure 1 is a block diagram showing information flow between system components, including the users, the message handling unit and the title registry;
• Figure 1A shows internal structure of the title registry in more detail;
• Figure 2 shows structure of a message;
• Figure 3 illustrates sending a message from a sending user to a receiving user through the message handling unit of the central system
• Figure 4 illustrates the receiving user's acknowledgment of receipt of the forwarded message originating from the sending user
• Figure 5 illustrates the receiving user's non-acknowledgment of receipt of the forwarded message originating from the sending user
• Figure 6 illustrates a user's indication of its intent to ignore a message through a SBRf -FBRf sequence
• Figure 7 illustrates all type header flows:
• Figure 7A is a table summarizing message flow and type headers;
• Figure 8 illustrates identifier structure showing the identifier parts of a user identifier, a user division identifier, and an extension
• Figure 9 is a block diagram illustrating signed message flow using the message handling unit
• Figure 10 is a flow diagram showing sending a message from user to user with signature verification and acknowledgments
• Figure 1 1 shows basic organizational structure for certificate services
• Figure 12 shows a sample certificate chain
• Figure 13 is a flow diagram showing the lifecycle of a subscriber certificate, from beginning to end;
• Figure 14 is a simplified illustration of a title registry record as presented in terms of its fields to a user;
• Figure 15 is a block diagram showing message flow for title registry operations:
• Figure 16 illustrates message components showing the Instruction element for the title registry:
• Figure 17 is a flow diagram showing the process of creating an electronic bill of lading
• Figure 18 is a flow diagram showing the process of designating a new holder
• Figure 19 is a flow diagram showing the process of designating a Consignee
• Figure 20 is a flow diagram showing the process of designating a To Order Party:
• Figure 21 is a flow diagram showing the process of blank-endorsing an electronic bill of lading
• Figure 22 is a flow diagram showing the process of designating a Pledgee
• Figure 23 is a flow diagram showing the process of relinquishing a pledge in an electronic bill of lading
• Figure 24 is a flow diagram showing the process of enforcing a pledge, where a To Order Party is designated;
• Figure 25 is a flow diagram showing the process of requesting amendment of an electronic bill of lading;
• Figure 26 is a flow diagram showing the process of denying amendment of an electronic bill of lading
• Figure 27 is a flow diagram showing the process of granting amendment of an electronic bill of lading
• Figure 28 is a flow diagram showing the process of surrendering an electronic bill of lading
• Figure 29 is a flow diagram showing the process of processing a switch-to- paper directive
• Figure 30 shows an example of an endorsement chain
• Figure 31 shows the format of a system message including message and document information, and a title registry instruction and attached electronic bill of lading (eBL);
• Figure 32 is a table summarizing the title registry functions and which party can execute which function:
• Figure 33 is a table summarizing the title registry functions and the conditions that apply to them;
• Figure 34 is a table showing for a Create instruction the functional elements of delivery of attond notice, allowance of business refusal, creation of endorsement chain record and delivery of an endorsement chain record;
• Figure 35 is a table showing for Name Holder and Name Pledgee Holder instructions the functional elements of delivery of attond notice, allowance of business refusal, creation of endorsement chain record and delivery of an endorsement chain record;
• Figure 36 is a table showing for Name to Order, Name Consignee and Blank
• Endorse instructions the functional elements of delivery of attond notice, allowance of business refusal, creation of endorsement chain record and delivery of an endorsement chain record;
• Figure 37 is a table showing for allowed simultaneous instructions the functional elements of delivery of attonce notice, allowance of business refusal, creation of endorsement chain record and delivery of an endorsement chain record;
• Figure 38 is a table showing for an Enforce Pledge instruction the functional elements of delivery of attonce notice, allowance of business refusal, creation of endorsement chain record and delivery of an endorsement chain record
• Figure 39 is a table showing for a Grant Amendment instruction (with a new eBL version) the functional elements of delivery of attonce notice, allowance of business refusal, creation of endorsement chain record and delivery of an endorsement chain record;
• Figure 40 is a table showing for a Grant Amendment instruction (with a new eBL identifier) the functional elements of delivery of attond notice, allowance of business refusal. creation of endorsement chain record and delivery of an endorsement chain record: and
• Figure 41 is a description of the errors a sender may receive as a result of validation errors or other errors in an incoming message.
• the present system is a technological and legal infrastructure to facilitate trade transactions through electronic means. It uses information technology to transfer messages and store certain information, and a legal system of rules and contracts to determine the effects of certain messages and updates to the stored information, as defined in a Rulebook which is reproduced further below.
• Rulebook which is reproduced further below.
• the following text describes the operating procedures of that technology and its operation. The business effect of the functionality of the operating procedures depends heavily on the appended Rulebook.
• the operational rules of the Rulebook are also recited alongside the relevant operating procedures.
• the operational rules are mandatory and binding on system users by contract law in accordance with the Rulebook, and are also reflected in many design aspects of the computer system used for implementing the automated transaction support system.
• the structure of the present system comprises the message handling unit, the title registry, the user database, the user support resources and the user systems.
• the message handling unit is a system for passing special electronic messages between system users among themselves and the system service provider, and for keeping track of those messages once sent.
• the message handling unit as used in the present system, is a special mail server for transporting messages coupled with a database for logging and storing the messages once sent. It works closely with the user database to check user identifiers.
• the message handling unit also sends information into the title registry and the user support resources via special interfaces. Messages may, at the sender ' s option, include "attachments", which are documents or other units of digital information included in the message.
• the title registry is a database of information created from and maintained by messages concerning rights and obligations in relation to specific transactions.
• the title registry records information used in conjunction with the legal rules and contracts of the present system to show the changing rights of system users in relation to an electronic bill of lading.
• the user database is a database of information about system users and is used to identify proper and authorized users, limit access to the present system, and determine the authenticity of messages received from users by the message handling unit.
• the user support resources comprise a collection of online information about system users, help on use of the present system, bulletins and alerts, your account status, and similar information; and a help desk for live support by telephone or e-mail. Further support resources may be added as desired.
• the online user support resources can be used through a Worldwide Web browser. Messages cannot be sent into the message handling unit and the title registry cannot be modified through the user support resources; they simply enable users to look up needed information and update the information pertaining to themselves.
• User systems are a user's computer facilities, including a communications link to a network connected to the message handling unit, desktop computer hardware connected to that communications link, and software for creating, sending and receiving messages using the message handling unit.
• the first four of the components listed above are central services provided by the system service provider to all users.
• the fifth component, user systems are provided by third-party vendors and service bureaus, and need to conform with the specifications defined by the service provider for interfacing with the message handling unit.
• Figure 1 illustrates the system structure and also shows the information and transaction flows between the components. Further internal structure of the title registry is shown in Figure 1A. Some of the more important information flows are messaging between users, browsing the user support services, changing information in the user support resources and user database, and interaction with the title registry.
• the principal means of communication between users of the present system is electronic messages via the message handling unit, which checks and logs each message as it passes through.
• the message handling unit also provides for acknowledgment of each message as it is received in order to assure the sender that a message is actually delivered.
• the online user support resources enable one user to look up another user's identifier, to find out other available information about users, check the status of messages, and obtain help for use of the present system, all through a simple Web-browser interface.
• Authorized representatives of a user may also update certain information about the user.
• the information in the user support resources originates from the enrollment process by which new users join the system. After enrollment, a user updates its information using special online forms available through the user support resources.
• users introduce records into the title registry by sending digitally signed messages through the message handling unit. By the same means, they enter further information to update those records and modify their status and relations to those records and the rights they signify.
• the present system secures its components and information flows mainly by user identification, resource access controls, document authentication, message integrity checking and message encryption.
• Factors that tend to weaken the reliability of an individual user ' s identification are taken into consideration in determining whether to issue a certificate identifying the user.
• the ability of a user to gain access to and use the components of the present system is limited to the user ' s legitimate requirements. Further, access to and usage of the system is tracked and audited.
• verifying a digital signature makes evident any changes in the digitally signed message made between the time when the message was signed and the time when verification took place.
• the present system verifies a message's digital signature on receipt of the message into the message handling unit. It then sends on the message only if it is verified as free from tampering.
• message encryption if the sender of a message wishes, the sender may encrypt the message so that, as a practical matter, it will not be readable by users other than the intended recipient.
• Some legal systems regulate the availability and use of encryption capabilities users subject to those legal systems will, of course, need to comply with applicable encryption regulations. That compliance is required by the force of the regulations themselves, and by the general requirement in the Rulebook to comply with applicable regulations.
• the present system imposes no restrictions of its own on the use of encryption technology, other than the practical limits of what its implemented systems are capable of accommodating.
• a message consists of a series of components, as illustrated in Figure 2.
• Figure 2 illustrates, the principal components of a typical message are message headers, message part headers, type headers, document parts, and message end indicators.
• Message headers are lines of text appearing at the beginning of a whole message to route it (such as "To " or '”From"), indicate its "Subject”, indicate to the software how to process it (such as by noting its "Content-Type”), and serve similar purposes at the level of the message as a whole.
• the message headers are prescribed by standards and are not specific to the present system.
• the principal standard prescribing message headers for Internet mail using the Simple Mail Transport Protocol is RFC 822 of the Internet Engineering Task Force.
• MIME message format is standardized mainly in RFCs 1521 and 1522 of the Internet
• Each pan is delimited by a header noting its content type and the encoding used to pass it through e-mail channels.
• the message part headers are prescribed by the MIME standards and are not specific to the present system.
• a type header is contained in each message. This is a part of the message which indicates its type and function within the present system and conveys data into the present system ' s logs, title registry, and other records.
• the type header is specific to the present system. It contains data tagged as elements in accordance with the
• XML is a method for labeling data. It is prescribed in a specification entitled
• One or more document parts may also be included in a message after the type header.
• a message may have one or more such additional parts, each consisting of a document introduced by a message part header.
• the document parts of a message are often termed "attachments " , "attached documents " or the like.
• Document parts are optional, but are common in most messages sent in the present system. The form of document parts is not specific to the present system and is prescribed by the MIME standards.
• a message end indicator is a line consisting of a single dot marks the end of the message as a whole.
• the message end indicator is the standard way of showing the end of a message according to Internet e-mail standards (mainly RFC 822).
• Message headers, message part headers, and the type header are technical devices used mainly for moving and processing messages behind the scenes and serving as containers for their contents.
• the message headers are not signed or encrypted, although the matter within them (including the type header) is.
• a message shall be in the form required by IETF RFC 822, IETF RFCs 1521 and 1522 (MIME standards), and IETF RFCs 1847 and 1848. Further, it shall have technically proper content as according to the specifications described herein.
• Composing a message into this technical form is a task for the user systems, rather then the message handling unit or any other components maintained by the system service provider.
• the message handling unit does however require that the message be in this required form. It further requires that accredited user systems demonstrate an ability to compose messages in that format. They may do so by providing on-screen forms to fill in, text editing and display capabilities, linkage with local databases and document systems, and other functionality to aid in creating a message.
• a user system will only rarely display received messages in this raw form.
• a user system may not display all of the message headers, and except in troubleshooting, only the to. from, dates of sending and receipt, and subject headers hold interest.
• the type header and documents within a message are used extensively in doing business via the present system, although usually in a more user-friendly onscreen display.
• the raw forms of the type headers are usually presented in more readable ways, the type header forms play an important and definitive role in the flow of messages through the message handling unit.
• Three principal user activities involving the message handling unit are the sending of messages, the issuing of acknowledgments of receipt and handling of refusals to do business.
• the sending of messages sending a message from one user to another user or to a present system resource such as the title registry with instructions to perform a function there (such as create an electronic bill of lading).
• the message consists of a type header and possibly one or more included documents, along with the headers used in routing and processing the message.
• Operation Rule 2 Acknowledging FMsg Messages
• Aui acknowledgment is not an assent to any obligations proposed in the acknowledged message. It is simply and merely a notice that the message arrived in proper, authentic form, and nothing more. The recipient acknowledges receipt of the message even if the recipient declines to proceed with any business proposed in the message.
• the recipient of a message may notify its original sender that the recipient intends to -99-
• type header of a message takes on different forms, each with different functional implications and content. These differing forms of type headers are noted below in explaining these basic message processes for creating, sending, and receiving messages.
• Sending a message from one user to another or to the title registry consists of a two-stage movement: First, the sender transmits the message to the message handling unit, which then relays it to its recipient.
• the message handling unit checks and tracks all message flows as an intermediary between all users, so all messages pass through the present system en route to their final destinations.
• a SMsg is the form of type header for a message sent by a system user into the message handling unit, and to be sent on from there to its ultimate recipient.
• the message handling unit When the message handling unit receives a SMsg, the message handling unit:
• Logs the SMsg by recording its type header, a hash result of any documents included in it, the time of processing, and other information.
• a Records Retention Schedule forms part of each Operational Service Contract between the system service provider and a user. Either the Records Retention Schedule from the sender's contract or the ultimate recipient's could apply, or both, depending on how the schedules in their respective Operational Service Contracts are worded and the options chosen by each user in making its Contract).
• a BAck does not indicate receipt by the ultimate recipient of the message; rather, it merely indicates that the message handling unit has received and processed the SMsg. If the message handling unit receives the message but encounters an error checking it, it returns a type header in the form of a Bolero Non-acknowledgment (BNak), where Bolero is the trading name of the service provider. If the message handling unit never receives the message, nothing is returned to the sender. Accredited user systems provide a function to link each SMsg with its BAck or BNak and alert the user after a BNak arrives or a message remains for a specified amount of time without either a BAck or a BNak.
• BNak Bolero Non-acknowledgment
• the SMsg takes the form of a Forwarded message, abbreviated FMsg.
• the recipient of the FMsg may be a user or the title registry.
• a FMsg ordinarily differs from its antecedent SMsg mainly in its type header, message identifiers, timing information, digital signature (which is the service provider ' s on an FMsg and the original sender ' s on a SMsg). and in its elements having to do with the title registry. Awaits an acknowledgment from the recipient indicating that the forwarded message (FMsg) was received.
• Figure 3 illustrates the flow of this process of sending a message via the message handling unit.
• the basic information flow in sending a message to another user or the title registry consists of (1) dispatching the message (a SMsg) to the service provider. (2) receiving an acknowledgment from the service provider (a BAck) indicating that the message was received and processed by the service provider or a BNAk indicating that it was received but not processed or forwarded, and (3) having the present system forward the message (now an FMsg) on to the intended recipient. 2.2.2. Recipient ' s Acknowledgment of Receipt
• the recipient of the message shall return a UAck message to the message handling unit at its earliest reasonable opportunity.
• Operational Rule 2 requires the recipient to acknowledge its receipt promptly.
• the recipient makes this acknowledgment by sending a message with a type header in the form of a user acknowledgment (UAck) to the message handling unit.
• UAck user acknowledgment
• the message handling unit On receipt of the UAck, the message handling unit then relays it on to the original sender as a type header in the form of a delivery notification (DNot), if the sender of the original SMsg requested notification of delivery.
• DNot delivery notification
• the UAck-DNot sequence indicates receipt of the message by its intended recipient (the recipient specified as the user who is to receive the message); in other words, it shows that the FMsg message arrived at its designated recipient ' s user system in accordance with the technical requirements prescribed by the system service provider.
• a recipient does not admit that the recipient has read the message, has the functionality necessary to read the message properly, has knowledge or notice of any of its contents, or agrees with or accepts any obligation in the message (see Rulebook).
• a UAck-DNot sequence indicates nothing more than the simple fact that the message arrived as a technically valid message, exactly as it was forwarded from the present system as a FMsg.
• the recipient If the forwarded message does not arrive as a technically valid FMsg message but rather bears an unverifiable digital signature or is not in the form specified for an FMsg. the recipient returns a type header in the form of a user non-acknowledgment (UNAk) to the message handling unit.
• the message handling unit in turn relays to the original sender a message containing a type header in the form of a failure notification (FNot).
• the message handling unit will also return a FNot if no UAck is received for the message within a timeout period.
• the originator of the message may specify timeout period or the message handling unit will apply one by default.
• the original sender may then address the problem indicated in the FNot as the reason for failure, and then resend the message or take other action as needed.
• Figure 5 illustrates the non-acknowledgment process. Accredited user systems return UAck or UNAk messages automatically as each FMsg is received, without requiring the recipient to take any action.
• a recipient may only send a UNAk if the message as received appears to have a critical technical fault.
• a UNAk should not be used to indicate that the recipient wishes not to have received the message, refuses to read or be bound by the message, or intends to disregard the message.
• a UNAk indicates a failure in message delivery for apparent technical causes, whereas a sender ' s business refusal (SBRf) indicates that no further response will be forthcoming due to human volition or inability to proceed, i.e., the recipient does not wish to progress or deal further with the content of the message.
• SBRf sender ' s business refusal
• a message may be received technically intact but make no sense to the receiving user, perhaps because the recipient cannot relate the message to a business context known to be significant. In other situations, the message may be unwelcome or otherwise worth ignoring in the recipient's judgment. In such circumstances, the recipient may notify the original sender of the message that the recipient intends to take no action based on the message and will ignore it. To notify the original sender of those intentions, the recipient sends a type header in the form of a sent business refusal (SBRf) to the message handling unit, which in turn relays a user ' s business refusal (FBRf) to the original sender of the message.
• SBRf sent business refusal
• FBRf user ' s business refusal
• the recipient of a message may send the SBRf (which triggers the FBRf to the original sender) within 24 hours after the message is received. Any other convenient time period could be selected.
• the SBRf will be confusing and contradictory if it is sent after the recipient has already taken some apparent action in response to the message.
• R a recipient, receives and duly acknowledges a message from S, a sender. R then replies to S in a message reading: "I got your note and will look into it shortly. " R later "looks into” the message from S and decides to ignore and discard it.
• a SBRf-FBRf sequence after R's earlier message to S, could be confusing or ambiguous. R could avoid that confusion by including an explanation in the free text fields of the SBRf-FBRf sequence, or by foregoing the SBRf option entirely and simply sending an ordinary SMsg to the sender expressing R's intentions.
• Messages in the message handling unit serve different functions necessary to provide a high-assurance messaging service. Those functions are indicated by the type headers in the messages.
• the varying forms of the type headers have varying significance for users, and they trigger varying operations, often another message with a responsive type header, within the message handling unit.
• Figure 7 summarizes the type header flow sequence, with one message triggering another.
• Figure 7A indicates as a table the type header forms illustrated in Figure 7, where they come from and where they go, and what they mean.
• the numbers in Figure 7 A refer to the numbers used in Figure 7. All of these messages are digitally signed, and a BNak will result from a digital signature that fails verification. For more information about digital signatures and message authenticity, see Section 2.4.2.
• an original sent message causes to exist and sets in motion the other type headers in a series or chain reaction.
• Some of the type header types are alternatives to others, or are optional, depending on the circumstances.
• Accredited user systems can link together or associate all of the type headers from various messages that comprise a single series or chain, all related to the same original Sent message (SMsg). Some user systems refer to this process of linking related messages as "reconciling " .
• type headers indicate the varying directions in which messages flow in the message handling unit. Besides indicating message flow, each type header form requires certain content, such as user identifiers and information about documents attached to the message.
• the type header is the principal means used by the server of the message handling unit of tracking the message and assuring that it satisfies requirements for documents, addressing and routing, and authenticity. To provide that tracking and assurance, the message handling unit checks the type header of each message, and will not proceed if required content is erroneous. The next sections examine some of these content requirements.
• a message consists of a type header and one or more optional documents, all encased in message headers used to route and process the message.
• the preceding section explained the various types of type headers recognized in the present system. This section explains what the present system, specifically the message handling unit and the title registry, does with documents included within a message.
• MIME Documents included in or "attached to" a message are incorporated into the message by a user system in the manner required by Internet MIME standards.
• the MIME methodology provides for transport of the document within the message through the digital communication channels used for e-mail.
• MIME does not provide for tracking of any documents traveling through the e-mail system, and it does not pass any information about the document other than the bare minimum necessary to move it through e-mail channels.
• the system keeps track of documents, although it does not scan them or examine their content.
• the information that the system keeps about a document consists of information about the message (or messages) in which it was contained, its form, and information necessary to determine whether one document purporting to be the same as another is indeed identical. That information is stored under a unique identifier for the document.
• a hash result is also known as a mathematical "message digest”, “cryptographic checksum”, or “seal” (in technical documents, without relation to the legal effect of a seal).
• the system tracks documents by a document identifier (also termed a "document ID”), which uniquely identifies its document from among all other documents logged in the system. Accordingly, the corresponding operation rule stipulates as follows:
• Operational Rule 3 Document ID Required For each document that a user sends into the system, that user shall specify a document ID in the prescribed form.
• a document ID is made up of a user identifier, a general identifier and a version indicator.
• the user identifier is the system user identifier of the user who first sent the document into the system. (User identifiers are explained in section 2.4.1). Both the base user identifier and any user division identifiers are included in the document ID, but not the extension of the user identifier (if an extension is used).
• the general identifier is a series of alphanumeric characters which uniquely identifies the document from among all documents sent into the present system by the user indicated in the user identifier forming part of the document ID.
• the version indicator is a portion of alphanumeric text indicating the version of the document.
• the above three sub-identifiers together comprise the document ID. Together, they form a unique identifier for the document, although either by itself may not necessarily be unique. For example, two distinct instances of the same document may share the same document ID, but must be identical.
• the sender creating the document ID can choose to include with it an on-or-off indicator to show that the sender regards the identified document as preliminary and nonbinding, a draft rather than a final, effective text.
• a sender or receiver of the document can review its movements through the present system by looking it up in the user support resources.
• the representative For a user representative to be able to review a document in the present system, the representative must (1) have a user identifier indicating that she is part of the user's organization and (2) be equal or senior to the sender or recipient of the document to be viewed within the division identifiers included in the relevant user identifiers, and (3) be listed in the user database as having a monitoring privilege.
• subsequent messages or documents may refer to the document by its document ID. If the draft indicator is on, a subsequent message may also replace the previously filed document with a new one bearing the same document identifier. However, if the draft indicator is off (indicating that the document is final), a new message never overwrites an older one.
• a new message may refer to a previously filed document by its document ID. and may send along a copy of the document. In such a case, when the message handling unit processes the new message, it will check the document copy and document ID to determine whether they are identical to the previously filed document and document ID. If they are not identical, the message handling unit returns a BNAk; for the SMsg sending in the nonconforming document. Otherwise, it returns a BAck if the message is valid in all other respects.
• Document type indicates the business role of the document as defined in the present system. As of this writing, the document type may be any of the document or message types defined for EDIFACT.
• Sending a message or performing any other significant action via the present system requires the sender to declare its user identifier.
• the present system checks for the user identifier and verifies the digital signature on the message according to that user identifier and the related public-key certificate. This verification process is to prevent one user from impersonating another without detection. It also ensures all users of the present system that only Enrolled persons governed by the Rulebook can send and receive Messages through the message handling unit. Thus, a user must supply a valid user identifier and digitally sign each i i-
• An information stream is the channel linking two digital information resources such as a Web browser and server. Signing an information stream consists of signing the packets (small, digital blocks of data) or groups of packets that comprise the stream.
• a user identifier is the name by which a system user is known within the present system. Because it is a name, the user identifier is different from an address, including an e-mail address, and other attributes of the user that may be recorded in the present system. In particular, an e-mail address does not. strictly speaking, identify a user; rather it identifies a location in a machine where e-mail can be received. An e- mail address, like a street address, a telephone number, and other location codes, may be a helpful attribute in identifying a company, but it is not the company itself. Any of those attributes may change without really affecting the identity of the company. That identity, as distinct from all other users and indeed, from all other companies, is what the user identifier signifies.
• each user identifier refers to a company, although often abbreviated.
• a user may add onto its user identifier a reference to a company division or department, and an "extension" noting whatever the user wishes
• Figure 8 illustrates optional additions to the base user identifier.
• the division identifiers and extension are each optional and determined by the user. They are entirely for the user's convenience and have no legal significance (see Rulebook). As Section 2.4.3 explains, other users may consider the identified user responsible for the message, regardless of what divisions or extensions are tacked onto the user identifier.
• the system service provider assigns each user a user identifier when the user is enrolled. Subsequent changes in the user identifier are rare, unless the user undergoes a fundamental organizational change such as a merger. The system service provider deactivates and will not recognize a user identifier after the user withdraws or is expelled, or while the user is suspended.
• a user In every message sent into the message handling unit, a user shall include its user identifier within the elements specified for it by the system.
• a user shall not attempt to include a user identifier in a message sent into the message handling unit when either:
• User identifiers are public to the user group. Any active user can look up any other user ' s identifier in the user support resources, and a user often keeps lists of common user identifiers as a ready address book for sending messages. Because users all have each other ' s user identifiers, the user identifiers are not a secure means of authenticating documents. Therefore, a user generally cannot reliably infer from the user identifier that a message or document is genuinely signed by or associated with the identified user. Rather, that inference should be drawn from the user ' s digital signature, if the digital signature can be properly verified by reference to a valid certificate. -DD-
• a digital signature results from a complex mathematical calculation, which produces a large number unique to both a given unit of data and a given private key.
• a digital signature After a digital signature is created, it can be verified as its signer's signature of the signed data by means of another mathematical process termed "verification".
• a computer runs a function and provides both the data that purports to have been signed and a certificate.
• the message handling unit verifies the digital signature on every message that it receives and forwards, and every user must verify the service provider's digital signature on every message that it receives purportedly from the message handling unit, or other system components under control of the service provider, if the user is to be certain that the message comes from the service provider.
• An accredited user system has a demonstrated ability to verify digital signatures, and often does so automatically as messages are received.
• a user may also digitally sign or encrypt a document sent within the message and forwarded on by the message handling unit.
• the present system does not verify any digital signature on such a document or decrypt it. That verification or decryption is left to the recipient of the document.
• a certificate in this specialized, digital-signature sense, means a digital record identifying the Holder of a private key, which is indicated, not by listing the private key (because the private key is a secret), but rather by listing its public key.
• a public key is a large number unique to its private key, and therefore, the public key can be used to indicate or identify its private key.
• the public and private keys of such a pair are mathematically related, but discovering the private key by knowing the public key is computationally infeasible.
• the digital signature verification yields a positive result, it demonstrates (1) that the digitally signed unit of data was not altered since it was digitally signed, and (2) that the digital signature was created with the private key corresponding to the public key listed in the certificate used for the verification. That certificate, in turn, identifies the Holder of that private key (the digital signer) as a particular user, and so the verifier can infer, based on the certificate, that the digital signature was created by that particular user.
• a digital signature is absolutely attributable to that user, if that digital signature can be verified using the public key listed in a certificate issued by an the system service provider and valid when the digital signature was created.
• a digital signature is deemed to be a particular user's if: (a) It is verified: The user relying on a digital signature relies at its own risk if the digital signature is not verifiable;
• the certificate was issued by an accredited certifier: A certificate which identifies a non-existent user or a user which does not have the private key indicated by the certificate will lead to inferences that are erroneous and potentially dangerous; and
• a message or document is "signed" when it bears a digital signature that can be verified as provided in the foregoing list. Further, if a message or document is signed, it satisfies any applicable legal requirements regarding its form (see Rulebook at 2.2.2).
• a digital signature associates a message with a particular private key. verification of that digital signature indicates which private key was used to create it, and a certificate indicate which user holds that private key. In light of proper verification, the message can be attributed to its signer.
• Operational Rule 6 Digitally Signing Messages Sent A user shall digitally sign each message sent via the message handling unit.
• Operational Rule 7 Requirements for Digital Signatures
• a user shall create its digital signature using a private key which corresponds to the public key listed in a certificate issued to the user by an accredited certifier.
• a user shall treat a message as of questionable authenticity if it is not signed. A user may disregard a message which is not signed.
• a document sent in a signed message is deemed signed as received in that message, regardless of whether it is signed as a separate unit.
• the present system acts as a disinterested operational intermediary between users.
• the process of sending a message from one user to another is a multi-step sequence as described in Section 2.2 above.
• the present section explains how digital signatures fit in that sequence.
• the sender digitally signs the message.
• the present system sends relays a message (including an acknowledgment) from one user to another, it digitally signs the message relayed from the original sender. Its digital signature on that forwarded message attests to the verifiability of the original sender's signature on the original message.
• This figure illustrates this sequential signing and messaging process.
• Figure 9 shows, the message flow, digital signing, and verification in the message handling unit proceeds by a sequence of steps as follows.
• a message is sent in the form SMsg.
• the originating user digitally signs and sends a message to the message handling unit for forwarding to the recipient.
• the message handling unit issues an acknowledgment in the form of a positive acknowledgment, referred to as a BAck or a negative acknowledgment referred to as a non-acknowledgment or BNak.
• the message handling unit verifies the sender's digital signature on the SMsg, checks its authenticity and form, and returns a BAck to the original sender if the message handling unit properly verifies the original sender's digital signature and finds the content in correct form. If the message handling unit fails to verify the digital signature properly or finds errors in form, it returns a BNack.
• the BAck or BNak message is signed by the system service provider.
• the message is forwarded with a forward message or FMsg. If the SMsg from the original sender bears a verified digital signature and is in technically proper form, the message handling unit returns a BAck to the original sender and sends the SMsg message on to its ultimate recipient as a FMsg.
• the FMsg is digitally signed by the system service provider. That digital signature indicates that the FMsg is from the service provider, and it further attests that the message handling unit has properly verified the sender's digital signature on the original SMsg, as the Operational Service Contract provides. On request, the system service provider will provide proof of that verification in accordance with the Operational Service Contract.
• the original user ' s signature and the original SMsg is available on request, from logs and records maintained by the service provider.
• a FMsg has a type header form differing from the SMsg that caused that FMsg to exist. Although the substantive content of the FMsg and its SMsg remains the same, the FMsg reflects its logging and tracking by the service provider run parts of the system. Consequently, it is not precisely identical in form to the SMsg, so the digital signature on the original SMsg cannot be verified against the resulting FMsg. (4) A user acknowledgment (UAck) or user non-acknowledgment (UNAk) is issued. On receipt of the FMsg, the recipient verifies the service provider ' s digital signature on the FMsg.
• the recipient's user system responds by sending a UAck to the message handling unit. If the verification fails or a technical fault is apparent, the recipient ' s user system returns a UNAk. The UAck or UNAk is digitally signed by the recipient of the FMsg before it is sent into the message handling unit.
• a delivery notification (DNot) or failure notification (FNot) is issued.
• DNot A delivery notification
• FNot failure notification
• the message handling unit receives a UAck. it relays a DNot to the sender of the original SMsg. If the message handling unit receives a UNAk. it relays a FNot to the original sender.
• the DNot or FNot bears the digital signature of the system service provider, and that digital signature attests to proper verifiability of the recipient ' s digital signature on the UAck or UNAk.
• the message handling unit handles a sent business refusal (SBRf) from the ultimate recipient in a way similar to a UNAk.
• SBRf sent business refusal
• Figure 10 is a flow chart illustrating the message handling unit flows with the digital signature steps shown.
• a private key is deemed to be certified to the user if the user's user identifier appears in a subfield of the subject field in a certificate.
• Other fields may also be appear within the subject field, at the user ' s option in cooperation with the issuer of the certificate. Those other fields can be used to manage individual representatives of the user and their keys and to trace and audit individuals ' activities within the user's organization.
• the user database records whether a user or a user representative is authorized to encrypt messages. If so, the user or user representative may encrypt message using a public key in a certificate listing the system service provider as subscriber. On receipt of that message, the message handling unit decrypts it using its private key. If the message handling unit sends on a message (such as an FMsg) based on the incoming message, the message handling unit encrypts it using the recipient ' s public key. The recipient can then decrypt it using its private key.
• a message such as an FMsg
• (b) contains a key Usage field which indicates that its public key may be used for encryption
• Public-key certificates are used in the message handling unit to establish the authenticity of messages and optionally providing for their confidentiality in transit.
• the authenticity service is provided by means of digital signatures, which depend on certificates to associate the digitally signed data with its signer.
• the certificate is used to assure that the person establishing the 59-
• confidentiality encrypts the confidential data by the public key of the person who is to break that confidentiality using his or her private key.
• the Issuer is the company that Issues certificates, in other words, who creates and digitally signs certificates, and then sends them to the subscribers listed in them.
• the Subscriber (or Signer) is the person listed in a certificate as the Holder of the private key corresponding to the public key listed in the certificate.
• the Subscriber is also the person who creates digital signatures verifiable by that certificate.
• the person is termed the "Subscriber” when referred to as the person listed in the certificate, and the "signer” when referred to as creating digital signatures.
• the Relying Party is the person to whom the signer of a digital signature, after creation of the digital signature, sends that digital signature with a message to the relying party, who verifies the digital signature.
• the Relying Party then ordinarily relies on the digital signature and the certificate to establish the authenticity of the digitally signed message.
• the Repository is a directory or database. In verifying the certificate, the Relying Party should obtain up-to-date information about its current validity. That information is ordinarily obtained from an online directory or database of certificates and information about them. That directory or database is termed a Repository. It provides support for the process of relying on certificates using information obtained from one or more Issuers and other sources.
• the only Accredited Issuer of certificates in the present system is the service provider, i.e. the operator of the present system. Other Issuers could also be accredited in due course.
• the service provider performs the issuer role pursuant to a contract with each user, and that contract provides the details of this relationship.
• the Service Provider and all Users are Subscriber/signers. Everyone who digitally signs messages sent via the message handling unit is the subscriber of a certificate by which that certificate can be verified.
• the Service Provider and all Users are Relying Parties.
• the message handling unit and users verify digital signatures and rely on them.
• the design of the message handling unit places its operator, the system service provider, in the role of relying directly on a user's digital signature, and then forwarding a message bearing its digital signature to another user, who in turn rely on that digital signature of the service provider. If the message handling unit cannot verify the digital signature on a message by reference to a certificate on file, the message handling unit returns a BNak to the sender and does not process the message further.
• the message handling unit also digitally signs all messages that it sends. It digital signature is verifiable by a certificate distributed to all users. This two-stage process is described in greater detail in section 2.4.2.2.
• the service provider is the Repository.
• the service provider keeps all user certificates in its user database.
• the message handling unit verifies a digital signature, it obtains the needed certificate from the user database.
• a user verifies the service provider's digital signature on a message, it obtains up-to-date information about the relevant certificate by checking a repository.
• This basic structure oversimplifies what happens in the upper part of the diagram, however.
• the Issuer relies on information obtained from others and on the enrollment process in which users enter into contracts for use of the present system and membership in the user group.
• a certificate is a digital record which identifies a named person with a public key, and contains other information needed to manage and limit its use.
• An Issuer undertakes significant responsibility for the information in a certificate, because Relying Parties rely on the certificates to establish the authenticity of messages.
• the authenticity of a certificate is established by verification of a digital signature on the certificate.
• a certifier digitally signs it.
• the verifier When using the certificate to verify a digital signature, the verifier must verify the digital signature on that certificate to determine whether the certificate is authentic.
• the verifier To verify the digital signature on that certificate, the verifier must refer to another certificate to obtain the necessary public key and subscriber identification. The digital signature on that other certificate must likewise be verified to establish its authenticity.
• Verification thus includes a chain reaction of verifications of the digital signatures on certificates along a generation line ending with a public key that is reliable without being certified.
• Figure 12 illustrates this chain reaction, which is sometimes termed "certificate chaining " .
• the number of "links " in a certificate chain in other words, the number of certificates to which a verifier must refer in order to verify a digital signature, is determined by the Issuer of the certificate and its antecedents in the chain. The number may vary from the three certificates shown in the illustration.
• the customer-provider relationship between a subscriber and a certifier is termed a "certification account" in the present system.
• the certifier For each certification account, the certifier (a) enters into a contract with the subscriber, (b) confirms the accuracy of facts to be used in certificates, and (c) keeps a certificate account history.
• the certifier opens a certification account after a user is enrolled in the present system pursuant to a service contract with the service provider. Precisely what is required to open that account depends on that contract.
• the certifier or subscriber may close the certification account as provided in their contract. Closure of the account generally terminates the contract and vice versa.
• Closing a certification account does not terminate the enrollment of the subscriber as a user of the present system, although it may affect the ability of the user to use the system as a practical matter, because a valid certificate is required to send messages via the message handling unit.
• Certificate Life Cvcle Figure 13 is a flowchart showing how a certificate begins when issued, becomes valid when accepted by its subscriber, and terminates when it expires or is revoked. The subsections describe the events shown in the flowchart in greater detail.
• an initial certificate is issued based on a paper and ink-signed request together with certain information provided in digital form. Because the account is newly opened, the subscriber probably has no means of digitally signing a certificate request, so this initial or "bootstrap " certificate must be requested on paper. Ordinarily, this first certificate becomes the initial account maintenance certificate.
• the certifier may publish valid certificates in a repository, if the subscriber permits or the contract between the subscriber and certifier provides for publication. If the safekeeping of the subscriber ' s private key becomes compromised or in doubt, or if the subscriber no longer wishes to be bound by its obligations with respect to a certificate, the subscriber should request the certifier to revoke the certificate.
• Revocation invalidates the certificate, so that neither the subscriber nor the certifier are bound by it any longer.
• the message handling unit performs this check when it verifies a digital signature.
• a user receives a digital signature, including the service provider ' s digital signature on a message forwarded from the message handling unit, the user must verify that digital signature and check for revocation of the certificate used for that verification.
• the subscriber's user system ordinarily checks for revocation automatically, without intervention by the subscriber, but the subscriber nevertheless bears responsibility to assure that it does so.
• a subscriber When required to verify a digital signature, a subscriber shall check the Repository listed in the crlDistributionPoints field in the certificate (or in the issuer field if crlDistributionPoints is not in the certificate) to determine whether notice of revocation has been posted for a certificate necessary for that verification.
• the subscriber When the subscriber encrypts information using the public key listed in a certificate, the subscriber should also check whether the certificate is revoked, although that check is not currently mandated by an operational rule.
• Operational Rule 12 Time of Revocation and Digital Signature A certificate is revoked at the time listed in the notice of revocation.
• the decision-maker In determining when a digital signature was created, the decision-maker considers all relevant facts and circumstances, including the times ascribed to the message or document bearing the digital signature.
• a certifier never states in a notice of revocation that the time of revocation is before the actual time when notice of revocation is published in the appropriate repository.
• the contract between the certifier and the subscriber should specify how soon, after receipt of a request, the certifier must effect the requested revocation through publication.
• Publication into a Repository is now described.
• a repository is an online directory or database containing notices of revocation, certificates, and other information useful in the process of relying on certificates.
• the repository is listed as the location where notice of revocation will be posted (the crlDistributionPoint) for all certificates issued by the service provider.
• the message handling unit checks that repository for notice of revocation of a certificate when verifying a user ' s digital signature on a message sent through the message handling unit.
• Title Registry is a central electronic database of information relating to electronic bills of lading. In the following, it is described how the title registry processes electronic bills of lading. A basic knowledge of traditional paper bills of lading is assumed.
• the Title Registry is a database application for recording and transferring the rights and obligations contained in an electronic bill of lading (eBL).
• the Title Registry does not store or read the eBL document but records information about the eBL contained in the Title Registry instruction.
• the bill of lading document itself is simply an electronic version of the bill of lading that is used today.
• the Title Registry instruction together with the eBL is referred to as a BBL (see Figure 31).
• the BBL and the Rule Book provide the functional equivalent of a traditional paper bill of lading.
• the Title Registry For each BBL. the Title Registry creates a set of records containing: (1) the parties (user IDs) involved; (2) the function requested/completed; (3) the type of eBL; and (4) the eBL identifier. Creation of or changes to a Title Registry record are made by instructions issued by authorized parties. These instructions are sent as normal system messages. When the message handling unit receives a message containing a Title Registry instruction, it forwards the message to the Title Registry. The Title Registry validates the information, creates or updates the records, and returns a result to the message handling unit. The message handling unit adds the result to the sender ' s message and forwards the new message to the recipient. To avoid receiving instructions out of sequence, the Title Registry only permits a single instruction in a system message.
• Paper bills of lading typically come in sets of three "originals".
• the concept of multiple originals is not necessary in the present system because the message handling unit guarantees the original content of the carrier's or NVOC's (Non Vessel Operating Carrier ' s) eBL (using digital signatures) and the Title Registry records all rights and obligations in a single place.
• the eBL can be copied to multiple parties for information, but the ability to act is determined by the status of the BBL in the Title Registry.
• the Title Registry In addition to recording information and controlling access to records, the Title Registry also carries out four additional, functions, namely (1) automatic notifications; (2) assurance that the eBL is enclosed when required; (3) management of amendments to the BBL; and (4) conformance with the rules as stated in the Rule Book. Maintenance of endorsement chains. When processing is completed in the Title Registry, a result is issued to the sender and receiver(s).
• a bill of lading is a document signed by a carrier and which serves as a receipt for goods in carriage, a contract for that carriage, and a document entitling the holder to delivery of the goods from the carrier. Functionally, the bill of lading moves from the carrier to the shipper and ultimately to the buyer of the goods, and it may pass through the hands of others such as banks along the way. As they come into possession of the bill, these persons may acquire rights and obligations in relation to it.
• the electronic bill of lading retains the traditional business meaning and functions of a bill of lading, while replacing its paper medium with electronic records.
• an electronic bill of lading consists of an electronic record of a document in combination with transactional information.
• the document part represents a bill of lading.
• the document, digitally signed by the carrier has a document ID and the other properties of a document as described in section 2.3, including the hash result that can be used to determine whether the document is identical to another.
• the bill-of-lading document is digitally signed as part of the message creating the electronic bill of lading. As with all documents included in digitally signed messages, the digital signature applies to the entire message, rather than to the document specifically.
• the bill-of-lading document is sent into the central parts of the system maintained by the service provider via the message handling unit, where it is recorded by its document ID. This document is termed the "electronic bill of lading text" or eBL text.
• the transactional information is related to the associated bill-of-lading document.
• the title registry For each electronic bill of lading, the title registry maintains a database record in the form of a table which is known as a "title registry record".
• the title registry record lists the user identifiers of users who occupy certain roles in relation to the electronic bill of lading, as well as certain other data.
• the rulebook interprets these role specifications to create certain rights and obligations in relation to the electronic bill of lading. Users empowered to change the data in the title registry record do so by sending title registry instructions in the type headers of messages sent via the message handling unit.
• the electronic bill of lading is thus (1) an eBL Text, a document reading like a conventional, paper bill of lading, combined with (2) a database record, termed a title registry record, kept by the system service provider to record the transactions in relation to that document by which system users acquire rights and obligations under it pursuant to the rulebook.
• Originator is the party that creates the BBL (carrier or NVOC). This field is mandatory.
• Surrender party is the party to whom the BBL will be surrendered (the agent of the carrier). If the Originator is also the Surrender Party, this field is not used.
• Shipper is the party that contracts with the Originator for carriage of the goods. This field is mandatory.
• the Holder is the party that is analogous to the person who would have physical possession of the eBL if it were a paper document.
• the Holder is the party that is entitled to receive the paper bill of lading if the BBL is switched to paper.
• BBL has no named To Order party or Consignee (blank endorsed), the Holder is described as a Bearer Holder. Either a Holder or a Pledgee Holder is mandatory.
• Pledgee Holder is the party that has a pledge on the BBL.
• a Pledgee Holder is a bank that has provided risk financing for a trade transaction covered by the BBL (typically through a letter of credit).
• a pledge enables the bank to assume the rights (subject to the liabilities) relating to the BBL in the event of a default.
• the Pledgee Holder is described as a Pledgee Bearer Holder. Either a Holder or a Pledgee Holder is mandatory.
• To Order Party is the party that is the endorsee of a transferable (negotiable)
• the Title Registry can also maintain a blank-endorsed (no named To Order party) transferable BBL. This field is optional.
• Consignee is the party that is normally the buyer of goods and is named on a non-transferable (non-negotiable) BBL. This field is optional. Moreover, any User ID (registered) can be a party in a Title Registry record.
• the rights and obligations of the users in relation to an electronic bill of lading are grouped into roles that reflect both the traditional functions of a bill of lading and the way those functions have been replicated by the operation of the title registry, which keeps a record of those roles as data fields within a title registry record.
• the title registry stores information about the status of the electronic bill of lading and the rights and obligations of system users in relation to it.
• Figure 14 depicts in a simplified way the logical structure of a title registry record. The fields in this illustration are explained below in this section.
• the content of a role field must be a user identifier, including all user division identifiers (the parts of the user identifier indicating departments or other subunits of the user), but without the user identifier extension. Although a full user identifier is listed, any person able to digitally sign on behalf of the user can send a title registry instruction to effect a change in the title registry for the user, unless limited by the user ' s own system. Whilst user division identifiers are listed in the title registry record, they are ignored when the title registry carries out title registry instructions.
• a user takes on a role in the title registry when a user having the requisite power designates itself or another user to that role.
• the processes for designating users to roles are explained in section 4.4. Section 4.2 describes the roles themselves.
• the Originator is the contracting carrier, the user that creates the electronic bill of lading by agreement with the Shipper.
• the role of Originator has various properties in the title registry as now described.
• any user can be entered into the field in a title registry record for an Originator (carrier), although as a real-world, practical matter, only certain users will be able to act as carriers in fact.
• Originator carrier
• An Originator designates itself as such when creating an electronic bill of lading as described in section 4.4.2.
• An Originator has the power to: (1) create an electronic bill of lading, and in so doing, designate its Shipper, initial Holder, and its initial To Order Party or its
• a Surrender Party is the person appointed by the Originator to receive the surrendered electronic bill of lading.
• the title registry uses the term "surrender" to mean the final transfer of an electronic bill of lading to its Originator (or Surrender Party) when delivery of the shipped goods is to occur.
• the Surrender Party role has a number of properties in the title registry as now described.
• Any user can be designated the Surrender Party (i.e., have its user identifier placed in the Surrender Party role field). Only one user identifier can be designated the Surrender Party for an electronic bill of lading.
• Designation of a Surrender Party is optional at the Originator's (carrier's) discretion. If no Surrender Party is specified, the Originator (carrier) will receive the surrendered electronic bill of lading. Only the Originator of the electronic bill of lading can designate the Surrender
• the Surrender Party is entered permanently and cannot be changed by normal title registry functions, although it can be changed by amendment of the electronic bill of lading by its Originator as described in section 4.4.5.
• the Surrender Party does not have the power to perform any title registry functions in its role as Surrender Party.
• a Shipper is the person contracting with the originator/carrier for the shipment of the goods in question. Often, the Shipper is the seller or exporter of the goods.
• the Shipper role field has a number of properties in the title registry as now described.
• Any user can be designated the Shipper (i.e., have its user identifier placed in the Shipper role field).
• the Originator who creates the electronic bill of lading designates the Shipper, in accordance with its agreement with that Shipper. Once designated, the Shipper is permanently entered and cannot be changed using normal title registry functions, although it can be changed by amendment of the electronic bill of lading by its Originator as described in section 4.4.5.
• a Shipper does not have the power to perform any title registry operations simply by virtue of its role as Shipper.
• a Shipper ' s powers derive from other roles besides being a Shipper.
• a Shipper can, for example:
• ( 1 ) Designate a Holder or Pledgee, if the Shipper is also simultaneously Holder of the electronic bill of lading; (2) Designate a Consignee or successive To Order Party, or blank endorse the bill so as to make it transferable by changing its Holder, if the Shipper is also simultaneously the bill's Holder-To Order or Bearer Holder;
• a Shipper who has ceased to be the Holder of the electronic bill of lading cannot perform any functions in relation to that bill.
• a Consignee is the buyer or importer, the person who is to receive the goods according to a non-transferable electronic bill of lading.
• a Consignee is designated for a transferable electronic bill of lading, the bill becomes non- transferable.
• the Consignee role field has various properties in the title registry as now described.
• Any user can be designated the Consignee (i.e., have its user identifier placed in the Consignee role field).
• the Consignee of an electronic bill of lading Only one user identifier can be designated the Consignee of an electronic bill of lading.
• the present system does not require a Consignee to be designated.
• the Originator can designate a Consignee of the bill, if the Originator is not designating a To Order Party for that bill.
• a To Order Party After a To Order Party has been designated for a bill, its current Holder-to-order or Bearer Holder can designate a Consignee.
• the Consignee is entered permanently and cannot be changed using normal title registry functions, although it can be changed by amendment of the electronic bill of lading by its Originator as described in section 4.4.5.
• the Consignee which is also simultaneously the Holder of an electronic bill of lading has the power to: ( 1 ) Request amendment of the electronic bill of lading;
• a To Order Party is the endorsee of a transferable electronic bill of lading.
• the role field for a To Order Party in the title registry has various properties as now described.
• Any user can be designated a To Order Party (i.e., have its user identifier placed in the to-order role field).
• the Originator may designate its initial To Order Party (as the Shipper instructs).
• a Bearer Holder may also designate a To Order Party by an instruction removing the blank endorsement on the bill and entering a user identifier in the To Order Party role field. Once designated, a To Order Party may designate a successor by a process analogous to endorsement, as described in section 4.4.3.3.
• a To Order Party Once a To Order Party has been designated, it may be changed by the process described in section 4.4.3.3.
• a user which is the current To Order Party and simultaneously Holder i.e., a
• a To Order Party cannot perform any operation in the title registry unless the To Order Party is also simultaneously the Holder of the affected electronic bill of lading. Such a To Order Party that is also the Holder is termed a "Holder-To Order".
• a Bearer Holder is analogous to the person in physical possession of a bearer bill of lading, i.e., one that is transferable by changing physical possession of the bill.
• a Bearer Holder is created by blank endorsing an electronic bill of lading and then designating a Holder as described in section 4.4.3.1. Thus, a Bearer Holder is simply the Holder of a blank endorsed electronic bill of lading.
• Any user can be designated a Bearer Holder (i.e., have its user identifier placed in the Holder role field of a blank endorsed electronic bill of lading). Only one user at a time can be the Holder (and thus, a Bearer Holder) of an electronic bill of lading.
• a Bearer Holder i.e., have its user identifier placed in the Holder role field of a blank endorsed electronic bill of lading. Only one user at a time can be the Holder (and thus, a Bearer Holder) of an electronic bill of lading.
• a Bearer Holder exists only if an electronic bill of lading has been blank endorsed. Blank endorsement is also optional.
• An Originator carrier, in creating an electronic bill of lading, or the current
• Holder-To Order can blank endorse it.
• Successive Holders of an electronic bill of lading are designated as described in section 4.4.3.1.
• designating a Holder is equivalent to designating its Bearer Holder.
• the current Bearer Holder may designate a successor by making another user the Holder of the electronic bill of lading.
• the Bearer Holder may also eliminate its role by removing the blank endorsement and designating a To Order Party or Consignee.
• the current Bearer Holder of an electronic bill of lading has the power to: (1) Designate a new Bearer Holder (by designating a new Holder for the blank endorsed electronic bill of lading).
• the Bearer Holder cannot, however, blank endorse the bill, because it is already blank endorsed;
• a Pledgee is a financial institution which has an interest in the electronic bill of lading based on financing of the shipped goods or assuring payment for them.
• the Pledgee role field has these properties in the title registry: Any system user identifier can be designated a Pledgee (i.e., placed in the Pledgee role field).
• a Holder-To Order or Bearer Holder can designate a Pledgee.
• One Pledgee may also name another, succeeding Pledgee. Whenever a Pledgee is designated, the
• Pledgee is also automatically designated the Holder of the pledged electronic bill of lading. So long as the Pledgee remains Pledgee, it is also Holder. A Pledgee which is also simultaneously the Holder is termed a Pledgee Holder.
• a Pledgee can designate a successor, or may delete its user identifier from the Pledgee role field and thereby relinquish its pledge.
• a Pledgee which is also simultaneously the Holder i.e., a Pledgee Holder
• the Holder is the party who is entitled to physical possession of the bill-of- lading document, if the electronic bill of lading is switched to paper.
• the Holder role field has various properties in the title registry as now described.
• Any system user identifier can be designated a Holder (i.e., have its user identifier placed in the Holder role field).
• the Holder of the electronic bill of lading may change as long as the bill is active (i.e., from the time when the bill is created until it is surrendered or switched to paper).
• a Holder has the power to: (1) Designate a Pledgee Holder or a successive
• An electronic bill of lading passes through a life cycle of creation and termination.
• the operations that the title registry can perform on the electronic bill of lading vary depending on which state the electronic bill of lading is in.
• the electronic bill of lading has three operational states. It is created into an active state, may transfer into a suspended state while an amendment is pending, and also has a terminated state which results from the electronic bill of lading having exhausted its functionality as a transaction support instrument.
• the active state begins when an Originator properly creates an electronic bill of lading.
• the active state is interrupted when the electronic bill of lading enters suspended status indicating an unresolved amendment request.
• the active state ends when the electronic bill of lading is terminated.
• the electronic bill of lading can be transferred as described in section 4.4.3., or pledged, amended, switched to paper, or surrendered.
• the suspended state is entered if a party with the power to request an amendment of the electronic bill of lading does so.
• the suspended state ends, and the active state is resumed, when the Originator denies the request for amendment, or grants the request and completes the amendment. While an electronic bill of lading is in the suspended state, no operations are possible other than the granting or denying of a request for amendment.
• the terminated state is entered when a party with the necessary power surrenders the electronic bill of lading or switches it to paper. Entry of the terminated state is irreversible. Moreover, no operations are possible on an electronic bill of lading in the terminated state.
• Section 4.4. below describes in more detail the operations that cause an electronic bill of lading to change between these operational states. 4.3.2. Transferability States
• the criterion differentiating the active, suspended, or terminated status of operational activity is based on the stages in the life cycle of an electronic bill of lading and the operations that should be permitted at each stage.
• the criterion differentiating the typology described in this subsection is the transferability of the electronic bill of lading. Since transfers are operations consisting of designating another user in a particular role, transferability differs only perhaps conceptually rather than functionally from the operational states.
• the system distinguishes between three states of transferability, namely non- transferable, transferable and pledged.
• a non-transferable state is entered when an Originator, current Holder-To Order or Bearer Holder designates a Consignee for an electronic bill of lading. Entry into the non-transferable state is irreversible and permanent as far as transferability state is concerned, and ends only when the electronic bill of lading enters the terminated state by surrender or a switch to paper. Transferability state changes are not possible with an electronic bill of lading in the non-transferable state.
• a transferable state is entered when an Originator designates a To Order Party or blank endorses the new electronic bill of lading. Transferability is interrupted while a bill is pledged. The transferability state ends when the bill is made non-transferable by designating a Consignee or when the bill enters the terminated operational state.
• the current To Order Party or Bearer Holder of a transferable bill may designate a successive To Order Party or Bearer Holder, designate a Consignee (making the bill pledged), or designate a Consignee (making the bill non-transferable).
• a pledged state is entered when a Holder designates a Pledgee for a transferable electronic bill of lading.
• the pledged state ends when the Pledgee enforces or relinquishes the pledge. In the pledged state, enforcement or relinquishment of the pledge are possible.
• the bill can also be amended or switched to paper. Transfers (e.g. designation of a successive Holder, To Order Party, or Consignee) are not possible.
• Name Holder transfers holdership in an existing BBL record.
• Name Pledgee Holder names a Pledgee Holder or transfers a pledge in an existing BBL record.
• Blank Endorse removes the To Order party in an existing BBL record.
• Enforce Pledge makes the Pledgee Holder the Holder and To Order party (if one is named) of a transferable BBL, in an existing BBL record.
• Request Amendment requests the Originator to amend the BBL(s) related to the existing BBL record(s).
• reference numeral 1 denotes the SMsg message sent from a User to the Message Handling Unit of the Central System
• reference numeral 2 denotes the input from the Message Handling Unit to the Title Registry of the Central System
• reference numeral 3 denotes the return code from the title registry regarding success of the database update
• reference numeral 4 denotes a notice in the form of a FMsg to the affected user (if required)
• reference numeral 5 denotes a DNot notice sent to the sender of the SMsg regarding completion.
• the user initiating the operation sends a message having a type header in the SMsg form to the message handling unit. That SMsg message includes in its type header an element labeled Instruction as illustrated in Figure 16.
• the sending user must often include the eBL Text as a document in the message.
• SMsg message need not indicate the recipient of an FMsg message, because the message handling unit and/or title registry will determine automatically as described in the sections below which users are to be notified and send them FMsg messages, regardless of which recipients the sender indicates in the SMsg message.
• the message handling unit receives an SMsg with the Instruction element, it returns a BAck (or BNak if the SMsg message is technically invalid as defined by prescribed criteria.
• the message handling unit passes an Instruction based on its Instruction element to the title registry, which processes the Instmction as explained below with regard to each specific type of Instruction. After processing the Instruction, the title registry returns to the message handling unit a code indicating whether the processing succeeded or failed.
• the title registry After the title registry has processed the input from the SMsg Instruction, it reports the action to affected users (other than the sender of the SMsg) in the form of forwarding messages each of which has a type header in the FMsg form. Which users receive such FMsg messages is explained below for each title registry operation.
• the message handling unit After the message handling unit forwards the FMsg messages to the affected users and they each return a UAck message, the message handling unit returns to the sender of the original SMsg message a delivery notification DNot message indicating that the title registry carried out the instmction and sent the related FMsg notifications to affected users. If one or more of them fails to acknowledge the FMsg notification by returning a UAck. the message handling unit returns a FNot to the sender of the SMsg message.
• the SMsg message has the same overall structure as any other message, except that its SMsg type header contains an element named Instruction, as illustrated in the simplified example in Figure 16. The Instruction element contains the information necessary to update the title registry, as explained in greater detail in the subsections of this section. Operations involving the title registry and the SMsg messages, and
• Instruction elements that effect them can be classified into the categories of: (a) creation, (b) transfers, (c) pledges, (d) amending, (e) surrendering and (f) switching to paper.
• Pledges result from financial institutions designating themselves as pledgees.
• a pledge makes the electronic bill of lading analogous to collateral for credit that the institution has extended in financing the sale of the shipped goods. While designated as Pledgee, the financial institution can enforce or relinquish its pledge.
• Amending of an electronic bill of lading is authorizable by the Originator of an electronic bill of lading on request by certain users. Surrendering occurs after the electronic bill of lading has ran its course. The electronic bill of lading is surrendered to the Originator (carrier) or the Surrender Party (the carrier ' s agent, if there is one). The Originator or Surrender Party will then set in motion the procedure for delivery of the shipped goods.
• Switching to paper can be performed if necessary to convert an electronic bill of lading to paper form at the request a user in an appropriate role.
• an Originator When creating an electronic bill of lading, an Originator shall: (a) complete the title registry instruction by:
• (c) sign and send a message (including the title registry instruction created under sub-rule (a) above and the eBL Text to the title registry via the message handling unit.
• the Originator (carrier) creates an electronic bill of lading.
• the present system does not distinguish between users who are Originators and may create electronic bills of lading and users who cannot.
• the title registry does not restrict when an Originator may create an electronic bill of lading.
• FIG. 17 illustrates creation of an electronic bill of lading. Creation takes place by the following steps:
• the Originator creates a message to the message handling unit.
• the message has a type header in the SMsg form.
• the title-registry is then supplied with the required information.
• the Originator ' s user system inserts the subelement CreateBBL., which directs the title registry to create a new electronic bill of lading.
• the Originator specifies a number of parameters, as follows: (a) the Originator supplies a document ID for the accompanying eBL Text;
• the Originator indicates whether the new electronic bill of lading is to be "negotiable” (i.e. transferable as described in section 4.3.2.) or "non-negotiable” (non- transferable as described in section 4.3.2.).
• the title registry checks this indicator of transferability against roles designated for the electronic bill of lading to determine whether the role designations are consistent with the "negotiable" or "non-negotiable" listing for the bill:
• the Originator also includes its own user identifier to indicate which user is sending the message and creating this electronic bill of lading: (d) the Originator may also specify a Surrender Party, depending on whether the Originator intends to authorize an agent to act on its behalf when the bill is surrendered;
• the Originator specifies the user identifier of the Shipper of the new electronic bill of lading; (f) the Originator also specifies the initial Holder of the new bill; and
• the Originator may specify either a Consignee or a To Order Party, or the
• Originator may Blank Endorse the new bill and thereby make its Holder a Bearer
• the Instmction must also indicate that the bill is "negotiable”. If a Consignee is designated, the Instmction must also indicate that the bill is to be "non-negotiable " .
• the Originator includes in the message (or "attaches" to it) a document that is to serve as the text of the bill of lading, i.e. the eBL Text.
• This document must have a document ID and satisfy the other requirements, including uniqueness, set out in section 2.3 above.
• the title registry stores this document as provided in the applicable document retention schedule. It is generally unnecessary to attach multiple instances of the same document by analogy to the practice of issuing multiple counterparts of a single bill of lading on paper. Because all users who need to see and change the electronic bill of lading can do so, users can forego the confusion and disputation that attends multiple copies.
• the Originator then digitally signs the message containing the eBL Text and the initial role designations and sends the message into the message handling unit.
• the message handling unit checks the message for conformity with the message validity requirements, including a check of its authenticity through verification of the Originator ' s digital signature on the message.
• the title registry and/or message handling unit also checks the form of the message. If the digital signature cannot be verified or any other fault in the message is detected, the message handling unit returns a BNak to the Originator.
• the title registry sends a message through the message handling unit having an FMsg type header to the Shipper and Holder of the new electronic bill of lading, and to the Surrender Party, if one is designated.
• the message serves as notice of the creation of the new electronic bill of lading and of the rights and obligations associated with designations of relevant users in the new electronic bill of lading.
• the title registry then confirms the successful creation of the electronic bill of lading by returning a message through the message handling unit having a BAck type header to the Originator who created the new electronic bill of lading. That type header includes a report from the title registry of the actions it has taken.
• the information entered into the title registry when an electronic bill of lading is created including the eBL Text and designations, all remains in the title registry and available to permitted users for the time specified in the applicable retention schedule.
• Entry of the new electronic bill of lading is also noted in the chronological logs of message flow, and that log is retained for as specified in the applicable retention schedule.
• Transfers of an electronic bill of lading pass rights and obligations from one user to another.
• a user makes a transfer by designating another user in a role field.
• the present system recognizes four transfers based on prior practices with paper bills of lading, namely: transfer by one Holder to a successor, transfer to a Consignee, transfer to a To Order Party, and transfer to a Bearer Holder by blank-endorsing.
• transferring the rights of a Holder is analogous to transferring the physical possession of the bill of lading, if it were in tangible form. This transfer consists of the current Holder designating a successor.
• the transfer is similar to making a paper bill of lading "straight" or "non-negotiable".
• An electronic bill of lading with a Consignee is not transferable to a To Order Party or capable of being blank endorsed.
• the Consignee, if also Holder, can surrender the electronic bill of lading and take delivery of the goods.
• designating a To Order Party is similar to issuing a negotiable paper bill of lading to the designee ' s order, and handing it to the Holder (probably the Shipper).
• the To Order Party is not also Holder and thus Holder-to-order, its capabilities are very limited.
• an existing Holder-to- order or Bearer Holder designates a Holder-to-order, the effect is analogous to endorsing the bill of lading to a specified endorsee.
• blank endorsement flags the electronic bill of lading as being blank endorsed and eliminates the existing To Order Party. It leaves the electronic bill of lading transferable simply by changing its Holder. It is thus analogous to a paper bill transferable by bearer.
• the Holder is analogous to the person who would have physical possession of the electronic bill of lading, if it were a tangible document. Therefore, the Holder the person who is entitled to receive the paper bill of lading, if the electronic bill of lading is switched to paper. Further, if the bill is blank endorsed as described in section 4.4.3.4.. its Holder is a Bearer Holder described in section 4.2.6. Thus, designating a new Holder of a bill which is not blank endorsed indicates who will henceforth be entitled to receive the paper bill when the switch-to-paper directive is carried out. However, if the bill is also blank endorsed, designating a Holder is equivalent to designating a Bearer Holder.
• the initial Holder is designated when the electronic bill of lading is created. Thereafter, the bill always has a Holder, because the title registry can only substitute user identifiers in the Holder role field. It does not empty the field of its content.
• the instmction for designating a Holder may be combined with either the instmction for designating a To Order Party, designating a Consignee, or blank- endorsing the electronic bill of lading. It is always automatically combined with designation of a Pledgee: so that the user designated as Pledgee is always also designated as Holder.
• the designation of a Pledgee as Holder is automatic and need not be included in a title registry instmction.
• the current Holder of that electronic bill of lading shall: (a) Complete a title registry instruction designating the new Holder for that electronic bill of lading; and
• a user can designate a Holder only if the user is either the current Holder of the electronic bill of lading, or an Originator creating a new electronic bill of lading.
• a Holder may designate a new Holder only when the electronic bill of lading is active as described in section 4.3.1. Further, if the electronic bill of lading is pledged, the Holder may designate a new Holder only if the designator is also Pledgee and the user designated the Holder is also simultaneously designated as the Pledgee.
• An Originator may designate a Holder only when creating the electronic bill of lading.
• the appropriate user creates a message to the message handling unit.
• the user identifier is then tagged by the user designating the new holder in the create message by listing the new Holder's user identifier within appropriate tags in the Instruction element of the message type header. Further tagged data, such as the Document ID of the bill to be affected, is also required there.
• the message handling unit checks the message's authenticity by verifying the sender's digital signature.
• the message handling unit and/or title registry also check the form of the message. If the message handling unit and title registry cannot properly verify the digital signature or does not find the form of the message correct, the message handling unit returns a BNak.
• the title registry is updated by changing the content of the Holder role field to be the user identifier of the new Holder listed in the message type header. The former Holder's user identifier is removed from the title registry record for that bill. (6) The title registry then confirms the successful designation of the new
• That type header includes a report from the title registry of the actions it has taken.
• the title registry notifies the newly designated Holder of its designation. Designating a new Holder generally does not affect the status of an electronic bill of lading. However, if the designation occurs as part of creating the bill, the completion of the creation process leaves the bill in the active state.
• the title registry record containing the designation of the Holder remains in the title registry and available to permitted users for the time specified in the applicable retention schedule.
• the title registry instmction effecting the designation is also recorded in the chronological log of message flow, and that log is retained for as specified in the applicable retention schedule.
• the Consignee of an electronic bill of lading is analogous to the Consignee of a conventional non-negotiable bill of lading.
• Designating a Consignee makes the electronic bill of lading non-transferable from that point on. Designation of the Consignee ordinarily occurs only once in the lifetime of an electronic bill of lading, so once the Consignee role field is filled in. its content remains unchanged.
• An Originator may designate a Consignee in creating an electronic bill of lading (see Operational Rule 13).
• Consignee Holder the Holder of an electronic bill of lading shall perform the procedures required in Operational Rules 14 and 15.
• the title registry instructions designating the same user as both Consignee and Holder may be sent within the same message.
• An Originator may designate a Consignee when creating the electronic bill of lading, but not after the present system has returned an acknowledgment notifying the Originator that the bill has been successfully created.
• the current Holder-to-order or Bearer Holder of the electronic bill of lading may also designate a Consignee.
• an Originator must be creating the electronic bill of lading to designate its Consignee.
• the current Holder-to-order or Bearer Holder may designate a Consignee only if the bill is active and transferable.
• Consignee's user identifier within appropriate tags in the Instruction element of the message type header. Further tagged information, such as the document ID of the bill to be affected and an indication that the bill is "non-negotiable", is also required there;
• the message handling unit checks its authenticity by verifying the sender's digital signature.
• the message handling unit and/or title registry also checks the form of the message. If the message handling unit and/or title registry cannot properly verify the digital signature or finds the form incorrect, it returns a BNak;
• the title registry changes the content of the Consignee role field from empty to the user identifier of the new Consignee listed in the message type header;
• the title registry then confirms the successful designation of the Consignee by returning via the message handling unit a DNot message having a BAck type header to the sender. That type header includes a report from the title registry of the actions it has taken.
• the Title Registry notifies the new Consignee of its designation. If the Consignee is also the current Holder (perhaps through the same message as the one effecting the Consignee designation), the notice includes the following text notice: "You have been designated as the Holder of this electronic bill of lading in accordance with the Rulebook. By virtue of your capacity as Holder of this electronic bill of lading, in addition to your designation as a To Order Party. Consignee, Bearer or Pledgee, we (the Service Providers) confirm on behalf of the Originator of this electronic bill of lading (the carrier) that the goods are now held to your order.”
• the new Consignee may reverse the designation by returning to the Title Registry a message with a header in the SBRf form within the timeout period of 24 hours beginning when the title registry record is updated with the new designation, provided that the SBRf message is sent before the designated user takes any other action in relation to the bill.
• it may accept the appointment by returning a UAck, letting the timeout period elapse, or taking action in relation to the bill other than returning an SBRf.
• Designating a Consignee makes the electronic bill of lading non-transferable beginning when the title registry is updated.
• the title registry record containing the designation of the Consignee remains in the title registry and available to permitted users for the time specified in the applicable retention schedule.
• the title registry instmction effecting the designation is also recorded in the chronological log of message flow, and that log is retained for as specified in the applicable retention schedule.
• the To Order Party of an electronic bill of lading is analogous to the endorsee of a conventional bill of lading. Like an endorsee, the To Order Party can further transfer the bill, if the To Order Party also holds it.
• the process analogous to endorsement to order consists of designating a successive To Order Party and Holder (i.e., a Holder-to-order).
• Operational Rule 17 Designating a To Order Partv A.
• An Originator may designate a To Order Party in creating an electronic bill of lading (see Operational Rule 13).
• a Pledgee Holder, Bearer Holder, or Holder-to- order of an electronic bill of lading shall:
• Operational Ride 18 Designating a Holder-to-order To designate a Holder-to-order, a Pledgee Holder, Bearer Holder, or existing Holder- to-order of an electronic bill of lading shall perform the procedures required in Operational Rules 14 and 17.
• the title registry instructions designating the same user as both To Order Party and Holder may be sent within the same message.
• An Originator may designate a To Order Party when creating the electronic bill of lading, but not after the title registry has returned an acknowledgment through the message handling unit notifying the Originator that the bill has been successfully created.
• the current Bearer Holder of the electronic bill of lading may also designate a Consignee.
• One To Order Party may also designate a successive To Order Party if the designating To Order Party is also Holder (i.e., the Holder-to-order).
• Figure 20 illustrates the process of designating a To Order Party, that has the followings steps:
• the user designates a To Order Party by listing the new To Order Party ' s user identifier within appropriate tags in the Instruction element of the message type header. Further tagged information, such as the document ID of the bill to be affected and an indication that the electronic bill of lading is "negotiable", is also required there:
• the message handling unit checks its authenticity by verifying the sender ' s digital signature.
• the message handling unit and/or title registry also checks the form of the message. If the message handling unit or title registry cannot properly verify the digital signature or find the form incorrect, a BNak is returned;
• the title registry changes the content of the To Order Party role field to the user identifier of the new To Order Party listed in the message type header.
• the former To Order Party ' s user identifier is removed from the title registry record for that bill;
• the title registry then confirms the successful designation of the new To Order Party by returning a DNot message having a BAck type header to the sender through the message handling unit. That type header includes a report from the title registry of the actions it has taken. The title registry notifies the new To Order Party of its designation. If the newly designated To Order Party is also the current Holder (perhaps through the same message as the one effecting To Order Party designation), the notice includes the following text: "You have been designated as the Holder of this electronic bill of lading in accordance with the Rulebook.
• Designating a To Order Party when none is currently designated makes the bill transferable by designating a successive To Order Party beginning when the title registry is updated.
• the bill remains transferable, with the transfer possible only by the successor beginning when the title registry is updated.
• the title registry record containing the designation of the To Order Party remains in the title registry and available to permitted users for the time specified in the applicable retention schedule.
• the title registry instmction effecting the designation is also recorded in the chronological log of message flow, and that log is retained for as specified in the applicable retention schedule.
• an electronic bill of lading is not already transferable by Bearer Holder, creating a Bearer Holder for it consists of blank-endorsing the bill.
• Blank-endorsing consists of flagging the electronic bill of lading as being Blank Endorsed in the title registry, which has the effect of making its Holder at that time its Bearer Holder.
• the new Bearer Holder may thereafter transfer the bill simply by changing its Holder as described in section 4.4.3.1.
• a Bearer Holder is the Holder of a blank endorsed electronic bill of lading. Designating a new Holder has already been covered in section 4.4.3.1. This section focuses on blank-endorsing electronic bills of lading.
• An Originator may Blank Endorse an electronic bill of lading in creating it (see Operational Rule 13).
• a Holder-to-order of an electronic bill of lading shall:
• the Holder of an electronic bill of lading becomes its Bearer Holder when the Instruction effecting the Blank Endorsement is entered into the title registry record.
• a Holder-to-order may designate a new Holder by an Instruction in the same message as the Instruction effecting the Blank Endorsement. The newly designated
• Operational Rule 21 Transfers by Bearer Holder
• a Bearer Holder (the Holder of a Blank Endorsed electronic bill of lading) may designate a new Bearer Holder by the procedure required in Operational Rule 14 for designating a new Holder.
• An electronic bill of lading can be blank endorsed only if it is active, transferable, and not pledged.
• the Bearer Holder simply designates a new Holder as described in section 4.4.3.1.
• Figure 21 illustrates the process of blank endorsing an electronic bill of lading, the operations of which are now described:
• the user in that message, the user includes a blank endorse indicator in the form of a BlankEndorse tag in the Instruction element of the message type header. Further tagged data, such as the document ID of the bill to be affected and an indication that the electronic bill of lading is "negotiable", is also required;
• the message handling unit checks its authenticity by verifying the sender's digital signature.
• the message handling unit and/or title registry also check the form of the message. If the message handling unit or title registry cannot properly verify the digital signature or find the form incorrect, a BNak is returned; (5) if the message handling unit and title registry properly verify the sender's digital signature and find the message valid, the title registry marks the electronic bill of lading as blank endorsed and changes the content of the To Order Party role field to empty; and
• the title registry then confirms via the message handling unit the successful Blank Endorsement by returning a DNot message having a BAck type header to the sender. That type header includes a report from the title registry of the actions it has taken.
• a new Bearer Holder is notified by the following text in the FMsg message: "You have been designated as the Holder of this electronic bill of lading in accordance with the Rulebook. By virtue of your capacity as Holder of this electronic bill of lading, in addition to your designation as a To Order Party, Consignee, Bearer or Pledgee, we (the system service provider) confirm on behalf of the Originator of this electronic bill of lading (the carrier) that the goods are now held to your order.”
• the new Bearer Holder may reverse the designation by returning to the title registry a message with a type header in the SBRf form within the timeout period of 24 hours beginning when the title registry record is updated with the new designation, provided that the SBRf message is sent before the designated user takes any other action in relation to the bill.
• it may accept the appointment by returning a UAck, letting the timeout period elapse, or taking action in relation to the bill other than returning an SBRf.
• Blank-endorsing an electronic bill of lading makes it transferable by its Bearer Holder.
• the title registry record containing the blank endorsement remains in the title registry and available to permitted users for the time specified in the applicable retention schedule.
• the title registry instmction effecting the designation is also recorded in the chronological log of message flow, and that log is retained for as specified in the applicable retention schedule.
• Pledge transactions reflect the activities of financial institutions involving bills of lading. There are three main pledge transactions, namely designating a Pledgee, relinquishing a pledge, and enforcing a pledge.
• Pledge Holder designates a Pledgee, it enters a user identifier into the Pledgee role field for the electronic bill of lading. It thereby converts the bill to pledged status, and thus suspends the ordinary powers of the To Order Party or Bearer Holder while the bill is pledged, as described in section 4.3.2..
• Designating an initial Pledgee for an electronic bill of lading is analogous to giving a conventional bill of lading to a bank as a sort of security for a documentary credit. Once a Pledgee is designated, it may also designate a successor.
• the Pledgee deletes its user identifier from the Pledgee role field. That deletion is the relinquishment of the pledge.
• the Pledgee designates itself the current Holder-to- order, if a To Order Party had previously been designated, or Bearer Holder if the electronic bill of lading had been Blank Endorsed. That double designation by the Pledgee is termed "enforcing the pledge".
• Designation of a Pledgee always includes designation of a Holder.
• the title registry also enters that user identifier into the Holder role field. This section describes that two-step process in greater detail.
• Pledgee Holder can designate a Pledgee. If an electronic bill of lading is pledged, its Holder is invariably also its Pledgee, and that Pledgee Holder may thus also transfer the bill.
• a Pledgee can be designated for an electronic bill of lading only if it is active and transferable. As Figure 22 illustrates, designation of a Pledgee involves the following steps:
• the user designates a Pledgee by listing the new Pledgee ' s user identifier within appropriate tags in the Instruction element of the message type header. Further tagged data, such as the document ID of the bill to be affected, is also required there;
• the message handling unit checks its authenticity by verifying the sender's digital signature.
• the message handling unit and title registry also check the form of the message. If the message handling unit or title registry cannot properly verify the digital signature or find the form incorrect, a BNak is returned;
• the title registry changes the content of the Pledgee role field to the user identifier of the new Pledgee listed in the message type header.
• the former Pledgee's user identifier is removed from the title registry record for that bill.
• the title registry also enters the new Pledgee ' s user identifier into the Holder role field in place of whatever user identifier was there; and
• the title registry then confirms the successful designation of the new Pledgee by returning, via the message handling unit, a DNot message having a BAck type header to the sender. That type header includes a report from the title registry of the actions it has taken.
• the title registry record containing the designation of the new Pledgee Holder remains in the title registry and available to permitted users for the time specified in the applicable retention schedule.
• the title registry instmction effecting the designations is also recorded in the chronological log of message flow, and that log is retained for as specified in the applicable retention schedule.
• Relinquishing a pledge removes the current Pledgee ' s user identifier from the Pledgee role field, which in turn has the effect of returning the bill from pledged to transferable status. This section describes the process of relinquishing in detail.
• the Pledgee Holder shall:
• Figure 23 is a flow chart illustrating the process of relinquishing a pledge. The remainder of this section comments on that Operational Rule. Only the current Pledgee Holder may relinquish the pledge in an electronic bill of lading. An Originator cannot designate a Bearer Holder when creating a bill (or in any other circumstances). Rather, if the bill is to be transferable, the Originator designates a To Order Party (often the Shipper), who can then Blank Endorse the bill. Clearly, an electronic bill of lading must be in the pledged status for its Pledgee to relinquish its pledge.
• Relinquishing a pledge consists of emptying its Pledgee role field so that no Pledgee is designated. This is implemented by the following steps:
• the current Pledgee creates a message to the message handling unit; (2) In that message, the current Pledgee includes a RelinquishPledge sub- element within the Instruction element of the message type header. Further tagged data, such as the document ID of the bill to be affected, is also required;
• the message handling unit checks its authenticity by verifying the sender's digital signature.
• the message handling unit and title registry also check the form of the message. If the message handling unit and title registry cannot properly verify the digital signature or find the form incorrect, a BNak is returned; (5) If the message handling unit and title registry properly verify the sender's digital signature and find the message valid, the title registry changes the content of the Pledgee role field to empty; and
• the title registry then confirms the successful relinquishment of the pledge by returning, via the message handling unit, a DNot message having a BAck type header to the sender. That type header includes a report from the title registry of the actions it has taken.
• Relinquishing a pledge discontinues the bill's pledged status and returns it to transferable status beginning when the title registry is updated.
• the title registry record reflecting the relinquishment of the pledge remains in the title registry and available to permitted users for the time specified in the applicable retention schedule.
• the title registry instmction effecting the relinquishment is also recorded in the chronological log of message flow, and that log is retained for as specified in the applicable retention schedule.
• the current Pledgee Holder of an electronic bill of lading displaces the current To Order Party of the bill if any, and thus becomes its Holder-to-order). If the electronic bill of lading is blank endorsed (and therefore has no To Order Party), its Pledgee Holder simply removes its designation as Pledgee, leaving itself the Bearer Holder. This section describes the process of enforcing a pledge in detail.
• a Pledgee Holder shall:
• Figure 24 illustrates the process of enforcing a pledge. Enforcing a pledge where a To Order Party is designated is substantially the same process as for designating a new To Order Party. If the electronic bill of lading is blank endorsed, enforcement of the pledge is substantially the same as relinquishing the pledge, leaving the former Pledgee Holder as the Bearer Holder. The title registry does not notify any users affected by the enforcement of a pledge, although the enforcing Pledgee Holder may notify them independently.
• Enforcing a pledge makes the electronic bill of lading transferable by the former Pledgee as its new Holder-to-order or Bearer Holder, beginning when the title registry is updated.
• the title registry record reflecting enforcement of a pledge remains in the title registry and available to permitted users for the time specified in the applicable retention schedule.
• the title registry instmction enforcing the pledge is also recorded in the chronological log of message flow, and that log is retained for as specified in the applicable retention schedule.
• a document including the document serving as a eBL Text, remains unchanged, just as it was originally received. Subsequent references to the document make no changes to it and must match the document's attributes entered into the present system when the document was originally received. Among those attributes is a mathematical digest of the document, which the present system uses to compare all subsequent references or instances of the document purporting to be the same, in order to assure that they are exactly identical to the document on file in the present system. Although the present system will leave an existing document unchanged, the title registry record for a particular electronic bill of lading can be made relate to a another, perhaps more recently filed eBL Text through the amendment process.
• amending an electronic bill of lading leaves the existing document unchanged and merely makes the documentary reference in the title registry point to a different document as the operative eBL Text.
• Each title registry record includes a field containing the document ID for the corresponding eBL Text. That field serves as a reference to the eBL Text, and changing the content of that field to list a new document ID is referred to as amending the electronic bill of lading, even though the former document remains unchanged and available in unaltered form for future reference.
• This "amendment" process occurs in two basic steps: First, a user requests the Originator to amend the bill, and then the Originator either grants or denies the request. If the request is granted, a new document ID is substituted for the former one in the title registry, and the transactional data in the title registry is then applied to the substituted eBL Text so that the pre-amendment rights and obligations of system users resume in relation to the new document.
• the Originator creates and signs the eBL Text
• the Originator 's approval is necessary to substitute a new document for the one already referenced in the title registry.
• Other interested users besides the Originator can request an amendment, and when they do.
• the title registry suspends the electronic bill of lading so that all title registry instmctions are declined until the Originator grants or denies the amendment request.
• the title registry does not process any dialogue between the Originator and other users in determining whether or how to amend; it simply suspends activity involving that title registry record until the request is either denied or granted with a substituted eBL Text.
• a request amendment title registry instmction suspends operations affecting the title registry and is forwarded to the Originator for its consideration.
• the requesting user would ordinarily include a document explaining its reasons for the request, and perhaps also a suggested revision. Any ensuing discussion will not involve the title registry until the Originator decides to grant or deny the request.
• a grant amendment title registry instmction from the Originator substitutes a new eBL Text for the one previously referenced in the title registry record.
• the electronic bill of lading then regains active (rather than suspended) status.
• a deny amendment title registry instruction simply returns the electronic bill of lading to active status without any change to its title registry record.
• the amendment process starts when Holder requests an amendment. That request is directed mainly to the Originator, but is recorded in the title registry in order to suspend further transactions in relation to the electronic bill of lading while the amendment request is pending, as described in greater detail below.
• Operational Rule 26 Requesting an Amendment To request or propose an amendment of the eBL Text, its Holder shall: (a) Create a title registry instruction in the form of an amendment request;
• Operational Rule 27 Granting or Denying Request 77ze Originator of an electronic bill of lading in receipt of an amendment request forwarded by the message handling unit shall either:
• Figure 25 is a flow chart illustrating the process of requesting amendment of an electronic bill of lading. The steps of this process are as follows: (1) The appropriate user creates a message to the message handling unit using a user system;
• the user includes an amendment request in the Instruction element of the message type header.
• the tagged data includes the document ID of the electronic bill of lading to be affected;
• the user then digitally signs and sends that message to the present system:
• the message handling unit checks its authenticity by verifying the sender ' s digital signature and also checks the form of the message. If the message handling unit cannot properly verify the digital signature or finds the form incorrect, it returns a BNak; (5) If the message handling unit and title registry verify the sender's digital signature and find the message valid, the title registry flags the electronic bill of lading as having an amendment pending, and changes its status to suspended. It also enters a request identifier to track which request effected that suspended state and subsequent operations relating to the requested amendment; (6) The amendment request is forwarded to the Originator. To do this, the title registry sends to the Originator of the electronic bill of lading, via the message handling unit, a report that a request for an amendment has been received from the sender of the message; and
• the title registry then confirms the processing of the amendment request by returning to the sender, via the message handling unit, a DNot message having a type header in the form of a BAck. That type header includes a report from the title registry of the actions it has taken.
• Requesting an amendment gives the electronic bill of lading the suspended status beginning when the title registry is updated. There is no time limit fixed for termination of that status, other than by a grant or denial of the amendment request.
• the title registry record reflecting the request for amendment remains in the title registry and available to permitted users for the time specified in the applicable retention schedule.
• the title registry instmction requesting the amendment is also recorded in the chronological log of message flow, and that log is retained for as specified in the applicable retention schedule.
• the Originator to which an amendment request is ultimately directed, can deny the request as described in this subsection.
• the bill must have suspended status for the Originator to deny the requested amendment.
• the title registry does not inquire into whether an Originator has a legal right to deny amendment or whether any user has satisfied any conditions agreed upon with the Originator for obtaining an amendment.
• FIG 26 illustrates the deny amendment process, which proceeds as follows:
• the Originator creates a message to the message handling unit using a user system; (2) The Originator expresses its intent to deny the amendment request by including a tag indicating denial of an amendment request in a form prescribed by the service provider. The tagged data includes the document ID of the bill to be affected and the request identifier of the amendment request denied; (3) The Originator then digitally signs and sends that message to the message handling unit;
• the message handling unit checks its authenticity by verifying the sender's (Originator ' s) digital signature and also checks the form of the message. If the message handling unit cannot properly verify the digital signature or finds the form incorrect, it returns a BNak;
• the amendment request is then forwarded to the Originator.
• the title registry then sends to the Originator of the electronic bill of lading, via the message handling unit, a report that a request for an amendment has been received from the sender of the message;
• the title registry then confirms the processing of the amendment denial by returning to the Originator a DNot message including a type header in the form of a BAck. That type header includes a report from the title registry of the actions it has taken.
• An Originator to which an amendment request is forwarded, may grant or deny the request as described in this subsection.
• the Originator cannot initiate an amendment on its own. A request must have been made by the Shipper who is also the Holder or the Consignee of the bill to be amended, and the bill must have thereby have suspended status.
• the title registry does not inquire into whether an Originator has a right to have the amendment request granted, or whether any user has satisfied .any conditions agreed upon with the Originator for obtaining an amendment.
• Figure 27 illustrates the process for granting a request for an amendment. The following steps are involved:
• the Originator creates a message to the message handling unit using a user system
• the Originator expresses its intent to grant the amendment request by including a tag indicating grant of an amendment request in the form prescribed by the service provider.
• the tagged data includes the request identifier of the amendment request granted and the document ID of the new electronic bill of lading attached. If the amendment combines multiple electronic bills of lading into one, multiple document IDs may appear in the granting Instmction. If the amendment splits a single electronic bill of lading into multiple distinct electronic bills of lading, it may have multiple Instmctions, all with the same amendment request identifier, but each indicating a separate document ID referring to a separate eBL Text included in the message.
• the message handling unit checks its authenticity by verifying the sender's (Originator ' s) digital signature.
• the message handling unit and title registry also check the form of the message. If the digital signature cannot be verified or the form of the message is found to be incorrect, the message handling unit returns a BNak message;
• the title registry then confirms the processing of the amendment denial by returning to the Originator, via the message handling unit, a DNot message including a type header in the form of a BAck. That type header includes a report from the title registry of the actions it has taken. Granting n amendment request discontinues the suspended status and returns the amended electronic bill(s) of lading to active status with a new eBL Text, beginning when the title registry is updated.
• the pre-amendment title registry record remains in the title registry and available to permitted users for the time specified in the applicable retention schedule.
• the title registry instmction granting the amendment is also recorded in the chronological log of message flow, and that log is retained for as specified in the applicable retention schedule.
• Surrendering an Electronic Bill of Lading is analogous to the presentation of a paper bill of lading by its consignee or endorsee (generally the buyer or importer) to the carrier in return for the shipped goods. It does not change any of the role fields, but simply indicates that the bill is terminated, as described in more detail below. Only the following can surrender an electronic bill of lading: (1) a Consignee, if it is also the Holder; and (2) the current holder-to-order.
• the bill must be active and not pledged in order to be surrendered.
• Figure 28 illustrates the process of surrendering an electronic bill of lading which is performed by the following steps: ( 1 ) The Consignee or current Holder-to-order creates a message to the message handling unit using a user system;
• the Consignee or Holder-to-order includes an Instmction in the form prescribed by the service provider.
• the information includes the document ID of the bill to be surrendered;
• the Consignee or Holder-to-order then digitally signs and sends the message to the message handling unit;
• the message handling unit checks its authenticity by verifying the sender's digital signature.
• the message handling unit and/or title registry also check the form of the message. If the message handling unit or title registry system cannot properly verify the digital signature or find the form incorrect, the message handling unit returns a BNak;
• the title registry If the message handling unit and title registry properly verify the sender's digital signature and find the message valid, the title registry flags the electronic bill of lading as surrendered; and (6) The title registry then confirms the surrender by returning to the sender a type header in the form of a BAck. That type header includes a report from the title registry of the actions it has taken.
• the title registry sends via the message handling unit a FMsg message to the Originator and Surrender Party (if any), notifying them that the electronic bill of lading has been surrendered and informing them who the current Consignee or Holder-to- order is
• the title registry record (including all prior transactions) of the terminated electronic bill of lading remains m the title registry and available to permitted users for the time specified in the applicable retention schedule
• the title registry instmction effecting the surrender is also recorded in the chronological log of message flow, and that log is retained for as specified in the applicable retention schedule
• a user To convert an electronic bill of lading from paper to electronic form, a user directs the Originator of the bill to print out the bill-of-lading document, sign the printed version, and pass it on to the next appropriate party, as set out in Rulebook ⁇ 3 7 As a technological process, it is a message ultimately directed to the Originator and passing en route through the title registry so that it can flag the electromc bill of lading as terminated, as described below
• a critical user is one which is: (1) the Shipper, if also the Holder; (2) the Consignee, if the Consignee is also the Holder; (3) the current Holder-to-order, unless the bill is pledged; (4) the current Bearer Holder, unless the bill is pledged; or (5) the current Pledgee Holder.
• the system service provider inactivates a user, it checks through the title registry to determine whether the user occupies one of the above roles and if so, initiates a switch- to-paper directive.
• the electronic bill of lading must not already be terminated when a switch-to- paper directive is given.
• Holder-to-order includes an instmction in the form prescribed by the service provider.
• the information includes the document ID of the bill to be switched to paper;
• the message handling unit checks its authenticity by verifying the sender's digital signature.
• the message handling unit and/or title registry also check the form of the message. If the message handling unit and title registry cannot properly verify the digital signature or find the form incorrect, a BNak is returned from the message handling unit;
• the switch-to-paper directive is forwarded to the Originator by the title registry sending to the Originator of the electronic bill of lading, via the message handling unit, a report that a directive for a switch to paper has been received from the sender of the message.
• the title registry does not interrogate the Originator to determine if the Originator has performed this directive.
• the title registry then confirms the processing of the switch-to-paper directive by returning to the sender via the message handling unit a type header in the form of a BAck. That type header includes a report from the title registry of the actions it has taken.
• the title registry record (including all prior transactions) of the terminated electronic bill of lading remains in the title registry and available to permitted users for the time specified in the applicable retention schedule.
• the title registry instmction effecting the switch to paper is also recorded in the chronological log of message flow, and that log is retained for as specified in the applicable retention schedule.
• the Title Registry maintains an endorsement chain for each BBL.
• the endorsement chain reflects the parties to the contract of carriage.
• the service provider manages the creation and delivery of endorsement chains reflecting the contractual state and transfer of the BBL. respectively.
• the Title Registry creates a record in the endorsement chain whenever a new party to the contract of carriage is named. This occurs when a party becomes both a Holder and To Order party or Consignee, as a result of one of a number of instmctions. These instmctions are: Name Holder; Name Holder and Name To Order party or Consignee; Name To Order or Consignee when the Bearer Holder names himself the To Order party or Consignee; Enforce Pledge if there is a To Order party named on the BBL; and Grant Amendment in some circumstances.
• Grant amendment creates a record in the endorsement chain when there is an eBL with a new version number and (i) the Holder who is also the To Order party becomes the Consignee and (ii) the Holder who is also the Consignee becomes the To Order party. Grant amendment also creates a record in the endorsement chain when there is an eBL with a new eBL identifier. In this case, the record is created for each eBL amended when the Holder is also the To Order party or Consignee.
• Figure 30 shows an example of the syntax of an endorsement chain. The definitive mles regarding when an endorsement chain is created are described with reference to Figures 31 to 37.
• the Title Registry will deliver endorsement chain information when a number of functions are completed, namely: Name Holder; Name Pledgee Holder; Enforce Pledge; Request Amendment; Grant Amendment; Switch to Paper; and Surrender BBL.
• the Title Registry will not deliver the endorsement chain if the record is empty. The definitive rules regarding when an endorsement chain is delivered are described with reference to Figures 31 to 37.
• the information about an electronic bill of lading is confidential according to the service provider's contract with the user supplying the information.
• certain information may be disclosed to certain persons at certain times.
• the Web site uses certificates and Transport Layer Security (formerly Secure Sockets Layer) to assure that only properly identified user representatives have access to title registry information.
• a user representative can obtain access only if she has information monitoring privileges according to the user database.
• users can obtain information by telephone inquiries to the service provider help desk.
• the access limitations applicable to the Web site apply to the staff supplying information at the help desk.
• the information that a given user can obtain varies depending on the type of information and the role of the requesting user. For messages, a user can obtain copies of messages it has sent or received (although most user systems keep copies so a need to resort to the central message handling unit to obtain a copy will likely be rare). For information in title registry (either current or archival, a user can obtain information of which the user is (or was) entitled to be notified, or which the user had previously provided. Again, a user system ordinarily keeps notices sent from the present system as well as copies of information sent in, so retrieval of the information from the present system will rarely be necessary.
• the title registry reports information about the to-order endorsement chain, the sequence of transfers of an electronic bill of lading by to-order parties, to users having certain roles in a particular electronic bill of lading, as described below.
• the present system In making transfer information available, the present system is designed to strike a general balance between the privacy interests of system users and their need to know information that affects their rights and obligations.
• the technical operations implement that general balance, which may be acceptable for most users but perhaps not all.
• the present system does not prevent promises between users supplementing the Rulebook and imposing greater restrictions on the availability of information.
• the technical ability to obtain transfer information is independent of the right to obtain it; so even where the present system gives a user the option to obtain transfer information, promises between users to maintain privacy may restrict a user's legal right to exercise that option.
• the available information about pledges includes information about transfers by one Pledgee to another can be obtained.
• Information about transfers by Holders and other roles, including Bearer Holders, is not available, except that the endorsement chain will indicate when an electronic bill of lading becomes Blank Endorsed (if that occurs) and when (if ever) it is again transferred to a To Order Party.
• the confidentiality of Bearer Holder transfers is, of course, subject to governmental search of the system service provider, to the extent that such information is retained in the present system.
• designation of a Consignee makes the electronic bill of lading non-transferable, it terminates the endorsement chain. Information about transfers after designation of a Consignee is therefore not available, and indeed, is non-existent.
• the endorsement information available to a To Order Party is as follows. For each to-order transfer or pledge that precedes the requesting To Order Party, the To Order Party can obtain the user identifier of the transferee or Pledgee and date and time of the transfer or pledge.
• the endorsement information available to a Current Bearer Holder is as follows. For each to-order transfer or pledge that precedes the requesting Bearer Holder, the current Bearer Holder can obtain the user identifier of the transferee or Pledgee and date and time of the transfer or pledge.
• the endorsement information available to a Consignee of a previously transferable bill is as follows. For each transfer or pledge, the Consignee can obtain the user identifier of the transferee or Pledgee and date and time of the transfer or pledge.
• the endorsement information available to a Originator of a terminated bill is as follows. For each transfer or pledge, the Originator of a surrendered or switched-to- paper bill can obtain the user identifier of the transferee or Pledgee and date and time of the transfer or pledge.
• the endorsement information available to a Surrender Party of a terminated bill is as follows. For each transfer or pledge, the Surrender Party of a surrendered or switched-to-paper bill can obtain the user identifier of the transferee or Pledgee and date and time of the transfer or pledge.
• transfer information is available only if the electronic bill of lading has become transferable at some time in its history, and only if the bill's status is not in error at the time the transfer is to occur.
• Endorsement chains are sent to the designated user whenever a Consignee, Holder-to-order, or Bearer Holder is designated.
• the present system permits users to post commonly referenced documents online in the online user support resources. It is then available to system users through the HyperText Transport Protocol (HTTP), the communication protocol commonly used in the Worldwide Web.
• HTTP HyperText Transport Protocol
• the system service provider assigns it a uniform resource locator (URL) by agreement with the posting user, and makes the document available accordingly.
• the URL is unique for all documents online in the user support resources.
• the service provider posts documents pursuant to an e-mail request to the user support resources.
• the posted document is available to and visible by all system users via HTTP, unless arrangements are made to limit access to it using the Secure Sockets Layer (SSL, also known as Transport Layer Security (TLS)) and specified classes of public-key certificates.
• SSL Secure Sockets Layer
• TLS Transport Layer Security
• a user may post a document for reference to the user support resources by further agreement with the system service provider.
• the Title Registry accepts only a single instmction at one time.
• the exception is with the Name (Pledgee) Holder instruction in which an additional instmction can be issued simultaneously.
• a Name Holder instmction can be accepted simultaneously with any one of a Name To Order, Name Consignee or Blank Endorse instmction.
• a Name Pledgee Holder instmction can be accepted simultaneously with a Name To Order or Blank Endorse instmction.
• the simultaneous functions described above can be issued in the same message. No other simultaneous functions are available. The simultaneous functions will be available only if the sender has the right to perform each of the functions separately.
• the Title Registry accepts only a single eBL at one time. The exception is with the Request or Grant Amendment instmction.
• the sender may request the carrier to amend the BBL by way of a split or combine.
• the sender requests the creation of multiple BBLs from a single BBL.
• the sender requests the creation of a single BBL from multiple BBLs.
• the requesting user sends a single eBL to the
• the Originator will respond with a Grant Amendment issuing multiple eBLs.
• the requesting user sends multiple eBLs to the Title Registry, and the Originator will respond with a Grant Amendment issuing a single eBL.
• BBLs The Title Registry caters for transferable (negotiable) and non-transferable (non-negotiable) BBLs. The roles determine the negotiability of the BBL.
• a transferable BBL is represented by a named To Order or blank-endorsed BBL.
• a non- transferable BBL is represented by a named Consignee BBL. The To Order and Consignee roles cannot co-exist on a single BBL.
• the Title Registry also provides a mandatory transferable/non-transferable field in the Title Registry sub-envelope. If a To Order party is named or the BBL is blank endorsed when the BBL is indicated as non-transferable, the Title Registry will reject the message. If a Consignee is named when the BBL is indicated as transferable, the Title Registry will reject the message.
• the Title Registry adheres to the same document ID convention and syntax used in the message handling unit. This consists of a RID, a General ID and a Version.
• the RID is an alpha-numeric string of no more that 64 characters that is the registered User ID of the Originator.
• the General ID is an alpha-numeric string of no more than 64 characters that is specified by the Originator and which must be unique to this user.
• the Version is an alpha-numeric string of no more than 16 characters that is optionally added to identify an amended document.
• Two eBL identifiers that are the same apart from the version number correspond to two versions of the same eBL.
• the latest version corresponds to an amendment issued by the Originator as a result of a request issued by the Holder.
• the Title Registry does not accept draft documents, therefore the draft attribute is not permitted in a Title Registry instmction.
• the Title Registry checks to ensure the eBL is enclosed when it is required. If the eBL is not enclosed when required, the Title Registry will issue a negative result and the sender will receive a BNAK.
• the Title Registry provides a function for amendments through the request, grant and deny amendment instmctions.
• the request amendment instmction is purposefully generic, providing facilities for all amendment requests. The request is issued by the current Holder and can only be acted upon by the Originator.
• the Title Registry When the Title Registry receives a valid amendment request, it suspends all actions on the BBL until a grant or deny amendment instmction is issued by the Originator.
• the Title Registry issues a request ID to the Originator when a valid request amendment instmction has been received. This provides the Originator the freedom to grant or deny the amendment as required by the business environment. If the Originator wishes to grant an amendment request to combine BBLs, he responds with the request ID provided by the Title Registry and the new BBL, regardless of the number of BBLs sent by the Holder. The Title Registry uses the request ID to replace all previous BBLs with the new BBL. Likewise, if the Originator wishes to grant an amendment request to split BBLs, he responds with the request ID provided by the Title Registry and the new BBLs. The Title Registry uses the request ID to replace the previous BBL with the new BBLs.
• An amended BBL must carry a new eBL identifier.
• the carrier can choose either to use a new eBL identifier or can use the same eBL identifier with a different version number.
• the new BBL is replacing multiple old BBLs (n: l) or when multiple new BBLs are replacing an old BBLs (n: l)
• the Originator of the BBL (the carrier) holds the cargo in its physical possession as an independent party (an independent bailee in legal terms).
• the Originator agrees, via the Rule Book, that the right to give it instmctions may pass in accordance with the terms of the Rule Book.
• Constmctive possession is initially with the Shipper and passes to another party in the following circumstances: (1) when a Bearer Holder is named; (2) when the named Holder is also the To Order party or Consignee; and (3) whenever a Pledgee Holder is named.
• the contract of carriage is initially between the Originator and the Shipper.
• a user becomes a party to the contract of carriage when it is both the Holder and either the To Order party or Consignee. This can occur in the following instances: (1) The (Pledgee) Bearer Holder names another user the Holder and either the To Order party or the Consignee.
• the Holder and To Order party of a BBL names another user the Holder and either the To Order party or the Consignee.
• the Bearer Holder names itself the To Order party or the Consignee.
• the Pledgee Holder of a BBL with a named To Order party enforces the pledge.
• An attond notice is generated by the Title Registry, on behalf of the Originator, when a user is designated to one of the statuses described above as conferring constmctive possession. This occurs in the three cases described above with the following exceptions: (1) when a Bearer Holder names himself the To Order party or Consignee; (2) after an Enforce Pledge; and (3) after a Grant Amendment when a version number is used. These are exceptions because the user who issues the instmction has constmctive possession both before the instmction is issued and after the instmction takes effect.
• a business refusal cannot be issued when a user becomes party to the contract of carriage when: (1) a Bearer Flolder names himself a To Order party or Consignee; (2) a user enforces a Pledge; and (3) there is a Grant Amendment in response to a Request Amendment by the user.
• the business refusal cannot be issued in these cases because the user has clearly given his consent to be named a party to the contract of carriage.
• the business refusal message must be sent within 24 hours and the party cannot issue any other Title Registry instmction before issuing the business refusal. If a party attempts to send a business refusal after 24 hours or after issuing another instmction related to the same BBL, the Title Registry will reject the message and issue a negative acknowledgment (BNAK).
• BNAK negative acknowledgment
• the Title Registry When the Title Registry receives a valid business refusal, it will unwind the BBL to its previous state (i.e., the state that existed before the user was designated) and will notify the former party of the refusal. The Title Registry will also remove the party issuing the business refusal from the endorsement chain (see below).
• the Title Registry issues a result to the sender and receiver(s).
• the result is automatically generated to the receiver(s) as described above. If the result is negative, the result to the sender is an error code and description. If the result is positive, the result to the sender is a list of the notified user IDs and the complete receiver result information. A list of the error codes appears in Figure 41. If the sender result is positive, the receiver result includes the following information:
• an eBL identifier i.e. the document ID of the eBL.
• Status information notifying the current state of the BBL i.e. active, suspended or end state. If active, the BBL record exists and can be acted upon by authorized parties. If suspended, the BBL record exists but is pending an amendment so that no action can take place until the Originator returns a grant or deny amendment instmction. If in the end state, the BBL record exists only in the Title Registry log and is no longer active. The End status will have been entered as a result of a Switch to Paper or Surrender instmction.
• Endorsement chain information in the form of the parties to the contract of carriage (i.e., the current and past Holder/To Order parties and Holder/Consignees) together with the date and time of each endorsement.
• a Request ID i.e. the identifier generated by the Title Registry when a Request Amendment instmction has been issued.
• Sender results are delivered by the message handling unit in either a BNAK or BAck as required.
• Receiver results are delivered by the message handling unit in the FMsg.
• the service provider provides a facility for carriers to store bill of lading terms and conditions on the secure, interactive facility. All registered users have access to this information, negating the need to send the terms and conditions with each bill of lading.
• the process for storing terms and conditions is as follows: (1) The carrier sends a digitally signed message (SMsg) to the helpdesk.
• SMSG includes the attached terms and conditions and the date from which the terms are applicable.
• the helpdesk supervisor sends a digitally signed message (SMSG) to the carrier confirming that the terms and conditions have been lodged.
• SMS digitally signed message
• the carrier reviews the terms and conditions on the interactive site prior to the date of activation.
• the carrier sends a digitally signed message (SMSG) to the helpdesk to confirm acceptance of the terms and conditions that have been lodged prior to the applicable date.
• SMSG digitally signed message
• Optional information additional information that the authorized party can send with the instmction. 4. Need to enclose eBL - because the Title Registry does not use the eBL document, the eBL only needs to be attached if the receiver requires it.
• Business refusal a business refusal can be issued when a party becomes both the Holder and the To Order party or Consignee. 6. Who is notified - the Title Registry will automatically notify the affected party. If the sender names the affected party as a receiver, the message handling unit will filter the Title Registry notification.
• Attond notice - the Title Registry generates a notice of attonce when as a result of an instruction there is a Holder of a blank endorsed BBL; the Holder is also the To Order party or the Consignee; or there is a Pledgee Holder.
• Endorsement chain record - the Title Registry creates an entry in the endorsement chain when as a result of an instmction the Holder is also the To Order party or the Consignee.
• Endorsement chain returned - the Title Registry will issue the endorsement chain when the BBL is transferred between parties after creation.
• a Create instmction is to allow the creation of a record in the Title Registry for a new BBL.
• Name Holder instmctions transfer holdership in an existing BBL record. An attond notice is made if as a result of the instmction there is a new
• An endorsement chain record is made if as a result of the instmction there is a new Holder who is also the To Order party or the Consignee. 4.10.3. Name Pledgee Holder
• Pledgee Holder instmction The purpose of a Pledgee Holder instmction is to name a Pledgee Holder or to transfer a pledge holdership in an existing BBL record.
• a Name To Order instmction is to name a To Order party in an existing BBL record.
• An endorsement chain record is made if as a result of the instmction the Holder is also the To Order party.
• An endorsement chain is returned only when a Bearer Holder names himself the To Order party and then returned only in the Sender result.
• a Name Consignee instmction is to name a Consignee in an existing BBL record.
• the BBL becomes non-transferable.
• An endorsement chain record is made if as a result of the instmction the Holder is also the Consignee.
• An endorsement chain is returned only when a Bearer Holder or the Holder who is also the To Order party names himself the Consignee and then returned only in the Sender result.
• Blank Endorse instmction The purpose of a Blank Endorse instmction is to blank endorses a transferable BBL that has a named To Order party.
• Enforce Pledge The purpose of an Enforce Pledge instmction is to make the Pledgee Holder the
• An endorsement chain record is made if as a result of the instmction the Holder is also the To Order party. An endorsement chain is returned only in the Sender result.
• a Request Amendment instruction is to request the Originator to amend the BBL that is related to an existing BBL record.
• An endorsement chain is returned for each of the eBLs to be amended.
• Amendments can be requested to "split" a BBL (creating 2 or more BBLs from
• Grant Amendment The purpose of a Grant Amendment instmction is to grant the amendment by updating or creating BBL record(s) in the Title Registry.
• an attond notice is sent if the amendment removes a To Order party or Consignee who was not the Holder.
• an attonce notice is sent for each eBL amended except when the Holder is not the To Order party or Consignee.
• endorsement chain records for an eBL with a new version number, no endorsement chain record is made.
• an endorsement chain record is made for each eBL amended when the Holder is also the To Order party or Consignee.
• the endorsement chain is returned for each eBL amended when the Holder is also the To Order party or Consignee.
• Amendments can be granted to "split" a BBL (creating 2 or more BBLs from 1 original) and to "combine” a BBL (creating 1 BBL from 2 or more originals), meaning that multiple BBLs can be sent to the Title Registry for this instmction.
• a BBL cannot be amended or created through the grant amendment instmction to an end state (where the Holder is also the To Order party or the Consignee) unless the request was made from an end state.
• the Originator and the Holder or Pledgee Holder cannot change from the Request Amendment.
• the Title Registry will generate an error (BNAK) if the Originator and Holder or Pledgee Holder fields are provided with the Grant Amendment.
• a Deny Amendment instmction The purpose of a Deny Amendment instmction is to deny the amendment by returning the BBL record(s) in the Title Registry to their pre-request amendment state.
• Switch to Paper instmction The purpose of a Switch to Paper instmction is to request the Originator to create an original paper bill of lading from an original BBL.
• the purpose of a Surrender instmction is to return the BBL to the Originator (to fulfill the obligations in the contract of carriage).
• the TR DTD uses the same basic elements as the message handling unit DTD.
• the definitions of general elements, such as RID and GenerallD, are exactly the same as for the message handling unit and contain the same limitations on the data types.
• the SMSG is used to send messages to the message handling unit for forwarding to a value-added application and/or a receiver.
• the Title Registry instruction is included in the SMSG. The form is as follows:
• the 'Name " instmction is a generic naming instmction for all functions naming a party to the contract (including the 'BlankEndorse " function). This allows two parties to be named in the two simultaneous naming functions executed as part of the same message.
• the form is as follows:
• the CreateBBL instmction has the following form: ⁇ ! ELEMENT CreateBBL ( DocumentID, BBLType, Originator, SurrenderParty? , Shipper, Holder, ( BlankEndorse j ToOrder
• ELEMENT Originator > ELEMENT SurrenderParty ( RID )
• ELEMENT Shipper > ELEMENT Holder ( RID ) > ELEMENT BlankEndorse EMPTY > ELEMENT ToOrder ( RID ) > ELEMENT Consignee ( RID ) >
• the mandatory field 'BBLType ' is used to ensure the consistency of the BBL.
• the BBLType is 'Transferable'
• the BBL can be BlankEndorse or a ToOrder party can be named. If the BBLType is 'NonTransferable ' , a Consignee party must be named.
• the naming function has the following form:
• the naming function is a generic function that is used to name all the roles on the BBL.
• the naming sub-functions are specified as parameters for the generic Name function.
• the BBL must have one and only one of ToOrder, Consignee or BlankEndorse.
• the BBLType is mandatory when ToOrder. BlankEndorse or Consignee is named.
• the BBLType When a Consignee is named, the BBLType must be 'NonTransferable'. When a ToOrder party is Named or the BBL is BlankEndorse, the BBLType must be 'Transferable'.
• the enforce pledge instruction has the following form:
• a PledgeeHolder can enforce a pledge. This implies that the PledgeeHolder enters the role as Holder and ToOrder. The latter only if a ToOrder party was named before the pledge was enforced.
• the request amendment instmction has the following form:
• the sender requests the Originator to amend the BBL.
• the amendment can either be a new version of the same document or one or more new documents can be created. In the latter case the old document is no longer active in the Title Registry.
• the sender can ask for one of the following three amendments: (1) One document to be replaced by a new one (or a new version); (2) several documents to be replaced by one new document (a merge), where all documents in the Request
• the Request Amendment is identified in the first parameter (RequestID).
• the Originator role and the Holder or PledgeeHolder roles are defined implicitly by the Request/Grant Amendment protocol: the sender of the request is the
• the deny amendment instmction has the following form:
• the originator denies the Request Amendment.
• the document referenced in the Request Amendment instruction will no longer be suspended.
• the switch to paper instruction has the following form:
• the Originator After this function is executed, the Originator has the responsibility of generating a paper version of the BBL.
• the BBL is no longer active in the Title Registry (the status becomes 'Ended').
• the BBL is returned to the Originator, who must now complete its requirements under the contract of carriage.
• the BBL is no longer active in the Title Registry (the status becomes 'Ended').
• the Title Registry delivers information about the execution of a Title Registry instmction in a standard result PDU to the message handling unit.
• the Title Registry delivers specific information to the sender and to the parties to be notified.
• the SenderFeedback is included in the BACK delivered to the sender by the message handling unit.
• the ReceiverFeedback is included in the FMSG delivered to the sender by the message handling unit. See [1] for full details on the BACK and FMSG.
• the specific elements in the BACK and FMSG that relate to the Title Registry are re-produced here for information.
• the Title Registry also issues a standard result upon the reception of a valid SBRf (business refusal).
• the result is included in the FBRf delivered to the original sender by the message handling unit.
• the specific elements in the SBRF and FBRF that relate to the Title Registry are re-produced here for information.
• the Title Registry delivers either positive or negative feedback to the sender of an instmction. Negative feedback results from an error condition. Positive feedback results from a validated Title Registry instmction. The feedback is delivered in the BNAK or BACK returned to the sender by the message handling unit.
• the ReasonSource is used to denote the relevant value added application. For the Title Registry, the ReasonSource is always '"TRA".
• the ReasonCode is a numeric value of the error intended to be used by client computers.
• the ReasonDescription is a descriptive text of the error. A list of error codes is included in Figure 41.
• the negative feedback is delivered to the sender in a BNAK by the message handling unit.
• the form of the BNAK is as follows:
• the NotifiedParties are the User IDs to whom the Title Registry automatically generates a reply based upon the instmction.
• the RequestID is a numeric identifier of a RequestAmendment. The identifier must be used in the subsequent Deny Amendment or Grant Amendment to identify the Request.
• the field is only present in the ReceiverFeedback generated by a RequestAmendment instmction.
• the Instmction is a copy of the Title Registry instmction from the SMSG. The information makes it possible to understand the context of the reply.
• the BBLInfo provides the current record of the BBL, including the relevant parties and the EndorsementCham.
• the FreeText is used for Attomment information only. It is generated when as a result of an instruction, a party has constructive possession.
• the BBLState contains the status of the BBL ("active " , "ended', 'suspended').
• the EndorsementChain contains the entries of all contracting parties to the B
• the positive feedback is delivered to the sender in a BACK by the message handling unit.
• the form of the BACK is as follows:
• the Title Registry delivers ReceiverFeedback to the message handling unit in the following form:
• the information contained is identical to the positive SenderFeedback.
• ReceiverFeedback in the FMSG The FMSG is sent to the named or notified receiver(s) upon validation (within the message handling unit and TR) of a SMSG.
• the Title Registry ReceiverFeedback is included in the FMSG. The form is as follows:
• the Title Registry employs the business refusal, PDUs used by the message handling unit.
• a user sends a SBRF to refuse a Title Registry instmction, and the message handling unit forwards a FBRF after processing by the Title Registry to the associated user.
• the SBRF is used by the receiver of a FMSG with a Title Registry instmction to unwind a contractual state.
• the Title Registry will only accept a SBRF from a party that is both the Holder and To Order or Consignee, and then only when (1) the SBRF was issued within 24 hours of the related BACK; and (2) no other valid instmction was sent relating to the identified BBL.
• the form of the SBRF is as follows:
• FBRF 4.12.3.1.
• the FBRT is created by the message handling unit upon reception of a SBRF and a valid response from the Title Registry.
• the FBRF is forwarded by the message handling unit to the sender of the SMSG that has been refused.
• the form of the FBRF is as follows:
• the receiver After reception and signature validation of the FBRF, the receiver is required to return a UAck. The FBRF cannot be refused by a SBRF. If the FBRF signature is invalid and a UNAk is returned, the Title Registry will not negate the unwind performed in accordance with the SBRF.
• the table of Figure 32 provides a summary of the functions available in the Title Registry and which party can exercise each function.
• 'states ' ' and covering the top part of the chart we have defined all possible combinations of parties that can exist in a BBL at one time (referred to as "'states ' ' and covering the top part of the chart) and the functions available with each state (covered in the bottom part of the chart).
• the Pledgee Holder can only name a Consignee if it also names the Holder through simultaneous instmction.
• Figures 31 to 37 provide the complete and definitive mles regarding each of these elements. These tables take precedent over any apparent contradictions with the text above.
• Figures 31 to 37 describe movements from one state to another, and as the result of each movement, the action of the Title Registry relative to the four elements.
• a blank box or cell signifies that it is not possible to move from one state to the other.
• the tables cover only receiver information and do not reflect sender information.
• Figure 35 relating to the Name Holder and Pledgee Holder includes Name
• Figure 35 also makes a distinction between two cases that occur as a result of the instmction, namely cases when the
• Figure 36 does not include the simultaneous instructions that are covered in a separate section.
• the superscript 1 in Figure 36 indicates that the endorsement chain is delivered only with the Sender result.
• Figure 37 is a table indicating the handling of allowed simultaneous instructions.
• a first group of allowed simultaneous instmctions are a combination of a Name Holder instmction with either (i) a Name To Order instmction, (ii) a Name Consignee instruction: or (iii) a Blank Endorse instruction.
• Another allowed combination is a Name Pledgee Holder instmction simultaneous with a Name To Order instmction.
• Figure 37 also makes a distinction between two cases that occur as a result of the instmction: first when the Holder or Pledgee Holder does not change (signified by "0"); and second when the Holder or Pledgee Holder is a new party (signified by "1").
• Figure 38 indicates the handling of an Enforce Pledge instmction.
• Enforce Pledge instmction is issued, the only relevant element is the endorsement chain record which is created and delivered when the pledge is enforced on a BBL that has a named To Order party.
• the superscript 1 in Figure 38 indicates that the endorsement chain is delivered only with the Sender result.
• Grant Amendment with a new eBL version Figure 39 indicates the handling of a Grant Amendment instmction in the case that there is a new eBL version.
• the Originator can only issue a Grant Amendment with a new eBL version when it is replacing one BBL with another BBL.
• the endorsement chain is carried forward from the previous BBL.
• the only elements affected relate to an amendment that is granted to a Bearer Holder in which case an attonce notice is sent if the To Order party or Consignee is removed.
• Figure 40 indicates the handling of a Grant Amendment instmction in the case that there is a new eBL identifier.
• the Originator uses a new eBL identifier to replace one BBL, to combine BBLs and to split BBLs.
• attonce notices are generated in all instances in which there is a Bearer Holder, a Pledgee Holder or when the Holder is also the To Order party or Consignee.
• an endorsement chain record is created and delivered.
• the superscript 1 in Figure 40 indicates that, when multiple eBLs are returned with the Grant Amendment, multiple attomment notices will be delivered, and multiple endorsement chains records will be created and delivered.
• the result of the execution of a title registry instruction can be positive a negative. When the result is positive, the instmction has been executed successfully. If the result is negative, the instmction has not been executed, and a result message is returned to the sender. No message is forwarded to any system user in this case. Each negative error is described further with a reason source, reason code and reason description.
• Figure 41 lists and describes the errors a sender may receive as a result of validation errors or other errors in the incoming message. Internal system errors in the title registry or message handling unit are not included in the list. In all cases, the ReasonSource is TRA.
• each User agrees, as a condition of becoming a User of the System, to be bound by the provisions of a set of rules which are codified in a book of mles. referred to as the Rulebook.
• the Rulebook and the users' contractual agreement to it, underpins and enables the system to function as a support system for transactions in property in that it defines the legal significance of the contents of the database records and the legal effect of messages, for example. For completeness, the Rulebook is now reproduced.
• BBL Text A Document which: (a) is sent into the Message Handling Unit and recorded in the Title Registry as the documentary component of the Electronic Bill of Lading, and (b) acknowledges the receipt of goods by a Carrier for carriage by sea.
• Bearer Holder A User who is or becomes designated a Holder of a Blank-endorsed Electronic Bill of Lading
• Beneficiary User A User who is designated under a Documentary Credit as the party to whom, or to whose order, payment is to be made or whose bills of exchange are to be accepted and paid.
• Blank-endorse To render, by the process described in the Operating Procedures, an Electronic Bill of Lading capable of transfer simply by designation of a new Holder.
• Central System or System The business processes and methods, the digital information system provided by the service provider XYZ Ltd for communicating Messages and Documents and facilitating business transactions, and the Rules governing both.
• Carrier A User which contracts with another User to carry goods by any means of transport, regardless of whether the Carrier is the owner or operator of the means of transport used. Certificate: A unit of information which, at a minimum: (a) lists its Issuer by name; (b) lists a Public Key; (c) lists by name or otherwise indicates a User which holds the Private Key corresponding to the listed Public Key; (d) is Digitally Signed by its Issuer, and (e) has the meaning consistent with this definition ascribed to it in an associated documentary form.
• Certification Account The relationship between XYZ Ltd and a User, in which XYZ Ltd acts as Issuer of Certificates to the User, and the User acts as Subscriber of those Certificates.
• Certifier A person [authorized by XYZ Ltd] to Issue Certificates to Users.
• the Certifier which issued a particular Certificate is also termed its "Issuer”.
• Performing Bill of Lading An acknowledgment by a Carrier of the receipt of goods for carriage on board its ship in respect of which there is a charterparty, other than a bareboat or demise charter, concurrently in force in respect of the use of the ship either for the same voyage (voyage charter) or for a period of time (time charter) within which the said carriage is to take place.
• Consignee Holder A User simultaneously Designated as Consignee and Holder of an Electronic Bill of Lading.
• Communication Link The digital networking connection to the Central System to be established by the User.
• Consignee A User Designated as such, being thereby identified as the party to whom delivery of the goods must be made by the Carrier and also indicating the intention to make the Electronic Bill of Lading non-transferable
• Designation means the act of Designating or the state of having been Designated.
• Digital Signature A mathematical result calculated from a unit of digital information and a Private Key. such that one having the unit of information and the corresponding
• Public Key can, through Verification, accurately determine (1) whether that mathematical result was created using that Private Key, and (2) whether the unit of information has been altered since that mathematical result was calculated.
• Document Identifier The unique identifier of a Document sent into and tracked by the System.
• Head Charter A charterparty contract, other than a charter by demise or bareboat charter, between a Carrier, as owner or disponent owner of a ship and another User as charterer, for the use of the Carrier ' s ship for the purpose of carrying cargo either for a specific voyage or series of voyages or for a period of time.
• Head Charterer A User who has entered into a Head Charter with a Carrier.
• Holder-to-order A User who is or becomes simultaneously Designated both Holder and To order Party of an Electronic Bill of Lading.
• Message Any communication, document, notice or other information sent through the message handling unit and in a format described hereinabove.
• Message Handling Unit The messaging system maintained as part of the Central System by the Service Provider, as described hereinabove.
• Operational Service Contract The standard form contract between each User and
• Pledgee Holder A User who is or becomes Designated as both Pledgee and Holder simultaneously.
• Private Key The key of a Key Pair used to create a Digital Signature.
• Public Key The key of a Key Pair used to Verify a Digital Signature.
• Relying Party The person Verifying a Digital Signature, relying on the representations in a Certificate, or both.
• Revoke In relation to a Certificate, to include the Certificate in a class of Certificates, for which the Issuer of the Certificates gives notice that they (each or together) are
• Rules, Rule Book, or Rulebook The Rulebook. as amended from time to time, governing the relationship between Users and their use of the System.
• Sea Waybill A Document, other than a BBL Text or a Ship ' s Delivery Order, which is such a receipt for goods as contains or evidences a contract for the carriage of goods by sea and identifies a User to whom delivery of the goods is to be made by the Carrier in accordance with that contract.
• Services The services supplied by XYZ Ltd through the System and specified in the
• Shipper User which is the original contracting party with whom a Carrier enters into the contract for the carriage of goods by sea.
• Ship's Delivery Order A Document, other than a BBL Text or a Sea Waybill, which contains an undertaking to deliver identified goods to an identified User, given under or for the purposes of a contract of carriage by sea of those goods or of goods which include those goods
• Subscriber A person who is identified in a Certificate as holding a private key that corresponds to the Public Key listed in that Certificate.
• a Subscriber is often termed a
• Surrender The presentation of an Electronic Bill of Lading to the Carrier or another User appointed by the Carrier, in accordance with the Operational Rules, in order to obtain delivery of the goods at the end of the carriage by sea.
• Surrender Party A User who is or becomes Designated as such and thereby identified as the person to whom the Electronic Bill of Lading must be presented to obtain delivery of the goods at the end of the carriage by sea.
• Title Registry The System's central electronic repository of information used in trade transactions, particularly those related to shipping and Electronic Bills of Lading.
• the Title Registry is an application operated by XYZ Ltd providing the means to: (a) execute the functions relating to holdership and transfer of Electronic Bills of Lading; (b) maintain a record of the status of current Electronic Bills of Lading; and (c) maintain an audit trail of dealings with such Electronic Bills of Lading.
• Title Registry Instruction, Instruction The portion of a Type Header which directs the Title Registry to enter or change certain specified information in the Title Registry Record for a specified Electronic Bill of Lading.
• Title Registry Record The stmctured information in relation to transactions involving the Electronic Bill of Lading after its creation kept in the Title Registry and linked to the BBL Text.
• Transport Document Any Document originated by a Carrier which is either a Sea Waybill or a Ship's Delivery Order.
• To Order Party A User Designated as such who is not also designated as the Holder of the Electronic Bill of Lading.
• Type Header or Header The part of a Message that indicates its type and function within the System and conveys data into the System ' s logs, User Database, Title Registry, and other records, and, in some cases, prompts one or more actions by the System.
• the value of an ITU X.500 directory attribute, or similar item of data means that the content or value is the only one within a specified range and no equal or identical content or value exists within that range
• User A person who has Enrolled as a user of the System
• User Database The records concerning Users kept in the System.
• User Division Identifier The optional portion of a User Identifier which indicates department, division, subdivision, or other part of the identified User's organization.
• User Identifier A name Uniquely identifying a User within the System.
• User Manual The User Manual issued from time by XYZ Ltd generally to all Users.
• User Support Resources The online information and functions provided by XYZ
• Valid Certificate A Certificate which is valid according to the terms specified in its documentary form. If no such terms are specified or available to a User relying on that
• the Certificate is valid if has been signed by its Issuer and has not expired on its face or been Revoked as set out in the Operating Procedures.

Landscapes

• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Finance (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Marketing (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Storage Device Security (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Priority Applications (4)

Applications Claiming Priority (4)

Publications (2)

Family

ID=26315305

Family Applications (1)

Country Status (4)

Cited By (10)

Citations (4)

Family Cites Families (3)

• 1999
  • 1999-09-16 WO PCT/GB1999/003091 patent/WO2000055774A2/en active IP Right Grant
  • 1999-09-16 AU AU61000/99A patent/AU766313B2/en not_active Expired
  • 1999-09-16 EP EP99947612A patent/EP1181658A2/en not_active Ceased
  • 1999-09-16 JP JP2000605932A patent/JP2002539564A/ja active Pending

Patent Citations (4)

Also Published As

Similar Documents

Legal Events