JP2023114612A - 移動状況に基づき保険料に係る移動状況スコアを決定するためのシステム、方法及びプログラム - Google Patents

Abstract

【課題】フードデリバリーサービス配達員等に対し、交通ルールを含むルールを守ろうとするインセンティブが働くような保険を実施するためのシステム等を提供すること。【解決手段】ユーザの端末から取得した位置情報に基づき、前記ユーザの移動状況を判定し（２２０）、前記ユーザの移動状況の前記判定の結果に少なくとも基づき、前記ユーザが支払う保険料に影響を与える移動状況スコアを決定する（２４０）ように構成されたシステムであって、前記ユーザの移動状況の前記判定は、前記ユーザが所定の交通ルールに従っているか否かの判定を含む、システム。【選択図】図２

Description

本発明は、ユーザの移動状況に少なくとも基づき、該ユーザが支払う保険料に影響を与える移動状況スコアを決定することに関する。

近年、フードデリバリーサービス配達員の交通ルール違反が問題視されている。これにより配達員による事故発生のリスクが高まっており、通行人の人身安全にも影響が出てきている。また、配達員が事故を起こした場合、当該配達員だけでなく、サービス業者も責任が問われる場合がある。

本願の発明者は、配達員に交通ルールを守ろうとするインセンティブを与えるために、保険を活用できることに気付いた。保険に係る従来技術として、特許文献１には、概略、走行した経路の交通状況に基づき、利用者の保険条件を設定する情報処理装置が記載されている。

特許第６２６１６３６号

しかしながら、上記従来技術は、利用者の交通ルール違反を考慮していない。
本発明は以上に鑑みてなされたものであり、その課題は、フードデリバリーサービス配達員等に対し、交通ルールを含むルールを守ろうとするインセンティブが働くような保険を実施するためのシステム等を提供することである。

上記課題を解決するため、本発明の実施形態によれば、ユーザの端末から取得した位置情報に基づき、前記ユーザの移動状況を判定し、前記ユーザの移動状況の前記判定の結果に少なくとも基づき、前記ユーザが支払う保険料に影響を与える移動状況スコアを決定するように構成されたシステムであって、前記ユーザの移動状況の前記判定は、前記ユーザが所定の交通ルールに従っているか否かの判定を含む、システムが提供される。

一実施形態であるシステムは、前記ユーザが所定の交通ルールに従っているか否かを判定するために、前記ユーザの移動手段を特定するように更に構成されていてよい。
一実施形態において、前記移動手段は、軽車両と、原動機付き自転車と、自動二輪車とを含むことができる。

一実施形態において、前記ユーザは、複数のユーザから構成されるグループに属すことができ、一実施形態であるシステムは、前記ユーザについて決定された前記移動状況スコアと、前記ユーザ以外の前記グループに属する他の各ユーザについて決定された移動状況スコアとに基づき、前記ユーザが支払う前記保険料を決定するように更に構成されていてよい。

一実施形態であるシステムは、前記ユーザの活動地域と、前記ユーザの属性との一方又は双方に少なくとも基づき、前記ユーザからの所定のグループへの加入の可否を判定するように更に構成されていてよい。

一実施形態であるシステムには、交通ルールごとに、前記移動状況スコアを決定するための点数が予め記憶されていてよい。
一実施形態において、前記移動状況は移動ルートを含むことができ、前記ユーザの移動状況の前記判定は、前記ユーザが所定のルートを移動したか及び前記ユーザが所定のエリアを移動したかの一方又は双方の判定を更に含むことができる。

一実施形態であるシステムは、前記ユーザの前記端末から取得した前記位置情報に基づき、前記ユーザが所定の交通ルールの違反を構成する要件の少なくとも一部に該当することと、前記ユーザが所定のルートを外れていることと、前記ユーザが所定のエリア内にいることとのうちの少なくとも１つを判定した場合に、所定の音と、所定の振動と、所定の表示との少なくとも１つを含むアラートを発生させるよう前記ユーザの前記端末に指示するように更に構成されていてよい。

一実施形態であるシステムは、前記ユーザについて決定された前記移動状況スコアをブロックチェーンに記憶するように更に構成されていてよい。
一実施形態において、前記ユーザは前記ブロックチェーンに記憶されるスマート・コントラクトにより実施される保険に加入することができ、一実施形態であるシステムは、前記スマート・コントラクトに対する所定のトランザクションに基づき、前記ユーザが支払う保険料を更新するように更に構成されていてよい。

一実施形態であるシステムは、前記スマート・コントラクトに対する所定のトランザクションに基づき、トークンによる前記ユーザからの前記保険料の支払いを実行するように更に構成されていてよい。

上記課題を解決するため、本発明の実施形態によれば、ユーザの端末から取得した前記位置情報に基づき、前記ユーザの移動状況を判定するステップと、前記ユーザの移動状況の前記判定の結果に少なくとも基づき、前記ユーザが支払う保険料に影響を与える移動状況スコアを決定するステップとを含む、コンピュータが実行する方法であって、前記ユーザの移動状況を判定する前記ステップは、前記ユーザが所定の交通ルールに従っているか否かを判定するステップを含む、方法が提供される。

上記課題を解決するため、本発明の実施形態によれば、ユーザの端末から取得した前記位置情報に基づき、前記ユーザの移動状況を判定するステップと、前記ユーザの移動状況の前記判定の結果に少なくとも基づき、前記ユーザが支払う保険料に影響を与える移動状況スコアを決定するステップとをコンピュータに実行させるプログラムであって、前記ユーザの移動状況を判定する前記ステップは、前記ユーザが所定の交通ルールに従っているか否かを判定するステップを含む、プログラムが提供される。

本発明の一実施形態によれば、交通ルールに従っているか否かにより配達員が支払う保険料を変動させることができることから、配達員には交通ルールを守ろうというインセンティブが働き、ひいては事故削減が期待される。

また、本発明の一実施形態によれば、交通ルールを守ろうというインセンティブを、配達員のグループ単位で働かせることができる。
更に、本発明の一実施形態によれば、狭い路地等の事故が発生する可能性の高まるルートを回避しようとするインセンティブをも配達員に与えることができきる。

フードデリバリーサービスの場合、配達員は、自動車ではなく、軽車両や原動機付き自転車、自動二輪車等様々な移動手段を用いる可能性がある。本発明の一実施形態によれば、配達員が用いる移動手段の種類に応じて適切な処理を行うことができる。

近年、フードデリバリーサービス業者の増加に伴い、配達員が複数業者を利用することも多くなった。本発明の一実施形態によれば、ライバル業者を巻込んだ業界横断的な情報連携を可能とすることができる。

