JP2014115895A - 情報処理装置及びその制御方法、並びにプログラム - Google Patents

Abstract

【課題】アプリケーションを操作する上でＷｅｂブラウザ上での操作が必要となった場合、ユーザー自身がアプリケーションとＷｅｂブラウザの切り替えを行う必要がある。
【解決手段】情報処理装置においてアプリケーションからＷｅｂブラウザ、Ｗｅｂブラウザからアプリケーションといった画面遷移を可能とする。
【選択図】図８

Description

本発明は、情報処理装置及びその制御方法、並びにプログラムに関する。特に、情報処理装置において動作するアプリケーションとＷｅｂブラウザとが連携する際の操作画面の制御に関する。

近年、画像処理装置においては、リアルタイム・オペレーティングシステム（以下、リアルタイムＯＳと略記する）上にさらに別の組み込みシステム向けの実行環境（例えば、Ｊａｖａ（登録商標）など）を構築している。このことにより、画像処理装置を制御するアプリケーションを外部からインストールして搭載することが可能となっている。

また、画像処理装置自体の高機能化、多機能化が進み、スキャン機能、プリント機能に関しても多種多様な画像処理装置が開発されている。近年では、スキャン機能、プリント機能といった紙文書の電子化や印刷といった基本的な機能だけでなく、ネットワーク・インターフェース（以下、ネットワークＩ／Ｆと略記する）を搭載した画像処理装置が開発されている。ネットワークＩ／Ｆを搭載した画像処理装置は、ネットワークで接続された外部システム、外部サービスと連携し、様々なソリューションを提供している。

画像処理装置が第１の外部サービスと連携し、かつ、第１の外部サービスがセキュリティドメインの異なる第２の外部サービスと連携するユースケースがある。このユースケースは、近年実用化されてきているクラウドコンピューティングシステムにより提供されるクラウドサービスが他のクラウドサービスと連携する場合にみられるユースケースである。

前記ユースケースにおいて、例えば、画像処理装置から原稿読み取りした画像データを第１の外部サービスへ送信し、更にその画像データを第１の外部サービスから第２の外部サービスへセキュリティを確保して送信する場合がある。この場合、一般的にＯＡｕｔｈと呼ばれる仕組みを利用する。ＯＡｕｔｈは、あらかじめ信頼関係を構築したサービス間でユーザーの同意のもとにセキュアにユーザーの権限を受け渡しする「認可情報の委譲」のためのオープンな仕様である。

ＯＡｕｔｈの仕組みを利用する場合、第１の外部サービスが第２の外部サービスから認可情報を受け取る必要がある。このとき、第１の外部サービスが第２の外部サービスから認可情報を受け取るためには、ユーザーによるＷｅｂブラウザからの操作が事実上必須となっている。以下、具体的に説明する。

画像処理装置上のアプリケーションによって原稿読み取りを実行し、取得した画像データに対して第１の外部サービスで処理を行い、処理後のデータを第２の外部サービスへ送信する場合、次のような処理を行う。

最初に、画像処理装置の操作画面のトップメニューからユーザーが画像処理装置上のアプリケーションを選択し、原稿読み取りを指示する。画像処理装置はユーザーからの指示に従い原稿読み取りを実行し、取得した画像データを第１の外部サービスへ送信する。第１の外部サービスは受信した画像データに対してＯＣＲ処理やＰＤＦファイルへの変換処理を行い、ファイル管理を行う第２の外部サービスへ処理後の画像データを送信する。このとき、第１の外部サービスが第２の外部サービスの認可情報を受け取っていない場合もしくは認可情報が無効になっていた場合、第１の外部サービスから第２の外部サービスへの画像データの送信処理が失敗する。

第１の外部サービスから第２の外部サービスへの画像データの送信処理が失敗した場合、次のような処理を行う。ユーザーは画像処理装置の操作画面に表示されているアプリケーションの操作画面から画像処理装置の操作画面のトップメニューに戻る。次にユーザーは新たにＷｅｂブラウザを選択し、Ｗｅｂブラウザを利用して第１の外部サービスの第２の外部サービス用認可情報取得ページにアクセスする。以降、ユーザーがＷｅｂブラウザに表示される画面に従い、認可情報取得操作を行う事で第１の外部サービスと第２の外部サービス間でＯＡｕｔｈの仕組みにしたがって情報がやり取りされ、第１の外部サービスに第２の外部サービスの認可情報が保管される。

認可情報取得操作終了後、ユーザーは再び画像処理装置の操作画面のトップメニューに戻り、アプリケーションを選択し、スキャン処理実行を指示する。画像処理装置はユーザーからの指示に従いスキャン処理実行を実行し、取得した画像データを再度第１の外部サービスへ送信する。第１の外部サービスは受信した画像データに対して再度ＯＣＲ処理やＰＤＦファイルへの変換処理を行い、再度第２の外部サービスへ処理後の画像データを送信する。

以上のように、画像処理装置の操作画面上、頻繁に画面切り替えが発生し、ユーザー操作も煩雑になっている。このような課題に対して、特許文献１では１つのアプリケーションの中で、ユーザー毎に定義された画面遷移情報に基づいて、次に表示させる画面を判定し、その結果に基づいて画面データを生成し、画面表示を行う手段を提供している。

特開２００７−２７９９７４号公報

画像処理装置のソフトウェア構成上、アプリケーションとＷｅｂブラウザは別アプリケーションとなっているため、第１の外部サービスへの認証操作の際には、Ｗｅｂブラウザからの認可操作が必要となる。また、画像処理装置の操作画面の制約から、画面上表示されるアプリケーションは１つになる。更に、画像処理装置のアプリケーション管理は統一的に行われるため、個別に、アプリケーションからＷｅｂブラウザ、Ｗｅｂブラウザからアプリケーションといった画面遷移をアプリケーション主導で行うことができない。

そのため、画像処理装置上でのユーザー操作が煩雑になっている。例えば、前記ユースケースの場合、ユーザーはスキャン処理実行操作を２回行わなければならない。また、画像処理装置上の画面操作において認可を受けるための操作を一連の流れで実施できない。

本発明に係る情報処理装置は、第１のサーバーが第２のサーバーに対して行う処理を前記第１のサーバーに指示する処理を含むアプリケーションの操作画面を表示する表示手段と、前記第１のサーバーが前記第２のサーバーに対して行う処理に用いられる認可情報が有効でない場合、前記認可情報を有効にする操作を行うブラウザを前記表示手段に表示する第１の画面制御手段と、前記認可情報を有効にする操作が終了した場合、前記表示手段に前記アプリケーションの操作画面を表示する第２の画面制御手段とを備えることを特徴とする。

本発明によれば、データ送信先でのユーザーの認可情報が有効・無効であるかの判定結果に基づいて画像処理装置上の任意のアプリケーションからＷｅｂブラウザを呼び出すことが可能となる。また、逆にＷｅｂブラウザ上での操作終了後、呼び出し元のアプリケーションに画面制御を戻すことが可能となる。

本発明の第１の実施形態にかかるシステム例の全体図である。 本発明の第１の実施形態にかかる画像処理装置１００の構成例を示すブロック図である。 本発明の第１の実施形態にかかる外部サーバーＡ１２０の構成例を示すブロック図である。 本発明の第１の実施形態にかかる画像処理装置１００のソフトウェア構成例を示す図である。 本発明の第１の実施形態にかかるアプリケーション４０８の構成例を示すブロック図である。 本発明の第１の実施形態にかかるＷｅｂブラウザ４０３の構成例を示すブロック図である。 本発明の第１の実施形態におけるアプリケーション４０８の操作画面の一例を示す図である。 本発明の第１の実施形態における処理シーケンスの一理江を示す図である。 本発明の第１の実施形態におけるアプリケーション４０８のフローチャートの一例を示す図である。 本発明の第１の実施形態におけるＷｅｂブラウザ４０３のフローチャートの一例を示す図である。 本発明の第２の実施形態における処理シーケンスの一例を示す図である。 本発明の第２の実施形態におけるアプリケーション４０８のフローチャートの一例を示す図である。 本発明の第２の実施形態におけるＷｅｂブラウザ４０３のフローチャートの一例を示す図である。

以下、本発明を実施するための形態について図面を用いて説明する。なお、以下の実施の形態は特許請求の範囲に係る発明を限定するものでなく、また実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。

（第１の実施形態）
図１は、本発明の実施形態における画像処理システムの全体の一例を示す図である。画像処理装置１００はＬＡＮ１０１を介してインターネット１１０に接続されている。また、外部サーバーＡ１２０は、ＬＡＮ１２１を介してインターネット１１０に接続されている。これらのネットワークを介して、画像処理装置１００は、外部サーバーＡ１２０と通信を行い、外部サーバーＡ１２０が提供する機能を利用することができる。更に、外部サーバーＢ１３０は、ＬＡＮ１３１を介してインターネット１１０に接続されている。これらのネットワークを介して、外部サーバーＡ１２０は、外部サーバーＢ１３０と通信を行い、外部サーバーＢ１３０が提供する機能を利用することができる。

なお、ここでは外部サーバーＡ１２０と外部サーバーＢ１３０が異なる認証ドメインで動作するサーバーであることとする。したがって、本実施形態においては、説明のため、外部サーバーＡ１２０と外部サーバーＢ１３０がインターネットを介して接続されている。しかしながら、外部サーバーＡ１２０と外部サーバーＢ１３０は、認証ドメインが異なればＬＡＮ接続されていても構わない。

また、外部サーバーＡ１２０と外部サーバーＢ１３０は、クラウドコンピューティング環境でサービスを提供しているサーバーであっても構わない。ここでは、外部サーバーＡ１２０が１台で画像処理サービスを提供する例を示す。しかしながら、外部サーバーＡ１２０の他の形態として、複数のサーバーによって構成され、そのサーバー群の中で複数のヴァーチャルマシンを起動して分散処理を行うようにしても構わない。この場合、所定の条件に応じてヴァーチャルマシンを増加させるスケールアウトと呼ばれる技術（クラウドコンピューティング）が用いられる。外部サーバーＢ１３０についても同様である。ここでは、外部サーバーＢ１３０が１台でファイル管理サービスを提供する例を示す。しかしながら、外部サーバーＢ１３０の他の形態として、複数のサーバーによって構成され、そのサーバー群の中で複数のヴァーチャルマシンを起動して分散処理を行うようにしても構わない。

図２は、第１の実施形態における画像処理装置１００の構成を示すブロック図である。ＣＰＵ２１１を含む制御部２１０は、画像処理装置１００全体の動作を制御する。ＣＰＵ２１１は、ＲＯＭ２１２に記憶された制御プログラムを読み出して読取制御や送信制御などの各種制御を行う。この制御プログラムにより後述のコントローラ制御部４０１が実装される。ＲＡＭ２１３は、ＣＰＵ２１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。

ＨＤＤ２１４は、画像データや各種プログラム、或いは各種情報テーブルを記憶する。操作部Ｉ／Ｆ２１５は、操作部２１９と制御部２１０とを接続する。操作部２１９には、タッチパネル機能を有する液晶表示部やキーボードなどが備えられている。後述する画像処理装置１００のＷｅｂブラウザ４０３、アプリケーション４０８は処理に応じて、後述するＡＰＩ４０２、仮想マシンＡＰＩ４０５を呼び出し、コントローラ制御部４０１に処理を依頼することによって操作画面を操作部２１９の液晶表示部に表示する。

プリンタＩ／Ｆ２１６は、プリンタ２２０と制御部２１０とを接続する。プリンタ２２０で印刷すべき画像データはプリンタＩ／Ｆ２１６を介して制御部２１０から転送され、プリンタ２２０において記録媒体上に印刷される。後述する画像処理装置１００のＷｅｂブラウザ４０３、アプリケーション４０８は処理に応じて、後述するＡＰＩ４０２、仮想マシンＡＰＩ４０５を呼び出し、コントローラ制御部４０１に処理を依頼することによって印刷処理を実行する。

スキャナＩ／Ｆ２１７は、スキャナ２２１と制御部２１０とを接続する。スキャナ２２１は、原稿上の画像を読み取って画像データを生成し、スキャナＩ／Ｆ２１７を介して制御部２１０に入力する。後述する画像処理装置１００のＷｅｂブラウザ４０３、アプリケーション４０８は処理に応じて、後述するＡＰＩ４０２、仮想マシンＡＰＩ４０５を呼び出し、コントローラ制御部４０１に処理を依頼することによってスキャン処理を実行し、画像データを受信する。

ネットワークＩ／Ｆ２１８は、制御部２１０（画像処理装置１００）をＬＡＮ１０１に接続する。ネットワークＩ／Ｆ２１８は、ＬＡＮ１０１上の外部装置に画像データや情報を送信したり、ＬＡＮ１０１上の外部装置から各種情報を受信したりする。

図３は、第１の実施形態における外部サービスを提供する外部サーバーＡ１２０の構成の一例を示すブロック図である。ＣＰＵ３１１を含む制御部３１０は、外部サーバーＡ１２０全体の動作を制御する。ＣＰＵ３１１は、ＲＯＭ３１２に記憶された制御プログラムを読み出して各種制御処理を実行する。ＲＡＭ３１３は、ＣＰＵ３１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ３１４は、画像データや各種プログラム、或いは後述する各種情報テーブルを記憶する。

ネットワークＩ／Ｆ３１５は、制御部３１０（外部サーバーＡ１２０）をＬＡＮ１２１に接続する。ネットワークＩ／Ｆ３１５は、ＬＡＮ１２１上の他の装置との間で各種情報を送受信する。

なお、外部サーバーＢ１３０も外部サーバーＡ１２０の構成と同じ構成とすることができる。

図４は、第１の実施形態における画像処理装置１００の基本的なソフトウェア構成の一例を示す図である。オペレーティング・システム（以下、ＯＳと略記する）４００は画像処理装置１００全体を制御する第１の実施形態の第１の実行環境の一例である。一般的にＯＳ４００は画像処理装置１００の各種機能をリアルタイムに制御可能なリアルタイムＯＳの各モジュール、或いは、ＣＰＵに命令してクリティカルに複写機のオプション装置、拡張カードを含む各機能を制御することが可能なライブラリ群から構成される。更に、ＯＳ４００はその上位で動作するアプリケーションに対して、インターフェース・コマンドを提供するモジュール群を含む。

コントローラ制御部４０１はＯＳ４００上で動作し、前述のスキャナ２２１、プリンタ２２０などを制御するモジュールにより構成されるものである。

アプリケーション・プログラミング・インターフェース（以下、ＡＰＩと略記する）４０２はアプリケーションからの命令の入力の命令列に応答して、コントローラ制御部４０１にアクセスするための処理をする機能を有する。また、ＡＰＩ４０２はネットワークＩ／Ｆ２１８を介してネットワークに接続された機器等に制御コマンドを送る機能を有する。

Ｗｅｂブラウザ４０３はＯＳ４００上で動作するアプリケーションの１つである。Ｗｅｂブラウザ４０３はＡＰＩ４０２を使用しコントローラ制御部４０１に各種処理を依頼するものである。

仮想マシン４０４は特定のアプリケーションを実行するために最適な第２の実行環境であり、例えば、Ｊａｖａ（登録商標）の仮想マシンなどにより実現されるものである。

仮想マシンＡＰＩ４０５は仮想マシン４０４上のアプリケーションがＯＳ４００上で動作するコントローラ制御部４０１にアクセスするためのＡＰＩであり、本実施形態においてはＡＰＩ４０２を呼び出すための変換モジュールの機能を有するものである。なお、本実施形態の説明においては、仮想マシン４０４上で実行されるアプリケーションとしてアプリケーション４０８、４０９を想定して説明するが、Ｗｅｂブラウザ４０３のようなアプリケーションであっても構わない。

フレームワークモジュール４０６は仮想マシン４０４上のアプリケーションを統括的に制御する機能を有する。アプリケーション管理アプリケーション４０７は仮想マシン４０４上の他のアプリケーションを管理するためのアプリケーションである。アプリケーション管理アプリケーション４０７は、フレームワーク４０６と協調し、アプリケーション４０８、４０９のダウンロード、アップロード、消去、無効化を行うものである。

アプリケーション４０８、４０９は仮想マシン４０４上で動作するアプリケーションであり、仮想マシンＡＰＩ４０５を使用しコントローラ制御部４０１に各種処理を依頼するものである。

リソース管理部４１０は仮想マシン４０４が使用する資源を管理するリソース管理部であり、ＯＳ４００上で動作する。リソース管理部４１０は、仮想マシン４０４自身、仮想マシンＡＰＩ４０５、フレームワーク４０６、或いはＯＳ４００上の全アプリケーションがメモリ等のリソース資源を使用する際、予め決められた以上の資源が使用できないように制限するものである。例えば、操作部２１９に画面を表示するアプリケーションについて、予め決められたアプリケーション上限数を超えた場合には、ＵＩ表示を行うことができない、などがある。

図５はアプリケーション４０８の構成を示すブロック図である。

ＵＩ制御部５０１は、画像処理装置が処理を行うための設定をユーザーに促すためのＵＩを表示する。例えば、スキャン処理を行う際には、ＵＩ制御部５０１は画像処理装置自体が生成可能なスキャンデータを設定させるためのＵＩを表示する。また、印刷処理を行う際には、ＵＩ制御部５０１は画像処理装置自体が印刷可能なデータの取得を設定させるためのＵＩを表示する。また、ＵＩ制御部５０１は後述のＷｅｂブラウザ連携部５０５からの依頼により、アプリケーション４０８の画面を操作部２１９の前面に表示するといった制御を行う。

スキャン処理制御部５０２は、ＵＩ制御部５０１での設定内容にしたがって、設定内容が画像処理装置自体の処理能力と整合性があっているかを考慮した処理を行う。

印刷処理制御部５０３は、ＵＩ制御部５０１での設定内容にしたがって、設定内容が画像処理装置自体の処理能力と整合性があっているかを考慮した処理を行う。

通信部５０４は、外部サーバーＡ１２０、外部サーバーＢ１３０と通信しデータの送受信や、ＦＴＰ、ＳＭＢ、ＷｅｂＤＡＶ等にしたがってファイルの送受信を行う処理を行う。

Ｗｅｂブラウザ連携部５０５は、Ｗｅｂブラウザ４０３と通信し、Ｗｅｂブラウザ４０３の呼び出しや、Ｗｅｂブラウザ４０３からの操作終了の通知を受け取るといった処理を行う。Ｗｅｂブラウザ連携部５０５は、Ｗｅｂブラウザ４０３から操作終了の通知を受け取った場合、アプリケーション４０８の画面を操作部２１９の前面に表示するようＵＩ制御部５０１に依頼する。

図６はＷｅｂブラウザ４０３の構成を示すブロック図である。

通信部６０１は、例えばＨＴＴＰプロトコル／ＨＴＴＰＳプロトコルにしたがって、外部サーバーＡ１２０や外部サーバーＢ１３０と通信する。また、アプリケーション４０８といった画像処理装置内部のアプリケーションの通信部５０４とも通信可能である。より具体的には、通信部６０１は、Ｗｅｂブラウザ４０３のＵＩ制御部６０２で表示した操作画面を介して入力される情報を外部サーバーＡ１２０などのアプリケーションに対するリクエストとして送信する。また、通信部６０１は、外部サーバーＡ１２０などのアプリケーションから送信されるレスポンス（処理結果）を受信する。

ＵＩ制御部６０２は、通信部６０１が受信したレスポンス中に含まれるＨＴＭＬファイルを解析し、解析結果に基づいて操作部２１９に操作画面を表示する。また、ＵＩ制御部６０２は後述のアプリケーション連携部６０４からの依頼により、Ｗｅｂブラウザ４０３の画面を操作部２１９の前面に表示するといった制御を行う。

セッション管理部６０３は、外部サーバーＡ１２０とＷｅｂブラウザ４０３が通信を行う際のセッション情報を管理する。

