Internet system for exchanging and organizing vessel transport information

Abstract

A ship chartering system is implemented on a computer or telecommunications network, such as the Internet, and is meant to supplement or replace services offered by current shipping brokers. The system allows a charterer to locate acceptable ships, receive bids from ship owners, and negotiate contract terms for their cargo. Ship owners are able to update their ship positions and cargo capabilities, add new ships to a database of available ships, and bid on the transportation of cargo entered by a charterer in an open market solicitation. In a preferred embodiment, both charterers and ship owners must subscribe to the system in order to access and participate in it.

Claims

I claim:

1. A method for providing an interface between charterers and ship owners, comprising:

receiving from a charterer an electronic description of cargo to be transported, its destination and location;

receiving from a ship owner an electronic description of a ship for transporting cargo;

processing the electronic descriptions to match the cargo with available ships;

transmitting from the ship owner to the charterer an offer by the ship owner to transport the cargo;

communicating acceptance of the offer by the charterer to the ship; and

creating a contract between the ship owner and the charterer, said contract comprising a provision that includes a charterer's option to determine a port/place for cargo loading and/or discharge within a negotiated loading and/or discharge range of ports/places.

2. The method of claim 1, wherein the cargo description is designated as public, the method further comprising:

communicating the cargo description to a plurality of ship owners.

3. The method of claim 1, wherein the cargo description is designated as private, the method further comprising:

communicating the cargo description to a designated ship owner.

4. The method of claim 1, wherein the cargo description includes at least one of a cargo quantity, a cargo type, a cargo load, a discharge requirement, a number of laydays, an indication of whether the cargo is public or private, a name of the charterer, and a loading region for the cargo.

5. The method of claim 1, wherein the ship description includes at least one of:

a ship name, a ship identification, a name of the ship owner, a deadweight, an overall length, a beam, a draft, a distance from a keel to a top of a mast, a cubic capacity, a hull type, an age, a flag, a classification society, a usual cargo, and a current ship position.

6. The method of claim 1, wherein the offer includes:

a rate for transporting the cargo.

7. The method of claim 1, wherein the communicating step further comprises:

communicating the offer to the charterer via an electronic mail message.

8. The method of claim 1, further comprising:

receiving a modification of the offer from the charterer; and

communicating the modification to the ship owner.

9. The method of claim 1, further comprising:

receiving a charter party contract including at least one term of the offer; and

storing the charter party contract in a memory.

10. The method of claim 1, further comprising:

receiving from the ship owner an update to the ship description.

11. The method of claim 1, further comprising:

receiving from the charterer an update to the cargo description.

12. The method of claim 1, further comprising:

charging a fee to at least one of: the charterer and the ship owner.

13. The method of claim 12, wherein the fee is a subscription fee.

14. The method of claim 12, wherein the fee is based on an amount of a charter party contract.

15. A computer-readable medium encoded with processing instructions for implementing a method, performed by a computer, for providing an interface between charterers and ship owners, the method comprising:

receiving from a charterer a description of cargo to be transported;

receiving from a ship owner a description of a ship for transporting cargo;

receiving from the ship owner an offer to transport the cargo;

communicating the offer by the ship owner to the charterer;

communicating acceptance of the offer by the charterer to the ship owner; and

creating a contract between the ship owner and the charterer, said contract comprising a provision that includes a charterer's option to determine a port/place for cargo loading and/or discharge within a negotiated loading and/or discharge range of ports/places.

16. An apparatus for providing an interface between charterers and ship owners, comprising:

means for receiving from a charterer a description of cargo to be transported;

means for receiving from a ship owner a description of a ship for transporting cargo;

means for receiving from the ship owner an offer to transport the cargo;

means for communicating the offer by the ship owner to the charterer

means for communicating acceptance of the offer by the charterer to the ship owner; and

means for creating a contract between the ship owner and the charterer, said contract comprising a provision that includes a charterer's option to determine a port/place for cargo loading and/or discharge within a negotiated loading and/or discharge range of ports/places.

17. An apparatus for providing an interface between charterers and ship owners, comprising:

a processor; and

a memory encoded with processing instructions for allowing the processor to:

receive from a charterer a description of cargo to be transported;

receive from a ship owner a description of a ship for transporting cargo;

receive from the ship owner an offer to transport the cargo;

communicate the offer by the ship owner to the charterer;

communicate acceptance of the offer by the charterer to the ship owner; and

create a contract between the ship owner and the charterer, said contract comprising a provision that includes a charterer's option to determine a port/place for cargo loading and/or discharge within a negotiated loading and/or discharge range of ports/places.

18. A method for submitting a cargo description for bidding by a ship owner, comprising:

transmitting a cargo description to a network site;

transmitting an indication that the cargo description is one of public and private;

receiving an offer from a ship owner for transporting the cargo

communicating the offer by the ship owner to a charterer;

communicating acceptance of the offer by the charterer to the ship owner; and

creating a contract between the ship owner and the charterer, said contract comprising a provision that includes a charterer's option to determine a port/place for cargo loading and/or discharge within a negotiated loading and/or discharge range of ports/places.

19. The method of claim 18, further comprising:

receiving a ship description with each received offer.

20. The method of claim 18, further comprising:

transmitting a modification of the offer.

21. The method of claim 18, wherein the cargo description is private, the method further comprising:

searching a ship database;

selecting a ship having a ship owner based on a ship description; and

transmitting, to the ship owner, a request for offer corresponding to the cargo description.

22. The method of claim 18, further comprising:

paying a fee to an operator of the network site.

23. The method of claim 22, wherein the fee is based on at least one of:

a subscription rate, a number of completed transactions, and a percentage of a charter party contract.

24. A method for bidding on a cargo description comprising:

transmitting a ship description to a network site;

searching a cargo database having a public cargo description;

selecting the cargo description;

transmitting an offer by a ship owner to transport a cargo corresponding to the cargo description, the offer including at least one contract provision and an indication of the ship description; and

creating a contract between the ship owner and a charterer, said contract comprising a provision that includes a charterer's option to determine a port/place for cargo loading and/or discharge within a negotiated loading and/or discharge range of ports/places.

25. The method of claim 24, further comprising:

receiving a modification of the offer.

26. The method of claim 24, further comprising:

paying a fee to the network site.

27. The method of claim 24, further comprising:

paying a fee to an operator of the network site.

28. The method of claim 27, wherein the fee is based on at least one of:

a subscription rate, a number of completed transactions, and a percentage of a charter party contract.

29. A method for bidding on a cargo description comprising:

transmitting a ship description to a network site;

receiving a private cargo description from a charterer and a request for offer, based on the ship description;

transmitting an offer by the ship owner to transport a cargo corresponding to the private cargo description, the offer including at least one contract provision;

receiving an acceptance of the offer by a charterer; and

creating a contract between the ship owner and the charterer, said contract comprising a provision that includes a charterer's option to determine a port/place for cargo loading and/or discharge within a negotiated loading and/or discharge range of ports/places.

30. The method of claim 29, further comprising:

receiving a modification of the offer.

31. The method of claim 30, further comprising:

paying a fee to an operator of the network site.

32. The method of claim 30, wherein the fee is based on at least one of:

a subscription rate, a number of completed transactions, and a percentage of a charter party contract.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to data processing for business applications and, more particularly, to booking systems for negotiating terms and reserving space on transport vessels.

2. Description of the Related Art

In the field of ship chartering, a typical transaction between a charterer, e.g. one who wishes to ship cargo, and a ship owner, e.g. one who may be hired to transport the cargo, usually requires the engagement of a shipping broker to bring the parties together and to effectuate a shipping agreement (referred to herein as a "fixture" or a "charter party" contract). This is because information on available ships is usually not widely available to charterers. Likewise, charterers generally have no forum, outside of brokers, for publicizing their chartering needs to ship owners on the open market. If such information were to become available to the shipping market at large, outside of the influence of brokers, significant savings in time and expense to both charterers and ship owners could be realized.