本発明の一実施形態である例示システムの概略を示すブロック図である。 例示システムに含まれるサーバが実行する処理のフローチャートである。 ユーザの移動状況を判定するための例示処理のフローチャートである。 逆行について説明するための図である。 車道側へのはみ出しについて説明するための図である。 ユーザの移動状況を判定するための例示処理のフローチャートである。 基準ルート及びペナルティ・エリアについて説明するための図である。 例示の保険加入及び成立処理のフローチャートである。 例示の保険料更新処理のフローチャートである。 例示の保険料収集処理のフローチャートである。 交通ルールに係る例示テーブルである。 交通ルールに係る例示テーブルである。 交通ルールに係る例示テーブルである。 コンピュータの例示のハードウエア構成に係る図である。

１ 本発明の実施形態
１－１ 例示システムの概要
本発明の一実施形態は、フードデリバリーサービスの配達員に対し、少なくとも交通ルールを守ろうというインセンティブを与えることが可能な保険を実施するためのシステムである。以下、配達員を「ユーザ」ともいう。なお、フードデリバリーサービスは本発明の適用例にすぎず、様々なサービスやビジネスのために本発明は用いることができることに留意されたい。

図１は、本発明の一実施形態である例示システム１００の概略を示すブロック図を示している。
１１０は、各配達員が携帯するユーザ端末を示している。ユーザ端末１１０は、測位機能を有する必要がある。測位機能は、米国のグローバル・ポジショニング・システム（ＧＰＳ）や日本の準天頂衛星システム（ＱＺＳＳ。使用する衛星の名前から「みちびき」と通称される。）、ヨーロッパのＧａｌｉｌｅｏ、ロシアのＧＬＯＮＡＳＳ、地上の無線基地局等を利用したものであってよいが、これらに限定されるわけではない。特に、本発明の一実施形態においては、ユーザ端末１１０は、精度の高い測位機能、例えば、配達員が道路を移動しているとき、その道路のどの辺りを移動しているか（複数車線のうちのどの車線なのか、また、その車線の左側なのか、中央なのか、右側なのか等）を判定可能な程度の精度を有する測位機能を有していることが好ましい。

ユーザ端末１１０は、配達員の私物である携帯情報端末、例えばスマートフォンに所定のアプリをインストールしたものであってよい。しかしながら、一般的なスマートフォンの測位機能、例えばＧＰＳや地上の無線基地局を利用したものはさほど精度がよくない。そのため、ユーザ端末１１０は、スマートフォン１１４と、より精度の高い例えばみちびきを利用した測位機能を有する外部デバイス（例えば、ＧＮＳＳ受信機）１１２とから構成されていてよい。スマートフォン１１４は、任意の接続技術、例えばＢｌｕｅｔｏｏｔｈ接続を介して測位結果を外部デバイス１１２から取得することができる。なお、後述する処理の少なくとも一部は、ＧＰＳや地上の無線基地局を利用した場合の精度の位置情報を用いても実施可能であるため、本発明は、一般的なスマートフォンのみからユーザ端末１１０が構成される実施形態を排除しているわけではないことに留意されたい。

ユーザ端末１１０は、定期的に又は不定期に繰り返し測位を実行し、自発的に又は要求に応じて、測位の結果を含む位置情報を後述するサーバ１２０に送信するように構成されている。この位置情報は、限定するわけではなく例示すると、ユーザ端末１１０を特定する情報と、測位により得られた緯度経度と、測位した時刻とを含んでいてよい。

１２０は、フードデリバリーサービスの業者（業者Ａ）が管理するサーバを示している。サーバ１２０は、任意の種類のコンピュータであってよい。
１３０は、サーバ１２０と通信するブロックチェーン・ノード群を示しており、１３０Ａ～１３０Ｄは、ブロックチェーン・ノード群１３０が含む各ブロックチェーン・ノードを示している。図１においてブロックチェーン・ノード群１３０が含むブロックチェーン・ノードは４つのみ表されているが、ブロックチェーン・ノード群１３０が含むブロックチェーン・ノードの数は、１以上の任意の数であってよく、好ましくは４以上の任意の数であってよい。ブロックチェーン・ノード１３０Ａ～１３０Ｄは、所定のブロックチェーン技術及び当該技術に基づくスマート・コントラクトを実施する機能を少なくとも有する任意の種類のコンピュータである。

１４０は、別の業者（業者Ｂ）が管理するサーバを示している。サーバ１４０は、任意の種類のコンピュータであってよい。業者Ｂは、フードデリバリーサービスの業者である場合もあれば、別の業種の業者である場合もある。なお、サーバ１４０に対しても、位置情報を送信する複数のユーザ端末（図示せず）が存在していてよい。また、サーバ１２０に位置情報を送信する複数のユーザ端末１１０と、サーバ１４０に位置情報を送信する複数のユーザ端末とは一部重複する場合がある。即ち、１つのユーザ端末は、サーバ１２０と１４０との双方に位置情報を送信する場合がある。これは、１人の配達員が複数の業者と契約する場合もあり得るためである。また、例示システム１００は、１以上の更に別の業者が管理するサーバ（図示せず）を含む場合があることに留意されたい。

なお、サーバ１２０及び１４０並びにブロックチェーン・ノード群１３０が含む各ブロックチェーン・ノードのうちの少なくとも１つは、１つの物理的なコンピュータではなく、１つの物理的なコンピュータ上で動作する１以上の仮想コンピュータのうちの１つ（例えば、いわゆるクラウド上に構築されたもの。）であり得ることに留意されたい。また、サーバ１２０及び１４０は、ブロックチェーン・ノード群１３０が含む１つのブロックチェーン・ノードとして機能してもよい。

また、ユーザ端末１１０とサーバ１２０との間、サーバ１２０及び１４０とブロックチェーン・ノード群１３０との間、ブロックチェーン・ノード群１３０が含む各ブロックチェーン・ノードの間には、ワイヤレス及び有線の一方又は双方により構築された、インターネットを含む１以上のネットワーク（図示せず）が存在し得ることに留意されたい。

１－２ 例示システムが実行する処理の概要
図２は、サーバ１２０が実行する例示処理２００のフローチャートである。なお、サーバ１４０も同様の処理を実行してよい。

２１０は、ユーザ端末１１０から位置情報を取得するステップを示している。サーバ１２０は、複数のユーザ端末の各々についてステップ２１０を実行してよい。サーバ１２０は、取得した位置情報を一時的に又は永続的に例えば自身の記憶装置に記憶してよい。

２２０は、取得した位置情報に基づき、ユーザ端末１１０を携帯している配達員即ちユーザの移動状況を判定するステップを示している。サーバ１２０は、ユーザ端末を携帯している複数のユーザの各々についてステップ２２０を実行してよい。なお、「位置情報に基づく」ことは、「位置情報の履歴に基づく」ことを含んでいてよい。これについては、以下同様である。

