(57)【要約】【課題】同一の計算機上で複数の事業者によりそれぞれのサービスを提供する場合に、事業者間のセキュリティを担保することが可能なサーバシステム及びサービス提供プログラムを提供する。【解決手段】サーバシステム１のサーブレットコンテナ２１は、禁止タグテーブル６４を参照し、事業者６〜８，２２から受信したＬＪＳＰファイル３６〜３８の中に、禁止されたタグの文字列の記述がないかを調べる。また、サーブレットコンテナ２１は、利用するタグライブラリ３０〜３２がサーバ運用者２によって利用を認められているものかを調べる。また、サーブレットコンテナ２１は、ログインユーザ検査タグがＬＪＳＰファイル３６〜３８中に記述されていることを確認し、当該事業者のＩＤがこのタグのｓｐｉｄとして記述されているかチェックを行なう。【選択図】図２
2006318203.tif 000002
【特許請求の範囲】
【請求項１】
事業者が顧客にサービスを提供するＷｅｂサーバを備え、サーブレット及びＪＳＰを用いて構成されるサーバシステムにおいて、
前記サービスの提供に関する処理が記述されたＪＳＰファイルのタグを実行するに際し、ログインしているユーザの権限を確認した後に、所定の処理を行う機能を有するタグライブラリと、
前記事業者により作成されたＪＳＰファイルを、前記事業者の端末から受信し、該ＪＳＰファイルに記述されたタグが、利用が禁止されているか否か、及び、該タグによる所定の処理を行う機能を有するタグライブラリの利用が許可されているか否かを判断し、該タグの利用が禁止されておらず、かつ、そのタグライブラリの利用が許可されている場合に、前記受信したＪＳＰファイルを、前記事業者毎に区別された領域に配置する制御手段とを備えたことを特徴とするサーバシステム。
【請求項２】
請求項１に記載のサーバシステムにおいて、
前記タグライブラリは、ＪＳＰファイルを作成した事業者の情報を含むログインユーザ検査タグにより、ログインしたユーザの権限を確認する処理を行う機能を有し、
前記制御手段は、さらに、受信したＪＳＰファイルに、前記ログインユーザ検査タグが記述されているか否かを判断し、該ログインユーザ検査タグが記述されている場合に、該タグに、受信したＪＳＰファイルを作成した事業者の情報が含まれるか否かを判断し、該事業者の情報が含まれる場合に、前記受信したＪＳＰファイルを、前記事業者毎に区別された領域に配置する制御手段とを備えたことを特徴とするサーバシステム。
【請求項３】
請求項１に記載のサーバシステムにおいて、
前記タグライブラリは、オブジェクト名を含むオブジェクトアクセスタグにより、アクセスするオブジェクトを、ログインしたユーザの識別子及び前記オブジェクト名により管理する機能を有することを特徴とするサーバシステム。
【請求項４】
請求項１から３までのいずれか一項に記載のサーバシステムにおいて、
さらに、該サーバシステムに接続されるホームゲートウェイを管理するＥＪＢを備えたことを特徴とするサーバシステム。
【請求項５】
事業者が顧客にサービスを提供するＷｅｂサーバを備え、サーブレット及びＪＳＰを用いて構成されるサーバシステムの下で、前記サービスの提供に関する処理をタグにより記述されたＪＳＰファイル、及び、該タグにより所定の処理を行う機能を有するタグライブラリにより、前記サービスを提供するプログラムであって、前記Ｗｅｂサーバを構成するコンピュータに、
前記事業者により作成されたＪＳＰファイルを、前記事業者の端末から受信する処理と、
該ＪＳＰファイルに記述されたタグが、利用が禁止されているか否か、及び、該タグによる所定の処理を行う機能を有するタグライブラリの利用が許可されているか否かを判断する処理と、
該タグの利用が禁止されておらず、かつ、そのタグライブラリの利用が許可されている場合に、前記受信したＪＳＰファイルを、前記事業者毎に区別された領域に配置する処理と、
該事業者毎に区別された領域に配置されたＪＳＰファイルに記述されたタグを実行するに際し、ログインしているユーザの権限を確認する処理とを実行させるサービス提供プログラム。
【請求項６】
請求項５に記載のサービス提供プログラムにおいて、
前記タグライブラリは、ＪＳＰファイルを作成した事業者の情報を含むログインユーザ検査タグにより、ログインしたユーザの権限を確認する処理を行う機能を有し、
前記Ｗｅｂサーバを構成するコンピュータに、
受信したＪＳＰファイルに、前記ログインユーザ検査タグが記述されているか否かを判断する処理と、
該ログインユーザ検査タグが記述されている場合に、該タグに、受信したＪＳＰファイルを作成した事業者の情報が含まれるか否かを判断する処理と、
該事業者の情報が含まれる場合、及び、前記タグの利用が禁止されておらず、かつ、そのタグライブラリの利用が許可されている場合に、前記受信したＪＳＰファイルを、前記事業者毎に区別された領域に配置する処理とを実行させるサービス提供プログラム。
【請求項７】
請求項５に記載のサービス提供プログラムにおいて、
前記タグライブラリは、オブジェクト名を含むオブジェクトアクセスタグにより、アクセスするオブジェクトを管理する機能を有し、
前記Ｗｅｂサーバを構成するコンピュータに、
前記タグライブラリのオブジェクトアクセスタグの機能により、アクセスするオブジェクトを、ログインしたユーザの識別子及び前記オブジェクト名により管理する処理を実行させるサービス提供プログラム。
【請求項８】
請求項５から７までのいずれか一項に記載のサービス提供プログラムにおいて、
前記Ｗｅｂサーバは、さらにＥＪＢを備え、該Ｗｅｂサーバを構成するコンピュータに、
該ＥＪＢにより、前記サーバシステムに接続されるホームゲートウェイを管理する処理を実行させるサービス提供プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｊａｖａ（登録商標）ベースのＷｅｂサーバを用いて、複数の事業者がそれぞれの顧客に対してサービスを提供するサーバシステムに関する。
【背景技術】
【０００２】
従来、Ｗｅｂ技術を利用したサービスの提供が盛んに行なわれている。そのサービスを実現する手法の一つとして、Ｊａｖａ技術をベースとしたサーブレット（Ｓｅｒｖｌｅｔ）、ＪＳＰ（Ｊａｖａ  Ｓｅｒｖｅｒ  Ｐａｇｅｓ）、またはタグリブ（Ｔａｇｌｉｂ）が利用されている（例えば、非特許文献１、２を参照）。このようなＪａｖａ技術により、ネットワークの顧客に対し、Ｗｅｂ技術を利用したサービスを提供する事業者が多い。従来、複数の事業者がそれぞれのサービスを提供する場合、それぞれの事業者が、異なる計算機上にシステムを構築し、運用していた。または、それぞれの事業者が、サービスの機能を制限し、カスタマイズ性を大きく制限することにより、一台の計算機上に複数のサービスを集約してシステムを構築し、運用していた。
【０００３】
【非特許文献１】“JavaServer Pages(TM) Specification.1.1”、［online］、Sun microsystems,Inc.［平成１７年４月２８日検索］、インターネット＜ＵＲＬ：http://java.sun.com/products/jsp/reference/api/index.html＞
【非特許文献２】“JSRs:Java Specification Requests  JSR 53:JavaTM Servlet 2.3 and JavaServer PagesTM 1.2 Specifications”、［online］、Sun microsystems,Inc.［平成１７年４月２８日検索］、インターネット＜ＵＲＬ：http://www.jcp.org/en/jsr/detail?id=53＞
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、複数の事業者がそれぞれのサービスを提供するに際し、それぞれの事業者が異なる計算機上にシステムを構築した場合には、事業者毎に計算機を必要とし、余分なハードウェアのリソースが必要になるという問題があった。
【０００５】
また、事業者の提供するサービスの機能を制限し、カスタマイズ性を大きく制限することにより、一台の計算機上に複数のサービスを集約したシステムを構築した場合には、事業者がサービスを自由にカスタマイズできないという問題があった。
【０００６】
また、事業者がサービスを自由にカスタマイズできるようにし、かつ、一台の計算機上に複数のサービスを集約したシステムを構築した場合には、ある事業者により提供されるサービスに関する機能等の情報に、他の事業者がアクセスする可能性があり、いわゆる「事業者間のセキュリティ」を確保できないという問題があった。
【０００７】
さらに、複数のサービスを複数の計算機で提供する場合には、顧客からのログインの管理が困難になる。このため、顧客は、各サービス毎に認証手順を踏む必要があり、利便性が低下するという問題があった。この問題に対し、シングルサインオンのシステムを利用することにより、ログイン管理の困難性を解決することができるが、このシステムは高価になるため、導入が難しいという問題があった。
【０００８】
そこで、本発明は、上記課題を解決するためになされたものであり、その目的は、同一の計算機上で複数の事業者によりそれぞれのサービスを提供する場合に、事業者間のセキュリティを担保することが可能なサーバシステム及びサービス提供プログラムを提供することにある。
【課題を解決するための手段】
【０００９】
Ｊａｖａを用いたＷｅｂサーバシステムにおいて、静的な情報を記述したＨＴＭＬファイルに加え、動的なコンテンツを生成するサーブレットやＪＳＰを用いることにより、サービスの提供を実現することができる。事業者毎のサービスに対する要望を満たすため、カスタマイズが必要な場合は、これらのサーブレットやＪＳＰを新規に開発したり、既存のものを変更したりする。
【００１０】
ここで、サーブレット及びＪＳＰは、Ｊａｖａのプログラムそのものであり、特定のプログラムが「許されたリソースのみにアクセスしていること」を調べることは困難であった。
【００１１】
本発明は、
（１）文法を制限したＪＳＰを用いてカスタマイズを実現する、
（２）アクセス権限を確認した後にタグライブラリが動作する、
（３）タグライブラリにより、ログインしているユーザの種別に応じて、アクセスするオブジェクトの名前空間を分けて管理する、
（４）ＪＳＰファイルの記述が予定したルールに従っていることを確認する、
ことにより、前記課題を解決する。
【００１２】
〔カスタマイズの実現〕
事業者（事業者が操作する装置）は、その操作者が、文法の制約されたＪＳＰ（Ｌｉｍｉｔｅｄ  ＪＳＰ：以下、ＬＪＳＰという。）を用いてサービスのロジックや表示方法を記述すると、当該ＬＪＳＰファイルをサーバシステムへ送信する。サーバシステムは、ＬＪＳＰファイルを受信すると、その事業者に割り当てた領域に当該ＬＪＳＰファイルを配置することを、当該サーバシステムの運用者が許可するか否かを判断する。ここで、ＬＪＳＰファイルには、プログラムを自由に書くことが許された「スクリプトレットタグ」を始め、ＪＳＰで定義されたタグのうちのいくつかのタグの利用が禁止されている。サーバシステムは、利用が禁止されたタグが格納されている禁止タグテーブルを参照し、受信したＬＪＳＰファイルに、利用が禁止されたタグが存在するか否かを判断し、存在する場合は、そのＬＪＳＰファイルの配置を行わない。また、利用が可能なタグライブラリのインデックスが格納された許可管理テーブルを参照し、受信したＬＪＳＰファイルにおいて、利用が許可されたタグライブラリを使用するか否かを判断し、利用が許可されていないタグライブラリを使用する場合は、そのＬＪＳＰファイルの配置を行わない。
【００１３】
このように、事業者は、後述するサーバ運用者が提供したタグを用いて、ＬＪＳＰファイルを作成することになるから、事業者間のセキュリティを確保することができると共に、事業者毎のカスタマイズを実現することができる。そして、事業者は、作成したＬＪＳＰファイルをサーバシステムにアップロードしてサーバシステムに組み込む。この場合、サーバシステムは、ＬＪＳＰファイルを事業者に割り当てられた領域に配置すべきか否かについて、ＬＪＳＰ検査を行い、ＬＪＳＰ検査の条件が満たされているか否かのチェックを行なう。条件が満たされていない場合は、ＬＪＳＰファイルを配置しない。尚、サーバ運用者が提供するタグ及びＬＪＳＰ検査の詳細については後述する。
【００１４】
〔タグライブラリ〕
タグライブラリは、ＪＳＰ仕様で規定された概念であり、複数のタグの定義と、そのタグが評価された際に実行する複数のプログラムとをまとめたものである。ＬＪＳＰによって動的なコンテンツを生成する場合は、スクリプトレットで行なわず、タグライブラリ中に記載されたタグを呼び出すことで実現する。サーバシステムは、ＬＪＳＰファイルに記述されたタグの実行に際し、ＬＪＳＰファイルに記述されたタグライブラリを呼び出し、まず最初に、ログインしている利用者の権限を調べる。利用者の権限に応じて、当該タグの動作が許可された場合は、そのプログラムに従って動作を行なう。一方、許可されない場合は、エラーページを転送する、タグの出力としてワーニングメッセージを出力する等の処理を行なう。
【００１５】
タグライブラリにおいて、ＪＳＰ仕様では、タグに関連付けられたプログラム中に、任意のＪａｖａコードを記載することができる。このプログラム中に、サーバ運用者が事業者間のセキュリティを維持できるように配慮して記載したコードを埋め込むものとする。この場合、事業者間のセキュリティに配慮して記述したコードの埋め込みは、サーバ運用者のみに限定されるものとする。つまり、サーバ運用者が事業者間のセキュリティを維持できるように配慮してコードを埋め込んだタグライブラリを、事業者により利用が認められるタグライブラリとする。
【００１６】
〔ＬＪＳＰ検査手順〕
図３（ａ）は、ＬＪＳＰファイルの正当性を検証する手順を説明するフローチャート図である。サーバシステムは、禁止タグテーブル６４を参照し、事業者から受信したＬＪＳＰファイルの中に、禁止されたタグの文字列の記述がないかを調べる（ステップ３０２〜３０４、３０６、３０７）。禁止されたタグがあった場合はエラーとする（ステップ３０５）。文字列の検査は周知の方法で行なうことができる。
【００１７】
また、サーバシステムは、事業者から受信したＬＪＳＰファイルの中に、サーバ運用者により利用が認められていないタグライブラリの使用宣言が存在するかを調べる（ステップ３０８〜３１１、３１３）。利用が認められているタグライブラリが存在した場合はエラーとする（ステップ３１２）。
【００１８】
また、サーバシステムは、事業者から受信したＬＪＳＰファイルの中に、ログインユーザ検査タグが記述されていることを確認する。そして、記述されている場合は、当該事業者のＩＤがこのタグのｓｐｉｄ（事業者ＩＤ）として記載されているかチェックを行なう。当該事業者のＩＤがｓｐｉｄとして記載されていない場合はエラーとする。ここで、ログインユーザ検査タグのｓｐｉｄには、当該ＬＪＳＰファイルが属する事業者のＩＤを記載するようになっている。
【００１９】
〔認証の単一性〕
本発明では、一つの計算機で複数のサービスを提供するため、セッション情報を一元的に管理することができる。これにより、顧客は一度認証手段を踏むことにより、複数の異なるサービスを享受することができる。
【発明の効果】
【００２０】
本発明によれば、複数の事業者が、それぞれのサービスを開発し、同一の計算機（Ｗｅｂサーバ）を用いて、それぞれの顧客にサービスを提供することが可能となる。このため、サーブレットコンテナやＥＪＢコンテナのサーバソフトウェア群も複数用意する必要がない。したがって、単一の計算機、単一のサーバソフトウェアを用いて、複数の事業者によるそれぞれのサービスを提供できるから、余分なハードウェアのリソースが不要となり、リソースを無駄に費やすこともない。
【００２１】
また、事業者が作成したＪＳＰファイルについて、種々の判断を行うようにしたから、セキュリティを考慮したタグの使用が求められることになり、新たなタグの追加に伴う事業者間のセキュリティを担保することができる。このため、複数の事業者のサービスを実現するソフトウェア群を同一の計算機、サーバソフトウェア上に配置しても、事業者間でデータの秘匿性が保たれる。
【００２２】
また、異なる事業者により複数のサービスを享受する顧客は、同じウェブサイトで複数のサービスを享受することが可能となり、利便性が高くなる。これに対し、本発明を用いない場合は、事業者毎に計算機を設ける必要があり、顧客は、事業者毎再ログインする必要があるため、利便性が低くなる。また、本発明を用いない場合は、シングルサインオンを実現するソフトウェアやハードウェアを用いる必要があるため、システムが高価になるというデメリットがある。
【発明を実施するための最良の形態】
【００２３】
以下、本発明の実施の形態について図面を用いて詳細に説明する。
図１は、本発明の実施の形態によるサーバシステムを含む概念的なシステム構成図である。このシステムは、サーバシステム１、サーバ運用者２、事業者６〜８及び顧客９〜１１により構成される。サーバシステム１とサーバ運用者２との間、サーバシステム１と事業者６〜８との間、及び、サーバシステム1と顧客９〜１１との間は、インターネット等のネットワークにより接続される。サーバシステム１は、Ｗｅｂサーバを含み、複数の事業者６〜８が同一の当該サーバシステム１においてそれぞれ独自のサービスを提供するためのソフトウェア群３〜５を備えている。サーバ運用者２は、サーバシステム１の保守、管理、運用を行う。事業者６〜８は、顧客９〜１１にサービスを提供するためのソフトウェアを開発し、カスタマイズする。事業者６〜８により開発及びカスタマイズされたソフトウェア群３〜５は、サーバシステム１の所定の領域に配置される。顧客９〜１１は、事業者６〜８の顧客であり、サーバシステム１にアクセスし、ソフトウェア群３〜５により、それぞれ所定のサービスを享受する。尚、ソフトウェア群３，４は、事業者６により開発及びカスタマイズされたものであり、ソフトウェア群５は、事業者２により開発及びカスタマイズされたものである。また、顧客９，１０は事業者６の顧客であり、顧客１１は事業者７の顧客である。
【００２４】
このように構成されたシステムの下で、サーバシステム１は、顧客９〜１１からのサービス提供要求を受信し、サービスを提供するためのソフトウェア群３〜５を実行し、所定のサービスを顧客９〜１１に提供する。尚、図１において、サーバ運用者２、事業者６〜８及び顧客９〜１１は主体の概念を示しており、実際は、それぞれの主体が操作するパーソナルコンピュータ等の通信装置である。
【００２５】
図２は、図１に示したサーバシステム１の構成図である。図２には、事業者Ａがサービスを提供するためのソフトウェア群、及び、事業者Ｂがサービスを提供するためのソフトウェア群の機能が示されている。サーバシステム１は、Ｊ２ＥＥ（Ｊａｖａ２  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ）サーバにより、一般的なサーブレットコンテナ２１、ＥＪＢコンテナ４２及びデータベースシステム３９に基づいて構成されている。サーブレットコンテナ２１は、サーバ運用者２が提供するソフトウェア要素が格納された領域２４、事業者２２（事業者Ａ）がサービスを提供するためのソフトウェア要素が格納された領域３３、及び、事業者Ｂ（図示せず）がサービスを提供するためのソフトウェア要素が格納された領域３４を備えている。尚、領域３３にはＬＪＳＰファイル３６，３７を配置することが、また、領域３４にはＬＪＳＰファイル３８を配置することが、サーバ運用者２により許可される。データベースシステム３９は、事業者Ａ用のデータ４０及び事業者Ｂ用のデータ４１を管理している。ＥＪＢコンテナ４２は、Ｅｎｔｅｒｐｒｉｓｅ  ＪａｖａＢｅａｎｓ（ＥＪＢ）４４，４５を備えている。
【００２６】
サーブレットコンテナ２１の領域２４には、ＪＳＰファイル２５，２６、サーブレット２７，２８、及びタグライブラリ３０〜３２が格納されている。領域３３には、ＬＪＳＰファイル３６，３７及びＪａｖａＢｅａｎｓ３５が格納されている。領域３４には、ＬＪＳＰファイル３８及びＪａｖａＢｅａｎｓ２９が格納されている。ここで、サーバシステム１のサーブレットコンテナ２１は、サーバ運用者２からＪＳＰファイル２５，２６、サーブレット２７，２８、及びタグライブラリ３０〜３２を受信し、サーブレットコンテナ１の領域２４に配置する。また、サーブレットコンテナ２１は、事業者ＡからＬＪＳＰファイル３６，３７を受信し、サーバ運用者２により配置が許可されるか否かを判断し、許可された場合は、これらのソフトウェア要素を領域３３に配置する。同様に、サーブレットコンテナ２１は、事業者ＢからＬＪＳＰファイル３８を受信し、サーバ運用者２により配置が許可されるか否かを判断し、許可された場合は、これらのソフトウェア要素を領域３４に配置する。ＪａｖａＢｅａｎｓ２９，３５は、ＬＪＳＰファイルにＪａｖａＢｅａｎｓを利用するタグの記載がされており、そのタグが実行された際に、領域３３，３４（この場合はメモリ領域）に作成される。
【００２７】
〔認証〕
事業者６〜８，２２、顧客９〜１１，２３、及びサーバ運用者２は、サーバシステム１を利用する前にログインする必要がある。サーバシステム１のサーブレットコンテナ２１は、事業者６〜８，２２、顧客９〜１１，２３、またはサーバ運用者２からログインがあると、ログインした事業者、顧客またはサーバ運用者の認証情報をセッション変数として、図示しない領域に格納する。この場合、サーブレットコンテナ２１がログインの認証処理を行なう場合もあれば、認証機能を有するサーブレット（例えばサーブレット２７）が行う場合もある。このログインの認証処理は、広く利用されている公知技術により実現することができるため、詳細な内容についての説明は省略する。
【００２８】
〔ＬＪＳＰ〕
ＬＪＳＰは、本明細書において定義された用語であり、前述のように、文法が制約されたＪＳＰをいう。つまり、ＪＳＰで規定されている記法を制限したものである。
【００２９】
〔利用を禁止するタグ一覧〕
図２及び図３を参照して、事業者６〜８，２２は、サービスを提供するためのソフトウェアをタグを用いてＬＪＳＰファイル３６〜３８に記述し、サーバシステム１は、このＬＪＳＰファイル３６〜３８を領域３３，３４に配置する。この場合、サーバシステム１のサーブレットコンテナ２１は、事業者ＡからＬＪＳＰファイル３６，３７を受信し、領域３３に配置する際に、利用が禁止されたタグが存在するか否かを判断し、利用が禁止されたタグの利用を禁止する。同様に、サーブレットコンテナ２１は、事業者ＢからＬＪＳＰファイル３８を受信し、領域３４に配置する際に、利用が禁止されたタグが存在するか否かを判断し、利用が禁止されたタグの利用を禁止する。このＬＪＳＰファイル３６〜３８は、前述のように、ＪＳＰで規定されているタグを制限したものであり、具体的には以下のタグの利用が禁止される。
＜ｊｓｐ：ｄｅｃｌａｒａｔｉｏｎ＞
＜％！  ％＞
＜ｊｓｐ：ｅｘｐｒｅｓｓｉｏｎ＞
＜％＝  ％＞
＜ｊｓｐ：ｓｃｒｉｐｔｌｅｔ＞
＜％  ％＞
＜ｊｓｐ：ｇｅｔＰｒｏｐｅｒｔｙ＞
＜ｊｓｐ：ｓｅｔＰｒｏｐｅｒｔｙ＞
＜ｊｓｐ：ｕｓｅＢｅａｎ＞
＜％＠  ｉｎｃｌｕｄｅ  ％＞
＜ｊｓｐ：ｄｉｒｅｃｔｉｖｅ．ｉｎｃｌｕｄｅ＞
＜ｊｓｐ：ｉｎｃｌｕｄｅ＞
サーバシステム1は、これらの利用が禁止されたタグが登録されたタグ禁止テーブル６４（図３（ｂ）を参照）を保持し、サーブレットコンテナ２１は、当該タグ禁止テーブル６４に基づいて、利用が禁止されたタグが存在するか否かを判断する。また、サーバ運用者２は、タグ禁止テーブル６４に対するタグの登録、修正、削除等の管理を行う。
【００３０】
また、ＬＪＳＰでは、サーバ運用者２によって利用を認められたタグライブラリを利用することができるが、認めていないタグライブラリを利用することはできない。ＪＳＰファイルの中にはタグライブラリの仕様宣言を次のようなフォーマットで記述することになっている。
＜％＠  ｔａｇｌｉｂ  ｕｒｉ＝“ＵＲＩＦｏｒＬｉｂｒａｒｙ”  ｐｒｅｆｉｘ＝“ｔａｇＰｒｅｆｉｘ”  ％＞
サーブレットコンテナ２１は、事業者ＡからＬＪＳＰファイル３６，３７を受信し、領域３３に配置する際に、この宣言をチェックし、サーバ運用者２により認められていないタグライブラリの利用を禁止する。同様に、サーバシステム１のサーブレットコンテナ２１は、事業者ＢからＬＪＳＰファイル３８を受信し、領域３４に配置する際に、この宣言をチェックし、サーバ運用者２により認められていないタグライブラリの利用を禁止する。サーバシステム1は、利用が認められているタグライブラリのインデックスが登録された許可管理テーブル６５（図４を参照、詳細については後述する。）を保持し、サーブレットコンテナ２１は、当該許可管理テーブル６５に基づいて、利用が認められているタグライブラリであるか否かを判断する。また、サーバ運用者２は、許可管理テーブル６５に対するライブラリインデックスの登録、修正、削除等の管理を行う。
【００３１】
また、ＪＳＰにおいては、スクリプトレットの形でＪａｖａコードを自由に埋め込むことが可能であるが、ＬＪＳＰファイル３６〜３８の作成に関しては、Ｊａｖａコードの埋め込みを禁止する。具体的には、サーバシステム１のサーブレットコンテナ２１は、事業者ＡからＬＪＳＰファイル３６，３７を受信し、領域３３に配置する際に、Ｊａｖａコードが埋め込まれているか否かを判断し、Ｊａｖａコードが埋め込まれている場合は、その利用を禁止する。同様に、サーバシステム１のサーブレットコンテナ２１は、事業者ＢからＬＪＳＰファイル３８を受信し、領域３４に配置する際に、Ｊａｖａコードが埋め込まれているか否かを判断する。これにより、アプリケーションの記述性はＪＳＰと比較して若干限定されるが、事業者６〜８，２２間のセキュリティを実現することができる。
【００３２】
〔サーバ運用者が提供するタグの例〕
次に、サーバ運用者２が提供するタグについて説明する。具体的には、サーバシステム１のサーブレットコンテナ２１は、サーバ運用者２から、タグを実行するための処理が規定された情報を受信し、タグライブラリ３０〜３２として領域２４に配置する。事業者６〜８，２２は、サーバ運用者２により提供されたタグをＬＩＳＰファイル３６〜３８に記述して利用することができる。
（１）ログインユーザ検査タグ
次のように定義されたタグが実行される。
＜ｓａｐ：ｕｓｅｒｃｈｅｃｋ  ｓｐｉｄ＝［事業者のＩＤ］  ｔｙｐｅ＝“ｅｎｄｕｓｅｒ”｜“ｏｐｅｒａｔｏｒ”｜“ａｄｍｉｎｉｓｔｒａｔｏｒ”｜“ｐｒｏｖｉｄｅｒ”｜“ａｌｌ”／＞
サーブレットコンテナ２１は、事業者６〜８，２２によりこのタグが記述されたＬＪＳＰファイル３６〜３８を所定の領域３３，３４に配置することにより、このタグの実行に際し、ログインしたユーザがＷｅｂページを閲覧する権利を有しているか否かを調べ、権利がないと判断した場合に、ユーザの画面にエラーページを表示させる。ログインユーザ検査タグには、ｓｐｉｄ属性として、当該タグの記述されたＬＪＳＰファイルがどの事業者に属するものか（どの事業者により作成されたファイルであるか）について規定される。また、Ｔｙｐｅ属性として、どの種類のユーザならばこのＷｅｂページを閲覧することができるかについて規定される。つまり、特定の事業者のエンドユーザ（ｅｎｄｕｓｅｒに対応）であるか、事業者の作業者（ｏｐｅｒａｔｏｒに対応）であるか、事業者の管理者であるかが規定される。Ｔｙｐｅ属性として、ｐｒｏｖｉｄｅｒが規定されていた場合は、ログインしたユーザが事業者の作業者（ｏｐｅｒａｔｏｒに対応）または事業者の管理者のときに、このＷｅｂページを閲覧することが可能となる。また、Ｔｙｐｅ属性として、“ａｌｌ”が規定されていた場合は、ログインしたユーザが特定の事業者のエンドユーザ（ｅｎｄｕｓｅｒに対応）、事業者の作業者（ｏｐｅｒａｔｏｒに対応）、または事業者の管理者（ａｄｍｉｎｉｓｔｒａｔｏｒに対応）のときに、このＷｅｂページを閲覧することが可能となる。
【００３３】
つまり、サーブレットコンテナ２１は、タグライブラリ３０〜３２によりこのタグに関連付けられたプログラムを実行する際に、ログインしたユーザの属性を調べ、タグに指定された条件に合うか否かを判断し、条件に合わない場合はエラーページをユーザへ転送する。このタグを利用することにより、図２におけるアクセス４６，４９を、閲覧する権利を有しないアクセスであるとし、エラーとすることが可能となる。
【００３４】
例えば、事業者Ｂ用の領域３４に配置されたＬＪＳＰファイル３８に、ログインユーザ検査タグのタイプ属性として、このページを閲覧することができるユーザの種類（事業者Ｂの顧客）が規定されているとする。この場合、事業者２２（事業者Ａ）からＬＪＳＰ３８にアクセスがあると、サーブレットコンテナ２１は、このログインユーザ検査タグに対応付けられたプログラムを実行する際に、ログインした事業者２２とＴｙｐｅ属性とにより、このアクセス４６をエラーとし、エラーページを事業者２２へ転送する。同様に、事業者Ａの顧客２３からＬＪＳＰ３８にアクセスがあると、サーブレットコンテナ２１は、このログインユーザ検査タグに対応付けられたプログラムを実行する際に、ログインした顧客２３とＴｙｐｅ属性とにより、このアクセス４９をエラーとし、エラーページを顧客２３へ転送する。
【００３５】
（２）データベースアクセスタグ
次のように定義されたタグが実行される。
＜ｓａｐ：ｔａｂｌｅ  ｖａｒｉａｂｌｅ＝“ｘｘ”  ｄｂｎａｍｅ＝“ｄｂ”  ｔａｂｌｅｎａｍｅ＝“ｓａｍｐｌｅ”  ｃｏｌｕｍｎｓ＝“ａ，ｂ，ｃ，ｄ”  ｓｅａｒｃｈｃｏｌｕｍｎ＝“ａ”  ｃｏｌｕｍｎｖａｌｕｅ＝“ａｌ”＞
サーブレットコンテナ２１は、事業者６〜８，２２によりＬＪＳＰファイル３６〜３８に記述されたこのタグの実行に際し、ログインしたユーザが、タグにより指定されたデータベース（ａｂｎａｍｅ属性）、テーブル（ｔａｂｌｅｎａｍｅ属性）、または、少なくとも１つ以上のカラム（ｃｏｌｕｍｎｎａｍｅ属性）にアクセスする権利を有するか否かを調べ、権利を有すると判断した場合に、その検索したデータをタグのｖａｒｉａｂｌｅ属性で指定された変数に格納する。データベースを検索して複数の結果を得た場合も、Ｊａｖａ言語に用意されているｊａｖａ．ｕｔｉｌ．Ｍａｐクラスや、ｊａｖａ．ｕｔｉｌ．ＡｒｒａｙＬｉｓｔ等の複数の値を格納できるクラスを利用することにより、前述した同じ方法で実現することができる。
【００３６】
つまり、サーブレットコンテナ２１は、タグライブラリ３０〜３２によりこのタグに対応付けられたプログラムを実行する際に、ログインしたユーザのアクセス権利を調べ、権利があることを確認した後に、検索したデータを変数に格納する。このタグを利用することにより、図２におけるアクセス４８を、アクセスする権利を有しないアクセスであるとして、エラーとすることが可能となる。これにより、他の事業者用のデータへのアクセスを防ぐことが可能となる。
【００３７】
また、アクセスする領域についてはさまざまな粒度が想定され、ＤＢ、テーブル、カラム、または特定のレコードに限りアクセスすることが可能である。このアクセス制御は、図６に示すデータベースアクセス制御テーブル８１を用いることにより実現することができる。図６のデータベースアクセス制御テーブル８１を参照して、「占有タイプ」の種別には、ｄｂ、ｔａｂｌｅ、ｃｏｌｕｍｎ、ｒｅｃｏｒｄｂｙＳＰ及びｒｅｃｏｒｄｂｙＥＵがある。それぞれデータベース、テーブル、カラム、レコード、レコードの単位でアクセス制御を行なうものである。レコード８２は、「占有タイプ」としてｄｂ単位でアクセスを許可することを示しており、「ＳＰ」の事業者Ａに対して、データベースｄｂ１への全体のアクセスを許可している。レコード８４は、「占有タイプ」としてｔａｂｌｅ単位でアクセスを許可することを示しており、「ＳＰ」の事業者Ｂに対して、データベースｄｂ２中にあるテーブルａｔａｂｌｅへのアクセスを許可している。レコード８５は、「占有タイプ」としてカラム単位でアクセスを許可することを示しており、「ＳＰ」の事業者Ｂに対して、任意のデータベース中にあるテーブルｂｔａｂｌｅのカラムＡＲＥＡＣＯＤＥへのアクセスを許可している。尚、＊は、任意のもの（全てのもの）にマッチすることを意味する。
【００３８】
また、レコード８６は、事業者からのアクセスに対して、レコード単位でアクセスを許可することを示しており、「ＩＤ＿ＣＯＬＵＭＮ」で指定されたカラムＳＰＮＡＭＥ中に、サーバシステム１にアクセスしているユーザの所属する事業者識別情報が記載されているレコードについてアクセスを許可している。この条件が整う場合（ユーザの所属する事業者識別情報が記載されている場合）は、「ｄｂｎａｍｅ」「ｔａｂｌｅｎａｍｅ」「ｃｏｌｕｍｎｎａｍｅ」について上記と同様に判断し、全てのデータベース中にあるテーブルａｔａｂｌｅ２の全てのカラムへのアクセスを許可する。つまり、ＳＰＮＡＭＥのカラムにＡ（アクセスしているユーザの事業者識別情報）の値が記載されていると判断した場合に、そのレコードについてアクセスすることができ、全てのデータベース中にあるテーブルａｔａｂｌｅ２の全てのカラムへのアクセスを許可する。
【００３９】
また、レコード８７は、顧客からのアクセスに対して、レコード単位でアクセスを許可することを示しており、「ＩＤ＿ＣＯＬＵＭＮ」で指定されたカラムＥＵＮＡＭＥ中に、サーバシステム１にアクセスしているユーザの識別情報が記載されているレコードについてアクセスを許可している。この条件が整う場合（ユーザの識別情報が記載されている場合）は、「ｄｂｎａｍｅ」「ｔａｂｌｅｎａｍｅ」「ｃｏｌｕｍｎｎａｍｅ」について上記と同様に判断し、全てのデータベース中にあるテーブルａｔａｂｌｅ２の全てのカラムへのアクセスを許可する。
【００４０】
尚、図６に示したデータベースアクセス制御テーブル８１を用いることにより、ＤＢ、テーブル、カラム、または特定のレコードに限りアクセスすることが可能となるが、アクセス制御は、これに制限されるものではない。例えば、ＩＰアドレスやポート番号を図６に示したデータベースアクセス制御テーブル８１に追加することにより、複数のデータベースサーバに対応することができる。また、「ＲＥＡＤ／ＷＲＩＴＥ種別」のようなカラムを追加することにより、書き込み／読み込みを区別して許可することができる。このようにして、細かなアクセス制御を実現することが可能となる。
【００４１】
（３）ＥＪＢアクセスタグ
次のように定義されたタグが実行される。
＜ｓａｐ：ｅｊｂｓｅｓｓｉｏｎ  ｖａｒｉａｂｌｅ＝“ｍｙｒｅｔｕｒｎ”  ｊｎｄｉｎａｍｅ＝“ｘｘｘ”  ｍｅｔｈｏｄｎａｍｅ＝“ｃａｌｌ１”  ａｒｇｎａｍｅ１＝“ｆｉｎｄ”  ａｒｇｎａｍｅ２＝“ｍｙｏｂｊ”＞
サーブレットコンテナ２１は、事業者６〜８，２２によりＬＪＳＰファイル３６〜３８に記述されたこのタグの実行に際し、ログインしたユーザのアクセス権を判断し、タグの属性で指定されたＪＮＤＩ名を有するＥＪＢオブジェクトに対して、指定されたメソッドを指定された引数を伴って呼び出しを行い、メソッドの戻り値をタグのｖａｒｉａｂｌｅ属性に指定された変数に格納する。
【００４２】
このＥＪＢアクセスタグにより、ＥＪＢのメソッドに対してもアクセス制御が可能となり、さらに、前述した（２）データベースアクセスタグの説明で示した図６のデータベースアクセス制御テーブル８１のようなテーブルを用いることにより、アクセスする領域の粒度を想定した細かなアクセス制御を実現することが可能となる。
【００４３】
また、サーブレットコンテナ２１は、このタグの実行に際し、当該タグを実現するタグライブラリ３０〜３２のプログラム中にて、図６に示したデータベースアクセス制御テーブル８１のようなテーブルを参照し、ログインしたユーザにアクセス権があるか否かを判断し、アクセス権があると判断した場合にのみ、メソッドの呼び出しを行なうことが記載されたプログラムを実行する。これにより、事業者間におけるセキュリティを担保することができる。また、図２におけるアクセス５０を、アクセスする権利を有しないアクセスであるとし、エラーとすることが可能となる。これは、顧客からの要求により、ＥＪＢへのアクセスを許可しないという方針に従ったアクセス制御の例である。
【００４４】
（４）ＪａｖａＢｅａｎｓアクセスタグ
前述のように、ＬＪＳＰファイルにおいて、以下のタグの利用は禁止されている。これは、ｊａｖａＢｅａｎｓのアクセス制御を実現できないからである。
＜ｊｓｐ：ｇｅｔＰｒｏｐｅｒｔｙ＞
＜ｊｓｐ：ｓｅｔＰｒｏｐｅｒｔｙ＞
＜ｊｓｐ：ｕｓｅＢｅａｎ＞
ここで、以下に示すように、これらのタグと同様の機能を有する別名のタグを用意する。
【００４５】
（４．１）＜ｓａｐ：ｕｓｅＢｅａｎ＞タグ
＜ｓａｐ：ｕｓｅＢｅａｎ＞タグは、ＪＳＰ仕様で定められており、＜ｊｓｐ：ｕｓｅＢｅａｎ＞タグと同様の動作を行なう。例えば、次のように記述して定義されたタグが実行される。
＜ｓａｐ：ｕｓｅＢｅａｎ  ｉｄ＝“ｏｂｊ１”  ｃｌａｓｓ＝“ＭｙＤａｔｅ”  ｓｃｏｐｅ＝“ｒｅｑｕｅｓｔ”／＞
ここでは、ｏｂｊ１という名前でＭｙＤａｔｅ型のインスタンスを生成することを宣言している。ＪＳＰ仕様では、ｓｃｏｐｅ属性でオブジェクトインスタンスのライフタイムを指定できることになっている。ただし、ｓｃｏｐｅ属性としてＡｐｐｌｉｃａｔｉｏｎのライフタイムは認めないこととする。サーブレットコンテナ２１は、このタグの実行に際し、ｓｃｏｐｅ属性が“Ａｐｐｌｉｃａｔｉｏｎ”であった場合は、何も処理を行なわない。＜ｊｓｐ：ｕｓｅＢｅａｎ＞タグでは、ｏｂｊ１がこのオブジェクトの名前として管理されるが、＜ｓａｐ：ｕｓｅＢｅａｎ＞タグでは、サーブレットコンテナ２１が、この名前の前に事業者のコード（識別子）とコロンを入れて、“Ａ：ｏｂｊ１”という名前でアクセスを管理する。事業者のコードは、ログイン時の認証情報により得ることができる。これにより、他の事業者の管理するオブジェクトと名前が重複することはない。ただし、タグ内に指定するｉｄ属性中に“：”を使用することは禁止される。サーブレットコンテナ２１は、このタグに関連づけられたプログラムを実行し、“：”が入っていないことを確認し、入っていた場合は処理を中断する。このタグを実行した際に、この名前を有したＪａｖａＢｅａｎｓインスタンスが存在しない場合は、ＪａｖａＢｅａｎｓインスタンスを生成し、前記の名前を付与して格納する。
【００４６】
（４．２）＜ｓａｐ：ｇｅｔＰｒｏｐｅｒｔｙ＞タグ、＜ｓａｐ：ｓｅｔＰｒｏｐｅｒｔｙ＞タグ
＜ｓａｐ：ｇｅｔＰｒｏｐｅｒｔｙ＞タグは、ＪＳＰ仕様で定められており、＜ｊｓｐ：ｇｅｔＰｒｏｐｅｒｔｙ＞タグと同様の動作を行なう。また、＜ｓａｐ：ｓｅｔＰｒｏｐｅｒｔｙ＞タグもＪＳＰ仕様で定められており、＜ｊｓｐ：ｓｅｔＰｒｏｐｅｒｔｙ＞タグと同様の動作を行なう。＜ｓａｐ：ｇｅｔＰｒｏｐｅｒｔｙ＞タグ及び＜ｓａｐ：ｓｅｔＰｒｏｐｅｒｔｙ＞タグでは、＜ｓａｐ：ｕｓｅＢｅａｎ＞タグと同様に、サーブレットコンテナ２１が、ｉｄ属性の前に事業者のコードとコロンを入れて、例えば、“Ａ：ｏｂｊ１”という名前で管理する。
【００４７】
尚、顧客の識別子も入れて管理することにより、さらに細かい粒度のアクセス制御を行なうバリエーションのタグを導入することもできる。例えば、“事業者：顧客ＩＤ：ｏｂｊ１”という名前で管理する。これにより、タグに記述されているアクセス対象のオブジェクトに対し、ログインしているユーザの種別によりそのユーザのコードを付加するから、オブジェクトの名前空間を分けた管理が可能となる。
【００４８】
このように、＜ｓａｐ：ｇｅｔＰｒｏｐｅｒｔｙ＞タグ，＜ｓａｐ：ｓｅｔＰｒｏｐｅｒｔｙ＞タグ及び＜ｓａｐ：ｕｓｅＢｅａｎ＞タグを利用したＬＪＳＰファイルにおいて、サーブレットコンテナ２１が、そのタグの実行に際し、認証情報に基づいてアクセスする権利を有するか否かを判断し、アクセス権利を有する場合にのみ、所定の機能を実行するようにした。これにより、図２におけるアクセス４７を、アクセス権利を有しないアクセスであるとし、エラーとすることが可能となる。つまり、サーブレットコンテナ２１は、ＬＪＳＰファイル３６の前記タグの実行に際し、他の事業者の領域３４に配置されたＪａｖａＢｅａｎｓ２９へのアクセス４７を禁止することにより、事業者間の領域を跨ったＪａｖａＢｅａｎへのアクセスを行なうことが不可能となる。
【００４９】
（５）画面表示タグ
前述の（１）〜（４）のタグでは、処理の結果、変数にさまざまな値を代入する処理が行なわれる。サーブレットコンテナ２１は、ＬＪＳＰファイル３６〜３８に記述された画面表示タグの実行に際し、処理結果である変数を、ログインしたユーザの画面にそのまま値として出力する。この場合、表形式で出力したりグラフを作成して出力するようにしてもよい。
【００５０】
（６）その他のタグ
（１）〜（５）のタグは、比較的簡単な処理を実現するタグの種類に属するものであるが、その他の処理を実現するタグを排除するものではない。サーバ運用者２が同様の多種多様なタグを開発して提供することができることは、同一の技術分野の技術者には容易に理解できる。サーバ運用者２が、タグライブラリを開発した場合は、通常のサーブレットコンテナ２１でタグライブラリを開発する手法に加えて、図４に示す許可管理テーブル６５に新たなレコードを追加することにより、本サーバシステム１において、タグライブラリを利用することが可能となる。また、サーバ運用者２がタグの種類を増やし、充実させていくことにより、事業者６〜８，２２は、顧客に提供するサービスを実現するためのＬＪＳＰファイル３６〜３８を効率的に記述することが可能となる。
【００５１】
〔ＬＪＳＰ検査手順〕
サーバシステム１のサーブレットコンテナ２１は、事業者６〜８，２２の管理者の操作により送信されたＬＪＳＰファイル３６〜３８を受信し、ＬＪＳＰファイル３６〜３８中に、禁止されたタグの文字列の記載があるか否かを調べる。禁止されたタグが存在すると判断した場合はエラーとし、エラー情報を事業者６〜８，２２へ転送する。文字列の検査は周知の方法で行なうことができる。サーブレットコンテナ２１は、図３（ｂ）に示した禁止タグテーブル６４を管理し、この禁止タグテーブル６４を参照して禁止されたタグの存在を判断する（図３（ａ）に示したステップ３０２〜３０７を参照）。
【００５２】
ＪＳＰ仕様は、継続してメンテナンスされており、今後バージョンアップされることが想定される。また、サーブレットコンテナベンダが独自の仕様を追加することにより、利用可能なタグが増えることも想定される。事業者間のセキュリティが保たれないような新しいタグが追加された場合には、図３（ｂ）に示した禁止タグテーブル６４にそのタグを追加することにより、新たなＪＳＰ仕様やベンダ独自の仕様等に対して、セキュリティの確保を実現することができる。
【００５３】
また、サーブレットコンテナ２１は、ＬＪＳＰファイル３６〜３８中に、禁止されたタグの文字列の記述があるか否かを調べることに加えて、使用するタグライブラリがサーバ運用者２により利用が認められているか否かを調べる。サーブレットコンテナ２１は、ＬＪＳＰ３６〜３８中に、利用が認められているタグライブラリ以外のタグライブラリが宣言されていた場合はエラーとする。利用が認められているタグライブラリであるか否かの検査は、図４に示した許可管理テーブル６５をサーバシステム１に保持しておき、このテーブルを参照して行う。ＬＪＳＰファイル３６〜３８を順に調べ、「＜％＠  ｔａｇｌｉｂ  ｕｒｉ＝“．．．”  ｐｒｅｆｉｘ＝“．．．”  ％＞」の記述を検索し、許可管理テーブル６５のデータと照らし合わせる（図３（ａ）に示したステップ３０８〜３１４を参照）。図４において、「利用を認める事業者」の欄が“＊”のレコードは、全ての事業者に対して認めていることを示しており、特定のＩＤ（「Ａ」「Ｂ」）が記載されていた場合は、そのＩＤに対応する事業者にのみ認めていることを示している。利用を認めていないと判断した場合はエラーとし、エラー情報を事業者６〜８，２２へ転送する。
【００５４】
また、サーブレットコンテナ２１は、ログインユーザー検査タグがＬＪＳＰファイル３６〜３８に記述されていることを確認する。この場合、当該事業者のＩＤがｓｐｉｄとして記載されているかチェックを行なう。条件が満たされない場合はエラーとし、ＬＪＳＰファイル３６〜３８の配置を中止する。または、事業者６〜８，２２の画面に警告を表示するのみとして、処理を継続する。
【００５５】
尚、前述のログインユーザ検査タグがＬＪＳＰファイル３６〜３８に記述されており、当該事業者のＩＤがｓｐｉｄとして記載されていることの条件は、「他の事業者の関係者に本ＬＪＳＰファイルを実行させないため」に用いられるものであり、「他の事業者の情報を本事業者が脅かすことを禁止するため」に用いられるものではないため、必須ではない。しかし、このチェックを行なうことで、他の事業者からの不正なアクセスを禁止できるという点でメリットが得られる。
【実施例】
【００５６】
次に、ホームアプリケーションサービスの利用事例について説明する。図５は、ホームゲートウェイを管理するサーバシステムの実施例を示すネットワーク構成図である。このホームアプリケーションサービスは、サーバシステム１の中に閉じて完結するのではなく、ＥＪＢ７３，７４配下に複数のホームゲートウェイ７０〜７２を接続し、家庭内のホームゲートウェイ７０〜７２を管理するものである。また、ホームゲートウェイ７０〜７２配下に接続されたデバイス群（図示せず）に対しても制御を行なうことができる。尚、図５において、図２と共通する部分には図２と同一の符号を付し、その詳しい説明は省略する。
【００５７】
図５を参照して、ＥＪＢ７３は、事業者６に対してホームゲートウェイ７０，７１の情報を提供する機能を有する。このＥＪＢ７３は、メソッド呼び出しの引数の一つとして事業者の識別情報が渡される構成となっており、その事業者の加入しているホームゲートウェイにしかアクセスを許さないコーディングがなされている。このため、ＥＪＢコンテナ４２は、サーブレットコンテナ２１によりＬＪＳＰファイル３６、タグライブラリ７５及びＥＪＢ７３から他の事業者２のホームゲートウェイ７２へのアクセス７８を禁止する。
【００５８】
また、ＥＪＢ７４は、顧客９に対してホームゲートウェイ７０の情報を提供する機能を有する。このＥＪＢ７４は、メソッド呼び出しの引数の一つとして顧客の識別情報が渡される構成となっており、顧客９の保有するホームゲートウェイ７０にしかアクセスを許さないコーディングがなされている。このため、ＥＪＢコンテナ４２は、サーブレットコンテナ２１によりＬＪＳＰファイル３７、タグライブラリ７６及びＥＪＢ７４から他の顧客１０の保有するホームゲートウェイ７１へのアクセス７７を禁止する。つまり、事業者６の顧客９は、自分の保有するホームゲートウェイ７０にしかアクセスが許されない。
【００５９】
尚、図２に示した領域２４，３３，３４とは、ディスク領域及びメモリ領域のことを指す。事業者６〜８，２２が配置するＬＪＳＰファイル３６〜３８は、まず、ディスク領域に配置され、その後、サーブレットコンテナ２１の機能において、メモリ領域に読み込まれ、実行可能状態となる。また、ＪａｖａＢｅａｎｓインスタンスは、メモリ領域に配置される。ＪａｖａＢｅａｎｓオブジェクトクラスは、サーバ運用者２により提供されるもののみしか利用することができない。
【００６０】
尚、上記サーバシステム１は、ＣＰＵ、ＲＡＭ等の揮発性の記憶媒体、ＲＯＭ等の不揮発性の記憶媒体、キーボード等の入力装置、データを表示する表示装置、及び外部の装置と通信するためのインターフェースを備えたコンピュータ装置によって構成される。この場合、サーバシステム１に備えた各種ソフトウェア要素の各機能は、当該機能を記述したプログラムをＣＰＵに実行させることにより実現される。また、これらのプログラムは、磁気ディスク（フロッピィーディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ等）、半導体メモリ等の記憶媒体に格納して頒布することもできる。
【図面の簡単な説明】
【００６１】
【図１】本発明の実施の形態によるサーバシステムを含む概念的なシステム構成図である。
【図２】図１のサーバシステムを示す構成図である。
【図３】ＬＪＳＰファイルの正当性を検証する手順を説明するフローチャート図である。
【図４】利用タグの許可情報を格納する許可管理テーブルを示す図である
【図５】ホームゲートウェイを管理するサーバシステムの実施例を示すネットワーク構成図である。
【図６】データベースアクセス制御テーブルを示す図である。
【符号の説明】
【００６２】
１  サーバシステム
２  サーバ運用者
３〜５  ソフトウェア要素
６〜８，２２  事業者
９〜１１，２３  顧客
２１  サーブレットコンテナ
２４，３３，３４  領域
２５，２６  ＪＳＰファイル
２７，２８  サーブレット
２９，３５  ＪａｖａＢｅａｎｓ
３０〜３２  タグライブラリ
３６〜３８  ＬＪＳＰファイル
３９  データベースシステム
４０  事業者Ａ用データ
４１  事業者Ｂ用データ
４２  ＥＪＢコンテナ
４４，４５，７３，７４  ＥＪＢ
４６〜５０，７７，７８  禁止されるアクセス
６４  禁止タグテーブル
６５  許可管理テーブル
７０〜７２  ホームゲートウェイ
８１  データベースアクセス制御テーブル
８２〜８７  レコード
【図１】
2006318203.tif 000003
【図２】
2006318203.tif 000004
【図３】
2006318203.tif 000005
【図４】
2006318203.tif 000006
【図５】
2006318203.tif 000007
【図６】
2006318203.tif 000008