JP2007172196A - ネットワーク装置におけるデータの管理 - Google Patents
ネットワーク装置におけるデータの管理 Download PDFInfo
- Publication number
- JP2007172196A JP2007172196A JP2005367396A JP2005367396A JP2007172196A JP 2007172196 A JP2007172196 A JP 2007172196A JP 2005367396 A JP2005367396 A JP 2005367396A JP 2005367396 A JP2005367396 A JP 2005367396A JP 2007172196 A JP2007172196 A JP 2007172196A
- Authority
- JP
- Japan
- Prior art keywords
- data
- server
- module
- acquisition request
- target data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Computer And Data Communications (AREA)
Abstract
【課題】ネットワーク装置におけるサーバ装置とサービス装置との間の通信の混雑を緩和することのできる技術を提供することを目的とする。
【解決手段】ネットワーク装置は、対象データを提供するサービス装置と、ネットワークとサービス装置とに接続されるとともに、クライアント装置とサービス装置との間の通信を制御するサーバ装置とを備える。サーバ装置は、対象データの一部分である第1部分データの取得要求を受けたことに応じて、対象データの全体の取得要求をサービス装置に送信する。そして、サーバ装置は、受信した対象データから第1部分データを抽出して、クライアント装置に送信する。その後に対象データの残りの部分に含まれる第2部分データの取得要求を受けた場合には、サーバ装置は、取得済の対象データから第2部分データを抽出して、クライアント装置に送信する。
【選択図】図5
【解決手段】ネットワーク装置は、対象データを提供するサービス装置と、ネットワークとサービス装置とに接続されるとともに、クライアント装置とサービス装置との間の通信を制御するサーバ装置とを備える。サーバ装置は、対象データの一部分である第1部分データの取得要求を受けたことに応じて、対象データの全体の取得要求をサービス装置に送信する。そして、サーバ装置は、受信した対象データから第1部分データを抽出して、クライアント装置に送信する。その後に対象データの残りの部分に含まれる第2部分データの取得要求を受けた場合には、サーバ装置は、取得済の対象データから第2部分データを抽出して、クライアント装置に送信する。
【選択図】図5
Description
本発明は、ネットワーク装置におけるデータの管理に関するものである。
従来より、ネットワークを介して種々のデータを提供するネットワーク装置が利用されている。また、データ通信には、しばしば、バッファメモリが利用されている。ここで、データ長検出手段の検出結果に基づいて、バッファメモリの中から最適な長さを有するデータ格納領域を選択する方法が提案されている(例えば、特許文献1参照)。
ところで、ネットワーク装置の中には、データを提供するサービス装置と、ネットワークとサービス装置との間のデータ通信を中継するサーバ装置と、を有するものがある。サービス装置は、プリンタや、スキャナ、ファクシミリ、コピー機、記憶装置、カメラ、時計などの種々の装置として実現可能である。サーバ装置は、ネットワーク上のクライアント装置からのデータ取得要求をサービス装置に転送する。そして、サーバ装置は、サービス装置によって提供されたデータをクライアント装置に送信する。ここで、クライアント装置の中には、データの一部分のみを対象とする取得要求を繰り返し発行することによって、データを取得するものがある。ところが、このような要求によって、サーバ装置とサービス装置との間の通信が混雑する場合があった。
本発明は、上記の課題を解決するためになされたものであり、ネットワーク装置におけるサーバ装置とサービス装置との間の通信の混雑を緩和することのできる技術を提供することを目的とする。
上述の課題の少なくとも一部を解決するため、本発明のネットワーク装置は、ネットワーク上のクライアント装置からの要求に応じて対象データを提供するサービス装置と、前記ネットワークと前記サービス装置とに接続されるとともに、前記クライアント装置と前記サービス装置との間の通信を制御するサーバ装置と、を備え、前記サーバ装置は、バッファメモリを有し、前記サーバ装置は、前記クライアント装置から前記対象データの一部分である第1部分データの取得要求を受けたことに応じて、前記対象データの全体の取得要求を前記サービス装置に送信し、前記バッファメモリは、前記サービス装置から送られてきた前記対象データの全体を格納し、前記サーバ装置は、前記バッファメモリに格納された前記対象データから前記第1部分データを抽出し、前記第1部分データを前記クライアント装置に送信し、前記サーバ装置は、前記対象データの取得後に同じ前記クライアント装置から同じ前記対象データの残りの部分の少なくとも一部である第2部分データの取得要求を受けたことに応じて、前記対象データの取得要求を前記サービス装置に送信せずに前記バッファメモリに格納された前記対象データから前記第2部分データを抽出し、前記第2部分データを前記クライアント装置に送信する。
このネットワーク装置によれば、サーバ装置は、対象データの一部分の第1部分データを取得する要求をクライアント装置から受けた場合であっても、対象データの全体の取得要求をサービス装置に送信し、その後に対象データの残りの部分に含まれる第2部分データの取得要求を受けた場合には、取得済の対象データから第2部分データを抽出するので、クライアント装置が同じ対象データを分割して受信する場合であっても、サービス装置からサーバ装置へ転送される対象データが過剰に細かく分割されることを抑制できる。その結果、サーバ装置とサービス装置との間の通信の混雑を緩和することが可能となる。
上記ネットワーク装置において、前記サーバ装置は、前記クライアント装置と前記サービス装置との間の通信を制御するサーバモジュールと、前記サーバモジュールの下位層で、前記サービス装置とのデータ通信を行うデータ処理モジュールと、を有し、前記バッファメモリは、前記サーバモジュールの下位層に設けられるとともに、前記データ処理モジュールによって利用され、前記サーバモジュールは、前記クライアント装置から前記第1部分データの取得要求を受けたことに応じて、前記対象データの全体の取得要求を前記サービス装置に送信する送信命令を、前記データ処理モジュールに対して発行し、前記データ処理モジュールは、前記送信命令に応じて前記全体の取得要求を前記サービス装置に送信するとともに、前記サービス装置から送られてきた前記対象データの全体を、前記バッファメモリに格納し、前記サーバモジュールは、前記第1部分データのみを提供する提供命令を、前記データ処理モジュールに対して発行し、前記データ処理モジュールは、前記提供命令に応じて、前記バッファメモリに格納された前記対象データから前記第1部分データを抽出し、前記第1部分データを前記サーバモジュールに提供し、前記サーバモジュールは、提供された前記第1部分データを前記クライアント装置に送信することとしてもよい。
この構成によれば、サーバモジュールが、対象データの全体を格納するためのメモリを消費せずに済むので、サーバモジュールが対象データの全体を取得する場合と比べて、サーバ装置におけるメモリ消費量を低減することが可能となる。
なお、本発明は、種々の形態で実現することが可能であり、例えば、ネットワーク装置用のサーバ装置、サーバ装置とサービス装置とを有するネットワーク装置、それらの装置の制御方法及び制御装置、それらの方法または装置の機能を実現するためのコンピュータプログラム、そのコンピュータプログラムを記録した記録媒体、そのコンピュータプログラムを含み搬送波内に具現化されたデータ信号、等の形態で実現することができる。
次に、この発明の実施の形態を実施例に基づいて以下の順序で説明する。
A.実施例:
B.変形例:
A.実施例:
B.変形例:
A.実施例:
図1は、本発明の実施例を適用するネットワークシステムの構成を示す概略図である。このネットワークシステム10は、携帯情報端末(PDA)100と、TVセット110と、複合機200とがLANを介して相互に接続された構成を有している。LANは、IEEE802.3のような有線ネットワークでも、IEEE802.11b/g/aなどの無線ネットワークでもよい。PDA100と、TVセット110と、複合機200とは、UPnP(Universal Plug and Play。UPnPは、UPnP Implementers Corporationの商標)対応のネットワーク装置である。PDA100とTVセット110とは、UPnPアーキテクチャにおけるコントロールポイント100C,110Cを備えている。これらのコントロールポイント100C,110Cの機能は、図示しないCPUがプログラムを実行することによって実現されている。以下、このようなコントロールポイントと、複合機200との間でデータが転送されることとして説明を行う。ただし、複合機200の通信相手としては、UPnPのコントロールポイントに限らず、LANに接続された任意の装置を採用可能である。
図1は、本発明の実施例を適用するネットワークシステムの構成を示す概略図である。このネットワークシステム10は、携帯情報端末(PDA)100と、TVセット110と、複合機200とがLANを介して相互に接続された構成を有している。LANは、IEEE802.3のような有線ネットワークでも、IEEE802.11b/g/aなどの無線ネットワークでもよい。PDA100と、TVセット110と、複合機200とは、UPnP(Universal Plug and Play。UPnPは、UPnP Implementers Corporationの商標)対応のネットワーク装置である。PDA100とTVセット110とは、UPnPアーキテクチャにおけるコントロールポイント100C,110Cを備えている。これらのコントロールポイント100C,110Cの機能は、図示しないCPUがプログラムを実行することによって実現されている。以下、このようなコントロールポイントと、複合機200との間でデータが転送されることとして説明を行う。ただし、複合機200の通信相手としては、UPnPのコントロールポイントに限らず、LANに接続された任意の装置を採用可能である。
複合機200は、MFPサーバ300と、MFPデバイスユニット400と、を有している。ここで、MFPは、「Multi Function Peripheral」の略であり、複数のデバイスの機能を有する複合周辺装置を意味している。MFPデバイスユニット400は、元画像データに従って印刷する機能と、PCカード用のスロット482に挿入されたメモリカードMCに格納されたデータ(例えば、画像データやテキストデータ)をLAN上の他の装置(クライアント装置)に提供する機能と、を有している。MFPサーバ300は、クライアント装置とMFPデバイスユニット400との間で転送されるデータ(例えば、印刷用の元画像データや、メモリカードMCから読み出されたデータ)を仲介する。MFPサーバ300とMFPデバイスユニット400との間は、USB(Universal Serial Bus)で接続されている。但し、両者の間をUSB以外の他の物理的インタフェースで接続することも可能である。
MFPサーバ300は、中央制御部(CPU)310と、RAM320と、ROM330と、ネットワーク制御部340と、USBホスト制御部350とを有している。図1の例では、ネットワーク制御部340は、コネクタ342を介して有線ネットワークに接続される。USBホスト制御部350は、ルートハブ352を有しており、ルートハブ352にはUSBコネクタ354が設けられている。USBコネクタ354は、USBケーブルを介してMFPデバイスユニット400のUSBコネクタ462に接続されている。
MFPデバイスユニット400は、中央制御部(CPU)410と、RAM420と、ROM430と、印刷エンジン440と、USBデバイス制御部460と、PCカードインタフェース480と、PCカードインタフェース480に接続されたPCカード用スロット482と、を有している。印刷エンジン440は、与えられた印刷データに応じて印刷を実行する印刷機構である。
本実施例では、MFPサーバ300の中央制御部310は、LAN上のコントロールポイント(例えば、コントロールポイント100C、110C)から印刷要求(印刷用のメッセージ)を受信し、この印刷要求に含まれる印刷用元画像データを、MFPデバイスユニット400に転送する。MFPデバイスユニット400の中央制御部410は、元画像データを解析し、色変換やハーフトーン処理を実行して印刷データを作成し、この印刷データを印刷エンジン440に供給する。但し、中央制御部410の代わりに印刷エンジン440が色変換やハーフトーン処理の機能を有するように構成することも可能である。
印刷要求の形式としては、種々の形式を採用可能である。例えば、UPnPのプロトコルに従った印刷用のメッセージを利用してもよい。また、LPR(Line PRinter daemon protocol)を利用してもよい。同様に、元画像データの形式としては、種々の形式を採用可能である。例えば、PDL(Page Description Language:ページ記述言語)で記述されたPDLデータを採用してもよい。また、JPEGデータやTIFFデータといった画像データを採用してもよい。また、XHTML(eXtensible HyperText Markup Language)で記述されたXHTMLデータを採用してもよい。
また、本実施例では、MFPサーバ300の中央制御部310は、LAN上のコントロールポイント(例えば、コントロールポイント100C、110C)からデータ取得要求(取得用のメッセージ)を受信し、この取得要求をMFPデバイスユニット400に転送する。MFPデバイスユニット400の中央制御部410は、取得要求を解析し、この取得要求で特定される対象データをメモリカードMCから読み出し、対象データをMFPサーバ300に転送する。MFPサーバ300の中央制御部310は、受信した対象データを、要求元のコントロールポイントに送信する。このようなデータ提供機能は、「コンテンツディレクトリサービス」とも呼ばれている。
本実施例では、取得要求として、HTTPプロトコルの「GET要求」を利用することとしている。中央制御部310は、GET要求で指定されたURI(Uniform Resource Identifier)をMFPデバイスユニット400に転送する。中央制御部410は、受信したURIで特定されるデータを、MFPサーバ300に転送する。これらの処理の詳細については後述する。また、取得要求の形式としては、「GET要求」に限らず、他の種々の形式(例えば、UPnPプロトコルに従ったデータ取得用のメッセージ)を採用可能である。
図2は、ROM330、430とRAM320とを中心とした複合機200の構成を示すブロック図である。図2では、各構成要素が、データ通信の階層と同じ順番に並んで配置されている。MFPサーバ300のROM330には、LAN上のコントロールポイントからの印刷要求とデータ取得要求とに応じてMFPデバイスユニット400に印刷とデータ提供とをそれぞれ実行させるサーバモジュール334が格納されている。このサーバモジュール334は、LANを介して受信した印刷要求に含まれる元画像データを、MFPデバイスユニット400に転送する。また、LANを介して受信したデータ取得要求に含まれるURIを、MFPデバイスユニット400に転送する。そして、MFPデバイスユニット400から転送された対象データ(URIで特定されるデータ)を、LANを介して要求元のコントロールポイントに送信する。
サーバモジュール334の下位には、ネットワークアーキテクチャの下位層と、USBアーキテクチャの下位層とが存在する。ネットワークアーキテクチャの下位層としては、ネットワークモジュール332が設けられている。ネットワークモジュール332の下位には、ネットワーク制御部340が設けられている。ネットワークモジュール332は、比較的上位のプロトコル(例えば、TCP(Transmission Control Protocol)やIP(Internet Protocol))を解釈することによって、LANを介したデータ通信を行う。ネットワーク制御部340は、比較的下位のプロトコル(例えば、Ethernet(登録商標))を解釈することによって、LANを介したデータ通信を行う。
一方、サーバモジュール334のUSBアーキテクチャの下位層としては、D4プロトコル処理モジュール336(以下、「サーバD4モジュール336」とも呼ぶ)が設けられている。このD4プロトコル処理モジュール336の下位には、USB制御モジュール338が設けられている。このUSB制御モジュール338の下位には、USBホスト制御部350が設けられている。
D4プロトコル処理モジュール336は、いわゆる「D4プロトコル」に従ってデータ転送を行う。D4プロトコルとは、IEEE P1284.4で規定された通信プロトコルである。このD4プロトコルでは、データの転送は、パケットを用いるとともに論理的なチャンネルを介して行われる。以下、IEEE P1284.4で規定されたパケットのことを「D4パケット」とも呼ぶ。
USB制御モジュール338は、比較的上位のUSBプロトコル(例えば、データ転送用のパイプ(Bulk OUT pipe)を用いた通信プロトコル)を解釈することによって、データ転送を行う。また、このUSB制御モジュール338は、USBシステムソフトウェアと、USBプリンタクラスのクライアント装置ソフトウェアと、のそれぞれの機能を有している。
一方、USBホスト制御部350は、比較的下位のUSBプロトコル(例えば、電気信号のプロトコル)を解釈することによって、データ転送を行う。このUSBホスト制御部350は、USBホストコントローラ(ホスト側バスインターフェース)として機能する。
一方、MFPデバイスユニット400のROM430には、デバイス機能モジュール434が格納されている。デバイス機能モジュール434は、印刷要求(元画像データ)に応じて印刷エンジン440に印刷データを供給する。また、データ取得要求に応じてメモリカードMC(図1)から対象データを読み出し、対象データをMFPサーバ300に転送する。
このデバイス機能モジュール434の下位には、USBアーキテクチャの下位層が存在する。USBアーキテクチャの下位層としては、D4プロトコル処理モジュール436(以下「デバイスD4モジュール436」とも呼ぶ)が設けられている。このD4プロトコル処理モジュール436の下位には、USB制御モジュール438が設けられている。このUSB制御モジュール438の下位には、USBデバイス制御部460が設けられている。
D4プロトコル処理モジュール436は、D4プロトコル処理モジュール336と同様に、D4プロトコルに従ってデータ転送を行う。
USB制御モジュール438は、USB制御モジュール338と同様に、比較的上位のUSBプロトコルに従ってデータ転送を行う。また、このUSB制御モジュール438は、USBプリンタクラスのUSB論理デバイスと、USBプリンタクラスのUSBファンクションと、のそれぞれの機能を有している。
USBデバイス制御部460は、USBホスト制御部350と同様に、比較的下位のUSBプロトコルを解釈することによって、データ転送を行う。このUSBデバイス制御部460は、USBバスインターフェースとして機能する。
なお、MFPサーバ300とMFPデバイスユニット400との間のデータ転送は、サーバモジュール334とデバイス機能モジュール434との間のメッセージ(データ)転送によって行われる。その下位層では、D4プロトコル処理モジュール336とD4プロトコル処理モジュール436とが、D4プロトコルに従ってデータ転送を行う。その下位層では、USB制御モジュール338とUSB制御モジュール438とが、USBプロトコルに従ってデータ転送を行う。その下位層では、USBホスト制御部350とUSBデバイス制御部460とが、USBプロトコルに従ってデータ転送を行う。
図2には、D4プロトコルの論理チャンネルdchが示されている。元画像データやURI、対象データの転送は、この論理チャンネルdchを介して行われる。なお、論理チャンネルとしては、これらのデータ(元画像データ、URI、対象データ)用の論理チャンネルdchに限らず、任意の複数の論理チャンネルが設けられ得る。例えば、印刷エンジン440のステータス情報を送受信するためのチャンネルを設けることができる。このようなステータス情報は、SNMP等のプロトコルにより、MFPサーバ300からネットワーク上の他の装置(例えば、PDA100)に対して提供され得る。また、データ毎に異なる論理チャンネルを利用してもよい。
また、RAM320には、管理テーブル390が格納され、RAM320の一部の領域はバッファメモリ392として利用される。このバッファメモリ392は、サーバモジュール334の下位層に設けられている、すなわち、上位層のサーバモジュール334は、下位層のバッファメモリ392に直接にアクセスしない。そして、バッファメモリ392は、下位層のサーバD4モジュール336に利用される。これらの詳細については、後述する。
図3は、D4パケットの構成を示す概略図である。本実施例では、D4パケットは、12バイトのパケットヘッダと、0バイト以上のデータから構成されている。パケットヘッダは、送信側論理チャンネル番号と、受信側論理チャンネル番号と、パケットサイズ(size)と、フロー制御用情報と、データ属性情報(EOM)と、データ識別子(RequestID)と、エラー情報と、を有している。送信側論理チャンネル番号と受信側論理チャンネル番号とは、論理チャンネルを識別するための番号である。本実施例では、送信側の番号と受信側の番号とが同じ値に設定される。ただし、互いに異なる値に設定されてもよい。パケットサイズは、パケットヘッダを含むパケットのサイズを示している(単位はバイト)。フロー制御用情報は、パケット転送の制御に利用される(詳細は省略)。データ属性情報(EOM(End Of Message))は、最後のパケットか否かを示す情報である。データを複数のパケットに分割して転送する場合には、最後のパケットのEOMが「1」に設定され、他のパケットのEOMが「0」に設定される。1つのパケットのみを用いてデータを転送する場合には、EOMが「1」に設定される。データ識別子(リクエストID(RequestID))は、MFPサーバ300とMFPデバイスユニット400との間のデータ転送において、同じデータを構成するパケットを識別するために使用される。また、本実施例では、同じデータ取得要求に起因して転送される複数のパケットには、共通のリクエストIDが割り当てられる(詳細は後述)。エラー情報は、パケット転送のエラーの有無に関する情報である(詳細は省略)。
図4は、管理テーブル390の構成を示す説明図である。この管理テーブル390は、部分的なデータ取得要求に応じた処理に利用される。この管理テーブル390は、MFPサーバ300のRAM320(図1、図2)に格納されており、サーバモジュール334によって利用される。この管理テーブル390は、コントロールポイントのIPアドレスと、取得要求で指定されたURIと、リクエストID(RequestID)と、取得済のレンジ(Range)と、データサイズと、データ種類と、の対応関係を格納している。
図5〜図8は、部分的なデータ取得要求に応じた処理の一例の概要を示すシーケンス図である。ここでは、コントロールポイント100Cと、MFPサーバ300と、MFPデバイスユニット400と、の間でデータが転送される場合を示している。
最初のステップS200では、コントロールポイント100Cが、HTTPのリクエストメッセージF11をサーバモジュール334に送信する。このリクエストメッセージF11には、リクエスト命令のメソッド(この例では「GET」)と、MFPデバイスユニット400内のデータの位置を示すURI(Uniform Resource Identifier。この例では「/image1.jpg」)と、データの一部分を指定するレンジフィールド(この例では、0−499(単位はバイト))と、が記述されている。このリクエストは、画像データ「/image1.jpg」のうちの「0−499バイト」の一部分のみの取得を要求するものである。このようなデータの一部分のみの取得要求(「部分的GETリクエスト」とも呼ばれる)は、例えば、データを受信する装置(PDA100やTVセット110)のメモリ量が少ない場合に利用される。ここで、データの全体を利用する場合には、レンジをシフトさせつつ複数回の「部分的GETリクエスト」が同じデータに対して発行される。なお、本実施例では、URIとして、メモリカードMC内のデータファイル名がそのまま利用される。
なお、図中の「<CR>」は「Carriage Return」を示すコードを示し、「<LF>」は「Line Feed」を示すコードを示し、「<ESC>」は「Escape」を示すコードを示している。これらは、後述する他の図においても同じである。
次のステップS204では、サーバモジュール334が、リクエストメッセージF11を解析する。メソッドが「GET」であり、かつ、レンジフィールドが記述されている場合には、サーバモジュール334は、この要求が「部分的なデータ取得要求」であると判断する。そして、サーバモジュール334は、リクエストメッセージF11からURIを抽出し、リクエスト元(コントロールポイント100C)のIPアドレスとURIとの組み合わせを、管理テーブル390から検索する。この組み合わせが検索されなかった場合、すなわち、この組み合わせが新規なものである場合には、サーバモジュール334は、この組み合わせにリクエストIDを割り当てる。そして、サーバモジュール334は、IPアドレスとURIとリクエストIDとの組み合わせを、管理テーブル390に格納する。図5の例では、ステップS200の取得要求が新規なものであることとしている。従って、IPアドレスとURIとの組み合わせと、新規に割り当てられたリクエストIDとの対応関係が、管理テーブル390に格納される。図5の例では、コントロールポイント100CのIPアドレスが「192.168.0.32」であり、リクエストIDが「0100」に設定されている。また、この段階では、「取得済みRange」と「データサイズ」と「データ種類」とは未設定である。なお、コントロールポイント100CのIPアドレスは、ネットワークモジュール332(図2)から取得される。
次のステップS208では、サーバモジュール334は、サーバD4モジュール336に対してWRITEコマンドを発行する。WRITEコマンドは、メッセージ(データ)をMFPデバイスユニット400に送信するためのコマンドである。サーバモジュール334は、このWRITEコマンドで、URI(「/image1.jpg」)を含むメッセージF12と、リクエストID(「0100」)とをサーバD4モジュール336に渡す。URIは、メッセージF12の先頭部分(「メッセージヘッダ」とも呼ばれる)に、テキスト形式で記述されている。
なお、サーバモジュール334は、指定範囲(Range)をメッセージF12に記述しない。これは、コントロールポイント100CによるRange指定に拘わらずに、URIで特定されるデータの全体を取得するためである。このように、本実施例では、Rangeが記述されずにURIが記述されたメッセージF12は、URIで特定されるデータの全体の取得要求である。
次のステップS212では、サーバD4モジュール336は、メッセージF12を、D4パケットを用いてMFPデバイスユニット400に転送する。この際、メッセージF12を含むD4パケットのパケットヘッダPH12のリクエストID(図3)が、サーバモジュール334に指定されたリクエストID(「0100」)に設定される。メッセージF12は、D4パケットのデータ部分に格納される。
サーバD4モジュール336は、メッセージF12を送信した後に、次のコマンドの受け入れが可能であることをサーバモジュール334に通知する(ステップS216)。この通知に応じて、サーバモジュール334は、次のステップS220で、サーバD4モジュール336に対してREADコマンドを発行する。READコマンドは、MFPデバイスユニット400から受信したメッセージを取得するためのコマンドである。サーバモジュール334は、このREADコマンドで、リクエストIDとサイズとをサーバD4モジュール336に渡す。ここで渡されるリクエストIDは、ステップS204で割り当てられた「0100」に設定される。また、サイズは、コントロールポイント100Cに指定された一部分のサイズ(この例では「500バイト」)に設定される。ただし、図5の例では、MFPデバイスユニット400からのデータがMFPサーバ300に到着する前に、READコマンドが発行されている。従って、サーバD4モジュール336は、データの到着を待ち、到着後にデータをサーバモジュール334に提供する(後述)。
次のステップS230(図6)では、MFPデバイスユニット400のデバイス機能モジュール434(図2)が、メッセージF12を解析する。デバイス機能モジュール434は、メッセージF12のメッセージヘッダからURIを抽出し、URIで指定された対象データ(この例では、画像データ「/image1.jpg」)をメモリカードMC(図1)から読み出す。そして、デバイス機能モジュール434は、この対象データの全体を含むメッセージF13を作成し、作成したメッセージF13をMFPサーバ300に送信する。
デバイス機能モジュール434(図2)は、メッセージF13のメッセージヘッダに、データ取得要求の処理結果を示す情報(「HR」「MT」「CL」)をテキスト形式で記述する。そして、対象データ(/image1.jpg)の全体を、メッセージヘッダの後ろの部分(「メッセージボディ」とも呼ばれる)に格納する。図6の例では、メッセージF13のメッセージヘッダに「HR:200」と「MT:image/jpeg」と「CL:1500」とが記述されている。なお、本実施例では、MFPサーバ300とMFPデバイスユニット400との間で転送されるメッセージにおいては、メッセージの先頭から<CR><LF>までの部分をメッセージヘッダとして扱うこととしている。
「HR」は、処理結果のステータスを示す。例えば、処理結果がOKであれば「HR:200」が記述され、処理結果がエラーであれば「HR:500」が記述される。後述するように、この情報HRは、HTTPレスポンスのステータスコードとして利用される。次に、「MT」は「Media-Type」の略であり、メッセージボディに格納されているデータの種類を示す。例えば、JPEG形式の画像データに対しては「MT:image/jpeg」が記述され、単純なテキスト形式のデータに対しては「MT:text/plain」が記述される。デバイス機能モジュール434は、対象データを解析することによって、データの種類を識別可能である。また、対象データに割り当てられたURI(例えば、ファイル名の拡張子)から、データの種類を識別してもよい。なお、後述するように、この情報MTは、HTTPレスポンスの「Content−Type」フィールドとして利用される。次に、「CL」は「Content-Length」の略であり、メッセージボディに格納されているデータの長さを示す(メッセージヘッダを除く。単位はバイト。図6の例では、1500バイト)。
また、デバイス機能モジュール434(図2)は、メッセージF13を格納するパケットのパケットヘッダPH13のリクエストIDを、ステップS212(図5)で受信したパケットで指定されたリクエストID(「0100」)と同じ値に設定する。デバイスD4モジュール436は、サーバD4モジュール336と同様に、デバイス機能モジュール434から渡されたリクエストIDを用いてパケットヘッダPH13のリクエストIDを設定する。サーバモジュール334とサーバD4モジュール336とは、このリクエストIDから、メッセージF13がメッセージF12(データ取得要求)に応じたメッセージであることを容易に認識することができる。
なお、図6の例では、メッセージF13のメッセージヘッダのサイズが31バイトであることとしている。従って、メッセージF13全体のサイズは1531(1500+31)バイトである。また、図6の例では、メッセージF13の全体が、1つのD4パケットに格納されたこととしている。一方、D4パケットのパケットヘッダのサイズは12バイトである。従って、パケットヘッダPH13では、サイズが「1543(1531+12)バイト」に設定されている。また、図6の例では、メッセージF13の全体が1つのD4パケットで送信されるので、パケットヘッダPH13では、EOMが「1」に設定されている。
次のステップS234では、サーバD4モジュール336は、受信したD4パケット(メッセージF13)をバッファメモリ392(図2)に格納する。このメッセージF13は、対象データ(この例では画像データ「/image1.jpg」)の全体を含んでいる。すなわち、サーバD4モジュール336は、対象データの全体をバッファメモリ392に格納する。図9(A)〜図9(J)は、バッファメモリ392に格納されたD4パケットの様子を示す説明図である。このステップS234では、図9(A)に示すように、パケットヘッダPH13とメッセージF13とがバッファメモリ392に格納される。
次のステップS238(図6)では、サーバD4モジュール336は、READコマンド(図5:S220)で指定されたデータを、バッファメモリ392から抽出する。この際、サーバD4モジュール336は、バッファメモリ392に格納された1以上のD4パケットのうちの、リクエストIDがREADコマンドで指定されたリクエストIDと同じであるパケットから、データを抽出する。また、サイズが指定されている場合には、サーバD4モジュール336は、パケットのデータ部分の先頭から要求されたサイズのデータを抽出する。図6の例では、READコマンド(図5:S220)でサイズが500バイトに設定されているので、500バイトのデータが抽出される。この際、図9(B)に示すように、メッセージF13の先頭の500バイトが抽出される。なお、本実施例では、サーバD4モジュール336は、メッセージヘッダとメッセージボディとを区別せずに、指定されたサイズのデータを抽出する。従って、抽出された500バイトのデータは、図6のステップS242に示すように、31バイトのメッセージヘッダと、469バイトの画像データとから構成されている。
次のステップS242では、サーバD4モジュール336は、抽出したデータをサーバモジュール334に提供する。また、サーバD4モジュール336は、抽出したデータに加えて、パケットヘッダPH13の情報(「サイズ」と「EOM」と「リクエストID」)を、サーバモジュール334に提供する。なお、サーバD4モジュール336は、サーバモジュール334に提供される「サイズ」を、抽出したデータのサイズに変更する(この例では500バイト)。また、バッファメモリ392にはメッセージF13の残り部分が格納されている。この残りの部分は、この段階では、サーバモジュール334には提供されない。そこで、サーバD4モジュール336は、サーバモジュール334に提供される「EOM」を「0(続き有り)」に変更する。これにより、サーバモジュール334は、データの残り部分がバッファメモリ392に格納されていることを容易に認識することができる。
次のステップS244では、サーバD4モジュール336は、バッファメモリ392のうちの抽出されたデータの分のメモリを解放する。図9(C)に示すように、データ抽出によって、パケットヘッダPH13と、メッセージF13の残り部分との間の位置(メモリアドレス)に未使用領域が生じる。そこで、サーバD4モジュール336は、パケットヘッダPH13を、残りのメッセージF13の前のアドレスにコピーする(図9(D))。これにより、パケットヘッダPH13と残りのメッセージF13とが連続なメモリアドレスを占める。ここで、サーバD4モジュール336は、パケットヘッダPH13における「パケットサイズ」を、残りのメッセージF13のサイズ(1031バイト)と、パケットヘッダPH13のサイズ(12バイト)とを足した値(1043バイト)に変更する(図示省略)。これらにより、サーバD4モジュール336は、パケットヘッダPH13を、その後ろに続くデータに関する情報として利用することができる。また、サーバD4モジュール336は、D4パケットが占めていた部分のうちの、コピーされたパケットヘッダPH13と、残りのメッセージF13とが占める部分を除いた部分RD(図9(D))を解放する。これにより、この部分RDは空き領域となり、新たな用途に利用可能な状態となる。
一方、サーバモジュール334は、ステップS242(図6)で、サーバD4モジュール336から抽出データを取得する。そして次のステップS246では、サーバモジュール334は、管理テーブル390の「取得済みRange」と「データサイズ」と「データ種類」とを更新する。サーバモジュール334は、抽出データに含まれるメッセージヘッダを解析し、「CL」と「MT」とを抽出する。そして、サーバモジュール334は、「データサイズ」を、抽出された「CL」と同じに設定し、「データ種類」を、抽出された「MT」と同じに設定する。図6の例では、「データサイズ」が「1500バイト」に設定され、「データ種類」が「image/jpeg」に設定されている。サーバモジュール334は、「データサイズ」と「データ種類」との設定を、サーバD4モジュール336から初めてデータを取得した時にのみ実行する。また、これらの設定は、IPアドレスとURIとの組み合わせ毎に実行される。
また、「取得済みRange」の更新は、メッセージヘッダのサイズを考慮して行われる。サーバモジュール334は、抽出データを解析し、メッセージヘッダのサイズを取得する。そして、サーバモジュール334は、受信したデータのサイズ(この例では、500バイト)から、メッセージヘッダのサイズ(この例では、31バイト)を差し引いた値(この例では、469バイト)を、取得したデータの範囲の終端として利用する。ただし、本実施例では、「取得済みRange」が「0」から始まるので、「取得済みRange」の終端は「1」だけ小さい値に設定される。図6の例では、「取得済みRange」が「0〜468」に設定されている。
このように、サーバモジュール334が最初にデータを取得した時には、取得されたデータのサイズは、コントロールポイント100Cによって指定されたサイズよりもメッセージヘッダのサイズだけ小さい。そこで、次のステップS256で(図7)、サーバモジュール334は、不足分の取得要求(READコマンド)をサーバD4モジュール336に対して発行する。この際、サイズは、不足分である31バイトに設定される。また、リクエストIDは、管理テーブル390においてIPアドレスとURIとの組み合わせに関連付けられているリクエストIDに設定される((図7の例では「0100」)。
次のステップS260では、サーバD4モジュール336が、31バイトのデータを抽出する。この際、サーバD4モジュール336は、リクエストIDで特定されるパケットのデータ部分の先頭から要求されたサイズ分のデータを抽出する。具体的には、図9(E)に示すように、残りのメッセージF13の先頭の31バイトのデータが抽出される。次のステップS264では、サーバD4モジュール336は、抽出したデータをサーバモジュール334に提供する。この際、サーバD4モジュール336は、サーバモジュール334に提供される「サイズ」を、抽出したデータのサイズに変更する(この例では31バイト)。また、バッファメモリ392にはメッセージF13の残り部分が格納されているので、サーバD4モジュール336は、サーバモジュール334に提供される「EOM」を「0(続き有り)」に変更する。
次のステップS266では、サーバD4モジュール336は、バッファメモリ392のうちのデータ抽出によって空いた部分を解放する。この処理は、図6のステップS244と同様に行われる。その結果、バッファメモリ392の状態は、図9(F)の状態を経て、図9(G)の状態に変わる。
次のステップS268(図7)では、サーバモジュール334は、管理テーブル390の「取得済みRange」を更新する。この段階では、新たに31バイトのデータが取得されたので、「取得済みRange」の終端に、31バイトが加算される。その結果、「取得済みRange」は「0〜499バイト」となる。
次のステップS272では、サーバモジュール334が、HTTPのレスポンスメッセージF16をコントロールポイント100Cに送信する。サーバモジュール334は、メッセージF16のメッセージボディに取得したデータ(対象データの一部分:0〜499バイト)を格納する。また、サーバモジュール334は、メッセージF16のメッセージヘッダに、HTTPリクエストの処理結果を示す情報をテキスト形式で記述する。図7の例では、メッセージヘッダに、以下の4つのフィールドが記述されている。
(1)HTTP/1.1 206 Partial Content(ステータスコード)
(2)Content-Type:image/jpeg
(3)Content-Range:0-499/1500
(4)Content-Length:500
(1)HTTP/1.1 206 Partial Content(ステータスコード)
(2)Content-Type:image/jpeg
(3)Content-Range:0-499/1500
(4)Content-Length:500
ステータスコード206は、部分的GETリクエストを受け付けたことを表している。「Contnt-typeフィールド」は、データの種類を表している。このフィールド値は、管理テーブル390の「データ種類」と同じに設定される。「Content-Rangeフィールド」は、送信されるデータがどの部分に該当するかを表している。分子が範囲を示し、分母が全体のサイズを示している。分母は、管理テーブル390の「データサイズ」と同じに設定される。分子は、コントロールポイント100CからのHTTPリクエスト(図5:S200)で指定された範囲と同じに設定される。「Content-Lengthフィールド」は、送信されるデータのサイズを表している。この値は、Rangeから算出される。
以上のように、コントロールポイント100Cは、ステップS200(図5)の部分的GETリクエストに応じた一部分のデータを取得する。
次のステップS344(図8)では、コントロールポイント100Cは、同じデータ(/image1.jpg)の続きの一部分を取得するためのHTTPのリクエストメッセージF17をサーバモジュール334に送信する。URIは、最初のリクエストメッセージF11(図5)と同じ「/image1.jpg」に設定されている。また、レンジフィールドは、リクエストメッセージF11での範囲(0〜499)の続きである「500〜999」に設定されている。このようなリクエストは、例えば、続き部分の閲覧を希望するユーザの指示に従って発行される。
次のステップS348では、サーバモジュール334が、リクエストメッセージF17を解析する。サーバモジュール334は、リクエストメッセージF17からURIを抽出し、リクエスト元(コントロールポイント100C)のIPアドレスとURIとの組み合わせを、管理テーブル390から検索する。この組み合わせが検出された場合には、さらに、サーバモジュール334は、指定範囲が「取得済みRange」の続きであるか否かを判定する。指定範囲が「取得済みRange」の続きでは無い場合には、サーバモジュール334は、受信したリクエストメッセージF17を、ステップS200のリクエストメッセージF11と同様に、新規なものとして扱う。すなわち、このリクエストに新たなリクエストIDが割り当てられ、そして、URIで特定される対象データをMFPデバイスユニット400からMFPサーバ300へ転送する処理が実行される。
一方、指定範囲が「取得済みRange」の続きである場合には、サーバモジュール334は、この部分的取得要求を、過去の部分的取得要求に続く継続部分的取得要求であると判断する。この場合には、サーバモジュール334は、MFPデバイスユニット400にデータ転送を要求せずに、サーバD4モジュール336に対してREADコマンドを発行する(ステップS352)。このREADコマンドでは、管理テーブル390においてIPアドレスとURIとの組み合わせに関連付けられているリクエストIDが利用される(図8の例では「0100」)。また、指定された範囲から算出されるサイズが利用される(図8の例では「500バイト」)。
次のステップS356では、サーバD4モジュール336は、READコマンドで指定されたデータを、バッファメモリ392から抽出する。この処理は、図7のステップS260と同様に行われる。具体的には、図9(H)に示すように、残りのメッセージF13の先頭の500バイトのデータが抽出される。
次のステップS360では、サーバD4モジュール336は、図7のS264と同様に、抽出したデータをサーバモジュール334に提供する。そして、次のステップS362で、サーバD4モジュール336は、バッファメモリ392のうちのデータ抽出によって空いた部分を解放する。この処理は、図6のステップS244と同様に行われる。その結果、バッファメモリ392の状態は、図9(I)の状態を経て、図9(J)の状態に変わる。なお、あるD4パケットのデータの全てが抽出された場合には、サーバD4モジュール336は、そのパケットのパケットヘッダが占めていた部分も解放する。
一方、サーバモジュール334は、ステップS360(図8)で、サーバD4モジュール336から抽出データを取得する。次のステップS364では、サーバモジュール334は、管理テーブル390の「取得済みRange」を更新する。具体的には、ステップS360で取得したデータの範囲、すなわち、コントロールポイント100Cに指定された範囲(500〜999バイト)が、「取得済みRange」に追加される。図6の例では、「取得済みRange」が「0〜999バイト」に更新されている。
次のステップS368では、サーバモジュール334は、HTTPのレスポンスメッセージF19をコントロールポイント100Cに送信する。サーバモジュール334は、メッセージF19のメッセージボディに取得したデータ(画像データの一部分:500〜999バイト)を格納する。また、サーバモジュール334は、メッセージF19のメッセージヘッダに、最初のレスポンスメッセージF16(図7)のメッセージヘッダと同様のフィールドを記述する。ただし、「Content-Rangeフィールド」の範囲は、HTTPリクエスト(図8:S344)で指定された範囲と同じに設定される(図8の例では、500−999バイト)。また、「Content-Lengthフィールド」の値は、Rangeから算出される(図8の例では、500バイト)。
以上のように、コントロールポイント100Cは、ステップS344(図8)の部分的GETリクエストに応じた一部分のデータを取得する。以後、コントロールポイント100Cが、続きの範囲の部分的取得要求を発行する度に、図8のステップS344〜S368と同様の処理が実行される。そして、対象データの全てがコントロールポイント100Cに転送されたら、サーバモジュール334は、管理テーブル390から、この部分的取得要求に関する情報を削除する。
なお、MFPサーバ300とMFPデバイスユニット400との間でメッセージが転送された後には、これらの装置300、400の間でデータ転送用クレジット提供が行われる(ステップS224、S226(図5)、S250、S252(図6))。サーバD4モジュール336は、メッセージF12の送信によって、クレジットを消費する(図5:S212)。そこで、MFPデバイスユニット400のデバイスD4モジュール436は、サーバD4モジュール336に新たなクレジットを提供する(ステップS224)。クレジット提供を受けたサーバD4モジュール336は、その応答をデバイスD4モジュール436に送信する(ステップS226)。これらの通信は、クレジット用のパケットを転送することによって用いて行われる。同様に、デバイスD4モジュール436は、メッセージF13の送信によって、クレジットを消費する(図6:S230)。そこで、サーバD4モジュール336は、デバイスD4モジュール436に新たなクレジットを提供する(ステップS250)。クレジット提供を受けたデバイスD4モジュール436は、その応答をサーバD4モジュール336に送信する(ステップS252)。なお、このようなクレジットの提供は、任意のタイミング(例えば、受信バッファメモリの空き容量が十分に大きくなった時)に行われ得る。
以上、MFPデバイスユニット400による処理結果がOKである場合(図6:ステップS230:HR200)について説明したが、処理結果がエラーである場合には、サーバモジュール334は、情報HRを、そのまま、HTTPレスポンスのステータスコードとして利用する。また、エラーが生じた場合には、サーバモジュール334は、その取得要求に関する情報を、管理テーブル390から削除する。
また、コントロールポイント100Cからのデータ取得要求が部分的なデータ取得要求ではない場合、すなわち、取得要求がレンジフィールドを含まない場合がある。この場合には、サーバモジュール334は、この取得要求に関する情報を管理テーブル390に格納せずに、MFPデバイスユニット400から取得した対象データの全体をコントロールポイント100Cに送信する。
以上のように、本実施例では、サーバモジュール334は、部分的取得要求をコントロールポイントから受信した場合であっても、対象データの全体を取得する要求をMFPデバイスユニット400に送信する。この構成により、MFPサーバ300とMFPデバイスユニット400との間の通信の混雑を緩和することができる。この理由は、以下の通りである。コントロールポイントがデータの一部分を取得した場合には、そのコントロールポイントは、しばしば、その後に同じデータの残りの部分を取得する。ここで、仮に、サーバモジュール334が、部分的取得要求をコントロールポイントから受信する毎に、指定部分のみの取得要求をMFPデバイスユニット400に送信するとする。すると、MFPデバイスユニット400に存在するデータは、コントロールポイントによって指定された範囲に従って分割されて、MFPサーバ300に転送される。すると、対象データの全体を取得する要求がMFPデバイスユニット400に対して発行された場合と比べて、より細かく対象データが分割される。その結果、MFPサーバ300とMFPデバイスユニット400との間で、より多くのパケットが転送される。ところが、本実施例では、サーバモジュール334は、部分的取得要求をコントロールポイントから受信した場合であっても、その対象データの全体を取得する要求をMFPデバイスユニット400に送信する。その結果、MFPサーバ300とMFPデバイスユニット400との間で転送されるパケット数が増大することを抑制し、通信の混雑を緩和することができる。また、本実施例では、MFPサーバ300とMFPデバイスユニット400との間のデータ転送のために「クレジット」が利用される。すなわち、データ用のパケットを転送するために、さらに、クレジット用のパケットが転送される。従って、データ用に転送されるパケット数の低減によって、クレジット用に転送されるパケット数も低減されるので、通信の混雑の緩和の効果が顕著である。
また、本実施例では、部分的取得要求が発行された場合には、サーバモジュール334は対象データの全てを取得せずに、その下位層で動作しているサーバD4モジュール336(バッファメモリ392)が対象データの全てを保持している。従って、サーバモジュール334によって利用されるメモリ量を低減することができる。
また、本実施例では、サーバD4モジュール336は、バッファメモリ392のうちの、抽出されたデータの分のメモリを解放するので、バッファメモリ392の利用効率を上げることも可能となる。
ところで、本実施例では、印刷要求についても、データ取得要求のメッセージ(図5:メッセージF11、F12)と同様のメッセージが利用される。ただし、URIは、印刷用の所定のURIに設定される。また、印刷用元画像データは、メッセージボディに格納される。このような印刷用のメッセージは、コントロールポイント(例えば、コントロールポイント100C)によって発行される。コントロールポイントは、HTTPプロトコルの「POST要求」を用いて、印刷用元画像データをMFPサーバ300に送信する。ここで、コントロールポイントは、POST要求の宛先を印刷用URIに設定し、印刷用元画像データをHTTPリクエストのボディに格納する。サーバモジュール334は、受信したリクエストメッセージを解析し、メソッドが「POST」であり、かつ、URIが印刷用URIに設定されている場合には、受信した印刷用メッセージをMFPデバイスユニット400に転送する。この際、サーバモジュール334は、メッセージヘッダに印刷用URIを記述し、HTTPリクエストのボディをそのままメッセージボディとして利用する。デバイス機能モジュール434は、受信したメッセージヘッダからURIを抽出する。URIが印刷用URIに設定されている場合には、デバイス機能モジュール434は、さらに、メッセージボディから印刷用元画像データを抽出する。そして、デバイス機能モジュール434は、この印刷用元画像データに応じて印刷エンジン440に印刷データを供給する。
なお、本実施例では、デバイス機能モジュール434は、受信したメッセージヘッダ(例えば、メッセージF12(図5)のメッセージヘッダ)に記述されたURIが印刷用URIとは異なる場合に、そのメッセージがデータ取得を要求していると判断する。ただし、この代わりに、データ取得用の所定のURIを利用してもよい。例えば、コントロールポイントは、所定のデータ取得用URI(例えば「/dirsrv」)の後ろに、メモリカードMC内のデータファイル名(例えば「image1.jpg」)を付加したURI(例えば、「/dirsrv/imgae1.jpg」)を、「GET要求」のURIとして設定する。サーバモジュール334は、このURIを、そのまま、MFPデバイスユニット400に転送する。デバイス機能モジュール434は、URIの先頭がデータ取得用URIである場合に、そのメッセージがデータ取得を要求していると判断する。
B.変形例:
なお、上記各実施例における構成要素の中の、独立クレームでクレームされた要素以外の要素は、付加的な要素であり、適宜省略可能である。また、この発明は上記の実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。
なお、上記各実施例における構成要素の中の、独立クレームでクレームされた要素以外の要素は、付加的な要素であり、適宜省略可能である。また、この発明は上記の実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。
変形例1:
上述の実施例において、部分的取得要求が過去の部分的取得要求に続く継続部分的取得要求であると判断するための条件としては、「部分的取得要求で指定された範囲が過去に取得済みの範囲の続きであること(図8:ステップS348)」に限らず、他の条件を採用可能である。一般には、指定範囲のデータがバッファメモリ392に格納されていることを示す任意の条件を採用可能である。例えば、指定範囲が「取得済みRange」よりも後ろの範囲であることを条件として採用してもよい。例えば、図8のステップS344で、指定範囲が「800−1099バイト」である場合に、サーバモジュール334が、この取得要求が継続部分的取得要求であると判断してもよい。このように、一連の部分的取得要求によって、不連続な複数の範囲が指定された場合には、サーバモジュール334は、管理テーブル390の「取得済みRange」として、取得済みの複数の範囲を設定すればよい。また、サーバD4モジュール336は、パケットのデータ部分の途中からデータを抽出すればよい。これらは、新規な部分的取得要求で、対象データの途中の一部分が指定された場合も同様である。ただし、上述の実施例のように、管理テーブル390に格納すべき新規な部分的取得要求として、対象データの先頭を含む連続な範囲を指定する取得要求を採用し、さらに、継続部分的取得要求として、取得済みの範囲(すなわち、クライアント装置に送信済みの範囲)に続く連続な範囲を指定するものを採用すれば、サーバモジュール334とサーバD4モジュール336との処理の簡素化が可能となる。
上述の実施例において、部分的取得要求が過去の部分的取得要求に続く継続部分的取得要求であると判断するための条件としては、「部分的取得要求で指定された範囲が過去に取得済みの範囲の続きであること(図8:ステップS348)」に限らず、他の条件を採用可能である。一般には、指定範囲のデータがバッファメモリ392に格納されていることを示す任意の条件を採用可能である。例えば、指定範囲が「取得済みRange」よりも後ろの範囲であることを条件として採用してもよい。例えば、図8のステップS344で、指定範囲が「800−1099バイト」である場合に、サーバモジュール334が、この取得要求が継続部分的取得要求であると判断してもよい。このように、一連の部分的取得要求によって、不連続な複数の範囲が指定された場合には、サーバモジュール334は、管理テーブル390の「取得済みRange」として、取得済みの複数の範囲を設定すればよい。また、サーバD4モジュール336は、パケットのデータ部分の途中からデータを抽出すればよい。これらは、新規な部分的取得要求で、対象データの途中の一部分が指定された場合も同様である。ただし、上述の実施例のように、管理テーブル390に格納すべき新規な部分的取得要求として、対象データの先頭を含む連続な範囲を指定する取得要求を採用し、さらに、継続部分的取得要求として、取得済みの範囲(すなわち、クライアント装置に送信済みの範囲)に続く連続な範囲を指定するものを採用すれば、サーバモジュール334とサーバD4モジュール336との処理の簡素化が可能となる。
変形例2:
上述の実施例において、サーバD4モジュール336が、あるパケットのうちの抽出データの分のメモリを、そのパケット中の全てのデータが抽出されるまで解放しないこととしてもよい。ただし、上述の実施例のようにメモリを解放すれば、バッファメモリの利用効率を向上させることが可能となる。この際、パケットヘッダを移動させずに、抽出データが占めていた部分を解放してもよい。
上述の実施例において、サーバD4モジュール336が、あるパケットのうちの抽出データの分のメモリを、そのパケット中の全てのデータが抽出されるまで解放しないこととしてもよい。ただし、上述の実施例のようにメモリを解放すれば、バッファメモリの利用効率を向上させることが可能となる。この際、パケットヘッダを移動させずに、抽出データが占めていた部分を解放してもよい。
変形例3:
上述の実施例において、サーバD4モジュール336とデバイスD4モジュール436とが利用する通信プロトコルとしては、D4プロトコルに限らず、パケット転送用のクレジットを用いる任意の通信プロトコルを採用可能である。また、クレジットを用いる通信プロトコルに限らず、クレジットを用いずにデータ通信を行うプロトコルを採用してもよい。ただし、クレジットを用いる通信プロトコルを用いれば、MFPサーバ300とMFPデバイスユニット400との間の通信の制御を容易に行うことが可能となる。また、このようなクレジットを用いる通信プロトコルを用いる場合には、データ転送用のパケット数の低減によって、クレジット転送用のパケット数も低減されるので、通信の混雑の緩和の効果が顕著である。
上述の実施例において、サーバD4モジュール336とデバイスD4モジュール436とが利用する通信プロトコルとしては、D4プロトコルに限らず、パケット転送用のクレジットを用いる任意の通信プロトコルを採用可能である。また、クレジットを用いる通信プロトコルに限らず、クレジットを用いずにデータ通信を行うプロトコルを採用してもよい。ただし、クレジットを用いる通信プロトコルを用いれば、MFPサーバ300とMFPデバイスユニット400との間の通信の制御を容易に行うことが可能となる。また、このようなクレジットを用いる通信プロトコルを用いる場合には、データ転送用のパケット数の低減によって、クレジット転送用のパケット数も低減されるので、通信の混雑の緩和の効果が顕著である。
変形例4:
上述の実施例において、部分的取得要求が発行された場合であっても、サーバモジュール334がサーバD4モジュール336から対象データの全てを取得することとしてもよい。この場合には、サーバモジュール334が、指定範囲のデータの抽出と、残りのデータの管理とを、実行する。ただし、この場合には、サーバD4モジュール336に加えて、サーバモジュール334も、対象データの全体を格納するためのメモリを消費することになる。従って、上述の実施例のように、サーバモジュール334が指定された一部分のみを取得すれば、メモリ消費量の低減が可能となる。
上述の実施例において、部分的取得要求が発行された場合であっても、サーバモジュール334がサーバD4モジュール336から対象データの全てを取得することとしてもよい。この場合には、サーバモジュール334が、指定範囲のデータの抽出と、残りのデータの管理とを、実行する。ただし、この場合には、サーバD4モジュール336に加えて、サーバモジュール334も、対象データの全体を格納するためのメモリを消費することになる。従って、上述の実施例のように、サーバモジュール334が指定された一部分のみを取得すれば、メモリ消費量の低減が可能となる。
変形例5:
上述の実施例では、クライアント装置(PDA100とTVセット110)と複合機200とのそれぞれがUPnP(商標)対応のネットワーク装置であったが、これらの装置100、110、200が、UPnP(商標)に対応していないネットワーク装置であってもよい。また、ネットワークとしては、インターネットプロトコルを利用したネットワークに限らず、任意のネットワークを採用可能である。
上述の実施例では、クライアント装置(PDA100とTVセット110)と複合機200とのそれぞれがUPnP(商標)対応のネットワーク装置であったが、これらの装置100、110、200が、UPnP(商標)に対応していないネットワーク装置であってもよい。また、ネットワークとしては、インターネットプロトコルを利用したネットワークに限らず、任意のネットワークを採用可能である。
変形例6:
上述の実施例では、サーバモジュール334は、データ取得要求の発行元のクライアント装置(コントロールポイント)を特定するためにIPアドレスを利用していたが、クライアント装置を特定する情報としては、IPアドレスに限らず任意の情報を採用可能である。例えば、イーサネット(登録商標)のMACアドレスを採用してもよい。
上述の実施例では、サーバモジュール334は、データ取得要求の発行元のクライアント装置(コントロールポイント)を特定するためにIPアドレスを利用していたが、クライアント装置を特定する情報としては、IPアドレスに限らず任意の情報を採用可能である。例えば、イーサネット(登録商標)のMACアドレスを採用してもよい。
また、同じクライアント装置上で複数のアプリケーションが動作し、各アプリケーションが独立してデータ取得要求を発行する場合がある。そこで、サーバモジュール334が、これらのアプリケーション毎に、部分的取得要求が新規なものか否かを判断してもよい。この場合には、クライアント装置において、アプリケーション毎に異なるポート番号(インターネットプロトコルのポート番号)が割り当てられる。そこで、サーバモジュール334は、IPアドレスとポート番号との組み合わせを用いることによって、アプリケーションを特定できる。ただし、部分的取得要求(部分的GETリクエスト)を発行するクライアント装置では、メモリ量が乏しい場合が多いので、複数のアプリケーションが独立にデータ取得要求を発行することが少ない。また、レンジをシフトさせつつ複数回の部分的GETリクエストが同じデータに対して発行される場合には、後のリクエスト発行時に割り当てられたポート番号が、先のリクエスト発行時に割り当てられたポート番号と異なっている場合がある。従って、上述の実施例のように、サーバモジュール334は、アプリケーションを特定せずに、クライアント装置と対象データ(URI)との組み合わせ毎に、部分的取得要求が新規なものであるか否かを判断してもよい。
変形例7:
上述の実施例において、バッファメモリ392に格納されたパケットの内の少なくとも一部が、そのパケットの全データがクライアント装置に送信される前であっても、所定の条件が満たされた場合に、バッファメモリ392から削除されることが好ましい。こうすれば、バッファメモリ392の容量が不足することを抑制できる。例えば、サーバモジュール334が、所定の削除条件を満たした部分的取得要求に応じたパケットを削除するためのコマンドを、サーバD4モジュール336に発行してもよい。この際、サーバモジュール334は、削除対象のリクエストIDをサーバD4モジュール336に渡せばよい。また、このような削除コマンドとしては、データがサーバモジュール334に提供されずに削除されるコマンドを採用することが好ましい。こうすれば、サーバD4モジュール336からサーバモジュール334に渡されるデータ量を低減できる。
上述の実施例において、バッファメモリ392に格納されたパケットの内の少なくとも一部が、そのパケットの全データがクライアント装置に送信される前であっても、所定の条件が満たされた場合に、バッファメモリ392から削除されることが好ましい。こうすれば、バッファメモリ392の容量が不足することを抑制できる。例えば、サーバモジュール334が、所定の削除条件を満たした部分的取得要求に応じたパケットを削除するためのコマンドを、サーバD4モジュール336に発行してもよい。この際、サーバモジュール334は、削除対象のリクエストIDをサーバD4モジュール336に渡せばよい。また、このような削除コマンドとしては、データがサーバモジュール334に提供されずに削除されるコマンドを採用することが好ましい。こうすれば、サーバD4モジュール336からサーバモジュール334に渡されるデータ量を低減できる。
なお、このような削除条件としては、任意の条件を採用可能である。例えば、管理テーブル390に格納されている取得要求の総数を所定の上限数(例えば、3つ)に限定してもよい。サーバモジュール334は、上限数の部分的取得要求が管理テーブル390に格納された状態で新たな部分的取得要求を管理テーブル390に格納する場合に、最初の部分的取得要求の受信時が最も古い部分的取得要求に関する情報を削除すればよい。具体的には、削除対象の部分的取得要求に関する情報を管理テーブル390から削除し、削除対象の部分的取得要求に応じたパケットの削除コマンドをサーバD4モジュール336に発行すればよい。また、サーバモジュール334は、同じクライアント装置からの同じデータに対する最後の部分的取得要求を受信してからの経過時間が所定時間(例えば、1時間)を越えた場合に、その部分的取得要求に関する情報を削除してもよい。
変形例8:
上述の実施例では、取得要求の対象データが1つのパケットでMFPデバイスユニット400からMFPサーバ300に転送されていたが、対象データが複数のパケットに分割して転送されてもよい。この場合には、MFPデバイスユニット400のデバイス機能モジュール434(図2)は、全てのパケットのリクエストIDを、サーバモジュール334に指定されたIDに設定する。また、サーバD4モジュール336は、全てのパケットをバッファメモリ392に格納する。ここで、クライアント装置が部分的取得要求を繰り返す場合には、サーバD4モジュール336は、先のパケットから順番に要求されたサイズのデータを抽出し、抽出データをサーバモジュール334に渡す。
上述の実施例では、取得要求の対象データが1つのパケットでMFPデバイスユニット400からMFPサーバ300に転送されていたが、対象データが複数のパケットに分割して転送されてもよい。この場合には、MFPデバイスユニット400のデバイス機能モジュール434(図2)は、全てのパケットのリクエストIDを、サーバモジュール334に指定されたIDに設定する。また、サーバD4モジュール336は、全てのパケットをバッファメモリ392に格納する。ここで、クライアント装置が部分的取得要求を繰り返す場合には、サーバD4モジュール336は、先のパケットから順番に要求されたサイズのデータを抽出し、抽出データをサーバモジュール334に渡す。
なお、MFPデバイスユニット400からサーバD4モジュール336に転送される各パケットのパケットヘッダのEOMについては、最後のパケットのEOMのみが「1(最後)」に設定され、他のパケットのEOMは「0(続き有り)」に設定される。また、サーバD4モジュール336からサーバモジュール334に渡されるEOMについては、抽出元のパケットのパケットヘッダのEOMに拘わらずに、対象データのうちの最後尾のデータを含む部分が渡される場合にのみEOMが「1」に設定され、他の部分のデータが渡される場合にはEOMは「0」に設定される。例えば、対象データが、1500バイトパケットと1000バイトパケットに分割して、MFPデバイスユニット400からサーバD4モジュール336に転送されたと仮定する。この場合には、最初の1500バイトパケットのEOMが「0」に設定され、最後の1000バイトパケットのEOMが「1」に設定される。次に、クライアント装置からの部分的取得要求に応じて、サーバモジュール334が、500バイトずつ対象データを転送すると仮定する。すると、サーバモジュール334は、500バイトのREADコマンドを5回発行することとなる。ここで、最初の4回のREADコマンドに応じて提供されるEOMは「0」に設定され、最後のREADコマンドに応じて提供されるEOMのみが「1」に設定される。
変形例9:
上述の実施例において、サーバモジュール334によるREADコマンドの発行(図5:S220)のタイミングとしては、クライアント装置からのデータ取得要求の受信後の任意のタイミングを採用可能である。例えば、サーバモジュール334が、サーバD4モジュール336によるデータのバッファメモリ392への格納の完了を確認した後に、READコマンドを発行してもよい。
上述の実施例において、サーバモジュール334によるREADコマンドの発行(図5:S220)のタイミングとしては、クライアント装置からのデータ取得要求の受信後の任意のタイミングを採用可能である。例えば、サーバモジュール334が、サーバD4モジュール336によるデータのバッファメモリ392への格納の完了を確認した後に、READコマンドを発行してもよい。
また、部分的取得要求に応じた処理としては、図5〜図8に示した手順に限らず、種々の手順を採用可能である。また、発行されるコマンドや転送されるメッセージとしても、図5〜図8に示したものに限らず、種々のものを採用可能である。
変形例10:
上述の実施例において、ネットワーク装置(複合機200)によって提供されるデータとしては、メモリカードMCに格納されたデータに限らず、任意のデータを採用可能である。例えば、MFPデバイスユニット400にスキャナを設け、このスキャナによって生成された画像データを提供してもよい。また、サービス装置としては、上述の実施例のMFPデバイスユニット400のような複数のデバイスの機能を有する装置に限らず、1つのデバイスの機能のみを有する装置を採用してもよい。ただし、サービス装置(MFPサーバ300)の機能が多いほど、サーバ装置(MFPサーバ300)とサービス装置(MFPデバイスユニット400)との間の通信量も増える傾向にあるので、通信の混雑の緩和の効果が顕著である。
上述の実施例において、ネットワーク装置(複合機200)によって提供されるデータとしては、メモリカードMCに格納されたデータに限らず、任意のデータを採用可能である。例えば、MFPデバイスユニット400にスキャナを設け、このスキャナによって生成された画像データを提供してもよい。また、サービス装置としては、上述の実施例のMFPデバイスユニット400のような複数のデバイスの機能を有する装置に限らず、1つのデバイスの機能のみを有する装置を採用してもよい。ただし、サービス装置(MFPサーバ300)の機能が多いほど、サーバ装置(MFPサーバ300)とサービス装置(MFPデバイスユニット400)との間の通信量も増える傾向にあるので、通信の混雑の緩和の効果が顕著である。
変形例11:
上記各実施例において、ハードウェアによって実現されていた構成の一部をソフトウェアに置き換えるようにしてもよく、逆に、ソフトウェアによって実現されていた構成の一部をハードウェアに置き換えるようにしてもよい。例えば、図2のサーバモジュール334の機能を、論理回路を有するハードウェア回路によって実現することとしてもよい。
上記各実施例において、ハードウェアによって実現されていた構成の一部をソフトウェアに置き換えるようにしてもよく、逆に、ソフトウェアによって実現されていた構成の一部をハードウェアに置き換えるようにしてもよい。例えば、図2のサーバモジュール334の機能を、論理回路を有するハードウェア回路によって実現することとしてもよい。
なお、本発明の機能の一部または全部がソフトウェアで実現される場合には、そのソフトウェア(コンピュータプログラム)は、コンピュータ読み取り可能な記録媒体に格納された形で提供することができる。この発明において、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスクやCD−ROMのような携帯型の記録媒体に限らず、各種のRAMやROM等のコンピュータ内の内部記憶装置や、ハードディスク等のコンピュータに固定されている外部記憶装置も含んでいる。
10…ネットワークシステム
100…PDA
100C…コントロールポイント
110…TVセット
110C…コントロールポイント
200…複合機
300…MFPサーバ
310…中央制御部
320…RAM
330…ROM
332…ネットワークモジュール
334…サーバモジュール
336…D4プロトコル処理モジュール(サーバD4モジュール)
338…USB制御モジュール
340…ネットワーク制御部
342…コネクタ
350…USBホスト制御部
352…ルートハブ
354…USBコネクタ
390…管理テーブル
392…バッファメモリ
400…MFPデバイスユニット
410…中央制御部
420…RAM
430…ROM
434…デバイス機能モジュール
436…D4プロトコル処理モジュール(デバイスD4モジュール)
438…USB制御モジュール
440…印刷エンジン
460…USBデバイス制御部
462…USBコネクタ
482…スロット
MC…メモリカード
100…PDA
100C…コントロールポイント
110…TVセット
110C…コントロールポイント
200…複合機
300…MFPサーバ
310…中央制御部
320…RAM
330…ROM
332…ネットワークモジュール
334…サーバモジュール
336…D4プロトコル処理モジュール(サーバD4モジュール)
338…USB制御モジュール
340…ネットワーク制御部
342…コネクタ
350…USBホスト制御部
352…ルートハブ
354…USBコネクタ
390…管理テーブル
392…バッファメモリ
400…MFPデバイスユニット
410…中央制御部
420…RAM
430…ROM
434…デバイス機能モジュール
436…D4プロトコル処理モジュール(デバイスD4モジュール)
438…USB制御モジュール
440…印刷エンジン
460…USBデバイス制御部
462…USBコネクタ
482…スロット
MC…メモリカード
Claims (3)
- ネットワークに接続されるネットワーク装置であって、
前記ネットワーク上のクライアント装置からの要求に応じて対象データを提供するサービス装置と、
前記ネットワークと前記サービス装置とに接続されるとともに、前記クライアント装置と前記サービス装置との間の通信を制御するサーバ装置と、
を備え、
前記サーバ装置は、バッファメモリを有し、
前記サーバ装置は、前記クライアント装置から前記対象データの一部分である第1部分データの取得要求を受けたことに応じて、前記対象データの全体の取得要求を前記サービス装置に送信し、
前記バッファメモリは、前記サービス装置から送られてきた前記対象データの全体を格納し、
前記サーバ装置は、前記バッファメモリに格納された前記対象データから前記第1部分データを抽出し、前記第1部分データを前記クライアント装置に送信し、
前記サーバ装置は、前記対象データの取得後に同じ前記クライアント装置から同じ前記対象データの残りの部分の少なくとも一部である第2部分データの取得要求を受けたことに応じて、前記対象データの取得要求を前記サービス装置に送信せずに前記バッファメモリに格納された前記対象データから前記第2部分データを抽出し、前記第2部分データを前記クライアント装置に送信する、
ネットワーク装置。 - 請求項1に記載のネットワーク装置であって、
前記サーバ装置は、
前記クライアント装置と前記サービス装置との間の通信を制御するサーバモジュールと、
前記サーバモジュールの下位層で、前記サービス装置とのデータ通信を行うデータ処理モジュールと、
を有し、
前記バッファメモリは、前記サーバモジュールの下位層に設けられるとともに、前記データ処理モジュールによって利用され、
前記サーバモジュールは、前記クライアント装置から前記第1部分データの取得要求を受けたことに応じて、前記対象データの全体の取得要求を前記サービス装置に送信する送信命令を、前記データ処理モジュールに対して発行し、
前記データ処理モジュールは、前記送信命令に応じて前記全体の取得要求を前記サービス装置に送信するとともに、前記サービス装置から送られてきた前記対象データの全体を、前記バッファメモリに格納し、
前記サーバモジュールは、前記第1部分データのみを提供する提供命令を、前記データ処理モジュールに対して発行し、
前記データ処理モジュールは、前記提供命令に応じて、前記バッファメモリに格納された前記対象データから前記第1部分データを抽出し、前記第1部分データを前記サーバモジュールに提供し、
前記サーバモジュールは、提供された前記第1部分データを前記クライアント装置に送信する、
ネットワーク装置。 - ネットワークに接続されるネットワーク装置の制御方法であって、
前記ネットワーク装置は、
前記ネットワーク上のクライアント装置からの要求に応じて対象データを提供するサービス装置と、
前記ネットワークと前記サービス装置とに接続されるとともに、前記クライアント装置と前記サービス装置との間の通信を制御するサーバ装置と、
を備え、
前記サーバ装置は、バッファメモリを有し、
前記制御方法は、
(A)前記サーバ装置が、前記クライアント装置から前記対象データの一部分である第1部分データの取得要求を受けたことに応じて、前記対象データの全体の取得要求を前記サービス装置に送信する工程と、
(B)前記バッファメモリが、前記サービス装置から送られてきた前記対象データの全体を格納する工程と、
(C)前記サーバ装置が、前記バッファメモリに格納された前記対象データから前記第1部分データを抽出し、前記第1部分データを前記クライアント装置に送信する工程と、
(D)前記サーバ装置が、前記対象データの取得後に同じ前記クライアント装置から同じ前記対象データの残りの部分の少なくとも一部である第2部分データの取得要求を受けたことに応じて、前記対象データの取得要求を前記サービス装置に送信せずに前記バッファメモリに格納された前記対象データから前記第2部分データを抽出し、前記第2部分データを前記クライアント装置に送信する工程と、
を備える、制御方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005367396A JP2007172196A (ja) | 2005-12-21 | 2005-12-21 | ネットワーク装置におけるデータの管理 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005367396A JP2007172196A (ja) | 2005-12-21 | 2005-12-21 | ネットワーク装置におけるデータの管理 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007172196A true JP2007172196A (ja) | 2007-07-05 |
Family
ID=38298691
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005367396A Pending JP2007172196A (ja) | 2005-12-21 | 2005-12-21 | ネットワーク装置におけるデータの管理 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007172196A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009093414A (ja) * | 2007-10-09 | 2009-04-30 | Brother Ind Ltd | サムネイル配信システム、サーバ、クライアント、およびプログラム |
JP2021105800A (ja) * | 2019-12-26 | 2021-07-26 | ブラザー工業株式会社 | プログラム、プログラム群、および情報処理装置 |
-
2005
- 2005-12-21 JP JP2005367396A patent/JP2007172196A/ja active Pending
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009093414A (ja) * | 2007-10-09 | 2009-04-30 | Brother Ind Ltd | サムネイル配信システム、サーバ、クライアント、およびプログラム |
JP4561804B2 (ja) * | 2007-10-09 | 2010-10-13 | ブラザー工業株式会社 | サムネイル配信システム、サーバ、クライアント、およびプログラム |
US9251288B2 (en) | 2007-10-09 | 2016-02-02 | Brother Kogyo Kabushiki Kaisha | Thumbnail distribution system, server, client and program |
JP2021105800A (ja) * | 2019-12-26 | 2021-07-26 | ブラザー工業株式会社 | プログラム、プログラム群、および情報処理装置 |
JP7338461B2 (ja) | 2019-12-26 | 2023-09-05 | ブラザー工業株式会社 | プログラム、プログラム群、および情報処理装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8593656B2 (en) | Information processing system, information processor and signal transmitting device | |
US8363257B2 (en) | Data processing apparatus, data processing system, method for controlling data processing apparatus, method for adding data converting function, program and medium | |
JP5654806B2 (ja) | サーバシステムとプリント装置及びそれらを有するネットワーク印刷システムとそれらにおける方法 | |
JP2010157208A (ja) | データ処理装置、プリンタネットワークシステム、データ処理方法、プログラムおよび記録媒体 | |
US9928013B2 (en) | Print control system, method of controlling printing, and recording medium | |
JPH1185662A (ja) | 通信制御方法及び装置及び通信システム | |
WO2006064650A1 (ja) | プロファイル取得方法、装置、プログラム、及び、記録媒体 | |
JPH11327815A (ja) | 通信制御方法及び装置及び通信システム | |
JP6190207B2 (ja) | システム、情報処理方法、処理装置、処理方法、及びプログラム | |
JP2007172196A (ja) | ネットワーク装置におけるデータの管理 | |
US9977632B2 (en) | Apparatus and method for processing information on file or job | |
US20130010319A1 (en) | Image forming system, output management method, and program product | |
JP2017151961A (ja) | (ipp上の)デバイス制御プロトコル | |
JP2011114805A (ja) | 通信装置及び方法、並びにプログラム | |
JP2010183530A (ja) | 蓄積装置及びコピーシステム | |
JP2004284259A (ja) | 画像形成装置及びその方法 | |
JP5884884B2 (ja) | データ処理装置、印刷システム、データ処理方法、プログラムおよび記録媒体 | |
JP2008085778A (ja) | 情報通信システムおよび受信装置および送信装置および受信制御プログラムおよび送信制御プログラム | |
JP4665705B2 (ja) | ネットワークプリンタにおけるデータ通信用クレジットの取得 | |
JP2005349768A (ja) | 印刷装置及び印刷方法 | |
JP2004013429A (ja) | データ制御方式及び記録装置 | |
JP2004126943A (ja) | 印刷処理装置、印刷処理方法及び印刷処理プログラム | |
JP5470518B2 (ja) | デバイス共有システム、デバイス共有クライアント、およびデバイス共有方法 | |
JP2002185693A (ja) | インターネットファクシミリ装置およびその制御方法 | |
JP4164243B2 (ja) | 印刷監視システム、印刷監視方法、及びコンピュータプログラム |