JP2007265037A - 子供のサイト閲覧申請可否判定方法 - Google Patents

Abstract

【課題】子供のサイト閲覧承認申請に関して子供のサイト閲覧を管理する管理者(実親)に過度の負担をかけることなく、子供のサイト閲覧承認/却下を子供のサイト閲覧端末画面に表示する子供のサイト閲覧申請可否判定方法を提供する。
【解決手段】システムから実親に承認可否判断を依頼する(S101)。依頼された親は、保留リストにあるサイトｎを参照する(S102)。S103では、サイトｎについて承認可否判断する親が承認かを判定する。承認であれば、S104において承認フラグを立てる。一方、承認でなければ、S105において却下フラグを立てる。S106においては、他に承認可否判断待ち（サイト）があるかを判定する。他に承認可否判断待ち（サイト）があれば、S102に戻り、S102〜S106を繰り返す。一方、他に承認可否判断待ち（サイト）がなければ、親の承認可否判断処理を終了する。
【選択図】図１０

Description

本発明は、インターネット上で子供に安全なホームページのみを閲覧させる際に子供のサイト閲覧申請に対して実の親に大きな負担を掛けさせずに子供の閲覧申請の可否を判定する技術に関する。

インターネット上にはさまざまな情報が氾濫しており、子供が関心を示す情報の中には子供にとって有害な情報も多々ある。このような有害な情報を提供するサイトから子供を守る方法として、有害な情報を含んでいると思われるキーワードを含むサイトを検出し、子供が閲覧できないようにするフィルタサービスがすでに一部のプロバイダーによって実用に供されている。しかし、この方法では、キーワードが一致する文字情報をブロックできても、キーワードが一致しない俗語や有害な画像情報をブロックできないという問題があり、また、フィルタの精度が低いために有害でないサイトまでブロックしてしまう場合があるという問題がある。

また、価値観の違いから親により子供にとって有害か無害かの判断が異なり、子供にとって有害なサイトを一律に決められないという問題もある。そのため子供が閲覧を希望するサイトをいちいち親が判定すれば確実であるが、親はいつも子供の傍に居られるわけではないので、この方法に依存することは現実的ではない。

このような問題点の所在に鑑み、下記特許文献１では、プロテクトがかかったサイトに対し、子供が閲覧を希望することをネットワークの管理者（たとえば親）に申請し、ネットワークの管理者が、当該サイトが子供の閲覧に相応しいかどうかを判断し、閲覧を承認するようにしたネットワーク管理者による子供のサイト閲覧希望承認方法が提案されている。
特開２００４−１１０７７４号公報

しかしながら、上記特許文献１で提案されている方法をもってしても、プロテクトがかかったサイトに対する子供の閲覧申請について実の親（管理者）がその閲覧の可否を全て判断しなければならず実の親の負担が非常に大きいという課題があった。

上記のような課題を解決するために本発明は、子供のサイト閲覧承認申請に関して子供のサイト閲覧を管理する管理者（実の親）に過度の負担をかけることなく、子供のサイト閲覧承認/却下を子供のサイト閲覧端末画面に表示する子供のサイト閲覧申請可否判定方法を提供することを目的とする。

上記課題を解決するために本発明は、子供のサイト閲覧可否を管理する管理者が子供のサイト閲覧承認の判定基準を予め設定する過程と、子供がインターネット上のあるサイトを閲覧申請した場合に前記管理者のサイト閲覧承認・却下履歴を参照する過程と、前記管理者の前記サイト閲覧承認・却下履歴に当該サイトが存在すれば前記閲覧申請を自動的に承認する過程と、前記管理者の前記サイト閲覧承認・却下履歴に当該サイトが存在しなければ前記管理者が設定した前記サイト閲覧承認の判定基準に合致する他の子供のサイト閲覧可否を管理する他の管理者グループのサイト閲覧承認・却下履歴を参照する過程と、前記他の管理者グループのサイト閲覧承認・却下履歴の参照の結果、前記管理者が予め設定した承認条件を満たす前記他の管理者グループが承認していれば自動的に承認し、前記管理者が予め設定した却下条件を満たす前記他の管理者グループが却下していれば自動的に却下し、前記管理者が予め設定した承認又は却下の条件をどちらも満たさないときまたは前記他の管理者グループによる閲覧承認・却下履歴に関する情報が得られなかったときのみ前記管理者に閲覧可否判断を依頼し前記管理者による閲覧可否判断を受領する過程と、を含むことを特徴とする。

本発明によれば、管理者(実の親)に過大な負担を負わせることなく、子供(我が子)の閲覧にとって相応しいサイトの閲覧可否判定が可能となるという効果がある。
また、親もしくは該親が信頼できる他の親が実際にサイトを見て子供の閲覧可否を判断することになるので、管理者(親)の責任において有害なサイトを確実にブロックできるという効果がある。