アプリケーション連携部６０４は、アプリケーション４０８と通信し、アプリケーション４０８からのＷｅｂブラウザ４０３の呼び出し要求を受信するといった処理や、アプリケーション４０８への操作終了の通知を送信するといった処理を行う。アプリケーション連携部６０４は、アプリケーション４０８からのＷｅｂブラウザ４０３の呼び出し要求を受信すると、Ｗｅｂブラウザ４０３の画面を操作部２１９の前面に表示するようＵＩ制御部６０２に依頼する。

図７は第１の実施形態におけるアプリケーション４０８の操作画面の一例を示す図である。前述のように本実施形態では、外部サーバーＡ１２０が画像処理サービスを提供しており、外部サーバーＢ１３０がファイル管理サービスを提供している。外部サーバーＡ１２０は、画像処理サービスにおいて画像処理装置１００から画像ファイルを受信して、受信した画像ファイルに対して、指定された画像処理を実施し、その結果の画像ファイルを外部サーバーＢ１３０へ送信する処理を行う。このとき、外部サーバーＡ１２０で行う画像処理に関するパラメータ等の設定や、外部サーバーＢ１３０へ送信する際の認証情報以外の送信先の情報などは、例えばチケットとして管理される。例えば、画像処理装置１００がスキャンして得た画像ファイルを外部サーバーＡ１２０へ送信する際には、予め外部サーバーＡ１２０へどのようなチケットがあるか確認し、ユーザーの指示に従いチケットを指定して画像ファイルを外部サーバーＡ１２０へ送信する。

画面７００は、画像処理装置１００が予め外部サーバーＡ１２０へどのようなチケットがあるか問い合わせし、問い合わせ結果のチケットをボタンとして操作部２１９に表示した際の表示例である。ここではチケット７０１、７０２、７０３が表示されている。ユーザーがそれぞれのチケットに対応したボタンを押下することで、画像処理装置１００はスキャンを実行し、スキャンした結果得られた画像データを画像ファイルとして、押下されたボタンに対応したチケット情報とともに外部サーバーＡ１２０へ送信する。

ここで、外部サーバーＡ１２０は、画像処理装置１００から送信された画像ファイルに対してチケットにしたがって画像処理を実施し、その結果の画像ファイルを外部サーバーＢ１３０へ送信する処理を行う。このとき、外部サーバーＡ１２０から外部サーバーＢ１３０へ送信する際には、後述のＯＡｕｔｈの仕組みで取得した認可トークンを使って、外部サーバーＡ１２０は外部サーバーＢ１３０へアクセスする。

なお、本実施形態においては、各種の情報を組み合わせたものをチケットとして管理し、そのチケットを指定することで、外部サーバーＡ１２０で行う画像処理に関するパラメータ等の設定や送信先情報などが設定される場合を例に挙げて説明した。しかしながら、チケットを用いることなく、各種の情報を必要に応じてユーザが適宜指定することによって各種の情報等が設定される形態を採用してもよい。

図８は本実施形態における処理シーケンスの一例を示す図である。

ステップＳ８００では、アプリケーション４０８が外部サーバーＡ１２０へ認証要求を送信する。前記認証要求は、アプリケーション４０８から外部サーバーＡ１２０へアクセスするために外部サーバーＡ１２０にアプリケーション４０８のユーザーを認証してもらうための要求である。アプリケーション４０８では、外部サーバーＡ１２０の認証に必要なユーザーＩＤ、パスワード等の情報を入力するための画面を操作部２１９に表示する。前記画面よりユーザー操作によって入力された認証に必要なユーザーＩＤ、パスワード等の情報をアプリケーション４０８は外部サーバーＡ１２０への認証要求に含め送信する。

ステップＳ８０１では、外部サーバーＡ１２０がアプリケーション４０８から送信された認証要求に含まれるユーザーＩＤ、パスワード等の情報を使って認証処理を行い、認証に成功したか失敗したかを返信する。ここでは、認証に成功した場合を示している。

ステップＳ８０２では、アプリケーション４０８が、外部サーバーＡ１２０が管理しているチケット情報を取得する要求を外部サーバーＡ１２０へ送信する。

ステップＳ８０３では、外部サーバーＡ１２０がアプリケーション４０８からの要求に従い、外部サーバーＡ１２０自身が管理しているチケット情報の一覧を返信する。チケット情報にはチケット名、画像処理情報、送信先情報などが含まれている。

ステップＳ８０４では、アプリケーション４０８が、ステップＳ８０３で取得したチケット情報に基づいて図７で示したような操作画面を表示する。アプリケーション４０８は、ユーザーがチケット７０１、７０２、７０３のいずれかを押下すると、アプリケーション実行指示がされたと判定する。本実施形態では、スキャン指示されたと判定する。

ステップＳ８０５では、アプリケーション４０８が、外部サーバーＡ１２０に対して外部サーバーで管理されている認可トークンの有無もしくは有効／無効を問い合わせる。すなわち、押下されたチケットに含まれる送信先情報が示す送信先（本例では外部サーバーＢ１３０）と外部サーバーＡ１２０との間の認可トークンの有無もしくは有効／無効を外部サーバーＡ１２０に問い合わせる。

ステップＳ８０６では、外部サーバーＡ１２０が、アプリケーション４０８からの問い合わせにしたがって、アプリケーション４０８からの問い合わせに含まれるチケット情報により特定される送信先に対する認可トークンを保持しているか否かを確認する。認可トークンを保持している場合は、更に外部サーバーＡ１２０は、チケット情報により特定される送信先である外部サーバーＢ１３０に対して外部サーバーＡ１２０が保持する認可トークンが有効か否か確認を行う。

ステップＳ８０７では、外部サーバーＢ１３０が、外部サーバーＡ１２０からの問い合わせにしたがって、外部サーバーＡ１２０が保持する認可トークンが有効か無効かを判定する。外部サーバーＢ１３０は判定結果を外部サーバーＡ１２０へ返信する。図８では、認可トークンが無効だった場合を示している。

ステップＳ８０８では、外部サーバーＡ１２０が、ステップＳ８０６における自身の認可トークンの有無の確認結果もしくは外部サーバーＢ１３０からの返信結果に基づいて、アプリケーション４０８に返信する。図８では、外部サーバーA１２０が認可トークンを保持していない場合、もしくは認可トークンが無効だった場合を示している。

アプリケーション４０８は、ステップＳ８０８の返信結果として認可トークンが無効であった場合、有効な認可トークンを外部サーバーＡ１２０に取得してもらう必要がある。ステップＳ８０９では、有効な認可トークンを外部サーバーＡ１２０に取得してもらうために、アプリケーション４０８がＷｅｂブラウザ４０３を呼び出す。このとき、アプリケーション４０８は、Ｗｅｂブラウザ４０３に対して認可トークンを得るために必要な情報として、外部サーバーＡ１２０へアクセスするアドレス情報であるＵＲＬ情報と、外部サーバーＡ１２０と通信中のセッション情報とを引き渡す。

