(57)【特許請求の範囲】
【請求項１】
サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加しているユーザ機器(UE)を操作する方法であって、
前記UEのディスプレイ上に、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するステップと、
前記所与の視覚表現の少なくとも1つの座標の選択を示すユーザ入力を受信するステップと、
前記少なくとも1つの座標の前記選択を示す座標パケットを、前記少なくとも1つの他のUEへの配布のために、前記サーバに選択的に送信するステップとを含み、
前記座標パケットが、前記UEの前記ディスプレイ上の前記所与の視覚表現に関連して前記選択が起こった少なくとも1つの位置を示すことによって、前記少なくとも1つの座標の前記選択を示す、方法。
【請求項２】
前記座標パケットが、前記所与の視覚表現の少なくとも1つの異なるバージョンに対する、前記少なくとも1つの他のUEにおける前記選択の再構築を許可するための、前記所与の視覚表現に関連付けられた提示再構築パラメータセットをさらに示すことによって、前記少なくとも1つの座標の前記選択を示す、請求項1に記載の方法。
【請求項３】
前記選択が、前記少なくとも1つの他のUEにおいて提示される前記所与の視覚表現の閲覧エリアの外の位置を選択すると判断するステップをさらに含み、
前記提示再構築パラメータセットが、前記UEにおいて選択された前記少なくとも1つの座標の提示のために、前記少なくとも1つの他のUEにおける前記閲覧エリアを調整するための要求を含む、請求項2に記載の方法。
【請求項４】
前記少なくとも1つの他のUEが、前記少なくとも1つの座標の前記選択を提示したかどうかを示す指示を受信するステップをさらに含む、請求項1に記載の方法。
【請求項５】
前記少なくとも1つの座標の提示が、前記少なくとも1つの他のUEにおける前記所与の視覚表現の提示と競合すると判断するステップをさらに含み、
前記選択的に送信するステップが、前記判断に基づく前記少なくとも1つの座標の前記選択を示す前記座標パケットを送信しない、請求項1に記載の方法。
【請求項６】
前記判断するステップが、(i)前記少なくとも1つの座標が、前記少なくとも1つの他のUEにおける前記所与の視覚表現の閲覧エリアの外に提示され、または(ii)前記少なくとも1つの座標が、前記少なくとも1つの他のUEにおいて提示されることが可能でないと判断する、請求項5に記載の方法。
【請求項７】
前記少なくとも1つの座標の提示が、前記少なくとも1つの他のUEにおける前記所与の視覚表現の提示と競合すると判断するステップと、
前記少なくとも1つの座標の前記選択を、前記判断された競合を解消するように修正するステップとをさらに含み、
前記選択的に送信するステップが、前記少なくとも1つの座標の前記修正された選択を示す前記座標パケットを送信する、請求項1に記載の方法。
【請求項８】
前記サーバが、(i)前記座標共有通信セッションに参加している所与のUEまたは(ii)前記座標共有通信セッションに参加しているUEの外部のネットワークエンティティに対応する、請求項1に記載の方法。
【請求項９】
前記メディアコンテンツが、前記座標共有通信セッションに関連している前記UEと前記少なくとも1つの他のUEとの間で交換される、請求項1に記載の方法。
【請求項１０】
前記座標共有通信セッションに関連している前記UEと前記少なくとも1つの他のUEとの間で前記メディアコンテンツが交換されないように、前記メディアコンテンツが、前記UEおよび前記少なくとも1つの他のUEにおいて単独で取得される、請求項1に記載の方法。
【請求項１１】
前記受信するステップおよび前記選択的に送信するステップが、複数の時間間隔だけ繰り返し、
前記受信するステップの各インスタンスが、単一の時間間隔を表す単一のユーザ入力を判断し、
前記選択的に送信するステップの各インスタンスが、それぞれの単一の時間間隔に、前記単一のユーザ入力を送信することを試みる、請求項1に記載の方法。
【請求項１２】
前記選択的に送信するステップが、トークスパートの送信とともに前記座標パケットを送信する、請求項1に記載の方法。
【請求項１３】
前記少なくとも1つの座標の前記選択に依存しない、前記UEにおける非同期イベントを検出するステップをさらに含み、
前記選択的に送信するステップが、前記検出された非同期イベントに関連付けられた非同期データとともに前記座標パケットを送信する、請求項1に記載の方法。
【請求項１４】
サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加しているユーザ機器(UE)を操作する方法であって、
前記UEのディスプレイ上に、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するステップと、
1つまたは複数の他のUEにおいて表示される前記所与の視覚表現に基づく1組の座標を示し、前記座標共有通信セッション中の所与の期間中の前記1つまたは複数の他のUEにおけるユーザ入力により選択された座標出力フレームを前記サーバから受信するステップと、
前記受信された座標出力フレームに含まれる前記1組の座標を反映するように、前記所与の視覚表現を選択的に更新するステップとを含み、
前記座標出力フレームが、前記1つまたは複数の他のUEの前記ディスプレイ上の前記所与の視覚表現に関連して前記選択が起こった位置を示すことによって、前記1組の座標の前記選択を示す、方法。
【請求項１５】
前記座標出力フレームが、前記UEにおける前記選択された座標の再構築を許可するための、前記所与の視覚表現に関連付けられた提示再構築パラメータセットをさらに示すことによって、前記1組の座標の前記選択を示す、請求項14に記載の方法。
【請求項１６】
前記示された位置のうち少なくとも1つが、前記UEにおいて表示される前記所与の視覚表現の閲覧エリアの外であり、
前記提示再構築パラメータセットが、前記UEに、前記1組の座標の提示のために前記閲覧エリアを調整するよう要求する、請求項15に記載の方法。
【請求項１７】
前記選択的に更新するステップに応答して、前記UEが前記1組の座標のうちの少なくとも1つを提示したという指示を送信するステップをさらに含む、請求項14に記載の方法。
【請求項１８】
前記1組の座標のうち少なくとも1つの座標の提示が、前記UE上での前記所与の視覚表現の提示と競合すると判断するステップをさらに含み、
前記選択的に更新するステップが、前記競合した少なくとも1つの座標についての前記所与の視覚表現を更新しない、請求項14に記載の方法。
【請求項１９】
前記判断するステップが、(i)前記競合した少なくとも1つの座標が、前記UEの前記所与の視覚表現の閲覧エリアの外に提示され、または(ii)前記競合した少なくとも1つの座標が、前記UEの前記所与の視覚表現内に提示されることが可能でないと判断する、請求項18に記載の方法。
【請求項２０】
前記1組の座標のうち少なくとも1つの座標の提示が、前記UE上での前記所与の視覚表現の提示と競合すると判断するステップと、
前記競合した少なくとも1つの座標を、前記判断された競合を解消するように修正するステップとをさらに含み、
前記選択的に更新するステップが、前記修正された少なくとも1つの座標を反映するように前記所与の視覚表現を更新する、請求項14に記載の方法。
【請求項２１】
前記サーバが、(i)前記座標共有通信セッションに参加している所与のUEまたは(ii)前記座標共有通信セッションに参加している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)の間の座標共有通信セッションをサーバにおいて調停する方法であって、
座標受信期間(CRP)中に、前記複数のUEの各々において表示されているメディアコンテンツに関連付けられた情報を示す、前記複数のUEからの座標パケットを監視するステップと、
前記複数のUEの少なくとも1つから、前記少なくとも1つのUEにおけるユーザ入力によって前記メディアコンテンツの所与の視覚表現の少なくとも1つの座標の選択を示す座標パケットを前記CRP中に受信するステップであって、前記座標パケットが、前記少なくとも1つのUEのディスプレイ上の前記所与の視覚表現に関連して前記選択が起こった少なくとも1つの位置を示すことによって、前記少なくとも1つの座標の前記選択を示す、ステップと、
前記座標パケットからの前記選択された少なくとも1つの座標を、前記CRP中の前記複数のUEによる座標選択を示すように構成された座標出力フレームセットにフォーマットするステップと、
前記座標出力フレームセットを前記複数のUEに送信するステップとを含む方法。
【請求項３１】
前記受信するステップが、前記CRP中に、前記複数のUEのうちの2つ以上から座標パケットを受信し、
前記座標出力フレームセットのうちの1つまたは複数の座標出力フレームが、前記複数のUEのうちの前記2つ以上からの座標選択を含む、請求項30に記載の方法。
【請求項３２】
前記受信するステップが、前記CRP中に、前記複数のUEのうちすべてに満たないUEから座標パケットを受信し、
前記CRP中に座標パケットを与えなかった1つまたは複数のUEが、前記座標出力フレームセットから省かれる、請求項31に記載の方法。
【請求項３３】
前記座標パケットが、前記所与の視覚表現の少なくとも1つの異なるバージョンに対する、前記少なくとも1つの他のUEのディスプレイ上での前記選択の再構築を許可するための、前記所与の視覚表現に関連付けられた提示再構築パラメータセットをさらに示すことによって、前記少なくとも1つの座標の前記選択を示す、請求項30に記載の方法。
【請求項３４】
前記フォーマットするステップが、前記提示再構築パラメータセットに基づいて前記座標出力フレームセットをフォーマットする、請求項33に記載の方法。
【請求項３５】
前記選択された位置が、前記複数のUEのうちの1つまたは複数において提示される前記所与の視覚表現と競合すると判断するステップをさらに含み、
前記フォーマットするステップが、前記少なくとも1つの座標を、前記判断された競合を解決するために、前記座標出力フレームセット内の前記複数のUEのうち前記1つまたは複数への送信用に修正する、請求項33に記載の方法。
【請求項３６】
前記判断された競合が、前記複数のUEのうち前記1つまたは複数のUEの閲覧エリアの外の前記選択された位置に対応し、
前記フォーマットするステップが、前記選択された位置を、前記閲覧エリア内に収まる、異なる位置に調整することによって、前記少なくとも1つの座標を修正する、請求項35に記載の方法。
【請求項３７】
前記選択された位置が、前記複数のUEのうちの1つまたは複数において提示される前記所与の視覚表現と競合すると判断するステップをさらに含み、
前記フォーマットするステップが、前記複数のUEのうち前記1つまたは複数への送信用にフレーム化された前記座標出力フレームセットから前記少なくとも1つの座標を省く、請求項30に記載の方法。
【請求項３８】
前記送信するステップが、前記提示再構築パラメータセットを前記複数のUEのうちの1つまたは複数に送信する、請求項33に記載の方法。
【請求項３９】
前記複数のUEのうちの1つが、前記少なくとも1つの座標の前記選択を提示したかどうかを示す指示を受信するステップと、
前記複数のUEの前記少なくとも1つに、前記受信された指示を通知するステップとをさらに含む、請求項30に記載の方法。
【請求項４０】
前記サーバが、(i)前記複数のUEのうちの1つ、または(ii)前記複数のUEの外部のネットワークエンティティに対応する、請求項30に記載の方法。
【請求項４１】
前記メディアコンテンツが、前記座標共有通信セッションに関連している前記複数のUEの間で交換される、請求項30に記載の方法。
【請求項４２】
前記メディアコンテンツが、前記座標共有通信セッションに関連している前記複数のUEの間で交換されないように、前記メディアコンテンツが、前記複数のUEの各々において単独で取得される、請求項30に記載の方法。
【請求項４３】
前記受信するステップが、前記少なくとも1つのUEからのトークスパートとともに前記座標パケットを受信する、請求項30に記載の方法。
【請求項４４】
前記受信するステップが、前記少なくとも1つのUEにおいて起きた、前記少なくとも1つのUEにおける座標選択に依存しない、非同期イベントに関連付けられた非同期データとともに前記座標パケットを受信する、請求項30に記載の方法。
【請求項４５】
前記座標共有通信セッションに関連付けられた座標情報をアーカイブするステップをさらに含み、
前記アーカイブされた座標情報が、前記座標パケットからの前記座標出力フレームセットおよび/または前記少なくとも1つの座標を含む、請求項30に記載の方法。
【請求項４６】
前記座標共有通信セッションがアクティブである間に、所与のUEが、前記座標共有通信セッションに遅れて加わり、または停止後に前記座標共有通信セッションに再度加わったことを検出するステップと、
前記アーカイブされた座標情報、および前記所与のUEが逃したと思われる前記座標共有通信セッション部分に基づいて、別の座標出力フレームセットを前記所与のUEに送信するステップとをさらに含む、請求項45に記載の方法。
【請求項４７】
前記座標出力フレームセットが前記複数のUEに送信されるよりも高いレートで、前記別の座標出力フレームセットが前記所与のUEに送信される、請求項46に記載の方法。
【請求項４８】
前記座標共有通信セッションが終了された後、前記アーカイブされた座標情報を所与のUEに送信すると判断するステップと、
前記アーカイブされた座標情報を、別の座標出力フレームセットにフォーマットするステップと、
前記別の座標出力フレームセットを前記所与のUEに送信するステップとをさらに含む、請求項45に記載の方法。
【請求項４９】
前記監視するステップが、
(i)前記CRPが満了に近づいているとき、前記座標共有通信セッションに参加している少なくとも1つの高優先度UEからの座標パケットがまだ受信されていないこと、および/または(ii)前記CRPが満了に近づいているとき、ハンディキャップ付きUEが座標パケットをまだ与えていない場合、前記ハンディキャップが、前記複数のUEのうちの1つまたは複数に関連付けられた遅いフィードバックを示すことに応答して、前記CRPを延長するステップを含む、請求項30に記載の方法。
【請求項５０】
前記監視するステップが、
(i)前記複数のUEのうちの各高優先度UEからの座標パケットが、前記CRPの満了前に受信されたこと、および/または(ii)前記複数のUEの各々からの座標パケットが、前記CRPの満了前に受信されたことに応答して前記CRPを短縮するステップを含む、請求項30に記載の方法。
【請求項５１】
前記送信するステップが、前記座標出力フレームセットを、共通座標出力フレームとして、前記複数のUEのうちの2つ以上にIPマルチキャストにより送信する、請求項30に記載の方法。
【請求項５２】
前記送信するステップが、前記座標出力フレームセットを、UE固有座標出力フレームセットとして、IPユニキャストにより前記複数のUEの各々に別々に送信する、請求項30に記載の方法。
【請求項５３】
前記UE固有座標出力フレームセットが各々、それぞれの目標UEにおける提示に適さないデータを選択的に省く、請求項52に記載の方法。
【請求項５４】
前記選択的に省かれたデータが、前記それぞれの目標UE自体の座標選択に関連付けられたデータを含む、請求項53に記載の方法。
【請求項５５】
サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加するように構成されたユーザ機器(UE)であって、
前記UEのディスプレイ上に、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するための手段と、
前記所与の視覚表現の少なくとも1つの座標の選択を示すユーザ入力を受信するための手段と、
前記少なくとも1つの座標の前記選択を示す座標パケットを、前記少なくとも1つの他のUEへの配布のために、前記サーバに選択的に送信するための手段とを備え、
前記座標パケットが、前記UEの前記ディスプレイ上の前記所与の視覚表現に関連して前記選択が起こった少なくとも1つの位置を示すことによって、前記少なくとも1つの座標の前記選択を示す、ユーザ機器(UE)。
【請求項５６】
サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加するように構成されたユーザ機器(UE)であって、
前記UEのディスプレイ上に、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するための手段と、
1つまたは複数の他のUEにおいて表示される前記所与の視覚表現に基づく1組の座標を示し、前記座標共有通信セッション中の所与の期間中の前記1つまたは複数の他のUEにおけるユーザ入力により選択された座標出力フレームを前記サーバから受信するための手段と、
前記受信された座標出力フレームに含まれる前記1組の座標を反映するように、前記所与の視覚表現を選択的に更新するための手段とを備え、
前記座標出力フレームが、前記1つまたは複数の他のUEの前記ディスプレイ上の前記所与の視覚表現に関連して前記選択が起こった位置を示すことによって、前記1組の座標の前記選択を示す、ユーザ機器(UE)。
【請求項５７】
複数のユーザ機器(UE)の間の座標共有通信セッションを調停するように構成されたサーバであって、
座標受信期間(CRP)中に、前記複数のUEの各々において表示されているメディアコンテンツに関連付けられた情報を示す、前記複数のUEからの座標パケットを監視するための手段と、
前記複数のUEの少なくとも1つから、前記少なくとも1つのUEにおけるユーザ入力によって前記メディアコンテンツの所与の視覚表現の少なくとも1つの座標の選択を示す座標パケットを前記CRP中に受信するための手段であって、前記座標パケットが、前記少なくとも1つのUEのディスプレイ上の前記所与の視覚表現に関連して前記選択が起こった少なくとも1つの位置を示すことによって、前記少なくとも1つの座標の前記選択を示す、手段と、
前記座標パケットからの前記選択された少なくとも1つの座標を、前記CRP中の前記複数のUEによる座標選択を示すように構成された座標出力フレームセットにフォーマットするための手段と、
前記座標出力フレームセットを前記複数のUEに送信するための手段とを備えるサーバ。
【請求項５８】
前記サーバが、(i)前記複数のUEのうちの1つ、または(ii)前記複数のUEの外部のネットワークエンティティに対応する、請求項57に記載のサーバ。
【請求項５９】
サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加するように構成されたユーザ機器(UE)であって、
前記UEのディスプレイ上に、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するように構成された論理部と、
前記所与の視覚表現の少なくとも1つの座標の選択を示すユーザ入力を受信するように構成された論理部と、
前記少なくとも1つの座標の前記選択を示す座標パケットを、前記少なくとも1つの他のUEへの配布のために、前記サーバに選択的に送信するように構成された論理部とを備え、
前記座標パケットが、前記UEの前記ディスプレイ上の前記所与の視覚表現に関連して前記選択が起こった少なくとも1つの位置を示すことによって、前記少なくとも1つの座標の前記選択を示す、ユーザ機器(UE)。
【請求項６０】
サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加するように構成されたユーザ機器(UE)であって、
前記UEのディスプレイ上に、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するように構成された論理部と、
1つまたは複数の他のUEにおいて表示される前記所与の視覚表現に基づく1組の座標を示し、前記座標共有通信セッション中の所与の期間中の前記1つまたは複数の他のUEにおけるユーザ入力により選択された座標出力フレームを前記サーバから受信するように構成された論理部と、
前記受信された座標出力フレームに含まれる前記1組の座標を反映するように、前記所与の視覚表現を選択的に更新するように構成された論理部とを備え、
前記座標出力フレームが、前記1つまたは複数の他のUEの前記ディスプレイ上の前記所与の視覚表現に関連して前記選択が起こった位置を示すことによって、前記1組の座標の前記選択を示す、ユーザ機器(UE)。
【請求項６１】
複数のユーザ機器(UE)の間の座標共有通信セッションを調停するように構成されたサーバであって、
座標受信期間(CRP)中に、前記複数のUEの各々において表示されているメディアコンテンツに関連付けられた情報を示す、前記複数のUEからの座標パケットを監視するように構成された論理部と、
前記複数のUEの少なくとも1つから、前記少なくとも1つのUEにおけるユーザ入力によって前記メディアコンテンツの所与の視覚表現の少なくとも1つの座標の選択を示す座標パケットを前記CRP中に受信するように構成された論理部であって、前記座標パケットが、前記少なくとも1つのUEのディスプレイ上の前記所与の視覚表現に関連して前記選択が起こった少なくとも1つの位置を示すことによって、前記少なくとも1つの座標の前記選択を示す、論理部と、
前記座標パケットからの前記選択された少なくとも1つの座標を、前記CRP中の前記複数のUEによる座標選択を示すように構成された座標出力フレームセットにフォーマットするように構成された論理部と、
前記座標出力フレームセットを前記複数のUEに送信するように構成された論理部とを備えるサーバ。
【請求項６２】
前記サーバが、(i)前記複数のUEのうちの1つ、または(ii)前記複数のUEの外部のネットワークエンティティに対応する、請求項61に記載のサーバ。 
【請求項６３】
サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加するように構成されたユーザ機器(UE)によって実行されると前記UEに動作を実施させる、記録された命令を含むコンピュータ可読記録媒体であって、前記命令が、
前記UEのディスプレイ上に、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するためのプログラムコードと、
前記所与の視覚表現の少なくとも1つの座標の選択を示すユーザ入力を受信するためのプログラムコードと、
前記少なくとも1つの座標の前記選択を示す座標パケットを、前記少なくとも1つの他のUEへの配布のために、前記サーバに選択的に送信するためのプログラムコードとを備え、
前記座標パケットが、前記UEの前記ディスプレイ上の前記所与の視覚表現に関連して前記選択が起こった少なくとも1つの位置を示すことによって、前記少なくとも1つの座標の前記選択を示す、コンピュータ可読記録媒体。
【請求項６４】
サーバによって調停される、少なくとも1つの他のUEとの座標共有通信セッションに参加するように構成されたユーザ機器(UE)によって実行されると、前記UEに動作を実施させる、記録された命令を含むコンピュータ可読記録媒体であって、前記命令が、
前記UEのディスプレイ上に、前記座標共有通信セッションに関連付けられたメディアコンテンツの所与の視覚表現を表示するためのプログラムコードと、
1つまたは複数の他のUEにおいて表示される前記所与の視覚表現に基づく1組の座標を示し、前記座標共有通信セッション中の所与の期間中の前記1つまたは複数の他のUEにおけるユーザ入力により選択された座標出力フレームを前記サーバから受信するためのプログラムコードと、
前記受信された座標出力フレームに含まれる前記1組の座標を反映するように、前記所与の視覚表現を選択的に更新するためのプログラムコードとを備え、
前記座標出力フレームが、前記1つまたは複数の他のUEの前記ディスプレイ上の前記所与の視覚表現に関連して前記選択が起こった位置を示すことによって、前記1組の座標の前記選択を示す、コンピュータ可読記録媒体。
【請求項６５】
複数のユーザ機器(UE)との間の座標共有通信セッションを調停するように構成されたサーバによって実行されると、前記サーバに動作を実施させる、記録された命令を含むコンピュータ可読記録媒体であって、前記命令が、
座標受信期間(CRP)中に、前記複数のUEの各々において表示されているメディアコンテンツに関連付けられた情報を示す、前記複数のUEからの座標パケットを監視するためのプログラムコードと、
前記複数のUEの少なくとも1つから、前記少なくとも1つのUEにおけるユーザ入力によって前記メディアコンテンツの所与の視覚表現の少なくとも1つの座標の選択を示す座標パケットを前記CRP中に受信するためのプログラムコードであって、前記座標パケットが、前記少なくとも1つのUEのディスプレイ上の前記所与の視覚表現に関連して前記選択が起こった少なくとも1つの位置を示すことによって、前記少なくとも1つの座標の前記選択を示す、プログラムコードと、
前記座標パケットからの前記選択された少なくとも1つの座標を、前記CRP中の前記複数のUEによる座標選択を示すように構成された座標出力フレームセットにフォーマットするためのプログラムコードと、
前記座標出力フレームセットを前記複数のUEに送信するためのプログラムコードとを備える、コンピュータ可読記録媒体。
【請求項６６】
前記サーバが、(i)前記複数のUEのうちの1つ、または(ii)前記複数のUEの外部のネットワークエンティティに対応する、請求項65に記載のコンピュータ可読記録媒体。
【請求項６７】
前記サーバから、前記少なくとも1つの他のUEが自身の視覚表現を前記少なくとも1つの座標の前記選択を反映するように更新済みであるという応答を受信するステップをさらに含む、請求項1に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
米国特許法第119条に基づく優先権の主張
本特許出願は、本出願の譲受人に譲渡され、参照により明示的に本明細書に組み込まれる、2010年12月8日に出願された「COORDINATE SHARING BETWEEN USER EQUIPMENTS DURING A GROUP COMMUNICATION SESSION IN A WIRELESS COMMUNICATIONS SYSTEM」という名称の仮出願第61/421,046号の優先権を主張する。
【０００２】
本発明の実施形態は、ワイヤレス通信システムにおけるグループ通信セッション中のユーザ機器(UE)の間の座標共有に関する。
【背景技術】
【０００３】
ワイヤレス通信システムは、第1世代アナログワイヤレス電話サービス(1G)、第2世代(2G)デジタルワイヤレス電話サービス(暫定の2.5Gおよび2.75Gネットワークを含む)、ならびに第3世代(3G)高速データ/インターネット対応ワイヤレスサービスを含む、様々な世代を通じて発展してきた。現在、セルラーシステムとパーソナルコミュニケーションズサービス(PCS)システムとを含む、多くの様々なタイプのワイヤレス通信システムが使用されている。知られているセルラーシステムの例には、セルラーアナログアドバンストモバイルフォンシステム(AMPS)、および符号分割多元接続(CDMA)、周波数分割多元接続(FDMA)、直交FDMA(OFDMA)、時分割多元接続(TDMA)、TDMAの広域移動通信システム(GSM(登録商標))変形に基づくデジタルセルラーシステム、およびTDMA技術とCDMA技術の両方を使用するより新しいハイブリッドデジタル通信システムがある。
【０００４】
CDMAモバイル通信を提供するための方法は、本明細書ではIS-95と呼ぶ、「Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System」と題するTIA/EIA/IS-95-Aにおいて、米国電気通信工業会/米国電子工業会によって米国で規格化された。複合AMPS&CDMAシステムは、TIA/EIA規格IS-98に記載されている。他の通信システムは、広帯域CDMA(WCDMA(登録商標))、CDMA2000(たとえばCDMA2000 1xEV-DO標準など)またはTD-SCDMAと呼ばれるものを対象とする、IMT-2000/UM、または国際移動電気通信システム2000/ユニバーサルモバイル通信システムの規格に記載されている。
【０００５】
WCDMA(登録商標)ワイヤレス通信システムにおいて、ユーザ機器(UE)は、基地局に隣接するまたは基地局の周囲の特定の地理的領域内の通信リンクまたはサービスをサポートする固定位置のノードB(セルサイトまたはセルとも呼ばれる)から信号を受信する。ノードBは、一般にサービス品質(QoS)要求に基づいてトラフィックを区別するための方法をサポートする標準Internet Engineering Task Force (IETF)ベースのプロトコルを使用したパケットデータネットワークであるアクセスネットワーク(AN)/無線アクセスネットワーク(RAN)にエントリーポイントを提供する。したがって、ノードBは、一般に、エアインターフェースを介してUEと、またインターネットプロトコル(IP)ネットワークデータパケットを介してRANと対話する。
【発明の概要】
【課題を解決するための手段】
【０００６】
ユーザ機器(UE)は、サーバによって調停される、少なくとも1つの他のUE(たとえば、セッションに参加する別のUEまたは独立サーバ)との座標共有通信セッションに参加する。UEは、座標共有通信セッションに関連付けられたメディアコンテンツの、所与の視覚表現を表示する。ある実施形態では、UEは、所与の視覚表現の少なくとも1つの座標の選択を示すユーザ入力を受信し、座標パケットにより、座標選択をサーバに報告する。座標共有通信セッション中、サーバは、参加UEからの座標パケットを監視し、それぞれのUEにおける選択座標を示す座標出力フレームをフォーマットする。別の実施形態では、UEは、少なくとも1つの他のUEにおける座標選択を示す座標出力フレームを受信し、それに従って、UEの所与の視覚表現を選択的に更新する。
【０００７】
本発明の実施形態およびその付随する利点の多くのより完全な諒解は、以下の詳細な説明を参照し、本発明を限定するためではなく単に例示するために提示する添付の図面とともに考察することによってよりよく理解されれば、容易に得られるであろう。
【図面の簡単な説明】
【０００８】
【図１】本発明の少なくとも1つの実施形態による、ユーザ機器および無線アクセスネットワークをサポートするワイヤレスネットワークアーキテクチャを示す図である。
【図２Ａ】本発明の一実施形態による図1のコアネットワークを示す図である。
【図２Ｂ】図1のワイヤレス通信システムの一例をより詳細に示す図である。
【図３】本発明の少なくとも1つの実施形態によるユーザ機器を示す図である。
【図４Ａ】本発明の実施形態による、当該点を示す座標情報が複数のUEの間で共有されるための、複数のユーザ機器(UE)の間のサーバ調停型グループ通信セッションをセットアップするプロセスを示す図である。
【図４Ｂ】本発明の実施形態による、図4Aのプロセスの続きを示す図である。
【図５Ａ】本発明の実施形態による、図4Aのプロセス中から受信され得るユーザ入力の例を示す図である。
【図５Ｂ】本発明の実施形態による、図5Aからのユーザ入力に基づく、複数のUEのディスプレイ上の、更新された視覚表現の例を示す図である。
【図５Ｃ】本発明の実施形態による、図4Bのプロセス中から受信され得るユーザ入力の例を示す図である。
【図５Ｄ】本発明の実施形態による、図5Cからのユーザ入力に基づく、複数のUEのディスプレイ上の、更新された視覚表現の例を示す図である。
【図６】本発明の実施形態による、図4Aおよび/または図4Bのプロセス中のアプリケーションサーバの動作を示す図である。
【図７Ａ】本発明のある実施形態による、図6のプロセスのより詳細な実装例を示す図である。
【図７Ｂ】本発明の別の実施形態による、図6のプロセスのより詳細な実装例を示す図である。
【図７Ｃ】本発明のさらに別の実施形態による、図6のプロセスのより詳細な実装例を示す図である。
【図８】本発明の実施形態による、図6のプロセスの一部分のより詳細な実装を示す図である。
【図９Ａ】本発明の実施形態による、図8のプロセス中に起こり得るデータ操作の例を示す図である。
【図９Ｂ】本発明の実施形態による、図8のプロセス中に起こり得るデータ操作の例を示す図である。
【図９Ｃ】本発明の実施形態による、図8のプロセス中に起こり得るデータ操作の例を示す図である。
【図９Ｄ】本発明の実施形態による、図8のプロセス中に起こり得るデータ操作の例を示す図である。
【図１０Ａ】本発明の実施形態による、図8のプロセス中に起こり得るデータ操作の例を示す図である。
【図１０Ｂ】本発明の実施形態による、図8のプロセス中に起こり得るデータ操作の例を示す図である。
【図１１Ａ】本発明の実施形態による、アーカイブされたグループ通信セッションをリプレイするプロセスを示す図である。
【図１１Ｂ】本発明の実施形態による、キャッチアップモードでアクティブグループ通信セッションの一部分をリプレイするプロセスを示す図である。
【図１２】本発明の実施形態による、機能性を実施するように構成された論理部を含む通信デバイスを示す図である。
【発明を実施するための形態】
【０００９】
本発明の特定の実施形態を対象とする以下の説明および関連する図面で本発明の態様を開示する。本発明の範囲から逸脱することなく、代替的な実施形態を考案することができる。さらに、本発明の関連する詳細を不明瞭にしないように、本発明のよく知られている要素については詳細に説明しないか、または省略する。
【００１０】
「例示的」および/または「例」という用語は、本明細書では「例、事例、または例示として機能すること」を意味するために使用される。本明細書で「例示的」および/または「例」として説明するいかなる実施形態も、必ずしも他の実施形態よりも好ましいまたは有利であると解釈すべきではない。同様に、「本発明の実施形態」という用語は、本発明のすべての実施形態が、論じられた特徴、利点または動作モードを含むことを必要としない。
【００１１】
さらに、多くの実施形態が、たとえば、コンピューティングデバイスの要素によって実行すべき一連のアクションに関して説明される。本明細書で説明する様々なアクションは、特定の回路(たとえば、特定用途向け集積回路(ASIC))によって、1つもしくは複数のプロセッサによって実行されるプログラム命令によって、または両方の組合せによって実行できることが認識されよう。さらに、本明細書で説明するこれらの一連のアクションは、実行時に、関連するプロセッサに本明細書で説明する機能を実行させるコンピュータ命令の対応するセットを記憶した、任意の形式のコンピュータ可読記憶媒体内で完全に具現化されるものと見なすことができる。したがって、本発明の様々な態様は、すべてが特許請求される主題の範囲内に入ることが企図されているいくつかの異なる形式で具現化できる。さらに、本明細書で説明する実施形態ごとに、任意のそのような実施形態の対応する形式を、たとえば、記載のアクションを実行する「ように構成された論理」として本明細書で説明することがある。
【００１２】
本明細書ではユーザ機器(UE)と呼ばれる高データレート(HDR)加入者局は、モバイルでも固定でもよく、ノードBと呼ばれ得る1つまたは複数のアクセスポイント(AP)と通信することができる。UEは、ノードBのうちの1つまたは複数を介して、無線ネットワークコントローラ(RNC)との間でデータパケットを送受信する。ノードBおよびRNCは、無線アクセスネットワーク(RAN)と呼ばれるネットワークの部分である。無線アクセスネットワークは、複数のUE間に音声およびデータパケットをトランスポートすることができる。
【００１３】
無線アクセスネットワークは、無線アクセスネットワークの外部の追加のネットワークにさらに接続されていてもよく、そのようなコアネットワークは、特定のキャリア関連のサーバおよびデバイス、ならびに企業内イントラネット、インターネット、公衆交換電話網(PSTN)、サービング汎用パケット無線サービス(GPRS)サポートノード(SGSN)、ゲートウェイGPRSサポートノード(GGSN)など他のネットワークへの接続を含んでおり、各UEとそのようなネットワークとの間で音声およびデータパケットをトランスポートすることができる。1つまたは複数のノードBとのアクティブなトラフィックチャネル接続を確立したUEは、アクティブなUEと呼ぶことができ、トラフィック状態であると呼ぶことができる。1つまたは複数のノードBとのアクティブなトラフィックチャネル(TCH)接続を確立する過程にあるUEは、接続セットアップ状態であると呼ぶことができる。UEは、ワイヤレスチャネルまたは有線のチャネルを介して通信する任意のデータデバイスとすることができる。UEは、さらに、限定はしないが、PCカード、コンパクトフラッシュ(登録商標)デバイス、外付けまたは内蔵のモデム、あるいはワイヤレスまたは有線の電話を含むいくつかのタイプのデバイスのうちの任意のものでもよい。UEが信号をノードBに送る通信リンクは、アップリンクチャネル(たとえば、逆方向トラフィックチャネル、制御チャネル、アクセスチャネルなど)と呼ばれる。ノードBが信号をUEに送る通信リンクは、ダウンリンクチャネル(たとえば、ページングチャネル、制御チャネル、ブロードキャストチャネル、順方向トラフィックチャネルなど)と呼ばれる。本明細書で使用する場合、トラフィックチャネル(TCH)という用語は、アップリンク/逆方向、またはダウンリンク/順方向トラフィックチャネルのいずれかを指し得る。
【００１４】
図1は、本発明の少なくとも1つの実施形態によるワイヤレス通信システム100の例示的な一実施形態のブロック図を示す。システム100は、パケット交換データネットワーク(たとえばイントラネット、インターネット、および/またはコアネットワーク126)とUE102、108、110、112との間にデータ接続を提供するネットワーク機器にアクセス端末102を接続することができるアクセスネットワークまたは無線アクセスネットワーク(RAN)120と、エアインターフェース104を介して通信しているセルラー電話102などのUEを含むことができる。本明細書に示すように、UEは、セルラー電話102、携帯情報端末108、本明細書では双方向テキストページャとして示すページャ110、さらにはワイヤレス通信ポータルを有する個別のコンピュータプラットフォーム112とすることができる。したがって、本発明の実施形態は、それだけには限定されないが、ワイヤレスモデム、PCMCIAカード、パーソナルコンピュータ、電話、またはそれらの任意の組合せまたは部分的組合せを含めて、ワイヤレス通信ポータルを含む、またはワイヤレス通信機能を有する任意の形態のアクセス端末において実現することができる。さらに、本明細書で使用するように、他の通信プロトコル(すなわちWCDMA(登録商標)以外)における「UE」という用語は、互換的に「アクセス端末」、「AT」、「ワイヤレスデバイス」、「クライアントデバイス」、「モバイル端末」、「移動局」、およびそれらの変形と呼ばれ得る。
【００１５】
再び図1を参照すると、ワイヤレス通信システム100の構成要素、および本発明の例示的な実施形態の要素の相互関係は、図示の構成に限定されない。システム100は、例にすぎず、ワイヤレスクライアントコンピューティングデバイス102、108、110、112などのリモートUEが、無線で互いの間で、および/またはそれだけには限定されないが、コアネットワーク126、インターネット、PSTN、SGSN、GGSN、および/または他のリモートサーバを含めて、エアインターフェース104およびRAN120を介して接続される構成要素の間で通信することができる任意のシステムを含むことができる。
【００１６】
RAN120は、RNC122に送られる(一般的にデータパケットとして送られる)メッセージを制御する。RNC122は、サービング汎用パケット無線サービス(GPRS)サポートノード(SGSN)とUE102/108/110/112との間のベアラチャネル(すなわち、データチャネル)のシグナリング、確立、およびティアダウンを行う役目を果たす。また、リンクレイヤ暗号化が可能な場合、RNC122は、エアインターフェース104を介してコンテンツを転送する前に、コンテンツを暗号化する。RNC122の機能は、当技術分野でよく知られており、簡潔のためにこれ以上は説明しない。コアネットワーク126は、ネットワーク、インターネット、および/または公衆交換電話網(PSTN)によって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(登録商標)システム内に実装される汎用パケット無線サービス(GPRS)コアネットワークの構成要素を示す。図2Aの実施形態では、コアネットワーク126は、サービングGPRSサポートノード(SGSN)160、ゲートウェイGPRSサポートノード(GGSN)165、およびインターネット175を含む。しかし、代替実施形態では、インターネット175および/または他の構成要素の部分がコアネットワークの外部に配置されていてもよいことを諒解されたい。
【００１８】
一般に、GPRSは、インターネットプロトコル(IP)パケットを送信するために、Global System for Mobile communications(GSM(登録商標))電話によって使用されるプロトコルである。GPRSコアネットワーク(たとえば、GGSN165および1つまたは複数のSGSN160)は、GPRSシステムの中央部であり、WCDMA(登録商標)ベースの3Gネットワークのサポートも提供する。GPRSコアネットワークは、GSM(登録商標)コアネットワークの一体部であり、GSM(登録商標)およびWCDMA(登録商標)ネットワークにおけるIPパケットサービスのモビリティ管理、セッション管理、およびトランスポートを提供する。
【００１９】
GPRSトンネリングプロトコル(GTP)は、GPRSコアネットワークの限定的なIPプロトコルである。GTPは、GGSN165において、まるで1つの位置からインターネットに接続し続けながら、GSM(登録商標)またはWCDMA(登録商標)ネットワークのエンドユーザ(たとえば、アクセス端末)があちこちに移動することができるプロトコルである。これは、加入者のデータを加入者の現在のSSGN160から、加入者のセッションを処理しているGGSN165に転送することによって達成される。
【００２０】
GTPの3つの形態、すなわち(i)GTP-U、(ii)GTP-C、および(iii)GTP'(GTP Prime)がGPRSコアネットワークによって使用される。GTP-Uは、パケットデータプロトコル(PDP)コンテキストごとに分離されたトンネルでのユーザデータの転送に使用される。GTP-Cは、制御シグナリング(たとえば、PDPコンテキストのセットアップおよび削除、GSN到達可能性の検証、加入者があるSGSNから別のSGSNに移動したときなどの更新または変更)に使用される。GTP'は、GSNから課金機能への課金データの転送のために使用される。
【００２１】
図2Aを参照すると、GGSN165は、GPRSバックボーンネットワーク(図示せず)と外部パケットデータネットワーク175との間のインターフェースとして働く。GGSN165は、関連するパケットデータプロトコル(PDP)形式(たとえば、IPまたはPPP)のパケットデータを、SGSN160から来るGPRSパケットから抽出し、対応するパケットデータネットワーク上でパケットを送る。他の方向では、着信データパケットは、GGSN165によってSGSN160に向けられ、SGSN160は、RAN120によってサービスされる宛先のUEの無線アクセスベアラ(RAB)を管理し、制御する。それによって、GGSN165は、ターゲットUEの現在のSGSNアドレス、およびそのユーザのプロファイルをそのロケーションレジスタ(たとえば、PDPコンテキスト内)に記憶する。GGSNは、IPアドレス割当ての役目を果たし、接続されたUEのデフォルトルータである。また、GGSNは、認証および課金機能を実行する。
【００２２】
一例では、SGSN160は、コアネットワーク126内の多くのSGSNのうちの1つの代表である。各SGSNは、関連する地理的サービスエリア内で、UEからおよびUEにデータパケットを配信する役目を果たす。SGSN160のタスクには、パケットルーティングおよび転送、モビリティ管理(たとえば、接続/切断およびロケーション管理)、論理リンク管理、ならびに認証および課金機能がある。SGSNのロケーションレジスタは、位置情報(たとえば、現在のセル、現在のVLRなど)、および、たとえばユーザまたはUEごとに1つまたは複数のPDPコンテキスト内など、SGSN160に登録されたすべてのGPRSユーザのユーザプロファイル(たとえば、パケットデータネットワークで使用するIMSI、PDPアドレスなど)を記憶する。したがって、SGSNは、(i)GGSN165からのダウンリンクGTPパケットの逆トンネリング、(ii)GGSN165方向のIPパケットのアップリンクトンネル、(iii)UEがSGSNサービスエリアの間を移動するときのモビリティ管理の実行、(iv)モバイル加入者の支払い請求の役目を果たす。当業者なら諒解するように、(i)〜(iv)の他に、GSM/EDGEネットワークのために構成されたSGSNは、WCDMA(登録商標)ネットワークのために構成されたSGSNと比較して、わずかに異なる機能を有する。
【００２３】
RAN120(たとえば、またはユニバーサルモバイル通信システム(UMTS)システムアーキテクチャにおけるUTRANなど)は、フレームリレーまたはIPなどの送信プロトコルによって、Iuインターフェースを介してSGSN160と通信する。SGSN160は、SGSN160および他のSGSN(図示せず)と内部のGGSNとの間のIPベースのインターフェースであり、上記で定義されたGTPプロトコル(たとえば、GTP-U、GTP-C、GTP'など)を使用するGnインターフェースを介してGGSN165と通信する。図2Aには示されていないが、Gnインターフェースは、ドメインネームシステム(DNS)によっても使用される。GGSN165は、公衆データネットワーク(PDN)(図示せず)に、次にインターネット175に、IPプロトコルによるGiインターフェースを介して直接、またはワイヤレスアプリケーションプロトコル(WAP)ゲートウェイを介して接続される。
【００２４】
PDPコンテキストは、UEがアクティブなGPRSセッションを有するとき、特定のUEの通信セッション情報を含む、SGSN160とGGSN165の両方に存在するデータ構造である。UEは、GPRS通信セッションを開始することを望むとき、まず、SGSN160に接続し、次いでGGSN165によりPDPコンテキストを起動させなければならない。これによって、加入者が現在訪問しているSGSN160、およびUEのアクセスポイントにサービスしているGGSN165において、PDPコンテキストデータ構造が割り振られる。
【００２５】
図2Bは、図1のワイヤレス通信システム100の一例をより詳細に示す。特に、図2Bを参照すると、UE1〜Nは、異なるパケットデータネットワークのエンドポイントによってサービスされる位置でRAN120に接続するものとして示されている。図2Bの例は、WCDMA(登録商標)システムおよび用語に固有のものであるが、1xEV-DOシステムに適合するために図2Bをどのように変更することができるかは理解されよう。したがって、UE1およびUE3は、第1のパケットデータネットワークエンドポイント162(たとえば、SGSN、GGSN、PDSN、ホームエージェント(HA)、外部エージェント(FA)などに対応し得る)によってサービスされる部分でRAN120に接続する。第1のパケットデータネットワークエンドポイント162は、次に、ルーティングユニット188を介して、インターネット175、ならびに/または認証、認可およびアカウンティング(AAA)サーバ182、プロビジョニングサーバ184、アーカイブデータベース186、および/もしくはアプリケーションサーバ170のうちの1つもしくは複数に接続する。UE2およびUE5〜Nは、(たとえば、SGSN、GGSN、PDSN、FA、HAなどに対応し得る)第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は、複数のメディア制御コンプレックス(MCC)1〜N 170Bと複数の地域ディスパッチャ1〜N 170Aとを含むものとして示されている。集合的に、地域ディスパッチャ170AおよびMCC170Bは、少なくとも1つの実施形態では、ワイヤレス通信システム100内の通信セッション(たとえば、IPユニキャストプロトコルおよび/またはIPマルチキャストプロトコルを介した半二重グループ通信セッション)を調停するように集合的に機能するサーバの分散型ネットワークに対応することができるアプリケーションサーバ170内に含まれる。たとえば、アプリケーションサーバ170によって調停される通信セッションは、理論上、システム100内のどこかに位置するUE間で行われ得るので、調停された通信セッションの待ち時間を減らすために(たとえば、北米のMCCが中国にあるセッション参加者間で媒体をあちこち中継しないように)、複数の地域ディスパッチャ170AおよびMCCが分散される。したがって、アプリケーションサーバ170を参照すると、関連する機能は、地域ディスパッチャ170Aのうちの1つもしくは複数、および/またはMCC170Bのうちの1つもしくは複数によって実施することができることを諒解されよう。地域ディスパッチャ170Aは、全般的に、通信セッションを確立することに関連する任意の機能(たとえば、UE間のシグナリングメッセージの処理、告知メッセージのスケジューリングおよび/または送信など)を受け持ち、MCC170Bは、通話中シグナリング、調停された通信セッション中の媒体の実際の交換を行うことを含めて、呼インスタンスの間の通信セッションをホストする役目を果たす。
【００２８】
図3を参照すると、セルラー電話などのUE200(ここではワイヤレスデバイス)は、コアネットワーク126、インターネットならびに/または他のリモートサーバおよびネットワークから最終的に来ることがある、RAN120から送信されたソフトウェアアプリケーション、データおよび/またはコマンドを受信し、実行することができるプラットフォーム202を有する。プラットフォーム202は、特定用途向け集積回路(ASIC)208もしくは他のプロセッサ、マイクロプロセッサ、論理回路、または他のデータ処理デバイスに動作可能に結合された、送受信機206を含むことができる。ASIC208または他のプロセッサは、ワイヤレスデバイスのメモリ212中の任意の常駐プログラムとインターフェースするアプリケーションプログラミングインターフェース(API)210レイヤを実行する。メモリ212は、読取り専用メモリもしくはランダムアクセスメモリ(RAMおよびROM)、EEPROM、フラッシュカード、またはコンピュータプラットフォームに共通の任意のメモリから構成することができる。プラットフォーム202は、メモリ212中でアクティブに使用されないアプリケーションを保持することができるローカルデータベース214を含むこともできる。ローカルデータベース214は、一般にフラッシュメモリセルであるが、磁気媒体、EEPROM、光学媒体、テープ、ソフトまたはハードディスクなど、当技術分野で知られている任意の二次記憶デバイスとすることができる。内部プラットフォーム202の構成要素はまた、当技術分野で知られていているように、他の構成要素の中でもアンテナ222、ディスプレイ224、プッシュツートークボタン228およびキーパッド226などの外部デバイスに動作可能に結合され得る。
【００２９】
したがって、本発明の一実施形態は、本明細書で説明した機能を実行する能力を含むUEを含むことができる。当業者ならば諒解するように、様々な論理要素は、本明細書で開示する機能を達成するために、個別の要素、プロセッサ上で実行されるソフトウェアモジュール、またはソフトウェアとハードウェアとの任意の組合せで実施できる。たとえば、ASIC208、メモリ212、API210およびローカルデータベース214をすべて協働的に使用して、本明細書で開示する様々な機能をロード、記憶および実行することができ、したがってこれらの機能を実行する論理を様々な要素に分散することができる。あるいは、機能を1つの個別構成要素に組み込むことができる。したがって、図3のUE200の特徴は、単に例示にすぎないものと見なされ、本発明は、示された特徴または構成に限定されない。
【００３０】
UE102またはUE200とRAN120との間のワイヤレス通信は、たとえば符号分割多元接続(CDMA)、WCDMA(登録商標)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交周波数分割多元(OFDM)、Global System for Mobile Communications (GSM(登録商標))、またはワイヤレス通信ネットワークもしくはデータ通信ネットワークで使用され得る他のプロトコルなど、異なる技術に基づき得る。たとえば、WCDMA(登録商標)では、データ通信は、一般的に、クライアントデバイス102、ノードB124、およびRNC122の間である。RNC122は、コアネットワーク126、PSTN、インターネット、仮想専用ネットワーク、SGSN、GGSNなど複数のデータネットワークに接続することができ、したがって、UE102またはUE200は、より広い通信ネットワークにアクセスすることができる。上記で説明し、当技術分野で知られているように、ボイス送信、および/またはデータは、様々なネットワークおよび構成を使用してRANからUEに送信することができる。したがって、本明細書で提供する例は、本発明の実施形態を限定するためのものではなく、単に本発明の実施形態の態様の説明を助けるためのものにすぎない。
【００３１】
以下、本発明の実施形態は、全般的に、WCDMA(登録商標)プロトコルおよび関連する用語に従って説明される(たとえば、移動局(MS)、モバイルユニット(MU)、アクセス端末(AT)などの代わりにUE、EV-DOでのBSCとは異なりRNC、EV-DOでのBSまたはMPT/BSとは異なりノードBなど)。しかしながら、WCDMA(登録商標)以外のワイヤレス通信プロトコルとともに本発明の実施形態がどのように適用され得るかを、当業者は容易に諒解されよう。
【００３２】
本発明の実施形態は、グループ通信セッション中の複数のUEの間での座標情報の共有を対象とする。後でより詳しく説明するように、所与のユーザが自分のUEと対話するとき、そのUEは、UEのディスプレイ上の、所与のユーザについての少なくとも1つの特定の当該点を判定する。たとえば、特定の当該点は、所与のユーザの指がタッチしている、UEのタッチスクリーンディスプレイ上の場所に対応し得る。別の例では、所与のユーザがタッチスクリーンディスプレイの複数の場所をタッチしている(たとえば、「マルチタッチ」)場合、複数の特定の当該点をUEによって検出することができる。別の例では、特定の当該点は、UEが(たとえば、マウスまたはタッチパッドインターフェースにより)カーソルを動かし、かつ/またはクリックした、UEのディスプレイ上の場所に対応し得る。別の例では、特定の当該点は、ユーザによる、UEのディスプレイのタッチと、ユーザがタッチしているディスプレイの位置の移動の組合せ(たとえば、「タッチアンドドラッグ」)とに基づき得る。
【００３３】
図4Aは、本発明の実施形態による、当該点を示す座標情報が複数のUEの間で共有されるための、複数のUEの間のサーバ調停型グループ通信セッションをセットアップするプロセスを示す。
【００３４】
図4Aを参照すると、所与のUE(「UE1」)が、少なくともUE2およびUE3を含む所与の通信グループとの座標共有グループ通信セッションの開始を決定すると仮定する。したがって、UE1は、400Aで、グループ通信セッションを開始するための要求を、RAN120を介してアプリケーションサーバ170に送信する。ある例では、400Aのセッション開始要求は、グループ通信セッションに参加しているUEの各々において何らかの方法で表示されるメディアコンテンツに関連付けられ得る。たとえば、セッション開始要求は、グループ通信セッション中に表示されるべき特定の地図、または様々なメディアコンテンツに関連付けられた特定のビデオゲーム(たとえば、複数のレベルや「ダンジョン」など)を指定することができる。
【００３５】
アプリケーションサーバ170は、UE1からセッション開始要求を受信し、所与の通信グループに属す目標UE(すなわち、UE2およびUE3)を識別および位置特定し、次いで、405Aで、所与の通信グループにグループ通信セッションを告知する。図4Aの実施形態において、UE2とUE3の両方が、アプリケーションサーバ170から告知メッセージを受信し、告知されたグループ通信セッションの受諾を決断し、その結果、410Aおよび415Aで、UE2およびUE3が、受諾を示す肯定応答(ACK)メッセージをアプリケーションサーバ170に送ると仮定する。
【００３６】
この点において、アプリケーションサーバ170は、グループ通信セッションが始まり得るとUE1〜3に命令し、420A、425Aおよび430Aで、UE1〜3の各々が、グループ通信セッション中にUE1〜3のユーザが対話することになるメディアコンテンツの所与の視覚表現を表示する。たとえば、メディアコンテンツは、地図に対応してよく、地図の所与のバージョンが、UE1〜3の各々に表示され得る。ただし、地図のケースでは、異なる地図および/または同じ地図の異なる表現が、それぞれのUEにおいて表示され得る。たとえば、UE1のディスプレイが、UE2のディスプレイよりも高い解像度が可能である場合、地図は、それぞれのUEの各々において、最も高い実際の解像度で表示され得る。別の例では、グループ通信セッションは、何らかのタイプのゲームセッションに対応してよく、メディアコンテンツは、ゲームの「レベル」に対応し得る。この場合、レベルは、それぞれのUEにおいてほぼ同じに見え得るが、やはり微妙な違いがあってよく、たとえば、特定のUEのユーザが、自分のスコアを、他のユーザのスコアよりも目立つように表示させる。
【００３７】
別の例では、UE1は、メディアコンテンツ(たとえば、Google、Bing、MapquestまたはNavteqなどによって地図を生成するための経度および緯度情報)を、所与のUEから他の参加UEに「プッシュする」ことができる。さらに別の例では、メディアコンテンツは、UE1のユーザによって選択され、メディアコンテンツの視覚表現の上にオーバーレイされるモダリティに関連付けられ得る。たとえば、モダリティは、選択され、次いで、グループ通信セッションの参加UEの間で共有され得る選択可能なタッチ点(または座標)の配置に対応し得る。メディアコンテンツに関連付けられたモダリティは、UE1および/または他のUEのうちの1つからの入力に基づいて、グループ通信セッション中に変化し得ることが諒解されよう。さらに、タッチ点のうちの1つまたは複数は、UE1(または別のUE)によって選択的に有効または無効にすることができ、そうすることによって、異なるタッチ点(または座標)が、グループ通信セッション中の異なるときに、参加UEによる選択に使用可能である。
【００３８】
代替実施形態では、図4Aのグループ通信セッションは、UE1のユーザが、たとえば、UE1にあるカレンダイベント中で実施される(たとえば、2010年12月4日土曜日の太平洋標準時8:50AMと9:00AMとの間に開始する)経路地図(たとえば、音声ノート、写真、リンクおよび/またはジオフェンスもしくはビーコンで注釈を付けられた)のうちの1つまたは複数に関連付けられたPLANボタン(たとえば、ユーザグループが2つ以上の場所の間の行き来を調整するための移動イベントなどのイベントを引き起こすように構成されたボタン)をプッシュしたときに引き起こされ得る。この場合、PLAN(およびその関連情報)は、グループ通信セッションのセットアップ中にUE1からUE2〜3に伝えられ得る。UE2〜3には、ACCEPT、DECLINEおよびMODIFY選択肢が与えられ得る。図4Aでは、UE2〜3は、UE1によって設定されたようにグループ通信セッションを単に受諾すると仮定されるが、このことが常に成り立つ必要はなく、グループ通信セッションの条件が確定される前に、セッション交渉手順が起こり得ることが諒解されよう。
【００３９】
PLANを受諾した後、開始ウィンドウ(たとえば、8:45〜9AM)中に、発信者/イニシエータ(すなわち、UE1)は、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のユーザは各々、それぞれのディスプレイ上の視覚表現の特定の点を選択する(たとえば、タッチし、クリックし、または指す)ことができる。地図のケースでは、ユーザは、たとえば、地図上に表示された特定の建物を選択し得る。ゲームのケースでは、ユーザは、アイテム、キャラクタ(たとえば、「ウォーリーを探せ(Where's Waldo)」というゲームでのウォーリーの居場所)などのような、視覚表現上の当該点を選択し得る。
【００４２】
ある例では、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を参照すると、選択座標(たとえば、それぞれ、UE1〜3において選択が行われた位置)を含めることに加え、450A、455Aおよび460Aで送信される1つまたは複数の座標パケットは、それぞれ、435A、440Aおよび445Aからのユーザ入力または選択の再構築を許可し、または容易にするための提示再構築パラメータセットをさらに含み得る。たとえば、UE1〜3は各々、通信セッション中に、異なるズームレベル(すなわち、異なる閲覧エリア)でニューヨーク市の地図を提示中であり得る。この場合、提示再構築パラメータセットは、単に対応するスクリーン位置ではなく、地図に相対した適切な位置での、目標UEにおけるユーザ選択の再構築を許可する。別の例では、UE1は、その座標選択が、変化なしでUE2において提示され得るが、その座標選択が、UE3における所与の視覚表現(たとえば、この場合、地図)の閲覧エリアの外である(たとえば、UE3の現在の閲覧エリアに関連した、アプリケーションサーバ170および/またはUE3からのフィードバックに基づいて)と検出し得る。この検出に応答して、提示再構築パラメータセットは、UE3が、UE1の選択座標の提示を許可するように、地図のその閲覧エリアを調整し、または配向し直すための要求を含み得る。
【００４６】
依然として図4Aの450A〜460Aを参照すると、別の例では、UE1は、ビデオコンテンツをフルスクリーンで提示中であってよく、UE2は、フルスクリーンではなく、スクリーン表示の小さい部分で、ビデオコンテンツを提示中であり得る。この場合、UE2は、提示再構築パラメータを送ることができ、そうすることによって、ビデオコンテンツに相対して選択座標が小さい部分においてどこに位置決めされたかについての指示とともに、選択座標が伝えられる。したがって、UE2のスクリーンの右下部分は、通信セッションに関連付けられたビデオコンテンツを表示しており、選択座標は、その部分の左上側であると仮定する。この場合、目標UEにおいて再提示されると、提示再構築パラメータは、目標UEに、選択座標を、視覚表現に専用の左上セクション(UE2からの絶対スクリーン位置に基づく右下スクリーンセクションではなく)に表示するよう命令することができる。
【００４７】
依然として図4Aの450A〜460Aを参照すると、別の実施形態では、これらの座標パケット送信のうちの1つまたは複数は、任意選択でよい。たとえば、UE1〜3は各々、435A、440Aおよび445Aで、それぞれ、少なくとも1つの座標選択に対応するユーザ入力を受信すると仮定する。ただし、UE1は、その座標選択が、UE2および/またはUE3における所与の視覚表現の提示と競合すると判断すると仮定する。たとえば、UE1は、その座標選択が、UE2および/またはUE3における所与の視覚表現の閲覧エリアの外であることを検出し得る。この場合、閲覧エリア調整命令を提示再構築パラメータセットにパッケージ化するのではなく、UE1は、競合検出に応答して、その座標パケットを送るのを控えるだけでよい。別の例では、UE1は、その座標選択を、それぞれの閲覧エリアにかかわらず、UE2および/またはUE3において表示することができないことを検出し得る(たとえば、UE2および/またはUE3はもはや、スクリーン上に所与の視覚表現を提示中ではあり得ないので、UE1の座標選択は適切でない、など)。この場合、UE1は、競合検出に応答して、その座標パケットを送るのを控えるだけでよい。
【００４８】
依然として図4Aの450A〜460Aを参照すると、別の実施形態では、選択座標のうちの1つまたは複数は、競合検出に応答して修正され得る。したがって、UE1〜3は各々、435A、440Aおよび445Aで、それぞれ、少なくとも1つの座標選択に対応するユーザ入力を受信すると仮定する。ただし、UE1は、その座標選択が、UE2および/またはUE3における所与の視覚表現の提示と競合すると判断すると仮定する。たとえば、UE1は、その座標選択が、UE2および/またはUE3における所与の視覚表現の閲覧エリアの外であることを検出し得る。この場合、閲覧エリア調整命令を提示再構築パラメータセットにパッケージ化し、または座標パケットの送信を完全に回避する代わりに、UE1は、そうではなく、座標選択を修正すればよい。たとえば、UE1のユーザが、UE2およびUE3の閲覧エリアの外の座標位置を選択した場合、選択された座標は、UE2およびUE3の閲覧エリア内の位置に動かしてよい(たとえば、UE1のユーザは、UE2およびUE3において表示されるにはあまりにも左寄りの位置を選択し、修正は、UE2および/またはUE3の閲覧エリアの範囲内にちょうど入るように水平スクリーン位置をさらに右にシフトしながら、座標の垂直スクリーン位置を維持することに対応する)。
【００４９】
依然として図4Aの450A〜460Aを参照すると、別の実施形態では、450A〜460Aの間での、座標パケットのうちの1つまたは複数の送信は、トークスパートとともに送信され得る。本実施形態では、座標パケットは、いくつかのオーバージエア(OTA)送信を削減するように、トークスパートパケットに組み込み、またはピギーバックすることができる。
【００５０】
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マルチキャスティングまたはブロードキャスティングプロトコル(たとえば、図8および図10Bを参照して後でより詳しく論じる)を介して、同じ、すなわち共通の出力フレームが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に向けられた座標出力フレームを調整すればよい(たとえば、UE1の選択座標を省き、UE1の選択座標を修正し、UE2に座標出力フレームとともに送信される提示再構築パラメータセットを、UE2の閲覧エリアを再配向または調整するための命令を含むように設定する、など)。したがって、それぞれのUEにおいて生成される提示再構築パラメータセットに関して上で論じた各例は、代わりに、本実施形態におけるアプリケーションサーバ170に引き継がれ得る。
【００５５】
図4Aを参照すると、UE1〜3の各々が、アプリケーションサーバ170から出力フレームを受信する。受信した出力フレームに基づいて、UE1〜3は各々が、490A、493Aおよび496Aで、それぞれのディスプレイにおけるメディアコンテンツの視覚表現を、受信した出力フレームによって示される他のUEの座標を反映するように更新する。上述したように、出力フレームは、提示再構築パラメータセットとともに、座標のうちの1つまたは複数が、受信側UEにおける視覚表現に対する更新に反映される方法を制御するように構成されたUE1〜3において受信され(たとえば、ソースUEおよび/またはアプリケーションサーバ170において生成され)得る。さらに、たとえば、図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に返送され得る(たとえば、目標UE自体またはアプリケーションサーバ170のどちらかによって)。したがって、UE1は、UE2およびUE3が、その視覚表現を、UE1の報告座標に基づいて(493Aおよび496Aで)更新済みであるという肯定応答などを受信し得る。
【００５７】
図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マルチキャスティングまたはブロードキャスティングプロトコル(たとえば、図8および図10Bを参照して後でより詳しく論じる)を介して、同じ、すなわち共通の出力フレームが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つもしくは複数は、(たとえば、特定の座標選択のためのソースUEまたはアプリケーションサーバ170自体において生成された)提示再構築パラメータセットとともに送られ得る。あるいは、それぞれ、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(「UE1〜N」)から受信すると仮定することができる。図8を参照して後で論じるいくつかの例外はあるが、特定の座標受信期間中に受信される座標パケットは、その特定の座標受信期間に、出力フレームセットに投入するのに使われるデータを与える。グループ通信セッションに参加しているUEは、各座標受信期間に、座標パケットを与えることを試みる。言い換えれば、図4AのUE1〜3は、送信された座標パケットがアプリケーションサーバ170において同じ座標受信期間内に受信されるように、450A〜460Aの送信を同期させることを試みる。
【００６７】
したがって、600で、アプリケーションサーバ170は、初期または次の座標受信期間に対する座標受信タイマを始動させる。この点において、座標受信期間の満了期間は、デフォルトまたは初期長(たとえば、200ms、300msなど)にセットされる。次に、アプリケーションサーバ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つまたは複数の出力フレームに関しては選択的に省き、または修正することができる(たとえば、選択座標は、目標UEのスクリーンまたは閲覧エリアに合うように修正することができ、目標UEに適合しない選択座標は、除外し、または省くことなどができる)。これらの態様も、後でより詳しく論じる図7A〜図7Cに該当する。
【００７０】
図7Aから図7Cまでは、それぞれ、図6のプロセスのより詳細な実装例を示す。
【００７１】
図7Aを参照すると、図4Aのグループ通信セッションのセットアップ中に、またはそれに先立って、アプリケーションサーバ170は、700Aで、UE1〜Nの各々に関連付けられた優先レベルを判断する(たとえば、図4Aでは、N=3)。後のどこかの時点で、アプリケーションサーバ170は、705Aで、次の座標受信期間に対する座標受信タイマを始動させる(たとえば、図6の600でのように)。この時点で、座標受信期間の満了期間は、デフォルトまたは初期長にセットされる。次に、アプリケーションサーバ170は、710Aで、UE1〜Nからの座標情報を含む座標パケットを監視する(たとえば、図6の605でのように)。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の各々に関連付けられた優先レベルを判断する(たとえば、図4Aでは、N=3)。後のどこかの時点で、アプリケーションサーバ170は、705Bで、次の座標受信期間に対する座標受信タイマを始動させる(たとえば、図6の600でのように)。この時点で、座標受信期間の満了期間は、デフォルトまたは初期長にセットされる。次に、アプリケーションサーバ170は、710Bで、UE1〜Nからの座標情報を含む座標パケットを監視する(たとえば、図6の605でのように)。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つまたは複数に関連付けられたハンディキャップを判断する(たとえば、図4Aでは、N=3)。たとえば、UE1およびUE2は各々が、比較的高速ネットワークに接続され(たとえば、有線接続、WiFiや4Gなどの高速ワイヤレス接続)、そうすることによって、アプリケーションサーバ170との接続に関して、待ち時間が比較的低いと仮定する。対照的に、UE3は、比較的遅いネットワークに接続されると仮定する。この場合、アプリケーションサーバ170は、少なくともUE3にハンディキャップを適用してよく、そうすることによって、UE3の座標パケットがアプリケーションサーバ170に到着するのが遅いケースでは、より多くの時間が、座標受信期間に選択的に割り振られる。代替例では、ハンディキャップは、UE1〜Nの中の所与のUEにサービングしているアクセスポイント(AP)のパイロット強度に基づいて判断することができる(たとえば、より大きいハンディキャップが、たとえば、低いパイロット強度をもつUEに割り振られることになる)。別の代替例では、ハンディキャップは、UE1〜Nの中の所与のUEと、所与のUEにサービングしているアクセスポイント(AP)との間の距離に基づいて判断することができる(たとえば、より大きいハンディキャップが、たとえば、そのサービングAPからの距離が比較的大きいUEに割り振られることになる)。別の代替例では、ハンディキャップは、アプリケーションサーバ170への座標パケット到着についての各UEの過去のパフォーマンスに基づいて判断することができる。この場合、通常はそれぞれの座標受信期間内にその座標パケットを比較的遅く与えているUEに、比較的高いハンディキャップを割り振ることができる。
【００７８】
図7Cの700Cを参照すると、アプリケーションサーバ170が特定のUEについて座標受信期間を延長する度合(たとえば、50msの延長、150msの延長など)は、ハンディキャップの規模に、また、二次的考察に基づき得る(たとえば、グループ通信セッションにおけるUEのほとんどが高速接続を有する場合、異常値UEへのハンディキャップは、あまり重みを与えられないので、セッションは、UEのほとんどに対して、望ましくない程遅くはならない)。
【００７９】
UE1〜Nのうちの1つまたは複数についてハンディキャップが判断された後のどこかの時点で、アプリケーションサーバ170は、705Cで、グループ通信セッション中の次の座標受信期間に対する座標受信タイマを始動させる(たとえば、図6の600でのように)。この時点で、座標受信期間の満了期間は、デフォルトまたは初期長にセットされる。次に、アプリケーションサーバ170は、710Cで、UE1〜Nからの座標情報を含む座標パケットを監視する(たとえば、図6の605でのように)。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の実施形態に基づいて延長し(たとえば、高優先度UEからの座標パケットの遅い到着)、次いで、図7Cの実施形態に基づいてさらに延長してもよい(たとえば、ハンディキャップ付きUEからの座標パケットの遅い到着)。あるいは、座標受信期間は、図7Aの実施形態に基づいて短縮してもよく(たとえば、高優先度UEからの座標パケットの早い到着)、次いで、同じ座標受信期間は、図7Cの実施形態に基づいて延長してもよい(たとえば、ハンディキャップ付きUEからの座標パケットの遅い到着)。
【００８３】
所与のグループ通信セッションの1つまたは複数の座標受信期間に、アプリケーションサーバ170において出力フレームを生成する例示的実装形態について、図8〜図10Bを参照して次に説明する。具体的には、図8の全体が、図6の615の例示的な一実装形態に対応する(たとえば、それぞれ、図7A、図7Bおよび/または図7Cの730A、730Bおよび/または730C)。図9A〜図10Bは、例示的実施形態による、図8のプロセス中に起こり得るデータ操作の例を示す。
【００８４】
図8を参照して、1組のUE1〜5の間でのグループ通信セッション中に、4つの重ならない期間T1〜T4が経過し、ここでT1は、T2と比較して、時間的により早く、T2は、T3と比較して、時間的により早く、以下同様であると仮定する。図8を説明する目的で、期間T1〜T4中の、UE1〜5における選択座標(たとえば、図4Aの435A〜445Aおよび/または図4Bの400B〜410Bで、UE1〜5において検出された)が、図9Aに示すテーブルに対応するとさらに仮定され得る。たとえば、T1で、UE1のユーザは、座標(3,3)に対応する位置で、UE1のディスプレイにタッチしており、UE2のユーザは、座標(6,9)に対応する位置で、UE2のディスプレイにタッチしており、以下同様である。さらに、T2で、UE2が所与の非同期イベントを検出すると同時に、UE4が、座標(4,7)に対応する位置を選択しているものとして示されている。
【００８５】
いくつかの理由により、図9Aのテーブルに示す初期座標選択に基づいて、アプリケーションサーバ170において受信された座標パケットは、必ずしも完璧に同期されるわけではないことが諒解されよう。たとえば、UE1〜5のうち異なるものを、異なる待ち時間をもつネットワークに接続することなどができる。したがって、図9B〜図9Dは、それぞれ、T1、T2およびT3に対応する座標受信期間中にアプリケーションサーバ170において受信された座標パケットの例を示すテーブルを示す。図9B〜図9Dにおいて、それぞれのテーブルの「より低い」セル中に示される座標(または座標情報)は、座標受信期間中に比較的早く受信された座標パケットを表し、それぞれのテーブルの「より高い」セル中に示される座標は、座標受信期間中に比較的後で受信された座標パケットを表す。図9B〜図9Dには明示的に示さないが、図に示す座標受信期間のうちどの期間の持続時間も、図7A〜図7Cのうちの1つまたは複数の図の実施形態によって延長および/または短縮されている可能性がある。
【００８６】
図9Bを参照すると、T1に対応する座標受信期間中に、座標(4,4)の選択を含む、UE3の座標パケットが、「消去」として列挙される。これは、UE3が、その座標に、特定の座標受信期間中に更新を与えることができなかったことを意味する(たとえば、UE3の座標パケットは、たとえば、ネットワーク待ち時間または他の理由により、座標受信期間中に比較的遅く受信された)。また、図9Cを参照すると、T2に対応する座標受信期間中に、座標(4,7)の選択を含む、UE4の座標パケットが、非同期指示と関連付けて列挙される(たとえば、非同期イベントについては、図8の820を参照して下でより詳しく説明する)。さらに、図9Dを参照すると、T3に対応する座標受信期間中に、UE3は、座標(5,5)と(6,4)の両方の選択を含む2つの別々の座標パケットを与えるものとして示されており、(5,5)に対応する座標パケットは、(6,4)に対応する座標パケットの前に受信されている。図9Aの検討から、座標パケット(6,4)は、T3ではなくT4についての座標受信期間に関連付けられたことが意図されていたことが諒解されよう。言い換えれば、座標(6,4)に対応する、UEの座標パケットは、早く受信された(「早期パケット」)。アプリケーションサーバ170が、消去パケット、非同期座標パケットおよび/または早期座標パケットを扱うように構成され得る方法の例については、図8を参照して後でより詳しく論じる。
【００８７】
図8を参照すると、アプリケーションサーバ170は、(たとえば、図9B、図9Cまたは図9Dに示すように)所与の座標受信期間中に受信した座標パケットを評価し、800で、UE1〜Nのいずれかから複数の座標パケットが受信されたかどうか判断する。図8の実施形態では、参加UEごとにただ1つの座標パケットが期待されると仮定される。ただし、他の実施形態(たとえば、ユーザが、UEのディスプレイの様々な位置を同時にタッチしている可能性があるマルチタッチ実施形態など)は、単一の座標受信期間中に複数の相異なる座標が選択され得るシナリオを対象とし得ることが諒解されよう。マルチ座標シナリオでは、図8の800が、特定の座標受信期間に関して「重複」座標選択が受信されているかどうか評価するように、相異なる各座標選択を別々に検討してよい。
【００８８】
図8の800で、特定のUEについて複数の座標パケットが受信されたとアプリケーションサーバ170が判断した場合、アプリケーションサーバ170は、複数の座標パケットのうちの1つまたは複数が、「早期」パケットに対応すると推論する。図9Aは、座標(6,4)がT4まで、アプリケーションサーバ170において受信済みであるはずがないことを示すので、図9Dにおいて、座標(6,4)に対応するUE3からの座標パケットは、早期パケットである。したがって、どの座標パケットが早期パケットであるか判断した後、アプリケーションサーバ170は、805で、現在の座標受信期間に関して出力フレームから早期パケットが除外されるように、早期パケットをドロップする。図8には明示的に示さないが、アプリケーションサーバ170は、任意選択で、ドロップした座標パケットを、次の座標受信期間に「プッシュ」することができ、そうすることによってアプリケーションサーバ170は、図8のプロセスの次の実行中に、ドロップした早期パケットからの座標を追加するかどうか検討することができる。
【００８９】
図8を参照すると、アプリケーションサーバ170は、810で、いずれかの消去パケットが、(i)現在の座標受信期間または(ii)以前の座標受信期間中に受信されているかどうか判断する。以前の座標受信期間中に消去パケットが受信されたとアプリケーションサーバ170が判断した場合、アプリケーションサーバ170は、消去パケットに含まれる座標を、現在の座標受信期間用の出力フレームに挿入すると決断し、それによって、これらの座標は以前の出力フレームで送信済みであるはずなので、815で、挿入される座標には、「置換」座標状況を示すようにフラグが立てられる。また、現在の座標受信期間中に消去パケットが受信されたとアプリケーションサーバ170が判断した場合、アプリケーションサーバ170は、815で、出力フレームの目標UEが、次の座標受信期間用の出力フレーム中の置換座標を予想するための告知に載せられるように、(消去パケットの座標をもたない)消去インジケータを、現在の座標受信期間用の出力フレームに挿入すると決断する。
【００９０】
図8を参照すると、820で、アプリケーションサーバ170は、現在の座標受信期間中に、UE1〜Nのうちの1つまたは複数によっていずれかの非同期イベントが報告されたかどうか判断する。非同期イベントは、座標選択とは別個の、グループ通信セッションに参加しているUEのうちの1つのUEの所与のユーザによって行われたアクションに対応する。非同期イベントの報告は、それにより、座標パケットに含まれる座標情報に関して、別個または追加データに対応するが、同じ座標パケット内で(たとえば、座標パケットの修正されたヘッダーまたはペイロード部分により)非同期イベントが報告され得ることが可能である。一例として、グループ通信セッションは、何らかのタイプの格闘ゲームに対応すると仮定する。次いで、図9AのT2で、UE4のユーザは、座標(4,7)を選択し、同時に格闘アクション(たとえば、パンチ、キック、発砲など)を選択するという、両方を行うと仮定する。この場合、座標(4,7)は上述したように報告され、この座標は、関連アクション(または非同期イベント)の指示とともに与えられる。この具体例において、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は、(6,3)という、それ自体が報告した座標を、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から、アーカイブされたセッションデータをロードする。上述したように、アーカイブされたセッションデータは、(i)終了グループ通信セッション中にUEに送信された生成出力フレーム、および/または(ii)終了グループ通信セッション中にUEから受信され、出力フレームを生成するのに使われた「未加工」座標データを含み得る。アプリケーションサーバ170が、未加工座標データのみをアーカイブした場合、アプリケーションサーバ170は、1125Aで、終了グループ通信セッションの第1の座標受信期間に対する、UE1向けの出力フレームを再生成する。あるいは、アプリケーションサーバ170が、終了グループ通信セッション用の生成出力フレームをアーカイブした場合、1125Aの再生成はスキップしてよく、アーカイブされた出力フレームを使えばよい(たとえば、終了グループ通信セッション中に、以前UE1に送られた、アーカイブされた出力フレーム)。
【００９７】
いずれのケースでも、終了グループ通信セッションの第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(「UE X」)がグループ通信セッションに加わると判断したとき、グループ通信セッションが進行中またはアクティブであると仮定する。この時点で、UE Xのユーザには、1105Bで、UE Xのユーザが逃した、グループ通信セッションのより早期の部分を単に無視するかどうか、またはグループ通信セッションのより早期の部分をリプレイするかどうかについての選択肢が与えられる。1105Bで、UE Xのユーザが逃した、グループ通信セッションのより早期の部分を無視するとUE Xのユーザが判断した場合、プロセスは、直接1150Bに進み、UE Xは、グループ通信セッションへのアクティブ参加を始める。あるいは、UE Xのユーザが、1105Bで、グループ通信セッションのより早期の部分をリプレイすると判断した場合、UE Xは、1110Bで、「キャッチアップ」モードでグループ通信セッションに加わるための要求を送信し、それによって、グループ通信セッションのより早期の部分が、UE1〜3にUE XがキャッチアップするまでUE Xに対して高速(たとえば、2倍の速度、3倍の速度など)でリプレイされる。
【０１００】
UE Xは、1115Bで、終了グループ通信セッションに関連付けられた、メディアコンテンツの初期視覚表現を表示することによって、リプレイセッションを開始する。たとえば、UE Xは、1115Bで、表示されるメディアコンテンツを、キャッチアップセッションのセットアップ中にアプリケーションサーバ170から受信することができ、あるいは、UE Xは、メディアコンテンツを有して事前構成することができ、このメディアコンテンツを、アプリケーションサーバ170がキャッチアップセッション用のアーカイブセッションデータを準備している間にロードすることができる。
【０１０１】
アプリケーションサーバ170は、1120Bで、アーカイブデータベース186から、アーカイブされたセッションデータをロードする。上述したように、アーカイブされたセッションデータは、(i)終了グループ通信セッション中にUEに送信された生成出力フレーム、および/または(ii)終了グループ通信セッション中にUEから受信され、出力フレームを生成するのに使われた「未加工」座標データを含み得る。アプリケーションサーバ170が、未加工座標データのみをアーカイブした場合、アプリケーションサーバ170は、1125Bで、終了グループ通信セッションの第1の座標受信期間に対する、UE Xのための出力フレームを再生成する。あるいは、アプリケーションサーバ170が、終了グループ通信セッション用の生成出力フレームをアーカイブした場合、1125Bの再生成は、可能性としてはスキップしてもよく、アーカイブされた出力フレームを使えばよい。1125Bで再生成された出力フレームが、IPユニキャスティングプロトコルにより、より早期にUE1〜3に送信される場合、これらのフレームは、より早期の送信に関連付けられた、その目標UEを省いている可能性があることが諒解されよう。ただし、UE Xに送られる出力フレームは、UE1〜3の各々からの座標を含む。また、1125Bで再生成された出力フレームが、IPマルチキャスティングプロトコルにより、UE1〜3により早期に送信された場合、これらのフレームは、IPユニキャスティングプロトコルによりUE Xに送信され得ることが諒解されよう(グループ通信セッションにおける他のUEは、キャッチアップモードで動作中ではなく、キャッチアップ出力フレームを受信中にはならないので)。
【０１０２】
いずれのケースでも、アクティブグループ通信セッションの第1の座標受信期間に対応する、UE X向けの出力フレームは、1130Bで、アプリケーションサーバ170によってUE Xに送られる。1130Bでの受信出力フレームに基づいて、UE Xは、1135Bで、そのディスプレイにおけるメディアコンテンツの視覚表現を、受信出力フレームによって示される他のUEの座標を反映するように選択的に更新する。この点において、1130Bおよび1135Bは、リアルタイムよりも高いレート(たとえば、2倍の速度、3x倍の速度など)で繰り返し、その結果UE Xは、UE1〜3に時間内にキャッチアップする間に、グループ通信セッションのアーカイブ部分を閲覧する。UE Xが「リアルタイム」の状況に近づくと、アプリケーションサーバ170は、1140Bで、UE Xをキャッチアップモードから、およびアクティブモードに遷移させると判断し、アクティブモードでは、UE Xは、それ自体の座標を、グループへの送信用にアプリケーションサーバ170に送ることを許可される。
【０１０３】
この時点で、アプリケーションサーバ170は、1145Bで、UE Xに、キャッチアップモードから、およびアクティブモードへのその遷移を通知し、UE Xは、1150Bで、UE Xにおけるディスプレイ上の視覚表現の少なくとも1つの座標の選択を示す、UE Xのユーザからのユーザ入力の受諾を始める。図11Bには明示的に示さないが、座標選択は、UE1〜3においても起こる(UE1〜3における座標選択は、暗黙的に図11B全体を通して起こる)。
【０１０４】
UE1〜3およびUE Xの各々における選択座標を判断した後、UE1〜3およびUE Xは、各々、1155B、1160B、1165Bおよび1170Bで、選択座標をアプリケーションサーバ170に送信する。アプリケーションサーバ170は、所与の座標受信期間内にUE1〜3およびUE Xから座標を受信し、1175Bで、UE1〜3およびUE Xの各々への送信用の出力フレームを生成する。1175Bで出力フレームを生成した後、アプリケーションサーバ170は、1180Bで、生成した出力フレームをUE Xに送信する。図11Bに明示的に示さないが、アプリケーションサーバ170は、出力フレームをUE1〜3に送ってもよい。また、UE Xは、現在またはUE1〜3と同時期のセッションにはないので、1180BでのUE Xへの出力フレームの送信は、通常レートで(たとえば、リアルタイムに)起こる。
【０１０５】
さらに、図11Bは、グループ通信セッションへの遅れた参加者(UE X)が、アプリケーションサーバ170による早送り型動作に基づいて、他の参加UEに「キャッチアップ」するのを許可されるための実装形態を対象とするが、図11Bは、UE Xが、1100Bに先立って、すでにグループ通信セッションへの参加者であったシナリオにも同様に適用され得ることが諒解されよう。たとえば、UE Xが、図4Bのプロセス中に、グループ通信セッションへの別の参加UEであったと仮定する。次いで、後のどこかの時点で、UE Xは、アプリケーションサーバ170への接続を失う。たとえば、UE XなどのUEが、アプリケーションサーバ170から「切断」されることは、UEが、閾値期間だけ座標パケットを与えていない(たとえば、UEのバッテリが消耗しており、UEが、RAN120への接続を失っている、などにより)ことを意味する。この場合、1100Bの判断は、UE Xがアプリケーションサーバ170への接続を回復した後、グループ通信セッションに再度加わるという判断に対応し得る。この時点で、アプリケーションサーバ170は、UE3がその切断期間中に逃したグループ通信セッション部分を、早送りまたはキャッチアップモードなどでリプレイし始めてよい。したがって、図11Bのキャッチアップモード例は、グループ通信セッションへの「新規」または遅れた参加者に適用可能であるだけではなく、むしろ、グループ通信セッションの一部または全部を逃した可能性があるどのUEにも適用可能である。
【０１０６】
さらに、上で論じた「切断」シナリオは、グループ通信セッションが、切断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つまたは複数の出力フレームに関しては選択的に省き、または修正することができる(たとえば、選択座標は、目標UEのスクリーンまたは閲覧エリアに合うように修正することができ、目標UEに適合しない選択座標は、除外し、または省くことなどができる)。
【０１０８】
本発明の上述の実施形態は、通信セッションを調停し、座標パケットの交換を仲介するものとして、アプリケーションサーバ170を開示するが、本発明の他の実施形態は、UEホスト型またはUE調停型座標共有セッションを対象とし得る。本実施形態では、セッションを調停するUEはサーバとして作用し、図6〜図8のプロセスは、アプリケーションサーバ170ではなくUEサーバによって実装される。本実施形態では、図4Aにあるアプリケーションサーバ170の機能性は、たとえば、図4Aに示す例からのいくつかの実装変化を結果的に生じる座標共有に参加しているUEのうちの1つに移される(たとえば、UE1が、セッション用の調停者として作用している場合、UE1は、何らかの外部のエンティティに座標パケットを送る必要はなく、その代わり、他のUEから座標パケットを受信し、UE1自体の座標データ直接を座標出力フレームにパッケージするだけなどでもよい)。同様の変化が、当業者には理解されるように、UEサーバ実装にも対応するように、他の実施形態を通して実装され得る。
【０１０９】
図12は、機能性を実施するように構成された論理を含む通信デバイス1200を示す。通信デバイス1200は、UE102、108、110、112または200、ノードBまたは基地局1244、RNCまたは基地局コントローラ122、パケットデータネットワークエンドポイント(たとえば、ロングタームエボリューション(LTE)におけるSGSN160、GGSN165、移動管理エンティティ(MME)など)、サーバ170〜186のうちいずれかなどを含むがそれに限定されない、上述の通信デバイスのいずれにも対応し得る。したがって、通信デバイス1200は、ネットワークを介して1つまたは複数の他のエンティティと通信する(または通信を容易にする)ように構成されたどの電子デバイスにも対応し得る。
【０１１０】
図12を参照すると、通信デバイス1200は、情報を受信および/または送信するように構成された論理1205を含む。ある例では、通信デバイス1200が、ワイヤレス通信デバイス(たとえば、UE200、ノードB124など)に対応する場合、情報を受信および/または送信するように構成された論理1205は、ワイヤレストランシーバおよび関連ハードウェア(たとえば、RFアンテナ、モデム、変調器および/または復調器など)などのワイヤレス通信インターフェース(たとえば、ブルートゥース、WiFi、2G、3Gなど)を含み得る。別の例では、情報を受信および/または送信するように構成された論理1205は、ワイヤード通信インターフェース(たとえば、インターネット175にアクセスし得るための直列接続、USBまたはファイアワイヤ接続、イーサネット(登録商標)接続など)に対応し得る。したがって、通信デバイス1200が、何らかのタイプのネットワークベースのサーバ(たとえば、SGSN160、GGSN165、アプリケーションサーバ170など)に対応する場合、情報を受信および/または送信するように構成された論理1205は、ある例では、イーサネット(登録商標)プロトコルによりネットワークベースのサーバを他の通信エンティティに接続するイーサネット(登録商標)カードに対応し得る。さらに別の例では、情報を受信および/または送信するように構成された論理1205は、通信デバイス1200がそのローカル環境を監視し得るための知覚または測定ハードウェア(たとえば、ローカルRF信号を監視するための加速度計、温度センサ、光センサ、アンテナなど)を含み得る。情報を受信および/または送信するように構成された論理1205は、実行されると、その受信および/または送信機能を実施するための、情報を受信および/または送信するように構成された論理1205の関連ハードウェアを許可するソフトウェアも含み得る。ただし、情報を受信および/または送信するように構成された論理1205は、ソフトウェア単体に対応するのではなく、情報を受信および/または送信するように構成された論理1205は、その機能性を遂行するためのハードウェアに少なくとも部分的に依拠する。
【０１１１】
図12を参照すると、通信デバイス1200は、情報を処理するように構成された論理1210をさらに含む。ある例では、情報を処理するように構成された論理1210は、少なくともプロセッサを含み得る。情報を処理するように構成された論理1210によって実施することができる処理タイプの例示的実装形態は、判断を実施すること、接続を確立すること、異なる情報選択肢の間での選択を行うこと、データに関連した評価を実施すること、測定動作を実施するための、通信デバイス1200に結合されたセンサと対話すること、ある形式から別の形式に(たとえば、.wmvから.aviなど、異なるプロトコルの間で)情報をコンバートすることなどを含むが、それに限定されない。たとえば、情報を処理するように構成された論理1210に含まれるプロセッサは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または他のプログラマブル論理デバイス、個別ゲートまたはトランジスタ論理、個別ハードウェア構成要素、あるいは本明細書で説明する機能を実行するように設計されたそれらの任意の組合せに相当し得る。汎用プロセッサはマイクロプロセッサであり得るが、別法として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。情報を処理するように構成された論理1210は、実行されると、その処理機能を実施するための、情報を処理するように構成された論理1210の関連ハードウェアを許可するソフトウェアも含み得る。ただし、情報を処理するように構成された論理1210は、ソフトウェア単体に対応するのではなく、情報を処理するように構成された論理1210は、その機能性を遂行するためのハードウェアに少なくとも部分的に依拠する。
【０１１２】
図12を参照すると、通信デバイス1200は、情報を記憶するように構成された論理1215をさらに含む。ある例では、情報を記憶するように構成された論理1215は、少なくとも非一時的メモリおよび関連ハードウェア(たとえば、メモリコントローラなど)を含み得る。たとえば、情報を記憶するように構成された論理1215に含まれる非一時的メモリは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体中に相当し得る。情報を記憶するように構成された論理1215は、実行されると、その記憶機能を実施するための、情報を記憶するように構成された論理1215の関連ハードウェアを許可するソフトウェアも含み得る。ただし、情報を記憶するように構成された論理1215は、ソフトウェア単体に対応するのではなく、情報を記憶するように構成された論理1215は、その機能性を遂行するためのハードウェアに少なくとも部分的に依拠する。
【０１１３】
図12を参照すると、通信デバイス1200はさらに、情報を提示するように構成された論理1220を任意選択で含む。ある例では、情報を提示するように構成された論理1220は、少なくとも出力デバイスおよび関連ハードウェアを含み得る。たとえば、出力デバイスは、ビデオ出力デバイス(たとえば、表示画面、USB、HDMI(登録商標)などのビデオ情報を搬送することができるポートなど)、オーディオ出力デバイス(たとえば、スピーカ、マイクロホンジャックなどのオーディオ情報を搬送することができるポート、USB、HDMI(登録商標)など)、振動デバイスならびに/あるいは情報を出力用にフォーマットし、または通信デバイス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セッションに関して説明されているが、他の実施形態は、たとえばプッシュツートランスファー(PTX)セッション、緊急VoIP呼など、任意のタイプの通信セッションを対象としてもよい。
【０１１７】
情報および信号は、多種多様な技術および技法のいずれかを使用して表すことができることを当業者は諒解されよう。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界または磁性粒子、光場または光学粒子、あるいはそれらの任意の組合せによって表され得る。
【０１１８】
さらに、本明細書で開示した実施形態に関連して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装できることを、当業者は諒解されよう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを、上記では概してそれらの機能に関して説明した。そのような機能をハードウェアとして実装するか、ソフトウェアとして実装するかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装することができるが、そのような実装の決定は、本発明の範囲からの逸脱を生じるものと解釈すべきではない。
【０１１９】
本明細書で開示する実施形態に関して説明する様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタルシグナルプロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、ディスクリートゲートもしくはトランジスタ論理、ディスクリートのハードウェアコンポーネント、または、本明細書で説明する機能を実行するように設計されたそれらの任意の組合せで、実装または実行することができる。汎用プロセッサはマイクロプロセッサであり得るが、別法として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。
【０１２０】
本明細書で開示した実施形態と関連して説明した方法、シーケンス、および/またはアルゴリズムは、ハードウェアで直接実施され得るか、プロセッサによって実行されるソフトウェアモジュールで実施され得るか、またはその2つの組合せで実施され得る。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体中に常駐し得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。あるいは、記憶媒体はプロセッサと一体であり得る。プロセッサおよび記憶媒体はASIC中に常駐し得る。ASICはユーザ端末(たとえば、アクセス端末)中に常駐し得る。あるいは、プロセッサおよび記憶媒体は、ユーザ端末中に個別構成要素として常駐し得る。
【０１２１】
1つまたは複数の例示的な実施形態では、説明した機能はハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装した場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体とコンピュータ通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または、命令もしくはデータ構造の形態の所望のプログラムコードを搬送または記憶するために使用でき、コンピュータによってアクセスできる、任意の他の媒体を含み得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または、赤外線、無線、およびマイクロ波などのワイヤレス技術を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または、赤外線、無線、およびマイクロ波などのワイヤレス技術は媒体の定義内に含まれる。本明細書で使用する場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザディスク、光ディスク、デジタル多用途ディスク(DVD)、フレキシブルディスク、およびブルーレイディスクを含み、ディスク(disk)は、通常、磁気的にデータを再生し、ディスク(disc)は、レーザで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
【０１２２】
上記の開示は本発明の例示的な実施形態を示すが、添付の特許請求の範囲によって規定される本発明の範囲から逸脱することなく、本明細書において様々な変更および修正を行えることに留意されたい。本明細書で説明した本発明の実施形態による方法クレームの機能、ステップおよび/またはアクションは、特定の順序で実行されなくてもよい。さらに、本発明の要素は、単数形で説明または特許請求されていることがあるが、単数形に限定することが明示的に述べられていない限り、複数形が企図される。
【符号の説明】
【０１２３】
100  ワイヤレス通信システム、システム
102  UE、アクセス端末、セルラー電話、ワイヤレスクライアントコンピューティングデバイス、クライアントデバイス
104  エアインターフェース
108  UE、携帯情報端末、ワイヤレスクライアントコンピューティングデバイス
110  UE、ワイヤレスクライアントコンピューティングデバイス
112  UE、コンピュータプラットフォーム、ワイヤレスクライアントコンピューティングデバイス
120  無線アクセスネットワーク(RAN)
122  RNC、基地局コントローラ
124  ノードB、基地局
126  コアネットワーク
160  サービングGPRSサポートノード(SGSN)
162  パケットデータネットワークエンドポイント
164  パケットデータネットワークエンドポイント
165  ゲートウェイGPRSサポートノード(GGSN)
170  アプリケーションサーバ
170A  地域ディスパッチャ
170B  メディア制御コンプレックス(MCC)
175  インターネット、外部パケットデータネットワーク
182  認証、認可およびアカウンティング(AAA)サーバ、AAA
184  プロビジョニングサーバ
186  アーカイブデータベース
188  ルーティングユニット
200  UE
202  プラットフォーム
206  送受信機
208  特定用途向け集積回路(ASIC)
210  アプリケーションプログラミングインターフェース(API)
212  メモリ
214  ローカルデータベース
224  ディスプレイ
226  キーパッド
1200  通信デバイス
1205  論理
1210  論理
1215  論理
1220  論理
1225  論理
【図１】
0005703386.tif 000002
【図２Ａ】
0005703386.tif 000003
【図２Ｂ】
0005703386.tif 000004
【図３】
0005703386.tif 000005
【図４Ａ】
0005703386.tif 000006
【図４Ｂ】
0005703386.tif 000007
【図５Ａ】
0005703386.tif 000008
【図５Ｂ】
0005703386.tif 000009
【図５Ｃ】
0005703386.tif 000010
【図５Ｄ】
0005703386.tif 000011
【図６】
0005703386.tif 000012
【図７Ａ】
0005703386.tif 000013
【図７Ｂ】
0005703386.tif 000014
【図７Ｃ】
0005703386.tif 000015
【図８】
0005703386.tif 000016
【図９Ａ】
0005703386.tif 000017
【図９Ｂ】
0005703386.tif 000018
【図９Ｃ】
0005703386.tif 000019
【図９Ｄ】
0005703386.tif 000020
【図１０Ａ】
0005703386.tif 000021
【図１０Ｂ】
0005703386.tif 000022
【図１１Ａ】
0005703386.tif 000023
【図１１Ｂ】
0005703386.tif 000024
【図１２】
0005703386.tif 000025