以下、本発明の実施の形態を、図面を参照しながら説明する。
図１は、本発明の実施形態に係る子供のサイト閲覧申請可否判定方法を実現するためのシステムの原理的構成を示すブロック図である。図１において本発明の実施形態に係る子供のサイト閲覧申請可否判定方法を実現するためのシステムは、大きくは、親側の端末１〜３と、子側の端末４〜６と、インターネットなどのネットワーク７と、リンクされた各種サイトのホームページ９の閲覧を可能にするウェブサーバ８と、ウェブサーバ８に接続される管理サーバ１０と、管理サーバ１０に接続されるデータベース２０とから構成される。図１において本実施形態では親Ａ（１）および子Ａ（４）を便宜的に実親および我が子とし、親Ａ（１）の信頼できる他の親を親Ｂ（２）および親Ｃ（３）であるとする。さらに信頼できる他の親Ｂ（２）および親Ｃ（３）に対する子はそれぞれ子Ｂ（５）および子Ｃ（６）であるとする。なお親Ｂ（２）および親Ｃ（３）は、少なくともそれぞれの子Ｂ（５）および子Ｃ（６）におけるサイト閲覧に係る閲覧承認・却下履歴が残され、本システムにおいて自分自身の閲覧承認・却下履歴の利用も含め他の親Ａ（１）に子供のサイト閲覧に係る閲覧承認・却下履歴が利用される可能性を予め了承しているものとする。

管理サーバ１０には、本発明の実施形態に係る子供のサイト閲覧申請可否判定方法を実現するために、親の承認判定基準設定処理部１１と、我が子の閲覧承認・却下履歴チェック処理部１２と、信頼できる他の親との個人属性一致度設定処理部１３と、信頼できる他の親の閲覧承認・却下履歴チェック基準設定処理部１４と、信頼できる他の親の閲覧承認・却下履歴チェック処理部１５と、信頼できる他の親選択処理部１６と、信頼できる他の親によるサイト閲覧承認可否判定処理部１７と、実の親の承認可否判断処理部１８とが設けられている。またデータベース２０には、我が子の閲覧承認・却下履歴ＤＢ（図１１参照）を含む閲覧履歴ＤＢ２１と、子供ＤＢ２２と、親ＤＢ２３と、図１４〜図２２に例示される各種テーブル、すなわち、子供の学年テーブル、子供の学校種別テーブル、子供の性別テーブル、都道府県テーブル、居住地区テーブル、親の年齢層テーブル、親の職業テーブル、親の年収テーブル、親の最終学歴テーブル等が設けられている。

図２は本発明の実施形態に係る子供のサイト閲覧申請可否判定方法における管理者（実親）の承認判定基準設定処理を説明するためのフロー図である。図２においてまず我が子のサイト閲覧を管理する管理者（実親）が予め図１に示した管理サーバ１０内の親の承認判定基準設定処理部１１を起動して承認履歴の有効期限を１ヶ月〜６ヶ月で設定する（ステップ１）。なお図ではステップをＳと略記する。以下の図においても同じである。次いで、管理者（実親）が信頼できる他の親（他の管理者）の閲覧承認・却下履歴チェック基準の設定を行う（ステップ２）。信頼できる他の親（他の管理者）の閲覧承認・却下履歴チェック基準の設定処理は図３で詳しく説明する。そして管理者（実親）が信頼できる他の親（他の管理者）との個人属性一致度の設定を行う（ステップ３）。信頼できる他の親（他の管理者）との個人属性一致度の設定処理は図４で詳しく説明する。以上の設定を行って、管理者（実親）の承認判定基準設定処理を終了する。

図３は、信頼できる他の親（他の管理者）の閲覧承認・却下履歴チェック基準の設定処理を説明するためのフロー図である。図３において管理者（実親）が予め図１に示した管理サーバ１０内の信頼できる他の親の閲覧承認・却下履歴チェック基準設定処理部１４を起動して信頼できる他の親（他の管理者）の最低人数を２〜１００人で設定する（ステップ１１）。次いで、管理者（実親）が信頼できる他の親（他の管理者）による承認判定のための最小許容承認者百分率を５０〜１００％で設定する（ステップ１２）。そして管理者（実親）が信頼できる他の親（他の管理者）による却下判定のための最小許容却下者百分率を５０〜１００％で設定する（ステップ１３）。以上の設定を行って、信頼できる他の親（他の管理者）の閲覧承認・却下履歴チェック基準の設定処理を終了する。

図４は、信頼できる他の親（他の管理者）との個人属性一致度の設定処理を説明するためのフロー図である。図４において管理者（実親）として信頼できる他の親（他の管理者）との個人属性一致度の設定をするために図１に示した管理サーバ１０内の信頼できる他の親との個人属性一致度設定処理部１３は、まず個人属性選択項目ｎ（ただしｎは任意の選択項目を一般化したものである。以下、同じ）を参照する（ステップ２１）。ここで図２４に示される信頼できる他の親判定テーブルを参照するに、個人属性選択項目ｎとして、（１）子供の学年、（２）子供の性別、（３）学校種別、（４）都道府県、（５）居住地区、（６）親の年齢（層）、（７）親の職業、（８）親の年収、（９）最終学歴、などの選択項目が挙げられている。

次いで参照した選択項目ｎを要チェック項目に入れるかを判定する（ステップ２２）。要チェック項目に入れない場合は、ステップ２４に進み、要チェック項目に入れる場合は、ステップ２３に進み、ステップ２３において要チェック項目リストに追加する。そしてステップ２４に進む。

