JP6942509B2 - 情報処理装置及び情報処理装置の制御方法 - Google Patents

Description

本発明は、例えばＷｅｂサーバーに接続され、当該Ｗｅｂサーバーにより提供される操作画面等を表示する情報処理装置及び情報処理装置の制御方法に関する。

近年、スキャナやプリンタを備えたＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）と呼ばれる画像処理装置の中にもＷｅｂブラウザーを備えているものがある。従来のＷｅｂブラウザーには、アドレスバーや戻るボタンといったＷｅｂブラウザー操作のためのＧＵＩ部品を有したツールバーを配置しているものがある。以降、単にツールバーと呼ぶ。Ｗｅｂアプリケーションの画面遷移のひとつとして、ある操作画面から他の操作画面に遷移した後にユーザーが元の操作画面に戻りたい場合は、ツールバーが有する戻るボタンを使って元の操作画面に戻るということがよく行われている。しかし、ＭＦＰなど表示領域が狭いデバイスでは、画面を広く使いたいためにツールバーを非表示にしていることがあり、Ｗｅｂアプリケーションの操作画面上に「戻る」ボタンがない場合は前の操作画面に戻れない。

近年、独自拡張したＨＴＭＬタグ（以降、拡張タグと呼ぶ）を使用して戻る手段を表示／非表示にする技術がある（特許文献１）。Ｗｅｂブラウザーの「戻る」機能などを抑止し、サーバー側でページ画面の切り替え制御を行うという技術であり、その手段としては、Ｗｅｂページのソースに拡張タグが含まれているかどうかを判断して戻る手段の表示／非表示を行うというものである。

特開２００２−４９５２３号公報

しかしながら、特許文献１では、ＨＴＭＬのタグを独自に拡張していることから、この拡張タグをサポートしている特定のＷｅｂアプリケーションでしか戻る手段の表示／非表示をすることが出来ない。そのため、拡張タグをサポートしていない外部サイトに遷移した場合、戻れないという課題を解決できない。

また、Ｗｅｂブラウザーのツールバーが非表示にされた環境下において、ある操作画面から外部サイトに遷移した際に、外部サイトの操作画面から元の操作画面へ戻れないという課題がある。その結果、元の操作画面へ戻れない際にユーザーがＷｅｂブラウザーに表示された操作画面の操作に行き詰ってしまいユーザビリティが低下する。

本発明は上記従来例に鑑みて成されたもので、前の操作画面に戻すための手段を提供していない操作画面においても、前の操作画面へ戻すことを可能とした情報処理装置およびその制御方法を提供することをと目的とする。

上記目的を達成するために本発明は以下の構成を有する。
画面への表示とユーザーによる操作とを行えるユーザインタフェース手段と、
前の画面に戻るための操作部を表示するためのコンテンツの所在を特定する所在情報を保持する保持手段と、
指定された所在からコンテンツを取得する取得手段と、
前記コンテンツを表示する際に、前記コンテンツを取得した所在が前記保持手段に保持された所在情報に含まれる所在であれば、前の画面に戻るための操作部を併せて前記ユーザインタフェース手段に表示する制御手段と
を有することを特徴とする情報処理装置が提供される。

本発明により、前の操作画面に戻すための手段を提供していない操作画面においても、前の操作画面へ戻すことを可能とすることができる。それによりユーザビリティを向上させる。

本発明の実施形態におけるＭＦＰの接続されるシステムの全体図である。 本発明の実施形態におけるＭＦＰ、Ｗｅｂサーバーのハードウェア構成を示すブロック図である。 本発明の実施形態におけるＭＦＰのソフトウェア構成を示す図である。 本発明の実施形態におけるツールバー表示を要するＵＲＬを記憶するシーケンス図である。 本発明の実施形態におけるツールバー表示を要するＵＲＬを記憶するフローである。 本発明の実施形態におけるテーブルである。 本発明の実施形態におけるツールバー表示を要するＵＲＬの場合にツールバーを表示するシーケンスを示した図である。 本発明の実施形態におけるツールバー表示を要するＵＲＬの場合にツールバーを表示するフローである。 本発明の実施形態におけるＵＩ表示装置２０５に表示した結果の例である。 本発明の実施形態における戻るボタンの表示を要するＵＲＬ情報と戻るボタン表示のための座標位置を記憶するシーケンスを示した図である。 本発明の実施形態における戻るボタン表示を要するＵＲＬの場合に戻るボタンを指定された座標位置に表示するシーケンスを示した図である。 本発明の実施形態における戻る手段を表示するかどうかを判定する処理のフローである。

以下、本発明を実施するための形態について図面を用いて説明する。
［実施形態１］（ツールバー表示）
図１は、本発明の画像処理装置を用いたシステムの構成例である。本システムはネットワーク１００を介して接続される画像処理装置であるＭＦＰ１０１と、Ｗｅｂサーバー（ウェブサーバー）１０２とを含む。ネットワーク１００は各装置間で通信を行うための基盤であって、インターネットに接続されていても良い。ＭＦＰ１０１はＷｅｂブラウザー（ウェブブラウザー）を搭載するＭＦＰ（Ｍｕｌｔｉｐｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ：多機能周辺機器）である。ＭＦＰは印刷や画像の複製、スキャナにより画像の取り込みなどの特定用途の機能を有するとともに、Ｗｅｂブラウザーを搭載するなど、汎用の情報処理装置としての機能も有している。なお、Ｗｅｂブラウザー機能を有すれば、本実施形態はＭＦＰに限定されるものではなく、他の種装置に適用することもできる。Ｗｅｂサーバー１０２は、ネットワーク経由でＭＦＰ１０１と接続されており、Ｗｅｂコンテンツを、ネットワークを介して配信する機能を持つ。Ｗｅｂサーバー１０２は、ＭＦＰ１０１からのリクエストに応じてＷｅｂコンテンツを提供する。各装置はローカルネットワーク上に存在しても良いし、インターネットを越えて接続されていても良い。また、Ｗｅｂサーバー１０２はＭＦＰ１０１の機能としてＭＦＰ１０１の中に存在してもよい。外部サイト１０３は、ＭＦＰ１０１とＷｅｂサーバー１０２の外部に存在する他のＷｅｂサーバーである。

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

＜ＭＦＰのソフトウェア構成＞
図３は本実施形態におけるＭＦＰ１０１のソフトウェア構成を説明するための図である。図３に示す各機能部は、ＭＦＰ１０１が有しているＣＰＵ２０１が制御プログラムを実行することにより実現される。

ＭＦＰ１０１は、Ｗｅｂブラウザー３００を有する。Ｗｅｂブラウザー３００は、任意のサーバーと通信を行うことによってＷｅｂコンテンツを取得、画面に表示するといった機能を有するものであればよい。Ｗｅｂブラウザー３００は、通信部３０１、解析部３０２、処理部３０３、記憶部３０４、履歴管理部３０５を有する。ＭＦＰ１０１上のＷｅｂブラウザー３００は、ツールバーを非表示にすることを通常の使用形態とする。

通信部３０１は、ＨＴＴＰプロトコルに従って、Ｗｅｂサーバー１０２と通信する。より具体的には、通信部３０１は、Ｗｅｂブラウザー３００が起動された際に、Ｗｅｂサーバー１０２に対してリクエストを送信し、Ｗｅｂコンテンツをレスポンスとして受信する。

解析部３０２は、Ｗｅｂサーバー１０２から受信したレスポンスを解析する。レスポンスの中にはＷｅｂブラウザー３００に表示すべき操作画面の内容を示す記述であるＨＴＭＬデータや、操作画面に適用するＪａｖａＳｃｒｉｐｔ（登録商標）が記載されている。以降、それらを合わせてＷｅｂコンテンツと呼ぶ。

処理部３０３は、解析部３０２による解析結果に基づいて、ＷｅｂコンテンツをＵＩ表示装置２０５に表示したり、ＪａｖａＳｃｒｉｐｔ（登録商標）が含まれる場合は、ＪａｖａＳｃｒｉｐｔ（登録商標）を実行したりする。

記憶部３０４は、Ｗｅｂブラウザー３００が使用するデータを記憶する。記憶するデータとして、戻るボタンの表示を要するＵＲＬ情報と戻るボタン表示のための座標位置及びＵＲＬ情報の記憶を指示した記憶元のＷｅｂアプリケーションのＵＲＬが含まれる。ＵＲＬはユニバーサルリソースロケータと呼ばれ、Ｗｅｂコンテンツ等のリソースの所在を示す情報である。

履歴管理部３０５は、Ｗｅｂブラウザー３００上で閲覧されたＵＲＬの履歴情報を管理する。履歴情報には、アクセスしたＵＲＬ，ＨＴＭＬのｔｉｔｌｅ要素の内容（以降、タイトル名と呼ぶ）、及びファビコンデータが含まれる。ファビコンとは、たとえばウェブサイトなどのシンボルとなるアイコンを指す。

＜ＵＲＬの記憶シーケンス＞
図４は、Ｗｅｂブラウザー３００がＷｅｂサーバー１０２からＷｅｂコンテンツを取得した際に、ツールバー表示を要するＵＲＬを記憶するシーケンスを示した図である。ステップＳ４０１では、Ｗｅｂブラウザー３００は、ユーザーの指示に従ってＷｅｂアプリケーションの開始指示を受け付ける。

ステップＳ４０２では、Ｗｅｂブラウザー３００は、通信部３０１を介してＷｅｂサーバー１０２に対してＨＴＴＰリクエストを送信する。

ステップＳ４０３では、Ｗｅｂブラウザー３００は、Ｗｅｂサーバー１０２からＨＴＴＰレスポンスとしてＷｅｂコンテンツを受信する。受信したＷｅｂコンテンツには、ツールバーを表示中であるかどうかを判定するためのスクリプトデータとツールバー表示を要するＵＲＬ情報とが含まれている。ＵＲＬ情報は、外部サイト１０３において戻る手段がなくツールバーを表示する必要のあるＵＲＬであり、外部サイト１０３にアクセスする際にツールバー表示の必要性を判断する際に使われる。Ｗｅｂブラウザー３００がＷｅｂサーバー１０２から受信したＷｅｂコンテンツの内容に、ｌｉｎｋ要素など、別途参照すべきリソース（画像やＨＴＭＬコンテンツ等）の場所を含む要素が含まれている場合がある。その場合は、その要素によって場所で示された参照すべきリソース（以降、サブリソースと呼ぶ）を未受信の場合がある。そのため、その際には、ステップＳ４０３に引き続き、未受信のサブリソースを取得するためのＨＴＴＰリクエスト／レスポンスをＷｅｂサーバー１０２に送受信するステップが必要となる場合がある。

