(57)【要約】強制ディスパッチ呼出（１０５）または招請ディスパッチ呼出（１０３）を選択する（１０１）ディスパッチ呼出設定方法に関する。ディスパッチ呼出の発信元装置（２０）は、いずれの選択肢を選択してもよい。必要な目標ユーザ（３０，４０）の応答によって、発信元の端末は呼出を完了する選択肢を有する（１１９）。着信する装置は、強制ディスパッチ呼出を受容、拒否、または変換することが可能である（１２７）。さらに、招請ディスパッチ呼出を受容または拒否する、もしくはユーザに制御させるようなプリセット・プリファレンスを目標装置が確立してもよい（１３９）。
2006515135.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークを介した発信元装置と、１つ以上の目標装置との間のディスパッチ呼出におけるディスパッチ呼出設定方法であって、
ディスパッチ呼出メッセージを１つ以上の目標装置へ送信するメッセージ送信工程と、
１つ以上の目標装置からの応答がディスパッチ呼出に充分か否かを判定する応答判定工程と、
１つ以上の目標装置からの応答が充分な場合、発信元装置と１つ以上の目標装置との間のディスパッチ呼出を完了させる呼出完了工程とから成る方法。
【請求項２】
ディスパッチ呼出メッセージは選択されたディスパッチ呼出設定型の招請メッセージを含み、
１つ以上の目標装置からの応答が不充分な場合、１つ以上の目標装置からの応答を無視する応答無視工程と、
ディスパッチ呼出を終了させる呼出終了工程とをさらに含む請求項１に記載の方法。
【請求項３】
１つ以上の目標装置が招請メッセージを受容した場合、
通信ネットワークを介した発信元装置と１つ以上の目標装置との間のディスパッチ呼出を完了させる呼出完了工程と、
ベアラ・トラフィックを送信するベアラ・トラフィック送信工程とをさらに含む請求項２に記載の方法。
【請求項４】
メッセージ送信工程の後に１つ以上の目標装置から１つ以上の応答を受信する応答受信工程をさらに含む請求項３に記載の方法。
【請求項５】
選択されたディスパッチ呼出設定型を判定する呼出設定型判定工程をさらに含む請求項４に記載の方法。
【請求項６】
選択されたディスパッチ呼出設定型が招請メッセージ型の場合、呼出開始メッセージを送信する工程と、応答を判定する工程と、１つ以上の目標装置からの応答が充分な場合、ディスパッチ呼出を完了させる工程と、ディスパッチ呼出メッセージを含むことと、応答を無視する工程と、ディスパッチ呼出を終了させる工程と、ディスパッチ呼出を完了させる工程と、ベアラ・トラフィックを送信する工程と、１つ以上の応答を受信する工程と、選択されたディスパッチ呼出設定型を判定する工程とを実行する請求項５に記載の方法。
【請求項７】
選択されたディスパッチ呼出設定型が強制メッセージ型の場合、１つ以上の目標装置へ強制メッセージを送信する強制メッセージ送信工程をさらに含む請求項５に記載の方法。
【請求項８】
強制メッセージ送信工程の後に、
１つ以上の目標装置の強制ディスパッチ呼出への参加の是非を発信元装置が考慮するか否かを判定する考慮判定工程をさらに含み、
発信元装置が考慮しない場合、呼出完了工程とベアラ・トラフィック送信工程とをさらに含む請求項７に記載の方法。
【請求項９】
発信元装置が考慮する場合、
充分な数の１つ以上の目標装置が強制型のディスパッチ呼出を受容したか否かを判定する呼出受容判定工程をさらに含み、
充分な数が受容した場合、トラフィックの工程をさらに含み、
不充分な数が受容した場合、ディスパッチ呼出を終了させる呼出終了工程をさらに含む請求項８に記載の方法。
【請求項１０】
通信ネットワークを介した発信元装置と目標装置との間のディスパッチ呼出におけるディスパッチ呼出設定方法であって、
目標装置がディスパッチ呼出の招請メッセージを受信する招請メッセージ受信工程と、
目標装置のプリセット・プリファレンスを判定するプリファレンス判定工程と、
招請メッセージを受容するか否かを判定する受容判定工程と、
招請メッセージが受容された場合、発信元装置へ受容メッセージを送信する受容メッセージ送信工程とから成る方法。
【請求項１１】
招請メッセージを拒否することが判定された場合、発信元装置へ拒否メッセージを送信する拒否メッセージ送信工程をさらに含む請求項１０に記載の方法。
【請求項１２】
プリセット・プリファレンスがユーザ制御である場合、目標装置がユーザに着信の招請ディスパッチ呼出を通知する招請ディスパッチ呼出通知工程をさらに含む請求項１０に記載の方法。
【請求項１３】
プリセット・プリファレンスが自動受容である場合、
発信元装置へ受容応答メッセージを送信する受容応答メッセージ送信工程と、
ベアラ・トラフィックを受容するベアラ・トラフィック受容工程とをさらに含む請求項１０に記載の方法。
【請求項１４】
プリセット・プリファレンスが招請メッセージの自動拒否である場合、
目標装置が発信元装置へ拒否メッセージを送信する拒否メッセージ送信工程と、
ベアラ・トラフィックの受容を禁止するベアラ・トラフィック受容禁止工程とをさらに含む請求項１０に記載の方法。
【請求項１５】
応答メッセージ送信工程の後に、ベアラ・トラフィックを受容するベアラ・トラフィック受容工程とをさらに含む請求項１４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はディスパッチ呼出セッションの連絡に関し、より詳細にはディスパッチ呼出を連絡するために参加者を招請する方法に関する。
【背景技術】
【０００２】
今日では、大抵のプッシュ・ツー・トーク（push-to-talk）式のディスパッチ呼出は、強制型の呼出である。すなわち、発信者が話すことを望む人または人々を選択すると、選択されたユーザすなわち目標ユーザの電話機の音声機構から、即座に話者の言葉が鳴り響く。目標ユーザすなわち受信するユーザは、発話を受取るタイミングの制御権を有しないので、この呼出は強制呼出と呼ばれる。通信ネットワークの呼出処理サーバによって、目標の加入者デバイスは自動的にベアラ（bearer）・チャネルへ移され、目標の呼出者は発信元のユーザによる音声機構または他のメディアと接続されて、目標の呼出者が強制的に呼出に連絡される。それが強制呼出である。そうした強制呼出では、不適当な時に目標の加入者のデバイスにて音声機構または他のメディアが鳴り響くことがしばしばある。例えば、専念が必要な作業を行っている作業者は、梯子を登っている時または足場の上で平衡を取っている時に、自身のディスパッチ無線が突然鳴り響くことを望まないであろう。
【０００３】
さらに、現在のディスパッチ呼出では、強制ディスパッチ呼出を受信するための人間工学的な要件が、各々の目標の装置に存在しない場合がある。すなわち、コンピュータまたは典型的なセルラー電話機などの一定の無線電話が、スピーカ・ホンなど高性能の音声機構を備えていない場合があり、その場合、強制ディスパッチ呼出を受容することは不可能である。
【０００４】
現在、ディスパッチ電話機には、目標ユーザが強制呼出を拒否する性能は提供されていない。
したがって、非強制モードで操作する能力を発信元のユーザに提供するための方法が存在することが非常に望ましいであろう。さらに、ディスパッチ呼出の目標ユーザに、そのような強制呼出または非強制呼出を受容または拒否する能力を提供することも、非常に望ましいであろう。
【発明を実施するための最良の形態】
【０００５】
図１には、ディスパッチ呼出サービスを促進する通信システムを示す。通信システム１００には通信ネットワーク１０が含まれ、通信ネットワーク１０には、端末２０と端末４０との間のベアラ・トラフィックの交換および伝送を促進する、呼出処理サーバ５０が含まれる。好適な実施態様には呼出処理サーバ５０を示したが、呼出処理サーバ５０は随意の要素である。呼出処理サーバ５０を必要とせずに各々の端末が呼出の発信または着信の必要な処理を提供する、分散型の呼出処理も可能である。本発明を説明する目的において、移動体装置２０は発信元の装置であり、移動体装置３０および移動体装置４０のうちの１つ以上は目標の装置である。典型的には、例えば、発信元装置２０は、通信ネットワーク１０および呼出処理サーバ５０を通じて、目標の移動体装置４０へディスパッチ呼出の要求を送信する。呼出処理サーバ５０および通信ネットワーク１０が目標装置４０を発信元装置２０と自動的に接続すると、目標装置のラウドスピーカが発信元装置２０の通信を鳴らし始める。これを強制ディスパッチ呼出と称する。
【０００６】
目標の移動体装置４０は、梯子を登るなど、専念が必要な動作を行っているユーザ（図示せず）に所持されていてもよい。発信元装置２０からの通信を目標装置４０が鳴らすようにすることで、ユーザを驚かせ、深刻な危害などを生じる場合がある。
【０００７】
別の種類のディスパッチ呼出は、招請ディスパッチ呼出である。招請ディスパッチ呼出では、呼出が完了してベアラ・トラフィックが届けられる前に、呼出の目標ユーザが呼出を受容することが必要である。
【０００８】
図２には、発信元装置２０におけるディスパッチ呼出の設定方法の流れ図を示す。方法が開始され、ブロック１０１に進む。ブロック１０１では、発信者に選択された呼出開始方法の型を判定する。ディスパッチ呼出の型が強制呼出の場合、ブロック１０１からブロック１０５へ制御が移る。実時間で何も選択されない場合、発信元のユーザはデフォルトのディスパッチ呼出方法を有し得る。
【０００９】
ブロック１０５は、通信ネットワーク１０および呼出処理サーバ５０を通じて、目標の移動体装置３０および４０のうちの１つ以上へ強制ディスパッチ呼出の要求を送信する。グループ呼出では、典型的には目標装置３０，４０の両方が選択される。個別ディスパッチ呼出では、目標装置３０または４０の一方または他方が選択される。
【００１０】
次に、ブロック１０９は、強制呼出処理に適切なように設定可能な時間の間、目標装置からの呼出受容または呼出拒否の応答を収集するために待機する。この時間は、加入者のデバイスのデフォルトに設定されてもよく、またはユーザ・プリファレンスに制御されてもよく、通常は呼出以前に設定される。強制呼出では、大抵の目標装置は強制呼出要求に即座に応答することが期待されるので、この時間は比較的短い時間、例えば、０．５〜２秒に典型的には設定される。別の例として、発信者が目標パーティの参加を考慮しない（ブロック１２１で判定されるように）場合、呼出処理を速めるため、この時間が零に設定されてもよい。
【００１１】
次に、ブロック１２１は、どの目標装置が呼出に参加するかを発信元装置２０が考慮するか否かを判定する。どの目標装置がディスパッチ呼出に参加するかを発信元装置２０が考慮しない場合、ブロック１２１から「ＮＯ」の経路を通じてブロック１１３へ制御が移る。典型的には、発信元装置２０によるそのような伝送は、実時間での応答が必要でない目標装置の１つのグループに対する、ブロードキャスト・メッセージである。
【００１２】
どの目標装置がディスパッチ呼出に参加するかを発信元装置２０が考慮する場合、ブロック１２１から「ＹＥＳ」の経路を通じてブロック１１５へ制御が移る。
選択したディスパッチ呼出開始方法が招請の場合、ブロック１０１からブロック１０３へ制御が移る。ブロック１０３は、通信ネットワーク１０および呼出処理サーバ５０を介して、各々の目標ユーザへ、招請要求を送信する。
【００１３】
次に、ブロック１０７は、招請呼出処理に適切なように設定可能な時間の間、目標装置からの呼出受容または呼出拒否の応答を収集するために待機する。この時間は、加入者のデバイスのデフォルトに設定されてもよく、またはユーザ・プリファレンスに制御されてもよく、通常は呼出以前に設定される。招請呼出では、目標の加入者装置のユーザが加入者装置と相互作用して招請呼出の要求に応答するには幾分時間を要する場合があることが期待されるので、この時間は強制呼出より長い時間、例えば、１０〜２０秒に典型的には設定される。
【００１４】
目標装置からの応答が受信された後、ブロック１０７からブロック１１５へ制御が移る。典型的には、招請ディスパッチ呼出には全ての目標装置からの応答が含まれるが、随意で、図３に示すように、強制ディスパッチ呼出に対する応答を通信システム１００が与えないように設定されてもよい。
【００１５】
次に、ブロック１１５は、ディスパッチ呼出を実施するために必要なだけの目標ユーザが呼出を受容したか否かを判定する。呼出を受容する「必要なだけ（enough）」の目標ユーザに対するしきい値は設定可能である。しきい値は、例えば、強制呼出において、単に１つ以上の目標パーティが聴いていることを確認することを発信者が望む場合、単に１ユーザに設定することも可能である。また、例えば、５０％など、グループのメンバーとなり得る数の百分率に設定することも可能である。また、その呼出に所望の目標パーティ全てが含まれることを確認するために、グループのメンバーとなり得る全て（１００％）に設定することも可能である。続いて、設定したしきい値（またはそれより多く）のグループ呼出の目標がその呼出を受容した場合、ブロック１１９へ制御が引き渡される。必要なだけのユーザが受容しない場合、ブロック１１５から「ＮＯ」の経路を通じてブロック１１７へ制御が移る。ブロック１１７は、応答を無視し、ベアラ・トラフィックを送信しない。ここでプロセスが終了する。
【００１６】
充分な目標ユーザが応答した場合、ブロック１１５から「ＹＥＳ」の経路を通じて随意のブロック１１９へ制御が移る。随意のブロック１１９は、例えば、幾つの目標ユーザが呼出を受容したか、どの特定の目標ユーザが呼出を受容したか、どの特定の目標ユーザが呼出を拒否したかなど、誰が呼出を受容したかについての情報を発信元のユーザに示す。このことによって、ブロック１１５にて単に受容のしきい値が到達されたことを知ることを超えて、目標ユーザへの呼出を完了させるか否かについて、発信元のユーザが情報に基づく決定を行うことが可能となる。発信者が呼出を完了することを選択した場合、ブロック１１３にて、発信元装置が目標の装置にベアラ・トラフィックの送信を開始する。ここでプロセスが終了する。
【００１７】
図３には、目標装置３０，４０におけるディスパッチ呼出の開始方法の流れ図を示す。この方法によって、強制または招請ディスパッチ呼出を受信する際、目標装置３０，４０が随意で挙動を選択することが可能となる。この方法によって、目標の移動体装置が提示するプリファレンスを目標の移動体装置のユーザが選択することが可能となる。
【００１８】
方法が開始され、ブロック１２５に進む。ブロック１２５では、発信元装置２０が要求したディスパッチ呼出の開始方法を判定する。発信元装置２０が強制ディスパッチ呼出を送信していた場合、ブロック１２５からブロック１２７へ制御が移る。次に、ブロック１２７は、目標装置３０，４０の現在のプリファレンスを判定する。目標装置のプリファレンスが強制ディスパッチ呼出を受容するように設定されていた場合、ブロック１２７からブロック１２９へ制御が移る。ブロック１２９は、自動的にベアラ・トラフィックを受容する。すなわち、発信者の音声が目標装置３０および４０のうちの１つ以上の高度な音声機構出力、典型的にはスピーカで出力される。随意の工程では、ブロック１２９の前に、ブロック１２８が発信元装置２０へ受容メッセージを送信する。このことによって、どの目標装置が呼出を受容したかに関する情報に基づき、発信者が決定を行うことが可能となる。しかしながら、目標装置３０および４０のうちの１つ以上が送信する受容メッセージなしでも、発信者は図２に示した流れを適正に継続することが可能である。ここでプロセスが終了する。
【００１９】
目標装置のプリファレンスが強制ディスパッチ呼出を拒否するように設定されていた場合、ブロック１２７からブロック１３１へ制御が移る。ブロック１３１は発信元装置へ拒否メッセージを送信し、いかなるベアラ・トラフィックも受容しない。ここで方法が終了する。
【００２０】
目標の移動体装置３０または４０のプリファレンスが強制ディスパッチ呼出を変換するように設定されていた場合、ブロック１２７からブロック１３３へ制御が移る。ブロック１３３は、強制ディスパッチ呼出を招請ディスパッチ呼出に変換し、目標ユーザに対して
招請呼出の情報を表示する。次に、ブロック１３５にて、招請呼出を受容するか拒否するかを目標ユーザが判定する。変換された招請呼出を目標ユーザが受容した場合、ブロック１３５からブロック１３７へ制御が移る。ブロック１３７は、目標装置３０または４０がベアラ・トラフィック「レイト（late）」を受信することを可能とする。レイトは、着信のディスパッチ呼出の要求が目標装置３０または４０の判断によって変換された場合、発信元装置１０の設定によっては、目標ユーザが呼出を受容する時より先に、この呼出のベアラ・トラフィックが開始される場合があることを示す。このため、目標装置３０または４０が完全な伝送を受信しない場合もあるが、典型的には、それはベアラ・トラフィックの極小部分である。随意の工程では、ブロック１３７の前に、ブロック１３６が発信元装置２０へ受容メッセージを送信する。このことによって、どの目標装置が呼出を受容したかに関する情報に基づき、発信者が決定を行うことが可能となる。しかしながら、目標装置３０および４０のうちの１つ以上が送信する受容メッセージなしでも、発信者は図２に示した流れを適正に継続することが可能である。ここで方法が終了する。
【００２１】
変換されたディスパッチ呼出を拒否すると目標ユーザが判定した場合、ブロック１３５からブロック１３１へ制御が移る。ブロック１３１は発信元装置２０へ拒否メッセージを送信し、いかなるベアラ・トラフィックも受容しない。ここでプロセスが終了する。
【００２２】
発信者が要求したディスパッチ呼出の要求は招請要求であると目標装置３０または４０が判定した場合、ブロック１２５からブロック１３９へ制御が移る。ブロック１３９は目標装置のプリファレンスを判定する。目標装置３０または４０のプリファレンスが自動受容に設定されていた場合、ブロック１３９からブロック１４１へ制御が移る。ブロック１４１は、招請ディスパッチ呼出を自動的に受容し、発信元装置へ受容メッセージを応答する。続いて、目標装置３０および４０のうちの１つ以上は、ベアラ・トラフィックを受容する。ここで方法が終了する。
【００２３】
目標装置３０または４０のプリファレンスが、招請ディスパッチ呼出を自動拒否に設定されていた場合、ブロック１３９からブロック１４９へ制御が移る。ブロック１４９は、発信元装置へ拒否メッセージを送信し、いかなるベアラ・トラフィックも受容しない。ここで方法が終了する。
【００２４】
目標装置３０または４０のプリファレンスが、実時間でユーザが応答を制御することを示すように設定されていた場合、ブロック１３９からブロック１４３へ制御が移る。ブロック１４３は、着呼の招請ディスパッチ呼出を目標ユーザに通知し、呼出者のＩＤ型情報を表示する。次に、ブロック１４５は、目標ユーザが招請ディスパッチ呼出を受容したか否かを判定する。目標ユーザが実時間で招請ディスパッチ呼出を受容しない場合、「ＮＯ」の経路を通じて、ブロック１４５からブロック１４９へ制御が移る。ブロック１４９は発信元装置へ拒否メッセージを送信し、いかなるベアラ・トラフィックも受容しない。目標ユーザが招請ディスパッチ呼出を受容した場合、「ＹＥＳ」の経路を通じて、ブロック１４５からブロック１４７へ制御が移る。ブロック１４７は発信元装置２０へ受容メッセージを送信し、ベアラ・トラフィックが送信されると受容する。ここで方法が終了する。
【００２５】
上述のプリファレンスは全て、その時点での通信の要請およびユーザの行動に従って移動体装置のユーザが変更し得る、一時的な設定であってよい。さらに、目標装置として用いたディスパッチ・プラットフォームの性能に基づき、目標装置の挙動が自動的に設定されることも可能である。例えば、プラットフォームが高性能の音声機構を受容またはサポートしない場合、目標のディスパッチ装置が強制ディスパッチ呼出を受容するように設定されることはない。
【００２６】
【表１】
2006515135.tif 000003
上述の説明から理解され得るように、本発明は移動体のディスパッチ・ユーザに新規なサービス・レベル性能を提供する。発信元ユーザおよび目標ユーザの両方は、招請および強制ディスパッチ呼出の両方を取扱うためのプリファレンスを柔軟に設定し得る。これらの特徴には、呼出開始方法のデフォルトの値を設定すること、強制または招請ディスパッチ呼出を自動的に受容または拒否すること、および招請ディスパッチ呼出の表示に関連して特定のロジスティクス（logistics ）をサポートすることが含まれる。これらの利点によって、非常に柔軟なディスパッチ呼出機能が可能となり、さらに調整されたユーザ経験（例えば、ホワイトカラー環境とブルーカラー環境）および目標ユーザの安全性の向上が提供される。
【図面の簡単な説明】
【００２７】
【図１】ディスパッチ呼出のサービスをサポートする通信ネットワーク相互接続のブロック図。
【図２】発信元ユーザ用のディスパッチ呼出方法の流れ図。
【図３】ディスパッチ呼出の目標ユーザ用のディスパッチ呼出の設定方法の流れ図。
【図１】
2006515135.tif 000004
【図２】
2006515135.tif 000005
【図３】
2006515135.tif 000006
【国際調査報告】
2006515135.tif 000007