(57)【要約】【課題】  通信接続要求を経路指定する方法を提供する。【解決手段】  本発明の方法は、通信接続要求に応答して通信接続要求元からコンテキスト情報を得るステップを含む。更に、通信接続アクションを決定するためにそのコンテキスト情報を使用するステップ、およびその接続アクションに基づいて通信接続要求元を接続するステップを含む。【選択図】  図２
2007529169.tif 000002
【特許請求の範囲】
【請求項１】
通信接続要求を経路指定するための方法であって、
通信接続要求に応答して、通信接続要求元からコンテキスト情報を得るステップと、
通信接続アクションを決定するために前記コンテキスト情報を使用するステップと、
前記接続アクションに基づいて前記通信接続要求元を接続するステップと
を含む方法。
【請求項２】
前記接続アクションに対する信頼要因を決定するステップを更に含む、請求項１に記載の方法。
【請求項３】
信頼要因の閾値を越えたことに応答して前記接続を遂行するステップを更に含む、請求項２に記載の方法。
【請求項４】
信頼要因の閾値を越えない接続に対して発呼者による前記接続アクションを正当化するステップを更に含む、請求項２に記載の方法。
【請求項５】
前記接続アクションを決定するステップがルール・エンジンによって行われる、請求項１に記載の方法。
【請求項６】
関連するアクションの表示を提供するステップを更に含む、請求項１に記載の方法。
【請求項７】
前記関連するアクションの表示を提供するステップが、データ送信を行うステップを更に含む、請求項６に記載の方法。
【請求項８】
前記関連するアクションの表示を提供するステップが、通知を行うステップを更に含む、請求項６に記載の方法。
【請求項９】
前記関連するアクションの表示を提供するステップが、ワークフローの開始を行うステップを更に含む、請求項６に記載の方法。
【請求項１０】
前記関連するアクションの表示を提供するステップが、ログ・アクションを行うステップを更に含む、請求項６に記載の方法。
【請求項１１】
前記関連するアクションの表示を提供するステップが、少なくとも１つの追加の接続に対して前記関連するアクションを指示するステップを更に含む、請求項６に記載の方法。
【請求項１２】
ユーザに対する通信接続を提供するための方法であって、
前記ユーザに対するコンテキスト情報を得るステップと、
通信接続アクションを決定するために前記コンテキスト情報を使用するステップと、
前記接続アクションに基づいて前記ユーザを接続するステップと
を含む方法。
【請求項１３】
前記接続アクションに対する信頼要因を決定するステップを更に含む、請求項１２に記載の方法。
【請求項１４】
信頼要因の閾値を越えたことに応答して前記接続を遂行するステップを更に含む、請求項１３に記載の方法。
【請求項１５】
信頼要因の閾値を越えない接続に対してユーザによる前記接続アクションを正当化するステップを更に含む、請求項１３に記載の方法。
【請求項１６】
前記接続アクションを決定するステップがルール・エンジンによって行われる、請求項１２に記載の方法。
【請求項１７】
発呼者のコールを経路指定する方法であって、
前記発呼者に対するコンテキスト情報を得るステップと、
通信接続アクションを決定するために前記コンテキスト情報を使用するステップと、
前記接続アクションに基づいて前記発呼者を接続するステップと
を含む方法。
【請求項１８】
前記接続アクションに対する信頼要因を決定するステップを更に含む、請求項１７に記載の方法。
【請求項１９】
信頼要因の閾値を越えたことに応答して前記接続を遂行するステップを更に含む、請求項１８に記載の方法。
【請求項２０】
信頼要因の閾値を越えない接続に対して前記発呼者による前記接続アクションを正当化するステップを更に含む、請求項１８に記載の方法。
【請求項２１】
前記接続アクションを決定するステップがルール・エンジンによって行われる、請求項１７に記載の方法。
【請求項２２】
前記通信接続アクションの決定を支援するために被呼者に対するコンテキスト情報を使用するステップを更に含む、請求項１７に記載の方法。
【請求項２３】
前記通信接続アクションの決定を支援するために被呼者のカレンダを使用するステップを更に含む、請求項１７に記載の方法。
【請求項２４】
前記通信接続アクションを決定する前に発呼者を認証するステップを更に含む、請求項１７に記載の方法。
【請求項２５】
前記通信接続アクションを決定するために発呼者による単一のアクションを要求するステップを更に含む、請求項１７に記載の方法。
【請求項２６】
前記発呼者を認証するためにバイオメトリックスを使用するステップを更に含む、請求項２４に記載の方法。
【請求項２７】
発呼者に対する通信接続を決定する方法であって、
前記発呼者に対するコンテキスト情報を得るステップと、
通信接続アクションを決定するために前記コンテキスト情報を使用するステップと、
前記接続アクションに基づいて前記発呼者を接続するステップと
を含む方法。
【請求項２８】
発呼者に対する通信接続を決定するためのサービス方法であって、
前記発呼者に対するコンテキスト情報を得るステップと、
通信接続アクションを決定するために前記コンテキスト情報を使用するステップと、
前記接続アクションに基づいて前記発呼者を接続するステップと
を含むサービス方法。
【請求項２９】
コンピュータ・サービス環境において使用するための装置であって、
発呼者に対するコンテキスト情報に基づいて前記発呼者のコールを経路指定するように動作し、前記発呼者を接続するための通信接続アクションを決定するために前記コンテキスト情報を使用する少なくとも１つのプロセッサを含む装置。
【請求項３０】
通信接続アクションを決定するためのルール・エンジンを更に含む、請求項２９に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、同期的通信を提供する分野に関し、詳しく云えば、発呼者のコンテキストに基づいてターゲットとの同期通信を得ることに関するものである。
【背景技術】
【０００２】
伝統的な電話技術は、コール要求を所望の受信者まで経路指定するためには電話番号の使用に依存している。８００番電話、９００番電話、グループ代理応答、電話転送は、すべて、発呼者によりダイヤルされた数字に基づいて、所望の特定受信者または受信者グループに到達することを可能にする。発呼者は、その後、（例えば、地域コード８００の宛先への）番号変換または（グループ代理応答におけるような）所定のファンアウトを受ける。
【０００３】
８００番電話は、公衆交換電話（ＰＳＴＮ）方式において、発信制御ポイント（ＳＣＰ）に常駐するデータベースにおけるルックアップを介して具現化される。このデータベースは、８００番電話を物理的電話番号にマップする。これは、ユーザによって入力された数字を取り出して番号変換データベースにおいてルックアップを行うシグナリング・システム７（ＳＳ７）の信号を通して達成される。返信される物理的ＰＳＴＮ番号は接続設定を行うために使用される。９００番電話に対するルックアップは、課金機構を除けば同じである。８００番電話および９００番電話の番号変換は事前設定された（動的な個人状態を無視した）変換に依存する。８００番電話および９００番電話の番号は、発呼者が所望の受信者に関連した数字をダイヤルすることを必要とする。
【０００４】
電話転送は、受信者へのパスにおける終端スイッチが、オリジナル番号の所有者によってプログラムされた第２の番号でもってオリジナル番号を置換するというサービスである。従って、電話転送は、エンド・ユーザによってプログラムされる番号変換のもう１つの形態である。電話転送は、発呼者が所望の受信者に関連した数字をダイヤルすることを必要とする。
【０００５】
コール・センタは、顧客が単一の電話番号をダイヤルするとき、多くのオペレータが応答することができるという方式のものである。企業によってまたは通信サービスとして提供される着信電話は自動着信分配器（ＡＣＤ）に経路指定される。ＡＣＤは、その後、その電話を多くの物理的電話機の１つに経路指定することが可能である。ターゲット電話機の選択は、ロンゲスト・アイドル（longest idle）またはスキル・ベースの経路指定（skills based routing）を含む多くのアルゴリズムの１つによって行うことが可能である。ターゲット電話機は、伝統的にはＡＣＤによって配置されていたが、通信の進歩は分散型コール・センタを可能にした。コール・センタは、一般に、企業によってまたは運搬業者によって（例えば、電話番号案内のために）使用される。コール・センタは、発呼者がその終了と関連した数字をダイヤルする時に到達される。
【０００６】
伝統的な電話は、発呼者がこの接続を行うために所望の受信者を表す識別子、例えば、電話番号、ｎのような短縮ダイヤル・シーケンス（ｎは数字または数字ストリング（通常は、わずか１つまたは２つの数字）、以前にダイヤル番号と関連付けられた口述の名称（例えば、音声作動ダイヤリング）等、を入力することを必要とする。Ｈ３２３およびＳＩＰ（session initiation protocol）のようなＶＯＩＰプロトコルの出現は、これが伝統的なＰＳＴＮを越えてインターネット・プロトコル（ＩＰ）アドレスまたは他の許可された指定まで拡張されることを可能にする。ＶＯＩＰプロトコルは電話パラダイムをＩＰの世界に拡張する。ＩＰの宛先に届くために、発呼ユーザは、到達されるべき所望のパーティの表示を提供しなければならない。
【０００７】
ＥＮＵＭと呼ばれる電話番号マッピング標準は、インターネットから電話番号をマップするための仕様である。ＰＳＴＮユーザに届くことを意図する「ボイス・オーバＩＰ（ＶＯＩＰ）」コール（定義によれば、インターネット・サイドで生じる）に関して、ＶＯＩＰコールはＩＰ−ＰＳＴＮゲートウェイで終了しなければならない。ＥＮＵＭは、宛先ＰＳＴＮ番号に基づいてそのようなゲートウェイの動的選択を可能にする。ＥＮＵＭルックアップはＤＮＳを介して達成される。この場合、インターネットにおいて使用されるホスト／サービス・ネーミングおよびルックアップ方式であるＤＮＳ（Domain Name System）は、所望のＰＳＴＮ番号に対するゲートウェアとして働くインターネット・ホストの名前にＰＳＴＮ番号をマップする。
【０００８】
ＣＴＩ（computer-telephonyintegration）は、コンピュータに接続されたＰＳＴＮインターフェースをプログラムすることをいう。コンピュータは、一般に、データ・ネットワークに接続され、従って、ＰＳＴＮインターフェース・カードを設けることはコンピュータがＰＳＴＮネットワークと対話することを可能にする。ＣＴＩは、基本的には、コンピュータがＰＳＴＮネットワークのエンドポイントとして作用することを可能にする。即ち、それは、ＰＳＴＮネットワークにとっては電話であるように見える。ＣＴＩの目的は、その名前が暗示するように、コンピュータ・アプリケーションがＰＳＴＮネットワークからのサービスを使用するように拡張されることを可能にすることである。
【０００９】
通信およびコンピュータ・アプリケーションにおいて個人の場所を使用することは、現在では一般的でない。携帯電話のユーザはその携帯電話の場所に適応したサービスを提供される。その例は、緊急９１１番電話、地方劇場のための映画音声、交通状況、付近のガソリン販売所等を含む。Hertz 社は、レンタカーの場所を使って道案内の手掛りを運転手に提供する対話デバイスをそのレンタカーの幾つかに備えている。調査研究所は、エンド・ユーザ・サービスにも適合するように装置の場所を使用する、博物館、小都市、および小売店用のモバイル装置上の電子ツア・ガイドを試作した。
【００１０】
通信要求を左右することを意図した公式声明のターゲットである個人のコンテキストを使用する通信アプリケーションに対してもそれは使用される。簡単な例は、既に電話に出ている人に電話しようとする場合に、誰でも聴いたことがある「話し中（busy）」信号である。誰かが個人のモバイル通信装置に連絡しようとするとき、テーマに関する新たな変動を経験することがある。例えば、Nextel社の所謂 DirectConnect（商標）電話は受信者の装置の状態に基づいた種々の態様で話をする。
【００１１】
通信アプリケーションも発呼者に関する何らかの情報を示すことができる。例えば、多くの電話サービスが、発呼者の電話番号を提供する発信者番号表示（caller ID）として知られた特徴を提供する。
【００１２】
無数の物理的センサからのデータが場所および装置の能力以上にコンテキストを拡張することも可能である。その例は、大気の測定、光レベル、音圧レベル、音声特徴の分析、重量および圧力、運動検出器、磁気ドアおよび窓スイッチ等を含む。個人の医療センサも、心拍数、血圧、体温、電子衝撃機能および抵抗等を含む種々の生理的測定に関するデータを提供することが可能である。そのようなアプリケーションの身近な例は、所謂、嘘発見器である。
【００１３】
コンテキストを意識したコンピューティングは、受信者（例えば、被呼者）に基づいてメッセージおよびコール配信を包含している。２つの例として、Xerox（商標）Parc からの Etherpyone システムおよび Olivetti（商標）からの Active Badge システムがある。それの両方とも被呼者の場所に基づいて着信コールを経路指定する。ＭＩＴからのActive Messenger（ＡＭ）システムは、被呼者の近くにある適当な装置、例えば、用紙、電話、ファクシミリに着信メッセージを経路指定する。しかし、これらの場合の経路指定は、発呼者の属性に基づいて行われるものではない。
【００１４】
伝統的な電話は、発呼者が所望の被呼者に対する番号を、またはアクセス・コードを想起することを必要とする。多くの潜在的な被呼者の場合、これは困難なことになる。短縮ダイヤルは簡単なアクセスを提供するが、依然として、発呼者がアクセス・コードを想起することを必要とし、更に、前の番号選択および短縮ダイヤル・コードとの関連付けを必要とする。求められていることは、予期された約束のような現在の発呼者の状態に応答して発呼者が適切な被呼者に到達するためのアクセスを簡易化するための方法である。
【００１５】
音声の発信は、発呼者が被呼者の名前または称号を思い出すことを必要とする。多くの潜在的な被呼者の場合、これは困難なことになる。求められていることは、ユーザにとって適切な受信者に対するアクセスを簡易化するための方法である。
【００１６】
紙製のカレンダ、ＰＤＡベースのカレンダ等を含むカレンダが種々の装置において入手可能である。これらは、予期された約束に基づいてコールするに適した人をユーザに決定させることを可能にするが、これらは、番号を読み取ること、番号を電話に入れること等を必要とすることがある。求められていることは、発呼者のコンテキスト（例えば、期待された約束）に基づいて人に到達する方法である。
【００１７】
更に、適切な人を決定することは、役割や任務を理解することを必要とすることがある。求められていることは、被呼者の番号またはＩＰアドレスに関係なく、被呼者の役割に基づいてそのような被呼者に到達する方法である。
【００１８】
ルール・ベースの経路指定も可能である。即ち、一旦（例えば、ヘルプ・デスクにおいて）受信されたコールは、時刻（time of day）のようなルールに基づいて適切な宛先（例えば、オペレータ）に経路指定され得るし、コールに関する理解された内容に基づいて経路指定され得るし（例えば、発信元に基づいて、正しい言語上の才能を持った適切なオペレータに経路指定する）、発呼回線ｉｄに基づいて経路指定され得る（例えば、この顧客に対する割り当てられたＣＲＭ担当者に経路指定する）。この機構は、すべて、側面決定（sidedetermined）と呼ばれる。必要なことは、発呼者のコンテキストに基づいて被呼対象を決定するための方法である。
【００１９】
求められていることは、より効率的な音声コールを行うために、カレンダ情報、任務リスト等のよいな企業データの使用を容易にし、被呼者および発呼者の両方に対するコンテキストを使用する方法およびシステムである。
【発明の開示】
【発明が解決しようとする課題】
【００２０】
ユーザのコンテキストがコールを開始することによって決定される適切なパーティに、そのユーザが、同期接続、例えば、音声コール接続を要求することを可能にする方法およびシステムが開示される。従来技術は、コール開始者に識別番号（例えば、被呼者に対する電話番号またはＰＩＮ番号）を提供してもらうことによってコールされるべきパーティを識別するが、本発明は、発呼者の識別子および発呼者の状況の認識度に基づいてコールされるべきパーティを選択する。
【課題を解決するための手段】
【００２１】
本発明の実施例では、接続詳細が発呼状況（コンテキスト）の認識度によって決定される。発呼者のコンテキストは、下記の４つの事項から得られた企業データおよび個人データの両方を含むが、それに限定されない。それらの事項は以下のものを含む。
（１）カレンダ、
（２）携帯電話、オフィスの電話、家庭の電話、ラップトップ・コンピュータ、デスクトップ・コンピュータ、自動車等のような個人的な装置の場所、活動性、およびネットワーク・アドレス、
（３）コール参加者が頻繁に集まるスペースに配備され、動作、音声、光、圧力等を検出する特別目的のセンサ、および
（４）コール参加者に関連した識別番号を備えている付属装置（例えば、ＲＦＩＤタグ）の存在を検出するＲＦＩＤ読取装置。
【００２２】
もう１つの実施例では、本発明は、発呼者に関して上述したソースと同じソースを含み得る被呼者のコンテキストに応答して通信を配付することを可能にする。本発明の目的は、コールに対するターゲットおよび接続の詳細を完全に指定するために発呼者からの簡単なアクションを要求することである。
【００２３】
本発明の他の種々な目的、特徴、および付随する利点は、それらが添付図面に関連して考察されるとき更に良く理解されるので、より十分に明らかとなるであろう。なお、添付図面では、同じ参照文字が、いくつかの図を通して同じまたは同様の素子を指定する。
【発明を実施するための最良の形態】
【００２４】
本発明の詳細な説明の前に、本発明はその使用に関するいくつかの例示によってより良く理解することができるであろう。
【００２５】
例１：自動車における携帯電話ユーザ（発呼者）が、自分の最新のカレンダ表示された電話会議に参加することを望んでいる。発呼者は番号を知らない。発呼者は、自分の個人番号をダイヤルし、そのコールに接続される。ここで、本発明のシステムは、発呼者がダイヤル・インしたという表示を受け取り、カレンダ情報を検索し、そのカレンダ情報を分析し、発呼者が音声電話会議に出席しようとするものと仮定するということを決定し、電話会議を開始した（パスワードを入力することを含む）。
【００２６】
例２：携帯電話のユーザ（発呼者）が同僚との会合を計画されたが、遅刻する。発呼者は同僚の番号を知らない。発呼者は彼らの個人番号をダイヤルし、そのコールに接続される。本発明のシステムは、発呼者がダイヤル・インしたという表示を受け取り、カレンダ情報を検索し、そのカレンダ情報を分析して、ユーザが特定の同僚に会おうとしているものと仮定するということを決定し、その同僚に関連したコンテキスト（例えば、存在情報）をアクセスし、同期通信のためにその同僚に到達する方法を決定し、同期通信を開始した。
【００２７】
例３：修理担当者（発呼者）がフィールドの外にあり、自分の仕事を終わろうとしている。修理担当者は自分の番号をダイヤルし、次の約束に接続される。修理担当者は、その約束が誰とのものであるかを知らない。本発明のシステムは、発呼者がダイヤル・インしたという表示を受け取り、約束情報（例えば、騒動リスト）を検索し、その約束情報を分析し、この時刻に対して許容し得る次の約束の数を決定し（例えば、自宅所有者が１１時と１時との間そこだけにおり、現在、時刻が１２:４５である場合、この１つがスキップされなければならず、修理担当者が次の約束に向かわなければならないという表示であり）、コールを開始した。
【００２８】
例４：従業員が自宅でケーブル・モデムに関する仕事をしている。彼は、ｅミーティングによって電話会議に参加するものと仮定する。彼は、自分の番号をダイヤルし、電話会議に接続される。ｅミーティングの内容が彼のスクリーン上にポップアップする。従業員はその番号を知らない。本発明のシステムは、発呼者がダイヤル・インしたという表示を受け取り、カレンダ情報を検索し、そのカレンダ情報を分析して、発呼者が音声電話会議に出席しようとしていると仮定することを決定し、電話会議（パスワードを入力することを含む）を開始した。更に、発呼者に関する出席情報は、それらがケーブル・モデムにおいて「アップ」であり、従って、ｅミーティングのデータを利用し得ることを示す。そのデータが（カレンダ情報に基づいて）検索され、スクリーン上にプッシュされる。同僚が同じ会議にダイヤル・インすることも可能であるが、出席情報が広帯域幅の使用可能性を表さない場合、接続はｅミーティング・データを受け取り得ないか、またはそれらの接続の性質に適したトランスコード済みバージョンを受け取り得ることに留意してほしい。
【００２９】
例５：患者が病院または診療室に電話し、自身を身分証明するか、または真正証明する（例えば、患者がＩＤコードまたはパスワードをキー・インする）。自分のコンテキスト（例えば、自分の医療状態、患者記録、必要な時だけ自分が電話するかどうかに関する医者の覚書、時刻）に基づいて、患者は医者に直接に連絡を取ることができる。患者が医者に接続されるとき、その患者の電子患者記録が医者のＰＤＡに送信される。
【００３０】
これらの例では、発呼者が、ダイヤルされる個人番号によって識別される。これは、使い易さを提供するためであるが、同様のサービスが１つの共通番号をダイヤルすることによっても提供可能である。発呼者の識別は、発呼回線ＩＤ（その後、発呼者を単一の装置に限定する）または他の手段を介して行うことが可能である。これらの手段の或るものは、セキュリティを提供するために使用することも可能である。例えば、識別は、話し手の識別を介するもの、または認証情報も提供し得る他のバイオメトリック識別を介するものも可能である。パスワードを必要とすることによって、それ以上のセキュリティを提供することも可能である。更に、セキュリティを優先的に適用することも可能である。即ち、カレンダ・エントリが機密のものである場合、それは認証ステップを必要とすることがあり、そうでない場合、セキュリティは必要とされないことがある。
【００３１】
図１は伝統的な電話ダイヤリング・システムの機能なブロック図を示す。素子１１０は、人またはＰＣプログラムが電話コールを開始することによって使用される装置である。素子１１０は、コール・ターゲット素子１２０の電話番号（またはＩＰアドレス）から成るダイヤリング信号１３０を送出する。その信号１３０のフォーマットは、ＰＳＴＮ電話のためのＳＳ７並びにＶＯＩＰ電話およびＰＣソフトフォンのためのＳＩＰまたはＨ３２３信号であってもよい。コール・ネットワーク素子１５０は、このコール・ターゲット電話番号またはＩＰアドレスに基づいて可能なコール経路指定サービス素子１６０（例えば、電話転送）を行うことができる。コール・ネットワーク素子１５０は、ＴＤＭ回路スイッチ・ネットワ−クまたはＩＰネットワークであってもよい。コール経路指定サービス素子１６０は、ＴＤＭ回路スイッチ・ネットワークまたはＩＰネットワークにおけるアプリケーション・サーバであってもよい。コール経路指定サービス素子１６０のロケーションは集中されてもよく、或いは分散されてもよい。コール経路指定サービス素子１６０は、内部の事前構成されたデータベース１９０に基づいて、コールをコール宛先素子１２０に経路指定するように、またはコールを実際の被呼ターゲット１７０に転送するように決定することができる。
【００３２】
図２は、本発明の実施例によるシステム２００を示す。素子２１０は、電話コールを開始する人によって使用される装置であり、電話コールを行うための要求をコール・マネージャ・サービス素子２６０に知らせるためにコール・ネットワーク素子２５０を使用することができる。素子２１０は、有線または無線電話、有線または無線ネットワーク接続および電話ソフトウェアを有するラップトップまたはデスクトップ・コンピュータ、または組込み電話機能を有する任意の物理的オブジェクト（例えば、自動車、クロック・ラジオ、セット・トップ・ボックス、ビデオ・ゲーム等）であってもよい。コール・ネットワーク素子２５０は、電話加入者の電話コールの素子２１０および２３０と通信を行うことができ且つ素子２６０によって提供される電話コール・マネージャ・サービスを使用することもできる無線および有線素子の集合体である。素子２６０は、コールの開始者を識別することができ且つ素子２７０として示された他のネットワーク・ベースのサービスを使用してその人のコンテキストを決定することができる、ネットワーク・ベースのサービスである。コール要求が関連のアクションをトリガする場合、素子２６０によって提供されたネットワーク・サービスはそれを管理することができる。ネットワーク・サービスの素子２６０は、適切なソフトウェアを実行し且つコール・ネットワーク素子２５０に対するハードウェア・インターフェースを有する専用または共用のコンピュータによって提供することが可能である。コールを開始する人の識別は、個々のアクセス番号、パスコードおよびＰＩＮ番号、パスワード、バイオメトリック・データおよび音声分析等を含む、この目的のための任意の既存方法を使用することが可能である。
【００３３】
ネットワーク・サービス素子２７０も、適切なソフトウェアを実行し且つネットワーク素子２２０および２４０に対するハードウェア・インターフェースを有する専用または共用のコンピュータによって提供することが可能であり、コールにおける参加者のコンテキスト（状況）を認識したままで使用することが可能な個人データの正確な識別、保存、および統合を行うことも可能である。ネットワーク素子２２０および２４０は、コール参加者の
（１）カレンダ、
（２）携帯電話、オフィスの電話、家庭の電話、ラップトップ・コンピュータ、デスクトップ・コンピュータ、自動車等のような個人的な装置の場所、活動性、およびネットワーク・アドレス、
（３）コール参加者が頻繁に集まるスペースに配備され、動作、音声、光、圧力等を検出する特別目的のセンサ、および
（４）コール参加者に関連した識別番号を備えている付属装置（例えば、ＲＦＩＤタグ）の存在を検出するＲＦＩＤ読取装置
を認識しているコンピューティングおよびセンシング技術を含む。なお、素子２４０が本システムでは任意選択的なものであることに留意してほしい。本発明の実施例は、素子２４０がなくても実現することが可能である。素子２４０を含むことは、ターゲット・コール参加者の状態に通信を適合させる更なる機会を提供する。
【００３４】
図３は、本発明の実施例による方法を示す。その方法はブロック３１０で始まり、コンテキスト通信要求を受け取る。コンテキスト通信要求を受け取ることは、有線または無線の電話受話器から数字またはアクセス・コードを受け取ることを伴うことがある。これは、ユーザが個人の通信番号（例えば、すべてのコールに対して同じである７または１０個の番号）ダイヤルすること、コマンドを話すこと、そのような装置におけるボタンまたはタッチ・スクリーンを押すことを含むが、それに限定されない。別の方法として、それは、スクリーン上のボタンをクリックすること、ＰＤＡにおける選択を表示することのような単一のユーザ・アクションを受けることを含むことも可能である。
【００３５】
コンテキスト通信要求は、正規のコールが接続ターゲット、即ち、被呼者の表示を必要とするという点で、発呼者が正規のコールを行うものとは異なる。被呼者は、被呼番号を表す数字をダイヤルすること、短縮ダイヤル、音声ダイヤルを使用すること、またはＶＯＩＰ接続の場合にはＶＯＩＰ宛先ＩＰアドレスを潜在的に表すこと、によって表示される。そのような数字または他の標識はコールのターゲットによって異なる。しかし、コンテキスト通信要求は変わらない。
【００３６】
次に、ブロック３２０が継続する。ブロック３２０の詳細は図４において見ることができる。ブロック３２０では、開始者または発呼者が識別され、発呼者に関連したコンテキスト情報がアクセスされる。そのような情報は次の２つのものを含むが、これに限定されない。
（１）カレンダを含む企業または個人の情報、
（２）携帯電話、オフィスの電話、家庭の電話、ラップトップ・コンピュータ、デスクトップ・コンピュータ、自動車のような個人装置の場所、活動性、およびネットワーク・アドレス。
【００３７】
ブロック３３０において、ブロック３２０でアクセスされたコンテキストに応答して、接続対象が決定される。この詳細は図５において見ることができる。接続対象は、電話会議、人、部屋、または役割を含むが、それに限定されない。決定は、発呼者のコンテキストにのみに基づくことも可能であり、或いは初期の接続対象に基づいた且つ被呼企業または被呼者のポリシ、可用性、接続性、または他の要素によって影響される反復プロセスを含むことも可能である。１つの実施例では、接続対象が発呼者のカレンダに基づいて決定される。第２の好適な実施例では、接続対象が役割および割当てデータに基づいて動的に決定される。即ち、この実施例では、接続対象は、モバイル労働力の最適化を含む企業労働力の実践に基づいて決定することが可能である。
【００３８】
ブロック３３５において、接続対象に関連したアクションが決定される。そのアクションは、接続対象に基づいて決定されてもよいし、発呼者のコンテキスト、発呼者と接続対象との間の以前の接続の履歴、被呼者のコンテキスト（役割を含む）、個人または企業のポリシ、ルール、またはアルゴリズムのうちの少なくとも１つに基づいてもよい。そのアクションは、発呼者、発呼者の企業のような発呼者と関連したエンティティ、発呼者と関連したサービスのうちの少なくとも１つと関連したルールによって決定することも可能である。そのアクションは、データ（イメージ・データを含む）を送信すること、データ・アクセスを可能にするポインタまたはＵＲＬを送信すること、ログ・レコードを作成すること、接続対象への通知を主導すること、第三者への通知を主導することを含み得るが、それに限定されない。
【００３９】
例えば、カレンダ・エントリは、「Call Dr. Doe todiscuss X-RAY for Jane Smith（Dr. Doe に電話して Jane Smith に対するＸ線を検討する）」というワードを含み得る。接続対象はDr. Doe であろうし、カレンダ・エントリを分析することによって決定される関連のアクションは、接続アクションを完成することに関連して Jane Smithに関連した最新のＸ線写真を Dr. Doe に送ることであろう。カレンダ・エントリが「Call Mrs. Smith to discuss x-ray ofher daughter Jane Smith（Mrs. Smith に電話して 彼女の娘の Jane Smith のＸ線を検討する）」を指定した場合、決定される関連のアクションは異なるであろう。
【００４０】
関連のアクションは、その関連のアクションを決定するアルゴリズムによって決定されるので、接続アクションの前に、接続アクションと並行して、または接続アクションの後に取られることもある。
【００４１】
ブロック３４０において、ブロック３３０で決定された接続対象に到達するように接続アクションが実行される。一旦接続対象が決定されると、接続アクションが更に決定される。そのようなアクションは、テーブルまたはデータベース・ルックアップに基づいてもよく、或いは、場所、被呼企業または被呼者のポリシ、可用性、接続性、接続状態、または他の要素を含むがそれに限定されない被呼者のコンテキストによって調整されてもよい。接続アクションは、電話番号をダイヤルすること、ＶＯＩＰ接続を開始すること、音声メール・ボックスに接続すること、コールを再指示すること、会議または接続サービスに接続することを含み得るが、それに限定されない。接続アクションが失敗する場合、エラー訂正が生じ得る。
【００４２】
中間結果がログされ、管理および維持のために、および将来の接続に対する接続対象のより良い解決のために、使用されてもよい。
【００４３】
図４は、ブロック３２０の詳細を示す。図４は、発呼者を識別し且つ発呼者に関する関連のコンテキストを得る本発明の方法の一部を示す。ブロック４１０において、発呼者を識別してそれを任意選択的に認証するための情報が得られる。識別情報は、発呼回線の識別、識別コード、識別のための音声データの分析、各潜在的な発呼者に対する独得の個人電話アクセス番号、個人装置に組み込まれた独得のコード（例えば、携帯電話のＳＩＭコード）、および指紋認識、顔認識、虹彩認識、および手相を含むバイオメトリック測定を含み得る。発呼者のアイデンティティは、簡単なパスワードまたはパスコードを使って、または公開鍵暗号化技術を使用するもっと精巧な方式（例えば、デジタル署名および証明書）を使って認証することが可能である。ブロック４２０において、発呼者から得られた個人識別および認証データが、許可されたユーザおよび特権を列挙した登録済みのユーザの保管装置と比較され、発呼者から得られた識別および認証データを正当化するために使用することが可能である。発呼者が識別、認証、および／または許可テストに失敗した場合、ブロック４５０に示されるように、コールは終了する。１つの実施例では、ブロック４５０に達したコールはオペレータに転送されるか、或いは別の識別および認証方法を使用するプロセスを開始してもよい。
【００４４】
発呼者がブロック４２０におけるテストを通ったことに対して、本発明は、次に、ブロック４３０に示されるように個人のコンテキスト情報を得る。これは、企業および個人のカレンダからのデータ、関連のスケジュールおよびジョブ割当てレジャーからのエントリ等を含む。このデータが単一の保管装置から得ることが可能であること、または保管装置およびネットワーク・サービスのセットから集めることが可能であることは注目される。
【００４５】
ブロック４４０において、発呼者のコンテキスト補足は、実時間センサ・データによるものである。関連のデータは次のものを含むが、それに限定されない。即ち、
（１）時刻および発呼者のタイム・ゾーン、
（２）ＧＰＳ（グローバル・ポジショニング・システム）の座標によって決定される発呼者の場所、関連の通信ネットワーク・リソース（例えば、ＴＣＰ／ＩＰサブネット）の場所、セルラー・タワー等
（３）発呼者が頻繁に行くスペースに配備された動作、音、光、圧力等を検出する特別目的のセンサからのデータ、および
（４）発呼者の生理的な状態を報告する個人医療センサ。
【００４６】
次に、フローチャートは図３のブロック３３０に戻る。
【００４７】
図５は接続対象を決定するための方法を示す。実施例では、図５および図６に示されるように、先ず、ユーザ・カレンダ・エントリが最も重要なコンテキストとして見なされる。他のコンテキストはカレンダよりも低い重要性の順位のものと見なされる。もう１つの実施例では、ブロック３３０における信頼要因は、それらが決定される方法に基づいてすべての接続対象と関連付けられる。更なるユーザの正当化なしに接続を形成する場合、事前設定された閾値を越える接続対象だけが利用される。
【００４８】
ブロック５０５を開始すると、しかも図４においてアクセスされたコンテキスト情報を使用すると、カレンダ・エントリがこの発呼者に対する現在のまたはそれに近い期間に対して使用可能である場合、プロセスはブロック５１０に進む。カレンダ・エントリが使用可能でない場合、プロセスはＡのマーカに進み、従って図６におけるブロック５７０に進む。
【００４９】
ブロック５１０はカレンダ・エントリを調べる。カレンダ・エントリは自由形式のものであってもよく、或いは、いくつかの受容された標準またはアドホック標準の１つに留まるものであってもよい。カレンダ・エントリにおける情報は、ＸＭＬを介して、またはキーワードを介して、または構成の解釈を介してアクセスし得るものであってもよい。ブロック５１０において、カレンダ・エントリ内に電話番号ターゲットが存在するかどうかを決定するために、そのカレンダ・エントリが分析される。カレンダ・エントリが自由形式のものである場合、そのエントリ内の電話番号を識別するために、テキスト分析を使用することが可能である。複数の電話番号（例えば、会合またはコールを設定する秘書に関連した電話番号）が存在し得ることに留意してほしい。カレンダ・エントリによって参照されるアクションをユーザがうまく開始するためにダイヤルされるいくつかの番号から正しい番号を識別するために、キーワード分析、セマンティック分析、ユーザ履歴、および他の技術を使用することも可能である。ブロック５１０において電話番号が検討されるとき、宛先対象を表すためにＩＰアドレスまたは他のデータ記述を使用することも可能であることは明らかである。ブロック５１０における分析は、電話番号の決定のみならず、他の形式のデータ・アドレスの決定も参照することを意図される。ブロック５１０における判断が、ターゲット電話番号が使用可能であるということであった場合、プロセスはブロック５１５に進み、その電話番号を接続対象（ＣＯ）として提供する。ブロック５４０では、図３のプロセスのブロック３４０に戻る。
【００５０】
ブロック５１０における判断が、ターゲット電話番号が使用可能でなかったということであった場合、プロセスはブロック５２０に進む。ブロック５２０では、使用可能なターゲットの名前または場所がカレンダ・エントリにあるかどうかを決定するためにカレンダ・エントリが分析される。これは、名前の始まりである大文字を捜すことから、「会議室」のようなキーワードを捜すことに、即ち、更に精密な分析に、精密度を変えるというテキスト分析技術によって決定することが可能である。
【００５１】
ブロック５２０において、名前または場所が決定され、プロセスはブロック５２５に進む。ここでは、ブロック５２０において見つかった名前または場所と接続対象が関連付けられる。ターゲットが同じ企業の従業員である場合、正しい接続対象（例えば、電話番号、ＩＰアドレス）を見つけるために、ディレクトリ・ルックアップが働くことも可能である。発呼者のプロファイルまたはレコード、発呼者のコール履歴、顧客のレコード（例えば、「ハリーと話す」は、コールを行う従業員に割り当てられた顧客であるハリー・ジョーンズにコールするという希望として解決することが可能である）、ディレクトリ・アシスタンス（例えば、「ウェストチェスタ・マリオットでジョーと会う」は、商業的に利用可能なディレクトリ・アシスタンス・サービスによってウェストチェスタ・マリオットに対する電話番号を決定するという結果を生じ得る）を含むがそれに限定されない接続対象をその名前または場所に照合するために、他のデータ・ソースを使用することも可能である。ブロック５２５では電話番号を検討したが、接続対象を表すためには、ＩＰアドレスまたは他のデータ記述も使用可能であることは明らかである。電話番号またはＩＰアドレスの他に、接続対象を接続サービスであるように決定することも可能である。即ち、明示的エントリを通してまたは企業ポリシを通して、カレンダ・エントリから決定された接続対象が、必要なアクションを完成させる企業または第三者のサービスに接続を提供することに決めることも可能である。接続サービスは、他のターゲット・エンドポイントに能動的に接続するサービス、または他のものが受動的に同じ対象をそのサービスに接続するのを待って、（一般的に電話会議へのダイヤリング時に経験するように）すべての発呼者を参加させるサービスであってもよい。プロセスはブロック５２５からブロック５３０に進んで接続対象の情報を提供し、しかる後、ブロック５４０に進む。ブロック５４０では、図３のプロセスのブロック３４０に戻る。
【００５２】
ブロック５２０における判断が、使用可能な名前または場所がないということであった場合、プロセスはブロック５５０に進む。判断ブロック５５０は、カレンダ・エントリに使用可能な何らかの情報があるかどうかを決定する。そのエントリがブランクである場合、プロセスはブロック５７０に進む。
【００５３】
そのエントリがブランクでない場合、プロセスはブロック５５５に進み、キーワードに関してエントリを調べる。例えば、エントリは、「アルファというプロジェクトに関するミーティング」または「ブローカにコールする」というものであってもよい。テキスト分析は、これらのうちのどちらが接続対象の潜在的な指示標識であるかを決定する。好適な実施例では、カレンダ・エントリにおける用語がキーワードのリストに関してチェックされる。用語は、ワード、略語、または特殊記号を含むがそれに限定されないテキストの単位である。キーワードは手操作でまたは自動的に作成することが可能である。そのようなキーワードを入手し得る自動知識プロファイル作成の例は、Tacit Knowledge 社（www.tacit.com）のような会社の製品において見ることが可能である。
【００５４】
ブロック５６０に進むと、接続対象をキーワードと関連付けることが求められる。例えば、同僚のグループがアルファというプロジェクトと関連付けられ、それらのすべてによる電話会議という接続対象を決定することが可能である。第２の例として、その方法は「ブローカ」がキーワードであると決定し得るが、更なる詳細はなく、従って、接続対象を決定することはできないであろう。ブロック５２５に関して説明したように、接続対象は接続サービスであってもよい。ブロック５６０において接続対象が少なくとも１つの見つかったキーワードと関連付けられた場合、プロセスはブロック５２５に進み、既に説明した処理を遂行する。
【００５５】
ブロック５６０において、接続対象がキーワードと関連付けられない場合、またはキーワードが見つからない場合、プロセスはブロック５７０に進み、コンテキスト・ハイアラーキをアクセスする。カレンダがその方法で使用されるべき唯一のコンテキストである場合、そのハイアラーキは空であり、プロセスはブロック５８５に進む。
【００５６】
このハイアラーキは、接続対象を決定するためには次にどのソースのコンテキストが調べられるべきかを表す。
【００５７】
例えば、電気製品修理事業では、「金」の顧客は特定の約束を与えられることがあるが、他の顧客は自分の順番を待たなければならない。そのような会社における修理担当者は、自分が守らなければならない約束を表すカレンダを有し、約束がスケジュールされてないときには、自由に次の顧客を処理する。この例では、訪問前に確認の電話をかけるために、本発明の方法は、先ず、カレンダを考慮し、次に、（会うべき次の顧客を決定するために）、役割（修理担当者）、場所、および約束を考慮する。図５および図６は考慮されるべきコンテキスト・ハイラーキの好適な実施例を示しているが、本発明の方法の別の具現化方法は、接続対象を決定するためにコンテキスト・ソースのハイアラーキを使用せず、代わりに、複数のコンテキスト・ソースからのデータを分析するルール・エンジンを使用する。
【００５８】
ブロック５７５およびブロック５８０において、ブロック５７０で設定されたソースからのコンテキストが考察され、接続対象を決定するために発呼者のコンテキストが調べられる。いずれかのコンテキスト・ソースに対する接続対象が決定される場合、プロセスはブロック５２５に進み、前に説明した処理を行う。接続対象が決定されない場合、プロセスはブロック５８５に続く。
【００５９】
ブロック５８５において、プロセスはデフォルトの接続対象をセットし、ブロック５９０においてそれをユーザによって確認する。デフォルトの接続対象はユーザ・プロファイル、企業ポリシ、または他の手段を通して設定することが可能である。デフォルトの接続対象は、その後の会議のためにコール終了ポイントを与えることが可能である。これは、不一致のカレンダ・エントリを有するパーティが「meet me」会議で約束することを可能にする。即ち、２つのパーティが会合することを意図し、１つのパーティだけがカレンダにその約束を書き込んだ場合、本発明の方法は、カレンダ・エントリのないパーティが最初にダイヤル・インすることおよびその後に適切な同僚と会議を行うことを可能にする。
【００６０】
提供された例が本発明に対する多くの可能な用途を網羅するものではないことは理解されるべきである。
【００６１】
上記の説明から、本発明の極めて重要な特徴を当業者が容易に確認することができ、その真意および範囲から逸脱することなく、種々の用法および状態に適合するように本発明の種々の変更および修正を行うことが可能である。
【００６２】
本発明が上記の実施例に限定されず、いずれの実施例も本願の「特許請求の範囲」の記載内に包含するものであることは当然である。
【図面の簡単な説明】
【００６３】
【図１】通常のダイヤリング・システムによる電話ダイヤリング・システムを示すブロック図である。
【図２】本発明の実施例によるシステムのブロック図である。
【図３】本発明による実施例のフローチャートである。
【図４】本発明の実施例に従って発呼者のコンテキスト情報をアクセスするためのフローチャートである。
【図５】本発明の実施例に従って接続対象を決定するためのフローチャートの一部分である。
【図６】本発明の実施例に従って接続対象を決定するためのフローチャートの一部分である。
【図１】
2007529169.tif 000003
【図２】
2007529169.tif 000004
【図３】
2007529169.tif 000005
【図４】
2007529169.tif 000006
【図５】
2007529169.tif 000007
【図６】
2007529169.tif 000008