(57)【要約】      （修正有）【課題】  プロキシに転送サイズ制限がかかった環境下でも容易にＨＴＴＰを使ったデータ転送を行えるようにする。【解決手段】データをＨＴＴＰプロトコルを用いて転送する機能を持つ通信装置において、送信データの分割サイズを決定する決定手段と、送信データを複数のＨＴＴＰパケットに分割する手段と、分割したデータにデータ番号を付加して送信する手段を設けて、データを最大転送サイズ内に分割して、サーバに転送すると共に、サーバ側では、分割受信したデータを一つのファイルに集約する処理を行う。【選択図】  図１２
2006019802.tif 000002
【特許請求の範囲】
【請求項１】
データをＨＴＴＰプロトコルを用いて転送する機能を持つ通信装置において、
送信データの分割サイズを決定する決定手段と、
送信データを複数のＨＴＴＰパケットに上記分割サイズで分割する手段と、
分割したデータにデータ番号を付加し、送信する手段と、
を有し、
サーバに対して、データを送信する場合に、データを分割して送信することを特徴とするＨＴＴＰデータ送信手段をもつことを特徴とする通信クライアント。
【請求項２】
データをＨＴＴＰプロトコルを用いて、転送する機能を持つ通信装置において、
複数のＨＴＴＰパケットに分割されたデータを受信する手段と、
分割受信したデータをまとめたデータとして取り扱う手段と、
を具備することを特徴とする通信サーバ。
【請求項３】
請求項１の分割サイズを決定する手段は、通信装置がもつユーザインターフェースからサイズを入力することを特徴とする通信装置。
【請求項４】
請求項１の分割サイズを決定する手段は、通信装置が接続するサーバから指定することを特徴とする通信装置。
【請求項５】
請求項１の分割サイズを決定する手段は、通信装置が接続するサーバからサイズを取得できなかった場合には、通信装置が持つユーザインターフェースからサイズを取得することを特徴とする通信装置。
【請求項６】
請求項１で記載されている通信クライアントと請求項２で記載されている通信サーバからなるシステムであることを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＨＴＴＰデータ通信における大量データの通信方法に関するものである。
【背景技術】
【０００２】
ＨＴＴＰプロトコルをトランスポートとして用いてデータ転送を行う方法は、現在、さまざまな用途に用いられ、一般的になってきている。このような環境下では、たとえば画像データや、印刷データなど、サイズの大きいデータをＨＴＴＰを用いて、通信を行うことも可能である。また、ＨＴＴＰを用いてデータ転送を行うメリットとして、プロキシを超えて、通信を行うこともできるといったメリットを持つ。
【特許文献１】特開２００２−２８７９３１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、近年、セキュリティについての関心が高まる中、プロキシの設定により、一回のＨＴＴＰのデータ転送サイズの上限を設けるような設定が可能になってきている。たとえば、オフィス内からプロキシを介して、インターネット上のサーバにデータを転送する場合、ＨＴＴＰプロトコルのＰＯＳＴ処理を用いてデータ転送がなされるが、オフィス内の情報漏洩を防ぐため、プロキシを介したＨＴＴＰのＰＯＳＴ処理には、１回のＰＯＳＴ処理に対して、最大転送サイズ４０Ｍバイトといった制限をかけ、オフィス内からインターネット上に大量のデータを転送させないような設定が行われる場合がある。
【０００４】
一方、オフィス内の電子ドキュメントや、電子画像データをインターネット上のストレージサービスに登録するサービスも行われており、こうしたサイズ制限のかかったプロキシ環境化では、ユーザが転送サイズの上限を意識して、上限を超える場合には、送信データを２つ以上のファイルに分けたりしなければならないという問題点があった。
【課題を解決するための手段】
【０００５】
本発明は上記課題に鑑みてなされたものであり、ユーザがプロキシの最大転送サイズを装置に設定することによって、その装置がデータを最大転送サイズ内に分割して、サーバに転送すると共に、サーバ側では、分割受信したデータを一つのファイルに集約する処理を行うことによって、プロキシに転送サイズ制限がかかった環境下でも容易にＨＴＴＰを使ったデータ転送が行える環境を提供することを目的とする。
【０００６】
そのために、本発明では以下のような特徴をもつ。
【０００７】
データをＨＴＴＰプロトコルを用いて転送する機能を持つ通信装置において、送信データの分割サイズを決定する決定手段と、送信データを複数のＨＴＴＰパケットに上記分割サイズで分割する手段と、分割したデータにデータ番号を付加し、送信する手段とを有し、サーバに対して、データを送信する場合に、データを分割して送信することを特徴とするＨＴＴＰデータ送信手段をもつ通信クライアント。
【０００８】
また、データをＨＴＴＰプロトコルを用いて、転送する機能を持つ通信装置において、複数のＨＴＴＰパケットに分割されたデータを受信する手段と、分割受信したデータをまとめたデータとして取り扱う手段とを具備する通信サーバ。
【０００９】
請求項１の分割サイズを決定する手段は、通信装置がもつユーザインターフェースからサイズを入力する。
【００１０】
請求項１の分割サイズを決定する手段は、通信装置が接続するサーバから指定する。
【００１１】
請求項１の分割サイズを決定する手段は、通信装置が接続するサーバからサイズを取得できなかった場合には、通信装置が持つユーザインターフェースからサイズを取得する
請求項１で記載されている通信クライアントと請求項２で記載されている通信サーバからなる。
【発明の効果】
【００１２】
装置がデータを最大転送サイズ内に分割して、サーバに転送すると共に、サーバ側では、分割受信したデータを一つのファイルに集約する処理を行うことによって、プロキシに転送サイズ制限がかかった環境下でも容易にＨＴＴＰを使ったデータ転送が行うことができる。
【発明を実施するための最良の形態】
【００１３】
以下、添付の図面を参照して本発明の実施例を詳細に説明する。
【００１４】
図１は、本実施例のＨＴＴＰクライアント装置、およびＨＴＴＰサーバ装置として、ネットワーク接続機能を持つマルチファンクションデバイスがＬＡＮに接続している概略図である。
【００１５】
１０１はＨＴＴＰ通信が可能なマルチファンクションデバイス装置で、本実施例ではスキャンした画像をＨＴＴＰ通信で転送するデバイスである。１０２はファイアーウォールである。１０１のマルチファンクションデバイスは１０２のファイアーウォールで守られているオフィス内にある。１０３はインターネット上にあるマルチファンクションデバイスで、プリント機能を持つ。
【００１６】
本実施例では、デバイス１０１からファイアーウォール１０２を介して、インターネット上に接続されているデバイス１０３に対して、デバイス１０１で読み込んだスキャナデータをデバイス１０３にプリントアウトするものである。
【００１７】
図２は、本実施例における１０１，１０３のマルチファンクションデバイス装置の概略を表すブロック図である。
【００１８】
２０１はスキャナエンジン２１３を制御するスキャナエンジン制御部、２０２はＣＰ、，２０３はプログラムが可能されているブートロム、２０４はＲＡＭ、２０５はパネルから設定された値を保持しておくための不揮発性のＲＡＭ（ＮＶＲＡＭ）、２０６はプリンタエンジン２１２を制御するエンジン制御部、２０７はＨＤＤ、２０８はタイマ、２０９はパネルやボタンランプといったユーザインターフェース部分２１４を制御するＩ／Ｏ制御部、２１０はネットワーク制御部で、それぞれがバス２１１に接続している。
【００１９】
図３は本実施例でデバイス１０１，１０３が所有するユーザインターフェース部分である。
【００２０】
３０１は大型タッチパネルで、ユーザはタッチパネルを操作することで、各種設定を行うことが可能である。図の画面はコピーの待機画面である。３０２はテンキーボタンで、１から０の数字を入力するのに使う。Ｓのボタンはサービスボタンで、このボタンを押下することにより、タッチパネル上に各種サービス画面が出現し、コピー以外のサービスを行うことができる。Ｒのボタンは設定ボタンで、このボタンを押下することによって、タッチパネル上に、各種設定画面が出現し、パラメータの設定を行うことができる。３０３はスピーカで、音声やブザー等をここから出力する。３０４はランプで、印刷やコピーがジャムした場合には、ランプが点滅する。
【００２１】
図４は、１０１のデバイスのネットワーク周りの制御を行うモジュール構成のブロック図を示したものである。
【００２２】
４０１はＥｔｈｅｒＤｒｉｖｅｒでオフィスＬＡＮに接続して、Ｅｔｈｅｒｎｅｔ（登録商標）のパケットの送受信を行うためのドライバモジュールである。４０２はＴＣＰ／ＩＰプロトコルスタックである。本発明のデバイスはマルチプロトコルをサポートし、ＮｅｔＷａｒｅやＡｐｐｌｅＴａｌｋといったプロトコルでも通信が可能であるが、ここでは記述を省略している。４０３はソケットレイヤーである。ＴＣＰ／ＩＰプロトコルを用いるためのＡＰＩが定義されている。ＴＣＰ／ＩＰを用いて通信を行うプログラムはすべてソケットレイヤーが提供するＡＰＩを用いて、その通信を行う。４０４はＨＴＴＰＣｌｉｅｎｔモジュールで、ＨＴＴＰ処理機能をもち、ＨＴＴＰプロトコルを用いて、相手先と通信を行う。４０５はＳＯＡＰモジュール、４０６はスキャナサービスモジュールでＳＯＡＰ／ＸＭＬを使ったスキャンＴｏプリントサービスを実現するためのモジュールである。デバイス１０１ではスキャンサービス４０６がパネルからの入力指示によって、スキャナエンジン２１３からスキャンした画像をＳＯＡＰモジュール４０５、ＨＴＴＰクライアントモジュール４０４を用いて、プリントデバイス１０１に転送するものである。
【００２３】
図５は、１０３のデバイスのネットワーク周りの制御を行うモジュール構成のブロック図を示したものである。
【００２４】
５０１はＥｔｈｅｒＤｒｉｖｅｒでインターネットに接続して、Ｅｔｈｅｒｎｅｔ（登録商標）のパケットの送受信を行うためのドライバモジュールである。５０２はＴＣＰ／ＩＰプロトコルスタックである。本発明のデバイスはマルチプロトコルをサポートし、ＮｅｔＷａｒｅやＡｐｐｌｅＴａｌｋといったプロトコルでも通信が可能であるが、ここでは記述を省略している。５０３はソケットレイヤーである。ＴＣＰ／ＩＰプロトコルを用いるためのＡＰＩが定義されている。ＴＣＰ／ＩＰを用いて通信を行うプログラムはすべてソケットレイヤーが提供するＡＰＩを用いて、その通信を行う。５０４はＨＴＴＰＳｅｒｖｅｒモジュールで、ＨＴＴＰ処理機能をもち、ＨＴＴＰプロトコルを用いて、相手先と通信を行う。５０５はＳＯＡＰモジュール、５０６はプリントサービスモジュールでＳＯＡＰ／ＸＭＬを使ったスキャンＴｏプリントサービスを実現するためのモジュールである。デバイス１０３ではスキャナデバイス１０１から受信したＳＯＡＰ／ＸＭＬを用いたＨＴＴＰデータからプリントデータを抽出して、エンジン制御２０６を介してプリンタエンジン２１２に送られ、印刷されることになる。
【００２５】
図６は、本実施例におけるＨＴＴＰ上のＳＯＡＰプリントサービスのプロトコルで、クライアントから印刷装置に送信されるＣｒｅａｔｅＪｏｂと称されるパケットデータの一例である。このデータはＸＭＬ形式で記述されている。ＣｒｅａｔｅＪｏｂパケットは、印刷装置に対し、ジョブ（印刷）の開始を指示するコマンドであり、要求元のユーザ名（＜ｒｅｑｕｅｓｔｉｎｇ−ｕｓｅｒ−ｎａｍｅ＞タグ）やジョブの処理に関する指示（＜ｊｏｂ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグ）等の情報が記述されている。＜ｊｏｂ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグには印刷部数を設定する＜ｃｏｐｉｅｓ＞タグ、両面印刷を設定する＜ｓｉｄｅｓ＞タグ、印刷の仕上げを設定する＜ｆｉｎｉｓｈｉｎｇ＞タグなどが含まれ、印刷装置はこれらのタグに設定された値に基づき、ジョブの処理を行う。さらに、＜ｊｏｂ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグにはオプションとして＜ｎｏｔｉｆｉｃａｔｉｏｎ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグを含めることも可能である。この＜ｎｏｔｉｆｉｃａｔｉｏｎ−ｉｎｓｔｒｕｃｔｉｏｎ＞タグにはジョブに関する通知情報が記述される。図６の例においては通知情報として、通知先を設定する＜ｎｏｔｉｆｉｃａｔｉｏｎ−ｒｅｃｉｐｉｅｎｔ＞タグおよび通知条件を設定する＜ｅｖｅｎｔ＞タグが記述されている。印刷装置はこれらのタグに設定された値に基づいてイベント送信処理を行う。本実施例では、ｊｏｂ−ｃｏｍｐｌｅｔｅｄおよび、ｊｏｂ−ｃａｎｃｅｌｅｄが指定されているため、ジョブ印刷終了、および、ジョブキャンセル時にイベントを通知することになる。
【００２６】
図７は、図６のＣｒｅａｔｅＪｏｂパケットに対する応答パケットデータの一例である。
【００２７】
本データも図６と同様にＸＭＬ形式で記述され、本実施例においてはＨＴＴＰ上のＳＯＡＰを用いて送受信される。ＣｒｅａｔｅＪｏｂ応答パケットには、ＣｒｅａｔｅＪｏｂコマンド対する結果コード（＜ｒｅｓｕｌｔ−ｃｏｄｅ＞タグ）や生成されたジョブの識別子（＜ｊｏｂ−ｉｄ＞タグ）、印刷用ポートのＵＲＩ（＜ｄａｔａ−ｓｉｎｋ−ｕｒｉ＞タグ）等の情報が含まれている。図７の７０１で示した部分が印刷用ポートのＵＲＩを示す部分であり、図７の例では「ｈｔｔｐ：／／１９２．１６８．１．４／ｊｏｂ００１」というＵＲＩが示されている。
【００２８】
図８は、スキャンデバイス１０１からプリントデバイス１０３にデータ転送を行う場合における本実施例の印刷装置の動作を示すフローチャートである。
【００２９】
以下、図８を用いて、本実施例のプリントデバイス１０３の動作を説明する。
【００３０】
スキャナデバイス１０１から図６に示したようなＣｒｅａｔｅＪｏｂパケットが印刷装置に送信されると、印刷装置はＳ８０１において、ＣｒｅａｔｅＪｏｂに記述されたＸＭＬデータを解析し、Ｓ８０２に進み解析結果にエラーがないか判定する。エラーがなければ、Ｓ８０３において印刷データ受信用の印刷ポートを生成する。Ｓ８０３の処理が終わるとＳ８０４へ進み、ＣｒｅａｔｅＪｏｂパケットに対するレスポンスのＸＭＬデータの生成を行なう。このときに印刷データ受信用に生成したポートのＵＲＩを＜ｄａｔａ−ｓｉｎｋ−ｕｒｉ＞タグの値として設定する。７０１のようなＵＲＩがＸＭＬデータに埋め込まれる。ＣｒｅａｔｅＪｏｂレスポンスデータの生成が終了するとＳ８０６へ進み、そのデータをＳＯＡＰを用いてスキャナデバイス１０１に送信する。スキャナデバイス１０１は、その後、＜ｄａｔａ−ｓｉｎｋ−ｕｒｉ＞タグで指定されたＵＲＩに対してＨＴＴＰのＰＯＳＴメソッドを用いて印刷データを送信する。図９はＨＴＴＰ  ＰＯＳＴメソッドによる印刷データ転送パケットの一例である。印刷装置はＳ８０７において印刷ポートに到着したデータを受信し、適切な処理をしながらプリンタに印刷する。Ｓ８０７において、印刷データの受信が正常に終了すると印刷装置はＳ８０８において図１０に示した例のようなＨＴＴＰレスポンスパケットをスキャナデバイス１０１に送信し、印刷用ポートを削除（クローズ）して印刷動作を終了する。一方、Ｓ８０２においてＣｒｅａｔｅＪｏｂに記述されたＸＭＬデータにエラーがあると判定された場合はＳ８０４へ進み、エラーレスポンスデータを生成する。図１１はエラーレスポンスの例である。次にＳ８０６においてエラーレスポンスをスキャナデバイス１０１に送信すると、スキャナデバイス１０１は印刷データを送信することはせず、処理を終了する。
【００３１】
図１２は図８で示した、ＰＯＳＴ処理の詳細である。
【００３２】
通常、図８で示したようにデータはＨＴＴＰのＰＯＳＴ処理１回で他方に相手に転送され、印刷装置側はそれを受信して応答を返す。
【００３３】
本発明においては、図１２のようにこのＨＴＴＰのＰＯＳＴ処理を複数回行うことによる。そのため、９０１に示したようにＨＴＴＰのヘッダ部分にｘ−Ｓｅｑｕｅｎｃｅ−Ｎｕｍｂｅｒとしてシーケンス番号を登録し、複数回のＨＴＴＰのＰＯＳＴ処理を行うようにする。ＰＯＳＴ処理の一番最後にはｘ−Ｓｅｑｕｅｎｃｅ−Ｎｕｍｂｅｒ：ｌａｓｔとして、そのＰＯＳＴ処理が最後のＰＯＳＴ処理であることを示す。
【００３４】
図１３はデバイス１０１のローカルインターフェース上に表示されるＨＴＴＰの最大転送サイズの画面である。
【００３５】
ユーザは転送最大サイズをテンキー３０２を用いて入力することが可能である。
【００３６】
この最大転送サイズはＨＴＴＰクライアントモジュール４０４によって参照され、そのサイズに収まるようにＨＴＴＰのＰＯＳＴ処理を分割することになる。
【００３７】
図１４は、スキャナデバイス１０１がプロキシ１０２にアクセスするときにプロキシ１０２からプロキシ情報を取得するシーケンスの一例である。
【００３８】
スキャナデバイスは接続先のＩＰアドレスによって、そのＩＰへの接続がプロキシを介して接続する必要があるか、直接接続するかを判断する。プロキシを介して、接続する場合に、まず、プロキシから最大転送サイズ情報を取得する。プロキシが応答した最大転送サイズをＨＴＴＰクライアントモジュール４０４は参照し、そのサイズ内に収まるようにＨＴＴＰのＰＯＳＴ処理を分割することになる。
【００３９】
図１５は、プロキシ接続時にプロキシサーバから転送サイズ情報を取得する処理の流れを示すフローチャートである。
【００４０】
図１６は、ＨＴＴＰクライアントモジュールのデータ送信時の処理の流れを示すフローチャートである。
【００４１】
図１７は、ＨＴＴＰサーバモジュールのデータ受信時の処理の流れを示すフローチャートである。
【００４２】
以下、図を用いて、本発明の処理の流れについて説明する。
【００４３】
デバイス１０１のＨＴＴＰクライアントモジュール４０４の処理の流れについて説明する。
【００４４】
デバイス１０１のスキャンサービスモジュール４０６はユーザから、スキャンして、別プリンタへデータを送信の指示があると、スキャナ制御２０１を介してスキャナエンジン２１３からユーザのセットした画像を読み取る。読み取った画像はＨＴＴＰクライアントモジュール４０４に転送される。スキャナサービス４０６はユーザから指定された宛先を指定して、ＨＴＴＰクライアントモジュール４０４にデータの転送を指示する。ＨＴＴＰクライアントモジュール４０４はＳＯＡＰ／ＸＭＬを使った制御方式で、プリントデバイス１０３に転送することになる。
【００４５】
ＨＴＴＰクライアントモジュール４０４はスキャナサービスモジュールから転送先の指示を受けると、その転送先がプロキシ１０２経由で転送するか、直接デバイスに接続できるかを判断する（不図示）。プロキシ１０２経由でデータを転送する場合の処理から、図１５を用いて説明する。
【００４６】
プロキシ１０２経由でデバイス１０３に接続する場合、まず、ＨＴＴＰクライアントモジュール４０４はプロキシ１０２から最大転送サイズを取得する（Ｓ１５０１）。このときのデバイス１０１とプロキシ１０２のパケットの授受は図１４に図示したようなシーケンスになる。図１４では、プロキシサーバ１０２にＨＴＴＰ  ＧＥＴでｘ−ＰＲＯＸＹ−ＭＡＸ−ＴｒａｎｓｆｅｒＳｉｚｅを取得要求し、プロキシサーバ１０２はＨＴＴＰ  ＯＫとしてｘ−ＰＲＯＸＹ−ＭＡＸ−ＴＲａｎｓｆｅｒＳｉｚｅ：４０Ｍｂｙｔｅｓを返している。この例では、このプロキシサーバ１０２の一回のＰＯＳＴ処理の最大サイズは４０Ｍｂｙｔｅであることがわかる。Ｓ１５０２でプロキシサーバ１０２から１回のＰＯＳＴ処理の最大サイズが取得できた場合にはその最大サイズをＲＡＭ２０４にＭＡＸ−ＴＲＡＮＳＦＥＲ−ＳＩＺＥとして、保持しておく（Ｓ１５０４）。Ｓ１５０２でプロキシサーバ１０２が応答を返さなかった場合には、Ｓ１５０３でパネルから取得する（Ｓ１５０３）。そして、この値をＳ１５０４でＲＡＭ２０４上に保持する。パネルからの入力は、あらかじめユーザが図１３に示した画面から入力しておくことになる。図１３では４０Ｍｂｙｔｅが入力されている。
【００４７】
本実施例では、１回のＰＯＳＴ処理の最大転送サイズは４０Ｍｂｙｔｅとして動作する。
【００４８】
次に実際の転送処理の処理の流れについて図１６を用いて説明する。
【００４９】
スキャナサービス４０６はデータのスキャンが終了するとＨＴＴＰクライアントモジュール４０４にデータを転送し、ＨＴＴＰクライアントモジュール４０４はＨＴＴＰおよび、ＳＯＡＰ／ＸＭＬを用いてデバイス１０３にデータを転送する。
【００５０】
データを転送のシーケンスは図８に図示したようなシーケンスになる。本実施例で、スキャンしたデータが４０Ｍｂｙｔｅ内に収まれば、図８に図示したように、ＨＴＴＰのＰＯＳＴは１回のみ行われることになる。４０ＭＢｙｔｅ以上の場合には、１回のＰＯＳＴの転送サイズを最大４０Ｍｂｙｔｅとして、図１２に図示したように複数回行われることになる。
【００５１】
では、その複数回の転送処理の流れを図１６を用いて説明する。ＨＴＴＰクライアントモジュール４０４はＣｒｅａｔｅＪｏｂのレスポンス受信後、指定されたＵＲＬに対して、ＨＴＴＰでスキャナサービス４０６のデータを転送することになる。まず、ｘ−Ｓｅｑｕｅｎｃｅ−Ｎｕｍｂｅｒ＝１として（Ｓ１６０１）、次に、スキャンサービスから指定されたＴｏｔａｌ転送サイズが先にＲＡＭ２０４上に保持しておいたＭＡＸ−ＴＲＡＮＳＦＥＲ−ＳＩＺＥ（本実施例では４０Ｍｂｙｔｅ）より大きいかどうかを判断する（Ｓ１６０３）。Ｓ１６０３で大きいと判断した場合には、１回のＰＯＳＴの転送サイズ（Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ）をＭＡＸ−ＴＲＡＮＳＦＥＲ−ＳＩＺＥ（４０Ｍｂｙｔｅ）に設定する（Ｓ１６０３）。続いて、そのサイズ分のＰＯＳＴ処理を実行する（Ｓ１６０４）。ＨＴＴＰクライアントモジュール４０４はデバイス１０３からのＨＴＴＰのレスポンスを待つ（Ｓ１６０５）。レスポンス受信後、Ｔｏｔａｌ転送サイズから、実際に転送した転送サイズを減算する（Ｓ１６０６）。減算後、Ｔｏｔａｌ転送サイズが０かどうかを判断する（Ｓ１６０７）。０でない場合には、まだ転送すべきデータあることから、ｘ−Ｓｅｑｕｅｎｃｅ−Ｎｕｍｂｅｒに１を加えて（Ｓ１６０８）、再び、Ｓ１６０２へ戻る。
【００５２】
Ｓ１６０２でＭＡＸ−ＴＲＡＮＳＦＥＲ−ＳＩＺＥよりＴｏｔａｌ転送サイズが小さい場合には、それを送れば、ＰＯＳＴ処理は終了することから、ＰＯＳＴの転送サイズ（Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ）をＴｏｔａｌ転送サイズとして、ｘ−Ｓｅｑｕｅｎｃｅ−ＮｕｍｂｅｒをＬａｓｔとする（Ｓ１６０９）。そして、Ｓ１６０４でＰＯＳＴ処理を実行する。
【００５３】
こうして、Ｓ１６０７でＴｏｔａｌ転送サイズが０になるまで繰り返して、データの転送が終了する。このときのネットワーク上のシーケンスは図１２に図示したようになる。
【００５４】
続いて、プリンタデバイス側１０３の処理の流れについて説明する。プリンタデバイス１０３のＨＴＴＰサーバモジュール５０４の処理の流れについて説明する。図８に図示したようにＤａｔａ−Ｓｉｎｋ−ＵＲＩを返した後、デバイス１０１はＨＴＴＰのＰＯＳＴ処理を用いて、スキャンデータを転送してくる。ＨＴＴＰサーバモジュール５０４はＳ１７０１にてデータの受信待ちになっている。デバイス１０１からデータを受信すると、ＨＴＴＰヘッダからｘ−Ｓｅｑｕｎｃｅ−Ｎｕｍｂｅｒを取得する（Ｓ１７０２）。続いて、ＨＴＴＰのＢｏｄｙ部（実際のデータ）をプリント処理に転送し、プリント処理を行う（Ｓ１７０３）。ＨＴＴＰのＣｏｎｔｅｎｔ−ｌｅｎｇｔｈ分データを受信したかをＳ１７０４で判断する。まだ受信していない場合には、引き続きＳ１７０７でデータを待ち、受信したデータをプリントモジュールに転送する（Ｓ１７０８）。Ｓ１７０４でＣｏｎｔｅｎｔ−ｌｅｎｇｔｈ分データを受信した場合にはＳ１７０５にてＨＴＴＰのレスポンス２００ＯＫをデバイス１０１に返送する。返送後、Ｓ１７０２で取得したｘ−Ｓｅｑｕｅｎｃｅ−ＮｕｍｂｅｒがＬａｓｔかどうかを判断する（Ｓ１７０６）。Ｌａｓｔでない場合には、引き続きデータがあることから、Ｓ１７０１にてデータの受信待ちになる。Ｌａｓｔであった場合には、これで全てのデータを受信したことになるので、処理を終了する。
【００５５】
本実施例では、ＨＴＴＰのＰＯＳＴの転送サイズがＣｏｎｔｅｎｔ−ｌｅｎｇｔｈとして与えることが可能となっているが、ＨＴＴＰのチャンク処理を用いても同様に実現できる。
【００５６】
また、プロキシがないような環境において、ルータで最大転送サイズを制限しているような環境下でも、同様に実現することができる。
【図面の簡単な説明】
【００５７】
【図１】本実施例のネットワークデバイス装置として、ネットワーク接続機能を持つマルチファンクションデバイスがＬＡＮに接続している概略図。
【図２】本実施例におけるマルチファンクションデバイスの概略を表すブロック図。
【図３】本デバイスが所有するユーザインターフェース部分。
【図４】本実施例におけるデバイス１０１のモジュール構成のブロック図。
【図５】本実施例におけるデバイス１０３のモジュール構成のブロック図。
【図６】本実施例におけるＨＴＴＰ上のＳＯＡＰプリントサービスのプロトコルで、クライアントから印刷装置に送信されるＣｒｅａｔｅＪｏｂと称されるパケットデータの一例。
【図７】図５のＣｒｅａｔｅＪｏｂパケットに対する応答パケットデータの一例。
【図８】クライアントが印刷を行う場合における本実施例の印刷装置の動作を示すフローチャート。
【図９】ＨＴＴＰ  ＰＯＳＴメソッドによる印刷データ転送パケットの一例。
【図１０】ＨＴＴＰレスポンスパケットの一例。
【図１１】エラーレスポンスの例。
【図１２】ＨＴＴＰ  ＰＯＳＴメソッドが分割して送られるシーケンスの例
【図１３】最大転送サイズの入力を行うパネルの例
【図１４】プロキシサーバから最大転送サイズを獲得するシーケンスの例
【図１５】プロキシサーバから最大転送サイズを取得するときのフローチャート
【図１６】ＨＴＴＰクライアントモジュールの処理を流れを示すフローチャート
【図１７】ＨＴＴＰサーバモジュールの処理の流れを示すフローチャート
【図１】
2006019802.tif 000003
【図２】
2006019802.tif 000004
【図３】
2006019802.tif 000005
【図４】
2006019802.tif 000006
【図５】
2006019802.tif 000007
【図６】
2006019802.tif 000008
【図７】
2006019802.tif 000009
【図８】
2006019802.tif 000010
【図９】
2006019802.tif 000011
【図１０】
2006019802.tif 000012
【図１１】
2006019802.tif 000013
【図１２】
2006019802.tif 000014
【図１３】
2006019802.tif 000015
【図１４】
2006019802.tif 000016
【図１５】
2006019802.tif 000017
【図１６】
2006019802.tif 000018
【図１７】
2006019802.tif 000019