(57)【要約】【課題】  ブローカモデルによるサービス分類情報提供サービスでは不可能であった細かいサービスに対する多様な観点に基づく分類の提供や関連付けを可能とする情報流通／検索方法を提供する。【解決手段】  プレイヤーＰが、自らを識別するための一意識別子と、被検索情報とを含む解釈記号をネットワークＢＮに公開し、他のプレイヤーＰが、ネットワークＢＮを介して上記プレイヤーＰが公開した解釈記号を取得し、自らを識別するための一意識別子と、被検索情報と、取得した解釈記号との関係を示す関係演算子とを含む解釈記号をネットワークＢＮに公開すると共に、取得した解釈記号を再公開する。また、別のプレイヤーＰが、ネットワークＢＮを介して希望するサービスに関する検索情報を送信し、解釈記号と検索情報とが合致した場合に、解釈記号を公開しているプレイヤーＰが解釈記号をプレイヤーＰへ返信する。【選択図】    図２
2005157443.tif 000002
【特許請求の範囲】
【請求項１】
複数の情報提供手段および複数の情報検索手段がブローカレスネットワークを介して接続された情報流通／検索システムにおいて、
一の情報提供手段が、自らを識別するための一意識別子と、被検索情報とを含む解釈記号を前記ブローカレスネットワークに公開し、
他の情報提供手段が、前記ブローカレスネットワークを介して前記一の情報提供手段が公開した前記解釈記号を取得し、
前記他の情報提供手段が、自らを識別するための一意識別子と、被検索情報と、前記取得した解釈記号との関係を示す関係演算子とを含む解釈記号を前記ブローカレスネットワークに公開すると共に、前記取得した解釈記号を再公開し、
前記情報検索手段が、前記ブローカレスネットワークを介して希望するサービスに関する検索情報を送信し、
前記情報提供手段が、自身で公開している前記解釈記号と前記検索情報とが合致した場合に、前記解釈記号を前記情報検索手段へ返信する
ことを特徴とする情報流通／検索方法。
【請求項２】
前記解釈記号は、提供可能な情報に関する事項が記載された解釈項を有することを特徴とする請求項１に記載の情報流通／検索方法。
【請求項３】
前記解釈記号は、提供可能な情報へのアクセス方法を記載した対象項を有することを特徴とする請求項１または請求項２に記載の情報流通／検索方法。
【請求項４】
前記情報検索手段は前記検索情報としてキーワードを送信することを特徴とする請求項１に記載の情報流通／検索方法。
【請求項５】
前記情報提供手段は、前記情報検索手段からキーワードを受信した時、該キーワードを予め決められた展開式に基づいて１ないし複数のキーワードないしは関係演算子に展開し、これと元のキーワードを前記情報検索手段へ返信する
ことを特徴とする請求項４に記載の情報流通／検索方法。
【請求項６】
一の情報提供手段が、複数の前記解釈記号の集団を代表する解釈記号である代表記号を有し、
前記代表記号が解釈項中に認証に必要な情報を有し、
前記解釈記号に対する特定の方法によるアクセスを受けて、該解釈記号を公開する情報提供手段が前記代表記号に対する特定の関係づけと認証情報とを応答し、
該代表記号中の解釈項中の情報と前記解釈記号の認証情報を元に認証を行い、前記代表記号に対する特定のアクセス方法に対して該代表記号を公開する前記一の情報提供手段が追加的な認証サービス手段へのアクセス方法を応答することを特徴とする請求項１に記載の情報流通／検索方法。
【請求項７】
前記代表記号に対する特定のアクセス方法に対して該代表記号を公開する前記一の情報提供手段が、前記集団を構成する複数の解釈記号の一覧表へのアクセス手段を応答することを特徴とする請求項６に記載の情報流通／検索方法。
【請求項８】
前記情報提供手段または前記情報検索手段が新たに情報流通／検索システムに参加した際に、最初に取得するべき解釈記号群の代表記号の一意識別子を前記情報流通／検索システムのいずれかの情報提供手段から受けることを特徴とする請求項６に記載の情報流通／検索方法。
【請求項９】
前記情報流通／検索システムにおいて解釈記号を公開する際に、特定の代表記号に対する関係付けを必須の条件とすることを特徴とする請求項６に記載の情報流通／検索方法。
【請求項１０】
一の情報検索手段が、連鎖条件、応答条件および最大連鎖数を有する検索情報を、自身の解釈記号に関連付けられた解釈記号を公開する情報提供手段へ送信し、
該検索情報を受けた情報提供手段が、前記応答条件を満足した場合は応答を前記一の情報検索手段へ送信し、前記連鎖条件を満足した場合は前記最大連鎖数を「１」減じた後、自身の解釈記号に関連付けられた解釈記号を公開する情報提供手段へ該検索情報を送信する
ことを特徴とする請求項１に記載の情報流通／検索方法。
【請求項１１】
前記情報提供手段は、自身が公開した解釈記号の前記解釈項に関する評価を受け、該解釈記号に前記評価の数を示すデータを記載することを特徴とする請求項２に記載の情報流通／検索方法。
【請求項１２】
前記情報提供手段は、自身が公開した解釈記号の前記対象項に関する評価を受け、該解釈記号に前記評価の数を示すデータを記載することを特徴とする請求項３に記載の情報流通／検索方法。
【請求項１３】
前記情報提供手段は、既存の解釈記号と関連付けて自身の解釈記号を公開する際に、
既存の解釈記号を作成した情報提供手段または再配布している情報提供手段から既存の解釈記号を取得して自身の解釈記号と対にして公開するか、
または、既存の解釈記号を公開した情報提供手段から対象項を削除した引用用の解釈記号を受け、
この引用用の解釈記号とこれに関連付けた自身の解釈記号を対にして公開するか、
または、既存の解釈記号を作成した情報提供手段から配布されている引用用の解釈記号の再配布されたものを取得して自身の解釈記号と対にして公開する
ことを特徴とする請求項１に記載の情報流通／検索方法。
【請求項１４】
前記引用用の解釈記号は、既存の解釈記号の対象項を削除し、表現項、解釈項、一意識別子を共通としていることを特徴とする請求項１３に記載の情報流通／検索方法。
【請求項１５】
前記情報提供手段が、既存の解釈記号の内容に対する修正、注釈の関係付けをした修正解釈記号の公開を行なった際に、通知するための通信方法を自動的に設定し、前記修正解釈記号の公開の際にこの通信方法によって既存の解釈記号を取得ないし再配布している情報提供手段に対して通知が行なわれることを特徴とする請求項１に記載の情報流通／検索方法。
【請求項１６】
前記修正解釈記号が公開されたことが通知された際に、通知内に記述された情報を用いて認証を行なった後で前記修正解釈記号の取得を行ない、前記修正解釈記号または対象項を削除した前記修正解釈記号を入手し、前記既存の解釈記号の再公開を行なう際に自動的に前記修正解釈記号または対象項を削除した前記修正解釈記号の再公開を行なうことを特徴とする請求項１５に記載の情報流通／検索方法。
【請求項１７】
前記情報検索手段は、一の解釈記号に対し特定の関係つけを持つ複数の解釈記号を、一括して取得する処理を有することを特徴とする請求項１に記載の情報流通／検索方法。
【請求項１８】
前記情報提供手段は、前記情報検索手段から前記検索情報として自身の一意識別子の一部と一致する情報を受けた時、一部一致が存在することを前記情報検索手段へ応答することを特徴とする請求項１に記載の情報流通／検索方法。
【請求項１９】
前記情報提供手段は、自身の解釈記号に他の解釈記号への関連づけを記述する際、特定の種類の関係付けの記述の総数を予め設定された上限値以下とすることを特徴とする請求項１に記載の情報流通／検索方法。
【請求項２０】
前記情報提供手段は、自身の解釈記号を他の解釈記号への関連付ける際、関連付けの容量または解釈記号中の特定部分の容量の総和を予め設定された上限値以下とすることを特徴とする請求項１に記載の情報流通／検索方法。
【請求項２１】
情報提供および情報検索を行う複数の情報処理手段がブローカレスネットワークを介して接続された情報流通／検索システムにおいて、
前記情報処理手段のコンピュータに、
自らを識別するための一意識別子と、被検索情報とを含む解釈記号を前記ブローカレスネットワークに公開する処理と、
前記ブローカレスネットワークを介して他の情報処理手段が公開した前記解釈記号を取得する処理と、
自らを識別するための一意識別子と、被検索情報と、前記取得した解釈記号との関係を示す関係演算子とを含む解釈記号を前記ブローカレスネットワークに公開すると共に、前記取得した解釈記号を再公開する処理と、
前記ブローカレスネットワークを介して希望するサービスに関する検索情報を送信する処理と、
自身で公開している前記解釈記号と他の情報処理手段が送信した前記検索情報とが合致した場合に、前記解釈記号を前記他の情報処理手段へ返信する処理と、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は対等な複数のプレイヤーがドメイン上でサービスを公開し、これを検索して上位アプリケーションから利用する情報流通／検索方法およびプログラムに関する。
【背景技術】
【０００２】
ネットワーク上で様々な提供者によって提供された種々のサービスを消費者が探索し、利用する形態のサービス提供は一般的なものとなっている。ドメイン上には複数のサービス提供者による複数のサービスが存在する。サービスを消費する消費者はサービスを発見し、かつ選択しなければならない。この際、サービスの提供者はサービスの内容説明（以下メタ情報という）を何らかの形で表現し、これを消費者に公開する。消費者はメタ情報を何らかの手段で収集し、その表現を解釈して評価しサービスを選択する。この際、何らかの観点からみて類似したサービス中から選択を行なう事が消費者にとっては望ましい。さらにその観点が個々の消費者の観点に近ければなお良い。
【０００３】
従来のネットワーク上での検索サービスでは、このような類似サービスの探索はもっぱらサービス分類を提供する分類検索サービスによって行なわれている。分類サービス検索の代表としてYahooを取り上げ、以下においてサービス分類と具体的なサービスとの結びつけの提供による類似サービスの探索が可能な環境の提供方法を説明する。まず、Yahooは自身の価値判断で行なったサービス分類を自身のＷＷＷサイト上で公開し、サービス提供者はYahooの運営者に対して自身のサービスを何らかの表現によって説明し、Yahooのサービス分類配下へのサービスの登録を依頼する。Yahooの運営者はサービスの内容の説明を評価し、サービス分類配下へ登録し公開する。このことからYahooを代表例とする分類化したサービス情報を提供するサービスにおいては、以下の役割が存在している事になる。
【０００４】
サービス提供者：サービスを提供する。サービスの広告を欲して分類化サービス情報提供者に自身の登録を依頼する。
サービス消費者：サービスを消費する。サービスの情報を欲して分類化サービス情報提供者から登録された情報を提供される。
分類体系提供者：サービスの分類体系を定義し提供する。
分類体系登録管理者：サービス提供者の提供するサービスを解釈し、分類体系に登録する。またサービスと分類体系の一致に関して継続的に管理する。
分類化サービス情報提供者：サービスの分類体系とこれに登録された分類化したサービスの情報を消費者の必要に応じて提供する。
【０００５】
Yahooにおいては、分類体系提供者、分類体系登録管理者、分類化サービス情報提供者の３者をYahooが兼ねている。一方でYahooの運営者はYahooが兼ねている３つのロールによるサービスをネットワーク外のあらゆる媒体をもちいて宣伝し、サービス提供者とサービス消費者への認知を計る。これはまずYahooのサービスを知って利用してもらわなければYahooが兼ねている３つのロールが機能しないからである。
【０００６】
ここにおいて、Yahooの果たしている３つのロールはいずれも特権的なものであり、元情報はサービス提供者が提供しているにも関わらずYahooの３つのロールを果たすに当たっての方針がYahooの提供するサービスのほとんどの部分を左右できる。Yahooの方針に反対するサービス提供者に可能なのはサービスを登録しない事だけである。このような特権的なロールが他のロール間を仲介する役割を持つ事を特徴とするモデルを以後ブローカモデルと呼ぶことにする。Yahooは典型的なブローカモデルによる分類化サービス情報提供サービスである。ブローカモデルによる分類化サービス情報提供サービスにおいてブローカが持つ特権は以下に整理できる。
【０００７】
１．分類体系とその背後にある分類の観点をブローカが特権として決定し配布する。
２．具体的なサービスを分類体系のどこに配するかおよびこれを提供するかをブローカが特権として決定し、かつ監視する。
３．分類化されたサービスの情報の提供の判断と実際の提供をブローカが特権として決定する。
【０００８】
ブローカモデルの分類化サービス情報提供において問題になるのは、ブローカに対する権限と負荷の集中、さらに分類観点の少なさである。特に分類体系の対象であるサービスが細分化され、これに対応して分類体系が細分化し変化が激しくなると、体系の作成、および登録、管理にかかる手間が増大する。ブローカモデルにおいてはこれを避けるために、分類体系を単純かつ大まかなものに抑えてサービスの登録単位もこれに併せた会社単位程度にすることが多く、個別のサービスに対応した分類を行なう事はしない事が多い。
なお、Yahooのサイトの登録、変更方法については下記のウエブページに開示されている。
http://add.yahoo.co.jp/docs/include.html(2003.11.10)
【０００９】
近年、特権的なロールを必然的に要求するブローカモデルのシステムに対立するものとして、ブローカレスモデルによるネットワーク構成が提案されている。ブローカレスモデルにおいては、対等な役割を担う個体（ここではこれをプレイヤーと称する事にする）の自律分散的な動作によってドメインが構成され、特権的なロールを必要とはしない。ブローカレスな分類化サービス情報提供サービスを実現するためには、ブローカモデルによるブローカの果たしていた特権的な役割を対等なプレイヤー間に分配して実現する必要がある。
【００１０】
これは、多様なサービスに対する視点に基づく分類の並立とその使いわけまで含めて対等なプレイヤーが様々な分類を作成、公開し利用することを意味する。また、分類は必ずしも全体的なものでなくても構わず、部分的なものであっても良いとする事で作成や公開がより容易に可能となる。この時必要となるのは、サービスとメタ情報の関係またはメタ情報とメタ情報の関係の関係付けの記述とその流通である。ツリー的なディレクトリ構造の中間点である概念はメタ情報とメタ情報の関係の一形態として表現する事ができる。
【００１１】
このようにブローカレスモデルにおける分類化サービス情報提供サービスを実現するためには、以下の機能を必要とする。
○プレイヤーが多様なメタ情報間ないしメタ情報とサービスの関係（以下概念関係と略記する）を作成、公開し、これが他のプレイヤーに流通させる事ができ、他のプレイヤーが概念関係を解釈して利用できること。
○プレイヤーが既存の概念関係に関係付けた概念関係を作成、公開しこれを流通可能させうる事。既存の概念関係を作成したプレイヤーが消滅した後でも新たに作られた概念関係については既存の概念関係を参照してその関係付けの利用や解釈が可能であること。
○概念関係を参照するプレイヤーは関連付けられた概念関係を探索できること。さらに必ずしも特定目的のために最適化されていない概念関係の関係つけを何段かたどる探索が可能であること。
【００１２】
○プレイヤーが流通している概念関係に対して評価を行ない、これを他のプレイヤーが利用できる事。評価したプレイヤーが消滅しても概念関係に対する評価は利用できること。
○既存の概念関係Ａを作成したプレイヤーかこれを後から修正した概念関係Ａ＋を流通させることができるが、それまでに作成されている概念関係Ａに関係付けられた概念関係Ｂのために修正前の概念関係Ａも他のプレイヤーから参照可能であること。この場合概念関係Ａを他のプレイヤーが参照する際、同時に修正後の概念関係Ａ＋も参照できることと、概念関係Ｂの作者は関係付けられた概念関係Ａが修正された事を通知され得ること。
○何らかの観点に基づく複数の概念関係を一つの群として扱い得る事。これが一つの群である事を認証ができ、本物の群の中の概念関係と悪意により追加される概念関係を区別する事か可能であること。
【００１３】
上記のような機能を提供することにより、ブローカモデルによるサービス分類情報提供サービスでは不可能であった精度の細かいサービスに対する多様な観点に基づく分類の提供や関連付けが可能となる。
ブローカレスモデルの機能を実現する分類化サービス情報提供サービスを実現するために必要な上記の技術の一部をなすものとして、概念関係の記述方式としてはＸＭＬがあり、複数のプレイヤーによる意味の記述に関してはWikiなどの技術がこれを実現している。またブローカレスなネットワーク上でのキーワードないしメタ情報による検索の技術としては、SIONet、Gnutellaなどが存在する。これは検索キーワードを一般化した概念であるメタ情報を用いてサービスを探索し、あるいはサービスを広告するものである。しかし、ブローカレス環境でメタ情報間の関係あるいはサービス間の関係である概念関係を流通させ共有すると共に評価しこの結果も共有する技術はこれまで存在していなかった。
なお、SIONetについては、特許文献１に開示されている。
【特許文献１】特開2003-196249号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
本発明は、上記の問題点を解決するために概念関係の流通を行なうことを主眼とし、概念関係の流通単位を規定してこれを流通させるための方法と併せて評価、探索、連鎖探索および評価の共有を行なう機能を種々のアプリケーションから利用可能とする情報流通／検索方法およびプログラムを提供することを目的とする。
また、本発明は、特定の観点やこれに関わる自動評価を利用したアプリケーションを作成する際、または多様な観点を許容し必要に応じて観点を切替えつつネットワーク上の意味を利用するアプリケーションを作成する際に必要な共通機能を提供することを目的とする。
【課題を解決するための手段】
【００１５】
本発明は上記の課題を解決するためになされたもので、請求項１に記載の発明は、複数の情報提供手段および複数の情報検索手段がブローカレスネットワークを介して接続された情報流通／検索システムにおいて、一の情報提供手段が、自らを識別するための一意識別子と、被検索情報とを含む解釈記号を前記ブローカレスネットワークに公開し、他の情報提供手段が、前記ブローカレスネットワークを介して前記一の情報提供手段が公開した前記解釈記号を取得し、前記他の情報提供手段が、自らを識別するための一意識別子と、被検索情報と、前記取得した解釈記号との関係を示す関係演算子とを含む解釈記号を前記ブローカレスネットワークに公開すると共に、前記取得した解釈記号を再公開し、前記情報検索手段が、前記ブローカレスネットワークを介して希望するサービスに関する検索情報を送信し、前記情報提供手段が、自身で公開している前記解釈記号と前記検索情報とが合致した場合に、前記解釈記号を前記情報検索手段へ返信することを特徴とする情報流通／検索方法である。
【００１６】
請求項２に記載の発明は、請求項１に記載の情報流通／検索方法において、前記解釈記号は、提供可能な情報に関する事項が記載された解釈項を有することを特徴とする。
請求項３に記載の発明は、請求項１または請求項２に記載の情報流通／検索方法において、前記解釈記号は、提供可能な情報へのアクセス方法を記載した対象項を有することを特徴とする。
請求項４に記載の発明は、請求項１に記載の情報流通／検索方法において、前記情報検索手段は前記検索情報としてキーワードを送信することを特徴とする。
【００１７】
請求項５に記載の発明は、請求項４に記載の情報流通／検索方法において、前記情報提供手段は、前記情報検索手段からキーワードを受信した時、該キーワードを予め決められた展開式に基づいて１ないし複数のキーワードないしは関係演算子に展開し、これと元のキーワードを前記情報検索手段へ返信することを特徴とする。
請求項６に記載の発明は、請求項１に記載の情報流通／検索方法において、一の情報提供手段が、複数の前記解釈記号の集団を代表する解釈記号である代表記号を有し、前記代表記号が解釈項中に認証に必要な情報を有し、前記解釈記号に対する特定の方法によるアクセスを受けて、該解釈記号を公開する情報提供手段が前記代表記号に対する特定の関係づけと認証情報とを応答し、該代表記号中の解釈項中の情報と前記解釈記号の認証情報を元に認証を行い、前記代表記号に対する特定のアクセス方法に対して該代表記号を公開する前記一の情報提供手段が追加的な認証サービス手段へのアクセス方法を応答することを特徴とする。
【００１８】
請求項７に記載の発明は、請求項６に記載の情報流通／検索方法において、前記代表記号に対する特定のアクセス方法に対して該代表記号を公開する前記一の情報提供手段が、前記集団を構成する複数の解釈記号の一覧表へのアクセス手段を応答することを特徴とする。
請求項８に記載の発明は、特徴とする請求項６に記載の情報流通／検索方法において、前記情報提供手段または前記情報検索手段が新たに情報流通／検索システムに参加した際に、最初に取得するべき解釈記号群の代表記号の一意識別子を前記情報流通／検索システムのいずれかの情報提供手段から受けることを。
【００１９】
請求項９に記載の発明は、請求項６に記載の情報流通／検索方法において、前記情報流通／検索システムにおいて解釈記号を公開する際に、特定の代表記号に対する関係付けを必須の条件とすることを特徴とする。
請求項１０に記載の発明は、請求項１に記載の情報流通／検索方法において、一の情報検索手段が、連鎖条件、応答条件および最大連鎖数を有する検索情報を、自身の解釈記号に関連付けられた解釈記号を公開する情報提供手段へ送信し、該検索情報を受けた情報提供手段が、前記応答条件を満足した場合は応答を前記一の情報検索手段へ送信し、前記連鎖条件を満足した場合は前記最大連鎖数を「１」減じた後、自身の解釈記号に関連付けられた解釈記号を公開する情報提供手段へ該検索情報を送信することを特徴とする。
【００２０】
請求項１１に記載の発明は、請求項２に記載の情報流通／検索方法において、前記情報提供手段は、自身が公開した解釈記号の前記解釈項に関する評価を受け、該解釈記号に前記評価の数を示すデータを記載することを特徴とする。
請求項１２に記載の発明は、請求項３に記載の情報流通／検索方法において、前記情報提供手段は、自身が公開した解釈記号の前記対象項に関する評価を受け、該解釈記号に前記評価の数を示すデータを記載することを特徴とする。
【００２１】
請求項１３に記載の発明は、請求項１に記載の情報流通／検索方法において、前記情報提供手段は、既存の解釈記号と関連付けて自身の解釈記号を公開する際に、既存の解釈記号を作成した情報提供手段または再配布している情報提供手段から既存の解釈記号を取得して自身の解釈記号と対にして公開するか、または、既存の解釈記号を公開した情報提供手段から対象項を削除した引用用の解釈記号を受け、この引用用の解釈記号とこれに関連付けた自身の解釈記号を対にして公開するか、または、既存の解釈記号を作成した情報提供手段から配布されている引用用の解釈記号の再配布されたものを取得して自身の解釈記号と対にして公開することを特徴とする。
【００２２】
請求項１４に記載の発明は、請求項１３に記載の情報流通／検索方法において、前記引用用の解釈記号は、既存の解釈記号の対象項を削除し、表現項、解釈項、一意識別子を共通としていることを特徴とする。
請求項１５に記載の発明は、請求項１に記載の情報流通／検索方法において、前記情報提供手段が、既存の解釈記号の内容に対する修正、注釈の関係付けをした修正解釈記号の公開を行なった際に、通知するための通信方法を自動的に設定し、前記修正解釈記号の公開の際にこの通信方法によって既存の解釈記号を取得ないし再配布している情報提供手段に対して通知が行なわれることを特徴とする。
【００２３】
請求項１６に記載の発明は、請求項１５に記載の情報流通／検索方法において、前記修正解釈記号が公開されたことが通知された際に、通知内に記述された情報を用いて認証を行なった後で前記修正解釈記号の取得を行ない、前記修正解釈記号または対象項を削除した前記修正解釈記号を入手し、前記既存の解釈記号の再公開を行なう際に自動的に前記修正解釈記号または対象項を削除した前記修正解釈記号の再公開を行なうことを特徴とする。
請求項１７に記載の発明は、請求項１に記載の情報流通／検索方法において、前記情報検索手段は、一の解釈記号に対し特定の関係つけを持つ複数の解釈記号を、一括して取得する処理を有することを特徴とする。
【００２４】
請求項１８に記載の発明は、請求項１に記載の情報流通／検索方法において、前記情報提供手段は、前記情報検索手段から前記検索情報として自身の一意識別子の一部と一致する情報を受けた時、一部一致が存在することを前記情報検索手段へ応答することを特徴とする。
請求項１９に記載の発明は、請求項１に記載の情報流通／検索方法において、前記情報提供手段は、自身の解釈記号に他の解釈記号への関連づけを記述する際、特定の種類の関係付けの記述の総数を予め設定された上限値以下とすることを特徴とする。
請求項２０に記載の発明は、請求項１に記載の情報流通／検索方法において、前記情報提供手段は、自身の解釈記号を他の解釈記号への関連付ける際、関連付けの容量または解釈記号中の特定部分の容量の総和を予め設定された上限値以下とすることを特徴とする。
【００２５】
請求項２１に記載の発明は、情報提供および情報検索を行う複数の情報処理手段がブローカレスネットワークを介して接続された情報流通／検索システムにおいて、前記情報処理手段のコンピュータに、自らを識別するための一意識別子と、被検索情報とを含む解釈記号を前記ブローカレスネットワークに公開する処理と、前記ブローカレスネットワークを介して他の情報処理手段が公開した前記解釈記号を取得する処理と、自らを識別するための一意識別子と、被検索情報と、前記取得した解釈記号との関係を示す関係演算子とを含む解釈記号を前記ブローカレスネットワークに公開すると共に、前記取得した解釈記号を再公開する処理と、前記ブローカレスネットワークを介して希望するサービスに関する検索情報を送信する処理と、自身で公開している前記解釈記号と他の情報処理手段が送信した前記検索情報とが合致した場合に、前記解釈記号を前記他の情報処理手段へ返信する処理とを実行させるためのプログラムである。
【００２６】
本発明では請求項１において、概念関係をブローカレス環境のネットワークの単位であるドメイン内で記述するための基本単位として自律分散型の意味記述オブジェクトである解釈記号を用いる。ここでドメインとは、プレイヤーが通信可能な範囲であるとする。解釈記号は概念関係を提供するサービスの単位であり、何らかのキーワードでサービスを検索できる環境を利用して提供される。解釈記号はその内部に外部からの探索の対象となるキーワード群を保持する表現項、自身が指し示すサービスヘのアクセス方法群を記述する対象項およびこの間の結び付きを説明する解釈項を有する。また、ドメイン内において一意である一意識別子を有し、これを表現項内に記述する事により、一意識別子の指定によって解釈記号をドメイン内で一意に指定し探索することが可能とする。さらに、他の解釈記号との間の関係を表現するために関係演算子を導入する。関係演算子は、解釈記号の間の関係に応じて関連、対立、包含、同義、疑問など複数の種類があり、この記述方法はドメイン内であらかじめ定められている。
【００２７】
ある解釈記号Ａの表現項に別の解釈記号Ｂの一意識別子と組で記述された関係演算子は、解釈記号Ａが解釈記号Ｂと関係演算子で表現される関係を持つ事を意味し、これを利用して解釈記号は他の解釈記号に対する関係を表現する。対象項は、サービスヘのアクセス方法を記述するかあるいはこれが無いことを示す記述かのどちらかが記述されている。サービスヘのアクセス方法が記述されていない解釈記号は、複数の解釈記号の関係付けの媒介など概略的な意味を表現するのに用いる。本発明における解釈符号の関連付けは、関連付けられた方に負担がなく関連付ける方が独自に関連つけを設定できる利点がある。関連付けられた方がその状況を知るためには、自身の解釈記号の一識別子と何らかの関連付けを組にした値で解釈記号の検索を行なえば良い。また、解釈項中の内容と表現項中の検索キーワードは重なる場合もあり、重ならない場合もある。いかなる形で表現項の記述を解釈項と関連つけるかは解釈記号の作者の自由である。この方法としては単純に解釈項の内容を形態素解析してキーワードになりうるものを表現項に記述する方法や、表現項の内容を独自に記述するといった方法があり得る。
【００２８】
探索は解釈記号に対するアクセス方法の基本である。解釈記号の探索は基本的にはキーワード、一意識別子、関係演算子＋一意識別子を１つないし複数指定すると共に何らかの評価方法と閾値を指定する事により評価値が一定の閾値を越えた事により解釈記号が応答する事で実行される。この際応答内に応答した解釈記号の一意識別子を含むことで、それ以降の解釈記号へのアクセスが容易になる。評価方法が省略されている場合、デフォルトの評価方法が使用される。デフォルトの評価方法の一例としては、ＯＲ検索として一つでもヒットすれば解釈記号が応答するといった例が挙げ得る。解釈記号へのアクセス方法は少なくとも以下の種類がある。
【００２９】
単純応答：解釈記号は一意識別子のみを応答する。
解釈項参照：解釈記号は一意識別子を含む表現項と解釈項の内容ならびに公開許可フラグの値を応答する。
記号取得：解釈記号は解釈記号の総体を送付する。受信元はこれをもとに解釈記号の複製を作成する。この際複製元のポリシーによって、総体ではなく対象項を削除した解釈記号を参照させて代表項のない解釈記号の複製を作成させることもできる。解釈項参照の代替として使用することも可能であり、主としてアプリケーション側の手間やネットワークヘの負荷を考慮して選択される。
【００３０】
対象取得：対象項を有する解釈記号は解釈記号の対象項中の対象へのアクセス方法を送付する対象項を有しない解釈記号はこのアクセスには反応しない。
解釈項評価参照：解釈記号は解釈項に対する評価を送付する。
対象項評価参照：解釈記号は対象項を有する解釈記号に対して対象項に対する評価を送付する。
連鎖探索：解釈記号に対して一定の条件を満たした範囲で関連する解釈記号への連鎖したアクセスを行なわせ、アクセスされた解釈記号が別の条件を満たすと、参照ないし取得が行なわれる。
メッセージ：解釈記号に対して一定の条件を満たした時、この解釈記号の生成を要求した上位APLに対してメッセージを通知する。APLによってはメッセージを拒否する事もある。
【００３１】
解釈記号は外部からの探索などを含めてあらかじめ定められた特定のアクセス方法に対して応答することによりその機能を実行するが、この際解釈記号の実体はドメイン経由でアクセス可能である限りにおいてどこに存在しても良い。しかしドメイン経由でのアクセスはそのトポロジや帯域幅によってコストや時間がかかる場合があり得る。また、プレイヤーのドメインからの離脱の際にも解釈記号が利用できた方が良い場合がありうる。このため解釈記号を利用するプレイヤーは特定のアクセス方法により解釈記号の複製を取得してキャッシュの目的で自身の端末やドメイン的に近くアクセスが容易な場所におく事が可能である。
【００３２】
以下、特に注記していない限り解釈記号への探索やアクセスはドメイン上に対してもキャッシュされているものに対しても同様に働いているものとする。さらに解釈記号の作者によって複製ないし一部を改変した解釈記号の再配布が許可されていてその旨を表す属性が記述されている場合には、プレイヤーによって取得された複製を公開し、外部からのアクセスに応答し、再配布することも可能である。この際、複製された解釈記号の再配布はこれを取得したプレイヤーの判断によって停止することもできる。
【００３３】
さらに、解釈記号による解釈記号の関係を表現するもう一つの方法として、本発明では請求項５において対象項による検索キーワードの展開を用いる。すなわち、１つないし複数の検索キーワードまたは一意識別子の１つないし複数の検索キーワードないし一意識別子への展開を解釈記号の対象項に対するあるアクセスを行なう事で実行することにより、特定の観点に基づいた異表記に対する対応や異なる意味の体系における共通要素の結びつけなどを行なう。
【００３４】
このような解釈記号は様々な観点から製作され得るので、何らかのキーワードで解釈記号を探索した時、異なる観点からの様々な解釈を得ることになる。これはある場面においては有用であるが、特定の観点からの探索が有用であるといえる場合も存在する。このような状況において一群の解釈記号が（少なくともそれらの製作者の主観では）同じ観点から作成されていることが示されることが望ましい。この時、一群の解釈記号があるその一群を代表する解釈記号と観点の共有を示す関連付けを行なうことによって実現できる。しかし解釈符号の関連付け方法では、関連付ける側が任意に関連付けを行なうことができるので、悪意のプレイヤーが代表たる解釈記号に対して勝手に観点の共有を示す関連付けを行なうことにより製作者の主観で同じ観点からという一群の解釈記号の最低の条件が満たされない可能性がある。
【００３５】
この問題を解決するために、本発明では請求項６において主張するように一群をなす解釈記号が一群である事を認証するため公開鍵などの情報を解釈項に保持し、代表たる解釈記号の対象項が追加的な認証を行なう方法へのアクセス方法を保持せしめる事と、一群の解釈記号が代表たる解釈記号に対してあらかじめ規定された認証付の関連づけを示す関係づけを保持せしめ、解釈記号に対する特定のアクセスによってこれを応答する事で解釈記号がー群をなす事を示すと共に、一群の解釈記号が電子署名などの認証情報を保持して特定のアクセス方法によってこの認証情報をこれを応答する事で認証を可能とすると共に、代表たるアクセス記号の対象項内に記述され特定のアクセスに対して応答される認証方法へのアクセス方法により提供される手段によって追加的な認証方法を提供する方法を用いる。
【００３６】
さらに解釈記号が保持する代表たる解釈記号への関連付けが記述されれば代表たる解釈記号から一群の解釈記号の検査を行なうことも可能になる。解釈記号の一群性はかならずしも一人の作者によって行われたことにより保証される必要はなく、何らかの合意に基づいた複数の作者による解釈、あるいは同じアルゴリズムに基づく自動処理された一群の解釈といった単位がありうる。
【００３７】
本請求項において保証されるのは特定の認証を行なうのに必要な情報を共有した集団ないし個人ないしプログラムが解釈を行なってこれを公開したことである。またこのことから、一群の代表たる解釈記号がある観点からの解釈を行なったのが誰かという情報を含んでいる必要はない。用途により解釈記号作者の個人情報が必要である場合には、これを解釈項に含む一群の代表たる解釈記号を記述すれば良く、さらに必要ならそれに対する認証情報を一群の代表たる解釈記号が保持すれば良いことである。
【００３８】
代表記号の解釈項ないしこれに関連つけた解釈記号中に作者の個人情報ないしそのアクセス方法を記述する事は請求項６からの容易な類推であることを主張する。また、後述する請求項１０で利用される対象項を削除した解釈記号に関しても対象項の削除の有無のそれぞれに対応した認証方法を用い、フラグを利用するかあるいは対象項を削除したものと対象項を削除していないものの双方の認証を準備することで解釈記号の記述内容に依存した認証方法でかつ同一の一意識別子を持つ解釈記号に対する認証が可能である。これは請求項６および請求項１０、請求項１１からの容易な類推であることを主張する。
【００３９】
前述した一群をなしている解釈記号を一括して知り得ることができれば有用である。本発明ではこの目的のために請求項７において、一群の解釈記号に対して代表たる解釈記号を作成し、一群の解釈記号が代表たる解釈記号に対するあらかじめ規定された特定の関連付けを保持し、一群の解釈記号であることを主張すると共に表現項の内容を得たプレイヤーに対して一群の代表たる解釈記号の一意識別子を通知し、一群の代表たる解釈記号の対象項に対するアクセスによって一群をなす解釈記号の一意識別子のリストの取得方法を応答する方法を用いる。また、この方法は請求項６において主張された方法と併用しても良い。この時、対象項に対する特定のアクセスによって認証を行なった上で別の特定のアクセス方法によりリストを得れば良い。これにより認証済のリストを得ることができる。この併用方法は請求項６、請求項７からの容易な類推であることを主張する。
【００４０】
ある解釈記号に関係付けられた解釈記号に対して更に解釈記号が関連付けられている場合、ある解釈記号と関連する解釈記号を探索する際に連鎖した先の解釈記号を取得することが可能である方が有用である場合が多い。単なる語彙の一致よりも解釈項の豊富な記述や対象の参照の後に作成された解釈記号の関係付けの方がより緊密な関係を表現できるからである。ただし、単に連鎖しているだけで必ずしも特定の目的のために最適化された関係つけと配置が行なわれているわけではない解釈記号を関連付けを元にたどった場合無用な解釈記号を捜し出す可能性も多い。このため、本発明においては請求項１０において主張する特定のアクセス方法によって解釈記号にアクセスした際に表現項ないし解釈項に記述された情報をアクセス時に指定された方法によって評価し、アクセスの際に記述された条件をクリアしなければそれ以上の連鎖探索を行なわない方法を用いて連鎖探索の範囲に制限を加え効率的な連鎖探索を可能とする。解釈記号がアクセス時に指定された評価方法を理解ないし実行できない場合、自動的にデフォルトの処理へ移行する。通常のデフォルト処理として考えられるものはその段階でその記号からの連鎖探索を打ち切ることである。これは解釈記号の解釈項の記述方式が複数存在したさいに、記述方式に依存した処理を可能とするために必要となる。
【００４１】
様々な観点から作成されかつ様々な観点から利用され得る解釈記号は使用する際の価値などが最初から保証されているわけではない。このため利用者が解釈記号を実際に利用した際の解釈記号に対する評価がフィードバックされ、公開されることは解釈記号の作成者にとっても他の利用者にとっても有益である。このため、本発明においては請求項１１において主張する解釈記号の公開時に解釈記号に対して評価を通知するための通信方法を自動的に設定し、解釈記号がこの通信方法によって通知された評価の通知を記録してその内容ないしは統計情報を公開して特定の解釈記号に対するアクセス方法でこの内容を公開する機能を用いる。この機能により、解釈記号の作成者や利用者はドメインにおいて利用された解釈記号に対してその評価を知り、これを利用して行動する事が可能となる。特に解釈記号の作者に関しては、解釈記号への評価を自動的に通知する機能があっても良く、前もって設定された契機によって自動的にこの機能が動けば便利である。このような解釈記号の作者への通知は請求項１１からの容易な類推であることを主張する。
【００４２】
解釈記号は複製されて再公開される事で作成者が存在しなくても公開され流通し得る。しかしサービスそのものは解釈記号とは異なる仕組で流通し、サービスの公開自体解釈記号とは異なる論理で決定されるので解釈記号は存在してもこの対象項がアクセス方法を提供するサービスが既に存在していない可能性がある。また、提供されているサービスが破壊されていたり、クラッキングの結果として悪意あるファイルなどを提供するサービスとなっている可能性もあり得る。このような場合、解釈記号に対してこれらの現象が生じていることを通知し、かつそれを公開するか解釈記号の作成者に通知することは有用であるが、解釈記号の解釈項に対する評価ではないので請求項１１における評価とは別のものとして扱うべきである。
【００４３】
本発明ではこの目的のために請求項１５において主張される対象項に記述されたアクセス方法によって得られる対象に対する問題点の報告を行なう通信経路を解釈記号の公開時に自動的に作成し、この通信によって行なわれた通信内容を記録するか、統計情報を取得する機能を用い、対象項に記述されたアクセス対象の問題点を記録する方法を用いる。これにより解釈記号の作成者は、アクセス対象の消失、対象の内容の破損、セキュリティ的な問題などアクセス対象に関する問題について、利用者たるプレイヤーからの情報を取得することか可能となり、自身で気づいていなかった問題点に対する対処が可能となる。
また、他の利用者たるプレイヤーにとってもアクセス対象への実際のアクセス前にこの情報を参照することは実際のアクセスを行なう際の判断に有益である。特に解釈記号の作者に関しては、解釈記号への評価を自動的に通知する機能かあっても良く、前もって設定された契機によって自動的にこの機能が動けば便利である。このような解釈記号の作者への通知は請求項１５からの容易な類推であることを主張する。
【００４４】
解釈記号は意味の体系の断片であって、大きな意味の体系ないしその一部分を構成するには他の解釈記号との関連付けが必要であり、請求項１においてはこれが主張されている。しかし、複数のプレイヤーによって公開ないし再公開されている解釈記号は、プレイヤー個別の都合で公開中止ないし消失する可能性がある。この時、消失した解釈記号に関連付けられた解釈記号群が存在した場合、その関係を連鎖探索によって知ることが難しくなる。ある記号の関連つけと同じ関連つけをもつ解釈記号を探すという形で探せば探せるが、媒介した解釈記号が存在すれば請求項１０におけるような連鎖探索の中でより効率的な探索を行なうことが可能である。また多数の解釈記号に関係付けられている解釈記号はそれ自体の対象項を指すよりも一種の概念として解釈されている可能性があり、ここに対して関係つけを行なうことは探索される上で有利である。この時多数関係付けられている解釈記号が消失することは中心となった概念を失ってしまうことであり損失が大きい。
【００４５】
本発明では、この問題を解決するために請求項１３においてあるプレイヤーが解釈記号Ｂが解釈記号Ａを引用するに当たって、解釈記号Ａの複製か、解釈記号Ａから対象項を除去した解釈記号Ａ’を取得し、解釈記号Ｂの公開と共に再公開を行なう方法を用いる。この方法により解釈記号Ａは引用されている解釈記号Ｂが公開されている場所にも存在してアクセスが容易になる。また、解釈記号Ａの作者が公開を中止したとしてもこれに関連つけている解釈記号Ｂが公開されている限り解釈記号Ａも対にして公開されアクセスが可能となる。ただし、解釈記号Ａの対象項に記述されたサービスヘのアクセスの複製を配布したくない場合が存在する。この例としては、サービスを提供するアクセス先の変更が予想されるといったケースや、サービス内部へのアクセス方法が随時に変更が行なわれる可能性が予想できるといったケースがある。このような場合、解釈記号Ａから対象項を削除した解釈記号Ａ’を作成し、複製を配布する際にこれを配布することによって実際のサービスヘのアクセスを行なう際には常に作者が保持する解釈記号Ａの情報を提供可能となり、実際のサービスのアクセス先の変更などに柔軟に対処できる。
【００４６】
前述した解釈記号Ａと対象項を削除した解釈記号Ａ’は元は同じ解釈記号であるが、特定のアクセスに対する反応が異なる。対象項が存在しない解釈記号Ａ’は対象項の内容に関するアクセスを受けた際に応答しない。この時解釈記号Ａと解釈記号Ａ’が異なる解釈記号であるとして異なる一意識別子を割り振ることも可能である。しかしこの場合解釈記号Ａ’に対して対象項取得を行なう時、改めて解釈記号Ａの一意識別子を得るための方法が必要になる。これは対象項が存在する解釈記号の関係つけを定義して解釈記号Ａ’に記述する事で解決できるが、余計な探索トラフィックの必要性が生じるのは避けられない。
【００４７】
この問題を解決するため本発明では請求項１４で主張するように解釈記号Ａとその対象項を削除した解釈記号Ａ’が一意識別子を共有すると共にオリジナルの解釈記号Ａが対象項が存在することを意味するフラグを表現項内に保持する方法を用い、対象項に対するアクセスにおいて一意識別子の一致とフラグの存在の論理積を条件として探索を行ないアクセスすることにより解釈記号Ａ’の一意識別子で対象項を有する解釈記号Ａを発見する方法を用いる。これによって解釈記号Ａと解釈記号Ａ’が一意識別子を共有することが可能になる。
【００４８】
また、請求項１１、請求項１２で主張される記号の評価に対する統計情報を必要な解釈記号Ａと解釈記号Ａ’にそれぞれ必要な解釈記号にのみ通知することが請求項１１においては一意識別子のみを指定することで、請求項１２においては一意識別子の一致と対象項が存在することを示すフラグの記述の双方が存在することを条件にすることによりそれぞれ可能となる。対象項が存在することを示すフラグは表現項内で記述可能で解釈の方法がドメイン内の各ブレイヤーに共有されている限りどのような方法で記述されていても良く、例えば一意識別子を階層化して特定ビットがフラグとなっていても構わない。このような記述方式は全て請求項１４からの容易な類推であることを主張する。
【００４９】
解釈記号Ｘが作成され再配布された後に修正や変更が行なった解釈記号Ｙが後から公開される場合があり得る。この場合解釈記号Ｘと解釈記号Ｙは一意識別子が事なる別の記号で、修正を意味する関係付けがなされているとする。一方で変更前の解釈記号Ｘに関連付けを行なった解釈記号Ｚが公開されている場合もあり得る。この際解釈記号Ｙに解釈記号Ｚを単純に関連付けるか否かは修正や変更の内容による。修正や変更された内容自体が解釈記号Ｚの関連付けの論拠である場合があるからである。しかし解釈記号Ｘの修正が起きたこと自体を特に再公開しているプレイヤーが知ることは有益である。少なくともそこから解釈記号Ｘに修正ないし変更を行なった解釈記号Ｙの内容を吟味し対応を考えることができる。
【００５０】
本発明ではこの目的のために請求項１５で主張する解釈記号Ｘの取得またはこの後に行なわれる再公開の際に解釈記号Ｘの変更を行なう関係付けをもつ解釈記号Ｙの公開時に自動的に通知を受信するための通信方法を設定し、解釈記号Ｘの取得者ないし再公開者に対してこれを通知する方法を用いる。これにより解釈記号Ｘの取得者ないし再公開者は変更や修正に関して通知を受けることができる。実際にこれを行なう際には、解釈記号Ｘ自体が解釈記号Ｘの一意識別子に特定の関係付けをあらわす関係演算子を組み合わせたものを検索キーとして行なわれる通信に対して反応し、この通信の内容を記録するかプレイヤーに対して通知すれば良い。
【００５１】
請求項１５で主張する解釈記号の変更に対する通信に対して、解釈記号を取得ないし再配布しているプレイヤーが直接解釈記号Ｘと解釈記号Ｙを置換するのは前述した理由により適当ではないが、解釈記号Ｘを取得しているプレイヤーが解釈記号Ｙを取得するのは有益である。ただし解釈記号Ｘの作者以外の悪意のプレイヤーが解釈記号Ｘに対する悪意の変更や修正を行なう可能性もある。この目的のため本発明では請求項１６で主張するように請求項１５で主張される通信方法で取得ないし再配布している解釈記号Ｘに変更の関係付けを持つ解釈記号Ｙが公開されたことが通知されたさいに、解釈記号Ｙを一度取得した上で認証を行ない認証をパスしたものを解釈記号Ｘと共に保存する方法を用いる。ここで認証の方法としては請求項７における認証方法を持って解釈記号Ｘおよび解釈記号Ｙが共に一群の解釈記号であることを認証する方法等がありうる。その他の認証方法をとるにせよ、解釈記号の取得ないし再公開に当たって自動的に設定された通信路による通信から認証、取得というプロセスが自動的に動作する限り請求項１６からの容易な類推であることを主張する。
【００５２】
一群の解釈記号の中には一群として存在しないと意味をなさないか、一群としてアクセスされることが多いと予想されるものがありうる。このような解釈記号群を取得する際に一括して取得できれば効率的である。例としてはあるドメインで利用される基本的な分類体系などを解釈記号群としてあらわし、これが請求項６で主張する代表記号に対する関係つけによって一群である事を主張している場合、一群たる解釈記号を全て取得することでドメインが扱う分野の概観を得ようとする場合などがある。この目的のために本発明では請求項１７で主張するある一意識別子を持つ解釈記号に対して特定の関係付けが行なわれている解釈記号の群を一括して取得する方法を用いる。
【００５３】
これは解釈記号の一意識別子を指定して取得するアクセスとは別に特定の関係つけを行なっている解釈記号を一括して取得している事を表示する関係つけを定義し、この関係つけを表現項内に保持する解釈記号（以下一括取得表示記号とする）の対象項内に一括して取得した解釈記号の一意識別子のリストの提供および解釈記号を一括した取得を提供するサービスヘのアクセス方法を記述し、このサービスを提供することによって実現する。また、一括取得した解釈記号が一群の全てであることを代表記号の対象項内のアクセス方法で提供されるサービスから入手したリストと照合するか、代表記号が周囲に発見できない際は一括取得表示記号の対象項内のアクセス方法で提供されるサービスから入手したリストと照合することにより確認する。この時代表記号から入手したリストで確認した際には公式確認としてその旨を一括取得表示記号の表現項内に表示し、一括取得記号から取得したリストで確認したさいには非公式確認としてその旨を一括取得表示記号の表現項内に表示する。
【００５４】
さらに一括取得記号が周囲に発見できない際には副次的な方法としてある解釈記号の一意識別子＋関係演算子を指定した特定のアクセスをマルチキャストすることにより、該当するそれぞれの解釈記号がこれに反応しての自身の複製ないし対象項を削除した複製を応答として送出する方法を併用し、以後これを行なったプレイヤーが一括取得表示記号を公開する。
【００５５】
マルチキャストによる取得、あるいは一括取得中の失敗などで途中で取得が終ったり確認ができなかった場合には、一括取得表示記号中の表現項目ないに未完了の旨を表示する。これは一群の全てを取得した保証がなされない事を意味する。プレイヤーは周囲で発見した一括取得表示記号の表現項内容からもっとも適した一括取得表示記号を選択し、この対象項内に記述されたアクセス方法により一群の解釈記号の一括取得を行なう。解釈記号の作者が一群性を保証していない場合には、もともと一群の解釈記号の全てを確認する事ができないから、未完了の一括取得記号しかない場合がある。このような場合でも、一括取得記号の情報から一括取得をおこなうことでマルチキャストによる取得よりもネットワークに対する負荷が軽い取得を行なう事は可能である。
【００５６】
解釈記号の一意識別子のドメイン内での一意性は重要である。一意識別子を作成する一つの方法として、プレイヤーが解釈記号の一意識別子のプレフィックスをまず作成し、プレイヤーが自身の作成した解釈記号についてはこの一意識別子のプレフィックスに加えてプレイヤーが一意である事を確認できる管理番号を付与することで構成する方法があり得る。ただし１プレイヤーが使用する一意識別子のプレフィックスが１つである必要はない。あるプレイヤーとそのプレイヤーが使用する一意識別子のプレフィックスが１対他であれば良い。この時、解釈記号の一意識別子が重複していないかを確認するには、階層化された一意識別子のプレフィックスが一致する他の解釈記号が存在しないかを確認すれば十分である。本発明ではこの目的のために請求項１８で主張する解釈記号のプレフィックスを決定しようとするプレイヤーが確認のために行なう解釈記号の一意識別子のあらかじめ規定された部分を含む特定のアクセス方法に対して、プレイヤーが保持し公開する解釈記号の一意識別子の規定された部分が一致した場合に、自身の一意識別子を含む応答をプレイヤーが返す方法を用いる。作成する解釈記号のプレフィックスを決定しようとするプレイヤーは、請求項１８による方法によっでそのプレフィックスが既に使用されていないか確認することができる。
【００５７】
解釈記号の関係付けの数は解釈記号の関係の複雑さを大きく左右し得る。一例を挙げれば解釈記号が自身の関連を１つしか定義できなければ解釈記号の関連は自動的にツリー構造か、せいぜい循環したリング構造がその中に一部交じるかのどちらかである。解釈記号の関連を利用しようとする時、解釈記号の関係の複雑さを一定以下に抑える目的で解釈記号が表現項内に保持できる関係付けを一定数以下に抑えることができれば有益な場合がある。この例としてはドメイン中の解釈記号の関係付け総体のトポロジを分析して大分類を作ったりドメインを分離してトラフィックを局所化して効率化を計るといった例があり得る。この目的のために本発明では請求項１９で主張する表現項中に特定の関係付けを除いた関係付けの記述数の上限をドメインで設定し、これ以上の関係付けの記述数を持つ解釈記号を不当なものであるとして、デフォルトの処理を行なう方法を用いる。デフォルトの処理としては不当な解釈記号の廃棄が挙げられる。
【００５８】
また、記述数から除かれる特定の関係つけとしては、請求項６で用いられた解釈記号が一群であることを示す代表記号に対する関係付け等が挙げられるが、この運用はドメインで規定されドメインに参加しているプレイヤーが全て知っていれば良い。解釈記号の関係付け総体のトポロジを利用するアプリケーションは、関係を評価する際に除外された関係付けを除いて解釈記号の関係の総体のトポロジを構成すれば良い。このようなアプリケーションを使用することが最初から分かっているドメインでは、このアプリケーションかドメインにおける関係付けの数と除外される関係付けの種類を規定することもあり得る。
【００５９】
ドメインにおいて流通する解釈記号を処理する際に不当に巨大な解釈記号が存在すると処理が複雑になり、かつ様々な種類の装置上に実装される本発明において大きな記憶容量が必要になるなど問題点が多い。この問題を緩和するため、本発明では請求項２０において主張する解釈記号の容量の上限ないし解釈記号の特定部分の容量の上限をドメインにおける規約として設定し、これ以上の容量を持つ解釈記号に対してはデフォルトの取扱をする方法を用いる。デフォルトの取扱の例としては、取得の中止と破棄および解釈項に対する容量オーバーを評価として通知する方法がある。
【００６０】
これを実現するためには、解釈記号の取得中に随時全体の容量ないし特定部分の容量を測定し、容量がオーバーした時点で取得を中止してそれまでの受信したデータを破棄すると共に容量オーバーした旨を通知すれば良い。これにより容量オーバーした解釈記号が流通することがなくなり、ドメインやプレイヤーに対する負荷を一定以下に抑えることが可能となる。また副次的な効果としてバッファオーバーフロー攻撃などのセキュリティ上の弱点を発生しにくくすることもできる。
【００６１】
プレイヤーがドメインに参加する際にドメインにおける規定やデフォルトで用いられているオントロジ体系などをなどを知るために解釈記号を元にアクセスする場合がある。この際の最初の手がかりとなる解釈記号をドメインに参加したさいに参加者に対して与える方法を請求項８として主張する。これによりプレイヤーはドメインに対して最低限の知識でアクセスした際にもこの解釈記号とそこからたどって得られるサービスとしての情報提供により特定のドメインの規定に即した行動を取ることが可能となり、前述した特定のドメインの規定による解釈記号に関する制限事項などを当初から得ることが可能となる。
【００６２】
特定の目的のために構成されたドメインではドメイン内において流通する解釈記号を制限する必要性が生じる場合がありうる。この例として特定のサービスを特定のサービス提供者が提供するためだけに作成されたドメインにおいてサービス提供者が提供する解釈記号以外は流通させないといった場合や、ドメインを利用する利用者を制限しあらかじめ登録された利用者以外からは解釈記号を流通させないといった場合があり得る。このような制限を実装する方法として、何らかの形で登録されている代表記号により認証か可能な解釈記号以外は不当なものとしてデフォルトの扱いをする方法を請求項９において主張する。デフォルトの扱いの例としては、解釈記号の破棄があげられる。
【００６３】
これまで述べた本発明による解釈記号の構成、流通、アクセスにより、ブローカレスな概念関係の構築を流動的なドメイン上で行なうことが可能となり、即時的かつ詳細なサービス分類情報提供サービスなど従来行ない得なかったドメイン上のサービスを提供することが可能となる。また、ドメイン内の概念関係への随時な追加、修正および評価が可能である事により、ドメインを利用するユーザのニーズの変化や状況の変化に追随して新規サービスを公開したり、従来サービスの新しい広告を作る事が可能となる。一方で解釈記号の一群性を特定の視点とみなす事が可能であるから、ドメイン内のサービスを複数の視点の一つから見た関係や評価から探索し、かつ必要なら別の視点で見直して改めて探索、評価する事も可能となり、ブローカ型サービス分類情報提供サービスのようにドメインに参加するか、退出するかの選択しかユーザにはないというドメインとユーザの関係からドメインに対するユーザの参加、評価の多様なあり方を提供するドメインを構築することが可能となる。特に特定サービスの提供を目的としたドメインではなく、その場に居あわせた、その近辺に居住しているなどユーザの属性の共有によって構成されたドメインにおいては、ドメイン内の概念関係の変化を可能とする意義は大きい。
【発明の効果】
【００６４】
本発明によれば、ブローカモデルによるサービス分類情報提供サービスでは不可能であった精度の細かいサービスに対する多様な観点に基づく分類の提供や関連付けが可能となる効果が得られる。また、ブローカレス環境でメタ情報間の関係あるいはサービス間の関係である概念関係を流通させ、共有すると共に評価し、この結果を共有することができる効果が得られる。
【発明を実施するための最良の形態】
【００６５】
（１）システムの概略
以下、図面を参照し、この発明の実施の形態について説明する。図１はこの発明の一実施の形態による情報流通／検索システムのハードウエア構成を示すブロック図である。この図において、Ｃ−１〜Ｃ−５はパーソナルコンピュータであり、インターネット等のネットワークＮＷを介して相互に接続されている。各パーソナルコンピュータＣ−１〜Ｃ−５にはそれぞれプレイヤーＰおよびエンティティＥと呼ばれるソフトウエアがセットされている。エンティティＥはブローカレスモデルによるネットワーク（例えば、SIONet）を構築しており、また、プレイヤーＰはブローカレス探索ドメインを構成している。
【００６６】
図２は上記システムのソフトウエア構成を示す図であり、この図において、Ｄはブローカレス探索ドメイン、ＳＲはシェアードリンク、ＢＮはブローカレス検索ネットワーク（SIONetではイベントプレースと呼ばれる）である。
本実施形態によるプレイヤーＰはブローカレス探索ネットワークＢＮの上位にあって、ブローカレス探索ネットワークＢＮの探索機能を利用する。以下、まず、ブローカレス探索ネットワークＢＮの一例であるSIONetの用語を主に用いて一般的なブローカレス探索ネットワークＢＮの概略を説明し、その上にプレイヤーＰがどのような形で動作するかを説明する。
【００６７】
ブローカレス探索ネットワークＢＮは動作主体であるエンティティ（Gnutella、JxtaではPeerと呼ぶ）Ｅの集団が、互いにシェアードリンク（JxtaではPipe，Gnutellaでは特に名称がついていない）ＳＲによって接続された一群のブローカレス探索ネットワークＢＮを構成する。この一群をイベントプレース（JxtaではPeer Group）と呼び、探索はこのイベントプレースの内部において行なわれる。エンティティＥは上位のプログラムに対してAPI(Application Program Interface)を有し、プログラムによるAPIへの操作により被検索情報の保持と検索情報のシェアードリンクＳＲを介した送出を行なう。送出された検索情報はシェアードリンクＳＲを介して隣接したエンティティＥヘ送出され、ここでエンティティＥが保持している被検索情報と照合される。
【００６８】
ここで被検索情報と検索情報が一部でも一致した場合、エンティティＥはAPIを介して検索情報を含む情報を上位のプログラムに渡す。これとともにエンティティＥは更にシェアードリンクＳＲを介して検索情報を隣接するエンティティＥに転送し、以下、同様に検索情報と被検索情報の照合が行なわれる。被検索情報と検索情報の一部一致を伝えられた際、最終的に何らかのアクションを行なうか否かは、上位プログラムが判断する。無限遠までの探索を行なうことはイベントプレースを構成する他のエンティティＥの負荷を増大させ過ぎるので、探索情報の到達範囲は制限する設定が行なわれることが通常であり、エンティティＥ間の検索情報の転送回数の制限を上位APIより設定して設定数を越えた場合にはそれ以上転送しないといった方法が取られる。検索情報の効率的な配布のための技術的工夫、さらにはエンティティＥの生成、消失、移動によるイベントプレースの再構成に関して対処する方法はブローカレス探索ネットワークによって異なる技術が用いられているが、本実施形態においては直接関わらないので説明は割愛する。
【００６９】
本実施形態におけるプレイヤーＰは、エンティティと１対１ないし１対多の関係をもったプログラムであり（図２では１対１の場合を示している）、エンティティＥが構成するブローカレス探索ネットワークＢＮの上に存在して同時に上位のプログラムに対してAPIを提供する。プレイヤーＰが下位のブローカレス探索ネットワークＢＮを介して相互に情報の検索を行ない得る範囲が本実施形態でいう所のドメインＤである。プレイヤーＰは配下のエンティティをドメインＤの下に存在するブローカレス探索ネットワークＢＮにまず参加させ、次にドメインＤに参加する際に最初に必要となる情報を探索して取得し、更に必要なら最初に必要となる情報を元にドメインＤヘの参加のための処理を行なうことによってドメインＤに参加する。本実施形態は、ドメインＤに参加したプレイヤーが後述する解釈記号を作成、アクセス、収集、保持、再配布、破棄する行動と解釈記号がアクセスに対する評価と応答を行なう動作によって実現される。
【００７０】
（２）解釈記号Ｋ
図３は解釈記号Ｋ１の構造を示す。解釈記号Ｋ１は表現項２−２、解釈項２−３、表現項ｂ２−９、対象項２−４および解釈項２−３に対する評価記録２−５、対象項２−４に対する評価記録２−７、対象項２−４へのアクセスカウンタ２−１７、解釈項２−３へのアクセスカウンタ２−１８、表現項ｂ２−９および対象項２−４の削除を行なった解釈記号Ｋ２（図４）の配布許可フラグ２−１２、表現項ｂ２−９および対象項２−４を含む解釈記号Ｋ１の配布許可フラグ２−１３、対象項の配布許可フラグ２−１４を有する。さらに図中の破線２−１５の範囲が改竄されていない事を示す電子署名２−８、同じく図中の破線２−１６の範囲が改竄されていない事を示す電子署名２−６を有する。
【００７１】
表現項ｂ２−９および対象項２−４の削除を行なった解釈記号Ｋ２においては、表現項２−２中に対象項２−４の記述を示すフラグ２−１１が存在しない。表現項２−２には必ず解釈記号Ｋ１またはＫ２（以下、解釈記号Ｋという）自体の一意識別子２−１０が記述される。対象項ｂ２−９には対象項２−４が存在する事を示すフラグが必ず存在する。
表現項２−２には、当該解釈記号Ｋの一意識別子、対象項記述を示すフラグ、キーワード、関係演算子等が記載される。この表現項２−２の内容は変換されてブローカレス探索ネットワークＢＮにおける被探索情報となり、ブローカレス探索ネットワークＢＮにおいて被探索情報と探索情報の何らかの一致があった場合にブローカレス探索ネットワークＢＮから解釈記号Ｋを公開しているプレイヤーＰに対してAPI経由で通知がおき、この通知の内容に対してプレイヤーＰが反応して応答する。解釈記号Ｋに対するアクセスは一般にこのブローカレス探索ネットワークＢＮ経由の通知によって実現され、プレイヤーＰの反応は同様にブローカレス探索ネットワークＢＮ経由で応答することによって実現される。
【００７２】
解釈項２−３には、サービスの要約、表現項２−２と対象項２−４との関係、サービスの宣伝、その他のコメント等が記載される。また対象項２−４にはサービスヘのアクセス方法（例えば、ＵＲＬ）等が記載される。
また、解釈記号Ｋに対するアクセスの度にアクセスカウンタ２−１７または２−１８が１つ増大する。すなわち、解釈項２−３のみを対象としたアクセスの場合、解釈項へのアクセスカウンタ２−１８が増大し、対象項のみを対象としたアクセスの場合、アクセスカウンタ２−１７が増大する。解釈記号Ｋ１の取得の場合両方のアクセスカウンタが増大する。
【００７３】
また、解釈項への評価２−５には、例えば、解釈項２−３に対するよい評価の場合に＋１、悪い評価の場合に−１が加算される。したがって、ユーザはこの評価２−３によって解釈項２−３の一般的評価が良いのか悪いのかを知ることができる。なお、評価の詳細内容はメッセージの形でプレイヤーＰに送信される。同様に、対象項への評価２−７には、対象項２−４に対するよい評価の場合に＋１、悪い評価の場合に−１が加算される。対象項に対する良い評価とは、例えば、「サービスへのアクセスが容易にできた」ということであり、悪い評価とは「サービスへアクセスできなかった」ということである。
【００７４】
（３）解釈記号Ｋとブローカレス探索ネットワークＢＮの関係
解釈記号Ｋが下位のブローカレス探索ネットワークＢＮに対してどのような情報を設定するかを図５で説明する。ここでは、下位のブローカレス探索ネットワークＢＮとしてSIONetを想定する。プレイヤーＰは解釈記号Ｋの表現項２−２の内容をエンティティＥを介してブローカレス探索ネットワークＢＮに対して登録し、エンティティＥが登録内容と到来した問い合わせを比較して、条件を満たした際にプレイヤーＰに対してアクセスがあった事を通知し、その後はプレイヤーＰがこのアクセスに対して反応し必要な情報を送出する。SIONetにおいては、エンティティＥがブローカレス探索ネットワークＢＮに対して登録する情報をフィルタといい、フィルタ内部に特定の書式にしたがって表現項の内容を記述する。フィルタに対する問い合わせをイベントといい、同じく特定の書式にしたがって問い合わせ内容を記述する。
【００７５】
イベントはSIONetの機能でエンティティＥによって構成されるブローカレス探索ネットワークＢＮ（イベントプレース）内を転送され、エンティティＥに登録されたフィルタと比較照合され、フィルタ内の条件式が真になればプレイヤーＰにイベントの内容が転送される。これに対する応答も同様に、エンティティＥがブローカレス探索ネットワークＢＮに対してイベントを送出する事で行なわれる。本実施形態においては解釈記号Ｋの表現項２−２内容をブローカレス探索ネットワークＢＮの種類に応じた書式や方法によって登録することで解釈記号Ｋを下位のネットワークであるブローカレス探索ネットワークＢＮにおいて公開することが可能となる。
【００７６】
図５においては一つの解釈記号から３つのフィルタ３−１〜３−３が登録されている。これは表現項２−２の内容にある程度一致したイベントによってプレイヤーＰにアクセスが行なわれるフィルタ３−１と、一意識別子の一致のみでプレイヤーＰにアクセスが行なわれるフィルタ３−２、ならびに一意識別子の一部一致でアクセスが行なわれるフィルタ３−３を登録することで、多様なアクセス種別に効率的に対応することを意図しているものである。一つの解釈記号Ｋから行なわれるブローカレス探索ネットワークＢＮへの登録情報が１つのみあるいは２つ以上になることもアクセスの種別およびブローカレス探索ネットワークＢＮへの対応方法によってあり得る。
【００７７】
（４）アクセス情報（イベント）
図６は解釈記号Ｋを探索するアクセス情報（イベント）の構造を説明する。アクセス情報はブローカレス探索ネットワークＢＮおいて、解釈記号Ｋを探索するための検索情報の基となる情報である。本実施形態においては、アクセス情報は図６で表される構造と各フィールドに記述された情報よりなり、ブローカレス探索ネットワークＢＮにおいて、規定された書式に変換されてフィルタとして公開され、フィルタにヒットしたアクセス情報はプレイヤーＰにおいて指定する構造に変換され、次いで解釈されて応答を引き起こす。以下、アクセス情報の各項目を順次説明する。
【００７８】
○KeyWord群の記述フィールド：ブローカレス探索ネットワークＢＮにおける検索キーワードとなる情報である。このフィールドにはキーワード一般、解釈記号Ｋの一意識別子、「関係演算子＋一意識別子」で記述される他の解釈記号との関係付けなどが検索キーワードとして記述される。
○アクセス情報識別子：アクセス情報を区別するための識別子である。これは主に同一アクセス情報が頻繁に到来した際に、応答数を抑制するためにアクセス情報の同一性を把握、記憶するために用いる。また、連鎖探索（後述する）の際に同一の解釈記号Ｋに対する同一のアクセス情報に対する応答や連鎖を抑制する目的で利用される。
○探索到達範囲記述フィールド：ブローカレス探索ネットワークＢＮにおける探索範囲に指定を行ないたい場合に記述される。記述がない場合探索範囲はブローカレス探索ネットワークＢＮのデフォルト値が設定される。
【００７９】
○アクセス種別記述フィールド：アクセス情報が解釈記号Ｋに対してどのような種類のアクセスを行なうかを記述するものである。
○応答条件記述フィールド：解釈記号Ｋが応答を行なう際の条件式を記述するものであり、解釈記号Ｋがこの条件式を評価して応答するかどうかを決定する。
○応答方法記述フィールド：プレイヤーＰが応答する際の方法を記述するものである。代表的な応答の方法としては、このフィールドに応答を受信した解釈記号Ｋの一意識別子が記述され、プレイヤーＰは応答方法記述フィールドに記述された一意識別子に対するアクセス情報として応答情報を作成し送出する。これ以外にもあらかじめ規定された方法の記述によりプレイヤーＰが応答方法を解釈して決定できるならば、応答方法記述フィールド内には種々の方法による応答方法が記述される場合があり得る。
○Option記述フィールド：アクセス情報中に上記以外の情報を付加しプレイヤーＰないしその上位のAPL（アプリケーション）での通信を行なうものである。一例としては、解釈記号Ｋに対する評価を通知するにあたり、評価内容をOption記述フィールドに規定の書式で記述する。また、連鎖探索時の連鎖条件もこのフィールドに規定の書式で記述される。
【００８０】
（５）解釈記号Ｋ相互の関係付け
図７は解釈記号Ｋ相互の関係付けの方法の説明である。解釈記号Ｋが配布許可の条件で、すなわち、図３の配布許可フラグ２−１２または２−１３または２−１４がチェックされてブローカレス探索ネットワークＢＮに公開された場合、他のプレイヤーＰはその解釈記号Ｋを内部のキャッシュに自由に取り込むことができる。そして、他の解釈記号Ｋ（以下、Ｋ−ａという）を取り込んだプレイヤーＰは、自作の解釈記号Ｋ（以下、Ｋ−ｂという）の表現項２−２に、解釈記号Ｋ−ａとの関係を示す関係演算子および解釈記号Ｋ−ａの一意識別子を記載し、解釈記号Ｋ−ａと共にブローカレス探索ネットワークＢＮに公開する。この関係演算子および解釈記号Ｋを表現項２−２に記載することを解釈記号の関係付けという。この場合、関係演算子として、例えば、
related…関係あり
subclass…サブクラスに属する
等がある。
なお、他のプレイヤーＰから取得した解釈記号Ｋ−ａを公開することを再公開という。
【００８１】
そして、データ検索を行うプレイヤーＰが、例えば、解釈記号Ｋ−ａに関連する情報を得たいと思った時は、アクセス情報に「related Ｋ−ａ」と記載して検索する（イベント送信する）。これによって、解釈記号Ｋ−ｂを公開するプレイヤーＰが応答する。この動作によって、関連ある情報の検索が可能となる。一方、解釈記号Ｋ−ｂを先に発見した場合、同解釈記号ｋ−ｂの表現項２−２に記載された解釈記号Ｋ−ａの一意識別子によって探索することで、解釈記号Ｋ−ａにアクセスすることができる。
【００８２】
（６）解釈記号Ｋの分類
図８はプレイヤーＰによる解釈記号Ｋの保持と再公開およびこれに関連するプレイヤーＰの諸機能および解釈記号Ｋのプレイヤー内部での分類に関する説明図である。プレイヤーＰは、解釈記号Ｋに対して探索、取得、公開、記憶管理、検査を行なう主体であり、内部の諸機能を利用してこれらを実現する。探索、取得、公開は主としてブローカレス探索ネットワークＢＮに対するアクセスと、解釈記号Ｋのアクセスに対する反応によって行なわれる。検査はブローカレス探索ネットワークＢＮを通して記号取得された解釈記号Ｋが保存される迄の間にドメインＤ内の規約などに適合しているか検査を行ない、不適当なものを排除する事で行なわれる。記憶管理は、プレイヤーＰが取得した解釈記号Ｋを保持、消去する判断を、プレイヤーＰの記憶容量と解釈記号Ｋに記述された公開等に関する指定および解釈記号Ｋ間の関連付けを勘案して自動的に行なうものである。内部記憶領域においては、解釈記号Ｋの記号取得以外のアクセスがブローカレス探索ネットワークＢＮを介した場合と同様に可能であって、解釈記号Ｋの保存時に表現項内容を用いて検索情報を別に作成することにより実行される。解釈記号Ｋの削除時には対応する検索情報も削除される。また、アクセスに対する応答は解釈記号Ｋの機能として行なわれる。
【００８３】
図８において、プレイヤーＰの記憶管理の概略を説明する。プレイヤーＰは解釈記号Ｋを分類して解釈記号Ｋの保持を行なう。分類の基準は３つある。その解釈記号Ｋを自身が作成したものか、それとも外部から取得したものか、その解釈記号Ｋが公開許可フラグを立てているかいないか、更に外部から入手した解釈記号Ｋが自作の解釈記号Ｋと関連付けられているかどうかである。これによって分けられた解釈記号Ｋの保持に関する４つの分類を図中の分類番号に即してそれぞれ説明する。
【００８４】
○分類１：自作かつ公開不許可。自身が参照などした複数の解釈記号Ｋに対して自分のみで使用するために作成した関係付けを行なった解釈記号Ｋや作成中でまだ外部に公開する前に自身のみでテストするために保持している解釈記号Ｋがここに分類される
○分類２：外部より取得しかつ公開不許可。公開不許可フラグが立っていない解釈記号Ｋを通信負荷の軽減のために自身でのみ利用する際に用いる。
分類２−ａ：自作解釈記号との関連付けされている。
分類２−ｂ：自作解釈記号との関連付けされていない。
○分類３：自作かつ公開許可。自身が外部に対して公開している解釈記号Ｋのために用いる。
○分類４：外部より取得しかつ公開許可。再配布許可フラグが立っている解釈記号Ｋを外部より取得した際にこの領域に分類する。
分類４−ａ：自作解釈記号との関連付けされている。
分類４−ｂ：自作解釈記号との関連付けされていない。
【００８５】
分類３、４に分類された解釈記号Ｋは自動的にそれぞれの表現項の内容をブローカレス探索層の被検索情報に翻訳して登録し、外部からのアクセスを受け付ける。分類１、２に分類された解釈記号はブローカレス探索層に登録せず外部からのアクセスは受け付けない。ただし、プレイヤーＰを利用している上位アプリケーションからの探索は受け付ける。
【００８６】
また、プレイヤーＰは、図９に示すように、自作の解釈記号Ｋが関連付けしている他の解釈記号Ｋのテーブルを保持し、新たな関係付けが発生した場合に解釈記号Ｋの分類を行ない、また、関係付けに関する一意識別子をキーワードにした問い合わせに対してそれが関連付けられているかどうかについての応答を行なう。この機能と、記号取得時および自作記号との関連付けの変更の都度行なわれる記憶されている解釈記号の再分類によってキャッシュ領域の内部で分類２−ａと分類２−ｂおよび分類４−ａと分類４−ｂの区別をそれぞれ行なうことが可能になる。なお、図９における「要求元」とは上位APLである。また、図９のテーブルに登録された解釈記号Ｋは、ガベージコレクト（記憶容量の確保のために不要な解釈記号を削除すること）によって消去されることがないようになっている。
【００８７】
（６）解釈記号Ｋの管理
図１０によって、図９中で説明した関連付け管理機能の実現方法を説明する。関連付け管理機能は自作の解釈記号ＫのプレイヤーＰにおける登録時に発生する生成要求および登録抹消時に発生する削除要求を要求元APLより受け付け、これにより内部の関係付け管理テーブルのエントリを管理して自作の解釈記号Ｋに関連付けられた解釈記号Ｋの情報を管理すると共に、管理テーブルの変化に応じて必要な通知や要求を他の機能に対して行なう。また、関連する内部の他機能からのエラー通知を要求元APLへ転送する。生成、削除の要求およびエラー通知に対するそれぞれの処理のフローチャートを図１０（ａ）〜（ｃ）に示す。
【００８８】
要求元APLから生成要求を受け取ると（ステップＳ１）、関連付け管理機能は関係付け管理のテーブルおよびキャッシュ領域の解釈記号Ｋの検索を行う（ステップＳ２）。詳しくは、
(a)関係付け管理テーブルをチェックして既に今回の関係付けを行なう際の関係先の解釈記号Kが別の関係元から関係付けられていないかどうかについて検索する。なお、関係元とは自作のこれから登録、公開しようという解釈記号Ｋであり、関係先とは関係元から関係付けられている相手の解釈記号Ｋである。この検索の理由は、既に関係付けられている関係先はガベージコレクトの対象とならないので存在していることがほぼ間違いないからである。
(b)上記(a)において既存の関係付けが存在しなかった場合にキャッシュ領域に実際に関係先たる解釈記号Ｋが保持されている事の確認を行なう。(a)において既に存在しているならば(b)を行なう必要はない。
【００８９】
次に、関係先の解釈記号Ｋが存在したかどうか判断する（ステップＳ３）。そして、判断結果が「ＹＥＳ」（存在している）の場合は、関係付け管理テーブルに関係元、関係先、要求元（APLのプロセス番号など）を記述した行エントリを一つ追加する。そして、処理終了をAPLに報告する。一方、ステップＳ３の判断結果が「ＮＯ」（存在しない）であった場合は、解釈記号分類機能に新規関係付けの作成が行なわれた事を報告する。解釈記号分類機能はこの報告を受けて、キャッシュ内に存在しないことを確認した上で一意識別子を指定した解釈記号Ｋの取得を行ない、成功すればその成功を報告し、失敗すればその失敗の内容をエラーとして報告する（ステップＳ５）。なお、この処理は図１２においてさらに説明する。
【００９０】
関連付け管理機能は、解釈記号分類機能よりの通知を判断し（ステップＳ６）、解釈記号Ｋの取得が成功した通知であれば、関係付け管理テーブルに新たな行エントリを作成する（ステップＳ７）。また、解釈記号Ｋの取得に失敗した旨の通知があれば、エラーの内容をAPLに通知して終了する。
【００９１】
次に、要求元APLから削除要求を受けると（ステップＳ８)、関連付け管理機能は関係付け管理のテーブルの検索を行う（ステップＳ９）。そして、削除要求があった関係付けがテーブルのエントリに存在した場合は（ステップＳ１０が「ＹＥＳ」）、その行の削除を行う（ステップＳ１１）。また、存在しなかった場合は、解釈記号分類機能へ新規関係付け削除報告を行なう（ステップＳ１２）。解釈記号分類機能はこれを受け、図１３に記載されるように、解釈記号Ｋが存在していれば所用の領域になるように処理し、存在していなければそれはそれで構わないのでやはり処理終了を返す。なお、この処理はキャッシュ領域を増やす処理ではないので、削除要求から解釈記号分類機能へ要求された処理にはエラーは発生せず、エラーの通知もない。
また、関連する内部の他機能からのエラー通知を受けた場合は（ステップＳ１３）、エラー通知の種類を判断し（ステップＳ１４）、その判断結果（キャッシュ容量不足または取得失敗）を要求元APLへ転送する。
【００９２】
（７）解釈記号Ｋの分類処理
次に、図１１〜図１４において解釈記号Ｋの分類機能について説明する。解釈記号Ｋの分類機能は、上位アプリケーションと関連付け管理機能を要求元とし、要求に応じて自作ないし外部から取得した解釈記号Ｋを内部の記憶領城中に分類して記憶し、また要求に応じて分類を変更する。これらの処理の間に必要ならば解釈記号Ｋの取得を解釈記号探索／取得機能に要求する。また、プレイヤーＰの記憶容量の制約から必要に応じて不要な解釈記号Ｋを削除し記憶容量の空きを作る。さらに記憶領域中の公開が許可されている解釈記号Ｋをブローカレス探索ネットワークＢＮに対する登録を行なわせる。
【００９３】
これらを行なうために解釈記号分類機能は、自作と取得した解釈記号Ｋとの関係付けと、公開に関するフラグに応じて分類する機能（図１１）、関係付けの変更を通知されたことにより記号の分類を変更する機能（図１２、図１３）、不要な解釈記号を削除する機能（図１４）、および公開が許可されている解釈記号を下位ブローカレス探索層に対して登録を行なう機能（図１５）を有する。以下の説明において、プレイヤーＰは解釈記号Ｋを消去する必要が生じた際、外部から取得し自作の解釈記号Ｋと関係付けられていない解釈記号（図８の分類２−ｂならびに分類４−ｂ）を消去すると前提する。これは自作の解釈記号Ｋと共に関係付けを行なった解釈記号Ｋを共に公開するために必要な動作である。また、ブックマークをこの動作を用いて実現することも可能である。
【００９４】
図１１は自作ないし取得され、新たに記憶領域に保存される解釈記号Ｋを関係付けと公開に関するフラグに応じて分類する機能を説明するためのフローチャートである。新たに記憶領域に保存される解釈記号Ｋが分類機能に対して入力された際、まず、記憶領域（キャッシュ領域）にその解釈記号Ｋが既にあるか否かをチェックし（ステップＳａ１、Ｓａ２）、あった場合は入力された解釈記号Ｋを破棄する。なかった場合は、新規取得をAPLに報告した後（ステップＳａ３）、記録領域の空き容量（以下記憶容量という）をチェックし（ステップＳａ４）、応答たる残容量から解釈記号Ｋが保存可能かどうかを判定する。保存可能でない場合、キャッシュクリアを実行し（ステップＳａ５）、記憶容量を確保する。ここで記憶容量が十分に確保できない場合はエラーメッセージを出して処理を終了する（ステップＳａ６が「ＮＯ」）。
【００９５】
記憶容量が確保できた場合、解釈記号分類機能は、次に、外部から取得した解釈記号Ｋであるか否かを判断し（ステップＳａ７）、判断結果が「ＮＯ」であった場合は公開許可フラグが立っているか否かを判断する（ステップＳａ）。そして、判断結果が「ＮＯ」の場合は分類１へ分類し、「ＹＥＳ」の場合は分類３へ分類する。また、ステップＳａ７の判断結果が「ＹＥＳ」の場合は、次に、公開許可フラグが立っているか否かを判断し、「ＹＥＳ」の場合は、関係付け管理機能へ問い合わせを行い（ステップＳａ１０）、自作の解釈記号に関連付けられている場合は分類４−ａへ、関連付けられていない場合は分類４−ｂへ分類する（ステップＳａ１１）。また、ステップＳａ９の判断が「ＮＯ」の場合は、関係付け管理機能へ問い合わせを行い（ステップＳａ１２）、自作の解釈記号に関連付けられている場合は分類２−ａへ、関連付けられていない場合は分類２−ｂへ分類する（ステップＳａ１３）。
また、新規に取得した解釈記号Ｋである場合、取得を要求したAPLに報告する。これは既に取得した事のある解釈記号Ｋの周囲を連鎖探索して新しい解釈記号Ｋを発見した際などにAPLに報告しこれを利用して新しい情報を取得するのに用いる。
【００９６】
図１２は新たな関係付けが作成された際の既存の解釈記号Ｋを再分類する機能を説明する。新たな関係付けの発生は関係付け管理機能から通知される。解釈記号分類機能はこの通知を受けて、図１２のフローチャートに従い、まず、既に保存している解釈記号Ｋを探索して、入力された解釈記号Ｋを発見し分類変更を行なう（ステップＳｂ１〜Ｓｂ４）。これは関係付けを行なう解釈記号Ｋは既に取得している可能性が高いからである。未取得か、あるいは取得されていたがすでにキャッシュクリアによって消去されるかにより保存されていない解釈記号Ｋを関係付けた場合、解釈記号分類機能は解釈記号探索／取得機能に対して一意識別子を指定して解釈記号Ｋの取得を要求する（ステップＳｂ５）。この取得が成功した場合（ステップＳｂ６が「ＹＥＳ」）、新たに入力された解釈記号Ｋは図１１で説明される解釈記号の新規取得時の分類機能によって分類される。取得が失敗した場合エラーを要求元に対して通知する（ステップＳｂ７）。これらの処理の終了後、新たな入力待ちの状態にはいる。
【００９７】
上記の処理において、一意識別子を指定した解釈記号Ｋの取得の失敗は以下の可能性がある。
(a)これを公開／再公開しているプレイヤーＰが発見できなかった。
(b)もともと該当する解釈記号は再配布を不許可としており取得不能であった。
(c)キャッシュ領域が一杯であった。このエラーは図１２での取得処理が図１１での解釈記号Ｋの入力処理を呼び出し、この中で発生したガベージコレクトでなお記憶領域が確保できなかった場合に可能性がある。
【００９８】
(a)の場合、解釈記号分類機能はとりあえずエラーを関係付け管理機能に通知し、再取得を試みようとする。これを受けた関係付け管理機能は再公開できないが、いずれ再取得に成功することに期待する。APLには一応この旨をエラーとして報告する。(b)の場合、解釈記号はもともと取得不能である旨をエラーとして関係付け管理機能に報告し、関係付け管理機能はAPLにこの旨をエラーとして報告する。(c)の場合、解釈記号Ｋの保持そのものが難しくなっているので、関係つけ管理機能にその旨を通知し、これを介してAPLに対して自作解釈記号Ｋを削除するなどの処置を促す。(a),(b)どちらのエラーも致命的エラーではなく、単にプレイヤーＰがその後どう動くかを示すものであって、プレイヤーＰは動作を続行する。(c)の場合プレイヤーＰは解釈記号の取得などの動作を一部中止して関係付け管理機能を介してAPLに対し自作解釈記号の記憶領域からの削除などを要請する。
【００９９】
図１３は関係付けが削除されたことが通知された際に、既存の解釈記号Ｋを再分類する機能を説明するためのフローチャートである。自作の解釈記号Ｋは分類を変更する必要はなく（ステップＳｃ１が「ＹＥＳ」）、外部から取得し、かつ、関係付けが削除された場合（ステップＳｃ２が「ＮＯ」）に、解釈記号Ｋの分類の変更を行なう（ステップＳｃ３）。この際、関係付けが存在する分類に解釈記号か存在しなければそのまま処理を終了する。
【０１００】
図１４はキャッシュ領域の管理機能を説明するためのフローチャートである。容量チェックの要求に対しては、記憶容量と新規解釈記号Ｋの容量を比較して残容量が大きければＯＫを、そうでなければErrorを出力する。キャッシュクリア要請に対しては、分類２−ｂ,４−ｂの解釈記号を消去し、あらたに残容量を計算する。
図１５は分類３、４に属する解釈記号Ｋをブローカレス探索ネットワークＢＮに登録する機能を説明する。ブローカレス探索ネットワークＢＮは複数の種類があり得るので、この機能はブローカレス探索ネットワークＢＮの種類毎に存在する。図１５ではSIONetを前提として記述した。
【０１０１】
まず、公開された解釈記号Ｋの表現項２−２を入力し（ステップＳｄ１）、フィルタと一意識別子の応答用対応表にエントリを追加する（ステップＳｄ２）。次に、表現項２−２の内容を検査し（ステップＳｄ３）、必須項目が存在するか否かをチェックする（ステップＳｄ４）。そして、存在していなかった場合は、デフォルト値で埋められるか否かをチェックし（ステップＳｄ５）、埋められない場合はＥｒｒｏｒ通知を行う。また、必須項目が存在する場合またはデフォルト値で埋められた場合は、表現項２−２の内容をブローカレス探索ネットワークＢＮのフィルタ情報の書式に変換し（ステップＳｄ６）、エンティティＥに対して登録依頼を行う（ステップＳｄ７）。エンティティＥから登録成功の通知がなかった場合はＥｒｒｏｒ通知を行う（ステップＳｄ８）。
【０１０２】
上述した各機能によりプレイヤーは自作解釈記号Ｋに関係付けられた解釈記号Ｋを消去せず、かつ、記憶容量を有効に使うために関係付けられていない解釈記号Ｋを消去することを自動的に行い、関係付けられた解釈記号Ｋによって記憶容量が不足した場合を除いて記憶容量の詳細な管理を上位APLから隠蔽して自動的に実行することおよび自作ないし取得した解釈記号Ｋを自動的に関係つけを管理し公開することが可能となる。
【０１０３】
（８）解釈記号Ｋへのアクセスに対するプレイヤーＰの応答
図１６はブローカレス探索ネットワークＢＮに登録した情報にヒットした外部よりのアクセスをプレイヤーＰが内容により振り分け応答を行なう最初の段階についてのフローチャートである。まず、フィルタ３−３（図５）にヒットしたアクセス（一意識別子の一部一致）は、識別子確認用のアクセスであるかが判定され（ステップＳｅ１）、もしそうであるなら部分一致した事を通知する応答が行なわれる（ステップＳｅ２）。それ以外の種別のアクセスである場合には廃棄する。
【０１０４】
フィルタ３−１にヒットしたアクセスは、解釈記号Ｋの内容に対するアクセスとして扱われる。まず、連鎖探索か否かが判定され（ステップＳｆ１）、連鎖探索の場合はこれに応答するルーチン（図１７〜図２０）へ移行する。詳細は次項で述べる。連鎖探索ではない場合は、アクセス中に記述された応答条件評価が実行される（ステップＳｆ２）。応答条件を満たさなければ解釈記号Ｋはアクセスに対して応答しない（ステップＳｆ３が「ＮＯ」）。応答条件を満たした場合は（ステップＳｆ３が「ＹＥＳ」）、アクセス種別が判定され、次の各アクセス種別に基づいた応答を解釈記号Ｋに保持された情報から作成する。
【０１０５】
○単純参照：一意識別子を応答内容として応答し（ステップＳｆ５）、アクセスカウントを＋１する（ステップＳｆ６）。
○解釈項参照：表現項内容と解釈項内容を応答内容として応答し（ステップＳｆ７）、アクセスカウントを＋１する（ステップＳｆ８）。
○メッセージ：上位ＡＰＬに通知し（ステップＳｆ９）、アクセスカウントを＋１する（ステップＳｆ１０）。
○記号取得：ポリシーに応じて解釈記号Ｋ１（図３）またはＫ２（図４）を応用内容として応答し（ステップＳｆ１１）、アクセスカウントを＋１する（ステップＳｆ１２）。
○対象取得：対象項あるかの判断を行い（ステップＳｆ１３）、判断結果が「ＮＯ」であれば処理を行わない。「ＹＥＳ」であれば、対象項は展開か否かを判断する（ステップＳｆ１４）。なお、展開については後に説明する。この判断結果が「ＮＯ」であれば、対象項内容と一意識別子を応答内容として応答し（ステップＳｆ１５）、アクセスカウントを＋１する（ステップＳｆ１６）。また、ステップＳｆ１４の判断結果が「ＹＥＳ」であれば、一意識別子と対象項の記述に従って展開した検索キーワード群を応答し（ステップＳｆ１７）（図２２参照）、アクセスカウントを＋１する（ステップＳｆ１８）。
○評価参照：評価の種別についてチェックし（ステップＳｆ１９）、解釈項、対象項にそれぞれ対応する評価（図３の符号２−５または２−７）と一意識別子を応答する（ステップＳｆ２０）。
○未知の種別：処理を行わない。
なお、上述した各場合においてアクセスカウンタは図３の符号２−１７または２−１８である。
【０１０６】
（９）連鎖探索
連鎖探索とは、次のような連鎖による情報探索をいう。いま、プレイヤーＡが連鎖探索を行う場合、アクセス情報に次の条件を記載してブローカレス探索ネットワークＢＮに流通させる。
連鎖条件
応答条件
最大連鎖数
その例を次に記載する。
連鎖条件：表現項２−２または解釈項２−３にアクセス情報に記載された単語リストの１０個の単語の内５個以上がある場合、次のプレイヤーへ送る。
応答条件：表現項２−２または解釈項２−３にアクセス情報に記載された単語リストの１０個の単語の内７個以上がある場合、発信元へ応答する。
最大連鎖数：５（６以上プレイヤーの連鎖を行わない）
【０１０７】
連鎖探索を行うプレイヤーＰは上述した条件を記載したアクセス情報をブローカレス探索ネットワークＢＮにおいて、自らの解釈記号と関連付けされた解釈記号を公開しているプレイヤーＰへ送信する。そのアクセス情報を受信したプレイヤーは、まず、応答条件を評価し（図１７）、次に、連鎖条件を評価する（図１８）。そして、応答条件を満たしていた場合は発信元へ応答し、連鎖条件を満たしていた場合は、自らの解釈記号と関連付けされた解釈記号を公開している次のプレイヤーへアクセス情報を送信する。この時、最大連鎖数を「１」減算する。ここで、連鎖する次のプレイヤーは、自解釈記号が関連付けした解釈記号を有するプレイヤーでも、自解釈記号が関連付けされた解釈記号を有するプレイヤーでもよい。
【０１０８】
図１７は連鎖探索においてプレイヤーＰが応答するか否かの判定およびその後の応答について説明するフローチャートである。連鎖探索のアクセス情報には、複数のアクセス情報間で重なる確率が十分に小さいアクセス情報の識別子（以下問い合わせ識別子）が付随している。これは連鎖探索の余計な送信や二重の応答を防ぎ、大量の連鎖探索の到来時に事態を鎮静化させるために用いられる。この詳細は図１９、図２０で説明する。
【０１０９】
図１７において、まず、応答に関する条件判定を行なう（ステップＳｇ１、Ｓｇ２）。応答条件を満たしたアクセスに対しては通常のアクセス同様にアクセス種別を判定し（ステップＳｇ３）、判定結果に応じて次の応答を行ない、次いで、連鎖判定へ移る。応答条件を満たさないアクセスに対しては応答を行なわずに連鎖判定へ移る。
○単純参照：一意識別子を応答内容として応答し（ステップＳｇ４）、アクセスカウントを＋１する（ステップＳｇ５）。
○解釈項参照：表現項内容として解釈項内容を応答内容として応答し（ステップＳｇ６）、アクセスカウントを＋１する（ステップＳｇ７）。
○記号取得：ポリシーに応じて解釈記号Ｋ１またはＫ２を応答内容として応答し（ステップＳｇ８）、アクセスカウントを＋１する（ステップＳｇ９）。
○対象取得：対象項あるかを判断し（ステップＳｇ１０）、判断結果が「ＮＯ」の場合はなにも処理をせずに連鎖判定へ進む。「ＹＥＳ」の場合は対象項内容を応答内容として応答し（ステップＳｇ１１）、アクセスカウントを＋１する（ステップＳｇ１２）。
【０１１０】
図１８は連鎖判定とその後の連鎖探索の続行について説明するためのフローチャートである。プレイヤーＰは連鎖条件評価を行ない（ステップＳｈ１）、連鎖条件を満たさないものは次のプレイヤーＰへの送信を中止する（ステップＳｈ２が「ＮＯ」）。連鎖条件を満たすものについては（ステップＳｈ２が「ＹＥＳ」）、新たに連鎖のためのアクセス情報を元のアクセス情報の内容を一部継承し必要な情報を変更して作成し（ステップＳｈ３）、送信する（ステップＳｈ４）。
【０１１１】
図１９は応答条件評価と連鎖探索の抑制方法を説明する。応答判定から応答条件評価が呼び出されると、まず、過去の問い合わせ識別子を一定数保持すると共に対象となった解釈記号Ｋの一意識別子およびこれに対する応答の記録をStatusと対にして保存する問い合わせ識別子テーブルを検索し（ステップＳｉ１）、存在しているかどうかをチェックする（ステップＳｉ２）。既に存在していれば応答済である事が確実なので応答はしない。存在しない場合、初めて受け取ったアクセス情報であるか、あるいは既に応答済だが問い合わせ識別子テーブルが多数の問い合わせに対して溢れたため可能性がある。これを区別することはできないので、この場合はさらに応答条件式の評価次第で応答を行なう（連鎖探索でこの問題に対しては対策する）。問い合わせ識別子テーブルに該当行が存在しなければ、問い合わせ識別子テーブルに行を追加する（ステップＳｉ３）。この時、問い合わせ識別子テーブルの容量をオーバーするようならもっとも古い行を削除する。また、この際のStatusは０を指定する。これは応答判断を行なうがまだ転送はしていない事を意味する。その後でアクセス情報中に記載された応答条件式の評価を行なう（ステップＳｉ４）。評価結果が応答すべしであるならば応答ＯＫを応答判定に返す（ステップＳｉ５が「ＹＥＳ」）。そうでなければ応答不要を応答判定に返す（ステップＳｉ５が「ＮＯ」）。
【０１１２】
図２０は連鎖探索条件判別と連鎖探索の抑制方法を説明するためのフローチャートである。連鎖探索条件判別は連鎖判定から呼び出され、転送ＯＫか不要かを応答する。連鎖探索条件判別は呼び出されると、まず、問い合わせ識別子テーブルを検索する（ステップＳｊ１）。この時問い合わせ識別子テーブル中に該当行が存在し、かつ、Statusが０である場合にのみ転送条件判定に進み（ステップＳｊ２が「ＹＥＳ」）、それ以外の場合は転送不要である（ステップＳｊ２が「ＮＯ」）。該当行が存在しStatusが１である場合とは、既に転送済みであり、従って同じ転送をする必要はない。該当行が存在しない場合とは処理の順序からすると大量の問い合わせの殺到により問い合わせ識別子テーブルが溢れたと考えられる。この時、この問い合わせの転送を見合わせる事で過剰なトラフィックの発生を避ける。この後テーブルの当該行のStatusを１に変更し（ステップＳｊ３）、応答条件式を評価して（ステップＳｊ４）、転送許可を返すか否かを判断する（ステップＳｊ５）。
【０１１３】
（１０）フィルタ３−２のヒットに対するプレイヤーＰの応答
図２１はフィルタ３−２（図５）にヒットした場合のアクセスに対するプレイヤーＰの応答決定過程をフローチャートで示す。アクセス種別が判定され（ステップＳｋ１）、それぞれの種別に対応して次の応答を行なう（ステップＳｋ２）。図２１の応答は主として解釈記号Ｋに対する通知など解釈記号Ｋの内容というよりも統計情報関係のアクセスであることが多い。このため、解釈記号Ｋの内容に対するアクセスの統計を行なうアクセスカウンタの増加は行なっていない。
【０１１４】
○対象項への評価の通知：対象項への評価（図３の符号２−７）へ追加し（ステップＳｋ３）、次いで、分類３の解釈記号か否かを判断し（ステップＳｋ４）、判断結果が「ＮＯ」の場合は処理を終了し、「ＹＥＳ」の場合は作者へ通知する（ステップＳｋ５）。
○解釈項への評価の通知：解釈項への評価（図３の符号２−５）へ追加し（ステップＳｋ６）、次いで、分類３の解釈記号か否かを判断し（ステップＳｋ７）、判断結果が「ＮＯ」の場合は処理を終了し、「ＹＥＳ」の場合は作者へ通知する（ステップＳｋ８）。
○修正通知：修正通知を認証（詳細は図３５）し（ステップＳｋ９）、認証Ｏ．Ｋか否かを判断する（ステップＳｋ１０）。そして、判断結果が「ＮＯ」の場合は破棄し、「ＹＥＳ」の場合は自作の関連する解釈記号を検索し、この一意識別子子と共に作者へ通知し（ステップＳｋ１１）、また、修正通知に記述された一意識別子を元に解釈記号を入手、認証し、キャッシュ領域へ保存する（ステップＳｋ１２）。
○評価参照：関連カウンタに加算する（ステップＳｋ１３）。
○評価参照：評価の種別をチェックし（ステップＳｋ１４）、解釈項、対象項に応じて、対応する評価と一意識別子を応答する（ステップＳｋ１５）。
○未知の種別：処理を行わない。
【０１１５】
（１１）対象項による展開
図２２は対象項２−４（図３）が展開を実行するものであった場合について説明する。この場合、対象項２−４内には展開式である事を示す内部表現と、展開式の情報が記述されている。この対象項２−４を有する解釈記号Ｋが対象取得アクセスを受けた時、アクセスの検索キーワード（複数も可）中の展開式の左辺にマッチするものを右辺の検索キーワードに展開して書き直した検索キーワードを作りこれを応答する。
いま、例えば、図２２に示すように、表現項２−２内にキーワードＣ、Ｅ、Ｆが記載され、対象項２−４内に[展開式Ｃ→Ｅ、Ｆ]が記載されていた場合、「Ａ、Ｂ、Ｃ，Ｄ」をキーワードとするアクセスに対し、「Ａ、Ｂ、Ｅ、Ｆ、Ｄ」なるキーワードを応答する。
【０１１６】
応答を受けたアクセス元のプレイヤーＰは展開されたキーワードを受け取ったことを上位APLに報告し、ここで一端処理を終了する。解釈記号Ｋが自動的に展開を行なうと、予想外に展開が広がり、トラフィックが増大するだけでなく、元のキーワードからずれて探索の精度が堕ちる可能性がある。そこで、展開毎に上位APLの判断によって再探索するかを判断させる方法を取っている。上位APLが展開されたキーワードを用いて再探索することを要求すると、改めて探索を行なって探索、アクセスを行なう。これにより、自身の知識にはなかったキーワードを用いて検索を行なうことが可能となる。
【０１１７】
（１２）連鎖探索に用いるアクセス情報
図２３は連鎖探索に用いるアクセス情報を示す図である。連鎖探索に用いるアクセス情報では、アクセス種別に連鎖探索であることが記述され、更に応答の方法について記述される。図の場合は記号取得である。Option記述フィールド中に連鎖条件が規定の書式で記述される。書式内には、連鎖条件の評価式と、これまで連鎖を行なってきた解釈記号の一意識別子が記述されている。連鎖条件の一例として、解釈記号Ｋの表現ないし解釈項２−３中に条件中に記述された単語がある個数以上使われていれば真であり連鎖するといった方法がある。解釈記号Ｋはこの連鎖条件を評価し、これが真である上でこれまで連鎖を行なってきた解釈記号の一意識別子リストに自身が無い事を確認した上で連鎖の判断を行なう。そして、アクセス情報中のKeyWord群表示フィールドを探索継続の判断を行なった解釈記号Ｋが保持する関係付けに書換え、Option領域に連鎖を行なってきた解釈記号Ｋの一意識別子に探索継続の判断を行なった解釈記号Ｋの一意識別子を付加するとともに連鎖の残り可能回数を１つ減らしたアクセス情報を作成し送出する。
【０１１８】
（１３）代表記号
図２４〜図２６は一群の解釈記号Ｋを代表する代表記号ＤＫと、その実現方法について説明するための図である。一群の解釈記号Ｋとは、作成に当たって一つの観点を共有した解釈記号のグループであり、これらの解釈記号Ｋは一群として観点を共有していることを代表記号ＤＫと特定の関連つけをすることで主張する。代表記号ＫＤは一群であることを認証する情報と、一群のリストを出力するなど一群を確認するための動作をするサービス（以下、認証APLという）へのアクセス情報を保持する。ユーザーは解釈記号Ｋを取得した後、この代表記号ＤＫを解釈記号中の記述から取得する。解釈記号Ｋの視点に興味を持ったユーザは、ある視点で情報を集めることを同じ一群にある解釈記号Ｋを取得することで行なう。また、これが悪意あるユーザによって勝手に付け加えられた解釈記号Ｋでないことを明らかにするために、解釈記号Ｋ中の認証情報（図３における電子署名２−６または２−８）と代表記号ＤＫ中の認証情報および認証APLを用いて認証を行なう。
【０１１９】
図２４は認証APL、代表記号ＤＫ、一群を構成する解釈記号Ｋの関係を示し、また認証APLの主要機能を示す。一群の解釈記号Ｋは「代表を意味する関係演算子＋代表記号の一意識別子」による関係つけを表現項２−２に表記することにより一群に属する解釈記号Ｋであることを表す。また、一群であることを確実に認証しようとする解釈記号Ｋは解釈記号内に電子署名を保持する。プレイヤーＰは特定の解釈記号Ｋが一群解釈記号Ｋの代表記号ＤＫであることを、一群に属する解釈記号Ｋが「代表を意味する関係演算子＋代表記号の一意識別子」という形で関係つけていることから、代表記号ＤＫの一意識別子を認識する。代表記号ＤＫの対象項２−４には、解釈記号Ｋを認証する認証APLへのアクセス方法か記述されており、解釈項には認証に用いられる公開鍵が記述されている。
【０１２０】
認証APLは同時に一群の解釈記号Ｋのリストを保持し、また、要求に応じてリストを出力する機能を有する。これは解釈記号Ｋ中に記述されている電子署名を用いて解釈記号Ｋが書換えられていないことを認証するためであり、また、書換えられていないことが保証された一意識別子を認証APLが把握して、一群の一つであることを認証するためである。これにより表現項２−２内に「代表＋一意識別子」を勝手に書くことで、一群に対して無関係な解釈記号Ｋの悪意の追加を行なわれたとしても、プレイヤーＰはこれを識別することができる。
【０１２１】
認証APLは、複数の群に対する構成リストと認証用の情報をそれぞれ保持し、これらを利用して解釈記号Ｋの認証およびリストの出力を行なう（図２５参照）。代表記号ＤＫの解釈項２−３中には何も記述されなくても良く、必要ならば代表記号ＤＫによって表される一群の属性に関する記述がなされてもよい。この属性としては、一群を作成した視点に関するテキストや一群を作成するのに用いたアプリケーションやアルゴリズムの説明、さらに必要であるならば一群を作成した作成者（複数、ニックネーム、連絡方法のみ等も可）などがあり得る。
【０１２２】
図２６は代表記号ＤＫと認証APLの関係、認証APLへの解釈記号Ｋの登録および認証の過程を説明する流れ図である。一群の解釈記号Ｋを作成しようとする時、解釈記号Ｋの作成者はまず電子署名を作成するための公開鍵と秘密鍵を作成する。そして、認証APLに対し一群の解釈記号Ｋの一意識別子のリストを作成するように依頼し、この時、公開鍵と秘密鍵がリスト生成依頼時に認証APL内で生成され、公開鍵が返される。次に代表記号ＤＫが作成される。代表記号ＤＫの電子署名以外の部分が作成されたら、認証APLに対してこれを送付してEntryの登録依頼を行ない、認証APLは電子署名を作成して付加するとともに、解釈項２−３中に公開鍵を付加して完成した代表記号ＤＫを返すとともに、認証対象として一意識別子をListに保存する。解釈記号Ｋの作成者はこの代表記号ＤＫをプレイヤーＰを介してドメインに公開する。
【０１２３】
続いて、解釈記号Ｋの作成者は一群をなす解釈記号Ｋの作成を開始する。一群をなす解釈記号Ｋは代表記号ＤＫとの特定の関連付けを表現項２−２内に記述している以外は通常の解釈記号Ｋと変わらない。この解釈記号Ｋを電子署名以外を記述した後に代表記号ＤＫの際と同様に、認証APLに送付してEntry登録依頼を行ない、同様の処理が行なわれて電子署名が記述され完成した解釈記号Ｋが返される。解釈記号Ｋの作者はこれをプレイヤーＰを介して公開する。以下、これを繰り返す事により一群の解釈記号Ｋが作成される。一群の代表たる代表記号ＤＫと認証APLの一群に対応するリストが作成されている限り、一群をなすと考えられる解釈記号Ｋを後から追加することは問題無い。
【０１２４】
一般のユーザは、プレイヤーＰを介してドメインにアクセスし解釈記号Ｋにアクセスする。ここでは簡単のためにプレイヤーＰが解釈記号Ｋを取得したこととする。プレイヤーＰは取得した解釈記号Ｋの表現項２−２を見てこれが一群に属している解釈記号Ｋであることを知り、かつ、この一群の代表記号ＤＫの一意識別子を知る。先に取得した解釈記号が一群に属していることを認証したい一般のユーザは、プレイヤーＰを介して代表記号ＤＫを取得して解釈項中の公開鍵を取得し、対象取得して対象項２−４の内容を取得し、認証APLへのアクセス方法を取得する。
代表記号ＤＫの解釈項から取得した公開鍵によっで解釈記号Ｋの電子署名を確認する事により該解釈記号Ｋが該代表記号ＤＫに代表される一群に属する事が明らかになる。また、代表記号ＤＫは対象項２−４が再配布不可である可能性が高い。これは認証ＡＰＬのアクセス先を必要に応じて変更する可能性が高いからである。これゆえ、代表記号ＤＫの対象項を取得する際には、代表記号ＤＫの解釈記号全体の電子署名２−８を取得してこれによる認証を行ない対象項が正当なものである事を確認した上で対象項内部の認証ＡＰＬへのアクセス先の情報を利用する。
【０１２５】
また、認証APLに対して、取得したアクセス方法を用い公開鍵で暗号化したデータを元にチャレンジ＆レスポンス方式を用いて認証APLが公開鍵と対になる秘密鍵を保持していることを確認する。一群に属している解釈記号Ｋのリストを取得したい場合には、認証APLへのアクセス先を取得し、認証APLが秘密鍵を保持している事を確認して正当な認証APLであることを確認した上でリストの取得要請を行なう。通常の認証の際にもこれを行ない、リスト中に該当する一意識別子が存在するかをチェックしても良い。この方法により、悪意のあるユーザないし偶然の一致により他の代表記号ＤＫと一意識別子が一致する代表記号ＤＫと認証APLを共に作成し、さらにこれで正当に認証した解釈記号Ｋを配布している場合以外は、ある解釈記号Ｋの一群性に関して保証することができ、かつ、この場合においても、ある認証APLにより保証されている解釈記号Ｋとそれ以外を区別することができる。
【０１２６】
（１４）解釈記号の一括取得
図２７〜図３２は一群を構成する解釈記号Ｋの一括取得の方法を示す。図２７では二種類の一括取得の方法をまず説明している。一括取得には大きく分けて２つの形態があり得る。一つは既に一括して一群の解釈記号Ｋを保持しているプレイヤーＰからまとめて取得する方法である。既に一括して一群の解釈記号Ｋを保持しているプレイヤーＰとは、記号の作者または既に一括取得を行なっているプレイヤーＰが挙げられる。この場合、一群の解釈記号Ｋの全てを取得してこれを確認する事ができる。もう一つの方法は不特定のプレイヤーＰに対して一群の記号に対する取得要請を行なう方法である。これは一群を規定する条件を検索キーワードとして解釈記号取得のアクセスを行なうことと同義である。
【０１２７】
さらに、一括取得した内容が最新のものであるかどうかについての確認には、図２８に示すように、３つの形態があり得る。作成元のリストと照合して全てを取得したことを確認した公式確認取得、一括取得元のリストと照合して全てを取得したことを確認した非公式確認取得、あるいは取得または確認が何らかの原因で未完了のまま終了したことを示す未完了取得である。一括取得の状態としては、これらに加えて現在取得動作を行なっている事を示す取得中を合わせた４つの状態がある。これらの遷移を図２８に示す。また、確認の形態を図２９に示す。
【０１２８】
ネットワークでの通信の効率性への考慮から、プレイヤーＰは、まず、既に一括取得を行なっていて、他のプレイヤーＰに対して一括取得の取得元になれることを表明しているプレイヤーＰを探し、ここからまとめて取得しようとする。プレイヤーＰは一括取得表示記号を公開することで一括取得の取得元となり得ることを表明する。図３０に一括取得表示記号の詳細を示す。表現項２−２には自身の一意識別子、一括取得対象たる記号の条件（通常は一群の代表記号ＤＫの一意識別子）、および取得状況と記号の最終更新時刻および解釈記号群の総量が記述されている。取得状況とは前述した４つの状態のどれに属するかを表明するものであり、解釈記号Ｋの一群の一括取得を希望するプレイヤーが複数の一括取得表示記号を探索した場合、もっとも条件の良いプレイヤーＰを選択するために用いるものである。対象項２−４には一括取得を行なうためおよび一括取得されている解釈記号の一意識別子のリストを取得するためのアクセス先が記述されている。プレイヤーＰはここにアクセスすることで一括取得および非公式確認を行なう。
【０１２９】
一括取得表示記号を探索できない場合、一括取得を望むプレイヤーＰは不特定のプレイヤーＰから一群の記号に対する取得要請を行なう。この時、全てを取得したという事を取得プロセスから確認できないから、不特定のプレイヤーからの取得要請はタイムアウトを契機に終了する。この後、代表記号ＤＫが発見できれば代表記号ＤＫのリストから不足した解釈記号Ｋを一意識別子で指定して取得する事が可能となるが、代表記号ＤＫ、一括取得表示記号の双方も発見できない場合、確認できず未完了のまま取得は終了する。この場合でもある程度収集した解釈記号を他のプレイヤーが一括取得する事はネットワークヘの負荷を考えると有益である場合が多いから、未完了の状態を表示して一括取得表示記号を公開することはできる。
【０１３０】
図３１に一括取得のプロセスのフローチャートを示す。まず、一定ホップ数での一括取得表示記号の探索を行い（ステップＳｌ１）、発見したか否かを判断する（ステップＳｌ２）。そして、発見できなかった場合は、一定範囲内に特定の一意識別子を代表記号とする解釈記号へ記号取得要求を行い（ステップＳｌ３）、一定時間経過後終了する（ステップＳｌ４）。以後、認識、表示プロセスへ進む。また、ステップＳｌ２において、Ｓｔａｔｕｓ未完了取得のみを発見した場合は、一括取得経過時間表示のある一括取得表示記号は存在するか否かを判断し（ステップＳｌ５）、判断結果が「ＮＯ」の場合は、取得記号数歳代の一括取得表示記号を選択する（ステップＳｌ６）。また、「ＹＥＳ」の場合は、一括取得経過時間の最小の一括取得表示記号を選択し（ステップＳｌ７）、次いで対象取得し一括取得プログラムへのアクセス方法を取得し（ステップＳｌ８）、次いで一括取得プログラムへアクセスし一群の解釈記号を取得する（ステップＳｌ９）。そして、認識、表示プロセスへ進む。
【０１３１】
また、ステップＳｌ２において、Ｓｔａｔｕｓ公式ないし非公式一括取得を発見した場合は、Ｓｔａｔｕｓ公式ないし非公式一括取得のうちから一括取得経過時間の最小の一括取得表示記号を選択し（ステップＳｌ１０）、次いで対象取得し一括取得プログラムへのアクセス方法を取得し（ステップＳｌ１１）、次いで一括取得プログラムへアクセスし、一群の解釈記号を取得する（ステップＳｌ１２）。そして、認識、表示プロセスへ進む。
【０１３２】
図３２に、上記処理の後の確認のプロセスのフローチャートを示す。一定ホップ数での対象項ありの代表記号一括取得表示記号の探索を行い（ステップＳｍ１）、発見したか否かを判断する（ステップＳｍ２）。そして、Ｓｔａｔｕｓ未完了取得のみを発見または発見できずであった場合は、未完了経過時刻を記述した一括取得表示記号を作成し公開する（ステップＳｍ３）。また、ステップＳｍ２において、解釈記号一括取得表示記号のみを発見した場合は、Ｌｉｓｔを取得して比較し（ステップＳｍ４）、一致したか否かを判断する（ステップＳｍ５）。そして、判断結果が「ＮＯ」であった場合は、不足した解釈記号の一意識別子の指定による解釈記号取得を行い（ステップＳｍ６）、過剰な解釈記号の廃棄および一意識別子のリスト作成と通知を行い（ステップＳｍ７）、そのリストを保持し（ステップＳｍ８）、そして、公式および非公式確認一括取得経過時間を一括取得表示記号のそれにあわせて一括取得表示記号を作成し公開する（ステップＳｍ９）。また、ステップＳｍ５の判断結果が「ＹＥＳ」であった場合は、リストを保持し（ステップＳｍ１０）、公式および非公式確認一括取得経過時間を一括取得表示記号のそれにあわせて一括取得表示記号を作成し公開する（ステップＳｍ１１）。
【０１３３】
また、ステップＳｍ２において、代表記号を発見した場合は、リストを取得して比較し（ステップＳｍ１２）、一致したか否かを判断する。そして、判断結果が「ＮＯ」の場合は、不足した解釈記号の一意識別子の指定による解釈記号取得を行い（ステップＳｍ１４）、過剰な解釈記号の廃棄および一意識別子のリスト作成と通知を行い（ステップＳｍ１５）、そのリストを保持し（ステップＳｍ１６）、そして、公式確認一括取得経過時間を代表記号のそれにあわせて一括取得表示記号を作成し公開する（ステップＳｍ１７）。また、ステップＳｍ１３の判断結果が「ＹＥＳ」の場合は、リストを保持し（ステップＳｍ１８）、公式確認一括取得経過時間を代表記号のそれにあわせて一括取得表示記号を作成し公開する（ステップＳｍ１９）。
上述したプロセスの後、一括取得表示記号を表示して一括取得のためのアクセスを受けるかどうかはプレイヤーＰのポリシーに依存する。
【０１３４】
（１５）ドメイン参加時のプレイヤーＰによる初期知識の取得
図３３はプレイヤーＰがドメインＤに参加した際に初期知識を受け取る過程を説明するための図である。あるドメインにプレイヤーＰが参加した際とは、あるドメイン用のプレイヤーＰが起動されてブローカレス探索ネットワークＢＮによる接続が行なわれた時点をいう。また、初期知識とは、ドメインＤ内で適用される通信の制限事項に関する規約、および、ドメインＤ内で最初に提示される意味体系が規定の書式で記述されたもののどちらかあるいは両方を意味する。この規約と意味体系の提示を行なえるのは、ドメインＤを最初に作ったプレイヤーＰである場合が通常であるが、これ以外の方法で提示される事もあり得る。これはドメインＤの管理を行なうプレイヤーＰの上位のAPLの定義と機能に従う。
【０１３５】
ドメインＤに参加したプレイヤーＰは、実装時に書き込まれている規定された初期知識の代表記号ＤＫを意味するWell-Knownな一意識別子によって、周囲のプレイヤーＰに対して探索を行なう。このWell-Knownな一意識別子は、後述する解釈記号Ｋに対する制限事項のデフォルトとしてあらかじめプレイヤーＰの実装時に記述されており、プレイヤーＰがドメインＤ内の規約を取得するために内部で使用する事のみ許可され、外部のAPLがプレイヤーＰを介してこの一意識別子を使用することは禁じられている。この一意識別子を持つ解釈記号Ｋは、ドメインＤで必要な初期情報を保持する一群の解釈記号Ｋの代表記号である。応答により代表記号ＤＫの存在を知った場合、前述した方法で一括取得を行ない一群の解釈記号Ｋを取得しこれらの解釈記号ＫからドメインＤにおける初期知識を得る。
【０１３６】
このドメインＤの初期知識は全てのプレイヤーＰが取得を行なおうとするものなので、仮にブロードキャスティングによる探索を下位レイヤで行なっていたとしても、プレイヤーＰは周囲に既に一括取得を行なったプレイヤーＰを発見できる可能性が高く、トラフィック的な問題を起こす可能性は少ない。また、かつてドメインＤに参加していたプレイヤーＰが離脱した後再参加する場合にも、プレイヤーＰはドメインＤの初期知識を改めて取得し従来の知識と比較してドメインの初期知識の一貫性や変更を知る。
【０１３７】
（１６）解釈記号およびアクセス情報のチェック
図３４は解釈記号Ｋに対する制限の実現方法を説明する。プレイヤーＰは前述したWell-Knownな一意識別子など実装時に記述されている制約事項と、前述した方法で取得したドメインＤ独自の制約事項を保持する。これらはプレイヤーＰが解釈できる書式で記述されている。プレイヤーＰはこれらの制約事項を元に、取得ないし公開する解釈記号Ｋに対して取得時ないし公開時に検査を行なう。検査によって制約事項に反した事が判明した解釈記号Ｋは放棄される（チャート（ｂ）参照）。また、アクセス情報の送出時にこの制約事項を元に検査を行ない、検索によって制約事項に反したものについてはアクセス情報の送出を中止し、送出を要求したAPLに対してエラー通知を行なう（チャート（ｃ）参照）。
【０１３８】
プレイヤーは前述した初期情報を収集した後、初期情報を構成する一群の解釈記号Ｋの解釈項２−３中に記述された情報から理解できる方法で記述されている制限事項を抽出し、内部チェック用情報に翻訳する。そして、これをチェック用情報テーブルＴｃに保存する（チャート（ａ）参照）。
その後、解釈記号Ｋを取得したさい、プレイヤーＰは取得した解釈記号Ｋをチェック用情報テーブルＴｃに記述された情報を元にチェックする。この時、チェック用情報テーブルの適用フィールドがなければそのエントリの評価は自動的に真となる。適用フィールドがあればそのエントリの評価式を適用し、評価式の真であれば次のエントリについて評価する。全てが真であれば解釈記号Ｋを記憶するプロセスに解釈記号を引き渡す。一つでも偽があれば解釈記号Ｋを放棄する。アクセス情報に関しても同様の評価を行ない、一つでも偽があればアクセス情報を放棄すると共にエラーメッセージをアクセス情報出力を要求したAPLに対して出力する。
【０１３９】
チェック用情報テーブルＴｃに記述される情報としては、特定の種類を除いた関係付けの個数を制限するもの、解釈記号Ｋの容量を制限するもの、解釈記号Ｋに特定の代表記号ＤＫへの関係付けを要求するもの等が挙げられる。図３４には上記の制限をそれぞれ記述したが、これらを記述するかどうかはドメインＤの管理方針に従う。
【０１４０】
（１７）修正通知
一度公開された解釈記号ＫはいずれかのプレイヤーＰによって取得されている場合が多く、したがって、修正はできない。しかし、その解釈記号Ｋを公開したプレイヤーＰが修正したいと思った場合は、修正解釈記号Ｋ’を公開する。他のプレイヤーＰが公開した解釈記号Ｋを取得したプレイヤーＰは、取得した解釈記号Ｋの修正解釈記号Ｋ’を探索することによって解釈記号Ｋの修正を知ることができる。
【０１４１】
図３５は修正通知アクセス情報および自動的に認証を経て修正された解釈記号Ｋ’の取得過程のフローチャートである。ここで、修正された解釈記号Ｋ’と元の解釈記号Ｋの一意識別子は異なっていて、修正された解釈記号Ｋ’は元の解釈記号Ｋに対して修正を意味する規定の関係付けを持っている。また、元の解釈記号Ｋと修正された解釈記号Ｋ’は共に代表記号ＤＫとの関係つけを表現項２−２内に記述し、一群である事を主張している。更に、修正通知アクセス情報内のOption記述フィールドに、規定の書式で電子署名が記述され、さらに修正された解釈記号Ｋ’の一意識別子も記述されている。修正通知による動作は図３５に記述されたような経路で最終的にはAPLへの通知を行なうが、その前にまず修正通知内に記述された電子署名と修正対象である解釈記号Ｋが代表として関係付けている代表記号ＤＫの解釈項２−３に記述された公開鍵を用いて電子署名の検証を行なう。これが成功すれば修正通知は代表記号の作者より出されたものとみなし、以後の処理へ進む。検証に失敗すれば修正通知は不正なものとみなして破棄する。
【０１４２】
次に、プレイヤーＰは、図３６に示すように、修正された解釈記号Ｋの取得を試みる。修正通知内に記述されている一意識別子に基づき記号取得を試み（ステップＳｎ１）、成功すれば検証に移り（ステップＳｎ２が「ＹＥＳ」）、失敗すれば時間をおいて規定の回数取得を試みる。最終的に取得に失敗すれば解釈記号Ｋの取得を放棄する（ステップＳｎ２が「ＮＯ」）。検証において、代表記号ＤＫが修正前の解釈記号Ｋと共通かを検査し（ステップＳｎ３）、共通でない場合はエラーとして破棄し（ステップＳｎ４が「ＮＯ」）、共通であった場合は（ステップＳｎ４が「ＹＥＳ」）、修正された解釈記号Ｋの代表記号ＤＫの解釈項２−３に記述された公開鍵と、解釈記号Ｋ中に記述された電子署名を検証し（ステップＳｎ５）、成功すればキャッシュ領域に保管する（ステップＳｎ６、Ｓｎ７）。失敗した場合は（ステップＳｎ６が「ＮＯ」）、エラー通知をこれに関連付けている解釈記号Ｋを作成したAPLに対して出力する。これは修正通知とこれに記述された一意識別子を持つ解釈記号Ｋの電子署名の検証結果が異なったことで、想定外の事態が生じた事をAPLに通知してこれらの解釈記号Ｋの扱いに注意すべきことを伝えるためである。
【０１４３】
（１８）ドメインの生成および消滅
図３７はドメインの生成と消去についてのべる。図２ではドメインＤヘの参加を説明した。ドメインＤの参加はブローカレス探索ネットワークＢＮヘの接続と、これに続くドメインＤの初期知識の取得によって行なわれる。ドメインＤからの離脱は同様にブローカレス探索ネットワークＢＮからの離脱によって行なわれる。これに対し、ドメインＤの生成とは、ブローカレス探索ネットワークＢＮに接続した際に与えられるドメインＤの初期情報を生成することである。これによってドメインＤ内での規約が決定されることになり、これを保持している間は、プレイヤーＰは仮にそのドメインＤにから一時的に離脱していてもそのドメインＤに所属している。あるドメインＤに属しているプレイヤーＰがこのドメインＤを完全に無用とみなし、もはやドメインＤに所属する意思が無くなれば、ドメインＤの規約を含む、ドメインＤにおいて取得ないし自作した解釈記号を消去する。これがドメインの消去である。
【０１４４】
上位APLの要求によりドメインＤの生成を開始したプレイヤーＰは、図３７のチャート（ａ）に示すように、ドメインＤの初期情報を作成する。この内容はドメインＤでの必要に応じて変わるが、少なくともWell-Knownな一意識別子を持ったドメインＤの初期情報を表す一群の解釈記号Ｋの代表記号ＤＫが作成される。さらに、プレイヤーＰはドメインＤに対応したキャッシュ領域と、これに関連したテーブルなどを作成し、ここにドメインの初期情報を表す一群の解釈記号（代表記号を含む）を保持して公開する。さらに、プレイヤーＰは下位のブローカレス探索ネットワークＢＮにおけるエンティティＥを生成する。ここでドメインが生成され参加可能になる。この時点でドメインを生成したプレイヤーＰは自身が生成したドメインＤに参加した事になる。
【０１４５】
ドメインを生成し参加可能としたプレイヤーは他のプレイヤーヘの参加を促すために下位ブローカレス探索ネットワークＢＮの機能を用いてドメインＤの存在を広告する。この方法はブローカレス探索ネットワークＢＮの機能に依存する。例えば、SIONetの場合は、あるノードで起動したエンティティＥの１つがベースイベントプレースと呼ばれる特定のイベントプレースに属し、ここでエンティティＥの属性公開という形でノード上の他のエンティティＥが参加しているイベントプレース名、イベントプレースの説明およびイベントプレースに参加するためのアクセス方法を公開することにより広告を行なう。また、他のブローカレス探索ネットワーク技術では、その技術に応じた方法を利用して生成されたドメインＤは自身の広告を行なう。プレイヤーＰを利用するAPLは他の方法を用いてドメインＤの存在を広告しても良い。例えば、ドメインＤに参加するためのアクセス先の情報をWebページなどに公開するといった方法があり得る。
【０１４６】
ドメインＤを生成したか参加したプレイヤーＰに対して、これを利用するAPLがドメインＤを無用とみなし所属する必要なしと判断した際、APLはプレイヤーＰに対して当該ドメインＤの消去を要求し、プレイヤーＰはドメインＤに対応したキャッシュ領域と関連するデープルなどを削除する。これによりプレイヤーＰはドメインＤを消去する（チャート（ｂ）参照）。あるプレイヤーＰがドメインＤを消去したとしても、他のプレイヤーＰがドメインＤに参加しているか所属している限りドメインＤは存在する。ドメインＤが完全に存在しなくなるのは全てのプレイヤーＰがドメインＤを消去した場合である。
【０１４７】
（１９）実施例と発明の効果
本発明の実施例を説明し本発明の効果を明らかにする。実施例としてある商店街の各商店によるサービスの広告を当初目的とした商店街ネットワークをP2Pネットワークとして作成し、その後、当初予定にはなかった周辺住民が参加する一時的なイベント情報を同じP2Pネットワーク内で流通させる場合を説明する。当初、商店街有志によって計画された商店街ネットワークは商店街の全ての商店主を網羅して計画されたものではない。また、もともと特定のサービスの提供のみを目的にして最適化して作られたものでもない。商店街有志は、自分たちの目的としては自身の提供するサービスを広告することであるが、必ずしもそれだけではサービスを広告する対象である周辺住民が提供するサービスの情報に対してアクセスしてくれないだろうと予想している。
【０１４８】
更に、商店街ネットワークヘのアクセスを増やすための広告を大々的に行なう費用もないので、場所、地域の共有という緩やかな属性に基づいた自由参加型のネットワークとして周辺住民からも情報を提供可能な形で運用する事で、ネットワークヘの参加者を増やし結果的に自身の当初目的たる各商店のサービス広告が達成できれば良いと考えている。このため、商店街ネットワークを計画した有志は、自分たちでは商店街のサービスを提供するための意味体系を共同で作成して提供することで自身が便利になるようにするが、周辺住民が参加して情報を提供することと、その際に周辺住民が独自に意味体系を作成して提供する事も可能とする。
【０１４９】
商店街ネットワークにおいては、参加する商店、商店やサービスの廃止、新設に対応できなければならない。そこで、当初は商店街内の位置の記述方法およびサービスの大まかな分類に関する意味の体系を解釈記号で体系的に定義する。この際有志は代表記号＃ａを作成して商店街内の基本的な意味の体系が一群である事を示し、意味の体系を個別の項目を解釈記号＃ａ−１という形で記述する。この解釈記号＃ａ−１は解釈記号＃ａを代表として関連つけて記述し、一群である事を主張する。代表記号＃ａはその解釈項中に認証のための公開鍵暗号と代表記号＃ａが商店街有志によって決められた商店街広告システムが準拠する用語集である事を記述する。各商店はまず商店街内の位置に関する記述方法を参照してこれに準拠して自店の位置を表現する。この表現は以降の解釈記号の表現項中に記述する。
【０１５０】
また、商店主は自身が作成した解釈記号の代表記号＃ｂを作成する。以降商店主が製作する解釈記号は代表記号＃ｂを代表として関係つける事になる。さらにサービスの大まかな分類に関する意味の体系の中で自店のサービスの近いものに関連つけて自店のサービスを解釈記号の表現項に記述した解釈記号＃b−１を作成し公開する。更に参加した商店主たちは自店が提供する個別のサービスを解釈記号＃ｂ−２...以降に作成する。これらは解釈記号＃ｂに関連つけられる。商店主の判断で解釈記号＃b−２...以降はサービスの中で特に広告したいものだけを作っても良い。解釈記号＃ｂ−２…以降の対象項中にはネットワーク越しに提供されるサービスならそのアクセス情報が、自店で提供されるサービスならこれを更に説明する写真、文書、Webページなどへのアクセス情報が記述される。他の店主たちも同様に自身の店舗およびサービスに関する解釈記号を作成してこれを公開する。
【０１５１】
プレイヤーは自分の機能を用いて解釈記号の一意識別子の一部についてドメイン内を探索し、既存の一意識別子の一部に重ならないことを確認した上で一意識別子を作成する。各プレイヤー中の公開されている解釈記号は自作、キャッシュによらず一意識別子の一部が一致した際には一致している事を通知し、通知されたプレイヤーは一意識別子が一致した事をもとにこの値を捨てて別の値を一意識別子の一部として試す。これによりプレイヤーの機能により一意識別子の一意性が確保される。これを利用する店主たちは一意識別子の値の決定に対して何かする必要はない。
【０１５２】
同時に店主たちは周辺住民がこのネットワークに参加した際に最初に周辺住民のアプリケーションに表示されるべき画面を定義する。本実施例の場合、商店街のサービスに関する分類を表示したもので、あるサービス分類を選択した場合、このサービス分類に関連した商店やサービス細目を検索し表示するメニュー画面である。最初にネットワークにアクセスした周辺住民はまずこのメニュー面面から商店やサービスなどを選び、解釈項や対象を参照してサービスの情報を得る。周辺住民は必要に応じて解釈記号をブックマークして商店街に対する自身の知識を集積する。ブックマークは非公開の自作解釈記号として扱われ、ブックマークされた情報はプレイヤーが保持し続ける事になり、以後はアクセスが容易になる。これにより、このネットワークに参加した周辺の住民は商店街で提供されるサービス分類をまず最初に表示されることでサービス分類毎に商店などの情報を得てネットワーク上で調べて商店街に出かける事が可能になり、かつ良く使う商店やサービスに関しては自身のプレイヤー中にその情報を保存する事ができるようになる。
【０１５３】
商店街において提供される複数のサービス中には関連するものがある。例えば、同日にある店で安売りされる食品と別の食品の組合せで一つの料理が作れる場合や近辺の店で行なわれる集客が見込まれるイベントに対して飲料販売、休憩のための喫茶店、入場券配布など関連したサービスがある場合である。このようなサービスを広告する解釈記号＃d−ｘに対し、他の店がこれに関連つけて解釈記号＃ｅ−ｙ等を公開することにより、集客の見込めるサービスに便乗して自店のサービスを広告する事が可能になる。このような解釈記号の連鎖により、このネットワークに参加した周辺住民は関連付けられたサービスをたどって商店街の特定のイベントに関連したサービスを見つけ利用する事が可能になる。
【０１５４】
また、この時解釈記号＃ｄ−ｘを公開するプレイヤーが故障などの理由で消失したとしても＃ｄ−ｙに関連つけた他の解釈記号を公開するプレイヤーが＃ｄ−ｘを再配布しているために、少なくとも解釈記号において記述されているイベントの内容に関しては周辺住民は知る事が可能になる。これにより関連付けが多く重要度の高い解釈記号に関しては冗長性を持って公開されることになり、参加する周辺住民がアクセス不能となる可能性が減少する。
【０１５５】
結成された商店街ネットワークはブローカレス探索ネットワークの上にある本発明を利用したプレイヤーの集合体であるドメインとして作成される。ドメインの作成、消滅、参加、離脱および広告については本発明の図３７において説明した方法で行なわれる。
商店街ネットワークに当初参加していなくても、新たに参加する商店は当初より参加してきた商店と同様に自店のサービス情報をサービス分類に関係つけて解釈記号として記述し公開したり、他店のサービスやイベントの情報と自店のサービスの解釈記号を関係つけて公開する事で自店のサービスを広告する事が可能になる。また、前述した重要性の高い解釈記号が冗長性を持って公開される事により、複数から引用され、キーワードとして使用されている解釈記号は作成した商店がネットワークから消滅ないし撤退しても使用され続ける事ができ、関連サービスを探す事ができる。これゆえ商店街ネットワークにおける商店の撤退、新規参加が起きた際にも従来のサービス分類に関する解釈記号の関連付けによって記述された商店街ネットワークの知識の重要な部分が利用され続ける事ができる。
【０１５６】
次に、商店街ネットワークに当初商店街の情報取得のために利用していた周辺住民が商店街にも関連のあるイベント情報を発信するために情報提供者として参加する方法を説明する。ここではイベントとして町内の夏祭を考える。夏祭は商店街を含めた住民全体のイベントであり、商店街の各店も協賛し関連するサービスを提供する。一方夏祭は一過性のイベントであるので、夏祭の情報を提供するドメインを新たに作成してこれに参加してもらうよりも既にあるドメインを利用する方が広告の効率の点で望ましい。そこで、夏祭イベントの実行メンバーは商店街ネットワーク中に夏祭イベントの情報を記述した解釈記号を作成し、この代表記号を商店街サービスの分類を示した解釈記号の代表記号に関連つけて公開することにより、商店街サービスに関連して夏祭イベントの情報が提供される事を示す。
【０１５７】
周辺住民ならび店主達はドメインヘの参加時に最初に与えられる商店街サービスの代表記号から連鎖探索を行なう事により、新規に獲得された解釈記号として夏祭イベントの存在を知る事ができる。このような連鎖探索はドメインヘの参加時に自動的に行なわれるようにAPLが要求しても良い。夏祭イベントの存在を知った店主は自身が夏祭に関連して提供しようとするサービスを新たに作るか、既存のサービスを夏祭に関連して提供するべく、既存のサービスと夏祭イベントの関連つけを行なう解釈記号を作成して公開する。一方夏祭イベントに参加したり関連したイベントを行なおうとする周辺住民も夏祭イベントに関連付けた解釈記号の作成を行ない公開する事で同じく情報を発信する事ができる。
【０１５８】
これらの解釈記号は周辺住民や商店主など複数のサービス提供者から提供されている。彼らには必ずしも共通の具体的な目的があるわけではなく、個別のサービス提供に関して地域的な緩やかな属性を特徴として持っている商店街ネットワークが便利であると判断したので解釈記号を公開する形でサービスの情報を提供しているだけである。商店街ネットワークのこのような性質から、提供される情報の質にバラツキがある事は当初から覚悟されねばならず、特に周辺住民にとって利益にならない情報や虚偽の情報を記述した解釈記号をばらまかれる事に対して対策が必要となる。この問題に対処して質の低い情報の氾濫
により商店街ネットワークが使用しずらいものになって参加者が減少することを防ぐために以下に列挙する対策を行なう。
【０１５９】
まず、商店街ネットワークでは各解釈記号に対する評価の共有を行なう。プレイヤーの上位APLはこの評価の統計値を利用して、評価の高いものを優先して表示する事が可能である。これにより情報が有用であると評価されている解釈記号の内容を優先して表示する事が可能になる。
また、商店街ネットワークでは一群の情報を代表する代表記号の作成と解釈記号に対する関係付けを行なう。これは代表記号の存在を必須条件としても良い。これにより、商店街ネットワーク内の多数の解釈記号を関係付けられた代表記号を手がかりとして解釈記号の作成の視点に応じた分類を行なうことができる。これによって質の低い情報に対してはこれを記述した代表記号に低い評価を与える事が可能となる。プレイヤーの上位APLはこの関連付けられた代表記号を基に有用な情報を与えてきた視点をあらわす代表記号に関連付けられた解釈記号を優先して表示する事が可能となる。既存の代表記号に自作の解釈記号を勝手に関連付けることでこの制約を逃れようとしても技術の詳細で記述した方法でこれを不当なものであると判定し排除する事ができる。
【０１６０】
さらに、特定の関係つけを除く関係付けの個数を制限する方法を用いる。ここでは１個だけに制限するとすれば、解釈記号のリンク関係はツリー上になる。ここで上位APLは解釈記号を連鎖探索などで複数取得し、内部で関係つけを解析した時、ツリーの上位にある情報の評価が低ければそこから辿れるツリーの下位に位置する解釈記号を自動的に低く評価することが可能となる。これにより上位APLは関係付けられた解釈記号のツリー情報中で有用な情報が存在する部分に集中してユーザに提示する事が可能となる。
【０１６１】
これらの技術を用いて商店街ネットワークを構築する事で、地域といった緩やかな属性を共有する情報を解釈記号を用いて自由に発信し、当初大まかなサービス分類のみが提示されていただけにも関わらず解釈記号間の関係付けによって商店街ネットワークにおいてきめ細かいサービス分類体系が自然に構成され、質の低い情報を評価の共有や規約による管理によって、ユーザに対して有用な解釈記号による情報を優先的に提示したり規約に反する解釈記号を徐々に排除といった穏やかな管理が可能となり、周辺住民を含めた多様な参加者による商店街ネットワークの適切な運営が可能となる。これは従来のブローカー的な技術に基づいて当初より目的を厳格に定義した上でこれを実現するためのオントロジ体系を構築し、これによる提供情報の分類と管理を行なう従来技術では困難な運営方法であり、本発明の有用性を示している。
【図面の簡単な説明】
【０１６２】
【図１】この発明の一実施の形態による情報流通／検索方法を適用した情報流通／検索システムのハードウエア構成を示すブロック図である。
【図２】同システムのソフトウエア構成を示すブロック図である。
【図３】解釈記号Ｋ１を示す図である。
【図４】解釈記号Ｋ２を示す図である。
【図５】解釈記号とブローカレス検索ネットワークＢＮとの関係を示す図である。
【図６】アクセス情報を示す図である。
【図７】解釈記号の関係付けを説明するための図である。
【図８】プレイヤーの機能を説明するための図である。
【図９】関連付け管理機能を説明するための図である。
【図１０】関係付け管理テーブルの生成、削除の過程およびエラー通知の処理を示すフローチャートである。
【図１１】解釈記号分類機能を説明するためのフローチャートである。
【図１２】解釈記号分類機能を説明するためのフローチャートである。
【図１３】解釈記号分類機能を説明するためのフローチャートである。
【図１４】キャッシュ領域管理方法を説明するためのフローチャートである。
【図１５】ブローカレス検索ネットワークＢＮのフィルタ登録の過程を示すフローチャートである。
【図１６】解釈記号へのアクセスに対する応答処理を説明するためのフローチャートである。
【図１７】連鎖探索の過程を説明するためのフローチャートである。
【図１８】連鎖探索の過程を説明するためのフローチャートである。
【図１９】連鎖探索における応答過程を説明するためのフローチャートである。
【図２０】連鎖探索における連鎖判定の過程を説明するためのフローチャートである。
【図２１】一意識別子を指定したアクセスに対する応答過程を示すフローチャートである。
【図２２】展開を説明するための説明図である。
【図２３】連鎖探索のアクセス情報を示す図である。
【図２４】代表記号を説明するための図である。
【図２５】認証APLの機能を説明するための図である
【図２６】代表記号およびそれに代表される集団に属する解釈記号に関わる処理を説明するための流れ図である。
【図２７】一括取得を説明するための図である。
【図２８】一括取得の取得状況を説明するための図である。
【図２９】一括取得の確認形態を説明するための図である。
【図３０】一括取得の解釈記号を示す図である。
【図３１】一括取得の過程を説明するためのフローチャートである。
【図３２】一括取得における確認、表示プロセスを説明するためのフローチャートである。
【図３３】プレイヤーがドメインに参加する際の処理を説明するための図である。
【図３４】解釈記号Ｋに対する制限の実現方法を説明するための図である。
【図３５】修正通知アクセス情報および自動的に認証を経て修正された解釈記号Ｋ’の取得過程のフローチャートである。
【図３６】修正された解釈記号Ｋの取得過程を示すフローチャートである。
【図３７】ドメインの生成、消去を説明するためのフローチャートである。
【符号の説明】
【０１６３】
Ｃ−１〜Ｃ−５…パーソナルコンピュータ
ＢＮ…ブローカレス検索ネットワーク
Ｄ…ドメイン
ＤＫ…代表記号
Ｅ…エンティティ
Ｋ、Ｋ１、Ｋ２…解釈記号
Ｐ…プレイヤー
ＳＲ…シェアードリンク
２−２…表現項
２−３…解釈項
２−４…対象項
２−５…解釈項への評価
２−７…対象項への評価
２−６、２−８…電子署名
２−１７、２−１８…アクセスカウンタ
【図１】
2005157443.tif 000003
【図２】
2005157443.tif 000004
【図３】
2005157443.tif 000005
【図４】
2005157443.tif 000006
【図５】
2005157443.tif 000007
【図６】
2005157443.tif 000008
【図７】
2005157443.tif 000009
【図８】
2005157443.tif 000010
【図９】
2005157443.tif 000011
【図１０】
2005157443.tif 000012
【図１１】
2005157443.tif 000013
【図１２】
2005157443.tif 000014
【図１３】
2005157443.tif 000015
【図１４】
2005157443.tif 000016
【図１５】
2005157443.tif 000017
【図１６】
2005157443.tif 000018
【図１７】
2005157443.tif 000019
【図１８】
2005157443.tif 000020
【図１９】
2005157443.tif 000021
【図２０】
2005157443.tif 000022
【図２１】
2005157443.tif 000023
【図２２】
2005157443.tif 000024
【図２３】
2005157443.tif 000025
【図２４】
2005157443.tif 000026
【図２５】
2005157443.tif 000027
【図２６】
2005157443.tif 000028
【図２７】
2005157443.tif 000029
【図２８】
2005157443.tif 000030
【図２９】
2005157443.tif 000031
【図３０】
2005157443.tif 000032
【図３１】
2005157443.tif 000033
【図３２】
2005157443.tif 000034
【図３３】
2005157443.tif 000035
【図３４】
2005157443.tif 000036
【図３５】
2005157443.tif 000037
【図３６】
2005157443.tif 000038
【図３７】
2005157443.tif 000039