ステップ２４では、他に個人属性選択項目はあるかを判定する。他に個人属性選択項目があれば、ステップ２１に戻り、再度、ステップ２１〜ステップ２４を繰り返す。他に個人属性選択項目がなければ、ステップ２５に進み、ステップ２５において要チェック項目ｎを参照する。

ステップ２６では、ステップ２５で参照した要チェック項目ｎは要完全一致かを判定する。ここで再び図２４を参照する。図２４において上述した個人属性選択項目ｎの上に、完全一致を要する項目として、子供の学年及び子供の性別が挙がっているので、本実施形態に係る管理者（実親）１は（１）子供の学年、（２）子供の性別、を完全一致を要する項目としていることが分る。子供の学年に関しては図１４の子供の学年テーブルに示されるように学年別に学年ＩＤが付与され、学年ＩＤで区別できるようにしている。また子供の性別に関しては図１６の子供の性別テーブルに示されているように子供の性別に性別ＩＤを付与し、性別ＩＤで区別できるようにしている。

ステップ２６において要チェック項目ｎが要完全一致項目であれば、ステップ２７に進み、ステップ２７において要完全一致項目リストに追加する。そしてステップ２８においてパラメーターを設定する。またステップ２６において要チェック項目ｎが要完全一致項目でなければ、ステップ２９に進み、ステップ２９において任意項目リストに追加する。そしてステップ３０においてパラメーターを設定する。ここでまた図２４を参照する。図２４において上述した個人属性選択項目ｎの上に、任意項目として、（３）学校種別、（４）都道府県、（５）居住地区、（６）親の年齢（層）、（７）親の職業、（８）親の年収、（９）最終学歴、が挙げられているので、本実施形態に係る管理者（実親）１はこれらを任意項目としているのが分る。なおパラメーターは、管理者（実親）１が信頼できる他の親（他の管理者）の個人属性一致度に係るファクタとして、例えば、都道府県、居住地区、職業、学歴などの項目中に展開される項目（図１７、図１８、図２０、図２２に示されるテーブルを参照）をＩＤ番号で選択・指示することである。

ステップ２８およびステップ３０におけるパラメーターの設定が済めば、ステップ３１に進む。ス
テップ３１では、他に要チェック項目はあるかを判定する。他に要チェック項目があれば、ステップ２５に戻り、ステップ２５〜ステップ３１を繰り返す。他に要チェック項目がなければ、信頼できる他の親（他の管理者）との個人属性一致度の設定処理を終了する。

図２６は個人属性一致度設定画面の例を示す図である。図２６の画面例において、設定した項目には二重丸を付けることで、設定しない項目（一重丸）と区別している。また図２７は子供（我が子）の学年設定画面を示す図である。設定する場合には、二重丸を付けることで設定しない項目（一重丸）と区別している。

図５Ａおよび図５Ｂは、本発明の実施形態に係る子供のサイト閲覧申請可否判定方法における承認・却下判定処理を説明するためのフロー図である。図５Ａおよび図５Ｂに示す判定処理を、図１の構成および図１１〜図３３の各ＤＢ、各種テーブル、および、各種表示画面を参照しながら説明する。図５Ａおよび図５Ｂにおいて子供（我が子：子供Ａ）４がサイトｎの閲覧を申請する（ステップ４１）。子供４が申請によりサイトを閲覧できるようにするには、図１に示した管理サーバ１０に接続されているデータベース２０内の親Ａ（実親：管理者）１に係る親ＤＢ２３に子供（我が子：子供Ａ）４のＩＤが登録されていることが前提となる。図１３は、図１の管理サーバ１０に接続されている親ＤＢ２３のデータ構造を示す図である。図１３において親ＤＢ２３は、レコードにおける親ＩＤ毎に氏名、都道府県ＩＤ、居住地区ＩＤ、年齢層ＩＤ、職業ＩＤ、年収ＩＤ、最終学歴ＩＤ、メールアドレス、複数の子供ＩＤの項目を備え、各項目にデータが記録されている。すなわちこの子供ＩＤに我が子４のＩＤが記述されている。また図１２は、図１の管理サーバ１０に接続されている子供ＤＢ２２のデータ構造を示す図である。図１２において子供ＤＢ２２は、レコードにおいて親ＩＤの元に展開される複数の子供ＩＤを有し、その子供ＩＤ毎に氏名、学年、性別、学校種別、メールアドレスの項目を備え、各項目にデータが記録されている。

次に、我が子の閲覧承認・却下履歴チェック処理を行う（ステップ４２）。我が子の閲覧承認・却下履歴チェック処理については図６で詳しく説明する。そしてステップ４３では、閲覧申請されたサイトｎが我が子の閲覧承認・却下履歴チェック処理で承認されているかを判定する。承認されていれば、すなわち図６における処理で承認フラグが立っていれば、図５Ｂのステップ５３に跳ぶ。承認されていなければ、ステップ４４に進む。ステップ４４では、閲覧申請されたサイトｎが我が子の閲覧承認・却下履歴チェック処理で却下されているかを判定する。却下されていれば、すなわち図６における処理で却下フラグが立っていれば、図５Ｂのステップ５４に跳ぶ。却下されていなければ、すなわち図６における処理で保留フラグが立っていれば、ステップ４５に進む。ステップ４５では、信頼できる他の親（他の管理者）の閲覧承認・却下履歴チェック処理を行う。信頼できる他の親の閲覧承認・却下履歴チェック処理については図７で詳しく説明する。

