JP6971597B2 - 情報処理装置、表示制御方法、及びプログラム - Google Patents

Description

本発明は、Ｗｅｂサーバーに接続され、当該Ｗｅｂサーバーにより提供されるサービスを利用する情報処理装置および表示制御方法、プログラムに関する。

ＰＣなどの情報処理装置がネットワーク上のＷｅｂサーバーに接続され、Ｗｅｂサーバー上のＷｅｂアプリケーションにより提供される操作画面を、情報処理装置が備えるＷｅｂブラウザー上に表示することが知られている。この場合、まず情報処理装置のＷｅｂブラウザーが、Ｗｅｂサーバー上のＷｅｂアプリケーションに対して操作画面を要求（リクエスト）する。そして、Ｗｅｂアプリケーションが情報処理装置からの要求に応えて、Ｗｅｂブラウザーに操作画面を表示させるためのＨＴＭＬデータを情報処理装置に応答（レスポンス）する。情報処理装置のＷｅｂブラウザーは、受信したＨＴＭＬデータを解析し、ＨＴＭＬデータの記述に基づいた操作画面を表示する。更に、Ｗｅｂブラウザーに表示された操作画面を介してユーザーが指示を入力すると、入力された指示をＷｅｂブラウザーがＷｅｂサーバーに対して通知する。そして、この通知を受けたＷｅｂサーバー上のＷｅｂアプリケーションは、入力された指示に従って処理を実行する。

近年、スキャナやプリンタを備えたＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）と呼ばれる画像処理装置の中にも、上述したようなＷｅｂブラウザーを備えているものがある。一方で、Ｗｅｂブラウザーで認証してＷｅｂサービスの利用を認可する仕組みとしてＯＡｕｔｈが業界標準となっている。ＯＡｕｔｈでは、リソースオーナーの同意のもとでその権限の一部がクライアントに移譲され、クライアントは委譲された権限の範囲でリソースへのアクセス許可を取得する。一般的に、ＷｅｂアプリケーションがＯＡｕｔｈに対応する場合、Ｗｅｂブラウザー上で認可サーバー等へのリダイレクトを繰り返して認可コードを取得する。また、組み込みアプリケーションがＯＡｕｔｈに対応する場合、Ｗｅｂブラウザーを介して認可コードを取得する。例えば、特許文献１では、ＭＦＰに搭載された組み込みアプリケーションがＷｅｂブラウザーを制御してＯＡｕｔｈ認可に対応している。

特開２０１４−１１５８９５号公報

ＯＡｕｔｈ認可に対応したＷｅｂアプリケーションをＷｅｂブラウザーから利用する場合、たとえばリダイレクト先の認可アプリケーションにより提供される認証画面を表示中であっても、ユーザーはＷｅｂブラウザーの「戻る」ボタンを押下して履歴に記録されたＵＲＬを開くことで認証操作を中断できる。その場合、Ｗｅｂブラウザーは、認可アプリケーションの認証画面からＷｅｂアプリケーションの操作画面へ戻ることが可能である。しかしながら、特許文献１のような組み込みアプリケーションの場合、ユーザーがＷｅｂブラウザーの戻るボタンを押下しても履歴に記録されたＵＲＬが開かれるだけであり、Ｗｅｂブラウザーから組み込みアプリケーションの操作画面に戻る手段がないという課題がある。

本発明は上記従来例に鑑みて成されたもので、アプリケーションがＷｅｂブラウザーを介して行っている認可処理をユーザーが中断しても、アプリケーションの操作画面に戻ることが可能な情報処理装置を提供することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。

本発明の一側面によれば、指示に応じてリソースを要求し、要求したリソースを取得する取得手段と、
前記リソースの履歴を記憶する記憶手段と、
戻り指示を入力するための入力部を含む、取得した前記リソースに基づく画面を表示手段により表示させる表示制御手段と、
前記戻り指示の入力を受けた場合、戻り先を決定する決定手段と、
前記リソースの要求の元となるアプリケーションから認可要求を受けた場合、認可モードであることを示す情報を保持する保持手段とを有し、
前記リソースの要求の元となるアプリケーションから認可要求を受けた場合、前記取得手段は、前記アプリケーションから受けた認可要求に応じて認可要求に関するリソースを要求し、要求した認可要求に関するリソースを取得し、
前記決定手段は、前記保持された情報に基づいて認可モードである場合は、前記リソースの要求の元となるアプリケーションの画面を戻り先として決定し、認可モードでない場合は、前記履歴に基づいて直前の画面を戻り先として決定し、
決定した前記戻り先に応じた画面を前記表示手段により表示させることを特徴とする情報処理装置が提供される。

本発明によれば、アプリケーションがＷｅｂブラウザーを介して行っている認可処理をユーザーが中断しても、アプリケーションの操作画面に戻ることができる。

本発明の第１の実施形態におけるＭＦＰの接続されるシステムの全体図である。 本発明の第１の実施形態におけるＭＦＰのハードウェア構成を示すブロック図である。 本発明の第１の実施形態におけるＷｅｂサーバーのハードウェア構成を示すブロック図である。 本発明の第１の実施形態におけるＭＦＰのソフトウェア構成を示す図である。 本発明の第１の実施形態におけるＷｅｂサーバーのソフトウェア構成を示す図である。 本発明の第１の実施形態における認可処理キャンセルの流れを示すシーケンス図である。 本発明の第１の実施形態において用いられるＵＲＩの一例である。 本発明の第１の実施形態における認可制御サービスが保持するアプリケーション識別情報の一例である。 本発明の第１の実施形態におけるＷｅｂブラウザーの操作画面の一例である。 本発明の第１の実施形態における戻るボタン押下時のＷｅｂブラウザーの処理の流れを示すフローである。 本発明の第１の実施形態における認可制御サービスが認可完了通知を受信したときの処理の流れを示すフローである。 本発明の第１の実施形態におけるアプリケーションが認可完了通知を受信したときの処理の流れを示すフローである。 本発明の第１の実施形態におけるアプリケーションの操作画面の一例である。 本発明の第２の実施形態における認証画面の一例である。 本発明の第２の実施形態における戻るボタン押下時のＷｅｂブラウザーの処理の流れを示すフローである。 本発明の第２の実施形態の変形例１における戻るボタン押下時のＷｅｂブラウザーの処理の流れを示すフローである。 本発明の第２の実施形態の変形例２における戻るボタン押下時のＷｅｂブラウザーの処理の流れを示すフローである。 本発明の第３の実施形態における認可制御サービスがアプリケーションからアプリケーション画面遷移指示を受け付けたときの処理の流れを表すフローである。

以下、本発明を実施するための形態について図面を用いて説明する。
［第１の実施形態］
図１は、画像処理装置を用いたシステムの構成例である。本システムはネットワーク１００を介して接続される画像処理装置であるＭＦＰ１０１と、Ｗｅｂサーバー１０２から構成される。ネットワーク１００は各装置間で通信を行うための基盤であって、インターネットに接続されていても良い。ＭＦＰ１０１はＷｅｂブラウザー（ウェブブラウザー）機能を有すれば、ＭＦＰ（Ｍｕｌｔｉｐｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）に限定されるものではない。Ｗｅｂサーバー１０２は、ネットワーク経由でＭＦＰ１０１と接続されており、ＭＦＰ１０１からのリクエストに応じてＷｅｂサービス４０１を提供する。なおＭＦＰ１０１は、その処理能力に着目して情報処理装置と呼ばれることもある。

＜ＭＦＰのハードウェア構成＞
図２は本実施例のＭＦＰ１０１のハードウェア構成の一例である。ＭＦＰ１０１を制御するＣＰＵ２０１、ＣＰＵ２０１のワークエリアを提供するＲＡＭ２０２、本実施形態に係るプログラムや様々な設定を記憶する記憶装置２０３（ＨＤＤやＮＶＲＡＭ等でもよい）が存在する。さらに、原稿をスキャンしてドキュメントデータを生成するスキャン装置２０３、ドキュメントデータを印刷するプリント装置２０５、ユーザーがコマンドの入力を行うユーザー入力装置２０６、画面表示を行うＵＩ表示装置２０７、他機器とネットワークによる通信を行うネットワーク装置２０８、メインバス２００により構成されている。尚、本実施例は特に断らない限り、ＭＦＰ１０１のＣＰＵ２０１がメインバス２００を介してＲＡＭ２０２、記憶装置２０３、ユーザー入力装置２０６、ＵＩ表示装置２０７、ネットワーク装置２０８を制御する。また、タッチパネルディスプレイのようにＵＩ表示装置２０７がユーザー入力装置２０６を兼ねても良い。また、ＭＦＰ１０１はその他にも画像読取装置や画像印刷装置がメインバス２００に接続されていても良い。

＜Ｗｅｂサーバーのハードウェア構成＞
図３は本実施例のＷｅｂサーバー１０２のハードウェア構成の一例である。Ｗｅｂサーバー１０２を制御するＣＰＵ３０１、ＣＰＵ３０１のワークエリアを提供するＲＡＭ３０２、本実施形態に係るプログラムや様々な設定を記憶する記憶装置３０３（ＨＤＤやＮＶＲＡＭ等でもよい）、他機器とネットワークによる通信を行うネットワーク装置３０５が存在する。尚、本実施例は特に断らない限り、Ｗｅｂサーバー１０２は、ＣＰＵ３０１がメインバス３００を介してＲＡＭ３０２、記憶装置３０３、ネットワーク装置３０４を制御する。

＜ＭＦＰのソフトウェア構成＞
図４は本実施例におけるＭＦＰ１０１のソフトウェア構成を説明するための図である。図４に示す各機能部は、ＭＦＰ１０１が有しているＣＰＵ２０１が制御プログラムを実行することにより実現される。ＭＦＰ１０１は、Ｗｅｂブラウザー４００、認可制御サービス４１０、アプリケーション４２０を有する。

Ｗｅｂブラウザー４００は、任意のサーバーと通信を行うことによって、Ｗｅｂコンテンツを受信して画面に表示したり、ユーザーの入力情報を送信したりといった機能を有するものであればよい。Ｗｅｂブラウザー４００は、通信部４０１、解析部４０２、記憶部４０３、入力部４０４、表示部４０５を有する。通信部４０１は、ＨＴＴＰプロトコルに従って、Ｗｅｂサーバー１０２および認可制御サービス４１０と通信する。より具体的には、通信部４０１は、Ｗｅｂサーバー１０２に対して、認可要求に関するＨＴＴＰリクエストを送信し、認証画面や認可コードを含むＨＴＴＰレスポンスを受信する。また、通信部４０１は、認可制御サービス４１０に対して、認可コードを含むＨＴＴＰレスポンスをリダイレクトする。解析部４０２は、Ｗｅｂサーバー１０２および認可制御サービス４１０から受信したレスポンスを解析する。レスポンスの中にはＷｅｂアプリケーションの操作画面を記述するＨＴＭＬデータであったりリダイレクトすべきＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）であったりという情報が含まれている。記憶部４０３は、認可制御サービス４１０から認可要求を受ける際に、認可制御サービス４１０により指定される認可モードを記憶し、指定されたリクエストすべきＵＲＩを記憶したり、Ｗｅｂページの履歴情報を記憶したりする。入力部４０４は、ユーザー入力装置２０６を介してユーザーの操作入力を受け付ける。表示部４０５は、解析部４０２の解析結果に基づいて、ＵＩ表示装置２０７に表示するＷｅｂアプリケーション操作画面を描画する。なおＵＲＩはインターネット等の通信ネットワーク上のリソースを指し示す識別情報であり、そのネットワーク上に置ける所在も含めて特定することができる所在情報である。

認可制御サービス４１０は、ＯＡｕｔｈ２．０に従って、Ｗｅｂブラウザー４００に対して制御指示を行って、アプリケーション４２０の要求する認可コードを取得する。認可制御サービス４１０は、通信部４１１、解析部４１２、認可制御部４１３、画面制御部４１４を有する。通信部４１１は、ＨＴＴＰプロトコルに従って、Ｗｅｂブラウザー４００と通信する。より具体的には、通信部４１１は、Ｗｅｂブラウザー４００から認可完了を通知するＨＴＴＰリクエストを受信すると、認可完了を示すＨＴＴＰレスポンスをＷｅｂブラウザー４００へ送信する。解析部４１２は、通信部４１１が受信した認可完了通知を解析し、認可処理が成功したかキャンセルされたかなどを解析する。認可制御部４１３は、アプリケーション４２０から認可要求を受け付けると、アプリケーション４２０のアプリケーション識別子を記憶し、Ｗｅｂブラウザー４００に対して、アプリケーション４２０に指示されたＷｅｂサーバー１０２のＵＲＩを開くことを指示する。また、認可制御部４１３は、解析部４１２の解析結果に基づいて、認可コードまたは認可がキャンセルされたことを、記憶するアプリケーション識別子が示すアプリケーション４２０へ通知する。画面制御部４１４は、アプリケーション４２０の認可要求を受け付けると、Ｗｅｂブラウザー４００の操作画面をＵＩ表示装置２０５に表示する。この結果、ＵＩ表示装置２０５に表示される操作画面はアプリケーション４２０からＷｅｂブラウザー４００へ遷移する。

アプリケーションには様々な機能を持たせることができるが、本例のアプリケーション４２０は、Ｗｅｂサービス（あるいはＷｅｂアプリケーション）を利用するための入口として機能する。アプリケーション４２０は、たとえばユーザーが基本メニュー画面から入力したアプリケーション４２０の起動の指示に応じて起動され、ユーザインタフェースを表示する。ユーザインタフェース上で所定の操作に応じて、その操作に関連付けられたＷｅｂサービスを利用するための手続きを実行する。もちろんこれは一例に過ぎない。アプリケーション４２０は、入力部４２１、認可要求部４２２、通信部４２３、表示部４２４を有する。入力部４２１はユーザー入力装置２０６を介してアプリケーション４２０の操作入力を受け付ける。認可要求部４２２は、認可制御サービス４１０へ認可処理の開始を要求する。より具体的には、認可要求部４２２は、Ｗｅｂブラウザー４００に対して認可モードを指定し、Ｗｅｂサーバー１０２のＷｅｂサービス５００が提供するＵＲＩへＨＴＴＰリクエストを送信することを要求する。また認可要求部４２２は、認可処理が完了すると、認可制御サービス４１０から認可コードまたは認可キャンセルされたことを表す認可完了通知を受け取る。通信部４２３は、ＨＴＴＰプロトコルに従って、Ｗｅｂサーバー１０２と通信する。より具体的には、通信部４２３は、認可制御サービス３１０から認可コードを受け取ると、Ｗｅｂサーバー１０２へ認可コードを送信しアクセストークンを受信する。更に、通信部４２３は、取得したアクセストークンを付与して、Ｗｅｂサーバー１０２に各種Ｗｅｂサービスの利用を要求する。表示部４２４は、ＵＩ表示装置２０７に表示するアプリケーション操作画面を描画する。

アプリケーション４２０は、たとえばＭＦＰ１０１のオペレーティングシステムの上に用意されたアプリケーションプラットフォームにインストールされ、実行される。アプリケーションプラットフォームは例えばＪＡＶＡ（登録商標）実行環境であり、その場合にはアプリケーションはＪＡＶＡ（登録商標）でコーディングされる。このアプリケーション４２０は、たとえばＵＩ表示装置２０７に表示された基本メニュー画面から呼び出して実行することができる。そしてその実行により、基本メニュー画面に代えてアプリケーション操作画面を表示する。ユーザーは、そのアプリケーション操作画面の操作により、アプリケーション４２０が提供する機能を利用できる。このアプリケーション４２０はＭＦＰ１０１に組み込まれてＭＦＰ１０１が提供する機能の一部として利用されるので、組み込みアプリケーションとも呼ばれる。アプリケーション４２０は、追加的にインストールすることもできるし、また、アンインストールすることもできる。

＜Ｗｅｂサーバーのソフトウェア構成＞
図５は、本発明の第１の実施形態におけるＷｅｂサーバー１０２のソフトウェア構成を示す図である。図５に示す各機能部は、Ｗｅｂサーバー１０２が有しているＣＰＵ３０１が制御プログラムを実行することにより実現される。なお以下の説明ではＷｅｂサーバーの通信相手であるクライアントはＭＦＰ１０１としているが、これは本実施形態の説明のためであって、クライアントはＭＦＰ１０１とは限らない。Ｗｅｂサービス５００は、通信部５０１、認可部５０２、記憶部５０３を有する。通信部５０１は、ＨＴＴＰプロトコルに従って、ＭＦＰ１０１と通信する。より具体的には、通信部５０１は、Ｗｅｂブラウザー４００または認可制御サービス４１０からのＨＴＴＰリクエストを受信して、ＨＴＴＰレスポンスを送信する。認可部５０２は、ＯＡｕｔｈ２．０に従って、Ｗｅｂサーバー１０２の提供する各種Ｗｅｂサービスの利用をＭＦＰ１０１に対して認可する。より具体的には、認可部５０２は、通信部５０１が認可要求を受信すると、認証画面を含むレスポンスを生成する。また、認可部５０２は、通信部５０１が認証情報を受信すると、認証情報が有効であるかどうか例えばデータベースと照合して判断して、有効であれば認可コードを含むレスポンスを生成する。また、認可部５０２は、通信部５０１が、有効な認可コードとともにアクセストークン要求を受信すると、アクセストークンを含むレスポンスを生成する。また、認可部５０２は、通信部５０１が各種Ｗｅｂサービス利用要求を受信すると、ＨＴＴＰリクエストに含まれるアクセストークンが有効であるかどうかを判断する。アクセストークンが有効であればＷｅｂサービス利用要求は受け付けられ、有効でなければ拒絶される。記憶部５０３は、各種ドキュメントファイルを管理する。より具体的には、記憶部５０３は、Ｗｅｂサーバー１０２が提供するＷｅｂサービスの一例として、ドキュメント管理サービスを提供する。例えば、記憶部５０３は、通信部５０１がドキュメントファイル一覧の参照要求を受信すると、ドキュメントファイル名の一覧を含むＨＴＴＰレスポンスを生成する。また、記憶部５０３は、通信部５０１がドキュメントファイルの取得要求を受信すると、ドキュメントファイルデータを含むＨＴＴＰレスポンスを生成する。また、記憶部５０３は、通信部５０１がドキュメントファイルのアップロード要求を受信すると、ドキュメントファイル名およびドキュメントファイルデータを保存し、アップロード結果を応答するＨＴＴＰレスポンスを生成する。

＜認可処理キャンセルシーケンス＞
図６は、本発明の第１の実施形態における認可処理キャンセルの処理及びメッセージの流れを示すシーケンス図である。ステップＳ６０１では、ユーザーの指示に従って、アプリケーション４２０が認可制御サービス４１０に対して認可処理開始を要求する。アプリケーション４２０がＷｅｂサービス５００に関連付けられているのであれば、ユーザーからの指示は、アプリケーション４２０を実行する或いはアクティブにするための指示であれば良い。このとき、アプリケーション４２０は、Ｗｅｂサービス５００に認可要求するための認可要求ＵＲＩを指定する。図７（ａ）は、本発明の第１の実施形態におけるＷｅｂサービス５００に認可要求するための認可要求ＵＲＩの一例である。ＵＲＩは、ＯＡｕｔｈ２．０に従って、クエリストリングにレスポンスタイプ、クライアントＩＤ、リダイレクトＵＲＩをパラメーターとして含む。リダイレクトＵＲＩに設定されるＵＲＩ"ｈｔｔｐ：／／１２７．０．０．１／ａｕｔｈ／ｘｘｘｘｘｘ"は、Ｗｅｂブラウザー４００が認可制御サービス４１０へ認可コードを通知するための認可完了通知ＵＲＩを表す。ＵＲＩの一部である"ｘｘｘｘｘｘ"は、アプリケーション４２０を識別するためのアプリケーション識別子である。ＩＰアドレス「１２７．０．０．１」はローカルループバックアドレスである。このＵＲＩにより、認可コードの通知先が、認可制御サービス４１０を介してアプリケーション４２０であることが特定される。本発明の第１の実施形態では、アプリケーション４２０は１つであるが、複数のアプリケーション４２０が認可処理を実行する構成であっても良い。

つぎにステップＳ６０２では、認可制御サービス４１０は、アプリケーション４２０からの認可処理開始要求に基づいて、Ｗｅｂブラウザー４００からの認可完了通知（すなわち認可コード）受付を開始する。図８は、本発明の第１の実施形態における認可制御サービス４１０が保持するアプリケーション識別情報の一例である。認可制御サービス４１０は、アプリケーション４２０が指定する認可要求ＵＲＩに含まれる認可完了通知ＵＲＩ"／ａｕｔｈ／ｘｘｘｘｘｘ"およびアプリケーション識別子"ｘｘｘｘｘｘ"をアプリケーション識別情報として保存する。

つぎにステップＳ６０３では、認可制御サービス４１０は、Ｗｅｂブラウザー４００に対して、認可モードを指定して、アプリケーション４２０に指示された認可要求ＵＲＩにＨＴＴＰリクエストを送信することを指示する。この指示はたとえば指定された認可要求ＵＲＩに対するリダイレクトの指示を含んでよい。ステップＳ６０３の指示は認可制御サービス４１０からの指示であるが、アプリケーション４２０を元とする指示ともいえる。ステップＳ６０４では、Ｗｅｂブラウザー４００は、Ｗｅｂサービス５００に対して、認可要求ＵＲＩへのＨＴＴＰリクエストを送信する。ステップＳ６０５では、Ｗｅｂサービス５００が、Ｗｅｂブラウザー４００へ認証画面を含むＨＴＴＰレスポンスを送信する。ステップＳ６０６では、Ｗｅｂブラウザー４００は、Ｗｅｂサービス５００から受信したＨＴＴＰレスポンスに基づいて、認証画面を描画する。

ステップＳ６０７では、認可制御サービス４１０がＷｅｂブラウザー４００の操作画面をＵＩ表示装置２０７に表示させる表示制御を行う。これによりＷｅｂブラウザー４００が描画した認証画面がＵＩ表示装置２０７に表示される。図６ではステップＳ６０６の後でステップＳ６０７が実行されるが、たとえばステップ６０３でＷｅｂブラウザー４００の起動後に直ちにステップＳ６０７を行ってもよい。図９は、本発明の第１の実施形態におけるＷｅｂブラウザー４００の操作画面の一例である。Ｗｅｂブラウザー４００の操作画面は、タイトルバー９０１、Ｗｅｂコンテンツ領域９０２、ツールバー９０３を有する。タイトルバー９０１は、Ｗｅｂコンテンツのタイトルを表示する領域である。Ｗｅｂコンテンツ領域９０２は、ＨＴＴＰレスポンスとして受信したＷｅｂコンテンツを描画する領域であり、Ｗｅｂブラウザー４００がＷｅｂサービス５００から受信した認証画面はこの領域に描画される。認証画面は、ユーザーＩＤを入力するためのユーザーＩＤ入力フィールド、パスワードを入力するためのパスワード入力フィールド、入力されたユーザーＩＤおよびパスワードをＷｅｂサービス５００へ送信してログインを指示するためのログインボタンを有する。ツールバー９０３は、戻るボタン９０４、進むボタン９０５、停止ボタン９０６、更新ボタン９０７、ＵＲＩバー９０８を有する。戻るボタン９０４は、Ｗｅｂブラウザー４００が管理するＷｅｂページの履歴情報を参照して前の操作画面を表示することを指示するためのＵＩである。進むボタン９０５は、Ｗｅｂブラウザー４００が管理するＷｅｂページの履歴情報を参照して次の操作画面を表示することを指示するためのＵＩである。停止ボタン９０６は、Ｗｅｂブラウザー４００の通信処理および描画処理を停止することを指示するためのＵＩである。更新ボタン９０７は、Ｗｅｂサーバー１０２と再度通信を行って、Ｗｅｂコンテンツを再取得し、Ｗｅｂコンテンツ領域を再描画することを指示するためのＵＩである。ＵＲＬバー９０８は、現在表示するＷｅｂコンテンツへのＵＲＩを表示するためのＵＩである。

つぎにステップＳ６０８では、Ｗｅｂブラウザー４００は、ユーザーが戻るボタン９０４（戻りボタンとも呼ぶ）を押下すると例えば図１０に示した処理（詳細は後述）を開始し、その処理に従って、認可制御サービス４１０へ戻る指示（単に「戻り指示」とも呼ぶ）を示すＵＲＩへＨＴＴＰリクエストを送信する。図７（ｂ）は、本発明の第１の実施形態における認可制御サービス４１０に送信される戻る指示を示すＵＲＩの一例である。戻る指示を示すＵＲＩは、通知先を示す認可完了通知ＵＲＩ"ｈｔｔｐ：／／１２７．０．０．１／ａｕｔｈ／ｘｘｘｘｘｘ"に対してクエリストリングで戻る指示を示すパラメーター"ｒｅｔｕｒｎ"を付与したものである。このＵＲＩは、リソース要求の指示元である認可制御サービス４１０を示す。通常ＯＡｕｔｈ２．０の認可処理が実行されると、Ｗｅｂブラウザー４００はＷｅｂサービス５００から受信した認可コードをクエリストリングのパラメーターとして含むレスポンスをリダイレクトすることで、認可コードを認可制御サービス４１０へ送信する。認可コードは認可制御サービス４１０からアプリケーション４２０へ引き渡される。アプリケーション４２０はその認可コードを用いてアクセストークンを取得し、Ｗｅｂサービス５００へアクセスする。一方、ユーザーが戻るボタン９０４を押下して認可処理キャンセルを指示した場合、本実施形態においては、Ｗｅｂブラウザー４００は、戻る指示を認可制御サービス４１０へ送信する。これは例えば、図７（ｂ）に示すＵＲＩにＨＴＴＰリクエストを送信することで実現される。

ステップＳ６０９では、認可制御サービス４１０は、アプリケーション４２０へ認可キャンセルを通知する。ステップＳ６１０では、アプリケーション４２０は認証がキャンセルされた旨を表す操作画面として認証キャンセル画面を作成あるいは描画する。ステップＳ６１１では、認可制御サービス４１０はアプリケーション４２０の操作画面をＵＩ表示装置２０７に表示する。つぎにステップＳ６１２では、認可制御サービス４１０は、保存したアプリケーション識別情報を削除し、アプリケーション３２０のための認可コード受付を終了する。最後にステップＳ６１３では、認可制御サービス４１０はＷｅｂブラウザー４００に認可処理終了を示すＨＴＴＰレスポンスを送信する。

一方、操作画面９０１でユーザーＩＤおよびパスワードなどのユーザー情報が入力されてログインボタンが押下された場合には、Ｗｅｂブラウザー４００は入力されたユーザー情報を操作画面情報の送信元であるＷｅｂサービス５００に送信する。Ｗｅｂサービス５００の認可部５０２は、ユーザー情報の認証が成功したなら認可コードをＷｅｂブラウザー４００に送信する。Ｗｅｂブラウザー４００は、認可コードを含む認可完了通知を、認可要求ＵＲＩ中のリダイレクトＵＲＩに宛てて送信する。図７（ａ）の例では、宛先はＵＲＩ"ｈｔｔｐ：／／１２７．０．０．１／ａｕｔｈ／ｘｘｘｘｘｘ"となっている。「戻る」指示または認可コードを受信した認可制御サービス４１０の動作は図１１を参照して後述する。

＜ＭＦＰのＷｅｂブラウザーによる「戻る」処理＞
図１０は、本発明の第１の実施形態における戻るボタン９０４押下時のＷｅｂブラウザー４００の処理の流れを示すフローである。ステップＳ１００１では、Ｗｅｂブラウザー４００の入力部４０４は、戻るボタン９０４が押下されると処理の流れを開始し、ステップＳ１００２へ進む。ステップＳ１００２では、Ｗｅｂブラウザー４００の記憶部４０３は、認可モードが記憶されているかどうか判断し、認可モードが記憶されている場合、ステップＳ１００３へ進む。それ以外の場合、ステップＳ１０１３へ進む。ステップＳ１００３では、Ｗｅｂブラウザー４００の通信部４０１は、図９に図示した認可制御サービス４１０へ戻る指示を送信し、ステップＳ１００４へ進む。一方ステップＳ１０１３では、Ｗｅｂブラウザー４００の記憶部４０３は履歴情報を参照して直前のＷｅｂページを開き、ステップＳ１００４へ進む。ステップＳ１００４では、Ｗｅｂブラウザー４００は、戻るボタン９０４押下時の処理の流れを終了する。

なお、図１０の処理手順は、Ｗｅｂブラウザー４００のプログラム中にコーディングしておいてもよいが、スクリプトにより実現してもよい。スクリプトにより実現する場合には、たとえば図６のステップＳ６０７でＷｅｂブラウザー４００を前面に表示させる指示と送信するとともにスクリプトを送信する。そのスクリプトはたとえば、その時に表示している画面（すなわちＨＴＭＬデータ）を、「戻る」の押下に応じて図１０のステップＳ１００３を実行させるように書き換えるスクリプトであってよい。

＜ＭＦＰの認可制御サービスによる処理＞
図１１は、本発明の第１の実施形態における認可制御サービス４１０が認可完了通知を受信したときの処理の流れを示すフローである。なおここでは「戻る」通知も含めて認可完了通知と呼ぶ。ステップＳ１１０１では、認可制御サービス４１０の通信部４１１は、Ｗｅｂブラウザー４００から認可完了通知ＵＲＩへのＨＴＴＰリクエストを受信すると処理の流れを開始し、ステップＳ１１０２へ進む。ステップＳ１１０２では、認可制御サービス４１０の認可制御部４１３が、ＨＴＴＰリクエストに戻る指示が含まれるかどうかを判断し、戻る指示でないと判断した場合ステップＳ１１０３へ進む。一方で、戻る指示であると判断した場合は、ステップＳ１１１３へ進む。より具体的には、図９に図示した「戻る」指示のＵＲＩの場合、クエリストリングにパラメーター"ｒｅｔｕｒｎ"を含むため、認可制御サービス４１０はこのパラメーターを参照してＨＴＴＰリクエストが戻る指示であると判断する。

ステップＳ１１０３では、認可制御サービス４１０の認可制御部３１３はアプリケーション４２０へ、認可完了通知とともに受信した認可コードを含む認可完了通知を通知し、ステップＳ１１０４へ進む。図７（ｃ）は、本発明の第１の実施形態における認可制御サービス３１０に送信される認可コードを示すＵＲＩの一例である。クエリストリングとして認可コードを示すパラメーター"ｃｏｄｅ"が指定されている。図７（ｃ）の例では、認可制御サービス４１０は、"ｃｏｄｅ"指定される値"ｌ０ｙ１ＬＹｈ７２４ＩｑｘｆｉｅＷｑｂｓ"を認可コードとしてアプリケーション４２０へ通知する。ステップＳ１１０４では、認可制御サービス３１０の画面制御部３１４は、アプリケーション４２０の操作画面をＵＩ表示装置２０７に表示し、ステップＳ１１０５へ進む。ステップＳ１１０５では、認可制御サービス４１０の認可制御部４１３は、保存されているアプリケーション４２０のアプリケーション識別情報を削除して認可コード受付を終了し、ステップＳ１１０６へ進む。ステップＳ１１０６では、認可制御サービス４１０はＷｅｂブラウザー４００に認可処理終了を示すＨＴＴＰレスポンスを送信し、ステップＳ１１０７へ進む。ステップＳ１１０７では、認可制御サービス３１０は認可完了通知を受信したときの処理を終了する。

一方ステップＳ１１１３では、認可制御サービス４１０の認可制御部４１３はアプリケーション４２０へ認可キャンセルを示す認可完了通知を通知して、ステップＳ１１０４へ進む。

