(57)【要約】データ項目は、コードワード要素のシーケンスから作られるコードワードにより識別される。このデータ項目及びコードワードは、テーブル（１０２）における複数のエントリに記憶され、これにより、各コードワード要素は別個のエントリに記憶される。テーブル１０２は、コードワード要素の値を記憶する列１０４と、もし存在する場合は直前に記憶されたコードワード要素への参照を記憶する列１０６と、データ項目を記憶する列１０８とを有する。
2004509414.tif 000002
【特許請求の範囲】
【請求項１】
コードワード要素のシーケンスを含むコードワードにより識別されるデータ項目を記憶する方法であって、前記コードワードが記憶空間におけるエントリのグループに記憶され、前記エントリの前記グループへの記憶が、
１）前記グループの各エントリに前記コードワード要素の特定のものを記憶するステップと、
２）前記グループ内の前記エントリからの前記コードワードの復元を可能にするために、もし存在する場合は近傍のコードワード要素の該コードワード要素を含むエントリへの参照を前記グループの各エントリに記憶するステップと、
３）前記グループの少なくとも１つのエントリに前記データ項目への参照を記憶するステップとを含む、データ項目を記憶する方法。
【請求項２】
所与のコードワード要素に関するエントリが、前記所与のコードワード要素にハッシュ関数を適用することにより決定される、請求項１に記載のデータ項目を記憶する方法。
【請求項３】
前記グループの前記エントリが、前記コードワードを構成するコードワード要素のシーケンスの順にアクセスされ、前記記憶ステップ ２）が、前記シーケンスにおける直前に記憶されたコードワード要素の該コードワード要素を含むエントリへの参照を記憶することにより実現される、請求項１に記載のデータ項目を記憶する方法。
【請求項４】
コードワード要素のシーケンスを含むコードワードにより識別されるデータ項目を取り出す方法であって、前記コードワードが記憶空間におけるエントリのグループに記憶されており、前記方法が、
１）前記シーケンスにおける第１のコードワード要素に基づいて前記記憶空間内のポテンシャルエントリの位置を決定し、該ポテンシャルエントリにアクセスして、該ポテンシャルエントリが第１のコードワードに関連するかどうかを確かめるステップと、
２）前記シーケンスにおける後に続くコードワード要素に基づいて、前記記憶空間内のポテンシャルエントリを繰り返し決定し、該ポテンシャルエントリにアクセスして、該ポテンシャルエントリが現在のコードワードに関連するかどうかを確かめるステップと、
３）最後にアクセスされたエントリから前記データ項目への参照を取り出すステップとを含む、データ項目を取り出す方法。
【請求項５】
所与のコードワード要素に関するエントリの位置は、ハッシュ関数を該所与のコードワード要素に適用することにより決定される、請求項４に記載のデータ項目を取り出す方法。
【請求項６】
コードワード要素のシーケンスを含むコードワードにより識別されるデータ項目を記憶するシステムであって、前記システムが、エントリのグループを含む記憶空間と、記憶ユニットとを有し、前記記憶ユニットが、
１）前記グループの各エントリに前記コードワード要素の特定のものを記憶し、
２）前記グループ内の前記エントリからの前記コードワードの復元を可能にするために、もし存在する場合は近傍のコードワード要素の該コードワード要素を含むエントリへの参照を前記グループの各エントリに記憶し、
３）前記グループの少なくとも１つのエントリに前記データ項目への参照を記憶するように構成される、システム。
【請求項７】
特定のコードワード要素が記憶されるエントリを決定するために前記記憶ユニットがハッシュ関数を含む、請求項６に記載のシステム。
【請求項８】
前記記憶ユニットが、前記コードワードを構成するコードワード要素のシーケンスの順に前記グループのエントリにアクセスするように構成され、前記記憶ユニットが、もし存在する場合は前記シーケンスにおける直前に記憶されたコードワード要素の該コードワード要素を含むエントリへの参照を記憶するように構成される、請求項６に記載のシステム。
【請求項９】
個々のデータ項目を識別するコードワードを記憶するデータ構造であって、各コードワードがコードワード要素のシーケンスを含み、前記データ構造において、特定のデータ項目を識別する特定のコードワードがエントリのグループに記憶され、
１）前記グループの各エントリが前記特定のコードワードの前記コードワード要素の特定のものを含み、
２）前記グループの各エントリが、前記グループのエントリから前記特定のコードワードの復元を可能にするために、もし存在する場合は前記特定のコードワードの近傍のコードワード要素の該コードワード要素を含むエントリへの参照を含み、
３）前記グループの少なくとも１つのエントリが前記特定のデータ項目への参照を含むように前記エントリの前記グループが構成されるデータ構造。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コードワード要素（コンポーネント）のシーケンスを含むコードワードによって識別されるデータ項目を記憶する方法に関する。
【０００２】
本発明は更に、コードワード要素のシーケンスを含むコードワードにより識別されるデータ項目を取り出す方法に関する。
【０００３】
本発明は更に、コードワード要素のシーケンスを含むコードワードにより識別されるデータ項目を記憶するシステムに関する。
【０００４】
【従来の技術】
コードワードによってデータ項目を識別し、コードワードを使用して記憶空間にデータ項目を記憶し、そののちそれを取り出すことは良く知られている。コードワードは、一般に、記憶空間におけるデータ項目が記憶されている特定の位置を識別するために使用される。例として、人事登録システムにおける給与番号及び在庫管理システムにおける製品番号が挙げられる。給与番号は、対応する人の１つ又は複数のレコードの位置を見つけだすために使用され、製品番号は、特定の製品の情報の位置を見つけだすために使用される。
【０００５】
このようなコードワードの使用の他の例は、文書「Ａｎ Ｉｎｔｒｏｄｕｃｔｏｒｙ Ｏｖｅｒｖｉｅｗ ｏｆ ＳＮＭＰ」（ＤＤＲＩ， Ｄｉｖｅｒｓｉｆｉｅｄ Ｄａｔａ Ｒｅｓｏｕｒｃｅｓ， Ｉｎｃ， １９９９， Ｎｏｖａｔｏ， ＣＡ ９４９４７， ＵＳＡ）に記載されているようないわゆるＳｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）を実現するシステムにある。このプロトコルでは、ネットワークに関連する或る情報を運ぶ複数のオブジェクトが規定されている。このようなオブジェクトは、複合コードワードであるいわゆるオブジェクト識別子（ＯＩＤ）により識別される。ＯＩＤは、要素のシーケンスからなる。要素の各々は、オブジェクトの特定の側面を規定する特定の階層レベルに関連し、シーケンス全体は、該当するオブジェクトをユニークに識別する。例えば、ＯＩＤ「１．３．６．１．２．１．１．３．０」は、管理された装置がブートされたときからの経過時間であるオブジェクト「ｓｙｓＵｐＴｉｍｅ」を識別する。別の例は、管理された装置の名前であるＯＩＤ「１．３．６．１．３．４」である。管理された装置は、要求時に、関連するオブジェクトの現在の値を供給するために個々のソフトウェア機能（ファンクション）を有する。このために、装置は、オブジェクトのＯＩＤと、そのオブジェクトに関する値を提供するソフトウェア機能との間の関連付けのデータベースを管理する。
【０００６】
【発明が解決しようとする課題】
本発明の目的は、冒頭部分に述べたデータ項目を記憶する方法であって、既知の方法より効率的な方法を提供することである。
【０００７】
【課題を解決するための手段】
この目的は、本発明により、コードワード要素のシーケンスを含むコードワードにより識別されるデータ項目を記憶する方法であって、前記コードワードが記憶空間におけるエントリのグループに記憶され、前記エントリの前記グループへの記憶が、
１）前記グループの各エントリに前記コードワード要素の特定のものを記憶するステップと、
２）前記グループ内の前記エントリからの前記コードワードの復元を可能にするために、もし存在する場合は近傍のコードワード要素の該コードワード要素を含むエントリへの参照を前記グループの各エントリに記憶するステップと、
３）前記グループの少なくとも１つのエントリに前記データ項目への参照を記憶するステップとを含む方法において達成される。
【０００８】
完全なコードワードを作るすべてのコードワード要素を１つのエントリに記憶するのではなく、エントリ毎に１つのコードワード要素を記憶することにより、あるエントリが、異なるコードワードにより使用されることができる。２つのコードワードが共通して１つ又は複数のコードワード要素を有する場合、これらの共通のコードワードは、１度記憶されるだけでよい。本発明によるコードワード要素の記憶は、複数のコードワードが共通して十分なコードワード要素を有するとき、記憶空間を節約する。コードワードがＯＩＤ規格により規定される上述したＳＮＭＰの例では、多くの異なるコードワードが共通して多くのコードワード要素を有するので、記憶空間が節約される。更に、本発明とは逆に、エントリが完全なコードワードを記憶することができるように設計される場合、エントリは、使用されるコードワード要素の最も長いシーケンスと同様の大きさである必要がある。これは、より小さいコードワード要素を含むコードワードについては記憶空間の浪費になる。
【０００９】
本発明によりデータ項目を記憶する方法の実施形態が請求項２に記載されている。ハッシュ関数のコードワード要素への適用は、コードワード要素を記憶するための記憶空間におけるエントリを決定する単純な方法である。ハッシュ関数は、簡単な方法で、コードワード要素の値の範囲を利用可能なエントリの範囲にマップする。
【００１０】
本発明によりデータを記憶する方法の別の実施形態が請求項３に記載されている。特定のコードワード要素を含むエントリに、直前のコードワード要素を含むエントリへの参照を記憶することによって、記憶されたエントリから完全なコードワードを復元するための簡単な手法が提供される。
【００１１】
本発明の他の目的は、冒頭部分に記述したデータ項目を取り出す方法であって、既知の方法より効率的な方法を提供することである。この目的は、コードワード要素のシーケンスを含むコードワードにより識別されるデータ項目を取り出す方法であって、前記データ項目及び前記コードワードが記憶空間におけるエントリのグループに記憶され、前記方法が、
１）前記シーケンスにおける第１のコードワード要素に基づいて前記記憶空間におけるポテンシャルエントリの位置を決定し、このポテンシャルエントリにアクセスしてそれが第１のコードワードに関連するかどうかを確かめるステップと、
２）前記シーケンスにおける後に続くコードワード要素に基づいて前記記憶空間内のポテンシャルエントリを繰り返し決定し、このポテンシャルエントリにアクセスしてそれが現在のコードワードに関連するかどうかを確かめるステップと、
３）最後にアクセスされたエントリから前記データ項目への参照を取り出すステップと、を含む方法において達成される。
【００１２】
完全なコードワードを作るためのすべてのコードワード要素を１つのエントリから取り出すのではなく、エントリ毎に１つのコードワード要素を取り出すことにより、コードワードのより効率的な記憶が可能になる。完全なコードワードを作るすべてのコードワード要素を１つのエントリに記憶するのではなく、エントリ毎に１つのコードワード要素を記憶することにより、或るエントリが、異なるコードワードにより使用されることができる。２つのコードワードが共通して１つ又は複数のコードワード要素を有する場合、これらの共通のコードワードは１度記憶されるだけでよい。複数のコードワードが共通して十分なコードワード要素を有するとき、本発明によるコードワード要素の記憶は、記憶空間を節約することになる。更に、より少ない個々の要素が記憶空間に記憶されるという事実により、所与のコードワードに基づいてデータ項目をより高速にサーチし取り出すことが可能になる。
【００１３】
本発明の他の目的は、冒頭部分に記述したデータ項目を記憶するシステムであって、既知のシステムより効率的なシステムを提供することである。この目的は、本発明により、コードワード要素のシーケンスを含むコードワードにより識別されるデータ項目を記憶するシステムであって、前記システムが、エントリのグループを含む記憶空間と、記憶ユニットとを有し、前記記憶ユニットが、
１）前記グループの各エントリにコードワード要素の特定のものを記憶し、
２）前記グループ内の前記エントリからの前記コードワードの復元を可能にするため、もし存在する場合には近傍のコードワード要素の該コードワード要素を含むエントリへの参照を前記グループの各エントリに記憶し、
３）前記グループの少なくとも１つのエントリに前記データ項目への参照を記憶するように構成されている、システムにおいて達成される。
【００１４】
本発明及びそれに付随する利点は、例示的な実施例及び添付の図面により解明されるであろう。
【００１５】
【発明の実施の形態】
多様な図面の対応する特徴は同じ参照符号により示されている。
【００１６】
図１は、本発明に従って記憶されたデータ項目及びコードワードをもつ記憶空間を示している。この実施例では、記憶空間は、Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）において規定されるオブジェクトのオブジェクト識別子（ＯＩＤ）と、そのオブジェクトに関する機能を実現するソフトウェア機能、すなわちオブジェクトの値にアクセスするための機能との間の関連付けを記憶するために使用される。ＳＮＭＰ及びその中で使用されるオブジェクトは、文書「Ａｎ Ｉｎｔｒｏｄｕｃｔｏｒｙ Ｏｖｅｒｖｉｅｗ ｏｆ ＳＮＭＰ」（ＤＤＲＩ， Ｄｉｖｅｒｓｉｆｉｅｄ Ｄａｔａ Ｒｅｓｏｕｒｃｅｓ， Ｉｎｃ， １９９９， Ｎｏｖａｔｏ， ＣＡ ９４９４７， ＵＳＡ）に記載されている。ＯＩＤは、ＯＩＤ要素より成る。ＯＩＤは、最高１２８個のＯＩＤ要素を含むことができ、ＯＩＤ要素は、（２＾３２）−１の最大値を有することができる。この実施例における記憶空間は、テーブル１０２として実現されている。ＯＩＤと、その実現する機能との間の関連付けは、テーブルにソフトウェア機能のアドレスを記憶することにより記憶される。図１に示される例では、以下のＯＩＤが記憶されている。
ＯＩＤ　１．２．６１．１　　機能Ａ
ＯＩＤ　１．２．６１．２　　機能Ｂ
ＯＩＤ　１．２．６１．３　　機能Ｃ
ＯＩＤ　１．２．６１．４　　機能Ｄ
テーブルのサイズ及び使用される数字は本発明の処理を示すことができる。
【００１７】
テーブル１０２は、ＯＩＤ要素を記憶する列１０４と、所与のＯＩＤの直前のＯＩＤ要素を含むエントリを記憶する列１０６と、ＯＩＤの機能へのアドレスを記憶する列１０８との３列を有する。テーブル１０２の行は、個々のエントリを形成する。このように、エントリは３つのフィールドを有しており、以下のようにしてＯＩＤ要素を記憶する。第１のフィールドは、特定のＯＩＤのＯＩＤ要素を含み、第２のフィールドは、そのＯＩＤの直前のＯＩＤ要素を含むエントリへの参照を含み、第３のフィールドは、そのＯＩＤの機能のアドレスを含む。この実現例では、第１のフィールドのサイズは３２ビットであり、第２のフィールドのサイズは３２ビットであり、第３のフィールドのサイズは１６ビットである。これは、エントリの全体のサイズが８０ビットであり、又は別の表現では８ビットの１０バイトである。例えば、エントリ１１０は、ＯＩＤ「１．２．６１．３」の第４のＯＩＤ要素を含む。
【００１８】
第１のフィールドは、ＯＩＤ要素の値「３」を含み、
第２のフィールドは、ＯＩＤの第３のＯＩＤ要素を含むテーブルの１２番目のエントリ（参照数字１１２で示される）への参照を含み、
第３のフィールドは、機能Ｃへのアドレスを含む。
【００１９】
該当する状況に依存して、フィールドは、後述されるような特別な条件を示すために特定の値を含むことができる。
【００２０】
テーブル１０２は、例えば１３個の複数のエントリを有するが実際にはこれよりかなり多く、これらは最初はすべて空である。空のエントリは、それが空であり、ＯＩＤ要素がそこに記憶されることができることを示すシグナル（しるし）を含む。この実施例では、空のエントリは、そのエントリの第２のフィールドに値「−２」を記憶することによりそのように識別される。エントリ１１４が空のエントリの例である。ＯＩＤの第１のＯＩＤ要素が記憶される場合、直前のＯＩＤ要素は無いので、第２のフィールドは、そのような直前のＯＩＤ要素への参照で埋められない。従って、ＯＩＤの第１のＯＩＤ要素を含むエントリの第２のフィールドは、値「−１」を含む。この例はエントリ１１６である。ＯＩＤの最後のＯＩＤ要素が記憶されるとそのＯＩＤの処理は終わり、このＯＩＤは、テーブルにおいて完全に特徴付けられる（又は表現される）。従って、ＯＩＤを実現する機能へのアドレスは、最後のＯＩＤ要素を含むエントリにのみ記憶される。このように、ＯＩＤ「１．２．６１．３」の最後のＯＩＤ要素を含むエントリ１１０は、その第３のフィールドに機能Ｃのアドレスを有し、ＯＩＤ「１．２．６１．３」の第３のＯＩＤ要素を含むエントリ１１２は、その第３のフィールドに「ｎｉｌ（ニル、空）」値を有する。
【００２１】
ＯＩＤ「１．２．６１．１」及びその関連付けされた機能の記憶は、次のように行われる。第１のＯＩＤ要素「１」に関してエントリが決定される。これは、ハッシュ関数をこのＯＩＤ要素に適用することにより行われ、この関数は、例示に従って値５を返す。これは、ＯＩＤ要素「１」がテーブルの５番目のエントリに記憶されることを意味する。これは、参照数字１１６により示されている。このエントリの第１のフィールドは、値「１」で埋められ、直前のＯＩＤ要素は無いので、第２のフィールドは値「−１」で埋められる。また、ＯＩＤ要素はＯＩＤの最後のものではないので、第３のフィールドは「ｎｉｌ」値で埋められる。次いで、第２のＯＩＤ要素「２」が処理される。例としてハッシュ関数を適用することにより、値８が返される。これは、第２のＯＩＤ要素がテーブルの第８のエントリに記憶されることを示す。第１のフィールドは値「２」を含む。第２のフィールドは値「５」を含む。これは、このＯＩＤの直前のＯＩＤ要素が５番目のエントリに記憶されたことを示す。これはＯＩＤの最後のＯＩＤ要素ではないので、第３のフィールドは「ｎｉｌ」値を含む。そののち第３のＯＩＤ要素が処理される。このＯＩＤ要素「６１」は、１２番目のエントリに記憶され、このエントリはそれぞれのフィールドに「６１」、「８」及び「ｎｉｌ」を含む。最終的に、最後のＯＩＤ要素「１」が記憶される。このＯＩＤ要素は、第３のエントリの第１のフィールドに記憶され、機能Ａのアドレスは、そのエントリの第３のフィールドに入れられる。
【００２２】
第１のＯＩＤ「１．２．６１．１」が上述したように記憶されると、第２のＯＩＤ「１．２．６１．２」の記憶が次のように行われる。第１のＯＩＤ要素を処理する際、これは５番目のエントリに記憶されなければならないようである。このエントリは空でないが、エントリ内の情報がこの第１のＯＩＤ要素に関して記憶される必要があるものと同じであるということが決定される。従って、テーブル内の次の空のエントリを見つける代わりに、５番目のエントリが、第２のＯＩＤの第１のＯＩＤ要素のエントリとみなされる。このように、５番目のエントリは、第１及び第２のＯＩＤによって共用される。全く同じことが第２のＯＩＤの第２及び第３の要素について生じる。第２のＯＩＤの最後のＯＩＤ要素が、そのときまで空だった１０番目のエントリに記憶される。この最後のＯＩＤ要素は、効果的に第２のＯＩＤの処理を終了し、完全に第２のＯＩＤを特徴付ける。従って、第２のＯＩＤに関連付けられた機能Ｂは、この１０番目のエントリに記憶される。
【００２３】
ＯＩＤ「１．２．６１．３」及び「１．２．６１．４」を記憶することは、ＯＩＤ「１．２．６１．２」を記憶するのと同じ条件をもたらす。すなわち、それらは、それらの第４のＯＩＤ要素に関して異なるだけである。これは、５番目、８番目、及び１２番目のエントリがすべての４つのＯＩＤにより共用されることを意味し、これは、テーブル内の効率的な記憶をもたらす。ＯＩＤは、左から右へのＯＩＤ要素のシーケンスが上から下への階層のレベルを反映する標準化された階層において規定される。最上レベルは多くのＯＩＤに関して同じであるので、ＯＩＤは、一般に、左から右への多くのＯＩＤ要素を共有する。
【００２４】
上述したように、特定のコードワード要素が記憶されうるエントリは、ハッシュ関数を使用することにより決定される。この機能は、コードワード要素の値を、テーブルに存在するエントリナンバに変換する。計算されたエントリが異なるコードワード要素によりすでに占有されていることが分かった場合、これは衝突と呼ばれ、直前のエントリナンバにオフセットを適用することにより新しいエントリナンバが決定される。この実施例では、下式を使用することによりハッシュ値が計算される。
ｈａｓｈ ＝ ｏｌｄ＿ｈａｓｈ ＊ １９ ＋ ｃｏｍｐｏｎｅｎｔ＿ｖａｌｕｅ ＋ ７
ここで、ｏｌｄ＿ｈａｓｈは、直前のＯＩＤ要素に関して計算されたハッシュ値であり、ｃｏｍｐｏｎｅｎｔ＿ｖａｌｕｅは、現在のＯＩＤ要素の値である。このハッシュ値は、テーブル内のエントリの利用可能な範囲にマップされる。テーブル内の使用されたエントリの数が増加する場合、衝突の機会は増加し、テーブル内のエントリを決定するプロセスの効率は低下する。従って、テーブルの埋まっている程度が観測され、それが特定の閾値に達すると、テーブルが拡張される。
【００２５】
テーブル１０２は、上述したように、ＯＩＤとこれらのＯＩＤに関する個々のソフトウェア機能との間の関連付けで埋められる。この情報は、テーブルを含む装置上で走るプログラムに関して利用可能である。特定のＯＩＤに関連してリクエストが受け取られる場合、テーブル１０２を使用して、リクエストをサービスするために呼び出される必要があるソフトウェア機能のアドレスが見つけられる。このようなリクエストは、特定のＯＩＤにより規定されるオブジェクトの値に関するリクエストであってもよく、ソフトウェア機能は、呼出し時に適当な場所からのこの値を取り出し、それを返す。特定のＯＩＤに基づいて機能のアドレスを見つけるプロセスは、上述したような記憶のプロセスと同様である。第１のＯＩＤ要素に関するエントリがハッシュ関数を使用することにより決定され、そのエントリが実際にこのＯＩＤ要素を記憶したかどうか、すなわち衝突が発生しないことがチェックされる。衝突が発生する場合、次のエントリが、ＯＩＤ要素を記憶するためのものと同じオフセットを使用して計算される。衝突が発生しない場合、第２のＯＩＤ要素に関するエントリが決定され、そのフィールドが取り出される。第２のフィールドが、処理されたばかりの第１のＯＩＤ要素を含むエントリをも参照しているかどうかを確かめることにより、このエントリが、現在処理されているＯＩＤの一部であるＯＩＤ要素に関連するかどうかがチェックされる。ＯＩＤの最後のＯＩＤ要素が処理されるまで、シーケンスにおけるすべてのＯＩＤ要素について処理が続行する。所望のソフトウェア機能へのアドレスは、この最後のエントリの第３のフィールドから取り出され、その機能を呼び出すために利用可能にされる。
【００２６】
図２は、コードワードにより識別されるデータ項目を記憶する本発明によるシステムを概略的に示す。このシステムは、ＳＮＭＰにより管理されるネットワーク内の装置の一部でありうる。このような装置は、ビデオ情報を受け取り、これをテレビジョン受信機のような表示装置上に表示されるように処理するセットトップボックスでありうる。システムは接続部２０２を有し、特定のオブジェクトと関連するリクエストは、特にこの接続部を通して受け取られる。このリクエストは、特定のオブジェクトのＯＩＤを含む。このリクエストは、その特定のオブジェクトについてどの機能が呼び出されなければならないかを決定するために、管理情報ベース（ＭＩＢ）２０６にアクセスするいわゆるＳＮＭＰエージェント２０４によって処理される。ＭＩＢは、管理情報の論理的グループ化及び管理されたオブジェクトへの読み書きアクセスを実現する。記憶は、それらの計測機能によりシステムに管理情報を提供することを望む計測ベースにおけるモジュールにより要求されうる。ＭＩＢは、ＯＩＤと個々のソフトウェア機能との間の関連付けを含み、図１に示すテーブルに基づく。更に、システムは、ソフトウェア機能にアクセスするためのレイヤ２０８を有する。このレイヤは、ＭＩＢとソフトウェア機能との間の依存性を切り離す。このレイヤ２０８は、上述したようにＯＩＤ及び機能のアドレスを記憶するための記憶機能２１０を有する。このために、記憶ユニットは、テーブル内のエントリを決定するためにハッシュ関数２１２を含むことができる。受信されたリクエストに対応するソフトウェア機能についてアドレスが決定されると、その機能の呼び出しが、インタフェース２１４を介してディスパッチされる。リクエストがオブジェクトの値の取り出しに関係する場合、この値は、ＳＮＭＰエージェント２０４によってインタフェース２１４を介して接続部２０２に返される。
【００２７】
上述した実施例は説明のためであって本発明を制限するものではなく、当業者は、請求項の範囲から逸脱することなく多くの代替の実施例を設計することができるであろうことに注意されたい。請求項において、括弧内にあるいかなる参照符号も請求項を制限するものとして解釈されないものとする。「有する、含む」という語は、請求項に挙げられていない構成要素又はステップの存在を除外しない。単数で表されている構成要素はそれらの複数の存在を除外しない。本発明は、いくつかの別個の要素を含むハードウェアによって、また適切にプログラムされたコンピュータによって実現されることができる。いくつかの手段を列挙している装置の請求項では、それらの手段のいくつかは、ハードウェアの１つの同じアイテムによって具体化されることができる。
【図面の簡単な説明】
【図１】本発明により記憶されたデータ項目及びコードワードを有する記憶空間を示す図。
【図２】コードワードによって識別されるデータ項目を記憶する本発明によるシステムを示す概略図。
【国際公開パンフレット】
2004509414.tif 000003
2004509414.tif 000004
2004509414.tif 000005
2004509414.tif 000006
2004509414.tif 000007
2004509414.tif 000008
2004509414.tif 000009
2004509414.tif 000010
2004509414.tif 000011
2004509414.tif 000012
2004509414.tif 000013
2004509414.tif 000014
2004509414.tif 000015
【国際調査報告】
2004509414.tif 000016
2004509414.tif 000017