JP2007172196A - ネットワーク装置におけるデータの管理 - Google Patents

Abstract

【課題】ネットワーク装置におけるサーバ装置とサービス装置との間の通信の混雑を緩和することのできる技術を提供することを目的とする。
【解決手段】ネットワーク装置は、対象データを提供するサービス装置と、ネットワークとサービス装置とに接続されるとともに、クライアント装置とサービス装置との間の通信を制御するサーバ装置とを備える。サーバ装置は、対象データの一部分である第１部分データの取得要求を受けたことに応じて、対象データの全体の取得要求をサービス装置に送信する。そして、サーバ装置は、受信した対象データから第１部分データを抽出して、クライアント装置に送信する。その後に対象データの残りの部分に含まれる第２部分データの取得要求を受けた場合には、サーバ装置は、取得済の対象データから第２部分データを抽出して、クライアント装置に送信する。
【選択図】図５

Description

本発明は、ネットワーク装置におけるデータの管理に関するものである。

従来より、ネットワークを介して種々のデータを提供するネットワーク装置が利用されている。また、データ通信には、しばしば、バッファメモリが利用されている。ここで、データ長検出手段の検出結果に基づいて、バッファメモリの中から最適な長さを有するデータ格納領域を選択する方法が提案されている（例えば、特許文献１参照）。

特開平７−２３１３３５号公報

ところで、ネットワーク装置の中には、データを提供するサービス装置と、ネットワークとサービス装置との間のデータ通信を中継するサーバ装置と、を有するものがある。サービス装置は、プリンタや、スキャナ、ファクシミリ、コピー機、記憶装置、カメラ、時計などの種々の装置として実現可能である。サーバ装置は、ネットワーク上のクライアント装置からのデータ取得要求をサービス装置に転送する。そして、サーバ装置は、サービス装置によって提供されたデータをクライアント装置に送信する。ここで、クライアント装置の中には、データの一部分のみを対象とする取得要求を繰り返し発行することによって、データを取得するものがある。ところが、このような要求によって、サーバ装置とサービス装置との間の通信が混雑する場合があった。

本発明は、上記の課題を解決するためになされたものであり、ネットワーク装置におけるサーバ装置とサービス装置との間の通信の混雑を緩和することのできる技術を提供することを目的とする。

上述の課題の少なくとも一部を解決するため、本発明のネットワーク装置は、ネットワーク上のクライアント装置からの要求に応じて対象データを提供するサービス装置と、前記ネットワークと前記サービス装置とに接続されるとともに、前記クライアント装置と前記サービス装置との間の通信を制御するサーバ装置と、を備え、前記サーバ装置は、バッファメモリを有し、前記サーバ装置は、前記クライアント装置から前記対象データの一部分である第１部分データの取得要求を受けたことに応じて、前記対象データの全体の取得要求を前記サービス装置に送信し、前記バッファメモリは、前記サービス装置から送られてきた前記対象データの全体を格納し、前記サーバ装置は、前記バッファメモリに格納された前記対象データから前記第１部分データを抽出し、前記第１部分データを前記クライアント装置に送信し、前記サーバ装置は、前記対象データの取得後に同じ前記クライアント装置から同じ前記対象データの残りの部分の少なくとも一部である第２部分データの取得要求を受けたことに応じて、前記対象データの取得要求を前記サービス装置に送信せずに前記バッファメモリに格納された前記対象データから前記第２部分データを抽出し、前記第２部分データを前記クライアント装置に送信する。

このネットワーク装置によれば、サーバ装置は、対象データの一部分の第１部分データを取得する要求をクライアント装置から受けた場合であっても、対象データの全体の取得要求をサービス装置に送信し、その後に対象データの残りの部分に含まれる第２部分データの取得要求を受けた場合には、取得済の対象データから第２部分データを抽出するので、クライアント装置が同じ対象データを分割して受信する場合であっても、サービス装置からサーバ装置へ転送される対象データが過剰に細かく分割されることを抑制できる。その結果、サーバ装置とサービス装置との間の通信の混雑を緩和することが可能となる。

上記ネットワーク装置において、前記サーバ装置は、前記クライアント装置と前記サービス装置との間の通信を制御するサーバモジュールと、前記サーバモジュールの下位層で、前記サービス装置とのデータ通信を行うデータ処理モジュールと、を有し、前記バッファメモリは、前記サーバモジュールの下位層に設けられるとともに、前記データ処理モジュールによって利用され、前記サーバモジュールは、前記クライアント装置から前記第１部分データの取得要求を受けたことに応じて、前記対象データの全体の取得要求を前記サービス装置に送信する送信命令を、前記データ処理モジュールに対して発行し、前記データ処理モジュールは、前記送信命令に応じて前記全体の取得要求を前記サービス装置に送信するとともに、前記サービス装置から送られてきた前記対象データの全体を、前記バッファメモリに格納し、前記サーバモジュールは、前記第１部分データのみを提供する提供命令を、前記データ処理モジュールに対して発行し、前記データ処理モジュールは、前記提供命令に応じて、前記バッファメモリに格納された前記対象データから前記第１部分データを抽出し、前記第１部分データを前記サーバモジュールに提供し、前記サーバモジュールは、提供された前記第１部分データを前記クライアント装置に送信することとしてもよい。

この構成によれば、サーバモジュールが、対象データの全体を格納するためのメモリを消費せずに済むので、サーバモジュールが対象データの全体を取得する場合と比べて、サーバ装置におけるメモリ消費量を低減することが可能となる。

なお、本発明は、種々の形態で実現することが可能であり、例えば、ネットワーク装置用のサーバ装置、サーバ装置とサービス装置とを有するネットワーク装置、それらの装置の制御方法及び制御装置、それらの方法または装置の機能を実現するためのコンピュータプログラム、そのコンピュータプログラムを記録した記録媒体、そのコンピュータプログラムを含み搬送波内に具現化されたデータ信号、等の形態で実現することができる。

次に、この発明の実施の形態を実施例に基づいて以下の順序で説明する。
Ａ．実施例：
Ｂ．変形例：

Ａ．実施例：
図１は、本発明の実施例を適用するネットワークシステムの構成を示す概略図である。このネットワークシステム１０は、携帯情報端末（ＰＤＡ）１００と、ＴＶセット１１０と、複合機２００とがＬＡＮを介して相互に接続された構成を有している。ＬＡＮは、ＩＥＥＥ８０２．３のような有線ネットワークでも、ＩＥＥＥ８０２．１１ｂ／ｇ／ａなどの無線ネットワークでもよい。ＰＤＡ１００と、ＴＶセット１１０と、複合機２００とは、ＵＰｎＰ（Universal Plug and Play。UPnPは、UPnP Implementers Corporationの商標）対応のネットワーク装置である。ＰＤＡ１００とＴＶセット１１０とは、ＵＰｎＰアーキテクチャにおけるコントロールポイント１００Ｃ，１１０Ｃを備えている。これらのコントロールポイント１００Ｃ，１１０Ｃの機能は、図示しないＣＰＵがプログラムを実行することによって実現されている。以下、このようなコントロールポイントと、複合機２００との間でデータが転送されることとして説明を行う。ただし、複合機２００の通信相手としては、ＵＰｎＰのコントロールポイントに限らず、ＬＡＮに接続された任意の装置を採用可能である。

複合機２００は、ＭＦＰサーバ３００と、ＭＦＰデバイスユニット４００と、を有している。ここで、ＭＦＰは、「Multi Function Peripheral」の略であり、複数のデバイスの機能を有する複合周辺装置を意味している。ＭＦＰデバイスユニット４００は、元画像データに従って印刷する機能と、ＰＣカード用のスロット４８２に挿入されたメモリカードＭＣに格納されたデータ（例えば、画像データやテキストデータ）をＬＡＮ上の他の装置（クライアント装置）に提供する機能と、を有している。ＭＦＰサーバ３００は、クライアント装置とＭＦＰデバイスユニット４００との間で転送されるデータ（例えば、印刷用の元画像データや、メモリカードＭＣから読み出されたデータ）を仲介する。ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間は、ＵＳＢ（Universal Serial Bus）で接続されている。但し、両者の間をＵＳＢ以外の他の物理的インタフェースで接続することも可能である。

ＭＦＰサーバ３００は、中央制御部（ＣＰＵ）３１０と、ＲＡＭ３２０と、ＲＯＭ３３０と、ネットワーク制御部３４０と、ＵＳＢホスト制御部３５０とを有している。図１の例では、ネットワーク制御部３４０は、コネクタ３４２を介して有線ネットワークに接続される。ＵＳＢホスト制御部３５０は、ルートハブ３５２を有しており、ルートハブ３５２にはＵＳＢコネクタ３５４が設けられている。ＵＳＢコネクタ３５４は、ＵＳＢケーブルを介してＭＦＰデバイスユニット４００のＵＳＢコネクタ４６２に接続されている。

ＭＦＰデバイスユニット４００は、中央制御部（ＣＰＵ）４１０と、ＲＡＭ４２０と、ＲＯＭ４３０と、印刷エンジン４４０と、ＵＳＢデバイス制御部４６０と、ＰＣカードインタフェース４８０と、ＰＣカードインタフェース４８０に接続されたＰＣカード用スロット４８２と、を有している。印刷エンジン４４０は、与えられた印刷データに応じて印刷を実行する印刷機構である。

本実施例では、ＭＦＰサーバ３００の中央制御部３１０は、ＬＡＮ上のコントロールポイント（例えば、コントロールポイント１００Ｃ、１１０Ｃ）から印刷要求（印刷用のメッセージ）を受信し、この印刷要求に含まれる印刷用元画像データを、ＭＦＰデバイスユニット４００に転送する。ＭＦＰデバイスユニット４００の中央制御部４１０は、元画像データを解析し、色変換やハーフトーン処理を実行して印刷データを作成し、この印刷データを印刷エンジン４４０に供給する。但し、中央制御部４１０の代わりに印刷エンジン４４０が色変換やハーフトーン処理の機能を有するように構成することも可能である。

印刷要求の形式としては、種々の形式を採用可能である。例えば、ＵＰｎＰのプロトコルに従った印刷用のメッセージを利用してもよい。また、ＬＰＲ（Line PRinter daemon protocol）を利用してもよい。同様に、元画像データの形式としては、種々の形式を採用可能である。例えば、ＰＤＬ（Page Description Language：ページ記述言語）で記述されたＰＤＬデータを採用してもよい。また、ＪＰＥＧデータやＴＩＦＦデータといった画像データを採用してもよい。また、ＸＨＴＭＬ（eXtensible HyperText Markup Language）で記述されたＸＨＴＭＬデータを採用してもよい。

また、本実施例では、ＭＦＰサーバ３００の中央制御部３１０は、ＬＡＮ上のコントロールポイント（例えば、コントロールポイント１００Ｃ、１１０Ｃ）からデータ取得要求（取得用のメッセージ）を受信し、この取得要求をＭＦＰデバイスユニット４００に転送する。ＭＦＰデバイスユニット４００の中央制御部４１０は、取得要求を解析し、この取得要求で特定される対象データをメモリカードＭＣから読み出し、対象データをＭＦＰサーバ３００に転送する。ＭＦＰサーバ３００の中央制御部３１０は、受信した対象データを、要求元のコントロールポイントに送信する。このようなデータ提供機能は、「コンテンツディレクトリサービス」とも呼ばれている。

本実施例では、取得要求として、ＨＴＴＰプロトコルの「ＧＥＴ要求」を利用することとしている。中央制御部３１０は、ＧＥＴ要求で指定されたＵＲＩ（Uniform Resource Identifier）をＭＦＰデバイスユニット４００に転送する。中央制御部４１０は、受信したＵＲＩで特定されるデータを、ＭＦＰサーバ３００に転送する。これらの処理の詳細については後述する。また、取得要求の形式としては、「ＧＥＴ要求」に限らず、他の種々の形式（例えば、ＵＰｎＰプロトコルに従ったデータ取得用のメッセージ）を採用可能である。

図２は、ＲＯＭ３３０、４３０とＲＡＭ３２０とを中心とした複合機２００の構成を示すブロック図である。図２では、各構成要素が、データ通信の階層と同じ順番に並んで配置されている。ＭＦＰサーバ３００のＲＯＭ３３０には、ＬＡＮ上のコントロールポイントからの印刷要求とデータ取得要求とに応じてＭＦＰデバイスユニット４００に印刷とデータ提供とをそれぞれ実行させるサーバモジュール３３４が格納されている。このサーバモジュール３３４は、ＬＡＮを介して受信した印刷要求に含まれる元画像データを、ＭＦＰデバイスユニット４００に転送する。また、ＬＡＮを介して受信したデータ取得要求に含まれるＵＲＩを、ＭＦＰデバイスユニット４００に転送する。そして、ＭＦＰデバイスユニット４００から転送された対象データ（ＵＲＩで特定されるデータ）を、ＬＡＮを介して要求元のコントロールポイントに送信する。

サーバモジュール３３４の下位には、ネットワークアーキテクチャの下位層と、ＵＳＢアーキテクチャの下位層とが存在する。ネットワークアーキテクチャの下位層としては、ネットワークモジュール３３２が設けられている。ネットワークモジュール３３２の下位には、ネットワーク制御部３４０が設けられている。ネットワークモジュール３３２は、比較的上位のプロトコル（例えば、ＴＣＰ（Transmission Control Protocol）やＩＰ（Internet Protocol））を解釈することによって、ＬＡＮを介したデータ通信を行う。ネットワーク制御部３４０は、比較的下位のプロトコル（例えば、Ｅｔｈｅｒｎｅｔ（登録商標））を解釈することによって、ＬＡＮを介したデータ通信を行う。

一方、サーバモジュール３３４のＵＳＢアーキテクチャの下位層としては、Ｄ４プロトコル処理モジュール３３６（以下、「サーバＤ４モジュール３３６」とも呼ぶ）が設けられている。このＤ４プロトコル処理モジュール３３６の下位には、ＵＳＢ制御モジュール３３８が設けられている。このＵＳＢ制御モジュール３３８の下位には、ＵＳＢホスト制御部３５０が設けられている。

Ｄ４プロトコル処理モジュール３３６は、いわゆる「Ｄ４プロトコル」に従ってデータ転送を行う。Ｄ４プロトコルとは、ＩＥＥＥ Ｐ１２８４．４で規定された通信プロトコルである。このＤ４プロトコルでは、データの転送は、パケットを用いるとともに論理的なチャンネルを介して行われる。以下、ＩＥＥＥ Ｐ１２８４．４で規定されたパケットのことを「Ｄ４パケット」とも呼ぶ。

ＵＳＢ制御モジュール３３８は、比較的上位のＵＳＢプロトコル（例えば、データ転送用のパイプ（Bulk OUT pipe）を用いた通信プロトコル）を解釈することによって、データ転送を行う。また、このＵＳＢ制御モジュール３３８は、ＵＳＢシステムソフトウェアと、ＵＳＢプリンタクラスのクライアント装置ソフトウェアと、のそれぞれの機能を有している。

一方、ＵＳＢホスト制御部３５０は、比較的下位のＵＳＢプロトコル（例えば、電気信号のプロトコル）を解釈することによって、データ転送を行う。このＵＳＢホスト制御部３５０は、ＵＳＢホストコントローラ（ホスト側バスインターフェース）として機能する。

一方、ＭＦＰデバイスユニット４００のＲＯＭ４３０には、デバイス機能モジュール４３４が格納されている。デバイス機能モジュール４３４は、印刷要求（元画像データ）に応じて印刷エンジン４４０に印刷データを供給する。また、データ取得要求に応じてメモリカードＭＣ（図１）から対象データを読み出し、対象データをＭＦＰサーバ３００に転送する。

このデバイス機能モジュール４３４の下位には、ＵＳＢアーキテクチャの下位層が存在する。ＵＳＢアーキテクチャの下位層としては、Ｄ４プロトコル処理モジュール４３６（以下「デバイスＤ４モジュール４３６」とも呼ぶ）が設けられている。このＤ４プロトコル処理モジュール４３６の下位には、ＵＳＢ制御モジュール４３８が設けられている。このＵＳＢ制御モジュール４３８の下位には、ＵＳＢデバイス制御部４６０が設けられている。

Ｄ４プロトコル処理モジュール４３６は、Ｄ４プロトコル処理モジュール３３６と同様に、Ｄ４プロトコルに従ってデータ転送を行う。

ＵＳＢ制御モジュール４３８は、ＵＳＢ制御モジュール３３８と同様に、比較的上位のＵＳＢプロトコルに従ってデータ転送を行う。また、このＵＳＢ制御モジュール４３８は、ＵＳＢプリンタクラスのＵＳＢ論理デバイスと、ＵＳＢプリンタクラスのＵＳＢファンクションと、のそれぞれの機能を有している。

ＵＳＢデバイス制御部４６０は、ＵＳＢホスト制御部３５０と同様に、比較的下位のＵＳＢプロトコルを解釈することによって、データ転送を行う。このＵＳＢデバイス制御部４６０は、ＵＳＢバスインターフェースとして機能する。

なお、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間のデータ転送は、サーバモジュール３３４とデバイス機能モジュール４３４との間のメッセージ（データ）転送によって行われる。その下位層では、Ｄ４プロトコル処理モジュール３３６とＤ４プロトコル処理モジュール４３６とが、Ｄ４プロトコルに従ってデータ転送を行う。その下位層では、ＵＳＢ制御モジュール３３８とＵＳＢ制御モジュール４３８とが、ＵＳＢプロトコルに従ってデータ転送を行う。その下位層では、ＵＳＢホスト制御部３５０とＵＳＢデバイス制御部４６０とが、ＵＳＢプロトコルに従ってデータ転送を行う。

