権限委譲システム、権限委譲方法、情報処理装置、及びプログラム
【課題】権限の委譲が無駄になる事態を極力回避することを目的とする。
【解決手段】処理依頼部と、権限委譲部と、管理部と、を有する権限委譲システムにおいて、処理依頼部は、ユーザが操作するユーザ装置からの処理の依頼に応答して、処理の内容を表す処理情報を含むリクエストを生成する生成手段を有し、権限委譲部は、生成手段で生成されたリクエストを受け取り、リクエストに基づいて、処理情報を含むリクエストを管理部に送信する送信手段を有し、管理部は、送信手段で送信されたリクエストを受け取り、リクエストに含まれる処理情報より管理部で処理を実行可能であるか否かを判断する判断手段を有し、権限委譲部は、判断手段により実行可能であると判断された場合、管理部に対するユーザの権限を処理依頼部に委譲すると決定する決定手段を更に有することによって課題を解決する。
【解決手段】処理依頼部と、権限委譲部と、管理部と、を有する権限委譲システムにおいて、処理依頼部は、ユーザが操作するユーザ装置からの処理の依頼に応答して、処理の内容を表す処理情報を含むリクエストを生成する生成手段を有し、権限委譲部は、生成手段で生成されたリクエストを受け取り、リクエストに基づいて、処理情報を含むリクエストを管理部に送信する送信手段を有し、管理部は、送信手段で送信されたリクエストを受け取り、リクエストに含まれる処理情報より管理部で処理を実行可能であるか否かを判断する判断手段を有し、権限委譲部は、判断手段により実行可能であると判断された場合、管理部に対するユーザの権限を処理依頼部に委譲すると決定する決定手段を更に有することによって課題を解決する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、権限委譲システム、権限委譲方法、情報処理装置、及びプログラムに関する。
【背景技術】
【０００２】
従来、あるユーザの保護されたリソースへのアクセス権限を、他の主体に委譲する方法が提案されている。例えば、委譲先の主体が他のユーザである場合の方法が提案されている（特許文献１参照）。これは、予め権限の委譲元のユーザがリソースを保護している対象に認証を受け、その際、委譲のための認証チケットが発行され、それを権限の委譲先のユーザに譲渡することによって実現しているものである。また、ＩＥＴＦにおいて、Ｗｅｂの保護リソースに対する認可の定義であるＷＲＡＰの一部として、ユーザの保護リソースに対するアクセス権限を、他の主体に対して委譲するプロトコルが検討されている。なお、ＩＥＴＦは、The Internet Engineering Task Forceの略称であり、ＷＲＡＰは、OAuth Web Resource Authorization Profilesの略称である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−２２１５０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来の権限委譲方法では、権限が委譲された後に、委譲を受けた主体のリソースへのアクセスが拒否され、結果的に権限を委譲することが無駄になる事態が生じ得る。
例えば、文書を生成するサービス（文書生成サービス）と、その文書の登録を受けて印刷するサービス（印刷管理サービス）とが連携する場合に、これらサービスを利用するユーザの権限を委譲するケースが考えられる。文書生成サービスが印刷管理サービスに文書を登録する場合は、ユーザが持つ文書を登録する権限を文書生成サービスに委譲する必要がある。
このとき、従来の技術では、印刷管理サービスが文書を登録する前にユーザに対して権限の委譲の確認を行い、権限が委譲されたことを証明するトークンが発行される。そして、発行されたトークンを利用して文書生成サービスは、印刷管理サービスに文書を登録する。しかしながら、印刷管理サービスにおいて、印刷ができないフォーマットの文書であることを理由に登録を拒否することがある。また、委譲されたユーザの権限では印刷可能なプリンタが無い可能性もある。その結果、印刷管理サービスが文書生成サービスに権限を委譲することが無駄になってしまうという問題がある。
【０００５】
本発明はこのような問題点に鑑みなされたもので、権限の委譲が無駄になる事態を極力回避することを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明に係る権限委譲システムは、処理依頼部と、権限委譲部と、管理部と、を有する権限委譲システムであって、前記処理依頼部は、ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成手段を有し、前記権限委譲部は、前記生成手段で生成されたリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記管理部に送信する送信手段を有し、前記管理部は、前記送信手段で送信されたリクエストを受け取り、前記リクエストに含まれる処理情報より前記管理部で前記処理を実行可能であるか否かを判断する判断手段を有し、前記権限委譲部は、前記判断手段により実行可能であると判断された場合、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲すると決定する決定手段を更に有することを特徴とする。
【０００７】
また、本発明に係る権限委譲方法は、例えば、処理依頼部と、権限委譲部と、管理部と、を有する権限委譲システムにおける権限委譲方法であって、前記処理依頼部が、ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成工程と、前記権限委譲部が、前記生成工程で生成されたリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記管理部に送信する送信工程と、前記管理部が、前記送信工程で送信されたリクエストを受け取り、前記リクエストに含まれる処理情報より前記管理部で前記処理を実行可能であるか否かを判断する判断工程と、前記権限委譲部が、前記判断工程により実行可能であると判断された場合、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲すると決定する決定工程とを有することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、権限の委譲が無駄になる事態を極力回避することができる。
【図面の簡単な説明】
【０００９】
【図１】権限委譲システムの構成の一例を示す図である。
【図２】情報処理装置のハードウェア構成の一例を示す図である。
【図３】文書生成サービス部の構成の一例を示す図である。
【図４】認証サービス部の構成の一例を示す図である。
【図５】印刷管理サービス部の構成の一例を示す図である。
【図６】ユーザ認証情報、ユーザトークン情報の一例を示す図である。
【図７】文書情報の一例を示す図である。
【図８】プリンタ情報、プリンタ能力情報の一例を示す図である。
【図９】権限情報の一例を示す図である。
【図１０】文書生成出力処理に係るフローチャートの一例を示す図である。
【図１１】トークン生成処理に係るフローチャートの一例を示す図である。
【図１２】確認処理に係るフローチャートの一例を示す図である。
【図１３】許可確認画面の一例を示す図である。
【図１４】確認処理に係るフローチャートの一例を示す図である。
【図１５】許可確認画面の一例を示す図である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施形態について図面に基づいて説明する。
【００１１】
図１は、本実施形態に係る権限委譲システムの構成の一例を示す図である。本実施形態では、権限委譲システムとして、ＷＷＷ（World Wide Web）システムを採用した場合を例に挙げて説明をする。権限委譲システムでは、外部ネットワークの一例であるＷＡＮ（Wide Area Network）１０、内部ネットワークの一例であるＬＡＮ（Local Area Network）１１等を介して複数の装置が互いに接続されている。
クライアント１２は、情報処理装置（コンピュータ）の一例であり、ＷＷＷを参照可能なＷｅｂブラウザを有するクライアント端末である。クライアント１２は、ＬＡＮ１１及びＷＡＮ１０を介して文書生成サーバ１３、認証サーバ１４、及び印刷管理サーバ１５等の各サーバに対してＷｅｂリクエスト（リクエスト）を発行する。
文書生成サーバ１３、認証サーバ１４、及び印刷管理サーバ１５は、情報処理装置の一例であり、クライアント１２からの処理の依頼などを表すリクエストを受け付けるＷｅｂサーバである。文書生成サーバ１３は、クライアント１２からのリクエストに従って文書（文書情報）を生成する。認証サーバ１４は、クライアント１２からのリクエストに従って認証を行う（クライアント１２を操作しているユーザの利用資格を確認する）。印刷管理サーバ１５は、クライアント１２からのリクエストに従って、指定された文書の指定されたプリンタ１６への印刷を管理する。プリンタ１６は、画像形成装置の一例であり、文書を印刷する。なお、プリンタ１６は、印刷管理サーバ１５に登録され、管理されている。
【００１２】
図２は、クライアント１２、文書生成サーバ１３、認証サーバ１４、及び印刷管理サーバ１５として採用し得る情報処理装置のハードウェア構成の一例を示す図である。ＣＰＵ２１は、内部バスで接続される各デバイス（ＲＯＭ２２、ＲＡＭ２３等）を直接、或いは間接的に制御し、各種のプログラムを実行する。ＲＯＭ２２は、ＢＩＯＳプログラム等を格納する。ＲＡＭ２３は、直接記憶装置の一例であり、ＣＰＵ２１のワーク領域として利用される。また、ＲＡＭ２３は、各種のソフトウェアモジュールの一時記憶として利用される。
ＨＤＤ２４は、間接記憶装置の一例であり、基本ソフトウェアであるＯＳやソフトウェアモジュールのプログラム等を記憶する。なお、ＨＤＤ２４は、ＳＳＤ（ソリッドステートドライブ）などであってもよい。入力装置２５は、キーボードやポインティングデバイスなどである。出力装置２６は、ディスプレイなどである。Ｉ／Ｆ２７は、ＬＡＮ１１、ＷＡＮ１０などに接続された装置とのデータの通信を制御する。
【００１３】
これらのハードウェアでは、情報処理装置の起動後に、ＣＰＵ２１によりＢＩＯＳプログラムが実行され、ＯＳプログラムがＨＤＤ２４からＲＡＭ２３に実行可能にロードされる。ＣＰＵ２１は、ＯＳの動作に従って各種のソフトウェアモジュールのプログラムをＨＤＤ２４からＲＡＭ２３に随時、実行可能にロードする。各種のソフトウェアモジュールは、ＣＰＵ２１等のデバイスの協調により動作する。すなわち、ＣＰＵ２１が、ＨＤＤ２４に格納されたプログラムの手順に従って処理を行うことによって、情報処理装置における機能及び後述するフローチャートに係る処理が実現される。
また、Ｉ／Ｆ２７は、ＬＡＮ１１に接続されており、ＯＳの動作に従ってＣＰＵ２１により制御され、各情報処理装置が有する後述のサービス部間のリクエストの送受信を行う。また、Ｉ／Ｆ２７は、ＬＡＮ１１を介してＷＡＮ１０に接続されており、ＯＳの動作に従ってＣＰＵ２１により制御され、ＷＷＷシステムにおける通信を可能にする。
【００１４】
図３は、文書生成サーバ１３において動作する文書生成サービス部３０の構成の一例を示す図である。文書生成サービス部３０は、処理依頼部の一例であり、Ｗｅｂアプリケーション部３１、文書生成部３２、データ取得部３３、及び文書出力部３４を含んで構成される。
Ｗｅｂアプリケーション部３１は、クライアント１２からのリクエストを受け付けるＷｅｂインタフェースを有する。Ｗｅｂアプリケーション部３１は、クライアント１２が有するＷｅｂブラウザからのリクエストに対して、文書の生成を要求するための画面（文書生成画面）を生成して応答する。
文書生成部３２は、クライアント１２において文書生成画面を介して生成された文書生成リクエストをＷｅｂアプリケーション部３１で受け付けられたと判断した場合は、文書を生成する。このとき、文書生成部３２は、予め設定されたロジックに従って文書を生成するが、その際、必要に応じてデータ取得部３３を介して不図示の他のサービス部からデータを取得する。また、生成された文書は、不図示のファイルシステムに保存され管理される。そして、Ｗｅｂアプリケーション部３１は、文書が生成されたと判断した場合、文書の出力を要求するための画面（文書出力画面）を生成してクライアント１２に送信する。
【００１５】
また、Ｗｅｂアプリケーション部３１は、クライアント１２において文書出力画面を介して生成された文書出力リクエストを受け付けた場合は、生成された文書を文書生成部３２及び文書出力部３４を介して他のサービス部に対して出力する。
なお、Ｗｅｂアプリケーション部３１は、クライアント１２からのリクエストに対して、文書を生成して出力を要求するための画面（文書生成出力画面）を生成してもよい。この場合、Ｗｅｂアプリケーション部３１は、クライアント１２において文書生成出力画面を介して生成された文書生成出力リクエストを受けた場合は、文書生成部３２にて生成された文書を、文書出力部３４を介して他のサービス部に対して出力する。
【００１６】
図４は、認証サーバ１４において動作する認証サービス部４０の構成の一例を示す図である。認証サービス部４０は、権限委譲部の一例であり、認証アプリケーション部４１、認証部４２、データベース４３、及びサービスアクセス部４４を含んで構成される。
認証アプリケーション部４１は、クライアント１２からのリクエストを受け付けるＷｅｂインタフェースを有する。認証アプリケーション部４１は、クライアント１２が有するＷｅｂブラウザからのＷｅｂリクエストに対して認証画面を生成して応答する。
認証部４２は、クライアント１２において認証画面を介して生成された認証リクエストが認証アプリケーション部４１で受け付けられたと判断した場合、認証処理を行う。このとき、例えば、認証部４２は、認証が成功したと判断した場合、認証トークンを生成し、認証アプリケーション部４１は、認証部４２で生成された認証トークンを、認証アプリケーション部４１を介してクライアント１２に送信する。
【００１７】
認証部４２は、予め設定されたロジックに従って認証処理を行うが、その際、データベース４３にアクセスし、予め登録されているユーザ認証情報とマッチングを行う。例えば、認証部４２は、認証リクエストに含まれる、ユーザを特定するユーザＩＤと秘匿情報の一例であるパスワードとの組み合わせをユーザ認証情報とマッチングし、認証の成否を判断する。
なお、本実施形態では、認証の方式として、認証部４２が、クライアント１２からの認証リクエストに含まれる、ユーザＩＤ、及びパスワードの情報を取得し、予め登録されたユーザ認証情報とマッチングする方式を採用している。しかしながら、本実施形態の認証の方式は、上述した認証の方式に限られるものではない。例えば、他の認証の方式として、証明書を確認することにより認証する方式や、ユーザの生体情報を確認することにより認証する方式を採用してもよい。
【００１８】
サービスアクセス部４４は、他のサービス部からリクエストを受け付けると共に、他のサービス部にリクエストを送信する。他のサービス部から受け付けるリクエストとしては、要求された処理を行う権限が委譲されたこと（権限委譲）を証明するトークンの取得を要求するトークン取得リクエスト、トークンの有効性を確認するためのトークン確認リクエストがある。また、他のサービス部に送信する要求としては、トークン取得リクエストに他のサービス部への確認項目が含まれる場合に送信されるサービス確認リクエストがある。また、認証の方式がリバースプロキシ方式である場合は、サービスアクセス部４４は、他のサービス部の入り口として認証をハンドリングし、認証の結果に応じて他のＷｅｂアプリケーションを呼び出す。サービスアクセス部４４で受信したリクエストは、主に認証部４２で処理されるが、詳細は後述する。
【００１９】
図５は、印刷管理サーバ１５において動作する印刷管理サービス部５０の構成の一例を示す図である。印刷管理サービス部５０は、管理部の一例であり、Ｗｅｂアプリケーション部５１、印刷管理部５２、文書管理部５３、文書データベース５４、プリンタ管理部５５、プリンタデータベース５６、及びサービスアクセス部５７を含んで構成される。
Ｗｅｂアプリケーション部５１は、クライアント１２からのリクエストを受け付けるＷｅｂインタフェースを有する。Ｗｅｂアプリケーション部５１は、クライアント１２が有するＷｅｂブラウザからのリクエストに対して、指定のプリンタ１６での指定の文書の印刷を要求するための印刷指示画面を生成して応答する。
その際、認証の方式がリバースプロキシ方式である場合は、Ｗｅｂアプリケーション部５１は、クライアント１２からリクエストを直接受けず、認証サービス部４０にて認証されたユーザ情報が付与されたリクエストを認証サービス部４０から受け付ける。また、例えば、認証の方式がエージェント方式である場合は、Ｗｅｂアプリケーション部５１に認証エージェントがアドインされ、クライアント１２からのリクエストは、認証エージェントで受け付けられて認証サービス部４０に転送される。認証サービス部４０では、認証が成功すると、認証したユーザ情報を付与したリクエストを、認証エージェントを介してＷｅｂアプリケーション部５１に送信する。
【００２０】
また、Ｗｅｂアプリケーション部５１は、印刷指示画面を生成する際に印刷管理部５２にユーザ情報を送信してプリンタや文書の情報を取得する。このとき、印刷管理部５２は、プリンタ管理部５５を介してプリンタ情報を取得し、文書管理部５３を介して文書情報を取得する。プリンタ管理部５５では、プリンタデータベース５６で管理されているプリンタ情報を取得するが、その際、プリンタデータベース５６で管理されているユーザの権限情報に従って参照可能なプリンタ情報のみを抽出して印刷管理部５２に応答する。文書管理部５３では、文書データベース５４で管理されている文書情報を取得するが、その際、文書データベース５４で管理されているユーザの権限情報に従って参照可能な文書情報のみを抽出して印刷管理部５２に応答する。
【００２１】
印刷管理部５２は、クライアント１２において印刷指示画面を介して生成された印刷リクエストがＷｅｂアプリケーション部５１で受け付けられたと判断した場合は、指定のプリンタに印刷処理を指示する。なお、印刷処理としては、印刷管理部５２がクライアント１２のＷｅｂブラウザを介して指定のプリンタにプルプリント指示を行うケースや、ユーザが指定のプリンタで直接プルプリントの指示を行うケースが考えられる。指定されたプリンタは、プルプリントの指示に応じて文書管理部５３に対してリクエストを行い、文書を取得して印刷を実行する。
サービスアクセス部５７は、他のサービス部からリクエストを受け付けると共に、他のサービス部にリクエストを送信する。他のサービス部から受け付けるリクエストとしては、文書の登録を受け付ける文書登録リクエスト、クライアント１２から要求された処理の成否を権限委譲の実行前に確認するためのサービス確認リクエスト等がある。また、他のサービス部に送信するリクエストとしては、トークン確認リクエスト等がある。サービスアクセス部５７で受信したリクエストは、主に印刷管理部５２で処理されるが、詳細は後述する。
【００２２】
図６は、データベース４３にて管理されているユーザ認証情報、ユーザトークン情報の一例を示す図である。ユーザ認証情報６０は、ユーザを特定可能なユーザＩＤ６０１、秘匿情報であるパスワード６０２、及びユーザの表示名であるユーザ名６０３の情報を含んで構成される。ユーザトークン情報６１は、ユーザを特定可能なユーザＩＤ６１１、及び認証されたことを示すトークン６１２の情報を含んで構成される。ユーザ認証情報６０とユーザトークン情報６１とは、ユーザＩＤによって関連付けられる。なお、ユーザ認証情報６０のうち、ユーザＩＤ６０１、ユーザ名６０３等の情報、すなわちパスワード６０２の情報を除く情報をユーザ情報と適宜称する。
【００２３】
図７は、文書データベース５４にて管理されている文書情報の一例を示す図である。文書情報７０は、文書を特定可能な文書ＩＤ７０１、文書の表示名である文書名７０２、文書のフォーマットを識別可能な文書種別７０３、文書の作成者のユーザＩＤである文書作成者７０４、及び文書データ７０５の情報を含んで構成される。文書データ７０５については、文書データのバイナリが格納されるよう構成されてもよいし、文書データ７０５を別の領域に記憶し、その記憶場所のパスを示す情報が格納されるよう構成されてもよい。
【００２４】
図８は、プリンタデータベース５６にて管理されているプリンタ情報、プリンタ能力情報の一例を示す図である。プリンタ情報８０は、プリンタを特定可能なプリンタＩＤ８０１、プリンタの表示名であるプリンタ名８０２、及びプリンタのアドレスを示すアドレス８０３の情報を含んで構成される。プリンタ能力情報８１は、プリンタを特定可能なプリンタＩＤ８１１、及びプリンタが印刷可能な文書のフォーマットの種別を示す印刷可能文書種別８１２の情報を含んで構成される。なお、印刷可能文書種別８１２は、プリンタの能力の一例である。プリンタ情報８０とプリンタ能力情報８１とは、プリンタＩＤによって関連付けられる。
【００２５】
図９は、文書データベース５４、プリンタデータベース５６で管理されている権限情報の一例を示す図である。権限情報９０は、プリンタ情報や文書情報に対するユーザの権限を格納するための情報である。権限情報９０は、主体種別９０１、主体ＩＤ９０２、許可／拒否９０３、リソース種別９０４、リソースＩＤ９０５、アクション９０６の情報を含んで構成される。例えば、あるユーザがあるプリンタに対して参照可能である権限を示す場合は、権限情報９０には以下の情報が格納される。主体種別９０１にはユーザであることを示す情報、主体ＩＤ９０２にはユーザＩＤ６０１の情報、許可／拒否９０３には許可の情報が格納される。更に、リソース種別９０４にはプリンタであること示す情報、リソースＩＤ９０５にはプリンタＩＤ８０１の情報、アクション９０６には参照することを示す情報が格納される。
【００２６】
以下では、本実施形態の各サービス部が行う処理について説明する。
図１０は、文書生成サービス部３０が文書生成出力リクエストを受けた場合の処理（文書生成出力処理）に係るフローチャートの一例を示す図である。
文書生成サービス部３０は、文書生成出力リクエストを受け付ける（Ｓ１００１）。続いて、文書生成サービス部３０は、予め設定されたロジックに従って文書を生成する（Ｓ１００２）。続いて、文書生成サービス部３０は、印刷管理サービス部５０に文書登録を行う権限が文書生成サービス部３０に委譲されたことを証明するトークンの取得を要求するトークン取得リクエストを生成する（Ｓ１００３）。トークン取得リクエストには、処理の内容を表す処理情報（確認有無情報、文書種別情報、サービス部特定情報、処理種別情報など）が含まれる。確認有無情報は、印刷管理サービス部５０への確認項目の有無を表す情報である。文書種別情報は、処理の対象を表す対象情報の一例であり、本実施形態では、登録する文書のフォーマットの種別を表す情報である。サービス部特定情報は、処理の依頼先を特定可能な特定情報の一例であり、本実施形態では、文書の登録先の印刷管理サービス部５０を特定可能な情報である。処理種別情報は、処理の種別を表す種別情報の一例であり、本実施形態では、対象の処理が文書の登録を行う処理であることを示す情報である。
【００２７】
続いて、文書生成サービス部３０は、生成したトークン取得リクエストを、クライアント１２を介して認証サービス部４０にリダイレクトし（Ｓ１００４）、トークン取得リクエストに対する応答を待つ。
ここで、認証サービス部４０は、図１１に示すトークン生成処理が終わると、クライアント１２を介してトークン取得リクエストの応答を文書生成サービス部３０にリダイレクトする。そして、文書生成サービス部３０は、トークン取得リクエストの応答を受け付ける（Ｓ１００５）。続いて、文書生成サービス部３０は、トークン取得リクエストの結果を判断し（Ｓ１００６）、トークン取得リクエストの結果が失敗（ＮＧ）であると判断した場合は、Ｓ１００９の処理を行う。他方、トークン取得リクエストの結果が成功（ＯＫ）であると判断した場合は、文書生成サービス部３０は、Ｓ１００７の処理を行う。
【００２８】
Ｓ１００７では、トークン取得リクエストに含まれるトークンを利用して印刷管理サービス部５０に文書登録リクエストを送信する。ここで、文書登録リクエストを受けた印刷管理サービス部５０は、不図示の処理にて、受け付けたトークンの有効性を認証サービス部４０に確認し、ＯＫであると判断した場合は文書登録を受け付け、文書の登録が成功した旨を文書生成サービス部３０に応答する。他方、ＮＧであると判断した場合は、印刷管理サービス部５０は、文書の登録を拒否し、文書の登録が失敗した旨を文書生成サービス部３０に応答する。続いて、文書生成サービス部３０は、文書登録リクエストの応答を受け付け（Ｓ１００８）、Ｓ１００９の処理を行う。
Ｓ１００９では、文書生成サービス部３０は、文書生成出力リクエストの結果に応答する。より具体的には、文書生成サービス部３０は、文書生成出力リクエストの結果がＮＧであると判断した場合、文書生成出力リクエストが失敗した旨を示す画面を生成してクライアント１２に送信する。また、文書生成サービス部３０は、文書生成出力リクエストの結果がＯＫであり、文書登録リクエストの結果がＯＫであると判断した場合、文書の登録が成功した旨を示す画面を生成してクライアント１２に送信する。また、文書生成サービス部３０は、文書生成出力リクエストの結果がＯＫであり、文書登録リクエストの結果がＮＧであると判断した場合、文書の登録が失敗した旨を示す画面を生成してクライアント１２に送信する。
【００２９】
図１１は、認証サービス部４０がトークン取得リクエストを受けた場合の処理（トークン生成処理）に係るフローチャートの一例を示す図である。
認証サービス部４０は、トークン取得リクエストを受け付ける（Ｓ１１０１）。続いて、認証サービス部４０は、認証サービス部４０の認証の方式に従って認証を行う（Ｓ１１０２）。続いて、認証サービス部４０は、トークン取得リクエストの内容を確認する（Ｓ１１０３）。続いて、認証サービス部４０は、他のサービス部への確認項目の有無を確認する（Ｓ１１０４）。このとき、認証サービス部４０は、トークン取得リクエストに含まれる確認有無情報が「無し」を表す情報であると判断した場合は、Ｓ１１０８の処理を行い、他方、「有り」を表す情報であると判断した場合は、Ｓ１１０５の処理を行う。
【００３０】
Ｓ１１０５では、認証サービス部４０は、対象のサービス部に対してサービス確認リクエストを送信する。より具体的には、認証サービス部４０は、文書種別情報、処理種別情報を含むサービス確認リクエストを生成し、トークン取得リクエストに含まれるサービス部特定情報に従って、印刷管理サービス部５０にサービス確認リクエストを送信する。その際、認証サービス部４０は、サービス確認リクエストにＳ１１０２にて認証したユーザ情報を追加する。続いて、認証サービス部４０は、サービス確認リクエストの応答を受け付ける（Ｓ１１０６）。なお、サービス確認リクエストを印刷管理サービス部５０に送信した際の印刷管理サービス部５０における処理については図１２を参照して詳細に説明する。
続いて、認証サービス部４０は、サービス確認リクエストの結果を判断する（Ｓ１１０７）。このとき、認証サービス部４０は、サービス確認リクエストの結果が、対象の処理を印刷管理サービス部５０で受け付けていないことを示すもの（拒否）であると判断した場合は、Ｓ１１１３の処理を行う。他方、サービス確認リクエストの結果が、対象の処理を印刷管理サービス部５０で受け付けていることを示すもの（許可）であると判断した場合は、認証サービス部４０は、Ｓ１１０８の処理を行う。
【００３１】
Ｓ１１０８では、認証サービス部４０は、対象の処理を行う権限を委譲するか否かをユーザに確認するための許可確認画面を生成する。例えば、認証サービス部４０は、サービス確認リクエストの応答の内容に従って許可確認画面を生成し、クライアント１２に送信する。図１３に、許可確認画面の一例を示す。
続いて、認証サービス部４０は、クライアント１２から許可確認画面を介して許可確認の結果を受け付ける（Ｓ１１０９）。続いて、認証サービス部４０は、許可確認の結果を判断する（Ｓ１１１０）。このとき、認証サービス部４０は、許可確認の結果が、対象の処理を行う権限の委譲を許可しないもの（拒否）であると判断した場合は、Ｓ１１１３の処理を行う。他方、許可確認の結果が、対象の処理を行う権限の委譲を許可するもの（許可）であると判断した場合は、認証サービス部４０は、Ｓ１１１１の処理を行う。すなわち、認証サービス部４０は、印刷管理サーバ１５に対するユーザの権限を文書生成サーバ１３に委譲するか否かを決定している。なお、本実施形態は、認証サービス部４０が許可確認の結果に基づいて権限を委譲するか否かを決定する構成に限られるものではない。例えば、認証サービス部４０は、サービス確認リクエストの結果が、対象の処理を印刷管理サービス部５０で受け付けていることを示すものであると判断した場合、権限を委譲すると決定する構成を採用してもよい。
【００３２】
Ｓ１１１１では、認証サービス部４０は、ユーザトークン情報などに基づいて、権限が委譲されたことを証明するトークンを生成する。続いて、認証サービス部４０は、トークン取得リクエストの成功を示すリクエストを生成し（Ｓ１１１２）、Ｓ１１１４の処理を行う。
Ｓ１１１３では、認証サービス部４０は、トークン取得リクエストの失敗を示すリクエストを生成し、Ｓ１１１４の処理を行う。
Ｓ１１１４では、認証サービス部４０は、生成したリクエスト（決定情報）を、クライアント１２を介してトークン取得リクエストの応答先（この例では、文書生成サービス部３０）にリダイレクトする。
【００３３】
図１２は、印刷管理サービス部５０がサービス確認リクエストを受けた場合の処理（確認処理）に係るフローチャートの一例を示す図である。
印刷管理サービス部５０は、サービス確認リクエストを受け付ける（Ｓ１２０１）。続いて、印刷管理サービス部５０は、処理の種別を確認する（Ｓ１２０２）。このとき、印刷管理サービス部５０は、サービス確認リクエストに含まれる処理種別情報が文書を登録することを示す情報でないと判断した場合は、サービス確認リクエストの結果として許可応答を生成し（Ｓ１２０４）、Ｓ１２１２の処理を行う。他方、処理種別情報が文書を登録することを示す情報であると判断した場合は、印刷管理サービス部５０は、Ｓ１２０５の処理を行う。
【００３４】
Ｓ１２０５では、印刷管理サービス部５０は、文書の種別を確認する。このとき、印刷管理サービス部５０は、サービス確認リクエストに含まれる文書種別情報が登録可能な文書のフォーマットの情報でないと判断した場合（Ｓ１２０６でＮＯの場合）は、Ｓ１２０７の処理を行う。他方、文書種別情報が登録可能な文書のフォーマットの情報であると判断した場合（Ｓ１２０６でＹＥＳの場合）は、印刷管理サービス部５０は、Ｓ１２０８の処理を行う。
Ｓ１２０７では、印刷管理サービス部５０は、サービス確認リクエストの結果として拒否の応答を生成し、Ｓ１２１２の処理を行う。
Ｓ１２０８では、印刷管理サービス部５０は、サービス確認リクエストに含まれるユーザ情報に対応するユーザが対象の文書のフォーマットで印刷可能なプリンタがあるかを権限情報に基づいて確認する。
【００３５】
このとき、印刷管理サービス部５０は、印刷可能なプリンタがあると判断した場合は、サービス確認リクエストの結果として印刷可能なプリンタが登録されている旨を付与した許可応答を生成し（Ｓ１２１０）、Ｓ１２１２の処理を行う。この場合、Ｓ１１０８では、例えば、図１３（１）に示す許可確認画面１３００Ａが生成される。許可確認画面１３００Ａは、サービス確認リクエストの結果が「プリンタあり」の場合の画面例である。確認メッセージ欄１３０１には、クライアント１２にて表示するメッセージ（内容）が記載され、メッセージは、サービス確認リクエストの応答の内容に従って生成される。
他方、印刷可能なプリンタが無いと判断した場合は、印刷管理サービス部５０は、サービス確認リクエストの結果として印刷可能なプリンタが登録されていない旨を付与した許可応答を生成し（Ｓ１２１１）、Ｓ１２１２の処理を行う。この場合、Ｓ１１０８では、例えば、図１３（２）に示す許可確認画面１３００Ｂが生成される。許可確認画面１３００Ｂは、サービス確認リクエストの結果が「プリンタなし」の場合の画面例であり、登録可能な文書を印刷可能なプリンタが無い旨が確認メッセージ欄１３０１に提示される。なお、許可確認画面１３００Ａ及び許可確認画面１３００Ｂの各々は、権限の委譲を許可する許可ボタン１３０２、権限の委譲を拒否する拒否ボタン１３０３を含んで構成される。
Ｓ１２１２では、印刷管理サービス部５０は、サービス確認リクエストの結果、すなわち、判断した結果の情報を含む判断情報を認証サービス部４０に送信する。
【００３６】
以上の処理により、印刷管理サービス部５０で登録ができないフォーマットの文書であると判断された場合に、権限の委譲を確認する画面にその旨を表示することで、文書の登録が無駄であるとユーザが判断した場合は、権限の移譲を拒否することが可能となる。更には、委譲されるユーザの権限では印刷可能なプリンタが無い場合に、権限の委譲を確認する画面にその旨を表示することで、印刷ができない状況での文書の登録が無駄であるとユーザが判断した場合は、権限の移譲を拒否することが可能となる。このように、ユーザは、委譲される権限をもって行う文書に係る処理の成否を、権限を委譲する前に確認し、権限の委譲の許可及び拒否を選択することができるので、権限を委譲することが無駄になることを防ぐことができる。
【００３７】
＜第２の実施形態＞
図１４は、第２の実施形態に係る印刷管理サービス部５０においてサービス確認リクエストを受けた場合の処理（確認処理）に係るフローチャートの一例を示す図である。なお、図１２と同様の処理については、同じ符号を付与して説明を省略し、以下、異なる部分を主に説明する。
印刷管理サービス部５０は、ユーザ情報に対応するユーザが対象の文書のフォーマットで印刷可能なプリンタがあるかを確認し、プリンタがないと判断した場合、Ｓ１２１１の処理を行う。他方、プリンタがあると判断した場合、印刷管理サービス部５０は、Ｓ１４０１の処理を行う（Ｓ１２０８、Ｓ１２０９）。
Ｓ１４０１では、印刷管理サービス部５０は、対象の文書のフォーマットで印刷可能なプリンタのリストを取得する。続いて、印刷管理サービス部５０は、サービス確認リクエストの結果として許可応答を生成し、取得したプリンタのリストを付与し（Ｓ１４０２）、サービス確認リクエストの結果を認証サービス部４０に送信する（Ｓ１２１２）。
【００３８】
図１５は、本実施形態に係る認証サービス部４０で生成される許可確認画面の一例を示す図である。なお、図１３と同様の構成については、同じ符号を付して説明を省略し、以下、異なる部分を主に説明する。
許可確認画面１３００Ｃは、図１４のＳ１４０２で生成されたプリンタのリストが付与されたサービス確認リクエストの応答を図１１のＳ１１０６にて受信した場合にＳ１１０８で生成される画面の例である。
【００３９】
許可確認画面１３００Ｃでは、追加メッセージ欄１５０１には対象の文書が印刷可能なプリンタがリスト形式で表示される。リスト形式で表示されたプリンタは、選択可能に構成されている。また、許可確認画面１３００Ｃには、権限の委譲を許可して印刷を実行する印刷ボタン１５０２を有している。印刷ボタン１５０２が押下された場合、認証サービス部４０は、図１１のＳ１１１１で権限が委譲されたことを証明するトークンを生成し、生成したトークンに選択されたプリンタを特定する情報を付与する。次に、認証サービス部４０は、Ｓ１１１２にてトークン取得リクエストの成功を示すリクエストを生成し、クライアント１２を介してトークン取得リクエストの応答先にリダイレクトする（Ｓ１１１４）。
【００４０】
また、文書生成サービス部３０では、図１０のＳ１００５にてプリンタを特定する情報が付与されたトークンを取得した場合は、Ｓ１００９の処理の終了後に、印刷管理サービス部５０に対して、印刷要求を実行する。
以上の処理により、権限を委譲することが無駄になることを防ぐことができると共に、ユーザの印刷指示を受ける処理を省略して文書の登録、印刷を実行することが可能になる。
【００４１】
＜その他の実施形態＞
上述した実施形態では、文書生成サービス部３０、認証サービス部４０、印刷管理サービス部５０は、それぞれ独立したサーバにホスティングする構成を採用したが、この構成に限られるものではない。例えば、１台のサーバにまとめてホスティングする構成を採用してもよいし、また、複数のサーバにクラスタリングして負荷分散を行う構成を採用してもよい。
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００４２】
上述した実施形態の構成によれば、権限の委譲が無駄になる事態を極力回避することができる。
【００４３】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【技術分野】
【０００１】
本発明は、権限委譲システム、権限委譲方法、情報処理装置、及びプログラムに関する。
【背景技術】
【０００２】
従来、あるユーザの保護されたリソースへのアクセス権限を、他の主体に委譲する方法が提案されている。例えば、委譲先の主体が他のユーザである場合の方法が提案されている（特許文献１参照）。これは、予め権限の委譲元のユーザがリソースを保護している対象に認証を受け、その際、委譲のための認証チケットが発行され、それを権限の委譲先のユーザに譲渡することによって実現しているものである。また、ＩＥＴＦにおいて、Ｗｅｂの保護リソースに対する認可の定義であるＷＲＡＰの一部として、ユーザの保護リソースに対するアクセス権限を、他の主体に対して委譲するプロトコルが検討されている。なお、ＩＥＴＦは、The Internet Engineering Task Forceの略称であり、ＷＲＡＰは、OAuth Web Resource Authorization Profilesの略称である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−２２１５０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来の権限委譲方法では、権限が委譲された後に、委譲を受けた主体のリソースへのアクセスが拒否され、結果的に権限を委譲することが無駄になる事態が生じ得る。
例えば、文書を生成するサービス（文書生成サービス）と、その文書の登録を受けて印刷するサービス（印刷管理サービス）とが連携する場合に、これらサービスを利用するユーザの権限を委譲するケースが考えられる。文書生成サービスが印刷管理サービスに文書を登録する場合は、ユーザが持つ文書を登録する権限を文書生成サービスに委譲する必要がある。
このとき、従来の技術では、印刷管理サービスが文書を登録する前にユーザに対して権限の委譲の確認を行い、権限が委譲されたことを証明するトークンが発行される。そして、発行されたトークンを利用して文書生成サービスは、印刷管理サービスに文書を登録する。しかしながら、印刷管理サービスにおいて、印刷ができないフォーマットの文書であることを理由に登録を拒否することがある。また、委譲されたユーザの権限では印刷可能なプリンタが無い可能性もある。その結果、印刷管理サービスが文書生成サービスに権限を委譲することが無駄になってしまうという問題がある。
【０００５】
本発明はこのような問題点に鑑みなされたもので、権限の委譲が無駄になる事態を極力回避することを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明に係る権限委譲システムは、処理依頼部と、権限委譲部と、管理部と、を有する権限委譲システムであって、前記処理依頼部は、ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成手段を有し、前記権限委譲部は、前記生成手段で生成されたリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記管理部に送信する送信手段を有し、前記管理部は、前記送信手段で送信されたリクエストを受け取り、前記リクエストに含まれる処理情報より前記管理部で前記処理を実行可能であるか否かを判断する判断手段を有し、前記権限委譲部は、前記判断手段により実行可能であると判断された場合、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲すると決定する決定手段を更に有することを特徴とする。
【０００７】
また、本発明に係る権限委譲方法は、例えば、処理依頼部と、権限委譲部と、管理部と、を有する権限委譲システムにおける権限委譲方法であって、前記処理依頼部が、ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成工程と、前記権限委譲部が、前記生成工程で生成されたリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記管理部に送信する送信工程と、前記管理部が、前記送信工程で送信されたリクエストを受け取り、前記リクエストに含まれる処理情報より前記管理部で前記処理を実行可能であるか否かを判断する判断工程と、前記権限委譲部が、前記判断工程により実行可能であると判断された場合、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲すると決定する決定工程とを有することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、権限の委譲が無駄になる事態を極力回避することができる。
【図面の簡単な説明】
【０００９】
【図１】権限委譲システムの構成の一例を示す図である。
【図２】情報処理装置のハードウェア構成の一例を示す図である。
【図３】文書生成サービス部の構成の一例を示す図である。
【図４】認証サービス部の構成の一例を示す図である。
【図５】印刷管理サービス部の構成の一例を示す図である。
【図６】ユーザ認証情報、ユーザトークン情報の一例を示す図である。
【図７】文書情報の一例を示す図である。
【図８】プリンタ情報、プリンタ能力情報の一例を示す図である。
【図９】権限情報の一例を示す図である。
【図１０】文書生成出力処理に係るフローチャートの一例を示す図である。
【図１１】トークン生成処理に係るフローチャートの一例を示す図である。
【図１２】確認処理に係るフローチャートの一例を示す図である。
【図１３】許可確認画面の一例を示す図である。
【図１４】確認処理に係るフローチャートの一例を示す図である。
【図１５】許可確認画面の一例を示す図である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施形態について図面に基づいて説明する。
【００１１】
図１は、本実施形態に係る権限委譲システムの構成の一例を示す図である。本実施形態では、権限委譲システムとして、ＷＷＷ（World Wide Web）システムを採用した場合を例に挙げて説明をする。権限委譲システムでは、外部ネットワークの一例であるＷＡＮ（Wide Area Network）１０、内部ネットワークの一例であるＬＡＮ（Local Area Network）１１等を介して複数の装置が互いに接続されている。
クライアント１２は、情報処理装置（コンピュータ）の一例であり、ＷＷＷを参照可能なＷｅｂブラウザを有するクライアント端末である。クライアント１２は、ＬＡＮ１１及びＷＡＮ１０を介して文書生成サーバ１３、認証サーバ１４、及び印刷管理サーバ１５等の各サーバに対してＷｅｂリクエスト（リクエスト）を発行する。
文書生成サーバ１３、認証サーバ１４、及び印刷管理サーバ１５は、情報処理装置の一例であり、クライアント１２からの処理の依頼などを表すリクエストを受け付けるＷｅｂサーバである。文書生成サーバ１３は、クライアント１２からのリクエストに従って文書（文書情報）を生成する。認証サーバ１４は、クライアント１２からのリクエストに従って認証を行う（クライアント１２を操作しているユーザの利用資格を確認する）。印刷管理サーバ１５は、クライアント１２からのリクエストに従って、指定された文書の指定されたプリンタ１６への印刷を管理する。プリンタ１６は、画像形成装置の一例であり、文書を印刷する。なお、プリンタ１６は、印刷管理サーバ１５に登録され、管理されている。
【００１２】
図２は、クライアント１２、文書生成サーバ１３、認証サーバ１４、及び印刷管理サーバ１５として採用し得る情報処理装置のハードウェア構成の一例を示す図である。ＣＰＵ２１は、内部バスで接続される各デバイス（ＲＯＭ２２、ＲＡＭ２３等）を直接、或いは間接的に制御し、各種のプログラムを実行する。ＲＯＭ２２は、ＢＩＯＳプログラム等を格納する。ＲＡＭ２３は、直接記憶装置の一例であり、ＣＰＵ２１のワーク領域として利用される。また、ＲＡＭ２３は、各種のソフトウェアモジュールの一時記憶として利用される。
ＨＤＤ２４は、間接記憶装置の一例であり、基本ソフトウェアであるＯＳやソフトウェアモジュールのプログラム等を記憶する。なお、ＨＤＤ２４は、ＳＳＤ（ソリッドステートドライブ）などであってもよい。入力装置２５は、キーボードやポインティングデバイスなどである。出力装置２６は、ディスプレイなどである。Ｉ／Ｆ２７は、ＬＡＮ１１、ＷＡＮ１０などに接続された装置とのデータの通信を制御する。
【００１３】
これらのハードウェアでは、情報処理装置の起動後に、ＣＰＵ２１によりＢＩＯＳプログラムが実行され、ＯＳプログラムがＨＤＤ２４からＲＡＭ２３に実行可能にロードされる。ＣＰＵ２１は、ＯＳの動作に従って各種のソフトウェアモジュールのプログラムをＨＤＤ２４からＲＡＭ２３に随時、実行可能にロードする。各種のソフトウェアモジュールは、ＣＰＵ２１等のデバイスの協調により動作する。すなわち、ＣＰＵ２１が、ＨＤＤ２４に格納されたプログラムの手順に従って処理を行うことによって、情報処理装置における機能及び後述するフローチャートに係る処理が実現される。
また、Ｉ／Ｆ２７は、ＬＡＮ１１に接続されており、ＯＳの動作に従ってＣＰＵ２１により制御され、各情報処理装置が有する後述のサービス部間のリクエストの送受信を行う。また、Ｉ／Ｆ２７は、ＬＡＮ１１を介してＷＡＮ１０に接続されており、ＯＳの動作に従ってＣＰＵ２１により制御され、ＷＷＷシステムにおける通信を可能にする。
【００１４】
図３は、文書生成サーバ１３において動作する文書生成サービス部３０の構成の一例を示す図である。文書生成サービス部３０は、処理依頼部の一例であり、Ｗｅｂアプリケーション部３１、文書生成部３２、データ取得部３３、及び文書出力部３４を含んで構成される。
Ｗｅｂアプリケーション部３１は、クライアント１２からのリクエストを受け付けるＷｅｂインタフェースを有する。Ｗｅｂアプリケーション部３１は、クライアント１２が有するＷｅｂブラウザからのリクエストに対して、文書の生成を要求するための画面（文書生成画面）を生成して応答する。
文書生成部３２は、クライアント１２において文書生成画面を介して生成された文書生成リクエストをＷｅｂアプリケーション部３１で受け付けられたと判断した場合は、文書を生成する。このとき、文書生成部３２は、予め設定されたロジックに従って文書を生成するが、その際、必要に応じてデータ取得部３３を介して不図示の他のサービス部からデータを取得する。また、生成された文書は、不図示のファイルシステムに保存され管理される。そして、Ｗｅｂアプリケーション部３１は、文書が生成されたと判断した場合、文書の出力を要求するための画面（文書出力画面）を生成してクライアント１２に送信する。
【００１５】
また、Ｗｅｂアプリケーション部３１は、クライアント１２において文書出力画面を介して生成された文書出力リクエストを受け付けた場合は、生成された文書を文書生成部３２及び文書出力部３４を介して他のサービス部に対して出力する。
なお、Ｗｅｂアプリケーション部３１は、クライアント１２からのリクエストに対して、文書を生成して出力を要求するための画面（文書生成出力画面）を生成してもよい。この場合、Ｗｅｂアプリケーション部３１は、クライアント１２において文書生成出力画面を介して生成された文書生成出力リクエストを受けた場合は、文書生成部３２にて生成された文書を、文書出力部３４を介して他のサービス部に対して出力する。
【００１６】
図４は、認証サーバ１４において動作する認証サービス部４０の構成の一例を示す図である。認証サービス部４０は、権限委譲部の一例であり、認証アプリケーション部４１、認証部４２、データベース４３、及びサービスアクセス部４４を含んで構成される。
認証アプリケーション部４１は、クライアント１２からのリクエストを受け付けるＷｅｂインタフェースを有する。認証アプリケーション部４１は、クライアント１２が有するＷｅｂブラウザからのＷｅｂリクエストに対して認証画面を生成して応答する。
認証部４２は、クライアント１２において認証画面を介して生成された認証リクエストが認証アプリケーション部４１で受け付けられたと判断した場合、認証処理を行う。このとき、例えば、認証部４２は、認証が成功したと判断した場合、認証トークンを生成し、認証アプリケーション部４１は、認証部４２で生成された認証トークンを、認証アプリケーション部４１を介してクライアント１２に送信する。
【００１７】
認証部４２は、予め設定されたロジックに従って認証処理を行うが、その際、データベース４３にアクセスし、予め登録されているユーザ認証情報とマッチングを行う。例えば、認証部４２は、認証リクエストに含まれる、ユーザを特定するユーザＩＤと秘匿情報の一例であるパスワードとの組み合わせをユーザ認証情報とマッチングし、認証の成否を判断する。
なお、本実施形態では、認証の方式として、認証部４２が、クライアント１２からの認証リクエストに含まれる、ユーザＩＤ、及びパスワードの情報を取得し、予め登録されたユーザ認証情報とマッチングする方式を採用している。しかしながら、本実施形態の認証の方式は、上述した認証の方式に限られるものではない。例えば、他の認証の方式として、証明書を確認することにより認証する方式や、ユーザの生体情報を確認することにより認証する方式を採用してもよい。
【００１８】
サービスアクセス部４４は、他のサービス部からリクエストを受け付けると共に、他のサービス部にリクエストを送信する。他のサービス部から受け付けるリクエストとしては、要求された処理を行う権限が委譲されたこと（権限委譲）を証明するトークンの取得を要求するトークン取得リクエスト、トークンの有効性を確認するためのトークン確認リクエストがある。また、他のサービス部に送信する要求としては、トークン取得リクエストに他のサービス部への確認項目が含まれる場合に送信されるサービス確認リクエストがある。また、認証の方式がリバースプロキシ方式である場合は、サービスアクセス部４４は、他のサービス部の入り口として認証をハンドリングし、認証の結果に応じて他のＷｅｂアプリケーションを呼び出す。サービスアクセス部４４で受信したリクエストは、主に認証部４２で処理されるが、詳細は後述する。
【００１９】
図５は、印刷管理サーバ１５において動作する印刷管理サービス部５０の構成の一例を示す図である。印刷管理サービス部５０は、管理部の一例であり、Ｗｅｂアプリケーション部５１、印刷管理部５２、文書管理部５３、文書データベース５４、プリンタ管理部５５、プリンタデータベース５６、及びサービスアクセス部５７を含んで構成される。
Ｗｅｂアプリケーション部５１は、クライアント１２からのリクエストを受け付けるＷｅｂインタフェースを有する。Ｗｅｂアプリケーション部５１は、クライアント１２が有するＷｅｂブラウザからのリクエストに対して、指定のプリンタ１６での指定の文書の印刷を要求するための印刷指示画面を生成して応答する。
その際、認証の方式がリバースプロキシ方式である場合は、Ｗｅｂアプリケーション部５１は、クライアント１２からリクエストを直接受けず、認証サービス部４０にて認証されたユーザ情報が付与されたリクエストを認証サービス部４０から受け付ける。また、例えば、認証の方式がエージェント方式である場合は、Ｗｅｂアプリケーション部５１に認証エージェントがアドインされ、クライアント１２からのリクエストは、認証エージェントで受け付けられて認証サービス部４０に転送される。認証サービス部４０では、認証が成功すると、認証したユーザ情報を付与したリクエストを、認証エージェントを介してＷｅｂアプリケーション部５１に送信する。
【００２０】
また、Ｗｅｂアプリケーション部５１は、印刷指示画面を生成する際に印刷管理部５２にユーザ情報を送信してプリンタや文書の情報を取得する。このとき、印刷管理部５２は、プリンタ管理部５５を介してプリンタ情報を取得し、文書管理部５３を介して文書情報を取得する。プリンタ管理部５５では、プリンタデータベース５６で管理されているプリンタ情報を取得するが、その際、プリンタデータベース５６で管理されているユーザの権限情報に従って参照可能なプリンタ情報のみを抽出して印刷管理部５２に応答する。文書管理部５３では、文書データベース５４で管理されている文書情報を取得するが、その際、文書データベース５４で管理されているユーザの権限情報に従って参照可能な文書情報のみを抽出して印刷管理部５２に応答する。
【００２１】
印刷管理部５２は、クライアント１２において印刷指示画面を介して生成された印刷リクエストがＷｅｂアプリケーション部５１で受け付けられたと判断した場合は、指定のプリンタに印刷処理を指示する。なお、印刷処理としては、印刷管理部５２がクライアント１２のＷｅｂブラウザを介して指定のプリンタにプルプリント指示を行うケースや、ユーザが指定のプリンタで直接プルプリントの指示を行うケースが考えられる。指定されたプリンタは、プルプリントの指示に応じて文書管理部５３に対してリクエストを行い、文書を取得して印刷を実行する。
サービスアクセス部５７は、他のサービス部からリクエストを受け付けると共に、他のサービス部にリクエストを送信する。他のサービス部から受け付けるリクエストとしては、文書の登録を受け付ける文書登録リクエスト、クライアント１２から要求された処理の成否を権限委譲の実行前に確認するためのサービス確認リクエスト等がある。また、他のサービス部に送信するリクエストとしては、トークン確認リクエスト等がある。サービスアクセス部５７で受信したリクエストは、主に印刷管理部５２で処理されるが、詳細は後述する。
【００２２】
図６は、データベース４３にて管理されているユーザ認証情報、ユーザトークン情報の一例を示す図である。ユーザ認証情報６０は、ユーザを特定可能なユーザＩＤ６０１、秘匿情報であるパスワード６０２、及びユーザの表示名であるユーザ名６０３の情報を含んで構成される。ユーザトークン情報６１は、ユーザを特定可能なユーザＩＤ６１１、及び認証されたことを示すトークン６１２の情報を含んで構成される。ユーザ認証情報６０とユーザトークン情報６１とは、ユーザＩＤによって関連付けられる。なお、ユーザ認証情報６０のうち、ユーザＩＤ６０１、ユーザ名６０３等の情報、すなわちパスワード６０２の情報を除く情報をユーザ情報と適宜称する。
【００２３】
図７は、文書データベース５４にて管理されている文書情報の一例を示す図である。文書情報７０は、文書を特定可能な文書ＩＤ７０１、文書の表示名である文書名７０２、文書のフォーマットを識別可能な文書種別７０３、文書の作成者のユーザＩＤである文書作成者７０４、及び文書データ７０５の情報を含んで構成される。文書データ７０５については、文書データのバイナリが格納されるよう構成されてもよいし、文書データ７０５を別の領域に記憶し、その記憶場所のパスを示す情報が格納されるよう構成されてもよい。
【００２４】
図８は、プリンタデータベース５６にて管理されているプリンタ情報、プリンタ能力情報の一例を示す図である。プリンタ情報８０は、プリンタを特定可能なプリンタＩＤ８０１、プリンタの表示名であるプリンタ名８０２、及びプリンタのアドレスを示すアドレス８０３の情報を含んで構成される。プリンタ能力情報８１は、プリンタを特定可能なプリンタＩＤ８１１、及びプリンタが印刷可能な文書のフォーマットの種別を示す印刷可能文書種別８１２の情報を含んで構成される。なお、印刷可能文書種別８１２は、プリンタの能力の一例である。プリンタ情報８０とプリンタ能力情報８１とは、プリンタＩＤによって関連付けられる。
【００２５】
図９は、文書データベース５４、プリンタデータベース５６で管理されている権限情報の一例を示す図である。権限情報９０は、プリンタ情報や文書情報に対するユーザの権限を格納するための情報である。権限情報９０は、主体種別９０１、主体ＩＤ９０２、許可／拒否９０３、リソース種別９０４、リソースＩＤ９０５、アクション９０６の情報を含んで構成される。例えば、あるユーザがあるプリンタに対して参照可能である権限を示す場合は、権限情報９０には以下の情報が格納される。主体種別９０１にはユーザであることを示す情報、主体ＩＤ９０２にはユーザＩＤ６０１の情報、許可／拒否９０３には許可の情報が格納される。更に、リソース種別９０４にはプリンタであること示す情報、リソースＩＤ９０５にはプリンタＩＤ８０１の情報、アクション９０６には参照することを示す情報が格納される。
【００２６】
以下では、本実施形態の各サービス部が行う処理について説明する。
図１０は、文書生成サービス部３０が文書生成出力リクエストを受けた場合の処理（文書生成出力処理）に係るフローチャートの一例を示す図である。
文書生成サービス部３０は、文書生成出力リクエストを受け付ける（Ｓ１００１）。続いて、文書生成サービス部３０は、予め設定されたロジックに従って文書を生成する（Ｓ１００２）。続いて、文書生成サービス部３０は、印刷管理サービス部５０に文書登録を行う権限が文書生成サービス部３０に委譲されたことを証明するトークンの取得を要求するトークン取得リクエストを生成する（Ｓ１００３）。トークン取得リクエストには、処理の内容を表す処理情報（確認有無情報、文書種別情報、サービス部特定情報、処理種別情報など）が含まれる。確認有無情報は、印刷管理サービス部５０への確認項目の有無を表す情報である。文書種別情報は、処理の対象を表す対象情報の一例であり、本実施形態では、登録する文書のフォーマットの種別を表す情報である。サービス部特定情報は、処理の依頼先を特定可能な特定情報の一例であり、本実施形態では、文書の登録先の印刷管理サービス部５０を特定可能な情報である。処理種別情報は、処理の種別を表す種別情報の一例であり、本実施形態では、対象の処理が文書の登録を行う処理であることを示す情報である。
【００２７】
続いて、文書生成サービス部３０は、生成したトークン取得リクエストを、クライアント１２を介して認証サービス部４０にリダイレクトし（Ｓ１００４）、トークン取得リクエストに対する応答を待つ。
ここで、認証サービス部４０は、図１１に示すトークン生成処理が終わると、クライアント１２を介してトークン取得リクエストの応答を文書生成サービス部３０にリダイレクトする。そして、文書生成サービス部３０は、トークン取得リクエストの応答を受け付ける（Ｓ１００５）。続いて、文書生成サービス部３０は、トークン取得リクエストの結果を判断し（Ｓ１００６）、トークン取得リクエストの結果が失敗（ＮＧ）であると判断した場合は、Ｓ１００９の処理を行う。他方、トークン取得リクエストの結果が成功（ＯＫ）であると判断した場合は、文書生成サービス部３０は、Ｓ１００７の処理を行う。
【００２８】
Ｓ１００７では、トークン取得リクエストに含まれるトークンを利用して印刷管理サービス部５０に文書登録リクエストを送信する。ここで、文書登録リクエストを受けた印刷管理サービス部５０は、不図示の処理にて、受け付けたトークンの有効性を認証サービス部４０に確認し、ＯＫであると判断した場合は文書登録を受け付け、文書の登録が成功した旨を文書生成サービス部３０に応答する。他方、ＮＧであると判断した場合は、印刷管理サービス部５０は、文書の登録を拒否し、文書の登録が失敗した旨を文書生成サービス部３０に応答する。続いて、文書生成サービス部３０は、文書登録リクエストの応答を受け付け（Ｓ１００８）、Ｓ１００９の処理を行う。
Ｓ１００９では、文書生成サービス部３０は、文書生成出力リクエストの結果に応答する。より具体的には、文書生成サービス部３０は、文書生成出力リクエストの結果がＮＧであると判断した場合、文書生成出力リクエストが失敗した旨を示す画面を生成してクライアント１２に送信する。また、文書生成サービス部３０は、文書生成出力リクエストの結果がＯＫであり、文書登録リクエストの結果がＯＫであると判断した場合、文書の登録が成功した旨を示す画面を生成してクライアント１２に送信する。また、文書生成サービス部３０は、文書生成出力リクエストの結果がＯＫであり、文書登録リクエストの結果がＮＧであると判断した場合、文書の登録が失敗した旨を示す画面を生成してクライアント１２に送信する。
【００２９】
図１１は、認証サービス部４０がトークン取得リクエストを受けた場合の処理（トークン生成処理）に係るフローチャートの一例を示す図である。
認証サービス部４０は、トークン取得リクエストを受け付ける（Ｓ１１０１）。続いて、認証サービス部４０は、認証サービス部４０の認証の方式に従って認証を行う（Ｓ１１０２）。続いて、認証サービス部４０は、トークン取得リクエストの内容を確認する（Ｓ１１０３）。続いて、認証サービス部４０は、他のサービス部への確認項目の有無を確認する（Ｓ１１０４）。このとき、認証サービス部４０は、トークン取得リクエストに含まれる確認有無情報が「無し」を表す情報であると判断した場合は、Ｓ１１０８の処理を行い、他方、「有り」を表す情報であると判断した場合は、Ｓ１１０５の処理を行う。
【００３０】
Ｓ１１０５では、認証サービス部４０は、対象のサービス部に対してサービス確認リクエストを送信する。より具体的には、認証サービス部４０は、文書種別情報、処理種別情報を含むサービス確認リクエストを生成し、トークン取得リクエストに含まれるサービス部特定情報に従って、印刷管理サービス部５０にサービス確認リクエストを送信する。その際、認証サービス部４０は、サービス確認リクエストにＳ１１０２にて認証したユーザ情報を追加する。続いて、認証サービス部４０は、サービス確認リクエストの応答を受け付ける（Ｓ１１０６）。なお、サービス確認リクエストを印刷管理サービス部５０に送信した際の印刷管理サービス部５０における処理については図１２を参照して詳細に説明する。
続いて、認証サービス部４０は、サービス確認リクエストの結果を判断する（Ｓ１１０７）。このとき、認証サービス部４０は、サービス確認リクエストの結果が、対象の処理を印刷管理サービス部５０で受け付けていないことを示すもの（拒否）であると判断した場合は、Ｓ１１１３の処理を行う。他方、サービス確認リクエストの結果が、対象の処理を印刷管理サービス部５０で受け付けていることを示すもの（許可）であると判断した場合は、認証サービス部４０は、Ｓ１１０８の処理を行う。
【００３１】
Ｓ１１０８では、認証サービス部４０は、対象の処理を行う権限を委譲するか否かをユーザに確認するための許可確認画面を生成する。例えば、認証サービス部４０は、サービス確認リクエストの応答の内容に従って許可確認画面を生成し、クライアント１２に送信する。図１３に、許可確認画面の一例を示す。
続いて、認証サービス部４０は、クライアント１２から許可確認画面を介して許可確認の結果を受け付ける（Ｓ１１０９）。続いて、認証サービス部４０は、許可確認の結果を判断する（Ｓ１１１０）。このとき、認証サービス部４０は、許可確認の結果が、対象の処理を行う権限の委譲を許可しないもの（拒否）であると判断した場合は、Ｓ１１１３の処理を行う。他方、許可確認の結果が、対象の処理を行う権限の委譲を許可するもの（許可）であると判断した場合は、認証サービス部４０は、Ｓ１１１１の処理を行う。すなわち、認証サービス部４０は、印刷管理サーバ１５に対するユーザの権限を文書生成サーバ１３に委譲するか否かを決定している。なお、本実施形態は、認証サービス部４０が許可確認の結果に基づいて権限を委譲するか否かを決定する構成に限られるものではない。例えば、認証サービス部４０は、サービス確認リクエストの結果が、対象の処理を印刷管理サービス部５０で受け付けていることを示すものであると判断した場合、権限を委譲すると決定する構成を採用してもよい。
【００３２】
Ｓ１１１１では、認証サービス部４０は、ユーザトークン情報などに基づいて、権限が委譲されたことを証明するトークンを生成する。続いて、認証サービス部４０は、トークン取得リクエストの成功を示すリクエストを生成し（Ｓ１１１２）、Ｓ１１１４の処理を行う。
Ｓ１１１３では、認証サービス部４０は、トークン取得リクエストの失敗を示すリクエストを生成し、Ｓ１１１４の処理を行う。
Ｓ１１１４では、認証サービス部４０は、生成したリクエスト（決定情報）を、クライアント１２を介してトークン取得リクエストの応答先（この例では、文書生成サービス部３０）にリダイレクトする。
【００３３】
図１２は、印刷管理サービス部５０がサービス確認リクエストを受けた場合の処理（確認処理）に係るフローチャートの一例を示す図である。
印刷管理サービス部５０は、サービス確認リクエストを受け付ける（Ｓ１２０１）。続いて、印刷管理サービス部５０は、処理の種別を確認する（Ｓ１２０２）。このとき、印刷管理サービス部５０は、サービス確認リクエストに含まれる処理種別情報が文書を登録することを示す情報でないと判断した場合は、サービス確認リクエストの結果として許可応答を生成し（Ｓ１２０４）、Ｓ１２１２の処理を行う。他方、処理種別情報が文書を登録することを示す情報であると判断した場合は、印刷管理サービス部５０は、Ｓ１２０５の処理を行う。
【００３４】
Ｓ１２０５では、印刷管理サービス部５０は、文書の種別を確認する。このとき、印刷管理サービス部５０は、サービス確認リクエストに含まれる文書種別情報が登録可能な文書のフォーマットの情報でないと判断した場合（Ｓ１２０６でＮＯの場合）は、Ｓ１２０７の処理を行う。他方、文書種別情報が登録可能な文書のフォーマットの情報であると判断した場合（Ｓ１２０６でＹＥＳの場合）は、印刷管理サービス部５０は、Ｓ１２０８の処理を行う。
Ｓ１２０７では、印刷管理サービス部５０は、サービス確認リクエストの結果として拒否の応答を生成し、Ｓ１２１２の処理を行う。
Ｓ１２０８では、印刷管理サービス部５０は、サービス確認リクエストに含まれるユーザ情報に対応するユーザが対象の文書のフォーマットで印刷可能なプリンタがあるかを権限情報に基づいて確認する。
【００３５】
このとき、印刷管理サービス部５０は、印刷可能なプリンタがあると判断した場合は、サービス確認リクエストの結果として印刷可能なプリンタが登録されている旨を付与した許可応答を生成し（Ｓ１２１０）、Ｓ１２１２の処理を行う。この場合、Ｓ１１０８では、例えば、図１３（１）に示す許可確認画面１３００Ａが生成される。許可確認画面１３００Ａは、サービス確認リクエストの結果が「プリンタあり」の場合の画面例である。確認メッセージ欄１３０１には、クライアント１２にて表示するメッセージ（内容）が記載され、メッセージは、サービス確認リクエストの応答の内容に従って生成される。
他方、印刷可能なプリンタが無いと判断した場合は、印刷管理サービス部５０は、サービス確認リクエストの結果として印刷可能なプリンタが登録されていない旨を付与した許可応答を生成し（Ｓ１２１１）、Ｓ１２１２の処理を行う。この場合、Ｓ１１０８では、例えば、図１３（２）に示す許可確認画面１３００Ｂが生成される。許可確認画面１３００Ｂは、サービス確認リクエストの結果が「プリンタなし」の場合の画面例であり、登録可能な文書を印刷可能なプリンタが無い旨が確認メッセージ欄１３０１に提示される。なお、許可確認画面１３００Ａ及び許可確認画面１３００Ｂの各々は、権限の委譲を許可する許可ボタン１３０２、権限の委譲を拒否する拒否ボタン１３０３を含んで構成される。
Ｓ１２１２では、印刷管理サービス部５０は、サービス確認リクエストの結果、すなわち、判断した結果の情報を含む判断情報を認証サービス部４０に送信する。
【００３６】
以上の処理により、印刷管理サービス部５０で登録ができないフォーマットの文書であると判断された場合に、権限の委譲を確認する画面にその旨を表示することで、文書の登録が無駄であるとユーザが判断した場合は、権限の移譲を拒否することが可能となる。更には、委譲されるユーザの権限では印刷可能なプリンタが無い場合に、権限の委譲を確認する画面にその旨を表示することで、印刷ができない状況での文書の登録が無駄であるとユーザが判断した場合は、権限の移譲を拒否することが可能となる。このように、ユーザは、委譲される権限をもって行う文書に係る処理の成否を、権限を委譲する前に確認し、権限の委譲の許可及び拒否を選択することができるので、権限を委譲することが無駄になることを防ぐことができる。
【００３７】
＜第２の実施形態＞
図１４は、第２の実施形態に係る印刷管理サービス部５０においてサービス確認リクエストを受けた場合の処理（確認処理）に係るフローチャートの一例を示す図である。なお、図１２と同様の処理については、同じ符号を付与して説明を省略し、以下、異なる部分を主に説明する。
印刷管理サービス部５０は、ユーザ情報に対応するユーザが対象の文書のフォーマットで印刷可能なプリンタがあるかを確認し、プリンタがないと判断した場合、Ｓ１２１１の処理を行う。他方、プリンタがあると判断した場合、印刷管理サービス部５０は、Ｓ１４０１の処理を行う（Ｓ１２０８、Ｓ１２０９）。
Ｓ１４０１では、印刷管理サービス部５０は、対象の文書のフォーマットで印刷可能なプリンタのリストを取得する。続いて、印刷管理サービス部５０は、サービス確認リクエストの結果として許可応答を生成し、取得したプリンタのリストを付与し（Ｓ１４０２）、サービス確認リクエストの結果を認証サービス部４０に送信する（Ｓ１２１２）。
【００３８】
図１５は、本実施形態に係る認証サービス部４０で生成される許可確認画面の一例を示す図である。なお、図１３と同様の構成については、同じ符号を付して説明を省略し、以下、異なる部分を主に説明する。
許可確認画面１３００Ｃは、図１４のＳ１４０２で生成されたプリンタのリストが付与されたサービス確認リクエストの応答を図１１のＳ１１０６にて受信した場合にＳ１１０８で生成される画面の例である。
【００３９】
許可確認画面１３００Ｃでは、追加メッセージ欄１５０１には対象の文書が印刷可能なプリンタがリスト形式で表示される。リスト形式で表示されたプリンタは、選択可能に構成されている。また、許可確認画面１３００Ｃには、権限の委譲を許可して印刷を実行する印刷ボタン１５０２を有している。印刷ボタン１５０２が押下された場合、認証サービス部４０は、図１１のＳ１１１１で権限が委譲されたことを証明するトークンを生成し、生成したトークンに選択されたプリンタを特定する情報を付与する。次に、認証サービス部４０は、Ｓ１１１２にてトークン取得リクエストの成功を示すリクエストを生成し、クライアント１２を介してトークン取得リクエストの応答先にリダイレクトする（Ｓ１１１４）。
【００４０】
また、文書生成サービス部３０では、図１０のＳ１００５にてプリンタを特定する情報が付与されたトークンを取得した場合は、Ｓ１００９の処理の終了後に、印刷管理サービス部５０に対して、印刷要求を実行する。
以上の処理により、権限を委譲することが無駄になることを防ぐことができると共に、ユーザの印刷指示を受ける処理を省略して文書の登録、印刷を実行することが可能になる。
【００４１】
＜その他の実施形態＞
上述した実施形態では、文書生成サービス部３０、認証サービス部４０、印刷管理サービス部５０は、それぞれ独立したサーバにホスティングする構成を採用したが、この構成に限られるものではない。例えば、１台のサーバにまとめてホスティングする構成を採用してもよいし、また、複数のサーバにクラスタリングして負荷分散を行う構成を採用してもよい。
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００４２】
上述した実施形態の構成によれば、権限の委譲が無駄になる事態を極力回避することができる。
【００４３】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【特許請求の範囲】
【請求項１】
処理依頼部と、権限委譲部と、管理部と、を有する権限委譲システムであって、
前記処理依頼部は、
ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成手段を有し、
前記権限委譲部は、
前記生成手段で生成されたリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記管理部に送信する送信手段を有し、
前記管理部は、
前記送信手段で送信されたリクエストを受け取り、前記リクエストに含まれる処理情報より前記管理部で前記処理を実行可能であるか否かを判断する判断手段を有し、
前記権限委譲部は、
前記判断手段により実行可能であると判断された場合、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲すると決定する決定手段を更に有することを特徴とする権限委譲システム。
【請求項２】
前記生成手段は、前記処理の内容を表す処理情報として、前記処理の種別を表す種別情報と前記処理の対象を表す対象情報とを含むリクエストを生成し、
前記送信手段は、前記生成手段で生成されたリクエストを受け取り、前記リクエストに基づいて、前記種別情報と前記対象情報とを含むリクエストを前記管理部に送信し、
前記判断手段は、前記送信手段で送信されたリクエストを受け取り、前記リクエストに含まれる種別情報より前記管理部で前記処理を実行可能であると判断した場合、前記リクエストに含まれる対象情報の前記処理の対象を扱うことができるか否かを更に判断し、
前記決定手段は、前記判断手段により前記処理の対象を扱うことができると判断された場合、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲すると決定することを特徴とする請求項１に記載の権限委譲システム。
【請求項３】
前記管理部は、前記処理の対象が文書情報であり、前記処理の種別が前記文書情報の登録である場合、前記判断手段で前記文書情報を登録することができると判断されたとき、前記判断手段で前記文書情報を登録することができると判断された結果を表す情報と、前記管理部で管理されている画像形成装置のうち前記文書情報を扱うことができる画像形成装置の有無を表す有無情報とを含む判断情報を作成する作成手段を更に有し、
前記決定手段は、前記作成手段で作成された判断情報を受け取り、前記判断情報に含まれる有無情報を示した、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲するか否かを前記ユーザに確認する確認画面の情報を生成し、前記確認画面を介して受け付けられた前記ユーザの確認の結果が前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲することを許可するものである場合、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲すると決定することを特徴とする請求項２に記載の権限委譲システム。
【請求項４】
前記作成手段は、前記管理部で管理されている画像形成装置のうち前記文書情報を扱うことができる画像形成装置がある場合は、前記有無情報として前記画像形成装置を特定可能な情報を含む判断情報を作成することを特徴とする請求項３に記載の権限委譲システム。
【請求項５】
前記処理依頼部は、前記生成手段で生成されたリクエストを、前記ユーザ装置を介して前記権限委譲部に送信する通信手段を更に有することを特徴とする請求項１乃至４の何れか１項に記載の権限委譲システム。
【請求項６】
ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成手段と、
前記処理の依頼先である管理装置に対する前記ユーザの権限を当該情報処理装置に委譲するか否かを決定する権限委譲装置に前記生成手段で生成されたリクエストを送信する送信手段と、
前記処理を実行可能であるか否かを前記管理装置に確認した結果に基づいて前記権限を委譲するか否かを決定した結果を表す決定情報を前記権限委譲装置から受け取り、前記決定情報に応じて前記管理装置に前記処理を依頼する制御を行う制御手段と、を有することを特徴とする情報処理装置。
【請求項７】
ユーザが操作するユーザ装置からの処理の依頼に応答して処理依頼装置で生成された、前記処理の内容を表す処理情報を含むリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記処理の依頼先である管理装置に送信する送信手段と、
前記リクエストに応答する、前記管理装置で前記処理を実行可能であるか否かが判断された結果が、前記管理装置で前記処理を実行可能であることを示すものである場合、前記管理装置に対する前記ユーザの権限を前記処理依頼装置に委譲すると決定する決定手段と、を有することを特徴とする情報処理装置。
【請求項８】
処理依頼部と、権限委譲部と、管理部と、を有する権限委譲システムにおける権限委譲方法であって、
前記処理依頼部が、ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成工程と、
前記権限委譲部が、前記生成工程で生成されたリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記管理部に送信する送信工程と、
前記管理部が、前記送信工程で送信されたリクエストを受け取り、前記リクエストに含まれる処理情報より前記管理部で前記処理を実行可能であるか否かを判断する判断工程と、
前記権限委譲部が、前記判断工程により実行可能であると判断された場合、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲すると決定する決定工程とを有することを特徴とする権限委譲方法。
【請求項９】
情報処理装置が実行する権限委譲方法であって、
ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成工程と、
前記処理の依頼先である管理装置に対する前記ユーザの権限を前記情報処理装置に委譲するか否かを決定する権限委譲装置に前記生成工程で生成されたリクエストを送信する送信工程と、
前記処理を実行可能であるか否かを前記管理装置に確認した結果に基づいて前記権限を委譲するか否かを決定した結果を表す決定情報を前記権限委譲装置から受け取り、前記決定情報に応じて前記管理装置に前記処理を依頼する制御を行う制御工程と、を有することを特徴とする権限委譲方法。
【請求項１０】
情報処理装置が実行する権限委譲方法であって、
ユーザが操作するユーザ装置からの処理の依頼に応答して処理依頼装置で生成された、前記処理の内容を表す処理情報を含むリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記処理の依頼先である管理装置に送信する送信工程と、
前記リクエストに応答する、前記管理装置で前記処理を実行可能であるか否かが判断された結果が、前記管理装置で前記処理を実行可能であることを示すものである場合、前記管理装置に対する前記ユーザの権限を前記処理依頼装置に委譲すると決定する決定工程と、を有することを特徴とする権限委譲方法。
【請求項１１】
コンピュータを、
ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成手段と、
前記処理の依頼先である管理装置に対する前記ユーザの権限を当該コンピュータに委譲するか否かを決定する権限委譲装置に前記生成手段で生成されたリクエストを送信する送信手段と、
前記処理を実行可能であるか否かを前記管理装置に確認した結果に基づいて前記権限を委譲するか否かを決定した結果を表す決定情報を前記権限委譲装置から受け取り、前記決定情報に応じて前記管理装置に前記処理を依頼する制御を行う制御手段として機能させるプログラム。
【請求項１２】
コンピュータを、
ユーザが操作するユーザ装置からの処理の依頼に応答して処理依頼装置で生成された、前記処理の内容を表す処理情報を含むリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記処理の依頼先である管理装置に送信する送信手段と、
前記リクエストに応答する、前記管理装置で前記処理を実行可能であるか否かが判断された結果が、前記管理装置で前記処理を実行可能であることを示すものである場合、前記管理装置に対する前記ユーザの権限を前記処理依頼装置に委譲すると決定する決定手段として機能させるプログラム。
【請求項１】
処理依頼部と、権限委譲部と、管理部と、を有する権限委譲システムであって、
前記処理依頼部は、
ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成手段を有し、
前記権限委譲部は、
前記生成手段で生成されたリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記管理部に送信する送信手段を有し、
前記管理部は、
前記送信手段で送信されたリクエストを受け取り、前記リクエストに含まれる処理情報より前記管理部で前記処理を実行可能であるか否かを判断する判断手段を有し、
前記権限委譲部は、
前記判断手段により実行可能であると判断された場合、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲すると決定する決定手段を更に有することを特徴とする権限委譲システム。
【請求項２】
前記生成手段は、前記処理の内容を表す処理情報として、前記処理の種別を表す種別情報と前記処理の対象を表す対象情報とを含むリクエストを生成し、
前記送信手段は、前記生成手段で生成されたリクエストを受け取り、前記リクエストに基づいて、前記種別情報と前記対象情報とを含むリクエストを前記管理部に送信し、
前記判断手段は、前記送信手段で送信されたリクエストを受け取り、前記リクエストに含まれる種別情報より前記管理部で前記処理を実行可能であると判断した場合、前記リクエストに含まれる対象情報の前記処理の対象を扱うことができるか否かを更に判断し、
前記決定手段は、前記判断手段により前記処理の対象を扱うことができると判断された場合、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲すると決定することを特徴とする請求項１に記載の権限委譲システム。
【請求項３】
前記管理部は、前記処理の対象が文書情報であり、前記処理の種別が前記文書情報の登録である場合、前記判断手段で前記文書情報を登録することができると判断されたとき、前記判断手段で前記文書情報を登録することができると判断された結果を表す情報と、前記管理部で管理されている画像形成装置のうち前記文書情報を扱うことができる画像形成装置の有無を表す有無情報とを含む判断情報を作成する作成手段を更に有し、
前記決定手段は、前記作成手段で作成された判断情報を受け取り、前記判断情報に含まれる有無情報を示した、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲するか否かを前記ユーザに確認する確認画面の情報を生成し、前記確認画面を介して受け付けられた前記ユーザの確認の結果が前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲することを許可するものである場合、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲すると決定することを特徴とする請求項２に記載の権限委譲システム。
【請求項４】
前記作成手段は、前記管理部で管理されている画像形成装置のうち前記文書情報を扱うことができる画像形成装置がある場合は、前記有無情報として前記画像形成装置を特定可能な情報を含む判断情報を作成することを特徴とする請求項３に記載の権限委譲システム。
【請求項５】
前記処理依頼部は、前記生成手段で生成されたリクエストを、前記ユーザ装置を介して前記権限委譲部に送信する通信手段を更に有することを特徴とする請求項１乃至４の何れか１項に記載の権限委譲システム。
【請求項６】
ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成手段と、
前記処理の依頼先である管理装置に対する前記ユーザの権限を当該情報処理装置に委譲するか否かを決定する権限委譲装置に前記生成手段で生成されたリクエストを送信する送信手段と、
前記処理を実行可能であるか否かを前記管理装置に確認した結果に基づいて前記権限を委譲するか否かを決定した結果を表す決定情報を前記権限委譲装置から受け取り、前記決定情報に応じて前記管理装置に前記処理を依頼する制御を行う制御手段と、を有することを特徴とする情報処理装置。
【請求項７】
ユーザが操作するユーザ装置からの処理の依頼に応答して処理依頼装置で生成された、前記処理の内容を表す処理情報を含むリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記処理の依頼先である管理装置に送信する送信手段と、
前記リクエストに応答する、前記管理装置で前記処理を実行可能であるか否かが判断された結果が、前記管理装置で前記処理を実行可能であることを示すものである場合、前記管理装置に対する前記ユーザの権限を前記処理依頼装置に委譲すると決定する決定手段と、を有することを特徴とする情報処理装置。
【請求項８】
処理依頼部と、権限委譲部と、管理部と、を有する権限委譲システムにおける権限委譲方法であって、
前記処理依頼部が、ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成工程と、
前記権限委譲部が、前記生成工程で生成されたリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記管理部に送信する送信工程と、
前記管理部が、前記送信工程で送信されたリクエストを受け取り、前記リクエストに含まれる処理情報より前記管理部で前記処理を実行可能であるか否かを判断する判断工程と、
前記権限委譲部が、前記判断工程により実行可能であると判断された場合、前記管理部に対する前記ユーザの権限を前記処理依頼部に委譲すると決定する決定工程とを有することを特徴とする権限委譲方法。
【請求項９】
情報処理装置が実行する権限委譲方法であって、
ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成工程と、
前記処理の依頼先である管理装置に対する前記ユーザの権限を前記情報処理装置に委譲するか否かを決定する権限委譲装置に前記生成工程で生成されたリクエストを送信する送信工程と、
前記処理を実行可能であるか否かを前記管理装置に確認した結果に基づいて前記権限を委譲するか否かを決定した結果を表す決定情報を前記権限委譲装置から受け取り、前記決定情報に応じて前記管理装置に前記処理を依頼する制御を行う制御工程と、を有することを特徴とする権限委譲方法。
【請求項１０】
情報処理装置が実行する権限委譲方法であって、
ユーザが操作するユーザ装置からの処理の依頼に応答して処理依頼装置で生成された、前記処理の内容を表す処理情報を含むリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記処理の依頼先である管理装置に送信する送信工程と、
前記リクエストに応答する、前記管理装置で前記処理を実行可能であるか否かが判断された結果が、前記管理装置で前記処理を実行可能であることを示すものである場合、前記管理装置に対する前記ユーザの権限を前記処理依頼装置に委譲すると決定する決定工程と、を有することを特徴とする権限委譲方法。
【請求項１１】
コンピュータを、
ユーザが操作するユーザ装置からの処理の依頼に応答して、前記処理の内容を表す処理情報を含むリクエストを生成する生成手段と、
前記処理の依頼先である管理装置に対する前記ユーザの権限を当該コンピュータに委譲するか否かを決定する権限委譲装置に前記生成手段で生成されたリクエストを送信する送信手段と、
前記処理を実行可能であるか否かを前記管理装置に確認した結果に基づいて前記権限を委譲するか否かを決定した結果を表す決定情報を前記権限委譲装置から受け取り、前記決定情報に応じて前記管理装置に前記処理を依頼する制御を行う制御手段として機能させるプログラム。
【請求項１２】
コンピュータを、
ユーザが操作するユーザ装置からの処理の依頼に応答して処理依頼装置で生成された、前記処理の内容を表す処理情報を含むリクエストを受け取り、前記リクエストに基づいて、前記処理情報を含むリクエストを前記処理の依頼先である管理装置に送信する送信手段と、
前記リクエストに応答する、前記管理装置で前記処理を実行可能であるか否かが判断された結果が、前記管理装置で前記処理を実行可能であることを示すものである場合、前記管理装置に対する前記ユーザの権限を前記処理依頼装置に委譲すると決定する決定手段として機能させるプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１２−８９５８（Ｐ２０１２−８９５８Ａ）
【公開日】平成２４年１月１２日（２０１２．１．１２）
【国際特許分類】
【出願番号】特願２０１０−１４６６４９（Ｐ２０１０−１４６６４９）
【出願日】平成２２年６月２８日（２０１０．６．２８）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２４年１月１２日（２０１２．１．１２）
【国際特許分類】
【出願日】平成２２年６月２８日（２０１０．６．２８）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]