JP4603737B2 - 通信装置及びネットワーク装置の管理方法、並びにプログラム及び記憶媒体 - Google Patents
通信装置及びネットワーク装置の管理方法、並びにプログラム及び記憶媒体 Download PDFInfo
- Publication number
- JP4603737B2 JP4603737B2 JP2001278759A JP2001278759A JP4603737B2 JP 4603737 B2 JP4603737 B2 JP 4603737B2 JP 2001278759 A JP2001278759 A JP 2001278759A JP 2001278759 A JP2001278759 A JP 2001278759A JP 4603737 B2 JP4603737 B2 JP 4603737B2
- Authority
- JP
- Japan
- Prior art keywords
- directory
- network
- information
- directory server
- network device
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
- H04N1/00127—Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture
- H04N1/00204—Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture with a digital computer or a digital computer system, e.g. an internet server
- H04N1/00236—Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture with a digital computer or a digital computer system, e.g. an internet server using an image reading or reproducing device, e.g. a facsimile reader or printer, as a local input to or local output from a computer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
- H04L41/0809—Plug-and-play configuration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
- H04L41/0856—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information by backing up or archiving configuration information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
- H04N1/32—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
- H04N1/32502—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device in systems having a plurality of input or output devices
- H04N1/32523—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device in systems having a plurality of input or output devices a plurality of output devices
- H04N1/32529—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device in systems having a plurality of input or output devices a plurality of output devices of different type, e.g. internal and external devices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
- H04N1/32—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
- H04N1/32502—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device in systems having a plurality of input or output devices
- H04N1/32523—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device in systems having a plurality of input or output devices a plurality of output devices
- H04N1/32539—Detecting or indicating the status of the output devices
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
［発明の分野］
本発明は、ネットワーク化企業の各装置を監視・管理するディレクトリ使用可能サーバの使用に関し、特に、ディレクトリ使用可能サーバネットワーク管理方法にレガシー装置を組み込むためのレガシー装置を検出し且つレガシー装置とインタフェースするＬＤＡＰディレクトリプロキシの使用に関する。
【０００２】
［関連技術の説明］
通常、コンピューティングネットワーク環境は、ワークステーション及びサーバなどの多数の計算機装置と、プリンタ及びスキャナなどのその他のネットワーク装置とから構成される。ネットワークで接続された環境において、これらの多数の計算機装置及びネットワーク装置の保守及び管理を行なうには、ネットワーク管理者は非常に多くの時間及び労力を必要とする。例えば、ネットワーク管理者は、通常、サーバのドメイン名及びネットワーク装置に対応するＩＰ（インターネットプロトコル）アドレスなどの適切なネットワーク情報を設定することによって、各ネットワーク装置をネットワークに統合するように構成する。また、ネットワーク管理者は、各ネットワーク装置の機能及びネットワークで接続された環境において各ネットワーク装置に求められる機能性に従って、各ネットワーク装置を構成する。
【０００３】
自動的にローカルな周辺装置を認識・構成することができるプラグ＆プレイ機能を備えたオペレーティングシステムを有する単純なパソコンとは異なり、ネットワークで接続された環境では、ネットワーク管理者は、通常、ネットワークに新規の装置が追加される度に、接続・構成を手動で行なう必要がある。また、新規のネットワーク装置が接続されたり、既存のネットワーク装置がネットワーク内で移動させられたりするため、ネットワーク構成は頻繁に変更される可能性がある。更に、ネットワークのユーザの要望に応じて、あるネットワーク装置のネットワークアクセス可能な機能性を変更するために、ネットワーク管理者は、そのネットワーク装置を再構成する必要が生じるかもしれない。例えば、ソートは時間のかかる処理であるので、プリンタがオフィスの多忙な区域に設置されている場合、ネットワーク管理者によりネットワークプリンタのソート機能が、最初から無効にされていることもある。その後、プリンタがソートを必要とするオフィスのそれほど多忙でない場所に移された場合、ネットワーク管理者は、ソート機能をサポートするためにそのネットワークプリンタを再構成（reconfigure）する必要が生じるであろう。また、ネットワークプリンタに封筒用のフィーダを設置する場合など、ネットワーク装置に新しいオプションが設置される場合にも、ネットワーク装置は再構成される。従って、ネットワーク上のネットワーク装置の台数が増加するにつれて、ネットワーク管理者が、そのネットワーク上の各ネットワーク装置の構成・保守に要する労力のレベルが飛躍的に上昇することは、理解できよう。
【０００４】
ネットワーク管理者による各ネットワーク装置の管理は、そのネットワーク装置の設置場所でローカルに行われることが多い。従来の管理技法の１つでは、ネットワーク管理者は、フロントパネル及び／又はキーパッドなどのネットワーク装置のユーザインタフェースからそのネットワーク装置のネットワーク設定及び機能を入力及び／又は選択する。別の周知の管理技法では、ネットワーク管理者は、ネットワーク装置に対するネットワーク設定及び機能を入力・選択するために、特定のネットワーク装置に対してリモートアクセスを行なう標準化されたネットワーク管理ツールを使用する。例えば、ネットワーク管理者は、ネットワークプリンタのＩＰアドレス、あるいは、ソートなどの機能オプションの１つを変更するために、集中型ＳＮＭＰツールを使用してＳＮＭＰプロトコルを介してネットワークプリンタへのリモートアクセスを行なっても良い。
【０００５】
ネットワーク管理者が、ネットワーク装置に対して、その設定及び機能をローカルで入力するか、あるいは、リモートで入力するかに関わらず、ネットワーク装置の選択された設定及び機能は、通常、ネットワーク管理者がネットワークサーバのネットワーク構成ファイルなどの集中化したネットワーク位置に入力し、ネットワーク上の他のネットワーク装置によるアクセスを可能とするために、このネットワーク設定及び機能は公表される。
【０００６】
このようにして、他のネットワーク装置は、各特定のネットワーク装置が有する共有のネットワーク機能性を認識し、利用することができる。言うまでもなく、ネットワーク装置の構成された設定及び機能が、ネットワーク装置の公表された設定及び機能に実際に対応しない場合、問題が生じるのは理解されるだろう。あるネットワーク装置の公表されたＩＰアドレスが、そのネットワーク装置に設定された実際のＩＰアドレスと一致しない場合、他のネットワーク装置は、ネットワークを介してそのネットワーク装置にアクセスしたり、装置を利用したりすることができない。
【０００７】
また、ワークステーションのユーザは、ネットワークプリンタが実際は標準のレターサイズの用紙での印刷のみをサポートする場合に、ネットワークプリンタの公表された機能からプリンタがリーガルサイズの用紙での印刷をサポートすることを読み取り、リーガルサイズの用紙を必要とする印刷ジョブのネットワークプリンタへの送信を試みる可能性がある。従って、各ネットワーク装置を構成し且つ集中化したネットワーク位置に各ネットワーク装置の構成された設定及び機能を入力する詳細且つ重複的なネットワーク管理タスクは、膨大なものとなる可能性があり、結果として、集中化したネットワーク位置のデータと対応するネットワーク装置の実際の構成との間で同期化エラーが生じる可能性がある。このような不一致の生じる頻度は、ネットワーク上にネットワーク装置が多数存在する場合、飛躍的に増加することは理解できよう。
【０００８】
前述の管理上の問題に対する１つの解決法は、ネットワーク化企業（network enterprize）でのネットワーク装置の保守・管理を行なうためにディレクトリサーバを使用する最近の傾向に表れている。このようなディレクトリ使用可能管理ツール(directory-enabled management tool)は、ネットワーク化企業の各ネットワーク装置に対応する選択されたネットワーク設定及び機能を記憶・保守するための集中化したネットワーク位置に対するディレクトリ構造を使用する。個々の登録又は登録事項（エントリ）は、各ネットワーク装置に関連する前述の情報を含むために、ディレクトリ構造内に設けられる。エントリは、階層方式のディレクトリ構造において編成され、このディレクトリ構造は、各種のネットワーク装置に対して個別の枝を有する。例えば、ディレクトリ構造は、ネットワークプリンタに対する枝（branch）、ネットワークコンピュータに対する枝及びその他の種類のネットワーク装置に対する枝を有し、ネットワークプリンタに対する枝は、インクジェットプリンタに対する下位枝、レーザプリンタに対する下位枝及びドットマトリックスプリンタに対する下位枝を有する。インクジェットプリンタに対する下位枝は、ネットワーク上のインクジェットプリンタの各々に対応する選択された設定及び機能を記憶するための複数のエントリを有する。
【０００９】
標準化された構成又は体系（スキーマ）を使用してディレクトリ構造内の各エントリに対する形式を定義し、それにより、各ネットワーク装置のネットワーク設定及び機能を含むための一定の形式を提供するのが好ましい。このようにして、ディレクトリ使用可能サーバ上に常駐するディレクトリ構造は、他の全てのネットワーク装置によるアクセスを可能とするために、各ネットワーク装置のネットワーク設定及び機能が公表される集中化された位置を提供する。このようなディレクトリ使用可能サーバへのアクセスは、通常、ディレクトリ構造に／から入出力される情報を効率的に公表・検索するためのある種類の標準化されたディレクトリプロトコルを介して実現される。このようなプロトコルの例として、Ｘ．５００ディレクトリアクセスプロトコル及びそれに関連する軽量プロトコルであるＬＤＡＰ（Lightweight Directory Access Protocol）がある。ネットワーク化企業におけるネットワーク装置の保守・管理を行なうためにこのようなディレクトリ使用可能サーバを使用する場合、ネットワーク管理者などのユーザが、ディレクトリ使用可能サーバのディレクトリ構造における情報をアクセス・修正するためのインタフェースを提供するディレクトリ使用可能管理ツールと結合させると、非常に効率の良いネットワーク管理方法を提供することができる。ＬＤＡＰは、通常、生成するネットワークトラフィックがＸ．５００よりも少ないので、このようなディレクトリ使用可能管理方法は、ディレクトリ使用可能サーバでの通信プロトコルとして、Ｘ．５００よりもＬＤＡＰを使用するのが好ましい。
【００１０】
ディレクトリ使用可能ネットワーク管理方法を使用することにより、ネットワーク化企業の全てのネットワーク装置のネットワーク管理に必要な時間を大幅に削減し、複雑な管理を大幅に単純化することができる。例えば、ディレクトリ使用可能管理ツールは、ディレクトリ使用可能サーバのディレクトリ構造内のエントリを大規模に管理・変更するために、複雑な問い合わせ、バッチモード処理及び汎用エントリ変更などの標準ディレクトリ機能を使用することができる。従って、ディレクトリ使用可能サーバを有するネットワーク化企業におけるネットワーク装置は、ディレクトリ使用可能管理ツールなどのディレクトリ使用可能クライアントを用いてディレクトリ使用可能サーバにアクセスすることによって、ネットワーク上のいずれの場所にあっても、集中的に管理・アクセスすることができる。
【００１１】
例えば、ネットワーク管理者は、インターネットを介して遠隔の場所からディレクトリ問い合わせ及び変更コマンドを通じて共通のグループのネットワーク装置へのアクセス及び変更を効率的に行なうことができる。このようなネットワーク管理機能は、大規模なネットワーク環境でのネットワーク管理の効率を大幅に高めることができることは理解されるだろう。また、ディレクトリ使用可能ネットワーク管理方法は、インターネットなどのより規模の大きいネットワーク化企業のネットワーク装置の機能の拡張を提供する。従って、大規模なネットワーク化企業が、各特定のネットワークのドメイン内でネットワーク化企業を管理するために、ネットワーク化企業全体を構成する種々のネットワーク間に分散する数台のディレクトリ使用可能サーバを有しても良いことは理解されるだろう。
【００１２】
ディレクトリ使用可能サーバをネットワーク管理のために使用する傾向は、ＤＭＴＦ（Desktop Management Task Force）、ＤＥＮ（Directory Enabled Network）イニシアチブ及びＣＩＭ（Common Information Model）イニシアチブの努力に反映されている。これらの努力は、ネットワーク上のネットワーク装置の管理を行なうためにディレクトリ構造を使用する幅広い構想及びディレクトリ使用可能サーバのデータ構造内でネットワーク上のネットワーク構成要素を表すための共通のデータ形式の作成に対して集中的に行われてきた。しかしながら、ＤＭＴＦ、ＤＥＮイニシアチブ及びＣＩＭイニシアチブは、ネットワーク化企業でネットワーク装置を管理するためのディレクトリ構造の実現に関連する諸問題の解決法を提供してはいない。具体的には、各ネットワーク装置に関連する情報のディレクトリ構造への入力及びディレクトリ構造での保守を行なう方法に関して、ネットワーク装置の管理のためのディレクトリ使用可能サーバの使用は、ネットワーク管理に対する従来のアプローチと同様の問題を提起する。ネットワーク管理者がディレクトリ構造内の各ネットワーク装置に関連する情報を入力・更新するのに必要な労力を軽減することが望ましい。従って、各ネットワーク装置に対応するディレクトリ構造へのエントリの効率的な公表を行なうためのメカニズムを提供するディレクトリ使用可能ネットワーク管理方法が必要である。
【００１３】
また、ネットワーク装置の実際のネットワーク設定及び機能とネットワーク装置に対応するデータ構造のエントリにおいて公表されるネットワーク設定及び機能との間に不一致が生じる場合、ディレクトリ使用可能ネットワーク管理方法の使用は問題を生じる。これらの不一致が生じるのは、ネットワーク装置のネットワーク設定及び機能に対する変更が、従来のＳＮＭＰネットワーク管理ツールを介して手動で行われるか、あるいは、ネットワーク管理者などのユーザによりディレクトリ構造中のエントリに対して直接行われるためである。従って、設定に対する変更が行なわれたか否かに関わらず、ディレクトリ構造のエントリにおいて公表されるネットワーク設定及び機能とネットワーク装置自体のネットワーク設定及び機能との確実な同期化を提供するディレクトリ使用可能管理方法の実現が必要とされる。
【００１４】
最後に、ディレクトリ使用可能ネットワーク管理方法の実現は、通常、ネットワーク化企業における全てのネットワーク装置が、ディレクトリ使用可能サーバをサポートするためにディレクトリ使用可能であることを想定する。この想定を正しいものとするためには、ディレクトリ使用可能管理機能をサポートする目的で、各ネットワーク装置は、ＬＤＡＰなどの選択されたディレクトリプロトコルを介して通信を行なう機能を有する必要があり、また、適切な論理を有する必要がある。このようなネットワーク管理方法は、ＬＤＡＰなどのディレクトリプロトコルを使用して通信する機能を持たず、このようなディレクトリ使用可能ネットワーク管理機能をサポートするために組み込まれる論理を持たないレガシーネットワーク装置を現在では多数使用することを考慮に入れていない。これらのレガシー装置が、今後とも長期にわたり使用されるものとすると、ディレクトリ使用可能ネットワーク管理方法にとって、ディレクトリ使用可能ネットワーク装置とレガシー装置の両方を含む混成異種ネットワーク化企業にこのレガシー装置を収容することが好ましい。従って、前述の諸問題を解決するディレクトリ使用可能ネットワーク管理方法が望まれる。
【００１５】
［発明の概要］
本発明は、レガシー装置が自動的に検出され、各レガシーネットワーク装置の設定及び機能に関連する情報がＳＮＭＰなどのレガシープロトコルを使用することで得られるディレクトリ使用可能ネットワーク管理方法を提供することにより前述の問題に対処する。各レガシーネットワーク装置に対応する１組の情報は、データエントリにフォーマット化され、このデータエントリは、ＬＤＡＰなどのディレクトリ通信プロトコルを介してディレクトリサーバに転送される。本発明のディレクトリ使用可能ネットワーク管理方法は、ネットワーク装置とこれに対応するディレクトリエントリの両方における変更を監視することによって、各ネットワーク装置の設定及び機能とディレクトリサーバの対応するエントリとの同期化を実現する。このようにして、ネットワーク管理者がネットワーク装置を管理する際に要求される労力を軽減し、ディレクトリ使用可能ネットワーク装置とレガシーネットワーク装置の両方を有する異種ネットワーク化企業を管理するディレクトリ使用可能ネットワーク管理方法を提供する。
【００１６】
従って、本発明の１つの面の、ネットワーク装置及びディレクトリサーバに接続された通信装置は、第１の通信プロトコルを使用して、前記ネットワーク装置の存在を検出する検出手段と、前記検出手段により検出されたネットワーク装置から、当該ネットワーク装置に関する情報を取得する情報取得手段と、前記情報取得手段が取得した情報を、第２の通信プロトコルを使用して前記ディレクトリサーバに送信するための形式に変換する変換手段と、前記変換手段により変換された情報を、前記ディレクトリサーバにおいてディレクトリエントリとして管理させるために、前記第２の通信プロトコルを使用して前記ディレクトリサーバに送信する第１の送信手段とを備え、前記第１の送信手段は、前記変換手段により変換された情報毎に、当該変換された情報を含むエントリ作成メッセージを前記ディレクトリサーバに送信し、前記第１の送信手段が送信した前記エントリ作成メッセージに対して、ディレクトリエントリが既に存在することを示すエラーメッセージが前記ディレクトリサーバから返送されてきた場合に、前記第１の送信手段は、当該既に存在するディレクトリエントリを前記変換手段により変換された情報に変更するために、エントリ変更メッセージを前記ディレクトリサーバに送信することを特徴とする。
【００１７】
ディレクトリサーバと通信するために使用される通信プロトコルは、ＬＤＡＰであるのが好ましく、レガシーネットワーク装置と通信するための通信プロトコルは、ＳＮＭＰであるのが好ましい。また、検出されたネットワーク装置の各々からの情報ブロックは、印刷速度や用紙の種類などのネットワーク機能に加え、ＩＰアドレスなどのネットワーク設定データを含むのが好ましい。各ディレクトリエントリの形式は、各ディレクトリエントリ間の整合性を保つため、標準化されたスキーマであるのが好ましい。
【００１８】
前述の構成により、１つのネットワーク化企業でレガシーネットワーク装置とディレクトリ使用可能装置の両方をサポートするディレクトリ使用可能管理方法が提供される。このようにして、本発明では、ディレクトリ使用可能管理方法に含めるために、ＬＤＡＰサポートをレガシーネットワーク装置にまで拡張するディレクトリプロキシを提供する。また、同期化機能により各ネットワーク装置の設定及び機能と対応するディレクトリエントリで発行される設定及び機能との確実な整合性が提供される。
【００１９】
別の面において、本発明は、ネットワーク装置の管理方法であって、
第１の通信プロトコルを使用して、前記ネットワーク装置の存在を検出する検出工程と、
前記検出工程で検出されたネットワーク装置から、当該ネットワーク装置に関する情報を取得する情報取得工程と、
前記情報取得工程で取得された情報を、第２の通信プロトコルを使用してディレクトリサーバに送信するための形式に変換する変換工程と、
前記変換工程で変換された情報を、前記ディレクトリサーバにおいてディレクトリエントリとして管理させるために、前記第２の通信プロトコルを使用して前記ディレクトリサーバに送信する送信工程とを備え、
前記送信工程では、前記変換工程により変換された情報毎に、当該変換された情報を含むエントリ作成メッセージを前記ディレクトリサーバに送信し、
前記送信工程で送信した前記エントリ作成メッセージに対して、ディレクトリエントリが既に存在することを示すエラーメッセージが前記ディレクトリサーバから返送されてきた場合に、当該既に存在するディレクトリエントリを前記変換工程により変換された情報に変更するために、エントリ変更メッセージを前記ディレクトリサーバに送信することを特徴とする。この管理方法は、第１の通信プロトコルを使用することによって、検出されたネットワーク装置の各々においてネットワーク装置の情報ブロック中の情報の更新を監視することと、検出されたネットワーク装置のうちの１台の情報ブロック中の情報が更新された場合、第１の通信プロトコルを使用することによって、対応するネットワーク装置から情報ブロックの更新された情報を取得することと、対応するネットワーク装置に対するディレクトリエントリへの配置を行なうために、第２の通信プロトコルを使用することによって、ディレクトリサーバに更新された情報を送信することとを更に含む。また、管理方法は、第３の通信プロトコルを使用することによって、ディレクトリサーバからのディレクトリサーバにおいてディレクトリエントリが更新されたことを示す更新メッセージの発行を監視することと、更新メッセージが発行された場合、第２の通信プロトコルを使用することによって、ディレクトリサーバから更新されたディレクトリエントリを取得することと、更新されたディレクトリエントリから更新されたデータを抽出することと、対応するネットワーク装置の情報ブロックへの配置を行なうために、更新されたディレクトリエントリに対応するネットワーク装置に更新されたデータを送信することとを含む。
【００２０】
ディレクトリサーバと通信するために使用される通信プロトコルは、ＬＤＡＰであるのが好ましく、レガシーネットワーク装置と通信するための通信プロトコルは、ＳＮＭＰであるのが好ましい。また、検出されたネットワーク装置の各々からの情報ブロックは、印刷速度や用紙の種類などのネットワーク機能に加え、ＩＰアドレスなどのネットワーク設定データを含むのが好ましい。各ディレクトリエントリの形式は、各ディレクトリエントリ間の整合性を保つため、標準化されたスキーマであるのが好ましい。更に、検出されたネットワーク装置における更新された情報の監視は、頻繁に行われるのが好ましい。最後に、ディレクトリサーバからの更新メッセージの発行は、標準ＩＰプロトコルを使用して更新メッセージを発行するディレクトリプラグインにより提供されるのが好ましい。
【００２１】
前述の構成により、１つのネットワーク化企業でレガシーネットワーク装置とディレクトリ使用可能装置の両方をサポートするディレクトリ使用可能ネットワーク管理方法が提供される。このようにして、本発明では、ディレクトリ使用可能管理方法に含めるために、ＬＤＡＰサポートをレガシーネットワーク装置にまで拡張するディレクトリプロキシを提供する。また、同期化機能により各ネットワーク装置の設定及び機能と対応するディレクトリエントリで発行される設定及び機能との確実な整合性が提供される。
【００２２】
この概要は、本発明の性質の理解を速めるために提供されるものである。添付の図面と合せて以下の好適な実施形態の詳細な説明を参照することにより、本発明をより完全に理解することが可能となる。
【００２３】
［好適な実施形態の詳細な説明］
図１は、本発明が使用されるネットワーク環境を示している。図１で明らかなように、ネットワーク１０は、それぞれネットワーク１８に接続されたサーバ１１及び１２とクライアントワークステーション１３と周辺装置１４、１５、１６及び１７とを含む。ネットワーク接続１８は、構内通信網（ＬＡＮ）や広域網（ＷＡＮ）であっても良く、又は、その他の種類のネットワークであっても良い。言うまでもなく、本発明は、図１に示すネットワークに限定されるものではなく、その他の多数の装置がネットワーク環境に含まれても良い。例えば、ネットワーク１０は、ルータ、更なるコンピュータワークステーション、更なるサーバ及び追加の周辺装置を含んでも良い。事実上は、無限の台数の装置をネットワーク１０に含めることができる。図１は、簡潔にする目的で、含まれるであろう装置のうちの数台のみを示している。
【００２４】
クライアントワークステーション１３は、コンピュータワークステーションであるのが好ましく、例えば、ＩＢＭ互換機、Macintosh ＰＣ、ＵＮＩＸワークステーション、Sun MicroSystems社製ワークステーション又はその他の種類のワークステーションであっても良い。クライアントワークステーション１３は、ユーザがサーバ１１及び／又は１２のディレクトリサーバアプリケーションプログラムにアクセスし、このディレクトリサーバアプリケーション（以下、「ディレクトリサーバ」と呼ぶ）で変更を行なうことを可能にするＬＤＡＰクライアントアプリケーションプログラムを含むのが好ましい。ディレクトリサーバアプリケーションの例としては、Microsoft Active Directory Server、Netscape Directory Server及びNovell Directory Serverがある。言うまでもなく、これらは本発明を実施する際に使用されるディレクトリサーバアプリケーションプログラムのほんの一例に過ぎない。本発明は、これらの特定のアプリケーションに限定されるものではなく、いずれのディレクトリサーバアプリケーションを用いて実現されても良い。また、クライアントワークステーション１３は、ＴＣＰ／ＩＰプロトコルを利用して通信を行なうことができるのが好ましい。後述するように、ＴＣＰ／ＩＰは、ディレクトリサーバ内のプラグインによりマルチキャストされるマルチキャストメッセージを受信するために利用される。
【００２５】
クライアントワークステーション１３のＬＤＡＰクライアントアプリケーションプログラムは、サーバ１１及び１２で実行中のディレクトリサーバアプリケーションとネットワーク１８を介して通信する。クライアントワークステーション１３とサーバ１１及び１２のディレクトリサーバとの通信は、図３を参照しながら以下により詳細に説明する。また、ＬＤＡＰクライアントアプリケーションプログラムは、サーバ１１及び１２のディレクトリサーバのマルチキャストプラグインによりマルチキャストされるマルチキャストメッセージを受信して処理する。尚、クライアントワークステーション１３のＬＤＡＰクライアントアプリケーションは、ユーザがディレクトリサーバで変更を行なうことを許可するがマルチキャストプラグインからマルチキャストメッセージを受信することは許可しないか、マルチキャストプラグインからマルチキャストメッセージを受信することのみ許可するがディレクトリサーバで変更を行なうことは許可しないか、あるいは、ディレクトリサーバで変更を行なうことを許可しマルチキャストメッセージを受信することも許可するかのいずれかであるように構成されても良い。更に、クライアントワークステーション１３のＬＤＡＰクライアントアプリケーションは、ディレクトリサーバで変更を行なえるようにするために、サーバ１１及び１２のディレクトリサーバアプリケーションに対応する必要がない。すなわち、サーバ１１及び１２のディレクトリサーバアプリケーションがNetscape Directory Serverである場合、ユーザがディレクトリサーバで変更を行なえるようにするためにクライアントワークステーション１３のＬＤＡＰクライアントアプリケーションをNetscape Directory ServerのＬＤＡＰクライアントにする必要はない。ＬＤＡＰクライアントとディレクトリサーバとの通信は、ＬＤＡＰプロトコルを用いて行われているので、サーバ１１及び１２のNetscape Directory Serverで変更を行なう際には、いずれのＬＤＡＰクライアントアプリケーションもクライアントワークステーション１３において使用可能である。
【００２６】
クライアントワークステーション１３のＬＤＡＰクライアントアプリケーションは、サーバ１１及び１２のディレクトリサーバアプリケーションで変更を行なう唯一の方法ではない。変更は、サーバ１１及び１２自体のネイティブアプリケーションを介してサーバ１１及び１２のディレクトリサーバで行なうこともできる。また、変更は、ネットワーク上の装置内の埋込み型ＬＤＡＰクライアントによって、あるいは、ディレクトリプロキシを介して行なうことが可能であろう。従って、本発明では、クライアントワークステーション１３のＬＤＡＰクライアントアプリケーションにより変更が行なわれる必要がなく、本発明の目的は、ディレクトリサーバでの変更のために行われるネットワーク上の多種多様な装置とディレクトリサーバとの通信を管理することである。
【００２７】
周辺装置１４、１５、１６及び１７は、ネットワーク１０に含まれるいかなる種類の周辺装置であっても良い。すなわち、プリンタ、複写機、ＦＡＸ装置、ルータなどであっても良く、図１では、これらの装置をプリンタ及び複写機として示すが、これに限定されない。しかしながら、簡潔にする目的で、周辺装置１４、１５及び１６はプリンタとして説明され、周辺装置１７はネットワーク複写機として説明される。
【００２８】
種々のプリンタ及び複写機がネットワーク１０に含まれても良いことは、容易に理解できる。例えば、ネットワーク１０は、最新のネットワーク通信技術を含むプリンタと従来のネットワーク通信技術を含むプリンタとから構成されても良い。すなわち、プリンタの一部が、ディレクトリサーバと直接通信する能力を提供する最新技術を含んでも良い。この種のプリンタは、埋込み型ＬＤＡＰクライアントを含んでも良い。一方、ネットワーク上の別のプリンタは、ＳＮＭＰを介して通信し、ディレクトリサーバと直接通信する能力がないレガシープリンタなどの従来のプリンタであっても良い。この種のプリンタは、媒介装置がＬＤＡＰプロトコルを使用してディレクトリサーバと通信可能であることを必要とすることもある。更に、ネットワーク上のプリンタの一部は、ＬＤＡＰプロトコルを使用してディレクトリサーバと直接通信することが可能な埋込み型のＬＤＡＰクライアントとディレクトリサーバと通信するための媒介手段を必要とするＳＮＭＰクライアントとの両方を含むハイブリッド装置であっても良い。簡潔にする目的で、ネットワーク１０では、プリンタ１４は、ディレクトリサーバと直接通信する埋込み型ＬＤＡＰクライアントを含むプリンタであるとし、プリンタ１６及び複写機１７は、それぞれ、ＳＮＭＰを使用して通信を行なうレガシープリンタ及びレガシー複写機であるとし、プリンタ１５は、埋込み型ＬＤＡＰクライアントを含み且つＳＮＭＰを使用して通信を行なうハイブリッドプリンタであるとする。
【００２９】
図２は、各装置１３から１７と、例えば、サーバ１１のディレクトリサーバとの間の通信プロトコルのアーキテクチャを示す。図２で明らかなように、ディレクトリサーバ２５は、ＬＤＡＰプロトコルを使用して、ＬＤＡＰクライアント２７、埋込み型クライアント装置２８、ディレクトリプロキシ２９及びハイブリッド装置３１と通信を行なう。ＬＤＡＰクライアント２７は、例えば、クライアントワークステーション１３上で実行中の上述のＬＤＡＰクライアントアプリケーションであっても良い。従って、ＬＤＡＰクライアント２７は、ディレクトリサーバで変更を行なうために、ディレクトリサーバ２５と直接通信を行なう。埋込み型クライアント装置２８及びハイブリッド装置３１は、それぞれ、埋込み型ＬＤＡＰクライアントを含むプリンタ１４及び１５であっても良い。埋込み型ＬＤＡＰクライアント２８とハイブリッド装置３１との相違点の１つは、ハイブリッド装置３１がＳＮＭＰを介して通信を行なう能力も含むのに対し、埋込み型ＬＤＡＰクライアント２８は、ＬＤＡＰのみを介して通信を行なうことである。ディレクトリプロキシ２９は、ディレクトリサーバ２５で変更を行なうために、ＬＤＡＰを介してディレクトリサーバ２５と通信を行ない、ディレクトリサーバ２５に対して、ＳＭＮＰ装置３０とハイブリッド装置３１との間の媒体手段、すなわち、変換器として動作する。ディレクトリプロキシ２９に関しては、以下でより詳細に説明する。
【００３０】
ディレクトリサーバ２５は、プラグイン２６及び４０から４３も含む。プラグイン２６は、通知プラグインであり、詳細は以下で説明するが、簡単には、ディレクトリサーバ２５で変更が行なわれる度に呼び出されるものである。通知プラグインは、呼び出されると、ネットワーク上の適切な装置に変更を通知する通知プロセスの管理を行なう。例えば、通知プラグイン２６は、ネットワーク上のＬＤＡＰ使用可能装置にユニキャストメッセージを送出したり、あるいは、マルチキャストメッセージを送信するためにマルチキャストプラグイン（４０から４３）のうちの１つを呼び出したりする。マルチキャストプラグイン４０から４３は、通知プラグイン２６により呼び出されると、ディレクトリサーバ２５で行われた変更に関する情報パケットを生成し、そのパケットをマルチキャストＩＰアドレスに送信する。マルチキャスト処理及びユニキャスト処理は、以下でより詳細に説明する。
【００３１】
図３は、サーバ１１の内部アーキテクチャのより詳細な図を示す。サーバ１２は、サーバ１１に類似しているので、簡潔にする目的で、サーバ１１のみの説明を行なう。サーバ１１は、例えば、Compaq Prosigniaサーバ又はその他の種類のサーバであっても良い。しかしながら、サーバ１１は、それ自体がサーバである必要はなく、ディレクトリサーバアプリケーションプログラムを実行可能であればいかなるコンピュータであっても良い。図３に示すように、サーバ１１は、ネットワークインタフェース３５にインタフェースされる接続１９によりネットワーク１８に接続される。ネットワークインタフェース３５は、ネットワークを介してサーバ１１により情報の送受信を制御するネットワークカードであるのが好ましい。ネットワークインタフェース３５とインタフェースされるのが、ＴＣＰ／ＩＰレイヤ３６である。ＴＣＰ／ＩＰは、ユニキャスト処理及びマルチキャスト処理を行なうのに好適なプロトコルであるが、その他のプロトコルを代わりに使用することもできる。ＴＣＰ／ＩＰを使用したユニキャスト処理及びマルチキャスト処理の理解を深めるために、以下の点を考慮する。
【００３２】
通常、ＩＰアドレスには、１対１通信、ブロードキャスト及びマルチキャストの３つの異なるカテゴリが存在する。ここでは、１対１通信及びマルチキャストのみが関係するので、ブロードキャストの説明は省略する。１対１通信の場合、ある範囲のＩＰアドレスが割当てられ、ネットワーク上の各装置を明確に識別するのに使用される。例えば、図１に示すネットワークに接続された各装置は、ネットワーク上のその装置を識別する別々のＩＰアドレスを割当てられるであろう。各装置は、装置自体が保有するＩＰアドレスを手動で割当てられるか、あるいは、装置がネットワークに接続される度にアプリケーションプログラムにより自動的に割当てられる。従って、ユニキャスト処理を行なう場合、ディレクトリサーバプラグイン２６から情報パケットを受信する各装置のＩＰアドレスが、プラグイン構成でセットアップされる。ディレクトリサーバで変更が行なわれた後に、通知プラグインが情報パケットを生成する場合、通知プラグイン構成でセットアップされたネットワーク上の各装置にこのパケットを送信する。
【００３３】
マルチキャスト処理では、ある範囲のＩＰアドレスが割当てられるが、そのＩＰアドレスのうちの１つに送信されたメッセージは、その１つのＩＰアドレスで登録した複数のメンバーのみが受信する。１対１のＩＰアドレスとは異なり、マルチキャスト範囲のＩＰアドレスは、ある特定の装置に割当てられるものではない。これらのアドレスは、送られてきたメッセージを受信するマルチキャストグループを表す仮想のアドレスであり、受信したメッセージは、そのグループに登録したメンバーに配布される。従って、情報パケットは、ディレクトリサーバマルチキャストプラグインにより指定のマルチキャストグループにマルチキャストされ、グループの登録メンバーに配布される。
【００３４】
図３において、ＴＣＰ／ＩＰレイヤ３６にインタフェースされるのがＬＤＡＰプロトコルレイヤ３７である。ＬＤＡＰプロトコルレイヤ３７は、ＬＤＡＰクライアントとサーバ１１のディレクトリサーバ２５のようなディレクトリサーバとの通信を実現する。ＬＤＡＰプロトコルレイヤは、ディレクトリサーバ２５で変更を行なうＬＤＡＰクライアントが、クライアントワークステーション１３のＬＤＡＰクライアントであるか、埋込み型ＬＤＡＰクライアント２８又はハイブリッド装置３１の埋込み型クライアントであるか、ディレクトリプロキシ２９のＬＤＡＰクライアントであるかに関わらず、ディレクトリサーバ２５と通信するために使用される。従って、ＬＤＡＰプロトコルを使用することで、ＬＤＡＰクライアントは、ディレクトリサーバで変更を行なうことができる。
【００３５】
図４は、メッセージシステムのアーキテクチャ及びサーバ１１から少なくとも１つのマルチキャストグループのメンバーとして登録したクライアントへのマルチキャストメッセージの流れの一例を示す。図４は、マルチキャストするためのアーキテクチャのみを示し、ユニキャスト処理は、以下で詳細に説明される。図４のメッセージシステムは、ディレクトリサーバアプリケーションプログラムのプラグイン機能を使用するのが好ましい。すなわち、ディレクトリサーバで変更が行なわれ、通知プラグインがマルチキャストメッセージを送信すべきであると判定した場合、ディレクトリサーバは、マルチキャストプラグインを呼び出す。このマルチキャストプラグインは、情報パケットを生成し、マルチキャストグループにマルチキャストする。しかしながら、プラグインが必要な訳ではなく、マルチキャスト情報パケットを生成し、対応するマルチキャストグループにマルチキャストするその他の実現例を使用することもできるであろう。他の適用例に特有のプラグインも同様に実現されるが、ここでは、Netscape Directory Serverの一部としてサポートされるプラグインを説明する。
【００３６】
図４で明らかなように、Netscape Directory Server２５では、ＡＤＤ（作成）プラグイン４０、ＤＥＬＥＴＥ（削除）プラグイン４１、ＭＯＤＩＦＹ（変更）プラグイン４２及びＳＥＡＲＣＨ（検索）プラグイン４３の４種類のマルチキャストプラグインが実施される。Netscape Directory Serverによりサポートされるプラグインのうちの１種類は、処理後プラグインである。前述のディレクトリサーバ２５用のマルチキャストプラグインは、それぞれ、処理後プラグインとして実施されるのが好ましい。処理後プラグインは、処理が行なわれた後（すなわち、処理後）に適切なプラグインが呼び出される時のプラグインである。従って、ディレクトリサーバで変更が行なわれた場合、ディレクトリサーバは、行われた変更の種類に対応する適切なマルチキャストプラグインを呼び出す。すなわち、新規オブジェクトがディレクトリサーバで作成された場合、ディレクトリサーバは、ＡＤＤプラグインを呼び出す。ＡＤＤプラグインが呼び出された場合、ＡＤＤ変更に関する情報パケットを生成し、変更の種類に対応するマルチキャストグループにマルチキャストする。それにより、マルチキャストグループの登録メンバーは情報パケットを受信する。
【００３７】
マルチキャスト処理により情報パケットを送信するために、各プラグインに対応するマルチキャストアドレスが確立される。各マルチキャストプラグインは、情報パケットの送信先である対応するマルチキャストアドレスを有する。例えば、図４で明らかなように、ＡＤＤプラグイン４０は、ＡＤＤ情報マルチキャストパケットを受信するように指定されたマルチキャストグループ４５に情報パケットを送信する。同様に、ＤＥＬＥＴＥプラグイン４１は、対応するマルチキャストグループ４６、ＭＯＤＩＦＹプラグイン４２は、対応するマルチキャストグループ４７、ＳＥＡＲＣＨプラグイン４３は、対応するマルチキャストグループ４７をそれぞれ有する。前述のマルチキャストグループの各々に対するマルチキャストＩＰアドレスの例は、以下の通りである。
【００３８】
処理／マルチキャストグループ ＩＰアドレス
ＡＤＤ処理（マルチキャストグループ４５）： 225.6.7.8
ＤＥＬＥＴＥ処理（マルチキャストグループ４６）： 225.6.7.9
ＭＯＤＩＦＹ処理（マルチキャストグループ４７）： 225.6.7.10
ＳＥＡＲＣＨ処理（マルチキャストグループ４８）： 225.6.7.11
ＬＤＡＰクライアントによりディレクトリサーバで変更が行なわれた場合、通知プラグインは、必要に応じて適切なマルチキャストプラグインを呼び出す。それにより、マルチキャストプラグインは、情報パケットを生成し、ネットワークを介して対応するマルチキャストＩＰアドレスにマルチキャストする。
【００３９】
マルチキャストメッセージを受信するためには、メンバーは、受信を希望する変更情報パケットの種類に対応する各マルチキャストグループに登録する。例えば、図４で明らかなように、クライアント５０は、マルチキャストグループ４５及び４６のメンバーとして登録する。従って、クライアント５０は、ディレクトリサーバ２５で行われたＡＤＤ処理及びＤＥＬＥＴＥ処理に対応するマルチキャストメッセージを受信する。クライアント５１は、マルチキャストグループ４５、４６、４７及び４８に登録し、その結果、ディレクトリサーバ２５で行われるＡＤＤ処理、ＤＥＬＥＴＥ処理、ＭＯＤＩＦＹ処理及びＳＥＡＲＣＨ処理に関するマルチキャストメッセージを受信する。クライアント５２は、マルチキャストグループ４７及び４８のメンバーとして登録し、その結果、ディレクトリサーバ２５で行われるＭＯＤＩＦＹ処理及びＳＥＡＲＣＨ処理に関するマルチキャストメッセージのみを受信する。ここで、ディレクトリプロキシ２９は、前述の各マルチキャストグループのメンバーとして登録しても良い。
【００４０】
従って、上述のように、ＬＤＡＰクライアントは、ディレクトリサーバで変更を行なうためにディレクトリサーバとインタフェースし、このディレクトリサーバは、必要であれば行われた変更に対応するマルチキャストプラグインを呼び出す通知プラグインを呼び出す。マルチキャストプラグインは、処理後情報パケットを生成し、ネットワークを介して変更の種類に対応するマルチキャストグループにマルチキャストする。そのマルチキャストグループに登録したクライアントは、そのマルチキャストメッセージを受信する。
【００４１】
ユニキャスト処理を行なうためには、通知プラグイン２６は、ネットワーク上の特定のＬＤＡＰ使用可能装置で行われた変更処理に対して、適切な時に変更情報パケットを送信するように構成されるであろう。例えば、通知プラグイン２６は、ＬＤＡＰ使用可能装置のディレクトリ入力のため、変更がディレクトリサーバにより開始された場合、情報パケットを生成して装置にユニキャストするように構成されても良い。通知プラグイン２６は、ディレクトリサーバで変更された特定の装置にのみユニキャストメッセージを送信し、ネットワーク上のその他の装置には送信しない。例えば、プリンタ１４の構成がディレクトリサーバ２５で変更された場合、通知プラグイン２６は、プリンタ１４にのみメッセージをユニキャストし、プリンタ１５（同様にＬＤＡＰ使用可能なハイブリッドプリンタ）にはユニキャストしない。しかしながら、後述するように、ユニキャスト処理に関する問題点の１つは、通知プラグインがユニキャストメッセージを送信する前に、どのＬＤＡＰクライアントが変更処理を行なったかを最初に判定することである。すなわち、プリンタ１４のＬＤＡＰクライアントが変更を開始した場合、変更を開始したのはプリンタ１４のＬＤＡＰクライアントであるので、プラグインは、変更を通知するユニキャストメッセージをプリンタ１４に送信しない。しかし、クライアントワークステーション１３のＬＤＡＰクライアントにより変更が開始された場合、プリンタ１４のＬＤＡＰクライアントにより変更が開始された訳ではないので、通知プラグインは、変更を通知するためのユニキャストメッセージをプリンタ１４に送信する。
【００４２】
図５は、ディレクトリプロキシ２９の内部アーキテクチャのより詳細な構成及びネットワーク上の種々の装置との通信を示す。図５に示すように、ディレクトリプロキシ２９は、ＬＤＡＰクライアント６０、ＳＮＭＰデバイスディスカバリモジュール６１、ＳＮＭＰデバイス監視／ポーリングモジュール６２、ＳＮＭＰクライアント６３及びＬＤＡＰ／ＳＮＭＰ変換器６４を含む。ＬＤＡＰクライアント６０は、ディレクトリサーバ２５で変更を行ない、変換を行なってネットワーク上のＳＮＭＰ使用可能装置に送信する予定のＬＤＡＰコマンドをディレクトリサーバ２５から受信するために、ＬＤＡＰプロトコルを使用してディレクトリサーバ２５と通信を行なう。また、ＬＤＡＰクライアント６０は、図４に関して上述したマルチキャストグループ４５から４８などの種々のマルチキャストグループからマルチキャストメッセージを受信する。更に、ＬＤＡＰクライアント６０は、ＬＤＡＰ／ＳＮＭＰ変換器６４とのＬＤＡＰコマンドの送受信を行なう。
【００４３】
ＳＮＭＰクライアント６３は、レガシー（ＳＮＭＰ）プリンタ１６及びハイブリッド（ＳＮＭＰ／ＬＤＡＰ）プリンタ１５を含むネットワーク上の全てのＳＮＭＰ使用可能装置と通信を行なう。ＳＮＭＰクライアント６３は、ネットワーク上の全てのＳＮＭＰ使用可能装置とＳＮＭＰコマンドの送受信を行なう。また、ＳＮＭＰクライアント６３は、ＳＮＭＰデバイスディスカバリモジュール６１及びＳＮＭＰデバイス監視／ポーリングモジュール６２と通信し、モジュール６１及び６２とネットワーク上の全てのＳＮＭＰ使用可能装置との間でのメッセージの送信を行なう。更に、ＳＮＭＰクライアント６３は、ＬＤＡＰ／ＳＮＭＰ変換器６４と通信を行ない、ＳＮＭＰコマンドの送受信を行なう。ＬＤＡＰ／ＳＮＭＰ変換器６４は、ＳＮＭＰクライアント６３から受信したＳＮＭＰコマンドをＬＤＡＰ形式に変換し、そのＬＤＡＰコマンドをＬＤＡＰクライアント６０に送信する。また、ＬＤＡＰ／ＳＮＭＰ変換器６４は、ＬＤＡＰコマンドをＬＤＡＰクライアント６０から受信し、それをＳＮＭＰコマンド形式に変換し、ＳＮＭＰクライアント６３に送信する。
【００４４】
ＳＮＭＰデバイスディスカバリモジュール６１は、ＳＮＭＰクライアント６３を介して問い合わせ処理を行ない、ネットワーク上の全てのＳＮＭＰ装置に関する情報を取得する。また、ＳＮＭＰデバイスディスカバリモジュール６１は、ネットワーク上の全てのＳＮＭＰ装置から問い合わせに対する応答を受信し、その応答に基づいてＳＮＭＰコマンドをＳＮＭＰクライアント６３に送信する。ＳＮＭＰデバイス監視／ポーリングモジュール６２も、ＳＮＭＰクライアント６３を介して問い合わせ処理を行ない、ネットワーク上の全てのＳＮＭＰ装置に関する情報を取得する。モジュール６１とモジュール６２との相違点の１つは、モジュール６１が、通常、ディレクトリプロキシの始動時に問い合わせを行なうのに対し、モジュール６２は、通常、始動後に定期的な問い合わせを行ない、ＳＮＭＰ使用可能装置の全てから更新情報を取得することである。モジュール６１及び６２の処理は、以下でより詳細に説明する。
【００４５】
通常、ネットワーク１８に接続される装置には、埋込み型ＬＤＡＰクライアント、埋込み型ＬＤＡＰクライアントを持たないＳＮＭＰ装置及びＳＮＭＰ装置であり且つ埋込み型ＬＤＡＰクライアントを有するハイブリッド装置の３つの異なる種類がある。ネットワーク上の各装置では、ディレクトリサーバ２５のディレクトリ登録又はディレクトリ登録事項（ディレクトリエントリ）において構成情報の保守が行なわれる。すなわち、ディレクトリサーバ２５は、全てのＳＮＭＰ使用可能装置、全ての埋込み型ＬＤＡＰクライアント装置及び全てのハイブリッド装置のディレクトリを含む。ディレクトリエントリは、通常、標準化された構成又は体系（スキーマ）に従ってフォーマット化されており、スキーマ拡張を含んでも良い。標準化されたスキーマは、その装置に対するディレクトリエントリにおいて行われた変更のソースを示すソースフラグを含む。ソースフラグは、通知プラグイン２６により設定され、変更が、ディレクトリサーバ、すなわち、ネイティブアプリケーション又はワークステーション１３のＬＤＡＰクライアントにより開始された場合、０に設定され、装置により開始された場合、１に設定される。３種類の装置の各々及びディレクトリサーバにおけるこれらの装置の構成に対する変更の行なわれ方については、図６を参照しながら説明する。
【００４６】
図６は、３種類の装置の各々に対する変更の開始方法に関して３つの可能性のあるシナリオを示す。シナリオの１つでは、変更は、埋込み型ＬＤＡＰクライアントを有する装置に対して開始される。埋込み型ＬＤＡＰクライアント装置に対する変更は、装置自体の埋込み型ＬＤＡＰクライアント、あるいは、ディレクトリサーバ、すなわち、ワークステーション１３のＬＤＡＰクライアント又はサーバ１１のネイティブアプリケーションにより開始されても良い。第２のシナリオでは、変更はＳＮＭＰ装置に対して開始される。変更は、ＳＮＭＰ装置自体またはディレクトリサーバにより開始されても良い。第３のシナリオでは、変更は、ハイブリッド装置に対して開始される。変更は、装置自体、すなわち、この場合は装置のＳＮＭＰクライアント又は装置の埋込み型ＬＤＡＰクライアントにより開始されても良く、あるいは、ディレクトリサーバにより開始されても良い。これらの３つのシナリオの各々についてより詳細に説明する。
【００４７】
尚、以下では、通常、ディレクトリサーバ２５におけるエントリが既に存在する装置の構成に対して行われる変更を説明する。しかしながら、装置のネットワークからの削除及び新規の装置のネットワークへの追加などのその他の変更も同様に行われることは容易に理解されるだろう。従って、簡潔にする目的で、ネットワーク上に既に存在する装置の構成に対する変更に関わる処理のみを説明する。上述のように、ネットワーク上の各装置の構成における変更は、装置自体とディレクトリサーバとのいずれによっても開始することができる。以下の説明では、ネットワーク管理者が、装置自体において装置のＩＰアドレスを変更する例と、ネットワーク管理者が、ディレクトリサーバにおいて装置のＩＰアドレスを変更する例との２つの例を提示することによって、両方の場合が説明される。
【００４８】
最初に説明する装置は、プリンタ１４などの埋込み型ＬＤＡＰクライアントを有する装置である。プリンタ１４は、埋込み型ＬＤＡＰクライアントを含み、ＳＮＭＰクライアントを含まない。プリンタ１４は、純粋なＬＤＡＰ使用可能装置であり、ハイブリッド装置ではない。図２に関して前述したように、埋込み型ＬＤＡＰクライアントは、ＬＤＡＰプロトコルを介してディレクトリサーバと直接通信を行なう。従って、装置の構成における変更は、ＬＤＡＰを介して装置とディレクトリサーバとの間で直接伝達され、変換器を用いる必要はない。
【００４９】
図６は、埋込み型ＬＤＡＰクライアントを有する装置における変更の管理方法を含む３種類の各装置の管理方法のプロセスステップを表すフローチャートを示す。第１の埋込み型ＬＤＡＰクライアントのシナリオの例では、管理者は、プリンタ１４自体の埋込み型ＬＤＡＰクライアントを使用してＩＰアドレスを変更する。
【００５０】
第１の例では、ステップＳ６０１において、管理者は、プリンタ１４の埋込み型ＬＤＡＰクライアントを使用してプロセスを実行し、プリンタ１４のＩＰアドレスを変更する。埋込み型ＬＤＡＰクライアントによりプリンタ１４に対する変更が行なわれた場合、埋込み型ＬＤＡＰクライアントは、ＬＤＡＰプロトコルを介してディレクトリサーバ２５との通信を開始する。通信が一度確立されると、埋込み型ＬＤＡＰクライアントは、ＬＤＡＰ＿ＭＯＤＩＦＹ（ＬＤＡＰ変更）コマンドを使用してディレクトリサーバに対する変更を自ら発行する。また、埋込み型ＬＤＡＰクライアントは、ソースフラグを１に設定する。ディレクトリサーバ２５に対する変更が行なわれると、通知プラグイン２６が呼び出される（ステップＳ６０２）。
【００５１】
ステップＳ６０３で、ディレクトリサーバに対する変更が一度行なわれると、ディレクトリサーバ通知プラグイン２６は、ソースフラグを参照して、いずれの通知プロセスが行われるべきかを判定する。フラグが１に設定されている場合、通知プラグイン２６は、変更が装置により開始されており、装置に変更を通知する必要がないことを認識する。従って、この例では、処理はステップＳ６０４へと進み、そこで通知プラグイン２６は、ソースフラグを０にリセットし、通知プロセスを終了する。
【００５２】
第２の埋込み型ＬＤＡＰクライアントのシナリオの例では、管理者は、クライアントワークステーション１３のＬＤＡＰクライアントを使用してディレクトリサーバ２５のプリンタ１４のＩＰアドレスを変更する。変更を行なうために、管理者は、ワークステーション１３のＬＤＡＰクライアントアプリケーションを起動する。ＬＤＡＰクライアントアプリケーションは、ディレクトリサーバ２５にアクセスするように構成され、特に、プリンタ１４を含むオブジェクトクラスをアクセスするように構成される。ＬＤＡＰクライアントは、一度構成されると、ＬＤＡＰプロトコルを介してディレクトリサーバ２５との通信を確立する。一度通信が確立されると、ＬＤＡＰクライアントアプリケーションは、管理者に対して、クライアントワークステーション１３のディスプレイ上にプリンタ１４を含むオブジェクトクラスに対するディレクトリ構造を表示する。クライアントワークステーション１３のＬＤＡＰクライアントを使用して、管理者は、ディレクトリサーバ２５においてプリンタ１４のＩＰアドレスを変更する（ステップＳ６０１）。また、ＬＤＡＰクライアントアプリケーションは、ソースフラグを０に設定する。変更が行なわれると、ディレクトリサーバは通知プラグイン２６を呼び出す（ステップＳ６０２）。
【００５３】
ステップＳ６０３では、通知プラグイン２６は、ソースフラグが０に設定されているか否かを判定する。ここでは、ソースフラグは０に設定されているので、処理はステップＳ６０５に進む。ステップＳ６０５では、通知プラグイン２６は、プリンタ１４に対するディレクトリエントリを参照して、装置がＬＤＡＰ使用可能であるかを判定する。この判定は、通知プラグインがＬＤＡＰ使用可能装置に対してユニキャストメッセージを送信するべきか、あるいは、ディレクトリプロキシにより受信されるマルチキャストメッセージを送信するためにマルチキャストプラグインの１つを呼び出すべきかを判定するために行われる。通知プラグインが、装置がＬＤＡＰ使用可能であると判定した場合、すなわち、本例においては、プリンタ１４が埋込み型ＬＤＡＰクライアントを有するのでＬＤＡＰ使用可能であると判定した場合、処理はステップＳ６０６に進む。
【００５４】
ステップＳ６０６では、通知プラグイン２６は、ユニキャストメッセージを生成し、プリンタ１４の埋込み型ＬＤＡＰクライアントに対して、プリンタ１４に対するディレクトリサーバ２５のディレクトリエントリにおいて変更が行われたことを通知する。通知プラグイン２６により送信されるユニキャストメッセージは、埋込み型ＬＤＡＰクライアントに対して変更が行なわれたことを通知するだけであり、変更自体に関するいかなる明確な情報も含まない。このユニキャストメッセージを受信すると、プリンタ１４の埋込み型ＬＤＡＰクライアントは、ディレクトリサーバ２５との通信を確立し、ディレクトリエントリを読み出して変更情報を取得する（Ｓ６０７）。変更情報を取得すると、埋込み型ＬＤＡＰクライアントは、装置の構成を更新し（ステップＳ６０８）、プロセスは終了する。
【００５５】
前述の第２の例の結果として、プリンタ１４のＩＰアドレスは、ワークステーション１３のＬＤＡＰクライアントによりディレクトリサーバにおいて変更され、ディレクトリサーバの通知プラグインは、プリンタ１４の埋込み型ＬＤＡＰクライアントに対して、ディレクトリサーバで変更が行なわれたことを通知し、埋込み型ＬＤＡＰクライアントは、ディレクトリサーバの変更情報を読み出し、プリンタ１４の構成を更新する。
【００５６】
第２のシナリオでは、純粋なＳＮＭＰ装置を説明する。図６は、ＳＮＭＰ装置における変更の管理方法に対するプロセスステップを示す。しかしながら、ＳＮＭＰ装置に対する変更の例を説明する前に、始動時の情報取得（ＳＮＭＰデバイスディスカバリモジュール６１及びそれに関連する図７のフローチャート）とネットワーク上の全てのＳＮＭＰ装置に対する更新の取得（ＳＮＭＰデバイス監視／ポーリングモジュール６２及びそれに関連する図８のフローチャート）とを含むネットワーク上のＳＮＭＰ装置に関する情報をディレクトリプロキシが取得する方法についてのより詳細な説明を行なう。
【００５７】
図７において、ＳＮＭＰデバイスディスカバリモジュール６１は、通常、ネットワーク上の全てのＳＮＭＰ使用可能装置に関するネットワーク情報を取得し、その情報は、ディレクトリプロキシを介してディレクトリサーバ向けに処理される。ディスカバリモジュール６１は、ディレクトリプロキシの始動時又は新規の装置に対する定期的なポーリング処理中に、装置からネットワーク情報を取得する。ディレクトリプロキシが開始されると、ディスカバリモジュール６１は、ネットワーク上の全てのＳＮＭＰ装置を検出する。ネットワーク上のＳＮＭＰ装置を検出するために、ディスカバリモジュール６１は、ネットワーク上の全てのＳＮＭＰ装置に関するネットワーク識別情報に対する問い合わせ（ＳＮＭＰ＿ＱＵＥＲＹ：ＳＮＭＰ問い合わせ）を送出する（ステップＳ７０１）。ネットワーク上の全てのＳＮＭＰ使用可能装置は、その問い合わせに対する応答を提出する（ステップＳ７０２）。ＳＮＭＰ使用可能装置からの応答は、その装置のＩＰアドレス、装置の種類、機種、ＭＡＣアドレス、装置名及びＭＩＢ（Management Information Base：管理情報ベース）ボードの種類などのネットワーク識別情報を含む。
【００５８】
ディスカバリモジュール６１は、各装置から応答を受信すると、各装置のネットワーク識別情報を使用して、問い合わせに応答した各装置に対してＳＮＭＰ＿ＧＥＴ（ＳＮＭＰ取得）コマンドを送出する（ステップＳ７０３）。ＳＮＭＰ＿ＧＥＴコマンドは、ＳＮＭＰ装置に送信され、装置のネットワーク設定、装置のステータス及び装置の特徴などの情報をＳＮＭＰ装置のＭＩＢから取得する。要求を受信した各ＳＮＭＰ装置は、要求された情報を伴ってディスカバリモジュール６１に応答する（ステップＳ７０４）。要求された情報を受信すると、ディスカバリモジュール６１は、ＳＮＭＰクライアント６３と通信し、ＳＮＭＰ装置の情報をＳＮＭＰクライアント６３に送信する（ステップＳ７０５）。続いて、ＳＮＭＰクライアント６３は、このＳＮＭＰ装置の情報をＬＤＡＰ／ＳＮＭＰ変換器６４に送信する（ステップＳ７０６）。変換器６４は、装置の情報をＬＤＡＰ形式に変換し、ＬＤＡＰクライアント６０と通信し、ＬＤＡＰ形式のＳＮＭＰ装置の情報をＬＤＡＰクライアント６０に送信する（ステップＳ７０７）。次に、ＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立し、ＳＮＭＰ装置の情報をディレクトリサーバに対して自ら発行する（ステップＳ７０８）。ＬＤＡＰクライアント６０は、まず、ＬＤＡＰ＿ＡＤＤ（ＬＤＡＰ作成）コマンドを使用して、ディレクトリサーバ２５にＳＮＭＰ装置の情報を追加することを試みる。ＳＮＭＰ装置に対するエントリがディレクトリサーバ２５に既に存在する場合、ディレクトリサーバにより、エラーメッセージがＬＤＡＰクライアントに返される。ＬＤＡＰクライアント６０は、ＬＤＡＰ＿ＭＯＤＩＦＹ（ＬＤＡＰ変更）コマンドを使用して、既存の装置に対するディレクトリサーバ２５のディレクトリエントリ情報を置換する。
【００５９】
従って、新規の装置がネットワーク上で検出された場合、又は、既存の装置の構成がディレクトリプロキシが始動されるのに先立って変更された場合、ディレクトリプロキシによる変更を始動時に開始することができる。ディレクトリプロキシにより始動時に変更を行なうこのプロセスでは、装置において変更が開始された場合と同様の装置管理処理が行なわれる。従って、以下の装置及び監視／ポーリングモジュールで開始された変更に関する説明は、ディレクトリプロキシのディスカバリモジュールにより開始された変更にも等しく適用される。
【００６０】
図８は、ＳＮＭＰデバイス監視／ポーリングモジュール６２により行われるプロセスステップを示す。ＳＮＭＰデバイス監視／ポーリングモジュール６２は、監視又はポーリングの２つのモードの一方で動作しても良い。ポーリングモードでは、モジュール６２は、通常、ネットワーク上で定期的な問い合わせを行ない、ＳＮＭＰ装置のいずれかが更新されたか否かを判定する。このモードでは、ディレクトリプロキシ２９の始動後及びディスカバリモジュール６１の処理終了後に、監視／ポーリングモジュール６２は、更新された情報に対する変更問い合わせメッセージを送出することによって定期的な問い合わせ処理を行なっても良い。例えば、モジュール６２は、ネットワーク上で検出されたＳＮＭＰ装置の全てに対して選択されたＭＩＢのデータ更新に関する問い合わせを行なうために、毎秒ポーリング処理を行なうように構成されても良い（ステップＳ８０１）。更新が行われていない場合、いずれの装置も応答しないので、設定されたタイムアウト時間の経過後に処理は終了する。各装置のいずれかの構成が変更されていた場合、ネットワーク上の更新された装置のみが、問い合わせを受信した際に監視／ポーリングモジュール６２に対して変更が行なわれたことを示す変更情報応答を伴って問い合わせに応答する（ステップＳ８０２）。変更情報応答メッセージを受信すると、モジュール６２は、応答した各装置に対して更新された情報に対する要求を送信する（ステップＳ８０３）。ＳＮＭＰ装置は、要求を受信すると、更新された情報をモジュール６２に送信する（ステップＳ８０４）。モジュール６１と同様に、モジュール６２は、ＳＮＭＰクライアント６３にこの情報を送信し（ステップＳ８０５）、ＳＮＭＰクライアント６３は、それをＬＤＡＰ／ＳＮＭＰ変換器６４に送信する（ステップＳ８０６）。ＬＤＡＰ／ＳＮＭＰ変換器６４は、ＳＮＭＰ情報をＬＤＡＰ形式に変換し、ＬＤＡＰ形式の情報をＬＤＡＰクライアント６０に送信する（ステップＳ８０７）。ＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立し、ディレクトリサーバにおいて変更を自ら発行する（ステップＳ８０８）。
【００６１】
監視／ポーリングモジュール６２は、更新を調べるためにネットワークをポーリングするのではなく、ネットワーク上の全てのＳＮＭＰ装置からの更新に関する更新メッセージが送出されるのを待ってネットワークを監視することもできる。ここで、ネットワーク上の各ＳＮＭＰ装置は、装置において変更が行なわれた場合にネットワーク上にメッセージを送出することができる。モジュール６２は、更新メッセージの送出を待ち、メッセージを受信すると、そのメッセージを送出した装置に対して、更新された情報を伴って応答するように要求する。このように、ステップＳ８０３からＳ８０８は、上述したのと同様の方法で実行される。ステップＳ８０１及びＳ８０２は、更新を調べるためにネットワークをポーリングするのではなく、メッセージの送出を待ってポーリングするように変更しただけである。
【００６２】
今度は、図６の説明に戻り、ＳＮＭＰ装置及びディレクトリプロキシ２９における変更について説明する。図７に関して上述したように、ディレクトリプロキシ２９の始動時に、ディスカバリモジュール６１は、ネットワーク上の全装置に関する情報を取得し、この情報は、ディレクトリプロキシ２９を介してＬＤＡＰクライアント６０向けに処理される。ＬＤＡＰクライアント６０は、ディレクトリサーバ２５においてＬＤＡＰ＿ＡＤＤ処理を行なうことを試みるが、ディレクトリサーバにＳＮＭＰ装置に対するエントリが既に存在する場合は、エラーメッセージを受信する。ＬＤＡＰクライアント６０は、ＬＤＡＰ＿ＭＯＤＩＦＹコマンドを実行し、ディレクトリサーバにおけるＳＮＭＰ装置のディレクトリエントリを置換する（ステップＳ６０１）。ＬＤＡＰクライアント６０は、追加又は変更があった全てのＳＮＭＰ装置に対してソースフラグを１に設定する。ディレクトリサーバにおいて変更を行なう際、通知プラグイン２６が呼び出される（ステップＳ６０２）。ステップＳ６０３で、通知プラグイン２６が、ソースフラグが１に設定されていると判定した場合、処理はステップＳ６０４に進む。ステップＳ６０４では、通知プラグインは、ソースフラグを０にリセットし、処理を終了する。
【００６３】
次に、プリンタ１６などのＳＮＭＰ装置のＩＰアドレスが、装置自体において変更される場合について説明する。ディレクトリプロキシが始動されており、監視／ポーリングモジュール６２は、更新を調べるためにネットワークのポーリングを行なっている最中であるとする。管理者が、プリンタ１６においてプリンタのＩＰアドレスを変更する。プリンタ１６に対して変更が行なわれた後、モジュール６２のポーリング処理により、ネットワーク上に更新問い合わせメッセージが送出される。プリンタ１６の構成が更新されているので、プリンタ１６は、更新情報応答メッセージを伴って応答する。続いて、モジュール６２は、更新された情報に対する要求をプリンタ１６に送信し、プリンタ１６は、モジュール６２に更新された情報を送信する。モジュール６２は、この更新された情報をＳＮＭＰクライアント６３に送信し、ＳＮＭＰクライアント６３は、情報をＬＤＡＰ／ＳＮＭＰ変換器６４に送信する。ＬＤＡＰ／ＳＮＭＰ変換器６４は、情報をＳＮＭＰ形式からＬＤＡＰ形式に変換し、ＬＤＡＰ形式の情報をＬＤＡＰクライアント６０に送信する。ＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立し、ディレクトリサーバ２５において変更を行ない、ソースフラグを１に設定する（ステップＳ６０１）。続いて、通知プラグイン２６が呼び出される（ステップＳ６０２）。ステップＳ６０３で、通知プラグイン２６は、ソースフラグが１に設定されていると判定し、それにより、処理はステップＳ６０４に進む。ステップＳ６０４では、通知プラグイン２６は、ソースフラグを０にリセットし、処理は終了する。
【００６４】
従って、ＳＮＭＰ使用可能装置の構成は、装置自体において変更され、この変更は、ディレクトリプロキシが更新された情報を調べるためにポーリングを行なうことによって検出される。変更は、ディレクトリプロキシのＬＤＡＰクライアントによりディレクトリサーバにおいて行なわれる。クライアントワークステーション１３のＬＤＡＰクライアントアプリケーションを使用して、ディレクトリサーバにおいてＳＮＭＰ使用可能装置（プリンタ１６）のＩＰアドレスに対する変更が行われる場合について説明する。
【００６５】
プリンタ１６に対するＩＰアドレスは、埋込み型ＬＤＡＰクライアントプリンタ１４に対してＩＰアドレスの変更が行なわれた場合に関して上述したのと同様の方法で、ワークステーション１３のＬＤＡＰクライアントを使用してディレクトリサーバ２５において変更される。従って、ディレクトリサーバにおいて変更が行なわれ、ソースフラグが０に設定される（ステップＳ６０１）場合についての説明は、ここでは繰り返さない。
【００６６】
プリンタ１６に対するＩＰアドレスの変更が、一度ディレクトリサーバにおいて行われると、通知プラグイン２６が呼び出される（ステップＳ６０２）。続いて、ステップＳ６０３で、通知プラグイン２６は、フラグがステップＳ６０１で０に設定されたと判定し、装置に変更を通知する必要があると認識する。処理はステップＳ６０５に進む。ステップＳ６０５では、通知プラグイン２６は、プリンタ１６に対するディレクトリエントリからプリンタ１６がＳＮＭＰ使用可能装置であって埋込み型ＬＤＡＰクライアントを含まないと判定する。従って、処理は、ステップＳ６０９に進み、通知プラグイン２６は、ディレクトリサーバで行われた変更処理の種類により、マルチキャストプラグイン４０から４３のうちの１つを呼び出す。ここでは、ディレクトリサーバ２５で変更処理が行われたので、ＭＯＤＩＦＹ（変更）プラグイン４２が呼び出される。ＭＯＤＩＦＹプラグイン４２は、情報パケットを生成し、マルチキャストグループ４７にこのパケットをマルチキャストする。マルチキャストグループ４７の全ての登録メンバーは、情報パケットを受信する。ここで、ディレクトリプロキシ２９及び場合によってはネットワーク上のその他のディレクトリプロキシは、マルチキャストグループ４７のメンバーとして登録されているので、マルチキャストプラグインから情報パケットを受信する（ステップＳ６１０）。ディレクトリプロキシ２９は、ディレクトリサーバ２５において行われた変更に関するマルチキャストメッセージを調べるためにネットワークを監視しても良い。マルチキャストメッセージは、通常、変更が行なわれたという情報とディレクトリエントリが変更されたディレクトリエントリ識別情報とを含む。
【００６７】
マルチキャストメッセージを受信すると、ディレクトリプロキシ２９のＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立し、更新されたディレクトリエントリを読み出す（ステップＳ６１０）。更新された情報を取得すると、ＬＤＡＰクライアント６０は、その情報をＬＤＡＰ／ＳＮＭＰ変換器６４に送信する。ＬＤＡＰ／ＳＮＭＰ変換器６４では、更新された情報がＳＮＭＰ形式に変換され、ＳＮＭＰクライアント６３に送信される（ステップＳ６１１）。ＳＮＭＰクライアント６３は、更新された情報をプリンタ１６に送信し（ステップＳ６１１）、プリンタ１６のＭＩＢに新規のＩＰアドレスが設定される。
【００６８】
従って、上述したように、ネットワーク上のＳＮＭＰ装置の構成における変更は、ディレクトリサーバにおいて行われ、ディレクトリサーバ通知プラグインは、マルチキャストプラグインを呼び出す。マルチキャストプラグインは、マルチキャストメッセージを送出し、このメッセージはディレクトリプロキシにより受信される。ディレクトリプロキシのＬＤＡＰクライアントは、ディレクトリサーバと通信し、更新された情報を読み出し、ディレクトリプロキシの変換器にこれを送信する。変換器は、この情報をＬＤＡＰ形式からＳＮＭＰ形式に変換し、ディレクトリプロキシのＳＮＭＰクライアントに送信する。ＳＮＭＰクライアントは、この情報をＳＮＭＰ装置に送信し、この新規の情報は、ＳＮＭＰ装置において更新される。
【００６９】
第３のシナリオにおいて、すなわち、プリンタ１５などのハイブリッドＳＮＭＰ使用可能且つＬＤＡＰ使用可能装置に関しては、２つの例が説明される。一方は、変更がディレクトリサーバにおいて開始される場合であり、他方は、装置自体において変更が開始される場合である。
【００７０】
図２に関して先に説明したように、ハイブリッド装置は、ＬＤＡＰを介して直接ディレクトリサーバとの通信を行なうが、ディレクトリプロキシ（ＳＮＭＰ）を介しても通信を行なう。従って、ハイブリッド装置における通信の流れは、同時に行われる並行プロセス（ＬＤＡＰ及びＳＮＭＰ）を含んでも良い。例えば、プリンタ１５が最初にネットワークに接続されたディスカバリモードの間、ディレクトリプロキシの始動の間、又はディスカバリモジュール６１の新規の装置を調べるための定期的なポーリング処理の間に、プリンタ１５は、ＬＤＡＰ及びＳＮＭＰの２つの通信プロトコルを介してディレクトリサーバとの通信を行なうことを試みても良い。本シナリオでは、両プロトコルは、並行プロセスを行ない、新規の装置に対して同時にディレクトリサーバへのエントリを作成することを試みる。
【００７１】
例えば、プリンタ１５が埋込み型ＬＤＡＰクライアントを含み、プリンタ１５がネットワークに接続された時にこの埋込み型ＬＤＡＰクライアントがディレクトリサーバ２５との通信を確立するようにし、プリンタ１５に対する新規のディレクトリエントリを作成することを試みても良い。しかしながら、プリンタ１５は、ＳＮＭＰを介してディレクトリプロキシ２９とも通信を行なうので、新規の装置がネットワークに接続された場合、ディレクトリプロキシ２９のディスカバリモジュール６１が新規の装置を検出し、図７に関して上述したように装置のＳＮＭＰ情報を取得する。続いて、ディレクトリプロキシ２９のＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立し、プリンタ１５に対する新規のディレクトリエントリを作成することを試みる。
【００７２】
並行プロセス、すなわち、ＬＤＡＰ及びＳＮＭＰの両方のプロセスが行われる本シナリオでは、最初にディレクトリサーバとの通信を確立するプロセスは、ＡＤＤ（作成）処理を行なうプロセスであり、他方のプロセスは、後述するように通知プラグイン論理により管理される。すなわち、ディレクトリサーバの通知プラグインは、ハイブリッド装置の管理を制御する。従って、プリンタ１５の埋込み型ＬＤＡＰクライアントが、最初にディレクトリサーバ２５との通信を確立する場合、ディレクトリサーバ２５においてプリンタ１５に対する新規のエントリを発行する。次に、ＬＤＡＰクライアント６０が、ディレクトリサーバ２５との通信を確立し、ＬＤＡＰ＿ＡＤＤ処理を実行することを試みる場合、プリンタ１５の埋込み型ＬＤＡＰクライアントは、既にディレクトリエントリを作成しているので、エラーメッセージを受信する。従って、ＬＤＡＰクライアント６０は、ＬＤＡＰ＿ＭＯＤＩＦＹ処理を行なってディレクトリエントリを変更する。ディレクトリサーバ２５の通知プラグインはソースフラグが１に設定されていることを確認し、プリンタ１５に対してディレクトリプロキシ２９による変更を通知するための更なる処理を行なわない。
【００７３】
しかしながら、ディレクトリプロキシ２９のＬＤＡＰクライアント６０が、最初にディレクトリサーバ２５との通信を確立する場合、プリンタ１５に対する新規のディレクトリエントリを作成する。続いて、プリンタ１５の埋込み型ＬＤＡＰクライアントが、ディレクトリサーバ２５との通信を確立する場合、変更を行なった後、通知プラグインがソースフラグが１であることを確認する。従って、装置に変更を通知するための更なる処理を行なわない。
【００７４】
ハイブリッドプリンタ１５の構成における変更は、上述したように、クライアントワークステーション１３のＬＤＡＰクライアント又はサーバ１１のネイティブアプリケーションプログラムを使用して、ディレクトリサーバ２５のディレクトリエントリに対して行われても良い。ワークステーション１３のＬＤＡＰクライアント又はネイティブアプリケーションプログラムを使用して、プリンタ１５の構成における変更を行なうプロセスは、埋込み型ＬＤＡＰクライアントプリンタ及びＳＮＭＰプリンタに関して上述したのと同様である。従って、このプロセスは、ここでは繰り返さない。ステップＳ６０１で、ディレクトリサーバ２５のディレクトリエントリにおいて変更が行なわれる場合、ソースフラグは０に設定され、通知プラグイン２６が呼び出される（ステップＳ６０２）。通知プラグイン２６は、ステップＳ６０３で、ソースフラグが０に設定されていると判定し、ステップＳ６０５で、ディレクトリエントリを参照することによりプリンタ１５がＬＤＡＰ使用可能であると判定する。通知プラグイン２６は、プリンタ１５がＬＤＡＰ使用可能であることを検出するので、通知プラグイン２６は、プリンタ１５の埋込み型ＬＤＡＰクライアントにメッセージをユニキャストする（ステップＳ６０６）。以降のプロセスは、プリンタ１４の埋込み型ＬＤＡＰクライアントがディレクトリサーバ２５との通信を確立し、変更された情報を読み出し（ステップＳ６０７）、埋込み型ＬＤＡＰクライアントが、プリンタ１５において変更を行なう（ステップＳ６０８）点で、上述のプリンタ１４に対するプロセスと同様である。
【００７５】
しかしながら、プリンタ１５は、ハイブリッド装置であるので、プリンタ１５の構成における変更が埋込み型ＬＤＡＰクライアントにより一度行なわれると、ディレクトリプロキシ２９は、監視／ポーリングモジュール６２を介して変更を検出する。変更を検出すると、モジュール６２は、上述のように動作して、更新された情報をプリンタ１５から取得し、この更新された情報は、ディレクトリプロキシ２９を介してＬＤＡＰクライアント６０向けに処理される。ディレクトリプロキシ２９のＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立するが、ディレクトリエントリを更新することもある。ここで、ディレクトリプロキシ２９は、ＬＤＡＰ使用可能装置を認識し、これらの装置に対する更なる処理を行なわないように構成されても良い。すなわち、ディレクトリプロキシが装置がハイブリッド装置であると認識する場合、ハイブリッド装置における変更を検出した時に、ＬＤＡＰクライアントがこの変更を処理し、ディレクトリプロキシが変更を行なわないように構成されても良い。一方、ディレクトリプロキシ２９は、既にＬＤＡＰクライアントによりディレクトリエントリが作成されていても、それを上書きしても良い。この場合、変更が行われた際に、ディレクトリプロキシによりソースフラグが１に設定される。通知プラグイン２６が、ソースフラグが１に設定されていることを確認すると、処理はステップＳ６０４に進み、通知プラグイン２６は、ソースフラグを０に設定し、通知プロセスは終了する。
【００７６】
プリンタ１５の構成における更新は、プリンタ１５自体において行われても良い。この場合、埋込み型ＬＤＡＰクライアント装置における更新に関して上述されたのと同様に、更新が行なわれる。上述のように、埋込み型ＬＤＡＰクライアントは、ディレクトリサーバとの通信を確立し、ＬＤＡＰクライアントは、ディレクトリエントリにおける変更を自ら発行する。ディレクトリサーバに対する変更を行なうと、埋込み型ＬＤＡＰクライアントは、ソースフラグを１に設定する。続いて、ステップＳ６０２で、通知プラグイン２６が呼び出される。ステップＳ６０３では、通知プラグイン２６は、ソースフラグが１に設定されていると判定し、処理は、ステップＳ６０４に進む。ステップＳ６０４では、プラグインはフラグを０にリセットし、通知プロセスは終了する。
【００７７】
プリンタ１５において、埋込み型ＬＤＡＰクライアントを使用して変更が行なわれた場合、ディレクトリプロキシ２９の監視／ポーリングモジュール６２が、変更を検出し、変更された情報を取得する。変更された情報は、ディレクトリプロキシ２９を介してＬＤＡＰクライアント６０向けに処理される。ディレクトリプロキシ２９は、ＬＤＡＰ使用可能装置における変更を無視するように構成されても良い。しかしながら、ディレクトリプロキシ２９が変更を処理する場合、ＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立し、再び変更を発行し、ソースフラグを１に設定する。通知プラグイン２６が呼び出され（ステップＳ６０２）、ソースフラグが１に設定されていることを検出する（ステップＳ６０３）。従って、通知プラグイン２６は、ソースフラグを０にリセットし、処理は終了する（ステップＳ６０４）。
【００７８】
従って、ハイブリッド装置に関して、装置において行われた変更は、埋込み型ＬＤＡＰクライアントを介してディレクトリサーバに送信される。場合によっては、ディレクトリプロキシが埋込み型ＬＤＡＰクライアントにより行われた変更を検出し、再び変更を行なう。ディレクトリプロキシが変更を検出するが、装置がＬＤＡＰ使用可能であると判定し、ＬＤＡＰクライアントがこの変更を処理できるようにする場合もある。ディレクトリサーバにおいて行なわれた変更に関して、この変更は、埋込み型ＬＤＡＰクライアントを介してハイブリッド装置に送信される。ディレクトリプロキシは、変更を検出し、ＬＤＡＰクライアントが、この変更を処理するか、あるいは、再びこの変更を実行することを可能にする。
【００７９】
本発明は、特定の例示的な実施形態に関して説明を行なってきた。本発明がこの上述の実施形態に限定されるものではなく、本発明の趣旨から逸脱することなく、種々の変更及び修正が行われても良いことは、当業者には理解されるべきである。
【図面の簡単な説明】
【図１】本発明を適用可能なネットワークシステムを示す図である。
【図２】図１のネットワーク上の各装置間での通信のアーキテクチャを示す図である。
【図３】図１に示すサーバの内部アーキテクチャを示す図である。
【図４】プラグインを使用するディレクトリサーバのアーキテクチャを示す図である。
【図５】ディレクトリプロキシの内部アーキテクチャのより詳細な構成及びネットワーク上の種々の装置との通信を示す図である。
【図６】図１のネットワーク上の装置の構成に対する変更の管理のためのプロセスステップのフローチャートである。
【図７】ディレクトリプロキシのディスカバリモジュールに対するプロセスステップのフローチャートである。
【図８】ディレクトリプロキシの監視／ポーリングモジュールに対するプロセスステップのフローチャートである。
［発明の分野］
本発明は、ネットワーク化企業の各装置を監視・管理するディレクトリ使用可能サーバの使用に関し、特に、ディレクトリ使用可能サーバネットワーク管理方法にレガシー装置を組み込むためのレガシー装置を検出し且つレガシー装置とインタフェースするＬＤＡＰディレクトリプロキシの使用に関する。
【０００２】
［関連技術の説明］
通常、コンピューティングネットワーク環境は、ワークステーション及びサーバなどの多数の計算機装置と、プリンタ及びスキャナなどのその他のネットワーク装置とから構成される。ネットワークで接続された環境において、これらの多数の計算機装置及びネットワーク装置の保守及び管理を行なうには、ネットワーク管理者は非常に多くの時間及び労力を必要とする。例えば、ネットワーク管理者は、通常、サーバのドメイン名及びネットワーク装置に対応するＩＰ（インターネットプロトコル）アドレスなどの適切なネットワーク情報を設定することによって、各ネットワーク装置をネットワークに統合するように構成する。また、ネットワーク管理者は、各ネットワーク装置の機能及びネットワークで接続された環境において各ネットワーク装置に求められる機能性に従って、各ネットワーク装置を構成する。
【０００３】
自動的にローカルな周辺装置を認識・構成することができるプラグ＆プレイ機能を備えたオペレーティングシステムを有する単純なパソコンとは異なり、ネットワークで接続された環境では、ネットワーク管理者は、通常、ネットワークに新規の装置が追加される度に、接続・構成を手動で行なう必要がある。また、新規のネットワーク装置が接続されたり、既存のネットワーク装置がネットワーク内で移動させられたりするため、ネットワーク構成は頻繁に変更される可能性がある。更に、ネットワークのユーザの要望に応じて、あるネットワーク装置のネットワークアクセス可能な機能性を変更するために、ネットワーク管理者は、そのネットワーク装置を再構成する必要が生じるかもしれない。例えば、ソートは時間のかかる処理であるので、プリンタがオフィスの多忙な区域に設置されている場合、ネットワーク管理者によりネットワークプリンタのソート機能が、最初から無効にされていることもある。その後、プリンタがソートを必要とするオフィスのそれほど多忙でない場所に移された場合、ネットワーク管理者は、ソート機能をサポートするためにそのネットワークプリンタを再構成（reconfigure）する必要が生じるであろう。また、ネットワークプリンタに封筒用のフィーダを設置する場合など、ネットワーク装置に新しいオプションが設置される場合にも、ネットワーク装置は再構成される。従って、ネットワーク上のネットワーク装置の台数が増加するにつれて、ネットワーク管理者が、そのネットワーク上の各ネットワーク装置の構成・保守に要する労力のレベルが飛躍的に上昇することは、理解できよう。
【０００４】
ネットワーク管理者による各ネットワーク装置の管理は、そのネットワーク装置の設置場所でローカルに行われることが多い。従来の管理技法の１つでは、ネットワーク管理者は、フロントパネル及び／又はキーパッドなどのネットワーク装置のユーザインタフェースからそのネットワーク装置のネットワーク設定及び機能を入力及び／又は選択する。別の周知の管理技法では、ネットワーク管理者は、ネットワーク装置に対するネットワーク設定及び機能を入力・選択するために、特定のネットワーク装置に対してリモートアクセスを行なう標準化されたネットワーク管理ツールを使用する。例えば、ネットワーク管理者は、ネットワークプリンタのＩＰアドレス、あるいは、ソートなどの機能オプションの１つを変更するために、集中型ＳＮＭＰツールを使用してＳＮＭＰプロトコルを介してネットワークプリンタへのリモートアクセスを行なっても良い。
【０００５】
ネットワーク管理者が、ネットワーク装置に対して、その設定及び機能をローカルで入力するか、あるいは、リモートで入力するかに関わらず、ネットワーク装置の選択された設定及び機能は、通常、ネットワーク管理者がネットワークサーバのネットワーク構成ファイルなどの集中化したネットワーク位置に入力し、ネットワーク上の他のネットワーク装置によるアクセスを可能とするために、このネットワーク設定及び機能は公表される。
【０００６】
このようにして、他のネットワーク装置は、各特定のネットワーク装置が有する共有のネットワーク機能性を認識し、利用することができる。言うまでもなく、ネットワーク装置の構成された設定及び機能が、ネットワーク装置の公表された設定及び機能に実際に対応しない場合、問題が生じるのは理解されるだろう。あるネットワーク装置の公表されたＩＰアドレスが、そのネットワーク装置に設定された実際のＩＰアドレスと一致しない場合、他のネットワーク装置は、ネットワークを介してそのネットワーク装置にアクセスしたり、装置を利用したりすることができない。
【０００７】
また、ワークステーションのユーザは、ネットワークプリンタが実際は標準のレターサイズの用紙での印刷のみをサポートする場合に、ネットワークプリンタの公表された機能からプリンタがリーガルサイズの用紙での印刷をサポートすることを読み取り、リーガルサイズの用紙を必要とする印刷ジョブのネットワークプリンタへの送信を試みる可能性がある。従って、各ネットワーク装置を構成し且つ集中化したネットワーク位置に各ネットワーク装置の構成された設定及び機能を入力する詳細且つ重複的なネットワーク管理タスクは、膨大なものとなる可能性があり、結果として、集中化したネットワーク位置のデータと対応するネットワーク装置の実際の構成との間で同期化エラーが生じる可能性がある。このような不一致の生じる頻度は、ネットワーク上にネットワーク装置が多数存在する場合、飛躍的に増加することは理解できよう。
【０００８】
前述の管理上の問題に対する１つの解決法は、ネットワーク化企業（network enterprize）でのネットワーク装置の保守・管理を行なうためにディレクトリサーバを使用する最近の傾向に表れている。このようなディレクトリ使用可能管理ツール(directory-enabled management tool)は、ネットワーク化企業の各ネットワーク装置に対応する選択されたネットワーク設定及び機能を記憶・保守するための集中化したネットワーク位置に対するディレクトリ構造を使用する。個々の登録又は登録事項（エントリ）は、各ネットワーク装置に関連する前述の情報を含むために、ディレクトリ構造内に設けられる。エントリは、階層方式のディレクトリ構造において編成され、このディレクトリ構造は、各種のネットワーク装置に対して個別の枝を有する。例えば、ディレクトリ構造は、ネットワークプリンタに対する枝（branch）、ネットワークコンピュータに対する枝及びその他の種類のネットワーク装置に対する枝を有し、ネットワークプリンタに対する枝は、インクジェットプリンタに対する下位枝、レーザプリンタに対する下位枝及びドットマトリックスプリンタに対する下位枝を有する。インクジェットプリンタに対する下位枝は、ネットワーク上のインクジェットプリンタの各々に対応する選択された設定及び機能を記憶するための複数のエントリを有する。
【０００９】
標準化された構成又は体系（スキーマ）を使用してディレクトリ構造内の各エントリに対する形式を定義し、それにより、各ネットワーク装置のネットワーク設定及び機能を含むための一定の形式を提供するのが好ましい。このようにして、ディレクトリ使用可能サーバ上に常駐するディレクトリ構造は、他の全てのネットワーク装置によるアクセスを可能とするために、各ネットワーク装置のネットワーク設定及び機能が公表される集中化された位置を提供する。このようなディレクトリ使用可能サーバへのアクセスは、通常、ディレクトリ構造に／から入出力される情報を効率的に公表・検索するためのある種類の標準化されたディレクトリプロトコルを介して実現される。このようなプロトコルの例として、Ｘ．５００ディレクトリアクセスプロトコル及びそれに関連する軽量プロトコルであるＬＤＡＰ（Lightweight Directory Access Protocol）がある。ネットワーク化企業におけるネットワーク装置の保守・管理を行なうためにこのようなディレクトリ使用可能サーバを使用する場合、ネットワーク管理者などのユーザが、ディレクトリ使用可能サーバのディレクトリ構造における情報をアクセス・修正するためのインタフェースを提供するディレクトリ使用可能管理ツールと結合させると、非常に効率の良いネットワーク管理方法を提供することができる。ＬＤＡＰは、通常、生成するネットワークトラフィックがＸ．５００よりも少ないので、このようなディレクトリ使用可能管理方法は、ディレクトリ使用可能サーバでの通信プロトコルとして、Ｘ．５００よりもＬＤＡＰを使用するのが好ましい。
【００１０】
ディレクトリ使用可能ネットワーク管理方法を使用することにより、ネットワーク化企業の全てのネットワーク装置のネットワーク管理に必要な時間を大幅に削減し、複雑な管理を大幅に単純化することができる。例えば、ディレクトリ使用可能管理ツールは、ディレクトリ使用可能サーバのディレクトリ構造内のエントリを大規模に管理・変更するために、複雑な問い合わせ、バッチモード処理及び汎用エントリ変更などの標準ディレクトリ機能を使用することができる。従って、ディレクトリ使用可能サーバを有するネットワーク化企業におけるネットワーク装置は、ディレクトリ使用可能管理ツールなどのディレクトリ使用可能クライアントを用いてディレクトリ使用可能サーバにアクセスすることによって、ネットワーク上のいずれの場所にあっても、集中的に管理・アクセスすることができる。
【００１１】
例えば、ネットワーク管理者は、インターネットを介して遠隔の場所からディレクトリ問い合わせ及び変更コマンドを通じて共通のグループのネットワーク装置へのアクセス及び変更を効率的に行なうことができる。このようなネットワーク管理機能は、大規模なネットワーク環境でのネットワーク管理の効率を大幅に高めることができることは理解されるだろう。また、ディレクトリ使用可能ネットワーク管理方法は、インターネットなどのより規模の大きいネットワーク化企業のネットワーク装置の機能の拡張を提供する。従って、大規模なネットワーク化企業が、各特定のネットワークのドメイン内でネットワーク化企業を管理するために、ネットワーク化企業全体を構成する種々のネットワーク間に分散する数台のディレクトリ使用可能サーバを有しても良いことは理解されるだろう。
【００１２】
ディレクトリ使用可能サーバをネットワーク管理のために使用する傾向は、ＤＭＴＦ（Desktop Management Task Force）、ＤＥＮ（Directory Enabled Network）イニシアチブ及びＣＩＭ（Common Information Model）イニシアチブの努力に反映されている。これらの努力は、ネットワーク上のネットワーク装置の管理を行なうためにディレクトリ構造を使用する幅広い構想及びディレクトリ使用可能サーバのデータ構造内でネットワーク上のネットワーク構成要素を表すための共通のデータ形式の作成に対して集中的に行われてきた。しかしながら、ＤＭＴＦ、ＤＥＮイニシアチブ及びＣＩＭイニシアチブは、ネットワーク化企業でネットワーク装置を管理するためのディレクトリ構造の実現に関連する諸問題の解決法を提供してはいない。具体的には、各ネットワーク装置に関連する情報のディレクトリ構造への入力及びディレクトリ構造での保守を行なう方法に関して、ネットワーク装置の管理のためのディレクトリ使用可能サーバの使用は、ネットワーク管理に対する従来のアプローチと同様の問題を提起する。ネットワーク管理者がディレクトリ構造内の各ネットワーク装置に関連する情報を入力・更新するのに必要な労力を軽減することが望ましい。従って、各ネットワーク装置に対応するディレクトリ構造へのエントリの効率的な公表を行なうためのメカニズムを提供するディレクトリ使用可能ネットワーク管理方法が必要である。
【００１３】
また、ネットワーク装置の実際のネットワーク設定及び機能とネットワーク装置に対応するデータ構造のエントリにおいて公表されるネットワーク設定及び機能との間に不一致が生じる場合、ディレクトリ使用可能ネットワーク管理方法の使用は問題を生じる。これらの不一致が生じるのは、ネットワーク装置のネットワーク設定及び機能に対する変更が、従来のＳＮＭＰネットワーク管理ツールを介して手動で行われるか、あるいは、ネットワーク管理者などのユーザによりディレクトリ構造中のエントリに対して直接行われるためである。従って、設定に対する変更が行なわれたか否かに関わらず、ディレクトリ構造のエントリにおいて公表されるネットワーク設定及び機能とネットワーク装置自体のネットワーク設定及び機能との確実な同期化を提供するディレクトリ使用可能管理方法の実現が必要とされる。
【００１４】
最後に、ディレクトリ使用可能ネットワーク管理方法の実現は、通常、ネットワーク化企業における全てのネットワーク装置が、ディレクトリ使用可能サーバをサポートするためにディレクトリ使用可能であることを想定する。この想定を正しいものとするためには、ディレクトリ使用可能管理機能をサポートする目的で、各ネットワーク装置は、ＬＤＡＰなどの選択されたディレクトリプロトコルを介して通信を行なう機能を有する必要があり、また、適切な論理を有する必要がある。このようなネットワーク管理方法は、ＬＤＡＰなどのディレクトリプロトコルを使用して通信する機能を持たず、このようなディレクトリ使用可能ネットワーク管理機能をサポートするために組み込まれる論理を持たないレガシーネットワーク装置を現在では多数使用することを考慮に入れていない。これらのレガシー装置が、今後とも長期にわたり使用されるものとすると、ディレクトリ使用可能ネットワーク管理方法にとって、ディレクトリ使用可能ネットワーク装置とレガシー装置の両方を含む混成異種ネットワーク化企業にこのレガシー装置を収容することが好ましい。従って、前述の諸問題を解決するディレクトリ使用可能ネットワーク管理方法が望まれる。
【００１５】
［発明の概要］
本発明は、レガシー装置が自動的に検出され、各レガシーネットワーク装置の設定及び機能に関連する情報がＳＮＭＰなどのレガシープロトコルを使用することで得られるディレクトリ使用可能ネットワーク管理方法を提供することにより前述の問題に対処する。各レガシーネットワーク装置に対応する１組の情報は、データエントリにフォーマット化され、このデータエントリは、ＬＤＡＰなどのディレクトリ通信プロトコルを介してディレクトリサーバに転送される。本発明のディレクトリ使用可能ネットワーク管理方法は、ネットワーク装置とこれに対応するディレクトリエントリの両方における変更を監視することによって、各ネットワーク装置の設定及び機能とディレクトリサーバの対応するエントリとの同期化を実現する。このようにして、ネットワーク管理者がネットワーク装置を管理する際に要求される労力を軽減し、ディレクトリ使用可能ネットワーク装置とレガシーネットワーク装置の両方を有する異種ネットワーク化企業を管理するディレクトリ使用可能ネットワーク管理方法を提供する。
【００１６】
従って、本発明の１つの面の、ネットワーク装置及びディレクトリサーバに接続された通信装置は、第１の通信プロトコルを使用して、前記ネットワーク装置の存在を検出する検出手段と、前記検出手段により検出されたネットワーク装置から、当該ネットワーク装置に関する情報を取得する情報取得手段と、前記情報取得手段が取得した情報を、第２の通信プロトコルを使用して前記ディレクトリサーバに送信するための形式に変換する変換手段と、前記変換手段により変換された情報を、前記ディレクトリサーバにおいてディレクトリエントリとして管理させるために、前記第２の通信プロトコルを使用して前記ディレクトリサーバに送信する第１の送信手段とを備え、前記第１の送信手段は、前記変換手段により変換された情報毎に、当該変換された情報を含むエントリ作成メッセージを前記ディレクトリサーバに送信し、前記第１の送信手段が送信した前記エントリ作成メッセージに対して、ディレクトリエントリが既に存在することを示すエラーメッセージが前記ディレクトリサーバから返送されてきた場合に、前記第１の送信手段は、当該既に存在するディレクトリエントリを前記変換手段により変換された情報に変更するために、エントリ変更メッセージを前記ディレクトリサーバに送信することを特徴とする。
【００１７】
ディレクトリサーバと通信するために使用される通信プロトコルは、ＬＤＡＰであるのが好ましく、レガシーネットワーク装置と通信するための通信プロトコルは、ＳＮＭＰであるのが好ましい。また、検出されたネットワーク装置の各々からの情報ブロックは、印刷速度や用紙の種類などのネットワーク機能に加え、ＩＰアドレスなどのネットワーク設定データを含むのが好ましい。各ディレクトリエントリの形式は、各ディレクトリエントリ間の整合性を保つため、標準化されたスキーマであるのが好ましい。
【００１８】
前述の構成により、１つのネットワーク化企業でレガシーネットワーク装置とディレクトリ使用可能装置の両方をサポートするディレクトリ使用可能管理方法が提供される。このようにして、本発明では、ディレクトリ使用可能管理方法に含めるために、ＬＤＡＰサポートをレガシーネットワーク装置にまで拡張するディレクトリプロキシを提供する。また、同期化機能により各ネットワーク装置の設定及び機能と対応するディレクトリエントリで発行される設定及び機能との確実な整合性が提供される。
【００１９】
別の面において、本発明は、ネットワーク装置の管理方法であって、
第１の通信プロトコルを使用して、前記ネットワーク装置の存在を検出する検出工程と、
前記検出工程で検出されたネットワーク装置から、当該ネットワーク装置に関する情報を取得する情報取得工程と、
前記情報取得工程で取得された情報を、第２の通信プロトコルを使用してディレクトリサーバに送信するための形式に変換する変換工程と、
前記変換工程で変換された情報を、前記ディレクトリサーバにおいてディレクトリエントリとして管理させるために、前記第２の通信プロトコルを使用して前記ディレクトリサーバに送信する送信工程とを備え、
前記送信工程では、前記変換工程により変換された情報毎に、当該変換された情報を含むエントリ作成メッセージを前記ディレクトリサーバに送信し、
前記送信工程で送信した前記エントリ作成メッセージに対して、ディレクトリエントリが既に存在することを示すエラーメッセージが前記ディレクトリサーバから返送されてきた場合に、当該既に存在するディレクトリエントリを前記変換工程により変換された情報に変更するために、エントリ変更メッセージを前記ディレクトリサーバに送信することを特徴とする。この管理方法は、第１の通信プロトコルを使用することによって、検出されたネットワーク装置の各々においてネットワーク装置の情報ブロック中の情報の更新を監視することと、検出されたネットワーク装置のうちの１台の情報ブロック中の情報が更新された場合、第１の通信プロトコルを使用することによって、対応するネットワーク装置から情報ブロックの更新された情報を取得することと、対応するネットワーク装置に対するディレクトリエントリへの配置を行なうために、第２の通信プロトコルを使用することによって、ディレクトリサーバに更新された情報を送信することとを更に含む。また、管理方法は、第３の通信プロトコルを使用することによって、ディレクトリサーバからのディレクトリサーバにおいてディレクトリエントリが更新されたことを示す更新メッセージの発行を監視することと、更新メッセージが発行された場合、第２の通信プロトコルを使用することによって、ディレクトリサーバから更新されたディレクトリエントリを取得することと、更新されたディレクトリエントリから更新されたデータを抽出することと、対応するネットワーク装置の情報ブロックへの配置を行なうために、更新されたディレクトリエントリに対応するネットワーク装置に更新されたデータを送信することとを含む。
【００２０】
ディレクトリサーバと通信するために使用される通信プロトコルは、ＬＤＡＰであるのが好ましく、レガシーネットワーク装置と通信するための通信プロトコルは、ＳＮＭＰであるのが好ましい。また、検出されたネットワーク装置の各々からの情報ブロックは、印刷速度や用紙の種類などのネットワーク機能に加え、ＩＰアドレスなどのネットワーク設定データを含むのが好ましい。各ディレクトリエントリの形式は、各ディレクトリエントリ間の整合性を保つため、標準化されたスキーマであるのが好ましい。更に、検出されたネットワーク装置における更新された情報の監視は、頻繁に行われるのが好ましい。最後に、ディレクトリサーバからの更新メッセージの発行は、標準ＩＰプロトコルを使用して更新メッセージを発行するディレクトリプラグインにより提供されるのが好ましい。
【００２１】
前述の構成により、１つのネットワーク化企業でレガシーネットワーク装置とディレクトリ使用可能装置の両方をサポートするディレクトリ使用可能ネットワーク管理方法が提供される。このようにして、本発明では、ディレクトリ使用可能管理方法に含めるために、ＬＤＡＰサポートをレガシーネットワーク装置にまで拡張するディレクトリプロキシを提供する。また、同期化機能により各ネットワーク装置の設定及び機能と対応するディレクトリエントリで発行される設定及び機能との確実な整合性が提供される。
【００２２】
この概要は、本発明の性質の理解を速めるために提供されるものである。添付の図面と合せて以下の好適な実施形態の詳細な説明を参照することにより、本発明をより完全に理解することが可能となる。
【００２３】
［好適な実施形態の詳細な説明］
図１は、本発明が使用されるネットワーク環境を示している。図１で明らかなように、ネットワーク１０は、それぞれネットワーク１８に接続されたサーバ１１及び１２とクライアントワークステーション１３と周辺装置１４、１５、１６及び１７とを含む。ネットワーク接続１８は、構内通信網（ＬＡＮ）や広域網（ＷＡＮ）であっても良く、又は、その他の種類のネットワークであっても良い。言うまでもなく、本発明は、図１に示すネットワークに限定されるものではなく、その他の多数の装置がネットワーク環境に含まれても良い。例えば、ネットワーク１０は、ルータ、更なるコンピュータワークステーション、更なるサーバ及び追加の周辺装置を含んでも良い。事実上は、無限の台数の装置をネットワーク１０に含めることができる。図１は、簡潔にする目的で、含まれるであろう装置のうちの数台のみを示している。
【００２４】
クライアントワークステーション１３は、コンピュータワークステーションであるのが好ましく、例えば、ＩＢＭ互換機、Macintosh ＰＣ、ＵＮＩＸワークステーション、Sun MicroSystems社製ワークステーション又はその他の種類のワークステーションであっても良い。クライアントワークステーション１３は、ユーザがサーバ１１及び／又は１２のディレクトリサーバアプリケーションプログラムにアクセスし、このディレクトリサーバアプリケーション（以下、「ディレクトリサーバ」と呼ぶ）で変更を行なうことを可能にするＬＤＡＰクライアントアプリケーションプログラムを含むのが好ましい。ディレクトリサーバアプリケーションの例としては、Microsoft Active Directory Server、Netscape Directory Server及びNovell Directory Serverがある。言うまでもなく、これらは本発明を実施する際に使用されるディレクトリサーバアプリケーションプログラムのほんの一例に過ぎない。本発明は、これらの特定のアプリケーションに限定されるものではなく、いずれのディレクトリサーバアプリケーションを用いて実現されても良い。また、クライアントワークステーション１３は、ＴＣＰ／ＩＰプロトコルを利用して通信を行なうことができるのが好ましい。後述するように、ＴＣＰ／ＩＰは、ディレクトリサーバ内のプラグインによりマルチキャストされるマルチキャストメッセージを受信するために利用される。
【００２５】
クライアントワークステーション１３のＬＤＡＰクライアントアプリケーションプログラムは、サーバ１１及び１２で実行中のディレクトリサーバアプリケーションとネットワーク１８を介して通信する。クライアントワークステーション１３とサーバ１１及び１２のディレクトリサーバとの通信は、図３を参照しながら以下により詳細に説明する。また、ＬＤＡＰクライアントアプリケーションプログラムは、サーバ１１及び１２のディレクトリサーバのマルチキャストプラグインによりマルチキャストされるマルチキャストメッセージを受信して処理する。尚、クライアントワークステーション１３のＬＤＡＰクライアントアプリケーションは、ユーザがディレクトリサーバで変更を行なうことを許可するがマルチキャストプラグインからマルチキャストメッセージを受信することは許可しないか、マルチキャストプラグインからマルチキャストメッセージを受信することのみ許可するがディレクトリサーバで変更を行なうことは許可しないか、あるいは、ディレクトリサーバで変更を行なうことを許可しマルチキャストメッセージを受信することも許可するかのいずれかであるように構成されても良い。更に、クライアントワークステーション１３のＬＤＡＰクライアントアプリケーションは、ディレクトリサーバで変更を行なえるようにするために、サーバ１１及び１２のディレクトリサーバアプリケーションに対応する必要がない。すなわち、サーバ１１及び１２のディレクトリサーバアプリケーションがNetscape Directory Serverである場合、ユーザがディレクトリサーバで変更を行なえるようにするためにクライアントワークステーション１３のＬＤＡＰクライアントアプリケーションをNetscape Directory ServerのＬＤＡＰクライアントにする必要はない。ＬＤＡＰクライアントとディレクトリサーバとの通信は、ＬＤＡＰプロトコルを用いて行われているので、サーバ１１及び１２のNetscape Directory Serverで変更を行なう際には、いずれのＬＤＡＰクライアントアプリケーションもクライアントワークステーション１３において使用可能である。
【００２６】
クライアントワークステーション１３のＬＤＡＰクライアントアプリケーションは、サーバ１１及び１２のディレクトリサーバアプリケーションで変更を行なう唯一の方法ではない。変更は、サーバ１１及び１２自体のネイティブアプリケーションを介してサーバ１１及び１２のディレクトリサーバで行なうこともできる。また、変更は、ネットワーク上の装置内の埋込み型ＬＤＡＰクライアントによって、あるいは、ディレクトリプロキシを介して行なうことが可能であろう。従って、本発明では、クライアントワークステーション１３のＬＤＡＰクライアントアプリケーションにより変更が行なわれる必要がなく、本発明の目的は、ディレクトリサーバでの変更のために行われるネットワーク上の多種多様な装置とディレクトリサーバとの通信を管理することである。
【００２７】
周辺装置１４、１５、１６及び１７は、ネットワーク１０に含まれるいかなる種類の周辺装置であっても良い。すなわち、プリンタ、複写機、ＦＡＸ装置、ルータなどであっても良く、図１では、これらの装置をプリンタ及び複写機として示すが、これに限定されない。しかしながら、簡潔にする目的で、周辺装置１４、１５及び１６はプリンタとして説明され、周辺装置１７はネットワーク複写機として説明される。
【００２８】
種々のプリンタ及び複写機がネットワーク１０に含まれても良いことは、容易に理解できる。例えば、ネットワーク１０は、最新のネットワーク通信技術を含むプリンタと従来のネットワーク通信技術を含むプリンタとから構成されても良い。すなわち、プリンタの一部が、ディレクトリサーバと直接通信する能力を提供する最新技術を含んでも良い。この種のプリンタは、埋込み型ＬＤＡＰクライアントを含んでも良い。一方、ネットワーク上の別のプリンタは、ＳＮＭＰを介して通信し、ディレクトリサーバと直接通信する能力がないレガシープリンタなどの従来のプリンタであっても良い。この種のプリンタは、媒介装置がＬＤＡＰプロトコルを使用してディレクトリサーバと通信可能であることを必要とすることもある。更に、ネットワーク上のプリンタの一部は、ＬＤＡＰプロトコルを使用してディレクトリサーバと直接通信することが可能な埋込み型のＬＤＡＰクライアントとディレクトリサーバと通信するための媒介手段を必要とするＳＮＭＰクライアントとの両方を含むハイブリッド装置であっても良い。簡潔にする目的で、ネットワーク１０では、プリンタ１４は、ディレクトリサーバと直接通信する埋込み型ＬＤＡＰクライアントを含むプリンタであるとし、プリンタ１６及び複写機１７は、それぞれ、ＳＮＭＰを使用して通信を行なうレガシープリンタ及びレガシー複写機であるとし、プリンタ１５は、埋込み型ＬＤＡＰクライアントを含み且つＳＮＭＰを使用して通信を行なうハイブリッドプリンタであるとする。
【００２９】
図２は、各装置１３から１７と、例えば、サーバ１１のディレクトリサーバとの間の通信プロトコルのアーキテクチャを示す。図２で明らかなように、ディレクトリサーバ２５は、ＬＤＡＰプロトコルを使用して、ＬＤＡＰクライアント２７、埋込み型クライアント装置２８、ディレクトリプロキシ２９及びハイブリッド装置３１と通信を行なう。ＬＤＡＰクライアント２７は、例えば、クライアントワークステーション１３上で実行中の上述のＬＤＡＰクライアントアプリケーションであっても良い。従って、ＬＤＡＰクライアント２７は、ディレクトリサーバで変更を行なうために、ディレクトリサーバ２５と直接通信を行なう。埋込み型クライアント装置２８及びハイブリッド装置３１は、それぞれ、埋込み型ＬＤＡＰクライアントを含むプリンタ１４及び１５であっても良い。埋込み型ＬＤＡＰクライアント２８とハイブリッド装置３１との相違点の１つは、ハイブリッド装置３１がＳＮＭＰを介して通信を行なう能力も含むのに対し、埋込み型ＬＤＡＰクライアント２８は、ＬＤＡＰのみを介して通信を行なうことである。ディレクトリプロキシ２９は、ディレクトリサーバ２５で変更を行なうために、ＬＤＡＰを介してディレクトリサーバ２５と通信を行ない、ディレクトリサーバ２５に対して、ＳＭＮＰ装置３０とハイブリッド装置３１との間の媒体手段、すなわち、変換器として動作する。ディレクトリプロキシ２９に関しては、以下でより詳細に説明する。
【００３０】
ディレクトリサーバ２５は、プラグイン２６及び４０から４３も含む。プラグイン２６は、通知プラグインであり、詳細は以下で説明するが、簡単には、ディレクトリサーバ２５で変更が行なわれる度に呼び出されるものである。通知プラグインは、呼び出されると、ネットワーク上の適切な装置に変更を通知する通知プロセスの管理を行なう。例えば、通知プラグイン２６は、ネットワーク上のＬＤＡＰ使用可能装置にユニキャストメッセージを送出したり、あるいは、マルチキャストメッセージを送信するためにマルチキャストプラグイン（４０から４３）のうちの１つを呼び出したりする。マルチキャストプラグイン４０から４３は、通知プラグイン２６により呼び出されると、ディレクトリサーバ２５で行われた変更に関する情報パケットを生成し、そのパケットをマルチキャストＩＰアドレスに送信する。マルチキャスト処理及びユニキャスト処理は、以下でより詳細に説明する。
【００３１】
図３は、サーバ１１の内部アーキテクチャのより詳細な図を示す。サーバ１２は、サーバ１１に類似しているので、簡潔にする目的で、サーバ１１のみの説明を行なう。サーバ１１は、例えば、Compaq Prosigniaサーバ又はその他の種類のサーバであっても良い。しかしながら、サーバ１１は、それ自体がサーバである必要はなく、ディレクトリサーバアプリケーションプログラムを実行可能であればいかなるコンピュータであっても良い。図３に示すように、サーバ１１は、ネットワークインタフェース３５にインタフェースされる接続１９によりネットワーク１８に接続される。ネットワークインタフェース３５は、ネットワークを介してサーバ１１により情報の送受信を制御するネットワークカードであるのが好ましい。ネットワークインタフェース３５とインタフェースされるのが、ＴＣＰ／ＩＰレイヤ３６である。ＴＣＰ／ＩＰは、ユニキャスト処理及びマルチキャスト処理を行なうのに好適なプロトコルであるが、その他のプロトコルを代わりに使用することもできる。ＴＣＰ／ＩＰを使用したユニキャスト処理及びマルチキャスト処理の理解を深めるために、以下の点を考慮する。
【００３２】
通常、ＩＰアドレスには、１対１通信、ブロードキャスト及びマルチキャストの３つの異なるカテゴリが存在する。ここでは、１対１通信及びマルチキャストのみが関係するので、ブロードキャストの説明は省略する。１対１通信の場合、ある範囲のＩＰアドレスが割当てられ、ネットワーク上の各装置を明確に識別するのに使用される。例えば、図１に示すネットワークに接続された各装置は、ネットワーク上のその装置を識別する別々のＩＰアドレスを割当てられるであろう。各装置は、装置自体が保有するＩＰアドレスを手動で割当てられるか、あるいは、装置がネットワークに接続される度にアプリケーションプログラムにより自動的に割当てられる。従って、ユニキャスト処理を行なう場合、ディレクトリサーバプラグイン２６から情報パケットを受信する各装置のＩＰアドレスが、プラグイン構成でセットアップされる。ディレクトリサーバで変更が行なわれた後に、通知プラグインが情報パケットを生成する場合、通知プラグイン構成でセットアップされたネットワーク上の各装置にこのパケットを送信する。
【００３３】
マルチキャスト処理では、ある範囲のＩＰアドレスが割当てられるが、そのＩＰアドレスのうちの１つに送信されたメッセージは、その１つのＩＰアドレスで登録した複数のメンバーのみが受信する。１対１のＩＰアドレスとは異なり、マルチキャスト範囲のＩＰアドレスは、ある特定の装置に割当てられるものではない。これらのアドレスは、送られてきたメッセージを受信するマルチキャストグループを表す仮想のアドレスであり、受信したメッセージは、そのグループに登録したメンバーに配布される。従って、情報パケットは、ディレクトリサーバマルチキャストプラグインにより指定のマルチキャストグループにマルチキャストされ、グループの登録メンバーに配布される。
【００３４】
図３において、ＴＣＰ／ＩＰレイヤ３６にインタフェースされるのがＬＤＡＰプロトコルレイヤ３７である。ＬＤＡＰプロトコルレイヤ３７は、ＬＤＡＰクライアントとサーバ１１のディレクトリサーバ２５のようなディレクトリサーバとの通信を実現する。ＬＤＡＰプロトコルレイヤは、ディレクトリサーバ２５で変更を行なうＬＤＡＰクライアントが、クライアントワークステーション１３のＬＤＡＰクライアントであるか、埋込み型ＬＤＡＰクライアント２８又はハイブリッド装置３１の埋込み型クライアントであるか、ディレクトリプロキシ２９のＬＤＡＰクライアントであるかに関わらず、ディレクトリサーバ２５と通信するために使用される。従って、ＬＤＡＰプロトコルを使用することで、ＬＤＡＰクライアントは、ディレクトリサーバで変更を行なうことができる。
【００３５】
図４は、メッセージシステムのアーキテクチャ及びサーバ１１から少なくとも１つのマルチキャストグループのメンバーとして登録したクライアントへのマルチキャストメッセージの流れの一例を示す。図４は、マルチキャストするためのアーキテクチャのみを示し、ユニキャスト処理は、以下で詳細に説明される。図４のメッセージシステムは、ディレクトリサーバアプリケーションプログラムのプラグイン機能を使用するのが好ましい。すなわち、ディレクトリサーバで変更が行なわれ、通知プラグインがマルチキャストメッセージを送信すべきであると判定した場合、ディレクトリサーバは、マルチキャストプラグインを呼び出す。このマルチキャストプラグインは、情報パケットを生成し、マルチキャストグループにマルチキャストする。しかしながら、プラグインが必要な訳ではなく、マルチキャスト情報パケットを生成し、対応するマルチキャストグループにマルチキャストするその他の実現例を使用することもできるであろう。他の適用例に特有のプラグインも同様に実現されるが、ここでは、Netscape Directory Serverの一部としてサポートされるプラグインを説明する。
【００３６】
図４で明らかなように、Netscape Directory Server２５では、ＡＤＤ（作成）プラグイン４０、ＤＥＬＥＴＥ（削除）プラグイン４１、ＭＯＤＩＦＹ（変更）プラグイン４２及びＳＥＡＲＣＨ（検索）プラグイン４３の４種類のマルチキャストプラグインが実施される。Netscape Directory Serverによりサポートされるプラグインのうちの１種類は、処理後プラグインである。前述のディレクトリサーバ２５用のマルチキャストプラグインは、それぞれ、処理後プラグインとして実施されるのが好ましい。処理後プラグインは、処理が行なわれた後（すなわち、処理後）に適切なプラグインが呼び出される時のプラグインである。従って、ディレクトリサーバで変更が行なわれた場合、ディレクトリサーバは、行われた変更の種類に対応する適切なマルチキャストプラグインを呼び出す。すなわち、新規オブジェクトがディレクトリサーバで作成された場合、ディレクトリサーバは、ＡＤＤプラグインを呼び出す。ＡＤＤプラグインが呼び出された場合、ＡＤＤ変更に関する情報パケットを生成し、変更の種類に対応するマルチキャストグループにマルチキャストする。それにより、マルチキャストグループの登録メンバーは情報パケットを受信する。
【００３７】
マルチキャスト処理により情報パケットを送信するために、各プラグインに対応するマルチキャストアドレスが確立される。各マルチキャストプラグインは、情報パケットの送信先である対応するマルチキャストアドレスを有する。例えば、図４で明らかなように、ＡＤＤプラグイン４０は、ＡＤＤ情報マルチキャストパケットを受信するように指定されたマルチキャストグループ４５に情報パケットを送信する。同様に、ＤＥＬＥＴＥプラグイン４１は、対応するマルチキャストグループ４６、ＭＯＤＩＦＹプラグイン４２は、対応するマルチキャストグループ４７、ＳＥＡＲＣＨプラグイン４３は、対応するマルチキャストグループ４７をそれぞれ有する。前述のマルチキャストグループの各々に対するマルチキャストＩＰアドレスの例は、以下の通りである。
【００３８】
処理／マルチキャストグループ ＩＰアドレス
ＡＤＤ処理（マルチキャストグループ４５）： 225.6.7.8
ＤＥＬＥＴＥ処理（マルチキャストグループ４６）： 225.6.7.9
ＭＯＤＩＦＹ処理（マルチキャストグループ４７）： 225.6.7.10
ＳＥＡＲＣＨ処理（マルチキャストグループ４８）： 225.6.7.11
ＬＤＡＰクライアントによりディレクトリサーバで変更が行なわれた場合、通知プラグインは、必要に応じて適切なマルチキャストプラグインを呼び出す。それにより、マルチキャストプラグインは、情報パケットを生成し、ネットワークを介して対応するマルチキャストＩＰアドレスにマルチキャストする。
【００３９】
マルチキャストメッセージを受信するためには、メンバーは、受信を希望する変更情報パケットの種類に対応する各マルチキャストグループに登録する。例えば、図４で明らかなように、クライアント５０は、マルチキャストグループ４５及び４６のメンバーとして登録する。従って、クライアント５０は、ディレクトリサーバ２５で行われたＡＤＤ処理及びＤＥＬＥＴＥ処理に対応するマルチキャストメッセージを受信する。クライアント５１は、マルチキャストグループ４５、４６、４７及び４８に登録し、その結果、ディレクトリサーバ２５で行われるＡＤＤ処理、ＤＥＬＥＴＥ処理、ＭＯＤＩＦＹ処理及びＳＥＡＲＣＨ処理に関するマルチキャストメッセージを受信する。クライアント５２は、マルチキャストグループ４７及び４８のメンバーとして登録し、その結果、ディレクトリサーバ２５で行われるＭＯＤＩＦＹ処理及びＳＥＡＲＣＨ処理に関するマルチキャストメッセージのみを受信する。ここで、ディレクトリプロキシ２９は、前述の各マルチキャストグループのメンバーとして登録しても良い。
【００４０】
従って、上述のように、ＬＤＡＰクライアントは、ディレクトリサーバで変更を行なうためにディレクトリサーバとインタフェースし、このディレクトリサーバは、必要であれば行われた変更に対応するマルチキャストプラグインを呼び出す通知プラグインを呼び出す。マルチキャストプラグインは、処理後情報パケットを生成し、ネットワークを介して変更の種類に対応するマルチキャストグループにマルチキャストする。そのマルチキャストグループに登録したクライアントは、そのマルチキャストメッセージを受信する。
【００４１】
ユニキャスト処理を行なうためには、通知プラグイン２６は、ネットワーク上の特定のＬＤＡＰ使用可能装置で行われた変更処理に対して、適切な時に変更情報パケットを送信するように構成されるであろう。例えば、通知プラグイン２６は、ＬＤＡＰ使用可能装置のディレクトリ入力のため、変更がディレクトリサーバにより開始された場合、情報パケットを生成して装置にユニキャストするように構成されても良い。通知プラグイン２６は、ディレクトリサーバで変更された特定の装置にのみユニキャストメッセージを送信し、ネットワーク上のその他の装置には送信しない。例えば、プリンタ１４の構成がディレクトリサーバ２５で変更された場合、通知プラグイン２６は、プリンタ１４にのみメッセージをユニキャストし、プリンタ１５（同様にＬＤＡＰ使用可能なハイブリッドプリンタ）にはユニキャストしない。しかしながら、後述するように、ユニキャスト処理に関する問題点の１つは、通知プラグインがユニキャストメッセージを送信する前に、どのＬＤＡＰクライアントが変更処理を行なったかを最初に判定することである。すなわち、プリンタ１４のＬＤＡＰクライアントが変更を開始した場合、変更を開始したのはプリンタ１４のＬＤＡＰクライアントであるので、プラグインは、変更を通知するユニキャストメッセージをプリンタ１４に送信しない。しかし、クライアントワークステーション１３のＬＤＡＰクライアントにより変更が開始された場合、プリンタ１４のＬＤＡＰクライアントにより変更が開始された訳ではないので、通知プラグインは、変更を通知するためのユニキャストメッセージをプリンタ１４に送信する。
【００４２】
図５は、ディレクトリプロキシ２９の内部アーキテクチャのより詳細な構成及びネットワーク上の種々の装置との通信を示す。図５に示すように、ディレクトリプロキシ２９は、ＬＤＡＰクライアント６０、ＳＮＭＰデバイスディスカバリモジュール６１、ＳＮＭＰデバイス監視／ポーリングモジュール６２、ＳＮＭＰクライアント６３及びＬＤＡＰ／ＳＮＭＰ変換器６４を含む。ＬＤＡＰクライアント６０は、ディレクトリサーバ２５で変更を行ない、変換を行なってネットワーク上のＳＮＭＰ使用可能装置に送信する予定のＬＤＡＰコマンドをディレクトリサーバ２５から受信するために、ＬＤＡＰプロトコルを使用してディレクトリサーバ２５と通信を行なう。また、ＬＤＡＰクライアント６０は、図４に関して上述したマルチキャストグループ４５から４８などの種々のマルチキャストグループからマルチキャストメッセージを受信する。更に、ＬＤＡＰクライアント６０は、ＬＤＡＰ／ＳＮＭＰ変換器６４とのＬＤＡＰコマンドの送受信を行なう。
【００４３】
ＳＮＭＰクライアント６３は、レガシー（ＳＮＭＰ）プリンタ１６及びハイブリッド（ＳＮＭＰ／ＬＤＡＰ）プリンタ１５を含むネットワーク上の全てのＳＮＭＰ使用可能装置と通信を行なう。ＳＮＭＰクライアント６３は、ネットワーク上の全てのＳＮＭＰ使用可能装置とＳＮＭＰコマンドの送受信を行なう。また、ＳＮＭＰクライアント６３は、ＳＮＭＰデバイスディスカバリモジュール６１及びＳＮＭＰデバイス監視／ポーリングモジュール６２と通信し、モジュール６１及び６２とネットワーク上の全てのＳＮＭＰ使用可能装置との間でのメッセージの送信を行なう。更に、ＳＮＭＰクライアント６３は、ＬＤＡＰ／ＳＮＭＰ変換器６４と通信を行ない、ＳＮＭＰコマンドの送受信を行なう。ＬＤＡＰ／ＳＮＭＰ変換器６４は、ＳＮＭＰクライアント６３から受信したＳＮＭＰコマンドをＬＤＡＰ形式に変換し、そのＬＤＡＰコマンドをＬＤＡＰクライアント６０に送信する。また、ＬＤＡＰ／ＳＮＭＰ変換器６４は、ＬＤＡＰコマンドをＬＤＡＰクライアント６０から受信し、それをＳＮＭＰコマンド形式に変換し、ＳＮＭＰクライアント６３に送信する。
【００４４】
ＳＮＭＰデバイスディスカバリモジュール６１は、ＳＮＭＰクライアント６３を介して問い合わせ処理を行ない、ネットワーク上の全てのＳＮＭＰ装置に関する情報を取得する。また、ＳＮＭＰデバイスディスカバリモジュール６１は、ネットワーク上の全てのＳＮＭＰ装置から問い合わせに対する応答を受信し、その応答に基づいてＳＮＭＰコマンドをＳＮＭＰクライアント６３に送信する。ＳＮＭＰデバイス監視／ポーリングモジュール６２も、ＳＮＭＰクライアント６３を介して問い合わせ処理を行ない、ネットワーク上の全てのＳＮＭＰ装置に関する情報を取得する。モジュール６１とモジュール６２との相違点の１つは、モジュール６１が、通常、ディレクトリプロキシの始動時に問い合わせを行なうのに対し、モジュール６２は、通常、始動後に定期的な問い合わせを行ない、ＳＮＭＰ使用可能装置の全てから更新情報を取得することである。モジュール６１及び６２の処理は、以下でより詳細に説明する。
【００４５】
通常、ネットワーク１８に接続される装置には、埋込み型ＬＤＡＰクライアント、埋込み型ＬＤＡＰクライアントを持たないＳＮＭＰ装置及びＳＮＭＰ装置であり且つ埋込み型ＬＤＡＰクライアントを有するハイブリッド装置の３つの異なる種類がある。ネットワーク上の各装置では、ディレクトリサーバ２５のディレクトリ登録又はディレクトリ登録事項（ディレクトリエントリ）において構成情報の保守が行なわれる。すなわち、ディレクトリサーバ２５は、全てのＳＮＭＰ使用可能装置、全ての埋込み型ＬＤＡＰクライアント装置及び全てのハイブリッド装置のディレクトリを含む。ディレクトリエントリは、通常、標準化された構成又は体系（スキーマ）に従ってフォーマット化されており、スキーマ拡張を含んでも良い。標準化されたスキーマは、その装置に対するディレクトリエントリにおいて行われた変更のソースを示すソースフラグを含む。ソースフラグは、通知プラグイン２６により設定され、変更が、ディレクトリサーバ、すなわち、ネイティブアプリケーション又はワークステーション１３のＬＤＡＰクライアントにより開始された場合、０に設定され、装置により開始された場合、１に設定される。３種類の装置の各々及びディレクトリサーバにおけるこれらの装置の構成に対する変更の行なわれ方については、図６を参照しながら説明する。
【００４６】
図６は、３種類の装置の各々に対する変更の開始方法に関して３つの可能性のあるシナリオを示す。シナリオの１つでは、変更は、埋込み型ＬＤＡＰクライアントを有する装置に対して開始される。埋込み型ＬＤＡＰクライアント装置に対する変更は、装置自体の埋込み型ＬＤＡＰクライアント、あるいは、ディレクトリサーバ、すなわち、ワークステーション１３のＬＤＡＰクライアント又はサーバ１１のネイティブアプリケーションにより開始されても良い。第２のシナリオでは、変更はＳＮＭＰ装置に対して開始される。変更は、ＳＮＭＰ装置自体またはディレクトリサーバにより開始されても良い。第３のシナリオでは、変更は、ハイブリッド装置に対して開始される。変更は、装置自体、すなわち、この場合は装置のＳＮＭＰクライアント又は装置の埋込み型ＬＤＡＰクライアントにより開始されても良く、あるいは、ディレクトリサーバにより開始されても良い。これらの３つのシナリオの各々についてより詳細に説明する。
【００４７】
尚、以下では、通常、ディレクトリサーバ２５におけるエントリが既に存在する装置の構成に対して行われる変更を説明する。しかしながら、装置のネットワークからの削除及び新規の装置のネットワークへの追加などのその他の変更も同様に行われることは容易に理解されるだろう。従って、簡潔にする目的で、ネットワーク上に既に存在する装置の構成に対する変更に関わる処理のみを説明する。上述のように、ネットワーク上の各装置の構成における変更は、装置自体とディレクトリサーバとのいずれによっても開始することができる。以下の説明では、ネットワーク管理者が、装置自体において装置のＩＰアドレスを変更する例と、ネットワーク管理者が、ディレクトリサーバにおいて装置のＩＰアドレスを変更する例との２つの例を提示することによって、両方の場合が説明される。
【００４８】
最初に説明する装置は、プリンタ１４などの埋込み型ＬＤＡＰクライアントを有する装置である。プリンタ１４は、埋込み型ＬＤＡＰクライアントを含み、ＳＮＭＰクライアントを含まない。プリンタ１４は、純粋なＬＤＡＰ使用可能装置であり、ハイブリッド装置ではない。図２に関して前述したように、埋込み型ＬＤＡＰクライアントは、ＬＤＡＰプロトコルを介してディレクトリサーバと直接通信を行なう。従って、装置の構成における変更は、ＬＤＡＰを介して装置とディレクトリサーバとの間で直接伝達され、変換器を用いる必要はない。
【００４９】
図６は、埋込み型ＬＤＡＰクライアントを有する装置における変更の管理方法を含む３種類の各装置の管理方法のプロセスステップを表すフローチャートを示す。第１の埋込み型ＬＤＡＰクライアントのシナリオの例では、管理者は、プリンタ１４自体の埋込み型ＬＤＡＰクライアントを使用してＩＰアドレスを変更する。
【００５０】
第１の例では、ステップＳ６０１において、管理者は、プリンタ１４の埋込み型ＬＤＡＰクライアントを使用してプロセスを実行し、プリンタ１４のＩＰアドレスを変更する。埋込み型ＬＤＡＰクライアントによりプリンタ１４に対する変更が行なわれた場合、埋込み型ＬＤＡＰクライアントは、ＬＤＡＰプロトコルを介してディレクトリサーバ２５との通信を開始する。通信が一度確立されると、埋込み型ＬＤＡＰクライアントは、ＬＤＡＰ＿ＭＯＤＩＦＹ（ＬＤＡＰ変更）コマンドを使用してディレクトリサーバに対する変更を自ら発行する。また、埋込み型ＬＤＡＰクライアントは、ソースフラグを１に設定する。ディレクトリサーバ２５に対する変更が行なわれると、通知プラグイン２６が呼び出される（ステップＳ６０２）。
【００５１】
ステップＳ６０３で、ディレクトリサーバに対する変更が一度行なわれると、ディレクトリサーバ通知プラグイン２６は、ソースフラグを参照して、いずれの通知プロセスが行われるべきかを判定する。フラグが１に設定されている場合、通知プラグイン２６は、変更が装置により開始されており、装置に変更を通知する必要がないことを認識する。従って、この例では、処理はステップＳ６０４へと進み、そこで通知プラグイン２６は、ソースフラグを０にリセットし、通知プロセスを終了する。
【００５２】
第２の埋込み型ＬＤＡＰクライアントのシナリオの例では、管理者は、クライアントワークステーション１３のＬＤＡＰクライアントを使用してディレクトリサーバ２５のプリンタ１４のＩＰアドレスを変更する。変更を行なうために、管理者は、ワークステーション１３のＬＤＡＰクライアントアプリケーションを起動する。ＬＤＡＰクライアントアプリケーションは、ディレクトリサーバ２５にアクセスするように構成され、特に、プリンタ１４を含むオブジェクトクラスをアクセスするように構成される。ＬＤＡＰクライアントは、一度構成されると、ＬＤＡＰプロトコルを介してディレクトリサーバ２５との通信を確立する。一度通信が確立されると、ＬＤＡＰクライアントアプリケーションは、管理者に対して、クライアントワークステーション１３のディスプレイ上にプリンタ１４を含むオブジェクトクラスに対するディレクトリ構造を表示する。クライアントワークステーション１３のＬＤＡＰクライアントを使用して、管理者は、ディレクトリサーバ２５においてプリンタ１４のＩＰアドレスを変更する（ステップＳ６０１）。また、ＬＤＡＰクライアントアプリケーションは、ソースフラグを０に設定する。変更が行なわれると、ディレクトリサーバは通知プラグイン２６を呼び出す（ステップＳ６０２）。
【００５３】
ステップＳ６０３では、通知プラグイン２６は、ソースフラグが０に設定されているか否かを判定する。ここでは、ソースフラグは０に設定されているので、処理はステップＳ６０５に進む。ステップＳ６０５では、通知プラグイン２６は、プリンタ１４に対するディレクトリエントリを参照して、装置がＬＤＡＰ使用可能であるかを判定する。この判定は、通知プラグインがＬＤＡＰ使用可能装置に対してユニキャストメッセージを送信するべきか、あるいは、ディレクトリプロキシにより受信されるマルチキャストメッセージを送信するためにマルチキャストプラグインの１つを呼び出すべきかを判定するために行われる。通知プラグインが、装置がＬＤＡＰ使用可能であると判定した場合、すなわち、本例においては、プリンタ１４が埋込み型ＬＤＡＰクライアントを有するのでＬＤＡＰ使用可能であると判定した場合、処理はステップＳ６０６に進む。
【００５４】
ステップＳ６０６では、通知プラグイン２６は、ユニキャストメッセージを生成し、プリンタ１４の埋込み型ＬＤＡＰクライアントに対して、プリンタ１４に対するディレクトリサーバ２５のディレクトリエントリにおいて変更が行われたことを通知する。通知プラグイン２６により送信されるユニキャストメッセージは、埋込み型ＬＤＡＰクライアントに対して変更が行なわれたことを通知するだけであり、変更自体に関するいかなる明確な情報も含まない。このユニキャストメッセージを受信すると、プリンタ１４の埋込み型ＬＤＡＰクライアントは、ディレクトリサーバ２５との通信を確立し、ディレクトリエントリを読み出して変更情報を取得する（Ｓ６０７）。変更情報を取得すると、埋込み型ＬＤＡＰクライアントは、装置の構成を更新し（ステップＳ６０８）、プロセスは終了する。
【００５５】
前述の第２の例の結果として、プリンタ１４のＩＰアドレスは、ワークステーション１３のＬＤＡＰクライアントによりディレクトリサーバにおいて変更され、ディレクトリサーバの通知プラグインは、プリンタ１４の埋込み型ＬＤＡＰクライアントに対して、ディレクトリサーバで変更が行なわれたことを通知し、埋込み型ＬＤＡＰクライアントは、ディレクトリサーバの変更情報を読み出し、プリンタ１４の構成を更新する。
【００５６】
第２のシナリオでは、純粋なＳＮＭＰ装置を説明する。図６は、ＳＮＭＰ装置における変更の管理方法に対するプロセスステップを示す。しかしながら、ＳＮＭＰ装置に対する変更の例を説明する前に、始動時の情報取得（ＳＮＭＰデバイスディスカバリモジュール６１及びそれに関連する図７のフローチャート）とネットワーク上の全てのＳＮＭＰ装置に対する更新の取得（ＳＮＭＰデバイス監視／ポーリングモジュール６２及びそれに関連する図８のフローチャート）とを含むネットワーク上のＳＮＭＰ装置に関する情報をディレクトリプロキシが取得する方法についてのより詳細な説明を行なう。
【００５７】
図７において、ＳＮＭＰデバイスディスカバリモジュール６１は、通常、ネットワーク上の全てのＳＮＭＰ使用可能装置に関するネットワーク情報を取得し、その情報は、ディレクトリプロキシを介してディレクトリサーバ向けに処理される。ディスカバリモジュール６１は、ディレクトリプロキシの始動時又は新規の装置に対する定期的なポーリング処理中に、装置からネットワーク情報を取得する。ディレクトリプロキシが開始されると、ディスカバリモジュール６１は、ネットワーク上の全てのＳＮＭＰ装置を検出する。ネットワーク上のＳＮＭＰ装置を検出するために、ディスカバリモジュール６１は、ネットワーク上の全てのＳＮＭＰ装置に関するネットワーク識別情報に対する問い合わせ（ＳＮＭＰ＿ＱＵＥＲＹ：ＳＮＭＰ問い合わせ）を送出する（ステップＳ７０１）。ネットワーク上の全てのＳＮＭＰ使用可能装置は、その問い合わせに対する応答を提出する（ステップＳ７０２）。ＳＮＭＰ使用可能装置からの応答は、その装置のＩＰアドレス、装置の種類、機種、ＭＡＣアドレス、装置名及びＭＩＢ（Management Information Base：管理情報ベース）ボードの種類などのネットワーク識別情報を含む。
【００５８】
ディスカバリモジュール６１は、各装置から応答を受信すると、各装置のネットワーク識別情報を使用して、問い合わせに応答した各装置に対してＳＮＭＰ＿ＧＥＴ（ＳＮＭＰ取得）コマンドを送出する（ステップＳ７０３）。ＳＮＭＰ＿ＧＥＴコマンドは、ＳＮＭＰ装置に送信され、装置のネットワーク設定、装置のステータス及び装置の特徴などの情報をＳＮＭＰ装置のＭＩＢから取得する。要求を受信した各ＳＮＭＰ装置は、要求された情報を伴ってディスカバリモジュール６１に応答する（ステップＳ７０４）。要求された情報を受信すると、ディスカバリモジュール６１は、ＳＮＭＰクライアント６３と通信し、ＳＮＭＰ装置の情報をＳＮＭＰクライアント６３に送信する（ステップＳ７０５）。続いて、ＳＮＭＰクライアント６３は、このＳＮＭＰ装置の情報をＬＤＡＰ／ＳＮＭＰ変換器６４に送信する（ステップＳ７０６）。変換器６４は、装置の情報をＬＤＡＰ形式に変換し、ＬＤＡＰクライアント６０と通信し、ＬＤＡＰ形式のＳＮＭＰ装置の情報をＬＤＡＰクライアント６０に送信する（ステップＳ７０７）。次に、ＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立し、ＳＮＭＰ装置の情報をディレクトリサーバに対して自ら発行する（ステップＳ７０８）。ＬＤＡＰクライアント６０は、まず、ＬＤＡＰ＿ＡＤＤ（ＬＤＡＰ作成）コマンドを使用して、ディレクトリサーバ２５にＳＮＭＰ装置の情報を追加することを試みる。ＳＮＭＰ装置に対するエントリがディレクトリサーバ２５に既に存在する場合、ディレクトリサーバにより、エラーメッセージがＬＤＡＰクライアントに返される。ＬＤＡＰクライアント６０は、ＬＤＡＰ＿ＭＯＤＩＦＹ（ＬＤＡＰ変更）コマンドを使用して、既存の装置に対するディレクトリサーバ２５のディレクトリエントリ情報を置換する。
【００５９】
従って、新規の装置がネットワーク上で検出された場合、又は、既存の装置の構成がディレクトリプロキシが始動されるのに先立って変更された場合、ディレクトリプロキシによる変更を始動時に開始することができる。ディレクトリプロキシにより始動時に変更を行なうこのプロセスでは、装置において変更が開始された場合と同様の装置管理処理が行なわれる。従って、以下の装置及び監視／ポーリングモジュールで開始された変更に関する説明は、ディレクトリプロキシのディスカバリモジュールにより開始された変更にも等しく適用される。
【００６０】
図８は、ＳＮＭＰデバイス監視／ポーリングモジュール６２により行われるプロセスステップを示す。ＳＮＭＰデバイス監視／ポーリングモジュール６２は、監視又はポーリングの２つのモードの一方で動作しても良い。ポーリングモードでは、モジュール６２は、通常、ネットワーク上で定期的な問い合わせを行ない、ＳＮＭＰ装置のいずれかが更新されたか否かを判定する。このモードでは、ディレクトリプロキシ２９の始動後及びディスカバリモジュール６１の処理終了後に、監視／ポーリングモジュール６２は、更新された情報に対する変更問い合わせメッセージを送出することによって定期的な問い合わせ処理を行なっても良い。例えば、モジュール６２は、ネットワーク上で検出されたＳＮＭＰ装置の全てに対して選択されたＭＩＢのデータ更新に関する問い合わせを行なうために、毎秒ポーリング処理を行なうように構成されても良い（ステップＳ８０１）。更新が行われていない場合、いずれの装置も応答しないので、設定されたタイムアウト時間の経過後に処理は終了する。各装置のいずれかの構成が変更されていた場合、ネットワーク上の更新された装置のみが、問い合わせを受信した際に監視／ポーリングモジュール６２に対して変更が行なわれたことを示す変更情報応答を伴って問い合わせに応答する（ステップＳ８０２）。変更情報応答メッセージを受信すると、モジュール６２は、応答した各装置に対して更新された情報に対する要求を送信する（ステップＳ８０３）。ＳＮＭＰ装置は、要求を受信すると、更新された情報をモジュール６２に送信する（ステップＳ８０４）。モジュール６１と同様に、モジュール６２は、ＳＮＭＰクライアント６３にこの情報を送信し（ステップＳ８０５）、ＳＮＭＰクライアント６３は、それをＬＤＡＰ／ＳＮＭＰ変換器６４に送信する（ステップＳ８０６）。ＬＤＡＰ／ＳＮＭＰ変換器６４は、ＳＮＭＰ情報をＬＤＡＰ形式に変換し、ＬＤＡＰ形式の情報をＬＤＡＰクライアント６０に送信する（ステップＳ８０７）。ＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立し、ディレクトリサーバにおいて変更を自ら発行する（ステップＳ８０８）。
【００６１】
監視／ポーリングモジュール６２は、更新を調べるためにネットワークをポーリングするのではなく、ネットワーク上の全てのＳＮＭＰ装置からの更新に関する更新メッセージが送出されるのを待ってネットワークを監視することもできる。ここで、ネットワーク上の各ＳＮＭＰ装置は、装置において変更が行なわれた場合にネットワーク上にメッセージを送出することができる。モジュール６２は、更新メッセージの送出を待ち、メッセージを受信すると、そのメッセージを送出した装置に対して、更新された情報を伴って応答するように要求する。このように、ステップＳ８０３からＳ８０８は、上述したのと同様の方法で実行される。ステップＳ８０１及びＳ８０２は、更新を調べるためにネットワークをポーリングするのではなく、メッセージの送出を待ってポーリングするように変更しただけである。
【００６２】
今度は、図６の説明に戻り、ＳＮＭＰ装置及びディレクトリプロキシ２９における変更について説明する。図７に関して上述したように、ディレクトリプロキシ２９の始動時に、ディスカバリモジュール６１は、ネットワーク上の全装置に関する情報を取得し、この情報は、ディレクトリプロキシ２９を介してＬＤＡＰクライアント６０向けに処理される。ＬＤＡＰクライアント６０は、ディレクトリサーバ２５においてＬＤＡＰ＿ＡＤＤ処理を行なうことを試みるが、ディレクトリサーバにＳＮＭＰ装置に対するエントリが既に存在する場合は、エラーメッセージを受信する。ＬＤＡＰクライアント６０は、ＬＤＡＰ＿ＭＯＤＩＦＹコマンドを実行し、ディレクトリサーバにおけるＳＮＭＰ装置のディレクトリエントリを置換する（ステップＳ６０１）。ＬＤＡＰクライアント６０は、追加又は変更があった全てのＳＮＭＰ装置に対してソースフラグを１に設定する。ディレクトリサーバにおいて変更を行なう際、通知プラグイン２６が呼び出される（ステップＳ６０２）。ステップＳ６０３で、通知プラグイン２６が、ソースフラグが１に設定されていると判定した場合、処理はステップＳ６０４に進む。ステップＳ６０４では、通知プラグインは、ソースフラグを０にリセットし、処理を終了する。
【００６３】
次に、プリンタ１６などのＳＮＭＰ装置のＩＰアドレスが、装置自体において変更される場合について説明する。ディレクトリプロキシが始動されており、監視／ポーリングモジュール６２は、更新を調べるためにネットワークのポーリングを行なっている最中であるとする。管理者が、プリンタ１６においてプリンタのＩＰアドレスを変更する。プリンタ１６に対して変更が行なわれた後、モジュール６２のポーリング処理により、ネットワーク上に更新問い合わせメッセージが送出される。プリンタ１６の構成が更新されているので、プリンタ１６は、更新情報応答メッセージを伴って応答する。続いて、モジュール６２は、更新された情報に対する要求をプリンタ１６に送信し、プリンタ１６は、モジュール６２に更新された情報を送信する。モジュール６２は、この更新された情報をＳＮＭＰクライアント６３に送信し、ＳＮＭＰクライアント６３は、情報をＬＤＡＰ／ＳＮＭＰ変換器６４に送信する。ＬＤＡＰ／ＳＮＭＰ変換器６４は、情報をＳＮＭＰ形式からＬＤＡＰ形式に変換し、ＬＤＡＰ形式の情報をＬＤＡＰクライアント６０に送信する。ＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立し、ディレクトリサーバ２５において変更を行ない、ソースフラグを１に設定する（ステップＳ６０１）。続いて、通知プラグイン２６が呼び出される（ステップＳ６０２）。ステップＳ６０３で、通知プラグイン２６は、ソースフラグが１に設定されていると判定し、それにより、処理はステップＳ６０４に進む。ステップＳ６０４では、通知プラグイン２６は、ソースフラグを０にリセットし、処理は終了する。
【００６４】
従って、ＳＮＭＰ使用可能装置の構成は、装置自体において変更され、この変更は、ディレクトリプロキシが更新された情報を調べるためにポーリングを行なうことによって検出される。変更は、ディレクトリプロキシのＬＤＡＰクライアントによりディレクトリサーバにおいて行なわれる。クライアントワークステーション１３のＬＤＡＰクライアントアプリケーションを使用して、ディレクトリサーバにおいてＳＮＭＰ使用可能装置（プリンタ１６）のＩＰアドレスに対する変更が行われる場合について説明する。
【００６５】
プリンタ１６に対するＩＰアドレスは、埋込み型ＬＤＡＰクライアントプリンタ１４に対してＩＰアドレスの変更が行なわれた場合に関して上述したのと同様の方法で、ワークステーション１３のＬＤＡＰクライアントを使用してディレクトリサーバ２５において変更される。従って、ディレクトリサーバにおいて変更が行なわれ、ソースフラグが０に設定される（ステップＳ６０１）場合についての説明は、ここでは繰り返さない。
【００６６】
プリンタ１６に対するＩＰアドレスの変更が、一度ディレクトリサーバにおいて行われると、通知プラグイン２６が呼び出される（ステップＳ６０２）。続いて、ステップＳ６０３で、通知プラグイン２６は、フラグがステップＳ６０１で０に設定されたと判定し、装置に変更を通知する必要があると認識する。処理はステップＳ６０５に進む。ステップＳ６０５では、通知プラグイン２６は、プリンタ１６に対するディレクトリエントリからプリンタ１６がＳＮＭＰ使用可能装置であって埋込み型ＬＤＡＰクライアントを含まないと判定する。従って、処理は、ステップＳ６０９に進み、通知プラグイン２６は、ディレクトリサーバで行われた変更処理の種類により、マルチキャストプラグイン４０から４３のうちの１つを呼び出す。ここでは、ディレクトリサーバ２５で変更処理が行われたので、ＭＯＤＩＦＹ（変更）プラグイン４２が呼び出される。ＭＯＤＩＦＹプラグイン４２は、情報パケットを生成し、マルチキャストグループ４７にこのパケットをマルチキャストする。マルチキャストグループ４７の全ての登録メンバーは、情報パケットを受信する。ここで、ディレクトリプロキシ２９及び場合によってはネットワーク上のその他のディレクトリプロキシは、マルチキャストグループ４７のメンバーとして登録されているので、マルチキャストプラグインから情報パケットを受信する（ステップＳ６１０）。ディレクトリプロキシ２９は、ディレクトリサーバ２５において行われた変更に関するマルチキャストメッセージを調べるためにネットワークを監視しても良い。マルチキャストメッセージは、通常、変更が行なわれたという情報とディレクトリエントリが変更されたディレクトリエントリ識別情報とを含む。
【００６７】
マルチキャストメッセージを受信すると、ディレクトリプロキシ２９のＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立し、更新されたディレクトリエントリを読み出す（ステップＳ６１０）。更新された情報を取得すると、ＬＤＡＰクライアント６０は、その情報をＬＤＡＰ／ＳＮＭＰ変換器６４に送信する。ＬＤＡＰ／ＳＮＭＰ変換器６４では、更新された情報がＳＮＭＰ形式に変換され、ＳＮＭＰクライアント６３に送信される（ステップＳ６１１）。ＳＮＭＰクライアント６３は、更新された情報をプリンタ１６に送信し（ステップＳ６１１）、プリンタ１６のＭＩＢに新規のＩＰアドレスが設定される。
【００６８】
従って、上述したように、ネットワーク上のＳＮＭＰ装置の構成における変更は、ディレクトリサーバにおいて行われ、ディレクトリサーバ通知プラグインは、マルチキャストプラグインを呼び出す。マルチキャストプラグインは、マルチキャストメッセージを送出し、このメッセージはディレクトリプロキシにより受信される。ディレクトリプロキシのＬＤＡＰクライアントは、ディレクトリサーバと通信し、更新された情報を読み出し、ディレクトリプロキシの変換器にこれを送信する。変換器は、この情報をＬＤＡＰ形式からＳＮＭＰ形式に変換し、ディレクトリプロキシのＳＮＭＰクライアントに送信する。ＳＮＭＰクライアントは、この情報をＳＮＭＰ装置に送信し、この新規の情報は、ＳＮＭＰ装置において更新される。
【００６９】
第３のシナリオにおいて、すなわち、プリンタ１５などのハイブリッドＳＮＭＰ使用可能且つＬＤＡＰ使用可能装置に関しては、２つの例が説明される。一方は、変更がディレクトリサーバにおいて開始される場合であり、他方は、装置自体において変更が開始される場合である。
【００７０】
図２に関して先に説明したように、ハイブリッド装置は、ＬＤＡＰを介して直接ディレクトリサーバとの通信を行なうが、ディレクトリプロキシ（ＳＮＭＰ）を介しても通信を行なう。従って、ハイブリッド装置における通信の流れは、同時に行われる並行プロセス（ＬＤＡＰ及びＳＮＭＰ）を含んでも良い。例えば、プリンタ１５が最初にネットワークに接続されたディスカバリモードの間、ディレクトリプロキシの始動の間、又はディスカバリモジュール６１の新規の装置を調べるための定期的なポーリング処理の間に、プリンタ１５は、ＬＤＡＰ及びＳＮＭＰの２つの通信プロトコルを介してディレクトリサーバとの通信を行なうことを試みても良い。本シナリオでは、両プロトコルは、並行プロセスを行ない、新規の装置に対して同時にディレクトリサーバへのエントリを作成することを試みる。
【００７１】
例えば、プリンタ１５が埋込み型ＬＤＡＰクライアントを含み、プリンタ１５がネットワークに接続された時にこの埋込み型ＬＤＡＰクライアントがディレクトリサーバ２５との通信を確立するようにし、プリンタ１５に対する新規のディレクトリエントリを作成することを試みても良い。しかしながら、プリンタ１５は、ＳＮＭＰを介してディレクトリプロキシ２９とも通信を行なうので、新規の装置がネットワークに接続された場合、ディレクトリプロキシ２９のディスカバリモジュール６１が新規の装置を検出し、図７に関して上述したように装置のＳＮＭＰ情報を取得する。続いて、ディレクトリプロキシ２９のＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立し、プリンタ１５に対する新規のディレクトリエントリを作成することを試みる。
【００７２】
並行プロセス、すなわち、ＬＤＡＰ及びＳＮＭＰの両方のプロセスが行われる本シナリオでは、最初にディレクトリサーバとの通信を確立するプロセスは、ＡＤＤ（作成）処理を行なうプロセスであり、他方のプロセスは、後述するように通知プラグイン論理により管理される。すなわち、ディレクトリサーバの通知プラグインは、ハイブリッド装置の管理を制御する。従って、プリンタ１５の埋込み型ＬＤＡＰクライアントが、最初にディレクトリサーバ２５との通信を確立する場合、ディレクトリサーバ２５においてプリンタ１５に対する新規のエントリを発行する。次に、ＬＤＡＰクライアント６０が、ディレクトリサーバ２５との通信を確立し、ＬＤＡＰ＿ＡＤＤ処理を実行することを試みる場合、プリンタ１５の埋込み型ＬＤＡＰクライアントは、既にディレクトリエントリを作成しているので、エラーメッセージを受信する。従って、ＬＤＡＰクライアント６０は、ＬＤＡＰ＿ＭＯＤＩＦＹ処理を行なってディレクトリエントリを変更する。ディレクトリサーバ２５の通知プラグインはソースフラグが１に設定されていることを確認し、プリンタ１５に対してディレクトリプロキシ２９による変更を通知するための更なる処理を行なわない。
【００７３】
しかしながら、ディレクトリプロキシ２９のＬＤＡＰクライアント６０が、最初にディレクトリサーバ２５との通信を確立する場合、プリンタ１５に対する新規のディレクトリエントリを作成する。続いて、プリンタ１５の埋込み型ＬＤＡＰクライアントが、ディレクトリサーバ２５との通信を確立する場合、変更を行なった後、通知プラグインがソースフラグが１であることを確認する。従って、装置に変更を通知するための更なる処理を行なわない。
【００７４】
ハイブリッドプリンタ１５の構成における変更は、上述したように、クライアントワークステーション１３のＬＤＡＰクライアント又はサーバ１１のネイティブアプリケーションプログラムを使用して、ディレクトリサーバ２５のディレクトリエントリに対して行われても良い。ワークステーション１３のＬＤＡＰクライアント又はネイティブアプリケーションプログラムを使用して、プリンタ１５の構成における変更を行なうプロセスは、埋込み型ＬＤＡＰクライアントプリンタ及びＳＮＭＰプリンタに関して上述したのと同様である。従って、このプロセスは、ここでは繰り返さない。ステップＳ６０１で、ディレクトリサーバ２５のディレクトリエントリにおいて変更が行なわれる場合、ソースフラグは０に設定され、通知プラグイン２６が呼び出される（ステップＳ６０２）。通知プラグイン２６は、ステップＳ６０３で、ソースフラグが０に設定されていると判定し、ステップＳ６０５で、ディレクトリエントリを参照することによりプリンタ１５がＬＤＡＰ使用可能であると判定する。通知プラグイン２６は、プリンタ１５がＬＤＡＰ使用可能であることを検出するので、通知プラグイン２６は、プリンタ１５の埋込み型ＬＤＡＰクライアントにメッセージをユニキャストする（ステップＳ６０６）。以降のプロセスは、プリンタ１４の埋込み型ＬＤＡＰクライアントがディレクトリサーバ２５との通信を確立し、変更された情報を読み出し（ステップＳ６０７）、埋込み型ＬＤＡＰクライアントが、プリンタ１５において変更を行なう（ステップＳ６０８）点で、上述のプリンタ１４に対するプロセスと同様である。
【００７５】
しかしながら、プリンタ１５は、ハイブリッド装置であるので、プリンタ１５の構成における変更が埋込み型ＬＤＡＰクライアントにより一度行なわれると、ディレクトリプロキシ２９は、監視／ポーリングモジュール６２を介して変更を検出する。変更を検出すると、モジュール６２は、上述のように動作して、更新された情報をプリンタ１５から取得し、この更新された情報は、ディレクトリプロキシ２９を介してＬＤＡＰクライアント６０向けに処理される。ディレクトリプロキシ２９のＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立するが、ディレクトリエントリを更新することもある。ここで、ディレクトリプロキシ２９は、ＬＤＡＰ使用可能装置を認識し、これらの装置に対する更なる処理を行なわないように構成されても良い。すなわち、ディレクトリプロキシが装置がハイブリッド装置であると認識する場合、ハイブリッド装置における変更を検出した時に、ＬＤＡＰクライアントがこの変更を処理し、ディレクトリプロキシが変更を行なわないように構成されても良い。一方、ディレクトリプロキシ２９は、既にＬＤＡＰクライアントによりディレクトリエントリが作成されていても、それを上書きしても良い。この場合、変更が行われた際に、ディレクトリプロキシによりソースフラグが１に設定される。通知プラグイン２６が、ソースフラグが１に設定されていることを確認すると、処理はステップＳ６０４に進み、通知プラグイン２６は、ソースフラグを０に設定し、通知プロセスは終了する。
【００７６】
プリンタ１５の構成における更新は、プリンタ１５自体において行われても良い。この場合、埋込み型ＬＤＡＰクライアント装置における更新に関して上述されたのと同様に、更新が行なわれる。上述のように、埋込み型ＬＤＡＰクライアントは、ディレクトリサーバとの通信を確立し、ＬＤＡＰクライアントは、ディレクトリエントリにおける変更を自ら発行する。ディレクトリサーバに対する変更を行なうと、埋込み型ＬＤＡＰクライアントは、ソースフラグを１に設定する。続いて、ステップＳ６０２で、通知プラグイン２６が呼び出される。ステップＳ６０３では、通知プラグイン２６は、ソースフラグが１に設定されていると判定し、処理は、ステップＳ６０４に進む。ステップＳ６０４では、プラグインはフラグを０にリセットし、通知プロセスは終了する。
【００７７】
プリンタ１５において、埋込み型ＬＤＡＰクライアントを使用して変更が行なわれた場合、ディレクトリプロキシ２９の監視／ポーリングモジュール６２が、変更を検出し、変更された情報を取得する。変更された情報は、ディレクトリプロキシ２９を介してＬＤＡＰクライアント６０向けに処理される。ディレクトリプロキシ２９は、ＬＤＡＰ使用可能装置における変更を無視するように構成されても良い。しかしながら、ディレクトリプロキシ２９が変更を処理する場合、ＬＤＡＰクライアント６０は、ディレクトリサーバ２５との通信を確立し、再び変更を発行し、ソースフラグを１に設定する。通知プラグイン２６が呼び出され（ステップＳ６０２）、ソースフラグが１に設定されていることを検出する（ステップＳ６０３）。従って、通知プラグイン２６は、ソースフラグを０にリセットし、処理は終了する（ステップＳ６０４）。
【００７８】
従って、ハイブリッド装置に関して、装置において行われた変更は、埋込み型ＬＤＡＰクライアントを介してディレクトリサーバに送信される。場合によっては、ディレクトリプロキシが埋込み型ＬＤＡＰクライアントにより行われた変更を検出し、再び変更を行なう。ディレクトリプロキシが変更を検出するが、装置がＬＤＡＰ使用可能であると判定し、ＬＤＡＰクライアントがこの変更を処理できるようにする場合もある。ディレクトリサーバにおいて行なわれた変更に関して、この変更は、埋込み型ＬＤＡＰクライアントを介してハイブリッド装置に送信される。ディレクトリプロキシは、変更を検出し、ＬＤＡＰクライアントが、この変更を処理するか、あるいは、再びこの変更を実行することを可能にする。
【００７９】
本発明は、特定の例示的な実施形態に関して説明を行なってきた。本発明がこの上述の実施形態に限定されるものではなく、本発明の趣旨から逸脱することなく、種々の変更及び修正が行われても良いことは、当業者には理解されるべきである。
【図面の簡単な説明】
【図１】本発明を適用可能なネットワークシステムを示す図である。
【図２】図１のネットワーク上の各装置間での通信のアーキテクチャを示す図である。
【図３】図１に示すサーバの内部アーキテクチャを示す図である。
【図４】プラグインを使用するディレクトリサーバのアーキテクチャを示す図である。
【図５】ディレクトリプロキシの内部アーキテクチャのより詳細な構成及びネットワーク上の種々の装置との通信を示す図である。
【図６】図１のネットワーク上の装置の構成に対する変更の管理のためのプロセスステップのフローチャートである。
【図７】ディレクトリプロキシのディスカバリモジュールに対するプロセスステップのフローチャートである。
【図８】ディレクトリプロキシの監視／ポーリングモジュールに対するプロセスステップのフローチャートである。
Claims (17)
- ネットワーク装置及びディレクトリサーバに接続された通信装置であって、
第１の通信プロトコルを使用して、前記ネットワーク装置の存在を検出する検出手段と、
前記検出手段により検出されたネットワーク装置から、当該ネットワーク装置に関する情報を取得する情報取得手段と、
前記情報取得手段が取得した情報を、第２の通信プロトコルを使用して前記ディレクトリサーバに送信するための形式に変換する変換手段と、
前記変換手段により変換された情報を、前記ディレクトリサーバにおいてディレクトリエントリとして管理させるために、前記第２の通信プロトコルを使用して前記ディレクトリサーバに送信する第１の送信手段とを備え、
前記第１の送信手段は、前記変換手段により変換された情報毎に、当該変換された情報を含むエントリ作成メッセージを前記ディレクトリサーバに送信し、
前記第１の送信手段が送信した前記エントリ作成メッセージに対して、ディレクトリエントリが既に存在することを示すエラーメッセージが前記ディレクトリサーバから返送されてきた場合に、前記第１の送信手段は、当該既に存在するディレクトリエントリを前記変換手段により変換された情報に変更するために、エントリ変更メッセージを前記ディレクトリサーバに送信する
ことを特徴とする通信装置。 - 前記通信装置はネットワークを介して複数のネットワーク装置に接続され、
前記検出手段は、前記ネットワークを介して、前記第１の通信プロトコルを使用して問合せメッセージをブロードキャスト送信し、当該問合せメッセージに対する応答メッセージを前記ネットワーク装置から受信することにより、前記ネットワーク装置の検出を行うことを特徴とする請求項１に記載の通信装置。 - 前記情報取得手段は、前記検出手段により検出されたネットワーク装置に対して、前記第１の通信プロトコルを使用して情報要求メッセージを送信し、当該情報要求メッセージに対する応答メッセージを前記ネットワーク装置から受信することにより、前記ネットワーク装置に関する情報の取得を行うことを特徴とする請求項１または２に記載の通信装置。
- 前記情報取得手段が取得するネットワーク装置に関する情報には、前記ネットワーク装置のネットワーク設定情報、及び当該ネットワーク装置のステータス情報が含まれることを特徴とする請求項１から３のいずれか１項に記載の通信装置。
- 前記ネットワーク装置における当該ネットワーク装置に関する情報の更新を監視する第１の監視手段を更に備え、
前記ネットワーク装置において当該ネットワーク装置に関する情報が更新された場合に、前記情報取得手段は前記ネットワーク装置から前記更新された情報を取得し、前記変換手段は当該取得された情報を変換し、前記第１の送信手段は当該変換された情報を前記第２の通信プロトコルを使用して前記ディレクトリサーバに送信することを特徴とする請求項１から４のいずれか１項に記載の通信装置。 - 前記第１の監視手段は、前記ネットワーク装置に対して、前記第１の通信プロトコルを使用して変更問合せメッセージを定期的に送信し、当該変更問合せメッセージに対する変更応答メッセージを前記ネットワーク装置から受信することにより、前記ネットワーク装置における当該ネットワーク装置に関する情報の更新を監視することを特徴とする請求項５に記載の通信装置。
- 前記更新された情報を取得する場合に、前記情報取得手段は、前記変更応答メッセージを送信したネットワーク装置に対して、前記第１の通信プロトコルを使用して前記情報要求メッセージを送信し、当該情報要求メッセージに対する応答メッセージを当該ネットワーク装置から受信することにより、前記更新された情報を取得することを特徴とする請求項６に記載の通信装置。
- 前記第１の送信手段により送信された情報が前記ディレクトリサーバにおいてディレクトリエントリとして格納された後、当該ディレクトリサーバにおける当該ディレクトリエントリの更新を監視する第２の監視手段と、
前記ディレクトリサーバにおいて前記ディレクトリエントリが更新された場合に、当該更新されたディレクトリエントリを取得するディレクトリエントリ取得手段と、
前記ディレクトリエントリ取得手段が取得したディレクトリエントリから更新されたデータを抽出する抽出手段と、
前記抽出手段により抽出されたデータを、前記第１の通信プロトコルを使用して前記ネットワーク装置に送信する第２の送信手段と、
を更に備えることを特徴とする請求項１から７のいずれか１項に記載の通信装置。 - 前記第２の監視手段は、前記ディレクトリサーバに格納されたディレクトリエントリが更新された場合に当該ディレクトリサーバから発行されるマルチキャストメッセージを受信することにより、前記ディレクトリサーバにおける前記ディレクトリエントリの更新を監視することを特徴とする請求項８に記載の通信装置。
- 前記ディレクトリエントリ取得手段は、前記第２の監視手段が前記マルチキャストメッセージを受信したことに応じて、前記第２の通信プロトコルを使用して前記更新されたディレクトリエントリを前記ディレクトリサーバから読み出して取得することを特徴とする請求項９に記載の通信装置。
- 前記第１の通信プロトコルは、ネットワーク管理プロトコルであることを特徴とする請求項１から９のいずれか１項に記載の通信装置。
- 前記第１の通信プロトコルは、ＳＮＭＰであることを特徴とする請求項１１に記載の通信装置。
- 前記第２の通信プロトコルは、ディレクトリプロトコルであることを特徴とする請求項１から１２のいずれか１項に記載の通信装置。
- 前記第２の通信プロトコルは、ＬＤＡＰまたはＸ．５００ディレクトリプロトコルであることを特徴とする請求項１３に記載の通信装置。
- ネットワーク装置の管理方法であって、
第１の通信プロトコルを使用して、前記ネットワーク装置の存在を検出する検出工程と、
前記検出工程で検出されたネットワーク装置から、当該ネットワーク装置に関する情報を取得する情報取得工程と、
前記情報取得工程で取得された情報を、第２の通信プロトコルを使用してディレクトリサーバに送信するための形式に変換する変換工程と、
前記変換工程で変換された情報を、前記ディレクトリサーバにおいてディレクトリエントリとして管理させるために、前記第２の通信プロトコルを使用して前記ディレクトリサーバに送信する送信工程とを備え、
前記送信工程では、前記変換工程により変換された情報毎に、当該変換された情報を含むエントリ作成メッセージを前記ディレクトリサーバに送信し、
前記送信工程で送信した前記エントリ作成メッセージに対して、ディレクトリエントリが既に存在することを示すエラーメッセージが前記ディレクトリサーバから返送されてきた場合に、当該既に存在するディレクトリエントリを前記変換工程により変換された情報に変更するために、エントリ変更メッセージを前記ディレクトリサーバに送信する
ことを特徴とする管理方法。 - 請求項１５に記載の管理方法をコンピュータに実行させるためのプログラム。
- 請求項１５に記載の管理方法をコンピュータに実行させるためのプログラムを記憶したコンピュータ読み取り可能な記憶媒体。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/661,030 US7024476B1 (en) | 2000-09-13 | 2000-09-13 | Directory-enabled device management |
| US09/661030 | 2000-09-13 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2002232423A JP2002232423A (ja) | 2002-08-16 |
| JP2002232423A5 JP2002232423A5 (ja) | 2008-10-23 |
| JP4603737B2 true JP4603737B2 (ja) | 2010-12-22 |
Family
ID=24651907
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001278759A Expired - Fee Related JP4603737B2 (ja) | 2000-09-13 | 2001-09-13 | 通信装置及びネットワーク装置の管理方法、並びにプログラム及び記憶媒体 |
Country Status (2)
| Country | Link |
|---|---|
| US (2) | US7024476B1 (ja) |
| JP (1) | JP4603737B2 (ja) |
Families Citing this family (65)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AUPQ963100A0 (en) * | 2000-08-24 | 2000-09-14 | Tele-Ip Limited | Means for interfacing non-standard devices under snmp |
| EP1202520A1 (en) * | 2000-10-23 | 2002-05-02 | THOMSON multimedia | Method and device for data transmission in a television system |
| FI20002402A (fi) * | 2000-11-01 | 2002-05-02 | Nokia Corp | Konfiguroinnin hallinta hajautetussa ympäristössä |
| JP3685083B2 (ja) * | 2001-04-05 | 2005-08-17 | セイコーエプソン株式会社 | ネットワークを介した画像、音声の出力システム |
| EP1271843B1 (en) * | 2001-06-18 | 2007-08-15 | Hewlett-Packard Company | A method and system for identifying network connected devices such as personal computers |
| DE10151116A1 (de) * | 2001-10-15 | 2003-05-08 | Siemens Ag | Verfahren zur Inbetriebnahme eines Bedien- und Beobachtungssystems von Feldgeräten |
| US7370353B2 (en) * | 2001-11-05 | 2008-05-06 | Cisco Technology, Inc. | System and method for managing dynamic network sessions |
| US7515546B2 (en) * | 2001-12-19 | 2009-04-07 | Alcatel-Lucent Canada Inc. | Method and apparatus for automatic discovery of network devices with data forwarding capabilities |
| US7197562B2 (en) * | 2002-04-05 | 2007-03-27 | Infocus Corporation | Projector device management system |
| US20030208609A1 (en) * | 2002-05-01 | 2003-11-06 | Verizon Services, Corp. | Automatic configuration of advanced services over DSL |
| AU2003232039A1 (en) * | 2002-05-03 | 2003-11-17 | Netbotz, Inc. | Method and apparatus for collecting and displaying network device information |
| US7606884B2 (en) * | 2002-09-04 | 2009-10-20 | Northrop Grumman Corporation | SNMP firewall for network identification |
| US20080261633A1 (en) * | 2002-10-22 | 2008-10-23 | Research In Motion Limited | System and Method for Pushing Information from a Host System to a Mobile Data Communication Device |
| US7437439B2 (en) * | 2002-12-03 | 2008-10-14 | Hewlett-Packard Development Company, L.P. | System and method for the hybrid harvesting of information from peripheral devices |
| US7831999B2 (en) * | 2002-12-09 | 2010-11-09 | Bea Systems, Inc. | System and method for single security administration |
| US7475133B2 (en) * | 2003-01-09 | 2009-01-06 | Ricoh Company, Ltd | Method for configuring a monitoring system to monitor selected network elements |
| US20040184070A1 (en) * | 2003-03-18 | 2004-09-23 | Microsoft Corporation | Network printer connection update scheme for printer clients |
| US7334217B2 (en) * | 2003-04-02 | 2008-02-19 | Microsoft Corporation | Ejection failure mechanism |
| KR100580173B1 (ko) * | 2003-07-15 | 2006-05-15 | 삼성전자주식회사 | 네트워크 스캐닝 방법 및 장치와 이를 위한 패킷 포맷 |
| US7555545B2 (en) * | 2003-07-30 | 2009-06-30 | AT&T Intellectual Property, I,L.P | Method system and storage medium for detecting network elements |
| US7389337B2 (en) * | 2003-09-26 | 2008-06-17 | Nortel Networks Limited | Management of network elements using a proxy agent |
| US8015301B2 (en) * | 2003-09-30 | 2011-09-06 | Novell, Inc. | Policy and attribute based access to a resource |
| US7467190B2 (en) * | 2003-10-06 | 2008-12-16 | Hitachi, Ltd. | Method and apparatus for alert distribution and archive sharing |
| US7343409B1 (en) * | 2003-10-14 | 2008-03-11 | Sun Microsystems, Inc. | Method, system and article of manufacture for discovering devices in a network monitoring system |
| JP4546967B2 (ja) * | 2003-10-22 | 2010-09-22 | ライカ ジオシステムズ アクチェンゲゼルシャフト | ワークサイト上の装置間情報交換管理方法とその装置 |
| US20050216575A1 (en) * | 2004-03-24 | 2005-09-29 | John Armstrong | Network devices for automatic network information access systems |
| US7784064B2 (en) * | 2004-04-14 | 2010-08-24 | Barclays Capital Inc. | Method for collecting monitor information |
| US7512774B2 (en) * | 2004-04-14 | 2009-03-31 | Barclays Capital Inc. | Method and system for collecting processor information |
| US8392545B2 (en) * | 2004-07-01 | 2013-03-05 | Nokia Corporation | Device management system |
| US8073960B2 (en) * | 2004-07-01 | 2011-12-06 | Nokia Corporation | Arranging management operations in management system |
| US20060031449A1 (en) * | 2004-07-01 | 2006-02-09 | Mika Hallamaa | Selection of management method |
| US8010576B2 (en) * | 2004-08-19 | 2011-08-30 | Oracle International Corporation | Inventory and configuration management |
| US7996814B1 (en) | 2004-12-21 | 2011-08-09 | Zenprise, Inc. | Application model for automated management of software application deployments |
| US20070043684A1 (en) * | 2005-08-18 | 2007-02-22 | Fargo Electronics, Inc. | Central Management of a Credential Production System |
| US8099178B2 (en) * | 2005-08-22 | 2012-01-17 | Trane International Inc. | Building automation system facilitating user customization |
| US7870090B2 (en) * | 2005-08-22 | 2011-01-11 | Trane International Inc. | Building automation system date management |
| US8055386B2 (en) * | 2005-08-22 | 2011-11-08 | Trane International Inc. | Building automation system data management |
| US8055387B2 (en) | 2005-08-22 | 2011-11-08 | Trane International Inc. | Building automation system data management |
| US8050801B2 (en) * | 2005-08-22 | 2011-11-01 | Trane International Inc. | Dynamically extensible and automatically configurable building automation system and architecture |
| US8024054B2 (en) * | 2005-08-22 | 2011-09-20 | Trane International, Inc. | Building automation system facilitating user customization |
| JP4838564B2 (ja) * | 2005-10-06 | 2011-12-14 | キヤノン株式会社 | ネットワークデバイス、その制御方法およびプログラム |
| US7921200B2 (en) * | 2006-02-03 | 2011-04-05 | International Business Machines Corporation | Apparatus, system, and method for interaction with multi-attribute system resources as groups |
| CN101390337B (zh) * | 2006-02-27 | 2011-09-28 | 沃纳格控股公司 | 自动装置配置 |
| US7562075B2 (en) * | 2006-12-07 | 2009-07-14 | International Business Machines Corporation | Change approvals for computing systems |
| US8095625B2 (en) * | 2007-02-28 | 2012-01-10 | Red Hat, Inc. | Directory server plug-in call ordering |
| US8091119B2 (en) * | 2007-08-22 | 2012-01-03 | Novell, Inc. | Identity based network mapping |
| US20090070439A1 (en) * | 2007-09-07 | 2009-03-12 | Hongfeng Wei | System and method for generating a pluggable network stack interface |
| WO2009102353A1 (en) * | 2008-02-13 | 2009-08-20 | Hewlett-Packard Development Company, L.P. | Managing electronic devices with different types of device location limited device management clients |
| WO2009102354A1 (en) * | 2008-02-13 | 2009-08-20 | Hewlett-Packard Development Company, L.P. | Managing electronic devices using an electronic device as a root of trust |
| US8645017B2 (en) | 2008-05-07 | 2014-02-04 | Bosch Automotive Service Solutions Llc | Dynamic discovery of vehicle communication interface device and method |
| US8280581B2 (en) * | 2008-05-07 | 2012-10-02 | Spx Corporation | Dynamic discovery of vehicle communication interface device and method |
| US20100138461A1 (en) * | 2008-12-03 | 2010-06-03 | Electronics And Telecommunications Research Institute | Apparatus for managing new device component of mobile terminal and method of the same |
| US8180824B2 (en) * | 2009-02-23 | 2012-05-15 | Trane International, Inc. | Log collection data harvester for use in a building automation system |
| US8402511B2 (en) * | 2009-07-30 | 2013-03-19 | Hewlett-Packard Development Company, L.P. | LDAPI communication across OS instances |
| US9258201B2 (en) * | 2010-02-23 | 2016-02-09 | Trane International Inc. | Active device management for use in a building automation system |
| US8219660B2 (en) * | 2010-02-26 | 2012-07-10 | Trane International Inc. | Simultaneous connectivity and management across multiple building automation system networks |
| US8793022B2 (en) * | 2010-02-26 | 2014-07-29 | Trane International, Inc. | Automated air source and VAV box association |
| US20120246297A1 (en) * | 2011-03-25 | 2012-09-27 | Vijaya Shanker | Agent based monitoring for saas it service management |
| US9325814B2 (en) * | 2011-06-02 | 2016-04-26 | Numerex Corp. | Wireless SNMP agent gateway |
| US9693111B2 (en) | 2013-07-08 | 2017-06-27 | Utc Fire & Security Corporation | Video transmission system |
| US10237115B2 (en) | 2015-11-10 | 2019-03-19 | Ca, Inc. | Role based configuration and management tool based on SNMP and LDAP |
| US11162702B2 (en) | 2016-04-28 | 2021-11-02 | Trane International Inc. | Method of associating a diagnostic module to HVAC system components |
| US10269235B2 (en) | 2016-08-26 | 2019-04-23 | Trane International Inc. | System and method to assist building automation system end user based on alarm parameters |
| US10397010B2 (en) * | 2017-11-30 | 2019-08-27 | International Business Machines Corporation | Customized multicasting |
| JP7180200B2 (ja) * | 2018-08-21 | 2022-11-30 | 日本電信電話株式会社 | 中継装置および中継方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000183877A (ja) * | 1998-12-15 | 2000-06-30 | Canon Inc | ネットワークデバイス制御装置及び方法 |
| JP2000353141A (ja) * | 1999-06-11 | 2000-12-19 | Canon Inc | ネットワークデバイス管理装置及び方法 |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5151989A (en) * | 1987-02-13 | 1992-09-29 | International Business Machines Corporation | Directory cache management in a distributed data processing system |
| US5680552A (en) * | 1994-09-20 | 1997-10-21 | Lucent Technologies Inc. | Gateway system for interconnecting different data communication networks |
| US5845081A (en) * | 1996-09-03 | 1998-12-01 | Sun Microsystems, Inc. | Using objects to discover network information about a remote network having a different network protocol |
| US6523696B1 (en) * | 1996-10-15 | 2003-02-25 | Kabushiki Kaisha Toshiba | Communication control device for realizing uniform service providing environment |
| US5778394A (en) * | 1996-12-23 | 1998-07-07 | Emc Corporation | Space reclamation system and method for use in connection with tape logging system |
| US6578077B1 (en) * | 1997-05-27 | 2003-06-10 | Novell, Inc. | Traffic monitoring tool for bandwidth management |
| US6052724A (en) * | 1997-09-02 | 2000-04-18 | Novell Inc | Method and system for managing a directory service |
| US6067477A (en) * | 1998-01-15 | 2000-05-23 | Eutech Cybernetics Pte Ltd. | Method and apparatus for the creation of personalized supervisory and control data acquisition systems for the management and integration of real-time enterprise-wide applications and systems |
| US6098099A (en) * | 1998-04-21 | 2000-08-01 | International Business Machines Corporation | Third-party notification by network directory server |
| US7293099B1 (en) * | 1998-09-29 | 2007-11-06 | Sun Microsystems, Inc. | Heterogeneous network file access |
| US6594700B1 (en) * | 1999-06-14 | 2003-07-15 | International Business Machines Corporation | System and method for implementing a universal service broker interchange mechanism |
| US6505244B1 (en) * | 1999-06-29 | 2003-01-07 | Cisco Technology Inc. | Policy engine which supports application specific plug-ins for enforcing policies in a feedback-based, adaptive data network |
| US6584502B1 (en) * | 1999-06-29 | 2003-06-24 | Cisco Technology, Inc. | Technique for providing automatic event notification of changing network conditions to network elements in an adaptive, feedback-based data network |
| US6539425B1 (en) * | 1999-07-07 | 2003-03-25 | Avaya Technology Corp. | Policy-enabled communications networks |
| US6292838B1 (en) * | 1999-08-23 | 2001-09-18 | 3Com Corporation | Technique for automatic remote media access control (MAC) layer address resolution |
| US6622170B1 (en) * | 1999-09-10 | 2003-09-16 | International Business Machines Corporation | System and method for DEN/LDAP client database access with a backoff capability |
| US6560644B1 (en) * | 1999-09-15 | 2003-05-06 | Cisco Technology, Inc. | Directory services network management locator |
| US20030208609A1 (en) * | 2002-05-01 | 2003-11-06 | Verizon Services, Corp. | Automatic configuration of advanced services over DSL |
-
2000
- 2000-09-13 US US09/661,030 patent/US7024476B1/en not_active Expired - Fee Related
-
2001
- 2001-09-13 JP JP2001278759A patent/JP4603737B2/ja not_active Expired - Fee Related
-
2005
- 2005-09-12 US US11/222,757 patent/US7478153B2/en not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000183877A (ja) * | 1998-12-15 | 2000-06-30 | Canon Inc | ネットワークデバイス制御装置及び方法 |
| JP2000353141A (ja) * | 1999-06-11 | 2000-12-19 | Canon Inc | ネットワークデバイス管理装置及び方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20060010232A1 (en) | 2006-01-12 |
| US7478153B2 (en) | 2009-01-13 |
| US7024476B1 (en) | 2006-04-04 |
| JP2002232423A (ja) | 2002-08-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4603737B2 (ja) | 通信装置及びネットワーク装置の管理方法、並びにプログラム及び記憶媒体 | |
| US5729689A (en) | Network naming services proxy agent | |
| JP4024589B2 (ja) | ネットワーク・デバイスのミミック・サポート | |
| JP5178539B2 (ja) | 情報処理装置、情報処理装置の制御方法、セッション管理システム並びにプログラム | |
| JP3915797B2 (ja) | プラグアンドプレイ機能を有するフレームワークおよびその再構成方法 | |
| JP3962612B2 (ja) | 情報処理装置及び情報処理装置で実行される設定方法とプログラム | |
| US20040136027A1 (en) | Hosted method and system for automated proxy creation of device resident services | |
| JPH0916492A (ja) | コンピュータシステム、周辺装置特性供給方法およびコンピュータ使用可能媒体 | |
| WO2019144965A1 (zh) | 一种镜像拉取的方法及其系统 | |
| US8489766B2 (en) | Information processing apparatus, control method therefor, and computer-readable storage medium, for updating device information corresponding to a device among the device information stored in a storage unit, and for sending a notification for releasing an internet-protocol address assigned to the device to a dynamic-host-configuration-protocol server based on whether received information specifies a specific condition | |
| US7468804B2 (en) | Techniques for printer-side network cluster printing | |
| US20090193133A1 (en) | Network device management apparatus, control method therefor, network system, and storage medium | |
| US20150067022A1 (en) | Network based software agent to allow dynamic resource access | |
| JP2013118663A (ja) | 情報処理装置、情報処理装置の制御方法及びプログラム | |
| US8676967B2 (en) | Event proxy notification apparatus and method of controlling the same and program | |
| US20020198972A1 (en) | Pre-boot multicast address management protocol for a computer network | |
| JP2009153050A (ja) | 情報処理装置、デバイス、情報処理装置の制御方法、及びコンピュータプログラム | |
| JP3609948B2 (ja) | マルチプロトコルネットワーク管理方法、マルチプロトコルネットワーク管理プロキシサーバシステム、マルチプロトコルアドレス管理サーバシステム、および、マルチプロトコルネットワーク管理システム | |
| JP5524606B2 (ja) | 仮想化環境におけるモジュール間の通信方法、情報処理装置およびその制御方法、クライアント装置、情報処理システム、プログラム | |
| KR100423391B1 (ko) | 고속 라우터 시스템에서 분산 포워딩 테이블 처리방법 | |
| CN102035670B (zh) | 具有多个网络接口的通信设备和控制通信设备的方法 | |
| Cisco | Configuring the TN3270 Server | |
| JP2002007091A (ja) | プリントサーバシステム | |
| US7792807B2 (en) | Processing apparatus, data processing method, program for implementing the method, and storage medium | |
| JP2001256153A (ja) | ネットワークデバイス制御装置および方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080909 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080909 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100614 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100702 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100827 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100927 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20101004 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131008 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |