JP4383685B2 - 情報提供方法 - Google Patents
情報提供方法 Download PDFInfo
- Publication number
- JP4383685B2 JP4383685B2 JP2001083594A JP2001083594A JP4383685B2 JP 4383685 B2 JP4383685 B2 JP 4383685B2 JP 2001083594 A JP2001083594 A JP 2001083594A JP 2001083594 A JP2001083594 A JP 2001083594A JP 4383685 B2 JP4383685 B2 JP 4383685B2
- Authority
- JP
- Japan
- Prior art keywords
- insurance
- information
- transaction
- solicitation
- subscriber
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims description 130
- 238000004364 calculation method Methods 0.000 claims description 8
- 239000000284 extract Substances 0.000 claims description 5
- 238000000605 extraction Methods 0.000 claims 2
- 238000012545 processing Methods 0.000 description 42
- 230000006870 function Effects 0.000 description 27
- 238000010586 diagram Methods 0.000 description 18
- 238000001514 detection method Methods 0.000 description 13
- 230000005540 biological transmission Effects 0.000 description 12
- 238000012544 monitoring process Methods 0.000 description 10
- 238000003672 processing method Methods 0.000 description 8
- 238000012795 verification Methods 0.000 description 8
- 230000004044 response Effects 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 6
- 238000005315 distribution function Methods 0.000 description 3
- 238000012905 input function Methods 0.000 description 2
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000000994 depressogenic effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000001404 mediated effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- Technology Law (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Development Economics (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、インターネットなどのコンピュータネットワークを用いて電子商取引を行う際に、取引当事者の保護を図る技術に関する。
【０００２】
【従来の技術】
近年、インターネットなどのコンピュータネットワークを用いて、商品などを売買する電子商取引が盛んになってきた。電子商取引では、取引相手が不明である場合も多く、例えば、取引相手が悪意を持っていれば、詐欺などのトラブルが発生するおそれがあった。また、取引相手が悪意を持っていなくとも、商品の配送経路や代金の支払い経路において、商品の破損や依頼伝票の紛失などの事故が発生してしまうおそれもあった。このため、保険業者から、電子商取引において発生した損失を補填する保険制度が提供されている。この保険制度では、電子商取引を行う前に、予想され得る事故項目に対応した保険契約を締結する必要があった。
【０００３】
【発明が解決しようとする課題】
しかしながら、電子商取引では、取引頻度が多く、その取引額が小額であることが多いため、従来の保険制度に加入する者は少なかった。また、電子商取引では、取引ごとに取引相手や取引内容が異なることが多いため、従来の保険制度に加入するのは煩雑でもあった。
【０００４】
一方、電子商取引において発生した損失を補填するには、従来の自動車保険制度と同様に、事故が発生した事実を客観的に立証する必要がある。しかし、電子商取引では、取引相手の実態が不明である場合も多く、双方の陳述に基づいて事故を客観的に立証することが困難であった。また、現実の公証役場の機能をネットワーク上で実現する「電子公証システム」により、電子商取引における事故の発生を客観的に立証しようという構想もある。しかし、電子公証システムでは、高額かつ重要なものを公証対象とし、その手続も厳密であるため、取引頻度が多く、その取引額が小額である電子商取引には不向きなものであった。
【０００５】
従って、電子商取引における取引当事者は、保険制度に未加入であることが多く、また、保険制度に加入していても事故発生の立証が客観的に行えないため、発生した損失が補填されず、保護が不十分になるおそれがあった。
そこで、本発明は以上のような従来の問題点に鑑み、電子商取引中に保険加入を促す一方、事故発生を客観的に立証できるようにすることで、取引当事者の保護を図った保険業務処理技術を提供することを目的とする。
【０００６】
【課題を解決するための手段】
このため、電子商取引中に保険加入を促すために、本発明に係る保険業務処理技術では、コンピュータネットワークを流通する電子情報を監視し、その中に保険勧誘の契機となる勧誘キーワードが含まれていたときに、電子情報を交換していた当事者の少なくとも一方に保険勧誘情報を配信することを特徴とする。
【０００７】
かかる構成によれば、コンピュータネットワークを流通する電子情報の中に、保険勧誘の契機となる勧誘キーワードが含まれていると、電子情報を交換していた当事者の少なくとも一方に保険勧誘情報が配信される。このため、当事者は、電子商取引に際しての危険性を再認識することが可能となる。また、保険勧誘情報に、保険商品の加入申請画面へのリンク情報を埋め込んでおけば、簡単な操作により加入申請画面が表示される。このため、当事者は、電子商取引中に簡単な操作で保険に加入することができ、当事者の保護が図られる。
【０００８】
このとき、保険未加入である当事者に対して保険勧誘情報を配信するようにすれば、保険加入済みである当事者には保険勧誘情報が配信されず、その者が煩わしいと感じることが防止される。また、当事者が保険加入済みであっても、保険が無効であるとき、又は、過去に電子商取引に係る事故の遭遇経験があるときには、その者に保険勧誘情報を優先して配信するようにすれば、保険の必要性を感じている当事者に対して、電子商取引における危険性を再確認させる機会が与えられる。さらに、電子情報の内容に応じて選択した保険業者からの保険勧誘情報を配信するようにすれば、取引内容に適合しない保険に加入することが防止され、本発明の目的が効果的に奏されることとなる。
【０００９】
ここで、通常の保険料率より割り引かれた保険料率を用い、取引価格に応じて演算された保険料を受信すると共に、受信された保険料と取引価格との合計を演算し、演算された保険料及び合計を当事者の双方に提示することが望ましい。
かかる構成によれば、双方の当事者が保険に加入する場合には、通常の保険料率より割り引かれた割引保険料率に基づき保険料が決定される。このため、当事者の一方のみが保険に加入する場合と比べて、当事者の保険加入に係る金銭的負担が軽減され、取引交渉中に保険に気楽に加入することが可能となる。また、当事者の双方が保険に加入するため、当事者間で金銭的負担が平等となり、一方が保険料を負担することによる不平・不満が緩和される。
【００１０】
また、電子商取引中に保険加入を促すために、本発明に係る保険業務処理技術では、電子商取引に係る取引情報を送信する際に、その中に保険勧誘の契機となる勧誘キーワードが含まれていると、保険業者のサーバから送信されてきた保険勧誘情報を受信することを特徴とする。
かかる構成によれば、電子商取引に係る取引情報を送信する際に、その中に保険勧誘の契機となる勧誘キーワードが含まれていると、保険業者のサーバから送信されてきた保険勧誘情報を受信することとなる。このため、当事者は、電子商取引に際しての危険性を再認識することが可能となる。また、保険勧誘情報に、保険商品の加入申請画面へのリンク情報を埋め込んでおけば、簡単な操作により加入申請画面が表示される。このため、当事者は、電子商取引中に簡単な操作で保険に加入することができ、当事者の保護が図られる。
【００１１】
このとき、取引情報の中に取引キーワードが含まれているとき、取引情報を実際に送信する前に、電子商取引に係る危険性を報知するようにすれば、当事者は、電子商取引における危険性を前もって再確認することが可能となる。このため、当事者をより厚く保護することが可能となる。
一方、事故発生を客観的に立証できるようにするために、本発明に係る保険業務処理技術では、コンピュータネットワークを流通する電子情報を監視し、その中に電子商取引交渉の完了を示す完了キーワードが含まれていたときに、秘密鍵を用いて電子商取引に係る取引情報を暗号化して保存することを特徴とする。
【００１２】
かかる構成によれば、コンピュータネットワークを流通する電子情報の中に、電子商取引交渉の完了を示す完了キーワードが含まれていると、取引情報が秘密鍵により暗号化された後保存される。このため、暗号化された取引情報は、事故立証の証拠として利用されることとなり、当事者の保護が図られる。なお、暗号化された取引情報は、保険金を支払う保険業者により復号化される。
【００１３】
このとき、完了キーワードが含まれていると判定されたときの日付及び時刻に基づいて秘密鍵が生成されるようにすれば、短期間に多数の電子商取引が行われても、各取引内容は異なる秘密鍵により暗号化されることとなる。このため、証拠としての取引内容の改竄は、一層困難となる。また、当事者が加入していた保険業者により秘密鍵が生成されるようにすれば、他の保険業者は取引内容を容易に見ることができず、個人情報の流出が防止される。さらに、暗号化された状態で保険業者から秘密鍵が配信されるようにすれば、秘密鍵が悪意を持った第三者に渡ったとしても、当事者の保護が図られる。
【００１４】
【発明の実施の形態】
以下、添付された図面を参照して本発明を詳述する。
図１は、本発明に係る保険業務処理技術を具現化した、保険業務処理システムの基本構成を示す。
保険業務処理システムは、コンピュータネットワークを構築するインターネット１０を介して相互接続されるクライアント２０，ＷＷＷ（World Wide Web）サーバ３０及び保険業者により運営される保険サーバ４０を含んで構成される。そして、クライアント２０，ＷＷＷサーバ３０及び保険サーバ４０の間では、例えば、インターネットで普及しているＨＴＴＰ（HyperText Transfer Protocol）により相互通信が行われる。また、ＷＷＷサーバ３０のデータベース３２には、電子商取引対象たる商品等の売買情報１００、保険サーバ４０のデータベース４２には、取引当事者に提供される保険勧誘情報１０２が夫々登録される。
【００１５】
なお、クライアント２０，ＷＷＷサーバ３０及び保険サーバ４０は、少なくともメモリと中央処理装置（ＣＰＵ）とを備えたコンピュータにより構成される。そして、メモリにロードされたプログラムにより、保険業務処理システムにおける種々の業務が遂行される。
保険業務処理システムは、電子商取引を仲介するネットワークサービス業者（以下「サービス業者」という）の有無に応じて、次のような２つの形態により運用される。即ち、サービス業者が存在する場合には、図２（Ａ）に示すように、ＷＷＷサーバ３０は、サービス業者により運用される。この場合、クライアント２０は、取引当事者たる買い手Ａ及び売り手Ｂにより利用される。一方、サービス業者が存在しない場合には、図２（Ｂ）に示すように、ＷＷＷサーバ３０は、取引当事者たる売り手Ｂにより運用される。この場合、クライアント２０は、買い手Ａにより利用される。ＷＷＷサーバ３０を買い手Ａが、クライアント２０を売り手Ｂが運用してもよい。なお、図示の運用形態では、保険サーバ４０は、ＡＡ保険，ＢＢ保険及びＣＣ保険により運用される。
【００１６】
クライアント２０及びＷＷＷサーバ３０には、図３に示すように、夫々、ＳＳＬ（Secure Socket Layer）コーダ５０とプロトコルモニタ５２とが備えられたクライアントプログラム２２及びサーバプログラム３４がインストールされる。ＳＳＬコーダ５０では、クライアント２０とＷＷＷサーバ３０との間で秘密通信を行うべく、取引情報の暗号化及び復号化が行われる。一方、プロトコルモニタ５２では、クライアント２０とＷＷＷサーバ３０との間で授受される取引情報の中に、ワード表５４に登録されている勧誘キーワードが含まれているか否かが監視される。そして、取引情報の中に勧誘キーワードが含まれていることが検出されたならば、その旨を示す信号（以下「キーワード検出信号」という）が出力される。なお、プロトコルモニタ５２は、クライアント２０及びＷＷＷサーバ３０の少なくとも一方に備えられていればよい。
【００１７】
ワード表５４は、図４に示すように、２次元の表形式をなしている。ワード表５４の各行（ｊ軸）には、保険勧誘の契機となるキーワードが列（ｉ軸）方向に登録されている。例えば、第１行（ｊ＝１）においては、保険勧誘の契機となる勧誘キーワードとして、「＜ＦＯＲＭ ＰＯＳＴ」が登録されている。
ここで、クライアント２０とＷＷＷサーバ３０との間で授受される取引情報の流れについて、図３を参照しつつ説明する。なお、以下の説明では、ＳＳＬコーダ５０による取引情報の暗号化及び復号化については省略する。
【００１８】
クライアント２０において、ＷＷＷサーバ３０上にある売買情報としてのＨＴＭＬ（HyperText Markup Language）データを参照する場合には、ＨＴＭＬデータ（html-0）１０４の所在を示すＵＲＬ（Uniform Resource Lacator）を含んだ“ＧＥＴ”リクエストがＷＷＷサーバ３０に送信される。“ＧＥＴ”リクエストを受信したＷＷＷサーバ３０では、データベース３２が検索され、ＵＲＬにより特定されるＨＴＭＬデータ１０４がクライアント２０に送信される。ＨＴＭＬデータ１０４を受信したクライアント２０では、これをディスプレイ装置２４に表示することで、売買情報を閲覧できるようになる。
【００１９】
そして、クライアント２０において、例えば、表示された売買情報に対して購入希望事項が入力された後、「送信」ボタンが押されると、購入希望事項を含んだ“ＰＯＳＴ”リクエストがＷＷＷサーバ３０に送信される。このとき、送信された購入希望事項が特定のプログラム（cgi-0）１０６で処理されるべく、ｃｇｉ（Common Gateway Interface）機能を介して指定することができる。
【００２０】
次に、保険業務処理システムにおいて、電子商取引の取引交渉中に、保険勧誘情報を提供する原理について説明する。ここでは、プロトコルモニタ５２はＷＷＷサーバ３０側にのみ備えられると共に、図２（Ａ）に示すように、サービス業者により電子商取引が仲介されるものとする。なお、図２（Ｂ）に示すように、売り手ＢによりＷＷＷサーバ３０が運営されている場合でも同様である。
【００２１】
売り手Ｂは、電子商取引において販売する商品等の売買情報として、例えば、図５に示すようなＨＴＭＬデータ（html-0）１０４を作成する。このＨＴＭＬデータ１０４は、図中左上のような取引画面６０を表示すべく記述されている。ＨＴＭＬデータ１０４では、送信データが特定のプログラム（cgi-0）で処理されること（１）、価格及び数量が入力可能であること（２，３）、送信は「送信」というボタン６２を押し下げることで行われること（４）、などが定義されている。
【００２２】
また、図示の例では、取引画面６０の領域（url-1）６４Ａ〜（url-3）６４Ｃに、３つの保険業者からの保険勧誘情報が表示され得ることが示されている。取引画面６０が表示された直後には、保険勧誘情報が表示されておらず、プロトコルモニタ５２からキーワード検出信号が出力されると、ＨＴＭＬデータ１０４の所定箇所に保険勧誘情報を表示する定義行が挿入される。例えば、ＡＡ保険の保険勧誘情報が表示されるのであれば、ＨＴＭＬデータ１０４の所定箇所に定義行<a href="url-1"><img src="url-1a"></a>が挿入され、領域（url-1）６４ＡにＡＡ保険の勧誘情報が表示される。
【００２３】
売り手Ｂは、ＨＴＭＬデータ１０４を作成した後、図６に示すように、商品情報ＢをＷＷＷサーバ３０のデータベース３２に登録する（手順（１））。商品情報Ｂは、名前（氏名，企業名など）、商品情報の概要（商品名，価格など）、ＨＴＭＬデータ１０４、連絡先（メールアドレスなど）を含んで構成される。なお、以下の説明では、データベース３２に、売り手Ｂの商品情報Ｂの他、売り手Ｃ及びＤの商品情報Ｃ及びＤも登録済みであるものとする。
【００２４】
ＷＷＷサーバ３０の取引仲介プログラム３６は、その一機能を奏するリスティングプログラム３６Ａを起動させる。すると、リスティングプログラム３６Ａは、データベース３２に登録された商品情報Ｂ〜Ｄから商品情報の概要のみを抽出し、これらを電子掲示板７０に掲示する形式に自動編集する（手順（２））。そして、自動編集された商品情報の概要は、電子掲示板７０に一覧表示される。
【００２５】
買い手Ａは、“ＧＥＴ”リクエストを用いて、ＷＷＷサーバ３０の電子掲示板７０にアクセスし（手順（３））、一覧表示の中から商品情報Ｂを指定する。すると、商品情報Ｂに係るＨＴＭＬデータ１０４を要求すべく、買い手Ａのクライアント２０からＷＷＷサーバ３０に対して“ＰＯＳＴ”リクエストが送信される（手順（４））。“ＰＯＳＴ”リクエストを受信したＷＷＷサーバ３０では、“ＰＯＳＴ”リクエストを処理すべく、指定されたプログラム（cgi-0）１０６を起動させる（手順（５））。プログラム１０６は、データベース３２に登録された商品情報ＢからＨＴＭＬデータ１０４を検索し（手順（６））、これを買い手Ａのクライアント２０に送信する（手順（７））。これにより、買い手Ａのクライアント２０には、図５に示す取引画面６０が表示される。その後、買い手Ａと売り手Ｂとの間の売買交渉は、例えば、電子メール，図５に示す取引画面６０を共有する、などの方法で行われる。なお、ここでは、取引画面６０を介して売買交渉が行われるものとする。
【００２６】
取引画面６０において、買い手Ａが価格や数量などの取引情報を入力した後、「送信」ボタン６２を押し下げると、ＷＷＷサーバ３０に取引情報が送信される（手順（８））。取引情報を受信したＷＷＷサーバ３０では、プロトコルモニタ５２を経由させて、取引情報が売り手Ｂのクライアント２０に送信される（手順（９））。
【００２７】
このとき、プロトコルモニタ５２では、ワード表５４が参照され、取引情報の中に保険勧誘の契機となる勧誘キーワードが含まれているか否かが監視される。そして、保険勧誘の契機となる勧誘キーワードが見出されたならば、後述する処理に従って保険勧誘情報を提供する保険業者が選択され、その保険業者の保険サーバ４０に対して、キーワード検出信号が送信される（手順（10））。キーワード検出信号を受信した保険サーバ４０では、ＷＷＷサーバ３０に対してデータベース４２に登録された保険勧誘情報が送信される（手順（11））。保険勧誘情報を受信したＷＷＷサーバ３０では、取引画面６０を構成するＨＴＭＬデータ１０４の所定箇所に、保険勧誘情報を表示する定義行が挿入される。これにより、取引画面６０に保険勧誘情報が表示されることとなる。
【００２８】
なお、手順（８）における処理により、入力ステップ，入力機能，入力手段，送信ステップ，送信機能及び送信手段が実現される。また、手順（10）における一連の処理により、勧誘判定ステップ，勧誘判定機能及び勧誘判定手段が実現される。さらに、手順（11）における処理及びＨＴＭＬデータ１０４に保険勧誘情報を表示する定義行を挿入する処理により、配信ステップ，配信機能及び配信手段が実現される。その他、取引画面６０に保険勧誘情報が表示される処理により、受信ステップ，受信機能及び受信手段が実現される。
【００２９】
図７は、プロトコルモニタ５２において、保険業者を選択する処理内容を示す。
ＷＷＷサーバ３０には、保険勧誘情報を提供する保険業者名が登録された保険業者リスト８０と、取引当事者間における最新取引情報が収集されたモニタリング表８２と、取引情報に応じて選択された保険業者名が登録される答え表８４と、が備えられる。ここで、モニタリング表８２は、クライアント２０とＷＷＷサーバ３０との間で授受される取引情報を監視しているプロトコルモニタ５２により随時更新される。
【００３０】
一方、保険業者の保険サーバ４０には、保険勧誘情報を提供する条件（以下「提供条件」という）を定義した定義表８６が備えられる。ＡＡ保険の定義表８６では、取引価格が５，０００より高く、かつ、オークションであることが提供条件として定義されている。また、ＢＢ保険の定義表８６では、取引価格が１，０００より高く、かつ、売買取引であることが提供条件として定義されている。
【００３１】
ここで、モニタリング表８２に登録されているように、取引価格１，５００、数量２の売買取引が行われようとしているものとする。プロトコルモニタ５２では、保険業者リスト８０とモニタリング表８２とが読み込まれ（手順（１））、保険業者リスト８０に登録された各保険業者の定義表８６が参照される（手順（２））。そして、どの保険業者が取引情報に適合した保険商品を提供しているかが判定される。図示の例では、取引価格が３，０００の売買取引であるので、ＢＢ保険が提供する保険商品が適合していると判定され、その判定結果たるＢＢ保険が答え表８４に登録される（手順（３））。次に、答え表８４が読み込まれ（手順（４））、ＢＢ保険の保険勧誘情報（html-2）１０２の所在を示すＵＲＬが、取引画面６０を定義したＨＴＭＬデータ（html-0）１０４の所定箇所に挿入される（手順（５））。この結果、取引当事者の取引画面６０には、図示するようなＢＢ保険の保険勧誘情報が表示される（手順（６））。
【００３２】
従って、取引画面６０に取引内容に応じた保険勧誘情報が表示されることで、取引当事者は、電子商取引に際しての危険性を再確認することができる。また、保険勧誘情報に、保険業者が提供する保険商品の加入申請画面へのリンク情報を埋め込んでおけば、例えば、これをクリックすることで、保険商品の加入申請画面を表示させることができる。このため、取引当事者は、電子商取引中に簡単な操作で保険に加入することができ、取引当事者の保護を図ることができる。
【００３３】
図８は、取引情報が実際に送信される前に、取引当事者に対して電子商取引における危険性を報知ならしめると共に、保険勧誘情報を提供する原理を示す。
取引当事者のクライアント２０には、前述したＳＳＬコーダ５０，プロトコルモニタ５２及びワード表５４の他に、警告機構５６が備えられる。警告機構５６では、プロトコルモニタ５２からのキーワード検出信号を契機として、主として、ディスプレイ装置２４に警告メッセージを表示する機能が奏される。
【００３４】
そして、取引画面６０において、価格及び数量が入力された後「送信」ボタン６２が押し下げられると、取引情報がプロトコルモニタ５２に伝達される（手順（１））。プロトコルモニタ５２では、伝達された取引情報が監視され、その中にワード表５４に登録された取引キーワードとしての重要単語（例えば、ＰＯＳＴ，ＰＲＩＣＥなど）があるか否かが判定される（手順（２））。取引情報の中に重要単語があることが見出されると、警告機構５６が起動され（手順（３））、ディスプレイ装置２４に警告メッセージが表示される（手順（４））。これと同時に、警告機構５６により、ＷＷＷサーバ３０に対して保険勧誘の契機が訪れたことが通知され（手順（５））、前述したような処理を経て、保険業者から提供された保険勧誘情報がディスプレイ装置２４に表示される（手順（６））。ここまでの処理では、取引画面６０上で「送信」ボタン６２が押し下げられたにもかかわらず、取引情報はＷＷＷサーバ３０に送信されない。そして、再度「送信」ボタン６２が押し下げられると、初めて取引情報がＷＷＷサーバ３０に送信される。
【００３５】
なお、手順（２）における一連の処理により、取引判定ステップが実現される。また、手順（３）における処理により、危険性報知ステップが実現される。
従って、最初の「送信」ボタン６２の押し下げは、警告メッセージ及び保険勧誘情報を表示させるトリガーとして利用されるだけであるので、取引情報が実際に送信される前に、電子商取引における危険性を再確認することができる。この場合、先の実施形態と異なり、取引情報の中に重要単語があっただけで、警告メッセージ及び保険勧誘情報が表示されるため、取引当事者をより厚く保護することができる。
【００３６】
図９は、保険未加入の取引当事者に対して、保険勧誘情報が添付された電子メールを送付するための原理を示す。なお、以下説明する一連の処理により、配信ステップ，配信機能及び配信手段が実現される。
ＷＷＷサーバ３０には、保険業者リスト８０と、取引当事者の名前が登録された当事者リスト８８と、保険勧誘情報の提供先である取引当事者名が登録される答え表８４と、電子メール送付機構９０と、が備えられる。ここで、当事者リスト８８は、取引当事者間の取引履歴、即ち、少なくとも、日付，開始時刻，終了時刻及び取引当事者が登録された取引履歴データベース９２（図１０参照）に基づいて作成される。なお、取引履歴データベース９２は、クライアント２０とＷＷＷサーバ３０との間で授受される取引情報を監視しているプロトコルモニタ５２により、随時更新される。
【００３７】
一方、保険業者の保険サーバ４０には、加入者データベース４４が備えられる。加入者データベース４４には、図１１に示すように、契約番号，保険契約状況，契約者名，契約者住所，保険品目名，保険契約期間，契約日，契約タイプ，取引タイプ，保険料率，保険料，保険金額，保険金の支払方法，取引口座，リンク（同一人の他の保険契約へのリンク）及び事故情報などが登録される。
【００３８】
電子メール送付機構９０では、保険業者リスト８０と当事者リスト８８とが読み込まれ（手順（１））、保険業者リスト８０に登録された各保険業者の加入者データベース４４に対して、当事者リスト８８に登録された各取引当事者の保険契約状況が検索される（手順（２））。そして、後述する処理に従って、取引当事者が取引内容に応じた保険に未加入であると判定されると、その取引当事者名が答え表８４に登録される（手順（３））。次に、答え表８４が読み込まれ（手順（４））、答え表８４に登録された各取引当事者に対して、前述した処理により決定された保険業者の保険勧誘情報が添付された電子メールが送信される（手順（５））。
【００３９】
図１２は、取引当事者が取引内容に応じた保険に未加入であるか否かを判定する処理内容を示す。
ステップ１（図では「Ｓ１」と略記する。以下同様）では、当事者リスト８８から取引当事者名が１つ取り出される。即ち、本ステップが最初に実行されるときには、当事者リスト８８の先頭に登録されている取引当事者名が取り出され、以後実行されるときには、２番目，３番目・・・に登録されている取引当事者名が逐次取り出される。
【００４０】
ステップ２では、保険業者リスト８０から保険業者名が１つ取り出される。即ち、ステップ２〜ステップ７のループ処理を行うに際し、最初に実行されるときには、保険業者リスト８０の先頭に登録されている保険業者名が取り出され、以後実行されるときには、２番目，３番目・・・に登録されている保険業者名が順次取り出される。
【００４１】
ステップ３では、取引当事者名をキーとして、保険業者名により特定される保険業者の加入者データベース４４が検索される。
ステップ４では、加入者データベース４４に取引当事者名が登録済みであるか否かが判定される。即ち、取引当事者は、保険業者から提供される保険に加入したことがあるか否かが判定される。そして、取引当事者名が加入者データベース４４に登録済みであればステップ５へと進み（Ｙｅｓ）、取引当事者名が加入者データベース４４に登録済みでなければステップ９へと進む（Ｎｏ）。
【００４２】
ステップ５では、加入者データベース４４の保険契約状況（図１１参照）に基づいて、取引当事者の保険契約は現在有効であるか否かが判定される。そして、保険契約が有効であればステップ６へと進み（Ｙｅｓ）、保険契約が有効でない、即ち、保険契約が中断又は終了していればステップ９へと進む（Ｎｏ）。
ステップ６では、加入者データベース４４の事故情報（図１１参照）に基づいて、事故情報が登録されているか否か、即ち、取引当事者が事故に遭遇したことがあるか否かが判定される。そして、事故情報が登録されていなければステップ７へと進み（Ｙｅｓ）、事故情報が登録されていればステップ９へと進む（Ｎｏ）。
【００４３】
ステップ７では、保険業者リスト８０に登録されているすべての保険業者名に対する処理が終了したか否かが判定される。そして、処理が終了していればステップ８へと進み（Ｙｅｓ）、処理が終了していなければステップ２へと戻る（Ｎｏ）。
ステップ８では、当事者リスト８８に登録されている全ての取引当事者名に対する処理が終了したか否かが判定される。そして、処理が終了していれば保険未加入判定処理を終了し（Ｙｅｓ）、処理が終了していなければステップ１へと戻る（Ｎｏ）。
【００４４】
ステップ９では、答え表８４に取引当事者名が登録され、ステップ９へと進む。このとき、答え表８４に取引当事者名が既に登録済みであるときには、重複した登録を排除するために、登録処理をスキップすることが望ましい。
以上説明したステップ１〜ステップ９の処理によれば、（１）取引当事者名がいずれかの加入者データベース４４に登録されていないとき、（２）取引当事者の保険契約が無効であるとき、（３）取引当事者が事故に遭遇したことがあるとき、その当事者名が答え表８４に登録される。即ち、取引当事者が、取引内容に応じた保険に未加入であるときに、取引当事者に対して保険勧誘情報を提供すべく、その取引当事者名が答え表８４に登録される。
【００４５】
従って、取引内容に応じた保険に加入済みである取引当事者には、保険勧誘情報は提供されず、不要な保険勧誘情報が提供されることで、取引当事者が煩わしいと感じることを防止することができる。一方、過去に事故に遭遇し、保険加入の必要性を感じている取引当事者には、優先的に保険勧誘情報が提供されるため、電子商取引における危険性を再認識することができる。
【００４６】
なお、本実施形態では、当事者リスト８８の代わりに、少なくとも、双方の取引当事者名が登録されたモニタリング表８２を用いてもよい。この場合、モニタリング表８２は、クライアント２０とＷＷＷサーバ３０との間で授受される取引情報を監視するプロトコルモニタ５２により、例えば、電子商取引の開始又は終了を契機として、逐次更新される。
【００４７】
また、本実施形態では、プロトコルモニタ５２からのキーワード検出信号に応じて保険勧誘情報が提供されたが、一方の取引当事者からの指示により、他方の取引当事者に対して保険勧誘情報が提供されるようにしてもよい。
さらに、電子商取引における取引交渉が完了した後、即ち、取引交渉は完了したが、取引自体は行われていないときに、保険未加入である取引当事者に対して保険勧誘情報が提供されるようにしてもよい。このようにすれば、取引当事者は、取引交渉の完了後であっても保険に加入することができ、取引当事者の保護を一層厚くすることができる。
【００４８】
その他、電子メール送付機構９０は、保険業者の保険サーバ４０に備えられる構成であってもよい。
図１３は、取引当事者の依頼に応じて、保険未加入の取引当事者に対して、保険勧誘情報を提供する原理を示す。ここでは、クライアント２０又はＷＷＷサーバ３０には、保険加入勧誘機構９４が備えられ、保険業者の保険サーバ４０には、加入者データベース４４が備えられるものとする。なお、以下説明する一連の処理により、配信ステップ，配信機能及び配信手段が実現される。
【００４９】
取引当事者Ａのクライアント２０から保険加入勧誘機構９４に対して、取引相手たる取引当事者Ｂの保険加入状況の照会指示があると、ＷＷＷサーバ３０に備えられた保険業者リスト８０が入力される（手順（１））。すると、図９に示す実施形態と同様に、各保険業者の保険サーバ４０に対して、取引当事者Ｂの保険加入状況が照会される（手順（２））。取引当事者Ｂの保険加入状況は、取引当事者Ａのクライアント２０に表示される（手順（３））。また、取引当事者Ｂが保険未加入であると、取引当事者Ａが加入している保険業者の保険サーバ４０に対して、取引当事者Ｂに保険勧誘情報を送信するよう依頼がなされる（手順（４））。保険勧誘情報の送信依頼を受信した保険サーバ４０では、取引当事者Ｂのクライアント２０に対して、保険勧誘情報が送信される（手順（５））。
【００５０】
従って、取引当事者Ａは、取引交渉中に、取引相手たる取引当事者Ｂの保険加入状況をいつでも確認することができ、取引相手の信頼度を推し量ることができる。また、取引当事者Ｂが保険未加入であるときには、取引当事者Ｂに対して保険勧誘情報が送信される。このため、取引当事者Ａは、保険勧誘情報が送信された取引当事者Ｂの対応によって、例えば、保険加入を拒むのならば、取引当事者Ｂとの取引交渉を中止するなどの対策をとることで、損害発生を未然に防止することができる。
【００５１】
図１４は、キーワード検出信号に応じて、保険未加入の取引当事者に対して、保険勧誘情報を提供する原理を示す。ここでは、サービス業者によりＷＷＷサーバ３０が運営され、ＷＷＷサーバ３０に保険加入勧誘機構９４が備えられるものとする。なお、以下説明する一連の処理により、配信ステップ，配信機能及び配信手段が実現される。
【００５２】
プロトコルモニタ５２から保険加入勧誘機構９４に対して、キーワード検出信号が入力されると、ＷＷＷサーバ３０に備えられた保険業者リスト８０が入力される（手順（１））。すると、図９に示す実施形態と同様に、各保険業者の保険サーバ４０に対して、取引当事者Ａ及びＢの保険加入状況が照会される（手順（２））。そして、取引当事者Ａの保険加入状況は、取引当事者Ｂのクライアント２０に表示される一方、取引当事者Ｂの保険加入状況は、取引当事者Ａのクライアント２０に表示される（手順（３））。また、取引当事者Ａ又は／及びＢが保険未加入であると、サービス業者が推薦する保険業者の保険サーバ４０に対して、保険未加入である取引当事者に保険勧誘情報を送信するよう依頼がなされる（手順（４））。保険勧誘情報の送信依頼を受信した保険サーバ４０では、保険未加入である取引当事者のクライアント２０に対して、保険勧誘情報が送信される（手順（５））。
【００５３】
従って、取引当事者は、取引相手たる他方の取引当事者の保険加入状況を確認することができ、取引相手の信頼度を推し量ることができる。また、取引交渉中に、保険加入の必要性を再確認でき、相互に保険加入を行うことで、取引当事者の保護を図ることができる。
図１５は、取引画面６０に保険勧誘情報を表示する際に、取引当事者の双方に対して、取引金額に応じた保険料を併せて表示する原理を示す。ここでは、サービス業者によりＷＷＷサーバ３０が運用され、ＷＷＷサーバ３０に保険料表示機構９６が備えられるものとする。
【００５４】
プロトコルモニタ５２から保険料表示機構９６に対してキーワード検出信号が入力されると、プロトコルモニタ５２により随時更新されるモニタリング表８２が入力される（手順（１））。保険料表示機構９６では、前述した処理により取引内容に応じた保険業者が選択され、その保険業者の保険サーバ４０に対して、保険料計算依頼を送信する（手順（２））。保険料計算依頼を受信した保険サーバ４０では、通常の保険料率（０．１５）から割引された割引保険料率（０．１３）を用いて、取引金額に応じた保険料が計算され、これが保険料表示機構９６に送信される（手順（３））。計算された保険料を受信した保険料表示機構９６では、取引金額に保険料を加算した合計金額が計算され、保険料及び合計金額が取引画面６０に表示される（手順（４））。また、保険料表示機構９６では、保険業者の保険勧誘情報を取引画面６０に表示させるべく、保険サーバ４０に登録されている保険勧誘情報（html-1）１０２を、取引画面６０を定義するＨＴＭＬデータ（html-0）の所定箇所に挿入させる（手順（５））。
【００５５】
なお、手順（４）における処理により、保険料受信ステップ，合計演算ステップ及び提示ステップが実現される。
従って、双方の取引当事者が保険に加入する場合には、通常の保険料率より割り引かれた割引保険料率により保険料が決定されるため、取引当事者の一方のみが保険に加入する場合と比べて、取引当事者の保険加入に係る金銭的負担が軽減される。このため、取引当事者は、取引交渉中に保険に気楽に加入することが可能となり、保険加入による取引当事者の保護を図ることができる。また、取引当事者の双方が保険に加入するため、当事者間で金銭的負担が平等となり、一方が保険料を負担することによる不平・不満が緩和される。
【００５６】
次に、電子商取引において発生した事故を客観的に立証するための構成について説明する。
図１６は、クライアント２０に証拠データを保存する構成を示す。なお、本実施形態では、プロトコルモニタ５２は、取引当事者間で授受される取引情報の中に取引交渉完了を示す完了キーワードが見出されたときに、キーワード検出信号を出力するものとする。
【００５７】
クライアント２０から保険業者の保険サーバ４０に対して、証拠データを記録する証拠収集プログラム１１０の送信要求がなされると（手順（１））、保険サーバ４０のデータベース４２に登録されている証拠収集プログラム１１０がクライアント２０に送信される（手順（２））。証拠収集プログラム１１０を受信したクライアント２０では、証拠収集プログラム１１０が実行可能状態で組み込まれる。ここで、証拠収集プログラム１１０は、圧縮された状態で送信されることが望ましい。
【００５８】
証拠収集プログラム１１０に対して、プロトコルモニタ５２からキーワード検出信号が入力されると（手順（３））、その時点における取引情報が一時的に保管され、保険サーバ４０に対して秘密鍵生成要求が送信される（手順（４））。秘密鍵生成要求を受信した保険サーバ４０では、そのときの日付及び時刻が読み込まれ（手順（５））、これに基づいて秘密鍵が生成される（手順（６））。秘密鍵の生成に関しては、例えば、ＲＳＡ（Rivest Shamir Adleman）アルゴリズムなどの公知技術が利用される。生成された秘密鍵は、取引当事者における日付及び時刻に対応したものとして、データベース４６に保存される（手順（７））。また、生成された秘密鍵は、保険業者特有の暗号化技術によりさらに暗号化される（手順（８））。暗号化された秘密鍵は、取引当事者のクライアント２０に送信される（手順（９））。
【００５９】
暗号化された秘密鍵を受信したクライアント２０では、秘密鍵が保険業者特有の復号化技術により復号化される（手順（10））。そして、秘密鍵により一時的に保管された取引情報が暗号化される（手順（11））。暗号化された取引情報は、その日付及び時刻と関連付けられた状態でファイル２６に保存される（手順（12））。
【００６０】
なお、ステップ（３）における処理により、完了判定ステップ，完了判定機能及び完了判定手段が実現される。また、手順（11）における処理により、暗号化ステップ，暗号化機能及び暗号化手段が実現される。さらに、手順（12）における処理により、保存ステップ，保存機能及び保存手段が実現される。
このように、取引当事者間で授受される取引情報の中に、取引交渉完了を示す完了キーワードが見出されると、そのときの日付及び時刻に基づいて生成された秘密鍵により取引情報が暗号化される。そして、暗号化された取引情報は、そのときの日付及び時刻と関連付けられた状態で、クライアント２０のファイル２６に保存される。この一連の処理は、保険サーバ４０から配信された証拠収集プログラム１１０により自動的に実行されるため、取引当事者は、事故立証のための証拠が収集には一切関与していない。
【００６１】
電子商取引において事故が発生した場合には、取引当事者は、保険金支払申請を行うに際し、事故発生の日付及び時刻を指定すると、ファイル２６から暗号化された取引情報が検索され、これが保険金支払申請書と共に保険サーバ４０に送信される（手順（13））。暗号化された取引情報を受信した保険サーバ４０では、保険金支払申請書で指定された日付及び時刻に基づいて、データベース４６から対応する秘密鍵が取り出され（手順（14））、取り出された秘密鍵により取引情報が復号化される（手順（15））。そして、復号化された取引情報が、保険金支払申請における証拠データとして活用される。
【００６２】
従って、事故立証に必要な証拠は、取引当事者の意識外で収集されるため、事故発生の客観的な証拠を提示する労力が低減される。そして、収集された証拠としての取引情報は、事故が発生したときのみ保険業者に対して開示されるため、個人情報の流出を最小限に抑えることができる。このとき、証拠としての取引情報は、保険サーバ４０において生成された秘密鍵により暗号化されているため、取引当事者が取引情報を故意に改竄することが困難であり、証拠としての価値を高めることができる。このため、事故発生は客観的に立証され、取引当事者の保護を図ることができる。
【００６３】
なお、証拠収集プログラム１１０は、電子商取引を仲介するサービス業者のＷＷＷサーバ３０から、取引当事者のクライアント２０に配信される構成であってもよい。この場合、ＷＷＷサーバ３０には、保険業者から配信委託された証拠収集プログラム１１０が前もって登録されることが条件となる。また、証拠収集プログラム１１０は、取引当事者のクライアント２０から、取引相手たる取引当事者のクライアント２０に再配信される構成であってもよい。
【００６４】
ここで、電子商取引における事故を立証する証拠としての取引情報は、図１７に示すように、ＷＷＷサーバ３０で保存されるようにしてもよい。
クライアント２０から保険業者の保険サーバ４０に対して、証拠データを記録する証拠収集プログラム１１０の配信要求がなされると（手順（１））、保険サーバ４０のデータベース４２に登録されている証拠収集プログラム１１０がＷＷＷサーバ３０に送信される（手順（２））。証拠収集プログラム１１０を受信したＷＷＷサーバ３０では、証拠収集プログラム１１０が実行可能状態で組み込まれる。
【００６５】
証拠収集プログラム１１０に対して、プロトコルモニタ５２からキーワード検出信号が入力されると（手順（３））、その時点における取引情報が一時的に保管され、保険サーバ４０に対して秘密鍵生成要求が送信される（手順（４））。秘密鍵生成要求を受信した保険サーバ４０では、前述した秘密鍵生成方法により秘密鍵が生成される（手順（５））。生成された秘密鍵は、取引当事者における日付及び時刻に対応したものとして、データベース４６に保存される（手順（６））。また、生成された秘密鍵は、暗号化された後、ＷＷＷサーバ３０に送信される（手順（７））。
【００６６】
暗号化された秘密鍵を受信したＷＷＷサーバ３０では、秘密鍵が保険業者特有の復号化技術により復号化される（手順（８））。そして、秘密鍵により一時的に保管された取引情報が暗号化される（手順（９））。暗号化された取引情報は、その日付及び時刻と関連付けられた状態でファイル３８に保存される（手順（10））。
【００６７】
なお、手順（３）における処理により、完了判定ステップ，完了判定機能及び完了判定手段が実現される。また、手順（９）における処理により、暗号化ステップ，暗号化機能及び暗号化手段が実現される。さらに、手順（10）における処理により、保存ステップ，保存機能及び保存手段が実現される。
このように、取引当事者間で授受される取引情報の中に、取引交渉完了を示す完了キーワードが見出されると、そのときの日付及び時刻に基づいて生成された秘密鍵により取引情報が暗号化される。そして、暗号化された取引情報は、そのときの日付及び時刻と関連付けられた状態で、ＷＷＷサーバ３０のファイル３８に保存される。この一連の処理は、保険サーバ４０から配信された証拠収集プログラム１１０により自動的に実行されるため、取引当事者は、事故立証のための証拠が収集には一切関与していない。
【００６８】
電子商取引において事故が発生した場合には、取引当事者は、氏名及び事故発生の日付を指定して、ＷＷＷサーバ３０に対して証拠送信要求を送信する（手順（11））。証拠送信要求を受信したＷＷＷサーバ３０では、指定された氏名及び事故発生の日付に基づいて暗号化された取引情報が保存されたファイル３８が検索され、該当する取引情報のリストがクライアント２０に送信される（手順（12））。取引情報のリストを受信したクライアント２０では、必要に応じて、証拠として必要な取引情報が選択され、選択結果がＷＷＷサーバ３０に送信される（手順（13））。選択結果を受信したＷＷＷサーバ３０では、選択された取引情報がファイル３８から取り出され、保険サーバ４０に送信される（手順（14））。
【００６９】
暗号化された取引情報を受信した保険サーバ４０では、事故発生の日付及び時刻に基づいて、データベース４６から対応する秘密鍵が取り出され（手順（15））、取り出された秘密鍵により取引情報が復号化される（手順（16））。そして、復号化された取引情報が、保険金支払申請における証拠データとして活用される。
【００７０】
このため、図１６に示す実施形態と同様に、事故発生が客観的に立証されることで、電子商取引において発生した損害が保険により填補され、取引当事者の保護を図ることができる。
このような機能を実現するプログラムを、例えば、磁気テープ，磁気ディスク，磁気ドラム，ＩＣカード，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭ等のコンピュータ読取可能な記録媒体に記録しておけば、本発明に係る保険業務処理プログラムを市場に流通させることができる。そして、かかる記録媒体を取得した者は、一般的なコンピュータシステムを利用して、本発明に係る保険業務処理システムを容易に構築することができる。
【００７１】
また、インターネットに接続されたサーバ上に、本発明に係る保険業務処理プログラムを登録させておけば、電気通信回線を介して、かかるプログラムをダウンロードすることで、本発明に係る保険業務処理システムを容易に構築することができる。
【００７２】
（付記１）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に保険勧誘の契機となる勧誘キーワードが含まれているか否かを判定する勧誘判定ステップと、該勧誘キーワードが含まれていると判定されたときに、前記電子情報を交換していた当事者の少なくとも一方に保険勧誘情報を配信する配信ステップと、を備えたことを特徴とする保険業務処理方法。
【００７３】
（付記２）前記配信ステップは、前記当事者が保険未加入であるときに、該当事者に保険勧誘情報を配信することを特徴とする付記１記載の保険業務処理方法。
【００７４】
（付記３）前記配信ステップは、前記当事者が保険加入済みであっても、該保険が無効であるとき、又は、過去に電子商取引に係る事故の遭遇経験があるときに、前記当事者に保険勧誘情報を配信することを特徴とする付記２記載の保険業務処理方法。
【００７５】
（付記４）前記配信ステップは、前記電子情報の内容に応じて選択した保険業者からの保険勧誘情報を配信することを特徴とする付記１〜付記３のいずれか１つに記載の保険業務処理方法。
【００７６】
（付記５）通常の保険料率より割り引かれた割引保険料率を用い、前記電子情報に含まれる取引価格に応じて演算された保険料を受信する保険料受信ステップと、該受信された保険料と前記取引価格との合計を演算する合計演算ステップと、該演算された保険料及び合計を前記当事者の双方に提示する提示ステップと、を備えたことを特徴とする付記１〜付記４のいずれか１つに記載の保険業務処理方法。
【００７７】
（付記６）電子商取引に係る取引情報を入力する入力ステップと、該入力した取引情報を送信する送信ステップと、該送信した取引情報の中に保険勧誘の契機となる勧誘キーワードが含まれていたときに、保険業者のサーバから送信されてきた保険勧誘情報を受信する受信ステップと、を備えたことを特徴とする保険業務処理方法。
【００７８】
（付記７）前記入力した取引情報の中に取引キーワードが含まれているか否かを判定する取引判定ステップと、該取引キーワードが含まれていると判定されたときに、電子商取引に係る危険性を報知する危険性報知ステップと、を備えたことを特徴とする付記６記載の保険業務処理方法。
【００７９】
（付記８）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に保険勧誘の契機となる勧誘キーワードが含まれているか否かを判定する勧誘判定機能と、該勧誘キーワードが含まれていると判定されたときに、前記電子情報を交換していた当事者の少なくとも一方に保険勧誘情報を配信する配信機能と、をコンピュータに実現させるための保険業務処理プログラム。
【００８０】
（付記９）電子商取引に係る取引情報を入力する入力機能と、該入力した取引情報を送信する送信機能と、該送信した取引情報の中に保険勧誘の契機となる勧誘キーワードが含まれていたときに、保険業者のサーバから送信されてきた保険勧誘情報を受信する受信機能と、をコンピュータに実現させるための保険業務処理プログラム。
【００８１】
（付記１０）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に保険勧誘の契機となる勧誘キーワードが含まれているか否かを判定する勧誘判定機能と、該勧誘キーワードが含まれていると判定されたときに、前記電子情報を交換していた当事者の少なくとも一方に保険勧誘情報を配信する配信機能と、をコンピュータに実現させるための保険業務処理プログラムを記録したコンピュータ読取可能な記録媒体。
【００８２】
（付記１１）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に保険勧誘の契機となる勧誘キーワードが含まれているか否かを判定する勧誘判定手段と、該勧誘キーワードが含まれていると判定されたときに、前記電子情報を交換していた当事者の少なくとも一方に保険勧誘情報を配信する配信手段と、を含んで構成されたことを特徴とする保険業務処理システム。
【００８３】
（付記１２）電子商取引に係る取引情報を入力する入力手段と、該入力した取引情報を送信する送信手段と、該送信した取引情報の中に保険勧誘の契機となる勧誘キーワードが含まれていたときに、保険業者のサーバから送信されてきた保険勧誘情報を受信する受信手段と、を含んで構成されたことを特徴とする保険業務処理システム。
【００８４】
（付記１３）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に電子商取引交渉の完了を示す完了キーワードが含まれているか否かを判定する完了判定ステップと、該完了キーワードが含まれていると判定されたときに、秘密鍵を用いて電子商取引に係る取引情報を暗号化する暗号化ステップと、該暗号化された取引情報を保存する保存ステップと、を備えたことを特徴とする保険業務処理方法。
【００８５】
（付記１４）前記秘密鍵は、前記完了キーワードが含まれていると判定されたときの日付及び時刻に基づいて生成されることを特徴とする付記１３記載の保険業務処理方法。
【００８６】
（付記１５）前記秘密鍵は、前記電子情報を交換していた当事者が加入している保険業者により生成されることを特徴とする付記１３又は付記１４に記載の保険業務処理方法。
【００８７】
（付記１６）前記秘密鍵は、暗号化された状態で保険業者から配信されることを特徴とする付記１５記載の保険業務処理方法。
【００８８】
（付記１７）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に電子商取引交渉の完了を示す完了キーワードが含まれているか否かを判定する完了判定機能と、該完了キーワードが含まれていると判定されたときに、秘密鍵を用いて電子商取引に係る取引情報を暗号化する暗号化機能と、該暗号化された取引情報を保存する保存機能と、をコンピュータに実現させるための保険業務処理プログラム。
【００８９】
（付記１８）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に電子商取引交渉の完了を示す完了キーワードが含まれているか否かを判定する完了判定機能と、該完了キーワードが含まれていると判定されたときに、秘密鍵を用いて電子商取引に係る取引情報を暗号化する暗号化機能と、該暗号化された取引情報を保存する保存機能と、をコンピュータに実現させるための保険業務処理プログラムを記録したコンピュータ読取可能な記録媒体。
【００９０】
（付記１９）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に電子商取引交渉の完了を示す完了キーワードが含まれているか否かを判定する完了判定手段と、該完了キーワードが含まれていると判定されたときに、秘密鍵を用いて電子商取引に係る取引情報を暗号化する暗号化手段と、該暗号化された取引情報を保存する保存手段と、を含んで構成されたことを特徴とする保険業務処理システム。
【００９１】
【発明の効果】
以上説明したように、本発明に係る保険業務処理技術によれば、電子商取引中に保険勧誘情報が配信されるため、電子商取引に際しての危険性が再認識されることで、保険への加入が促され、当事者の保護を図ることができる。また、電子商取引交渉が完了すると、そのときの取引情報が秘密鍵により暗号化された後保存されるため、暗号化された取引情報は、事故立証のための証拠として利用されることとなり、当事者の保護を図ることができる。
【図面の簡単な説明】
【図１】保険業務処理システムの基本構成図である。
【図２】保険業務処理システムの運用形態を示し、（Ａ）はサービス業者によりＷＷＷサーバが運用されるときの構成図、（Ｂ）は売り手によりＷＷＷサーバが運用されるときの構成図である。
【図３】クライアント及びＷＷＷサーバにおける基本動作の説明図である。
【図４】ワード表の説明図である。
【図５】取引画面に保険勧誘情報を表示させる原理の説明図である。
【図６】保険業務処理システムの基本動作の説明図である。
【図７】取引情報に適合した保険業者を選択する原理の説明図である。
【図８】取引情報の送信前に警告メッセージを表示させる原理の説明図である。
【図９】保険未加入者に対して保険勧誘情報が添付された電子メールを送信する原理の説明図である。
【図１０】取引履歴データベースの説明図である。
【図１１】加入者データベースの説明図である。
【図１２】取引内容に応じた保険に未加入であるか否かを判定する処理内容を示すフローチャートである。
【図１３】取引当事者の依頼に応じて、保険未加入者に対して保険勧誘情報を提供する原理の説明図である。
【図１４】キーワード検出信号に応じて、保険未加入者に対して保険勧誘情報を提供する原理の説明図である。
【図１５】取引金額に応じた保険料を表示させる原理の説明図である。
【図１６】クライアントに事故立証のための証拠データを保存する原理の説明図である。
【図１７】ＷＷＷサーバに事故立証のための証拠データを保存する原理の説明図である。
【符号の説明】
１０ インターネット
２０ クライアント
２６ ファイル
３０ ＷＷＷサーバ
３８ ファイル
４０ 保険サーバ
４４ 加入者データベース
５２ プロトコルモニタ
５４ ワード表
５６ 警告機構
６０ 取引画面
８０ 保険業者リスト
８２ モニタリング表
８４ 答え表
８６ 定義表
８８ 当事者リスト
９０ 電子メール送付機構
９２ 取引履歴データベース
９４ 保険加入勧誘機構
９６ 保険料表示機構
１００ 売買情報
１０２ 保険勧誘情報
１０４ ＨＴＭＬデータ
１１０ 証拠収集プログラム
【発明の属する技術分野】
本発明は、インターネットなどのコンピュータネットワークを用いて電子商取引を行う際に、取引当事者の保護を図る技術に関する。
【０００２】
【従来の技術】
近年、インターネットなどのコンピュータネットワークを用いて、商品などを売買する電子商取引が盛んになってきた。電子商取引では、取引相手が不明である場合も多く、例えば、取引相手が悪意を持っていれば、詐欺などのトラブルが発生するおそれがあった。また、取引相手が悪意を持っていなくとも、商品の配送経路や代金の支払い経路において、商品の破損や依頼伝票の紛失などの事故が発生してしまうおそれもあった。このため、保険業者から、電子商取引において発生した損失を補填する保険制度が提供されている。この保険制度では、電子商取引を行う前に、予想され得る事故項目に対応した保険契約を締結する必要があった。
【０００３】
【発明が解決しようとする課題】
しかしながら、電子商取引では、取引頻度が多く、その取引額が小額であることが多いため、従来の保険制度に加入する者は少なかった。また、電子商取引では、取引ごとに取引相手や取引内容が異なることが多いため、従来の保険制度に加入するのは煩雑でもあった。
【０００４】
一方、電子商取引において発生した損失を補填するには、従来の自動車保険制度と同様に、事故が発生した事実を客観的に立証する必要がある。しかし、電子商取引では、取引相手の実態が不明である場合も多く、双方の陳述に基づいて事故を客観的に立証することが困難であった。また、現実の公証役場の機能をネットワーク上で実現する「電子公証システム」により、電子商取引における事故の発生を客観的に立証しようという構想もある。しかし、電子公証システムでは、高額かつ重要なものを公証対象とし、その手続も厳密であるため、取引頻度が多く、その取引額が小額である電子商取引には不向きなものであった。
【０００５】
従って、電子商取引における取引当事者は、保険制度に未加入であることが多く、また、保険制度に加入していても事故発生の立証が客観的に行えないため、発生した損失が補填されず、保護が不十分になるおそれがあった。
そこで、本発明は以上のような従来の問題点に鑑み、電子商取引中に保険加入を促す一方、事故発生を客観的に立証できるようにすることで、取引当事者の保護を図った保険業務処理技術を提供することを目的とする。
【０００６】
【課題を解決するための手段】
このため、電子商取引中に保険加入を促すために、本発明に係る保険業務処理技術では、コンピュータネットワークを流通する電子情報を監視し、その中に保険勧誘の契機となる勧誘キーワードが含まれていたときに、電子情報を交換していた当事者の少なくとも一方に保険勧誘情報を配信することを特徴とする。
【０００７】
かかる構成によれば、コンピュータネットワークを流通する電子情報の中に、保険勧誘の契機となる勧誘キーワードが含まれていると、電子情報を交換していた当事者の少なくとも一方に保険勧誘情報が配信される。このため、当事者は、電子商取引に際しての危険性を再認識することが可能となる。また、保険勧誘情報に、保険商品の加入申請画面へのリンク情報を埋め込んでおけば、簡単な操作により加入申請画面が表示される。このため、当事者は、電子商取引中に簡単な操作で保険に加入することができ、当事者の保護が図られる。
【０００８】
このとき、保険未加入である当事者に対して保険勧誘情報を配信するようにすれば、保険加入済みである当事者には保険勧誘情報が配信されず、その者が煩わしいと感じることが防止される。また、当事者が保険加入済みであっても、保険が無効であるとき、又は、過去に電子商取引に係る事故の遭遇経験があるときには、その者に保険勧誘情報を優先して配信するようにすれば、保険の必要性を感じている当事者に対して、電子商取引における危険性を再確認させる機会が与えられる。さらに、電子情報の内容に応じて選択した保険業者からの保険勧誘情報を配信するようにすれば、取引内容に適合しない保険に加入することが防止され、本発明の目的が効果的に奏されることとなる。
【０００９】
ここで、通常の保険料率より割り引かれた保険料率を用い、取引価格に応じて演算された保険料を受信すると共に、受信された保険料と取引価格との合計を演算し、演算された保険料及び合計を当事者の双方に提示することが望ましい。
かかる構成によれば、双方の当事者が保険に加入する場合には、通常の保険料率より割り引かれた割引保険料率に基づき保険料が決定される。このため、当事者の一方のみが保険に加入する場合と比べて、当事者の保険加入に係る金銭的負担が軽減され、取引交渉中に保険に気楽に加入することが可能となる。また、当事者の双方が保険に加入するため、当事者間で金銭的負担が平等となり、一方が保険料を負担することによる不平・不満が緩和される。
【００１０】
また、電子商取引中に保険加入を促すために、本発明に係る保険業務処理技術では、電子商取引に係る取引情報を送信する際に、その中に保険勧誘の契機となる勧誘キーワードが含まれていると、保険業者のサーバから送信されてきた保険勧誘情報を受信することを特徴とする。
かかる構成によれば、電子商取引に係る取引情報を送信する際に、その中に保険勧誘の契機となる勧誘キーワードが含まれていると、保険業者のサーバから送信されてきた保険勧誘情報を受信することとなる。このため、当事者は、電子商取引に際しての危険性を再認識することが可能となる。また、保険勧誘情報に、保険商品の加入申請画面へのリンク情報を埋め込んでおけば、簡単な操作により加入申請画面が表示される。このため、当事者は、電子商取引中に簡単な操作で保険に加入することができ、当事者の保護が図られる。
【００１１】
このとき、取引情報の中に取引キーワードが含まれているとき、取引情報を実際に送信する前に、電子商取引に係る危険性を報知するようにすれば、当事者は、電子商取引における危険性を前もって再確認することが可能となる。このため、当事者をより厚く保護することが可能となる。
一方、事故発生を客観的に立証できるようにするために、本発明に係る保険業務処理技術では、コンピュータネットワークを流通する電子情報を監視し、その中に電子商取引交渉の完了を示す完了キーワードが含まれていたときに、秘密鍵を用いて電子商取引に係る取引情報を暗号化して保存することを特徴とする。
【００１２】
かかる構成によれば、コンピュータネットワークを流通する電子情報の中に、電子商取引交渉の完了を示す完了キーワードが含まれていると、取引情報が秘密鍵により暗号化された後保存される。このため、暗号化された取引情報は、事故立証の証拠として利用されることとなり、当事者の保護が図られる。なお、暗号化された取引情報は、保険金を支払う保険業者により復号化される。
【００１３】
このとき、完了キーワードが含まれていると判定されたときの日付及び時刻に基づいて秘密鍵が生成されるようにすれば、短期間に多数の電子商取引が行われても、各取引内容は異なる秘密鍵により暗号化されることとなる。このため、証拠としての取引内容の改竄は、一層困難となる。また、当事者が加入していた保険業者により秘密鍵が生成されるようにすれば、他の保険業者は取引内容を容易に見ることができず、個人情報の流出が防止される。さらに、暗号化された状態で保険業者から秘密鍵が配信されるようにすれば、秘密鍵が悪意を持った第三者に渡ったとしても、当事者の保護が図られる。
【００１４】
【発明の実施の形態】
以下、添付された図面を参照して本発明を詳述する。
図１は、本発明に係る保険業務処理技術を具現化した、保険業務処理システムの基本構成を示す。
保険業務処理システムは、コンピュータネットワークを構築するインターネット１０を介して相互接続されるクライアント２０，ＷＷＷ（World Wide Web）サーバ３０及び保険業者により運営される保険サーバ４０を含んで構成される。そして、クライアント２０，ＷＷＷサーバ３０及び保険サーバ４０の間では、例えば、インターネットで普及しているＨＴＴＰ（HyperText Transfer Protocol）により相互通信が行われる。また、ＷＷＷサーバ３０のデータベース３２には、電子商取引対象たる商品等の売買情報１００、保険サーバ４０のデータベース４２には、取引当事者に提供される保険勧誘情報１０２が夫々登録される。
【００１５】
なお、クライアント２０，ＷＷＷサーバ３０及び保険サーバ４０は、少なくともメモリと中央処理装置（ＣＰＵ）とを備えたコンピュータにより構成される。そして、メモリにロードされたプログラムにより、保険業務処理システムにおける種々の業務が遂行される。
保険業務処理システムは、電子商取引を仲介するネットワークサービス業者（以下「サービス業者」という）の有無に応じて、次のような２つの形態により運用される。即ち、サービス業者が存在する場合には、図２（Ａ）に示すように、ＷＷＷサーバ３０は、サービス業者により運用される。この場合、クライアント２０は、取引当事者たる買い手Ａ及び売り手Ｂにより利用される。一方、サービス業者が存在しない場合には、図２（Ｂ）に示すように、ＷＷＷサーバ３０は、取引当事者たる売り手Ｂにより運用される。この場合、クライアント２０は、買い手Ａにより利用される。ＷＷＷサーバ３０を買い手Ａが、クライアント２０を売り手Ｂが運用してもよい。なお、図示の運用形態では、保険サーバ４０は、ＡＡ保険，ＢＢ保険及びＣＣ保険により運用される。
【００１６】
クライアント２０及びＷＷＷサーバ３０には、図３に示すように、夫々、ＳＳＬ（Secure Socket Layer）コーダ５０とプロトコルモニタ５２とが備えられたクライアントプログラム２２及びサーバプログラム３４がインストールされる。ＳＳＬコーダ５０では、クライアント２０とＷＷＷサーバ３０との間で秘密通信を行うべく、取引情報の暗号化及び復号化が行われる。一方、プロトコルモニタ５２では、クライアント２０とＷＷＷサーバ３０との間で授受される取引情報の中に、ワード表５４に登録されている勧誘キーワードが含まれているか否かが監視される。そして、取引情報の中に勧誘キーワードが含まれていることが検出されたならば、その旨を示す信号（以下「キーワード検出信号」という）が出力される。なお、プロトコルモニタ５２は、クライアント２０及びＷＷＷサーバ３０の少なくとも一方に備えられていればよい。
【００１７】
ワード表５４は、図４に示すように、２次元の表形式をなしている。ワード表５４の各行（ｊ軸）には、保険勧誘の契機となるキーワードが列（ｉ軸）方向に登録されている。例えば、第１行（ｊ＝１）においては、保険勧誘の契機となる勧誘キーワードとして、「＜ＦＯＲＭ ＰＯＳＴ」が登録されている。
ここで、クライアント２０とＷＷＷサーバ３０との間で授受される取引情報の流れについて、図３を参照しつつ説明する。なお、以下の説明では、ＳＳＬコーダ５０による取引情報の暗号化及び復号化については省略する。
【００１８】
クライアント２０において、ＷＷＷサーバ３０上にある売買情報としてのＨＴＭＬ（HyperText Markup Language）データを参照する場合には、ＨＴＭＬデータ（html-0）１０４の所在を示すＵＲＬ（Uniform Resource Lacator）を含んだ“ＧＥＴ”リクエストがＷＷＷサーバ３０に送信される。“ＧＥＴ”リクエストを受信したＷＷＷサーバ３０では、データベース３２が検索され、ＵＲＬにより特定されるＨＴＭＬデータ１０４がクライアント２０に送信される。ＨＴＭＬデータ１０４を受信したクライアント２０では、これをディスプレイ装置２４に表示することで、売買情報を閲覧できるようになる。
【００１９】
そして、クライアント２０において、例えば、表示された売買情報に対して購入希望事項が入力された後、「送信」ボタンが押されると、購入希望事項を含んだ“ＰＯＳＴ”リクエストがＷＷＷサーバ３０に送信される。このとき、送信された購入希望事項が特定のプログラム（cgi-0）１０６で処理されるべく、ｃｇｉ（Common Gateway Interface）機能を介して指定することができる。
【００２０】
次に、保険業務処理システムにおいて、電子商取引の取引交渉中に、保険勧誘情報を提供する原理について説明する。ここでは、プロトコルモニタ５２はＷＷＷサーバ３０側にのみ備えられると共に、図２（Ａ）に示すように、サービス業者により電子商取引が仲介されるものとする。なお、図２（Ｂ）に示すように、売り手ＢによりＷＷＷサーバ３０が運営されている場合でも同様である。
【００２１】
売り手Ｂは、電子商取引において販売する商品等の売買情報として、例えば、図５に示すようなＨＴＭＬデータ（html-0）１０４を作成する。このＨＴＭＬデータ１０４は、図中左上のような取引画面６０を表示すべく記述されている。ＨＴＭＬデータ１０４では、送信データが特定のプログラム（cgi-0）で処理されること（１）、価格及び数量が入力可能であること（２，３）、送信は「送信」というボタン６２を押し下げることで行われること（４）、などが定義されている。
【００２２】
また、図示の例では、取引画面６０の領域（url-1）６４Ａ〜（url-3）６４Ｃに、３つの保険業者からの保険勧誘情報が表示され得ることが示されている。取引画面６０が表示された直後には、保険勧誘情報が表示されておらず、プロトコルモニタ５２からキーワード検出信号が出力されると、ＨＴＭＬデータ１０４の所定箇所に保険勧誘情報を表示する定義行が挿入される。例えば、ＡＡ保険の保険勧誘情報が表示されるのであれば、ＨＴＭＬデータ１０４の所定箇所に定義行<a href="url-1"><img src="url-1a"></a>が挿入され、領域（url-1）６４ＡにＡＡ保険の勧誘情報が表示される。
【００２３】
売り手Ｂは、ＨＴＭＬデータ１０４を作成した後、図６に示すように、商品情報ＢをＷＷＷサーバ３０のデータベース３２に登録する（手順（１））。商品情報Ｂは、名前（氏名，企業名など）、商品情報の概要（商品名，価格など）、ＨＴＭＬデータ１０４、連絡先（メールアドレスなど）を含んで構成される。なお、以下の説明では、データベース３２に、売り手Ｂの商品情報Ｂの他、売り手Ｃ及びＤの商品情報Ｃ及びＤも登録済みであるものとする。
【００２４】
ＷＷＷサーバ３０の取引仲介プログラム３６は、その一機能を奏するリスティングプログラム３６Ａを起動させる。すると、リスティングプログラム３６Ａは、データベース３２に登録された商品情報Ｂ〜Ｄから商品情報の概要のみを抽出し、これらを電子掲示板７０に掲示する形式に自動編集する（手順（２））。そして、自動編集された商品情報の概要は、電子掲示板７０に一覧表示される。
【００２５】
買い手Ａは、“ＧＥＴ”リクエストを用いて、ＷＷＷサーバ３０の電子掲示板７０にアクセスし（手順（３））、一覧表示の中から商品情報Ｂを指定する。すると、商品情報Ｂに係るＨＴＭＬデータ１０４を要求すべく、買い手Ａのクライアント２０からＷＷＷサーバ３０に対して“ＰＯＳＴ”リクエストが送信される（手順（４））。“ＰＯＳＴ”リクエストを受信したＷＷＷサーバ３０では、“ＰＯＳＴ”リクエストを処理すべく、指定されたプログラム（cgi-0）１０６を起動させる（手順（５））。プログラム１０６は、データベース３２に登録された商品情報ＢからＨＴＭＬデータ１０４を検索し（手順（６））、これを買い手Ａのクライアント２０に送信する（手順（７））。これにより、買い手Ａのクライアント２０には、図５に示す取引画面６０が表示される。その後、買い手Ａと売り手Ｂとの間の売買交渉は、例えば、電子メール，図５に示す取引画面６０を共有する、などの方法で行われる。なお、ここでは、取引画面６０を介して売買交渉が行われるものとする。
【００２６】
取引画面６０において、買い手Ａが価格や数量などの取引情報を入力した後、「送信」ボタン６２を押し下げると、ＷＷＷサーバ３０に取引情報が送信される（手順（８））。取引情報を受信したＷＷＷサーバ３０では、プロトコルモニタ５２を経由させて、取引情報が売り手Ｂのクライアント２０に送信される（手順（９））。
【００２７】
このとき、プロトコルモニタ５２では、ワード表５４が参照され、取引情報の中に保険勧誘の契機となる勧誘キーワードが含まれているか否かが監視される。そして、保険勧誘の契機となる勧誘キーワードが見出されたならば、後述する処理に従って保険勧誘情報を提供する保険業者が選択され、その保険業者の保険サーバ４０に対して、キーワード検出信号が送信される（手順（10））。キーワード検出信号を受信した保険サーバ４０では、ＷＷＷサーバ３０に対してデータベース４２に登録された保険勧誘情報が送信される（手順（11））。保険勧誘情報を受信したＷＷＷサーバ３０では、取引画面６０を構成するＨＴＭＬデータ１０４の所定箇所に、保険勧誘情報を表示する定義行が挿入される。これにより、取引画面６０に保険勧誘情報が表示されることとなる。
【００２８】
なお、手順（８）における処理により、入力ステップ，入力機能，入力手段，送信ステップ，送信機能及び送信手段が実現される。また、手順（10）における一連の処理により、勧誘判定ステップ，勧誘判定機能及び勧誘判定手段が実現される。さらに、手順（11）における処理及びＨＴＭＬデータ１０４に保険勧誘情報を表示する定義行を挿入する処理により、配信ステップ，配信機能及び配信手段が実現される。その他、取引画面６０に保険勧誘情報が表示される処理により、受信ステップ，受信機能及び受信手段が実現される。
【００２９】
図７は、プロトコルモニタ５２において、保険業者を選択する処理内容を示す。
ＷＷＷサーバ３０には、保険勧誘情報を提供する保険業者名が登録された保険業者リスト８０と、取引当事者間における最新取引情報が収集されたモニタリング表８２と、取引情報に応じて選択された保険業者名が登録される答え表８４と、が備えられる。ここで、モニタリング表８２は、クライアント２０とＷＷＷサーバ３０との間で授受される取引情報を監視しているプロトコルモニタ５２により随時更新される。
【００３０】
一方、保険業者の保険サーバ４０には、保険勧誘情報を提供する条件（以下「提供条件」という）を定義した定義表８６が備えられる。ＡＡ保険の定義表８６では、取引価格が５，０００より高く、かつ、オークションであることが提供条件として定義されている。また、ＢＢ保険の定義表８６では、取引価格が１，０００より高く、かつ、売買取引であることが提供条件として定義されている。
【００３１】
ここで、モニタリング表８２に登録されているように、取引価格１，５００、数量２の売買取引が行われようとしているものとする。プロトコルモニタ５２では、保険業者リスト８０とモニタリング表８２とが読み込まれ（手順（１））、保険業者リスト８０に登録された各保険業者の定義表８６が参照される（手順（２））。そして、どの保険業者が取引情報に適合した保険商品を提供しているかが判定される。図示の例では、取引価格が３，０００の売買取引であるので、ＢＢ保険が提供する保険商品が適合していると判定され、その判定結果たるＢＢ保険が答え表８４に登録される（手順（３））。次に、答え表８４が読み込まれ（手順（４））、ＢＢ保険の保険勧誘情報（html-2）１０２の所在を示すＵＲＬが、取引画面６０を定義したＨＴＭＬデータ（html-0）１０４の所定箇所に挿入される（手順（５））。この結果、取引当事者の取引画面６０には、図示するようなＢＢ保険の保険勧誘情報が表示される（手順（６））。
【００３２】
従って、取引画面６０に取引内容に応じた保険勧誘情報が表示されることで、取引当事者は、電子商取引に際しての危険性を再確認することができる。また、保険勧誘情報に、保険業者が提供する保険商品の加入申請画面へのリンク情報を埋め込んでおけば、例えば、これをクリックすることで、保険商品の加入申請画面を表示させることができる。このため、取引当事者は、電子商取引中に簡単な操作で保険に加入することができ、取引当事者の保護を図ることができる。
【００３３】
図８は、取引情報が実際に送信される前に、取引当事者に対して電子商取引における危険性を報知ならしめると共に、保険勧誘情報を提供する原理を示す。
取引当事者のクライアント２０には、前述したＳＳＬコーダ５０，プロトコルモニタ５２及びワード表５４の他に、警告機構５６が備えられる。警告機構５６では、プロトコルモニタ５２からのキーワード検出信号を契機として、主として、ディスプレイ装置２４に警告メッセージを表示する機能が奏される。
【００３４】
そして、取引画面６０において、価格及び数量が入力された後「送信」ボタン６２が押し下げられると、取引情報がプロトコルモニタ５２に伝達される（手順（１））。プロトコルモニタ５２では、伝達された取引情報が監視され、その中にワード表５４に登録された取引キーワードとしての重要単語（例えば、ＰＯＳＴ，ＰＲＩＣＥなど）があるか否かが判定される（手順（２））。取引情報の中に重要単語があることが見出されると、警告機構５６が起動され（手順（３））、ディスプレイ装置２４に警告メッセージが表示される（手順（４））。これと同時に、警告機構５６により、ＷＷＷサーバ３０に対して保険勧誘の契機が訪れたことが通知され（手順（５））、前述したような処理を経て、保険業者から提供された保険勧誘情報がディスプレイ装置２４に表示される（手順（６））。ここまでの処理では、取引画面６０上で「送信」ボタン６２が押し下げられたにもかかわらず、取引情報はＷＷＷサーバ３０に送信されない。そして、再度「送信」ボタン６２が押し下げられると、初めて取引情報がＷＷＷサーバ３０に送信される。
【００３５】
なお、手順（２）における一連の処理により、取引判定ステップが実現される。また、手順（３）における処理により、危険性報知ステップが実現される。
従って、最初の「送信」ボタン６２の押し下げは、警告メッセージ及び保険勧誘情報を表示させるトリガーとして利用されるだけであるので、取引情報が実際に送信される前に、電子商取引における危険性を再確認することができる。この場合、先の実施形態と異なり、取引情報の中に重要単語があっただけで、警告メッセージ及び保険勧誘情報が表示されるため、取引当事者をより厚く保護することができる。
【００３６】
図９は、保険未加入の取引当事者に対して、保険勧誘情報が添付された電子メールを送付するための原理を示す。なお、以下説明する一連の処理により、配信ステップ，配信機能及び配信手段が実現される。
ＷＷＷサーバ３０には、保険業者リスト８０と、取引当事者の名前が登録された当事者リスト８８と、保険勧誘情報の提供先である取引当事者名が登録される答え表８４と、電子メール送付機構９０と、が備えられる。ここで、当事者リスト８８は、取引当事者間の取引履歴、即ち、少なくとも、日付，開始時刻，終了時刻及び取引当事者が登録された取引履歴データベース９２（図１０参照）に基づいて作成される。なお、取引履歴データベース９２は、クライアント２０とＷＷＷサーバ３０との間で授受される取引情報を監視しているプロトコルモニタ５２により、随時更新される。
【００３７】
一方、保険業者の保険サーバ４０には、加入者データベース４４が備えられる。加入者データベース４４には、図１１に示すように、契約番号，保険契約状況，契約者名，契約者住所，保険品目名，保険契約期間，契約日，契約タイプ，取引タイプ，保険料率，保険料，保険金額，保険金の支払方法，取引口座，リンク（同一人の他の保険契約へのリンク）及び事故情報などが登録される。
【００３８】
電子メール送付機構９０では、保険業者リスト８０と当事者リスト８８とが読み込まれ（手順（１））、保険業者リスト８０に登録された各保険業者の加入者データベース４４に対して、当事者リスト８８に登録された各取引当事者の保険契約状況が検索される（手順（２））。そして、後述する処理に従って、取引当事者が取引内容に応じた保険に未加入であると判定されると、その取引当事者名が答え表８４に登録される（手順（３））。次に、答え表８４が読み込まれ（手順（４））、答え表８４に登録された各取引当事者に対して、前述した処理により決定された保険業者の保険勧誘情報が添付された電子メールが送信される（手順（５））。
【００３９】
図１２は、取引当事者が取引内容に応じた保険に未加入であるか否かを判定する処理内容を示す。
ステップ１（図では「Ｓ１」と略記する。以下同様）では、当事者リスト８８から取引当事者名が１つ取り出される。即ち、本ステップが最初に実行されるときには、当事者リスト８８の先頭に登録されている取引当事者名が取り出され、以後実行されるときには、２番目，３番目・・・に登録されている取引当事者名が逐次取り出される。
【００４０】
ステップ２では、保険業者リスト８０から保険業者名が１つ取り出される。即ち、ステップ２〜ステップ７のループ処理を行うに際し、最初に実行されるときには、保険業者リスト８０の先頭に登録されている保険業者名が取り出され、以後実行されるときには、２番目，３番目・・・に登録されている保険業者名が順次取り出される。
【００４１】
ステップ３では、取引当事者名をキーとして、保険業者名により特定される保険業者の加入者データベース４４が検索される。
ステップ４では、加入者データベース４４に取引当事者名が登録済みであるか否かが判定される。即ち、取引当事者は、保険業者から提供される保険に加入したことがあるか否かが判定される。そして、取引当事者名が加入者データベース４４に登録済みであればステップ５へと進み（Ｙｅｓ）、取引当事者名が加入者データベース４４に登録済みでなければステップ９へと進む（Ｎｏ）。
【００４２】
ステップ５では、加入者データベース４４の保険契約状況（図１１参照）に基づいて、取引当事者の保険契約は現在有効であるか否かが判定される。そして、保険契約が有効であればステップ６へと進み（Ｙｅｓ）、保険契約が有効でない、即ち、保険契約が中断又は終了していればステップ９へと進む（Ｎｏ）。
ステップ６では、加入者データベース４４の事故情報（図１１参照）に基づいて、事故情報が登録されているか否か、即ち、取引当事者が事故に遭遇したことがあるか否かが判定される。そして、事故情報が登録されていなければステップ７へと進み（Ｙｅｓ）、事故情報が登録されていればステップ９へと進む（Ｎｏ）。
【００４３】
ステップ７では、保険業者リスト８０に登録されているすべての保険業者名に対する処理が終了したか否かが判定される。そして、処理が終了していればステップ８へと進み（Ｙｅｓ）、処理が終了していなければステップ２へと戻る（Ｎｏ）。
ステップ８では、当事者リスト８８に登録されている全ての取引当事者名に対する処理が終了したか否かが判定される。そして、処理が終了していれば保険未加入判定処理を終了し（Ｙｅｓ）、処理が終了していなければステップ１へと戻る（Ｎｏ）。
【００４４】
ステップ９では、答え表８４に取引当事者名が登録され、ステップ９へと進む。このとき、答え表８４に取引当事者名が既に登録済みであるときには、重複した登録を排除するために、登録処理をスキップすることが望ましい。
以上説明したステップ１〜ステップ９の処理によれば、（１）取引当事者名がいずれかの加入者データベース４４に登録されていないとき、（２）取引当事者の保険契約が無効であるとき、（３）取引当事者が事故に遭遇したことがあるとき、その当事者名が答え表８４に登録される。即ち、取引当事者が、取引内容に応じた保険に未加入であるときに、取引当事者に対して保険勧誘情報を提供すべく、その取引当事者名が答え表８４に登録される。
【００４５】
従って、取引内容に応じた保険に加入済みである取引当事者には、保険勧誘情報は提供されず、不要な保険勧誘情報が提供されることで、取引当事者が煩わしいと感じることを防止することができる。一方、過去に事故に遭遇し、保険加入の必要性を感じている取引当事者には、優先的に保険勧誘情報が提供されるため、電子商取引における危険性を再認識することができる。
【００４６】
なお、本実施形態では、当事者リスト８８の代わりに、少なくとも、双方の取引当事者名が登録されたモニタリング表８２を用いてもよい。この場合、モニタリング表８２は、クライアント２０とＷＷＷサーバ３０との間で授受される取引情報を監視するプロトコルモニタ５２により、例えば、電子商取引の開始又は終了を契機として、逐次更新される。
【００４７】
また、本実施形態では、プロトコルモニタ５２からのキーワード検出信号に応じて保険勧誘情報が提供されたが、一方の取引当事者からの指示により、他方の取引当事者に対して保険勧誘情報が提供されるようにしてもよい。
さらに、電子商取引における取引交渉が完了した後、即ち、取引交渉は完了したが、取引自体は行われていないときに、保険未加入である取引当事者に対して保険勧誘情報が提供されるようにしてもよい。このようにすれば、取引当事者は、取引交渉の完了後であっても保険に加入することができ、取引当事者の保護を一層厚くすることができる。
【００４８】
その他、電子メール送付機構９０は、保険業者の保険サーバ４０に備えられる構成であってもよい。
図１３は、取引当事者の依頼に応じて、保険未加入の取引当事者に対して、保険勧誘情報を提供する原理を示す。ここでは、クライアント２０又はＷＷＷサーバ３０には、保険加入勧誘機構９４が備えられ、保険業者の保険サーバ４０には、加入者データベース４４が備えられるものとする。なお、以下説明する一連の処理により、配信ステップ，配信機能及び配信手段が実現される。
【００４９】
取引当事者Ａのクライアント２０から保険加入勧誘機構９４に対して、取引相手たる取引当事者Ｂの保険加入状況の照会指示があると、ＷＷＷサーバ３０に備えられた保険業者リスト８０が入力される（手順（１））。すると、図９に示す実施形態と同様に、各保険業者の保険サーバ４０に対して、取引当事者Ｂの保険加入状況が照会される（手順（２））。取引当事者Ｂの保険加入状況は、取引当事者Ａのクライアント２０に表示される（手順（３））。また、取引当事者Ｂが保険未加入であると、取引当事者Ａが加入している保険業者の保険サーバ４０に対して、取引当事者Ｂに保険勧誘情報を送信するよう依頼がなされる（手順（４））。保険勧誘情報の送信依頼を受信した保険サーバ４０では、取引当事者Ｂのクライアント２０に対して、保険勧誘情報が送信される（手順（５））。
【００５０】
従って、取引当事者Ａは、取引交渉中に、取引相手たる取引当事者Ｂの保険加入状況をいつでも確認することができ、取引相手の信頼度を推し量ることができる。また、取引当事者Ｂが保険未加入であるときには、取引当事者Ｂに対して保険勧誘情報が送信される。このため、取引当事者Ａは、保険勧誘情報が送信された取引当事者Ｂの対応によって、例えば、保険加入を拒むのならば、取引当事者Ｂとの取引交渉を中止するなどの対策をとることで、損害発生を未然に防止することができる。
【００５１】
図１４は、キーワード検出信号に応じて、保険未加入の取引当事者に対して、保険勧誘情報を提供する原理を示す。ここでは、サービス業者によりＷＷＷサーバ３０が運営され、ＷＷＷサーバ３０に保険加入勧誘機構９４が備えられるものとする。なお、以下説明する一連の処理により、配信ステップ，配信機能及び配信手段が実現される。
【００５２】
プロトコルモニタ５２から保険加入勧誘機構９４に対して、キーワード検出信号が入力されると、ＷＷＷサーバ３０に備えられた保険業者リスト８０が入力される（手順（１））。すると、図９に示す実施形態と同様に、各保険業者の保険サーバ４０に対して、取引当事者Ａ及びＢの保険加入状況が照会される（手順（２））。そして、取引当事者Ａの保険加入状況は、取引当事者Ｂのクライアント２０に表示される一方、取引当事者Ｂの保険加入状況は、取引当事者Ａのクライアント２０に表示される（手順（３））。また、取引当事者Ａ又は／及びＢが保険未加入であると、サービス業者が推薦する保険業者の保険サーバ４０に対して、保険未加入である取引当事者に保険勧誘情報を送信するよう依頼がなされる（手順（４））。保険勧誘情報の送信依頼を受信した保険サーバ４０では、保険未加入である取引当事者のクライアント２０に対して、保険勧誘情報が送信される（手順（５））。
【００５３】
従って、取引当事者は、取引相手たる他方の取引当事者の保険加入状況を確認することができ、取引相手の信頼度を推し量ることができる。また、取引交渉中に、保険加入の必要性を再確認でき、相互に保険加入を行うことで、取引当事者の保護を図ることができる。
図１５は、取引画面６０に保険勧誘情報を表示する際に、取引当事者の双方に対して、取引金額に応じた保険料を併せて表示する原理を示す。ここでは、サービス業者によりＷＷＷサーバ３０が運用され、ＷＷＷサーバ３０に保険料表示機構９６が備えられるものとする。
【００５４】
プロトコルモニタ５２から保険料表示機構９６に対してキーワード検出信号が入力されると、プロトコルモニタ５２により随時更新されるモニタリング表８２が入力される（手順（１））。保険料表示機構９６では、前述した処理により取引内容に応じた保険業者が選択され、その保険業者の保険サーバ４０に対して、保険料計算依頼を送信する（手順（２））。保険料計算依頼を受信した保険サーバ４０では、通常の保険料率（０．１５）から割引された割引保険料率（０．１３）を用いて、取引金額に応じた保険料が計算され、これが保険料表示機構９６に送信される（手順（３））。計算された保険料を受信した保険料表示機構９６では、取引金額に保険料を加算した合計金額が計算され、保険料及び合計金額が取引画面６０に表示される（手順（４））。また、保険料表示機構９６では、保険業者の保険勧誘情報を取引画面６０に表示させるべく、保険サーバ４０に登録されている保険勧誘情報（html-1）１０２を、取引画面６０を定義するＨＴＭＬデータ（html-0）の所定箇所に挿入させる（手順（５））。
【００５５】
なお、手順（４）における処理により、保険料受信ステップ，合計演算ステップ及び提示ステップが実現される。
従って、双方の取引当事者が保険に加入する場合には、通常の保険料率より割り引かれた割引保険料率により保険料が決定されるため、取引当事者の一方のみが保険に加入する場合と比べて、取引当事者の保険加入に係る金銭的負担が軽減される。このため、取引当事者は、取引交渉中に保険に気楽に加入することが可能となり、保険加入による取引当事者の保護を図ることができる。また、取引当事者の双方が保険に加入するため、当事者間で金銭的負担が平等となり、一方が保険料を負担することによる不平・不満が緩和される。
【００５６】
次に、電子商取引において発生した事故を客観的に立証するための構成について説明する。
図１６は、クライアント２０に証拠データを保存する構成を示す。なお、本実施形態では、プロトコルモニタ５２は、取引当事者間で授受される取引情報の中に取引交渉完了を示す完了キーワードが見出されたときに、キーワード検出信号を出力するものとする。
【００５７】
クライアント２０から保険業者の保険サーバ４０に対して、証拠データを記録する証拠収集プログラム１１０の送信要求がなされると（手順（１））、保険サーバ４０のデータベース４２に登録されている証拠収集プログラム１１０がクライアント２０に送信される（手順（２））。証拠収集プログラム１１０を受信したクライアント２０では、証拠収集プログラム１１０が実行可能状態で組み込まれる。ここで、証拠収集プログラム１１０は、圧縮された状態で送信されることが望ましい。
【００５８】
証拠収集プログラム１１０に対して、プロトコルモニタ５２からキーワード検出信号が入力されると（手順（３））、その時点における取引情報が一時的に保管され、保険サーバ４０に対して秘密鍵生成要求が送信される（手順（４））。秘密鍵生成要求を受信した保険サーバ４０では、そのときの日付及び時刻が読み込まれ（手順（５））、これに基づいて秘密鍵が生成される（手順（６））。秘密鍵の生成に関しては、例えば、ＲＳＡ（Rivest Shamir Adleman）アルゴリズムなどの公知技術が利用される。生成された秘密鍵は、取引当事者における日付及び時刻に対応したものとして、データベース４６に保存される（手順（７））。また、生成された秘密鍵は、保険業者特有の暗号化技術によりさらに暗号化される（手順（８））。暗号化された秘密鍵は、取引当事者のクライアント２０に送信される（手順（９））。
【００５９】
暗号化された秘密鍵を受信したクライアント２０では、秘密鍵が保険業者特有の復号化技術により復号化される（手順（10））。そして、秘密鍵により一時的に保管された取引情報が暗号化される（手順（11））。暗号化された取引情報は、その日付及び時刻と関連付けられた状態でファイル２６に保存される（手順（12））。
【００６０】
なお、ステップ（３）における処理により、完了判定ステップ，完了判定機能及び完了判定手段が実現される。また、手順（11）における処理により、暗号化ステップ，暗号化機能及び暗号化手段が実現される。さらに、手順（12）における処理により、保存ステップ，保存機能及び保存手段が実現される。
このように、取引当事者間で授受される取引情報の中に、取引交渉完了を示す完了キーワードが見出されると、そのときの日付及び時刻に基づいて生成された秘密鍵により取引情報が暗号化される。そして、暗号化された取引情報は、そのときの日付及び時刻と関連付けられた状態で、クライアント２０のファイル２６に保存される。この一連の処理は、保険サーバ４０から配信された証拠収集プログラム１１０により自動的に実行されるため、取引当事者は、事故立証のための証拠が収集には一切関与していない。
【００６１】
電子商取引において事故が発生した場合には、取引当事者は、保険金支払申請を行うに際し、事故発生の日付及び時刻を指定すると、ファイル２６から暗号化された取引情報が検索され、これが保険金支払申請書と共に保険サーバ４０に送信される（手順（13））。暗号化された取引情報を受信した保険サーバ４０では、保険金支払申請書で指定された日付及び時刻に基づいて、データベース４６から対応する秘密鍵が取り出され（手順（14））、取り出された秘密鍵により取引情報が復号化される（手順（15））。そして、復号化された取引情報が、保険金支払申請における証拠データとして活用される。
【００６２】
従って、事故立証に必要な証拠は、取引当事者の意識外で収集されるため、事故発生の客観的な証拠を提示する労力が低減される。そして、収集された証拠としての取引情報は、事故が発生したときのみ保険業者に対して開示されるため、個人情報の流出を最小限に抑えることができる。このとき、証拠としての取引情報は、保険サーバ４０において生成された秘密鍵により暗号化されているため、取引当事者が取引情報を故意に改竄することが困難であり、証拠としての価値を高めることができる。このため、事故発生は客観的に立証され、取引当事者の保護を図ることができる。
【００６３】
なお、証拠収集プログラム１１０は、電子商取引を仲介するサービス業者のＷＷＷサーバ３０から、取引当事者のクライアント２０に配信される構成であってもよい。この場合、ＷＷＷサーバ３０には、保険業者から配信委託された証拠収集プログラム１１０が前もって登録されることが条件となる。また、証拠収集プログラム１１０は、取引当事者のクライアント２０から、取引相手たる取引当事者のクライアント２０に再配信される構成であってもよい。
【００６４】
ここで、電子商取引における事故を立証する証拠としての取引情報は、図１７に示すように、ＷＷＷサーバ３０で保存されるようにしてもよい。
クライアント２０から保険業者の保険サーバ４０に対して、証拠データを記録する証拠収集プログラム１１０の配信要求がなされると（手順（１））、保険サーバ４０のデータベース４２に登録されている証拠収集プログラム１１０がＷＷＷサーバ３０に送信される（手順（２））。証拠収集プログラム１１０を受信したＷＷＷサーバ３０では、証拠収集プログラム１１０が実行可能状態で組み込まれる。
【００６５】
証拠収集プログラム１１０に対して、プロトコルモニタ５２からキーワード検出信号が入力されると（手順（３））、その時点における取引情報が一時的に保管され、保険サーバ４０に対して秘密鍵生成要求が送信される（手順（４））。秘密鍵生成要求を受信した保険サーバ４０では、前述した秘密鍵生成方法により秘密鍵が生成される（手順（５））。生成された秘密鍵は、取引当事者における日付及び時刻に対応したものとして、データベース４６に保存される（手順（６））。また、生成された秘密鍵は、暗号化された後、ＷＷＷサーバ３０に送信される（手順（７））。
【００６６】
暗号化された秘密鍵を受信したＷＷＷサーバ３０では、秘密鍵が保険業者特有の復号化技術により復号化される（手順（８））。そして、秘密鍵により一時的に保管された取引情報が暗号化される（手順（９））。暗号化された取引情報は、その日付及び時刻と関連付けられた状態でファイル３８に保存される（手順（10））。
【００６７】
なお、手順（３）における処理により、完了判定ステップ，完了判定機能及び完了判定手段が実現される。また、手順（９）における処理により、暗号化ステップ，暗号化機能及び暗号化手段が実現される。さらに、手順（10）における処理により、保存ステップ，保存機能及び保存手段が実現される。
このように、取引当事者間で授受される取引情報の中に、取引交渉完了を示す完了キーワードが見出されると、そのときの日付及び時刻に基づいて生成された秘密鍵により取引情報が暗号化される。そして、暗号化された取引情報は、そのときの日付及び時刻と関連付けられた状態で、ＷＷＷサーバ３０のファイル３８に保存される。この一連の処理は、保険サーバ４０から配信された証拠収集プログラム１１０により自動的に実行されるため、取引当事者は、事故立証のための証拠が収集には一切関与していない。
【００６８】
電子商取引において事故が発生した場合には、取引当事者は、氏名及び事故発生の日付を指定して、ＷＷＷサーバ３０に対して証拠送信要求を送信する（手順（11））。証拠送信要求を受信したＷＷＷサーバ３０では、指定された氏名及び事故発生の日付に基づいて暗号化された取引情報が保存されたファイル３８が検索され、該当する取引情報のリストがクライアント２０に送信される（手順（12））。取引情報のリストを受信したクライアント２０では、必要に応じて、証拠として必要な取引情報が選択され、選択結果がＷＷＷサーバ３０に送信される（手順（13））。選択結果を受信したＷＷＷサーバ３０では、選択された取引情報がファイル３８から取り出され、保険サーバ４０に送信される（手順（14））。
【００６９】
暗号化された取引情報を受信した保険サーバ４０では、事故発生の日付及び時刻に基づいて、データベース４６から対応する秘密鍵が取り出され（手順（15））、取り出された秘密鍵により取引情報が復号化される（手順（16））。そして、復号化された取引情報が、保険金支払申請における証拠データとして活用される。
【００７０】
このため、図１６に示す実施形態と同様に、事故発生が客観的に立証されることで、電子商取引において発生した損害が保険により填補され、取引当事者の保護を図ることができる。
このような機能を実現するプログラムを、例えば、磁気テープ，磁気ディスク，磁気ドラム，ＩＣカード，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭ等のコンピュータ読取可能な記録媒体に記録しておけば、本発明に係る保険業務処理プログラムを市場に流通させることができる。そして、かかる記録媒体を取得した者は、一般的なコンピュータシステムを利用して、本発明に係る保険業務処理システムを容易に構築することができる。
【００７１】
また、インターネットに接続されたサーバ上に、本発明に係る保険業務処理プログラムを登録させておけば、電気通信回線を介して、かかるプログラムをダウンロードすることで、本発明に係る保険業務処理システムを容易に構築することができる。
【００７２】
（付記１）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に保険勧誘の契機となる勧誘キーワードが含まれているか否かを判定する勧誘判定ステップと、該勧誘キーワードが含まれていると判定されたときに、前記電子情報を交換していた当事者の少なくとも一方に保険勧誘情報を配信する配信ステップと、を備えたことを特徴とする保険業務処理方法。
【００７３】
（付記２）前記配信ステップは、前記当事者が保険未加入であるときに、該当事者に保険勧誘情報を配信することを特徴とする付記１記載の保険業務処理方法。
【００７４】
（付記３）前記配信ステップは、前記当事者が保険加入済みであっても、該保険が無効であるとき、又は、過去に電子商取引に係る事故の遭遇経験があるときに、前記当事者に保険勧誘情報を配信することを特徴とする付記２記載の保険業務処理方法。
【００７５】
（付記４）前記配信ステップは、前記電子情報の内容に応じて選択した保険業者からの保険勧誘情報を配信することを特徴とする付記１〜付記３のいずれか１つに記載の保険業務処理方法。
【００７６】
（付記５）通常の保険料率より割り引かれた割引保険料率を用い、前記電子情報に含まれる取引価格に応じて演算された保険料を受信する保険料受信ステップと、該受信された保険料と前記取引価格との合計を演算する合計演算ステップと、該演算された保険料及び合計を前記当事者の双方に提示する提示ステップと、を備えたことを特徴とする付記１〜付記４のいずれか１つに記載の保険業務処理方法。
【００７７】
（付記６）電子商取引に係る取引情報を入力する入力ステップと、該入力した取引情報を送信する送信ステップと、該送信した取引情報の中に保険勧誘の契機となる勧誘キーワードが含まれていたときに、保険業者のサーバから送信されてきた保険勧誘情報を受信する受信ステップと、を備えたことを特徴とする保険業務処理方法。
【００７８】
（付記７）前記入力した取引情報の中に取引キーワードが含まれているか否かを判定する取引判定ステップと、該取引キーワードが含まれていると判定されたときに、電子商取引に係る危険性を報知する危険性報知ステップと、を備えたことを特徴とする付記６記載の保険業務処理方法。
【００７９】
（付記８）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に保険勧誘の契機となる勧誘キーワードが含まれているか否かを判定する勧誘判定機能と、該勧誘キーワードが含まれていると判定されたときに、前記電子情報を交換していた当事者の少なくとも一方に保険勧誘情報を配信する配信機能と、をコンピュータに実現させるための保険業務処理プログラム。
【００８０】
（付記９）電子商取引に係る取引情報を入力する入力機能と、該入力した取引情報を送信する送信機能と、該送信した取引情報の中に保険勧誘の契機となる勧誘キーワードが含まれていたときに、保険業者のサーバから送信されてきた保険勧誘情報を受信する受信機能と、をコンピュータに実現させるための保険業務処理プログラム。
【００８１】
（付記１０）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に保険勧誘の契機となる勧誘キーワードが含まれているか否かを判定する勧誘判定機能と、該勧誘キーワードが含まれていると判定されたときに、前記電子情報を交換していた当事者の少なくとも一方に保険勧誘情報を配信する配信機能と、をコンピュータに実現させるための保険業務処理プログラムを記録したコンピュータ読取可能な記録媒体。
【００８２】
（付記１１）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に保険勧誘の契機となる勧誘キーワードが含まれているか否かを判定する勧誘判定手段と、該勧誘キーワードが含まれていると判定されたときに、前記電子情報を交換していた当事者の少なくとも一方に保険勧誘情報を配信する配信手段と、を含んで構成されたことを特徴とする保険業務処理システム。
【００８３】
（付記１２）電子商取引に係る取引情報を入力する入力手段と、該入力した取引情報を送信する送信手段と、該送信した取引情報の中に保険勧誘の契機となる勧誘キーワードが含まれていたときに、保険業者のサーバから送信されてきた保険勧誘情報を受信する受信手段と、を含んで構成されたことを特徴とする保険業務処理システム。
【００８４】
（付記１３）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に電子商取引交渉の完了を示す完了キーワードが含まれているか否かを判定する完了判定ステップと、該完了キーワードが含まれていると判定されたときに、秘密鍵を用いて電子商取引に係る取引情報を暗号化する暗号化ステップと、該暗号化された取引情報を保存する保存ステップと、を備えたことを特徴とする保険業務処理方法。
【００８５】
（付記１４）前記秘密鍵は、前記完了キーワードが含まれていると判定されたときの日付及び時刻に基づいて生成されることを特徴とする付記１３記載の保険業務処理方法。
【００８６】
（付記１５）前記秘密鍵は、前記電子情報を交換していた当事者が加入している保険業者により生成されることを特徴とする付記１３又は付記１４に記載の保険業務処理方法。
【００８７】
（付記１６）前記秘密鍵は、暗号化された状態で保険業者から配信されることを特徴とする付記１５記載の保険業務処理方法。
【００８８】
（付記１７）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に電子商取引交渉の完了を示す完了キーワードが含まれているか否かを判定する完了判定機能と、該完了キーワードが含まれていると判定されたときに、秘密鍵を用いて電子商取引に係る取引情報を暗号化する暗号化機能と、該暗号化された取引情報を保存する保存機能と、をコンピュータに実現させるための保険業務処理プログラム。
【００８９】
（付記１８）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に電子商取引交渉の完了を示す完了キーワードが含まれているか否かを判定する完了判定機能と、該完了キーワードが含まれていると判定されたときに、秘密鍵を用いて電子商取引に係る取引情報を暗号化する暗号化機能と、該暗号化された取引情報を保存する保存機能と、をコンピュータに実現させるための保険業務処理プログラムを記録したコンピュータ読取可能な記録媒体。
【００９０】
（付記１９）コンピュータネットワークを流通する電子情報を監視し、該電子情報の中に電子商取引交渉の完了を示す完了キーワードが含まれているか否かを判定する完了判定手段と、該完了キーワードが含まれていると判定されたときに、秘密鍵を用いて電子商取引に係る取引情報を暗号化する暗号化手段と、該暗号化された取引情報を保存する保存手段と、を含んで構成されたことを特徴とする保険業務処理システム。
【００９１】
【発明の効果】
以上説明したように、本発明に係る保険業務処理技術によれば、電子商取引中に保険勧誘情報が配信されるため、電子商取引に際しての危険性が再認識されることで、保険への加入が促され、当事者の保護を図ることができる。また、電子商取引交渉が完了すると、そのときの取引情報が秘密鍵により暗号化された後保存されるため、暗号化された取引情報は、事故立証のための証拠として利用されることとなり、当事者の保護を図ることができる。
【図面の簡単な説明】
【図１】保険業務処理システムの基本構成図である。
【図２】保険業務処理システムの運用形態を示し、（Ａ）はサービス業者によりＷＷＷサーバが運用されるときの構成図、（Ｂ）は売り手によりＷＷＷサーバが運用されるときの構成図である。
【図３】クライアント及びＷＷＷサーバにおける基本動作の説明図である。
【図４】ワード表の説明図である。
【図５】取引画面に保険勧誘情報を表示させる原理の説明図である。
【図６】保険業務処理システムの基本動作の説明図である。
【図７】取引情報に適合した保険業者を選択する原理の説明図である。
【図８】取引情報の送信前に警告メッセージを表示させる原理の説明図である。
【図９】保険未加入者に対して保険勧誘情報が添付された電子メールを送信する原理の説明図である。
【図１０】取引履歴データベースの説明図である。
【図１１】加入者データベースの説明図である。
【図１２】取引内容に応じた保険に未加入であるか否かを判定する処理内容を示すフローチャートである。
【図１３】取引当事者の依頼に応じて、保険未加入者に対して保険勧誘情報を提供する原理の説明図である。
【図１４】キーワード検出信号に応じて、保険未加入者に対して保険勧誘情報を提供する原理の説明図である。
【図１５】取引金額に応じた保険料を表示させる原理の説明図である。
【図１６】クライアントに事故立証のための証拠データを保存する原理の説明図である。
【図１７】ＷＷＷサーバに事故立証のための証拠データを保存する原理の説明図である。
【符号の説明】
１０ インターネット
２０ クライアント
２６ ファイル
３０ ＷＷＷサーバ
３８ ファイル
４０ 保険サーバ
４４ 加入者データベース
５２ プロトコルモニタ
５４ ワード表
５６ 警告機構
６０ 取引画面
８０ 保険業者リスト
８２ モニタリング表
８４ 答え表
８６ 定義表
８８ 当事者リスト
９０ 電子メール送付機構
９２ 取引履歴データベース
９４ 保険加入勧誘機構
９６ 保険料表示機構
１００ 売買情報
１０２ 保険勧誘情報
１０４ ＨＴＭＬデータ
１１０ 証拠収集プログラム
Claims (6)
- ネットワークに接続されたコンピュータが、電子商取引を行う端末装置に対し該電子商取引に係る保険を勧誘するための保険勧誘情報を提供する情報提供方法であって、
前記コンピュータは、
保険勧誘の契機となる勧誘キーワードを格納したキーワードテーブルと、
前記保険勧誘情報の所在を示す情報である保険勧誘情報所在情報を格納した保険勧誘情報テーブルと、
前記コンピュータが提供する提供情報を複数保存した記憶装置と、
少なくとも商品の識別子と、当該商品に対応する売り手の識別子及び連絡先情報と、を含む商品情報を格納した商品情報テーブルと、
を備え、
前記コンピュータが、特定の提供情報を要求するための要求情報を端末装置から受信し、該要求情報で要求された提供情報を前記記憶装置から特定し、該提供情報についてキーワードテーブルに格納されたいずれかの勧誘キーワードが含まれているか否かを判定する判定ステップと、
前記コンピュータが、前記提供情報に含まれる商品の識別子及び買い手の識別子を抽出する抽出ステップと、
前記コンピュータが、前記抽出した商品の識別子に基づき前記商品情報テーブルを参照して売り手の識別子及び連絡先情報を取得する商品情報テーブル参照ステップと、
前記コンピュータが、保険加入者の識別子、該加入者の契約状況、及び、該加入者の事故情報を含む加入者情報を格納した加入者テーブルを備えつつ前記ネットワークに接続された保険提供装置にアクセスして、前記加入者テーブルに前記抽出した買い手の識別子を含む加入者情報と前記取得した売り手の識別子を含む加入者情報を夫々照会する照会ステップと、
前記提供情報にいずれかの勧誘キーワードが含まれていると判定され、かつ、前記加入者テーブルに前記抽出した買い手の識別子を含む加入者情報が登録されていなかったとき、または、該買い手の加入者情報の契約状況が有効でない若しくは事故情報が登録されているときに、前記コンピュータが、該提供情報及び前記保険勧誘情報所在情報を前記端末装置に配信する配信ステップと、
前記コンピュータが、前記端末装置が送信した電子商取引の申し込み情報を受信する受信ステップと、
前記加入者テーブルに前記取得した売り手の識別子を含む加入者情報が登録されていなかったとき、または、該売り手の加入者情報の契約状況が有効でない若しくは事故情報が登録されているときに、前記コンピュータが、前記受信した電子商取引の申し込み情報を前記売り手の連絡先情報に基づき送付する送付ステップと、
を備えたことを特徴とする情報提供方法。 - 前記提供情報は、電子商取引を申し込むために端末装置から入力情報を受け付けるための申し込み画面情報であり、
前記勧誘キーワードは、前記申し込み画面情報であることを示す文字列である
ことを特徴とする請求項１記載の情報提供方法。 - 前記申し込み画面情報は、ＨＴＭＬデータであり、
前記勧誘キーワードは、ＨＴＭＬデータがＨＴＴＰのＰＯＳＴリクエストを送信することを示す文字列である
ことを特徴とする請求項２記載の情報提供方法。 - 前記配信ステップは、前記加入者テーブルを照会した内容に基づき、前記買い手が加入している保険の内容と、前記売り手が加入している保険の内容と、の配信を行い、
前記送付ステップは、前記加入者テーブルを照会した内容に基づき、前記買い手が加入している保険の内容と、前記売り手が加入している保険の内容と、の送付を行う
ことを特徴とする請求項１〜請求項３のいずれか１つに記載の情報提供方法。 - 前記保険提供装置は、取引内容に対する保険勧誘の条件である保険勧誘条件を格納した保険勧誘条件テーブルを備え、
前記抽出ステップは、前記提供情報に含まれる取引内容をさらに抽出し、
前記コンピュータが、前記保険提供装置夫々にアクセスして前記保険勧誘条件テーブルに格納された保険勧誘条件を受信し、前記抽出した取引内容が前記受信したいずれかの保険勧誘条件を満たすか否かを判定する条件判定ステップを備え、
前記配信ステップは、前記保険勧誘条件が満たされた保険提供装置に係る保険勧誘情報所在情報の配信を行い、
前記送付ステップは、前記保険勧誘条件が満たされた保険提供装置に係る保険勧誘情報所在情報の送付を行う
ことを特徴とする請求項１〜請求項４のいずれか１つに記載の情報提供方法。 - 前記コンピュータが、前記保険提供装置に対し、前記提供情報に含まれる取引内容に基づき保険料計算依頼を作成して送信する保険料依頼ステップと、
前記保険提供装置が、前記送信された保険料計算依頼を受信し、該保険料計算依頼から取引内容を抽出し、該取引内容に基づいて保険料を計算し、該計算した保険料を前記コンピュータに送信する保険料計算ステップと、
前記コンピュータが、前記送信された保険料を受信し、該保険料と取引価格とを加算した合計金額を計算する合計金額計算ステップと、
を備え、
前記配信ステップは、前記合計金額の配信を行い、
前記送付ステップは、前記合計金額の送付を行う
ことを特徴とする請求項１〜請求項５のいずれか１つに記載の情報提供方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001083594A JP4383685B2 (ja) | 2001-03-22 | 2001-03-22 | 情報提供方法 |
| US09/910,716 US20020138308A1 (en) | 2001-03-22 | 2001-07-24 | Insurance task processing method, insurance task processing program, computer-readable storage medium recorded with insurance task processing program, and insurance task processing system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001083594A JP4383685B2 (ja) | 2001-03-22 | 2001-03-22 | 情報提供方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002279185A JP2002279185A (ja) | 2002-09-27 |
| JP4383685B2 true JP4383685B2 (ja) | 2009-12-16 |
Family
ID=18939388
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001083594A Expired - Lifetime JP4383685B2 (ja) | 2001-03-22 | 2001-03-22 | 情報提供方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20020138308A1 (ja) |
| JP (1) | JP4383685B2 (ja) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020082871A1 (en) * | 2000-10-30 | 2002-06-27 | Ted Younger | System and method for providing online insurance information |
| US8121871B2 (en) | 2001-01-26 | 2012-02-21 | Genworth Financial, Inc. | System, method and software application for accessing and processing information |
| US7953636B2 (en) | 2001-02-21 | 2011-05-31 | Genworth Financial, Inc. | System and method for providing customized sales-related data over a network |
| JP4378064B2 (ja) | 2001-08-29 | 2009-12-02 | インターナショナル・ビジネス・マシーンズ・コーポレーション | トランザクションの監視方法、トランザクションの監視システムおよび記録媒体 |
| US20040122764A1 (en) * | 2002-03-27 | 2004-06-24 | Bernie Bilski | Capped bill systems, methods and products |
| US20040128171A1 (en) * | 2002-12-31 | 2004-07-01 | Rees Timothy E. | Systems and methods for processing insurance information |
| US7617128B2 (en) * | 2004-06-15 | 2009-11-10 | Revolutionary E-Commerce Systems, Inc. | Online transaction hosting apparatus and system |
| JP4963886B2 (ja) * | 2006-07-18 | 2012-06-27 | 楽天株式会社 | 取引システム、情報提供装置、情報提供方法及び情報提供処理プログラム |
| US20080120143A1 (en) * | 2006-11-17 | 2008-05-22 | Uniprise, Inc. | Method for Providing Discounted Insurance |
| US8688482B1 (en) * | 2011-10-07 | 2014-04-01 | Allstate Insurance Company | Claim satisfaction guarantee |
| CN103473354A (zh) * | 2013-09-25 | 2013-12-25 | 焦点科技股份有限公司 | 基于电子商务平台的保险推荐系统框架及保险推荐方法 |
| EP3790301B1 (en) * | 2014-03-19 | 2022-04-06 | Bluefin Payment Systems, LLC | Systems and methods for creating fingerprints of encryption devices |
| JP6473297B2 (ja) * | 2014-05-07 | 2019-02-20 | 株式会社日本総合研究所 | 保険受付装置、保険受付方法、およびプログラム |
| JP6293245B1 (ja) * | 2016-11-25 | 2018-03-14 | 株式会社三井住友銀行 | 強化されたセキュリティを有する取引相互監視システム |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4179655B2 (ja) * | 1998-01-29 | 2008-11-12 | ソニー株式会社 | 情報提供装置および方法、情報送信装置、ならびに、情報提供システム |
| US7089194B1 (en) * | 1999-06-17 | 2006-08-08 | International Business Machines Corporation | Method and apparatus for providing reduced cost online service and adaptive targeting of advertisements |
| JP2001034546A (ja) * | 1999-07-22 | 2001-02-09 | Fujitsu Ltd | メッセージ装置 |
| US6853988B1 (en) * | 1999-09-20 | 2005-02-08 | Security First Corporation | Cryptographic server with provisions for interoperability between cryptographic systems |
| US7260724B1 (en) * | 1999-09-20 | 2007-08-21 | Security First Corporation | Context sensitive dynamic authentication in a cryptographic system |
| US7003482B1 (en) * | 1999-12-10 | 2006-02-21 | Computer Sciences Corporation | Middleware for business transactions |
| US6405177B1 (en) * | 2000-04-28 | 2002-06-11 | Dimattina Joseph | System for securing commercial transactions conducted on-line |
| US7778912B2 (en) * | 2001-01-10 | 2010-08-17 | Efficient Markets Corporation | System for appraising a financial product |
-
2001
- 2001-03-22 JP JP2001083594A patent/JP4383685B2/ja not_active Expired - Lifetime
- 2001-07-24 US US09/910,716 patent/US20020138308A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20020138308A1 (en) | 2002-09-26 |
| JP2002279185A (ja) | 2002-09-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3133243B2 (ja) | オンラインショッピングシステム | |
| JP5011027B2 (ja) | 顧客情報取引システム、顧客情報取引方法、サーバ及びプログラム | |
| US20140114859A1 (en) | Encrypted e-commerce product | |
| JP4383685B2 (ja) | 情報提供方法 | |
| US20070299732A1 (en) | Electronic commerce system utilizing custom merchant calculations | |
| US20160005043A1 (en) | Apparatus and method for purchasing a product using an electronic device | |
| JP6347471B1 (ja) | クレジットカード利用額管理システム | |
| US20010037319A1 (en) | Public submission content library | |
| KR100952335B1 (ko) | 범용 ｉｄ 기반 전자상거래 서비스 제공 방법, 선물추천서비스 제공 방법, 그를 위한 전자상거래 서비스 시스템 및통합 서버 시스템 | |
| KR100391710B1 (ko) | 디지털카탈로그에 의한 분산 전자상거래 시스템 및 방법 | |
| JP2004126976A (ja) | 電子商取引与信処理方法及び電子商取引システム | |
| JP2002342688A (ja) | 電子商取引方法、決済代行方法、使い捨て後払い方式情報発行方法、および決済依頼方法 | |
| US20020038424A1 (en) | Apparatus and method for providing security for electronic signatures | |
| US20020087474A1 (en) | Electronic commerce system, electronic commerce method and storage medium | |
| JP3632051B2 (ja) | ネットワーク決済処理システム、ネットワーク決済処理装置、ネットワーク決済処理方法、および、ネットワーク決済処理プログラム | |
| US20040167826A1 (en) | Anonymous electronic funds transfer system and method, and anonymous shipping system and method | |
| JP2002140590A (ja) | 電子商取引システム | |
| KR20010100701A (ko) | 인터넷상에서의 대금결제에 대한 클리어링 하우징 시스템및 방법 | |
| JP2002063444A (ja) | 匿名による個人間取引方法及びシステム | |
| KR101681889B1 (ko) | 기업 간 거래 정보 공유 및 중개 시스템 운용 방법 | |
| JP2002207928A (ja) | 電子商取引サーバ装置及び方法 | |
| JP2002117264A (ja) | 電子商取引の仲介サーバーおよび仲介方法 | |
| JP2005149036A (ja) | 電子商取引方法 | |
| US20110184852A1 (en) | Secured acquisition process via credit card terminal | |
| KR102618456B1 (ko) | 메타버스 서비스에 적용가능한 블록체인 기반의 상품 관람 시스템 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060612 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090317 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090514 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090616 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090807 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090915 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090924 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121002 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |