Method and apparatus for insurance management system

The system provides a method and apparatus for tracking and managing insurance coverage for an enterprise. In one embodiment, the system provides automated reports that include all types of coverage in a single report with a visual representation that fully informs the reader of status and areas of risk and concern. The reports are fully sortable and can provide a single resource for management of all policies and coverages of an enterprise. In one embodiment the system presents data in a unique grid that provides important information at a glance and enhances management of the system.

BACKGROUND OF THE SYSTEM

Many enterprises must obtain and maintain a wide range of insurance coverages to protect against loss. It is important for an enterprise to not be over-insured, which adds to overhead and expenses. It is also important for an enterprise to not be under-insured, which can lead to uncovered losses. In some instances, the failure to have the correct insurance may be prohibited, either by statute, practice, contractual agreement, trade association requirements, and the like. Tracking multiple types of insurance and multiple policies presents a problem for many enterprises.

In the prior art, an enterprise may manually maintain databases and/or spreadsheets for each coverage type as well as a master consolidated spreadsheet of all coverages. Making any change or update must be populated correctly over all databases and spreadsheets, which can lead to errors that affect coverage. The spreadsheets may be sent periodically to the insurance agent of the company to verify coverage by issuing certificates of insurance and premium invoices based on the spreadsheet. If the spreadsheet is wrong, the insurance agent may issue incorrect or insufficient policies and/or coverages.

SUMMARY

The system provides a method and apparatus for tracking and managing insurance coverage for an enterprise. In one embodiment, the system provides automated reporting systems that include all types of coverage in a single report with a visual representation that fully informs the reader of status and areas of risk and concern. The report is fully sortable and can provide a single resource for management of all policies and coverages of an enterprise. In one embodiment the system presents data in a unique grid that provides important information at a glance and enhances management of the system.

DETAILED DESCRIPTION OF THE SYSTEM

The system can be used to accomplish a number of operations related to enterprise insurance. One industry in particular with complex insurance needs is the transportation industry. A transportation company may use many drivers, either as employees or independent contractors, and use many vehicles, either owned, leased, or contracted. It is critical that all insurance obligations be met properly, avoiding over-insurance and under-insurance situations. The company must have a variety of insurance coverage types, including auto liability, physical damage, non-trucking liability, occupational accident, contingent liability, cargo insurance, general liability, passenger accident liability, and the like. Although the system is described in connection with a trucking enterprise, it is understood that it has equal application in any enterprise that has insurance.

FIG.1is a functional block diagram of an embodiment of the system. The system100includes a processing engine/database101that provides the intelligence of the system and stores the data related to the elements of the insurance management system. This data includes the coverages, policy information, renewal dates, premiums, vehicles (asset type, ID, values, type of driver, lienholder information), sponsored and non-sponsored coverages, employee/independent contractor status, driver information (including some personally identifiable information that will be encrypted) and the like

The system communicates with the outside world via import/export engine102and/or user interface107. The import/export engine102can be used to send reports, alerts, communications, and the like as appropriate. In addition, import/export engine102can receive communications from transportation management systems (TMS), agency management systems (AMS), insureds, insurers, customers, and the like. The system includes the ability to import and export vehicle lists to and from spreadsheets (e.g. Excel) and provide alerts when data is not complete. Multi-user audit tracking is implemented to maximize reliability and accuracy of data. Client access is provided to permit direct changes while maintaining an audit trail for accountability.

The reporting engine103is used to generate the automatic and custom reports of the system. The reporting engine receives commands from the processing engine/database101including deadlines for report runs and will generate the required reports when triggered. The reporting engine103can also generate communications (e.g. texts, emails) with clients as desired, generate invoice, and the like. The system provides reporting for periodic (e.g. monthly) billing (e.g. monthly PD and NT billing). The system will save a report of enterprise status pursuant to policy requirements of reporting. For example, if a policy requires a report to be run on the 5thof each month, the system will automatically save a report on that day. The system permits customization of all aspects of the reporting and data analytics.

Certificate engine104can generate and deliver vehicle certificates individually, in batches, and can do so based on values, owner, lienholder, and the like. The system can batch all certificates for a lienholder for example, and email them at once. In one embodiment the system can issue physical damage (PD) and non-trucking (NT) certificates. It can also issue occupational accident (OA) certificates and combined PD, NT, and OA on a single certificate. The system allows for batching of vehicles and batch production of multiple vehicle certificates (e.g. for all units with the same lienholder).

The VIN decoder/analyzer105checks the accuracy of VINs input to the system. The VIN decoder/analyzer105has multiple levels of checks for correct VINs, including analyzing the VIN itself for the correct number of digits, and recalling the vehicle description associated with the VIN to make sure it matches a vehicle that is in the system. The VIN decoder/analyzer105also checks automatically for duplicate VINs, avoiding errors in many parts of the system. The VIN decoder/analyzer105can catch mistakes in VIN entry, preventing downstream problems.

Audit engine106tracks which user makes changes to any data or meta-data in the system, with timestamps and date-codes. The audit engine106also tracks client changes made by users accessing the system via user interface107. By allowing users to make changes, while maintaining an audit trail, efficiency and accuracy are promoted by the system. The user interface107communicates with a user dashboard108.

The user dashboard108is used by a number of entities, including an agency (e.g. insurance agency) an insured (e.g. a trucking company) or others, to track a number of metrics. In one embodiment the user dashboard108allows the user to track expiring policies, recent vehicle transactions, recently added vehicles, recently deleted vehicles, non-sponsored policies, recent policy transactions, and the like.

The dashboard108also includes a clients summary page where the agency may add clients, initiate client summary exports, present policy counts (with linking to parent and grandparent clients, child and grandchild clients, etc.), units client transactions, insured unit summaries by coverage type and drivers, and the like.

The dashboard also includes a vehicles page for each client that includes sortable columns, the ability to add and delete vehicles, manage certificates, respond to a call-to-action, track lienholder/owner/drivers/transactions, and the like.

Unit coverage can be determined at a glance. In some situations, an enterprise may have independent contractors on both sponsored and non-sponsored plans. The system allows easy tracking of such situations.

The system has a number of advantages over prior art systems. The system provides a consolidated vehicle list, provides multiple user access and audit trail, can issue insurance certificates, provides employee access to online certificates, and provides reports at the frequency selected by the user. The system presents a color-coded and icon-based grid of unit coverages that allows a user to know status at a glance. The system includes a counter of responses and action items, and allows easy sorting to get to only the items that require action. This eliminates manual searching for action items.

FIG.2illustrates an example of an interface on the dashboard in an embodiment. The dashboard200has a plurality of tabs201-209that each represent an interface. The tabs include Home201, Clients202, Policies203, Vehicles204, Insurers205, Contracts206, Lienholders207, Agencies208, and Settings209. The system may have additional, different, or fewer tabs as appropriate.

InFIG.2the Clients tab202is selected. The dashboard presents clients of an insurance agency in this example. The Clients202interface includes a number of columns including Name201(the name of the insured), Agency211(the insurance agency that is working with the insured to get the policy), Producer212(the agent of the agency who is handling the insured), CSR213(Customer Service Representative), and Policies214. The “M” next to Policies represents the “master” or “parent” client policy. In one embodiment, the light blue color represents a clickable link so if the user clicks the number in this column, the system will redirect to the client policies listing. The number on the left represents child client policies. The system can manage grandchild/child/parent policy logic as well.

