シングルサインオンサーバ及びシングルサインオンプログラム
【課題】シングルサインオンの特徴を可能な範囲で活かしつつセキュリティ性の維持を図ることを容易に実現可能にする。
【解決手段】ＳＳＯサーバ１０は、サービスサーバ４に対する各ユーザの利用状況を記憶する利用ログ情報記憶部１６と、各ユーザのサービスサーバ４の利用実績に関する情報を記憶する利用実績情報記憶部１７と、ログインしたユーザの利用ログ情報から得られる利用傾向が当該ユーザの利用実績と合致した場合及び合致しなくてもＳＳＯの必要度が所定の基準値以上であった場合にＳＳＯによる認証の許可、そうでない場合にＳＳＯによる認証の禁止と判定する判定部１９と、認証可と判定されたサービスサーバ４及びアプリケーションに対してのみ当該ユーザにＳＳＯによるユーザ認証を行う認証処理部１１とを有する。
【解決手段】ＳＳＯサーバ１０は、サービスサーバ４に対する各ユーザの利用状況を記憶する利用ログ情報記憶部１６と、各ユーザのサービスサーバ４の利用実績に関する情報を記憶する利用実績情報記憶部１７と、ログインしたユーザの利用ログ情報から得られる利用傾向が当該ユーザの利用実績と合致した場合及び合致しなくてもＳＳＯの必要度が所定の基準値以上であった場合にＳＳＯによる認証の許可、そうでない場合にＳＳＯによる認証の禁止と判定する判定部１９と、認証可と判定されたサービスサーバ４及びアプリケーションに対してのみ当該ユーザにＳＳＯによるユーザ認証を行う認証処理部１１とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、シングルサインオンサーバ及びシングルサインオンプログラムに関する。
【背景技術】
【０００２】
ＳＳＯ（Ｓｉｎｇｌｅ Ｓｉｇｎ Ｏｎ）は、ユーザがＳＳＯサーバにて一度認証を受けるだけで、許可されている他のサーバ、機能等を利用できるようになる点で便利である。しかし、その一方で、不正者に認証情報が漏洩してしまった場合にセキュリティ上の脅威、被害等を拡大させてしまうという問題が発生しうる。このような問題に対処するためには、何らかの手段を講じる必要が生じてくる。
【０００３】
なお、ログインユーザのアプリケーションの利用状況に応じてアクセス権を動的に変更する技術が提案されている（例えば、特許文献１）。
【０００４】
【特許文献１】特開２００４−０６２２４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
セキュリティ上の脅威を広げずにＳＳＯの利便性を維持しようとすると、例えば、管理者がアプリケーション毎にＳＳＯサーバを介してログインを許可/禁止させるような設定を行えば可能であるかもしれない。しかしながら、アプリケーション毎に、かつユーザ毎に個別の設定を行うことになると、その設定作業は複雑かつ面倒であり、現実的ではない。
【０００６】
本発明は、シングルサインオンの特徴を可能な範囲で活かしつつセキュリティ性の維持を図ることを容易に実現可能にすることを目的とする。
【課題を解決するための手段】
【０００７】
本発明に係るシングルサインオンサーバは、ユーザにサービスを提供するサービスサーバそれぞれに対する各ユーザの利用状況を記憶する利用ログ情報記憶手段と、当該ユーザの前記サービスサーバの利用実績に関する情報を記憶する利用実績情報記憶手段と、ユーザがログインしたときに、当該ユーザの利用ログ情報から得られる利用傾向と当該ユーザの利用実績とを比較した結果に応じてシングルサインオンによるユーザ認証の可否を前記サービスサーバ毎に判定する判定手段と、前記判定手段により認証可と判定されたサービスサーバに対してのみ当該ユーザにシングルサインオンによるユーザ認証を行う認証手段と、を有することを特徴とする。
【０００８】
また、シングルサインオンによるユーザ認証の可否の判定に用いる基準値を記憶する基準値記憶手段を有し、前記判定手段は、当該ユーザの利用傾向と当該ユーザの利用実績とを比較した結果、シングルサインオンによるユーザ認証を否と判定した場合でも、当該ユーザの利用実績が前記基準値に達している場合にはシングルサインオンによるユーザ認証を可と判定することを特徴とする。
【０００９】
また、前記利用実績情報記憶手段には、当該ユーザの前記サービスサーバ毎アプリケーション毎の利用実績に関する情報が記憶されており、前記判定手段は、前記サービスサーバに搭載されたアプリケーション毎にシングルサインオンによるユーザ認証の可否を判定することを特徴とする。
【００１０】
また、前記判定手段は、当該ユーザの利用傾向が当該ユーザの利用実績と合致した場合にシングルサインオンによるユーザ認証を可と判定することを特徴とする。
【００１１】
また、前記判定手段による当該ユーザの利用傾向を前記利用実績情報記憶手段に記憶された当該ユーザの利用実績情報に反映させることで更新する更新手段を有することを特徴とする。
【００１２】
本発明に係るシングルサインオンプログラムは、コンピュータを、ユーザにサービスを提供するサービスサーバそれぞれに対する各ユーザの利用状況を記憶する利用ログ情報記憶手段、当該ユーザの前記サービスサーバの利用実績に関する情報を記憶する利用実績情報記憶手段、ユーザがログインしたときに、当該ユーザの利用ログ情報から得られる利用傾向と当該ユーザの利用実績とを比較した結果に応じてシングルサインオンによるユーザ認証の可否を前記サービスサーバ毎に判定する判定手段、前記判定手段により認証可と判定されたサービスサーバに対してのみ当該ユーザにシングルサインオンによるユーザ認証を行う認証手段として機能させることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、ユーザの利用状況に応じてシングルサインオンによる認証の是非を動的に決定することができるので、ユーザの便宜を図りつつセキュリティ性の維持を図ることができる。また、複雑な設定作業が不要である。
【発明を実施するための最良の形態】
【００１４】
以下、図面に基づいて、本発明の好適な実施の形態について説明する。
【００１５】
図１は、本発明に係るシングルサインオンサーバの一実施の形態を含むネットワークシステムの全体構成図である。図１には、シングルサインオン（ＳＳＯ）サーバ１０と、クライアント２と、サービスサーバ４とがネットワーク６で接続された構成が示されている。サービスサーバ４は、ユーザに対して所定のサービスを提供するサーバコンピュータである。クライアント２は、ＳＳＯサーバ１０を介してサービスサーバ４が提供するサービスを利用するユーザによって使用されるコンピュータであり、本実施の形態ではパーソナルコンピュータ（ＰＣ）を実現することを想定している。ＳＳＯサーバ１０は、ＳＳＯをクライアントユーザに提供するサーバコンピュータである。なお、図１では、各コンピュータを接続するネットワーク手段としてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を想定して図示したが、ＬＡＮに限定する必要はない。
【００１６】
更に、図１には、ＳＳＯサーバ１０のブロック構成が示されている。本実施の形態におけるＳＳＯサーバ１０は、認証処理部１１、利用状況収集部１２、制御部１３、認証情報記憶部１４、基準値情報記憶部１５、利用ログ情報記憶部１６及び利用実績情報記憶部１７を有している。
【００１７】
認証情報記憶部１４には、ユーザＩＤとパスワードの組から成るユーザ認証情報が事前に登録されている。ユーザ認証情報には、各サービスサーバ４に対応した情報と、ユーザ認証を要求するアプリケーションに対応した情報とが存在する。基準値情報記憶部１５には、ＳＳＯによるユーザ認証の可否の判定に用いる複数種類の基準値が事前に登録されている。利用ログ情報記憶部１６には、サービスサーバ４及びサービスサーバ４に搭載されたアプリケーションに対する各ユーザの利用状況に関連するログが蓄積されている。利用実績情報記憶部１７には、各ユーザの利用状況が解析されることによって得られる利用実績に関する情報が記憶される。
【００１８】
認証処理部１１は、ログイン画面から入力されたユーザＩＤ及びパスワードを、認証情報記憶部１４に登録されているユーザ認証情報と照合することでユーザ認証を行う。本実施の形態における認証処理部１１は、ログ解析部１８、判定部１９及び実績更新部２０を有している。ログ解析部１８は、利用ログ情報記憶部１６に蓄積されたログインユーザに関するログを解析することによって当該ユーザの利用傾向を求める。判定部１９は、ログインユーザの利用傾向と、当該ユーザの利用傾向を分析することによって得られた利用実績との対比、またサービスサーバ４ａあるいはアプリケーションの必要度と基準値との比較を行うことによりＳＳＯによるユーザ認証の可否をサービスサーバ毎アプリケーション毎に判定する。実績更新部２０は、判定部１９が判定を行う過程で得た利用実績情報により利用ログ情報記憶部１６に記憶されている当該ユーザの利用実績情報を更新する。利用状況収集部１２は、ＳＳＯサーバ１０にログインした各ユーザの利用状況をログとして利用ログ情報記憶部１６に逐次記録する。制御部１３は、ＳＳＯサーバ１０における各構成要素１１，１２の制御を行う。
【００１９】
図２は、本実施の形態におけるＳＳＯサーバ１０のハードウェア構成図である。本実施の形態においてＳＳＯサーバ１０を形成するサーバコンピュータは、従前から存在する汎用的なハードウェア構成で実現できる。すなわち、コンピュータは、図２に示したようにＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、ハードディスクドライブ（ＨＤＤ）２４を接続したＨＤＤコントローラ２５、入力手段として設けられたマウス２６とキーボード２７、及び表示装置として設けられたディスプレイ２８をそれぞれ接続する入出力コントローラ２９、通信手段として設けられたネットワークコントローラ３０を内部バス３１に接続して構成される
【００２０】
なお、性能的に差異はあるかもしれないが、サービスサーバ４、更にはクライアント２もコンピュータであることから、そのハードウェア構成は、図２と同じように図示することができる。
【００２１】
ＳＳＯサーバ１０における各構成要素１１〜１３は、ＳＳＯサーバ１０に搭載されたコンピュータと、コンピュータに搭載されたＣＰＵ２１で動作するプログラムとの協調動作により実現される。また、各記憶部１４〜１７は、ＳＳＯサーバ１０に搭載されたＨＤＤ２４にて実現される。
【００２２】
また、本実施の形態で用いるプログラムは、通信手段により提供することはもちろん、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体に格納して提供することも可能である。通信手段や記録媒体から提供されたプログラムはコンピュータにインストールされ、コンピュータのＣＰＵがインストールプログラムを順次実行することで各種処理が実現される。
【００２３】
図３は、本実施の形態における利用ログ情報記憶部１６に蓄積されるログ情報のデータ構成例を示した図である。ログ情報は、サービスサーバ４へのアクセスを開始した日時情報（アクセス日時）、サービスサーバ４へアクセスした際に用いたクライアント２の識別情報（アクセス端末）、サービスサーバ４が提供するサービスシステムの名称（サービス名）及びアクセスをしたユーザの識別情報（ユーザＩＤ）が対応付けして構成される。もちろん、ログ情報には、その他のデータ項目も含めてもよいが、図３には、本実施の形態の説明上必要な項目を抽出して図示した。
【００２４】
従来のＳＳＯサーバにおけるユーザ認証においては、認証を受けたユーザはアクセスが許可されている全てのサービスサーバに対して個々にユーザ認証を受けなくてもアクセスすることが可能になる。これに対し、本実施の形態においては、当該ユーザの各サービスサーバ４に対する利用状況、更にアプリケーションの利用状況に応じてＳＳＯを許可することによってユーザ認証を省略可能にしたり、ＳＳを許可しないことによってサービスサーバ４等の利用の都度ユーザ認証を要求したりする。本実施の形態において特徴的なことは、ＳＳＯを一律的に有効にするのではなく、ユーザの利用状況によって、具体的には過去の利用実績から頻繁に利用するサービスサーバ４やアプリケーションに関してはＳＳＯを許可し、あまり利用しないサービスサーバ４やアプリケーションに関してはＳＳＯを禁止するようにしたことである。このように、ユーザの利用状況に応じてＳＳＯの可否を分けて取り扱うようにしたので、セキュリティ性の維持とＳＳＯの利便性の双方を効果的に満たすことができる。
【００２５】
次に、本実施の形態における認証処理について図４に示したフローチャートを用いて説明する。
【００２６】
ユーザがクライアント２を用いてＳＳＯサーバ１０にアクセスすると、ＳＳＯサーバ１０は、ログイン画面をクライアント２に表示させてログインを要求する。ユーザが表示されたログイン画面からユーザＩＤ及びパスワードを入力すると、ＳＳＯサーバ１０における認証処理部１１は、その入力された認証情報を受け付ける（ステップ１１０）。そして、認証処理部１１は、入力された認証情報を、認証情報記憶部１４に登録されているユーザ認証情報と照合することによって当該ユーザを認証する。なお、ここでは、正規のユーザが正しい認証情報を入力したものとして説明する。正しくない認証情報が入力された場合は認証情報の再入力を促すなど従前と同様に対処すればよい。続いて、認証処理部１１におけるログ解析部１８は、利用ログ情報記憶部１６に蓄積されたログインユーザに関するログを解析することによって週、月などの所定期間内における当該ユーザの利用傾向を得る。この利用傾向についてここで詳述する。
【００２７】
図３に例示したように、ログ情報として、アクセス日時、アクセス端末、サービス名及びユーザＩＤの各データ項目が収集されている。ここで、まずアクセス日時に注目して分析してみると、ログインしたユーザは、毎週決まった曜日に当該システムを利用している、毎日利用している、特定の月に利用している、ある特定の時間帯に集中して利用している、などの利用傾向を得ることが可能である。また、アクセス端末に注目して分析してみると、ログインしたユーザは、特定の決まった端末からのアクセスがある、同じドメインからアクセスしている、などの利用傾向を得ることが可能である。更にサービス名に注目して分析してみると、ログインしたユーザは、特定のサービスのみ利用しているなどの利用傾向を得ることが可能である。また、これらを組み合わせて分析してみると、ログインしたユーザは、あるシステムに関しては、特定の曜日・日・月に利用している、特定のアクセス端末からある時間帯に利用している、などの利用傾向を得ることが可能である。
【００２８】
更に、サービスサーバ毎からアプリケーション毎まで落とし込んだ利用傾向を得るようにしてもよい。本実施の形態では、これをアプリケーション間の依存度と称している。例えば、ＳＳＯサーバ１０で管理可能なサービスに勤怠管理システムと工数管理システムが含まれているとする。そして、ほとんどのユーザが勤怠管理システムを利用して勤怠を入力した後に工数管理システムを利用して工数を入力する傾向にあるとする。つまり、勤怠管理システムを提供するサービスサーバ４が利用された後に工数管理システムを提供するサービスサーバ４が利用される傾向がある場合、これらのサービスは依存関係のあるサービス関係として利用実績情報記憶部１７に事前に登録しておく。これにより、勤怠管理システムがＳＳＯによる認証を許可する場合には工数管理システムも同じくＳＳＯによる認証を許可するように設定しておくことは、ユーザにとって都合が良い。
【００２９】
また、このようなユーザの利用に依存しない処理の工程の流れから導き出すこと以外に、前述したログの解析を行うことによって、例えば、あるユーザは、あるサービスサーバ４が提供するサービスＡを利用した後は他のサービスサーバ４が提供するサービスＢを利用する傾向にあるというというユーザに特化した利用傾向を導き出す。
【００３０】
利用傾向の強弱は、アプリケーション間の依存度によって表すことができる。依存度は、有り／無しという表現や、数値で表現可能とする。数値で表現可能な場合の例として数値が低いほど依存度が弱く、高いほど依存度が強いと設定する。例えば、サービスＡを利用した後にサービスＢを利用するユーザが１００人に達していれば、サービスＡ，Ｂの依存度は１、２００人に達していれば、サービスＡ，Ｂの依存度は２、とサービス間の依存度を定義できる。また、依存度が数値で表されている場合でも、基準値情報記憶部１５に事前に設定されている依存度の基準値（閾値）と比較することによって依存度を有り／無しと置換することも可能になる。
【００３１】
以上のように、ログ解析部１８がログインユーザ及び当該ユーザが利用するシステム環境に関連した利用傾向を得ると、判定部１９は、利用実績情報記憶部１７から当該ユーザの利用実績情報を取得する（ステップ１３０）。ここで、ユーザの利用実績というのは、ユーザの利用傾向を解析した結果として得られる情報である。利用実績としては、例えば、過去Ｘヶ月間におけるシステムAへのアクセス日数がＺ％以上である、１日におけるＸ時〜Ｙ時という時間帯におけるアクセスはＺ％以上である、などのように表現し、その分析結果は数値化して百分率（％）で表現できるように求める。ただ、情報量（サンプル数）が少ないうちは、分析結果の精度は必ずしも高いとは言えないので、一定のアクセス件数を要件としてもよい。
【００３２】
まず、判定部１９は、ログ解析部１８が求めた利用傾向が利用実績と合致しているか否かを判定する。例えば、利用傾向が、サービスＡに対するアクセスは月曜日に集中しＺ％以上である、という利用実績に該当するか否かを判別する。利用傾向が利用実績と合致している場合（ステップ１４０でＹ）、判定部１９は、ログインユーザをＳＳＯによる認証を許可すると判定する。これにより、認証処理部１１は、その判定結果に従って該当するサービスサーバ４及びアプリケーションにＳＳＯの許可を設定する（ステップ１５０）。つまり、上記例によるとサービスＡを提供するサービスサーバ４及びサービスＡのアプリケーションに対して、ＳＳＯを有効とする、すなわちＳＳＯサーバ１０へのログインによってサービスＡのアプリケーションを利用する際にユーザ認証を要求しないことになる。なお、ステップ１４０における利用傾向と利用実績との対比は、利用実績として登録されている数だけ行われる。
【００３３】
一方、利用傾向が利用実績と合致していない場合（ステップ１４０でＮ）、判定部１９は、続いて必要度と基準値とを比較する。ここで、必要度というのは、ＳＳＯを許可する必要性の度合いである。利用傾向が利用実績に合致すると、利用実績の％が上がり、この結果、必要度は上昇する。一方、利用傾向が利用実績に合致しないと、利用実績の％が下がるため必要度は減少する。ただ、外出や休暇を取ることによって必然的に必要度が低くなってしまう場合を考慮して、利用傾向が利用実績に合致しない場合でも、必要度に対して設定された基準値を必要度が上回っていればＳＳＯを許可する。数値例をあげて説明すると、サービスＡに対するアクセスは月曜日に集中しＺ（＝９０）％以上である、という利用実績に対し、必要度の基準値として８０％が設定されているとする。今までのサービスＡに対する月曜日の利用傾向が９２％で利用実績を満たしていたものの、祭日や振替休日でサービスＡにアクセスしなかったことで、利用傾向が８６％と下がり利用実績を満たさなくなったとする。このような場合に、利用傾向（８６％）が利用実績（９０％）を合致しなくなったとしても基準値（８０％）は満たす関係にある。
【００３４】
従って、必要度と基準値とを比較した結果、必要度が基準値以上である場合（ステップ１７０でＹ）、判定部１９は、ログインユーザをＳＳＯによる認証を許可すると判定する。これにより、認証処理部１１は、その判定結果に従って該当するサービスサーバ４及びアプリケーションにＳＳＯの許可を設定する（ステップ１５０）。
【００３５】
一方、必要度が基準値を下回った場合（ステップ１７０でＮ）、判定部１９は、ログインユーザをＳＳＯによる認証を禁止すると判定する。これにより、認証処理部１１は、その判定結果に従って該当するサービスサーバ４及びアプリケーションにＳＳＯの禁止を設定する（ステップ１５０）。すなわち、当該サービスサーバ４やアプリケーションを利用する際には、ユーザ認証を要求することになる。このユーザ認証が改めて要求されるサービスサーバ４及びアプリケーションは、当該ユーザが本来利用していない、若しくはほとんど利用していない。このようなサービスサーバ４等が利用されようとしているのは、正規ユーザによる利用かもしれないけれども利用実績からして正規ユーザでない可能性が相対的に高いと考えられる。このため、本実施の形態では、ＳＳＯサーバ１０の管理対象といえどもＳＳＯを禁止することによってセキュリティの維持を図ることを優先した。
【００３６】
以上のようにＳＳＯの許可又は禁止を設定した後、実績更新部２０は、利用傾向を現時点における当該ユーザの利用実績に反映させることによって利用実績情報記憶部１７に記憶されている当該ユーザの利用実績情報を更新する（ステップ１６０）。
【００３７】
以上説明したように、本実施の形態では、管理対象のサービスサーバ４及びアプリケーションに対してＳＳＯを一律に許可するのではなく、利用状況に応じてＳＳＯの許可／禁止を動的に設定する。仮に、ＳＳＯが禁止されたことでサービスサーバ４等を利用する度にユーザ認証が要求されていたとしても当該サービスサーバ４等を繰り返し利用し続ければ必要度が増加するので、いずれＳＳＯが許可されることになる。従って、管理者等がＳＳＯの許可／禁止を個別に設定する必要はない。
【図面の簡単な説明】
【００３８】
【図１】本発明に係るシングルサインオンサーバの一実施の形態を含むネットワークシステムの全体構成図である。
【図２】本実施の形態におけるＳＳＯサーバ１０のハードウェア構成図である。
【図３】本実施の形態における利用ログ情報記憶部１６に蓄積されるログのデータ構成例を示した図である。
【図４】本実施の形態における認証処理を示したフローチャートである。
【符号の説明】
【００３９】
２ クライアント、４ サービスサーバ、６ ネットワーク、１０ ＳＳＯサーバ、１１ 認証処理部、１２ 利用状況収集部、１３ 制御部、１４ 認証情報記憶部、１５ 基準値情報記憶部、１６ 利用ログ情報記憶部、１７ 利用実績情報記憶部、１８ ログ解析部、１９ 判定部、２０ 実績更新部、２１ ＣＰＵ、２２ ＲＯＭ、２３ ＲＡＭ、２４ ハードディスクドライブ（ＨＤＤ）、２５ ＨＤＤコントローラ、２６ マウス、２７ キーボード、２８ ディスプレイ、２９ 入出力コントローラ、３０ ネットワークコントローラ、３１ 内部バス。
【技術分野】
【０００１】
本発明は、シングルサインオンサーバ及びシングルサインオンプログラムに関する。
【背景技術】
【０００２】
ＳＳＯ（Ｓｉｎｇｌｅ Ｓｉｇｎ Ｏｎ）は、ユーザがＳＳＯサーバにて一度認証を受けるだけで、許可されている他のサーバ、機能等を利用できるようになる点で便利である。しかし、その一方で、不正者に認証情報が漏洩してしまった場合にセキュリティ上の脅威、被害等を拡大させてしまうという問題が発生しうる。このような問題に対処するためには、何らかの手段を講じる必要が生じてくる。
【０００３】
なお、ログインユーザのアプリケーションの利用状況に応じてアクセス権を動的に変更する技術が提案されている（例えば、特許文献１）。
【０００４】
【特許文献１】特開２００４−０６２２４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
セキュリティ上の脅威を広げずにＳＳＯの利便性を維持しようとすると、例えば、管理者がアプリケーション毎にＳＳＯサーバを介してログインを許可/禁止させるような設定を行えば可能であるかもしれない。しかしながら、アプリケーション毎に、かつユーザ毎に個別の設定を行うことになると、その設定作業は複雑かつ面倒であり、現実的ではない。
【０００６】
本発明は、シングルサインオンの特徴を可能な範囲で活かしつつセキュリティ性の維持を図ることを容易に実現可能にすることを目的とする。
【課題を解決するための手段】
【０００７】
本発明に係るシングルサインオンサーバは、ユーザにサービスを提供するサービスサーバそれぞれに対する各ユーザの利用状況を記憶する利用ログ情報記憶手段と、当該ユーザの前記サービスサーバの利用実績に関する情報を記憶する利用実績情報記憶手段と、ユーザがログインしたときに、当該ユーザの利用ログ情報から得られる利用傾向と当該ユーザの利用実績とを比較した結果に応じてシングルサインオンによるユーザ認証の可否を前記サービスサーバ毎に判定する判定手段と、前記判定手段により認証可と判定されたサービスサーバに対してのみ当該ユーザにシングルサインオンによるユーザ認証を行う認証手段と、を有することを特徴とする。
【０００８】
また、シングルサインオンによるユーザ認証の可否の判定に用いる基準値を記憶する基準値記憶手段を有し、前記判定手段は、当該ユーザの利用傾向と当該ユーザの利用実績とを比較した結果、シングルサインオンによるユーザ認証を否と判定した場合でも、当該ユーザの利用実績が前記基準値に達している場合にはシングルサインオンによるユーザ認証を可と判定することを特徴とする。
【０００９】
また、前記利用実績情報記憶手段には、当該ユーザの前記サービスサーバ毎アプリケーション毎の利用実績に関する情報が記憶されており、前記判定手段は、前記サービスサーバに搭載されたアプリケーション毎にシングルサインオンによるユーザ認証の可否を判定することを特徴とする。
【００１０】
また、前記判定手段は、当該ユーザの利用傾向が当該ユーザの利用実績と合致した場合にシングルサインオンによるユーザ認証を可と判定することを特徴とする。
【００１１】
また、前記判定手段による当該ユーザの利用傾向を前記利用実績情報記憶手段に記憶された当該ユーザの利用実績情報に反映させることで更新する更新手段を有することを特徴とする。
【００１２】
本発明に係るシングルサインオンプログラムは、コンピュータを、ユーザにサービスを提供するサービスサーバそれぞれに対する各ユーザの利用状況を記憶する利用ログ情報記憶手段、当該ユーザの前記サービスサーバの利用実績に関する情報を記憶する利用実績情報記憶手段、ユーザがログインしたときに、当該ユーザの利用ログ情報から得られる利用傾向と当該ユーザの利用実績とを比較した結果に応じてシングルサインオンによるユーザ認証の可否を前記サービスサーバ毎に判定する判定手段、前記判定手段により認証可と判定されたサービスサーバに対してのみ当該ユーザにシングルサインオンによるユーザ認証を行う認証手段として機能させることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、ユーザの利用状況に応じてシングルサインオンによる認証の是非を動的に決定することができるので、ユーザの便宜を図りつつセキュリティ性の維持を図ることができる。また、複雑な設定作業が不要である。
【発明を実施するための最良の形態】
【００１４】
以下、図面に基づいて、本発明の好適な実施の形態について説明する。
【００１５】
図１は、本発明に係るシングルサインオンサーバの一実施の形態を含むネットワークシステムの全体構成図である。図１には、シングルサインオン（ＳＳＯ）サーバ１０と、クライアント２と、サービスサーバ４とがネットワーク６で接続された構成が示されている。サービスサーバ４は、ユーザに対して所定のサービスを提供するサーバコンピュータである。クライアント２は、ＳＳＯサーバ１０を介してサービスサーバ４が提供するサービスを利用するユーザによって使用されるコンピュータであり、本実施の形態ではパーソナルコンピュータ（ＰＣ）を実現することを想定している。ＳＳＯサーバ１０は、ＳＳＯをクライアントユーザに提供するサーバコンピュータである。なお、図１では、各コンピュータを接続するネットワーク手段としてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を想定して図示したが、ＬＡＮに限定する必要はない。
【００１６】
更に、図１には、ＳＳＯサーバ１０のブロック構成が示されている。本実施の形態におけるＳＳＯサーバ１０は、認証処理部１１、利用状況収集部１２、制御部１３、認証情報記憶部１４、基準値情報記憶部１５、利用ログ情報記憶部１６及び利用実績情報記憶部１７を有している。
【００１７】
認証情報記憶部１４には、ユーザＩＤとパスワードの組から成るユーザ認証情報が事前に登録されている。ユーザ認証情報には、各サービスサーバ４に対応した情報と、ユーザ認証を要求するアプリケーションに対応した情報とが存在する。基準値情報記憶部１５には、ＳＳＯによるユーザ認証の可否の判定に用いる複数種類の基準値が事前に登録されている。利用ログ情報記憶部１６には、サービスサーバ４及びサービスサーバ４に搭載されたアプリケーションに対する各ユーザの利用状況に関連するログが蓄積されている。利用実績情報記憶部１７には、各ユーザの利用状況が解析されることによって得られる利用実績に関する情報が記憶される。
【００１８】
認証処理部１１は、ログイン画面から入力されたユーザＩＤ及びパスワードを、認証情報記憶部１４に登録されているユーザ認証情報と照合することでユーザ認証を行う。本実施の形態における認証処理部１１は、ログ解析部１８、判定部１９及び実績更新部２０を有している。ログ解析部１８は、利用ログ情報記憶部１６に蓄積されたログインユーザに関するログを解析することによって当該ユーザの利用傾向を求める。判定部１９は、ログインユーザの利用傾向と、当該ユーザの利用傾向を分析することによって得られた利用実績との対比、またサービスサーバ４ａあるいはアプリケーションの必要度と基準値との比較を行うことによりＳＳＯによるユーザ認証の可否をサービスサーバ毎アプリケーション毎に判定する。実績更新部２０は、判定部１９が判定を行う過程で得た利用実績情報により利用ログ情報記憶部１６に記憶されている当該ユーザの利用実績情報を更新する。利用状況収集部１２は、ＳＳＯサーバ１０にログインした各ユーザの利用状況をログとして利用ログ情報記憶部１６に逐次記録する。制御部１３は、ＳＳＯサーバ１０における各構成要素１１，１２の制御を行う。
【００１９】
図２は、本実施の形態におけるＳＳＯサーバ１０のハードウェア構成図である。本実施の形態においてＳＳＯサーバ１０を形成するサーバコンピュータは、従前から存在する汎用的なハードウェア構成で実現できる。すなわち、コンピュータは、図２に示したようにＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、ハードディスクドライブ（ＨＤＤ）２４を接続したＨＤＤコントローラ２５、入力手段として設けられたマウス２６とキーボード２７、及び表示装置として設けられたディスプレイ２８をそれぞれ接続する入出力コントローラ２９、通信手段として設けられたネットワークコントローラ３０を内部バス３１に接続して構成される
【００２０】
なお、性能的に差異はあるかもしれないが、サービスサーバ４、更にはクライアント２もコンピュータであることから、そのハードウェア構成は、図２と同じように図示することができる。
【００２１】
ＳＳＯサーバ１０における各構成要素１１〜１３は、ＳＳＯサーバ１０に搭載されたコンピュータと、コンピュータに搭載されたＣＰＵ２１で動作するプログラムとの協調動作により実現される。また、各記憶部１４〜１７は、ＳＳＯサーバ１０に搭載されたＨＤＤ２４にて実現される。
【００２２】
また、本実施の形態で用いるプログラムは、通信手段により提供することはもちろん、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体に格納して提供することも可能である。通信手段や記録媒体から提供されたプログラムはコンピュータにインストールされ、コンピュータのＣＰＵがインストールプログラムを順次実行することで各種処理が実現される。
【００２３】
図３は、本実施の形態における利用ログ情報記憶部１６に蓄積されるログ情報のデータ構成例を示した図である。ログ情報は、サービスサーバ４へのアクセスを開始した日時情報（アクセス日時）、サービスサーバ４へアクセスした際に用いたクライアント２の識別情報（アクセス端末）、サービスサーバ４が提供するサービスシステムの名称（サービス名）及びアクセスをしたユーザの識別情報（ユーザＩＤ）が対応付けして構成される。もちろん、ログ情報には、その他のデータ項目も含めてもよいが、図３には、本実施の形態の説明上必要な項目を抽出して図示した。
【００２４】
従来のＳＳＯサーバにおけるユーザ認証においては、認証を受けたユーザはアクセスが許可されている全てのサービスサーバに対して個々にユーザ認証を受けなくてもアクセスすることが可能になる。これに対し、本実施の形態においては、当該ユーザの各サービスサーバ４に対する利用状況、更にアプリケーションの利用状況に応じてＳＳＯを許可することによってユーザ認証を省略可能にしたり、ＳＳを許可しないことによってサービスサーバ４等の利用の都度ユーザ認証を要求したりする。本実施の形態において特徴的なことは、ＳＳＯを一律的に有効にするのではなく、ユーザの利用状況によって、具体的には過去の利用実績から頻繁に利用するサービスサーバ４やアプリケーションに関してはＳＳＯを許可し、あまり利用しないサービスサーバ４やアプリケーションに関してはＳＳＯを禁止するようにしたことである。このように、ユーザの利用状況に応じてＳＳＯの可否を分けて取り扱うようにしたので、セキュリティ性の維持とＳＳＯの利便性の双方を効果的に満たすことができる。
【００２５】
次に、本実施の形態における認証処理について図４に示したフローチャートを用いて説明する。
【００２６】
ユーザがクライアント２を用いてＳＳＯサーバ１０にアクセスすると、ＳＳＯサーバ１０は、ログイン画面をクライアント２に表示させてログインを要求する。ユーザが表示されたログイン画面からユーザＩＤ及びパスワードを入力すると、ＳＳＯサーバ１０における認証処理部１１は、その入力された認証情報を受け付ける（ステップ１１０）。そして、認証処理部１１は、入力された認証情報を、認証情報記憶部１４に登録されているユーザ認証情報と照合することによって当該ユーザを認証する。なお、ここでは、正規のユーザが正しい認証情報を入力したものとして説明する。正しくない認証情報が入力された場合は認証情報の再入力を促すなど従前と同様に対処すればよい。続いて、認証処理部１１におけるログ解析部１８は、利用ログ情報記憶部１６に蓄積されたログインユーザに関するログを解析することによって週、月などの所定期間内における当該ユーザの利用傾向を得る。この利用傾向についてここで詳述する。
【００２７】
図３に例示したように、ログ情報として、アクセス日時、アクセス端末、サービス名及びユーザＩＤの各データ項目が収集されている。ここで、まずアクセス日時に注目して分析してみると、ログインしたユーザは、毎週決まった曜日に当該システムを利用している、毎日利用している、特定の月に利用している、ある特定の時間帯に集中して利用している、などの利用傾向を得ることが可能である。また、アクセス端末に注目して分析してみると、ログインしたユーザは、特定の決まった端末からのアクセスがある、同じドメインからアクセスしている、などの利用傾向を得ることが可能である。更にサービス名に注目して分析してみると、ログインしたユーザは、特定のサービスのみ利用しているなどの利用傾向を得ることが可能である。また、これらを組み合わせて分析してみると、ログインしたユーザは、あるシステムに関しては、特定の曜日・日・月に利用している、特定のアクセス端末からある時間帯に利用している、などの利用傾向を得ることが可能である。
【００２８】
更に、サービスサーバ毎からアプリケーション毎まで落とし込んだ利用傾向を得るようにしてもよい。本実施の形態では、これをアプリケーション間の依存度と称している。例えば、ＳＳＯサーバ１０で管理可能なサービスに勤怠管理システムと工数管理システムが含まれているとする。そして、ほとんどのユーザが勤怠管理システムを利用して勤怠を入力した後に工数管理システムを利用して工数を入力する傾向にあるとする。つまり、勤怠管理システムを提供するサービスサーバ４が利用された後に工数管理システムを提供するサービスサーバ４が利用される傾向がある場合、これらのサービスは依存関係のあるサービス関係として利用実績情報記憶部１７に事前に登録しておく。これにより、勤怠管理システムがＳＳＯによる認証を許可する場合には工数管理システムも同じくＳＳＯによる認証を許可するように設定しておくことは、ユーザにとって都合が良い。
【００２９】
また、このようなユーザの利用に依存しない処理の工程の流れから導き出すこと以外に、前述したログの解析を行うことによって、例えば、あるユーザは、あるサービスサーバ４が提供するサービスＡを利用した後は他のサービスサーバ４が提供するサービスＢを利用する傾向にあるというというユーザに特化した利用傾向を導き出す。
【００３０】
利用傾向の強弱は、アプリケーション間の依存度によって表すことができる。依存度は、有り／無しという表現や、数値で表現可能とする。数値で表現可能な場合の例として数値が低いほど依存度が弱く、高いほど依存度が強いと設定する。例えば、サービスＡを利用した後にサービスＢを利用するユーザが１００人に達していれば、サービスＡ，Ｂの依存度は１、２００人に達していれば、サービスＡ，Ｂの依存度は２、とサービス間の依存度を定義できる。また、依存度が数値で表されている場合でも、基準値情報記憶部１５に事前に設定されている依存度の基準値（閾値）と比較することによって依存度を有り／無しと置換することも可能になる。
【００３１】
以上のように、ログ解析部１８がログインユーザ及び当該ユーザが利用するシステム環境に関連した利用傾向を得ると、判定部１９は、利用実績情報記憶部１７から当該ユーザの利用実績情報を取得する（ステップ１３０）。ここで、ユーザの利用実績というのは、ユーザの利用傾向を解析した結果として得られる情報である。利用実績としては、例えば、過去Ｘヶ月間におけるシステムAへのアクセス日数がＺ％以上である、１日におけるＸ時〜Ｙ時という時間帯におけるアクセスはＺ％以上である、などのように表現し、その分析結果は数値化して百分率（％）で表現できるように求める。ただ、情報量（サンプル数）が少ないうちは、分析結果の精度は必ずしも高いとは言えないので、一定のアクセス件数を要件としてもよい。
【００３２】
まず、判定部１９は、ログ解析部１８が求めた利用傾向が利用実績と合致しているか否かを判定する。例えば、利用傾向が、サービスＡに対するアクセスは月曜日に集中しＺ％以上である、という利用実績に該当するか否かを判別する。利用傾向が利用実績と合致している場合（ステップ１４０でＹ）、判定部１９は、ログインユーザをＳＳＯによる認証を許可すると判定する。これにより、認証処理部１１は、その判定結果に従って該当するサービスサーバ４及びアプリケーションにＳＳＯの許可を設定する（ステップ１５０）。つまり、上記例によるとサービスＡを提供するサービスサーバ４及びサービスＡのアプリケーションに対して、ＳＳＯを有効とする、すなわちＳＳＯサーバ１０へのログインによってサービスＡのアプリケーションを利用する際にユーザ認証を要求しないことになる。なお、ステップ１４０における利用傾向と利用実績との対比は、利用実績として登録されている数だけ行われる。
【００３３】
一方、利用傾向が利用実績と合致していない場合（ステップ１４０でＮ）、判定部１９は、続いて必要度と基準値とを比較する。ここで、必要度というのは、ＳＳＯを許可する必要性の度合いである。利用傾向が利用実績に合致すると、利用実績の％が上がり、この結果、必要度は上昇する。一方、利用傾向が利用実績に合致しないと、利用実績の％が下がるため必要度は減少する。ただ、外出や休暇を取ることによって必然的に必要度が低くなってしまう場合を考慮して、利用傾向が利用実績に合致しない場合でも、必要度に対して設定された基準値を必要度が上回っていればＳＳＯを許可する。数値例をあげて説明すると、サービスＡに対するアクセスは月曜日に集中しＺ（＝９０）％以上である、という利用実績に対し、必要度の基準値として８０％が設定されているとする。今までのサービスＡに対する月曜日の利用傾向が９２％で利用実績を満たしていたものの、祭日や振替休日でサービスＡにアクセスしなかったことで、利用傾向が８６％と下がり利用実績を満たさなくなったとする。このような場合に、利用傾向（８６％）が利用実績（９０％）を合致しなくなったとしても基準値（８０％）は満たす関係にある。
【００３４】
従って、必要度と基準値とを比較した結果、必要度が基準値以上である場合（ステップ１７０でＹ）、判定部１９は、ログインユーザをＳＳＯによる認証を許可すると判定する。これにより、認証処理部１１は、その判定結果に従って該当するサービスサーバ４及びアプリケーションにＳＳＯの許可を設定する（ステップ１５０）。
【００３５】
一方、必要度が基準値を下回った場合（ステップ１７０でＮ）、判定部１９は、ログインユーザをＳＳＯによる認証を禁止すると判定する。これにより、認証処理部１１は、その判定結果に従って該当するサービスサーバ４及びアプリケーションにＳＳＯの禁止を設定する（ステップ１５０）。すなわち、当該サービスサーバ４やアプリケーションを利用する際には、ユーザ認証を要求することになる。このユーザ認証が改めて要求されるサービスサーバ４及びアプリケーションは、当該ユーザが本来利用していない、若しくはほとんど利用していない。このようなサービスサーバ４等が利用されようとしているのは、正規ユーザによる利用かもしれないけれども利用実績からして正規ユーザでない可能性が相対的に高いと考えられる。このため、本実施の形態では、ＳＳＯサーバ１０の管理対象といえどもＳＳＯを禁止することによってセキュリティの維持を図ることを優先した。
【００３６】
以上のようにＳＳＯの許可又は禁止を設定した後、実績更新部２０は、利用傾向を現時点における当該ユーザの利用実績に反映させることによって利用実績情報記憶部１７に記憶されている当該ユーザの利用実績情報を更新する（ステップ１６０）。
【００３７】
以上説明したように、本実施の形態では、管理対象のサービスサーバ４及びアプリケーションに対してＳＳＯを一律に許可するのではなく、利用状況に応じてＳＳＯの許可／禁止を動的に設定する。仮に、ＳＳＯが禁止されたことでサービスサーバ４等を利用する度にユーザ認証が要求されていたとしても当該サービスサーバ４等を繰り返し利用し続ければ必要度が増加するので、いずれＳＳＯが許可されることになる。従って、管理者等がＳＳＯの許可／禁止を個別に設定する必要はない。
【図面の簡単な説明】
【００３８】
【図１】本発明に係るシングルサインオンサーバの一実施の形態を含むネットワークシステムの全体構成図である。
【図２】本実施の形態におけるＳＳＯサーバ１０のハードウェア構成図である。
【図３】本実施の形態における利用ログ情報記憶部１６に蓄積されるログのデータ構成例を示した図である。
【図４】本実施の形態における認証処理を示したフローチャートである。
【符号の説明】
【００３９】
２ クライアント、４ サービスサーバ、６ ネットワーク、１０ ＳＳＯサーバ、１１ 認証処理部、１２ 利用状況収集部、１３ 制御部、１４ 認証情報記憶部、１５ 基準値情報記憶部、１６ 利用ログ情報記憶部、１７ 利用実績情報記憶部、１８ ログ解析部、１９ 判定部、２０ 実績更新部、２１ ＣＰＵ、２２ ＲＯＭ、２３ ＲＡＭ、２４ ハードディスクドライブ（ＨＤＤ）、２５ ＨＤＤコントローラ、２６ マウス、２７ キーボード、２８ ディスプレイ、２９ 入出力コントローラ、３０ ネットワークコントローラ、３１ 内部バス。
【特許請求の範囲】
【請求項１】
ユーザにサービスを提供するサービスサーバそれぞれに対する各ユーザの利用状況を記憶する利用ログ情報記憶手段と、
当該ユーザの前記サービスサーバの利用実績に関する情報を記憶する利用実績情報記憶手段と、
ユーザがログインしたときに、当該ユーザの利用ログ情報から得られる利用傾向と当該ユーザの利用実績とを比較した結果に応じてシングルサインオンによるユーザ認証の可否を前記サービスサーバ毎に判定する判定手段と、
前記判定手段により認証可と判定されたサービスサーバに対してのみ当該ユーザにシングルサインオンによるユーザ認証を行う認証手段と、
を有することを特徴とするシングルサインオンサーバ。
【請求項２】
請求項１記載のシングルサインオンサーバにおいて、
シングルサインオンによるユーザ認証の可否の判定に用いる基準値を記憶する基準値記憶手段を有し、
前記判定手段は、当該ユーザの利用傾向と当該ユーザの利用実績とを比較した結果、シングルサインオンによるユーザ認証を否と判定した場合でも、当該ユーザの利用実績が前記基準値に達している場合にはシングルサインオンによるユーザ認証を可と判定することを特徴とするシングルサインオンサーバ。
【請求項３】
請求項１記載のシングルサインオンサーバにおいて、
前記利用実績情報記憶手段には、当該ユーザの前記サービスサーバ毎アプリケーション毎の利用実績に関する情報が記憶されており、
前記判定手段は、前記サービスサーバに搭載されたアプリケーション毎にシングルサインオンによるユーザ認証の可否を判定することを特徴とするシングルサインオンサーバ。
【請求項４】
請求項１記載のシングルサインオンサーバにおいて、
前記判定手段は、当該ユーザの利用傾向が当該ユーザの利用実績と合致した場合にシングルサインオンによるユーザ認証を可と判定することを特徴とするシングルサインオンサーバ。
【請求項５】
請求項１記載のシングルサインオンサーバにおいて、
前記判定手段による当該ユーザの利用傾向を前記利用実績情報記憶手段に記憶された当該ユーザの利用実績情報に反映させることで更新する更新手段を有することを特徴とするシングルサインオンサーバ。
【請求項６】
コンピュータを、
ユーザにサービスを提供するサービスサーバそれぞれに対する各ユーザの利用状況を記憶する利用ログ情報記憶手段、
当該ユーザの前記サービスサーバの利用実績に関する情報を記憶する利用実績情報記憶手段、
ユーザがログインしたときに、当該ユーザの利用ログ情報から得られる利用傾向と当該ユーザの利用実績とを比較した結果に応じてシングルサインオンによるユーザ認証の可否を前記サービスサーバ毎に判定する判定手段、
前記判定手段により認証可と判定されたサービスサーバに対してのみ当該ユーザにシングルサインオンによるユーザ認証を行う認証手段、
として機能させることを特徴とするシングルサインオンプログラム。
【請求項１】
ユーザにサービスを提供するサービスサーバそれぞれに対する各ユーザの利用状況を記憶する利用ログ情報記憶手段と、
当該ユーザの前記サービスサーバの利用実績に関する情報を記憶する利用実績情報記憶手段と、
ユーザがログインしたときに、当該ユーザの利用ログ情報から得られる利用傾向と当該ユーザの利用実績とを比較した結果に応じてシングルサインオンによるユーザ認証の可否を前記サービスサーバ毎に判定する判定手段と、
前記判定手段により認証可と判定されたサービスサーバに対してのみ当該ユーザにシングルサインオンによるユーザ認証を行う認証手段と、
を有することを特徴とするシングルサインオンサーバ。
【請求項２】
請求項１記載のシングルサインオンサーバにおいて、
シングルサインオンによるユーザ認証の可否の判定に用いる基準値を記憶する基準値記憶手段を有し、
前記判定手段は、当該ユーザの利用傾向と当該ユーザの利用実績とを比較した結果、シングルサインオンによるユーザ認証を否と判定した場合でも、当該ユーザの利用実績が前記基準値に達している場合にはシングルサインオンによるユーザ認証を可と判定することを特徴とするシングルサインオンサーバ。
【請求項３】
請求項１記載のシングルサインオンサーバにおいて、
前記利用実績情報記憶手段には、当該ユーザの前記サービスサーバ毎アプリケーション毎の利用実績に関する情報が記憶されており、
前記判定手段は、前記サービスサーバに搭載されたアプリケーション毎にシングルサインオンによるユーザ認証の可否を判定することを特徴とするシングルサインオンサーバ。
【請求項４】
請求項１記載のシングルサインオンサーバにおいて、
前記判定手段は、当該ユーザの利用傾向が当該ユーザの利用実績と合致した場合にシングルサインオンによるユーザ認証を可と判定することを特徴とするシングルサインオンサーバ。
【請求項５】
請求項１記載のシングルサインオンサーバにおいて、
前記判定手段による当該ユーザの利用傾向を前記利用実績情報記憶手段に記憶された当該ユーザの利用実績情報に反映させることで更新する更新手段を有することを特徴とするシングルサインオンサーバ。
【請求項６】
コンピュータを、
ユーザにサービスを提供するサービスサーバそれぞれに対する各ユーザの利用状況を記憶する利用ログ情報記憶手段、
当該ユーザの前記サービスサーバの利用実績に関する情報を記憶する利用実績情報記憶手段、
ユーザがログインしたときに、当該ユーザの利用ログ情報から得られる利用傾向と当該ユーザの利用実績とを比較した結果に応じてシングルサインオンによるユーザ認証の可否を前記サービスサーバ毎に判定する判定手段、
前記判定手段により認証可と判定されたサービスサーバに対してのみ当該ユーザにシングルサインオンによるユーザ認証を行う認証手段、
として機能させることを特徴とするシングルサインオンプログラム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２００９−９３５９６（Ｐ２００９−９３５９６Ａ）
【公開日】平成２１年４月３０日（２００９．４．３０）
【国際特許分類】
【出願番号】特願２００７−２６６３２３（Ｐ２００７−２６６３２３）
【出願日】平成１９年１０月１２日（２００７．１０．１２）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
【公開日】平成２１年４月３０日（２００９．４．３０）
【国際特許分類】
【出願日】平成１９年１０月１２日（２００７．１０．１２）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
[ Back to top ]