２３０は、所定の条件を満たしたかを判定するステップを示している。例えば、１回の例示処理２００は、ユーザの１回の配達に対応することができる。即ち、例示処理２００はユーザが配達を開始したときに開始されてよく、ステップ２３０における所定の条件は、当該配達が終了したことであってよい。なお、所定の条件を満たしたかの判定は、公知技術を含む任意の手法により行うことができる。所定の条件を満たしたと判定した場合、処理はステップ２４０に進み、そうでない場合、処理はステップ２１０に戻る。

２４０は、移動状況の判定の結果に基づき、ユーザの移動状況スコアを決定するステップを示している。ステップ２４０においては、複数回行われる移動状況の判定の全ての結果に基づき、ユーザの移動状況スコアを決定することができる。サーバ１２０は、上記複数のユーザの各々についてステップ２４０を実行してよい。なお、サーバ１２０は、移動状況スコアを、該移動状況スコアを決定したユーザに関連付けて、一時的に又は永続的に例えば自身の記憶装置に記憶してよい。あるいは、サーバ１２０は、適切なトランザクションをブロックチェーン・ノード群１３０のうちの少なくとも１つに送信することにより、移動状況スコアを、該移動状況スコアを決定したユーザのアカウント（後述する）に関連付けてブロックチェーンに記憶してもよい。

２５０は、移動状況スコアに基づき、ユーザが加入している保険に係る処理を実行するステップを示している。保険に係る処理は、保険の各加入者の保険料を更新するための処理や、保険の各加入者から保険料をトークン（代用通貨）にて収集するための処理等（後述する）の少なくとも一部を含んでいてよい。なお、トークンはいわゆる暗号資産（仮想通貨）であってもよいが、これに限定されるわけではない。

１－３ 移動状況の判定
ステップ２２０においては、様々な手法により、ユーザの移動状況を判定することができる。

１－３－１ 交通ルールに従っているかに係る判定
図３は、ユーザの移動状況を判定するステップ２２０が含むことのできる例示処理３００のフローチャートである。例示処理３００は、ユーザが交通ルールに従っているかに係るものである。

３１０は、ユーザの移動手段を特定するステップを示している。ユーザの移動手段の特定手法は任意である。例えば、予めユーザから申告され、サーバ１２０に該ユーザに関連付けて記憶された移動手段を該ユーザの移動手段として特定してよい。あるいは、例えば、ユーザ端末１１０から取得した位置情報に基づき、公知の手法により当該ユーザの移動手段を特定してよい。移動手段の例は、軽車両や原動機付き自転車、自動二輪車であるが、これらに限定されるわけではない。特定される移動手段は、徒歩を含んでいてもよい。また、特定される移動手段として、普通自転車（以下、単に「自転車」という。）と自転車以外の軽車両とを区別してもよい。

３２０は、ユーザが位置する道路の属性を特定するステップを示している。ユーザが位置する道路の属性の特定手法は任意である。ユーザが位置する道路の属性は、例えば、ユーザ端末１１０から取得した位置情報を、予め記憶されている電子地図データとマッピングすることにより特定することができる。なお、「道路の属性」は、関係する交通ルール及び後述する減点数を特定するための任意の情報であってよい。そのような情報は、例えば、車線数や対象とする移動手段（例えば、歩道、自転車歩道、自転車専用レーンのある道路の別）、センターラインがあるかないかを含んでいてよいが、これらに限定されるわけはない。

３３０は、所定の１以上の交通ルールから、関係する交通ルールを１つ選択するステップを示している。「関係する交通ルール」とは、ステップ３１０において特定された移動手段及びステップ３２０において特定された道路の属性に関係する交通ルールである。

３４０は、ユーザ端末１１０から取得した位置情報に基づき、選択した交通ルールの違反要件の少なくとも一部にユーザが該当するかを判定するステップを示している。ステップ３４０において、該当すると判定した場合、処理はステップ３５０に進み、そうでない場合、処理はステップ３６０に進む。

３５０は、所定の音と、所定の振動と、所定の表示との少なくとも１つを含むアラートを発生させるようユーザ端末１１０に指示するステップを示している。このアラートは、交通ルール違反及び事故を未然に防ぐことを目的として、当該目的が達成されるような態様で発生するよう構成されてよい。

３６０は、ユーザ端末１１０から取得した位置情報に基づき、選択した交通ルールの違反要件の全てにユーザが該当するかを判定するステップを示している。ステップ３６０において、該当すると判定した場合、処理はステップ３７０に進み、そうでない場合、処理はステップ３８０に進む。

３７０は、ユーザに関連付けられた減点を増加させるステップを示している。なお、ユーザに関連付けられた減点は、例示処理２００が開始されてから最初のステップ２２０の実行前に例えばゼロに初期化されていてよい。

サーバ１２０は、所定の１以上の交通ルールの違反要件及び対応する減点を増加させる量（以下、「減点数」という。）を例えばテーブルの形式で記憶しておくことができ、ステップ３３０は、テーブルの１つの行を選択するステップであることができる。図１１～図１３は、そのような例示のテーブル１１００～１３００をそれぞれ示している。

図１１の例示テーブル１１００は、交通ルールとして逆行に係る判定を行うためのものである。逆行について図４を参照して説明する。４００は、ある２車線の道路の模式図である。４１０はセンターラインを示しており、４２０は路肩を示しており、４３０は歩道を示している。道路交通法上、軽車両である自転車は、原則的には、４４０で示す方向に、４４０で示すセンターライン４１０の左側の車道の左側又は路肩を走行する必要がある。本実施形態においては、ユーザの移動手段が自転車であり且つ４００で示す道路を移動している場合に、ユーザが４４０で示す方向及び位置以外を２０ｍ以上走行しているときに、ユーザは逆行していると判定することができる。例示テーブル１１００の１行目は、この交通ルールに対応するものである。即ち、例示テーブル１１００の１行目は、ユーザの移動手段が自転車であり且つユーザが位置する道路の属性が４００で示す道路即ち２車線の道路である場合に関係するものであり、違反要件として「進行方向左車線の左端及び左の路肩以外を走行している」及びこの状態で「２０ｍ以上走行している」という２つの要件を示すものである。従って、例えば、ユーザが自転車で二車線の道路の「進行方向左車線の左端及び左の路肩以外を走行し」始めた場合に、ステップ３３０において例示テーブル１１００の１行目が選択されたときには、ステップ３４０において違反要件の少なくとも一部にユーザが該当すると判定され、事故を誘発する恐れがあるものとしてステップ３５０においてアラートが発生することになる。また、例えば、ユーザが自転車で二車線の道路の「進行方向左車線の左端及び左の路肩以外を」「２０ｍ以上走行し」てしまった場合に、ステップ３３０において例示テーブル１１００の１行目が選択されたときには、ステップ３４０において違反要件の少なくとも一部にユーザが該当すると判定され、事故を誘発する恐れがあるものとしてステップ３５０においてアラートが発生し、且つ、ステップ３６０において違反要件の全てにユーザが該当すると判定され、ユーザは逆行に係る交通ルールに違反しているとしてステップ３７０において減点が増加することになる。なお、このときにステップ３７０において増加する減点は、例示テーブル１１００の選択された行即ち１行目の「減点数」の列の値即ち１０点であってよい。

