JP4563124B2 - 通信を管理するための参加者のグループ分け及び識別方法、その装置、そのコンピュータプログラム及び記憶媒体 - Google Patents

Description

以下の記載は、通信に関し、例えば、参加者のグループとの通信を管理するためのセグメントの識別に関する。

事業の参加者の数が増加するにつれて、参加者間の効率的な通信はしばしば妨げられる。特に、各メッセージが各参加者に配送される場合、個々の参加者それぞれにとっての、各メッセージの平均価値は低下する。メッセージの数が増加するに従って、個々の参加者は、最終的に、メッセージを（個々の参加者の事業への参加に密接に関連するメッセージでさえ）無視し始める。

多くの事業では、全参加者のグループのサブグループ（セグメントとも呼ばれる）に、事業の参加者を分割することにより、この問題への対処を試みている。このように、参加者の分割には、事業の参加者のサブグループへの分割が含まれている。

本願は、事業の参加者の分割に関連するシステムおよび技術について記載している。本発明者は、従来の分割システムおよび技術は使いにくく、密接な関連のあるメッセージから参加者を除外すること、または不適切な通信に参加者を含めることがあるという点で不正確であり、そして、参加者の参加の性質が変化する場合がある動的な事業には不適合であることが多い、ということを認識した。

したがって、発明者は、事業内の通信を管理するためのシステムおよび技術を開発した。一態様による方法は、事業の参加者を参加者の特性に従ってプロファイリングするステップと、第１の分類項目に関連付けられた、ドメインの識別情報を受信するステップと、第１の分類項目に関連付けられた特性のうちの１つまたは複数を識別する、仕様の識別情報を受信するステップと、参加者の特性をドメインおよび仕様と照合することにより、プロファイリングされた参加者をサブグループに分割するステップとを含む。前記特性は、分類項目の主題に従って分類項目に関連付けられていてもよい。

この態様およびその他の態様は、以下の特徴のうちの１つまたは複数を含んでいてもよい。第２の分類項目から導き出された、ボーダーの識別情報が受信されてもよい。サブグループは、ボーダーと、ドメインおよび仕様との共通部分に、参加者の特性を照合することにより分割されてもよい。ユーザは、ドメインの識別情報および仕様の識別情報を問い合わせられてもよい。ドメインを識別する情報が、メッセージに追加され、そのメッセージがサブグループに送信されてもよい。参加者は、特性を説明する有限の語彙に従ってプロファイリングされてもよい。会社事業に共通する会社ドメインの識別情報が受信されてもよい。

別の態様による方法は、選ばれた事業参加者の第１のサブグループを識別する特性を受信するステップと、前記特性の仕様を受信するステップであって、前記仕様は、第１のサブグループ内で参加者の第２のサブグループを区分するステップと、前記特性および特性の仕様に基づいて、第２のサブグループとの通信を管理するステップとを含む。受信される特性は、通信の受信者を分割するために、機械読み取り可能命令の組の中にハードコード化されてもよい。

この態様およびその他の態様は、以下の特徴のうちの１つまたは複数を含んでいてもよい。操作は、特性の仕様を受信するステップを含んでいてもよい。仕様は、機械読み取り可能命令の組を事業に合わせてカスタマイズするために、特性に割り当てられてもよい。仕様は、特性に固有であってもよい。受信される特性は、第１のサブグループの、事業への参加の性質とタイプに基づいて第１のサブグループを識別する、ドメインであってもよく、そして、可能な特性の集まりの中からの選択肢として受信されてもよい。前記操作は、特性の仕様の目録を参加者に提示するステップを含んでいてもよい。

前記操作は、また、複数の参加者特性を、複数の事業参加者のそれぞれと関連付けるステップを含んでいてもよい。参加者のサブグループは、共通の特性を共有していてもよい。また、複数の属性値が、複数の参加者のそれぞれに関連付けられていてもよい。通信を管理するステップは、第２のサブグループ内の参加者の連絡先リストを確立するステップを含んでいてもよい。連絡先リストは、特定のメッセージのために動的に確立されてもよい。

前記操作は、選ばれた参加者の第２のサブグループの、第３のサブグループを識別する、ボーダーを受信するステップを含んでいてもよい。ボーダーは、機械読み取り可能命令の組の中にハードコード化された第２の特性から導き出されてもよい。通信は、ボーダーによってではなく、１つまたは複数の特性および特性の仕様によって識別されてもよい。前記操作は、また、第２のサブグループ内の参加者の役割を受信するステップと、役割に基づいて、第２のサブグループ内の通信から参加者を除外するステップとを含んでいてもよい。

別の態様による方法は、ユーザからメッセージを受信するステップと、メッセージの受領のために、選ばれた事業参加者のサブグループを識別する２つ以上の特性を受信するステップと、受信されたメッセージの受領のために参加者のサブグループを動的に識別するステップとを含む。

この態様およびその他の態様は、以下の特徴のうちの１つまたは複数を含んでいてもよい。メッセージは、メッセージの発信元のソースデータ処理システムを経由して、ユーザから受信されてもよい。参加者のサブグループは、メッセージの受領時に、または定期的に、動的に識別されてもよい。参加者のサブグループの識別情報は、メッセージの通信の後で廃棄されてもよい。

２つ以上の特性を受信するステップは、事業内での参加の位置に基づいて、選ばれた事業参加者を識別する、第１の特性を受信するステップと、事業への参加の性質に基づいて、選ばれた事業参加者を識別する、第２の特性を受信するステップとを含んでいてもよい。サブグループ内の参加者の役割も、受信される特性であってもよい。参加者は、識別されたサブグループから、役割に基づいて除外されてもよい。

別の態様による、機械実装される方法は、第１の参加者の事業への参加の説明を受信するステップと、第１の参加者の参加の説明を参加者データオブジェクトに格納するステップと、第１の参加者の参加の特性および位置に基づいて、第１の参加者が、あるクラスのメッセージの受信者のグループのメンバーであることを識別するステップと、第１の参加者を前記受信者のグループに関連付けるステップと、前記受信者のグループを識別するために適用できる情報を含むメッセージを受信するステップと、前記受信者のグループ内での第１の参加者の役割に基づいて、前記受信者のグループの他のメンバーへの、受信されたメッセージの伝達から、第１の参加者を除外するステップとを含む。前記説明は、第１の参加者の参加の特性および位置を含んでいてもよい。第１の参加者は、前記受信者のグループ内での第１の参加者の役割を識別することにより、前記受信者のグループに関連付けられてもよい。

別の態様による物品は、１つまたは複数のマシンに操作を実行させるために動作可能な命令を記憶した、機械読み取り可能媒体を含む。前記操作は、参加者のセグメントに関する情報を受信するステップと、参加者のセグメントに、参加者の共通の特性を共有する新しいメンバーを、セグメント内で特定の役割を有するものとして登録するステップとを含んでいてもよい。

この態様およびその他の態様は、以下の特徴のうちの１つまたは複数を含んでいてもよい。新しいメンバーの登録は、参加者のセグメントへの特定の通信から、新しいメンバーが除外されるべきであることを指示するステップを含んでいてもよい。参加者のセグメントに関して受信される情報は、多くの事業に共通する汎用ドメインと、汎用ドメインのトピック仕様とを含んでいてもよい。汎用ドメインは、参加者のセグメントよりも大きなグループを識別してもよい。トピック仕様は、汎用ドメインにより識別されるグループ内で、第２のサブグループを区分してもよい。例えば、トピック仕様は、参加者のセグメントを区分してもよい。

別の態様による装置は、参加者を識別し、参加者の事業への参加を説明する、参加者説明データベースと、処理動作を実行するように構成されたデータ処理システムとを含む。前記動作は、選ばれた事業参加者の第１のサブグループを識別する特性を受信するステップと、第１のサブグループを第２のサブグループにさらに区分するために、可能な特性の仕様の集まりをユーザに提示するための機械読み取り可能命令を提供するステップと、特性の仕様をユーザから受信するステップと、特性および特性の仕様を、参加者説明データベース内で検出される、参加者の事業への参加と比較して、第１のサブグループを識別するステップと、第１のサブグループを第２のサブグループに区分するステップとを含んでいてもよい。受信される特性は、通信の受信者を分割するために、機械読み取り可能命令の組の中にハードコード化されてもよい。

この態様およびその他の態様は、以下の特徴のうちの１つまたは複数を含んでいてもよい。前記参加者説明データベースは、特定の参加者を識別し、特定の参加者の事業への参加を説明する、参加者オブジェクトを含んでいてもよい。前記参加者オブジェクトは、特定の参加者の資格を説明する情報を含んでいてもよい。前記データ処理システムは、特性に固有の仕様を受信するように構成されていてもよい。

これらおよびその他の態様により、以下の利点のうちの１つまたは複数が実現される場合がある。最も主要な全社的分類項目のために、規制された語彙が導入されてもよい。各参加者は、そのような分類項目に従ってプロファイリングされてもよい。専用のクエリ表記法が、分類項目の１つに対応するプライマリドメインの識別をサポートしてもよい。オプションの共通部分は、セグメントボーダーを定義するための追加の分類項目を使用してもよい。この技術を使用すれば、プライマリターゲットグループの特性に関する情報は失われない。

分割アルゴリズムは、適切な参加者セグメントを判定するために、クエリをユーザプロファイルと突き合わせてもよい。セグメントは、固定された参加者リストとして保存されてもよい。あるいは、セグメントを定期的に、または要求に応じて更新する、動的クエリが保存されてもよい。

事業参加者は、正確かつ迅速に分割されることが可能である。分割は、事業の活動に密接な関係のある、事業全体にわたる語彙を使用して実行されてもよい。そのような語彙は、分類項目とも呼ばれ、通信システムの開発者によって導入されること、および事業の特定の性質に合わせて修正または補足されることが可能である。事業の参加者は、そのような語彙に従ってプロファイリングされてもよい。

システムおよび技術は、参加者の分割をサポートするタームを使用してもよい。タームは、分類項目に対応するプライマリドメインの識別情報を含んでいてもよい。タームは、また、セグメントを狭めるために、例えば追加の分類項目によって定義される、追加の共通部分を含んでいてもよい。そのような狭められたセグメントを使用することにより、プライマリドメインの識別情報を維持することができ、適宜、その他の目的に適用することが可能となる。

参加者のセグメントは、後続の検索のために保存されてもよい。あるいは、参加者のセグメントは、定期的にまたは要求に応じて更新されるという点で、動的であってもよい。

１つまたは複数の実装の詳細について、添付の図面を使用して以下に説明する。その他の特徴および利点は、以下の説明と図面、および請求の範囲から明らかになるであろう。

これらおよびその他の態様について、以下の図面を参照して詳しく説明する。

異なる図面中の同じ参照符号は、同じ要素を示す。

説明するシステムおよび技術は、事業の参加者の分割に関する。事業とは、２人以上の個人が関与している活動である。事業の例としては、企業、協会、団体、組織、行政体、業界、プロジェクトチーム、利益集団などがある。図１に示す概略図では、事業の参加者のグループ１００が、サブグループ１０５、１１０、１１５、１２０、１２５、１３０、１３５、１４０、１４５の集まりに分割されている。サブグループ１０５、１１０、１１５、１２０、１２５、１３０、１３５、１４０、１４５のそれぞれには、グループ１００内での通信の効率が向上するように通信を管理するために使用可能な１つまたは複数の共通特性を共有する、グループ１００からの参加者が含まれている。例えば、メッセージがメッセージ受信者に関連している可能性を増加することにより、および、参加者の事業への参加に関連するメッセージの受信から、どの参加者も誤って除外されることがない可能性を増加することにより、通信の効率を向上させることができる。これは、サブグループ１０５、１１０、１１５、１２０、１２５、１３０、１３５、１４０、１４５の内部または外部での参加者の位置に基づいて、メッセージを参加者に中継すべきかどうかを判定することにより行うことができる。

図２は、事業の参加者を説明する記述情報２００の例を示す。記述情報２００は、参加者がある特性を共有するかどうか、および事業の参加者のサブグループに属するかどうかを判定するために使用されてもよい。記述情報２００は、共通特性のさまざまなカテゴリを含む。図２は、共通特性のカテゴリの例２０５と、いくつかのカテゴリ例内の特性の例２１０、２１５、２２０、２２５、２３０、２３５、２４０を示す。共通特性のカテゴリの例２０５には、参加者の資格および技能２４５、参加者の個人的嗜好２５０、参加者の許可レベル２５５、公式および非公式のグループへの参加者の所属２６０、参加者の情報ニーズ２６５、参加者が関与しているタスクおよびプロジェクト２７０、参加者と事業との間の関係２７５、参加者の事業への参加の背景２８０、参加者がアクセスするポータルコンテンツ２８５が含まれている。カテゴリ２４５、２５０、２５５、２６０、２６５、２７０、２７５、２８０は、網羅的でも、相互排他的でもない。言い換えると、事業の参加者を記述する他の情報のカテゴリが存在し、また、特定の記述情報が２つ以上のカテゴリに属していてもよい。

図３は、事業の参加者を説明する記述テーブル３００の例を示す。記述テーブル３００は、合わせて参加者を説明する、一連の属性３０５および値３１０を含んでいる。属性３０５は、参加者の特性であり、値３１０は、説明されている特定の参加者の特性の名称である。特性は、全社的な汎用ドメインに属してもよい。値は、参加者全員にわたる一貫したプロファイリングを保証するために、規制された語彙に制限されてもよい。

記述テーブル３００は、ヒューマン・キャピタル・マネージメント（ｈｕｍａｎ ｃａｐｉｔａｌ ｍａｎａｇｅｍｅｎｔ、ＨＣＭ）システム内の従業員レコードなどの、単一のデータオブジェクトの全部または一部であってもよく、あるいは、記述テーブル３００内の参加者説明情報は、複数のデータオブジェクトおよび／または複数のデータ処理システムにわたって分散されていてもよい。属性３０５と値３１０は、一連の属性−値ペアとして、または一連のタグと要素として保存されてもよく、あるいは、属性３０５と値３１０の間の結合は、それらの記憶領域のその他の特徴またはその他の関連する情報から決定可能であってもよい。属性３０５と値３１０のセマンティックス、および属性３０５と値３１０との間の結合のセマンティックスは、参加者説明をデータ処理装置で読み取り可能にするために適切なものである。

一実装では、値３１０は、可能な特性の名称の、有限の集まりに制限されてもよい。例えば、値３１０は、事業の参加者の許容されるあらゆる状態を包含する、規制された語彙に制限されてもよい。例えば、「場所」属性の名称は、「ヨーロッパ」、「アジア」、「アメリカ合衆国」、「ラテンアメリカ」、および「北米−アメリカ合衆国以外」に制限されてもよく、その場合、「カナダ」および「オーストラリア」などの名称は無効になる。そのような、値３１０の、名称の有限の集まりへの制限は、参加者全員にわたる一貫したプロファイリングを保証するために使用されてもよい。

記述テーブル３００内の説明情報は、説明されている参加者自身による入力の使用により、他の参加者からの入力の使用により、デフォルト割り当ての使用により、および／または、ユーザの入力とは関係なしに集められてもよい。例えば、説明情報を集めるため、あるいはデフォルトの割り当てまたはユーザが入力した説明情報を修正するために、参加者の事業への参加が追跡されてもよい。

図４は、参加者を分割するためのプロセス４００のフローチャートを示す。プロセス４００は、参加者の単一の主要な特性の識別に依拠して、参加者を分割することができる。プロセス４００は、データ通信ネットワーク内の任意数のデータ処理装置において実行されてもよい。例えば、プロセス４００は、メッセージの発信元のソースデータ処理システムにおいて実行されてもよい。あるいは、プロセス４００は、ソースデータ処理システムから受信者へメッセージを中継する、ルータまたはその他の中間データ処理システムにおいて実行されてもよい。また、プロセス４００は、事業の参加者によってメッセージが受信されるターゲットデータ処理システムにおいて実行されてもよい。

プロセス４００を実行しているシステムは、４０５において、ドメインに関する情報を受信してもよい。ドメインとは、事業の参加者のグループ内で広範なサブグループを定義するために使用できる、特性のカテゴリである。ドメインは、一般的な事業の活動に関連し、事業の特定の性質には依存しない可能性があるという点で、汎用であってもよい。例えば、多くの会社事業は、生産ライン、ビジネス分野、および目標市場を有している。ドメインは、事業のそのような一般的な要素に対応していてもよい。

ドメインは、規制された語彙を提供する分類項目に基づいていてもよい。分類項目とは、事業の活動と密接な関係のある語彙（つまり、言葉の組）である。分類項目は、制限された言葉の組のみを含むように制限されているという点で、規制されていてもよい。規制された語彙を提供する分類項目によりモデル化されたドメインは、事業全体にわたる一貫性を保証することができる。例えば、任意の事業は、生産ライン、ビジネス分野、目標市場、およびその他の共通の特徴を有する。分割は、そのような全社的ドメインの存在を想定していてもよいが、いかなる具体的な分類項目の実現にも依存しない。

一般的なドメインは、通信を管理するための機械読み取り可能な命令の中にハードコード化されていてもよい。例えば、ソフトウェア開発者は、顧客に出荷されるソフトウェアのために、一般的なドメインのリストをあらかじめ実装してもよい。そのようなあらかじめ実装されたドメインの内容は、出荷品に含まれている必要はない。そのようなソフトウェアを受け取った顧客は、あらかじめ実装されたドメインに関係する内容を顧客レコードに埋めてもよい。

プロセス４００を実行しているシステムは、４１０において、受信したドメイン情報のトピック仕様も受信してもよい。トピック仕様は、ドメインにより定義された参加者のサブグループをさらに絞るために使用できる１つまたは複数の特性である。ドメインは、一般に、顧客の特定の目的に合う一連のトピック仕様の定義を通して、事業に合わせてカスタマイズされる。例えば、顧客の製品ラインは、さまざまな自動車モデルを含んでいてもよい。製品ラインドメインのためのトピック仕様は、したがって、それらのモデルが顧客に固有のものである場合でも、さまざまなモデルに対応していてもよい。

トピック仕様は、一般に、事業の特定の性質に依存するため、トピック仕様は、事業レベルにおいて、機械読み取り可能な命令の中に入れられてもよい。例えば、組織の管理者またはその他の参加者は、事業の特定の性質に基づいて、各ドメインのためのトピック仕様のカスタマイズされたリストを入力してもよい。トピック仕様は、ユーザ入力に基づいて、あるいは１つまたは複数のメッセージから抽出された情報に基づいて、ユーザから直接、または他のデータ処理システムを経由して受信されてもよい。

プロセス４００を実行しているシステムは、次に、４１５において、受信したドメイン情報およびトピック仕様を使って、参加者の集まりを分割してもよい。分割は、通信を管理するために使用されてもよい。分割は、例えば、将来の通信のための連絡先リストの確立、特定のメッセージの受信者のアドホックな集まりの定義、およびセグメントの作成と修正を含んでいてもよい。

図５は、通信を管理するためのそのような多次元的アプローチを記号的に表現するターム５００を示す。ターム５００は、トピック５１０により区分されるドメイン５０５を含む。ドメイン５０５は、一般的な事業に関連し、事業の特定の性質には依存しない可能性があるという点で、汎用であってもよい。ドメイン５０５は、また、プライマリドメインであってもよい。プライマリドメインは、特定のサブグループを定義するために使用される唯一のドメインである。プライマリドメインは、また、特定のサブグループの定義の背後にある発信者の動機を表現するという点で、通信の発信者の意図を表現することもできる。

トピック５１０は、事業の特定の性質を反映するという点で、事業に固有であってもよい。

このように、汎用またはほぼ汎用のドメインの組が、第１の次元を形成することができ、第１の次元はさらに、トピックという第２の次元によって区分される。そのような多次元的アプローチは、１つまたは複数のメッセージを参加者に伝達するかどうかを決定するための２レベルの基礎を提供することにより通信を管理するために使用されてもよい。

図６は、メッセージのドメインおよびトピックに関する入力を、メッセージの送信を希望する事業の参加者から直接受信することができる、表示パネル６００の部分の例を示す。表示パネル部分６００は、電子メールプログラム、メーリングリスト、またはその他の通信システムのための専用の電子メッセージウィンドウであってもよい。

表示パネル６００は、ドメイン選択セクション６０５、トピック選択セクション６１０、およびメッセージ入力セクション６１５を含む。ドメイン選択セクション６０５には、それぞれがドメイン名６２０により識別され、ドメイン選択ボックス６２５により選択可能な、ドメインの目録が含まれていてもよい。トピック選択セクション６１０には、ドメイン選択セクション６０５で選択された各ドメインに関連するトピックの目録が含まれていてもよい。図に示すように、トピック選択セクション６１０には、ドメイン選択セクション６０５内で選択されたドメイン「ツール（ｔｏｏｌ）」に関連するツールトピック（ｔｏｏｌ ｔｏｐｉｃ）の目録が含まれている。トピック選択セクション６１０内のトピックは、トピック名６３０により識別することができ、トピック選択ボックス６３５により選択可能である。メッセージ入力セクション６１５には、件名入力６４０およびメッセージ本体入力６４５が含まれていてもよい。

操作の際に、事業の参加者は、件名およびメッセージ本体を入力するために、それぞれ、件名入力６４０およびメッセージ本体入力６４５と対話してもよい。ユーザは、また、マウスなどのポインティングデバイスを使用して、例えばドメイン選択ボックス６２５をクリックすることにより、ドメイン選択セクション６０５と対話して、メッセージのためのドメインを選択してもよい。ドメインの選択に基づいて、データ処理装置は、選択されたドメインに関連するトピックの目録をトピック選択セクション６１０に表示してもよい。ユーザは、次に、例えばトピック選択ボックス６３５をクリックすることにより、トピック選択セクション６１０と対話して、メッセージのためのトピックを選択してもよい。受信したトピックおよびドメインの選択を使用して、ソース、中間、またはターゲットのデータ処理装置は、例えば、１つまたは複数のメッセージを参加者に中継すべきかどうかを判定することによって、通信を管理することができる。

図７は、ドメインおよびトピック情報を受信するための代替のプロセス７００のフローチャートである。プロセス７００は、例えば、メッセージの発信元のソースデータ処理システムにおいて実行されてもよいし、ソースデータ処理システムから受信者へメッセージを中継するルータまたはその他の中間データ処理システムにおいて実行されてもよいし、あるいは、事業の参加者によってメッセージが受信されるターゲットデータ処理システムにおいて実行されてもよい。

プロセス７００を実行しているデータ処理装置は、７０５において、メッセージを受信してもよい。受信されたメッセージは、メッセージの件名とメッセージ本体を含んでいてもよい。メッセージは、また、ストリング内の前のメッセージに関する情報、またはメッセージを送信している参加者の説明などの、補足情報を含んでいてもよい。送信している参加者の説明は、図２の記述情報２００などの情報を含んでいてもよい。メッセージは、さらに、メッセージのためのドメインおよびトピックを明示的に識別する、ユーザ入力に基づいて導き出された情報を含んでいてもよい。前記補足情報は、通常はメッセージ受信者からは見えないメタデータとして、メッセージに含まれていてもよい。

システムは、７１０において、メッセージからドメイン情報を抽出してもよい。抽出されたドメインは、メッセージの通信を管理するために使用されてもよい。システムは、キーワード検索、自然言語構文解析、ルールベースのエキスパートシステムなどの、メッセージのドメインを識別するための１つまたは複数の技術を使用して、ドメイン情報を抽出してもよい。例えば、システムは、自然言語構文解析を使用して、特定のメッセージが、事業の情報技術トレーニング部門により提供されるサービスに関連していることを識別してもよい。その他の例としては、エキスパートシステムが、メッセージの内容、メッセージストリングの履歴、送信者により識別されるドメイン、およびメッセージを送信している参加者に関する情報を使用して、ドメイン情報を抽出してもよい。

抽出されたドメイン情報に基づいて、プロセス７００を実行しているシステムは、７１５において、メッセージに関するトピック仕様情報も抽出してもよい。トピック仕様は各ドメインについて事前定義されていてもよく、または、トピックはメッセージに基づいて生成され、メッセージに割り当てられてもよい。例えば、メッセージドメインが、情報技術トレーニング部門により提供されるサービスである場合、システムは、ソフトウェア製品の名前などの、繰り返し発生するキーワードに基づいてトピックを割り当ててもよい。抽出されたドメインおよびトピック情報は、次に、抽出しているデータ処理システムにより、または、抽出しているシステムからドメインおよびトピック情報を受信するその他のシステムにより、通信を管理するために使用されてもよい。

図８は、参加者セグメントを定義するためのもう１つのアプローチを記号的に表現するターム８００を示す。ターム８００は、トピック５１０により区分され、１つまたは複数のボーダー基準８０５により交差される、プライマリドメイン５０５を含む。ボーダー基準８０５は、他のドメインからのトピックであり、プライマリドメインおよびトピック仕様により定義された参加者のグループ内でサブグループを定義するために使用されてもよい。ボーダー８０５は、追加のターゲットを識別するというよりは、プライマリドメイン５０５を制限することに関連しているという点で、セカンドドメインとは異なるものである。

ターム８００内の、ドメイン５０５は、トピック５１０、および１つまたは複数のボーダー８０５により区分される。プライマリドメイン５０５は、トピック５１０と合わせて、セグメントの主要な特性を表現する。ボーダー８０５は、セグメントを狭くするために使用されてもよいが、通常は、セグメントのプライマリドメインなどの、セグメントの主要な特性は変更しない。セグメントの主要な特性は、通信の送信者の動機を反映している。通信は主要な特性を有しているため、識別されたセグメントに投函されたメッセージを受信する参加者は、ドメイン５０５およびトピック５１０により実施されたメッセージ送信の背後にある発信者の動機を識別する情報を、依然として提供されてもよい。したがって、識別されたセグメントに投函されたメッセージを受信する、参加者のグループの全メンバーは、このメッセージを送信する主要な理由を、やはり認識することができる。

例えば、管理者が、仕事の活動に関連するプライマリドメイン５０５およびトピック５１０に基づいて、事業内のすべての販売員にメッセージを送信する場合、他の（例えば、地理）ドメインから引き出されたボーダー８０５は、メッセージのターゲットを絞ることが可能であるが、ドメイン５０５およびトピック５１０に関連する情報が送信に含まれているならば、管理者の動機（つまり、販売員と連絡を取るということ）が識別されることが、依然として可能である。システムは、プライマリドメインに関連するさまざまなチャネル内でそのようなメッセージを配信するために、この知識を使用してもよい。

通信を管理するためのシステムおよび技術の中で、ドメイン、トピック、およびボーダーを使用することにより、通信の効率を向上させることが可能である。特に、ボーダーにより識別されるグループ内の全メンバーは、ドメインおよびトピックにより識別されるグループ内の全メンバーと強い相互関係がある必要はないという点で、ボーダーはドメインおよびトピックと交錯していてもよい。このように、ドメイン、トピック、およびボーダーの組み合わせは、正確にターゲットが絞られたサブグループの通信を管理するために使用されてもよい。

図９は、メッセージの１つまたは複数のボーダー、ならびにドメインおよびトピック仕様に関する入力を、メッセージの送信を希望する事業の参加者から受信することができる、表示パネル９００の部分の例を示す。

表示パネル９００は、ドメイン選択セクション６０５、トピック選択セクション６１０（プルダウンメニューとして示されている）、メッセージ入力セクション６１５、およびボーダー選択セクション９０５を含む。ボーダー選択セクション９０５には、それぞれがボーダー名９１０により識別され、ボーダー選択ボックス９１５により選択可能な、ボーダーの目録が含まれている。

操作の際に、事業の参加者は、マウスなどのポインティングデバイスを使用して、例えばボーダー選択ボックス９１５をクリックすることにより、ボーダー選択セクション９０５と対話して、メッセージのための１つまたは複数のボーダーを選択してもよい。ボーダーの選択に基づき、そして、ドメインおよびトピック仕様の選択と組み合わせて、ソース、中間、またはターゲットのデータ処理装置は、例えば、メッセージを参加者に伝達すべきかどうかを判定することによって、通信を管理することができる。

図１０は、プライマリドメインにボーダー基準を交差させることによりセグメントを構築するためのプロセス１０００を示す。プロセス１０００は、事業の参加者による要求があった場合に（特定のメッセージとは関係なく）、またはそのような参加者が特定のメッセージの伝達を希望する時に、データ処理システムにより実行されてもよい。

プロセス１０００を実行しているシステムは、１００５において、ドメイン情報、およびドメインのトピック仕様を受信してもよい。システムは、さらに、１０１０において、ボーダー情報を受信してもよい。ボーダー情報は、参加者から明示的に受信されてもよく、あるいは、メッセージの中で暗黙に受信され、その後抽出されてもよい。

システムは、１０１５において、ドメイン、トピック、およびボーダー情報を使用して、セグメント参加者のリストを作成することにより、セグメントを構築してもよい。セグメント参加者のリストは、受信したドメイン、トピック、およびボーダーに関連する活動に参加する、事業の参加者を含んでいてもよい。

プロセス１０００を実行しているシステムは、１０２０において、連絡先リストを保存してもよい。例えば、システムは、データ記憶装置上にローカルまたはリモートで連絡先リストを格納することにより、連絡先リストを保存してもよい。前記連絡先リストは、リストの作成に関連する処理費用を節約するために、後でアクセスされてもよい。

図１１は、事業の参加者が特定のメッセージの伝達を希望する場合に、データ処理システムによってアドホックに実行されてもよい、通信を管理するためのプロセス１１００を示す。

プロセス１１００を実行しているシステムは、１１０５、１１１０において、ドメイン、トピック、および／またはボーダー情報を受信する。システムは、また、１１１５において、通信が管理されるべき特定のメッセージを受信する。受信されるメッセージは、メッセージ本体、メッセージの件名、およびストリング内での前のメッセージに関する情報またはメッセージを送信している参加者の説明などの補足情報を含んでいてもよい。ドメイン、トピック、およびボーダー情報は、メッセージと同時に受信されてもよい。例えば、ドメイン、トピック、およびボーダー情報は、メッセージから抽出されてもよく、あるいは、ドメイン、トピック、およびボーダー情報は、メッセージに関連するメタデータとして受信されてもよい。

プロセス１１００を実行しているシステムは、１１２０において、受信された特定のメッセージのための１つまたは複数の受信者のグループを動的に識別してもよい。受信者の動的な識別には、トリガを受信したら、メッセージを受信する参加者のリストを再作成することが含まれていてもよい。参加者リストの再作成は、例えば、事前定義された時間間隔が経過した後で定期的に、または、リストの再作成の要求をユーザから受信した場合に、または、通信操作の実行のためにそのようなリストが必要になった場合にトリガされてもよい。例えば、１１１５におけるメッセージの受信により、参加者のリストの再作成がトリガされてもよい。

識別される受信者のグループは、受信された特定のメッセージの通信以外のいかなる目的にも関係している必要はない。次に、システムは、１１２５において、動的に識別された受信者にメッセージを伝達してもよい。例えば、プロセス１１００を実行しているシステムがメッセージのソースである場合、システムは、識別された受信者にメッセージを送信してもよい。あるいは、プロセス１１００を実行しているシステムが中間システムである場合、システムは、適切なターゲットシステムにメッセージを選択的に中継してもよい。さらなる例として、プロセス１１００を実行しているシステムがターゲットシステムである場合、システムは、ローカルの参加者による受信が適切かどうかを判定するために、着信メッセージをフィルタリングしてもよい。

