(57)【特許請求の範囲】
【請求項１】
複数の電子機器を有する通信システムであって、
ＩＥＥＥ１３９４．３で定められたイニシエータの役割をはたすイニシエータ機器が、
ＩＥＥＥ１３９４．３で定められたバージョンのエントリの値を持つ第１のユニットディレクトリと、
ＩＥＥＥ１３９４．３で定められた値とは異なるバージョンのエントリの値を持つ第２のユニットディレクトリと
を備え、
ＩＥＥＥ１３９４．３で定められたターゲットの役割を果たすターゲット機器が、
前記イニシエータ機器が提供しているサービスを知るために、前記イニシエータ機器が備えている前記第１のユニットディレクトリと前記第２のユニットディレクトリの少なくとも１つを読み取る読み取り手段と、
前記読み取り手段によって前記第１のユニットディレクトリ又は前記第２のユニットディレクトリが読み取られた場合、読み取られたユニットディレクトリのバージョン以外のエントリをＩＥＥＥ１３９４．３の規定にしたがって解析する解析手段と
を備えることを特徴とする通信システム。
【請求項２】
前記ターゲット機器は、前記読み取り手段によって読み取られたユニットディレクトリのバージョンのエントリの値が０か１かを判定する判定手段を更に有することを特徴とする請求項１に記載の通信システム。
【請求項３】
前記ターゲット機器は、前記読み取り手段で読み取られたユニットディレクトリにディレクトリＩＤのエントリがあるかどうか判定し、もし当該ユニットディレクトリがディレクトリＩＤのエントリを含んでいれば、その値を取り出すことを特徴とする請求項２に記載の通信システム。
【請求項４】
前記ターゲット機器は、前記読み取り手段によって読み取られたユニットディレクトリのバージョンのエントリの値が１で、かつ、当該ユニットディレクトリがディレクトリＩＤのエントリを含んでいる場合、当該ディレクトリＩＤの値をＩＥＥＥ１３９４．３で定められたコネクトのパラメータとして付け加えることを特徴とする請求項３に記載の通信システム。
【請求項５】
前記ターゲット機器は、前記読み取り手段によって読み取られたユニットディレクトリのバージョンのエントリの値が１で、当該ユニットディレクトリがディレクトリＩＤのエントリを含んでいない場合、当該ユニットディレクトリのアドレスをＩＥＥＥ１３９４．３で定められたコネクトのパラメータとして付け加えることを特徴とする請求項３に記載の通信システム。
【請求項６】
前記イニシエータ機器は、前記ターゲット機器からＩＥＥＥ１３９４．３で定められたコネクトのパラメータを受信した場合、付加されたパラメータの有無を判定する機能を更に有することを特徴とする請求項３または４に記載の通信システム。
【請求項７】
前記イニシエータ機器は、前記付加されたパラメータがある場合に、該パラメータで指定されるユニットディレクトリが存在するかどうか確認する第１の確認手段と、前記第１の確認手段によって存在が確認された場合に当該ユニットディレクトリの内容がバージョンのエントリを除いてＩＥＥＥ１３９４．３で定められたイニシエータ用のユニットディレクトリであることを確認する第２の確認手段とを更に有することを特徴とする請求項６に記載の通信システム。
【請求項８】
前記イニシエータ機器は、前記第１の確認手段によって存在が確認されなかった場合、または、第２の確認手段によってＩＥＥＥ１３９４．３で定められたイニシエータ用のユニットディレクトリであることが確認されなかった場合、コネクト拒否を前記ターゲット機器に返すことを特徴とする請求項７に記載の通信システム。
【請求項９】
前記イニシエータ機器は、前記第１の確認手段によって存在が確認され、かつ、前記第２の確認手段によってＩＥＥＥ１３９４．３で定められたイニシエータ用のユニットディレクトリであることが確認された場合、前記パラメータで指定されたサービスＩＤが当該パラメータで指定されたユニットディレクトリによってサポートされているかどうか判定する機能を更に有することを特徴とする請求項７に記載の通信システム。
【請求項１０】
前記イニシエータ機器は、前記第１の確認手段によって存在が確認され、かつ、前記第２の確認手段によってＩＥＥＥ１３９４．３で定められたイニシエータ用のユニットディレクトリであることが確認された場合、前記パラメータで指定されたサービスＩＤが該パラメータで指定されたユニットディレクトリによってサポートされていなければ、コネクト拒否を前記ターゲット機器に返すことを特徴とする請求項９に記載の通信システム。
【請求項１１】
前記イニシエータ機器は、前記第１の確認手段によって存在が確認され、かつ、前記第２の確認手段によってＩＥＥＥ１３９４．３で定められたイニシエータ用のユニットディレクトリであることが確認された場合、前記パラメータで指定されたサービスＩＤが当該パラメータで指定されたユニットディレクトリによってサポートされていれば、コネクトＯＫを前記ターゲット機器に返すことを特徴とする請求項９に記載の通信システム。
【請求項１２】
コンピュータにより、請求項１又は請求項６乃至請求項１１のいずれか１項に記載のイニシエータ機器を実現するためのコンピュータプログラムを格納することを特徴とするコンピュータ可読の記憶媒体。
【請求項１３】
コンピュータにより、請求項１乃至請求項５のいずれか１項に記載のターゲット機器を実現するためのコンピュータプログラムを格納することを特徴とするコンピュータ可読の記憶媒体。
【請求項１４】
少なくともひとつの論理デバイスを有し、論理デバイスごとに提供可能なサービスを管理するイニシエータ機器とともにネットワークに接続された通信制御装置であって、
接続要求により指定されたイニシエータ機器から、論理デバイスとそれに対する接続手順とを示す情報を獲得する獲得手段と、
前記獲得手段により獲得した情報に基づいて、前記イニシエータ機器の有する論理デバイスが、第１の接続手順で接続可能であるかを判定する第１の判定手段と、
前記第１の判定手段により、前記第１の接続手順で接続可能と判定された論理デバイスに対して、その論理デバイスを特定する識別子と、前記接続要求で指定されたサービスの識別子とを指定して、前記イニシエータ機器との間において前記第１の接続手順で接続を確立する接続手段と、
前記接続手段による接続を介して、前記指定した論理デバイスにより、前記指定したサービスを要求する要求手段と
を備えることを特徴とする通信制御装置。
【請求項１５】
前記獲得手段により獲得した情報に基づいて、前記イニシエータ機器の有する論理デバイスが、第２の接続手順で接続可能であるかを判定する第２の判定手段を更に備え、
前記接続手段は、前記第２の判定手段により、前記第２の接続手順で接続可能と判定された論理デバイスに対して、前記接続要求で指定されたサービスの識別子を指定して、前記イニシエータ機器との間において前記第２の接続手順で接続を確立し、
前記要求手段は、前記接続手段による接続を介して前記指定したサービスを要求することを特徴とする請求項１４に記載の通信制御装置。
【請求項１６】
接続要求に応じて、論理デバイスの識別子とサービスの識別子とを指定して、あるいは、サービスの識別子を指定して接続を要求するターゲット機器とともにネットワークに接続された通信制御装置であって、
前記ターゲット機器から接続要求を受けた場合、その要求に論理デバイスを特定する識別子が含まれているか判定する第１の判定手段と、
前記第１の判定手段により前記識別子が含まれていると判定された場合に、該識別子により特定される論理デバイスが、前記接続要求に含まれたサービスの識別子で特定されるサービスを提供するか判定する第２の判定手段と、
前記第２の判定手段によりサービスが提供されると判定された場合に、前記接続要求に応答して接続を確立する接続手段と、
前記接続手段による接続を介して、前記指定された論理デバイスにより、前記指定されたサービスを提供する提供手段と
を備えることを特徴とする通信制御装置。
【請求項１７】
前記第１の判定手段により、前記接続要求に論理デバイスを特定する識別子が含まれていないと判定された場合に、前記接続要求に含まれたサービスの識別子で特定されるサービスを前記通信制御装置が提供するか判定する第３の判定手段を更に備え、
前記接続手段は、前記第３の判定手段によりサービスが提供されると判定された場合にも、前記接続要求に応答して接続を確立し、
前記提供手段は、前記接続手段による接続を介して前記指定されたサービスを提供することを特徴とする請求項１６に記載の通信制御装置。
【請求項１８】
請求項１４または１５に記載の通信制御装置をターゲット機器として、請求項１６または１７に記載の通信制御装置をイニシエータ機器として互いに接続してなることを特徴とする通信システム。
【請求項１９】
少なくともひとつの論理デバイスを有し、論理デバイスごとに提供可能なサービスを管理するイニシエータ機器とともにネットワークに接続された通信制御装置の制御方法であって、
接続要求により指定されたイニシエータ機器から、論理デバイスとそれに対する接続手順とを示す情報を獲得する獲得工程と、
前記獲得工程により獲得した情報に基づいて、前記イニシエータ機器の有する論理デバイスが、第１の接続手順で接続可能であるかを判定する第１の判定工程と、
前記第１の判定工程により、前記第１の接続手順で接続可能と判定された論理デバイスに対して、その論理デバイスを特定する識別子と、前記接続要求で指定されたサービスの識別子とを指定して、前記イニシエータ機器との間において前記第１の接続手順で接続を確立する接続工程と、
前記接続工程による接続を介して、前記指定した論理デバイスにより、前記指定したサービスを要求する要求工程と
を備えることを特徴とする通信制御装置の制御方法。
【請求項２０】
前記獲得工程により獲得した情報に基づいて、前記イニシエータ機器の有する論理デバイスが、第２の接続手順で接続可能であるかを判定する第２の判定工程を更に備え、
前記接続工程は、前記第２の判定工程により、前記第２の接続手順で接続可能と判定された論理デバイスに対して、前記接続要求で指定されたサービスの識別子を指定して、前記イニシエータ機器との間において前記第２の接続手順で接続を確立し、
前記要求工程は、前記接続工程による接続を介して前記指定したサービスを要求することを特徴とする請求項１９に記載の通信制御装置の制御方法。
【請求項２１】
接続要求に応じて、論理デバイスの識別子とサービスの識別子とを指定して、あるいは、サービスの識別子を指定して接続を要求するターゲット機器とともにネットワークに接続された通信制御装置の制御方法であって、
前記ターゲット機器から接続要求を受けた場合、その要求に論理デバイスを特定する識別子が含まれているか判定する第１の判定工程と、
前記第１の判定工程により前記識別子が含まれていると判定された場合に、該識別子により特定される論理デバイスが、前記接続要求に含まれたサービスの識別子で特定されるサービスを提供するか判定する第２の判定工程と、
前記第２の判定工程によりサービスが提供されると判定された場合に、前記接続要求に応答して接続を確立する接続工程と、
前記接続工程による接続を介して、前記指定された論理デバイスにより、前記指定されたサービスを提供する提供工程と
を備えることを特徴とする通信制御装置の制御方法。
【請求項２２】
前記第１の判定工程により、前記接続要求に論理デバイスを特定する識別子が含まれていないと判定された場合に、前記接続要求に含まれたサービスの識別子で特定されるサービスを前記通信制御装置が提供するか判定する第３の判定工程を更に備え、
前記接続工程は、前記第３の判定工程によりサービスが提供されると判定された場合にも、前記接続要求に応答して接続を確立し、
前記提供工程は、前記接続工程による接続を介して前記指定されたサービスを提供することを特徴とする請求項２１に記載の通信制御装置の制御方法。
【請求項２３】
コンピュータにより、請求項１４乃至１７のいずれか１項に記載の通信制御装置を実現するためのコンピュータプログラムを格納することを特徴とするコンピュータ可読の記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、２機器間のデータ転送の制御を行うための通信制御装置及び方法に関するもので、特に通信プロトコルとしてＩＥＥＥ１３９４を使用する通信制御装置及び方法に関する。
【０００２】
【従来の技術】
ＩＥＥＥ（米国電気電子学会）で規定された通信規格のひとつに、ＩＥＥＥ１３９４と呼ばれるものがある。ＩＥＥＥ１３９４で規定された通信方式は、ハンドシェイク方式に比べて高速で、しかも双方向通信が可能である。また、メモリバスモデルのインターフェースであり、ＩＥＥＥ１３９４シリアルバスで接続された機器は、相手の指定したアドレスにアクセスすることができる。このＩＥＥＥ１３９４は広範囲に応用するための物理層及びリンク層のプロトコルを定めたもので、機器ごとの詳細なプロトコルは定められていない。
【０００３】
そのため、物理層・リンク層としてＩＥＥＥ１３９４を利用したトランスポート層のプロトコルとして、ＳＢＰ−２（ｓｅｒｉａｌ  ｂｕｓ  ｐｒｏｔｏｃｏｌ−２）なるプロトコルが定義されている。ＳＢＰ−２は、ＩＥＥＥ１３９４のメモリバスモデルとしての特長を生かしたプロトコルであり、これに従えばコマンドの受信側がそれ自身の都合に応じて送信側からデータを受信できる。このＳＢＰ−２で接続される２つのデバイスは、コマンドの送信側がイニシエータ、受信側がターゲットと呼ばれ、通信を開始するに当たってのイニシアチブはイニシエータがとる。そのためにログイン動作はイニシエータのみが行え、ターゲットは原則的にはイニシエータからの働きかけに応える動作を行うことになる。
【０００４】
ＳＢＰ−２によれば、イニシエータからログインされると、イニシエータは、データの送受信のために使用されるメモリアドレス等が書かれたＯＲＢと呼ばれるブロックを作成し、そのＯＲＢのアドレスをターゲットに通知する。ターゲットは、通知されたＯＲＢを呼んで、そこに記載されたアドレスからデータを読み出したり、あるいはそのアドレスにデータを書き込むことで、データの送受信を実現している。このために、ＯＲＢのアドレスはターゲットにおいてキューイングされ、それに対するレスポンスはイニシエータにおいてキューイングされる。ターゲットはキューイングされたＯＲＢを順に処理し、レスポンスをイニシエータに返す。処理すべきＯＲＢが含まれたキューをアクティブなキューと呼ぶ。
【０００５】
さらにこのＳＢＰ−２の上に、ターゲットからイニシエータに対してログインを促すリバースログインなどを規定したＩＥＥＥ１３９４．３なる規格が、ＳＢＰ−２と同じくトランスポート層のプロトコルとして提案されている。このＩＥＥＥ１３９４．３においては、ログイン動作はイニシエータのみが行え、ターゲットは原則的にはイニシエータからの働きかけに応える動作を行うことになるが、イニシエータによるログインを促すためのリバースログインという動作がターゲットからは可能となっている。
【０００６】
このように、イニシエータの方がイニシアチブをとる構成上、通常はイニシエータの方が有する資源が多く、そのために規格上もイニシエータにより種々のサービスを提供させ、ターゲットから所望のサービスを指定してそのサービスを受ける、というものになっている。
【０００７】
【発明が解決しようとする課題】
ここで、ＩＥＥＥ１３９４の規格においては、互いに接続される各ノードが１つのデバイスを構成するものとされている。これは、ひとつのノード内で複数のデバイスを管理することの煩雑さ故に、各ノードは単一のデバイスであるという想定の下に規格化された、たとえばＳＣＳＩなどにおける規定をそのまま継承しているためである。このため、ＩＥＥＥ１３９４．３で規定されているターゲットからＩＥＥＥ１３９４．３で規定されているイニシエータへ、ＩＥＥＥ１３９４．３で規定されている方法で接続（コネクト）するとき、ターゲットはイニシエータに対し、サービスを特定するパラメータとしてサービスのＩＤしか特定しなかった。
【０００８】
したがって、現在のＩＥＥＥ１３９４．３で規定されている接続方法では、イニシエータがその内部に複数の論理デバイスを含有しているとき、その論理デバイスを指定する方法がない。そのためひとつのイニシエータ内の複数の論理デバイスが同じＩＤを有するサービスをサポートしているとき、ターゲットがイニシエータ内の特定の論理デバイスのサービスの利用を欲しても、ＩＥＥＥ１３９４．３で規定されている接続方法ではその論理デバイスを特定することができなかった。
【０００９】
本発明は上記従来例に鑑みてなされたもので、イニシエータが複数の論理デバイスを有する場合には、イニシエータにおいて各論理デバイスの管理を可能ならしめ、ターゲットからは論理デバイスの指定を行った上で各論理デバイスが提供するサービスの指定を行えるようにした通信制御装置及び方法を提供することを目的とする。
【００１０】
【課題を解決するための手段】
上記目的を達成するために本発明は次のような構成からなる。
【００１１】
複数の電子機器を有する通信システムであって、
ＩＥＥＥ１３９４．３で定められたイニシエータの役割をはたすイニシエータ機器が、
ＩＥＥＥ１３９４．３で定められたバージョンのエントリの値を持つ第１のユニットディレクトリと、
ＩＥＥＥ１３９４．３で定められた値とは異なるバージョンのエントリの値を持つ第２のユニットディレクトリと
を備え、
ＩＥＥＥ１３９４．３で定められたターゲットの役割を果たすターゲット機器が、
前記イニシエータ機器が提供しているサービスを知るために、前記イニシエータ機器が備えている前記第１のユニットディレクトリと前記第２のユニットディレクトリの少なくとも１つを読み取る読み取り手段と、
前記読み取り手段によって前記第１のユニットディレクトリ又は前記第２のユニットディレクトリが読み取られた場合、読み取られたユニットディレクトリのバージョン以外のエントリをＩＥＥＥ１３９４．３の規定にしたがって解析する解析手段とを備える。
【００２２】
あるいは、少なくともひとつの論理デバイスを有し、論理デバイスごとに提供可能なサービスを管理するイニシエータ機器とともにネットワークに接続された通信制御装置であって、
接続要求により指定されたイニシエータ機器から、論理デバイスとそれに対する接続手順とを示す情報を獲得する獲得手段と、
前記獲得手段により獲得した情報に基づいて、前記イニシエータ機器の有する論理デバイスが、第１の接続手順で接続可能であるかを判定する第１の判定手段と、
前記第１の判定手段により、前記第１の接続手順で接続可能と判定された論理デバイスに対して、その論理デバイスを特定する識別子と、前記接続要求で指定されたサービスの識別子とを指定して、前記イニシエータ機器との間において前記第１の接続手順で接続を確立する接続手段と、
前記接続手段による接続を介して、前記指定した論理デバイスにより、前記指定したサービスを要求する要求手段とを備える。
【００２３】
更に好ましくは、前記獲得手段により獲得した情報に基づいて、前記イニシエータ機器の有する論理デバイスが、第２の接続手順で接続可能であるかを判定する第２の判定手段を更に備え、
前記接続手段は、前記第２の判定手段により、前記第２の接続手順で接続可能と判定された論理デバイスに対して、前記接続要求で指定されたサービスの識別子を指定して、前記イニシエータ機器との間において前記第２の接続手順で接続を確立し、
前記要求手段は、前記接続手段による接続を介して前記指定したサービスを要求する。
【００２４】
あるいは、接続要求に応じて、論理デバイスの識別子とサービスの識別子とを指定して、あるいは、サービスの識別子を指定して接続を要求するターゲット機器とともにネットワークに接続された通信制御装置であって、
前記ターゲット機器から接続要求を受けた場合、その要求に論理デバイスを特定する識別子が含まれているか判定する第１の判定手段と、
前記第１の判定手段により前記識別子が含まれていると判定された場合に、該識別子により特定される論理デバイスが、前記接続要求に含まれたサービスの識別子で特定されるサービスを提供するか判定する第２の判定手段と、
前記第２の判定手段によりサービスが提供されると判定された場合に、前記接続要求に応答して接続を確立する接続手段と、
前記接続手段による接続を介して、前記指定された論理デバイスにより、前記指定されたサービスを提供する提供手段とを備える。
【００２５】
更に好ましくは、前記第１の判定手段により、前記接続要求に論理デバイスを特定する識別子が含まれていないと判定された場合に、前記接続要求に含まれたサービスの識別子で特定されるサービスを前記通信制御装置が提供するか判定する第３の判定手段を更に備え、
前記接続手段は、前記第３の判定手段によりサービスが提供されると判定された場合にも、前記接続要求に応答して接続を確立し、前記提供手段は、前記接続手段による接続を介して前記指定されたサービスを提供する。
【００２６】
【発明の実施の形態】
［第１の実施の形態］
以下、図面を参照し、本発明の実施形態である通信システム及びそれを構成するイニシエータとターゲットについて詳細に説明する。なお、以下の説明で「本発明の規定に準拠」との表現、あるいはそれに類する表現をする場合があるが、これは、本発明に係るシステムや装置あるいは方法などの構成や手順（実施形態中で説明される）による限定を表すための表現であって、発明が規格や取り決めそのものであることを意味するものではない。
【００２７】
＜システムの構成＞
本実施形態の概略は次のようなものである。すなわち、ＩＥＥＥ１３９４．３の規定によれば、イニシエータのノードが有するデバイス（ユニット）を定義するためのイニシエータユニットディレクトリは、ひとつの物理ノード（１３９４シリアルバスが接続されたノードを指す。物理デバイスとも呼ぶ）はひとつしか持てないとされている。これを拡張し、ひとつの物理ノードにつき複数のイニシエータユニットディレクトリ持ってもよいことにする。そしてそれぞれのイニシエータユニットディレクトリに識別子をつけ、ターゲットからイニシエータに対してＩＥＥＥ１３９４．３で規定されているキューをコネクトするとき必要であれば、前記識別子を論理デバイスを指定するパラメータとして、コネクトリクエストコマンドのパラメータに付加する。なお、論理デバイスとは、ひとつの物理ノードを構成するデバイスそれぞれを指す。たとえば、コンピュータが物理ノードであるとすれば、それにローカル接続されたスキャナやプリンタ、モデムなどがそれぞれ論理デバイスとなり得る。
【００２８】
本発明が適用される機器構成の概略は図１６に示されている。そして、各ノードの構成を定義したデータが登録されているコンフィグＲＯＭの中の構成の一例は図３Ａ、図３Ｂで示される。
【００２９】
図１６において、本システムのイニシエータは、論理デバイスＡ，Ｂ，Ｃを備えている。本例ではこのデバイスはプリンタであるものとする。同じ機器であるために、各論理デバイスは同じサービスを提供する。ここではサービスＡ，Ｂ，Ｃをそれぞれ提供している。コンフィグＲＯＭ（ＣＯＮＦＩＧＲＯＭ）には、各論理デバイスが定義されている。
【００３０】
一方、ターゲットには、イニシエータの提供するサービスを利用するクライアントを有する。イニシエータとターゲットとは１３９４シリアルバスで接続されており、双方とも１３９４回線制御部を介して接続される。
【００３１】
図１は本発明を適応するＩＥＥＥ１３９４．３で規定されたターゲット（以下ターゲット）の電子機器の内部のブロック構成図である。１は本発明を制御するＣＰＵ、２はＣＰＵ１のワークエリアを提供するＲＡＭ、３は本発明のプログラムを提供するハードディスク（フロッピーディスク、ＣＤＲＯＭ、ＭＯ、ＲＯＭ、磁気テープ等でもよい）、５はＩＥＥＥ１３９４回線制御部、８はメインバスである。
【００３２】
図２は本発明を適応するＩＥＥＥ１３９４．３で規定されたイニシエータ（以下イニシエータ）の電子機器の内部のブロック構成図である。１１は本発明を制御するＣＰＵ、１２はＣＰＵ１１のワークエリアを提供するＲＡＭ（コンフィグＲＯＭはここに格納される）、１３は本発明のプログラムを提供するハードディスク（フロッピーディスク、ＣＤＲＯＭ、ＭＯ、ＲＯＭ、磁気テープ等でもよい）、１５はＩＥＥＥ１３９４回線制御部、１８はメインバスである。尚、ＩＥＥＥ１３９４回線制御部にはＩＥＥＥ１３９４、ＳＢＰ−２（Ｓｅｒｉａｌ  Ｂｕｓ  ｐｒｏｔｏｃｏｌ−２）で規定されている規約が実装されているとする。
【００３３】
尚、本発明は特に断らない限り、ターゲット、イニシエータともにＣＰＵがメインバスを介してＲＡＭ、ハードディスク、ＩＥＥＥ１３９４回線制御部を本発明のプログラムに則り制御して動作する。また、ＩＥＥＥ１３９４回線制御部は、ＩＥＥＥ１３９４プロトコル制御部とも呼ばれるが、本実施形態においては両者は同一のものである。
【００３４】
＜コンフィグＲＯＭの内容＞
図３Ａに本発明に係るイニシエータのコンフィグＲＯＭの内容の一例をあげる。構成情報は階層構造のディレクトリで管理される。すなわち、ルートディレクトリの下に、論理デバイスを定義するインスタンスディレクトリがあり、その下に論理デバイスを更に詳細に定義するためのユニットディレクトリがある。更に各論理デバイスの提供するサービス等を定義したフィーチャーディレクトリがその下にある。
【００３５】
図３Ｂはその詳細を示す。ルートディレクトリ３０１の下には、インスタンスとして各論理デバイスを定義するインスタンスディレクトリがリンクされている。たとえばインスタンスディレクトリ３０２には、論理デバイスであるプリンタＢのモデル識別子が記述されているのに加えて、さらにその下のユニットディレクトリ３０３へのリンクが用意されている。ユニットディレクトリには、プロトコルを指定するスペシファイア（本実施形態ではＩＥＥＥ１３９４を示す０ｘ５０２９が指定される）と、プロトコルのバージョン、さらにサービスを定義するフィーチャーディレクトリ３０４へのリンクが含まれる。フィーチャーディレクトリ３０４には、論理デバイスＢが提供するサービスである、サービスＡ，Ｂ，Ｃが定義されている。
【００３６】
ここで注目すべきは、イニシエータユニットディレクトリ１はＩＥＥＥ１３９４．３が規定するとおりであるが、イニシエータユニットディレクトリ２についてはＩＥＥＥ１３９４．３が規定するバージョンの値が異なり、それ以外の項目はＩＥＥＥ１３９４．３の規定とおりである。すなわち、ＩＥＥＥ１３９４．３が規定するイニシエータユニットディレクトリのバージョンの値は０だがイニシエータユニットディレクトリ２では１である。このバージョン番号により、本来のＩＥＥＥ１３９４．３の規格であるか、本実施形態で説明する拡張規格であるかが判定可能となる。
【００３７】
そして、イニシエータユニットディレクトリ３にはイニシエータユニットディレクトリ２の特徴に加えて、ＤＩＲＥＣＴＯＲＹ＿ＩＤ（ディレクトリＩＤ）の項目がある。
【００３８】
なお本発明の前提として、特に断らない限り、ターゲットにはＩＥＥＥ１３９４．３が規定するターゲットに必要な機能が、そしてイニシエータにはイニシエータに必要な機能が実装されているとする。そしてターゲットとイニシエータはＩＥＥＥ１３９４で規定された回線で物理的に接続されているとする（図１６参照）。
【００３９】
＜ターゲットの動作＞
次に本発明に係るターゲットの動作を図４Ａ、図４Ｂ、図５、図６のフローチャートを用いて詳細に説明する。最初に図４Ａ，４Ｂに従い説明する。
【００４０】
図４Ａ，４Ｂのフローチャートを実現するためのプログラムがターゲットの機器初期化の過程で起動された後、アプリケーションからの物理デバイス、論理デバイスとサービスを指定したパラメータを伴った接続要求（コネクトの指示）を待っている（Ｓ１０１）。もしそのような接続要求を受信したならば、１３９４回線制御部５に、今１３９４回線で接続されている物理デバイス（物理ノード）をすべて列挙するように要求する（Ｓ１０２）。なお、図では１３９４プロトコル制御部と記載されているが、すべて１３９４回線制御部のことである。
【００４１】
１３９４回線制御部５がＩＥＥＥ１３９４回線を介して現在接続されている物理デバイス名を読み取る（Ｓ１０３）。１３９４回線制御部５から現在接続されている物理デバイスのリストを受け取ると、その中にアプリケーションが指定した物理デバイスがあるかどうか調べる（Ｓ１０４）。もしなければ、アプリケーションに指定した物理デバイスがないことを通知する（Ｓ１０６）。そしてＳ１０１へ戻る。
【００４２】
もし、物理デバイスのリストにアプリケーションが指定した物理デバイスがあれば、その物理デバイスのルートディレクトリの読み込みを１３９４回線制御部５に要求する（Ｓ１０５）。１３９４回線制御部５が読んだルートディレクトリの中にまだその属性を調査していないインスタンスディレクトリのエントリがあるどうかルートディレクトリを調べる（Ｓ１０７）。
【００４３】
すべてのインスタンスディレクトリのエントリに関して調査済みであれば、ＭＯＤＥＬＦＬＧがＯＮかＯＦＦか調べる（Ｓ１０８）。もしＭＯＤＥＬＦＬＧがＯＮであれば、ＩＥＥＥ１３９４．３と本発明に係る方法以外の方法で通信（接続）ができる可能性があるので、もし可能であれば、他の通信プロトコル（例えばＦＣＰ等）で接続を試みる（図４Ｂ：Ｓ１０９）。そして終了後Ｓ１０１へ進む。もしＭＯＤＥＬＦＬＧがＯＦＦであれば、アプリケーションに指定した論理デバイスがないことを通知する（Ｓ１０６）。そしてＳ１０１へ戻る。
【００４４】
一方、ステップＳ１０７において、もし未調査のインスタンスディレクトリのエントリが１３９４回線制御部５が読んだルートディレクトリにあれば、その中の一番若いアドレスのインスタンスディレクトリを読むように１３９４回線制御部５に要求する（Ｓ１１０）。１３９４回線制御部５が読みこんだインスタンスディレクトリのモデルのエントリに書かれているモデルがアプリケーションがコネクトを要求した論理デバイスと一致するかどうか調べる（Ｓ１１１）。もし一致しなければＳ１０７へ戻る。もし一致すればＭＯＤＥＬＦＬＧをＯＮにする（Ｓ１１２）。ＭＯＤＥＬＦＬＧは図４Ａ，４Ｂの手順のプログラムが起動するとき、ＯＦＦに初期化されているものとする。
【００４５】
未調査のユニットディレクトリのエントリが１３９４回線制御部５が読んだインスタンスディレクトリにあるかどうか調べる（Ｓ１１３）。もしすべてのユニットディレクトリのエントリが調査済みであれば、このインスタンスディレクトリは、本実施形態で定義する手順（プロトコル）に適合しないと判断してステップＳ１０７へ進む。
【００４６】
もし未調査のユニットディレクトリのエントリが１３９４回線制御部５が読んだインスタンスディレクトリにあれば、その中の一番若いアドレスのユニットディレクトリを読むように１３９４回線制御部５に要求する（Ｓ１１４）。１３９４回線制御部５が読みこんだユニットディレクトリのスペシファイアＩＤの項目の値が０ｘ５０２９（ＩＥＥＥ１３９４．３を作成した団体の識別子）であるか調べる（Ｓ１１５）。スペシファイアＩＤの項目の値が０ｘ５０２９でなければ、このユニットディレクトリは１ＥＥＥ１３９４をサポートしていないと判断し、Ｓ１０７へ進む。
【００４７】
スペシファイアＩＤの項目の値が０ｘ５０２９であれば、１３９４回線制御部５が読みこんだユニットディレクトリのバージョンエントリの値を調べる（Ｓ１１６）。ユニットディレクトリのバージョンエントリの値が０ｘ００であれば、このユニットディレクトリはＩＥＥＥ１３９４．３完全準拠のものであると判断し、図５のＡへ進む。もしユニットディレクトリのバージョンエントリの値が０ｘ０１であれば（Ｓ１１７）、ＩＥＥＥ１３９４．３を拡張した、本実施形態で定義する手順に従うものと判断し、図５のＢへ進む。ユニットディレクトリのバージョンエントリの値が０ｘ００でも、０ｘ０１でもなければ、他のプロトコルで通信できる可能性があるため、可能であればその処理を行う（Ｓ１０９）。
【００４８】
＜本発明に係るターゲットの動作＞
ここからは、このユニットディレクトリがＩＥＥＥ１３９４．３を拡張した規格に準拠する、本発明に係るターゲットの動作を図６を用いて説明する。
【００４９】
読み込んだユニットディレクトリにディレクトリＩＤのエントリがあるかどうか調べる（Ｓ３０１）。もしディレクトリＩＤのエントリがあればその値をＩＮＳ（ディレクトリ識別子格納場所）に格納する（Ｓ３０３）。もしなければ読み込んだユニットディレクトリの先頭アドレスをＩＮＳに格納する（Ｓ３０２）。
【００５０】
アプリケーションから指定されたサービスに対応したサービスＩＤとＩＮＳに格納されたユニットディレクトリにディレクトリＩＤを組み込んだコネクトコントロールリクエストを作成する（Ｓ３０４）。コネクトコントロールリクエストは図９に示したとおりである。すなわち、先頭のＲｑフィールドの値はリクエストを表す"１"、ｃｔｒｌ＿ｆｕｎｃｔｉｏｎフィールドの値はコネクトであることを表す"ＣＯＮＮＥＣＴ"であり、ｒｅｓｐｏｎｓｅフィールドについては、リクエストなのでその値は特に問題にならない。その他のフィールドは図９に示すとおりとなる。ここではコネクトコントロールリクエストのサービスＩＤを"ＰＲＮ"（印刷）であるとする。またＤＩＲＥＣＴＯＲＹ＿ＩＤをここでは２Ｆ４２５６であるとする。ＤＩＲＥＣＴＯＲＹ＿ＩＤの定義は図１４に示してある。すなわち、ターゲットが接続を試みたイニシエータ中のユニットディレクトリを特定する値である。
【００５１】
そして、すでに当該イニシエータの物理デバイスとＳＢＰ−２のログインが確立しているか調べる（Ｓ３０５）。もし確立していなければ、１３９４回線制御部５に、ＩＥＥＥ１３９４．３規定のリバースログイン処理を要求する（Ｓ３０６）。リバースログインでログインが確立できたかどうか確認し（Ｓ３０７）、もし確立できなければ、アプリケーションにコネクト失敗を報告しステップＳ３０８へ進む。
【００５２】
ＳＢＰ−２のログインが確立していたり、リバースログイン処理が成功したとき、前記のコネクトコントロールリクエスト（単にコネクトとも呼ぶ）をＩＥＥＥ１３９４．３規定の方法でイニシエータに送信するように１３９４回線制御部５に要求する（Ｓ３０９）。そして１３９４回線制御部５が当該イニシエータの物理デバイスから何か送信されてくることを待つ（Ｓ３１０）。１３９４回線制御部５が当該イニシエータの物理デバイスから何か受信したとき、それがコネクトに対するレスポンス（単にコネクトレスポンスとも呼ぶ）かどうか調べる（Ｓ３１１）。コネクトレスポンスがＯＫであれば、図１１に示す値がレスポンスされる。すなわち、Ｒｑフィールドの値が"０"、ｃｔｒｌ＿ｆｕｎｃｔｉｏｎフィールドの値が"ＣＯＮＮＥＣＴ"、ｒｅｓｐｏｎｓｅフィールドの値はＯＫを示す"０"である。
【００５３】
コネクトコントロールリクエストに対するスポンスでなければ、そのコマンドに対応する処理を行う（Ｓ３１２）。コネクトレスポンスであれば、その結果がコネクトＯＫかＮＧ（失敗）かをレスポンス項目で判定する（Ｓ３１３）。コネクトがＮＧであればアプリケーションにコネクト失敗を報告してステップＳ３０８へ進む。コネクトがＯＫであればアプリケーションが要求したサービスが利用可能になったことをアプリケーションに報告する（Ｓ３１４）。そしてアプリケーションの指示に従い、データの送受信をおこない（Ｓ３１５）、アプリケーションの指示によりシャットダウン処理を行う（Ｓ３１６）。
【００５４】
他にアクティブなキューがログイン上に存在するかどうかを調べ（Ｓ３１７）、存在しなければログアウト処理を１３９４回線制御部５を要求して（Ｓ３１８）終了する。存在すればそのまま終了する。
【００５５】
＜ＩＥＥＥ１３９４．３準拠のターゲットの動作＞
ここからはこのユニットディレクトリがＩＥＥＥ１３９４．３準拠のときのターゲットの動作を図５を用いて説明する。
【００５６】
まずアプリケーションから指定されたサービスに対応したサービスＩＤを組み込んだコネクトコントロールリクエストを作成する（Ｓ２０１）。図８にその内容を示す。ｃｎｔｒｌ＿ｆｕｎｃｔｉｏｎフィールドがコネクトコントロールリクエストを示す"ＣＯＮＮＥＣＴ"であり、残りのフィールドは図示したとおりである。ここではサービスＩＤを"ＰＲＮ"とする。
【００５７】
そして、すでに当該イニシエータの物理デバイスとＳＢＰ−２のログインが確立しているか調べる（Ｓ２０２）。もし確立していなければ、１３９４回線制御部５にＩＥＥＥ１３９４．３規定のリバースログイン処理を要求する（Ｓ２０３）。もしリバースログインでログインが確立できたかどうか確認し（Ｓ２０４）、もし確立できなければ、アプリケーションにコネクト失敗を報告し、ステップＳ２０５へ進む。
【００５８】
ＳＢＰ−２のログインが確立していたり、リバースログイン処理が成功したとき、ステップＳ２０１で作成したコネクトコントロールリクエストをＩＥＥＥ１３９４．３規定の方法でイニシエータに送信するように１３９４回線制御部５に要求する（Ｓ２０６）。そして１３９４回線制御部５が当該イニシエータの物理デバイスから何か送信されてくることを待つ（Ｓ２０７）。１３９４回線制御部５が当該イニシエータの物理デバイスから何か受信したとき、それがコネクトレスポンスかどうか調べる（Ｓ２０８）。
【００５９】
コネクトレスポンスであれば図１１のレスポンスが返される。コネクトレスポンスでなければ、そのコマンドに対応する処理を行う（Ｓ２０９）。コネクトレスポンスであれば、その結果がコネクトＯＫかＮＧ（失敗）かをレスポンス項目で判定する（Ｓ２１０）。コネクトがＮＧであればアプリケーションにコネクト失敗を報告してＳ２０５へ進む。コネクトがＯＫであればアプリケーションが要求したサービスが利用可能になったことををアプリケーションに報告する（Ｓ２１１）。そしてアプリケーションの指示に従い、データの送受信をおこない（Ｓ２１２）アプリケーションの指示によりシャットダウン処理を行う（Ｓ２１３）。
【００６０】
他にアクティブなキューがログイン上に存在するかどうかを調べ（Ｓ２１４）、存在しなければログアウト処理を１３９４回線制御部５を要求して（Ｓ２１５）終了する。存在すればそのまま終了する。
【００６１】
＜イニシエータの動作＞
次に本発明に係るイニシエータの動作を図７Ａ乃至図７Ｃを用いて説明する。イニシエータは、本発明を含む機器が初期化されたとき、同時の起動、初期化されるものとする。また、ＳＢＰ−２で規定されているログインの動作は１３９４回線制御部１５が制御するので、ここでは詳細に説明しない。
【００６２】
まず１３９４回線制御部１５から本発明に関わるデータを当該ターゲット機器から受信するのを待つ（Ｓ４０１）。そして受信したデータがキュー０に関わるものかどうかを、対応するＯＲＢのキューの項目（ＩＥＥＥ１３９４．３で規定）を調べる（Ｓ４０２）。もしキュー０に関するものでなければ、そのキュー番号に対応する処理（ＩＥＥＥ１３９４．３で規定）を行う（Ｓ４０３）。Ｓ４０１へ進む。
【００６３】
キュー０に関するものであれば、そのコントロールインフォメーションのｃｎｔｒｌ＿ｆｕｎｃｔｉｏｎの項目（図８，９参照）がコネクトかどうか調べる（Ｓ４０４）。コネクトでなければ、指定されたコントロールファンクションに対応する処理（ＩＥＥＥ１３９４．３で規定）を行い（Ｓ４０５）、Ｓ４０１へ進む。
【００６４】
そのコントロールインフォメーションのｃｎｔｒｌ＿ｆｕｎｃｔｉｏｎの項目（図８，９参照）がコネクトであれば、そのコントロールインフォメーションのＲｑの項目を調べる（Ｓ４０５）。Ｒｑの項目がレスポンスであれば対応する処理（ＩＥＥＥ１３９４．３で規定）を行い（Ｓ４０６）、Ｓ４０１へ進む。
【００６５】
もしそのコントロールインフォメーションのＲｑの項目がリクエストであれば、コントロールインフォメーションにＤＩＲＥＣＴＯＲＹ＿ＩＤの項目（図８，９，１４参照）があるかどうか調べる（Ｓ４０７）。
【００６６】
もしＤＩＲＥＣＴＯＲＹ＿ＩＤの項目があればその他のパラメータはＩＥＥＥ１３９４．３のコネクトコントロールで規定されている通りのパラメータがどうか調べる（Ｓ４０８）。もし規定外であれば対応するエラー処理をおこない（Ｓ４０９）、Ｓ４０１へ進む。
【００６７】
ステップＳ４０８において、もしＤＩＲＥＣＴＯＲＹ＿ＩＤの項目以外のすべてパラメータがＩＥＥＥ１３９４．３のコネクトコントロールで規定通りであれば、ＤＩＲＥＣＴＯＲＹ＿ＩＤの項目で指定されているディレクトリＩＤと同値のディレクトリＩＤを持つユニットディレクトリがイニシエータ内に存在するかどうか調べる（Ｓ４１１）。もしＤＩＲＥＣＴＯＲＹ＿ＩＤと同値のディレクトリＩＤを持つユニットディレクトリがイニシエータ内に存在しなければ、ＤＩＲＥＣＴＯＲＹ＿ＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在するかどうか調べる（Ｓ４１２）。ＤＩＲＥＣＴＯＲＹ＿ＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在しなければコネクトレスポンスのパラメータに"指定されたユニットは存在しない"を設定する（図１５，１２参照）（Ｓ４１３）。そしてＳ４２２へ進む。
【００６８】
ステップＳ４２２では、指定されたコネクトレスポンスのパラメータを含むコネクトレスポンスを作成する。そして１３９４回線制御１５に作成したコネクトレスポンスを送信するように要求する（Ｓ４２３）。そしてＳ４２９へ進む。
【００６９】
ステップＳ４１１において、ＤＩＲＥＣＴＯＲＹ＿ＩＤの項目で指定されているディレクトリＩＤと同値のディレクトリＩＤを持つユニットディレクトリがイニシエータ内に存在するか、または、ＤＩＲＥＣＴＯＲＹ＿ＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在すれば、ＤＩＲＥＣＴＯＲＹ＿ＩＤの指すユニットディレクトリが図１７に示したようなディレクトリの内容を持つかどうか調べる（Ｓ４１４）。もし異なれば、コネクトレスポンスのパラメータに"指定されたユニットは存在しない"を設定する（図１５，１２参照）（Ｓ４１３）。そしてＳ４２２へ進む。図１７は本発明に係るユニットディレクトリの内容を示し、スペシファイヤＩＤ及びバージョンの各エントリが必須であり、ディレクトリＩＤと、提供可能なサービスを定義するフィーチャーディレクトリが必要に応じて付加される。
【００７０】
ステップＳ４１４において、もしＤＩＲＥＣＴＯＲＹ＿ＩＤの指すユニットディレクトリが、本実施形態で説明するディレクトリの内容、すなわち、図１７に示すようなエントリを有するのであれば、コネクトコントロールで指定されたサービスＩＤで要求されたサービスを、指定されたＤＩＲＥＣＴＯＲＹ＿ＩＤの指すユニットディレクトリに対応するユニット（論理デバイス）がサポートしているかどうか調べる（Ｓ４１５）。もしサポートしていなければコネクトレスポンスのパラメータに"指定されたサービスを指定されたユニットはサポートしていない"を設定する（図１５，１３参照）（Ｓ４１６）。Ｓ４２２へ進む。
【００７１】
ステップＳ４０７において、もしディレクトリＩＤの項目がなければ、ＩＥＥＥ１３９４．３のコネクトコントロールで規定されている通りのパラメータがどうか調べる（Ｓ４１０）。もし規定外であれば対応するエラー処理をおこないＳ４２１へ進む。すべてのパラメータが規定通りであればコネクトコントロールで指定されたサービスＩＤで要求されたサービスを、イニシエータはサポートしているかどうか調べる（Ｓ４１７）。
【００７２】
サポートしている場合には、コネクトコントロールで指定されたサービスＩＤで要求されたサービスが必要とするキューの性格、数がコネクトコントロールのキューフィールドで指定されたものと合致するかどうか調べる（Ｓ４１８）。そして合致していなければ、コネクトレスポンスのパラメータに"ミスマッチ"を設定する（図１５、図１０参照）（Ｓ４１９）。Ｓ４２２へ進む。
【００７３】
一方ステップＳ４１８において、もしコネクトコントロールで指定されたサービスＩＤで要求されたサービスが必要とするキューの性格、数がコネクトコントロールのキューフィールドで指定されたものと合致していれば、サービスを要求されたサーバーは指定されたサービスを提供するかどうか調べる（Ｓ４２０）。もし接続しないのであればコネクトレスポンスのパラメータに"接続拒否"を設定する（図１５，図１９参照）（Ｓ４２１）。そしてＳ４２２へ進む。
【００７４】
サービスを要求されたサーバは指定されたサービスを提供するのであれば、コネクトレスポンスのパラメータに"接続ＯＫ"を設定する（図１５、図１１参照）（Ｓ４２４）。そしてＳ４２５へ進む。
【００７５】
指定されたコネクトレスポンスのパラメータを含むコネクトレスポンスを作成する（Ｓ４２５）。そして１３９４回線制御１５に作成したコネクトレスポンスを送信するように要求する（Ｓ４２６）。そしてクライアントの要求に従い１３９４回線制御１５を介してイニシエータとターゲット間でデータの送受信をＩＥＥＥ１３９４．３で規定された方法で行う（Ｓ４２７）。サービスが終了すればクライアントの要求に従い、ＩＥＥＥ１３９４．３で規定された方法でシャットダウン処理を行う（Ｓ４２８）。なお、クライアントとは、ターゲットを介してイニシエータにサービスを要求するアプリケーションを指す。すなわち、図５のステップＳ２１２，２１３、あるいは、図６のステップＳ３１５，３１６における処理に対応して、ステップＳ４２７，Ｓ４２８の処理は行われる。ステップＳ４２７においては、データの送受信が行われると共に、ターゲットから指定されたサービスがイニシエータによって提供される。その際、ターゲットから、イニシエータにより管理されている論理デバイスおよびその論理デバイスによりサポートされるサービスが指定されていれば、指定された論理デバイスによる指定されたサービスが提供される。
【００７６】
たとえば、ターゲットからイニシエータに対して発行するコネクトコントロールファンクションのＤＥＶＩＣＥ＿ＩＤフィールドで、図３Ｂの論理プリンタＢのユニットディレクトリ３０３のアドレスを指定し、論理プリンタＢがサポートするサービスである「印刷」を指定すれば、ターゲットとイニシエータとの間にコネクションが確立される。その後、イニシエータは、ターゲットに対してバッファを提供し、ターゲットからそのバッファに書き込まれるデータを読んで、そのデータに基づいて印刷というサービスを遂行することになる。
【００７７】
その後、そのログイン内にキュー０以外のアクティブなキューがあるかどうか調べ（Ｓ４２９）、もしあればステップＳ４０１へ進む。なければＳＢＰ−２で規定されているログアウト処理を行い、終了する（Ｓ４３０）。
【００７８】
ステップＳ４１０においてパラメータが正常でないと判定された場合、あるいは、ステップＳ４１７において指定されたサービスをイニシエータが提供していないと判定された場合には、それぞれに対応する処理を行って（Ｓ４１０−１）、ステップＳ４１９へ進む。
【００７９】
以上の手順により、イニシエータにおけるコンフィグＲＯＭにより、イニシエータの論理デバイスごとに各論理デバイスで使用可能なサービスを管理することで、ターゲットとイニシエータとのコネクションを、ターゲットからイニシエータの論理デバイス及びサービスを指定して確立することができる。さらに、ターゲットは指定した論理デバイスによりサービスの提供を受けることができる。
【００８０】
以上の構成及び手順により、ＩＥＥＥ１３９４．３ではサポートできなかったイニシエータの役割を持つ１つの物理ノードに複数の論理デバイスが存在し、すくなくとも２つ以上の論理デバイスが同じサービスＩＤであらわされるサービスを提供するとき、ターゲットはそれらのサービスをどの論理デバイスのサービスか特定してアクセスできるようになる。このことはマルチファンククションデバイス等に対して非常に有効である。
【００８１】
また本発明はＩＥＥＥ１３９４．３との下位互換性に特に留意して作成されたものであるため、ＩＥＥＥ１３９４．３を実装していれば非常に少ない工数で本発明を実装可能であるというメリットも提供する。
【００８２】
［第２の実施の形態］
第１の実施の形態では、ユニットディレクトリにディレクトリＩＤを持たせて、それぞれの論理デバイスを区別する手段とした。
【００８３】
それに対して、すべてのインスタンスディレクトリにより、ユニットディレクトリで指定されているフィーチャーディレクトリをそれぞれ指し示させ、ディレクトリＩＤをフィーチャーディレクトリに持たせる（図１８参照）。そして、論理デバイスの識別子として、第１の実施形態におけるコネクトコントロールリクエストのパラメータであるＤＩＲＥＣＴＯＲＹ＿ＩＤに、フィーチャーディレクトリのディレクトリＩＤを設定することによっても、論理デバイスを指定させることができる。
【００８４】
［第３の実施の形態］
第２の実施の形態では、フィーチャーディレクトリにディレクトリＩＤを持たせて、それぞれの論理デバイスを区別する手段とした。第３の実施の形態としては、インスタンスディレクトリにディレクトリＩＤを持たせ、それを論理デバイスの識別子として、第１の実施の形態におけるコネクトコントロールリクエストのパラメータであるＤＩＲＥＣＴＯＲＹ＿ＩＤにインスタンスレクトリのディレクトリＩＤを設定することも可能である。
【００８５】
【発明の効果】
以上の説明したように、イニシエータが複数の論理デバイスを有する場合には、イニシエータにおいて論理デバイスごとの管理を行い、また、ターゲットから論理デバイスを指定してターゲットとイニシエータとの間のコネクションを確立することができる。
【００８６】
それにより、従来ＩＥＥＥ１３９４．３ではサポートできなかった、イニシエータの役割を持つ１つの物理ノードに複数の論理デバイスが存在し、すくなくとも２つ以上の論理デバイスが同じサービスＩＤであらわされるサービスを提供する場合であっても、ターゲットはそれらのサービスをどの論理デバイスのサービスか特定してアクセスできるようになる。このことはマルチファンククションデバイス等に対して非常に有効である。
【００８７】
また本発明のシステムあるいは装置あるいは方法は、ＩＥＥＥ１３９４．３との下位互換性に特に留意して作成されたものであるため、ＩＥＥＥ１３９４．３を実装していれば非常に少ない工数で本発明を実現可能であるというメリットも提供する。
【図面の簡単な説明】
【図１】本発明を実装するターゲット側のブロック図である。
【図２】本発明を実装するイニシエータ側のブロック図である。
【図３Ａ】本発明を実装するイニシエータに実装されるコンフィグＲＯＭの概略階層図である。
【図３Ｂ】本発明を実装するイニシエータに実装されるコンフィグＲＯＭの具体的なエントリの値の一例を示す図である。
【図４Ａ】、
【図４Ｂ】本発明を実装する、ターゲット側の動作を示すフローチャートである。
【図５】本発明を実装する、ターゲット側の動作を示すフローチャートである。
【図６】本発明を実装する、ターゲット側の動作を示すフローチャートである。
【図７Ａ】、
【図７Ｂ】、
【図７Ｃ】本発明を実装する、イニシエータ側の動作を示すフローチャートである。
【図８】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）リクエストの構造図である。
【図９】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）リクエストを本発明を実装するために拡張したものを示す図である。
【図１０】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図でサービスと指定されたキューのタイプがミスマッチのときの構造図である。
【図１１】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図でコネクトがＯＫのときの構造図である。
【図１２】本発明でＩＥＥＥ１３９４．３で規定から拡張されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図でが指定されたユニットディレクトリがないときの構造図である。
【図１３】本発明でＩＥＥＥ１３９４．３で規定から拡張されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図でが指定されたサービスが指定されたユニットディレクトリがないときの構造図である。
【図１４】本発明でＩＥＥＥ１３９４．３で規定から拡張されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）の値とその意味でディレクトリＩＤが拡張項目を示す図である。
【図１５】本発明でＩＥＥＥ１３９４．３で規定から拡張されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの値とその意味で６、７が拡張項目を示す図である。
【図１６】本発明を実装したときのイニシエータ、ターゲット、イニシエータのコンフィグＲＯＭ、本発明モジュール等の関係の一例をモデル化したものを示す図である。
【図１７】本発明を実装したときのユニットディレクトリの構造図である
【図１８】本発明の第２実施形態を実装したときのイニシエータのコンフィグＲＯＭを示す図である。
【図１９】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図で接続拒否のときの構造図である
【図１】
0004484353.tif 000002
【図２】
0004484353.tif 000003
【図３Ａ】
0004484353.tif 000004
【図３Ｂ】
0004484353.tif 000005
【図４Ａ】
0004484353.tif 000006
【図４Ｂ】
0004484353.tif 000007
【図５】
0004484353.tif 000008
【図６】
0004484353.tif 000009
【図７Ａ】
0004484353.tif 000010
【図７Ｂ】
0004484353.tif 000011
【図７Ｃ】
0004484353.tif 000012
【図８】
0004484353.tif 000013
【図９】
0004484353.tif 000014
【図１０】
0004484353.tif 000015
【図１１】
0004484353.tif 000016
【図１２】
0004484353.tif 000017
【図１３】
0004484353.tif 000018
【図１４】
0004484353.tif 000019
【図１５】
0004484353.tif 000020
【図１６】
0004484353.tif 000021
【図１７】
0004484353.tif 000022
【図１８】
0004484353.tif 000023
【図１９】
0004484353.tif 000024