＜ＭＦＰのアプリケーションによる認可完了通知の受信処理＞
図１２は、本発明の第１の実施形態におけるアプリケーション４２０が認可完了通知を受信したときの処理の流れを示すフローである。ステップＳ１２０１では、アプリケーション４２０の認可要求部４２２は、認可制御サービス４１０から認可完了通知を受けると処理の流れを開始し、ステップＳ１２０２へ進む。ステップＳ１２０２では、アプリケーション４２０の認可要求部４２２は、認可完了通知が認可コードを含むかどうかを判断し、認可コードを含む場合、ステップＳ１２０３へ進む。それ以外の場合はステップＳ１２１３へ進む。

ステップＳ１２０３では、アプリケーション４２０の通信部４２３は、取得した認可コードを付与したアクセストークン取得を要求するＨＴＴＰリクエストをＷｅｂサービス５００へ送信し、その結果としてアクセストークンを含むＨＴＴＰレスポンスを受信する。アプリケーション４２０は、アクセストークンを取得するとステップＳ１２０４へ進む。ステップＳ１２０４では、アプリケーション４２０の通信部４２３は、アクセストークンを付与したドキュメント一覧情報取得を要求するＨＴＴＰリクエストをＷｅｂサービス５００へ送信し、その結果としてドキュメント一覧情報を含むＨＴＴＰレスポンスを受信する。アプリケーション４２０は、ドキュメント一覧情報を取得するとステップＳ１２０５へ進む。ステップＳ１２０５では、アプリケーション４２０の表示部４２４は、ＵＩ表示装置２０７に表示される認証成功画面１３０１を描画し、ステップＳ１２０６へ進む。ステップＳ１２０６では、アプリケーション４２０は、認可完了通知を受信したときの処理の流れを終了する。

一方ステップＳ１２１３では、アプリケーション４２０の認可要求部４２２は、認可完了通知が認可キャンセルかどうかを判断し、認可キャンセルの場合、ステップＳ１２１４へ進む。それ以外の場合はステップＳ１２２４へ進む。ステップＳ１２１４では、アプリケーション４２０の表示部４２４は、ＵＩ表示装置２０７に表示される認証キャンセル画面１３０２を描画し、ステップＳ１２０６へ進む。一方で、ステップＳ１２２４では、アプリケーション４２０の表示部４２４は、ＵＩ表示装置２０７に表示される認証エラー画面１３０３を描画し、ステップＳ１２０６へ進む。

＜アプリケーションの操作画面＞
図１３は、本発明の第１の実施形態におけるアプリケーション４２０の操作画面の一例である。認証成功画面１３０１は、ドキュメントファイル一覧、スキャンボタン、プリントボタンを有する。ドキュメントファイル一覧は、アプリケーション４２０がアクセストークンを使用してＷｅｂサービス５００の記憶部から取得したドキュメントファイル情報の一覧を表示するためのＵＩである。スキャンボタンは、スキャン装置を制御して生成されたドキュメントデータをＷｅｂサービス５００へアップロードすることを指示するためのＵＩである。プリントボタンは、ドキュメントファイル一覧で選択されたドキュメントファイルをＷｅｂサービス５００から取得し、プリント装置を制御して印刷することを指示するためのＵＩである。スキャンボタンまたはプリントボタンが押下されると、図６に示したシーケンスが開始されることになる。そしてアプリケーションが認証完了通知を受信すると、図１２の手順が実行される。

認証キャンセル画面１３０２は、認証がキャンセルされた旨を示す画面であり、再度認可処理を指示するためのＵＩを有する。この画面１３０２が図６のステップＳ６１０で描画され、表示される。認証エラー画面１３０３は、認証中にエラーが発生した旨を示す画面であり、再度認可処理を指示するためのＵＩを有する。

以上に示す構成により、ユーザーは、組み込みアプリケーション４２０の認可処理中にＷｅｂブラウザー４００での認証操作を中断して組み込みアプリケーションの操作画面に戻ることが可能となる。

［第２の実施形態］
本発明の第１の実施形態では、図１０のフローに示したように、Ｗｅｂブラウザー４００は、認可モードで認可要求されたかどうかを判断して、認可制御サービス４１０へ戻る指示を送信するのか履歴にしたがって戻るのか処理を分岐した。しかしながら、図１４に示すように、認証画面がＩＤ入力画面１４０１とパスワード入力画面１４０３の２画面で構成されており、ＩＤ入力画面１４０１からパスワード入力画面１４０３へと画面遷移する場合、ユーザーがユーザーＩＤを再入力するためにパスワード画面表示中に戻るボタンを押下してもアプリケーション４２０の操作画面へ戻ってしまうという課題がある。

そこで本発明の第２の実施形態として、Ｗｅｂブラウザー４００は、戻るボタンを押下したとき、認可要求ＵＲＩが示す操作画面を表示している場合はアプリケーション画面へ戻るが、それ以外の場合は履歴にしたがって戻るように制御してもよい。

＜戻るボタン押下時のＷｅｂブラウザーによる処理＞
図１５は、本発明の第２の実施形態における戻るボタン押下時のＷｅｂブラウザー４００の処理の流れを表すフローである。本発明の第１の実施形態の図１０との差分は、ステップＳ１００２で、Ｗｅｂブラウザー４００の記憶部４０３が、認可モードが記憶されていると判断した場合、ステップＳ１５０１へ進む点である。ステップＳ１５０１では、Ｗｅｂブラウザーの記憶部４０３が、現在表示しているＷｅｂページのＵＲＩは認可要求ＵＲＩであるかどうか判断し、認可要求ＵＲＩであると判断すればステップＳ１５０２へ進む。それ以外の場合は、ステップＳ１０１３へ進む。認可要求ＵＲＩは図７（ａ）に例示したＵＲＩであり、ステップＳ６０４で送信した認可要求に応じて図６ステップＳ６０６で描画する画面のＵＲＩが認可要求ＵＲＩである。ステップＳ１５０２では、Ｗｅｂブラウザーの記憶部４０３が、履歴情報に含まれるＨＴＴＰリクエストのメソッドは所定の形式、たとえばＰＯＳＴかどうか判断して、ＰＯＳＴである場合はステップＳ１００３へ進む。ＰＯＳＴでない場合は、パスワード入力画面において「戻る」ボタンが押されたと判定し、ステップＳ１１１３へ進む。ステップＳ１０１３では履歴に従って戻る。