図１２の例示テーブル１２００は、交通ルールとして速度超過に係る判定を行うためのものである。即ち、例示テーブル１２００の１行目は、ユーザの移動手段が自転車であり且つユーザが位置する道路の属性が歩道である場合に関係するものであり、違反要件として「速度２５ｋｍ／ｈ以上で走行している」及びこの状態で「５秒以上走行している」という２つの要件を示すものである。従って、例えば、ユーザが自転車で歩道を「速度２５ｋｍ／ｈ以上で走行し」始めた場合に、ステップ３３０において例示テーブル１２００の１行目が選択されたときには、ステップ３４０において違反要件の少なくとも一部にユーザが該当すると判定され、事故を誘発する恐れがあるものとしてステップ３５０においてアラートが発生することになる。また、例えば、ユーザが自転車で歩道を「速度２５ｋｍ／ｈ以上で」「５秒以上走行し」てしまった場合に、ステップ３３０において例示テーブル１２００の１行目が選択されたときには、ステップ３４０において違反要件の少なくとも一部にユーザが該当すると判定され、事故を誘発する恐れがあるものとしてステップ３５０においてアラートが発生し、且つ、ステップ３６０において違反要件の全てにユーザが該当すると判定され、ユーザは速度超過に係る交通ルールに違反しているとしてステップ３７０において減点が増加することになる。なお、このときにステップ３７０において増加する減点は、例示テーブル１２００の選択された行即ち１行目の「減点数」の列の値即ち１５点であってよい。

図１３の例示テーブル１３００は、交通ルールとして車道側へのはみ出しに係る判定を行うためのものである。車道側へのはみ出しについて図５を参照して説明する。５００は、ある２車線の道路の模式図である。５１０は自転車レーンを示しており、５２０は停車している大型バス（例えば、全長１２．０ｍ、車幅２．５ｍ、車高３．５ｍ、乗車定員４５～６０人のもの。）を示している。自転車で５００によって示される道路を移動する場合、ユーザは原則的には進行方向左側の自転車レーン５１０を走行しなければならないが、大型バス５２０等により自転車レーン５１０が塞がれているときには、一時的に車道側にはみ出して走行する必要がある。例示テーブル１３００の１行目は、ユーザの移動手段が自転車であり且つユーザが位置する道路の属性が自転車レーンのある道路である場合に関係するものであり、違反要件として「車道側に４ｍ以上はみ出して走行している」（はみ出し幅５３０が４ｍ以上であること）、「３０ｋｍ／ｈ以上で走行している」及びこれら状態で「２０ｍ以上走行している」（走行距離５４０が２０ｍ以上であること）という３つの要件を示すものである。従って、例えば、ユーザが自転車で自転車レーンのある道路において「車道側に４ｍ以上はみ出して走行し」始めた場合、あるいは、「車道側に４ｍ以上はみ出して」「３０ｋｍ／ｈ以上で走行し」始めた場合に、ステップ３３０において例示テーブル１３００の１行目が選択されたときには、ステップ３４０において違反要件の少なくとも一部にユーザが該当すると判定され、事故を誘発する恐れがあるものとしてステップ３５０においてアラートが発生することになる。また、例えば、自転車で自転車レーンのある道路において「車道側に４ｍ以上はみ出して」「３０ｋｍ／ｈ以上で」「２０ｍ以上走行し」てしまった場合に、ステップ３３０において例示テーブル１３００の１行目が選択されたときには、ステップ３４０において違反要件の少なくとも一部にユーザが該当すると判定され、事故を誘発する恐れがあるものとしてステップ３５０においてアラートが発生し、且つ、ステップ３６０において違反要件の全てにユーザが該当すると判定され、ユーザは車道側へのはみ出しに係る交通ルールに違反しているとしてステップ３７０において減点が増加することになる。なお、このときにステップ３７０において増加する減点は、例示テーブル１３００の選択された行即ち１行目の「減点数」の列の値即ち５点であってよい。

図３に戻ると、３８０は、所定の１以上の交通ルールのうち、選択されていない関係する交通ルールは存在するかを判定するステップを示している。選択されていない関係する交通ルールが存在すると判定した場合、処理はステップ３３０に戻り、そうでない場合、例示処理３００は終了する。

なお、交通ルールは、法定されているもの、及び、法定されていないが常識的には守るべきルールとして予め定められたものの一方又は双方を含んでいてよい。
１－３－２ 移動ルートに係る判定
図６は、ユーザの移動状況を判定するステップ２２０が含むことのできる例示処理６００のフローチャートである。例示処理６００は、ユーザの移動ルートに係るものである。

６１０は、ユーザ端末１１０から取得した位置情報に基づき、ユーザが基準ルートから外れているかを判定するステップを示している。基準ルートから外れていると判定した場合、処理はステップ６２０に進み、そうでない場合、処理はステップ６５０に進む。６５０は、ユーザがペナルティ・エリア内にいるかを判定するステップを示している。ペナルティ・エリア内にいると判定した場合、処理はステップ６６０に進み、そうでない場合、例示処理６００は終了する。

ステップ６１０及び６５０について、図７を参照して説明する。７２０は基準ルートを示している。基準ルートは、交通量の少なさや道路の広さ等の交通事故を起こすリスクの低さに基づき予め定められてよい。７１０は、ユーザ端末１１０から取得した位置情報の履歴即ちユーザが移動したルートを示している。即ち、ステップ６１０は、基準ルート７２０とユーザが移動したルート７１０とが図７に示す関係である場合、ユーザがルート７１０を移動している間、ステップ６１０において、ユーザは基準ルートから外れていると判定されることになる。７３０はペナルティ・エリアを示している。ペナルティ・エリア７３０は交通事故を起こすリスクの高さに基づき予め定められてよい。即ち、ペナルティ・エリアとは、通学路や事故多発地帯を含む領域など、例示システム１００に登録されているリスクの高い領域を示し、遠回りしてでもそのエリアを避けるように例示システム１００から示されるもものであってよい。なお、ペナルティ・エリアは通過すべきでない領域として二次元的に定義される必要はなく、通過すべきでない道路や通過すべきでない交差点として定義されてもよい。ペナルティ・エリア７３０とユーザが移動したルート７１０とが図７に示す関係である場合、ユーザがペナルティ・エリア７３０内を移動している間、ステップ６５０において、ユーザはペナルティ・エリア内にいると判定されることになる。なお、基準ルート及びペナルティ・エリアは、サーバ１２０に予め記憶されていてよい。また、基準ルート及びペナルティ・エリアは、ユーザに予め知らせるために、ユーザが移動を開始する前にユーザ端末１１０において表示されてよい。従って、例示システム１００は、ユーザの配達開始地点と配達先が決定されることに応答して、推奨される例えば安全で歩行者に優しい道（基準ルート）を決定し、当該基準ルートを一般的なナビゲーション・システムと同様にナビゲーション・ルートとしてユーザに提示し、近隣のペナルティ・エリアをユーザに更に提示するよう構成されていてよい。

