JP2015032225A - 情報処理装置、情報処理装置の制御方法、及びプログラム、記憶媒体 - Google Patents

Abstract

【課題】 Ｗｅｂサーバがインターネットなどの外部ネットワークにあり、複数のデバイスがＬＡＮなどの内部ネットワークにある場合は、Ｗｅｂサーバから複数のデバイスにリクエストを直接投入できない。【解決手段】 Ｗｅｂサーバに接続され、当該Ｗｅｂサーバにより提供される操作画面を表示可能なＷｅｂブラウザを備えた情報処理装置とその制御方法であって、Ｗｅｂサーバから受け取った処理要求を他の情報処理装置と分担して実行できるかどうかを判定し、実行できると判定すると、その処理要求を情報処理装置と他の情報処理装置との処理に分割して、その情報処理装置と他の情報処理装置に実行させ、情報処理装置と他の情報処理装置で実行された処理の結果をまとめて前記処理要求に対する処理結果としてＷｅｂサーバに通知する。【選択図】 図４

Description

本発明は、Ｗｅｂサーバに接続され、当該Ｗｅｂサーバにより提供される操作画面を表示するＷｅｂブラウザを備えた情報処理装置、情報処理装置の制御方法、及びプログラム、記憶媒体に関する。

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

ところで、最近ではスキャナやプリンタを備えた複合機（ＭＦＰ：Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）の中にも、上述したようなＷｅｂブラウザを備えているものがある。そのようなＭＦＰでは、上述した手順を用いてＷｅｂサーバにより提供される操作画面をＭＦＰのＷｅｂブラウザで操作パネルに表示し、その操作パネルを介してユーザからの各種指示を受け付けることができる。

また更には、ＭＦＰが備える各機能を利用するための指示を入力する操作画面をＷｅｂサーバが提供し、ＭＦＰのＷｅｂブラウザで表示された操作画面を介して、ＭＦＰに対する指示を入力するシステムも考えられている。このシステムでは、Ｗｅｂサーバは、ユーザから入力された指示の内容に従って、ＭＦＰに対して各機能の実行を依頼し、この依頼を受けたＭＦＰは、その依頼された処理を実行する。これにより、ＭＦＰを操作するための全ての操作画面をＭＦＰに保持しておく必要がなくなり、また操作画面の変更もＷｅｂサーバで容易に行うことができるようになる。

具体的には、ＭＦＰの各機能をＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）に公開し、Ｗｅｂサーバから適宜、各機能を呼び出す方法が考えられている。この方法では、Ｗｅｂサーバに処理のメインロジックを持たせ、ＭＦＰの制御やユーザとの対話処理をＷｅｂサーバに実行させて、ＭＦＰによる処理の負荷を軽減できる。

例えばＷｅｂサービスとしてＭＦＰの機能を公開することで、Ｗｅｂサーバからローカルなサブルーチンを呼び出すようにＭＦＰが提供する機能を実行できる。また、その呼び出しの応答を管理することで処理のメインロジックをＷｅｂサーバに持たせことができる。更には、生産性を高めるため、Ｗｅｂアプリケーションから複数のＭＦＰにジョブを投入することで高速にジョブを処理する方法がある（特許文献１参照）。

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

ＲＰＣは、クライアントが要求メッセージをサーバに送信することで開始されるため、クライアントと、サービスを提供するサーバとの間で通信可能な状態にする必要がある。即ち、この方法では、情報処理装置やＭＦＰ等のデバイスがファイアウォールで守られている場合や、ネットワークアドレス変換を用いる環境にある場合、そのデバイスは外部ネットワークに存在するＷｅｂサーバからのＲＰＣ要求を受け付けることができない。これはファイアウォールは、一般的に内部から外部への接続は許可するが、外部から内部への接続は許可しないためである。また、デバイスがアドレス変換を用いる環境にある場合は、サーバ側からデバイスを特定できないためである。このため、Ｗｅｂサーバがインターネットなどの外部ネットワークにあり、複数のデバイスがＬＡＮなどの内部ネットワークにある場合は、Ｗｅｂサーバのリクエストは、通信できるデバイスに対してのみ有効となる。つまりは、上述した環境下において、生産性を向上させるために、Ｗｅｂサーバから複数のデバイスにリクエストを直接投入しようとしても、クライアント以外のデバイスにはリクエストを投入できないという問題がある。

本発明の目的は、上記従来技術の問題点を解決することにある。

本発明の目的は、Ｗｅｂサーバからの処理要求を複数の情報処理装置で分担して処理する技術を提供することにある。

上記目的を達成するために本発明の一態様に係る情報処理装置は以下のような構成を備える。即ち、
Ｗｅｂサーバに接続され、当該Ｗｅｂサーバにより提供される操作画面を表示可能なＷｅｂブラウザを備えた情報処理装置であって、
前記Ｗｅｂサーバから受け取った処理要求を他の情報処理装置と分担して実行できるかどうかを判定する判定手段と、
前記判定手段により実行できると判定すると前記処理要求を前記情報処理装置と前記他の情報処理装置との処理に分割して、前記情報処理装置と前記他の情報処理装置に実行させる処理手段と、
前記処理手段により前記情報処理装置と前記他の情報処理装置で実行された処理の結果をまとめて前記処理要求に対する処理結果として前記Ｗｅｂサーバに通知する通知手段と、を有することを特徴とする。

本発明によれば、Ｗｅｂサーバからの処理要求を複数の情報処理装置で分担して処理できるため、生産性が向上し、ユーザの利便性を高められるという効果がある。

実施形態に係る情報処理装置を収容する情報処理システムの構成例を示す図。 実施形態に係るデバイスのハードウェア構成を説明するブロック図。 本実施形態に係るサーバのハードウェア構成を説明するブロック図。 本実施形態に係る情報処理システム全体のソフトウェア構成を説明する図。 本発明の実施形態１に係る情報処理システムにおける一連の処理の流れを説明するシーケンス図。 本実施形態１に係るデバイス１０１の重連アプリケーションが処理要求を受け付けて処理結果を応答するまでの処理を説明するフローチャート。 本実施形態１においてＷｅｂアプリケーションがＷｅｂブラウザに返すＨＴＴＰレスポンスヘッダの一例を示す図。 本発明の実施形態１に係る処理要求とその分割の例を説明する図。 実施形態１に係る重連設定画面の一例を示す図（Ａ）と、実施形態１に係るデバイス１０１のジョブＩＤ管理部が管理している親ジョブＩＤと子ジョブＩＤとの対応付けを記憶するテーブルの一例を示す図（Ｂ）。 実施形態１におけるデバイス１０１の重連アプリケーションの処理部で作成される処理結果の一例を説明する図。 本実施形態２に係る重連アプリケーションが処理要求を受け付けてから、処理結果の応答までの処理を説明するフローチャート。 本発明の実施形態２に係るＦａｘ同報送信の処理要求とその分割の例を説明する図。

以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。尚、本実施形態では、ＰＣやＭＦＰを総称してデバイスと呼び、このような複数のデバイスを用いて処理することの総称を重連処理と呼ぶことにする。また本実施形態では、本発明に係るＷｅｂサーバに接続され、当該Ｗｅｂサーバにより提供される操作画面を表示可能なＷｅｂブラウザを備えた情報処理装置をＭＦＰを用いて説明するが、本発明はこれに限定されない。

図１は、本発明の実施形態に係る情報処理装置を収容する情報処理システムの構成例を示す図である。

このシステムは、ネットワーク１００を介して互いに接続されたデバイス１０１，１０２と、インターネット１０４を介して接続されたサーバ１０３を含む。ネットワーク１００は、各デバイス間で通信を行うための基盤であって、インターネット１０４に接続されている。デバイス１０１，１０２は、Ｗｅｂブラウザ機能を有すれば、ＭＦＰ等でもよい。更に、デバイス１０１，１０２は、ローカルなＩＰアドレスで管理されていても良い。その場合、ネットワーク１００とデバイス１０１，１０２の間にゲートウェイ（不図示）が存在し、そのゲートウェイはアドレス変換を行う。例えばゲートウェイにはルータが含まれる。またゲートウェイや、デバイス１０１，１０２がファイアウォール機能を備えていても良い。サーバ１０３は、Ｗｅｂコンテンツをインターネット１０４、ネットワーク１００を介して配信する機能を持っており、デバイス１０１，１０２からのリクエストに応じてＷｅｂコンテンツを返す。

図２は、実施形態に係るデバイス１０１のハードウェア構成を説明するブロック図である。

このデバイス１０１は、ＣＰＵ２０１、ＣＰＵ２０１による処理の実行時にワークエリアを提供するＲＡＭ２０２、画像を読み取る読取部２０３、画像を印刷する印刷部２０４、プログラムや様々な設定を記憶する記憶部２０５（ＨＤＤやＮＶＲＡＭ等）を含む。更に、ユーザがコマンドの入力を行う入力部２０６、ＵＩ画面などを表示する表示部２０７、他機器とネットワークによる通信を行うネットワークＩ／Ｆ（インターフェース）２０８を含み、これらはメインバス２００を介して相互に接続されている。尚、本実施形態では特に断らない限り、ＣＰＵ２０１がメインバス２００を介してＲＡＭ２０２、読取部２０３、印刷部２０４、記憶部２０５、入力部２０６、表示部２０７、ネットワークＩ／Ｆ２０８を制御する。また、タッチパネルディスプレイのように表示部２０７が入力部２０６を兼ねても良い。尚、ＣＰＵ２０１が実行するプログラムは、不図示のＲＯＭに記憶されたブートプログラムにより記憶部２０５からＲＡＭ２０２に展開され、ＣＰＵ２０１の制御の下に実行される。尚、デバイス１０２のハードウェア構成も同じであるため、その説明を省略する。

図３は、本実施形態に係るサーバ１０３のハードウェア構成を説明するブロック図である。

このサーバは、ＣＰＵ３０１、ＣＰＵ３０１のワークエリアを提供するＲＡＭ３０２、プログラムや各種設定情報等を記憶する記憶部３０３、他機器とネットワークによる通信を行うネットワークＩ／Ｆ３０４を有している。これら各部は、メインバス３００を介して相互に接続されている。尚、本実施形態では特に断らない限り、ＣＰＵ３０１がメインバス３００を介してＲＡＭ３０２、記憶部３０３、ネットワークＩ／Ｆ３０４を制御する。

図４は、本実施形態に係る情報処理システム全体のソフトウェア構成を説明する図である。図４に示す各機能部は、デバイス１０１，１０２、サーバ１０３のそれぞれが有しているＣＰＵ２０１，ＣＰＵ３０１が制御プログラムを実行することにより実現される。尚、図４では、デバイス１０２ではサービスプロバイダ４４０のみを示し、他のソフトウェア構成を省略して示している。

サーバ１０３は、Ｗｅｂアプリケーション４１０、通信部４０１を有する。更に、Ｗｅｂアプリケーション４１０には、プレゼンテーション部４１１及びロジック部４１２が含まれる。

プレゼンテーション部４１１は、通信部４０１を介して、デバイス１０１からのリクエストに応えてデバイス１０１のＷｅｂブラウザ４２０で表示すべき操作画面、又はサービスプロバイダ４４０への処理要求をレスポンスとしてデバイス１０１に送信する。また、デバイス１０１のＷｅｂブラウザ４２０に表示された操作画面を介して入力されたユーザからの入力情報を、通信部４０１を介してデバイス１０１から受け取る。

ロジック部４１２は、プレゼンテーション部４１１から渡されたデバイス１０１からの入力情報に対して処理を行う。例えば、ユーザからの入力に応じて、表示すべき画面の変更や、デバイスの機能を実行するための処理要求を作成する。通信部４０１は、ネットワークＩ／Ｆ３０４を制御してＨＴＴＰプロトコルにより通信を行うソフトウェアモジュールである。

デバイス１０１は、Ｗｅｂブラウザ４２０、重連アプリケーション４３０、サービスプロバイダ４４０を有している。Ｗｅｂブラウザ４２０、重連アプリケーション４３０、サービスプロバイダ４４０のそれぞれは、デバイス１０１が有しているＣＰＵ２０１が制御プログラムを実行することにより実現される。尚、Ｗｅｂブラウザ４２０は、サーバ１０３のコンテンツを表示するものに限定するものではない。同様に、サーバ１０３もＨＴＴＰプロトコルに従ってリクエスト／レスポンスを送受信するＷｅｂサーバに限定するものではない。即ち、Ｗｅｂブラウザ４２０は、任意のサーバと通信を行うことによってコンテンツを取得し、画面に表示するといった機能を有するものであればよい。

Ｗｅｂブラウザ４２０は、通信部４２１、解析部４２２、画面表示部４２３、重連アプリ起動部４２４、及びアップロード処理部４２５を有する。通信部４２１は、ＨＴＴＰプロトコルに従って、サーバ１０３の通信部４０１を介してＷｅｂアプリケーション４１０のプレゼンテーション部４１１と通信する。より具体的には、通信部４２１は、Ｗｅｂブラウザ４２０で表示した操作画面を介して入力される情報を、Ｗｅｂアプリケーション４１０に対するリクエストとして送信する。また通信部４２１は、Ｗｅｂアプリケーション４１０から送信されるレスポンスを受信する。

解析部４２２は、Ｗｅｂアプリケーション４１０から受信したレスポンスを解析する。このレスポンスには、Ｗｅｂブラウザ４２０に表示すべき操作画面の内容を示す記述であるＨＴＭＬデータや、サービスプロバイダ４４０への処理要求が記載されている。解析部４２２は、ＨＴＴＰレスポンスヘッダのＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドがａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃｏｍｐａｎｙ．Ｗｅｂｓｅｒｖｉｃｅと一致するかどうか確認する。一致する場合は、その受信したレスポンスに対する処理を重連アプリ起動部４２４に依頼する。

画面表示部４２３は、解析部４２２による解析結果に基づいて、ＨＴＭＬデータに基づく操作画面をを表示部２０７に表示する。重連アプリ起動部４２４は、解析部４２２による解析結果に基づいて、Ｗｅｂアプリケーション４１０から受信したレスポンスを処理要求とみなして、ジョブを処理するように重連アプリケーション４３０に依頼する。尚、レスポンスが、デバイス１０１への処理要求であるかどうかの判別が可能であれば、ＨＴＴＰレスポンスのヘッダを参照する以外の方法で判別しても良い。アップロード処理部４２５は、デバイス１０１の要求に応じて、指定されたデータを、通信部４２１を介してサーバ１０３に送信する。本実施形態では、ＨＴＴＰ ＰＯＳＴコマンドを用いて指定のデータをアップロードするが、Ｗｅｂブラウザ４２０が処理可能なプロトコルであれば何でもよい。

次に重連アプリケーション４３０について説明する。重連アプリケーション４３０は、通信部４３１、判断部４３２、処理部４３３、ジョブＩＤ管理部４３４、分割部４３５、結合部４３６を有する。通信部４３１は、処理部４３３から依頼を受け、デバイス１０１又は１０２のサービスプロバイダ４４０の通信部４４１に処理要求を送信し、また、その処理要求に対する結果をサービスプロバイダ４４０から受信する。判断部４３２は、処理部４３３からの処理要求に従って、その処理要求を分割してデバイス１０２に処理させる必要があるかどうかを判断する。また通信部４３１を介して処理部４３３が処理結果を受信した際に、その処理部４３３の要求に従ってジョブのステータスを判断する。

処理部４３３は、Ｗｅｂブラウザ４２０の重連アプリ起動部４２４からの依頼を受けると、判断部４３２での判断結果を基に、その処理要求を、分割部４３５で分割、或いは分割せずに、通信部４３１を介してサービスプロバイダ４４０に送信する。この場合の送信先は、デバイス１０１がネットワーク１００に存在するデバイスを動的に取得した送信先、或いは静的に保持しておいた送信先としてもよい。また、Ｗｅｂアプリケーション４１０から受信したレスポンスのヘッダに記載されている重連処理先（後述する）を送信先に指定してもよい。また処理部４３３は、結合部４３６により生成された処理結果を、Ｗｅｂブラウザ４２０にアップロードするように要求する。

ジョブＩＤ管理部４３４は、Ｗｅｂアプリケーション４１０からの処理要求と、処理部４３３からのサービスプロバイダ４４０への要求によって得られたジョブを紐づけて管理する。重連処理を行う場合、Ｗｅｂアプリケーション４１０からの処理要求が複数のデバイスに分割されるため、１つの処理要求が複数のジョブに分割されることになる。つまりは、ジョブＩＤ管理部４３４は、この対応関係を管理していることになる。

分割部４３５は、Ｗｅｂブラウザ４２０からの処理要求をデバイス１０１とデバイス１０２のサービスプロバイダ４４０で処理できるように分割する。結合部４３６は、デバイス１０１とデバイス１０２のサービスプロバイダ４４０からの処理結果を結合する。

本実施形態では、重連アプリケーション４３０は、Ｗｅｂブラウザ４２０と独立して動作している。但し、処理要求の分割と結合を行う機能を有すれば、重連アプリケーション４３０はヘルパーアプリケーションではなく、プラグインや、Ｗｅｂブラウザ４２０の一機能、又は受信したレスポンス内に記載されたＪａｖａＳｃｒｉｐｔ（登録商標）として存在しても良い。

次にデバイス１０１とデバイス１０２のサービスプロバイダ４４０について説明する。サービスプロバイダ４４０は、通信部４４１、ジョブ生成部４４２を有する。通信部４４１は、重連アプリケーション４３０から処理依頼を受け付ける。ジョブ生成部４４２は、通信部４４１が受け付けた処理依頼を受け取り、依頼された処理を実行するためのジョブを生成して実行する。
［実施形態１］
図５は、本発明の実施形態１に係る情報処理システムにおける一連の処理の流れを説明するシーケンス図である。このシーケンス図を参照して、このシステムで実施される処理を処理の順に詳しく説明する。尚、このシーケンス図で表される処理は、デバイス１０１，１０２を使用したプリントの重連処理である。尚、Ｗｅｂブラウザ４２０、重連アプリケーション４３０、サービスプロバイダ４４０で行われる処理は、ＲＡＭ２０２及び記憶部２０５に存在するデータを、メインバス２００を介してＣＰＵ２０１で実行される。また、Ｗｅｂアプリケーション４１０で行われる処理は、ＲＡＭ３０２に展開されたプログラムをＣＰＵ３０１が実行することにより実現される。更に、デバイス１０１，１０２及びサーバ１０３間の通信処理は、ネットワークＩ／Ｆ２０８及びネットワークＩ／Ｆ３０４を介して行われる。

まず、ユーザがデバイス１０１の入力部２０６から、Ｗｅｂブラウザ４２０を起動するためのボタン（不図示）の押下を受けると、Ｗｅｂブラウザ４２０を起動する。このボタンは、ハードウェアボタンに限ったものではなく、表示部２０７のタッチパネルに表示されたボタンでも良い。Ｗｅｂブラウザ４２０は起動すると、サーバ１０３のＷｅｂアプリケーション４１０に設定画面のリクエストを行う。この実施形態１では、設定画面のコンテンツを示すＵＲＬが予めデバイス１０１に設定されているものとする。

まずＳ５０１で、Ｗｅｂブラウザ４２０は、ＵＲＬで示されるコンテンツを保持するＷｅｂアプリケーション４１０に対して、ＨＴＴＰのＧＥＴコマンドによるリクエストを行う。具体的には、Ｗｅｂブラウザ４２０が通信部４２１を介してＨＴＴＰプロトコルによりサーバ１０３の通信部４０１と通信を行う。これによりサーバ１０３の通信部４０１は、その受け取ったＵＲＬに応じて、適切なＷｅｂアプリケーションに、その受け取ったデータを渡す。これにより、Ｗｅｂブラウザ４２０からＷｅｂアプリケーション４１０へのリクエストが行われる。以下、通信部４０１と通信部４２１の動作は省略して説明する。

次にＳ５０２で、Ｗｅｂアプリケーション４１０のプレゼンテーション部４１１が、Ｓ５０１のリクエストに応じて、設定画面のＨＴＭＬデータを作成し、ＨＴＴＰのレスポンスとしてＷｅｂブラウザ４２０に送信する。これによりＷｅｂブラウザ４２０は、その受け取ったＨＴＭＬデータを解析し、表示部２０７に設定画面を表示する。

図７は、本実施形態１においてＷｅｂアプリケーション４１０がＷｅｂブラウザ４２０に返すＨＴＴＰレスポンスヘッダの一例を示す図である。

このＨＴＴＰレスポンスヘッダは、宛先７０１、サービスコンテントタイプ７０２、アップロード宛先７０３、重連処理属性７０４、重連処理先７０５を有する。

宛先７０１は、重連アプリケーション４３０が処理要求であるＨＴＴＰレスポンスボディを送信する際の宛先である。宛先７０１は複数のサービスプロバイダが公開するサービスの何れかを指し示す。サービスコンテントタイプ７０２は、重連アプリケーション４３０が、サービスプロバイダ４４０にＨＴＴＰレスポンスボディを転送する際にＨＴＴＰヘッダのＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドに記載する内容である。ＨＴＴＰ Ｐｏｓｔコマンドを用いた処理要求送信の際に、処理先のサービスプロバイダ４４０が正しく理解できるＣｏｎｔｅｎｔ−Ｔｙｐｅを記載する必要があるためである。サービスコンテントタイプ７０２が省略されている場合は、重連アプリケーション４３０が送信時にデフォルトの値を設定するようにしても良い。アップロード宛先７０３は、Ｗｅｂブラウザ４２０が処理結果をＷｅｂアプリケーション４１０にアップロードする際の宛先である。重連処理属性７０４は、重連処理を行うかどうかの属性値である。重連処理先７０５は重連処理を行う場合に、どのデバイスで行うかを特定するための属性値であり、Ｗｅｂアプリケーション４１０により指定される。但し、重連処理先７０５が存在しない場合は、デバイス１０１がネットワーク１００上に存在するデバイスを動的に取得、もしくは静的に保持しておいたものが自動的に指定してもよい。

再び図５に戻り、Ｓ５０３では、Ｗｅｂブラウザ４２０は、Ｗｅｂアプリケーション４１０に対して、処理の実行を指示する。ここではユーザにより、Ｓ５０２で表示された設定画面のボタンが押されると、Ｗｅｂブラウザ４２０は、その設定画面で設定されたパラメータをＷｅｂアプリケーション４１０に通知する。この通信には、ＨＴＴＰプロトコルのＰＯＳＴコマンドを利用する。

次にＳ５０４では、Ｗｅｂアプリケーション４１０のロジック部４１２が、Ｓ５０３で送信された情報を基に、例えば図７に示すＨＴＴＰレスポンスヘッダと、ＨＴＴＰレスポンスボディを含む処理要求（図８（Ａ））を生成する。そして、ＨＴＴＰレスポンスヘッダとＨＴＴＰレスポンスボディとを合わせてＨＴＴＰレスポンスとしてＷｅｂブラウザ４２０に送信する。これによりＷｅｂブラウザ４２０は、Ｗｅｂアプリケーション４１０が送信したＨＴＴＰレスポンスを受信する。このＨＴＴＰレスポンスには、図７に示すＨＴＴＰレスポンスヘッダと、後述の図８（Ａ）に示す処理要求が含まれる。これらの詳細については後述する。

Ｓ５０５では、Ｗｅｂブラウザ４２０の解析部４２２は、Ｓ５０４で受信したＨＴＴＰレスポンスヘッダのＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドがａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ａｂｃ．Ｗｅｂｓｅｒｖｉｃｅと一致するかを判定する。一致する場合は、重連アプリ起動部４２４が、重連アプリケーション４３０の処理部４３３に対して、Ｓ５０４で受信したＨＴＴＰレスポンスボディを送信する。このとき、重連処理に必要な情報として、Ｓ５０４で受信したＨＴＴＰレスポンスヘッダを重連アプリケーション４３０に渡す。尚、ここでＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドがａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ａｂｃ．Ｗｅｂｓｅｒｖｉｃｅと一致しない場合は、解析部４２２は、ＨＴＭＬデータの解析結果に基づいて、表示部２０７に操作画面を表示する。

Ｓ５０６では、重連アプリケーション４３０の判断部４３２が、Ｓ５０５で受信した情報を基に重連処理を行うかどうかを判断する。本実施形態１では、判断部４３２は、Ｓ５０５で受信したＨＴＴＰレスポンスヘッダに記載されている重連処理属性７０４を参照し、その値が「ｔｒｕｅ」であれば重連処理を行い、「ｆａｌｓｅ」であれば重連処理を行わない、と判断する。尚、重連処理属性７０４は、Ｗｅｂアプリケーション４１０が指定するものとは限らない。例えば、ユーザがＷｅｂブラウザ４２０を介して入力した情報や、又は、ユーザがデバイスの設定画面を介して予め入力した情報であってもよい。また重連アプリケーション４３０は、重連処理先のデバイスの性能に合わせて、Ｓ５０５で受信したＨＴＴＰレスポンスを書き換えても良い。

例えば、図８を参照して後述するように、ＨＴＴＰレスポンスに含まれる処理要求（図８（Ａ））のプリント要求８０１には、プリントサイズ８０２が含まれるが、デバイスの性能によっては利用できるプリントサイズに制限がある。そこで、重連処理先のデバイスで動作させることが可能なプリントサイズの設定に書き換えることが考えられる。どのように情報を書き換えるかの条件とその値は、Ｗｅｂアプリケーション４１０から指示しても良く、或いは予めデバイス１０１に設定しておいてもよい。また、重連処理先のデバイス１０２から、その性能を取得して判断しても良い。

Ｓ５０７では、重連アプリケーション４３０の処理部４３３が、Ｓ５０６の重連判断を受けて、図９（Ａ）に示す重連設定画面を表示部２０７に表示する。

図９（Ａ）は、実施形態１に係る重連設定画面の一例を示す図である。

この重連設定画面は、重連処理先のデバイスの一覧と、そのデバイスが利用可能かどうかを示す情報の一覧が対となって構成されている。本実施形態１では、重連処理が実行できるデバイスＢが選択された状態であることを示している。尚、重連処理先のデバイスの一覧と、そのデバイスが利用可能かどうかの情報は、デバイスが、ＳＮＭＰなどを使って動的に取得して設定してもかまわないし、ユーザにより静的に設定されていても良い。また、Ｗｅｂアプリケーション４１０からの指示に含まれていても良い。

図８（Ａ）〜（Ｃ）は、本発明の実施形態１に係る処理要求とその分割の例を説明する図である。

図８（Ａ）は、処理要求８００の一例を示す。８０１はプリント要求を示し、８０２はプリントする用紙サイズ（プリントサイズ）で、図８（Ａ）ではＡ４サイズが指定されている。８０３はプリント部数で図８（Ａ）では２０部が設定されている。８０４はレスポンス先を示し、ここではＷｅｂアプリケーション４１０を示す「Ｗｅｂａｐｐｌｉｃａｔｉｏｎ」となっている。尚、このレスポンス先８０４は、図７のアップロード宛先７０３と同一にしてもよい。

図８（Ｂ）（Ｃ）は、図８（Ａ）の処理要求８００を分割した例を示す。ここでは処理要求８００が２つの処理要求８１０と８２０に分割され、それぞれ１０部ずつのプリント部数となっている。更に、これらに処理要求８１０と８２０では、レスポンス先が「ｄｅｖｉｃｅＡと」なっている。尚、プリント部数の分割比は、本実施形態１では均等にしているが、デバイスの処理能力から自動的に決定してもよい。また、デバイスに予め設定された比率を分割比としてもよい。更には、Ｗｅｂアプリケーション４１０からの要求に含めてもよい。次に、レスポンス先を「ｄｅｖｉｃｅＡ」としているのは、レスポンス先をＷｅｂアプリケーションのままにした場合、デバイス１０２のサービスプロバイダ４４０からＷｅｂアプリケーション４１０へ直接レスポンスが行われるため、それを防ぐためである。なぜならば、要求元のＷｅｂアプリケーション４１０としては、デバイス１０１への１つのプリントジョブに対し、デバイス１０１及びデバイス１０２からそれぞれレスポンスを受けることになり、ジョブの状況を監視することが難しくなるからである。このため、処理要求を分割するデバイスのアドレスをレスポンス先に設定している。尚、本実施形態１では、処理要求をＳＯＡＰメッセージに分割しているが、デバイスで処理可能な様態であればよく、これに限定されるものではない。以後、ＳＯＡＰメッセージの送信をＳＯＡＰリクエスト、ＳＯＡＰリクエストに対する応答をＳＯＡＰレスポンスと記す。

再び図５に戻り、Ｓ５０８では、重連アプリケーション４３０の処理部４３３がジョブＩＤを発行し、Ｗｅｂブラウザ４２０に通知する。このジョブＩＤ（以後、親ジョブＩＤ）は、プリント要求８０１に対応するプリントジョブの識別子である。そして、処理部４３３は、ジョブＩＤ管理部４３４に親ジョブＩＤを登録する。

Ｓ５０９では、Ｗｅｂブラウザ４２０が、取得したジョブＩＤをＨＴＴＰ Ｐｏｓｔ リクエストにより、Ｗｅｂアプリケーション４１０に通知する。これにより、Ｗｅｂアプリケーション４１０は、このジョブＩＤを介して、デバイス１０１にジョブ状況を問い合わせられるようになる。

Ｓ５１０では、Ｗｅｂアプリケーション４１０が、Ｓ５０９のリクエストに対するレスポンスを行う。Ｓ５１１では、重連アプリケーション４３０の分割部４３５が処理要求８００を分割する。具体的には、本実施形態１では、プリント要求８０１に、プリントサイズ８０２がＡ４、プリント部数８０３が２０部、レスポンス先８０４がＷｅｂａｐｐｌｉｃａｔｉｏｎが設定されている。尚、レスポンス先８０４は、アップロード宛先７０３と同一にしてもよい。分割部４３５は、このプリント要求８０１を解析し、デバイス１０１及びデバイス１０２で処理できるように、図８（Ｂ）の処理要求８１０と図８（Ｃ）の処理要求８２０とに分割する。処理要求８１０と処理要求８２０はともにプリント部数が１０部で、レスポンス先がｄｅｖｉｃｅＡとなっている。

Ｓ５１２では、重連アプリケーション４３０の処理部４３３は、分割して生成した処理要求８１０（ＳＯＡＰメッセージ）を、ＳＯＡＰリクエストとして通信部４３０から、デバイス１０１のサービスプロバイダ４４０の通信部４４１に送信する。尚、以降では、通信部４３１と通信部４４１の処理の説明は省略する。

Ｓ５１３では、デバイス１０１のサービスプロバイダ４４０はジョブＩＤ（以後、子ジョブＩＤ１００２（図９（Ｂ）））を発行し、重連アプリケーション４３０に通知する。Ｓ５１４では、通知をうけた重連アプリケーション４３０は、この子ジョブＩＤ１００２を、Ｓ５０８で通知した親ジョブＩＤと対応付けて、ジョブＩＤ管理部４３４に登録要求する。

Ｓ５１５では、重連アプリケーション４３０の処理部４３３は、分割して生成した処理要求８２０（ＳＯＡＰメッセージ）をＳＯＡＰリクエストとして、デバイス１０２のサービスプロバイダ４４０に送信する。Ｓ５１６で、デバイス１０２のサービスプロバイダ４４０は子ジョブＩＤ１００３（図９（Ｂ））を発行し、デバイス１０１の重連アプリケーション４３０に通知する。Ｓ５１７で、通知をうけた重連アプリケーション４３０は、この子ジョブＩＤ１００３をＳ５０８で通知した親ジョブＩＤと対応付けて、ジョブＩＤ管理部４３４に登録要求する。尚、Ｓ５０８，Ｓ５１４，Ｓ５１６で登録された親ジョブＩＤと、子ジョブＩＤ１００２、子ジョブＩＤ１００３は、図９（Ｂ）のジョブ関係対応表のようにジョブＩＤ管理部４３４によって管理されている。これにより、親ジョブＩＤ１００１から対応する子ジョブＩＤを特定できる。

図９（Ｂ）は、実施形態１に係るデバイス１０１のジョブＩＤ管理部４３４が管理している親ジョブＩＤと子ジョブＩＤとの対応付けを記憶するテーブルの一例を示す図である。

次にＳ５１８，Ｓ５１９では、デバイス１０１及びデバイス１０２のサービスプロバイダ４４０によって印刷部２０４へのプリント要求が行われ、プリント処理が実行される。そしてＳ５２０で重連アプリケーション４３０の処理部４３３は、子ジョブＩＤ１００２のステータスの取得をＳＯＡＰリクエストとしてデバイス１０１のサービスプロバイダ４４０に要求する。これによりＳ５２１でサービスプロバイダ４４０は、ＳＯＡＰレスポンスとしてＲｅｓｕｌｔＣｏｄｅ ＯＫを含んだ処理結果を重連アプリケーション４３０に通知する。またＳ５２２でデバイス１０１の重連アプリケーション４３０の処理部４３３は、デバイス１０２で実行されている子ジョブＩＤ１００３のステータスの取得をＳＯＡＰリクエストとしてデバイス１０２のサービスプロバイダ４４０に要求する。これによりＳ５２３で、デバイス１０２のサービスプロバイダ４４０は、ＳＯＡＰレスポンスとしてＲｅｓｕｌｔＣｏｄｅ ＯＫを含んだ処理結果を重連アプリケーション４３０に通知する。

こうしてＳ５２４でデバイス１０１の重連アプリケーション４３０の結合部４３６は、子ジョブＩＤ１００２と子ジョブＩＤ１００３のステータスがともにＯＫであるため、親ジョブＩＤに対応するステータスとしてＯＫを含んだ処理結果を生成する。更に、この処理結果には、どのデバイスで処理されたかを表す対象デバイスに関する情報を含んでいてもよい。そしてＳ５２５で重連アプリケーション４３０の処理部４３３は、Ｗｅｂブラウザ４２０のアップロード処理部４２５に対して、処理結果をＷｅｂアプリケーション４１０に対してアップロードするように依頼する。この依頼に際して処理部４３３は、アップロード処理部４２５に対してアップロードの宛先として、レスポンス先８０４を指定する。このレスポンス先８０４は、図７のＨＴＴＰレスポンスヘッダに記載されており、重連アプリケーション４３０からアップロード処理部４２５に指定せず、Ｗｅｂブラウザ４２０がこの情報を記憶しておいてその情報を使用してもよい。また宛先を固定値とし、Ｗｅｂアプリケーション４１０から指定しないシステムとしても良い。その他、Ｗｅｂアプリケーション４１０が必要とする情報を記載しても良い。

こうしてＳ５２６でアップロード処理部４２５は、通信部４２１を介してＨＴＴＰ ＰＯＳＴコマンドで、処理部４３３からの依頼に従って処理結果をサーバ１０３にアップロードする。このとき、重連アプリケーション４３０の処理部４３３から依頼された宛先８０４に対してアップロードを行う。Ｓ５２７でＷｅｂアプリケーション４１０は、Ｗｅｂブラウザ４２０に対して、画面表示用のＨＴＭＬコンテンツをレスポンスする。このレスポンスを受け取ったＷｅｂブラウザ４２０は、解析部４２２によるＨＴＭＬデータの解析結果に基づいて、表示部２０７に操作画面を表示する。

図１０（Ａ）〜（Ｃ）は、本発明の実施形態１におけるデバイス１０１の重連アプリケーション４３０の処理部４３３で作成される処理結果の一例を説明する図である。

図１０（Ａ）は、図５のＳ５２１で、デバイス１０１のサービスプロバイダ４４０がＳＯＡＰレスポンスとして送信する処理結果を示す。ここではジョブＩＤ「１２３４」（図９（Ｂ）よりデバイス１０１のサービスプロバイダ４４０が実行したジョブ）のジョブの処理結果（ResultCode）が「ＯＫ」であることが記述されている。

図１０（Ｂ）は、図５のＳ５２３で、デバイス１０２のサービスプロバイダ４４０がＳＯＡＰレスポンスとして送信する処理結果を示す。ここではジョブＩＤ「２３４５」（図９（Ｂ）よりデバイス１０２のサービスプロバイダ４４０が実行したジョブ）のジョブの処理結果（ResultCode）が「ＯＫ」であることが記述されている。

図１０（Ｃ）は、デバイス１０１の重連アプリケーション４３０の結合部４３６が生成した処理結果を示す図である。ここでは子ジョブＩＤ１００２と子ジョブＩＤ１００３のステータスがともに「ＯＫ」であるため、親ジョブＩＤ「１２３４５」（図９（Ｂ）参照）に対応するステータスとしてＯＫを含む処理結果となっている。尚、図１０（Ｃ）では、そのジョブが、どのデバイスで処理されたかを表す対象デバイス１０２１に関する情報も含まれている。

図６は、本実施形態１に係るデバイス１０１の重連アプリケーション４３０が処理要求を受け付けて処理結果を応答するまでの処理を説明するフローチャートである。尚、この処理を実行するプログラムは実行時に、デバイス１０１の記憶部２０５からＲＡＭ２０２に展開されＣＰＵ２０１の制御の下に実行されることにより、この処理が達成される。尚、このフローチャートで示す処理はデバイス１０１のＣＰＵ２０１により実行されるが、以下の説明では、デバイス１０１の重連アプリケーション４３０による処理として説明する。

まずＳ６０１で重連アプリケーション４３０の処理部４３３が、Ｗｅｂブラウザ４２０からＨＴＴＰヘッダ、ＨＴＴＰボディを含んだ処理要求８００を受信する。次にＳ６０２に進み判断部４３２は、その処理要求８００を解析し、そのＨＴＴＰヘッダに重連処理属性７０４が「ｔｒｕｅ」かどうかを判定する。「ｔｒｕｅ」であればＳ６０４へ、属性値が「ｔｒｕｅ」でないとき、即ち、「ｆａｌｓｅ」であればＳ６０３へ処理を移す。Ｓ６０３では重連処理を行わないため、デバイス１０１のサービスプロバイダ４４０に、その処理要求に従った処理を要求して、この処理を終了する。

Ｓ６０４で処理部４３３は、図９（Ａ）で説明した重連設定画面を表示部２０７に表示する。尚、本実施形態１では、この重連設定画面を重連アプリケーション４３０が生成、出力しているが、Ｗｅｂアプリケーション４１０が作成し、Ｗｅｂブラウザ４２０により表示してもかまわない。その場合は、処理部４３３による重連設定画面の表示処理は省略してもよい。そしてステップ６０５に進み処理部４３３は、重連処理の実行通知を受信するとＳ６０６に進む。Ｓ６０６で処理部４３３は、親ジョブＩＤを発行してＷｅｂブラウザ４２０にアップロードを依頼する。次にＳ６０７に進み処理部４３３は、処理要求８００を解釈し、前述したように処理要求８１０と処理要求８２０に分割する。この場合の分割の仕方については、特に限定しない。そしてＳ６０８に進み処理部４３３は、デバイス１０１のサービスプロバイダ４４０に処理要求８１０をＳＯＡＰリクエストとして送信してＳ６０９に進む。Ｓ６０９で処理部４３３は、デバイス１０１のサービスプロバイダ４４０からＳＯＡＰレスポンスを受信する。このレスポンスには子ジョブＩＤ１００２が含まれている。次にＳ６１０に進み処理部４３３は、デバイス１０２のサービスプロバイダ４４０に処理要求８１０をＳＯＡＰリクエストとして送信してＳ６１１に進む。Ｓ６１１で処理部４３３は、デバイス１０１のサービスプロバイダ４４０からＳＯＡＰレスポンスを受信する。このレスポンスには子ジョブＩＤ１００３が含まれている。

次にＳ６１２に進み処理部４３３は、親ジョブＩＤのジョブ状況の取得要求を受け付ける。尚、この要求元は、Ｗｅｂアプリケーション４１０からのポーリングによるものや、デバイス１０１で生成されたジョブ状況の監視スレッドによるもの等が挙げられるが、Ｗｅｂアプリケーション４１０がジョブ状況を取得できる様態であればよい。即ち、サーバ１０３がプッシュ型に対応していなければ、Ｗｅｂアプリケーション４１０からのポーリングによる要求であり、ＷｅｂＳｏｃｋｅｔなどのプッシュ型に対応していれば、デバイス１０１からの要求でも構わず、ジョブ状況の要求元は限定されない。

次にＳ６１３に進み処理部４３３は、親ジョブＩＤからジョブＩＤ管理部４３４に子ジョブＩＤ１００２と子ジョブＩＤ１００３を取得し、それぞれの子ジョブＩＤに対応するサービスプロバイダ４４０へステータスの問い合わせを行う。次にＳ６１４に進み判断部４３２は、デバイス１０１のサービスプロバイダ４４０からの処理結果（例えば図１０（Ａ））とデバイス１０２のサービスプロバイダ４４０からの処理結果（例えば図１０（Ｂ）とを受け取って解析する。そして全ての処理結果のＲｅｓｕｌｔＣｏｄｅがＯＫかどうかを判定し、ＯＫであればＳ６１５へ、そうでなければＳ６１６へ処理を進める。Ｓ６１５で処理部４３３は、ＲｅｓｕｌｔＣｏｄｅをＯＫにする。一方、Ｓ６１６で判断部４３２は、サービスプロバイダ４４０からのレスポンスがタイムアウトしていないかを判定する。タイムアウトしていなければＳ６１７へ、タイムアウトしていればＳ６１８へ処理を進める。Ｓ６１７で処理部４３３はＲｅｓｕｌｔＣｏｄｅをジョブの実行中を表す「ｅｘｅｃｕｔｉｎｇ」にしてＳ６１９に処理を進める。一方Ｓ６１８で処理部４３３は、ＲｅｓｕｌｔＣｏｄｅをジョブのタイムアウトを表す「ｔｉｍｅｏｕｔ」にしてＳ６１９に進む。

Ｓ６１９で結合部４３６は、親ジョブＩＤとＲｅｓｕｌｔＣｏｄｅとを付加して、例えばず１０（Ｃ）に示すような処理結果を生成する。尚、この処理結果には、どのデバイスで処理されたかを表す対象デバイス１０２１を付加しても構わない。そしてＳ６２０に進み処理部４３３は、その処理結果をＷｅｂブラウザ４２０にアップロードするように依頼してＳ６２１に進む。Ｓ６２１で判断部４３２は、ＲｅｓｕｌｔＣｏｄｅがＯＫもしくは、ｔｉｍｅｏｕｔかどうかを確認し、そうであれば、この処理を終了する。一方、それ以外であればジョブは実行中であるためＳ６１２に戻り、ジョブのステータスの取得要求を待つ。

以上説明したように本実施形態１によれば、デバイスのＷｅｂブラウザを介して得られたＷｅｂサーバからのリクエスト（処理要求）を、そのデバイスが分割して内部ネットワークの他のデバイスに処理させることができる。これにより、ファイアウォールを超えて、Ｗｅｂサーバからのリクエストを受信して複数のデバイスで分担して処理できる。

また、複数のデバイスでの処理結果を統合して、ＷｅｂブラウザからＷｅｂアプリケーションにアップロードする。これにより、例えば、インターネット環境下にあるＷｅｂアプリケーションからのプリント要求に基づいて、内部ネットワークの複数のデバイスが分担して、そのプリント要求に対応するプリントジョブを並行して実行できる。そして、複数のデバイスによるプリントジョブの処理結果を、サーバのＷｅｂアプリケーションが把握できるため、Ｗｅｂアプリケーションからユーザに対して重連処理の処理結果を通知できる。

こうして外部ネットワークに存在するＷｅｂサーバからのリクエストであっても、内部ネットワーク内の複数のデバイスを活用できるようになるため、生産性が向上する。更には、ユーザが、その処理要求に基づく処理が、どのデバイスで実行されたかを把握できるようになり、利便性が高まる。

［実施形態２］
次に本発明の実施形態２について説明する。この実施形態２では、Ｗｅｂアプリケーション４１０の指示に従ってデバイス１０１の重連アプリケーション４３０がファクシミリの重連処理を行う例を説明する。尚、この実施形態２に係るシステム構成、及びデバイス１０１，１０２、サーバ１０３のハードウェア構成は前述の実施形態１と同様であるため、その説明を省略する。

図１１は、本実施形態２に係る重連アプリケーション４３０が処理要求を受け付けてから、処理結果の応答までの処理を説明するフローチャートである。尚、この処理を実行するプログラムは実行時に、デバイス１０１の記憶部２０５からＲＡＭ２０２に展開されＣＰＵ２０１の制御の下に実行されることにより、この処理が達成される。

図１２は、本発明の実施形態２に係る処理要求とその分割の例を説明する図である。

まずＳ１１０１で重連アプリケーション４３０の処理部４３３は、重連処理を含む処理要求１２００（図１２（Ａ））を受信してＳ１１０２に進む。Ｓ１１０２で重連アプリケーション４３０の分割部４３５は、図１２（Ａ）で示す処理要求１２００を分割する。具体的には、本実施形態２では、Ｆａｘ同報送信要求１２０１に、Ｆａｘの送信データとしてＦａｘＤａｔａタグで「ｄｅｖｉｃｅＡ．ｂｏｘ．０１」が、送信宛先としてＰｈｏｎｅＮｕｍｂｅｒｓタグで複数の電話番号が設定されている。尚、本実施形態２では、Ｆａｘの送信データについては、デバイス１０１の読取部２０３を介して記憶部２０５に保存されたものが指定されている。但し、サーバ１０３の記憶部３０３に保存されているデータを、Ｗｅｂアプリケーション４１０からの処理要求に付加することで指定してもよい。尚、その場合には、サーバ１０３からのデータが、デバイス１０１の記憶部２０５に保存されるため、ａｘＤａｔａタグの指定方法に違いはない。そして分割部４３５は、このＦａｘ同報送信要求１２０１を解析し、デバイス１０１及びデバイス１０２で処理できるように、図１２（Ｂ）の処理要求１２１０と図１２（Ｃ）の処理要求１２２０とに分割する。処理要求１２１０と処理要求１２２０は、送信宛先が分割され、レスポンス先がｄｅｖｉｃｅＡとなっている。尚、この送信宛先の分割比は、均等でも良く、或いは、各デバイスの最大同報送信能力等の処理能力から自動的に決定してもよい。また、デバイスに予め設定された比率を分割比としてもよい。更には、Ｗｅｂアプリケーション４１０からの要求に含めてもよい。尚、本実施形態２では、処理要求１２００をＳＯＡＰメッセージに分割しているが、デバイスで処理可能な様態であればよく、これに限定されるものではない。そしてＳ１１０３に進み、前述の図６のＳ６０８〜Ｓ６２１で説明したように、各デバイスでの処理結果を受け取って、その処理結果をサーバ１０３にアップロードする。

以上説明したように本実施形態２によれば、インターネット環境下にあるサーバのＷｅｂアプリケーションからの要求に基づいて、ＦＡＸの同報送信においても、複数のデバイスを活用することでより多くのジョブを並行して処理できる。

これにより、外部ネットワークに存在するＷｅｂサーバからのリクエストであっても、内部ネットワーク内の複数のデバイスを活用できるようになるため、生産性が向上し、ユーザの利便性を高められる。

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

Claims (13)

1. Ｗｅｂサーバに接続され、当該Ｗｅｂサーバにより提供される操作画面を表示可能なＷｅｂブラウザを備えた情報処理装置であって、
   前記Ｗｅｂサーバから受け取った処理要求を他の情報処理装置と分担して実行できるかどうかを判定する判定手段と、
   前記判定手段により実行できると判定すると前記処理要求を前記情報処理装置と前記他の情報処理装置との処理に分割して、前記情報処理装置と前記他の情報処理装置に実行させる処理手段と、
   前記処理手段により前記情報処理装置と前記他の情報処理装置で実行された処理の結果をまとめて前記処理要求に対する処理結果として前記Ｗｅｂサーバに通知する通知手段と、
   を有することを特徴とする情報処理装置。
2. 前記判定手段は、前記処理要求に含まれる属性に基づいて、前記処理要求を他の情報処理装置と分担して実行できるかどうかを判定することを特徴とする請求項１に記載の情報処理装置。
3. 前記処理手段は、前記情報処理装置と前記他の情報処理装置のサービスプロバイダにＳＯＡＰリクエストとして前記分割した処理要求を送信することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記処理手段は、前記処理を実行できる情報処理装置の一覧を表示し、前記一覧からユーザが選択した情報処理装置を前記他の情報処理装置に決定することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記処理手段は、前記処理要求で要求された処理を実行できる前記他の情報処理装置を前記Ｗｅｂサーバからの指示により決定することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
6. 前記処理手段は、前記Ｗｅｂサーバから受け取った処理要求と、前記処理要求を分割した処理要求のそれぞれをＩＤにより対応付けて管理することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 前記処理手段は、前記処理要求を前記情報処理装置と前記他の情報処理装置のそれぞれの処理能力に応じて分割することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
8. 前記処理手段は、前記Ｗｅｂサーバからの指示に基づいて前記処理要求を前記情報処理装置と前記他の情報処理装置のそれぞれに分割することを特徴とする請求項５に記載の情報処理装置。
9. 前記Ｗｅｂブラウザは、ＨＴＴＰのＧＥＴコマンドにより前記Ｗｅｂサーバに操作画面の情報を要求し、前記操作画面を介して入力された指示に従って前記ＷｅｂサーバにＨＴＴＰのＰＯＳＴコマンドを送信し、前記ＨＴＴＰのＰＯＳＴコマンドに対するＨＴＴＰレスポンスとして前記処理要求を受信することを特徴とする請求項１に記載の情報処理装置。
10. 前記情報処理装置と前記他の情報処理装置はネットワークを介して接続されており、前記Ｗｅｂサーバは、前記ネットワークの外部ネットワークに接続されていることを特徴とする請求項１乃至９のいずれか１項に記載の情報処理装置。
11. Ｗｅｂサーバに接続され、当該Ｗｅｂサーバにより提供される操作画面を表示可能なＷｅｂブラウザを備えた情報処理装置を制御する制御方法であって、
    判定手段が、前記Ｗｅｂサーバから受け取った処理要求を他の情報処理装置と分担して実行できるかどうかを判定する判定工程と、
    処理手段が、前記判定工程で実行できると判定すると前記処理要求を前記情報処理装置と前記他の情報処理装置との処理に分割して、前記情報処理装置と前記他の情報処理装置に実行させる処理工程と、
    通知手段が、前記処理工程で前記情報処理装置と前記他の情報処理装置で実行された処理の結果をまとめて前記処理要求に対する処理結果として前記Ｗｅｂサーバに通知する通知工程と、
    を有することを特徴とする情報処理装置の制御方法。
12. コンピュータを、請求項１乃至１０のいずれか１項に記載の情報処理装置として機能させるためのプログラム。
13. 請求項１２に記載のプログラムを記憶した、コンピュータにより読み取り可能な記憶媒体。

Images