図１４に示したように認証画面がＩＤ入力画面１４０１とパスワード入力画面１４０３が分割されている場合、ＩＤ入力画面１４０１からパスワード入力画面１４０３への画面遷移はＧＥＴメソッドが使用され、ＩＤおよびパスワードはパスワード入力画面よりＰＯＳＴメソッドでサブミットされるのが通常の処理の流れである。したがって、パスワード入力画面１４０３が表示されているときには、履歴情報に記録された最後のＨＴＴＰリクエストのメソッドはＧＥＴメソッドであり、ＰＯＳＴメソッドではない。そこでステップＳ１５０２では、Ｗｅｂブラウザー４００は最後のＨＴＴＰリクエストがＰＯＳＴメソッドかどうか判断することによって認証操作が終了したのかどうかを判断している。

このように制御することで、ユーザーＩＤとパスワードとが別々の画面で入力される場合には、いずれか後の入力画面において「戻る」ボタンが押された場合には、Ｗｅｂブラウザー４００の保持する履歴に従って画面を戻す。一方、先の入力画面において「戻る」ボタンが押された場合には、第１の実施形態と同様に認可制御サービス４１０へと戻すことができる。なおステップＳ１５０２の判定の理由は上述した通りなので、ステップＳ１５０２では履歴に記録された最後のリクエストがＧＥＴメソッドか判定し、ＧＥＴであればステップＳ１０１３に、そうでなければステップＳ１００３に分岐してもよい。

＜変形例１＞
図１６は、本発明の第２の実施形態の変形例１における戻るボタン押下時のＷｅｂブラウザー４００の処理の流れを表すフローである。図１５に示したフローとの差分は、ステップＳ１５０２の代わりにステップＳ１６０２を実行する点である。ステップＳ１６０２では、Ｗｅｂブラウザーの記憶部４０３が、履歴情報に含まれるＨＴＴＰレスポンスのステータスコードが３ｘｘかどうか判断して、３ｘｘである場合はステップＳ１００３へ進む。それ以外の場合は、パスワード入力画面において「戻る」ボタンが押されたと判定し、ステップＳ１１１３へ進む。認証画面から認証情報（あるいはユーザー情報とも呼ぶ）をサブミットした場合、認証の成功失敗に関わらず、Ｗｅｂブラウザー４００はステータスコード３ｘｘのレスポンスを受信するのが通常の処理の流れである。したがって、コードステップＳ１６０２では、Ｗｅｂブラウザー４００はＨＴＴＰレスポンスのステータスコードが３ｘｘかどうか判断することによって認証操作が終了したのかどうかを判断している。

なお、第２の実施形態の基本形と変形例１を組み合わせて、Ｗｅｂブラウザー４００は、履歴情報のＨＴＴＰリクエストがＰＯＳＴメソッドかどうか、および、履歴情報のＨＴＴＰレスポンスが３ｘｘかどうかを判断して、処理の流れを決定してもよい。

＜変形例２＞
変形例１を含む上述の実施形態では、Ｗｅｂブラウザー４００が判断して戻るボタン押下時の処理の流れを決定したが、同じ課題を解決する第２の実施形態の変形例として、アプリケーション４２０が「戻る」処理の判断基準を提供し、Ｗｅｂブラウザー４００はその基準に基づいて判断して戻るボタン押下時の処理を決定する構成でもよい。具体的には、アプリケーション４２０が認可モードに付加する情報として、戻るボタン押下時にアプリケーション４２０の操作画面へ戻るべきＷｅｂページのＵＲＩ一覧を指定する構成でもよい。 図１７は、本発明の第２の実施形態の変形例２における戻るボタン押下時のＷｅｂブラウザーの処理の流れを表すフローである。本発明の第１の実施形態との差分は、ステップＳ１００２で、Ｗｅｂブラウザー４００の記憶部４０３が、認可モードが記憶されていると判断した場合、ステップＳ１７０１へ進む点である。ステップＳ１７０１では、Ｗｅｂブラウザーの記憶部４０３が、履歴情報に記録された最後のＵＲＩが、認可モードに付加されるＵＲＩ一覧に含まれるかどうか、すなわち一覧に含まれたいずれかのＵＲＩと一致するか判断し、ＵＲＩ一覧に含まれるのであればステップＳ１００３へ進む。それ以外の場合は、パスワード入力画面において「戻る」ボタンが押されたと判定し、ステップＳ１０１３へ進む。この場合にはパスワード入力画面に限らず、アプリケーション４２０で指定されたのではないＵＲＩが履歴の最後の記録されている場合には、履歴に従って戻ることになる。本変形例では、アプリケーション４２０が、戻るボタン押下時の画面遷移をより細かく制御できるという効果がある。

＜＞［第３の実施形態］
また同じ課題を解決する第３の実施形態として、Ｗｅｂブラウザー４００が認可制御サービス４１０へ戻る指示を送信する際に、履歴情報に含まれる直前のＷｅｂページに関する情報も送信する構成であっても良い。本構成では、Ｗｅｂブラウザー４００は第１の実施形態や第２の実施形態およびその変形例のように振る舞ってもよいし、戻るボタンが押下されたなら無条件で認可制御サービスに戻る指示（戻り指示）を、認可制御サービス４１０に送信してもよい。ただし、本実施形態では、戻り指示とともに、Ｗｅｂブラウザーの記録した履歴のうちの、少なくとも最後の要求および応答またはそのいずれかを送信する。これを受信した認可制御サービス４１０が戻る指示と共に履歴情報に含まれる直前のＷｅｂページに関する情報をアプリケーション４２０へ送信し、アプリケーション４２０は、アプリケーション４２０の操作画面に戻るかどうかを判断して画面遷移指示を認可制御サービス４１０へ通知する。たとえば、図６のＳ６０９で認可キャンセルに代えて認可位制御サービス４１０は戻る指示をアプリケーション４２０に送信する。アプリケーション４２０は、操作画面に戻るか否かを、たとえば履歴情報を参照して第２実施形態のＷｅｂブラウザー４００と同じ要領で判断する。その判断の結果アプリケーションに戻すか否かを示した画面遷移指示を認可位制御サービス４１０に送信する。アプリケーションに戻すと判断した場合には、アプリケーション４２０はたとえば認証キャンセル画面を描画しておく。

