インターネットアクセス要求システム
【課題】
従来、そのほとんどを人手に頼っていた、従業員から申請されるｗｅｂページ対する閲覧・利用申請について、真に業務上必要なｗｅｂページかの判断および閲覧・利用許可について、人手をできるだけなくし、自動的に行うことを課題とする。
【解決手段】
申請者の所属などの属性に応じて、要求されたｗｅｂページが新規事例かを判断し、新規事例の場合には許容しないと判断し、新規事例でない場合には予め定めた分類のいずれに該当するかを判断し、その結果に応じて自動的な判断が可能かを判定する。
従来、そのほとんどを人手に頼っていた、従業員から申請されるｗｅｂページ対する閲覧・利用申請について、真に業務上必要なｗｅｂページかの判断および閲覧・利用許可について、人手をできるだけなくし、自動的に行うことを課題とする。
【解決手段】
申請者の所属などの属性に応じて、要求されたｗｅｂページが新規事例かを判断し、新規事例の場合には許容しないと判断し、新規事例でない場合には予め定めた分類のいずれに該当するかを判断し、その結果に応じて自動的な判断が可能かを判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、いわゆるｗｅｂページ(サイト)へのアクセスを制御するための技術に関する。その中でも特に、所定のｗｅｂページへのアクセス許可を得るためのアクセス申請を効率的に行うための技術に関する。
【背景技術】
【０００２】
現在、企業などでは、業務に関係しないＷｅｂページへのアクセスを制限していることが多い(業務に関係するｗｅｂページのみアクセスを許容している)。ここで、業務によってアクセス(閲覧を含む)が必要なｗｅｂページが変わってくることが多いので、従業員等によってアクセス可能なページを制限することがなされている。
【０００３】
例えば特許文献１においては、従来技術として「特定の有害キーワードを含んでいるかを検索して、もし有害キーワードを含んでいれば、その情報の表示を禁止し、かつその情報の発信元のＵＲＬを記録しておいて、以後のアクセスを制御する」ことが記載されている。また、「有害語キーワードが存在すればそのメッセージをインターネット等の電子掲示板システムに掲載することを拒否する」ことが開示されている。
【０００４】
【特許文献１】特開２００１−２８２７９７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、従業員によりアクセス可能なｗｅｂページを変えている場合、特定の有害キーワードだけでアクセス可能かを判断することはできない。つまり、効率的に、従業員、業務もしくは組織毎にいずれのｗｅｂページにアクセスを許容するか（もしくは制限するか）を判断することは困難であった。
【課題を解決するための手段】
【０００６】
そこで、本発明では、禁止されているｗｅｂページへのアクセス要求について、以下のようにして許容するか否かを判断する。すなわち、要求者の属性に応じて、要求されたｗｅｂページが新規事例かを判断し、新規事例の場合には許容しないと判断し、新規事例でない場合には予め定めた分類のいずれに該当するかを判断し、その結果に応じて自動的な判断が可能かを判定する。
【０００７】
ここで、要求されたｗｅｂページはＵＲＬで特定され、このＵＲＬから所定順序で部分ＵＲＬを抽出し、これが含まれる過去事例であるＵＲＬが存在するか、上記の所定順序で比較することで、上記の新規事例かを判断することも本発明に含まれる。
【発明の効果】
【０００８】
本発明よれば、効率的に、従業員、業務もしくは組織毎にいずれのｗｅｂページにアクセスを許容するかを判断可能になる。
【発明を実施するための最良の形態】
【０００９】
本発明の実施の形態について、以下図面を用いて説明する。
図１は、本発明を適用したWeb閲覧申請処理システムの実施形態のブロック図を示したものである。図１において、100および110は申請者Ａ、管理者Ｂが使用する端末機であり通信回線によりイントラネットに接続されている。また、200はAPサーバであり、自動申請可否決定機構と自動申請レベル決定機構を有する。また、300はDBサーバであり、過去の申請事例をURLごとに蓄積したURL一覧テーブル、過去のすべての申請事例をすべて蓄積した申請情報一覧テーブル、自動申請可否を決定するレベル（以下、申請レベル）を判定するための情報を蓄積した申請レベル判定情報URLマッチング結果テーブルを有する（各テーブルの詳細については図2参照）。
【００１０】
以下、本実施の形態の処理内容について、説明する。
本Web閲覧申請処理システムによる自動申請処理を図3-1〜3-5のフローチャートに従って説明する。図3-1〜3-5は申請者Aがアクセス禁止サイトを閲覧したいとき、入力された閲覧申請に必要なデータを入力し、入力されたデータをもとにAPサーバが自動申請処理可能かどうか判断する場合を示したものである。それぞれ図3-1 はWeb閲覧申請データの登録、図3-2 は過去事例の検索、図3-3 は申請レベル（１）〜（３）における自動申請可否の決定（図5参照、申請レベルの判定については後述）、図3-4 は申請レベル（４）〜（７）における自動申請可否の決定、図3-5 は自動申請可否決定後の処理を表している。
【００１１】
まず、ステップ2101において、申請者Aがアクセス禁止サイトを閲覧したい場合、APサーバ200はアクセスをブロックする。ステップ2103において、申請者端末１００は、閲覧申請に必要なデータ（申請者氏名、URL、部門、所属部署、利用目的等）の入力を受付けし閲覧申請を行う。ここで、申請者端末１００は、ＡＰサーバ２００に対して、入力された情報を送信することで上記の閲覧申請処理を実行する。
ステップ21024において、APサーバ２００は、入力送信されたデータ（すなわち申請データ）を申請情報一覧テーブル320に登録した後、この申請データとURL一覧テーブル３１０のデータを照合し、以下の手順で自動申請処理可能かどうか判断する。
【００１２】
まずAPサーバ200は、まずステップ2106において、申請データのドメインをキーにURL一覧テーブル310から過去事例を検索する。次にステップ2108において、過去事例が存在しないとき、自動申請処理不可と決定する。
【００１３】
過去事例が存在するとき、ステップ2110において、申請されたデータのURLと過去事例のURLすなわちURL一覧テーブル310に格納されているURLのセカンドレベルドメイン以降からのマッチングを行う。一致するドメインが存在しない場合、自動申請処理不可とする。一方、一致するドメインが存在する場合、URLのパス名のマッチングを前方からスラッシュ区切りで行っていく。URLのパス名をディレクトリの階層構造で考えたとき、申請データのされたURL（以下、申請URL）が過去事例のURL（以下、過去事例URL）における子ディレクトリとなる場合、過去事例のURLが申請されたURLを包含するといい、申請されたURLが過去事例のURLにおける親ディレクトリとなる場合、申請されたURLが過去事例のURLを包含するということとする（図6参照）。
【００１４】
ステップ2111において、マッチング結果をURLマッチング結果テーブル330に登録する。マッチングによって、申請されたURLを包含する過去事例URL、または申請URLと一致する過去事例のURL、またはパス名がすべて一致する過去事例のURLを探し、見つかった場合その過去事例（複数可）を記録する。が見つからなかった場合、申請されたURLに包含される過去事例のURLをマッチングによって探し、見つかった場合その過去事例（複数可）を記録し、自動申請処理不可とする。見つかった場合、ステップ2115において、該当した過去事例の申請レベルを調べ、申請レベルによる自動申請可否の決定を行う。申請レベルとは、システムの管理者が予め判定した自動申請処理の可否を判断するためのレベルである。また、マッチングによって、包含関係のある過去事例のURLが見つからなかった場合も、自動申請処理不可とする。
【００１５】
自動申請可否の決定においては、次に、該当した過去事例を申請レベルの数値の低いものから順に照合する。申請レベルとは、システムの管理者が予め判定した自動申請処理の可否を判断するためのレベルである（図5参照、申請レベルの判定については後述）レベルが（１）であれば、ステップ2118において、無条件で自動申請処理可とする。レベルが（２）であれば、ステップ2116において、申請データのされた利用目的と過去事例の利用目的のマッチングを行い、一致した場合自動申請処理可とし、一致しなかった場合自動申請処理不可とする。レベルが（３）であれば、ステップ2117において、申請データのされた部門と過去事例の部門のマッチングを行い、一致した場合自動申請処理可とし、一致しなかった場合自動申請処理不可とする。レベルが（４）であれば、ステップ2122において、利用目的のマッチング、ステップ2123において、と部門のマッチングを行う。
【００１６】
この結果、一致した場合自動申請処理可とし、一致しなかった場合自動申請処理不可とする。レベルが（５）であれば、ステップ2124において、申請された部署と過去事例の部署のマッチングを行い、一致した場合自動申請処理可とし、一致しなかった場合自動申請処理不可とする。前方からスラッシュ区切りで行う。部署もURLと同様に木構造で考え、マッチングによって、申請された部署名を包含する過去事例の部署名、または部署名がすべて一致する過去事例を探し、見つかった場合自動申請処理可とする。見つからなかった場合、自動申請処理不可とする。レベルが（６）であれば、ステップ2120において、利用目的のマッチング、ステップ2121において、と部署のマッチングを行い、一致した場合自動申請処理可とし、一致しなかった場合自動申請処理不可とする。レベルが（７）であれば、ステップ2129において、無条件で自動申請処理不可とする。
【００１７】
利用目的が一致しかつ申請された部署名を包含するもしくは申請された部署名とすべて一致する過去事例の部署名が存在する場合場合自動申請処理可とし、それ以外の場合自動申請処理不可とする。この操作を該当した過去事例分繰り返し、自動申請処理が可となった時点で終了する。
【００１８】
自動申請処理の可否を決定後、ステップ2130において、結果を申請情報一覧テーブル320に登録する。
【００１９】
次に、本Web閲覧申請処理システムによる申請レベルの判定を図4-1〜4-2のフローチャートに従って説明する。図4-1〜4-2は管理者Ｂ端末110が自動申請処理不可となった申請に対して、入力された申請データとURLのパス名のマッチングによって記録した過去事例のデータをもとに判定した申請レベルに対し、判定したい時、APサーバが選択可能な申請レベルを管理者ＢにAPサーバ200が、申請レベルが適切であるかを判断する提示する場合を示したものである。
【００２０】
管理者Ｂ端末110は申請レベルを判定したい場合、ステップ2201において、申請レベル未定のURLを要求する。APサーバ200はステップ2202において、自動申請処理不可となった申請データを申請に対して、申請情報一覧テーブル320から検索する。管理者Ｂ端末110はステップ2205において、一覧から対象URLをひとつ選択し要求し、申請データAPサーバ200はステップ2206において、URLマッチング結果テーブル330から過去事例を検索する。とURL一覧テーブルからURLのパス名が最も一致する過去事例のデータを検索し、管理者Ｂ端末110はステップ2209において、それらの情報をもとに申請レベルを判定する。そのとき、APサーバ200は、以下の手順で管理者Ｂ端末110が判定したレベルが適切であるかに選択可能な申請レベルを提示判断する。
【００２１】
過去事例のURLが申請されたURLを包含する場合、ステップ2211において、過去事例の申請レベル以下のレベルが判定されているとき適切と判断し、それ以外の場合不適切と判断する。を申請データに対して選択可能にする。次に、申請されたURLと過去事例のURLがすべて一致する場合、ステップ2213において、閲覧可と不可が混在するならば、申請レベル（３）以上のレベルが判定されているとき適切と判断し、それ以外の場合不適切と判断する。を選択可能にし、そうでなければ任意の申請レベルを選択可能にする。申請されたURLが過去事例のURLを包含する場合、ステップ2212において、申請データに対して過去事例の申請レベル以上のレベルが判定されているとき適切と判断し、それ以外の場合不適切と判断する。を選択可能にする。申請されたURLと過去事例のURLとの間に包含関係が存在しないそれ以外の場合、ステップ2211において、任意の申請レベルが判定されているとき適切と判断し、それ以外の場合不適切と判断を選択可能にする。不適切と判断した場合、申請レベルの再判定を管理者Ｂ端末110に行わせる。適切と判断した場合、ステップ2214において、APサーバ200は申請レベルをURL一覧テーブル310に登録する。
【００２２】
管理者Ｂからの選択可能な申請レベルから適切なレベルの選択を受付け、その受付けられた内容に応じて、申請データをURL一覧テーブルに登録する。
【００２３】
以上、本発明の実施の形態を説明したが、図1において、自動申請の可否を決定する判断材料として、部門・部署・利用目的以外に申請者の職位などを加味することも可能である。
【図面の簡単な説明】
【００２４】
【図１】本発明の一実施形態におけるweb閲覧申請処理システムのブロック図。
【図２】本発明の一実施形態で用いる各種データテーブルを示す図。
【図３−１】Web閲覧申請処理システムによる自動申請処理のフローチャート（その１）。
【図３−２】Web閲覧申請処理システムによる自動申請処理のフローチャート（その２）。
【図３−３】Web閲覧申請処理システムによる自動申請処理のフローチャート（その３）。
【図３−４】Web閲覧申請処理システムによる自動申請処理のフローチャート（その４）。
【図３−５】Web閲覧申請処理システムによる自動申請処理のフローチャート（その５）。
【図４−１】Web閲覧申請処理システムによる申請レベルの判定処理のフローチャート（その１）。
【図４−２】Web閲覧申請処理システムによる申請レベルの判定処理のフローチャート（その２）。
【図５】自動申請可否の決定に用いる基準テーブルを示す図。
【図６】申請されたURLが過去事例のURLを包含するかを示す図。
【符号の説明】
【００２５】
１００…申請者Ａ端末、１１０…管理者Ｂ端末、２００…ＡＰサーバ、３００…ＤＢサーバ
【技術分野】
【０００１】
本発明は、いわゆるｗｅｂページ(サイト)へのアクセスを制御するための技術に関する。その中でも特に、所定のｗｅｂページへのアクセス許可を得るためのアクセス申請を効率的に行うための技術に関する。
【背景技術】
【０００２】
現在、企業などでは、業務に関係しないＷｅｂページへのアクセスを制限していることが多い(業務に関係するｗｅｂページのみアクセスを許容している)。ここで、業務によってアクセス(閲覧を含む)が必要なｗｅｂページが変わってくることが多いので、従業員等によってアクセス可能なページを制限することがなされている。
【０００３】
例えば特許文献１においては、従来技術として「特定の有害キーワードを含んでいるかを検索して、もし有害キーワードを含んでいれば、その情報の表示を禁止し、かつその情報の発信元のＵＲＬを記録しておいて、以後のアクセスを制御する」ことが記載されている。また、「有害語キーワードが存在すればそのメッセージをインターネット等の電子掲示板システムに掲載することを拒否する」ことが開示されている。
【０００４】
【特許文献１】特開２００１−２８２７９７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、従業員によりアクセス可能なｗｅｂページを変えている場合、特定の有害キーワードだけでアクセス可能かを判断することはできない。つまり、効率的に、従業員、業務もしくは組織毎にいずれのｗｅｂページにアクセスを許容するか（もしくは制限するか）を判断することは困難であった。
【課題を解決するための手段】
【０００６】
そこで、本発明では、禁止されているｗｅｂページへのアクセス要求について、以下のようにして許容するか否かを判断する。すなわち、要求者の属性に応じて、要求されたｗｅｂページが新規事例かを判断し、新規事例の場合には許容しないと判断し、新規事例でない場合には予め定めた分類のいずれに該当するかを判断し、その結果に応じて自動的な判断が可能かを判定する。
【０００７】
ここで、要求されたｗｅｂページはＵＲＬで特定され、このＵＲＬから所定順序で部分ＵＲＬを抽出し、これが含まれる過去事例であるＵＲＬが存在するか、上記の所定順序で比較することで、上記の新規事例かを判断することも本発明に含まれる。
【発明の効果】
【０００８】
本発明よれば、効率的に、従業員、業務もしくは組織毎にいずれのｗｅｂページにアクセスを許容するかを判断可能になる。
【発明を実施するための最良の形態】
【０００９】
本発明の実施の形態について、以下図面を用いて説明する。
図１は、本発明を適用したWeb閲覧申請処理システムの実施形態のブロック図を示したものである。図１において、100および110は申請者Ａ、管理者Ｂが使用する端末機であり通信回線によりイントラネットに接続されている。また、200はAPサーバであり、自動申請可否決定機構と自動申請レベル決定機構を有する。また、300はDBサーバであり、過去の申請事例をURLごとに蓄積したURL一覧テーブル、過去のすべての申請事例をすべて蓄積した申請情報一覧テーブル、自動申請可否を決定するレベル（以下、申請レベル）を判定するための情報を蓄積した申請レベル判定情報URLマッチング結果テーブルを有する（各テーブルの詳細については図2参照）。
【００１０】
以下、本実施の形態の処理内容について、説明する。
本Web閲覧申請処理システムによる自動申請処理を図3-1〜3-5のフローチャートに従って説明する。図3-1〜3-5は申請者Aがアクセス禁止サイトを閲覧したいとき、入力された閲覧申請に必要なデータを入力し、入力されたデータをもとにAPサーバが自動申請処理可能かどうか判断する場合を示したものである。それぞれ図3-1 はWeb閲覧申請データの登録、図3-2 は過去事例の検索、図3-3 は申請レベル（１）〜（３）における自動申請可否の決定（図5参照、申請レベルの判定については後述）、図3-4 は申請レベル（４）〜（７）における自動申請可否の決定、図3-5 は自動申請可否決定後の処理を表している。
【００１１】
まず、ステップ2101において、申請者Aがアクセス禁止サイトを閲覧したい場合、APサーバ200はアクセスをブロックする。ステップ2103において、申請者端末１００は、閲覧申請に必要なデータ（申請者氏名、URL、部門、所属部署、利用目的等）の入力を受付けし閲覧申請を行う。ここで、申請者端末１００は、ＡＰサーバ２００に対して、入力された情報を送信することで上記の閲覧申請処理を実行する。
ステップ21024において、APサーバ２００は、入力送信されたデータ（すなわち申請データ）を申請情報一覧テーブル320に登録した後、この申請データとURL一覧テーブル３１０のデータを照合し、以下の手順で自動申請処理可能かどうか判断する。
【００１２】
まずAPサーバ200は、まずステップ2106において、申請データのドメインをキーにURL一覧テーブル310から過去事例を検索する。次にステップ2108において、過去事例が存在しないとき、自動申請処理不可と決定する。
【００１３】
過去事例が存在するとき、ステップ2110において、申請されたデータのURLと過去事例のURLすなわちURL一覧テーブル310に格納されているURLのセカンドレベルドメイン以降からのマッチングを行う。一致するドメインが存在しない場合、自動申請処理不可とする。一方、一致するドメインが存在する場合、URLのパス名のマッチングを前方からスラッシュ区切りで行っていく。URLのパス名をディレクトリの階層構造で考えたとき、申請データのされたURL（以下、申請URL）が過去事例のURL（以下、過去事例URL）における子ディレクトリとなる場合、過去事例のURLが申請されたURLを包含するといい、申請されたURLが過去事例のURLにおける親ディレクトリとなる場合、申請されたURLが過去事例のURLを包含するということとする（図6参照）。
【００１４】
ステップ2111において、マッチング結果をURLマッチング結果テーブル330に登録する。マッチングによって、申請されたURLを包含する過去事例URL、または申請URLと一致する過去事例のURL、またはパス名がすべて一致する過去事例のURLを探し、見つかった場合その過去事例（複数可）を記録する。が見つからなかった場合、申請されたURLに包含される過去事例のURLをマッチングによって探し、見つかった場合その過去事例（複数可）を記録し、自動申請処理不可とする。見つかった場合、ステップ2115において、該当した過去事例の申請レベルを調べ、申請レベルによる自動申請可否の決定を行う。申請レベルとは、システムの管理者が予め判定した自動申請処理の可否を判断するためのレベルである。また、マッチングによって、包含関係のある過去事例のURLが見つからなかった場合も、自動申請処理不可とする。
【００１５】
自動申請可否の決定においては、次に、該当した過去事例を申請レベルの数値の低いものから順に照合する。申請レベルとは、システムの管理者が予め判定した自動申請処理の可否を判断するためのレベルである（図5参照、申請レベルの判定については後述）レベルが（１）であれば、ステップ2118において、無条件で自動申請処理可とする。レベルが（２）であれば、ステップ2116において、申請データのされた利用目的と過去事例の利用目的のマッチングを行い、一致した場合自動申請処理可とし、一致しなかった場合自動申請処理不可とする。レベルが（３）であれば、ステップ2117において、申請データのされた部門と過去事例の部門のマッチングを行い、一致した場合自動申請処理可とし、一致しなかった場合自動申請処理不可とする。レベルが（４）であれば、ステップ2122において、利用目的のマッチング、ステップ2123において、と部門のマッチングを行う。
【００１６】
この結果、一致した場合自動申請処理可とし、一致しなかった場合自動申請処理不可とする。レベルが（５）であれば、ステップ2124において、申請された部署と過去事例の部署のマッチングを行い、一致した場合自動申請処理可とし、一致しなかった場合自動申請処理不可とする。前方からスラッシュ区切りで行う。部署もURLと同様に木構造で考え、マッチングによって、申請された部署名を包含する過去事例の部署名、または部署名がすべて一致する過去事例を探し、見つかった場合自動申請処理可とする。見つからなかった場合、自動申請処理不可とする。レベルが（６）であれば、ステップ2120において、利用目的のマッチング、ステップ2121において、と部署のマッチングを行い、一致した場合自動申請処理可とし、一致しなかった場合自動申請処理不可とする。レベルが（７）であれば、ステップ2129において、無条件で自動申請処理不可とする。
【００１７】
利用目的が一致しかつ申請された部署名を包含するもしくは申請された部署名とすべて一致する過去事例の部署名が存在する場合場合自動申請処理可とし、それ以外の場合自動申請処理不可とする。この操作を該当した過去事例分繰り返し、自動申請処理が可となった時点で終了する。
【００１８】
自動申請処理の可否を決定後、ステップ2130において、結果を申請情報一覧テーブル320に登録する。
【００１９】
次に、本Web閲覧申請処理システムによる申請レベルの判定を図4-1〜4-2のフローチャートに従って説明する。図4-1〜4-2は管理者Ｂ端末110が自動申請処理不可となった申請に対して、入力された申請データとURLのパス名のマッチングによって記録した過去事例のデータをもとに判定した申請レベルに対し、判定したい時、APサーバが選択可能な申請レベルを管理者ＢにAPサーバ200が、申請レベルが適切であるかを判断する提示する場合を示したものである。
【００２０】
管理者Ｂ端末110は申請レベルを判定したい場合、ステップ2201において、申請レベル未定のURLを要求する。APサーバ200はステップ2202において、自動申請処理不可となった申請データを申請に対して、申請情報一覧テーブル320から検索する。管理者Ｂ端末110はステップ2205において、一覧から対象URLをひとつ選択し要求し、申請データAPサーバ200はステップ2206において、URLマッチング結果テーブル330から過去事例を検索する。とURL一覧テーブルからURLのパス名が最も一致する過去事例のデータを検索し、管理者Ｂ端末110はステップ2209において、それらの情報をもとに申請レベルを判定する。そのとき、APサーバ200は、以下の手順で管理者Ｂ端末110が判定したレベルが適切であるかに選択可能な申請レベルを提示判断する。
【００２１】
過去事例のURLが申請されたURLを包含する場合、ステップ2211において、過去事例の申請レベル以下のレベルが判定されているとき適切と判断し、それ以外の場合不適切と判断する。を申請データに対して選択可能にする。次に、申請されたURLと過去事例のURLがすべて一致する場合、ステップ2213において、閲覧可と不可が混在するならば、申請レベル（３）以上のレベルが判定されているとき適切と判断し、それ以外の場合不適切と判断する。を選択可能にし、そうでなければ任意の申請レベルを選択可能にする。申請されたURLが過去事例のURLを包含する場合、ステップ2212において、申請データに対して過去事例の申請レベル以上のレベルが判定されているとき適切と判断し、それ以外の場合不適切と判断する。を選択可能にする。申請されたURLと過去事例のURLとの間に包含関係が存在しないそれ以外の場合、ステップ2211において、任意の申請レベルが判定されているとき適切と判断し、それ以外の場合不適切と判断を選択可能にする。不適切と判断した場合、申請レベルの再判定を管理者Ｂ端末110に行わせる。適切と判断した場合、ステップ2214において、APサーバ200は申請レベルをURL一覧テーブル310に登録する。
【００２２】
管理者Ｂからの選択可能な申請レベルから適切なレベルの選択を受付け、その受付けられた内容に応じて、申請データをURL一覧テーブルに登録する。
【００２３】
以上、本発明の実施の形態を説明したが、図1において、自動申請の可否を決定する判断材料として、部門・部署・利用目的以外に申請者の職位などを加味することも可能である。
【図面の簡単な説明】
【００２４】
【図１】本発明の一実施形態におけるweb閲覧申請処理システムのブロック図。
【図２】本発明の一実施形態で用いる各種データテーブルを示す図。
【図３−１】Web閲覧申請処理システムによる自動申請処理のフローチャート（その１）。
【図３−２】Web閲覧申請処理システムによる自動申請処理のフローチャート（その２）。
【図３−３】Web閲覧申請処理システムによる自動申請処理のフローチャート（その３）。
【図３−４】Web閲覧申請処理システムによる自動申請処理のフローチャート（その４）。
【図３−５】Web閲覧申請処理システムによる自動申請処理のフローチャート（その５）。
【図４−１】Web閲覧申請処理システムによる申請レベルの判定処理のフローチャート（その１）。
【図４−２】Web閲覧申請処理システムによる申請レベルの判定処理のフローチャート（その２）。
【図５】自動申請可否の決定に用いる基準テーブルを示す図。
【図６】申請されたURLが過去事例のURLを包含するかを示す図。
【符号の説明】
【００２５】
１００…申請者Ａ端末、１１０…管理者Ｂ端末、２００…ＡＰサーバ、３００…ＤＢサーバ
【特許請求の範囲】
【請求項１】
利用者の利用者端末と、前記利用者端末に接続され前記利用者端末のインターネットへのアクセスを制御するサーバとからなるインターネットアクセス要求システムにおいて、
前記利用者端末から前記サーバへ、前記利用者の属性および利用を要求するｗｅｂページを特定するｗｅｂページ識別情報を送信し、
前記サーバは、利用者の属性毎にアクセスを許容するｗｅｂページのｗｅｂページ識別情報を記憶装置に格納しており、
前記サーバにおいて、受信された前記ｗｅｂページ識別情報が前記記憶装置に、受信された前記属性に対応して格納されているかを判断し、
格納されていないと判断された場合には、前記サーバにおいて、前記要求に対して許容しないと判断し、
格納されていると判断された場合には、前記サーバにおいて、前記要求が予め記憶している分類のいずれに対応するかを特定して、特定された分類に応じて前記要求に対する自動判断が可能かを判定することを特徴とするインターネットアクセス要求システム。
【請求項２】
請求項１に記載のインターネットアクセス要求システムにおいて、
前記ｗｅｂページ識別情報は、ＵＲＬであって、
前記サーバは、
送信されたＵＲＬから所定順序で部分ＵＲＬを抽出し、抽出された部分ＵＲＬが前記記憶装置に格納されているかを、上記の所定順序で比較することで判断することを特徴とするインターネットアクセス要求システム。
【請求項１】
利用者の利用者端末と、前記利用者端末に接続され前記利用者端末のインターネットへのアクセスを制御するサーバとからなるインターネットアクセス要求システムにおいて、
前記利用者端末から前記サーバへ、前記利用者の属性および利用を要求するｗｅｂページを特定するｗｅｂページ識別情報を送信し、
前記サーバは、利用者の属性毎にアクセスを許容するｗｅｂページのｗｅｂページ識別情報を記憶装置に格納しており、
前記サーバにおいて、受信された前記ｗｅｂページ識別情報が前記記憶装置に、受信された前記属性に対応して格納されているかを判断し、
格納されていないと判断された場合には、前記サーバにおいて、前記要求に対して許容しないと判断し、
格納されていると判断された場合には、前記サーバにおいて、前記要求が予め記憶している分類のいずれに対応するかを特定して、特定された分類に応じて前記要求に対する自動判断が可能かを判定することを特徴とするインターネットアクセス要求システム。
【請求項２】
請求項１に記載のインターネットアクセス要求システムにおいて、
前記ｗｅｂページ識別情報は、ＵＲＬであって、
前記サーバは、
送信されたＵＲＬから所定順序で部分ＵＲＬを抽出し、抽出された部分ＵＲＬが前記記憶装置に格納されているかを、上記の所定順序で比較することで判断することを特徴とするインターネットアクセス要求システム。
【図１】
【図２】
【図３−１】
【図３−２】
【図３−３】
【図３−４】
【図３−５】
【図４−１】
【図４−２】
【図５】
【図６】
【図２】
【図３−１】
【図３−２】
【図３−３】
【図３−４】
【図３−５】
【図４−１】
【図４−２】
【図５】
【図６】
【公開番号】特開２０１０−１３４８０８（Ｐ２０１０−１３４８０８Ａ）
【公開日】平成２２年６月１７日（２０１０．６．１７）
【国際特許分類】
【出願番号】特願２００８−３１１７１７（Ｐ２００８−３１１７１７）
【出願日】平成２０年１２月８日（２００８．１２．８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２２年６月１７日（２０１０．６．１７）
【国際特許分類】
【出願日】平成２０年１２月８日（２００８．１２．８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]