そしてステップ４６では閲覧申請されたサイトｎが信頼できる他の親の閲覧承認・却下履歴チェック処理で承認されているか判定する。承認されていれば、図５Ｂのステップ５３に跳ぶ。承認されていなければ、ステップ４７に進む。ステップ４７では、閲覧申請されたサイトｎが信頼できる他の親の閲覧承認・却下履歴チェック処理で却下されているか判定する。却下されていれば、図５Ｂのステップ５４に跳ぶ。却下されていなければ、ステップ４８に進む。ステップ４８では閲覧申請されたサイトｎが保留リストに追加される。次いで、他に見たいサイトはあるかを判定する（ステップ４９）。他に見たいサイトがあればステップ４１に戻り、ステップ４１〜ステップ４９を繰り返す。他に見たいサイトがなければ、図５Ｂのステップ５０に進む。

図２８は、子供（我が子）の閲覧申請画面例を示す図である。この場合、子供４はリンク選択されて表示されたホームページ一覧のタイトルをクリックすることで図１に示すウェブサーバ８にリンクされている各種サイトのホームページ９について閲覧申請することができる。本実施形態の説明では図２８において一例として『ダイエットに役立つページ一覧』が表示され、その中から子供（我が子）４は、『３．食べながら痩せる私のダイエット法』、『２．私は１０日間で１０キロ痩せた！』、『１．スーパーダイエット』のタイトルを順に閲覧申請のためにクリックして行くものとする。

また図２９ないし図３１は、図２８の閲覧申請画面に対する子供（我が子）へのシステムの応答画面例を示すものであり、図２９は図２８でクリックにより閲覧申請選択された『３．食べながら痩せる私のダイエット法』のタイトルに対する閲覧許可画面例であり、図３０は図２８でクリックにより閲覧申請選択された『２．私は１０日間で１０キロ痩せた！』のタイトルに対する閲覧却下画面例であり、図３１は図２８でクリックにより閲覧申請選択された『１．スーパーダイエット』のタイトルに対する親可否判断待ち画面例である。

図５Ｂのステップ５０では、システムが実の親（我が子の管理者）に承認可否判断を依頼する。ステップ５１では、依頼された承認可否判断について実親（管理者）が承認可否判断処理を行う。親（実親）の承認可否判断処理については図１０で詳しく説明する。

ステップ５１における親（実親）の承認可否判断処理において、親（実親）が承認したかを判定する（ステップ５２）。親（実親）が承認していれば、ステップ５３に進み、親（実親）が承認していなければ、ステップ５４に進む。

ステップ５３では、閲覧申請した子供（我が子：子供Ａ）４へ閲覧承認を通知する。またステップ５４では、閲覧申請した子供（我が子：子供Ａ）４へ閲覧却下を通知する。ステップ５５では、ステップ５３における承認通知、および、ステップ５４における却下通知に基づいて承認・却下履歴を記録・更新する。そして承認・却下判定処理を終了する。

図３２は、実の親への承認可否判断依頼画面を示す図である。図３２には３つのサイトについて実の親への承認可否判断依頼がなされ、それぞれに対する判断を二重丸によって示している。また図３３は、子供（我が子）への承認・却下通知画面を示す図である。図３２において実の親が判断した結果が図３２の送信ボタンをクリックすることで子供（我が子）への承認・却下通知をシステムに行わせるようにしている。

図６は、本発明の実施形態に係る我が子の閲覧承認・却下履歴チェック処理を説明するためのフロー図である。図６において図１に示した管理サーバ１０内の我が子の閲覧承認・却下履歴チェック処理部１２は、閲覧履歴ＤＢ２１内の我が子の閲覧承認・却下履歴ＤＢ（図１１参照）を参照する（ステップ６１）。我が子の閲覧承認・却下履歴ＤＢは、図１１に示されるように、レコードにおける子供ＩＤ毎に閲覧申請したことのあるサイトＩＤが展開され、そのサイトＩＤ毎に、サイトアドレス、承認・却下日、判定の各項目を備え、判定の項目において我が子の承認・却下履歴による判定、信頼できる他の親の承認・却下履歴による判定、実の親による判定、最終判定の各判定結果を承認・却下履歴として記録している。例えば図１１においては、３つのサイトの閲覧申請が我が子の閲覧承認・却下履歴として記録されており、そのうち、サイトＩＤ「10001」は我が子の閲覧承認・却下履歴では保留扱いであったが信頼できる他の親の承認・却下履歴による承認を参酌して最終判定で承認という記録が残されており、またサイトＩＤ「25309」は我が子の閲覧承認・却下履歴では保留扱いにされ、さらに信頼できる他の親の承認・却下履歴でも保留扱いにされていたのを実の親による判定で承認され最終判定で承認という記録が残されており、またサイトＩＤ「66543」は我が子の閲覧承認・却下履歴では却下として取り扱われ、信頼できる他の親の承認・却下履歴についてはデータの記録はないが、最終判定で却下という記録が残されている例を示している。