Region215in the Client tab202shows numerical information related to the column headings. In other tabs, the region may show iconic and/or graphical representations of information. Region215shows a plurality of columns related to the vehicles, including AL (Auto Liability), CG (Cargo) PD (Physical Damage), NT (Non-Trucking), OA (Occupational Accident), PA (Passenger Accident), Drivers, Reports and Options (Options include Edit vehicle, Delete unit, and Transaction/audit trail.

FIG.3illustrates the Client tab202when a client edit option has been selected. Selecting a client in Name201column brings up the interface300illustrated inFIG.3. Region301includes fields for Client name, address, contact, and other information, including DOT # (Department of Transportation). Region302includes a list of client contacts, titles, and contact information (e.g. email). Client contact can also include permission logic to define contact roles and rights, as well as access to monthly reports, audit emails, and the like.

FIG.4Aillustrates a summary page for client reports. The interface is one that appears when a Report icon is selected in region215ofFIG.2in an embodiment. The interface400shows a summary of reports for PD Policies401, OA Policies402, AL Policies403, NT Policies404, PA policies405, CG Policies406and Vehicle Policy Summary407. The report summaries may include policy term, policy number, average values, monthly rate, monthly average, and the like. Each report may have different summary information. For example, OA Report402includes the average number of drivers, AL report includes the average units, power units, and non-power units.

FIG.4Billustrates a detailed report when the user selects, for example, summary401ofFIG.4A. The client is illustrated in region410, with the type of report (e.g. PD Policies) in region411. Policy detail is provided in region412, including report date, values, monthly rate, monthly total, report +/−, and regenerate. The monthly summary view gives data as well as two report types per month; a PDF for invoice unit summary of costs and an Excel type report showing Adds/Deletes of units/drivers with net summary of change, information which is important to some insurance companies billing report requirements.

FIG.5illustrates the Vehicle tab204in one embodiment. The system provides an all-in-one consolidated vehicle list that makes it easy to manage real-time assets for clients. The system has built-in logic to reduce errors and omissions, data entry errors, and mis-identification of vehicles. The system includes a VIN decoder to make sure the vehicles have the proper number of digits and that make and model are accurate. This interface500includes columns for Unit501, VIN502, Year503, Make504Added Date505, Value506, Client Name507, Type508, Status Region509, Driver510, and Owner511.

Region509implements a practical system for displaying information that can be quickly digested and understood by a user. Region509includes information about DT, AL, CG, PD, NT, OA, PA, and Options. The columns typically include one entry per row, but in one embodiment, an “F” in a circle indicates that a future policy selection is present. Selecting the F will map to the new future policy and any active policy. The system uses, symbols and color to provide status information in each column. For example, a red circle with an exclamation point inside indicates that action is required. This icon is a call-to-action that means a response is needed. In one embodiment, this icon is a default icon alert for a unit that has no known coverage information. This means that someone needs to take actions to determine if the unit has sponsored coverage, or if a certificate needs to be issued for the unit, or if the unit has non-sponsored coverage.

A green check means the vehicle is confirmed for sponsored coverage. Coverage is entered and/or verified through a client sponsored program. A certificate of insurance is available for viewing. A blue check means the vehicle is confirmed for non-sponsored coverage. A certificate is not available but coverage dates and expiration dates are tracked in one embodiment of the system. As noted above, the green “F” in a circle refers to a future policy. If a unit is mapped to a current/active sponsored policy and a future policy then green check+F will be displayed. If it is a new client and/or new policy then there is no active policy so the “F” designation is helpful to know it's successfully mapped to a future effective date policy and the certificate icon is available for proof of future insurance. If active and future are present, on clicking of certificate icon both certificates will be generated; one for active policy and one for future policy.

The Options columns of region509include certificate generation (green circle), Email certificate (dark blue email symbol), Edit vehicle gold icon, Transaction/audit trail (opposing arrows) and Delete unit (gold x). The certificate generation icon will show one or more insurance certificates for a unit when selected. The Email icon will create an email with the certificate attached.

The user can select filter the Vehicle tab204to show only the vehicles for a particular client. An embodiment of that interface600is illustrated inFIG.6. In this view the client is shown in region601. A coverage summary is shown in region602and region603shows the responses needed. The user can click on the call-to-action in region603and the system will display only those units with response needed.

The goal is to get the Response Needed (RN) value to zero, meaning every vehicle has sponsored coverage, non-sponsored coverage, or coverage declined. In one embodiment, the user can click on the RN number on the Home tab201and it will display only the clients for which responses are needed. When the user selects one of those clients, the system will display the RN for that client. If the user selects the client RN number the system shows only the rows for the client vehicles needing responses. This allows the user to quickly take care of necessary responses.

FIG.7illustrates the interface when “drivers” is selected inFIG.4,5, or6. The interface700includes region701for the name of the client, region702shows the total number of drivers currently with the company. Region703shows the total of OA drivers. Region704is the average driver age, region705is the average number of years of experience of the drivers, and region706is the geographical location (e.g. by state) of the drivers.

Region708provides information about each driver. This region can be reduced to a more limited number of columns as desired. For example, the region could simply show vehicle unit, driver name, OA information, and the option field. In the expanded view, in one embodiment, the region708shows vehicle unit number (if a driver is attached to multiple units, no unit number is shown for that driver), name, date of hire, date of birth (and age), CDL original date (with number of years), license issue state, license number, address, contact information (address, email, phone, and the like), OA added date, and option field. The option field can contain icons that provide certificate, editing, deletion, and audit trail in one embodiment.

When the RN region707has a non-zero number, the system can isolate drivers who have an RN condition when the user clicks on the number in region707. The system will display only those drivers who need some sort of action to be taken.

The RN region in every interface is powerful because it provides a practical way to identify and isolate action items that need to be accomplished to make sure that requirements are met and that the enterprise is in compliance. This practical solution is a benefit over prior art spreadsheet-based systems where the user needs to hunt down action items manually or perform a plurality of sorting operations to ensure that all action items are discovered, handled, and updated.

As described above, one of the Response Needed items is that coverage is missing from a certificate of insurance. In one example embodiment, the system is used in the insurance industry, in particular for truck fleet insurance.FIG.8is an example of an insurance certificate issued by the system in an embodiment. The certificate800can be automatically generated by the system. The certificate includes the date of issuance801, the issuing agency802, the named insured803, and the vehicle owner804, which may be different than the client, depending on the situation.

The certificate800automatically populates the vehicle805, unit number806(defined by the insured803), and the VIN807(note the VIN will be double checked by the VIN decoder/analyzer to make sure the VIN807matches the vehicle805).

The coverages are listed, such as Auto Liability Coverage808and Physical Damage Coverage809. The coverages include policy numbers, effective date (which may be different than the issue date), end date, limits, deductible, and the actual insurance company. Region810includes disclaimer language and the system anticipates e-signing region811. This is a specific signature by the system attached Agency's approved licensed Producer. If no producer selected then no signature would be required, but in an embodiment, the Agency should have a Producer selected.

FIG.9Ais an example of the Home201interface900in an embodiment of the system. The interface900includes RN region901showing RN(V) for vehicles and RN(D) for drivers, Power Units902, Non-power units903, Driver count904, expiring policies905, and recent vehicle transactions906. In one embodiment the Home tab can also show recently added vehicles, and recently deleted vehicles. The system will automatically generate important reports that track the net change in vehicles (newly added vs newly deleted) so that appropriate billing adjustments can be made. For example, in some circumstances, billing is a monthly “per power unit” rate. Therefore, a plus or minus change in the number of vehicles is used to calculate the change in rate. If there is a net increase of seven power units for example, the billing is adjusted up by seven times the monthly rate per power unit.

If the user selects RN(V) (showing 1 RN in this case) the system will display the interface as shown inFIG.9B. This will filter to show only the client rows having RN(V) greater than zero (the same for RN(D). The interface includes region905which is a filter set to show RN (but the user can change that filter to display other data. Region906shows the client and the RN(V) column907shows the count of responses needed.

If the user selects the number in column907, the system presents the interface as shown inFIG.9C. Region909indicates the filter is “response needed”. Region910graphically shows the coverage that requires a response. In this example, it is the PD policy that requires action.

Another advantage of the system is the ability to interface with third parties, including the Department of Transportation (DOT). This allows the system to obtain DOT information, FMCSA information, Safety inspections, and the like. The system can also integrate transportation management systems and agency management systems. These systems all have the ability and permission to add vehicles, delete vehicles, and edit vehicles, providing for a single system to replace multiple prior art systems.

FIG.10is a flow diagram illustrating the operation of the system in an embodiment. The steps ofFIG.10may be performed on a per client basis, per agency basis, and the like. At step1001the system checks expiring policies. At step1002the system checks for net changes in vehicles. At step1003the system checks driver changes and updates, including unit assignments. At step1004the system checks certificates.

At step1005the system updates icons associated with system data based on the results of steps1001-1004. For example, expiring policies and missing coverage will create a red action icon associated with the data. In one embodiment the dashboard will also display policies that are due to expire shortly (e.g. within some user determined time period). Expired policies are shown in Not Active policy pages for access by the user. Attached Reports for those Expired policies are accessible too. At step1006the system updates the Response Needed counters as appropriate (based on missing responses) and displays data at step1007.

FIG.11is flow diagram illustrating a response to a call-to-action in an embodiment of the system. At step1101a user selects an icon indicating a response needed. As noted above, such an icon could be a red exclamation point in a circle. At step1102the system provides the proper interface for taking the desired action. For example, the system could provide a certificate for completion, a report to generate, email to send, and the like. At step1103the user performs the action.

At decision block1104it is determined if the action is complete. If not, the system returns to step1103. If the action is complete, the icons and RN counters are updated accordingly.

Example Computer System

FIG.12illustrates an exemplary a system1200that may implement the system. The electronic system1200of some embodiments may be a mobile apparatus. The electronic system includes various types of machine-readable media and interfaces. The electronic system includes a bus1205, processor(s)1210, read only memory (ROM)1215, input device(s)1220, random access memory (RAM)1225, output device(s)1230, a network component1235, and a permanent storage device1240.

The bus1205communicatively connects the internal devices and/or components of the electronic system. For instance, the bus1205communicatively connects the processor(s)1210with the ROM1215, the RAM1225, and the permanent storage1240. The processor(s)1210retrieve instructions from the memory units to execute processes of the invention.

The processor(s)1210may be implemented with one or more general-purpose and/or special-purpose processors. Examples include microprocessors, microcontrollers, DSP processors, and other circuitry that can execute software. Alternatively, or in addition to the one or more general-purpose and/or special-purpose processors, the processor may be implemented with dedicated hardware such as, by way of example, one or more FPGAs (Field Programmable Gate Array), PLDs (Programmable Logic Device), controllers, state machines, gated logic, discrete hardware components, or any other suitable circuitry, or any combination of circuits.

Many of the above-described features and applications are implemented as software processes of a computer programming product. The processes are specified as a set of instructions recorded on a machine-readable storage medium (also referred to as machine readable medium). When these instructions are executed by one or more of the processor(s)1210, they cause the processor(s)1210to perform the actions indicated in the instructions.

Furthermore, software shall be construed broadly to mean instructions, data, or any combination thereof, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. The software may be stored or transmitted over as one or more instructions or code on a machine-readable medium. Machine-readable media include both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage medium may be any available medium that can be accessed by the processor(s)1210. By way of example, and not limitation, such machine-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a processor. Also, any connection is properly termed a machine-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared (IR), radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray® disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Thus, in some aspects machine-readable media may comprise non-transitory machine-readable media (e.g., tangible media). In addition, for other aspects machine-readable media may comprise transitory machine-readable media (e.g., a signal). Combinations of the above should also be included within the scope of machine-readable media.

Also, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while remaining distinct software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Any combination of separate programs that together implement a software invention described here is within the scope of the invention. In some embodiments, the software programs, when installed to operate on one or more electronic systems1200, define one or more specific machine implementations that execute and perform the operations of the software programs.

The ROM1215stores static instructions needed by the processor(s)1210and other components of the electronic system. The ROM may store the instructions necessary for the processor(s)1210to execute the processes provided by the system. The permanent storage1240is a non-volatile memory that stores instructions and data when the electronic system1200is on or off. The permanent storage1240is a read/write memory device, such as a hard disk or a flash drive. Storage media may be any available media that can be accessed by a computer. By way of example, the ROM could also be EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.

The RAM1225is a volatile read/write memory. The RAM1225stores instructions needed by the processor(s)1210at runtime, the RAM1225may also store the real-time video or still images acquired by the system. The bus1205also connects input and output devices1220and1230. The input devices enable the user to communicate information and select commands to the electronic system. The input devices1220may be a keypad, image capture apparatus, or a touch screen display capable of receiving touch interactions. The output device(s)1230display images generated by the electronic system. The output devices may include printers or display devices such as monitors.

The bus1205also couples the electronic system to a network1235. The electronic system may be part of a local area network (LAN), a wide area network (WAN), the Internet, or an Intranet by using a network interface. The electronic system may also be a mobile apparatus that is connected to a mobile data network supplied by a wireless carrier. Such networks may include 3G, HSPA, EVDO, and/or LTE.