A broker typically earns a commission of 1.25% of the fixture. This percentage is then usually charged by the broker to both parties. An average fixture for the spot tanker market in 1992 was $459,800, leading to an average commission of $11,495. A broker may complete 25-30 fixtures per week, totaling $287,375 to $344,850 a week in commissions, or $14,943,500 to $17,932,200 a year. Thus, brokers in the spot tanker chartering market earn significant revenues for themselves, which in turn adds millions of dollars to chartering transactions each year.

Accordingly, it would be advantageous to provide a forum wherein shipping information is directly available to both charterers and ship owners in order to allow for the negotiation of fixtures or charter parties without enlisting a broker.

BRIEF SUMMARY OF THE INVENTION

In order to address and solve certain of the foregoing shortcomings in the prior art, the present invention provides a method and accompanying apparatus which allow charterers and ship owners to exchange cargo transportation information without the assistance of a broker. In a first embodiment, the method includes providing an electronic network site for receiving and storing information from both charterers and ship owners in order to more readily accomplish agreements for cargo transport. The network site is operative to process the received information so as to provide to the charterer a listing of ships, which fit criteria established by the charterer, from among the information supplied by the ship owners.

In a second embodiment, a method of brokerless arrangement for the shipment of cargoes includes providing for direct negotiations between a charterer and a ship owner by making information concerning the charter directly available to both the charterer and the ship owner without the use of a broker.

In a further embodiment of the present invention, the cargo transportation information is provided on forms or templates.

In yet another embodiment of the present invention the processing step includes a matching step in which criteria from the charterer is matched with ship descriptions and availability stored on the network site.

In still another embodiment, a method of the present invention further includes a step of initiating communication between the charterer and the ship owner whose ship fits the criteria established by the charterer, wherein such direct communication may be facilitated by e-mail.

In a still further embodiment, a method of the present invention further includes the step of providing the ship owner with an on-screen display of the standard terms used by the charterer, which, in turn, may enable more rapid agreement between the charterer and the ship owner.

In a further embodiment of the present invention, the network site may memorialize the agreement between the ship owner and the charterer in the form of a fixture. This may be accomplished, for example, by automatically generating a charter party contract based on the fixture.

In a still further embodiment, a method of the present invention may further include the payment of a commission to the owner of the network site.

In yet another embodiment, the network site may be implemented on the Internet or on a private network.

In another embodiment of the present invention, the network site may further include a central database accessible by the charterer and the ship owner, and maintained at the network site. The database may include information such as ship descriptions and positions. The database may further include a plurality of fixtures which are authorized by one or more charterers and owners to be placed in the database, and publicly or privately viewed. The database may further include co-loading cargo information and financing information.

It is therefore an advantage of certain embodiments of the present invention that an interactive network site can store up-to-date information for use by ship owners and charterers which enable them to negotiate and enter into charter party contracts.

It is a further advantage of certain embodiments of the present invention that ship owners and charterers may agree to terms of fixtures and charter party contracts by communicating directly through a network site rather than through a traditional broker.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Further aspects of the instant invention will be more readily appreciated upon review of the detailed description of the preferred embodiments included below when taken in conjunction with the accompanying drawings, of which:

FIG. 1 is a schematic diagram of a communications network for use with the present invention, which allows charterers and ship owners to communicate with a network site;

FIG. 2 is a schematic block diagram of exemplary components of the network site of FIG. 1;

FIG. 3 is a representation of an exemplary ship database stored by the central server of FIG. 2;

FIG. 4 is a representation of an exemplary contracts database stored by the network site of FIG. 2;

FIG. 5 is a representation of an exemplary user profile database stored by the network site of FIG. 2;

FIG. 6 is a representation of an exemplary cargo database stored by the network site of FIG. 2;

FIG. 7 is a representation of an exemplary offers database stored by the network site of FIG. 2;

FIG. 8 is a representation of an exemplary forms database stored by the network site of FIG. 2;

FIG. 9 is a representation of an exemplary preferences database stored by the network site of FIG. 2;

FIG. 10 is a representation of an exemplary trade sheet database stored by the network site of FIG. 2;

FIG. 11 is a representation of an exemplary clauses database stored by the network site of FIG. 2;

FIG. 12 is a representation of an exemplary e-mail database stored by the network site of FIG. 2;

FIG. 13 is a representation of an exemplary help database stored by the network site of FIG. 2;

FIG. 14 is a representation of an exemplary log file database stored by the network site of FIG. 2;

FIG. 15 is a flowchart representing exemplary steps performed by a ship owner for negotiating a fixture according to one embodiment of the present invention;

FIG. 16 is a flowchart representing exemplary steps performed by a charterer for negotiating a fixture according to one embodiment of the present invention;

FIG. 17 is an exemplary set of main menu functions provided to a user of the network site of FIG. 2;

FIG. 18 is a flowchart representing exemplary steps performed by a ship owner for updating ship positions according to one embodiment of the present invention;

FIG. 19 is a flowchart representing exemplary steps performed by a user for accessing a ship position list according to one embodiment of the present invention;

FIG. 20 is a flowchart representing exemplary steps performed by a ship owner for updating ship specifications according to one embodiment of the present invention;

FIG. 21 is a flowchart representing exemplary steps performed by a user for viewing ship specifications according to one embodiment of the present invention;

FIG. 22 is a flowchart representing exemplary steps performed by a charterer for listing and updating cargo according to one embodiment of the present invention;

FIG. 23 is a flowchart representing exemplary steps performed by a user for viewing listed cargo according to one embodiment of the present invention;

FIG. 24 is a flowchart representing exemplary steps performed by a user for generating and viewing a daily fixture report according to one embodiment of the present invention;

FIG. 25 is a flowchart representing exemplary steps performed by a user for generating and viewing a custom fixture report according to one embodiment of the present invention;

FIG. 26 is a flowchart representing exemplary steps performed by a ship owner for submitting an offer to ship listed cargo according to one embodiment of the present invention;

FIG. 27 is a flowchart representing exemplary steps performed by a charterer for negotiating a fixture according to a further embodiment of the present invention;

FIG. 28 is a flowchart representing exemplary steps performed by a ship owner for negotiating a fixture according to a further embodiment of the present invention;

FIG. 29 is a flowchart representing exemplary steps performed by a user for accessing stored charter party forms according to one embodiment of the present invention;

FIG. 30 is a flowchart representing exemplary steps performed by a user for accessing stored standard contract clauses according to one embodiment of the present invention;

FIG. 31 is a flowchart representing exemplary steps performed by a user for accessing stored trade sheets according to one embodiment of the present invention;

FIG. 32 is a flowchart representing exemplary steps performed by a user for accessing a user list according to one embodiment of the present invention;

FIG. 33 is a flowchart representing exemplary steps performed by a user for changing user preferences according to one embodiment of the present invention;

FIG. 34 is a flowchart representing exemplary steps performed by a user for contacting a site administrator according to one embodiment of the present invention; and

FIG. 35 is a flowchart representing exemplary steps performed by a user for accessing help functions according to one embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring now to FIGS. 1-35, wherein similar components of the instant invention are referenced in like manner, a preferred apparatus for allowing charterers and ship owners to exchange information and negotiate charter parties, and accompanying methods for using the same, are disclosed.

Turning now to FIG. 1, depicted therein is an exemplary computer network 10 by which a plurality of charterers, using charterer terminals 20a-20c may interact with a plurality of ship owners, using owner terminals 30a-30c, via network site 40 in any known manner. Although computer network 10 is preferably an Internet-based network, it may be any one or more of a local area network (LAN), a wide-area network (WAN), an intranet environment, an extranet environment, a broadband wireless network or other type of computer or communications network, such as those enabled over public switched telephone networks. Remote terminals 20, 30 may be any computing device, such as a personal computer, a workstation, a network terminal, a wireless Internet access device or any other device that can communicate with the network site 40 over the computer network 10. Remote terminals 20, 30 may include one or more charterer remote terminals 20a-20c and one or more ship owner remote terminals 30a-30c as described further hereinbelow. Network site 40 may include any number of computer servers which cooperate to maintain the system of the present invention and perform the methods for using the same.

In one embodiment of the present invention, a network site 40 may maintain a web site which is hosted on the Internet. A charterer or ship owner may communicate with the server 40 through remote terminals 20, 30 which may be equipped with hardware and software that accommodates Internet access over the computer network 10. In the alternative, the network site 40 may host a bulletin board site or a separate community of network servers, such as those maintained by AMERICA ONLINE. In that case, a charterer or a ship owner may communicate with the network site 40 by dialing directly into the network site 40 using the appropriate remote terminal 20, 30 which, in turn, may be equipped with a modem or the like that can transmit and receive data over a public switched telephone network. Other variations and configurations of the computer network 10 will be apparent to one of ordinary skill in the art.

Turning now to FIG. 2, displayed therein are exemplary components of the server 40 which may be necessary to implement the present invention. Although the descriptions below may be additionally applicable to either type of remote terminal 20, 30, the components will be discussed with regard to network site 40 for the sake of brevity.

The primary component of network site 40 is a processor 41, which may be any commonly available microprocessor, such as the PENTIUM III manufactured by INTEL CORP. The processor 41 may be operatively connected to further exemplary components, such as RAM/ROM 42, a clock 43, input/output devices 44, and a memory 45 which stores one or more operating system and application programs 46 as well as a plurality of databases 47-58, described further hereinbelow.

The processor 41 operates in conjunction with random access memory and read-only memory in a manner well known in the art. The random-access memory (RAM) portion of RAM/ROM 42 may be a suitable number of Single In-line Memory Module (SIMM) chips having a storage capacity (typically measured in kilobytes or megabytes) sufficient to store and transfer, inter alia, processing instructions utilized by the processor 41 which may be received from the programs 46. The read-only memory (ROM) portion of RAM/ROM 42 may be any permanent non-rewritable memory medium capable of storing and transferring, inter alia, processing instructions performed by the processor 41 during a start-up routine of the network site 40. Further functions of RAM/ROM 42 will be apparent to one of ordinary skill in the art.

The clock 43 may be an on-board component of the processor 41 which dictates a clock speed (typically measured in MHz) at which the processor 41 performs and synchronizes, inter alia, communication between the internal components of the network site 40. Further functions of the clock 43 will be known to one of ordinary skill in the art.

The input/output device(s) 44 may be one or more commonly known devices used for receiving operator inputs, network data, and the like and transmitting the same to the remote terminals 20, 30. Accordingly, exemplary input devices may include a keyboard, a mouse, a voice recognition unit and the like for receiving user inputs.

Exemplary output devices may include any commonly known devices used to present data to an operator of the network site 40 or to transmit data over the computer network 10. Accordingly, suitable output devices may include a display, a printer and a voice synthesizer connected to a speaker.

Other input/output devices 44 may include a telephonic or network connection device, such as a telephone modem, a wireless modem, a cable modem, a T-1 connection, a digital subscriber line or a network card, for communicating data to and from other computer devices 20, 30 over the computer network 10. It is preferable that any network or communication devices used as input/output devices 44 be of the type that can handle high bandwidth or large amounts of network traffic as is consistent with the operation of an Internet web server and the like.

The memory 45 may be an internal or external large capacity device for storing computer processing instructions, computer-readable data, and the like. The storage capacity of the memory 45 is typically measured in megabytes or gigabytes. Accordingly, the memory 45 may be one or more of the following: a floppy disk in conjunction with a floppy disk drive, a hard disk drive, a CD-ROM disk and reader/writer, a DVD disk and reader/writer, a ZIP disk and a ZIP drive of the type manufactured by IOMEGA CORP., and/or any other computer readable medium that may be encoded with processing instructions in a read-only or read-write format. Further functions of, and available devices for, memory 45 will be apparent to one of ordinary skill in the art.

The memory 45 may store, inter alia, a plurality of programs 46 which may include, for example, an operating system such as WINDOWS NT by MICROSOFT CORP. The memory 45 may further store one or more application programs which are necessary to implement the embodiments of the present invention, such as a database program for managing databases 46-58, and a web hosting program for presenting users with preformatted web pages or other appropriate interfaces.

The database program may be any large volume data management software, and is preferably an SQL-based relational database management program of the type manufactured by ORACLE. The web hosting program may allow pre-formatted web pages that allow users to perform the processes described below with respect to FIGS. 15-35. Such programs may be written in HTML, XML, JAVA Script, and the like. Memory 25 may contain further programs which contain processing instructions for implementing the methods disclosed herein.

FIG. 3 depicts an exemplary ship database 47 which may be stored on network site 40 according to the present invention. The ship database 47 is operative to store data for a plurality of ships in order to allow charterers to find a ship suiting their cargo transport needs. Accordingly, the ship database 47 may have a plurality of fields for storing a plurality of ship names, ship identifications, and owners of each ship stored therein. Further ship statistics may be stored for each ship, such as, deadweight, overall length (loa), beam, draft, distance from keel to top of mast, cubic capacity, hull type, age, flag (i.e., the nation in which the ship is registered), classification society, usual cargoes, current ship position/location and the like. All these factors may be used to negotiate and determine whether a particular ship is suitable, as well as to determine an acceptable fee for transportation of cargo.

FIG. 4 depicts an exemplary fixture or contract database 48 which may be stored on network site 40 according to the present invention. The contract database 48 is operative to store data for a plurality of contracts that have been entered into by subscribers (i.e., charterers and ship owners) of the network site 40. Such stored contracts may be used by other users of the network site 40 as a model for contract negotiations. Accordingly, the contract database 48 may have a plurality of fields for storing fixture dates, names of ships involved, cargo quantities involved, cargo types, load dates, load ranges, discharge ranges, cargo rates, names of charterers, and other information that is determinable from typical charter party contracts. The information in this database may be provided to other charterers and ship owners, upon approval of the contracting parties, so that other charterers and ship owners may gain insight into the current market conditions for shipping contracts. Otherwise, this database 48 serves to preserve agreements entered into by subscribers of the network site 40 in case of later conflict. An example of a stored charter party contract is provided hereinbelow.

FIG. 5 depicts an exemplary user profile database 49 which may be stored on network site 40 according to the present invention. The user profile database 49 is operative to store data for a plurality of ship owners and charterers who, for example, may subscribe to the service provided by network site 40 as described herein. The user profile database 49 stores information on each such subscriber for reference by the system or for examination by other subscribers. Accordingly, the user profile database 49 may have a plurality of fields for storing a login identification, a password, a name, an address, contact information (such as an e-mail address, telephone number, cellular telephone number, pager number and the like), as well as an indication of whether the user is a charterer or a ship owner. As will be apparent to one of ordinary skill in the art, the login identification and password fields, as well as other sensitive information, may be shielded through encryption and the like from all but the actual user to whom they correspond, in order to protect against fraud.

FIG. 6 depicts an exemplary cargo database 50 which may be stored on network site 40 according to the present invention. The cargo database 50 is operative to store data entered by a plurality of charterers so that ship owners may bid on a rate for transporting the cargo. The charterers input rate offers into the cargo database 50, which are reviewed by the ship owners. If a ship owner finds a particular rate acceptable, the ship owner selects that rate for transporting cargo from the cargo database 50. Accordingly, the cargo database 50 may have a plurality of fields for storing a cargo quantity, a cargo type, a cargo load, discharge requirements, required lay days, an indication of whether the cargo may be publicly or privately bid, the name or other identification of the charterer, and the loading region for the cargo. All these factors may be used to negotiate and determine an acceptable rate or fee for transportation of cargo corresponding to each stored description.

FIG. 7 depicts an exemplary offers database 51 which may be stored on network site 40 according to the present invention. The offers database 51 is operative to store offers made by ship owners to charterers for handling a particular cargo. Accordingly, the offers database 51 may have a plurality of fields for storing a cargo quantity to which the offer relates, the cargo type, the load range, discharge requirements, range limitations, lay days involved in the transaction, shipping rates, demurrer rates, rider clauses and any other negotiable or non-negotiable data to be affiliated with a particular offer. The offer may be stored for a predetermined time, until accepted or rejected by a charterer.

