WO2018222759A1 - Systems and methods for predicing weather related risks to maritime shipping interests - Google Patents

Abstract

Systems and methods are provided for system, method, and website for providing a risk assessment for a weather event at a given shipping terminal or set of terminals for particular dates. It provides a framework and efficient and novel computer based data structure that can be used to compute weather probabilities and policies terms, and it can assist ship owners anticipate where expensive delays may occur.

Description

Systems and Methods for Predicting Weather Related Risks to Maritime Shipping Interests

RELATED APPLICATION

This application is a continuation in part of U.S. Patent application No. 15/608,579, filed on May 30, 2017 which is hereby incorporated by reference in its entirety.

FIELD OF THE INVENTION

The present invention generally relates to systems and methods for protecting the interests of maritime commercial shipping and in particular to systems, methods and website interfaces for determining weather-related risks to such maritime shipping and procuring insurance protection against same.

BACKGROUND

Each year, 90% or more of all trade moves between ports around the world are via commercial maritime shipping. Cargo owners (Charterers) pay operators and ship owners to move this cargo. The amount paid for moving a particular cargo from a first point to a second point is based on a freight rate calculated by the shipping company for each voyage. When a particular cargo is to be moved, the cargo owner and the ship owner enter into an agreement or contract known as a Charter Party. While each such contract is in theory unique; in practice, the contracts contain many clauses that are reused. In the commercial shipping marketplace, there is currently an oversupply of available tonnage (ships) on the water. This leads to cargo owners having an advantage over ship owners. This, in turn, prevents much negotiation over terms or clauses in the Charter Party. While it should be straight-forward that a particular price should be paid to transport a particular cargo between two ports, this is hardly the case. One of the most important unknown variables that leads to difficulty and uncertainty in shipping costs, is the weather.

Weather is a key factor in determining the revenue generated by a vessel while in port. Charter Party provisions including "Weather Working Days" clauses (for dry bulk) and the "Conoco Weather Clause" (for tankers) are in place to protect the Charterer in the event weather prevents cargo operations to take place. Both of these clauses hold the ship owner responsible for time lost during weather conditions that prevent cargo operations from taking place in port (i.e., loading and unloading collectively referred to herein as "cargo operations"). Moreover, such clauses are in effect at the terminal in question itself

(loading or unloading point), and not at the location the vessel is actually sitting as long as the Notice of Readiness has been tendered.

When a vessel is ready to load or unload, it tenders a Notice of Readiness (NOR) advising the terminal that it is ready to perform cargo operations. As soon as the NOR is tendered, laytime begins. Laytime at the loading terminal is thus the total time between the tendering of the NOR and the Commencement of Sea Passage. There is a similar laytime at the discharge terminal. Weather Working Days Clauses in a Charter Party stipulate that if cargo operations cannot take place at the terminal, the time lost will be deducted from laytime. It does not matter if the vessel is actually alongside the pier, as long as the vessel has tendered their NOR stating that they are ready to perform cargo operations.

For example, suppose a ship loads 25,000 metric tons of wheat at the Port of Houston. The total time from tendering of the NOR to the Commencement of Sea Passage is 87 hours. The ship owner's potential laytime revenue is $27,817 based on a per day rate of $7,500. However, suppose there is 22 hours of recorded rainfall during in that interval when loading was not possible. There will be a deduction of $6,875 from the laytime revenue because of the Weather Working Days clause. A similar analysis will be done at the discharge port. In general, the laytime deduction is unknown to the ship owner until the vessel actually sails and the statement of facts is reviewed. However, the charterer, who may know a lot about a particular facility, might have a very good idea of what to expect based on local weather and past statistics.

Deductions from weather events can range from a few hundred dollars in the case of short delays to several hundreds of thousands of dollars for longer delays. These losses of revenue are all determined on what the current Time Charter Equivalent (TCE) rate for the vessel is. Given the state of the markets, the ship owner's only recourse into combating weather delays affecting the commercial performance of the voyage is to try and build that cost into the freight rates, or plan a voyage around ports where weather delays are minimal.

Many insurance companies currently offer parametric based policies to other markets and industries based on an assigned index. If that index is exceeded, the policy holder gets paid. An example of this is drought insurance, where farmers get paid if the drought index exceeds a set threshold, regardless of the insured's actual loss.

Accordingly, it would be desirable for ship owners to receive similar treatment and to have systems and methods for efficiently and effectively evaluating, calculating and offsetting the risk of potential lost vessel time due to unfavorable weather conditions at particular terminals on particular dates.

It would be further desirable to have an efficient user interface that allows a user to enter information regarding the particulars of a proposed maritime shipping voyage that can calculate the risk of potential lost vessel time due to unfavorable weather conditions at particular terminals on particular dates.

It would be additionally desirable if the systems, methods and user interfaces were configured to take into account certain other factors relevant to weather related lost time at port such as the current hire rate (TCE). It would be additionally desirable if the systems, methods and user interfaces were configured to provide a consumer with various risk mitigation policy options to choose from in order to better address risks or needs with respect to weather related risk factors.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide systems and methods for evaluating and calculating the risk of potential lost vessel time due to unfavorable weather conditions at a particular port or terminal on particular dates.

It is therefore a further object of the present invention to provide an efficient user interface to that allows a user to enter information regarding the particulars of a proposed maritime shipping voyage that can calculate the risk of potential lost vessel time due to unfavorable weather conditions at particular ports on particular dates.

It is therefore an additional object of the present invention to provide the systems, methods and user interfaces configured to take into account certain other factors relevant to weather related lost time such as vessel and cargo type.

