(57)【要約】      （修正有）【課題】ＭＦＰ上のＷｅｂブラウザーへの変更を加えずに、独立したデバッグ用機能を追加する。【解決手段】画像処理装置１０１（ＭＰＦ）のＷｅｂアプリケーション３１０は、決定手段と要求手段と提供手段を備える。決定手段は、デバッグ機能の実行の要求を受け付けると、コンテンツ表示手段１００１〜１００３のうちのいずれにデバッグ機能を実行させるか決定する。要求手段は、決定されたコンテンツ表示手段に対し、Ｗｅｂアプリケーションから第二のスクリプトを取得するための記述がされている第一のスクリプトを送信し、スクリプトを実行させる。提供手段は、第一のスクリプトが実行されたことによりコンテンツ表示手段から送信された第二のスクリプトの取得要求を受信すると、当該コンテンツ表示手段に第二のスクリプトを提供する。第二のスクリプトがコンテンツ表示手段により実行されることで、当該コンテンツ表示手段によりデバッグ機能が提供される。【選択図】図１０
2017097661.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂアプリケーションと、複数のコンテンツ表示手段とを有する画像処理装置であって、
前記Ｗｅｂアプリケーションは、
デバッグ機能の実行の要求を受け付ける受け付け手段と、
前記受け付け手段により前記デバッグ機能の実行の要求を受け付けたことに応じて、前記複数のコンテンツ表示手段のうちのいずれのコンテンツ表示手段にて前記デバッグ機能を実行させるかを決定する決定手段と、
前記決定手段にて決定されたコンテンツ表示手段に対し、前記Ｗｅｂアプリケーションから第二のスクリプトを取得するための記述がされている第一のスクリプトを送信し、当該第一のスクリプトを実行させる要求手段と、
前記第一のスクリプトが実行されたことにより前記コンテンツ表示手段から送信された前記第二のスクリプトの取得の要求を受信したことに応じて、当該コンテンツ表示手段に前記第二のスクリプトを提供する提供手段と
を備え、
前記第二のスクリプトがコンテンツ表示手段により実行されることで、当該コンテンツ表示手段により前記デバッグ機能が提供されることを特徴とする画像処理装置。
【請求項２】
前記複数のコンテンツ表示手段それぞれにより表示される画面のうち、最前面に表示されている画面を特定する特定手段を更に有し、
前記決定手段は、前記特定手段にて特定された画面に対応するコンテンツ表示手段に対して前記デバッグ機能を実行させると決定することを特徴とする請求項１に記載の画像処理装置。
【請求項３】
コンテンツ表示手段により表示される画面に含まれる複数のコンテンツのうち、最後に操作されたコンテンツの情報を保持する保持手段を更に有し、
前記決定手段は、前記特定手段により特定された画面において複数のコンテンツが表示されている場合、前記保持手段にて保持された情報に基づき、最後に操作されたコンテンツに対して前記デバッグ機能を実行させると決定することを特徴とする請求項２に記載の画像処理装置。
【請求項４】
前記第二のスクリプトは、コンテンツ表示手段により実行された際に、コンテンツを含む画面の表示サイズを変更する機能が含まれることを特徴とする請求項１乃至３のいずれか一項に記載の画像処理装置。
【請求項５】
画面遷移を検知する検知手段を更に有し、
前記要求手段は、前記検知手段により画面遷移を検知した場合、前記決定手段にて決定されたコンテンツ表示手段に対し、再度、前記第一のスクリプトを送信し、当該第一のスクリプトを実行させることを特徴とする請求項１乃至４のいずれか一項に記載の画像処理装置。
【請求項６】
前記複数のコンテンツ表示手段は、Ｗｅｂブラウザーを含むことを特徴とする請求項１乃至５のいずれか一項に記載の画像処理装置。
【請求項７】
前記第一のスクリプトは、擬似スキームを用いて記述されることを特徴とする請求項１乃至６のいずれか一項に記載の画像処理装置。
【請求項８】
前記第一のスクリプトは、前記コンテンツ表示手段のＵＲＩスキームで指定が可能な文字数以内で記述されることを特徴とする請求項７に記載の画像処理装置。
【請求項９】
前記第一のスクリプトは、前記コンテンツ表示手段が現在表示しているコンテンツに挿入されることにより実行されることを特徴とする請求項１乃至８のいずれか一項に記載の画像処理装置。
【請求項１０】
前記第二のスクリプトが前記コンテンツ表示手段により実行されることで、前記デバッグ機能の実行結果が当該コンテンツ表示手段の画面に表示されることを特徴とする請求項１乃至９のいずれか一項に記載の画像処理装置。
【請求項１１】
前記第二のスクリプトが前記コンテンツ表示手段により実行されることで、前記デバッグ機能の実行結果が前記Ｗｅｂアプリケーションへ送信され、
前記受け付け手段は、前記デバッグ機能の実行結果を前記デバッグ機能の実行の要求元へ応答として返すことを特徴とする請求項１乃至１０のいずれか一項に記載の画像処理装置。
【請求項１２】
前記受け付け手段は、前記コンテンツ表示手段による前記デバッグ機能の実行の要求を受け付けるための画面を外部装置へ提供することを特徴とする請求項１乃至１１のいずれか一項に記載の画像処理装置。
【請求項１３】
前記第一、および前記第二のスクリプトは、ＪａｖａＳｃｒｉｐｔであることを特徴とする請求項１乃至１２のいずれか一項に記載の画像処理装置。
【請求項１４】
Ｗｅｂアプリケーションと、複数のコンテンツ表示手段とを有する画像処理装置の制御方法であって、
前記Ｗｅｂアプリケーションにおいて、
デバッグ機能の実行の要求を受け付ける受け付け工程と、
前記受け付け工程にて前記デバッグ機能の実行の要求を受け付けたことに応じて、前記複数のコンテンツ表示手段のうちのいずれのコンテンツ表示手段にて前記デバッグ機能を実行させるかを決定する決定工程と、
前記決定工程にて決定されたコンテンツ表示手段に対し、前記Ｗｅｂアプリケーションから第二のスクリプトを取得するための記述がされている第一のスクリプトを送信し、当該第一のスクリプトを実行させる要求工程と、
前記第一のスクリプトが実行されたことにより前記コンテンツ表示手段から送信された前記第二のスクリプトの取得の要求を受信したことに応じて、当該コンテンツ表示手段に前記第二のスクリプトを提供する提供工程と
を有し、
前記第二のスクリプトがコンテンツ表示手段により実行されることで、当該コンテンツ表示手段により前記デバッグ機能が提供されることを特徴とする画像処理装置の制御方法。
【請求項１５】
Ｗｅｂアプリケーションと、複数のコンテンツ表示手段とを有するコンピューターに、
前記Ｗｅｂアプリケーションにおいて、
デバッグ機能の実行の要求を受け付ける受け付け工程と、
前記受け付け工程にて前記デバッグ機能の実行の要求を受け付けたことに応じて、前記複数のコンテンツ表示手段のうちのいずれのコンテンツ表示手段にて前記デバッグ機能を実行させるかを決定する決定工程と、
前記決定手段にて決定されたコンテンツ表示手段に対し、前記Ｗｅｂアプリケーションから第二のスクリプトを取得するための記述がされている第一のスクリプトを送信し、当該第一のスクリプトを実行させる要求工程と、
前記第一のスクリプトが実行されたことにより前記コンテンツ表示手段から送信された前記第二のスクリプトの取得の要求を受信したことに応じて、当該コンテンツ表示手段に前記第二のスクリプトを提供する提供工程と
を実行させ、
前記第二のスクリプトがコンテンツ表示手段により実行されることで、当該コンテンツ表示手段により前記デバッグ機能が提供されることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像処理装置およびその制御方法、並びにプログラムに関する。
【背景技術】
【０００２】
近年、ＭＦＰ（Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｅｒｉｐｈｅｒａｌ）などの画像処理装置の中に、ネットワーク上のＷｅｂサーバーが備えるＷｅｂアプリケーションと連携して処理を行うＷｅｂブラウザーを備えているものがある。Ｗｅｂブラウザーには、Ｗｅｂアプリケーションのコンテンツの開発を補助するための様々な機能が搭載されていることが知られている。例えば、表示中のコンテンツの内容を表示する機能、コンソールログを表示する機能、ＪａｖａＳｃｒｉｐｔ（登録商標）のステップ実行機能などが挙げられる。これらにより、コンテンツ開発者は効率的にＷｅｂアプリケーションの開発を行うことが可能となる。また、上述したようなＷｅｂブラウザーの機能を、簡単にＷｅｂブラウザー以外のアプリケーションから利用できるようにするための、ＷｅｂＶｉｅｗと呼ばれるＧＵＩコンポーネントが提供されていることも多い。アプリケーション開発者はこのＷｅｂＶｉｅｗを用いることで、簡単にＷｅｂコンテンツを表示するアプリケーションを開発することができる。
【０００３】
一方、Ｗｅｂアプリケーションのデバッグ操作をリモートで行う方法として、特許文献１では、開示された方法を用いることで、ＰＣなどを用いてリモート環境から対象となるデバイスのデバッグを行うことができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１１−８５５６４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＭＦＰが備えるＷｅｂブラウザーで表示・動作させるためのＷｅｂアプリケーションを開発するためには、実際にＭＦＰが備えるＷｅｂブラウザーで動作させて確認することが重要である。しかし、ＭＦＰが備えるＷｅｂブラウザー向けに、各種デバッグ用の機能を追加することは、開発・運用コストが大きくかかるという問題がある。これは、ＭＦＰが様々な機種が生産されており、それに搭載されるソフトウェアは機器構成の異なる複数の機種のＭＦＰに対応する必要があることに起因する。更に、Ｗｅｂブラウザーへの変更を加えることは、既存のＭＦＰに対してファームウェアアップデートを必要とする。
【０００６】
そこで、画像形成装置が備えるＷｅｂブラウザー自体に変更を加えずに、Ｗｅｂブラウザーに対し、共通利用できる独立したデバッグ用機能を追加する方法が望まれている。
【課題を解決するための手段】
【０００７】
上記課題を解決するために本願発明は以下の構成を有する。すなわち、Ｗｅｂアプリケーションと、複数のコンテンツ表示手段とを有する画像処理装置であって、前記Ｗｅｂアプリケーションは、デバッグ機能の実行の要求を受け付ける受け付け手段と、前記受け付け手段により前記デバッグ機能の実行の要求を受け付けたことに応じて、前記複数のコンテンツ表示手段のうちのいずれのコンテンツ表示手段にて前記デバッグ機能を実行させるかを決定する決定手段と、前記決定手段にて決定されたコンテンツ表示手段に対し、前記Ｗｅｂアプリケーションから第二のスクリプトを取得するための記述がされている第一のスクリプトを送信し、当該第一のスクリプトを実行させる要求手段と、前記第一のスクリプトが実行されたことにより前記コンテンツ表示手段から送信された前記第二のスクリプトの取得の要求を受信したことに応じて、当該コンテンツ表示手段に前記第二のスクリプトを提供する提供手段とを備え、前記第二のスクリプトがコンテンツ表示手段により実行されることで、当該コンテンツ表示手段により前記デバッグ機能が提供される。
【発明の効果】
【０００８】
本願発明により、画像形成装置が備えるＷｅｂブラウザーのプログラム変更を行うことなく共通利用できる独立したデバッグ機能を追加することができる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態に係るシステム全体の構成例を示す図。
【図２】本実施形態に係る各装置のハードウェア構成の例を示す図。
【図３】本実施形態に係るＭＦＰのソフトウェア構成の例を示す図。
【図４】本実施形態に係るデバッグ機能動作までのシーケンス図。
【図５】本実施形態に係るＪａｖａＳｃｒｉｐｔの記述例を示す図。
【図６】本実施形態に係るデバッグツール画面の例を示す図。
【図７】本実施形態に係るデバッグ実行時のＷｅｂブラウザー画面の例を示す図。
【図８】本実施形態に係るデバッグ実行時の処理を示すフローチャート。
【図９】本実施形態に係る情報の構成例を示す図。
【図１０】本実施形態に係るＭＦＰのソフトウェアの連携を説明するための図。
【図１１】本実施形態に係るデバック実行時のＷｅｂブラウザー画面の例を示す図。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための一実施形態について図面を用いて説明する。
【００１１】
＜第一の実施形態＞
［システム構成］
図１は、本発明に係る画像処理装置を含むシステム全体の構成例を示す。本システムは、画像処理装置としてのＭＦＰ１０１、情報処理装置１０２、およびサーバー１０３を含んで構成され、各装置はネットワーク１００を介して通信可能に接続される。ネットワーク１００は、各装置間で通信を行うための基盤であって、インターネットなどの外部ネットワークに接続されていてもよい。また、ネットワーク１００は、有線／無線は問わない。ＭＦＰ１０１は、画像処理装置であり、Ｗｅｂブラウザー機能を有する。なお、本実施形態では、画像処理装置の例としてＭＦＰを用いて説明するがこれに限定されるものではなく、Ｗｅｂブラウザー機能を有する装置であればよい。情報処理装置１０２は、ネットワーク１００経由でＭＦＰ１０１と接続され、自身が備えるＷｅｂブラウザーを介してＭＦＰ１０１にＨＴＴＰリクエストを送信することが可能である。なお、ここで用いる通信プロトコルは、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）に限定するものではなく、本願発明に係る各種リクエストが可能であれば、他の通信プロトコルを用いてもよい。情報処理装置１０２は、ネットワーク１００に接続され、Ｗｅｂブラウザーが利用できればどのような装置でもよく、ＰＣや携帯電話のようなモバイル端末でもよい。
【００１２】
サーバー１０３は、Ｗｅｂコンテンツを、ネットワーク１００を介して配信する機能を備え、ＭＦＰ１０１からのリクエストに応じてＷｅｂコンテンツを返す。各装置は、ローカルネットワーク上に存在してもよいし、インターネットなどの外部ネットワークを介して接続されていてもよい。
【００１３】
図２は、本実施形態に係るＭＦＰ１０１、情報処理装置１０２、およびサーバー１０３のハードウェア構成の一例を示す。ここでは、いずれの装置も同じハードウェアを含んで構成されているものとして説明するが、それぞれが異なる部位を備える構成であってもよい。各装置は、自装置全体を制御するＣＰＵ２０１、ワークエリアとして機能するＲＡＭ２０２、各種プログラムや設定を記憶する記憶装置２０３を含む。記憶装置２０３としては、ＨＤＤやＮＶＲＡＭ等が挙げられる。さらに、各装置は、ユーザーがコマンドの入力を行うためのユーザー入力装置２０４、画面表示を行うＵＩ表示装置２０５、および、他機器とネットワーク１００による通信を行うネットワーク装置２０６を含んで構成される。各部位は、メインバス２００に接続され、各部位間で通信可能である。尚、本実施形態において、特に断らない限り、各装置は、ＣＰＵ２０１がメインバス２００を介してＲＡＭ２０２、記憶装置２０３、ユーザー入力装置２０４、ＵＩ表示装置２０５、およびネットワーク装置２０６を制御する。ＵＩ表示装置２０５は、タッチパネルディスプレイのように、ユーザー入力装置２０４を兼ねてもよい。また、サーバー１０３は、ユーザー入力装置２０４とＵＩ表示装置２０５を有していなくてもよい。また、ＭＦＰ１０１は、図２に示す構成の他にも画像読取部や印刷部がメインバス２００に接続されていてもよい。
【００１４】
図３は、本実施形態に係るＭＦＰ１０１のソフトウェア構成の例を示す。図３に示す各機能部は、ＭＦＰ１０１が有するＣＰＵ２０１が記憶装置２０３に保持された制御プログラムを読み出して実行することにより実現される。以下、アプリケーションを単に「アプリ」とも称する。
【００１５】
ＭＦＰ１０１は、Ｗｅｂアプリケーション３１０、エンジン利用アプリ３２０、ブラウザエンジン３３０、振分モジュール３４０、およびウィンドウ制御モジュール３５０を有する。なお、エンジン利用アプリ３２０は、サーバー１０３が提供するコンテンツを表示するものに限定しない。また、エンジン利用アプリ３２０は、任意のサーバーと通信を行うことによってコンテンツを取得し、画面に表示するといった機能を有するものであればよい。
【００１６】
エンジン利用アプリ３２０は、ブラウザエンジン３３０が提供するＷｅｂコンテンツを描画する機能を利用したアプリケーションであり、ＷｅｂブラウザーやＷｅｂＶｉｅｗを利用するアプリケーション（以下、「ＷｅｂＶｉｅｗ利用アプリ」）が該当する。また、エンジン利用アプリ３２０は複数存在してよい。本実施形態では、エンジン利用アプリ３２０が複数存在する場合に、その中からどれをデバッグ処理の対象にするか決定するための方法、及び構成に特徴を有する。本実施形態に係るエンジン利用アプリ３２０が複数存在する場合のモジュール間の関係については、図１０を用いて後述する。
【００１７】
Ｗｅｂアプリケーション３１０は、デバッグ機能の操作ＵＩ（Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を提供し、外部からの指示に従ってデバッグ機能を実行するモジュールである。Ｗｅｂアプリケーション３１０は、通信部３１１、処理部３１２、および記憶部３１３を有する。通信部３１１は、ＭＦＰ１０１のエンジン利用アプリ３２０からのＨＴＴＰリクエストを受け付け、リクエスト内容に応じたＨＴＴＰレスポンスを返す。このとき、通信部３２１は、記憶部３１３に保存されているコンテンツデータを参照し、ＨＴＴＰレスポンスを生成する。本実施形態では、デバッグ機能を提供するＪａｖａＳｃｒｉｐｔファイルが応答として返される。なお、本実施形態では、デバッグ機能に係るスクリプトが記載されるスクリプト言語として、ＪａｖａＳｃｒｉｐｔ（登録商標）を例にとって説明している。この場合において、エンジン利用アプリ３２０では、ＪａｖａＳｃｒｉｐｔ（登録商標）の実行が可能な構成であるものとする。
【００１８】
同様に、通信部３２１は、情報処理装置１０２からのＨＴＴＰリクエストを受け付け、リクエスト内容に応じたＨＴＴＰレスポンスを返す。本実施形態では、リクエストに応じて、デバッグ機能をユーザーに提供するためのＵＩや、デバッグ機能の実行結果を返す。
【００１９】
処理部３１２は、通信部３１１がエンジン利用アプリ３２０からのデバッグ実行要求を受け付けた際に、記憶部３１３から後述する挿入ＪａｖａＳｃｒｉｐｔを読み出し、振分モジュール３４０の処理部３４１にデバッグ実行を要求する。このとき、読み出したＪａｖａＳｃｒｉｐｔを、ＪａｖａＳｃｒｉｐｔ擬似スキーム（ｊａｖａｓｃｒｉｐｔ：）を用いた形に変換してから挿入を行う。ここでの変換後の記述例については図５（ｂ）を用いて後述する。本実施形態に係る、挿入されるＪａｖａＳｃｒｉｐｔを便宜上、「挿入ＪａｖａＳｃｒｉｐｔ」もしくは「第一のスクリプト」と記載する。挿入は、エンジン利用アプリ３２０の処理部３２３に対して依頼をすることで行われる。ＪａｖａＳｃｒｉｐｔ擬似スキームを用いたＪａｖａＳｃｒｉｐｔの挿入は、ＨＴＴＰスキーム（ＵＲＩスキーム）によるＵＲＬ指定の代わりに指示することが可能であり、例えば、一般的なＷｅｂブラウザーではこの機能をサポートしている。
【００２０】
記憶部３１３には、通信部３１１でレスポンスするコンテンツや、処理部３１２で挿入するＪａｖａＳｃｒｉｐｔのデータが保存されており、通信部３１１や処理部３１２からの要求に従って保存されたデータを読み出される。また、Ｗｅｂアプリケーション３１０は、ＭＦＰ１０１にプリインストールされている必要はなく、Ｊａｖａアプリケーションとして構成されており、後からインストールすることができるものであってよい。ＭＦＰ１０１には、Ｊａｖａアプリケーションを実行するためのＪａｖａ実行環境（不図示）が搭載される。
【００２１】
エンジン利用アプリ３２０は、ブラウザエンジン３３０を利用したＷｅｂコンテンツを表示可能なアプリケーションである。エンジン利用アプリ３２０は、通信部３２１、解析部３２２、および処理部３２３を有する。通信部３２１は、ＨＴＴＰに従って、Ｗｅｂアプリケーション３１０、及び、サーバー１０３と通信する。具体的には、通信部３２１は、エンジン利用アプリ３２０で表示した操作画面を介して入力される情報をサーバー１０３に対するリクエストとして送信し、表示コンテンツをレスポンスとして受信する。また、通信部３２１は、挿入ＪａｖａＳｃｒｉｐｔの動作に従って、Ｗｅｂアプリケーション３１０にデバッグ機能を提供するためのＪａｖａＳｃｒｉｐｔを取得するリクエストを送信する。また、通信部３２１は、そのレスポンスをＷｅｂアプリケーション３１０から受信する。ここで、デバッグ機能を提供するためのＪａｖａＳｃｒｉｐｔを便宜上、「第二のスクリプト」とも記載する。
【００２２】
解析部３２２は、サーバー１０３やＷｅｂアプリケーション３１０から受信したレスポンスを解析する。レスポンスの中にはエンジン利用アプリ３２０に表示すべき操作画面の内容を示す記述であるＨＴＭＬデータや、ＪａｖａＳｃｒｉｐｔが記載されている。処理部３２３は、ブラウザエンジン３３０の処理部３３１に処理を依頼することで、解析部３２２による解析結果に基づいて、表示コンテンツをＵＩ表示装置２０５に表示したり、ＪａｖａＳｃｒｉｐｔが含まれる場合は、そのＪａｖａＳｃｒｉｐｔを実行したりする。また、処理部３２３は、振分モジュール３４０の処理部３４１からＪａｖａＳｃｒｉｐｔ擬似スキームによるＪａｖａＳｃｒｉｐｔ実行指示を受け付けた場合、ブラウザエンジン３３０の処理部３３１に処理を依頼する。これにより、与えられたＪａｖａＳｃｒｉｐｔが実行される。
【００２３】
本実施形態では、処理部３２３は、Ｗｅｂアプリケーション３１０の処理部３１２から、振分モジュール３４０を介して挿入ＪａｖａＳｃｒｉｐｔの実行指示を受け付けて実行する。挿入ＪａｖａＳｃｒｉｐｔが実行されることにより、処理部３２３は、通信部３２１を介して、Ｗｅｂアプリケーション３１０にデバッグ機能を提供するＪａｖａＳｃｉｒｐｔをリクエストする。そして、処理部３２３は、リクエストの応答として受信したＪａｖａＳｃｒｉｐｔが現在表示中のコンテンツに挿入、実行されることによって、デバッグ機能を提供することが可能となる。具体的には、現在表示中のコンテンツのＤＯＭ（Ｄｏｃｕｍｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ）をＪａｖａＳｃｒｉｐｔによって解析し、その詳細な内容をＨＴＭＬコンテンツ上に視覚的に描画する。また、処理部３２３は、スタイルを入力するフォームを設け、動的にコンテンツの見た目を書き換える機能を提供する。ただし、デバッグ機能は前述の機能に限るものではなく、コンソールログの表示機能など、ユーザーのＷｅｂアプリケーション開発の効率を向上させる様々な機能を有していてもよい。
【００２４】
エンジン利用アプリ３２０の処理部３２３上でデバッグ機能を実行するのは、ＭＦＰ上のＷｅｂブラウザーで表示・動作させるＷｅｂアプリケーションを開発する際に、実際にＭＦＰ上のＷｅｂブラウザーで動作させて確認することが重要なためである。これは、一般的にＷｅｂブラウザーの種類やバージョンが異なると、Ｗｅｂコンテンツの表示機能に差異が存在するからである。
【００２５】
上述したように、デバッグ操作を指示するためのＵＩを複数のエンジン利用アプリ３２０のそれぞれに作り込むのはコストがかかる。そこで、本実施形態では、共通して利用できる形として、外部の情報処理装置１０２からＷｅｂアプリケーション３１０を介して、デバッグ操作の指示を受け付けるようにする。
【００２６】
ブラウザエンジン３３０は、Ｗｅｂコンテンツの描画や、ＪａｖａＳｃｒｉｐｔの実行を行うための処理機能を持ったモジュールである。ブラウザエンジン３３０は、処理部３３１、および管理部３３２を有する。処理部３３１は、エンジン利用アプリ３２０からの要求に従って、Ｗｅｂコンテンツを解析して描画したり、ＪａｖａＳｃｒｉｐｔを実行したりする。また、処理部３３１は、振分モジュール３４０の処理部３４１に対して、エンジン利用アプリ３２０の識別情報を送信する。ここでの識別情報は、エンジン利用アプリ３２０が起動したときに、エンジン利用アプリ３２０から通知されるエンジン利用アプリを一意に識別するための識別子を管理部３３２で保存していたものである。処理部３３１は、複数のエンジン利用アプリ３２０が起動完了した後、振分モジュール３４０に保存されている全ての識別子を通知する。管理部３３２は、前述の通り、エンジン利用アプリ３２０から通知される識別子を保持する。
【００２７】
振分モジュール３４０は、Ｗｅｂアプリケーション３１０からのデバッグ機能の実行指示を、複数存在するエンジン利用アプリ３２０のいずれかに転送するモジュールである。振分モジュール３４０は、Ｗｅｂアプリケーション３１０や、ブラウザエンジン３３０の一部として存在してもよいし、独立したモジュールとして存在してもよい。
【００２８】
振分モジュール３４０は、処理部３４１、および記憶部３４２を有する。処理部３４１は、ブラウザエンジン３３０の処理部３３１からエンジン利用アプリ３２０の識別子を受け付けると、記憶部３４２にその識別子を保存する。また、処理部３４１は、ウィンドウ制御モジュール３５０の処理部３５１に対して、画面遷移イベントの通知を要求する。これにより、ＭＦＰ１０１上で動作するアプリケーションの画面が遷移し、最前面に表示されている画面が変更になった場合に、振分モジュール３４０はウィンドウ制御モジュール３５０から通知を受け取ることができる。振分モジュール３４０は、通知を受け取ると、記憶部３４２に保存されている識別子の中に、通知に含まれるアプリケーションの識別子と一致するものがあるか否かを確認する。一致するものがあれば、その識別子のアプリケーションはエンジン利用アプリであり、かつ、最前面に表示されたことになるため、その識別子を最前面のアプリケーション（以下、「最前面アプリ」）の識別子として記憶部３４２に保存する。処理部３４１は、Ｗｅｂアプリケーション３１０の処理部３１２からデバッグ実行指示の要求を受け付けると、記憶部３４２に保存した最前面アプリの識別子に基づいて、デバッグ実行指示を転送する対象となるエンジン利用アプリ３２０を決定する。そして、処理部３４１は、その決定されたエンジン利用アプリ３２０に対し、デバッグ実行指示を転送する。
【００２９】
記憶部３４２は、前述の通り、ブラウザエンジン３３０から通知される複数のエンジン利用アプリ３２０の識別子と、画面が最前面に表示されているエンジン利用アプリ３２０（最前面アプリ）の識別子が保存されている。保存例を図９（ａ）に示す。記憶部３４２には、エンジン利用アプリ３２０の識別子９０１と、最前面アプリの識別子９０２が存在している。識別子９０１には、ＭＦＰ１０１上に存在する全てのエンジン利用アプリ３２０の識別子が保存されている。最前面アプリの識別子９０２は、エンジン利用アプリのうち、最前面に表示されているアプリの識別子である。従って、複数のエンジン利用アプリ３２０が登録されている場合においては、そのうちの１つのみが最前面アプリとして管理されることとなる。
【００３０】
ウィンドウ制御モジュール３５０は、ＭＦＰ１０１上で実行されるアプリケーションそれぞれに対応するウィンドウを制御するためのモジュールである。ウィンドウ制御モジュール３５０は、処理部３５１を有する。処理部３５１は、ＭＦＰ１０１上のアプリケーションが画面遷移し、最前面に表示された場合に、画面遷移したアプリケーションを特定し、その識別子を振分モジュール３４０の処理部３４１に通知する。
【００３１】
［処理シーケンス］
図４は、情報処理装置１０２からのリクエストによってＭＦＰ１０１でデバッグ機能が呼び出される際のシーケンスを示す。前提として、エンジン利用アプリ３２０では、Ｗｅｂアプリケーションの開発者がデバッグ機能を実行したいＷｅｂコンテンツの画面を表示しているものとする。ここでのＷｅｂコンテンツは、例えば、サーバー１０３から取得されているものとする。また、本処理シーケンスは、ＭＦＰ１０１および情報処理装置１０２それぞれのＣＰＵ２０１が記憶装置２０３に格納された各種プログラムを読み出して実行する事により実現される。
【００３２】
Ｓ４０１にて、ユーザーの操作に従って、情報処理装置１０２は、情報処理装置１０２上のＷｅｂブラウザー（不図示）から、Ｗｅｂアプリケーション３１０に対して、デバッグツール画面６００（後述）の取得のためのＨＴＴＰリクエストを送信する。
【００３３】
Ｓ４０２にて、情報処理装置１０２からのリクエストに応じて、ＭＦＰ１０１のＷｅｂアプリケーション３１０は、デバッグツール画面６００のコンテンツを、要求元である情報処理装置１０２にレスポンスとして返す。また、レスポンスを受信した情報処理装置１０２のＷｅｂブラウザー（不図示）は、デバッグツール画面６００のコンテンツを表示する。
【００３４】
Ｓ４０３にて、ユーザーは、情報処理装置１０２のＷｅｂブラウザー（不図示）上に表示されているデバッグツール画面６００を操作し、デバッグツール画面６００の各種ボタンを操作することで、デバッグ機能の実行指示を行う。
【００３５】
Ｓ４０４にて、情報処理装置１０２は、Ｓ４０３にてユーザーにより行われたデバッグ機能実行指示に従って、Ｗｅｂアプリケーション３１０に対してデバッグ機能実行を要求するＨＴＴＰリクエストを送信する。
【００３６】
Ｓ４０５にて、Ｗｅｂアプリケーション３１０は、Ｓ４０４にて情報処理装置１０２から送信されたＨＴＴＰリクエストに応じて、デバッグツール画面６００のコンテンツをレスポンスとして返す。このとき、デバッグ実行処理を受け付けたことを示す記述がコンテンツに含まれている。なお、Ｗｅｂアプリケーション３１０は、レスポンスを、ＭＦＰ１０１のエンジン利用アプリ３２０によるデバッグ処理の実行が完了した後に返すようにしてもよい。例えば、Ｗｅｂアプリケーション３１０は、後述するＳ４１２の後に、処理の実行結果をエンジン利用アプリ３２０から受信し、その結果を含めて情報処理装置１０２にレスポンスを返すようにしてもよい。これにより、ＭＦＰ１０１側のみならず、情報処理装置１０２側でもデバッグのための情報を参照することが可能となる。
【００３７】
Ｓ４０６にて、Ｗｅｂアプリケーション３１０は、Ｓ４０４にて情報処理装置１０２からデバッグ機能実行の要求を受信したことに応じて、振分モジュール３４０に対して、ＪａｖａＳｃｒｉｐｔ擬似スキームを用いて、コンテンツに対する挿入ＪａｖａＳｃｒｉｐｔの挿入を依頼する。挿入ＪａｖａＳｃｒｉｐｔはコンテンツに挿入されることで、このコンテンツが実行された際に併せて実行されることとなる。
【００３８】
図５（ａ）は、に挿入ＪａｖａＳｃｒｉｐｔの記述例を示す。挿入ＪａｖａＳｃｒｉｐｔには、デバッグ機能を提供するＪａｖａＳｃｒｉｐｔをダウンロードするための処理が記述されている。挿入ＪａｖａＳｃｒｉｐｔが実行されると、ＵＲＬ５０１が示す宛先（ここでは、Ｗｅｂアプリケーション３１０）に対してデバッグ機能を提供するＪａｖａＳｃｒｉｐｔを取得するためのリクエストを送信する。
【００３９】
なお、上述したように、ＪａｖａＳｃｒｉｐｔ擬似スキームによるＪａｖａＳｃｒｉｐｔの指定は、Ｗｅｂブラウザーに対してＨＴＴＰスキームでＵＲＬを指定する代わりに行われる。そのため、一般的に、Ｗｅｂブラウザーで許容されるＵＲＬの文字列長の上限までのＪａｖａＳｃｒｉｐｔしか実行（記述）できない。この理由により、デバッグ機能を提供するＪａｖａＳｃｒｉｐｔ（すなわち、第二のスクリプト）を直接挿入することはできない。従って、ＪａｖａＳｃｒｉｐｔ擬似スキームで挿入するＪａｖａＳｃｒｉｐｔ（すなわち、第一のスクリプト）に、デバッグ機能を提供するＪａｖａＳｃｒｉｐｔ（すなわち、第二のスクリプト）をダウンロードするための処理が記述される。本実施形態において、このダウンロードするための処理が記述されている挿入ＪａｖａＳｃｒｉｐｔは、Ｗｅｂアプリケーション３１０の記憶部３１３に保存されている。なお、挿入ＪａｖａＳｃｒｉｐｔは、エンジン利用アプリ３２０にて許容されるＵＲＬ（ＵＲＩ）の文字数以内となるように記述される。
【００４０】
図５（ｂ）は、ＪａｖａＳｃｒｉｐｔ擬似スキームを用いた例を示す。ＪａｖａＳｃｒｉｐｔ擬似スキーム５０２が付与されたワンラインのＪａｖａＳｃｒｉｐｔである。なお、デバッグ機能を提供するためのＪａｖａＳｃｒｉｐｔ（第二のスクリプト）の記述の詳細はここでは省略するが、上述したように各種デバッグ機能に応じた記述がなされるものとする。
【００４１】
Ｓ４０７にて、振分モジュール３４０は、Ｓ４０６にて受け付けた挿入ＪａｖａＳｃｒｉｐｔを、複数存在するエンジン利用アプリ３２０のどれに挿入させるかを決定する。言い換えると、振分モジュール３４０は、いずれのエンジン利用アプリ３２０にて、デバッグ機能を実行させるかを決定する。挿入対象の決定は、前述の通り、ウィンドウ制御モジュール３５０により通知された画面遷移イベントの情報に基づいて、画面が最前面に表示されているエンジン利用アプリ３２０の識別子を記憶部３４２に保存しておくことで実現する。保存する際のフローについては、図８（後述）にて詳細に説明する。すなわち、振分モジュール３４０は、挿入ＪａｖａＳｃｒｉｐｔの挿入指示を受け付けた際に、記憶部３４２に保存された識別子を参照して決定する。この決定処理により、ユーザーが現在操作しているエンジン利用アプリ３２０に対して、デバッグ機能を実行させることができるようになる。図９（ａ）の例であれば、識別子が、「Ａｐｐｌｉｃａｉｏｎ＿ＩＤ＿２」であるアプリの画面が最前面に表示されているため、識別子が「Ａｐｐｌｉｃａｉｏｎ＿ＩＤ＿２」であるアプリに挿入ＪａｖａＳｃｒｉｐｔを挿入すると決定される。
【００４２】
Ｓ４０８にて、振分モジュール３４０は、Ｓ４０７で決定した振分先（挿入先）に対して、Ｓ４０６で受け付けた挿入ＪａｖａＳｃｒｉｐｔの挿入を依頼する。これにより、エンジン利用アプリ３２０は、現在表示しているＷｅｂコンテンツに挿入ＪａｖａＳｃｒｉｐｔを挿入する。
【００４３】
Ｓ４０９にて、エンジン利用アプリ３２０は、Ｓ４０８で挿入された挿入ＪａｖａＳｃｒｉｐｔを解釈し、実行する。
【００４４】
Ｓ４１０にて、Ｓ４０９にて挿入された挿入ＪａｖａＳｃｒｉｐｔが実行されることにより、エンジン利用アプリ３２０は、Ｗｅｂアプリケーション３１０に対して、デバッグ機能を提供するＪａｖａＳｃｒｉｐｔ（第二のスクリプト）を取得するためのＨＴＴＰリクエストを送信する。
【００４５】
Ｓ４１１にて、Ｗｅｂアプリケーション３１０は、Ｓ４１０のリクエストに応じて、デバッグ機能を提供するＪａｖａＳｃｒｉｐｔ（第二のスクリプト）を記憶部３１３から読み出し、レスポンスとしてエンジン利用アプリ３２０に返す。
【００４６】
Ｓ４１２にて、エンジン利用アプリ３２０は、Ｓ４１１でＷｅｂアプリケーション３１０から受信したデバッグ機能を提供するＪａｖａＳｃｒｉｐｔを実行する。
【００４７】
図６は、デバッグツール画面６００の例を示す。デバッグツール画面６００は、ＭＦＰ１０１のＷｅｂアプリケーション３１０によってＷｅｂコンテンツとして提供され、情報処理装置１０２のＷｅｂブラウザー（不図示）上に表示される。これは、ＭＦＰ１０１のエンジン利用アプリ３２０上で表示されているコンテンツをデバッグするにあたって、ＭＦＰ１０１の画面を占有しないようにするためである。また、エンジン利用アプリ３２０にデバッグ機能実行のための画面を作り込む必要をなくすためでもある。
【００４８】
デバッグツール画面６００には１または複数のデバッグ実行指示ボタン６０１が含まれる。デバッグ実行指示ボタン６０１は、デバッグに関する様々な操作に対応している。デバッグ実行指示ボタン６０１が押下されると、情報処理装置１０２のＷｅｂブラウザー（不図示）は、Ｗｅｂアプリケーション３１０に対して、デバッグ処理実行のためＨＴＴＰリクエストを送信する。ここでは、３つのデバッグ機能それぞれに対応したボタンを設けた例を示しているがこれに限定するものではなく、更に多くのデバッグ機能が設けられてもよい。
【００４９】
図７は、ＭＦＰ１０１のエンジン利用アプリ３２０における、デバッグ機能実行時の画面の例を示す。画面７００には、オリジナルコンテンツ７０１とデバッグ機能による追加コンテンツ７０２が含まれる。オリジナルコンテンツ７０１は、ユーザーがデバッグを実行したいＷｅｂコンテンツを示す。それに対して、デバッグ機能が実行されることで、追加コンテンツ７０２の領域が画面７００上に表示される。図７に示す例では、追加コンテンツ７０２にはオリジナルコンテンツ７０１の詳細な情報（ＨＴＭＬのソースコード）が表示された例を示している。しかし、これに限定するものではなく、出力されたログや、Ｃｏｏｋｉｅの情報など、その他の情報が表示されるようにしてもよい。
【００５０】
［処理フロー］
図８は、ＭＦＰ１０１における、最前面アプリの識別子保存処理のフローである。最前面にあるアプリケーションの画面が変更された際に、行われる処理である。本処理フローはＭＦＰ１０１のＣＰＵ２０１が記憶装置２０３に格納されたプログラムを読み出して実行することにより実現される。
【００５１】
Ｓ８０１にて、ウィンドウ制御モジュール３５０は、ＭＦＰ１０１上で動作するアプリケーションの画面遷移を検知する。ここで検知されるのは、アプリケーションの画面が最前面に表示される場合の画面遷移である。
【００５２】
Ｓ８０２にて、ウィンドウ制御モジュール３５０は、Ｓ８０１で検知した画面遷移（画面遷移イベント）を、振分モジュール３４０に通知する。このとき、画面遷移したアプリケーションの識別子を通知に含めることで、ウィンドウ制御モジュール３５０は、どのアプリケーションの画面が遷移したのかを振分モジュール３４０に通知する。
【００５３】
Ｓ８０３にて、振分モジュール３４０は、Ｓ８０２で通知されたアプリケーションの識別子と一致する識別子が、記憶部３４２に保持されたテーブル９００の識別子９０１に保存されているか否かを確認する。一致する識別子が保存されている場合は（Ｓ８０３にてＹＥＳ）Ｓ８０４に進み、保存されていない場合は（Ｓ８０３にてＮＯ）本処理フローを終了する。保存されていない場合とは、通知されたアプリケーションがエンジン利用アプリではない場合であるため、本実施形態では現在の状態を維持する。すなわち、最前面にあるアプリの情報は更新されず、エンジン利用アプリ３２０がその他の種類のアプリの背面に隠れていたとしても、最前面アプリとして扱われることでデバッグの対象となる。これは、設定画面やエラー通知画面など、エンジン利用アプリ３２０から一時的に他の画面に遷移している場合があるためである。
【００５４】
Ｓ８０４にて、振分モジュール３４０は、Ｓ８０２で通知され識別子のアプリケーションがエンジン利用アプリ３２０であり、最前面に表示されたとして特定する。そして、振分モジュール３４０は、最前にあるエンジン利用アプリ３２０の識別子として、Ｓ８０２で通知された識別子を記憶部３４２に保持されたテーブル９００の識別子９０２に保存する。
【００５５】
保存された識別子は、ユーザーによってデバッグ機能の実行が指示された場合に読み出して利用される（図４のＳ４０７）。本実施形態では、最前面に表示された画面が切り替わった際に、最前面アプリの判定を行っているが、デバッグ機能実行の指示を受け付けた際に、振分モジュール３４０がウィンドウ制御モジュール３５０に最前面アプリを問い合わせる構成であってもよい。
【００５６】
図１０は、ＭＦＰ１０１におけるエンジン利用アプリ３２０が複数存在する場合の構成例である。ＭＦＰ１０１には、ＷｅｂＶｉｅｗ利用アプリ１００１、ＷｅｂＶｉｅｗ利用アプリ１００２、およびＷｅｂブラウザー１００３が含まれる。これらは全てエンジン利用アプリ３２０であり、ブラウザエンジン３３０を利用してＷｅｂコンテンツを表示することができるアプリケーションである。なお、エンジン利用アプリ３２０は、これらに限定するものではなく、この他にも存在してよい。また、ＷｅｂＶｉｅｗ利用アプリ１００１、ＷｅｂＶｉｅｗ利用アプリ１００２、およびＷｅｂブラウザー１００３は、それぞれが異なるアプリケーションであり、ウィンドウ制御モジュール３５０によって、ウィンドウの表示上の前後関係が制御される。
【００５７】
ユーザーがアプリケーションを起動して利用する際には、ウィンドウ制御モジュール３５０によって、利用するアプリの画面が最前面に表示される。その際、ウィンドウ制御モジュール３５０は、振分モジュール３４０に最前面に表示された画面のアプリケーションの識別子を通知する。振分モジュール３４０は、上述した方法により、最前面アプリを判定し、デバッグ実行指示を受け付けた場合に、ＷｅｂＶｉｅｗ利用アプリ１００１、ＷｅｂＶｉｅｗ利用アプリ１００２、もしくはＷｅｂブラウザー１００３のいずれかに、デバッグ実行指示を送る。
【００５８】
以上に示す構成により、ＭＦＰ上に配置されたＷｅｂアプリケーションは、外部からのＨＴＴＰリクエストを受け付けると、最前面に表示されたＷｅｂコンテンツ表示機能を有するアプリケーションのコンテンツに、ＪａｖａＳｃｒｉｐｔを挿入する。そして、ＪａｖａＳｃｒｉｐｔが挿入されたコンテンツは、そのＪａｖａＳｃｒｉｐｔが解釈され、実行されることにより、さらにデバッグ機能を有するＪａｖａＳｃｒｉｐｔを取得する。これにより、ＭＦＰ上のＷｅｂブラウザーやＷｅｂＶｉｅｗ利用アプリへの変更を入れずに、それらで共通で利用できる独立したデバッグ機能を後から追加することができる。
【００５９】
また、上記実施形態では、複数のＷｅｂ利用アプリが画像形成装置にて動作している場合であっても、画面の表示状態に応じてデバッグ機能を実行させるコンテンツを切り替えることが可能となる。
【００６０】
＜その他の実施形態＞
本願発明に係るその他の実施形態について説明する。エンジン利用アプリ３２０において、複数のコンテンツが同時に表示される状況が存在する。例えば、Ｗｅｂブラウザーにおいてタブ形式で同時にコンテンツを表示している場合や、ＷｅｂＶｉｅｗを利用した画面（表示領域）を２つ以上ならべて配置している場合などである。図１１（ａ）は、ＷｅｂＶｉｅｗを２つ以上ならべて配置している画面１１００の表示例を示す。一つのアプリケーション上に、ＷｅｂＶｉｅｗを利用した表示領域１１０１、１１０２が同時に表示されている。この場合、振分モジュール３４０は、最前面に表示されたアプリケーション（最前面アプリ）という要素だけでは、どのコンテンツをデバック対象としてＪａｖａＳｃｒｉｐｔを転送（挿入）すべきかを決定できない。
【００６１】
このような場合には、最後にユーザーが操作したコンテンツをブラウザエンジン３３０からの通知を元に、振分モジュール３４０が記憶しておく。その操作履歴の情報に基づき、振分モジュール３４０は、最前面に表示されたアプリケーションにおいてユーザーが最後に操作したコンテンツに対して、挿入ＪａｖａＳｃｒｉｐｔを転送する。
【００６２】
図９（ｂ）に、複数コンテンツの表示に対応した場合の保存情報のテーブルの構成例を示す。テーブル９１０は、振分モジュール３４０の記憶部３４２に保持される。テーブル９１０は、図９（ａ）に示したテーブル９００と比較すると、エンジン利用アプリ識別子９１１および最前面アプリ識別子９１２に加え、モジュールＩＤ９１３と最終利用モジュールＩＤ９１４を有する。モジュールＩＤ９１３は、同じエンジン利用アプリ３２０で、複数のコンテンツが表示される場合に、それぞれを識別するために付与されるＩＤ（識別情報）である。これは、ブラウザエンジン３３０から、エンジン利用アプリ３２０の識別子が通知される際に、一緒に通知される。また、最終利用モジュールＩＤ９１４は、エンジン利用アプリ３２０で最後にユーザーが利用した（操作した）コンテンツのモジュールＩＤを示す。これは、ユーザーがエンジン利用アプリ３２０上で表示コンテンツを操作した際に、ブラウザエンジン３３０を通じて通知される。
【００６３】
振分モジュール３４０は、図９（ｂ）に示すような情報を用いて、最前面に表示されたアプリケーションの画面においてユーザーが最後に操作したコンテンツを判定し、デバッグ指示を送信する。図９（ｂ）の例であれば、アプリケーションの識別子が「Ａｐｐｌｉｃａｉｏｎ＿ＩＤ＿１」であって、モジュールＩＤが「００１」のコンテンツに対して、振分モジュール３４０は、挿入ＪａｖａＳｃｒｉｐｔを挿入すると決定する。
【００６４】
この構成により、１の画面にて複数のコンテンツが表示されている場合であっても、ユーザーの操作に応じてデバッグ機能の対象とするコンテンツを切り替えることが可能となる。
【００６５】
更に他の実施形態について説明する。第一の実施形態にて述べたデバッグ機能を実行した際に表示される追加コンテンツ７０２は、デバッグ対象のコンテンツ（図７の場合はオリジナルコンテンツ７０１）に対して埋め込まれる。そのため、追加コンテンツ７０２は、表示された際に、画面７００における表示領域を大きく占有してしまう。特に、エンジン利用アプリ３２０において、Ｗｅｂコンテンツの表示領域以外の領域（ツールバー、アドレスバー、その他の機能ボタン）が存在し、コンテンツの表示がＵＩ表示装置２０５の一部に限られてしまうと、追加コンテンツ７０２の視認性が低下する。
【００６６】
図１１（ｂ）は、ＷｅｂＶｉｅｗを画面の一部で利用する画面１１１０の表示例である。表示領域１１１１は、ＷｅｂＶｉｅｗを利用する領域であるとする。デバック機能を実行した結果、表示領域１１１１の中に、デバッグ情報表示領域１１１２が存在する。この場合、表示領域１１１１のサイズが小さいとその表示内容の一部が見切れてしまうことがある。このように、表示領域が小さい状態の場合、一時的に画面１１１０を全画面のサイズに拡張するようにしてもよい。具体的には、図４のＳ４１１でＷｅｂアプリケーション３１０が提供するデバッグ機能のＪａｖａＳｃｒｉｐｔに、画面の表示サイズを変更するコードを埋め込んでおくようにしてもよい。もしくは、ＪａｖａＳｃｒｉｐｔに、デバッグ機能の対象となるコンテンツの表示内容もしくはデバッグ結果に応じて表示領域のサイズを変更できるようなコードが含まれていてもよい。
【００６７】
この構成により、デバッグ機能の実行結果の視認性を向上させつつ、ユーザーによる画面のサイズ変更等の手間を削減することが可能となる。
【００６８】
更に他の実施形態について説明する。追加コンテンツ７０２は、デバッグ対象のコンテンツ（図７の場合は、オリジナルコンテンツ７０１）に埋め込まれる。そのため、表示されているコンテンツが変更された場合に（ＵＲＬの変更、画面の遷移など）、追加コンテンツ７０２は、表示から消えてしまう。そこで、振分モジュール３４０は、挿入ＪａｖａＳｃｒｉｐｔの挿入をリクエストした際に、その挿入ＪａｖａＳｃｒｉｐｔを保持しておく。その後、コンテンツの変更をブラウザエンジン３３０が検知した際に、ブラウザエンジン３３０は振分モジュール３４０に通知を行い、この通知に基づいて、振分モジュール３４０が再度、挿入ＪａｖａＳｃｒｉｐｔの挿入を行ってもよい。
【００６９】
この構成により、コンテンツが変更された場合でも、継続して追加コンテンツ７０２が表示され、利便性が向上する。
【００７０】
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００７１】
１０１：ＭＦＰ、１０２：情報処理装置、３１０：Ｗｅｂアプリケーション、３２０：エンジン利用アプリ、３３０：ブラウザエンジン、３４０：振分モジュール、３５０：ウィンドウ制御モジュール 
【図１】
2017097661.tif 000003
【図２】
2017097661.tif 000004
【図３】
2017097661.tif 000005
【図４】
2017097661.tif 000006
【図５】
2017097661.tif 000007
【図６】
2017097661.tif 000008
【図７】
2017097661.tif 000009
【図８】
2017097661.tif 000010
【図９】
2017097661.tif 000011
【図１０】
2017097661.tif 000012
【図１１】
2017097661.tif 000013