Typically, charter party contracts or fixtures contain many standardized contract clauses and the like. Thus, many features of fixtures, even those involving various parties, may tend to resemble each other in form and substance, with variations in certain negotiable terms. Accordingly, charterers and ship owners would require access to standard forms in order to more readily accomplish the completion of a charter party contract. FIG. 8, then, depicts an exemplary forms database 52 which may be stored on network site 40 according to the present invention. The forms database 52 may store a plurality of forms for use by subscribers and the like, including charter party forms, standard riders and contract addenda. FIG. 9 depicts an exemplary preferences database 53 which may be stored on network site 40 according to the present invention. The preferences database 53 is operative to store user-defined preferences corresponding to each subscriber or user of the network site 40. Accordingly, the preference database 53 allows each user to determine and store, for example, which menus from menu system 1700 (FIG. 17) are to be presented upon login and the order in which the user wishes the fields to be presented. Other user preferences that may be applied will be apparent to one of ordinary skill in the art.

Trade sheets are commonly available in the chartering market. Trade sheets are published by charterers and contain standard elements of a charter party contract in negotiable form. Accordingly, it would be useful to post such trade sheets on the network site 40 for use by subscribers during negotiations. FIG. 10 thus depicts an exemplary trade sheet database 54 that may be stored on network site 40. The trade sheet database 54 may have exemplary fields for storing the source of the trade sheet (i.e., the company or party who published it), the date of the trade sheet and the information contained in each trade sheet.

FIG. 11 depicts an exemplary clauses database 55 which may be stored on network site 40 according to the present invention. The clauses database 55 is operative to store a plurality of standard clauses such as are displayed in Part II of the sample Tanker Voyage Charter Party provided below. Accordingly, the clauses database 55 may have a plurality of fields for storing standard charter party clauses such as warranties, voyage requirements, full cargo clauses, bunker replacement clauses, freight, nomination of loading and discharge ports, estimated time of arrival, notice of readiness provisions, cancellations, laytime and demurrage. Other standard charter party clauses may likewise be stored.

There may be times when a user or subscriber may wish to contact the operator of the network site 40 or another subscriber. The most commonplace way for accomplishing this is through an electronic mail (e-mail) message. It is contemplated that the network site 40 will allow for inter-party electronic communication. In order to keep a record of such communications, the network site 40 may maintain an e-mail database 56 as depicted in FIG. 12. The e-mail database 56 may include a plurality of fields including the party to whom the message was addressed, the party who sent the message, the date of the message, the subject line of the message and the text of the message. Messages may be stored for a predetermined amount of time, or my be deleted by the sending or receiving party at their discretion. In addition to e-mail, other types of electronic communication, such as facsimile or instant messaging may be employed.

It is further contemplated that a user or subscriber of the network site 40 may need help to accomplish a desired function. Rather then sending a message to an operator or administrator of the network site 40, a help database 57, such as is depicted in FIG. 13 may be stored for access by users or subscribers of the system. Accordingly, the help database 57 may contain an index of searchable terms or keywords that a subscriber may review. The help database 57 may further contain text instructions that correspond to each keyword for assisting the subscriber in performing or completing a desired function.

FIG. 14 depicts an exemplary log file database 58 which may be stored on network site 40 according to the present invention. The log file database 58 is operative to store a record of transactions which take place on network 40. Such a database may be useful, for example, to reconstruct current data if the site 40 experiences a crash between backups. Accordingly, the log file database 58 may have a plurality of fields for storing the date and time of a transaction on the site 40, the user id of the user initiating the transaction and the type of transaction (i.e. a change in user preferences, the transmission of an offer, or any other transaction contemplated as being part of the present invention). Other data may likewise be stored in log file database 58.

Regarding the databases described above with respect to FIGS. 3-14, it should be noted that the illustrated databases may vary from the examples provided. For example, further or fewer fields may be provided, or databases may be combined, integrated or further sub-divided as will be appreciated by one of ordinary skill in the art. In addition, field titles may be altered from those presented above without impacting the spirit and scope of the present invention. Furthermore, alternative data structures, other than standard database formats, may be readily employed.

Turning now to FIG. 15, therein is depicted an exemplary process 1500 performed by a ship owner for negotiating a charter party contract. The process 1500 is initiated when a ship owner, using remote terminal 30a logs into the network site 40 (step 1502). The site 40 compares the entered login identification (i.d.) and password to those stored in the user profile database 49. If the i.d. and password are verified, the site 40 allows the ship owner to access various information including the ship owner's information stored in the ship database 47. The ship owner may then, for example, update particular ship information (step 1504) including, for example, a current position of the ship. The update may then be stored in the ship database 47 so that other subscribers may review it.

A charterer having cargo requirements which match the ship owner's ship information may then contact the ship owner, e.g. via e-mail, and enter negotiations for completing a charter party contract (step 1506). If the negotiations are successful both parties then finalize a charter party agreement and the system stores the contract in the contract database 48 (step 1508).

Turning to FIG. 16, a therein is depicted an exemplary process 1600 performed by a charterer for negotiating a charter party contract with a ship owner. The process 1600 is initiated when a charterer, using remote terminal 20a, logs into the network site 40 (step 1602). The site 40 compares the entered login i.d. and password to those stored in the user profile database 49. If the i.d. and password are verified, the site 40 allows the charterer to access various information including searching ship and cargo data entered by a plurality of ship owners, which is stored in the ship database 47 (step 1604) including, for example, a current position of the ship, an availability of the ship and the like.

If the Charterer finds one or more suitable ships, he or she may send messages to the owners to begin negotiations. Also, the ship owner may review the parameters entered by the charterer and, if they match the ship owner's ship information, the ship owner may alternatively contact the charterer, e.g. via e-mail, and enter negotiations for completing a charter party contract (step 1606). If the negotiations are successful both parties then finalize a charter party agreement and the system stores the contract in the contract database 48 (step 1608).

FIG. 17 displays a list of main menu functions 1702-1736 which may be available in a system of the present invention and which are each described in further detail below with respect to FIGS. 18-35. For each process depicted in FIGS. 17-35, it should be noted that steps on the left portion of each flowchart may be performed by users or subscribers accessing the system. Additionally, the steps on the right portion of the flowcharts may be performed by the network site 40. It is contemplated that in order to access the main menu features of the system of the present invention, a user may be required to enter a valid user identification and password. It is further contemplated that in order to access certain of the functions, the user i.d. and password must be re-entered each time that function is requested. An exemplary process 1701 for re-entering the user i.d. and password is therefore presented in FIG. 17.

The process 1701 begins when a user requests a particular function, for example, a request to update ship specifications 1706, to view ship specifications 1708, to list and update cargos 1710 and to view available cargoes 1712. After one of the designated functions has been requested, the system requires the user to enter the user's i.d. and password (step 1740). The system then verifies that the entered i.d. and password are valid (step 1742). If the i.d. and/or the password are invalid, the system presents an "invalid user/password" message to the user (step 1744) and the user is returned to the main menu. If the entered i.d. and password are valid, the system processes the requested function (step 1746), formats a screen display corresponding to the request (step 1748) and transmits the screen presentation data to the user's remote terminal (step 1750). The user may then view the screen containing the requested information (step 1752). If the user requests further functions which require the re-entry of an i.d. and password (step 1754), then process 1701 returns to step 1740, discussed above. Otherwise, process 1701 ends.

A first process 1800 available to users of the system of the present invention, allows ship owners to update ship positions by selecting the "update ship position function" 1702. Upon actuating a virtual button corresponding to function 1702, which is presented on the main menu 1700 of the user's display, the system sends a ship list corresponding to one or more ships owned or operated by the owner (step 1802). The ship list may include ship names, the deadweight of each ship and the year each ship was built. The owner than selects a ship for updating by designating one of the ships on the list (step 1804). The system then accesses the ship database 47 and retrieves current ship parameters, such as the next date the ship is available, the next port where the ship will be available, the ship's ballast speed, the ship's last cargo, the ship's last charterer, the last update to information for the ship, etc (step 1806). The information is then displayed to the ship owner (step 1808).

The ship owner may then update the desired ship information by entering the update data into a remote terminal 30 and transmitting the same to the network site 40 (step 1810). The site 40 then stores the new data in the appropriate fields of ship database 47 (step 1812), and transmits an acknowledgment of the update to the ship owner (step 1814), which is displayed on the ship owners remote terminal (step 1816). A record of the update may further be stored in the log file.

The system then presents to the owner the option of updating another ship (step 1820). If the ship owner wishes to update another ship, the process 1800 returns to step 1804, described above. If the ship owner indicates that there are no other ships that are to be updated, process 1800 ends and the ship owner is returned to the main menu 1700 (step 1822). Process 1800 may be used to add a new ship as well as to update current ships stored by the system.

A user of the system of the present invention may also select a `position list` function 1704 which will display ships having designated parameters to the user. A process 1900 for presenting such information starts when the user activates a virtual button which corresponds to the function (step 1704). A screen for entering particular ship parameters is then transmitted to the user (step 1902). The user may then enter ship parameters which define the type of ship in which the user is interested (step 1904). Such parameters may include the ship's next open port, the date range in which the ship is needed, the cargo type, hull type, maximum age, as well as minimum or maximum values for ship deadweight, draft, overall length, beam and cubic capacity. The system then compares the entered parameters to values stored in the ship database 47 (step 1906). The system then generates a list of ships matching the entered criteria and presents it to the user for review (step 1908). The user is then given the option to print the ship list (step 1910). If the user indicates that the list is to be printed, the list is then printed, for example on printer 21, 31 which is in communication with the user terminal 20,30 as shown in FIG. 1. If the user does not wish to print the ship list, the process 1900 continues to step 1912, where the user may select more information for a particular ship. If the user wishes to view more information for a particular ship the process 1900 continues to step 1916, discussed below. If, however, the user does not select more information for a particular ship, the process 1900 continues to step 1914, where the user may revise the previously entered ship parameters. If the user wishes to revise entered ship parameters, process 1900 returns to step 1904, described above. Otherwise, the process 1900 ends.

At step 1916, the user may select a ship for which more information is to be presented. The system prepares a form to display the further ship information by accessing the ship database 47 and transmitting the form with the completed information to the user (step 1918). The user may then review the further ship information (step 1920). The system then inquires whether the user wishes to view more ship information for another ship (step 1922). If so, the process 1900 returns to step 1908, described above. Otherwise, the process 1900 continues to step 1924, where the user is asked whether the further ship information is to be printed. If the user wishes to print the further ship information, the user directs the information to be printed (step 1926).

If the user does not wish to print the further information, the process 1900 continues to step 1928 where the user can specify that more specific information be presented on the subject ship, if available. If there is more information to present and the user wishes to heave it displayed, the user selects the form corresponding to the desired information (step 1930) and the process returns to step 1918, discussed above. If the user does not wish to have more information presented, the process continues to step 1932. At step 1932, the user is presented with the option to receive a new list of ships. If the user wishes to view a new list of ships, the process 1900 returns to step 1902, otherwise the process 1900 continues to step 1934.

At step 1934, if the user finds an acceptable ship, he may start negotiations by requesting that an offer be made by the ship owner to transport desired cargo. The cargo information is entered (step 1936), designated as public or private information, and stored in the cargo database 50. Then the request for an offer is preferably transmitted to the owner of the ship (step 1938), preferably via e-mail, and the communication may then be stored in e-mail database 56. If, on the other hand, the user at step 1934 does not wish to enter a request for an offer, process 1900 ends.

Turning now to FIG. 20, therein is depicted an exemplary process 2000 for allowing a ship owner to update ship specifications. An "update ship specifications" button 1702 may be provided on the main menu 1700. Upon activation of the button 1706, the system executes an exemplary process 2000 for updating stored ship specifications. The process 2000 begins where the list of all ship owned by the owner is retrieved from the ship database 47 and transmitted to the ship owner (step 2002). The ship owner may then select a ship and a form or template corresponding to the information that is to be added, deleted, transferred or updated (step 2004). If information is to be updated, the process 2000 continues to step 2022. Otherwise, the process continues to step 2006, discussed further hereinbelow.

At step 2022, the system receives a description of the ship from the ship owner and retrieves the record corresponding to that ship from the ship database 47. The currently stored information is transmitted to the ship owner and presented in a predefined form (step 2024). The ship owner may then select whether the information is to be updated (step 2026). If so, the updated ship information is entered by the ship owner and transmitted to the system for storing in the ship database 47 (step 2028). After the information has been updated, or if the ship owner does not wish to update the ship information, the process 2000 continues to step 2030, where the owner has the option of selecting another ship to update.

If the owner wishes to update another ship, the process 2000 returns to step 2004 discussed above. Otherwise the process 2000 continues to step 2032, where the owner is asked whether the ship information is to be printed (step 2032). If so, the process 2000 continues to step 2034 where the information is printed. Otherwise, the process 2000 ends.

If the ship owner instead requests to add or delete a ship, process 2000 continues to step 2006 from step 2004. The ship owner is first asked whether a new ship is to be added. If so, the process 2000 continues to step 2008 where the new ship specifications are entered by the ship owner. The new ship information is then added to the ship database 47 (step 2010). If instead, the ship owner wishes to delete a ship, the process 2000 continues to step 2012 from step 2006. The ship owner selects the ship to be deleted (step 2014) and the ship information is removed from the ship database 47.

If the user does not wish to delete a ship, then process 2000 continues to step 2016, where the user may change the ship data to reflect that a new owner or charter authority controls the ship. The name of the new owner or authority is entered at step 2018 and transmitted to the system for storage in the ship database 47 (step 2020).

The transaction between the ship owner and the system in which updates, transfers, additions or deletions to the ship database 47 may be recorded in a log file as discussed above.

Referring now to FIG. 21, therein is depicted an exemplary process 2100 for allowing a user to view various ship specifications for a ship already known to the user. A "view ship specifications" button 1708 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1708, the system initiates the process 2100.

The process 2100 begins where a request form to be completed by the user is transmitted to the user's remote terminal 20, 30 (step 2102). The user enters the desired ship criteria into the appropriate places on the form (step 2104). Such criteria may include a ship's name, deadweight, the year it was built, the owner, or any other particular ship data. The system uses the entered criteria to retrieve the corresponding ship data from the ship database 47 (step 2106). If the ship data is found (step 2108), the process continues to step 2110 below. Otherwise, the process returns to step 2104 where the user is requested to enter new data.

At step 2110, a list of one or more ships that match the entered criteria are transmitted to the user. The user may then select the desired ship and a form containing the data in which the user is interested in reviewing (step 2112). The system then fills in the form information from data stored in the ship database 47 (step 2114) and transmits the data for display on the user terminal (step 2116).

The process 2100 continues to step 2118 where the user is presented with the option of selecting another form containing further ship data. If the user wishes to view further forms of data, the process 2100 returns to step 2112 above. Otherwise, the process continues to step 2120.

At step 2120, the user is presented with the option to review ship specifications for another ship. If the user decides to view ship data for another ship, the process returns to step 2104 above. Otherwise, the process continues to step 2122, where the user is presented with the option of printing the data. If the user so chooses, the retrieved data may be printed (step 2124). Otherwise the process 2100 ends.

Turning now to FIG. 22, depicted therein is an exemplary process 2200 for allowing a charterer to list and update available cargoes. A "list and update cargo" button 1710 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1710, the system executes the process 2200 which begins at step 2201 where a list of available cargoes is retrieved from the cargo database 50 and transmitted to the charterer.

The charterer may choose a particular cargo for viewing (step 2202). It is contemplated that cargoes entered into the system may be of two types, public or private. A public cargo is available for viewing by all users of the system. A private cargo, on the other hand, is entered and stored in cargo database 50, but may only be viewed by ship owners or other users designated by the party who entered the cargo data.

After a cargo has been presented, the charterer may periodically refresh the screen display to confirm that no new data has been entered for the cargo (step 2204). The cargo listing may then be viewed in detail (steps 2206 and 2208).

At step 2210, the charterer is asked whether he or she wishes to enter new cargo data. If so, the cargo data is entered at step 2212 and stored in the cargo database 50. Otherwise, the process continues to step 2214.

At step 2214, the charterer is asked whether he or she wishes to update existing cargo data. Only data originally entered by the charterer may be updated. If the charterer wishes to update any data, the update is entered at step 2216 and stored in the cargo database 50. Otherwise the process continues to step 2218.

At step 2218, the charterer is asked whether he or she wishes to delete existing cargo data. Only data originally entered by the charterer may be deleted. If the charterer wishes to delete any data, the request is executed at step 2220 and removed from the cargo database 50. Otherwise the process continues to step 2222.

At step 2222, the charterer is asked whether he or she wishes to print any of the displayed cargo data. If so, the cargo data is printed at step 2224. Otherwise the process continues to step 2226.

At step 2226, the charterer is asked whether he or she wishes to quote particular cargo data to other users. Only data originally entered by the charterer may be quoted. If so, the quote is received by the system (step 2228) stored in the e-mail database 56 and communicated, preferably by e-mail, to other subscribers of the system (step 2230), after which process 2200 ends.

Referring now to FIG. 23, there is depicted an exemplary process 2300 for allowing a user to view available cargoes. A "view cargo" button 1712 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1712, the system executes the process 2300 which begins at step 2301 where a list of available cargoes is retrieved from the cargo database 50 and transmitted to the user.

The user may then select a particular cargo from the list for viewing (step 2302). The user may search for cargo meeting certain criteria by entering a search request (step 2304). The system compares the request to data stored within the cargo database 50 and presents any returns to the user at step 2310, described below.

If, however, the user selects a cargo from the list presented, the user is then asked whether the listing should be printed (step 2306). If so, the selected cargo is printed at step 2308. Otherwise, the process 2300 continues to step 2310.

At step 2310, particular information corresponding to the cargo is presented to the user in a predefined format. The system then inquires whether the user would like to print the displayed cargo (step 2312) and if so, the listing is printed at step 2314. Otherwise, the process 2300 continues to step 2316.

At step 2316, the system inquires whether the user would like to select another cargo listing. If so, the process returns to step 2302, described above. Otherwise, the process 2300 continues to step 2318.

At step 2318, the user is asked whether they would like to place an offer on the cargo. If so, the offer is accepted and sent, preferably via e-mail, to the user who posted the cargo (step 2320). The terms of the offer may be parsed and stored in the offers database 51. If the user does not wish to transmit an offer, the process 2300 ends.

Turning now to FIG. 24, there is depicted an exemplary process 2400 for allowing a user to review information from previously-stored fixtures or charter party contracts based on the date of each fixture. A "view fixtures" button 1714 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1714, the system executes the process 2400 which begins at step 2401 where the system asks the user to specify a date or a date range of entered fixtures to view. The user then inputs the desired data or date range (step 2402). The system then refers to the fixture database 48 and retrieves data for all fixtures meeting the criteria and the results are transmitted to the user in a predefined format (step 2404).

Continuing to step 2406, the system inquires whether the user wishes to print any or all of the retrieved data. If so, the process 2400 continues to step 2408 where a report of the fixture data is printed. Otherwise, the process 2400 continues to step 2410.

At step 2410, the system inquires whether the user wishes to review other fixture data. If so, the process 2400 returns to step 2402, discussed above. Otherwise, the process 2400 ends.

Similar to process 2400 above, it is contemplated that the system of the present invention will include a custom report feature wherein fixtures having certain characteristics, such as type of cargo, or involving certain parties, may be searched and presented. Referring now to FIG. 25, therein is depicted an exemplary process 2500 for searching the fixture database 48 based on features other than the date. A "custom fixture report" button 1716 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1716, the system executes the process 2500 which begins at step 2501 where a list of available search fields related to the cargo database 50 is presented to the user. The user may then input the desired fixture criteria (step 2502). Next, the system refers to the fixture database 48 and retrieves data for all fixtures meeting the criteria. The system assembles the returned data in a predefined format (step 2503) and the results are transmitted to the user (step 2504).

Continuing to step 2506, the system inquires whether the user wishes to print any or all of the retrieved data. If so, the process 2500 continues to step 2508 where a report of the fixture data is printed. Otherwise, the process 2500 continues to step 2510.

At step 2510, the system inquires whether the user wishes to review other fixture data. If so, the process 2500 returns to step 2502, discussed above. Otherwise, the process 2500 ends.

Turning now to FIG. 26, there is depicted an exemplary process 2600 for allowing a ship owner to make an offer on public or private cargo. A "submit offer" button 1718 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1718, the system executes the process 2600 which begins at step 2602 where the system transmits to the ship owner a list of public cargoes, as well as private cargoes addressed to the ship owner. At step 2604, the ship owner may review the cargo list. The ship owner may then choose to print the list (steps 2606 and 2608).

Next, the ship owner may select a particular cargo and a format containing cargo information of interest (step 2610). The system then retrieves the selected cargo data and transmits it to the ship owner in the selected format (step 2612). The ship owner then reviews the cargo information (step 2614).

The system next inquires whether the ship owner would like to review another cargo entry (step 2616). If so, the process 2600 returns to step 2604, described above. Otherwise, the process 2600 continues to step 2618 where the ship owner is asked whether a previous offer should be retrieved for review. If the ship owner wishes to view the terms of a previous offer, the system receives an identification of the previous offer, retrieves it from the offers database 51 and presents it to the ship owner (step 2620).

Next, the ship owner is asked whether the retrieved offer should be printed (step 2622). If so, the retrieved offer is printed at step 2623. The process then continues to step 2624, wherein the system inquires whether the ship owner would like to insert the previous offering criteria into a new offer, or to prepare a new offer without using previously stored information. The ship owner may then enter new offer criteria or select any or all of the retrieved offer criteria, if available. Offering criteria may include a quantity of a cargo, a cargo type, a discharge requirement, a cargo range, the number of laydays required, a rate to be paid, a demurrage rate, desired rider clauses for the fixture, and the like.

The process 2600 then continues to step 2626 wherein the system inquires whether the prepared offer is to be submitted. If so, the offer is sent to the charterer who entered the cargo data, preferably via e-mail, and is stored in the offers database 51 (step 2628). Otherwise, the process 2600 continues to step 2630.

At step 2630, the system inquires whether the offer is instead to be saved for future submission. If so, the offer is saved in the offer database 51, and designated as being on hold rather than active (step 2632), after which the process 2632 ends. In the alternative, the ship owner may choose not to save or submit the entered offer, in which case the process 2600 ends as well.

Turning now to FIG. 27, there is depicted an exemplary process 2700 for allowing a charterer to negotiate a fixture or charter party contract with a ship owner. A "negotiate (by charterer)" button 1720 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1720, the system executes the process 2700 which begins at step 2702 where the system sends the charterer a list of open (i.e. listed but non-negotiated) cargoes which have received an offer. The charterer may then open the open cargo list (step 2704), choose a cargo (step 2706) and review a list of offers submitted for the cargo (step 2710) which are retrieved from the offers database 51 (step 2708). The charterer may then select an offer and respond to the party who transmitted it, preferably via an e-mail message (step 2712). The response may include a modification of the submitted offer. The system then transmits the response to the owner (step 2714) and the e-mail is stored in the e-mail database 56.

The owner, in turn, may review the response (step 2716). At step 2728, the system inquires whether the ship owner agrees to the terms in the response. If so, the process 2700 continues to step 2730 discussed below. Otherwise, the system then inquires whether the owner wishes to continue the negotiation (step 2718). If not, the system inquires whether the owner wishes to place the offer on hold (step 2720). If the owner elects to hold the offer, the offer is stored in offers database 51 with a designation that its status is on hold. If the owner does not wish to place the offer on hold, the process 2700 ends at step 2722.

Returning to step 2718, if the owner wishes to continue the negotiation, the process 2700 continues to step 2724, where the owner generates a response to the charterer's response which is transmitted to the charterer. The response may be stored in e-mail database 56. The charterer then reviews the ship owners response (step 2726). If the charterer agrees to the terms in the response, the process 2700 continues through step 2728 to step 2730, discussed further below. Otherwise, the system inquires whether the charterer wishes to continue the negotiations (step 2734). If the charterer does not wish to continue the negotiations, then the system inquires whether the modified offer is to be placed on hold (step 2736). If the charterer so designates, then the modified offer is stored in the offers database 51 with an indication that it is on hold. If the charterer does not wish to hold the offer, then the process 2700 returns to step 2710 above where the charterer may review another offer and continue therefrom.

Returning to step 2730, the system next inquires whether all portions of the offer which may relate to third parties have received approval from such third parties. If no approval has been received, the process 2700 returns to step 2726 discussed above. If all third party subjects have been lifted, a charter party agreement is created (step 2732) from the terms of the latest offer communicated.

The interactions between the ship owner and the charterer may be recorded in a log file 58, as discussed above.

Turning now to FIG. 28, there is depicted an exemplary process 2800 for allowing a ship owner to negotiate a fixture or charter party contract with a charterer. A "negotiate (by ship owner)" button 1722 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1722, the system executes the process 2800 which begins at step 2802 where the system sends the ship owner a list of the ship owner's open ships offered for a particular cargo. The ship owner may then open an offered ship list (step 2804), choose a ship (step 2806) and review a list of offers submitted corresponding to the ship (step 2810) which are retrieved from the offers database 51 (step 2808). The ship owner may then select an offer and respond to the party who transmitted it, preferably via an e-mail message (step 2812). The response may include a modification of the submitted offer. The system then transmits the response to the charterer (step 2814) and the e-mail is stored in the e-mail database 56.

The charterer, in turn, may review the response (step 2816). Then at step 2828, the system inquires whether the charterer agrees to the terms in the response. If so, the process 2800 continues to step 2830 discussed below. Otherwise, the system then inquires whether the charterer wishes to continue the negotiation (Step 2818). If not, the system inquires whether the charterer wishes to place the offer on hold (step 2820). If the charterer so elects, the offer is stored in offers database 51 with a designation that its status is on hold. If the charterer, on the other hand, does not wish to place the offer on hold, the process 2800 ends at step 2822.

Returning to step 2818, if the charterer wishes to continue the negotiation, the process 2800 continues to step 2824, where the charterer generates a response to the owner's response which is then transmitted to the ship owner. The response may be stored in e-mail database 56. The ship owner then reviews the charterer's response (step 2826). If the ship owner agrees to the terms in the response, the process 2800 continues through step 2828 to step 2830, discussed further below. Otherwise, the system inquires whether the ship owner wishes to continue the negotiations (step 2834). If the owner does not wish to continue the negotiations, then the system inquires whether the modified offer is to be placed on hold (step 2836). If the owner so designates, then the modified offer is stored in the offers database 51 with an indication that it is on hold. If the owner does not wish to hold the offer, then the process 2800 returns to step 2810 above where the ship owner may review another offer and continue therefrom.

Returning to step 2830, the system next inquires whether all portions of the offer which relate to third parties have received approval. If not, the process 2800 returns to step 2826 discussed above. On the other hand, if all third party subjects have been lifted, a charter party agreement is created (step 2832).

The interactions between the ship owner and the charterer may be recorded in a log file 58 as discussed above.

Turning now to FIG. 29, there is depicted an exemplary process 2900 wherein a user of the system may access, modify and print standard or user-specific charter party contract forms stored in the forms database 52. A "charter party forms" button 1724 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1724, the system executes the process 2900 which begins at step 2902 where the system sends a list of available forms to the user. The user then selects a form from the list (step 2904). In response, the form is retrieved from the forms database 52 (step 2906) and is transmitted to the user. The user then views the form at step 2908.

Upon viewing the form, the system then inquires whether the user wishes to modify the form (step 2910). The "modify" functionality of step 2910 is available only to the owner of the form. If it is determined that the form is to be modified, and if the selected form is proprietary, the process 2900 continues to step 2912, where the system confirms that the user is the owner of the form to be modified. If the user does not own the form, the user is returned to step 2908. Otherwise, the system receives the user's modifications (step 2914), stores and updates the forms database 52 (step 2916).

Returning to step 2910, if the user does not wish to modify the form, the system then inquires whether another form is to be viewed instead (step 2918). If so, the process 2900 returns to step 2904 above. Otherwise, the process continues to step 2920. At step 2920, the user may choose to print the form being viewed. If the user does not wish to print the form, the process 2900 continues to step 2924.

At step 2924, the system inquires whether new information is to be added in order to create a new form. The "add" functionality of step 2924 is available only to users who are not owners of the form. If it is determined that a new form is added in step 2924, the user adds new information (step 2926) which is then used to update the forms database 52 (step 2928). If the user does not wish to add new information, the process 2900 continues to step 2930, where the system inquires whether the user wishes to change current information in the selected form. If so, the system receives the changes to current information (step 2932) and adds the changes to the forms database 52 (step 2928). If there are no changes to be made to current form information, the process 2900 ends.

Turning now to FIG. 30, there is depicted an exemplary process 3000 wherein a user of the system may access, modify and print standard or user-specific clauses stored in a clauses database 55. A "clauses" button 1726 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1726, the system initiates the process 3000 which begins at step 3002 where the system sends a list of available clauses to the user. The user then selects a clause from the list (step 3004). In response, the clause is retrieved from the clause database 55 (step 3006) and transmitted to the user. The user then views the selected clause at step 3008.

Upon viewing the clause, the system then inquires whether the user wishes to modify the clause (step 3010). The "modify" functionality of step 3010 is available only to the owner of the form for the clause. If it is determined that the form is to be modified and if the selected clause is proprietary, the process 3000 continues to step 3012, where the system confirms that the user is the owner of the clause to be modified. If the user did not originally submit the clause, the user is returned to step 3008. Otherwise, the system receives the user's modifications (step 3014) and updates the clauses database 55 (step 3016).

Returning to step 3010, if the user does not wish to modify the clause, the system then inquires whether another clause is to be viewed instead (step 3018). If so, the process 3000 returns to step 3004 above. Otherwise, the process continues to step 3020. At step 3020, the user may choose to print the clause being viewed (step 3022). If the user does not wish to print the clause, the process 3000 continues to step 3024.

At step 3024, the system inquires whether a new form is to be created for the clause. The "add" functionality of step 3024 is available only to users who are not owners of the form. If it is determined that a new form is to be added, the user adds new information (step 3026) which is then used to update the clauses database 55 (step 3028). If the user does not wish to add new information, the process 3000 continues to step 3030, where the system inquires whether the user wishes to change current information in the selected clause. If so, the system receives the changes to current information (step 3032) and adds the changes to the clauses database 55 (step 3028). If, on the other hand, there are no changes to be made to current clause, the process 3000 ends.

Turning now to FIG. 31, there is depicted an exemplary process 3100 wherein a user of the system may access, modify and print standard or user-specific trade sheets stored in a trade sheet database 54. A "trade sheets" button 1728 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1728, the system initiates the process 3100 which begins at step 3102 where the system sends a list of available trade sheets to the user. The user then selects a trade sheet from the list (step 3104). In response, the trade sheet is retrieved from the trade sheet database 54 (step 3106) and transmitted to the user. The user then views the selected trade sheet at step 3108.

Upon viewing the trade sheet, the system then inquires whether the user wishes to modify the trade sheet (step 3110). The "modify" functionality of step 3110 is available only to the owner of the form for the trade sheet. If it is determined that the form is to be modified, so and if the selected trade sheet is proprietary, the process 3100 continues to step 3112, where the system confirms that the user is the owner of the trade sheet to be modified. If the user did not originally submit the trade sheet, the user is returned to step 3108. Otherwise, the system receives the user's modifications (step 3114) and updates the trade sheets database 54 (step 3116).

Returning to step 3110, if the user does not wish to modify the trade sheet, the system then inquires whether another trade sheet is to be viewed instead (step 3018). If so, the process 3100 returns to step 3104 above. Otherwise, the process continues to step 3120. At step 3120, the user may choose to print the trade sheet being viewed (step 3122). If the user does not wish to print the trade sheet, the process 3100 continues to step 3124.

