フルメディアコール実現のための Presence 情報に基づく

平成 27 年度
修士学位論文
フルメディアコール実現のための
Presence 情報に基づく最適メディア選択
支援機構に関する研究
A study of optimal media selection support based on
communicator’s presence for the full media call
1185075
赤澤 将太
指導教員
島村 和典
2016 年 2 月 26 日
高知工科大学大学院 工学研究科 基盤工学専攻
情報システム工学コース
要 旨
フルメディアコール実現のための Presence 情報に基づく最適メ
ディア選択支援機構に関する研究
赤澤 将太
近年，音声通話アプリやメッセージアプリなど，スマートフォンで利用できるメディアア
プリケーションは多様化している．そのため，利用者は一人のユーザに対して複数のメディ
アアプリケーションでの連絡が可能となった．しかし，多様なメディアアプリケーション
サービスが提供される環境の中，コミュニケーション時に，利用者は一般的に１つのメディ
アアプリケーションのみを用いる．これはメディアアプリケーションが多様化する以前に比
べ何も進化していない．
そこで，フルメディアコールが提案されている．フルメディアコールとは，知人である１
人のユーザに対して複数のメディアアプリケーションで同時に多様な表現メディアを使って
コミュニケーションすることである．フルメディアコールの実現のためには，多様化してい
るすべてのメディアアプリケーションを適切に連動させなければならない．最適なメディア
アプリケーションの選択を支援することはフルメディアコールの重要な構成要素のひとつで
ある．
本稿では，最適メディアアプリケーション群選択支援の実現方法として Presence Service
に着目した．フルメディアコールのための連絡相手の Presence に基づいた最適なメディア
アプリケーション群選択支援システムを提案した．
提案システムでは，3 つの機能を新しく追加した．1 つ目は，通信相手の利用可能なメディ
アアプリケーションを知る機能である．2 つ目は Presence 通知機能である．3 つ目は最適
メディアアプリケーション群を自動選択する機能である．
–i–
最適メディアアプリケーション群とは通信相手がすぐに応じることができるアプリケー
ション群である．また，発信者と着信者がお互いに使い慣れているアプリケーション群であ
る．最適なメディアアプリケーション群は 4 つの情報によって選ばれる．4 つのプレゼンス
情報は，通信相手のメディアアプリケーション利用可否状態，通信相手との通信履歴，発信
者のアプリケーション利用履歴，着信者のアプリケーション利用履歴である．最適なメディ
アアプリケーション群は，連絡相手が利用可能なアプリケーション であり，連絡相手との連
絡に最もよく利用するアプリケーションである．連絡相手との初めての連絡の場合は，発信
者と着信者のアプリケーション使用率から判断する．
検証のために最適メディアアプリケーション群を自動選択するアプリを作成し，最適メ
ディアアプリケーション選択にかかる時間を計測した．その結果，メディアアプリケーショ
ン数が 22 個（スマートフォンユーザに利用されているアプリ数の平均）のとき，最適メディ
アアプリケーションの選択は 3.77 ミリ秒以上 4.53 ミリ秒以下で行えた．
以上より，提案方式はフルメディアコール利用者の発信動作に遅延の影響を与えずに最適
なメディアアプリケーション群選択ができることを確認した．
キーワード
フルメディアコール， Presence Service，最適メディアアプリ推薦支援
– ii –
Abstract
A study of optimal media selection support based on
communicator’s presence for the full media call
Shouta AKAZAWA
In recent years, many of media applications such as voice call application and
message application can be used on a smartphone. The user has enabled to communicate
using plural media applications on a single communication call. While the user can meet
from a variety of media applications services, the user typically uses only one media
application during a communication. This situation does not differ from the previous
behavior where the media applications not to be diversified.
Therefore, the full media call has been proposed in this article. The full media call
is to allow the users to communicate simultaneously on multiple media applications for
a single user communicator. In order to realize this full media call, all of the media
applications which are diversified must be properly linked to the opposite communicator’s applications installed. The important requirement of this full media call is to be
supported the optimal selection among the many applications.
In this paper, the Presence Service was focused as a method of realizing the optimum media application selection support. The optimal media application selection for
the full media call support system was proposed based on the communicator’s presence.
The first, the available media applications of the communicator should be recognized.
The second, the receiver’s Presence should be realized through the notification function. The third requirements for this purpose is to realize the function of automatically
– iii –
selecting the optimal media applications group.
The optimal media application is an application which can be the communicator
responds immediately on the occasion called. In addition, the application should be
familiar with each other of the caller and the communicator.
The optimal media applications are selected using the four information. The four
information are the media application availability state of the communicator, the communication history with the communicator, the application usage history of the caller’s
and the application usage history for communicating with all users of the communicator’s. Optimal media application for the caller should be an available application and
most frequently used application with the communicator. In the case of first-time contact with the communicator, it is determined from the application usage of the caller
and the communicator.
The creating time of an application which is that automatically selected as the
optimal media application group availability was measured for the verification. The
smartphone users are using 22 applications on average. Under the number of media
applications was 22, the selection time of the optimal media application was done in
more than 3.77 milliseconds, less than 4.53 milliseconds.
The proposed method was confirmed that it is optimal media application selection
support without affecting the delay in the communication operation of the full media
call user.
key words
full media , full media call, Presence Service , Optimal media application
selection
– iv –
目次
第1章
研究背景と研究目的
1
1.1
メディアアプリケーションの普及 . . . . . . . . . . . . . . . . . . . . . .
1
1.2
表現メディアの種類 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
既存コミュニケーションにおける問題点 . . . . . . . . . . . . . . . . . . .
4
問題 1：コミュニケーションの形が進化していない
. . . . . . . . .
4
問題 2：円滑なコミュニケーションのためのメディアアプリケーショ
ン選択が難しい . . . . . . . . . . . . . . . . . . . . . . .
4
1.4
メディアアプリケーション利用形式の進化 . . . . . . . . . . . . . . . . .
5
1.5
Presence Service による通信可否判断 . . . . . . . . . . . . . . . . . . . .
6
1.6
フルメディアコールの必要性
. . . . . . . . . . . . . . . . . . . . . . . .
6
1.7
研究目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.8
論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
フルメディアコール
9
2.1
緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2
フルメディアコールの構想 . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3
フルメディアコール機能群 . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.1
保有するメディアアプリケーション群の把握機能 . . . . . . . . . .
11
2.3.2
Presence 通知機能 . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.3
最適メディアアプリケーション群の自動選択機能 . . . . . . . . . .
12
2.3.4
メディアアプリケーション群の多重起動機能 . . . . . . . . . . . . .
13
2.4
最適メディアアプリケーション群選択支援の応用 . . . . . . . . . . . . . .
14
2.5
結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
第2章
–v–
目次
第3章
最適メディアアプリケーション群選択支援方式
15
3.1
緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2
提案方式の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.3
提案方式の機能構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.4
動作内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.4.1
ユーザの保有するメディアアプリケーション群の把握 . . . . . . . .
19
3.4.2
Presence 通知 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.4.3
最適メディアアプリケーション群の自動選択 . . . . . . . . . . . . .
21
主要メディアアプリケーションの選定 . . . . . . . . . . . . . . . .
23
補助メディアアプリケーション群の選定 . . . . . . . . . . . . . . .
25
結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
評価検証
27
4.1
緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2
概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.3
最適メディアアプリケーション群選択支援方式の検証
. . . . . . . . . . .
27
4.3.1
検証環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.3.2
検証方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
検証結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.4.1
メディアアプリケーション数の変化における計測結果 . . . . . . . .
30
4.4.2
表現メディアの網羅率 . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.4.3
検証結果からの考察 . . . . . . . . . . . . . . . . . . . . . . . . . .
31
結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
結論
35
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.5
第4章
4.4
4.5
第5章
5.1
– vi –
目次
謝辞
37
参考文献
39
付録 A
最適メディアアプリケーション選定アルゴリズム
41
A.1
主要メディアの選定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
A.2
補助メディアアプリケーション群の選定 . . . . . . . . . . . . . . . . . . .
44
– vii –
図目次
1.1
フルメディアコールの概念図 . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1
フルメディアコールの動作 . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1
提案システムの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2
連絡相手ユーザの保有するメディアアプリケーション群把握のフロー . . . .
19
3.3
最適メディアアプリケーション群選定のための Presence 通知フロー . . . .
21
3.4
最適メディアアプリケーション群選定のフロー . . . . . . . . . . . . . . . .
22
3.5
主要メディアアプリケーション選定のフロー . . . . . . . . . . . . . . . . .
24
4.1
作成したアプリケーションによる検証画面 . . . . . . . . . . . . . . . . . .
29
4.2
メディアアプリケーション数の変化時の計測結果
. . . . . . . . . . . . . .
32
4.3
表現メディアの計測結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
– ix –
表目次
1.1
主なメッセージングアプリの例 . . . . . . . . . . . . . . . . . . . . . . . .
1
4.1
Google Nexus7 の性能 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.2
実験による検証結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
– xi –
第1章
研究背景と研究目的
1.1
メディアアプリケーションの普及
近年は，スマートフォンの普及により，音声通話アプリやメッセージングアプリ，SNS
（Sorcial Networking Service）といったコミュニケーションのためのメディアアプリケー
ションが広く普及した．メディアアプリケーションは，日々様々な企業から新しいサービス
が展開され，多種多様化している．表 1.1 に世界中で多くのシェアを持つ主なメッセージン
グアプリの例を示す [1]．
表 1.1 主なメッセージングアプリの例
サービス名
企業名（国籍）
開始年
平成 26 年時点のユーザ数
LINE
LINE（日本）
2011
500 百万人（登録者数）
Facebook Messanger
Facebook（米国）
2013
200 百万人（MAU）
WhatsApp
Facebook（米国）
2009
500 百万人（MAU）
Kakao Talk
カカオ（韓国）
2010
100 百万人（登録者数）
WeChat
テンセント（中国）
2011
396 百万人（MAU）
Kik Messenger
Kik Interactive
2010
100 百万人（登録者数）
LINE とは，LINE 社が提供するメディアアプリケーションで，無料音声・映像通話，イ
ンスタントメッセージが利用可能である．主に日本，東南アジア，スペイン，チリ，ベネズ
エラといった地域で利用されており，5 億人の登録者を抱えるサービスである．Facebook
Messanger とは，Facebook 社が提供するメッセージングアプリである．現在では無料音声
–1–
第1章
研究背景と研究目的
通話，無料映像通話が可能で，無料 SNS の Facebook アカウントがあれば誰でも利用が可
能である．主に日本や，香港，北米，ヨーロッパといった地域で利用されており，2 億人の
MAU（Monthly Active User）にサービスを提供している．WhatsApp とは Facebook 社
が提供するスマートフォン向けのインスタントメッセンジャーアプリケーションである．主
にヨーロッパでの利用者が多く，ラテンアメリカや，インド，メキシコ，ロシアといった地
域にサービス展開されており，5 億人の MAU が存在する．Kakao Talk とは，韓国のカカ
オ社が展開する音声通アプリで，無料音声通話，インスタントメッセージが利用可能である．
主に韓国での利用者が多い．WeChat は中国のテンセント社が展開する特に Voice Chat に
特化したメディアアプリケーションである．主に中国やインド，東南アジア，メキシコと
いった地域でサービス展開されており，3.96 億人の MAU を抱える．Kit Messenger はカ
ナダの Kit Interactive 社が提供するメッセージングアプリで，カナダや米国で 1 億人の登
録者に提供されている．
サービス利用者は，このような多様化したメディアアプリケーションそれぞれで，ユーザ
同士の友人登録を行っている．そして，友人登録されたユーザ同士でコミュニケーション音
声通話やインスタントメッセージなどのコミュニケーションをとりあうのが一般的である．
ネットワークサービス上の友人関係情報はそれぞれのメディアアプリケーションサーバで
ソーシャルグラフとして表されている．このソーシャルグラフは各サービス毎に形成されて
おり，友人登録がなされる毎にソーシャルグラフは大きくなる．
近年のメディアアプリケーションの多様化により，1 人のユーザに対して複数のメディア
アプリケーションで繋がりを持ち，連絡とることが可能になった．一方で，メディアアプリ
ケーションの多様化はユーザへの選択肢を増やし，ユーザのメディアアプリケーション選択
に煩雑さを与えている．
–2–
1.2 表現メディアの種類
1.2
表現メディアの種類
メディアアプリケーションは，それぞれのサービス内容に応じて独自の表現メディアを持
つ．これらは”音声”，”映像”，”テキスト”，”グラフィック”といった従来のマルチメディ
アに留まっておらず，メディアアプリケーションによって様々である．本稿では，独自の調
査により，多様な表現メディアを下記の 17 種にカテゴライズした．
• ビデオ通話
• 音声通話／ IP 電話
• マルチメディアメッセージ
– テキストメッセージ（インスタントメッセージ）
– ボイスメッセージ
– イメージメッセージ（写真送信）
∗ 静止画，写真
∗ 静止画，写真（音声付き）
∗ アニメーション
∗ アニメーション（音声付き）
– ムービーメッセージ（動画送信）
∗ ユーザの保存データ送信
∗ サーバの保持データ送信（ビデオシェア）
• サービスコンテンツ送信
– 音楽
– カレンダー
– ゲーム
• 手書きイメージ重畳（イメージシェア）
• 位置情報，地図情報
• 画面共有
–3–
第1章
研究背景と研究目的
• ファイル共有
近年では端末性能の向上や，通信ネットワークの高速化・大容量化に伴い，従来に比べリ
アルタイム性の高いコミュニケーションが実現可能となっている．そのため，表現メディア
を複数組み合わせて通信することも可能となってきている．
1.3
既存コミュニケーションにおける問題点
スマートフォンにおける現在のメディアアプリケーションを用いたコミュニケーションに
は，2 つの問題が考えられる．次からはそれらについて説明する．
問題 1：コミュニケーションの形が進化していない
節 1.1 でも述べたように，メディアアプリケーションは日々多様化が進んでいる．しか
し，ユーザは 1 回のコミュニケーションにつき，1 つのメディアアプリケーションのみを利
用するのが一般的である．例えば，音声電話に至っては，耳に押し当てて通話するのが一般
的であり，音声以外の表現メディアの利用に制限をかけてしまっている．これは，スマート
フォンが普及し，メディアアプリケーションが多様化する以前から進化していない．
問題 2：円滑なコミュニケーションのためのメディアアプリケーション選択が難しい
ユーザは，表現メディアやメディアアプリケーションを選択する際，メディアアプリケー
ションの特性や対人的要素，話の中身を総合的に加味して，経験則をもとに判断を下して
いる．
メディアアプリケーションの特性には，表現メディアやメディアアプリケーションの持つ
儀礼性や記録・保存性，物理的簡便性が含まれる．対人的要素には，相手との上下関係や間
柄，親密度が含まれる．話の中身は，要件の儀礼やいいにくさ，内容の機密性，展開性（応
答の必要性，発展的な会話の必要性）が含まれる．これらの条件を加味した上で，ユーザは
–4–
1.4 メディアアプリケーション利用形式の進化
自身の経験を元に最終的なメディアアプリケーションの選択判断を行なっている．しかし，
特に早急な応答が必要な連絡については，応答するかどうかは相手の現在の状態に依存する
ため経験則だけでのメディアプリケーション選択判断は難しい．相手の応答がなかった場
合，発信者は再度表現メディアやメディアアプリケーションを選択し直し発信を行う必要が
ある．このように，現環境におけるメディアアプリケーションの選択方法は，円滑なコミュ
ニケーションの実現を害している．
1.4
メディアアプリケーション利用形式の進化
様々なメディアアプリケーションが提供される今，メディアアプリケーション提供者はよ
り利便性の高いサービスを提供しサービス利用者を獲得するため，新たなメディアサービス
を提供するようになった．例えば，KDDI 社が提供するシンクコール [4] では，従来の音声
通話に新たにシンク機能を追加した．シンク機能とは，ユーザ同士の画面を共有できる機能
のことで，画面シンク，カメラシンク，位置シンク，手書きシンクの 4 つの機能からなる．
• 画面シンク： ユーザの利用端末の画面をリアルタイムに共有する．
• カメラシンク： ユーザの利用端末のカメラから撮影された写真や映像を共有する．
• 位置シンク： お互いのユーザの現在位置情報を地図上に表示し共有する．
• 手書きシンク： ユーザ端末上で描画した手書き文字やイラストをリアルタイムに共有
する．他のシンク機能と同時に利用できる．
シンクコールのように，一部サービスでは音声やテキストだけでなく，複数の表現メディ
アを組み合わせてコミュニケーションを行う，フルメディア化が進んでいる．フルメディア
化により，ユーザは１回のコミュニケーションで利用できる表現メディア数が増え，利便性
が向上することが期待できる．しかし，現状では同一メディアアプリケーション間での通信
が前提であり，キャリアの制約などの様々な要因がフルメディア化の普及の大きな障害と
なっている．
–5–
第1章
1.5
研究背景と研究目的
Presence Service による通信可否判断
Presence Service とは，通信相手の現在の状態（Status）を含む Presence 情報をやり取
りするサービスである．ユーザは通信相手の現在の状態を確認することで，利用するメディ
アアプリケーションや表現メディアの選択の判断材料にすることができ，円滑なコミュニ
ケーションを実現することができる [5]．
現在では，Presence Service は Skype や Facebook Massager といったメディアアプリ
ケーションに導入されている．Skype では，”オンライン”，”退席中”，”取り込み中”，”オ
フライン”
，といった Status を提示している [6]．Skype ユーザは通信相手の Status から利
用する表現メディア（音声通話，インスタントメッセージ）や発信タイミングを判断する．
一方で，Skype における Presence 情報は，表現メディア自体の利用可否については明確に
していない．そこで，先行研究 [5] において，表現メディア毎に利用可否状態を付与する手
法が提案されている．
既存環境に Presence Service を導入することで，ユーザは Presence 情報から通信相手が
すぐに応答できるかどうかを判断し，表現メディアやメディアアプリケーションを適切に選
択できるようになる．これにより，ユーザへの利便性向上が期待できる．
1.6
フルメディアコールの必要性
スマートフォン時代で実現する新しいコミュニケーション形態であるフルメディアコール
を提案する．フルメディアコールの概念図を図 1.1 に示す．
フルメディアコールは，複数のメディアアプリケーションを組み合わせることで実現す
る．フルメディアコールの条件を下記に示す．
• スマートフォン及びタブレット端末で利用可能な複数の表現メディアを同時に利用
する．
• 複数のメディアアプリケーションを多重起動し，それぞれのメディアアプリケーション
で通信相手とのメディアセッションを確立して通信する．
–6–
1.6 フルメディアコールの必要性
図 1.1
フルメディアコールの概念図
• 通信相手がすぐに応答することができる最適なメディアプリケーション群が自動で選
定・起動する．
フルメディアコールを実現することは，1.3 節で示した 2 つの問題を解決し，利便性の高
いコミュニケーションをユーザに提供する．また，フルメディアコールは従来の「コミュニ
ケーション時に 1 つのメディアアプリケーションのみを利用する」という一般的な概念を覆
し，新しい文化を創る．
現在の技術では，1.4 節にもあるように，複数のメディアアプリケーションを用いて，そ
れぞれでメディアセッションを確立し通信を行うことは既に実現がなされている．一方で，
通信相手がすぐに応答することのできる最適なメディアアプリケーション群を選定する方法
については現在検討がなされていないため，検討が必要である．本論では，すぐに応答でき
るかどうかを判断するため，Presence Service に着目した．
–7–
第1章
1.7
研究背景と研究目的
研究目的
フルメディアコールの実現は，スマートフォン及びタブレット端末を用いたコミュニケー
ションの利便性を向上させる．本研究はフルメディアコールの実現に向け，最適なメディア
アプリケーション群の自動選定により，ユーザのメディアアプリケーション選択支援を行う
ことを目的とする．
また，達成すべき課題として，新たに提案するフルメディアコールの追加による，ユーザ
への負荷感（コミュニケーション開始への大幅な遅延）を感じさせないこと，メディアアプ
リケーション提供者への負荷（既存メディアサービスへの変更を加えること）を与えないこ
とを挙げる．
1.8
論文の構成
本論では，まず 2 章でフルメディアコールの構想及び必要となる機能群について述べる．
第 3 章では，提案内容である，フルメディアコール実現のための最適メディアアプリケー
ション群選択支援方式について述べる．第 4 章では提案方式の実現可能性について，実証実
験の結果を交え考察する．第 5 章では，本研究の総括を述べ，今後の課題についても述べる．
–8–
第2章
フルメディアコール
2.1
緒言
本章では，提案するフルメディアコールの構想やフルメディアコール実現のために必要と
なる機能群について述べる．
2.2
フルメディアコールの構想
1.6 節でも述べたとおり，フルメディアコールとは，スマートフォンやタブレット端末で
利用できる表現メディアをメディアアプリケーション群の多重起動により利用する方式で
ある．通信相手の Presence 情報に基づき，通信相手が直ぐに応じることのできる最適なメ
ディアアプリケーション群を自動起動する．メディアアプリケーション毎に通信相手とメ
ディアセッションを確立して通信を行う．スマートフォン及びタブレット端末で利用できる
表現メディアには，1.2 節で述べた 17 種が該当し，これらの表現メディアのうち複数を利用
することをフルメディアと呼ぶ．また，利用する表現メディア数が多いほど，フルメディア
性が高いと呼ぶ．
フルメディアコールの動作を図 2.1 に示す．
フルメディアコールの発信ユーザが連絡相手を選択すると，フルメディアコール機能群は
最適なメディアアプリケーション群を選定するために着信ユーザの保有するメディアアプリ
ケーション群の把握のために確認動作を行う．フルメディアコール機能群は予め取得して
いた着信ユーザの Presence 情報から，最適メディアアプリケーション群として選定するメ
–9–
第2章
フルメディアコール
図 2.1 フルメディアコールの動作
ディアアプリケーション群の絞り込みを行う．その後，絞り込んだメディアアプリケーショ
ン群から最適なメディアアプリケーション群を選定し，発信者に通知する．発信者が発信動
作を行うと，フルメディアコール機能群は発着信ユーザの該当するメディアアプリケーショ
ン群を起動し，メディアアプリケーション毎にメディアセッションの確立を行う．これによ
り，フルメディアコールによるコミュニケーションが開始される．
フルメディアコールが実現することで，ユーザは従来のコミュニケーションに比べ得られ
る表現メディアが増え，利便性を高めることができる．さらに，今後アプリケーションの組
– 10 –
2.3 フルメディアコール機能群
み合わせ次第で，自動外国語翻訳通話や音声字幕表示機能，通話内容のテキスト化といっ
た，従来のコミュニケーションでは実現が難しかったコミュニケーションが可能となる．
2.3
フルメディアコール機能群
フルメディアコールは，ユーザが保有するメディアアプリケーション群の把握機能，
Presence 通知機能，最適メディアアプリケーション群の自動選択機能，メディアアプリケー
ション群の多重起動機能によって構成される．次から，それぞれの機能について説明する．
2.3.1
保有するメディアアプリケーション群の把握機能
フルメディアコールでは，発着信ユーザ双方の保有しているメディアアプリケーション群
を相互に把握し合う必要がある．これは，通信相手と共通して利用しているメディアアプリ
ケーション群の中から，最適メディアアプリケーション群を自動選択するために必要とな
る．またフルメディアコールでは，ユーザ同士がどのメディアアプリケーションで連絡がと
れるか（ユーザ同士が友人認証を済ませているかどうか）や，それぞれのメディアアプリ
ケーション群の利用状況についても取得する．これらの情報から最適なメディアアプリケー
ション群の判断を行う．
2.3.2
Presence 通知機能
フルメディアコールでは，最適なメディアアプリケーション群選択支援のために，Presence
Service を用いる．フルメディアコール実現のための Presence 情報には，ユーザの表現メ
ディアの利用可否状態 [5]，メディアアプリケーションの利用可否状態の情報が必要となる．
これらの Presence 情報は動的に取得するのが望ましい．Presence 情報を動的に判断する手
法については，様々な手法が提案されている．
• 端末の電源が On か Off かをやり取りする方法
• 加速度センサを用いて推測する方法 [7]
– 11 –
第2章
フルメディアコール
• 位置情報を元に推測する方法
– GPS を用いた推定法
– 無線 LAN による推定法 [8]
– ビーコンを用いた推定法
– LED レーザを用いた推定法
– NFC を用いて位置情報を取得する方法
• カレンダーや TODO といった外部サービスと同期して位置情報を推定する方法
• 音声通話アプリケーションによって通話中かどうかを判断する方法
• サービスのログイン状態により判断する方法
Presence 情報を動的に取得するためには，位置情報や端末のセンサ情報とユーザの行動情
報を紐付けておくことで実現が可能となる [5]．しかし，動的にかつ機械的に Presence 情報
を取得するのは正確性に欠けるため，現時点では実用に至っていない．メディアアプリケー
ションの利用可否状態は，ログイン状態により動的に Presence の取得が可能である．ログ
イン状態から判断し，Presence Service を導入しているサービスとして Skype や Facebook
Messanger が挙げられる．しかし，ほとんどのサービスが，手動で Presence 情報を入力す
るか，メディアサーバとメディアアプリケーションの通信が可能かどうか定期的に通信し
あって確認するなどの方法でしか，Presence 情報の取得はできない．現在提案されている
Presence 情報の動的取得方法を幾つか組み合わせることで，Presence 情報の正確性が向上
することが見込まれるが，Presence 情報の動的取得方法については大きな課題であると言
える．
2.3.3
最適メディアアプリケーション群の自動選択機能
フルメディアコールでは，多重に起動するメディアアプリケーション群を，自動で選定し
起動する．選定方法を下記に記述する．
1. 通信相手が現在利用可能であるメディアアプリケーション群である．各メディアアプリ
– 12 –
2.3 フルメディアコール機能群
ケーションの利用可否は Presence 情報のやり取りによって判断される．
2. 最適メディアアプリケーション群は，主要メディアアプリケーションと，補助メディア
アプリケーション群からなる．
• 主要メディアアプリケーションは，コミュニケーションの主となる表現メディアを
有するメディアアプリケーションである．該当する表現メディアには，ビデオ通
話，音声通話，マルチメディアメッセージが該当する．主要メディアアプリケー
ションは，フルメディアコール利用者同士のコミュニケーション履歴や，各メディ
アアプリケーション利用回数を元に算出される．
• 補助メディアアプリケーション群は，主要メディアアプリケーションでは表現しき
れない表現メディアをもつアプリケーションの集合である．補助メディアアプリ
ケーション群は，主要メディアアプリケーションの持つ表現メディアとの可算集合
が最大となるように選定される．
2.3.4
メディアアプリケーション群の多重起動機能
フルメディアコールでは，端末にインストールされているメディアアプリケーションを複
数利用することでフルメディアを実現する．メディアアプリケーション群を多重起動するこ
とで，従来のメディアアプリケーション単一では表現できない，不足している表現メディア
を他メディアアプリケーション群によって補う．起動するメディアアプリケーション群は，
2.3.3 節で述べた手法で選定される．
1.4 節で述べたシンクコールのように，現時点で複数のメディアアプリケーションを同時
に起動し，それぞれでメディアセッションを確立することは可能であり，既に実現がなされ
ている．
– 13 –
第2章
2.4
フルメディアコール
最適メディアアプリケーション群選択支援の応用
フルメディアコールは，Presence 情報から判断されるユーザの利用可能なメディアアプ
リケーション群を選定，起動し通信を行う．しかし，ユーザの Presence 状態によっては単
一の表現メディアやメディアアプリケーションのみの利用しかできず，フルメディアを実現
できない可能性も想定しうる．しかし，本章で述べたフルメディアコールを構成する各機能
を導入することにより，単一の表現メディアやメディアアプリケーションのみの推薦誘導を
行うことも可能となる．また，通信相手の Presence 状態が変化したタイミングで発呼を行
うといった自動発呼予約など，Presence 情報との組み合わせから，様々なサービス展開が
期待できる．
2.5
結言
本章では，提案するフルメディアコール実現のため，フルメディアコールの全体構想や必
要な機能群の説明した．フルメディアコール実現のためには，保有するメディアアプリケー
ション群の把握機能，Presence 通知機能，最適メディアアプリケーション群の自動選択機
能，メディアアプリケーション群の多重起動機能が必要となる．メディアアプリケーション
群の多重起動機能については，既に実現済みであるが他 3 つの機能については実現がなされ
ていない．次章では，フルメディアコール実現に必要な最適メディアアプリケーション群選
択支援方式として，保有するメディアアプリケーション群の把握機能，Presence 通知機能，
最適メディアアプリケーション群の自動選択機能それぞれの実現方法について述べる．
– 14 –
第3章
最適メディアアプリケーション群選
択支援方式
3.1
緒言
本章では，フルメディアコールを実現するための最適メディアアプリケーション群選択支
援方式について提案を行う．また，提案するシステム構成や動作，最適メディアアプリケー
ション群選定アルゴリズムについて説明する．
3.2
提案方式の概要
提案する最適メディアアプリケーション群選択支援方式は，フルメディアコールにおい
て，多重起動させるメディアアプリケーション群の選定を行うものである．最適メディアア
プリケーション群推薦のため，2.3 節で説明した下記機能が必要となる．
• ユーザの保有するメディアアプリケーション群の把握機能
• Presence 通知機能
• 最適メディアアプリケーション群の自動選択機能
また，本提案における，最適なメディアアプリケーションとは，下記 2 つの条件を満たすも
のとする．
• ユーザがすぐに応答可能であるメディアアプリケーションとする．つまり，Presence
– 15 –
第3章
最適メディアアプリケーション群選択支援方式
情報から判断されるメディアアプリケーションの利用可否状態が”利用可能”である．
• 発着信ユーザ双方にとって使い慣れたメディアアプリケーションである．
なお，最適メディアアプリケーション群とは，各メディアについて最適と判断されたメディ
アアプリケーションの集合を表す．また，2.3.3 節で述べた通り，最適メディアアプリケー
ション群は主要メディアアプリケーションと補助メディアアプリケーション群から構成さ
れる．
3.3
提案方式の機能構成
提案する最適メディアアプリケーション群選択支援方式の機能構成を図 3.1 に示す．本
提案では，フルメディアコール利用端末が既にメディアアプリケーション群及びメディア
サーバ群によるサービスを利用しているものとする．提案手法では新たに，Presence アプ
リケーション，Presence サーバ，通知先 List Server，フルメディアコールアプリケーショ
ン，フルメディアコールサーバを追加する，以下では，図に示す構成要素についてそれぞれ
説明する．
• メディアアプリケーション（Media AP： MA）
表現メディアを用いるコミュニケーション用アプリケーションである．フルメディア
コール利用端末には，複数のメディアアプリケーションがインストールされている．
• メディアサーバ（Media Server： MS）
メディアアプリケーションサービス毎に利用されるサーバ群である．メディアセッショ
ンの確立や，ユーザ登録情報，連絡先リストの管理等に用いられている．
• Presnce アプリケーション（Presence Application： PA）
ネットワーク状況やユーザからの入力，端末の状況によって Presence 情報を取得・生
成するアプリケーションである．また，通信相手の Presence 情報の取得も行う．フル
メディアコール利用者の Presence 情報は後述する Presence サーバに送信される．
• Presence サーバ（Presence Server： PS）
– 16 –
3.3 提案方式の機能構成
図 3.1
提案システムの構成
Presence アプリケーションから Presence 情報を受け取り，集約・加工するサーバであ
る．集約された Presence 情報は，連絡先 List Server を介して Presence 情報閲覧者に
通知される．
• 連絡先 List Server（LS）
Presence 情報発信者（Presentity）に対する Presence 情報閲覧者（Watcher）を連絡
先リストとして生成・管理するサーバである．Presnce サーバから受け取った Presence
情報を，連絡先リストを元にそれぞれの Watcher に送信する．
• フルメディアコールアプリケーション (Full media Call Application： FCAP）
メディアアプリケーション間の連携や最適なメディアアプリケーション群の選定を行う
アプリケーションである．FCAP は最適なメディアアプリケーション群を選定次第，メ
ディアアプリケーションの多重起動を行う．また，メディアアプリケーション群選択支
援のために各メディアアプリケーションの利用履歴や，ユーザとの連絡履歴を保存・管
理する．
– 17 –
第3章
最適メディアアプリケーション群選択支援方式
• フルメディアコールサーバ (Full media Call Server： FCS）
1 ユーザが持つ，各メディアアプリケーションの ID を集約し，管理するサーバである．
また，メディアサーバ群からメディアアプリケーション毎の友人承認状況を取得する．
取得した情報からユーザ同士の繋がりを表すソーシャルグラフを生成し，ユーザ同士の
連絡可能なメディアアプリケーションを把握・管理する．
3.4
動作内容
提案方式における最適メディアアプリケーション群選択動作を下記に示す．
1. フルメディアコール発信者の FCAP は，通信相手の保有するメディアアプリケーショ
ン群を把握する．
2. フルメディアコール発信者の FCAP は，通信相手の Presence 情報を受け取り，FCAP
内のデータベースに Presence 情報を格納する．
3. フルメディアコール発信者の FCAP は，最適メディアアプリケーション群の自動選定
を行う．
（a）FCAP のデータベースから通信相手の情報を取り出す．
（b）取り出した Presence 情報から，利用可能なメディアアプリケーション群の絞り込
みを行う．
（c）主要メディアアプリケーションの選定を行う．
（d）補助メディアアプリケーション群の選定を行う．
上記の動作により，通信相手がすぐに応じることのできる最適なメディアアプリケーショ
ン群を自動で選定し，フルメディアを実現する．以下では，それぞれの動作内容について詳
しく説明する．
– 18 –
3.4 動作内容
3.4.1
ユーザの保有するメディアアプリケーション群の把握
フルメディアコール利用者の FCAP は，フルメディアコールを利用する事前準備として，
連絡相手が利用するメディアアプリケーション群を把握する．これは，FCAP がフルメディ
アコール開始時に利用する最適なメディアアプリケーション群を自動で選定するためであ
る．連絡相手ユーザの保有するメディアアプリケーション群把握のフローを図 3.2 に示す．
図 3.2
連絡相手ユーザの保有するメディアアプリケーション群把握のフロー
発着信ユーザの FCAP はそれぞれ，メディアアプリケーションからメディアアプリケー
ション ID，Presence アプリケーションからは Presence ID を取得する．FCAP は各メディ
アアプリケーションの ID と Presence ID を集約し，フルメディアコールの個人識別 ID
（FC ID）と集約した情報を FCS に登録する．FCS はメディアサーバに対して，各メディ
アアプリケーション ID の友人リストを取得し，ソーシャルグラフを生成する．FCS は生成
したソーシャルグラフを元に，発着信ユーザが共通して利用するメディアアプリケーション
を判断し，発着信ユーザ双方に，連絡先リストとして共通して利用しているメディアアプリ
ケーションとその ID を送信する．また，FCS には通知先 List Server に対して，Presence
ID と共通して利用しているメディアアプリケーションを通知し，Presence 通知を可能とす
– 19 –
第3章
最適メディアアプリケーション群選択支援方式
る．これらの動作により，FCAP は通信相手と連絡を取り合うことが可能なメディアアプ
リケーションを把握する．
3.4.2
Presence 通知
FCAP では，最適メディアアプリケーション群を推薦するため，Presence 情報から判断
される現在利用可能なメディアアプリケーションを取得する．また，互いのユーザにとって
使い慣れたメディアアプリケーションを選定するために，着信ユーザのメディアアプリケー
ションの利用回数についても Presence 情報として通知する．図 3.3 に最適メディアアプリ
ケーション群選定のための Presence 通知フローを示す．
Presence アプリケーションはメディアアプリケーションや，ユーザからの入力，端末から
の自動取得を通じて Presence 情報を取得・更新する．本提案に必要な Presence 情報はメ
ディアアプリケーションの利用可否，メディアアプリケーションの利用回数（利用率）であ
る．メディアアプリケーション利用可否情報は端末の状態や，メディアアプリケーションへ
のログイン状態から取得する．メディアアプリケーションの利用回数（利用率）は，FCAP
がメディアアプリケーションの利用履歴を保存し，その情報をやりとりする．
Presence アプリケーションが取得した Presence 情報は Pressence サーバに送信・保存さ
れる．Presence サーバは，取得した Presence 情報を通知先 List Server に送信し，通知先
リストに従って Presence 情報を閲覧者（図中の発信者）に発信する．
フルメディアコール発信時，発信ユーザが通信相手を選ぶと，発信ユーザの Presence ア
プリケーションは Presence サーバに対して Presence 情報の更新がなされていないかを問
い合わせ，再取得要求を行う．その後，発信ユーザの Presence アプリケーションは取得し
た Presence 情報を，FCAP に送り，次節で示す最適メディアアプリケーション群選定のア
ルゴリズムを適応する．
– 20 –
3.4 動作内容
図 3.3
3.4.3
最適メディアアプリケーション群選定のための Presence 通知フロー
最適メディアアプリケーション群の自動選択
最適メディアアプリケーション群選定のフローを図 3.4 に示す．
最適メディアアプリケーション群の選定のため，予め FCAP のデータベースに格納して
いた情報を取得する．なお，FCAP のデータベース内にはメディアアプリケーション毎に
下記の情報を格納しているものとする．
– 21 –
第3章
最適メディアアプリケーション群選択支援方式
図 3.4 最適メディアアプリケーション群選定のフロー
• メディアアプリケーション名
• メディアアプリケーションが保有する表現メディア
• 発着信ユーザ同士で連絡を取り合った回数
• 発信ユーザのメディアアプリケーション利用回数
• 着信ユーザのメディアアプリケーション利用回数
• 着信ユーザのメディアアプリケーション利用可否情報（Presence 情報）
なお，データベースからの取得対象となるメディアアプリケーションは，3.4.1 節で述べ
– 22 –
3.4 動作内容
た手法によりユーザ同士で連絡を取り合うことが可能と確認されたものである．
次に，データベースから取得した着信ユーザのメディアアプリケーション利用可否情報を
各メディアアプリケーションに適応する．メディアアプリケーションが”利用不可能”であ
れば，選定に必要となる情報を無効化し，最適メディアアプリケーション群の候補から取り
除く．ここで，選定に必要となる情報とは発着信ユーザの連絡履歴，発信ユーザのメディア
アプリケーション利用回数，着信ユーザのメディアアプリケーション利用回数の 3 情報を指
す．もし，利用可能なメディアアプリケーションが 1 つもない場合はフルメディアコールの
発信は行えない．
その後，主要メディアアプリケーション選定，補助メディアアプリケーション群選定の順
に行う．以降では，主要メディアアプリケーションと補助メディアアプリケーション群の選
定方法についてそれぞれについて説明する．
主要メディアアプリケーションの選定
主要メディアアプリケーションとは，コミュニケーションの主となる表現メディアであ
る，
”ビデオ通話”
，
”音声通話”
，
”テキストメッセージ”のいずれか，あるいは全てを持つメ
ディアアプリケーションを指す．これ以降，この 3 つの表現メディアを主要表現メディアと
呼ぶ．主要メディアアプリケーションの選定には，発着信ユーザ同士の連絡履歴，発信ユー
ザのメディアアプリケーション利用回数，着信ユーザのメディアアプリケーション利用回数
の 3 つの情報を用いる．主要メディアアプリケーション選定のフローを図 3.5 に示す.
まず，FCAP は発信ユーザの端末にあるメディアアプリケーション群から，主要表現メ
ディアを保持するメディアアプリケーションを検索する．主要表現メディアは”ビデオ通
話”，”音声通話”，”テキストメッセージ”の順に優先付けする．まずは，”ビデオ通話”を
保有する全てのメディアアプリケーションについて，発着信ユーザ同士の連絡に用いた履歴
回数の最大値が 0 であるかを判断する．最大値が 0 より大きい場合は，利用履歴が最大値
をもつメディアアプリケーションを最適主要メディアアプリケーションとして選定する．も
– 23 –
第3章
図 3.5
最適メディアアプリケーション群選択支援方式
主要メディアアプリケーション選定のフロー
し，最大値が 0，つまり”ビデオ通話”を保有するすべてのメディアプリケーションについ
て連絡で用いたことがない場合は，発着信ユーザの”ビデオ通話”を保有するメディアアプ
リケーション利用回数による選定を行う．
発信ユーザ，着信ユーザそれぞれで，”ビデオ通話”を保有するメディアアプリケーショ
ンの利用回数の総和をとる．もし，発信ユーザも着信ユーザも”ビデオ通話”を利用したこ
とがある場合，つまり総和が 0 より大きい場合，それぞれのメディアアプリケーション利用
回数と総和を用いて，メディアアプリケーション利用率を求める．発信ユーザの各メディア
アプリケーション利用率と着信ユーザの各メディアアプリケーション利用率が最大のものを
最適主要メディアアプリケーションとして選定する．
もしいずれかの総和が 0 であれば，主要表現メディアを”音声通話”として，”ビデオ通
話”と同様の判断を行う．”ビデオ通話”についても，最適主要メディアアプリケーション
– 24 –
3.4 動作内容
が選定できなければ，”テキストメッセージ”でも同様の判断を行う．それでも該当しなけ
れば，フルメディアコールの発信は行わない．
以上の選定アルゴリズムを用いることで，主要メディアアプリケーションは現在利用可能
であり，使い慣れているものという最適メディアアプリケーションの条件を満たすことが可
能となる．
このアルゴリズムによって選定された最適主要メディアアプリケーションを元に，補助メ
ディアアプリケーション群を選定する．
補助メディアアプリケーション群の選定
補助メディアアプリケーション群とは，主要メディアアプリケーションの保有しない表現
メディアを持つアプリケーション群である．主要メディアアプリケーションで表現しきれな
い表現メディアを，メディアアプリケーション群によって補い，高いフルメディア性を実現
する．
補助メディアアプリケーション群選定の要因は以下の通りである．
• ユーザ同士で連絡を取り合うことが可能なメディアアプリケーションである．
• 通信相手の Presence 情報から，現在利用が可能であるメディアアプリケーションで
ある．
• メディアアプリケーションの組み合わせによる，表現メディアの重複はない．
• 最適な補助メディアアプリケーション群は，表現メディアの可算集合が最大となるメ
ディアアプリケーションの組み合わせである．
これらの条件を満たす，最適な補助メディアアプリケーション群を選定し，フルメディア
コールを実現する．
– 25 –
第3章
3.5
最適メディアアプリケーション群選択支援方式
結言
本章では，フルメディアコール実現のため最適メディアアプリケーション群選択支援方式
について提案を行なった．最適メディアアプリケーション群選択支援方式実現に必要となる
3 つの機能（ユーザの保有するメディアアプリケーションの把握機能，Presence 通知機能，
最適メディアアプリケーション群の自動選択機能）についてそれぞれ提案を行なった．
提案手法では，Presence アプリケーション，Presence サーバ，通知先リストサーバ，フ
ルメディアコールアプリケーション，フルメディアサーバを新たに追加した．これらと，現
環境で運用されているメディアアプリケーションとそのメディアサーバとの連携により最適
メディアアプリケーション群選択支援が行えるようになる．
– 26 –
第4章
評価検証
4.1
緒言
本章では，フルメディアコール実現のための最適メディアアプリケーション群推薦機能に
ついて，実用可能かどうかを検証する．検証実験方法と検証結果，考察について述べる．
4.2
概要
提案システムにより，最適なメディアアプリケーションの推薦が実際に実用できるかを検
証するため，最適メディアアプリケーション群推薦アプリを作成・実装し，実際に推薦にか
かる時間について測定を行なった．また，その測定結果をもとに，推薦にかかる時間が実用
可能範囲内であることを確認し，提案するフルメディアコールを実用の必要性を示した．
4.3
最適メディアアプリケーション群選択支援方式の検証
提案手法によって最適なメディアアプリケーション群を提示するため，提案内容につい
て実際に Android アプリを作成した．今回作成したアプリは，フルメディアコールアプリ
ケーションの推薦動作を擬似的に行うものである．通信相手の Presence 情報を既に取得済
みで，作成した FCAP 内のデータベースに格納されているものとして，推薦動作を行なっ
た．なお，ここでいう推薦動作とは，3.4.3 節で述べたアルゴリズムを適応したものである．
今回は，ユーザが実際に推薦動作を取り入れた場合に，最適メディアアプリケーション群の
判断にどれ位の処理時間を要したかについて測定する．また，提案手法により，17 種の表
– 27 –
第4章
評価検証
現メディアのうち，実際にどれだけの表現メディアが提示されるのかについても計測を行
なった．
4.3.1
検証環境
本研究の実験は，Google 社が提供する Android アプリ開発環境である Android Studio1.4
を用いた．開発言語には Java を用いた．また，Presence 情報を格納するデータベースと
して，RDBMS（Relational Database Management System）である SQLite[9] を用いた．
作成したアプリは Android4.4 で動作するように設定した．
検証に用いる端末として，Google 社の Nexus7 を用いた．表 4.1 に検証に用いた google
Nexus7 の性能を示す．
表 4.1 Google Nexus7 の性能
4.3.2
項目
性能
OS
Android 4.4.4 KitKat
ディスプレイ
7 インチ IPS
解像度
1920 × 1200（WUXGA）
プロセッサ
1.5GHx クアッドコア
RAM
2GB
ストレージ
16GB
検証方法
作成したアプリケーションを実際に動作させ，推薦動作にかかる時間を測定した．作成し
たアプリケーションによる検証画面を図 4.1 に示す．
提案手法実装にあたり，構築した FCAP 内のデータベースには，以下の Presence 情報が
登録されている．
– 28 –
4.3 最適メディアアプリケーション群選択支援方式の検証
図 4.1
作成したアプリケーションによる検証画面
• Caller テーブル ： 発信者に関する情報を集約
– ServiceName ： メディアアプリケーションサービス名
– UserHistory ： 発信相手との連絡回数
– MyUsage ： 発信ユーザのメディアアプリケーション利用回数
• Called テーブル ： 着信者（連絡相手）に関する情報の集約
– ServiceName ： メディアアプリケーションサービス名
– YourUsage ： 着信ユーザのメディアアプリケーション利用回数
– RoW ： メディア利用可否情報
• MediaApp テーブル ： メディアアプリケーションの保有するメディアを管理
– ServiceName ： メディアアプリケーションサービス名
– 29 –
第4章
評価検証
– ServiceType1 - ServiceType17 ： メディアアプリケーションの保有する表現メ
ディア
UserHistory は 0 以上 10 以下，MyUsage，YourUsage はそれぞれ 0 以上 1000 以下の値
をランダムに格納した．また RoW に格納されている利用可否状態については利用可能，利
用不可能のいずれかがランダムに格納されている．また，LINE や Skype などの現在サービ
ス提供がなされているメディアアプリケーション 32 個について独自に調査を行ったところ，
１つのメディアアプリケーションにつき平均で 4.57 種（カテゴライズした表現メディアの
26.9 ％）の表現メディアを保持している．本検証では，表現メディア１つあたり 27 ％の確
率で保持するように設定した．
なお本検証では，データベースから読み出す時間，主要メディアアプリケーション選定に
かかる時間，補助メディアアプリケーション群の取得にかかる時間，データベースの読み出
しからアルゴリズム適応までにかかるトータル時間の 4 つについてそれぞれメディアアプリ
ケーション数を変化させて計測を行なった．
4.4
検証結果
本検証では，データベースに格納されている各情報の取得から，主要メディアアプリケー
ション，補助メディアアプリケーション群を選定し提示するまでの時間を計測した．
4.4.1
メディアアプリケーション数の変化における計測結果
メディアアプリケーション数を変えた時の計測結果について検証した．表 4.2 に実験によ
る計測結果を示す．またメディアアプリケーション数の変化時の計測結果を図 4.2 に示す．
なお，計測値は施行回数 500 回の平均値である．選定されたメディアアプリケーション群に
よって表現メディアの可算集合が最大となっているかどうかは出力結果の目視により判断し
た．図中の黄色のグラフは最適メディアアプリケーション群選定にかかったトータル時間を
表す．青のグラフはデーターベースからの取得にかかった時間を表す．灰色のグラフは補助
– 30 –
4.4 検証結果
メディアアプリケーション群の選定，橙色のグラフは主要メディアアプリケーションの選定
にかかった時間を表す．
表 4.2
4.4.2
実験による検証結果
MA 数 [個]
10
20
30
40
50
DB Serch [ms]
2.791381
3.507019
4.197876
4.970275
5.769531
Main [ms]
0.022766
0.028747
0.062805
0.065185
0.071777
Sub [ms]
0.094299
0.234436
0.26123
0.529541
0.633911
Total [ms]
2.911987
3.774414
4.526123
5.569519
6.479614
MA 数 [個]
60
70
80
90
100
DB Serch [ms]
6.560974
6.560058
7.358398
8.032897
9.03363
Main [ms]
0.088562
0.070312
0.07843
0.079711
0.119506
Sub [ms]
0.996765
1.752319
1.879821
2.342895
3.517944
Total [ms]
7.650146
8.383739
9.320983
10.45996
12.676086
表現メディアの網羅率
提案手法により，提示した 17 種の表現メディアのうち，どれだけの表現メディアを網羅
できているのか検証した．表現メディア網羅率の計測結果を図 4.3 に示す．なお，計測値は
施行回数 500 回の平均値である．
4.4.3
検証結果からの考察
表 4.2 の結果からメディアアプリケーションが 100 個以下の場合において，FCAP にお
ける推薦処理時間は 12.68ms 以下であることがわかる．このうちデータベースからの情報
取得が 9.03ms と約 71 ％を占めている．一方で主要メディアアプリケーションの選定及び
補助メディアアプリケーション群の選定からなる最適メディアアプリケーション群の選定に
– 31 –
第4章
図 4.2
メディアアプリケーション数の変化時の計測結果
図 4.3
表現メディアの計測結果
– 32 –
評価検証
4.5 結言
は 3.62ms であった．この結果から，フルメディアコール発信時にユーザに対して与える影
響がほぼないといえる．また，MMD 総研の調べ [10] によると，一人あたりのスマートフォ
ンアプリインストール数は平均で 22 個である．メディアアプリケーション数 22 個におけ
る本提案システムの実測結果は 3.77ms 以上 4.53ms 以下である．このことからも，提案手
法の導入によるユーザへの発信時の待ち時間に対しての影響はほぼないといえる．
一方で，表現メディアにおける網羅率は，メディアアプリケーション数 100 個の場合，網
羅率 89.5 ％（平均 15.21 種）となっており，これは従来の表現メディア数 4.57 種のおよそ
3.3 倍となっている．このことから，十分にフルメディア性は高められ，ユーザの利便性向
上に繋がると考える．しかし，一人あたりのスマートフォンアプリインストール平均数であ
るメディアアプリケーション数 22 個の場合，網羅率は 65.24 ％（平均 11.09 種）と従来のお
よそ 2.43 倍となった．この原因は，メディアアプリケーション数が少なさから表現メディ
アの重複や不足分を補うことができなかったことが考えられる．このことから，現環境にお
いてフルメディアコールを実現するためには，少数の表現メディアに特化したメディアアプ
リケーションの導入する必要があると考えられる．
4.5
結言
本提案ではフルメディアコール実現のため，最適メディアアプリケーション群選択支援手
法の提案を行なった．その実現可能性を示すため，Android アプリ構築による検証を行い，
ユーザのフルメディアコール発信動作に影響がないことを示した．しかし，今回の検証は
端末内での処理の一部を行なったものにすぎない．実際は Presence 情報の取得や，データ
ベースの更新，またユーザ数増加によるデータベースからの情報取得処理の遅延といった要
因が影響してくる．特に，ソーシャルネットワークサービスが広く普及した現在の環境にお
いて，友人の増加によるデータベースからの情報取得処理遅延の影響は大きいと考えられ，
データベースの設計法や取得法に十分な検討が必要である．
– 33 –
第5章
結論
5.1
まとめ
スマートフォンで利用できるメディアアプリケーション（音声通話アプリやメッセージア
プリなど）は多様化する中，利用者は一人のユーザに対して複数のメディアアプリケーショ
ンでの連絡が可能となった．しかし，多様なメディアアプリケーションサービスが提供され
る環境の中，利用者は一般的に１つのメディアアプリケーションでのコミュニケーションし
か行わない．例えば，音声電話では耳に押し当てて通話するのが一般的であり，音声以外の
メディアの利用に制限がかかっている．これは，コミュニケーションアプリケーションが
多様化する以前に比べ何も進化していない．また，メディアアプリケーションの多様化は，
ユーザにメディアアプリケーション選択の煩雑さを与えている．どのメディアアプリケー
ションであれば相手が応じられるのかは経験則を基に判断するしかないため，実際に相手に
応じられない可能性も高い．
そこで，フルメディアコールを提案した．フルメディアコールとは，知人である１人の
ユーザに対して複数のメディアアプリケーションで同時にコミュニケーションすることであ
る．フルメディアコールの実現のためには，多様化しているすべてのメディアアプリケー
ションを適切に連動させなければならない．その中でも，最適なメディアアプリケーション
の選択を支援することはフルメディアコールの重要な構成要素のひとつである．
本稿では，最適メディアアプリケーション選択支援の実現方法として Service に着目し，
フルメディアコールのための連絡相手の Presence に基づいた最適なメディアアプリケー
ション選択支援システムを提案した．
– 35 –
第 5 章 結論
提案システムでは，3 つの機能を新しく追加した．1 つ目は，通信相手の利用可能なメディ
アアプリケーションを取得する機能である．これを実現するために新たにフルメディアコー
ルサーバを設け，ユーザのメディア利用状況を中央管理した．2 つ目は Presence 通知機能
である．これは新しく，Prssence サーバと通知先 List Server を設けることで Presence 情
報のやり取りを行うことができるようにした．しかし，Presence 情報の取得方法について
は，完全に自動で行うことが難しいため，今後の課題である．3 つ目は最適メディアアプリ
ケーション群を自動選択する機能である．これは，発着信ユーザ双方の Presence 情報をも
とに最適なメディアアプリケーション群を選定提示させた．最適メディアアプリケーション
群は主要メディアアプリケーションと補助メディアアプリケーション群からなる．主要メ
ディアアプリケーションとは，”ビデオ通話”，”音声通話”，”テキストメッセージ”の表現
メディアのうちいずれか，あるいはすべてを保有するメディアアプリケーションを指す．主
要メディアアプリケーションは発着信ユーザ同士の連絡履歴や発着信ユーザそれぞれのメ
ディアアプリケーション利用回数から判断する．補助メディアアプリケーション群とは，主
要メディアアプリケーションが保有しない表現メディアを保持するメディアアプリケーショ
ン群で，主要メディアアプリケーションの不足する表現メディアを補う．補助メディアアプ
リケーション群の選定は，表現メディアの可算集合が最大となるような組み合わせを計算す
ることで求める．
これらの検証のために最適メディアアプリケーション群を自動選択するアプリを作成し，
最適メディアアプリケーション選択にかかる時間を計測した．その結果，メディアアプリ
ケーション数が 22 個（スマートフォンユーザに利用されているアプリ数の平均）のとき，
最適メディアアプリケーションの選択は 3.77ms 以上 4.53ms 以下で行えた．以上より，提
案方式はフルメディアコール利用者の発信動作に遅延の影響を与えずに最適なメディアアプ
リケーション選択ができることを確認した．
– 36 –
謝辞
本研究を進めるにあたり．指導教員として甚大なご指導を頂きました，高知工科大学情報
学群の島村和典教授に心より感謝いたします．研究では，方向性が振れる意志の弱い私に熱
心に的確なアドバイスを頂きました．また，研究だけでなく，就職活動や社会人としての振
る舞い方，人付き合いについて，お酒の場などにおけるマナーについてもたくさんのアドバ
イスを頂けたことを深く感謝しております．私自身が院進学を行うか悩んでいた際，先生か
ら頂いた一喝のお言葉が私の院進学の意思を固めたきっかけになりました．先生から頂いた
本はくよくよしがちな私の指針となるような内容で，人生の教本にしたいと思っておりま
す．先生からたくさんのことを学ばせて頂いた研究室生活 4 年間は私にとっての人生の宝
です．また，学部時代より研究の副査として熱いご指導頂いた高知工科大学福本昌弘先生，
植田和憲先生には心より感謝申し上げます．福本先生からは時には厳しくも温かいご指導を
頂き，そのご期待に応えるべく眠れぬ夜を過ごしたことは私にとって大変心に残っておりま
す．また，植田先生には，私の中身のない研究の相談に伺った際も，研究の進め方や考え方
に至るまで的確かつ優しくご教授いただけたことは，研究に焦りを覚えていた私にとって大
変心の救いとなりました．福本昌弘先生，植田和憲先生の御二方には本研究論文の副査をお
引き受けくださり，貴重なご助言，ご指摘を頂きましたこと，心より厚くお礼申し上げます．
また，唯一の研究室生同期として，時には茶々を入れあい，また時には多くのことを学ば
せてくれた島村研究室修士 2 年 竹本万里雄氏にはこの 4 年間本当にお世話になりました．
研究だけでなく，数々の研究室活動で頼りっぱなしでした．本当にお世話になりました．そ
して隣で高々とキーボードのエンターキーを弾き，騒音問題でご迷惑をお掛けしたことを合
わせてお詫び申し上げます．同じ IoN グループとして共に研究を進めて来た学部 4 年の中
村真也氏，高野雅弘氏には私達修士生が研究に打ち込めるよう率先して研究室の裏方のお仕
事をしてもらいました．中村氏は，遅くまで研究室に残った私に温かいチキン南蛮弁当を
買ってきてくれたことは本当に感謝しています．また高野氏は明るい性格で研究室を笑いの
– 37 –
謝辞
渦に巻き込んでくれ，研究室の雰囲気を良くしてくれたことは今でもよく覚えています．今
後もその明るい性格で，周りの人達を明るく励ましてあげてください．学部 4 年 宮野拓洋
氏には，私が実験系のプログラムで悩むときにたくさんのアドバイスを頂き，どちらが先輩
かわらないほどたくさんのことを教えてもらいました．山崎秋音氏には研究室の伝統である
久保商店の店長として，忙しい中私の主食のカップ麺を買ってきてくれたことは本当に感謝
の思いでいっぱいです．吉崎友拓氏は，研究室一の体育会系ということで，研究室中に大き
な返事を響かせ，研究室を活気付けてくれました．吉崎氏の返事があってこその島村研究室
だったと思います．研究室を明るくしてくれてありがとうございました．また，研究室唯一
の学部 2 年生 川島成絵氏には，大変忙しい時期にもかかわらず，研究室の布団を洗っても
らい大変感謝しています．心地よく研究活動に打ち込むことができました．この先 2 年ない
し 4 年の学生生活が残っていると思いますが，悔いの残らないよう全力で楽しんで一生の財
産を手にいれてください．また，元研究室生としてたまに研究室にあらわれていた今田七海
氏は，よく自虐ネタで笑わしてもらいました．ありがとうございました．大学院でのご活躍
を願っております．
諸先生方，卒業生，同期，後輩と学生生活 6 年間でお世話になった方々一人一人に感謝の
意を表したいと思います．本当にありがとうございました．また，無理を言って大学院に進
学させてくださった両親には心より感謝申し上げます．最後に，私を支えてくださった皆様
に心から感謝の気持ちと御礼を申し上げたく，謝辞に代えさせて頂きます．
– 38 –
参考文献
[1] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h26/html/
nc141120.html 平 成 位 26 年 版 情 報 通 信 白 書 第 1 部 特 集 ICT が も た ら す 世
界規模でのパラダイムシフト 第 1 節 ICT の進化によるライフスタイル・ワークスタイ
ルの変化 （2016 年 1 月 29 日)．
[2] ゴンザロ・カマリロ，ミゲール・A・マーチン共著，澤田 拓也， 鹿島 拓也， 海老原
成， 永松 良一訳，”IMS 標準テキスト 改訂版” pp.453-484， 2010 年 3 月．
[3] https://www.ietf.org/rfc/rfc3921.txt P.Saint-Andre, Ed , Jabber Software
Foundation, ”RFC3921 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence”, 2004 年 8 月 (2016 年 2 月 1 日）
[4] http://www.au.kddi.com/mobile/service/call/sync-call/ KDDI 株式会社 au
サービス機能 通話サービス シンクコール （2016 年 1 月 30 日）
[5] 赤澤将太，島村和典，”NGN における Presence 通知プロトコルの研究”，平成 25 年度
学士学位論文．
[6] https://support.skype.com/ja/faq/FA3501 Microsoft， Skype（2016 年 2 月 11
日）
[7] 小笠原一聡，島村和典，”Rich Communication Services における Presence Service 実
現に関する研究”，平成 26 年度修士学位論文．
[8] 磯田佳徳，山田直治，石黒浩，”オフィス環境での無線 LAN を利用した屋内プレゼンス
システム”，電子情報通信学会論文誌，2010 年 10 月 vol.J93-D No.10 ，pp1903-1913
[9] https://www.sqlite.org/ SQLite (2016 年 2 月 2 日)
[10] MMD 研究所，”2015 年版：スマートフォン利用者実態調査”，https://mmdlabo.jp/
investigation/detail_1511.html， H28 年 1 月 27 日
– 39 –
付録 A
最適メディアアプリケーション選定
アルゴリズム
A.1
主要メディアの選定
//******** 主メディア選定 *********
//**** 主メディアの判断
public void getMain ( StringBuilder sb ){
int CopyUH [] = new int [ UsageHistory . length ];
int CopyMU [] = new int [ MyUsage . length ];
int CopyYU [] = new int [ YourUsage . length ];
for ( int a = 0; a < 3; a ++){
for ( int i = 0; i < CopyUH . length ; i ++){
CopyUH [ i ] = UsageHistory [ i ];
CopyMU [ i ] = MyUsage [ i ];
CopyYU [ i ] = YourUsage [ i ];
}
if ( get MainSe rvice ( a ) > 0){
if ( Max ( CopyUH , a ) >= 0) {
M a i n M e d i a A p p l i c a t i o n = Max ( CopyUH , a );
MainMediaType = a ;
/*
sb . append (" Main Type " + a
+ " ( feeds1 ): Main Service is "
+ ServiceName [ M a i n M e d i a A p p l i c a t i o n ] + "\ n ");
// */
– 41 –
付録 A 最適メディアアプリケーション選定アルゴリズム
break ;
}
float MySUM = 0;
float YourSUM = 0;
for ( int i = 0; i < MEDIA_NUM ; i ++){
MySUM += MyUsage [ i ];
YourSUM += YourUsage [ i ];
}
if ( MySUM > 0 && YourSUM > 0 ){
float BothMax [] = new float [ MEDIA_NUM ];
for ( int i = 0; i < MEDIA_NUM ; i ++){
BothMax [ i ] = CopyMU [ i ]/ MySUM * CopyYU [ i ]/ YourSUM ;
}
if ( Max_float ( BothMax , a ) >=0){
M a i n M e d i a A p p l i c a t i o n = Max_float ( BothMax , a );
MainMediaType = a ;
/*
sb . append (" Main Type " + a
+ "( feeds2 ): Main Service is "
+ ServiceName [ Max_float ( BothMax , a )] + "\ n ");
// */
break ;
}
}
}
/* 画面出力用
if ( M a i n M e d i a A p p l i c a t i o n == -1){
sb . append (" CANNOT USE FULL MEDIA CALL \ n ");
}
// */
} 主メディアとなるメディアアプリケーションの表現メディア取得
// 第一引数はサービス名，返り値利用可能
//0 ,1 ,2 表現メディアの有無 AP
public int get MainService ( int M ){
– 42 –
A.1 主要メディアの選定
int C ou n tS er v ic eNu m = 0;
for ( int i = 0; i < MEDIA_NUM ; i ++){
if ( S e rv ic e M e d ia T y p e [ i ][ M ] == 1){
Co untSer vi c eN um ++;
}
}
return Co unt Se r vi ce N um ;
} 最大値を持つ配列の添字を返す
//
public int Max ( int [] A , int a ) {
int max = 0;
int max_num = -1;
for ( int i = 0; i < A . length ; i ++) {
if ( Se rv i c e M e di a T y p e [ i ][ a ] == 1 && A [ i ] > max ) {
max = A [ i ];
max_num = i ;
}
}
return max_num ;
} 最大値を持つ配列の添字を返す
//
public
int Max_float ( float [] A , int a ) {
float max = 0;
int max_num = -1;
for ( int i = 0; i < A . length ; i ++) {
if ( S e r v ic eM e d i a Ty p e [ i ][ a ] == 1 && A [ i ] > max ) {
max = A [ i ];
max_num = i ;
}
}
return max_num ;
}
– 43 –
付録 A 最適メディアアプリケーション選定アルゴリズム
A.2
補助メディアアプリケーション群の選定
//*********** 補助メディアアプリケーション群選定補助メディアアプリケーション群の判断
//
public void getSubMedias ( StringBuilder sb ){
for ( int i = 0;
i < S e r v i ce M e d i a T yp e [ M a i n M e d i a A p p l i c a t i o n ]. length ;
i ++){
Ch eckMed iaLis t [ i ] = Ser vi ceMedia Type [ M a i n M e d i a A p p l i c a t i o n ][ i ];
C o p y C h e c kM e d i a L i s t [ i ] = CheckMediaList [ i ];
}
COUNT = C ou n tS er v ic eN u m ( CheckMediaList );
for ( int i = 0; i < MEDIA_NUM ; i ++){
Selected [ i ] = 0;
}
AddRoop ( CopyCheckMediaList , 0 , Selected , sb ); 画面出力用
//
/*
sb . append ("\ n " + " MEDIA :" + M a i n M e d i a A p p l i c a t i o n );
for ( int i = 0; i < Selected . length ; i ++){
if ( Selected [ i ] == 1) {
sb . append (" + "+ i );
} else if ( Selected [ i ] > 1){
sb . append (" + ?");
}
}
sb . append ("\ n ");
for ( int i = 0; i < Ch eckMediaLis t . length ; i ++){
if ( Check Media List [ i ] == 1){
sb . append ( i + " , ");
} else if ( Che ckMed iaList [ i ] == 0){
if ( i >= 10){
sb . append (" ");
– 44 –
A.2 補助メディアアプリケーション群の選定
}
sb . append (" - , ");
}
}
sb . append ("\ n \ n ");
// */
}
public void AddRoop ( int [] Root , int RootNum , int [] beforeSelected ,
StringBuilder sb ){
int CopyRT [] = new int [ Root . length ];
int CopyBS [] = new int [ beforeSelected . length ];
for ( int i = 0; i < Root . length ; i ++){
CopyRT [ i ] = Root [ i ];
Reef [ i ] = Root [ i ];
}
for ( int i = 0; i < be foreSelecte d . length ; i ++){
CopyBS [ i ] = befor eSelec ted [ i ];
afterSelected [ i ] = beforeSelected [ i ];
}
for ( int i = RootNum ; i < MEDIA_NUM ; i ++){
/*
sb . append (" MediaService " + i );
sb . append (" Reef : ");
for ( int j = 0; j < Reef . length ; j ++){
sb . append ( Reef [ j ] + " , ");
}
sb . append ("\ n ");
sb . append (" Root : ");
for ( int j = 0; j < Root . length ; j ++){
sb . append ( Root [ j ] + " , ");
}
sb . append ("\ n ");
// */
int addcount = 0;
– 45 –
付録 A 最適メディアアプリケーション選定アルゴリズム
for ( int j = 0; j < MEDIA_TYPE ; j ++){
int add = S er v i c e M e diaType [ i ][ j ];
if (( CopyRT [ j ] + add ) > 1){
break ;
}
addcount ++;
}
int Array [] = S e r v i c e M ediaT yp e [ i ];
int CSN = Co un t Se r vi ce Num ( Array );
if ( addcount == MEDIA_TYPE && CSN != 0){
for ( int k = 0; k < MEDIA_TYPE ; k ++){
Reef [ k ] = CopyRT [ k ] + Se rviceM ediaT y p e [ i ][ k ];
}
afterSelected [ i ]++;
if ( COUNT < C ou nt S erviceNum ( Reef )){
COUNT = Cou nt S erviceNum ( Reef );
for ( int m = 0; m < CheckMediaList . length ; m ++){
Che ckMedi aList [ m ] = Reef [ m ];
}
for ( int m = 0; m < Selected . length ; m ++){
Selected [ m ] = afterSelected [ m ];
}
}
/*
sb . append ("\ n Befor [" + i + "] Root ");
for ( int k = 0; k < MEDIA_TYPE ; k ++){
sb . append ( CopyRT [ k ] + " , ");
}
sb . append ("\ n ");
sb . append (" Befor [" + i + "] Reef ");
for ( int k = 0; k < MEDIA_TYPE ; k ++){
sb . append ( Reef [ k ] + " , ");
}
sb . append ("\ n ");
– 46 –
A.2 補助メディアアプリケーション群の選定
// */
AddRoop ( Reef , i +1 , afterSelected , sb );
for ( int k = 0; k < MEDIA_TYPE ; k ++){
Reef [ k ] = CopyRT [ k ];
}
for ( int k = 0; k < MEDIA_NUM ; k ++){
afterSelected [ k ] = CopyBS [ k ];
}
/*
sb . append (" After [" + i + "] Root ");
for ( int k = 0; k < MEDIA_TYPE ; k ++){
sb . append ( CopyRT [ k ] + " , ");
}
sb . append ("\ n ");
sb . append (" After [" + i + "] Reef ");
for ( int k = 0; k < MEDIA_TYPE ; k ++){
sb . append ( Reef [ k ] + " , ");
}
sb . append ("\ n ");
// */
}
}
}
public int Co un t Se rv ice N um ( int [] Array ){
int cnt = 0;
for ( int i =0; i < Array . length ; i ++){
if ( Array [ i ] == 1){
cnt ++;
}
}
return cnt ;
}
– 47 –