特表 2024-520680 通話品質問題を解決すること

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-05-24

(54)【発明の名称】通話品質問題を解決すること

(51)【国際特許分類】

   H04W 24/10 20090101AFI20240517BHJP

   H04W 24/02 20090101ALI20240517BHJP

   H04W 76/10 20180101ALI20240517BHJP

【ＦＩ】

H04W24/10

H04W24/02

H04W76/10

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023574499

(86)(22)【出願日】2021-06-02

(85)【翻訳文提出日】2024-01-31

(86)【国際出願番号】 US2021035531

(87)【国際公開番号】W WO2022256009

(87)【国際公開日】2022-12-08

(81)【指定国・地域】

(71)【出願人】

【識別番号】502208397

【氏名又は名称】グーグル エルエルシー

【氏名又は名称原語表記】Ｇｏｏｇｌｅ ＬＬＣ

【住所又は居所原語表記】１６００ Ａｍｐｈｉｔｈｅａｔｒｅ Ｐａｒｋｗａｙ ９４０４３ Ｍｏｕｎｔａｉｎ Ｖｉｅｗ， ＣＡ Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】レスマン，マット・ビィ

(72)【発明者】

【氏名】ガン，タイラー・ジェイ

(72)【発明者】

【氏名】アグラワル，ラディカ

(72)【発明者】

【氏名】ラマチャンドラン，アムルス

(72)【発明者】

【氏名】クラウス，デイビッド・ジェイ

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA23

5K067DD41

5K067EE02

5K067EE10

5K067LL05

(57)【要約】

本文書は、リアルタイムパーソントゥパーソンメディアセッション（例えば、通話）中の通話品質問題を解決するための方法およびデバイスを説明する。本明細書で説明する技術は、無線通信ネットワーク（例えば、ＩＭＳネットワーク）を通して第２のコンピューティングデバイスとの通話を確立するために第１のコンピューティングデバイスを利用する。第１のコンピューティングデバイスは、デバイスのステータス情報を通信するために、通話中に第２のコンピューティングデバイスとステータスメッセージを交換することができる。例えば、第２のコンピューティングデバイスからのステータスメッセージにおいて受信されたステータス情報を使用して、通話品質問題が第１のコンピューティングデバイスによって検出される場合、第１のコンピューティングデバイスは、問題の原因を決定し、第１のコンピューティングデバイスのユーザに通話品質問題を通知することができる。さらに、第１のコンピューティングデバイスは、ユーザ体験を改善するために、通話品質問題を解決するための推奨を決定し、ユーザに推奨を通知することができる。

【特許請求の範囲】

【請求項1】

第１のコンピューティングデバイス（１０２－１）によって実施される方法（９００）であって、
無線通信ネットワークにおいて登録を要求する（９０２）ことと、
前記無線通信ネットワークにおいて登録を要求することに応答して、第２のコンピューティングデバイス（１０２－１）と前記無線通信ネットワークを通じてリアルタイムパーソントゥパーソンメディアセッションを確立する（９０４）ことと、
前記第２のコンピューティングデバイスからステータスメッセージを受信する（９０６）こととを含み、
前記ステータスメッセージは前記第２のコンピューティングデバイスのデバイス健全性情報を含み、前記デバイス健全性情報は前記リアルタイムパーソントゥパーソンメディアセッションの品質を示し、
前記方法は、
前記第２のコンピューティングデバイスの前記デバイス健全性情報に基づいて前記リアルタイムパーソントゥパーソンメディアセッションの通話品質問題を判定する（９０８）ことと、
前記リアルタイムパーソントゥパーソンメディアセッションの前記通話品質問題を判定することに応答して、前記第１のコンピューティングデバイスのユーザに前記リアルタイムパーソントゥパーソンメディアセッションの前記通話品質問題を知らせるための通知を生成する（９１０）ことと、
前記通知を使用して前記第１のコンピューティングデバイスの前記ユーザに通知する（９１２）ことと
をさらに含む、方法。

【請求項2】

前記リアルタイムパーソントゥパーソンメディアセッションの前記通話品質問題の原因を決定するために前記第２のコンピューティングデバイスの前記デバイス健全性情報を利用することと、
前記原因を利用して、前記第１のコンピューティングデバイスの前記ユーザが、前記通話品質問題を解決することを可能にするための推奨を決定することとをさらに含み、
前記推奨は、前記ユーザが実施するための推奨タスクを含み、
前記方法は、
前記第１のコンピューティングデバイスの前記ユーザに前記推奨を通知することをさらに含む、請求項１に記載の方法。

【請求項3】

前記第１のコンピューティングデバイスのデバイス健全性情報を決定することと、
前記第１のコンピューティングデバイスの前記デバイス健全性情報に基づいて前記リアルタイムパーソントゥパーソンメディアセッションの第２の通話品質問題を判定することと、
前記リアルタイムパーソントゥパーソンメディアセッションの前記第２の通話品質問題を判定することに応答して、前記第１のコンピューティングデバイスの前記ユーザに前記リアルタイムパーソントゥパーソンメディアセッションの前記第２の通話品質問題を知らせるための第２の通知を生成することと、
前記第１のコンピューティングデバイスの前記ユーザに前記リアルタイムパーソントゥパーソンメディアセッションの前記第２の通話品質問題を通知することとをさらに含む、先行する請求項のいずれかに記載の方法。

【請求項4】

前記リアルタイムパーソントゥパーソンメディアセッションの前記第２の通話品質問題を判定することに応答して、前記第１のコンピューティングデバイスの前記デバイス健全性情報を含む第２のステータスメッセージを生成することと、
前記第２のコンピューティングデバイスのユーザが前記第２の通話品質問題を通知されることを可能にするために前記第２のコンピューティングデバイスに前記第２のステータスメッセージを送信することとをさらに含む、請求項３に記載の方法。

【請求項5】

前記第１のコンピューティングデバイスの前記ユーザについての前記推奨は、前記ユーザが実施するための前記推奨されたタスクの実施を促進させるためにショートカットを含む、請求項２～請求項４のいずれかに記載の方法。

【請求項6】

第３者が前記第１のコンピューティングデバイスの前記ステータス情報にアクセスすることを防止するために、前記第２のステータスメッセージをエンコードすることをさらに含み、前記第３者は、前記第１のコンピューティングデバイスとは異なり、また、前記第２のコンピューティングデバイスとは異なる、請求項３～請求項５のいずれかに記載の方法。

【請求項7】

前記第１のコンピューティングデバイスの前記デバイス健全性情報を前記決定することは、
前記無線通信ネットワークの状態を決定すること、
前記リアルタイムパーソントゥパーソンメディアセッションの品質を決定すること、
現時点における前記第１のコンピューティングデバイスの健全性ステータスを決定すること、または、
前記ユーザからの前記第１のコンピューティングデバイスへの少なくとも１つの入力を検出すること
のうちの１つを含む、請求項３～請求項６のいずれかに記載の方法。

【請求項8】

前記第１のコンピューティングデバイスの前記デバイス健全性情報の前記決定を可能にするために、前記第１のコンピューティングデバイスの少なくとも１つのセンサから取得されるコンテキスト情報を利用することをさらに含む、請求項３～請求項７のいずれかに記載の方法。

【請求項9】

より早い時点における前記第１のコンピューティングデバイスの前記ステータス情報と比較したときの、現時点における前記第１のコンピューティングデバイスの前記ステータス情報の変化を決定することと、
前記第１のコンピューティングデバイスの前記ステータス情報の前記決定された変化に基づいて前記第２のコンピューティングデバイスに送信するために第３のステータスメッセージを生成することと、
前記第２のコンピューティングデバイスが、前記リアルタイムパーソントゥパーソンメディアセッションの通話品質問題を解決することを可能にするために、前記第２のコンピューティングデバイスに前記第３のステータスメッセージを送信することとをさらに含む、請求項３～請求項８のいずれかに記載の方法。

【請求項10】

前記第２の通話品質問題は、
機械学習モデル、
内部論理システム、または、
ヒステリシス論理
のうちの少なくとも１つを使用して予測される、請求項３～請求項９のいずれかに記載の方法。

【請求項11】

ハンドシェーク手順を使用して、前記リアルタイムパーソントゥパーソンメディアセッション中にステータスメッセージを交換するために、デバイストゥデバイス通信を確立することをさらに含み、前記ハンドシェーク手順は、
前記無線通信ネットワークを通して前記第２のコンピューティングデバイスに要求メッセージを送信することを含み、前記送信された要求メッセージは、前記第２のコンピューティングデバイスと前記第１のコンピューティングデバイスとの間でのステータスメッセージの交換を要求する、または、
前記無線通信ネットワークを通して前記第２のコンピューティングデバイスから要求メッセージを受信することを含み、前記受信された要求メッセージは、前記第２のコンピューティングデバイスと前記第１のコンピューティングデバイスとの間でのステータスメッセージの前記交換を要求する、先行する請求項のいずれかに記載の方法。

【請求項12】

前記ハンドシェーク手順は、
前記第２のコンピューティングデバイスに要求メッセージを送信することに応答して、前記無線通信ネットワークを通して前記第２のコンピューティングデバイスから応答メッセージを受信することをさらに含み、前記受信された応答メッセージは、前記第２のコンピューティングデバイスが、前記第２のコンピューティングデバイスと前記第１のコンピューティングデバイスとの間でのステータスメッセージの前記交換をサポートすることを示す、または、
前記第２のコンピューティングデバイスから要求メッセージを受信することに応答して、前記無線通信ネットワークを通して前記第２のコンピューティングデバイスに応答メッセージを送信することをさらに含み、前記送信された応答メッセージは、前記第１のコンピューティングデバイスが、前記第２のコンピューティングデバイスと前記第１のコンピューティングデバイスとの間でのステータスメッセージの前記交換をサポートすることを示す、請求項１１に記載の方法。

【請求項13】

Ａ、Ｂ、Ｃ、またはＤのうちの１つまたは複数のデュアルトーンマルチ周波数、ＤＴＭＦ、デジットを使用して、前記第２のコンピューティングデバイスが、前記第２のコンピューティングデバイスと前記第１のコンピューティングデバイスとの間でのステータスメッセージの前記交換をサポートするか否かを判定するために前記ハンドシェーク手順を実施することと、
前記第１のコンピューティングデバイスのステータス情報を含むＤＴＭＦステータスメッセージを生成することとをさらに含み、
前記ＤＴＭＦステータスメッセージは、Ａ、Ｂ、Ｃ、またはＤのうちの１つまたは複数のＤＴＭＦデジットを使用し、
前記方法は、
Ａ、Ｂ、Ｃ、またはＤのうちの１つまたは複数のＤＴＭＦデジットを使用して、前記第２のコンピューティングデバイスが、前記第２のコンピューティングデバイスと前記第１のコンピューティングデバイスとの間でのステータスメッセージの前記交換をサポートすると判定することに応答して、前記無線通信ネットワークを通して前記第２のコンピューティングデバイスに前記ＤＴＭＦステータスメッセージを送信することをさらに含む、請求項１１または請求項１２に記載の方法。

【請求項14】

リアルタイムトランスポートプロトコル、ＲＴＰ、ヘッダ拡張を使用して、前記第２のコンピューティングデバイスが、前記第２のコンピューティングデバイスと前記第１のコンピューティングデバイスとの間でのステータスメッセージの前記交換をサポートするか否かを判定するために前記ハンドシェーク手順を実施することと、
前記第１のコンピューティングデバイスのステータス情報を含むＲＴＰステータスメッセージを生成することとをさらに含み、
前記ＲＴＰステータスメッセージは、前記ＲＴＰヘッダ拡張を使用し、
前記方法は、
ＲＴＰヘッダ拡張を使用して、前記第２のコンピューティングデバイスが、前記第２のコンピューティングデバイスと前記第１のコンピューティングデバイスとの間でのステータスメッセージの前記交換をサポートすると判定することに応答して、前記無線通信ネットワークを通して前記第２のコンピューティングデバイスに前記ＲＴＰステータスメッセージを送信することをさらに含む、請求項１１または請求項１２に記載の方法。

【請求項15】

コンピューティングデバイス（１０２）であって、
少なくとも１つのプロセッサ（２０４）と、
命令を含むコンピュータ可読記憶媒体（２１０）とを備え、前記命令は、前記プロセッサによる実行に応答して、請求項１～請求項１４に記載の方法のうちのいずれか１つの方法を実施するように前記コンピューティングデバイスに指示するためのものである、コンピューティングデバイス。

【発明の詳細な説明】

【背景技術】

【0001】

背景
コンピューティングデバイス（例えば、スマートフォン）は、通信ネットワークを通して別のコンピューティングデバイスと通信することができる。例えば、第１のコンピューティングデバイスは、リアルタイムパーソントゥパーソンメディアセッション（例えば、通話）のために無線通信ネットワークを通して第２のコンピューティングデバイスに接続することができる。しかしながら、通信ネットワークを通したデバイスのそのようなネットワーク接続は、通話の品質を下げる場合がある問題が起こりやすい。これらの通話品質問題は、例えば、デバイスがローバッテリ状態によって突然電力を喪失すること、遠隔の場所に位置するデバイスによって引き起こされる不十分な音声（オーディオ）の品質、輻輳したネットワークによる不十分なオーディオ品質などを含む。ユーザは、しばしば、これらの通話品質問題のための解決策を独力で決定するのを任され、それは、ユーザが、問題を解決する試みにおいて自分のデバイス上で設定をナビゲートすることを要求する場合がある。ユーザは、ナビゲートする間に注意散漫になるかまたは問題を解決する方法に関して迷う場合があり、通話およびユーザ体験の効果をさらに減少させる。結果として、ユーザが、通話中に別のユーザと効果的に通信することを妨げる障壁が存在する。

【発明の概要】

【課題を解決するための手段】

【0002】

概要
本文書は、通話品質問題を解決するための技術およびデバイスを説明する。本明細書で説明する技術は、無線通信ネットワーク（例えば、インターネットプロトコルマルチメディアコアネットワークサブシステム（ＩＭＳ：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｍｕｌｔｉｍｅｄｉａ Ｃｏｒｅ Ｎｅｔｗｏｒｋ Ｓｕｂｓｙｓｔｅｍ）ネットワーク）を使用して別のデバイスとのリアルタイムパーソントゥパーソンメディアセッション（本明細書で略して通話と呼ばれる）を確立するためにコンピューティングデバイスを利用する。無線通信ネットワークを通して、コンピューティングデバイスは、デバイスうちの少なくとも１つのステータス情報（例えば、デバイスの健全性、コールの品質、ネットワークの品質）を通信するために、通話中に他のデバイスとステータスメッセージを交換することができる。ステータスメッセージは、例えば、リアルタイムトランスポートプロトコル（ＲＴＰ：ｒｅａｌ－ｔｉｍｅ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ）ヘッダ拡張または未使用デュアルトーンマルチ周波数（ＤＴＭＦ：ｄｕａｌ－ｔｏｎｅ ｍｕｌｔｉ－ｆｒｅｑｕｅｎｃｙ）デジット（例えば、デジットＡ、Ｂ、Ｃ、またはＤ）を使用して、通話中にデバイス間に交換され得る。通話品質問題は、別のデバイスからのステータスメッセージにおいて受信されたステータス情報を一部には使用して、コンピューティングデバイスによって検出され得る。通話品質問題を判定すると、コンピューティングデバイスは、ユーザに問題を知らせるために、デバイスのユーザに表示される通知を生成することができる。コンピューティングデバイスは、ユーザが通話品質問題を解決するのを助けるために推奨をさらに決定することができる。

【0003】

以下で説明する態様は、通話品質問題を解決するための技術を含む。例の方法は、第１のコンピューティングデバイスによって実施され、無線通信ネットワークにおいて登録を要求すること、および、第２のコンピューティングデバイスと、無線通信ネットワークを通じてリアルタイムパーソントゥパーソンメディアセッションを確立することを含むことができる。第１のコンピューティングデバイスは、第２のコンピューティングデバイスからステータスメッセージを受信することができ、ステータスメッセージは、リアルタイムパーソントゥパーソンメディアセッションの品質を示す、第２のコンピューティングデバイスのデバイス健全性情報を含む。第２のコンピューティングデバイスのデバイス健全性情報に基づいて、第１のコンピューティングデバイスは、リアルタイムパーソントゥパーソンメディアセッションの通話品質問題を判定することができる。通知は、第１のコンピューティングデバイスのユーザにリアルタイムパーソントゥパーソンメディアセッションの通話品質問題を知らせるために、第１のコンピューティングデバイスによって生成され得る。第１のコンピューティングデバイスは、通知を使用してユーザに通知することができる。

【0004】

認識されるように、本明細書で説明される種々の例は、通話に対する１人または複数人の加入者に接続／通信の支配的な状態および／または切断についての理由を通知するのに役立つことができる。幾つかの例において、提供される通知は、２人の加入者間の接続／通信問題を効率的に解決するためのヒューマンマシンインタラクションの一部を形成することができる。切断についての理由を示す通知は、様々な利点の中でも、接続を再始動させようと試みることが、価値があるか否かについての情報を提供することができる。

【0005】

この概要は、詳細な説明および図面において以下でさらに説明される、通話品質問題を解決するための単純化された概念を導入するために提供される。この概要は、特許請求される主題の本質的な特徴を特定することを意図されないし、特許請求される主題の範囲を決定するときの使用についても意図されない。

【0006】

通話品質問題を解決するための技術およびデバイスの１つまたは複数の態様の詳細は、添付図面を参照して説明される。

【図面の簡単な説明】

【0007】

【図1】通話品質問題を解決する技術が、通話中に、接続されたコンピューティングデバイスによって実施される例の環境を示す図である。

【図2】通話品質問題を解決する技術を実行する例のコンピューティングデバイスを示す図である。

【図3】通話中にデバイストゥデバイス通信を確立するために使用され得る例のハンドシェーク手順を示す図である。

【図4】通話品質問題を特定し解決するために、ステータスメッセージに含まれ得る例のステータス情報を示す図である。

【図5】プライバシーオプションのユーザ選択を可能にするステータスモジュールの例のステータス共有制御を示す図である。

【図6】第１のデバイス上に経時的に表示される通知の例のシーケンスを示す図である。

【図7】通話品質問題を解決するためにコンピューティングデバイス上に表示される推奨の例のシーケンスを示す図である。

【図8】通話品質問題を解決するための例の方法を示す図である。

【図9】通話品質問題を解決する技術を具現化する、または、その技術の使用を可能にする技術が実行され得る例のコンピューティングシステムを示す図である。

【発明を実施するための形態】

【0008】

図面全体を通した異なるインスタンスにおける同じ数字の使用は、同様の機能およびコンポーネントを参照することができる。

【0009】

詳細な説明
概要
コンピューティングデバイス間のネットワーク接続（例えば、オーディオ通話、ビデオ通話を可能にする）は、通話の品質を下げる場合がある通話品質問題が起こりやすい。これらの問題は、例えば、スマートフォンがローバッテリによって突然電力を喪失すること、遠隔の場所にあるスマートフォンの不十分な信号に伴うオーディオ擾乱、輻輳したネットワークによるビデオ通話のレーテンシなどを含む場合がある。デバイスユーザは、問題の原因または問題についての解決策を理解することなく、通話品質問題をしばしば体験する場合がある。例えば、通話が不意に中断する場合、ユーザは、通話がなぜ終了したかおよび自分のデバイスがその問題の発生源であるか否かを思案するままにされる場合がある。問題がデバイスに特定される場合でも、ユーザは、問題を素早く解決する方法を知りたいと思う場合がある。ユーザは、しばしば、通話品質問題に対する解決策を独力で決定し、問題を解決するために自分のデバイスをナビゲートするのを任される。ユーザは、ナビゲートする間に注意散漫になるかまたは問題を解決する方法に関して迷う場合があり、通話およびユーザ体験の効果をさらに減少させる。結果として、ユーザが通話品質問題を解決することを妨げる障壁が存在する。

【0010】

これらの課題に対処するために、本文書は、通話品質問題を解決するための方法を説明する。態様において、解決はリアルタイムに実施される。別のデバイスとの通話を確立した後、コンピューティングデバイスは、デバイスの１つまたは複数のステータス情報をリアルタイムに受動的に通信する（例えば、ユーザによって知覚されるように）ために、他のデバイスとステータスメッセージを交換することができる。このステータス情報は、例えば、デバイスのステータス（例えば、バッテリレベル）、通話の品質（例えば、接続強度）、無線通信ネットワークの品質（例えば、ネットワークトラフィックレベル）、および／または関連するユーザ入力（例えば、設定、入力）を含むことができる。通話中にこれらのステータスメッセージを交換するために、デバイスは、例えば、ＲＴＰヘッダ拡張および／または未使用ＤＴＭＦデジットを使用するハンドシェーク手順の動作を実施することによって、別のデバイスとのデバイストゥデバイス(device-to-device)通信を確立することができる。

【0011】

デバイスは、プレコールの（例えば、通話（コール）前の）、電話をかける間の、通話中の、またはポストコールの（例えば、通話（コール）が中断した後の）通話品質問題を判定するために、通話の際の接続されたデバイスの受信されたステータスメッセージおよび／または自分自身のデバイスのローカル健全性を使用することができる。通話品質問題を判定した後、コンピューティングデバイスは、デバイスのユーザに問題の詳細情報を通知すること、問題を素早く解決するための推奨をユーザに通知すること、または、他のデバイスのユーザに通話品質問題を知らせるために通話の際に別のデバイスにステータスメッセージを送信すること、の１つまたは複数を実施することによって問題を解決することができる。推奨は、ユーザが、動作を実施するように自分のデバイスをナビゲートすることなく、通話品質問題を素早く解決することを可能にするさらなる機能（例えば、ショートカット）を含むことができる。例えば、推奨は、１つまたは複数のユーザ選択可能オプションを含むことができ、そのオプションの選択は、推奨がそれに関して選択されるデバイスに、推奨された行為／動作を実施させることができる。

【0012】

例の環境
図１は、通話品質問題を解決する技術が、通話中に、接続されたコンピューティングデバイスによって実施される例の環境１００を示す。例の環境１００は、無線リンク１１０－１として示される１つまたは複数の無線通信リンク１１０（無線リンク１１０）を通して第１の基地局１０６と通信する第１のコンピューティングデバイス１０２－１（デバイス１０２－１）を含む。例の環境１００は、無線リンク１１０－２として示される１つまたは複数の無線通信リンク１１０を通して第２の基地局１０８と通信する第２のコンピューティングデバイス１０２－２（デバイス１０２－２）をさらに含む。説明を容易にするために、第１のデバイス１０２－１および第２のデバイス１０２－２は、本明細書でコンピューティングデバイス１０２とそれぞれ呼ばれ得、第１の基地局１０６および第２の基地局１０８は、ひとまとめに基地局１０４として示される。

【0013】

マクロセル、マイクロセル、スモールセル、ピコセル、分散基地局、および同様なもの、あるいはその任意の組み合わせまたは将来進化は、基地局１０４（例えば、進化型ユニバーサル地上無線アクセスネットワークＮｏｄｅＢ、Ｅ－ＵＴＲＡＮ ＮｏｄｅＢ、進化型ＮｏｄｅＢ、ｅＮｏｄｅＢ、ｅＮＢ、次世代ｅＮＢ、ｎｇ－ｅＮＢ、次世代ＮｏｄｅＢ、ｇＮｏｄｅ Ｂ、ｇＮＢ、基地局送受信機システム、無線ローカルアクセスネットワーク（ＷＬＡＮ：Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）ルータ、衛星、地上テレビジョンブロードキャストタワー、アクセスポイント、ピアトゥピアデバイス、基地局として働く別のコンピューティングデバイス、または同様なもの）を実装することができる。基地局１０４は、任意の適切なタイプの無線リンクとして実装される無線リンク１１０を使用してコンピューティングデバイス１０２と通信することができる。無線リンク１１０は、制御およびデータ通信、例えば、基地局１０４からコンピューティングデバイス１０２に通信されるデータおよび制御情報のダウンリンク、コンピューティングデバイス１０２から基地局１０４に通信される他のデータおよび制御情報のアップリンク、または両方を含むことができる。無線リンク１１０は、任意の適切な通信プロトコルまたは規格あるいは通信プロトコルまたは規格の組み合わせ、例えば、第３世代パートナーシッププロジェクト長期進化（３ＧＰＰ（登録商標） ＬＴＥ：３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ Ｌｏｎｇ－Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、第５世代ニューラジオ（５Ｇ ＮＲ：Ｆｉｆｔｈ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｗ Ｒａｄｉｏ）などを使用して実装される１つまたは複数の無線リンク（例えば、ラジオリンク）またはベアを含むことができる。

【0014】

基地局１０４（第１の基地局１０６、第２の基地局１０８）は、ひとまとめに無線アクセスネットワーク１１８（例えば、ＲＡＮ（：Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）、進化型ユニバーサル地上無線アクセスネットワーク、Ｅ－ＵＴＲＡＮ、５Ｇ ＮＲ ＲＡＮ、またはＮＲ ＲＡＮ）である。ＲＡＮ１１８内の基地局１０６および１０８は、コアネットワーク１１２（例えば、音声、画像、ビデオ、テキスト、メッセージング、および同様なもののために他のネットワークとインタフェースすることができるサービスをサポートするＩＭＳネットワーク）に接続される。基地局１０６および１０８は、５Ｇコアネットワークに接続するときユーザプレーンデータ通信用のＮＧ３インタフェース、進化型パケットコア（ＥＰＣ：Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）ネットワークに接続するときコントロールプレーンシグナリングおよびユーザプレーンデータ通信用のＳ１インタフェース、および同様なもののうちの任意の１つを使用して、コントロールプレーンシグナリング用のＮＧ２インタフェースを通して、それぞれ１２０および１２２において、コアネットワーク１１２に接続することができる。基地局１０６および１０８は、１２３において、Ｘｎインタフェースを通したＸｎアプリケーションプロトコル（ＸｎＡＰ：Ｘｎ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を使用して、ユーザプレーンデータおよびコントロールプレーンデータを交換するためのＸ２インタフェースを通したＸ２アプリケーションプロトコル（Ｘ２ＡＰ：Ｘ２ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を使用して、および同様なものを使用して通信することができる。コンピューティングデバイス１０２は、リモートサービス１１６と相互作用するために、インターネット１１４などのパブリックネットワーに、コアネットワーク１１２を使用して接続することができる。

【0015】

通話品質問題を解決する開示される技術は、第１のデバイス１０２－１または第２のデバイス１０２－２の一方または両方によって実施され得る。例の環境１００において、第１のデバイス１０２－１は、基地局１０４を通して第２のデバイス１０２－２との通話を可能にするため、シグナリングを実施し、リアルタイムパーソントゥパーソンメディアセッションに登録するために、無線リンク１１０－１を利用する。通話は、ＩＭＳネットワークを通じて確立され、例えば、オーディオ通話、ビデオ通話、共有サーバ上での接続、ボイスオーバー長期進化（ＶｏＬＴＥ：ｖｏｉｃｅ ｏｖｅｒ ｌｏｎｇ－ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ）通話、ボイスオーバーインターネットプロトコル（ＶｏＩＰ：ｖｏｉｃｅ ｏｖｅｒ ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）通話、ボイスオーバー５Ｇニューラジオ（ＶｏＮＲ：ｖｏｉｃｅ ｏｖｅｒ ５Ｇ Ｎｅｗ Ｒａｄｉｏ）通話、ボイスオーバーＷｉＦｉ（登録商標）（ＶｏＷｉＦｉ：ｖｏｉｃｅ ｏｖｅｒ ＷｉＦｉ）通話などを含むことができる。通話の確立は、第１のユーザ１２４－１が第２のユーザ１２４－２と、両者のそれぞれのコンピューティングデバイス１０２を利用して通信することを可能にする。説明を容易にするために、第１のユーザ１２４－１および第２のユーザ１２４－２は、本明細書でそれぞれユーザ１２４と呼ばれ得る。

【0016】

例の環境１００において、第１のデバイス１０２－１および第２のデバイス１０２－２は、通話品質問題を特定し解決するために、通話中にステータスメッセージを交換することができる。これらの通話品質問題は、例えば、ネットワーク状態（例えば、輻輳したネットワーク）、メディアセッションの品質、コンピューティングデバイス１０２の健全性ステータス（例えば、バッテリレベル）、あるいは１つまたは複数のユーザ入力（例えば、ユーザ１２４の意図的コマンド、ユーザ１２４の非意図的コマンド）の１つまたは複数に関連する場合がある。

【0017】

例の環境１００において、第１のデバイス１０２－１と第２のデバイス１０２－２との間の通話は、第１のユーザ１２４－１によって知覚されるように不意に中断する。本明細書で説明する技術を使用して、第２のデバイス１０２－２のローバッテリ状態によって通話が中断した可能性があることを第１のユーザ１２４－１に知らせるための通知１２６が、第１のデバイス１０２－１のディスプレイ１２８－１上に表示される。この例において、第１のデバイス１０２－１は、通話品質問題（例えば、中断された通話）を検出し、第２のデバイス１０２－２からのステータスメッセージにおいて受信された情報に基づいて通話品質問題（例えば、第２のデバイス１０２－２のローバッテリ状態）の原因を決定し、通話品質問題の原因を含んだ通知１２６を用いて第１のユーザ１２４－１に通知した可能性がある。一般に、第１のデバイス１０２－１は、検出された通話品質問題に関するステータスメッセージを第２のデバイス１０２－２に送信することができ、ステータスメッセージは、第２のデバイス１０２－２が第２のユーザ１２４－２に問題を通知することを可能にすることができる。しかしながら、第２のデバイス１０２－２は、例の環境１００において電力を喪失したため、通知は、第２のデバイス１０２－２のディスプレイ１２８－２上に表示されないかまたは第２のデバイス１０２－２によって受信されない場合がある。説明を容易にするために、ディスプレイ１２８－１およびディスプレイ１２８－２は、本明細書でそれぞれディスプレイ１２８と呼ばれ得る。本開示で説明する例のコンピューティングデバイスはスマートフォンであるが、他のタイプのコンピューティングデバイス１０２が、図２に関してさらに説明するように通話品質問題を解決する技術をサポートすることもできる。

【0018】

例のコンピューティングデバイス
図２は、通話品質問題を解決する技術を実行する例のコンピューティングデバイス１０２を示す。コンピューティングデバイス１０２は、デスクトップコンピュータ２０２－１、タブレット２０２－２、ラップトップ２０２－３、テレビジョン２０２－４、コンピューティングウォッチ２０２－５、コンピューティングメガネ２０２－６、ゲーミングシステム２０２－７、マイクロ波２０２－８、および車両２０２－９を含む種々の非制限的な例のデバイスと共に示される。他のデバイスも使用され得、他のデバイスは、ホームサービスデバイス、スマートスピーカ、スマートサーモスタット、セキュリティカメラ、ベビーモニター、ＷｉＦｉ（登録商標）ルータ、ドローン、トラックパッド、ドローイングパッド、ネットブック、電子書籍リーダ、ホームオートメーションおよび制御システム、ウォールディスプレイ、仮想現実ヘッドセット、および／または別の家電製品を含む。コンピューティングデバイス１０２は、装着可能、非装着可能であるがモバイルである、または比較的固定である（例えば、デスクトップ、電化製品）とすることができる。

【0019】

コンピューティングデバイス１０２は、例えば、中央処理ユニット（ＣＰＵ：ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、データ処理ユニット（ＤＰＵ：ｄａｔａ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、グラフィクス処理ユニット（ＧＰＵ：ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）などの１つまたは複数を含むプロセッサ２０４を含むことができる。コンピューティングデバイス１０２は、信号を受信し送信するために使用される１つまたは複数の送受信機２０６を含むこともできる。送受信機２０６は、ステータスメッセージを別のコンピューティングデバイスに送信し、ステータスメッセージを他のコンピューティングデバイスから受信するために使用され得る。図２に示さないが、コンピューティングデバイス１０２は、代替的に、それぞれ、別のデバイスから信号を受信し、別のデバイスに信号を送信するように指定される受信機および送信機を含むことができる。

【0020】

コンピューティングデバイス１０２は、ディスプレイ１２８および少なくとも１つのセンサ２０８を含むことができる。図１の例の環境１００において、ディスプレイ１２８は、中断された通話の通知１２６を表示するために一部が使用され得る。一般に、ディスプレイ１２８は、ユーザ設定、選好などを含むコンピューティングデバイス１０２のコンテンツを観察および／または制御するために使用され得る。少なくとも１つのセンサ２０８は、例えば、コンピューティングデバイス１０２に関連するコンテキスト情報（例えば、触覚入力、場所、検出された動きなど）を使用して、コンピューティングデバイス１０２のステータスを決定するために一部が使用され得る。センサ２０８は、例えば、カメラ、マイクロフォン、スピーカ、周囲光センサ、バイオメトリックセンサ、加速度計、ジャイロスコープ、磁力計、近接センサ、全地球航法衛星システム（ＧＮＳＳ：ｇｌｏｂａｌ ｎａｖｉｇａｔｉｏｎ ｓａｔｅｌｌｉｔｅ ｓｙｓｔｅｍ）センサ、タッチスクリーンセンサ、健全性センサ、バーコードセンサ、迅速応答（ＱＲ：ｑｕｉｃｋ ｒｅｓｐｏｎｓｅ）コードスキャナ、バロメータ、レーダーセンサなどを含むことができる。

【0021】

図２に示すコンピューティングデバイス１０２は、コンピュータ可読媒体（ＣＲＭ：ｃｏｍｐｕｔｅｒ－ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）２１０を含むこともできる。ＣＲＭ２１０上のコンピュータ可読命令として実現されるアプリケーションおよび／またはオペレーティングシステム（示さず）は、プロセッサ２０４によって実行され、本明細書で説明する機能の一部を提供することができる。ＣＲＭ２１０は、通話品質問題を判定するために、ステータスモジュール２１２への入力として、送受信機２０６および／またはセンサ２０８から情報を受信することができる。ＣＲＭ２１０は、通話品質問題を解決する技術を実施するようにコンピューティングデバイス１０２のステータスモジュール２１２に指示するための命令を含むことができる。

【0022】

通話中にステータスメッセージの交換を可能にするために、デバイストゥデバイス通信が、ステータスモジュール２１２のメッセージ初期化器２１４を使用して確立され得る。メッセージ初期化器２１４は、送受信機２０６を使用して通話の際に別のデバイスに送信され得る要求メッセージを生成するようにメッセージ生成器２１６に指示することによってデバイストゥデバイス通信を確立することができる。コンピューティングデバイス１０２が送受信機２０６を使用して応答メッセージを受信する場合、ステータスモジュール２１２のメッセージ解析器２１８は、メッセージ初期化器２１４への入力としてこのメッセージを解析する（例えば、デコードする、変換する）。コンピューティングデバイス１０２が別のデバイスとのデバイストゥデバイス通信を確立すると、メッセージ生成器２１６およびメッセージ解析器２１８は、デバイス間で交換されるステータスメッセージを、それぞれ生成し解析するためにさらに使用され得る。

【0023】

ステータスモジュール２１２の接続解析器２２０は、通話の際に別のデバイスからの受信されたステータスメッセージおよび／またはコンピューティングデバイス１０２のローカル健全性情報内の情報に基づいて通話品質問題を判定することができる。示さないが、ステータスモジュール２１２は、ＣＲＭ２１０のユーザ入力モジュール（例えば、１つまたは複数のユーザ入力を検出するため）、デバイス健全性モジュール（例えば、コンピューティングデバイス１０２の健全性ステータスを決定するため）、メディア接続モジュール（例えば、無線リンク１００を通る通話の品質を決定するため）、または通信ネットワークモジュール（例えば、コアネットワーク１１２の状態を検出するため）のうちの任意の１つまたは組み合わせを使用してローカル健全性情報を決定することができる。これらのモジュール（示さず）の１つまたは複数は、ハードウェア、ソフトウェア、ファームウェア、またはその組み合わせを使用して実行され得る。

【0024】

接続解析器２２０が通話品質問題を判定した後、通知生成器２２２は、（例えば、ディスプレイ１２８－１上で第１のユーザ１２４－１に通知するために第１のデバイス１０２－１を使用して）デバイスのユーザに問題を警告するために使用される１つまたは複数の通知１２６を決定することができる。通知生成器２２２は、通話品質問題に関連するステータス情報を含む、別のデバイスに（例えば、送受信機２０６を使用して）送信される１つまたは複数のステータスメッセージを決定することもできる。他のデバイスにおいてこのステータスメッセージを受信すると、他のデバイスは、そのデバイスのユーザに問題を通知する同様の動作を実施するためにローカルステータスモジュール２１２を使用することができる。さらに、ステータスモジュール２１２は、通話品質問題を解決するための１つまたは複数の推奨を決定するために推奨生成器２２４を使用することができる。第１のデバイス１０２－１の推奨生成器２２４は、例えば、推奨を決定し、ディスプレイ１２８－１上で第１のユーザ１２４－１にその推奨を知らせることができる。

【0025】

デバイストゥデバイス通信を確立すること
通話品質問題を解決する技術をイネーブルするために、コンピューティングデバイス１０２は、通話中に、接続されたデバイスとステータスメッセージを交換することができる。ステータスメッセージのこの交換（デバイストゥデバイス通信）は、ユーザ１２４が直接関わることなく実施され得る（例えば、ユーザ１２４によって知覚される受動的交換）。例えば、第１のデバイス１０２－１は、第１のユーザ１２４－１も第２のユーザ１２４－２も直接に交換を実施することなく、第２のデバイス１０２－２と、通話中に１つまたは複数のステータスメッセージを受信および／または送信することができる。通話品質問題（例えば、中断された通話）を検出すると、第１のデバイス１０２－１は、第２のデバイス１０２－２からのステータスメッセージにおいて受信された情報に、一部には基づいて、第１のユーザ１２４－１に通話品質問題を通知するためにディスプレイ１２８－１上に通知１２６を表示することができる。第１のデバイス１０２－１および第２のデバイス１０２－２の例のコンピューティングデバイス１０２はこのデバイストゥデバイス通信をサポートするが、一部のコンピューティングデバイス１０２は、そのようなメッセージ交換をサポートしない。したがって、第１のデバイス１０２－１は、図３に関してさらに説明するように、ステータスメッセージを送信する前に、接続された第２のデバイス１０２－２がデバイストゥデバイス通信をサポートするか否かを判定する必要がある場合がある。

【0026】

図３は、通話中にデバイストゥデバイス通信を確立するために使用され得る例のハンドシェーク手順３００を示す。例のハンドシェーク手順３００は、第１のデバイス１０２－１および第２のデバイス１０２－２を含むシステムによって実施される動作（または動き）のセットとして示される。これらのコンピューティングデバイス１０２の一方または両方は、示す動作をイネーブルするためにそのコンピューティングデバイス１０２のそれぞれのステータスモジュール２１２を利用することができる。例のハンドシェーク手順３００は、示す動作に限定されず、本明細書で説明する技術をイネーブルするために、必要に応じて再配置、反復、または排除され得る。２つのライフラインが３００に示され、第１のデバイス１０２－１によって実施される動作は、少なくとも部分的に第１のライフラインの周りに配向するか第１のライフラインから生じ、第２のデバイス１０２－２によって実施される動作は、少なくとも部分的に第２のライフラインの周りに配向するか第２のライフラインから生じる。

【0027】

例のハンドシェーク手順３００は、ステータスモジュール２１２のメッセージ初期化器２１４によって実施され得るが、一般に、例のハンドシェーク手順３００は、プロセッサ２０４、ＣＲＭ２１０の別のモジュール、またはその任意の組み合わせによって実施され得る。例のハンドシェーク手順３００の動作は、通話に先立って（プレコール）、電話をかける間に（例えば、通話が第１のデバイスによって始動された後であるが、第２のデバイスがその通話に接続される前に）、および／または通話中に実施され得る。デバイストゥデバイス通信を確立した後、ステータスメッセージは、電話をかける間にまたは通話中に交換され得る。一般に、デバイストゥデバイス通信は、例えばユーザニーズに基づいてユーザによって、任意のデバイス上で、手動でイネーブル（稼働）またはディセーブル（停止）され得る。第１のデバイス１０２－１がデバイストゥデバイス通信機能をイネーブルしてしまっており、第２のデバイス１０２－２が、デバイスによってサポートされる場合、この機能を同様にイネーブルしたか否かを、一部には判定するために、ハンドシェーク手順を実施していることが３００において仮定される。

【0028】

ネットワーク接続手順３０２－１にて、第１のデバイス１０２－１および第２のデバイス１０２－２は、本明細書で説明する技術をイネーブルする、１つまたは複数の基地局（例えば、基地局１０４）、共通サーバ、ピアトゥピアネットワーク、および／またはクライアントサーバモデルを使用して無線通信ネットワークに対する接続を（例えば、無線リンク１１０を使用して）確立する。基地局１０４は、コアネットワーク１１２に対する接続（例えば、ＩＭＳネットワーク接続）をイネーブルすることができる。例えば、第１のデバイス１０２－１は、ＩＭＳネットワークにおいて登録を要求することができる。

【0029】

通話接続手順３０２－１において、リアルタイムパーソントゥパーソンメディアセッション（通話）は、無線通信ネットワークに対する接続を確立すると、第１のデバイス１０２－１と第２のデバイス１０２－２との間に確立される。例えば、第１のデバイス１０２－１は、ＩＭＳネットワークにおいて登録を受信し、その後、第２のデバイス１０２－２とのオーディオ通話を確立し始めることができる。通話は、オーディオ通話、ビデオ通話、共有サーバ上での接続、ＶｏＬＴＥ通話、ＶｏＩＰ通話、ＶｏＮＲ通話、またはＶｏＷｉＦｉ通話などの１つまたは複数を含むことができる。

【0030】

第１のデバイス１０２－１は、要求メッセージ３０４（第１の要求メッセージ３０４－１として３００に示す）を送信することができる。この要求メッセージ３０４は、接続された第２のデバイス１０２－２に送信され得る、１つまたは複数のバイナリーデジット（ビット）、第１のデバイス１０２－１によってサポートされるメッセージングプロトコルのバージョン（例えば、デバイストゥデバイス通信）、トーン、メッセージ、命令のセットなどを含むことができる。第１のデバイス１０２－１のメッセージ初期化器２１４は、第２のデバイス１０２－２がステータスメッセージの交換をサポートするか否かを判定するため、送受信機２０６を使用して第２のデバイス１０２－２に要求メッセージ３０４を送信するように第１のデバイス１０２－１に指示することによってデバイストゥデバイス通信を確立することができる。

【0031】

要求メッセージ３０４は、メッセージ生成器２１６によって生成され、或る継続時間にわたって（例えば、周期的に４０ミリ秒（ｍｓ）ごとに）再送され得る。なぜなら、要求の受信が、無線通信ネットワークに対して保証されない場合があるからである。継続時間中、第１の受信検証手順３０６は、応答メッセージ３１２が第２のデバイス１０２－２から受信されたか否かを判定するために、第１のデバイス１０２－１によって実施され得る。応答メッセージ３１２が、継続時間内の所与の時間に受信されなかった場合、第１のデバイス１０２－１は、要求メッセージ３０４を再送することができる（別の要求メッセージ３０４－Ｎとして３００に示す、ここで、Ｎは、再送ごとに単調に増加する１より大きい整数値を示す）。第１のデバイス１０２－１は、応答メッセージ３１２が第１のデバイス１０２－１によって受信されるかまたは継続時間が終了してしまうまで、要求を再送することができる。要求メッセージ３０４の再送は、ユーザニーズ（例えば、バッテリ充電の維持）に基づいて、継続時間にわって、連続的に、周期的に、所定の時間に、または断続的に実施され得る。

【0032】

継続時間は、第１の要求メッセージ３０４－１が第１のデバイス１０２－１から送信された時間に対して測定され得る。特に、タイマーは、第１の要求メッセージ３０４－１を送信すると、アクティブ状態にトリガーされ得る（例えば、タイマーの開始をトリガーする）。タイマー（例えば、計時システム）は、継続時間内の時間を計数するために使用され、継続時間が終了するかまたは応答メッセージ３１２が第２のデバイス１０２－２から受信されるまで、アクティブ状態にあるままである。第１の受信検証手順３０６において、第１のデバイス１０２－１は、タイマーが、アクティブ状態にあるかまたは非アクティブ状態にある（例えば、継続時間が終了したことを示す）かをさらに判定することができる。継続時間内の所与の時間にて、タイマーが、アクティブ状態にあると判定され、応答メッセージ３１２が受信されていない場合、第１のデバイス１０２－１は、要求メッセージ３０４を再送することができる。

【0033】

例のハンドシェーク手順３００において、応答プロセス３０８は、第２のデバイス１０２－２がデバイストゥデバイス通信をサポートする場合、実施され得る。第１の肯定応答手順３１０において、第２のデバイス１０２－２は、第１のデバイス１０２－１が、例えば要求メッセージ３０４を受信することに基づいてデバイストゥデバイス通信をサポートすると判定することができる。第２のデバイス１０２－２が、第１のデバイス１０２－１からの再送された要求メッセージ（例えば、３０４－Ｎ）を受信する場合、第２のデバイス１０２－２は、第１の受信された要求メッセージ３０４と同様であるいずれのさらなる要求を無視することができる。第２のデバイス１０２－２は、将来参照するために、第２のデバイス１０２－２（例えば、ＣＲＭ２１０）上に第１のデバイス１０２－１のデバイストゥデバイス通信設定を記憶することができる。

【0034】

第２のデバイス１０２－２は、要求メッセージ３０４と同様であるかまたは要求メッセージ３０４とは異なる、１つまたは複数のビット、第２のデバイス１０２－２によってサポートされるメッセージングプロトコルのバージョン、トーン、メッセージ、命令のセットなどを含む、第１のデバイス１０２－１に対する応答メッセージ３１２（第１の応答メッセージ３１２－１として３００に示す）を送信することもできる。特に、第２のデバイス１０２－２の送受信機２０６は、第１のデバイス１０２－１から要求メッセージ３０４を受信することができ、第２のデバイス１０２－２のメッセージ初期化器２１４は、第１のデバイス１０２－１がデバイストゥデバイス通信をサポートすると判定することができる。このメッセージ初期化器２１４は、第２のデバイス１０２－２の送受信機２０６を使用して、第１のデバイス１０２－１に送信され得る応答メッセージ３１２を生成するようにメッセージ生成器２１６に指示することもできる。

【0035】

第２の受信検証手順３１４において、第２のデバイス１０２－２は、第２の継続時間にわたって応答メッセージ３１２（別の要求メッセージ３１２－Ｍとして３００に示す、ここで、Ｍは、再送ごとに単調に増加する１より大きい整数値を示す）を再送することができる。なぜなら、応答の受信が、無線通信ネットワークに対して保証されない場合があるからである。第２のデバイス１０２－２は、デバイストゥデバイス通信が始まる（例えば、ステータスメッセージが、第１のデバイス１０２－１から第２のデバイス１０２－２において受信される）かまたは第２の継続時間が終了するまで、応答を再送することができる。応答メッセージ３１２の再送は、ユーザニーズに基づいて、第２の継続時間にわたって、連続的に、周期的に、所定の時間に、または断続的に実施され得る。第２の継続時間は、上記に述べた継続時間と同様であるかまたは上記に述べた継続時間とは異なる場合がある。第２のタイマーは、第１の応答メッセージ３１２－１の送信によって、アクティブ状態に同様にトリガーされ得る。第２のタイマーは、第２の継続時間内の時間を計数するために使用され、第２の継続時間が終了するかまたはデバイストゥデバイス通信が始まる（例えば、ステータスメッセージが、第１のデバイス１０２－１から受信される）まで、アクティブ状態にあるままである。

【0036】

第２の肯定応答手順３１６において、第１のデバイス１０２－１は、例えば継続時間内に応答メッセージ３１２を受信することに基づいて第２のデバイス１０２－２がデバイストゥデバイス通信をサポートすると判定することができる。この判定を行うと、第１のタイマーは、第１のデバイス１０２－１によって非アクティブ状態にトリガーされ得る。第１のデバイス１０２－１が、第２のデバイス１０２－２から、再送された応答メッセージ（例えば、３１２－Ｍ）を受信する場合、第１のデバイス１０２－１は、第１の受信された応答メッセージ３１２と同様であるいずれのさらなる応答も無視することができる。第１のデバイス１０２－１は、将来参照するために、第１のデバイス１０２－１（例えば、ＣＲＭ２１０）上に第２のデバイス１０２－２のデバイストゥデバイス通信設定を記憶することができる。

【0037】

一般に、要求メッセージ３０４および／または応答メッセージ３１２は、ランダムである、予め決められる、暗号化される（例えば、プライバシーのためにエンコードされる）、および／または、送信デバイスに関する情報（例えば、識別子）を含むことができる。例のハンドシェーク手順３００の第１のライフラインに関連する動作が第１のデバイス１０２－１によって実施されるものとして説明され、第２のライフラインに関連する動作が第２のデバイス１０２－２によって実施されるものとして説明されるが、一般に、第２のデバイス１０２－２は第１のライフラインの動作を実施することができ、第１のデバイス１０２－１は第２のライフラインの動作を実施することができる。

【0038】

第２のデバイス１０２－２がデバイストゥデバイス通信をサポートすると判定した後、第１のデバイス１０２－１および第２のデバイス１０２－２は、ステータスメッセージを交換し始めることができる。一例において、ステータスメッセージは、一部には、通話品質問題を特定し解決するために、デバイストゥデバイス通信を使用して交換され得る。しばしば、ユーザは、問題の原因または問題についての解決策を理解することなく、通話品質問題を体験する場合がある。例えば、通話は、不意に中断する場合があり、通話がなぜ終了したかおよびユーザのデバイスが問題の発生源であるか否かをユーザが思案するままにさせる。ステータスメッセージは、これらのタイプの通話品質問題に対処することができる、接続されたデバイスに関するコンテキスト情報を通信するために通話中に交換され得る。目下の例において、デバイスは、デバイストゥデバイス通信を使用して「ローバッテリ（ｌｏｗ ｂａｔｔｅｒｙ）」というステータスメッセージを送信して、中断された通話をもたらす可能性がある低レベルのバッテリ充電を他のデバイスに知らせることができる。通話が不意に終了する場合、ユーザは、ステータスメッセージにおいて受信された情報（例えば、他のデバイスが、不十分なレベルのバッテリ充電のせいで電力を喪失した）から、中断された通話の原因をよりよく理解することができる。

【0039】

ステータスメッセージは、ステータスモジュール２１２からの命令によって、デバイストゥデバイス通信を使用してコンピューティングデバイス１０２の送受信機２０６によって任意の時間に（例えば、周期的に、所定の時間に、間欠的に）送信され得る。ステータスメッセージは、メッセージ生成器２１６によって生成され得、第３者（例えば、第１のデバイス１０２－１および第２のデバイス１０２－２とは異なるエンティティ）がデバイスのステータス情報にアクセスすることを防止するために暗号化され得る。コンピューティングデバイス１０２は、コンピューティングデバイス１０２の送受信機２０６において任意の時間にステータスメッセージを受信することもできる。メッセージ解析器２１８は、暗号化されたメッセージをデコードする、ステータスメッセージ内の情報を変換する、および／またはステータスメッセージ内の情報を理解するために解析手順を実施することができる。

【0040】

一例において、第１のデバイス１０２－１は、デバイスのバッテリ充電レベルの変化を検出し、プロセッサ２０４は、デバイストゥデバイス通信を使用して通話中に、接続された第２のデバイス１０２－２に第１のデバイス１０２－１のステータス情報のこの変化を通信するようにステータスモジュール２１２に指示する。第１のデバイス１０２－１のメッセージ生成器２１６は、第１のデバイス１０２－１がローレベルのバッテリ充電を有することを第２のデバイス１０２－２に知らせるために、（例えば、「ローバッテリ」の）ステータスメッセージを生成することができる。第１のデバイス１０２－１は、送受信機２０６によって第２のデバイス１０２－２に送信されるこのステータスメッセージを暗号化することができる。第２のデバイス１０２－２は、暗号化されたメッセージを、送受信機２０６を使用して受信することができ、第２のデバイス１０２－２のメッセージ解析器２１８は、接続解析器２２０への入力としてメッセージをデコードすることができる。

【0041】

ディセーブリングプロセス３２０は、第２のデバイス１０２－２がデバイストゥデバイス通信をサポートしない場合に実施され得る。却下手順３２２において、第２のデバイス１０２－２は、第１のデバイス１０２－１からの要求メッセージ（複数可）３０４を無視することができる。第２のデバイス１０２－２がデバイストゥデバイス通信をサポートすることが可能であっても、ユーザ１２４（例えば、第２のユーザ１２４－２）は、第２のデバイス１０２－２に対して機能をディセーブルした可能性がある。この場合、第２のデバイス１０２－２は、却下手順３２２に示すように、要求メッセージ３０４を依然として無視することができる。

【0042】

時間検証手順３２４において、第１のデバイス１０２－１は、（例えば、タイマーを使用して）継続時間が終了したこと、および、応答メッセージ３１２が第２のデバイス１０２－２から受信されなかったことを判定する。この判定に基づいて、第１のデバイス１０２－１は、第３の肯定応答手順３２６において、第２のデバイス１０２－２がデバイストゥデバイス通信をサポートせず、ステータスメッセージの交換をディセーブルするかまたはそれを控えることができると判定することができる。デバイストゥデバイス通信機能は、例えば第１のデバイス１０２－１のＣＲＭ２１０上の第２のデバイス１０２－２の記憶された設定を使用して、この通話中におよび／または第２のデバイス１０２－２との将来の通話中に一時的にディセーブルされ得る。この機能は、例えば第３のデバイスとのデバイストゥデバイス通信を確立するときに、再びイネーブルされ得る。

【0043】

要求メッセージ３０４、応答メッセージ３１２、およびステータスメッセージは、メッセージヘッダ（例えば、ＲＴＰヘッダ拡張を使用する）および／または未使用ＤＴＭＦデジット（例えば、Ａ～Ｄのデジット）を利用することができる。メッセージヘッダまたは未使用ＤＴＭＦデジットを使用して、例のハンドシェーク手順３００の動作は、既存の規格（例えば、機械、ソフトウェア、ネットワーク）を全く修正することなくおよび／またはキャリアインフラストラクチャ（例えば、ＬＴＥ、５Ｇ ＮＲ、または無線ローカルエリアネットワーク）に対する変更を全く必要とすることなく実施され得る。さらに、ステータスメッセージは、電気通信システムを動作させるキャリアネットワークによって修正またはブロックされることなくデバイス間で交換され得る。

【0044】

一例において、デバイストゥデバイス通信およびハンドシェーク手順は、少なくとも１つのＲＴＰヘッダ拡張を含むメッセージヘッダを使用して実施され得る。電気通信システム用の３ＧＰＰによって設定された規格および仕様によれば、多くのコンピューティングデバイス１０２は、ＩＰネットワークを通じてオーディオおよびビデオ情報を送出するためにＲＴＰデータパケットをサポートする。ＩＭＳネットワークは、例えば、マルチメディアサービス（例えば、通話、テキスト、ＲＴＰメッセージ）が、ＩＰネットワークを使用して別のデバイスに送出されることを可能にすることができる。この例において、ＩＭＳネットワークは、ＲＴＰデータパケットが、第１のコンピューティングデバイス（例えば、第１のデバイス１０２－１）から第２のコンピューティングデバイス（例えば、第２のデバイス１０２－２）に送出されることを可能にする。ＲＴＰデータパケットは、コンピューティングデバイス１０２間のリアルタイムデータ伝送（例えば、メディアストリーミング、遠隔会議アプリケーションなど）を可能にするエンドトゥエンドネットワークトランスポート機能を提供することができる。ＲＴＰデータパケットを使用してデータを伝送する動作は、ＩＰネットワークにわたる迅速送出を可能にするためにデータをデータパケットに構造化することを含むことができる。データパケットを受信した後、データは、受信者コンピューティングデバイスのためのデータの滑らかに流れるストリームになるように再構築される。ＲＴＰデータパケットは、受信者コンピューティングデバイスにデータを再構築する方法を知らせるＲＴＰヘッダを含むことができる。ＲＴＰヘッダは、例えば、ヘッダ拡張、プロトコルのバージョン、パディングバイト、貢献ソース識別、マーカ、ペイロードタイプ情報、シーケンス番号、タイムスタンプなどを含むことができる。

【0045】

ＲＴＰ仕様は、理解されないＲＴＰヘッダを無視するように受信者コンピューティングデバイスに要求する。ＲＴＰヘッダは独立した情報（例えば、ＲＴＰペイロードとは異なる）を保持するため、ＲＴＰヘッダを無視することは、データ（例えば、オーディオデータ、ビデオデータ）の処理、デコーディング、またはエンコーディングに影響を及ぼさない。メッセージ（例えば、ステータス情報を含む）は、コンピューティングデバイス１０２間でデータを伝送するための技術としてのＲＴＰヘッダ拡張に含まれ得る。例のハンドシェーク手順３００において、第１のデバイス１０２－１は、ＲＴＰヘッダ拡張を使用して要求メッセージ３０４（例えば、ＲＴＰ要求）を送信することができる。ＲＴＰ要求は、例えば、識別子（ＩＤ：ｉｄｅｎｔｉｆｉｅｒ）、情報の長さ、およびデータを含む情報の１つまたは複数のビットを含むことができる。ＲＴＰ要求の送出は、無線通信ネットワークにわたって保証されない場合があるため、第１のデバイス１０２－１は、或る継続時間にわたって（例えば、バンドリングに応じて２０～４０ｍｓごとに）ＲＴＰ要求を再送することができる。ＲＴＰヘッダ拡張を使用する応答メッセージ３１２（例えば、ＲＴＰ応答）が、継続時間内に第１のデバイス１０２－１において受信される場合、第１のデバイス１０２－１は、ＲＴＰ要求を再送することを止めることができる。幾つかの場合に、ＲＴＰヘッダ拡張は、例えば未使用ＤＴＭＦデジットに関してステータスメッセージを交換するための主要な技術として優先順位付けされ得る。

【0046】

デバイス間でのメッセージの交換中に、ＲＴＰヘッダ拡張は、例えば、ビットアレイで、コンピューティングデバイス１０２のステータスに関する情報を含むことができる。例えば、ＲＴＰヘッダ拡張に含まれるＲＴＰメッセージは、［１０１１ ００００ ０００１ ０１００］のビットアレイを含むことができ、第１のカルテット［１０１１］はデバイスステータスを指すメッセージを示し、第２のカルテット［００００］はペイロード長を指し、第３のカルテット［０００１］は、新しいＲＴＰメッセージごとに単調増加するシーケンス番号を示し、そして、第４のカルテット［０１００］は、デバイスの「ローバッテリ」のメッセージを示す。任意の所与の時間に、各デバイスは、１つまたは複数のＲＴＰメッセージを受信することができる。コンピューティングデバイス１０２は、受信された以前のメッセージと同様である１つまたは複数のＲＴＰメッセージを無視することができる。結果として、コンピューティングデバイス１０２は、本明細書で説明する技術を使用して、通話の際に別のコンピューティングデバイスのステータスの変化を検出するためにＲＴＰメッセージを使用することができる。

【0047】

ステータスメッセージの交換は、ＲＴＰヘッダ拡張を含むメッセージヘッダに限定されない。デバイストゥデバイス通信およびハンドシェーク手順は、未使用ＤＴＭＦデジットを使用して実施され得る。電気通信システム用の３ＧＰＰによって設定された規格および仕様は、多くのコンピューティングデバイス１０２が、１５のデジット（０～９、＊、♯、Ａ、Ｂ、Ｃ、およびＤ）を使用するＤＴＭＦシグナリングの使用をネゴシエートしサポートすることができることも示す。ユーザ１２４は、コンピューティングデバイス１０２のキーパッド上で１２のデジット（０～９、＊、および♯）のみによって制限され得るが、さらなる未使用ＤＴＭＦデジットＡ～Ｄが、デバイストゥデバイス通信のために利用可能とすることができる。

【0048】

例のハンドシェーク手順３００において、第１のデバイス１０２－１は、１つまたは複数の未使用ＤＴＭＦデジットを使用して１つまたは複数の要求メッセージ３０４を送信する。要求は、例えば、パラメータ識別子およびパラメータ値を含むことができる。パラメータ識別子は、デジットＤによって終端されるデジットＡおよび／またはＢによって示されるベース３でエンコードしたバージョン番号を含むことができる。パラメータ値は、例えば、第１のデバイス１０２－１によってサポートされるプロトコルバージョンを第２のデバイス１０２－２に通信することができる。デジットＡ～Ｃは、プロトコルバージョンを特定するために組み合わせて使用され得、一方、デジットＤはパラメータ値の終端を特定する。例えば、第１のデバイス１０２－１は、第１のデバイス１０２－１によってサポートされるＩＰバージョン１．０を通信するために、要求メッセージ３０４において「ＡＤ」を第２のデバイス１０２－２に送信する。第２のデバイス１０２－２が、未使用ＤＴＭＦデジットを使用してデバイストゥデバイス通信をサポートすると、第１のデバイス１０２－１が判定する場合、第１のデバイス１０２－１は、第２のデバイス１０２－２にステータス情報を通信するために文字Ａ～Ｄの組み合わせを送信することができる。

【0049】

一例において、「ＡＢＢＡＤ」のＤＴＭＦメッセージは、シーケンスの開始を特定するために第１のデジット「Ａ」を、および、シーケンスの終了を特定するために第５のデジット「Ｄ」を含む。第２、第３、および第４のデジットは、アレイ［ＸＹＺ］を形成し、ステータスメッセージのデータを示し、ここで、Ｘはパラメータカテゴリを示し、Ｙはパラメータタイプを示し、Ｚはパラメータ値を示す。ステータスメッセージ「ＡＢＢＡＤ」のデータは「ＢＢＡ」を含み、ここで、Ｘ＝「Ｂ」はデバイスステータスを指し、Ｙ＝「Ｂ」はネットワークカバレジを指し、Ｚ＝「Ａ」は、不十分という品質を指す。ステータスメッセージ「ＡＢＢＡＤ」は、デバイスが不十分なネットワークカバレジを体験していることを示す。一般に、データのアレイは、代替のアレイ（例えば、Ｘのアレイ、ＵＶＷＸＹＺのアレイなど）を形成するために、３より少ないかまたは３より多い任意の量のデジットを含むことができる。未使用ＤＴＭＦデジットは、通信ネットワークの輻輳を防止するために、ＲＴＰヘッダ拡張に関してステータスメッセージを交換するための２次技術として優先順位付けされ得る。未使用ＤＴＭＦデジットがメッセージを交換するために使用される場合、各デバイスは、ユーザ体験を改善するために、Ａ～ＤのＤＴＭＦデジットに関連する音階を奏することを控えることができる。

【0050】

デバイストゥデバイス通信は、非互換性条件であって、例えば、緊急通話、勧誘員通話、会議、単一無線音声通信継続（ＳＲＶＣＣ：ｓｉｎｇｌｅ ｒａｄｉｏ ｖｏｉｃｅ ｃｏｎｔｉｎｕｉｔｙ）のアクティブ状態が検出される、などを含む、非互換性条件が生じる場合、コンピューティングデバイス１０２によって任意の時間にディセーブルされ得る。これらの事例において、他の接続されたデバイス（例えば、緊急オペレータの固定電話）は、しばしば、通話中にステータスメッセージの交換をサポートせず、本明細書で説明する技術から利益を得ない場合がある。

【0051】

図３に示すハンドシェーク手順は、両方のデバイス（例えば、第１のデバイス１０２－１および第２のデバイス１０２－２）が共有サーバ上にある場合、同様に簡略化され得る。この場合、第１のデバイス１０２－１は、共有サーバに接続し、第２のデバイス１０２－２も共有サーバに接続されていると判定する。２つのデバイスは、共有サーバにわたってステータスメッセージを交換し始めることができる。

【0052】

通話品質問題を判定すること
ステータスメッセージは、図４に関してさらに説明されるように、例えば、無線通信ネットワークの状態（例えば、ＩＭＳネットワークの状態）、通話の品質（例えば、オーディオ品質）、通話の際の１つまたは複数のデバイスの健全性ステータス（例えば、バッテリレベル）、デバイスのユーザからの入力（例えば、触覚入力、コマンド、ユーザ設定）、カスタムメッセージなどの１つまたは複数に関するステータス情報を含むことができる。このステータス情報は、例えば、ステータスメッセージにおいて交換された情報、受信されたステータスメッセージの解析（接続解析器２２０によって実施される）、ＣＲＭ２１０の１つまたは複数のセンサ２０８、１つまたは複数のさらなるモジュール（示さず）などによって収集された情報を使用して決定され得る。ステータスメッセージに含まれるステータス情報は、歪んだオーディオ／ビデオ信号、エコー、間欠的なオーディオ／ビデオ信号、沈黙、オーディオ信号のボリュームまたは明瞭さの変化、ビデオ信号の解像度の減少、遅延したオーディオ／ビデオ（例えば、レーテンシ、ラグ）、オーディオ／ビデオ干渉または静的ノイズ、背景ノイズ、意図的でないユーザ入力、１つまたは複数のユーザ設定、ユーザコマンド、触覚入力、音声入力、ジャスチャ入力、他のデバイスと共有するためにユーザによって選択された記憶情報（例えば、旅行情報、カレンダーイベント）、バッテリレベル、１つまたは複数のセンサのアクティブまたは非アクティブ状態、マイクロフォンのミュートステータス、スピーカのミュートステータスなどの１つまたは複数に関する情報をさらに含むことができる。ステータス情報は、加速度計を使用して決定されたユーザの活動（例えば、ウォーキング）、位置センサによって決定されたデバイスの場所、動きセンサによって決定された緊急情報（例えば、自動車衝突）などを含むこともできる。

【0053】

コンピューティングデバイス１０２のユーザ１２４は、本明細書で説明するシステム、アプリケーション、および／または機能が、ユーザ情報および／またはデバイス情報（例えば、選好、記憶情報、デバイスの目下の場所）の収集を可能にすることができるか否かおよびいつ可能にすることができるか、および、ユーザ１２４がサーバからコンテンツおよび／または通信情報を送信されるか否かの両方についてユーザ１２４が選択を行うことを可能にする制御を提供され得る。さらに、特定のデータは、個人的に特定可能な情報が除去されるように、特定のデータが記憶および／または使用される前に１つまたは複数の方法で処理され得る。例えば、ユーザ１２４のアイデンティティは、個人的に特定可能な情報がユーザ１２４について特定されることができないように処理され得る。別の例において、ユーザ１２４の地理的場所は一般化され得、場所情報は、ユーザ１２４の特定の場所が決定されることができないように（例えば、都市、便集配区域改善計画（ＺＩＰ：ｚｏｎｅ ｉｍｐｒｏｖｅｍｅｎｔ ｐｌａｎ）コード、または州レベルに対して）取得される。そのため、ユーザ１２４は、どんな情報が収集されるか、その情報がどのように使用されるか、およびどんな情報が、通話の際にデバイスに提供されるかを制御することができる。ステータスメッセージ内の情報は、ユーザ体験を改善するために、１つまたは複数のコンピューティングデバイス１０２のソフトウェアアプリケーション（例えば、フォンブックアプリケーション）によって同様に使用され得る。

【0054】

図４は、通話品質問題を特定し解決するためにステータスメッセージに含まれ得る例のステータス情報を示す。ステータス情報の例は、例の環境４０２、４０４、４０６、および４０８に示され、通話品質問題を判定するためにステータスモジュール２１２の接続解析器２２０によって使用され得る。ステータス情報は、コンピューティングデバイス１０２上の他のアプリケーションまたはプログラムにリンクされ得る（例えば、フォンブックアプリケーション、メッセージングアプリケーションなどと共有される）。

【0055】

例の環境４０２において、第１のデバイス１０２－１は、第２のデバイス１０２－２との通話中に、基地局（例えば、１０４）から遠い遠隔の場所（例えば、森）に移動しており、第１のデバイス１０２－１の不十分な接続性をもたらす。ステータスモジュール２１２は、第１のデバイス１０２－１の不十分な接続性に関するステータス情報を第２のデバイス１０２－２に送信して、第２のデバイス１０２－２のステータスモジュール２１２が通話品質問題を判定することを可能にすることができる。第１のデバイス１０２－１および／または第２のデバイス１０２－２の接続解析器２２０は、例えば、接続の以前の品質（例えば、遠隔でない場所における）と比較したときのデバイスの接続性の品質の変化（例えば、平均から不十分への）を特定することによって、第１のデバイス１０２－１の不十分な接続性に関連する通話品質問題を判定することができる。特に、接続解析器２２０は、接続性の不十分な条件が、通話品質問題に関連する所定の閾値を超えると判定することができる。一般に、接続解析器２２０は、経時的なデバイスの接続性の変化、所定のまたは可変の閾値を超える場合がある接続性レベル、通話の品質に関する第２のデバイス１０２－２からの受信されたステータスメッセージ内のステータス情報などの１つまたは複数を特定することによって、この通話品質問題を判定することができる。

【0056】

例の環境４０４において、基地局１０４は、多数のユーザデバイスに接続され、輻輳したネットワークをもたらす。第１のデバイス１０２－１が、この基地局１０４を使用してネットワーク接続を確立する場合、１つまたは複数の通話品質問題が生じる場合があり、例えば、オーディオ／ビデオコンテンツのレーテンシまたは中断された通話をもたらす。例えば、無線通信ネットワークの目下の品質に関するセンサ２０８からの入力に基づいて、接続解析器２２０は、輻輳したネットワークに関連する通話品質問題を特定することができる。第１のデバイス１０２－１は、例えば第２のデバイス１０２－２に関して電話がかけられる前に、この問題を特定することができる。通話が試みられる前に、この通話品質問題を特定することによって、第１のデバイス１０２－１は、成功裏の通話についての可能性に関して第１のユーザ１２４－１によりよく知らせることができる。

【0057】

例の環境４０６において、第１のユーザ１２４－１は、第２のユーザ１２４－２（例えば、ジョン）と通話中であり、第１のユーザ１２４－１は、第１のデバイス１０２－１のマイクロフォン４１２をユーザの手で部分的に覆うことによって通話のオーディオを意図せずに歪ませ始める。第１のデバイス１０２－２は、接続解析器２２０を使用して、このオーディオ歪みに関連する通話品質問題を判定することができる。特に、第１のデバイス１０２－１のセンサ２０８（例えば、タッチセンサ、レーダーセンサ、超音波センサ、周囲光センサ）は、マイクロフォン４１２のこの閉鎖をステータスモジュール２１２への入力として検出することができる。接続解析器２２０は、第１のユーザの手によるマイクロフォン４１２の閉鎖が、オーディオ歪みを引き起こしていると判定することができる。メッセージ生成器２１６は、第２のデバイス１０２－２がオーディオ歪みに関連する通話品質問題を局所的に判定することを可能にするため、第２のデバイス１０２－２にこのステータス情報を通信するために１つまたは複数のステータスメッセージを生成することができる。

【0058】

例の環境４０８において、第１のデバイス１０２－１は、第２のデバイス１０２－２との中断された通話をもたらす場合があるローバッテリになっている。ステータスモジュール２１２への入力（例えば、バッテリレベル充電情報）に基づいて、接続解析器２２０は、通話品質問題（例えば、中断された通話）がローバッテリのせいで起こる可能性があると判定し、ステータスモジュール２１２は、この通話品質問題を通信するために他のデバイスとステータスメッセージを交換し始める。

【0059】

一般に、接続解析器２２０は、ステータスメッセージにおいて受信された第１のデバイス１０２－１のステータス情報および／または第２のデバイス１０２－２のステータス情報を使用して、デバイスの健全性の変化、所定のまたは可変の閾値（例えば、バッテリレベル）を超える場合があるデバイス健全性レベルなどの１つまたは複数を特定することによって、通話品質問題を判定することができる。接続解析器２２０は、受信されたステータスメッセージからの情報、ローカルデバイスのステータス情報、および／または機械学習（ＭＬ：ｍａｃｈｉｎｅ－ｌｅａｒｎｅｄ）モデルを使用して通話品質問題を判定することもできる。ＭＬモデルは、デバイスによって体験される通話品質問題の履歴に基づいてローカルデバイスにおける問題を予測することができる。ＭＬモデルは、標準的なニューラルネットワークベースモデルとすることができ、その際、対応するレイヤが、固定側ベクトル、テキスト埋め込み、または可変長シーケンスのような入力機能を処理するために必要とされる。ＭＬモデルは、サポートベクターマシン（ＳＶＭ：ｓｕｐｐｏｒｔ ｖｅｃｔｏｒ ｍａｃｈｉｎｅ）、再帰型ニューラルネットワーク（ＲＮＮ：ｒｅｃｕｒｒｅｎｔ ｎｅｕｒａｌ ｎｅｔｗｏｒｋ）、畳み込みニューラルネットワーク（ＣＮＮ：ｃｏｎｖｏｌｕｔｉｏｎａｌ ｎｅｕｒａｌ ｎｅｔｗｏｒｋ）、デンスニューラルネットワーク（ＤＮＮ：ｄｅｎｓｅ ｎｅｕｒａｌ ｎｅｔｗｏｒｋ）、１つまたは複数のヒューリスティック、他の機械学習技術、その組み合わせなどの１つまたは複数として実行され得る。ＭＬモデルは、通話の際の１つまたは複数のデバイスのステータス履歴に基づいて通話品質問題を予測するように訓練され得る。ステータス履歴は、別のデバイスから受信される１つまたは複数のステータスメッセージおよび／またはデバイスのローカルステータス情報を含むことができる。ユーザ１２４のステータス情報を保護するために、プライバシー設定は、図５に関して説明される。

【0060】

図５は、プライバシーオプションのユーザ選択を可能にするステータスモジュール２１２の例のステータス共有制御を示す。例の環境５００において、ステータスモジュール２１２は、ユーザが、デバイストゥデバイス通信にオプトインするかまたはそこからオプトアウトするためのオプションを提供する。ユーザ１２４がオプトアウトする場合、却下手順３２２は、別の接続されたデバイスがデバイストゥデバイス通信を確立しようと試みる場合、コンピューティングデバイス１０２によって実施され得る。ユーザ１２４がデバイストゥデバイス通信にオプトインする場合、ユーザ１２４は、他のデバイスと共有される情報を修正するためにさらなる制御を提供され得る。例の環境５０２において、ユーザ１２４は、通話中に連絡先と共有される情報をカスタム選択することができる。ユーザ１２４は、全ての連絡先と情報を共有することからオプトアウトする（５０２に示す）場合、個々の連絡先についてユーザの共有設定をカスタマイズすることができる。例えば、ユーザ１２４は、通話中に情報を共有する特定の連絡先（例えば、ジョン）を選択することができる。示さないが、ユーザ１２４は、同様に、ステータスモジュール２１２によって収集される情報をモニターするために制御を提供され、コンピューティングデバイス１０２上に経時的に記憶される情報についての選好を設定され得る。

【0061】

接続解析器２２０が通話品質問題を判定した後、ステータスモジュール２１２は、通話品質問題を解決するためにさらなる動作を実施することができる。特に、ステータスモジュール２１２は、通知生成器２２２を使用してローカルデバイスのユーザに通話品質問題を通知することができる。一般に、通知１２６は、通話品質問題に関する詳細（例えば、検出されたノイズ）、各デバイスの関連するステータス情報、通話品質問題の原因、および／または問題の発生源を含むことができる。したがって、特定の通知１２６が、システム（例えば、２つのデバイスおよび２つのデバイス間の接続）の支配的な状態を示すことができ、接続に対する一方または両方の加入者が、通話品質問題がなぜ起こったかをよりよく理解することを可能にすることができることが認識されるであろう。これは、通話品質問題がより効率的に解決されることを可能にするおよび／またはユーザ体験を改善することができる。他の通知１２６は、通話が中断されることにつながったシステムの技術的状況／状態をユーザに示すことができる。とりわけ、そのような通知１２６は、通話に対する再始動を試みるか否かを判定するときにユーザ１２４のために情報を提供することができる。例えば、第２のデバイス１０２－２のローバッテリ状態のせいで通話が中断された可能性があることを示す通知１２６は、メディアセッションを即座に再始動しようと試みることが、価値がないことを第１のユーザ１２４－１に示すことができる。対照的に、何らかの一時的な／説明できない異常が通話を中断させたことを示す通知１２６は、通話を再始動しようと試みることが、価値があることを第１のユーザ１２４－１に知らせることができる。

【0062】

図６は、第１のデバイス１０２－１上に経時的に表示される通知１２６の例のシーケンス６００を示す。この例において、第１のユーザ１２４－１は、第２のユーザ１０４－２（例えば、ジョン）を通話したいと思い、通話品質問題が経時的に生じるにつれて通知される。６００の通知１２６は、ディスプレイ１２８－１上に視覚的に表示されるが、一般に、通知１２６は、第１のユーザ１２４－１に通知１２６を報知するために、音（例えば、音階）、振動、またはさらなる視覚的キュー（例えば、光）を含むこともできる。

【0063】

例の環境６０１において、第１のデバイス１０２－１は、「ネットワークがビジーである（ｎｅｔｗｏｒｋ ｉｓ ｂｕｓｙ）」ことを示すために、通話が確立される前（例えば、プレコール６０２）に、通知１２６－１を表示することができる。６０１にて、ステータスモジュール２１２は、無線通信ネットワークの品質に関する入力を使用して、ネットワークが、（例の環境４０４を参照して）目下、輻輳していると判定することができる。一般に、通知１２６は、例えば、問題の発生源（例えば、ネットワーク）および問題の原因（例えば、ネットワークの輻輳）に関する情報を含むことができる。

【0064】

例の環境６０４において、しかしながら、第１のユーザ１２４－１は、通話を行う（例えば、電話をかける６０６）ことに決める。示さないが、第１のデバイス１０２－１は、（ハンドシェーク手順を実施した後）この時間中、第２のデバイス１０２－２からステータスメッセージを受信することができる。この例において、第１のデバイス１０２－１は、（例の環境４０８を参照して）ジョンの電話がローバッテリになっていることを示す、第２のデバイス１０２－２からステータスメッセージを受信する。接続解析器２２０は、このローバッテリ状態が通話品質問題の資格があると判定し、表示用の通知１２６－２を生成するように通知生成器２２２に指示する。通知１２６－２は、「ジョンがローバッテリになっている（Ｊｏｈｎ ｈａｓ ａ ｌｏｗ ｂａｔｔｅｒｙ）」ことを第１のユーザ１２４－１に知らせ、第１のユーザ１２４－１は、第２のデバイス１０２－２のバッテリがより十分に充電されるまで、ジョンが通話を成功裏に確立または維持することができない可能性があると推測することができる。

【0065】

例の環境６０８において、しかしながら、通話は、ジョンに関して確立される。通話中６１０、第１のユーザ１２４－１は、（例の環境４０６を参照して）自分の手をデバイスのマイクロフォンの近くでこすることによって背景ノイズを意図せずに生成する可能性がある。接続解析器２２０は、ローカル入力（例えば、第１のデバイス１０２－１のセンサ２０８からの）および／または通話品質問題を示す第２のデバイス１０２－２からのステータスメッセージを使用して、通話品質問題（例えば、望ましくない背景ノイズ）が起こったと判定することができる。ステータスモジュール２１２は、第１のユーザ１２４－１に通知するため、「背景ノイズがあなたのデバイス上で検出された（ｂａｃｋｇｒｏｕｎｄ ｎｏｉｓｅ ｄｅｔｅｃｔｅｄ ｏｎ ｙｏｕｒ ｄｅｖｉｃｅ）」という別の通知１２６－３を生成するために通知生成器２２２を使用することができる。

【0066】

例の環境６１２において、通話は、（例の環境４０２を参照して）不十分なネットワーク接続のせいで中断している。接続解析器２２０は、第１のデバイス１０２－１のローカルステータス情報（例えば、第１のデバイス１０２－１に関連するネットワーク接続情報）および／または第２のデバイス１０２－２からの直近に受信されたステータスメッセージ（例えば、通話が中断される前に、通話中６１０に受信された直近のステータスメッセージ）を使用して、この通話品質問題を判定することができる。「通話は不十分なネットワーク接続のせいで中断した（ｃａｌｌ ｄｒｏｐｐｅｄ ｄｕｅ ｔｏ ｐｏｏｒ ｎｅｔｗｏｒｋ ｃｏｎｎｅｃｔｉｏｎ）」という通知１２６－４が、ポストコール６１４に（例えば、通話が終了した後に）現れて、通話がなぜ中断したかを第１のユーザ１２４－１がよりよく理解するのを助ける。

【0067】

６００の例の通知１２６は、ユーザに、通話品質問題の発生源および原因を通知するために使用されたが、ユーザ１２４は、この問題をどのように解決するかを知りたいと思う場合がある。ステータスモジュール２１２は、図７に関してさらに説明するように、この問題を解決するため最良の解決策を決定するために、推奨生成器２２４を使用することができる。

【0068】

通話品質問題を解決すること
図７は、通話品質問題を解決するためにコンピューティングデバイス１０２上に表示される推奨７０１の例のシーケンス７００を示す。例のシーケンス７００は、それぞれ、例の環境６０１、６０４、６０８、および６１２に対応する例の環境７０２、７０４、７０６、および７０８を含む。推奨７０１は、ステータスモジュール２１２の推奨生成器２２４によって決定された、通話品質問題を解決するのを助けるためにユーザ１２４が実施することができる１つまたは複数の提案された行為を含むことができる。推奨生成器２２４は、プリセットされた解決策、内部論理システム、ヒステリシス論理、またはＭＬモデルに基づいて通話品質問題に対する考えられる解決策を決定することができる。考えられる解決策は、１つまたは複数のデバイスの目下のステータス（例えば、１つまたは複数のセンサ、アプリケーション、またはプログラムのユーザ設定および／またはアクティブまたは非アクティブ状態）を条件とすることができる。例えば、ユーザ１２４が無線ローカルエリアネットワークに接続される場合、推奨生成器２２４は、推奨７０１を決定するときにこの設定を含むことができる。

【0069】

第１の時間に、第１のユーザ１２４－１（例えば、ジェーン）は、第２のユーザ１２４－２（例えば、ジョン）に関して電話をかけることを意図するが、ステータスモジュール２１２は、ネットワークがビジーであると判定する。通知１２６－１（６０１に示す）は、ジェーンに輻輳したネットワークを警告し、例の環境７０２において、推奨７０１－１は、ＷｉＦｉ（登録商標）コーリングに切り換えることを提案する。この例において、推奨７０１－１は、例の環境６０１の通知１２６－１と別個に示された。しかしながら、通知１２６－１および推奨７０１－１は、ディスプレイ１２８－１上に、同時に現れる（例えば、ジェーンに対する１つのメッセージまたは別個のメッセージとして）または異なる時間に現れることができる。推奨７０１は、通話品質問題が解決されるかまたは期間が終了するまで、或る期間、現れることができる。推奨７０１が、通知１２６が表示される時間と異なる時間に表示される場合、着信音または振動が、ユーザ１２４に推奨７０１を報知するためにトリガーされ得る。示さないが、各推奨７０１は、関連するユーザ設定、アプリケーション、またはプログラムに対する迅速アクセスのためのショートカットを提供することもできる。例えば、７０２の推奨７０１－１は、正しい設定をアクティブ化するために第１のデバイス１０２－１をナビゲートするようにジェーンに要求する代わりに、ＷｉＦｉ（登録商標）コーリングを迅速にアクティブ化するためにショートカット（例えば、アイコン、ボタン、リンク）を含むことができる。したがって、幾つかの例において、推奨７０１に関するユーザ選択（例えば、推奨７０１に含まれるショートカット）が、推奨された行為／動作がデバイスによって実施されるようにさせることができることが認識されるであろう（または、換言すれば、デバイスは、推奨された行為／動作の実施を引き起こすことによって推奨７０１に関するユーザ選択に応答することができる）。

【0070】

第２の時間に、第１のデバイス１０２－１は、第２のデバイス１０２－２に対して電話をかけており６０６、ステータスモジュール２１２は、第２のデバイス１０２－２がローバッテリになっていると判定する。例の環境７０４において、ジョンのデバイスを充電するようジョンに求めることを提案する推奨７０１－２が、第１のデバイス１０２－１上に現れる。示さないが、この推奨７０１－２は、例えば、テキストメッセージを作成し、推奨７０１－２をテキストメッセージに書き直し、テキストメッセージをジョンに送信するようにジェーンに要求することなく、ジェーンが推奨７０１－２のテキストメッセージをジョンに迅速に送信することを可能にするシュートカットを含むことができる。

【0071】

第３の時間に、第１のデバイス１０２－１は、第２のデバイス１０２－２と通話中であり、通知１２６－３は、背景ノイズが第１のデバイス１０２－１上で検出されたことをジェーンに知らせる。例の環境７０６において、推奨７０１－３は、ノイズがあるか自分のデバイスをチェックするようにジェーンに提案する。１つまたは複数のセンサ２０８からの入力を使用して、推奨７０１－３は、より詳細な命令（例えば、マイクロフォンが、妨害がないことをチェックする）を含むことができる。通話品質問題が、例えば、マイクロフォンまたはスピーカに関連する場合、推奨７０１－３は、ジェーンがマイクロフォンまたはスピーカ試験（例えば、較正、再構成）を迅速に実施することを可能にするためにショートカット（示さず）を含むことができる。

【0072】

第４の時間に、第２のデバイス１０２－２との通話は、不十分なネットワーク接続のせいで中断している。例の環境７０８において、推奨７０１－４は、後でジョンにコールバックするようリマインダーを設定するようにジェーンを促す。ジェーンが後でコールバックすべきであることをこの推奨７０１－４が提案することが推測され得る。示さないが、推奨７０１－４は、後のためにリマインダーを迅速に設定するためにショートカットを含むことができる。リマインダーを設定するとき、ステータスモジュール２１２は、コールバックする時間を最適化するために、記憶された情報（例えば、カレンダーイベント）を利用することができる。例えば、ジェーンが、（例えば、図５に関して説明したプライバシー設定を使用して）記憶されたカレンダーイベントをステータスモジュール２１２と共有することにオプトインする場合、推奨生成器２２４は、ジェーンのカレンダー内の計画されたイベントと競合しないコールバックに対する将来の時間を提案することができる。他の推奨７０１は、異なる通信方法によって（例えば、電子メールまたはテキストメッセージによって）ジョンと連絡をとるための、または、異なるデバイスを使用して（例えば、異なる番号、ハンドセット、ランドラインを使用して）ジョンと連絡をとるためのユーザ選択可能なオプションを含むことができる。そのような推奨がユーザ１２４によって選択されると、デバイスは、推奨された行為を実施する、または、ユーザ１２４がそれを実施するのを支援することができる（例えば、例えば受信者としてジョンが事前選択された状態の電子メールまたはメッセージングアプリケーションを開けることによって）。通話品質問題を解決するための技術は、図７に示す例に限定されず、これらの技術は、図８に関してより一般的に説明される。

【0073】

例の方法
図８は、通話品質問題を解決するための例の方法８００を示す。方法８００は、実施される動作（または行為）のセットとして示され、動作が本明細書で示される順序または組み合わせに必ずしも限定されない。さらに、動作の１つまたは複数の任意の動作は、豊富なさらなるおよび／または代替の方法を提供するために、反復、結合、再編成、またはリンクされ得る。以下の議論の複数の部分において、図１～７で詳述する環境およびエンティティに対して参照が行われ得、それらに対する参照は例のためにだけ行われる。技術は、１つのコンピューティングデバイス１０２上で動作する１つまたは複数のエンティティによる実施に限定されない。さらに、例の方法８００は、通話の際に任意のコンピューティングデバイス１０２によって実施され得る。

【0074】

８０２にて、第１のコンピューティングデバイスは、無線通信ネットワークにおける登録を要求する。例えば、第１のデバイス１０２－１は、図１の例の環境１００に示すように基地局１０４を使用してコアネットワーク１１２に対して（例えば、無線リンク１１０を使用して）ネットワーク接続を確立する。コアネットワーク１１２は、音声、画像、ビデオ、テキスト、メッセージング、および同様なもののために他のネットワークとインタフェースすることができるサービスをサポートするＩＭＳネットワークを含むことができる。

【0075】

８０４にて、第１のコンピューティングデバイスは、第２のコンピューティングデバイスとの無線通信ネットワークを通じたリアルタイムパーソントゥパーソンメディアセッションを確立する。例えば、第１のデバイス１０２－１は、第２のデバイス１０２－２とのＩＭＳネットワークを通じた通話を確立する。通話は、例えば、オーディオ通話、ビデオ通話、共有サーバ上での接続、ＶｏＬＴＥ通話、ＶｏＩＰ通話、ＶｏＮＲ通話、またはＶｏＷｉＦｉ通話などを含むことができる。図１において、第１のデバイス１０２－１および第２のデバイス１０２－２は共に、通話中にデバイストゥデバイス通信（例えば、ステータスメッセージの交換）をサポートする。しかしながら、第１のデバイス１０２－１は、第２のデバイス１０２－２が、図３の例のハンドシェーク手順３００を使用してデバイストゥデバイス通信をサポートするか否かを判定することができる。

【0076】

８０６にて、第１のコンピューティングデバイスは、第２のコンピューティングデバイスからステータスメッセージを受信する。例えば、第１のデバイス１０２－１は、ハンドシェーク手順中に確立されたデバイストゥデバイス通信を使用して、第２のデバイス１０２－２からのステータスメッセージを送受信機２０６において受信する。このステータスメッセージは、第１のデバイス１０２－１が通話品質問題を特定し解決することを可能にするために、第２のデバイス１０２－２に関するステータス情報（例えば、デバイス健全性情報）を含むことができる。

【0077】

８０８にて、リアルタイムパーソントゥパーソンメディアセッションの通話品質問題が、第２のコンピューティングデバイスのデバイス健全性情報に基づいて第１のコンピューティングデバイスによって判定される。例えば、通話の通話品質問題は、ステータスメッセージにおいて受信された第２のデバイス１０２－２のステータス情報に基づいて第１のデバイス１０２－１のステータスモジュール２１２の接続解析器２２０によって判定される。特に、接続解析器２２０は、第１のユーザ１２４－１に詳細情報を提供するために、通話品質問題の原因および発生源（例えば、第２のデバイス１０２－２）を決定することができる。ステータスメッセージにおいて受信されたステータス情報に一部には基づいて通話品質問題を判定することは、図４に関して詳細に説明される。

【0078】

８１０にて、第１のコンピューティングデバイスは、第１のコンピューティングデバイスのユーザに通話品質問題を知らせるための通知を生成する。例えば、第１のデバイス１０２－１のステータスモジュール２１２の通知生成器２２２は、第１のユーザ１２４－１に通話品質問題を知らせるための通知１２６を生成する。例の通知１２６は、図６の例のシーケンス６００に示される。

【0079】

８１２にて、第１のコンピューティングデバイスは、通知を使用して第１のコンピューティングデバイスのユーザに通知する。例えば、第１のデバイス１０２－１は、例えば、ディスプレイ１２８－１上に通知１２６を表示することによって、第１のユーザ１２４－１に警告するために音階を奏することによって、および／または第１のデバイス１０２－１のさらなる視覚的アラート（例えば、光）をトリガーすることによって第１のユーザ１２４－１に通知する。

【0080】

例のコンピューティングシステム
図９は、通話品質問題を解決する技術を具現化する、または、その技術の使用を可能にする技術が実行され得る例のコンピューティングシステム９００を示す。例のコンピューティングシステム９００は、任意のタイプのクライアント、サーバ、および／または図２を参照して説明するコンピューティングデバイスとして実行され得る。

【0081】

コンピューティングシステム９００は、デバイスデータ９０２（例えば、受信されたデータ、受信されているデータ、ブロードキャストのためにスケジュールされたデータ、データのデータパケット）を含むことができる。デバイスデータ９０２または他のデバイスコンテンツは、デバイスの構成設定、デバイス上に記憶されたメディアコンテンツ、および／またはデバイスのユーザに関連する情報を含むことができる。コンピューティングシステム９００上に記憶されたメディアコンテンツは、任意のタイプのオーディオ、ビデオ、テキスト、および／または画像データを含むことができる。コンピューティングシステム９００は、任意のタイプのデータ、メディアコンテンツ、および／または入力がそれによって受信され得る１つまたは複数のデータ入力９０４を含むことができ、１つまたは複数のデータ入力９０４は、ユーザ選択可能入力（明示的なまたは暗黙的な）、メッセージ、ミュージック、テレビジョンメディアコンテンツ、記録されたメディアコンテンツ、ならびに、任意のコンテンツおよび／またはデータ源から受信される任意の他のタイプのオーディオ、ビデオ、テキスト、および／または画像データを含む。

【0082】

コンピューティングシステム９００は、通信インタフェース９０６を含むこともでき、通信インタフェース９０６は、シリアルおよび／またはパラレルインタフェース、無線インタフェース、任意のタイプのネットワークインタフェース、モデム、および任意の他のタイプの通信インタフェースのうちの任意の１つまたは複数として実行され得る。通信インタフェース９０６は、コンピューティングシステム９００間の接続および／または通信リンク、ならびに、他の電子、コンピューティング、および通信デバイスが、それによってコンピューティングシステム９００とデータを通信する通信ネットワークを提供することができる。

【0083】

コンピューティングシステム９００は、１つまたは複数のプロセッサ９０８（例えば、マイクロプロセッサ、コントローラ、および同様なもののうちの任意のもの）を含むことができ、１つまたは複数のプロセッサ９０８は、種々のコンピュータ実行可能命令を処理して、コンピューティングシステム９００の動作を制御し、通話品質問題を解決するための技術、または、通話品質問題を解決することがそこで具現化され得る技術を可能にする。代替的にまたは付加的に、コンピューティングシステム９００は、９１０にて一般に特定される処理および制御回路に関連して実行される、ハードウェア、ファームウェア、または固定論理回路部の任意の１つまたは組み合わせによって実行され得る。示さないが、コンピューティングシステム９００は、デバイス内の種々のコンポーネントを結合するシステムバスまたはデータ転送システムを含むことができる。システムバスは、メモリバスまたはメモリコントローラ、ペリフェラルバス、ユニバーサルシリアルバス、および／または種々のバスアーキテクチャの任意のバスアーキテクチャを利用するプロセッサまたはローカルバスを含む異なるバス構造の任意の１つまたは組み合わせを含むことができる。

【0084】

コンピューティングシステム９００は、永続的および／または非一時的データストレージ（例えば、単なる信号伝送と対照的に）を可能にする１つまたは複数のメモリデバイスを含むコンピュータ可読媒体２１０をさらに含むことができ、その例は、ランダムアクセスメモリ（ＲＡＭ）、不揮発性メモリ（例えば、読み出し専用メモリ（ＲＯＭ）、フラッシュメモリ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの任意の１つまたは複数）、およびディスクストレージデバイスを含む。ディスクストレージデバイスは、ハードディスクドライブ、記録可能および／または再書き込み可能コンパクトディスク（ＣＤ）を含む任意のタイプの磁気または光ストレージデバイス、任意のタイプのデジタル多用途ディスク（ＤＶＤ）、ならびに同様なものとして実行され得る。コンピューティングシステム９００は、大容量ストレージメディアデバイス（ストレージメディア）９１２を含むこともできる。

【0085】

コンピュータ可読媒体２１０は、デバイスデータ９０２、ならびに、種々のデバイスアプリケーション９１４、および、コンピューティングシステム９００の動作態様に関連する任意の他のタイプの情報および／またはデータを記憶するデータストレージ機構を提供することができる。例えば、オペレーティングシステム９１６は、コンピュータ可読媒体２１０によってコンピュータアプリケーションとして維持され、プロセッサ９０８上で実行される。デバイスアプリケーション９１４は、デバイスマネジャを含むことができ、デバイスマネジャは、任意の形態の制御アプリケーション、ソフトウェアアプリケーション、信号処理および制御モジュール、特定のデバイスに固有のコード、特定のデバイス用のハードウェア抽象化レイヤなどを含む。コンピュータ可読媒体２１０のステータスモジュール２１２を使用して、コンピューティングシステム９００は、通話中に通話品質問題を特定し解決することができる。

【0086】

むすび
通話品質問題を解決するための技術およびデバイスが、機能および／または方法に特有の言語で説明されたが、添付請求項の主題が、説明される特定の機能または方法に必ずしも限定されないことが理解される。むしろ、特定の機能または方法は、通話品質問題を解決する例の実行態様として開示される。

【0087】

幾つかの例が以下で説明される。
例１：第１のコンピューティングデバイスによって実施される方法であって、無線通信ネットワークにおいて登録を要求することを含む。方法は、無線通信ネットワークにおいて登録を受信することに応答して、第２のコンピューティングデバイスと無線通信ネットワークを通じてリアルタイムパーソントゥパーソンメディアセッションを確立することを含む。方法は、第２のコンピューティングデバイスからステータスメッセージを受信することを含む。ステータスメッセージは第２のコンピューティングデバイスのデバイス健全性情報を含む。デバイス健全性情報はリアルタイムパーソントゥパーソンメディアセッションの品質を示す。方法は、第２のコンピューティングデバイスのデバイス健全性情報に基づいてリアルタイムパーソントゥパーソンメディアセッションの通話品質問題を判定することを含む。方法は、リアルタイムパーソントゥパーソンメディアセッションの通話品質問題を判定することに応答して、第１のコンピューティングデバイスのユーザにリアルタイムパーソントゥパーソンメディアセッションの通話品質問題を知らせるための通知を生成することを含む。方法は、通知を使用して第１のコンピューティングデバイスのユーザに通知することを含む。

【0088】

例２：例１に記載された方法であって、リアルタイムパーソントゥパーソンメディアセッションの通話品質問題の原因を決定するために第２のコンピューティングデバイスのデバイス健全性情報を利用することをさらに含む。方法は、原因を利用して、第１のコンピューティングデバイスのユーザが、通話品質問題を解決するための推奨を決定することをさらに含む。推奨は、ユーザが実施するための推奨タスクを含む。方法は、第１のコンピューティングデバイスのユーザに推奨を通知することをさらに含む。

【0089】

例３：先行する例のいずれかに記載された方法であって、第１のコンピューティングデバイスのデバイス健全性情報を決定することを含む。方法は、第１のコンピューティングデバイスのデバイス健全性情報に基づいてリアルタイムパーソントゥパーソンメディアセッションの第２の通話品質問題を判定することを含む。方法は、リアルタイムパーソントゥパーソンメディアセッションの第２の通話品質問題を判定することに応答して、第１のコンピューティングデバイスのユーザにリアルタイムパーソントゥパーソンメディアセッションの第２の通話品質問題を知らせるための第２の通知を生成することを含む。方法は、第１のコンピューティングデバイスのユーザにリアルタイムパーソントゥパーソンメディアセッションの第２の通話品質問題を通知することを含む。

【0090】

例４：例３に記載された方法であって、リアルタイムパーソントゥパーソンメディアセッションの第２の通話品質問題を判定することに応答して、第１のコンピューティングデバイスのデバイス健全性情報を含む第２のステータスメッセージを生成することをさらに含む。方法は、第２のコンピューティングデバイスのユーザが第２の通話品質問題を通知されることを可能にするために第２のコンピューティングデバイスに第２のステータスメッセージを送信することをさらに含む。

【0091】

例５：例２～例４のいずれかに記載された方法であって、第１のコンピューティングデバイスのユーザについての推奨は、ユーザが実施するための推奨されたタスクの実施を促進させるためにショートカットを含む。

【0092】

例６：例３～例５のいずれかに記載された方法であって、第３者が第１のコンピューティングデバイスのステータス情報にアクセスすることを防止するために、第２のステータスメッセージをエンコードすることをさらに含む。第３者は、第１のコンピューティングデバイスとは異なり、また、第２のコンピューティングデバイスとは異なる。

【0093】

例７：例３～例６のいずれかに記載された方法であって、第１のコンピューティングデバイスのデバイス健全性情報を決定することは、無線通信ネットワークの状態を決定すること、リアルタイムパーソントゥパーソンメディアセッションの品質を決定すること、現時点における第１のコンピューティングデバイスの健全性ステータスを決定すること、または、ユーザからの第１のコンピューティングデバイスへの少なくとも１つの入力を検出することのうちの１つを含む。

【0094】

例８：例３～例７のいずれかに記載された方法であって、第１のコンピューティングデバイスのデバイス健全性情報の決定を可能にするために、第１のコンピューティングデバイスの少なくとも１つのセンサから取得されるコンテキスト情報を利用することをさらに含む。

【0095】

例９：例３～例８のいずれかに記載された方法であって、より早い時点における第１のコンピューティングデバイスのステータス情報と比較したときの、現時点における第１のコンピューティングデバイスのステータス情報の変化を決定することをさらに含む。方法は、第１のコンピューティングデバイスのステータス情報の決定された変化に基づいて第２のコンピューティングデバイスに送信するために第３のステータスメッセージを生成することをさらに含む。方法は、第２のコンピューティングデバイスが、リアルタイムパーソントゥパーソンメディアセッションの通話品質問題を解決することを可能にするために、第２のコンピューティングデバイスに第３のステータスメッセージを送信することをさらに含む。

【0096】

例１０：例３～例９のいずれかに記載された方法であって、第２の通話品質問題は、機械学習モデルによって予測される。

【0097】

例１１：先行する例のいずれかに記載された方法であって、ハンドシェーク手順を使用して、リアルタイムパーソントゥパーソンメディアセッション中にステータスメッセージを交換するために、デバイストゥデバイス通信を確立することをさらに含む。ハンドシェーク手順は、無線通信ネットワークを通して第２のコンピューティングデバイスに要求メッセージを送信することを含む。送信された要求メッセージは、第２のコンピューティングデバイスと第１のコンピューティングデバイスとの間でのステータスメッセージの交換を要求する。または、ハンドシェーク手順は、無線通信ネットワークを通して第２のコンピューティングデバイスから要求メッセージを受信することを含む。受信された要求メッセージは、第２のコンピューティングデバイスと第１のコンピューティングデバイスとの間でのステータスメッセージの交換を要求する。

【0098】

例１２：例１１に記載された方法であって、ハンドシェーク手順は、第２のコンピューティングデバイスに要求メッセージを送信することに応答して、無線通信ネットワークを通して第２のコンピューティングデバイスから応答メッセージを受信することをさらに含む。受信された応答メッセージは、第２のコンピューティングデバイスが、第２のコンピューティングデバイスと第１のコンピューティングデバイスとの間でのステータスメッセージの交換をサポートすることを示す。または、ハンドシェーク手順は、第２のコンピューティングデバイスから要求メッセージを受信することに応答して、無線通信ネットワークを通して第２のコンピューティングデバイスに応答メッセージを送信することをさらに含む。送信された応答メッセージは、第１のコンピューティングデバイスが、第２のコンピューティングデバイスと第１のコンピューティングデバイスとの間でのステータスメッセージの交換をサポートすることを示す。

【0099】

例１３：例１１または例１２に記載された方法であって、Ａ、Ｂ、Ｃ、またはＤのうちの１つまたは複数のデュアルトーンマルチ周波数、ＤＴＭＦ、デジットを使用して、第２のコンピューティングデバイスが、第２のコンピューティングデバイスと第１のコンピューティングデバイスとの間でのステータスメッセージの交換をサポートするか否かを判定するためにハンドシェーク手順を実施することをさらに含む。方法は、第１のコンピューティングデバイスのステータス情報を含むＤＴＭＦステータスメッセージを生成することをさらに含む。ＤＴＭＦステータスメッセージは、Ａ、Ｂ、Ｃ、またはＤのうちの１つまたは複数のＤＴＭＦデジットを使用する。方法は、Ａ、Ｂ、Ｃ、またはＤのうちの１つまたは複数のＤＴＭＦデジットを使用して、第２のコンピューティングデバイスが、第２のコンピューティングデバイスと第１のコンピューティングデバイスとの間でのステータスメッセージの交換をサポートすると判定することに応答して、無線通信ネットワークを通して第２のコンピューティングデバイスにＤＴＭＦステータスメッセージを送信することをさらに含む。

【0100】

例１４：例１１または例１２に記載された方法であって、リアルタイムトランスポートプロトコル、ＲＴＰ、ヘッダ拡張を使用して、第２のコンピューティングデバイスが、第２のコンピューティングデバイスと第１のコンピューティングデバイスとの間でのステータスメッセージの交換をサポートするか否かを判定するためにハンドシェーク手順を実施することをさらに含む。方法は、第１のコンピューティングデバイスのステータス情報を含むＲＴＰステータスメッセージを生成することをさらに含む。ＲＴＰステータスメッセージは、ＲＴＰヘッダ拡張を使用する。方法は、ＲＴＰヘッダ拡張を使用して、第２のコンピューティングデバイスが、第２のコンピューティングデバイスと第１のコンピューティングデバイスとの間でのステータスメッセージの交換をサポートすると判定することに応答して、無線通信ネットワークを通して第２のコンピューティングデバイスにＲＴＰステータスメッセージを送信することをさらに含む。

【0101】

例１５：先行する例のいずれかに記載された方法であって、メディッセッションは、オーディオ通話、ビデオ通話、共有サーバ上での接続、ＶｏＬＴＥ通話、ＶｏＩＰ通話、ＶｏＮＲ通話、またはＶｏＷｉＦｉ通話のうちの１つを含む。

【0102】

例１６：コンピューティングデバイスであって、少なくとも１つのプロセッサと、命令を含むコンピュータ可読記憶媒体とを備える。命令は、プロセッサによる実行に応答して、例１～例１５に記載された方法のうちのいずれか１つの方法を実施するようにコンピューティングデバイスに指示するためのものである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【国際調査報告】