JP6270576B2

JP6270576B2 - 情報処理装置、その制御方法、及びプログラム

Info

Publication number: JP6270576B2
Application number: JP2014060796A
Authority: JP
Inventors: 黒田　茂樹; 茂樹黒田
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2014-03-24
Filing date: 2014-03-24
Publication date: 2018-01-31
Anticipated expiration: 2034-03-24
Also published as: JP2015184916A; US20150269266A1; CN104954611A; CN104954611B; US11036819B2

Description

本発明は、ＷＥＢブラウザによって操作されるアプリケーション間の画面の遷移を制御する情報処理装置、その制御方法、及びプログラムに関する。

Ｗｅｂブラウザで操作可能なＷｅｂサーバーが提供するＷｅｂアプリケーションでは、他のＷｅｂアプリケーションの画面にリンクを張り、所定の操作等に応じて別のアプリケーションの画面に遷移することが可能なアプリケーションが存在する。アプリケーションから他のアプリケーションの画面に遷移する際は、該当する画面上のメニューで遷移先画面のＵＲＬを直接指定することができる。また、他のアプリケーション画面に遷移した後、遷移元のアプリケーション画面に戻るメニューを備えるアプリケーションが存在し、例えば、遷移先のアプリケーションのメニューで、戻るべき遷移元の画面のＵＲＬを直接指定する方法が知られている。

特許文献１では、ユーザーがＷｅｂブラウザを遷移させて処理を実行する場合に、Ｗｅｂ画面ごとにユーザーが行った処理を特定する情報及び画面表示に必要となる属性情報等を遷移情報として蓄積し、当該遷移情報を用いて画面遷移を行う方法が開示されている。具体的には、過去のＷｅｂ画面がユーザーによって選択されて表示が求められた場合に、選択された画面の識別子を取得し、この識別子を用いてＷｅｂ画面の属性情報を取得し、選択されたＷｅｂ画面を表示している。

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

しかしながら、上記従来技術には以下に記載する問題がある。例えば、遷移元の選択肢となる画面が複数存在し、それぞれの画面から一つの遷移先に画面遷移する場合、当該遷移先画面のメニュー等にＵＲＬを直接指定していると戻り先が固定されてしまう。そのため、ユーザーの意図した遷移元の画面に戻らない場合があり、ユーザーの利便性を損なうという問題がある。

また、予め戻り先として、遷移元へ戻るためのＵＲＬを直接定義してしまうと、遷移元の画面又はメニュー構成に変更があった場合には、お互いのアプリケーションを修正する必要があり、プログラムの保守性に問題がある。また、他のアプリケーションにリンクを張り遷移した後、遷移元のアプリケーションに戻る際、リンク先のＵＲＬを直接指定すると、ＵＲＬを知られてしまい攻撃の対象になるなどセキュリティ上の問題がある。また、直接指定したリンク先のＵＲＬを、遷移先以外のアプリケーションから直接指定されると、遷移元のアプリケーションの画面が直接の攻撃の対象となる可能性があり、セキュリティ上の問題となる。

本発明は、上述の問題に鑑みて成されたものであり、画面遷移の際に遷移元に複数の画面が存在する場合であっても、それぞれにおいて、好適に遷移先の画面からユーザーが意図する遷移元の画面へ戻るとともに、メンテナンスが容易で、遷移元の画面への攻撃の脅威を軽減する仕組みを提供することを目的とする。

本発明は、外部装置のＷｅｂブラウザから利用可能な第１のＷｅｂアプリケーションと前記第１のＷｅｂアプリケーションとは異なる第２のＷｅｂアプリケーションを少なくとも有する情報処理装置であって、外部装置で動作するＷｅｂブラウザに、前記第１のＷｅｂアプリケーションの画面を表示するための画面データを送信する第１の送信手段と、前記第１のＷｅｂアプリケーションの画面から前記第２のＷｅｂアプリケーションの画面に遷移するための画面遷移を引き起こす指示に応じて、前記第２のＷｅｂアプリケーションの画面を要求する指示を前記外部装置から受信する第１の受信手段と、前記第２のＷｅｂアプリケーションの画面を要求する指示を受信した場合に、前記第２のＷｅｂアプリケーションの画面を表示するための画面データとともに、前記Ｗｅｂブラウザに提供されていた前記第１のＷｅｂアプリケーションの画面を識別する識別情報を前記外部装置の前記Ｗｅｂブラウザに送信する第２の送信手段と、前記第２のＷｅｂアプリケーションの画面から前記第１のＷｅｂアプリケーションの提供する画面に遷移するための画面遷移を引き起こす指示に応じて、前記第１のＷｅｂアプリケーションの画面を識別する識別情報に対応する情報を前記外部装置のＷｅｂブラウザから受信した場合に、前記受信した識別情報に対応する情報に基づいて前記第１のＷｅｂアプリケーションが提供する遷移先の画面を決定する決定手段と、を有することを特徴とする。

本発明によれば、画面遷移の際に遷移元に複数の画面が存在する場合であっても、それぞれにおいて、好適に遷移先の画面からユーザーが意図する遷移元の画面へ戻るとともに、メンテナンスが容易で、遷移元の画面への攻撃の脅威を軽減することができる。

第１の実施形態に係る情報処理システムの全体図。第１の実施形態に係るＭＦＰ１０１をハードウェア構成を示すブロック図。第１の実施形態に係る情報処理システムの制御構成を示す図。第１の実施形態に係るＷｅｂサーバー部３０１のアプリケーションの情報処理システムのソフトウェア構成を示す図。第１の実施形態に係る情報処理システムの動作を説明するシーケンス図。第１の実施形態に係るアプリケーション３１１の画面遷移時の動作を説明するフローチャート。第１の実施形態に係るアプリケーション３１１の画面遷移後の動作を説明するフローチャート。第１の実施形態に係るアプリケーション３１２の動作を説明するフローチャート。第１の実施形態に係るパラメータデータ４１４として保存されたデータの内容を模試したデータテーブルを示す図。第１の実施形態に係るパラメータデータ４１４として保存されたデータの内容を模試したデータテーブルを示す図。第２の実施形態に係る情報処理システムの動作を説明するシーケンス図。

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

＜第１の実施形態＞
＜情報処理システム＞
以下では、図１乃至図１０を参照して、本発明の第１の実施形態について説明する。まず、図１を参照して、本実施形態に係る情報処理装置を含む情報処理システム１００の全体構成について説明する。情報処理システム１００は、ＭＦＰ１０１、ＭＦＰ１０６、外部ＷＥＢサーバー１０４、及びクライアント端末（外部装置）１０５を含む。これらの装置は、ＬＡＮ（ローカルエリアネットワーク）１０２やインターネット１０３によって構成されたネットワークを介して接続されている。

また、クライアント端末１０５は、外部のＷｅｂサービスに接続し、Ｗｅｂアプリケーションを操作可能なＷｅｂブラウザ機能を備える。ＭＦＰ１０１及びＭＦＰ１０６は、紙媒体をスキャンし、そのスキャンデータを元に用紙に画像を形成して印刷するコピー機能を有する。さらには、これらのＭＦＰは、クライアント端末からアクセスし操作可能なアプリケーションを提供可能なＷｅｂサイト機能を有するＷｅｂサーバー部を備える。外部Ｗｅｂサーバー１０４も同様に、クライアント端末１０５からアクセスし操作可能なアプリケーションを提供可能なＷｅｂサイト機能を有するＷｅｂサーバー部を備える。

＜ＭＦＰの構成＞
次に、図２を参照して、ＭＦＰ１０１の構成について説明する。ＭＦＰ１０６も以下で説明するＭＦＰ１０１と同様の構成であるため、説明を省略する。ＭＦＰ１０１は、スキャナ２１３及びプリンタ２１４を接続するとともに、操作表示部２１１、操作入力部２１２、及びＬＡＮ１０２を接続することが可能なコントローラユニット２００を備える。コントローラユニット２００は、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ＨＤＤ２０４、操作部出力Ｉ／Ｆ２０５、操作部入力Ｉ／Ｆ２０６、ネットワークＩ／Ｆ２０７、スキャナＩ／Ｆ２０８、及びプリンタＩ／Ｆ２０９を備える。各種制御プログラムを実行するＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）２０１を有する。ＣＰＵ２０１は、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）２０３に格納されているブートプログラムに基づきシステムを起動する。さらに、ＣＰＵ２０１は、ＨＤＤ（ハードディスクドライブ）２０４に格納されている制御プログラムを読み出してＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）２０２をワークエリアとして所定の処理を実行する。ＨＤＤ２０４には、ＷＥＢブラウザ４０２の機能を含む、各種制御プログラムが格納される。また、ＨＤＤ２０４には、スキャナ２１３から読み込んだスキャンデータやネットワークＩ／Ｆ２０７を介して装置外から取得したデータが格納される。

操作部出力Ｉ／Ｆ２０５は、操作表示部２１１へのデータ出力通信制御を行う。操作部入力Ｉ／Ｆ２０６は、操作入力部２１２からのデータ入力通信制御を行う。ネットワークＩ／Ｆ２０７は、ＬＡＮ１０２に接続され、ＬＡＮ１０２を介した情報の入出力制御を行う。スキャナＩ／Ｆ２０８は、スキャナ２１３から画像データを入力するとともに、スキャナ制御データの入出力を行う。プリンタＩ／Ｆ２０９は、プリンタ２１４へ出力画像データを出力するとともに、プリンタ制御データの入出力を行う。このように、各コンポーネント２０１〜２０９はシステムバス２１０上に配置される。

操作入力部２１２は、タッチパネルやハードキーなどの入力装置を備えた、ユーザーからの指示入力インターフェースである。操作表示部２１１は、ＬＣＤ（ＬｉｑｕｉｄＣｒｙｓｔａｌＤｉｓｐｌａｙ）やＬＥＤ（ＬｉｇｈｔＥｍｉｔｔｉｎｇＤｉｏｄｅ）などの表示装置を備えた、ユーザーへの表示インターフェースである。

スキャナ２１３は、ＣＣＤ（ＣｈａｒｇｅＣｏｕｐｌｅｄＤｅｖｉｃｅ）などの光学的な読み取り装置を備え、紙媒体を光学的に操作して、電子的な画像データとして読み取る機能を有する。プリンタ２１４は、電子的な画像データを、用紙などの記録媒体上に画像として形成する機能を有する。

＜制御構成＞
次に、図３を参照して、ＭＦＰ１０１を例とした画像処理装置（情報処理装置）を含むシステム全体の制御構成について説明する。図３に示す各機能部は、ＭＦＰ１０１内のＣＰＵ２０１が、ＲＯＭ２０３又はＨＤＤ２０４に格納された制御プログラムをＲＡＭ２０２に読み出して実行することにより実現される。ここで、図１で説明したＭＦＰ１０６の構成はＭＦＰ１０１の構成と同様であるため、ここではＭＦＰ１０１について説明し、ＭＦＰ１０６の説明は割愛する。また、外部Ｗｅｂサーバー１０４においても同様の制御構成とすることができるので、外部Ｗｅｂサーバー１０４の説明も割愛する。つまり、以下で説明するＭＦＰ１０１の構成は、外部Ｗｅｂサーバー１０４において実現してもよい。この場合、クライアント端末１０５へ提供するＭＦＰ１０１のサービス（機能）を提供するＷｅｂアプリケーションを外部Ｗｅｂサーバー１０４で管理する。

ＭＦＰ１０１は、制御構成として、Ｗｅｂサーバー部３０１と前述のネットワークＩ／Ｆ２０７を有する。ネットワークＩ／Ｆ２０７は、外部のクライアント端末１０５へＷｅｂサービスを提供するために通信を行う。また、外部のＷｅｂサービスを利用するために、外部Ｗｅｂサーバー１０４や、さらにＭＦＰ１０６とも通信を行う。

外部のクライアント端末１０５は、Ｗｅｂサービスの提供を受けるためにＷｅｂブラウザ１５０を有する。具体的には、Ｗｅｂサービスを提供するＷｅｂサーバー部３０１にリクエストメッセージを送信するとともに、Ｗｅｂサーバー部３０１から送信されるレスポンスメッセージを受信しＷｅｂブラウザ１５０に画面を表示する。ここでＷｅｂサービスはＷｅｂサーバー部３０１の複数のアプリケーションプログラムという形で提供される。クライアント端末１０５のＷｅｂブラウザ１５０では、これらのアプリケーションのＷｅｂサービスを利用し、Ｗｅｂサーバーを有するＭＦＰ１０１の操作を行ったりすることも可能である。

次に、Ｗｅｂサーバー部３０１の構成について説明する。Ｗｅｂサーバー部３０１は、Ｗｅｂサービス処理部３１０、アプリケーション３１１、３１２、３１３を備える。なお、アプリケーション３１１は第１アプリケーションに対応し、アプリケーション３１２は第２アプリケーションに対応する。Ｗｅｂサービス処理部３１０は、クライアントであるＷｅｂブラウザ１５０からのリクエストメッセージを受け付け、リクエストメッセージに従って、どのＷｅｂアプリケーションのサービスと通信するかを決定する、ＨＴＴＰサービスとしての機能を有する。具体的には、Ｗｅｂサービス処理部３１０は、リクエストメッセージとしてＵＲＬを受け付け、ＵＲＬを解析し、ＵＲＬに従って予め登録されている１つ以上のＷｅｂアプリケーションのうち、どのＵＲＬへのリクエストかを判断する。そしてリクエストに従って該当のＷｅｂアプリケーションをリクエストとともに呼び出す。前述のリクエストメッセージは、具体的にはＨＴＴＰのリクエストメッセージであり、ＵＲＬに紐づいたＷｅｂブラウザからのパラメータの値も含むことができる。

アプリケーション３１１、３１２、３１３は、Ｗｅｂサービスを提供するＷｅｂアプリケーションであり、それぞれ個別のプログラム構成となっている。各アプリケーションは、事前にＷｅｂサービス処理部３１０に登録することで、Ｗｅｂサービス処理部３１０での指示を受け、Ｗｅｂブラウザ１５０と通信し、クライアント端末１０５にＷｅｂサービスを提供することが可能である。

＜アプリケーションの構成＞
次に、図４を参照して、図３におけるアプリケーション３１１の構成について説明する。なお、図３で説明したアプリケーション３１２、３１３は、アプリケーション３１１の構成と同様であるため、説明を割愛する。

アプリケーション３１１は、ＣＧＩ処理部４１０、認証処理部４１１、画面生成部４１２、パラメータ処理部４１３、パラメータデータ４１４、及びデバイス処理部４１５を備える。ＣＧＩ処理部４１０は、前述のＷｅｂサービス処理部３１０から呼び出され、Ｗｅｂサービス処理部３１０からのリクエストメッセージを受け付ける。その後、ＣＧＩ処理部４１０は、アプリケーション３１１でＷｅｂサービスを提供すべく処理を実行し、その結果をＷｅｂサービス処理部３１０に送信する。また、ＣＧＩ処理部４１０は、Ｗｅｂサービスを提供するために、前述のリクエストメッセージに基づいて、後述する認証処理、パラメータ処理、画面生成処理、及びデバイス制御処理等を実行する。

認証処理部４１１は、ＣＧＩ処理部４１０から呼び出され、リクエストメッセージが有効か否かの判断や、改めて認証を要求するなどのセッションの処理や認証処理を実行する。具体的には、認証処理部４１１は、リクエストメッセージのＵＲＬ、パラメータ、ＨＴＴＰのヘッダやリクエスト又はＣｏｏｋｉｅを解析する。さらに、認証処理部４１１は、リクエストの認証期限やセッションが期限内かどうか、改めて認証処理が必要か否かなどを判断し、その結果をＣＧＩ処理部４１０に通知する。

画面生成部４１２は、ＣＧＩ処理部４１０から呼び出され、Ｗｅｂサービスを提供すべく画面生成処理を行う。具体的には、画面生成部４１２は、ＣＧＩ処理部４１０で処理された各結果に基づいて、テンプレートのＨＴＭＬファイルから、サービスに必要なＨＴＭＬの画面を生成する。ここでの画面は、アプリケーション３１１の他のＷｅｂサービスを受けるべく配置されたメニューボタンを含んでいる。さらに、当該画面には、他のＷｅｂアプリケーション、例えばアプリケーション３１２を呼び出すためのメニューボタンが含まれてもよい。

パラメータ処理部４１３は、ＣＧＩ処理部４１０から呼び出され、前述のリクエストメッセージ中のパラメータを解析し、必要な処理を判断し、その結果をＣＧＩ処理部４１０に通知する。また、パラメータ処理部４１３は、ＣＧＩ処理部４１０からのリクエストに応じて、必要なパラメータを生成し、そのパラメータをＣＧＩ処理部４１０に送付する。また、パラメータ処理部４１３は、当該リクエスト中のパラメータや、生成したパラメータをパラメータデータ４１４としてＲＡＭ２０２又はＨＤＤ２０４に保存することが可能である。また、パラメータ処理部４１３は、必要に応じで保存されたパラメータデータ４１４を呼び出すことも可能である。パラメータデータ４１４は、具体的には、当該リクエストメッセージ中のパラメータとして、画面に紐づく情報を生成したり、記憶したりする。ＣＧＩ処理部４１０は、パラメータ処理部４１３の結果に基づいて、前述の認証処理を認証処理部４１１に実行させたり、必要な画面を画面生成部４１２に指示し処理することが可能である。

デバイス処理部４１５は、ＣＧＩ処理部４１０から呼び出され、指示に基づきＭＦＰ１０１の設定値の更新、参照、及び実際のＭＦＰ１０１を動作させるなどの処理を行う。また、参照された設定値及びＭＦＰ１０１の動作結果等をＣＧＩ処理部４１０に通知する。例えば、アプリケーションプログラムとしてＭＦＰ１０１の設定を参照、更新したり、ＭＦＰ１０１のスキャナ２１３又はプリンタ２１４を動作させるアプリケーションプログラムが存在する。これらのアプリケーションは、提供する画面に、情報表示や設定メニューを表示する。また、ＭＦＰ１０１の各機能を動作させるためのメニューを表示し、ユーザーの指示を受け付ける。その場合、前述のアプリケーションプログラムは、デバイス処理部４１５を利用しＭＦＰ１０１が有する機能を動作させることが可能となる。

ここで各アプリケーションである、アプリケーション３１１、３１２、３１３は、事前にＷｅｂサーバー部３０１に登録されているアプリケーションプログラムでもよい。或いは、後からＷｅｂサーバー部３０１に追加インストールされるアプリケーションプログラムでもよい。その場合、インストールサービスプログラムがＷｅｂサーバー部３０１に登録された状態で、アプリケーションプログラムの追加インストール処理を実行することができる。追加インストールされたアプリケーションプログラムは、前述のインストールサービスプログラムによってＷｅｂサービス処理部３１０に登録され、同様のＷｅｂサービスを提供することが可能となる。

＜画面遷移の処理シーケンス＞
次に、図５は、本実施形態におけるアプリケーション３１１、３１２の画面遷移の処理シーケンスについて説明する。図５のシーケンス図に示す各動作は、ＭＦＰ１０１のＣＰＵ２０１が制御プログラムを実行することにより実現される。ここでは、ユーザーがアプリケーション３１１のＷｅｂサービスを受けるべく指示した例を説明する。

Ｓ５０１において、ユーザーは、必要なＷｅｂアプリケーションのサービスを受けるべく、Ｗｅｂブラウザ１５０に表示された画面中のメニュー等をクリックしユーザー指示を行う。Ｗｅｂブラウザ５０１は、当該ユーザー指示を画面遷移指示として受け取る。続いて、Ｓ５０２において、Ｗｅｂブラウザ１５０は、リクエストメッセージとして、受け取った画面遷移指示をＷｅｂサービス処理部３１０に送信する。Ｓ５０３において、Ｗｅｂサービス処理部３１０は、リクエストメッセージを解析し、アプリケーション３１１を呼び出すべく、アプリケーション３１１に画面遷移指示を行う。

Ｓ５０４において、アプリケーション３１１は、リクエストメッセージに応じた画面データを生成し、Ｓ５０５において、生成した画面データをＷｅｂサービス処理部３１０に送信する。Ｓ５０６において、Ｗｅｂサービス処理部３１０は、Ｓ５０４でアプリケーション３１１から受け取った画面データを、ＷｅｂブラウザＳ５０５へ送信する。これによって当該ユーザーは、指示したアプリケーション３１１のＷｅｂサービスを受けることができる。

Ｓ５０７において、ユーザーは、受け取った画面から新たなサービスを受けるべく、Ｗｅｂブラウザ５０６に対してユーザー指示を行う。具体的には、ユーザーはＷｅｂブラウザ１５０に表示された画面中のメニューボタン等をクリックすることで、ユーザー指示を行う。Ｗｅｂブラウザ１５０は、当該ユーザー指示を画面遷移指示として受け取る。ここでは、Ｗｅｂブラウザ１５０に表示された画面のメニューボタンのうちアプリケーション３１２のＷｅｂサービスを受けるためのメニューボタンがクリックされた例を説明する。Ｓ５０８において、Ｗｅｂブラウザ１５０は、前述のＳ５０６におけるユーザー指示に従い、Ｗｅｂサービス処理部３１０にリクエストメッセージとして画面遷移指示を送信する。

Ｓ５０９において、Ｗｅｂサービス処理部３１０は、アプリケーション３１１に画面遷移指示を行う。Ｓ５１０において、アプリケーション３１１は、リクエストされた画面遷移がアプリケーション３１２のメニューであるため、アプリケーション３１２の画面にリダイレクトすべく、対応するＵＲＬを生成する。さらに、アプリケーション３１１は、画面ＩＤを生成し、ＵＲＬのパラメータとして付加し、遷移先情報を生成する。遷移先情報とは、例えば当該画面遷移指示によって遷移するアプリケーション３１２の画面からの戻り先画面を示す情報である。ここでのパラメータ処理は、前述の図４のパラメータ処理部４１３で行われる。ここで、生成したパラメータを前述のパラメータデータ４１４として記憶する。続いて、Ｓ５１１において、アプリケーション３１１は、生成した遷移先情報を画面のリダイレクト処理としてＷｅｂサービス処理部３１０に送信する。

