保険システム
【課題】携帯通信端末の購入手続と保険契約の申込手続とにおける重複した手続の無駄を防止する。
【解決手段】顧客３０が携帯電話会社６の窓口において、携帯電話の購入手続と保険契約の申込手続を行なって保険契約とセットとなっている携帯電話の購入手続を行なえば（２）、その手続において入力された顧客の個人情報等の所定の情報が携帯電話会社６の顧客データベースに登録されるとともに、保険会社１１にも送信され（３）、保険会社１１の顧客データベース１５にも登録される。
【解決手段】顧客３０が携帯電話会社６の窓口において、携帯電話の購入手続と保険契約の申込手続を行なって保険契約とセットとなっている携帯電話の購入手続を行なえば（２）、その手続において入力された顧客の個人情報等の所定の情報が携帯電話会社６の顧客データベースに登録されるとともに、保険会社１１にも送信され（３）、保険会社１１の顧客データベース１５にも登録される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、たとえば、交通傷害保険、賠償責任保険、あるいは携帯電話破損保険等の各種保険の契約をユーザが行なった場合に該保険契約をコンピュータを用いて管理する保険システムに関する。
【背景技術】
【０００２】
この種の保険システムにおいて、従来から一般的に知られているものに、たとえば、ユーザの所持する携帯電話等の携帯通信端末から保険契約についての保険制御信号が保険契約コンピュータに送信されてくれば、その送信されてきた保険制御信号に応答して、保険契約コンピュータが、保険契約の成立または終了あるいは保険契約に係る期間的条件を制御するものがあった（特許文献１）。
【０００３】
この特許文献１に記載のものは、携帯通信端末の位置または移動距離に関する情報信号を携帯通信端末から保険契約コンピュータへ送信し、保険契約コンピュータにおいて、その送信されてきた位置または移動距離に関わる情報信号に応答して保険契約に関わる金銭的条件を制御するように構成されていた。
【特許文献１】特開２００３−５０９１４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、この特許文献１に記載のものは、ユーザが携帯通信端末を購入した後、その携帯通信端末を事後的に保険契約に有効利用するものである。その結果、ユーザは、携帯通信端末の購入時に購入手続を行なった後、保険契約の申込時に申込手続を行なうこととなり、前後して両手続きを重複して行なわなければならない。その結果、ユーザ自身の住所氏名等の個人情報を両手続きで重複して提示しなければならないという無駄な手続作業を強いられるという不都合があった。
【０００５】
本発明は、係る実情に鑑み考え出されたものであり、その目的は、携帯通信端末の購入手続と保険契約の申込手続とにおける重複した手続の無駄を防止することである。
【課題を解決するための手段の具体例およびその効果】
【０００６】
次に、課題を解決するための手段の具体例を括弧書きで示すとともに、その効果を記載する。
【０００７】
（１） ユーザの保険契約（たとえば、交通傷害保険、賠償責任保険、携帯電話破損保険等の契約）をコンピュータ（たとえば、図１の顧客管理サーバ１３、Ｗｅｂサーバ１２、保険処理サーバ１０等）を用いて管理する保険システムであって、
ユーザによる保険契約の申込手続が行なわれた場合に該ユーザの個人情報（たとえば、図１の氏名、住所、電話番号等）および契約内容に関する情報（たとえば、図１の保険情報等）を登録する保険業務用サーバ（たとえば、図１の顧客管理サーバ１３、顧客データベース１５等）と、
ユーザによる携帯通信端末（たとえば、図１、図２の携帯電話１）の購入手続が行なわれた場合に、該ユーザの個人情報（たとえば、図１の氏名、住所、電話番号等）を、登録する携帯通信用サーバ（たとえば、図１の保険処理サーバ８、顧客データベース１０等）と、
前記携帯通信端末の購入手続と前記保険契約の申込手続とを行なうユーザが１回提示した個人情報を、前記保険業務用サーバと前記携帯通信用サーバとの両方に登録する個人情報登録手段（たとえば、図１２のＳ１４５〜Ｓ１４７、図８（ｂ）のＳ７０、Ｓ７１等）とを備えている。
【０００８】
このような構成によれば、携帯通信端末の購入手続と保険契約の申込手続とを行なうユーザが１回提示した個人情報が、保険業務用サーバと携帯通信用サーバとの両方に登録されるために、ユーザは、携帯通信端末の購入手続と保険契約の申込手続の両方で重複して自己の個人情報を提示する必要がなくなり、重複した手続による無駄を極力防止することができる。
【０００９】
（２） 前記携帯通信用サーバを運用する携帯通信端末会社（たとえば、図１の携帯電話会社６等）が、前記携帯通信端末の購入手続と前記保険契約の申込手続とを受付けたときに保険契約ユーザから支払われた当該保険契約の契約金を、前記保険業務用サーバを運用する保険会社との間で決済するための処理を行なう決済処理手段（たとえば、図９のＳ１００〜Ｓ１０４、図１３のＳ１６５〜Ｓ１６９等）をさらに備え、
該決済処理手段は、
前記保険業務用サーバに登録された保険契約ユーザの保険契約登録数を集計する保険会社側集計手段（たとえば、図９のＳ１００〜Ｓ１０４等）と、
前記携帯通信用サーバに登録された保険契約ユーザの保険契約登録数を集計する携帯通信端末会社側集計手段（たとえば、図１３のＳ１６５〜Ｓ１６９等）とを含む。
【００１０】
このような構成によれば、携帯通信端末の購入手続と保険契約の申込手続との両方が携帯通信端末会社で受付けられ、両手続の受付窓口を一本化することによりユーザの利便性が向上する。しかも、一本化された受付窓口である携帯通信端末会社に対してユーザが保険契約の契約金を支払い、携帯通信端末会社と保険会社との間でその保険契約金の決済を行なうにおいて保険業務用サーバに登録された保険契約ユーザの保険契約登録数が保険会社側集計手段により集計され、かつ、携帯通信用サーバに登録された保険契約ユーザの保険契約登録数が携帯通信端末会社側集計手段により集計されるために、両集計手段による集計結果を照合することにより間違った請求や不正請求による不適正な決済が行なわれることを極力防止することができる。
【００１１】
（３） ユーザが携帯通信端末を購入する際に、該ユーザが前記保険契約を希望し該保険契約の申込手続と携帯通信端末の購入手続とを行なった場合に、当該ユーザに提供される携帯通信端末（たとえば、図１、図２の携帯電話１）をさらに備え、
前記携帯通信端末は、当該携帯通信端末にメールアドレスを設定した際に該メールアドレスを自動的に前記保険業務用サーバへ送信する自動送信手段（たとえば、図５のＳ１３等）を備え、
前記保険業務用サーバは、
前記自動送信手段により前記メールアドレスが送信されてきた場合に（たとえば、図８（ｃ）のＳ７５でＹＥＳの場合に）、該メールアドレスの送信元のユーザが前記個人情報登録手段により個人情報が登録されている登録済ユーザであるか否か判定する登録判定手段（たとえば、図８（ｄ）のＳ８５〜Ｓ８８等）と、
該登録判定手段により登録済ユーザであると判定された場合に（たとえば、図８（ｄ）のＳ８６でＹＥＳと判定された場合に）該登録済ユーザの個人情報に対応させて前記送信されてきたメールアドレスを登録するメールアドレス登録手段（たとえば、図８（ｃ）のＳ７７、Ｓ７８等）と、
前記登録判定手段により登録済ユーザでないと判定された場合に（たとえば、図８（ｄ）のＳ８６でＮＯと判定された場合に）異常報知を行なう異常報知手段（たとえば、図８（ｃ）のＳ８０等）とを含む。
【００１２】
このような構成によれば、保険契約の申込手続と携帯通信端末の購入手続とを行なったユーザに提供される携帯通信端末に備えられた自動送信手段の働きにより、携帯通信端末にメールアドレスを設定した際にそのメールアドレスが自動的に保険業務用サーバへ送信されるために、メールアドレスの保険業務用サーバへの登録手続が自動的に行なわれ、ユーザの利便性が向上する。しかも、保険業務用サーバにおいては、送信されてきたメールアドレスの送信元のユーザの個人情報が既に登録されているか否か判定され、登録されていない場合には異常報知が行なわれるために、保険契約の申込手続が行なわれながらもその申込手続を行なったユーザの個人情報が保険業務用サーバに登録されていない異常、または、保険契約の申込手続を行なっていないユーザに対して自動送信手段を備えた携帯通信端末が販売された異常等の発生したことを、保険会社が認識することができる。
【００１３】
また、一本化された受付窓口である携帯通信端末会社に対してユーザが保険契約の契約金を支払い、携帯通信端末会社と保険会社との間でその保険契約金の決済を行なう場合においては、携帯通信端末会社から保険会社への決済申告に間違いまたは虚偽の申告があったとしても、保険契約の申込手続と携帯通信端末の購入手続とを行なったユーザの携帯通信端末にメールアドレスを設定した際にそのメールアドレスが自動的に保険業務用サーバへ送信されるために、そのメールアドレスの受信数のデータを基に、携帯通信端末会社からの申告数を検証することができ、携帯通信端末会社からの申告の間違いまたは虚偽申告の監視が可能となる。
【発明を実施するための最良の形態】
【００１４】
次に、本発明の実施の形態を図面に基づいて詳細に説明する。図１は、本発明に係る保険システムの全体の概略を示す構成図である。通信網の一例のインターネット５を通じて、携帯電話会社６のゲートウェイ７、保険会社１１のゲートウェイ１２、および、携帯電話網２のゲートウェイ４が接続されており、互いに情報の送受信ができるように構成されている。また、携帯電話網２には、基地局３が接続されており、携帯通信端末の一例の携帯電話１と基地局３との間で無線通信を行ない、その無線通信のデータが携帯電話網２、ゲートウェイ４、インターネット５を経由して、携帯電話会社６あるいは保険会社１１に送信される。さらに、携帯電話会社６あるいは保険会社１１からのデータが、インターネット５、ゲートウェイ４、携帯電話網２、基地局３を経由して携帯電話１に送信される。
【００１５】
携帯電話会社６には、前述のゲートウェイ７の他に、携帯電話１を利用した保険業務の処理を行なうための保険処理サーバ８と、その保険契約に加入した契約ユーザの顧客データを記憶している顧客データベース１０と、その他のサーバ９とが設けられている。
【００１６】
保険会社１１には、前述したゲートウェイ１２の他に、Ｗｅｂサーバ１４、Ｗｅｂデータベース１６、携帯電話１を利用した保険契約に加入した契約ユーザの顧客管理を行なうための顧客管理サーバ１３、その契約ユーザの顧客データを記憶している顧客データベース１５が、設けられている。
【００１７】
顧客データベース１５には、携帯電話１を利用した保険契約に加入した契約ユーザの所持する携帯電話１の端末ＩＤ（携帯電話固有の製造番号）、当該携帯電話のメールアドレス、契約ユーザの氏名、住所、電話番号、加入した保険の種類を特定する保険情報、事故請求データ等が記憶されている。なお、携帯電話１は、保険契約の申込手続および携帯電話の購入手続を行なったユーザにのみ販売される保険契約ユーザ専用の携帯電話であり、保険業務の運用の際にユーザの利便性を向上する支援機能が予め組込まれたものである。この携帯電話１の販売時点では、まだメールアドレスが設定されていないために、顧客データベース１５のメールアドレスの記憶エリアには、何らデータが記憶されていない。また事故請求データは、保険対象の事故（たとえば、交通事故、賠償責任事故、携帯電話破損事故等）が発生したときの保険金の支払請求に関するデータであり、事故が発生していなければ未だ発生していない旨の「なし」のデータが記憶されており、事故が発生して保険金の支払請求があった場合には、その事故の内容と請求内容と事故現場の状況のデータ（たとえば写真データ等）の、各種事故詳細データが記憶される。保険情報とは、契約ユーザが加入した保険の種類を特定する情報であり、たとえば、端末ＩＤ「８１４３１１」のユーザの場合には、交通傷害保険に加入しており、端末ＩＤが「７１０４３６」のユーザの場合には、傷害責任保険と交通傷害保険との両方に加入している。なお、「交通傷害保険」の場合には、交通事故で当該契約ユーザの所持している携帯電話が破損した場合には、その携帯電話の破損に対する保険金の支払を受けることができる。この交通傷害保険とは別に、交通事故以外の原因で携帯電話が破損した場合の補償として、携帯電話破損保険がある。
【００１８】
保険会社１１のＷｅｂデータベース１６には、契約ユーザのために用意されたＷｅｂサイトのページのデータが記憶されており、携帯電話１を用いてそのＷｅｂサイトのページにアクセスできるように構成されている。このＷｅｂサイトのページは、具体的には、保険対応窓口ページがあり、その保険対応窓口ページを入口として事故請求窓口ページまたは相談窓口ページにアクセスできるようになっている。事故請求窓口ページには、さらに、交通事故請求窓口ページ、賠償責任事故請求窓口ページ、携帯電話破損事故請求窓口ページがある。契約ユーザが保険に関する相談を保険会社１１に行ないたい場合には、携帯電話１を操作して保険会社１１のＷｅｂサイトのページにアクセスする。すると、まず保険対応窓口ページが表示され、その中から相談窓口を選択（クリック）することにより、相談窓口ページが携帯電話１に表示され、その相談窓口ページの所定箇所に相談事項を入力して送信することにより、保険会社１１がその相談事項の回答を追って携帯電話１に返信（メールによる返信等）する。
【００１９】
契約ユーザが自分の加入している保険の対象とする事故が発生した場合に、携帯電話１を操作して保険対応窓口ページにアクセスし、そこで事故請求窓口ページを選択して事故請求窓口ページにアクセスする。その事故請求窓口ページにおいて、発生した事故の種類により、交通事故請求窓口ページ、賠償責任事故請求窓口ページ、あるいは携帯電話破損事故請求窓口ページのいずれかにアクセスする。そして、アクセスした事故請求窓口ページが携帯電話１に表示され、その事故請求窓口ページの所定箇所に、所定事項を入力して保険会社１１に送信するとともに、携帯電話１のデジタルカメラ２６（図２参照）により事故現場の写真を撮り、その写真データを保険会社１１に送信する。
【００２０】
この事故請求窓口ページに入力されたデータおよび事故現場の写真データが、顧客データベース１５の事故請求データにおける対応する携帯ＩＤのエリアに格納される。
【００２１】
なお、携帯電話会社６の顧客データベース１０には、保険会社１１の顧客データベース１５の記憶データのうち、「事故請求データ」を除く各種データが記憶されている。
【００２２】
図２は、携帯電話１の機能ブロック図である。携帯電話１には、制御中枢としてのＣＰＵ（Central Processing Unit）等からなる制御部２２と、その制御部の制御動作を司るプログラムおよび各種データが記憶されたメモリ２３が設けられている。制御部２２は、メモリ２３に記憶されているデータやプログラムを読出して、所定の制御動作を実行するとともに、受信したデータを必要に応じてメモリ２３に記憶させる。
【００２３】
制御部２２には、無線部２１が接続されており、その無線部２１にはアンテナ２０が接続されている。また、制御部２２には、ユーザによって操作される操作部２４、受話部２５、デジタルカメラ２６、液晶等からなる表示部２７、送話部２８、サラウンダ２９が接続されている。ユーザが操作部２４を操作すればその操作信号が制御部２２に入力され、ユーザが発した音声が受話部２５から制御部２２に入力され、ユーザがデジタルカメラ２６で写真を撮るとその写真データが制御部２２に入力される。また、ユーザが操作部２４を操作してＷｅｂページにアクセスした場合には、そのＷｅｂページが表示部２７により表示される。他人から電話がかかってきた場合には、サラウンダ２９によりコール音が発せられ、操作部２４を操作して通話状態にした後、相手からの音声電波をアンテナ２０により受信して無線部２１、制御部２２を経由して送話部２８から相手側の音声が発せられる。
【００２４】
メモリ２３には、一般の携帯電話に必要な制御プログラムおよびデータが記憶されているが、この携帯電話１は、前述したように、保険契約に加入した保険契約ユーザ専用のカスタマイズされた携帯電話であり、保険業務の遂行の上でユーザに便利な機能を実現するためのプログラムやデータが予めメモリ２３に記憶されている。たとえば、後述する図５のＳ１３、図６のＳ２３等のプログラムが、メモリ２３に予め記憶されている。
【００２５】
図３は、携帯電話を利用するべく携帯電話の販売とセットとなっている保険システムの流れを説明するための説明図である。
【００２６】
まず、（１）において、携帯電話会社６から保険会社１１に、概算保険料（年間保険料）が支払われる。対象となる保険の種類は、前述したように、交通傷害保険、賠償責任保険、携帯電話破損保険の３種類があり、それぞれ、年間契約で１つの契約に対して契約金２０００円である。携帯電話会社６は、１年間における契約数を予測し、その予測した見込契約数に２０００円を乗じた概算保険料を予め保険会社１１に支払う。
【００２７】
次に、（２）において、顧客（契約者）３０が携帯電話会社６の窓口において、携帯電話の購入手続と保険契約の申込手続とを行なう。具体的には、１枚の携帯電話加入申込書（数枚写真様式）に、保険契約者および被保険者等の所定事項（個人情報）を記載し、保険同意事項を記入する。これにより、携帯電話の購入手続と保険契約の申込手続とが完了し、その顧客（契約者）３０に対して前述の携帯電話１が販売される。その販売された携帯電話１の端末ＩＤと顧客（契約者）３０が記入した内容とが、携帯電話会社６の社員により電子データとしてコンピュータに入力され、その入力データが携帯電話会社６の顧客データベース１０に登録される。それと同時に、その電子データが（３）において、保険会社１１にも送信され、保険会社１１の顧客データベース１５に登録される。
【００２８】
次に、顧客（契約者）３０は、新たに購入した携帯電話１に対し、メールアドレスを設定する。すると、その設定されたメールアドレスのデータが、（４）において、携帯電話会社６ばかりでなく保険会社１１にも自動送信される。この設定されたメールアドレスの送信に際しては、後述するように、携帯電話１の電話番号と端末ＩＤも併せて自動送信される。その結果、その送信されてきたデータを受けた携帯電話会社６および保険会社１１では、受信した端末ＩＤに基づいて顧客データベース１０、１５を検索し、対応する端末ＩＤのエリアにおけるメールアドレスの箇所に受信したメールアドレスを登録する。
【００２９】
次に、保険会社１１は、（５）において、顧客（契約者）３０の携帯電話１に対して、保険事故発生時等の保険対応窓口アドレス（ＵＲＬ）をダイレクトメールする。顧客（契約者）３０は、その受信した保険対応窓口アドレスを携帯電話１のメモリ（お気に入り）に記憶させる。
【００３０】
次に、保険事故が発生したときに、顧客（契約者）３０は、携帯電話１を操作して、（６）において、保険会社１１の保険対応窓口アドレスにアクセスし、Ｗｅｂページに示された所定の様式に所定事項を入力して送信する。たとえば、交通事故が発生した場合には、（６）−Ａにおいて、所定の様式への入力情報と交通事故現場でのデジタルカメラ２６による撮像データとが保険会社１１へ送信される。また、賠償責任保険事故が発生した場合には、（６）−Ｂにおいて、所定の様式への入力情報と破損した物のデジタルカメラ２６による撮像データとが、保険会社１１にメール送信される。
【００３１】
また、損害賠償責任事故の場合には、保険会社１１から被害者（物損賠償責任の相手）に対して電話での確認が行なわれその確認内容が保険審査に利用される。
【００３２】
次に、書類審査の結果、保険金を支払う場合には、（８）において、顧客（契約者）３０の銀行口座に保険会社１１から保険金の振込みが行なわれる。
【００３３】
次に、（９）において、携帯電話会社６と保険会社１１との間で、年度末の保険料精算の決済が行なわれる。これは、前述の（１）において、携帯電話会社６から保険会社１１に年間の契約見込数に対して２０００円を乗じた概算保険料の支払が行なわれており、その支払から１年後において年間の実際の申込数が確定するため、その実際の申込数に応じた契約金額のトータルと事前に支払っている概算保険料との精算を行なって決済を行なうものである。
【００３４】
図４は、携帯電話１のメモリ２３に記憶されているプログラムのフローチャートである。まず、ステップ（以下単に「Ｓ」という）１により、携帯電話１に対するメールアドレスの設定が行なわれたときのメールアドレス設定時処理が実行され、Ｓ２によりＷｅｂブラウザ処理が行なわれ、メールアドレスを変更設定したときのメールアドレス変更時処理が行なわれ、Ｓ４により、その他の処理が実行され、Ｓ１へ戻る。
【００３５】
図５は、図４のＳ１に示されたメールアドレス設定時処理の具体的制御内容を示すフローチャートである。Ｓ１０により、自己のメールアドレスの設定操作が行なわれたか否かの判断がなされ、行なわれていなければこのメールアドレス設定時処理が終了（リターン）するが、自己のメールアドレスの設定操作が行なわれた場合には、Ｓ１１に進み、その設定されたメールアドレスをメモリ２３に記憶する処理が行なわれる。
【００３６】
次にＳ１２に進み、登録要求信号とともに自己のメールアドレスと電話番号と端末ＩＤとを携帯電話会社６へ送信する処理が行なわれる。携帯電話会社６では、これを受けて、顧客データベース１０の対応するメールアドレスのエリアに送信されてきたメールアドレスを登録する処理を行なう。
【００３７】
次にＳ１３により、登録要求信号とともに自己のメールアドレスと電話番号と端末ＩＤとを保険会社１１へ送信する処理が行なわれる。これを受けた保険会社１１では、顧客データベース１５の対応するメールアドレスエリアに受信したメールアドレスを登録する処理を行なう。
【００３８】
次にＳ１４へ進み、保険対応窓口のアドレスを受信したか否かの判断がなされ、受信していなければＳ１５へ進み、不適正の認証結果を受信したか否かの判断がなされ、受信していなければＳ１４へ戻る。
【００３９】
登録要求信号とメールアドレスと電話番号と端末ＩＤとのデータを受信した保険会社１１の顧客管理サーバ１３では、その受信した端末ＩＤが顧客データベース１５に登録されている端末ＩＤであるか否かをチェックし、登録された端末ＩＤの場合には、Ｗｅｂデータベース１６の保険対応窓口ページのアドレス（ＵＲＬ）を携帯電話１に返信する。一方、受信した端末ＩＤが顧客データベース１５に登録されていなければ、保険契約手続を行なっていないユーザからメールアドレスが送信されてきたこととなり、異常判定して不適正の認証結果を携帯電話１に返信する。保険会社１１から保険対応窓口のアドレスが返信されてくれば、Ｓ１４によりＹＥＳの判断がなされてＳ１６へ進み、保険対応窓口のアドレスをメモリ２３へ登録する処理が行なわれる。一方、保険会社１１から前述した不適正の認証結果が返信されてくれば、Ｓ１５によりＹＥＳの判断がなされてＳ１７へ進み、不適正の表示が携帯電話１の表示部２７により行なわれ、このメールアドレス設定時処理が終了する。
【００４０】
図６は、図４のＳ３に示したメールアドレス変更時処理の具体的制御内容を示すフローチャートである。Ｓ２０により、メールアドレスの変更操作が行なわれたか否かの判断がなされ、行なわれていない場合にはこのメールアドレス変更時処理が終了する。ユーザが携帯電話１の操作部２４を操作して既に設定されているメールアドレスを他のメールアドレスに変更した場合には、Ｓ２０によりＹＥＳの判断がなされてＳ２１へ進み、自己のメールアドレスを変更された新たなメールアドレスに更新する処理が行なわれる。次にＳ２２により、メールアドレス変更信号とともに新メールアドレスと電話番号と端末ＩＤとを携帯電話会社６へ送信する処理が行なわれる。次にＳ２３により、メールアドレス変更信号とともに新メールアドレスと電話番号と端末ＩＤとを保険会社１１へ送信する処理が行なわれる。
【００４１】
携帯電話会社６および保険会社１１では、これを受けて、顧客データベース１０、１５の対応するメールアドレスエリアに記憶されているメールアドレスを新メールアドレスに更新する処理を行なう。
【００４２】
図７は、図４のＳ２に示したＷｅｂブラウザ処理の具体的制御内容を示すフローチャートである。まず、Ｓ２５により、ホームページへのアクセスがあったか否かの判断がなされ、ない場合にはこのＷｅｂブラウザ処理が終了する。ユーザが携帯電話１の操作部２４を操作して、Ｗｅｂ上のいずれかのホームページへのアクセス操作を行なった場合には、Ｓ２５によりＹＥＳの判断がなされてＳ２６へ進み、保険対応窓口へのアクセスであるか否かの判断がなされる。保険対応窓口へのアクセスでない場合にはＳ５６により、その他のＷｅｂブラウザ処理が実行されてこのＷｅｂブラウザ処理が終了する。一方、ユーザが保険会社１１の保険対応窓口ページのＵＲＬにアクセスした場合には、Ｓ２６によりＹＥＳの判断がなされてＳ２７へ進み、携帯電話１から端末ＩＤが保険会社１１へ送信される。保険会社１１は、後述するように、その受信した端末ＩＤに基づいて顧客データベース１５を検索し、対応する端末ＩＤが登録されているか否か判定し、登録されている場合には認証結果が適正な旨を返信し、登録されていなければ認証結果が不適正な旨を返信する。携帯電話１では、端末ＩＤの送信を行なった後、Ｓ２７により、認証結果の返信があったか否かを判断し、あるまで待機する。そして、保険会社１１からの認証結果の返信があれば、制御がＳ２９へ進み、その返信結果が適正であるか否かの判断が行なわれる。不適正であった場合には、Ｓ３０に進み、不適正表示が表示部２７によりなされて、このＷｅｂブラウザ処理が終了する。一方、返信された認証結果が適正であった場合には、制御がＳ３１へ進み、保険対応窓口ページが表示部２７により表示される。
【００４３】
その保険対応窓口ページを見たユーザは、事故請求窓口ページまたは相談窓口ページのいずれにアクセスするか、さらにはキャンセルするかの操作を、操作部２４により行なう。携帯電話１では、Ｓ３２により、事故請求窓口へのアクセス操作が行なわれたか否かの判断がなされ、未だアクセス操作がなされていなければＳ３３により、相談窓口へのアクセス操作が行なわれたか否かの判断がなされ、未だにアクセス操作がなされていなければＳ３４により、キャンセル操作が行なわれたか否かの判断がなされ、未だにキャンセル操作が行なわれていない場合にはＳ３３に戻る。このＳ３２→Ｓ３３→Ｓ３４→Ｓ３２のループの巡回途中で、ユーザがキャンセル操作を行なえばＳ３４によりＹＥＳの判断がなされてこのＷｅｂブラウザ処理が終了する。一方、ユーザが相談窓口へのアクセス操作を行なえばＳ３３によりＹＥＳの判断がなされてＳ５４へ進み、相談窓口ページが表示部２７により表示され、Ｓ５５により、相談受付処理が行なわれてこのＷｅｂブラウザ処理が終了する。さらに、事故請求窓口へのアクセス操作が行なわれた場合には、Ｓ３２によりＹＥＳの判断がなされてＳ３５へ進み、事故請求窓口のページが表示部２７により表示される。
【００４４】
次に、携帯電話１の制御部２２は、Ｓ３６により交通事故の選択操作があったか否かの判断がなされ、未だに交通事故の選択操作がない場合にはＳ３７へ進み、損害賠償責任事故の選択操作があったか否かの判断がなされ、未だにない場合にはＳ５４ａへ進み、携帯電話破損事故の選択操作があったか否かの判断がなされ、未だにない場合にはＳ３８へ進み、キャンセル操作があったか否かの判断がなされ、未だにない場合にはＳ３６へ戻る。
【００４５】
このＳ３６→Ｓ３７→Ｓ５４→Ｓ３８→Ｓ３６のループの巡回途中で、ユーザがキャンセル操作を行なえば、Ｓ３８によりＹＥＳの判断がなされてＷｅｂブラウザ処理が終了する。また、ユーザが交通事故の選択操作を行なえば、Ｓ３６によりＹＥＳの判断がなされてＳ３９へ進み、交通事故時記入ページ（交通事故請求窓口ページ）が表示部２７により表示される。一方、ユーザが賠償責任事故の選択操作を行なえば、Ｓ３７によりＹＥＳの判断がなされてＳ４０へ進み、賠償責任事故時記入ページ（賠償責任事故請求窓口ページ）が表示部２７により表示される。さらに、ユーザが携帯電話破損事故の選択操作を行なえば、Ｓ５４によりＹＥＳの判断がなされて図１１のＳ２００に進み、携帯電話破損事故時記入ページ（携帯電話破損事故請求窓口ページ）が表示部２７により表示される。なお、この携帯電話破損事故の場合は、たとえば通話機能が破損しＷｅｂサイトへのアクセスおよび通信機能が破損されていない場合に、その携帯電話１による前述のＳ５４ａ、Ｓ２００〜Ｓ２０４のオンライン制御が可能となる。Ｗｅｂサイトへのアクセスや通信機能が破損している場合には、オンライン制御が不可能であり、郵送等を利用したオフラインによる請求手続き、または、他の通信機器を利用してのオンラインによる請求手続きを行なうこととなる。
【００４６】
Ｓ３９による、交通事故時記入ページの表示がなされた後、Ｓ４７に進み、所定事項の記入が完了したか否かの判断がなされ、未だ完了していない場合にはＳ４８に進み、キャンセル操作が行なわれたか否かの判断がなされ、未だキャンセル操作が行なわれていない場合にはＳ４７へ戻る。ユーザは、表示部２７に表示された交通事故時記入ページを見て、操作部２４を操作して所定事項を記入するか、あるいはキャンセル操作を行なう。キャンセル操作を行なった場合には、Ｓ４８によりＹＥＳの判断がなされてＷｅｂブラウザ処理が終了する。一方、所定事項の記入を行なって完了操作が行なわれた場合には、Ｓ４７によりＹＥＳの判断がなされてＳ４９へ進み、事故現場の写真添付のメッセージ表示が表示部２７により行なわれる。
【００４７】
次にＳ５０へ進み、事故現場の写真の添付があったか否かの判断がなされ、未だにない場合にはＳ５１へ進み、キャンセル操作があったか否かの判断がなされ、未だにない場合にはＳ５０へ戻る。ユーザがキャンセル操作を行なえば、Ｓ５１によりＹＥＳの判断がなされてＷｅｂブラウザ処理が終了する。一方、ユーザがデジタルカメラ２６により事故現場の写真を撮りその撮像データを添付すれば、Ｓ５０によりＹＥＳの判断がなされてＳ５２へ進み、記入事項と添付された写真データとを保険会社１１のＷｅｂサーバ１４へ送信する処理が行なわれる。
【００４８】
次にＳ５３へ進み、携帯電話１に備えられているＧＰＳ機能（測位機能）により現在位置を特定して、その現在位置データを保険会社１１のＷｅｂサーバ１４へ送信する処理が行なわれて、このＷｅｂブラウザ処理が終了する。
【００４９】
一方、Ｓ４０による、賠償責任事故時記入ページが表示された後、Ｓ４１により、所定事項の記入が完了したか否かの判断がなされ、未だ完了していない場合にはＳ４２により、キャンセル操作が行なわれたか否かの判断がなされ、未だ操作されていない場合にはＳ４１へ戻る。ユーザがキャンセル操作を行なえば、Ｓ４２によりＹＥＳの判断がなされてこのＷｅｂブラウザ処理が終了する。一方、表示部２７に表示された賠償責任事故時記入ページを見てユーザが所定事項を入力し完了操作を行なえば、Ｓ４１によりＹＥＳの判断がなされてＳ４３へ進み、破損物の写真を添付するメッセージ表示が表示部２７により行なわれる。
【００５０】
次にＳ４４へ進み、破損物の写真の添付があったか否かの判断がなされ、未だにない場合にはＳ４５に進み、キャンセル操作があったか否かの判断がなされ、未だにない場合にはＳ４４へ戻る。ユーザがキャンセル操作を行なえば、Ｓ４５によりＹＥＳの判断がなされてこのＷｅｂブラウザ処理が終了する。一方、ユーザがデジタルカメラ２６により破損物の写真を撮りその撮像データを添付した場合には、Ｓ４４によりＹＥＳの判断がなされてＳ４６へ進み、記入事項と添付された写真データとを保険会社１１のＷｅｂサーバ１４へ送信する処理が行なわれ、Ｓ５３によるＧＰＳ機能により現在位置を特定して送信する処理が行なわれる。
【００５１】
図１１（ｂ）のＳ２００による、携帯電話破損事故時記入ページの表示が行なわれた後、Ｓ２０１により、所定事項の記入が完了したか否かの判断がなされ、未だ完了していない場合にはＳ２０２へ進み、キャンセル操作があったか否かの判断がなされ、未だない場合にはＳ２０１へ戻る。ユーザがキャンセル操作を行なえば、Ｓ２０２によりＹＥＳの判断がなされてこのＷｅｂブラウザ処理が終了する。一方、ユーザが操作部２４を操作して所定事項の記入を行ない完了操作を行なえば、Ｓ２０１によりＹＥＳの判断がなされてＳ２０３へ進み、その記入された記入事項データを保険会社１１のＷｅｂサーバ１４へ送信する処理が行なわれる。
【００５２】
次にＳ２０４へ進み、携帯電話１に備えられているＧＰＳ機能により現在位置を特定してその現在位置データを保険会社１１のＷｅｂサーバ１４へ送信する処理が行なわれて、このＷｅｂブラウザ処理が終了する。
【００５３】
図８、図９は、顧客管理サーバ１３の制御動作を示すフローチャートである。
まず、図８（ａ）を参照して、Ｓ６０により、保険契約の申込時に行なわれる申込時処理が実行され、Ｓ６１により、メールアドレス受信時処理が行なわれ、Ｓ６２により、メールアドレス変更受信時処理が行なわれ、Ｓ６３により、認証依頼があったか否かの判断がなされ、ない場合にはＳ６５に進むが、あった場合にはＳ６４により、認証処理が行なわれ、次にＳ６５により、事故請求登録処理が行なわれ、Ｓ６６により、年度末精算処理が行なわれてＳ６０へ戻る。
【００５４】
図８（ｂ）は、Ｓ６０に示した申込時処理の具体的制御内容を示すフローチャートである。Ｓ７０により、保険契約の申込手続が行なわれた際に携帯電話会社から送信されてくる申込書データの受信があったか否かの判断がなされ、ない場合にはこの申込時処理が終了する。一方、申込書データの受信があった場合には、Ｓ７１に進み、その申込書データに基づいて、顧客データベース１５に、メールアドレス以外の個人データ（端末ＩＤ、氏名、住所、電話番号、保険情報）を登録する処理が行なわれる。
【００５５】
図８（ｃ）は、Ｓ６１に示したメールアドレス受信時処理の具体的制御内容を示すフローチャートである。Ｓ７５により、登録要求信号を受信したか否かの判断がなされ、受信していない場合にはこのメールアドレス受信時処理が終了する。図５のＳ１３に従って携帯電話１から登録要求信号が送信されてくれば、Ｓ７５によりＹＥＳの判断がなされてＳ７６へ進み、認証処理が行なわれる。この認証処理の具体的制御内容は、図８（ｄ）のフローチャートに示されている。図８（ｄ）のフローチャートは、前述のＳ６４に示された認証処理の具体的制御内容のフローチャートでもある。
【００５６】
図８（ｄ）を参照して、Ｓ８５により、受信した端末ＩＤと電話番号とに基づいて顧客データベース１５を検索する処理が行なわれる。そしてＳ８６により、該当する顧客の個人データが顧客データベース１５に登録されているか否かの判断が行なわれる。顧客データベース１５には、保険契約手続を行なって保険に加入している契約ユーザの個人データ等が登録されており、受信した端末ＩＤが顧客データベース１５に登録されている契約ユーザの携帯電話であるか否かの判断が、このＳ８６により行なわれる。そして、該当する顧客の個人データが登録されている場合には、Ｓ８７に進み、適正認証結果を返信する処理が行なわれる。一方、該当する顧客の個人データがない場合には、Ｓ８８により、不適正認証結果を返信する処理が行なわれて、この認証処理を終了（リターン）する。Ｓ８７、Ｓ８８による認証結果の返信先は、Ｓ３６によるＷｅｂサーバ１４からの認証依頼があったときにはその認証依頼元であるＷｅｂサーバ１４であり、その他の図８（ｃ）、図９（ａ）等のフローチャートで行なわれる場合には、登録要求信号やメールアドレス変更信号を送信してきた携帯電話１である。
【００５７】
Ｓ７６の認証処理の次に、Ｓ７７により、その認証処理の結果が適正であったか否かの判断がなされる。適正であった場合には、Ｓ７８へ進み、受信したメールアドレスを顧客データベース１５内の対応するエリアに記憶する処理が行なわれ、Ｓ７９により、保険対応窓口アドレス（ＵＲＬ）を携帯電話１に返信する処理が行なわれて、このメールアドレス受信時処理が終了する。この保険対応窓口アドレスの返信を受けた携帯電話１では、前述の図５のＳ１４によりＹＥＳの判断がなされ、Ｓ１６による、保険対応窓口のアドレスを登録する処理が行なわれる。
【００５８】
一方、認証結果が不適正であった場合には、Ｓ７７によりＮＯの判断がなされてＳ８０へ進み、受信した端末ＩＤと未登録異常メッセージとを顧客管理サーバ１３により表示する処理が行なわれる。この表示を見た保険会社１１の社員は、未登録の異常が発生したことを認識することができる。この未登録異常の発生原因は、主に２つのことが考えられる。まず第１に、保険契約手続を行なっていないユーザに対して、メール設定時のメール自動送信機能（Ｓ１３）が組込まれた契約ユーザ専用の携帯電話１が販売されたことが考えられる。この場合には、契約ユーザ以外のユーザの携帯電話から登録要求信号が送信されてくるために、当然顧客データベース１５には対応する個人情報が登録されておらず、未登録異常メッセージが表示されることとなる。
【００５９】
第２に、保険契約を行なった契約ユーザに対して契約ユーザ専用の携帯電話１が販売されたが、その契約ユーザの契約申込時の個人情報等が、携帯電話会社６から保険会社１１に送信されて来なかった場合が考えられる。これは、図３の（９）で説明したように、年度末に携帯電話会社６と保険会社１１との間で保険契約金の決済を行なう関係上、携帯電話会社６が保険契約の申込数を実際よりも少なく保険会社１１に申告して年末決済時に過小申告分に相当する保険契約金を不正に携帯電話会社６が入手するという、不正行為が考えられる。このような過小申告による不正行為が発生した場合にも、未登録異常メッセージが表示されることにより、保険会社１１の従業員がその異常に気づき、携帯電話会社６に対してその真相を究明することが可能となる。この過小申告の異常は、契約ユーザに販売された契約ユーザ専用の携帯電話１からメールアドレス設定時に登録要求信号が自動的に保険会社１１の顧客管理サーバ１３へ送信されてくることにより発覚するのであり、これは、顧客ユーザ専用の携帯電話１から携帯電話会社６を経由することなく直接保険会社１１の顧客管理サーバ１３へ自動的に送信されてくるものであるために、過小申告を行なおうとする携帯電話会社６がその自動送信を阻止する術がない。よって、携帯電話会社６による過小申告の不正行為を抑止する効果が期待できる。
【００６０】
この過小申告の不正行為を抑止の効果をより確実にするために、図５のＳ１３により、加入契約した保険の数（たとえば端末ＩＤが７１０４３６では「２」）を併せて送信し、顧客データベース１５内の該当する顧客の保険情報の保険の数をも、Ｓ１５１で認証チェックするようにしてもよい。
【００６１】
また、過小申告の不正行為を抑止の効果のみのためであれば、自動送信する対象は、契約ユーザの設定したメールの自動送信に限らず、契約ユーザが購入した携帯電話１を操作（たとえば購入後初回の電話等）したときに何らかの情報（たとえば１人契約加入した旨の情報や加入契約数情報等）を自動送信するようにしてもよい。
【００６２】
図９（ａ）は、Ｓ６２のメールアドレス変更受信時処理の具体的制御内容を示すフローチャートである。Ｓ９０により、メールアドレス変更信号を受信したか否かの判断がなされ、受信していない場合にはこのメールアドレス変更受信時処理が終了する。一方、図６のＳ２３に従って携帯電話１からメールアドレス変更信号とともに新メールアドレスと電話番号と端末ＩＤとが送信されてくれば、Ｓ９０によりＹＥＳの判断がなされ、Ｓ９１により、前述の認証処理が行なわれる。
【００６３】
そして、Ｓ９２により、認証処理の結果が適正であったか否かの判断が行なわれる。適正の場合には、Ｓ９３へ進み、受信した新メールアドレスを顧客データベース１５内の対応するエリアに記憶する処理が行なわれる。一方、認証処理の結果が不適正であった場合には、Ｓ９４へ進み、受信した端末ＩＤと未登録異常メッセージとを顧客管理サーバ１３により表示する処理が行なわれる。
【００６４】
図９（ｂ）は、Ｓ６５の事故請求登録処理の具体的制御内容を示すフローチャートである。Ｓ９５により、事故請求登録要求があったか否かの判断がなされ、ない場合にはこの事故請求登録処理が終了する。一方、Ｓ４６、Ｓ５２、Ｓ５３、Ｓ２０３、Ｓ２０４に従って携帯電話１から事故請求時における記入事項データや撮像データ等がＷｅｂサーバ１４へ送信され、Ｗｅｂサーバ１４において後述する図１１（ａ）のＳ１３７に従って事故請求登録要求と受信した記入事項データと現在位置と端末ＩＤのデータが顧客管理サーバ１３へ送信する処理が行なわれれば、Ｓ９５によりＹＥＳの判断がなされてＳ９６へ進む。Ｓ９６では、受信した端末ＩＤに基づいて顧客データベース１５を検索し、対応するエリアに事故請求データを記憶する処理が行なわれる。
【００６５】
図９（ｃ）は、Ｓ６６の年度末精算処理の具体的制御内容を示すフローチャートである。Ｓ１００により、年度末精算操作があったか否かの判断がなされ、ない場合にはこの年度末精算が終了する。保険会社１１の従業員が顧客管理サーバ１３を操作して年度末精算操作を行なえば、Ｓ１００によりＹＥＳの判断がなされてＳ１０１へ進み、顧客データベースをチェックして今年度の保険契約の申込数を算出集計する処理が行なわれる。たとえば、図１の顧客データベース１５に記憶されている端末ＩＤが７１０４３６のユーザの場合には、１人で２つの保険（賠償責任保険と交通傷害保険）に加入しているために、１人でありながら契約数を「２」とカウントする。次にＳ１０２へ進み、申込数×２０００円を算出して、今年度の契約金額を求める処理が行なわれる。次にＳ１０３へ進み、今年度契約金額−受取概算保険料（図３（１）に従って携帯電話会社６から払い込まれた概算保険料支払額）の計算を行ない、収支を算出する処理が行なわれる。そして、Ｓ１０４により、その算出された収支を顧客管理サーバ１３により表示する処理が行なわれる。この収支の値がプラスの場合には、そのプラスの収支金額だけ、携帯電話会社６に請求することとなる。逆に、収支がマイナスの値の場合には、そのマイナスの収支金額を保険会社１１が携帯電話会社６へ支払うこととなる。
【００６６】
図１０は、Ｗｅｂサーバ１６の制御動作を示すフローチャートである。まずＳ１１０により、携帯電話１から保険会社１１のホームページにアクセスがあったか否かの判断がなされ、ない場合にはこのＷｅｂサーバの処理が終了する。一方、ユーザが携帯電話１を操作してホームページにアクセスした場合には、制御がＳ１１１へ進み、保険対応窓口へのアクセスであるか否かの判断が行なわれる。保険対応窓口へのアクセスでない場合には、その他のＷｅｂサーバ処理がＳ１１２により行なわれ、その後Ｗｅｂサーバの処理が終了する。一方、ユーザが携帯電話１を操作して保険対応窓口にアクセスした場合には、Ｓ１１１によりＹＥＳの判断がなされてＳ１１３へ進み、端末ＩＤを受信したか否かの判断が行なわれ、受信するまで待機する。携帯電話１では、前述の図７のＳ２７で説明したように、保険対応窓口にアクセスした後そのアクセスした携帯電話１の端末ＩＤを自動送信する処理が行なわれるのであり、携帯電話１から端末ＩＤが送信されてくれば、Ｓ１１３によりＹＥＳの判断がなされてＳ１１４へ進み、認証依頼を顧客管理サーバ１３へ出す処理が行なわれる。
【００６７】
その後、Ｓ１１５により、適正認証結果を受信したか否かの判断がなされ、未だ受信していない場合にはＳ１１６へ進み、不適正認証結果を受信したか否かの判断がなされ、未だ受信していない場合にはＳ１１５へ戻る。認証依頼を受けた顧客管理サーバ１３では、前述のＳ６３によりＹＥＳの判断がなされてＳ６４による認証処理が実行され、Ｓ８７による適正認証結果の返信またはＳ８８による不適正認証結果の返信を行なう。不適正認証結果の返信が行なわれてくれば、Ｓ１１６によりＹＥＳの判断がなされてＳ１２４へ進み、不適正認証結果を携帯電話１へ返信する処理が行なわれる。これを受けた携帯電話１では、前述の図７のＳ３０により、不適正表示を行なう。一方、顧客管理サーバ１３から適正認証結果が返信されてくれば、Ｓ１１５によりＹＥＳの判断がなされてＳ１１７へ進み、適正認証結果を携帯電話１へ返信する処理が行なわれる。これを受けた携帯電話１では、前述の図７のＳ２９によりＹＥＳの判断がなされてＳ３１により、保険対応窓口ページを表示する処理が行なわれる。
【００６８】
Ｗｅｂサーバ１４では、Ｓ１１７の処理の後、Ｓ１１８により、保険対応窓口ページを携帯電話１に送信する処理が行なわれる。次に、Ｓ１１９に進み、事故請求窓口へのアクセスがあったか否かの判断がなされ、未だない場合にはＳ１２０により、相談窓口へのアクセスがあったか否かの判断がなされ、未だない場合にはＳ１２１に進み、キャンセル操作があったか否かの判断がなされ、未だない場合にはＳ１１９へ戻る。
【００６９】
Ｓ１１９→Ｓ１２０→Ｓ１２１→Ｓ１１９のループの巡回途中で、携帯電話１から図７のＳ３４に従ってキャンセル操作が行なわれた場合には、Ｓ１２１によりＹＥＳの判断がなされてこのＷｅｂサーバの処理が終了する。一方、図７のＳ３３に従って相談窓口へのアクセスが行なわれた場合には、Ｓ１２０によりＹＥＳの判断が行なわれてＳ１２２へ進み、相談窓口のページを携帯電話１に送信する処理が行なわれ、Ｓ１２３により、相談対応処理が行なわれてこのＷｅｂサーバの処理が終了する。
【００７０】
さらに、携帯電話１により前述の図７のＳ３２に従って事故請求窓口へのアクセスが行なわれた場合には、Ｓ１１９によりＹＥＳの判断がなされて、図１１（ａ）に示すＳ１２５へ進み、交通事故の選択操作があったか否かの判断がなされ、未だない場合にはＳ１２６に進み、賠償責任事故の選択操作があったか否かの判断がなされ、未だない場合にはＳ１２７へ進み、携帯電話破損事故の選択操作があったか否かの判断がなされ、未だない場合にはＳ１３３へ進み、キャンセル操作があったか否かの判断がなされ、未だない場合にはＳ１２５へ戻る。
【００７１】
Ｓ１２５→Ｓ１２６→Ｓ１２７→Ｓ１３３→Ｓ１２５のループの巡回途中で、携帯電話１により、図７のＳ３８に従ってキャンセル操作が行なわれた場合には、Ｓ１３３によりＹＥＳの判断がなされてこのＷｅｂサーバの処理が終了する。携帯電話１により、図７のＳ３６に従って交通事故の選択操作が行なわれた場合には、Ｓ１２５によりＹＥＳの判断がなされてＳ１２８へ進み、交通事故時記入ページ（交通事故請求窓口ページ）を携帯電話１に送信する処理がなされた後、Ｓ１３０へ進む。
【００７２】
Ｓ１３０では、記入事項と写真データと現在位置とを受信したか否かの判断がなされ、未だ受信していない場合にはＳ１３１へ進み、キャンセル操作が行なわれたか否かの判断がなされ、未だ操作されていない場合にはＳ１３０へ戻る。
【００７３】
携帯電話１において、図７のＳ４８またはＳ５８によりキャンセル操作が行なわれた場合には、Ｓ１３１によりＹＥＳの判断がなされてこのＷｅｂサーバの処理が終了する。一方、携帯電話１において、図７のＳ５２、Ｓ５３に従って記入事項と写真データと現在位置とが送信されてくれば、Ｓ１３０によりＹＥＳの判断がなされてＳ１３２へ進み、事故請求登録要求と受信した記入事項と写真データと現在位置と端末ＩＤとを顧客管理サーバ１３へ送信する処理が行なわれる。
【００７４】
一方、携帯電話１において、図７のＳ３７に従って賠償責任事故の選択操作が行なわれた場合には、Ｓ１２６によりＹＥＳの判断がなされてＳ１２９へ進み、賠償責任事故時記入ページ（賠償責任事故請求窓口ページ）を携帯電話１に返信する処理が行なわれる。その後、Ｓ１３０→Ｓ１３１→Ｓ１３０のループを巡回することとなる。このループの巡回途中で、携帯電話１において、図７のＳ４２またはＳ４５に従ってキャンセル操作が行なわれれば、Ｓ１３１によりＹＥＳの判断がなされてこのＷｅｂサーバの処理が終了する。一方、携帯電話１において、Ｓ４６、Ｓ５３に従って記入事項と写真データと現在位置とのデータが送信されてくれば、Ｓ１３０によりＹＥＳの判断がなされて、Ｓ１３２の処理が実行される。
【００７５】
携帯電話１において、図７のＳ５４に従って携帯電話破損事故が選択されれば、Ｓ１２７によりＹＥＳの判断がなされてＳ１３４へ進み、携帯電話破損時記入ページ（携帯電話破損事故請求窓口ページ）を携帯電話１に返信する処理が行なわれる。その後、Ｓ１３５により、記入事項データを受信したか否かの判断がなされ、未だ受信していない場合にはＳ１３６に進み、キャンセル操作が行なわれたか否かの判断がなされ、未だなされていない場合にはＳ１３５へ戻る。
【００７６】
携帯電話１において、図１１（ｂ）のＳ２０２によりキャンセル操作が行なわれた場合には、Ｓ１３６によりＹＥＳの判断がなされてこのＷｅｂサーバの処理が終了する。一方、携帯電話１において、図１１（ｂ）のＳ２０３、Ｓ２０４に従って記入事項データと現在位置とのデータが送信されてくれば、Ｓ１３５によりＹＥＳの判断がなされてＳ１３７へ進み、事故請求登録要求と受信した記入事項データと現在位置と端末ＩＤとを顧客管理サーバ１３へ送信する処理が行なわれる。それを受けた顧客管理サーバ１３では、前述の図９のＳ９５によりＹＥＳの判断がなされてＳ９６の登録処理が実行される。
【００７７】
図１２、図１３は、保険処理サーバ８の制御動作を示すフローチャートである。
図１２（ａ）を参照して、Ｓ１４０により、保険契約の申込手続と携帯電話の申込手続とが行なわれたときに実行される申込時処理が行なわれ、Ｓ１４１により、メールアドレス受信時処理が行なわれ、Ｓ１４２により、メールアドレス変更受付時処理が行なわれ、Ｓ１４３により年度末精算処理が行なわれた後、Ｓ１４０へ戻る。
【００７８】
図１２（ｂ）は、Ｓ１４０に示された購入時処理の具体的制御内容を示すフローチャートである。Ｓ１４５により、申込データの入力があったか否かの判断がなされ、ない場合にはこの申込時処理が終了する。一方、前述の図３の（２）に基づいて説明した申込書データが保険処理サーバ８に入力された場合には、Ｓ１４５によりＹＥＳの判断がなされ、Ｓ１４６に進み、申込書データに基づいて顧客データベース１０にメールアドレス以外のデータ（端末ＩＤ、氏名、住所、電話番号、保険情報）を登録する処理が行なわれる。次に、Ｓ１４７に進み、申込書データを保険会社１１の顧客管理サーバ１５へ送信する処理が行なわれる。
【００７９】
図１２（ｃ）は、Ｓ１４１に示したメールアドレス受信時処理の具体的制御内容を示すフローチャートである。このメールアドレス受信時処理は、図８（ｃ）に示したメールアドレス受信時処理とほぼ同様であり、相違点としては、図８（ｃ）のＳ７９の処理が行なわれない点である。それ以外は同様であるために、ここでの説明の繰返しを省略する。
【００８０】
図１２（ｄ）は、Ｓ１５１の認証処理の具体的制御内容を示すフローチャートである。この認証処理は、図８の（ｄ）に示した認証処理と同じ制御内容であり、ここでの説明の繰返しを省略する。
【００８１】
図１３（ａ）は、Ｓ１４２のメールアドレス変更受信時処理の具体的制御内容を示すフローチャートである。このメールアドレス変更受信時処理は、図９（ａ）に示したメールアドレス変更受信時処理と同様の内容であり、ここでの説明の繰返しを省略する。
【００８２】
図１３（ｂ）は、Ｓ１４３に示した年度末精算処理の具体的制御内容を示すフローチャートである。まずＳ１６５により、年度末精算操作があったか否かの判断がなされ、ない場合にはこの年度末精算処理が終了する。携帯電話会社６の従業員が保険処理サーバを操作して、年度末精算操作を行なえば、Ｓ１６５によりＹＥＳの判断がなされてＳ１６６へ進み、顧客データベース１０をチェックして今年度の保険契約の申込数を算出集計する処理が行なわれる。次にＳ１６７に進み、申込数×２０００円を計算して今年度契約金額を算出する処理が行なわれる。次にＳ１６８へ進み、今年度契約金額−支払概算保険料（図３の（１）の説明参照）の計算を行なって収支を算出する処理が行なわれる。次にＳ１６９へ進み、その算出された収支を保険処理サーバ８により表示する処理が行なわれる。この収支の値がプラスの場合には、そのプラスの収支の金額を携帯電話会社６が保険会社１１に対して請求することとなり、収支の値がマイナスの場合には、そのマイナスの収支金額を携帯電話会社６が保険会社１１に支払うこととなる。
【００８３】
［変形例］
次に、以上説明した実施の形態における変形例を列挙する。
【００８４】
（１） 前述の実施の形態では、携帯電話の購入手続と保険契約の申込手続とが携帯電話会社６の窓口にて所定用紙に所定事項を記載することにより行なわれるもの（オフライン契約）を示した。しかし、その代わりに、ユーザのパーソナルコンピュータ等を用いて、インターネット経由で携帯電話会社の申込窓口サイトにアクセスし、予め用意されている保険契約セット型の携帯電話申込ページにおいて、保険契約者および被保険者の個人情報を含む所定事項を記入して申込ができるオンライン契約にしてもよい。その場合において、身分証明書の写等は、携帯電話会社６に郵送し、電話確認がなされるようにする。料金プランや、携帯電話の操作方法、取扱注意、重要説明事項をインターネット経由でユーザのパーソナルコンピュータに動画で紹介し、最後に本人確認をインターネット経由で送信し、携帯電話の購入手続と保険契約の申込手続とが完了する。そして、携帯電話１が、後日契約ユーザに郵送される。この保険契約の申込手続に関するデータが、携帯電話会社６から保険会社１１に送信され、保険会社１１においても契約内容のデータが登録される。これにより、書類の簡素化と手続のスピードアップとが図られる。
【００８５】
（２） 契約ユーザ専用の携帯電話１に予め組込まれる契約保険契約ユーザのための支援機能として、前述のＳ１３、Ｓ２３のほかに、保険会社１１の保険対応窓口のアドレス（ＵＲＬ）を事前にメモリ（お気に入り等）２３に記憶させておいてもよい。さらには、事故発生時に一般的にユーザが連絡する機関（たとえば警察や消防署等）の電話番号（たとえば１１０番や１１９番等）が携帯電話１に入力されて通話が行なわれた場合に、その通話終了後自動的に事故が発生した旨が携帯電話１から保険会社１１の顧客管理サーバ１３へ送信され、顧客管理サーバにおいて対応するユーザの電話番号を検索し、保険会社１１からその電話番号に電話がかかるような仕組みにしてもよい。このようにすれば、保険会社１１からの電話によって、ユーザに保険対応窓口ページへのアクセスを促すことができ、事故発生後ユーザが保険対応窓口ページへのアクセスを忘れてしまう不都合を防止することができる。
【００８６】
（３） 前述の実施の形態では、携帯電話１の端末ＩＤを顧客データベース１５、１０に登録し、その端末ＩＤに基づいて顧客データベース１５、１０を検索するようにしたが、この端末ＩＤの代わりにまたはそれに加えて、クッキー（ｃｏｏｋｉｅ）を利用するようにしてもよい。具体的には、契約ユーザに販売する専用の携帯電話１のメモリ２３に、当該携帯電話１を識別するためのクッキーを記憶させた上で、その携帯電話１を契約ユーザに販売し、顧客データベース１５、１０には、そのクッキーとともに契約ユーザの個人情報等を登録しておく。そして、携帯電話１から、Ｗｅｂサーバ１４、顧客管理サーバ１３、あるいは保険処理サーバ８にアクセスがあった場合に、携帯電話１からメモリ２３に記憶されているクッキーをそれらサーバに送信し、サーバ側において、受信したクッキーに基づいて顧客データベース１５、１０を検索し、対応する個人情報を割り出すことができるように構成する。
【００８７】
（４） 今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなく特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【図面の簡単な説明】
【００８８】
【図１】保険システムの全体構成を示すシステム図である。
【図２】携帯電話の機能ブロック図である。
【図３】保険システムの流れを示す説明図である。
【図４】携帯電話の制御を示すフローチャートである。
【図５】メールアドレス設定時処理の具体的制御内容を示すフローチャートである。
【図６】メールアドレス変更時処理の具体的制御内容を示すフローチャートである。
【図７】Ｗｅｂブラウザ処理の具体的制御内容を示すフローチャートである。
【図８】（ａ）は顧客管理サーバの制御を示すフローチャートであり、（ｂ）は申込時処理の具体的制御内容を示すフローチャートであり、（ｃ）はメールアドレス受信時処理の具体的制御内容を示すフローチャートであり、（ｄ）は認証処理の具体的制御内容を示すフローチャートである。
【図９】（ａ）はメールアドレス変更受信時処理の具体的制御内容を示すフローチャートであり、（ｂ）は事故請求登録処理の具体的制御内容を示すフローチャートであり、（ｃ）は年度末精算処理の具体的制御内容を示すフローチャートである。
【図１０】Ｗｅｂサーバの制御動作を示すフローチャートである。
【図１１】（ａ）はＷｅｂサーバの制御動作の続きを示すフローチャートであり、（ｂ）はＷｅｂブラウザ処理の続きを示すフローチャートである。
【図１２】（ａ）は保険処理サーバの制御動作を示すフローチャートであり、（ｂ）は申込時処理の具体的制御内容を示すフローチャートであり、（ｃ）はメールアドレス受信時処理の具体的制御内容を示すフローチャートであり、（ｄ）は認証処理の具体的制御内容を示すフローチャートである。
【図１３】（ａ）はメールアドレス変更受信時処理の具体的制御内容を示すフローチャートであり、（ｂ）は年度末精算処理の具体的制御内容を示すフローチャートである。
【符号の説明】
【００８９】
１ 携帯電話、５ インターネット、６ 携帯電話会社、８ 保険処理サーバ、１０ 顧客データベース、１１ 保険会社、１３ 顧客管理サーバ、１５ 顧客データベース、１４ Ｗｅｂサーバ、１６ Ｗｅｂデータベース、２２ 制御部、２３ メモリ、２４ 操作部、２６ デジタルカメラ、２７ 表示部、３０ 顧客（契約者）。
【技術分野】
【０００１】
本発明は、たとえば、交通傷害保険、賠償責任保険、あるいは携帯電話破損保険等の各種保険の契約をユーザが行なった場合に該保険契約をコンピュータを用いて管理する保険システムに関する。
【背景技術】
【０００２】
この種の保険システムにおいて、従来から一般的に知られているものに、たとえば、ユーザの所持する携帯電話等の携帯通信端末から保険契約についての保険制御信号が保険契約コンピュータに送信されてくれば、その送信されてきた保険制御信号に応答して、保険契約コンピュータが、保険契約の成立または終了あるいは保険契約に係る期間的条件を制御するものがあった（特許文献１）。
【０００３】
この特許文献１に記載のものは、携帯通信端末の位置または移動距離に関する情報信号を携帯通信端末から保険契約コンピュータへ送信し、保険契約コンピュータにおいて、その送信されてきた位置または移動距離に関わる情報信号に応答して保険契約に関わる金銭的条件を制御するように構成されていた。
【特許文献１】特開２００３−５０９１４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、この特許文献１に記載のものは、ユーザが携帯通信端末を購入した後、その携帯通信端末を事後的に保険契約に有効利用するものである。その結果、ユーザは、携帯通信端末の購入時に購入手続を行なった後、保険契約の申込時に申込手続を行なうこととなり、前後して両手続きを重複して行なわなければならない。その結果、ユーザ自身の住所氏名等の個人情報を両手続きで重複して提示しなければならないという無駄な手続作業を強いられるという不都合があった。
【０００５】
本発明は、係る実情に鑑み考え出されたものであり、その目的は、携帯通信端末の購入手続と保険契約の申込手続とにおける重複した手続の無駄を防止することである。
【課題を解決するための手段の具体例およびその効果】
【０００６】
次に、課題を解決するための手段の具体例を括弧書きで示すとともに、その効果を記載する。
【０００７】
（１） ユーザの保険契約（たとえば、交通傷害保険、賠償責任保険、携帯電話破損保険等の契約）をコンピュータ（たとえば、図１の顧客管理サーバ１３、Ｗｅｂサーバ１２、保険処理サーバ１０等）を用いて管理する保険システムであって、
ユーザによる保険契約の申込手続が行なわれた場合に該ユーザの個人情報（たとえば、図１の氏名、住所、電話番号等）および契約内容に関する情報（たとえば、図１の保険情報等）を登録する保険業務用サーバ（たとえば、図１の顧客管理サーバ１３、顧客データベース１５等）と、
ユーザによる携帯通信端末（たとえば、図１、図２の携帯電話１）の購入手続が行なわれた場合に、該ユーザの個人情報（たとえば、図１の氏名、住所、電話番号等）を、登録する携帯通信用サーバ（たとえば、図１の保険処理サーバ８、顧客データベース１０等）と、
前記携帯通信端末の購入手続と前記保険契約の申込手続とを行なうユーザが１回提示した個人情報を、前記保険業務用サーバと前記携帯通信用サーバとの両方に登録する個人情報登録手段（たとえば、図１２のＳ１４５〜Ｓ１４７、図８（ｂ）のＳ７０、Ｓ７１等）とを備えている。
【０００８】
このような構成によれば、携帯通信端末の購入手続と保険契約の申込手続とを行なうユーザが１回提示した個人情報が、保険業務用サーバと携帯通信用サーバとの両方に登録されるために、ユーザは、携帯通信端末の購入手続と保険契約の申込手続の両方で重複して自己の個人情報を提示する必要がなくなり、重複した手続による無駄を極力防止することができる。
【０００９】
（２） 前記携帯通信用サーバを運用する携帯通信端末会社（たとえば、図１の携帯電話会社６等）が、前記携帯通信端末の購入手続と前記保険契約の申込手続とを受付けたときに保険契約ユーザから支払われた当該保険契約の契約金を、前記保険業務用サーバを運用する保険会社との間で決済するための処理を行なう決済処理手段（たとえば、図９のＳ１００〜Ｓ１０４、図１３のＳ１６５〜Ｓ１６９等）をさらに備え、
該決済処理手段は、
前記保険業務用サーバに登録された保険契約ユーザの保険契約登録数を集計する保険会社側集計手段（たとえば、図９のＳ１００〜Ｓ１０４等）と、
前記携帯通信用サーバに登録された保険契約ユーザの保険契約登録数を集計する携帯通信端末会社側集計手段（たとえば、図１３のＳ１６５〜Ｓ１６９等）とを含む。
【００１０】
このような構成によれば、携帯通信端末の購入手続と保険契約の申込手続との両方が携帯通信端末会社で受付けられ、両手続の受付窓口を一本化することによりユーザの利便性が向上する。しかも、一本化された受付窓口である携帯通信端末会社に対してユーザが保険契約の契約金を支払い、携帯通信端末会社と保険会社との間でその保険契約金の決済を行なうにおいて保険業務用サーバに登録された保険契約ユーザの保険契約登録数が保険会社側集計手段により集計され、かつ、携帯通信用サーバに登録された保険契約ユーザの保険契約登録数が携帯通信端末会社側集計手段により集計されるために、両集計手段による集計結果を照合することにより間違った請求や不正請求による不適正な決済が行なわれることを極力防止することができる。
【００１１】
（３） ユーザが携帯通信端末を購入する際に、該ユーザが前記保険契約を希望し該保険契約の申込手続と携帯通信端末の購入手続とを行なった場合に、当該ユーザに提供される携帯通信端末（たとえば、図１、図２の携帯電話１）をさらに備え、
前記携帯通信端末は、当該携帯通信端末にメールアドレスを設定した際に該メールアドレスを自動的に前記保険業務用サーバへ送信する自動送信手段（たとえば、図５のＳ１３等）を備え、
前記保険業務用サーバは、
前記自動送信手段により前記メールアドレスが送信されてきた場合に（たとえば、図８（ｃ）のＳ７５でＹＥＳの場合に）、該メールアドレスの送信元のユーザが前記個人情報登録手段により個人情報が登録されている登録済ユーザであるか否か判定する登録判定手段（たとえば、図８（ｄ）のＳ８５〜Ｓ８８等）と、
該登録判定手段により登録済ユーザであると判定された場合に（たとえば、図８（ｄ）のＳ８６でＹＥＳと判定された場合に）該登録済ユーザの個人情報に対応させて前記送信されてきたメールアドレスを登録するメールアドレス登録手段（たとえば、図８（ｃ）のＳ７７、Ｓ７８等）と、
前記登録判定手段により登録済ユーザでないと判定された場合に（たとえば、図８（ｄ）のＳ８６でＮＯと判定された場合に）異常報知を行なう異常報知手段（たとえば、図８（ｃ）のＳ８０等）とを含む。
【００１２】
このような構成によれば、保険契約の申込手続と携帯通信端末の購入手続とを行なったユーザに提供される携帯通信端末に備えられた自動送信手段の働きにより、携帯通信端末にメールアドレスを設定した際にそのメールアドレスが自動的に保険業務用サーバへ送信されるために、メールアドレスの保険業務用サーバへの登録手続が自動的に行なわれ、ユーザの利便性が向上する。しかも、保険業務用サーバにおいては、送信されてきたメールアドレスの送信元のユーザの個人情報が既に登録されているか否か判定され、登録されていない場合には異常報知が行なわれるために、保険契約の申込手続が行なわれながらもその申込手続を行なったユーザの個人情報が保険業務用サーバに登録されていない異常、または、保険契約の申込手続を行なっていないユーザに対して自動送信手段を備えた携帯通信端末が販売された異常等の発生したことを、保険会社が認識することができる。
【００１３】
また、一本化された受付窓口である携帯通信端末会社に対してユーザが保険契約の契約金を支払い、携帯通信端末会社と保険会社との間でその保険契約金の決済を行なう場合においては、携帯通信端末会社から保険会社への決済申告に間違いまたは虚偽の申告があったとしても、保険契約の申込手続と携帯通信端末の購入手続とを行なったユーザの携帯通信端末にメールアドレスを設定した際にそのメールアドレスが自動的に保険業務用サーバへ送信されるために、そのメールアドレスの受信数のデータを基に、携帯通信端末会社からの申告数を検証することができ、携帯通信端末会社からの申告の間違いまたは虚偽申告の監視が可能となる。
【発明を実施するための最良の形態】
【００１４】
次に、本発明の実施の形態を図面に基づいて詳細に説明する。図１は、本発明に係る保険システムの全体の概略を示す構成図である。通信網の一例のインターネット５を通じて、携帯電話会社６のゲートウェイ７、保険会社１１のゲートウェイ１２、および、携帯電話網２のゲートウェイ４が接続されており、互いに情報の送受信ができるように構成されている。また、携帯電話網２には、基地局３が接続されており、携帯通信端末の一例の携帯電話１と基地局３との間で無線通信を行ない、その無線通信のデータが携帯電話網２、ゲートウェイ４、インターネット５を経由して、携帯電話会社６あるいは保険会社１１に送信される。さらに、携帯電話会社６あるいは保険会社１１からのデータが、インターネット５、ゲートウェイ４、携帯電話網２、基地局３を経由して携帯電話１に送信される。
【００１５】
携帯電話会社６には、前述のゲートウェイ７の他に、携帯電話１を利用した保険業務の処理を行なうための保険処理サーバ８と、その保険契約に加入した契約ユーザの顧客データを記憶している顧客データベース１０と、その他のサーバ９とが設けられている。
【００１６】
保険会社１１には、前述したゲートウェイ１２の他に、Ｗｅｂサーバ１４、Ｗｅｂデータベース１６、携帯電話１を利用した保険契約に加入した契約ユーザの顧客管理を行なうための顧客管理サーバ１３、その契約ユーザの顧客データを記憶している顧客データベース１５が、設けられている。
【００１７】
顧客データベース１５には、携帯電話１を利用した保険契約に加入した契約ユーザの所持する携帯電話１の端末ＩＤ（携帯電話固有の製造番号）、当該携帯電話のメールアドレス、契約ユーザの氏名、住所、電話番号、加入した保険の種類を特定する保険情報、事故請求データ等が記憶されている。なお、携帯電話１は、保険契約の申込手続および携帯電話の購入手続を行なったユーザにのみ販売される保険契約ユーザ専用の携帯電話であり、保険業務の運用の際にユーザの利便性を向上する支援機能が予め組込まれたものである。この携帯電話１の販売時点では、まだメールアドレスが設定されていないために、顧客データベース１５のメールアドレスの記憶エリアには、何らデータが記憶されていない。また事故請求データは、保険対象の事故（たとえば、交通事故、賠償責任事故、携帯電話破損事故等）が発生したときの保険金の支払請求に関するデータであり、事故が発生していなければ未だ発生していない旨の「なし」のデータが記憶されており、事故が発生して保険金の支払請求があった場合には、その事故の内容と請求内容と事故現場の状況のデータ（たとえば写真データ等）の、各種事故詳細データが記憶される。保険情報とは、契約ユーザが加入した保険の種類を特定する情報であり、たとえば、端末ＩＤ「８１４３１１」のユーザの場合には、交通傷害保険に加入しており、端末ＩＤが「７１０４３６」のユーザの場合には、傷害責任保険と交通傷害保険との両方に加入している。なお、「交通傷害保険」の場合には、交通事故で当該契約ユーザの所持している携帯電話が破損した場合には、その携帯電話の破損に対する保険金の支払を受けることができる。この交通傷害保険とは別に、交通事故以外の原因で携帯電話が破損した場合の補償として、携帯電話破損保険がある。
【００１８】
保険会社１１のＷｅｂデータベース１６には、契約ユーザのために用意されたＷｅｂサイトのページのデータが記憶されており、携帯電話１を用いてそのＷｅｂサイトのページにアクセスできるように構成されている。このＷｅｂサイトのページは、具体的には、保険対応窓口ページがあり、その保険対応窓口ページを入口として事故請求窓口ページまたは相談窓口ページにアクセスできるようになっている。事故請求窓口ページには、さらに、交通事故請求窓口ページ、賠償責任事故請求窓口ページ、携帯電話破損事故請求窓口ページがある。契約ユーザが保険に関する相談を保険会社１１に行ないたい場合には、携帯電話１を操作して保険会社１１のＷｅｂサイトのページにアクセスする。すると、まず保険対応窓口ページが表示され、その中から相談窓口を選択（クリック）することにより、相談窓口ページが携帯電話１に表示され、その相談窓口ページの所定箇所に相談事項を入力して送信することにより、保険会社１１がその相談事項の回答を追って携帯電話１に返信（メールによる返信等）する。
【００１９】
契約ユーザが自分の加入している保険の対象とする事故が発生した場合に、携帯電話１を操作して保険対応窓口ページにアクセスし、そこで事故請求窓口ページを選択して事故請求窓口ページにアクセスする。その事故請求窓口ページにおいて、発生した事故の種類により、交通事故請求窓口ページ、賠償責任事故請求窓口ページ、あるいは携帯電話破損事故請求窓口ページのいずれかにアクセスする。そして、アクセスした事故請求窓口ページが携帯電話１に表示され、その事故請求窓口ページの所定箇所に、所定事項を入力して保険会社１１に送信するとともに、携帯電話１のデジタルカメラ２６（図２参照）により事故現場の写真を撮り、その写真データを保険会社１１に送信する。
【００２０】
この事故請求窓口ページに入力されたデータおよび事故現場の写真データが、顧客データベース１５の事故請求データにおける対応する携帯ＩＤのエリアに格納される。
【００２１】
なお、携帯電話会社６の顧客データベース１０には、保険会社１１の顧客データベース１５の記憶データのうち、「事故請求データ」を除く各種データが記憶されている。
【００２２】
図２は、携帯電話１の機能ブロック図である。携帯電話１には、制御中枢としてのＣＰＵ（Central Processing Unit）等からなる制御部２２と、その制御部の制御動作を司るプログラムおよび各種データが記憶されたメモリ２３が設けられている。制御部２２は、メモリ２３に記憶されているデータやプログラムを読出して、所定の制御動作を実行するとともに、受信したデータを必要に応じてメモリ２３に記憶させる。
【００２３】
制御部２２には、無線部２１が接続されており、その無線部２１にはアンテナ２０が接続されている。また、制御部２２には、ユーザによって操作される操作部２４、受話部２５、デジタルカメラ２６、液晶等からなる表示部２７、送話部２８、サラウンダ２９が接続されている。ユーザが操作部２４を操作すればその操作信号が制御部２２に入力され、ユーザが発した音声が受話部２５から制御部２２に入力され、ユーザがデジタルカメラ２６で写真を撮るとその写真データが制御部２２に入力される。また、ユーザが操作部２４を操作してＷｅｂページにアクセスした場合には、そのＷｅｂページが表示部２７により表示される。他人から電話がかかってきた場合には、サラウンダ２９によりコール音が発せられ、操作部２４を操作して通話状態にした後、相手からの音声電波をアンテナ２０により受信して無線部２１、制御部２２を経由して送話部２８から相手側の音声が発せられる。
【００２４】
メモリ２３には、一般の携帯電話に必要な制御プログラムおよびデータが記憶されているが、この携帯電話１は、前述したように、保険契約に加入した保険契約ユーザ専用のカスタマイズされた携帯電話であり、保険業務の遂行の上でユーザに便利な機能を実現するためのプログラムやデータが予めメモリ２３に記憶されている。たとえば、後述する図５のＳ１３、図６のＳ２３等のプログラムが、メモリ２３に予め記憶されている。
【００２５】
図３は、携帯電話を利用するべく携帯電話の販売とセットとなっている保険システムの流れを説明するための説明図である。
【００２６】
まず、（１）において、携帯電話会社６から保険会社１１に、概算保険料（年間保険料）が支払われる。対象となる保険の種類は、前述したように、交通傷害保険、賠償責任保険、携帯電話破損保険の３種類があり、それぞれ、年間契約で１つの契約に対して契約金２０００円である。携帯電話会社６は、１年間における契約数を予測し、その予測した見込契約数に２０００円を乗じた概算保険料を予め保険会社１１に支払う。
【００２７】
次に、（２）において、顧客（契約者）３０が携帯電話会社６の窓口において、携帯電話の購入手続と保険契約の申込手続とを行なう。具体的には、１枚の携帯電話加入申込書（数枚写真様式）に、保険契約者および被保険者等の所定事項（個人情報）を記載し、保険同意事項を記入する。これにより、携帯電話の購入手続と保険契約の申込手続とが完了し、その顧客（契約者）３０に対して前述の携帯電話１が販売される。その販売された携帯電話１の端末ＩＤと顧客（契約者）３０が記入した内容とが、携帯電話会社６の社員により電子データとしてコンピュータに入力され、その入力データが携帯電話会社６の顧客データベース１０に登録される。それと同時に、その電子データが（３）において、保険会社１１にも送信され、保険会社１１の顧客データベース１５に登録される。
【００２８】
次に、顧客（契約者）３０は、新たに購入した携帯電話１に対し、メールアドレスを設定する。すると、その設定されたメールアドレスのデータが、（４）において、携帯電話会社６ばかりでなく保険会社１１にも自動送信される。この設定されたメールアドレスの送信に際しては、後述するように、携帯電話１の電話番号と端末ＩＤも併せて自動送信される。その結果、その送信されてきたデータを受けた携帯電話会社６および保険会社１１では、受信した端末ＩＤに基づいて顧客データベース１０、１５を検索し、対応する端末ＩＤのエリアにおけるメールアドレスの箇所に受信したメールアドレスを登録する。
【００２９】
次に、保険会社１１は、（５）において、顧客（契約者）３０の携帯電話１に対して、保険事故発生時等の保険対応窓口アドレス（ＵＲＬ）をダイレクトメールする。顧客（契約者）３０は、その受信した保険対応窓口アドレスを携帯電話１のメモリ（お気に入り）に記憶させる。
【００３０】
次に、保険事故が発生したときに、顧客（契約者）３０は、携帯電話１を操作して、（６）において、保険会社１１の保険対応窓口アドレスにアクセスし、Ｗｅｂページに示された所定の様式に所定事項を入力して送信する。たとえば、交通事故が発生した場合には、（６）−Ａにおいて、所定の様式への入力情報と交通事故現場でのデジタルカメラ２６による撮像データとが保険会社１１へ送信される。また、賠償責任保険事故が発生した場合には、（６）−Ｂにおいて、所定の様式への入力情報と破損した物のデジタルカメラ２６による撮像データとが、保険会社１１にメール送信される。
【００３１】
また、損害賠償責任事故の場合には、保険会社１１から被害者（物損賠償責任の相手）に対して電話での確認が行なわれその確認内容が保険審査に利用される。
【００３２】
次に、書類審査の結果、保険金を支払う場合には、（８）において、顧客（契約者）３０の銀行口座に保険会社１１から保険金の振込みが行なわれる。
【００３３】
次に、（９）において、携帯電話会社６と保険会社１１との間で、年度末の保険料精算の決済が行なわれる。これは、前述の（１）において、携帯電話会社６から保険会社１１に年間の契約見込数に対して２０００円を乗じた概算保険料の支払が行なわれており、その支払から１年後において年間の実際の申込数が確定するため、その実際の申込数に応じた契約金額のトータルと事前に支払っている概算保険料との精算を行なって決済を行なうものである。
【００３４】
図４は、携帯電話１のメモリ２３に記憶されているプログラムのフローチャートである。まず、ステップ（以下単に「Ｓ」という）１により、携帯電話１に対するメールアドレスの設定が行なわれたときのメールアドレス設定時処理が実行され、Ｓ２によりＷｅｂブラウザ処理が行なわれ、メールアドレスを変更設定したときのメールアドレス変更時処理が行なわれ、Ｓ４により、その他の処理が実行され、Ｓ１へ戻る。
【００３５】
図５は、図４のＳ１に示されたメールアドレス設定時処理の具体的制御内容を示すフローチャートである。Ｓ１０により、自己のメールアドレスの設定操作が行なわれたか否かの判断がなされ、行なわれていなければこのメールアドレス設定時処理が終了（リターン）するが、自己のメールアドレスの設定操作が行なわれた場合には、Ｓ１１に進み、その設定されたメールアドレスをメモリ２３に記憶する処理が行なわれる。
【００３６】
次にＳ１２に進み、登録要求信号とともに自己のメールアドレスと電話番号と端末ＩＤとを携帯電話会社６へ送信する処理が行なわれる。携帯電話会社６では、これを受けて、顧客データベース１０の対応するメールアドレスのエリアに送信されてきたメールアドレスを登録する処理を行なう。
【００３７】
次にＳ１３により、登録要求信号とともに自己のメールアドレスと電話番号と端末ＩＤとを保険会社１１へ送信する処理が行なわれる。これを受けた保険会社１１では、顧客データベース１５の対応するメールアドレスエリアに受信したメールアドレスを登録する処理を行なう。
【００３８】
次にＳ１４へ進み、保険対応窓口のアドレスを受信したか否かの判断がなされ、受信していなければＳ１５へ進み、不適正の認証結果を受信したか否かの判断がなされ、受信していなければＳ１４へ戻る。
【００３９】
登録要求信号とメールアドレスと電話番号と端末ＩＤとのデータを受信した保険会社１１の顧客管理サーバ１３では、その受信した端末ＩＤが顧客データベース１５に登録されている端末ＩＤであるか否かをチェックし、登録された端末ＩＤの場合には、Ｗｅｂデータベース１６の保険対応窓口ページのアドレス（ＵＲＬ）を携帯電話１に返信する。一方、受信した端末ＩＤが顧客データベース１５に登録されていなければ、保険契約手続を行なっていないユーザからメールアドレスが送信されてきたこととなり、異常判定して不適正の認証結果を携帯電話１に返信する。保険会社１１から保険対応窓口のアドレスが返信されてくれば、Ｓ１４によりＹＥＳの判断がなされてＳ１６へ進み、保険対応窓口のアドレスをメモリ２３へ登録する処理が行なわれる。一方、保険会社１１から前述した不適正の認証結果が返信されてくれば、Ｓ１５によりＹＥＳの判断がなされてＳ１７へ進み、不適正の表示が携帯電話１の表示部２７により行なわれ、このメールアドレス設定時処理が終了する。
【００４０】
図６は、図４のＳ３に示したメールアドレス変更時処理の具体的制御内容を示すフローチャートである。Ｓ２０により、メールアドレスの変更操作が行なわれたか否かの判断がなされ、行なわれていない場合にはこのメールアドレス変更時処理が終了する。ユーザが携帯電話１の操作部２４を操作して既に設定されているメールアドレスを他のメールアドレスに変更した場合には、Ｓ２０によりＹＥＳの判断がなされてＳ２１へ進み、自己のメールアドレスを変更された新たなメールアドレスに更新する処理が行なわれる。次にＳ２２により、メールアドレス変更信号とともに新メールアドレスと電話番号と端末ＩＤとを携帯電話会社６へ送信する処理が行なわれる。次にＳ２３により、メールアドレス変更信号とともに新メールアドレスと電話番号と端末ＩＤとを保険会社１１へ送信する処理が行なわれる。
【００４１】
携帯電話会社６および保険会社１１では、これを受けて、顧客データベース１０、１５の対応するメールアドレスエリアに記憶されているメールアドレスを新メールアドレスに更新する処理を行なう。
【００４２】
図７は、図４のＳ２に示したＷｅｂブラウザ処理の具体的制御内容を示すフローチャートである。まず、Ｓ２５により、ホームページへのアクセスがあったか否かの判断がなされ、ない場合にはこのＷｅｂブラウザ処理が終了する。ユーザが携帯電話１の操作部２４を操作して、Ｗｅｂ上のいずれかのホームページへのアクセス操作を行なった場合には、Ｓ２５によりＹＥＳの判断がなされてＳ２６へ進み、保険対応窓口へのアクセスであるか否かの判断がなされる。保険対応窓口へのアクセスでない場合にはＳ５６により、その他のＷｅｂブラウザ処理が実行されてこのＷｅｂブラウザ処理が終了する。一方、ユーザが保険会社１１の保険対応窓口ページのＵＲＬにアクセスした場合には、Ｓ２６によりＹＥＳの判断がなされてＳ２７へ進み、携帯電話１から端末ＩＤが保険会社１１へ送信される。保険会社１１は、後述するように、その受信した端末ＩＤに基づいて顧客データベース１５を検索し、対応する端末ＩＤが登録されているか否か判定し、登録されている場合には認証結果が適正な旨を返信し、登録されていなければ認証結果が不適正な旨を返信する。携帯電話１では、端末ＩＤの送信を行なった後、Ｓ２７により、認証結果の返信があったか否かを判断し、あるまで待機する。そして、保険会社１１からの認証結果の返信があれば、制御がＳ２９へ進み、その返信結果が適正であるか否かの判断が行なわれる。不適正であった場合には、Ｓ３０に進み、不適正表示が表示部２７によりなされて、このＷｅｂブラウザ処理が終了する。一方、返信された認証結果が適正であった場合には、制御がＳ３１へ進み、保険対応窓口ページが表示部２７により表示される。
【００４３】
その保険対応窓口ページを見たユーザは、事故請求窓口ページまたは相談窓口ページのいずれにアクセスするか、さらにはキャンセルするかの操作を、操作部２４により行なう。携帯電話１では、Ｓ３２により、事故請求窓口へのアクセス操作が行なわれたか否かの判断がなされ、未だアクセス操作がなされていなければＳ３３により、相談窓口へのアクセス操作が行なわれたか否かの判断がなされ、未だにアクセス操作がなされていなければＳ３４により、キャンセル操作が行なわれたか否かの判断がなされ、未だにキャンセル操作が行なわれていない場合にはＳ３３に戻る。このＳ３２→Ｓ３３→Ｓ３４→Ｓ３２のループの巡回途中で、ユーザがキャンセル操作を行なえばＳ３４によりＹＥＳの判断がなされてこのＷｅｂブラウザ処理が終了する。一方、ユーザが相談窓口へのアクセス操作を行なえばＳ３３によりＹＥＳの判断がなされてＳ５４へ進み、相談窓口ページが表示部２７により表示され、Ｓ５５により、相談受付処理が行なわれてこのＷｅｂブラウザ処理が終了する。さらに、事故請求窓口へのアクセス操作が行なわれた場合には、Ｓ３２によりＹＥＳの判断がなされてＳ３５へ進み、事故請求窓口のページが表示部２７により表示される。
【００４４】
次に、携帯電話１の制御部２２は、Ｓ３６により交通事故の選択操作があったか否かの判断がなされ、未だに交通事故の選択操作がない場合にはＳ３７へ進み、損害賠償責任事故の選択操作があったか否かの判断がなされ、未だにない場合にはＳ５４ａへ進み、携帯電話破損事故の選択操作があったか否かの判断がなされ、未だにない場合にはＳ３８へ進み、キャンセル操作があったか否かの判断がなされ、未だにない場合にはＳ３６へ戻る。
【００４５】
このＳ３６→Ｓ３７→Ｓ５４→Ｓ３８→Ｓ３６のループの巡回途中で、ユーザがキャンセル操作を行なえば、Ｓ３８によりＹＥＳの判断がなされてＷｅｂブラウザ処理が終了する。また、ユーザが交通事故の選択操作を行なえば、Ｓ３６によりＹＥＳの判断がなされてＳ３９へ進み、交通事故時記入ページ（交通事故請求窓口ページ）が表示部２７により表示される。一方、ユーザが賠償責任事故の選択操作を行なえば、Ｓ３７によりＹＥＳの判断がなされてＳ４０へ進み、賠償責任事故時記入ページ（賠償責任事故請求窓口ページ）が表示部２７により表示される。さらに、ユーザが携帯電話破損事故の選択操作を行なえば、Ｓ５４によりＹＥＳの判断がなされて図１１のＳ２００に進み、携帯電話破損事故時記入ページ（携帯電話破損事故請求窓口ページ）が表示部２７により表示される。なお、この携帯電話破損事故の場合は、たとえば通話機能が破損しＷｅｂサイトへのアクセスおよび通信機能が破損されていない場合に、その携帯電話１による前述のＳ５４ａ、Ｓ２００〜Ｓ２０４のオンライン制御が可能となる。Ｗｅｂサイトへのアクセスや通信機能が破損している場合には、オンライン制御が不可能であり、郵送等を利用したオフラインによる請求手続き、または、他の通信機器を利用してのオンラインによる請求手続きを行なうこととなる。
【００４６】
Ｓ３９による、交通事故時記入ページの表示がなされた後、Ｓ４７に進み、所定事項の記入が完了したか否かの判断がなされ、未だ完了していない場合にはＳ４８に進み、キャンセル操作が行なわれたか否かの判断がなされ、未だキャンセル操作が行なわれていない場合にはＳ４７へ戻る。ユーザは、表示部２７に表示された交通事故時記入ページを見て、操作部２４を操作して所定事項を記入するか、あるいはキャンセル操作を行なう。キャンセル操作を行なった場合には、Ｓ４８によりＹＥＳの判断がなされてＷｅｂブラウザ処理が終了する。一方、所定事項の記入を行なって完了操作が行なわれた場合には、Ｓ４７によりＹＥＳの判断がなされてＳ４９へ進み、事故現場の写真添付のメッセージ表示が表示部２７により行なわれる。
【００４７】
次にＳ５０へ進み、事故現場の写真の添付があったか否かの判断がなされ、未だにない場合にはＳ５１へ進み、キャンセル操作があったか否かの判断がなされ、未だにない場合にはＳ５０へ戻る。ユーザがキャンセル操作を行なえば、Ｓ５１によりＹＥＳの判断がなされてＷｅｂブラウザ処理が終了する。一方、ユーザがデジタルカメラ２６により事故現場の写真を撮りその撮像データを添付すれば、Ｓ５０によりＹＥＳの判断がなされてＳ５２へ進み、記入事項と添付された写真データとを保険会社１１のＷｅｂサーバ１４へ送信する処理が行なわれる。
【００４８】
次にＳ５３へ進み、携帯電話１に備えられているＧＰＳ機能（測位機能）により現在位置を特定して、その現在位置データを保険会社１１のＷｅｂサーバ１４へ送信する処理が行なわれて、このＷｅｂブラウザ処理が終了する。
【００４９】
一方、Ｓ４０による、賠償責任事故時記入ページが表示された後、Ｓ４１により、所定事項の記入が完了したか否かの判断がなされ、未だ完了していない場合にはＳ４２により、キャンセル操作が行なわれたか否かの判断がなされ、未だ操作されていない場合にはＳ４１へ戻る。ユーザがキャンセル操作を行なえば、Ｓ４２によりＹＥＳの判断がなされてこのＷｅｂブラウザ処理が終了する。一方、表示部２７に表示された賠償責任事故時記入ページを見てユーザが所定事項を入力し完了操作を行なえば、Ｓ４１によりＹＥＳの判断がなされてＳ４３へ進み、破損物の写真を添付するメッセージ表示が表示部２７により行なわれる。
【００５０】
次にＳ４４へ進み、破損物の写真の添付があったか否かの判断がなされ、未だにない場合にはＳ４５に進み、キャンセル操作があったか否かの判断がなされ、未だにない場合にはＳ４４へ戻る。ユーザがキャンセル操作を行なえば、Ｓ４５によりＹＥＳの判断がなされてこのＷｅｂブラウザ処理が終了する。一方、ユーザがデジタルカメラ２６により破損物の写真を撮りその撮像データを添付した場合には、Ｓ４４によりＹＥＳの判断がなされてＳ４６へ進み、記入事項と添付された写真データとを保険会社１１のＷｅｂサーバ１４へ送信する処理が行なわれ、Ｓ５３によるＧＰＳ機能により現在位置を特定して送信する処理が行なわれる。
【００５１】
図１１（ｂ）のＳ２００による、携帯電話破損事故時記入ページの表示が行なわれた後、Ｓ２０１により、所定事項の記入が完了したか否かの判断がなされ、未だ完了していない場合にはＳ２０２へ進み、キャンセル操作があったか否かの判断がなされ、未だない場合にはＳ２０１へ戻る。ユーザがキャンセル操作を行なえば、Ｓ２０２によりＹＥＳの判断がなされてこのＷｅｂブラウザ処理が終了する。一方、ユーザが操作部２４を操作して所定事項の記入を行ない完了操作を行なえば、Ｓ２０１によりＹＥＳの判断がなされてＳ２０３へ進み、その記入された記入事項データを保険会社１１のＷｅｂサーバ１４へ送信する処理が行なわれる。
【００５２】
次にＳ２０４へ進み、携帯電話１に備えられているＧＰＳ機能により現在位置を特定してその現在位置データを保険会社１１のＷｅｂサーバ１４へ送信する処理が行なわれて、このＷｅｂブラウザ処理が終了する。
【００５３】
図８、図９は、顧客管理サーバ１３の制御動作を示すフローチャートである。
まず、図８（ａ）を参照して、Ｓ６０により、保険契約の申込時に行なわれる申込時処理が実行され、Ｓ６１により、メールアドレス受信時処理が行なわれ、Ｓ６２により、メールアドレス変更受信時処理が行なわれ、Ｓ６３により、認証依頼があったか否かの判断がなされ、ない場合にはＳ６５に進むが、あった場合にはＳ６４により、認証処理が行なわれ、次にＳ６５により、事故請求登録処理が行なわれ、Ｓ６６により、年度末精算処理が行なわれてＳ６０へ戻る。
【００５４】
図８（ｂ）は、Ｓ６０に示した申込時処理の具体的制御内容を示すフローチャートである。Ｓ７０により、保険契約の申込手続が行なわれた際に携帯電話会社から送信されてくる申込書データの受信があったか否かの判断がなされ、ない場合にはこの申込時処理が終了する。一方、申込書データの受信があった場合には、Ｓ７１に進み、その申込書データに基づいて、顧客データベース１５に、メールアドレス以外の個人データ（端末ＩＤ、氏名、住所、電話番号、保険情報）を登録する処理が行なわれる。
【００５５】
図８（ｃ）は、Ｓ６１に示したメールアドレス受信時処理の具体的制御内容を示すフローチャートである。Ｓ７５により、登録要求信号を受信したか否かの判断がなされ、受信していない場合にはこのメールアドレス受信時処理が終了する。図５のＳ１３に従って携帯電話１から登録要求信号が送信されてくれば、Ｓ７５によりＹＥＳの判断がなされてＳ７６へ進み、認証処理が行なわれる。この認証処理の具体的制御内容は、図８（ｄ）のフローチャートに示されている。図８（ｄ）のフローチャートは、前述のＳ６４に示された認証処理の具体的制御内容のフローチャートでもある。
【００５６】
図８（ｄ）を参照して、Ｓ８５により、受信した端末ＩＤと電話番号とに基づいて顧客データベース１５を検索する処理が行なわれる。そしてＳ８６により、該当する顧客の個人データが顧客データベース１５に登録されているか否かの判断が行なわれる。顧客データベース１５には、保険契約手続を行なって保険に加入している契約ユーザの個人データ等が登録されており、受信した端末ＩＤが顧客データベース１５に登録されている契約ユーザの携帯電話であるか否かの判断が、このＳ８６により行なわれる。そして、該当する顧客の個人データが登録されている場合には、Ｓ８７に進み、適正認証結果を返信する処理が行なわれる。一方、該当する顧客の個人データがない場合には、Ｓ８８により、不適正認証結果を返信する処理が行なわれて、この認証処理を終了（リターン）する。Ｓ８７、Ｓ８８による認証結果の返信先は、Ｓ３６によるＷｅｂサーバ１４からの認証依頼があったときにはその認証依頼元であるＷｅｂサーバ１４であり、その他の図８（ｃ）、図９（ａ）等のフローチャートで行なわれる場合には、登録要求信号やメールアドレス変更信号を送信してきた携帯電話１である。
【００５７】
Ｓ７６の認証処理の次に、Ｓ７７により、その認証処理の結果が適正であったか否かの判断がなされる。適正であった場合には、Ｓ７８へ進み、受信したメールアドレスを顧客データベース１５内の対応するエリアに記憶する処理が行なわれ、Ｓ７９により、保険対応窓口アドレス（ＵＲＬ）を携帯電話１に返信する処理が行なわれて、このメールアドレス受信時処理が終了する。この保険対応窓口アドレスの返信を受けた携帯電話１では、前述の図５のＳ１４によりＹＥＳの判断がなされ、Ｓ１６による、保険対応窓口のアドレスを登録する処理が行なわれる。
【００５８】
一方、認証結果が不適正であった場合には、Ｓ７７によりＮＯの判断がなされてＳ８０へ進み、受信した端末ＩＤと未登録異常メッセージとを顧客管理サーバ１３により表示する処理が行なわれる。この表示を見た保険会社１１の社員は、未登録の異常が発生したことを認識することができる。この未登録異常の発生原因は、主に２つのことが考えられる。まず第１に、保険契約手続を行なっていないユーザに対して、メール設定時のメール自動送信機能（Ｓ１３）が組込まれた契約ユーザ専用の携帯電話１が販売されたことが考えられる。この場合には、契約ユーザ以外のユーザの携帯電話から登録要求信号が送信されてくるために、当然顧客データベース１５には対応する個人情報が登録されておらず、未登録異常メッセージが表示されることとなる。
【００５９】
第２に、保険契約を行なった契約ユーザに対して契約ユーザ専用の携帯電話１が販売されたが、その契約ユーザの契約申込時の個人情報等が、携帯電話会社６から保険会社１１に送信されて来なかった場合が考えられる。これは、図３の（９）で説明したように、年度末に携帯電話会社６と保険会社１１との間で保険契約金の決済を行なう関係上、携帯電話会社６が保険契約の申込数を実際よりも少なく保険会社１１に申告して年末決済時に過小申告分に相当する保険契約金を不正に携帯電話会社６が入手するという、不正行為が考えられる。このような過小申告による不正行為が発生した場合にも、未登録異常メッセージが表示されることにより、保険会社１１の従業員がその異常に気づき、携帯電話会社６に対してその真相を究明することが可能となる。この過小申告の異常は、契約ユーザに販売された契約ユーザ専用の携帯電話１からメールアドレス設定時に登録要求信号が自動的に保険会社１１の顧客管理サーバ１３へ送信されてくることにより発覚するのであり、これは、顧客ユーザ専用の携帯電話１から携帯電話会社６を経由することなく直接保険会社１１の顧客管理サーバ１３へ自動的に送信されてくるものであるために、過小申告を行なおうとする携帯電話会社６がその自動送信を阻止する術がない。よって、携帯電話会社６による過小申告の不正行為を抑止する効果が期待できる。
【００６０】
この過小申告の不正行為を抑止の効果をより確実にするために、図５のＳ１３により、加入契約した保険の数（たとえば端末ＩＤが７１０４３６では「２」）を併せて送信し、顧客データベース１５内の該当する顧客の保険情報の保険の数をも、Ｓ１５１で認証チェックするようにしてもよい。
【００６１】
また、過小申告の不正行為を抑止の効果のみのためであれば、自動送信する対象は、契約ユーザの設定したメールの自動送信に限らず、契約ユーザが購入した携帯電話１を操作（たとえば購入後初回の電話等）したときに何らかの情報（たとえば１人契約加入した旨の情報や加入契約数情報等）を自動送信するようにしてもよい。
【００６２】
図９（ａ）は、Ｓ６２のメールアドレス変更受信時処理の具体的制御内容を示すフローチャートである。Ｓ９０により、メールアドレス変更信号を受信したか否かの判断がなされ、受信していない場合にはこのメールアドレス変更受信時処理が終了する。一方、図６のＳ２３に従って携帯電話１からメールアドレス変更信号とともに新メールアドレスと電話番号と端末ＩＤとが送信されてくれば、Ｓ９０によりＹＥＳの判断がなされ、Ｓ９１により、前述の認証処理が行なわれる。
【００６３】
そして、Ｓ９２により、認証処理の結果が適正であったか否かの判断が行なわれる。適正の場合には、Ｓ９３へ進み、受信した新メールアドレスを顧客データベース１５内の対応するエリアに記憶する処理が行なわれる。一方、認証処理の結果が不適正であった場合には、Ｓ９４へ進み、受信した端末ＩＤと未登録異常メッセージとを顧客管理サーバ１３により表示する処理が行なわれる。
【００６４】
図９（ｂ）は、Ｓ６５の事故請求登録処理の具体的制御内容を示すフローチャートである。Ｓ９５により、事故請求登録要求があったか否かの判断がなされ、ない場合にはこの事故請求登録処理が終了する。一方、Ｓ４６、Ｓ５２、Ｓ５３、Ｓ２０３、Ｓ２０４に従って携帯電話１から事故請求時における記入事項データや撮像データ等がＷｅｂサーバ１４へ送信され、Ｗｅｂサーバ１４において後述する図１１（ａ）のＳ１３７に従って事故請求登録要求と受信した記入事項データと現在位置と端末ＩＤのデータが顧客管理サーバ１３へ送信する処理が行なわれれば、Ｓ９５によりＹＥＳの判断がなされてＳ９６へ進む。Ｓ９６では、受信した端末ＩＤに基づいて顧客データベース１５を検索し、対応するエリアに事故請求データを記憶する処理が行なわれる。
【００６５】
図９（ｃ）は、Ｓ６６の年度末精算処理の具体的制御内容を示すフローチャートである。Ｓ１００により、年度末精算操作があったか否かの判断がなされ、ない場合にはこの年度末精算が終了する。保険会社１１の従業員が顧客管理サーバ１３を操作して年度末精算操作を行なえば、Ｓ１００によりＹＥＳの判断がなされてＳ１０１へ進み、顧客データベースをチェックして今年度の保険契約の申込数を算出集計する処理が行なわれる。たとえば、図１の顧客データベース１５に記憶されている端末ＩＤが７１０４３６のユーザの場合には、１人で２つの保険（賠償責任保険と交通傷害保険）に加入しているために、１人でありながら契約数を「２」とカウントする。次にＳ１０２へ進み、申込数×２０００円を算出して、今年度の契約金額を求める処理が行なわれる。次にＳ１０３へ進み、今年度契約金額−受取概算保険料（図３（１）に従って携帯電話会社６から払い込まれた概算保険料支払額）の計算を行ない、収支を算出する処理が行なわれる。そして、Ｓ１０４により、その算出された収支を顧客管理サーバ１３により表示する処理が行なわれる。この収支の値がプラスの場合には、そのプラスの収支金額だけ、携帯電話会社６に請求することとなる。逆に、収支がマイナスの値の場合には、そのマイナスの収支金額を保険会社１１が携帯電話会社６へ支払うこととなる。
【００６６】
図１０は、Ｗｅｂサーバ１６の制御動作を示すフローチャートである。まずＳ１１０により、携帯電話１から保険会社１１のホームページにアクセスがあったか否かの判断がなされ、ない場合にはこのＷｅｂサーバの処理が終了する。一方、ユーザが携帯電話１を操作してホームページにアクセスした場合には、制御がＳ１１１へ進み、保険対応窓口へのアクセスであるか否かの判断が行なわれる。保険対応窓口へのアクセスでない場合には、その他のＷｅｂサーバ処理がＳ１１２により行なわれ、その後Ｗｅｂサーバの処理が終了する。一方、ユーザが携帯電話１を操作して保険対応窓口にアクセスした場合には、Ｓ１１１によりＹＥＳの判断がなされてＳ１１３へ進み、端末ＩＤを受信したか否かの判断が行なわれ、受信するまで待機する。携帯電話１では、前述の図７のＳ２７で説明したように、保険対応窓口にアクセスした後そのアクセスした携帯電話１の端末ＩＤを自動送信する処理が行なわれるのであり、携帯電話１から端末ＩＤが送信されてくれば、Ｓ１１３によりＹＥＳの判断がなされてＳ１１４へ進み、認証依頼を顧客管理サーバ１３へ出す処理が行なわれる。
【００６７】
その後、Ｓ１１５により、適正認証結果を受信したか否かの判断がなされ、未だ受信していない場合にはＳ１１６へ進み、不適正認証結果を受信したか否かの判断がなされ、未だ受信していない場合にはＳ１１５へ戻る。認証依頼を受けた顧客管理サーバ１３では、前述のＳ６３によりＹＥＳの判断がなされてＳ６４による認証処理が実行され、Ｓ８７による適正認証結果の返信またはＳ８８による不適正認証結果の返信を行なう。不適正認証結果の返信が行なわれてくれば、Ｓ１１６によりＹＥＳの判断がなされてＳ１２４へ進み、不適正認証結果を携帯電話１へ返信する処理が行なわれる。これを受けた携帯電話１では、前述の図７のＳ３０により、不適正表示を行なう。一方、顧客管理サーバ１３から適正認証結果が返信されてくれば、Ｓ１１５によりＹＥＳの判断がなされてＳ１１７へ進み、適正認証結果を携帯電話１へ返信する処理が行なわれる。これを受けた携帯電話１では、前述の図７のＳ２９によりＹＥＳの判断がなされてＳ３１により、保険対応窓口ページを表示する処理が行なわれる。
【００６８】
Ｗｅｂサーバ１４では、Ｓ１１７の処理の後、Ｓ１１８により、保険対応窓口ページを携帯電話１に送信する処理が行なわれる。次に、Ｓ１１９に進み、事故請求窓口へのアクセスがあったか否かの判断がなされ、未だない場合にはＳ１２０により、相談窓口へのアクセスがあったか否かの判断がなされ、未だない場合にはＳ１２１に進み、キャンセル操作があったか否かの判断がなされ、未だない場合にはＳ１１９へ戻る。
【００６９】
Ｓ１１９→Ｓ１２０→Ｓ１２１→Ｓ１１９のループの巡回途中で、携帯電話１から図７のＳ３４に従ってキャンセル操作が行なわれた場合には、Ｓ１２１によりＹＥＳの判断がなされてこのＷｅｂサーバの処理が終了する。一方、図７のＳ３３に従って相談窓口へのアクセスが行なわれた場合には、Ｓ１２０によりＹＥＳの判断が行なわれてＳ１２２へ進み、相談窓口のページを携帯電話１に送信する処理が行なわれ、Ｓ１２３により、相談対応処理が行なわれてこのＷｅｂサーバの処理が終了する。
【００７０】
さらに、携帯電話１により前述の図７のＳ３２に従って事故請求窓口へのアクセスが行なわれた場合には、Ｓ１１９によりＹＥＳの判断がなされて、図１１（ａ）に示すＳ１２５へ進み、交通事故の選択操作があったか否かの判断がなされ、未だない場合にはＳ１２６に進み、賠償責任事故の選択操作があったか否かの判断がなされ、未だない場合にはＳ１２７へ進み、携帯電話破損事故の選択操作があったか否かの判断がなされ、未だない場合にはＳ１３３へ進み、キャンセル操作があったか否かの判断がなされ、未だない場合にはＳ１２５へ戻る。
【００７１】
Ｓ１２５→Ｓ１２６→Ｓ１２７→Ｓ１３３→Ｓ１２５のループの巡回途中で、携帯電話１により、図７のＳ３８に従ってキャンセル操作が行なわれた場合には、Ｓ１３３によりＹＥＳの判断がなされてこのＷｅｂサーバの処理が終了する。携帯電話１により、図７のＳ３６に従って交通事故の選択操作が行なわれた場合には、Ｓ１２５によりＹＥＳの判断がなされてＳ１２８へ進み、交通事故時記入ページ（交通事故請求窓口ページ）を携帯電話１に送信する処理がなされた後、Ｓ１３０へ進む。
【００７２】
Ｓ１３０では、記入事項と写真データと現在位置とを受信したか否かの判断がなされ、未だ受信していない場合にはＳ１３１へ進み、キャンセル操作が行なわれたか否かの判断がなされ、未だ操作されていない場合にはＳ１３０へ戻る。
【００７３】
携帯電話１において、図７のＳ４８またはＳ５８によりキャンセル操作が行なわれた場合には、Ｓ１３１によりＹＥＳの判断がなされてこのＷｅｂサーバの処理が終了する。一方、携帯電話１において、図７のＳ５２、Ｓ５３に従って記入事項と写真データと現在位置とが送信されてくれば、Ｓ１３０によりＹＥＳの判断がなされてＳ１３２へ進み、事故請求登録要求と受信した記入事項と写真データと現在位置と端末ＩＤとを顧客管理サーバ１３へ送信する処理が行なわれる。
【００７４】
一方、携帯電話１において、図７のＳ３７に従って賠償責任事故の選択操作が行なわれた場合には、Ｓ１２６によりＹＥＳの判断がなされてＳ１２９へ進み、賠償責任事故時記入ページ（賠償責任事故請求窓口ページ）を携帯電話１に返信する処理が行なわれる。その後、Ｓ１３０→Ｓ１３１→Ｓ１３０のループを巡回することとなる。このループの巡回途中で、携帯電話１において、図７のＳ４２またはＳ４５に従ってキャンセル操作が行なわれれば、Ｓ１３１によりＹＥＳの判断がなされてこのＷｅｂサーバの処理が終了する。一方、携帯電話１において、Ｓ４６、Ｓ５３に従って記入事項と写真データと現在位置とのデータが送信されてくれば、Ｓ１３０によりＹＥＳの判断がなされて、Ｓ１３２の処理が実行される。
【００７５】
携帯電話１において、図７のＳ５４に従って携帯電話破損事故が選択されれば、Ｓ１２７によりＹＥＳの判断がなされてＳ１３４へ進み、携帯電話破損時記入ページ（携帯電話破損事故請求窓口ページ）を携帯電話１に返信する処理が行なわれる。その後、Ｓ１３５により、記入事項データを受信したか否かの判断がなされ、未だ受信していない場合にはＳ１３６に進み、キャンセル操作が行なわれたか否かの判断がなされ、未だなされていない場合にはＳ１３５へ戻る。
【００７６】
携帯電話１において、図１１（ｂ）のＳ２０２によりキャンセル操作が行なわれた場合には、Ｓ１３６によりＹＥＳの判断がなされてこのＷｅｂサーバの処理が終了する。一方、携帯電話１において、図１１（ｂ）のＳ２０３、Ｓ２０４に従って記入事項データと現在位置とのデータが送信されてくれば、Ｓ１３５によりＹＥＳの判断がなされてＳ１３７へ進み、事故請求登録要求と受信した記入事項データと現在位置と端末ＩＤとを顧客管理サーバ１３へ送信する処理が行なわれる。それを受けた顧客管理サーバ１３では、前述の図９のＳ９５によりＹＥＳの判断がなされてＳ９６の登録処理が実行される。
【００７７】
図１２、図１３は、保険処理サーバ８の制御動作を示すフローチャートである。
図１２（ａ）を参照して、Ｓ１４０により、保険契約の申込手続と携帯電話の申込手続とが行なわれたときに実行される申込時処理が行なわれ、Ｓ１４１により、メールアドレス受信時処理が行なわれ、Ｓ１４２により、メールアドレス変更受付時処理が行なわれ、Ｓ１４３により年度末精算処理が行なわれた後、Ｓ１４０へ戻る。
【００７８】
図１２（ｂ）は、Ｓ１４０に示された購入時処理の具体的制御内容を示すフローチャートである。Ｓ１４５により、申込データの入力があったか否かの判断がなされ、ない場合にはこの申込時処理が終了する。一方、前述の図３の（２）に基づいて説明した申込書データが保険処理サーバ８に入力された場合には、Ｓ１４５によりＹＥＳの判断がなされ、Ｓ１４６に進み、申込書データに基づいて顧客データベース１０にメールアドレス以外のデータ（端末ＩＤ、氏名、住所、電話番号、保険情報）を登録する処理が行なわれる。次に、Ｓ１４７に進み、申込書データを保険会社１１の顧客管理サーバ１５へ送信する処理が行なわれる。
【００７９】
図１２（ｃ）は、Ｓ１４１に示したメールアドレス受信時処理の具体的制御内容を示すフローチャートである。このメールアドレス受信時処理は、図８（ｃ）に示したメールアドレス受信時処理とほぼ同様であり、相違点としては、図８（ｃ）のＳ７９の処理が行なわれない点である。それ以外は同様であるために、ここでの説明の繰返しを省略する。
【００８０】
図１２（ｄ）は、Ｓ１５１の認証処理の具体的制御内容を示すフローチャートである。この認証処理は、図８の（ｄ）に示した認証処理と同じ制御内容であり、ここでの説明の繰返しを省略する。
【００８１】
図１３（ａ）は、Ｓ１４２のメールアドレス変更受信時処理の具体的制御内容を示すフローチャートである。このメールアドレス変更受信時処理は、図９（ａ）に示したメールアドレス変更受信時処理と同様の内容であり、ここでの説明の繰返しを省略する。
【００８２】
図１３（ｂ）は、Ｓ１４３に示した年度末精算処理の具体的制御内容を示すフローチャートである。まずＳ１６５により、年度末精算操作があったか否かの判断がなされ、ない場合にはこの年度末精算処理が終了する。携帯電話会社６の従業員が保険処理サーバを操作して、年度末精算操作を行なえば、Ｓ１６５によりＹＥＳの判断がなされてＳ１６６へ進み、顧客データベース１０をチェックして今年度の保険契約の申込数を算出集計する処理が行なわれる。次にＳ１６７に進み、申込数×２０００円を計算して今年度契約金額を算出する処理が行なわれる。次にＳ１６８へ進み、今年度契約金額−支払概算保険料（図３の（１）の説明参照）の計算を行なって収支を算出する処理が行なわれる。次にＳ１６９へ進み、その算出された収支を保険処理サーバ８により表示する処理が行なわれる。この収支の値がプラスの場合には、そのプラスの収支の金額を携帯電話会社６が保険会社１１に対して請求することとなり、収支の値がマイナスの場合には、そのマイナスの収支金額を携帯電話会社６が保険会社１１に支払うこととなる。
【００８３】
［変形例］
次に、以上説明した実施の形態における変形例を列挙する。
【００８４】
（１） 前述の実施の形態では、携帯電話の購入手続と保険契約の申込手続とが携帯電話会社６の窓口にて所定用紙に所定事項を記載することにより行なわれるもの（オフライン契約）を示した。しかし、その代わりに、ユーザのパーソナルコンピュータ等を用いて、インターネット経由で携帯電話会社の申込窓口サイトにアクセスし、予め用意されている保険契約セット型の携帯電話申込ページにおいて、保険契約者および被保険者の個人情報を含む所定事項を記入して申込ができるオンライン契約にしてもよい。その場合において、身分証明書の写等は、携帯電話会社６に郵送し、電話確認がなされるようにする。料金プランや、携帯電話の操作方法、取扱注意、重要説明事項をインターネット経由でユーザのパーソナルコンピュータに動画で紹介し、最後に本人確認をインターネット経由で送信し、携帯電話の購入手続と保険契約の申込手続とが完了する。そして、携帯電話１が、後日契約ユーザに郵送される。この保険契約の申込手続に関するデータが、携帯電話会社６から保険会社１１に送信され、保険会社１１においても契約内容のデータが登録される。これにより、書類の簡素化と手続のスピードアップとが図られる。
【００８５】
（２） 契約ユーザ専用の携帯電話１に予め組込まれる契約保険契約ユーザのための支援機能として、前述のＳ１３、Ｓ２３のほかに、保険会社１１の保険対応窓口のアドレス（ＵＲＬ）を事前にメモリ（お気に入り等）２３に記憶させておいてもよい。さらには、事故発生時に一般的にユーザが連絡する機関（たとえば警察や消防署等）の電話番号（たとえば１１０番や１１９番等）が携帯電話１に入力されて通話が行なわれた場合に、その通話終了後自動的に事故が発生した旨が携帯電話１から保険会社１１の顧客管理サーバ１３へ送信され、顧客管理サーバにおいて対応するユーザの電話番号を検索し、保険会社１１からその電話番号に電話がかかるような仕組みにしてもよい。このようにすれば、保険会社１１からの電話によって、ユーザに保険対応窓口ページへのアクセスを促すことができ、事故発生後ユーザが保険対応窓口ページへのアクセスを忘れてしまう不都合を防止することができる。
【００８６】
（３） 前述の実施の形態では、携帯電話１の端末ＩＤを顧客データベース１５、１０に登録し、その端末ＩＤに基づいて顧客データベース１５、１０を検索するようにしたが、この端末ＩＤの代わりにまたはそれに加えて、クッキー（ｃｏｏｋｉｅ）を利用するようにしてもよい。具体的には、契約ユーザに販売する専用の携帯電話１のメモリ２３に、当該携帯電話１を識別するためのクッキーを記憶させた上で、その携帯電話１を契約ユーザに販売し、顧客データベース１５、１０には、そのクッキーとともに契約ユーザの個人情報等を登録しておく。そして、携帯電話１から、Ｗｅｂサーバ１４、顧客管理サーバ１３、あるいは保険処理サーバ８にアクセスがあった場合に、携帯電話１からメモリ２３に記憶されているクッキーをそれらサーバに送信し、サーバ側において、受信したクッキーに基づいて顧客データベース１５、１０を検索し、対応する個人情報を割り出すことができるように構成する。
【００８７】
（４） 今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなく特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【図面の簡単な説明】
【００８８】
【図１】保険システムの全体構成を示すシステム図である。
【図２】携帯電話の機能ブロック図である。
【図３】保険システムの流れを示す説明図である。
【図４】携帯電話の制御を示すフローチャートである。
【図５】メールアドレス設定時処理の具体的制御内容を示すフローチャートである。
【図６】メールアドレス変更時処理の具体的制御内容を示すフローチャートである。
【図７】Ｗｅｂブラウザ処理の具体的制御内容を示すフローチャートである。
【図８】（ａ）は顧客管理サーバの制御を示すフローチャートであり、（ｂ）は申込時処理の具体的制御内容を示すフローチャートであり、（ｃ）はメールアドレス受信時処理の具体的制御内容を示すフローチャートであり、（ｄ）は認証処理の具体的制御内容を示すフローチャートである。
【図９】（ａ）はメールアドレス変更受信時処理の具体的制御内容を示すフローチャートであり、（ｂ）は事故請求登録処理の具体的制御内容を示すフローチャートであり、（ｃ）は年度末精算処理の具体的制御内容を示すフローチャートである。
【図１０】Ｗｅｂサーバの制御動作を示すフローチャートである。
【図１１】（ａ）はＷｅｂサーバの制御動作の続きを示すフローチャートであり、（ｂ）はＷｅｂブラウザ処理の続きを示すフローチャートである。
【図１２】（ａ）は保険処理サーバの制御動作を示すフローチャートであり、（ｂ）は申込時処理の具体的制御内容を示すフローチャートであり、（ｃ）はメールアドレス受信時処理の具体的制御内容を示すフローチャートであり、（ｄ）は認証処理の具体的制御内容を示すフローチャートである。
【図１３】（ａ）はメールアドレス変更受信時処理の具体的制御内容を示すフローチャートであり、（ｂ）は年度末精算処理の具体的制御内容を示すフローチャートである。
【符号の説明】
【００８９】
１ 携帯電話、５ インターネット、６ 携帯電話会社、８ 保険処理サーバ、１０ 顧客データベース、１１ 保険会社、１３ 顧客管理サーバ、１５ 顧客データベース、１４ Ｗｅｂサーバ、１６ Ｗｅｂデータベース、２２ 制御部、２３ メモリ、２４ 操作部、２６ デジタルカメラ、２７ 表示部、３０ 顧客（契約者）。
【特許請求の範囲】
【請求項１】
ユーザの保険契約をコンピュータを用いて管理する保険システムであって、
ユーザによる保険契約の申込手続が行なわれた場合に該ユーザの個人情報および契約内容に関する情報を登録する保険業務用サーバと、
ユーザによる携帯通信端末の購入手続が行なわれた場合に、該ユーザの個人情報を、登録する携帯通信用サーバと、
前記携帯通信端末の購入手続と前記保険契約の申込手続とを行なうユーザが１回提示した個人情報を、前記保険業務用サーバと前記携帯通信用サーバとの両方に登録する個人情報登録手段とを備えている、保険システム。
【請求項２】
前記携帯通信用サーバを運用する携帯通信端末会社が、前記携帯通信端末の購入手続と前記保険契約の申込手続とを受付けたときに保険契約ユーザから支払われた当該保険契約の契約金を、前記保険業務用サーバを運用する保険会社との間で決済するための処理を行なう決済処理手段をさらに備え、
該決済処理手段は、
前記保険業務用サーバに登録された保険契約ユーザの保険契約登録数を集計する保険会社側集計手段と、
前記携帯通信用サーバに登録された保険契約ユーザの保険契約登録数を集計する携帯通信端末会社側集計手段とを含む、請求項１に記載の保険システム。
【請求項３】
ユーザが携帯通信端末を購入する際に、該ユーザが前記保険契約を希望し該保険契約の申込手続と携帯通信端末の購入手続とを行なった場合に、当該ユーザに提供される携帯通信端末をさらに備え、
前記携帯通信端末は、当該携帯通信端末にメールアドレスを設定した際に該メールアドレスを自動的に前記保険業務用サーバへ送信する自動送信手段を備え、
前記保険業務用サーバは、
前記自動送信手段により前記メールアドレスが送信されてきた場合に、該メールアドレスの送信元のユーザが前記個人情報登録手段により個人情報が登録されている登録済ユーザであるか否か判定する登録判定手段と、
該登録判定手段により登録済ユーザであると判定された場合に該登録済ユーザの個人情報に対応させて前記送信されてきたメールアドレスを登録するメールアドレス登録手段と、
前記登録判定手段により登録済ユーザでないと判定された場合に異常報知を行なう異常報知手段とを含む、請求項１または請求項２に記載の保険システム。
【請求項１】
ユーザの保険契約をコンピュータを用いて管理する保険システムであって、
ユーザによる保険契約の申込手続が行なわれた場合に該ユーザの個人情報および契約内容に関する情報を登録する保険業務用サーバと、
ユーザによる携帯通信端末の購入手続が行なわれた場合に、該ユーザの個人情報を、登録する携帯通信用サーバと、
前記携帯通信端末の購入手続と前記保険契約の申込手続とを行なうユーザが１回提示した個人情報を、前記保険業務用サーバと前記携帯通信用サーバとの両方に登録する個人情報登録手段とを備えている、保険システム。
【請求項２】
前記携帯通信用サーバを運用する携帯通信端末会社が、前記携帯通信端末の購入手続と前記保険契約の申込手続とを受付けたときに保険契約ユーザから支払われた当該保険契約の契約金を、前記保険業務用サーバを運用する保険会社との間で決済するための処理を行なう決済処理手段をさらに備え、
該決済処理手段は、
前記保険業務用サーバに登録された保険契約ユーザの保険契約登録数を集計する保険会社側集計手段と、
前記携帯通信用サーバに登録された保険契約ユーザの保険契約登録数を集計する携帯通信端末会社側集計手段とを含む、請求項１に記載の保険システム。
【請求項３】
ユーザが携帯通信端末を購入する際に、該ユーザが前記保険契約を希望し該保険契約の申込手続と携帯通信端末の購入手続とを行なった場合に、当該ユーザに提供される携帯通信端末をさらに備え、
前記携帯通信端末は、当該携帯通信端末にメールアドレスを設定した際に該メールアドレスを自動的に前記保険業務用サーバへ送信する自動送信手段を備え、
前記保険業務用サーバは、
前記自動送信手段により前記メールアドレスが送信されてきた場合に、該メールアドレスの送信元のユーザが前記個人情報登録手段により個人情報が登録されている登録済ユーザであるか否か判定する登録判定手段と、
該登録判定手段により登録済ユーザであると判定された場合に該登録済ユーザの個人情報に対応させて前記送信されてきたメールアドレスを登録するメールアドレス登録手段と、
前記登録判定手段により登録済ユーザでないと判定された場合に異常報知を行なう異常報知手段とを含む、請求項１または請求項２に記載の保険システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２００８−２６９２２９（Ｐ２００８−２６９２２９Ａ）
【公開日】平成２０年１１月６日（２００８．１１．６）
【国際特許分類】
【出願番号】特願２００７−１１０５４１（Ｐ２００７−１１０５４１）
【出願日】平成１９年４月１９日（２００７．４．１９）
【出願人】（５０５３９８９６３）西日本高速道路株式会社 (105)
【Ｆターム（参考）】
【公開日】平成２０年１１月６日（２００８．１１．６）
【国際特許分類】
【出願日】平成１９年４月１９日（２００７．４．１９）
【出願人】（５０５３９８９６３）西日本高速道路株式会社 (105)
【Ｆターム（参考）】
[ Back to top ]