なお、ステップ６５０はステップ６１０の前に実行されてもよい。あるいは、ステップ６１０とステップ６５０とは並列的に実行されてもよい。また、ステップ６１０及び６５０における判定は、ユーザ端末１１０から取得した位置情報における誤差を考慮してなされるべきであることに留意されたい。

図６に戻ると、６２０は、所定の音と、所定の振動と、所定の表示との少なくとも１つを含むアラートを発生させるようユーザ端末１１０に指示するステップを示している。ステップ６２０は、ステップ３５０と同様のものであってよいが、異なる態様でアラートを発生させてよい。

６３０は、ユーザ端末１１０から取得した位置情報に基づき、ユーザが基準ルートから外れて所定時間経過したかを判定するステップを示している。基準ルートから外れて所定時間経過したと判定した場合、処理はステップ６４０に進み、そうでない場合、処理はステップ６５０に進む。

６４０は、ユーザに関連付けられた減点を増加させるステップを示している。減点数は任意であり、一定であってもよいし、ユーザの移動手段やユーザが位置する道路の属性等（交通事故を起こすリスクの高低等）に応じて変動させてもよい。また、減点数は予めサーバ１２０に記憶しておくことができる。

６６０は、所定の音と、所定の振動と、所定の表示との少なくとも１つを含むアラートを発生させるようユーザ端末１１０に指示するステップを示している。ステップ６６０は、ステップ３５０及びステップ６２０と同様のものであってよいが、異なる態様でアラートを発生させてよい。

６７０は、ユーザ端末１１０から取得した位置情報に基づき、ユーザがペナルティ・エリアに入って所定時間経過したかを判定するステップを示している。ペナルティ・エリアに入って所定時間経過したと判定した場合、処理はステップ６８０に進み、そうでない場合、例示処理６００は終了する。なお、ステップ６７０における「所定時間」は、ステップ６３０における「所定時間」と同一であっても異なっていてもよい。

６８０は、ユーザに関連付けられた減点を増加させるステップを示している。ステップ６８０は、ステップ６４０と同様のステップであってよいが、ステップ６８０における減点数は、ステップ６４０における減点数と同一であっても異なっていてもよい。

従って、例えば、ユーザが基準ルートを外れ始めたときには、ステップ６１０において基準ルートから外れていると判定され、事故を誘発する恐れがあるものとしてステップ６２０においてアラートが発生することになる。また、例えば、ユーザが基準ルートを外れて所定時間経過してしまったときには、ステップ６１０において基準ルートから外れていると判定され、事故を誘発する恐れがあるものとしてステップ６２０においてアラートが発生し、且つ、ステップ６３０において基準ルートから外れて所定時間経過したと判定され、ステップ６４０において減点が増加することになる。

更に、例えば、ユーザがペナルティ・エリアに入り始めたときには、ステップ６５０においてペナルティ・エリア内にいると判定され、事故を誘発する恐れがあるものとしてステップ６６０においてアラートが発生することになる。また、例えば、ユーザがペナルティ・エリアに入ってから所定時間経過してしまったときには、ステップ６５０においてペナルティ・エリア内にいると判定され、事故を誘発する恐れがあるものとしてステップ６６０においてアラートが発生し、且つ、ステップ６７０においてペナルティ・エリアに入ってから所定時間が経過したと判定され、ステップ６８０において減点が増加することになる。

１－４ 移動状況スコアの決定
ステップ２４０においては、予め定められた基準となる移動状況スコアに、ステップ２２０において得られた最終的な減点を反映させることにより、ユーザの移動状況スコアを決定してよい。

１－５ 保険に係る処理
本実施形態において、保険に係る処理は所定のブロックチェーン技術に基づくスマート・コントラクトを用いて実施することができる。

１－５－１ スマート・コントラクトに係る基本的な仕組み
以下、ブロックチェーン技術に基づくスマート・コントラクトに係る基本的な仕組みについて説明する。なお、以下の説明では、ブロックチェーン・ノードが実施するブロックチェーン技術としてイーサリアムに基づく技術を仮定しており、説明しない事項については、イーサリアムにおける事項を適用してよい。しかしながら、ブロックチェーン・ノードが実施するブロックチェーン技術は、これに限定されるわけではないことに留意されたい。また、ブロックチェーン技術は、分散台帳技術の１つである。本発明は、以下に説明する処理と類似の処理を実現可能な任意の分散台帳技術を用いて実施してよいことに留意されたい。例えば、本発明は分散台帳技術であるＣｏｒｄａに基づく技術を用いて実施することができる。Ｃｏｒｄａに基づく技術はブロックを生成しないが、以下に説明するスマート・コントラクトに類似の仕組みを有している。

ブロックチェーン・ノードは、いわゆるブロックチェーンを記憶する。ブロックチェーンは複数のブロックから構成されており、各ブロックには、最初のブロック（例えば、ジェネシス・ブロック）を除いて、ただ１つの親ブロックが定められている。

各ブロックは、スマート・コントラクトを含むことができる。スマート・コントラクトには、ブロックチェーン・ノードが実行すべき処理 と、ブロックチェーン・ノードが記憶すべき情報（例えば、ステートやイベント）とを少なくとも定義することができる。また、スマート・コントラクトは、実行すべき処理を各々が定義する１以上の部分（例えば、関数）を含むことができる。なお、実行すべき処理は、新たに記憶すべき情報の内容を記憶する処理、記憶すべき情報の内容を更新する処理、及び、要求に応答して記憶すべき情報の内容を返す処理を含むことができる。

各ブロックは、親ブロックが含むものに応じて一意に定まる情報（例えば、親ブロックのハッシュ値）、及び、当該ブロックが生成された時点において、ブロックチェーン・ノードが記憶すべき情報の内容に応じて一意に定まる情報（例えば、ステート・ルートやレシート・ルート）を含んでおり、あるブロックから最初のブロックまでの間の何れかのブロックが含むものや、当該何れかのブロックが生成された時点における記憶すべき情報の内容の改竄が矛盾を生じさせるようになっている。

ブロックチェーン・ノードは、トランザクションを受信すると、当該トランザクションの妥当性を検証する。このトランザクションは、スマート・コントラクトを生成するためのトランザクション（当該スマート・コントラクト自体を含む）と、スマート・コントラクトの部分に定義された処理を実行するためのトランザクション（処理に関するパラメータを含むことができる。）とを含むことができる。トランザクションの妥当性の検証に成功すると、ブロックチェーン・ノードは、当該トランザクション即ち妥当性のあるトランザクションを少なくとも１つの別のブロックチェーン・ノードに転送する。なお、ブロックチェーン・ノードは、妥当性のあるトランザクションを自ら生成し、少なくとも１つの別のブロックチェーン・ノードに転送することもある。また、スマート・コントラクトの部分に定義された処理は、トランザクションを介さずに（例えば、ｃａｌｌメソッドを介して）実行される場合もある。

ブロックチェーン・ノードは、妥当性のあるトランザクションを含むブロックの生成を試行する。この試行において、当該トランザクションがスマート・コントラクトを生成するためのものである場合に、当該スマート・コントラクトのアカウント及びそのアドレス（例えば、Ｃｏｎｔｒａｃｔ Ａｃｃｏｕｎｔ（ＣＡ）及びそのアドレス）を生成して、当該スマート・コントラクトに関連付ける。また、この試行において、当該トランザクションがスマート・コントラクトの部分に定義された処理を実行するためのものである場合に、ブロックチェーン・ノードは当該処理を実行する。ブロックの生成に成功すると、ブロックチェーン・ノードは、当該ブロックを、自身が記憶するブロックチェーンに追加し、少なくとも１つの別のブロックチェーン・ノードに転送する。また、ブロックの生成に成功すると、ブロックチェーン・ノードは、ブロックの生成の試行において記憶すべき情報の内容を更新する処理を実行した場合に、情報の更新された内容を記憶する。なお、ブロックの生成は、計算量的に困難な問題を解いたときに成功するような手法（例えば、プルーフ・オブ・ワークやプルーフ・オブ・ステークや各種の合意形成アルゴリズム）を用いて行われる。

ブロックチェーン・ノードは、ブロックを受信すると、当該ブロックの妥当性を検証する。この検証において、当該ブロックがスマート・コントラクトの部分に定義された処理を実行するためのトランザクションを含む場合に、ブロックチェーン・ノードが当該処理を実行する。ブロックの妥当性の検証に成功すると、ブロックチェーン・ノードは、当該ブロックを、自身が記憶するブロックチェーンに追加し、少なくとも１つの別のブロックチェーン・ノードに転送する。また、ブロックの妥当性の検証に成功すると、ブロックチェーン・ノードは、ブロックの妥当性の検証において記憶すべき情報の内容を更新する処理を実行した場合に、更新された情報の内容を記憶する。

以上に述べたような仕組みにより、ブロックチェーン・ノード群１４０が含む各ブロックチェーン・ノードにおいて、スマート・コントラクトの部分に定義された処理が実行され、情報の内容が記憶される。

１－５－２ 保険加入及び成立処理
図８は、保険に係る処理に含まれる、例示の保険加入及び成立処理８００のフローチャートである。保険加入処理は、ユーザが保険に加入するための処理である。保険成立処理は、保険の実施を開始するための処理である。

８１０は、ユーザ端末１１０が、該ユーザ端末１１０を使用しているユーザの、選択された保険への加入申し込みをサーバ１２０に送信するステップを示している。この加入申し込みは、当該ユーザを特定する情報と、選択された保険を特定する情報とを含むことができる。

８２０は、サーバ１２０が、ユーザの保険への加入申し込みを受信したときに、当該加入申し込みに基づき、当該ユーザの保険への加入可否を判定するための情報を取得するステップを示している。この情報は、当該ユーザの配達地域即ち活動地域と、当該ユーザの属性（例えば、現在の移動状況スコアや他のフードデリバリーサービスを含む配達員としての経験、走行距離、平均移動速度等）と、当該保険への加入条件とを含む。この情報は、サーバ１２０又はブロックチェーンに予め記憶されていてよい。あるいは、この情報の一部は、上記加入申し込みが含んでいてよい。なお、加入条件は、例えば、ユーザの活動地域が所定の地域であるという条件や、ユーザの属性が所定の属性である（例えば、移動状況スコアが所定値以上であることや、配達員として所定回数以上配達を行っていること）という条件であってよいが、これらに限定されるわけではない。

８３０は、サーバ１２０が、当該ユーザは当該保険への加入条件を満たしているかを判定するステップを示している。加入条件を満たしていると判定した場合、処理はステップ８４０に進み、そうでない場合、例示処理８００は終了する。なお、例示処理８００を終了する前に、ユーザ端末１１０に、当該保険への加入条件を満たしていないことを示すアラートを送信するステップ（図示せず）を実行してもよい。

８４０は、サーバ１２０が、当該保険の加入者として、当該ユーザを特定する情報を記憶するステップを示している。当該保険の複数の加入者は、１つのグループを形成することが理解されよう。

８５０は、サーバ１２０が、当該保険は成立したかを判定するステップを示している。成立したと判定した場合、処理はステップ８６０に進み、そうでない場合、例示処理８００は終了する。保険が成立する条件は任意であり、例えば、当該保険の現在の加入者数が、保険ごとに定めることのできる最低加入者数以上であるという条件であってよいが、これに限定されるわけではない。

８６０は、当該保険の実施を開始するために、当該保険を実施するためのスマート・コントラクト（以下、「保険コントラクト」という。）を生成するためのトランザクション（以下、「保険コントラクト生成トランザクション」という。）を生成するステップを示している。保険コントラクト生成トランザクションは、当該保険を実施するための各種処理を表す、ブロックチェーン・ノード上で実行可能な形式のプログラムを含むことができる。しかしながら、保険コントラクト生成トランザクションが含む情報は、これに限定されるわけではない。なお、上記プログラムには、当該保険についての情報が定義即ちハードコーディングされていてよい。ここで、保険についての情報は、当該保険グループの複数の加入者のアカウントを特定する情報等を含むことができる。

８７０は、サーバ１２０が、保険コントラクト生成トランザクションを、ブロックチェーン・ノード群１３０のうちの少なくとも１つのブロックチェーン・ノードに送信するステップを示している。

８８０は、ステップ８７０において送信されたトランザクションに基づき、上に説明した仕組みにより、あるブロックチェーン・ノードが、保険コントラクトを生成する処理を示している。なお、この処理は、保険コントラクトのアカウント及びそのアドレスを生成するステップ８８５を含み、生成されたアドレスはブロックチェーンに記憶されるために、ユーザ端末１１０及びサーバ１２０は、当該保険コントラクトのアカウントのアドレスをブロックチェーンから取得することが可能である。

なお、「アカウント」は、ブロックチェーン・ノード群１３０が実施するブロックチェーン技術において各主体（ユーザ、業者Ａ及び業者Ｂ並びにスマート・コントラクト等）に付与されるものであり、「アドレス」は、当該ブロックチェーン技術において各「アカウント」に割り当てられるものであり、「アカウント」及び当該「アカウント」が付与された主体を特定する情報のうちの１つとして用いることができるものである。

１－５－３ 保険料更新処理
図９は、保険に係る処理に含まれる、例示の保険料更新処理９００のフローチャートである。例示の保険料更新処理９００の少なくとも一部は、ステップ２５０において実行されるもの考えることができる。保険料更新処理９００は、保険の各加入者即ちユーザが支払う保険料を更新するための処理である。

９１０は、サーバ１２０が、保険コントラクトのうち、保険料更新処理に対応した部分（以下、「保険料更新関数」という。）をブロックチェーン・ノードに実行させるトランザクション（以下、「保険料更新トランザクション」）を生成するステップを示している。保険料更新トランザクションは、
当該保険コントラクトのアカウントのアドレスと、
保険料更新関数を特定する情報と
を含むことができるが、保険料更新トランザクションが含む情報は、これらに限定されるわけではない。

９２０は、サーバ１２０が、保険料更新トランザクションを、ブロックチェーン・ノード群１３０のうちの少なくとも１つのブロックチェーン・ノードに送信するステップを示している。

９３０は、ステップ９２０において送信されたトランザクションに基づいて、上に説明した仕組みにより、あるブロックチェーン・ノードが、保険料更新関数を実行することによって実行されるステップを示している。

９３５は、ステップ９３０が含む、当該保険の各加入者の保険料を更新する処理を示している。
ある加入者の保険料は、当該加入者の移動状況スコアに基づき更新されてよい。ある加入者の保険料は、例えば、当該加入者の移動状況スコアが小さいほど高くなるように更新されてよい。これは、当該加入者の移動状況スコアが小さいことは、当該加入者がルール（交通ルール、基準ルートに従うこと及びペナルティ・エリアに入らないことを含む。）の少なくとも一部を守らない傾向があり、従って、事故を起こす可能性が高いと考えられるためである。より具体的には、ある加入者の保険料は、例えば、当該加入者の移動状況スコアが所定の閾値より小さい場合には所定の基準保険料から増額した額となり、そうでない場合には所定の基準保険料から減額した額又は更新前と同額となるように更新されてよい。

あるいは、ある加入者の保険料は、当該加入者の移動状況スコアと、他の各加入者の移動状況スコアとに基づき更新されてよい。ある加入者の保険料は、例えば、自身を含む当該保険の加入者全ての移動状況スコアの平均値や最大値等が小さいほど高くなるように更新されてよい。より具体的には、ある加入者の保険料は、自身を含む当該保険の加入者全ての移動状況スコアの平均値や最大値等が所定の閾値より小さい場合には所定の基準保険料から増額した額となり、そうでない場合には所定の基準保険料から減額した額又は更新前と同額となるように更新されてよい。保険の加入者全て即ちグループ全体の移動状況スコアにより各加入者の保険料を更新することにより、保険料を下げよう即ちルールを守ろうとするインセンティブをグループ単位で働かせ得ることが理解されよう。

なお、所定の基準保険料及び各加入者の移動状況スコアは、ブロックチェーンから取得してよい。また、更新された保険料は、各加入者のアカウント及び当該保険コントラクトのアカウントに関連付けて、ブロックチェーンに記憶してよい。また、所定の基準保険料は、保険に加入した当初の加入者が支払う保険料であってよい。

１－５－４ 保険料収集処理
図１０は、保険に係る処理に含まれる、例示の保険料収集処理１０００のフローチャートである。例示の保険料収集処理１０００の少なくとも一部は、ステップ２５０において実行されるもの考えることができる。保険料収集処理１０００は、保険の各加入者から保険料をトークンにて収集するための処理である。

１０１０は、サーバ１２０が、保険コントラクトのうち、保険料収集処理に対応した部分（以下、「保険料収集関数」という。）をブロックチェーン・ノードに実行させるトランザクション（以下、「保険料収集トランザクション」という。）を生成するステップを示している。保険料収集トランザクションは、
当該保険コントラクトのアカウントのアドレスと、
保険料収集関数を特定する情報と
を含むことができるが、保険料収集トランザクションが含む情報は、これらに限定されるわけではない。

１０２０は、サーバ１２０が、保険料収集トランザクションを、ブロックチェーン・ノード群１３０のうちの少なくとも１つのブロックチェーン・ノードに送信するステップを示している。

１０３０は、ステップ１０２０において送信されたトランザクションに基づいて、上に説明した仕組みにより、あるブロックチェーン・ノードが、保険料収集関数を実行することによって実行されるステップを示している。

１０３５は、ステップ１０３０が含む、当該保険の各加入者から保険料をトークン（代用通貨）で収集する処理を示している。この処理は、各加入者のアカウントに基づき、ブロックチェーン・ノードから各加入者の保険料の額を取得するステップと、各加入者のアカウントから所定のアカウントへとトークンを送金するトランザクションを生成し、実行し、少なくとも１つの他のブロックチェーン・ノードに送信するステップとを含むことができる。

２ 本発明の別実施形態
本発明の別の実施形態は、コンピュータが上述したような処理を実行する方法である。
本発明のまた別の実施形態は、コンピュータに、上述したような処理を実行させるプログラムである。

３ コンピュータ
以下、本発明の一実施形態を実施するために用いることができるコンピュータのハードウエア構成の一例について説明する。

図１４は、コンピュータのハードウエア構成の一例を表している。同図に示すように、コンピュータ１４００は、ハードウエア資源として、主に、プロセッサ１４１０と、主記憶装置１４２０と、補助記憶装置１４３０と、入出力インターフェース１４４０と、通信インターフェース１４５０とを備えており、これらはアドレスバス、データバス、コントロールバス等を含むバスライン１４６０を介して相互に接続されている。なお、バスライン１４６０と各ハードウエア資源との間には適宜インターフェース回路（図示せず）が介在している場合もある。

プロセッサ１４１０は、ＣＰＵやマイクロプロセッサ等のコンピュータ全体又は少なくとも一部の制御を行うものである。なお、１つのコンピュータは複数のプロセッサ１４１０を含む場合がある。このような場合、以上の説明における「プロセッサ」は、複数のプロセッサ１４１０の総称であってもよい。

主記憶装置１４２０は、プロセッサ１４１０に対して作業領域を提供する、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）やＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の揮発性メモリである。

補助記憶装置１４３０は、ソフトウエアであるプログラム等やデータ等を格納する、ＨＤＤやＳＳＤ、フラッシュメモリ等の不揮発性メモリである。当該プログラムやデータ等は、任意の時点で補助記憶装置１４３０からバスライン１４６０を介して主記憶装置１４２０へとロードされる。補助記憶装置１４３０は、コンピュータ可読記憶媒体、非一時的コンピュータ可読記憶媒体、又は、コンピュータ判読可能な貯蔵媒体と呼ばれることがある。なお、プログラムは、プロセッサに所望の処理を実行させる命令を含むものである。

入出力インターフェース１４４０は、情報を提示すること及び情報の入力を受けることの一方又は双方を行うものであり、デジタル・カメラ、キーボード、マウス、ディスプレイ、タッチパネル・ディスプレイ、マイク、スピーカ、各種センサ等である。

通信インターフェース１４５０は、インターネットやローカル・エリア・ネットワーク（ＬＡＮ）の等うちの１以上から構成されたネットワーク１４５５と接続されるものであり、ネットワーク１４５５を介してデータを送受する。通信インターフェース１４５０とネットワーク１４５５とは、有線又は無線で接続されうる。通信インターフェース１４５０は、ネットワークに係る情報、例えば、Ｗｉ－Ｆｉのアクセスポイントに係る情報、通信キャリアの基地局に関する情報等も取得することがある。

上に例示したハードウエア資源とソフトウエアとの協働により、コンピュータ１４００は、所望の手段として機能し、所望のステップを実行し、所望の機能を実現させることできることは、当業者には明らかであろう。

４ むすび
以上、本発明の実施形態の幾つかの例を説明してきたが、これらは例示にすぎず、本発明の技術的範囲を限定するものではないことが理解されるべきである。説明した実施形態についても、本開示の趣旨及び範囲から逸脱することなく、変更、追加、改良などを適宜行うことができることが理解されるべきである。本発明の技術的範囲は、上述した実施形態のいずれによっても限定されるべきではなく、特許請求の範囲及びその均等物によってのみ規定されるべきである

１００…例示システム
１１０…ユーザ端末
１３０…ブロックチェーン・ノード群
２００…サーバが実行する例示処理
３００…ユーザの移動状況を判定するための例示処理（ユーザが交通ルールに従っているかに係る）
４００…２車線の道路
４１０…センターライン
４２０…路肩
４３０…歩道
４４０…軽車両である自転車が走行すべき方向及び位置
５００…２車線の道路
５１０…自転車レーン
５２０…大型バス
５３０…ユーザのはみ出し幅
５４０…ユーザの走行距離
６００…ユーザの移動状況を判定するための例示処理（ユーザの移動ルートに係る）
７１０…ユーザの移動ルート
７２０…基準ルート
７３０…ペナルティ・エリア
８００…例示の保険加入及び成立処理
９００…例示の保険料更新処理
１０００…例示の保険料収集処理
１１００…逆行に係る判定を行うための例示テーブル
１２００…速度超過に係る判定を行うための例示テーブル
１３００…車道側へのはみ出しに係る判定を行うための例示テーブル
１４５５…ネットワーク
１４６０…バスライン

Claims (13)

1. ユーザの端末から取得した位置情報に基づき、前記ユーザの移動状況を判定し、
   前記ユーザの移動状況の前記判定の結果に少なくとも基づき、前記ユーザが支払う保険料に影響を与える移動状況スコアを決定する
   ように構成されたシステムであって、前記ユーザの移動状況の前記判定は、前記ユーザが所定の交通ルールに従っているか否かの判定を含む、システム。
2. 請求項１に記載のシステムであって、前記ユーザが所定の交通ルールに従っているか否かを判定するために、前記ユーザの移動手段を特定するように更に構成されたシステム。
3. 請求項２に記載のシステムであって、前記移動手段は、軽車両と、原動機付き自転車と、自動二輪車とを含む、システム。
4. 請求項１から３のうちの何れか一項に記載のシステムであって、
   前記ユーザは、複数のユーザから構成されるグループに属し、
   前記システムは、前記ユーザについて決定された前記移動状況スコアと、前記ユーザ以外の前記グループに属する他の各ユーザについて決定された移動状況スコアとに基づき、前記ユーザが支払う前記保険料を決定するように更に構成された、
   システム。
5. 請求項４に記載のシステムであって、前記ユーザの活動地域と、前記ユーザの属性との一方又は双方に少なくとも基づき、前記ユーザからの所定のグループへの加入の可否を判定するように更に構成されたシステム。
6. 請求項１から５のうちの何れか一項に記載のシステムであって、交通ルールごとに、前記移動状況スコアを決定するための点数が予め記憶されたシステム。
7. 請求項１から６のうちの何れか一項に記載のシステムであって、
   前記移動状況は移動ルートを含み、
   前記ユーザの移動状況の前記判定は、前記ユーザが所定のルートを移動したか及び前記ユーザが所定のエリアを移動したかの一方又は双方の判定を更に含む、
   システム。
8. 請求項１から７のうちの何れか一項に記載のシステムであって、前記ユーザの前記端末から取得した前記位置情報に基づき、
   前記ユーザが所定の交通ルールの違反を構成する要件の少なくとも一部に該当することと、
   前記ユーザが所定のルートを外れていることと、
   前記ユーザが所定のエリア内にいることと
   のうちの少なくとも１つを判定した場合に、所定の音と、所定の振動と、所定の表示との少なくとも１つを含むアラートを発生させるよう前記ユーザの前記端末に指示するように更に構成されたシステム。
9. 請求項１から８のうちの何れか一項に記載のシステムであって、前記ユーザについて決定された前記移動状況スコアをブロックチェーンに記憶するように更に構成されたシステム。
10. 請求項９に記載のシステムであって、
    前記ユーザは前記ブロックチェーンに記憶されるスマート・コントラクトにより実施される保険に加入し、
    前記スマート・コントラクトに対する所定のトランザクションに基づき、前記ユーザが支払う保険料を更新するように更に構成された
    システム。
11. 請求項１０に記載のシステムであって、前記スマート・コントラクトに対する所定のトランザクションに基づき、トークンによる前記ユーザからの前記保険料の支払いを実行するように更に構成されたシステム。
12. ユーザの端末から取得した前記位置情報に基づき、前記ユーザの移動状況を判定するステップと、
    前記ユーザの移動状況の前記判定の結果に少なくとも基づき、前記ユーザが支払う保険料に影響を与える移動状況スコアを決定するステップと
    を含む、コンピュータが実行する方法であって、前記ユーザの移動状況を判定する前記ステップは、前記ユーザが所定の交通ルールに従っているか否かを判定するステップを含む、方法。
13. ユーザの端末から取得した前記位置情報に基づき、前記ユーザの移動状況を判定するステップと、
    前記ユーザの移動状況の前記判定の結果に少なくとも基づき、前記ユーザが支払う保険料に影響を与える移動状況スコアを決定するステップと
    をコンピュータに実行させるプログラムであって、前記ユーザの移動状況を判定する前記ステップは、前記ユーザが所定の交通ルールに従っているか否かを判定するステップを含む、プログラム。

Images