(57)【特許請求の範囲】
【請求項１】
複数のクライアント端末とネットワークを介して接続可能に構成され、各クライアント端末から仮想コミュニティへ投稿されたメッセージを分類、蓄積することによって知識の蓄積を支援する知識蓄積支援システムであって、
前記クライアント端末からのメッセージ投稿を許可するために、アクセス要求元のクライアント端末に対してユーザ認証を行うアクセス制御手段と、
複数のクライアント端末が参加可能な仮想コミュニティを管理し、前記アクセス制御手段によってアクセス許可された各クライアント端末から仮想コミュニティに投稿されるメッセージを話題毎に分類、蓄積するコミュニティ処理手段とを具備し、
前記コミュニティ処理手段は、
前記分類、蓄積したメッセージを購読ユーザに配信するための、第１の制御情報をメッセージヘッダ、第２の制御情報をサブジェクトにそれぞれ埋め込んだメールに応答して、返信メッセージを投稿するための返信メールが前記クライアント端末から返送されたときに、その返信メールのメッセージヘッダを解析して、前記第１の制御情報が当該メッセージヘッダに埋め込まれているか否かを判定し、第１の制御情報が埋め込まれていた場合、このメッセージヘッダに埋め込まれていた第１の制御情報に基づき、その返信メッセージを分類、蓄積し、第１の制御情報が埋め込まれていなかった場合、その返信メールのサブジェクトを解析して、前記第２の制御情報を検出し、このサブジェクトから検出した第２の制御情報に基づき、その返信メッセージを分類、蓄積する返信メッセージ処理手段を具備することを特徴とする知識蓄積支援システム。
【請求項２】
複数のクライアント端末とネットワークを介して接続可能に構成され、各クライアント端末から仮想コミュニティへ投稿されたメッセージを分類、蓄積することによって知識の蓄積を支援する知識蓄積支援システムにおける返信メッセージ処理方法であって、
前記知識蓄積支援システムは、
前記クライアント端末からのメッセージ投稿を許可するために、アクセス要求元のクライアント端末に対してユーザ認証を行うアクセス制御ステップと、
複数のクライアント端末が参加可能な仮想コミュニティを管理し、前記アクセス制御手段によってアクセス許可された各クライアント端末から仮想コミュニティに投稿されるメッセージを話題毎に分類、蓄積するコミュニティ処理ステップとを具備し、
前記コミュニティ処理ステップは、
前記分類、蓄積したメッセージを購読ユーザに配信するための、第１の制御情報をメッセージヘッダ、第２の制御情報をサブジェクトにそれぞれ埋め込んだメールに応答して、返信メッセージを投稿するための返信メールが前記クライアント端末から返送されたときに、その返信メールのメッセージヘッダを解析して、前記第１の制御情報が当該メッセージヘッダに埋め込まれているか否かを判定し、第１の制御情報が埋め込まれていた場合、このメッセージヘッダに埋め込まれていた第１の制御情報に基づき、その返信メッセージを分類、蓄積し、第１の制御情報が埋め込まれていなかった場合、その返信メールのサブジェクトを解析して、前記第２の制御情報を検出し、このサブジェクトから検出した第２の制御情報に基づき、その返信メッセージを分類、蓄積する返信メッセージ処理ステップを具備することを特徴とする知識蓄積支援システムにおける返信メッセージ処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、ナレッジマネジメントシステムで用いられる知識蓄積支援システムおよび同システムにおける返信メッセージ処理方法に係り、特に、不特定多数のユーザが参加する仮想コミュニティを用いて知識の蓄積を支援する知識蓄積支援システムおよび同システムにおける返信メッセージ処理方法に関する。
【０００２】
【従来の技術】
近年、企業を中心に複数のユーザ間で情報共有を行うためのグループウェアの導入が進められている。代表的なグループウェアとしては、電子メールシステムやワークフローシステムなどが知られているが、最近では、知識や情報の共有支援を図るためのナレッジマネジメントシステムも開発され始めている。
【０００３】
このナレッジマネジメントシステムは、Ｗｅｂ情報や電子ファイル情報などに加え、個人のノウハウなどを知識データベースとして蓄積・管理するためのものであり、自然言語検索などの検索機能と組み合わせることにより、知識、情報の効率的な活用が可能となる。
【０００４】
ところで、このようなナレッジマネジメントシステムにおいては、個人のノウハウなどの知識をどのように収集・蓄積するかが重要となる。個人のノウハウなどの知識はいわゆる暗黙知であって、Ｗｅｂ情報や電子ファイル情報などのように形式化されたものではないため、それを自動的に収集、蓄積することは困難であるからである。
【０００５】
そこで、最近では、知識蓄積支援機能を持つナレッジマネジメントシステムの開発が要求されている。個人のノウハウなどの知識を自動的に収集・蓄積する仕組みを実現することにより、暗黙知としての知識をもＷｅｂ情報や電子ファイル情報などのような形式化された形式知と同様に活用することが可能となる。
【０００６】
【発明が解決しようとする課題】
しかしながら、従来のナレッジマネジメントシステムでは、収集・蓄積した知識を活用するためのユーザインタフェースが画一的であるため、一部のユーザについては、好みのインタフェースがあるにも関わらず、それ以外のインタフェースで収集・蓄積した知識を活用することを強制してしまっていた。
【０００７】
また、電子メールシステムにより送受信される情報を知識として収集・蓄積する場合を考えると、この収集した知識を効率的に分類・蓄積するために、メッセージヘッダ内に制御情報を埋め込むことが有効であるが、ユーザが利用するメーラーによっては、この意図的に埋め込んだ制御情報が認識されずに欠落されてしまうといった問題があった。
【０００８】
この発明は、このような事情を考慮してなされたものであり、個人のノウハウなどの知識を自動的に効率よく収集・蓄積する仕組みを実現できるようにし、様々な知識の共有を図ることを可能とする知識蓄積支援システムおよび同システムにおける返信メッセージ処理方法を提供することを目的とする。
【００１２】
前述した目的を達成するために、この発明の知識蓄積支援システムは、複数のクライアント端末とネットワークを介して接続可能に構成され、各クライアント端末から仮想コミュニティへ投稿されたメッセージを分類、蓄積することによって知識の蓄積を支援する知識蓄積支援システムであって、前記クライアント端末からのメッセージ投稿を許可するために、アクセス要求元のクライアント端末に対してユーザ認証を行うアクセス制御手段と、複数のクライアント端末が参加可能な仮想コミュニティを管理し、前記アクセス制御手段によってアクセス許可された各クライアント端末から仮想コミュニティに投稿されるメッセージを話題毎に分類、蓄積するコミュニティ処理手段とを具備し、前記コミュニティ処理手段は、前記分類、蓄積したメッセージを購読ユーザに配信するための、第１の制御情報をメッセージヘッダ、第２の制御情報をサブジェクトにそれぞれ埋め込んだメールに応答して、返信メッセージを投稿するための返信メールが前記クライアント端末から返送されたときに、その返信メールのメッセージヘッダを解析して、前記第１の制御情報が当該メッセージヘッダに埋め込まれているか否かを判定し、第１の制御情報が埋め込まれていた場合、このメッセージヘッダに埋め込まれていた第１の制御情報に基づき、その返信メッセージを分類、蓄積し、第１の制御情報が埋め込まれていなかった場合、その返信メールのサブジェクトを解析して、前記第２の制御情報を検出し、このサブジェクトから検出した第２の制御情報に基づき、その返信メッセージを分類、蓄積する返信メッセージ処理手段を具備することを特徴とする。
【００１３】
また、この発明の返信メッセージ処理方法は、複数のクライアント端末とネットワークを介して接続可能に構成され、各クライアント端末から仮想コミュニティへ投稿されたメッセージを分類、蓄積することによって知識の蓄積を支援する知識蓄積支援システムにおける返信メッセージ処理方法であって、前記知識蓄積支援システムは、前記クライアント端末からのメッセージ投稿を許可するために、アクセス要求元のクライアント端末に対してユーザ認証を行うアクセス制御ステップと、複数のクライアント端末が参加可能な仮想コミュニティを管理し、前記アクセス制御手段によってアクセス許可された各クライアント端末から仮想コミュニティに投稿されるメッセージを話題毎に分類、蓄積するコミュニティ処理ステップとを具備し、前記コミュニティ処理ステップは、前記分類、蓄積したメッセージを購読ユーザに配信するための、第１の制御情報をメッセージヘッダ、第２の制御情報をサブジェクトにそれぞれ埋め込んだメールに応答して、返信メッセージを投稿するための返信メールが前記クライアント端末から返送されたときに、その返信メールのメッセージヘッダを解析して、前記第１の制御情報が当該メッセージヘッダに埋め込まれているか否かを判定し、第１の制御情報が埋め込まれていた場合、このメッセージヘッダに埋め込まれていた第１の制御情報に基づき、その返信メッセージを分類、蓄積し、第１の制御情報が埋め込まれていなかった場合、その返信メールのサブジェクトを解析して、前記第２の制御情報を検出し、このサブジェクトから検出した第２の制御情報に基づき、その返信メッセージを分類、蓄積する返信メッセージ処理ステップを具備することを特徴とする。
【００１４】
この発明においては、電子メールシステムにより送受信される情報を知識として収集・蓄積するにあたって、ユーザの目に触れることのない制御情報を用いて収集した知識を効率的に分類・蓄積することを可能とし、また、メッセージヘッダに加えて、メッセージのサブジェクトを解析する仕組みをもつことにより、この意図的に埋め込んだ制御情報を認識できずに欠落してしまうメーラーにも対応することができ、ユーザが利用するメーラーの差異を吸収することを可能とする。
【００１５】
【発明の実施の形態】
以下、図面を参照してこの発明の一実施形態を説明する。
【００１６】
図１には、この発明の実施形態に係る知識蓄積支援システムの構成が示されている。この知識蓄積支援システムは、知識蓄積支援機能を持つナレッジマネジメントシステムとして利用されるものであり、複数のクライアント端末１１が共通に利用可能な仮想コミュニティを用いて、知識の分類、蓄積を行う。具体的な構成の説明を行う前に、まず、図２乃至図５を用いて、この実施形態に係る知識蓄積支援システムの概要を説明することにする。
【００１７】
図２に示されているように、知識には「形式知」と「暗黙知」とが存在する。現在、文書管理システムやＷｅｂサーバなど、形式化された情報（形式知）に対する整理、管理の体系は完成されつつある。しかし、実際のところ、それらによって「知識の蓄積」という点の全てを賄えているわけではない。これは、単にメールによって交わされるだけの軽い会話や、各人の頭の中だけにある知識など、非常に不明確な情報が存在しているからである。これが「暗黙知」と呼ばれるものである。この暗黙知をいかにうまく取り扱い、それを共有していくかが重要である。従来のシステムでは、暗黙知の蓄積を支援することは困難であり、暗黙知を取り扱うためのシステムが必要である。
【００１８】
この実施形態の知識蓄積支援システムは、このような暗黙知と呼ばれる情報を形式知化し、知識の蓄積促進を目的としたツールであり、グループにおけるディスカッションを電子掲示板形式の仮想コミュニティで行い、メッセージ（投稿記事）をその話題毎に分類、蓄積する。１つの話題（以下、スレッドと称する）に対して、まとめを作成することも出来る。スレッドは仮想コミュニティ上における関連性のある知識の束を意味する。まとめは、グループにおけるディスカッションを総括する一種の議事録としての役割を持つメッセージであり、スレッド毎に作成することが出来る。
【００１９】
メッセージの投稿は、電子メールまたはＷｅｂブラウザからの入力によって行い、投稿されたメッセージは知識蓄積支援システムを構成するサーバ内に蓄積される。この知識蓄積支援システムにおいては、電子メールによるメッセージの投稿も可能であり、メーリングリストとしての側面も持つ。各ユーザがメールによって会話を行うだけで、知らず知らずのうちに暗黙知が蓄積されていく。この様子を図３に示す。
【００２０】
図３には、スポーツに関する仮想コミュニティである「スポーツコミュニティ」と、英語勉強会に関する仮想コミュニティである「英語勉強会コミュニティ」と、ある開発メンバ同士の仮想コミュニティである「○×開発メンバコミュニティ」とが示されている。各ユーザからの投稿メッセージはこれら各仮想コミュニティ毎に分類・蓄積され、また各仮想コミュニティ内ではスレッド毎に分類される。図３では、「スポーツコミュニティ」にはスレッド１，２，３の３種類の話題に関するメッセージが現在蓄積されており、また、「英語勉強会コミュニティ」にはスレッド１，２の２種類の話題に関するメッセージが蓄積され、「○×開発メンバコミュニティ」にはスレッド１の１つの話題に関するメッセージが蓄積されている場合が示されている。これら各仮想コミュニティに投稿されたメッセージは、他の知識（ｗｅｂ、ワークフロー、ファイリングシステムなどから収集された形式知）と同様にして、知識データベース（知識ＤＢ）に知識情報として蓄積される。特に、各スレッド毎に作成される「まとめ」を知識ＤＢに収集してそれを例えば全文検索や自然言語検索などの検索対象として他のメッセージに優先して適用することにより、いわゆるフロー情報としての「メッセージの流れ」を静的なストック情報として効率よく活用することが可能となる。
【００２１】
＜サイト＞
本明細書においては、この知識蓄積支援システムのサーバ機能を「サイト」と呼ぶ。サイトには管理者ユーザ（Ａｄｍｉｎｉｓｔｒａｔｏｒ）が存在し、サイト情報を管理する。サイト情報には、以下のようなものがある。
【００２２】
（１）ユーザ情報
サイトを利用可能なユーザに関する情報
サイト管理者によって、登録、削除、変更が可能である
（２）コミュニティ作成権限情報
仮想コミュニティを作成するための権限情報
仮想コミュニティ（以下、単にコミュニティと言う）は、メッセージの投稿、閲覧のために複数のユーザによって共通に利用可能な一種の電子掲示版であり、同じ目的を持って集まった人たちがコミュニケーションを行う「場」のことを示す。各ユーザは、目的に見合ったテーマのコミュニティに対してアクセスすることで、必要な知識を得たり、メッセージ（記事）を投稿したりする。各コミュニティには最低１名の管理者がいる（コミュニティ作成者がデフォルトで管理者となるが変更可能）。コミュニティ作成に関する権限は、以下の２つから選択することができる。
【００２３】
・登録されている全てのユーザが、コミュニティを作成できる。
【００２４】
・サイト管理者に承認されたユーザのみ、コミュニティを作成できる。
【００２５】
（３）コミュニティのカテゴリ情報
コミュニティを分類するためのカテゴリ情報
これは、サイト管理者によって登録、削除、変更が可能である。
【００２６】
＜コミュニティ＞
次に、コミュニティについて説明する。各コミュニティを管理するためのコミュニティ情報（コミュニティのプロパティ）には、以下のようなものがある。
【００２７】
（１）名前
コミュニティの名前。
【００２８】
（２）投稿用メールアドレス
コミュニティ毎にもつメールアドレス。ユーザがこのアドレスにメールを送ると、その内容が自動的に新規投稿メッセージとして該当するコミュニティに登録される。
【００２９】
（３）受信メールのSubject情報
コミュニティに対する参加形態には、ｗｅｂブラウザを通じてメッセージの閲覧、投稿を行う「ｗｅｂで購読」と、このｗｅｂブラウザを通じたメッセージの閲覧、投稿に加えて、新規投稿メッセージの自動メール配信サービスが受けられる「メールで購読」とがある。「メールで購読」を選択したユーザに対しては、そのコミュニティに新規メッセージが投稿されると、自動的にその新規投稿メッセージが電子メールにて配信される。その際、配信される電子メールのSubject情報には、上記「受信メールのSubject情報」（例えば，｛コミュニティ名，メッセージ番号｝等の情報）が付加される。
【００３０】
（４）作成者
コミュニティを作成したユーザ名。
【００３１】
（５）作成日
コミュニティが作成された日付。
【００３２】
（６）コミュニティの紹介
コミュニティの簡単な紹介文。
【００３３】
（７）コミュニティのカテゴリ
上述したように、コミュニティはその内容に応じてカテゴリ分けすることができ、分類先のカテゴリに関する情報がコミュニティ毎に保持される。また、カテゴリは、サイト管理者によって登録されたものを使用する。
【００３４】
（８）コミュニティタイプ
コミュニティの公開レベルを意味する。コミュニティの公開レベルには、自由参加の「公開制」、承認された参加者のグループからなる「メンバ制」、承認された参加者以外には公開しない「非公開制」の３つがある。
【００３５】
（９）統計情報
各コミュニティ毎にそれに属しているユーザの数や参加者別の発言数ランキングなどを含む。
【００３６】
（１０）管理者
このコミュニティを管理する管理者名。
【００３７】
（１１）メンバ
このコミュニティに属している（アクセス可能な）ユーザ。
【００３８】
（１２）メッセージ削除権限
投稿済みメッセージの削除を許されているユーザ。以下のいずれかを選択できる。
【００３９】
・コミュニティ管理者のみ
・コミュニティ管理者と投稿者
＜メッセージとスレッド＞
次に、メッセージとスレッドについて説明する。
【００４０】
メッセージとは、コミュニティ内の会話において、やりとりされる発言（記事の投稿）一つ一つのことである。メッセージには、複数のファイルを添付することも可能である。メッセージは、ｗｅｂブラウザからの入力またはコミュニティが持つメールアドレスへのメール送信によって投稿できる。
【００４１】
一方、スレッドとは、上述したようにある話題に関するメッセージの束のことである。１つの話題に対して、様々な意見（メッセージ）によって会話が進んでいき、結論を出す。この結論が「まとめ」である。この知識蓄積支援システムにおいては、「まとめ」に関する作成支援機能も有している。この作成支援機能を利用することにより、該当するスレッド内のメッセージや添付ファイルなどを援用しつつ、話題の結論としての「まとめ」を容易に作成することができる。
【００４２】
図４には、スレッドを構成するメッセージの階層構造の一例が示されている。図４において、スレッド１には５つのメッセージ１，２，３，４，５が含まれている。このスレッド１の構造は、まず、メッセージ１が投稿され、そのメッセージ１に対する返信（応答）メッセージとしてメッセージ２，３が投稿され、そして、メッセージ３に対する返信（応答）メッセージとしてメッセージ４が投稿され、さらにメッセージ１に対する返信（応答）メッセージとしてメッセージ５が投稿された場合に対応している。
【００４３】
また、スレッド２も５つのメッセージ１，２，３，４，５から構成されているが、これは、最初に投稿されたメッセージ１に対する返信（応答）メッセージとしてメッセージ２，３が投稿され、さらにメッセージ３に対する返信（応答）メッセージとしてメッセージ４，５が投稿された場合に対応している。
【００４４】
なお、スレッド１，２の各メッセージに対する返信とは異なるメッセージがスレッド１，２と同一のコミュニティに対して新たに投稿された場合には、その新規投稿メッセージにはスレッド３が割り当てられることになる。
【００４５】
＜まとめ＞
「まとめ」とは、上述したように会話（スレッド）に対する「結論」のことである。職場などの会議で言えば「議事録」に相当し、例えば開発ならばレビューに対する「仕様書」に相当する。図５に示すように、１つのスレッドに対して、１つの「まとめ」が対応する。つまり、ユーザまたは管理者によってスレッド毎に総括たる「まとめ」が作成され、該当するスレッドを構成するメッセージの特殊形態として管理される。「まとめ」にも他の通常のメッセージと同様に複数のファイルを添付することができる。
【００４６】
また、「まとめ」は改訂することができ、既に作成された「まとめ」を更新すること等によって新たな「まとめ」を作成し、それを最新の「まとめ」として登録することができる。
【００４７】
＜メールによるメッセージの投稿＞
メールによって、各コミュニティに投稿されたメッセージは、以下の手順で処理される。
【００４８】
（１）ユーザは、投稿先のコミュニティに割り当てられているメールアドレスに対してメッセージをメールにて投稿する。
【００４９】
（２）知識蓄積支援システムのサーバは、全てのコミュニティ宛に届いたメールをメールサーバから一括取得する。
【００５０】
（３）知識蓄積支援システムのサーバは、投稿先メールアドレスによってどのコミュニティ宛のメッセージなのかを判断し、振り分ける。
【００５１】
（４）知識蓄積支援システムのサーバは、取得したメールのヘッダ情報（またはタイトル）により、該当するコミュニティ内のどのスレッドのどの階層に登録するかを判別し、取得したメールの本文をそこにメッセージとして登録する。
【００５２】
メールによってコミュニティ宛に投稿されたメッセージは、上記の処理によって自動的に該当する場所に格納されていく。ユーザは、メーリングリストへの投稿と同じ感覚で、メッセージを投稿するだけでよい。
【００５３】
＜メッセージ購読タイプ＞
知識蓄積支援システムを利用するユーザは、上述したようにメッセージの購読タイプとして、以下の２種類を選択することができる。
【００５４】
・ｗｅｂブラウザによる購読（知識蓄積支援システムのＵＲＬ（Uniform Resource Locator）へアクセスする）
・メールによる購読
ユーザがどちらの購読タイプを選択してもｗｅｂブラウザからの購読（投稿も含む）が可能である。つまり、メッセージの新規投稿が行われた際に、自動的にそのメッセージをメール配信するかどうかの選択である。メッセージの新規投稿が行われると、メール購読を選択しているユーザにはメッセージのメール配信が行われる。また、ユーザは、この配信されたメールを返信するだけで、返信メッセージを投稿することができる。この購読タイプの選択は、ユーザが属しているコミュニティ毎に行うことが可能である。
【００５５】
＜システム構成＞
次に、図１を参照して、この実施形態に係る知識蓄積支援システムのシステム構成について説明する。
【００５６】
この実施形態の知識蓄積支援システムは、複数のクライアント端末１１とＬＡＮ等のコンピュータネットワーク１３を介して相互に接続可能なサーバコンピュータ１２にて実現されている。サーバコンピュータ１２とクライアント端末１１には、それぞれ、図示しないが、ＣＰＵ、メインメモリ、記憶装置としての磁気ディスク装置、及びキーボードやマウスなどの入力部とディスプレイなどの表示部とを持つ入出力装置が設けられている。
【００５７】
クライアント端末１１では、Ｗｅｂブラウザ１１１とメールクライアント１１２のいずれか一方又は両方が動作している。サーバコンピュータ１２上に構築された知識蓄積支援のためのリソースを示すＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）をＷｅｂブラウザ１１１から指定したり、あるいはコミュニティサーバ１２２にて管理される各コミュニティのメールアドレス宛にメールクライアント１２からメール送信を行うことにより、知識蓄積支援処理を各クライアント端末１１から利用することができる。
【００５８】
サーバコンピュータ１２の知識蓄積支援機能は、主に、制御部１２１、コミュニティサーバ１２２、Ｗｅｂサーバ１２７、およびメールサーバ１２８などのソフトウェアと、これらソフトフェアによってメッセージの投稿、閲覧のために利用される管理情報および実データとによって実現されている。管理情報には、各クライアント端末１１に対してユーザ認証を行うためのログイン管理情報１２３と、各コミュニティ毎にその管理を行うためのコミュニティ管理情報１２４とが存在し、また、実データとしては、メッセージデータ１２５と添付ファイル１２６とが存在する。
【００５９】
制御部１２１は、知識蓄積支援に関する全体の動作を制御するためのものであり、この知識蓄積支援システムの中核プログラムであるコミュニティサーバ１２３とＷｅｂサーバ１２７およびメールサーバ１２８それぞれとの間の仲介機能を初め、Ｗｅｂサーバ１２７およびメールサーバ１２８を通じて各クライアント端末１１がコミュニティサーバ１２２にログインする際のユーザ認証機能を持つ。このユーザ認証のために、制御部１２１は、ログイン管理情報１２３を管理している。このログイン管理情報１２３には、この知識蓄積支援システムに参加しているユーザそれぞれのユーザＩＤとパスワード等が格納されている。このユーザ認証により、各クライアント端末１１からのメッセージ投稿等の為になされるコミュニティサーバ１２２に対するアクセスの許可・禁止の制御が行われる。
【００６０】
コミュニティサーバ１２２は、複数のクライアント端末１１が参加可能なコミュニティの管理、運用を行うためのものであり、各クライアント端末１１から投稿されたメッセージをコミュニティ毎、且つ話題（スレッド）毎に分類、蓄積する。コミュニティサーバ１２２による各コミュニティの管理・運用は、コミュニティ管理情報１２４、メッセージデータ１２５、および添付ファイル１２６を用いて行われる。つまり、これらコミュニティ管理情報１２４、メッセージデータ１２５、および添付ファイル１２６は、コミュニティ毎にメッセージの蓄積・管理を行うためのデータベースとして利用される。
【００６１】
さらに、コミュニティサーバ１２２には、購読タイプ設定部１２９と返信メール処理部１３０とが設けられている。購読タイプ設定部１２９は、コミュニティ管理情報１２４を用いて、各クライアント端末１１のユーザの購読タイプをそのアクセス先となるコミュニティ毎に管理する。返信メール処理部１３０は、「メールで購読」を選択したユーザが配信されたメッセージを返信することにより投稿した返信メッセージを解析して自動的に該当する場所に格納する。
【００６２】
次に、コミュニティ管理情報１２４を構成する各テーブルについて説明する。
【００６３】
図１に示されているように、コミュニティ管理情報１２４は、ユーザテーブル２０１、コミュニティテーブル２０２、購読タイプテーブル２０３、メンバテーブル２０４、スレッドテーブル２０５、メッセージテーブル２０６およびまとめテーブル２０７などから構成されている。以下、これら各テーブルについて説明する。
【００６４】
＜ユーザテーブル＞
図６は、ユーザを管理するユーザテーブル２０１の構成例を示す図である。ユーザテーブル２０１には、本知識蓄積支援システムに参加しているユーザそれぞれについてユーザＩＤ、ユーザ名およびメールアドレスが格納されている。図６においては、ユーザＩＤ「Ｕ００００１」、ユーザ名「田中一郎」、メールアドレス「ichiro.tanaka@xxxx.co.jp」のユーザと、ユーザＩＤ「Ｕ００００２」、ユーザ名「山田太郎」、メールアドレス「taro.yamada@xxxx.co.jp」のユーザが登録されている例が示されている。
【００６５】
＜コミュニティテーブル＞
図７は、コミュニティを管理するコミュニティテーブル２０２の構成例を示す図である。コミュニティテーブル２０２は、本知識蓄積支援システム上に作成された各コミュニティと各コミュニティに参加しているユーザを管理するためのテーブルであり、ここには、本知識蓄積支援システム上に作成されたコミュニティそれぞれについてコミュニティＩＤ、コミュニティ名およびコミュニティタイプと、そのコミュニティに参加しているメンバそれぞれのメンバＩＤリストが格納されている。図７においては、コミュニティＩＤ「Ｃ００１」、コミュニティ名「コミュニティＡ」のコミュニティは、コミュニティタイプが「公開」であって、メンバＩＤ「Ｍ０００００１」、「Ｍ０００００４」、…が割り当てられたユーザが参加しており、また、コミュニティＩＤ「Ｃ００２」、コミュニティ名「コミュニティＢ」のコミュニティは、コミュニティタイプが「メンバ制」であって、メンバＩＤ「Ｍ０００００２」、「Ｍ０００００３」、…が割り当てられたユーザが参加している場合を示している。なお、メンバＩＤは全コミュニティにわたってユニーク（一意）であり、各ユーザには参加しているコミュニティの数と同数のメンバＩＤが割り当てられる。
【００６６】
＜購読タイプテーブル＞
図８は、購読タイプを管理する購読タイプテーブル２０３の構成例を示す図である。購読タイプテーブル２０３には、本知識蓄積支援システムに参加しているユーザそれぞれについてユーザＩＤ、ユーザ名、参加しているコミュニティのコミュニティＩＤ、そのコミュニティに対する購読タイプおよび購読タイプがメールの場合のユーザのメールアドレスが格納されている。なお、ユーザテーブル２０１でメールアドレスを管理する場合には、この購読タイプテーブル２０３には必ずしもメールアドレスを登録する必要はなく、また逆に、ユーザテーブル２０１ではメールアドレスを管理せず、購読タイプがメールの場合のユーザのメールアドレスのみを購読タイプテーブル２０３にて管理するようにしても良い。
【００６７】
図８においては、ユーザＩＤが「Ｕ００００１」で、ユーザ名が「田中一郎」のユーザが、コミュニティＩＤ「Ｃ００１」と「Ｃ００２」の２つのコミュニティに参加しており、コミュニティＩＤ「Ｃ００１」のコミュニティに関する購読タイプはｗｅｂで、コミュニティＩＤ「Ｃ００１」のコミュニティに関する購読タイプがメールであり、またユーザＩＤが「Ｕ００００２」で、ユーザ名が「山田太郎」のユーザが、コミュニティＩＤ「Ｃ００５」のコミュニティに参加しており、そのコミュニティに関する購読タイプがｗｅｂである場合を示している。
【００６８】
＜メンバテーブル＞
図９は、メンバを管理するメンバテーブル２０４の構成例を示す図である。メンバテーブル２０４には、メンバＩＤそれぞれについて、それが参加しているコミュニティに関する参加属性を示すメンバタイプと、メンバとして参加しているユーザのユーザ名とが格納されている。メンバタイプには、参加が承認されている「参加者」、参加者として仮登録されている「仮登録者」、参加を申し込んでいるが承認されていない「参加希望者」、参加に関する手続きを行っておらず一種のゲストとして参加する「匿名」とがある。
【００６９】
図９においては、ユーザ名「田中一郎」のユーザは、メンバＩＤ「Ｍ０００００１」として参加しているコミュニティに対してはそのメンバタイプが「参加者」で、またメンバＩＤ「Ｍ０００００３」として参加しているコミュニティに対してはそのメンバタイプが「参加希望者」であり、またユーザ名「山田太郎」のユーザは、メンバＩＤ「Ｍ０００００２」として参加しているコミュニティに対してはそのメンバタイプが「仮登録者」で、またメンバＩＤ「Ｍ０００００４」として参加しているコミュニティに対してはそのメンバタイプが「匿名」である場合を示している。
【００７０】
＜スレッドテーブル＞
図１０は、スレッドを管理するスレッドテーブル２０５の構成例を示す図である。スレッドテーブル２０５には、コミュニティそれぞれについてコミュニティＩＤと、そのコミュニティー内に生成されているスレッドそれぞれのスレッドＩＤを含むスレッドＩＤリストとが格納されている。スレッドＩＤも全コミュニティについてユニークな値が用いられる。
【００７１】
図１０においては、コミュニティＩＤ「Ｃ００１」のコミュニティにはスレッドＩＤ「Ｔ０１００１」、「Ｔ０１００２」、…のスレッドが含まれており、またコミュニティＩＤ「Ｃ００２」のコミュニティにはスレッドＩＤ「Ｔ０２００１」、…のスレッドが含まれている場合を示している。
【００７２】
＜メッセージテーブル＞
図１１は、メッセージを管理するメッセージテーブル２０６の構成例を示す図である。メッセージテーブル２０６には、スレッドＩＤ毎にそれを構成するメッセージそれぞれのメッセージＩＤと、メッセージデータ１２５として格納されている該当するメッセージの実データの所在を示すＵＲＬとが格納されている。なお、このＵＲＬは、該当するスレッドＩＤとメッセージＩＤとから一義に特定できるようにしてもよく、この場合には、ＵＲＬのフィールドは不要となる。
【００７３】
＜まとめテーブル＞
図１２は、スレッド毎に作成される「まとめ」を管理するまとめテーブル２０７の構成例を示す図である。まとめテーブル２０７には、スレッドＩＤ毎にそのスレッドの「まとめ」として作成・登録されたメッセージのメッセージＩＤと、複数の「まとめ」が作成・登録された場合における各メッセージの版番号と、メッセージデータ１２５として格納されている該当する「まとめ」に関するメッセージの実データの所在を示すＵＲＬとが格納されている。
【００７４】
また、メッセージテーブル２０６の場合と同様に、まとめテーブル２０７のＵＲＬは、該当するスレッドＩＤとメッセージＩＤとから一義に特定できるようにしてもよく、この場合にはＵＲＬのフィールドは不要となる。
【００７５】
ここで、コミュニティサーバ１２２の購読タイプ設定部１２９によって実行される、この知識蓄積支援システムにおけるメッセージ購読タイプの選択処理について説明する。
【００７６】
まず、図１３乃至図１５を参照して、この知識蓄積支援システムにおいてクライアント端末１１のＷｅｂブラウザ１１１により表示される画面の状態遷移の一例を説明する。
【００７７】
図１３は、個人用画面でのメッセージの購読タイプの変更を行う際のＷｅｂブラウザ画面の状態遷移を示す図であり、（Ａ）では、「田中一郎」というユーザが参加しているコミュニティの一覧と、それに対する購読タイプとが表示されている。ここで、「コミュニティＡ」のメッセージ購読を「Ｗｅｂ」から「メール」に変更するために、（Ｂ）のように該当するプルダウンメニューを表示させて「メール」を選択すると、（Ｃ）のように変更後の状態が表示される。この変更は、コミュニティサーバ１２２に送信され、購読タイプ設定部１２９によってコミュニティ管理情報１２４に反映されるので、次回からは「メール」が表示されることとなる。
【００７８】
一方、図１４及び図１５は、管理者用画面でのメッセージの購読タイプの変更を行う際のＷｅｂブラウザ画面の状態遷移を示す図であり、図１４（Ａ）では、「コミュニティＡ」、「コミュニティＢ」、…といったコミュニティの一覧が表示されている。ここで、「コミュニティＡ」を選択すると、図１４（Ｂ）のように「田中一郎」、「山田太郎」、…といったこのコミュニティの参加ユーザの購読タイプが表示される。ここで、「山田太郎」のメッセージ購読を「メール」から「脱退」に変更するために、図１５（Ａ）のように該当するプルダウンメニューを表示させて「脱退」を選択すると、図１５（Ｂ）のように変更後の状態が表示される。この変更は、コミュニティサーバ１２２に送信され、購読タイプ設定部１２９によってコミュニティ管理情報１２４に反映されるので、次回からは「脱退」が表示されることとなる。なお、この「脱退」は、以降コミュニティには参加できないことを示し、このため、このユーザからメッセージが届けられたとしても破棄されることとなる。
【００７９】
図１６は、購読タイプ変更処理の流れを示した図であり、この例では、「Ｗｅｂ」から「メール」に変更する例を示している。まず、Ｗｅｂブラウザ１１１がコミュニティのＵＲＬを指定し、表示された画面から購読タイプ変更要求を行うと（１）、コミュニティサーバ１２２の購読タイプ設定部１２９は、コミュニティ管理情報１２４の購読タイプテーブル２０３を検索し（２）、Ｗｅｂブラウザ１１１に返信する（３）。そして、ユーザは、この画面上で所望のコミュニティの購読タイプを「Ｗｅｂ」から「メール」に変更する。
【００８０】
その後、他のユーザからの新規メッセージ投稿が行われると、そのメッセージはメッセージデータ１２５に格納される（４）。そして、コミュニティサーバ１２２は、この新規メッセージを検索し（５）、購読タイプが“メール”となっているユーザのメールアドレスを購読タイプテーブルから取得し、そのメールクライアント１１２に対して自動送信する（６）。
【００８１】
図１７は、図１６で示した購読タイプ変更処理の手順を示すフローチャートである。
【００８２】
ユーザ「田中一郎」がＷｅｂブラウザ１１１によりサーバコンピュータ１２の制御部１２１へログイン要求すると（ステップＡ１）、制御部１２１は、ユーザから入力されたユーザＩＤおよびパスワードが登録されているか否かを調べるためにログイン管理情報１２３にアクセスし（ステップＡ２）、このログインを許可するかどうかを判定するためのユーザ認証を行う（ステップＡ３）。ユーザＩＤおよびパスワードがログイン管理情報１２３に登録されておらず、ログインが失敗した場合（ステップＡ３のＮＯ）、制御部１２１は、ログイン失敗をＷｅｂサーバ１２７を通じてＷｅｂブラウザ１１１に返してこの処理を終了する（ステップＡ４）。
【００８３】
一方、ユーザＩＤおよびパスワードがログイン管理情報１２３に登録されており、ログインが成功した場合には（ステップＡ３のＹＥＳ）、コミュニティサーバ１２２の購読タイプ設定部１２９が、指定されたユーザ名からコミュニティ管理情報１２４の購読タイプテーブル２０３に格納された当該ユーザの購読タイプを検索し、Ｗｅｂブラウザ１１１に返却する（ステップＡ５）。
【００８４】
このコミュニティサーバ１２２から返されたデータをもとにＷｅｂブラウザ１１１が図１３に示した個人用画面を表示すると（ステップＡ６）、ユーザは、表示された個人用画面の購読タイプを「Ｗｅｂ」から「メール」に変更する（ステップＡ７）。また、Ｗｅｂブラウザ１１１が変更された購読タイプをコミュニティサーバ１２２に送信すると（ステップＡ８）、コミュニティサーバ１２２の購読タイプ設定部１２９は、受信した購読タイプをもとに当該コミュニティの当該ユーザの購読タイプを変更して購読タイプテーブル２０３に反映する（ステップＡ９）。
【００８５】
その後、コミュニティサーバ１２２は、当該コミュニティに関するメッセージがくるたびに当該ユーザのメールアドレスに自動送信し（ステップＡ１０）、一方、当該ユーザは、メールクライアントによりこのメッセージを受信する（ステップＡ１１）。
【００８６】
また、図１８は、管理者があるユーザを購読から脱退させる処理の手順を示すフローチャートである。
【００８７】
管理者がＷｅｂブラウザ１１１によりサーバコンピュータ１２の制御部１２１へログイン要求すると（ステップＢ１）、制御部１２１は、ユーザから入力されたユーザＩＤおよびパスワードが登録されているか否かを調べるためにログイン管理情報１２３にアクセスし（ステップＢ２）、このログインを許可するかどうかを判定するためのユーザ認証を行う（ステップＢ３）。ユーザＩＤおよびパスワードがログイン管理情報１２３に登録されておらず、ログインが失敗した場合（ステップＢ３のＮＯ）、制御部１２１は、ログイン失敗をＷｅｂサーバ１２７を通じてＷｅｂブラウザ１１１に返してこの処理を終了する（ステップＢ４）。
【００８８】
一方、ユーザＩＤおよびパスワードがログイン管理情報１２３に登録されており、ログインが成功した場合には（ステップＢ３のＹＥＳ）、コミュニティサーバ１２２の購読タイプ設定部１２９が、コミュニティ管理情報１２４のコミュニティテーブル２０２に格納されたコミュニティを検索し、Ｗｅｂブラウザ１１１にコミュニティ一覧を返却する（ステップＢ５）。
【００８９】
このコミュニティサーバ１２２から返されたデータをもとにＷｅｂブラウザ１１１が図１４及び図１５に示した管理者用画面を表示すると（ステップＢ６）、管理者は、表示された管理者用画面の購読タイプを「Ｗｅｂ」から「脱退」に変更する（ステップＢ７）。また、Ｗｅｂブラウザ１１１が変更された購読タイプをコミュニティサーバ１２２に送信すると（ステップＢ８）、コミュニティサーバ１２２の購読タイプ設定部１２９は、受信した購読タイプをもとに当該コミュニティの当該ユーザの購読タイプを変更して購読タイプテーブル２０３に反映する（ステップＢ９）。
【００９０】
その後、コミュニティサーバ１２２は、当該コミュニティに対して当該ユーザからメッセージがきても廃棄する（ステップＢ１０）。
【００９１】
このように、この知識蓄積支援システムは、メッセージの購読タイプを各ユーザおよび管理者が選択する仕組みを備えるため、好みのインタフェースで知識を活用可能とするとともに、その購読管理を一元的に行うことを可能とする。
【００９２】
次に、コミュニティサーバ１２２の返信メール処理部１３０によって実行される、この知識蓄積支援システムにおける返信メールの処理について説明する。
【００９３】
図１９は、投稿メッセージに対するメール返信処理の流れを示したブロック図である。コミュニティサーバ１２２は、投稿メッセージ検索を行うと（１）、その投稿メッセージをメールクライアント１１２に送信する（２）。このとき、コミュニティサーバ１２２は、この投稿メッセージのメッセージヘッダおよびＳＵＢＪＥＣＴにコミュニティおよびスレッドを特定するための制御情報を埋め込んでおく。一方、この投稿メッセージを受信したメールクライアント１１２で、この投稿メッセージに対する返信を行うと（３）、コミュニティサーバ１２２の返信メール処理部１３０は、この返信メッセージをコミュニティ管理情報１２４のメッセージテーブル２０６で同一スレッドとして管理し（４）、かつ、メッセージデータ１２５に格納する（５）。
【００９４】
図２０は、この投稿メッセージの構造を示す図であり、図２０に示されるように、投稿メッセージａは、メッセージヘッダａ１、ＳＵＢＪＥＣＴａ２、メッセージ本体ａ３から構成される。メッセージヘッダａ１には、画面には表示されないメッセージＩＤおよびスレッドＩＤａ１１が含まれている。また、ＳＵＢＪＥＣＴａ２には、画面に表示されるコミュニティ名および当該メッセージに対して発番された番号ａ２１が含まれている。
【００９５】
図２１は、返信メールの第１の処理方法を示した図であり、メールクライアント１１２がヘッダ情報を落とさない（削除しない）機能を有している場合の説明図である。
【００９６】
投稿メッセージがメールクライアント１１２により受信され、ユーザが当該メッセージに対して返信メールを送信すると、メッセージヘッダ内のメッセージＩＤおよびスレッドＩＤはそのままコミュニティサーバ１２２に送信されるので、コミュニティサーバ１２２の返信メール処理部１３０は、メッセージヘッダを解析して得られるこのメッセージＩＤおよびスレッドＩＤに基づき、この返信メールをコミュニティ管理情報１２４とメッセージデータ１２５とにて管理・格納する。
【００９７】
一方、図２２は、返信メールの第２の処理方法を示した図であり、メールクライアント１１２がヘッダ情報を認識する機能がないために落とされる（削除される）場合の説明図である。
【００９８】
投稿メッセージがメールクライアント１１２により受信され、ユーザが当該メッセージに対して返信メールを送信すると、メッセージヘッダ内のメッセージＩＤおよびスレッドＩＤは削除されてコミュニティサーバ１２２に送信されるので、コミュニティサーバ１２２の返信メール処理部１３０は、ＳＵＢＪＥＣＴを解析して得られるコミュニティ名、メッセージ番号およびタイトルに基づき、この返信メールをコミュニティ管理情報１２４とメッセージデータ１２５とにて管理・格納する。
【００９９】
図２３は、図２１および図２２で示した返信メールの処理方法を示すフローチャートである。
【０１００】
まず、コミュニティサーバ１２２が、メッセージを検索してメールクライアント１１２に送信する（ステップＣ１）。一方、このメッセージを受信したメールクライアント１１２のユーザが返信メールを作成すると（ステップＣ２）、メールクライアント１１２は、その返信メールをコミュニティサーバ１２２に送信する（ステップＣ３）。
【０１０１】
コミュニティサーバ１２２の返信メール処理部１３０は、返信メールのメッセージヘッダ内にメッセージＩＤとスレッドＩＤがあるかをチェックし（ステップＣ４）、ない場合には（ステップＣ５のＮＯ）、ＳＵＢＪＥＣＴ内に含まれているコミュニティ名とメッセージ番号とタイトルとを使用して、コミュニティ管理を行うとともに、メッセージデータ１２５に格納してこの処理を終了し（ステップＣ６）、一方、あった場合には（ステップＣ５のＹＥＳ）、このメッセージＩＤとスレッドＩＤとを使用して、コミュニティ管理を行うとともに、メッセージデータ１２５に格納し処理を終了する（ステップＣ７）。
【０１０２】
このように、この知識蓄積支援システムは、メッセージヘッダに加えて、ＳＵＢＪＥＣＴを解析する仕組みを備えるため、意図的に埋め込んだ制御情報を認識できずに欠落してしまうメールクライアント１１２にも対応でき、返信メールを該当する場所に自動的かつ確実に格納することを実現する。
【０１０３】
なお、本実施形態の知識蓄積支援システムの機能は全てコンピュータプログラムにより実現されているので、そのコンピュータプログラムをコンピュータ読み取り可能な記憶媒体に記憶しておき、その記憶媒体を通じてコンピュータプログラムを、コンピュータネットワーク接続可能な通常のコンピュータに導入するだけで、本実施形態と同様の効果を得ることができる。
【０１０４】
また本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。更に、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果の欄で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【０１０５】
【発明の効果】
以上、詳述したように、この発明によれば、仮想コミュニティへ投稿されたメッセージをどのように購読するのか、その購読タイプを選択するための仕組みをもつことにより、各ユーザが好みのインタフェースで収集・蓄積された知識を活用することを可能とする。また、この購読タイプを予め定められた管理者ユーザが設定できるようにすることにより、仮想コミュニティにおけるメッセージの購読管理を一元的に行うことを可能とする。
【０１０６】
また、電子メールシステムにより送受信される情報を知識として収集・蓄積するにあたって、ユーザの目に触れることのない制御情報を用いて収集した知識を効率的に分類・蓄積することを可能とし、また、メッセージヘッダに加えて、メッセージのサブジェクトを解析する仕組みをもつことにより、この意図的に埋め込んだ制御情報を認識できずに欠落してしまうメーラーにも対応することができ、ユーザが利用するメーラーの差異を吸収することを可能とする。
【図面の簡単な説明】
【図１】この発明の実施形態に係る知識蓄積支援システムのシステム構成を示すブロック図。
【図２】同実施形態の知識蓄積支援システムで扱われる知識を説明するための図。
【図３】同実施形態の知識蓄積支援システムにおける知識蓄積処理の原理を説明するための図。
【図４】同実施形態の知識蓄積支援システムで管理されるメッセージとスレッドとの関係を説明するための図。
【図５】同実施形態の知識蓄積支援システムで管理されるメッセージと「まとめ」との関係を説明するための図。
【図６】同実施形態の知識蓄積支援システムで使用されるユーザテーブルの一例を示す図。
【図７】同実施形態の知識蓄積支援システムで使用されるコミュニティテーブルの一例を示す図。
【図８】同実施形態の知識蓄積支援システムで使用される購読タイプテーブルの一例を示す図。
【図９】同実施形態の知識蓄積支援システムで使用されるメンバテーブルの一例を示す図。
【図１０】同実施形態の知識蓄積支援システムで使用されるスレッドテーブルの一例を示す図。
【図１１】同実施形態の知識蓄積支援システムで使用されるメッセージテーブルの一例を示す図。
【図１２】同実施形態の知識蓄積支援システムで使用されるまとめテーブルの一例を示す図。
【図１３】同実施形態の知識蓄積支援システムにおいて個人用画面でのメッセージの購読タイプの変更を行う際のＷｅｂブラウザ画面の状態遷移を示す図。
【図１４】同実施形態の知識蓄積支援システムにおいて管理者用画面でのメッセージの購読タイプの変更を行う際のＷｅｂブラウザ画面の状態遷移を示す第１の図。
【図１５】同実施形態の知識蓄積支援システムにおいて管理者用画面でのメッセージの購読タイプの変更を行う際のＷｅｂブラウザ画面の状態遷移を示す第２の図。
【図１６】同実施形態の知識蓄積支援システムにおける購読タイプ変更処理の流れを示した図。
【図１７】同実施形態の知識蓄積支援システムにおける購読タイプ変更処理の手順を示すフローチャート。
【図１８】同実施形態の知識蓄積支援システムにおいて管理者があるユーザを購読から脱退させる処理の手順を示すフローチャート。
【図１９】同実施形態の知識蓄積支援システムにおける投稿メッセージに対するメール返信処理の流れを示したブロック図。
【図２０】同実施形態の知識蓄積支援システムにおける投稿メッセージの構造を示す図。
【図２１】同実施形態の知識蓄積支援システムにおける返信メールの第１の処理方法を示した図。
【図２２】同実施形態の知識蓄積支援システムにおける返信メールの第２の処理方法を示した図。
【図２３】同実施形態の知識蓄積支援システムにおける返信メールの処理の流れを示したフローチャート。
【符号の説明】
１１…クライアント端末
１２…サーバコンピュータ
１１１…Ｗｅｂブラウザ
１１２…メールクライアント
１２１…制御部
１２２…コミュニティサーバ
１２３…ログイン管理情報
１２４…コミュニティ管理情報
１２５…メッセージデータ
１２６…添付ファイル
１２７…Ｗｅｂサーバ
１２８…メールサーバ
１２９…購読タイプ設定部
１３０…返信メール処理部
２０１…ユーザテーブル
２０２…コミュニティテーブル
２０３…購読タイプテーブル
２０４…メンバテーブル
２０５…スレッドテーブル
２０６…メッセージテーブル
２０７…まとめテーブル
【図１】
0004213360.tif 000002
【図２】
0004213360.tif 000003
【図３】
0004213360.tif 000004
【図４】
0004213360.tif 000005
【図５】
0004213360.tif 000006
【図６】
0004213360.tif 000007
【図７】
0004213360.tif 000008
【図８】
0004213360.tif 000009
【図９】
0004213360.tif 000010
【図１０】
0004213360.tif 000011
【図１１】
0004213360.tif 000012
【図１２】
0004213360.tif 000013
【図１３】
0004213360.tif 000014
【図１４】
0004213360.tif 000015
【図１５】
0004213360.tif 000016
【図１６】
0004213360.tif 000017
【図１７】
0004213360.tif 000018
【図１８】
0004213360.tif 000019
【図１９】
0004213360.tif 000020
【図２０】
0004213360.tif 000021
【図２１】
0004213360.tif 000022
【図２２】
0004213360.tif 000023
【図２３】
0004213360.tif 000024