知財求人 - 知財ポータルサイト「IP Force」
特許7446716メッセンジャーサービスでユーザ状況に合わせて効率的にマルチメディアメッセージを提供する方法およびシステム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-03-01
(45)【発行日】2024-03-11
(54)【発明の名称】メッセンジャーサービスでユーザ状況に合わせて効率的にマルチメディアメッセージを提供する方法およびシステム
(51)【国際特許分類】
H04L 51/04 20220101AFI20240304BHJP
【ＦＩ】
H04L51/04
【請求項の数】
23
(21)【出願番号】P 2019054294
(22)【出願日】2019-03-22
(65)【公開番号】P2019175450
(43)【公開日】2019-10-10
【審査請求日】2022-03-14
(31)【優先権主張番号】10-2018-0036776
(32)【優先日】2018-03-29
(33)【優先権主張国・地域又は機関】KR
【前置審査】
(73)【特許権者】
【識別番号】516014409
【氏名又は名称】ライン プラス コーポレーション
【氏名又は名称原語表記】ＬＩＮＥ Ｐｌｕｓ Ｃｏｒｐｏｒａｔｉｏｎ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ジャン ヒョクジェ
【審査官】岩田 玲彦
(56)【参考文献】
【文献】特表２００４－５１６６９３（ＪＰ，Ａ）
【文献】特開２０１７－０４１２３２（ＪＰ，Ａ）
【文献】特表２０１６－５０７８２０（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ ５１／０４
(57)【特許請求の範囲】
【請求項1】
メッセンジャーサーバによって実行されるマルチメディアメッセージ提供方法であって、
前記メッセンジャーサーバが、送信者端末から、受信者端末へのマルチメディアメッセージの送信要求を受信する段階、
前記メッセンジャーサーバが、前記送信者端末および前記受信者端末それぞれから収集される状況情報を分析して、前記送信者端末および前記受信者端末それぞれの状況を決定する段階、
前記メッセンジャーサーバが、前記決定された状況に応じ、前記マルチメディアメッセージの原本マルチメディアデータについて、前記送信者端末から受信されるべきデータの第１種類および前記受信者端末に送信されるべきデータの第２種類を決定する段階であって、前記第１種類のデータおよび前記第２種類のデータは、前記原本マルチメディアデータに基づいており、前記第１種類のデータは、前記原本マルチメディアデータまたは前記原本マルチメディアデータのプレビューのうちのいずれか１つを含む、段階、および
前記メッセンジャーサーバが、前記マルチメディアメッセージの送信要求を処理する段階であって、
前記メッセンジャーサーバが、前記送信者端末から、前記第１種類のデータを含む前記マルチメディアメッセージを受信する段階と、
前記送信者端末から前記第１種類のデータを含む前記マルチメディアメッセージを受信したことに応答して、前記メッセンジャーサーバが、前記受信者端末に、前記第２種類のデータを含む前記マルチメディアメッセージを送信する段階と、
を含む、前記マルチメディアメッセージの送信要求を処理する段階、
を含む、マルチメディアメッセージ提供方法。
【請求項2】
前記収集される状況情報は、前記送信者端末のネットワーク状況、前記受信者端末のネットワーク状況、受信者が前記受信者端末を使用中であるか否か、前記受信者端末のアクセス可能性、前記受信者が前記受信者端末および／または前記受信者端末にインストールされたメッセンジャーアプリケーションの使用に没入する強度、前記受信者の明示的な入力に応じて前記受信者端末から受信される原本要求のうちの２つ以上に関する情報を含む、請求項１に記載のマルチメディアメッセージ提供方法。
【請求項3】
前記第２種類のデータは、前記マルチメディアメッセージの送信に対するイベント、前記原本マルチメディアデータ、および前記原本マルチメディアデータに対するプレビューのうちのいずれか１つを含み、前記決定された状況において、前記第１種類のデータと前記第２種類のデータは、互いに異なるデータとして決定される、
請求項１に記載のマルチメディアメッセージ提供方法。
【請求項4】
前記収集される状況情報の変化に伴って前記決定された状況が変わる場合、前記メッセンジャーサーバが、前記変わった状況に応じて前記第１種類および前記第２種類のうちの少なくとも一方を変更する段階、および前記メッセンジャーサーバが、前記送信者端末から前記変更された第１種類のデータをさらに受信するか、または前記受信者端末に前記変更された第２種類のデータをさらに送信する段階
をさらに含む、請求項１に記載のマルチメディアメッセージ提供方法。
【請求項5】
前記マルチメディアメッセージの送信要求を処理する段階は、前記メッセンジャーサーバが、前記送信者端末から前記第１種類のデータとして前記原本マルチメディアデータを受信および記録する段階、
前記メッセンジャーサーバが、前記原本マルチメディアデータに対するプレビューを生成する段階、
前記メッセンジャーサーバが、前記生成されたプレビューを前記第２種類のデータとして前記受信者端末に送信する段階、および
前記メッセンジャーサーバが、前記受信者端末から前記プレビューを基盤とした原本要求が受信され、状況の変化に伴い、前記記録された原本マルチメディアデータを、変更された第２種類のデータとして前記受信者端末に送信する段階
を含む、請求項１に記載のマルチメディアメッセージ提供方法。
【請求項6】
前記マルチメディアメッセージの送信要求を処理する段階は、前記メッセンジャーサーバが、前記送信者端末から前記第１種類のデータとして前記原本マルチメディアデータに対するプレビューを受信する段階、
前記メッセンジャーサーバが、前記プレビューを前記第２種類のデータとして前記受信者端末に送信する段階、
前記メッセンジャーサーバが、前記受信者端末から前記プレビューを基盤とした原本要求が受信され、状況の変化に伴い、前記送信者端末から変更された第１種類のデータとして前記原本マルチメディアデータを受信する段階、および
前記メッセンジャーサーバが、前記受信した原本マルチメディアデータを、変更された第２種類のデータとして前記受信者端末に送信する段階
を含む、請求項１に記載のマルチメディアメッセージ提供方法。
【請求項7】
前記マルチメディアメッセージの送信要求を処理する段階は、前記メッセンジャーサーバが、前記マルチメディアメッセージの送信についてのイベントを前記第２種類のデータとして前記受信者端末に送信する段階、
前記メッセンジャーサーバが、前記受信者端末にインストールされたメッセンジャーアプリケーションを通じて前記イベントの表示を認識する段階、および
前記認識に応答し、前記メッセンジャーサーバが、前記送信者端末から、前記第１種類のデータとして前記原本マルチメディアデータに対するプレビューおよび前記原本マルチメディアデータのうちのいずれか１つのデータを受信する段階、
前記イベントの表示が認識されて状況が変化することに伴い、前記メッセンジャーサーバが、前記プレビューおよび前記原本マルチメディアデータのうちのいずれか１つのデータを、変更された第２種類のデータとして前記受信者端末に送信する段階
を含む、請求項１に記載のマルチメディアメッセージ提供方法。
【請求項8】
前記いずれか１つのデータを受信する段階は、前記送信者端末から前記プレビューを受信して前記受信者端末に送信した場合、前記メッセンジャーサーバが、前記受信者端末から前記プレビューを基盤とした原本要求が受信され、追って状況が変化することに伴い、前記送信者端末から変更された第１種類のデータとして前記原本マルチメディアデータを受信する段階を含み、
前記いずれか１つのデータを前記受信者端末に送信する段階は、前記メッセンジャーサーバが、前記受信した原本マルチメディアデータを前記変更された第２種類のデータとして前記受信者端末に追って送信する段階を含む、
請求項７に記載のマルチメディアメッセージ提供方法。
【請求項9】
前記メッセンジャーサーバが、前記受信者端末に予め送信されたデータに対する送信履歴を管理する段階、前記メッセンジャーサーバが、前記管理される送信履歴から、前記第２種類のデータが前記受信者端末に送信された履歴が存在するかを確認する段階、および
前記第２種類のデータが前記受信者端末に送信された履歴が存在する場合、前記メッセンジャーサーバが、前記第２種類のデータの識別子または前記第２種類のデータを送信するのに利用されたメッセージの識別子を前記受信者端末に送信する段階
をさらに含み、
前記受信者端末では、前記データの識別子またはメッセージの識別子により、予め送信されて前記受信者端末に記録されたデータが識別される、
請求項１に記載のマルチメディアメッセージ提供方法。
【請求項10】
メッセンジャーサーバとして構成されるコンピュータと結合して請求項１乃至９のうちのいずれか一項に記載の方法を前記コンピュータに実行させる、コンピュータプログラム。
【請求項11】
請求項１乃至９のうちのいずれか一項に記載の方法をメッセンジャーサーバとして構成されるコンピュータに実行させるためのプログラムが記録されている、コンピュータ読み取り可能な記録媒体。
【請求項12】
コンピュータと結合してマルチメディアメッセージ提供方法をコンピュータに実行させるためにコンピュータ読み取り可能な記録媒体に記録されたコンピュータプログラムであって、前記マルチメディアメッセージ提供方法は、
送信者端末が、受信者端末へのマルチメディアメッセージの送信要求をメッセンジャーサーバに送信する段階、
前記送信者端末が、前記メッセンジャーサーバに状況情報を送信する段階、および
前記送信された状況情報および前記受信者端末から受信した状況情報を分析して前記メッセンジャーサーバによって決定された、前記送信者端末および前記受信者端末それぞれの状況に応じて前記メッセンジャーサーバによって要求される、前記マルチメディアメッセージの原本マルチメディアデータに基づく第１種類のデータを含む前記マルチメディアメッセージを、前記送信者端末が前記メッセンジャーサーバに送信する段階であって、前記メッセンジャーサーバは、前記送信者端末から前記第１種類のデータを含む前記マルチメディアメッセージを受信したことに応答して、前記受信者端末に、第２種類のデータを含む前記マルチメディアメッセージを送信するように構成され、前記第１種類のデータおよび前記第２種類のデータは、前記原本マルチメディアデータに基づいており、前記第１種類のデータは、前記原本マルチメディアデータまたは前記原本マルチメディアデータのプレビューのうちのいずれか１つを含む、段階
を含む、コンピュータプログラム。
【請求項13】
前記送信された状況情報は、前記送信者端末のネットワーク状況に関する情報を含み、前記受信者端末から受信した状況情報は、前記受信者端末のネットワーク状況、受信者が前記受信者端末を使用中であるか否か、アクセス可能性、使用没入強度、前記受信者の明示的な入力に応じて前記受信者端末から受信される原本要求のうちの少なくとも１つに関する情報を含む、
請求項１２に記載のコンピュータプログラム。
【請求項14】
前記第２種類のデータは、前記メッセンジャーサーバにより、前記決定された状況に応じて前記マルチメディアメッセージの送信についてのイベント、前記原本マルチメディアデータ、および前記原本マルチメディアデータに対するプレビューのうちのいずれか１つとして決定され、前記決定された状況において、前記第１種類のデータと前記第２種類のデータは、互いに異なるデータとして決定される、
請求項１２に記載のコンピュータプログラム。
【請求項15】
前記送信された状況情報および前記受信者端末から受信した状況情報のうちのいずれか１つが時間とともに変化することに伴って前記メッセンジャーサーバで決定される状況が変わる場合、前記変わった状況に応じて前記第１種類が変更され、前記マルチメディアメッセージ提供方法は、
前記送信者端末が、前記変更された第１種類のデータを前記メッセンジャーサーバにさらに送信する段階
をさらに含む、請求項１２に記載のコンピュータプログラム。
【請求項16】
前記送信者端末が、前記メッセンジャーサーバに送信したデータに対する送信履歴を管理する段階、前記送信者端末が、前記管理される送信履歴から、前記第１種類のデータが前記メッセンジャーサーバに送信された履歴が存在するかを確認する段階、および
前記送信者端末が、前記第１種類のデータが前記メッセンジャーサーバに送信された履歴が存在する場合、前記第１種類のデータの識別子または前記第１種類のデータを送信するのに利用されたメッセージの識別子を前記メッセンジャーサーバに送信する段階
をさらに含み、
前記メッセンジャーサーバでは、前記データの識別子またはメッセージの識別子により、予め送信されて前記メッセンジャーサーバに記録されたデータが識別される、
請求項１２に記載のコンピュータプログラム。
【請求項17】
コンピュータ装置であって、当該コンピュータ装置は、メッセンジャーサーバとして構成され、
コンピュータ読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサ
を含み、
前記少なくとも１つのプロセッサにより、
送信者端末から受信者端末へのマルチメディアメッセージの送信要求を受信し、
前記送信者端末および前記受信者端末それぞれから収集される状況情報を分析して、前記送信者端末および前記受信者端末それぞれの状況を決定し、
前記決定された状況に応じ、前記マルチメディアメッセージの原本マルチメディアデータついて、前記送信者端末から受信されるべきデータの第１種類および前記受信者端末に送信されるべきデータの第２種類を決定することであって、前記第１種類のデータおよび前記第２種類のデータは、前記原本マルチメディアデータに基づいており、前記第１種類のデータは、前記原本マルチメディアデータまたは前記原本マルチメディアデータのプレビューのうちのいずれか１つを含み、
前記マルチメディアメッセージの送信要求を処理することであって、
前記送信者端末から、前記第１種類のデータを含む前記マルチメディアメッセージを受信することと、
前記送信者端末から前記第１種類のデータを含む前記マルチメディアメッセージを受信したことに応答して、前記受信者端末に、前記第２種類のデータを含む前記マルチメディアメッセージを送信することと、
によって、前記マルチメディアメッセージの送信要求を処理する、コンピュータ装置。
【請求項18】
前記収集される状況情報は、前記送信者端末のネットワーク状況、前記受信者端末のネットワーク状況、受信者が前記受信者端末を使用中であるか否か、前記受信者端末のアクセス可能性、前記受信者が前記受信者端末および／または前記受信者端末にインストールされたメッセンジャーアプリケーションの使用に没入する強度、前記受信者の明示的な入力に応じて前記受信者端末から受信される原本要求のうちの２つ以上に関する情報を含む、請求項１７に記載のコンピュータ装置。
【請求項19】
前記第２種類のデータは、前記マルチメディアメッセージの送信についてのイベント、前記原本マルチメディアデータ、および前記原本マルチメディアデータに対するプレビューのうちのいずれか１つを含み、前記決定された状況において、前記第１種類のデータと前記第２種類のデータは、互いに異なるデータとして決定される、
請求項１７に記載のコンピュータ装置。
【請求項20】
前記少なくとも１つのプロセッサにより、前記収集される状況情報の変化に伴って前記決定された状況が変わる場合、前記変わった状況に応じて前記第１種類および前記第２種類のうちの少なくとも一方を変更し、
前記送信者端末から前記変更された第１種類のデータをさらに受信するか、または前記受信者端末に前記変更された第２種類のデータをさらに送信する、
請求項１７に記載のコンピュータ装置。
【請求項21】
メッセンジャーサーバによって実行されるマルチメディアメッセージ提供方法であって、
送信者端末から受信者端末へのマルチメディアメッセージの送信要求を受信する段階、
前記送信者端末および前記受信者端末それぞれから収集される状況情報を分析して、前記送信者端末および前記受信者端末それぞれの状況を決定する段階、
前記決定された状況に応じ、前記マルチメディアメッセージの原本マルチメディアデータについて、前記送信者端末から受信されるべきデータの第１種類および前記受信者端末に送信されるべきデータの第２種類を決定する段階、および
前記第１種類のデータを含む前記マルチメディアメッセージを前記送信者端末から受信し、前記第２種類のデータを含む前記マルチメディアメッセージを前記受信者端末に送信することによって、前記マルチメディアメッセージの送信要求を処理する段階
を含み、
前記受信者端末に予め送信されたデータに対する送信履歴を管理する段階、
前記管理される送信履歴から、前記第２種類のデータが前記受信者端末に送信された履歴が存在するかを確認する段階、および
前記第２種類のデータが前記受信者端末に送信された履歴が存在する場合、前記第２種類のデータの識別子または前記第２種類のデータを送信するのに利用されたメッセージの識別子を前記受信者端末に送信する段階、
をさらに含む、マルチメディアメッセージ提供方法。
【請求項22】
コンピュータと結合してマルチメディアメッセージ提供方法をコンピュータに実行させるためにコンピュータ読み取り可能な記録媒体に記録されたコンピュータプログラムであって、前記マルチメディアメッセージ提供方法は、
送信者端末が、受信者端末へのマルチメディアメッセージの送信要求をメッセンジャーサーバに送信する段階、
前記送信者端末が、前記メッセンジャーサーバに状況情報を送信する段階、および
前記送信された状況情報および前記受信者端末から受信した状況情報を分析して前記メッセンジャーサーバによって決定された、前記送信者端末および前記受信者端末それぞれの状況に応じて前記メッセンジャーサーバによって要求される、前記マルチメディアメッセージの原本マルチメディアデータに基づく第１種類のデータを含む前記マルチメディアメッセージを、前記送信者端末が前記メッセンジャーサーバに送信する段階
を含み、前記マルチメディアメッセージ提供方法は、
前記メッセンジャーサーバに送信したデータに対する送信履歴を管理する段階、
前記管理される送信履歴から、前記第１種類のデータが前記メッセンジャーサーバに送信された履歴が存在するかを確認する段階、および
前記第１種類のデータが前記メッセンジャーサーバに送信された履歴が存在する場合、前記第１種類のデータの識別子または前記第１種類のデータを送信するのに利用されたメッセージの識別子を前記メッセンジャーサーバに送信する段階、
をさらに含む、コンピュータプログラム。
【請求項23】
コンピュータ装置であって、当該コンピュータ装置は、メッセンジャーサーバとして構成され、
コンピュータ読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサ
を含み、
前記少なくとも１つのプロセッサにより、
送信者端末から受信者端末へのマルチメディアメッセージの送信要求を受信し、
前記送信者端末および前記受信者端末それぞれから収集される状況情報を分析して、前記送信者端末および前記受信者端末それぞれの状況を決定し、
前記決定された状況に応じ、前記マルチメディアメッセージの原本マルチメディアデータについて、前記送信者端末から受信されるべきデータの第１種類および前記受信者端末に送信されるべきデータの第２種類を決定し、
前記第１種類のデータを含む前記マルチメディアメッセージを前記送信者端末から受信し、前記第２種類のデータを含む前記マルチメディアメッセージを前記受信者端末に送信することによって、前記マルチメディアメッセージの送信要求を処理し、
前記少なくとも１つのプロセッサにより、
前記受信者端末に予め送信されたデータに対する送信履歴を管理し、
前記管理される送信履歴から、前記第２種類のデータが前記受信者端末に送信された履歴が存在するかを確認し、
前記第２種類のデータが前記受信者端末に送信された履歴が存在する場合、前記第２種類のデータの識別子または前記第２種類のデータを送信するのに利用されたメッセージの識別子を前記受信者端末に送信する、コンピュータ装置。
【発明の詳細な説明】
【技術分野】
【0001】
以下の説明は、メッセンジャーサービスでユーザ状況（ｃｏｎｔｅｘｔ）に合わせて効率的にマルチメディアメッセージを提供する方法およびシステムに関し、より詳細には、メッセンジャーサービスでメッセージの送信者と受信者それぞれの状況に合わせてマルチメディアメッセージを効率的に送信、受信、および／または表示することができるマルチメディアメッセージ提供方法、マルチメディアメッセージ提供方法を実行するコンピュータ装置、コンピュータ装置と結合してマルチメディアメッセージ提供方法をコンピュータ装置に実行させるためにコンピュータ読み取り可能な記録媒体に記録されたコンピュータプログラムとその記録媒体に関する。
【背景技術】
【0002】
最近のメッセンジャーサービスにおいて、ユーザは、単なるテキストメッセージだけでなく、写真や動画、音声録音などのような多様なマルチメディアメッセージをやり取りする。例えば、特許文献１は、モバイル・マルチメディア・インスタントメッセンジャーサービス・システムおよびこれを利用したモバイル・マルチメディア・メッセンジャーサービス方法に関するものであり、モバイル・マルチメディア・インスタントメッセンジャーサービス・システムを利用してカメラで撮影したイメージや動画を含むマルチメディアデータをメッセンジャーサービス内でリアルタイムにやり取りすることができるモバイル・マルチメディア・メッセンジャーサービス方法を開示している。
【0003】
ところが、このようなマルチメディアメッセージのサイズは、テキストメッセージとは異なり、単一メッセージの場合でも、一例として、数百キロバイト（ｋｉｌｏｂｙｔｅ：ＫＢ）から数十メガバイト（ｍｅｇａｂｙｔｅ：ＭＢ）のようにテキストメッセージに比べて極めて大きい。したがって、ネットワーク状況が良くない地域や国では、このようなマルチメディアメッセージの送受信に遅延が生じることがあり、最悪の場合は送受信自体ができなくなることもある。
【先行技術文献】
【特許文献】
【0004】
【文献】韓国公開特許第１０－２００６－００３９４９７号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
メッセンジャーサービスでメッセージの送信者と受信者それぞれの状況（ｃｏｎｔｅｘｔ）に合わせてマルチメディアメッセージを効率的に送信、受信、および／または表示することができるマルチメディアメッセージ提供方法、マルチメディアメッセージ提供方法を実行するコンピュータ装置、コンピュータ装置と結合してマルチメディアメッセージ提供方法をコンピュータ装置に実行させるためにコンピュータ読み取り可能な記録媒体に記録されたコンピュータプログラムとその記録媒体を提供する。
【課題を解決するための手段】
【0006】
送信者端末から受信者端末へのマルチメディアメッセージの送信要求を受信する段階、前記送信者端末および前記受信者端末それぞれから収集される状況情報を分析して状況を決定する段階、前記決定された状況に応じ、前記マルチメディアメッセージに含まれる原本マルチメディアデータに対し、前記送信者端末から受信されるべきデータの第１種類および前記受信者端末に送信されるべきデータの第２種類を決定する段階、および前記原本マルチメディアデータに対し、前記決定された第１種類のデータを前記送信者端末から受信し、前記決定された第２種類のデータを前記受信者端末に送信することによって前記マルチメディアメッセージの送信要求を処理する段階を含む、マルチメディアメッセージ提供方法を提供する。
【0007】
一側面によると、前記収集される状況情報は、前記送信者端末のネットワーク状況、前記受信者端末のネットワーク状況、受信者が前記受信者端末を使用中であるか否か、アクセス可能性、使用没入強度、前記受信者の明示的な入力に応じて前記受信者端末から受信される原本要求のうちの２つ以上に関する情報を含んでよい。
【0008】
他の側面によると、前記第１種類のデータは、前記原本マルチメディアデータおよび前記原本マルチメディアデータに対するプレビューのうちのいずれか１つを含み、前記第２種類のデータは、前記マルチメディアメッセージの送信に対するイベント、前記原本マルチメディアデータ、および前記原本マルチメディアデータに対するプレビューのうちのいずれか１つを含み、前記決定された状況において、前記第１種類のデータと前記第２種類のデータは、互いに異なるデータとして決定されてよい。
【0009】
また他の側面によると、前記マルチメディアメッセージ提供方法は、前記収集される状況情報の変化に伴って前記決定された状況が変わる場合、前記変わった状況に応じて前記第１種類および前記第２種類のうちの少なくとも一方を変更する段階、および前記送信者端末から前記変更された第１種類のデータをさらに受信するか、または前記受信者端末に前記変更された第２種類のデータをさらに送信する段階をさらに含んでよい。
【0010】
また他の側面によると、前記マルチメディアメッセージの送信要求を処理する段階は、前記送信者端末から前記第１種類のデータとして前記原本マルチメディアデータを受信して記録する段階、前記原本マルチメディアデータに対するプレビューを生成する段階、前記生成されたプレビューを前記第２種類のデータとして前記受信者端末に送信する段階、および前記受信者端末から前記プレビューを基盤とした原本要求が受信され、状況の変化に伴い、前記記録された原本マルチメディアデータを変更された第２種類のデータとして前記受信者端末に送信する段階を含んでよい。
【0011】
また他の側面によると、前記マルチメディアメッセージの送信要求を処理する段階は、前記送信者端末から前記第１種類のデータとして前記原本マルチメディアデータに対するプレビューを受信する段階、前記プレビューを前記第２種類のデータとして前記受信者端末に送信する段階、前記受信者端末から前記プレビューを基盤とした原本要求が受信され、状況の変化に伴い、前記送信者端末から変更された第１種類のデータとして前記原本マルチメディアデータを受信する段階、および前記受信した原本マルチメディアデータを変更された第２種類のデータとして前記受信者端末に送信する段階を含んでよい。
【0012】
また他の側面によると、前記マルチメディアメッセージの送信要求を処理する段階は、前記イベントを前記第２種類のデータとして前記受信者端末に送信する段階、前記受信者端末にインストールされたメッセンジャーアプリケーションを通じて前記イベントが表示されることを認識する段階、前記認識に応答し、前記送信者端末から前記第１種類のデータとして前記原本マルチメディアデータに対するプレビューおよび前記原本マルチメディアデータのうちのいずれか１つのデータを受信する段階、および前記イベントの表示が認識されて状況が変化することに伴い、前記プレビューおよび前記原本マルチメディアデータのうちのいずれか１つのデータを変更された第２種類のデータとして前記受信者端末に送信する段階を含んでよい。
【0013】
また他の側面によると、前記いずれか１つのデータを受信する段階は、前記送信者端末から前記プレビューを受信して前記受信者端末に送信した場合、前記受信者端末からの前記プレビューを基盤とした原本要求が受信され、状況が追って変化することに伴い、前記送信者端末から変更された第１種類のデータとして前記原本マルチメディアデータを受信する段階を含み、前記いずれか１つのデータを前記受信者端末に送信する段階は、前記受信した原本マルチメディアデータを変更された第２種類のデータとして前記受信者端末に追って送信する段階を含んでよい。
【0014】
さらに他の側面によると、前記マルチメディアメッセージ提供方法は、前記受信者端末に送信済みのデータに対する送信履歴を管理する段階、前記管理される送信履歴から、前記第２種類のデータが前記受信者端末に送信された履歴が存在するかを確認する段階、および前記第２種類のデータが前記受信者端末に送信された履歴が存在する場合、前記第２種類のデータの識別子または前記第２種類のデータを送信するのに利用されたメッセージの識別子を前記受信者端末に送信する段階をさらに含み、前記受信者端末では、前記データの識別子またはメッセージの識別子を利用して前記受信者端末に送信済みの記録されたデータが識別されてよい。
【0015】
送信者端末が、受信者端末へのマルチメディアメッセージの送信要求をメッセンジャーサーバに送信する段階、前記送信者端末が前記メッセンジャーサーバに状況情報を送信する段階、および前記送信された状況情報および前記受信者端末から受信した状況情報を分析して前記メッセンジャーサーバによって決定される状況に応じて前記メッセンジャーサーバによって要求される、前記マルチメディアメッセージに含まれる原本マルチメディアデータに対する第１種類のデータを、前記送信者端末が前記メッセンジャーサーバに送信する段階を含む、マルチメディアメッセージ提供方法を提供する。
【0016】
コンピュータ装置と結合して前記マルチメディアメッセージ提供方法をコンピュータ装置に実行させるためにコンピュータ読み取り可能な記録媒体に記録された、コンピュータプログラムを提供する。
【0017】
前記マルチメディアメッセージ提供方法をコンピュータ装置に実行させるためのプログラムが記録されている、コンピュータ読み取り可能な記録媒体を提供する。
【0018】
コンピュータ装置であって、コンピュータ読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサを含み、前記少なくとも１つのプロセッサにより、送信者端末から受信者端末へのマルチメディアメッセージの送信要求を受信し、前記送信者端末および前記受信者端末それぞれから収集される状況情報を分析して状況を決定し、前記決定された状況に応じ、前記マルチメディアメッセージが含む原本マルチメディアデータに対し、前記送信者端末から受信されるべきデータの第１種類および前記受信者端末に送信すべきデータの第２種類を決定し、前記原本マルチメディアデータに対し、前記決定された第１種類のデータを前記送信者端末から受信し、前記決定された第２種類のデータを前記受信者端末に送信することによって前記マルチメディアメッセージの送信要求を処理する、コンピュータ装置を提供する。
【0019】
コンピュータ装置で読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサを含み、前記少なくとも１つのプロセッサにより、送信者端末が受信者端末へのマルチメディアメッセージの送信要求をメッセンジャーサーバに送信し、前記送信者端末が前記メッセンジャーサーバに状況情報を送信し、前記送信した状況情報および前記受信者端末から受信された状況情報を分析して前記メッセンジャーサーバによって決定される状況に応じて前記メッセンジャーサーバが要求する前記マルチメディアメッセージが含む原本マルチメディアデータに対する第１種類のデータを、前記送信者端末が前記メッセンジャーサーバに送信する、コンピュータ装置を提供する。
【発明の効果】
【0020】
メッセンジャーサービスでメッセージの送信者と受信者それぞれの状況（ｃｏｎｔｅｘｔ）に合わせてマルチメディアメッセージを効率的に送信、受信、および／または表示することができる。
【図面の簡単な説明】
【0021】
【図1】本発明の一実施形態における、ネットワーク環境の例を示した図である。
【図2】本発明の一実施形態における、コンピュータ装置の例を示したブロック図である。
【図3】本発明の一実施形態における、マルチメディアメッセージを提供する例を示した図である。
【図4】本発明の一実施形態における、プレビューの等級および／または形式の例を示した図である。
【図5】本発明の一実施形態における、プレビューの等級および／または形式の他の例を示した図である。
【図6】本発明の一実施形態における、送信データの重複送信防止のための過程の例を示した図である。
【図7】本発明の一実施形態における、送信データの重複送信防止のための過程の他の例を示した図である。
【図8】本発明の一実施形態における、メッセンジャーサーバのマルチメディアメッセージ提供方法の例を示したフローチャートである。
【図9】本発明の一実施形態における、マルチメディアメッセージの送信要求を処理する第１例を示したフローチャートである。
【図10】本発明の一実施形態における、マルチメディアメッセージの送信要求を処理する第２例を示したフローチャートである。
【図11】本発明の一実施形態における、マルチメディアメッセージの送信要求を処理する第３例を示したフローチャートである。
【図12】本発明の一実施形態における、受信者端末に送信されるデータの重複送信防止のための例を示したフローチャートである。
【図13】本発明の一実施形態における、送信者端末のマルチメディアメッセージ提供方法の例を示したフローチャートである。
【発明を実施するための形態】
【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】
ナイーブベイズは条件付き確率モデルであって、分類されるインスタンスはＮ個の特性（従属変数）を示すベクターで表現される。ナイーブベイズ分類器は、このベクターを利用してｋ個の可能な確率的結果（クラス）を次の数式（１）のように割り当てる。
【0103】
【数1】
【0104】
【数2】
【0105】
【数3】
【0106】
実際に、上述した数式（３）では、分子部分だけが意味を有する。分母部分の場合には与えられたＣ値に依存せず、特性の値Ｆｉの場合には分母の値が定数になるように与えられるためである。分子部分は、次の数式（４）のような結合確率モデルである。
【0107】
【数4】
【0108】
【数5】
【0109】
ナイーブベイズにおいて条件付き独立性は、次の数式（６）のように表現されてよい。
【0110】
【数6】
【0111】
【数7】
【0112】
【数8】
【0113】
ナイーブベイズ分類は、このような確率モデルと決定規則を組み合わせたものであり、１つの共通する規則は、最も可能性の高い仮説を選択することである。これは、事後またはＭＡＰ決定規則の最大値を選択することを意味する。すなわち、ナイーブベイズ分類では、クラスｋ、すなわち、Ｃｋに対して次の数式（９）から最大確率を有するクラスｋを見つけ出す。
【0114】
【数9】
【0115】
一方、非確率的分類モデルとしては、サポートベクターマシン（Ｓｕｐｐｏｒｔ Ｖｅｃｔｏｒ Ｍａｃｈｉｎｅ：ＳＶＭ）が活用されてよい。サポートベクターマシンは、機械学習の分野の１つであって、パターン認識や資料分析のための指導学習モデルであり、分類と回帰分析のために主に使用される。２つのカテゴリのいずれか１つに属するデータの集合が与えられたとき、ＳＶＭアルゴリズムは、与えられたデータ集合に基づき、新たなデータがどのカテゴリに属するかを判断する非確率的２クラス線形分類モデルを生成する。生成された分類モデルは、データが思想された空間において境界として表現されるが、ＳＶＭアルゴリズムは、その中でも最大の幅を有する境界を探し出すアルゴリズムである。ＳＶＭは、線形分類とともに非線形分類でも使用されてよい。非線形分類のために与えられたデータを高次元特徴空間として思想する作業が必要となるが、これを効率的に行うためにカーネルトリックを使用したりもする。
【0116】
メッセンジャーサーバ３３０は、上述したような収集された状況情報というデータの集合（データのベクター）がどのカテゴリに属するかを連続的に分類することにより、データの集合に対応する状況（カテゴリ）として送信至急性と内容没入度を決定してよく、決定された状況に応じて送信方式（送信内容と送信時期／時点）を決定してよい。
【0117】
類似した方法として、メッセンジャーサーバ３３０は、収集された状況情報に関する未来予測を用いて未来の送信至急性と内容没入度を計算することも可能である。例えば、メッセンジャーサーバ３３０は、１時間後のネットワーク状況、アクセス可能性、使用状況などの状況情報を予想し、１時間後の送信至急性と内容没入度を計算してよい。この場合、メッセンジャーサーバ３３０は、現在の送信至急性と内容没入度、さらには未来に対して予想される送信至急性と内容没入度に対する変化予想推移（一例として、上昇、下落、維持）に基づき、マルチメディアメッセージに対する送信方式（送信内容と送信時点）を決定してよい。例えば、メッセンジャーサーバ３３０は、決定される送信内容と送信時点により、現時点では受信者端末３２０にマルチメディアメッセージに対するイベントだけを送信し、状況の変化が生じるまで１時間待機した後、原本マルチメディアメッセージを送信してよい。他の例として、メッセンジャーサーバ３３０は、送信者端末３１０に原本マルチメディアデータに対するプレビューを生成して伝達するようにし、受信者端末３２０にはマルチメディアメッセージに対するイベントだけを送信する送信方式を選択してよい。また他の例として、メッセンジャーサーバ３３０は、送信者端末３１０からは原本マルチメディアデータを受信し、メッセンジャーサーバ３３０でプレビューを生成して受信者端末３２０に送信し、以後は受信者端末３２０からの原本マルチメディアデータの要求に応じてメッセンジャーサーバ３３０が受信者端末３２０に原本マルチメディアデータを送信する送信方式を選択してもよい。
【0118】
図８は、本発明の一実施形態における、メッセンジャーサーバのマルチメディアメッセージ提供方法の例を示したフローチャートである。本実施形態に係るマルチメディアメッセージ提供方法は、一例として、上述したメッセンジャーサーバ３３０を実現するコンピュータ装置２００によって実行されてよい。例えば、コンピュータ装置２００のプロセッサ２２０は、メモリ２１０が含むオペレーティングシステムのコードと少なくとも１つのプログラムのコードとによる制御命令（ｉｎｓｔｒｕｃｔｉｏｎ）を実行するように実現されてよい。ここで、プロセッサ２２０は、コンピュータ装置２００に記録されたコードが提供する制御命令に従ってコンピュータ装置２００が図８のマルチメディアメッセージ提供方法に含まれる段階８１０～段階８４０を実行するようにコンピュータ装置２００を制御してよい。図８では、メッセンジャーサーバ３３０が段階８１０～段階８４０を実行する過程について説明する。
【0119】
段階８１０において、メッセンジャーサーバ３３０は、送信者端末から受信者端末へのマルチメディアメッセージの送信要求を受信することができる。一例として、送信者端末と受信者端末は、上述した送信者端末３１０および受信者端末３２０にそれぞれ対応してよい。一般的なメッセンジャーサービスでは、送信者端末は、原本マルチメディアデータが含まれるマルチメディアメッセージを直ぐにメッセンジャーサーバ３３０に送信するだけに過ぎない。この反面、本実施形態では、送信者端末での原本マルチメディアデータの送信方式がメッセンジャーサーバ３３０によって決定されるため、原本マルチメディアデータの送信に先立ち、マルチメディアメッセージの送信に対する要求をメッセンジャーサーバ３３０が受信してよい。
【0120】
段階８２０において、メッセンジャーサーバ３３０は、送信者端末および受信者端末それぞれから収集される状況情報を分析して状況を決定することができる。収集される状況情報は、一例として、送信者端末のネットワーク状況、受信者端末のネットワーク状況、受信者が受信者端末を使用中であるか否か、アクセス可能性、使用没入強度、受信者の明示的な入力に応じて受信者端末から受信される原本要求うちの２つ以上に関する情報を含んでよい。このような個別な状況情報と状況情報によって決定される状況については上述したとおりであるため、繰り返される説明は省略する。
【0121】
段階８３０において、メッセンジャーサーバ３３０は、決定された状況に応じ、マルチメディアメッセージが含む原本マルチメディアデータに対し、送信者端末から受信されるべきデータの第１種類および受信者端末に送信すべきデータの第２種類を決定することができる。例えば、第１種類のデータは、原本マルチメディアデータおよび原本マルチメディアデータに対するプレビューのうちのいずれか１つを含んでよい。また、第２種類のデータは、マルチメディアメッセージの送信に対するイベント、原本マルチメディアデータ、および原本マルチメディアデータに対するプレビューのうちのいずれか１つを含んでよい。このとき、メッセンジャーサーバ３３０で決定される少なくとも１つの状況において、第１種類のデータと第２種類のデータは、互いに異なるデータとして決定されてよい。一例として、図３を参照しながら説明したように、メッセンジャーサーバ３３０は、第１種類のデータとして送信者端末から原本マルチメディアデータが受信されたものの、ネットワーク状況が「悪い」である受信者端末のために、第２種類のデータとして原本マルチメディアデータのプレビューを生成して受信者端末に送信してよい。言い換えれば、メッセンジャーサーバ３３０は、決定される状況に応じ、送信者端末から受信するデータと受信者端末に送信するデータを互いに異なるデータとすることができる。
【0122】
段階８４０において、メッセンジャーサーバ３３０は、原本マルチメディアデータに対し、決定された第１種類のデータを送信者端末から受信し、決定された第２種類のデータを受信者端末に送信することによってマルチメディアメッセージの送信要求を処理することができる。このように、メッセンジャーサーバ３３０は、送信者端末が受信者端末に原本マルチメディアデータを含むマルチメディアメッセージを伝達するにあたり、送信者端末と受信者端末から収集される状況情報によって決定される状況に応じて、原本マルチメディアデータについて受信および／または送信されるべきデータの種類を決定して送信することにより、マルチメディアメッセージを効率的に送信、受信、および表示することができる。
【0123】
また、メッセンジャーサーバ３３０は、収集される状況情報の変化に伴って決定された状況が変わる場合、変わった状況に応じて第１種類および第２種類のうちの少なくとも一方を変更してよい。この場合、メッセンジャーサーバ３３０は、送信者端末から変更された第１種類のデータをさらに受信するか、または受信者端末に変更された第２種類のデータをさらに送信してよい。
【0124】
図９は、本発明の一実施形態における、マルチメディアメッセージの送信要求を処理する第１例を示したフローチャートである。図９の段階９１０～段階９４０は、上述した段階８４０に含まれて実行されてよい。一例として、図９の実施形態は、図３を参照しながら説明したように、送信者端末のネットワーク状況が「良い」であり、受信者端末のネットワーク状況が「悪い」であり、受信者の受信者端末に対する使用状況が「はい」であり、使用没入強度が「良い」である場合の実施形態であってよい。言い換えれば、図９の実施形態は、送信者端末に対しては送信至急性が高く、受信者端末に対しては、送信至急性は低いが内容没入度は高い場合のメッセンジャーサーバ３３０の動作の例を説明している。
【0125】
段階９１０において、メッセンジャーサーバ３３０は、送信者端末から第１種類のデータとして原本マルチメディアデータを受信して記録することができる。一例として、図３では、メッセンジャーサーバ３３０によって決定された送信方式に従って送信者端末が原本マルチメディアデータをアップロードし、メッセンジャーサーバ３３０がアップロードされた原本マルチメディアデータを受信して記録することについて説明した。
【0126】
段階９２０において、メッセンジャーサーバ３３０は、原本マルチメディアデータに対するプレビューを生成することができる。一例として、図４および図５を参照しながら、動画や音源のような多様な原本マルチメディアデータが複数の等級および／または形式によるプレビューとして生成されることについて説明した。より具体的な例として、メッセンジャーサーバ３３０によって決定される状況は、状況に応じてサブ状況を含んでよく、このようなサブ状況ごとに互いに異なる等級および／または形式のプレビューが生成されてよい。
【0127】
段階９３０において、メッセンジャーサーバ３３０は、生成されたプレビューを第２種類のデータとして受信者端末に送信することができる。例えば、図３では、メッセンジャーサーバ３３０が送信者端末から原本マルチメディアデータを受信したものの、ネットワーク状況が「悪い」である受信者端末のために、原本マルチメディアデータではなく原本マルチメディアデータのプレビューを送信することについて説明した。
【0128】
段階９４０において、メッセンジャーサーバ３３０は、受信者端末からプレビューを基盤とした原本要求が受信され、状況の変化に伴い、記録された原本マルチメディアデータを変更された第２種類のデータとして受信者端末に送信することができる。言い換えれば、メッセンジャーサーバ３３０は、既存の状況に応じて受信者端末にプレビューを送信したものの、受信者からの原本マルチメディアデータの要求に応じ、状況が変わった後に、変わった状況に合うように原本マルチメディアデータをさらに送信してよい。
【0129】
図１０は、本発明の一実施形態における、マルチメディアメッセージの送信要求を処理する第２例を示したフローチャートである。図１０の段階１０１０～段階１０４０は、上述した段階８４０に含まれて実行されてよい。本実施形態は、送信者端末のネットワーク状況が「悪い」であり、受信者端末のネットワーク状況が「良い」である場合であってよい。言い換えれば、図１０の実施形態は、送信者端末に対しては送信至急性が低く、受信者端末に対しては送信至急性が高い場合のメッセンジャーサーバ３３０の動作の例について説明する。
【0130】
段階１０１０において、メッセンジャーサーバ３３０は、送信者端末から第１種類のデータとして原本マルチメディアデータに対するプレビューを受信することができる。上述したように、送信者端末に対しては送信至急性が低いことから、送信者端末からは、初めから原本マルチメディアデータを受信するよりも、プレビューのように容量が相対的に少ないデータを受信してよい。
【0131】
段階１０２０において、メッセンジャーサーバ３３０は、プレビューを第２種類のデータとして受信者端末に送信することができる。
【0132】
段階１０３０において、メッセンジャーサーバ３３０は、受信者端末からプレビューを基盤とした原本要求が受信され、状況の変化に伴い、送信者端末から変更された第１種類のデータとして原本マルチメディアデータを受信することができる。
【0133】
段階１０４０において、メッセンジャーサーバ３３０は、受信した原本マルチメディアデータを変更された第２種類のデータとして受信者端末に送信することができる。
【0134】
このとき、受信者端末から原本要求が受信されるということは、受信者端末の状況が、送信至急性が最高に高くなったことを意味してよい。したがって、送信者端末の送信至急性は低かったとしても、メッセンジャーサーバ３３０は、受信者端末の送信至急性を優先視して送信者端末から原本マルチメディアデータを受信して受信者端末に送信してよい。
【0135】
図１１は、本発明の一実施形態における、マルチメディアメッセージの送信要求を処理する第３例を示したフローチャートである。図１１の段階１１１０～段階１１４０は、上述した段階８４０に含まれて実行されてよい。本実施形態は、送信者端末のネットワーク状況が「悪い」のように送信者端末に対して送信至急性が低く、受信者端末のネットワーク状況が「悪い」であり、受信者の受信者端末に対する使用状況が「いいえ」であり、使用没入強度が「悪い」の場合のように、受信者端末に対しても送信至急性が低く、内容没入度も低い場合であってよい。
【0136】
段階１１１０において、メッセンジャーサーバ３３０は、イベントを第２種類のデータとして受信者端末に送信することができる。送信者端末は、図８の段階８１０のように、マルチメディアメッセージの送信要求をメッセンジャーサーバ３３０に既に送信しているため、このようなイベントを送信者端末から受信する必要がない。一方、メッセンジャーサーバ３３０は、送信者からマルチメディアメッセージの送信が要求されたことに対する通知イベントだけを受信者端末に送信してよい。
【0137】
段階１１２０において、メッセンジャーサーバ３３０は、受信者端末にインストールされたメッセンジャーアプリケーションを通じてイベントが表示されることを認識してよい。このようなイベントの表示の認識は、受信者が受信者端末を使用中であることを意味してよく、受信者側の内容没入度が高くなることのように状況が変化したことを意味してよい。
【0138】
段階１１３０において、メッセンジャーサーバ３３０は、認識に応答し、送信者端末から第１種類のデータとして、原本マルチメディアデータに対するプレビューおよび原本マルチメディアデータのうちのいずれか１つのデータを受信することができる。
【0139】
段階１１４０において、メッセンジャーサーバ３３０は、イベントの表示が認識されて状況が変わることに伴い、プレビューおよび原本マルチメディアデータのうちのいずれか１つのデータを、変更された第２種類のデータとして受信者端末に送信してよい。このとき、メッセンジャーサーバ３３０は、送信者端末からプレビューを受信して受信者端末に送信した場合、受信者端末からプレビューを基盤とした原本要求が受信され、状況が追って変わることに伴い、送信者端末から変更された第１種類のデータとして原本マルチメディアデータを受信してよく、受信した原本マルチメディアデータを変更された第２種類のデータとして受信者端末に追って送信してよい。
【0140】
すなわち、メッセンジャーサーバ３３０は、受信者側の内容没入度が高くなることに伴い、プレビューまたは原本マルチメディアデータのうちのいずれか１つを送信者端末から受信して受信者端末に送信してよい。このとき、送信至急性は低いため、メッセンジャーサーバ３３０は、可能な場合、プレビューを先に受信者端末に送信した後、受信者からの明示的な要求に応じて原本マルチメディアデータを受信者端末に提供してよい。
【0141】
このように、本発明の実施形態によると、メッセンジャーサーバ３３０は、ユーザの多様な状況に応じて効率的にマルチメディアメッセージを伝達することができる。
【0142】
図１２は、本発明の一実施形態における、受信者端末に送信されるデータの重複送信防止のための例を示したフローチャートである。図１２の段階１２１０～段階１２３０は、上述した段階８４０に含まれて実行されてよく、実質的に、図８の段階８１０～段階８４０とは並列的に、メッセンジャーサーバ３３０が受信者端末にデータを送信する場合ごとに実行されてよい。
【0143】
段階１２１０において、メッセンジャーサーバ３３０は、受信者端末に送信済みのデータに対する送信履歴を管理することができる。例えば、メッセンジャーサーバ３３０は、受信者端末に送信されたデータの種類や識別子、時間などの履歴を管理してよい。
【0144】
段階１２２０において、メッセンジャーサーバ３３０は、管理される送信履歴に基づき、第２種類のデータが受信者端末に送信された履歴が存在するかを確認し、および段階１２３０において、メッセンジャーサーバ３３０は、第２種類のデータが受信者端末に送信された履歴が存在する場合、第２種類のデータの識別子または第２種類のデータを送信するのに利用されたメッセージの識別子を、受信者端末に送信することができる。このとき、受信者端末では、データの識別子またはメッセージの識別子により、予め送信されて受信者端末に記録されたデータが識別されてよい。したがって、メッセンジャーサーバ３３０は、第２種類のデータが受信者端末に重複送信されることを防ぐことができる。第２種類のデータが受信者端末に記録されていない場合には、メッセンジャーサーバ３３０が、受信者端末からの要求に応じて第２種類のデータを受信者端末に送信してよい。このようなデータの重複送信防止の例については、図６および図７を参照しながら詳しく説明したとおりである。
【0145】
図１３は、本発明の一実施形態における、送信者端末のマルチメディアメッセージ提供方法の例を示したフローチャートである。本実施形態に係るマルチメディアメッセージ提供方法は、一例として、上述した送信者端末３１０を実現するコンピュータ装置２００によって実行されてよい。例えば、コンピュータ装置２００のプロセッサ２２０は、メモリ２１０が含むオペレーティングシステムのコードと少なくとも１つのプログラムのコードとによる制御命令（ｉｎｓｔｒｕｃｔｉｏｎ）を実行するように実現されてよい。ここで、プロセッサ２２０は、コンピュータ装置２００に記録されたコードが提供する制御命令に従ってコンピュータ装置２００が図１３のマルチメディアメッセージ提供方法に含まれる段階１３１０～段階１３３０を実行するようにコンピュータ装置２００を制御してよい。図１３では、送信者端末３１０が段階１３１０～段階１３３０を実行する過程について説明する。
【0146】
段階１３１０において、送信者端末３１０は、受信者端末へのマルチメディアメッセージの送信要求をメッセンジャーサーバに送信することができる。ここで、メッセンジャーサーバは、上述したメッセンジャーサーバ３３０に対応してよい。上述したように、一般的なメッセンジャーサービスでは、送信者側が原本マルチメディアデータを含むマルチメディアメッセージを直ぐにメッセンジャーサーバ３３０に送信することに過ぎない。この反面、本実施形態では、送信者端末３１０での原本マルチメディアデータの送信方式がメッセンジャーサーバによって決定されるため、原本マルチメディアデータの送信に先立ち、このようなマルチメディアメッセージの送信に対する要求をメッセンジャーサーバが受信してよい。
【0147】
段階１３２０において、送信者端末３１０は、メッセンジャーサーバに状況情報を送信することができる。一例として、送信された状況情報は、送信者端末３１０のネットワーク状況に関する情報を含んでよい。
【0148】
段階１３３０において、送信者端末３１０は、送信された状況情報および受信者端末から受信した状況情報を分析して、メッセンジャーサーバによって決定される状況に応じて、メッセンジャーサーバが要求するマルチメディアメッセージに含まれる原本マルチメディアデータについての第１種類のデータを、メッセンジャーサーバに送信することができる。ここで、受信者端末から受信した状況情報は、受信者端末のネットワーク状況、受信者が受信者端末を使用中であるか否か、アクセス可能性、使用没入強度、受信者の明示的な入力に応じて受信者端末から受信される原本要求のうちの少なくとも１つに関する情報を含んでよい。一方、第１種類のデータは、原本マルチメディアデータおよび原本マルチメディアデータに対するプレビューのうちのいずれか１つを含んでよく、メッセンジャーサーバから、状況に応じてマルチメディアメッセージの送信に対するイベント、原本マルチメディアデータ、および原本マルチメディアデータに対するプレビューのうちのいずれか１つとして決定される第２種類のデータが、受信者端末に送信されてよい。このとき、メッセンジャーサーバで決定される少なくとも１つの状況において、第１種類のデータと第２種類のデータは、互いに異なるデータとして決定されてよい。
【0149】
一方、上述したように、送信された状況情報および受信者端末から受信した状況情報のうちのいずれか一方が時間とともに変化することに伴ってメッセンジャーサーバで決定される状況が変わる場合、変わった状況に応じて第１種類のデータが変更されてよい。この場合、送信者端末３１０は、変更された第１種類のデータをメッセンジャーサーバにさらに送信してよい。
【0150】
また、送信者端末３１０は、データの重複送信を防ぐために、メッセンジャーサーバに送信したデータに対する送信履歴を管理してよい。このとき、送信者端末３１０は、管理される送信履歴から、第１種類のデータがメッセンジャーサーバに送信された履歴が存在するかを確認してよく、第１種類のデータがメッセンジャーサーバに送信された履歴が存在する場合、第１種類のデータの識別子または第１種類のデータを送信するのに利用されたメッセージの識別子をメッセンジャーサーバに送信してよい。この場合、メッセンジャーサーバでデータの識別子またはメッセージの識別子により、予め送信されてメッセンジャーサーバに記録されたデータが識別されることにより、第１種類のデータに対する重複送信を防ぐことができる。
【0151】
図１３で省略された内容は、上述した内容を参照することができる。
【0152】
以上のように、本発明の実施形態によると、メッセンジャーサービスでメッセージの送信者と受信者それぞれの状況（ｃｏｎｔｅｘｔ）に合わせてマルチメディアメッセージを効率的に送信、受信、および／または表示することができる。
【0153】
上述したシステムまたは装置は、ハードウェア構成要素、ソフトウェア構成要素、またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ、マイクロコンピュータ、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特殊目的コンピュータを利用して実現されてよい。処理装置は、オペレーティングシステム（ＯＳ）およびＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを記録、操作、処理、および生成してもよい。理解の便宜のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者は、処理装置が複数個の処理要素および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数個のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでよい。また、並列プロセッサのような、他の処理構成も可能である。
【0154】
ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、思うままに動作するように処理装置を構成したり、独立的または集合的に処理装置に命令したりしてよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供したりするために、いかなる種類の機械、コンポーネント、物理装置、仮想装置、コンピュータ記録媒体または装置に具現化されてよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された状態で記録されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータ読み取り可能な記録媒体に記録されてよい。
【0155】
実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータ読み取り可能な媒体に記録されてよい。コンピュータ読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独でまたは組み合わせて含んでよい。媒体に記録されるプログラム命令は、実施形態のために特別に設計されたものであっても、コンピュータソフトウェアの当業者に公知されて使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例には、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープのような磁気媒体、ＣＤ－ＲＯＭおよびＤＶＤのような光媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどを含んで実行するように特別に構成されたハードウェア装置が含まれる。このような記録媒体は、単一または複数のハードウェアが結合された形態の多様な記録手段または格納手段であってよく、あるコンピュータシステムに直接接続される媒体に限定されることはなく、ネットワーク上に分散存在するものであってもよい。プログラム命令の例には、コンパイラによって生成されるもののような機械語コードだけでなく、インタプリタなどを使用してコンピュータによって実行され得る高級言語コードを含む。
【0156】
以上のように、実施形態を、限定された実施形態および図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能であろう。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、かつ／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって代替されたり置換されたとしても、適切な結果を達成することができる。
【0157】
したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。
【符号の説明】
【0158】
３１０：送信者端末
３２０：受信者端末
３３０：メッセンジャーサーバ
３２０：受信者端末
３３０：メッセンジャーサーバ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