It is therefore yet an additional object of the present invention to provide systems, methods and user interfaces configured to provide a consumer with various risk mitigation policy options to choose from in order to better address consumer risks or needs.

One aspect of the present invention relates to systems and methods for creating and providing a Risk Index that determines the likelihood of one or more unfavorable weather events at a given port or a set of ports in the case of a complete voyage, usually for particular dates. It may further provide a statistical background that can be used as a basis to compute premiums and/or other terms for weather shipping delay insurance policies that have an integrated or standalone weather delay component. Further, it can assist ship and cargo owners in anticipating where expensive weather related delays may occur and provide forecasts for port operations including congestion related delays. This may be important to the logistics and planning for a voyage or future voyages.

A substantial amount of historical weather data is available in addition to short-term and long-term forecasts that may be used to determine a probability of certain unfavorable weather events occurring. Historical data can be retrieved from databases including weather station observation data and/or from satellite observation data and may include the timing of rain, overall amount of rain, temperature, visibility, wind velocity and/or barometric pressure at any given time. Historical data concerning certain period weather events such as hurricanes and cyclones may also be considered.

Embodiments of the present invention may compute the likelihood of precipitation (rain, snow, sleet) duration, using weather data to compute climatological daily duration of rainfall, weighing climatology in short-range and long-range with probabilistic forecast model data. Other factors, such as visibility (fog) and wind may also be determined and considered. A Weather Risk Probability (RP) value may be computed for each ports of interest for the dates of interest. This may include the probability of daily precipitation duration exceeding a predetermined number of hours. This is typically related to the average hours per day of expected precipitation which is also related to ambient temperature, barometric pressure and dew point. Other embodiments may consider visibility and wind. Severity of the adverse weather event(s) is typically not of primary importance as compared with event duration.

In some embodiments, it also may include the expected amount of time a port may experience limited visibility and/or the amount of time wind may exceed a pre-determined value for a certain period of time (the pre-determined value may be based on, e.g., ship type, cargo or unloading infrastructure, Charter Party terms, port restrictions, etc.). Any weather related variables that may affect laytime may be considered if desired and will be recognized as within the scope of the invention.

Next, data relating to the average cost of per day of the voyage may be considered. For example, shipping cost information from the Baltic Dry Index (BDI) may be accessed from a database. This is a commercially available economic indicator published by the London- based Baltic Exchange and is not restricted to Baltic Sea countries. Other similar indices or data may also be used if desired. For example, liquids such as oil or liquid natural gas or perishable good cargos may rely on data other than BDI. For example, such data may be proprietary and used by the systems and methods of the present invention contemplated hereunder. The operator of a vessel may also elect to update the cost per day basis using the known TCE at the time of the engagement.

The BDI provides an assessment of the price of moving major dry bulk raw materials by sea. These indices may be processed in view with the Time in Port information (End of Sea Passage - Commencement of Sea Passage). This may be an average turnaround time for a similar ship at the same port. Typically, the longer time a vessel spends in port, the greater the chance of potential loss. The result is a Risk Index (delay based) for a given port. In some embodiments, this Index may be further refined by based on cargo type, which cargos are considered weather sensitive and having a higher risk than cargoes which are not weather sensitive. Using this information above, the present invention can calculate a baseline at any given time by looking at the 750 most prolific bulk ports based on the number of port calls.

One aspect of the present inventions provides computer-implemented method for determining weather risk associated port based lading operations comprising: determining a port of origin; determining a destination port; determining a departure date from the point of origin; determining an approximate arrival date at the destination port; calculating aggregate weather based risk to a ship owner, determining a near term weather forecast and variation thereof and adjusting the calculated aggregate risk of port based weather delays in lading operations based on the near term weather forecast; generating, based on the adjusted calculated aggregate risk a Charter Party insurance policy including premium calculation and associated terms; transmitting, over a network in near real time to an application on a client device, terms of the Charter party contract including the cost of the policy and coverage limits and thereafter cause the application to display the policy on the client device for approval by a Charter party. Another aspect of the present invention provides for a system for determining weather risk associated port based lading operations comprising: determining a port of origin through a client based user interface; determining a destination port through the client based user interface; determining a departure date from the point of origin through the client based user interface; determining an approximate arrival date at the destination port; calculating aggregate weather based risk to a ship owner with a risk assessment server, determining a near term weather forecast and variation thereof and adjusting the calculated aggregate risk of port based weather delays in lading operations based on the near term weather forecast with a risk assessment server; generating, based on the adjusted calculated aggregate risk a Charter Party insurance policy including premium calculation and associated terms with the risk assessment server; transmitting, over a network in from the risk assessment server in near real time to an application on a client device, terms of the Charter party contract including the cost of the policy and coverage limits and cause the application to display the policy on the client device for approval by a Charter party.

Another aspect of the present invention provides for a website and associated user interface that allows a user to determine weather risk associated port based lading operations comprising: a first data entry field that allows a user to select a port of origin through a client based user interface; a second data entry field that allows a user to select a destination port through the client based user interface; a third data entry field that allows a user to select a departure date from the point of origin; a fourth data field for determining an approximate arrival date at the destination port; a communication link to a risk assessment server that allows for the calculation of a aggregate weather based risk to a ship owner with a risk assessment server, and further allowing for the determination of a near term weather forecast and variation thereof and adjusting the calculated aggregate risk of port based weather delays in lading operations based on the near term weather forecast with a risk assessment server; wherein the risk assessment server generates, based on the adjusted calculated aggregate risk a Charter Party insurance policy including premium calculation and associated terms and; transmitting, over a network in from the risk assessment server in near real time to an application on a client device, terms of the Charter party contract including the cost of the policy and coverage limits and cause the application to display the policy on the client device for approval by a Charter party.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects and advantages of the present invention will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:

FIG. 1 shows an illustrative diagram of a distributed system that may be used to implement aspects of the present invention.

FIG. 1A shows an illustrative login screen in accordance with the principles of the present invention.

FIG. 2 shows an illustrative website and associated user interface in accordance with the principles of the present invention.

FIG. 3 shows a flow chart illustrating some of the steps in accordance with the principles of the present invention.

FIG. 4 shows an illustrative recap screen and policy terms and conditions in accordance with the principles of the present invention.

FIG. 5 shows a flow chart illustrating some of the steps in accordance with the principles of the present invention.

FIG. 6 Illustrates and risk index calculation in accordance with the principles of one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTIONS

In the following description of the various embodiments, reference is made to the accompanying drawings, in which are shown by way of illustration, some of the exemplary embodiments that may be practiced. It shall be understood, however, that other embodiments may be used and various structural and/or functional modifications may be made without departing from the spirit and scope of the present invention.

FIG. 1 illustrates one example of a network architecture 100 that may be used to implement one or more of the inventive aspects of the present invention. Various network components 103, 105, 107, and 109 may be interconnected via a wide area network (WAN) 101, such as the Internet. Generally speaking, components 103, 105, 107, and 109 may be any suitable computing and/or data storage device such as a server, personal computer, laptop computer, tablet, mobile phone or the like. Other networks may also or alternatively be used, including private intranets, corporate networks, LANs, wireless networks, and the like and may include secure connections such as VPNs to provide an environment suitable for financial transactions. Encryption techniques such as "block chain," RSA and the like may also be employed if desired. It will be understood that network 101 is for illustration purposes and may be replaced or modified with fewer or additional computer networks. A local area network (LAN) may have one or more of any known LAN arrangement and may use one or more of a variety of different protocols, such as Ethernet, optical, WiFi etc. Components 103, 105, 107, 109 and other devices (not shown) may be connected to one or more of the networks via any known suitable wireless connection or hard wired connection such as coaxial cable, fiber optics, etc.

The term network as used herein generally refers not only to systems in which remote computing and/or storage devices are coupled together via one or more communication paths, but also to stand-alone devices that may be coupled, from time to time, to such systems that have storage and/or computing capability. Consequently, the term "network" includes not only a physical network but also may include a virtual data network which includes the information that resides across virtual and/or physical networks. In one embodiment, the components may include Risk Assessment and calculation server 103, a server 105, and user (client) devices 107, 109. In some embodiments, Risk Assessment and calculation server 103 may provide overall access, control and administration of databases and control software for performing one or more illustrative aspects of the invention as described herein which may include premium calculation, policy term generation (financial and non- financial) and other suitable or desired tasks. Risk Assessment and calculation server 103 may be connected to actuarial server 105 through which users interact with and obtain certain data as requested. This may include current or historical weather data, shipping cost indices, proprietary information databases and risk calculation routines, etc. Alternatively, Risk Assessment server 103 may act as an actuarial server itself and be directly connected to the Internet or in

combination with component 105. Risk Assessment server 103 may be connected to actuarial server 105 through the network 101 {e.g., the Internet), via direct or indirect connection, or via some other network which may be a secure or private connection {e.g., protected through encryption such as block chain).

In some embodiments, actuarial server 105 may include information, data and functional programming for risk assessment and forecasting models, and may also be a repository for current and/or historical weather information and/or may have subscriptions to various other data sources including weather forecasting services such as WeatherBELL Analytics, the assignee of the present application. In some embodiments, actuarial server 105 may also include

subscriptions and/or license to certain insurance company risk assessment tools and/or proprietary models and may consult and/or partner with various underwriters when determining policy terms, limits, coverage type, structure etc. This arrangement also contemplates tools which may assess the performance of similar or the same weather delay products over a period of time for similarly situated voyages, cargos and vessels, etc. Furthermore, in some embodiments server 103 and/or 105 may host one or more external client facing website(s) that are provided by a third party such as insurance company or shipping company.

Users, such as vessel or cargo owners may interact with Risk Assessment server 103 using remote client components 107, 109, e.g., using a web browser to connect to server 103 via one or more externally accessible web sites hosted by actuarial servers 103 or 105. Examples of such a website and associated user interface are further described herein in connection with FIG. 2. Client devices 107 and 109 may be used in concert with server 103 to access data stored therein, or may be used for other purposes. For example, from client device 107 a user may access server 103 or 105 using an Internet browser, as is known in the art, or by executing a software application that communicates with actuarial server 105 and/or Risk Assessment server 103 over a computer network (such as the Internet).

In some embodiments, actuarial server 105 may include information regarding historical weather data and/or may be programmed to actively retrieve, combine, average or otherwise process weather data from one or more external sources as further described herein in connection with the contemplated invention. Server 105 may operate in conjunction with Risk Assessment server 103 and third parties to process historical weather information to perform various desired application calculations such as risk assessment, transit time, and insurance premiums and policies for use in accordance with aspects of the present invention.

In certain embodiments of the inventions, servers and various applications programs may be combined on the same physical machines, and retain separate virtual or logical addresses, or may reside on separate physical machines. It will be understood that FIG. 1 merely illustrates just one example of a network architecture that may be used, and those of skill in the art will appreciate that the specific network architecture and data processing devices used may vary, and are secondary to the functionality that they provide, as further described herein. For example, services provided by actuarial server 105 and Risk Assessment server 103 may be combined on a single server or other suitable computing device whether distributed or local, etc.

