(57)【要約】  アイテムおよびアイテムに関連付けられた属性を保存する電子カタログが提供されている。属性の中の１または複数のものは、複数の値を具備可能である。アイテムは、アイテムテーブル内に保存されており、アイテムの様々な属性は、属性テーブル内の異なる行に保存されている。追加の行をアイテムテーブルに追加することにより、追加のアイテムをカタログに追加可能であり、追加アイテムと関係付けられた属性を属性テーブル内に行として追加可能である。特定の属性は、複数の値を具備可能であり、複数の値を有する属性は、アイテムと関連付けられた異なる属性ツリーまたは属性セットに対応したサブアイテムと関連付けられている。属性値についてサーチを実行可能であり、検索基準を満足したすべてのアイテムおよびサブアイテムを通知するサーチ結果を返すことができる。
2009515258.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータのデータリポジトリ内にデータを保存する方法において、
少なくとも第１のアイテムと、該第１のアイテムと関連付けられた少なくとも第１と第２のサブアイテムを識別するデータを第１のテーブル内に保存する段階と、
前記第１のアイテムと関連付けられた少なくとも第１と第２の属性ＩＤを第２のテーブル内に保存する段階であって、前記第１と第２の属性ＩＤは、それぞれ、前記第１のアイテムの特性を識別している段階と、
前記第１の属性ＩＤの属性値を保存する段階であって、前記属性値は、それぞれ、前記第１と第２のサブアイテムと関連付けられている段階とを含んで成る方法。
【請求項２】
前記第１と第２の属性ＩＤは、前記第２のテーブル内の別個の行に保存される請求項１１記載の方法。
【請求項３】
前記属性値は、第３のテーブル内の別個の行に保存される請求項１記載の方法。
【請求項４】
まず、第２のアイテムを前記第１のテーブルに追加する段階と、
次に、前記最初の追加段階に応答し、少なくとも１つの新しい属性ＩＤを前記第２のテーブルに追加する段階であって、前記新しい属性ＩＤは、前記第２のアイテムと関連付けられている段階とを更に含む請求項１記載の方法。
【請求項５】
第３のサブアイテムを前記第１のテーブルに追加する段階であって、前記第３のサブアイテムは、前記第１のアイテムと関連付けられている段階と、
前記第３のサブアイテムについて第１の新しい属性ＩＤを前記第２のテーブルに追加する段階と、
前記第１の新しい属性ＩＤと関連付けられた少なくとも１つの新しい属性値を追加する段階とを更に含む請求項１記載の方法。
【請求項６】
前記第１のテーブルは、
アイテムを識別する第１の列と、
前記第１の列内において識別されているアイテムと関連付けられたサブアイテムを識別する第２の列と、
それぞれのサブアイテムと関連付けられた属性ツリーを識別する第３の列とを含む請求項１記載の方法。
【請求項７】
前記第２のテーブルは、
アイテムを識別する第１の列と、
前記第１の列のアイテムと関連付けられたサブアイテムを識別する第２の列と、
前記第１の列のアイテムおよび前記第２の列のサブアイテムと関連付けられた属性ＩＤを識別する第３の列とを含む請求項６記載の方法。
【請求項８】
第３のテーブルは、
属性を識別する第１の列と、
前記属性が、関連付けられたストリング値を具備している場合には、ストリング値を識別し、前記属性が、関連付けられたストリング値を具備していない場合には、値を含まない第２の列と、
前記属性が、関連付けられた数値を具備している場合には、数値を識別し、前記属性が、関連付けられた数値を具備していない場合には、値を含まない第３の列とを含む請求項７記載の方法。
【請求項９】
前記第３のテーブルは、
前記属性が、関連付けられた言語値を具備している場合には、言語を識別し、前記属性が、関連付けられた言語値を具備していない場合には、値を含まない第４の列を更に含む請求項８記載の方法。
【請求項１０】
前記アイテムと前記サブアイテムの間の関係を識別する少なくとも１つの属性ツリーを定義するメタデータをメタデータテーブル内に保存する段階を更に含む請求項１記載の方法。
【請求項１１】
前記メタデータは、それぞれのサブアイテムごとに、前記サブアイテムの属性ツリーと、前記属性ツリー内のレベルを識別している請求項１０記載の方法。
【請求項１２】
少なくとも前記第１の属性をキー属性として識別する段階と、
前記第１の属性がキー属性であるという通知を前記メタデータテーブル内に保存する段階とを更に含む請求項１０記載の方法。
【請求項１３】
電子カタログを保存すべく動作可能であるサーバーを有しており、
前記電子カタログは、
少なくとも第１のアイテムおよび前記第１のアイテムと関連付けられた少なくとも第１と第２のサブアイテムを保存する第１のテーブルと、
前記第１のアイテムと関連付けられた少なくとも第１の属性ＩＤを保存する第２のテーブルであって、前記第１の属性ＩＤが前記第１のアイテムの特性を識別するようにした第２のテーブルと、
前記第１の属性ＩＤについて少なくとも第１と第２の属性値を保存する第３のテーブルであって、前記第１と第２の属性値は、それぞれ、前記第１と第２のサブアイテムと関連付けられている第３のテーブルとを含む演算システム。
【請求項１４】
前記サーバーは、ユーザーからサーチ要求を受信すると共に、前記サーチ要求に応答し、前記第１のアイテムおよび前記第１のアイテムと関連付けられた前記属性値を返すべく更に動作可能である請求項１３記載の演算システム。
【請求項１５】
前記サーバーは、前記ユーザーから、少なくとも前記第１の属性ＩＤおよび前記第１の属性値を識別する第２サーチ要求を受信すべく更に動作可能であり、前記サーバーは、これに応答し、前記第１の属性ＩＤおよび前記第１の属性値に等価である関連付けられた属性値を具備したアイテムについて前記電子カタログをサーチすべく動作可能である請求項１４記載の演算システム。
【請求項１６】
前記サーバーは、新しいアイテムを前記電子カタログに追加すべくユーザーからの入力を受信すると共に、これに応答し、前記新しいアイテムと関連付けられた少なくとも１つの行を前記第１のテーブルに追加すべく更に動作可能である請求項１３記載の演算システム。
【請求項１７】
少なくとも第１のアイテムおよび前記第１のアイテムと関連付けられた少なくとも第１と第２のサブアイテムを保存する第１のテーブルと、
前記第１のアイテムと関連付けられた少なくとも第１の属性ＩＤを保存する第２のテーブルであって、前記第１の属性ＩＤが前記第１のアイテムの特性を識別するようにした第２のテーブルと、
前記第１の属性ＩＤの少なくとも第１と第２の属性値を保存する第３のテーブルであって、前記第１と第２の属性値は、それぞれ、前記第１と第２のサブアイテムと関連付けられている、第３のテーブルとを含むコンピュータのデータリポジトリ。
【請求項１８】
前記第１と第２の属性ＩＤは、前記第２のテーブル内の別個の行に保存される請求項１７記載のコンピュータのデータリポジトリ。
【請求項１９】
前記第１と第２の属性値は、前記第３のテーブル内の別個の行に保存される請求項１７記載のコンピュータのデータリポジトリ。
【請求項２０】
前記アイテムと前記サブアイテムの間の関係を識別する少なくとも１つの属性ツリーを定義するメタデータを保存するメタデータテーブルを更に含む請求項１７記載のコンピュータのデータリポジトリ。
【請求項２１】
少なくとも１つの属性を含む第１の属性セットであって、前記第１の属性セットは、アイテムを一意に定義する第１の属性レベルとして識別されており、前記第１の属性セット内の属性は、単一の値を具備可能である、第１属セットと、
前記第１の属性セットと関連付けられた第１の属性ツリーであって、
少なくとも１つの属性を含む第２属性セットであって、前記第２属性セットは、第２属性レベルとして識別されており、前記第２属性セット内の属性は、前記アイテムを識別しており、かつ、少なくとも２つの値を具備可能である、第２属性セットと、
少なくとも１つの属性を含む第３属性セットであって、前記第３属性セットは、第３属性レベルとして識別されており、前記第３属性セット内の属性は、前記第２属性セット内のそれぞれの値ごとに少なくとも２つの値を具備可能である、第３属性セットと、
を有する第１の属性ツリーとを含む電子カタログ。
【請求項２２】
前記第１の属性セットと関連付けられた第２属性ツリーであって、
前記第２属性レベルとして識別された第４属性セットであって、前記第４属性セット内の属性は、少なくとも２つの値を具備可能である、第４属性セットと、
前記第３属性レベルとして識別された第５属性セットであって、前記第５属性セット内の属性は、前記第４属性セット内のそれぞれの値ごとに少なくとも２つの値を具備可能である、第５属性セットと、
を有する第２属性ツリーを更に有しており、
この場合に、前記第２属性ツリーの属性は、前記第１の属性ツリーの属性とは無関係に保存および表示可能である請求項２１記載の電子カタログ。
【請求項２３】
前記第１の属性ツリーに加えて、複数の属性ツリーを更に有しており、前記複数の属性ツリーのそれぞれは、関連付けられた複数の属性セットを具備可能であり、前記属性セットは、前記第１の属性レベルよりも高次の属性レベルによって識別されており、個々の属性レベル内の前記属性のそれぞれは、前記個々の属性レベルの直接下の属性レベルにおけるそれぞれの属性ごとに少なくとも２つの値を具備可能である請求項２１記載の電子カタログ。
【請求項２４】
前記第１、第２および第３属性セットは、それぞれ、少なくとも１つの属性ＩＤを有しており、前記属性ＩＤは、第２のテーブル内の別個の行に保存されており、前記属性ＩＤと関連付けられた値は、第２のテーブル内の別個の行に保存される請求項２１記載の電子カタログ。
【請求項２５】
コンピュータによって実行された際に、前記コンピュータに方法を実行させるコンピュータ可読媒体上において実施された命令のセットであって、
前記方法は、
少なくとも第１のアイテムおよび前記第１のアイテムと関連付けられた第１と第２のサブアイテムを識別するデータを第１のテーブル内に保存する段階と、
前記第１のアイテムと関連付けられた少なくとも第１と第２の属性ＩＤを第２のテーブル内に保存する段階であって、前記第１と第２の属性ＩＤは、それぞれ、前記第１のアイテムの特性を識別している段階と、
前記第１の属性ＩＤの属性値を保存する段階であって、前記属性値は、それぞれ、前記第１と第２のサブアイテムと関連付けられている段階とを含んで成る命令のセット。
【請求項２６】
前記方法は、
まず、第２のアイテムを前記第１のテーブルに追加する段階と、
次に、前記最初の追加段階に応答し、少なくとも１つの新しい属性ＩＤを前記第２のテーブルに追加する段階であって、前記新しい属性ＩＤは、前記第２のアイテムと関連付けられている段階とを更に含む請求項２５記載の命令のセット。
【請求項２７】
前記方法は、
第３のサブアイテムを前記第１のテーブルに追加する段階であって、前記第３のサブアイテムは、前記第１のアイテムと関連付けられている段階と、
前記第３のサブアイテムについて第１の新しい属性ＩＤを前記第２のテーブルに追加する段階と、
前記第１の新しい属性ＩＤと関連付けられた少なくとも１つの新しい属性値を追加する段階とを更に含む請求項２５記載の命令のセット。
【請求項２８】
前記命令は、前記コンピュータと動作可能に相互接続されたデータ通信ネットワークによって前記コンピュータに提供される請求項２５記載の命令のセット。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースシステムリポジトリ内におけるアイテムの保存、検索および編成に関するものであり、更に詳しくは、電子カタログ内におけるアイテムの複数の属性値の関係付けに関するものである。
【背景技術】
【０００２】
様々な電子商取引および購入機能をサポートすべく、サーチ可能な電子カタログが一般的に使用されている。個人または会社は、このようなカタログを使用し、そのカタログ内に提供されているいくつかのアイテムの中からアイテムを選択して購入可能である。また、カタログは、企業アプリケーションにおいても一般的に使用されており、この場合には、１または複数のアイテムカタログ、購入注文の生成および支払および費用の追跡を提供可能である共通システムに対して企業内のいくつかの異なるサイトがアクセス可能である。これらのカタログは、通常、カタログのアイテムに対応したレコードを選択的に検索および提供するインターフェイスと、選択されたアイテムを電子的に購入するシステムを具備している。
【０００３】
このようなカタログ内において識別可能な多くのアイテムは、様々な異なる構成で入手可能であり、それぞれの構成は、固有の部品番号および／または関連付けられたその他の識別機能を具備可能である。更には、様々なアイテムは、企業内の異なるサイトにおいて、いくつかの異なる供給者から、並びに／或いは、その購入量に基づいた異なる価格で入手可能であろう。例えば、特定のタイプのペンは、様々な色およびペン先で入手可能であり、衣料品は、様々なサイズ、布地および色で入手可能である。電源は、様々な入力および出力電圧、電流容量およびハウジングにおいて入手可能であろう。更には、このようなアイテムのそれぞれは、いくつかの場所の中の１つにおいて、並びに／或いは、いくつかの供給者の中の１つから、入手可能であろう。更には、様々な場所が、特定のアイテムについて様々な供給者を使用可能であり、様々な供給者は、固有の供給者部品番号および価格を具備可能である。会社内の様々な場所が１つのアイテムについて様々な法人部品番号を具備している場合や特定の供給者および／または場所が様々な通貨を使用している場合など、様々な場所および様々供給者により、結果的に、しばしば、複雑さが更に増大することになる。１つのアイテムについて、すべての部品番号、供給者、場所、価格および任意のその他の情報を、それぞれ、カタログ内において別個のアイテムとして列挙した場合には、そのカタログの生成および維持は、極めて面倒なものとなろう。更には、このようなカタログからのアイテムの検出および選択も、極めて困難なものとなろう。或いは、この代わりに、相対的に単純なカタログを提供すべく、１つのアイテムに関連付けられている様々な構成および／または場所を無視した場合には、そのアイテムに関する詳細事項および完全なアイテム情報をそのアイテムについて入手することができなくなるであろう。このような不完全な情報は、結果的に、例えば、配達時間の増大および／または費用の増大に起因し、個人、会社および／または企業にとっての非効率性をもたらすことになろう。更には、サプライチェーンを管理している企業の場合には、サプライチェーン管理における効率を向上させるべく、完全かつ正確な情報を必要としている。例えば、企業が、従来、２つの異なる供給者に対して特定の部品を発注している場合には、その部品を相対的に大きな分量で単一の供給者に発注することにすれば、ボリュームディスカウントを得ることができよう。また、多くの場合に、企業は、サプライチェーンが中断されるリスクを低減すべく、その企業の事業に必要な特定のアイテムについて単一の供給源を回避することを所望する場合がある。このような場合には、それぞれのアイテムごとに複数の供給者を有していることが望ましく、かつ、それらの供給者を識別すると共に様々な供給者間において発注を効率的に管理および配分すべく、様々な供給者に関係付けられた情報を効率的に識別および管理することが有用であろう。
【０００４】
ペンおよびシャツは、様々な利用可能な構成を有する製品の単純な例を表しており、これらの構成は、多数の異なる供給者、価格、場所において入手可能であり、かつ、様々な異なる部品番号を具備可能である。いくつかの製品領域においては、１つの特定のアイテムにおいて、数千、或いは、場合によっては、数百万の異なる可能な組合わせが存在可能である。例えば、照明器具は、様々な供給者が提供可能であり、それぞれの供給者は、器具の購入量に基づいた異なる価格を具備可能である。この器具は、様々な場所において入手可能であり、供給者および／または場所に基づいて異なる法人部品番号を具備可能であり、かつ、場所に基づいて異なる価格を具備可能である。これらの列挙された選択肢のそれぞれが２つの異なる値しかを具備していない場合にも、結果は、その特定のアイテムにおける３２個の可能な組合わせとなる。このようなアイテムは、一般的に、様々な選択肢のそれぞれについて、２つを上回る数の異なる値を具備しており、それぞれの選択肢は、一般的に、サブ選択肢と、従って、格段に更に多くの可能な組合わせを具備している。それぞれの潜在的な組合わせごとに１つずつである数千の異なるアイテムとして表現した際には、このようなアイテムをサーチし、読み込み、抽出し、かつ、電子カタログに追加することは、ほとんど不可能になろう。更には、数千の可能性にわたってサーチすれば、多大な時間の消費と混乱をユーザーに対してもたらすことになろう。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来、このようなアイテムを含む多くのカタログは、通常、「Ｉｆ，  ｔｈｅｎ」ステートメントの形態における条件付きのブランチ命令の長いシーケンスをコーディングすることにより、或いは、アイテムのいくつかの異なる属性を定義すると共に属性の外部キーによって識別された異なるテーブル内にアイテムデータを保存することにより、処理されている。このような構成は、使用可能ではあるものの、しばしば、様々な製品および／または特定の製品の場所を追加するための変更が困難である複雑なロジックシステムを結果的にもたらしている。更には、このような構成は、しばしば、異なるソフトウェアまたはアーキテクチャを使用して動作するカタログに対してデータ入力すべくプラットフォームに跨って変換するのが困難である。供給者、価格および場所などの多くのアイテムの選択肢は、一般に、相対的に頻繁なインターバルで変更されているため、更新および変換が特に重要である。特定のペンの例を再度参照すると、特定のペンについて、追加の価格および／またはサイトを任意の時点において追加可能である。前述の照明器具の場合には、利用可能なハウジングおよび仕上げの変更などの構成の変更も一般的であり、この結果、それぞれの場所におけるそのアイテムの変更が発生可能であろう。この結果、このような従来のシステムは、一般に、様々なカタログに追加されるアイテムの数が増大するのに伴って、極めて複雑なものとなる。
【課題を解決するための手段】
【０００６】
本発明は、アイテムおよびアイテムと関連付けられた属性を保存する電子カタログを提供している。属性の中の１または複数のものは、複数の値を具備可能である。アイテムは、アイテムテーブル内に保存されており、アイテムの様々な属性は、属性テーブル内の異なる行に保存されている。追加の行をアイテムテーブルに追加することにより、追加アイテムをカタログに追加可能であり、追加アイテムに関係付けられた属性は、行として属性テーブルに追加可能である。特定の属性は、複数の値を具備可能であり、このような多値属性は、アイテムと関連付けられたサブアイテムに割り当てられている。属性値についてサーチを実行可能であり、検索基準を満足しているすべてのアイテムおよびサブアイテムを通知するサーチ結果を返すことができる。
【０００７】
更に詳しくは、一実施例においては、本発明は、コンピュータのデータリポジトリ内に電子カタログを保存する方法を提供している。この方法は、（ａ）電子カタログの少なくとも第１のアイテムを識別し、かつ、第１のアイテムと関連付けられた少なくとも第１と第２のサブアイテムを識別可能であるデータを第１のテーブル内に保存する段階と、（ｂ）第１のアイテムと関連付けられた少なくとも第１と第２の属性ＩＤを第２のテーブル内に保存する段階であって、第１と第２の属性ＩＤは、それぞれ、第１のアイテムの特性を識別している段階と、（ｃ）第１の属性ＩＤについて少なくとも第１と第２の属性値を保存する段階であって、第１と第２の属性値は、それぞれ、第１と第２のサブアイテムと関連付けられている段階と、を含んでいる。一実施例においては、第１と第２の属性ＩＤは、第２のテーブル内の別個の行に保存されており、第１と第２の属性値は、第３のテーブル内の別個の行に保存されている。まず、第２のアイテムを識別する新しい行を第１のテーブルに追加し、次いで、第２のアイテムと関連付けられた第１の新しい属性ＩＤを識別する少なくとも１つの新しい行を第２のテーブルに追加することにより、追加のアイテムをカタログに追加可能である。第１のアイテムと関連付けられた第３のサブアイテムを識別する新しい行をテーブルに追加し、かつ、第３のサブアイテムの第１の新しい属性ＩＤを識別する新しい行を第２のテーブルに追加することにより、アイテムについて追加のサブアイテムを追加可能である。
【０００８】
電子カタログは、一実施例においては、アイテムを識別する第１の列と、第１の列内において識別されているアイテムと関連付けられたサブアイテムを識別する第２の列を具備した第１のテーブルと、アイテムを識別する第１の列と、第１の列のアイテムと関連付けられたサブアイテムを識別する第２の列と、第１の列のアイテムおよび第２の列のサブアイテムと関連付けられた属性ＩＤを識別する第３の列を具備した第２のテーブルと、属性を識別する第１の列と、ストリング値を識別する第２の列と、数値を識別する第３の列を具備した第３のテーブルを有している。また、第３のテーブルは、言語を識別する第４の列をも包含可能である。また、電子カタログは、メタデータを保存するテーブルをも包含可能であり、メタデータは、アイテムとサブアイテムの間の関係を識別する少なくとも１つの属性ツリーを定義している。メタデータは、それぞれのサブアイテムについて、サブアイテムの属性ツリーと、その属性ツリー内のレベルを識別している。一実施例においては、メタデータは、少なくとも１つの属性をキー属性として更に識別している。
【０００９】
本発明の別の実施例は、電子カタログを保存すべく動作可能であるサーバーを有する演算システムを提供しており、前述の電子カタログは、（ａ）少なくとも第１のアイテムと、第１のアイテムと関連付けられた少なくとも第１と第２のサブアイテムを保存する第１のテーブルと、（ｂ）第１のアイテムと関連付けられた少なくとも１つの第１の属性ＩＤを保存する第２のテーブルであって、第１の属性ＩＤは、第１のアイテムの特性を識別している、第２のテーブルと、（ｃ）第１の属性ＩＤの少なくとも第１と第２の属性値を保存する第３のテーブルであって、第１と第２の属性値は、それぞれ、第１と第２のサブアイテムと関連付けられている、第３のテーブルと、を有している。この演算システムは、一実施例においては、ユーザーからサーチ要求を受信し、このサーチ要求に応答して、第１のアイテムと、第１のアイテムと関連付けられた属性値を返すべく更に動作可能である。サーバーは、少なくとも第１の属性ＩＤおよび第１の属性値を識別する第２サーチ要求をユーザーから受信可能であり、かつ、これに応答し、第１の属性ＩＤおよび第１の属性値に等価である関連付けられた属性値を具備したアイテムについて電子カタログをサーチしている。
【発明を実施するための最良の形態】
【００１０】
以下、本発明のこれらの並びにその他の特徴について説明する。
【００１１】
本発明は、特定のアイテムのすべての関連情報を含む電子カタログ内におけるアイテムの保存が複雑なタスクとなる可能性を有していることを認識している。更には、特定の基本アイテムに関係付けられた様々な選択肢または特徴を保存することにより、この複雑性が更に増大する。例えば、特定のコンポーネントが複数の値を具備可能である場合には、従来のシステムにおいては、通常、アイテムのそれぞれの異なる潜在的な値について別個のアイテムを列挙する必要があった。このようなシステムは、大きなリソースを消費すると共に、しばしば、カタログに読み込む際に、複雑な接合および／または外部キーによって個々のカタログアイテムをカスタマイズする必要があった。本発明は、複数の値を具備可能なアイテム属性を効率的に保存すると共にアイテム属性を効率的にサーチする方法およびシステムを提供している。本発明の一実施例は、アイテムおよびアイテムと関連付けられたサブアイテムを列挙した第１のテーブルを提供している。第２のテーブルは、属性と、それらの属性に対応したアイテムおよびサブアイテムを識別している。第３のテーブルは、第２のテーブル内において識別されている属性の値を識別している。最後に、アイテムと関連付けられたメタデータが、アイテムとサブアイテムの関係を定義しており、これにより、様々な異なるサブアイテムおよびこのサブアイテムとその他のサブアイテムとの関連付けの能力を提供している。
【００１２】
図１を参照すると、本発明の一実施例のシステムのブロックダイアグラムが示されている。システム２０は、１または複数のカタログ２４、サーバー２８および１または複数のクライアント３２を含んでいる。カタログ２４およびサーバー２８は、接続３６によって接続されており、この接続は、インターネット、イントラネット、または任意のその他の適切な接続などのローカルまたはワイドエリアネットワークを含むカタログ２４およびサーバー２８を接続するための任意の適切な接続であってよい。同様に、サーバー２８およびクライアント３２も、接続４０によって接続されており、この接続も、インターネット、イントラネット、または任意のその他の適切な接続などの任意のローカルまたはワイドエリアネットワークであってよい。更には、カタログ２４、サーバー２８、クライアント３２は、別個のコンポーネントであるものとして示されているが、このようなコンポーネントは、サーバーと一緒に配置することも可能であり、サーバー内に内蔵することも可能であると共に／または、任意の接続を使用して接続することも可能である。クライアント３２は、ローカルまたはワイドエリアネットワーク４０を通じてサーバー２８に接続されたワークステーションから構成可能である。クライアント３２であるワークステーションは、サーバーにアクセスすべく使用される一般的なインターネットウェブブラウザなどのグラフィカルユーザーインターフェイスを包含可能である。また、クライアント３２は、サーバー２８によって実行される動作と関連付けられた表示をレンダリングすべくブラウザとの組合わせにおいて使用されるまたはこれとは別個に使用されるサーバー２８とワークステーションが通信するための専用のソフトウェアを包含することも可能である。調達機能は、サーバー２８および／またはカタログに対して提供される購入注文またはその他の購入通知を生成すべく使用されるサーバー２８および／またはクライアント２４によって提供可能である。
【００１３】
カタログ２４は、コンピュータのメモリストレージ装置内に保存されたデータベース内に存在することも可能であり、或いは、カタログと関連付けられたアイテムを収容する能力を有する別の適切なシステム内に保存することも可能である。ウェブブラウザおよび／またはその他のソフトウェアを通じたものなどのクライアント３２からの命令により、情報をカタログ２４から抽出し、クライアント３２に対して提供可能である。この情報は、クライアント３２において稼動しているソフトウェアによって使用可能なデータとして、並びに／或いは、ユーザーによって要求され、かつ、サーバー２８によって提供されたサーチ表示またはなんらかのその他の表示内において、提供可能である。本発明は、ＨＴＴＰ(Hyper Text Transfer Protocol)およびJava（登録商標）命令などの一般的なウェブインターフェイスを使用して通信するブラウザを使用して実装可能であるが、本発明は、特定のプラットフォームインターフェイスに依存したものではなく、本発明は、いくつかの利用可能なプラットフォームまたはインターフェイスの中のいずれかを使用して実装可能であることを理解されたい。本発明は、ウェブタイプのブラウザソフトウェア、または固有のコード、インターフェイス、表示技術によって本発明のために特別に開発されたソフトウェアを使用可能である。本発明は、単一の装置上において、或いは、ダム端末を有するメインフレームから無線ネットワーク上において通信している無線クライアントを有する無線サーバーに至る任意の種類の分散処理環境により、実装可能である。
【００１４】
カタログ２４は、製品および／またはサービスなどのアイテムの電子カタログである。一実施例においては、カタログ２４は、アイテムのカタログ内のそれぞれの製品またはサービスをその製品またはサービスと関連付けられたいくつかの異なる属性によって識別できるように、一様なカタログスキーマを使用して構築されている。アイテムと関連付けられた様々な属性は、複数の値を具備可能である。このような属性は、例えば、製品またはサービスの説明属性、製品またはサービスの供給者、製品またはサービスの企業内の場所、製品またはサービスの様々な価格、並びに／或いは、製品またはサービスのカタログ分類を包含可能である。更には、カタログ２４は、例えば、それぞれの供給者ごとの１または複数のカタログなどの複数のカタログ、或いは、複数の供給者からの製品情報の集合体をカタログ２４内に収容可能である集合的なカタログを包含可能である。一実施例においては、サーバー２８は、カタログからデータを受信し、データを編成すると共に、様々な分類および／またはデータストレージ構造を使用して同一または異なるカタログ内にデータを再保存している。別の実施例においては、サーバー２８は、いくつかの異なるカタログからデータを受信し、データを編成すると共に、様々な分類および／またはデータストレージ構造を使用して同一のまたは異なる１または複数のカタログ内にデータを再保存している。
【００１５】
一実施例のサーバー２８の更なる詳細が図２に示されている。この実施例においては、サーバー２８は、検索エンジン／アグリゲータ５０と通信していると共に１または複数の電子カタログ２４に対するアクセスを提供している１または複数のサーブレット４８を含んでいる。サーブレット４８は、１または複数の異なるデータベース内に保存可能である１または複数の電子カタログとインターフェイスするアプリケーションプログラムインターフェイス(Application Program Interface: API)を包含可能である。例えば、サーブレット４８は、ＯＲＡＣＬＥデータベースシステム上に保存された電子カタログとインターフェイスするためのＡＰＩを包含可能である。同様に、サーブレット４８は、ＳＡＰ、ＩＢＭその他の多くのデータベースプロバイダによって提供されているデータベースとインターフェイスするＡＰＩを包含可能である。検索エンジン／アグリゲータ５０は、１または複数のカタログからレコードを検索し、１または複数の電子カタログのコンテンツに基づいて別個のカタログを生成すると共に／または、単一の電子カタログの基本的なサーチをわかりやすく提供すべく動作可能である。検索エンジン／アグリゲータ５０を使用することにより、市場、購入者、販売者に対して、または企業内において公開される別個のカタログを生成可能である。更には、検索エンジン／アグリゲータ５０は、直接的な製品購入および／またはシステムの監督、管理および品質管理などのカタログレコードの任意のその他の使用法のために使用することも可能である。
【００１６】
また、本実施例のサーバー２８は、カタログキャッシュ５２をも含んでいる。カタログキャッシュ５２を使用することにより、カタログ２４のみを使用して入手可能であるサーチを上回るサーチの更なる選択肢および柔軟性を実現する方式において１または複数の電子カタログ２４からのアイテムを保存可能である。例えば、一実施例においては、検索エンジン／アグリゲータ５０は、サーブレット４８を通じて電子カタログ２４にアクセスし、電子カタログ２４内において様々なアイテムを識別している。カタログ２４からのこれらのアイテムと任意のＩＤ属性を、同一または異なる分類スキーマに配置すると共に、本発明に従ってサーチ可能である同一または異なるストレージ構造においてカタログキャッシュ５２内に保存している。同一アイテムがいくつかの異なるカタログ２４内に出現する場合には、カタログキャッシュ５２内において、そのアイテムが出現する様々なカタログを識別する属性と共に、そのアイテムを列挙可能である。一実施例においては、１つの特定の属性または複数の特定の属性をレベル０属性として選択しており、これらは、アイテムの基本ＩＤとして機能している。本明細書において使用されているレベル０属性とは、アイテムの固有の説明を提供している属性を意味している。例えば、カタログのアイテムは、テキサスインスツルメンツ(Texas Instruments)社によって製造され、かつ、製造者部品番号であるＴＩ１２３が割り当てられた演算増幅器を表す属性を具備可能である。このアイテムは、いくつかの異なる供給者から入手可能であろう。この特定のアイテムの製造者部品番号（ＴＩ１２３）は、異なる供給者間において共通であり、従って、これは、レベル０属性として選択可能である。そして、様々な供給者に関係付けられている情報をレベル１属性として選択可能であり、レベル１属性は、様々な供給者のそれぞれに対応した値を具備可能である。また、このアイテムは、特定の供給者においてそのアイテムを異なる価格および／または異なる場所において入手可能である場合などに、更なるレベルの属性を具備することも可能である。それぞれの供給者におけるこれらの属性をそのアイテムについて更に識別可能である。このような多値属性については、後程、更に詳しく説明する。
【００１７】
サーバー２８は、更なるサーブレット４４を更に含んでおり、このサーブレットは、検索エンジン／アグリゲータ５０、カタログキャッシュ５２および／またはサーブレット４８にアクセスしていると共に、１または複数のクライアント３２に接続されている。この結果、ワークステーションにアクセスしているユーザーなどのクライアント３２は、サーブレット４４にアクセスすることにより、アイテムについてのサーチを提供可能である。サーブレット４４は、検索エンジン／アグリゲータ５０にアクセスしており、この検索エンジン／アグリゲータは、１または複数のカタログ２４および／またはカタログキャッシュ５２のサーチを生成し、１または複数の結果をサーチ要求に対して提供可能である。また、サーブレット４４は、サーブレット４８にもアクセスし、かつ、これに対してサーチパラメータを提供可能であり、これらのサーチパラメータが、次いで、１または複数のカタログに伝達され、これらが１または複数の結果を返すことになる。更には、サーブレット４４、４８を使用することにより、本明細書に記述されているストレージ構造および方法の中の１または複数のものに従って電子カタログ内においてコンテンツを保存および／または変更可能である。サーブレット４４は、クライアント３２上において稼動可能な様々な異なるソフトウェアプログラムとインターフェイスするＡＰＩを包含可能である。同様に、サーブレット４８との関係において説明したように、このようなＡＰＩを使用することにより、例えば、企業ソフトウェアアプリケーション、購入調達アプリケーション、サプライチェーン管理アプリケーションなどを含む多数の異なるソフトウェアアプリケーションとインターフェイス可能である。また、例えば、磁気または光学媒体を介したものおよび／またはネットワーク接続を通じたものなどの任意の適切な方法を使用することにより、このようなサーブレット４４、４８を配布してサーバー２８上にインストールすることも可能である。この結果、必要に応じて、ＡＰＩを供給、インストールおよび更新可能である。
【００１８】
一実施例においては、検索エンジン／アグリゲータ５０は、クライアント３２からサーチ要求を受信する検索エンジンとして動作している。アプリケーションサーバー２８は、サーブレット４８を使用することにより、検索エンジン５０を通じて１または複数の電子カタログ２４および／またはカタログキャッシュ５２に対して問い合わせを実行すると共に、その結果をサーチ要求を起動したクライアント３２に対して送付している。カタログのタイプまたはフォーマットは、そのカタログがサーブレット４８および検索エンジン／アグリゲータ５０からの問い合わせに対して適切に応答する限り、任意の適切なフォーマットであってよい。例えば、カタログ２４は、リレーショナルデータベース内に存在することも可能であり、或いは、オブジェクト指向のデータベース内に存在することも可能である。一実施例においては、カタログキャッシュ５２は、１または複数のオブジェクト指向データベースおよび／またはリレーショナルデータベース内に存在する電子カタログ２４から得られたアイテムを含んでいる。電子カタログ２４および／またはカタログキャッシュ５２は、ディスクドライブ、テープドライブ、ランダムアクセスメモリ(Random Access Memory: RAM)、プログラム可能な読出専用メモリなどの読出専用メモリ、または任意のその他のコンピュータのデータストレージ装置またはこれらの組合わせを含む任意の適切なデータストレージ装置上に保存可能である。アプリケーションサーバー２８は、このストレージ装置に直接的に装着されたコンピュータ内に存在することも可能であり、或いは、この代わりに、ネットワークを通じてストレージ装置に接続することも可能である。一実施例においては、サーブレット４８、４４は、Java（登録商標） APIおよびJavascript/HTMLインターフェイス生成に基づいたものである。これらのＡＰＩは、JDBC(Java（登録商標） Database Connectivity)を使用することにより、検索エンジンを通じて、電子カタログ２４が存在可能である別個のデータストアに対して通信可能である。ＪＤＢＣプロトコルにより、検索エンジンは、例えば、オラクル社(Oracle Corp.)、マイクロソフト社(Microsoft Corp.)およびＳＡＰ社などから入手可能なものを含む様々な一般的に使用されているデータベースに基づいて１または複数のカタログ２４と通信可能である。更には、サーブレット４４は、例えば、オラクル社、マイクロソフト社、ＳＡＰ社などから入手可能なものを含む様々な一般的に使用されているソフトウェアアプリケーションに基づいてユーザーおよびクライアントと関連付けられたワークステーションに対して通信可能である。
【００１９】
特定の一実施例においては、サーブレット４４、４８は、ＳＡＰ社のＯＣＩ(Open Catalog Interface)と共に動作すべく構成されたカタログを含むＤＢＭＳ(Database Management System)と通信すべく動作可能であるＡＰＩを含んでいる。この実施例においては、サーブレット４８のＡＰＩは、ＯＣＩ呼び出しと呼ばれるＳＡＰ社のＯＣＩが必要としているように、データベース問い合わせおよびその他のデータベース命令をフォーマットしている。サーバー２８は、ＯＣＩ呼び出しのイニシエータとして動作することにより、このような呼び出しをサーバー４８において生成し、１または複数のカタログに対して伝送可能である。また、サーバー２８は、このような呼び出しに対するレスポンダとして動作することにより、サーブレット４４において呼び出しを受信し、これに対する応答を生成することも可能である。これらのＡＰＩは、問い合わせを受信し、カタログ２４の中の１または複数のものに対して伝送される命令を生成すべく動作している。このような命令は、１または複数のカタログに対して起動および伝送されたＯＣＩ呼び出しに必要なフォーマッティングを含んでいる。このようなＯＣＩ呼び出しは、特定のカタログ２４のＵＲＬ、ユーザー名／パスワードおよびコンテンツ要求などのパラメータおよびリターンＵＲＬを包含可能である。例えば、ユーザーは、サーバー２８を使用することにより、このようなＯＣＩ呼び出しに応答すべく構成されたいくつかの異なるカタログを統合することを所望可能である。クライアント３２は、要求を入力し、これが、サーブレット４４において受信され、検索エンジン／アグリゲータ５０に対して転送される。検索エンジン／アグリゲータ５０は、例えば、筆記用具などの特定のカタログ内において分類されたアイテムについてサーチングを開始すると共にサーチ要求をサーブレット４８に伝達すべく動作可能である。サーブレット４８は、このサーチ要求をＯＣＩ呼び出しにフォーマットし、この呼び出しを１または複数のカタログ２４に対して伝送する。１または複数のカタログ２４から応答を受信した際に、サーブレット４８は、サーチ結果を検索エンジン／アグリゲータ５０に対して返す。これらの結果は、カタログキャッシュ５２内に保存可能であると共に／または、サーブレット４４を通じてクライアント３２に返送可能である。様々なカタログ２４内のアイテムをカタログキャッシュ５２内に統合する必要がある場合には、その要求された統合が完了する時点まで、このような操作が継続される。同様に、別の実施例においては、サーブレット４４、４８は、クライアント３２から要求を受信し、ＯＣＩ呼び出しをフォーマットすべく動作しており、このＯＣＩ呼び出しが、１または複数のカタログに対して伝送され、１または複数のカタログから受信された結果が、クライアント３２に対して返送されている。
【００２０】
前述のように、サーバー２８は、このようなＯＣＩ呼び出しを受信すべく動作することも可能である。このような一実施例においては、サーブレット４４は、このような呼び出しを受信し、この呼び出し内の任意の要求を検索エンジン／アグリゲータ５０に対して伝達し、次いで、この検索エンジン／アグリゲータが、同様に、前述のように、その他のカタログ２４用の問い合わせを生成可能である。或いは、この代わりに、サーブレット４４は、このような呼び出しを受信し、カタログキャッシュ５２にアクセスすることにより、呼び出しに対する応答を生成することも可能である。一実施例においては、呼び出しを起動するクライアント３２上において稼動しているＳＲＭサーバーは、サーブレット４４が受信可能なＯＣＩ呼び出し内において追加パラメータを提供し、かつ、これに応答して様々な動作を実行すべく構成されている。更には、カタログ２４の中の１または複数のものおよび／またはカタログキャッシュ５２は、機能強化された効率的なアイテムおよび属性の保存を提供する方式においてアイテムおよび関係する属性を保存することも可能である。このようなアイテムは、サーチ可能な多値属性を具備可能であり、アイテム属性の中の１または複数のものは、関連付けられた複数の値を具備可能である。このようなアイテムおよび属性の保存については、後程、更に詳しく説明するものとする。ＳＲＭサーバーは、例えば、ショッピングカートアイテムを生成すると共にアイテムの購入を起動および完了させるべく、いくつかの方式の中のいずれかにより、返送された結果を使用可能である。尚、この実施例においては、カタログ２４、クライアント３２およびサーブレット４４、４８について、ＳＡＰシステムを使用してインターフェイスするものとして説明しているが、その他のデータベースシステムおよび企業管理システムを利用可能であることを理解されたい。例えば、サーバー２８は、例えば、Oracleシステムおよび／またはＩＢＭシステムとインターフェイス可能である。
【００２１】
次に図３〜図５を参照し、本発明の一実施例におけるカタログ内における複数のアイテム属性を具備した様々なアイテムの保存について説明することとする。まず、図３を参照すると、１または複数のカタログからのいくつかのアイテムを収容したテーブル６０が示されている。この例におけるアイテムは、１００Ωの抵抗器である。このようなアイテムは、いくつかの異なるカタログにおいて入手可能であり、かつ、いくつかの異なる供給者および製造者から入手可能であろう。例えば、この例においては、２つの供給者であるベンダ１およびベンダ２は、モトローラ(Motorola)社によって製造され、かつ、ＸＥ５８８９−１００Ｏｈｍという部品番号を具備すべくモトローラ社によって割り当てられた１００Ωの抵抗器を提供している。これらの２つの供給者は、このアイテムを提供してはいるが、それぞれの供給者は、通常、異なる供給者部品番号、異なる価格、このアイテムを発注するための異なる計量単位(Unit Of measure: UOM)などを具備している。特定のケースにおいては、図４に示されているように、単一のテーブル６０内に様々な異なるアイテムを表示することが望ましいであろう。このようなアイテムの表現法は、例えば、アイテムの供給者の数の低減を求めている企業にとって、或いは、アイテムの相対的に低い価格を具備した供給者からの購入を求めている企業にとって有用であろう。このような場合には、企業は、このようなアイテムがいくつかの異なる供給者から購入されていることを判定可能である。このような状況は、例えば、企業内の異なるサイトによるそのサイトに局限されたローカルな供給者の使用、異なる供給者との以前の関係、企業内の様々な要員が使用した以前のカタログに基づいた異なる供給者、以前に異なる供給者を使用していた会社の買収など、いくつかの理由から発生可能である。このような状況においては、それらの異なる供給者に発注されるアイテムの合計数は、累積すれば、結果的に、その企業によるそのアイテムの大量購入に結ぶ付く可能性あり、従って、このような大量購入に基づいて、１つの供給者との間においてボリュームディスカウントを折衝可能である。また、企業は、特定のアイテムにおける供給者の数の増加を所望する場合もある。このような状況は、例えば、単一の供給者から購入しているアイテムの供給中断のリスクの低減、サプライチェーンの効率化のための供給者ベースの多様化および特定のサイトに局限された供給者からのアイテムの購入など、様々な理由から発生可能である。
【００２２】
アイテムは、複数の異なる属性によって表現されており、属性の１または複数のものも、複数の異なる値を具備可能である。例えば、このようなアイテムと関連付けられた属性は、説明、製造者名、製造者部品番号、供給者名、供給者部品番号および公差を包含可能である。この例においては、３つの異なる製造者、即ち、示されているように、モトローラ社、Ｔｙｃｏ社およびＡＭＤ社が１００Ωの抵抗器を供給している。製造者のそれぞれは、「製造者部品番号」というヘッダが付与された列に属性として列挙されているアイテムの製造者部品番号を具備している。更には、この例においては、いくつかの異なる供給者がアイテムを供給しており、この例の２つのケースにおいては、複数のベンダが同一のアイテムを供給している。例えば、ベンダ１およびベンダ２の両方が、モトローラ社の１００Ω抵抗器を提供している。従って、「供給者名」というヘッダが付与された列には、これらのベンダが列挙されている。これは、単一の属性、即ち、「供給者名」を提供しており、これは、２つの異なる値を具備している。同様に、ベンダ１およびベンダ３の両方も、ＡＭＤ社のアイテムを供給しており、従って、このアイテムの供給者名という属性は、ベンダ１およびベンダ３という両方の値を具備している。従来から、複数の属性値を単一の説明属性として具備するアイテムの保存およびサーチおよび検索は、相対的に複雑なタスクであった。例えば、カタログは、カタログデータベース内の単一の行としてアイテムを包含可能である。データベースは、多数の異なるアイテムを含むテーブルを含んでおり、特定のアイテムは、テーブル内の単一の行を占有し、テーブルの様々な列は、アイテムの属性を含んでいる。アイテムが複数の値を具備可能な属性を具備している場合には、そのような状況を説明すべく、複雑なリンクテーブルおよび／または複雑なリンク属性を具備した追加の列を提供しなければならない。
【００２３】
更には、この複雑性に加えて、企業または法人は、しばしば、様々なアイテムについて法人部品番号を提供している。このような例が図４に示されている。図４においては、テーブル８０は、別個の列に列挙された追加の「法人部品番号」属性と共に、１００Ωの抵抗器に対応した様々なアイテムを示している。この例においては、１００Ωの抵抗器に対応するモトローラ社のアイテムは、図４の「法人部品番号」に示されている２つの異なる法人部品番号に対して割り当てられている。従って、このアイテムの単一の属性である法人部品番号は、２つの異なる値を具備している。本発明は、複雑な追加のリンクや外部キー、或いは、テーブルの別の列に記述された属性に対応した複数の列の特定のテーブルに対する追加を必要としないこのような複数の値を具備した属性を異なるデータベーステーブル内に保存するシステムおよび方法を提供している。本発明の一実施例においては、特定のアイテムの１または複数の属性は、レベル０属性となるように選択されており、このような属性は、単一の値のみを具備可能である。この例においては、製造者名および製造者部品番号属性は、レベル０属性である。製造者名および製造者部品番号属性は、この特定のアイテムを一意に表しているため、これらの属性は、単一の値に制限されている。即ち、アイテムに対して割り当て可能である異なる様々な説明、法人部品番号および供給者部品番号とは無関係に、製造者名および部品番号は変化しないのである。
【００２４】
レベル０属性となるように選択される特定の属性は、カタログ内に保存される特定のアイテムに依存している。例えば、いくつかの異なる製造者によって製造され、かつ、製造者とは無関係に自由に相互交換されるアイテムは、レベル０属性として選択される１または複数の異なる属性を具備可能である。このようなアイテムは、例えば、ペーパークリップであってよく、この場合に、このアイテムのユーザーは、ペーパークリップの特定の供給源または製造者に関する嗜好を具備してはいない。この場合には、サイズおよび材料などのペーパークリップを表す属性をレベル０属性として選択可能であり、製造者名および製造者部品番号は、複数の値を具備可能なレベル１（または、更に高次の）属性として選択可能である。レベル０属性として使用される属性の選択は、そのカタログが使用されるアプリケーションに基づいている。一実施例においては、システム管理者は、カタログ内のアイテムをレビューし、レベル０となる属性およびレベル１（または、更に高次の）属性となる属性、並びに、異なる属性間の関係を識別可能である。一実施例においては、関係付けられた属性を、特定のツリー内の属性のすべてがカタログ内のアイテムの異なる供給者に関係付けられている供給者属性ツリーなどのアイテム用の属性ツリー内に配置している。属性の選択および関係と、アイテム用の様々な属性ツリーについては、後程、詳細に説明することとする。
【００２５】
前述のように、レベル１または更に高次のレベルとして指定されたその他の属性は、複数の値を具備可能である。例えば、図３、４においては、供給者名および供給者部品番号は、複数の値を具備可能であり、従って、これらは、多値属性である。従って、製造者名および製造者部品番号によって識別されたそれぞれの一意の部品ごとに、その特定のアイテムを供給可能である複数の異なる供給者を、そのアイテムと関連付け可能であり、かつ、そのアイテムの単一の属性とも関連付け可能である。更には、価格などの追加の供給者固有の情報を包含することも可能であり、この供給者固有の情報は、複数の異なる値を具備可能な属性に対して割り当てられている。更には、法人部品番号も、製造者によって提供される特定のアイテムと関連付けられた複数の異なる値を具備可能である。この結果、１つの法人部品番号属性を使用することにより、いくつかの一意の製造アイテムをリンクさせることが可能となる。この例においては、法人部品番号ＲＥＳ−１００は、２つの異なる一意の製造アイテム、即ち、モトローラ社およびＴｙｃｏ社から供給されている１００Ωの抵抗器に対応している。従って、法人部品番号ＲＥＳ−１００が要求された際には、モトローラ社およびＴｙｃｏ社の両方から提供されているこれらの一意のアイテムを提供可能である。更には、特定のアイテムは、様々な使用法に応じて、複数の法人部品番号を具備可能である。例えば、法人部品番号ＲＥＳ−１００は、その部品の製造者とは無関係に、１０％以下の公差を具備した１００オームの抵抗器と関連付け可能である。この例においては、Ｔｙｃｏ社およびモトローラ社の抵抗器は、このような要件を満足しているが、ＡＭＤ社の抵抗器は満足していない。従って、モトローラ社およびＴｙｃｏ社の抵抗器には、ＲＥＳ−１００という法人部品番号が割り当てられているが、ＡＭＤ社の製品には、割り当てられていない。その他の状況においては、企業は、単純に、特定のアイテムについて重複した法人部品番号を具備可能である。例えば、企業は、モトローラ社のアイテムを使用しており、異なる法人部品番号をそのアイテムに割り当てている２つの異なる部門を具備可能である。この例においては、モトローラ社のアイテムは、ＲＥＳ−１００およびＲＥＳ−１３１という法人部品番号に対応している。このような状況は、例えば、企業内の異なる部門または場所が、その他の部門または場所とは無関係に部品番号を割り当てている場合に発生可能である。また、このような状況は、例えば、合併や買収の結果としても発生可能である。一実施例においては、本発明は、このような発生を識別すると共に、企業内において一意のアイテムに複数の部品番号が割り当てられている状況に対してフラグを付加すべく動作可能である。システム管理者またはその他のユーザーは、例えば、このようなアイテムの購買効率を向上させるべく、このような重複部品番号を除去するための行動を実行可能である。
【００２６】
更には、単一の供給者が、複数の場所において入手可能なアイテムを具備可能であるその他の例も存在している。このような状況においては、単一の属性、即ち、場所が、複数の異なる値を具備可能である。従って、いくつかのケースにおいては、複数の供給者が、特定のアイテムを提供可能であり、これらの供給者の中の１または複数のものが、複数の場所において入手可能なアイテムを具備可能である。更には、同様に、前述のように、アイテムも、複数の法人部品番号を具備可能である。このようなアイテムは、２つの属性ツリーを具備していると見なすことができる。第１の属性ツリーは、法人部品番号情報を含んでおり、第２属性ツリーは、供給者情報を含んでいる。第２属性ツリーは、特定の供給者用の第１レベルと、その供給者が、入手可能なアイテムを具備している場所用の第２レベルという２つのレベルを更に具備することになろう。このようなアイテムの一例が図５〜図６に示されている。この例におけるアイテムは、Ａｃｍｅ社によって製造されている３／８インチのボールバルブである。このアイテムは、これに割り当てられた２つの異なる法人部品番号を具備しており（第１の属性ツリー）、このアイテムは、２つの異なる供給者から２つの異なる場所において供給されている（２つのレベルを有する第２属性ツリー）。図５は、このアイテムを、異なる供給者およびこのアイテムをテーブル８０内のそれぞれの供給者から入手可能である異なる場所と共に示している。図６は、このアイテムを、テーブル９０内のこのアイテムと関連付けられた異なる法人部品番号と共に示している。
【００２７】
本発明は、いくつかの属性を具備したアイテムの保存、サーチおよび検索を提供しており、属性の１または複数のものは、複数の値を具備している。このようなアイテム、関連付けられた属性および属性値は、一実施例においては、複数のテーブル内に保存されており、これらのテーブルのそれぞれは、いくつかの列および行を具備しており、アイテムの様々な属性は、テーブルの単一の列に保存されており、これらの属性の値は、テーブルの単一の列に保存されている。これらのアイテムは、属性ツリーを具備可能であり、異なるツリーは、アイテムの異なる情報を表している。アイテム、アイテム属性およびアイテム属性を関連付け可能である異なる属性ツリーの間における関係は、そのアイテムのメタデータによって定義されている。一例として、図５、６のアイテムを参照し、一実施例におけるこのような属性の保存について説明しよう。アイテム、属性および属性値が図７の３つの異なるテーブル内に示されている。テーブル１は、アイテムＩＤの列、サブアイテムＩＤの列およびツリーの列という３つの列を含んでいる。アイテムＩＤの列は、アイテムの一意のＩＤを含んでいる。この例においては、アイテムは、アイテム１として識別されている。アイテム１は、この例においては、５つの異なるサブアイテムを含んでいる。ツリーの列は、特定のサブアイテムが関連付けられている属性ツリーを識別している。この例においては、サブアイテム１およびサブアイテム２は、法人部品番号ツリーと関連付けられており、サブアイテム３〜サブアイテム５は、供給者情報ツリーと関連付けられている。
【００２８】
更に図７を参照すると、テーブル２は、アイテムおよび関連付けられた属性ＩＤ、並びに、属性値の保存を示している。この例においては、第１の列であるアイテムＩＤは、この例においては、アイテムＩＤであるアイテム１を含んでいる。第２の列であるサブアイテムＩＤは、様々なサブアイテムのサブアイテムＩＤを含んでいる。第３の列である属性は、このアイテムと関連付けられた様々な属性の属性ＩＤを含んでいる。第４の列であるストリング値は、文字のストリングである属性値を含んでいる。最後に、第５列である数値は、数値である属性値を含んでいる。属性が数値を具備していない場合には、その属性の数値の列は空となる。いくつかのケースにおいては、属性は、ストリング値および数値の両方を具備可能であり、この場合には、ストリング値および数値の両方の列が値を具備することになる。図７の例において、価格属性は、数値およびストリング値の両方を具備している。この場合には、ストリング値の列の属性値は、通貨の単位であり、数値の列の属性値は、その価格と関連付けられた数値である。従って、サブアイテム３は、１０９．９９米国ドルの価格を有しており、サブアイテム４は、１００ユーロの価格を具備している。図７の例における属性ツリーの関係は、テーブル３に示されている。テーブル３は、様々な属性が属するツリーを示すツリーという第１の列を含んでいる。第２の列であるレベルは、それらの属性のレベルを示しており、第３の列である属性は、属性を識別している。この例においては、法人部品番号ツリーは、２つのレベル１属性、即ち、法人部品番号および法人部品番号の説明を具備している。供給者情報ツリーは、２つのレベル１属性と２つのレベル２属性を含んでいる。この結果、このアイテムに対する属性の関係が確立されている。また、テーブル３は、特定の属性がキー属性であるのかどうかを示す「キーであるか」という第４の列をも含んでいる。
【００２９】
図７に示されているように、アイテムは、異なる属性ツリー内に配置されたいくつかの異なるサブアイテムを具備可能である。属性ツリーのそれぞれは、その他の属性ツリーとは独立しているが、いくつかの実施例においては、１つの属性ツリーに含まれている属性をそのアイテムの別の属性ツリー内に包含することも可能である。例えば、アイテムの法人部品番号ツリーは、その法人部品番号によって表されている部品の１または複数の供給者を識別する対応した値を具備した供給者名を表す属性を包含可能である。法人部品番号ツリーとは別個の供給者情報属性ツリーも、供給者名を表す属性を包含可能である。供給者名属性は、これらの例示用の属性ツリーのそれぞれのものに含まれているが、これらの異なる属性ツリーは、互いに独立しており、通常は、その特定の属性ツリーに関係した情報を含んでいる。更には、個々のアイテムは、組織、或いは、場合によっては、特定のユーザーにとって有用であるアイテムに関係付けられた情報の異なるグループに対応した任意の数の異なる属性ツリーを具備することも可能である。従って、属性ツリー内のアイテムに関係付けられた情報を保存すべく記述されているデータ構造は、１つの次元がそれぞれの属性ツリー用のものである複数の異なる次元において情報を保存しているものと考えることができる。アイテムに対応した属性の異なる個々の組合わせの数は、相対的に大きな数になる可能性があり、これは、それぞれの属性ツリーのエンドポイントの数の積として演算可能であることが理解されよう。３／８インチのボールバルブの例を参照すると、２つの属性ツリーが存在している。法人部品番号属性ツリーは、２つのエンドポイント、即ち、このアイテムと関連付けられた異なる法人部品番号を具備している。供給者情報属性ツリーは、３つのエンドポイントを具備しており、即ち、２つの供給者であって、この中の１つの供給者が、２つの異なる場所において入手可能なアイテムを具備している。従って、このアイテムを表す属性の可能な組合わせの合計数は６つである。具体的には、それぞれの法人部品番号ごとに、供給者／場所の３つの可能な組合わせが存在している。多くの場合に、アイテムは、部品の物理的な属性を表す属性ツリーなどの追加の属性ツリーを具備可能である。３／８インチのボールバルブの例においては、このアイテムは、真鍮から製造されたものであってよく、かつ、ネジが切られたエンド金具を具備可能である。このような場合には、アイテムは、異なる物理的属性を含む属性ツリーを具備可能である。追加属性ツリー内のいずれかの属性が複数の値を具備している場合には、属性の可能な組合わせの数に１または複数の追加属性ツリーのエンドポイントの数を乗算することになろう。
【００３０】
図７には、３つの異なるテーブルにおいて示されているが、様々なアイテムに関係付けられた情報を保存すべく使用される構造は、多数の異なる形態をとることが可能であることを理解されたい。例えば、アイテムに関係付けられている情報を３つのテーブルに包含するのではなく、アイテムと関連付けられた情報の異なる部分を含む更なるまたは少ない数のテーブルを利用可能である。この保存構造の選択は、アイテムに対して実行されると想定されるサーチ、要求されると予想されるビューおよび様々なテーブルの連結または特定フォーマットにおけるアイテムおよび属性の表示を必要としている異なるビューにおいて提供を要する情報などのいくつかの要因に依存している。更には、アイテムの様々な異なる属性を表すデータは、本明細書に提供されているいくつかの例においては、テーブル内に保存されるものとして説明されているが、このようなテーブルは、概念的なものであり、かつ、例えば、正規化などの一般的なデータベース設計法によって実現可能である別の物理的な実装を具備可能であることを理解されたい。本明細書に記述されている概念は、その他の等価な物理的実装を具備可能である様々なその他の実施例において実施可能であると考えられる。
【００３１】
本発明の一実施例においては、アイテムおよびサブアイテム、属性ＩＤ、属性値およびメタデータは、それぞれ、別個のテーブルに保存されている。次に図８を参照すると、この実施例における様々なテーブル内における様々なアイテムの保存が示されている。これらのテーブルは、特定のアイテムおよびアイテムと関連付け可能な様々なサブアイテムと関連付けられた行を含んでいる。この実施例においては、サブアイテムは、特定の属性について複数の値を具備するアイテムであってよい。更には、異なるサブアイテムは、関連付けられた複数の値を具備可能である異なる属性を更に具備可能である。従って、アイテムは、サブアイテムを具備可能であり、このサブアイテムも、更に複数のサブアイテムを具備可能であり、これ以降についても同様である。一実施例においては、アイテムは、レベル０属性と呼ばれる１または複数の属性を具備しており、これらのレベル０属性は、その属性と関連付けられた単一の値のみを具備している。サブアイテムは、レベル１属性である属性を具備しており、その属性と関連付けられた複数の値を具備可能である。更には、アイテムは、レベル１属性と呼ばれるいくつかの属性を具備することも可能であり、従って、アイテムのいくつかの異なる属性は、複数の値を具備可能である。図５、６の例においては、法人部品番号およびベンダ名属性は、両方とも、レベル１属性であり、場所は、供給者情報ツリー内においてレベル２属性であった。再度図８を参照すると、複雑な外部キーまたはテーブルに対する列の追加という要件を伴うことなしに、複数の異なる値を具備可能な複数の属性を具備する能力を提供すべく、アイテムおよび属性が、４つの異なるテーブル内に保存されている。これらのテーブルは、アイテム用の第１の列、サブアイテム用の第２の列および属性ツリー用の第３の列という３つの列を具備したテーブル１を含んでいる。図８に示されている例においては、第１のアイテムであるアイテム１は、それぞれ、サブアイテムの列に「サブアイテム番号１〜５」として列挙されている関連した５つのサブアイテムを具備している。アイテムおよび関連付けられたサブアイテムを示すテーブルに追加の列を単純に追加することにより、追加のアイテムをテーブルに追加可能である。図５、６の例において継続すれば、アイテム１は、ＡＣＭＥ社の３／８インチのボールバルブに対応しており、サブアイテム１および２は、このアイテムと関連付けられた異なる法人部品番号属性に対応している。サブアイテム３〜５は、このアイテムと関連付けられた異なる供給者および場所属性に対応している。異なるアイテムおよびサブアイテムと関連付けられた対応する属性および属性値が、テーブル２およびテーブル３に列挙されており、アイテムおよびサブアイテム間の関係を定義しているメタデータが、テーブル４に含まれている。
【００３２】
次に図８のテーブル２を参照すると、このテーブルは、アイテム列、サブアイテム列、属性ＩＤ列および属性名列という４つの列を含んでいる。それぞれのアイテムは、関連付けられたいくつかの異なる属性ＩＤを具備可能である。更には、それぞれのサブアイテムも、関連付けられた１または複数の属性ＩＤを具備可能である。この例においては、第１のアイテムであるアイテム１は、１９個の属性ＩＤ、即ち、属性ＩＤ番号１〜１９を具備している。属性ＩＤ番号１〜３は、アイテム１と関連付けられた特定のサブアイテムと関連付けられてはおらず、従って、これらの属性ＩＤのサブアイテム列は空になっている。属性ＩＤ番号４〜１９は、サブアイテム列に示されているように、関連付けられたサブアイテムを具備している。この例においては、「属性ＩＤ番号１」は、製造者の説明であり、属性ＩＤ番号２は、製造者名であり、属性ＩＤ番号３は、製造者部品番号である。これらの属性のそれぞれは、特定の製造者によって提供される装置と関連付けられていることから、これらは、関連付けられた複数の値を具備してはおらず、従って、これらは、レベル０属性と関連付けられており、これが、これらの属性と関連付けられたサブアイテムの欠如によって示されている。アイテム１と関連付けられているサブアイテム１は、関連付けられた２つの属性ＩＤ、即ち、属性ＩＤ番号４および５を具備している。この例においては、属性ＩＤ番号４は、法人部品番号であり、属性ＩＤ番号５は、法人部品番号の説明である。アイテム１のサブアイテム２も、関連付けられた２つの属性ＩＤ、即ち、属性ＩＤ番号６および７を具備しており、これらは、第２サブアイテムの法人部品番号および法人部品番号の説明に対応している。サブアイテム３〜５は、それぞれ、関連付けられた４つの属性ＩＤを具備しており、それぞれのサブアイテムは、供給者名、供給者部品番号、場所および価格の属性ＩＤを具備している。
【００３３】
次に図８のテーブル３を参照すると、このテーブルには属性値が保存されている。テーブル３は、属性ＩＤの列、ストリング値の列、数値の列および言語値の列という４つの列を含んでいる。これらの列のそれぞれは、属性ＩＤと関連付けられた値を包含可能である。従って、それぞれの属性ＩＤは、テーブル３に保存されている値を具備している。特定の属性の値は、ストリング値、数値および言語値の中の１または複数のものであってよい。再度図５および６の例を参照すると、テーブル１および２との関連において前述したように、アイテム１は、ＡＣＭＥ社の３／８インチのボールバルブと関連付けられており、かつ、関連付けられたサブアイテム１〜５を具備すると共に、関連付けられた属性ＩＤ番号１〜１９をも具備している。テーブル３に示されているように、属性ＩＤ番号１は、「ボールバルブ３／８インチ」というストリング値を具備しており、属性ＩＤ番号２は、製造者名に対応した「ＡＣＭＥ」というストリング値を具備しており、属性ＩＤ番号３は、製造者部品番号に対応した「６９２８５００」というストリング値を具備している。これらの属性の場合には、これらの特定の属性が、関連付けられた数値を具備していないことから、数値の列は空になっている。尚、属性ＩＤ番号３は、製造者部品番号であり、かつ、数字を含んではいるが、サーチを部品番号に基づいて実行する場合には、部品番号は、通常、数値ではない文字を含んでいることから、一様なサーチを提供すべく、この実施例においては、この属性値を依然としてストリング値の列に配置している。最後に、これらの属性の言語属性は、米国英語である。特定の属性の言語は、いくつかの異なる言語の中のいずれかであってよく、この言語が言語属性の列に記録されていることを理解されたい。更には、特定のアイテムが、複数の言語である属性を具備している場合には、複数の言語を具備したその特定の１または複数の属性について、それぞれの言語用に１つの値である複数の値を提供すべく、それらの属性を、属性ツリーと、そのツリー内のレベルに対して割り当て可能である。属性ＩＤ番号４〜１９は、図５、６の様々なアイテムおよびサブアイテムと関連付けられたテーブル２との関係において前述した属性名に対応している。
【００３４】
最後に、テーブル４を参照すると、属性ツリーのそれぞれのものと関連付けられたメタデータが列挙されている。この例においては、法人部品番号属性ツリーは、２つの属性を具備しており、これらはいずれもレベル１属性である。供給者情報属性ツリーは、４つの属性を具備しており、この中の２つは、レベル１属性であり、残りの２つは、レベル２属性である。属性のそれぞれのものと関連付けられた属性ＩＤは、属性ＩＤ列１６８に列挙されている。
【００３５】
次に図９を参照すると、別の実施例の様々なテーブル内における様々なアイテムの保存が示されている。Ａｃｍｅ社によって製造された３／８インチのボールバルブの例において継続すれば、この実施例は、複数の属性値を保存すべく使用可能であり、かつ、従って、異なる属性値の重複エントリを低減すべく使用可能である属性値ＩＤを含んでいる。これらのテーブルは、同様に、前述のように、アイテムおよびアイテムと関連付け可能である様々なサブアイテムと関連付けられた行を含んでいる。同様に、前述のように、サブアイテムは、特定の属性の複数の値を具備可能であり、異なるサブアイテムは、関連付けられた複数の値を具備可能である異なる属性を更に具備可能であり、従って、この結果、アイテムは、サブアイテムを具備可能であり、このサブアイテムも、複数の追加のサブアイテムを具備可能であり、これ以降についても同様である。図９の実施例においては、アイテムおよび属性は、４つの異なるテーブルに保存されている。これらのテーブルは、３つの列を具備すると共に、図８の実施例において説明したテーブル１に類似しているテーブル１を含んでいる。具体的には、テーブル１は、アイテム用の第１の列、サブアイテム用の第２の列および属性ツリー用の第３の列を含んでいる。前述のように、第１のアイテムであるアイテム１は、関連付けられた５つのサブアイテムを具備している。
【００３６】
次にテーブル２を参照すると、このテーブルは、アイテムの列、サブアイテムの列、属性値ＩＤの列および属性名の列という４つの列を含んでいる。それぞれのアイテムは、関連付けられたいくつかの異なる属性ＩＤ値を具備可能である。更には、それぞれのサブアイテムは、関連付けられた１または複数の属性値ＩＤを具備可能である。この例においては、第１のアイテムであるアイテム１は、１６個の属性値ＩＤ、即ち、属性値ＩＤ番号１〜１６を具備している。属性値ＩＤ番号１〜３は、アイテム１と関連付けられた特定のサブアイテムと関連付けられてはおらず、従って、これらの属性値ＩＤ用のサブアイテム列は、空になっている。また、これは、これらの属性がレベル０属性であることをも示している。属性値ＩＤ４〜１６は、サブアイテム列に示されているように、関連付けられたサブアイテムを具備している。この例においては、属性値ＩＤ番号１は、製造者の説明であり、属性値ＩＤ番号２は、製造者名であり、属性値ＩＤ番号３は、製造者部品番号である。アイテム１と関連付けられたサブアイテム１は、関連付けられた２つの属性値ＩＤ、即ち、属性値ＩＤ番号４および５を具備している。この例においては、属性値ＩＤ番号４は、法人部品番号であり、属性値ＩＤ番号５は、法人部品番号の説明である。また、アイテム１のサブアイテム２も、関連付けられた２つの属性値ＩＤ、即ち、属性値ＩＤ番号６および７を具備しており、これらは、第２サブアイテムの法人部品番号および法人部品番号の説明に対応している。サブアイテム３〜５は、それぞれ、関連付けられた４つの属性値ＩＤを具備しており、それぞれのサブアイテムは、供給者名、供給者部品番号、場所および価格という属性値ＩＤを具備している。この実施例においては、属性値ＩＤ８、９および１２は、サブアイテムの３つものについて複製されており、これらのサブアイテムのそれぞれが、複製である属性値を具備していることを示している。これらの特定の属性値は、この例においては、供給者であるGLOVAL VALVE、GLOVAL VALVEの供給者部品番号である８１２５４３およびベルリンという所在地に対応している。これらの特定の属性は、同一値を具備しているため、属性値テーブルであるテーブル３の重複行を回避可能である。
【００３７】
次に図９のテーブル３を参照すると、このテーブルには属性値が保存されている。テーブル３は、４つの列、即ち、属性値ＩＤを含む属性値ＩＤの列、属性値ＩＤと関連付けられたストリング値を含むストリング値の列、属性値ＩＤと関連付けられた数値属性を含む数値属性の列および属性値ＩＤと関連付けられた言語値を含む言語の列を含んでいる。従って、それぞれの属性値ＩＤは、テーブル３に保存されている値を具備している。図９のテーブル３に保存されている属性値は、図８のテーブル３に保存されている属性値に類似しているが、重複値を具備した属性が除去されている。この例において、図８のテーブル３は、同一値を具備した３つの属性を含んでいた。即ち、属性ＩＤ番号８および１２は、いずれも、「Global Valve」という属性値に対応しており、属性ＩＤ番号９および１３は、いずれも、「８１２５４３」という属性値に対応しており、属性ＩＤ番号１４および１８は、いずれも、「ベルリン」という属性値に対応していた。図９の実施例においては、これらの属性値は、単一の属性値ＩＤに保存されており、この属性値ＩＤがテーブル２内において複製されている。従って、テーブル３に保存される属性値の数を低減可能である。カタログが、重複した属性値を具備する多数の異なるアイテムを含んでいる場合には、このような実施例は、様々なテーブルを保存するためのデータベースにおける大きなストレージの節約を結果的に実現可能である。
【００３８】
最後に、図９のテーブル４を参照すると、属性ツリーのそれぞれのものと関連付けられたメタデータが列挙されている。この例においては、法人部品番号属性ツリーは、２つの属性を具備しており、これらは、レベル１属性である。供給者情報属性ツリーは、４つの属性を具備しており、この中の２つは、レベル１属性であり、残りの２つは、レベル２属性である。属性名の列には、属性のそれぞれものと関連付けられた属性名が列挙されている。
【００３９】
以上、カタログのアイテムに関係付けられた情報の保存について、いくつかの異なる実施例との関係において説明したが、このような情報を保存すべく、多数のその他の選択肢が存在していることを理解されたい。例えば、図８、９の実施例においては、別個の属性ＩＤを具備するものとしていくつかの属性が列挙されており、これらの属性は、特定のアイテムおよびサブアイテムにおける同一の情報を表していた。このような一例が、属性ＩＤ番号１１、１５および１９であり、これらのそれぞれは、そのアイテムの価格を表していた。このような属性の説明を別個のテーブル内に保存し、属性ＩＤまたは属性値ＩＤが、属性名がそのような別個のテーブル内に保存されていることを示す対応した情報を具備することも可能であると考えられる。この結果、同一ＩＤが多数回にわたってテーブル内に配置されないことから、そのテーブルを保存するのに必要な物理的ストレージの量が低減されることになる。
【００４０】
前述のアイテムのストレージを利用するカタログは、様々な多数のアプリケーションにおいて使用可能である。以下、本発明の一実施例におけるこのようなカタログ内におけるアイテムのサーチについて説明することとする。サーチを実行した際には、サーチの結果が、ユーザーに表示されるか、或いは、さもなければ、クライアントが使用可能であるフォーマットにおいてクライアントに提供されることになる。表示される属性および属性値は、そのアイテムについて定義されている属性ツリーのいずれかと関連付けられた属性であってよい。一実施例においては、メタデータ内に列挙された第１の属性ツリーと関連付けられた既定の属性ツリーを表示し、ユーザーが閲覧対象の別の属性ツリーを選択するためのドロップダウンボックスを提供可能である。この結果、ユーザーは、自身が関心のある属性のみを閲覧可能である。一実施例においては、ユーザーが最も頻繁に閲覧する属性ツリーを既定の属性ツリーに設定しており、別の属性ツリーを選択すべく、ドロップダウンボックスがユーザーに提供されている。一実施例においては、様々な属性ツリーの表示は、図３〜図６に示されているものに類似したテーブルフォーマットにおけるものである。
【００４１】
一実施例においては、選択されたアイテムと等価な１または複数の属性を具備したアイテムについて、電子カタログをサーチ可能である。このようなサーチは、いくつかの使用法を具備可能である。例えば、設計に包含することを所望している特定の部品が容易に入手可能ではないことを設計者が見出す場合がある。設計者は、その所望の部品に機能的に等価であり、かつ、相対的に容易に入手可能である部品を見出すことを所望するであろう。このようなサーチの別の使用法は、大量生産活動における一時的な交換部品用のものであろう。このような活動は、装置の１つが特定のコンポーネントの障害の影響を受けた結果、稼動不能となる場合がある。このような活動の中断は、大きな収入の損失を結果的にもたらす可能性があり、従って、可能な限り早期に、装置を再度回復させて稼動させるのが有益である。交換部品が容易に入手可能ではない場合には、等価な部品をサーチ可能であり、等価な部品が入手可能である場合には、それを使用し、その装置を再度回復させることができる。このようなサーチの更なる別の使用法は、会社または企業内において使用している部品数の低減を所望する会社または企業用のものである。このような部品の低減は、例えば、在庫量の低減、結果的にボリュームディスカウントに結び付く可能性のある残りの部品の購入量の増大、設計の標準化などのいくつかの利益を具備可能である。
【００４２】
次に図１０を参照すると、本発明の一実施例における等価性サーチ動作の段階が示されている。まず、ブロック１００に示されているように、部品番号をサーチインターフェイスに入力している。特定の設計における使用が望ましい特定のアイテムの部品番号を設計者が入力するなど、ユーザーは、いくつかの方法の中のいずれかによって部品番号を選択可能である。例えば、図３、４の例を再度参照すると、設計者は、モトローラ社の１００Ωの抵抗器の製造者部品番号を入力可能である。ブロック１０４に示されているように、電子カタログのサーチを実行し、その部品番号と関連付けられている最初のアイテムを検索している。モトローラ社の１００Ωの抵抗器の例においては、この抵抗器と関連付けられている属性を検索し、図１１に示されているように、これをユーザーに対して表示している。或いは、この代わりに、ユーザーは、部品番号を含まないその他の基準に基づいてサーチを実施し、サーチ結果の組の中に表示されているアイテムを選択することも可能ある。
【００４３】
前述のように、特定のアイテムは、関連付けられたいくつかの異なる属性ツリーを具備可能であり、特定のサーチの結果として表示される属性は、ユーザーの要件に基づいて判定可能である。一実施例においては、物理的なアイテム特性、アイテムの供給者およびアイテムの法人情報と関連付けられた属性ツリーが存在している。表示すべく選択される属性は、ユーザーに基づいて異なるものであってよい。例えば、等価な部品をサーチする技術者は、アイテムと関係付けられた供給者または法人情報に関心を有していない可能性があり、部品の材料や特定の電気定格などの物理的なアイテム特性にのみ関心を有している。或いは、この代わりに、会社の購買専門家は、物理的なアイテム特性や法人情報には関心を有していない可能性があり、代替供給者および供給者と関連付けられた価格にのみ関心を有している。本発明の一実施例においては、ユーザーは、最初のサーチにおいて表示される属性を選択可能であり、次いで、これらの属性を、その特定のユーザーの将来のサーチにおける既定の属性として選択可能である。従って、最初のサーチにおいて物理的なアイテム特性を選択した場合には、アイテムについてサーチする技術者は、その他の属性を選択しない限り、将来のサーチにおいても、既定として物理的なアイテム特性を参照することになる。別の実施例においては、表示される結果は、そのアイテムの様々な属性ツリーを示すドロップダウンリストを含んでいる。ユーザーは、別の属性を選択することにより、そのツリー内に含まれている属性を表示可能である。
【００４４】
図１０を再度参照すると、ブロック１０８において、特定のアプリケーションに必要な属性を選択している。図１１の例においては、ユーザーは、公差属性を選択可能である。このような選択は、特定のコンポーネント、この例においては、特定の装置が正しく機能するのに必要な特定の公差を具備した１００Ωの抵抗器を設計者が所望しているという知識の結果であってよい。従って、この例においては、抵抗の値の属性である１００Ωと共に、公差属性が選択されることになろう。ブロック１１２において、ブロック１０８において選択された１または複数の属性の属性値に等価である選択された属性を具備したアイテムのサーチを実行している。図１１の例においては、サーチは、１０％の公差を具備した１００Ωの抵抗器であるアイテムについて実行されることになろう。別の実施例においては、等価属性のサーチは、属性値の範囲のサーチを包含可能である。例えば、図１１において、サーチのために、１０％未満の公差を選択可能である。このような場合には、１０％以下の公差を具備したすべての１００Ωの抵抗器がサーチされることになろう。最後に、ブロック１１６において、この検索基準を満足しているアイテムのリストを生成している。ユーザーは、このリストを閲覧し、このリストから１または複数のアイテムを選択し、次いで、例えば、１または複数のアイテムの購買を開始可能である。一実施例においては、本システムは、購買システムとやり取りすることにより、１または複数のアイテムに対する注文を発行している。
【００４５】
本発明の特徴を実装可能であるシステムの一例を表すコンピュータシステム２００が図１２に示されている。図１、２に示されている様々なアイテムは、図１２に示されているものと同様に構成可能であるが、多数のその他の構成も可能であることを理解されたい。これらのコンポーネントのそれぞれは、その独自のコンピュータシステムを使用して提供することも可能であり、或いは、いくつかの異なるコンポーネントを組合わせることも可能である。例えば、単一のコンピュータシステムを使用することにより、検索エンジン、サーバー、アプレットおよびカタログのすべてを提供可能である。同様に、このようなコンポーネントを分散コンピュータシステムを使用することによって提供することも可能である。コンピュータシステムは、図示のように単一のプラットフォーム上に配備することも可能であり、或いは、マスストレージ２０７およびその他のシステム２１０のコンポーネントの様々な部分または側面を含むいくつかの異なるプラットフォームをバス２０１が１つに接続するように、様々なコンポーネントを別個のプラットフォーム上に提供することも可能である。また、コンピュータシステムは、ラップトップおよび／またはデスクトップコンピュータなどの１または複数の小さな携帯型のプラットフォーム内に実装することも可能である。システム２００は、情報を伝達するためのバスまたはその他の通信装置２０１と、情報を処理するためのバス２０１と結合されたマイクロプロセッサ２０２などの処理コンポーネントを含んでいる。コンピュータシステム２００は、ランダムアクセスメモリ（ＲＡＭ）またはプロセッサ２０２によって実行される情報および命令を保存するためのバス２０１に結合されたその他の動的データストレージ装置などのメインメモリ２０４を更に含んでいる。また、メインメモリは、プロセッサによる命令の実行の際に生成される一時的な変数および／またはその他の中間情報を保存すべく使用することも可能である。
【００４６】
また、コンピュータシステムは、読出専用メモリ(Read Only Memory: ROM)またはプロセッサ用の静的情報および命令を保存すべくバスに結合されたその他の静的データストレージ装置などの不揮発性メモリ２０６をも包含可能である。また、空気圧ディスクまたは光学ディスクおよびその対応するドライブなどのマスメモリ２０７は、コンピュータシステムのバスに結合することも可能であり、かつ、様々なデータベースなどの情報および命令を保存すべく動作可能である。
【００４７】
また、情報をユーザーに対して表示すべく、コンピュータシステムを、バスを介して、ＣＲＴ、ＬＣＤ、またはその他のタイプの表示装置またはモニタ２２１に結合することも可能である。例えば、様々な命令および／または動作の状態のグラフィカルなおよびテキストによる通知およびその他の情報を表示装置上においてユーザーに対して提示可能である。通常、情報および命令選択内容をプロセッサに対して伝達すべく、キーボードなどの英数字入力装置２２２をバスに結合可能である。方向情報および命令選択内容をプロセッサに伝達すると共に表示装置２２１上におけるカーソルの移動を制御すべく、マウス、トラックボール、タッチスクリーン、またはその他のカーソル方向キーなどのカーソル制御装置２２３をバスに結合可能である。
【００４８】
また、通信装置２２５もバス２０１に結合されている。通信装置２２５は、例えば、ローカルエリアネットワークまたはワイドエリアネットワーク（ＬＡＮまたはＷＡＮ）をサポートするための通信リンクを提供すべく、モデム、ネットワークインターフェイスカード、無線通信装置、或いは、インターネット、トークンリング、またはその他のタイプの物理的なアタッチメントに対する結合のために使用されるものなどの任意のその他の周知のインターフェイス装置を包含可能である。この結果、コンピュータシステムは、例えば、インターネットまたはイントラネットを含む従来のネットワークインフラストラクチャを介して多数のクライアントまたはサーバーに結合することも可能である。このようなネットワークインフラストラクチャ上においてソースコンテンツおよびデータベースをコンピュータシステムに提供可能である。
【００４９】
以上において説明したコンピュータシステム２００は、説明および例示のためのものに過ぎず、本発明のシステムの機能は、任意の適切な演算システムおよび演算プラットフォーム上において実装可能であることを理解されたい。従って、模範的なコンピュータシステム２００の構成は、価格上の制約、性能要件、技術的な改善および／またはその他の事情などの多数の要因に応じて実装ごとに変化することになる。
【００５０】
以上、その様々な実施例を参照し、本発明について具体的に図示および説明したが、当業者であれば、本発明の精神および範囲を逸脱することなしに、形態および詳細における様々なその他の変更を実施可能であることを理解するであろう。
【図面の簡単な説明】
【００５１】
【図１】本発明の一実施例のシステムのブロックダイアグラムである。
【図２】本発明の一実施例のサーバーのコンポーネントを示す本発明の一実施例のシステムのブロックダイアグラムである。
【図３】アイテムおよびアイテムと関連付けられた様々な属性を示すテーブルである。
【図４】アイテムおよびアイテムと関連付けられた様々な属性を示すテーブルである。
【図５】別のアイテムおよびアイテムと関連付けられた様々な属性を示すテーブルである。
【図６】別のアイテムおよびアイテムと関連付けられた様々な属性を示すテーブルである。
【図７】本発明の一実施例のアイテムおよび関連する属性のストレージを示している。
【図８】本発明の別の実施例のアイテムおよび関連する属性のストレージを示している。
【図９】本発明の別の実施例のアイテムおよび関連する属性のストレージを示している。
【図１０】本発明の一実施例のサーチ動作の段階のフローチャートである。
【図１１】サーチされたアイテムと関連したレコードである。
【図１２】本発明の一実施例のコンピュータシステムのブロックダイアグラムである。
【符号の説明】
【００５２】
２０    システム
２４    カタログ
２８    サーバー
３２    クライアント
３６    接続
４０    ネットワーク
【図１】
2009515258.tif 000003
【図２】
2009515258.tif 000004
【図３】
2009515258.tif 000005
【図４】
2009515258.tif 000006
【図５】
2009515258.tif 000007
【図６】
2009515258.tif 000008
【図７】
2009515258.tif 000009
【図８】
2009515258.tif 000010
【図９】
2009515258.tif 000011
【図１０】
2009515258.tif 000012
【図１１】
2009515258.tif 000013
【図１２】
2009515258.tif 000014