U.S. patent application number 14/068617 was filed with the patent office on 2014-02-27 for processing and optimizing travel insurance transactions.
This patent application is currently assigned to American International Group, Inc.. The applicant listed for this patent is American International Group, Inc.. Invention is credited to Robert Azuma, Jeff Schafer, Ellison Scudder, John Selle.
Application Number | 20140058765 14/068617 |
Document ID | / |
Family ID | 45807579 |
Filed Date | 2014-02-27 |
United States Patent
Application |
20140058765 |
Kind Code |
A1 |
Scudder; Ellison ; et
al. |
February 27, 2014 |
Processing and Optimizing Travel Insurance Transactions
Abstract
A method and system are provided for processing communications
between travel service providers and travel insurers where travel
service providers use different messaging formats. A travel service
provider transmits itinerary data to a travel insurer in one
messaging format. The travel insurer may then convert the itinerary
data into a format compatible with the travel insurer's system and
determine an optimal policy choice based on the itinerary data. The
travel insurer may then transmit this choice to the travel service
provider in the travel service provider's preferred messaging
format, and the travel service provider offers the product to the
consumer through the travel service provider's interface.
Inventors: |
Scudder; Ellison; (New York,
NY) ; Selle; John; (Cedar Grove, NJ) ; Azuma;
Robert; (Parsippany, NJ) ; Schafer; Jeff;
(Jersey City, NJ) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
American International Group, Inc. |
New York |
NY |
US |
|
|
Assignee: |
American International Group,
Inc.
New York
NY
|
Family ID: |
45807579 |
Appl. No.: |
14/068617 |
Filed: |
October 31, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13231535 |
Sep 13, 2011 |
8577767 |
|
|
14068617 |
|
|
|
|
61382418 |
Sep 13, 2010 |
|
|
|
Current U.S.
Class: |
705/4 |
Current CPC
Class: |
G06Q 10/10 20130101;
G06Q 40/08 20130101; G06Q 50/14 20130101; G06Q 30/0241
20130101 |
Class at
Publication: |
705/4 |
International
Class: |
G06Q 40/08 20060101
G06Q040/08 |
Claims
1-20. (canceled)
21. A method for processing transactions involving a travel insurer
and a travel service provider, comprising: receiving, by a travel
insurer computing device, itinerary data in a travel service
provider messaging format generated by the travel service provider;
converting, by the travel insurer computing device, the itinerary
data in the travel service provider messaging format to itinerary
data in a travel insurer messaging format based on a mapping of the
travel service provider messaging format to the travel insurer
messaging format, wherein the mapping is one of a plurality of
mappings between messaging formats associated with travel service
providers and the travel insurer messaging format; determining, by
the travel insurer computing device, a travel insurance policy
based on the itinerary data in the travel insurer messaging format;
and transmitting, by the travel insurer computing device,
information pertaining to the determined travel insurance policy to
a customer computing device for presentation to a customer of the
travel service provider.
22. The method of claim 21, wherein the information pertaining to
the determined travel insurance policy is presented to the customer
on the customer computing device via a user interface associated
with the travel service provider.
23. The method of claim 21, wherein the travel insurer messaging
format is a messaging format compatible with a rating and issuance
engine of the travel insurer, and wherein the determining utilizes
the rating and issuance engine.
24. The method of claim 21, wherein the travel service provider
messaging format is one of the group consisting of: XML, HTML, and
delimited text.
25. The method of claim 21, further comprising: converting the
information pertaining to the determined travel insurance policy
into a messaging format compatible with the travel service provider
before the transmitting.
26. The method of claim 21, further comprising: receiving, from the
customer computing device, a customer response corresponding to the
determined travel insurance policy, wherein the customer response
includes payment information; and converting, by the travel insurer
computing device, the customer response including payment
information into a corresponding travel insurer messaging
format.
27. The method of claim 21, further comprising: selecting an
advertisement for presentation to the consumer based on the
itinerary data; and transmitting the selected advertisement or an
indication of the selected advertisement to the customer computing
device for presentation of the selected advertisement to the
customer.
28. A non-transitory computer-readable medium, part of a travel
insurer computing system, having processor-executable instructions
stored thereon for processing transactions involving a travel
insurer and a travel service provider, the processor-executable
instructions including instructions for: receiving itinerary data
in a travel service provider messaging format generated by the
travel service provider; converting the itinerary data in the
travel service provider messaging format to itinerary data in a
travel insurer messaging format based on a mapping of the travel
service provider messaging format to the travel insurer messaging
format, wherein the mapping is one of a plurality of mappings
between messaging formats associated with travel service providers
and the travel insurer messaging format; determining a travel
insurance policy based on the itinerary data in the travel insurer
messaging format; and transmitting information pertaining to the
determined travel insurance policy to a customer computing device
for presentation to a customer of the travel service provider.
29. The non-transitory computer-readable medium of claim 28,
wherein the information pertaining to the determined travel
insurance policy is presented to the customer on the customer
computing device via a user interface associated with the travel
service provider.
30. The non-transitory computer-readable medium of claim 28,
wherein the travel insurer messaging format is a messaging format
compatible with a rating and issuance engine of the travel insurer,
and wherein the determining utilizes the rating and issuance
engine.
31. The non-transitory computer-readable medium of claim 28,
wherein the travel service provider messaging format is one of the
group consisting of: XML, HTML, and delimited text.
32. The non-transitory computer-readable medium of claim 28, the
processor-executable instructions further comprising instructions
for: converting the information pertaining to the determined travel
insurance policy into a messaging format compatible with the travel
service provider before the transmitting.
33. The non-transitory computer-readable medium of claim 28, the
processor-executable instructions further comprising instructions
for: receiving, from the customer computing device, a customer
response corresponding to the determined travel insurance policy,
wherein the customer response includes payment information; and
converting the customer response including payment information into
a corresponding travel insurer messaging format.
34. The non-transitory computer-readable medium of claim 28, the
processor-executable instructions further comprising instructions
for: selecting an advertisement for presentation to the consumer
based on the itinerary data; and transmitting the selected
advertisement or an indication of the selected advertisement to the
customer computing device for presentation of the selected
advertisement to the customer.
35. A travel insurer computing system for processing transactions
involving a travel insurer and a travel service provider,
comprising: a travel insurer server, configured to: receive
itinerary data in a travel service provider messaging format
generated by the travel service provider; convert the itinerary
data in the travel service provider messaging format to itinerary
data in a travel insurer messaging format based on a mapping of the
travel service provider messaging format to the travel insurer
messaging format, wherein the mapping is one of a plurality of
mappings between messaging formats associated with travel service
providers and the travel insurer messaging format; determine a
travel insurance policy based on the itinerary data in the travel
insurer messaging format; and transmit information pertaining to
the determined travel insurance policy to a customer computing
device for presentation to a customer of the travel service
provider; and a database, configured to store the plurality of
mappings between messaging formats associated with travel service
providers and the travel insurer messaging format.
36. The travel insurer computing system of claim 35, wherein the
travel insurer messaging format is a messaging format compatible
with a rating and issuance engine of the travel insurer, and
wherein to determine the travel insurance policy, the travel
insurer server is configured to execute the rating and issuance
engine.
37. The travel insurer computing system of claim 35, wherein the
travel service provider messaging format is one of the group
consisting of: XML, HTML, and delimited text.
38. The travel insurer computing system of claim 35, wherein the
travel insurer server is further configured to: convert the
information pertaining to the determined travel insurance policy
into a messaging format compatible with the travel service provider
before the transmitting.
39. The travel insurer computing system of claim 35, wherein the
travel insurer server is further configured to: receive, from the
customer computing device, a customer response corresponding to the
determined travel insurance policy, wherein the customer response
includes payment information; and convert the customer response
including payment information into a corresponding travel insurer
messaging format.
40. The travel insurer computing system of claim 35, wherein the
travel insurer server is further configured to: select an
advertisement for presentation to the consumer based on the
itinerary data; and transmit the selected advertisement or an
indication of the selected advertisement to the customer computing
device for presentation of the selected advertisement to the
customer.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This patent application is a continuation of U.S. patent
application Ser. No. 13/231,535, filed on Sep. 13, 2011, which will
issue as U.S. Pat. No. 8,577,767 on Nov. 5, 2013. This patent
application claims the benefit of U.S. Provisional Patent
Application No. 61/382,418, filed on Sep. 13, 2010.
FIELD
[0002] The present invention relates generally to data processing
and relates more particularly to processing communications between
travel service providers and travel insurers.
BACKGROUND
[0003] Retail sellers often partner with other types of retail
sellers to provide consumers with a convenient forum from which
they can have multiple product needs met. For example, travel
insurance companies often partner with travel service providers
(airlines, hotels, on-line travel agencies, etc.) for the
integration of travel insurance into the "booking path" of the
travel purchase. When a consumer purchases an airline ticket on an
airline's website, an offer is made to the consumer for travel
insurance. If the offer is accepted, a policy is issued. In this
example, the airline's booking system interacts with the travel
insurer's system, typically via XML messaging, to quote and bind
the insurance policy as part of a seamless consumer experience.
[0004] The travel insurer may require travel service providers
(e.g., the airline) to undergo an extensive and time-consuming
integration process whereby they "code to" the travel insurer's XML
specification. Additionally, the travel service providers are
required to develop the logic on their systems whereby they
communicate to the travel insurer which product will be sold on a
particular transaction to a particular consumer. The travel insurer
may provide the business logic for these product choices, but the
burden typically falls on the travel service provider to develop
the technical logic to support it.
[0005] For example, an airline or other travel service provider's
website must determine which product is appropriate for the
consumer and then request a quote using the travel insurer's
proprietary XML specification. Because the business logic is
implemented on the travel service provider's website, the travel
insurer simply responds by providing a quote to the travel service
provider, rather than verifying the travel service provider's
product choice or providing alternative or more optimal options.
This arrangement between the travel service provider and the travel
insurer limits the capability of the travel insurer to provide
flexible and up-to-date product choices available to the consumers.
This arrangement can also result in errors due to the lack of
verification by the travel insurer.
[0006] It will be appreciated that the inventors have created the
above body of information for the convenience of the reader. The
foregoing is a discussion of problems discovered and/or appreciated
by the inventors, and is not an attempt to review or catalog the
prior art.
SUMMARY
[0007] The described invention allows for the processing of
different data formats that contains the business data needed to
sell a product without requiring a partner to code to a specific
standard. A preferred embodiment of the invention has applicability
in quoting and binding travel insurance. A travel service provider
may send relevant itinerary data to the travel insurer utilizing
the travel service provider's pre-existing or preferred format, and
the travel insurer determines which product is appropriate for the
itinerary and responds to the travel service provider in the travel
service provider's pre-existing or preferred format. In contrast to
conventional systems, travel service providers are not restricted
to using a particular XML format specified by the travel insurers,
so the travel service providers are free to use whichever data
format is more convenient to them (including XML, HTML, or simple
text delimited files). Furthermore, an optimal policy determination
is performed at the travel insurer's system to allow the travel
insurer to provide better and more up-to-date policy options based
on the itinerary data, as well as allowing the travel insurer to
verify that the correct policy option or options are being offered
to the consumer based on the itinerary data.
[0008] In a general embodiment, a partner sends transaction data to
a seller in the partner's preferred format, and if the partner's
preferred format is incompatible with the seller's preferred
format, the data needed is extracted and converted to the seller's
preferred format by an XML processor. The particular conversion
code for each partner's preferred format may be advantageously
loaded into the XML processor's memory cache for increased speed
and security.
[0009] The seller may then apply the seller's product selection
logic to the transaction data to determine an optimal product or
products based on the transaction data. Because the product
selection logic is being implemented on the seller's system, the
seller is able to formulate a variety of options suited
specifically to a particular consumer's needs. The seller can
verify that the product selected is appropriate for the consumer,
the seller can provide alternative product choices, and the seller
has flexibility in freely changing its product selection
algorithms. Thus, the seller can account for additional
consumer-specific variables and rapidly adapt to changing market
conditions.
[0010] After determining an optimal product or products, the
seller's system may utilize an XML processor or other appropriate
processors to convert the optimal product or products data into the
partner's preferred format, and the message may then be transmitted
to the partner. The partner displays the product choice or choices
on its website, and the consumer receives an optimal product offer
or offers based on the seller's recommendations. The seller may
additionally include advertisements or promotional material in
combination with the product offer or offers displayed on the
partner's website.
[0011] In a preferred embodiment described with further detail
herein, the seller is a travel insurer and the partner is a travel
service provider, and the travel insurer's product offerings are
integrated into the interface that the travel service provider
presents to consumers purchasing the travel service provider's
products.
[0012] As will be appreciated by the teachings herein, the present
invention allows partners to utilize whichever format for data
storage and transmission that they prefer, as well as allowing
sellers to offer optimized product choices and change product
options with greatly reduced technical support from partners. Other
objects and advantages of the invention will become apparent upon
reading the following detailed description and upon reference to
the drawings.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)
[0013] FIG. 1 is a diagram illustrating the components of a travel
insurer's data processing system in one exemplary embodiment;
[0014] FIG. 2 is a flowchart illustrating the processing of
itinerary data received from a travel service provider at a travel
insurer system in one exemplary embodiment; and
[0015] FIG. 3 is a flowchart illustrating the processing a customer
response received from a travel service provider at a travel
insurer system in one exemplary embodiment.
DETAILED DESCRIPTION
[0016] While the invention is described below in the context of a
preferred embodiment involving a travel insurer as a "seller" and a
travel service provider as a "partner," it will be appreciated that
the inventive principles disclosed with respect to the preferred
embodiment are more broadly applicable to other seller-partner
relationships.
[0017] FIG. 1 provides an exemplary system architecture 100 of a
travel insurer's system and its connection to a travel service
provider's system. A computer or server 102 of the travel service
provider's system is connected to a network 110 (e.g., the
Internet). It will be appreciated that the travel service
provider's system may be more complex and include more components
(e.g. databases, application servers, firewalls, etc.), but for
simplicity of illustration only a computer or server 102 is
depicted.
[0018] The travel insurer's system 120 is also connected to the
network 110 and protected by a firewall 121. Messages received
through the network 110 are processed by a conventional load
balancer 122 (for distributing workload corresponding to entities
accessing the travel insurer's system) and one or more XML
processors 123, which parse received messages to extract data and
re-format the messages (to a format compatible with the travel
insurer's proprietary rating and issuance engine residing on
application servers 124) if needed. Preferably, a pool of multiple
XML processors 123 may be used. In one embodiment, the XML
processors may be DataPower XI50s manufactured by IBM, of Armonk,
N.Y.
[0019] The travel insurer's system 120 further includes application
servers 124, through which the travel insurer's proprietary rating
and issuance engine may process message data to determine an
appropriate policy. These application servers 124 may access data
from database servers 126 within the travel insurer's system 120,
and the connection between the application servers 124 and the
database servers 126 may be protected by another firewall 125.
[0020] It will be appreciated the travel insurer's system 120 need
not be implemented in the manner depicted and that one of ordinary
skill in the art would be able to vary the system design and still
practice the inventive principles described herein. For example,
various components of the travel insurer's system 120 may be
interconnected without firewalls, or the travel insurer's system
may additionally include a web server (depending on how the travel
service provider's user interface is configured). It will further
be appreciated that, in other embodiments, the various components
described herein (e.g. the load balancers, XML processors, and
application servers) may be implemented by other types of hardware,
such as a general computing unit with appropriate programming.
[0021] It will further be appreciated by those of skill in the art
that the execution of the various machine-implemented processes and
steps described herein may occur via the computerized execution of
computer-executable instructions stored on a tangible
computer-readable medium, e.g., RAM, ROM, PROM, volatile,
nonvolatile, or other electronic memory mechanism. Thus, for
example, the operations performed by the travel insurer's
proprietary rating and issuance engine may be carried out according
to instructions or applications stored at the application servers
124.
[0022] Given the exemplary system architecture depicted by FIG. 1,
a general process 200 for receiving and processing itinerary data
from a travel service provider (TSP) at the travel insurer's system
120 is depicted by FIG. 2. In one embodiment, the travel insurer's
system 120 receives itinerary data corresponding to one or more
consumers from a travel service provider's system 101, and the
itinerary data is formatted using the travel service provider's
preferred format, which may be, for example, XML, HTML, or simple
delimited text (201). A component of the travel insurer's system
120, such as the load balancer 122, XML processors 123, or
application servers 124, then determines whether the itinerary data
is in a format that is compatible with the travel insurer's rating
and issuance engine (203). If it is not compatible, the XML
processors 123 convert the received itinerary data into a format
that is compatible with the travel insurer's rating and issuance
engine (205), and the rating and issuance engine, implemented on
the applications servers 125 and accessing information from
database servers 127, determines one or more optimal policy options
based on the itinerary data (207). If the received itinerary data
is already compatible with the travel insurer's rating and issuance
engine, no conversion is necessary.
[0023] If the optimal policy data determined by the travel
insurer's rating and issuance engine is not in a format compatible
with the travel service provider's system 101 (209), the optimal
policy data is converted into a format that is compatible with the
travel service provider's system 101 (211). The reformatted optimal
policy data is then transmitted to the travel service provider's
system 101 for presentation to a consumer using the travel service
provider's system 101 (213). If the optimal policy data determined
by the travel insurer's rating and issuance engine is already in a
format compatible with the travel service provider's system 101
(209), no conversion is necessary before transmission to the travel
service provider's system 101 (213). In a preferred embodiment, the
offer to purchase travel insurance is presented to the consumer
through the travel service provider's interface in order to
integrate the purchase of travel insurance with the consumer's
purchase of the travel services provided by the travel service
provider.
[0024] It will be appreciated that the determination of one or more
optimal policy options by the travel insurer's rating and issuance
engine may be based on parameters including, but not limited to,
the itinerary type (one way or round trip), the type of consumer
(individual or multiple travelers), the trip duration, the category
of destination, the trip cost (insured or policy level), the
consumer's frequent flier status, and the type of package (air only
or package deal). To perform the determination of the one or more
optimal policy options, the rating and issuance engine on the
application servers may query the database for underwriting data
and risk factor data such as itinerary-specific (e.g., based on
date, length of trip, region(s) being visited, etc.) costs relating
to lost luggage, medical expenses, and/or trip cancellations. The
rating and issuance engine then applies one or more policy
calculation algorithms to the itinerary data and risk factor data
to generate optimal policy data, which is transmitted to the travel
service provider and may include parameters such as plan choice(s),
price(s) and coverage(s). It will further be appreciated that more
than one optimal policy option may be included in the optimal
policy data and transmitted to the travel service provider's system
101 for presentation to the consumer. For example, it may be
advantageous to provide the consumer with multiple travel insurance
options based on their itinerary data in the event that one or the
other is more appealing to the consumer (e.g., a less expensive
plan including only cancellation coverage and a more expensive plan
including coverage for both medical expenses and cancellation). In
addition, the system and method of an embodiment of the invention
may use a consumer-indicated preference or factor to be optimized
to determine an appropriate policy to be quoted (e.g., the consumer
may indicate that he or she wants comprehensive medical coverage
but only minimal cancellation and lost luggage coverage).
[0025] In a further embodiment, advertisements and/or promotions
may be transmitted to the travel service provider's system 101 for
presentation to the consumer in addition to the one or more optimal
policy options and/or prices (215). Such advertisements and/or
promotions may be specifically targeted to the consumer based on
the itinerary data. For example, these advertisements may stress
the need for insurance based on the consumer's travel plans
("Protect yourselves from travel delays caused by the holiday
rush!") or promote special discounted rates for specific types of
consumers ("Get an additional 10% Off! Exclusively for our Gold
Members"). To accomplish this variation, application servers 124
work in conjunction with database servers 126 to identify potential
insurable risks, special circumstances, or other considerations.
For example, if the itinerary data indicates that the consumer is
going to travel to a hurricane-prone area during hurricane-prone
season, the ratings and issuance engine, working with the database
servers 126, may identify that the risk for cancellation and/or
medical expenses is especially high and automatically generate
corresponding advertisements and optimal policy options taking
those considerations into account.
[0026] Turning now to FIG. 3, in a preferred embodiment, a consumer
may respond to the travel insurer's offer to sell a policy through
the travel service provider's interface (301). This response may
indicate whether the consumer wishes to purchase the policy or not,
and, in the event that the consumer wishes to purchase the policy,
may further provide payment information (such as desired payment
method and any necessary details). It will be appreciated that a
lack of response for a predeteimined length of time (e.g. a
timeout) may also indicate to the travel insurer system 120 that
the consumer does not wish to purchase the policy. It will further
be appreciated that other methods of responding to the offer may be
utilized as well, such as, for example, providing a link to the
consumer to access a travel insurer's web interface directly.
[0027] The travel insurer's system 120 may determine whether data
corresponding to a consumer response is in a format compatible with
the travel insurer's system 120 (303), and if it is not, may use
one or more XML processors 123 to convert the consumer response
data into a format compatible with the travel insurer's system 120
(305). The application servers 124 may then process the consumer
response data (307), which may include processing the payment
information (e.g. charging a credit card using credit card
information provided by the consumer) and storing transaction
information at the database servers 126 (e.g. storing transaction
details or logging successful and unsuccessful policy offers or
promotion offers). If the consumer response data was already in a
format compatible with the travel insurer's system 120 to begin
with, no conversion may be necessary.
[0028] It will be appreciated that further communications may take
place between the travel insurer system 120 and the travel service
provider system 101. For example, the travel insurer system 120 may
transmit a transaction confirmation (e.g. including a policy
number, payment details, a message stating that the transaction was
completed, etc.) back to the travel service provider system 101,
performing format conversion if necessary according to the
procedures described above.
[0029] In order to transform a message from a travel service
provider's preferred format that is not compatible with the travel
insurer's proprietary rating and issuance engine into a format that
is compatible with the travel insurer's proprietary rating and
issuance engine, the travel insurer may first verify that the
travel service provider is capturing the data that the travel
insurer desires from the consumer. This may be performed by, for
example, giving the travel service provider a checklist as depicted
in Table 1 below to ensure that data used by the rating and
issuance engine is being collected. It will be appreciated that
Table 1 is merely exemplary and that more or less (or different)
data fields may be used.
TABLE-US-00001 TABLE 1 Data Collection Checklist CUSTOMER
INFORMATION Customer Last Name Customer First Name Customer Address
Phone number email Country of Residence Date of Birth Age Passenger
Type (e.g., Infant/Child/Adult/Senior) Customer Status (e.g., FF
level - gold, platinum, etc.) Number of insureds/passengers on trip
Customer ID (e.g., Passport number) TRIP INFORMATION One
Way/RoundTrip Indicator Origin (IATA airport code) Trip Begin Date
Trip End Date Destination (IATA airport code) - (must be Furthest
Destination) PNR/Record Locator (e.g., ABC123) Trip Cost by
Individual Payment Details (Cash, Credit Card, Miles . . . etc) If
yes, please provide details Class of Service (First/Business/Coach)
Fare Basis Code (e.g., YM, K14NYC) Booking Class of Service (e.g,
F, Y, K, Q, K, N, X) Carrier/Provider Name (e.g., United, American,
NCL, Marriott) Airline Only versus Package Indicator Total Trip
Cost
If not all the data desired by the travel insurer is being
collected, the travel service provider may be asked to adjust their
interface so as to collect that data, or the travel insurer may
modify its rating and issuance engine to work with the data
presently collected for that travel service provider in particular
(or some combination thereof).
[0030] Assuming the travel service provider's data is collected in
a messaging format that is not compatible with the travel insurer's
rating and issuance engine, the travel insurer may then map the
data in the travel service provider's format to corresponding data
fields in the format compatible with the rating and issuance engine
(e.g. identifying where a customer's name is, where a customer
address is, and where trip information is in the travel service
provider's format). For example, in one embodiment, assume that the
travel service provider uses an XML message format (not compatible
with the travel insurer's rating and issuance engine) and that a
sample data record corresponding to a customer's itinerary is
provided by Table 2 below.
TABLE-US-00002 TABLE 2 Sample XML Message <?xml
version="1.0"?> <flight> <customer_info>
<first_name>John</first_name>
<last_name>Doe</last_name> <address>123 123rd
Street, Los Angeles, CA 12345</address>
<phone>123-456-7890</phone>
<email>john_doe@hotmail.com</email>
<country>USA</country>
<date_of_birth>01.01.1978</date_of_birth>
<age>32</age> <type>Adult</type>
<status>Platinum</status>
<number_insured>1</number_insured>
<passport>123456789</passport> </customer_info>
<trip_data> <provider>XYZ Airlines</provider>
<round_trip>Yes</round_trip>
<origin>SYD</origin>
<departure_date>08.26.2010</departure_date>
<return_date>09.05.2010</return_date>
<destination>LAX</destination>
<flight_no>815</flight_no>
<payment>Cash</payment>
<fare_basis>YM</fare_basis>
<booking_class>F</booking_class>
<package>Yes</package> </trip_data>
</flight>
[0031] A mapping code may be created using commercially available
XML processing tools such as the Altova MapForce data mapping tool
and the Altova XMLSpy XML editor (developed by Altova of Beverly,
Mass.) and may be implemented in the memory cache of the XML
processor. Using eXtensible Stylesheet Language Transformations
(XSLT), the travel service provider's message containing the
desired consumer data in the travel service provider's preferred
messaging format is manipulated to generate a new message in a
format compatible with the travel insurer's rating and issuance
engine. It will be appreciated that a different mapping may be used
for each unique data messaging format used by a plurality of
providers. One example illustrating an excerpt of several lines of
mapping code used to transform the travel service provider's
preferred XML format to a format compatible with the travel
insurer's rating and issuance engine is given by Table 3 below.
TABLE-US-00003 TABLE 3 Sample Mapping Code <?xml version="1.0"
encoding="UTF-8"?> <!-- This file was generated by Altova
MapForce 2009sp1 Refer to the Altova MapForce Documentation for
further details. http://www.altova.com/mapforce -->
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
exclude-result-prefixes="xs xsi xsl"> <xsl:output
method="xml" encoding="UTF-8" indent="yes"/> <xsl:template
match="/"> <TINS_XML_DATA> <xsl:attribute
name="xsi:noNamespaceSchemaLocation"> <xsl:value-of
select=`"C:/Datapower/DA8DB2~1/StandardOffering/WaatsLite/Group1Input.xsd`-
"/> </xsl:attribute> <xsl:variable name="var1_instance"
select="."/> <Segment> <TransactionType>
<xsl:copy-of
select="$var1_instance/TravelGuardInsuranceRQ/Transaction/TransactionCode"-
/> </TransactionType> <TransactionId>
<xsl:copy-of
select="$var1_instance/TravelGuardInsuranceRQ/Transaction/TransactionCode"-
/> </TransactionType>
[0032] The message generated by the XML processor in the format
that is compatible with the travel insurer's rating and issuance
engine will then be processed by the rating and issuance engine. An
exemplary set of data parameters that may be used by a rating and
issuance engine in one embodiment is given by Table 4 below.
TABLE-US-00004 TABLE 4 Sample Data Parameters Used by Rating and
Issuance Engine Data Parameters Sample Values GDS_CD AAA
ORIGIN_IATA_CNTRY_CD 41 ORIGIN_IATA_AIRPORT_CD ALL
FREQUENT_FLYER_STATUS NONE DEST_CONTINENT_CD AS DEST_IATA_CNTRY_CD
41 DEST_IATA_AIRPORT_CD ALL TRIP_TYPE ALL ISO_CURRENCY_CD ALL
WAATS_IATA_AGENCY_CD 99999999 WAATS_AGENCY_PCC_CD 99999
WAATS_PRODUCT_CD 20971 WAATS_PLAN_CD ONE WAATS_BENEFIT_CD 0
RECORD_EFF_DT 6/14/2010 11:05:32 AM RECORD_EXP_DT 6/14/2030
11:05:32 AM SOURCE_SYSTEM_ID WT USERID_CD WAATS TIMESTAMP 9/2/2010
10:33:15 AM
[0033] Having received an XML message corresponding to itinerary
data in a format compatible with the rating and issuance engine
containing the data parameters used by the rating and issuance
engine, the rating and issuance engine processes the data and
outputs a message corresponding to an optimal policy or policies
based on the itinerary data. An example of the policy data output
by the rating and issuance engine in an XML format compatible with
the rating and issuance engine is given in Table 5 below.
TABLE-US-00005 TABLE 5 Sample Policy Output
<TINS_XML_DATA><Header><ErrorCode>0</ErrorCode><-
;ErrorMessage>OK</Err
orMessage><Version>1.0</Version><SourceId>AUS</Sou-
rceId><MessageId>6AUSq
3caYz8DBnw0nS2O9Em735K</MessageId></Header><Segment><-
IgnoreFg></Ignor
eFg><ErrorCode>0</ErrorCode><ErrorMessage></ErrorM-
essage><TransactionType>
NSell</TransactionType><TransactionId></TransactionId>&l-
t;PolicyIn><GDSCode>AU
S</GDSCode><AgencyPCC>CallCentre</AgencyPCC><AgencyCo-
de>60000089</A
gencyCode><IATACntryCd>6</IATACntryCd><TransactionType&g-
t;NSell</Transactio
nType><GDSProductCode>020960</GDSProductCode><InceptionD-
ate>06/03/2010 12:00:00
AM</InceptionDate><ExpirationDate>06/10/2010 11:59:00
PM</ExpirationDate><PaymentType>0</PaymentType><Total-
NumberOfInsureds>1<
/TotalNumberOfInsureds><Address></Address><PolicyType>-
;0</PolicyType><Gener
alPurpose2>WebSiteUser</GeneralPurpose2><TransactionApplDate&g-
t;10/27/2009 01:33:43
PM</TransactionApplDate><InsuranceType>IND</InsuranceType&g-
t;<TransactionEffD ate>06/03/2010 12:00:00
AM</TransactionEffDate><TransactionExpDate>06/l0/2010
11:59:00 PM</TransactionExpDate>
[0034] Subsequently, as described above, this policy output may be
converted back to a format preferred by the travel service provider
if necessary, and further communications between the travel service
provider and travel insurer may take place based on the user's
response to the travel insurance offer.
[0035] Thus, it will be appreciated that a new and useful method
and system for sellers to provide flexible product options to
consumers integrated into partners' sites while requiring minimal
technical integration effort by the partners has been invented.
However, it will also be appreciated that the disclosed embodiments
are merely examples, and that the described principles are more
widely applicable. All references, including publications, patent
applications, and patents, cited herein are hereby incorporated by
reference to the same extent as if each reference were individually
and specifically indicated to be incorporated by reference and were
set forth in its entirety herein.
[0036] The use of the terms "a" and "an" and "the" and similar
referents in the context of describing the invention (especially in
the context of the following claims) are to be construed to cover
both the singular and the plural, unless otherwise indicated herein
or clearly contradicted by context. The terms "comprising,"
"having," "including," and "containing" are to be construed as
open-ended terms (i.e., meaning "including, but not limited to,")
unless otherwise noted. Recitation of ranges of values herein are
merely intended to serve as a shorthand method of referring
individually to each separate value falling within the range,
unless otherwise indicated herein, and each separate value is
incorporated into the specification as if it were individually
recited herein. All methods described herein can be performed in
any suitable order unless otherwise indicated herein or otherwise
clearly contradicted by context. The use of any and all examples,
or exemplary language (e.g., "such as") provided herein, is
intended merely to better illuminate the invention and does not
pose a limitation on the scope of the invention unless otherwise
claimed. No language in the specification should be construed as
indicating any non-claimed element as essential to the practice of
the invention.
[0037] Preferred embodiments of this invention are described
herein, including the best mode known to the inventors for carrying
out the invention. Variations of those preferred embodiments may
become apparent to those of ordinary skill in the art upon reading
the foregoing description. The inventors expect skilled artisans to
employ such variations as appropriate, and the inventors intend for
the invention to be practiced otherwise than as specifically
described herein. Accordingly, this invention includes all
modifications and equivalents of the subject matter recited in the
claims appended hereto as permitted by applicable law. Moreover,
any combination of the above-described elements in all possible
variations thereof is encompassed by the invention unless otherwise
indicated herein or otherwise clearly contradicted by context.
* * * * *
References