JP2023114612A - System, method and program for determining moving status score related to premium based on moving status - Google Patents

Abstract

To provide a system etc. for implementing insurance which promotes incentive for protecting a rule including a traffic rule, for a food delivery service deliverer etc.SOLUTION: A system is constituted to determine a user's moving status, based on position information acquired from a user's terminal (220), and determine a moving status score which affects premium paid by the user, based on at least a determination result of the user's moving status (240). The determination of the user's moving status includes the determination on whether or not the user follows a predetermined traffic rule.SELECTED DRAWING: Figure 2

Description

The present invention relates to determining a mobility score based at least on a user's mobility status that influences the premium paid by the user.

In recent years, traffic rule violations by food delivery service delivery workers have been viewed as a problem. As a result, the risk of accidents caused by delivery workers is increasing, and the personal safety of passers-by is also affected. Further, when a delivery member causes an accident, not only the delivery member but also the service provider may be held responsible.

The inventors of the present application have realized that insurance can be used to incentivize delivery workers to follow traffic rules. As a conventional technology related to insurance, Patent Literature 1 describes an information processing device that sets insurance conditions for a user based on the traffic conditions of a traveled route.

Patent No. 6261636

However, the above-described conventional technology does not take into consideration traffic rule violations by users.
The present invention has been made in view of the above, and its object is to provide a system or the like for implementing insurance that provides incentives for food delivery service delivery workers to follow rules including traffic rules. It is to be.

In order to solve the above problems, according to an embodiment of the present invention, the user's movement status is determined based on location information acquired from the user's terminal, and based at least on the result of the determination of the user's movement status, A system configured to determine a mobility score that influences a premium paid by the user, wherein the determination of the user's mobility includes determining whether the user follows predetermined traffic rules. A system is provided, comprising:

The system, which is an embodiment, may be further configured to identify the means of transportation of the user in order to determine whether the user complies with predetermined traffic rules.
In one embodiment, the means of transportation may include light vehicles, motorized bicycles, and motorcycles.

In one embodiment, the user can belong to a group consisting of a plurality of users, and in one embodiment, the system calculates the mobility score determined for the user and the group other than the user. It may be further configured to determine the premium to be paid by the user based on mobility scores determined for each of the other users to which it belongs.

In one embodiment, the system is further configured to determine whether the user is allowed to join a predetermined group based on at least one or both of the user's area of activity and the user's attributes. good.

A system that is an embodiment may store in advance a score for determining the movement situation score for each traffic rule.
In one embodiment, the movement status may include a movement route, and the determination of the user's movement status is one of whether the user has traveled a predetermined route and whether the user has traveled a predetermined area. Or it can further include determination of both.

In one embodiment, the system, based on the location information obtained from the terminal of the user, determines that the user meets at least part of the requirements constituting a violation of a predetermined traffic rule, and that the user meets a predetermined traffic rule. at least one of a predetermined sound, a predetermined vibration, and a predetermined display when it is determined that the user is off the route and that the user is within a predetermined area; It may be further configured to instruct the terminal of the user to generate an alert including:

In one embodiment, the system may be further configured to store the mobility score determined for the user on a blockchain.
In one embodiment, the user can purchase insurance implemented by a smart contract stored on the blockchain, and in one embodiment the system, based on a predetermined transaction to the smart contract, It may be further configured to update premiums paid by the user.

In one embodiment, the system may be further configured to effect payment of said insurance premium from said user in tokens based on a predetermined transaction to said smart contract.

In order to solve the above problems, according to an embodiment of the present invention, there are provided: a step of determining the movement status of the user based on the location information obtained from the user's terminal; determining a mobility status score that influences premiums paid by the user based at least on A method is provided that includes determining whether traffic rules are being obeyed.

In order to solve the above problems, according to an embodiment of the present invention, there are provided: a step of determining the movement status of the user based on the location information obtained from the user's terminal; determining a travel situation score that affects the insurance premiums paid by the user, based on at least A program is provided that includes the step of determining whether it complies with.

According to one embodiment of the present invention, insurance premiums paid by delivery workers can be changed depending on whether they comply with traffic rules. Therefore, delivery workers have an incentive to follow traffic rules, which is expected to reduce accidents. be done.

Further, according to one embodiment of the present invention, an incentive to follow traffic rules can be applied to each group of delivery workers.
In addition, according to an embodiment of the present invention, the delivery person may be incentivized to avoid routes that are more likely to cause accidents, such as narrow alleys.

In the case of food delivery services, delivery workers may use various means of transportation, such as light vehicles, motorized bicycles, and motorcycles, instead of automobiles. According to one embodiment of the present invention, appropriate processing can be performed according to the type of transportation means used by the delivery person.

In recent years, with the increase in the number of food delivery service providers, delivery workers often use multiple providers. According to one embodiment of the present invention, it is possible to enable cross-industry information cooperation involving rival traders.

1 is a block diagram outlining an exemplary system that is an embodiment of the present invention; FIG. 4 is a flowchart of processing performed by a server included in the exemplary system; FIG. 4 is a flow chart of an exemplary process for determining a user's mobility status; FIG. It is a figure for demonstrating retrograde. It is a figure for demonstrating the protrusion to the roadway side. FIG. 4 is a flow chart of an exemplary process for determining a user's mobility status; FIG. FIG. 3 is a diagram for explaining a reference route and penalty areas; FIG. 4 is a flow chart of an exemplary insurance subscription and establishment process; 4 is a flow chart of an exemplary premium update process; 5 is a flowchart of an exemplary insurance premium collection process; 4 is an exemplary table relating to traffic rules; 4 is an exemplary table relating to traffic rules; 4 is an exemplary table relating to traffic rules; 1 is a diagram of an exemplary hardware configuration of a computer; FIG.

1 Embodiment of the Present Invention 1-1 Outline of Exemplary System One embodiment of the present invention is a system for implementing insurance capable of giving an incentive to at least observe traffic rules for delivery workers of a food delivery service. System. Hereinafter, the delivery person is also referred to as "user". It should be noted that the food delivery service is only an application example of the present invention and that the present invention can be used for various services and businesses.

FIG. 1 depicts a block diagram outlining an exemplary system 100 that is one embodiment of the present invention.
Reference numeral 110 denotes a user terminal carried by each delivery person. The user terminal 110 should have positioning capabilities. Positioning functions include the Global Positioning System (GPS) in the United States, the Quasi-Zenith Satellite System (QZSS) in Japan (QZSS, commonly known as "Michibiki" from the name of the satellite used), Galileo in Europe, GLONASS in Russia, It may use a radio base station or the like, but is not limited to these. In particular, in one embodiment of the present invention, the user terminal 110 has a high-precision positioning function, for example, which part of the road the delivery person is moving on (out of multiple lanes). It is preferable to have a positioning function with accuracy enough to determine which lane it is, and whether it is on the left side, the center, or the right side of the lane.

The user terminal 110 may be a personal digital assistant, such as a smart phone, installed with a predetermined application. However, positioning functions of general smartphones, such as those using GPS or terrestrial wireless base stations, are not very accurate. Therefore, the user terminal 110 may be composed of a smart phone 114 and an external device (eg, a GNSS receiver) 112 having a positioning function using, for example, Michibiki with higher accuracy. Smartphone 114 can obtain positioning results from external device 112 via any connection technology, such as a Bluetooth connection. At least part of the processing to be described later can be performed using position information with accuracy obtained when using GPS or ground wireless base stations. Note that we do not exclude embodiments in which

The user terminal 110 is configured to repeatedly perform positioning regularly or irregularly, and to transmit position information including the positioning result to the server 120, which will be described later, voluntarily or in response to a request. This position information may include, by way of example and not limitation, information specifying the user terminal 110, latitude and longitude obtained by positioning, and time of positioning.

Reference numeral 120 denotes a server managed by a food delivery service company (company A). Server 120 may be any type of computer.
130 indicates a group of blockchain nodes that communicate with server 120, and 130A-130D indicate each blockchain node that group of blockchain nodes 130 contains. Although only four blockchain nodes included in the blockchain node group 130 are shown in FIG. It may be any number, preferably four or more. Blockchain nodes 130A-130D are any type of computer having at least the functionality to implement a given blockchain technology and smart contracts based on that technology.

A reference numeral 140 denotes a server managed by another company (company B). Server 140 may be any type of computer. The trader B may be a food delivery service trader, or may be a trader in another business. It should be noted that a plurality of user terminals (not shown) that transmit location information may also exist for the server 140 . Also, the plurality of user terminals 110 that transmit location information to the server 120 and the plurality of user terminals that transmit location information to the server 140 may partially overlap. That is, one user terminal may transmit location information to both servers 120 and 140 . This is because one delivery person may contract with a plurality of companies. It should also be noted that example system 100 may include servers (not shown) managed by one or more additional vendors.

At least one of the servers 120 and 140 and each blockchain node included in the blockchain node group 130 is not one physical computer, but one or more Note that it can be one of the virtual computers (for example built on the so-called cloud). Servers 120 and 140 may also function as one blockchain node included in blockchain node group 130 .

Also, between the user terminal 110 and the server 120, between the servers 120 and 140 and the blockchain node group 130, and between each blockchain node included in the blockchain node group 130, either wireless or wired Note that there may be one or more networks (not shown), including the Internet, built by or both.

1-2 Overview of Processing Performed by Exemplary System FIG. 2 is a flowchart of exemplary processing 200 performed by server 120 . Note that the server 140 may also perform similar processing.

210 indicates the step of acquiring location information from the user terminal 110 . Server 120 may perform step 210 for each of a plurality of user terminals. The server 120 may temporarily or permanently store the obtained location information, for example, in its own storage device.

Reference numeral 220 denotes a step of determining the movement status of the delivery person carrying the user terminal 110, that is, the user, based on the acquired position information. Server 120 may perform step 220 for each of a plurality of users carrying user terminals. Note that "based on location information" may include "based on the history of location information." This is the same below.

230 indicates a step of determining whether a predetermined condition is satisfied. For example, one exemplary process 200 may correspond to one user's delivery. That is, example process 200 may begin when a user initiates a delivery, and the predetermined condition at step 230 may be that the delivery is completed. It should be noted that determination of whether or not the predetermined condition is satisfied can be performed by any method including known techniques. If it is determined that the predetermined condition is satisfied, the process proceeds to step 240; otherwise, the process returns to step 210.

240 indicates the step of determining a mobility status score for the user based on the results of the mobility status determination. In step 240, a travel context score for the user may be determined based on the results of all of the multiple travel context determinations. Server 120 may perform step 240 for each of the plurality of users. Note that the server 120 may temporarily or permanently store the travel situation score in, for example, its own storage device in association with the user who determined the travel situation score. Alternatively, the server 120 associates the mobility score with the user's account (described below) that determined the mobility score by sending an appropriate transaction to at least one of the blockchain nodes 130. May be stored on the blockchain.

250 indicates the step of performing a process related to the insurance that the user has, based on the travel situation score. The processing related to insurance includes at least processing for updating insurance premiums for each insurance subscriber, processing for collecting insurance premiums from each insurance subscriber in tokens (substitute currency), etc. (described later). It may contain a part. The token may be a so-called crypto asset (virtual currency), but is not limited to this.

1-3 Determining Movement Status At step 220, the movement status of the user can be determined by various methods.

1-3-1 Determination of Observance of Traffic Rules FIG. 3 is a flowchart of an exemplary process 300 that the step 220 of determining a user's movement status may include. The example process 300 concerns whether the user is following traffic rules.

310 indicates the step of identifying the user's means of transportation. Any method can be used to specify the means of transportation of the user. For example, the means of transportation declared by the user in advance and stored in the server 120 in association with the user may be specified as the means of transportation of the user. Alternatively, for example, based on the location information acquired from the user terminal 110, the means of transportation of the user may be identified by a known technique. Examples of means of transportation are, but are not limited to, light vehicles, motorized bicycles, and motorcycles. The means of transportation identified may include walking. In addition, as means of transportation to be specified, ordinary bicycles (hereinafter simply referred to as "bicycles") and light vehicles other than bicycles may be distinguished.

320 indicates the step of identifying attributes of the road on which the user is located. Any method can be used to specify the attribute of the road on which the user is located. The attribute of the road on which the user is located can be specified by mapping the position information obtained from the user terminal 110 with pre-stored electronic map data, for example. Note that the "road attribute" may be arbitrary information for specifying related traffic rules and demerit points, which will be described later. Such information may include, but is not limited to, number of lanes, intended mode of transport (e.g. sidewalks, cycle paths, roads with bike lanes), presence or absence of a centerline, for example. It cannot be done.

330 indicates the step of selecting one relevant traffic rule from one or more predetermined traffic rules. “Relevant traffic rules” are traffic rules related to the mode of transport identified in step 310 and the attributes of the road identified in step 320 .

340 indicates the step of determining whether the user meets at least some of the selected traffic rule violation requirements based on the location information obtained from the user terminal 110 . In step 340 , if so, processing proceeds to step 350 , otherwise processing proceeds to step 360 .

350 indicates the step of instructing the user terminal 110 to generate an alert including at least one of a predetermined sound, a predetermined vibration, and a predetermined display. This alert may be configured to occur in such a manner as to achieve the purpose of preventing traffic rule violations and accidents.

360 indicates a step of determining whether the user meets all of the selected traffic rule violation requirements based on the location information acquired from the user terminal 110 . In step 360 , if so, processing proceeds to step 370 , otherwise processing proceeds to step 380 .

370 indicates the step of increasing the penalty points associated with the user. It should be noted that the deduction associated with the user may have been initialized to, for example, zero before execution of the first step 220 after the exemplary process 200 began.

The server 120 can store, for example, in the form of a table, one or more predetermined traffic rule violation requirements and the corresponding amount by which deduction points are increased (hereinafter referred to as "deduction points"), and step 330 includes: It can be the step of selecting one row of a table. FIGS. 11-13 show such exemplary tables 1100-1300, respectively.

An example table 1100 in FIG. 11 is for making determinations regarding reverse traveling as a traffic rule. Retrograde will be described with reference to FIG. 400 is a schematic diagram of a two-lane road. 410 indicates the centerline, 420 indicates the shoulder, and 430 indicates the sidewalk. According to the Road Traffic Law, a bicycle, which is a light vehicle, is basically required to travel in the direction indicated by 440 on the left side of the roadway or shoulder on the left side of the center line 410 indicated by 440 . In this embodiment, when the user's means of transportation is a bicycle and the user is moving on the road indicated by 400, and the user is traveling 20 m or more in a direction and position other than indicated by 440, the user travels backward. It can be determined that The first row of the example table 1100 corresponds to this traffic rule. That is, the first row of the example table 1100 relates to the case where the user's means of transportation is a bicycle and the attribute of the road on which the user is located is the road indicated by 400, that is, a two-lane road. It shows two requirements: ``running in a place other than the left edge of the left lane in the direction of travel and the left shoulder'' and ``running 20 m or more'' in this state. Therefore, for example, when the user starts riding a bicycle on a two-lane road "other than the left end of the left lane in the direction of travel and the left shoulder", when the first row of the example table 1100 is selected in step 330, At step 340 it is determined that the user falls under at least some of the violation requirements and an alert will be generated at step 350 as a potential accident hazard. Further, for example, when the user "travels 20 m or more" on a two-lane road "other than the left edge of the left lane in the direction of travel and the left shoulder", in step 330, the first row of the example table 1100 is When selected, it is determined at step 340 that the user is subject to at least some of the violating requirements, an alert is generated at step 350 as a potential accident-inducing event, and all of the violating requirements are at step 360. is determined to be applicable, and the demerit points are increased in step 370 as the user is violating the traffic rules related to going backwards. It should be noted that the deduction points increased in step 370 at this time may be the value of the "deduction point" column of the selected row, that is, the first row of the example table 1100, ie, 10 points.

An exemplary table 1200 in FIG. 12 is for making determinations regarding speeding as a traffic rule. That is, the first row of the example table 1200 relates to the case where the user's means of transportation is a bicycle and the attribute of the road on which the user is located is a sidewalk. It shows two requirements: "running for 5 seconds or more" in this state. Thus, for example, if the user begins to "run at a speed of 25 km/h or more" on a sidewalk on a bicycle, and the first row of example table 1200 is selected in step 330, then in step 340 at least part of the violation requirement is determined to correspond to the user, and an alert is generated in step 350 as a possibility of inducing an accident. In addition, for example, when the user rides a bicycle on a sidewalk "at a speed of 25 km/h or more" and "runs for 5 seconds or more", when the first row of the example table 1200 is selected in step 330, in step 340 It is determined that the user corresponds to at least part of the violation requirements, an alert is generated in step 350 as being likely to induce an accident, and it is determined that the user corresponds to all of the violation requirements in step 360, and the user At step 370, demerit points will be increased for violating traffic rules related to speeding. It should be noted that the deduction points increased in step 370 at this time may be the value of the "deduction point" column in the selected row, ie, the first row of the example table 1200, ie, 15 points.

An example table 1300 in FIG. 13 is for making a judgment related to running off into the roadway as a traffic rule. The protrusion to the roadway side will be described with reference to FIG. 500 is a schematic diagram of a two-lane road. 510 indicates a bicycle lane, and 520 indicates a parked large bus (for example, a bus with a total length of 12.0 m, a width of 2.5 m, a height of 3.5 m, and a seating capacity of 45 to 60 people). there is When traveling on the road indicated by 500 by bicycle, the user basically has to travel in the bicycle lane 510 on the left side of the direction of travel. Generally, it is necessary to protrude to the road side and run. The first row of the example table 1300 relates to the case where the user's means of transportation is a bicycle and the attribute of the road on which the user is located is a road with a bicycle lane. ``Running at over 30km/h'', and ``Running at 20m or more'' in these states (Running distance 540 is at least 20m It shows the three requirements of Therefore, for example, when the user starts to "run off the road by 4 m or more" on a road with a bicycle lane, or "run off the road by 4 m or more" and "run at 30 km/h or more". If the first row of example table 1300 is selected in step 330, it is determined in step 340 that the user falls under at least a portion of the violation requirements, and an alert is issued in step 350 as a potential accident hazard. will occur. In addition, for example, when a bicycle "protrudes into the roadway by 4 m or more", "at 30 km/h or more", or "runs 20 m or more" on a road with a bicycle lane, in step 330, the first row of the example table 1300 is selected, it is determined in step 340 that the user falls under at least some of the violation requirements, an alert is generated in step 350 as a potential accident-inducing event, and all of the violation requirements are met in step 360. It is determined that the user falls under this category, and the demerit points are increased in step 370 because the user is violating the traffic rules relating to running out onto the roadway. It should be noted that the deduction points increased in step 370 at this time may be the value of the "deduction point" column in the selected row, ie, the first row of the example table 1300, ie, 5 points.

Returning to FIG. 3, 380 depicts the step of determining if there are any unselected related traffic rules of the one or more predetermined traffic rules. If it is determined that there are relevant traffic rules that have not been selected, processing returns to step 330, otherwise example process 300 ends.

The traffic rules may include one or both of legal rules and non-legal rules that should be observed in common sense.
1-3-2 Determining Travel Route FIG. 6 is a flow chart of an exemplary process 600 that the step 220 of determining a user's travel status may include. Exemplary process 600 pertains to a user's travel route.

610 indicates a step of determining whether the user has deviated from the reference route based on the position information obtained from the user terminal 110 . If so, the process proceeds to step 620 , otherwise the process proceeds to step 650 . 650 indicates the step of determining if the user is within the penalty area. If so, processing proceeds to step 660, otherwise example process 600 ends.

Steps 610 and 650 are described with reference to FIG. 720 indicates a reference route. The reference route may be determined in advance based on the low risk of causing a traffic accident, such as low traffic volume and road width. Reference numeral 710 denotes a history of location information acquired from the user terminal 110, that is, a route traveled by the user. That is, in step 610, if the reference route 720 and the route 710 traveled by the user have the relationship shown in FIG. will be judged. 730 indicates the penalty area. Penalty area 730 may be predetermined based on the high risk of causing a traffic accident. That is, the penalty area indicates a high-risk area registered in the example system 100, such as an area including a school road or an accident-prone area. It can be a thigh. The penalty area need not be two-dimensionally defined as an area through which the vehicle should not pass, but may be defined as a road through which the vehicle should not pass or an intersection through which the vehicle should not pass. If the penalty area 730 and the route 710 traveled by the user have the relationship shown in FIG. will be Note that the reference route and penalty area may be stored in the server 120 in advance. Also, the reference route and penalty area may be displayed at the user terminal 110 before the user starts to move, to inform the user in advance. Accordingly, the example system 100 determines a recommended, e.g., safe, pedestrian-friendly route (reference route) in response to the user's delivery starting point and delivery destination being determined, and defines the reference route as a generic route. may be configured to present to the user as a navigation route similar to other navigation systems, and to further present nearby penalty areas to the user.

Note that step 650 may be performed before step 610 . Alternatively, steps 610 and 650 may be performed in parallel. Also, it should be noted that the decisions in steps 610 and 650 should be made considering the error in the location information obtained from the user terminal 110 .

Returning to FIG. 6, 620 depicts instructing the user terminal 110 to generate an alert including at least one of a predetermined sound, a predetermined vibration, and a predetermined display. Step 620 may be similar to step 350, but may generate an alert in a different manner.

630 indicates a step of determining whether a predetermined time has passed since the user deviated from the reference route based on the position information acquired from the user terminal 110 . If it is determined that the vehicle has deviated from the reference route and has passed the predetermined time, the process proceeds to step 640 , otherwise the process proceeds to step 650 .

640 shows the step of increasing the penalty points associated with the user. The number of points to be deducted is arbitrary and may be constant, or may be varied according to the user's means of transportation, the attributes of the road on which the user is located, etc. (the degree of risk of causing a traffic accident, etc.). Also, the number of demerit points can be stored in the server 120 in advance.

660 indicates the step of instructing the user terminal 110 to generate an alert including at least one of a predetermined sound, a predetermined vibration, and a predetermined display. Step 660 may be similar to steps 350 and 620, but may generate an alert in a different manner.

670 indicates a step of determining whether a predetermined time has passed since the user entered the penalty area based on the position information obtained from the user terminal 110 . If it is determined that the predetermined amount of time has passed since entering the penalty area, processing proceeds to step 680, otherwise exemplary process 600 ends. The “predetermined time” in step 670 may be the same as or different from the “predetermined time” in step 630 .

680 shows the step of increasing the penalty points associated with the user. Step 680 may be a similar step to step 640 , but the number of points deducted in step 680 may be the same as or different from the number of demerits in step 640 .

Therefore, for example, when the user begins to deviate from the reference route, it is determined in step 610 that the user has deviated from the reference route, and an alert is generated in step 620 as a possible accident. Further, for example, when the user deviates from the reference route and a predetermined time has elapsed, it is determined in step 610 that the user has deviated from the reference route, and an alert is generated in step 620 as an accident may be induced. Also, in step 630, it is determined that the predetermined time has passed since the vehicle deviated from the reference route, and in step 640, the demerit points are increased.

Further, for example, when the user begins to enter the penalty area, it will be determined in step 650 to be in the penalty area and an alert will be generated in step 660 as a potential accident hazard. Also, for example, when a predetermined time has passed since the user entered the penalty area, it is determined in step 650 that the user is in the penalty area, and an alert is generated in step 660 as there is a risk of causing an accident. Then, in step 670, it is determined that the predetermined time has passed since entering the penalty area, and in step 680, the demerit points are increased.

1-4 Determining Movement Situation Score In step 240, the user's movement situation score is determined by reflecting the final deduction points obtained in step 220 on the movement situation score that serves as a predetermined reference. good.

1-5 Insurance-Related Processing In this embodiment, insurance-related processing can be implemented using a smart contract based on predetermined blockchain technology.

1-5-1 Basic Mechanism for Smart Contracts The basic mechanism for smart contracts based on blockchain technology is explained below. It should be noted that the following description assumes technology based on Ethereum as the blockchain technology implemented by the blockchain nodes, and matters in Ethereum may be applied to matters not explained. However, it should be noted that the blockchain technology implemented by the blockchain nodes is not so limited. Also, blockchain technology is one of the distributed ledger technologies. It should be noted that the present invention may be implemented using any distributed ledger technology capable of performing processes similar to those described below. For example, the present invention can be implemented using technology based on Corda, a distributed ledger technology. Corda-based technology does not produce blocks, but has a mechanism similar to the smart contracts described below.

A blockchain node stores a so-called blockchain. A blockchain is made up of blocks, each with a single parent block, except for the first block (eg, the genesis block).

Each block can contain a smart contract. A smart contract can define at least the operations that a blockchain node should perform and the information that the blockchain node should store (eg states and events). A smart contract can also include one or more parts (eg, functions) that each define a process to be performed. Note that the processing to be executed includes processing to store the content of information to be newly stored, processing to update the content of information to be stored, and processing to return the content of information to be stored in response to a request. be able to.

