(57)【要約】【課題】Ｗｅｂアプリケーションを介して複数の画像処理装置が連携してジョブを実行させる際に、ユーザの操作性を煩雑にすることなく、他のＭＦＰにおけるジョブの処理状況を容易に確認する仕組みを提供する。【解決手段】本情報処理装置は、Ｗｅｂサーバからの処理要求を受信し、処理要求を解析して他の情報処理装置に処理要求を転送する必要があるか否かを判定し、転送する必要がないと判定すると、処理要求を自装置で処理し、転送する必要があると判定すると、処理要求を他の情報処理装置へ転送し、処理要求を自装置で処理した場合は当該処理結果をＷｅｂサーバに送信し、処理要求を他の情報処理装置に転送した場合は他の情報処理装置における処理結果をＷｅｂサーバに送信する。【選択図】  図６
2015014893.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂサーバから提供される操作画面を表示してＷｅｂアプリケーションを実行する情報処理装置であって、
前記Ｗｅｂサーバからの処理要求を受信する受信手段と、
前記受信手段によって受信した前記処理要求を解析して他の情報処理装置に該処理要求を転送する必要があるか否かを判定する転送判定手段と、
前記転送判定手段が前記処理要求を前記他の情報処理装置に転送する必要がないと判定すると、該処理要求を自装置の処理手段に転送し、前記転送判定手段が前記処理要求を前記他の情報処理装置に転送する必要があると判定すると、該処理要求を該他の情報処理装置へ転送する転送手段と、
前記受信手段によって受信した前記処理要求を自装置で処理した場合は当該処理結果を前記Ｗｅｂサーバに送信し、該処理要求を前記他の情報処理装置に転送した場合は該他の情報処理装置における処理結果を該Ｗｅｂサーバに送信する応答手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記転送手段は、さらに、自装置の前記処理手段による処理結果がエラーである場合に、前記他の情報処理装置へ前記処理要求を転送することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記転送判定手段が前記処理要求を前記他の情報処理装置に転送する必要があると判定すると、該処理要求を前記他の情報処理装置で処理可能な要求に書き換える書換手段をさらに備えることを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記書換手段は、前記処理要求がファクシミリジョブである場合に、該処理要求に指定されたスキャンサイズを、前記他の情報処理装置が実行可能なスキャンサイズに書き換えることを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記転送手段は、前記処理要求を前記他の情報処理装置へ転送する際に、該処理要求を前記他の情報処理装置へ転送することをユーザに確認する転送確認画面を表示することを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。
【請求項６】
Ｗｅｂサーバから提供される操作画面を表示してＷｅｂアプリケーションを実行する第１の情報処理装置及び第２の情報処理装置と、該Ｗｅｂサーバとを含む情報処理システムであって、
前記Ｗｅｂサーバは、
処理要求を前記第１の情報処理装置に送信する送信手段を備え、
前記第１の情報処理装置は、
前記Ｗｅｂサーバからの処理要求を受信する受信手段と、
前記受信手段によって受信した前記処理要求を解析して他の情報処理装置に該処理要求を転送する必要があるか否かを判定する転送判定手段と、
前記転送判定手段が前記処理要求を前記他の情報処理装置に転送する必要がないと判定すると、該処理要求を自装置の処理手段に転送し、前記転送判定手段が前記処理要求を前記他の情報処理装置に転送する必要があると判定すると、該処理要求を該他の情報処理装置へ転送する転送手段と、
前記受信手段によって受信した前記処理要求を自装置で処理した場合は当該処理結果を前記Ｗｅｂサーバに送信する第１応答手段とを備え、
前記第２の情報処理装置は、
転送された前記処理要求を処理する処理手段と、
前記処理要求に対する応答として、前記処理手段による処理結果を前記Ｗｅｂサーバに送信する第２応答手段と
を備えることを特徴とする情報処理システム。
【請求項７】
前記転送手段は、さらに、自装置の前記処理手段による処理結果がエラーである場合に、前記第２の情報処理装置へ前記処理要求を転送することを特徴とする請求項６に記載の情報処理システム。
【請求項８】
前記転送手段は、前記処理要求を前記他の情報処理装置へ転送する際に、該処理要求を前記他の情報処理装置へ転送することをユーザに確認する転送確認画面を表示することを特徴とする請求項６又は７に記載の情報処理システム。
【請求項９】
Ｗｅｂサーバから提供される操作画面を表示してＷｅｂアプリケーションを実行する第１の情報処理装置及び第２の情報処理装置と、該Ｗｅｂサーバとを含む情報処理システムであって、
前記Ｗｅｂサーバは、
処理要求を前記第１の情報処理装置に送信する送信手段を備え、
前記第１の情報処理装置は、
前記Ｗｅｂサーバからの処理要求を受信する受信手段と、
前記受信手段によって受信された処理要求を処理する第１処理手段と、
前記第１処理手段による処理結果に基づき、前記処理要求に関する情報を前記第１の情報処理装置に保持するか否かを判定する保持判定手段と、
前記保持判定手段が、前記処理要求に関する情報を保持する必要があると判定すると、前記第１の情報処理装置を操作しているユーザのユーザ情報と該処理要求に関する情報とを紐付けて記憶する記憶手段と、
前記第２の情報処理装置から送信されるユーザ情報に対応する前記処理要求に関する情報を前記記憶手段が記憶していれば、該処理要求を前記第２の情報処理装置に転送する転送手段とを備え、
前記第２の情報処理装置は、
所定の処理要求に関する処理再開をユーザ情報とともに受け付ける処理再開手段と、
前記処理再開手段によって受け付けた前記ユーザ情報を前記第１の情報処理装置に通知する通知手段と、
前記通知手段による通知の応答として転送された処理要求を処理する第２処理手段と、  前記処理要求に対する応答として、前記第２処理手段による処理結果を前記Ｗｅｂサーバに送信する応答手段と
を備えることを特徴とする情報処理システム。
【請求項１０】
前記第１の情報処理装置は、前記転送手段によって転送した処理要求に対応する、前記処理要求に関する情報を前記記憶手段から削除する削除手段をさらに備えることを特徴とする請求項９に記載の情報処理システム。
【請求項１１】
前記記憶手段は、前記処理要求に関する情報を保存した時刻情報も併せて記憶し、
前記第１の情報処理装置は、前記時刻情報に相当する時間が経過した前記処理要求に関する情報を前記記憶手段から削除する削除手段をさらに備えることを特徴とする請求項９に記載の情報処理システム。
【請求項１２】
前記転送手段が転送する情報には、前記処理要求に加えて、前記Ｗｅｂサーバと前記第１の情報処理装置との間で使用されたセッション情報と、該第１の情報処理装置を操作したユーザの情報とが含まれることを特徴とする請求項６乃至１１の何れか１項に記載の情報処理システム。
【請求項１３】
前記第１の情報処理装置は、
前記処理要求を前記第２の情報処理装置で処理可能な要求に書き換える書換手段をさらに備えることを特徴とする請求項６乃至１２の何れか１項に記載の情報処理システム。
【請求項１４】
Ｗｅｂサーバから提供される操作画面を表示してＷｅｂアプリケーションを実行する情報処理装置の制御方法であって、
受信手段が、前記Ｗｅｂサーバからの処理要求を受信する受信工程と、
転送判定手段が、前記受信工程において受信した前記処理要求を解析して他の情報処理装置に該処理要求を転送する必要があるか否かを判定する転送判定工程と、
転送手段が、前記転送判定工程において前記処理要求を前記他の情報処理装置に転送する必要がないと判定すると、該処理要求を自装置の処理手段に転送し、前記転送判定工程において前記処理要求を前記他の情報処理装置に転送する必要があると判定すると、該処理要求を該他の情報処理装置へ転送する転送工程と、
応答手段が、前記受信工程において受信した前記処理要求を自装置で処理した場合は当該処理結果を前記Ｗｅｂサーバに送信し、該処理要求を前記他の情報処理装置に転送した場合は該他の情報処理装置における処理結果を該Ｗｅｂサーバに送信する応答工程と
を実行することを特徴とする情報処理装置の制御方法。
【請求項１５】
Ｗｅｂサーバから提供される操作画面を表示してＷｅｂアプリケーションを実行する第１の情報処理装置及び第２の情報処理装置と、該Ｗｅｂサーバとを含む情報処理システムの制御方法であって、
前記Ｗｅｂサーバは、
送信手段が、処理要求を前記第１の情報処理装置に送信する送信工程を実行し、
前記第１の情報処理装置は、
受信手段が、前記Ｗｅｂサーバからの前記処理要求を受信する受信工程と、
転送判定手段が、前記受信工程において受信した前記処理要求を解析して他の情報処理装置に該処理要求を転送する必要があるか否かを判定する転送判定工程と、
転送手段が、前記転送判定工程が前記処理要求を前記他の情報処理装置に転送する必要がないと判定すると、該処理要求を自装置の処理手段に転送し、前記転送判定工程が前記処理要求を前記他の情報処理装置に転送する必要があると判定すると、該処理要求を該他の情報処理装置へ転送する転送工程と、
第１応答手段が、前記受信工程において受信した前記処理要求を自装置で処理した場合は当該処理結果を前記Ｗｅｂサーバに送信する第１応答工程とを実行し、
前記第２の情報処理装置は、
処理手段が、転送された前記処理要求を処理する処理工程と、
第２応答手段が、前記処理要求に対する応答として、前記処理手段による処理結果を前記Ｗｅｂサーバに送信する第２応答工程と
を実行することを特徴とする情報処理システムの制御方法。
【請求項１６】
Ｗｅｂサーバから提供される操作画面を表示してＷｅｂアプリケーションを実行する第１の情報処理装置及び第２の情報処理装置と、該Ｗｅｂサーバとを含む情報処理システムの制御方法であって、
前記Ｗｅｂサーバは、
送信手段が、処理要求を前記第１の情報処理装置に送信する送信工程を実行し、
前記第１の情報処理装置は、
受信手段が、前記Ｗｅｂサーバからの処理要求を受信する受信工程と、
第１処理手段が、前記受信工程において受信された前記処理要求を処理する第１処理工程と、
保持判定手段が、前記第１処理工程による処理結果に基づき、前記処理要求に関する情報を前記第１の情報処理装置に保持するか否かを判定する保持判定工程と、
記憶手段が、前記保持判定工程において前記処理要求に関する情報を保持する必要があると判定すると、前記第１の情報処理装置を操作しているユーザのユーザ情報と該処理要求に関する情報とを紐付けて記憶する記憶工程と、
転送手段が、前記第２の情報処理装置から送信されるユーザ情報に対応する前記処理要求に関する情報を前記記憶手段が記憶していれば、該処理要求を前記第２の情報処理装置に転送する転送工程とを実行し
前記第２の情報処理装置は、
処理再開手段が、所定の処理要求に関する処理再開をユーザ情報とともに受け付ける処理再開工程と、
通知手段が、前記処理再開工程において受け付けた前記ユーザ情報を前記第１の情報処理装置に通知する通知工程と、
第２処理手段が、前記通知工程による通知の応答として転送された処理要求を処理する第２処理工程と、
応答手段が、前記処理要求に対する応答として、前記第２処理工程による処理結果を前記Ｗｅｂサーバに送信する応答工程と
を実行することを特徴とする情報処理システムの制御方法。
【請求項１７】
請求項１４に記載の情報処理装置の制御方法における各工程をコンピュータに実行させるためのプログラム。
【請求項１８】
請求項１５又は１６に記載の情報処理システムの制御方法における各工程をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサーバに接続され、当該Ｗｅｂサーバにより提供される操作画面を表示するＷｅｂブラウザを備えた情報処理装置、情報処理システム、それらの制御方法、及びプログラムに関するものである。
【背景技術】
【０００２】
ＰＣなどの情報処理装置がネットワーク上のＷｅｂサーバに接続され、Ｗｅｂサーバにより提供される操作画面を、情報処理装置が備えるＷｅｂブラウザ上に表示することが知られている。この場合、まず情報処理装置のＷｅｂブラウザが、Ｗｅｂサーバに対して操作画面を要求（リクエスト）する。そして、Ｗｅｂサーバ上のＷｅｂアプリケーションが情報処理装置からの要求に応じて、Ｗｅｂブラウザに操作画面を表示させるためのＨＴＭＬデータを情報処理装置に応答（レスポンス）する。情報処理装置のＷｅｂブラウザは、受信したＨＴＭＬデータを解析し、ＨＴＭＬデータの記述に基づいた操作画面を表示する。更に、Ｗｅｂブラウザに表示された操作画面を介してユーザが指示を入力すると、入力された指示をＷｅｂブラウザがＷｅｂサーバに対して通知する。そして、この通知を受けたＷｅｂサーバ上のＷｅｂアプリケーションは、入力された指示に従って処理を実行する。
【０００３】
ところで、最近ではスキャナやプリンタを備えたＭＦＰ（Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｅｒｉｐｈｅｒａｌ）の中にも、上述したようなＷｅｂブラウザを備えているものがある。そして、ＭＦＰは、上述した手順を用いてＷｅｂサーバにより提供される操作画面をＭＦＰのＷｅｂブラウザに表示し、ユーザからの各種指示を受け付ける。また更には、ＭＦＰが備える各機能を利用するための指示を入力する操作画面をＷｅｂサーバが提供し、ユーザがＷｅｂブラウザ上に表示された操作画面を介して、ＭＦＰに対する指示を入力するシステムも考えられている。
【０００４】
このシステムでは、Ｗｅｂサーバは、ユーザから入力された指示の内容に従って、ＭＦＰに対して各種処理の実行を依頼する。そして、この依頼を受けたＭＦＰは、依頼された処理を実行する。これにより、ＭＦＰを操作するための全ての操作画面をＭＦＰ内で保持しておく必要がなくなり、また操作画面の変更もＷｅｂサーバ上で容易に行うことができるようになる。具体的には、ＭＦＰの各機能をＲＰＣ（Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ  Ｃａｌｌ）的に公開し、Ｗｅｂサーバから適宜呼び出す方法が考えられている。この方法では、Ｗｅｂサーバ側に処理のメインロジックを持たせ、ＭＦＰの制御やユーザとの対話的処理をＷｅｂサーバに実行させて、処理の負荷を軽減させることができる。例えばＷｅｂサービスとしてＭＦＰの機能を公開することで、Ｗｅｂサーバからはローカルなサブルーチンを呼び出すようにＭＦＰが提供する機能を実行できる。また、その呼び出しの応答を管理することで処理のメインロジックをサーバ側に持たせることができる。
【０００５】
しかしながら、ＲＰＣは、クライアントが要求メッセージをサーバに送信することで開始されるため、クライアントからサービスを提供するサーバに通信コネクションを張る必要がある。即ち、この方法では、ＭＦＰがファイアウォールで守られていたり、ネットワークアドレス変換を用いる環境にいたりする場合、ＭＦＰは外部ネットワークに存在するＷｅｂサーバからのＲＰＣ要求を受け付けることができない。ファイアウォールは一般的に内部から外部への接続は許可するが、外部から内部への接続は許可しないためである。また、ＭＦＰがアドレス変換を用いる環境にいる場合は、サーバ側からＭＦＰを特定できないためである。
【０００６】
そこで、Ｗｅｂブラウザに表示された操作画面を介して入力された指示に基づいてＷｅｂサーバが制御スクリプトを提供し、デバイスがその制御スクリプトを実行することでＭＦＰを操作することが考えられる。制御スクリプトは、Ｗｅｂブラウザからのリクエストに対する応答としてデバイスに渡される。そのため、ＷｅｂサーバからＭＦＰにコネクションを張る必要がなく、ＭＦＰがファイアウォールで守られていたり、ネットワークアドレス変換を用いる環境にいたりする場合でも利用が可能である。
【０００７】
しかしながら、このような仕組みを用いた場合、サーバはユーザが操作しているＭＦＰにしかジョブを実行させることができない。例えば、ユーザが操作しているＭＦＰにおいて、ジョブの実行に失敗した場合、Ｗｅｂアプリケーションは他のＭＦＰにジョブを投入することで代行処理を行いたいことがある。なお、この代行処理は、複数のＭＦＰが１つのジョブを実行する連携処理の一例である。しかし、外部ネットワークに存在するＷｅｂアプリケーションからユーザが操作しているＭＦＰ以外のＭＦＰにジョブを投入することはできない。特許文献１には、ＭＦＰでジョブの実行ができなかった場合、処理中のジョブをＷｅｂサーバでプールし、ユーザが別のＭＦＰに移動し、プールしておいたＷｅｂサーバ上のジョブにアクセスすることで代行処理を実現する技術が提案されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１１−９５８９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、上記従来技術には以下に記載する問題がある。上述したように、外部ネットワークに存在するＷｅｂサーバが制御スクリプトをＷｅｂブラウザからのリクエストに対する応答としてデバイスに渡す方法では、Ｗｅｂサーバは、ユーザが操作しているＭＦＰ以外のＭＦＰにジョブを投入することができない。そのため、ジョブの代行処理や複数のＭＦＰに渡る連携処理を他のＭＦＰに依頼することができない。
【００１０】
一方で、特許文献１の方法では、ユーザが必ず代行処理を行うＭＦＰまで移動し、さらにデバイスを操作してＷｅｂサーバにプールしておいたジョブにアクセスする必要があり、ユーザにとっては非常に手間がかかるという問題がある。また、一般的なジョブの代行処理では、ジョブの実行が指示されたＭＦＰから、ローカルネットワークに存在する他のＭＦＰに対してジョブの実行を依頼するだけである。そのため、ジョブの実行結果をＷｅｂアプリケーションが知ることができず、ユーザに対して代行処理の結果を通知することができないという問題がある。
【００１１】
本発明は、上述の問題に鑑みて成されたものであり、Ｗｅｂアプリケーションを介して複数の画像処理装置が連携してジョブを実行させる際に、ユーザの操作性を煩雑にすることなく、他のＭＦＰにおけるジョブの処理状況を容易に確認する仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明は、Ｗｅｂサーバから提供される操作画面を表示してＷｅｂアプリケーションを実行する情報処理装置であって、前記Ｗｅｂサーバからの処理要求を受信する受信手段と、前記受信手段によって受信した前記処理要求を解析して他の情報処理装置に該処理要求を転送する必要があるか否かを判定する転送判定手段と、前記転送判定手段が前記処理要求を前記他の情報処理装置に転送する必要がないと判定すると、該処理要求を自装置の処理手段に転送し、前記転送判定手段が前記処理要求を前記他の情報処理装置に転送する必要があると判定すると、該処理要求を該他の情報処理装置へ転送する転送手段と、前記受信手段によって受信した前記処理要求を自装置で処理した場合は当該処理結果を前記Ｗｅｂサーバに送信し、該処理要求を前記他の情報処理装置に転送した場合は該他の情報処理装置における処理結果を該Ｗｅｂサーバに送信する応答手段とを備えることを特徴とする。
【００１３】
また、本発明は、Ｗｅｂサーバから提供される操作画面を表示してＷｅｂアプリケーションを実行する第１の情報処理装置及び第２の情報処理装置と、該Ｗｅｂサーバとを含む情報処理システムであって、前記Ｗｅｂサーバは、処理要求を前記第１の情報処理装置に送信する送信手段を備え、前記第１の情報処理装置は、前記Ｗｅｂサーバからの処理要求を受信する受信手段と、前記受信手段によって受信した前記処理要求を解析して他の情報処理装置に該処理要求を転送する必要があるか否かを判定する転送判定手段と、前記転送判定手段が前記処理要求を前記他の情報処理装置に転送する必要がないと判定すると、該処理要求を自装置の処理手段に転送し、前記転送判定手段が前記処理要求を前記他の情報処理装置に転送する必要があると判定すると、該処理要求を該他の情報処理装置へ転送する転送手段と、前記受信手段によって受信した前記を自装置で処理した場合は当該処理結果を前記Ｗｅｂサーバに送信する第１応答手段とを備え、前記第２の情報処理装置は、転送された前記処理要求を処理する処理手段と、前記処理要求に対する応答として、前記処理手段による処理結果を前記Ｗｅｂサーバに送信する第２応答手段とを備えることを特徴とする。
【００１４】
また、本発明は、Ｗｅｂサーバから提供される操作画面を表示してＷｅｂアプリケーションを実行する第１の情報処理装置及び第２の情報処理装置と、該Ｗｅｂサーバとを含む情報処理システムであって、前記Ｗｅｂサーバは、処理要求を前記第１の情報処理装置に送信する送信手段を備え、前記第１の情報処理装置は、前記Ｗｅｂサーバからの処理要求を受信する受信手段と、前記受信手段によって受信された処理要求を処理する第１処理手段と、前記第１処理手段による処理結果に基づき、前記処理要求に関する情報を前記第１の情報処理装置に保持するか否かを判定する保持判定手段と、前記保持判定手段が、前記処理要求に関する情報を保持する必要があると判定すると、前記第１の情報処理装置を操作しているユーザのユーザ情報と該処理要求に関する情報とを紐付けて記憶する記憶手段と、前記第２の情報処理装置から送信されるユーザ情報に対応する前記処理要求に関する情報を前記記憶手段が記憶していれば、該処理要求を前記第２の情報処理装置に転送する転送手段とを備え、前記第２の情報処理装置は、所定の処理要求に関する処理再開をユーザ情報とともに受け付ける処理再開手段と、前記処理再開手段によって受け付けた前記ユーザ情報を前記第１の情報処理装置に通知する通知手段と、前記通知手段による通知の応答として転送された処理要求を処理する第２処理手段と、前記処理要求に対する応答として、前記第２処理手段による処理結果を前記Ｗｅｂサーバに送信する応答手段とを備えることを特徴とする。
【発明の効果】
【００１５】
本発明は、Ｗｅｂアプリケーションを介して複数の画像処理装置が連携してジョブを実行させる際に、ユーザの操作性を煩雑にすることなく、他のＭＦＰにおけるジョブの処理状況を容易に確認する仕組みを提供できる。
【図面の簡単な説明】
【００１６】
【図１】第１の実施形態における情報処理システムの全体を示す図。
【図２】第１の実施形態における情報処理装置の構成を示すブロック図。
【図３】第１の実施形態におけるＷｅｂサーバの構成を示すブロック図。
【図４】第１の実施形態におけるソフトウェア構成を示す図。
【図５】第１の実施形態における処理のシーケンス図。
【図６】第１の実施形態における転送アプリケーションのフローチャート。
【図７】第１の実施形態におけるレスポンスヘッダの一例を示す図。
【図８】第１の実施形態における処理要求とその応答の一例を示す図。
【図９】第１の実施形態における転送確認画面の一例を示す図。
【図１０】第２の実施形態におけるソフトウェア構成を示す図。
【図１１】第２の実施形態における処理のシーケンス図。
【図１２】第２の実施形態における転送アプリケーションの転送元のフローチャート。
【図１３】第２の実施形態における転送アプリケーションの転送先のフローチャート。
【図１４】第２の実施形態における転送処理要求の一例を示す図。
【図１５】第３の実施形態におけるソフトウェア構成を示す図。
【図１６】第３の実施形態における処理のシーケンス図。
【図１７】第３の実施形態における転送アプリケーションのフローチャート。
【図１８】第３の実施形態における利用する変換アプリケーションを決定する際の転送アプリケーションのフローチャート。
【図１９】第３の実施形態における変換アプリケーションのフローチャート。
【図２０】第４の実施形態におけるソフトウェア構成を示す図。
【図２１】第４の実施形態における情報処理システムの一連の処理を示したシーケンス図。
【図２２】第４の実施形態における転送アプリケーションがＷｅｂブラウザからリクエストを受信した時の処理の流れを示すフローチャート。
【図２３】第４の実施形態における転送アプリケーションが処理再開ボタンの押下を検知した時の処理の流れを示すフローチャート。
【図２４】第４の実施形態における転送アプリケーションがユーザ情報パケットを受信した際の処理の流れを示すフローチャート。
【図２５】第４の実施形態における処理要求とその応答の一例を示す図。
【図２６】第４の実施形態における処理再開ボタンが押下された時にブロードキャストするユーザ情報パケットの一例を示す図。
【図２７】第４の実施形態における処理再開時に送信する情報の一例を示す図。
【発明を実施するための形態】
【００１７】
以下、添付図面を参照して本発明の実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。
【００１８】
＜第１の実施形態＞
＜情報処理システムの構成＞
以下では、図１乃至図９を参照して、本発明の第１の実施形態について説明する。まず、図１を参照して、本実施形態に係る情報処理装置を収容する情報処理システムの構成例について説明する。本情報処理システムは、ネットワーク１００を介して接続されるＭＦＰ１０１、１０２、１０５と、Ｗｅｂサーバ１０３から構成される。ネットワーク１００は、各装置間で通信を行うための基盤であって、インターネット１０４に接続されている。ＭＦＰ１０１、１０２は、Ｗｅｂブラウザ機能を有するＭＦＰ（Ｍｕｌｔｉｐｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）である。ＭＦＰ１０５は、Ｗｅｂブラウザ機能を持たないＭＦＰ（Ｍｕｌｔｉｐｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）である。さらに、ＭＦＰ１０１、１０２、１０５は、ローカルなＩＰアドレスで管理されていてもよい。その場合ネットワーク１００とＭＦＰ１０１、１０２、１０５の間にゲートウェイ（不図示）が存在し、ゲートウェイはアドレス変換を行う。例えばゲートウェイにはルーターが含まれる。またゲートウェイや、ＭＦＰ１０１、１０２、１０５がファイアウォール機能を備えていてもよい。Ｗｅｂサーバ１０３は、Ｗｅｂコンテンツを、ネットワークを介して配信する機能を持っており、ＭＦＰ１０１からのリクエストに応じてＷｅｂコンテンツを返す。
【００１９】
＜情報処理装置の構成＞
次に、図２を参照して、本実施形態のＭＦＰ１０１のハードウェア構成について説明する。ＭＦＰ１０１は、情報処理装置の一例である。なお、ここでは、ＭＦＰ１０１の構成例について説明するが、ＭＦＰ１０２、１０５についても同様の構成を有する。ＭＦＰ１０１は、ＣＰＵ２０１、ＲＡＭ２０２、読取装置２０３、印刷装置２０４、記憶装置２０５、ユーザ入力装置２０６、ＵＩ表示装置２０７、及びネットワーク装置２０８を備える。
【００２０】
ＣＰＵ２０１は、ＭＦＰ１０１を統括的に制御する。ＲＡＭ２０２は、ＣＰＵ２０１のワークエリアとして使用される。読取装置２０３は、原稿から画像を読み取る。印刷装置２０４は、画像データに従って記録媒体に画像を印刷する。記憶装置２０５は、本発明のプログラムや様々な設定を記憶する（ＨＤＤやＮＶＲＡＭ等でもよい）。ユーザ入力装置２０６は、ユーザがコマンドの入力を行う。ＵＩ表示装置２０７は、基本画面や設定画面等の画面表示を行う。ネットワーク装置２０８は、他機器とネットワークによる通信を行う。これら各装置は、メインバス２００を介して情報を相互に伝達することができる。なお、本実施形態は特に断らない限り、ＣＰＵ２０１が、メインバス２００を介してＲＡＭ２０２、読み取り装置２０３、印刷装置２０４、記憶装置２０５、ユーザ入力装置２０６、ＵＩ表示装置２０７及びネットワーク装置２０８を制御する。また、タッチパネルディスプレイのようにＵＩ表示装置２０７がユーザ入力装置２０６を兼ねてもよい。
【００２１】
＜サーバの構成＞
次に、図３を参照して、本実施形態のサーバ１０３のハードウェア構成について説明する。サーバ１０３は、ＣＰＵ３０１、ＲＡＭ３０２、記憶装置３０３、及びネットワーク装置３０４を備える。ＣＰＵ３０１は、サーバ１０３を統括的に制御する。ＲＡＭ３０２は、ＣＰＵ３０１のワークエリアを提供する。記憶装置３０３は、本発明のプログラム、設定を記憶する。ネットワーク装置３０４は、他機器とネットワークによる通信を行う。これら各装置は、メインバス３００を介して情報を相互に伝達することができる。なお、本実施形態は特に断らない限り、ＣＰＵ３０１がメインバス３００を介してＲＡＭ３０２、記憶装置３０３、及びネットワーク装置３０４を制御する。
【００２２】
＜情報処理システムの制御構成＞
次に、図４を参照して、本実施形態における情報処理システム全体におけるソフトウェア構成について説明する。図４に示す各機能部は、ＭＦＰ１０１／サーバ１０３のそれぞれが有しているＣＰＵ２０１／ＣＰＵ３０１が制御プログラムを実行することにより実現される。
【００２３】
サーバ１０３は、Ｗｅｂアプリケーション４１０及び通信部４０１を有する。さらに、Ｗｅｂアプリケーション４１０には、プレゼンテーション部４１１及びロジック部４１２が含まれる。プレゼンテーション部４１１は、通信部４０１を介して、ＭＦＰ１０１からのリクエストに応じてＭＦＰ１０１のＷｅｂブラウザ４２０で表示すべき操作画面、又はサービスプロバイダ４４０への処理要求を、ＭＦＰ１０１にレスポンスとして送信する。また、ＭＦＰ１０１のＷｅｂブラウザ４２０に表示された操作画面を介して入力されたユーザからの入力情報を、通信部４０１を介してＭＦＰ１０１から受け取る。ロジック部４１２は、プレゼンテーション部４１１から渡されたＭＦＰ１０１からの入力情報に対する処理を行う。例えば、ユーザからの入力に応じて、表示すべき画面を変更したり、ＭＦＰのデバイス機能実行のための処理要求を作成したりする。
【００２４】
通信部４０１は、ネットワーク装置３０４を制御してＨＴＴＰプロトコルにより通信を行うソフトウェアモジュールである。ＭＦＰ１０１は、Ｗｅｂブラウザ４２０、転送アプリケーション４３０、及びサービスプロバイダ４４０を有している。Ｗｅｂブラウザ４２０、転送アプリケーション４３０、サービスプロバイダ４４０のそれぞれは、ＭＦＰ１０１が有しているＣＰＵ２０１が制御プログラムを実行することにより実現される。なお、Ｗｅｂブラウザ４２０は、サーバ１０３のコンテンツを表示するものに限定するものではない。同様に、サーバ１０３もＨＴＴＰプロトコルに従ってリクエスト／レスポンスを送受信するＷｅｂサーバに限定するものではない。Ｗｅｂブラウザ４２０は、任意のサーバと通信を行うことによってコンテンツを取得し、画面に表示するといった機能を有するものであればよい。
【００２５】
Ｗｅｂブラウザ４２０は、通信部４２１、解析部４２２、画面表示部４２３、転送アプリ起動部４２４、及びアップロード処理部４２５を有する。通信部４２１は、ＨＴＴＰプロトコルに従って、サーバ１０３の通信部４０１を介してＷｅｂアプリケーション４１０のプレゼンテーション部４１１と通信する。より具体的には、通信部４２１は、Ｗｅｂブラウザ４２０で表示した操作画面を介して入力される情報をＷｅｂアプリケーション４１０に対するリクエストとして送信する。また、通信部４２１は、Ｗｅｂアプリケーション４１０から送信されるレスポンスを受信する。
【００２６】
解析部４２２は、Ｗｅｂアプリケーション４１０から受信したレスポンスを解析する。レスポンスの中にはＷｅｂブラウザ４２０に表示すべき操作画面の内容を示す記述であるＨＴＭＬデータや、サービスプロバイダへの処理要求が記載されている。解析部４２２はＨＴＴＰレスポンスヘッダのＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドがａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．Ｗｅｂｓｅｒｖｉｃｅと一致するかどうか確認する。一致する場合は転送アプリ起動部４２４に受信したレスポンスに対する処理を依頼する。
【００２７】
画面表示部４２３は、解析部４２２による解析結果に基づいて、ＨＴＭＬデータを用いてＵＩ表示装置２０７に操作画面を表示する。転送アプリ起動部４２４は、解析部４２２による解析結果に基づいて、Ｗｅｂアプリケーション４１０から受信したレスポンスを処理要求とみなして、転送アプリケーション４３０に対し、転送するように依頼する。なお、レスポンスが本発明におけるＭＦＰ１０１への処理要求であるかどうかの判別が可能であれば、ＨＴＴＰレスポンスヘッダを参照する以外の方法でもよい。アップロード処理部４２５は、デバイス内部からの要求に応じて、指定されたデータを、通信部４２１を介してサーバ１０３に送信する。本実施形態ではＨＴＴＰ ＰＯＳＴコマンドを用いて指定のデータをアップロードするが、Ｗｅｂブラウザ４２０が処理可能なプロトコルであれば何でもよい。
【００２８】
転送アプリケーション４３０は、通信部４３１、判断部４３２、及び処理部４３３を有する。通信部４３１は、処理部４３３から依頼を受け、ＭＦＰ１０１、１０２のサービスプロバイダ４４０の通信部４４１に処理要求を転送し、処理要求に対する結果を受信する。判断部４３２は、処理部４３３からの要求に従って、ＳＯＡＰリクエストをどこに転送するか、転送が必要かどうかを判断する。また、通信部４３１を介して処理部４３３がＳＯＡＰレスポンスを受信した際に、処理部４３３の要求に従って、ＳＯＡＰリクエストの転送が必要かどうかを判断する。処理部４３３は、Ｗｅｂブラウザ４２０の転送アプリ起動部４２４からの依頼を受け、サービスプロバイダへの処理要求を、通信部４３１を介して転送する。このときＷｅｂアプリケーション４１０から受信したレスポンスのヘッダに記載されている、後述する宛先７０１に転送を行う。宛先７０１は、ＭＦＰ１０１自身でもよいし、ＭＦＰ１０２でもよい。
【００２９】
転送アプリケーション４３０は、一般的にＷＥＢブラウザで対応できない形式のファイル（音声や動画，アニメーションなど）を処理できるようにするヘルパーアプリケーションとして動作し、Ｗｅｂブラウザと独立して動作する。しかしながら、処理要求の転送を行う機能を有すれば、転送アプリケーション４３０は、ヘルパーアプリケーションではなく、プラグインや、Ｗｅｂブラウザ内の一機能、又は受信したレスポンス内に記載されたＪａｖａＳｃｒｉｐｔとして存在してもよい。
【００３０】
サービスプロバイダ４４０は、通信部４４１、及びジョブ生成部４４２を有する。通信部４４１は、転送アプリケーション４３０から処理依頼を受け付ける。ジョブ生成部４４２は、通信部４４１が受け付けた処理依頼を受け取り、依頼された処理を実行するためのジョブを生成して実行する。
【００３１】
＜シーケンス＞
次に、図５を参照して、本実施形態における情報処理システムの一連の処理を示したシーケンスについて説明する。本シーケンス図にて順に情報処理システムで実施される処理の詳細説明を行う。本シーケンス図で表される処理は、プルファックス（ファクシミリジョブ）の代行処理である。まず、ユーザがＭＦＰ１０１のユーザ入力装置２０６から、Ｗｅｂブラウザの起動を行うためのボタン（不図示）押下を受けると、Ｗｅｂブラウザ４２０を起動する。上記ボタンは、ハードウェアボタンに限ったものではなく、タッチパネル上に表示されたソフトウェアボタンであってもよい。Ｗｅｂブラウザ４２０は、起動するとサーバ１０３上のＷｅｂアプリケーション４１０に設定画面のリクエストを行う。本実施形態では、設定画面のコンテンツを示すＵＲＬが予めＭＦＰ１０１に設定されているものとする。
【００３２】
まず、Ｓ５０１では、Ｗｅｂブラウザ４２０は、ＵＲＬで示されるコンテンツを保持するＷｅｂアプリケーション４１０に対して、ＨＴＴＰのＧＥＴコマンドによるリクエストを行う。具体的には、Ｗｅｂブラウザ４２０が通信部４２１を介してＨＴＴＰプロトコルによりサーバ１０３の通信部４０１と通信を行う。通信部４０１は受け取ったＵＲＬに応じて、適切なＷｅｂアプリケーションに受け取ったデータを渡す。これにより、Ｗｅｂブラウザ４２０からＷｅｂアプリケーション４１０へのリクエストが行われる。以下、通信部４０１と通信部４２１の動作は省略して説明する。
【００３３】
Ｓ５０２では、Ｗｅｂアプリケーション４１０のプレゼンテーション部４１１が、Ｓ５０１のリクエストに応じて、設定画面のＨＴＭＬデータを作成し、ＨＴＴＰのレスポンスとして、作成したＨＴＭＬデータをＷｅｂブラウザに送信する。Ｗｅｂブラウザ４２０は、受け取ったＨＴＭＬデータを解析し、ＵＩ表示装置２０７に設定画面を表示する。
【００３４】
Ｓ５０３では、Ｗｅｂブラウザ４２０は、Ｗｅｂアプリケーション４１０に対して、処理の実行を指示する。ユーザによってＳ５０２で表示された設定画面のボタンが押されると、Ｗｅｂブラウザ４２０は、設定画面で設定されたパラメータをＷｅｂアプリケーション４１０に通知する。通信にはＨＴＴＰプロトコルのＰＯＳＴコマンドを利用する。
【００３５】
Ｓ５０４では、Ｗｅｂアプリケーション４１０のロジック部４１２がＳ５０３で送信された情報に基づき、ＨＴＴＰレスポンスヘッダ７００と、ＨＴＴＰレスポンスボディとして、後述する処理要求８００を生成する。そして、ＨＴＴＰレスポンスヘッダと、ＨＴＴＰレスポンスボディを合わせてＨＴＴＰレスポンス（ＳＯＡＰリクエスト）としてＷｅｂブラウザ４２０に送信する。Ｗｅｂブラウザ４２０は、Ｗｅｂアプリケーション４１０が送信したＨＴＴＰレスポンスを受信する。このＨＴＴＰレスポンスには、ＨＴＴＰレスポンスヘッダ７００と、処理要求８００が含まれる。これらの詳細については図８を用いて後述する。
【００３６】
Ｓ５０５では、解析部４２２は、Ｓ５０４で受信したＨＴＴＰレスポンスヘッダのＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドがａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．Ｗｅｂｓｅｒｖｉｃｅと一致するか確認する。一致する場合は、転送アプリ起動部４２４が、転送アプリケーション４３０の処理部４３３に対して、Ｓ５０４で受信したＨＴＴＰレスポンスボディを送信し、サービスプロバイダ４４０に転送するように依頼する。このとき、転送に必要な情報として、Ｓ５０４で受信したＨＴＴＰレスポンスヘッダを転送アプリケーション４３０に渡す。Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールドがａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．Ｗｅｂｓｅｒｖｉｃｅと一致しない場合は、解析部４２２は、ＨＴＭＬデータの解析結果に基づいて、ＵＩ表示装置２０７に操作画面を表示する。
【００３７】
Ｓ５０６では、転送アプリケーション４３０の判断部４３２が、Ｓ５０５で受信した情報に基づき、ＨＴＴＰレスポンスボディの転送先を判断する。本実施形態ではＳ５０５で受信したＨＴＴＰレスポンスヘッダに記載されている宛先７０１を転送先アドレスとする。これはＷｅｂアプリケーション４１０が指定するものとは限らない。例えば、ユーザがＷｅｂブラウザ４２０を介して入力した情報であったり、或いは、Ｗｅｂアプリケーションは転送処理だけを指示し、転送先はＭＦＰ１０１に予め設定されていてもよい。また、デバイスの構成や状態に応じて動的に転送先を変更してもよい。さらには、転送アプリケーション４３０は、転送先の情報処理装置の性能に合わせて、Ｓ５０５で受信したＨＴＴＰレスポンスを当該転送先の情報処理装置で実行可能な処理要求に書き換えてもよい。例えば、ＨＴＴＰレスポンスに含まれる処理要求８００のプルファックス要求８０１には、スキャンサイズ８０４が含まれるが、情報処理装置（ＭＦＰ）の性能によっては利用できるスキャンサイズに制限がある。そこで、処理部４３３（ＣＰＵ２０１）は、書換手段として機能し、転送先の情報処理装置で動作させることが可能な設定に書き換えることが考えられる。本実施形態では、スキャンサイズ８０４は、ＩＳＯ＿Ａ３が指定されているが、ＩＳＯ＿Ａ４とすることで、多くの情報処理装置で処理可能となる。どのように情報を書き換えるかの条件とその値は、Ｗｅｂアプリケーションから指示してもよいし、予め情報処理装置内に設定しておいてもよい。また、転送先の情報処理装置から情報処理装置の性能を取得して判断してもよい。
【００３８】
Ｓ５０７では、転送アプリケーション４３０の処理部４３３は、Ｓ５０６で決定した宛先に対して、Ｓ５０５で受信したＨＴＴＰレスポンスボディを、通信部４３１を介して送信する。本実施形態ではＨＴＴＰ ＰＯＳＴコマンドを用いて、ＭＦＰ１０２のサービスプロバイダ４４０に対して送信するが、送信方法は他の方法でもよい。
【００３９】
Ｓ５０８では、ＭＦＰ１０２のサービスプロバイダ４４０は、Ｓ５０７で転送アプリケーション４３０が送信した処理要求８００を通信部４４１で受信し、処理要求８００に従ってジョブ生成部４４２でジョブを生成し、実行する。処理要求８００にはプルファックス要求８０１が含まれており、ＭＦＰ１０２はプルファックス要求８０１に従って、ファックス送信するドキュメントを取得先８０３から取得し、ファックス送信を実行する。
【００４０】
Ｓ５０９では、ＭＦＰ１０２のサービスプロバイダ４４０は、処理結果８１０を、Ｓ５０７で受信したリクエストのレスポンスとして、通信部４４１を介して、ＭＦＰ１０１の転送アプリケーション４３０に対して送信する。そして、転送アプリケーション４３０の処理部４３３は、処理結果８１０を、通信部４３１を介して受信する。
【００４１】
Ｓ５１０では、転送アプリケーション４３０の処理部４３３は、Ｗｅｂブラウザ４２０のアップロード処理部４２５に対して、処理結果８１０をＷｅｂアプリケーション４１０に対してアップロードするように依頼する。依頼に際して、処理部４３３は、アップロード処理部４２５に対してアップロードの宛先としてアップロード宛先７０３を指定する。アップロード宛先７０３はＨＴＴＰレスポンスヘッダに記載されており、転送アプリケーション４３０からアップロード処理部４２５に指定せず、Ｗｅｂブラウザ４２０がこの情報を記憶しておき、当該情報を使用してもよい。また宛先を固定値とし、Ｗｅｂアプリケーション４１０から指定しないシステムとしてもよい。このとき転送アプリケーション４３０は、処理結果８１０の内容を書き換えてからアップロードを依頼してもよい。処理結果８１０をそのままＷｅｂアプリケーション４１０にアップロードした場合、Ｗｅｂアプリケーション４１０は、処理要求８００が転送されてＭＦＰ１０２で実行されたことを知ることができない。図８の８２０は処理結果８１０を書き換えた例である。ここでは、処理結果８１０に対して、転送結果８２１を挿入している。他にも、転送先のアドレスや、転送時に書き換えられた処理要求の内容など、Ｗｅｂアプリケーション４１０が必要とする情報を記載してもよい。
【００４２】
Ｓ５１１では、アップロード処理部４２５は、通信部４２１を介してＨＴＴＰ ＰＯＳＴコマンドで、処理部４３３からの依頼に従って処理結果８１０をアップロードする。このとき、転送アプリケーション４３０の処理部４３３から依頼された宛先７０３に対してアップロードを行う。Ｓ５１２では、Ｗｅｂアプリケーション４１０は、Ｗｅｂブラウザ４２０に対して、画面表示用のＨＴＭＬデータをレスポンスする。レスポンスを受け取ったＷｅｂブラウザ４２０は、解析部４２２によるＨＴＭＬデータの解析結果に基づいて、ＵＩ表示装置２０７に操作画面を表示する。
【００４３】
＜転送アプリケーションの処理＞
次に、図６を参照して、転送アプリケーション４３０における処理フローについて説明する。Ｓ６０１、Ｓ６０２、Ｓ６０６、Ｓ６０７、及びＳ６０８における処理は、Ｓ５０５からＳ５１０において既に説明しているため、不足部分を補足する形で説明する。
【００４４】
Ｓ６０１では、Ｓ５０５の処理が実行される。Ｓ６０２では、Ｓ５０６の処理が実行される。なお、Ｓ６０２では、ＣＰＵ２０１は、転送判定手段として機能する。このとき、転送先が外部の情報処理装置である場合はＳ６０６へ進む。一方、転送先がＭＦＰ１０１自身である場合はＳ６０３へ進む。Ｓ６０３では、転送アプリケーション４３０の処理部４３３は、Ｓ５０５で受信したＨＴＴＰレスポンスボディを、通信部４３１を介して、ＭＦＰ１０１のサービスプロバイダ４４０に送信する。この宛先は、Ｓ６０２で決定されている。Ｓ６０４では、ＭＦＰ１０１のサービスプロバイダ４４０は、ＳＯＡＰリクエストに対する処理における処理結果８１０を、Ｓ６０３で受信したリクエストのレスポンスとして、通信部４４１を介して、転送アプリケーション４３０に対して送信する。そして、転送アプリケーション４３０の処理部４３３は、処理結果８１０を、通信部４３１を介して受信する。
【００４５】
Ｓ６０５では、転送アプリケーション４３０の判断部４３２が、Ｓ６０４で受信した処理結果８１０に基づき、Ｓ５０５で受信したＨＴＴＰレスポンスボディの転送が必要かどうかを判断する。処理結果８１０には処理結果コード（ＲｅｓｕｌｔＣｏｄｅ）８１１が含まれており、このＲｅｓｕｌｔＣｏｄｅがＯＫであれば、転送の必要はないと判断し、Ｓ６０８へ進む。ＲｅｓｕｌｔＣｏｄｅがＮＧであれば、正常に処理が実行できなかったため転送の必要があると判断し、転送先アドレスを決定し、Ｓ６０６へ進む。また、ＲｅｓｕｌｔＣｏｄｅがＮＧであっても、他の条件に従って転送を実施しない場合があってもよい。転送が必要かどうかの判断はこの方法に限定されるものではなく、例えばＨＴＴＰレスポンスコードに従って判断してもよい。そして、本実施形態ではＳ５０５で受信したＨＴＴＰレスポンスヘッダに記載されている転送宛先７０４を転送先アドレスとする。これはＷｅｂアプリケーション４１０が指定するものとは限らず、ユーザがＷｅｂブラウザ４２０を介して入力した情報であったり、又は、Ｗｅｂアプリケーション４１０は転送処理だけを指示し、転送先はＭＦＰ１０１に予め設定されていたりしてもよい。また、デバイスの構成や状態に応じて動的に転送先を変更してもよい。
【００４６】
Ｓ６０６では、転送アプリケーション４３０の処理部４３３は、Ｓ６０２又はＳ６０５で決定した宛先に対して、Ｓ５０５で受信したＨＴＴＰレスポンスボディを、通信部４３１を介して送信する。本実施形態ではＨＴＴＰ ＰＯＳＴコマンドを用いて、ＭＦＰ１０２のサービスプロバイダ４４０に対して送信するが、送信方法は他の方法でもよい。Ｓ６０７では、Ｓ５０９が実行される。Ｓ６０８では、Ｓ５１０が実行される。
【００４７】
＜ＨＴＴＰレスポンス＞
次に、図７及び図８を参照して、本実施形態におけるＷｅｂアプリケーション４１０がＷｅｂブラウザ４２０に対して通知するＨＴＴＰレスポンスについて説明する。まず、図７を参照して、ＨＴＴＰレスポンスヘッダについて説明する。ＨＴＴＰレスポンスヘッダ７００は、宛先７０１、転送時コンテントタイプ７０２、アップロード宛先７０３、転送宛先７０４、及びコンテントタイプ７０５を有する。
【００４８】
宛先７０１は前述の通り、Ｓ５０７において、転送アプリケーション４３０が処理要求８００であるＨＴＴＰレスポンスボディを転送する際の宛先である。宛先７０１は複数のサービスプロバイダが公開するサービスの何れかを指し示す。転送時コンテントタイプ７０２は、Ｓ５０７において、転送アプリケーション４３０が、サービスプロバイダ４４０にＨＴＴＰレスポンスボディを転送する際にＨＴＴＰヘッダのＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドに記載する内容である。ＨＴＴＰ Ｐｏｓｔコマンドを用いた転送の際に、転送先のサービスプロバイダ４４０が正しく理解できるＣｏｎｔｅｎｔ−Ｔｙｐｅを記載する必要があるためである。転送時コンテントタイプ７０２が省略されている場合は、転送アプリケーションが転送時にデフォルトの値を設定してもよい。
【００４９】
アップロード宛先７０３は前述の通り、Ｓ５１０においてＷｅｂブラウザ４２０が処理結果８１０をＷｅｂアプリケーション４１０にアップロードする際の宛先である。転送宛先７０４は前述の通り、Ｓ６０５において決定される転送先のアドレスである。コンテントタイプ７０５は前述の通り、Ｓ５０５において、Ｓ５０４で受信したＨＴＴＰレスポンスボディの内容が、処理要求か、Ｗｅｂブラウザ４２０に表示するＨＴＭＬコンテンツかの判断に用いる。
【００５０】
次に、図８を参照して、ＨＴＴＰレスポンスについて説明する。８００は、Ｗｅｂアプリケーション４１０が生成し、Ｗｅｂブラウザ４２０にレスポンスとして返す処理要求の内容を示す。処理要求８００は、プルファックス要求８０１を有し、Ｓ５０４でＷｅｂブラウザ４２０が受信するレスポンスボディに含まれる。処理要求８００は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  ＬａＮＧｕａｇｅ）フォーマットで記載されているが、ＭＦＰ１０１に対する処理が記載できて、ＭＦＰ１０１が処理できる形式であれば何れの言語で記載されてもよい。
【００５１】
プルファックス要求８０１は、ＭＦＰ１０１に対してプルファックス処理の実行を要求する命令である。また、プルファックス要求８０１には、ファックス送信の制御に関わる設定値を記載することができる。例えば、ファックス番号８０２や、ファックス送信するドキュメントの取得先８０３、及びスキャンサイズ８０４が設定できる。
【００５２】
８１０は、サービスプロバイダ４４０が生成し、転送アプリケーション４３０にレスポンスとして返す処理結果の内容を示す図である。処理結果８１０は、処理結果コード８１１と転送結果８２１を有する。処理結果８１０は処理要求と同様に、ＸＭＬフォーマットで記載されているが、他の形式であってもよい。処理結果コード８１１には、サービスプロバイダ４４０で生成され実行されたジョブの処理結果コードが記載されている。この処理結果コードを参照することで、転送アプリケーション４３０は、サービスプロバイダ４４０がジョブの実行に成功したか失敗したかが分かる。また、Ｗｅｂアプリケーション４１０は、この処理結果８１０をＷｅｂブラウザ４２０のアップロードによって受信することで、ユーザに対して処理結果に応じたＨＴＭＬコンテンツを生成し、Ｗｅｂブラウザ４２０に送信することができる。サービスプロバイダがジョブの実行に成功した場合、処理結果コード８１１にはＯＫが記載され、失敗した場合は、ＮＧや、エラーコードが記載される。転送結果８２１は、転送アプリケーション４３０が転送処理を行ったかどうかが記載されている。
【００５３】
８２０は、転送アプリケーション４３０が処理結果８１０を書き換えた結果を示す図である。書き換え後処理結果８２０は、転送結果８２１を有する。転送結果８２１は、転送アプリケーション４３０によって挿入され、Ｗｅｂアプリケーション４１０に転送処理の内容を通知するために利用する。例えば、転送が実行されたかどうか、転送先のアドレス、転送する際に書き換えられた処理要求の内容などが記載される。
【００５４】
以上説明したように、本実施形態では、ＭＦＰ１０１はＷｅｂアプリケーション４１０から、Ｗｅｂブラウザ４２０への応答として処理要求を受信し、他のデバイス（ＭＦＰ１０２）へジョブを転送することができる。また、その処理要求に対する結果をＷｅｂブラウザ４２０からＷｅｂアプリケーション４１０にアップロードする。よって、Ｗｅｂアプリケーション４１０は、ユーザが操作しているＭＦＰ１０１以外のＭＦＰ１０２にジョブを投入し、代行処理をさせることが可能になり、また、ユーザ操作の介在無しに他のＭＦＰ１０２で処理が実行できるため、代行処理時のユーザの手間を省くことができる。そして、ジョブの実行結果をＷｅｂアプリケーション４１０が知ることができるため、Ｗｅｂアプリケーション４１０によってユーザに対して代行処理時の処理結果の通知を行うことが可能となる。
【００５５】
＜変形例＞
第１の実施形態では、Ｗｅｂアプリケーション４１０の指示、又は、ＭＦＰ１０１内に存在する情報に従って転送アプリケーション４３０が転送処理を実行する。そのため、システムを利用するユーザが意図せず処理要求８００が転送されてしまうことが考えられる。そこで、転送アプリケーション４３０は、異なるＭＦＰ１０２に処理要求８００を転送する際に、転送確認画面９００をユーザに提示し、転送してよいかどうかをユーザに確認してもよい。
【００５６】
図９は、転送確認画面の一例を示す。転送確認画面９００には、転送宛先提示部９０１と、確認ボタン９０２と、キャンセルボタンが含まれる。転送宛先提示部９０１には、処理要求８００を転送する宛先が記載されており、ユーザはこの宛先を見て転送するかどうかを決定する。宛先の記載方法は、対象となる情報処理装置（ＭＦＰ１０２）の愛称やＩＰアドレスなど、ユーザがその情報処理装置を識別できる情報であればよい。また、本実施形態においては、宛先は１つのみ表示しているが、複数の宛先を提示し、ユーザに選択させてもよい。また、対象となるデバイスの能力を表示するなどして、ユーザの判断を補助するような機能があってもよい。確認ボタン９０２が押下されると、転送をが実行される。一方、キャンセルボタン９０３が押下されると、転送がキャンセルされ、代行処理を実行せずジョブの処理を終了する。このように、転送確認画面９００をユーザに提示することで、ユーザの意図しない転送を防ぐことができる。
【００５７】
＜第２の実施形態＞
＜情報処理システムの制御構成＞
以下では、本発明の第２の実施形態について説明する。なお、上記第１の実施形態と同様の構成及び制御については説明を省略する。また、同一の構成については同一の参照符号を付す。図１０は、本実施形態における情報処理システム全体のソフトウェア構成を示す。図１０に示す各機能部は、ＭＦＰ１０１／ＭＦＰ１０２／サーバ１０３のそれぞれが有しているＣＰＵ２０１／ＣＰＵ３０１が制御プログラムを実行することにより実現される。本実施形態においては、上記第１の実施形態と異なり、ＭＦＰ１０２がＭＦＰ１０１と同じ構成を有する。この点のみが異なり、他の構成は上記第１の実施形態と同様である。従って、サーバ１０３及びＭＦＰ１０１（ＭＦＰ１０２）の構成は、上記第１の実施形態で図４を用いて説明した構成と同様であるため説明を省略する。図１０に示すように、本実施形態によれば、ＭＦＰ１０２がＭＦＰ１０１と同様の構成を有するため、ＭＦＰ１０２の通信部４２１と、サーバ１０３の通信部４０１との間で通信を行うことができる。  
【００５８】
＜シーケンス＞
次に、図１１を参照して、本実施形態における情報処理システムの一連の処理を示したシーケンスについて説明する。本シーケンス図で表される処理は、プルプリントの代行処理である。なお、Ｓ５０１乃至Ｓ５０６の処理は、図５と同様であるため説明を省略する。したがって、以下では、Ｓ５０６に続いて行われるＳ１１０１乃至１１０９の処理について説明する。
【００５９】
Ｓ１１０１では、ＭＦＰ１０１の転送アプリケーション４３０の処理部４３３は、Ｓ５０６で決定した宛先に対して、ＨＴＴＰリクエスト１４００を、通信部４３１を介して送信する。本実施形態ではＨＴＴＰ ＰＯＳＴコマンドを用いて、ＭＦＰ１０２の転送アプリケーション４３０に対して送信するが、送信方法は他の方法でもよい。ＨＴＴＰリクエスト１４００は、Ｓ５０５で受信したＨＴＴＰレスポンスボディに、ユーザ情報とセッション情報を付加したメッセージである。より具体的には、メッセージをマルチパートで扱うための識別情報１００１を定め、Ｓ５０５で受信したＨＴＴＰレスポンスボディをパート１００２に格納する。同様にセッション情報をパート１００３に、ユーザ情報をパート１００４に格納する。格納するパートの順番は、本実施形態に限定されるものではない。また、セッション情報は文字列化されていてもよく、データ形式を本実施形態に限定するものではない。ユーザ情報もドメイン情報をさらに別パートに分離していてもよく、送信される情報としてこれらが格納されているのであれば、データ形式として本実施形態に限定されるものではない。
【００６０】
Ｓ１１０２では、ＭＦＰ１０２の転送アプリケーション４３０の処理部４３３は、Ｓ１１０１で受信したＨＴＴＰリクエスト１４００から、Ｓ５０５で受信したＨＴＴＰレスポンスボディ部を抽出する。そして、ＭＦＰ１０２のサービスプロバイダ４４０に処理要求８００を、通信部４３１を介して送信する。
【００６１】
Ｓ１１０３では、ＭＦＰ１０２のサービスプロバイダ４４０は、Ｓ１１０２で転送アプリケーション４３０が送信した処理要求８００を通信部４４１で受信し、処理要求８００に従ってジョブ生成部４４２でジョブを生成し、実行する。処理要求８００にはプルプリント要求が含まれており、ＭＦＰ１０２はプルプリント要求に従って、印刷するドキュメントを取得先から取得し、印刷を実行する。ここでの、処理要求は、上記第１の実施形態において説明した図８の処理要求８００とほぼ同様であり、プルファックス要求８０１の内容がプルプリント要求に変化するのみである。具体的には、プルプリント要求には、少なくとも印刷するドキュメントの取得先と、プリントサイズ（ＩＳＯ＿Ａ３等）とが含まれる。また、図８の＜ＰｕｌｌＦａｘ＞のタグが＜ＰｕｌｌＰｒｉｎｔ＞のタグに変更となる。以下では、図８の処理要求８００及び処理結果８１０、８２０を参照して説明する。
【００６２】
Ｓ１１０４では、ＭＦＰ１０２のサービスプロバイダ４４０は、処理結果８１０を、Ｓ１１０２で受信したＨＴＴＰリクエストのレスポンスとして、通信部４４１を介して、ＭＦＰ１０２の転送アプリケーション４３０に対して送信する。そして、転送アプリケーション４３０の処理部４３３は、処理結果８１０を、通信部４３１を介して受信する。
【００６３】
Ｓ１１０５では、ＭＦＰ１０１を操作していた操作者が、ＭＦＰ１０２の操作を始めることを待つ。本実施形態では、ＭＦＰ１０２に対するログイン操作を待つものとする。より具体的には、ユーザ入力装置２０６、或いはＵＩ表示装置２０７から操作者が操作者自身を特定する情報を入力し、不図示の一般的な認証方法等によりＭＦＰ１０２の使用を開始する操作を待つ。入力された情報は、ＭＦＰ１０２の転送アプリケーション４３０に通知され、Ｓ１１０１で受信したＨＴＴＰリクエスト１４００のパート１００４からユーザ情報と比較され、一致した場合にＳ１１０６に進む。尚、一致しなかった場合はＭＦＰ１０２を別の操作者が操作していると判断し、不図示の通常の処理を継続することはいうまでもない。なお、操作者の操作開始を待つタイミングとして、本実施形態ではこのタイミングで行っているが、Ｓ１１０１の直後であってもよい。また、Ｓ１１０１で受信したＨＴＴＰリクエスト１４００の処理内容に従い待つタイミングを変えるように構成してもよい。
【００６４】
Ｓ１１０６では、転送アプリケーション４３０の処理部４３３は、Ｗｅｂブラウザ４２０のアップロード処理部４２５に対して、処理結果８１０をＷｅｂアプリケーション４１０に対してアップロードするように依頼する。その際、Ｓ１１０１で受信したＨＴＴＰリクエスト１４００のパート１００３からセッション情報を抽出し、処理結果８１０と共にＷｅｂブラウザ４２０に送信する。また、処理部４３３は、アップロード処理部４２５に対してアップロードの宛先としてアップロード宛先７０３を指定する。このとき転送アプリケーション４３０は、処理結果８１０の内容を書き換えてからアップロード依頼をしてもよい。処理結果８１０をそのままＷｅｂアプリケーション４１０にアップロードした場合、Ｗｅｂアプリケーション４１０は、処理要求８００が転送されてＭＦＰ１０２で実行されたことを知ることができない。図８の８２０は処理結果８１０を書き換えた例である。ここでは、処理結果８１０に対して、転送結果８２１を挿入している。他にも、転送先のアドレスや、転送時に書き換えられた処理要求の内容など、Ｗｅｂアプリケーション４１０が必要とする情報を記載してもよい。
【００６５】
Ｓ１１０７では、アップロード処理部４２５は、通信部４２１を介してＨＴＴＰ ＰＯＳＴコマンドで、処理部４３３からの依頼に従って処理結果８１０をアップロードする。このとき、転送アプリケーション４３０の処理部４３３から依頼された宛先に対して、Ｓ１１０６で抽出したセッション情報を使い、アップロードを行う。
【００６６】
Ｓ１１０８では、Ｗｅｂアプリケーション４１０はＷｅｂブラウザ４２０に対して、セッション情報と処理結果８１０に基づく所定の画面表示用のＨＴＭＬコンテンツをレスポンスする。レスポンスを受け取ったＷｅｂブラウザ４２０は、解析部４２２によるＨＴＭＬデータの解析結果に基づいて、ＵＩ表示装置２０７に操作画面を表示する。Ｓ１１０９では、Ｓ１１０８に引き続き捜査を行うための画面を要求するリクエストを送信する。
【００６７】
＜転送アプリケーションの処理＞
次に、図１２を参照して、ＭＦＰ１０１の転送アプリケーション４３０における処理フローについて説明する。Ｓ１２０１、Ｓ１２０２、Ｓ１２０６、Ｓ１２０７、Ｓ１２０８における処理は、Ｓ５０５からＳ１１０１において既に説明しているため、不足部分を補足する形で説明する。
【００６８】
Ｓ１２０１では、Ｓ５０５の処理が実行される。Ｓ１２０２では、Ｓ５０６の処理が実行される。このとき、転送先が外部の情報処理装置である場合はＳ１２０７へ進む。転送先がＭＦＰ１０１自身である場合はＳ１２０３へ進む。Ｓ１２０３では、転送アプリケーション４３０の処理部４３３は、Ｓ５０５で受信したＨＴＴＰレスポンスボディを、通信部４３１を介して、ＭＦＰ１０１のサービスプロバイダ４４０に送信する。この宛先は、Ｓ５０６で決定されている。Ｓ１２０４では、ＭＦＰ１０１のサービスプロバイダ４４０は、処理結果８１０を、Ｓ１２０３で受信したリクエストのレスポンスとして、通信部４４１を介して、転送アプリケーション４３０に対して送信する。そして、転送アプリケーション４３０の処理部４３３は、処理結果８１０を、通信部４３１を介して受信する。
【００６９】
Ｓ１２０５では、転送アプリケーション４３０の判断部４３２が、Ｓ１２０４で受信した処理結果８１０を元にＳ５０５で受信したＨＴＴＰレスポンスボディの転送が必要かどうかを判断する。処理結果８１０には処理結果コード８１１が含まれており、このＲｅｓｕｌｔＣｏｄｅがＯＫであれば、転送の必要はないと判断し、Ｓ１２０６へ進む。ＲｅｓｕｌｔＣｏｄｅがＮＧであれば、転送の必要があると判断し、転送先アドレスを決定し、Ｓ１２０７へ進む。また、ＲｅｓｕｌｔＣｏｄｅがＮＧであっても、他の条件に従って転送を実施しない場合があってもよい。転送が必要かどうかの判断はこの方法に限定されるものではなく、例えばＨＴＴＰレスポンスコードを元に判断を行ってもよい。そして、本実施形態ではＳ５０５で受信したＨＴＴＰレスポンスヘッダに記載されている転送宛先を転送先アドレスとする。これはＷｅｂアプリケーションが指定するものとは限らず、ユーザがＷｅｂブラウザ４２０を介して入力した情報であったり、又は、Ｗｅｂアプリケーション４１０は転送処理だけを指示し、転送先はＭＦＰ１０１に予め設定されていたりしてもよい。また、デバイスの構成や状態に応じて動的に転送先を変更してもよい。Ｓ１２０６では、アップロード処理部４２５は、通信部４２１を介してＨＴＴＰ ＰＯＳＴコマンドで、処理部４３３からの依頼に従って処理結果８１０をアップロードし、処理を終了する。
【００７０】
Ｓ１２０２でリクエストが転送条件にあてはまると判定されると、Ｓ１２０７に進む。Ｓ１２０７では、Ｓ１１０１のパート１００３、パート１００４を作成するステップである。Ｓ１２０８では、Ｓ５０５で受信したＨＴＴＰレスポンスボディをマルチパート化し、Ｓ１２０７で作成したパート１００３、パート１００４を追加し、ＨＴＴＰリクエスト１４００を作成するステップである。Ｓ１２０９では、転送アプリケーション４３０の処理部４３３は、Ｓ１２０２又はＳ１２０５で決定した宛先に対して、Ｓ１２０８で作成したＨＴＴＰリクエスト１４００を、通信部４３１を介して送信する。本実施形態ではＨＴＴＰ ＰＯＳＴコマンドを用いて、ＭＦＰ１０２のサービスプロバイダ４４０に対して送信するが、送信方法は他の方法でもよい。Ｓ１２１０では、操作者をＭＦＰ１０２に向かわせるための不図示のポップアップを表示するステップである。操作者は、本メッセージ確認後ＭＦＰ１０１の操作を完了しＭＦＰ１０２に向かう。
【００７１】
図１３は、ＭＦＰ１０２の転送アプリケーション４３０における処理フローの詳細を示す。Ｓ１３０１からＳ１３０７における処理は、Ｓ１１０２からＳ１１０９において既に説明しているため、不足部分を補足する形で説明する。
【００７２】
Ｓ１３０１では、ＭＦＰ１０２の転送アプリケーション４３０は、Ｓ１２０９でＭＦＰ１０１の転送アプリケーション４３０から送信されたＨＴＴＰリクエスト１４００を受信する。Ｓ１３０２では、ＭＦＰ１０２の転送アプリケーション４３０Ｓ１３０１で受信したＨＴＴＰリクエスト１４００から、Ｓ５０５で受信したオリジナルのＨＴＴＰリクエストである、パート１００２を抽出する。Ｓ１３０３では、ＭＦＰ１０２の転送アプリケーション４３０Ｓ１３０２で抽出したパート１００２のＨＴＴＰレスポンスボディを、ＭＦＰ１０２のサービスプロバイダ４４０に対して、通信部４３１を介して送信する。本実施形態ではＨＴＴＰ  ＰＯＳＴコマンドを用いて送信するが、送信方法は他の方法でもよい。Ｓ１３０４では、ＭＦＰ１０２の転送アプリケーション４３０Ｓ５０４の処理結果８１０を、通信部４３１を介して受信する。
【００７３】
Ｓ１３０５では、Ｓ１１０５の処理が実行される。ユーザ入力装置２０６、或いはＵＩ表示装置２０７から、操作者が操作者自信を特定する情報を入力する、いわゆるログインを待つ。また、入力されたユーザ情報とＳ１１０１で受信したＨＴＴＰリクエスト１４００のパート１００４のユーザ情報を比較し、一致する場合はＳ１３０６に進む。なお、操作者の操作開始を待つタイミングとして、本実施形態ではこのタイミングで行っているが、Ｓ１３０２の直後であってもよい。また、Ｓ１３０１で受信したＨＴＴＰリクエスト１４００の処理内容に従い待つタイミングを変えるように構成してもよい。Ｓ１３０６では、Ｓ１３０４で受信した処理結果８１０に、Ｓ１１０１で受信したＨＴＴＰリクエスト１４００のセッション情報を加える。Ｓ１３０７では、Ｓ１３０６で作成したＨＴＴＰレスポンスを、通信部４３１を介してＭＦＰ１０２のＷｅｂブラウザ４２０に送信する。なお、本実施形態では、操作者がＭＦＰ１０２にログインする前に、サービスプロバイダ４４０に処理を実行させているが、サービスプロバイダ４４０に指示する処理の内容によっては、Ｓ１３０５のログインの後で転送するようにしてもよい。
【００７４】
＜処理要求の内容＞
次に、図１４を参照して、転送アプリケーション４３０が、Ｓ１１０１でＭＦＰ１０２に処理を転送する際の処理要求の内容について説明する。なお、本実施形態におけるＨＴＴＰレスポンスヘッダ及びＨＴＴＰレスポンスは、図７及び図８を用いて説明した構成とほぼ同様であるため、説明を省略する。なお、図８の処理要求８００及び処理結果８１０、８２０との差異については上述したため説明を省略する。
【００７５】
処理要求１４００は、複数の情報をパート毎に格納するための識別情報１４０１を有し、処理要求８００の内容、Ｗｅｂアプリケーション４１０とＷｅｂブラウザ４２０の通信を識別するセッション情報、及び操作しているユーザを識別する情報を有する。処理要求１４００はＸＭＬフォーマットで記載されているが、ＭＦＰ１０２に対する処理が記載できて、ＭＦＰ１０２が処理できる形式であれば何でもよい。
【００７６】
パート１４０２は、プルプリント要求を有し、Ｓ５０４でＷｅｂブラウザ４２０が受信するレスポンスボディが含まれる。パート１４０３は、Ｗｅｂアプリケーション４１０とＷｅｂブラウザ４２０の通信を識別するセッション情報が含まれる。パート１４０４は、ＭＦＰ１０１を操作しているユーザの識別情報が含まれる。各パートの区切りは識別情報１４０１により行われる。
【００７７】
格納するパートの順番は、本実施形態に限定されるものではない。また、パート１４０３のセッション情報は文字列化されていてもよく、データ形式を本実施形態に限定するものではない。パート１４０４のユーザ情報もドメイン情報をさらに別パートに分離していてもよく、送信される情報としてこれらが格納されているのであれば、データ形式として本実施形態に限定されるものではない。
【００７８】
以上説明したように、本発明では、ＭＦＰ１０１はＷｅｂアプリケーション４１０から、Ｗｅｂブラウザ４２０への応答として処理要求を受信し、他のデバイスへ転送することができる。また、その処理要求に対する結果を転送先のＷｅｂブラウザ４２０からＷｅｂアプリケーション４１０に同じセッション情報を使いアップロードする。よって、Ｗｅｂアプリケーション４１０は、ユーザが操作しているＭＦＰ以外のＭＦＰ１０２にジョブを投入し、代行処理をさせることが可能になる。また、ユーザは代行先のＭＦＰ１０２でログインするだけで作業が継続できるようになる。そして、ジョブの実行結果をＷｅｂアプリケーション４１０はＭＦＰの区別なく知ることができるため、Ｗｅｂアプリケーション４１０はユーザに対して継続した作業を提供することが可能となる。
【００７９】
＜変形例＞
第２の実施形態では、Ｗｅｂアプリケーション４１０の指示、又は、ＭＦＰ１０１内に存在する情報に従って転送アプリケーション４３０が転送処理を実行する。そのため、システムを利用するユーザが意図せず処理要求１４００が転送されてしまことが考えられる。そこで、転送アプリケーション４３０は、異なるＭＦＰ１０２に処理要求１４００を転送する際に、転送確認画面９００と同様の転送確認画面をユーザに提示し、転送してよいかどうかをユーザに確認してもよい。
【００８０】
＜第３の実施形態＞
以下では、本発明の第３の実施形態について説明する。なお、上記第１及び第２の実施形態と同様の構成及び制御については説明を省略する。また、同一の構成については同一の参照符号を付す。図１５は、本実施形態における情報処理システム全体のソフトウェア構成を示す。図１５に示す構成は、上記第１の実施形態で説明した構成に加えて、ＭＦＰ１０１が変換アプリケーション４５０をさらに備える。さらに、ＭＦＰ１０５の構成についても新たに説明する。他の構成については、図４の構成と同様であるため説明を省略する。
【００８１】
通信部４３１は、処理部４３３から依頼を受け、ＭＦＰ１０１、１０２のサービスプロバイダ４４０の通信部４４１、又は変換アプリケーション４５０の通信部４５１に処理要求を転送し、処理要求に対する結果を受信する。変換アプリケーション４５０は、サービスプロバイダを搭載しないＭＦＰ１０５で処理要求を実行するためのアプリケーションである。本実施形態では変換アプリケーション４５０は転送先情報処理装置の制御コマンド種別毎に用意される。個々の変換アプリケーションは、通信部４５１、リクエスト解析部４５２、外部デバイス制御部４５３、レスポンス生成部４５４、デバイス判定部４５５から構成される。
【００８２】
通信部４５１は、転送アプリケーション４３０とＳＯＡＰリクエスト・ＳＯＡＰレスポンスのやり取りをしたり、ＭＦＰ１０５に制御コマンドを送信したり、ＭＦＰ１０５からデバイス情報を受信したりする。リクエスト解析部４５２は、通信部４５１経由で転送アプリケーション４３０から受信したＳＯＡＰリクエストの内容を解析する。外部デバイス制御部４５３は、リクエスト解析部４５２で解析した内容に基づいてＭＦＰ１０５を制御するためのコマンドを生成し、通信部４５１経由でＭＦＰ１０５にコマンドを送信してジョブを投入する。さらに投入したジョブ情報をＭＦＰ１０５から取得する。レスポンス生成部４５４は、取得したジョブ情報にもとづいてＳＯＡＰレスポンスを生成し、通信部４５１経由で転送アプリケーション４３０に送信する。デバイス判定部４５５は、転送アプリケーション４３０からの要求に応じて指定されたデバイスがその変換アプリケーションで制御できるかどうかを判定する。
【００８３】
ＭＦＰ１０５は、コントローラ４６０を備える。コントローラ４６０は、通信部４６１とジョブ生成部４４２から構成される。通信部４６１は外部からの制御コマンドを受け付け、ジョブ生成部４４２は受信した制御コマンドに基づいてジョブを生成し実行する。また、通信部４６１は、ＭＦＰ１０１の変換アプリケーション４５０における通信部４５１と通信を行う。
【００８４】
＜シーケンス＞
次に、図１６を参照して、本実施形態における情報処理システムの一連の処理を示したシーケンスについて説明する。本シーケンス図で表される処理は、プルファックスサービスプロバイダを搭載していないファックス対応ＭＦＰでプルファックスの代行処理を行う例である。なお、Ｓ５０１乃至Ｓ５０６の処理は、図５と同様であるため説明を省略する。したがって、以下では、Ｓ５０６に続いて行われるＳ１６０１乃至１６１１の処理について説明する。
【００８５】
Ｓ５０６に続いてＳ１６０１では、転送アプリケーション４３０の処理部４３３は、Ｓ５０６で決定した宛先に対して、どのような方法で転送するかを判定する。転送先の情報処理装置（ＭＦＰ）がサービスプロバイダを備えていれば、転送先の情報処理装置に、Ｓ５０５で受信したＨＴＴＰレスポンスボディを、通信部４３１を介して送信する。転送先の情報処理装置がサービスプロバイダを備えていない場合、転送先に応じた変換アプリケーションを判定して、変換アプリケーション４５０に対してＳ５０５で受信したＨＴＴＰレスポンスボディを、通信部４３１を介して送信する。本実施形態では転送先のＭＦＰ１０５がサービスプロバイダを備えていないため、Ｓ１６０２にて、変換アプリケーション４５０に対して、ＨＴＴＰレスポンスボディを送信する。なお、本実施形態ではＨＴＴＰ ＰＯＳＴコマンドを用いて送信するが、送信方法は他の方法でもよい。
【００８６】
Ｓ１６０３では、変換アプリケーション４５０のリクエスト解析部４５２がＨＴＴＰレスポンスボディに含まれる処理要求８００を解析し、外部デバイス制御部４５３がＭＦＰ１０５でファックス送信を実行するための制御コマンドを生成する。なお、ＭＦＰ１０５にはプルファックス機能が備わっていないため、変換アプリケーション４５０が送信する原稿データの取得を行い、コマンド内に原稿データを埋め込む。Ｓ１６０４では、変換アプリケーション４５０は、Ｓ１６０３で生成したコマンドを、通信部４５１経由でＭＦＰ１０５に送信する。ＭＦＰ１０５のコントローラ４６０は、通信部４６１経由でファックス処理の制御コマンドを受信すると、Ｓ１６０５で、ジョブ生成部４４２がジョブを生成し、実行する。
【００８７】
一方、ＭＦＰ１０１の変換アプリケーション４５０は、Ｓ１６０４で制御コマンドを送信した後に、Ｓ１６０６にて投入したジョブの実行状況を監視する。ジョブ監視は情報処理装置固有の制御コマンドを用いてもよいし、ＳＮＭＰ等の汎用プロトコルを用いてもよい。ここで、ジョブ終了を検出するとＳ１６０７に移行する。なお、Ｓ１６０３にて何らかの理由で制御コマンドの送信が行えなかった場合は、ジョブの実行状況の監視は行わずに、ジョブ実行エラーとしてただちにＳ１６０７に移行する。これにより、ＭＦＰ１０５でのジョブの処理状況等を監視することができる。
【００８８】
Ｓ１６０７では、変換アプリケーション４５０は、ジョブ実行結果に基づいて転送アプリケーション４３０に送信するための処理結果８１０（ＳＯＡＰレスポンス）を生成する。Ｓ１６０８では、変換アプリケーション４５０は、Ｓ１６０２で受信したリクエストのレスポンスとして、通信部４５１を介して、転送アプリケーション４３０にＳ１６０７で生成したレスポンスを送信する。そして、転送アプリケーション４３０の処理部４３３は、処理結果８１０を、通信部４３１を介して受信する。なお、本実施形態におけるＨＴＴＰレスポンスヘッダ及びＨＴＴＰレスポンスは、図７及び図８を用いて説明した構成と同様であるため、説明を省略する。
【００８９】
Ｓ１６０９では、転送アプリケーション４３０の処理部４３３は、Ｗｅｂブラウザ４２０のアップロード処理部４２５に対して、処理結果８１０をＷｅｂアプリケーション４１０に対してアップロードするように依頼する。依頼に際して、処理部４３３は、アップロード処理部４２５に対してアップロードの宛先としてアップロード宛先７０３を指定する。アップロード宛先７０３はＨＴＴＰレスポンスヘッダに記載されており、転送アプリケーション４３０からアップロード処理部４２５に指定せず、Ｗｅｂブラウザ４２０がこの情報を記憶しておいてその情報を使用してもよい。また宛先を固定値とし、Ｗｅｂアプリケーション４１０から指定しないシステムとしてもよい。このとき転送アプリケーション４３０は、処理結果８１０の内容を書き換えてからアップロード依頼をしてもよい。処理結果８１０をそのままＷｅｂアプリケーション４１０にアップロードした場合、Ｗｅｂアプリケーション４１０は、処理要求８００が転送されてＭＦＰ１０５で実行されたことを知ることができない。図８の８２０は処理結果８１０を書き換えた例である。ここでは、処理結果８１０に対して、転送結果８２１を挿入している。他にも、転送先のアドレスや、転送時に書き換えられた処理要求の内容など、Ｗｅｂアプリケーション４１０が必要とする情報を記載してもよい。
【００９０】
Ｓ１６１０では、アップロード処理部４２５は、通信部４２１を介してＨＴＴＰ ＰＯＳＴコマンドで、処理部４３３からの依頼に従って処理結果８１０をアップロードする。このとき、転送アプリケーション４３０の処理部４３３から依頼された宛先７０３に対してアップロードを行う。
【００９１】
Ｓ１６１１では、Ｗｅｂアプリケーション４１０はＷｅｂブラウザ４２０に対して、画面表示用のＨＴＭＬコンテンツをレスポンスする。レスポンスを受け取ったＷｅｂブラウザ４２０は、解析部４２２によるＨＴＭＬデータの解析結果に基づいて、ＵＩ表示装置２０７に操作画面を表示する。
【００９２】
＜転送アプリケーションの処理＞
次に、図１７を参照して、ＭＦＰ１０１の転送アプリケーション４３０における処理フローについて説明する。Ｓ１７０１、Ｓ１７０２、Ｓ１７０６、Ｓ１７０９〜Ｓ１７１６における処理は、Ｓ５０５からＳ１６０９において既に説明しているため、不足部分を補足する形で説明する。
【００９３】
Ｓ１７０１では、Ｓ５０５の処理が実行される。Ｓ１７０２では、Ｓ５０６の処理が実行される。このとき、転送先が外部の情報処理装置である場合はＳ１７０６へ進む。転送先がＭＦＰ１０１自身である場合はＳ１７０３へ進む。Ｓ１７０３では、転送アプリケーション４３０の処理部４３３は、Ｓ５０５で受信したＨＴＴＰレスポンスボディを、通信部４３１を介して、ＭＦＰ１０１のサービスプロバイダ４４０に送信する。この宛先は、Ｓ５０６で決定されている。Ｓ１７０４では、ＭＦＰ１０１のサービスプロバイダ４４０は、処理結果８１０を、Ｓ１７０３で受信したリクエストのレスポンスとして、通信部４４１を介して、転送アプリケーション４３０に対して送信する。そして、転送アプリケーション４３０の処理部４３３は、処理結果８１０を、通信部４３１を介して受信する。
【００９４】
Ｓ１７０５では、転送アプリケーション４３０の判断部４３２が、Ｓ１７０４で受信した処理結果８１０を元にＳ５０５で受信したＨＴＴＰレスポンスボディの転送が必要かどうかを判断する。処理結果８１０には処理結果コード８１１が含まれており、このＲｅｓｕｌｔＣｏｄｅがＯＫであれば、転送の必要はないと判断し、Ｓ１７０８へ進む。ＲｅｓｕｌｔＣｏｄｅがＮＧであれば、転送の必要があると判断し、転送先アドレスを決定し、Ｓ１７０６へ進む。また、ＲｅｓｕｌｔＣｏｄｅがＮＧであっても、他の条件に従って転送を実施しない場合があってもよい。転送が必要かどうかの判断はこの方法に限定されるものではなく、例えばＨＴＴＰレスポンスコードを元に判断を行ってもよい。そして、本実施形態ではＳ５０５で受信したＨＴＴＰレスポンスヘッダに記載されている転送宛先７０４を転送先アドレスとする。これはＷｅｂアプリケーションが指定するものとは限らず、ユーザがＷｅｂブラウザ４２０を介して入力した情報であったり、又は、Ｗｅｂアプリケーション４１０は転送処理だけを指示し、転送先はＭＦＰ１０１に予め設定されていたりしてもよい。また、デバイスの構成や状態に応じて動的に転送先を変更してもよい。
【００９５】
Ｓ１７０６では、転送アプリケーション４３０の処理部４３３は、Ｓ１７０２又はＳ１７０５で決定した宛先の情報処理装置にてサービスプロバイダが利用可能かどうかを判定する。サービスプロバイダが利用可能であればＳ１７０７に進み、サービスプロバイダが利用できないのであればＳ１７０９に進む。Ｓ１７０７では、転送アプリケーション４３０の処理部４３３は、Ｓ１７０２又はＳ１７０５で決定した宛先に対して、Ｓ５０５で受信したＨＴＴＰレスポンスボディを、通信部４３１を介して送信する。本実施形態ではＨＴＴＰ ＰＯＳＴコマンドを用いて、ＭＦＰ１０２のサービスプロバイダ４４０に対して送信するが、送信方法は他の方法でもよい。Ｓ１７０８では、転送アプリケーション４３０の処理部４３３が、処理結果８１０を、通信部４３１を介して受信する。
【００９６】
Ｓ１７０９では、Ｓ１６０１が実行される。Ｓ１７０９の詳細については図１８を用いて後述する。Ｓ１７１０では、Ｓ１７０９にて転送先に対応した変換アプリケーションが特定できたかどうか（転送先に対応した変換アプリケーションが存在するか）を判定する。特定できた場合はＳ１７１１に進み、特定できなかった場合はＳ１７１４に進む。Ｓ１７１１では、Ｓ１６０２が実行される。Ｓ１７１２では、Ｓ１６０３及びＳ１６０４が実行される。Ｓ１７１２の処理の詳細については図１９を用いて後述する。Ｓ１７１３では、Ｓ１６０６が実行される。Ｓ１７１４では、Ｓ１６０７が実行される。Ｓ１７１０で転送先に応じた変換アプリケーションを特定できなかった場合は、ジョブの実行失敗のレスポンスを生成する。Ｓ１７１５では、Ｓ１６０８が実行される。Ｓ１７１６では、Ｓ１６０９が実行される。
【００９７】
図１８は、図１７のフローチャートのＳ１７０９の処理詳細を示すフローチャートであり、転送アプリケーション４３０の判断部４３２で実行される。
【００９８】
まず、Ｓ１８０１で、ＭＦＰ１０１に存在する変換アプリケーションのリストを取得し、変数ｉに０を代入する。Ｓ１８０２は、Ｓ１８０１で取得した変換アプリケーションリストの中のｉ番目の変換アプリケーションのデバイス判定部４５５に処理要求内容及び転送先情報（例えばＩＰアドレス）を渡して判定結果を取得する。デバイス判定部４５５は、転送先のデバイス情報及び処理要求から自変換アプリケーションで処理が行えるかを判定し結果を返す。このときデバイス判定部は、ＳＮＭＰなどを介して転送先デバイスから情報を取得して判定を行う。
【００９９】
Ｓ１８０３は、Ｓ１８０２にてデバイス判定部４５５から取得した判定結果をもとに変換アプリケーションが転送先デバイスの制御に対応しているかどうかを判定する。もし対応していると判定された場合は、Ｓ１８０４に進み、対応していないと判定された場合は、Ｓ１８０５に進む。Ｓ１８０４では、ｉ番目の変換アプリケーションを利用することを決定して処理を終了する。
【０１００】
Ｓ１８０５では、Ｓ１８０１で取得した変換アプリケーションリストの中の全ての変換アプリケーションについて処理を行ったかを判定する。リスト中の全ての変換アプリケーションの処理を行っていないと判定した場合は、Ｓ１８０６に進み、すべて処理したと判定した場合は、Ｓ１８０７に進む。Ｓ１８０６では、変数ｉをインクリメントしてＳ１８０２に進む。
【０１０１】
Ｓ１８０７は、利用可能な変換アプリケーションが無い旨を示すエラーを返す。なお、本実施形態では利用する変換アプリケーションを決定するために、各変換アプリケーションにデバイス判定部４５５を設ける構成にしている。しかしながら、本発明はこれに限定されず、変換アプリケーションと対応デバイスのテーブルを転送アプリケーションに保持し、それをもとに変換アプリケーションを決定してもよい。
【０１０２】
図１９は、プルファックスのための変換アプリケーション４５０の処理（Ｓ１７１２）の流れを示すフローチャートである。Ｓ１９０１は、受信したＳＯＡＰリクエストからドキュメントの取得先８０３を取得する。Ｓ１９０２では、Ｓ１９０１で取得したドキュメントの取得先にアクセスして文書データを取得する。Ｓ１９０３では、Ｓ１９０２でドキュメントの取得に成功したかどうかを判定する。成功した場合はＳ１９０４に進み、失敗した場合は処理を終了する。
【０１０３】
Ｓ１９０４では、受信したＳＯＡＰリクエストからファックスの設定情報を抽出する。具体的にはファックス宛先８０２及びスキャンサイズ８０４である。Ｓ１９０５では、Ｓ１９０２で取得した文書データ及びＳ１９０４で抽出した設定情報から、ファックス実行コマンドを生成し転送先のデバイスに送信して、ファックスジョブの実行指示を行う。
【０１０４】
以上説明したように、本発明では、ＭＦＰ１０１はＷｅｂアプリケーション４１０から、Ｗｅｂブラウザ４２０への応答として処理要求を受信し、他のデバイスへ転送することができる。また、その処理要求に対する結果をＷｅｂブラウザ４２０からＷｅｂアプリケーション４１０にアップロードする。よって、Ｗｅｂアプリケーション４１０は、ユーザが操作しているＭＦＰ１０１以外のＭＦＰ１０２、１０５にジョブを投入し、代行処理をさせることが可能になり、また、ユーザ操作の介在無しに他のＭＦＰ１０２、１０５で処理が実行できるため、代行処理時のユーザの手間を省くことができる。そして、ジョブの実行結果をＷｅｂアプリケーション４１０が知ることができるため、Ｗｅｂアプリケーション４１０によってユーザに対して代行処理時の処理結果の通知を行うことが可能となる。また、古いＭＦＰやローエンドのＭＦＰなどＳＯＡＰリクエストによるジョブ実行に対応していない機種でも代行処理を行うことが可能となりユーザの利便性が向上する。
【０１０５】
＜変形例＞
第３の実施形態では、Ｗｅｂアプリケーション４１０の指示、又は、ＭＦＰ１０１内に存在する情報に従って転送アプリケーション４３０が転送処理を実行する。そのため、システムを利用するユーザが意図せず処理要求８００が転送されてしまことが考えられる。そこで、転送アプリケーション４３０は、ＭＦＰ１０２もしくはＭＦＰ１０５に処理要求８００を転送する際に、転送確認画面９００をユーザに提示し、転送してよいかどうかをユーザに確認してもよい。
【０１０６】
＜第４の実施形態＞
以下では、本発明の第４の実施形態について説明する。なお、上記第１乃至第３の実施形態と同様の構成及び制御については説明を省略する。また、同一の構成については同一の参照符号を付す。図２０は、本実施形態における情報処理システム全体のソフトウェア構成を示す。図１０に示す各機能部は、ＭＦＰ１０１／ＭＦＰ１０２／サーバ１０３のそれぞれが有しているＣＰＵ２０１／ＣＰＵ３０１が制御プログラムを実行することにより実現される。本実施形態においては、上記第２の実施形態と異なる点は、ＭＦＰ１０１，１０２のそれぞれの転送アプリケーション４３０に、情報記憶部４３４が設けられている点のみである。他の構成は上記実施形態と同様であるため説明を省略する。
【０１０７】
ＭＦＰ１０１、１０２におけるそれぞれの転送アプリケーション４３０は、通信部４３１、判断部４３２、処理部４３３、及び情報記憶部４３４を有する。情報記憶部４３４は、判断部４３２により転送が必要と判断された際にユーザ識別情報と処理要求及びＷｅｂブラウザ４２０で管理されているセッション情報とを紐付けて記憶装置に格納し管理する。ここでセッション情報とはセッションを管理するための識別情報であり、セッションとは、ユーザがＷｅｂアプリケーションを利用する上での一連の操作単位のことである。
【０１０８】
＜シーケンス＞
次に、図２１を参照して、本実施形態における情報処理システムの一連の処理を示したシーケンスについて説明する。本シーケンス図で表される処理は、プルプリントの代行処理である。なお、Ｓ５０１乃至Ｓ５０５の処理は、図５と同様であるため説明を省略する。したがって、以下では、Ｓ５０５に続いて行われるＳ２１０１乃至２１１９の処理について説明する。まず、ユーザがＭＦＰ１０１のユーザ入力装置２０６から、Ｗｅｂブラウザの起動を行うためのボタン（不図示）押下を受けると、Ｗｅｂブラウザ４２０を起動する。ボタンは、ハードウェアボタンに限ったものではなく、タッチパネル上に表示されたボタンでもよい。
【０１０９】
Ｓ５０５に続いて、Ｓ２１０１では、転送アプリケーション４３０の判断部４３２が、Ｓ５０５で受信した情報に基づき、ＨＴＴＰレスポンスボディの送信先を判断する。本実施形態ではＳ５０５で受信したＨＴＴＰレスポンスヘッダに記載されている宛先で示されるサービスプロバイダ４４０に対して処理要求２５００を送信する。Ｓ２１０２では、ＭＦＰ１０１のサービスプロバイダ４４０は、Ｓ２１０１で転送アプリケーション４３０が送信した処理要求２５００を通信部４４１で受信し、処理要求２５００に従ってジョブ生成部４４２でジョブ生成し、実行する。なお、ここでは、ＭＦＰ１０１にて印刷できないジョブが指定された場合等が原因でエラーを返すことを想定している。
【０１１０】
Ｓ２１０３では、ＭＦＰ１０１のサービスプロバイダ４４０は、処理結果２５１０を、Ｓ２１０１で受信した処理要求のレスポンスとして、通信部４４１を介して、ＭＦＰ１０１の転送アプリケーション４３０に対して送信する。そして、転送アプリケーション４３０の処理部４３３は、処理結果２５１０を、通信部４３１を介して受信する。Ｓ２１０４では、転送アプリケーション４３０の判断部４３２が、Ｓ２１０３で受信した処理結果に基づき、Ｗｅｂブラウザ４２０にレスポンスをそのまま返すか否かを判定する。当該処理は、保持判定手段の処理の一例である。ここで、Ｓ２１０３にて受信した処理結果２５１０はエラーであるため、他のデバイスで処理が継続できるように処理要求情報を保存すると判定する。
【０１１１】
Ｓ２１０５では、転送アプリケーション４３０の処理部４３３は、Ｗｅｂブラウザ４２０からセッション情報を取得する。Ｓ２１０６では、転送アプリケーション４３０の情報記憶部４３４が処理要求及びセッション情報を、Ｗｅｂブラウザ４２０を操作したユーザの識別情報と紐付けて記憶装置に記憶する。なお、ここで処理要求はＳ５０４で受信したＨＴＴＰレスポンスボディに含まれる処理要求２５００であり、セッション情報はＳ２１０５で取得したセッション情報である。Ｓ２１０７では、転送アプリケーション４３０の処理部４３３はＷｅｂブラウザ４２０に対して要求された処理が行えなかったことをユーザに知らせるための確認画面の表示要求を出す。Ｓ２１０８では、Ｗｅｂブラウザ４２０の画面表示部４２３は、Ｓ２１０７で要求された内容に応じた画面を表示する。ここで、Ｗｅｂブラウザ４２０は、サーバ１０３にはアクセスせずにＷｅｂブラウザ４２０に組み込まれた画面を表示する。
【０１１２】
ここでユーザはＭＦＰ１０２に移動して処理を再開することを想定する。ユーザがＭＦＰ１０２にログインしてＵＩ表示装置２０７上に表示されている処理再開ボタンを押すと、Ｓ２１０９にて、ＭＦＰ１０２の転送アプリケーション４３０の処理部４３３は、処理再開ボタン押下を検出する。なお、ここで、ログインとは、ユーザ入力装置２０６或いはＵＩ表示装置２０７からユーザからのユーザ自身を特定する情報の入力を受け、ユーザにＭＦＰの機能を利用可能な状態にすることである。ここで入力された情報は、ＭＦＰ１０２の転送アプリケーション４３０に通知され、ユーザ識別情報として利用される。Ｓ２１１０では、ＭＦＰ１０２の転送アプリケーション４３０は、ＭＦＰ１０２を操作しているユーザの識別情報を含むユーザ情報パケット２６００をブロードキャストする。ユーザ情報パケットの詳細については後述する。
【０１１３】
Ｓ２１１１では、ＭＦＰ１０１の転送アプリケーション４３０の処理部４３３は、Ｓ２１１０で受信したユーザ情報パケット２６００からユーザ識別情報を抽出し、そのユーザに関連する情報を保持しているかどうかを判定する。ここではユーザに関連する情報を保持していることを想定したシーケンスを示しているため、ユーザに紐付けられたＨＴＴＰリクエスト１２００を、通信部４３１を介して送信する。本実施形態ではＨＴＴＰ ＰＯＳＴコマンドを用いて、ＭＦＰ１０２の転送アプリケーション４３０に対して送信するが、送信方法は他の方法でもよい。ＨＴＴＰリクエスト１２００は、Ｓ５０５で受信したＨＴＴＰレスポンスボディに、セッション情報を付加したメッセージである。より具体的には、メッセージをマルチパートで扱うための識別情報１２０１を定め、Ｓ５０５で受信したＨＴＴＰレスポンスボディをパート１２０２に格納する。同様にセッション情報をパート１２０３に格納する。格納するパートの順番は、本実施形態に限定されるものではない。また、セッション情報は文字列化されていてもよく、データ形式を本実施形態に限定するものではない。
【０１１４】
Ｓ２１１２では、ＭＦＰ１０１で中断した処理を再開できたことをユーザに知らせるため、ＭＦＰ１０２の転送アプリケーション４３０の処理部４３３は、Ｗｅｂブラウザ４２０に処理再開画面表示依頼を送信する。Ｓ２１１３ではＷｅｂブラウザ４２０の画面表示部４２３はＭＦＰ１０１からの処理を再開したことをユーザに知らせるための画面を表示する。ここでＷｅｂブラウザ４２０はサーバ１０３にアクセスにはいかずにＷｅｂブラウザ４２０に組み込まれた画面を表示する。
【０１１５】
Ｓ２１１４では、ＭＦＰ１０２の転送アプリケーション４３０の処理部４３３において、Ｓ２１１１で受信したＨＴＴＰリクエスト１２００から、処理要求２５００を抽出する。そして、抽出した処理要求２５００をＭＦＰ１０２のサービスプロバイダ４４０に通信部４３１を介して送信する。Ｓ２１１５では、ＭＦＰ１０２のサービスプロバイダ４４０は、Ｓ２１１４で転送アプリケーション４３０が送信した処理要求２５００を通信部４４１で受信し、処理要求２５００に従ってジョブ生成部４４２でジョブ生成し、実行する。処理要求２５００にはプルプリント要求２５０１が含まれており、ＭＦＰ１０２はプルプリント要求２５０１に従って、印刷するドキュメントを取得先２５０２から取得し、印刷を実行する。Ｓ２１１６では、ＭＦＰ１０２のサービスプロバイダ４４０は、処理結果２５２０を、Ｓ２１１４で受信したＨＴＴＰリクエストのレスポンスとして、通信部４４１を介して、ＭＦＰ１０２の転送アプリケーション４３０に対して送信する。そして、転送アプリケーション４３０の処理部４３３は、処理結果２５２０を、通信部４３１を介して受信する。
【０１１６】
Ｓ２１１７では、転送アプリケーション４３０の処理部４３３は、Ｗｅｂブラウザ４２０のアップロード処理部４２５に対して、処理結果２５２０をＷｅｂアプリケーション４１０に対してアップロードするように依頼する。その際、Ｓ２１１１で受信したＨＴＴＰリクエスト１２００のパート１２０２からセッション情報を抽出し、処理結果２５２０と共にＷｅｂブラウザ４２０に送信する。また、処理部４３３は、アップロード処理部４２５に対してアップロードの宛先としてアップロード宛先７０３を指定する。なお、処理結果２５２０をそのままＷｅｂアプリケーション４１０にアップロードした場合、Ｗｅｂアプリケーション４１０は、処理要求２５００が転送されてＭＦＰ１０２で実行されたことを知ることができない。そのため、転送アプリケーション４３０は、処理結果２５２０の内容を書き換えてからアップロード依頼をしてもよい。図２５の２５３０は、処理結果２５２０を書き換えた例である。ここでは、処理結果２５２０に対して、転送結果２５３１を挿入している。他にも、転送先のアドレスや、転送時に書き換えられた処理要求の内容など、Ｗｅｂアプリケーション４１０が必要とする情報を記載してもよい。
【０１１７】
Ｓ２１１８では、アップロード処理部４２５は、通信部４２１を介してＨＴＴＰ ＰＯＳＴコマンドで、処理部４３３からの依頼に従って処理結果２５２０をアップロードする。このとき、転送アプリケーション４３０の処理部４３３から依頼された宛先に対して、Ｓ２１１７で抽出したセッション情報を使い、アップロードを行う。Ｓ２１１９では、Ｗｅｂアプリケーション４１０はＷｅｂブラウザ４２０に対して、セッション情報と処理結果２５２０に基づく所定の画面表示用のＨＴＭＬコンテンツをレスポンスする。レスポンスを受け取ったＷｅｂブラウザ４２０は、解析部４２２によるＨＴＭＬデータの解析結果に基づいて、ＵＩ表示装置２０７に操作画面を表示する。
【０１１８】
＜転送アプリケーションの処理＞
次に、図２２を参照して、ＭＦＰ１０１の転送アプリケーション４３０における処理フローについて説明する。Ｓ２２０１〜Ｓ２２０７における処理は、Ｓ５０５、Ｓ２１０１、Ｓ２１０３〜Ｓ２１０７において既に説明しているため、不足部分を補足する形で説明する。
【０１１９】
Ｓ２２０１では、Ｓ５０５の処理を実行する。Ｓ２２０２では、Ｓ２１０１の処理を実行する。Ｓ２２０３では、Ｓ２１０３の処理を実行する。Ｓ２２０４では、Ｓ２１０４の処理を実行する。本実施形態ではＳ２２０３で受信した処理結果２５１０、２５２０を基に、Ｓ５０５で受信した処理要求２５００をＭＦＰ内に保持しておくか否かを判定する。処理結果２５１０、２５２０には処理結果コード２５１１、２５２１が含まれており、処理結果コード２５１１がＮＧであれば、保持する必要があると判断し、Ｓ２２０５へ進む。処理結果コード２５２１がＯＫであれば、保持する必要がないと判断しＳ２２０７へ進む。なお、本実施形態では処理結果コード２５１１の結果を基に決定しているが、処理結果２５１０に含まれる他の条件や、複数の条件から複合的に判定を行ってもよい。
【０１２０】
Ｓ２２０５では、Ｓ２１０５，Ｓ２１０６の処理を実行する。ここでユーザ識別情報はユーザがＭＦＰ１０１にログインを行った時に通知される情報を記憶しておき利用する。Ｓ２２０６では、Ｓ２１０７の処理を実行する。Ｓ２２０７では、Ｓ２２０３で受信した処理要求に対する応答として処理結果をＷｅｂブラウザ４２０に送信する。
【０１２１】
図２３は、ＭＦＰ１０２の転送アプリケーション４３０における処理フローの詳細を示す。Ｓ２３０１、Ｓ２３０２〜Ｓ２３０５、Ｓ２３０７における処理は、Ｓ２１１０、Ｓ２１１１、Ｓ２１１２、Ｓ２１１４，Ｓ２１１６、Ｓ２１１７において既に説明しているため、不足部分を補足する形で説明する。
【０１２２】
Ｓ２３０１では、Ｓ２１１０の処理を行い、ユーザ情報パケット２６００をブロードキャストする。本実施形態においてはパケットをブロードキャストするようにしているがこの構成に限定されるものではなく、事前にＭＦＰリストを登録可能としておき、そのリストに登録されているＭＦＰに対してそれぞれ問い合わせを出すようにしてもよい。Ｓ２３０２では、Ｓ２１１１の処理を行い、ＭＦＰ１からの応答を受信する。もし応答を受信できた場合はＳ２３０３に進み、応答を受信できなかった場合はＳ２３１０に進む。
【０１２３】
Ｓ２３０３では、Ｓ２１１２の処理を行う。Ｓ２３０４では、Ｓ２１１４の処理を行う。Ｓ２３０５では、Ｓ２１１６の処理を行う。Ｓ２３０６では、Ｓ２３０５で受信した処理結果を基に、Ｓ２３０２で受信した処理要求をＭＦＰ内に保持しておくか否かを判定する。もし処理要求に含まれるＲｅｓｕｌｔＣｏｄｅがＮＧであればＳ２３０８に進み、ＮＧ以外であればＳ２３０７に進む。なお、このステップの処理の詳細はＳ６０４と同じである。Ｓ２３０７では、Ｓ２１１７の処理を行い、処理を終了する。
【０１２４】
Ｓ２３０８では、Ｓ２３０２で受信した応答に含まれる処理要求とセッション情報とユーザ識別情報とを関連付けて記憶装置に保存する。Ｓ２３０９では、Ｗｅｂブラウザ４２０にエラー画面表示要求を出して処理を終了する。Ｓ２３１０では、処理を再開できるジョブが存在しない旨のエラー画面を表示して処理を終了する。
【０１２５】
図８は、ＭＦＰ１０１が、Ｓ２１１０にてブロードキャストされたユーザ情報パケット（図２６）を受信した際の転送アプリケーション４３０の処理フローの詳細を示す。
【０１２６】
Ｓ２４０１では、Ｓ２１１０にてＭＦＰ１０２の転送アプリケーションが送信したユーザ情報パケット２６００からユーザ識別情報部２６０３を抽出する。Ｓ２４０２では、Ｓ２４０１で抽出したユーザ識別情報に紐付けられた情報がＭＦＰ内に保存されているかを判定する。もし情報が保存されていない場合は処理を終了し、情報が保存されている場合はＳ２４０３に進む。Ｓ２４０３では、Ｓ２４０１で抽出したユーザ識別情報に紐付けられた情報を記憶装置から読み出し、ユーザ情報パケットの送信元ＭＦＰに対して送信する。Ｓ２４０４では、送信完了した情報を記憶装置から削除して処理を終了する。
【０１２７】
＜ＨＴＴレスポンス＞
なお、本実施形態におけるＨＴＴＰレスポンスヘッダは、図７を用いて説明した構成と同様であるため、説明を省略する。図２５の２５００は、Ｗｅｂアプリケーション４１０が生成し、Ｗｅｂブラウザ４２０にレスポンスとして返す処理要求の内容を示す。処理要求２５００は、プルプリント要求２５０１を有し、Ｓ５０４でＷｅｂブラウザ４２０が受信するレスポンスボディに含まれる。処理要求２５００はＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  ＬａＮＧｕａｇｅ）フォーマットで記載されているが、ＭＦＰ１０１に対する処理が記載できて、ＭＦＰ１０１が処理できる形式であれば何でもよい。
【０１２８】
プルプリント要求２５０１は、ＭＦＰ１０１に対してプルプリント処理の実行を要求する命令である。また、プルプリント要求２５０１には、印刷の制御に関わる設定値を記載することができる。例えば、印刷するドキュメントの取得先２５０２、印刷サイズ２５０３が設定できる。
【０１２９】
図１０の２５１０、２５２０は、サービスプロバイダ４４０が生成し、転送アプリケーション４３０にレスポンスとして返す処理結果の内容を示す。処理結果２５１０、２５２０は、それぞれ処理結果コード２５１１、２５２１を有する。処理結果２５１０、２５２０は処理要求と同様に、ＸＭＬフォーマットで記載されているが、他の形式であってもよい。処理結果コード２５１１、２５２１には、サービスプロバイダ４４０で生成され実行されたジョブの処理結果コードが記載されている。この処理結果コードを参照することで、転送アプリケーション４３０はサービスプロバイダ４４０がジョブの実行に成功したか失敗したかが分かる。また、Ｗｅｂアプリケーション４１０は、この処理結果２５１０、２５２０をＷｅｂブラウザ４２０のアップロードによって受信することで、ユーザに対して処理結果に応じたＨＴＭＬコンテンツを生成し、Ｗｅｂブラウザ４２０に送信することができる。サービスプロバイダがジョブの実行に成功した場合、処理結果コード２５２１にはＯＫ（２５２２）が記載され、失敗した場合の処理結果コード２５１１には、ＮＧ（２５１２）が記載される。
【０１３０】
図１０の２５３０は、転送アプリケーション４３０が処理結果２５１０を書き換えた結果を示す。書き換え後処理結果１０２０は、転送結果２５３１を有する。転送結果２５３１は、Ｓ２１１１において、転送アプリケーション４３０によって挿入され、Ｗｅｂアプリケーション４１０に転送処理の内容を通知するために利用する。例えば、転送が実行されたかどうか、転送先のアドレス、転送する際に書き換えられた処理要求の内容などが記載される。
【０１３１】
＜ユーザ情報パケット＞
次に、図２６を参照して、ＭＦＰ２において処理再開ボタン押下を検知した際に転送アプリケーション４３０がブロードキャストするユーザ情報パケットの一例について説明する。バージョン部２６０１は、パケットのバージョンを示す情報が格納される。バージョン情報は、以降に続くパケットのデータ構造を決定するために利用される。本実施形態ではバージョンは０ｘ０００１が設定される。データサイズ部２６０２は、以降に続くデータのサイズ情報が格納される。ユーザ識別情報部２６０３は、ユーザの識別情報が文字列として格納される。この例では”Ｄｏｍａｉｎ￥Ｏｐｅｒａｔｏｒ１”という１６バイトの情報が格納されているため、データサイズ部２６０２には０ｘ００１０が格納される。  
【０１３２】
＜処理要求の内容＞
次に、図２７を参照して、転送アプリケーション４３０が、Ｓ２１１１でＭＦＰ１０２に処理を転送する際の処理要求の内容について説明する。処理要求２７００は、複数の情報をパート毎に格納するための識別情報２７０１を有し、処理要求２５００の内容、Ｗｅｂアプリケーション４１０とＷｅｂブラウザ４２０の通信を識別するセッション情報、及び操作しているユーザを識別する情報を有する。処理要求２７００はＸＭＬフォーマットで記載されているが、ＭＦＰ１０２に対する処理が記載できて、ＭＦＰ１０２が処理できる形式であれば何でもよい。
【０１３３】
パート２７０２は、プルプリント要求２５０１を有し、Ｓ５０４でＷｅｂブラウザ４２０が受信するレスポンスボディが含まれる。パート２７０３は、Ｗｅｂアプリケーション４１０とＷｅｂブラウザ４２０の通信を識別するセッション情報が含まれる。パート２７０４は、ＭＦＰ１０１を操作しているユーザの識別情報が含まれる。
【０１３４】
各パートの区切りは識別情報２７０１により行われる。格納するパートの順番は、本実施形態に限定されるものではない。また、パート２７０３のセッション情報は文字列化されていてもよく、データ形式を本実施形態に限定するものではない。パート２７０４のユーザ情報もドメイン情報をさらに別パートに分離していてもよく、送信される情報としてこれらが格納されているのであれば、データ形式として本実施形態に限定されるものではない。
【０１３５】
以上説明したように、本実施形態では、ＭＦＰ１０１はＷｅｂアプリケーション４１０から、Ｗｅｂブラウザ４２０への応答として処理要求を受信し、処理要求を完遂できなかった場合に、ユーザ情報と処理要求・セッション情報を紐付けてデバイス内に保存する。また他のデバイスからの通知を受けて保持している情報を転送する。さらに、転送された情報を受信したデバイスは転送された処理要求を実行して、処理結果を転送されたセッション情報を使いアップロードする。これにより、Ｗｅｂアプリケーション４１０は、Ｗｅｂアプリケーション４１０に特別な対応を入れることなく、ユーザが操作しているＭＦＰ１０１以外のＭＦＰ１０２にジョブを投入し、代行処理をさせることが可能になる。また、ユーザは代行先のＭＦＰ１０２で処理再開ボタンを押すだけで作業が継続できるようになり利便性が向上する。
【０１３６】
なお、本実施形態では、ＭＦＰ１０１内に保存した処理要求及びセッション情報を他のＭＦＰ１０２に送信した後にだけ削除するようにしている。しかし、この構成に限定されず、情報保存時に保存時刻情報も同時に記憶するようにして、時刻情報に相当する時間が経過すると情報記憶部４３４が情報を自動的に削除してもよい。また、本実施形態では条件を満たした場合に、常にＭＦＰ１０１内に情報を保存するような構成になっているが、ＵＩ表示装置に確認画面を表示して、ユーザに情報を保存しておくかを選択させるようにしてもよい。
【０１３７】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2015014893.tif 000003
【図２】
2015014893.tif 000004
【図３】
2015014893.tif 000005
【図４】
2015014893.tif 000006
【図５】
2015014893.tif 000007
【図６】
2015014893.tif 000008
【図７】
2015014893.tif 000009
【図８】
2015014893.tif 000010
【図９】
2015014893.tif 000011
【図１０】
2015014893.tif 000012
【図１１】
2015014893.tif 000013
【図１２】
2015014893.tif 000014
【図１３】
2015014893.tif 000015
【図１４】
2015014893.tif 000016
【図１５】
2015014893.tif 000017
【図１６】
2015014893.tif 000018
【図１７】
2015014893.tif 000019
【図１８】
2015014893.tif 000020
【図１９】
2015014893.tif 000021
【図２０】
2015014893.tif 000022
【図２１】
2015014893.tif 000023
【図２２】
2015014893.tif 000024
【図２３】
2015014893.tif 000025
【図２４】
2015014893.tif 000026
【図２５】
2015014893.tif 000027
【図２６】
2015014893.tif 000028
【図２７】
2015014893.tif 000029