|
Insurance Abstract
Provided is a technique for evaluating risk associated with underwriting
an insurance policy (FIG. 1). At least one location to be covered
under the insurance policy is received (FIG. 3, block 320). Risk
associated with the location is automatically assessed (FIG. 3,
block 338). It is determined whether to underwrite the location
based on the assessed risk (FIG. 3, block 340). Also provided is
a technique for proximity analysis (FIG. 54). Selection of a proximity
center is received (FIG. 55). A function is executed with the proximity
center to determine target data items that fall within a proximity
area around the proximity center. The target data items are spatially
represented.
Insurance Claims
1. A computer-implemented method for evaluating risk associated
with underwriting an insurance policy, comprising: receiving one
or more locations to be covered under the insurance policy; and
automatically assessing risk associated with the one or more locations,
including generating rating results for one or more perils, wherein
the rating results indicate whether that peril may occur at each
of the one or more locations.
2. The method of claim 1, wherein automatically assessing risk
further comprises: applying at least one business rule.
3. The method of claim 1, further comprising: enabling selection
of at least one of an underwriting analysis and a risk analysis.
4. The method of claim 1, further comprising: enabling setup of
an event that may impact assessment of risk.
5. A computer-implemented method for evaluating risk associated
with underwriting an insurance policy, comprising: displaying a
setup events screen to enable setup of an event that may impact
assessment of risk; receiving an event type; receiving at least
one of ring details, damage rate information, and PML rating data;
receiving at least one location to be covered under the insurance
policy; and automatically assessing risk associated with the location
based on the event type and the received at least one of ring details,
damage rate information, and PML rating.
6. The method of claim 5, wherein ring details include a number
of rings and ring distance between each of the rings.
7. The method of claim 5, wherein damage rate information is associated
with each ring.
8. The method of claim 5, wherein the PML rating data includes
an association of PML and CAP.
9. A computer-implemented method for evaluating risk associated
with underwriting an insurance policy, comprising: displaying a
setup landmarks screen to enable setup of a landmark; receiving
a name of the landmark, a location of the landmark, a CAP associated
with the landmark, and a PML adjustment to the landmark; automatically
assessing risk associated with the location based on the CAP and
PML adjustment; and displaying rating results for the location for
one or more perils.
10. The method of claim 1, wherein a location may be selected by
at least one of a company search, an address search, or uploading
a file.
11. The method of claim 10, wherein selection of a location by
company search further comprises: receiving at least part of a company
name; searching for the company name in a business data store; and
retrieving at least one address from the searching.
12. The method of claim 11, further comprising: determining that
there are ambiguous addresses for the company name; and enabling
selection of at least one of the addresses.
13. The method of claim 10, wherein selection of a location by
an address search further comprises. receiving a street address
and at least one of a zip code and a city and state.
14. The method of claim 10, wherein selection of a location by
uploading a file further comprises: associating data in the file
with a predefined format.
15. The method of claim 10, further comprising: attempting to automatically
geocode the selected location.
16. The method of claim 15, wherein the location can not be automatically
geocoded and further comprising: enabling use of a spatial interface
to manually geocode the location.
17. The method of claim 1, wherein automatically assessing risk
further comprises: performing a proximity analysis.
18. The method of claim 1, wherein the rating results for at least
one peril are capable of being displayed on a map.
19. The method of claim 1, further comprising: enabling drilldown
into details of at least a portion of the rating results
20. The method of claim 1, further comprising: enabling exporting
of the rating results.
21. A computer-implemented method for evaluating risk associated
with underwriting an insurance policy, comprising: receiving at
least one location to be covered under the insurance policy; automatically
assessing risk associated with the location for at least one peril
by performing PML calculations for the peril at the location; and
providing rating results for the location and the at least one peril.
22. The method of claim 21, further comprising: receiving insurance
policy details; receiving location details for one location associated
with the insurance policy details; and generating PML results for
the location.
23. The method of claim 1, wherein assessing risk associated with
the location further comprises: assessing risk based on at least
one of unbound policies and bound policies.
24. A computer-implemented method for proximity analysis, further
comprising: receiving selection of a proximity center, wherein the
proximity center comprises a location; executing a function with
the proximity center to determine target data items that fall within
one or more proximity areas around the proximity center; and spatially
representing the target data items.
25. The method of claim 24, further comprising: receiving proximity
dimensions and a proximity analysis target data set.
26. The method of claim 25, wherein the target data items are identified
from the target data set.
27. The method of claim 24, wherein the function is a user-specific
function.
28. The method of claim 24, wherein the function may execute user-specific
logic to calculate result data.
29. The method of claim 24, further comprising: retrieving metadata
for the user-specific function.
30. The method of claim 24, further comprising: rendering the target
data items within at least one proximity area associated with the
proximity center; and overlaying the at least one proximity area
with at least one area boundary.
31. The method of claim 24, wherein there are multiple proximity
areas and wherein spatially representing the target data items further
comprises: displaying the target data items within the multiple
proximity areas.
32. The method of claim 24, wherein the function is a first function
and further comprising: retrieving metadata for a second function
that aggregates data in the target data set based on a proximity
area in which the target data item falls.
33. The method of claim 32, further comprising: executing the second
function to obtain aggregated proximity analysis results.
34. The method of claim 33, further comprising: retrieving metadata
for a report that generates custom reports from the aggregated proximity
analysis results; and creating the report.
35. The method of claim 34, further comprising: displaying the
report.
36. The method of claim 34, wherein the report comprises at least
one of a summary report and a fill report.
37. The method of claim 24, wherein the proximity center is selected
by at least one of an address selection, a latitude and longitude
selection, and manual creation on a map.
38. The method of claim 24, wherein proximity analysis is performed
for an event.
39. The method of claim 24, further comprising: saving proximity
analysis data by saving at least the proximity center, proximity
area data, report data, and at least one spatial data layer.
40. The method of claim 39, further comprising: enabling editing
of the proximity analysis data.
41. A computer-implemented method for proximity analysis, further
comprising: receiving selection of a proximity center; executing
a function with the proximity center to determine target data items
that fall within a proximity area around the proximity center; and
spatially representing the target data items; wherein the proximity
center comprises a landmark and proximity areas comprise rings encircling
the landmark.
42. An article of manufacture including a program for evaluating
risk associated with underwriting an insurance policy, wherein the
program causes operations to be performed, the operations comprising:
receiving one or more locations to be covered under the insurance
policy; and automatically assessing risk associated with the one
or more locations, including generating rating results for one or
more perils, wherein the rating results indicate whether that peril
may occur at each of the one or more locations.
43. The article of manufacture of claim 42, wherein the operations
for automatically assessing risk further comprise: applying at least
one business rule.
44. The article of manufacture of claim 42, wherein the operations
further comprise: enabling selection of at least one of an underwriting
analysis and a risk analysis.
45. The article of manufacture of claim 42, wherein the operations
further comprise: enabling setup of an event that may impact assessment
of risk.
46. An article of manufacture including a program for evaluating
risk associated with underwriting an insurance policy, wherein the
program causes operations to be performed, the operations comprising:
displaying a setup events screen to enable displaying a setup events
screen to enable setup of an event that may impact assessment of
risk; receiving an event type; receiving at least one of ring details,
damage rate information, and PML rating data; and automatically
assessing risk associated with the location based on the event type
and the received at least one of ring details, damage rate information,
and PML rating.
47. The article of manufacture of claim 46, wherein ring details
include a number of rings and ring distance between each of the
rings.
48. The article of manufacture of claim 46, wherein damage rate
information is associated with each ring.
49. The article of manufacture of claim 46, wherein the PML rating
data includes an association of PML and CAP.
50. An article of manufacture including a program for evaluating
risk associated with underwriting an insurance policy, wherein the
program causes operations to be performed, the operations comprising:
displaying a setup landmarks screen to enable setup of a landmark;
receiving a name of the landmark, a location of the landmark a CAP
associated with the landmark, and a PML adjustment to the landmark;
receiving at least one location to be covered under the insurance
policy; automatically assessing risk associated with the location
based on the CAP and PML adjustment; and displaying rating results
for the location for one or more perils.
51. The article of manufacture of claim 42, wherein a location
may be selected by at least one of a company search, an address
search, or uploading a file.
52. The article of manufacture of claim 51, wherein the operations
for selection of a location by company search further comprise:
receiving at least part of a company name; searching for the company
name in a business data store; and retrieving at least one address
from the searching.
53. The article of manufacture of claim 52, wherein the operations
further comprise: determining that there are ambiguous addresses
for the company name; and enabling selection of at least one of
the addresses.
54. The article of manufacture of claim 51, wherein the operations
for selection of a location by an address search further comprise:
receiving a street address and at least one of a zip code and a
city and state.
55. The article of manufacture of claim 51, wherein the operations
for selection of a location by uploading a file further comprise:
associating data in the file with a predefined format.
56. The article of manufacture of claim 51, wherein the operations
further comprise: attempting to automatically geocode the selected
location.
57. The article of manufacture of claim 56, wherein the location
can not be automatically geocoded and wherein the operations further
comprise: enabling use of a spatial interface to manually geocode
the location.
58. The article of manufacture of claim 42, wherein the operations
for automatically assessing risk further comprise: performing a
proximity analysis.
59. The article of manufacture of claim 42, wherein the rating
results for at least one peril are capable of being displayed on
a map.
60. The article of manufacture of claim 59, wherein the operations
further comprise. enabling drilldown into details of at least a
portion of the rating results
61. The article of manufacture of claim 59, wherein the operations
further comprise: enabling exporting of the rating results.
62. An article of manufacture including a program for evaluating
risk associated with underwriting an insurance policy, wherein the
program causes operations to be performed, the operations comprising:
receiving at least one location to be covered under the insurance
policy; automatically assessing risk associated with the location
for at least one peril by performing PML calculations for the peril
at the location; and providing rating results for the location and
the at least one peril.
63. The article of manufacture of claim 62, wherein the operations
further comprise: receiving insurance policy details; receiving
location details for one location associated with the insurance
policy details; and generating PML results for the location.
64. The article of manufacture of claim 42, wherein the operations
for assessing risk associated with the location further comprise:
assessing risk based on at least one of unbound policies and bound
policies.
65. A article of manufacture including a program for proximity
analysis, wherein the program causes operations to be performed,
the operations comprising: receiving selection of a proximity center,
wherein the proximity center comprises a location; executing a function
with the proximity center to determine target data items that fall
within one or more proximity areas around the proximity center;
and spatially representing the target data items.
66. The article of manufacture of claim 65, wherein the operations
further comprise: receiving proximity dimensions and a proximity
analysis target data set.
67. The article of manufacture of claim 66, wherein the target
data items are identified from the target data set.
68. The article of manufacture of claim 65, wherein the function
is a user-specific function.
69. The article of manufacture of claim 65, wherein the function
may execute user-specific logic to calculate result data.
70. The article of manufacture of claim 65, wherein the operations
further comprise: retrieving metadata for the user-specific function.
71. The article of manufacture of claim 65, wherein the operations
further comprise: rendering the target data items within at least
one proximity area associated with the proximity center; and overlaying
the at least one proximity area with at least one area boundary.
72. The article of manufacture of claim 65, wherein there are multiple
proximity areas and wherein the operations for spatially representing
the target data items further comprise: displaying the target data
items within the multiple proximity areas.
73. The article of manufacture of claim 65, wherein the function
is a first function and wherein the operations further comprise:
retrieving metadata for a second function that aggregates data in
the target data set based on a proximity area in which the target
data item falls.
74. The article of manufacture of claim 73, wherein the operations
further comprise: executing the second function to obtain aggregated
proximity analysis results.
75. The article of manufacture of claim 74, wherein the operations
further comprise: retrieving metadata for a report that generates
custom reports from the aggregated proximity analysis results; and
creating the report.
76. The article of manufacture of claim 75, wherein the operations
further comprise: displaying the report.
77. The article of manufacture of claim 75, wherein the report
comprises at least one of a summary report and a full report.
78. The article of manufacture of claim 65, wherein the proximity
center is selected by at least one of an address selection, a latitude
and longitude selection, and manual creation on a map.
79. The article of manufacture of claim 65, wherein proximity analysis
is performed for an event.
80. The article of manufacture of claim 65, wherein the operations
further comprise: saving proximity analysis data by saving at least
the proximity center, proximity area data, report data, and at least
one spatial data layer.
81. The article of manufacture of claim 80, wherein the operations
further comprise: enabling editing of the proximity analysis data.
82. An article of manufacture including a program for proximity
analysis, wherein the program causes operations to be performed,
the operations comprising: receiving selection of a proximity center;
executing a function with the proximity center to determine target
data items that full within a proximity area around the proximity
center; and spatially representing the target data items; wherein
the proximity center comprises a landmark and proximity areas comprise
rings encircling the landmark.
83. A computer system having logic for evaluating risk associated
with underwriting an insurance policy, wherein the logic is executed
by the computer system, the logic comprising: receiving one or more
locations to be covered under the insurance policy; and automatically
assessing risk associated with the one or more locations, including
generating rating results for one or more perils, wherein the rating
results indicate whether that peril may occur at each of the one
or more locations.
84. A computer system having logic for proximity analysis, wherein
the logic is executed by the computer system, the logic comprising:
receiving selection of a proximity center, wherein the proximity
center comprises a location; executing a function with the proximity
center to determine target data items that fall within one or more
proximity areas around the proximity center; and spatially representing
the target data items.
85. A computer system having logic for evaluating risk associated
with underwriting an insurance policy, wherein the logic is executed
by the computer system, the logic comprising: displaying a setup
events screen to enable setup of an event that may impact assessment
of risk; receiving an event type; receiving at least one of ring
details, damage rate information, and PML rating data; receiving
at least one location to be covered under the insurance policy;
and automatically assessing risk associated with the location based
on the event type and the received at least one of ring details,
damage rate information, and PML rating data.
86. The article of manufacture of claim 85, wherein ring details
include a number of rings and ring distance between each of the
rings.
87. The article of manufacture of claim 85, wherein damage rate
information is associated with each ring.
88. The article of manufacture of claim 85, wherein the PML rating
data includes an association of PML and CAP.
89. A computer system having logic for evaluating risk associated
with underwriting an insurance policy, wherein the logic is executed
by the computer system, the logic comprising: displaying a setup
landmarks screen to enable setup of a landmark; receiving name of
the landmark a location of the landmark a CAP associated with the
landmark, and a PML adjustment to the landmark; automatically assessing
risk associated with the location based on the CAP and PML adjustment;
and displaying rating results for the location for one or more perils.
90. A computer system having logic for evaluating risk associated
with underwriting an insurance policy, wherein the logic is executed
by the computer system, the logic comprising: receiving at least
one location to be covered under the insurance policy; automatically
assessing risk associated with the location for at least one peril
by performing PML calculations for the peril at the location; and
providing rating results for the location and the at least one peril.
91. The computer system of claim 87, wherein the logic further
comprises: receiving insurance policy details; receiving location
details for one location associated with the insurance policy details;
and generating PML results for the location.
92. Previously Presented) A computer system having logic for proximity
analysis, wherein the logic is executed by the computer system,
the logic comprising: receiving selection of a proximity center;
executing a function with the proximity center to determine target
data items that fall within a proximity area around the proximity
center; and spatially representing the target data items; wherein
the proximity center comprises a landmark and proximity areas comprise
rings encircling the landmark.
Insurance Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] The present invention relates to real time insurance policy
underwriting and risk management.
[0003] 2. Description of the Related Art
[0004] Insurance companies may insure against personal harm, property
damage, and business interruption caused by a specified peril. By
way of example, such perils (or perilous events) may include a natural
disaster (e.g., a tornado, a hurricane, an earthquake, a flood,
etc.), a manmade disaster (e.g. a release of hazardous material
from an industrial plant, a terrorist attack, arson, etc.), and
the like. Before underwriting a new or renewing an existing insurance
policy, an insurance company may receive information from an existing
or prospective customer from which an evaluation may be made about
the appropriateness of underwriting the policy.
[0005] When an insurance agent receives a request for an insurance
policy, the agent may receive existing or prospective customer data
from the policy such as: 1) the name and address of the requesting
entity (e.g. an individual or a company and the address of the property
to be covered); 2) the requested coverage type (e.g. life insurance
or property insurance for a specified peril); 3) the desired amount
of coverage, deductible, and premium; and 4) any other information
that the insurance company may use in evaluating whether to underwrite
the policy.
[0006] An insurance company may then evaluate such existing or
prospective customer data to determine whether underwriting the
requested insurance policy is appropriate. For example, an insurance
company may consider how accepting the proposed insurance policy
will affect their: 1) total revenue (e.g. an additional policy should
increase the insurance company's total revenue by the policy's premium);
2) total exposure (e.g., an additional policy should increase the
insurance company's total exposure by the policy's loss coverage);
3) probable maximum loss (PML) (e.g., an additional policy should
increase the insurance company's PML, the amount of loss expected
based on the total exposure underwritten for a specified zone and
perilous event times a predetermined PML loss factor).
[0007] Those skilled in the insurance industry know that a PML
loss factor may vary based on an estimated likelihood that a specified
peril (e.g., a tornado) may occur in a specified zone (e.g., Dallas,
Tex.) to cause a specified degree of damage (e.g., 10 million).
It is also known to those skilled in the art that a PML loss factor
may vary for various areas within a specified high risk zone (e.g.
an area within a zone may have had far more tornadoes than other
areas within the same zone). Moreover, to estimate a PML loss factor,
those skilled in the art may consider such issues as the type of
peril, the particular area of the country where the perilous event
may occur, the time of year for the perilous event, the type of
construction for the potentially-effected structures, etc.
[0008] The insurance company may base its evaluation on a predetermined
standard, such as PML for a specified peril in a specified high
risk zone not exceeding a specified PML limit. For example, if accepting
a prospective policy would (by adding one or more locations for
coverage for a specified peril in a specified high risk zone) increase
the PML for this zone and peril above a predetermined PML limit
(also known as CAP limit), then the policy may be presumptively
denied. Alternatively, if accepting a prospective policy would not
(by adding one or more locations for coverage for a specified peril
in specified high risk zone) increase the PML for this zone and
peril above the CAP limit, then the policy may be presumptively
accepted.
[0009] To make such an evaluation, the insurance company may wish
to determine where the locations to be covered reside with respect
to the specified high risk zone (e.g., in the zone, out of the zone,
or near the zone). As discussed below, the process presently used
by the insurance companies to determine where locations to be covered
reside in relation to a specified high risk zone and evaluate based
on such a determination whether to underwrite a policy is manually-intensive,
very slow, and often produces inconsistent and inaccurate results.
[0010] There are presently two general approaches that may be taken.
In one approach, using geospatial analysis techniques, a geographic
information system (GIS) specialist uses a conventional GIS application,
such as Arc Info from ESRI, Inc. of Redlands, Calif., to determine
whether locations from a prospective policy are geographically located
within a high risk zone, while the other general approach may not
even make such a determination and does not employ a GIS application.
The GIS-based approach may provide a more well-reasoned evaluation
(compared to a non-GIS-based approach) but, as discussed below,
is generally a manually-intensive, slow, and inconsistent process.
Because the GIS-based approach is so slow, insurance companies may
not use it other than for their largest policies or possibly not
at all. Consequently, many insurance companies presently underwrite
numerous policies, assuming risk without the knowledge that may
be gleaned from the GIS-based approach.
[0011] One factor that slows GIS-based evaluations is the fact
that although GIS software applications are indeed available, such
applications require interactive manual operation by a specially
trained GIS operator. The number of trained GIS operators is limited
compared to the number of insurance underwriters drafting policies
for evaluation.
[0012] Even assuming that an insurance company has access to a
GIS operator, other issued contribute to the slowness of the GIS-based
approach. For instance, before a GIS operator may consider an existing
or prospective customer's address, the address must be "encoded."
Gooding is a well-known GIS process performed by conventional programs
that, among other things, associate a specific geographic location,
such as a geospatial coordinate (e.g. latitude and longitude), with
an address so that the location of the address may be displayed
on a display device over a spatial (e.g., a map) image, which may
include other geospatial information such as state or county boundaries,
building locations, etc. A GIS operator may then observe on a GIS
application's display the location of the encoded address from the
prospective policy.
[0013] However, before encoding an existing or prospective customer's
address, it is desirable to obtain a comprehensive list of all relevant
addresses to be covered by the prospective policy. For instance,
the existing or prospective customer may be a company owning several
subsidiary companies, which together have hundreds of business locations
to be covered under the policy. Before encoding, someone (typically
not the GIS operator) may wish to obtain the addresses of all the
locations to be covered. Thus, the GIS operator may have to wait
for other personnel to create a comprehensive list of addresses
for the prospective policy, assuming that such a list is prepared
at all. Presently, crating a comprehensive list of relevant addresses
is, at best, inconsistently performed in the insurance industry.
[0014] Before encoding, it is also desirable to perform an "address
cleansing process," regardless of whether a comprehensive address
list is first created. At present, address cleansing is also, at
best, inconsistently performed in the insurance industry. Address
cleansing, a well-known process in the GIS field, generally involves
comparing the address entries for a prospective policy against a
reliable master address database to ensure that a final list of
all addresses is accurate and, preferably, expressed, in a standard
form before encoding. Such address cleansing may be useful when,
for example, a customer-provided address (e.g., the Plaza Building)
may fail to accurately identify a street address for a particular
business location. Such failure may prevent the GIS operator and/or
other insurance company evaluators from understanding the impact
of underwriting a policy that includes an unrecognized high-risk
business location. For example, if a prospective business address
is incorrect, not corrected through address cleansing, and as a
result placed outside a high risk zone (using the incorrect address),
the policy may be accepted because the related business address
appears to be outside of the high risk area, though in reality it
may actually be inside the high risk area.
[0015] Assuming that a comprehensive list of prospective addresses
has been cleansed and encoded, processes which may consume considerable
time, the GIS operator can begin work. The basic task of the GIS
operator is to display a prospective address location and determine
whether it is in a zone of high risk, such as on the San Andreas
Fault. To do this, the operator selects a prospective address for
display on a GIS application screen and also selects a high risk
zone for display from a database of predefined high risk zones.
Utilizing conventional spatial query techniques, the GIS operator
is able to identify the spatial intersection of the location of
the address and the high risk zone, in relation to the earth, utilizing,
for example, longitude and latitude information. It is now possible
for the operator to determine whether the address's location and
the high risk zone intersect. If the selected address is not in
the selected high risk zone, then there is a relative low risk that
the peril associated with the selected high risk zone will affect
the location being insured (e.g. if the selected address is outside
of the selected high risk zone where, for example, tornadoes, are
historically likely to hit, then the selected address is less likely
of being affected by a tornado) and it may be presumptively accepted
for coverage.
[0016] Alternatively, if the selected address is in the selected
high risk zone, then there may be a higher risk with the business
location at the selected address. The GIS operator may then wish
to identify the existing policies with business locations in the
selected high risk zone, as they represent the current level of
risk for the specified zone (e.g., PML for the specified zone and
peril). For example, if the selected address is located in a predefined
high risk zone including the San Andreas Fault, the GIS operator
may wish to identify the existing policies with locations that have
earthquake coverage in the same high risk zone. The insurance company
may evaluate the propriety of accepting a prospective policy from
such a baseline list, which, as known to those with ordinary skill
in the art, may be evaluated by itself or in conjunction with other
relevant information, such as the added exposure and premium for
the prospective policy.
[0017] However, the GIS operator may also wish to identify existing
policies that are not precisely within the selected high risk zone,
but perhaps within some reasonable proximity to it, as the insurance
company evaluators may wish to consider these policies too in deciding
whether to accept a prospective policy. Thus, the GIS operator may
vary the size and shape of the evaluation zone to consider existing
policies outside but in proximity to a predefined high risk zone.
The GIS operator may experiment in other ways to provide the insurance
company with the best possible list of existing policies (the existing
risk) from which an evaluation can be made as to whether to accept
a prospective policy.
[0018] What is most relevant about the GIS operator's task is that
it generally takes considerable time for the GIS operator to provide
a list of relevant existing policies for the insurance company to
use in considering whether to underwrite a prospective policy. Moreover,
because there are several optional processes both preceding and
coinciding with the GIS operator's task (e.g., whether or not to
use: 1) a comprehensive prospective address list 2) address cleansing,
or 3) any particular GIS operator technique), the evaluation results
may vary widely depending on the selected options and the GIS operator.
[0019] Moreover, even after the GIS operator has analyzed the data,
the insurance company may use this date with predetermined standard
(e.g., will the PML with the prospective policy included exceed
a PML CAP limit that the company may want to stay under, such as
$50 million, for the specified zone and peril, such as earthquake
exposure in a predefined zone including San Francisco) to evaluate
whether to accept a prospective policy. Such evaluation may take
significant time, particularly when, as presently performed, it
involves an insurance company representative manually entering the
GIS operator data into a spreadsheet or an algorithm that embodies
the company's predetermined evaluation standard.
[0020] Moreover, the present process for evaluating whether to
underwrite an insurance policy cannot be completed in real-time.
Consequently, it is not possible for the process described above
to result in a real-time evaluation result being returned to the
user who submitted the evaluation request. Instead, the process
that is followed by insurance companies today either takes days
or weeks to return results to the user who submitted the evaluation
request, or the GIS-based process does not occur at all.
[0021] Thus, there is a need for more efficiently and consistently
evaluating the risk associated with underwriting an insurance policy
in real-time.
BRIEF DESCRIPTION OF THE DRAWINGS
[0022] Referring now to the drawings in which like reference numbers
represent corresponding parts throughout:
[0023] FIG. 1 illustrates a computing environment in which certain
implementations of the invention are implemented.
[0024] FIG. 2 illustrates, in a block diagram, a workflow through
a computing environment in accordance with certain implementations
of the invention.
[0025] FIG. 3 illustrates logic for generating a report for an
insurance policy request in accordance with certain implementations
of the invention.
[0026] FIG. 4A illustrates a landmark, FIG. 4B illustrates risk
rings, and FIG. 4C illustrates logic for identifying risk rings
for a landmark in accordance with certain implementations of the
invention.
[0027] FIG. 5 illustrates an initial screen displayed by an enterprise
spatial system in accordance with certain implementations of the
invention.
[0028] FIG. 6 illustrates a setup screen for events and landmarks
in accordance with certain implementations of the invention.
[0029] FIG. 7 illustrates a setup events screen in accordance with
certain implementations of the invention.
[0030] FIG. 8 illustrates a setup event ring attributes screen
in accordance with certain implementations of the invention.
[0031] FIG. 9 illustrates a setup event damage rates screen in
accordance with certain implementations of the invention.
[0032] FIG. 10 illustrates a setup PML rating details screen in
accordance with certain implementations of the invention.
[0033] FIG. 11 illustrates a setup landmarks screen in accordance
with certain implementations of the invention.
[0034] FIG. 12 illustrates logic for a user interface flow for
an underwriting system 132 in accordance with certain implementations
of the invention.
[0035] FIG. 13 illustrates a screen provided by an underwriting
system for uploading of information from a file in accordance with
certain implementations of the invention.
[0036] FIG. 14 illustrates a screen provided by an underwriting
system for entering address information in accordance with certain
implementations of the invention.
[0037] FIG. 15 illustrates a screen provided by an underwriting
system for mapping fields from a spreadsheet to an enterprise spatial
system format in accordance with certain implementations of the
invention.
[0038] FIG. 16 illustrates a screen provided by an underwriting
system for entering a company name in accordance with certain implementations
of the invention.
[0039] FIG. 17 illustrates a screen provided by an underwriting
system with encoded results in accordance with certain implementations
of the invention.
[0040] FIG. 18 illustrates a screen provided by an underwriting
system for address resolution in accordance with certain implementations
of the invention.
[0041] FIG. 19 illustrates a screen provided by an underwriting
system for address resolution for non-encoded locations in accordance
with certain implementations of the invention.
[0042] FIG. 20 illustrates a screen provided by an underwriting
system for a spatial interface to manually correct a genocide in
accordance with certain implementations of the invention.
[0043] FIG. 21 illustrates a screen provided by an underwriting
system for searching by address in accordance with certain implementations
of the invention.
[0044] FIG. 22 illustrates a screen provided by an underwriting
system for searching by company name in accordance with certain
implementations of the invention.
[0045] FIG. 23 illustrates an ambiguous results screen provided
by an underwriting system in which company name, city, and state
are displayed in accordance with certain implementations of the
invention.
[0046] FIG. 24 illustrates a screen provided by an underwriting
system for searching by policy number for an existing business in
accordance with certain implementations of the invention.
[0047] FIG. 25 illustrates a screen provided by an underwriting
system for quick search by ZIP code in accordance with certain implementations
of the invention.
[0048] FIG. 26 illustrates a screen provided by an underwriting
system for multi-peril rating results in accordance with certain
implementations of the invention.
[0049] FIG. 27 illustrates a screen provided by an underwriting
system for rating result details by location and by peril in accordance
with certain implementations of the invention.
[0050] FIG. 28 illustrates a screen provided by an underwriting
system for exporting rating results to a file in accordance with
certain implementations of the invention.
[0051] FIG. 29 illustrates a screen provided by an underwriting
system for saving results for a temporary period of time in accordance
with certain implementations of the invention.
[0052] FIG. 30 illustrates a screen provided by an underwriting
system displaying selected rating results on a map in accordance
with certain implementations of the invention.
[0053] FIG. 31 illustrates a screen provided by an underwriting
system displaying selected rating results on a map when risk manager
functionality is available in accordance with certain implementations
of the invention.
[0054] FIG. 32A illustrates a location specific PML flow in accordance
with certain implementations of the invention.
[0055] FIG. 32B illustrates a location specific PML flow in accordance
with certain alternative implementations of the invention.
[0056] FIG. 33 illustrates a screen provided by an underwriting
system for location specific PML calculations in accordance with
certain implementations of the invention.
[0057] FIG. 34 illustrates a screen provided by an underwriting
system to provide a summary of locations for individual analysis
in accordance with certain implementations of the invention.
[0058] FIG. 35 illustrates a screen provided by an underwriting
system to provide a summary of location specific PML calculations
in accordance with certain implementations of the invention.
[0059] FIG. 36 illustrates a screen provided by an underwriting
system for displaying location specific PML results in accordance
with certain implementations of the invention.
[0060] FIG. 39 illustrates a screen provided by an underwriting
system for displaying rating results for a user with an external
role in accordance with certain implementations of the invention.
[0061] FIG. 40 illustrates a main approver/reviewer screen provided
by an underwriting system in accordance with certain implementations
of the invention.
[0062] FIG. 41 illustrates a screen provided by an underwriting
system after an approval process is continued from FIG. 40 in accordance
with certain implementations of the invention.
[0063] FIG. 42 illustrates a screen provided by an underwriting
system to allow writing or rejection of a policy in accordance with
certain implementations of the invention.
[0064] FIG. 43 illustrates a screen provided by an underwriting
system with summary report status in accordance with certain implementations
of the invention.
[0065] FIG. 44 illustrates an architecture diagram in accordance
with certain implementations of the invention.
[0066] FIG. 45 illustrates process flow in accordance with certain
implementations of the invention.
[0067] FIG. 46 illustrates an enterprise spatial system schema
and a generic insurance (GI) schema that are provided in accordance
with certain implementations of the invention.
[0068] FIGS. 47A and 47B illustrate logic for proximity analysis
in accordance with certain implementations of the invention.
[0069] FIG. 48 illustrates an insurance solution flow in accordance
with certain implementations of the invention.
[0070] FIG. 49 illustrates a screen showing proximity analysis
with rings at different distances from an epicenter in accordance
with certain implementations of the invention.
[0071] FIG. 50 illustrates proximity analysis process in accordance
with certain implementations of the invention.
[0072] FIG. 51 illustrates a proximity analysis screen in accordance
with certain implantations of the invention.
[0073] FIG. 52 illustrates manual point tools in accordance with
certain implementations of the invention.
[0074] FIG. 53 illustrates a screen showing a sample selection
of an XY coordinate in accordance with certain implementations of
the invention.
[0075] FIG. 54 illustrates an initial proximity analysis screen
for generic proximity analysis in accordance with certain implementations
of the invention.
[0076] FIG. 55 illustrates a second proximity analysis screen for
generic proximity analysis in accordance with certain implementations
of the invention.
[0077] FIG. 56 illustrates a third proximity analysis screen for
generic proximity analysis in accordance with certain implementations
of the invention.
[0078] FIG. 57 illustrates a third proximity analysis screen with
summary options for generic proximity analysis in accordance with
certain implementations of the invention.
[0079] FIG. 58 illustrates a screen provided by the proximity analysis
manager with a proximity analysis full report in accordance with
certain implementations of the invention.
[0080] FIG. 59 illustrates a screen provided by the proximity analysis
manager with a point n' view report in accordance with certain implementations
of the invention.
[0081] FIG. 60 illustrates a screen provided by the proximity analysis
manager with a proximity summary in accordance with certain implementations
of the invention.
[0082] FIG. 61A illustrates a table provided by the proximity analysis
manager of landmark proximity analysis totals in accordance with
certain implementations of the invention.
[0083] FIG. 61B illustrates a table provided by the proximity analysis
manager of proximity aggregates in accordance with certain implementations
of the invention.
[0084] FIG. 62 illustrates a proximity summary provided by the
proximity analysis manager in accordance with certain implementations
of the invention.
[0085] FIG. 63 illustrates a screen of a details report in accordance
with certain implementations of the invention.
[0086] FIG. 64 illustrates an initial screen for an event driven
wizard in accordance with certain implementations of the invention.
[0087] FIG. 65 illustrates a second screen for an event driven
wizard that shows the addition of a landmark option in accordance
with certain implementations of the invention.
[0088] FIG. 66 illustrates a third screen for an event driven wizard
in accordance with certain implementations of the invention.
[0089] FIG. 67 illustrates a proximity summary in accordance with
certain implementations of the invention.
[0090] FIG. 68 illustrates a layer control provided by the proximity
analysis in accordance with certain implementations of the invention.
[0091] FIG. 69 illustrates proximity analysis menus in accordance
with certain implementations of the invention.
[0092] FIG. 70 illustrates a screen provided by the proximity analysis
manager to allow selection of a proximity analysis for editing in
accordance with certain implementations of the invention.
[0093] FIGS. 71A and 71B illustrate screens provided by the proximity
analysis manager to allow deletion of a proximity analysis for editing
in accordance with certain implementations of the invention.
[0094] FIG. 72 illustrates a screen provided by the proximity analysis
manager to save a proximity analysis in accordance with certain
implementations of the invention.
[0095] FIG. 73 illustrates a screen provided by the proximity analysis
manager that allows selection of users for assigning access privileges
in accordance with certain implementations of the invention.
[0096] FIG. 74 illustrates a screen provided by the proximity analysis
manager for Saving To a layer in accordance with certain implementations
of the invention.
[0097] FIG. 75 illustrates a screen provided by the proximity analysis
manager for inputting information for the Save To option in accordance
with certain implementations of the invention.
[0098] FIG. 76 illustrates proximity analysis for an insurance
industry scenario in accordance with certain implementations of
the invention.
[0099] FIG. 77 illustrates customer specific inputs for a formula
for generating PML in accordance with certain implementations of
the invention.
[0100] FIG. 78 illustrates a center point and a selected point
for which a policy may be issued in accordance with certain implementations
of the invention.
[0101] FIG. 79A illustrates a stepped relationship in accordance
with certain implementations of the invention.
[0102] FIG. 79B illustrates a linear relationship in accordance
with certain implementations of the invention.
[0103] FIG. 79C illustrates a logarithmic relationship in accordance
with certain implementations of the invention.
[0104] FIG. 80 illustrates a NAC structure that is used to determine
a NAC in accordance with certain implementations of the invention.
[0105] FIG. 81 illustrates a rating process in accordance with
certain implementations of the invention.
[0106] FIG. 82 illustrates metadata used to implement ring analysis
in accordance with certain implementations of the invention.
[0107] FIG. 83 illustrates metadata to support proximity analysis
functionality for a customer in the insurance business in accordance
with certain implementations of the invention.
[0108] FIG. 84 illustrates a sample handle table 8400 in accordance
with certain implementations of the invention.
[0109] FIG. 85 illustrates a representation of a Handle Manager
class in accordance with certain implementations of the invention.
[0110] FIG. 86 illustrates a sequence diagram that describes the
client and ESS server interaction for proximity image/proximity
summary generation in accordance with certain implementations of
the invention.
[0111] FIG. 87 illustrates an ESS system service context diagram
in accordance with certain implementations of the invention.
[0112] FIG. 88 illustrates a new business approval process in accordance
with certain implementations of the invention.
[0113] FIG. 89 illustrates a policy renewal process in accordance
with certain implementations of the invention.
[0114] FIG. 90 illustrates a process 9000 of an annual in force
book of business review in accordance with certain implementations
of the invention.
[0115] FIG. 91 illustrates an additional data entry process in
accordance with certain implementations of the invention.
[0116] FIG. 92 illustrates an ETL process in accordance with certain
implementations of the invention.
[0117] FIG. 93 illustrates a map view in accordance with certain
implementations of the invention.
[0118] FIG. 94 illustrates a screen with event information, ring
information, and ring weighting in accordance with certain implementations
of the invention.
[0119] FIG. 95 illustrates a portal entry screen in accordance
with certain implementations of the invention.
[0120] FIG. 96 illustrates a portal menu application service site
map in accordance with certain implementations of the invention.
[0121] FIG. 97 illustrates a sample of a Portal Menu application
service main page and subsequent screen flow based on user selections
in accordance with certain implementations of the invention.
[0122] FIG. 98 illustrates a screen of a selected map image with
a map summary in accordance with certain implementations of the
invention.
[0123] FIG. 99 illustrates a screen of a selected map image with
an analysis summary in accordance with certain implementations of
the invention.
[0124] FIG. 100 illustrates a point n' view tool in accordance
with certain implementations of the invention.
[0125] FIG. 101 illustrates a full report screen in accordance
with certain implementations of the invention.
[0126] FIG. 102 illustrates an analysis summary in accordance with
certain implementations of the invention.
[0127] FIG. 103 illustrates a sample network implementation to
connect a client data center and an enterprise spatial system secure
data facility to enable real-time access to ESS system services
in accordance with certain implementations of the invention.
[0128] FIG. 104 illustrates an internet connectivity diagram in
accordance with certain implementations of the invention.
[0129] FIG. 105 illustrates a system architecture in accordance
with certain implementations of the invention.
[0130] FIG. 106 illustrates a table of application services in
accordance with certain implementations of the invention.
[0131] FIG. 107 illustrates a table of portal application service
assignments in accordance with certain implementations of the invention.
[0132] FIG. 108 illustrates a top-level portal site map in accordance
with certain implementations of the invention.
[0133] FIG. 109 illustrates a screen of a set of features available
for the corporate risk manager user in accordance with certain implementations
of the invention.
[0134] FIG. 110 illustrates a screen that shows the reporting menu
page and its associated links in accordance with certain implementations
of the invention.
[0135] FIG. 111 illustrates a screen that shows an ESS admin menu
page and its associated links in accordance with certain implementations
of the invention.
[0136] FIG. 112 illustrates a screen in accordance with certain
implementations of the invention.
[0137] FIG. 113 illustrates a table of data layers in accordance
with certain implementations of the invention.
[0138] FIG. 114 illustrates a table of landmark location fields
in accordance with certain implementations of the invention.
[0139] FIG. 115 illustrates a table of policy location fields in
accordance with certain implementations of the invention.
[0140] FIG. 116 illustrates a ring analysis wizard screen in accordance
with certain implementations of the invention.
[0141] FIG. 117 illustrates screen 2 in accordance with certain
implementations of the invention.
[0142] FIG. 118 illustrates a screen in which the Ring Attributes
section is disabled in accordance with certain implementations of
the invention.
[0143] FIG. 119 illustrates a screen with the expanded Show Options
link in accordance with certain implementations of the invention.
[0144] FIG. 120 illustrates a table of different scenarios that
may be requested by a user in accordance with certain implementations
of the invention.
[0145] FIG. 121 illustrates a ring analysis Results and Summary
screen in accordance with certain implementations of the invention.
[0146] FIG. 122 illustrates a screen in accordance with certain
implementations of the invention.
[0147] FIG. 123 illustrates a screen of a save landmark address
example in accordance with certain implementations of the invention.
[0148] FIG. 124 illustrates a screen of a save landmark latitude/longitude
example in accordance with certain implementations of the invention.
[0149] FIG. 125 illustrates a table of landmark ring analysis totals
in accordance with certain implementations of the invention.
[0150] FIG. 126 illustrates a table of landmark ring analysis by
ring totals in accordance with certain implementations of the invention.
[0151] FIG. 127 illustrates a screen in accordance with certain
implementations of the invention.
[0152] FIG. 128 illustrates an underwriter application service
screen flow in accordance with certain implementations of the invention.
[0153] FIG. 129 illustrates a main underwriter application service
screen, which is a location list screen, in accordance with certain
implementations of the invention.
[0154] FIG. 130 illustrates a table of four combinations of user
data entered for a Find Company Query in accordance with certain
implementations of the invention.
[0155] FIG. 131 illustrates a table of columns for a Company Name
List in accordance with certain implementations of the invention.
[0156] FIG. 132 illustrates a company location search results dialog
in accordance with certain implementations of the invention.
[0157] FIG. 133 illustrates a table of columns for a location Results
List in accordance with certain implementations of the invention.
[0158] FIG. 134 illustrates a encoding process Results dialog that
is used to display results of a encoding process in accordance with
certain implementations of the invention.
[0159] FIG. 135 illustrates a screen displaying location records
in accordance with certain implementations of the invention.
[0160] FIG. 136 illustrates a table describing a data source for
a location list columns in accordance with certain implementations
of the invention.
[0161] FIG. 137 illustrates a table listing columns of data that
may be exported in accordance with certain implementations of the
invention.
[0162] FIG. 138 illustrates a sample CSV file in accordance with
certain implementations of the invention.
[0163] FIG. 139 illustrates a reporting application service screen
flow in accordance with certain implementations of the invention.
[0164] FIG. 140 illustrates a total book of business by landmark
report in accordance with certain implementations of the invention.
[0165] FIG. 141 illustrates a new business by landmark report in
accordance with certain implementations of the invention.
[0166] FIG. 142 illustrates a new business by landmark report in
accordance with certain implementations of the invention.
[0167] FIG. 143 illustrates a table of columns for a policy detail
in accordance with certain implementations of the invention.
[0168] FIG. 144 illustrates an admin application service custom
screen flow in accordance with certain implementations of the invention.
[0169] FIG. 145 illustrates a screen for setting up landmarks in
accordance with certain implementations of the invention.
[0170] FIGS. 146 and 147 illustrate a screen for setting up events
in accordance with certain implementations of the invention.
[0171] FIG. 148 illustrates an admin application service business
table screen flow in accordance with certain implementations of
the invention.
[0172] FIG. 149 illustrates an admin application service ESS delegated
screen flow in accordance with certain implementations of the invention.
[0173] FIG. 150 illustrates a table for policy data access rights
in accordance with certain implementations of the invention.
[0174] FIG. 151 illustrates a primary table in accordance with
certain implementations of the invention.
[0175] FIG. 152 illustrates a table of views of a client data store
in accordance with certain implementations of the invention.
[0176] FIG. 153 illustrates a table of physical and logical layers
in accordance with certain implementations of the invention.
[0177] FIG. 154 illustrates a ETL process in accordance with certain
implementations of the invention.
[0178] FIG. 155 illustrates a data integration services flow in
accordance with certain implementations of the invention.
[0179] FIGS. 156A and 156B illustrate administration scenarios
1 and 2 in accordance with certain implementations of the invention.
[0180] FIGS. 157A, 157B, and 157C illustrate data integration services
scenario 3 in accordance with certain implementations of the invention.
[0181] FIGS. 158A, 158B, and 158C illustrate another data integration
services scenario in accordance with certain implementations of
the invention.
[0182] FIG. 159 illustrates screen with a list of existing known
data sources for a given customer in accordance with certain implementations
of the invention.
[0183] FIG. 160 illustrates a screen with an example of a possible
treatment for how to add a new data source in accordance with certain
implementations of the invention.
[0184] FIG. 161 illustrates a preference menu in accordance with
certain implementations of the invention.
[0185] FIG. 162 illustrates a screen with a list of data sources
available to a give data admin in accordance with certain implementations
of the invention.
[0186] FIG. 163 illustrates an example of a screen used for a batch
type data source in accordance with certain implementations of the
invention.
[0187] FIG. 164 illustrates an example of a screen used for a transaction
type data source.
[0188] FIG. 165 illustrates a screen with advanced edit menus in
accordance with certain implementations of the invention.
[0189] FIG. 166 illustrates a table of editing extension points
in accordance with certain implementations of the invention.
[0190] FIG. 167 illustrates how overlapping polygons may be modified
in different ways in accordance with certain implementations of
the invention.
[0191] FIGS. 168A and 168B illustrate objects split by selection
and/or intersection in accordance with certain implementations of
the invention.
[0192] FIG. 169 illustrates objects to be split by a drawn line
in accordance with certain implementations of the invention.
[0193] FIG. 170 illustrates multi-polygons in accordance with certain
implementations of the invention.
[0194] FIG. 171 illustrates examples of shapes that cannot be represented
by a single multi-polygon in accordance with certain implementations
of the invention.
[0195] FIG. 172 illustrates a screen for shaded area thematic mapping
in accordance with certain implementations of the invention.
[0196] FIG. 173 illustrates a screen for sized symbols thematic
mapping in accordance with certain implementations of the invention.
[0197] FIG. 174 illustrates a screen for shaded symbols thematic
mapping in accordance with certain implementations of the invention.
[0198] FIG. 175 illustrates an architecture of a computer system
that may be used in accordance with certain implementations of the
invention.
DETAILED DESCRIPTION
[0199] In the following description, reference is made to the accompanying
drawings which form a part hereof and which illustrate several implementations
of the present invention. It is understood that other implementations
may be utilized and structural and operational changes may be made
without departing from the scope of implementations of the present
invention.
A. OVERVIEW
[0200] Certain implementations of the invention enable a more efficient
and consistent evaluation of whether an insurance company should
underwrite an insurance policy. Moreover, certain implementations
of the invention may utilize conventional geospatial query techniques
to provide in real-time, rather than in days or weeks, the results
of the evaluation back to a user who submitted the request for evaluation.
To this end, certain implementations of the invention may permit
a user to submit existing or prospective customer data, such as
a company name and address, and promptly receive an evaluation report
recommending acceptance or denial of the request for insurance coverage,
or requesting the user to contact the insurance company for further
consideration of a prospective policy. Unlike past practice, certain
implementations of the invention provide an automated technique
to more efficiently and consistently evaluate existing or prospective
customer data provided by the user and report back to the user an
appropriate answer (e.g., the policy may be accepted, denied, or
further consideration is merited) in real time, such as a matter
of seconds as opposed to days or weeks.
[0201] Certain implementations of the invention also enable an
insurance company to define high risk zones, based on a selected
landmark (a landmark may be a specified point, such as a predefined
point of a building or structure, or a specified area, such as a
flood zone). The user may also define and select a perilous event
for the landmark, such as an explosion, a fire, a release of hazardous
material, a flood, etc. For the selected landmark and perilous event,
the user may also define zones in proximity to the landmark that
have variable user-defined loss factors. Such user-defined high
risk zones, including associated perils and loss factors, may be
added to a data store for use in evaluation whether an insurance
company should underwrite an additional insurance policy that may
involve covering locations in a specified high risk zone for a specified
peril. Such data may be made available to a user of a client application
connected to a continuously-running server without having to shut
down the server, and without requiring the user to log onto the
server again to gain access to newly-entered high risk zones (and
their associated perils and loss factors) for real-time evaluations.
[0202] FIG. 1 illustrates a computing environment in which certain
implementations of the invention are implemented. A client computer
100 is connected via a network 190 to a server computer 120. The
client computer 100 may comprise any computing device known in the
art, such as a server, mainframe, workstation, personal computer,
hand held computer, laptop telephony device, network appliance,
etc.
[0203] The network 190 may comprise any type of network, such as,
for example, a Storage Area Network (SAN), a Local Area Network
(LAN), Wide Area Network (WAN), the Internet, an Intranet, etc.
The client computer 100 includes system memory 104, which may be
implemented in volatile and/or non-volatile devices. One or more
client applications 110 may execute in the system memory 104. Additionally,
user interfaces 112 may be displayed by components of the enterprise
spatial system 130 at server computer 1200.
[0204] The server computer 1200 includes system memory 122, which
may be implemented in volatile and/or non-volatile devices. An enterprise
spatial system 130 executes in the system memory 122. In certain
implementations of the invention, the enterprise spatial system
130 includes an underwriting system 132, a risk manager 134 that
includes a proximity analysis manager 136, a spatial editor 138,
and data integration services 140 (also referred to as Extraction,
Transformation, and Loading (ETL)). Additional components and/or
services 142 may also be provided by the enterprise spatial system
130 (e.g., those depicted in FIG. 2)
[0205] Although components 132, 136, 134, 138, and 140 are illustrated
as separate components within an enterprise spatial system 130,
the functionality of the components 132, 136, 134, 138, and 140
may be implemented in fewer or more or different components than
illustrated. Additionally, the functionality of the components 132,
136, 134, 138, and 140 may be implemented at a Web application server
computer or other server computer that is connected to the server
computer 1200. Additionally, one or more server applications 160
may execute in system memory 122.
[0206] The server computer 1200 provides the client computer 100
with access to data in one or more data stores 170 (e.g., data stores).
Although data store 170 is illustrated as directly connected to
server computer 1200, tables 150 and other data (e.g., the locations
for an insurance company's existing policies and other policy details)
in data store 170 may be stored in data stores at other computers
connected to server computer 1200. Although tables 150 are referred
to herein for ease of understanding, other types of structures may
be used to hold the data that is described as being stored in tables
150.
[0207] Also, an operator console 180 executes one or more applications
182 and is used to access the server computer 1200 and the data
store 170.
[0208] The data store 170 may comprise an array of storage devices,
such as Direct Access Storage Devices (DASDs), Just a Bunch of Disks
(JBOD), Redundant Array of Independent Disks (RAID), virtualization
device, etc.
[0209] FIG. 2 illustrates, in a block diagram, workflow through
a computing environment in accordance with certain implementations
of the invention. FIG. 2 represents a system data work flow diagram
for simultaneously integrating enterprise data with third party
data using a processing center and a live data center, processing
spatially referenced data, and providing access to the data.
[0210] FIG. 2 illustrates several additional components of an enterprise
spatial system provided by certain implementations of the invention,
including (1) a Geographical Information System (GIS) processing
center/operations center 210, (2) a data center 220, (3) a fulfillment
center 230, (4) enterprise integration 240 (which may be part of
the data center 220), and (5) client software 250 (e.g., one or
more client applications). The client software 250 executes on a
client system 252, which has a display screen on which a UI screen
or other data may be displayed for viewing by, for example, a user.
Although, one client system 252 is illustrated, it is to be understood
that many client systems may access data in the production center
222 at any time, including other server systems acting as clients
to the enterprise spatial system. Certain implementations of the
invention provide a 24/7 live system that integrates and offers
on-demand data (e.g., superior quality geographical imagery, associated
industry or enterprise specific data, such as, sales information),
and analysis tools to enterprises, government, industry, and the
general public.
[0211] Prior to implementations of the invention, conventional
systems provided no interactive GIS tools for users to access dynamic
enterprise data at run time and integrate third party data hosted
by a data center. That is, with implementations of the invention,
users may access the GIS processing center/operations center 210,
which processes data (e.g., converting Tagged Image File Format
(TIFF) to Joint Photographic Expert Group (JPEG) format) at run
time, and makes the processed data available at run time to users
without disrupting the data center 220 operations.
[0212] Referring to FIG. 2, enterprise data sources 202, government/Freedom
of Information (FOI) public data 204, and satellite imagery data
206 is input to the GIS processing center/operations center 210
in the form of vector data, tabular data, third party imagery, and/or
raw tiled TIFF imagery. Although not shown, other types of data
may also be input into the enterprise spatial system. In certain
implementations, the satellite imagery data 206 is obtained using
airplanes flying over areas and taking photographs with cameras
that provide high resolution images. The data is stored in an interim
archive tape library 212. As a part of processing data, the GIS
processing center 214 retrieves data from the interim archive tape
library and forwards the data to pre-production processing 216.
Ultimately, the data is stored in the production center 222 for
client software 250 access.
[0213] The GIS processing center/operations center 210 handles
many different operations in pre-production processing 216 due to
irregularities in GIS data from various sources. For example, the
GIS Processing Center performs data compression (e.g., of image
data) at run time during the data transformation stage. Compressing
data is important because some data (e.g., GIS image data) cannot
be accessed over the Internet due to the size of the data. For example,
some image data is in a graphical data format called TIFF. TIFF,
as understood by those skilled in the art, is a tag-based image
file format that is designed to promote the interchange of digital
image data. TIFF provides a multi-purpose data format and is compatible
with a wide range of scanners and image-processing applications.
It is device independent and is used in most operating environments,
including Windows.RTM., Macintosh.RTM., and UNIX.RTM.. TIFF is one
of the most popular and flexible of the current public domain raster
file formats. To be able to use GIS image data that may be transferred
over the Internet, implementations of the invention convert large
image data to a compressed data format, such as JPEG. There are
many reasons for using the JPEG file format. JPEG permits a greater
degree of compression than other image formats, such as TIFF, enabling
quicker downloading times for larger graphics. Furthermore, JPEG
documents appear to retain almost complete image quality for most
photographs.
[0214] There are several important stages in data processing at
the GIS processing center 214. The following demonstrate four of
the different stages and functions of each stage: (a) data acquisition
stage; (b) data extraction stage; (c) data transformation state;
and, (d) GIS product inventory creation stage. The data acquisition
state procures data from various sources (e.g., enterprise data
202, government/FOI public data 204, and satellite imagery data
206). Data acquisition is an important function of the GIS processing
center 214. In the data extraction stage, data is staged for use,
the data integrity is verified, and data quality control is provided.
In the data transformation stage, the following actions occur on
data: color fusion, histograms, matching, misaiming, re-sampling,
tiling, and compression, which are well known in the art. In the
GIS product inventory creation stage, the following actions occur:
metadata is created for the data layers, different data layers are
described using metadata, data (e.g., vector, raster or tabular
data) is stored in spatial data store, and GIS data is uploaded
to the data center 220 for deployment.
[0215] The data center 220 includes a staging system 221. Data
from the staging system 221 is sent to the production center 222.
Data from the staging system 221 may also be stored at a master
archive tape library 223 and sent to offsite storage 224. The staging
system 221 provides a replica of the production center 222 and is
used to test the client software, enterprise spatial system software
(e.g., server software at servers in the enterprise spatial system),
and data. The staging system 221 is used to ensure that a new version
of client software and/or data will work correctly when deployed
to the production center 222. The production center 222 is used
to store data accessed by users via client software 250.
[0216] The data center 220 supports many operations. For example,
the data center 220 hosts raster data, vector data, and tabular
data for users to access using various client software 250 (e.g.,
client applications such as, a browser client, a thin client, or
an enterprise client). Various techniques of accessing data (e.g.,
tabular data of sales information) from an enterprise data store
and geocoding non-spatially referenced data are supported. In particular,
although geocoding may be performed in the GIS processing center/operations
center 210, the data center 220 also supports functions that require
geocoding in the production center 222. The data center 220 also
manages network communications between enterprise users and the
data center 220. The data center 220 supports linear scalability
to be able to expand the enterprise spatial system provided by implementations
of the invention to handle larger data sets (i.e., larger amounts
of data) at run time.
[0217] The data center 220 provides security and access controls
to enterprise users to securely access their enterprise data, allows
enterprise users to simultaneously access dynamic data from their
enterprise data store 202 and the data center 220, and processes
requests from, for example, client applications by supporting client
applications' functionality. The data center 220 also supports different
types of analytical functions, such as querying for data, generating
data reports, retrieving data layers, accessing data, and sharing
and/or collaborating with multiple users.
[0218] The fulfillment center 230 receives orders for data (e.g.,
particular data, a particular image or a set of images), prepares
the data (e.g., creates or collects the appropriate data), and delivers
the data to a requested location. Further details of order fulfillment
are provided below.
[0219] Enterprise integration 240 allows users to access securely
their enterprise data that is stored outside of the data center
220. Enterprise integration 240 also determines whether enterprise
data are pre-geocoded or not, and, if the enterprise data is not
pre-geocoded, the enterprise data is parsed and geocoding information
is provided by determining the proper longitude and latitude information
to be associated with the enterprise data elements (e.g., records).
The enterprise integration technology 240 also provides the ability
to interact with and retrieve data from third party applications
using various Application Programming Interfaces (API) exposed by
the third party applications and makes the data available to the
client systems of the data center 220. The enterprise integration
technology 240 also provides various Application Programming Interfaces
(API) to third party applications so that different third party
applications, including enterprise applications, can access production
data from the data center 220. The APIs provide defined function
calls to third party applications so that users can interact with
the enterprise spatial system provided by implementations of the
invention to utilize stored data (e.g., raster data, vector data,
and tabular data) for spatially analyzing enterprise data. In addition
to accessing data, the APIs also allow third party applications
to utilize the various analysis functions provided by the enterprise
spatial system.
[0220] The client software 250 (e.g., client applications) allows
users to manipulate spatial data interactively by making dynamic
data requests from the data center 220. The client software 250
includes, for example, browser-based clients, thin clients, thick
clients, and enterprise clients. The client software 250 handles
all user actions promptly and retrieves spatial data from the data
center 220 in a timely manner. To achieve this goal, the client
software 250 and the data center 220 rely on using a multiple data
layering mechanism. That is, unlike legacy GIS software, the data
center 220 does not combine multiple data layers as one composite
image when transmitting spatial data to users over a network. Instead,
the data center 220 retrieves proper spatial data layers from various
data stores based on client requests and converts the data layers
to individual images. Then, rather than combining multiple spatial
data layers as one raster file or vector file (e.g., JPEG, ASCII
Extensible Markup Language (XML) or other forms of binary file),
the data center 220 sends the images separately to the client software
250. The client software caches the images for the different spatial
data layers to avoid generating new image files every time users
change back and forth between different spatial data layers. The
client software may combine multiple images to form a composite
image that is displayed to a user.
[0221] Thus, the enterprise spatial system includes components
illustrated in FIG. 1 as well as components illustrated in FIG.
2. The components illustrated in FIG. 2 are used to provide interactive
maps for use by the components illustrated in FIG. 1.
[0222] FIG. 3 illustrates logic for generating a report for an
insurance policy request in accordance with certain implementations
of the invention. At block 320, an insurance agent may receive a
request for an insurance policy for coverage against terrorism and/or
some other peril. The agent may also receive existing or prospective
customer data for the desired policy such as: 1) the name and address
of the entity seeking coverage (e.g. an individual or a company
name and the address of the property to be covered); 2) the requested
coverage type (e.g., property insurance for a loss resulting from
a terrorist attack and/or some other peril); and 3) the desired
amount of coverage, deductible and premium. The request and the
existing or prospective customer data may be submitted to the insurance
agent, or any other insurance company representative, using any
conventional means.
[0223] At block 322, the insurance company representative, such
as the underwriter, using the request and the existing or prospective
customer data reported in block 320, may activate a conventional
Web browser or any other client application on client computer 100
to access server computer 120 and build a comprehensive address
list.
[0224] To build a comprehensive address list, the representative
may enter on client computer 100 one or more addresses that were
provided. Additionally, the representative may enter on client computer
100 a search query consisting of an estimated spelling for the entity
(e.g., in case the correct spelling is unknown to the representative).
Server computer 120 may then access one or more commercially available
data stores 170, such as, the U.S. Marketing File data store from
Dun & Bradstreet, to return for display on client computer 100
a list of entity names that begin with the representative's search
query. Using client computer 100, the representative may then select
the correct entity. If the insurance company representative knows
the correct entity name, then such an entity name search may be
skipped.
[0225] When the representative enters or selects an entity name,
the representative may be prompted to select search criteria for
a data store search for related entities. The representative may
select from search criteria including: 1) whether to search for
related entities (e.g., subsidiaries, affiliates, and the like for
the entity; presumably, for an individual entity, as opposed to
a business entity, no such search would be desired); and 2) if a
related entity search is requested, whether any geographical, or
other, restrictions apply.
[0226] The representative may enter on client computer 100 the
search criteria, and server computer 120 may access one or more
commercially available data stores 170, such as the U.S. Marketing
File data store from Dum & Bradstreet, and employ a conventional
search routine to identify the sought-after entities in data store
170. Server computer 120 may then obtain the sought-after entities
located in the entity-name-based search of data store 170.
[0227] The representative may also enter on client computer 100
additional relevant addresses not originally provided by the existing
or prospective customer or located in the entity-name-based search.
For example, data store 170 employed for the entity-name-based search
may not be up to date to include the latest business locations for
a given entity.
[0228] Thus, at block 322 a comprehensive address list may be built
for the existing or prospective customer, which may include: 1)
addresses originally provided by the existing or prospective customer;
2) addresses found in the entity-name-based search, such as related
entities; and 3) any other addresses for entities that are related
to the existing or prospective customer but not found in the entity-name-based
search.
[0229] At block 322, the representative may also enter on client
computer 100 any remaining existing or prospective customer data
for the desired policy such as: 1) the requested coverage type (e.g.,
property insurance for a loss resulting from a terrorist attack
and/or some other peril); 2) the desired amount of coverage, deductible,
and premium; and 3) any other information that the insurance company
wants to consider in evaluating whether to underwrite the requested
insurance policy.
[0230] At block 324, server computer 120 cleanses the addresses
in the comprehensive address list by executing any well-known address
cleansing process, such as the common address matching technology
of the Address Broker software from Sagent, Inc. of Mountain View,
Calif. In executing the address cleaning process, server computer
120 may compare the addresses in the comprehensive address list
with addresses in a reliable master address data store 170, such
as the USPS Address Matching address data store from the U.S. Postal
Service. From the comparison, server computer 120 may correct addresses
in the comprehensive address list that were incorrect prior to the
address cleansing.
[0231] Alternatively, data store 170 that may be utilized with
block 322 to build a comprehensive address list may be "precleansed."
Specifically, an address cleansing process, such as described in
block 324, may be performed on the addresses in data store 170 that
may be utilized in block 322 to build a comprehensive address list.
The address cleansing of data store 170 may be performed before
a user employs system 10. Consequently, run-time address cleansing,
such as block 324, may be skipped.
[0232] At block 326, server computer 120 geocodes the addresses
in the comprehensive address list by executing any well-known geocoding
process, such as that performed by Address Broker from Sagent Technology,
Inc. of Mountain View, Calif. As those skilled in the art appreciate,
the geocoding process may associate with each address in the comprehensive
address list a unique geographic identifier, such as a latitude
and a longitude value. As such, each address location may be evaluated
with any spatial query techniques well-known to those skilled in
the GIS arts to determine the address's location relative to any
other geocoded data sets (e.g., whether a geocoded address location
intersects with a geocoded high risk zone).
[0233] Alternatively, data store 170 that may be utilized with
block 322 to build a comprehensive address list may be "pregeocoded."
Specifically, a geocoding process, such as described in block 326,
may be performed on the addresses in data store 170 that may be
utilized in block 322 to build a comprehensive address list. The
geocoding of data store 170 may be performed before a user employs
system 10. Consequently, run-time geocoding, such as block 326,
may be skipped.
[0234] At block 328, server computer 120 may select an address
(now cleansed and geocoded) from the comprehensive address list.
The list may include a single address, if, for example, the existing
or prospective customer requested coverage for a single location.
Alternatively, the list may include several addresses, if the existing
or prospective customer requested coverage of a number of locations.
In the latter case, server computer 120 may select one or more addresses
at a time from the comprehensive address list for processing, as
discussed below in blocks 332-340.
[0235] At block 330, server computer 120 may retrieve the requested
coverage type (e.g., property insurance, including coverage for
a loss resulting from a tornado) previously entered at block 320.
Utilizing any well-known spatial query techniques, server computer
120 may then access data store 170, which may contain predefined
high risk zones. Each predefined high risk zone may be associated
with a predetermined peril (e.g., a tornado) and a predetermined
zone where the perilous event has a specified probability of occurring
(e.g., specified counties in the Midwestern United States known
as Tornado Alley), as known to those skilled in the art. Moreover,
a predetermined high risk zone may cover one or more geographically
discrete areas for the predetermined peril. For example, there may
be a predetermined tornado risk zone that coves only Tornado Alley,
and there may be another predetermined tornado risk zone that covers
not only Tornado Alley, but other statistically-relevant tornado
risk areas in the United States. Data store 170 may also include
one or more predefined high risk zones for terrorism-based perils.
FIG. 4C illustrates logic for building high risk zones for such
terrorism-based and other perils. Moreover, in certain implementations,
block 330 is not limited to selecting a single predefined high risk
zone; multiple high risk zones may be selected for evaluation.
[0236] Those skilled in the art understand that it may be necessary
for server computer 120 to be conventionally programmed to query
data store 170 using any well-known spatial query techniques to
retrieve, for example: 1) high risk zones; 2) any specific area
within a high risk zone (such as an area with an elevated loss factor
due to, for example, historical data indicating elevated risk);
and 3) existing policies within a high risk zone that may also contain
the same spatial coordinates as one or more of the address(3s) selected
in block 328. Those skilled in the art also understand that it may
be necessary to geocode the high risk zones and the locations for
the existing policies either prior to the processing of block 330
or during the processing of block 330.
[0237] Server computer 120 may select a predefined high risk zone
that matches the requested coverage type. For example, if the requested
coverage type was for storm damage anywhere in the United States,
server computer 120 may retrieve a predefined high risk zone for
tornadoes in the United States.
[0238] Utilizing any well-known spatial query techniques at block
332, server computer 120 may compare one or more selected addresses
with the selected high risk zone to determine whether any prospective
address location(s) are within the selected high risk zone. Geocoding
of the addresses and the high risk zones may facilitate this comparison.
Moreover, the matching process of block 332 may alternatively consider
a modification of a selected high risk zone (e.g. it may be expanded
by some predefined quantity to encompass nearby locations that may
not otherwise be in the zone or it may be reduced by some predefined
quantity to encompass fewer locations than would otherwise be in
the zone).
[0239] If there is only one prospective address and the prospective
address is not within the selected high risk zone, at block 334
a report may be made indicating to the insurance company representative
that underwriting the insurance policy is acceptable (because the
prospective address is not in the selected high risk zone). Alternatively,
if the prospective address is within the selected high risk zone,
then at block 336 server computer 120 may utilize any well-known
spatial query techniques to retrieve from data store 170 the existing
policies and associated covered locations that are also located
within the selected high risk zone. Those skilled in the art understand
that it may be necessary for server computer 120 to be conventionally
programmed to query data store 170 using any well-known spatial
query techniques to identify the high risk zones that include the
longitude and latitude values for one or more selected address(es)
of the submitted policy, as well as to identify all the existing
policies and associated covered locations whose longitude and latitude
values are also within the identified high risk zones.
[0240] At block 338, server computer 120 may make an evaluation
using any predetermined insurance company standard. For example,
server computer 120 and/or data store 170 may be conventionally
programmed to determine a revised PML (including the new policy)
and whether the revised PML exceeds a predetermined PML limit. If
the PML limit is not exceeded, at block 340 a report may be sent
back to client computer 100 to the insurance company representative
to indicate that the new policy may be issued. Alternatively, if
the PML limit is exceeded, at block 340 a report may be sent back
to client computer 100 to indicate to the insurance company representative
that the new policy may not be issued or that further information
may be considered before the policy may be accepted. However, those
skilled in the art appreciate that the predetermined insurance company
standard for the evaluation of block 338 is not limited to the example
described above (whether the revised PML exceeds a predefined PML
limit). Those skilled in the art understand that server computer
120 may be conventionally programmed to make an evaluation of whether
to underwrite a policy using any predetermined standard desired
by the insurance company.
[0241] Alternatively, if there is more than one prospective address
and none of them are within the selected high risk zone, at block
334 a report may be made to the insurance company representative
to indicate that underwriting the insurance policy is acceptable.
However, if any of the prospective addresses are within the selected
high risk zone, then at block 336 server computer 120 may retrieve
from data store 170 those policies that are also located within
the selected high risk zone. A report may also be made to indicate
to the insurance company representative that underwriting the insurance
policy is acceptable for the prospective addresses that are not
within the selected high risk zone.
[0242] At block 338, server computer 120 may make an evaluation
using any predetermined insurance company standard. For example,
server computer 120 may be conventionally programmed to determine
a revised PML and whether the revised PML exceeds a predetermined
PML limit. In determining a revised PML, server computer 120 may
consider prospective addresses in the high risk region either individually
or in one or more groups. Assuming single-address consideration,
if the PML limit is not exceeded for the considered address, at
block 340 a report may be sent back to client computer 100 to indicate
to the insurance company representative that the new policy may
be issued for that address location. Alternatively, if the PML limit
is exceeded for the single address location, at block 340 a report
may be sent back to client computer 100 to indicate to the insurance
company representative that the location may not be covered by the
policy or that further information may be considered before the
policy may be accepted. Thus, a policy for multiple addresses may
be accepted for some locations and not accepted for others (e.g.,
if a single branch office of a multi-branch bank is deemed to be
too high or a risk to insure, it may be excluded from the policy
covering the other branch offices for the particular business).
[0243] FIG. 4A illustrates a landmark, FIG. 4B illustrates risk
rings, and FIG. 4C illustrates logic for identifying risk rings
for a landmark in accordance with certain implementations of the
invention. With this method, an insurance company representative
may use a Web browser on client computer 100 to custom design a
high risk zone, such as a perceived terrorist target. The custom-designed
high risk zone may then be stored in data store 170 for use with
the method described for FIG. 3.
[0244] Referring to the flowchart of FIG. 4C, the user at block
450 identifies a landmark 446, which is shown by way of example
in FIG. 4A. FIG. 4A represents a map display 442 that may show on
client computer 100 a user-selected image 444 that may include landmark
446, which may correspond to a high risk zone, such as a perceived
terrorist target.
[0245] To identify landmark 446 at block 450, the user may enter
on client computer 100 the address for landmark 446, which is reported
to server computer 120 for display on client computer 100. Alternatively,
using a mouse, the user may point to user-selected image 444, zoom
into an appropriate resolution (to show landmarks, such as buildings),
and select with the mouse the desired landmark 446.
[0246] At block 452, the address for the identified landmark may
be conventionally cleansed as discussed above with reference to
block 424 in the method of FIG. 3.
[0247] At block 454, the user may identify on client computer 100
a perilous event, such as specified type of terrorist attack on
landmark 446 (e.g., a conventional bomb with specified characteristics,
a biological weapon with specified characteristics, a chemical weapon
with specified characteristics, etc.). Server computer 120 may have
a number of such perilous events predefined for the user to select
with client computer 100. Additionally, the user may enter with
client computer 100 any desired perilous event and define its characteristics,
as desired.
[0248] At block 456, the user may identify on client computer 100
risk rings for the selected landmark 446, as depicted in FIG. 4B.
Each risk ring 448a-448d represents an area in proximity to the
landmark 446. The user may select for each risk ring 448a-448d an
expected loss factor. Thus, for one type of perilous event (e.g.,
a conventional bomb of specified strength), the user can enter a
loss factor for each risk ring 448a-448d based on the expected damage
for the selected perilous event. For example, a user may expect
a 2,000 pound conventional bomb to destroy 90 percent of the value
of the property within risk ring 448a, 80 percent of the value of
the property within risk ring 448b, etc. Block 456 may permit the
user to create on client computer 100 specified loss profiles for
a specified perilous event, as well as to edit existing high risk
zones. Risk rings 448a-448d need not be circular, as shown in FIG.
4B, and may take any desired shape.
[0249] At block 458, the high risk zone identified in blocks 450-556
is conventionally geocoded and stored at block 460 in data store
170 for use with the logic of FIG. 3.
[0250] Once a new high risk zone has been created with its related
perilous event and loss factors, it may be stored on data store
170 for immediate use in evaluating insurance policies, as described
by the logic of FIG. 3. Moreover, server computer 120 does not need
to be shut down and restarted and client computer 100 does not need
to be interrupted in any way before the new high risk zones may
be accessed for such evaluation. This allows insurance companies
to dynamically and in real-time add, change, or delete additional
high risk zones, peril events and loss factors without having to
shut down system 10 and interrupt the method of real-time insurance
policy evaluation of FIG. 3.
B. INSURANCE UNDERWRITING AND RISK MANAGEMENT
[0251] Insurance underwriting is a dynamic business that requires
intimate knowledge of the book of business and company-specified
thresholds for accumulated risk based on natural and manmade perils.
A peril may be described as a specific risk or cause of loss covered
by an insurance policy. In general, underwriting is the process
of insuring someone for something. An underwriter's primary responsibility
is to produce, underwrite, and quote new and renewal business for
their company. Being location aware is an integral component of
underwriting. A location may be described as a physical location
that may be tied to a policy. By having immediate knowledge of policyholders'
locations and their proximity to catastrophe zones or targets allows
underwriters to distribute risk.
[0252] With services provided by the underwriting system 132, the
guesswork is taken out of the equation when underwriting insurance.
Underwriters are provided with access to real-time location assessment
and prospect approval workflow with the underwriter system. Starting
with an address, the underwriting system 132 is a sophisticated
underwriting service that allows users to quickly and easily input
location information and determine whether to write, investigate
or not write policies based on, for example, peril, coverage type
(i.e., a type of insurance policy) or line of business. The underwriting
system 132 provides several techniques to input location or policy
details and quickly determine whether the location is in proximity
to perils and appropriately set or adjust pricing premiums. A premium
may be described as an amount the policyholder pays for insurance
coverage. To have a clear understanding of impact on current book
of business, the underwriting system 132 provides company specific
ratings and exposes location verification, audit, and assessment
prior to writing, renewing or terminating business.
[0253] The underwriting system 132 provides an easy to use technique
for rating new business against perils, such as terrorist events.
In order to accommodate the workflow of underwriters who are working
with multiple lines of business and multiple perils, the underwriter
system provides underwriters with an interactive process to determine
whether to write, renew or reject business.
[0254] The underwriting system 132 provides several interactive
techniques for inputting prospective policyholder details, including
the ability to upload records from a file, input an individual address,
and search by company. The underwriting system 132 allows underwriters
to input policy details and save prospective information for a company-specified
period of time. Underwriters are provided with the ability to perform
peril-specific queries to determine whether prospective policies
are in man made, natural catastrophe, or company-specified peril
zones. A peril zone may be described as a specific peril territory
that is defined by, for example, a point, a line, or a polygon.
The underwriting system 132 includes natural catastrophe zone data
for several catastrophes, such as terrorism, hail, wind, flood,
hurricane, and earthquake.
[0255] The underwriting system 132 interacts with the geocoding
service available in the enterprise spatial system in both interactive
and batch modes prior to rating locations. Location ratings are
driven b |