Ｓ５１２において、Ｗｅｂサービス処理部３１０は、遷移先情報を一度Ｗｅｂブラウザ１５０に送信する。Ｓ５１３において、Ｗｅｂブラウザ１５０は、受け付けたリクエストがリダイレクトであるため、ＵＲＬと画面ＩＤで構成された遷移先情報を参照し、当該遷移先情報に基づいて、画面遷移指示をＷｅｂサービス処理部３１０に送信する。Ｓ５１４において、Ｗｅｂサービス処理部３１０は、送信されたリクエストメッセージ中のＵＲＬがアプリケーション３１２のメニューであるため、アプリケーション３１２に画面遷移指示を行うべく、アプリケーション３１２を呼び出す。その際、画面遷移指示のリクエストには、Ｓ５０９で生成された画面ＩＤの情報を含むことが可能である。

Ｓ５１５において、アプリケーション３１２は、Ｓ５１３でＷｅｂサービス処理部３１０から受け付けた画面ＩＤ（識別子）を記憶する。画面ＩＤの記憶は、アプリケーション３１２が管理するＲＡＭ２０２又はＨＤＤ２０４の記憶領域に保存することが可能である。さらに、アプリケーション３１２は、リクエストメッセージに応じた画面データを生成する。Ｓ５１６において、アプリケーション３１２は、生成した画面データをＷｅｂサービス処理部３１０に送信する。Ｓ５１７において、Ｗｅｂサービス処理部３１０は、アプリケーション３１２から受信したＷｅｂブラウザ１５０に画面データを送信する。これにより、ユーザーは、Ｗｅｂブラウザ１５０より、アプリケーション３１２のＷｅｂサービスが受けられる。

次に、ユーザーがアプリケーション３１２の画面から、遷移元であるアプリケーション３１１の画面に戻るための画面遷移指示を行う場合のフローを説明する。Ｓ５１８において、ユーザーは、元のアプリケーション３１１に戻るべく、Ｗｅｂブラウザ１５０に表示された画面中の、戻るためのメニューをクリックするなどして、ユーザー指示を行う。Ｗｅｂブラウザは、当該ユーザー指示を、画面遷移指示として受け付ける。

Ｓ５１９において、Ｗｅｂブラウザ１５０は、画面遷移指示をＷｅｂサービス処理部３１０に送信する。Ｓ５２０において、Ｗｅｂサービス処理部３１０は、同様に画面遷移指示をアプリケーション３１２へ送信し、画面遷移指示をすべくアプリケーション３１２を呼び出す。Ｓ５２１において、アプリケーション３１２は、前述のＳ５１４で記憶領域に記憶した画面ＩＤを参照し、遷移元（戻り先）であるアプリケーション３１１のテンポラリのＵＲＬ（仮のＵＲＬ：仮想画面）を設定し、画面ＩＤをパラメータとして、遷移先情報を生成する。Ｓ５２２において、アプリケーション３１２は、設定したテンポラリのＵＲＬにリダイレクトさせるべく、遷移先情報をＷｅｂサービス処理部３１０に送信する。

Ｓ５２３において、Ｗｅｂサービス処理部３１０は、遷移先情報を一度Ｗｅｂブラウザ１５０に送信する。Ｓ５２４において、Ｗｅｂブラウザ１５０は、受け付けたリクエストがリダイレクトであるため、ＵＲＬと画面ＩＤで構成された遷移先情報を参照し、画面遷移指示をＷｅｂサービス処理部３１０に送信する。Ｓ５２５において、Ｗｅｂサービス処理部３１０は、送信されたリクエストメッセージ中のＵＲＬがアプリケーション３１１のメニューであるため、アプリケーション３１１に画面遷移指示を行うべく、アプリケーション３１１を呼び出す。その際、画面遷移指示のリクエストには、Ｓ５０９で生成され、Ｓ５２１でアプリケーション３１２で設定された画面ＩＤの情報をパラメータとして含んでいる。

Ｓ５２６において、アプリケーション３１１は、ＵＲＬの内容とパラメータを解析する。具体的には、ＵＲＬが予め定義されたテンポラリのＵＲＬであれば、前述のＳ５１９で生成し記憶したパラメータデータ４１４を参照し、指定されたパラメータがどの画面に割り当てられているかを判断する。そして指定されたパラメータと一致したパラメータデータに紐づけられた画面を判断し、新たなＵＲＬを含む遷移先情報を生成する。Ｓ５２７において、アプリケーション３１１は、生成した遷移先情報を画面のリダイレクト処理としてＷｅｂサービス処理部３１０に送信する。Ｓ５２８において、Ｗｅｂサービス処理部３１０は、遷移先情報を一度Ｗｅｂブラウザ１５０に送信する。

Ｓ５２９において、Ｗｅｂブラウザ１５０は、受け付けたリクエストがリダイレクトであるため、ＵＲＬと画面ＩＤで構成された該遷移先情報を参照し、画面遷移指示をＷｅｂサービス処理部３１０に送信する。Ｓ５３０において、Ｗｅｂサービス処理部３１０は、送信されたリクエストメッセージ中のＵＲＬがアプリケーション３１１のメニューであるため、アプリケーション３１１に画面遷移指示を行うべく、アプリケーション３１１を呼び出す。

Ｓ５３１において、アプリケーション３１１は、セッション処理を実行する。ここでのセッション処理は前述の図４の認証処理部４１１で行われる。また、ここでセッション処理だけでなく認証処理を実行することも可能である。その場合の認証処理も前述の図４の認証処理部４１１で行われることとなる。

Ｓ５３２において、アプリケーション３１１は、ＵＲＬ情報を含むリクエストメッセージに基づき、遷移元の画面データを生成する。ここでの画面生成処理は、前述の図４の画面生成部４１２で行われる。Ｓ５３３において、アプリケーション３１１は、生成した画面データをＷｅｂサービス処理部３１０に送信する。Ｓ５３４において、Ｗｅｂサービス処理部３１０は、受信した画像データをＷｅｂブラウザ１５０に送信する。

＜処理フロー＞
以下では、図６乃至図８を参照して、アプリケーション３１１、３１２の画面遷移時における処理フローについて説明する。まず、図６を参照して、アプリケーション３１１の画面遷移時における処理手順を説明する。ここでは、前述の図５のＳ５０１乃至Ｓ５１６におけるアプリケーション３１１の動作を補足しながら説明する。

Ｓ６０１において、アプリケーション３１１は、Ｗｅｂサービス処理部３１０から受けたリクエストメッセージの指示内容を解析する。この処理はＣＧＩ処理部４１０で行われる。具体的には、リクエストメッセージのＵＲＬから、どのメニューに対するリクエストなのかを解析する。

Ｓ６０２において、アプリケーション３１１は、解析結果に基づき、リクエストがアプリケーションの画面遷移であるか否かを判断する。アプリケーション画面遷移としてのリクエストメッセージは、予め定義することが可能なので、ここでは当該リクエストメッセージが予め定義されたアプリケーション画面への遷移か否かを判断してもよい。Ｓ６０２でアプリケーション画面遷移でないと判断された場合はＳ６０４に進み、アプリケーション３１１は、通常のアプリケーション３１１の動作や画面生成等の通常処理を実行し、処理を終了する。なお、画面生成等の通常処理は、前述の図５のＳ５０４に該当する。