図２には、Ｄ４プロトコルの論理チャンネルｄｃｈが示されている。元画像データやＵＲＩ、対象データの転送は、この論理チャンネルｄｃｈを介して行われる。なお、論理チャンネルとしては、これらのデータ（元画像データ、ＵＲＩ、対象データ）用の論理チャンネルｄｃｈに限らず、任意の複数の論理チャンネルが設けられ得る。例えば、印刷エンジン４４０のステータス情報を送受信するためのチャンネルを設けることができる。このようなステータス情報は、ＳＮＭＰ等のプロトコルにより、ＭＦＰサーバ３００からネットワーク上の他の装置（例えば、ＰＤＡ１００）に対して提供され得る。また、データ毎に異なる論理チャンネルを利用してもよい。

また、ＲＡＭ３２０には、管理テーブル３９０が格納され、ＲＡＭ３２０の一部の領域はバッファメモリ３９２として利用される。このバッファメモリ３９２は、サーバモジュール３３４の下位層に設けられている、すなわち、上位層のサーバモジュール３３４は、下位層のバッファメモリ３９２に直接にアクセスしない。そして、バッファメモリ３９２は、下位層のサーバＤ４モジュール３３６に利用される。これらの詳細については、後述する。

図３は、Ｄ４パケットの構成を示す概略図である。本実施例では、Ｄ４パケットは、１２バイトのパケットヘッダと、０バイト以上のデータから構成されている。パケットヘッダは、送信側論理チャンネル番号と、受信側論理チャンネル番号と、パケットサイズ(size)と、フロー制御用情報と、データ属性情報(EOM)と、データ識別子(RequestID）と、エラー情報と、を有している。送信側論理チャンネル番号と受信側論理チャンネル番号とは、論理チャンネルを識別するための番号である。本実施例では、送信側の番号と受信側の番号とが同じ値に設定される。ただし、互いに異なる値に設定されてもよい。パケットサイズは、パケットヘッダを含むパケットのサイズを示している（単位はバイト）。フロー制御用情報は、パケット転送の制御に利用される（詳細は省略）。データ属性情報（ＥＯＭ（End Of Message）)は、最後のパケットか否かを示す情報である。データを複数のパケットに分割して転送する場合には、最後のパケットのＥＯＭが「１」に設定され、他のパケットのＥＯＭが「０」に設定される。１つのパケットのみを用いてデータを転送する場合には、ＥＯＭが「１」に設定される。データ識別子（リクエストＩＤ（RequestID））は、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間のデータ転送において、同じデータを構成するパケットを識別するために使用される。また、本実施例では、同じデータ取得要求に起因して転送される複数のパケットには、共通のリクエストＩＤが割り当てられる（詳細は後述）。エラー情報は、パケット転送のエラーの有無に関する情報である（詳細は省略）。

図４は、管理テーブル３９０の構成を示す説明図である。この管理テーブル３９０は、部分的なデータ取得要求に応じた処理に利用される。この管理テーブル３９０は、ＭＦＰサーバ３００のＲＡＭ３２０（図１、図２）に格納されており、サーバモジュール３３４によって利用される。この管理テーブル３９０は、コントロールポイントのＩＰアドレスと、取得要求で指定されたＵＲＩと、リクエストＩＤ（RequestID）と、取得済のレンジ（Range）と、データサイズと、データ種類と、の対応関係を格納している。

図５〜図８は、部分的なデータ取得要求に応じた処理の一例の概要を示すシーケンス図である。ここでは、コントロールポイント１００Ｃと、ＭＦＰサーバ３００と、ＭＦＰデバイスユニット４００と、の間でデータが転送される場合を示している。

最初のステップＳ２００では、コントロールポイント１００Ｃが、ＨＴＴＰのリクエストメッセージＦ１１をサーバモジュール３３４に送信する。このリクエストメッセージＦ１１には、リクエスト命令のメソッド（この例では「ＧＥＴ」）と、ＭＦＰデバイスユニット４００内のデータの位置を示すＵＲＩ（Uniform Resource Identifier。この例では「/image1.jpg」）と、データの一部分を指定するレンジフィールド（この例では、０−４９９（単位はバイト））と、が記述されている。このリクエストは、画像データ「/image1.jpg」のうちの「０−４９９バイト」の一部分のみの取得を要求するものである。このようなデータの一部分のみの取得要求（「部分的ＧＥＴリクエスト」とも呼ばれる）は、例えば、データを受信する装置（ＰＤＡ１００やＴＶセット１１０）のメモリ量が少ない場合に利用される。ここで、データの全体を利用する場合には、レンジをシフトさせつつ複数回の「部分的ＧＥＴリクエスト」が同じデータに対して発行される。なお、本実施例では、ＵＲＩとして、メモリカードＭＣ内のデータファイル名がそのまま利用される。

なお、図中の「＜ＣＲ＞」は「Carriage Return」を示すコードを示し、「＜ＬＦ＞」は「Line Feed」を示すコードを示し、「＜ＥＳＣ＞」は「Escape」を示すコードを示している。これらは、後述する他の図においても同じである。

次のステップＳ２０４では、サーバモジュール３３４が、リクエストメッセージＦ１１を解析する。メソッドが「ＧＥＴ」であり、かつ、レンジフィールドが記述されている場合には、サーバモジュール３３４は、この要求が「部分的なデータ取得要求」であると判断する。そして、サーバモジュール３３４は、リクエストメッセージＦ１１からＵＲＩを抽出し、リクエスト元（コントロールポイント１００Ｃ）のＩＰアドレスとＵＲＩとの組み合わせを、管理テーブル３９０から検索する。この組み合わせが検索されなかった場合、すなわち、この組み合わせが新規なものである場合には、サーバモジュール３３４は、この組み合わせにリクエストＩＤを割り当てる。そして、サーバモジュール３３４は、ＩＰアドレスとＵＲＩとリクエストＩＤとの組み合わせを、管理テーブル３９０に格納する。図５の例では、ステップＳ２００の取得要求が新規なものであることとしている。従って、ＩＰアドレスとＵＲＩとの組み合わせと、新規に割り当てられたリクエストＩＤとの対応関係が、管理テーブル３９０に格納される。図５の例では、コントロールポイント１００ＣのＩＰアドレスが「１９２．１６８．０．３２」であり、リクエストＩＤが「０１００」に設定されている。また、この段階では、「取得済みＲａｎｇｅ」と「データサイズ」と「データ種類」とは未設定である。なお、コントロールポイント１００ＣのＩＰアドレスは、ネットワークモジュール３３２（図２）から取得される。

次のステップＳ２０８では、サーバモジュール３３４は、サーバＤ４モジュール３３６に対してＷＲＩＴＥコマンドを発行する。ＷＲＩＴＥコマンドは、メッセージ（データ）をＭＦＰデバイスユニット４００に送信するためのコマンドである。サーバモジュール３３４は、このＷＲＩＴＥコマンドで、ＵＲＩ（「/image1.jpg」）を含むメッセージＦ１２と、リクエストＩＤ（「０１００」）とをサーバＤ４モジュール３３６に渡す。ＵＲＩは、メッセージＦ１２の先頭部分（「メッセージヘッダ」とも呼ばれる）に、テキスト形式で記述されている。

なお、サーバモジュール３３４は、指定範囲（Ｒａｎｇｅ）をメッセージＦ１２に記述しない。これは、コントロールポイント１００ＣによるＲａｎｇｅ指定に拘わらずに、ＵＲＩで特定されるデータの全体を取得するためである。このように、本実施例では、Ｒａｎｇｅが記述されずにＵＲＩが記述されたメッセージＦ１２は、ＵＲＩで特定されるデータの全体の取得要求である。

次のステップＳ２１２では、サーバＤ４モジュール３３６は、メッセージＦ１２を、Ｄ４パケットを用いてＭＦＰデバイスユニット４００に転送する。この際、メッセージＦ１２を含むＤ４パケットのパケットヘッダＰＨ１２のリクエストＩＤ（図３）が、サーバモジュール３３４に指定されたリクエストＩＤ（「０１００」）に設定される。メッセージＦ１２は、Ｄ４パケットのデータ部分に格納される。

サーバＤ４モジュール３３６は、メッセージＦ１２を送信した後に、次のコマンドの受け入れが可能であることをサーバモジュール３３４に通知する（ステップＳ２１６）。この通知に応じて、サーバモジュール３３４は、次のステップＳ２２０で、サーバＤ４モジュール３３６に対してＲＥＡＤコマンドを発行する。ＲＥＡＤコマンドは、ＭＦＰデバイスユニット４００から受信したメッセージを取得するためのコマンドである。サーバモジュール３３４は、このＲＥＡＤコマンドで、リクエストＩＤとサイズとをサーバＤ４モジュール３３６に渡す。ここで渡されるリクエストＩＤは、ステップＳ２０４で割り当てられた「０１００」に設定される。また、サイズは、コントロールポイント１００Ｃに指定された一部分のサイズ（この例では「５００バイト」）に設定される。ただし、図５の例では、ＭＦＰデバイスユニット４００からのデータがＭＦＰサーバ３００に到着する前に、ＲＥＡＤコマンドが発行されている。従って、サーバＤ４モジュール３３６は、データの到着を待ち、到着後にデータをサーバモジュール３３４に提供する（後述）。

