(57)【特許請求の範囲】
【請求項１】
予め定められたプロトコルに従ってネットワーク上に複数の印刷装置とホストコンピュータとが接続された印刷システムの印刷装置であって、
該印刷装置が代表プリンタであるか又はクライアントプリンタであるかを決定する決定手段と、
代表プリンタであることを示す識別子を含み、前記プロトコルに従った識別データを生成する識別データ生成手段と、
前記決定手段により前記印刷装置が代表プリンタと決定された場合には、前記複数の印刷装置と前記ホストコンピュータに対して、前記識別データをマルチキャストパケットを用いて通知する通知手段と、
前記決定手段により前記印刷装置が代表プリンタではないと決定された場合には、代表プリンタとして動作する印刷装置から送信されるマルチキャストパケットを受信可能な受信手段とを有し、
前記決定手段は前記受信手段により受信したマルチキャストパケットが含む識別データに含まれる識別子と前記識別データ生成手段により生成された識別データに含まれる識別子とが一致した場合には、前記印刷装置をクライアントプリンタであると決定することを特徴とする印刷装置。
【請求項２】
前記予め定められたプロトコルは、ＵＰｎＰあるいはＷＳＤプロトコルであることを特徴とする請求項１に記載の印刷装置。
【請求項３】
前記通知手段は、Ｈｅｌｌｏマルチキャストパケットを送出することを特徴とする請求項２に記載の印刷装置。
【請求項４】
前記決定手段により前記印刷装置が代表プリンタであると決定された場合、前記ネットワークの接続を解除するマルチキャストパケットを前記ネットワーク上の前記複数の印刷装置と前記ホストコンピュータとに送信した後に、前記通知手段により改めて代表プリンタとして前記ネットワークに再接続することを特徴とする請求項１乃至３のいずれか１項に記載の印刷装置。
【請求項５】
前記受信手段により、代表プリンタとして動作する他の印刷装置からのマルチキャストパケットが受信されない場合、前記ネットワーク上の代表プリンタを探索するパケットを送出する探索手段をさらに有することを特徴とする請求項１乃至３のいずれか１項に記載の印刷装置。
【請求項６】
前記識別データ生成手段は、前記識別データとして代表プリンタであることを示す所定の識別子が含まれたＵＵＩＤを生成することを特徴とする請求項１乃至５のいずれか１項に記載の印刷装置。
【請求項７】
予め定められたプロトコルに従ってネットワークを介して印刷装置とホストコンピュータとを接続した印刷システムであって、
前記印刷装置は、
該印刷装置が代表プリンタであるか又はクライアントプリンタであるかを決定する第１の決定手段と、
代表プリンタであることを示す識別子を含み、前記プロトコルに従った識別データを生成する識別データ生成手段と、
前記第１の決定手段により前記印刷装置が代表プリンタと決定された場合には、前記複数の印刷装置と前記ホストコンピュータに対して、前記識別データをマルチキャストパケットを用いて通知する第１の通知手段と、
前記第１の決定手段により前記印刷装置が代表プリンタではないと決定された場合には、代表プリンタとして動作する他の印刷装置から送信されるマルチキャストパケットを受信可能な受信手段とを有し、
前記ホストコンピュータは、
前記第１の通知手段により通知されるマルチキャストパケットに従って、前記代表プリンタとして動作する印刷装置に対してメタデータの送信要求を行なう第１の要求手段と、
前記第１の要求手段による要求に応じて前記代表プリンタとして動作する印刷装置から送信されるメタデータを受信し、該受信したメタデータに基づいて、前記代表プリンタとして動作する印刷装置の状態を表わすアイコンを表示する表示手段と、
前記ホストコンピュータ自身がプライマリサーバとするか又はセカンダリサーバとするか又はクライアントとするかを決定する第２の決定手段と、
前記第２の決定手段が前記ホストコンピュータ自身をプライマリサーバ又はセカンダリサーバと決定した場合には、サーバ用のメタデータを生成する生成手段と、
前記ネットワークに接続された前記複数の印刷装置又は他のホストコンピュータに対して、サーバであることを示す識別子をマルチキャストパケットを用いて通知する第２の通知手段と、
前記複数の印刷装置又は前記他のホストコンピュータからの要求に応じて、前記要求を発行した印刷装置或は他のホストコンピュータに対して、メタデータを送信する送信手段とを有することを特徴とする印刷システム。
【請求項８】
前記ホストコンピュータはさらに、
前記第２の決定手段がクライアントと決定した場合には、サーバとして動作する他のホストコンピュータからのマルチキャストパケットを受信するように自分自身を設定する設定手段と、
前記受信したマルチキャストパケットに応じてサーバとして動作する他のホストコンピュータに対してメタデータの要求を行なう第２の要求手段と、
前記第２の要求手段による要求に応じて送信されるメタデータを受信する受信手段とを有することを特徴とする請求項７に記載の印刷システム。
【請求項９】
請求項１乃至６のいずれか１項に記載の印刷装置の各手段をコンピュータに実行させるプログラム。
【請求項１０】
予め定められたプロトコルに従ってネットワーク上に複数の印刷装置とホストコンピュータとが接続された印刷システムの印刷装置であって、
該印刷装置を含む前記複数の印刷装置の中から代表プリンタと決定された場合には、前記複数の印刷装置と前記ホストコンピュータに対して、代表プリンタであることを示す識別子をマルチキャストパケットを用いて通知する通知手段と、
前記印刷装置が代表プリンタではないと決定された場合には、代表プリンタとして動作する印刷装置から送信されるマルチキャストパケットを受信できるように設定する設定手段と、
前記印刷装置が代表プリンタであると決定された場合、前記ネットワークの接続を解除するマルチキャストパケットを前記ネットワーク上の前記複数の印刷装置と前記ホストコンピュータとに送信する接続解除手段とを有し、
前記通知手段により改めて代表プリンタとして前記ネットワークに再接続することを特徴とする印刷装置。
【請求項１１】
予め定められたプロトコルに従ってネットワークを介して印刷装置とホストコンピュータとを接続した印刷システムであって、
前記印刷装置は、
該印刷装置を含む複数の印刷装置の中から代表プリンタと決定された場合には、前記複数の印刷装置と前記ホストコンピュータに対して、代表プリンタであることを示す識別子をマルチキャストパケットを用いて通知する通知手段と、
前記印刷装置が代表プリンタではないと決定された場合には、代表プリンタとして動作する他の印刷装置からのマルチキャストパケットを受信できるように設定する設定手段とを有し、
前記ホストコンピュータは、
前記通知手段により通知されるマルチキャストパケットに従って、前記代表プリンタとして動作する印刷装置に対してメタデータの送信要求を行なう要求手段と、
前記要求手段による要求に応じて前記代表プリンタとして動作する印刷装置から送信されるメタデータを受信し、該受信したメタデータに基づいて、前記代表プリンタとして動作する印刷装置の状態を表わすアイコンを表示する表示手段と、
ユーザからの指示に従うか或は自律的に、自分自身をプライマリサーバとするか、セカンダリサーバとするか、或は、クライアントとするかを決定する決定手段と、
前記決定手段がプライマリサーバ或はセカンダリサーバと決定した場合には、サーバ用のメタデータを生成する生成手段と、
前記ネットワークに接続された前記複数の印刷装置或は他のホストコンピュータに対して、サーバであることを示す識別子をマルチキャストパケットを用いて通知する通知手段と、
前記複数の印刷装置或は前記他のホストコンピュータからの要求に応じて、前記要求を発行した印刷装置或は他のホストコンピュータに対して、メタデータを送信する送信手段とを有することを特徴とする印刷システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は印刷装置及び印刷システムに関し、特に、ネットワークに接続され、例えば、ＷＳＤプロトコルに従ってマルチキャストパケットによる通信を行なう印刷装置及び印刷システムに関する。
【背景技術】
【０００２】
近年、ネットワーク対応機器の増加に伴い、ネットワーク上のデバイス同士の為の通信プロトコル、デバイスのディスカバリの仕組み、デバイスのインストールの仕組み、印刷・スキャン等の各種サービスの仕様が標準規格化されている。また、クライアントＰＣからより汎用的にネットワーク機器を利用する為の標準通信プロトコルや、より簡単にデバイスを使用するためのサービスが規格化されている。例えば、ＷＳＤ（Ｗｅｂ  Ｓｅｒｖｉｃｅ  ｆｏｒ  Ｄｅｖｉｃｅｓ）やＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ＆Ｐｌａｙ）（登録商標）がある。
【０００３】
ＷＳＤは、デバイスを用いた様々なサービスの要求に答える為に定義された標準仕様である（非特許文献１）。基本的にＷｅｂサービスのアーキテクチャを使用し、標準化された通信プロトコル群、印刷サービス及びスキャンサービスを提供している。ＷＳＤはＷｅｂサービスをベースとしたデバイス同士の相互接続を可能とする為のネットワーク上の標準通信プロトコル群を用いる。デバイス用のＷｅｂサービスの構成要素として、デバイス発見（Ｄｉｓｃｏｖｅｒｙ）、デバイス情報提示（Ｄｅｓｃｒｉｐｔｉｏｎ）、デバイス制御（Ｃｏｎｔｒｏｌ）、デバイスのイベント通知（Ｅｖｅｎｔｉｎｇ）等の仕様が定められている。
【０００４】
また、ネットワーク経由で接続するデバイスに対してＭｉｃｒｏｓｏｆｔ社が提唱するＰｎＰ−Ｘ（Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ  ｅＸｔｅｎｓｉｏｎｓ）を使用して、ＰｎＰ−Ｘ対応のクライアントＰＣへデバイスドライバを簡単にインストールできる。従来のＰｎＰ（Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ）では各デバイスとクライアントＰＣを様々なローカルのＩ／Ｏポートに直接ケーブルやコネクタで接続した際に働く機能である。ＰｎＰでは、デバイスが機種名（デバイスＩＤ）や製造者名（ベンダＩＤ）、シリアル番号等をホストＰＣに送信する。ホストＰＣはこれら受信した情報を参照して、デバイスを使用するためのデバイスドライバをクライアントに自動でインストールすることが可能である。
【０００５】
Ｕｐｎｐも、ＷＳＤと同様にデバイスを用いた様々なサービスの要求に答える為に定義された標準仕様である（非特許文献２）。Ｕｐｎｐは、標準化された通信プロトコル群、印刷サービス及びスキャンサービス、ＡＶ機器制御サービスなどを提供している。Ｕｐｎｐには、デバイス発見（Ｄｉｓｃｏｖｅｒｙ）、デバイス情報提示（Ｄｅｓｃｒｉｐｔｉｏｎ）、デバイス制御（Ｃｏｎｔｒｏｌ）、デバイスのイベント通知（Ｅｖｅｎｔｉｎｇ）等の仕様が定められている。
【０００６】
またＵｐｎｐを用いてデバイスの相互接続性を確保するためＤＬＮＡなどの組織で互換性に関する検討が行われている。ＵｐｎｐはＰＣ以外にも多くのＡＶ機器、家電、ネットワーク機器での採用が進んでいる。
【０００７】
ＷＳＤ通信プロトコルと印刷サービスとの関係
ＷＳＤ印刷サービスには、印刷データを送信するためのＳｅｎｄＤｏｃｕｍｅｎｔコマンドやプリンタのステータス情報を取得するためのＧｅｔＰｒｉｎｔｅｒＥｌｅｍｎｔｓなどがある。印刷を行うにはこれらコマンドを組み合わせて使用することで実行することができる。これらコマンド処理がＣｏｎｔｒｏｌとなる。また、デバイスで発生したイベントをホストへ知らせるための仕組みとしてＥｖｅｎｔｉｎｇがあり、ホストは取得したいイベントに対してＳｕｂｓｃｒｉｂｅコマンドを発行し、ホスト側のイベントに対するアクセス先を登録する。デバイスは登録されたイベントに対する事象が発生した場合、登録されたホストに対してイベントを通知する。コマンド・イベントのやり取りはＴＣＰ／ＩＰ上でＨＴＴＰを使用し、ＨＴＴＰ上でＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）を利用する。ＳＯＡＰ上にＸＭＬで記述されたサービスのコマンドをやり取りすることで各種コマンドが実行される。Ｄｉｓｃｏｖｅｒｙで使用されるメッセージのやり取りは標準的な通信プロトコルの一つであるＵＤＰ上でＳＯＡＰを利用する。ＳＯＡＰ上にＸＭＬで記述されたメッセージをやり取りすることでメッセージの交換が実行される。これをＳＯＡＰ−Ｏｖｅｒ−ＵＤＰ通信という。
【０００８】
Ｕｐｎｐ通信プロトコルと印刷サービスとの関係
Ｕｐｎｐ印刷サービスでは目的とするアドレスに対して印刷サービスで規定されているコマンドを送信することにより実行される。また、デバイスで発生したイベントをホストへ知らせるための仕組みとしてＥｖｅｎｔｉｎｇがある。即ち、ホストは取得したいイベントに対してＳｕｂｓｃｒｉｂｅコマンドを発行し、ホスト側のイベントに対するアクセス先を登録する。デバイスは登録されたイベントに対する事象が発生した場合、登録されたホストに対してイベントを通知する。コマンド・イベントのやり取りはＴＣＰ／ＩＰ上でＨＴＴＰを使用し、ＨＴＴＰ上でＳＯＡＰを利用する。ＳＯＡＰ上にＸＭＬで記述されたサービスのコマンドをやり取りすることで各種コマンドが実行される。ＵｐｎｐとＷＳＤでの違いは、Ｕｐｎｐでは定期的にＳＳＤＰを使いデバイスの状態を通知する機能がある点にある。ＵｐｎｐではこのＳＳＤＰのメッセージを受け取ることで最新のデバイスの接続状態を知ることができる。
【０００９】
これらのプロトコルには、前述したように、あるデバイスの状態を他のデバイスに通知する仕組みとして、イベントデータの送付やステータス問い合わせに応答する形でデバイス状態を通知する仕組みが標準的に定められている。これらの仕組みを利用した装置として、例えば、紙無しエラー等の情報をイベント送信によってホストＰＣに通知するＷＳＤプロトコルを備えたプリンタが知られている。また同様に、ＷＳＤプロトコルを備えたプリンタにおいて、ステータス問い合わせに対して紙無しエラー等の状態を応答する装置も知られている。
【００１０】
一方、前述のイベント送付やステータス応答の仕組みと異なり、特定のホストに限らずネットワーク接続された多数のホストにデバイス状態を通知する技術としては、例えば、特許文献１〜３に記載のような技術が知られている。特許文献１では、ＵＰｎＰプロトコルを備えたデバイスにおいて、拡張デバイスが追加されて新たに機能が追加されると、自分自身の基本のサービス情報に追加機能に関するサービス情報を追加して、ネットワーク上に公開する構成を開示している。特許文献２によれば、意図したネットワークデバイスのみの自動インストールを行うために、予めクライアントとデバイス側に一時的な識別情報を設定する。そして、デバイスは、ＷＳＤプロトコルで定められたネットワーク接続メッセージであるＨｅｌｌｏメッセージにその識別情報を付加して送信する。一方、クライアントは、その識別情報を持つＨｅｌｌｏメッセージのみ認識する。引用文献３では、プリンタからＷＳＤプロトコルで規定されたＢｙｅメッセージを受信すると、クライアントはＢｙｅメッセージの原因（スリープ、故障、オフライン等）を判断して、プリンタアイコンの種類を変更する構成を開示している。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００６−２０２２１０号公報
【特許文献２】特開２００７−０６６０９２号公報
【特許文献３】特開２００７−１２２３７６号公報
【非特許文献】
【００１２】
【非特許文献１】Device Profile for Web Services, Feb 2006  (http://specs.xmlsoap.org/ws/2006/02/devprof/ )
【非特許文献２】UPnPIM Device Architecture   (http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20080424.pdf)
【発明の概要】
【発明が解決しようとする課題】
【００１３】
前述のＷＳＤやＵＰｎＰプロトコルで標準的に定められたイベント送付方式やステータス問い合わせに応答する形でデバイス状態を通知する仕組みは、ネットワーク接続された不特定多数のホストにデバイス状態を通知するのに不適当であるという課題がある。
【００１４】
即ち、イベント送付方式であれば、イベントを送付する対象であるホストデバイスを事前の登録などにより予め知っている必要があり、不特定のホストにデバイス状態を通知することはできない。また、多数のデバイスに通知する場合には、元々イベント送付方式が１対１通信を基本としているため、通知対象とするホスト数の分だけイベント送付を繰り返さなければならない。従って、ネットワークトラフィック増大や処理の煩雑さという課題が生じる。
【００１５】
また、ステータス応答方式は、周辺デバイス側から特定のデバイスに対してステータス問い合わせを行う仕組みであるため、デバイスの状態の変化を適時に知るためにはステータス問い合わせのポーリングを行う必要がある。従って、処理の煩雑さや、特に多数の周辺デバイスが存在する場合のネットワークトラフィック増大という課題がある。
【００１６】
ＷＳＤやＵＰｎＰプロトコルを利用して不特定多数のホストにデバイス状態を通知する際の課題を解決するために、ＷＳＤやＵＰｎＰにおけるネットワーク接続メッセージを応用した方式が考えられる。この方式によれば、デバイスの状態の変化時にネットワーク接続メッセージを再発行して、Ｄｉｓｃｏｖｅｒｙ後に応答するデバイス情報の中に通知したい状態を記載する。この例が、特許文献１に開示された技術である。しかしながら、この方式では、周辺デバイスがあるデバイスの状態を知るためには、ネットワーク接続メッセージ受信後に、必ずそのデバイスに対して問い合わせをする必要がある。従って、ネットワーク接続メッセージ発行後に問い合わせが集中し、ネットワークトラフィックが増大してしまうという課題がある。
【００１７】
上記の課題を解決しつつ、不特定多数のホストにデバイス状態を通知する技術として、特許文献２や特許文献３に開示された方式も考えられている。この方式によれば、標準規格化されているネットワーク接続あるいは離脱メッセージを独自に拡張し、そこにデバイスの状態を保存して送信する。この方式は、マルチキャストパケットであるネットワーク接続あるいは離脱メッセージで状態を通知するため、不特定多数のデバイスに１つのパケットで状態を通知できる、即ち、ネットワークトラフィックの増大が生じないという利点がある。しかしながら、この方式では、独自拡張したパケットに対応していない装置に対し不具合が発生しない事を確認するためには、接続検証作業が必要であるという別の課題がある。
【００１８】
本発明は上記従来例に鑑みてなされたもので、不特定多数の装置の状態確認をネットワークトラフィックを増大させることなく行なうことができる印刷装置及び印刷システムを提供することを目的としている。
【課題を解決するための手段】
【００１９】
上記目的を達成するために本発明の印刷装置は次のような構成からなる。
【００２０】
即ち、予め定められたプロトコルに従ってネットワーク上に複数の印刷装置とホストコンピュータとが接続された印刷システムの印刷装置であって、該印刷装置が代表プリンタであるか又はクライアントプリンタであるかを決定する決定手段と、代表プリンタであることを示す識別子を含み、前記プロトコルに従った識別データを生成する識別データ生成手段と、前記決定手段により前記印刷装置が代表プリンタと決定された場合には、前記複数の印刷装置と前記ホストコンピュータに対して、前記識別データをマルチキャストパケットを用いて通知する通知手段と、前記決定手段により前記印刷装置が代表プリンタではないと決定された場合には、代表プリンタとして動作する印刷装置から送信されるマルチキャストパケットを受信可能な受信手段とを有し、前記決定手段は前記受信手段により受信したマルチキャストパケットが含む識別データに含まれる識別子と前記識別データ生成手段により生成された識別データに含まれる識別子とが一致した場合には、前記印刷装置をクライアントプリンタであると決定することを特徴とする。
【００２１】
また他の発明によれば、予め定められたプロトコルに従ってネットワークを介して印刷装置とホストコンピュータとを接続した印刷システムであって、前記印刷装置は、該印刷装置が代表プリンタであるか又はクライアントプリンタであるかを決定する第１の決定手段と、代表プリンタであることを示す識別子を含み、前記プロトコルに従った識別データを生成する識別データ生成手段と、前記第１の決定手段により前記印刷装置が代表プリンタと決定された場合には、前記複数の印刷装置と前記ホストコンピュータに対して、前記識別データをマルチキャストパケットを用いて通知する第１の通知手段と、前記第１の決定手段により前記印刷装置が代表プリンタではないと決定された場合には、代表プリンタとして動作する他の印刷装置から送信されるマルチキャストパケットを受信可能な受信手段とを有し、前記ホストコンピュータは、前記第１の通知手段により通知されるマルチキャストパケットに従って、前記代表プリンタとして動作する印刷装置に対してメタデータの送信要求を行なう第１の要求手段と、前記第１の要求手段による要求に応じて前記代表プリンタとして動作する印刷装置から送信されるメタデータを受信し、該受信したメタデータに基づいて、前記代表プリンタとして動作する印刷装置の状態を表わすアイコンを表示する表示手段と、前記ホストコンピュータ自身がプライマリサーバとするか又はセカンダリサーバとするか又はクライアントとするかを決定する第２の決定手段と、前記第２の決定手段が前記ホストコンピュータ自身をプライマリサーバ又はセカンダリサーバと決定した場合には、サーバ用のメタデータを生成する生成手段と、前記ネットワークに接続された前記複数の印刷装置又は他のホストコンピュータに対して、サーバであることを示す識別子をマルチキャストパケットを用いて通知する第２の通知手段と、前記複数の印刷装置又は前記他のホストコンピュータからの要求に応じて、前記要求を発行した印刷装置或は他のホストコンピュータに対して、メタデータを送信する送信手段とを有することを特徴とする印刷システムを備える。
【００２２】
さらに他の発明によれば上記構成の印刷装置の各手段をコンピュータに実行させるプログラムを備える。
【発明の効果】
【００２３】
従って本発明によれば、ネットワークに接続された各装置の状態を不特定多数の他の装置に１つのパケットで通知できるので、ネットワークトラフィックを増大させることが無いという効果がある。また、予め定められたプロトコルに従って状態の通知を行なうので、装置との接続検証作業が必要ではないという利点がある。
【００２４】
さらに、マルチキャストパケットを受信する受信側の装置がメタデータの要求を行なって、その要求に応じてメタデータを取得するので、必要な場合にのみメタデータ取得がなされ、不必要にネットワークトラフィックを発生させないという利点もある。
【図面の簡単な説明】
【００２５】
【図１】本発明の代表的な実施例である印刷装置のハードウェア構成の概略を示す図である。
【図２】印刷装置のソフトウェア構成の概略を示す図である。
【図３】印刷装置管理アプリケーションモジュール２１０の機能構成を示すブロック図である。
【図４】ＷＳＤプロトコルを採用した印刷装置管理アプリケーションモジュール２１０の動作概要を示すフローチャートである。
【図５】印刷装置２台とＰＣ１台とによるネットワークを介したデータ送受信の様子を示す図である。
【図６】印刷装置がクライアント或は代表プリンタとして動作する際に発行するＨｅｌｌｏマルチキャストパケットの例を示す図である。
【図７】印刷装置がクライアント或は代表プリンタとして動作する際に応答するＰｒｏｂｅＭａｔｃｈｅｓパケットの例を示す図である。
【図８】印刷装置がクライアント或は代表プリンタとして動作する際にメタデータ取得要求に対して応答するメタデータの例を示す図である。
【図９】印刷装置がクライアントとして動作している状態から代表プリンタとして動作するように移行した場合に、ＰＣ上で印刷装置を表すアイコン表示状態がどのように変化するのかの例を示す図である。
【図１０】他の実施例に従うパーソナルコンピュータ（ＰＣ）のハードウェア構成の概略を示す図である。
【図１１】ＷＳＤプロトコルを採用したＰＣ４０１がどのように動作するかを説明するフローチャートである。
【図１２】ＰＣが３つの異なる動作をする場合に発行されるＨｅｌｌｏマルチキャストパケットの例を示す図である。
【発明を実施するための形態】
【００２６】
以下添付図面を参照して本発明の好適な実施例について、さらに具体的かつ詳細に説明する。
【００２７】
図１は本発明の代表的な実施例である印刷システムのハードウェア構成の概略を示す図である。図１に示すように、印刷装置１０１はプリンタエンジン１０７、ＣＰＵ１０２、ＲＯＭ１０３、ＲＡＭ１０４、操作部１０５、ネットワークコントローラ１０６を備える。印刷装置１０１はネットワークコントローラ１０６を介してネットワークに接続され、ネットワークに接続された複数の機器と通信可能なように構成されている。ネットワーク上には、本実施例を採用した別の印刷装置１０１ａ、１０１ｂが接続されている。また、ＰＣ（ホストコンピュータ）１１０もネットワークに接続されている。なお、ネットワークはこの実施例ではＥｔｈｅｒｎｅｔ（登録商標）のＬＡＮを用いているが、別のＬＡＮ、例えば、無線ＬＡＮなどを用いても良い。
【００２８】
図２は、印刷装置のソフトウェア構成の概略を示す図である。図２に示すように、印刷装置１０１は、オペレーティングシステム２０１上で各ソフトウェアモジュールが動作するように構成されている。オペレーティングシステム２０１上では、ネットワークの通信を担当するミドルウェア２０２が動作し、さらにその上位にネットワークにより送受信されるデータを利用するアプリケーションプログラム２０３が動作する。
【００２９】
ミドルウェア２０２はいくつかのレイヤに分かれ、その最下層では、ネットワークコントローラ１０６を制御するＬＡＮドライバ２０４が動作する。その上位には、ネットワークの基本的な通信プロトコルを制御するＴＣＰ／ＩＰ通信モジュール２０５、ＵＤＰ通信モジュール２０６、及びＨＴＴＰ通信モジュール２０７が動作する。さらにその上位では、これらの通信プロトコルを利用したＵＰｎＰプロトコルやＷＳＤプロトコルを制御するＵＰｎＰモジュール２０８及びＷＳＤモジュール２０９が動作する。
【００３０】
アプリケーションプログラム（以下、プログラム）２０３には、ＵＰｎＰプロトコルやＷＳＤプロトコルを利用して印刷を行う印刷アプリケーションモジュール２１１が含まれる。また、この実施例では、ネットワーク上における印刷装置１０１の各種振る舞いを管理するための印刷装置管理アプリケーションモジュール２１０が動作する。
【００３１】
印刷装置管理アプリケーションモジュール２１０は、予め別途に定められた方法に従って印刷装置１０１が代表プリンタであると決定されると、ネットワークに接続された同様の構成をもつ印刷装置１０１ａ、１０１ｂのステータス状態を管理する処理を行う。予め別途に定められた方法とは、操作部１０５を通じたユーザ操作による指示、自律的な決定アルゴリズム、或はネットワーク上の別途のプロトコルによる周辺装置とのネゴシエーションによる決定方法などが考えられる。
【００３２】
例えば、印刷装置１０１が予め別途に定められた方法により代表プリンタであると決定すると、接続されたネットワークに対して代表プリンタ状態となった事を通知する。ネットワークに接続された同様の構成をもつ各印刷装置１０１ａ、１０１ｂは、ネットワーク上にどの装置が代表プリンタであるかを検知すると、代表プリンタに対して自身のステータス情報を別途の手段により適宜送信するよう構成されている。代表プリンタは、受信したステータス情報を収集し、その分析結果を各装置ごと、或は、まとめてＷｅｂページあるいは別途の手段によりユーザに提示する。印刷装置管理アプリケーションモジュール２１０は、このような代表プリンタとしての処理およびステータス情報を送信するクライアントとしての処理を司っている。
【００３３】
この実施例では、このネットワーク上における代表プリンタ状態の通知あるいは検知処理に本発明の構成を採用している。
【００３４】
図３は、印刷装置管理アプリケーションモジュール２１０の機能構成を示すブロック図である。代表装置決定部３０２は、前述のように、予め別途に定められた操作部１０５を介したユーザ操作による指示により自身が代表プリンタであるかどうかを決定する。また、自律的な決定アルゴリズム、或はネットワーク上の別途のプロトコルによる周辺装置とのネゴシエーション等により自身が代表プリンタであるかを決定してもよい。自身が代表プリンタに決定した場合は、代表プリンタ用処理部３０３により処理を実行し、代表プリンタではない場合には、クライアント用処理部３０４により処理を実行する。
【００３５】
代表プリンタ用処理部３０３は、代表プリンタ処理部３０６、代表プリンタ用メタデータ生成・応答制御部３０７、ＵＵＩＤ置き換え指示部３０８、ネットワーク接続パケット制御部３０９、マルチキャストパケット応答制御部３１０により構成される。クライアント用処理部３０４は、クライアント処理部３１１、代表プリンタメタデータ解析部３１２、受信ＵＵＩＤ指示部３１３、代表プリンタメタデータ取得指示部３１４、ネットワーク接続パケット受信制御部３１５により構成される。また、代表プリンタ用処理部３０３とクライアント用処理部３０４に共通にＵＵＩＤ生成部３０５がある。
【００３６】
図４はＷＳＤプロトコルを採用した印刷装置管理アプリケーションモジュール２１０の動作概要を示すフローチャートである。
【００３７】
まず、ステップＳ４０１代表プリンタ決定部３０２は、ユーザから受付た指示に従って自分自身が代表プリンタであるかどうかを決定する。ここで、代表プリンタに決定されると、処理はステップＳ４０２に進み、代表プリンタ用処理部３０３は、ネットワーク接続パケット制御部３０９により、Ｂｙｅマルチキャストパケットをネットワーク上に送出する。この処理により、ネットワーク上から従来の処理を行っていた印刷装置が離脱する。
【００３８】
次に、ステップＳ４０３ではＵＵＩＤ生成部３０５により、予め定めた手順に従って代表プリンタである事を示すＵＵＩＤを生成する。ＵＵＩＤとは、重複しないとされる汎用一意識別子の名称であり、Ｕｎｉｖｅｒｓａｌｌｙ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｉｅｒ  の略である。以下 ＵＵＩＤと表記する。続いて、ステップＳ４０４では代表プリンタ用メタデータ生成・応答制御部３０７により、メタデータ問い合わせに応答する代表プリンタ用のメタデータを予め生成する。また、ＵＵＩＤ置き換え指示部３０８は、ステップＳ４０３で生成したＵＵＩＤを含むネットワーク接続メッセージであるＨｅｌｌｏマルチキャストパケットを生成する。マルチキャストパケットとは、１台のコンピュータから複数のコンピュータに向けて、同じＩＰパケットを同時に届ける通信方式のことを言う。そして、ステップＳ４０５ではネットワーク接続パケット制御部３０９により、生成したＨｅｌｌｏマルチキャストパケットをネットワーク上に送出する。この処理により、ネットワーク上に代表プリンタのＵＵＩＤを持つ印刷処理装置が接続された事になる。
【００３９】
その後、ステップＳ４０６では、ネットワークに接続された各装置からメタデータ問い合わせが行われるため、それに備えて代表プリンタ用メタデータ生成・応答制御部３０７は、メタデータ取得要求待ち状態となる。ここで、代表プリンタ用メタデータ生成・応答制御部３０７がメタデータ取得要求を受信すると、処理はステップＳ４０７に進み、ステップＳ４０４で生成した代表プリンタ用のメタデータを応答する。
【００４０】
以上のように、この実施例の印刷装置が代表プリンタとして動作する際には、標準プロトコルに定められたマルチキャストパケットのみを用いて代表プリンタとして動作している事を通知する。なお、この実施例では、ユーザの指示により代表プリンタとして動作する事が決定しているが、別のアルゴリズム等により印刷装置自身が自律的に決定しても良い。
【００４１】
さて、ステップＳ４０１で、代表プリンタ決定部３０２により自身が自分代表プリンタでないと決定されたなら、処理はステップＳ４０８に進み、クライアント用処理部３０４の処理を実行する。クライアント用処理部３０４では、予め定めた手法により代表プリンタである事を示すＵＵＩＤをＵＵＩＤ生成部３０５により生成する。ここで生成されるＵＵＩＤは、ステップＳ４０３で生成されるＵＵＩＤと同一のものである。ステップＳ４０９では、受信ＵＵＩＤ指示部３１３は、生成されたＵＵＩＤを含むネットワーク接続メッセージであるＨｅｌｌｏ待ちキャストパケットを受信するようにネットワーク接続パケット受信制御部３１５に対して指示する。
【００４２】
ステップＳ４１０において、ネットワーク接続パケット受信制御部３１５は、Ｈｅｌｌｏパケットを受信すると、処理はステップＳ４１３に進み、パケットに含まれているＵＵＩＤが指示された代表プリンタを示すＵＵＩＤに一致するかどうかを調べる。ここで、Ｈｅｌｌｏパケットに含まれているＵＵＩＤが代表プリンタを示すＵＵＩＤと一致している場合、処理はステップＳ４１４に進み、代表プリンタメタデータ取得指示部３１４により、代表プリンタに対してメタデータ取得要求を送信する。そして、代表プリンタのメタデータを取得し、代表プリンタメタデータ解析部３１２によりメタデータを解析し、後続のステータスデータ送信処理（不図示）に備える。ステップＳ４１０で、Ｈｅｌｌｏパケットの受信がない場合、処理はステップＳ４１１に進み、ネットワーク接続パケット受信制御部３１５はネットワークに負荷をかけない範囲で、定期的にネットワーク探索パケットであるＰｒｏｂｅパケットを送出する。そして、ステップＳ４１２において、ネットワーク接続パケット受信制御部３１５がＰｒｏｂｅパケットに対する応答であるＰｒｏｂｅＭａｔｃｈｅｓ  ＵＤＰパケットを受信したかどうかを調べる。ここで、ＰｒｏｂｅＭａｔｃｈｅｓ  ＵＤＰパケットを受信した場合は、処理はステップＳ４１３に進み、Ｈｅｌｌｏパケットを受信した際の処理と同様の処理を行う。これに対して、ＰｒｏｂｅＭａｔｃｈｅｓ  ＵＤＰパケットを受信していない場合には、処理はステップＳ４１０に戻り、Ｈｅｌｌｏパケットの受信があるかどうかを調べる。
【００４３】
以上のように、この実施例に従う印刷装置は、クライアントとして動作する場合に、マルチキャストパケット受信あるいはマルチキャストパケット送信に対する応答ＵＤＰパケットのみを用いて代表プリンタの存在を検出する事ができる。また、必要な場合にのみ代表プリンタとメタデータ送受信を行う。このように、この印刷装置がクライアントとして動作する場合には、代表プリンタからのＨｅｌｌｏパケットを取得した場合に限り、メタデータを取得する。
【００４４】
次に、ネットワークに印刷装置２台とＰＣ１台とが接続され、１台の印刷装置が代表プリンタとして動作する場合のネットワーク上のデータ送受信について説明する。
【００４５】
図５は、印刷装置２台とＰＣ１台とによるネットワークを介したデータ送受信の様子を示す図である。ここでは、印刷装置Ａがユーザにより代表プリンタである事を指示され、印刷装置Ｂがクライアント装置であるとして説明する。
【００４６】
図５によれば、印刷装置ＡはステップＳ４０２に示したＢｙｅマルチキャストパケットを送出する（５０１）。続いて、印刷装置ＡがステップＳ４０５に示した代表プリンタのＵＵＩＤを持つＨｅｌｌｏマルチキャストパケットを送出する（５０２）。これに対して、印刷装置Ｂは、ステップＳ４１０に示したように代表プリンタのＵＵＩＤを持つＨｅｌｌｏマルチキャストパケットを受信すると、ステップＳ４１４に示したようにメタデータ取得要求を印刷装置Ａに対して送信する（５０３）。印刷装置Ａは、印刷装置Ｂからのメタデータ取得要求に対して、ステップＳ４０４で作成した代表プリンタ用メタデータをステップＳ４０７に示したように応答する（５０４）。
【００４７】
一方、ＰＣは、Ｈｅｌｌｏマルチキャストパケットを受信すると、それが代表プリンタのＵＵＩＤを持つかどうかにかかわらず、標準に定めた手順によりメタデータ取得要求を印刷装置Ａに対して送信する（５０５）。印刷装置Ａは、ＰＣからのメタデータ取得要求に対して、ステップＳ４０４で作成した代表プリンタ用メタデータをステップＳ４０７に示したように応答する（５０６）。このように、ＰＣであれば、標準に定めた手順により代表プリンタのメタデータを自動的に取得する事ができる。
【００４８】
また、印刷装置ＢはＨｅｌｌｏパケットを受信できなかった場合、ステップＳ４１１に示したように定期的にＰｒｏｂｅマルチキャストパケットを送出する（５０７）。印刷装置Ａは、Ｐｒｏｂｅマルチキャストパケットを受信すると、不図示の手順に従って、ステップＳ４０３で作成したＵＵＩＤを持つＰｒｏｂｅＭａｔｃｈｅｓ  ＵＤＰパケットを応答する（５０８）。印刷装置Ｂは、ステップＳ４１２に示したように代表プリンタのＵＵＩＤを持つＰｒｏｂｅＭａｔｃｈｅｓ  ＵＤＰパケットを受信すると、ステップＳ４１４に示したようにメタデータの取得要求を印刷装置Ａに対して送信する（５０９）。印刷装置Ａは、印刷装置Ｂからのメタデータ取得要求に対して、ステップＳ４０４で作成した代表プリンタ用メタデータをステップＳ４０７に示したように応答する（５１０）。
【００４９】
さて、ＰＣがリフレッシュ動作等によりＰｒｏｂｅマルチキャストパケットを送出する場合も有る。この場合は、印刷装置Ａは代表プリンタのＵＵＩＤを持つＰｒｏｂｅＭａｔｃｈｅｓ  ＵＤＰパケットを応答するが、ＰＣ側は、標準に定めた手順によりメタデータの取得要求を印刷装置Ａに対して送信する。このようにＰＣであれば、リフレッシュ動作時等でも標準に定めた手順により代表プリンタのメタデータを自動的に取得する事ができる。
【００５０】
以下、図６〜図８を参照して代表プリンタのＵＵＩＤを持つマルチキャストパケットを生成する方法について説明する。
【００５１】
図６は印刷装置がクライアント或は代表プリンタとして動作する際に発行するＨｅｌｌｏマルチキャストパケットの例を示す図である。
【００５２】
図６（ａ）は印刷装置がクライアントとして動作する場合に発行するＨｅｌｌｏマルチキャストパケットの例を示しており、そのパケットに含まれている印刷装置を示す識別子であるＵＵＩＤは枠線で囲っている。この例では、ＵＵＩＤの下１２桁部分に、装置のネットワークコントローラの持つＭＡＣアドレスを入れたＵＵＩＤが用いられている（文字列“000085123456”）。
【００５３】
図６（ｂ）は印刷装置が代表プリンタとなった際に発行するＨｅｌｌｏマルチキャストパケットの例を示しており、そのパケットに含まれている代表プリンタである事を示す識別子であるＵＵＩＤは枠線で囲っている。この例では、ＵＵＩＤの下１２桁部分に、装置が代表プリンタである事を示す文字列として“000085000001”を使用している。
【００５４】
代表プリンタを示す文字列“000085000001”は、ＵＵＩＤ生成部３０５により生成される文字列であり、代表プリンタとなる印刷装置とクライアントとなる印刷装置の双方で共通に認識される文字列である。なお、この例では、予め決められた文字列を生成しているが、代表プリンタとクライアントとなる印刷装置の双方で共有する事ができれば、別途のアルゴリズム等により動的に生成した文字列でも構わない。
【００５５】
クライアントとして動作する印刷装置が、代表プリンタから送出された図６（ｂ）に示すＨｅｌｌｏパケットを受信すると、まず、その装置を示す識別子であるＵＵＩＤ（枠線で囲った部分）を取り出す。そのＵＵＩＤが、ＵＵＩＤ生成部３０５により予め生成された文字列“000085000001”を下１２桁部分に含むかどうかをステップＳ４１３で検査し、合致していれば、代表プリンタのメタデータの取得を行う。
【００５６】
図７は印刷装置がクライアント或は代表プリンタとして動作する際に応答するＰｒｏｂｅＭａｔｃｈｅｓパケットの例を示す図である。
【００５７】
図７（ａ）は印刷装置がクライアントとして動作する際にＰｒｏｂｅマルチキャストパケットに対して応答するＰｒｏｂｅＭａｔｃｈｅｓパケットの例を示しており、このパケットに含まれている印刷装置を示す識別子であるＵＵＩＤを枠線で囲っている。この例では、ＵＵＩＤの下１２桁部分に、装置のネットワークコントローラの持つＭＡＣアドレスを入れたＵＵＩＤが用いられている（文字列“000085123456”）。従って、例えば、ＰＣ１１０がＰｒｏｂｅメッセージをクライアントとして動作する印刷装置に送信すれば、その応答からＰＣ１１０は印刷装置はクライアントとして動作していることを知る。
【００５８】
図７（ｂ）は印刷装置が代表プリンタとなった際に応答するＰｒｏｂｅＭａｔｃｈｅｓパケットの例を示しており、このパケットに含まれている代表プリンタである事を示す識別子であるＵＵＩＤを枠線で囲っている。この例では、ＵＵＩＤの下１２桁部分に装置が代表プリンタである事を示す文字列として“000085000001”を使用している。この代表プリンタを示す文字列“000085000001”はＵＵＩＤ生成部３０３により生成される文字列であり、図６（ｂ）に示したＨｅｌｌｏマルチキャストパケットに含まれる文字列と同一の文字列である。
【００５９】
クライアントとして動作する印刷装置が、代表プリンタからの応答である図７（ｂ）で示すＰｒｏｂｅＭａｔｃｈｅｓパケットを受信すると、まず、その装置を示す識別子であるＵＵＩＤ（枠線で囲った部分）を取り出す。そのＵＵＩＤが、ＵＵＩＤ生成部３０５により予め生成されている文字列“000085000001”を下１２桁部分に含むかどうかをステップＳ４１３で検査し、合致していれば、代表プリンタのメタデータの取得を行う。
【００６０】
図８は印刷装置がクライアント或は代表プリンタとして動作する際にメタデータ取得要求に対して応答するメタデータの例を示す図である。
【００６１】
図８（ａ）に示されているように、この印刷装置がクライアントとして動作する場合、ＰＣがこの印刷装置を発見した際に表示される名称がＡ０１に代入されている。また、この印刷装置の情報をＷｅｂページ形式で閲覧可能とするＵＲＬ情報がＡ０２に代入されており、この印刷装置に対する制御コマンドを送信するためのアクセスポイント情報がＡ０３に代入されている。
【００６２】
図８（ｂ）に示されているように、この印刷装置が代表プリンタとして動作する場合、ＰＣがこの印刷装置を発見した際に表示される名称がＢ０１に代入されている。Ｂ０１において、Ａ０１と比較して変更部分は網がけされ、Ｂ０１では、印刷装置を示す名称が代表プリンタを示す名称“XXX Series_Master”に置換されている。また、この印刷装置の情報をＷｅｂページ形式で閲覧可能とするＵＲＬ情報がＢ０２に代入されている。Ｂ０２において、Ａ０２と比較して変更部分は網がけされ、Ｂ０２では、代表プリンタ専用のホームページを示すＵＲＬアドレスとなっている。さらに、この印刷装置に対する制御コマンドを送信するためのアクセスポイント情報がＢ０３に代入されている。Ｂ０３において、Ａ０３と比較して変更部分は網がけされ、Ｂ０３では代表プリンタ専用の制御コマンドをやり取りするためのＣＧＩアクセスポイントを示すＵＲＬアドレスとなっている。
【００６３】
クライアントとして動作する印刷装置は、代表プリンタから図８（ｂ）に示すメタデータ応答を受信すると、Ｂ０３のＣＧＩアクセスポイント情報を取り出す。そして、別途定められた手段に従って代表プリンタとデータの送受信を行う。このＣＧＩアクセスポイントで送受信するデータは、標準プロトコルに定められたコマンドあるいはデータであっても良い。また、代表プリンタ用に定めた独自のプロトコルに従ったコマンドあるいはデータでも良い。
【００６４】
一方、ＰＣが、代表プリンタから図８（ｂ）に示すメタデータ応答を受信すると、Ｂ０１から代表プリンタの名称を取り出す。そして、ユーザに対して取り出した名称をアイコン名称として表示する。また、ＰＣはＢ０２から代表プリンタのＷｅｂページのＵＲＬ情報を取り出す。そして、ＰＣはユーザに対してこのＵＲＬ情報を提示する。ユーザは代表プリンタの情報をＷｅｂページ経由で容易に閲覧可能となる。このように、ＰＣのユーザにとっても代表プリンタの存在が容易に判別可能であり、容易に代表プリンタにアクセスする事が可能な構成となっている。
【００６５】
図９は印刷装置がクライアントとして動作している状態から代表プリンタとして動作するように移行した場合に、ＰＣ上で印刷装置を表すアイコン表示状態がどのように変化するのかの例を示す図である。
【００６６】
印刷装置がクライアントとして動作している状態では、図９（Ａ）あるいは（Ｂ）の左側のアイコンがＰＣに表示される。この状態での印刷装置の名称は、図８（ａ）のＡ０１に代入された“XXX series_123456”が表示される。印刷装置が代表プリンタとなると、図８（ｂ）に示すメタデータを取得すると同時にＢ０１に代入されている“XXX series_Master”という名称へと変更となり、図９（Ａ）の右側のアイコンのように表示される。
【００６７】
ここで、ＵＰｎＰプロトコル（不図示）に従うメタデータ問い合わせがあった場合、その応答メタデータにＵＰｎＰプロトコル標準仕様に定められた方式で代表プリンタ（不図示）を示すアイコンデータを付加する構成としても良い。この場合、ＰＣ側の表示は図９（Ｂ）の右側のアイコンのようにデフォルト状態から付加したアイコンデータに従うアイコンへと変わって表示される。
【００６８】
従って以上説明した実施例に従えば、印刷装置は標準仕様に定められたマルチキャストパケットを拡張する事なく、代表プリンタという状態に変化したことをネットワークに接続された各装置に通知する事ができる。また、クライアントとして動作する場合にも、標準仕様に定められたマルチキャストパケット受信あるいはマルチキャストパケット送信に対する応答ＵＤＰパケットのみを用いて代表プリンタの存在を検出することができる。そして、必要な場合にのみ代表プリンタとメタデータ送受信を行うため、不要なネットワークトラフィックを発生させないという利点がある。
【００６９】
＜他の実施例＞
図１０は他の実施例に従うパーソナルコンピュータ（ＰＣ）のハードウェア構成の概略を示す図である。図１０に示すように、ＰＣ４０１は、ＣＰＵ４０２、ＲＯＭ４０３、ＲＡＭ４０４、操作部４０５、ネットワークコントローラ４０６、表示部４０７を備えている。ＰＣ４０１はネットワークコントローラ４０６を介してネットワークに接続されており、ネットワークに接続された複数の機器（図１０では、ＰＣ）と通信可能なように構成されている。図１０に示す構成では、ネットワーク上に、ＰＣ４０１と同様の構成をもつ５台のＰＣ４０１ａ〜４０１ｅが接続されている。なお、ネットワークはこの実施例ではＥｔｈｅｒｎｅｔ（登録商標）ＬＡＮを用いているが、他のＬＡＮ、例えば、無線ＬＡＮでも良い。
【００７０】
図１１はＷＳＤプロトコルを採用したＰＣ４０１がどのように動作するかを説明するフローチャートである。
【００７１】
まず、ステップＳ６０１では、ＰＣ４０１はユーザ指示に基づいて自分自身がプライマリサーバであるかどうかを決定する。ここで、ＰＣ自身がプライマリサーバであると決定すると、処理はステップＳ６０２に進み、Ｂｙｅマルチキャストパケットをネットワーク上に送出する。この処理により、ネットワーク上から従来の処理を行っていたＰＣが離脱する。そして、ステップＳ６０３では予め定めた手順に従ってプライマリサーバである事を示すＵＵＩＤを生成する。
【００７２】
これに対し、ＰＣ自身がプライマリサーバではない場合、処理はステップＳ６０８に進んで、ＰＣ自分自身がセカンダリサーバであるかどうかを決定する。ここで、ＰＣ自身がセカンダリサーバであると決定した場合は、処理はステップＳ６０９に進み、ステップＳ６０２と同様にＢｙｅマルチキャストパケットをネットワーク上に送出する。その後、ステップＳ６１０では、予め定めた手順に従ってセカンダリサーバである事を示すＵＵＩＤを生成する。
【００７３】
ステップＳ６０３或はＳ６１０によりＵＵＩＤを生成した後、ステップＳ６０４ではメタデータ問い合わせ応答用のサーバとしてのメタデータを予め生成する。そして、ステップＳ６０３或はステップＳ６１０で生成したＵＵＩＤを含むネットワーク接続メッセージであるＨｅｌｌｏマルチキャストパケットを生成する。そして、ステップＳ６０５では生成したＨｅｌｌｏマルチキャストパケットをネットワーク上に送出する。
【００７４】
以上の処理により、ネットワーク上にプライマリサーバ或はセカンダリサーバのＵＵＩＤを持つＰＣが接続されたことになる。
【００７５】
Ｈｅｌｌｏパケットをネットワークに送出すると、処理はステップＳ６０６において、ネットワークに接続された各ＰＣからメタデータ問い合わせが行われるため、それに備えてメタデータ取得要求待ち状態となる。メタデータ取得要求を受信すると、処理はステップＳ６０７に進み、ステップＳ６０４で生成したサーバ用のメタデータを応答する。
【００７６】
以上のように、この実施例に従うＰＣは、プライマリサーバ或はセカンダリサーバとして動作する時に、マルチキャストパケットのみを用いて自身がサーバとして動作していることを通知する。なお、この実施例においては、ユーザ指示に基づいてそのＰＣがプライマリサーバ或はセカンダリサーバとして動作することが決定しているが、別途のアルゴリズム等によりＰＣ自身が自律的に決定しても良い。
【００７７】
さて、ステップＳ６０１とＳ６０８の処理で、ＰＣ４０１がプライマリサーバでもセカンダリサーバでもないことが識別された場合（即ち、ＰＣはクライアントである場合）、処理はステップＳ６１１に進む。そして、ステップＳ６１１とＳ６１２夫々において、予め定めた方法によりプライマリサーバであることを示すＵＵＩＤ、及びセカンダリサーバであることを示すＵＵＩＤを生成する。さらに、ステップＳ６１３では、生成したＵＵＩＤを含むネットワーク接続メッセージであるＨｅｌｌｏ待ちキャストパケットを受信するようプロトコルに設定する。
【００７８】
次に、ステップＳ６１４では、Ｈｅｌｌｏパケットを受信しているかどうかを調べる。ここで、Ｈｅｌｌｏパケットを受信すると、処理はステップＳ６１７に進み、そのパケットに含まれているＵＵＩＤがプライマリサーバのＵＵＩＤに一致するかどうかを調べる。ここで、Ｈｅｌｌｏパケットに含まれているＵＵＩＤがプライマリサーバのＵＵＩＤと一致している場合、処理はステップＳ６１８に進み、マスタサーバに対してメタデータ取得要求を送信する。そして、マスタサーバのメタデータを取得すると、メタデータを解析し、後続のサーバとのデータ送受信処理（不図示）に備える。
【００７９】
これに対して、Ｈｅｌｌｏパケットに含まれているＵＵＩＤがプライマリサーバのＵＵＩＤとは一致しない場合、処理はステップＳ６１９に進んで、セカンダリサーバのＵＵＩＤと一致するかどうかを調べる。ここで、セカンダリサーバのＵＵＩＤと一致している場合、処理はステップＳ６２０に進んで、セカンダリサーバに対してメタデータ取得要求を送信して、セカンダリサーバのメタデータを取得する。これに対して、Ｈｅｌｌｏパケットに含まれているＵＵＩＤがセカンダリサーバのＵＵＩＤとも一致しない場合、処理はステップＳ６１４に戻ってＨｅｌｌｏパケットの受信を待ち合わせる。
【００８０】
このように、この実施例に従うＰＣは、プライマリサーバが存在すればプライマリサーバにアクセスし、プライマリサーバが不在時にセカンダリサーバにアクセスする。
【００８１】
さて、ステップＳ６１４でＨｅｌｌｏパケットを受信していない場合、処理はステップＳ６１５に進み、定期的にＰｒｏｂｅパケットを送出する。そして、ステップＳ６１６では送出したＰｒｏｂｅパケットに対する応答であるＰｒｏｂｅＭａｔｃｈｅｓパケットを受信したかどうかを調べる。ここで、ＰｒｏｂｅＭａｔｃｈｅｓパケットを受信した場合は、処理はステップＳ６１７に進み、Ｈｅｌｌｏパケットを受信した際の処理と同様の処理を行う。
【００８２】
以上のように、この実施例に従うＰＣはクライアントとして動作する時にマルチキャストパケット受信あるいはマルチキャストパケット問い合わせに対する応答ＵＤＰパケットのみを用いて、サーバの存在検出および区別をする事が可能なように構成されている。
【００８３】
以下、図１２を参照してＰＣがプライマリサーバ或はセカンダリサーバのＵＵＩＤを持つマルチキャストパケットを生成する方法について説明する。
【００８４】
図１２はＰＣが３つの異なる動作をする場合に発行されるＨｅｌｌｏマルチキャストパケットの例を示す図である。
【００８５】
図１２（Ａ）はＰＣがクライアントとして動作する際に発行している通常のＨｅｌｌｏマルチキャストパケットの例を示しており、このパケットに含まれているＰＣを示す識別子であるＵＵＩＤは枠線で囲っている。この例では、ＵＵＩＤの下１２桁部分に、装置のネットワークコントローラの持つＭＡＣアドレスを入れたＵＵＩＤが用いられている（文字列“000085123456”）。
【００８６】
図１２（Ｂ）はＰＣがプライマリサーバとなった際に発行するＨｅｌｌｏマルチキャストパケットの例を示しており、このパケットに含まれているプライマリサーバであることを示す識別子であるＵＵＩＤは枠線で囲っている。この例では、ＵＵＩＤの下１２桁部分にＰＣがプライマリサーバである事を示す文字列として“000085000001”を用いている。プライマリサーバを示す文字列“000085000001”は、プライマリサーバとなるＰＣとクライアントとなるＰＣの双方で共通に認識される文字列である。
【００８７】
図１２（Ｃ）はＰＣがセカンダリサーバとなった際に発行するＨｅｌｌｏマルチキャストパケットの例を示しており、このパケットに含まれているセカンダリサーバであることを示す識別子であるＵＵＩＤは枠線で囲っている。この例では、ＵＵＩＤの下１２桁部分にＰＣがセカンダリサーバである事を示す文字列として“000085000002”を用いている。セカンダリサーバを示す文字列“000085000002”は、セカンダリサーバとなるＰＣとクライアントとなるＰＣの双方で共通に認識される文字列である。
【００８８】
なお、この実施例では、予め決められた文字列として“000085000001”と“000085000002”という文字列とを生成している。しかしながら、プライマリサーバ或はセカンダリサーバとなるＰＣと、クライアントとなるＰＣの双方で共有する事ができれば、別のアルゴリズムにより動的にこれらの文字列を生成しても構わない。
【００８９】
従って以上説明した実施例に従えば、ＰＣはサーバとして動作する際にその動作状態を標準仕様に定められたマルチキャストパケットを拡張する事なく通知することができる。また、クライアントとして動作する場合にも、標準仕様に定められたマルチキャストパケット受信あるいはマルチキャストパケット送信に対する応答ＵＤＰパケットのみを用いてサーバの動作状態を区別する事が可能なように構成されている。
【図１】
0005563246.tif 000002
【図２】
0005563246.tif 000003
【図３】
0005563246.tif 000004
【図４】
0005563246.tif 000005
【図５】
0005563246.tif 000006
【図６】
0005563246.tif 000007
【図７】
0005563246.tif 000008
【図８】
0005563246.tif 000009
【図９】
0005563246.tif 000010
【図１０】
0005563246.tif 000011
【図１１】
0005563246.tif 000012
【図１２】
0005563246.tif 000013