つぎにステップ６２では、当該サイトの承認・却下履歴があるかを判定する。当該サイトの承認・却下履歴がなければステップ６６に進んで、ステップ６６で保留フラグを立てて処理を終了する。また、当該サイトの承認・却下履歴があれば、ステップ６３において承認かを判定する。ここで承認でなければステップ６８に進んで、ステップ６８で却下フラグを立てて処理を終了する。ステップ６３で承認であれば、ステップ６４に進み、ステップ６４において予め設定した有効期限を超過しているかを判定する。因みに有効期限は図２に示した親の承認判定基準設定処理における図２のステップ１で管理者（実親）により１ヶ月〜６ヶ月に設定されているものである。

ステップ６４による判定で予め設定した有効期限を超過していれば、ステップ６５において承認済みリストより当該サイトの承認を削除する。そしてステップ６６に進み、ステップ６６において保留フラグを立てて処理を終了する。一方、ステップ６４による判定で予め設定した有効期限を超過していなければ、ステップ６７において承認フラグを立てて処理を終了する。

図７は、本発明の実施形態に係る信頼できる他の親の閲覧承認・却下履歴チェック処理を説明するためのフロー図である。図７において図１に示した管理サーバ１０内の信頼できる他の親の閲覧承認・却下履歴チェック処理部１５は、まず信頼できる他の親の選択処理を行う（ステップ７１）。信頼できる他の親の選択処理は図８で詳細に説明する。次いで信頼できる他の親ｎの閲覧承認・却下履歴を参照する（ステップ７２）。信頼できる他の親ｎの閲覧承認・却下履歴の中に当該サイトの承認・却下履歴があるかを判定する（ステップ７３）。ステップ７３で当該サイトの承認・却下履歴がなければステップ７６に跳ぶ。またステップ７３で当該サイトの承認・却下履歴があれば、ステップ７４に進み、ステップ７４において承認かを判定する。ステップ７４で承認されていなければ、ステップ７７に進み、ステップ７７において当該サイトの閲覧を却下した信頼できる他の親のリストに追加する処理を行い、ステップ７６に進む。ステップ７４で承認されていればステップ７５に進む。

ステップ７５では、予め設定した有効期限を超過したかを判定する。有効期限は図２に示した親の承認判定基準設定処理における図２のステップ１で管理者（実親）により１ヶ月〜６ヶ月に設定されているものである。そしてステップ７５による判定で予め設定した有効期限を超過していなければ、ステップ７８に進み、ステップ７８において当該サイトの閲覧を承認した信頼できる他の親のリストに追加する処理を行い、ステップ７６に進む。ステップ７５による判定で予め設定した有効期限を超過していれば、ステップ７６に進む。

ステップ７６では、他に信頼できる他の親はいるかを判定する。他に信頼できる他の親がいれば、ステップ７２に戻り、ステップ７２〜ステップ７８を繰り返す。一方、他に信頼できる他の親がいなければ、ステップ７９に進み、ステップ７９において信頼できる他の親による当該サイト閲覧承認可否判定処理を行う。信頼できる他の親による当該サイト閲覧承認可否判定処理が済めば、信頼できる他の親の閲覧承認・却下履歴チェック処理を終了する。なお、信頼できる他の親による当該サイト閲覧承認可否判定処理は図９で詳細に説明する。

図８は、本発明の実施形態に係る信頼できる他の親の選択処理を説明するためのフロー図である。図８において図１に示した管理サーバ１０内の信頼できる他の親の選択処理部１６は、システムに登録済みの他の親ｎを参照する（ステップ８１）。システムに登録済みの他の親とは、図１３に示された親ＤＢ（図１の親ＤＢ２３参照）に登録されている親ＩＤを有する実親以外の者である。親ＤＢは、レコードにおける親ＩＤ毎に氏名、都道府県ＩＤ、居住地区ＩＤ、年齢層ＩＤ、職業ＩＤ、年収ＩＤ、最終学歴ＩＤ、メールアドレス、複数の子供ＩＤについての項目を有し、各項目にデータが記録されている。なお、図１３では他の親は、実際には多数存在するのであるが、具体例としては１名だけしか例示していない。

ステップ８２では、参照した他の親ｎの個人属性項目と実親（管理者）の個人属性項目とにおいて設定した完全一致項目が合致するかを判定する。合致しなければ、ステップ８６に跳ぶ。一方、合致すればステップ８３に進み、ステップ８３において個人属性一致度が設定以上かを判定する。個人属性一致度が設定以上でなければステップ８６に跳び、個人属性一致度が設定以上であればステップ８４に進む。

ここで個人属性一致度について説明を補足する。個人属性の一致度を判定する前提として、ポイントについて説明する。本実施形態に係るポイントとは、信頼できる他の親の個人属性項目と親（実親）の個人属性項目とが一致すれば１ポイントとして加点し、一致しなければ加点しないようにして、ポイントの合計が所定値を超えるか否かを基準にして親（実親）が信頼できる他の親であるか否かを判定するものである。参考までに図２３は、信頼できる他の親の個人属性一致度判定基準となるポイントの付け方を示す表である。図２３では、子供の学年、子供の性別、子供の学校種別、都道府県、居住地区、親の職業、親の年齢層、親の年収、親の最終学歴、などの個人属性項目のそれぞれにおいて一致していれば、１ポイントを加点し、一致していなければポイントを加点しない、というポイントの加点法を用いている。

図１４〜図２２には、各種テーブルすなわち、子供の学年テーブル（図１４）、子供の学校種別テーブル（図１５）、子供の性別テーブル（図１６）、都道府県テーブル（図１７）、居住地区テーブル（図１８）、親の年齢層テーブル（図１９）、親の職業テーブル（図２０）、親の年収テーブル（図２１）、親の最終学歴テーブル（図２２）が示されている。

個人属性一致度の設定は、信頼できる他の親であるか否かを判定するために親（実親）は個人属性項目で完全一致することを要する項目で完全一致することを前提に、任意の項目におけるポイント合計数を所定値（ここでは、３）以上とし、任意項目における合計ポイント数が所定値以上であれば信頼できる他の親であると判定している。図２４に示す例では、他の親ＩＤが「3571」の信頼できる他の親候補は、任意項目では親の年齢（層）、最終学歴の項目におけるポイント加点があるけれどもそれ以外にはポイント加点が無いため任意項目における合計ポイント数は２で、合計ポイント数３に満たないため信頼できる他の親であるとは判定されていない。

図８の説明に戻って、ステップ８４では、サイト閲覧承認履歴一致度が設定以上かを判定する。サイト閲覧承認履歴一致度が設定以上でなければステップ８６に進み、サイト閲覧承認履歴一致度が設定以上であればステップ８５に進む。サイト閲覧承認履歴一致度の設定は、例えば、実の親１により一致度９０％以上を目安に予め設定しておくものとする。サイト閲覧承認履歴一致度は本来完全一致が望ましいが、そうすると信頼できる他の親の母数を確保できなくなる恐れがあるのを考慮して適当な百分率、例えば一致度９０％、でもって設定する。ステップ８５では、信頼できる他の親リストに追加する処理を行い、ステップ８６に進む。ステップ８６では、他に登録済みの他の親はいるかを判定する。登録済みの他の親がいれば、ステップ８１に戻り、ステップ８１〜ステップ８６を繰り返す。登録済みの他の親がいなければ、信頼できる他の親選択処理を終了する。

図９は、本発明の実施形態に係る信頼できる他の親による当該サイト閲覧承認可否判定処理を説明するためのフロー図である。図９において図１に示した管理サーバ１０内の信頼できる他の親によるサイト閲覧承認可否判定処理部１７は、まず当該サイトの閲覧承認・却下履歴のある信頼できる他の親リストを参照する（ステップ９１）。次いでステップ９２では、承認・却下履歴のある信頼できる他の親の数は設定以上かを判定する。信頼できる他の親の数が設定以上でなければ、ステップ９７に進み、ステップ９７において保留フラグを立てて処理を終了する。一方、信頼できる他の親の数が設定以上であれば、ステップ９３に進む。

ステップ９３では、承認した親は設定した百分率以上かを判定する。ここで承認に係る設定した百分率とは、図３に示した信頼できる他の親（他の管理者）の閲覧承認・却下履歴チェック基準の設定処理における図３のステップ１２で設定した承認判定のための最小許容百分率のことである。設定した百分率以上であれば、ステップ９４に進み、ステップ９４において承認フラグを立てて、処理を終了する。一方、設定した百分率以上でなければ、ステップ９５に進み、ステップ９５において、却下した親は設定した百分率以上かを判定する。ここで却下に係る設定した百分率とは、図３に示した信頼できる他の親（他の管理者）の閲覧承認・却下履歴チェック基準の設定処理における図３のステップ１３で設定した却下判定のための最小許容百分率のことである。そして、設定した百分率以上であれば、ステップ９６に進み、ステップ９６において却下フラグを立てて、処理を終了する。一方、設定した百分率以上でなければ、ステップ９７に進み、ステップ９７において保留フラグを立てて、処理を終了する。

図２５は信頼できる他の親グループによるサイト閲覧承認可否判定処理結果を示す表であり、閲覧申請のあったサイトＩＤについて、信頼できる他の親グループ（図２５の例では１０人）が下した承認・却下の判定に基づいてそれぞれ百分率を求め、図３のステップ１２、ステップ１３で予め設定した所定の百分率（これを例えば７０％とする）を超えているかを判定し、却下について求めた百分率（図２５の例では２０％）は７０％に満たないが、承認について求めた百分率（図２５の例では８０％）が７０％を超えていることで信頼できる他の親グループによるサイト閲覧承認可否判定処理で『承認』判定したことを表している。なお、図２５の承認、却下の欄における‘１’はフラグを示し、図２５の合計欄はフラグの総数を示している。

図１０は、本発明の実施形態に係る親（実親）の承認可否判断処理を説明するためのフロー図である。図１０においてシステム（図１に示した管理サーバ１０内の実の親の承認可否判断処理部１８）から親１に承認可否判断を依頼する（ステップ１０１）（図３２参照）。依頼された親１は、承認可否判断依頼リスト、すなわち保留リスト、にあるサイトｎを参照する（ステップ１０２）。ステップ１０３では、承認可否判断する親１が実際にサイトｎを見て子供が閲覧するのを承認かを判定する。承認であればステップ１０４に進み、ステップ１０４において承認フラグを立てる。そしてステップ１０６に進む。一方、承認でなければステップ１０５に進み、ステップ１０５において却下フラグを立てる。そしてステップ１０６に進む。ステップ１０６においては、他に承認可否判断待ち（サイト）があるかを判定する。他に承認可否判断待ち（サイト）があれば、ステップ１０２に戻り、ステップ１０２〜ステップ１０６を繰り返す。一方、他に承認可否判断待ち（サイト）がなければ、親（実親）の承認可否判断処理を終了する。上記において「承認フラグ」、「却下フラグ」を立てるということは、図３２における依頼画面で親１が承認又は却下の判断をしてそのどちらかに二重丸を付し送信ボタンを押すことで、システムすなわち図１に示した管理サーバ１０内の実の親の承認可否判断処理部１８でフラグ処理されるものである。
以上説明したことを概観すれば本発明は以下のような構成を備えるものである。

（付記１）子供のサイト閲覧可否を管理する管理者が子供のサイト閲覧承認の判定基準を予め設定する過程と、子供がインターネット上のあるサイトを閲覧申請した場合に前記管理者のサイト閲覧承認・却下履歴を参照する過程と、前記管理者の前記サイト閲覧承認・却下履歴に当該サイトが存在すれば前記閲覧申請を自動的に承認する過程と、前記管理者の前記サイト閲覧承認・却下履歴に当該サイトが存在しなければ前記管理者が設定した前記サイト閲覧承認の判定基準に合致する他の子供のサイト閲覧可否を管理する他の管理者グループのサイト閲覧承認・却下履歴を参照する過程と、前記他の管理者グループのサイト閲覧承認・却下履歴の参照の結果、前記管理者が予め設定した承認条件を満たす前記他の管理者グループが承認していれば自動的に承認し、前記管理者が予め設定した却下条件を満たす前記他の管理者グループが却下していれば自動的に却下し、前記管理者が予め設定した承認又は却下の条件をどちらも満たさないときまたは前記他の管理者グループによる閲覧承認・却下履歴に関する情報が得られなかったときのみ前記管理者に閲覧可否判断を依頼し前記管理者による閲覧可否判断を受領する過程と、を含むことを特徴とする子供のサイト閲覧申請可否判定方法。

（付記２）前記管理者が予め設定する前記サイト閲覧承認の判定基準は、判定に必要な、過去の承認・却下履歴の有効期限、前記他の管理者による承認又は却下の総数、および、前記他の管理者との個人属性一致度、について設定するものであることを特徴とする付記１に記載の子供のサイト閲覧申請可否判定方法。

（付記３）前記他の管理者グループは、前記管理者が設定した個人属性一致度の選択項目の中から指定した完全一致項目で一致することを前提に他の任意の選択項目について一致する合計数が所定以上であるという条件をクリアした他の管理者から選ばれるものであることを特徴とする付記１に記載の子供のサイト閲覧申請可否判定方法。

（付記４）前記管理者が予め設定した承認又は却下の条件をどちらも満たさないときまたは前記他の管理者グループによる閲覧承認・却下履歴に関する情報が得られなかったとき若しくは有効期限を超過しているときは、保留リストに入れて前記管理者に閲覧可否判断を依頼する過程を含むことを特徴とする付記１に記載の子供のサイト閲覧申請可否判定方法。

（付記５）前記管理者が予め設定した却下条件を満たす前記他の管理者グループが却下していても、すぐには却下とせず、前記保留リストに入れることを特徴とする付記４に記載の子供のサイト閲覧申請可否判定方法。