次のステップＳ２３０（図６）では、ＭＦＰデバイスユニット４００のデバイス機能モジュール４３４（図２）が、メッセージＦ１２を解析する。デバイス機能モジュール４３４は、メッセージＦ１２のメッセージヘッダからＵＲＩを抽出し、ＵＲＩで指定された対象データ（この例では、画像データ「/image1.jpg」）をメモリカードＭＣ（図１）から読み出す。そして、デバイス機能モジュール４３４は、この対象データの全体を含むメッセージＦ１３を作成し、作成したメッセージＦ１３をＭＦＰサーバ３００に送信する。

デバイス機能モジュール４３４（図２）は、メッセージＦ１３のメッセージヘッダに、データ取得要求の処理結果を示す情報（「ＨＲ」「ＭＴ」「ＣＬ」）をテキスト形式で記述する。そして、対象データ（/image1.jpg）の全体を、メッセージヘッダの後ろの部分（「メッセージボディ」とも呼ばれる）に格納する。図６の例では、メッセージＦ１３のメッセージヘッダに「ＨＲ：２００」と「ＭＴ：ｉｍａｇｅ／ｊｐｅｇ」と「ＣＬ：１５００」とが記述されている。なお、本実施例では、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間で転送されるメッセージにおいては、メッセージの先頭から＜ＣＲ＞＜ＬＦ＞までの部分をメッセージヘッダとして扱うこととしている。

「ＨＲ」は、処理結果のステータスを示す。例えば、処理結果がＯＫであれば「ＨＲ：２００」が記述され、処理結果がエラーであれば「ＨＲ：５００」が記述される。後述するように、この情報ＨＲは、ＨＴＴＰレスポンスのステータスコードとして利用される。次に、「ＭＴ」は「Media-Type」の略であり、メッセージボディに格納されているデータの種類を示す。例えば、ＪＰＥＧ形式の画像データに対しては「ＭＴ：ｉｍａｇｅ／ｊｐｅｇ」が記述され、単純なテキスト形式のデータに対しては「ＭＴ：ｔｅｘｔ／ｐｌａｉｎ」が記述される。デバイス機能モジュール４３４は、対象データを解析することによって、データの種類を識別可能である。また、対象データに割り当てられたＵＲＩ（例えば、ファイル名の拡張子）から、データの種類を識別してもよい。なお、後述するように、この情報ＭＴは、ＨＴＴＰレスポンスの「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ」フィールドとして利用される。次に、「ＣＬ」は「Content-Length」の略であり、メッセージボディに格納されているデータの長さを示す（メッセージヘッダを除く。単位はバイト。図６の例では、１５００バイト）。

また、デバイス機能モジュール４３４（図２）は、メッセージＦ１３を格納するパケットのパケットヘッダＰＨ１３のリクエストＩＤを、ステップＳ２１２（図５）で受信したパケットで指定されたリクエストＩＤ（「０１００」）と同じ値に設定する。デバイスＤ４モジュール４３６は、サーバＤ４モジュール３３６と同様に、デバイス機能モジュール４３４から渡されたリクエストＩＤを用いてパケットヘッダＰＨ１３のリクエストＩＤを設定する。サーバモジュール３３４とサーバＤ４モジュール３３６とは、このリクエストＩＤから、メッセージＦ１３がメッセージＦ１２（データ取得要求）に応じたメッセージであることを容易に認識することができる。

なお、図６の例では、メッセージＦ１３のメッセージヘッダのサイズが３１バイトであることとしている。従って、メッセージＦ１３全体のサイズは１５３１（１５００＋３１）バイトである。また、図６の例では、メッセージＦ１３の全体が、１つのＤ４パケットに格納されたこととしている。一方、Ｄ４パケットのパケットヘッダのサイズは１２バイトである。従って、パケットヘッダＰＨ１３では、サイズが「１５４３（１５３１＋１２）バイト」に設定されている。また、図６の例では、メッセージＦ１３の全体が１つのＤ４パケットで送信されるので、パケットヘッダＰＨ１３では、ＥＯＭが「１」に設定されている。

次のステップＳ２３４では、サーバＤ４モジュール３３６は、受信したＤ４パケット（メッセージＦ１３）をバッファメモリ３９２（図２）に格納する。このメッセージＦ１３は、対象データ（この例では画像データ「/image1.jpg」）の全体を含んでいる。すなわち、サーバＤ４モジュール３３６は、対象データの全体をバッファメモリ３９２に格納する。図９（Ａ）〜図９（Ｊ）は、バッファメモリ３９２に格納されたＤ４パケットの様子を示す説明図である。このステップＳ２３４では、図９（Ａ）に示すように、パケットヘッダＰＨ１３とメッセージＦ１３とがバッファメモリ３９２に格納される。

次のステップＳ２３８（図６）では、サーバＤ４モジュール３３６は、ＲＥＡＤコマンド（図５：Ｓ２２０）で指定されたデータを、バッファメモリ３９２から抽出する。この際、サーバＤ４モジュール３３６は、バッファメモリ３９２に格納された１以上のＤ４パケットのうちの、リクエストＩＤがＲＥＡＤコマンドで指定されたリクエストＩＤと同じであるパケットから、データを抽出する。また、サイズが指定されている場合には、サーバＤ４モジュール３３６は、パケットのデータ部分の先頭から要求されたサイズのデータを抽出する。図６の例では、ＲＥＡＤコマンド（図５：Ｓ２２０）でサイズが５００バイトに設定されているので、５００バイトのデータが抽出される。この際、図９（Ｂ）に示すように、メッセージＦ１３の先頭の５００バイトが抽出される。なお、本実施例では、サーバＤ４モジュール３３６は、メッセージヘッダとメッセージボディとを区別せずに、指定されたサイズのデータを抽出する。従って、抽出された５００バイトのデータは、図６のステップＳ２４２に示すように、３１バイトのメッセージヘッダと、４６９バイトの画像データとから構成されている。

次のステップＳ２４２では、サーバＤ４モジュール３３６は、抽出したデータをサーバモジュール３３４に提供する。また、サーバＤ４モジュール３３６は、抽出したデータに加えて、パケットヘッダＰＨ１３の情報（「サイズ」と「ＥＯＭ」と「リクエストＩＤ」）を、サーバモジュール３３４に提供する。なお、サーバＤ４モジュール３３６は、サーバモジュール３３４に提供される「サイズ」を、抽出したデータのサイズに変更する（この例では５００バイト）。また、バッファメモリ３９２にはメッセージＦ１３の残り部分が格納されている。この残りの部分は、この段階では、サーバモジュール３３４には提供されない。そこで、サーバＤ４モジュール３３６は、サーバモジュール３３４に提供される「ＥＯＭ」を「０（続き有り）」に変更する。これにより、サーバモジュール３３４は、データの残り部分がバッファメモリ３９２に格納されていることを容易に認識することができる。

次のステップＳ２４４では、サーバＤ４モジュール３３６は、バッファメモリ３９２のうちの抽出されたデータの分のメモリを解放する。図９（Ｃ）に示すように、データ抽出によって、パケットヘッダＰＨ１３と、メッセージＦ１３の残り部分との間の位置（メモリアドレス）に未使用領域が生じる。そこで、サーバＤ４モジュール３３６は、パケットヘッダＰＨ１３を、残りのメッセージＦ１３の前のアドレスにコピーする（図９（Ｄ））。これにより、パケットヘッダＰＨ１３と残りのメッセージＦ１３とが連続なメモリアドレスを占める。ここで、サーバＤ４モジュール３３６は、パケットヘッダＰＨ１３における「パケットサイズ」を、残りのメッセージＦ１３のサイズ（１０３１バイト）と、パケットヘッダＰＨ１３のサイズ（１２バイト）とを足した値（１０４３バイト）に変更する（図示省略）。これらにより、サーバＤ４モジュール３３６は、パケットヘッダＰＨ１３を、その後ろに続くデータに関する情報として利用することができる。また、サーバＤ４モジュール３３６は、Ｄ４パケットが占めていた部分のうちの、コピーされたパケットヘッダＰＨ１３と、残りのメッセージＦ１３とが占める部分を除いた部分ＲＤ（図９（Ｄ））を解放する。これにより、この部分ＲＤは空き領域となり、新たな用途に利用可能な状態となる。

一方、サーバモジュール３３４は、ステップＳ２４２（図６）で、サーバＤ４モジュール３３６から抽出データを取得する。そして次のステップＳ２４６では、サーバモジュール３３４は、管理テーブル３９０の「取得済みＲａｎｇｅ」と「データサイズ」と「データ種類」とを更新する。サーバモジュール３３４は、抽出データに含まれるメッセージヘッダを解析し、「ＣＬ」と「ＭＴ」とを抽出する。そして、サーバモジュール３３４は、「データサイズ」を、抽出された「ＣＬ」と同じに設定し、「データ種類」を、抽出された「ＭＴ」と同じに設定する。図６の例では、「データサイズ」が「１５００バイト」に設定され、「データ種類」が「ｉｍａｇｅ／ｊｐｅｇ」に設定されている。サーバモジュール３３４は、「データサイズ」と「データ種類」との設定を、サーバＤ４モジュール３３６から初めてデータを取得した時にのみ実行する。また、これらの設定は、ＩＰアドレスとＵＲＩとの組み合わせ毎に実行される。

また、「取得済みＲａｎｇｅ」の更新は、メッセージヘッダのサイズを考慮して行われる。サーバモジュール３３４は、抽出データを解析し、メッセージヘッダのサイズを取得する。そして、サーバモジュール３３４は、受信したデータのサイズ（この例では、５００バイト）から、メッセージヘッダのサイズ（この例では、３１バイト）を差し引いた値（この例では、４６９バイト）を、取得したデータの範囲の終端として利用する。ただし、本実施例では、「取得済みＲａｎｇｅ」が「０」から始まるので、「取得済みＲａｎｇｅ」の終端は「１」だけ小さい値に設定される。図６の例では、「取得済みＲａｎｇｅ」が「０〜４６８」に設定されている。

このように、サーバモジュール３３４が最初にデータを取得した時には、取得されたデータのサイズは、コントロールポイント１００Ｃによって指定されたサイズよりもメッセージヘッダのサイズだけ小さい。そこで、次のステップＳ２５６で（図７）、サーバモジュール３３４は、不足分の取得要求（ＲＥＡＤコマンド）をサーバＤ４モジュール３３６に対して発行する。この際、サイズは、不足分である３１バイトに設定される。また、リクエストＩＤは、管理テーブル３９０においてＩＰアドレスとＵＲＩとの組み合わせに関連付けられているリクエストＩＤに設定される（（図７の例では「０１００」）。

次のステップＳ２６０では、サーバＤ４モジュール３３６が、３１バイトのデータを抽出する。この際、サーバＤ４モジュール３３６は、リクエストＩＤで特定されるパケットのデータ部分の先頭から要求されたサイズ分のデータを抽出する。具体的には、図９（Ｅ）に示すように、残りのメッセージＦ１３の先頭の３１バイトのデータが抽出される。次のステップＳ２６４では、サーバＤ４モジュール３３６は、抽出したデータをサーバモジュール３３４に提供する。この際、サーバＤ４モジュール３３６は、サーバモジュール３３４に提供される「サイズ」を、抽出したデータのサイズに変更する（この例では３１バイト）。また、バッファメモリ３９２にはメッセージＦ１３の残り部分が格納されているので、サーバＤ４モジュール３３６は、サーバモジュール３３４に提供される「ＥＯＭ」を「０（続き有り）」に変更する。

次のステップＳ２６６では、サーバＤ４モジュール３３６は、バッファメモリ３９２のうちのデータ抽出によって空いた部分を解放する。この処理は、図６のステップＳ２４４と同様に行われる。その結果、バッファメモリ３９２の状態は、図９（Ｆ）の状態を経て、図９（Ｇ）の状態に変わる。

次のステップＳ２６８（図７）では、サーバモジュール３３４は、管理テーブル３９０の「取得済みＲａｎｇｅ」を更新する。この段階では、新たに３１バイトのデータが取得されたので、「取得済みＲａｎｇｅ」の終端に、３１バイトが加算される。その結果、「取得済みＲａｎｇｅ」は「０〜４９９バイト」となる。

次のステップＳ２７２では、サーバモジュール３３４が、ＨＴＴＰのレスポンスメッセージＦ１６をコントロールポイント１００Ｃに送信する。サーバモジュール３３４は、メッセージＦ１６のメッセージボディに取得したデータ（対象データの一部分：０〜４９９バイト）を格納する。また、サーバモジュール３３４は、メッセージＦ１６のメッセージヘッダに、ＨＴＴＰリクエストの処理結果を示す情報をテキスト形式で記述する。図７の例では、メッセージヘッダに、以下の４つのフィールドが記述されている。
（１）HTTP/1.1 206 Partial Content（ステータスコード）
（２）Content-Type:image/jpeg
（３）Content-Range:0-499/1500
（４）Content-Length:500

ステータスコード２０６は、部分的ＧＥＴリクエストを受け付けたことを表している。「Contnt-typeフィールド」は、データの種類を表している。このフィールド値は、管理テーブル３９０の「データ種類」と同じに設定される。「Content-Rangeフィールド」は、送信されるデータがどの部分に該当するかを表している。分子が範囲を示し、分母が全体のサイズを示している。分母は、管理テーブル３９０の「データサイズ」と同じに設定される。分子は、コントロールポイント１００ＣからのＨＴＴＰリクエスト（図５：Ｓ２００）で指定された範囲と同じに設定される。「Content-Lengthフィールド」は、送信されるデータのサイズを表している。この値は、Ｒａｎｇｅから算出される。

以上のように、コントロールポイント１００Ｃは、ステップＳ２００（図５）の部分的ＧＥＴリクエストに応じた一部分のデータを取得する。

次のステップＳ３４４（図８）では、コントロールポイント１００Ｃは、同じデータ（/image1.jpg）の続きの一部分を取得するためのＨＴＴＰのリクエストメッセージＦ１７をサーバモジュール３３４に送信する。ＵＲＩは、最初のリクエストメッセージＦ１１（図５）と同じ「/image1.jpg」に設定されている。また、レンジフィールドは、リクエストメッセージＦ１１での範囲（０〜４９９）の続きである「５００〜９９９」に設定されている。このようなリクエストは、例えば、続き部分の閲覧を希望するユーザの指示に従って発行される。

次のステップＳ３４８では、サーバモジュール３３４が、リクエストメッセージＦ１７を解析する。サーバモジュール３３４は、リクエストメッセージＦ１７からＵＲＩを抽出し、リクエスト元（コントロールポイント１００Ｃ）のＩＰアドレスとＵＲＩとの組み合わせを、管理テーブル３９０から検索する。この組み合わせが検出された場合には、さらに、サーバモジュール３３４は、指定範囲が「取得済みＲａｎｇｅ」の続きであるか否かを判定する。指定範囲が「取得済みＲａｎｇｅ」の続きでは無い場合には、サーバモジュール３３４は、受信したリクエストメッセージＦ１７を、ステップＳ２００のリクエストメッセージＦ１１と同様に、新規なものとして扱う。すなわち、このリクエストに新たなリクエストＩＤが割り当てられ、そして、ＵＲＩで特定される対象データをＭＦＰデバイスユニット４００からＭＦＰサーバ３００へ転送する処理が実行される。

一方、指定範囲が「取得済みＲａｎｇｅ」の続きである場合には、サーバモジュール３３４は、この部分的取得要求を、過去の部分的取得要求に続く継続部分的取得要求であると判断する。この場合には、サーバモジュール３３４は、ＭＦＰデバイスユニット４００にデータ転送を要求せずに、サーバＤ４モジュール３３６に対してＲＥＡＤコマンドを発行する（ステップＳ３５２）。このＲＥＡＤコマンドでは、管理テーブル３９０においてＩＰアドレスとＵＲＩとの組み合わせに関連付けられているリクエストＩＤが利用される（図８の例では「０１００」）。また、指定された範囲から算出されるサイズが利用される（図８の例では「５００バイト」）。

次のステップＳ３５６では、サーバＤ４モジュール３３６は、ＲＥＡＤコマンドで指定されたデータを、バッファメモリ３９２から抽出する。この処理は、図７のステップＳ２６０と同様に行われる。具体的には、図９（Ｈ）に示すように、残りのメッセージＦ１３の先頭の５００バイトのデータが抽出される。

次のステップＳ３６０では、サーバＤ４モジュール３３６は、図７のＳ２６４と同様に、抽出したデータをサーバモジュール３３４に提供する。そして、次のステップＳ３６２で、サーバＤ４モジュール３３６は、バッファメモリ３９２のうちのデータ抽出によって空いた部分を解放する。この処理は、図６のステップＳ２４４と同様に行われる。その結果、バッファメモリ３９２の状態は、図９（Ｉ）の状態を経て、図９（Ｊ）の状態に変わる。なお、あるＤ４パケットのデータの全てが抽出された場合には、サーバＤ４モジュール３３６は、そのパケットのパケットヘッダが占めていた部分も解放する。

一方、サーバモジュール３３４は、ステップＳ３６０（図８）で、サーバＤ４モジュール３３６から抽出データを取得する。次のステップＳ３６４では、サーバモジュール３３４は、管理テーブル３９０の「取得済みＲａｎｇｅ」を更新する。具体的には、ステップＳ３６０で取得したデータの範囲、すなわち、コントロールポイント１００Ｃに指定された範囲（５００〜９９９バイト）が、「取得済みＲａｎｇｅ」に追加される。図６の例では、「取得済みＲａｎｇｅ」が「０〜９９９バイト」に更新されている。

次のステップＳ３６８では、サーバモジュール３３４は、ＨＴＴＰのレスポンスメッセージＦ１９をコントロールポイント１００Ｃに送信する。サーバモジュール３３４は、メッセージＦ１９のメッセージボディに取得したデータ（画像データの一部分：５００〜９９９バイト）を格納する。また、サーバモジュール３３４は、メッセージＦ１９のメッセージヘッダに、最初のレスポンスメッセージＦ１６（図７）のメッセージヘッダと同様のフィールドを記述する。ただし、「Content-Rangeフィールド」の範囲は、ＨＴＴＰリクエスト（図８：Ｓ３４４）で指定された範囲と同じに設定される（図８の例では、５００−９９９バイト）。また、「Content-Lengthフィールド」の値は、Ｒａｎｇｅから算出される（図８の例では、５００バイト）。

以上のように、コントロールポイント１００Ｃは、ステップＳ３４４（図８）の部分的ＧＥＴリクエストに応じた一部分のデータを取得する。以後、コントロールポイント１００Ｃが、続きの範囲の部分的取得要求を発行する度に、図８のステップＳ３４４〜Ｓ３６８と同様の処理が実行される。そして、対象データの全てがコントロールポイント１００Ｃに転送されたら、サーバモジュール３３４は、管理テーブル３９０から、この部分的取得要求に関する情報を削除する。

なお、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間でメッセージが転送された後には、これらの装置３００、４００の間でデータ転送用クレジット提供が行われる（ステップＳ２２４、Ｓ２２６（図５）、Ｓ２５０、Ｓ２５２（図６））。サーバＤ４モジュール３３６は、メッセージＦ１２の送信によって、クレジットを消費する（図５：Ｓ２１２）。そこで、ＭＦＰデバイスユニット４００のデバイスＤ４モジュール４３６は、サーバＤ４モジュール３３６に新たなクレジットを提供する（ステップＳ２２４）。クレジット提供を受けたサーバＤ４モジュール３３６は、その応答をデバイスＤ４モジュール４３６に送信する（ステップＳ２２６）。これらの通信は、クレジット用のパケットを転送することによって用いて行われる。同様に、デバイスＤ４モジュール４３６は、メッセージＦ１３の送信によって、クレジットを消費する（図６：Ｓ２３０）。そこで、サーバＤ４モジュール３３６は、デバイスＤ４モジュール４３６に新たなクレジットを提供する（ステップＳ２５０）。クレジット提供を受けたデバイスＤ４モジュール４３６は、その応答をサーバＤ４モジュール３３６に送信する（ステップＳ２５２）。なお、このようなクレジットの提供は、任意のタイミング（例えば、受信バッファメモリの空き容量が十分に大きくなった時）に行われ得る。

以上、ＭＦＰデバイスユニット４００による処理結果がＯＫである場合（図６：ステップＳ２３０：ＨＲ２００）について説明したが、処理結果がエラーである場合には、サーバモジュール３３４は、情報ＨＲを、そのまま、ＨＴＴＰレスポンスのステータスコードとして利用する。また、エラーが生じた場合には、サーバモジュール３３４は、その取得要求に関する情報を、管理テーブル３９０から削除する。

また、コントロールポイント１００Ｃからのデータ取得要求が部分的なデータ取得要求ではない場合、すなわち、取得要求がレンジフィールドを含まない場合がある。この場合には、サーバモジュール３３４は、この取得要求に関する情報を管理テーブル３９０に格納せずに、ＭＦＰデバイスユニット４００から取得した対象データの全体をコントロールポイント１００Ｃに送信する。

以上のように、本実施例では、サーバモジュール３３４は、部分的取得要求をコントロールポイントから受信した場合であっても、対象データの全体を取得する要求をＭＦＰデバイスユニット４００に送信する。この構成により、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間の通信の混雑を緩和することができる。この理由は、以下の通りである。コントロールポイントがデータの一部分を取得した場合には、そのコントロールポイントは、しばしば、その後に同じデータの残りの部分を取得する。ここで、仮に、サーバモジュール３３４が、部分的取得要求をコントロールポイントから受信する毎に、指定部分のみの取得要求をＭＦＰデバイスユニット４００に送信するとする。すると、ＭＦＰデバイスユニット４００に存在するデータは、コントロールポイントによって指定された範囲に従って分割されて、ＭＦＰサーバ３００に転送される。すると、対象データの全体を取得する要求がＭＦＰデバイスユニット４００に対して発行された場合と比べて、より細かく対象データが分割される。その結果、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間で、より多くのパケットが転送される。ところが、本実施例では、サーバモジュール３３４は、部分的取得要求をコントロールポイントから受信した場合であっても、その対象データの全体を取得する要求をＭＦＰデバイスユニット４００に送信する。その結果、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間で転送されるパケット数が増大することを抑制し、通信の混雑を緩和することができる。また、本実施例では、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間のデータ転送のために「クレジット」が利用される。すなわち、データ用のパケットを転送するために、さらに、クレジット用のパケットが転送される。従って、データ用に転送されるパケット数の低減によって、クレジット用に転送されるパケット数も低減されるので、通信の混雑の緩和の効果が顕著である。

また、本実施例では、部分的取得要求が発行された場合には、サーバモジュール３３４は対象データの全てを取得せずに、その下位層で動作しているサーバＤ４モジュール３３６（バッファメモリ３９２）が対象データの全てを保持している。従って、サーバモジュール３３４によって利用されるメモリ量を低減することができる。

また、本実施例では、サーバＤ４モジュール３３６は、バッファメモリ３９２のうちの、抽出されたデータの分のメモリを解放するので、バッファメモリ３９２の利用効率を上げることも可能となる。

ところで、本実施例では、印刷要求についても、データ取得要求のメッセージ（図５：メッセージＦ１１、Ｆ１２）と同様のメッセージが利用される。ただし、ＵＲＩは、印刷用の所定のＵＲＩに設定される。また、印刷用元画像データは、メッセージボディに格納される。このような印刷用のメッセージは、コントロールポイント（例えば、コントロールポイント１００Ｃ）によって発行される。コントロールポイントは、ＨＴＴＰプロトコルの「ＰＯＳＴ要求」を用いて、印刷用元画像データをＭＦＰサーバ３００に送信する。ここで、コントロールポイントは、ＰＯＳＴ要求の宛先を印刷用ＵＲＩに設定し、印刷用元画像データをＨＴＴＰリクエストのボディに格納する。サーバモジュール３３４は、受信したリクエストメッセージを解析し、メソッドが「ＰＯＳＴ」であり、かつ、ＵＲＩが印刷用ＵＲＩに設定されている場合には、受信した印刷用メッセージをＭＦＰデバイスユニット４００に転送する。この際、サーバモジュール３３４は、メッセージヘッダに印刷用ＵＲＩを記述し、ＨＴＴＰリクエストのボディをそのままメッセージボディとして利用する。デバイス機能モジュール４３４は、受信したメッセージヘッダからＵＲＩを抽出する。ＵＲＩが印刷用ＵＲＩに設定されている場合には、デバイス機能モジュール４３４は、さらに、メッセージボディから印刷用元画像データを抽出する。そして、デバイス機能モジュール４３４は、この印刷用元画像データに応じて印刷エンジン４４０に印刷データを供給する。

なお、本実施例では、デバイス機能モジュール４３４は、受信したメッセージヘッダ（例えば、メッセージＦ１２（図５）のメッセージヘッダ）に記述されたＵＲＩが印刷用ＵＲＩとは異なる場合に、そのメッセージがデータ取得を要求していると判断する。ただし、この代わりに、データ取得用の所定のＵＲＩを利用してもよい。例えば、コントロールポイントは、所定のデータ取得用ＵＲＩ（例えば「/dirsrv」）の後ろに、メモリカードＭＣ内のデータファイル名（例えば「image1.jpg」）を付加したＵＲＩ（例えば、「/dirsrv/imgae1.jpg」）を、「ＧＥＴ要求」のＵＲＩとして設定する。サーバモジュール３３４は、このＵＲＩを、そのまま、ＭＦＰデバイスユニット４００に転送する。デバイス機能モジュール４３４は、ＵＲＩの先頭がデータ取得用ＵＲＩである場合に、そのメッセージがデータ取得を要求していると判断する。

Ｂ．変形例：
なお、上記各実施例における構成要素の中の、独立クレームでクレームされた要素以外の要素は、付加的な要素であり、適宜省略可能である。また、この発明は上記の実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。

変形例１：
上述の実施例において、部分的取得要求が過去の部分的取得要求に続く継続部分的取得要求であると判断するための条件としては、「部分的取得要求で指定された範囲が過去に取得済みの範囲の続きであること（図８：ステップＳ３４８）」に限らず、他の条件を採用可能である。一般には、指定範囲のデータがバッファメモリ３９２に格納されていることを示す任意の条件を採用可能である。例えば、指定範囲が「取得済みＲａｎｇｅ」よりも後ろの範囲であることを条件として採用してもよい。例えば、図８のステップＳ３４４で、指定範囲が「８００−１０９９バイト」である場合に、サーバモジュール３３４が、この取得要求が継続部分的取得要求であると判断してもよい。このように、一連の部分的取得要求によって、不連続な複数の範囲が指定された場合には、サーバモジュール３３４は、管理テーブル３９０の「取得済みＲａｎｇｅ」として、取得済みの複数の範囲を設定すればよい。また、サーバＤ４モジュール３３６は、パケットのデータ部分の途中からデータを抽出すればよい。これらは、新規な部分的取得要求で、対象データの途中の一部分が指定された場合も同様である。ただし、上述の実施例のように、管理テーブル３９０に格納すべき新規な部分的取得要求として、対象データの先頭を含む連続な範囲を指定する取得要求を採用し、さらに、継続部分的取得要求として、取得済みの範囲（すなわち、クライアント装置に送信済みの範囲）に続く連続な範囲を指定するものを採用すれば、サーバモジュール３３４とサーバＤ４モジュール３３６との処理の簡素化が可能となる。

変形例２：
上述の実施例において、サーバＤ４モジュール３３６が、あるパケットのうちの抽出データの分のメモリを、そのパケット中の全てのデータが抽出されるまで解放しないこととしてもよい。ただし、上述の実施例のようにメモリを解放すれば、バッファメモリの利用効率を向上させることが可能となる。この際、パケットヘッダを移動させずに、抽出データが占めていた部分を解放してもよい。

変形例３：
上述の実施例において、サーバＤ４モジュール３３６とデバイスＤ４モジュール４３６とが利用する通信プロトコルとしては、Ｄ４プロトコルに限らず、パケット転送用のクレジットを用いる任意の通信プロトコルを採用可能である。また、クレジットを用いる通信プロトコルに限らず、クレジットを用いずにデータ通信を行うプロトコルを採用してもよい。ただし、クレジットを用いる通信プロトコルを用いれば、ＭＦＰサーバ３００とＭＦＰデバイスユニット４００との間の通信の制御を容易に行うことが可能となる。また、このようなクレジットを用いる通信プロトコルを用いる場合には、データ転送用のパケット数の低減によって、クレジット転送用のパケット数も低減されるので、通信の混雑の緩和の効果が顕著である。

変形例４：
上述の実施例において、部分的取得要求が発行された場合であっても、サーバモジュール３３４がサーバＤ４モジュール３３６から対象データの全てを取得することとしてもよい。この場合には、サーバモジュール３３４が、指定範囲のデータの抽出と、残りのデータの管理とを、実行する。ただし、この場合には、サーバＤ４モジュール３３６に加えて、サーバモジュール３３４も、対象データの全体を格納するためのメモリを消費することになる。従って、上述の実施例のように、サーバモジュール３３４が指定された一部分のみを取得すれば、メモリ消費量の低減が可能となる。

変形例５：
上述の実施例では、クライアント装置（ＰＤＡ１００とＴＶセット１１０）と複合機２００とのそれぞれがＵＰｎＰ（商標）対応のネットワーク装置であったが、これらの装置１００、１１０、２００が、ＵＰｎＰ（商標）に対応していないネットワーク装置であってもよい。また、ネットワークとしては、インターネットプロトコルを利用したネットワークに限らず、任意のネットワークを採用可能である。

変形例６：
上述の実施例では、サーバモジュール３３４は、データ取得要求の発行元のクライアント装置（コントロールポイント）を特定するためにＩＰアドレスを利用していたが、クライアント装置を特定する情報としては、ＩＰアドレスに限らず任意の情報を採用可能である。例えば、イーサネット（登録商標）のＭＡＣアドレスを採用してもよい。

また、同じクライアント装置上で複数のアプリケーションが動作し、各アプリケーションが独立してデータ取得要求を発行する場合がある。そこで、サーバモジュール３３４が、これらのアプリケーション毎に、部分的取得要求が新規なものか否かを判断してもよい。この場合には、クライアント装置において、アプリケーション毎に異なるポート番号（インターネットプロトコルのポート番号）が割り当てられる。そこで、サーバモジュール３３４は、ＩＰアドレスとポート番号との組み合わせを用いることによって、アプリケーションを特定できる。ただし、部分的取得要求（部分的ＧＥＴリクエスト）を発行するクライアント装置では、メモリ量が乏しい場合が多いので、複数のアプリケーションが独立にデータ取得要求を発行することが少ない。また、レンジをシフトさせつつ複数回の部分的ＧＥＴリクエストが同じデータに対して発行される場合には、後のリクエスト発行時に割り当てられたポート番号が、先のリクエスト発行時に割り当てられたポート番号と異なっている場合がある。従って、上述の実施例のように、サーバモジュール３３４は、アプリケーションを特定せずに、クライアント装置と対象データ（ＵＲＩ）との組み合わせ毎に、部分的取得要求が新規なものであるか否かを判断してもよい。

変形例７：
上述の実施例において、バッファメモリ３９２に格納されたパケットの内の少なくとも一部が、そのパケットの全データがクライアント装置に送信される前であっても、所定の条件が満たされた場合に、バッファメモリ３９２から削除されることが好ましい。こうすれば、バッファメモリ３９２の容量が不足することを抑制できる。例えば、サーバモジュール３３４が、所定の削除条件を満たした部分的取得要求に応じたパケットを削除するためのコマンドを、サーバＤ４モジュール３３６に発行してもよい。この際、サーバモジュール３３４は、削除対象のリクエストＩＤをサーバＤ４モジュール３３６に渡せばよい。また、このような削除コマンドとしては、データがサーバモジュール３３４に提供されずに削除されるコマンドを採用することが好ましい。こうすれば、サーバＤ４モジュール３３６からサーバモジュール３３４に渡されるデータ量を低減できる。

なお、このような削除条件としては、任意の条件を採用可能である。例えば、管理テーブル３９０に格納されている取得要求の総数を所定の上限数（例えば、３つ）に限定してもよい。サーバモジュール３３４は、上限数の部分的取得要求が管理テーブル３９０に格納された状態で新たな部分的取得要求を管理テーブル３９０に格納する場合に、最初の部分的取得要求の受信時が最も古い部分的取得要求に関する情報を削除すればよい。具体的には、削除対象の部分的取得要求に関する情報を管理テーブル３９０から削除し、削除対象の部分的取得要求に応じたパケットの削除コマンドをサーバＤ４モジュール３３６に発行すればよい。また、サーバモジュール３３４は、同じクライアント装置からの同じデータに対する最後の部分的取得要求を受信してからの経過時間が所定時間（例えば、１時間）を越えた場合に、その部分的取得要求に関する情報を削除してもよい。

変形例８：
上述の実施例では、取得要求の対象データが１つのパケットでＭＦＰデバイスユニット４００からＭＦＰサーバ３００に転送されていたが、対象データが複数のパケットに分割して転送されてもよい。この場合には、ＭＦＰデバイスユニット４００のデバイス機能モジュール４３４（図２）は、全てのパケットのリクエストＩＤを、サーバモジュール３３４に指定されたＩＤに設定する。また、サーバＤ４モジュール３３６は、全てのパケットをバッファメモリ３９２に格納する。ここで、クライアント装置が部分的取得要求を繰り返す場合には、サーバＤ４モジュール３３６は、先のパケットから順番に要求されたサイズのデータを抽出し、抽出データをサーバモジュール３３４に渡す。

なお、ＭＦＰデバイスユニット４００からサーバＤ４モジュール３３６に転送される各パケットのパケットヘッダのＥＯＭについては、最後のパケットのＥＯＭのみが「１（最後）」に設定され、他のパケットのＥＯＭは「０（続き有り）」に設定される。また、サーバＤ４モジュール３３６からサーバモジュール３３４に渡されるＥＯＭについては、抽出元のパケットのパケットヘッダのＥＯＭに拘わらずに、対象データのうちの最後尾のデータを含む部分が渡される場合にのみＥＯＭが「１」に設定され、他の部分のデータが渡される場合にはＥＯＭは「０」に設定される。例えば、対象データが、１５００バイトパケットと１０００バイトパケットに分割して、ＭＦＰデバイスユニット４００からサーバＤ４モジュール３３６に転送されたと仮定する。この場合には、最初の１５００バイトパケットのＥＯＭが「０」に設定され、最後の１０００バイトパケットのＥＯＭが「１」に設定される。次に、クライアント装置からの部分的取得要求に応じて、サーバモジュール３３４が、５００バイトずつ対象データを転送すると仮定する。すると、サーバモジュール３３４は、５００バイトのＲＥＡＤコマンドを５回発行することとなる。ここで、最初の４回のＲＥＡＤコマンドに応じて提供されるＥＯＭは「０」に設定され、最後のＲＥＡＤコマンドに応じて提供されるＥＯＭのみが「１」に設定される。

変形例９：
上述の実施例において、サーバモジュール３３４によるＲＥＡＤコマンドの発行（図５：Ｓ２２０）のタイミングとしては、クライアント装置からのデータ取得要求の受信後の任意のタイミングを採用可能である。例えば、サーバモジュール３３４が、サーバＤ４モジュール３３６によるデータのバッファメモリ３９２への格納の完了を確認した後に、ＲＥＡＤコマンドを発行してもよい。

また、部分的取得要求に応じた処理としては、図５〜図８に示した手順に限らず、種々の手順を採用可能である。また、発行されるコマンドや転送されるメッセージとしても、図５〜図８に示したものに限らず、種々のものを採用可能である。

変形例１０：
上述の実施例において、ネットワーク装置（複合機２００）によって提供されるデータとしては、メモリカードＭＣに格納されたデータに限らず、任意のデータを採用可能である。例えば、ＭＦＰデバイスユニット４００にスキャナを設け、このスキャナによって生成された画像データを提供してもよい。また、サービス装置としては、上述の実施例のＭＦＰデバイスユニット４００のような複数のデバイスの機能を有する装置に限らず、１つのデバイスの機能のみを有する装置を採用してもよい。ただし、サービス装置（ＭＦＰサーバ３００）の機能が多いほど、サーバ装置（ＭＦＰサーバ３００）とサービス装置（ＭＦＰデバイスユニット４００）との間の通信量も増える傾向にあるので、通信の混雑の緩和の効果が顕著である。

変形例１１：
上記各実施例において、ハードウェアによって実現されていた構成の一部をソフトウェアに置き換えるようにしてもよく、逆に、ソフトウェアによって実現されていた構成の一部をハードウェアに置き換えるようにしてもよい。例えば、図２のサーバモジュール３３４の機能を、論理回路を有するハードウェア回路によって実現することとしてもよい。

なお、本発明の機能の一部または全部がソフトウェアで実現される場合には、そのソフトウェア（コンピュータプログラム）は、コンピュータ読み取り可能な記録媒体に格納された形で提供することができる。この発明において、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスクやＣＤ−ＲＯＭのような携帯型の記録媒体に限らず、各種のＲＡＭやＲＯＭ等のコンピュータ内の内部記憶装置や、ハードディスク等のコンピュータに固定されている外部記憶装置も含んでいる。

本発明の実施例を適用するネットワークシステムの構成を示す概略図。 ＲＯＭ３３０４３０とＲＡＭ３２０とを中心とした複合機２００の構成を示すブロック図。 Ｄ４パケットの構成を示す概略図。 管理テーブル３９０の構成を示す説明図。 部分的なデータ取得要求に応じた処理の一例の概要を示すシーケンス図。 部分的なデータ取得要求に応じた処理の一例の概要を示すシーケンス図。 部分的なデータ取得要求に応じた処理の一例の概要を示すシーケンス図。 部分的なデータ取得要求に応じた処理の一例の概要を示すシーケンス図。 バッファメモリ３９２に格納されたＤ４パケットの様子を示す説明図。

符号の説明

１０…ネットワークシステム
１００…ＰＤＡ
１００Ｃ…コントロールポイント
１１０…ＴＶセット
１１０Ｃ…コントロールポイント
２００…複合機
３００…ＭＦＰサーバ
３１０…中央制御部
３２０…ＲＡＭ
３３０…ＲＯＭ
３３２…ネットワークモジュール
３３４…サーバモジュール
３３６…Ｄ４プロトコル処理モジュール（サーバＤ４モジュール）
３３８…ＵＳＢ制御モジュール
３４０…ネットワーク制御部
３４２…コネクタ
３５０…ＵＳＢホスト制御部
３５２…ルートハブ
３５４…ＵＳＢコネクタ
３９０…管理テーブル
３９２…バッファメモリ
４００…ＭＦＰデバイスユニット
４１０…中央制御部
４２０…ＲＡＭ
４３０…ＲＯＭ
４３４…デバイス機能モジュール
４３６…Ｄ４プロトコル処理モジュール（デバイスＤ４モジュール）
４３８…ＵＳＢ制御モジュール
４４０…印刷エンジン
４６０…ＵＳＢデバイス制御部
４６２…ＵＳＢコネクタ
４８２…スロット
ＭＣ…メモリカード

Claims (3)

1. ネットワークに接続されるネットワーク装置であって、
   前記ネットワーク上のクライアント装置からの要求に応じて対象データを提供するサービス装置と、
   前記ネットワークと前記サービス装置とに接続されるとともに、前記クライアント装置と前記サービス装置との間の通信を制御するサーバ装置と、
   を備え、
   前記サーバ装置は、バッファメモリを有し、
   前記サーバ装置は、前記クライアント装置から前記対象データの一部分である第１部分データの取得要求を受けたことに応じて、前記対象データの全体の取得要求を前記サービス装置に送信し、
   前記バッファメモリは、前記サービス装置から送られてきた前記対象データの全体を格納し、
   前記サーバ装置は、前記バッファメモリに格納された前記対象データから前記第１部分データを抽出し、前記第１部分データを前記クライアント装置に送信し、
   前記サーバ装置は、前記対象データの取得後に同じ前記クライアント装置から同じ前記対象データの残りの部分の少なくとも一部である第２部分データの取得要求を受けたことに応じて、前記対象データの取得要求を前記サービス装置に送信せずに前記バッファメモリに格納された前記対象データから前記第２部分データを抽出し、前記第２部分データを前記クライアント装置に送信する、
   ネットワーク装置。
2. 請求項１に記載のネットワーク装置であって、
   前記サーバ装置は、
   前記クライアント装置と前記サービス装置との間の通信を制御するサーバモジュールと、
   前記サーバモジュールの下位層で、前記サービス装置とのデータ通信を行うデータ処理モジュールと、
   を有し、
   前記バッファメモリは、前記サーバモジュールの下位層に設けられるとともに、前記データ処理モジュールによって利用され、
   前記サーバモジュールは、前記クライアント装置から前記第１部分データの取得要求を受けたことに応じて、前記対象データの全体の取得要求を前記サービス装置に送信する送信命令を、前記データ処理モジュールに対して発行し、
   前記データ処理モジュールは、前記送信命令に応じて前記全体の取得要求を前記サービス装置に送信するとともに、前記サービス装置から送られてきた前記対象データの全体を、前記バッファメモリに格納し、
   前記サーバモジュールは、前記第１部分データのみを提供する提供命令を、前記データ処理モジュールに対して発行し、
   前記データ処理モジュールは、前記提供命令に応じて、前記バッファメモリに格納された前記対象データから前記第１部分データを抽出し、前記第１部分データを前記サーバモジュールに提供し、
   前記サーバモジュールは、提供された前記第１部分データを前記クライアント装置に送信する、
   ネットワーク装置。
3. ネットワークに接続されるネットワーク装置の制御方法であって、
   前記ネットワーク装置は、
   前記ネットワーク上のクライアント装置からの要求に応じて対象データを提供するサービス装置と、
   前記ネットワークと前記サービス装置とに接続されるとともに、前記クライアント装置と前記サービス装置との間の通信を制御するサーバ装置と、
   を備え、
   前記サーバ装置は、バッファメモリを有し、
   前記制御方法は、
   （Ａ）前記サーバ装置が、前記クライアント装置から前記対象データの一部分である第１部分データの取得要求を受けたことに応じて、前記対象データの全体の取得要求を前記サービス装置に送信する工程と、
   （Ｂ）前記バッファメモリが、前記サービス装置から送られてきた前記対象データの全体を格納する工程と、
   （Ｃ）前記サーバ装置が、前記バッファメモリに格納された前記対象データから前記第１部分データを抽出し、前記第１部分データを前記クライアント装置に送信する工程と、
   （Ｄ）前記サーバ装置が、前記対象データの取得後に同じ前記クライアント装置から同じ前記対象データの残りの部分の少なくとも一部である第２部分データの取得要求を受けたことに応じて、前記対象データの取得要求を前記サービス装置に送信せずに前記バッファメモリに格納された前記対象データから前記第２部分データを抽出し、前記第２部分データを前記クライアント装置に送信する工程と、
   を備える、制御方法。

Images