図１８は、本発明の第３の実施形態における認可制御サービス４１０がアプリケーション４２０からアプリケーション画面遷移指示を受け付けたときの処理の流れを表すフローである。ステップＳ１８０１では、認可制御サービス４１０の通信部４１１がアプリケーション４２０から画面遷移指示を受け付けると、ステップＳ１８０２へ進む。ステップＳ１８０２では、認可制御サービス４１０の認可制御部４１３は、画面遷移指示がアプリケーション４２０の操作画面へ戻ることを指示しているかどうかを判断し、アプリケーション操作画面へ戻ることを指示する場合ステップＳ１８０３へ進む。それ以外の場合はステップＳ１８１３へ進む。

ステップＳ１８０３では、認可制御サービス４１０の画面制御部４１４はアプリケーション４２０の操作画面をＵＩ表示装置２０７へ表示し、ステップＳ１８０４へ進む。ステップＳ１８０４では、認可制御サービス４１０の通信部４１１は認可処理終了を示すＨＴＴＰレスポンスをＷｅｂブラウザー４００に送信する。

一方ステップＳ１８１３では、認可制御サービス４１０の画面制御部４１４は、Ｗｅｂブラウザー４００の履歴情報の直前のページへ戻ることを指示するＪａｖａＳｃｒｉｐｔ（登録商標）を含むＨＴＴＰレスポンスを生成する。具体的には、ＨＴＴＰレスポンスは"ｈｉｓｔｏｒｙ．ｂａｃｋ（）"命令を含む。そしてＷｅｂブラウザー４００の解析部４０２がＨＴＴＰレスポンスに含まれるＪａｖａＳｃｒｉｐｔを処理した結果、Ｗｅｂブラウザー４００の表示部４０５は記憶部４０３に記憶される履歴情報の直前のページをＷｅｂブラウザー４００の操作画面に描画する。本変形例では、変形例２と同様に、アプリケーション４２０が戻るボタン押下時の画面遷移をより細かく制御できるという効果がある。

［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０１...ＭＦＰ、１０２...Ｗｅｂサーバー、４００...Ｗｅｂブラウザー、４１０...認可制御サービス、４２０...アプリケーション

Claims (8)

1. 指示に応じてリソースを要求し、要求したリソースを取得する取得手段と、
   前記リソースの履歴を記憶する記憶手段と、
   戻り指示を入力するための入力部を含む、取得した前記リソースに基づく画面を表示手段により表示させる表示制御手段と、
   前記戻り指示の入力を受けた場合、戻り先を決定する決定手段と、
   前記リソースの要求の元となるアプリケーションから認可要求を受けた場合、認可モードであることを示す情報を保持する保持手段とを有し、
   前記リソースの要求の元となるアプリケーションから認可要求を受けた場合、前記取得手段は、前記アプリケーションから受けた認可要求に応じて認可要求に関するリソースを要求し、要求した認可要求に関するリソースを取得し、
   前記決定手段は、前記保持された情報に基づいて認可モードである場合は、前記リソースの要求の元となるアプリケーションの画面を戻り先として決定し、認可モードでない場合は、前記履歴に基づいて直前の画面を戻り先として決定し、
   決定した前記戻り先に応じた画面を前記表示手段により表示させることを特徴とする情報処理装置。
2. 前記リソースの要求の元となるアプリケーションから認可要求を受けた場合、前記表示制御手段は、戻り指示を入力するための入力部を含む、取得した前記リソースに基づく認可要求のための認証画面を表示手段により表示させることを特徴とする請求項１に記載の情報処理装置。
3. 前記決定手段が、前記リソースの要求の元となるアプリケーションの画面を戻り先として決定した場合、前記表示手段に表示される戻り先に応じた画面は、前記アプリケーションの画面であって、認証キャンセルを示す画面であることを特徴とする請求項１又は請求項２に記載の情報処理装置。
4. 前記取得手段と前記記憶手段と前記表示制御手段と前記決定手段とはウェブブラウザーに含まれていることを特徴とする請求項１に記載の情報処理装置。
5. 指示に応じてリソースを要求し、要求したリソースを取得する取得手段と、
   前記リソースの履歴を記憶する記憶手段と、
   戻り指示を入力するための入力部を含む、取得した前記リソースに基づく画面を表示手段により表示させる表示制御手段と、
   前記戻り指示の入力を受けた場合、戻り先を決定する決定手段と、
   前記リソースの要求の元となるアプリケーションから認可要求を受けた場合、認可モードであることを示す情報を保持する保持手段としてコンピュータを機能させるためのプログラムであって、
   前記リソースの要求の元となるアプリケーションから認可要求を受けた場合、前記取得手段は、前記アプリケーションから受けた認可要求に応じて認可要求に関するリソースを要求し、要求した認可要求に関するリソースを取得し、
   前記決定手段は、前記保持された情報に基づいて認可モードである場合は、前記リソースの要求の元となるアプリケーションの画面を戻り先として決定し、認可モードでない場合は、前記履歴に基づいて直前の画面を戻り先として決定し、
   決定した前記戻り先に応じた画面を前記表示手段により表示させることを特徴とするプログラム。
6. 前記リソースの要求の元となるアプリケーションから認可要求を受けた場合、前記表示制御手段は、戻り指示を入力するための入力部を含む、取得した前記リソースに基づく認可要求のための認証画面を表示手段により表示させることを特徴とする請求項５に記載のプログラム。
7. 前記決定手段が、前記リソースの要求の元となるアプリケーションの画面を戻り先として決定した場合、前記表示手段に表示される前記戻り先に応じた画面は、前記アプリケーションの画面であって、認証キャンセルを示す画面であることを特徴とする請求項５又は請求項６に記載のプログラム。
8. 情報処理装置により実行される表示制御方法であって、
   指示に応じてリソースを要求し、要求したリソースを取得する取得工程と、
   前記リソースの履歴を記憶する記憶工程と、
   戻り指示を入力するための入力部を含む、取得した前記リソースに基づく画面を表示手段により表示させる表示制御工程と、
   前記戻り指示の入力を受けた場合、戻り先を決定する決定工程と、
   前記リソースの要求の元となるアプリケーションから認可要求を受けた場合、認可モードであることを示す情報を保持手段に保持させる保持工程とを有し
   前記リソースの要求の元となるアプリケーションから認可要求を受けた場合、前記取得工程では、前記アプリケーションから受けた認可要求に応じて認可要求に関するリソースを要求し、要求した認可要求に関するリソースを取得し、
   前記決定工程では、前記保持された情報に基づいて認可モードである場合は、前記リソースの要求の元となるアプリケーションの画面を戻り先として決定し、認可モードでない場合は、前記履歴に基づいて直前の画面を戻り先として決定し、
   決定した前記戻り先に応じた画面を前記表示手段により表示させることを特徴とする表示制御方法。

Images