WO2023128871A2

WO2023128871A2 - Method and device for setting a premium for an insurance of a transport task

Info

Publication number: WO2023128871A2
Application number: PCT/SG2022/050936
Authority: WO
Inventors: Wei Ming Melvin LEE; Harshit Gupta
Original assignee: Gshield Asia Pte. Ltd.
Priority date: 2021-12-27
Filing date: 2022-12-27
Publication date: 2023-07-06
Also published as: WO2023128871A3

Abstract

Aspects concern a method for setting a premium for an insurance of a transport task, comprising recording, for each of a plurality of transport tasks that have been performed, a delivery time necessary to perform the transport task and information about weather conditions when performing the transport task, determining a correlation between weather and delivery time from the recorded delivery times and the recorded weather conditions, determining, for a transport task, a route for performing the transport task and acquiring, from one or more sensors, measurement data about a weather condition along the determined route for the transport task and setting a premium for an insurance against delayed delivery for the transport task according to the weather condition and the determined correlation between weather and delivery time.

Description

METHOD AND DEVICE FOR SETTING A PREMIUM FOR AN INSURANCE OF A TRANSPORT TASK

TECHNICAL FIELD

[0001] Various aspects of this disclosure relate to methods and devices for setting a premium for an insurance of a transport task.

BACKGROUND

[0002] In addition to providing a transport service, an operator of a transport system may offer insurances against delayed delivery (of persons, parcels, food, etc.). For example, if food is delivered late, a user may be provided with a food voucher provided that the user has a corresponding insurance. Since compensating the user in accordance with the insurance (like giving a food voucher to the user) involves costs for the transport system provider the user is typically charged a premium. However, depending on the risk that the user needs to be compensated, the premium may be too low (thus leading to loss for the transport system provider) or too high (thus making the insurance uninteresting for the user). Accordingly, approaches for suitably setting a premium for an insurance against delayed delivery are desirable.

SUMMARY

[0003] Various embodiments concern a method for setting a premium for an insurance of a transport task, comprising recording, for each of a plurality of transport tasks that have been performed, a delivery time necessary to perform the transport task and information about weather conditions when performing the transport task, determining a correlation between weather and delivery time from the recorded delivery times and the recorded weather conditions, determining, for a transport task, a route for performing the transport task and acquiring, from one or more sensors, measurement data about a weather condition along the determined route and setting a premium for an insurance against delayed delivery for the transport task according to the weather condition and the determined correlation between weather and delivery time. [0004] According to one embodiment, setting the premium comprises calculating a dynamic adjustment from the weather condition and the determined correlation between weather and delivery time and setting the premium to a pre-determined flat premium adjusted by the dynamic adjustment.

[0005] According to one embodiment, the dynamic adjustment specifies a percentage by which the flat premium is to be changed.

[0006] According to one embodiment, the method further comprises determining a time when the transport task is to be performed, estimating traffic conditions for the determined time and setting the premium for the insurance further depending on the estimated traffic conditions.

[0007] According to one embodiment, the method comprises determining a traffic score from the estimated traffic conditions, a weather score from the weather condition and the determined correlation between weather and delivery time and setting the premium for the insurance depending on a weighted sum of the weather score and the traffic score.

[0008] According to one embodiment, estimating the traffic conditions comprises dividing a route of the transport task into route segments and estimating traffic conditions of each road segment depending on the determined time.

[0009] According to one embodiment, estimating traffic conditions comprises determining, from previous transport tasks, a correlation between traffic condition and time and estimating the traffic conditions from the determined time and the determined correlation between traffic condition and time.

[0010] According to one embodiment, the method comprises determining a customer segment to which a customer of the transport task belongs and setting the premium further depending on the customer segment.

[0011] According to one embodiment, the transport task is a transport of one or more persons, fresh food or one or more parcels.

[0012] According to one embodiment, a server is provided configured to perform the method of one of the embodiments described above.

[0013] According to one embodiment, a computer program element is provided including program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method of one of the embodiments described above. [0014] According to one embodiment, a computer-readable medium is provided including program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method of one of the embodiments described above.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The invention will be better understood with reference to the detailed description when considered in conjunction with the non-limiting examples and the accompanying drawings, in which:

FIG. 1 shows a communication arrangement for usage of an e-hailing service including a smartphone and a server.

FIG. 2 shows an architecture for setting of a premium for an insurance, for example implemented by the server.

FIG. 3 illustrates a process flowchart for setting of a premium for an insurance, for example implemented by the server.

FIG. 4 shows a flow diagram illustrating a method for setting a premium for an insurance of a transport task.

FIG. 5 shows a transport system management server according to an embodiment.

DETAILED DESCRIPTION

[0016] The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure. Other embodiments may be utilized and structural, and logical changes may be made without departing from the scope of the disclosure. The various embodiments are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.

[0017] Embodiments described in the context of one of the devices or methods are analogously valid for the other devices or methods. Similarly, embodiments described in the context of a device are analogously valid for a vehicle or a method, and vice-versa.

[0018] Features that are described in the context of an embodiment may correspondingly be applicable to the same or similar features in the other embodiments. Features that are described in the context of an embodiment may correspondingly be applicable to the other embodiments, even if not explicitly described in these other embodiments. Furthermore, additions and/or combinations and/or alternatives as described for a feature in the context of an embodiment may correspondingly be applicable to the same or similar feature in the other embodiments.

[0019] In the context of various embodiments, the articles “a”, “an” and “the” as used with regard to a feature or element include a reference to one or more of the features or elements.

[0020] As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.

[0021] In the following, embodiments will be described in detail.

[0022] An e-hailing app, typically used on a smartphone, allows its user to hail a taxi (or also a private driver) through his or her smartphone for a trip.

[0023] FIG. 1 shows a communication arrangement including a smartphone 100 and a server (computer) 106.

[0024] The smartphone 100 has a screen showing the graphical user interface (GUI) of an e- hailing app that the smartphone’s user has previously installed on his smartphone and has opened (i.e. started) to e-hail a ride (taxi or private driver).

[0025] The GUI 101 includes a map 102 of the vicinity of the user’s position (which the app may determine based on a location service, e.g. a GPS-based location service). Further, the GUI 101 includes a box for point of departure 103 (which may be set to the user’s present location obtained from the location service) and a box for destination 104 which the user may touch to enter a destination (e.g. opening a list of possible destinations). There may also be a menu (not shown) allowing the user to select various options, e.g. how to pay (cash, credit card, credit balance of the e-hailing service). When the user has selected a destination and made any necessary option selections, he or she may touch a “find car” button 105 to initiate searching of a suitable car.

[0026] For this, the e-hailing app communicates with the server 106 of the e-hailing service via a radio connection. The server 106 may consult a memory 109 or a data storage 108 having information about the current location of registered vehicles 111, about when they are expected to be free, about traffic jams etc. From this, a processor 110 of the server 106 selects the most suitable vehicle (if available, i.e. if the request can be fulfilled) and provides an estimate of the time when the driver will be there to pick up the user, a price of the ride and how long it will take to get to the destination. The server communicates this back to the smartphone 100 and the smartphone 100 displays this information on the GUI 101. The user may then accept (i.e. book) by touching a corresponding button. If the user accepts, the server 106 informs the selected vehicle 111 (or, equivalently, its driver), i.e. the vehicle the server 106 has allocated for fulfilling the transport request.

[0027] It should be noted while the server 106 is described as a single server, its functionality, e.g. for providing an e-hailing service for a whole city, will in practical application typically be provided by an arrangement of multiple server computers (e.g. implementing a cloud service). Accordingly, the functionality described in the following as being provided by the server 106 may be understood to be provided by an arrangement of servers or server computers.

[0028] The data storage 108 may for example be part of a cloud-based system 107 provided by a cloud storage provider to store and access data which it may use for taking decisions, such as information about the location of passengers and vehicles, their history (earlier bookings and routes taken) etc.

[0029] The server 106 together with the vehicles 111 provides the e-hailing service, i.e. forms a transport system. It should be noted that while the example of FIG.1 relates to an e- hailing service where persons are transported, a transport system providing a transport service for transporting other items like fresh food and parcels may similarly be provided.

[0030] When a user makes a booking for a transport task, the server 106 may provide the user’s terminal 100 with an estimate of the time when the transport task will be completed, e.g. when the user will arrive, when food will be delivered to the user, etc.

[0031] Since, however, conditions, such as traffic jams, may lead to delays it may occur that those time estimates cannot always be fulfilled. Therefore, according to various embodiments, the server 106 also offers scenario-based insurance products to users in the transport system’s coverage area (which may span multiple countries) as add-ons to insure users against the uncertainties of transport services provided by the transport system (such as ride hailing and food delivery). These insurances may not only cover delays but also damages to goods, accidents etc.

[0032] For example, a scenario-based insurance product for a ride hailing service may include that a user is charged with a small premium and is in turn provided with a personal accident coverage for the ride, as well as being provided with a ride voucher or other compensation if the pick-up is delayed for a specific time, like 15 minutes. Similarly, there may be an insurance for a food delivery service where the consumer is charged with a premium for the food delivery and is in turn provided with a food voucher or other compensation if the delivery is delayed by at least 45 minutes.

[0033] A flat premium may be charged for these insurances, e.g. specific for the country of offering (e.g. $0.30 per ride in Singapore, and Rpl.000 per ride in Indonesia for the ride hailing service insurance mentioned above). These premiums are for example calculated based on risk across all possible scenarios and may be disadvantageous to the consumer under some scenarios. For example, consumers are less inclined to opt in for an insurance if they are ordering during off-peak hours where there are generally better traffic conditions and more delivery drivers available to pick up his/her order.

[0034] Therefore, according to various embodiments, dynamic pricing for transport task insurances, i.e. dynamic setting of premiums, is provided.

[0035] A dynamic setting of premiums may encourage consumers to opt-in into the products on scenarios that were originally disadvantageous to them but no longer are since the premiums will be adjusted accordingly based on numerous factors.

[0036] It should be noted that a dynamic pricing may be pre-implemented in some form for ride hailing and food delivery services. For example, the server 106 may calculate ride hailing and food delivery fees based on numerous factors such as estimated traveling time and traffic conditions. Fees are also subjected to surge pricing which are calculated based on supply and demand. According to various embodiments, this is now supplemented with dynamic setting of premiums.

[0037] The main benefits of dynamic premium setting for scenario-based insurance products can be seen in one or more of:

1. Better control on pricing strategy

2. Revenue Growth

3. Quick response to dynamic conditions in traffic and weather

4. Better pricing algorithm leading to long term relationship with the customer

[0038] According to various embodiments, the server 106 generates premiums for scenariobased insurance products using historical as well as live data of traffic at the time of consideration, weather conditions of a certain past period (e.g. the last Y days) as well as at the same time of a certain past period (e.g. the last X years). It can also consider live demand and supply of the service and take into account deviations from the standard price (i.e. a static base premium) when calculating the premium.

[0039] The server 106 for example calculates a premium for an insurance based on a (e.g. pre-determined, i.e. existing) base flat premium by adding or subtracting an additional dynamic premium component, which is for example based on a computed dynamic pricing score. This score is for example a weighted sum of a weather score and a traffic score.

[0040] The server 106 determines the weather score for the area covered by the booking. The weather score determines the likelihood of delay based on the weather conditions for a specific booking. To get the score, the server 106 collects the following information from each of a plurality of past bookings: weather condition for the booking (this may be categorical, e.g. “sunny”, “rain”, “thunderstorm” but may also include numerical information like a rainfall amount (e.g. per hour per square metre) for the booking (if raining) arrival or completion time of the booking location(s) covered for the booking

[0041] The server examines this collected information to find a correlation of the delivery times (i.e. arrival or completion times) and the weather condition to get a score (coefficient) that it uses to determine the weather score for future bookings.

[0042] For example, the correlation may be determined according to a model in which at least the weather condition is an independent variable, and the corresponding travel times are observations (outputs of the model). In some embodiments other independent variables may be included in the model, such as the total distance (estimated or actual) for the transport task, the pickup location and/or dropoff location, the type of vehicle used for the transport task, elevation change during the carrying out of the transport task, etc. Where there are multiple independent variables, the model may also include interaction terms (e.g. interaction between the weather condition and the total distance, interaction between the weather condition and the type of vehicle, etc.). From this model, a weather score may be obtained (e.g., a regression coefficient for the weather condition, or a number that is derived from the regression coefficient). The weather condition may for example include an amount of rainfall in or around a specific region. [0043] The traffic score for a booking is a score for the route covered when the transport task ordered by the booking is performed and indicates a likelihood of delay based on the traffic conditions on the route.

[0044] Information about the amount of traffic may be obtained from a traffic monitoring system, e.g. using traffic counters deployed in near proximity to the roadway and using an on-road medium, such as pneumatic road tubes laid across the roadway, piezo-electric sensors embedded in the roadway, inductive loops cut into the roadway, or a combination of these to detect the passing vehicles. The traffic monitoring system may also include cameras providing images of roads and a system which analysis the images (possibly using machine- learning-based object detection) to detect and count vehicles.

[0045] Another possible way to compute traffic score for a driver is to collect data from other drivers of the e-hailing service (e.g. using an e-hailing service app used by the drivers to accept bookings) going on the same road as the driver and determining how long it takes to go from one junction to another. The average speed of these drivers can be used to determine whether it is congested - either by comparing past data or comparing with the desired speed (e.g. given by distance divided by speed limit).

[0046] For determining the traffic score, the server 106 splits the route into road intervals and retrieves the following information for each road interval for each of plurality of past bookings:

Time taken from start to finish of the road interval

Time when the road interval was traversed from the start and end of the road

[0047] From this information, the server 106 determines a correlation between the time when a road interval was traversed and the time (i.e. length of time period) taken to traverse the road interval. For example, when a road interval is traversed at peak hour timings, it takes much longer to traverse the road interval.

[0048] From this correlation, the server 106 assigns, for the current booking (i.e. transport task), a road interval score to each of these road intervals (depending on the time when the road interval is expected to be used for the current transport task) which it uses to compute the traffic score for the whole route (e.g. by averaging the road interval scores).

[0049] To determine a weather score and traffic score, the server 106 may receive and process data measured by sensors of one or more data sources. For example, weather condition data may be measured by a weather station that is proximate to the pick up location of the booking, or that is proximate to the drop off location, and may be transmitted to the server 106 (e.g. based on a pull request by the server). In another example, one or more sensors of the vehicle that is associated with the booking may be used to measure weather data and to transmit this to the server 106. For example, a camera of the vehicle may capture one or more images of conditions outside the vehicle, and these images may be processed to automatically determine a weather condition (e.g. based on detection of rainfall, detection of the amount of light reaching the camera, etc.). Such processing may be done locally at the vehicle by a computing device, such as a smartphone, that is in communication with the camera (or which incorporates the camera).

[0050] The server 106 for example determines the (final) dynamic pricing score as a weighted sum of the weather score and traffic score as

Score = /3 x weather score + 6 x traffic score

[0051] The parameters as well as the weather and traffic score are for example set such that the dynamic pricing score lies in the range of [0,1], wherein a score of 0 indicates no price change (i.e. premium is set to the base premium). The premium may be computed as the base premium plus the dynamic pricing score times the base premium. For instance, a base premium of 2$ with a dynamic pricing score of 1 would be 2$ + 1*2$ = 4$.

[0052] The server 106 may calculate the premium together with the fare and present both to the user (via the user’s smartphone). Before making the booking, the user can then make a decision whether to proceed with the booking, try out an alternative option, or simply reject it (and e.g. try again later).

[0053] FIG. 2 shows an architecture for setting of a premium for an insurance, for example implemented by the server 106.

[0054] An insurance frontend service 201 receives the information that a user 208 considers to opt in for an insurance. It contacts an insurance backend service 202 which triggers a dynamic pricing service 203 to set the premium for the insurance. The dynamic pricing services gathers information from a data base 204 like the base premium, route segments involved, a customer segment to which the customer belongs, weather conditions and the dependency of the delivery time on the weather. This information may be provided by a data processor 205 which may in turn use information from a data base 206 storing information about past bookings (i.e. historical trip data including, in particular, delivery times and weather conditions) and an insurance database 207 (e.g. the base premium, for example depending on country or region).

[0055] FIG. 3 illustrates a process flowchart for setting of a premium for an insurance, for example implemented by the server 106.

[0056] In 301, the server 106 performs data collection, e.g. from the bookings database 206 and the insurance database 207. In 302, the server 106 pre-processes (e.g. analyses) the collected data, e.g. determines the insurance which the user 208 has chosen (on which the base premium may depend), determines the correlation of the delivery times with weather condition and the correlation between the time of a transport task and the time taken to traverse road intervals and determines the taxi type or types the user 208 uses. For example, the base premium may depend on the taxi type; also, correlation between delivery times and traversal times and weather and time, respectively, may be determined per vehicle type. In 303, the server 106 identifies attributes on which the premium may depend such as demography, time of booking and price ranges. In 304, the server 106 identifies a segment to which the customer belongs, e.g. using k-means based identified attributes and/or features of the booking. In 305, the server 106 performs dynamic price calculation. As explained above, this may determine setting a base premium (e.g. depending on the customer segment and other factors) as well as a possible adjustment according to the dynamic pricing score.

[0057] The server 106 may ensure that premiums stay within a limit and/or that the rate of change of the premium is limited.

[0058] In summary, according to various embodiments, a method is provided as illustrated in FIG. 4.

[0059] FIG. 4 shows a flow diagram 400 illustrating a method for setting a premium for an insurance of a transport task.

[0060] In 401, for each of a plurality of transport tasks that have been performed (i.e. previous or historical transport tasks), a delivery time necessary to perform the transport task and information about weather conditions when performing the transport task are recorded.

[0061] In 402, a correlation between weather and delivery time from the recorded delivery times and the recorded weather conditions is determined.

[0062] In 403, for a transport task (currently to be performed, i.e. corresponding to a booking to be performed), a route for performing the transport task is determined and, from one or more sensors, measurement data about a weather condition for the transport task is acquired. [0063] In 404, a premium for an insurance against delayed delivery for the transport task is set according to the weather condition and the determined correlation between weather and delivery time.

[0064] According to various embodiments, in other words, a premium for an insurance is dynamically set depending on weather conditions, wherein a correlation between weather and delivery time is used which is determined from historical information, i.e. historical trip data of previous transport tasks.

[0065] The method of FIG. 4 is for example carried out by a server as illustrated in FIG. 5.

[0066] FIG. 5 shows a transport system management server 500 according to an embodiment. [0067] The transport system management server 500, e.g. implemented by a server computer, includes a communication interface 501 (e.g. configured to receive requests for transport tasks and/or insurances). The transport system management server 500 further includes a processing unit 502 and a memory 503. The memory 503 may be used by the processing unit 502 to store, for example, historical trip data. The transport system management server 500 is configured to perform the method of FIG. 4. For example, the memory 503 stores program code which makes the transport system management server 500 perform the method of FIG.

4.

[0068] The transport resources may in particular include autonomous vehicles. Thus, the approach of FIG. 4 provides a control of a robotic system (including a plurality of robotic agents in the form of autonomous vehicles).

[0069] The methods described herein may be performed and the various processing or computation units and the devices and computing entities described herein may be implemented by one or more circuits. In an embodiment, a "circuit" may be understood as any kind of a logic implementing entity, which may be hardware, software, firmware, or any combination thereof. Thus, in an embodiment, a "circuit" may be a hard-wired logic circuit or a programmable logic circuit such as a programmable processor, e.g. a microprocessor. A "circuit" may also be software being implemented or executed by a processor, e.g. any kind of computer program, e.g. a computer program using a virtual machine code. Any other kind of implementation of the respective functions which are described herein may also be understood as a "circuit" in accordance with an alternative embodiment.

[0070] While the disclosure has been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced.

Claims

CLAIMS A method for setting a premium for an insurance of a transport task, comprising: recording, for each of a plurality of transport tasks that have been performed, a delivery time necessary to perform the transport task and information about weather conditions when performing the transport task; determining a correlation between weather and delivery time from the recorded delivery times and the recorded weather conditions; determining, for a transport task, a route for performing the transport task and acquiring, from one or more sensors, measurement data about a weather condition along the determined route ; and setting a premium for an insurance against delayed delivery for the transport task according to the weather condition and the determined correlation between weather and delivery time. The method of claim 1, wherein setting the premium comprises calculating a dynamic adjustment from the weather condition and the determined correlation between weather and delivery time and setting the premium to a pre-determined flat premium adjusted by the dynamic adjustment. The method of claim 2, wherein the dynamic adjustment specifies a percentage by which the flat premium is to be changed . The method of any one of claims 1 to 3, further comprising determining a time when the transport task is to be performed, estimating traffic conditions for the determined time and setting the premium for the insurance further depending on the estimated traffic conditions. The method of claim 4, comprising determining a traffic score from the estimated traffic conditions, a weather score from the weather condition and the determined correlation between weather and delivery time and setting the premium for the insurance depending on a weighted sum of the weather score and the traffic score. The method of claim 4 or 5, wherein estimating the traffic conditions comprises dividing a route of the transport task into route segments and estimating traffic conditions of each road segment depending on the determined time. The method of any one of claims 4 to 6, wherein estimating traffic conditions comprises determining, from previous transport tasks, a correlation between traffic condition and time and estimating the traffic conditions from the determined time and the determined correlation between traffic condition and time. The method of any one of claims 1 to 7, comprising determining a customer segment to which a customer of the transport task belongs and setting the premium further depending on the customer segment. The method of any one of claims 1 to 8, wherein the transport task is a transport of one or more persons, fresh food or one or more parcels. A transport system management server configured to perform the method of any one of claims 1 to 9. A computer program element comprising program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 1 to 9. A computer-readable medium comprising program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 1 to 9.