Rich Communication Service 化

平成 26 年度
学士学位論文
Rich Communication Service 化
のための LINE アプリケーション用
Presence Service 機能仕様の研究
A study of presence service functional specifications
for rich communication service of LINE application
1150318
仙波 紗和
指導教員
島村 和典
2015 年 2 月 6 日
高知工科大学 情報学群
要 旨
Rich Communication Service 化
のための LINE アプリケーション用
Presence Service 機能仕様の研究
仙波 紗和
近年，新たなコミュニケーションツールとして LINE が普及しており，利用率は年々増加
傾向にある．また，次世代ネットワークとして NGN（Next Generation Network）の導入
が進んでいる．NGN を実現するための基本サービスとして RCS（Rich Communication
Service）が期待されている．RCS は電話やメールにとって代わる基本コミュニケーション
サービス群のことで IM（Instant Message），SMS（Short Message Service），MMS（Mul-
timedia Message Service），Voice Call，Video Share，Image Share，Presence Service の
7 種類のサービスがある．その中でも，Presence Service は，通信相手の状態（Status）や属
性（Characteristics）を含む Presence 情報を通知するサービスである．利用者は,Presence
Service を利用することで，連絡の手段やタイミングなどを選択でき, コミュニケーションが
より円滑になる．しかし，LINE には Presence Service が提供されていない．
本稿では，円滑なコミュニケーションを行うために Presence Service のサービス機能と
システム構成を提案した．さらに，親密度に応じて，新しい Presence Service の通信相手
の階層化を行った．また，親密度の階層化に基づいて，Status の通知範囲を規定した．
検証では，1 日で最も通信が集中している 1 時間で，LINE システムと，新しい Presence
Service を追加したときとの 1 人あたりのトラフィック量を求めた．そして求めたトラ
フィック量を比較し，増加量を求めた．LINE システムのトラフィック量は 466KB，新しい
Presence Service を追加したときのトラフィック量は 766KB となり，トラフィック増加量
–i–
は約 1.6 倍となった．トラフィック増加量より，LINE システムとして実装可能な範囲と言
える．結果より，新しい Presesnce Service による LINE アプリケーションの利便性の向上
を確認した．
キーワード
LINE，NGN，RCS，Presence Service 仕様
– ii –
Abstract
A study of presence service functional specifications for rich
communication service of LINE application
Sawa SENBA
The LINE is widely used as a new communication tool in recent years, and it’s
utilization user raises every year. The NGN（Next Generation Network） has been introduced as a next-generation network. RCS (Rich Communication Service) is expected
as the basic current service to fulfil the NGN. RCS is the basic communication service
group which replaces the basic current couple of telephone and mail. It includes 7 kinds
of services which are IM (Instant Message) , SMS (Short Message Service), MMS (Multimedia Message Service) , Voice Call, Video Share, Image Share and Presence Service.
Especially, the presence service among them is a new service to notify the presence
information among communicators. The user can choose the means of the contact and
timing by knowing the presence status of the communication partner. But the presence service isn’t offered to the current LINE application which now provide RCS like
services.
The service function for the presence service and the system configuration were
proposed in this article. The communication partners using the new presence service
would be classified into the four categories according to the degree of the respective
friendship. The notice range of a communications presence status was prescribed based
on classification of the category.
The traffic amount per person when adding the new presence service feature to
– iii –
the current LINE system was evaluated. The increase of the traffic per hour of a
communication with presence status notice compared to the communication without
the notice at the most concentrated time in a day. The traffic amount of the LINE
system was be 466KB, the traffic amount when adding new presence service was be
766KB. The traffic increase was about 1.6 times. It’s possible to mount as the LINE
system from the light traffic increase. The improvement of communication convenience
of the LINE application could be improved by adding the new presence service proposed.
key words
LINE, NGN, RCS, Presence Service specification
– iv –
目次
第1章
研究背景と研究目的
1
1.1
電気通信サービスの動向 . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
NGN（Next Generation Network）の導入 . . . . . . . . . . . . . . . . .
2
1.3
RCS（Rich Communication Service）のサービス群 . . . . . . . . . . . .
3
1.3.1
Presence Service の概要 . . . . . . . . . . . . . . . . . . . . . . .
3
1.3.2
IM（Instant Message）の概要 . . . . . . . . . . . . . . . . . . . .
3
1.3.3
SMS（Short Message Service）の概要 . . . . . . . . . . . . . . .
4
1.3.4
MMS（Multimedia Messaging Service）の概要 . . . . . . . . . .
4
1.3.5
Voice Call の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3.6
Video Share の概要 . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3.7
Image Share の概要 . . . . . . . . . . . . . . . . . . . . . . . . . .
5
LINE の普及 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.4.1
RCS に対比した LINE サービス機能 . . . . . . . . . . . . . . . . .
5
1.4.2
LINE の Presence Service の現状 . . . . . . . . . . . . . . . . . .
6
研究目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Presence Service
8
2.1
緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2
SIP（Session Initiation Protocol） . . . . . . . . . . . . . . . . . . . . .
8
2.3
Presence Service を実現するアーキテクチャ . . . . . . . . . . . . . . . .
8
2.4
Presence 情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.5
Presence 情報の拡張 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
提案方式
12
1.4
1.5
第2章
第3章
–v–
目次
3.1
緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2
提案する Presence Service のサービス機能の概要 . . . . . . . . . . . . .
12
3.2.1
入力操作状況 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2.2
気分自動表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2.3
双方向通話可否状態 . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.2.4
居場所属性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.2.5
居場所詳細 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Presentity 及び Watcher の階層化 . . . . . . . . . . . . . . . . . . . . .
14
3.3.1
親密度による階層化 . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.3.2
階層ごとの通知範囲 . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.4
新しい Presence Sevice を追加した LINE のシステム構成 . . . . . . . . .
16
3.5
Presence 情報の入力 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.6
Presence 情報の出力 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.7
結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
提案方式の検証
20
4.1
検証方法と前提条件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.2
トラフィック量の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2.1
LINE システムのトラフィック量 . . . . . . . . . . . . . . . . . . .
22
4.2.2
新しい Presence Service を追加してときのトラフィック量
. . . . .
23
4.3
トラフィック量の比較結果 . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.4
考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
まとめ
26
3.3
第4章
第5章
謝辞
28
参考文献
30
– vi –
図目次
1.1
平成 25 年末のインターネット利用端末の種類 . . . . . . . . . . . . . . . .
2
1.2
平成 24 年 ソーシャルメディア利用率 . . . . . . . . . . . . . . . . . . . .
5
1.3
平成 25 年 ソーシャルメディア利用率 . . . . . . . . . . . . . . . . . . . .
5
2.1
SIP における Presence Service のアーキテクチャ . . . . . . . . . . . . . .
9
3.1
提案するシステム構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2
Presence 情報を表示する LINE 画面 . . . . . . . . . . . . . . . . . . . . .
19
– vii –
表目次
1.1
RCS に対応させた LINE のサービス機能 . . . . . . . . . . . . . . . . . . .
6
2.1
RPID 要素 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1
「個人」の階層化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2
「グループ」の階層化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.3
階層化による通知範囲 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.4
Presence 情報の変更の度に通知する Status . . . . . . . . . . . . . . . . .
18
3.5
新しい Presence Service の Status 表示箇所 . . . . . . . . . . . . . . . . .
19
4.1
モデルユーザ
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2
新しい Presence Service の１日あたりの Status 通知回数 . . . . . . . . . .
21
4.3
LINE システムの通信 1 回あたりのトラフィック量 . . . . . . . . . . . . . .
22
4.4
新しい Presence Service を追加したときの通信 1 回あたりのトラフィック量
22
4.5
トラフィック量の比較結果 . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
– viii –
第1章
研究背景と研究目的
1.1
電気通信サービスの動向
近年，インターネットの利用者が増え、平成 25 年末のインターネット利用者数は 10,044
万人，人口普及率は 82.8 ％となっている．また，端末別インターネット利用率をみると，自
宅のパソコンが 58.4 ％と最も多く，次いでスマートフォンが 42.4 ％，自宅以外のパソコン
が 27.9 ％となっている．平成 25 年末のインターネット利用端末の種類を図 1.1 に示す．ス
マートフォンの普及に伴い，パソコンだけでなくモバイル端末からのインターネットを利用
者が増加していると言える．また，モバイル端末は，電話やメールのみではなく，SNS な
どのソーシャルネットワークのアクセスにも利用が拡大している．今後，インターネット
へのアクセスはさらに拡大すると考えられる [1]．このことから，将来的には FMC（Fixed
Mobile Convergence）による移動通信と固定通信が融合した通信サービスの形態になると
考えられる．FMC を実現する方法として，電話網と IP 網を統合した次世代ネットワーク，
NGN（Next Generation Network）が注目されている．
–1–
1.2 NGN（Next Generation Network）の導入
図 1.1 平成 25 年末のインターネット利用端末の種類
1.2
NGN（Next Generation Network）の導入
NGN とは，インターネットで使用されている中核的な技術である IP（InternetProtocol）
を使用する次世代の安全性や信頼性の高いネットワークの総称である．国際標準機関である
ITU-T によって標準化され，マルチメディアサービスの提供を目的に広帯域で QoS 制御が
可能なパケットベースのネットワークである．NGN はセキュリティが強く，信頼性が大き
いサービス品質（QoS）機能をもつ電話網と，IP プロトコルを使用して汎用性の高い機器を
導入でき，柔軟性が大きいインターネットの双方の長所を採用して構築されている．NGN
は，電話網で実現されていた基本的なサービスを IP 上で実現する [2]．この電話サービス
を実現するための技術として，IP の環境において通信回線の接続や切断などの制御を行う
ためのプロトコルである SIP（Session Initiation Protocol）を採用している．また，音声
だけでなく，映像やテキストなども含めたマルチメディア通信を行うシステムとして IMS
（IP Multimedia Subsystem）を採用している．このため，音声系のサービスについては既
存電話網と遜色のない同じ品質のサービスが実現されるとともに，より多彩なメディアを利
–2–
1.3 RCS（Rich Communication Service）のサービス群
用した通信が可能となる．また，IMS を用いた RCS（Rich Communication Service）が基
本サービスとして提唱されている [5]．
1.3
RCS（Rich Communication Service）のサービス群
RCS は GSMA（Global System for Mobile Communications Association）が標準化を
進めている電話やメールに代わる基本コミュニケーションサービス群であり，利用者に利便
性・快適さを提供している．RCS の利用者は，利用者が契約している携帯電話事業者の加入
者に限らず，国内や海外の他の携帯電話事業者の加入者，さらにはパソコンでインターネッ
トを利用する人，モバイル端末でインターネットを利用する人が想定される [4]．RCS のサー
ビス群には Presence Service，IM（Instant Message），SMS（Short Message Service），
MMS（Multimedia Messaging Service），Voice Call，Video Share，Image Share の 7 つ
のサービスが定義されている．以下，それぞれのサービス概要について説明する．
1.3.1
Presence Service の概要
Presence Service は通信しようとする相手の状態（Status）や相手の属性（Characteristics）を含む Presence 情報を通知するサービスである．通信相手の Presence 情報によって，
利用者は連絡の手段やタイミングを選択することが可能となり，コミュニケーションの円滑
化を図ることができる．Presence Service を実現するために，IP 電話の呼制御で用いられ
る SIP が採用されている．
1.3.2
IM（Instant Message）の概要
IM はメッセージを通信相手に送信するサービスである．IM がリアルタイムという特徴
を持っており，利用者は簡単なメッセージをすぐに通信相手に送ることができる．IM の中
身は通常，テキストメッセージであるが，HTML ページ，画像，音楽ファイル，ビデオク
リップ，その他の一般ファイルを乗せることも可能である．
–3–
1.3 RCS（Rich Communication Service）のサービス群
1.3.3
SMS（Short Message Service）の概要
SMS は携帯電話同士で短いメッセージを送受信できるサービスである．URI の指定に
相手の電話番号を指定するため，加入者間で即時にメッセージが交換できる．世界的には，
GSMA 規格の一部として 140Bytes（アルファベットで 160 文字）までのメッセージ交換が
できる標準規格が普及した．日本では，第 2 世代携帯電話で複数の方式が並立したこともあ
り，キャリアごとに独自の仕様がされたため，他のキャリアの加入者や国外とはやりとりは
できなかった．しかし，2011 年 7 月頃から国内キャリア同士で相互接続されるようになっ
た．NGN では，キャリアを気にすることなく接続することが可能なため，異なるキャリア
間でメッセージの送受信が可能である．
1.3.4
MMS（Multimedia Messaging Service）の概要
MMS は携帯電話同士で文字や音声，画像などを短いメッセージとして送受信できるサー
ビスである．SMS と相互運用性を保ちつつ，機能拡張が行われている．MMS は 3GPP
（3rd Generation Partnership Project）によって標準化されている．NGN でも同様に扱う
ことが可能で，文字や音声，画像の送受信が可能である．
1.3.5
Voice Call の概要
Voice Call は IP 網を利用した音声通話サービスである．NGN でも IP 網を用いて音声通
話を行うことが可能である．
1.3.6
Video Share の概要
Video Share は通信相手と動画を共有するサービスである．NGN では共有中に動画の再
生，一時停止，再開動作が可能である．
–4–
1.4 LINE の普及
1.3.7
Image Share の概要
Image Share は通信相手と画像を共有するサービスである．NGN では画像を編集するこ
とができ，通信相手と共有することが可能である．また，編集した画像をお互いに保存する
ことも可能である．
1.4
LINE の普及
近年，主に携帯端末で利用されるコミュニケーションツールとして LINE が普及してお
り，利用率は年々増加傾向にある [6]．総務省の発表による平成 24 年と平成 25 年のソーシャ
ルメディアの利用率をそれぞれ図 1.2 と図 1.3 に示す．LINE の利用率は他のソーシャルメ
ディアよりも高く，1 年で倍増しおり，今後も利用率の増加が見込まれる．以下では，RCS
における LINE の現状及び LINE の Presence Service の現状について記述する．
図 1.2 平成 24 年 ソーシャルメディア利用率
1.4.1
図 1.3 平成 25 年 ソーシャルメディア利用率
RCS に対比した LINE サービス機能
RCS に対応させた LINE のサービス機能を表 1.1 に示す．RCS のサービス群は，既
に LINE のサービス機能として一部実現されている．しかし，RCS のサービス群の中の
Presence Service は実現されていない．また，LINE サービスの中に「既読」機能や「タイ
ムライン」機能があるが，これらは動的な Presence Service ではない．詳細を 1.4.2 節で述
–5–
1.4 LINE の普及
べる．
表 1.1 RCS に対応させた LINE のサービス機能
1.4.2
RCS サービス群
LINE の機能
IM
トーク機能のメッセージの送受
SMS
×
MMS
スタンプ，Voice メッセージ
Voice Call
LINE 電話
Video Share
動画を共有
Image Share
画像を共有
Presence Service
×
LINE の Presence Service の現状
Presence Service は動的な通信相手の状態（Status）を Presence 情報として通知する
サービスである．LINE には「既読」機能が実装されている．これは，通信相手が LINE の
メッセージやスタンプを確認した際に通知されるものであるが，これは Status 情報ではな
い．一度「既読」が通知されると消えることもない．詳細は第 2 章にて述べる．また，LINE
には，
「タイムライン」機能が実装されている．
「タイムライン」機能の使い方によっては，通
信者の Status を動的に通知することも可能である．これは，自身や通信相手が投稿したメッ
セージやスタンプなどが，時間の流れに沿って表示されるものである．しかし，この機能は
RCS の Presence Service とは機能設計目的が異なっている．従って，LINE には Status を
含む Presense 情報を通知するサービスは提供されていない．そして，LINE には「個人」
と「グループ」に分け，通信相手の人数を変更して通信することが可能である．
「個人」は，
1 対 1 で通信を行い，
「グループ」は，1 対多で通信を行う．この機能によって，通信者は通
知相手を選択することができる．
–6–
1.5 研究目的
1.5
研究目的
本論では，より利便性の高い LINE アプリケーションを提供することを目的とした新し
い Presence Service と，実現するためのシステム構成を提案する．また，新しい Presence
Service では，通信相手との親密度による階層化を行い，Status の通知範囲を制限する．第
2 章では，Presence Service の通信相手に通知する Presence 情報について説明を行う．第 3
章では，新しい Presnece Service について述べる．第 4 章では，新しい Presence Service
の利便性を検証するために行った LINE システムと新しい Presence Service を追加したシ
ステムの 1 人あたりの通信にかかるトラフィック量との比較を述べる．第 5 章では，本研究
のまとめを述べる．
–7–
第2章
Presence Service
2.1
緒言
本章では，Presence Service を実現するために必要な SIP と送受信されるの Presence 情
報及び Presence 情報の拡張について述べる．
2.2
SIP（Session Initiation Protocol）
IMS では，セッション制御プロトコルとして SIP を採用している．SIP は，IP ネットワー
ク上で IETF（INternet Engineering Task Force）で策定された IP ネットワーク上でマル
チメディアセッションを確立し管理するためのプロトコルである．RFC3261 で標準化されて
いる [3]．また，SMTP（Simple Mail Transfer Protocol）や HTTP（Hypertext Transfer
Protocol）をベースに作られたため，CGI（Common Geteway Interface）や Java サーブ
レットなど HTTP のために開発されたすべてのサービス・フレームワークが利用可能であ
る [4]．SIP によって実現可能なサービスには，ビデオ会議や電話，IM，Presence Service
がある．
2.3
Presence Service を実現するアーキテクチャ
Presence Service は，通信相手の Presence 情報を通知するサービスである．自身の
Presence 情報を通知する人を Presentity，Presentity の Presence 情報を受けとる人を
Watcher という．Presence Service を利用することで，通信相手は通信するタイミングや連
–8–
2.4 Presence 情報
絡手段を選択することができ，利便性の高い通信が利用可能となる．SIP における Presence
Service のアーキテクチャを図 2.1 に示す．Presentity からの Presence 情報の送信には SIP
メソッドの PIBLISH が用いられ，Watcher からの Presence 情報の取得には SUBSCRIBE
を用いる．Watcher からの要求に対して，Presence Server は SIP メソッドの NOTIFY を
用いて Presence 情報を通知する．
図 2.1 SIP における Presence Service のアーキテクチャ
2.4
Presence 情報
Presence 情報は Status（状態）と Characteristics（属性）がある．Status は動的な情報
が当てはまり，Characteristics は静的な情報となる．また 3 つの要素に分かれており，
「パー
ソン要素」，
「サービス要素」，
「ディバイス要素」がある．
「パーソン要素」はプレゼンスの対
象として，通信の可否や意思に影響を与える状態によって特徴付けられる要素が該当する．
「サービス要素」は一定の様式や内容を生むユーザ間で相互作用するためのシステムが該当
する．
「ディバイス要素」は通信を開始・受信するためにユーザが相互作用する物理的要素が
該当する [8]．
–9–
2.5 Presence 情報の拡張
2.5
Presence 情報の拡張
Presence 情 報 は PIDF（Presence Information Data Format）に よ り 拡 張 で き ，
RFC3863[9] に規定されている．PIDF はプレゼンスシステムの 2 つのエンティティ間で
Presence 情報の意味内容を伝達するために設計された [4]．また，PIDF を拡張する RPID
（Rich Presence Information Data Format）が存在する．RFC4480[10] に規定されている．
RPID は PIDF を拡張して，Presentity が Watcher に対して詳細で高度な Presence 情報
を Watcher に対して表現して見せることが可能とするものである．RPID は，Status を表
す要素が 13 種類ある [4]．また，既存研究 [4] より，新たに RCS のサービス利用制御を可能
とする Available Servie が拡張され，14 種類となっている．RPID の要素を表 2.1 に示す．
– 10 –
2.5 Presence 情報の拡張
表 2.1 RPID 要素
要素名
説明
Activities status
Presentity の現在の活動状況．1 つ以上の状態が示せる．拡張可能．
Class status
共通点があるパーソン，ディバイス，サービス要素を同じクラスに分
類し，グループ化．
Device status
特定のサービスを提供するディバイスを特定する ID．
Mood status
その人の気分
Place is status
その場所の性質．
「明るい」，
「騒がしい」など．
Place type status
Presentity の現在いる場所の種類．拡張可能．
Privacy status
第三者から勝手に見られたり聞かれたりすることなく，安全に受信
できるメディアの種類．
Relationship status
Presentity 自身の代わりの連絡先となる人物との関係．
Service class status
そのサービスの種類．電子サービス，郵便，配達サービス，直接訪
問．
Sphere status
Presentity の現時点での状況や役割．
Status icon status
人やサービスを視覚的に表すアイコンへのリンク．
Time offset status
ユーザの現地時間と UTC（協定世界時）との差分時間．
User input status
ユーザからの入力状況やサービスやディバイスの利用状況などを表
現することが可能．
Available status
RCS のサービス利用制御
– 11 –
第3章
提案方式
3.1
緒言
本章では，新しい LINE 向け Presence Service の提案を行い，その Presence Service の
実現方法を述べる．
3.2
提案する Presence Service のサービス機能の概要
新しい Presence Service のサービス機能は，
「入力操作状況」，
「気分自動表示」，
「双方向通
話可否状態」，
「居場所属性」，
「居場所詳細」の 5 つの Status である．それぞれの Status の
詳細について述べる．
3.2.1
入力操作状況
入力操作状況は，Presentity が LINE のトーク機能でメッセージを入力している最中であ
れば，Watcher に「入力中」と通知，そうでなければ通知しない．
3.2.2
気分自動表示
気分自動表示は，Presentity がトーク機能で最後に使用したスタンプを現在の気分にあっ
たスタンプとして Watcher に通知する．
スタンプが未使用であったり，12 時間以上未使用である場合は，最後に使用したスタンプ
が Presentity の気分に対応したスタンプである信憑性が低くなるため，Presentity のトーク
– 12 –
3.2 提案する Presence Service のサービス機能の概要
機能で入力してるメッセージの中から最新の気分を表す言葉を拾い，対応するスタンプに変
換して通知する．このとき気分を表す言葉は，RFC4480 に規定されている「Mood-status」
を採用する．対応するスタンプは LINE にデフォルトとして用意されているスタンプを使用
し，予め気分を表す言葉と対応付けておく．また，LINE を 1 日以上使用していない場合は，
気分表示を行わないものとし，表示されているスタンプを削除する．
3.2.3
双方向通話可否状態
双方向通話可否状態は，Presentity の現在双方向通話の可否を「通話中」，
「待機中」，
「双
方向通話不可」の三段階で Watcher に通知する．
「通話中」は通話をしている状態，
「待機中」
は電話に出ることが可能な状態，
「双方向通話不可」はオンラインかつリアルタイムサービス
には応答できない状態を示す．
3.2.4
居場所属性
居場所属性は，Presentity の現在地を GPS を用いて取得し，対応する属性に変換して，
Watcher に通知する．属性は，RFC4589 に規定されている「Place-type-status」を採用し，
必要に応じて拡張する．
3.2.5
居場所詳細
居場所詳細は，Presentity の現在地点を予め場所情報を設定している Wi-Fi を用いて取
得し，対応する属性詳細に変化して，Watcher に通知する．属性詳細では Wi-Fi を用いる
ことで GPS では取得できない屋内の詳細まで通知することが可能となる．よって，
「居場所
属性」よりも通信相手の居場所の詳細を通知することとなる．
– 13 –
3.3 Presentity 及び Watcher の階層化
3.3
Presentity 及び Watcher の階層化
自身の Presence 情報を通知する人を Presentity，Presentity の Presence 情報を受けと
る人を Watcher とする．Presentity は Watcher を，Watcher は Presentity をそれぞれの
親密度に基づいて階層化を行う．LINE には 1 対 1 で通信を行う「個人」と，1 対多で通信
を行う「グループ」とあり，それぞれの階層化を行う．
3.3.1
親密度による階層化
「個人」では，Intimate Distance，Relative Distance，Familiar Distance，Acquaintance
Distance の 4 種類に分ける．Intimate Distance は恋人，Relative Distance は夫婦や家族，
Familiar Distance は友人，Acquaintance Distance は社会的知り合いに該当させる．ま
た，Acquaintance Distance，Familiar Distance，Relative Distance，Intimate Distance
の順位に親密度は高くなる．
「グループ」では，Transmission Distance，No Transmission
Distance に分ける．Transmission Distance はグループ構成した通信相手全員に伝える，
No Transmission Distance はグループ構成した通信相手全員に伝えないとする．
また Presentity の設定と Watcher の設定が同じであるとき，双方の設定を反映させる．
しかし，双方の設定が異なるときは，親密度の認識の違いにより発生するトラブルを防ぐた
めに，親密度が低い設定を採用する．
「個人」と「グループ」を親密度による階層化を行った．
「個人」の階層化を表 3.1，
「グループ」の階層化を表 3.2 に示す．
表 3.1
「個人」の階層化
Presentity の設定
Wacther
の設定
Intimate
Relative
Familiar
Acquaintance
Intimate
Intimate
Relative
Familiar
Acquaintance
Relative
Relative
Relative
Familiar
Acquaintance
Familiar
Familiar
Familiar
Familiar
Acquaintance
Acquaintance
Acquaintance
Acquaintance
Acquaintance
Acquaintance
– 14 –
3.3 Presentity 及び Watcher の階層化
表 3.2
Wacther
の設定
3.3.2
「グループ」の階層化
Presentity の設定
Transmission
No Transmission
Transmission
Transmission
No Transmission
No Transmission
No Transmission
No Transmission
階層ごとの通知範囲
親密度によって階層化を行った「個人」と「グループ」に表示させる新しい Presence
Service の Status 通知範囲を設定した．階層化による通知範囲を表 3.3 に示す．
「個人」の
Intimate Distance は ID，Relative Distance は RD，Familiar Distance は FD，Acquaintance Distance は AD，グループ」の Transmission Distance は TD，No Transmission
Distance は NTD を示す．
「入力操作状況」，
「双方向通話可否状態」の 2 つの Status は階層
化に関係なく，
「個人」「グループ」共に通知する．
表 3.3
階層化による通知範囲
個人
グループ
入力操作状況
ID, RD, FD, AD
TD
気分自動表示
ID, RD, FD
TD or NTD
双方向通話可否状態
ID, RD, FD, AD
TD
居場所属性
ID, （RD, FD）
TD or NTO
居場所詳細
ID, （RD, FD）
TD or NTD
– 15 –
3.4 新しい Presence Sevice を追加した LINE のシステム構成
3.4
新しい Presence Sevice を追加した LINE のシステム
構成
新しい Presence Service を追加した LINE のシステム構成を図 3.1 に示す．LINE システ
ムに新たに Presence Server を設け，Presentity の Status 管理を行う．Intimacy 管理 DB
（Data Base）は，
「個人」の Presentity 及び Watcher を親密度によって分けた 4 段階と「グ
ループ」の 2 段階の階層による，Presence 情報の通知範囲を管理する．Presence 管理 DB
は，Presentity の Presence 情報を管理する．Mood & Place 参照元 DB は，スタンプと
気分を表す言葉の変換情報と現在地情報と対応する属性，属性詳細の変換情報を管理する．
RCS アプリケーションサーバ群は，Presence Service と RCS の Presence Service 以外の
サービスと連携をさせる．
また，新しい Presence Service の通知方法について，
「入力操作状況」は，Presentity が
「入力中」となった時点で LINE システムに情報が送られ，Watcher から通知予約がされた
際に通知される．そして，Presentity がメッセージの入力を終え，
「入力中」でなくなった時
点で LINE システムに情報を送り，Watcher から通知予約された際に通知される．
「気分自
動表示」は，Presentity の気分表示のスタンプが更新されるとその都度 LINE システムに
情報送られ，Presence Server が管理する．更新される度に Watcher に通知するのではな
く，Watcher から通知予約がなされた際に，LINE システムに問い合わせ，Presence 情報
が Watcher に通知される．スタンプが未使用や 12 時間以上未使用である場合は，LINE シ
ステムから Presentity の端末に問い合わせがあり，トーク機能内のメッセージから気分を
表す言葉を読み取り，Presence Server に送り，対応するスタンプに変換される．このとき，
Watcher には通知せず，Watcher から通知予約があった際に通知する．また，LINE を 1 日
以上使用していない場合は，LINE システムから Presence Server に通知され，Presentity
の Presence 情報は削除される．Watcher にはの通知予約があった際に通知される．
「双方
向通話可否状態」は，Presentity の Status に変更がある度に LINE システムに通知され，
Watcher に通知される．
「居場所属性」は，Presentity の居場所は変更があるたびに LINE シ
– 16 –
3.5 Presence 情報の入力
ステムに送られ，Watcher から通知予約があった際に通知される．
「居場所詳細」は，居場所
属性と同様に，Presentity の居場所は変更があるたびに LINE システムに送られ，Watcher
から通知予約があった際に通知される．
図 3.1
3.5
提案するシステム構成
Presence 情報の入力
「入力操作状況」の Presence 情報の入力は，トーク機能内でメッセージの入力が行われ
ることで「入力中」と自動で設定される．
「気分自動表示」は，トーク機能の最後に使用し
たスタンプを自動で取得する．
「双方向通話可否状態」の「通話中」は LINE 電話やビデオ
電話，無料電話をしている場合は自動で設定され，
「待機中」及び「双方向通話不可」の場
合は Presentity 自身が設定を行う．
「居場所属性」及び「居場所詳細」は，GPS や Wi-Fi を
使用して自動で設定される．Presentity 自身が行う設定はすべて LINE の「設定」機能から
行う．
– 17 –
3.6 Presence 情報の出力
3.6
Presence 情報の出力
Presence 情報の出力は Presentity が Presence 情報の変更の度に通知する Status と，
Watcher が通知予約をした際に通知する Status がある．Presence 情報の変更の度に通知す
る Status を表 3.4 に示す．これは LINE の「タイムライン」に表示する．また，グループ
は更新頻度が多くなるためすべて表示しない．また，Watcher が通知予約をした際に通知
する Status は「双方向通話可否状態」以外の Status である．新しい Presence Service の
Status 表示箇所を表 3.5 に示す．
「個人」の Status の表示は「入力操作状況」，
「双方向通話
可否状態」，
「居場所属性」，
「居場所詳細」は「トーク内」や「友だち内」にするのではな
く，一目でわかるようにそれぞれの「トークの一覧」，
「友だち一覧」にする．
「グループ」の
Status の表示は「グループ」の人数によっては表示させる Status が多くなり，表示させる
場所が限られるため，すべて「トーク内」や「友だち内」にする．実際に Presence 情報を
表示する LINE 画面を図 3.2 に示す．
「トークの一覧」は今までに通信をしている友だち全員
の一覧を示し，
「トークの一覧」から通信をしたい友だちを選択すると「トーク内」に遷移
し，メッセージのやりとりを行う画面になる．
「友だち一覧」が，LINE で友だちとなってい
る全員の一覧を示し，
「友だち一覧」から通信したい友だちを選択すると「友だち内」に遷移
しする．
「友だち内」では，選択した友だちとトークをするか，電話をするかなど選択を行な
える画面になる．
表 3.4 Presence 情報の変更の度に通知する Status
個人
グループ
入力操作状況
×
×
気分自動表示
×
×
双方向通話可否状態
○
×
居場所属性
×
×
居場所詳細
×
×
– 18 –
3.7 結言
表 3.5
新しい Presence Service の Status 表示箇所
個人
グループ
入力操作状況
トーク内
トーク内
気分自動表示
トークの一覧，友だち一覧
トーク内
双方向通話可否状態
トークの一覧，友だち一覧
トーク内
居場所属性
友だち一覧
友だち内
居場所詳細
友だち一覧
友だち内
図 3.2
3.7
Presence 情報を表示する LINE 画面
結言
新しい Presence Service のサービス機能の説明及びシステム構成，Presentity 及び
Watcher の階層化，Presence 情報の入力・出力について述べた．新しい Presence Service
として「入力操作状況」，
「気分自動表示」，
「双方向通話可否状態」，
「居場所属性」，
「居場所
詳細」の新しい 5 つの Status を提案した．また，通信相手との親密度によって「個人」を
Intimate Distance，Relative Distance，Familiar Distance，Acquaintance Distance の 4
段階に，
「グループ」を Transmission Distance，No Transmission Distance の 2 段階に階
層化を行い，新しい Presence Service の通知範囲を規定した．
– 19 –
第4章
提案方式の検証
新しい Presence Service の利便性を示すために，LINE システムと新しい Presence
Service を追加したときのトラフィック量の比較を行う．
4.1
検証方法と前提条件
LINE システムの 1 日で最も通信が集中している 1 時間あたりの 1 人のトラフィック量
と新しい Presence Service を追加したときのトラフィック量を比較する．前提条件として，
LINE を使用するモデルユーザを設定する．これは，よく LINE を使用するヘビーユーザ
と，あまり LINE を使用しないライトユーザーの平均ユーザーとする．モデルユーザを表
4.1 に示す．モデルユーザの LINE の 1 日あたりの 1 人あたりのメッセージの回数，1 回に
送信するメッセージの長さ，1 人あたりのスタンプの回数，通信する友達の数，友だち数，
既読数，タイムライン（気分）の投稿回数を設定する．また，新しい Presence Service の１
日に通知する Status の回数を表 4.2 に示す．
「入力操作状況」は Presentity が通知するメッ
セージに対して，
「入力中」と「入力中」でなくなったときの 2 回通知する必要があるため，
1 人あたりのメッセージ回数 15 回を 2 倍して 30 回になる．
「気分自動表示」は，スタンプの
回数で 5 回である．
「双方向通話可否状態」は LINE 株式会社による職業別のユーザの割合
より一番多いユーザは会社員で全体の 38.3 ％を占めている [7] という結果より，朝・昼・晩
に 2 回ずつ変更されると設定する．よって，計 6 回とする．
「居場所属性」，
「居場所詳細」に
ついても会社員の 1 日を仮定し，設定する．
– 20 –
4.2 トラフィック量の比較
表 4.1
モデルユーザ
1 人あたりのメッセージの回数
15 回 1 回に送信するメッセージの長さ 15 文字
1 人あたりのスタンプの回数 5回
通信する友達
7人
友だち数
100 人
既読数
メッセージ + スタンプ = 20 回
タイムライン（気分）の投稿回数
0.01 回
表 4.2 新しい Presence Service の１日あたりの Status 通知回数
4.2
入力操作状況
30 回 気分自動表示
5 回 双方向通話可否状態
6 回 居場所属性
5 回 居場所詳細
10 回 トラフィック量の比較
LINE システムの通信 1 回あたりのトラフィック量を表 4.3，新しい Presence Service を
追加したときの通信 1 回あたりのトラフィック量を表 4.4 に示す．LINE システムで対象と
するのは「メッセージ」，
「スタンプ」，
「既読」の 3 つとする．
「メッセージ」の 1 回の通信
のパケットは wireshake で測定した結果に基づいている．また，スタンプ 1 回のデータ量
は 30KB とする．新しい Presence Service の Presentity から LINE システム間の通信では
「気分自動表示」にかかるトラフィックはない．それは，LINE システムにすでに送られてい
たスタンプを使用して Watcher に通知するからである．また，Presentity から LINE シス
テムの通信と LINE システムから Watcher の通信で「居場所属性」と「居場所詳細」のト
ラフィック量の違いは，Presentity から LINE システムの通信では，GPS の座標や Wi-Fi
– 21 –
4.2 トラフィック量の比較
のアクセスポイント識別子の情報を通知しているのに対して，LINE システムから Watcher
の通信では，GPS や Wi-Fi の情報を属性や属性詳細に変換してテキストで通知しているか
らである．
表 4.3 LINE システムの通信 1 回あたりのトラフィック量
表 4.4
834byte
スタンプ
30,740byte
既読
20.13byte
新しい Presence Service を追加したときの通信 1 回あたりのトラフィック量
Presentity から LINE シス
LINE
テムの通信
Watcher の通信
入力操作状況
20.25byte
20.25byte 気分自動表示
×
30,740byte 20.375byte
20.375byte 居場所属性
78byte
200byte 居場所詳細
148byte
200byte 双方向通話可否状態
4.2.1
メッセージ
シ ス テ ム か ら
LINE システムのトラフィック量
LINE システムの 1 日に最も通信が集中している 1 時間あたりのトラフィック量を検証す
る．モデルユーザは会社員としており，
「メッセージ」，
「スタンプ」，
「既読」の最も通信が集
中している時間は朝・昼・晩の約 5 時間に集中しているとする．これは総務省の情報通信政
策研究所が発表してる調査に基づいている [6]．このとき，LINE システムの 1 人 1 日あた
りのトラフィック量は 11,66270byte と求めることができ，1 時間当たり 233KB となる．こ
れは，Presentity から LINE システムの通信で，LINE システムから Watcher の通信でも
同じだけのトラフィック量がかかるため，466KB となる．
– 22 –
4.3 トラフィック量の比較結果
4.2.2
新しい Presence Service を追加してときのトラフィック量
新しい Presence Service を追加したときの 1 日に最も通信が集中している 1 時間あたり
のトラフィック量を検証する．Presentity から LINE システムを経由し，Presence Server
に通知するまでのトラフィック量は Presentity から LINE システムの通信を 2 倍することで
求められる．Presentity から LINE システムのトラフィック量は，LINE システムと同様に
1 日あたりの総トラフィック量から総時間で割り，1 時間の 1 人あたりのトラフィック量を求
める．通知する対象の相手は 1 日に通信する友だち 7 人であり，Presentity から LINE シス
テムのトラフィック量は 457byte と求められ，2 倍して Presentity から LINE システムを経
由し，Presence Server に通知するまでのトラフィック量は 914byte となる．次に，Presence
Server から LINE システムの通信と LINE システムから Watcher の通信のトラフィック量
を求める．新しい Presence Service の Status の「双方向通話可否状態」は友だち 100 人に
通知し，
「入力操作状況」，
「気分自動表示」と「居場所属性」，
「居場所詳細」は 1 日にやりと
りする友達の 7 人に通知する．Presence Server から LINE システムの通信は 149,950byte
と求められ，2 倍して Presence Server から LINE システムを経由して Watcher に通知す
るトラフィック量は 299,900byte となる．よって新しい Presence Service の 1 日に最も通信
が集中している 1 時間あたりのトラフィック量は Presentity から LINE システムを経由し，
Presence Server に通知するまでのトラフィック量 914byte と Presence Server から LINE
システムを経由して Watcher に通知するトラフィック量 299,900byte を合わせて 300KB と
なり，LINE システムのトラフィック量 466KB とあわせて 766KB となる．
4.3
トラフィック量の比較結果
LINE システムと新しい Presence Service を追加したときの 1 日最も通信が集中している
1 時間あたりのトラフィック量はそれぞれ 466KB，766KB となった．よって LINE システ
ムと新しい Presence Service を追加したときのトラフィックの増加量は約 1.6 倍と求められ
る．また，Presence Server から LINE システムの通信と LINE システムから Watcher の通
– 23 –
4.4 考察
信を友だち 100 人全ての Watcher に行った際のトラフィック量も求め，比較を行った．1 日
最も通信が集中している 1 時間あたりのトラフィック量は LINE システムが 466KB，新しい
Presence Service を追加し，友だち 100 人全ての Watcher に通知したときが 4,715KB であ
るため，LINE システムと新しい Presence Service を追加したときのトラフィックの増加量
は約 10.1 倍となった．トラフィック量の比較結果を表 4.5 に示す．親密度による Presentity
及び Watcher の階層化に基づいた，通知範囲を設定して一部の Presnece 情報を通知する新
しい Presence Service の方がトラフィク量は少なく，トラフィックの増加量も少ない．よっ
て，通信範囲を設定して一部を Presence 情報を通知する新しい Presence Service とする．
表 4.5
トラフィック量の比較結果
LINE システム
Presence 情報を
新しい Presence Service を
ト ラ フィック
追加した LINE システム
の増加量 466KB
4,715KB
約 10.1 倍
466KB
766KB
約 1.6 倍
すべて通知
一部の Presence
情報を通知
4.4
考察
新しい Presence Service の利便性を示すために，LINE システムと新しい Presence
Service を追加したときのトラフィック量の比較を行った．すべての Status を Presentity か
ら変更がある度に Watcher に通知した場合，LINE システムと新しい Presence Service を
追加した LINE システムとではトラフックの増加量が約 10.1 倍となった．これは，日本の
LINE ユーザ数約 5,000 万人が約 5 億人になることに相当する．現在，世界の LINE ユー
ザー数が約 5 億人であるため，LINE システムとして実装可能な範囲内とは言い難い．その
ため，親密度による Presentity 及び Watcher の階層化に基づいた，通知範囲を利用して，
– 24 –
4.4 考察
Presentity の Status に変更がある度に Watcher に通知される「双方向通話可否状態」は友
だち 100 人の Watcher に通知し，Watcher から通知予約がされたときに通知される「入力
操作状況」，
「気分自動表示」，
「居場所属性」，
「居場所詳細」は Presentity が 1 日にやりとり
を行う 7 人の Watcher に通知すると決めた．この場合，LINE システムと新しい Presence
Service を追加した LINE システムとではトラフックの増加量が約 1.6 倍となった．これは，
日本の LINE ユーザ数約 5,000 万人が約 8,000 万人になることに相当し，１人あたりのト
ラフィック増加量は高々1.5 倍強ですむ．１回の通信のトラフィック量が大きい「気分自動
表示」のスタンプを Presentity から Presence 情報が変更される度に通知するのではなく，
Watcher からの通知予約があった際に通知することにしているため，トラフィック量を大幅
に削減できた．また，Presentity 及び Watcher の階層化による通知範囲の規定して求めた
トラフィック量は最大値であるため，Presentity 及び Watcher の階層化に変化があったとし
ても最大値を越えることはないため，LINE システムとして実装可能な範囲と評価できる．
– 25 –
第5章
まとめ
本研究では，近年急速に発展しているコミュニケーションツールである LINE に新しい
Presence Service の機能と，LINE システムに新しい Presence Server を追加したシステム
構成を提案した．また，親密度による Presentity 及び Watcher の階層化を行い，Status の
通知範囲を規定した．提案方式は，新しい Presence Service の Status は「入力操作状況」，
「気分自動表示」，
「双方向通話可否状態」，
「居場所属性」，
「居場所詳細」の 5 つである．
「入力
操作状況」は Presentity のメッセージの入力操作の状況を Watcher に通知する．
「気分自動
表示」は，Presentity の現在の気分を LINE のスタンプを用いて通知する．
「双方向通話可
否状態」は，Presentity の現在の双方通話の可否を「通話中」，
「待機中」，
「双方向通話不可」
の 3 段階で通知する．
「居場所属性」は，Presentity の現在地を GPS で取得し，対応する属
性に変換して通知する．
「居場所詳細」は，Presentity の現在地点を Wi-Fi で取得し，対応
する属性詳細に変換して通知する．
また，親密度による Presentity 及び Watcher の階層化を行い，階層ごとに通知する範
囲を規定した．LINE の 1 対 1 で通信を行う「個人」では，親密度が高い順位に Intimate
Distance，Relative Distance，Familiar Distance，Acquaintance Distance の 4 階層に分
けた．Intimate Distance は恋人，Relative Distance は夫婦・家族，Familiar Distance は
友人，Acquaintance Distance は社会的な知り合いに該当させた．また，1 対多で通信を行
う「グループ」では，Transmission Distance と No Transmission Distance の 2 階層に分
け，グループ全体に Status を通知するか否かを分けた．
そして，新しい Presence Service の利便性の向上を示すため，LINE システムの 1 日に
最も通信を行う 1 時間の 1 人あたりのトラフィック量 466KB と，新しい Presence Service
– 26 –
を追加したときの 1 日に最も通信を行う 1 時間の 1 人あたりのトラフィック量 766KB であ
ることを求めた．LINE システムと新しい Presence Service を追加したときのトラフィック
量より，増加量は約 1.6 倍であることを示した．LINE システムに新しい Presence Service
を追加してもトラフィック量は約 1.6 倍ですむことから，新しい Presence Service を追加し
たシステムは実現可能な範囲であることを示した．よって，本提案は LINE アプリケーショ
ンの利便性の向上させ得ることを示し，円滑なコミュニケーション化をはかることが可能で
ある．
– 27 –
謝辞
本研究を進めるにあたり，指導教員としてご指導いただきました高知工科大学情報学群
島村和典教授に心より感謝いたします．教授には，日ごろから大変ためになることを数多く
指導頂き，感謝しております．卒業研究論文の副査として，的確なご指導を頂きました，妻
鳥貴彦准教授，植田和憲講師に心より感謝いたします．
さらに，島村研究室修士 2 年の小笠原一聡氏にも，研究について気にかけて頂いて，感謝
いたします．梗概の添削の指導などにも時間を割いてアドバイスを頂き，ありがとうござい
ました．また，修士 1 年の赤澤将太氏には，IoN グループの上司として，熱心なご指導とご
意見を頂きました．特に，学会の梗概の添削に時間をかけて指導していただき感謝していま
す．また，定期的に研究について声をかけてくださり，相談にも親身になって乗って頂き，
心より感謝しています．研究のことだけでなく，社会に出てからのアドバイスなども頂き，
とてもためになることを多く頂きました．研究室の活動でも何事にも率先して取り組む姿を
みて，見習うべきところが数多くありました．今後の生活に生かして参ります．修士 2 年の
京極海氏，島田裕幸氏，辻際宗和氏，修士 1 年の竹本万里雄氏には，的確なアドバイスとご
指摘を頂き，身になることばかりでした．また，同期の上田安柚香氏，國和武司氏，中島春
菜氏，三角隆太氏，吉本圭佑氏，渡部弘章氏には短いながら一緒に 2 年間島村研究室で過ご
してきました．研究のみならずソフトウェア工学の講義や研究室活動でたくさんお世話にな
りました．助けや多くのアドバイスも頂き，同期であるため話しやすく，よく相談にものっ
て頂き心より感謝いたします．上田安柚香氏には，豊富な知識を頂き，また食べ物はよく噛
んで食べることの大切さを教えて頂きました．國和武司氏には，困っているときにアドバイ
スを頂き，たくさん助けて頂きました．中島春菜氏には，いつも笑顔で話しかけて頂き，美
味しいご飯屋さんも数多く教えて頂きました．三角隆太氏には，たくさん笑わせて頂き，た
のしい研究室活動をさせて頂きました．吉本圭佑氏には，冷静な判断と几帳面な姿から多く
を学ばせて頂きました．渡部弘章氏には，困ったときにそっとアドバイスや手伝いをして頂
– 28 –
謝辞
きました．同期のみなさんには大変感謝しております．このメンバーと共に過ごせて幸せで
した．今後は，それぞれの就職で高知を離れて，寂しくなりますが今後ともよろしくお願い
いたします．また，学部 3 年の今田七海氏，高野雅裕氏，中村真也氏，宮野拓洋氏，山崎秋
音氏，吉崎友拓氏は日ごろからたくさんの元気を頂きました．他愛もない話をたくさんし，
楽しい時間を過ごさせて頂きました．感謝いたします．今後ともよろしくお願いいたします．
最後になりますが，大学に進学させてくれた両親に，心より感謝申し上げます．一番身近
な相談相手として親身になって話を聞いてくれたり，時には厳しく間違いを正してくださり，
大変救われました．今後も恩を忘れず，精進していきたいと思います．ここまで 22 年間育
てて頂き本当にありがとうございました．今後ともよろしくお願いします．最後に，私を支
えてくださった皆様に心から感謝の気持ちと御礼を申し上げ，謝辞に代えさせて頂きます．
– 29 –
参考文献
[1] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h26/html/
nc253120.html 総務省 情報通信の現状・政策の動向（2015 年 1 月 23 日）．
[2] 井上友人，沖中秀夫，竹内芳明，竹田義行，花澤隆，”NGN 教科書”pp.2-8，2008 年
[3] 坂口克彦，”エッセンシャル SIP”，pp.29，2005 年
[4] 赤澤将太，島村和典，”NGN における Presence 通知プロトコルの研究”，平成 25 年度
学士学位論文
[5] ゴンザロ・カマリロ，ミゲール・A・マーチン共著，澤田拓也，鹿島拓也，海老原成，
永松良一訳，”IMS 標準テキスト 改訂版”，pp453，2010 年
[6] http://www.soumu.go.jp/iicp/chousakenkyu/data/research/survey/
telecom/2014/h25mediariyou_1sokuhou.pdf 総 務 省 平 成 25 年 情 報 通 信 メ
ディアの利用時間と情報行動に関する調査（2015 年 2 月 3 日）．
[7] file:///C:/Users/sawa.senba/Downloads/mediaguide_LINE_2014_4_9\
%20(2).pdf LINE 株式会社 LINE 2014 年 4-9 月媒体資料（2015 年 2 月 5 日）
[8] J.Rosenberg.”A Data Model for Presence”.RFC4479 Inernet Engineering Task
Force, July 2006
[9] H.Sugano, S.Fuhimoto, G.Klyne, A.Bateman, W.Carr, and J.Peterson.”Presence
Information Data Format（PIDF）”.RFC3863, Internet Engineering Task Force,
August 2004.
[10] H.Schulzrinne, V.Gurbani, and J. Rosenberg.”RPID:Rich Presence Extensions to
the Presence Information Data Format（PIDF）”.RFC4480, Internet Engineering
Task Force, July 2006.
– 30 –