図１２は、通信を管理するためのもう１つのアプローチを記号的に表現するターム１２００を示す。ターム１２００は、トピック仕様５１０により区分されるドメイン５０５、１つまたは複数のボーダー８０５、および役割１２０５を含む。役割１２０５は、結果として得られるセグメントへの、参加者の参加の性質を識別する。

役割１２０５は、一般に、特定のセグメントに適用可能である。役割１２０５の例としては、中核セグメント参加者役割、ゲスト役割、能動セグメント参加者役割、受動セグメント参加者役割、主題エキスパート役割、仲介役割、アドバイザ役割、新参役割がある。特定のセグメント内で１つの役割を有する参加者は、他のセグメント内で他の役割を有していてもよい。例えば、１つのセグメント内でのゲストは、他のセグメントではアドバイザであってもよい。

役割は、さまざまな事業内の共通セグメントまたはその他の通信インフラストラクチャコミュニティに対して汎用で、通信を管理するための機械読み取り可能命令の中に一般に入れられていてもよく、あるいは、役割は、事業の特定の性質を反映するという点で、ある事業に特化されたものであってもよい。特化された役割は、一般に、事業レベルで通信を管理するために、例えば事業内での通信の管理を希望している参加者によって、機械読み取り可能命令の中に入れられてもよい。

ターム１２００内の、ドメイン５０５は、トピック仕様５１０、１つまたは複数のボーダー８０５、および役割１２０５により区分される。言い換えると、役割１２０５は、ドメイン５０５、トピック仕様５１０、および１つまたは複数のボーダー８０５により識別されるサブグループよりもさらに小さいサブグループを識別することができる。

通信を管理するためのシステムおよび技術の中で役割１２０５を使用することにより、通信の効率が向上する可能性がある。特に、セグメントの選ばれたメンバーのみに関連または該当する情報を通信することが可能になる。これは、セグメントの特定のメンバーのみが情報を受信する権限を付与されている場合、またはセグメントとの特定の関係を有しているセグメント参加者のみに情報が関連する場合などの、いくつかの状況に適用できる。例えば、製品の製造に従事しているセグメント参加者は、製品開発部門内での、将来の開発作業または個人的な問題に関する通信を受信する権限を付与されなくてもよく、あるいは、そのような通信には興味がない可能性がある。

図１３は、通信を管理するためのプロセス１３００を示す。プロセス１３００は、ソース、中間、またはターゲットのデータ処理システムで実行されてもよい。

プロセス１３００を実行しているシステムは、１３０５において、既存のコミュニティ役割に関する情報を受信してもよい。受信する情報は、ドメイン、ドメインのトピック仕様、および１つまたは複数のボーダーを含んでいてもよい。コミュニティ役割は、連絡先リスト、または通信チャネル内へのフィルタリングなどの、通信を取りまとめるためのシステムまたは技術であってもよい。

システムは、次に、１３１０において、参加者をコミュニティ役割にメンバーとして登録してもよい。登録には、連絡先リストに参加者を追加すること、または、通信チャネル内で通信される特定のメッセージタイプを参加者が受信できることを保証することが含まれていてもよい。登録には、セグメントに対する参加者の役割を識別することが含まれていてもよい。登録は、ユーザから受信した要求により、またはユーザの入力なしで、セグメントと参加者の説明との間の対応に基づいて促されてもよい。

図１４は、通信を管理するためのプロセス１４００を示す。プロセス１４００は、新しいセグメントを確立する必要が識別された場合に、データ処理システムにおいて実行されてもよい。例えば、新しいセグメントの必要は、参加者の要求により識別されてもよく、または、事業内での参加者の通信の量および性質に基づいて自動的に識別されてもよい。

プロセス１４００を実行しているシステムは、１４０５において、セグメントテンプレートを受信してもよい。セグメントテンプレートは、事業内の可能なドメイン、トピック、およびボーダーを識別してもよい。セグメントテンプレートは、また、参加者が利用できる可能な役割、および参加者の役割が参加者との通信に及ぼす影響を識別してもよい。

プロセス１４００を実行しているシステムは、また、１４１０において、新しいセグメントのためのドメイン、トピック、およびボーダー情報を受信してもよい。システムは、１４１５において、受信した情報を使用して、連絡先リストなどのセグメントを定義してもよい。

システムは、また、１４２０において、新しいセグメントに含まれる可能性のある参加者の説明を受信してもよい。参加者の説明は、図２に示す記述情報２００を含んでいてもよい。参加者情報は、図３に示す記述テーブル３００の中に受信されてもよい。

プロセス１４００を実行しているシステムは、１４２５において、受信した参加者情報を使用して、新しいセグメント内の適切な役割に、選ばれた参加者を割り当ててもよい。例えば、部門の上級管理者として説明された参加者は、セグメント内の管理者役割に割り当てられてもよい。割り当ては、セグメント内のすべての参加者が割り当てについて検討されるまで継続されてもよい。

図１５は、参加者の分割が発生可能なデータ処理環境１５００の例を示す。データ処理環境１５００は、ソースシステム１５０５、中間データ処理システム１５１０、ターゲットシステム１５１５、およびデータ記憶システム１５２０を含む。システム１５０５、１５１０、１５１５、１５２０は、データリンク１５２５を介したデータ通信のために相互に結合されている。

ソースシステム１５０５には、ユーザとの対話のために、１つまたは複数のメッセージ入力装置１５３０が含まれている。ソースシステム１５０５は、携帯電話、キーボード、あるいは、コンピュータまたはハンドヘルド装置などのデータ処理装置であってもよい。メッセージ入力装置１５３０は、キーボード、ポインティングデバイス、マイクロフォン、タッチスクリーン、またはユーザからのメッセージの受信に適したその他の装置であってもよい。

ターゲットシステム１５１５には、ユーザとの対話のために、１つまたは複数のメッセージ出力装置１５３５が含まれている。ターゲットシステム１５１５は、携帯電話、表示画面、あるいは、コンピュータまたはハンドヘルド装置などのデータ処理装置であってもよい。メッセージ出力装置１５３５は、表示画面、スピーカ、またはユーザからのメッセージの提示に適したその他の装置であってもよい。

中間データ処理システム１５１０は、データ処理装置、および／または１組の機械読み取り可能命令の論理に従って処理動作を実行するソフトウェアであってもよい。中間データ処理システム１５１０によって実行可能な処理動作としては、アイデンティティエディタ１５４０、セグメントエディタ１５４５、および参加者セグメンタ１５５０によるものがある。

データ記憶システム１５２０は、中間データ処理システム１５１０において実行されるような処理動作のための、命令およびデータを格納できる、１つまたは複数のメモリ装置あるいはサーバであってもよい。データ記憶装置１５２０において格納されるデータとしては、参加者説明の集まり１５５５、およびセグメントの集まり１５６０がある。

操作の際に、データ処理環境１５００は、事業内の参加者のグループのセグメントを識別するために、通信を管理してもよい。一実装では、特定の事業参加者を記述する情報が、アイデンティティエディタの動作１５４０を実行している中間データ処理システム１５１０によって受信されてもよい。参加者説明は、ソースシステム１５０５内のメッセージ入力装置１５３０を介して受信されてもよい。受信される参加者説明は、図２に示す共通特性のカテゴリ２０５のうちの１つに分類される情報を含んでいてもよい。アイデンティティエディタの動作１５４０には、受信された参加者説明を使用して、データ記憶装置１５２０内の参加者説明１５５５を作成または修正する動作が含まれていてもよい。例えば、アイデンティティエディタの動作１５４０には、受信された参加者説明を使用して、図３の記述テーブル３００のような既存の参加者説明のフィールド内の属性の値を修正する動作が含まれていてもよい。

別の実装では、１人または複数の事業参加者のセグメントを識別するために使用できる情報が、例えばソースシステム１５０５内のメッセージ入力装置１５３０を介して、中間データ処理システム１５１０内のセグメントエディタ１５４５により受信されてもよい。受信されるセグメンテーション情報は、事業の参加者を識別する、１つまたは複数のドメイン、トピック、ボーダー、および役割を含んでいてもよい。受信されるセグメンテーション情報は、また、参加者の名前などの、個々の参加者を明示的に識別する情報を含んでいてもよい。セグメントエディタの動作１５４５には、受信された参加者識別情報を使用して、データ記憶システム１５２０内のセグメント１５６０を作成または修正する動作が含まれていてもよい。例えば、セグメントエディタの動作１５４５には、識別された参加者を既存のセグメント内に登録する動作、または、受信された参加者識別情報を使用して新しいセグメントを定義する動作が含まれていてもよい。

別の実装では、メッセージが、メッセージ入力装置１５３０を介して、ソースシステム１５０５における参加者から受信されてもよい。受信されるメッセージは、そのメッセージが関連している受信者のセグメントを識別するために使用できる情報を、暗黙に、または明示的に含んでいてもよい。ソースシステム１５０５は、データリンク１５２５を介して、中間データ処理システム１５１０にメッセージを中継してもよい。

次に、中間データ処理システム１５１０は、受信されるメッセージに暗黙に、または明示的に含まれている識別情報に基づいてメッセージの受信者を識別することにより、メッセージの通信を管理するために、参加者セグメンタの動作１５５０を実行してもよい。例えば、参加者セグメンタの動作１５５０は、メッセージに含まれている識別情報と参加者説明１５５５との比較による、メッセージ受信者の動的な識別を含んでいてもよい。参加者セグメンタの動作１５５０は、また、セグメント１５６０からの関連セグメントの検索による、１人または複数のメッセージ受信者の識別を含んでいてもよい。

メッセージ受信者の識別方法にかかわらず、中間データ処理システム１５１０は、データリンク１５２５を介してターゲットシステム１５１５にメッセージを中継してもよい。ターゲットシステム１５１５は、次に、出力装置１５３５を使用して、識別された参加者にメッセージを伝達してもよい。

ここで説明したシステムおよび技術のさまざまな実装は、ディジタル電子回路、集積回路、専用に設計されたＡＳＩＣ（特定用途向け集積回路）、コンピュータハードウェア、ファームウェア、ソフトウェア、および／またはそれらの組み合わせにより実現されてもよい。これらのさまざまな実装には、プログラマブルシステム上で実行可能および／または解釈可能な、１つまたは複数のコンピュータプログラムが含まれていてもよい。前記プログラマブルシステムは、データと命令をストレージシステムから受信するため、およびデータと命令をストレージシステムに送信するためにストレージシステムに接続された、専用または汎用であってもよい少なくとも１つのプログラマブルプロセッサ、少なくとも１つの入力装置、および少なくとも１つの出力装置を含む。

前記コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、またはコードとも呼ばれる）は、プログラマブルプロセッサ用の機械命令を含んでいてもよく、高レベルの手続き型および／またはオブジェクト指向のプログラミング言語、および／または、アセンブリ言語／機械語で実装されることが可能である。「機械読み取り可能媒体」という用語は、ここで使用される場合、機械命令および／またはデータをプログラマブルプロセッサに提供するために使用される任意のコンピュータプログラム製品、装置、および／または素子（例えば、磁気ディスク、光ディスク、メモリ、プログラマブルロジックデバイス（ＰＬＤ））を意味し、機械命令を機械読み取り可能信号として受け取る機械読み取り可能媒体を含む。「機械読み取り可能信号」という用語は、機械命令および／またはデータをプログラマブルプロセッサに提供するために使用される任意の信号を意味する。

ユーザとの対話を提供するために、ここに記載したシステムおよび技術は、ユーザに情報を表示するための表示装置（例えば、ＣＲＴ（陰極線管）またはＬＣＤ（液晶ディスプレイ）モニタ）、ならびにユーザがコンピュータに入力を提供できるようにするためのキーボードおよびポインティングデバイス（例えば、マウスまたはトラックボール）を有するコンピュータ上に実装されてもよい。その他の種類の装置も、ユーザとの対話を提供するために使用されてもよい。例えば、ユーザに提供されるフィードバックは、任意の形態の感覚フィードバック（視覚フィードバック、聴覚フィードバック、触覚フィードバックなど）であってもよく、ユーザからの入力は、音響、音声、または触覚入力を含む、任意の形態で受け取られてもよい。

ここに記載したシステムおよび技術は、バックエンドコンポーネント（例えば、データサーバ）、ミドルウェアコンポーネント（例えば、アプリケーションサーバ）、フロントエンドコンポーネント（例えば、ここに記載したシステムおよび技術の実装とユーザが対話することを可能にする、グラフィカルユーザインタフェースまたはＷｅｂブラウザを有するクライアントコンピュータ）、あるいはそのようなバックエンド、ミドルウェア、またはフロントエンドコンポーネントの任意の組み合わせを含む、コンピューティングシステム内に実装されてもよい。システムのコンポーネントは、ディジタルデータ通信の任意の形態または媒体（例えば、通信ネットワーク）により相互接続されていてもよい。通信ネットワークの例としては、ローカルエリアネットワーク（“ＬＡＮ”）、ワイドエリアネットワーク（“ＷＡＮ”），パーソナルエリアネットワーク（“ＰＡＮ”）、移動通信ネットワーク、および／またはインターネットがある。

前記コンピューティングシステムは、クライアントおよびサーバを含んでいてもよい。クライアントおよびサーバは、一般に、お互いに離れた位置にあり、通常は通信ネットワークを介して相互作用する。クライアントとサーバの関係は、それぞれのコンピュータ上で実行され、お互いにクライアント−サーバの関係を有するコンピュータプログラムによって発生する。

上記では、いくつかの実施形態のみについて詳しく説明したが、その他の変更形態も可能である。フローチャートに示した論理フローは、望ましい結果を得るために、示されている特定の順序で実行される必要はなく、また、連続して実行される必要もない。特定の実装では、マルチタスキングおよび並列処理が好ましい場合もある。通信管理は、１つまたは複数のドメイン、トピック仕様、ボーダー、および役割を使用して進行してもよい。

したがって、その他の実装が、特許請求の範囲内に含まれる可能性がある。

事業の参加者を分割可能な方法の概略図である。 事業の参加者を説明する記述情報の例を示す。 事業の参加者の機械読み取り可能な説明の例を示す。 参加者を分割するためのプロセスを示すフローチャートである。 参加者を分割するための多次元のシステムおよび技術用のタームである。 メッセージに関する入力を事業の参加者から受け取ることが可能な表示パネルの部分を示す。 メッセージから情報を抽出することにより参加者を分割するためのプロセスを示すフローチャートである。 参加者を分割するためのシステムおよび技術用の、もう１つのタームである。 メッセージに関する入力を事業参加者から受け取ることが可能な、もう１つの表示パネルの部分を示す。 参加者を分割するためのプロセスを示すフローチャートである。 特定のメッセージの通信を管理するためのプロセスを示すフローチャートである。 参加者を分割するためのシステムおよび技術用の、もう１つのタームである。 参加者を既存の通信セグメントに登録することにより通信を管理するためのプロセスを示すフローチャートである。 通信セグメントを確立することにより通信を管理するためのプロセスを示すフローチャートである。 参加者の分割が発生可能なデータ処理環境の例を示す。

符号の説明

１００ 参加者のグループ
１０５、１１０、１１５、１２０、１２５、１３０、１３５、１４０、１４５ サブグループ
２００ 記述情報
２０５ 共通特性のカテゴリの例
２１０、２１５、２２０、２２５、２３０、２３５、２４０ 特性の例
２４５ カテゴリ、参加者の資格および技能
２５０ カテゴリ、参加者の個人的嗜好
２５５ カテゴリ、参加者の許可レベル
２６０ カテゴリ、公式および非公式のグループへの参加者の所属
２６５ カテゴリ、参加者の情報ニーズ
２７０ カテゴリ、参加者が関与しているタスクおよびプロジェクト
２７５ カテゴリ、参加者と事業との間の関係
２８０ カテゴリ、参加者の事業への参加の背景
２８５ カテゴリ、参加者がアクセスするポータルコンテンツ
３００ 記述テーブル
３０５ 属性
３１０ 値
４００ プロセス
５００ ターム
５０５ ドメイン
５１０ トピック
６００ 表示パネル
６０５ ドメイン選択セクション
６１０ トピック選択セクション
６１５ メッセージ入力セクション
６２０ ドメイン名
６２５ ドメイン選択ボックス
６３０ トピック名
６３５ トピック選択ボックス
６４０ 件名入力
６４５ メッセージ本体入力
７００ プロセス
８００ ターム
８０５ ボーダー基準
９００ 表示パネル
９０５ ボーダー選択セクション
９１０ ボーダー名
９１５ ボーダー選択ボックス
１０００ プロセス
１１００ プロセス
１２００ ターム
１２０５ 役割
１３００ プロセス
１４００ プロセス
１５００ データ処理環境
１５０５ ソースシステム
１５１０ 中間データ処理システム
１５１５ ターゲットシステム
１５２０ データ記憶システム
１５２５ データリンク
１５３０ メッセージ入力装置
１５３５ メッセージ出力装置
１５４０ アイデンティティエディタ
１５４５ セグメントエディタ
１５５０ 参加者セグメンタ
１５５５ 参加者説明の集まり
１５６０ セグメントの集まり

Claims (45)

1. コンピュータに実装される方法であって、
   ユーザからメッセージを受信するステップと、
   前記メッセージの受領のために、事業内の選択された参加者のサブグループを識別する２つ以上の特性を受信するステップと、
   前記受信されたメッセージの受領のために参加者の前記サブグループを動的に識別する
   ステップと、
   前記動的に識別されたサブブループの参加者にメッセージを送信するステップと、
   を有し、
   前記選択された参加者のサブグループを識別する前記特性は、キーワードの出現を伴う前記メッセージの内容から抽出され、
   識別は、前記特性と参加者説明との比較により行われることを特徴とする方法。
2. 前記参加者のサブブループを識別する２つ以上の特性を受信するステップは、さらに、
   選ばれた事業参加者の第１のサブグループを識別する特性を受信するステップであって、前記特性は、通信の受信者を分割するために、機械読み取り可能命令の組の中にハードコード化されるステップと、
   前記特性の仕様を受信するステップであって、前記仕様は、前記第１のサブグループ内で参加者の第２のサブグループを区分し、前記仕様は、前記機械読み取り可能命令の組に追加されるステップと、
   を含み、
   前記方法は、さらに、
   前記特性および前記特性の仕様に基づいて、前記第２のサブグループとの通信を管理するステップとを含む、請求項１に記載の方法。
3. 前記特性の仕様を受信するステップにおける、前記特性の仕様を受信するステップを含み、前記仕様は、前記機械読み取り可能命令の組を前記事業に合わせてカスタマイズするために、前記特性に割り当てられる、請求項２に記載の方法。
4. 前記特性の仕様を受信するステップは、前記特性に固有の仕様を受信するステップを含む、請求項２に記載の方法。
5. 前記第１のサブグループを識別する特性を受信するステップは、前記第１のサブグループの前記事業への参加の性質とタイプに基づいて前記第１のサブグループを識別する、ドメインを受信するステップを含む、請求項２から４のいずれかに記載の方法。
6. 前記第１のサブグループを識別する特性を受信するステップは、可能な特性の集まりの中からの選択肢を受信するステップを含む、請求項２から５のいずれかに記載の方法。
7. 前記特性の仕様の目録を参加者に提示するステップをさらに含む、請求項２から６のいずれかに記載の方法。
8. 複数の参加者特性を、前記事業の複数の参加者のそれぞれと関連付けるステップをさらに含み、前記複数の参加者のサブグループは、共通の特性を共有している、請求項２から７のいずれかに記載の方法。
9. 前記複数の参加者特性を、前記複数の参加者のそれぞれと関連付けるステップは、複数の属性値を、前記複数の参加者のそれぞれと関連付けるステップを含む、請求項８に記載の方法。
10. 前記通信を管理するステップは、前記第２のサブグループ内の前記参加者の連絡先リストを確立するステップを含む、請求項２から９のいずれかに記載の方法。
11. 前記連絡先リストを確立するステップは、特定のメッセージのために前記連絡先リストを動的に確立するステップを含む、請求項１０に記載の方法。
12. 選ばれた参加者の前記第２のサブグループの、第３のサブグループを識別するボーダーを受信するステップをさらに含み、前記ボーダーは、機械読み取り可能命令の組の中にハードコード化された第２の特性から導き出される、請求項２から１１のいずれかに記載の方法。
13. 管理される通信を、前記ボーダーによってではなく、１つまたは複数の前記特性および前記特性の仕様によって識別する、請求項１２に記載の方法。
14. 前記第２のサブグループ内の参加者の役割を受信するステップと、
    前記役割に基づいて、前記第２のサブグループ内の通信から前記参加者を除外するステップとをさらに含む、請求項２から１３のいずれかに記載の方法。
15. さらに、
    事業の参加者を、前記参加者の特性に従ってプロファイリングするステップであって、前記特性は、分類項目の主題に従って前記分類項目に関連付けられているステップと、
    前記分類項目のうちの第１の分類項目に関連付けられた、ドメインの識別情報を受信するステップと、
    前記第１の分類項目に関連付けられた前記特性のうちの１つまたは複数を識別する、仕様の識別情報を受信するステップと、
    前記参加者の特性を前記ドメインおよび前記仕様と照合することにより、前記プロファイリングされた参加者をサブグループに分割するステップとを含む、請求項１に記載の方法。
16. 第２の分類項目から導き出された、ボーダーの識別情報を受信するステップと、
    前記ボーダーと、前記ドメインおよび前記仕様との共通部分に、前記参加者の特性を照合することにより、前記サブグループを分割するステップとをさらに含む、請求項１５に記載の方法。
17. 前記ドメインの識別情報および前記仕様の識別情報をユーザに問い合わせるステップをさらに含む、請求項１５または１６に記載の方法。
18. 前記ドメインを識別する情報をメッセージに追加するステップと、
    前記メッセージを前記サブグループに送信するステップとをさらに含む、請求項１５から１７のいずれかに記載の方法。
19. 前記参加者を、前記特性を説明する有限の語彙に従ってプロファイリングするステップをさらに含む、請求項１５から１８のいずれかに記載の方法。
20. 前記ドメインの識別情報を受信するステップは、企業ドメインの識別情報を受信するステップを含み、前記企業ドメインは企業の事業に共通している、請求項１５から１９のいずれかに記載の方法。
21. 前記ユーザからメッセージを受信するステップは、メッセージの発信元のソースデータ処理システムを経由してユーザからメッセージを受信するステップを含む、請求項１から２０のいずれかに記載の方法。
22. 前記参加者のサブグループを動的に識別するステップは、前記メッセージの受領時に、前記受信されたメッセージのために、前記参加者のサブグループを識別するステップを含む、請求項１から２１のいずれかに記載の方法。
23. 前記参加者のサブグループを動的に識別するステップは、前記参加者のサブグループを定期的に識別するステップを含む、請求項１から２２のいずれかに記載の方法。
24. 前記参加者のサブグループを動的に識別するステップは、前記メッセージの通信の後で、前記参加者のサブグループの識別情報を廃棄するステップを含む、請求項１から２３のいずれかに記載の方法。
25. 前記２つ以上の特性を受信するステップは、
    前記事業内での参加の位置に基づいて、前記事業内の選ばれた参加者を識別する、第１
    の特性を受信するステップと、
    前記事業への参加の性質に基づいて、前記事業内の選ばれた参加者を識別する、第２の
    特性を受信するステップとを含む、請求項１から２４のいずれかに記載の方法。
26. 前記２つ以上の特性を受信するステップは、前記サブグループ内の参加者の役割を受信するステップを含む、請求項１から２５のいずれかに記載の方法。
27. 前記受信されたメッセージの受領のために前記参加者のサブグループを動的に識別するステップは、前記識別されたサブグループから、役割に基づいて前記参加者を除外するステップを含む、請求項２６に記載の方法。
28. 第１の参加者の事業への参加の説明を受信するステップであって、前記説明は、前記第１の参加者の参加の特性および位置を含むステップと、
    前記第１の参加者の参加の説明を参加者データオブジェクトに格納するステップと、
    前記第１の参加者の参加の前記特性および位置に基づいて、前記第１の参加者が、あるクラスのメッセージの受信者のグループのメンバーであることを識別するステップと、
    前記第１の参加者を前記受信者のグループに関連付けるステップであって、前記第１の参加者を関連付けるステップは、前記受信者のグループ内での前記第１の参加者の役割を識別するステップを含むステップと、
    前記受信者のグループを識別するために適用できる情報を含むメッセージを受信するステップと、
    前記受信者のグループ内での前記第１の参加者の役割に基づいて、前記受信者のグループの他のメンバーへの、前記受信されたメッセージの伝達から、前記第１の参加者を除外するステップと、をさらに含む、請求項１から２７のいずれかに記載の方法。
29. 前記特性は、参加者の資格及び技能、参加者の個人的嗜好、参加者の許可レベル、公式及び非公式のグループへの参加者の所属、参加者の情報ニーズ、参加者が関与しているタスク及びプロジェクト、参加者の事業との間の関係、参加者の事業の参加の背景、参加者がアクセスするポータルコンテンツからなるカテゴリの少なくともいずれか一つに属するもの、または／及び、生産ライン、ビジネス分野、目標市場のいずれかに関連するカテゴリに属するものである、請求項１から２８のいずれかに記載の方法。
30. 前記ドメインは、前記事業の参加者のグループ内で複数のサブブループを定義するために使用可能な事業活動に関連した特性のカテゴリ、または／及び、生産ライン、ビジネス分野、目標市場のいずれかに関連する特性を含むカテゴリに属するものである、請求項５から２９のいずれかに記載の方法。
31. 前記仕様は、前記ドメインにより定義された参加者のサブグループをさらに絞るために使用できる、または、前記ドメインをカスタマイズ可能な、１つまたは複数の前記特性である、請求項５から３０のいずれかに記載の方法。
32. 前記ボーダにより識別されるグループ内の全メンバーは、前記ドメインおよび前記仕様により識別されるグループ内の全メンバーとの強い相関関係は不要であり、特定のボーダに属するメンバーは、複数の特定のドメインまたは複数の特定の仕様に属することが可能である、請求項１２から３１のいずれかに記載の方法。
33. 前記参加者説明は、特定の参加者を識別し、前記特定の参加者の事業への参加を説明するものであり、参加者の属性及びその属性に対応する属性値を含み、参加者の前記属性は、参加者の特性であり、前記属性値は、説明されている特定の参加者の特性の名称である、請求項１から３２のいずれかに記載の方法。
34. 参加者を識別し、前記参加者の事業への参加を説明する、参加者説明データベースと、
    処理動作を実行するように構成されたデータ処理システムと、を有する装置であって、前記動作は、
    ユーザからメッセージを受信するステップと、
    前記メッセージの受領のために、事業内の選択された参加者のサブグループを識別する２つ以上の特性を受信するステップと、
    前記受信されたメッセージの受領のために参加者の前記サブグループを動的に識別するステップと、
    前記動的に識別されたサブブループの参加者にメッセージを送信するステップと、
    を有し、
    前記選択された参加者のサブグループを識別する前記特性は、キーワードの出現を伴う前記メッセージの内容から抽出され、
    識別は、前記特性と参加者説明との比較により行われることを特徴とする装置。
35. 前記データ処理システムにおける前記動作は、さらに、
    事業内の選ばれた参加者の第１のサブグループを識別する特性を受信するステップであって、前記特性は、通信の受信者を分割するために、機械読み取り可能命令の組の中にハードコード化されるステップと、
    前記第１のサブグループを第２のサブグループにさらに区分するために、可能な特性の仕様の集まりをユーザに提示するための、機械読み取り可能命令を提供するステップと、
    前記特性の仕様をユーザから受信して、前記特性および前記特性の仕様を、前記参加者説明データベース内で検出される、前記参加者の事業への参加と比較して、前記第１のサブグループを識別し、前記第１のサブグループを前記第２のサブグループに区分するステップと、を含む請求項３４に記載の装置。
36. 前記参加者説明データベースは、特定の参加者を識別し、前記特定の参加者の事業への
    参加を説明する、参加者オブジェクトを含む、請求項３４または３５に記載の装置。
37. 前記参加者オブジェクトは、前記特定の参加者の資格を説明する情報を含む、請求項３
    ６に記載の装置。
38. 前記参加者説明データベースは、特定の参加者を識別し、前記特定の参加者の事業への
    参加を説明する、参加者説明のためのデータを含み、前記参加者説明は、参加者の属性及びその属性に対応する値を含み、参加者の前記属性は、参加者の特性であり、前記値は、説明されている特定の参加者の特性の名称である、請求項３４または３５に記載の装置。
39. 前記動作における前記特性は、参加者の資格及び技能、参加者の個人的嗜好、参加者の許可レベル、公式及び非公式のグループへの参加者の所属、参加者の情報ニーズ、参加者が関与しているタスク及びプロジェクト、参加者の事業との間の関係、参加者の事業の参加の背景、参加者がアクセスするポータルコンテンツからなるカテゴリの少なくともいずれか一つに属するもの、または／及び、生産ライン、ビジネス分野、目標市場のいずれかに関連するカテゴリに属するものである、請求項３４から３８のいずれかに記載の装置。
40. 前記データ処理システムは、さらに、前記メッセージからドメイン情報を抽出可能に構成され、前記ドメイン情報は、前記事業の参加者のグループ内で複数のサブブループを定義するために使用可能な事業活動に関連した特性のカテゴリ、または／及び、生産ライン、ビジネス分野、目標市場のいずれかに関連する特性を含むカテゴリに属するものである、請求項３４から３９のいずれかに記載の装置。
41. 前記データ処理システムは、さらに、前記特性に固有の仕様の受信を含む動作を実行するように構成されており、前記仕様は、前記ドメイン情報により定義された参加者のサブグループをさらに絞るために使用できる、または、前記ドメイン情報をカスタマイズ可能な、１つまたは複数の前記特性である、請求項４０に記載の装置。
42. 前記データ処理システムは、前記ドメイン情報および前記仕様により識別されるグループ内の全メンバーとの強い相関関係は不要であり、複数の特定のドメイン情報または複数の特定の仕様に属することが可能であるボーダ情報により識別される、第３のグループを構成可能である、請求項３４から４１のいずれかに記載の装置。
43. プログラムコード部分を有するコンピュータプログラムであって、
    ユーザからメッセージを受信するステップと、
    前記メッセージの受領のために、事業内の選択された参加者のサブグループを識別する２つ以上の特性を受信するステップと、
    前記受信されたメッセージの受領のために参加者の前記サブグループを動的に識別する
    ステップと、
    前記動的に識別されたサブブループの参加者にメッセージを送信するステップと、
    を含み、
    前記選択された参加者のサブグループを識別する前記特性は、キーワードの出現を伴う前記メッセージの内容から抽出され、
    識別は、前記特性と参加者説明との比較により行われることを特徴とする方法をコンピュータに実行させるコンピュータプログラム。
44. プログラムコード部分を有するコンピュータプログラムであって、請求項２から３３に記載の方法をコンピュータに実行させるコンピュータプログラム。
45. 請求項４３または４４に記載のコンピュータプログラムを記憶した、コンピュータ読み取り可能な記憶媒体。
    

Images