(57)【要約】【課題】ＷＷＷサイトにとって自らのＷｅｂページの不具合を監視することの負担を軽減する。【解決手段】ＷＷＷサイト２において公開されるＷｅｂページの不具合に関する不具合情報を管理する不具合情報管理サーバ１に、ユーザが端末装置３でＷｅｂページを閲覧しているときに見つかったＷｅｂページの不具合情報を不具合報告情報ＤＴ１としてその端末装置３から取得する不具合情報取得部１０１と、取得された不具合報告情報ＤＴ１の送信元のユーザに対して不具合情報の提供の報奨を与えるための処理を行う報奨金支払処理部１６１と、取得された不具合報告情報ＤＴ１に係るＷｅｂページを公開するＷＷＷサイト２の運営者に対してＷｅｂページに不具合がある旨の通報を行う不具合通報部１０２と、を設ける。【選択図】      図３
2004157906.tif 000002
【特許請求の範囲】
【請求項１】
ＷＷＷサイトにおいて公開されるＷｅｂページの不具合に関する不具合情報を管理する不具合情報管理サーバであって、
ユーザが端末装置でＷｅｂページを閲覧しているときに見つかった当該Ｗｅｂページの不具合の前記不具合情報を当該端末装置から取得する不具合情報取得手段と、
前記不具合情報取得手段によって取得された前記不具合情報の送信元のユーザに対して当該不具合情報の提供の報奨を与えるための処理を行う報奨付与手段と、
前記不具合情報取得手段によって取得された前記不具合情報に係るＷｅｂページを公開するＷＷＷサイトの運営者に対して当該Ｗｅｂページに不具合がある旨の通報を行う不具合通報手段と、
を有してなることを特徴とする不具合情報管理サーバ。
【請求項２】
前記報奨付与手段は、取得された複数の前記不具合情報が同じＷｅｂページの同じ不具合に関するものである場合は、より早く当該不具合情報を提供した所定の人数のユーザに対してのみ報奨を与える、
請求項１記載の不具合情報管理サーバ。
【請求項３】
Ｗｅｂページに不具合がある旨の通報を行ったことに対する対価を、当該Ｗｅｂページを公開するＷＷＷサイトから徴収するための処理を行う通報対価徴収手段を有してなる、
請求項１または請求項２記載の不具合情報管理サーバ。
【請求項４】
前記不具合情報取得手段によって取得された前記不具合情報を記憶する不具合情報データベースと、
端末装置から依頼された、当該端末装置のユーザが閲覧しようとするＷｅｂページに不具合があるか否かの判別を行う、不具合有無判別手段と、
前記不具合有無判別手段による判別結果を依頼元の端末装置に送信する結果送信手段と、を有し、
前記不具合情報には、当該不具合情報に係るＷｅｂページのＵＲＬが含まれており、
前記不具合有無判別手段は、前記閲覧しようとするＷｅｂページのＵＲＬと前記不具合情報データベースに記憶されている前記各不具合情報のＵＲＬとを照合することによって当該Ｗｅｂページに不具合があるか否かを判別する、
請求項１ないし請求項３のいずれかに記載の不具合情報管理サーバ。
【請求項５】
前記判別を行ったことに対する対価を、当該判別の依頼元の端末装置のユーザから徴収するための処理を行う判別対価徴収手段を有してなる、
請求項４記載の不具合情報管理サーバ。
【請求項６】
Ｗｅｂページの不具合に関する不具合情報を管理する不具合情報管理サーバに接続可能な端末装置であって、
Ｗｅｂページの不具合のパターンごとに当該パターンを示すパターン情報を記憶するパターン情報記憶手段と、
ユーザが閲覧しているＷｅｂページを構成するためのコード群の中にいずれかの前記パターン情報に示されるパターンが含まれているか否かを調べることによって、当該Ｗｅｂページに含まれる不具合を発見する不具合発見手段と、
前記不具合発見手段によって発見された不具合を前記不具合情報管理サーバに報告するための処理を行う不具合報告手段と、
を有してなることを特徴とする端末装置。
【請求項７】
前記不具合情報管理サーバで管理されている前記不具合情報を取得する不具合情報取得手段を有し、
前記不具合報告手段は、前記不具合発見手段によって発見されたＷｅｂページの不具合が前記不具合情報取得手段によって取得された前記各不具合情報のいずれにも示されていない場合に、当該不具合を前記不具合情報管理サーバに報告するための処理を行う、
請求項６記載の端末装置。
【請求項８】
ＷＷＷサイトにおいて公開されるＷｅｂページの不具合に関する不具合情報を当該ＷＷＷサイトに対して通報する不具合通報方法であって、
ユーザが端末装置でＷｅｂページを閲覧しているときに見つかった当該Ｗｅｂページの不具合の前記不具合情報を当該端末装置から取得するステップと、
取得された前記不具合情報の送信元のユーザに対して当該不具合情報の提供の報奨を与えるための処理を行うステップと、
取得された前記不具合情報に係るＷｅｂページを公開するＷＷＷサイトの運営者に対して当該Ｗｅｂページに不具合がある旨の通報を行うステップと、
を有してなることを特徴とする不具合通報方法。
【請求項９】
ＷＷＷサイトにおいて公開されるＷｅｂページの不具合に関する不具合情報を管理するコンピュータに用いられるコンピュータプログラムであって、
ユーザが端末装置でＷｅｂページを閲覧しているときに見つかった当該Ｗｅｂページの不具合の前記不具合情報を当該端末装置から取得する処理と、
取得された前記不具合情報の送信元のユーザに対して当該不具合情報の提供の報奨を与えるための処理を行う処理と、
取得された前記不具合情報に係るＷｅｂページを公開するＷＷＷサイトの運営者に対して当該Ｗｅｂページに不具合がある旨の通報を行う処理と、
をコンピュータに実行させるためのコンピュータプログラム。
【請求項１０】
Ｗｅｂページの不具合に関する不具合情報を管理する不具合情報管理サーバに接続可能であり、Ｗｅｂページの不具合のパターンごとに当該パターンを示すパターン情報を記憶するパターン情報記憶手段を有するコンピュータに用いられるコンピュータプログラムであって、
ユーザが閲覧しているＷｅｂページを構成するためのコード群の中にいずれかの前記パターン情報に示されるパターンが含まれているか否かを調べることによって、当該Ｗｅｂページに含まれる不具合を発見する処理と、
発見された不具合を前記不具合情報管理サーバに報告する処理と、
をコンピュータに実行させるためのコンピュータプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ユーザの端末装置で発見されたＷｅｂページの不具合に関する情報を管理する不具合情報管理サーバなどに関する。
【０００２】
【従来の技術】
近年、インターネットの発達により、多くの企業、団体、および個人などがＷＷＷサイト（Ｗｅｂサイト）を開設するようになった。これにより、ＷＷＷサイトから発信されるＷｅｂページの数および種類が増加している。
【０００３】
さらに、様々な技術を用いたＷｅｂページが実現されている。例えば、ＷＷＷサーバにおいてＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）のプログラムを実行させることによって、電子掲示板（ＢＢＳ）を備えたＷｅｂページが実現されている。これにより、多くのユーザ同士が電子掲示板で意見を交換することができる。また、端末装置のＷＷＷブラウザにおいてＪａｖａＳｃｒｉｐｔ（登録商標）、Ｊａｖａアプレット（商標）、またはＡｃｔｉｖｅＸコントロール（商標）などの言語で書かれたプログラムを実行させることによって、変化のある動的なＷｅｂページや複雑な処理を行うＷｅｂページなどが実現されている。このように、インターネットを利用するユーザは、多種多様な形態のＷｅｂページを閲覧し利用することができるようになった。
【０００４】
【特許文献１】
特開２０００−１０１６３５号公報
【０００５】
【特許文献２】
特開２００１−１８８８２５号公報
【０００６】
【発明が解決しようとする課題】
ところが、様々な技術の発達により、ＷＷＷサイトにとってもユーザにとっても具合の悪いＷｅｂページが公開されてしまう危険性が増している。例えば、ウィルスに感染したＷｅｂページが公開されると、ＷＷＷサイトにとってはユーザに対する信用を失ってしまうおそれがあり、Ｗｅｂページを閲覧したユーザにとっては自分の端末装置のシステムを壊されるなど悪影響を受けるおそれがある。クラッカ（悪意を持ったハッカ）によってＷｅｂページがアタックを仕掛けるものに改変されてしまうと、やはり、ＷＷＷサイトは信用を失い、ユーザは端末装置のシステムに被害を受けるおそれがある。
【０００７】
また、他人を誹謗中傷する発言や嘘の情報などが電子掲示板に書き込まれると、ユーザは不快な思いをするなどの不利益を被るおそれがあり、ＷＷＷサイトは閉鎖に追い込まれるおそれがある。その他、ポルノなどの成人向けのＷｅｂページを制限なく閲覧できると、子どもがインターネットで情報検索を行う場合に不都合である。
【０００８】
そこで、ＷＷＷサイトの運営者は、自ら公開しているＷｅｂページの内容に責任を持ち、Ｗｅｂページに不具合がないかどうか把握しておく必要がある。一方、ユーザは、不具合のあるＷｅｂページに関する情報を収集し、そのようなＷｅｂページにはアクセスしないように注意する必要がある。
【０００９】
しかし、公開しているＷｅｂページを監視し続けることはＷＷＷサイトの運営者にとって大きな負担となる。また、インターネット上では次々に新しいＷｅｂページが発信されるため、不具合のあるＷｅｂページに関する情報を収集することはユーザにとって大きな負担となる。上記の特許文献１、２に示される技術を用いたとしても、Ｗｅｂページの不具合に関する情報を効率的に集め、ＷＷＷサイトの運営者およびユーザの負担を軽減することはできない。
【００１０】
本発明は、このような問題点に鑑み、ＷＷＷサイトの運営者にとって自らのＷｅｂページの不具合を監視することの負担を軽減することを目的とする。また、ユーザにとって不具合のあるＷｅｂページへアクセスすることを効率的に防止することを目的とする。
【００１１】
【課題を解決するための手段】
本発明に係る不具合情報管理サーバは、ＷＷＷサイトにおいて公開されるＷｅｂページの不具合に関する不具合情報を管理する不具合情報管理サーバであって、ユーザが端末装置でＷｅｂページを閲覧しているときに見つかった当該Ｗｅｂページの不具合の前記不具合情報を当該端末装置から取得する不具合情報取得手段と、前記不具合情報取得手段によって取得された前記不具合情報の送信元のユーザに対して当該不具合情報の提供の報奨を与えるための処理を行う報奨付与手段と、前記不具合情報取得手段によって取得された前記不具合情報に係るＷｅｂページを公開するＷＷＷサイトの運営者に対して当該Ｗｅｂページに不具合がある旨の通報を行う不具合通報手段とを有してなる。
【００１２】
好ましくは、前記報奨付与手段は、取得された複数の前記不具合情報が同じＷｅｂページの同じ不具合に関するものである場合は、より早く当該不具合情報を提供した所定の人数のユーザに対してのみ報奨を与える。
【００１３】
または、Ｗｅｂページに不具合がある旨の通報を行ったことに対する対価を、当該Ｗｅｂページを公開するＷＷＷサイトから徴収するための処理を行う通報対価徴収手段を有してなる。
【００１４】
または、前記不具合情報取得手段によって取得された前記不具合情報を記憶する不具合情報データベースと、端末装置から依頼された、当該端末装置のユーザが閲覧しようとするＷｅｂページに不具合があるか否かの判別を行う、不具合有無判別手段と、前記不具合有無判別手段による判別結果を依頼元の端末装置に送信する結果送信手段とを有し、前記不具合情報には、当該不具合情報に係るＷｅｂページのＵＲＬが含まれており、前記不具合有無判別手段は、前記閲覧しようとするＷｅｂページのＵＲＬと前記不具合情報データベースに記憶されている前記各不具合情報のＵＲＬとを照合することによって当該Ｗｅｂページに不具合があるか否かを判別する。または、前記判別を行ったことに対する対価を、当該判別の依頼元の端末装置のユーザから徴収するための処理を行う判別対価徴収手段を有してなる。
【００１５】
本発明に係る端末装置は、Ｗｅｂページの不具合に関する不具合情報を管理する不具合情報管理サーバに接続可能な端末装置であって、Ｗｅｂページの不具合のパターンごとに当該パターンを示すパターン情報を記憶するパターン情報記憶手段と、ユーザが閲覧しているＷｅｂページを構成するためのコード群の中にいずれかの前記パターン情報に示されるパターンが含まれているか否かを調べることによって、当該Ｗｅｂページに含まれる不具合を発見する不具合発見手段と、前記不具合発見手段によって発見された不具合を前記不具合情報管理サーバに報告するための処理を行う不具合報告手段とを有してなる。
【００１６】
好ましくは、前記不具合情報管理サーバで管理されている前記不具合情報を取得する不具合情報取得手段を有し、前記不具合報告手段は、前記不具合発見手段によって発見されたＷｅｂページの不具合が前記不具合情報取得手段によって取得された前記各不具合情報のいずれにも示されていない場合に、当該不具合を前記不具合情報管理サーバに報告するための処理を行う。
【００１７】
本発明において、「不具合」とは、ＷＷＷサイトの運営者およびＷｅｂページを閲覧するユーザのうち少なくともいずれか一方の者にとって具合が悪いことまたは都合が悪いことなどを意味する。
【００１８】
【発明の実施の形態】
図１は本発明に係る不具合情報管理サーバ１および端末装置３を有する不具合情報管理システムの構成の例を示す図、図２は不具合情報管理サーバ１のハードウェア構成の例を示す図、図３は不具合情報管理サーバ１の機能的構成の例を示す図、図４はユーザ情報データベース１Ｄ１の例を示す図、図５はサイト情報データベース１Ｄ２の例を示す図、図６は不具合カテゴリデータベース１Ｄ３の例を示す図、図７は不具合報告フォームＨＧ１の例を示す図、図８は不具合情報データベース１Ｄ４の例を示す図、図９は不具合情報ＤＴ２を報告する電子メールの例を示す図、図１０は注意画面ＨＧ２の例を示す図である。
【００１９】
図１に示すように、本発明に係る不具合情報管理サーバ１は、例えばプロバイダ（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ  ）１００によって運営されており、各ＷＷＷサイト２で公開されているＷｅｂページの不具合についての情報を管理している。以下、係る情報を「不具合情報」と記載することがある。この不具合情報管理サーバ１は、インターネットを利用するユーザ（以下、単に「ユーザ」と記載する。）の端末装置３、ＷＷＷサイト２の各装置、および銀行または信販会社などのシステムにネットワーク４を介して接続し、後に説明する報奨金の支払または料金の引落としに関する情報のやり取りを行うことができる。ネットワーク４として、インターネット、専用線、または公衆回線などが用いられる。
【００２０】
端末装置３は、ＷＷＷブラウザ機能および通信装置を有するパーソナルコンピュータ、携帯電話装置、またはＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）などである。ユーザは、端末装置３にＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を入力するなどして各ＷＷＷサイト２で公開されているＷｅｂページを閲覧することができる。ユーザは、閲覧しているＷｅｂページの中に不具合を発見することがある。このとき、プロバイダ１００に対してその不具合についての情報（不具合情報）を提供することにより、プロバイダ１００を介してＷＷＷサイト２から報奨金を得ることができる。また、ユーザは、プロバイダ１００に集められた不具合情報を用いて、自分が閲覧しようとしているＷｅｂページに不具合があるかどうかを検査（チェック）するサービスを受けることができる。この場合は、ユーザはプロバイダ１００に対して利用料金を支払うことになる。つまり、ユーザは、不具合情報の提供者でもあり利用者でもある。
【００２１】
各ＷＷＷサイト２は、端末装置３で発見されプロバイダ１００に提供された不具合情報のうち自らが公開しているＷｅｂページに関するものを提供してもらうように、プロバイダ１００と契約を結んでいる。ＷＷＷサイト２の形態として、企業、学校、研究機関、および公共団体などが運営するＷＷＷサイト、およびプロバイダ１００または他のプロバイダに加入しているユーザが運営するＷＷＷサイト（いわゆる個人サイト）などがある。
【００２２】
ＷＷＷサイト２は、ＷＷＷサーバ２ａによって実現される。基本的に１つのＷＷＷサイト２ごとに１台または複数台のＷＷＷサーバ２ａが設けられている。ただし、個人サイト、企業の支店または関連会社のＷＷＷサイト、または団体の支部のＷＷＷサイトなどの場合は、プロバイダ、本社、または本部のＷＷＷサーバ２ａが共用されることがある。また、各ＷＷＷサイト２の運営者は、プロバイダ１００からの不具合情報を受信するための端末装置２ｂを有している。
【００２３】
不具合情報管理サーバ１は、図２に示すように、ＣＰＵ１０ａ、ＲＡＭ１０ｂ、ＲＯＭ１０ｃ、磁気記憶装置１０ｄ、ディスプレイ装置１０ｅ、マウスまたはキーボードなどの入力装置１０ｆ、および各種インタフェースなどによって構成される。磁気記憶装置１０ｄには、ＯＳ（オペレーティングシステム）および後に説明する処理を行うためのプログラムおよびデータが記憶されている。プログラムおよびデータは必要に応じてＲＡＭ１０ｂにロードされ、ＣＰＵ１０ａによってプログラムが実行される。
【００２４】
このような構成によって、不具合情報管理サーバ１には、図３に示すように、不具合情報取得部１０１、不具合通報部１０２、不具合情報配付部１０３、不具合照会部１０４、不具合通知部１０５、金銭処理部１０６、および情報記憶部１０７などの機能が実現される。
【００２５】
情報記憶部１０７は、ユーザ情報データベース１Ｄ１、サイト情報データベース１Ｄ２、不具合カテゴリデータベース１Ｄ３、および不具合情報データベース１Ｄ４などを有している。
【００２６】
ユーザ情報データベース１Ｄ１には、図４に示すように、プロバイダ１００に加入しているユーザのユーザＩＤ、氏名、連絡先、電子メールアドレス、および不具合情報の提供に対する報奨金の振込先の口座番号などに関する情報が格納されている。
【００２７】
サイト情報データベース１Ｄ２には、図５に示すように、プロバイダ１００のサービス（不具合情報の提供）を受けるＷＷＷサイト２のサイトＩＤ、サイト名、そのＷＷＷサイト２のルートとなるＵＲＬ（ルートＵＲＬ）、連絡先、および運営者の電子メールアドレスなどに関する情報が格納されている。
【００２８】
不具合カテゴリデータベース１Ｄ３には、図６に示すように、不具合の種類（カテゴリ）がカテゴリＩＤと対応付けて格納されている。「ウィルス感染」は、Ｗｅｂページがウィルスに感染していることを意味する。「リンク切れ」は、Ｗｅｂページに設けられたハイパーリンクの全部または一部が正しくリンクされていないことを意味する。「Ｗｅｂページ不存在」は、ＵＲＬが指すＷｅｂページが存在しないことを意味する。
【００２９】
「アタック」は、端末装置３に対して悪意のある攻撃が仕掛けられることを意味する。アタック（攻撃）として、例えば、ＷＷＷブラウザのウィンドウを無限に開かせるプログラムを端末装置３に実行させ、ＣＰＵなどに大きな負荷を発生させてダメージを与えるようなものがある。「エラー発生」は、ＷＷＷブラウザでＷｅｂページの機能を実現するためのプログラムを実行すると、エラーが発生することを意味する。「成人向け情報」、「不法行為の情報」「間違った情報」、および「古い情報」は、それぞれ、ポルノなど未成年者にとっては好ましくない情報、薬物や危険物などの無許可での売買またはマルチ商法の斡旋などの不法行為にユーザを導く情報、事実とは異なる情報、および時間の経過により無用になってしまった情報（例えば期間が終了したキャンペーンの情報）が掲載されていることを意味する。
【００３０】
不具合情報取得部１０１はユーザが発見した不具合情報をそのユーザの端末装置３から取得し、情報記憶部１０７は取得された不具合情報を不具合情報データベース１Ｄ４に登録するための処理を行う。これらの処理は、次のような手順で行われる。
【００３１】
まず、端末装置３において、ユーザは、Ｗｅｂページを閲覧しているときにそのＷｅｂページの不具合を発見すると、ＷＷＷブラウザに所定のＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を入力し、図７に示すような不具合報告フォームＨＧ１を表示させる。この不具合報告フォームＨＧ１を表示するための画面情報すなわちハイパーテキストは、不具合情報管理サーバ１から送信されるようにしてもよいし、別のＷＷＷサーバから送信されるようにしてもよい。
【００３２】
ユーザは、そのＷｅｂページのＵＲＬおよび不具合の状態を不具合報告フォームＨＧ１に入力する。例えば、あるプロバイダの電子掲示板（ＢＢＳ）に人を誹謗中傷する発言が書き込まれているのを発見した場合は、テキストボックスＴＸ１１にその電子掲示板のあるＷｅｂページのＵＲＬを入力し、チェックボックス群ＣＢの中から「誹謗中傷」に対応するチェックボックスをクリックして選択する。さらに、必要に応じて、不具合の具体的な内容をテキストボックスＴＸ１２に入力する。誹謗中傷以外のカテゴリにも該当する場合は、それに対応するチェックボックスも選択しておく。いずれのカテゴリにも該当しない場合または分類することが難しい場合は、「その他」のチェックボックスを選択し、テキストボックスＴＸ１２に不具合の具体的な内容を入力すればよい。
【００３３】
テキストボックスＴＸ１３〜ＴＸ１６には、それぞれ、不具合を発見したユーザのユーザＩＤ、氏名、連絡先、および報奨金の振込先の口座番号を入力する。ただし、プロバイダ１００に加入しているユーザの場合は、氏名などの情報は図４に示すユーザ情報データベース１Ｄ１に登録されているので、ユーザＩＤだけを入力すればよい。加入していないユーザの場合は、ユーザＩＤが与えられていないので、ユーザＩＤ以外の各項目について入力すればよい。送信ボタンＢＮ１がクリックされると、テキストボックスＴＸ１１〜ＴＸ１６に入力された内容およびチェックボックスにチェックされた項目（不具合の状態のカテゴリ）が不具合報告情報ＤＴ１として、ユーザの端末装置３から不具合情報管理サーバ１に送信される。
【００３４】
ここで、図３の不具合情報取得部１０１は、この不具合報告情報ＤＴ１を受け付け、プロバイダ１００の運営者に対してその旨を知らせる。運営者は、直ちに不具合報告情報ＤＴ１に示されるＷｅｂページを閲覧し、報告の内容の真偽を確認する。正しい内容であれば、情報記憶部１０７に対して不具合情報を登録する旨の命令を行う。なお、「Ｗｅｂページ不存在」または「リンク切れ」などのように機械的に真偽の確認が可能なものについては、自動的に確認を行うように構成してもよい。「誹謗中傷」または「間違った情報」などについては、運営者がＷｅｂページを実際に閲覧して確認するのが望ましい。
【００３５】
すると、情報記憶部１０７は、不具合報告情報ＤＴ１に示されるＵＲＬを図８に示すように不具合情報データベース１Ｄ４に格納する。さらに、図６の不具合カテゴリデータベース１Ｄ３に基づいて、そのＵＲＬおよび格納の日時（登録日時）と対応付けて不具合の状態のカテゴリＩＤを登録する。そして、不具合情報取得部１０１は、不具合報告情報ＤＴ１の送信元の端末装置３に対して、情報提供を受け付けた旨のメッセージを送信する。
【００３６】
このようにして、ユーザによって発見された不具合情報が次々に不具合情報管理サーバ１に集められ、蓄積される。以下、図８に示すような登録日時、ＵＲＬ、カテゴリＩＤ、および備考などの情報からなる不具合情報を「不具合情報ＤＴ２」と記載する。なお、不具合報告情報ＤＴ１のうち図７のテキストボックスＴＸ１３〜ＴＸ１６に入力された情報は、ユーザに報奨金を支払うための処理に用いられる。
【００３７】
不具合通報部１０２は、受け付けられた不具合報告情報ＤＴ１の内容が正しいことが確認されると直ちに、その情報に示されるＷｅｂページを公開しているＷＷＷサイト２に対して不具合が発見された旨の通報（報告）を行う。
【００３８】
例えば、図７に示す内容の不具合報告情報ＤＴ１が取得された場合は、まず、図５のサイト情報データベース１Ｄ２に格納されている各ルートＵＲＬと不具合報告情報ＤＴ１に示されるＵＲＬとを比較し、不具合のあるＷｅｂページを公開しているＷＷＷサイト２が「プロバイダＢＢＢ」であることを特定する。そして、図９に示すような不具合情報ＤＴ２を報告する電子メールを生成し、プロバイダＢＢＢの運営者の電子メールアドレスに宛てて送信する。不具合情報ＤＴ２を受け取ったプロバイダＢＢＢの運営者は、その内容を確認し、Ｗｅｂページのメンテナンスを行う。
【００３９】
なお、同時期に同じＷｅｂページの同じ不具合についての不具合報告情報ＤＴ１が複数寄せられた場合は、不具合情報取得部１０１は、最初に取得した不具合報告情報ＤＴ１のみに基づいて不具合情報ＤＴ２の登録を行う。同様に、不具合通報部１０２も、最初の不具合報告情報ＤＴ１のみに基づいてＷＷＷサイトへの通報を行う。
【００４０】
不具合情報配付部１０３は、所定の期間（例えば１週間）の間に不具合情報データベース１Ｄ４に新たに格納された不具合情報ＤＴ２を、各ユーザの端末装置３に送信する。または、不具合情報データベース１Ｄ４に新たに格納されるごとにその不具合情報ＤＴ２を送信するようにしてもよいし、端末装置３から要求があった場合に送信するようにしてもよい。
【００４１】
この不具合情報ＤＴ２は、端末装置３において、不具合情報データベース３Ｄ１（図１６参照）に格納され、ユーザが閲覧しようとするＷｅｂページの内容の検査（チェック）のために次のように用いられる。ユーザがＷＷＷブラウザでＷｅｂページを閲覧しようとすると、端末装置３にインストールされているチェックプログラムが起動し、そのＷｅｂページのＵＲＬが不具合情報データベース３Ｄ１のいずれかの不具合情報ＤＴ２に示されるＵＲＬと一致するか否か判別する。そして、いずれかの不具合情報ＤＴ２に示されるＵＲＬと一致した場合は、図１０に示すように、その不具合情報ＤＴ２の内容を注意画面ＨＧ２に表示し、閲覧しようとしているＷｅｂページに不具合がある旨の注意をユーザに対して与える。
【００４２】
図６に示す種々の不具合のカテゴリのうち、いずれのカテゴリについて注意が与えられるかを、ユーザが端末装置３に自由に設定できるようにしてもよい。例えば、子どもが端末装置３を使用する場合は、「成人向け」のＷｅｂページにアクセスしようとすると注意が与えられるように設定する。または、「リンク切れ」および「Ｗｅｂページ不存在」のＷｅｂページについては端末装置３のシステムにとっては害がないので注意が与えられず、「ウィルス感染」および「アタック」のＷｅｂページについては害があるので注意が与えられるように設定してもよい。
【００４３】
ユーザが閲覧しようとするＷｅｂページの内容の検査を、端末装置３ではなく不具合情報管理サーバ１で行うこともできる。図３の不具合照会部１０４は、端末装置３において閲覧しようとするＷｅｂページのＵＲＬが指定されると、そのＵＲＬが不具合情報データベース１Ｄ４に記憶されているいずれかの不具合情報ＤＴ２のＵＲＬと一致するか否か判別する。いずれかのＵＲＬと一致した場合は、不具合通知部１０５は、図１０に示す注意画面ＨＧ２を表示するための画面情報を結果情報ＤＴ３とともに端末装置３に送信する。すると、端末装置３は、注意画面ＨＧ２を表示するとともに、指定されたＵＲＬのＷｅｂページへのアクセスを中止する。一致しなかった場合は、不具合がない旨の結果情報ＤＴ３を端末装置３に送信する。すると、端末装置３は、指定されたＵＲＬのＷｅｂページへのアクセスを開始する。
【００４４】
金銭処理部１０６は、報奨金支払処理部１６１、通報料金処理部１６２、および検査料金処理部１６３などによって構成され、プロバイダ１００とユーザおよびＷＷＷサイト２との間で行われる金銭のやり取りに関する処理を行う。
【００４５】
報奨金支払処理部１６１は、プロバイダ１００に不具合情報を提供してくれたユーザに対して報奨金を支払うための処理を行う。同じＷｅｂページの同じ不具合についての不具合情報が多数寄せられた場合は、その不具合情報に対する報奨金は、先着順に所定の人数（例えば先着１０人）にのみ支払われる。さらに、その所定の人数の中でも、より早く不具合情報を提供してくれたユーザに対してより高額の報奨金（例えば先着順に５００円、３００円、…）が支払われる。
【００４６】
すなわち、報奨金支払処理部１６１は、同じ不具合の内容を示す不具合情報（不具合報告情報ＤＴ１）が受信されるごとにその人数をカウントし、所定の人数に達するまで情報提供者（ユーザ）の口座に所定の金額を振込む処理を行う。
【００４７】
通報料金処理部１６２は、不具合の通報先（不具合情報ＤＴ２の送信先）であるＷＷＷサイト２から通報の料金を徴収するための処理を行う。例えば、ＷＷＷサイト２が指定する口座から料金を引き落とす処理を行う。または、プロバイダ１００の口座に料金を振り込むように要求する電子メールをＷＷＷサイト２の運営者に対して送信する。これらの処理は、所定の期間（例えば１ヶ月間）の分を一括して行ってもよいし、不具合情報ＤＴ２を送信するごとに行ってもよい。また、課金は、１つの不具合情報ＤＴ２ごとに行ってもよいし（従量制）、不具合情報ＤＴ２の数に関わらず本サービスの使用期間に応じて行ってもよい（定額制）。
【００４８】
検査料金処理部１６３は、不具合情報配付部１０３が端末装置３に対して配付した検査用の不具合情報ＤＴ２の提供料金または不具合照会部１０４が行った検査の料金をユーザから徴収するための処理を行う。通報料金処理部１６２の場合と同様に、料金の徴収はユーザが指定する口座から引き落とすなどして行えばよいし、課金は従量制または定額制で行えばよい。
【００４９】
図１１は不具合情報管理サーバ１における不具合情報の収集の処理の流れを説明するフローチャート、図１２は対提供者処理の流れの例を説明するフローチャート、図１３は対ＷＷＷサイト処理の流れの例を説明するフローチャート、図１４は加入者の端末装置３に対して不具合情報を与える処理の流れの例を説明するフローチャート、図１５は非加入者の端末装置３に対して不具合情報を与える処理の流れの例を説明するフローチャートである。
【００５０】
次に、不具合情報管理サーバ１および端末装置３の処理の流れを、フローチャートを参照して説明する。不具合情報管理サーバ１は、図１１に示すように、端末装置３において発見されたＷｅｂページの不具合情報を受け付けると（＃１）、その端末装置３に対して情報の受付を完了した旨の通知を行う（＃２）。
【００５１】
受け付けられた不具合情報が不具合情報データベース１Ｄ４にすでに登録されており、かつ、その不具合情報についての報奨金が所定の人数に対してすでに支払われているか否かを確認する（＃３）。登録済みでありかつ支払済みである場合は（＃３でＹｅｓ）、情報提供者（ユーザ）に対してその旨を通知し（＃４）、処理を終了する。
【００５２】
その不具合情報が初めて得られた情報であれば（＃５でＹｅｓ）、その不具合情報の内容が正しいか否かを調査する（＃６）。調査の結果、内容が正しくないと判別された場合または正しいことを確認できなかった場合は（＃７でＮｏ）、その旨を情報提供者に対して通知し（＃８）、処理を終了する。内容が正しければ（＃７でＹｅｓ）、不具合情報データベース１Ｄ４にその不具合情報を登録する（＃９）。
【００５３】
情報提供者に支払う報奨金などについての処理を図１２に示すような手順で行う（＃１０）。まず、その不具合情報を提供してくれた順番に基づいて報奨金の額を決める（＃１０１）。前に述べたように、同じ内容の不具合情報が複数寄せられた場合は、より早く提供してくれたユーザほど、より多くの報奨金が支払われる。不具合情報についての調査結果および報奨金の査定結果を情報提供者に対して通知する（＃１０２）。そして、情報提供者の口座に報奨金を振り込むための処理を行う（＃１０３）。
【００５４】
ステップ＃１０の処理と並行してまたは前後して、不具合情報に示されるＷｅｂページを公開しているＷＷＷサイトに対する処理を図１３に示すような手順で行う（＃１１）。そのＷＷＷサイトに対して、図９に示すような電子メールを送信することによって不具合のあるＷｅｂページについての通報を行う（＃１１１）。そして、そのＷＷＷサイトから通報の料金を徴収するための処理を行う（＃１１２）。
【００５５】
また、図１４に示すように、不具合情報管理サーバ１は、Ｗｅｂページに不具合があるか否かを検査するための不具合情報ＤＴ２を端末装置３から要求されると（＃２１）、その端末装置３のユーザに利用権があるか否かすなわちプロバイダ１００の加入者であるか否かを判別する（＃２２）。利用権がある場合は、（＃２２でＹｅｓ）要求された不具合情報ＤＴ２を端末装置３に送信する（＃２３）。利用権がない場合は（＃２２でＮｏ）、不具合情報ＤＴ２を送信せず、利用権がない旨を通知する（＃２４）。
【００５６】
なお、プロバイダ１００に加入していないユーザのために、図１５に示すような処理を行ってもよい。すなわち、端末装置３から不具合情報ＤＴ２の要求をユーザの氏名、連絡先、および口座の番号などの情報とともに受け付けると（＃３１）、その口座から不具合情報ＤＴ２の料金を引き落とすための処理を行う（＃３２）。引落としに成功した場合は（＃３３でＹｅｓ）、要求された不具合情報ＤＴ２を端末装置３に送信する（＃３４）。失敗した場合は（＃３３でＮｏ）、課金できなかった旨を端末装置３に通知する（＃３５）。
【００５７】
本実施形態によると、ＷＷＷサイトの運営者は、自らのＷｅｂページの不具合の監視の負担を軽減することができる。また、不具合情報管理サーバ１を運営するプロバイダは、Ｗｅｂページの不具合情報を早く提供してくれたユーザに対して報奨を与えることにより、ユーザの情報提供の意欲を高め、効果的に不具合情報を収集することができる。さらに、端末装置のユーザは、不具合のあるＷｅｂページへアクセスすることを効率的に防止することができる。
【００５８】
図１６は端末装置３の機能的構成の例を示す図、図１７は不具合発見プログラムを起動したときの端末装置３の処理の流れの例を説明するフローチャートである。
【００５９】
本実施形態では、不具合情報は、端末装置３のユーザによって発見され、図７に示す不具合報告フォームＨＧ１にユーザが所定の事項を入力することによって不具合情報管理サーバ１に報告されたが、ユーザの操作によらず自動的に発見され報告されるようにしてもよい。
【００６０】
この場合は、端末装置３には、図１６に示すようなパターン情報データベース３０１、不具合発見部３０２、および不具合報告部３０３などの機能を実現するためのプログラム（不具合発見プログラム）をインストールしておく。また、不具合情報管理サーバ１には、Ｗｅｂページの様々な不具合について、その特徴のパターンを示すパターン情報ＤＴ４を用意しておく。例えば、成人向けのＷｅｂページに頻繁に用いられる語句（キーワード）を示すパターン情報ＤＴ４、またはアタックを仕掛けるプログラムに頻繁に用いられるコマンドまたはコマンド群を示すパターン情報ＤＴ４などを用意しておく。さらに、新たなＷｅｂページの不具合が発見されるごとに、それに対応するパターン情報ＤＴ４を用意する。そして、定期的（例えば１週間ごと）に新たなパターン情報ＤＴ４を各端末装置３に対して送信するように制御を行う。
【００６１】
図１６において、パターン情報データベース３０１は、通信装置３０ａによって受信されたパターン情報ＤＴ４を記憶する。ユーザがＷｅｂページのＵＲＬを指定すると、ＷＷＷサイトからそのＷｅｂページを実現
（構成）するためのソース（ハイパーテキストまたはＪａｖａＳｃｒｉｐｔなどの言語で記述されたコード群）がダウンロードされる。
【００６２】
不具合発見部３０２は、ユーザに指定されてダウンロードされたＷｅｂページのソースの中に、パターン情報データベース３０１に記憶されているいずれかのパターン情報ＤＴ４に示されるパターンが含まれているか否かを調べる。パターンが含まれていれば、そのＷｅｂページには不具合があると判別することができる。
【００６３】
不具合が発見された場合は、不具合報告部３０３は、ユーザに不具合の状態を知らせるとともに、発見された不具合と不具合情報データベース３Ｄ１に記憶されているいずれかの不具合情報ＤＴ２の不具合とが一致するか否か判別する。一致するものがなかった場合は、ユーザの許可を得た上で、不具合があったＷｅｂページのＵＲＬおよびその状態などの情報を不具合報告情報ＤＴ１’  として不具合情報管理サーバ１に送信する。一致するものがあった場合は、その不具合はすでに不具合情報管理サーバ１に登録されているものなので、不具合情報管理サーバ１への送信の処理は行わない。
【００６４】
つまり、端末装置３は、図１７に示すような手順で自動的に不具合を発見し不具合情報管理サーバ１に報告する処理を行う。ユーザが閲覧しているＷｅｂページに不具合があるか否かを解析する（＃４１）。不具合が発見されなかった場合は（＃４２でＮｏ）、通常通りの処理を行う（＃４３）。不具合が発見された場合は（＃４２でＹｅｓ）、その不具合が既に不具合情報管理サーバ１に登録されているものであるか否か判別する（＃４４）。まだ登録されていないと判別された場合は（＃４５でＮｏ）、ユーザの許可を得て（＃４６）、発見された不具合についての情報を不具合情報管理サーバ１に対して報告する（＃４７）。
【００６５】
このような構成および処理により、ユーザにとって不具合情報の提供の手間を省くことができ、ＷＷＷサイトにとって不具合情報の収集の効率を上げることができる。また、前に説明した不具合報告フォームＨＧ１（図７参照）を不具合発見プログラムと併せて用いることにより、不具合情報の収集の漏れを少なくすることができる。
【００６６】
なお、端末装置３が大容量の記憶手段を有しないもの（例えば携帯電話装置）である場合は、不具合情報管理サーバ１の各データベースに記憶されているパターン情報ＤＴ４および不具合情報ＤＴ２に基づいて不具合の発見および報告の処理を行ってもよい。不具合発見プログラムの利用を促進するために、不具合発見プログラムを端末装置３にインストールしてくれたユーザに対して報奨金（協力金）を支払うようにしてもよい。ユーザの許可を得ることなく不具合情報管理サーバ１に不具合情報を自動的に送信するようにしてもよい。その他、不具合情報の提供は、電子メールにより行えるようにしてもよい。
【００６７】
一般に、Ｗｅｂページを実現する際にＪａｖａＳｃｒｉｐｔなどの言語で記述されたプログラムが用いられている場合は、端末装置３の機種、ブラウザの種類およびバージョン、およびＯＳの種類などの使用環境によって不具合が生じたり生じなかったりする。また、ＨＴＭＬには、特定の種類のＷＷＷブラウザに対してのみ有効なタグ（コード）が存在する。そこで、不具合が見つかった際に、不具合情報とともに端末装置３の使用環境を不具合情報管理サーバ１に報告するように構成してもよい。
【００６８】
本実施形態では、より早く不具合情報を提供してくれたユーザに対してより高額の報奨金を与えたが、全員に対して同額の報奨金を与えてもよい。不具合情報の対価として金銭の代わりにポイントを与え、溜まったポイントに応じて賞品やサービスなどと交換できるようにしてもよい。プロバイダ１００と契約をしているＷＷＷサイトを各ユーザに予め公開しておいてもよい。
【００６９】
プロバイダ１００以外の者が不具合情報管理サーバ１を管理してもよい。例えば、大規模な社内ネットワークを有する企業が、自社の計算機センターに不具合情報管理サーバ１を設け、社員の端末装置３が不具合のあるＷｅｂページによる被害に遭わないように独自に対策を取ってもよい。
【００７０】
不具合情報管理サーバ１を、Ｗｅｂページの不具合情報以外の収集に用いることも可能である。例えば、ＷＷＷサイト２は、自分の欲しい情報をＷｅｂページに公示するとともにプロバイダ１００（不具合情報管理サーバ１）に知らせておく。そして、その情報が端末装置３のユーザからプロバイダ１００に提供されると、ＷＷＷサイト２に転送されるようにする。
【００７１】
その他、不具合情報管理サーバ１、端末装置３の全体または各部の構成、不具合報告フォームＨＧ１の構成、各データベースの構成および内容、処理内容、処理順序などは、本発明の趣旨に沿って適宜変更することができる。
【００７２】
【発明の効果】
本発明によると、ＷＷＷサイトの運営者にとって自らのＷｅｂページの不具合を監視することの負担を軽減することができる。また、請求項４、５の発明によると、ユーザにとって不具合のあるＷｅｂページへアクセスすることを効率的に防止することができる。請求項６、７、１０の発明によると、端末装置で発見されたＷｅｂページの不具合を自動的に収集することができる。
【図面の簡単な説明】
【図１】本発明に係る不具合情報管理サーバおよび端末装置を有する不具合情報管理システムの構成の例を示す図である。
【図２】不具合情報管理サーバのハードウェア構成の例を示す図である。
【図３】不具合情報管理サーバの機能的構成の例を示す図である。
【図４】ユーザ情報データベースの例を示す図である。
【図５】サイト情報データベースの例を示す図である。
【図６】不具合カテゴリデータベースの例を示す図である。
【図７】不具合報告フォームの例を示す図である。
【図８】不具合情報データベースの例を示す図である。
【図９】不具合情報を報告する電子メールの例を示す図である。
【図１０】注意画面の例を示す図である。
【図１１】不具合情報管理サーバにおける不具合情報の収集の処理の流れを説明するフローチャートである。
【図１２】対提供者処理の流れの例を説明するフローチャートである。
【図１３】対ＷＷＷサイト処理の流れの例を説明するフローチャートである。
【図１４】加入者の端末装置に対して不具合情報を与える処理の流れの例を説明するフローチャートである。
【図１５】非加入者の端末装置に対して不具合情報を与える処理の流れの例を説明するフローチャートである。
【図１６】端末装置の機能的構成の例を示す図である。
【図１７】不具合発見プログラムを起動したときの端末装置の処理の流れの例を説明するフローチャートである。
【符号の説明】
１  不具合情報管理サーバ
２  ＷＷＷサイト
３  端末装置
１０１  不具合情報取得部（不具合情報取得手段）
１０２  不具合通報部（不具合通報手段）
１０４  不具合照会部（不具合有無判別手段）
１０５  不具合通知部（結果送信手段）
１６１  報奨金支払処理部（報奨付与手段）
１６２  通報料金処理部（通報対価徴収手段）
１６３  検査料金処理部（判別対価徴収手段）
１Ｄ４  不具合情報データベース（不具合情報データベース）
３０１  パターン情報データベース（パターン情報記憶手段）
３０２  不具合発見部（不具合発見手段）
３０３  不具合報告部（不具合報告手段）
３０ａ  通信装置（不具合情報取得手段）
ＤＴ１  不具合報告情報（不具合情報）
ＤＴ３  結果情報（判別結果）
ＤＴ４  パターン情報
【図１】
2004157906.tif 000003
【図２】
2004157906.tif 000004
【図３】
2004157906.tif 000005
【図４】
2004157906.tif 000006
【図５】
2004157906.tif 000007
【図６】
2004157906.tif 000008
【図７】
2004157906.tif 000009
【図８】
2004157906.tif 000010
【図９】
2004157906.tif 000011
【図１０】
2004157906.tif 000012
【図１１】
2004157906.tif 000013
【図１２】
2004157906.tif 000014
【図１３】
2004157906.tif 000015
【図１４】
2004157906.tif 000016
【図１５】
2004157906.tif 000017
【図１６】
2004157906.tif 000018
【図１７】
2004157906.tif 000019