Each block contains information that is uniquely determined according to what the parent block contains (e.g., the hash value of the parent block) and information that the blockchain node should store at the time the block was generated. contains information that is uniquely determined by each block (for example, state route or receipt route), and includes what any block from a certain block to the first block contains, or the time when any block is generated tampering with the content of the information to be stored in the .

When a blockchain node receives a transaction, it verifies the validity of the transaction. This transaction includes a transaction for creating a smart contract (including the smart contract itself) and a transaction for executing a process defined in part of the smart contract (which may include parameters for the process). ) and Upon successfully validating a transaction, the blockchain node forwards the transaction, ie, a valid transaction, to at least one other blockchain node. Note that a blockchain node may also generate valid transactions on its own and forward them to at least one other blockchain node. Also, the processing defined in the smart contract portion may be executed without going through a transaction (eg, via a call method).

Blockchain nodes attempt to generate blocks containing valid transactions. In this trial, if the transaction is for generating a smart contract, generate an account of the smart contract and its address (e.g., Contract Account (CA) and its address), Associate with a contract. Also, in this trial, if the transaction is for performing the processing defined in the smart contract part, the blockchain node will perform the processing. Upon successfully generating a block, a blockchain node adds the block to its stored blockchain and transfers it to at least one other blockchain node. Also, when the block generation is successful, the blockchain node stores the updated content of the information when executing the process of updating the content of the information to be stored in the block generation attempt. Block generation is done using methods that are successful when solving computationally difficult problems (for example, proof of work, proof of stake, and various consensus building algorithms). .

When a blockchain node receives a block, it verifies the validity of the block. In this verification, if the block contains a transaction to perform the processing defined in the smart contract part, the blockchain node performs the processing. Upon successful validation of the block, the blockchain node adds the block to its stored blockchain and transfers it to at least one other blockchain node. In addition, when the block validity verification succeeds, the blockchain node stores the updated information content when executing the processing to update the information content to be stored in the block validity verification. .

With the mechanism described above, each blockchain node included in the blockchain node group 140 executes the processing defined in the smart contract portion and stores the information content.

1-5-2 Insurance Enrollment and Acquisition Processing FIG. 8 is a flow chart of an exemplary insurance enrollment and entitlement processing 800 included in insurance related processing. Insurance subscription processing is processing for the user to subscribe to insurance. The insurance establishment process is a process for starting the implementation of insurance.

810 indicates a step in which the user terminal 110 transmits to the server 120 the application for the selected insurance of the user using the user terminal 110 . The subscription may include information identifying the user and information identifying the insurance selected.

820 indicates a step of acquiring information for judging whether or not the user can enroll in insurance based on the application for insurance when the server 120 receives the application for insurance from the user. This information includes the user's delivery area or activity area, the user's attributes (e.g., current mobility score, experience as a delivery person including other food delivery services, distance traveled, average travel speed, etc.), and conditions for subscribing to the insurance. This information may be pre-stored on the server 120 or on the blockchain. Alternatively, part of this information may be included in the subscription. Note that the subscription conditions are, for example, a condition that the user's activity area is a predetermined area, or that the user's attribute is a predetermined attribute (for example, that the moving situation score is a predetermined value or more, or that a predetermined delivery has been made more than once), but it is not limited to these conditions.

830 shows the step of server 120 determining whether the user meets the conditions for subscribing to the insurance. If it is determined that the subscription conditions have been met, processing proceeds to step 840; otherwise, example process 800 ends. Before ending the exemplary process 800, a step (not shown) of sending an alert to the user terminal 110 indicating that the conditions for subscribing to the insurance are not met may be executed.

840 indicates a step in which server 120 stores information identifying the user as a subscriber of the insurance. It will be appreciated that multiple subscribers to the insurance form a group.

850 indicates a step in which the server 120 determines whether the insurance is valid. If so, the process proceeds to step 860, otherwise the example process 800 ends. The conditions under which the insurance is established are arbitrary. For example, it may be the condition that the current number of subscribers of the insurance is equal to or greater than the minimum number of subscribers that can be specified for each insurance, but it is not limited to this. isn't it.

860 initiates a transaction for generating a smart contract for implementing the insurance (hereinafter "insurance contract") (hereinafter "insurance contract generation transaction") to initiate implementation of the insurance. ) is shown. An insurance contract creation transaction may include a program in executable form on a blockchain node representing various processes for implementing the insurance. However, the information contained in the insurance contract creation transaction is not so limited. Information about the insurance may be defined, ie hard-coded, in the program. Here, information about insurance may include information identifying accounts of a plurality of subscribers of the insurance group, and the like.

870 depicts server 120 sending an insurance contract creation transaction to at least one blockchain node in blockchain nodes 130 .

880 shows the process by which one blockchain node generates an insurance contract based on the transaction submitted in step 870 and according to the mechanism described above. It should be noted that this process includes a step 885 of generating an insurance contract account and its address, and since the generated address is stored in the blockchain, the user terminal 110 and server 120 can access the address of the insurance contract account. can be obtained from the blockchain.

The “account” is given to each entity (user, vendor A and vendor B, smart contract, etc.) in the blockchain technology implemented by the blockchain node group 130, and the “address” is the It is assigned to each “account” in blockchain technology, and can be used as one of the information that identifies the “account” and the entity to which the “account” is assigned.

1-5-3 Premium Update Processing FIG. 9 is a flowchart of an exemplary premium update processing 900 included in insurance processing. At least a portion of the example premium update process 900 can be considered to be performed at step 250 . The premium update process 900 is a process for updating premiums paid by each subscriber of the insurance, that is, the user.

910 is a transaction (hereinafter referred to as an "insurance premium update transaction") in which the server 120 causes a blockchain node to execute a portion (hereinafter referred to as an "insurance premium update function") corresponding to insurance premium update processing in the insurance contract. ) is shown. Premium renewal transactions are
the address of the account for the insurance contract; and
Information specifying a premium update function can include, but is not limited to, the information a premium update transaction includes.

920 shows server 120 sending the premium update transaction to at least one blockchain node in blockchain nodes 130 .

930 shows the steps performed by one blockchain node executing the premium update function, based on the transaction submitted in step 920 and according to the mechanism described above.

935 shows the processing that step 930 includes, updating premiums for each participant in the policy.
A subscriber's premium may be updated based on the subscriber's mobility score. A subscriber's insurance premium may be updated, for example, so that the lower the mobility score of the subscriber, the higher the premium. This means that the subscriber's low mobility score indicates that the subscriber tends not to follow at least some of the rules (including following traffic rules, standard routes, and not entering penalty areas). , and therefore, there is a high possibility of causing an accident. More specifically, the insurance premium for a certain subscriber is, for example, an amount increased from a predetermined base insurance premium if the mobility score of the subscriber is smaller than a predetermined threshold; The amount may be reduced from the standard insurance premium or updated to the same amount as before the update.

Alternatively, a subscriber's premium may be updated based on that subscriber's mobility score and each other participant's mobility score. A certain subscriber's insurance premium may be updated, for example, so that the smaller the average value or the maximum value of the movement status scores of all the subscribers of the insurance, including the subscriber himself/herself, the higher the insurance premium. More specifically, the insurance premium for a certain subscriber is increased from a predetermined standard insurance premium if the average value or maximum value of the mobility score of all subscribers of the insurance, including the self, is smaller than a predetermined threshold. If not, the amount may be reduced from the predetermined standard insurance premium or updated to the same amount as before the renewal. It will be appreciated that by updating each policyholder's premium with the mobility score of all policyholders, i.e., the group as a whole, incentives to lower premiums or to follow the rules may be exercised on a group-by-group basis.

Note that the predetermined base insurance premium and mobility score for each subscriber may be obtained from the blockchain. Also, updated premiums may be stored on the blockchain in association with each subscriber's account and the insurance contract's account. Also, the predetermined standard insurance premium may be the insurance premium paid by the initial subscriber who enrolled in the insurance.

1-5-4 Insurance Premium Collection Processing FIG. 10 is a flowchart of an exemplary insurance premium collection processing 1000 included in insurance processing. At least a portion of the exemplary premium collection process 1000 can be considered as performed at step 250 . Insurance premium collection processing 1000 is processing for collecting insurance premiums in tokens from each insurance subscriber.

1010, the server 120 performs a transaction (hereinafter, an “insurance premium collection transaction”) that causes a blockchain node to execute a portion of the insurance contract that corresponds to insurance premium collection processing (hereinafter, “insurance premium collection function”). ) is shown. Premium collection transactions are
the address of the account for the insurance contract; and
Information specifying a premium collection function may include, but is not limited to, the information a premium collection transaction includes.

1020 depicts server 120 sending the premium collection transaction to at least one blockchain node in blockchain nodes 130 .

1030 shows the steps performed by one blockchain node executing a premium collection function based on the transaction sent in step 1020 and according to the mechanism described above.

1035 shows the processing that step 1030 includes, collecting premiums in tokens (monetary currency) from each subscriber of the policy. Based on each subscriber's account, this process generates a transaction to obtain each subscriber's premium amount from a blockchain node and transfer tokens from each subscriber's account to a given account. , executing and transmitting to at least one other blockchain node.

2 Alternative Embodiments of the Invention Another embodiment of the invention is a method for a computer to perform processes such as those described above.
Yet another embodiment of the present invention is a program that causes a computer to perform processing as described above.

3 Computer An example of the hardware configuration of a computer that can be used to implement an embodiment of the present invention will be described below.

FIG. 14 shows an example of the hardware configuration of a computer. As shown in the figure, the computer 1400 mainly includes a processor 1410, a main storage device 1420, an auxiliary storage device 1430, an input/output interface 1440, and a communication interface 1450 as hardware resources. These are interconnected via bus lines 1460 including an address bus, data bus, control bus, and the like. An interface circuit (not shown) may be appropriately interposed between the bus line 1460 and each hardware resource.

The processor 1410 controls all or at least part of a computer such as a CPU or a microprocessor. Note that one computer may include multiple processors 1410 . In such a case, the “processor” in the above description may be a generic term for multiple processors 1410 .

The main memory 1420 is a volatile memory such as SRAM (Static Random Access Memory) or DRAM (Dynamic Random Access Memory) that provides a work area for the processor 1410 .

The auxiliary storage device 1430 is a non-volatile memory such as an HDD, an SSD, or a flash memory that stores software such as programs and data. The programs, data, and the like are loaded from the auxiliary storage device 1430 to the main storage device 1420 via the bus line 1460 at any time. Secondary storage 1430 may also be referred to as computer-readable storage media, non-transitory computer-readable storage media, or computer-readable storage media. The program includes instructions for causing the processor to execute desired processing.

The input/output interface 1440 performs one or both of presenting information and receiving input of information. be.

The communication interface 1450 is connected to a network 1455 including one or more of the Internet, a local area network (LAN), etc., and transmits and receives data via the network 1455 . Communication interface 1450 and network 1455 may be wired or wirelessly connected. Communication interface 1450 may also obtain network information, such as Wi-Fi access points, communication carrier base stations, and the like.

It will be apparent to those skilled in the art that the computer 1400 can function as desired means, execute desired steps, and realize desired functions through the cooperation of the hardware resources and software illustrated above. be.

4 Conclusion Although several examples of embodiments of the present invention have been described above, it should be understood that these are merely examples and are not intended to limit the technical scope of the present invention. It should also be understood that the described embodiments may be subject to appropriate changes, additions, improvements, etc. without departing from the spirit and scope of the present disclosure. The scope of the invention should not be limited by any of the above-described embodiments, but should be defined only by the claims and their equivalents.

100... Exemplary system 110... User terminal 130... Blockchain node group 200... Exemplary process executed by server 300... Exemplary process for determining user's movement status (whether the user follows traffic rules)
400 Two-lane road 410 Center line 420 Road shoulder 430 Sidewalk 440 Direction and position where a light vehicle bicycle should travel 500 Two-lane road 510 Bicycle lane 520 Large bus 530 Width of user's protrusion 540 -- Distance traveled by the user 600 -- Exemplary process for determining the movement status of the user (related to the movement route of the user)
710 User movement route 720 Reference route 730 Penalty area 800 Exemplary insurance enrollment and establishment process 900 Exemplary insurance premium renewal process 1000 Exemplary insurance premium collection process 1100 Exemplary insurance premium collection process 1100 Determination for reversal Exemplary table 1200 -- Exemplary table 1300 -- Exemplary table for judging excessive speed -- Exemplary table 1455 -- Exemplary table for judging overrunning onto the roadway 1455 -- Network 1460 -- Bus line

Claims (13)

Determining the user's movement status based on the location information obtained from the user's terminal,
A system configured to determine a mobility status score that influences a premium paid by the user based at least on results of the determination of the user's mobility status, wherein the determination of the user's mobility status comprises: A system comprising determining whether the user is following predetermined traffic rules. 2. The system of claim 1, further configured to identify the user's means of transportation to determine whether the user complies with predetermined traffic rules. 3. The system of claim 2, wherein the means of transportation includes light vehicles, motorized bicycles, and motorcycles. A system according to any one of claims 1 to 3,
The user belongs to a group consisting of a plurality of users,
The system determines the premium to be paid by the user based on the mobility score determined for the user and the mobility score determined for each other user belonging to the group other than the user. further configured to
system. 5. The system of claim 4, further configured to determine whether the user is allowed to join a predetermined group based on at least one or both of the user's area of activity and the user's attributes. system. 6. The system according to any one of claims 1 to 5, wherein a score for determining said movement situation score is pre-stored for each traffic rule. A system according to any one of claims 1 to 6,
the movement status includes a movement route;
The determination of the movement status of the user further includes determination of one or both of whether the user has traveled a predetermined route and whether the user has traveled a predetermined area.
system. The system according to any one of claims 1 to 7, wherein, based on the location information obtained from the terminal of the user,
that the user meets at least some of the requirements that constitute a violation of predetermined traffic rules;
the user is off a predetermined route;
the user to generate an alert including at least one of a predetermined sound, a predetermined vibration, and a predetermined display when it is determined that the user is within a predetermined area; a system further configured to instruct said terminal of . 9. The system of any one of claims 1-8, further configured to store the mobility score determined for the user on a blockchain. 10. The system of claim 9, wherein
the user subscribes to insurance implemented by a smart contract stored on the blockchain;
A system further configured to update premiums paid by the user based on predetermined transactions to the smart contract. 11. The system of claim 10, further configured to effect payment of the insurance premium from the user in tokens based on a predetermined transaction to the smart contract. determining the movement status of the user based on the location information obtained from the user's terminal;
determining a mobility context score that influences a premium paid by the user based at least on results of the determination of the user's mobility context. The method, wherein the step of determining includes determining whether the user follows predetermined traffic rules. determining the movement status of the user based on the location information obtained from the user's terminal;
Determining a travel situation score that affects insurance premiums paid by the user based at least on results of the determination of the user's travel situation, the program causing a computer to determine the user's travel situation. The program, wherein the step includes determining whether the user follows predetermined traffic rules.

Images