ステップＳ４０４では、Ｗｅｂブラウザー３００は、受信したＷｅｂコンテンツを解析部３０２において解析し、結果をＵＩ表示装置２０５に表示する。表示した結果の例を図９（ａ）に示す。図９（ａ）では、ウェブアプリケーションにアクセスする前に受けるべき認証を行う認証サービスのサイトの選択肢がボタン９１１などとして示されている。

ステップＳ４０５では、Ｗｅｂブラウザー３００は、ステップＳ４０３で受信したＷｅｂコンテンツに含まれるツールバーを表示中であるかどうかを判定するためのスクリプトデータを処理部３０３で実行する。ツールバーが表示中であるかどうかどうかを判定する方法は、Ｗｅｂブラウザー３００の操作画面の広さを確認する方法を使ってもよいし、Ｗｅｂブラウザー３００が提供するＡＰＩを経由して確認する方法でもよい。操作画面の広さを確認する方法では、たとえば、Ｗｅｂブラウザーから操作画面の縦横サイズを取得し、全画面表示の場合はツールバーが表示されていないと判定し、全画面表示でない場合は、ツールバーが表示されていると判定することもできる。ＡＰＩを経由して確認する方法では、たとえば、ツールバーが表示中であるかどうかを判定することができるＡＰＩを使用して、Ｗｅｂブラウザー３００がツールバー表示中であるかどうかを判定する。

ステップＳ４０６では、Ｗｅｂブラウザー３００は、ステップＳ４０３で受信したＷｅｂコンテンツに含まれるツールバー表示を要するＵＲＬ情報を記憶するためのスクリプトデータを実行し、ツールバー表示を要するＵＲＬ情報を記憶部３０４に記憶する。このスクリプトデータはステップＳ４０３で受信したＷｅｂコンテンツに含まれていてもよいし、Ｗｅｂブラウザー３００が受信したＷｅｂコンテンツを書き換えて挿入してもよい。記憶部３０４に記憶したＵＲＬ情報は、操作画面が戻る手段を要しないＵＲＬに切り替わったタイミングで削除してもよいし、認証サービスからのログアウトしたタイミングで削除してもよいし、Ｗｅｂアプリケーションが切り替わったタイミングで削除してもよい。

＜Ｗｅｂブラウザーによる、ツールバー表示を要するＵＲＬの記憶フロー＞
図５は、Ｗｅｂブラウザー３００がＷｅｂサーバー１０２からＷｅｂコンテンツを取得した際に、ツールバー表示を要するＵＲＬを記憶するフローである。ステップＳ４０１〜ステップＳ４０５については、図４に示したとおりである。ステップＳ５０６では、Ｗｅｂブラウザー３００の処理部３０３は、前記ステップＳ４０５において処理部３０３でツールバー表示の有無の判定を実行した結果から、ツールバーが表示中であるかどうかを判定する。Ｗｅｂブラウザー３００においてツールバーが表示中であるならばツールバー表示を要するＵＲＬの登録は不要である。そのため、ステップＳ５０６においてツールバーが表示中かどうかを判定する。ツールバーが表示されていない場合は、ステップＳ４０６に遷移する。ここで、ステップＳ４０３で受信した、ツールバー表示を要するＵＲＬを記憶する。ツールバーが表示されている場合は、ステップＳ５０８に遷移する。ステップＳ４０６の処理の後は、ステップＳ７０１またはステップＳ８０１へ遷移する。これらの処理については図７、図８を参照して後で説明する。

ステップＳ５０８では、Ｗｅｂブラウザー３００は、外部サイト１０３へのアクセス要求を受信する。ここでは、Ｗｅｂサーバー１０２から受信した表示画面上から、外部サーバー１０３へのリンクボタンが押下されたものとする。例えば図９（ａ）では他の認証サーバーをユーザーに選択させ、選択された認証サーバーにアクセスする。この例では、いずれかの認証サーバーに対応するボタンが押下されると、Ｗｅｂブラウザー３００はステップＳ５０８でそれをアクセス要求として受信する。

ステップＳ５０９では、Ｗｅｂブラウザー３００は、通信部３０１を介して外部サイト１０３に対してＨＴＴＰリクエストを送信する。

ステップＳ５１０では、Ｗｅｂブラウザー３００は、外部サイト１０３からＨＴＴＰレスポンスとしてＷｅｂコンテンツを受信する。受信したＷｅｂコンテンツの内容にｌｉｎｋ要素など別途参照すべきリソース（画像やＨＴＭＬコンテンツ等）の場所を含む要素が含まれている場合は、その要素で示された場所のリソース（以降、サブリソースと呼ぶ）が未受信の場合がある。そのため、その際には、ステップＳ５１０に引き続き、未受信のサブリソースを取得するためのＨＴＴＰリクエスト／レスポンスを外部サイト１０３に送受信するステップが必要となる場合がある。

ステップＳ５１１では、Ｗｅｂブラウザー３００は、受信したＷｅｂコンテンツを解析部３０２において解析し、結果をＵＩ表示装置２０５に表示する。表示した結果の例を図９（ｂ）に示す。

ステップＳ５１２では、Ｗｅｂブラウザー３００は、ユーザー１１０からツールバー上の戻るボタンの操作を受け付ける。その結果として、戻るボタンが押されたそのＷｅｂコンテンツの直前に表示されていたＷｅｂコンテンツが表示される。

上記のステップＳ５０８〜Ｓ５１２は、Ｗｅｂブラウザー３００に予めツールバーが表示されていた場合のフローである。

＜ツールバーが表示されないＷｅｂコンテンツのための処理手順＞
図６（ａ）は、Ｗｅｂブラウザー３００の記憶部３０４に記憶されているツールバーの表示を要するＵＲＬのテーブル（以降、ＵＲＬテーブルと呼ぶ）６００を示す図である。図６の例では、ＵＲＬテーブル６００には、ツールバーの表示を要するＵＲＬが項目１〜項目３に保存されている。これらＵＲＬは、図５のステップＳ４０６で記憶されたＵＲＬ情報であり、ツールバーが表示されないＷｅｂコンテンツのＵＲＬである。

図７は、ツールバー表示を要するＵＲＬの場合にツールバーを表示するシーケンスを示した図である。Ｗｅｂブラウザー３００が外部サイト１０３からＷｅｂコンテンツを取得した際に、ステップＳ４０５でＷｅｂブラウザー３００がツールバーの表示中でないと判定された場合、ツールバーの表示判定をする。前記ツールバーの表示判定において、ツールバー表示を要するＵＲＬの場合にそのＵＲＬが記憶される。そして図７の手順では、記憶したＵＲＬのＷｅｂコンテンツを表示する際にツールバーあるいはその代替となるオブジェクトも合わせても表示する。

ステップＳ７０１では、Ｗｅｂブラウザー３００は、ユーザーの指示による外部サイトへのアクセス要求を受信する。

ステップＳ７０２では、Ｗｅｂブラウザー３００は、通信部３０１を介して外部サイト１０３に対してＨＴＴＰリクエストを送信する。

ステップＳ７０３では、Ｗｅｂブラウザー３００は、外部サイト１０３からＨＴＴＰレスポンスとしてＷｅｂコンテンツを受信する。

ステップＳ７０４では、Ｗｅｂブラウザー３００は、記憶部３０４に記憶されているＵＲＬテーブル６００からＵＲＬの１つ目を読み出す。読み出したＵＲＬとステップＳ７０２でＨＴＴＰリクエストを送信した際のアクセス先のＵＲＬと比較を行う。換言すれば、ステップＳ７０２でＨＴＴＰリクエストを送信した際のアクセス先のＵＲＬを所定のＵＲＬと比較する。一致しない場合は、ＵＲＬテーブル６００に記憶されているＵＲＬの数を超えない条件で、ＵＲＬテーブル６００から次のＵＲＬを１つ読み出して、ステップＳ７０２でＨＴＴＰリクエストを送信したＵＲＬとの比較を繰り返す。

ステップＳ７０５では、ステップＳ７０４でＵＲＬテーブル６００の中にあるＵＲＬとＳ７０２でＨＴＴＰリクエストを送信した際のＵＲＬとが一致した場合に、Ｗｅｂブラウザー３００はＵＩ表示装置２０５に「戻る」ボタンすなわち「戻る」操作部を含むツールバーを表示する。ＵＲＬテーブル６００の中のＵＲＬ全てと比較して一致しなかった場合は、Ｗｅｂブラウザー３００はツールバーを表示しない。

ステップＳ７０６では、Ｗｅｂブラウザー３００は、受信したＷｅｂコンテンツを解析部３０２において解析し、結果をＵＩ表示装置２０５に表示する。表示した結果の例を図９（ｂ）に示す。この例ではツールバー９２１が表示されている。

ステップＳ７０７では、Ｗｅｂブラウザー３００は、ユーザーから戻るボタンの操作待ちを行う。

ステップＳ７０８では、Ｗｅｂブラウザー３００は、ユーザーからツールバーの戻るボタン操作を受け付ける。ここで戻るボタンの操作を行う主体はユーザーでなくてもよく、ユーザーの操作を模擬するスクリプトで操作されてもよい。

ステップＳ７０９では、Ｗｅｂブラウザー３００は、Ｗｅｂブラウザーに表示されているツールバーを非表示にする。

＜ツールバー表示フロー＞
図８は、ツールバー表示を要するＵＲＬの場合にツールバー（あるいはその代替オブジェクト等）を表示するフローを示した図である。Ｗｅｂブラウザー３００が外部サイト１０３からＷｅｂコンテンツを取得した際に、ステップＳ５０６でＷｅｂブラウザー３００がツールバーの表示中でないと判定された場合、図８の中でツールバーの表示判定をする。前記ツールバーの表示判定において、ツールバー表示を要するＵＲＬの場合にツールバーを表示する。ステップＳ８０１〜Ｓ８０６は、前記ステップＳ７０１〜７０６とそれぞれ同じである。すなわちステップＳ８０５はステップＳ７０５と同じである。ステップＳ８０７はステップＳ７０７とＳ７０８とを含む。ステップＳ８０８にはステップＳ７０９が対応する。

ステップＳ８１０では、ステップＳ８０４でツールバーを表示しないと判定された場合に、Ｗｅｂブラウザー３００は、ツールバーを表示することなく操作画面を表示する。

ステップＳ８０１〜Ｓ８０８とステップＳ５０８〜Ｓ５１２との違いは、ツールバーを表示／非表示する処理を含むか含まないかである。ステップＳ５０６でツールバーが表示中であると判断された場合は、ツールバーを表示／非表示する必要がないため、ステップＳ５０８〜Ｓ５１２においてツールバーを表示／非表示する処理は含まれていない。

図９（ａ）は、ステップＳ４０４においてＵＩ表示装置２０５に表示した結果の例である。操作画面中には外部サイトへのリンクが４つ含まれている。

図９（ｂ）は、ステップＳ７０６及びステップＳ８０６においてＵＩ表示装置２０５に外部サイトのＷｅｂコンテンツが表示された結果の例である。ＵＲＬテーブル６００に含まれているＵＲＬへアクセスしているため、Ｗｅｂブラウザー内下部に戻るボタン９２２を含むツールバー９２１が表示されている。

以上に示す構成により、ＭＦＰ１０１上のＷｅｂブラウザー３００は、Ｗｅｂブラウザー３００のツールバーが非表示にされた環境下において、外部サイトの操作画面から元の操作画面へ戻れるようにするために「戻る」ボタンを含むツールバーを表示する。Ｗｅｂブラウザー３００は、ＵＲＬの遷移を履歴として管理しており、「戻る」ボタンの押下により、ひとつ前の画面に戻ることが可能となる。また、ツールバーが表示されない環境において、「戻る」ボタンを含むツールバーを、指定したＵＲＬにアクセスして得たＷｅｂコンテンツを対象として追加的に表示している。このようにすることで、「戻る」操作を許すＷｅｂコンテンツと、「戻る」操作を許さないＷｅｂコンテンツとを、Ｗｅｂサーバーがコントロールすることもできる。なお「戻る」ボタンにより戻る「前の画面」とは、たとえばＵＲＬの変更に応じて切り替えられるコンテンツに応じた画面を指す。たとえば第一のＵＲＬを指定して取得したコンテンツを表示し、次にそのコンテンツに含まれるリンクにより、あるいは新たな指定により第二のＵＲＬが指定されるとそのＵＲＬに対応するコンテンツが表示される。この状態において、第一のＵＲＬから取得したコンテンツが「前の画面」に相当する。このように、アクセス先のＵＲＬの時系列を考えた場合に、その時系列を現在の表示状態から１段階遡る操作が「戻る」操作に相当する。

以上により、外部サイトの操作画面から元の操作画面へ戻れずにユーザーが操作に行き詰るということが防止できるためユーザビリティを向上させることが可能になる。

［実施形態２］（戻るボタン表示）
次に、本発明の第2の実施形態を説明する。

実施形態１では、ユーザーに対し戻る手段としてツールバーを提供していたが、戻る手段としてはツールバーでなくても良く、単に戻るボタンを提供するだけでも戻る操作を実現することが出来る。さらに、実施形態１のようにツールバーによって戻る手段を提供すると画面が狭くなることで、画面のレイアウトが崩れたり、スクロールしないと操作できない領域が出てきたりしてユーザビリティが低下する。そのため、実施形態２では、戻るボタンのみを操作画面に重ね合わせるようにオーバーレイ（フローティング）表示する。以下、実施形態１で説明している部分に関しては省略する。

図１０は、Ｗｅｂブラウザー３００がＷｅｂサーバー１０２からＷｅｂコンテンツを取得した際に、戻るボタンの表示を要するＵＲＬ情報と戻るボタン表示のための座標位置を記憶するシーケンスを示した図である。ステップＳ１００１〜Ｓ１００２は、図４のステップＳ４０１〜Ｓ４０２と同じである。

ステップＳ１００３では、Ｗｅｂブラウザー３００は、Ｗｅｂサーバー１０２からＨＴＴＰレスポンスとしてＷｅｂコンテンツを受信する。受信したＷｅｂコンテンツには、ツールバーを表示中であるかどうかを確認するためのスクリプトデータと、戻るボタンの表示を要するＵＲＬ情報と、戻るボタン表示のための座標位置とが含まれている。ＵＲＬ情報は、外部サイト１０３の操作画面において戻る手段がなく戻るボタンを表示する必要のあるＵＲＬであり、外部サイト１０３にアクセスする際に戻るボタン表示の必要性を判断する際に使われる。戻るボタン表示のための座標位置は、Ｗｅｂブラウザー３００の操作画面上で戻るボタンを表示する際に使われる。図６（ｂ）は、Ｗｅｂブラウザー３００の記憶部３０４に記憶されている戻るボタンの表示を要するＵＲＬ情報と戻るボタン表示のための座標位置がセットになって保存されたテーブル（以降、位置付きＵＲＬテーブル６１０と呼ぶ）を示す図である。位置付きＵＲＬテーブル６１０には、戻るボタンの表示を要するＵＲＬ情報と戻るボタン表示のための座標位置がセットになり項目１〜３に保存されている。

ステップＳ１００４〜ステップＳ１００５は、図４のステップＳ４０４〜Ｓ４０５と同じである。

ステップＳ１００６では、Ｗｅｂブラウザー３００は、前記ステップＳ１００３で受信したＷｅｂコンテンツに含まれる戻るボタン表示を要するＵＲＬ情報と座標位置とを記憶するためのスクリプトデータを処理部３０３で実行する。このスクリプトデータはステップＳ１００３で受信したＷｅｂコンテンツに含まれていてもよいし、Ｗｅｂブラウザー３００が、受信したＷｅｂコンテンツを書き換えて挿入してもよい。そして得られた、戻るボタン表示を要するＵＲＬ情報と座標位置をＷｅｂブラウザー３００の記憶部３０４に記憶する。

つぎに、Ｗｅｂブラウザー３００の操作画面上で外部サイト１０３へのリンクボタンが押下された際の説明を行う。

