JP5886376B2 - 構造化メタデータに基づく発見を公開するプラグインモデルのための方法および装置 - Google Patents

構造化メタデータに基づく発見を公開するプラグインモデルのための方法および装置 Download PDF

Info

Publication number
JP5886376B2
JP5886376B2 JP2014143385A JP2014143385A JP5886376B2 JP 5886376 B2 JP5886376 B2 JP 5886376B2 JP 2014143385 A JP2014143385 A JP 2014143385A JP 2014143385 A JP2014143385 A JP 2014143385A JP 5886376 B2 JP5886376 B2 JP 5886376B2
Authority
JP
Japan
Prior art keywords
service
service description
unique
keyword
searchable
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2014143385A
Other languages
English (en)
Other versions
JP2014241141A (ja
Inventor
アシュウィン・スワミナサン
ランジス・スブラマニアン・ジャヤラム
ビドヤ・ナラヤナン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2014241141A publication Critical patent/JP2014241141A/ja
Application granted granted Critical
Publication of JP5886376B2 publication Critical patent/JP5886376B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99933—Query processing, i.e. searching
    • Y10S707/99936—Pattern matching access

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

優先権の主張
米国特許法第１１９条に基づく優先権の主張
本特許出願は、本特許の譲受人に譲渡され、明白に参照によって本明細書に組み込まれている、２００９年６月１１日に出願した、「ＭＥＴＨＯＤＳ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ Ａ ＰＬＵＧ−ＩＮ ＭＯＤＥＬ ＦＯＲ ＰＵＢＬＩＳＨＩＮＧ ＳＴＲＵＣＴＵＲＥＤ ＤＡＴＡ ＩＮ Ａ ＤＩＳＴＲＩＢＵＴＥＤ ＮＥＴＷＯＲＫ」という名称の仮出願第６１／１８６，３１９号に対する優先権を主張する。
本開示は、モバイル動作環境に関し、より詳細には、オーバレイネットワークと、オーバレイネットワーク内でデータ構造を公開する方法および装置とに関する。
オーバレイネットワークとは、既存のネットワークの上に構築される、ノードおよび論理リンクからなる仮想ネットワークである。オーバレイネットワークの例は、インターネット、Ｃｈｏｒｄ、Ｃｏｎｔｅｎｔ Ａｄｄｒｅｓｓａｂｌｅ Ｎｅｔｗｏｒｋ（ＣＡＮ）、Ｐａｓｔｒｙ、およびＶｉｃｅｒｏｙを含むが、それに限定されない。一部のオーバレイネットワークでは、各ノードは、データをネットワークに分散させて、データの格納および取出しにおけるネットワーク効率を増すように、区画（partition）と呼ばれる、オーバレイネットワークデータの一部分を格納することができる。
オーバレイネットワークに参加するデバイスまたはノードは、オーバレイネットワーク内の別のデバイスまたはノードからサービスを取得することを望む場合がある。このようなサービスは、複数のサービス記述言語のいずれか１つを使って、オーバレイネットワーク内で公開され、該複数のサービス記述言語のそれぞれは、公開されているサービスを見つけるのに使用するための、対応するサービス発見プロトコルをもつ。Ｗｉｋｉｐｅｄｉａによって与えられるサービス発見の定義は、「サービス発見プロトコルは、デバイスと、こうしたデバイスによってコンピュータネットワーク上で提供されるサービスとの自動検出を可能にするネットワークプロトコルである」と述べている。言い換えると、サービス発見は、リクエストされたサービスのサービスプロバイダを見つけるアクションである。要望されたサービスの場所（通常、サービスプロバイダのアドレス）が取得されると、ユーザは、そのサービスにさらにアクセスし、利用することができる。
概して、サービス発見プロトコルは、（ａ）オーバレイ上でサービスを提供するサービスプロバイダ、および（ｂ）サービスを利用するクライアント、という２つのエンティティを含む。一態様において、サービスプロバイダの例は、印刷、スキャン、ファックス送信、格納、音楽共有、ファイル共有、ゲームなどのサービス、およびたとえば映画チケット、ホテル、航空券を予約するため、またはオンラインゲームなどのためのウェブサービスを提供するノードを含む。さらに、ネットワーク内のどのノードも、クライアントとして作用し得る。したがって、サービス発見の目標は、関心を引くある特定のサービス（このようなサービスが存在する場合）のサービスプロバイダをクライアントが見つけるのを助けることである。
ピアツーピアオーバレイネットワークにおいてサービス発見が成功するために、サービスプロバイダは、そのサービス（１つまたは複数）を、サービス記述言語を使って指定するべきであり、サービスについてのメタデータは、検索可能な何らかの形で、オーバレイ内のノード上に格納されているべきであり、クライアントは、対応するサービスを見つけるのを助けるためにクエリシステムに渡される検索可能キーワードを使って、サービス要求を表すことができるべきである。
ただし、従来技術では、異なるプロトコルを使用するので、全利用可能サービスを見つける上で問題が起こる。上述したように、サービスは一般に、サービス記述言語により記述され、この言語は、オーバレイでのサービスの公開と、サービスの発見の両方に使われる。ただし、異なる種類のサービスを記述する、標準化され、広く普及し、広く展開されているいくつかのサービス記述言語がある。一部の例は、ＯＷＬ−Ｓ、ＵＤＤＩ、ＵＰｎＰ、ＷＳＤＬ、ＸＭＬ、ＲＤＦなどを含む。こうした言語はそれぞれ、独自の普及領域をもっており、明らかに勝っているものはない。したがって、異なる言語が異なるサービスによって使われるので、クライアントは、クライアントのクエリと同じ言語を使って記述されたサービスを認識することしかできない。従来技術では、発見プロトコルとサービス記述言語との間は、緩やかに結合されている。たとえば、ＵＰｎＰは、独自のサービス記述言語を使い、ＵＤＤＩは、ウェブサービス用のＷＳＤＬを使う、などのようになる。したがって、多くの利用可能サービスは認識されない。
複数のサービス言語を扱うという問題に対処しようとするこれまでの試みは、あるサービス記述言語で公開されたサービス記述を、最終的にはオーバレイで公開することができる別の言語に変換するための翻訳機の使用を伴ってきた。ただし、このようなアプローチは煩わしく、異なるＮ個のサービス記述言語が与えられると（Ｎは正の整数）、少なくともＯ（Ｎ）個の翻訳機が各ノードにおいて実装される必要がある。ここで、Ｏは何らかの関数である。
したがって、サービス記述の効率的公開と、効率的クエリ処理とを可能にする、複数のサービス言語を扱う方法を実現することが望ましいであろう。
以下では、１つまたは複数の態様の基本的な理解のために、このような態様の簡略化した要約を提示している。この要約は、企図したすべての態様の包括的な概要ではなく、すべての態様の主要または重大な要素を明らかにすることも、一部または全部の態様の範囲を定めることも意図していない。その唯一の目的は、後で提示するより詳細な説明の前置きとして、１つまたは複数の態様のいくつかの概念を、簡略化した形で提示することである。
一態様によると、ネットワーク内でサービスを公開または発見する方法は、ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信することと、固有サービス記述から１つまたは複数のキーワードを抽出することと、各キーワードは、ネットワーク上でのサービス発見に必要とされる情報に対応し、固有サービス記述から、１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出することと、必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成することと、必須フィールドは、固有サービス記述から抽出された各キーワードを備え、キーワードとともに公開フィールドは、各抽出されたキーワードに対応する抽出された追加情報を備え、サービスを広告するためにネットワークにオーバレイ検索可能サービス記述を公開することと、を備える。
さらに他の一態様は、ネットワーク内でサービスを公開または発見するように構成された少なくとも１つのプロセッサに関し、このプロセッサは、ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信する第１のモジュールと、固有サービス記述から１つまたは複数のキーワードを抽出する第２のモジュールと、各キーワードはネットワーク上でのサービス発見に必要とされる情報に対応し、固有サービス記述から、１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出する第３のモジュールと、必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成する第４のモジュールと、必須フィールドは固有サービス記述から抽出された各キーワードを備え、キーワードとともに公開フィールドは、各抽出キーワードに対応する抽出された追加情報を備え、サービスを広告するために、ネットワークに検索可能サービス記述を公開する第５のモジュールと、を備える。
さらに別の態様は、コンピュータに、ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信させる第１のコードセットと、コンピュータに、固有サービス記述から１つまたは複数のキーワードを抽出させる第２のコードセットと、各キーワードはネットワーク上でのサービス発見に必要とされる情報に対応し、コンピュータに、固有サービス記述から、１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出させる第３のコードセットと、コンピュータに、必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成させる第４のコードセットと、必須フィールドは固有サービス記述から抽出された各キーワードを備え、キーワードとともに公開フィールドは各抽出されたキーワードに対応し、コンピュータに、サービスを広告するために、ネットワークに検索可能サービス記述を公開させる第５のコードセットと、を備えるコンピュータ可読媒体を備えるコンピュータプログラム製品に関する。
さらに他の一態様は、ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信するための手段と、固有サービス記述から１つまたは複数のキーワードを抽出するための手段と、各キーワードはネットワーク上でのサービス発見に必要とされる情報に対応し、固有サービス記述から、１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出するための手段と、必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成するための手段と、必須フィールドは固有サービス記述から抽出された各キーワードを備え、キーワードとともに公開フィールドは各抽出されたキーワードに対応する抽出された追加情報を備え、サービスを広告するために、ネットワークに検索可能サービス記述を公開するための手段と、を備える装置に関する。
別の態様は、ネットワーク内でサービスを公開する装置に関し、該装置は、ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信するように構成された受信機と、検索可能スキーマプラグイン構成要素と、を備え、該検索可能スキーマプラグイン構成要素は、固有サービス記述から１つまたは複数のキーワードを抽出し、各キーワードはネットワーク上でのサービス発見に必要とされる情報に対応し、固有サービス記述から、１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出し、必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成し、必須フィールドは固有サービス記述から抽出された各キーワードを備え、キーワードとともに公開フィールドは各抽出されたキーワードに対応する抽出された追加情報を備え、さらに、該装置は、サービスを広告するために、オーバレイネットワークに検索可能サービス記述を公開する公開処理構成要素を備える。
別の態様によると、ネットワーク検索クエリを処理する方法は、固有サービス記述言語での固有サービスクエリを受信することと、固有サービスクエリを、正規化スキーマに従って検索可能クエリに翻訳することと、固有検索クエリによって識別されるサービスを求めてネットワークを検索することと、検索は正規化スキーマに従って実施され、検索結果を、正規化スキーマから固有検索記述言語に翻訳することと、を備える。
上記および関連目的の遂行のために、１つまたは複数の態様は、以下で完全に記載するとともに請求項において具体的に指摘する特徴を備える。以下の説明および添付の図面では、１つまたは複数の態様の特定の例示的特徴を詳しく説明する。ただし、こうした特徴は、様々な態様の原理を利用し得るための様々なやり方のいくつかを示すに過ぎず、本記述は、このようなすべての態様とその等価物とを含むことを意図している。
本開示態様を、本開示態様を限定するためではなく例示するために与えられる、添付の図面とともに以下に記載するが、同じ呼称は同じ要素を示す。
ピアツーピアネットワークの態様を示すブロック図。 ネットワークにおいて、異なる様々なサービス記述言語をサポートする、サービス公開のためのシステムの態様を示す概略図。 図１のネットワークまたは図２のシステムにおいて、本明細書に記載する機能を実施するように構成されたコンピューティングデバイスの態様を示す概略図。 検索可能サービス記述を生成および公開する方法の態様を示すフローチャート。 サービスを求めるクエリを処理する方法の態様を示すフローチャート。 ネットワーク内でサービスを公開および発見するシステムの態様を示す概略図。 正規化スキーマの例を示す図。 正規化スキーマの例を示す図。 正規化スキーマの別の例を示す図。
次に、図面を参照して、様々な態様を記載する。以下の記述では、説明目的で、１つまたは複数の態様の完全な理解のために多数の具体的詳細を説明する。ただし、こうした態様（１つまたは複数）は、こうした具体的詳細なしで実施され得ることが明らかであろう。
ネットワーク、たとえばピアツーピアネットワークは、コンピュータネットワーク上で、デバイスと、こうしたデバイスによって提供されるサービスとを発見する能力に依拠する。サービスを記述するのに、様々なサービス記述言語スキーマが使われ得る。本明細書に記載するシステムおよび方法は、サービスを公開し発見する共通フレームワークを提供する。サービスは、サービスを記述するのに使われるサービス記述言語に関わらず、公開し発見することができる。
図１を参照すると、ピアツーピアオーバレイネットワーク１００のブロック図が与えられている。ネットワーク１００は、インターネットプロトコルネットワークなど、どのタイプのネットワークも備える基底ネットワーク１０２を備える。基底ネットワーク１０２を、単一エンティティとして示してあるが、基底ネットワークは、ＷＡＮ、ＬＡＮ、ワイヤレスネットワーク、または他のあらゆるタイプのネットワークなど、任意の数またはタイプのネットワークを備えてもよい。図１は、ピアツーピアオーバレイネットワークを示すが、本出願は、オーバレイネットワークに限定されない。本明細書に記載するシステムおよび方法は、集中型ネットワークを含む、どのタイプのネットワークにも等しく適用可能である。たとえば、ネットワーク１００は、発見サービスを提供するサーバを含み得る。このようなケースでは、サーバは、発見に関連した情報を収容するディレクトリとして作用し得る。たとえば、サーバは、ネットワーク内のノードによって公開されるキーワードと、対応する情報とを収容し得る。ノードは、情報をサーバに公開してよく、クエリもサーバに送られ得る。
ある態様において、基底ネットワーク１０２は、複数のピアツーピアネットワーク（１０４、１０６、１０８）を備える。ピアツーピアネットワーク１０４、１０６、１０８は、それぞれ、基底ネットワーク１０２のノードのサブセットを構成し、こうしたノードが通信可能なように、基底ネットワーク１０２のサービスを利用して動作する。たとえば、ピアツーピアネットワーク１０４、１０６、１０８において、ノードは、基底ネットワーク１０２によって与えられる通信リンクによって接続されて、所望のルーティングパスを形成する。ピアツーピアネットワーク１０４、１０６、１０６は、いかなるルーティング構成も可能にするためのどのトポロジまたはアーキテクチャを有してもよく、図１に示す構成に限定されない。
ピアツーピアオーバレイネットワーク、たとえばネットワーク１０４、１０６、１０８内部で、各ノードは、サービスプロバイダとして、および／またはクライアントとして動作することができる。つまり、ノードは、オーバレイにサービスを提供することができ、他の１つまたは複数のノードのサービスを利用することができる。このようなサービスは、たとえば、印刷、スキャン、ファックス送信、格納、音楽共有、ファイル共有、ゲーム、映画のチケット、ホテル、航空券の予約、またはオンラインゲームなどのウェブサービスを含み得る。ただし、こうしたサービス例は非限定的であり、実際のサービスは、列挙したものより多くの、または少ないサービスを含み得ることに留意されたい。各ノードは、たとえば、パーソナルコンピュータ、ラップトップコンピュータ、ワイヤレス通信デバイス、モバイル電話、携帯情報端末、プリンタ、ファックスマシン、および／または他のあらゆるネットワーク接続可能コンピューティングデバイスなどのコンピューティングデバイスを備え得る。
サービス発見プロトコルを使って、クライアントとして動作するノードが、関心を引くある特定のサービスのサービスプロバイダを見つけるのを支援することができる。サービスプロバイダは、そのサービスを、たとえば、拡張マークアップ言語（ＸＭＬ）、Ｒｅｓｅａｒｃｈ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｏｒｍａｔ（ＲＤＦ）、ＲＤＦ−Ｓ、ウェブサービス記述言語（ＷＳＤＬ）、ＷＳＤＬ−Ｓ、オントロジーウェブ言語（ＯＷＬ）、サービス用オントロジーウェブ言語（ＯＷＬ−Ｓ）、Ｕｎｉｖｅｒｓａｌ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｉｓｃｏｖｅｒｙ ａｎｄ Ｉｎｔｅｇｒａｔｉｏｎ（ＵＤＤＩ）、ユニバーサルプラグアンドプレイ（ＵＰｎＰ）、および／または他のサービス記述言語などのサービス記述言語を使って指定する。サービスについてのメタデータは、オーバレイ内のノード上に検索可能フォーマットで格納され、クライアントは、対応するサービスを見つけるのを助けるための、クエリシステムに渡される検索可能キーワードを使ってサービス要求を表せばよい。
図２は、異なる様々なサービス記述言語をサポートする、サービス公開のための例示的なシステム２００を示す。システム２００は、ピアツーピアネットワーク上で広告し、発見されるべきサービス用の共通フレームワークを提供する。図２に示すように、サービス記述のためのデータ２０２は、たとえば、ＸＭＬ、ＸＤＳ、ＲＤＦ、ＲＤＦ−Ｓ、ＷＳＤＬ、ＵＤＤＩ、ＵＰｎＰ、ＯＷＬ、ＯＷＬ−ｓ、およびそれ以外など、どのサービス記述言語／スキーマ２０４を使って公開してもよい。１つまたは複数のプラグインモジュール２０６は、サービス記述を、たとえばそれぞれのサービス記述言語２０４での、その固有の形から、正規化スキーマ２０９に基づく検索可能サービス記述２０８に変換するために提供される。検索可能サービス記述２０８は次いで、オーバレイネットワーク２１０上で公開される。
検索可能サービス記述２０８は、サービス発見に必要とされる情報と、サービスを順位づけし、アクセスするのに必要とされる情報とをすべて集約するのを可能にする。検索可能サービス記述２０８の公開は、固有サービス記述からのキーワードの抽出を含む。キーワードは、たとえば、ＸＭＬ属性値のペアとして、ＲＤＦトリプルとして、単純なキーワードとして、または他のいかなる抽出方法にも従って抽出することができる。プラグインモジュール２０６は、抽出されるべき特定のフィールドと、そのフィールドを抽出するフォーマットとを定義する正規化スキーマ２０９を提供する。正規化スキーマ２０９は、サービス記述言語の機能のすべてを提供するわけではないので、サービス記述言語ではない。翻訳機の使用とは異なり、プラグインモジュール２０６は、あるサービス記述言語から他の１つまたは複数のサービス記述言語には翻訳しない。そうではなく、プラグインモジュール２０６は、正規化スキーマ２０９に基づいて、元のサービス記述からの一定のデータの抽出を容易にする。たとえば、正規化スキーマ２０９によって指定されたフィールドは、固有サービス記述２０４中の特定のデータにマップされる。したがって、オーバレイネットワーク上で公開されるのは、正規化スキーマ２０９に従って抽出された情報である。したがって、それぞれ異なるサービス記述言語での複数のバージョンのサービス記述を、ネットワーク上で公開させるのではなく、どのノードによっても検索し認識することができる単一の記述が、ネットワークに公開され得る。
図３は、ピアツーピアおよび／またはオーバレイネットワーク内のノードとして働き得る例示的なコンピューティングデバイス３００を示す。コンピューティングデバイス３００は、本明細書に記載する１つまたは複数の構成要素および機能に関連づけられた処理機能を実施するプロセッサ３０２を含む。プロセッサ３０２は、単一または複数のプロセッサまたはマルチコアプロセッサセットを含み得る。さらに、プロセッサ３０２は、統合型処理システムおよび／または分散型処理システムとして実装することができる。
コンピューティングデバイス３００は、たとえば、プロセッサ３０２によって実行されるアプリケーションのローカルバージョンを格納するメモリ３０４をさらに含む。メモリ３０４は、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、テープ、磁気ディスク、光ディスク、揮発性メモリ、不揮発性メモリ、およびそのあらゆる組合せなど、コンピュータによって使用可能などのタイプのメモリも含み得る。
さらに、コンピュータデバイス３００は、本明細書に記載するハードウェアと、ソフトウェアと、サービスとを使用して、１人または複数の当事者との通信を確立し維持することを可能にする通信構成要素３０６を含む。通信構成要素３０６は、コンピュータデバイス３００上の構成要素の間で、ならびにコンピュータデバイス３００と、通信ネットワークを越えて配置されたデバイスおよび／またはコンピュータデバイス３００にシリアルもしくはローカルに接続されたデバイスなどの外部デバイスとの間で通信内容を搬送することができる。たとえば、通信構成要素３０６は、１つまたは複数のバスを含んでよく、それぞれ、外部デバイスとインターフェースをとるように動作可能な送信機と受信機とに関連づけられた送信チェーン構成要素と受信チェーン構成要素とをさらに含んでよい。さらに、たとえば、通信構成要素３０６は、コンピュータデバイス３００がオーバレイネットワーク内の他のノードと通信することを可能にするように構成され得る。
さらに、コンピュータデバイス３００は、データストア３０８をさらに含んでよく、データストア３０８は、本明細書に記載する態様と関連して利用される、情報、データベース、およびプログラムの大容量記憶を可能にする、ハードウェアおよび／またはソフトウェアの適切などの組合せでもよい。たとえば、データストア３０８は、プロセッサ３０２によって現時点で実行されていないアプリケーション用のデータリポジトリでよい。
コンピュータデバイス３００は、コンピュータデバイス３００のユーザから入力を受信するように動作可能であり、ユーザへの表示用の出力を生成するようにさらに動作可能な、ユーザインターフェース構成要素３１０をさらに含み得る。ユーザインターフェース構成要素３１０は、キーボード、数字パッド、マウス、タッチディスプレイ、ナビゲーションキー、ファンクションキー、マイクロホン、音声認識構成要素、ユーザから入力を受信することが可能な他のいかなる機構、またはそのどのような組合せも含むが、それに限定されない、１つまたは複数の入力デバイスを含み得る。さらに、ユーザインターフェース構成要素３１０は、ディスプレイ、スピーカ、触覚フィードバック機構、プリンタ、ユーザに出力を提示することが可能な他のいかなる機構、またはそのどのような組合せも含むが、それに限定されない、１つまたは複数の出力デバイスを含み得る。
ある態様において、コンピュータデバイス３００は、１つまたは複数の検索可能スキーマプラグインモジュール２０６も含み得る。たとえば、１つまたは複数のプラグインモジュール２０６は、メモリ３０４に格納することができる。各スキーマプラグインモジュール２０６は、正規化スキーマ２０９に基づいて、あらゆるサービス記述言語２０４で書かれたサービス記述から検索可能サービス記述２０８（図２）を生成するように構成され得る。検索可能サービス記述２０８は、ネットワークに公開され、サービスに対するクエリを処理するのに使われる。検索可能サービス記述２０８の生成は、サービス記述からキーワードを、その固有の形で抽出することと、次いで、こうしたキーワードを、検索可能サービス記述２０８のフォーマットでネットワーク上に広告することとを含む。
コンピュータデバイス３００は、検索可能サービス記述２０８（図２）の公開を容易にする公開処理モジュール３１２をさらに含む。さらに、ネットワークへのクエリを処理するクエリ処理モジュール３１４も含まれる。クエリが固有サービス記述言語で受信されると、クエリ処理モジュール３１４は、正規化スキーマ２０９に基づいてクエリを翻訳するように構成される。したがって、ネットワークの検索を実施することができる。検索結果が取得されると、クエリ処理モジュール３１４は、結果を、元のクエリの固有サービス記述言語に逆翻訳するように、また、結果を要求側に転送するように構成される。
図４は、検索可能サービス記述を生成および公開する例示的な方法を示すフローチャートである。４０２で示すように、プロセスは、たとえば、ＸＭＬ、ＲＤＦ、ＷＳＤＬ、ＯＷＬ、および／または他のあらゆるサービス記述言語などの固有サービス記述言語で書かれたサービス記述の受信で始まる。図２、３に示すプラグインモジュール２０６が、固有言語サービス記述を受信する。
４０４で示すように、１つまたは複数のキーワードを、サービス記述から抽出することができる。さらに、キーワードとともに公開されるべき、他の識別された情報も抽出される。キーワードは、たとえば、サービス名、サービス記述言語などに対応する。４０６で示すように、検索可能サービス記述が、正規化スキーマに基づいて、抽出されたキーワードと、他の識別情報とを使って作成される。検索可能サービス記述は、たとえば、必須、オプション、および「キーワードとともに公開」などのフィールドを備えるが、これらに限定するものではない。正規化スキーマは、サービス記述言語ファイル中の複数の属性から選択され得る属性を各フィールド内に備える。異なるサービス記述言語は、特定の属性に対して異なる命名規則を有し得る。正規化スキーマは、属性ごとに標準属性名を定義する。キーワードを抽出し、検索可能サービス記述を生成するとき、固有属性値は、適切な標準属性名に関連づけられる。
必須フィールドは、サービス発見のためにネットワーク上で公開されなければならない固有サービス記述にある情報をすべて備える。必須情報の例は、たとえば、サービス記述に関連づけられたサービス名、サービスによって使われるサービス記述言語についての情報などを含むが、それに限定されない。必須フィールドは、サービスが複数の言語で記述されている場合、２つ以上のサービス記述言語を含み得る。さらに、サービス発見を容易にするためのテキスト記述および／またはキーワード、サービスとコンタクトするための情報、および／またはサービスに関連があるとともに他のフィールドによって記述されない可能なキーワードのリストなど、他の情報が、必須フィールド中に含まれ得る。
オプションフィールドは、サービス発見のために公開され得る情報すべてを含む。このフィールドは、発展型検索および発見を容易にするための追加情報を提示し、既に必須フィールド中にあるフィールドは含まなくてよい。オプションフィールド中の例示的エンティティは、たとえば、サービスが受け取る可能な入力タイプについての情報、サービスが生成する可能な出力タイプについての情報、サービスの前提条件およびスキーマに従って定義される前提条件インスタンスに及ぶ範囲、サービスのある特定の結果についての情報およびどのような条件で出力が生成されるか、公開元についての情報、サービスに関連があるとともに他のフィールドによって記述されない可能キーワードのリスト、および／または他の情報、を含み得る。
「キーワードとともに公開」フィールドは、必須およびオプションフィールドから抽出されたキーワードとともに公開される必要がある情報を備える。「キーワードとともに公開」フィールドは、たとえば、ある特定のキーワードに特有であるとともに、その選ばれたキーワードのみとともに格納されている情報、サービス記述から抽出された全キーワードと一緒に格納されている記述されるサービスについての情報、および／または他の情報、を含み得る。たとえば、ある特定のキーワードに特有の情報は、サービス記述のドキュメントにおいてある特定のキーワードが出現する回数を含んでもよい。この情報は、クエリ結果の順位づけが索引語−頻度値に基づいて行われる、関連性ベースの検索に有用であり得る。
再度図４を参照すると、４０６で示すように、正規化スキーマに基づいて作成された検索可能サービス記述は、ネットワークに公開することができる。検索可能サービス記述によって記述されたサービスは次いで、どのサービス記述言語でフォーマットされた検索クエリを発行するノードによっても発見され得る。
図５は、サービスに対するクエリを処理する例示的な方法を示すフローチャートである。５０２で示すように、プロセスは、固有検索記述言語でのクエリが受信されたとき始まる。５０４で示すように、クエリは次いで、正規化スキーマに基づいて、サービスクエリに翻訳される。５０６で示すように、サービスクエリに合致するサービスを求めて、ネットワークの検索が実施される。本明細書に記載するように、ネットワークは、正規化スキーマに基づいてフォーマットされているサービス記述を格納している。５０８で示すように、検索クエリの結果が受信される。結果は、正規化スキーマに従ってもフォーマットされる。５１０で示すように、結果は、対応する固有検索クエリの元のまたは固有サービス記述言語に翻訳される。
図６に移ると、ネットワークにおいてサービスを公開および発見するシステム６００が示されている。図示するように、システム６００は、プロセッサ、ソフトウェア、またはその組合せ（たとえば、ファームウェア）によって実装される機能を表し得る機能ブロックを含む。システム６００は、連携して作用する電気構成要素の論理グループ６０２を含む。システム６００は、たとえば、ピアツーピアネットワーク内のノードとして作用するコンピューティングデバイスによって実装することができる。
論理グループ６０２は、ネットワークにおける公開のために第１のサービス記述言語でのサービスの固有サービス記述を受信するモジュール６０４を含む。さらに、論理グループ６０２は、１つまたは複数のキーワードを固有サービス記述から抽出するモジュール６０６を含み、各キーワードは、ネットワーク上でのサービス発見に必要とされる情報に対応する。論理グループ６０２は、さらに、１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を固有サービス記述から抽出するモジュール６０８と、必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成するモジュール６１０と、を備え、当該必須フィールドは固有サービス記述から抽出された各キーワードを備え、当該キーワードとともに公開フィールドは、各抽出されたキーワードに対応する抽出された追加情報を備え、当該論理グループ６０２は、さらに、サービスを広告するために、検索可能サービス記述をネットワークに公開するモジュール６１２を含む。さらに、システム６００は、電気構成要素６０４〜６１２に関連づけられた機能を実行する命令を保持するメモリ６１８を含む。メモリ６１８の外部にあるものとして示してあるが、電気構成要素６０４〜６１２は、メモリ６１８内部に存在してもよいことを理解されたい。
正規化スキーマ２０９（図２）の一例は、Ｑｕａｌｃｏｍｍ，Ｉｎｃから入手可能なＧｅｎｉｅ検索可能スキーマである。正規化スキーマ２０９と同様に、Ｇｅｎｉｅ検索可能スキーマ（ＧＳＳまたはＧｅｎｉｅ）は、サービス記述言語ではない。このスキーマは、サービス記述言語の機能性をすべて提供するわけではないので、サービス記述言語と理解されるべきではない。ＧＳＳは、サービス発見に必要とされる情報と、サービスを順位づけ、アクセスするのに必要とされる情報とをすべて集約するための機構を提供するだけである。Ｇｅｎｉｅでは、サービスは、その固有サービス記述を使って記述されると考える。固有サービス記述は、ＯＷＬ−Ｓ、ＷＳＤＬ、ＵＰｎＰ、または他の公知もしくは未発見スキーマでもよいであろう。この情報をオーバレイ上に公開することは、２つのステップを伴う。第１のステップは、記述からキーワードを抽出することである。抽出された各キーワードは、３つのタイプ、すなわち、単純なキーワード、ＸＭＬ属性値のペア、およびＲＤＦトリプルの１つでよい。次のステップは、こうしたキーワードをオーバレイ上で広告することである。広告は、ＰＵＴコマンドを使って行うことができる。ＰＵＴコマンドは、入力として、ＲｅｓｏｕｒｃｅＮａｍｅと、ＡｕｔｈＮａｍｅと、ＫｉｎｄＩＤと、Ｎａｍｅと、Ｖａｌｕｅと、ＬｉｆｅＴｉｍｅとをもつ。ＰＵＴコマンドは、３タイプのキーワード用に、異なる３つのｋｉｎｄＩＤ、すなわち、ＫＥＹＷＯＲＤと、ＸＭＬ＿ＫＥＹＷＯＲＤと、ＲＤＦ＿ＫＥＹＷＯＲＤとをサポートすることに留意されたい。
ＧＳＳは、それゆえ、サービス公開における中間ステップとして作用する。ＧＳＳは、元のサービス記述から抽出されたキーワードのリストを、こうしたキーワードと一緒に公開され得る追加サイド情報のリストとともに含む。ＧＳＳは、ステップ１の最終生成物であり、Ｇｅｎｉｅミドルウェアを含み得るノードに、サービス記述のどこの部分を公開してよく、何をオーバレイに格納することができるかについての何らかの情報を提供する。ＧＳＳ自体は、オーバレイ内のどのノードにも、１つのドキュメントとしては格納されない。
ＧＳＳは、３つの基本フィールドを含む。
１．必須（required）：オーバレイにおいて公開されなければならない固有サービス記述中のフィールドをすべて含む。
２．オプション（optional）：オプションであるとともにサービス発見のために公開してよい固有サービス記述中の情報をすべて含む。
３．キーワードとともに公開（publishWithKeywords）：このフィールドは、固有サービス記述から抽出された各キーワードとともに公開される必要がある情報をすべて含む。
図７は、ＧＳＳ７００の例を示す。必須（required）フィールド７０２は、サービス発見のためにオーバレイ上で公開される必要がある情報をすべて含む。必須フィールド７０２は、下に列挙する以下のエンティティを含み得る。どのＧＳＳ７００の必須フィールド７０２も、servicenameとservicedescriptionlanguageとを含み、必須フィールド７０２中の残りのフィールドについては、ＧＳＳ７００に含めるのは任意である。テーブル１は、必須フィールド中のエントリの例を示す。
Figure 0005886376
フィールドservicedescriptionlanguageは、サービスによって使われるサービス記述言語についての情報を含む。必須フィールドは、少なくとも１つのservicedescriptionlanguageフィールドを含まなければならない。必須フィールドは、サービスが複数の言語で記述されている場合は、２つ以上のservicedescriptionlanguageフィールドを含み得る。このフィールド中の値は、ある特定の言語によって記述されているサービスをノード／アプリケーションに検索させるように標準化される必要がある。可能な選択肢は、以下を含む。
・ウェブサービス記述言語にはＷＳＤＬ、
・ＯＷＬ−Ｓの場合はＯＷＬＳ、
・ＯＷＬの場合はＯＷＬ、
・Universal Description，Discovery，and Integrationの場合はＵＤＤＩ、
・ユニバーサルプラグアンドプレイの場合はＵＰｎＰ、など。
フィールドsearchKeywordsは、サービスに関連のある可能キーワードのリストをもつ。この情報は、固有サービス記述から抽出してもよく、サービス、アプリケーション、またはノードによって、サービスを公開するときに追加するだけでもよい。searchKeywordsフィールド中の情報は、単純なキーワード、ＸＭＬ属性値のペア、またはＲＤＦトリプルでもよい。キーワードは、外部手段によって（サービスまたはアプリケーションなどにより）追加される場合、図７でのように、フィールドuserDefinedKeyword中に封入される。
オプション（optional）フィールド７０４は、サービス発見のために公開してよい情報をすべて含む。オプションフィールド７０４は、発展型検索および発見を容易にするための追加情報を提示し、既に必須フィールド中にあるフィールドは含まなくてよい。オプションフィールド内のエンティティはすべて、本当に任意であり、テーブル２に示す以下のエントリを含む。
Figure 0005886376
フィールドservicePublisherは、追加サブフィールド、すなわち、公開元の名称を含むservicePublisherNameと、公開元についてのテキスト記述および／またはキーワードを含むtextDescription（サービス広告は、こうしたキーワードでユーザに検索させたい場合、追加キーワードを追加してよい）と、サービスとのコンタクト法についての情報を含むcontactInformationとを有する。
フィールドsearchKeywordsは、サービスと関連があるとともに必須フィールド中で直接カバーされない可能キーワードのリストをもつ。この情報は、固有サービス記述から抽出してもよく、サービス、アプリケーション、またはノードによって、サービスを公開するときに追加するだけでもよい。searchKeywordsフィールド中の情報は、単純なキーワード、ＸＭＬ属性値のペア、またはＲＤＦトリプルでよい。可能な例は、ＯＷＬ−ＳスキーマにおけるserviceParameterおよびserviceCategoryフィールドを含む。フィールドserviceParameterは、ＯＷＬ−Ｓでのプロファイル記述を伴い得るプロパティの拡張可能リストをもつ。このフィールドは、追加サブフィールド、すなわち、serviceParameterName（実際のパラメータの名前）と、sParameter（パラメータの値をポイントする）とを有し得る。serviceCategoryは、ＯＷＬ−Ｓ外部であり、可能性としてはＯＷＬ［ＯＷＬ−Ｓ］外部でよい何らかの類別に基づくサービスのカテゴリを記述する。このカテゴリは、以下のフィールドを含む。すなわち、（ａ）categoryName：実際のカテゴリの名前、（ｂ）taxonomy：分類方式への参照を格納する、（ｃ）value：具体的分類における値をポイントする、および（ｄ）code：サービスタイプごとの分類に関連づけられたコードを格納する。serviceParameterおよびserviceCategoryフィールドは、ＯＷＬ−Ｓバージョン１．１における主要プロファイル記述中に存在し、バージョン１．２で始まる比較的最近のバージョンのＰｒｏｆｉｌｅ．ｏｗｌ外部では廃止されてきた。こうしたバージョンにおいて、こうしたフィールドは、それぞれ、ServiceParameter.owlおよびServiceCategory.owlという別個のファイルに見ることができる。
オーバレイにおいて公開される情報の量に依存して、オプションフィールドおよびそのサブフィールドは、公開されてもされなくてもよい。それゆえ、必須およびオプションフィールドは、サービス発見のためにオーバレイにおいて何を公開しなければならないか、または公開してよいかを、オーバレイが決めるためのやり方を提供する。
publishWithKeywordフィールド７０６は、必須およびオプションフィールドから抽出されたキーワードとともに公開される必要がある情報を含む。publishWithKeywordフィールド７０６は主として、２つのタイプの情報、すなわち、ある特定のキーワードに特有であるとともにその選ばれたキーワードとだけ一緒に格納されている情報を含むkeywordSpecificInfoと、記述されるサービスについての情報を含むserviceSpecificInfoとを含む。keywordSpecificInfoとは異なり、serviceSpecificInfoは、サービスのプロパティであり、サービス記述から抽出された全キーワードと一緒に格納される。keywordSpecificInfoの例は、ある特定のキーワードがドキュメントまたはサービス記述中に出現する回数であるnumberOfOccurrencesである。この情報は、クエリ結果の順位づけが索引語−頻度値に基づいて行われる、関連性ベースの検索に有用であり得る。
serviceSpecificInfoのいくつかの例は、serviceReputationおよびcontactInformationである。serviceReputationは、サービスの評価を指定する。この情報は、ユーザが異なる検索結果の中から選ぶのを助けるために、検索プロセスの最後に、ユーザに提示すればよい。この評価スコアは、検索結果を順位づけるのにも使うことができる。serviceReputationは、publishWithKeyword中のオプションフィールドである。serviceReputationとは対照的に、contactInformationフィールドは、publishWithKeywordにおいて必須であり、必須およびオプションフィールドから抽出されたすべてのキーワードとともに公開されなければならない。このフィールドは、以下の中にあってよい少なくとも１つのエントリを含まなければならない。すなわち、overlayURI：オーバレイ内のサービス記述ドキュメントへのＵＲＩポインタ、weburi：サービスもしくはサービス記述へのポインタであるＵＲＬもしくはＵＲＩ（これはオーバレイ特有ポインタでなくてよい）、contactNode：ノード識別子やｎｏｄｅＩＤなど、サービスを提供するノードについての情報（contactNodeフィールドは、結果のスコーピングと順位づけとを容易にするための、ノードの評価格付けおよびノードの場所などの追加情報を含み得る）、またはcontactPerson：サービスを担当する人の名前およびコンタクト情報である。publishWithKeywordに含まれる情報は、取り出された結果の順位づけとスコーピングとに使うことができ、キーワードＰＵＴコマンドのDocumentPointerおよびOtherInfoフィールドにおいてキーワードとともに公開される。
普及している１つのサービス記述言語は、ＯＷＬ−Ｓである。ＯＷＬ−Ｓは、サービス用の上位レイヤオントロジー（ontology）を提供する。サービスは、サービスクラスを使って記述される。Serviceクラスは、宣言されたＷｅｂサービスに対する組織的参照ポイントを与える。各Serviceインスタンスは、ServiceProfile記述を提示し、ServiceModel記述で記述され、ServiceGrounding記述をサポートすることになる。ServiceProfileは、エージェントがサービスを発見するのに必要とされる情報を与え、ServiceModelおよびServiceGroundingは、見つかると、まとめられて、エージェントがサービスを利用するのに十分な情報を与える。サービスプロファイルは、サービスを求めているエージェントが、サービスがエージェントの必要を満たすかどうか判定するのに適したやり方で、「サービスが何を行うか」を伝える。この表現形式は、サービスによって何が遂行されるか、サービス適用可能性およびサービス品質に対する制限、ならびにサービス要求元がサービスをうまく利用するために満足しなければならない要件の記述を含み得る。ＯＷＬ−ＳにおけるServiceProfileクラスは、サービスの発見に必要とされる情報をすべて与え、それゆえ、この情報は、公開用に十分である。
上述したＧＳＳ７００は、ＯＷＬ−ＳにおけるServiceProfileクラスに対しカプセル化し及びラッパー（wrapper）を提供する。ＧＳＳ７００は、ServiceProfileに基づくので、ＯＷＬ−ＳプロパティからＧＳＳフィールドへのマッピングは、テーブル３に示すように簡単である。
Figure 0005886376
いくつかの具体的サービス記述言語への、ＧＳＳ７００の適用の例について、ここで論じる。
サンプルＯＷＬ−Ｓサービス記述が付表Ａで与えられ、Ｇｅｎｉｅ検索可能スキーマ７００へのその記述の翻訳が付表Ｂで与えられる。付表Ａの例では、その構造およびサブフィールドがＯＷＬ−Ｓスキーマでは直接は定義されず、http://www.daml.org/services/owl-s/1.0/ActorDefault.owlという別個のファイルで定義され、<!ENTITY actor “http:/ /www.daml.org/services/owl-s/1.0/ActorDefault.owl”>というコマンドを使って示される「ａｃｔｏｒ」など、一定のフィールドがサービス記述中にあることに留意されたい。このようなエントリは、ＧＳＳスキーマ７００では直接は定義されず、searchKeywordsフィールドに含まれ得る。
別の普及しているサービス記述言語は、ＷＳＤＬである。ＷＳＤＬは、１つは抽象であり１つは具象である２つの根本的段階で、ウェブサービスを記述する。各段階において、記述は、いくつかの構成物を使って、記述の再利用性を促進し、独立した設計問題を切り離す。ＷＳＤＬの２つの普及バージョン、すなわち、ＷＳＤＬ１．１およびＷＳＤＬ２．０がある。抽象レベルで、ＷＳＤＬは、ＷＳＤＬが送り、受信するメッセージに関してウェブサービスを記述する。メッセージは、通常はＸＭＬスキーマである、タイプシステムを使う具体的ワイヤーフォーマットに依存せずに記述される。操作により、メッセージ交換パターンを１つまたは複数のメッセージと関連づける。メッセージ交換パターンは、送られる及び／または受信されるメッセージのシーケンスおよびカーディナリティ（cardinality）と、それらが誰に論理的に送られ、及び／または誰から受信されるかを識別する。インターフェースが、トランスポートまたはワイヤーフォーマットとは無関係に、操作を１つのグループにする。具象レベルで、バインドが、１つまたは複数のインターフェースに関するトランスポートおよびワイヤーフォーマットの詳細を指定する。エンドポイントが、ネットワークアドレスをバインドに関連づける。最終的に、サービスが、共通インターフェースを実装するエンドポイントを１つのグループにする。
２つのＷＳＤＬバージョンの間には、重要な違いがいくつかある。こうした違いは、記述言語へのさらなるセマンティクスの追加と、portTypeからインターフェース、ポートからエンドポイントへの変更などのようないくつかのメッセージ構成物の再命名と、バージョン２．０のＸＭＬスキーマのタイプシステムを使って指定されるいくつかのメッセージ構成物の削除／廃止とを含む。２つのバージョンの間のこうした重要な違いを除くと、ＷＳＤＬ１．１からＷＳＤＬ２．０への１対１のマッピングが存在し、ユーザが既存のＷＳＤＬ１．１ドキュメントをバージョン２．０のファイルに変えるのを助けるいくつかの変換器が存在する。一態様において、ＧＳＳ７００は、ＷＳＤＬ２．０サービス記述をＧＳＳ７００に変換するための機構を提供し、ＷＳＤＬ１．１からＷＳＤＬ２．０への変換は、このような変換器に任せる。
ＯＷＬ−Ｓのケースとは異なり、ＷＳＤＬは、ServiceProfileをもたず、サービスの発見に必要とされる情報は、サービス記述全体から集められる必要がある。テーブル４には、ＧＳＳフィールドと、ＧＳＳフィールドがそこから抽出され得るＷＳＤＬ２．０サービス記述の一部と、を示すための詳細が与えられている。テーブルに見られるように、servicenameおよびtextdescriptionなど、ＧＳＳ７００におけるいくつかのフィールドは、ＷＳＤＬサービスのプロパティから取得することができ、hasInputおよびhasOutputなど、他のいくつかのＧＳＳフィールドは、ＷＳＤＬインターフェース構成要素のプロパティから導出することができる。
Figure 0005886376
ＷＳＤＬ１．１サービス記述のサンプルを、付表Ｃに示し、それに対応するＷＳＤＬ２．０およびＧｅｎｉｅ検索可能スキーマ７００を、それぞれ、付表Ｄおよび付表Ｅに示す。
ＵＤＤＩ（Universal Description, Discovery, and Integration）プロトコルは、ウェブサービスのスタックを備える関連標準のグループの中心的要素である。ＵＤＤＩ仕様は、サービス指向アーキテクチャのネットワークベースのソフトウェア構成要素を公開し発見する標準的方法を定義する。その開発は、企業ソフトウェアベンダおよび顧客からなるＯＡＳＩＳコンソーシアムによって先導されている。
ＵＤＤＩレジストリの機能的目的は、ウェブサービスについてのデータおよびメタデータを表現することである。レジストリは、公衆網上または組織の内部インフラストラクチャ内でのいずれで使用するためであっても、ウェブサービスを類別し、カタログし、管理するための、標準ベースの機構を提供するので、こうしたサービスは、他のアプリケーションによって発見し消費することができる。サービスベースのアプリケーションの中でのインダイレクション（indirection）を一般化した戦略の一部として、ＵＤＤＩは、設計時間と実行時間の両方において、コードの再利用の増大とインフラストラクチャ管理の向上とを含む、いくつかの利益をＩＴマネージャにもたらす。
ＵＤＤＩレジストリによって使われるコア情報モデルは、いくつかのＸＭＬスキーマにおいて定義される。ＸＭＬが選ばれたのは、データについて、プラットフォームに中立な見方をし、階層関係を中立に記述させるからである。ＸＳＤが選ばれたのは、豊富なデータタイプをサポートし、スキーマで表される情報モデルに基づいて情報を容易に記述し検証することができるからである。ＵＤＤＩ ＸＳＤは、ＵＤＤＩレジストリの基本情報モデルと、対話フレームワークとを形成する。情報モデルの主要構成要素は、サービスのビジネス機能（businessServiceと呼ばれる）の記述と、サービスを公開した組織（businessEntity）についての情報と、サービスのプログラマティックインターフェース、またはＡＰＩへの参照を含む、サービスの技術詳細（bindingTemplate）と、たとえばｔＭｏｄｅｌｓにおいて定義される分類、トランスポート、デジタル署名など、他の様々な属性またはメタデータとを含む。テーブル５では、ＧＳＳフィールドと、こうしたフィールドがそこから抽出され得るＵＤＤＩサービス記述の一部とを示す詳細が与えられている。
Figure 0005886376
「ユニバーサルプラグアンドプレイ」というフレーズから派生したＵＰｎＰは、家庭および企業環境内のデバイス向けの単純なピアツーピアネットワーキングを提供することを目指すネットワークプロトコルのセットである。ＵＰｎＰは、ＴＣＰ／ＩＰ、ＨＴＴＰ、ＸＭＬおよびＳＯＡＰなど、オープンなインターネットベース標準に基づいてプロトコルを定義することによって、この目標を達成する。ＵＰｎＰプロトコルは、アドレス指定、サービス発見のための手順、サービス記述、ならびにサービス交換のための制御、イベント通知および提示を含む、ピアツーピアネットワーキングのほぼ全側面を定義する。
ＵＰｎＰは、サービスを提供するデバイス（Ｄｅｖｉｃｅ）、およびデバイスによって提供されるサービスをユーザがそれを通して制御することができる制御ポイント（Ｃｏｎｔｒｏｌ ｐｏｉｎｔ）という２つのクラスの機能的エンティティを定義する。Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ（ＳＳＤＰ）として知られる、ＵＰｎＰのサービス発見プロトコルは、新規デバイスが、それ自体をそのネットワーク内の制御ポイントに広告することを可能にする。同様に、制御ポイントは、ネットワークに参加すると、ＳＳＤＰを使って、ネットワーク内で関心を引くデバイスを検索する。制御ポイントは、サービスを発見した後、サービスの包括的記述（ＸＭＬで表される）を、サービス発見中に取得したＵＲＬから取り出す。このサービス記述ファイルは、組み込まれているサービスのリスト、ならびに制御、イベント通知および提示に関する情報に対するＵＲＬを含む。
ＵＰｎＰのケースにおいて、デバイスは、ネットワークに追加されると、またはデバイスの広告を一新すると、ＮＯＴＩＦＹメッセージをマルチキャスト（またはユニキャスト）する。ＮＯＴＩＦＹメッセージは、以下のものを使う。
・General Event Notification Architecture（ＧＥＮＡ）によって定義されるＮＯＴＩＦＹ動詞
・ＨＯＳＴヘッダー中のＳＳＤＰ用にＩＡＮＡによって予約されたマルチキャストアドレスおよびポート
・ＣＡＣＨＥ−ＣＯＮＴＲＯＬヘッダー中の広告の持続期間
・ＬＯＣＡＴＩＯＮヘッダー中の、発見のための場所
・ＮＴ（通知タイプ）ヘッダー中の広告用の特定タイプ
・ＮＴＳ（通知サブタイプ）ヘッダー中のサブタイプ
○広告用のｓｓｄｐ：ａｌｉｖｅ（付表Ｆの例を参照）
○アップデート用のｓｓｄｐ：ｕｐｄａｔｅ（付表Ｇの例を参照）
○広告をキャンセルするためのｓｓｄｐ：ｂｙｅｂｙｅ（付表Ｈの例を参照）
・ＵＳＮ（ユニークなシリアル番号unique serial number）ヘッダー中でのこの広告に対する一意のＩＤ
ＮＯＴＩＦＹメッセージは、以下のフォーマットで与えられる。
NOTIFY*HTTP/1.1 HOST:(HostAddress):(ServicePort) CACHE-CONTROL:max-age=LifeTime LOCATION:ルートテ゛ハ゛イス用のUPnP記述に対するURL NT: 検索目標NTS: ssdp:alive USN: ユニークなシリアル番号上記において、
NOTIFY このメッセージがサービス広告であることを示す。
HOST 広告されるサービスのＩＰアドレスとポート番号とを与える。デバイスは通常、ＮＯＴＩＦＹメッセージ用に２３９．２５５．２５５．２５０：１９００を使う。
CACHE-CONTROL 広告されるサービスの存続時間を秒で設定する。
LOCATION ルートデバイス用ＵＰｎＰ記述へのＵＲＬを指定する。
NT 広告されるサービスの検索目標を指定する。
NTS ＳＳＤＰの現在の状況を示す。
USN 広告を一意に識別するＵＵＩＤ。
他のタイプのサービス記述言語とは異なり、ＵＰｎＰは、ＮＯＴＩＦＹメッセージの一部として、サービス向けのいかなる名称も定義しないことに留意されたい。ただし、ＮＯＴＩＦＹメッセージは、ＬＯＣＡＴＩＯＮフィールド中にＵＰｎＰ記述用のＵＲＬを含み、このドキュメントは、デバイスによって提供されるサービスの名称を含む、サービスについての追加情報を含む。
ＮＯＴＩＦＹメッセージは、ＵＰｎＰ記述用のＵＲＬを含む。ノードは、サービスを公開するとき、ＮＯＴＩＦＹメッセージのＬＯＣＡＴＩＯＮフィールドにあるＵＰｎＰ記述から情報を抽出し、オーバレイ上で公開する必要もある。この情報は、ＸＭＬで指定される。記述は、２つの部分の中にあり、１つはデバイス用の記述、もう一つはデバイスによって提供される、ネストされたサービスごとの記述である。デバイス記述は、デバイスのタイプと、コンテナプロパティと、デバイスによって指定されるユーザインターフェース（ＵＩ）情報とを含む。デバイス記述は、ＸＭＬフォーマットである。サービスは、デバイス内の機能ユニットであり、コンテナに含まれる。サービス記述ファイルは、メソッドと状態変数（またはプロパティ）とを含み、ＯＷＬ−ＳまたはＷＳＤＬファイルに含まれるものと同様である。
サービスの記述に使われるサンプルＸＭＬファイルが、付表Ｉで与えられている。ＵＰｎＰのケースにおいて、デバイスは、２つの情報セットを公開する必要がある。第１のセットは、ＮＯＴＩＦＹメッセージから導出され、サービス記述の場所についての情報と、ＵＰｎＰ Ｍ−ＳＥＡＲＣＨクエリに回答するのに必要とされるＮＴ／ＳＴ値とを含む。公開されるべき第２の情報セットは、デバイス／サービス記述ファイルからもたらされる。ＧＳＳフォーマットを使ってＮＯＴＩＦＹメッセージ中で情報を公開するために、公開側ノードは、図８に示すＧＳＳ８００を作成しなければならない。
ＮＯＴＩＦＹメッセージは、オーバレイにおいてデバイスを広告し、アップデートし、消去するのに使われる。次のステップは、デバイス／サービス記述ファイルを公開することである。付表Ｉは、ＸＭＬで書かれたＵＰｎＰデバイス記述ファイルの例を挙げており、対応するＧＳＳは、付表Ｊに示してある。こうした付表に見ることができるように、デバイス記述ファイルは、デバイス、モデル、モデル名、製造元、およびモデルＵＲＩについての情報を含む。この情報に加え、デバイス記述ファイルは、<service></service>フィールドに封入されたデバイスによって提供されるサービスについての情報を含む。このフィールドは、サービス記述ファイル用のＵＲＩを含む、サービスについてのさらなる情報を含む。公開プロセスの一部として、サービス提供ピアは、この情報を抽出し、ＧＳＳの形でオーバレイ上で公開する必要もある。
異なる２つのスキーマ（または、この例におけるＷＳＤＬなど、同じ方式の、異なる２つのバージョンでさえも）が、同じドキュメント／クエリを、同じことを意味するが異なるやり方で記述することも可能であろう。たとえば、オーバレイ内のプリンタサービス（ｓｅｒｖｉｃｅ１という）は、servicename=”myprinter”であるｓｃｈｅｍａ１を使って広告することができ、検索要求は、属性printername=”myprinter”である全サービス記述を見つけるために、ｓｃｈｅｍａ２を使って発行することができる。単純な検索システムは、値「ｍｙｐｒｉｎｔｅｒ」に関連づけられた異なる属性をもつので、ｓｅｒｖｉｃｅ１を戻すことはない。というのは、サービスを記述するのに使われるスキーマと、クエリを公式化するスキーマとは異なるからである。ＯＷＬ−ＳおよびＷＳＤＬのケースにおける別の例では、こうしたスキーマは、共通して使われるフィールドを指すのに、それぞれ、textDescriptionおよびdocumentationなど、異なる属性名を利用する。このようなシナリオの１つの扱い方は、簡略化された汎用スキーマを１つ用意し、その全サービスおよびクエリがこのスキーマに従うことを強制することである。ただし、このような解決法は、あまりに制約的であり、新たな未定義の言語の要望に対処することができない。
ＧＳＳ７００は、この問題を扱うために、単純化した手法をとる。ＧＳＳ７００は、上述したように、たとえばservicename、textdescription、hasInput、hasOutputなど、共通して使われるものに対する標準属性名のリストを定義する。こうした属性に対して、ＧＳＳ７００は、固有サービス記述スキーマから対応する値を抽出し、標準属性名とともにオーバレイにおいて公開する。リスト中で具体的に定義されない他の属性に対しては、ＧＳＳ７００は、固有スキーマで定義される属性名を直接公開する。上で定義したプラグイン２０６（図２）は、この公開プロセスを助け、固有属性名を標準属性名に翻訳する。
問い合わせ（querying）は、公開と同じステップに従う。固有属性名に対するクエリが与えられると、プラグイン２０６は、標準属性のリストを調べ、存在する場合、固有属性名を標準のものに翻訳する。このクエリは、標準属性名をもつＳＥＡＲＣＨコマンドを使ってオーバレイに送られる。先に記載したプリンタサービスの例では、「printername=myprinter」という形のクエリに対して、プラグインは、クエリを「servicename=myprinter」に変換し、オーバレイ上で、修正されたクエリを送ることになる。この時点で、検索の出力は、「ｍｙｐｒｉｎｔｅｒ」に関連づけられた同じ属性をもつので、ｓｅｒｖｉｃｅ１を含むことになる。
したがって、正規化されたオーバレイスキーマ２０９の一例は、上述したＧＳＳ７００を含むが、正規化されたオーバレイスキーマ２０９の上述の機能性を実施する、他の具体的スキーマも開発され得ることを理解されたい。
本出願において使われる際、「構成要素」、「モジュール」、「システム」などの用語は、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアなどだが、それに限定されないコンピュータ関連エンティティを含むことを意図している。たとえば、構成要素は、プロセッサ上で稼動するプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータでよいが、それに限定されない。例として、コンピューティングデバイス上で稼動するアプリケーションおよびそのコンピューティングデバイス両方が構成要素となり得る。１つまたは複数の構成要素が実行プロセスおよび／またはスレッド中に存在してよく、構成要素は、１台のコンピュータに配置し、かつ／または２台以上のコンピュータの間に分散してよい。さらに、こうした構成要素は、様々なデータ構造が格納された様々なコンピュータ可読媒体から実行し得る。構成要素は、ローカルおよび／またはリモートプロセスによって、１つまたは複数のデータパケット、たとえば、ローカルシステム、分散型システム内の別の構成要素と、および／またはインターネットなどのネットワークを越えて、他のシステムと信号により対話する、ある構成要素からのデータをもつ信号に従って通信することができ得る。
さらに、様々な態様を、ワイヤード端末でもワイヤレス端末でもよい端末との関連で本明細書に記載してある。端末は、システム、デバイス、加入者ユニット、加入者局、移動局、モバイル、モバイルデバイス、リモートステーション、リモート端末、アクセス端末、ユーザ端末、端末、通信デバイス、ユーザエージェント、ユーザデバイス、またはユーザ機器（ＵＥ）と呼ぶこともできる。ワイヤレス端末は、セルラー電話、衛星電話、コードレス電話、セッション開始プロトコル（ＳＩＰ）電話、無線ローカルループ（ＷＬＬ）局、携帯情報端末（ＰＤＡ）、無線接続機能をもつハンドヘルドデバイス、コンピューティングデバイス、または無線モデムに接続された他の処理デバイスでよい。さらに、様々な態様を、基地局との関連で、本明細書に記載してある。基地局は、ワイヤレス端末（１つまたは複数）との通信に使用することができ、アクセスポイント、ノードＢ、または他の何らかの用語で呼ばれてもよい。
さらに、「または」という用語は、排他的な「または」ではなく、包含的な「または」を意味することを意図している。つまり、特に指定がない限り、または文脈から明らかでない限り、「ＸがＡまたはＢを利用する」というフレーズは、自然な包含的置換のいずれも意味することを意図している。つまり、「ＸがＡまたはＢを利用する」というフレーズは、ＸがＡを利用する、ＸがＢを利用する、またはＸがＡおよびＢ両方を利用する、という事例のいずれによっても満たされる。さらに、本出願および添付の請求項において使われる冠詞「ａ」および「ａｎ」は概して、特に指定がない限り、または単数形を対象とすることが文脈から明らかでない限り、「１つまたは複数」を意味するものと企図されるべきである。
本明細書に記載する技法は、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡおよび他のシステムなど、様々なワイヤレス通信システムに用いられ得る。「システム」および「ネットワーク」という用語はしばしば、入れ換えて使われる。ＣＤＭＡシステムは、たとえばユニバーサル地上無線アクセス（ＵＴＲＡ）、ｃｄｍａ２０００などの無線技術を実装し得る。ＵＴＲＡは、広帯域ＣＤＭＡ（Ｗ−ＣＤＭＡ）およびＣＤＭＡの他の変形体を含む。さらに、ｃｄｍａ２０００は、ＩＳ−２０００、ＩＳ−９５およびＩＳ−８５６標準をカバーする。ＴＤＭＡシステムは、汎欧州デジタルモバイル電話方式（ＧＳＭ（登録商標））などの無線技術を実装し得る。ＯＦＤＭＡシステムは、たとえばＥｖｏｌｖｅｄ ＵＴＲＡ（Ｅ−ＵＴＲＡ）、ウルトラモバイルブロードバンド（ＵＭＢ）、ＩＥＥＥ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ８０２．２０、Ｆｌａｓｈ−ＯＦＤＭなどの無線技術を実装し得る。ＵＴＲＡおよびＥ−ＵＴＲＡは、ユニバーサルモバイル通信システム（ＵＭＴＳ）の一部である。３ＧＰＰロングタームエボリューション（ＬＴＥ）は、Ｅ−ＵＴＲＡを用いるＵＭＴＳのリリースであり、ダウンリンク上ではＯＦＤＭＡを、およびアップリンク上ではＳＣ−ＦＤＭＡを利用する。ＵＴＲＡ、Ｅ−ＵＴＲＡ、ＵＭＴＳ、ＬＴＥおよびＧＳＭは、「第３世代パートナーシッププロジェクト」（３ＧＰＰ）という名称の組織からのドキュメントに記載されている。さらに、ｃｄｍａ２０００およびＵＭＢは、「第３世代パートナーシッププロジェクト２」（３ＧＰＰ２）という名称の組織からのドキュメントに記載されている。さらに、このようなワイヤレス通信システムは、不対無認可スペクトル、８０２．ｘｘワイヤレスＬＡＮ、ブルートゥースおよび他のあらゆる短距離または長距離、ワイヤレス通信技法をしばしば用いるピアツーピア（たとえば、モバイルツーモバイル）アドホックネットワークシステムをさらに含み得る。
いくつかのデバイス、構成要素、モジュールなどを含み得るシステムに関して、様々な態様または特徴を提示する。様々なシステムは、追加デバイス、構成要素、モジュールなどを含んでよく、かつ／または図面に関連して論じたデバイス、構成要素、モジュールなどのすべては含まなくてもよいことを理解されたい。こうした手法の組合せも用いられ得る。
本明細書で開示した態様に関連して記載した様々な例示的論理、論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラム可能ゲートアレイ（ＦＰＧＡ）または他のプログラム可能論理素子、離散ゲートもしくはトランジスタ論理、離散ハードウェア構成要素、または本明細書に記載した機能を実施するように設計されたその任意の組合せで実装され、または実施され得る。汎用プロセッサはマイクロプロセッサでよいが、代替形態では、プロセッサは、従来のどのプロセッサ、コントローラ、マイクロコントローラ、または状態マシンでもよい。プロセッサは、コンピューティングデバイスの組合せ、たとえば、ＤＳＰおよびマイクロプロセッサ、複数のマイクロプロセッサ、ＤＳＰコアを併用する１つもしくは複数のマイクロプロセッサ、または他のこのような任意の構成の組合せとしても実装され得る。さらに、少なくとも１つのプロセッサが、上述したステップおよび／またはアクションの１つまたは複数を実施するように動作可能な１つまたは複数のモジュールを備え得る。
さらに、本明細書で開示した態様に関連して記載した方法またはアルゴリズムのステップおよび／またはアクションは、直接ハードウェアとして、プロセッサによって実行されるソフトウェアモジュールとして、またはこの２つの組合せとしても実施することができ得る。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取外し可能ディスク、ＣＤ−ＲＯＭ、または当該分野において公知である他のどの形の記憶媒体の中にも存在し得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読むとともに情報を書き込めるように、プロセッサに結合され得る。代替形態では、記憶媒体は、プロセッサに統合され得る。さらに、一部の態様では、プロセッサおよび記憶媒体は、ＡＳＩＣに存在し得る。さらに、ＡＳＩＣは、ユーザ端末に存在し得る。代替態様では、プロセッサおよび記憶媒体は、離散構成要素としてユーザ端末に存在し得る。さらに、いくつかの態様では、方法またはアルゴリズムのステップおよび／またはアクションは、コンピュータプログラム製品に組み込まれ得る機械可読媒体および／またはコンピュータ可読媒体上に、コードおよび／または命令の１つまたは任意の組合せまたはセットとして存在し得る。
１つまたは複数の態様では、記載した機能は、ハードウェア、ソフトウェア、ファームウェア、またはその組合せで実装され得る。ソフトウェアで実装される場合、機能は、コンピュータ可読媒体に１つまたは複数の命令またはコードとして格納され、または送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を容易にするどの媒体も含むコンピュータ記憶媒体および通信媒体両方を含む。記憶媒体は、コンピュータによってアクセスされ得る市販されているどの媒体でもよい。限定ではなく例として、このようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくは他の光ディスク記憶、磁気ディスク記憶もしくは他の磁気記憶デバイス、または所望のプログラムコードを命令もしくはデータ構造の形で搬送し、もしくは格納するのに使われ、コンピュータによってアクセスされ得る他のどの媒体も備え得る。また、どの接続も、コンピュータ可読媒体と呼ばれ得る。たとえば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者線（ＤＳＬ）、または赤外線、ラジオ、およびマイクロ波などの無線技術を使ってウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、または赤外線、ラジオ、およびマイクロ波などの無線技術は、媒体の定義に含まれる。本明細書で使用するディスク（ｄｉｓｋ）およびディスク（ｄｉｓｃ）は、コンパクトディスク（ＣＤ）、レーザディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピー（登録商標）ディスク、およびブルーレイディスクを含むが、ディスク（ｄｉｓｋ）は通常はデータを磁気的に再現し、ディスク（ｄｉｓｃ）は通常、データをレーザで光学的に再現する。上記の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。
上記開示では、例示的態様および／または態様を論じているが、記載した態様および／または添付の請求項によって定義される態様の範囲から逸脱することなく、本明細書において様々な変更および修正を行ってよいことに留意されたい。さらに、記載した態様および／または態様の要素は、単数形で記載され、権利請求される場合があるが、単数形への限定が明示的に記載されていない限り、複数形も企図される。さらに、特に記載のない限り、任意の態様および／または態様の全部または一部分が、他の任意の態様および／または態様の全部または一部分とともに利用され得る。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
ネットワーク内でサービスを公開または発見する方法であって、
ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信することと、
前記固有サービス記述から１つまたは複数のキーワードを抽出することと、各キーワードは前記ネットワーク上でのサービス発見に必要とされる情報に対応し、
前記固有サービス記述から、前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出することと、
必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って、検索可能サービス記述を生成することと、前記必須フィールドは前記固有サービス記述から抽出された各キーワードを備え、前記キーワードとともに公開フィールドは各抽出されたキーワードに対応する前記抽出された追加情報を備え、
前記サービスを広告するために、前記ネットワークに前記検索可能サービス記述を公開することと、
を備える方法。
［Ｃ２］
前記正規化スキーマの前記必須フィールドおよび前記キーワードとともに公開フィールドは、それぞれ、複数の固有サービス記述言語のそれぞれにおける、１つまたは複数の対応するプロパティにマッピングされる、Ｃ１記載の方法。
［Ｃ３］
前記マッッピングは、前記固有サービス記述属性名に対応する複数の標準属性名から選択される標準属性名を選択することと、前記標準属性名を、前記固有サービス記述属性名に対応する、前記固有サービス記述から抽出された固有属性値に関連づけることと、をさらに備え、
記生成することは、前記標準属性名および前記対応する固有属性値をもつ前記検索可能サービス記述を生成することをさらに備える、Ｃ２記載の方法。
［Ｃ４］
前記マッピングは、前記固有サービス記述から前記固有サービス記述属性名と前記対応する固有属性値とを抽出することをさらに備え、前記生成することは、前記固有サービス記述属性名および前記対応する固有属性値をもつ前記検索可能サービス記述を生成することをさらに備える、Ｃ２記載の方法。
［Ｃ５］
前記検索可能サービス記述を生成することは、正規化された拡張マークアップ言語（ＸＭＬ）属性値のペアまたは資源記述フレームワーク（ＲＤＦ：Resource Description Framework）トリプルを生成することをさらに備える、Ｃ１記載の方法。
［Ｃ６］
１つまたは複数のキーワードを抽出することは、サービス名に対応する第１のキーワードと、サービス記述言語に対応する第２のキーワードとを抽出することをさらに備え、
追加情報を抽出することは、各抽出されたキーワードに対応するキーワード特有情報または各抽出されたキーワードに対応するサービス特有情報のうちの１つまたは複数を抽出することをさらに備える、Ｃ１記載の方法。
［Ｃ７］
１つまたは複数のキーワードを抽出することは、追加検索キーワードを含むテキスト記述に対応する第３のキーワードと、前記サービスへのコンタクトの仕方を記述するコンタクト情報に対応する第４のキーワードと、前記サービスに関連があるとともに他のフィールドによって記述されない検索キーワードのリストに対応する第５のキーワードとのうちの１つまたは複数を抽出することをさらに備え、
キーワード特有情報を抽出することは、各キーワードが出現する出現回数を抽出することをさらに備え、
サービス特有情報を抽出することは、サービス評価またはコンタクト情報のうちの少なくとも１つを抽出することをさらに備える、Ｃ６に記載の方法。
［Ｃ８］
前記固有サービス記述から、前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数のオプション情報を抽出すること、をさらに備え、各オプション情報はサービス発見に必須でなく、
前記生成することは、オプションフィールドをさらに有する前記正規化スキーマに従って前記検索可能サービス記述を生成することをさらに備え、前記オプションフィールドは、各抽出されたキーワードに対応する各オプション情報を備える、
Ｃ１記載の方法。
［Ｃ９］
前記オプション情報は、
前記サービスが受け取る入力のタイプについての情報、
前記サービスが生成する出力のタイプについての情報、
前記サービスの前提条件および前提条件インスタンスに及ぶ範囲についての情報、
前記サービスの結果、およびどのような条件で前記出力が生成されるかのうちの１つについての情報、
前記サービスへのコンタクトの仕方についての情報、
前記サービスの公開元についての情報、および
前記サービスに関連があるとともに他のフィールドによって記述されない他のキーワードのリスト
のうちの少なくとも１つを備える、Ｃ８記載の方法。
［Ｃ１０］
第２の固有サービス記述言語での固有サービスクエリを受信することと、
前記固有サービスクエリを、前記正規化スキーマに従って検索可能クエリに翻訳することと、
前記正規化スキーマでのクエリ結果を受信することと、
固有クエリ結果を定義するために、前記クエリ結果を、前記正規化スキーマから前記第２の固有サービス記述言語に翻訳することと、
前記固有クエリ結果を送信することと、
をさらに備える、Ｃ１記載の方法。
［Ｃ１１］
前記ネットワークは分散型オーバレイネットワークである、Ｃ１記載の方法。
［Ｃ１２］
前記ネットワークは発見サービスを提供するように構成されたサーバを備える、Ｃ１記載の方法。
［Ｃ１３］
ネットワーク内でサービスを公開または発見するように構成された少なくとも１つのプロセッサであって、
ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信する第１のモジュールと、
前記固有サービス記述から１つまたは複数のキーワードを抽出する第２のモジュールと、各キーワードは、前記ネットワーク上でのサービス発見に必要とされる情報に対応し、
前記固有サービス記述から、前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出する第３のモジュールと、
必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成する第４のモジュールと、前記必須フィールドは前記固有サービス記述から抽出された各キーワードを備え、前記キーワードとともに公開フィールドは各抽出されたキーワードに対応する前記抽出された追加情報を備え、
前記サービスを広告するために、前記ネットワークに前記検索可能サービス記述を公開する第５のモジュールと、
を備えるプロセッサ。
［Ｃ１４］
コンピュータに、ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信させる第１のコードセットと、
前記コンピュータに、前記固有サービス記述から１つまたは複数のキーワードを抽出させる第２のコードセットと、各キーワードは前記ネットワーク上でのサービス発見に必要とされる情報に対応し、
前記コンピュータに、前記固有サービス記述から、前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出させる第３のコードセットと、
前記コンピュータに、必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成させる第４のコードセットと、前記必須フィールドは前記固有サービス記述から抽出された各キーワードを備え、前記キーワードとともに公開フィールドは、各抽出キーワードに対応する前記抽出された追加情報を備え、
前記コンピュータに、前記サービスを広告するために、前記ネットワークに前記検索可能サービス記述を公開させる第５のコードセットと、
を備えるコンピュータ可読媒体を備えるコンピュータプログラム製品。
［Ｃ１５］
ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信する手段と、
前記固有サービス記述から１つまたは複数のキーワードを抽出する手段と、各キーワードは前記ネットワーク上でのサービス発見に必要とされる情報に対応し、
前記固有サービス記述から、前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出する手段と、
必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成する手段と、前記必須フィールドは前記固有サービス記述から抽出された各キーワードを備え、前記キーワードとともに公開フィールドは各抽出キーワードに対応する前記抽出された追加情報を備え、
前記サービスを広告するために、前記ネットワークに前記検索可能サービス記述を公開する手段と、
を備える装置。
［Ｃ１６］
ネットワーク内でサービスを公開する装置であって、
ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信する受信機と、
検索可能スキーマプラグイン構成要素と、前記検索可能スキーマプラグイン構成要素は、
前記固有サービス記述から１つまたは複数のキーワードを抽出し、各キーワードは前記ネットワーク上でのサービス発見に必要とされる情報に対応し、
前記固有サービス記述から、前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出し、
必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成し、前記必須フィールドは前記固有サービス記述から抽出された各キーワードを備え、前記キーワードとともに公開フィールドは各抽出されたキーワードに対応する前記抽出された追加情報を備え、
前記サービスを広告するために、前記ネットワークに前記検索可能サービス記述を公開する公開処理構成要素と、
を備える装置。
［Ｃ１７］
前記検索可能スキーマプラグイン構成要素は、さらに、前記正規化スキーマの前記必須フィールドおよび前記キーワードとともに公開フィールドのそれぞれを、複数の固有サービス記述言語それぞれにおける１つまたは複数の対応するプロパティにマッピングする、Ｃ１６に記載の装置。
［Ｃ１８］
前記検索可能スキーマプラグイン構成要素は、さらに、
前記固有サービス記述属性名に対応する複数の標準属性名から選択される標準属性名を選択し、
前記標準属性名を、前記固有検索記述属性名に対応する前記固有サービス記述から抽出された固有属性値に関連づけ、
前記標準属性名および前記対応する固有属性値をもつ前記検索可能サービス記述を生成する、
Ｃ１７記載の装置。
［Ｃ１９］
検索可能スキーマプラグイン構成要素は、さらに、
前記固有サービス記述から前記固有サービス記述属性名と前記対応する固有属性値とを抽出し、
前記固有サービス記述属性名および前記対応する固有属性値をもつ前記検索可能サービス記述を生成する
Ｃ１７記載の装置。
［Ｃ２０］
前記検索可能スキーマプラグイン構成要素は、さらに、正規化された拡張マークアップ言語（ＸＭＬ）属性値のペアまたは資源記述フレームワーク（ＲＤＦ：Resource Description Framework）トリプルを生成する、Ｃ１６記載の装置。
［Ｃ２１］
前記検索可能スキーマプラグイン構成要素は、さらに、
サービス名に対応する第１のキーワードと、サービス記述言語に対応する第２のキーワードとを抽出し、
各抽出されたキーワードに対応するキーワード特有情報または各抽出されたキーワードに対応するサービス特有情報のうちの１つまたは複数を抽出する、
Ｃ１６記載の装置。
［Ｃ２２］
前記検索可能スキーマプラグイン構成要素は、さらに、
追加検索キーワードを含むテキスト記述に対応する第３のキーワード、前記サービスへのコンタクトの仕方を記述するコンタクト情報に対応する第４のキーワードと、前記サービスに関連があるとともに他のフィールドによって記述されない検索キーワードのリストに対応する第５のキーワードとのうちの１つまたは複数を抽出し、
各キーワードの出現回数を抽出し、
サービス評価またはコンタクト情報のうちの少なくとも１つを抽出する、
Ｃ２１記載の装置。
［Ｃ２３］
前記検索可能スキーマプラグイン構成要素は、さらに、
前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数のオプション情報を、前記固有サービス記述から抽出し、各オプション情報はサービス発見に必須でなく、
オプションフィールドをさらに有する前記正規化スキーマに従って前記検索可能サービス記述を生成し、前記オプションフィールドは各抽出されたキーワードに対応する各オプション情報を備える、
Ｃ１６記載の装置。
［Ｃ２４］
前記オプション情報は、
前記サービスが受け取る入力のタイプについての情報、
前記サービスが生成する出力のタイプについての情報、
前記サービスの前提条件および前提条件インスタンスに及ぶ範囲についての情報、
前記サービスの結果、およびどのような条件で前記出力が生成されるかのうちの１つについての情報、
前記サービスへのコンタクトの仕方についての情報、
前記サービスの公開元についての情報、ならびに
前記サービスに関連があるとともに他のフィールドによって記述されない他のキーワードのリスト、
のうちの少なくとも１つを備える、Ｃ２３記載の装置。
［Ｃ２５］
第２の固有記述言語での固有サービスクエリを受信し、前記固有サービスクエリを、前記正規化スキーマに従って検索可能サービスクエリに翻訳し、前記正規化スキーマでのクエリ結果を受信し、固有クエリ結果を定義するために、前記クエリ結果を、前記正規化スキーマから前記第２の固有記述言語に翻訳し、前記固有クエリ結果を送信するクエリ処理構成要素、をさらに備えるＣ１６記載の装置。
［Ｃ２６］
前記ネットワークは分散型オーバレイネットワークである、Ｃ１６記載の装置。
［Ｃ２７］
前記ネットワークは発見サービスを提供するように構成されたサーバを備える、Ｃ１６に記載装置。
［Ｃ２８］
ネットワーク検索クエリを処理する方法であって、
固有サービス記述言語での固有サービスクエリを受信することと、
前記固有サービスクエリを、前記正規化スキーマに従って検索可能クエリに翻訳することと、
前記固有検索クエリによって識別されるサービスを求めてネットワークを検索することと、前記検索は前記正規化スキーマに従って実施され、
検索結果を、前記正規化スキーマから前記固有検索記述言語に翻訳することと、
を備える方法。
付表ＡＢｒａｖｏ Ａｉｒサービス用ＯＷＬ−Ｓスキーマ
Figure 0005886376
Figure 0005886376
Figure 0005886376
Figure 0005886376
Figure 0005886376
Figure 0005886376
付表ＢＢｒａｖｏ Ａｉｒサービス用Ｇｅｎｉｅ検索可能スキーマ
Figure 0005886376
Figure 0005886376
Figure 0005886376
付表ＣＳｔｏｃｋ Ｑｕｏｔａサービス用ＷＳＤＬ１．１スキーマ
Figure 0005886376
Figure 0005886376
付表ＤＳｔｏｃｋ ＱｕｏｔｅサービスのＷＳＤＬ１．１スキーマからＷＳＤＬ２．０への変換［ＷＳＤＬＥｘａｍｐｌｅ］からの例
Figure 0005886376
Figure 0005886376
付表ＥＳｔｏｃｋ Ｑｕｏｔｅサービス用ＧＳＳスキーマ
Figure 0005886376
Figure 0005886376
付表ＦＮＯＴＩＦＹを使ってのＵＰｎＰデバイスの公開以下は、ＵＰｎＰサービスを公開するＵＰｎＰコマンドを指定する：
ＮＯＴＩＦＹ＊ＨＴＴＰ／１．１
ＨＯＳＴ：（ＨｏｓｔＡｄｄｒｅｓｓ）：（ＳｅｒｖｉｃｅＰｏｒｔ）
ＣＡＣＨＥ−ＣＯＮＴＲＯＬ：ｍａｘ−ａｇｅ＝ＬｉｆｅＴｉｍｅ
ＬＯＣＡＴＩＯＮ：ルートデバイス用ＵＰｎＰ記述に対するＵＲＬ
ＮＴ：検索目標
ＮＴＳ：ｓｓｄｐ：ａｌｉｖｅ
ＵＳＮ：ユニークなシリアル番号この情報は、ＧＳＳで以下のように表される：
Figure 0005886376
この情報がＧＳＳに変換されると、公開側ノードは、ＬＯＣＡＴＩＯＮフィールドからＸＭＬデバイス／サービス記述ファイルをダウンロードし、オーバレイ上で別個に公開する必要がある。
付表ＧＮＯＴＩＦＹを使ってのＵＰｎＰデバイスのアップデート以下は、ＵＰｎＰサービスをアップデートするＵＰｎＰコマンドを指定する：
ＮＯＴＩＦＹ＊ＨＴＴＰ／１．１
ＨＯＳＴ：（ＨｏｓｔＡｄｄｒｅｓｓ）：（ＳｅｒｖｉｃｅＰｏｒｔ）
ＣＡＣＨＥ−ＣＯＮＴＲＯＬ：ｍａｘ−ａｇｅ＝ＬｉｆｅＴｉｍｅ
ＬＯＣＡＴＩＯＮ：ルートデバイス用ＵＰｎＰ記述に対するＵＲＬ
ＮＴ：検索目標
ＮＴＳ：ｓｓｄｐ：ｕｐｄａｔｅ
ＵＳＮ：ユニークなシリアル番号この情報は、サービスがどのように公開されるかと同様に、以下のようにＧＳＳで表される：
Figure 0005886376
この情報がＧＳＳに変換されると、公開側ノードは、ＬＯＣＡＴＩＯＮフィールドからＸＭＬデバイス／サービス記述ファイルをダウンロードし、アップデートされた情報をオーバレイが確実にもつようにするために、再度オーバレイ上で公開する必要もある。
付表ＨＮＯＴＩＦＹを使ってのＵＰｎＰデバイスの消去以下は、ＵＰｎＰサービスを消去するＵＰｎＰコマンドを指定する：
ＮＯＴＩＦＹ＊ＨＴＴＰ／１．１
ＨＯＳＴ：（ＨｏｓｔＡｄｄｒｅｓｓ）：（ＳｅｒｖｉｃｅＰｏｒｔ）
ＮＴ：検索目標
ＮＴＳ：ｓｓｄｐ：ｂｙｅｂｙｅ
ＵＳＮ：ユニークなシリアル番号サービスを担当するピアは、デバイス／サービス記述ファイルのロケーションとともに、ピアが提供するサービスのリストを用いてテーブルを維持する必要がある。ＮＯＴＩＦＹメッセージ（上記の通り）を使って消去コマンドが発行されると、担当ピアは、デバイス／サービス記述ファイルを取得し、ファイル中のキーワードごとに消去コマンドを送る必要がある。あるいは、格納側ノードが、存続期間が満了したときにキーワードを消去してよい。
付表ＩＵＰｎＰデバイス用の例示的ＸＭＬスキーマ
Figure 0005886376
Figure 0005886376
付表ＪＸＭＬスキーマからＧＳＳへの変換
Figure 0005886376

Claims (21)

  1. ネットワーク内でサービスを公開または発見する方法であって、前記方法はコンピュータデバイスが実行し、
    ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信することと、
    前記固有サービス記述から１つまたは複数のキーワードを抽出することと、各キーワードは前記ネットワーク上でのサービス発見に必要とされる情報に対応し、
    前記固有サービス記述から、前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出することと、
    必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って、検索可能サービス記述を生成することと、前記必須フィールドは前記固有サービス記述から抽出された各キーワードを備え、前記キーワードとともに公開フィールドは各抽出されたキーワードに対応する前記抽出された追加情報を備え、
    前記サービスを広告するために、前記ネットワークに前記検索可能サービス記述を公開することと、
    第２の固有サービス記述言語での固有サービスクエリを受信することと、
    前記固有サービスクエリを、前記正規化スキーマに従って検索可能クエリに翻訳することと、前記検索可能クエリに合致するサービスを求めて前記ネットワークの検索が実施され、
    を備え、
    前記正規化スキーマの前記必須フィールドおよび前記キーワードとともに公開フィールドは、それぞれ、複数の固有サービス記述言語のそれぞれにおける、１つまたは複数の対応する属性にマッピングされ、
    前記マッピングは、各固有サービス記述属性名に対し標準属性名を定義し、
    前記１つまたは複数のキーワードを抽出することは、前記標準属性名にマッピングされた前記固有サービス記述属性名に対応する固有属性値を抽出することを備え、
    前記生成することは、
    前記標準属性名に、前記固有サービス記述から抽出された前記固有属性値を関連づけることと、
    前記標準属性名および前記対応する固有属性値をもつ前記検索可能サービス記述を生成することと、を備える、方法。
  2. 前記検索可能サービス記述を生成することは、正規化された拡張マークアップ言語（ＸＭＬ）属性値のペアまたはリソース記述フレームワーク（ＲＤＦ：Resource Description Framework）トリプルを生成することをさらに備える、請求項１記載の方法。
  3. １つまたは複数のキーワードを抽出することは、サービス名に対応する第１のキーワードと、サービス記述言語に対応する第２のキーワードとを抽出することをさらに備え、
    追加情報を抽出することは、各抽出されたキーワードに対応するキーワード特有情報または各抽出されたキーワードに対応するサービス特有情報のうちの１つまたは複数を抽出することをさらに備える、請求項１記載の方法。
  4. １つまたは複数のキーワードを抽出することは、追加検索キーワードを含むテキスト記述に対応する第３のキーワードと、前記サービスへのコンタクトの仕方を記述するコンタクト情報に対応する第４のキーワードと、前記サービスに関連があるとともに他のフィールドによって記述されない検索キーワードのリストに対応する第５のキーワードとのうちの１つまたは複数を抽出することをさらに備え、
    キーワード特有情報を抽出することは、各キーワードが出現する出現回数を抽出することをさらに備え、
    サービス特有情報を抽出することは、サービス評価またはコンタクト情報のうちの少なくとも１つを抽出することをさらに備える、請求項３に記載の方法。
  5. 前記固有サービス記述から、前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数のオプション情報を抽出すること、をさらに備え、各オプション情報はサービス発見に必須でなく、
    前記生成することは、オプションフィールドをさらに有する前記正規化スキーマに従って前記検索可能サービス記述を生成することをさらに備え、前記オプションフィールドは、各抽出されたキーワードに対応する各オプション情報を備える、
    請求項１記載の方法。
  6. 前記オプション情報は、
    前記サービスが受け取る入力のタイプについての情報、
    前記サービスが生成する出力のタイプについての情報、
    前記サービスの前提条件および前提条件インスタンスに及ぶ範囲についての情報、
    前記サービスの結果、およびどのような条件で前記出力が生成されるかのうちの１つについての情報、
    前記サービスへのコンタクトの仕方についての情報、
    前記サービスの公開元についての情報、および
    前記サービスに関連があるとともに他のフィールドによって記述されない他のキーワードのリスト
    のうちの少なくとも１つを備える、請求項５記載の方法。
  7. 前記正規化スキーマでのクエリ結果を受信することと、
    固有クエリ結果を定義するために、前記クエリ結果を、前記正規化スキーマから前記第２の固有サービス記述言語に翻訳することと、
    前記固有クエリ結果を送信することと、
    をさらに備える、請求項１記載の方法。
  8. 前記ネットワークは分散型オーバレイネットワークである、請求項１記載の方法。
  9. 前記ネットワークは発見サービスを提供するように構成されたサーバを備える、請求項１記載の方法。
  10. ネットワーク内でサービスを公開または発見するように構成された少なくとも１つのプロセッサであって、
    ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信する第１のモジュールと、
    前記固有サービス記述から１つまたは複数のキーワードを抽出する第２のモジュールと、各キーワードは、前記ネットワーク上でのサービス発見に必要とされる情報に対応し、
    前記固有サービス記述から、前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出する第３のモジュールと、
    必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成する第４のモジュールと、前記必須フィールドは前記固有サービス記述から抽出された各キーワードを備え、前記キーワードとともに公開フィールドは各抽出されたキーワードに対応する前記抽出された追加情報を備え、
    前記サービスを広告するために、前記ネットワークに前記検索可能サービス記述を公開する第５のモジュールと、
    第２の固有サービス記述言語での固有サービスクエリを受信し、前記固有サービスクエリを、前記正規化スキーマに従って検索可能クエリに翻訳する第６のモジュールと、前記検索可能クエリに合致するサービスを求めて前記ネットワークの検索が実施され、
    を備え、
    前記正規化スキーマの前記必須フィールドおよび前記キーワードとともに公開フィールドは、それぞれ、複数の固有サービス記述言語のそれぞれにおける、１つまたは複数の対応する属性にマッピングされ、
    前記マッピングは、各固有サービス記述属性名に対し標準属性名を定義し、
    前記第２のモジュールは、前記標準属性名にマッピングされた前記固有サービス記述属性名に対応する固有属性値を抽出し、
    前記第４のモジュールは、
    前記標準属性名に、前記固有サービス記述から抽出された前記固有属性値を関連づけ、
    前記標準属性名および前記対応する固有属性値をもつ前記検索可能サービス記述を生成する、プロセッサ。
  11. コンピュータに、ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信させる第１のコードセットと、
    前記コンピュータに、前記固有サービス記述から１つまたは複数のキーワードを抽出させる第２のコードセットと、各キーワードは前記ネットワーク上でのサービス発見に必要とされる情報に対応し、
    前記コンピュータに、前記固有サービス記述から、前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出させる第３のコードセットと、
    前記コンピュータに、必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成させる第４のコードセットと、前記必須フィールドは前記固有サービス記述から抽出された各キーワードを備え、前記キーワードとともに公開フィールドは、各抽出キーワードに対応する前記抽出された追加情報を備え、
    前記コンピュータに、前記サービスを広告するために、前記ネットワークに前記検索可能サービス記述を公開させる第５のコードセットと、
    前記コンピュータに、第２の固有サービス記述言語での固有サービスクエリを受信させ、前記固有サービスクエリを、前記正規化スキーマに従って検索可能クエリに翻訳させる第６のコードセットと、前記検索可能クエリに合致するサービスを求めて前記ネットワークの検索が実施され、
    を備え、
    前記正規化スキーマの前記必須フィールドおよび前記キーワードとともに公開フィールドは、それぞれ、複数の固有サービス記述言語のそれぞれにおける、１つまたは複数の対応する属性にマッピングされ、
    前記マッピングは、各固有サービス記述属性名に対し標準属性名を定義し、
    １つまたは複数のキーワードを抽出することは、前記標準属性名にマッピングされた前記固有サービス記述属性名に対応する固有属性値を抽出することを備え、
    前記生成することは、
    前記標準属性名に、前記固有サービス記述から抽出された前記固有属性値を関連づけることと、
    前記標準属性名および前記対応する固有属性値をもつ前記検索可能サービス記述を生成することと、を備えるコンピュータプログラム。
  12. ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信する手段と、
    前記固有サービス記述から１つまたは複数のキーワードを抽出する手段と、各キーワードは前記ネットワーク上でのサービス発見に必要とされる情報に対応し、
    前記固有サービス記述から、前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出する手段と、
    必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成する手段と、前記必須フィールドは前記固有サービス記述から抽出された各キーワードを備え、前記キーワードとともに公開フィールドは各抽出キーワードに対応する前記抽出された追加情報を備え、
    前記サービスを広告するために、前記ネットワークに前記検索可能サービス記述を公開する手段と、
    第２の固有サービス記述言語での固有サービスクエリを受信し、前記固有サービスクエリを、前記正規化スキーマに従って検索可能クエリに翻訳する手段と、前記検索可能クエリに合致するサービスを求めて前記ネットワークの検索が実施され、
    を備え、
    前記正規化スキーマの前記必須フィールドおよび前記キーワードとともに公開フィールドは、それぞれ、複数の固有サービス記述言語のそれぞれにおける、１つまたは複数の対応する属性にマッピングされ、
    前記マッピングは、各固有サービス記述属性名に対し標準属性名を定義し、
    前記１つまたは複数のキーワードを抽出する手段は、前記標準属性名にマッピングされた前記固有サービス記述属性名に対応する固有属性値を抽出する手段を備え、
    前記生成する手段は、
    前記標準属性名に、前記固有サービス記述から抽出された前記固有属性値を関連づける手段と、
    前記標準属性名および前記対応する固有属性値をもつ前記検索可能サービス記述を生成する手段と、を備える装置。
  13. ネットワーク内でサービスを公開する装置であって、
    ネットワーク内での公開のために、第１のサービス記述言語での、サービスの固有サービス記述を受信する受信機と、
    検索可能スキーマプラグイン構成要素と、前記検索可能スキーマプラグイン構成要素は、
    前記固有サービス記述から１つまたは複数のキーワードを抽出し、各キーワードは前記ネットワーク上でのサービス発見に必要とされる情報に対応し、
    前記固有サービス記述から、前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数の追加情報を抽出し、
    必須フィールドとキーワードとともに公開フィールドとをもつ正規化スキーマに従って検索可能サービス記述を生成し、前記必須フィールドは前記固有サービス記述から抽出された各キーワードを備え、前記キーワードとともに公開フィールドは各抽出されたキーワードに対応する前記抽出された追加情報を備え、
    前記サービスを広告するために、前記ネットワークに前記検索可能サービス記述を公開する公開処理構成要素と、
    第２の固有記述言語での固有サービスクエリを受信し、前記固有サービスクエリを、前記正規化スキーマに従って検索可能サービスクエリに翻訳するクエリ処理構成要素と、前記検索可能クエリに合致するサービスを求めて前記ネットワークの検索が実施され、
    を備え、
    前記正規化スキーマの前記必須フィールドおよび前記キーワードとともに公開フィールドは、それぞれ、複数の固有サービス記述言語のそれぞれにおける、１つまたは複数の対応する属性にマッピングされ、
    前記マッピングは、各固有サービス記述属性名に対し標準属性名を定義し、
    前記１つまたは複数のキーワードを抽出することは、前記標準属性名にマッピングされた前記固有サービス記述属性名に対応する固有属性値を抽出することを備え、
    前記生成することは、
    前記標準属性名に、前記固有サービス記述から抽出された前記固有属性値を関連づけることと、
    前記標準属性名および前記対応する固有属性値をもつ前記検索可能サービス記述を生成することと、を備える装置。
  14. 前記検索可能スキーマプラグイン構成要素は、さらに、正規化された拡張マークアップ言語（ＸＭＬ）属性値のペアまたはリソース記述フレームワーク（ＲＤＦ：Resource Description Framework）トリプルを生成する、請求項１３記載の装置。
  15. 前記検索可能スキーマプラグイン構成要素は、さらに、
    サービス名に対応する第１のキーワードと、サービス記述言語に対応する第２のキーワードとを抽出し、
    各抽出されたキーワードに対応するキーワード特有情報または各抽出されたキーワードに対応するサービス特有情報のうちの１つまたは複数を抽出する、
    請求項１３記載の装置。
  16. 前記検索可能スキーマプラグイン構成要素は、さらに、
    追加検索キーワードを含むテキスト記述に対応する第３のキーワード、前記サービスへのコンタクトの仕方を記述するコンタクト情報に対応する第４のキーワードと、前記サービスに関連があるとともに他のフィールドによって記述されない検索キーワードのリストに対応する第５のキーワードとのうちの１つまたは複数を抽出し、
    各キーワードの出現回数を抽出し、
    サービス評価またはコンタクト情報のうちの少なくとも１つを抽出する、
    請求項１５記載の装置。
  17. 前記検索可能スキーマプラグイン構成要素は、さらに、
    前記１つまたは複数の抽出されたキーワードのそれぞれに対応する１つまたは複数のオプション情報を、前記固有サービス記述から抽出し、各オプション情報はサービス発見に必須でなく、
    オプションフィールドをさらに有する前記正規化スキーマに従って前記検索可能サービス記述を生成し、前記オプションフィールドは各抽出されたキーワードに対応する各オプション情報を備える、
    請求項１３記載の装置。
  18. 前記オプション情報は、
    前記サービスが受け取る入力のタイプについての情報、
    前記サービスが生成する出力のタイプについての情報、
    前記サービスの前提条件および前提条件インスタンスに及ぶ範囲についての情報、
    前記サービスの結果、およびどのような条件で前記出力が生成されるかのうちの１つについての情報、
    前記サービスへのコンタクトの仕方についての情報、
    前記サービスの公開元についての情報、ならびに
    前記サービスに関連があるとともに他のフィールドによって記述されない他のキーワードのリスト、
    のうちの少なくとも１つを備える、請求項１７記載の装置。
  19. 前記クエリ処理構成要素は、さらに、前記正規化スキーマでのクエリ結果を受信し、固有クエリ結果を定義するために、前記クエリ結果を、前記正規化スキーマから前記第２の固有記述言語に翻訳し、前記固有クエリ結果を送信する、請求項１３記載の装置。
  20. 前記ネットワークは分散型オーバレイネットワークである、請求項１３記載の装置。
  21. 前記ネットワークは発見サービスを提供するように構成されたサーバを備える、請求項１３に記載装置。
JP2014143385A 2009-06-11 2014-07-11 構造化メタデータに基づく発見を公開するプラグインモデルのための方法および装置 Expired - Fee Related JP5886376B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US18631909P 2009-06-11 2009-06-11
US61/186,319 2009-06-11
US12/797,940 2010-06-10
US12/797,940 US9043409B2 (en) 2009-06-11 2010-06-10 Methods and apparatus for a plug-in model for publishing structured meta-data based discovery

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2012515206A Division JP2012530299A (ja) 2009-06-11 2010-06-11 構造化メタデータに基づく発見を公開するプラグインモデルのための方法および装置

Publications (2)

Publication Number Publication Date
JP2014241141A JP2014241141A (ja) 2014-12-25
JP5886376B2 true JP5886376B2 (ja) 2016-03-22

Family

ID=42988180

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2012515206A Withdrawn JP2012530299A (ja) 2009-06-11 2010-06-11 構造化メタデータに基づく発見を公開するプラグインモデルのための方法および装置
JP2014143385A Expired - Fee Related JP5886376B2 (ja) 2009-06-11 2014-07-11 構造化メタデータに基づく発見を公開するプラグインモデルのための方法および装置

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2012515206A Withdrawn JP2012530299A (ja) 2009-06-11 2010-06-11 構造化メタデータに基づく発見を公開するプラグインモデルのための方法および装置

Country Status (7)

Country Link
US (1) US9043409B2 (ja)
EP (1) EP2441234A1 (ja)
JP (2) JP2012530299A (ja)
KR (1) KR101357704B1 (ja)
CN (1) CN102461125B (ja)
TW (1) TW201108006A (ja)
WO (1) WO2010144889A1 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9547676B2 (en) 2010-03-30 2017-01-17 Disos Pty Ltd. Cloud computing operating system and method
US20120158772A1 (en) * 2010-12-20 2012-06-21 Sap Ag Automated generation of structured service descriptions from semi-structured enterprise service repositories
JP5874214B2 (ja) * 2011-06-24 2016-03-02 ソニー株式会社 情報処理装置、プログラム、情報処理方法及び情報処理システム
CN103888954A (zh) * 2012-12-20 2014-06-25 中国人民解放军总参谋部第六十一研究所 一种面向服务的无线电架构sora
US20140316808A1 (en) * 2013-04-23 2014-10-23 Lexmark International Technology Sa Cross-Enterprise Electronic Healthcare Document Sharing
US9913308B2 (en) 2013-10-28 2018-03-06 Koninklijke Kpn N.V. Device-to-device discovery and control in a wide area network
CN103716308B (zh) * 2013-12-17 2017-04-12 北京京东尚科信息技术有限公司 一种多协议平台通信方法及多协议平台
US10372689B1 (en) * 2014-08-04 2019-08-06 Intuit, Inc. Consumer-defined service endpoints
US10353955B2 (en) * 2014-11-06 2019-07-16 Lexisnexis, A Division Of Reed Elsevier Inc. Systems and methods for normalized schema comparison
US10455401B2 (en) * 2015-02-24 2019-10-22 Apple Inc. Neighbor awareness networking datapath—reciprocation and coexistence
CN107667544B (zh) * 2015-06-04 2021-11-09 瑞典爱立信有限公司 控制移动终端的通信模式
CN105426200B (zh) * 2015-10-30 2018-11-09 小米科技有限责任公司 通讯模组固件和插件生成方法及装置
CN109710814B (zh) * 2018-12-17 2021-09-03 航天恒星科技有限公司 一种多源遥感数据归档处理方法及装置
US12058193B2 (en) * 2021-06-30 2024-08-06 Tencent America LLC Bidirectional presentation datastream
KR102692238B1 (ko) * 2022-05-11 2024-08-06 (주)투비소프트 Ui 개발 툴이 탑재된 전자 단말 장치 및 그 동작 방법
KR102683141B1 (ko) * 2022-05-18 2024-07-09 (주)투비소프트 Ui 설계안에 대한 이미지 분석을 통해 ui 컴포넌트 자동 생성 기능을 제공할 수 있는 ui 개발 툴이 탑재된 전자 단말 장치 및 그 동작 방법

Family Cites Families (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6256623B1 (en) 1998-06-22 2001-07-03 Microsoft Corporation Network search access construct for accessing web-based search services
JP2002063054A (ja) * 2000-08-17 2002-02-28 Nippon Telegr & Teleph Corp <Ntt> オペレーションシステム間情報流通用共通モデル構築方法
FR2813471B1 (fr) 2000-08-31 2002-12-20 Schneider Automation Systeme de communication d'un equipement d'automatisme base sur le protocole soap
US6781567B2 (en) 2000-09-29 2004-08-24 Seiko Epson Corporation Driving method for electro-optical device, electro-optical device, and electronic apparatus
TWI280488B (en) 2000-09-29 2007-05-01 Victor Hsieh Online intelligent information comparison agent of multilingual electronic data sources over inter-connected computer networks
JP2002196990A (ja) * 2000-12-27 2002-07-12 Kddi Corp サービス発見プロトコル変換ゲートウェイ
US7149732B2 (en) 2001-10-12 2006-12-12 Microsoft Corporation Clustering web queries
US20030172127A1 (en) * 2002-02-06 2003-09-11 Northrup Charles J. Execution of process by references to directory service
JP2003304523A (ja) 2002-02-08 2003-10-24 Ntt Docomo Inc 情報配信システム、情報配信方法、情報配信サーバ、コンテンツ配信サーバ及び端末
US7054857B2 (en) 2002-05-08 2006-05-30 Overture Services, Inc. Use of extensible markup language in a system and method for influencing a position on a search result list generated by a computer network search engine
CN100418088C (zh) 2002-09-03 2008-09-10 富士通株式会社 检索处理系统及方法
CN1181649C (zh) 2002-09-18 2004-12-22 联想(北京)有限公司 家庭网络中不同子网设备间描述信息的转换方法
JP2004199515A (ja) 2002-12-19 2004-07-15 Fuji Xerox Co Ltd サービス検索装置、サービス検索方法、クライアント装置
US20040128344A1 (en) 2002-12-30 2004-07-01 Nokia Corporation Content and service registration, query and subscription, and notification in networks
US7007014B2 (en) 2003-04-04 2006-02-28 Yahoo! Inc. Canonicalization of terms in a keyword-based presentation system
JP4401679B2 (ja) 2003-05-12 2010-01-20 キヤノン株式会社 制御装置、制御プログラム、制御方法
JP4661047B2 (ja) 2003-05-30 2011-03-30 ソニー株式会社 情報処理装置及び情報処理方法、並びにコンピュータ・プログラム
US20050097087A1 (en) * 2003-11-03 2005-05-05 Punaganti Venkata Murali K. System and method for providing a unified framework for service discovery
US7656822B1 (en) * 2003-12-22 2010-02-02 Sun Microsystems, Inc. Method and apparatus for decentralized device and service description and discovery
KR100636380B1 (ko) * 2004-12-17 2006-10-19 한국전자통신연구원 이종의 홈네트워크 미들웨어상에 접속해 있는 홈디바이스들간의 상호 연동을 위한 홈네트워크 범용미들웨어 브릿지 시스템 및 그 방법
CN100456286C (zh) 2005-01-17 2009-01-28 马岩 一种通用的文件搜索系统及方法
EP1681823A1 (en) * 2005-01-17 2006-07-19 Sap Ag A method and a system to organize and manage a semantic web service discovery
WO2006127197A2 (en) 2005-04-26 2006-11-30 Matsushita Electric Industrial Co., Ltd. Mechanism to support transparent roaming in heterogeneous service discovery systems
WO2007005131A2 (en) 2005-05-19 2007-01-11 Matsushita Electric Industrial Co., Ltd. System and method for multiprotocol service discovery in a computer network
US20060277189A1 (en) * 2005-06-02 2006-12-07 Microsoft Corporation Translation of search result display elements
JP2007072654A (ja) 2005-09-06 2007-03-22 Yokogawa Electric Corp サービス検索装置及びサービス検索システム
EP1835417A1 (en) * 2006-03-13 2007-09-19 Alcatel Lucent Web service with associated lexical tree
US20070280206A1 (en) 2006-05-31 2007-12-06 Samsung Electronics Co., Ltd. Method for consuming heterogeneous services on heterogeneous devices using script plugins
EP1865687B1 (en) * 2006-06-06 2011-05-11 Koninklijke KPN N.V. Proxy-bridge for connecting different types of devices
US7831586B2 (en) * 2006-06-09 2010-11-09 Ebay Inc. System and method for application programming interfaces for keyword extraction and contextual advertisement generation
US20080086490A1 (en) * 2006-10-04 2008-04-10 Sap Ag Discovery of services matching a service request
TWI328965B (en) 2006-11-06 2010-08-11 Arcadyan Technology Corp Method for creating a customized tv/radio service from user-selected contents and playback device using the same
JP2010515338A (ja) * 2006-12-28 2010-05-06 テレフオンアクチーボラゲット エル エム エリクソン（パブル） サービス発見のための方法と装置
US20080244514A1 (en) * 2007-03-29 2008-10-02 Microsoft Corporation Scriptable object model for network based services
US20090006311A1 (en) 2007-06-28 2009-01-01 Yahoo! Inc. Automated system to improve search engine optimization on web pages
US8046355B2 (en) 2007-09-04 2011-10-25 Google Inc. Word decompounder
US7769749B2 (en) 2007-11-13 2010-08-03 Yahoo! Inc. Web page categorization using graph-based term selection
US7987163B2 (en) * 2008-02-12 2011-07-26 Bae Systems Information And Electronic Systems Integration Inc. Apparatus and method for dynamic web service discovery
CN101237457B (zh) 2008-03-14 2010-09-29 华为技术有限公司 一种服务发现方法、系统及设备
US8560563B2 (en) * 2008-07-09 2013-10-15 International Business Machines Corporation Apparatus and method of semantic service correlation system
US8185536B2 (en) * 2009-01-30 2012-05-22 Hewlett-Packard Development Company, L.P. Rank-order service providers based on desired service properties
US8255405B2 (en) * 2009-01-30 2012-08-28 Hewlett-Packard Development Company, L.P. Term extraction from service description documents
US10754896B2 (en) * 2009-03-24 2020-08-25 Micro Focus Llc Transforming a description of services for web services

Also Published As

Publication number Publication date
JP2014241141A (ja) 2014-12-25
KR20120028373A (ko) 2012-03-22
US9043409B2 (en) 2015-05-26
US20110072055A1 (en) 2011-03-24
CN102461125B (zh) 2015-11-25
KR101357704B1 (ko) 2014-02-03
JP2012530299A (ja) 2012-11-29
WO2010144889A1 (en) 2010-12-16
CN102461125A (zh) 2012-05-16
EP2441234A1 (en) 2012-04-18
TW201108006A (en) 2011-03-01

Similar Documents

Publication Publication Date Title
JP5886376B2 (ja) 構造化メタデータに基づく発見を公開するプラグインモデルのための方法および装置
US20050193106A1 (en) Service discovery and delivery for ad-hoc networks
KR101079570B1 (ko) 검색 웹 서비스
EP1253766B1 (en) Peer group name server
US8423671B2 (en) Middleware device and method of supporting compatibility of devices in home network
JP2010503088A (ja) 連結ディスカバリ・ウェブ・サービス
US7805485B2 (en) Web services interface extension channel
Elenius et al. Ontology-based Service Discovery in P2P Networks.
Gu et al. An architecture for flexible service discovery in OCTOPUS
Lin et al. Osgi-based smart home architecture for heterogeneous network
US20110016226A1 (en) Methods and Apparatus for Updating Index Information While Adding and Updating Documents in a Distributed Network
Thompson et al. Service description for pervasive service discovery
KR100965458B1 (ko) 유비쿼터스 서브네트워크 연동을 위한 브로커
Blefari-Melazzi et al. Context-aware service discovery in mobile heterogeneous environments
Pantazoglou et al. Discovering web services and JXTA peer-to-peer services in a unified manner
Li et al. Combine concept of agent and service to build distributed object-oriented system
Leitner et al. Towards flexible interface mediation for dynamic service invocations
Wang et al. A semantic service discovery approach for ubiquitous computing
Livingstone Service Discovery in Pervasive Systems
Bashah et al. Service Discovery for mobile multi-domain multilanguage environments
Schmitt et al. An extensible framework for context-aware communication management using heterogeneous sensor networks
Wang et al. Design issues of semantic service discovery for ubiquitous computing
Leitner et al. A Mediator-Based Approach to Resolving Interface Heterogeneity of Web Services
Elenius Service discovery in peer-to-peer networks
Zhu Scalability of p2p based mobile web services discovery

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20150619

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150630

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20150930

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20151029

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160112

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160210

R150 Certificate of patent or registration of utility model

Ref document number: 5886376

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees