サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加しているユーザ機器を操作する方法であって、前記UEのディスプレイ上に、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するステップと、前記所与の視覚表現の少なくとも1つの座標の選択を示すユーザ入力を受信するステップと、前記少なくとも1つの座標の前記選択を示す座標パケットを、前記少なくとも1つの他のUEへの配布のために、前記サーバに選択的に送信するステップとを含む方法。前記座標パケットが、前記UEの前記ディスプレイ上の前記所与の視覚表現に相対して、前記選択が起こった位置を示すこと、および前記所与の視覚表現の少なくとも1つの異なるバージョンに対する、前記少なくとも1つの他のUEにおける前記選択の再構築を許可するための、前記所与の視覚表現に関連付けられた提示再構築パラメータセットを示すことによって、前記少なくとも1つの座標の前記選択を示す、請求項1に記載の方法。前記選択が、前記少なくとも1つの他のUEにおいて提示される前記所与の視覚表現の閲覧エリアの外の位置を選択すると判断するステップをさらに含み、前記提示再構築パラメータセットが、前記UEにおいて選択された前記少なくとも1つの座標の提示のために、前記少なくとも1つの他のUEにおける前記閲覧エリアを調整するための要求を含む、請求項2に記載の方法。前記少なくとも1つの他のUEが、前記少なくとも1つの座標の前記選択を提示したかどうかを示す指示を受信するステップをさらに含む、請求項1に記載の方法。前記少なくとも1つの座標の提示が、前記少なくとも1つの他のUEにおける前記所与の視覚表現の提示と競合すると判断するステップをさらに含み、前記選択的に送信するステップが、前記判断に基づく前記少なくとも1つの座標の前記選択を示す前記座標パケットを送信しない、請求項1に記載の方法。前記判断するステップが、前記少なくとも1つの座標が、前記少なくとも1つの他のUEにおける前記所与の視覚表現の閲覧エリアの外に提示され、または前記少なくとも1つの座標が、前記少なくとも1つの他のUEにおいて提示されることが可能でないと判断する、請求項5に記載の方法。前記少なくとも1つの座標の提示が、前記少なくとも1つの他のUEにおける前記所与の視覚表現の提示と競合すると判断するステップと、前記少なくとも1つの座標の前記選択を、前記判断された競合を解消するように修正するステップとをさらに含み、前記選択的に送信するステップが、前記少なくとも1つの座標の前記修正選択を示す前記座標パケットを送信する、請求項1に記載の方法。前記サーバが、前記座標共有通信セッションに参加している所与のUEまたは前記座標共有通信セッションに参加しているUEの外部のネットワークエンティティに対応する、請求項1に記載の方法。前記メディアコンテンツが、前記座標共有通信セッションに関連している前記UEと前記少なくとも1つの他のUEとの間で交換される、請求項1に記載の方法。前記座標共有通信セッションに関連している前記UEと前記少なくとも1つの他のUEとの間で前記メディアコンテンツが交換されないように、前記メディアコンテンツが、前記UEおよび前記少なくとも1つの他のUEにおいて単独で取得される、請求項1に記載の方法。前記受信するステップおよび前記選択的に送信するステップが、複数の時間間隔だけ繰り返し、前記受信するステップの各インスタンスが、単一の時間間隔を表す単一のユーザ入力を判断し、前記選択的に送信するステップの各インスタンスが、それぞれの単一の時間間隔に、前記単一のユーザ入力を送信することを試みる、請求項1に記載の方法。前記選択的に送信するステップが、トークスパートの送信とともに前記座標パケットを送信する、請求項1に記載の方法。前記少なくとも1つの座標の前記選択に依存しない、前記UEにおける非同期イベントを検出するステップをさらに含み、前記選択的に送信するステップが、前記検出された非同期イベントに関連付けられた非同期データとともに前記座標パケットを送信する、請求項1に記載の方法。サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加しているユーザ機器を操作する方法であって、前記UEのディスプレイ上に、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するステップと、1つまたは複数の他のUEにおいて表示される前記所与の視覚表現に基づく1組の座標を示し、前記座標共有通信セッション中の所与の期間中の前記1つまたは複数の他のUEにおけるユーザ入力により選択された座標出力フレームを前記サーバから受信するステップと、前記受信座標出力フレームに含まれる前記1組の座標を反映するように、前記所与の視覚表現を選択的に更新するステップとを含む方法。前記座標出力フレームが、前記1つまたは複数の他のUEの前記ディスプレイ上の前記所与の視覚表現に相対して、前記選択が起きた位置を示すこと、および前記UEにおける前記選択された座標の再構築を許可するための、前記所与の視覚表現に関連付けられた提示再構築パラメータセットを示すことによって、前記1組の座標の前記選択を示す、請求項14に記載の方法。前記示された位置のうち少なくとも1つが、前記UEにおいて表示される前記所与の視覚表現の閲覧エリアの外であり、前記提示再構築パラメータセットが、前記UEに、前記1組の座標の提示のために前記閲覧エリアを調整するよう要求する、請求項15に記載の方法。前記選択的に更新するステップに応答して、前記UEが前記1組の座標のうちの少なくとも1つを提示したという指示を送信するステップをさらに含む、請求項14に記載の方法。前記1組の座標のうち少なくとも1つの座標の提示が、前記UE上での前記所与の視覚表現の提示と競合すると判断するステップをさらに含み、前記選択的に更新するステップが、前記競合した少なくとも1つの座標についての前記所与の視覚表現を更新しない、請求項14に記載の方法。前記判断するステップが、前記競合した少なくとも1つの座標が、前記UEの前記所与の視覚表現の閲覧エリアの外に提示され、または前記競合した少なくとも1つの座標が、前記UEの前記所与の視覚表現内に提示されることが可能でないと判断する、請求項18に記載の方法。前記1組の座標のうち少なくとも1つの座標の提示が、前記UE上での前記所与の視覚表現の提示と競合すると判断するステップと、前記競合した少なくとも1つの座標を、前記判断された競合を解消するように修正するステップとをさらに含み、前記選択的に更新するステップが、前記修正された少なくとも1つの座標を反映するように前記所与の視覚表現を更新する、請求項14に記載の方法。前記サーバが、前記座標共有通信セッションに参加している所与のUEまたは前記座標共有通信セッションに参加しているUEの外部のネットワークエンティティに対応する、請求項14に記載の方法。前記メディアコンテンツが、前記座標共有通信セッションに関連している前記UEと前記少なくとも1つの他のUEとの間で交換される、請求項14に記載の方法。前記座標共有通信セッションに関連している前記UEと前記少なくとも1つの他のUEとの間で前記メディアコンテンツが交換されないように、前記メディアコンテンツが、前記UEおよび前記少なくとも1つの他のUEにおいて単独で取得される、請求項14に記載の方法。前記受信するステップおよび選択的に更新するステップが、複数の時間間隔だけ繰り返し、前記受信するステップの各インスタンスが、単一の時間間隔を表す単一座標出力フレームを判断する、請求項14に記載の方法。前記座標出力フレームが、前記所与のUEにおいて起きた、前記1つまたは複数の他のUEのうちの所与のUEにおける座標選択に依存しない、非同期イベントに基づく非同期データを含む、請求項14に記載の方法。前記座標出力フレームが、マルチキャストパケットに入れて受信され、前記座標出力フレームが、前記座標共有通信セッションに参加している複数のUEによって受信される共通座標出力フレームである、請求項14に記載の方法。前記座標出力フレームが、ユニキャストパケット内で受信される、請求項14に記載の方法。前記UEにおいて受信される前記座標出力フレームが、前記UEに固有であり、前記UEにおける提示に適さないデータを省く、請求項27に記載の方法。前記省かれるデータが、前記UE自体の座標選択に関連付けられたデータを含む、請求項28に記載の方法。複数のユーザ機器の間の座標共有通信セッションをサーバにおいて調停する方法であって、座標受信期間中に、前記複数のUEの各々において表示されているメディアコンテンツに関連付けられた情報を示す、前記複数のUEからの座標パケットを監視するステップと、前記複数のUEの少なくとも1つから、前記少なくとも1つのUEにおけるユーザ入力によって前記メディアコンテンツの視覚表現の座標の選択を示す座標パケットを前記CRP中に受信するステップと、前記受信された座標パケットからの、前記選択された座標を、前記CRP中の前記複数のUEによる座標選択を示すように構成された座標出力フレームセットにフォーマットするステップと、前記座標出力フレームセットを前記複数のUEに送信するステップとを含む方法。前記受信するステップが、前記CRP中に、前記複数のUEのうちの2つ以上から座標パケットを受信し、前記座標出力フレームセットのうちの1つまたは複数の座標出力フレームが、前記複数のUEのうちの前記2つ以上からの座標選択を含む、請求項30に記載の方法。前記受信するステップが、前記CRP中に、前記複数のUEのうちすべてに満たないUEから座標パケットを受信し、前記CRP中に座標パケットを与えなかった1つまたは複数のUEが、前記座標出力フレームセットから省かれる、請求項31に記載の方法。前記座標パケットが、前記少なくとも1つのUEのディスプレイ上の前記所与の視覚表現に相対して、前記選択が起こった位置を示すこと、および前記所与の視覚表現の少なくとも1つの異なるバージョンに対する、前記少なくとも1つの他のUEのディスプレイ上での前記選択の再構築を許可するための、前記所与の視覚表現に関連付けられた提示再構築パラメータセットを示すことによって、前記少なくとも1つの座標の前記選択を示す、請求項30に記載の方法。前記フォーマットするステップが、前記提示再構築パラメータセットに基づいて前記座標出力フレームセットをフォーマットする、請求項33に記載の方法。前記選択位置が、前記複数のUEのうちの1つまたは複数において提示される前記所与の視覚表現と競合すると判断するステップをさらに含み、前記フォーマットするステップが、前記少なくとも1つの座標を、前記判断された競合を解決するために、前記座標出力フレームセット内の前記複数のUEのうち前記1つまたは複数への送信用に修正する、請求項33に記載の方法。前記判断された競合が、前記複数のUEのうち前記1つまたは複数のUEの閲覧エリアの外の前記選択位置に対応し、前記フォーマットするステップが、前記選択位置を、前記閲覧エリア内に収まる、異なる位置に調整することによって、前記少なくとも1つの座標を修正する、請求項35に記載の方法。前記選択位置が、前記複数のUEのうちの1つまたは複数において提示される前記所与の視覚表現と競合すると判断するステップをさらに含み、前記フォーマットするステップが、前記複数のUEのうち前記1つまたは複数への送信用にフレーム化された前記座標出力から前記少なくとも1つの座標を省く、請求項33に記載の方法。前記送信するステップが、前記提示再構築パラメータセットを前記複数のUEのうちの1つまたは複数に送信する、請求項33に記載の方法。前記複数のUEのうちの1つが、前記少なくとも1つの座標の前記選択を提示したかどうかを示す指示を受信するステップと、前記複数のUEの前記少なくとも1つに、前記受信指示を通知するステップとをさらに含む、請求項30に記載の方法。前記サーバが、前記複数のUEのうちの1つ、または前記複数のUEの外部のネットワークエンティティに対応する、請求項30に記載の方法。前記メディアコンテンツが、前記座標共有通信セッションに関連している前記複数のUEの間で交換される、請求項30に記載の方法。前記メディアコンテンツが、前記座標共有通信セッションに関連している前記複数のUEの間で交換されないように、前記メディアコンテンツが、前記複数のUEの各々において単独で取得される、請求項30に記載の方法。前記受信するステップが、前記少なくとも1つからのトークスパートとともに前記座標パケットを受信する、請求項30に記載の方法。前記受信するステップが、前記少なくとも1つのUEにおいて起きた、前記少なくとも1つのUEにおける座標選択に依存しない、非同期イベントに関連付けられた非同期データとともに前記座標パケットを受信する、請求項30に記載の方法。前記座標共有通信セッションに関連付けられた座標情報をアーカイブするステップをさらに含み、前記アーカイブされた座標情報が、前記受信座標パケットからの前記座標出力フレームセットおよびまたは前記少なくとも1つの座標を含む、請求項30に記載の方法。前記座標共有通信セッションがアクティブである間に、所与のUEが、前記座標共有通信セッションに遅れて加わり、または停止後に前記座標共有通信セッションに再度加わったことを検出するステップと、前記アーカイブされた座標情報、および前記所与のUEが逃したと思われる前記座標共有通信セッション部分に基づいて、別の座標出力フレームセットを前記所与のUEに送信するステップとをさらに含む、請求項45に記載の方法。前記座標出力フレームセットが前記複数のUEに送信されるよりも高いレートで、前記別の座標出力フレームセットが前記所与のUEに送信される、請求項46に記載の方法。前記通信セッションが終了された後、前記アーカイブされた座標情報を所与のUEに送信すると判断するステップと、前記アーカイブされた座標情報を、別の座標出力フレームセットにフォーマットするステップと、前記別の座標出力フレームセットを前記所与のUEに送信するステップとをさらに含む、請求項45に記載の方法。前記監視するステップが、前記CRPが満了に近づいているとき、前記座標共有通信セッションに参加している少なくとも1つの高優先度UEからの座標パケットがまだ受信されていないこと、およびまたは前記CRPが満了に近づいているとき、ハンディキャップ付きUEが座標パケットをまだ与えていない場合、前記ハンディキャップが、前記複数のUEのうちの1つまたは複数に関連付けられた遅いフィードバックを示すことに応答して、前記CRPを延長するステップを含む、請求項30に記載の方法。前記監視するステップが、前記複数のUEのうちの各高優先度UEからの座標パケットが、前記CRPの満了前に受信されたこと、およびまたは前記複数のUEの各々からの座標パケットが、前記CRPの満了前に受信されたことに応答して前記CRPを短縮するステップを含む、請求項30に記載の方法。前記送信するステップが、前記座標出力フレームセットを、共通座標出力フレームとして、前記複数のUEのうちの2つ以上にIPマルチキャストにより送信する、請求項30に記載の方法。前記送信するステップが、前記座標出力フレームセットを、UE固有座標出力フレームセットとして、IPユニキャストにより前記複数のUEの各々に別々に送信する、請求項30に記載の方法。前記UE固有座標出力フレームセットが各々、それぞれの目標UEにおける提示に適さないデータを選択的に省く、請求項52に記載の方法。前記選択的に省かれたデータが、前記それぞれの目標UE自体の座標選択に関連付けられたデータを含む、請求項53に記載の方法。サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加するように構成されたユーザ機器であって、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するための手段と、前記所与の視覚表現の少なくとも1つの座標の選択を示すユーザ入力を受信するための手段と、前記少なくとも1つの座標の前記選択を示す座標パケットを、前記少なくとも1つの他のUEへの配布のために、前記サーバに選択的に送信するための手段とを備えるユーザ機器。サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加するように構成されたユーザ機器であって、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するための手段と、1つまたは複数の他のUEにおいて表示される前記所与の視覚表現に基づく1組の座標を示し、前記座標共有通信セッション中の所与の期間中の前記1つまたは複数の他のUEにおけるユーザ入力により選択された座標出力フレームを前記サーバから受信するための手段と、前記受信座標出力フレームに含まれる前記1組の座標を反映するように、前記所与の視覚表現を選択的に更新するための手段とを備えるユーザ機器。複数のユーザ機器の間の座標共有通信セッションを調停するように構成されたサーバであって、座標受信期間中に、前記複数のUEの各々において表示されているメディアコンテンツに関連付けられた情報を示す、前記複数のUEからの座標パケットを監視するための手段と、前記複数のUEの少なくとも1つから、前記少なくとも1つのUEにおけるユーザ入力によって前記メディアコンテンツの視覚表現の座標の選択を示す座標パケットを前記CRP中に受信するための手段と、前記受信座標パケットからの前記選択座標を、前記CRP中の前記複数のUEによる座標選択を示すように構成された座標出力フレームセットにフォーマットするための手段と、前記座標出力フレームセットを前記複数のUEに送信するための手段とを備えるサーバ。前記サーバが、前記複数のUEのうちの1つ、または前記複数のUEの外部のネットワークエンティティに対応する、請求項57に記載のサーバ。サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加するように構成されたユーザ機器であって、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するように構成された論理部と、前記所与の視覚表現の少なくとも1つの座標の選択を示すユーザ入力を受信するように構成された論理部と、前記少なくとも1つの座標の前記選択を示す座標パケットを、前記少なくとも1つの他のUEへの配布のために、前記サーバに選択的に送信するように構成された論理部とを備えるサーバ。サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加するように構成されたユーザ機器であって、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するように構成された論理部と、1つまたは複数の他のUEにおいて表示される前記所与の視覚表現に基づく1組の座標を示し、前記座標共有通信セッション中の所与の期間中の前記1つまたは複数の他のUEにおけるユーザ入力により選択された座標出力フレームを前記サーバから受信するように構成された論理部と、前記受信座標出力フレームに含まれる前記1組の座標を反映するように、前記所与の視覚表現を選択的に更新するように構成された論理部とを備えるユーザ機器。複数のユーザ機器の間の座標共有通信セッションを調停するように構成されたサーバであって、座標受信期間中に、前記複数のUEの各々において表示されているメディアコンテンツに関連付けられた情報を示す、前記複数のUEからの座標パケットを監視するように構成された論理部と、前記複数のUEの少なくとも1つから、前記少なくとも1つのUEにおけるユーザ入力によって前記メディアコンテンツの視覚表現の座標の選択を示す座標パケットを前記CRP中に受信するように構成された論理部と、前記受信座標パケットからの前記選択座標を、前記CRP中の前記複数のUEによる座標選択を示すように構成された座標出力フレームセットにフォーマットするように構成された論理部と、前記座標出力フレームセットを前記複数のUEに送信するように構成された論理部とを備えるサーバ。前記サーバが、前記複数のUEのうちの1つ、または前記複数のUEの外部のネットワークエンティティに対応する、請求項61に記載のサーバ。サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加するように構成されたユーザ機器によって実行されると前記UEに動作を実施させる、記録された命令を含むコンピュータ可読記録媒体であって、前記命令が、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するためのプログラムコードと、前記所与の視覚表現の少なくとも1つの座標の選択を示すユーザ入力を受信するためのプログラムコードと、前記少なくとも1つの座標の前記選択を示す座標パケットを、前記少なくとも1つの他のUEへの配布のために、前記サーバに選択的に送信するためのプログラムコードとを備える、コンピュータ可読記録媒体。サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加するように構成されたユーザ機器によって実行されると、前記UEに動作を実施させる、記録された命令を含むコンピュータ可読記録媒体であって、前記命令が、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するためのプログラムコードと、1つまたは複数の他のUEにおいて表示される前記所与の視覚表現に基づく1組の座標を示し、前記座標共有通信セッション中の所与の期間中の前記1つまたは複数の他のUEにおけるユーザ入力により選択された座標出力フレームを前記サーバから受信するためのプログラムコードと、前記受信座標出力フレームに含まれる前記1組の座標を反映するように、前記所与の視覚表現を選択的に更新するためのプログラムコードとを備える、コンピュータ可読記録媒体。複数のユーザ機器との間の座標共有通信セッションを調停するように構成されたサーバによって実行されると、前記サーバに動作を実施させる、記録された命令を含むコンピュータ可読記録媒体であって、前記命令が、座標受信期間中に、前記複数のUEの各々において表示されているメディアコンテンツに関連付けられた情報を示す、前記複数のUEからの座標パケットを監視するためのプログラムコードと、前記複数のUEの少なくとも1つから、前記少なくとも1つのUEにおけるユーザ入力によって前記メディアコンテンツの視覚表現の座標の選択を示す座標パケットを前記CRP中に受信するためのプログラムコードと、前記受信座標パケットからの前記選択座標を、前記CRP中の前記複数のUEによる座標選択を示すように構成された座標出力フレームセットにフォーマットするためのプログラムコードと、前記座標出力フレームセットを前記複数のUEに送信するためのプログラムコードとを備える、コンピュータ可読記録媒体。前記サーバが、前記複数のUEのうちの1つ、または前記複数のUEの外部のネットワークエンティティに対応する、請求項65に記載のコンピュータ可読記録媒体。ユーザ機器は、サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加する。UEは、座標共有通信セッションに関連付けられたメディアコンテンツの、所与の視覚表現を表示する。ある実施形態では、UEは、所与の視覚表現の少なくとも1つの座標の選択を示すユーザ入力を受信し、座標パケットにより、座標選択をサーバに報告する。座標共有通信セッション中、サーバは、参加UEからの座標パケットを監視し、それぞれのUEにおける選択座標を示す座標出力フレームをフォーマットする。別の実施形態では、UEは、少なくとも1つの他のUEにおける座標選択を示す座標出力フレームを受信し、それに従って、UEの所与の視覚表現を選択的に更新する。本発明の実施形態およびその付随する利点の多くのより完全な諒解は、以下の詳細な説明を参照し、本発明を限定するためではなく単に例示するために提示する添付の図面とともに考察することによってよりよく理解されれば、容易に得られるであろう。本発明の特定の実施形態を対象とする以下の説明および関連する図面で本発明の態様を開示する。本発明の範囲から逸脱することなく、代替的な実施形態を考案することができる。さらに、本発明の関連する詳細を不明瞭にしないように、本発明のよく知られている要素については詳細に説明しないか、または省略する。例示的およびまたは例という用語は、本明細書では例、事例、または例示として機能することを意味するために使用される。本明細書で例示的およびまたは例として説明するいかなる実施形態も、必ずしも他の実施形態よりも好ましいまたは有利であると解釈すべきではない。同様に、本発明の実施形態という用語は、本発明のすべての実施形態が、論じられた特徴、利点または動作モードを含むことを必要としない。さらに、多くの実施形態が、たとえば、コンピューティングデバイスの要素によって実行すべき一連のアクションに関して説明される。本明細書で説明する様々なアクションは、特定の回路によって、1つもしくは複数のプロセッサによって実行されるプログラム命令によって、または両方の組合せによって実行できることが認識されよう。さらに、本明細書で説明するこれらの一連のアクションは、実行時に、関連するプロセッサに本明細書で説明する機能を実行させるコンピュータ命令の対応するセットを記憶した、任意の形式のコンピュータ可読記憶媒体内で完全に具現化されるものと見なすことができる。したがって、本発明の様々な態様は、すべてが特許請求される主題の範囲内に入ることが企図されているいくつかの異なる形式で具現化できる。さらに、本明細書で説明する実施形態ごとに、任意のそのような実施形態の対応する形式を、たとえば、記載のアクションを実行するように構成された論理として本明細書で説明することがある。本明細書ではユーザ機器と呼ばれる高データレート加入者局は、モバイルでも固定でもよく、ノードBと呼ばれ得る1つまたは複数のアクセスポイントと通信することができる。UEは、ノードBのうちの1つまたは複数を介して、無線ネットワークコントローラとの間でデータパケットを送受信する。ノードBおよびRNCは、無線アクセスネットワークと呼ばれるネットワークの部分である。無線アクセスネットワークは、複数のUE間に音声およびデータパケットをトランスポートすることができる。無線アクセスネットワークは、無線アクセスネットワークの外部の追加のネットワークにさらに接続されていてもよく、そのようなコアネットワークは、特定のキャリア関連のサーバおよびデバイス、ならびに企業内イントラネット、インターネット、公衆交換電話網、サービング汎用パケット無線サービスサポートノード、ゲートウェイGPRSサポートノードなど他のネットワークへの接続を含んでおり、各UEとそのようなネットワークとの間で音声およびデータパケットをトランスポートすることができる。1つまたは複数のノードBとのアクティブなトラフィックチャネル接続を確立したUEは、アクティブなUEと呼ぶことができ、トラフィック状態であると呼ぶことができる。1つまたは複数のノードBとのアクティブなトラフィックチャネル接続を確立する過程にあるUEは、接続セットアップ状態であると呼ぶことができる。UEは、ワイヤレスチャネルまたは有線のチャネルを介して通信する任意のデータデバイスとすることができる。UEは、さらに、限定はしないが、PCカード、コンパクトフラッシュデバイス、外付けまたは内蔵のモデム、あるいはワイヤレスまたは有線の電話を含むいくつかのタイプのデバイスのうちの任意のものでもよい。UEが信号をノードBに送る通信リンクは、アップリンクチャネルと呼ばれる。ノードBが信号をUEに送る通信リンクは、ダウンリンクチャネルと呼ばれる。本明細書で使用する場合、トラフィックチャネルという用語は、アップリンク逆方向、またはダウンリンク順方向トラフィックチャネルのいずれかを指し得る。図1は、本発明の少なくとも1つの実施形態によるワイヤレス通信システム100の例示的な一実施形態のブロック図を示す。システム100は、パケット交換データネットワークとUE102、108、110、112との間にデータ接続を提供するネットワーク機器にアクセス端末102を接続することができるアクセスネットワークまたは無線アクセスネットワーク120と、エアインターフェース104を介して通信しているセルラー電話102などのUEを含むことができる。本明細書に示すように、UEは、セルラー電話102、携帯情報端末108、本明細書では双方向テキストページャとして示すページャ110、さらにはワイヤレス通信ポータルを有する個別のコンピュータプラットフォーム112とすることができる。したがって、本発明の実施形態は、それだけには限定されないが、ワイヤレスモデム、PCMCIAカード、パーソナルコンピュータ、電話、またはそれらの任意の組合せまたは部分的組合せを含めて、ワイヤレス通信ポータルを含む、またはワイヤレス通信機能を有する任意の形態のアクセス端末において実現することができる。さらに、本明細書で使用するように、他の通信プロトコル以外におけるUEという用語は、互換的にアクセス端末、AT、ワイヤレスデバイス、クライアントデバイス、モバイル端末、移動局、およびそれらの変形と呼ばれ得る。再び図1を参照すると、ワイヤレス通信システム100の構成要素、および本発明の例示的な実施形態の要素の相互関係は、図示の構成に限定されない。システム100は、例にすぎず、ワイヤレスクライアントコンピューティングデバイス102、108、110、112などのリモートUEが、無線で互いの間で、およびまたはそれだけには限定されないが、コアネットワーク126、インターネット、PSTN、SGSN、GGSN、およびまたは他のリモートサーバを含めて、エアインターフェース104およびRAN120を介して接続される構成要素の間で通信することができる任意のシステムを含むことができる。RAN120は、RNC122に送られるメッセージを制御する。RNC122は、サービング汎用パケット無線サービスサポートノードとUE102108110112との間のベアラチャネルのシグナリング、確立、およびティアダウンを行う役目を果たす。また、リンクレイヤ暗号化が可能な場合、RNC122は、エアインターフェース104を介してコンテンツを転送する前に、コンテンツを暗号化する。RNC122の機能は、当技術分野でよく知られており、簡潔のためにこれ以上は説明しない。コアネットワーク126は、ネットワーク、インターネット、およびまたは公衆交換電話網によってRNC122と通信することができる。あるいは、RNC122は、インターネットまたは外部ネットワークに直接接続することができる。一般的に、コアネットワーク126とRNC122との間のネットワークまたはインターネット接続は、データを転送し、PSTNは、ボイス情報を転送する。RNC122は、複数のノードB124に接続することができる。コアネットワーク126と同様の方法で、RNC122は、一般的に、データ転送およびまたはボイス情報転送のために、ネットワーク、インターネット、およびまたはPSTNによってノードB124に接続される。ノードB124は、データメッセージを、たとえばセルラー電話102などのUEにワイヤレスでブロードキャストすることができる。当技術分野で知られているように、ノードB124、RNC122、および他の構成要素は、RAN120を形成することができる。しかし、代替構成が使用されてもよく、本発明は、図示の構成に限定されない。たとえば、別の実施形態では、RNC122、およびノードB124のうちの1つまたは複数の機能は、RNC122とノードB124の両方の機能を有する単一のハイブリッドモジュールに縮小することができる。図2Aは、本発明の一実施形態によるコアネットワーク126を示す。特に、図2Aは、WCDMAシステム内に実装される汎用パケット無線サービスコアネットワークの構成要素を示す。図2Aの実施形態では、コアネットワーク126は、サービングGPRSサポートノード160、ゲートウェイGPRSサポートノード165、およびインターネット175を含む。しかし、代替実施形態では、インターネット175およびまたは他の構成要素の部分がコアネットワークの外部に配置されていてもよいことを諒解されたい。一般に、GPRSは、インターネットプロトコルパケットを送信するために、GlobalSystemforMobilecommunications電話によって使用されるプロトコルである。GPRSコアネットワークは、GPRSシステムの中央部であり、WCDMAベースの3Gネットワークのサポートも提供する。GPRSコアネットワークは、GSMコアネットワークの一体部であり、GSMおよびWCDMAネットワークにおけるIPパケットサービスのモビリティ管理、セッション管理、およびトランスポートを提供する。GPRSトンネリングプロトコルは、GPRSコアネットワークの限定的なIPプロトコルである。GTPは、GGSN165において、まるで1つの位置からインターネットに接続し続けながら、GSMまたはWCDMAネットワークのエンドユーザがあちこちに移動することができるプロトコルである。これは、加入者のデータを加入者の現在のSSGN160から、加入者のセッションを処理しているGGSN165に転送することによって達成される。GTPの3つの形態、すなわちGTPU、GTPC、およびGTPがGPRSコアネットワークによって使用される。GTPUは、パケットデータプロトコルコンテキストごとに分離されたトンネルでのユーザデータの転送に使用される。GTPCは、制御シグナリングに使用される。GTPは、GSNから課金機能への課金データの転送のために使用される。図2Aを参照すると、GGSN165は、GPRSバックボーンネットワークと外部パケットデータネットワーク175との間のインターフェースとして働く。GGSN165は、関連するパケットデータプロトコル形式のパケットデータを、SGSN160から来るGPRSパケットから抽出し、対応するパケットデータネットワーク上でパケットを送る。他の方向では、着信データパケットは、GGSN165によってSGSN160に向けられ、SGSN160は、RAN120によってサービスされる宛先のUEの無線アクセスベアラを管理し、制御する。それによって、GGSN165は、ターゲットUEの現在のSGSNアドレス、およびそのユーザのプロファイルをそのロケーションレジスタに記憶する。GGSNは、IPアドレス割当ての役目を果たし、接続されたUEのデフォルトルータである。また、GGSNは、認証および課金機能を実行する。一例では、SGSN160は、コアネットワーク126内の多くのSGSNのうちの1つの代表である。各SGSNは、関連する地理的サービスエリア内で、UEからおよびUEにデータパケットを配信する役目を果たす。SGSN160のタスクには、パケットルーティングおよび転送、モビリティ管理、論理リンク管理、ならびに認証および課金機能がある。SGSNのロケーションレジスタは、位置情報、および、たとえばユーザまたはUEごとに1つまたは複数のPDPコンテキスト内など、SGSN160に登録されたすべてのGPRSユーザのユーザプロファイルを記憶する。したがって、SGSNは、GGSN165からのダウンリンクGTPパケットの逆トンネリング、GGSN165方向のIPパケットのアップリンクトンネル、UEがSGSNサービスエリアの間を移動するときのモビリティ管理の実行、モバイル加入者の支払い請求の役目を果たす。当業者なら諒解するように、~の他に、GSMEDGEネットワークのために構成されたSGSNは、WCDMAネットワークのために構成されたSGSNと比較して、わずかに異なる機能を有する。RAN120システムアーキテクチャにおけるUTRANなどは、フレームリレーまたはIPなどの送信プロトコルによって、Iuインターフェースを介してSGSN160と通信する。SGSN160は、SGSN160および他のSGSNと内部のGGSNとの間のIPベースのインターフェースであり、上記で定義されたGTPプロトコルを使用するGnインターフェースを介してGGSN165と通信する。図2Aには示されていないが、Gnインターフェースは、ドメインネームシステムによっても使用される。GGSN165は、公衆データネットワークに、次にインターネット175に、IPプロトコルによるGiインターフェースを介して直接、またはワイヤレスアプリケーションプロトコルゲートウェイを介して接続される。PDPコンテキストは、UEがアクティブなGPRSセッションを有するとき、特定のUEの通信セッション情報を含む、SGSN160とGGSN165の両方に存在するデータ構造である。UEは、GPRS通信セッションを開始することを望むとき、まず、SGSN160に接続し、次いでGGSN165によりPDPコンテキストを起動させなければならない。これによって、加入者が現在訪問しているSGSN160、およびUEのアクセスポイントにサービスしているGGSN165において、PDPコンテキストデータ構造が割り振られる。図2Bは、図1のワイヤレス通信システム100の一例をより詳細に示す。特に、図2Bを参照すると、UE1~Nは、異なるパケットデータネットワークのエンドポイントによってサービスされる位置でRAN120に接続するものとして示されている。図2Bの例は、WCDMAシステムおよび用語に固有のものであるが、1xEVDOシステムに適合するために図2Bをどのように変更することができるかは理解されよう。したがって、UE1およびUE3は、第1のパケットデータネットワークエンドポイント162、外部エージェントなどに対応し得るによってサービスされる部分でRAN120に接続する。第1のパケットデータネットワークエンドポイント162は、次に、ルーティングユニット188を介して、インターネット175、ならびにまたは認証、認可およびアカウンティングサーバ182、プロビジョニングサーバ184、アーカイブデータベース186、およびもしくはアプリケーションサーバ170のうちの1つもしくは複数に接続する。UE2およびUE5~Nは、第2のパケットデータネットワークエンドポイント164によってサービスされる部分でRAN120に接続する。第1のパケットデータネットワークエンドポイント162と同様に、第2のパケットデータネットワークエンドポイント164は、次に、ルーティングユニット188を介して、インターネット175、ならびにまたはAAAサーバ182、プロビジョニングサーバ184、アーカイブデータベース186、およびもしくはアプリケーションサーバ170のうちの1つもしくは複数に接続する。UE4は、直接インターネット175に接続し、次いでインターネット175を介して、上記のシステム構成要素のうちのいずれかに接続することができる。図2Bを参照すると、UE1、UE3、およびUE5~Nは、ワイヤレス携帯電話として示され、UE2は、ワイヤレスタブレット型PCとして示され、UE4は、有線のデスクトップステーションとして示されている。しかし、他の実施形態では、ワイヤレス通信システム100が任意のタイプのUEに接続することができ、図2Bに示される例は、システム内に実装され得るUEのタイプを制限するものではないことを諒解されよう。また、AAA182、プロビジョニングサーバ184、アーカイブデータベース186、およびアプリケーションサーバ170はそれぞれ、構造的に別のサーバとして示されているが、本発明の少なくとも1つの実施形態において、これらのサーバのうちの1つまたは複数は、統合されていてもよい。さらに、図2Bを参照すると、アプリケーションサーバ170は、複数のメディア制御コンプレックス1~N170Bと複数の地域ディスパッチャ1~N170Aとを含むものとして示されている。集合的に、地域ディスパッチャ170AおよびMCC170Bは、少なくとも1つの実施形態では、ワイヤレス通信システム100内の通信セッションを調停するように集合的に機能するサーバの分散型ネットワークに対応することができるアプリケーションサーバ170内に含まれる。たとえば、アプリケーションサーバ170によって調停される通信セッションは、理論上、システム100内のどこかに位置するUE間で行われ得るので、調停された通信セッションの待ち時間を減らすために、複数の地域ディスパッチャ170AおよびMCCが分散される。したがって、アプリケーションサーバ170を参照すると、関連する機能は、地域ディスパッチャ170Aのうちの1つもしくは複数、およびまたはMCC170Bのうちの1つもしくは複数によって実施することができることを諒解されよう。地域ディスパッチャ170Aは、全般的に、通信セッションを確立することに関連する任意の機能を受け持ち、MCC170Bは、通話中シグナリング、調停された通信セッション中の媒体の実際の交換を行うことを含めて、呼インスタンスの間の通信セッションをホストする役目を果たす。図3を参照すると、セルラー電話などのUE200は、コアネットワーク126、インターネットならびにまたは他のリモートサーバおよびネットワークから最終的に来ることがある、RAN120から送信されたソフトウェアアプリケーション、データおよびまたはコマンドを受信し、実行することができるプラットフォーム202を有する。プラットフォーム202は、特定用途向け集積回路208もしくは他のプロセッサ、マイクロプロセッサ、論理回路、または他のデータ処理デバイスに動作可能に結合された、送受信機206を含むことができる。ASIC208または他のプロセッサは、ワイヤレスデバイスのメモリ212中の任意の常駐プログラムとインターフェースするアプリケーションプログラミングインターフェース210レイヤを実行する。メモリ212は、読取り専用メモリもしくはランダムアクセスメモリ、EEPROM、フラッシュカード、またはコンピュータプラットフォームに共通の任意のメモリから構成することができる。プラットフォーム202は、メモリ212中でアクティブに使用されないアプリケーションを保持することができるローカルデータベース214を含むこともできる。ローカルデータベース214は、一般にフラッシュメモリセルであるが、磁気媒体、EEPROM、光学媒体、テープ、ソフトまたはハードディスクなど、当技術分野で知られている任意の二次記憶デバイスとすることができる。内部プラットフォーム202の構成要素はまた、当技術分野で知られていているように、他の構成要素の中でもアンテナ222、ディスプレイ224、プッシュツートークボタン228およびキーパッド226などの外部デバイスに動作可能に結合され得る。したがって、本発明の一実施形態は、本明細書で説明した機能を実行する能力を含むUEを含むことができる。当業者ならば諒解するように、様々な論理要素は、本明細書で開示する機能を達成するために、個別の要素、プロセッサ上で実行されるソフトウェアモジュール、またはソフトウェアとハードウェアとの任意の組合せで実施できる。たとえば、ASIC208、メモリ212、API210およびローカルデータベース214をすべて協働的に使用して、本明細書で開示する様々な機能をロード、記憶および実行することができ、したがってこれらの機能を実行する論理を様々な要素に分散することができる。あるいは、機能を1つの個別構成要素に組み込むことができる。したがって、図3のUE200の特徴は、単に例示にすぎないものと見なされ、本発明は、示された特徴または構成に限定されない。UE102またはUE200とRAN120との間のワイヤレス通信は、たとえば符号分割多元接続、WCDMA、時分割多元接続、周波数分割多元接続、直交周波数分割多元、GlobalSystemforMobileCommunications、またはワイヤレス通信ネットワークもしくはデータ通信ネットワークで使用され得る他のプロトコルなど、異なる技術に基づき得る。たとえば、WCDMAでは、データ通信は、一般的に、クライアントデバイス102、ノードB124、およびRNC122の間である。RNC122は、コアネットワーク126、PSTN、インターネット、仮想専用ネットワーク、SGSN、GGSNなど複数のデータネットワークに接続することができ、したがって、UE102またはUE200は、より広い通信ネットワークにアクセスすることができる。上記で説明し、当技術分野で知られているように、ボイス送信、およびまたはデータは、様々なネットワークおよび構成を使用してRANからUEに送信することができる。したがって、本明細書で提供する例は、本発明の実施形態を限定するためのものではなく、単に本発明の実施形態の態様の説明を助けるためのものにすぎない。以下、本発明の実施形態は、全般的に、WCDMAプロトコルおよび関連する用語に従って説明される、モバイルユニット、アクセス端末などの代わりにUE、EVDOでのBSCとは異なりRNC、EVDOでのBSまたはMPTBSとは異なりノードBなど。しかしながら、WCDMA以外のワイヤレス通信プロトコルとともに本発明の実施形態がどのように適用され得るかを、当業者は容易に諒解されよう。本発明の実施形態は、グループ通信セッション中の複数のUEの間での座標情報の共有を対象とする。後でより詳しく説明するように、所与のユーザが自分のUEと対話するとき、そのUEは、UEのディスプレイ上の、所与のユーザについての少なくとも1つの特定の当該点を判定する。たとえば、特定の当該点は、所与のユーザの指がタッチしている、UEのタッチスクリーンディスプレイ上の場所に対応し得る。別の例では、所与のユーザがタッチスクリーンディスプレイの複数の場所をタッチしている場合、複数の特定の当該点をUEによって検出することができる。別の例では、特定の当該点は、UEがカーソルを動かし、かつまたはクリックした、UEのディスプレイ上の場所に対応し得る。別の例では、特定の当該点は、ユーザによる、UEのディスプレイのタッチと、ユーザがタッチしているディスプレイの位置の移動の組合せとに基づき得る。図4Aは、本発明の実施形態による、当該点を示す座標情報が複数のUEの間で共有されるための、複数のUEの間のサーバ調停型グループ通信セッションをセットアップするプロセスを示す。図4Aを参照すると、所与のUEが、少なくともUE2およびUE3を含む所与の通信グループとの座標共有グループ通信セッションの開始を決定すると仮定する。したがって、UE1は、400Aで、グループ通信セッションを開始するための要求を、RAN120を介してアプリケーションサーバ170に送信する。ある例では、400Aのセッション開始要求は、グループ通信セッションに参加しているUEの各々において何らかの方法で表示されるメディアコンテンツに関連付けられ得る。たとえば、セッション開始要求は、グループ通信セッション中に表示されるべき特定の地図、または様々なメディアコンテンツに関連付けられた特定のビデオゲームを指定することができる。アプリケーションサーバ170は、UE1からセッション開始要求を受信し、所与の通信グループに属す目標UEを識別および位置特定し、次いで、405Aで、所与の通信グループにグループ通信セッションを告知する。図4Aの実施形態において、UE2とUE3の両方が、アプリケーションサーバ170から告知メッセージを受信し、告知されたグループ通信セッションの受諾を決断し、その結果、410Aおよび415Aで、UE2およびUE3が、受諾を示す肯定応答メッセージをアプリケーションサーバ170に送ると仮定する。この点において、アプリケーションサーバ170は、グループ通信セッションが始まり得るとUE1~3に命令し、420A、425Aおよび430Aで、UE1~3の各々が、グループ通信セッション中にUE1~3のユーザが対話することになるメディアコンテンツの所与の視覚表現を表示する。たとえば、メディアコンテンツは、地図に対応してよく、地図の所与のバージョンが、UE1~3の各々に表示され得る。ただし、地図のケースでは、異なる地図およびまたは同じ地図の異なる表現が、それぞれのUEにおいて表示され得る。たとえば、UE1のディスプレイが、UE2のディスプレイよりも高い解像度が可能である場合、地図は、それぞれのUEの各々において、最も高い実際の解像度で表示され得る。別の例では、グループ通信セッションは、何らかのタイプのゲームセッションに対応してよく、メディアコンテンツは、ゲームのレベルに対応し得る。この場合、レベルは、それぞれのUEにおいてほぼ同じに見え得るが、やはり微妙な違いがあってよく、たとえば、特定のUEのユーザが、自分のスコアを、他のユーザのスコアよりも目立つように表示させる。別の例では、UE1は、メディアコンテンツを、所与のUEから他の参加UEにプッシュすることができる。さらに別の例では、メディアコンテンツは、UE1のユーザによって選択され、メディアコンテンツの視覚表現の上にオーバーレイされるモダリティに関連付けられ得る。たとえば、モダリティは、選択され、次いで、グループ通信セッションの参加UEの間で共有され得る選択可能なタッチ点の配置に対応し得る。メディアコンテンツに関連付けられたモダリティは、UE1およびまたは他のUEのうちの1つからの入力に基づいて、グループ通信セッション中に変化し得ることが諒解されよう。さらに、タッチ点のうちの1つまたは複数は、UE1によって選択的に有効または無効にすることができ、そうすることによって、異なるタッチ点が、グループ通信セッション中の異なるときに、参加UEによる選択に使用可能である。代替実施形態では、図4Aのグループ通信セッションは、UE1のユーザが、たとえば、UE1にあるカレンダイベント中で実施される経路地図のうちの1つまたは複数に関連付けられたPLANボタンをプッシュしたときに引き起こされ得る。この場合、PLANは、グループ通信セッションのセットアップ中にUE1からUE2~3に伝えられ得る。UE2~3には、ACCEPT、DECLINEおよびMODIFY選択肢が与えられ得る。図4Aでは、UE2~3は、UE1によって設定されたようにグループ通信セッションを単に受諾すると仮定されるが、このことが常に成り立つ必要はなく、グループ通信セッションの条件が確定される前に、セッション交渉手順が起こり得ることが諒解されよう。PLANを受諾した後、開始ウィンドウ中に、発信者イニシエータは、PLANを修正してよく、または準備ができているときは、グループ通信セッションを開始してよい。PLANが、関連付け経路地図をもつ何らかのタイプの移動イベントである例では、グループ通信セッションは、参加者の進行ならびにアクションが追跡され、1組の画像、アイコンおよびオーディオ要素を使ってグループに逆ブロードキャストされるリアルタイムのグループセッションに対応し得る。イベントおよびPLANが、地図と、行程に沿った物理的進行とを使用するとき、ジオビーコニングおよびジオフェンシング、ならびに所定の瞬間が、個人またはグループアラート用のトリガとして使われ得る。セッション中、どの参加者も、他のどの参加者またはグループ全体とも直接関与することができる。そのようにして、イベントのホストは、参加者を監視し、個人またはその全員と通信することができる。さらに、図4Aにおいて明示的には示さないが、420A、425Aおよび430Aで、メディアコンテンツは、いくつものやり方でUE1~3において関連視覚表現により表示されることが諒解されよう。たとえば、メディアコンテンツは、図4Aに示すグループ通信セッションのセットアップ中に、UE1~3のうちの1つまたは複数によってダウンロードされ得る。あるいは、グループ通信セッションがより迅速にセットアップすることができ、アプリケーションサーバ170は、グループ通信セッションのセットアップ中に、予めロードされたコンテンツに関連付けられた参照またはポインタをUE1~3に伝えるだけでよいように、メディアコンテンツは、UE1~3のうちの1つまたは複数において予めロードされ得る。あるいは、メディアコンテンツは、UE1~3の間でリアルタイムに、UE1~3のうちの1つまたはアプリケーションサーバ170自体によって提供されるビデオフィードと交換することができる。したがって、420A~430Aの後、メディアコンテンツの視覚表現が、UE1~3の各々において表示されている。次に、UE1~3の各々は、435A、440Aおよび445Aで、UEのそれぞれのユーザから、それぞれ、UE1~3におけるディスプレイ上の視覚表現の少なくとも1つの座標の選択を示すユーザ入力を受信する。ある例では、UE1のユーザがUE1においてSENDボタンを選択するとすぐに、およびまたはUE2~3がグループ通信セッションに加わることを決定するとすぐに、それぞれのUEの座標選択のログ記録が始まり得る。たとえば、UE1~3のユーザは各々、それぞれのディスプレイ上の視覚表現の特定の点を選択することができる。地図のケースでは、ユーザは、たとえば、地図上に表示された特定の建物を選択し得る。ゲームのケースでは、ユーザは、アイテム、キャラクタというゲームでのウォーリーの居場所などのような、視覚表現上の当該点を選択し得る。ある例では、UE1~3の選択座標は、それぞれの表示画面上の位置に対応し得る。別の例では、UE1~3の選択座標は、それぞれの表示画面上のメディアコンテンツの、レンダリングまたは表示された視覚表現に専用である、表示画面の部分内の位置に対応し得る。したがって、たとえば、特定のUE上のメディアコンテンツの視覚表現が、ウィンドウの内側でフレーム化される場合、選択座標は、視覚表現を含むフレーム化されたウィンドウに関連し得る。図5Aは、メディアコンテンツがニューヨーク市の地図に相当する例において、435A、440Aおよび445A中にUE1~3のユーザから受信され得るユーザ入力の例を示す。図5Aに示すように、UE1のユーザは、地図の中央左側の位置または座標を選択し、UE2のユーザは、地図の右上側の位置または座標を選択し、UE3のユーザは、地図の右下側の位置または座標を選択する。あるいは、図4Aの435A~445Aの選択座標は、UE1~3における変換動作の結果であり得る。たとえば、メディアコンテンツが、図5Aにあるようにニューヨーク市の地図に相当する場合、UE1~3における表示は、地図上で様々な程度までズームインされ得る。次に、UE1~3のユーザは各々、それぞれの地図においてエンパイアステートビルディングを選択すると仮定する。UE1のユーザにとって、このことは、ディスプレイの左側がタッチまたは選択されることを意味してよく、UE2のユーザにとって、このことは、ディスプレイの右側がタッチまたは選択されることを意味し得る。この場合、UEの特定のディスプレイ上のエンパイアステートビルディングの位置にかかわらず、UEは、ユーザの選択を経度緯度座標にマップすることができる。UE1~3の各々における選択座標を判断した後、UE1~3は各々、450A、455Aおよび460Aで、選択座標を、1つまたは複数の座標パケットに入れて、アプリケーションサーバ170に送信する。図4Aの450A~460Aを参照すると、選択座標を含めることに加え、450A、455Aおよび460Aで送信される1つまたは複数の座標パケットは、それぞれ、435A、440Aおよび445Aからのユーザ入力または選択の再構築を許可し、または容易にするための提示再構築パラメータセットをさらに含み得る。たとえば、UE1~3は各々、通信セッション中に、異なるズームレベルでニューヨーク市の地図を提示中であり得る。この場合、提示再構築パラメータセットは、単に対応するスクリーン位置ではなく、地図に相対した適切な位置での、目標UEにおけるユーザ選択の再構築を許可する。別の例では、UE1は、その座標選択が、変化なしでUE2において提示され得るが、その座標選択が、UE3における所与の視覚表現の閲覧エリアの外であると検出し得る。この検出に応答して、提示再構築パラメータセットは、UE3が、UE1の選択座標の提示を許可するように、地図のその閲覧エリアを調整し、または配向し直すための要求を含み得る。依然として図4Aの450A~460Aを参照すると、別の例では、UE1は、ビデオコンテンツをフルスクリーンで提示中であってよく、UE2は、フルスクリーンではなく、スクリーン表示の小さい部分で、ビデオコンテンツを提示中であり得る。この場合、UE2は、提示再構築パラメータを送ることができ、そうすることによって、ビデオコンテンツに相対して選択座標が小さい部分においてどこに位置決めされたかについての指示とともに、選択座標が伝えられる。したがって、UE2のスクリーンの右下部分は、通信セッションに関連付けられたビデオコンテンツを表示しており、選択座標は、その部分の左上側であると仮定する。この場合、目標UEにおいて再提示されると、提示再構築パラメータは、目標UEに、選択座標を、視覚表現に専用の左上セクションに表示するよう命令することができる。依然として図4Aの450A~460Aを参照すると、別の実施形態では、これらの座標パケット送信のうちの1つまたは複数は、任意選択でよい。たとえば、UE1~3は各々、435A、440Aおよび445Aで、それぞれ、少なくとも1つの座標選択に対応するユーザ入力を受信すると仮定する。ただし、UE1は、その座標選択が、UE2およびまたはUE3における所与の視覚表現の提示と競合すると判断すると仮定する。たとえば、UE1は、その座標選択が、UE2およびまたはUE3における所与の視覚表現の閲覧エリアの外であることを検出し得る。この場合、閲覧エリア調整命令を提示再構築パラメータセットにパッケージ化するのではなく、UE1は、競合検出に応答して、その座標パケットを送るのを控えるだけでよい。別の例では、UE1は、その座標選択を、それぞれの閲覧エリアにかかわらず、UE2およびまたはUE3において表示することができないことを検出し得る。この場合、UE1は、競合検出に応答して、その座標パケットを送るのを控えるだけでよい。依然として図4Aの450A~460Aを参照すると、別の実施形態では、選択座標のうちの1つまたは複数は、競合検出に応答して修正され得る。したがって、UE1~3は各々、435A、440Aおよび445Aで、それぞれ、少なくとも1つの座標選択に対応するユーザ入力を受信すると仮定する。ただし、UE1は、その座標選択が、UE2およびまたはUE3における所与の視覚表現の提示と競合すると判断すると仮定する。たとえば、UE1は、その座標選択が、UE2およびまたはUE3における所与の視覚表現の閲覧エリアの外であることを検出し得る。この場合、閲覧エリア調整命令を提示再構築パラメータセットにパッケージ化し、または座標パケットの送信を完全に回避する代わりに、UE1は、そうではなく、座標選択を修正すればよい。たとえば、UE1のユーザが、UE2およびUE3の閲覧エリアの外の座標位置を選択した場合、選択された座標は、UE2およびUE3の閲覧エリア内の位置に動かしてよい。依然として図4Aの450A~460Aを参照すると、別の実施形態では、450A~460Aの間での、座標パケットのうちの1つまたは複数の送信は、トークスパートとともに送信され得る。本実施形態では、座標パケットは、いくつかのオーバージエア送信を削減するように、トークスパートパケットに組み込み、またはピギーバックすることができる。450A、455Aおよび460Aで座標パケットが送信された後、アプリケーションサーバ170は、所与の座標受信期間内にUE1~3から座標パケットを受信し、465Aで、UE1~3の各々への送信用の出力フレームを生成する。ある例では、上述したように、座標パケットは、トークスパートとともに、アプリケーションサーバ170において受信され得る。465Aの動作については、図7A~図10Bを参照して、後でかなり詳しく論じる。465Aで出力フレームを生成した後、アプリケーションサーバ170は、470A、475Aおよび480Aで、生成出力フレームをUE1~3に送信する。UE1~3への出力フレームの送信は、図4Aでは、IPユニキャスティングプロトコルに従う3つの別々の送信であるものとして示されているが、これらの別々の送信は、IPマルチキャスティングまたはブロードキャスティングプロトコルを介して、同じ、すなわち共通の出力フレームがUE1~3の各々に送信されるイベントに統合され得ることが諒解されよう。アプリケーションサーバ170はまた、485Aで、アーカイブデータベース186内に、UE1~3から受信された座標に関連付けられたセッションデータを記憶またはアーカイブする。アーカイブされたセッションデータは、470A~480Aで目標UEに送られる生成出力フレームに対応し得る。あるいは、アーカイブされたセッションデータは、450A~460Aで受信される未加工座標データに対応し得る。あるいは、アプリケーションサーバ170は、未加工座標データならびに生成出力フレームの両方をアーカイブすることができる。アプリケーションサーバ170は、グループ通信セッションのための、アーカイブされたセッションデータを、図2Bに示すアプリケーションサーバ170に結合されたアーカイブデータベース186に記憶することができ、あるいは、アーカイブデータを、アプリケーションサーバ170においてローカルに記憶することができる。グループ通信セッションのためのセッションデータのアーカイブについては、図11Aおよび図11Bを参照して、以下でより詳しく説明する。図4Aの470A~480Aを参照すると、UE1~3への座標出力フレームの送信に加え、アプリケーションサーバ170は、それぞれ、435A、440Aおよびまたは445Aからのユーザ入力または選択の再構築を許可または容易にするための提示再構築パラメータセットをさらに送信することができる。ある例では、提示再構築パラメータセットは、UE1~3のうちの1つまたは複数から受信され、次いで、単に、アプリケーションサーバ170によって適切な目標UEに転送され得る。別の例では、ソースUEにおいて生成され、次いで、アプリケーションサーバ170に報告されるのではなく、特定のUEの座標選択を再構築するための提示再構築パラメータセットは、アプリケーションサーバ170自体において生成することができる。たとえば、UE1は、その選択座標を報告すればよく、アプリケーションサーバ170は、たとえば、選択座標がUE2の閲覧エリアの外にあると判断すればよく、次いで、それに従って、UE2に向けられた座標出力フレームを調整すればよい。したがって、それぞれのUEにおいて生成される提示再構築パラメータセットに関して上で論じた各例は、代わりに、本実施形態におけるアプリケーションサーバ170に引き継がれ得る。図4Aを参照すると、UE1~3の各々が、アプリケーションサーバ170から出力フレームを受信する。受信した出力フレームに基づいて、UE1~3は各々が、490A、493Aおよび496Aで、それぞれのディスプレイにおけるメディアコンテンツの視覚表現を、受信した出力フレームによって示される他のUEの座標を反映するように更新する。上述したように、出力フレームは、提示再構築パラメータセットとともに、座標のうちの1つまたは複数が、受信側UEにおける視覚表現に対する更新に反映される方法を制御するように構成されたUE1~3において受信され得る。さらに、たとえば、図5Aを参照して上述した仮定を用いると、図5Bは、490A、493Aおよび496Aが実施された後の、UE1~3のディスプレイ上の更新視覚表現の例を示す。図5Bに示すように、何らかのタイプのインジケータが、UE1~3の各々のディスプレイ上のメディアコンテンツの視覚表現に追加されて、UE1~3のそれぞれのユーザに対して、他のユーザによって選択されている当該点を示す。したがって、UE1の視覚表現は、それぞれ、UE2およびUE3によって、選択座標のインジケータなどを示すように更新される。また、図5Bに示すように、点線の円は、各ユーザ自身の座標選択を示す。タッチスクリーン実装形態では、UE1~3のユーザは、選択座標において自分のUEディスプレイに物理的にタッチしており、その結果、このシナリオにおけるそれぞれのユーザの指接触点は、図5Bに示す点線の円に対応することが諒解されよう。点線の円自体は、そうすることによって、それぞれのUEによって実際に表示されるグラフィカルオブジェクトである必要はない。図4Aに明示的には示さないが、目標UEがその視覚表現を、別のUEまたは複数のUEの報告座標選択を反映するように更新済みであるという指示または肯定応答が、報告側UEに返送され得る。したがって、UE1は、UE2およびUE3が、その視覚表現を、UE1の報告座標に基づいて更新済みであるという肯定応答などを受信し得る。図4Bは、本発明のある実施形態による、図4Aのプロセスの続きを示す。図4Bを参照すると、UE1~3の各々は、400B、405Bおよび410Bで、UEのそれぞれのユーザから、それぞれ、UE1~3におけるディスプレイ上の視覚表現の少なくとも1つの座標の別の選択を示す別のユーザ入力を受信する。たとえば、UE1~3のユーザは各々、それぞれのディスプレイ上の視覚表現の特定の点を選択することができ、その点は、図4Aの420A~430Aで選択されたのと同じ点でも異なる点でもよい。図5Cは、メディアコンテンツがニューヨーク市の地図に相当する、図5Aおよび図5Bに続く例において400B、405Bおよび410Bの間にUE1~3のユーザから受信され得るユーザ入力の例を示す。図5Cに示すように、UE1およびUE3のユーザは、地図の異なる位置を選択し、UE2のユーザは、地図の同じ位置を選択する。ある例では、図5Cにおける変化は、UE1およびUE3のユーザが、自分の指を、それぞれのUEのタッチスクリーンディスプレイ上の異なる位置に動かした結果であり得るが、UE2のユーザは、自分の指を動かさない。UE1~3の各々における選択座標を判断した後、UE1~3は各々、415B、420Bおよび425Bで、選択座標パケットを、アプリケーションサーバ170に送信する。アプリケーションサーバ170は、所与の座標受信期間内にUE1~3から座標パケットを受信し、430Bで、UE1~3の各々への送信用の出力フレームを生成する。430Bの動作については、図7A~図10Bを参照して、後でかなり詳しく論じる。430Bで出力フレームを生成した後、アプリケーションサーバ170は、435B、440Bおよび445Bで、生成出力フレームをUE1~3に送信する。UE1~3への出力フレームの送信は、図4Bでは、IPユニキャスティングプロトコルに従う3つの別々の送信であるものとして示されているが、これらの別々の送信は、IPマルチキャスティングまたはブロードキャスティングプロトコルを介して、同じ、すなわち共通の出力フレームがUE1~3の各々に送信されるイベントに統合され得ることが諒解されよう。アプリケーションサーバ170はまた、図4Aの485Aに関して上述したように、450Bで、アーカイブデータベース186内に、UE1~3から受信した座標に関連付けられたセッションデータを記憶またはアーカイブする。グループ通信セッションのためのセッションデータのアーカイブについては、図11Aおよび図11Bを参照して、以下でより詳しく説明する。図4Bを参照すると、UE1~3の各々が、アプリケーションサーバ170から出力フレームを受信する。受信した出力フレームに基づいて、UE1~3は各々が、455B、460Bおよび465Bで、それぞれのディスプレイにおけるメディアコンテンツの視覚表現を、受信した出力フレームによって示される他のUEの座標のいかなる変化も反映するように選択的に更新する。たとえば、図5Cを参照して上述した仮定を用いると、図5Dは、455B、460Bおよび465Bが実施された後の、UE1~3のディスプレイ上の更新視覚表現の例を示す。図5Dに示すように、UE1およびUE3を、UE1~3のディスプレイ上の視覚表現に関連付けて表すのに使われるインジケータは、UE1およびUE3の新たな座標を反映するように動かされる。図5Bでは、点線矢印は、UE1およびUE3のインジケータが、図5Bに示す、より早期の位置からどのように動いたかを指すのに使われる。タッチスクリーン実装形態では、UE1~3のユーザは、選択座標において自分のUEディスプレイに物理的にタッチしており、その結果、このシナリオにおけるそれぞれのユーザの指接触点は、図5Dに示す点線の円に対応することが諒解されよう。そうすることによって、点線の円の位置に関する動きを示す点線矢印は、ある例における、UE1およびUE3のユーザの指の動きを指す。これらの点線矢印は、説明の便宜上与えられているのであって、それぞれのUEにおいて実際に表示されるグラフィカルオブジェクトである必要はないことが諒解されよう。図4Aと同様に、415B、420Bおよびまたは425Bで、それぞれ、UE1~3によって送信される座標パケットのうちの1つもしくは複数、およびまたは435B、440Bおよびまたは445Bで、それぞれ、アプリケーションサーバ170によって送信される座標出力フレームのうちの1つもしくは複数は、提示再構築パラメータセットとともに送られ得る。あるいは、それぞれ、415B、420Bおよびまたは425BでUE1~3によって送信される座標パケットのうちの1つまたは複数、ならびにあるいは435B、440Bおよびまたは、それぞれ、445Bでアプリケーションサーバ170によって送信される座標出力フレームに含まれる座標のうちの1つもしくは複数は、図4Aを参照して上述したように、目標UEにおける競合検出に応答して選択的に省き、または修正することができる。図6は、図4Aおよびまたは図4Bのプロセス中のアプリケーションサーバ170の動作をより詳しく示す。具体的には、図6は、図4Aの450Aと485Aとの間ならびにあるいは図5Bの415Bと450Bとの間のアプリケーションサーバ170の動作を示す。図6を参照すると、図4Aおよびまたは図4Bのグループ通信セッション中に、アプリケーションサーバ170が、座標受信期間内に、座標情報を含む座標パケットを参加UEから受信すると仮定することができる。図8を参照して後で論じるいくつかの例外はあるが、特定の座標受信期間中に受信される座標パケットは、その特定の座標受信期間に、出力フレームセットに投入するのに使われるデータを与える。グループ通信セッションに参加しているUEは、各座標受信期間に、座標パケットを与えることを試みる。言い換えれば、図4AのUE1~3は、送信された座標パケットがアプリケーションサーバ170において同じ座標受信期間内に受信されるように、450A~460Aの送信を同期させることを試みる。したがって、600で、アプリケーションサーバ170は、初期または次の座標受信期間に対する座標受信タイマを始動させる。この点において、座標受信期間の満了期間は、デフォルトまたは初期長にセットされる。次に、アプリケーションサーバ170は、605で、UE1~Nからの座標情報を含む座標パケットを監視する。図4Aおよび図4Bに示すように、605の監視は、450A~460Aおよびまたは415B~425BでのUE1~3からの送信座標の受信と一致し得る。アプリケーションサーバ170は、610で、座標受信タイマが満了しているかどうか判断する。610で、座標受信タイマが満了していないとアプリケーションサーバ170が判断した場合、プロセスは605に戻り、アプリケーションサーバ170は、参加UEからの着信座標パケットを監視し続ける。そうでなければ、610で、座標受信タイマが満了しているとアプリケーションサーバ170が判断した場合、アプリケーションサーバ170は、615で、605の監視中に受信した座標パケットに含まれる座標情報に基づいて、UE1~Nへの送信用の出力フレームを生成する。615の出力フレーム生成は、図4Aの465Aおよびまたは図4Bの430Bに対応し得ることが諒解されよう。さらに、アプリケーションサーバ170が図6の615の間に出力フレームを生成するやり方については、図8~図10Bを参照して、以下でより詳しく説明する。620で、アプリケーションサーバ170は、生成した出力フレームを、IPユニキャスティングおよびまたはIPマルチキャスティングプロトコルにより、UE1~Nに送信する。620の送信は、図4Aの470A~480Aおよびまたは図4Bの435B~445Bに対応し得ることが諒解されよう。625で、アプリケーションサーバ170は、現在の座標受信期間についてのセッションデータをアーカイブする。たとえば、625で、アプリケーションサーバ170は、605の座標受信期間中にUE1~Nからの座標パケットに入れて受信された座標情報を未加工フォーマットで記憶することができ、かつまたは615からの生成出力フレームを記憶することができる。625のアーカイブは、アプリケーションサーバ170における、またはアーカイブデータベース186におけるローカルストレージ内で起こり得る。625で、現在の座標受信期間についてのセッションデータをアーカイブした後、プロセスは600に戻り、ここでアプリケーションサーバ170は、次の座標受信期間に対する座標受信タイマをリスタートする。あるいは、次の座標受信期間に対する座標受信タイマは、次の座標受信期間に対する座標パケットの監視と並行して615~625が実行され得るように、610の後、スタートすればよい。図6には明示的に示さないが、600と610との間のCRT中に受信された座標パケットのうちの1つまたは複数ならびにあるいは620で送信された出力フレームのうちの1つまたは複数は、提示再構築パラメータセットとともに受信およびまたは送信され得る。提示再構築パラメータの例については、図4Aおよび図4Bを参照して上で挙げたので、ここでは簡潔のためにこれ以上は論じない。あるいは、600と610との間のCRT中に受信された1つまたは複数の座標は、615の生成中に、1つまたは複数の出力フレームに関しては選択的に省き、または修正することができる。これらの態様も、後でより詳しく論じる図7A~図7Cに該当する。図7Aから図7Cまでは、それぞれ、図6のプロセスのより詳細な実装例を示す。図7Aを参照すると、図4Aのグループ通信セッションのセットアップ中に、またはそれに先立って、アプリケーションサーバ170は、700Aで、UE1~Nの各々に関連付けられた優先レベルを判断する。後のどこかの時点で、アプリケーションサーバ170は、705Aで、次の座標受信期間に対する座標受信タイマを始動させる。この時点で、座標受信期間の満了期間は、デフォルトまたは初期長にセットされる。次に、アプリケーションサーバ170は、710Aで、UE1~Nからの座標情報を含む座標パケットを監視する。710Aの監視中に、アプリケーションサーバ170は、715Aで、所与の優先度閾値を上回る優先レベルに関連付けられたUE1~Nの各々から少なくとも1つの座標パケットを受信すると仮定する。言い換えれば、715Aで、アプリケーションサーバ170は、各高優先度UEがその座標パケットを現在の座標受信期間に与えていると判断する。したがって、アプリケーションサーバ170は、720Aで、座標受信期間の長さを削減する。言い換えれば、座標受信タイマの満了期間は、打ち切られ、または短縮される。ある例では、720Aは、座標受信期間の即時終了に相当してよく、それにより、720Aの後で座標受信タイマが満了すると言うことができる。あるいは、720Aは、必ずしも座標受信期間の即時終了を起こすわけではない、座標受信タイマの満了期間の切詰めに相当し得る。座標受信期間の短縮は、このように、UE1~Nの各々からの座標パケットが、現在の座標受信期間に対する出力フレームに追加されるべき時間内に、アプリケーションサーバ170に達する機会を減らすことが諒解されよう。ただし、座標受信期間の短縮は、高優先度UEがその座標情報を他の参加UEと共有することができるようになるまでの遅延を減らすことにもなる。アプリケーションサーバ170は、725Aで、座標受信タイマが満了しているかどうか判断する。725Aで、座標受信タイマが満了していないとアプリケーションサーバ170が判断した場合、プロセスは710Aに戻り、アプリケーションサーバ170は、参加UEからの着信座標パケットを監視し続ける。そうでなければ、725Aで、座標受信タイマが満了しているとアプリケーションサーバ170が判断した場合、アプリケーションサーバ170は、730Aで、710Aの監視中に受信した座標パケットに含まれる座標情報に基づいて、UE1~Nへの送信用の出力フレームを生成する。アプリケーションサーバ170が図7Aの730A中に出力フレームを生成するやり方については、図8~図10Bを参照して、以下でより詳しく説明する。次に、735Aおよび740Aは、実質的に、それぞれ図6の615~625に相当するので、簡潔のためにさらに詳細に説明はしない。図7Bを参照すると、図4Aのグループ通信セッションのセットアップ中に、またはそれに先立って、アプリケーションサーバ170は、700Bで、UE1~Nの各々に関連付けられた優先レベルを判断する。後のどこかの時点で、アプリケーションサーバ170は、705Bで、次の座標受信期間に対する座標受信タイマを始動させる。この時点で、座標受信期間の満了期間は、デフォルトまたは初期長にセットされる。次に、アプリケーションサーバ170は、710Bで、UE1~Nからの座標情報を含む座標パケットを監視する。710Bの監視中、715Bで、座標受信タイマが満了に近づいており、どの座標パケットも、所与の優先度閾値を上回る優先レベルに関連付けられたUE1~Nのうち少なくとも1つからはまだ出ていないと、アプリケーションサーバ170が判断すると仮定する。言い換えれば、715Bで、アプリケーションサーバ170は、1つまたは複数の高優先度UEが、現在の座標受信期間に対するその座標パケットをまだ与えていないと判断する。したがって、アプリケーションサーバ170は、720Bで、座標受信期間の長さを増大または延長する。座標受信期間の延長は、このように、UE1~Nからの座標パケットが、現在の座標受信期間に対する出力フレームに追加されるべき時間内に、アプリケーションサーバ170に達する機会を増やすことが諒解されよう。ただし、座標受信期間の延長は、アプリケーションサーバ170によってUE1~Nに出力フレームが送信される前の遅延も増大することになる。アプリケーションサーバ170は、725Bで、座標受信タイマが満了しているかどうか判断する。725Bで、座標受信タイマが満了していないとアプリケーションサーバ170が判断した場合、プロセスは710Bに戻り、アプリケーションサーバ170は、参加UEからの着信座標パケットを監視し続ける。そうでなければ、725Bで、座標受信タイマが満了しているとアプリケーションサーバ170が判断した場合、アプリケーションサーバ170は、730Bで、710Bの監視中に受信した座標パケットに含まれる座標情報に基づいて、UE1~Nへの送信用の出力フレームを生成する。アプリケーションサーバ170が図7Bの730B中に出力フレームを生成するやり方については、図8~図10Bを参照して、以下でより詳しく説明する。次に、735Bおよび740Bは、実質的に、それぞれ図6の620~625に相当するので、簡潔のためにさらに詳細に説明はしない。図7Cを参照すると、図4Aのグループ通信セッションのセットアップ中に、またはそれに先立って、アプリケーションサーバ170は、700Cで、UE1~Nのうちの1つまたは複数に関連付けられたハンディキャップを判断する。たとえば、UE1およびUE2は各々が、比較的高速ネットワークに接続され、そうすることによって、アプリケーションサーバ170との接続に関して、待ち時間が比較的低いと仮定する。対照的に、UE3は、比較的遅いネットワークに接続されると仮定する。この場合、アプリケーションサーバ170は、少なくともUE3にハンディキャップを適用してよく、そうすることによって、UE3の座標パケットがアプリケーションサーバ170に到着するのが遅いケースでは、より多くの時間が、座標受信期間に選択的に割り振られる。代替例では、ハンディキャップは、UE1~Nの中の所与のUEにサービングしているアクセスポイントのパイロット強度に基づいて判断することができる。別の代替例では、ハンディキャップは、UE1~Nの中の所与のUEと、所与のUEにサービングしているアクセスポイントとの間の距離に基づいて判断することができる。別の代替例では、ハンディキャップは、アプリケーションサーバ170への座標パケット到着についての各UEの過去のパフォーマンスに基づいて判断することができる。この場合、通常はそれぞれの座標受信期間内にその座標パケットを比較的遅く与えているUEに、比較的高いハンディキャップを割り振ることができる。図7Cの700Cを参照すると、アプリケーションサーバ170が特定のUEについて座標受信期間を延長する度合は、ハンディキャップの規模に、また、二次的考察に基づき得る。UE1~Nのうちの1つまたは複数についてハンディキャップが判断された後のどこかの時点で、アプリケーションサーバ170は、705Cで、グループ通信セッション中の次の座標受信期間に対する座標受信タイマを始動させる。この時点で、座標受信期間の満了期間は、デフォルトまたは初期長にセットされる。次に、アプリケーションサーバ170は、710Cで、UE1~Nからの座標情報を含む座標パケットを監視する。710Cの監視中、715Cで、座標受信タイマが満了に近づいており、どの座標パケットも、700Cからのハンディキャップに関連付けられたUE1~Nのうち少なくとも1つからはまだ出ていないと、アプリケーションサーバ170が判断すると仮定する。言い換えれば、715Cで、アプリケーションサーバ170は、1つまたは複数のハンディキャップ付きUEが、現在の座標受信期間に対するその座標パケットをまだ与えていないと判断する。したがって、アプリケーションサーバ170は、720Cで、座標受信期間の長さを増大または延長する。座標受信期間の延長は、このように、UE1~Nからの座標パケットが、現在の座標受信期間に対する出力フレームに追加されるべき時間内に、アプリケーションサーバ170に達する機会を増やすことが諒解されよう。ただし、座標受信期間の延長は、アプリケーションサーバ170によってUE1~Nに出力フレームが送信される前の遅延も増大することになる。アプリケーションサーバ170は、725Cで、座標受信タイマが満了しているかどうか判断する。725Cで、座標受信タイマが満了していないとアプリケーションサーバ170が判断した場合、プロセスは710Cに戻り、アプリケーションサーバ170は、参加UEからの着信座標パケットを監視し続ける。そうでなければ、725Cで、座標受信タイマが満了しているとアプリケーションサーバ170が判断した場合、アプリケーションサーバ170は、730Cで、710Cの監視中に受信した座標パケットに含まれる座標情報に基づいて、UE1~Nへの送信用の出力フレームを生成する。アプリケーションサーバ170が図7Cの730C中に出力フレームを生成するやり方については、図8~図10Bを参照して、以下でより詳しく説明する。次に、735Cおよび740Cは、実質的に、それぞれ図6の620~625に相当するので、簡潔のためにさらに詳細に説明はしない。図7A、図7Bおよび図7Cは、座標受信期間が、1つまたは複数のUEに関連付けられた優先度およびまたはハンディキャップに基づいて延長または短縮される例を示すが、これらの実施形態は、別の実施形態では連携して実装してもよいことが諒解されよう。したがって、座標受信期間は、図7Bの実施形態に基づいて延長し、次いで、図7Cの実施形態に基づいてさらに延長してもよい。あるいは、座標受信期間は、図7Aの実施形態に基づいて短縮してもよく、次いで、同じ座標受信期間は、図7Cの実施形態に基づいて延長してもよい。所与のグループ通信セッションの1つまたは複数の座標受信期間に、アプリケーションサーバ170において出力フレームを生成する例示的実装形態について、図8~図10Bを参照して次に説明する。具体的には、図8の全体が、図6の615の例示的な一実装形態に対応する。図9A~図10Bは、例示的実施形態による、図8のプロセス中に起こり得るデータ操作の例を示す。図8を参照して、1組のUE1~5の間でのグループ通信セッション中に、4つの重ならない期間T1~T4が経過し、ここでT1は、T2と比較して、時間的により早く、T2は、T3と比較して、時間的により早く、以下同様であると仮定する。図8を説明する目的で、期間T1~T4中の、UE1~5における選択座標が、図9Aに示すテーブルに対応するとさらに仮定され得る。たとえば、T1で、UE1のユーザは、座標に対応する位置で、UE1のディスプレイにタッチしており、UE2のユーザは、座標に対応する位置で、UE2のディスプレイにタッチしており、以下同様である。さらに、T2で、UE2が所与の非同期イベントを検出すると同時に、UE4が、座標に対応する位置を選択しているものとして示されている。いくつかの理由により、図9Aのテーブルに示す初期座標選択に基づいて、アプリケーションサーバ170において受信された座標パケットは、必ずしも完璧に同期されるわけではないことが諒解されよう。たとえば、UE1~5のうち異なるものを、異なる待ち時間をもつネットワークに接続することなどができる。したがって、図9B~図9Dは、それぞれ、T1、T2およびT3に対応する座標受信期間中にアプリケーションサーバ170において受信された座標パケットの例を示すテーブルを示す。図9B~図9Dにおいて、それぞれのテーブルのより低いセル中に示される座標は、座標受信期間中に比較的早く受信された座標パケットを表し、それぞれのテーブルのより高いセル中に示される座標は、座標受信期間中に比較的後で受信された座標パケットを表す。図9B~図9Dには明示的に示さないが、図に示す座標受信期間のうちどの期間の持続時間も、図7A~図7Cのうちの1つまたは複数の図の実施形態によって延長およびまたは短縮されている可能性がある。図9Bを参照すると、T1に対応する座標受信期間中に、座標の選択を含む、UE3の座標パケットが、消去として列挙される。これは、UE3が、その座標に、特定の座標受信期間中に更新を与えることができなかったことを意味する。また、図9Cを参照すると、T2に対応する座標受信期間中に、座標の選択を含む、UE4の座標パケットが、非同期指示と関連付けて列挙される。さらに、図9Dを参照すると、T3に対応する座標受信期間中に、UE3は、座標との両方の選択を含む2つの別々の座標パケットを与えるものとして示されており、に対応する座標パケットは、に対応する座標パケットの前に受信されている。図9Aの検討から、座標パケットは、T3ではなくT4についての座標受信期間に関連付けられたことが意図されていたことが諒解されよう。言い換えれば、座標に対応する、UEの座標パケットは、早く受信された。アプリケーションサーバ170が、消去パケット、非同期座標パケットおよびまたは早期座標パケットを扱うように構成され得る方法の例については、図8を参照して後でより詳しく論じる。図8を参照すると、アプリケーションサーバ170は、所与の座標受信期間中に受信した座標パケットを評価し、800で、UE1~Nのいずれかから複数の座標パケットが受信されたかどうか判断する。図8の実施形態では、参加UEごとにただ1つの座標パケットが期待されると仮定される。ただし、他の実施形態は、単一の座標受信期間中に複数の相異なる座標が選択され得るシナリオを対象とし得ることが諒解されよう。マルチ座標シナリオでは、図8の800が、特定の座標受信期間に関して重複座標選択が受信されているかどうか評価するように、相異なる各座標選択を別々に検討してよい。図8の800で、特定のUEについて複数の座標パケットが受信されたとアプリケーションサーバ170が判断した場合、アプリケーションサーバ170は、複数の座標パケットのうちの1つまたは複数が、早期パケットに対応すると推論する。図9Aは、座標がT4まで、アプリケーションサーバ170において受信済みであるはずがないことを示すので、図9Dにおいて、座標に対応するUE3からの座標パケットは、早期パケットである。したがって、どの座標パケットが早期パケットであるか判断した後、アプリケーションサーバ170は、805で、現在の座標受信期間に関して出力フレームから早期パケットが除外されるように、早期パケットをドロップする。図8には明示的に示さないが、アプリケーションサーバ170は、任意選択で、ドロップした座標パケットを、次の座標受信期間にプッシュすることができ、そうすることによってアプリケーションサーバ170は、図8のプロセスの次の実行中に、ドロップした早期パケットからの座標を追加するかどうか検討することができる。図8を参照すると、アプリケーションサーバ170は、810で、いずれかの消去パケットが、現在の座標受信期間または以前の座標受信期間中に受信されているかどうか判断する。以前の座標受信期間中に消去パケットが受信されたとアプリケーションサーバ170が判断した場合、アプリケーションサーバ170は、消去パケットに含まれる座標を、現在の座標受信期間用の出力フレームに挿入すると決断し、それによって、これらの座標は以前の出力フレームで送信済みであるはずなので、815で、挿入される座標には、置換座標状況を示すようにフラグが立てられる。また、現在の座標受信期間中に消去パケットが受信されたとアプリケーションサーバ170が判断した場合、アプリケーションサーバ170は、815で、出力フレームの目標UEが、次の座標受信期間用の出力フレーム中の置換座標を予想するための告知に載せられるように、消去インジケータを、現在の座標受信期間用の出力フレームに挿入すると決断する。図8を参照すると、820で、アプリケーションサーバ170は、現在の座標受信期間中に、UE1~Nのうちの1つまたは複数によっていずれかの非同期イベントが報告されたかどうか判断する。非同期イベントは、座標選択とは別個の、グループ通信セッションに参加しているUEのうちの1つのUEの所与のユーザによって行われたアクションに対応する。非同期イベントの報告は、それにより、座標パケットに含まれる座標情報に関して、別個または追加データに対応するが、同じ座標パケット内で非同期イベントが報告され得ることが可能である。一例として、グループ通信セッションは、何らかのタイプの格闘ゲームに対応すると仮定する。次いで、図9AのT2で、UE4のユーザは、座標を選択し、同時に格闘アクションを選択するという、両方を行うと仮定する。この場合、座標は上述したように報告され、この座標は、関連アクションの指示とともに与えられる。この具体例において、T2においてUE4からアプリケーションサーバ170に報告される非同期情報は、格闘アクションのタイプ、使われる武器のタイプ、およびまたは他のどの関連情報も含み得る。さらに、非同期イベントおよび座標が同じ座標受信期間中に報告されるときでも、非同期イベントは、座標に直接関連する必要はない。たとえば、非同期イベントは、たとえば、呪文を唱えている、所与のUEのユーザに対応してよく、その間、ユーザは、ディスプレイ上の所与の座標位置を単独で操作している。さらに別の例では、非同期イベントは、非同期イベントのタイミングがUEにおける現在の座標選択に密接に結合され得るように、待ち時間制約のある状況において使うことができる。したがって、ゲームセッションにおいて目標に銃を発砲しているユーザは、自分の目標を正確に撃つために、非同期イベントと、結合されるべき座標の両方を必要とする。図8には示さないが、時間制約の少ない非同期イベントは、帯域外シグナリングにより、またはアプリケーションサーバ170における座標受信期間との同期を外れて送られ得る。現在の座標受信期間中に非同期パケットが受信されたとアプリケーションサーバ170が判断した場合、アプリケーションサーバ170は、非同期パケットに含まれる座標を、現在の座標受信期間用の出力フレームに挿入すると決断し、それによって、825で、挿入される座標には、非同期イベントを示すようにフラグが立てられる。830で、アプリケーションサーバ170は、IPマルチキャスティングプロトコルにより、それともIPユニキャスティングプロトコルにより出力フレームを目標UEに送信するか判断する。たとえば、目標UEのうち多数が地理的に同じ場所に置かれている場合、アプリケーションサーバ170は、830で、IPマルチキャスティングプロトコルにより送信すると判断し、アプリケーションサーバ170は、835で、目標UEへの送信用の共通出力フレームを生成する。図10Aは、図8のプロセスの実行後の、図9A~図9Dを参照して上で提示した仮定に基づいて、T1~T3に対応する座標受信期間に対する、UE1~5の各々に送信されるべき共通出力フレームを示す。目標UEの一部は、図10Aの実施形態において、それ自体が報告した座標を受信することが諒解されよう。たとえば、UE1は、という、それ自体が報告した座標を、T1に対応する出力フレーム中に受信する。目標UEは、ある例では、835のIPマルチキャスティング実装に従って受信された、どの出力フレームからのそれ自体の座標も無視してよいことが諒解されよう。あるいは、目標UEが地理的に同じ場所に置かれていない場合、アプリケーションサーバ170は、830で、IPユニキャスティングプロトコルにより送信すると判断し、アプリケーションサーバ170は、840で、目標UEへの送信用の複数のUE固有出力フレームを生成する。図10Bは、図8のプロセスの実行後の、図9A~図9Dを参照して上で提示した仮定に基づいて、T1~T3に対応する座標受信期間に対する、UE1~5の各々に送信されるべき複数の出力フレームを示す。図10Bに示すように、840の間、アプリケーションサーバ170は、目標UE自体が報告した座標を、その特定の目標UE用に生成された出力フレームから除外することができる。当業者には諒解されるように、図4Aの485A、図4Bの450Bおよびまたは図6の625を参照して上述した、セッションデータのアーカイブに対する1つの潜在的利益は、終了グループ通信セッションおよびまたはアクティブグループ通信セッションの以前の部分をリプレイする機会がユーザに与えられ得ることである。セッションデータをリプレイするようにUEが構成され得る様々なシナリオの例については、図11Aおよび図11Bを参照して後で説明する。図11Aを参照すると、1100Aで、図4Bの465Bの後の何らかの時点において、UE1~3の間でのグループ通信セッションが終了されると仮定する。後のどこかの時点において、UE1は、そのユーザから、1105Aで、1100Aで終了されたグループ通信セッションをリプレイするための要求を受信する。UE1は、1110Aで、アプリケーションサーバ170にセッションリプレイ要求を送信する。UE1は、1115Aで、終了グループ通信セッションに関連付けられた、メディアコンテンツの初期視覚表現を表示する。たとえば、UE1は、1115Aで、表示されるメディアコンテンツを、リプレイセッションのセットアップ中にアプリケーションサーバ170から受信することができ、あるいは、UE1は、メディアコンテンツを有して事前構成することができ、このメディアコンテンツを、アプリケーションサーバ170がアーカイブされたセッションデータを準備している間にロードすることができる。アプリケーションサーバ170は、1120Aで、アーカイブデータベース186から、アーカイブされたセッションデータをロードする。上述したように、アーカイブされたセッションデータは、終了グループ通信セッション中にUEに送信された生成出力フレーム、およびまたは終了グループ通信セッション中にUEから受信され、出力フレームを生成するのに使われた未加工座標データを含み得る。アプリケーションサーバ170が、未加工座標データのみをアーカイブした場合、アプリケーションサーバ170は、1125Aで、終了グループ通信セッションの第1の座標受信期間に対する、UE1向けの出力フレームを再生成する。あるいは、アプリケーションサーバ170が、終了グループ通信セッション用の生成出力フレームをアーカイブした場合、1125Aの再生成はスキップしてよく、アーカイブされた出力フレームを使えばよい。いずれのケースでも、終了グループ通信セッションの第1の座標受信期間に対応する、UE1向けの出力フレームは、1130Aで、アプリケーションサーバ170によってUE1に送られる。1130Aでの受信出力フレームに基づいて、UE1は、1135Aで、そのディスプレイにおけるメディアコンテンツの視覚表現を、受信出力フレームによって示される他のUEの座標を反映するように選択的に更新する。終了グループ通信セッションの第2の座標受信期間に対応する、UE1向けの次の出力フレームは、1140Aで、アプリケーションサーバ170によってUE1に送られる。1140Aでの受信出力フレームに基づいて、UE1は、1145Aで、そのディスプレイにおけるメディアコンテンツの視覚表現を、受信出力フレームによって示される他のUEの座標におけるいかなる変更も反映するように選択的に更新する。次いで、1140Aおよび1145Aは、終了グループ通信セッションの持続期間だけ、およびまたはUE1のユーザがリプレイセッションを停止すると判断するまで、繰り返し得る。図11Aには示さないが、図11Aのリプレイセッションは、他のアクティブ参加者を伴うリアルタイムのセッションではないので、UE1のユーザは、リプレイセッションを可変速度で再生することができる。たとえば、UE1のユーザは、アプリケーションサーバ170が、リプレイセッションを、元来はUE1のユーザの嗜好に基づいて起こった終了グループ通信セッションよりゆっくりと、同じ速度で、またはより速く再生することを要求することができる。また、図11Aは、以前終了されたグループ通信セッションのリプレイを対象とするが、図11Bは、新規UEがアクティブグループ通信セッションに遅れて加わり、新規参入者が逃してしまったグループ通信セッションのより早期の部分をリプレイすることによって他のUEにキャッチアップすると決定する例を対象とする。図11Bを参照すると、図4Bの465Bの後の何らかの時点において、1100Bで、所与のUEがグループ通信セッションに加わると判断したとき、グループ通信セッションが進行中またはアクティブであると仮定する。この時点で、UEXのユーザには、1105Bで、UEXのユーザが逃した、グループ通信セッションのより早期の部分を単に無視するかどうか、またはグループ通信セッションのより早期の部分をリプレイするかどうかについての選択肢が与えられる。1105Bで、UEXのユーザが逃した、グループ通信セッションのより早期の部分を無視するとUEXのユーザが判断した場合、プロセスは、直接1150Bに進み、UEXは、グループ通信セッションへのアクティブ参加を始める。あるいは、UEXのユーザが、1105Bで、グループ通信セッションのより早期の部分をリプレイすると判断した場合、UEXは、1110Bで、キャッチアップモードでグループ通信セッションに加わるための要求を送信し、それによって、グループ通信セッションのより早期の部分が、UE1~3にUEXがキャッチアップするまでUEXに対して高速でリプレイされる。UEXは、1115Bで、終了グループ通信セッションに関連付けられた、メディアコンテンツの初期視覚表現を表示することによって、リプレイセッションを開始する。たとえば、UEXは、1115Bで、表示されるメディアコンテンツを、キャッチアップセッションのセットアップ中にアプリケーションサーバ170から受信することができ、あるいは、UEXは、メディアコンテンツを有して事前構成することができ、このメディアコンテンツを、アプリケーションサーバ170がキャッチアップセッション用のアーカイブセッションデータを準備している間にロードすることができる。アプリケーションサーバ170は、1120Bで、アーカイブデータベース186から、アーカイブされたセッションデータをロードする。上述したように、アーカイブされたセッションデータは、終了グループ通信セッション中にUEに送信された生成出力フレーム、およびまたは終了グループ通信セッション中にUEから受信され、出力フレームを生成するのに使われた未加工座標データを含み得る。アプリケーションサーバ170が、未加工座標データのみをアーカイブした場合、アプリケーションサーバ170は、1125Bで、終了グループ通信セッションの第1の座標受信期間に対する、UEXのための出力フレームを再生成する。あるいは、アプリケーションサーバ170が、終了グループ通信セッション用の生成出力フレームをアーカイブした場合、1125Bの再生成は、可能性としてはスキップしてもよく、アーカイブされた出力フレームを使えばよい。1125Bで再生成された出力フレームが、IPユニキャスティングプロトコルにより、より早期にUE1~3に送信される場合、これらのフレームは、より早期の送信に関連付けられた、その目標UEを省いている可能性があることが諒解されよう。ただし、UEXに送られる出力フレームは、UE1~3の各々からの座標を含む。また、1125Bで再生成された出力フレームが、IPマルチキャスティングプロトコルにより、UE1~3により早期に送信された場合、これらのフレームは、IPユニキャスティングプロトコルによりUEXに送信され得ることが諒解されよう。いずれのケースでも、アクティブグループ通信セッションの第1の座標受信期間に対応する、UEX向けの出力フレームは、1130Bで、アプリケーションサーバ170によってUEXに送られる。1130Bでの受信出力フレームに基づいて、UEXは、1135Bで、そのディスプレイにおけるメディアコンテンツの視覚表現を、受信出力フレームによって示される他のUEの座標を反映するように選択的に更新する。この点において、1130Bおよび1135Bは、リアルタイムよりも高いレートで繰り返し、その結果UEXは、UE1~3に時間内にキャッチアップする間に、グループ通信セッションのアーカイブ部分を閲覧する。UEXがリアルタイムの状況に近づくと、アプリケーションサーバ170は、1140Bで、UEXをキャッチアップモードから、およびアクティブモードに遷移させると判断し、アクティブモードでは、UEXは、それ自体の座標を、グループへの送信用にアプリケーションサーバ170に送ることを許可される。この時点で、アプリケーションサーバ170は、1145Bで、UEXに、キャッチアップモードから、およびアクティブモードへのその遷移を通知し、UEXは、1150Bで、UEXにおけるディスプレイ上の視覚表現の少なくとも1つの座標の選択を示す、UEXのユーザからのユーザ入力の受諾を始める。図11Bには明示的に示さないが、座標選択は、UE1~3においても起こる。UE1~3およびUEXの各々における選択座標を判断した後、UE1~3およびUEXは、各々、1155B、1160B、1165Bおよび1170Bで、選択座標をアプリケーションサーバ170に送信する。アプリケーションサーバ170は、所与の座標受信期間内にUE1~3およびUEXから座標を受信し、1175Bで、UE1~3およびUEXの各々への送信用の出力フレームを生成する。1175Bで出力フレームを生成した後、アプリケーションサーバ170は、1180Bで、生成した出力フレームをUEXに送信する。図11Bに明示的に示さないが、アプリケーションサーバ170は、出力フレームをUE1~3に送ってもよい。また、UEXは、現在またはUE1~3と同時期のセッションにはないので、1180BでのUEXへの出力フレームの送信は、通常レートで起こる。さらに、図11Bは、グループ通信セッションへの遅れた参加者が、アプリケーションサーバ170による早送り型動作に基づいて、他の参加UEにキャッチアップするのを許可されるための実装形態を対象とするが、図11Bは、UEXが、1100Bに先立って、すでにグループ通信セッションへの参加者であったシナリオにも同様に適用され得ることが諒解されよう。たとえば、UEXが、図4Bのプロセス中に、グループ通信セッションへの別の参加UEであったと仮定する。次いで、後のどこかの時点で、UEXは、アプリケーションサーバ170への接続を失う。たとえば、UEXなどのUEが、アプリケーションサーバ170から切断されることは、UEが、閾値期間だけ座標パケットを与えていないことを意味する。この場合、1100Bの判断は、UEXがアプリケーションサーバ170への接続を回復した後、グループ通信セッションに再度加わるという判断に対応し得る。この時点で、アプリケーションサーバ170は、UE3がその切断期間中に逃したグループ通信セッション部分を、早送りまたはキャッチアップモードなどでリプレイし始めてよい。したがって、図11Bのキャッチアップモード例は、グループ通信セッションへの新規または遅れた参加者に適用可能であるだけではなく、むしろ、グループ通信セッションの一部または全部を逃した可能性があるどのUEにも適用可能である。さらに、上で論じた切断シナリオは、グループ通信セッションが、切断UEからの参加なしで続くと仮定する。ただし、別の実施形態では、UEの切断により、グループ通信セッション自体が破棄され得る。たとえば、グループ通信セッションがチームゲームセッションに対応する場合、プレーヤがいなくなった結果、いなくなったプレーヤが再度加わることができるようになるまでゲームが中断されるような、不公平なゲームになり得る。一定の閾値期間だけ、または一定の閾値数の座標受信期間だけ座標パケットを与えるのに失敗した後、UEが切断されると見なされるように、タイマを使えばよいであろう。すべてのグループ通信セッションがフル参加を必要とするわけではないこと、およびまたは、1つもしくは複数のUEが切断されたときであってもセッションが続くことも許可され得るように、切断UEがセッションに対して低い優先度をもってもよいことも諒解されたい。図11Aまたは図11Bには明示的に示さないが、図11Bの1155Bと1170Bとの間のCRT中に受信される座標パケットのうちの1つまたは複数ならびにあるいは図11Aの1130Aおよびまたは1140Aあるいは図11Bの1130Bおよびまたは1180Bで送信される出力フレームのうちの1つまたは複数は、提示再構築パラメータセットとともに受信およびまたは送信され得る。提示再構築パラメータの例については、図4Aおよび図4Bを参照して上で挙げたので、ここでは簡潔のためにこれ以上は論じない。あるいは、1155Bと1170Bとの間のCRT中に受信される1つまたは複数の座標は、1180Bで送信される1つまたは複数の出力フレームに関しては選択的に省き、または修正することができる。本発明の上述の実施形態は、通信セッションを調停し、座標パケットの交換を仲介するものとして、アプリケーションサーバ170を開示するが、本発明の他の実施形態は、UEホスト型またはUE調停型座標共有セッションを対象とし得る。本実施形態では、セッションを調停するUEはサーバとして作用し、図6~図8のプロセスは、アプリケーションサーバ170ではなくUEサーバによって実装される。本実施形態では、図4Aにあるアプリケーションサーバ170の機能性は、たとえば、図4Aに示す例からのいくつかの実装変化を結果的に生じる座標共有に参加しているUEのうちの1つに移される。同様の変化が、当業者には理解されるように、UEサーバ実装にも対応するように、他の実施形態を通して実装され得る。図12は、機能性を実施するように構成された論理を含む通信デバイス1200を示す。通信デバイス1200は、UE102、108、110、112または200、ノードBまたは基地局1244、RNCまたは基地局コントローラ122、パケットデータネットワークエンドポイントにおけるSGSN160、GGSN165、移動管理エンティティなど、サーバ170~186のうちいずれかなどを含むがそれに限定されない、上述の通信デバイスのいずれにも対応し得る。したがって、通信デバイス1200は、ネットワークを介して1つまたは複数の他のエンティティと通信するように構成されたどの電子デバイスにも対応し得る。図12を参照すると、通信デバイス1200は、情報を受信およびまたは送信するように構成された論理1205を含む。ある例では、通信デバイス1200が、ワイヤレス通信デバイスに対応する場合、情報を受信およびまたは送信するように構成された論理1205は、ワイヤレストランシーバおよび関連ハードウェアなどのワイヤレス通信インターフェースを含み得る。別の例では、情報を受信およびまたは送信するように構成された論理1205は、ワイヤード通信インターフェース接続などに対応し得る。したがって、通信デバイス1200が、何らかのタイプのネットワークベースのサーバに対応する場合、情報を受信およびまたは送信するように構成された論理1205は、ある例では、イーサネットプロトコルによりネットワークベースのサーバを他の通信エンティティに接続するイーサネットカードに対応し得る。さらに別の例では、情報を受信およびまたは送信するように構成された論理1205は、通信デバイス1200がそのローカル環境を監視し得るための知覚または測定ハードウェアを含み得る。情報を受信およびまたは送信するように構成された論理1205は、実行されると、その受信およびまたは送信機能を実施するための、情報を受信およびまたは送信するように構成された論理1205の関連ハードウェアを許可するソフトウェアも含み得る。ただし、情報を受信およびまたは送信するように構成された論理1205は、ソフトウェア単体に対応するのではなく、情報を受信およびまたは送信するように構成された論理1205は、その機能性を遂行するためのハードウェアに少なくとも部分的に依拠する。図12を参照すると、通信デバイス1200は、情報を処理するように構成された論理1210をさらに含む。ある例では、情報を処理するように構成された論理1210は、少なくともプロセッサを含み得る。情報を処理するように構成された論理1210によって実施することができる処理タイプの例示的実装形態は、判断を実施すること、接続を確立すること、異なる情報選択肢の間での選択を行うこと、データに関連した評価を実施すること、測定動作を実施するための、通信デバイス1200に結合されたセンサと対話すること、ある形式から別の形式に情報をコンバートすることなどを含むが、それに限定されない。たとえば、情報を処理するように構成された論理1210に含まれるプロセッサは、汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイまたは他のプログラマブル論理デバイス、個別ゲートまたはトランジスタ論理、個別ハードウェア構成要素、あるいは本明細書で説明する機能を実行するように設計されたそれらの任意の組合せに相当し得る。汎用プロセッサはマイクロプロセッサであり得るが、別法として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。情報を処理するように構成された論理1210は、実行されると、その処理機能を実施するための、情報を処理するように構成された論理1210の関連ハードウェアを許可するソフトウェアも含み得る。ただし、情報を処理するように構成された論理1210は、ソフトウェア単体に対応するのではなく、情報を処理するように構成された論理1210は、その機能性を遂行するためのハードウェアに少なくとも部分的に依拠する。図12を参照すると、通信デバイス1200は、情報を記憶するように構成された論理1215をさらに含む。ある例では、情報を記憶するように構成された論理1215は、少なくとも非一時的メモリおよび関連ハードウェアを含み得る。たとえば、情報を記憶するように構成された論理1215に含まれる非一時的メモリは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CDROM、または当技術分野で知られている任意の他の形態の記憶媒体中に相当し得る。情報を記憶するように構成された論理1215は、実行されると、その記憶機能を実施するための、情報を記憶するように構成された論理1215の関連ハードウェアを許可するソフトウェアも含み得る。ただし、情報を記憶するように構成された論理1215は、ソフトウェア単体に対応するのではなく、情報を記憶するように構成された論理1215は、その機能性を遂行するためのハードウェアに少なくとも部分的に依拠する。図12を参照すると、通信デバイス1200はさらに、情報を提示するように構成された論理1220を任意選択で含む。ある例では、情報を提示するように構成された論理1220は、少なくとも出力デバイスおよび関連ハードウェアを含み得る。たとえば、出力デバイスは、ビデオ出力デバイスなどのビデオ情報を搬送することができるポートなど、オーディオ出力デバイスなど、振動デバイスならびにあるいは情報を出力用にフォーマットし、または通信デバイス1200のユーザもしくはオペレータによって実際に出力し得るための他のどのデバイスも含み得る。たとえば、通信デバイス1200が、図3に示すようなUE200に対応する場合、情報を提示するように構成された論理1220は、ディスプレイ224を含み得る。さらに別の例では、情報を提示するように構成された論理1220は、ローカルユーザをもたないネットワーク通信デバイスなど、いくつかの通信デバイスに関しては省いてもよい。情報を提示するように構成された論理1220は、実行されると、その提示機能を実施するための、情報を提示するように構成された論理1220の関連ハードウェアを許可するソフトウェアも含み得る。ただし、情報を提示するように構成された論理1220は、ソフトウェア単体に対応するのではなく、情報を提示するように構成された論理1220は、その機能性を遂行するためのハードウェアに少なくとも部分的に依拠する。図12を参照すると、通信デバイス1200はさらに、ローカルユーザ入力を受信するように構成された論理1225を任意選択で含む。ある例では、ローカルユーザ入力を受信するように構成された論理1225は、少なくともユーザ入力デバイスおよび関連ハードウェアを含み得る。たとえば、ユーザ入力デバイスは、ボタン、タッチスクリーン表示、キーボード、カメラ、オーディオ入力デバイス、およびまたは通信デバイス1200のユーザまたはオペレータから情報を受信し得るための他のどのデバイスも含み得る。たとえば、通信デバイス1200が、図3に示すようなUE200に対応する場合、ローカルユーザ入力を受信するように構成された論理1225は、ディスプレイ224、キーパッド226などを含み得る。さらに別の例では、ローカルユーザ入力を受信するように構成された論理1225は、ローカルユーザをもたないネットワーク通信デバイスなど、いくつかの通信デバイスに関しては省いてもよい。ローカルユーザ入力を受信するように構成された論理1225は、実行されると、その入力受信機能を実施するための、ローカルユーザ入力を受信するように構成された論理1225の関連ハードウェアを許可するソフトウェアも含み得る。ただし、ローカルユーザ入力を受信するように構成された論理1225は、ソフトウェア単体に対応するのではなく、ローカルユーザ入力を受信するように構成された論理1225は、その機能性を遂行するためのハードウェアに少なくとも部分的に依拠する。図12を参照すると、1205~1225の構成された論理は、図12では別個または相異なるブロックとして示されているが、それぞれの構成された論理がその機能性を実施するためのハードウェアおよびまたはソフトウェアは、部分的に重複し得ることが諒解されよう。たとえば、1205~1225の構成された論理の機能性を容易にするのに使われるどのソフトウェアも、情報を記憶するように構成された論理1215に関連付けられた非一時的メモリに記憶することができ、そうすることによって、1205~1225の構成された論理は各々、その機能性を、情報を記憶するように構成された論理1205によって記憶されたソフトウェアの動作に部分的に基づいて実施する。同様に、構成された論理のうちの1つに直接関連付けられたハードウェアは、他の構成された論理によって時々借り、または使うことができる。たとえば、情報を処理するように構成された論理1210のプロセッサは、データを、情報を受信およびまたは送信するように構成された論理1205によって送信される前に、適切な形式にフォーマットすることができ、そうすることによって、情報を受信およびまたは送信するように構成された論理1205は、その機能性を、情報を処理するように構成された論理1210に関連付けられたハードウェアの動作に部分的に基づいて実施する。さらに、1205~1225の構成された論理またはように構成された論理は、特定の論理ゲートまたは要素に限定されるのではなく、概して、本明細書に記載した機能性を、実施するための能力を指す。したがって、1205~1225の構成された論理またはように構成された論理は、論理という言葉を共有するにもかかわらず、必ずしも論理ゲートまたは論理要素として実装されるわけではない。構成された論理1205~1225の間の他の対話または協働が、後でより詳しく説明する実施形態の検討から、当業者には明らかになるであろう。本発明の上記で説明した実施形態における参照は、全体的に、呼およびセッションの用語を互換的に使用しているが、任意の呼およびまたはセッションは、異なる当事者間の実際の呼を含むものとして、または技術的に呼とみなされない可能性があるデータトランスポートセッションの代わりとして解釈されるものとすることを理解されよう。また、上記実施形態は、全体的に、PTTセッションに関して説明されているが、他の実施形態は、たとえばプッシュツートランスファーセッション、緊急VoIP呼など、任意のタイプの通信セッションを対象としてもよい。情報および信号は、多種多様な技術および技法のいずれかを使用して表すことができることを当業者は諒解されよう。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界または磁性粒子、光場または光学粒子、あるいはそれらの任意の組合せによって表され得る。さらに、本明細書で開示した実施形態に関連して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装できることを、当業者は諒解されよう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを、上記では概してそれらの機能に関して説明した。そのような機能をハードウェアとして実装するか、ソフトウェアとして実装するかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装することができるが、そのような実装の決定は、本発明の範囲からの逸脱を生じるものと解釈すべきではない。本明細書で開示する実施形態に関して説明する様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタルシグナルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイもしくは他のプログラマブル論理デバイス、ディスクリートゲートもしくはトランジスタ論理、ディスクリートのハードウェアコンポーネント、または、本明細書で説明する機能を実行するように設計されたそれらの任意の組合せで、実装または実行することができる。汎用プロセッサはマイクロプロセッサであり得るが、別法として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。本明細書で開示した実施形態と関連して説明した方法、シーケンス、およびまたはアルゴリズムは、ハードウェアで直接実施され得るか、プロセッサによって実行されるソフトウェアモジュールで実施され得るか、またはその2つの組合せで実施され得る。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CDROM、または当技術分野で知られている任意の他の形態の記憶媒体中に常駐し得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。あるいは、記憶媒体はプロセッサと一体であり得る。プロセッサおよび記憶媒体はASIC中に常駐し得る。ASICはユーザ端末中に常駐し得る。あるいは、プロセッサおよび記憶媒体は、ユーザ端末中に個別構成要素として常駐し得る。1つまたは複数の例示的な実施形態では、説明した機能はハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装した場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体とコンピュータ通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CDROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または、命令もしくはデータ構造の形態の所望のプログラムコードを搬送または記憶するために使用でき、コンピュータによってアクセスできる、任意の他の媒体を含み得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線、または、赤外線、無線、およびマイクロ波などのワイヤレス技術を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または、赤外線、無線、およびマイクロ波などのワイヤレス技術は媒体の定義内に含まれる。本明細書で使用する場合、ディスクおよびディスクは、コンパクトディスク、レーザディスク、光ディスク、デジタル多用途ディスク、フレキシブルディスク、およびブルーレイディスクを含み、ディスクは、通常、磁気的にデータを再生し、ディスクは、レーザで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。上記の開示は本発明の例示的な実施形態を示すが、添付の特許請求の範囲によって規定される本発明の範囲から逸脱することなく、本明細書において様々な変更および修正を行えることに留意されたい。本明細書で説明した本発明の実施形態による方法クレームの機能、ステップおよびまたはアクションは、特定の順序で実行されなくてもよい。さらに、本発明の要素は、単数形で説明または特許請求されていることがあるが、単数形に限定することが明示的に述べられていない限り、複数形が企図される。