本発明の実施形態に係る子供のサイト閲覧申請可否判定方法を実現するためのシステムの原理的構成を示すブロック図である。 本発明の実施形態に係る子供のサイト閲覧申請可否判定方法における管理者（実親）の承認判定基準設定処理を説明するためのフロー図である。 信頼できる他の親（他の管理者）の閲覧承認・却下履歴チェック基準の設定処理を説明するためのフロー図である。 信頼できる他の親（他の管理者）との個人属性一致度の設定処理を説明するためのフロー図である。 本発明の実施形態に係る子供のサイト閲覧申請可否判定方法における承認・却下判定処理を説明するためのフロー図である。 本発明の実施形態に係る子供のサイト閲覧申請可否判定方法における承認・却下判定処理を説明するためのフロー図である。 本発明の実施形態に係る我が子の閲覧承認・却下履歴チェック処理を説明するためのフロー図である。 本発明の実施形態に係る信頼できる他の親の閲覧承認・却下履歴チェック処理を説明するためのフロー図である。 本発明の実施形態に係る信頼できる他の親の選択処理を説明するためのフロー図である。 本発明の実施形態に係る信頼できる他の親による当該サイト閲覧承認可否判定処理を説明するためのフロー図である。 本発明の実施形態に係る親（実親）の承認可否判断処理を説明するためのフロー図である。 本発明の実施形態に係る我が子の閲覧承認・却下履歴ＤＢのデータ構造を示す図である。 本発明の実施形態に係る子供ＤＢのデータ構造を示す図である。 本発明の実施形態に係る親ＤＢのデータ構造を示す図である。 本発明の実施形態に係る子供の学年テーブルを示す図である。 本発明の実施形態に係る子供の学校種別テーブルを示す図である。 本発明の実施形態に係る子供の性別テーブルを示す図である。 本発明の実施形態に係る都道府県テーブルを示す図である。 本発明の実施形態に係る居住地区テーブルを示す図である。 本発明の実施形態に係る親の年齢層テーブルを示す図である。 本発明の実施形態に係る親の職業テーブルを示す図である。 本発明の実施形態に係る親の年収テーブルを示す図である。 本発明の実施形態に係る親の最終学歴テーブルを示す図である。 本発明の実施形態に係る信頼できる他の親の個人属性一致度判定基準となるポイントの付け方を示す表である。 本発明の実施形態に係る信頼できる他の親判定テーブルを示す図である。 本発明の実施形態に係る信頼できる他の親グループによるサイト閲覧承認可否判定処理結果を示す表である。 本発明の実施形態に係る個人属性一致度設定画面の例を示す図である。 本発明の実施形態に係る子供（我が子）の学年設定画面を示す図である。 本発明の実施形態に係る子供（我が子）の閲覧申請画面例を示す図である。 本発明の実施形態に係る閲覧許可画面例を示す図である。 本発明の実施形態に係る閲覧却下画面例を示す図である。 本発明の実施形態に係る親可否判断待ち画面例を示す図である。 本発明の実施形態に係る実の親への承認可否判断依頼画面を示す図である。 本発明の実施形態に係る子供（我が子）への承認・却下通知画面を示す図である。

符号の説明

１ 親Ａ(実親：管理者)
２ 親Ｂ(信頼できる他の親：他の管理者)
３ 親Ｃ(信頼できる他の親：他の管理者)
４ 子Ａ(我が子)
５ 子Ｂ(信頼できる他の親Ｂの子)
６ 子Ｃ(信頼できる他の親Ｃの子)
７ ネットワーク
８ ウェブ(Web)サーバ
９ 各種サイトのホームページ
１０ 管理サーバ
１１ 親の承認判定基準設定処理部
１２ 我が子の閲覧承認・却下履歴チェック処理部
１３ 信頼できる他の親との個人属性一致度設定処理部
１４ 信頼できる他の親の閲覧承認・却下履歴チェック基準設定処理部
１５ 信頼できる他の親の承認・却下履歴チェック処理部
１６ 信頼できる他の親選択処理部
１７ 信頼できる他の親によるサイト閲覧承認可否判定処理部
１８ 実の親の承認可否判断処理部
２０ データベース
２１ 閲覧承認ＤＢ
２２ 子供ＤＢ
２３ 親ＤＢ

Claims (3)

1. 子供のサイト閲覧可否を管理する管理者が子供のサイト閲覧承認の判定基準を予め設定する過程と、
   子供がインターネット上のあるサイトを閲覧申請した場合に前記管理者のサイト閲覧承認・却下履歴を参照する過程と、
   前記管理者の前記サイト閲覧承認・却下履歴に当該サイトが存在すれば前記閲覧申請を自動的に承認する過程と、
   前記管理者の前記サイト閲覧承認・却下履歴に当該サイトが存在しなければ前記管理者が設定した前記サイト閲覧承認の判定基準に合致する他の子供のサイト閲覧可否を管理する他の管理者グループのサイト閲覧承認・却下履歴を参照する過程と、
   前記他の管理者グループのサイト閲覧承認・却下履歴の参照の結果、前記管理者が予め設定した承認条件を満たす前記他の管理者グループが承認していれば自動的に承認し、前記管理者が予め設定した却下条件を満たす前記他の管理者グループが却下していれば自動的に却下し、前記管理者が予め設定した承認又は却下の条件をどちらも満たさないときまたは前記他の管理者グループによる閲覧承認・却下履歴に関する情報が得られなかったときのみ前記管理者に閲覧可否判断を依頼し前記管理者による閲覧可否判断を受領する過程と、
   を含むことを特徴とする子供のサイト閲覧申請可否判定方法。
2. 前記管理者が予め設定する前記サイト閲覧承認の判定基準は、判定に必要な、過去の承認・却下履歴の有効期限、前記他の管理者による承認又は却下の総数、および、前記他の管理者との個人属性一致度、について設定するものであることを特徴とする請求項１に記載の子供のサイト閲覧申請可否判定方法。
3. 前記他の管理者グループは、前記管理者が設定した個人属性一致度の選択項目の中から指定した完全一致項目で一致することを前提に他の任意の選択項目について一致する合計数が所定以上であるという条件をクリアした他の管理者から選ばれるものであることを特徴とする請求項１に記載の子供のサイト閲覧申請可否判定方法。