Each component 103, 105, 107, 109 may be any suitable type of known computer, server, or data processing device. Server 103 may include a processor 111 controlling overall operation of server 103 and distributed applications originating therefrom.

Server 103 may further include certain memory elements such as RAM 113, ROM 115, network interface 117, input/output interfaces 119 {e.g., keyboard, mouse, display, printer, etc), and memory 121. I/O 119 may include a variety of interface units and drives for reading, writing, displaying, and/or printing data or files. Memory 121 may further store operating system software 123 for controlling overall operation of the data processing device 103, control logic 125 for instructing Risk Assessment server 103 to perform aspects of the invention as described herein, and other application software 127 for providing secondary support, and/or other functionalities which may or may not be used in conjunction with aspects of the present disclosure.

The control logic may also be referred to herein may include risk assessment and calculation software 125. Functionality of the risk assessment and insurance premium

calculation and billing server software 125 may refer to operations or decisions made

automatically based on rules coded into the control logic, made manually by a user providing input into the system, and/or a combination of automatic processing based on user input (e.g., queries, data updates, etc.). This is discussed in more detail in connection with the flow charts of FIGS. 3 and 5. Those skilled in the art will realize that components 105, 107, and 109 may also include similar hardware components (e.g., processor, RAM/ROM, memory, etc.) as discussed above with respect to server 103.

Memory 121 may also store data used in performance of one or more aspects of the invention, including a first database 129 and a second database 131. In some embodiments, the first database may include additional databases such the second database 129 for storing related information (e.g., historical and near term weather forecast information, tables, spread sheets, reports, policy details including various terms for policy creation etc.). That is, the information can be stored in a single database, or separated into different logical, virtual, or physical databases, depending on system design, or requirements. Any suitable such arrangement as known in the art may be used if desired. Devices 105, 107, 109 may have similar or different architecture as described with respect to device 103. Those of skill in the art will appreciate that the functionality of data processing device 103 (or devices 105, 107, 109) as described herein may be spread across multiple data processing devices, for example, to distribute processing load across multiple computers, to segregate transactions based on geographic location, user access level, quality of service (QoS), etc.

One or more aspects of the invention may be embodied in computer-usable or readable data and/or computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices as described herein. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The modules may be written in a source code programming language that is subsequently compiled for execution, or may be written in a scripting language such as (but not limited to) HTML or XML. The computer executable instructions may be stored on a non- transitory computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, RAM, etc. As will be appreciated by one of skill in the art, the functionality of the program modules may be combined or distributed as desired in various embodiments. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), and the like. Particular data structures may be used to more effectively implement one or more aspects of the invention, and such data structures are contemplated within the scope of computer executable instructions and computer-usable data described herein (discussed in more detail below).

FIG. 1A represents an illustrative login screen 150. As shown a user may enter a username 152 and password 153 as is common in the art. Next, the user must agree to the terms and conditions of the website and check box 154. Next, user may click box 155 and a management database such as one resident and server 103 and/or 105 validates user credentials against those inputs. Upon validation, the system may load various information that was entered previously such when the account was created or earlier transactions were begun and/or completed (omitted here for simplicity).

FIG. 2 represents an illustrative data entry screen for the users such as the front end of a client facing website. The interface of FIG. 2 may include interactive world map in which a user may navigate graphically to select load and/or discharges ports. In some embodiments, the interface of FIG. 2 may be used to display current and forecast weather conditions at point of interest such as an origination or destination port (not shown). In some embodiments, the interface of FIG. 2 may be used to display areas where there is a high likelihood of weather related delays. For example, major ports with problematic delays may be displayed in red, ports with minor or emerging delays in yellow and ports within normal operating parameters in green (not shown). However, this is only exemplary and other schemes may be used as well (e.g., during a mouse "rollover").

The interface of FIG. 2 may be used to visually determine certain information regarding aspects of maritime shipping commerce. This may include determining the shipping transit time from one destination to another generally, or with respect to certain cargo, obtaining information about certain shipping lanes, ports and shipping routes including weather actual and predicted delays. It also may allow cargo owners to find shipping companies as well as allow an interested party (operator, owner, charterer, trader) to asses or otherwise calculate potential weather based delays. The may be done using interactive world map 200 as well as dialogue boxes 204-218 (discussed in more detail below). Dialogue boxes may allow any type of input such as text input, input based selections made from map 200, or, from a pull down or "pick" lists and date time pickers (and may be generally referred to herein as "data fields").

As shown, the interface in FIG. 2 may include an interactive world map 200 that allows a user to navigate by mouse, touchscreen or other input device to various portions of interest around the globe. In some embodiments of the invention, map 200 may support a mouse "rollover" or other similar feature that allows a user to alter (increase or decrease) the magnification of certain geographic point of interest, such as through the use of "slider" 201. This may be done to allow a user to view and/or identify and select a seaport of interest and then zoom in or out as desired. Zooming in general provides more information about the selected point of interest.

Upon selection or rollover, certain information regarding the port may be displayed such as longitude and latitude, local time, winds, temperature and a link the a local weather forecast or shipping related information may also be available where data has been collected and maintained on the servers as well as red, yellow or green indication of delays.

For example, 3D map information of satellite images and/or weather information such as graphics may also be available. This information may be defined by default, configured by the service provider, or configurable by an end user or limited based on the data or available information regarding the point of interest. Certain information may be available such as advanced weather forecasts, high resolution satellite maps and analytics may be available through user subscription (whereas in some embodiments the basic interface may be

substantially free of charge).

In some embodiments, the interface of FIG. 2 may perform multiple functions. For example, a cargo holder may enter information regarding point of origin and destination along with cargo type and desired arrival date to find a freight carrier and get a shipping quote (not shown). Such information may be depicted on a different screen with a list of carriers and contact information and preliminary terms (not shown). For example, a registered website user such as a cargo or vessel owner may use the interface to obtain estimated transit time for the selected points of origin and destination for the indicated dates.

The Interface of FIG. 2 may also be used to obtain weather delay or laytime based insurance for shipping. For example, in the case where an operator is interested in obtaining such insurance, the interface of FIG. 2 may be used as described in connection with flowcharts in FIGS. 3 and 5.

The interface of FIG. 2 may operate as follows. A user may update/select the vessel name using input field box 204 (MT Neversink). This step is shown as step 304 in the flow chart of FIG. 3 (after the user has successfully logged in at point B). The system may then check the name for matches and its associated International Maritime Owner (IMO) number may automatically populate (step 320) based on the vessel name and generally cannot be edited by the user. In some embodiments, vessels without an associated IMO number may not qualify for insurance products but can still receive certain information from the website (e.g., route times and any delay estimates). In other embodiments, FMO number may be added and verified. This is shown in input field 205 (IMO number 98765431) in FIG. 2 and illustrated as step 305 in FIG. 3.

Input field 206 may allow the user to create a voyage number to identify the

contemplated or active journey for future reference (001/MSY/CHI). This is illustrated as step 306 in FIG. 3. Upon logon, a user's active voyages may appear in a listing that the user can select from to view, update or change information (not shown). Further commonly used routes may be stored and named so a user may quickly get a quote for one or more saved common routes based on certain updated information such as departure and arrival, dates cargo type, vessel type etc. Next, as shown, in FIG. 2, a user may enter port of origination information in field 207 (Mississippi river). This is illustrated as step 307 in FIG. 3. This can be accomplished in a number of ways. For example, a user may select a port of origination from map 200, from a pick list associated with field 207, or enter such information in field 207 with a keyboard or other data entry device. The user may then enter vessel ETA (11/10/18, estimated time of arrival) in Date/Time picker 208 (step 308) and the number of days expected at the loadport identified in field 207 within the numerical field 209 (15 days) and correspondingly at step 309 (or, in some embodiments, may automatically calculated and filled in based on origin and destination information in view of averages or normal time expected in view of past similar voyages).

Next, the port of destination (disport) may be selected in a similar way as described above in field 210 (Chiba JP) and corresponding step 310. ETA may be entered in field 211 either by direct entry or selecting from a pull down calendar (step 311). In some embodiments, this may be calculated based on other known information such as departure date, shipping route and ship and/or cargo type. Expected duration at port of call can be entered into field 212 (12 days) (step 312) or, in some embodiments, automatically calculated and filled in based on certain information {e.g., such as origin and destination) . In some embodiments, other information may be optionally entered or automatically filled in such as cargo type, ship type {e.g., based on IMO, vessel AIS (automatic identification system) data {e.g., based on IMO), shipping company information, and terminal data (not shown). This may further obtain and take into account current unloading delays at destination and expected clear up times to provide a more accurate estimate.

Next, if the user wishes to obtain a quote for insurance regarding certain weather related loading and/or unloading delays (TIP delays), he or she may do so by entering a hire rate into field 213 (step 313). In some embodiments, this hire rate may be automatically estimated based on the Baltic Dry Index or other comparable indices based on cargo type or as a default rate. The user may then click on button 214 (step 314) to generate a calculation for an insurance quote for the current voyage based on weather delays which may include policy payout limits policy premiums and other terms. Button 215 (step 315) may be selected to clear the data, or button 216 selected (step 316) to save the currently entered voyage for future reference.

If the user generates a voyage for which weather based insurance is sought, a premium amount which takes into account the historical weather data, time estimated in port times (which may be at point or origin and destination), hire rate, and, in cases where the first port call is within about 1-21 days (e.g., 14 days or under), the near term weather forecast from various sources may also be considered to provide a premium to the user in field 217 ($8776.93).

If the user wants to purchase the insurance at the rate displayed in field 217, he or she will select the GoTo purchase button 218 which will take the user to a "recap" page which may display the content of fields 204-212 and ask the user to confirm such information is correct (not fully shown, partial blocked view shown in FIG. 4). If correct, the user may continue with the purchase, if not may go back and make any necessary or desired changes.

If the user elects to purchase a copy of the policy particulars is displayed at FIG. 4. Typically, user cannot purchase the policy until all the policy terms and conditions have been reviewed. Accordingly, the user may review detailed terms of any insurance or surety contract that may be provided by participating carriers to determine if acceptable. In certain policies terms and selected coverage deductibles or limits may affect policy pricing and applicability for certain carriers or clients. The user may scroll to view the entire policy by clicking arrow 221 and accept the terms and conditions by checking box 222. In some embodiments, the user can print and make changes to the policy affecting the premium. In some embodiments, the user may e-sign the policy document. Confirmation hard copies may be necessary for policies over a certain amount. Payment may be affected through a pre-existing account set up by the user or through conventional credit card, PayPal, wire transfer or other known electronic payment method.

In some embodiments, the user may select a certain type of weather risk (rain, wind, visibility, etc.) to receive quotes on, from a pull down menu for example, or just select "all" to obtain comprehensive coverage for a predetermined group of weather events underwritten by various underwriters (not shown). In some embodiments, if the user selects button 218, coverage type (full, partial, contingency or otherwise) may be selected (not shown). Insurance for a vessel having multiple cargos and multiple destinations may be available. For example, the user may enter a series of voyages that may be combined together for multiples stops at multiple ports with multiple cargos (a "run"). Insurance may be obtained for each leg of the voyage (single origin to single destination) or, if available, combined together for the entire run. Moreover, in many instances, large shipping companies may have multiple vessels making multiple runs through common ports on a regular basis. Group based insurance for such occurrences and such companies is also possible based on number of vessels, vessel type, origin, destination, frequency of voyage etc. Such polices may also be obtained through the interface of FIG. 2 (not shown).

Further, some embodiments may include "find a carrier" feature which may allow cargo owners to identify carriers that can accommodate the cargo type, location, size and shipping dates required or preferred by cargo owner. This information would be displayed on a subsequent display screen (not shown).

With respect to policy type, multiple types may be available. For example, one type may be for weather delay at the origination port only. Another type may be for the destination port only. A third type may include both destination and origination ports. A fourth type may include the third type plus account for weather variability in transit time that effects arrival at the destination port. A fifth type may include a vessel that has multiple cargos shipped to multiple destination ports. A sixth type may include premiums based on perishable goods and the degree of perishability. These and other configurations are contemplated by and within the scope of the present invention. Other types of policies may be supported by the systems and methods of the present invention.

Turning now to flow chart 500 of FIG. 5, some of the steps involved in determining weather risk probabilities (RP) for maritime lading events in accordance with some embodiments of the current invention are shown. First, at step 502, historical weather information for the ports of origin and/or destination are obtained for the specified (or calculated) dates from interface of FIG. 2. This information may come from any suitable source such subscription, proprietary database, or known public indices etc. In some embodiments, multiple such historical databases may be consulted and their information combined or otherwise processed {e.g., averaged) to improve accuracy. Location data (step 503) is then accessed based on the data obtained from interface of FIG. 2 and user input.

Such information may also be weighted accordingly based on various factors such as resolution of available data points (weekly, daily, hourly etc), length of history {e.g., 1 year, 5 years, 30 years), source of data (satellite, historical database), geographic proximity of data collection point to port of interest, etc. The information may be combined as described above to produce a Combined Adjusted Historical Forecast (CAHF). This is typically desired on an hourly forecast basis but larger increments (3, 6, 12, or 24 hour) may be used if desired or if limited based on best available data resolution.

Next, at step 504, technical premium data may be accessed from servers operated by the underwriters or other third parties. This data may be relatively static, but can fluctuate based the margins expected.

Next, at step 505, BDI rates or other applicable rates based on cargo, vessel type etc., may be extracted if the user fails to enter a hire rate. These rates, on average, may be weighted in favor of a higher rate to help ensure profitability and avoid potential losses and may be adjusted based on the historic performance of certain similar or same shipping route. If the arrival time (call) is taking place about within 14 days, (for example 1-10 days) near term forecast data, (step 506), may be accessed and incorporated into the premium/risk calculation. Such near term forecast data may also be weighted, for example, 1-4 day forecast be given a higher weight than 4-8 day out forecast which would be given a higher rate than an 8-12 days out forecast etc. In some embodiments, weights may be assigned in descending order daily or even in hourly increments depending on the quality of the forecast.

In some embodiments, the chance of precipitation may be cross-checked by using short term temperature data and barometric pressure information. For example, one aspect of the invention may utilize near term temperature information in view of dew point {i.e., the atmospheric temperature varying according to pressure and humidity below which water droplets begin to condense and dew can form), assuming rain occurs when the dew point is above a certain predetermined temperature (e.g., about 68 degrees F). Portions of weather forecast where precipitation is uncertain may benefit from this analysis.

Next, at step 507, the models may combine the CAFIF data, location information, and BDI or other hire rates to calculate weather risk probability (RP) and an associated estimated premium for each day and combine this information to form a quote for the user. In some embodiments,. Time In Port (which may be measured in days or hours) may be the average turnaround time for a similar ship at the same port may be taken into consideration in determining the RP. Generally speaking, the longer time spent in port (busy, congested port, large ship) the greater the chance of potential loss. The present invention may account for this variable by using a moving average for the last several similar vessels to arrive/depart from the terminal.

In some preferred embodiments, this information is relatively current, (days or weeks, or a few months at most) because older values of this number may not accurately reflect current expected TIP due to changes in port or other conditions.

Furthermore, it will be understood that numerous proprietary algorithms may be used if desired at step 507 to calculate risk probability. One such basic example is given below.

However any other suitable method that considers the input data may be used if desired.

It will be understood that these steps are merely illustrative, and are not meant to be comprehensive or necessarily performed in the order shown. Further it may not be necessary to perform all steps or fill out all fields of the invention as described above in order for the invention to function as contemplated. For example, the user interface may specify certain "required fields" depending on the desired operation or insurance type desired in order for a basic calculation to take place and thus other such unnecessary fields may be optional.

Weather Risk Probability (RP) Calculation:

One possible way of calculating RP at step 507 may be to use hourly weather data to compute climatological daily duration of rainfall. It will be understood this is merely just one basic method and many other different methods or more sophisticated methods may be used if desired. The process may be as follows:

1. Obtain intra-daily weather data from the Integrated Surface Hourly Dataset. a. consider historical stations that have at least 20 years of data, of which 10 are substantially complete years. b. identify a characteristic reporting frequency of each station. i. Index a data time series according to several common reporting frequencies (1 -hourly, 3 -hourly, 6-hourly) ii. For a given variable of interest:

1. If all three frequencies yield a data completion percentage of 90 percent or greater, the assumed reporting frequency is 1 hour.

2. Otherwise, the assumed frequency that yields the greatest percent completion is the assumed reporting frequency. c. consider data from local forecasts if period of interest is within about 14 days or less in future. d. When a reporting frequency is established, fill out missing entries in the time series with null values so subsequent statistical computations can be based on a complete series.

2. Compute a value for each Julian calendar day of the year (excluding 29 Feb) of the average number of hours per day with precipitation for each station. a. For stations only reporting in 6-hour intervals assume that precipitation duration is related to dew point. This assumption is not required for stations reporting data in 1 or 3-hour intervals. i. If the dew point was 68F (20C) or greater, assume rainfall occurred over 3 of the 6 hours. Else, assume it rained over all 6 hours. b. For each Julian calendar day, use a centered window of +/- 14 days, over a climatological period of 30 years, 1981-2010. (Other sized windows and years or periods are within the scope of the present the invention). i. For example, for July 1 at an arbitrary station:

1. Average hours of precipitation from 17 June - 15 July

for each year in 1981-2010 to create a series of thirty

values that represents the 30 July 1 dates in the series.

2. Average the thirty July 1 values to obtain the average

daily precipitation duration for July 1 at that station. c. Values for 29 Feb shall be the average of the values of 28 Feb

and 1 Mar.

3. Results are stored in a file system/database format for use in subsequent queries.

Total Potential Risk:

In some embodiments, three primary factors may be taken into account when calculating the actual financial risk due to weather delays for any given voyage

• Weather Risk Probability (RP)— This is the total number of hours of rain for the expected duration of a stay in port on the relevant dates divided by the total number of hours of the stay. The total number of hours of rain is obtained by taking the average rainfall for each Julian day of the stay as derived as described above, and then adding up these hours.

This is shown in FIG. 6 for several ports. For example, in the first table, the stay is 72 hours, and the average rainfall for the relevant dates totals 16 out of the 72 hours, hence, the RP is 0.22.

• Baltic Dry Index (BDI)— This is an economic indicator issued daily by the London-based Baltic Exchange. The index provides "an assessment" of the price of moving major raw materials by sea. The Index is gives us an indication of the revenue earning potential of a bulk carrier on that day.

In embodiments of the present invention, the current day's BDI at the time of the fixture can be used (other days' BDI are within the scope of the present invention).

• Time in port (Days)— This is an average turnaround time for a similar ship at the same port. The longer time spent in port the more chance of potential loss. The present invention uses a moving average for the last several vessels calling the terminal. This is very current, since old values of this number may be meaningless.

Formula (1) for calculating the Risk Index for a given port on a particular day is as follows:

Risk Index = f(RP * 100) * BDI * Days] / 100

Final Analysis

A risk index may be computed for each port of call. In some embodiments, these may not combined together, for example, in the case where the risk at one port may be substantially higher than the risk at another port. In such instances, the risks are considered separately in computing premiums.

Explanation of BDI

As stated, the Baltic Dry Index (BDI) is an economic indicator issued daily by the London-based Baltic Exchange. Not restricted to Baltic Sea countries, the index provides "an assessment" of the price of moving the major raw materials by sea. Taking in 23 shipping routes measured on a timecharter basis, the index covers Handysize, Supramax, Panamax, and Capesize dry bulk carriers carrying a range of commodities including coal, iron ore and grain.

The concept is to use the previous day's quote to assess the potential financial risk. There are variations within the BDI from week to week. The index itself can be viewed at: https://www.bloomberg.eom/quote/BDIY:IND

To put in perspective how poorly the market has performed, and why the present invention helps alleviate uncertainty caused by loss of revenue due to weather, the following can be considered. In 2007 the BDI was around 12,000; it now (2017) hovers around 1,000. While the financial risks are greater at 12,000, the gains make up for the losses very quickly. Staff, ships, bunkers, stores, and the like are static regardless of the BDI, so the lower the BDI, the more potential risk to an organization.

The present invention is a system and method for accessing risk associated with shipping a cargo into or out of a port. Risk for an entire shipment can be considered by computing a Risk Index for each port of call where loading or discharge will occur. These numbers are random variables and are considered statistically independent (from one port to another). They can be combined to access the overall weather-related risks for a particular shipment. The present invention does not consider time at sea or risks associated with events that can occur at sea including weather-related events.

Aspects of the present invention can 1) provide a global average over a given year based on known variables; 2) provide a port specific or cargo specific average at any given time; and 3) compare a fixture to these averages to gauge the financial risk of weather delays. Several descriptions and illustrations have been presented to aid in understanding the present invention. One with skill in the art will realize that numerous changes and variations may be made without departing from the spirit of the invention. Each of these changes and variations is within the scope of the present invention.

Technological Improvements

The present inventions provide numerous technological improvements over the prior art. In the first instance, an efficient user interface is provided that allows a vessel and/or cargo owner to quickly assess weather related delay risks associated with an anticipated or

contemplated voyage. Customization options regarding voyage details to mitigate risk are provided. Further, the systems and methods described herein offer several computer science related advantages. The first advantage is it provides a framework within which weather forecast information associated with certain dates and locations can be transformed into an economic risk assessment based on likely weather related delays so business decisions can be made. A financial cost and risk mitigation option or alternative is provided to the vessel and/or cargo owners, assisting in ensuring economic variability of a contemplated voyage for vessel and cargo owners alike. This may include dynamically pre-populating and updating databases with the relevant changing weather information in view of historical shipping route and port of call performance to provide real time responses to consumer request for insurance quotes. Changes in hire rates may also be reflected.

This is important in the competitive insurance industry because consumers are savvy with cost parameters and are likely to select the first most economically viable solution to fit their particular needs. Delay and/or poor fashioned rate quotes may cost a sale. Thus, real time or near real time responses to consumer requests may be a key to insurance merchant success.