一方、Ｓ６０２でアプリケーション画面遷移と判断された場合は、Ｓ６０３に進み、アプリケーション３１１は、該当のアプリケーションへ画面遷移するための遷移先情報を生成する。ここでの遷移先情報とは、具体的にはアプリケーション３１２への画面遷移のためのＵＲＬと、そのパラメータである画面ＩＤとを含む。続いて、Ｓ６０５において、アプリケーション３１１は、生成したＵＲＬと画面ＩＤとを関連付けてパラメータデータ４１４としてテーブルに記憶する。これらＳ６０３とＳ６０５の処理は前述の図５のＳ５１０に該当する。Ｓ６０６において、アプリケーション３１１は、生成した画面データをＷｅｂサービス処理部３１０に送信し、処理を終了する。このＳ６０６の処理は前述の図５のＳ５１１に該当する。

次に、図７を参照して、アプリケーション３１１の遷移元へ戻る際の画面遷移時の処理手順を説明する。ここでは、前述の図５のＳ５２４乃至Ｓ５３４におけるアプリケーション３１１の動作を補足しながら説明する。

Ｓ７０１において、アプリケーション３１１は、Ｗｅｂサービス処理部３１０から受けたリクエストメッセージの指示内容を解析する。この処理はＣＧＩ処理部４１０で行われる。具体的にはリクエストメッセージのＵＲＬからどのメニューに対するリクエストなのかを解析する。

Ｓ７０２において、アプリケーション３１１は、解析結果に基づき、ＵＲＬがテンポラリのＵＲＬか否かを判断する。テンポラリのＵＲＬは予め定義することが可能なので、ここでは当該リクエストメッセージ中のＵＲＬが予め定義されたテンポラリのＵＲＬか否かを判断する。Ｓ７０２でＵＲＬがテンポラリのＵＲＬと判断された場合は、Ｓ７０３に進み、アプリケーション３１１は、当該リクエストメッセージのパラメータを確認すべく、パラメータデータ４１４に格納されたパラメータテーブルを参照し、Ｓ７０４に進む。

Ｓ７０４において、アプリケーション３１１は、当該リクエストメッセージのパラメータデータが、パラメータテーブルに登録されているか否かを判断する。ここで、パラメータデータとは、画面ＩＤのことである。つまり、アプリケーション３１１は、画面ＩＤを検索キーとして、該当するデータをパラメータテーブルから検索する。さらに、前述の図６のＳ６０５で画面ＩＤと遷移先の画面のＵＲＬは関連付けられてパラメータデータ４１４にテーブルとして登録されている。したがって、アプリケーション３１１は、画面ＩＤより遷移先の画面のＵＲＬを特定することが可能である。ここで、パラメータデータとしての画面ＩＤは、予め定義しておくことも可能である。

Ｓ７０４でリクエストメッセージのパラメータがパラメータデータ４１４としてテーブルに登録されている場合は、戻り先画面が特定できたものとし、Ｓ７０５へ進む。Ｓ７０５において、アプリケーション３１１は、遷移先画面をＵＲＬに設定しリダイレクトの処理をすべく遷移先情報を生成する。これらＳ７０２乃至Ｓ７０５の処理は前述の図５のＳ５２６に該当する。続いて、Ｓ７０６に進み、アプリケーション３１１は、生成した遷移先情報をＷｅｂサービス処理部３１０に送信し、処理を終了する。このＳ７０６の処理は、前述の図５のＳ５２７に該当する。

Ｓ７０４でリクエストメッセージのパラメータがパラメータデータ４１４としてテーブルに登録されていない場合は、エラー処理を実行すべくＳ７０７へ進む。Ｓ７０７において、アプリケーション３１１は、該当する画面がないなどを示すエラー画面の画面データを生成する。続いて、Ｓ７０８に進み、アプリケーション３１１は、エラー画面データをＷｅｂサービス処理部３１０に送信し、処理を終了する。

一方、Ｓ７０２でＵＲＬがテンポラリのＵＲＬでないと判断された場合はＳ７１０に進み、アプリケーション３１１は、セッションを解析する。具体的には、アプリケーション３１１は、リクエストメッセージのＵＲＬ、パラメータ、ＨＴＴＰのヘッダやリクエスト又はＣｏｏｋｉｅを解析し、セッション情報を取得する。続いて、Ｓ７１１に進み、アプリケーション３１１は、当該セッション情報が有効期限内か否かなど、セッションの有効性を判断する。

Ｓ７１０のセッション解析及びＳ７１１のセッション判断は図４の認証処理部４１１で行われる。また、ステップＳ７１０及びＳ７１１の処理は、前述の図５のＳ５３１に該当する。Ｓ７１１でセッションが有効と判断された場合はＳ７１２に進み、アプリケーション３１１は、該当する画面の画面データを生成する。続いて、Ｓ７１３に進み、アプリケーション３１１は、生成した画面データをＷｅｂサービス処理部３１０に送信し、処理を終了する。また、セッション判断に加えて又はセッション判断の代わりに認証処理を実行して認証判断を行ってもよい。この場合、認証が失敗した場合はＳ７０７に進みエラー処理を実行する。

Ｓ７１１でセッションが有効と判断されなかった場合は、エラー処理を実行すべく同様にＳ７０７へ進む。Ｓ７０７において、アプリケーション３１１は、セッションが無効などのエラー画面データを生成する。Ｓ７０８に進み、アプリケーション３１１は、当該エラー画面データをＷｅｂサービス処理部３１０に送信し、処理を終了する。

次に、図８を参照して、アプリケーション３１２の画面遷移時の処理手順を説明する。ここでは、前述の図５のＳ５１３乃至Ｓ５２２におけるアプリケーション３１２の動作を補足しながら説明する。

Ｓ８０１において、アプリケーション３１２は、Ｗｅｂサービス処理部３１０から受けたリクエストメッセージの指示内容を解析する。この処理はＣＧＩ処理部４１０で行われる。具体的には、リクエストメッセージのＵＲＬからどのメニューに対するリクエストなのかを解析する。

Ｓ８０２において、アプリケーション３１２は、解析結果に基づき、遷移元への画面遷移指示か否かを判断する。予め遷移元への画面遷移としてのリクエストメッセージは定義することが可能なので、ここでは当該リクエストメッセージが予め定義された遷移元への画面遷移指示か否かを判断する。

Ｓ８０２で遷移元への画面遷移指示と判断されなかった場合はＳ８０６へ進む。Ｓ８０６において、アプリケーション３１２は、当該リクエストメッセージにパラメータがあるか否かを判断する。具体的には、当該リクエストメッセージのＵＲＬに続くパラメータ情報として画面ＩＤのパラメータがあるか否かを判断する。Ｓ８０６でパラメータ情報がありと判断された場合はＳ８０７に進み、アプリケーション３１２は、当該パラメータを記憶する。ここでの記憶処理は前述の図４において説明したアプリケーション３１１と同様に、アプリケーション３１２のパラメータデータ４１４として記憶することが可能である。続いて、Ｓ８０７に進み、アプリケーション３１２は、画面遷移をすべく画面処理を実行し、処理を終了する。Ｓ８０６で当該リクエストメッセージにパラメータとしての画面ＩＤがない場合はＳ８０７を実行することなくＳ８０８に進み、アプリケーション３１２は、画面遷移をすべく画面処理を実行し、処理を終了する。

一方、Ｓ８０２で遷移元への画面遷移指示と判断された場合はＳ８０３に進み、アプリケーション３１２は、前述のＳ８０７で記憶した画面ＩＤとしてのパラメータを参照する。続いて、Ｓ８０４において、アプリケーション３１２は、遷移先情報を生成する。具体的には、ＵＲＬとして遷移元の予め決められたテンポラリのＵＲＬを指定し、そのパラメータ情報として参照した（取得した）パラメータ情報を付加する。これらＳ８０３及びＳ８０４は前述の図５のＳ５２１に該当する処理である。続いて、Ｓ８０５に進み、アプリケーション３１２は、遷移先情報をＷｅｂサービス処理部３１０に送信し、処理を終了する。このＳ８０５は前述の図５のＳ５２２に該当する処理である。

＜パラメータデータ＞
次に、図９を参照して、図４のパラメータデータ４１４として記憶されているテーブルについて説明する。ここでは、まず当該テーブルに登録されている画面ＩＤの総数をＮとして管理している。この例では総数Ｎは３である。また画面ＩＤとそれに紐付けられたＵＲＬがＣＧＩの名称として登録されている。例えば画面ＩＤが“ＡＡＡＡＡＡＡ”の場合、遷移先の画面のＵＲＬはＣＧＩを指定するものとして“Ａ１．ｃｇi“となっている。また、画面ＩＤが“ＢＢＢＢＢＢＢ”の場合、遷移先の画面のＵＲＬはＣＧＩを指定するものとして“Ｂ１．ｃｇi“となっている。

ここで、具体的な画面遷移のためのＵＲＬの例について画面ＩＤが“ＡＡＡＡＡＡＡ”の場合について説明する。画面ＩＤが“ＡＡＡＡＡＡＡ”の場合、遷移先の画面のＵＲＬはＣＧＩを指定するものとして“Ａ１．ｃｇi“となっている。したがって、アプリケーション３１１は、“Ａ１．ｃｇi“の画面からアプリケーション３１２の画面に遷移する際は、アプリケーション３１２の該当のＵＲＬ及びパラメーターとして“ＡＡＡＡＡＡＡ”を指定することとなる。下記はそのＵＲＬとパラメータの一例である。
／Ａｐｐｌi２.ｃｇi／？Ｌａｎｇ＝ＪＡ＆ＤＩＤ＝ＡＡＡＡＡＡＡ＆Ｄｕｍｍｙ＝１２３４５６
上記ＵＲＬの例では、アプリケーション３１２の遷移先として“Ａｐｐｌi２.ｃｇi”を指定している。また、パラメータとして言語を指定するＬａｎgと本実施例で説明している画面ＩＤとしてのＤＩＤ及びＤｕｍｍｙパラメータが指定されている。アプリケーション３１２の遷移先では、画面ＩＤのパラメータであるＤＩＤを一時記憶し、遷移元のアプリケーション３１１に戻る際に、ダミーのＵＲＬとそのパラメータを指定することになる。

下記はアプリケーション３１２がアプリケーション３１１に戻る際に指定するＵＲＬ及びパラメータの例である。
／Ａｐｐｌi１ｔｍｐ. ｃｇi／？Ｌａｎｇ＝ＪＡ＆ＤＩＤ＝ＡＡＡＡＡＡＡ＆Ｄｕｍｍｙ＝３２１６５４
上記ＵＲＬの例では、アプリケーション３１１の戻り先として予め決められたテンポラリのＵＲＬである、“Ａｐｐｌi１ｔｍｐ. ｃｇi”を指定している。また、画面ＩＤのパラメータとして、遷移元のアプリケーション３１１が指定した“ＡＡＡＡＡＡＡ”をそのまま指定している。

上記遷移元（アプリケーション３１１）では、テンポラリＵＲＬが指定された場合に、画面ＩＤであるパラメータ“ＡＡＡＡＡＡＡ”より、パラメータデータテーブルの画面ＩＤ欄と一致した真の戻り先のＵＲＬが特定できる。この例では真の戻り先として“Ａ１．ｃｇi“を特定することが可能となる。

＜画面例＞
次に、図１０を参照して、アプリケーション３１１とアプリケーション３１２の画面の例について説明する。図１０の画面１０００は、アプリケーション３１１の画面の例を示している。ここで画面１０００は、Ｗｅｂブラウザ１５０に表示され、アプリケーション３１１のヘッダや各メニューが配置されている様子を示している。１００１は、各メニューの１つであるが、アプリケーション３１２に遷移するメニューの例を示している。

画面１０１０は、アプリケーション３１２の画面の例を示している。ここで画面１０１０は、Ｗｅｂブラウザ１５０に表示され、アプリケーション３１２のヘッダや各メニューが配置されている様子を示している。１０１１は、各メニューの１つであるが、遷移元であるアプリケーション３１１に遷移するメニューの例を示している。

本実施形態では、Ｗｅｂサーバー部３０１がＭＦＰ１０１内に存在し動作する例を説明したが、Ｗｅｂサーバー部３０１は他のＭＦＰであるＭＦＰ１０６や、外部Ｗｅｂサーバー１０４内に存在し動作することも可能である。また、複数のアプリケーションであるアプリケーション３１１、アプリケーション３１２、アプリケーション３１３は、一つのＷｅｂサーバー部内だけでなく、複数の分散したＷｅｂサーバー部内に存在することも可能である。その場合、アプリケーション３１１は、外部Ｗｅｂサーバー１０４のＷｅｂサーバー部内、アプリケーション３１２は、外部ＭＦＰ１０１のＷｅｂサーバー部内に存在し同様の動作をすることも可能である。

以上説明したように、本実施形態によれば、本情報処理装置は、外部装置のＷｅｂブラウザへ画面を提供し、画面遷移が生じる場合に遷移元のアプリケーションにおいて、遷移先のアプリケーションからの戻り先を示す遷移先情報を生成して通知する。一方、遷移先のアプリケーションにおいて、当該遷移先情報を受信して保持し、画面を戻る指示を受けると、保持している遷移先情報を用いてい画面遷移を実行する。これにより、遷移元に複数の画面が存在し、それぞれの画面から一つの遷移先に画面遷移する場合に、ユーザーが意図した遷移元の画面に戻ることが可能となる。また、予め戻り先のＵＲＬを固定しないので、遷移元の画面又はメニュー構成の変更があった場合に、遷移先のアプリケーションの修正をせずに済み、プログラムの保守性が保たれることとなる。また、遷移元の画面のＵＲＬを、画面のメニューや戻るボタン等において直接指定しないので、遷移元の画面への攻撃の脅威が軽減するなどのセキュリティーを強化することが可能となる。

＜第２の実施形態＞
以下では、図１１を参照して、本発明の第２の実施形態について説明する。なお、システム構成などは上記第１の実施形態と同等のため、ここでは、第１の実施形態と差異のある部分のみについて説明し、重複する部分については説明を省略する。本実施形態では、前述の図５で説明した画面ＩＤを遷移先情報として送信する代わりに、直接戻り先のＵＲＬを遷移先情報として送信する。なお、従来技術においては、遷移先の画面におけるメニューや戻りボタン等に直接戻り先のＵＲＬをリンクするものであるが、本実施形態では、戻り先をＵＲＬで直接指定するものの、遷移元のそれぞれの画面（アプリケーション）が戻り先を指定可能な点で異なる。

図１１は、第２の実施形態の本システムにおける、アプリケーション３１１、３１２の画面遷移の処理シーケンスを示す。各動作は、ＭＦＰ１０１のＣＰＵ２０１が制御プログラムを実行することにより実現される。ここでは、ユーザーがアプリケーション３１１のＷｅｂサービスを受けるべく指示した例について説明する。

