"サーバ装置、ユーザ端末装置、認証サーバ装置、とデータ通信可能に接続されている情報処理装置であって、前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信する受信手段と、前記サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報を前記ユーザ端末装置に対して送信する手段と、前記ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信し、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスを前記サーバ装置が提供する前に認証を行う前記認証サーバ装置に対して送信する手段と、前記認証サーバ装置による認証が成功した場合には、前記サーバ装置に対して前記選択されたサービスを提供させるよう指示する手段とを備えることを特徴とする情報処理装置。前記受信手段は、前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信する為のURIが記された文書を該サーバ装置から受信する手段と、前記文書を受信すると、該文書から前記URIを取得し、該取得したURIで特定される前記サーバ装置に対して前記サービス情報を要求し、該要求に応じて前記サーバ装置から送信されたサービス情報を受信する手段とを備えることを特徴とする請求項1に記載の情報処理装置。前記受信手段は、予め定められたアクセストークンを用いて前記サーバ装置に対してアクセスした場合に、該アクセストークンが不正である旨のエラー通知を受信した場合に、前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信することを特徴とする請求項1又は2に記載の情報処理装置。サーバ装置、ユーザ端末装置、認証サーバ装置、とデータ通信可能に接続されている情報処理装置が行う情報処理方法であって、前記情報処理装置の受信手段が、前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信する受信工程と、前記情報処理装置の表示情報の送信手段が、前記サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報を前記ユーザ端末装置に対して送信する工程と、前記情報処理装置の認証要求の送信手段が、前記ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信し、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスを前記サーバ装置が提供する前に認証を行う前記認証サーバ装置に対して送信する工程と、前記情報処理装置の指示手段が、前記認証サーバ装置による認証が成功した場合には、前記サーバ装置に対して前記選択されたサービスを提供させるよう指示する工程とを備えることを特徴とする情報処理方法。コンピュータを、請求項1乃至3の何れか1項に記載の情報処理装置の各手段として機能させるためのコンピュータプログラム。リソースプロバイダのバージョンアップによってWebAPIの仕様を変更した場合には、OAuthのscopeパラメータが不正になるため、OAuthクライアントは正しい認可メッセージをOAuthサーバに送信できなかった。例えば図1の場合、オフィス文書サービス104のWebAPIがバージョンアップし、サービスを提供するWebAPIの提供範囲が変更された場合、印刷サービス102は図2におけるscopeパラメータを更新する必要があった。従来のOAuthクライアントとしては、このscopeパラメータは、リソースプロバイダのWebAPIの仕様に基づいて固定値として保存しておくものが一般的であった。もし、リソースプロバイダのWebAPIが変更された場合には、scopeパラメータをその都度手作業で更新する。もし、scopeパラメータを更新せずにOAuthの認可フローを実行すると、リソースプロバイダにアクセスした際にアクセス範囲エラーとなり、ユーザデータにアクセスすることができなくなる。本発明は以上の問題に鑑みてなされたものであり、OAuthクライアントがリソースプロバイダから動的にアクセス範囲情報を取得できるようになり、アクセス範囲情報の管理を容易にするための技術を提供することを目的とする。本発明の目的を達成するために、例えば、本発明の情報処理装置は、サーバ装置、ユーザ端末装置、認証サーバ装置、とデータ通信可能に接続されている情報処理装置であって、前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信する受信手段と、前記サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報を前記ユーザ端末装置に対して送信する手段と、前記ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信し、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスを前記サーバ装置が提供する前に認証を行う前記認証サーバ装置に対して送信する手段と、前記認証サーバ装置による認証が成功した場合には、前記サーバ装置に対して前記選択されたサービスを提供させるよう指示する手段とを備えることを特徴とする。本発明の構成によれば、OAuthクライアントは、リソースプロバイダから動的にアクセス範囲情報を取得できるようになり、アクセス範囲情報の管理が容易になる。以下、添付図面を参照し、本発明の好適な実施形態について説明する。なお、以下説明する実施形態は、本発明を具体的に実施した場合の一例を示すもので、特許請求の範囲に記載した構成の具体的な実施例の一つである。[第1の実施形態]先ず、本実施形態に係るシステムの構成例について、図3を用いて説明する。図3に示す如く、本実施形態に係るシステムは、情報処理装置201、サーバサーバ装置207、認可サーバ認証サーバ装置208、ユーザ端末装置209,を有し、それぞれの装置はデータ通信が可能なように接続されている。それぞれの装置の構成やそれぞれの装置が行う処理については、以下に詳しく説明する。情報処理装置201が行う処理について、同処理のフローチャートを示す図4のフローチャートを用いて説明する。なお、この説明では、情報処理装置201以外の各装置の動作についても説明する。ユーザ端末装置209は、図7の手順1のように、Webブラウザを用いて情報処理装置201印刷サービスにアクセスし、サーバ207外部のオフィス文書サービス内に保存しているユーザのオフィス文書ユーザデータの印刷を要求する。この要求を受信した情報処理装置201は、サーバ207によって公開されているディスカバリーサービスここではhttps//docssampleorg/discoveryに対して、後述するXRD文書の取得要求を送信する。サーバ207はこの取得要求に応じてXRD文書を送信するので、ステップS102においてサービス情報解析部202は、このXRD文書を受信する。ステップS103においてサービス情報解析部202は、この受信したXRD文書を、XMLパーサを用いて解析する。ここで、印刷サービスは、この固定URLのディカバリサービスを用いることによって、常に最新のサービス内容を取得できるものとする。このXRD文書の一例を図8に示す。図8に示したXRD文書には、オフィス文書サービスのWebAPIのアクセス範囲情報取得用URL、フィード文書取得用URL、認証コード取得用URL、アクセストークン取得用URL、が含まれている。これらのURLの種別は、各Service要素の子要素であるType要素の要素内容に基づいて識別することができる。次に、ステップS104では、記述特定部203は、以下で用いる変数defaulturiと変数scopediscoveryを適当な値に初期化する。次にステップS105では、記述特定部203は、XRD文書中の全てのService要素について解析したか否かを判断する。この判断の結果、まだ解析していないService要素が残っている場合には、処理はステップS106に進み、全てのService要素を解析した場合には、処理はステップS111に進む。ステップS106では、記述特定部203は、XRD文書中において未解析のService要素のType要素の内容を解析する。そしてステップS107では、記述特定部203は、この解析したType要素の内容がアクセス範囲情報を提供するサービスであるか否かを判断する。この判断の結果、この解析したType要素の内容がアクセス範囲情報を提供するサービスである場合には、処理はステップS108に進む。一方、この解析したType要素の内容がアクセス範囲情報を提供するサービスではない場合は、処理はステップS109に進む。ステップS108では、記述特定部203は、アクセス範囲情報を提供するサービスであることを示すType要素が属するService要素の子要素であるURI要素の要素内容を変数scopediscoveryに設定する。ステップS109では、記述特定部203は、ステップS106で解析したType要素の内容が、ユーザのリソース情報を提供するサービスであるか否かを判断する。この判断の結果、ユーザのリソース情報を提供するサービスである場合には、処理はステップS110に進み、ユーザのリソース情報を提供するサービスではない場合には、処理はステップS105に戻る。ステップS110では、ユーザのリソース情報を提供するサービスであることを示すType要素が属するService要素の子要素であるURI要素の要素内容を変数defaulturiに設定する。ユーザのリソース情報は、RFC5023TheAtomPublishingProtocolに基づいて取得するものとする。ステップS111では、アクセス範囲情報取得部204は、変数scopediscoveryに初期値以外の何らかの値が設定してあるか否かを判断する。この判断の結果、変数scopediscoveryに初期値以外の何らかの値が設定してある場合には、処理はステップS112に進む。一方、変数scopediscoveryに初期値以外の何らかの値が設定してない場合は、処理はステップS114に進む。ステップS112では、アクセス範囲情報取得部204は、変数scopediscoveryに設定されているURIを用いて、アクセス範囲情報の取得要求をサーバ207に送信する。この取得要求、取得要求に応じてサーバ207から返信されるアクセス範囲情報、の一例を図9に示す。図9aは、情報処理装置201がサーバ207に対して送信する、アクセス範囲情報の取得要求の一例を示す。図9bは、この取得要求に応じてサーバ207が情報処理装置201に対して送信するアクセス範囲情報の一例を示す。図9bに示す如く、アクセス範囲情報はXML形式のデータである。図9bのアクセス範囲情報には、3つのアクセス範囲情報が含まれており、各scope要素の要素内容がURL形式のアクセス範囲情報となる。図9bでは、この3つのXML形式のアクセス範囲情報のそれぞれは、文書サービス、スプレッドシートサービス、PDFサービス、に対応したものである。また、scope要素のuse属性の値がdefaultである場合、このscope要素に対応するサービスアクセス範囲の使用を、標準設定において指定してあることを示している。また、scope要素のuse属性の値がoptionalである場合、このscope要素に対応するサービスアクセス範囲の使用は標準設定では指定しておらず、ユーザによって任意に指定するものであることを示している。また、scope要素のicon属性は、このscope要素に対応するサービスアクセス範囲を表現したアイコン画像へのURLを示している。次に、上記のステップS112における処理の詳細について、図5のフローチャートを用いて説明する。なお、この説明では、情報処理装置201がサーバ207から図9bに示したアクセス範囲情報を受信した場合を例にとっている。しかし、以下の説明は、図9bに示したアクセス範囲情報以外のアクセス範囲情報を受信した場合であっても同様に適用することができる。ステップS202では、アクセス範囲情報取得部204が送信した要求に応じてサーバ207から送信されたアクセス範囲情報を、アクセス範囲情報解析部205が受信する。そしてアクセス範囲情報解析部205が有する記述解析部が、この受信したアクセス範囲情報を解析する。ステップS203では、アクセス範囲情報解析部205は、以下の処理で用いる変数scopeListをリスト型で初期化する。即ち、変数scopeListに対して複数個の構造体を格納できるようにする。ステップS204では、アクセス範囲情報解析部205は、受信したアクセス範囲情報中における、ルートのscopes要素以下の全てのscope要素を解析したか否かを判断する。この判断の結果、全てのscope要素を解析した場合には、処理はステップS210に進み、まだ解析していないscope要素が残っている場合には、処理はステップS205に進む。ステップS205では、アクセス範囲情報解析部205は、変数構造体scopeを適当な値に初期化する。ステップS206では、アクセス範囲情報解析部205の属性解析部が、未解析のscope要素のuse属性の値を、変数scopeのメンバー変数useに設定する。ステップS207では、アクセス範囲情報解析部205の属性解析部が、未解析のscope要素のicon属性の値を、変数scopeのメンバー変数iconに設定する。ステップS208では、アクセス範囲情報解析部205の属性解析部が、未解析のscope要素の要素内容を変数scopeのメンバー変数uriに設定する。ステップS209では、アクセス範囲情報解析部205の属性解析部は、ステップS206~S208で確定した変数scopeを、変数scopeListに追加登録する。ステップS210では、アクセス範囲情報解析部205の選択画面生成部は、変数scopeListを用いて、サーバ207が提供可能なサービスを選択可能に表示する為の選択用HTMLページ表示情報を生成する。そしてアクセス範囲情報解析部205の選択画面生成部は、この該生成した選択用HTMLページを、ユーザ端末装置209に対して送信する。ステップS210における処理の詳細について、図6のフローチャートを用いて説明する。なお、図6のフローチャートの各ステップにおける処理の主体は何れも、アクセス範囲情報解析部205の選択画面生成部である。ステップS302では、ユーザ端末装置209に送信するレスポンスの出力ストリームを初期化する。ステップS303では、html要素の開始タグとhead要素を出力ストリームに対して出力する。ステップS304では、body要素の開始タグと、form要素の開始タグを出力ストリームに対して出力する。ステップS305では、変数scopeListに含まれる全てのscopeオブジェクトを解析したか否かを判断する。この判断の結果、全てのscopeオブジェクトを解析している場合は、処理はステップS312に進み、まだ解析していないscopeオブジェクトが残っている場合は、処理はステップS306に進む。ステップS306では、div要素の開始タグを出力ストリームに対して出力する。ステップS307では、未解析のscopeオブジェクトのメンバ変数useの値がdefaultと等しいか否かを判断する。この判断の結果、等しい場合には、処理はステップS308に進み、等しくない場合は、処理はステップS309に進む。ステップS308では、checkboxを値とするtype属性と、scopeを値とするname属性と、scopeのメンバ変数uriを値とするvalue属性と、checked属性を含むinput要素を出力ストリームに対して出力する。ステップS309では、checkboxを値とするtype属性と、scopeを値とするname属性と、scopeのメンバ変数uriを値とするvalue属性と、を含むinput要素を出力ストリームに対して出力する。ステップS310では、未解析のscopeオブジェクトのメンバ変数iconを値とするsrc属性を含むimg要素を出力ストリームに対して出力する。ステップS311では、div要素の終了タグを出力ストリームに対して出力する。ステップS312では、form要素の終了タグと、body要素の終了タグと、html要素の終了タグを出力ストリームに対して出力する。そして、ステップS313では、レスポンスの出力ストリームをクローズする。このようにして生成した出力ストリームを、上記の選択用HTMLページとしてユーザ端末装置209に対して送信する。上記の処理により生成される選択用HTMLページを図10bに示す。また、この選択用HTMLページを受信したユーザ端末装置209の表示画面に表示される、選択用HTMLページの画面の表示例を図10aに示す。図10aに示した画面上には、form要素以下の各div要素に各サービスを利用するか否かのチェックボックスと、そのサービスを表現するアイコン画像とが配されている。図9bにおいてサービスhttps//docssampleorg/feedを含むscope要素のuse属性はdefaultであるため、図10aの画面でこのサービスに対応するチェックボックスは標準設定で選択状態にある。ユーザ端末装置209のユーザは、図10aの画面において、利用するサービスに対応するチェックボックスを指示し、その後OKボタンを指示する。これによりユーザ端末装置209からは、form要素のaction属性で指定したCGIに対して、ユーザの選択したチェックボックスの内容がGETリクエストのクエリパラメータとして送信される。このクエリパラメータには、ユーザが図10aの画面で選択したサービスに関するアクセス範囲情報が含まれている。図11aに、図10aの画面において、ユーザが文書サービスとスプレッドシートサービスのチェックボックスを選択した場合に、CGIに送信されるGETリクエストの内容を示す。ステップS211では、アクセス範囲情報解析部205の選択範囲解析部は、この送信されたクエリパラメータを受信する。そしてステップS212では、アクセス範囲情報解析部205の選択範囲解析部は、この受信したクエリパラメータを解析する。ステップS113では、アクセス範囲情報解析部205の選択範囲解析部は、この解析により判明したユーザが選択したサービスをOAuthのscopeパラメータに設定する。一方、ステップS114では、アクセス範囲情報解析部205の選択範囲解析部は、変数defaulturiのURIをOAuthのscopeパラメータに設定する。ステップS115では、認可要求送信部206は、ユーザ端末装置209を認可サーバ208にリダイレクトすべく、認可サーバ208に対して、リダイレクトメッセージを送信する。ステップS113の後にステップS115において送信されるリダイレクトメッセージを図11bに示す。このリダイレクトメッセージでは、ステップS112で取得したアクセス範囲情報をURLエンコード変換してscopeパラメータに設定している。ステップS114の後にステップS115において送信されるリダイレクトメッセージを図2に示す。このリダイレクトメッセージでは、scopeパラメータには1つのURLを設定し、情報処理装置201は、1つのWebAPIへのアクセス許可を求める。以降の処理は、図7のOAuthプロトコルの認可フローに従い、情報処理装置201によるサーバ207へのアクセスを認可した場合には、図7の手順5のように、ユーザ端末装置209を情報処理装置201にリダイレクトする。その際、認可サーバ208から取得した認証コードを用いて、図7の手順6のように、認可サーバ208からアクセストークンを取得する。そして、取得したアクセストークンを用いて、サーバ207から、そのユーザ個人の文書とスプレッドシートを取得し、印刷する。なお、上記の情報処理装置201の構成は、文書を用いたサービスを前提としたものであり、下記の構成の一例に過ぎない。即ち、情報処理装置201は、サーバ装置、ユーザ端末装置、認証サーバ装置、とデータ通信可能に接続されていることを前提とする。この前提において情報処理装置201は、サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信し、サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報をユーザ端末装置に送信する。そして情報処理装置201は、ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信する。そして、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスをサーバ装置が提供する前に認証を行う認証サーバ装置に対して送信する。そして、認証サーバ装置による認証が成功した場合には、サーバ装置に対してこの選択されたサービスを提供させるよう指示する。[第2の実施形態]本実施形態では、OAuthクライアントによるリソースプロバイダへのアクセス要求に対して、トークン不正エラー通知を受信した場合に、動的にアクセス範囲情報を取得して認可処理を行う方法について説明する。本実施形態における情報処理装置201が行う処理の流れを図12に示す。また、ユーザ、印刷サービス、認可サーバ、オフィス文書サービス、のそれぞれの間における認可処理のフローを図13に示す。まず、図13の手順1のように、ユーザ101がWebブラウザを用いて印刷サービス102にアクセスし、外部のオフィス文書サービス104内に保存しているユーザのオフィス文書の印刷を要求する。そして、印刷サービス102は、あらかじめ取得済みのアクセストークンを用いて、オフィス文書サービス104に対して、文書取得要求を送信するステップS402。そして、オフィス文書サービス104からのレスポンスを解析し、アクセストークンが不正であるというエラー通知を受信したか否かを判断するステップS403。もし、アクセストークンが不正であるというエラー通知を受信しなかった場合には、オフィス文書サービス104から指定したオフィス文書を取得するステップS404。一方、アクセストークンが不正であるというエラー通知を受信した場合には、オフィス文書サービス104のディスカバリーサービスからXRD文書を取得するステップS405。そして、ステップS103以降の処理を行うことで、認可サーバ103からアクセストークンを再発行し、オフィス文書サービス104から指定したオフィス文書を取得する。[第3の実施形態]図3に示した情報処理装置201を構成する各部はハードウェアで構成してもよいが、ソフトウェアコンピュータプログラムで実装してもよい。この場合、このソフトウェアや第1の実施形態で既知の情報として取り扱ったデータを格納するためのメモリと、このメモリに格納されているソフトウェアやデータを用いて処理を実行するCPUと、を有する装置は情報処理装置201に適用することができる。このような装置には、例えば、一般のPCパーソナルコンピュータを適用することができる。図3に示した情報処理装置201を構成する各部のうちのいくつかは統合してもよいし、いくつかを別個の装置としてもよい。即ち、第1の実施形態を実現するためのシステムの構成は、図1に示した構成に限るものではない。その他の実施例また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェアプログラムを、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータまたはCPUやMPU等がプログラムを読み出して実行する処理である。"