Furthermore, accurate data helps ensure that underwriter provide coverages that are

economically productive to help ensure profitability to underwriters and savings to consumers. For example, in some embodiments, each voyage entered by a consumer may have its own associated unique dynamic data structure such as a record associated with it that reflects voyage details. In some embodiments, this may be stored on network devices 103 or 105 (or a combination thereof). In other embodiments, this information may be stored on client devices. As time progresses, information regarding each voyage may be periodically updated to reflect changing conditions. In this case, premium quotes and/or other terms and conditions may be remodeled. Thus, for example, if a user has entered certain voyage details but not purchased insurance, updates may be sent (via email or text message) to the consumer in real time (or near real time) reflecting policy updates to the consumer based on the most current information. Such updates may reflect or indicate trends in pricing moving up or down, risk of shipping delay increasing or decreasing, other terms changing, purchase option windows, etc. all of which allows the consumer to make informed purchase decisions. Further, for policies in force, the underwriter may offer similar periodic modifications based on periodic remodeling that may benefit the consumer based on the favorably changing conditions.

It will be understood that these steps are merely illustrative, and are not meant to be comprehensive or necessarily performed in the order shown. Persons skilled in the art will appreciate that the present invention can be practiced by other than the described embodiments, which are presented for purposes of illustration rather than of limitation, and the present invention is limited only by the claims which follow.

Claims

1. A computer-implemented method for determining weather risk associated port

based lading operations comprising:

determining a port of origin;

determining a destination port;

determining a departure date from the point of origin;

determining an approximate arrival date at the destination port;

calculating aggregate weather based risk to a ship owner,

determining a near term weather forecast and variation thereof and adjusting the calculated aggregate risk of port based weather delays in lading operations based on the near term weather forecast;

generating, based on the adjusted calculated aggregate risk a Charter Party insurance policy including premium calculation and associated terms;

transmitting, over a network in near real time to an application on a client device, terms of the Charter party contract including the cost of the policy and coverage limits and cause the application to display the policy on the client device for approval by a charter party.

2. The method of claim 1 wherein the calculating aggregate weather based risk is performed at least in part by a risk assessment server.

3. The method of claim 1 wherein the calculating aggregate weather based risk is performed at least in part by an actuarial server.

4. The method of claim 1 wherein the adjusted calculated aggregate weather based risk is performed at least in part by an actuarial server.

5. The method of claim 1 wherein the adjusted calculating aggregate weather based risk is performed at least in part by a risk assessment server.

6. The method of claim 1 further comprising generating a substantially unique voyage data structure for each port of origin and destination determined.

7. The method of claim 6 further comprising dynamically updating the substantially unique voyage data structure.

8. The method of claim 1 wherein the generating the adjusted calculated aggregate risk a Charter Party insurance policy including premium is based, at least in part on hire rate.

9. A system for determining weather risk associated port based lading operations comprising:

determining a port of origin through a client based user interface;

determining a destination port through the client based user interface;

determining a departure date from the point of origin through the client based user interface;

determining an approximate arrival date at the destination port;

calculating aggregate weather based risk to a ship owner with a risk

assessment server,

determining a near term weather forecast and variation thereof and

adjusting the calculated aggregate risk of port based weather delays in lading operations based on the near term weather forecast with a risk assessment

server;

generating, based on the adjusted calculated aggregate risk a Charter Party insurance policy including premium calculation and associated terms with the risk assessment server;

transmitting, over a network in from the risk assessment server in near real time to an application on a client device, terms of the Charter party contract including the cost of the policy and coverage limits and cause the application to display the policy on the client device for approval by a charter party.

10. The system of claim 9 wherein the calculating aggregate weather based risk is performed at least in part by an actuarial server.

11. The system of claim 9 wherein the adjusted calculated aggregate weather based risk is performed at least in part by an actuarial server.

12. The system of claim 9 further comprising generating a substantially unique voyage data structure for each port of origin and destination determined with the risk assessment server or actuarial server.

13. The system of claim 9 further comprising dynamically updating the substantially unique voyage data structure with the risk assessment server or actuarial server.

14. The system of claim 9 wherein the generating the adjusted calculated aggregate risk a Charter Party insurance policy including premium is based, at least in part on hire rate.

15. A website that allows a user to determine weather risk associated port based lading operations comprising:

a first data entry field that allows a user to select a port of origin through a client based user interface;

a second data entry field that allows a user to select a destination port

through the client based user interface;

a third data entry field that allows a user to select a departure date from the point of origin;

a fourth data field for determining an approximate arrival date at the

destination port;

a communication link to a risk assessment server that allows for the

calculation of a aggregate weather based risk to a ship owner with a risk

assessment server, and further allowing for the determination of a near term weather forecast and variation thereof and adjusting the calculated aggregate risk of port based weather delays in lading operations based on the near term weather forecast with a risk assessment server;

wherein the risk assessment server generates, based on the adjusted

calculated aggregate risk a Charter Party insurance policy including premium calculation and associated terms and; transmitting, over a network in from the risk assessment server in near real time to an application on a client device, terms of the Charter party contract including the cost of the policy and coverage limits and cause the application to display the policy on the client device for approval by a charter party.

16. The website of claim 15 further comprising generating a substantially unique voyage data structure for each port of origin and destination determined with the risk assessment server or actuarial server.

17. The website of claim 16 further comprising dynamically updating the substantially unique voyage data structure with the risk assessment server or actuarial server.

18. The website of claim 15 wherein the generating the adjusted calculated aggregate risk a Charter Party insurance policy including premium is based, at least in part on hire rate.