Ｓ１１０１において、ユーザーは、必要なＷｅｂアプリケーションのサービスを受けるべく、Ｗｅｂブラウザ１５０に表示された画面中のメニュー等をクリックし画面遷移指示を行う。Ｓ１１０２において、Ｗｅｂブラウザ１５０は、リクエストメッセージとして画面遷移指示をＷｅｂサービス処理部３１０に送信する。Ｓ１１０３において、Ｗｅｂサービス処理部３１０は、リクエストメッセージを解析し、アプリケーション３１１を呼び出すべく、アプリケーション３１１に画面遷移指示を行う。Ｓ１１０４において、アプリケーション３１１は、リクエストメッセージに応じた画面データの生成等を行う。

Ｓ１１０５において、アプリケーション３１１は、生成した画面データをＷｅｂサービス処理部３１０に送信する。Ｓ１１０６において、Ｗｅｂサービス処理部３１０は、Ｓ１１０４でアプリケーション３１１から受け取った画面データを、Ｗｅｂブラウザ１５０へ送信する。これによって当該ユーザーは、指示したアプリケーション３１１のＷｅｂサービスを受けることができる。

Ｓ１１０７において、ユーザーは、受け取った画面から新たなサービスを受けるべく、Ｗｅｂブラウザ１５０に対して画面遷移指示を行う。具体的には、ユーザーは、Ｗｅｂブラウザ１５０に表示された画面中のメニューボタン等をクリックすることで、画面遷移指示を行う。ここでは、Ｗｅｂブラウザ１５０に表示された画面のメニューボタンのうちアプリケーション３１２のＷｅｂサービスを受けるためのメニューボタンがクリックされた例を説明する。

Ｓ１１０８において、Ｗｅｂブラウザ１５０は、前述のＳ１１０６におけるユーザーの指示に従い、Ｗｅｂサービス処理部３１０にリクエストメッセージとして画面遷移指示を送信する。Ｓ１１０９において、Ｗｅｂサービス処理部３１０は、アプリケーション３１１に画面遷移指示を行う。

Ｓ１１１０において、アプリケーション３１１は、リクエストされた画面遷移がアプリケーション３１２のメニューであるため、アプリケーション３１２の画面にリダイレクトすべく、該当するＵＲＬを生成する。さらに戻り先ＵＲＬとして本画面のＵＲＬをＵＲＬのパラメータとして付加し遷移先情報を生成する。ここでのパラメータ処理は、前述の図４のパラメータ処理部４１３で行われる。ここで、生成したパラメータを前述のパラメータデータ４１４として記憶する。

Ｓ１１１１において、アプリケーション３１１は、生成した遷移先情報を画面のリダイレクト処理としてＷｅｂサービス処理部３１０に送信する。Ｓ１１１２において、Ｗｅｂサービス処理部３１０は、当該遷移先情報を一度Ｗｅｂブラウザ１５０に送信する。Ｓ１１１３において、Ｗｅｂブラウザ１５０は、受け付けたリクエストがリダイレクトであるため、ＵＲＬと戻り先ＵＲＬで構成された遷移先情報を参照し、画面遷移指示をＷｅｂサービス処理部３１０に送信する。Ｓ１１１４において、Ｗｅｂサービス処理部３１０は、送信されたリクエストメッセージ中のＵＲＬがアプリケーション３１２のメニューであるため、アプリケーション３１２に画面遷移指示を行うべく、アプリケーション３１２を呼び出す。その際、画面遷移指示のリクエストには、Ｓ１１０９で生成された戻り先ＵＲＬの情報を含むことが可能である。

Ｓ１１１５において、アプリケーション３１２は、Ｓ１１１３でＷｅｂサービス処理部３１０から受け付けた戻り先ＵＲＬを記憶する。戻り先ＵＲＬの記憶は、アプリケーション３１２が管理するＲＡＭ２０２又はＨＤＤ２０４領域に記憶してもよい。さらに、アプリケーション３１２は、リクエストメッセージに応じた画面データを生成する。Ｓ１１１６において、アプリケーション３１２は、生成した画面データをＷｅｂサービス処理部３１０に送信する。Ｓ１１１７において、Ｗｅｂサービス処理部３１０は、Ｗｅｂブラウザ１５０に当該画面データを送信する。これにより、ユーザーは、Ｗｅｂブラウザ１５０より、アプリケーション３１２のＷｅｂサービスを受けられる。

次に、ユーザーがアプリケーション３１２の画面から、遷移元であるアプリケーション３１１の画面に戻るための画面遷移指示を行う場合のシーケンスをＳ１１１８以降で説明する。Ｓ１１１８において、ユーザーは、元のアプリケーション３１１に戻るべく、Ｗｅｂブラウザ１５０に表示された画面中の、戻るためのメニューをクリックするなどして、画面遷移指示を行う。

Ｓ１１１９において、Ｗｅｂブラウザ１５０は、画面遷移指示をＷｅｂサービス処理部３１０に送信する。Ｓ１１２０において、Ｗｅｂサービス処理部３１０は、同様に画面遷移指示をアプリケーション３１２へ送信し、画面遷移指示をすべくアプリケーション３１２を呼び出す。Ｓ１１２１において、アプリケーション３１２は、前述のＳ１１１４で記憶した戻り先ＵＲＬを呼び出す。そして遷移元（戻り先）であるアプリケーション３１１のＵＲＬとして戻り先ＵＲＬを設定し、遷移先情報を生成する。Ｓ１１２２において、アプリケーション３１２は、設定した戻り先ＵＲＬに画面遷移させるべく、当該遷移先情報をＷｅｂサービス処理部３１０に送信する。Ｓ１１２３において、Ｗｅｂサービス処理部３１０は、当該遷移先情報を一度Ｗｅｂブラウザ１５０に送信する。

Ｓ１１２４において、Ｗｅｂブラウザ１５０は、受け付けたリクエストがリダイレクトであるため、戻り先ＵＲＬで構成された遷移先情報を参照し、画面遷移指示をＷｅｂサービス処理部３１０に送信する。Ｓ１１２５において、Ｗｅｂサービス処理部３１０は、送信されたリクエストメッセージ中のＵＲＬがアプリケーション３１１のメニューであるため、アプリケーション３１１に画面遷移指示を行うべく、アプリケーション３１１を呼び出す。

Ｓ１１２６において、アプリケーション３１１は、セッション処理を行う。ここでのセッション処理は、第１の実施形態と同様に前述の図４の認証処理部４１１で行われる。また、ここでセッション処理だけでなく認証処理を行うことも可能である。その場合の処理も前述の図４の認証処理部４１１で行われることとなる。Ｓ１１２７において、アプリケーション３１１は、当該ＵＲＬ情報を含むリクエストメッセージより遷移元の画面データを生成する。ここでの画面生成処理は前述の図４の画面生成部４１２で行われる。

Ｓ１１２８において、アプリケーション３１１は、生成した画面データをＷｅｂサービス処理部３１０に送信する。Ｓ１１２９において、Ｗｅｂサービス処理部３１０は、受け取った該画像データをＷｅｂブラウザ１５０に送信する。

以上説明したように、本実施形態では、上記第１の実施形態で説明した画面ＩＤの代わりに、直接戻り先のＵＲＬを遷移先情報として送信し、画面遷移することも可能となる。

＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims

外部装置のＷｅｂブラウザから利用可能な第１のＷｅｂアプリケーションと前記第１のＷｅｂアプリケーションとは異なる第２のＷｅｂアプリケーションを少なくとも有する情報処理装置であって、
外部装置で動作するＷｅｂブラウザに、前記第１のＷｅｂアプリケーションの画面を表示するための画面データを送信する第１の送信手段と、
前記第１のＷｅｂアプリケーションの画面から前記第２のＷｅｂアプリケーションの画面に遷移するための画面遷移を引き起こす指示に応じて、前記第２のＷｅｂアプリケーションの画面を要求する指示を前記外部装置から受信する第１の受信手段と、
前記第２のＷｅｂアプリケーションの画面を要求する指示を受信した場合に、前記第２のＷｅｂアプリケーションの画面を表示するための画面データとともに、前記Ｗｅｂブラウザに提供されていた前記第１のＷｅｂアプリケーションの画面を識別する識別情報を前記外部装置の前記Ｗｅｂブラウザに送信する第２の送信手段と、
前記第２のＷｅｂアプリケーションの画面から前記第１のＷｅｂアプリケーションの提供する画面に遷移するための画面遷移を引き起こす指示に応じて、前記第１のＷｅｂアプリケーションの画面を識別する識別情報に対応する情報を前記外部装置のＷｅｂブラウザから受信した場合に、前記受信した識別情報に対応する情報に基づいて前記第１のＷｅｂアプリケーションが提供する遷移先の画面を決定する決定手段と、を有することを特徴とする情報処理装置。
前記受信した識別情報に対応する前記情報には、前記第１のＷｅｂアプリケーションの画面を識別するための識別子と、所定のＵＲＬとが含まれ、
前記決定手段は、前記識別子及び前記所定のＵＲＬから、前記第１のＷｅｂアプリケーションが提供する遷移先のＵＲＬを決定することを特徴とする請求項１に記載の情報処理装置。
前記決定手段は、前記所定のＵＲＬが含まれている前記情報を受信したことに従って、前記情報に含まれている前記識別子を検索キーとして、予め保持している識別子を検索し、検索された該識別子に関連付けて記憶されている情報を用いて前記遷移先のＵＲＬを決定することを特徴とする請求項２に記載の情報処理装置。
前記受信した識別情報に対応する情報には、さらに、ダミーパラメータが含まれていることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
前記第１のＷｅｂアプリケーションは、
前記決定手段によって決定された前記遷移先のＵＲＬに対応する画面を要求する指示を受け付けると、セッション処理を実行し、
前記セッション処理の結果、前記外部装置とのセッションが有効である場合は、前記遷移先のＵＲＬに対応する前記遷移先の画面を表示するための画面データを前記Ｗｅｂブラウザへ提供することを特徴とする請求項２乃至４の何れか１項に記載の情報処理装置。
前記第１のＷｅｂアプリケーションは、
前記セッション処理の結果、前記外部装置との前記セッションが無効である場合は、前記遷移先のＵＲＬに対応する前記遷移先の画面を表示するための画面データを前記Ｗｅｂブラウザへ提供することなしに、エラー処理を実行することを特徴とする請求項５に記載の情報処理装置。
前記第１のＷｅｂアプリケーションは、さらに、
認証処理を実行し、
前記認証処理の結果、認証に失敗した場合は、前記遷移先のＵＲＬに対応する前記遷移先の画面を表示するための画面データを前記Ｗｅｂブラウザへ提供することなしに、エラー処理を実行することを特徴とする請求項６に記載の情報処理装置。
前記第２の送信手段は、前記第２のＷｅｂアプリケーションの画面に遷移するための画面遷移を引き起こす指示に応じて、前記第２のＷｅｂアプリケーションの画面を要求する指示を受信した場合に、前記識別情報を前記外部装置の前記Ｗｅｂブラウザに送信するとともに、前記Ｗｅｂブラウザに提供されていた前記第１のＷｅｂアプリケーションの画面を識別する識別子を記憶手段に記憶し、
前記第１のＷｅｂアプリケーションは、
前記決定手段によって決定された前記遷移先のＵＲＬに対応する画面を要求する指示を受け付けた場合であって、前記遷移先のＵＲＬに対応する画面と、前記記憶手段に記憶された識別子に対応する画面とが一致する場合は、前記遷移先のＵＲＬに対応する前記遷移先の画面を表示するための画面データを前記Ｗｅｂブラウザへ提供し、
前記決定手段によって決定された前記遷移先のＵＲＬに対応する画面を要求する指示を受け付けた場合であって、前記遷移先のＵＲＬに対応する画面と、前記記憶手段に記憶された識別子に対応する画面とが一致しない場合には、前記遷移先の画面の画面データを前記Ｗｅｂブラウザに提供することなしに、エラー処理を実行することを特徴とする請求項２乃至４のいずれか１項に記載の情報処理装置。
前記第１のＷｅｂアプリケーションは、
前記エラー処理として、エラー内容を通知する画面データを生成し、当該生成した画面データを前記Ｗｅｂブラウザへ提供することを特徴とする請求項６乃至８のいずれか１項に記載の情報処理装置。
前記第１のＷｅｂアプリケーションは、前記情報処理装置の各種設定を外部装置のＷｅｂブラウザから変更するための機能を提供するＷｅｂアプリケーションであり、前記第２のＷｅｂアプリケーションは、前記情報処理装置にインストールされるアプリケーションの管理に関する機能を提供するＷｅｂアプリケーションであることを特徴とする請求項１乃至８のいずれか１項に記載の情報処理装置。
前記情報処理装置は、印刷手段を有するプリンタであることを特徴とする請求項１乃至１０のいずれか１項に記載の情報処理装置。
前記情報処理装置は、印刷手段と、読取手段とを少なくとも有する画像処理装置であることを特徴とする請求項１乃至１０のいずれか１項に記載の情報処理装置。
外部装置のＷｅｂブラウザから利用可能な第１のＷｅｂアプリケーションと前記第１のＷｅｂアプリケーションとは異なる第２のＷｅｂアプリケーションを少なくとも有する情報処理装置の制御方法であって、
外部装置で動作するＷｅｂブラウザに、前記第１のＷｅｂアプリケーションの画面を表示するための画面データを送信する第１の送信ステップと、
前記第１のＷｅｂアプリケーションの画面から前記第２のＷｅｂアプリケーションの画面に遷移するための画面遷移を引き起こす指示に応じて、前記第２のＷｅｂアプリケーションの画面を要求する指示を前記外部装置から受信する第１の受信ステップと、
前記第２のＷｅｂアプリケーションの画面を要求する指示を受信した場合に、前記第２のＷｅｂアプリケーションの画面を表示するための画面データとともに、前記Ｗｅｂブラウザに提供されていた前記第１のＷｅｂアプリケーションの画面を識別する識別情報を前記外部装置の前記Ｗｅｂブラウザに送信する第２の送信ステップと、
前記第２のＷｅｂアプリケーションの画面から前記第１のＷｅｂアプリケーションの提供する画面に遷移するための画面遷移を引き起こす指示に応じて、前記第１のＷｅｂアプリケーションの画面を識別する識別情報に対応する情報を前記外部装置のＷｅｂブラウザから受信した場合に、前記受信した識別情報に対応する情報に基づいて前記第１のＷｅｂアプリケーションが提供する遷移先の画面を決定する決定ステップと、を有することを特徴とする制御方法。
請求項１乃至１２の何れか１項に記載の情報処理装置としてコンピュータを機能させるためのプログラム。