At step 3124, the system inquires whether a new form is to be created for the trade sheet. The "add" functionality of step 3124 is available only to users who are not owners of the form for the trade sheet. If it is determined that a new form is to be added, the user adds new information in a newly added form (step 3126) which is then used to update the trade sheets database 54 (step 3128). If the user does not wish to add new information, the process 3100 continues to step 3130, where the system inquires whether the user wishes to change current information in the selected trade sheet. If so, the system receives the changes to current information (step 3132) and adds the changes to the trade sheets database 54 (step 3128). If, on the other hand, there are no changes to be made to current trade sheet, the process 3100 ends.

In the processes described above with respect to FIGS. 29-31, it is additionally contemplated that an administrator or operator of the site may make changes to forms, clauses, trade sheets, and the like that they stored in the subject databases for use by subscribers and the like.

Referring now to FIG. 32, there is depicted an exemplary process 3200 wherein a user of the system may search for and contact other users and subscribers of the network site 40. A "directory" button 1730 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1730, the system initiates the process 3200 which begins at step 3202 where the system transmits a form for submitting a search of users stored in the users database 49. The user may enter desired criteria on the form (step 3204). The system then compares the entered criteria to the information stored in the users database 49 and generates a list of matched users (step 3206). The list is then transmitted to the submitting user (step 3208). The user may then choose to print the list (steps 3210 and 3212).

The user may also select one or more of the users on the list to view in more complete detail. The system then prepares a form for presenting the selected user data (step 3214) and inserts the appropriate data from the user database 49. The form and inserted data are then transmitted to the user who may view the form on a remote user terminal 20, 30 (step 3216). The user may then again choose to print the received data (steps 3218 and 3219). The user may then choose to view another user from the received list (step 3220), in which case, the process 3200 returns to step 3208 described above.

If the user does not choose to view data for another user on the returned list, the process 3200 continues to step 3222 where the user may choose to e-mail the selected user. An e-mail form is presented for the user to fill in (step 3224). After the message has been completed, the system may transmit the e-mail to the user and/or store the e-mail message in the e-mail database 56 for later retrieval.

Turning now to FIG. 33, there is depicted an exemplary process 3300 wherein a user of the system may set or change existing preferences regarding an interface to the network site 40. A "preferences" button 1732 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1732, the system initiates the process 3300 which begins at step 3302 where the system transmits a list of preferences which the user may set and change. The user may then choose one or more preference settings to change, such as a password, the order of menu functions, and the like (step 3304).

The system then retrieves the current preference setting from the preferences database 53 and transmits the current setting to the user (step 3306). The user may then view the current preference setting (step 3308) and may print the same (steps 3310 and 3312). The system then inquires whether the user wishes to view another preference setting. If so, the process returns to step 3304, described above.

Otherwise, the process 3300 continues to step 3316 where the user is asked whether the current preference setting displayed is to be modified (step 3316).

The user may then enter changes to the preference setting (step 3318) and may also print the changes that were entered (steps 3320 and 3312). The system then processes the changes and stores them in the preferences database 53. A record of the entered changes may further be recorded in the log file database 58, discussed above.

Turning now to FIG. 34, there is depicted an exemplary process 3400 wherein user of the system may contact an operator or administrator of the network site 40. A "contact site operator" button 1734 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1734, the system initiates the process 3400 which begins at step 3402 where the system transmits an e-mail template to be completed by the user. The user may then input data in the appropriate fields of the template, such as to, from, subject and message text fields (step 3404). After the template or form has been completed, the message is forwarded to the system (step 3406) and stored in the e-mail database 56 for retrieval by the operator or administrator.

Referring now to FIG. 35, there is depicted an exemplary process 3500 wherein a user of the system may search a help index relating to functions performed by the network site 40. A "help" button 1736 may be provided on the main menu 1700 for selecting this function. Upon activation of the button 1736, the system initiates the process 3500 which begins at step 3502 where an index of help topics may be prepared and transmitted to the user. The help topics may be retrieved from the help database 57 stored on the network site 40.

The user, in turn may select a particular help topic from the index (step 3504) and may additionally choose to print the index (steps 3506 and 3508). After the user selects a particular help topic, further information regarding the topic are retrieved from the help database 57 (step 3510) and displayed to the user (step 3512). The user may, in turn choose to print the further information (steps 3514 and 3516) and may select and view further help topics (step 3518). After all desired help topics have been viewed, the process 3500 ends.

The following is a sample charter party contract that may be entered into by charterers and ship owners:

                                TANKER VOYAGE CHARTER PARTY
    .sub.------------------------------  .sub.------------------------------
                   Place                Date
                                         PREAMBLE
    IT IS THIS DAY MUTUALLY AGREED between
     .sub.--------------------------------------------------
    .sub.
     --------------------------------------------------------------------------
    --------------------------
    Owner/Chartered Owner (hereinafter called "Owner") of the good
     .sub.------------------------------ flag
    ST/MT .sub.------------------------------------------------------------
     (hereinafter called the "Vessel")
    and
     .sub.
     --------------------------------------------------------------------------
    --------------------------
    (hereinafter called "Charterer") that the transportation hereinafter
     provided for shall be performed subject
    to the terms and conditions of this Charter Party, which includes this
     Preamble, Part I and Part II. In the
    event of a conflict, the provisions of Part I shall prevail over Part II to
     the extent of such conflict.
                                          PART I
    A.  VESSEL DESCRIPTION AND POSITION:
        Year Built: .sub.------------------------------  Classed:
     .sub.----------------------------------------
        Summer Deadweight: .sub.------------------------------13 -------- tons
     (2240 lbs.) metric tons (1000 kg.)
        on .sub.------------------------------ feet-inches/meters draft in salt
     water on assigned summers freeboard.
        Gross Registered Tonnage: .sub.-------------------- Suez/Panama Canal
     Net Tonnage: .sub.--------------------
        Capacity for Cargo: .sub.---------- metric tons (1000 kg.)
     .sub.---------- % more or less, Vessel's option.
        Cubic Capacity for Cargo (at 98%): .sub.------------------------------
     cubic feet/cubic meters/barrels.
        Length Overall: .sub.-------------------- feet-inches/meters. Beam:
     .sub.-------------------- feet-inches/meters
        Bow to Center Manifold: .sub.-------------------- feet-inches/meters.
        Keel to Top Mast: .sub.-------------------- feet-inches/meters.
        Tons Per Inch/Centimeter Immersion: .sub.--------------------
    Charter Speed: .sub.------------------ Knots Laden (weather and safe
     navigation permitting).
    Maximum Speed: .sub.------------------ Knots Laden (weather and safe
     navigation permitting):
    Vessel has segregated ballast tank (SBT) capacity of .sub.-------- m'
     according to its MARPOL certificate.
    Vessel has clean ballast tank (CBT) capacity of .sub.-------- m' according
     to its MARPOL certificate.
    Vessel has operational Inert Gas System: .sub.-------- Yes .sub.-------- No
    Vessel has operational Crude Oil Wash System: .sub.-------- Yes
     .sub.-------- No
    If Crude Oil Wash is required, the allowed pumping hours specified in Part
     II, Clause 15(c) shall be
    increased by a maximum of .sub.-------- hours pursuant to Part II, Clause
     15(d).
    Cargo Tanks:
    Fully Coated:  .sub.-------- Yes .sub.-------- No  Type:
     .sub.------------------------------
    Heating:      .sub.-------- Yes .sub.-------- No  Type:
     .sub.------------------------------
    .sub.---- derrick(s) each side with a maximum safe working load of
     .sub.---- tons (2240 lbs.)/meters tons (1000 kg.)
    Last 3 cargoes: Last.
                    2.
                    3.
    Vessel is entered in
     .sub.------------------------------------------------------------ P & I
     Club.
    Vessel position on date of Charter Party:
     .sub.------------------------------------------------------------
    Expected ready to load about:
     .sub.
     ----------------------------------------------------------------------
    Based upon loading at:
     .sub.
     ----------------------------------------------------------------------
    B.  LAYDAYS:
        Commencing: .sub.------------------------------ Cancelling:
     .sub.------------------------------
    C.  LOADING RANGE(S)/PORT(S)/PLACE(S):
                                                            Charterer's Option
    D.  DISCHARGE RANGE(S)/PORT(S)/PLACE(S):
                                                            Charterer's Option