JP4683587B2 - 通信制御装置及び方法 - Google Patents
通信制御装置及び方法 Download PDFInfo
- Publication number
- JP4683587B2 JP4683587B2 JP2000332891A JP2000332891A JP4683587B2 JP 4683587 B2 JP4683587 B2 JP 4683587B2 JP 2000332891 A JP2000332891 A JP 2000332891A JP 2000332891 A JP2000332891 A JP 2000332891A JP 4683587 B2 JP4683587 B2 JP 4683587B2
- Authority
- JP
- Japan
- Prior art keywords
- directory
- unit
- initiator
- ieee
- communication
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40123—Interconnection of computers and peripherals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
Description
【０００１】
【発明の属する技術分野】
本発明は、２機器間のデータ転送の制御を行うための通信制御装置及び方法に関するもので、特に通信プロトコルとしてＩＥＥＥ１３９４を使用する通信制御装置及び方法に関する。
【０００２】
【従来の技術】
ＩＥＥＥ（米国電気電子学会）で規定された通信規格のひとつに、ＩＥＥＥ１３９４と呼ばれるものがある。ＩＥＥＥ１３９４で規定された通信方式は、ハンドシェイク方式に比べて高速で、しかも双方向通信が可能である。また、メモリバスモデルのインターフェースであり、ＩＥＥＥ１３９４シリアルバスで接続された機器は、相手の指定したアドレスにアクセスすることができる。このＩＥＥＥ１３９４は広範囲に応用するための物理層及びリンク層のプロトコルを定めたもので、機器ごとの詳細なプロトコルは定められていない。
【０００３】
そのため、物理層・リンク層としてＩＥＥＥ１３９４を利用したトランスポート層のプロトコルとして、ＳＢＰ−２（ｓｅｒｉａｌ ｂｕｓ ｐｒｏｔｏｃｏｌ−２）なるプロトコルが定義されている。ＳＢＰ−２は、ＩＥＥＥ１３９４のメモリバスモデルとしての特長を生かしたプロトコルであり、これに従えばコマンドの受信側がそれ自身の都合に応じて送信側からデータを受信できる。このＳＢＰ−２で接続される２つのデバイスは、コマンドの送信側がイニシエータ、受信側がターゲットと呼ばれ、通信を開始するに当たってのイニシアチブはイニシエータがとる。そのためにログイン動作はイニシエータのみが行え、ターゲットは原則的にはイニシエータからの働きかけに応える動作を行うことになる。
【０００４】
ＳＢＰ−２によれば、イニシエータからログインされると、イニシエータは、データの送受信のために使用されるメモリアドレス等が書かれたＯＲＢと呼ばれるブロックを作成し、そのＯＲＢのアドレスをターゲットに通知する。ターゲットは、通知されたＯＲＢを読んで、そこに記載されたアドレスからデータを読み出したり、あるいはそのアドレスにデータを書き込むことで、データの送受信を実現している。このために、ＯＲＢのアドレスはターゲットにおいてキューイングされ、それに対するレスポンスはイニシエータにおいてキューイングされる。ターゲットはキューイングされたＯＲＢを順に処理し、レスポンスをイニシエータに返す。
【０００５】
さらにこのＳＢＰ−２の上に、ターゲットからイニシエータに対してログインを促すリバースログインなどを規定したＩＥＥＥ１３９４．３なる規格が、ＳＢＰ−２と同じくトランスポート層のプロトコルとして提案されている。このＩＥＥＥ１３９４．３においては、ログイン動作はイニシエータのみが行え、ターゲットは原則的にはイニシエータからの働きかけに応える動作を行うことになるが、イニシエータによるログインを促すためのリバースログインという動作がターゲットからは可能となっている。
【０００６】
このように、イニシエータの方がイニシアチブをとる構成上、規格上もイニシエータにより種々のサービスを提供させ、ターゲットから所望のサービスを指定してそのサービスを受ける、というものになっている。
【０００７】
【発明が解決しようとする課題】
ここで、ＩＥＥＥ１３９４の規格においては、互いに接続される各ノードが１つのデバイスを構成するものとされている。これは、ひとつのノード内で複数のデバイスを管理することの煩雑さ故に、各ノードは単一のデバイスであるという想定の下に規格化された、たとえばＳＣＳＩなどにおける規定をそのまま継承しているためである。
【０００８】
このためＩＥＥＥ１３９４．３の規定では、イニシエータのノードが有する論理デバイス（ユニット）を定義するためのイニシエータユニットディレクトリは、ひとつの物理ノード（１３９４シリアルバスが接続されたノードを指す。物理デバイスとも呼ぶ）についてひとつしか持てないと規定されている。この規定により、イニシエータはユニットディレクトリを２つ以上持つことが許されず、ある物理デバイスが、ＩＥＥＥ１３９４．３が規定する物理デバイスを構成する論理デバイスを複数持ち、しかもその役割がイニシエータであるとき、その物理デバイスと各論理デバイスと各サービスの関係を適切な階層構造で他の機器に対して表現することができなかった。
【０００９】
図１９にユニットディレクトリの一例を示す。ＩＥＥＥ１３９４．３では、少なくとも図１８のようなエントリを持つユニットディレクトリを、ＩＥＥＥ１３９４．３で規定するイニシエータの役割が可能な各ノードに１個のみ持つことを許していた。そして、ユニットディレクトリに含まれるフィーチャーディレクトリオフセットでアドレスを特定された場所にあるフィーチャーディレクトリに、そのノードが提供可能なサービスをＩＥＥＥ１３９４．３で規定された記述方法で記述することにより、そのノードが他ノードに対してＩＥＥＥ１３９４．３を介して提供が可能なサービスを知らしめることができる。図２０はそのフォーマットの１例である。
【００１０】
そして、ＩＥＥＥ１３９４．３により規定されるイニシエータ のルートディレクトリ、インスタンスディレクトリ、ユニットディレクトリ、フィーチャーディレクトリをＩＥＥＥ１３９４．３で規定するイニシエータの役割が可能な各ノードが持つとすれば、階層構造の一例は図２１のとおりである。なお、バスインフォメーション、ルートディレクトリ、インスタンスディレクトリの記述方法はＩＥＥＥ１２１２Ｒで規定されているので詳細は省略する。
【００１１】
しかしＩＥＥＥ１３９４．３では、各イニシエータノードはイニシエータユニットディレクトリを２つ以上持つことを許されていないため、イニシエータにおける複数のインスタンスがそれぞれのサービスのロケーションをインスタンスごとにＩＥＥＥ１３９４．３を介して提供可能であることを他のノードに対して知らしめる方法がない。そのため、もし複数のインスタンスがＩＥＥＥ１３９４．３で規定される同じサービスＩＤで表現されるサービスを提供していれば、そのサービスＩＤがどちらのインスタンスが提供するサービスか区別がつかない。図２２はそのような状況に置かれたイニシエータノードにおけるディレクトリの層構造の一例である。このように、イニシエータにおける物理デバイスと各論理デバイスと各サービスの関係を適切な階層構造で他の機器に対して示すことができなかった。
【００１２】
その一方、ある物理デバイスの役割がターゲットである場合には、ターゲットは複数のユニットディレクトリを持つことができ、複数の論理デバイスを持っている場合でも、それぞれの論理デバイスをユニットディレクトリを用いて階層的に表現することができた。
【００１３】
そのため、ＩＥＥＥ１３９４．３を下位レイヤとして使用するクライアントは、その機器のＩＥＥＥ１３９４．３層がイニシエータかターゲットかによって論理デバイスやそれが提供するサービスの表現の仕方が共通でないために、ＩＥＥＥ１３９４．３層がイニシエータかターゲットかによって振る舞いを変更しなければならない可能性があった。
【００１４】
本発明は上記従来例に鑑みてなされたもので、イニシエータが複数の論理デバイスを有する場合には、ユニットディレクトリを論理デバイスに対応して設けることで、イニシエータにおける論理デバイスの階層的表現を可能ならしめる通信制御装置及び方法を提供することを目的とする。
【００１５】
【課題を解決するための手段】
上記目的を達成するために本発明は次のような構成からなる。
【００１６】
ＩＥＥＥ１３９４．３におけるターゲットとして機能する外部装置と通信し、ＩＥＥＥ１３９４．３におけるイニシエータとして機能する通信制御装置であって、通信制御装置が提供可能な複数の機能を示す情報、及び、それぞれの機能に対応する複数のユニットディレクトリを格納する格納手段と、ユニットディレクトリを特定するディレクトリＩＤを外部装置から受信する受信手段と、受信手段によって受信したディレクトリＩＤに対応するユニットディレクトリが通信制御装置内に存在するか否かを判定する判定手段と、受信手段によって受信したディレクトリＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在するかどうかを判断する判断手段と、判定手段が格納手段にディレクトリＩＤに対応するユニットディレクトリが存在すると判定した場合、または前記判断手段が前記ディレクトリＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在すると判断した場合にＩＥＥＥ１３９４．３に規定された方法で外部装置と通信を行う通信手段とを有し、前記通信手段は、判定手段が格納手段にディレクトリＩＤに対応するユニットディレクトリが存在しないと判定し、前記判断手段が前記ディレクトリＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在しないと判断した場合に、ＩＥＥＥ１３９４．３に規定された方法で前記外部装置と通信しないことを特徴とする。
【００２３】
あるいは、通信回線を通して接続された機器に対して要求されたサービスを提供するための通信制御装置であって、
複数のサービス提供デバイスと、
前記複数のサービス提供デバイスそれぞれにより提供されるサービスについての情報を、前記通信回線を介して他の機器から読み取り可能に記憶する記憶手段とを備え、
前記サービスについての情報は、前記複数のサービス提供デバイスごとに階層的な木構造で構成する。
【００２４】
【発明の実施の形態】
［第１の実施の形態］
以下、図面を参照し、本発明の実施形態である通信システム及びそれを構成するイニシエータとターゲットについて詳細に説明する。なお、以下の説明で「本発明の規定に準拠」との表現、あるいはそれに類する表現をする場合があるが、これは、本発明に係るシステムや装置あるいは方法などの構成や手順（実施形態中で説明される）による限定を表すための表現であって、発明が規格や取り決めそのものであることを意味するものではない。
【００２５】
＜システムの構成＞
本実施形態の概略は次のようなものである。すなわち、ＩＥＥＥ１３９４．３の規定によれば、イニシエータのノードが有するデバイス（ユニット）を定義するためのイニシエータユニットディレクトリは、ひとつの物理ノード（１３９４シリアルバスが接続されたノードを指す。物理デバイスとも呼ぶ）はひとつしか持てないとされている。本発明においてはこれを拡張し、ひとつの物理ノードにつき複数のイニシエータユニットディレクトリ持つことができる。そしてそれぞれのイニシエータユニットディレクトリに識別子をつけ、ターゲットからイニシエータに対してＩＥＥＥ１３９４．３で規定されているキューをコネクトするとき必要であれば、前記識別子を論理デバイスを指定するパラメータとして、コネクトリクエストコマンドのパラメータに付加する。なお、論理デバイスとは、ひとつの物理ノードを構成するデバイスそれぞれを指す。たとえば、コンピュータが物理ノードであるとすれば、それにローカル接続されたスキャナやプリンタ、モデムなどがそれぞれ論理デバイスとなり得る。
【００２６】
本発明が適用される機器構成の概略は図１６に示されている。そして、各ノードの構成を定義したデータが登録されているコンフィグＲＯＭの中の構成の一例は図３Ａ、図３Ｂで示される。
【００２７】
図１６において、本システムのイニシエータは、論理デバイスＡ，Ｂ，Ｃを備えている。本例ではこのデバイスはプリンタであるものとする。同じ機器であるために、各論理デバイスは同じサービスを提供する。ここではサービスＡ，Ｂ，Ｃをそれぞれ提供している。コンフィグＲＯＭ（ＣＯＮＦＩＧＲＯＭ）には、各論理デバイスが定義されている。
【００２８】
一方、ターゲットには、イニシエータの提供するサービスを利用するクライアントを有する。イニシエータとターゲットとは１３９４シリアルバスで接続されており、双方とも１３９４回線制御部を介して接続される。
【００２９】
図１は本発明を適応するＩＥＥＥ１３９４．３で規定されたターゲット（以下ターゲット）の電子機器の内部のブロック構成図である。１は本発明を制御するＣＰＵ、２はＣＰＵ１のワークエリアを提供するＲＡＭ、３は本発明のプログラムを提供するハードディスク（フロッピーディスク、ＣＤＲＯＭ、ＭＯ、ＲＯＭ、磁気テープ等でもよい）、５はＩＥＥＥ１３９４回線制御部、８はメインバスである。
【００３０】
図２は本発明を適応するＩＥＥＥ１３９４．３で規定されたイニシエータ（以下イニシエータ）の電子機器の内部のブロック構成図である。１１は本発明を制御するＣＰＵ、１２はＣＰＵ１１のワークエリアを提供するＲＡＭ（コンフィグＲＯＭはここに格納される）、１３は本発明のプログラムを提供するハードディスク（フロッピーディスク、ＣＤＲＯＭ、ＭＯ、ＲＯＭ、磁気テープ等でもよい）、１５はＩＥＥＥ１３９４回線制御部、１８はメインバスである。尚、ＩＥＥＥ１３９４回線制御部にはＩＥＥＥ１３９４、ＳＢＰ−２（Ｓｅｒｉａｌ Ｂｕｓ ｐｒｏｔｏｃｏｌ−２）で規定されている規約が実装されているとする。
【００３１】
尚、本発明は特に断らない限り、ターゲット、イニシエータともにＣＰＵがメインバスを介してＲＡＭ、ハードディスク、ＩＥＥＥ１３９４回線制御部を本発明のプログラムに則り制御して動作する。また、ＩＥＥＥ１３９４回線制御部は、ＩＥＥＥ１３９４プロトコル制御部とも呼ばれるが、本実施形態においては両者は同一のものである。
【００３２】
＜コンフィグＲＯＭの内容＞
図３Ａに本発明に係るイニシエータのコンフィグＲＯＭの内容の一例をあげる。構成情報は階層構造のディレクトリで管理される。すなわち、ルートディレクトリの下に、論理デバイスを定義するインスタンスディレクトリがあり、その下に論理デバイスを更に詳細に定義するためのユニットディレクトリがある。更に各論理デバイスの提供するサービス等を定義したフィーチャーディレクトリがその下にある。
【００３３】
図３Ｂはその詳細を示す。ルートディレクトリ３０１の下には、インスタンスとして各論理デバイスを定義するインスタンスディレクトリがリンクされている。たとえばインスタンスディレクトリ３０２には、論理デバイスであるプリンタＢのモデル識別子が記述されているのに加えて、さらにその下のユニットディレクトリ３０３へのリンクが用意されている。ユニットディレクトリには、プロトコルを指定するスペシファイア（本実施形態ではＩＥＥＥ１３９４を示す０ｘ５０２９が指定される）と、プロトコルのバージョン、さらにサービスを定義するフィーチャーディレクトリ３０４へのリンクが含まれる。フィーチャーディレクトリ３０４には、論理デバイスＢが提供するサービスである、サービスＡ，Ｂ，Ｃが定義されている。
【００３４】
ここで注目すべきは、イニシエータユニットディレクトリ１はＩＥＥＥ１３９４．３が規定するとおりであるが、イニシエータユニットディレクトリ２，３についてはＩＥＥＥ１３９４．３が規定するバージョンの値が異なり、それ以外の項目はＩＥＥＥ１３９４．３の規定とおりである。すなわち、ＩＥＥＥ１３９４．３が規定するイニシエータユニットディレクトリのバージョンの値は０だがイニシエータユニットディレクトリ２，３では１である。このバージョン番号により、本来のＩＥＥＥ１３９４．３の規格であるか、本実施形態で説明する拡張規格であるかが判定可能となる。
【００３５】
そして、イニシエータユニットディレクトリ３にはイニシエータユニットディレクトリ２の特徴に加えて、ＤＩＲＥＣＴＯＲＹ＿ＩＤ（ディレクトリＩＤ）の項目がある。
【００３６】
なお本発明の前提として、特に断らない限り、ターゲットにはＩＥＥＥ１３９４．３が規定するターゲットに必要な機能が、そしてイニシエータにはイニシエータに必要な機能が実装されているとする。そしてターゲットとイニシエータはＩＥＥＥ１３９４で規定された回線で物理的に接続されているとする（図１６参照）。
【００３７】
＜ターゲットの動作＞
次に本発明に係るターゲットの動作を図４Ａ、図４Ｂ、図５、図６のフローチャートを用いて詳細に説明する。最初に図４Ａ，４Ｂに従い説明する。
【００３８】
図４Ａ，４Ｂのフローチャートを実現するためのプログラムがターゲットの機器初期化の過程で起動された後、アプリケーションからの物理デバイス、論理デバイスとサービスを指定したパラメータを伴った接続要求（コネクトの指示）を待っている（Ｓ１０１）。もしそのような接続要求を受信したならば、１３９４回線制御部５に、今１３９４回線で接続されている物理デバイス（物理ノード）をすべて列挙するように要求する（Ｓ１０２）。なお、図では１３９４プロトコル制御部と記載されているが、すべて１３９４回線制御部のことである。
【００３９】
１３９４回線制御部５がＩＥＥＥ１３９４回線を介して現在接続されている物理デバイス名を読み取る（Ｓ１０３）。１３９４回線制御部５から現在接続されている物理デバイスのリストを受け取ると、その中にアプリケーションが指定した物理デバイスがあるかどうか調べる（Ｓ１０４）。もしなければ、アプリケーションに指定した物理デバイスがないことを通知する（Ｓ１０６）。そしてＳ１０１へ戻る。
【００４０】
もし、物理デバイスのリストにアプリケーションが指定した物理デバイスがあれば、その物理デバイスのルートディレクトリの読み込みを１３９４回線制御部５に要求する（Ｓ１０５）。１３９４回線制御部５が読んだルートディレクトリの中にまだその属性を調査していないインスタンスディレクトリのエントリがあるどうかルートディレクトリを調べる（Ｓ１０７）。
【００４１】
すべてのインスタンスディレクトリのエントリに関して調査済みであれば、ＭＯＤＥＬＦＬＧがＯＮかＯＦＦか調べる（Ｓ１０８）。もしＭＯＤＥＬＦＬＧがＯＮであれば、ＩＥＥＥ１３９４．３と本発明に係る方法以外の方法で通信（接続）ができる可能性があるので、もし可能であれば、他の通信プロトコル（例えばＦＣＰ等）で接続を試みる（図４Ｂ：Ｓ１０９）。そして終了後Ｓ１０１へ進む。もしＭＯＤＥＬＦＬＧがＯＦＦであれば、アプリケーションに指定した論理デバイスがないことを通知する（Ｓ１０６）。そしてＳ１０１へ戻る。
【００４２】
一方、ステップＳ１０７において、もし未調査のインスタンスディレクトリのエントリが１３９４回線制御部５が読んだルートディレクトリにあれば、その中の一番若いアドレスのインスタンスディレクトリを読むように１３９４回線制御部５に要求する（Ｓ１１０）。１３９４回線制御部５が読みこんだインスタンスディレクトリのモデルのエントリに書かれているモデルがアプリケーションがコネクトを要求した論理デバイスと一致するかどうか調べる（Ｓ１１１）。もし一致しなければＳ１０７へ戻る。もし一致すればＭＯＤＥＬＦＬＧをＯＮにする（Ｓ１１２）。ＭＯＤＥＬＦＬＧは図４Ａ，４Ｂの手順のプログラムが起動するとき、ＯＦＦに初期化されているものとする。
【００４３】
未調査のユニットディレクトリのエントリが１３９４回線制御部５が読んだインスタンスディレクトリにあるかどうか調べる（Ｓ１１３）。もしすべてのユニットディレクトリのエントリが調査済みであれば、このインスタンスディレクトリは、本実施形態で定義する手順（プロトコル）に適合しないと判断してステップＳ１０７へ進む。
【００４４】
もし未調査のユニットディレクトリのエントリが１３９４回線制御部５が読んだインスタンスディレクトリにあれば、その中の一番若いアドレスのユニットディレクトリを読むように１３９４回線制御部５に要求する（Ｓ１１４）。１３９４回線制御部５が読みこんだユニットディレクトリのスペシファイアＩＤの項目の値が０ｘ５０２９（ＩＥＥＥ１３９４．３を作成した団体の識別子）であるか調べる（Ｓ１１５）。スペシファイアＩＤの項目の値が０ｘ５０２９でなければ、このユニットディレクトリは１ＥＥＥ１３９４をサポートしていないと判断し、Ｓ１０７へ進む。
【００４５】
スペシファイアＩＤの項目の値が０ｘ５０２９であれば、１３９４回線制御部５が読みこんだユニットディレクトリのバージョンエントリの値を調べる（Ｓ１１６）。ユニットディレクトリのバージョンエントリの値が０ｘ００であれば、このユニットディレクトリはＩＥＥＥ１３９４．３完全準拠のものであると判断し、図５のＡへ進む。もしユニットディレクトリのバージョンエントリの値が０ｘ０１であれば（Ｓ１１７）、ＩＥＥＥ１３９４．３を拡張した、本実施形態で定義する手順に従うものと判断し、図５のＢへ進む。ユニットディレクトリのバージョンエントリの値が０ｘ００でも、０ｘ０１でもなければ、他のプロトコルで通信できる可能性があるため、可能であればその処理を行う（Ｓ１０９）。
【００４６】
このようにして、ターゲットは、イニシエータの資源を示す階層的な構成を獲得し、その資源をターゲットが欲するものであるか否か判断することができる。
【００４７】
＜本発明に係るターゲットの動作＞
ここからは、このユニットディレクトリがＩＥＥＥ１３９４．３を拡張した規格に準拠する、本発明に係るターゲットの動作を図６を用いて説明する。
【００４８】
読み込んだユニットディレクトリにディレクトリＩＤのエントリがあるかどうか調べる（Ｓ３０１）。もしディレクトリＩＤのエントリがあればその値をＩＮＳ（ディレクトリ識別子格納場所）に格納する（Ｓ３０３）。もしなければ読み込んだユニットディレクトリの先頭アドレスをＩＮＳに格納する（Ｓ３０２）。
【００４９】
アプリケーションから指定されたサービスに対応したサービスＩＤとＩＮＳに格納されたユニットディレクトリにディレクトリＩＤを組み込んだコネクトコントロールリクエストを作成する（Ｓ３０４）。コネクトコントロールリクエストは図９に示したとおりである。すなわち、先頭のＲｑフィールドの値はリクエストを表す“１”、ｃｔｒｌ＿ｆｕｎｃｔｉｏｎフィールドの値はコネクトであることを表す“ＣＯＮＮＥＣＴ”であり、ｒｅｓｐｏｎｓｅフィールドについては、リクエストなのでその値は特に問題にならない。その他のフィールドは図９に示すとおりとなる。ここではコネクトコントロールリクエストのサービスＩＤを“ＰＲＮ”（印刷）であるとする。またＤＩＲＥＣＴＯＲＹ＿ＩＤをここでは２Ｆ４２５６であるとする。ＤＩＲＥＣＴＯＲＹ＿ＩＤの定義は図１４に示してある。すなわち、ターゲットが接続を試みたイニシエータ中のユニットディレクトリを特定する値である。
【００５０】
そして、すでに当該イニシエータの物理デバイスとＳＢＰ−２のログインが確立しているか調べる（Ｓ３０５）。もし確立していなければ、１３９４回線制御部５に、ＩＥＥＥ１３９４．３規定のリバースログイン処理を要求する（Ｓ３０６）。リバースログインでログインが確立できたかどうか確認し（Ｓ３０７）、もし確立できなければ、アプリケーションにコネクト失敗を報告しステップＳ３０８へ進む。
【００５１】
ＳＢＰ−２のログインが確立していたり、リバースログイン処理が成功したとき、前記のコネクトコントロールリクエスト（単にコネクトとも呼ぶ）をＩＥＥＥ１３９４．３規定の方法でイニシエータに送信するように１３９４回線制御部５に要求する（Ｓ３０９）。そして１３９４回線制御部５が当該イニシエータの物理デバイスから何か送信されてくることを待つ（Ｓ３１０）。１３９４回線制御部５が当該イニシエータの物理デバイスから何か受信したとき、それがコネクトに対するレスポンス（単にコネクトレスポンスとも呼ぶ）かどうか調べる（Ｓ３１１）。コネクトレスポンスがＯＫであれば、図１１に示す値がレスポンスされる。すなわち、Ｒｑフィールドの値が“０”、ｃｔｒｌ＿ｆｕｎｃｔｉｏｎフィールドの値が“ＣＯＮＮＥＣＴ”、ｒｅｓｐｏｎｓｅフィールドの値はＯＫを示す“０”である。
【００５２】
コネクトコントロールリクエストに対するスポンスでなければ、そのコマンドに対応する処理を行う（Ｓ３１２）。コネクトレスポンスであれば、その結果がコネクトＯＫかＮＧ（失敗）かをレスポンス項目で判定する（Ｓ３１３）。コネクトがＮＧであればアプリケーションにコネクト失敗を報告してステップＳ３０８へ進む。コネクトがＯＫであればアプリケーションが要求したサービスが利用可能になったことをアプリケーションに報告する（Ｓ３１４）。そしてアプリケーションの指示に従い、データの送受信をおこない（Ｓ３１５）、アプリケーションの指示によりシャットダウン処理を行う（Ｓ３１６）。
【００５３】
他にアクティブなキューがログイン上に存在するかどうかを調べ（Ｓ３１７）、存在しなければログアウト処理を１３９４回線制御部５を要求して（Ｓ３１８）終了する。存在すればそのまま終了する。
【００５４】
＜ＩＥＥＥ１３９４．３準拠のターゲットの動作＞
ここからはこのユニットディレクトリがＩＥＥＥ１３９４．３準拠のときのターゲットの動作を図５を用いて説明する。
【００５５】
まずアプリケーションから指定されたサービスに対応したサービスＩＤを組み込んだコネクトコントロールリクエストを作成する（Ｓ２０１）。図８にその内容を示す。ｃｎｔｒｌ＿ｆｕｎｃｔｉｏｎフィールドがコネクトコントロールリクエストを示す“ＣＯＮＮＥＣＴ”であり、残りのフィールドは図示したとおりである。ここではサービスＩＤを“ＰＲＮ”とする。
【００５６】
そして、すでに当該イニシエータの物理デバイスとＳＢＰ−２のログインが確立しているか調べる（Ｓ２０２）。もし確立していなければ、１３９４回線制御部５にＩＥＥＥ１３９４．３規定のリバースログイン処理を要求する（Ｓ２０３）。もしリバースログインでログインが確立できたかどうか確認し（Ｓ２０４）、もし確立できなければ、アプリケーションにコネクト失敗を報告し、ステップＳ２０５へ進む。
【００５７】
ＳＢＰ−２のログインが確立していたり、リバースログイン処理が成功したとき、ステップＳ２０１で作成したコネクトコントロールリクエストをＩＥＥＥ１３９４．３規定の方法でイニシエータに送信するように１３９４回線制御部５に要求する（Ｓ２０６）。そして１３９４回線制御部５が当該イニシエータの物理デバイスから何か送信されてくることを待つ（Ｓ２０７）。１３９４回線制御部５が当該イニシエータの物理デバイスから何か受信したとき、それがコネクトレスポンスかどうか調べる（Ｓ２０８）。
【００５８】
コネクトレスポンスであれば図１１のレスポンスが返される。コネクトレスポンスでなければ、そのコマンドに対応する処理を行う（Ｓ２０９）。コネクトレスポンスであれば、その結果がコネクトＯＫかＮＧ（失敗）かをレスポンス項目で判定する（Ｓ２１０）。コネクトがＮＧであればアプリケーションにコネクト失敗を報告してＳ２０５へ進む。コネクトがＯＫであればアプリケーションが要求したサービスが利用可能になったことををアプリケーションに報告する（Ｓ２１１）。そしてアプリケーションの指示に従い、データの送受信をおこない（Ｓ２１２）アプリケーションの指示によりシャットダウン処理を行う（Ｓ２１３）。
【００５９】
他にアクティブなキューがログイン上に存在するかどうかを調べ（Ｓ２１４）、存在しなければログアウト処理を１３９４回線制御部５を要求して（Ｓ２１５）終了する。存在すればそのまま終了する。
【００６０】
＜イニシエータの動作＞
次に本発明に係るイニシエータの動作を図７Ａ乃至図７Ｃを用いて説明する。イニシエータは、本発明を含む機器が初期化されたとき、同時の起動、初期化されるものとする。また、ＳＢＰ−２で規定されているログインの動作は１３９４回線制御部１５が制御するので、ここでは詳細に説明しない。
【００６１】
まず１３９４回線制御部１５から本発明に関わるデータを当該ターゲット機器から受信するのを待つ（Ｓ４０１）。そして受信したデータがキュー０に関わるものかどうかを、対応するＯＲＢのキューの項目（ＩＥＥＥ１３９４．３で規定）を調べる（Ｓ４０２）。もしキュー０に関するものでなければ、そのキュー番号に対応する処理（ＩＥＥＥ１３９４．３で規定）を行う（Ｓ４０３）。Ｓ４０１へ進む。
【００６２】
キュー０に関するものであれば、そのコントロールインフォメーションのｃｎｔｒｌ＿ｆｕｎｃｔｉｏｎの項目（図８，９参照）がコネクトかどうか調べる（Ｓ４０４）。コネクトでなければ、指定されたコントロールファンクションに対応する処理（ＩＥＥＥ１３９４．３で規定）を行い（Ｓ４０５）、Ｓ４０１へ進む。
【００６３】
そのコントロールインフォメーションのｃｎｔｒｌ＿ｆｕｎｃｔｉｏｎの項目（図８，９参照）がコネクトであれば、そのコントロールインフォメーションのＲｑの項目を調べる（Ｓ４０５）。Ｒｑの項目がレスポンスであれば対応する処理（ＩＥＥＥ１３９４．３で規定）を行い（Ｓ４０６）、Ｓ４０１へ進む。
【００６４】
もしそのコントロールインフォメーションのＲｑの項目がリクエストであれば、コントロールインフォメーションにＤＩＲＥＣＴＯＲＹ＿ＩＤの項目（図８，９，１４参照）があるかどうか調べる（Ｓ４０７）。
【００６５】
もしＤＩＲＥＣＴＯＲＹ＿ＩＤの項目があればその他のパラメータはＩＥＥＥ１３９４．３のコネクトコントロールで規定されている通りのパラメータがどうか調べる（Ｓ４０８）。もし規定外であれば対応するエラー処理をおこない（Ｓ４０９）、Ｓ４０１へ進む。
【００６６】
ステップＳ４０８において、もしＤＩＲＥＣＴＯＲＹ＿ＩＤの項目以外のすべてパラメータがＩＥＥＥ１３９４．３のコネクトコントロールで規定通りであれば、ＤＩＲＥＣＴＯＲＹ＿ＩＤの項目で指定されているディレクトリＩＤと同値のディレクトリＩＤを持つユニットディレクトリがイニシエータ内に存在するかどうか調べる（Ｓ４１１）。もしＤＩＲＥＣＴＯＲＹ＿ＩＤと同値のディレクトリＩＤを持つユニットディレクトリがイニシエータ内に存在しなければ、ＤＩＲＥＣＴＯＲＹ＿ＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在するかどうか調べる（Ｓ４１２）。ＤＩＲＥＣＴＯＲＹ＿ＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在しなければコネクトレスポンスのパラメータに“指定されたユニットは存在しない”を設定する（図１５，１２参照）（Ｓ４１３）。そしてＳ４２２へ進む。
【００６７】
ステップＳ４２２では、指定されたコネクトレスポンスのパラメータを含むコネクトレスポンスを作成する。そして１３９４回線制御１５に作成したコネクトレスポンスを送信するように要求する（Ｓ４２３）。そしてＳ４２９へ進む。
【００６８】
ステップＳ４１１において、ＤＩＲＥＣＴＯＲＹ＿ＩＤの項目で指定されているディレクトリＩＤと同値のディレクトリＩＤを持つユニットディレクトリがイニシエータ内に存在するか、または、ＤＩＲＥＣＴＯＲＹ＿ＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在すれば、ＤＩＲＥＣＴＯＲＹ＿ＩＤの指すユニットディレクトリが図１７に示したようなディレクトリの内容を持つかどうか調べる（Ｓ４１４）。もし異なれば、コネクトレスポンスのパラメータに“指定されたユニットは存在しない”を設定する（図１５，１２参照）（Ｓ４１３）。そしてＳ４２２へ進む。図１７は本発明に係るユニットディレクトリの内容を示し、スペシファイヤＩＤ及びバージョンの各エントリが必須であり、ディレクトリＩＤと、提供可能なサービスを定義するフィーチャーディレクトリが必要に応じて付加される。図２３は、各エントリに対応するコードを示している。図のように、スペシファイアＩＤは１２（１６進）、バージョンは１３（１６進）、フィーチャディレクトリオフセットは９Ａ（１６進）で示される。また、スペシファイアＩＤ及びバージョンそれぞれのエントリについては、００５０２９（１６進），０００００１（１６進）という値で固定されている。
【００６９】
ステップＳ４１４において、もしＤＩＲＥＣＴＯＲＹ＿ＩＤの指すユニットディレクトリが、本実施形態で説明するディレクトリの内容、すなわち、図１７に示すようなエントリを有するのであれば、コネクトコントロールで指定されたサービスＩＤで要求されたサービスを、指定されたＤＩＲＥＣＴＯＲＹ＿ＩＤの指すユニットディレクトリに対応するユニット（論理デバイス）がサポートしているかどうか調べる（Ｓ４１５）。もしサポートしていなければコネクトレスポンスのパラメータに”指定されたサービスを指定されたユニットはサポートしていない”を設定する（図１５，１３参照）（Ｓ４１６）。Ｓ４２２へ進む。
【００７０】
ステップＳ４０７において、もしディレクトリＩＤの項目がなければ、ＩＥＥＥ１３９４．３のコネクトコントロールで規定されている通りのパラメータがどうか調べる（Ｓ４１０）。もし規定外であれば対応するエラー処理をおこないＳ４２１へ進む。すべてのパラメータが規定通りであればコネクトコントロールで指定されたサービスＩＤで要求されたサービスを、イニシエータはサポートしているかどうか調べる（Ｓ４１７）。
【００７１】
サポートしている場合には、コネクトコントロールで指定されたサービスＩＤで要求されたサービスが必要とするキューの性格、数がコネクトコントロールのキューフィールドで指定されたものと合致するかどうか調べる（Ｓ４１８）。そして合致していなければ、コネクトレスポンスのパラメータに“ミスマッチ”を設定する（図１５、図１０参照）（Ｓ４１９）。Ｓ４２２へ進む。
【００７２】
一方ステップＳ４１８において、もしコネクトコントロールで指定されたサービスＩＤで要求されたサービスが必要とするキューの性格、数がコネクトコントロールのキューフィールドで指定されたものと合致していれば、サービスを要求されたサーバーは指定されたサービスを提供するかどうか調べる（Ｓ４２０）。もし接続しないのであればコネクトレスポンスのパラメータに“接続拒否”を設定する（図１５，図１９参照）（Ｓ４２１）。そしてＳ４２２へ進む。
【００７３】
サービスを要求されたサーバは指定されたサービスを提供するのであれば、コネクトレスポンスのパラメータに“接続ＯＫ”を設定する（図１５、図１１参照）（Ｓ４２４）。そしてＳ４２５へ進む。
【００７４】
指定されたコネクトレスポンスのパラメータを含むコネクトレスポンスを作成する（Ｓ４２５）。そして１３９４回線制御１５に作成したコネクトレスポンスを送信するように要求する（Ｓ４２６）。そしてクライアントの要求に従い１３９４回線制御１５を介してイニシエータとターゲット間でデータの送受信をＩＥＥＥ１３９４．３で規定された方法で行う（Ｓ４２７）。サービスが終了すればクライアントの要求に従い、ＩＥＥＥ１３９４．３で規定された方法でシャットダウン処理を行う（Ｓ４２８）。なお、クライアントとは、ターゲットを介してイニシエータにサービスを要求するアプリケーションを指す。すなわち、図５のステップＳ２１２，２１３、あるいは、図６のステップＳ３１５，３１６における処理に対応して、ステップＳ４２７，Ｓ４２８の処理は行われる。ステップＳ４２７においては、データの送受信が行われると共に、ターゲットから指定されたサービスがイニシエータによって提供される。その際、ターゲットから、イニシエータにより管理されている論理デバイスおよびその論理デバイスによりサポートされるサービスが指定されていれば、指定された論理デバイスによる指定されたサービスが提供される。
【００７５】
たとえば、ターゲットからイニシエータに対して発行するコネクトコントロールファンクションのＤＥＶＩＣＥ＿ＩＤフィールドで、図３Ｂの論理プリンタＢのユニットディレクトリ３０３のアドレスを指定し、論理プリンタＢがサポートするサービスである「印刷」を指定すれば、ターゲットとイニシエータとの間にコネクションが確立される。その後、イニシエータは、ターゲットに対してバッファを提供し、ターゲットからそのバッファに書き込まれるデータを読んで、そのデータに基づいて印刷というサービスを遂行することになる。
【００７６】
その後、そのログイン内にキュー０以外のアクティブなキューがあるかどうか調べ（Ｓ４２９）、もしあればステップＳ４０１へ進む。なければＳＢＰ−２で規定されているログアウト処理を行い、終了する（Ｓ４３０）。
【００７７】
ステップＳ４１０においてパラメータが正常でないと判定された場合、あるいは、ステップＳ４１７において指定されたサービスをイニシエータが提供していないと判定された場合には、それぞれに対応する処理を行って（Ｓ４１０−１）、ステップＳ４１９へ進む。
【００７８】
以上の手順により、イニシエータにおけるコンフィグＲＯＭにより、イニシエータの論理デバイスごとに各論理デバイスで使用可能なサービスを管理することで、ターゲットとイニシエータとのコネクションを、ターゲットからイニシエータの論理デバイス及びサービスを指定して確立することができる。さらに、ターゲットは指定した論理デバイスによりサービスの提供を受けることができる。
【００７９】
以上の構成及び手順により、ＩＥＥＥ１３９４．３が規定するイニシエータの役割の１つのノードが複数のインスタンスを持つとき、それぞれのインスタンスとサービスの関係を表現することができ、また１つのノード内の複数のインスタンスが同じサービスＩＤのサービスを提供しているときでも、そのサービスＩＤが格納されている、フィーチャーディレクトリ、ユニットディレクトリのすくなくともどちらかのディレクトリＩＤを指定することによりどのインスタンスが提供しているサービスのサービスＩＤなのかを特定して表現することができる。
【００８０】
これにより回線で接続されている、本発明をサポートしている他のノードはサービスＩＤで公開されているサービスがどのインスタンスによって提供されているか理解することが可能になる。具体的に多機能周辺機器等の対応が可能になる。
【００８１】
また、既存のＩＥＥＥ１３９４．３でイニシエータ用のユニットディレクトリと規定されたユニットディレクトリと、本発明で規定されたユニットディレクトリが混在している場合でも、１つのノードにつき、ひとつのインスタンスに限ってのみだではあるものの、既存のＩＥＥＥ１３９４．３との下位互換が可能になる。
【００８２】
［第２の実施の形態］
第１の実施の形態では本発明で規定されたユニットディレクトリでのみ構成されるケースについて説明したが、本実施形態では既存のＩＥＥＥ１３９４．３でイニシエータ用のユニットディレクトリと規定されたユニットディレクトリと本発明で規定されたユニットディレクトリが混在していないときの例を示す。図２４はその場合の階層構造を示す図である。
【００８３】
こうすることにより、１つのノードにつき、ひとつのインスタンスに限ってのみだが既存のＩＥＥＥ１３９４．３の下位互換が可能になる。
【００８４】
【発明の効果】
以上の説明したように、ＩＥＥＥ１３９４．３が規定するイニシエータの役割の１つのノードが複数のインスタンスを持つとき、それぞれのインスタンスとサービスの関係を表現することができ、また１つのノード内の複数のインスタンスが同じサービスＩＤのサービスを提供しているときでも、そのサービスＩＤが格納されている、フィーチャーディレクトリ、ユニットディレクトリのすくなくともどちらかのディレクトリＩＤを指定することによりどのインスタンスが提供しているサービスのサービスＩＤなのかを特定して表現することができる。
【００８５】
これにより回線で接続されている、本発明をサポートしている他のノードはサービスＩＤで公開されているサービスがどのインスタンスによって提供されているか理解することが可能になる。具体的に多機能周辺機器等の対応が可能になる。
【００８６】
また、既存のＩＥＥＥ１３９４．３でイニシエータ用のユニットディレクトリと規定されたユニットディレクトリと、本発明で規定されたユニットディレクトリが混在している場合でも、１つのノードにつき、ひとつのインスタンスに限ってのみだではあるものの、既存のＩＥＥＥ１３９４．３との下位互換が可能になる。
【図面の簡単な説明】
【図１】本発明を実装するターゲット側のブロック図である。
【図２】本発明を実装するイニシエータ側のブロック図である。
【図３Ａ】本発明を実装するイニシエータに実装されるコンフィグＲＯＭの概略階層図である。
【図３Ｂ】本発明を実装するイニシエータに実装されるコンフィグＲＯＭの具体的なエントリの値の一例を示す図である。
【図４Ａ】、
【図４Ｂ】本発明を実装する、ターゲット側の動作を示すフローチャートである。
【図５】本発明を実装する、ターゲット側の動作を示すフローチャートである。
【図６】本発明を実装する、ターゲット側の動作を示すフローチャートである。
【図７Ａ】、
【図７Ｂ】、
【図７Ｃ】本発明を実装する、イニシエータ側の動作を示すフローチャートである。
【図８】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）リクエストの構造図である。
【図９】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）リクエストを本発明を実装するために拡張したものを示す図である。
【図１０】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図でサービスと指定されたキューのタイプがミスマッチのときの構造図である。
【図１１】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図でコネクトがＯＫのときの構造図である。
【図１２】本発明でＩＥＥＥ１３９４．３で規定から拡張されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図でが指定されたユニットディレクトリがないときの構造図である。
【図１３】本発明でＩＥＥＥ１３９４．３で規定から拡張されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図でが指定されたサービスが指定されたユニットディレクトリがないときの構造図である。
【図１４】本発明でＩＥＥＥ１３９４．３で規定から拡張されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）の値とその意味でディレクトリＩＤが拡張項目を示す図である。
【図１５】本発明でＩＥＥＥ１３９４．３で規定から拡張されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの値とその意味で６、７が拡張項目を示す図である。
【図１６】本発明を実装したときのイニシエータ、ターゲット、イニシエータのコンフィグＲＯＭ、本発明モジュール等の関係の一例をモデル化したものを示す図である。
【図１７】本発明を実装したときのユニットディレクトリの構造図である
【図１８】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図で接続拒否のときの構造図である
【図１９】従来のユニットディレクトリの構成を示す図である。
【図２０】従来のユニットディレクトリの構成を示す図である。
【図２１】従来のイニシエータにおいて提供するサービスを示す階層ディレクトリ構造を示す図である。
【図２２】従来のイニシエータにおいて提供するサービスを示す階層ディレクトリ構造を示す図である。
【図２３】本発明を実装したときのユニットディレクトリの構造図である
【図２４】第２実施形態におけるイニシエータに実装されるコンフィグＲＯＭの概略階層図である。
【発明の属する技術分野】
本発明は、２機器間のデータ転送の制御を行うための通信制御装置及び方法に関するもので、特に通信プロトコルとしてＩＥＥＥ１３９４を使用する通信制御装置及び方法に関する。
【０００２】
【従来の技術】
ＩＥＥＥ（米国電気電子学会）で規定された通信規格のひとつに、ＩＥＥＥ１３９４と呼ばれるものがある。ＩＥＥＥ１３９４で規定された通信方式は、ハンドシェイク方式に比べて高速で、しかも双方向通信が可能である。また、メモリバスモデルのインターフェースであり、ＩＥＥＥ１３９４シリアルバスで接続された機器は、相手の指定したアドレスにアクセスすることができる。このＩＥＥＥ１３９４は広範囲に応用するための物理層及びリンク層のプロトコルを定めたもので、機器ごとの詳細なプロトコルは定められていない。
【０００３】
そのため、物理層・リンク層としてＩＥＥＥ１３９４を利用したトランスポート層のプロトコルとして、ＳＢＰ−２（ｓｅｒｉａｌ ｂｕｓ ｐｒｏｔｏｃｏｌ−２）なるプロトコルが定義されている。ＳＢＰ−２は、ＩＥＥＥ１３９４のメモリバスモデルとしての特長を生かしたプロトコルであり、これに従えばコマンドの受信側がそれ自身の都合に応じて送信側からデータを受信できる。このＳＢＰ−２で接続される２つのデバイスは、コマンドの送信側がイニシエータ、受信側がターゲットと呼ばれ、通信を開始するに当たってのイニシアチブはイニシエータがとる。そのためにログイン動作はイニシエータのみが行え、ターゲットは原則的にはイニシエータからの働きかけに応える動作を行うことになる。
【０００４】
ＳＢＰ−２によれば、イニシエータからログインされると、イニシエータは、データの送受信のために使用されるメモリアドレス等が書かれたＯＲＢと呼ばれるブロックを作成し、そのＯＲＢのアドレスをターゲットに通知する。ターゲットは、通知されたＯＲＢを読んで、そこに記載されたアドレスからデータを読み出したり、あるいはそのアドレスにデータを書き込むことで、データの送受信を実現している。このために、ＯＲＢのアドレスはターゲットにおいてキューイングされ、それに対するレスポンスはイニシエータにおいてキューイングされる。ターゲットはキューイングされたＯＲＢを順に処理し、レスポンスをイニシエータに返す。
【０００５】
さらにこのＳＢＰ−２の上に、ターゲットからイニシエータに対してログインを促すリバースログインなどを規定したＩＥＥＥ１３９４．３なる規格が、ＳＢＰ−２と同じくトランスポート層のプロトコルとして提案されている。このＩＥＥＥ１３９４．３においては、ログイン動作はイニシエータのみが行え、ターゲットは原則的にはイニシエータからの働きかけに応える動作を行うことになるが、イニシエータによるログインを促すためのリバースログインという動作がターゲットからは可能となっている。
【０００６】
このように、イニシエータの方がイニシアチブをとる構成上、規格上もイニシエータにより種々のサービスを提供させ、ターゲットから所望のサービスを指定してそのサービスを受ける、というものになっている。
【０００７】
【発明が解決しようとする課題】
ここで、ＩＥＥＥ１３９４の規格においては、互いに接続される各ノードが１つのデバイスを構成するものとされている。これは、ひとつのノード内で複数のデバイスを管理することの煩雑さ故に、各ノードは単一のデバイスであるという想定の下に規格化された、たとえばＳＣＳＩなどにおける規定をそのまま継承しているためである。
【０００８】
このためＩＥＥＥ１３９４．３の規定では、イニシエータのノードが有する論理デバイス（ユニット）を定義するためのイニシエータユニットディレクトリは、ひとつの物理ノード（１３９４シリアルバスが接続されたノードを指す。物理デバイスとも呼ぶ）についてひとつしか持てないと規定されている。この規定により、イニシエータはユニットディレクトリを２つ以上持つことが許されず、ある物理デバイスが、ＩＥＥＥ１３９４．３が規定する物理デバイスを構成する論理デバイスを複数持ち、しかもその役割がイニシエータであるとき、その物理デバイスと各論理デバイスと各サービスの関係を適切な階層構造で他の機器に対して表現することができなかった。
【０００９】
図１９にユニットディレクトリの一例を示す。ＩＥＥＥ１３９４．３では、少なくとも図１８のようなエントリを持つユニットディレクトリを、ＩＥＥＥ１３９４．３で規定するイニシエータの役割が可能な各ノードに１個のみ持つことを許していた。そして、ユニットディレクトリに含まれるフィーチャーディレクトリオフセットでアドレスを特定された場所にあるフィーチャーディレクトリに、そのノードが提供可能なサービスをＩＥＥＥ１３９４．３で規定された記述方法で記述することにより、そのノードが他ノードに対してＩＥＥＥ１３９４．３を介して提供が可能なサービスを知らしめることができる。図２０はそのフォーマットの１例である。
【００１０】
そして、ＩＥＥＥ１３９４．３により規定されるイニシエータ のルートディレクトリ、インスタンスディレクトリ、ユニットディレクトリ、フィーチャーディレクトリをＩＥＥＥ１３９４．３で規定するイニシエータの役割が可能な各ノードが持つとすれば、階層構造の一例は図２１のとおりである。なお、バスインフォメーション、ルートディレクトリ、インスタンスディレクトリの記述方法はＩＥＥＥ１２１２Ｒで規定されているので詳細は省略する。
【００１１】
しかしＩＥＥＥ１３９４．３では、各イニシエータノードはイニシエータユニットディレクトリを２つ以上持つことを許されていないため、イニシエータにおける複数のインスタンスがそれぞれのサービスのロケーションをインスタンスごとにＩＥＥＥ１３９４．３を介して提供可能であることを他のノードに対して知らしめる方法がない。そのため、もし複数のインスタンスがＩＥＥＥ１３９４．３で規定される同じサービスＩＤで表現されるサービスを提供していれば、そのサービスＩＤがどちらのインスタンスが提供するサービスか区別がつかない。図２２はそのような状況に置かれたイニシエータノードにおけるディレクトリの層構造の一例である。このように、イニシエータにおける物理デバイスと各論理デバイスと各サービスの関係を適切な階層構造で他の機器に対して示すことができなかった。
【００１２】
その一方、ある物理デバイスの役割がターゲットである場合には、ターゲットは複数のユニットディレクトリを持つことができ、複数の論理デバイスを持っている場合でも、それぞれの論理デバイスをユニットディレクトリを用いて階層的に表現することができた。
【００１３】
そのため、ＩＥＥＥ１３９４．３を下位レイヤとして使用するクライアントは、その機器のＩＥＥＥ１３９４．３層がイニシエータかターゲットかによって論理デバイスやそれが提供するサービスの表現の仕方が共通でないために、ＩＥＥＥ１３９４．３層がイニシエータかターゲットかによって振る舞いを変更しなければならない可能性があった。
【００１４】
本発明は上記従来例に鑑みてなされたもので、イニシエータが複数の論理デバイスを有する場合には、ユニットディレクトリを論理デバイスに対応して設けることで、イニシエータにおける論理デバイスの階層的表現を可能ならしめる通信制御装置及び方法を提供することを目的とする。
【００１５】
【課題を解決するための手段】
上記目的を達成するために本発明は次のような構成からなる。
【００１６】
ＩＥＥＥ１３９４．３におけるターゲットとして機能する外部装置と通信し、ＩＥＥＥ１３９４．３におけるイニシエータとして機能する通信制御装置であって、通信制御装置が提供可能な複数の機能を示す情報、及び、それぞれの機能に対応する複数のユニットディレクトリを格納する格納手段と、ユニットディレクトリを特定するディレクトリＩＤを外部装置から受信する受信手段と、受信手段によって受信したディレクトリＩＤに対応するユニットディレクトリが通信制御装置内に存在するか否かを判定する判定手段と、受信手段によって受信したディレクトリＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在するかどうかを判断する判断手段と、判定手段が格納手段にディレクトリＩＤに対応するユニットディレクトリが存在すると判定した場合、または前記判断手段が前記ディレクトリＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在すると判断した場合にＩＥＥＥ１３９４．３に規定された方法で外部装置と通信を行う通信手段とを有し、前記通信手段は、判定手段が格納手段にディレクトリＩＤに対応するユニットディレクトリが存在しないと判定し、前記判断手段が前記ディレクトリＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在しないと判断した場合に、ＩＥＥＥ１３９４．３に規定された方法で前記外部装置と通信しないことを特徴とする。
【００２３】
あるいは、通信回線を通して接続された機器に対して要求されたサービスを提供するための通信制御装置であって、
複数のサービス提供デバイスと、
前記複数のサービス提供デバイスそれぞれにより提供されるサービスについての情報を、前記通信回線を介して他の機器から読み取り可能に記憶する記憶手段とを備え、
前記サービスについての情報は、前記複数のサービス提供デバイスごとに階層的な木構造で構成する。
【００２４】
【発明の実施の形態】
［第１の実施の形態］
以下、図面を参照し、本発明の実施形態である通信システム及びそれを構成するイニシエータとターゲットについて詳細に説明する。なお、以下の説明で「本発明の規定に準拠」との表現、あるいはそれに類する表現をする場合があるが、これは、本発明に係るシステムや装置あるいは方法などの構成や手順（実施形態中で説明される）による限定を表すための表現であって、発明が規格や取り決めそのものであることを意味するものではない。
【００２５】
＜システムの構成＞
本実施形態の概略は次のようなものである。すなわち、ＩＥＥＥ１３９４．３の規定によれば、イニシエータのノードが有するデバイス（ユニット）を定義するためのイニシエータユニットディレクトリは、ひとつの物理ノード（１３９４シリアルバスが接続されたノードを指す。物理デバイスとも呼ぶ）はひとつしか持てないとされている。本発明においてはこれを拡張し、ひとつの物理ノードにつき複数のイニシエータユニットディレクトリ持つことができる。そしてそれぞれのイニシエータユニットディレクトリに識別子をつけ、ターゲットからイニシエータに対してＩＥＥＥ１３９４．３で規定されているキューをコネクトするとき必要であれば、前記識別子を論理デバイスを指定するパラメータとして、コネクトリクエストコマンドのパラメータに付加する。なお、論理デバイスとは、ひとつの物理ノードを構成するデバイスそれぞれを指す。たとえば、コンピュータが物理ノードであるとすれば、それにローカル接続されたスキャナやプリンタ、モデムなどがそれぞれ論理デバイスとなり得る。
【００２６】
本発明が適用される機器構成の概略は図１６に示されている。そして、各ノードの構成を定義したデータが登録されているコンフィグＲＯＭの中の構成の一例は図３Ａ、図３Ｂで示される。
【００２７】
図１６において、本システムのイニシエータは、論理デバイスＡ，Ｂ，Ｃを備えている。本例ではこのデバイスはプリンタであるものとする。同じ機器であるために、各論理デバイスは同じサービスを提供する。ここではサービスＡ，Ｂ，Ｃをそれぞれ提供している。コンフィグＲＯＭ（ＣＯＮＦＩＧＲＯＭ）には、各論理デバイスが定義されている。
【００２８】
一方、ターゲットには、イニシエータの提供するサービスを利用するクライアントを有する。イニシエータとターゲットとは１３９４シリアルバスで接続されており、双方とも１３９４回線制御部を介して接続される。
【００２９】
図１は本発明を適応するＩＥＥＥ１３９４．３で規定されたターゲット（以下ターゲット）の電子機器の内部のブロック構成図である。１は本発明を制御するＣＰＵ、２はＣＰＵ１のワークエリアを提供するＲＡＭ、３は本発明のプログラムを提供するハードディスク（フロッピーディスク、ＣＤＲＯＭ、ＭＯ、ＲＯＭ、磁気テープ等でもよい）、５はＩＥＥＥ１３９４回線制御部、８はメインバスである。
【００３０】
図２は本発明を適応するＩＥＥＥ１３９４．３で規定されたイニシエータ（以下イニシエータ）の電子機器の内部のブロック構成図である。１１は本発明を制御するＣＰＵ、１２はＣＰＵ１１のワークエリアを提供するＲＡＭ（コンフィグＲＯＭはここに格納される）、１３は本発明のプログラムを提供するハードディスク（フロッピーディスク、ＣＤＲＯＭ、ＭＯ、ＲＯＭ、磁気テープ等でもよい）、１５はＩＥＥＥ１３９４回線制御部、１８はメインバスである。尚、ＩＥＥＥ１３９４回線制御部にはＩＥＥＥ１３９４、ＳＢＰ−２（Ｓｅｒｉａｌ Ｂｕｓ ｐｒｏｔｏｃｏｌ−２）で規定されている規約が実装されているとする。
【００３１】
尚、本発明は特に断らない限り、ターゲット、イニシエータともにＣＰＵがメインバスを介してＲＡＭ、ハードディスク、ＩＥＥＥ１３９４回線制御部を本発明のプログラムに則り制御して動作する。また、ＩＥＥＥ１３９４回線制御部は、ＩＥＥＥ１３９４プロトコル制御部とも呼ばれるが、本実施形態においては両者は同一のものである。
【００３２】
＜コンフィグＲＯＭの内容＞
図３Ａに本発明に係るイニシエータのコンフィグＲＯＭの内容の一例をあげる。構成情報は階層構造のディレクトリで管理される。すなわち、ルートディレクトリの下に、論理デバイスを定義するインスタンスディレクトリがあり、その下に論理デバイスを更に詳細に定義するためのユニットディレクトリがある。更に各論理デバイスの提供するサービス等を定義したフィーチャーディレクトリがその下にある。
【００３３】
図３Ｂはその詳細を示す。ルートディレクトリ３０１の下には、インスタンスとして各論理デバイスを定義するインスタンスディレクトリがリンクされている。たとえばインスタンスディレクトリ３０２には、論理デバイスであるプリンタＢのモデル識別子が記述されているのに加えて、さらにその下のユニットディレクトリ３０３へのリンクが用意されている。ユニットディレクトリには、プロトコルを指定するスペシファイア（本実施形態ではＩＥＥＥ１３９４を示す０ｘ５０２９が指定される）と、プロトコルのバージョン、さらにサービスを定義するフィーチャーディレクトリ３０４へのリンクが含まれる。フィーチャーディレクトリ３０４には、論理デバイスＢが提供するサービスである、サービスＡ，Ｂ，Ｃが定義されている。
【００３４】
ここで注目すべきは、イニシエータユニットディレクトリ１はＩＥＥＥ１３９４．３が規定するとおりであるが、イニシエータユニットディレクトリ２，３についてはＩＥＥＥ１３９４．３が規定するバージョンの値が異なり、それ以外の項目はＩＥＥＥ１３９４．３の規定とおりである。すなわち、ＩＥＥＥ１３９４．３が規定するイニシエータユニットディレクトリのバージョンの値は０だがイニシエータユニットディレクトリ２，３では１である。このバージョン番号により、本来のＩＥＥＥ１３９４．３の規格であるか、本実施形態で説明する拡張規格であるかが判定可能となる。
【００３５】
そして、イニシエータユニットディレクトリ３にはイニシエータユニットディレクトリ２の特徴に加えて、ＤＩＲＥＣＴＯＲＹ＿ＩＤ（ディレクトリＩＤ）の項目がある。
【００３６】
なお本発明の前提として、特に断らない限り、ターゲットにはＩＥＥＥ１３９４．３が規定するターゲットに必要な機能が、そしてイニシエータにはイニシエータに必要な機能が実装されているとする。そしてターゲットとイニシエータはＩＥＥＥ１３９４で規定された回線で物理的に接続されているとする（図１６参照）。
【００３７】
＜ターゲットの動作＞
次に本発明に係るターゲットの動作を図４Ａ、図４Ｂ、図５、図６のフローチャートを用いて詳細に説明する。最初に図４Ａ，４Ｂに従い説明する。
【００３８】
図４Ａ，４Ｂのフローチャートを実現するためのプログラムがターゲットの機器初期化の過程で起動された後、アプリケーションからの物理デバイス、論理デバイスとサービスを指定したパラメータを伴った接続要求（コネクトの指示）を待っている（Ｓ１０１）。もしそのような接続要求を受信したならば、１３９４回線制御部５に、今１３９４回線で接続されている物理デバイス（物理ノード）をすべて列挙するように要求する（Ｓ１０２）。なお、図では１３９４プロトコル制御部と記載されているが、すべて１３９４回線制御部のことである。
【００３９】
１３９４回線制御部５がＩＥＥＥ１３９４回線を介して現在接続されている物理デバイス名を読み取る（Ｓ１０３）。１３９４回線制御部５から現在接続されている物理デバイスのリストを受け取ると、その中にアプリケーションが指定した物理デバイスがあるかどうか調べる（Ｓ１０４）。もしなければ、アプリケーションに指定した物理デバイスがないことを通知する（Ｓ１０６）。そしてＳ１０１へ戻る。
【００４０】
もし、物理デバイスのリストにアプリケーションが指定した物理デバイスがあれば、その物理デバイスのルートディレクトリの読み込みを１３９４回線制御部５に要求する（Ｓ１０５）。１３９４回線制御部５が読んだルートディレクトリの中にまだその属性を調査していないインスタンスディレクトリのエントリがあるどうかルートディレクトリを調べる（Ｓ１０７）。
【００４１】
すべてのインスタンスディレクトリのエントリに関して調査済みであれば、ＭＯＤＥＬＦＬＧがＯＮかＯＦＦか調べる（Ｓ１０８）。もしＭＯＤＥＬＦＬＧがＯＮであれば、ＩＥＥＥ１３９４．３と本発明に係る方法以外の方法で通信（接続）ができる可能性があるので、もし可能であれば、他の通信プロトコル（例えばＦＣＰ等）で接続を試みる（図４Ｂ：Ｓ１０９）。そして終了後Ｓ１０１へ進む。もしＭＯＤＥＬＦＬＧがＯＦＦであれば、アプリケーションに指定した論理デバイスがないことを通知する（Ｓ１０６）。そしてＳ１０１へ戻る。
【００４２】
一方、ステップＳ１０７において、もし未調査のインスタンスディレクトリのエントリが１３９４回線制御部５が読んだルートディレクトリにあれば、その中の一番若いアドレスのインスタンスディレクトリを読むように１３９４回線制御部５に要求する（Ｓ１１０）。１３９４回線制御部５が読みこんだインスタンスディレクトリのモデルのエントリに書かれているモデルがアプリケーションがコネクトを要求した論理デバイスと一致するかどうか調べる（Ｓ１１１）。もし一致しなければＳ１０７へ戻る。もし一致すればＭＯＤＥＬＦＬＧをＯＮにする（Ｓ１１２）。ＭＯＤＥＬＦＬＧは図４Ａ，４Ｂの手順のプログラムが起動するとき、ＯＦＦに初期化されているものとする。
【００４３】
未調査のユニットディレクトリのエントリが１３９４回線制御部５が読んだインスタンスディレクトリにあるかどうか調べる（Ｓ１１３）。もしすべてのユニットディレクトリのエントリが調査済みであれば、このインスタンスディレクトリは、本実施形態で定義する手順（プロトコル）に適合しないと判断してステップＳ１０７へ進む。
【００４４】
もし未調査のユニットディレクトリのエントリが１３９４回線制御部５が読んだインスタンスディレクトリにあれば、その中の一番若いアドレスのユニットディレクトリを読むように１３９４回線制御部５に要求する（Ｓ１１４）。１３９４回線制御部５が読みこんだユニットディレクトリのスペシファイアＩＤの項目の値が０ｘ５０２９（ＩＥＥＥ１３９４．３を作成した団体の識別子）であるか調べる（Ｓ１１５）。スペシファイアＩＤの項目の値が０ｘ５０２９でなければ、このユニットディレクトリは１ＥＥＥ１３９４をサポートしていないと判断し、Ｓ１０７へ進む。
【００４５】
スペシファイアＩＤの項目の値が０ｘ５０２９であれば、１３９４回線制御部５が読みこんだユニットディレクトリのバージョンエントリの値を調べる（Ｓ１１６）。ユニットディレクトリのバージョンエントリの値が０ｘ００であれば、このユニットディレクトリはＩＥＥＥ１３９４．３完全準拠のものであると判断し、図５のＡへ進む。もしユニットディレクトリのバージョンエントリの値が０ｘ０１であれば（Ｓ１１７）、ＩＥＥＥ１３９４．３を拡張した、本実施形態で定義する手順に従うものと判断し、図５のＢへ進む。ユニットディレクトリのバージョンエントリの値が０ｘ００でも、０ｘ０１でもなければ、他のプロトコルで通信できる可能性があるため、可能であればその処理を行う（Ｓ１０９）。
【００４６】
このようにして、ターゲットは、イニシエータの資源を示す階層的な構成を獲得し、その資源をターゲットが欲するものであるか否か判断することができる。
【００４７】
＜本発明に係るターゲットの動作＞
ここからは、このユニットディレクトリがＩＥＥＥ１３９４．３を拡張した規格に準拠する、本発明に係るターゲットの動作を図６を用いて説明する。
【００４８】
読み込んだユニットディレクトリにディレクトリＩＤのエントリがあるかどうか調べる（Ｓ３０１）。もしディレクトリＩＤのエントリがあればその値をＩＮＳ（ディレクトリ識別子格納場所）に格納する（Ｓ３０３）。もしなければ読み込んだユニットディレクトリの先頭アドレスをＩＮＳに格納する（Ｓ３０２）。
【００４９】
アプリケーションから指定されたサービスに対応したサービスＩＤとＩＮＳに格納されたユニットディレクトリにディレクトリＩＤを組み込んだコネクトコントロールリクエストを作成する（Ｓ３０４）。コネクトコントロールリクエストは図９に示したとおりである。すなわち、先頭のＲｑフィールドの値はリクエストを表す“１”、ｃｔｒｌ＿ｆｕｎｃｔｉｏｎフィールドの値はコネクトであることを表す“ＣＯＮＮＥＣＴ”であり、ｒｅｓｐｏｎｓｅフィールドについては、リクエストなのでその値は特に問題にならない。その他のフィールドは図９に示すとおりとなる。ここではコネクトコントロールリクエストのサービスＩＤを“ＰＲＮ”（印刷）であるとする。またＤＩＲＥＣＴＯＲＹ＿ＩＤをここでは２Ｆ４２５６であるとする。ＤＩＲＥＣＴＯＲＹ＿ＩＤの定義は図１４に示してある。すなわち、ターゲットが接続を試みたイニシエータ中のユニットディレクトリを特定する値である。
【００５０】
そして、すでに当該イニシエータの物理デバイスとＳＢＰ−２のログインが確立しているか調べる（Ｓ３０５）。もし確立していなければ、１３９４回線制御部５に、ＩＥＥＥ１３９４．３規定のリバースログイン処理を要求する（Ｓ３０６）。リバースログインでログインが確立できたかどうか確認し（Ｓ３０７）、もし確立できなければ、アプリケーションにコネクト失敗を報告しステップＳ３０８へ進む。
【００５１】
ＳＢＰ−２のログインが確立していたり、リバースログイン処理が成功したとき、前記のコネクトコントロールリクエスト（単にコネクトとも呼ぶ）をＩＥＥＥ１３９４．３規定の方法でイニシエータに送信するように１３９４回線制御部５に要求する（Ｓ３０９）。そして１３９４回線制御部５が当該イニシエータの物理デバイスから何か送信されてくることを待つ（Ｓ３１０）。１３９４回線制御部５が当該イニシエータの物理デバイスから何か受信したとき、それがコネクトに対するレスポンス（単にコネクトレスポンスとも呼ぶ）かどうか調べる（Ｓ３１１）。コネクトレスポンスがＯＫであれば、図１１に示す値がレスポンスされる。すなわち、Ｒｑフィールドの値が“０”、ｃｔｒｌ＿ｆｕｎｃｔｉｏｎフィールドの値が“ＣＯＮＮＥＣＴ”、ｒｅｓｐｏｎｓｅフィールドの値はＯＫを示す“０”である。
【００５２】
コネクトコントロールリクエストに対するスポンスでなければ、そのコマンドに対応する処理を行う（Ｓ３１２）。コネクトレスポンスであれば、その結果がコネクトＯＫかＮＧ（失敗）かをレスポンス項目で判定する（Ｓ３１３）。コネクトがＮＧであればアプリケーションにコネクト失敗を報告してステップＳ３０８へ進む。コネクトがＯＫであればアプリケーションが要求したサービスが利用可能になったことをアプリケーションに報告する（Ｓ３１４）。そしてアプリケーションの指示に従い、データの送受信をおこない（Ｓ３１５）、アプリケーションの指示によりシャットダウン処理を行う（Ｓ３１６）。
【００５３】
他にアクティブなキューがログイン上に存在するかどうかを調べ（Ｓ３１７）、存在しなければログアウト処理を１３９４回線制御部５を要求して（Ｓ３１８）終了する。存在すればそのまま終了する。
【００５４】
＜ＩＥＥＥ１３９４．３準拠のターゲットの動作＞
ここからはこのユニットディレクトリがＩＥＥＥ１３９４．３準拠のときのターゲットの動作を図５を用いて説明する。
【００５５】
まずアプリケーションから指定されたサービスに対応したサービスＩＤを組み込んだコネクトコントロールリクエストを作成する（Ｓ２０１）。図８にその内容を示す。ｃｎｔｒｌ＿ｆｕｎｃｔｉｏｎフィールドがコネクトコントロールリクエストを示す“ＣＯＮＮＥＣＴ”であり、残りのフィールドは図示したとおりである。ここではサービスＩＤを“ＰＲＮ”とする。
【００５６】
そして、すでに当該イニシエータの物理デバイスとＳＢＰ−２のログインが確立しているか調べる（Ｓ２０２）。もし確立していなければ、１３９４回線制御部５にＩＥＥＥ１３９４．３規定のリバースログイン処理を要求する（Ｓ２０３）。もしリバースログインでログインが確立できたかどうか確認し（Ｓ２０４）、もし確立できなければ、アプリケーションにコネクト失敗を報告し、ステップＳ２０５へ進む。
【００５７】
ＳＢＰ−２のログインが確立していたり、リバースログイン処理が成功したとき、ステップＳ２０１で作成したコネクトコントロールリクエストをＩＥＥＥ１３９４．３規定の方法でイニシエータに送信するように１３９４回線制御部５に要求する（Ｓ２０６）。そして１３９４回線制御部５が当該イニシエータの物理デバイスから何か送信されてくることを待つ（Ｓ２０７）。１３９４回線制御部５が当該イニシエータの物理デバイスから何か受信したとき、それがコネクトレスポンスかどうか調べる（Ｓ２０８）。
【００５８】
コネクトレスポンスであれば図１１のレスポンスが返される。コネクトレスポンスでなければ、そのコマンドに対応する処理を行う（Ｓ２０９）。コネクトレスポンスであれば、その結果がコネクトＯＫかＮＧ（失敗）かをレスポンス項目で判定する（Ｓ２１０）。コネクトがＮＧであればアプリケーションにコネクト失敗を報告してＳ２０５へ進む。コネクトがＯＫであればアプリケーションが要求したサービスが利用可能になったことををアプリケーションに報告する（Ｓ２１１）。そしてアプリケーションの指示に従い、データの送受信をおこない（Ｓ２１２）アプリケーションの指示によりシャットダウン処理を行う（Ｓ２１３）。
【００５９】
他にアクティブなキューがログイン上に存在するかどうかを調べ（Ｓ２１４）、存在しなければログアウト処理を１３９４回線制御部５を要求して（Ｓ２１５）終了する。存在すればそのまま終了する。
【００６０】
＜イニシエータの動作＞
次に本発明に係るイニシエータの動作を図７Ａ乃至図７Ｃを用いて説明する。イニシエータは、本発明を含む機器が初期化されたとき、同時の起動、初期化されるものとする。また、ＳＢＰ−２で規定されているログインの動作は１３９４回線制御部１５が制御するので、ここでは詳細に説明しない。
【００６１】
まず１３９４回線制御部１５から本発明に関わるデータを当該ターゲット機器から受信するのを待つ（Ｓ４０１）。そして受信したデータがキュー０に関わるものかどうかを、対応するＯＲＢのキューの項目（ＩＥＥＥ１３９４．３で規定）を調べる（Ｓ４０２）。もしキュー０に関するものでなければ、そのキュー番号に対応する処理（ＩＥＥＥ１３９４．３で規定）を行う（Ｓ４０３）。Ｓ４０１へ進む。
【００６２】
キュー０に関するものであれば、そのコントロールインフォメーションのｃｎｔｒｌ＿ｆｕｎｃｔｉｏｎの項目（図８，９参照）がコネクトかどうか調べる（Ｓ４０４）。コネクトでなければ、指定されたコントロールファンクションに対応する処理（ＩＥＥＥ１３９４．３で規定）を行い（Ｓ４０５）、Ｓ４０１へ進む。
【００６３】
そのコントロールインフォメーションのｃｎｔｒｌ＿ｆｕｎｃｔｉｏｎの項目（図８，９参照）がコネクトであれば、そのコントロールインフォメーションのＲｑの項目を調べる（Ｓ４０５）。Ｒｑの項目がレスポンスであれば対応する処理（ＩＥＥＥ１３９４．３で規定）を行い（Ｓ４０６）、Ｓ４０１へ進む。
【００６４】
もしそのコントロールインフォメーションのＲｑの項目がリクエストであれば、コントロールインフォメーションにＤＩＲＥＣＴＯＲＹ＿ＩＤの項目（図８，９，１４参照）があるかどうか調べる（Ｓ４０７）。
【００６５】
もしＤＩＲＥＣＴＯＲＹ＿ＩＤの項目があればその他のパラメータはＩＥＥＥ１３９４．３のコネクトコントロールで規定されている通りのパラメータがどうか調べる（Ｓ４０８）。もし規定外であれば対応するエラー処理をおこない（Ｓ４０９）、Ｓ４０１へ進む。
【００６６】
ステップＳ４０８において、もしＤＩＲＥＣＴＯＲＹ＿ＩＤの項目以外のすべてパラメータがＩＥＥＥ１３９４．３のコネクトコントロールで規定通りであれば、ＤＩＲＥＣＴＯＲＹ＿ＩＤの項目で指定されているディレクトリＩＤと同値のディレクトリＩＤを持つユニットディレクトリがイニシエータ内に存在するかどうか調べる（Ｓ４１１）。もしＤＩＲＥＣＴＯＲＹ＿ＩＤと同値のディレクトリＩＤを持つユニットディレクトリがイニシエータ内に存在しなければ、ＤＩＲＥＣＴＯＲＹ＿ＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在するかどうか調べる（Ｓ４１２）。ＤＩＲＥＣＴＯＲＹ＿ＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在しなければコネクトレスポンスのパラメータに“指定されたユニットは存在しない”を設定する（図１５，１２参照）（Ｓ４１３）。そしてＳ４２２へ進む。
【００６７】
ステップＳ４２２では、指定されたコネクトレスポンスのパラメータを含むコネクトレスポンスを作成する。そして１３９４回線制御１５に作成したコネクトレスポンスを送信するように要求する（Ｓ４２３）。そしてＳ４２９へ進む。
【００６８】
ステップＳ４１１において、ＤＩＲＥＣＴＯＲＹ＿ＩＤの項目で指定されているディレクトリＩＤと同値のディレクトリＩＤを持つユニットディレクトリがイニシエータ内に存在するか、または、ＤＩＲＥＣＴＯＲＹ＿ＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在すれば、ＤＩＲＥＣＴＯＲＹ＿ＩＤの指すユニットディレクトリが図１７に示したようなディレクトリの内容を持つかどうか調べる（Ｓ４１４）。もし異なれば、コネクトレスポンスのパラメータに“指定されたユニットは存在しない”を設定する（図１５，１２参照）（Ｓ４１３）。そしてＳ４２２へ進む。図１７は本発明に係るユニットディレクトリの内容を示し、スペシファイヤＩＤ及びバージョンの各エントリが必須であり、ディレクトリＩＤと、提供可能なサービスを定義するフィーチャーディレクトリが必要に応じて付加される。図２３は、各エントリに対応するコードを示している。図のように、スペシファイアＩＤは１２（１６進）、バージョンは１３（１６進）、フィーチャディレクトリオフセットは９Ａ（１６進）で示される。また、スペシファイアＩＤ及びバージョンそれぞれのエントリについては、００５０２９（１６進），０００００１（１６進）という値で固定されている。
【００６９】
ステップＳ４１４において、もしＤＩＲＥＣＴＯＲＹ＿ＩＤの指すユニットディレクトリが、本実施形態で説明するディレクトリの内容、すなわち、図１７に示すようなエントリを有するのであれば、コネクトコントロールで指定されたサービスＩＤで要求されたサービスを、指定されたＤＩＲＥＣＴＯＲＹ＿ＩＤの指すユニットディレクトリに対応するユニット（論理デバイス）がサポートしているかどうか調べる（Ｓ４１５）。もしサポートしていなければコネクトレスポンスのパラメータに”指定されたサービスを指定されたユニットはサポートしていない”を設定する（図１５，１３参照）（Ｓ４１６）。Ｓ４２２へ進む。
【００７０】
ステップＳ４０７において、もしディレクトリＩＤの項目がなければ、ＩＥＥＥ１３９４．３のコネクトコントロールで規定されている通りのパラメータがどうか調べる（Ｓ４１０）。もし規定外であれば対応するエラー処理をおこないＳ４２１へ進む。すべてのパラメータが規定通りであればコネクトコントロールで指定されたサービスＩＤで要求されたサービスを、イニシエータはサポートしているかどうか調べる（Ｓ４１７）。
【００７１】
サポートしている場合には、コネクトコントロールで指定されたサービスＩＤで要求されたサービスが必要とするキューの性格、数がコネクトコントロールのキューフィールドで指定されたものと合致するかどうか調べる（Ｓ４１８）。そして合致していなければ、コネクトレスポンスのパラメータに“ミスマッチ”を設定する（図１５、図１０参照）（Ｓ４１９）。Ｓ４２２へ進む。
【００７２】
一方ステップＳ４１８において、もしコネクトコントロールで指定されたサービスＩＤで要求されたサービスが必要とするキューの性格、数がコネクトコントロールのキューフィールドで指定されたものと合致していれば、サービスを要求されたサーバーは指定されたサービスを提供するかどうか調べる（Ｓ４２０）。もし接続しないのであればコネクトレスポンスのパラメータに“接続拒否”を設定する（図１５，図１９参照）（Ｓ４２１）。そしてＳ４２２へ進む。
【００７３】
サービスを要求されたサーバは指定されたサービスを提供するのであれば、コネクトレスポンスのパラメータに“接続ＯＫ”を設定する（図１５、図１１参照）（Ｓ４２４）。そしてＳ４２５へ進む。
【００７４】
指定されたコネクトレスポンスのパラメータを含むコネクトレスポンスを作成する（Ｓ４２５）。そして１３９４回線制御１５に作成したコネクトレスポンスを送信するように要求する（Ｓ４２６）。そしてクライアントの要求に従い１３９４回線制御１５を介してイニシエータとターゲット間でデータの送受信をＩＥＥＥ１３９４．３で規定された方法で行う（Ｓ４２７）。サービスが終了すればクライアントの要求に従い、ＩＥＥＥ１３９４．３で規定された方法でシャットダウン処理を行う（Ｓ４２８）。なお、クライアントとは、ターゲットを介してイニシエータにサービスを要求するアプリケーションを指す。すなわち、図５のステップＳ２１２，２１３、あるいは、図６のステップＳ３１５，３１６における処理に対応して、ステップＳ４２７，Ｓ４２８の処理は行われる。ステップＳ４２７においては、データの送受信が行われると共に、ターゲットから指定されたサービスがイニシエータによって提供される。その際、ターゲットから、イニシエータにより管理されている論理デバイスおよびその論理デバイスによりサポートされるサービスが指定されていれば、指定された論理デバイスによる指定されたサービスが提供される。
【００７５】
たとえば、ターゲットからイニシエータに対して発行するコネクトコントロールファンクションのＤＥＶＩＣＥ＿ＩＤフィールドで、図３Ｂの論理プリンタＢのユニットディレクトリ３０３のアドレスを指定し、論理プリンタＢがサポートするサービスである「印刷」を指定すれば、ターゲットとイニシエータとの間にコネクションが確立される。その後、イニシエータは、ターゲットに対してバッファを提供し、ターゲットからそのバッファに書き込まれるデータを読んで、そのデータに基づいて印刷というサービスを遂行することになる。
【００７６】
その後、そのログイン内にキュー０以外のアクティブなキューがあるかどうか調べ（Ｓ４２９）、もしあればステップＳ４０１へ進む。なければＳＢＰ−２で規定されているログアウト処理を行い、終了する（Ｓ４３０）。
【００７７】
ステップＳ４１０においてパラメータが正常でないと判定された場合、あるいは、ステップＳ４１７において指定されたサービスをイニシエータが提供していないと判定された場合には、それぞれに対応する処理を行って（Ｓ４１０−１）、ステップＳ４１９へ進む。
【００７８】
以上の手順により、イニシエータにおけるコンフィグＲＯＭにより、イニシエータの論理デバイスごとに各論理デバイスで使用可能なサービスを管理することで、ターゲットとイニシエータとのコネクションを、ターゲットからイニシエータの論理デバイス及びサービスを指定して確立することができる。さらに、ターゲットは指定した論理デバイスによりサービスの提供を受けることができる。
【００７９】
以上の構成及び手順により、ＩＥＥＥ１３９４．３が規定するイニシエータの役割の１つのノードが複数のインスタンスを持つとき、それぞれのインスタンスとサービスの関係を表現することができ、また１つのノード内の複数のインスタンスが同じサービスＩＤのサービスを提供しているときでも、そのサービスＩＤが格納されている、フィーチャーディレクトリ、ユニットディレクトリのすくなくともどちらかのディレクトリＩＤを指定することによりどのインスタンスが提供しているサービスのサービスＩＤなのかを特定して表現することができる。
【００８０】
これにより回線で接続されている、本発明をサポートしている他のノードはサービスＩＤで公開されているサービスがどのインスタンスによって提供されているか理解することが可能になる。具体的に多機能周辺機器等の対応が可能になる。
【００８１】
また、既存のＩＥＥＥ１３９４．３でイニシエータ用のユニットディレクトリと規定されたユニットディレクトリと、本発明で規定されたユニットディレクトリが混在している場合でも、１つのノードにつき、ひとつのインスタンスに限ってのみだではあるものの、既存のＩＥＥＥ１３９４．３との下位互換が可能になる。
【００８２】
［第２の実施の形態］
第１の実施の形態では本発明で規定されたユニットディレクトリでのみ構成されるケースについて説明したが、本実施形態では既存のＩＥＥＥ１３９４．３でイニシエータ用のユニットディレクトリと規定されたユニットディレクトリと本発明で規定されたユニットディレクトリが混在していないときの例を示す。図２４はその場合の階層構造を示す図である。
【００８３】
こうすることにより、１つのノードにつき、ひとつのインスタンスに限ってのみだが既存のＩＥＥＥ１３９４．３の下位互換が可能になる。
【００８４】
【発明の効果】
以上の説明したように、ＩＥＥＥ１３９４．３が規定するイニシエータの役割の１つのノードが複数のインスタンスを持つとき、それぞれのインスタンスとサービスの関係を表現することができ、また１つのノード内の複数のインスタンスが同じサービスＩＤのサービスを提供しているときでも、そのサービスＩＤが格納されている、フィーチャーディレクトリ、ユニットディレクトリのすくなくともどちらかのディレクトリＩＤを指定することによりどのインスタンスが提供しているサービスのサービスＩＤなのかを特定して表現することができる。
【００８５】
これにより回線で接続されている、本発明をサポートしている他のノードはサービスＩＤで公開されているサービスがどのインスタンスによって提供されているか理解することが可能になる。具体的に多機能周辺機器等の対応が可能になる。
【００８６】
また、既存のＩＥＥＥ１３９４．３でイニシエータ用のユニットディレクトリと規定されたユニットディレクトリと、本発明で規定されたユニットディレクトリが混在している場合でも、１つのノードにつき、ひとつのインスタンスに限ってのみだではあるものの、既存のＩＥＥＥ１３９４．３との下位互換が可能になる。
【図面の簡単な説明】
【図１】本発明を実装するターゲット側のブロック図である。
【図２】本発明を実装するイニシエータ側のブロック図である。
【図３Ａ】本発明を実装するイニシエータに実装されるコンフィグＲＯＭの概略階層図である。
【図３Ｂ】本発明を実装するイニシエータに実装されるコンフィグＲＯＭの具体的なエントリの値の一例を示す図である。
【図４Ａ】、
【図４Ｂ】本発明を実装する、ターゲット側の動作を示すフローチャートである。
【図５】本発明を実装する、ターゲット側の動作を示すフローチャートである。
【図６】本発明を実装する、ターゲット側の動作を示すフローチャートである。
【図７Ａ】、
【図７Ｂ】、
【図７Ｃ】本発明を実装する、イニシエータ側の動作を示すフローチャートである。
【図８】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）リクエストの構造図である。
【図９】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）リクエストを本発明を実装するために拡張したものを示す図である。
【図１０】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図でサービスと指定されたキューのタイプがミスマッチのときの構造図である。
【図１１】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図でコネクトがＯＫのときの構造図である。
【図１２】本発明でＩＥＥＥ１３９４．３で規定から拡張されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図でが指定されたユニットディレクトリがないときの構造図である。
【図１３】本発明でＩＥＥＥ１３９４．３で規定から拡張されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図でが指定されたサービスが指定されたユニットディレクトリがないときの構造図である。
【図１４】本発明でＩＥＥＥ１３９４．３で規定から拡張されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）の値とその意味でディレクトリＩＤが拡張項目を示す図である。
【図１５】本発明でＩＥＥＥ１３９４．３で規定から拡張されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの値とその意味で６、７が拡張項目を示す図である。
【図１６】本発明を実装したときのイニシエータ、ターゲット、イニシエータのコンフィグＲＯＭ、本発明モジュール等の関係の一例をモデル化したものを示す図である。
【図１７】本発明を実装したときのユニットディレクトリの構造図である
【図１８】ＩＥＥＥ１３９４．３で規定されたコネクトコントロールファンクション（ＣＯＮＮＥＣＴ）レスポンスの構造図で接続拒否のときの構造図である
【図１９】従来のユニットディレクトリの構成を示す図である。
【図２０】従来のユニットディレクトリの構成を示す図である。
【図２１】従来のイニシエータにおいて提供するサービスを示す階層ディレクトリ構造を示す図である。
【図２２】従来のイニシエータにおいて提供するサービスを示す階層ディレクトリ構造を示す図である。
【図２３】本発明を実装したときのユニットディレクトリの構造図である
【図２４】第２実施形態におけるイニシエータに実装されるコンフィグＲＯＭの概略階層図である。
Claims (5)
- ＩＥＥＥ１３９４．３におけるターゲットとして機能する外部装置と通信し、ＩＥＥＥ１３９４．３におけるイニシエータとして機能する通信制御装置であって、
前記通信制御装置が提供可能な複数の機能を示す情報、及び、それぞれの機能に対応する複数のユニットディレクトリを格納する格納手段と、
ユニットディレクトリを特定するディレクトリＩＤを前記外部装置から受信する受信手段と、
前記受信手段によって受信したディレクトリＩＤに対応するユニットディレクトリが前記通信制御装置内に存在するか否かを判定する判定手段と、
前記受信手段によって受信したディレクトリＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在するかどうかを判断する判断手段と、
前記判定手段が前記格納手段に前記ディレクトリＩＤに対応するユニットディレクトリが存在すると判定した場合、または前記判断手段が前記ディレクトリＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在すると判断した場合にＩＥＥＥ１３９４．３に規定された方法で前記外部装置と通信を行う通信手段とを有し、
前記通信手段は、前記判定手段が前記格納手段に前記ディレクトリＩＤに対応するユニットディレクトリが存在しないと判定し、前記判断手段が前記ディレクトリＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在しないと判断した場合に前記ＩＥＥＥ１３９４．３に規定された方法で前記外部装置と通信しないことを特徴とする通信制御装置。 - 前記複数のユニットディレクトリは、それぞれが前記通信制御装置の通信プロトコル能力に依存する属性を保持することを特徴とする請求項１に記載の通信制御装置。
- 前記複数のユニットディレクトリは、それぞれがＩＥＥＥ１３９４．３の規格に準拠したものか、ＩＥＥＥ１３９４．３の拡張規格であるかを示すバージョン情報を保持することを特徴とする請求項２に記載の通信制御装置。
- 前記通信手段による通信で受信したデータを印刷するための印刷手段をさらに備えることを特徴とする請求項１乃至３のいずれか一項に記載の通信制御装置。
- ＩＥＥＥ１３９４．３におけるターゲットとして機能する外部装置と通信し、ＩＥＥＥ１３９４．３におけるイニシエータとして機能する通信制御装置の制御方法であって、前記通信制御装置が提供可能な複数の機能を示す情報、及び、それぞれの機能に対応する複数のユニットディレクトリを格納部に格納する格納ステップと、
ユニットディレクトリを特定するディレクトリＩＤを前記外部装置から受信する受信ステップと、
前記受信ステップによって受信したディレクトリＩＤに対応するユニットディレクトリが前記通信制御装置内に存在するか否かを判定する判定ステップと、
前記受信ステップによって受信したディレクトリＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在するかどうかを判断する判断ステップと、
前記判定ステップが前記格納部に前記ディレクトリＩＤに対応するユニットディレクトリが存在すると判定した場合、または前記判断ステップが前記ディレクトリＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在すると判断した場合にＩＥＥＥ１３９４．３に規定された方法で前記外部装置と通信を行う通信ステップとを有し、
前記通信ステップは、前記判定ステップが前記格納部に前記ディレクトリＩＤに対応するユニットディレクトリが存在しないと判定し、前記判断手段が前記ディレクトリＩＤの値を先頭アドレスに持つユニットディレクトリがイニシエータ内に存在しないと判断した場合に前記ＩＥＥＥ１３９４．３に規定された方法で前記外部装置と通信しないことを特徴とする通信制御装置の制御方法。
Priority Applications (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000332891A JP4683587B2 (ja) | 2000-10-31 | 2000-10-31 | 通信制御装置及び方法 |
| PCT/JP2001/009505 WO2002037769A1 (fr) | 2000-10-31 | 2001-10-30 | Appareil et procede de gestion de communication |
| AT01978946T ATE367037T1 (de) | 2000-10-31 | 2001-10-30 | Vorrichtung und verfahren zur kommunikationssteuerung |
| DE60129296T DE60129296D1 (de) | 2000-10-31 | 2001-10-30 | Vorrichtung und verfahren zur kommunikationssteuerung |
| CNB018033555A CN100484070C (zh) | 2000-10-31 | 2001-10-30 | 通信控制装置及方法 |
| KR10-2002-7008592A KR100501856B1 (ko) | 2000-10-31 | 2001-10-30 | 통신 제어 장치 및 방법 |
| EP01978946A EP1241834B1 (en) | 2000-10-31 | 2001-10-30 | Communication control apparatus and method |
| US10/185,233 US7363405B2 (en) | 2000-10-31 | 2002-06-28 | Communication control apparatus and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000332891A JP4683587B2 (ja) | 2000-10-31 | 2000-10-31 | 通信制御装置及び方法 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2002141966A JP2002141966A (ja) | 2002-05-17 |
| JP2002141966A5 JP2002141966A5 (ja) | 2007-12-27 |
| JP4683587B2 true JP4683587B2 (ja) | 2011-05-18 |
Family
ID=18809040
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000332891A Expired - Fee Related JP4683587B2 (ja) | 2000-10-31 | 2000-10-31 | 通信制御装置及び方法 |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7363405B2 (ja) |
| EP (1) | EP1241834B1 (ja) |
| JP (1) | JP4683587B2 (ja) |
| KR (1) | KR100501856B1 (ja) |
| CN (1) | CN100484070C (ja) |
| AT (1) | ATE367037T1 (ja) |
| DE (1) | DE60129296D1 (ja) |
| WO (1) | WO2002037769A1 (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8254372B2 (en) * | 2003-02-21 | 2012-08-28 | Genband Us Llc | Data communication apparatus and method |
| DE10335572A1 (de) * | 2003-07-31 | 2005-03-17 | Deutsche Thomson-Brandt Gmbh | Netzwerkteilnehmerstation für ein Netzwerk verteilter Stationen und Verfahren zum Betreiben einer Netzwerkteilnehmerstation |
| DE60318952T2 (de) * | 2003-12-15 | 2009-01-29 | Alcatel Lucent | Verfahren zum Reaktivieren einer Mehrzahl deaktivierter Geräte, ein entsprechendes Netzwerkelement und eine entsprechende Aktivierungseinrichtung |
| US8027265B2 (en) * | 2004-03-19 | 2011-09-27 | Genband Us Llc | Providing a capability list of a predefined format in a communications network |
| US7990865B2 (en) | 2004-03-19 | 2011-08-02 | Genband Us Llc | Communicating processing capabilities along a communications path |
| TWI386807B (zh) * | 2004-11-24 | 2013-02-21 | Qualcomm Inc | 數位資料介面裝置訊息格式 |
| US7660922B2 (en) * | 2006-05-12 | 2010-02-09 | Intel Corporation | Mechanism to flexibly support multiple device numbers on point-to-point interconnect upstream ports |
| CN101622711B (zh) | 2006-12-28 | 2012-07-18 | 杰恩邦德公司 | 用于无声插入描述符（sid）转换的方法、系统 |
| US8570441B2 (en) * | 2008-06-11 | 2013-10-29 | Microsoft Corporation | One pass video processing and composition for high-definition video |
| US8908541B2 (en) | 2009-08-04 | 2014-12-09 | Genband Us Llc | Methods, systems, and computer readable media for intelligent optimization of digital signal processor (DSP) resource utilization in a media gateway |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000187934A (ja) * | 1998-09-01 | 2000-07-04 | Sony Corp | 情報処理装置および方法、並びに媒体 |
Family Cites Families (39)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS63205747A (ja) * | 1987-02-13 | 1988-08-25 | インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン | 通信方法及びデータ処理システム |
| JP2916828B2 (ja) | 1991-08-07 | 1999-07-05 | 太平洋工業株式会社 | クロスフローファンおよびその組立方法 |
| US5809331A (en) | 1996-04-01 | 1998-09-15 | Apple Computer, Inc. | System for retrieving configuration information from node configuration memory identified by key field used as search criterion during retrieval |
| US5968152A (en) * | 1996-04-10 | 1999-10-19 | Apple Computer, Inc. | Method and apparatus for extending key space in a plug and play ROM |
| CN1167230A (zh) | 1996-06-04 | 1997-12-10 | 王光先 | 民用轻质油汽化燃烧装置 |
| JPH1023097A (ja) * | 1996-07-09 | 1998-01-23 | Nec Commun Syst Ltd | 複数プロトコルバージョン対応方法 |
| US5991842A (en) | 1996-08-27 | 1999-11-23 | Canon Kabushiki Kaisha | Communication system for providing digital data transfer, electronic equipment for transferring data using the communication system, and an interface control device |
| US6523696B1 (en) | 1996-10-15 | 2003-02-25 | Kabushiki Kaisha Toshiba | Communication control device for realizing uniform service providing environment |
| DE69840972D1 (de) | 1997-02-14 | 2009-08-27 | Canon Kk | Vorrichtung, System und Verfahren zur Datenübertragung und Vorrichtung zur Bildverarbeitung |
| EP0859326A3 (en) | 1997-02-14 | 1999-05-12 | Canon Kabushiki Kaisha | Data transmission apparatus, system and method, and image processing apparatus |
| JP3927647B2 (ja) | 1997-04-21 | 2007-06-13 | キヤノン株式会社 | 情報処理装置、情報処理方法及び情報処理システム |
| US6003065A (en) | 1997-04-24 | 1999-12-14 | Sun Microsystems, Inc. | Method and system for distributed processing of applications on host and peripheral devices |
| ID24894A (id) | 1997-06-25 | 2000-08-31 | Samsung Electronics Co Ltd Cs | Metode dan apparatus untuk pembangun tiga-oto suatu jaringan rumah |
| US6667992B1 (en) | 1997-08-04 | 2003-12-23 | Matsushita Electric Industrial Co., Ltd. | Network control system |
| JP4537502B2 (ja) * | 1997-11-20 | 2010-09-01 | 富士フイルム株式会社 | 画像データ通信システムおよび画像データ通信方法ならびに画像データ通信システムを構成するディジタル・カメラおよび画像データ送信方法 |
| US6160796A (en) | 1998-01-06 | 2000-12-12 | Sony Corporation Of Japan | Method and system for updating device identification and status information after a local bus reset within a home audio/video network |
| ES2546173T3 (es) | 1998-03-13 | 2015-09-21 | Canon Kabushiki Kaisha | Aparato y procedimiento para el procesamiento de la información |
| EP0944081B1 (en) | 1998-03-17 | 2009-05-13 | Panasonic Corporation | Data transmission apparatus and method thereof using command adapted thereto |
| US6788882B1 (en) | 1998-04-17 | 2004-09-07 | Timesurf, L.L.C. | Systems and methods for storing a plurality of video streams on re-writable random-access media and time-and channel- based retrieval thereof |
| EP1093319A4 (en) * | 1998-06-30 | 2005-08-10 | Matsushita Electric Ind Co Ltd | NETWORK CONTROL SYSTEM AND METHOD THEREFOR |
| US6185632B1 (en) * | 1998-10-19 | 2001-02-06 | Hewlett-Packard Company | High speed communication protocol for IEEE-1394 including transmission of request and reply writes to a datagram-FIFO-address to exchange commands to end a job |
| US7080399B1 (en) | 1999-01-22 | 2006-07-18 | Matsushita Electric Industrial Co., Ltd. | Network control system, and controller, target and consumer for use in the network control system |
| JP2000253463A (ja) * | 1999-02-26 | 2000-09-14 | Matsushita Electric Ind Co Ltd | ネットワーク制御システム及びこのネットワーク制御システムに用いるターゲット、コントローラ、並びにコンシューマ |
| JP2000341302A (ja) | 1999-05-27 | 2000-12-08 | Sony Corp | 電子機器 |
| US6775244B1 (en) | 1999-06-21 | 2004-08-10 | Intel Corporation | Gathering of device discovery information |
| US6801507B1 (en) | 1999-07-27 | 2004-10-05 | Samsung Electronics Co., Ltd. | Device discovery and configuration in a home network |
| US8032833B1 (en) | 1999-07-27 | 2011-10-04 | Samsung Electronics Co., Ltd. | Home network device information architecture |
| JP3365377B2 (ja) | 1999-08-12 | 2003-01-08 | セイコーエプソン株式会社 | ログイン装置、被ログイン装置、及び装置間通信システム、ログイン制御方法、並びに記録媒体 |
| JP2001086195A (ja) * | 1999-09-14 | 2001-03-30 | Sony Corp | 電子機器 |
| US6671768B1 (en) | 1999-11-01 | 2003-12-30 | Apple Computer, Inc. | System and method for providing dynamic configuration ROM using double image buffers for use with serial bus devices |
| US6813663B1 (en) * | 1999-11-02 | 2004-11-02 | Apple Computer, Inc. | Method and apparatus for supporting and presenting multiple serial bus nodes using distinct configuration ROM images |
| JP2001148706A (ja) * | 1999-11-18 | 2001-05-29 | Canon Inc | 情報処理装置およびその方法、並びに、記憶媒体 |
| US6697884B1 (en) | 2000-01-03 | 2004-02-24 | Genesis Microchip, Inc. | Communication protocol for serial peripheral devices |
| US6723496B2 (en) | 2000-02-22 | 2004-04-20 | Fuji Photo Film Co., Ltd. | Silver halide photographic material |
| US6725311B1 (en) | 2000-09-14 | 2004-04-20 | Microsoft Corporation | Method and apparatus for providing a connection-oriented network over a serial bus |
| JP2002118558A (ja) | 2000-10-10 | 2002-04-19 | Sony Corp | 情報処理装置および方法、並びにプログラム格納媒体 |
| US6907301B2 (en) | 2000-10-16 | 2005-06-14 | Sony Corporation | Method and system for selecting and controlling devices in a home network |
| JP4484353B2 (ja) | 2000-10-31 | 2010-06-16 | キヤノン株式会社 | 通信制御装置及びその制御方法及び通信システム |
| US6760804B1 (en) | 2001-09-11 | 2004-07-06 | 3Com Corporation | Apparatus and method for providing an interface between legacy applications and a wireless communication network |
-
2000
- 2000-10-31 JP JP2000332891A patent/JP4683587B2/ja not_active Expired - Fee Related
-
2001
- 2001-10-30 WO PCT/JP2001/009505 patent/WO2002037769A1/ja active IP Right Grant
- 2001-10-30 EP EP01978946A patent/EP1241834B1/en not_active Expired - Lifetime
- 2001-10-30 DE DE60129296T patent/DE60129296D1/de not_active Expired - Lifetime
- 2001-10-30 KR KR10-2002-7008592A patent/KR100501856B1/ko not_active IP Right Cessation
- 2001-10-30 CN CNB018033555A patent/CN100484070C/zh not_active Expired - Fee Related
- 2001-10-30 AT AT01978946T patent/ATE367037T1/de not_active IP Right Cessation
-
2002
- 2002-06-28 US US10/185,233 patent/US7363405B2/en not_active Expired - Fee Related
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000187934A (ja) * | 1998-09-01 | 2000-07-04 | Sony Corp | 情報処理装置および方法、並びに媒体 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20030005106A1 (en) | 2003-01-02 |
| KR100501856B1 (ko) | 2005-07-20 |
| CN1394413A (zh) | 2003-01-29 |
| JP2002141966A (ja) | 2002-05-17 |
| WO2002037769A1 (fr) | 2002-05-10 |
| DE60129296D1 (de) | 2007-08-23 |
| CN100484070C (zh) | 2009-04-29 |
| WO2002037769A8 (fr) | 2002-12-12 |
| EP1241834B1 (en) | 2007-07-11 |
| ATE367037T1 (de) | 2007-08-15 |
| EP1241834A4 (en) | 2006-01-11 |
| EP1241834A1 (en) | 2002-09-18 |
| KR20020069232A (ko) | 2002-08-29 |
| US7363405B2 (en) | 2008-04-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3740403B2 (ja) | 印刷システム、印刷制御装置、情報処理方法、制御プログラム | |
| US7747779B2 (en) | Information processing apparatus, information processing method, and medium storing therein program for executing the method | |
| US7812984B2 (en) | Remote stored print job retrieval | |
| JP2000033755A (ja) | 周辺装置のネットワ―ク構成方法 | |
| US7720097B2 (en) | Communication apparatus, communication method, communication program and recording medium | |
| JP2005014591A (ja) | 認証動作システム、認証印刷システム、ネットワークプリンタ、プリンタ管理端末、プリンタ用プログラムおよび端末用プログラム、並びに認証印刷方法 | |
| JPH1153139A (ja) | ネットワークシステム、ネットワーク管理方法、インターフェース装置、インターフェース装置を動作させるためのプログラムが記録された記録媒体及び端末装置 | |
| US20030065952A1 (en) | Authentication system using device address to verify authenticity of terminal | |
| JP4683587B2 (ja) | 通信制御装置及び方法 | |
| JP2003271429A (ja) | 記憶装置資源管理方法、記憶資源管理プログラム、該プログラムを記録した記録媒体、及び記憶資源管理装置 | |
| US7768664B2 (en) | Communication system that receives an input from a user | |
| JP2000330742A (ja) | ネットワークプリンタシステム | |
| JP4484353B2 (ja) | 通信制御装置及びその制御方法及び通信システム | |
| JP2001053925A (ja) | 通信制御装置及びシリアルバス管理装置 | |
| US6377977B1 (en) | Method for loading application program and opening files in host terminals before collaborating on a joint project | |
| JP2002244943A (ja) | 周辺装置の選択方法 | |
| JP2014522016A (ja) | ローカル装置へのシェアドアクセス | |
| JP2011114805A (ja) | 通信装置及び方法、並びにプログラム | |
| JP2005051314A (ja) | 無線ｌａｎシステム、アクセスポイント、端末装置および接続管理プログラム | |
| JPH06175957A (ja) | 周辺機器制御装置 | |
| WO2024050753A1 (zh) | 通信方法、第一设备、配置设备以及云平台 | |
| JP3862463B2 (ja) | 情報処理装置およびネットワークシステムおよび印刷装置およびネットワークシステムのデバイス情報登録方法およびコンピュータが読み取り可能な記憶媒体 | |
| JP2865075B2 (ja) | ネットワークプリンタ | |
| JP3638175B2 (ja) | 通信アクセス制御装置 | |
| WO2024050754A1 (zh) | 用于启动客户端的方法、第一设备、配置设备及云平台 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071031 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20071031 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20071031 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20080825 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100323 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100524 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100730 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100924 |
|
| 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: 20110204 |
|
| 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: 20110207 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140218 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 |