図１１は、Ｗｅｂブラウザー３００が外部サイト１０３からＷｅｂコンテンツを取得した際に、戻るボタンの表示判定をし、戻るボタン表示を要するＵＲＬの場合に戻るボタンを指定された座標位置に表示するシーケンスを示した図である。ステップＳ１１０１〜Ｓ１１０３及びＳ１１０６は、図７のステップＳ７０１〜Ｓ７０３及びＳ７０６と同じである。

ステップＳ１１０４では、Ｓ１１０２でＨＴＴＰリクエストを送信した際のＵＲＬと一致するＵＲＬが位置付きＵＲＬテーブル６１０に登録されているか判定する。これはステップＳ７０４において、ＵＲＬテーブル６００の代わりに位置付きＵＲＬテーブル６１０を使用した場合と同様である。

ステップＳ１１０５では、ステップＳ１１０４で位置付きＵＲＬテーブル６１０の中にあるＵＲＬとＳ１１０２でＨＴＴＰリクエストを送信した際のＵＲＬとが一致した場合に、位置付きＵＲＬテーブル６１０から、一致したＵＲＬに対応する座標位置を読み出す。Ｗｅｂブラウザー３００はＵＩ表示装置２０５に戻るボタンを、読み出した座標位置に表示する。Ｓ１１０２でＨＴＴＰリクエストを送信した際のＵＲＬとＵＲＬテーブル６１０の中のＵＲＬ全てとを比較して一つも一致しなかった場合は、Ｗｅｂブラウザー３００は戻るボタンを表示しない。ここで、位置付きＵＲＬテーブル６１０の中に座標位置の情報が無ければ実施形態１に示すようにツールバーを表示してもよい。また適当な位置をデフォルト位置として決めておき、その位置に表示してもよい。

以上説明したように、ツールバーを表示する代わりに「戻る」ボタンを表示することで、狭い画面でも表示スペースを有効に活用することが可能となり、ユーザーの利便性を向上することができる。

［実施形態３］（ファビコン表示）
次に、本発明の第３の実施形態を説明する。実施形態２では、戻るボタンだけでは戻る先が分かりにくいという課題がある。そのため、実施形態３では、戻るボタンにファビコンやアプリ名の情報を付加して戻る先を目立たせて識別し易く表示する。なお、ファビコンとは、ウェブブラウザのアドレスバーなどに表示されるアイコンのことで、ウェブサイトのシンボルマークやイメージとして使用される。以下、実施形態１及び実施形態２で説明している部分に関しては省略する。

Ｗｅｂブラウザー３００がファビコン情報を取得する手段を実施形態２で示した図１０及び図１１を使って説明する。

ステップＳ１００３では、Ｗｅｂブラウザー３００は、Ｗｅｂサーバー１０２からＨＴＴＰレスポンスとしてＷｅｂコンテンツを受信する。ここでは、受信したＷｅｂコンテンツには、ツールバーを表示中であるかどうかを確認するためのスクリプトデータと、戻るボタンの表示を要するＵＲＬ情報と、戻るボタン表示のための座標位置とに加えて、サブリソースとしてファビコンデータを受信する。受信したファビコンデータは、Ｗｅｂブラウザー３００の履歴管理部３０５でアクセスしたＵＲＬと紐づけされて記憶され、管理される。

ステップＳ１１０５では、履歴管理部３０５から戻る先のＵＲＬのファビコンデータ読み出し、Ｗｅｂブラウザーの処理部３０３においてファビコンデータと戻るボタンを合成したＵＩ部品を生成する。Ｗｅｂブラウザー３００は、前記生成されたＵＩ部品をＵＩ表示装置２０５に表示する。

次にＷｅｂブラウザー３００がアプリケーション名を取得する手段を実施形態２で示した図１０及び図１１を使って説明する。以下では、実施形態２との差分のみ説明する。

ステップＳ１００３では、Ｗｅｂブラウザー３００は、Ｗｅｂサーバー１０２からＨＴＴＰレスポンスとしてＷｅｂコンテンツを受信する。ここではＷｅｂコンテンツの一部として、ツールバーを表示中であるかどうかを確認するためのスクリプトデータと、戻るボタンの表示を要するＵＲＬ情報と、戻るボタン表示のための座標位置とに加えて、ｔｉｔｌｅ要素の内容（タイトル名）を受信する。受信したタイトル名は、Ｗｅｂブラウザー３００の履歴管理部３０５でアクセスしたＵＲＬと紐づけされて記憶され、管理される。

ステップＳ１１０５では、履歴管理部３０５から戻る先のＵＲＬのｔｉｔｌｅ要素の内容（タイトル名）を読み出し、Ｗｅｂブラウザーの処理部３０３において戻るボタンをタイトル名と合成したＵＩ部品を生成する。Ｗｅｂブラウザー３００は、前記生成されたＵＩ部品をＵＩ表示装置２０５に表示する。ファビコンとアプリケーション名を使用した戻るボタンの例を図９（ｃ）に示す。図９（ｃ）には、ファビコンとアプリケーション名の両方を表示しているが、このためには、Ｗｅｂサーバーが応答するコンテンツに、ファビコンデータとタイトル名とを含めておけばよい。

以上説明したように、「戻る」ボタンを付与する際に、ファビコンやアプリケーション名といった、コンテンツと関連したオブジェクトを付加して戻り先を判り易く表示することで、ユーザビリティを向上することができる。

なお上記実施形態において、ファビコン及びアプリケーション名は、ＭＦＰ１０１が保持しているデータを使用することもできる。

［実施形態４］（派生先もＯＫ）
次に、本発明の第４の実施形態を説明する。実施形態１〜３では、Ｗｅｂサーバー１０２上のＷｅｂアプリケーションが、戻る手段表示を要する外部サイトを把握していることが前提となっている。しかし、ユーザーが外部サイトの画面を操作中にＷｅｂサーバー１０２上のＷｅｂアプリケーションが把握していない別の外部サイトに行ってしまう場合がある。ＭＦＰ１０１上のＷｅｂブラウザー３００は、表示領域が小さく画面を広く使いたいためにツールバーを非表示にすることを通常の使用形態にしていることがよくある。そのため、アドレスバーが表示されていないことから、直接、Ｗｅｂアプリケーションが知らない更に外部サイトに行くことはない。しかし、Ｗｅｂアプリケーションが知っている外部サイトのページの中のリンクをクリックすることで、Ｗｅｂアプリケーションが知らない更に外部サイトに行ってしまうことがある。実施形態４では、ＵＲＬテーブル６００又は位置付きＵＲＬテーブル６１０に保存されたＵＲＬのページから派生してリンクした先のＵＲＬも、戻る手段の表示対象にする。

本実施形態では、図４のステップＳ４０６、図１０のＳ１００６において、ＵＲＬテーブル６００又はＵＲＬテーブル６１０に加えて、登録元のＷｅｂアプリケーションのＵＲＬを、戻る手段表示を要するＵＲＬと共に保存する。図６（ｃ）は、ＵＲＬ６１０に登録元ＷｅｂアプリケーションのＵＲＬを付加したテーブル（以降、登録元つきＵＲＬテーブル６２０と呼ぶ）である。なお、登録元つきＵＲＬテーブル６２０には、表示位置は必ずしも含まなくともよい。

図１２は、図７のステップＳ７０４、図８のＳ８０４及び図１１のステップＳ１１０４における戻る手段を表示するかどうかを判定する処理のフローである。

ステップＳ１２０１では、Ｗｅｂブラウザー３００の記憶部３０４から登録元つきＵＲＬテーブル６２０を読み出し、ステップＳ７０２、Ｓ８０２及びＳ１１０２のＨＴＴＰリクエストでアクセスしたＵＲＬと一致するＵＲＬが、戻る手段表示を要するＵＲＬとして含まれているか判定する。ステップＳ１２０１で、アクセス先のＵＲＬが、戻る手段表示を要するＵＲＬとして登録元つきＵＲＬテーブル６２０に含まれていないと判定された場合は、ステップＳ１２０２に分岐する。一方、ステップＳ１２０１で、アクセス先のＵＲＬが、戻る手段表示を要するＵＲＬとして登録元つきＵＲＬテーブル６２０に含まれていると判定された場合は、ステップＳ１２０９に分岐する。

ステップＳ１２０２では、Ｗｅｂブラウザー３００の履歴管理部３０５から、履歴データが保存されたスタックから、履歴データが格納された順とは逆の順序でデータを取り出して参照するループを開始する。履歴データは逐次的に保存されるためにスタックを形成しており、格納された順序と逆の順序でレコードを取り出すことで、最新の履歴から時系列に遡ることができる。なお履歴スタックには、たとえばアクセスしたＵＲＬがレコードとして保存されている。なおここではデータを取り出すと表現するが、履歴スタックはそのままとして内容を参照すれば十分である。また時系列を遡ることができれば、履歴データの構造はスタックでなくともよい。

ステップＳ１２０３では、履歴スタックからレコードを１つ取り出し、ＵＲＬテーブルの登録元のＷｅｂアプリケーションのＵＲＬと一致するか判定する。

ステップＳ１２０４では、Ｓ１２０３で一致しなければ、ステップＳ４０２、Ｓ７０２，Ｓ１１０２のＨＴＴＰリクエストでアクセスしたＵＲＬが、登録元つきＵＲＬテーブル６２０の戻る手段表示を要するＵＲＬに含まれているか判定する。含まれていると判定すればステップＳ１２０５に、そうでなければステップＳ１２０７に分岐する。

ステップＳ１２０５は、ステップＳ７０５、Ｓ８０５及びＳ１１０５と同じである。すなわち、「戻る」ボタンなどの戻る手段を現在のコンテンツ表示画面に重ねて表示する。

ステップＳ１２０６では、Ｓ１２０５で戻る手段を表示した後、履歴スタックの参照ループから抜ける。

ステップＳ１２０７では、Ｓ１２０４において前記ＨＴＴＰリクエストでアクセスしたＵＲＬがＵＲＬテーブルの戻る手段表示を要するＵＲＬに含まれていない場合に、履歴スタックの参照要素の位置を１つ戻す。

ステップＳ１２０３でＵＲＬテーブルの登録元のＷｅｂアプリケーションのＵＲＬと履歴スタックから参照したＵＲＬとが一致すると判定した場合には、ステップＳ１２０８で戻る手段を非表示にする。これは、戻る手段を必要とするＵＲＬの登録元のＷｅｂアプリケーションに戻ることになり、Ｗｅｂブラウザー３００が戻る手段を提供する必要がなくなるためである。

ステップＳ１２０９では、「戻る」ボタンを含むツールバー等を表示する。ステップＳ７０５、Ｓ８０５及びＳ１１０５と同じである。

以上のように、履歴スタックを遡ることでツールバーの表示／非表示を決定することができるのは、以下の理由による。組み込みデバイスのブラウザー向けＷｅｂアプリケーションでは、画面を大きく使いたいためツールバーを表示しないことが一般的であり、ツールバーに含まれているアドレスバーも表示されない。そのため、アドレスバーに直接ＵＲＬを入力して画面遷移を生じさせることができない。画面遷移は表示されたコンテンツ中のリンクをたどって可能となる。すなわち、履歴スタックを遡って、戻る手段表示を有するＵＲＬを登録したＷｅｂアプリケーションのＵＲＬが、戻る手段表示を有するＵＲＬの前に現れれば、戻る手段表示をする必要はないと判断できる。逆に、戻る手段表示を有するＵＲＬが、それを登録したＷｅｂアプリケーションのＵＲＬより前に現れれば、戻る手段の表示を要すると判断できる。

なお図１２の手順では、戻る手段の表示を要するＵＲＬを登録した（すなわちコンテンツの一部としてＷｅｂブラウザー３００に引き渡した）登録元ＷｅｂアプリケーションのＵＲＬが必ず履歴スタックに残っていることを前提としている。そのため、スタックを最後まで参照してステップＳ１２０３でもステップＳ１２０４でも該当するレコードがない場合を想定していない。しかし、該当するレコードが履歴から発見できなかった場合には、例えば戻る手段を非表示にするものと判断してもよい。

以上説明したように、もともと想定している外部サイト以外のサイトに遷移した場合でも、適切に戻ることが可能となり、ユーザビリティを向上させることができる。

なお、本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

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

１０１ ＭＦＰ、１０２ Ｗｅｂサーバー、１０３ 外部サイト、３００ Ｗｅｂブラウザー

Claims (10)

1. 画面への表示とユーザーによる操作とを行えるユーザインタフェース手段と、
   前の画面に戻るための操作部を表示するためのコンテンツの所在を特定する所在情報を保持する保持手段と、
   指定された所在からコンテンツを取得する取得手段と、
   前記コンテンツを表示する際に、前記コンテンツを取得した所在が前記保持手段に保持された所在情報に含まれる所在であれば、前の画面に戻るための操作部を併せて前記ユーザインタフェース手段に表示する制御手段と
   を有することを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記制御手段は、前記保持手段に保持された所在情報に含まれる所在のコンテンツを表示しなくなると、前記操作部を表示しないことを特徴とする情報処理装置。
3. 請求項１または２に記載の情報処理装置であって、
   前記ユーザインタフェース手段に、前の画面に戻るための操作部が表示されているかを判定する判定手段をさらに有し、
   前記制御手段は、前記コンテンツを表示する際に、前記判定手段で前の画面に戻るための操作部が表示されていないと判定され、かつ、前記コンテンツを取得した所在が前記保持手段に保持された所在情報に含まれる所在であれば、前の画面に戻るための操作部を併せて前記ユーザインタフェース手段に表示することを特徴とする情報処理装置。
4. 請求項３に記載の情報処理装置であって、
   前記判定手段は、前記ユーザインタフェース手段に、前の画面に戻るための操作部が表示されているかを、前記コンテンツの一部として取得したスクリプトにより判定することを特徴とする情報処理装置。
5. 請求項１乃至４のいずれか一項に記載の情報処理装置であって、
   前記コンテンツを取得した所在は、ウェブアプリケーションの提供を受けるための認証サービスを提供する所在であることを特徴とする情報処理装置。
6. 請求項５に記載の情報処理装置であって、
   前記制御手段は、前の画面に戻るための操作部を表示するためのコンテンツの所在を特定する前記所在情報を、前記ウェブアプリケーションを提供する所在からのコンテンツの一部として取得することを特徴とする情報処理装置。
7. 請求項６に記載の情報処理装置であって、
   前記制御手段は、前記操作部の位置を、前記ウェブアプリケーションを提供する所在からのコンテンツの一部としてさらに取得し、前記操作部を前記位置に表示することを特徴とする情報処理装置。
8. 請求項１乃至７のいずれか一項に記載の情報処理装置であって、
   前記指定された所在のシンボルを、前記操作部として表示することを特徴とする情報処理装置。
9. 画面への表示とユーザーによる操作とを行えるユーザインタフェース手段と、
   前の画面に戻るための操作部を表示するためのコンテンツの所在を特定する所在情報を保持する保持手段と、
   指定された所在からコンテンツを取得する取得手段と、
   前記コンテンツを表示する際に、前記コンテンツを取得した所在が前記保持手段に保持された所在情報に含まれる所在であれば、前の画面に戻るための操作部を併せて前記ユーザインタフェース手段に表示する制御手段と
   してコンピュータを機能させるためのプログラム。
10. 画面への表示とユーザーによる操作とを行えるユーザインタフェース手段を有する情報処理装置において、
    前の画面に戻るための操作部を表示するためのコンテンツの所在を特定する所在情報を保持手段に保持し、
    指定された所在からコンテンツを取得し、
    前記コンテンツを表示する際に、前記コンテンツを取得した所在が前記保持手段に保持された所在情報に含まれる所在であれば、前の画面に戻るための操作部を併せて前記ユーザインタフェース手段に表示する
    ことを特徴とする情報処理装置の制御方法。

Images