ステップＳ８１０では、Ｗｅｂブラウザ４０３が、アプリケーション４０８からの呼び出しに従い、Ｗｅｂブラウザ４０３自身を操作部２１９の前面に表示する（第１の画面制御処理）。

ステップＳ８１１では、Ｗｅｂブラウザ４０３が、アプリケーション４０８から取得した外部サーバーＡ１２０へアクセスするＵＲＬ情報を元にＨＴＴＰリクエストを送信する。このとき、Ｗｅｂブラウザ４０３はアプリケーション４０８から受け取ったセッション情報を使用する。このことによって、Ｗｅｂブラウザ４０３が外部サーバーＡ１２０へアクセスする際に、アプリケーション４０８と外部サーバーＡ１２０とが通信を行っていたセッションを引き継ぐ。そのため、Ｗｅｂブラウザ４０３から外部サーバーＡ１２０へアクセスする際に、認証のためにユーザーが情報を入力する手間を省くことができる。なお、上記例ではアドレス情報としてＵＲＬを用いる例を説明したが、例えばＩＰアドレスなどを用いてもよい。

ステップＳ８１２からステップＳ８２０は、ＯＡｕｔｈの仕組みに従ったシーケンスである。

ステップＳ８１２では、外部サーバーＡ１２０がＷｅｂブラウザ４０３からのＨＴＴＰリクエストを受信する。外部サーバーＡ１２０は受信したＨＴＴＰリクエストに従い、外部サーバーＢ１３０の認可ページへアクセスするためのＵＲＬ文字列を生成する。次に、外部サーバーＡ１２０が、前記生成したＵＲＬ文字列の示すＵＲＬへリダイレクトするためのＨＴＴＰレスポンスを生成し、Ｗｅｂブラウザ４０３へ返信する。

ステップＳ８１３では、Ｗｅｂブラウザ４０３はステップＳ８１２で受け取ったＨＴＴＰレスポンスに含まれるリダイレクト先ＵＲＬにＨＴＴＰリクエストを送信する。リダイレクト先ＵＲＬは、前述のように外部サーバーＢ１３０の認可ページへアクセスするＵＲＬであるため、ＨＴＴＰリクエストは外部サーバーＢ１３０へ送信される。

ステップＳ８１４では、外部サーバーＢ１３０は認可ページへのアクセスするためのＨＴＴＰリクエストを受信し、認可ページを表すＨＴＴＰレスポンスを生成し、Ｗｅｂブラウザ４０３へ返信する。Ｗｅｂブラウザ４０３は、受信したＨＴＴＰレスポンスにしたがって認可ページを表示する。

ステップＳ８１５では、Ｗｅｂブラウザ４０３はユーザーが入力した外部サーバーＢ１３０のユーザーＩＤ、パスワードといった認可に必要な情報を認可リクエストとして外部サーバーＢ１３０に対して送信する。

ステップＳ８１６では、認可リクエストを受信した外部サーバーＢ１３０は、受信した認可に必要な情報を元に外部サーバーＡ１２０が外部サーバーＢ１３０の機能を利用してもよいかどうかを判定する。次に、外部サーバーＢ１３０は、ステップＳ８１６での判定結果として外部サーバーＡ１２０が外部サーバーＢ１３０の機能を利用してもよい場合、外部サーバーＢ１３０は認可コードを発行する。外部サーバーＢ１３０は発行した認可コードと外部サーバーＡ１２０へリダイレクトするＵＲＬを含めＨＴＴＰレスポンスを生成し、Ｗｅｂブラウザ４０３へ返信する。このとき、外部サーバーＡ１２０へリダイレクトするＵＲＬ情報は、外部サーバーＢ１３０に予め登録されていてもよいし、ステップＳ８１２で外部サーバーＡ１２０が生成したＵＲＬ文字列に含まれていてもよい。

ステップＳ８１７では、Ｗｅｂブラウザ４０３が、前記外部サーバーＢ１３０から返信されたＨＴＴＰレスポンスに含まれるリダイレクトするＵＲＬと認可コードとを取得する。Ｗｅｂブラウザ４０３はステップＳ８１７で取得したＵＲＬを元に外部サーバーＡ１２０へ前記認可コードを含めたＨＴＴＰリクエストを認可トークン取得リクエストとして送信する。

ステップＳ８１８では、Ｗｅｂブラウザ４０３からの認可トークン取得リクエストを受信した外部サーバーＡ１２０は、リクエストに含まれる認可コードを取得して外部サーバーＢ１３０へ認可トークン取得要求を送信する。

ステップＳ８１９では、前記認可トークン取得要求を受信した外部サーバーＢ１３０が、要求に含まれる認可コードを検証し、認可コードが正しければ認可トークンを発行する。外部サーバーＢ１３０は発行した認可トークンを前記認可トークン取得要求に対する応答として外部サーバーＡ１２０へ返信する。

ステップＳ８２０では、外部サーバーＡ１２０は、外部サーバーＢ１３０へアクセス時の認可トークンとして、前記受信した認可トークンを外部サーバーＡ１２０にアクセス中のユーザー（Ｓ８００、Ｓ８０１で認証したユーザー）に関連付けて保管する。外部サーバーＡ１２０は、外部サーバーＡ１２０にアクセス中のユーザーが以降外部サーバーＢ１３０へアクセスする際には前記保管した認可トークンを用いてアクセスする。更に、外部サーバーＡ１２０は、ステップＳ８１７の認可トークン取得リクエストのレスポンスを返信する。このレスポンスには、アプリケーション４０８へのリダイレクトＵＲＬを含む。

ステップＳ８２１では、ステップＳ８２０のレスポンスを受信したＷｅｂブラウザ４０３はレスポンスに含まれるリダイレクトＵＲＬを取得し、ＨＴＴＰリクエストをリダイレクト先へ送信する。このとき、Ｗｅｂブラウザ４０３から送信するＨＴＴＰリクエストは認可操作終了リクエストであり、リダイレクト先は、アプリケーション４０８になっている。つまり、アプリケーション４０８はＷｅｂブラウザ４０３から認可操作終了リクエストを受信することになる。

ステップＳ８２２では、アプリケーション４０８はＷｅｂブラウザ４０３から受信した認可操作終了リクエストにより、認可操作終了と判定する。

ステップＳ８２３では、アプリケーション４０８は操作部２１９の前面にアプリケーション４０８自身の操作画面を表示する（第２の画面制御処理）。

図９は本実施形態におけるアプリケーション４０８のフローチャートをの一例を示す図である。図９のフローチャートに示す各動作（ステップ）は画像処理装置１００のＣＰＵ２１１がＨＤＤ２１４などに記憶された制御プログラムを実行することにより実現される。

ステップＳ９００において、ユーザーによる操作部２１９からの指示によりＵＩ制御部５０１が外部サーバーＡ１２０にアクセスするためのログイン画面を表示する。ログイン画面は外部サーバーＡ１２０の認証に必要な情報（ユーザーＩＤ、パスワード等）の入力エリアを持つものとする。次に、ＵＩ制御部５０１はユーザーによるログイン画面への入力操作により、外部サーバーＡ１２０の認証に必要な情報（ユーザーＩＤ、パスワード等）を取得する。ＵＩ制御部５０１は前記取得した外部サーバーＡ１２０の認証に必要な情報（ユーザーＩＤ、パスワード等）を通信部５０４に送信する。通信部５０４は、ＵＩ制御部５０１からの外部サーバーＡ１２０の認証に必要な情報（ユーザーＩＤ、パスワード等）を外部サーバーＡ１２０への認証要求に含め、認証要求を外部サーバーＡ１２０へ送信する。

ステップＳ９０１において、通信部５０４は、外部サーバーＡ１２０からの認証要求に対する応答を受信し、応答に含まれる認証結果を取得する。認証結果として認証成功している場合は、ステップＳ９０２に進み、認証失敗している場合は、通信部５０４は認証結果をＵＩ制御部５０１へ通知する。認証失敗の旨、通知を受けたＵＩ制御部５０１はエラーメッセージを表示し、処理を終了する。

認証が成功している場合、ステップＳ９０２において、通信部５０４は、認証要求に対する応答に含まれるセッション情報をＨＤＤ２１４もしくはＲＡＭ２１３に格納する。以降、通信部５０４は一連の処理を終了するまで、外部サーバーＡ１２０と通信する際はＨＤＤ２１４もしくはＲＡＭ２１３に格納したセッション情報を要求やリクエストに含めて送信する。次に、通信部５０４は、外部サーバーＡ１２０に対してチケット一覧を要求するためにチケット取得要求を送信する。更に、通信部５０４は外部サーバーＡ１２０からチケット取得要求に対する応答を受信する。

ステップＳ９０３において、通信部５０４は受信したチケット取得要求に対する応答の中からチケット一覧を取得し、チケット一覧情報をＵＩ制御部５０１へ送信する。チケット一覧情報を受信したＵＩ制御部５０１は、操作部２１９に図７のようなチケット一覧表示画面を表示する。

ステップＳ９０４において、ＵＩ制御部５０１は、前記チケット一覧表示画面からのユーザー操作によるチケット実行指示を待つ。

ステップＳ９０５において、ＵＩ制御部５０１は、操作部２１９からユーザー操作により、ある１つのチケットを選択してチケット実行指示があったか否かを判定する。チケット実行指示があった場合は、Ｓ９０６へ進み、チケット実行指示がなかった場合はステップＳ９０４へ戻りチケット実行指示を待つ。

ステップＳ９０６において、ＵＩ制御部５０１はチケット実行指示があった旨とチケット情報とを通信部５０４へ通知する。通知を受けた通信部５０４は、チケット情報を含む認可情報有効確認要求を外部サーバーＡ１２０へ送信する。外部サーバーＡ１２０は受信したチケット情報に含まれている送信先への認可トークンを保持しているか否か、さらに、保持している場合は有効か否かを確認し、その結果を応答として通信部５０４に返信する。通信部５０４は認可情報有効確認要求に対する応答を外部サーバーＡ１２０から受信する。

ステップＳ９０７において、通信部５０４は認可情報有効確認要求に対する応答の中から、外部サーバーＡ１２０が保持している外部サーバーＢ１３０の認可トークンが有効か無効かの判定結果を取得する。判定結果、認可トークンが有効な場合はステップＳ９０８へ進み、無効な場合はステップＳ９１１へ進む。なお、外部サーバーＡ１２０が認可トークンを保持していないと判定した場合も、無効な場合と同様にステップＳ９１１へ進む。

なお、外部サーバーＡ１２０が保持している外部サーバーＢ１３０に対する認可トークンは、外部サーバーＡ１２０が受信した画像ファイルを画像処理して、外部サーバーＢ１３０へ送信する際に使用される。また、チケットに含まれている情報としては、チケットを識別するための識別子およびチケット名称、外部サーバーＡ１２０における画像処理に関するパラメータ、および送信先（例、外部サーバーＢ１３０）の指定などである。

認可トークンが有効であったため、ステップＳ９０８において、通信部５０４は当該アプリケーション４０８の実行が可能と判定する。本実施形態では、通信部５０４はスキャン処理実行可能と判定し、スキャン処理制御部５０２にスキャン実行を依頼する。スキャン処理制御部５０２は通信部５０４からのスキャン実行依頼により、コントローラ制御部４０１に処理を依頼し、スキャン処理を実行する。

ステップＳ９０９において、スキャン処理制御部５０２は、スキャン処理結果得られた画像データを取得し、ＰＤＦファイルなどのファイル形式にフォーマット変換処理を行う。

ステップＳ９１０において、スキャン処理制御部５０２は通信部５０４へ前記ステップＳ９０９にて生成した画像ファイルを送信する。画像ファイルを受信した通信部５０４は、前記ステップＳ９０６にて受け取ったチケット情報とともに画像ファイルを外部サーバーＡ１２０へ送信する。画像ファイルを受け取った外部サーバーＡ１２０は、チケット情報にしたがって画像処理を実行し、前記認可トークンを用いて画像処理結果の画像ファイルを外部サーバーＢ１３０へ送信する。

一方、認可トークンが無効であった場合、ステップＳ９１１において、通信部５０４はＷｅｂブラウザ連携部５０５に前記認可トークンが無効であった旨を通知する。Ｗｅｂブラウザ連携部５０５は、認可操作終了後にＷｅｂブラウザ４０３からリクエストを送信してもらうためのアプリケーション４０８自身のＵＲＬを生成する。

ステップＳ９１２において、Ｗｅｂブラウザ連携部５０５はＷｅｂブラウザ４０３に対して、外部サーバーＡ１２０の認可情報取得ページへのＵＲＬに前記生成したアプリケーション４０８のＵＲＬをクエリー文字列として追加したＵＲＬ文字列を生成する。次にＷｅｂブラウザ連携部５０５は、前記生成したＵＲＬ文字列をＷｅｂブラウザ４０３に送信する。このとき、Ｗｅｂブラウザ連携部５０５は、前記ステップＳ９０２において通信部５０４が格納したセッション情報を取得し、セッション情報もＷｅｂブラウザ４０３へ送信する。このことにより、画像処理装置１００の操作部２１９の前面にＷｅｂブラウザ４０３が表示される。その際、Ｗｅｂブラウザ４０３は前記生成したＵＲＬ文字列を元にＨＴＴＰリクエストを送信し、外部サーバーＡ１２０の認可情報取得ページへアクセスする。外部サーバーＡ１２０は、受信したＨＴＴＰリクエストのクエリー文字列を保管し、Ｓ８２０で述べた認可操作終了時の処理のリダイレクト先ＵＲＬとして使用する。

ステップＳ９１３は、前記ステップＳ９１２において画像処理装置１００の操作部２１９に表示されたＷｅｂブラウザ４０３上でのユーザーによる一連の操作が終了した際の処理になる。ステップＳ９１３において、Ｗｅｂブラウザ４０３の通信部６０１は、ステップＳ９１１、Ｓ９１２で説明したアプリケーション４０８自身のＵＲＬに対してＨＴＴＰリクエストを送信する。Ｗｅｂブラウザ４０３からのＨＴＴＰリクエストは、Ｗｅｂブラウザ連携部５０５が受信する。本実施形態においては、外部サーバーＡ１２０からのレスポンスに含まれるリダイレクトＵＲＬとしてアプリケーション４０８自身のＵＲＬが含まれる。そのため、Ｗｅｂブラウザ４０３の通信部６０１はアプリケーション４０８自身のＵＲＬに対してＨＴＴＰリクエストを送信することが可能となっている。

ステップＳ９１４において、Ｗｅｂブラウザ連携部５０５はＷｅｂブラウザ４０３からのＨＴＴＰリクエストから、前記ステップＳ９１１において生成したＵＲＬへのリクエストか否かを判定する。前記ステップＳ９１１において生成したＵＲＬへのリクエストであった場合、ステップＳ９１５へ進む。また、前記ステップＳ９１１において生成したＵＲＬへのリクエストでなかった場合、ステップＳ９１６へ進む。

ステップＳ９１５において、Ｗｅｂブラウザ連携部５０５は前記ＨＴＴＰリクエストに対する応答として成功を意味するＨＴＴＰステータスコード２００のレスポンスを送信する。次に、Ｗｅｂブラウザ連携部５０５は、ＵＩ制御部５０１に対して操作画面表示依頼を通知する。操作画面表示依頼を受信したＵＩ制御部５０１は、アプリケーション４０８の操作画面を画像処理装置１００の操作部２１９の前面に表示する。

一方、ステップＳ９１６において、Ｗｅｂブラウザ連携部５０５は前記ＨＴＴＰリクエストに対する応答としてＨＴＴＰステータスコード４００などのエラーステータスのレスポンスを送信する。

図１０は本実施形態におけるＷｅｂブラウザ４０３のフローチャートを示す図である。図１０のフローチャートに示す各動作（ステップ）は画像処理装置１００のＣＰＵ２１１がＨＤＤ２１４に記憶された制御プログラムを実行することにより実現される。

ステップＳ１０００において、前記ステップＳ９１２において説明したアプリケーション４０８のＷｅｂブラウザ連携部５０５から送信されるＵＲＬ文字列とセッション情報とをアプリケーション連携部６０４が受信する。

ステップＳ１００１において、アプリケーション連携部６０４は、前記Ｗｅｂブラウザ連携部５０５から受信したＵＲＬ文字列とセッション情報とを通信部６０１へ送信する。通信部６０１は、前記ＵＲＬ文字列の示すＵＲＬへＨＴＴＰリクエストを送信する。このとき、ＨＴＴＰリクエストの送信先は外部サーバーＡ１２０になっており、通信部６０１はＨＴＴＰリクエストを生成する際に、セッション情報をＣｏｏｋｉｅに含める。このことにより、Ｗｅｂブラウザ４０３が外部サーバーＡ１２０と通信を行う際に、アプリケーション４０８と外部サーバーＡ１２０との通信セッションを引き継ぐことが可能となる。また、通信部６０１はセッション情報およびＷｅｂブラウザ４０３が本通信セッション中に外部サーバーＡ１２０とやり取りした情報をセッション管理部６０３に渡す。セッション管理部６０３は、受け取ったセッション情報およびＷｅｂブラウザ４０３が本通信セッション中に外部サーバーＡ１２０とやり取りした情報をＲＡＭ２１３もしくはＨＤＤ２１４に保管し、管理する。

ステップＳ１００２において、通信部６０１はＵＩ制御部６０２に操作画面表示依頼を通知する。操作画面表示依頼を受信したＵＩ制御部６０２は、Ｗｅｂブラウザ４０３の操作画面を画像処理装置１００の操作部２１９の前面に表示する。ここで、表示されるＷｅｂブラウザ４０３の画面は、前記ステップＳ１００１で送信したＨＴＴＰリクエストに対するレスポンスが表示される。前述のように外部サーバーＡ１２０とアプリケーション４０８との通信セッションを引き継いでＷｅｂブラウザ４０３と外部サーバーＡ１２０が通信を行うため、Ｗｅｂブラウザ４０３からの外部サーバーＡ１２０への認証操作は不要となる。

以上の通り、第１の実施形態において、画像処理装置１００の操作部２１９上、アプリケーション４０８とＷｅｂブラウザ４０３との間で画面制御を行うことで一連の流れでの操作を提供することが可能となる。また、そのため、想定ユースケースにおいて、ユーザーは原稿読み取り操作を１回のみ行えばよいことになる。更に、アプリケーション４０８からＷｅｂブラウザ４０３に画面制御が移った際に、接続先サーバー（サービス）への認証操作も不要となる。

なお、第１の実施形態においては、画像処理装置１００においてスキャンを行う場合について説明した。他の実施形態として、印刷を行う際に画像処理装置１００と外部サーバーＡ１２０、外部サーバーＡ１２０と外部サーバーＢ１３０間で通信を行う場合に発生する同様の課題にも適用可能である。

（第２の実施形態）
第２の実施形態では、画像処理装置１００のアプリケーション４０８とＷｅｂブラウザ４０３との連携時、ユーザーの認可操作によってＷｅｂブラウザ４０３内に保管される情報（セッション情報、キャッシュ）を削除する仕組みを提供する。このことによって、Ｗｅｂブラウザ４０３操作時の情報漏えいなどユーザーのセキュリティに対するリスクを低減することを可能とする。

第２の実施形態における画像処理装置および外部サーバーの構成等については、基本的に第１の実施形態で説明した構成と同様の構成とすることができる。以下では第１の実施形態と異なる点を中心に説明する。

図１１は本実施形態における処理シーケンスを示す図である。なお、図１１におけるステップＳ８００〜Ｓ８２３は、第１の実施形態における図８におけるステップＳ８００〜Ｓ８２３と同じ処理とすることができるので説明を割愛する。

ステップＳ１１００では、認可操作終了と判定したアプリケーション４０８が、Ｗｅｂブラウザ４０３に対してセッション破棄要求を送信する。

ステップＳ１１０１では、セッション破棄要求を受信したＷｅｂブラウザ４０３は、ステップＳ８０９〜Ｓ８２１までの操作履歴、キャッシュ、セッション情報を削除する。つまり、Ｗｅｂブラウザ４０３は、ステップＳ８０９においてアプリケーション４０８から引き渡されたセッション情報およびステップＳ８１０〜Ｓ８２１までにＷｅｂブラウザ４０３上でユーザーが操作した画面情報のキャッシュを削除する。

図１２は本実施形態におけるアプリケーション４０８のフローチャートを示す図である。図１２のフローチャートに示す各動作（ステップ）は画像処理装置１００のＣＰＵ２１１がＨＤＤ２１４などに記憶された制御プログラムを実行することにより実現される。

なお、図１２におけるステップＳ９００〜Ｓ９１６は、第１の実施形態における図９におけるステップＳ９００〜Ｓ９１６と同じ処理とすることができるので説明を割愛する。

ステップＳ１２００において、Ｗｅｂブラウザ連携部５０５はＷｅｂブラウザ４０３に対してセッション破棄要求を送信する。

図１３は本実施形態におけるＷｅｂブラウザ４０３のフローチャートを示す図である。図１３のフローチャートに示す各動作（ステップ）は画像処理装置１００のＣＰＵ２１１がＨＤＤ２１４に記憶された制御プログラムを実行することにより実現される。

なお、図１３におけるステップＳ１０００〜Ｓ１００２は、第１の実施形態における図１０におけるステップＳ１０００〜Ｓ１００２と同じ処理とすることができるので説明を割愛する。

ステップＳ１３００において、アプリケーション連携部６０４はＷｅｂブラウザ４０３のＷｅｂブラウザ連携部５０５からセッション破棄要求を受信しているか否か判定する。セッション破棄要求を受信している場合はステップＳ１３０１へ進む。セッション破棄要求を受信していない場合は処理を終了する。

ステップＳ１３０１において、アプリケーション連携部６０４はセッション管理部６０３にセッション破棄を依頼する。セッション管理部６０３は前記ステップＳ１００１において通信部６０１から受け取ったセッション情報およびＷｅｂブラウザ４０３が本通信セッション中に外部サーバーＡ１２０とやり取りした情報を保管したＲＡＭ２１３もしくはＨＤＤ２１４から削除する。

以上の通り、第２の実施形態において、画像処理装置１００の操作部２１９上、アプリケーション４０８とＷｅｂブラウザ４０３との間で画面制御を行うことで一連の流れでの操作を提供することが可能となる。更に、アプリケーション４０８からＷｅｂブラウザ４０３に画面制御が移った際に行われた操作のセッション情報、キャッシュを削除することが可能となる。このことは、Ｗｅｂブラウザ４０３操作時の情報漏えいなどユーザーのセキュリティに対するリスクを低減することを可能とする。

（その他の実施形態）
なお、上記例においては、第１のサーバーに所定の画像処理をさせて、処理後のデータを第２のサーバーに送信させる例を説明した。しかしながら、第１のサーバーに所定の情報処理を行わせるために、第１のサーバーに第２のサーバーから所定の情報を取得させるといった情報処理に本発明を適用してもよい。

上記例においては、画像処理装置上のアプリケーションとＷｅｂブラウザとの連携を例に挙げて説明した。しかしながら、上記のように情報処理装置上のアプリケーションとＷｅｂブラウザとの連携に適用する実施形態を採用することも可能である。すなわち、操作画面の大きさに制約があるような情報処理装置、または、マルチウィンドウに対応していないような情報処理装置においては、前述した課題と同様の課題が生じることが考えられる。そのような場合においても、上述した各実施形態の構成を採用することによって、任意のアプリケーションとＷｅｂブラウザとの間の画面制御を行うことが可能となる。

なお、本発明の目的は、以下の処理を実行することによっても達成される。すなわち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体をシステム或いは装置に供給し、システム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードおよび該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

Claims (9)

1. 第１のサーバーが第２のサーバーに対して行う処理を前記第１のサーバーに指示する処理を含むアプリケーションの操作画面を表示する表示手段と、
   前記第１のサーバーが前記第２のサーバーに対して行う処理に用いられる認可情報が有効でない場合、前記認可情報を有効にする操作を行うブラウザを前記表示手段に表示する第１の画面制御手段と、
   前記認可情報を有効にする操作が終了した場合、前記表示手段に前記アプリケーションの操作画面を表示する第２の画面制御手段と
   を備えることを特徴とする情報処理装置。
2. 第１のサーバーが第２のサーバーに対して行う処理を前記第１のサーバーに指示する処理を含むアプリケーションの操作画面を表示する表示手段と、
   前記第１のサーバーが前記第２のサーバーに対して行う処理に用いられる認可情報が有効であるかを判定する判定手段と、
   前記判定手段で前記認可情報が有効でないと判定された場合、前記認可情報を有効にする操作を行うブラウザを前記アプリケーションの操作画面に代えて前記表示手段に表示する第１の画面制御手段と、
   前記認可情報を有効にする操作が終了した場合、前記ブラウザに代えて前記表示手段に前記アプリケーションの操作画面を表示する第２の画面制御手段と
   を備えることを特徴とする情報処理装置。
3. 前記ブラウザは、前記アプリケーションと前記第１のサーバーとの間のセッション情報を用いて前記認可情報を有効にする操作を行うことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記ブラウザは、前記認可情報を有効にする操作が終了した際に、前記セッション情報を削除することを特徴とする請求項３に記載の情報処理装置。
5. 前記ブラウザは、前記アプリケーションから通知されたアドレス情報に従って、前記第１のサーバーが前記第２のサーバーから認可情報を取得するよう前記第１のサーバーに要求することを特徴とする請求項１から４のいずれかに記載の情報処理装置。
6. 前記アドレス情報は、前記認可情報を有効にする操作が終了した際に用いられる前記アプリケーションの呼び出し情報を含むことを特徴とする請求項５に記載の情報処理装置。
7. 前記アプリケーションは、第１の実行環境で実行され、前記ブラウザは前記第１の実行環境とは異なる第２の実行環境で実行されることを特徴とする請求項１から６のいずれかに記載の情報処理装置。
8. 表示手段を備えた情報処理装置の制御方法であって、
   第１のサーバーが第２のサーバーに対して行う処理を前記第１のサーバーに指示する処理を含むアプリケーションの操作画面を表示する表示ステップと、
   前記第１のサーバーが前記第２のサーバーに対して行う処理に用いられる認可情報が有効でない場合、前記認可情報を有効にする操作を行うブラウザを前記表示手段に表示する第１の画面制御ステップと、
   前記認可情報を有効にする操作が終了した場合、前記表示手段に前記アプリケーションの操作画面を表示する第２の画面制御ステップと
   を備えることを特徴とする情報処理装置の制御方法。
9. コンピュータを、請求項１から７のいずれかに記載の情報処理装置として機能させるためのプログラム。

Images