JP2021140578A - サーバのプログラム、情報処理方法、サーバ - Google Patents

Abstract

【課題】ユーザの端末の利用期間に応じた広告情報を送信することができるサーバのプログラムを提供することを目的とする。【解決手段】端末と通信するサーバによって実行されるプログラムであって、端末のアプリケーションによって取得された端末情報をサーバの通信部によって受信することと、端末情報に基づく、端末のユーザの利用期間に関する情報に基づいて、広告に関する広告情報を通信部によって端末に送信することとがサーバによって実行される。【選択図】図１

Description

本開示は、サーバのプログラム、情報処理方法、並びにサーバに関する。

従来、様々な工夫を凝らして宣伝効果の高い広告情報をユーザの端末に送信することが行われてきた。特許文献１には、ユーザの端末の機種に応じた情報を送信することが開示されている。

特開２００２−２５９２９４号公報

本発明の第一の態様は、端末と通信するサーバによって実行されるプログラムであって、端末のアプリケーションによって取得された端末情報をサーバの通信部によって受信することと、端末情報に基づく、端末のユーザの利用期間に関する情報に基づいて、広告に関する広告情報を通信部によって端末に送信することとがサーバによって実行される。
本発明の第二の態様は、端末と通信するサーバの情報処理方法であって、端末のアプリケーションによって取得された端末情報をサーバの通信部によって受信することと、端末情報に基づく、端末のユーザの利用期間に関する情報に基づいて、広告に関する広告情報を通信部によって端末に送信することとを含む。
本発明の第三の態様は、端末と通信するサーバであって、端末のアプリケーションによって取得された端末情報を受信する通信部と、端末情報に基づく、端末のユーザの利用期間に関する情報に基づいて、広告に関する広告情報を通信部によって端末に送信する制御を行う制御部とを備える。
本発明の第四の態様は、端末と通信するサーバであって、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサーを備え、プロセッサーは、端末のアプリケーションによって取得された端末情報をサーバの通信部によって受信することと、端末情報に基づく、端末のユーザの利用期間に関する情報に基づいて、広告に関する広告情報を通信部によって端末に送信することとを実行する。

通信システムの構成例を示し、端末及びサーバの構成例を示すブロック図である。 実施形態に係る通信システムの概要を説明する概要図である。 ユーザ情報のデータ構成例を示すデータ概念図である。 ユーザのメッセージングアプリケーションの利用履歴を示す利用履歴情報のデータ構成例を示すデータ概念図である。 通信システムにおける各装置のやり取りの一例を示すシーケンス図である。 図５に関連する端末の動作例を示すフローチャートである。 図５に関連するサーバの動作例を示すフローチャートである。 通信システムにおける各装置のやり取りの一例を示すシーケンス図である。 図８に関連するサーバの動作例を示すフローチャートである。 図８に関連する端末の動作例を示すフローチャートである。 （ａ）は、学習モデルの教師データのデータ概念図である。（ｂ）は、推定による解答の例を示すデータ概念図である。 サーバの学習処理を示すフローチャートである。 サーバの推定処理を示すフローチャートである。 （ａ）は、学習モデルの教師データの他の例を示すデータ概念図である。（ｂ）は、推定による解答の例を示すデータ概念図である。 キャリアごとの契約期間を示す契約期間情報のデータ概念図である。 利用期間情報を利用した広告の配信を行うサーバの動作例を示すフローチャートである。 広告の配信に係る通信システムの各装置間のやり取りの例を示すシーケンス図である。 端末の広告の表示例を示す画面図である。

＜法的事項の遵守＞
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。

本開示に係る端末による送信または受信に係る状況を確認できる表示方法等を実施するための実施形態について、図面を参照して説明する。

＜システム構成＞

図１は、本開示の一実施形態に係る通信システム１の構成を示す。図１に開示されるように、通信システム１では、ネットワーク３０を介してサーバ１０と、端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ）とが接続される。サーバ１０は、ネットワーク３０を介してユーザが所有する端末２０に、端末２０間でのメッセージの送受信を実現するサービスを提供する。なお、ネットワーク３０に接続される端末２０の数は限定されない。

ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０とを接続する役割を担う。すなわち、ネットワーク３０は、端末２０がサーバ１０に接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。

ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定でなく例として、アドホック・ネットワーク（ad hoc network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（virtual private network：ＶＰＮ）、ローカル・エリア・ネットワーク（local area network：ＬＡＮ）、ワイヤレスＬＡＮ（wireless LAN：ＷＬＡＮ）、広域ネットワーク（wide area network：ＷＡＮ）、ワイヤレスＷＡＮ（wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（metropolitan area network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮ（integrated service digital networks）、無線ＬＡＮ、ＬＴＥ（long term evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。

端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ）は、各実施形態において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ（personal digital assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末２０は情報処理端末と表現されてもよい。

端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は基本的には同一であるため、以下の説明においては、端末２０について説明する。また、必要に応じて、ユーザXが利用する端末を端末２０Xと表現し、ユーザXまたは端末２０Xに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Xと表現する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。

サーバ１０は、端末２０に対して、所定のサービスを提供する機能を備える。サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１０は、限定でなく例として、サーバ装置、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ１０は情報処理装置と表現されてもよい。サーバ１０と端末２０とを区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。

＜ハードウェア（HW）構成＞

図１を用いて、通信システム１に含まれる各装置のHW構成について説明する。

（１）端末のHW構成

端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、表示部２４、位置情報取得部２５を備える。端末２０のHWの各構成要素は、限定でなく例として、バスBを介して相互に接続される。なお、端末２０のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、マイク２３２、カメラ２３４、位置情報取得部２５等、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。

通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

入出力部２３は、端末２０に対する各種操作を入力する装置、および、端末２０で処理された処理結果を出力する装置を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。

入力部は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定でなく例として、タッチパネル２３１、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ２３４（動画像を介した操作入力）、マイク２３２（音声による操作入力）を含む。

出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定でなく例として、 タッチパネル、タッチディスプレイ、スピーカ２３３（音声出力）、レンズ（限定でなく例として３D（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。

表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定でなく例として、タッチパネル、タッチディスプレイ、モニタ（限定でなく例として、液晶ディスプレイやOELD（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Dで表示データを表示可能であってもよいし、そうでなくてもよい。

入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。

制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

制御部２１は、限定でなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。

記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定でなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。

端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。

マイク２３２は、音声データの入力に利用される。スピーカ２３３は、音声データの出力に利用される。カメラ２３４は、動画像データの取得に利用される。

（２）サーバのHW構成

サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、表示部１３を備える。サーバ１０のHWの各構成要素は、限定でなく例として、バスBを介して相互に接続される。なお、サーバ１０のHWは、サーバ１０のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のHWは、表示部１３を取り外すような構成であってもよいし、そうでなくてもよい。

制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。

制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。

記憶部１５は、サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ(memory)と表現されてもよいし、されなくてもよい。

通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０に送信する。また、通信Ｉ／Ｆ１４は、端末２０から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

入出力部１２は、サーバ１０に対する各種操作を入力する装置により実現される。入出力部１２は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部１２は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部１２、限定でなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部１２は、これらに限定されない。

表示部１３は、代表的にはモニタ（限定でなく例として、液晶ディスプレイやOELD（organic electroluminescence display））で実現される。なお、表示部１３は、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらの表示部１３は、３Dで表示データを表示可能であってもよいし、そうでなくてもよい。ただし、本開示において、表示部１３は、これらに限定されない。

サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。

本開示の各実施形態においては、端末２０および／または、サーバ１０のＣＰＵがプログラムPを実行することにより、実現するものとして説明する。

なお、端末２０の制御部２１、および／または、サーバ１０の制御部１１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

また、本開示の各実施形態のプログラムP(限定ではなく、例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムPを記憶可能である。また、プログラムPは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムPとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。

記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定でなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。

サーバ１０および／または端末２０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。

また、本開示のプログラムＰＤＤは、当該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。サーバ１０および／または端末２０は、限定でなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。

また、本開示の各実施形態は、プログラムPが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。

端末２０における処理の少なくとも一部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。

サーバ１０における処理の少なくとも一部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。

明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。

なお、本開示のプログラムは、限定でなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのオブジェクト指向プログラミング言語、HTML5などのマークアップ言語などを用いて実装される。

＜実施形態＞
本実施形態に係るサーバ１０は、ユーザが端末の機種変更を行いそうなタイミングや通信の契約の態様（以下、契約態様と記載する）を変更するタイミングを推定し、そのタイミングに効果的な広告情報を送信することで、広告としての宣伝効果を向上させる。

ここで端末の機種変更とは、通信事業者を変更することなく端末を新たな端末に変更すること、通信事業者を変更したうえで端末を新たな端末に変更することを含む。

また、契約態様を変更するとは、ユーザが利用している通信事業者そのものを変更すること、通信事業者を変更せずに通信事業者と契約している通信プランを変更することを含む。

通信事業者とは、一般的にキャリアと呼称される、電話通信やメッセージ等の通信サービスを提供する電気通信事業者、および、仮想移動体通信事業者（ＭＶＮＯ：Mobile Virtual Network Operator）と呼称される、無線通信回線設備を開設・運用せずに移動体通信サービスを行う事業者を含む。

図２を用いて、サーバ１０によるユーザの端末の機種変更を行いそうなタイミングの推定例を説明する。なお、ここでは、機種変更を行いそうなタイミングとしているが、これは、上述の通り、契約態様の変更を行いそうなタイミングであってもよいし、そうでなくてもよい。

図２に示すように、ユーザ４０は、自身の端末２０に、２０１７年２月８日に、メッセージングアプリケーションをインストールする。メッセージングアプリケーションは、サーバ１０を介して、複数のユーザ間でコンテンツのやり取りを行うための通信ツールであり、各ユーザ間のコンテンツのやり取りは、トークルームで行われる。

コンテンツとは、メッセージングアプリケーション上でトークルームを介してユーザによりやり取りされるデータのことであり、ユーザが自身の端末２０を利用して入力した文字情報（テキストデータ）、写真やスタンプなどを含む画像情報（例えば、ユーザがいる場所の写真）、音声ファイル、動画ファイル、データファイルなど各種のファイル情報、広告情報を含むが、これらに限定するものではない。

トークルームとは、限定ではなく一例として、サーバ１０が提供するメッセージングサービスにおいて、メッセージングサービスを利用するユーザ同士によって、送受信されたコンテンツをユーザの端末に表示可能にするユーザインターフェースである。トークルームは、チャットルームと呼称されてもよい。

メッセージングアプリケーションがインストールされてから、期間Ｔ１をあけて、２０１７年１１月２０に、ユーザ４０は、端末２０の機種変更を行って、メッセージングアプリケーションのアカウントの引継ぎを行う。

アカウントの引継ぎとは、新たな端末で、以前と同じアカウントでメッセージングアプリケーションを利用できるようにするための設定である。そして、期間Ｔ２が経過した２０１８年９月１４日に、ユーザ４０は、再度、機種変更とメッセージングアプリケーションのアカウントの引継ぎを行う。サーバ１０は、端末２０からメッセージングアプリケーションを利用している（実行している）ことを示す利用情報を適宜受信する。ここでいう利用情報は、ユーザを特定可能な情報と、ユーザが利用している端末の機種情報とが含まれてもよいし、そうでなくてもよい。したがって、サーバ１０は、日々サーバ１０に送信される利用情報の履歴をとっておくことで、受信した利用情報に含まれる機種情報の変化を確認することで機種変更を行ったタイミングを推定できる。なお、契約態様の変更のタイミングを推定する場合には、利用情報には、機種情報に代えて（あるいは、機種情報に加えて）、通信事業者の情報や契約プランの情報が含まれてもよいし、そうでなくてもよい。

そして、サーバ１０は、ユーザが現在同一の機種を利用している利用期間Ｔ３から機種変更を行う可能性が高いかを推定する。限定ではなく一例として、サーバ１０は、期間Ｔ１と期間Ｔ２とから、現在ユーザ４０が機種変更を行う可能性が高いか、あるいは、期間Ｔ３を推定し、機種変更を行う可能性が高い場合に、広告情報を送信する。

広告情報とは、企業、店舗あるいは人物などを紹介、宣伝し、情報伝達を行うものをいう。広告情報は、上述したメッセージ、スタンプ、動画、静止画等であってもよいし、そうでなくてもよい。広告を行う広告主は、サーバ１０であってもよいし、サーバ１０以外の企業や店舗、人物であってもよい。また、この広告は、機種変更に関連する情報であってよい。本実施形態の場合、特に、機種変更に関連する広告であると、広告として高い宣伝効果が見込める。限定ではなく一例として、端末の新機種を紹介する広告が挙げられる。

以下、ユーザが機種変更を行う可能性が高いかどうかの推定処理と広告情報の送信について詳細に説明する。なお、本実施形態においては、ユーザが機種変更を行う可能性が高いかをどうかを推定する場合について詳述する。契約態様を変更する可能性が高いかどうかを推定する手法については、代替として必要となる情報、処理について適宜説明する。

（１）ユーザの端末の機能構成
図１に示すように、端末２０の制御部２１は、メッセージ処理部２１１と、表示処理部２１２と、を備える。

メッセージ処理部２１１は、サーバ１０が提供するメッセージングサービスから提供されるメッセージングアプリケーションに従って、ユーザからの入力および／または通信Ｉ／Ｆ１２が受信したメッセージを含むコンテンツの入力を受け付けて、表示処理部２１２に表示するように指示する。なお、ユーザからの入力を受け付けた場合には、その受け付けた入力内容を通信Ｉ／Ｆ２２にサーバ１０に宛てて送信するように指示する。また、ここでメッセージ処理部２１１が処理する対象として、トークルームに対してユーザが入力したテキストメッセージに限らず、写真やスタンプなどを含む画像情報、音声ファイル、動画ファイル、データファイルなどを含んでよい。また、メッセージ処理部２１１は、メッセージングアプリケーションの一日の中での最初の起動時に、通信Ｉ／Ｆ２２を介して、サーバ１０にメッセージングアプリケーションを利用していることを示す利用情報を送信する。利用情報は、少なくともユーザＩＤと、端末２０の機種情報とを含む。なお、ここでいう最初の起動時は、メッセージングアプリケーションを実行すること、並びに、実行されていてスリープ状態のメッセージングアプリケーションを表示することの、双方の場合を含む。なお、契約態様の変更の可能性が高いかどうかを推定する場合には、利用情報には、端末２０の機種情報に代えて（あるいは、加えて）、ユーザが契約している通信事業者の情報や契約している通信プランを識別する通信プラン情報が含まれる。

表示処理部２１２は、サーバ１０が提供するメッセージングサービスから提供されるメッセージングアプリケーションに従って、ユーザからの入力および／または通信Ｉ／Ｆ１２が受信したメッセージを含むコンテンツの入力を受け付けて、表示部２４の表示領域に表示するように指示する。なお、ユーザからの入力を受け付けた場合には、その受け付けた入力内容を通信Ｉ／Ｆ２２にサーバ１０に宛てて送信するように指示する。表示処理部２１２は、サーバ１０からの指示に従って、トークルームに表示する各メッセージについて、指定された表示態様、または、メッセージを送信した端末の場所に基づく表示態様でメッセージ（コンテンツ）を表示することとしてもよいし、そうしなくてもよい。表示処理部２１２は、広告情報を表示する。
以上が、端末２０の機能構成である。

（２）サーバの機能構成
図１に示すように、サーバ１０の制御部１１は、メッセージ処理部１１１と、登録部１１２と、推定部１１３と、広告送信部１１４と、を備える。また、制御部１１は、学習部１１５を備えていてもよい。

メッセージ処理部１１１は、各ユーザ間のやり取りを行うためのトークルームを管理する機能を備える。メッセージ処理部１１１は、サーバ１０が提供するメッセージングサービスの提供を受ける端末間のコンテンツを含むコンテンツのやり取りを中継する。即ち、あるユーザからトークルームへのコンテンツが送信された場合に、そのトークルームを特定し、トークルームに属する他のユーザにコンテンツを送信する。

登録部１１２は、ユーザが端末にメッセージングアプリケーションをインストールした際に、ユーザの端末から送信されるユーザ自身の情報を、記憶部１５に登録する。

推定部１１３は、ユーザが端末を利用している利用期間を特定可能な利用履歴情報４００を参照して、ユーザが機種変更を行うタイミングかどうかを推定する。推定部１１３による推定は、現在機種変更を行う可能性があるかどうかを推定するものであってもよいし、次にいつ機種変更を行う可能性がある日時を推定するものであってもよい。また、推定部１１３は、ユーザが、利用している端末の通信の契約情報を含む利用履歴情報を参照して、契約態様を変更するタイミングかどうかを推定する。

広告送信部１１４は、推定部１１３による推定に基づき、機種変更を行う可能性があるユーザの端末に、広告を送信する。

学習部１１５は、少なくともユーザが同じ機種の端末を利用している利用期間を含むユーザの属性を示す情報と、そのユーザが機種変更を行ったかどうか、又は、契約態様を変更したかどうかを示すコンバージョン情報とが対応付けられた情報を教師データとして学習を行い、ユーザの同じ機種の利用期間又は同じ契約態様の利用期間とコンバージョンとの関係を示す学習モデルを生成する。学習のアルゴリズムは既存のアルゴリズムを利用してよい。また、学習部１１５は、所定のタイミング（限定ではなく一例として、所定数の教師データとなる利用履歴情報が蓄積されたタイミングであってもよいし、予め定められた期間毎（限定ではなく一例として３ヶ月毎）で適宜、記憶部１５に記憶されている学習モデルを更新することとしてもよい。メッセージングアプリケーションの利用履歴の情報は、日を追うごとに蓄積されていくので、より多くの教師データの元となるデータが蓄積されることになる。したがって、その追加された履歴データを利用して、学習モデルの更新を行うこととしてもよい。

なお、図示はしていないが、サーバ１０の記憶部１５は、後述するユーザ情報３００や利用履歴情報４００を記憶している。また、記憶部１５は、学習部１１５あるいは他の装置により生成されたユーザが機種変更を行うかどうかを推定するために用いる学習モデルを記憶していてもよい。

＜データ＞
図３は、ユーザ情報３００の構成例を示すデータ概念図である。ユーザ情報３００は、メッセージングアプリケーションを利用している各ユーザに関する情報であり、各ユーザに関するものであって、サーバ１０が収集可能な情報であれば、どのような情報が含まれてもよい。

図３に示すように、ユーザ情報３００は、ユーザＩＤ３０１と、ユーザ名３０２と、機種情報３０３と、契約情報３０４と、年代３０５と、性別３０６と、エリア３０７と、嗜好３０８とが対応付けられた情報である。ユーザ情報３００に含まれる各情報は、ユーザがメッセージングアプリケーションをダウンロードする際にユーザにより登録される情報であってもよいし、ユーザがメッセージングアプリケーションを使用する上でサーバ１０が取得できる情報であってもよい。

ユーザＩＤ３０１は、通信システム１上で各ユーザを一意に識別するための識別情報である。

ユーザ名３０２は、ユーザＩＤ３０１に対応するユーザの名称を示す情報である。ユーザ名３０２は、本名であってもよいし、本名ではなく、便宜上の呼称、即ち、ニックネームやハンドルネームであってもよい。

機種情報３０３は、ユーザＩＤ３０１に対応するユーザが保持する端末の機種を示す情報であって、ユーザがメッセージングアプリケーションをインストールした端末の機種を示す情報である。機種情報３０３は、ユーザがメッセージングアプリケーションをインストールし、そのメッセージングアプリケーションが起動されて、情報がユーザの端末２０からサーバ１０に送信されることで取得することができる。なお、機種情報３０３に代えて、各端末固有の端末ＩＤ（シリアルナンバー）を用いることとしてもよい。

契約情報３０４は、ユーザＩＤ３０１に対応するユーザが保持する端末を利用して通信を行うために契約している通信事業者を示す情報である。通信事業者は、電気通事業者及び仮想移動体通信事業者を含む。また、契約情報３０４は、更に、契約しているプランを示す情報も含まれてもよいし、含まなくともよい。

年代３０５は、ユーザＩＤ３０１に対応するユーザの年齢が含まれる年代を示す情報である。年代３０５は、ユーザにより入力される情報であってよく、ユーザの年代ではなく、ユーザの正確な年齢を示す情報であってもよい。また、あるいは、年代３０５は、ユーザの生年月日で代替されてもよい。

性別３０６は、ユーザＩＤ３０１に対応するユーザの性別を示す情報である。性別３０６は、ユーザにより入力される情報である。

エリア３０７は、ユーザＩＤ３０１に対応するユーザが高頻度で滞在している地域を示す情報である。図３では、一例として都道府県を示しているが、これは都道府県の単位である必要はなく市町村の単位であってもよいし、逆に、関東、東北などの地方を示す情報であってもよい。また、あるいは、地図の経緯度の範囲で示されるセグメントの情報であってもよい。エリア３０７は、ユーザが起動したメッセージングアプリケーションの機能として保持されユーザからの許可がある場合に実行が許容される位置情報取得機能により取得された位置情報から特定することができる。

嗜好３０８は、ユーザＩＤ３０１に対応するユーザの嗜好、趣味、関心を示すものを示す情報である。嗜好３０８は、ユーザにより入力されてもよいし、ユーザがアクセスしたニュースやウェブサイトなどから特定されてもよい。

図３の例で言えば、ユーザＩＤ３０１が「Ｕ００９２８０１」のユーザは、ユーザ名が、「Ａ山Ａ夫」であり、使用している端末の機種は、「kphone」であり、契約している通信事業者は、「Ａ社」であり、年代は「３５〜３９」であり、性別は「男」であり、よくいるエリアは「東京」であり、嗜好の情報として、「株、金融、切手、…」が対応付けられている。

なお、図３には、図示していないが、ユーザ情報３００には、その他のユーザに関連する情報が含まれてもよい。また、サーバ１０によるメッセージングアプリケーションの運用上必須ではない情報、限定ではなく一例として年代３０５や性別３０６などの情報は含まれていなくてもよい。

図４は、ユーザがメッセージングアプリケーションを利用している日時であって、どの機種の端末を利用してメッセージングアプリケーションを運用しているかを示す利用履歴情報４００の構成例を示すデータ概念図である。図４に示すように利用履歴情報４００は、ユーザＩＤ４０１と、機種情報４０２と、利用日時４０３とが対応付けられた情報である。

ユーザＩＤ４０１は、通信システム１上で各ユーザを一意に識別するための識別情報であり、図３に示すユーザＩＤ３０１と同じ内容の情報である。

機種情報４０２は、ユーザＩＤ４０１に対応するユーザが保持する端末の機種を示す情報であって、図３に示す機種情報３０３と同じ内容の情報である。

利用日時４０３は、ユーザＩＤ４０１で示されるユーザが、対応する機種情報４０２で示される端末を利用して、メッセージングアプリケーションを利用した日時を示す情報である。メッセージングアプリケーションは、一日の最初にメッセージングアプリケーションを開いたとき（起動したとき、複数のアプリを並列起動しておいたものの中からメッセージングアプリケーションを選択して表示したとき）に、メッセージングアプリケーションが開かれたことを示す情報を、ユーザが利用している端末の機種を示す機種情報とともに送信されたものを取得することで得られる。

利用履歴情報４００があることにより、ユーザがいつからいつまで同じ機種を利用していたかを特定することができる。図４に示す例で言えば、ユーザＩＤ４０１が「Ｕ００９２８０１」で示されるユーザは、メッセージングアプリケーションを「２０１７／２／８」から利用しており、そのとき利用していた端末は「kphone」である。図４の、同ユーザの利用履歴情報によれば、「２０１７／１１／１９」から「２０１７／１１／２０」の間で、機種情報が「kphone」から「Galactic 8」に変化をしており、メッセージングアプリケーションを使用している端末が変更されたことが理解できる。したがって、このユーザがこのタイミングで、機種変更を行ったと理解できる。また同様に、「２０１８／９／１６」から「２０１８／９／１７」の間で、機種情報が「Galactic 8」から「Galactic 9」に変化していることから、ここでも機種変更を行ったと理解できる。よって、同ユーザは、メッセージングアプリケーションを利用し始めてから、約９ヶ月で最初の機種変更を行い、その約９か月後に再度機種変更を行っていることになる。また、このユーザが、「Galactic 9」に機種を変更してから、更なる機種の変更を行っていない場合には、現在日時から、「Galactic 9」に切り替えた日付けの「２０１８／９／１７」を減じることで、「Galactic 9」の利用期間を算出することができる。

なお、図４に示す利用履歴情報４００の利用日時４０３は、図３に示すユーザ情報３００に含まれてもよい。即ち、ユーザ情報３００と利用履歴情報４００とは一つのデータベースとして構成されてもよい。また、契約態様の変更の可能性を推定する場合には、利用履歴情報４００は、機種情報４０２に代えて、契約情報を保持した利用履歴情報を用いてもよいし、そうでなくてもよい。契約情報は、図３に示す契約情報３０４と同様の情報であり、利用情報に含まれる情報であってもよいし、そうでなくてもよい。契約情報について内容の変化があった場合に、通信事業者の変更あるいは通信プランの変更が行われたと推定することができる。

＜動作＞
まず、ユーザが機種変更を行うかどうかを判定するための判断材料となる情報の収集のための処理について、図５〜図７を用いて説明する。図５は、通信システム１における端末２０とサーバ１０との間のやり取りの例を示すシーケンス図である。図５に示すやり取りは、ユーザが端末２０を利用してメッセージングアプリケーションをインストールする際のやり取りを示している。なお、メッセージングアプリ―ションをすでにインストールしている端末２０であれば、以下のステップＳ５０１〜Ｓ５０３の処理は不要であり、省略してもよいし、しなくてもよい。

図５に示すように、端末２０は、ユーザの指示に基づき、メッセージアプリケーションのインストーラを要求する要求情報をサーバ１０に送信する（ステップＳ５０１）。

サーバ１０は、端末２０からのメッセージングアプリケーションのインストーラの要求を受け付けて、当該インストーラを、端末２０に送信する（ステップＳ５０２）。

端末２０は、サーバ１０からメッセージングアプリケーションのインストーラを受信すると、ユーザの指示にしたがって、メッセージングアプリケーションのインストールを実行する（ステップＳ５０３）。

端末２０は、メッセージングアプリケーションを起動し、ユーザに関する情報を含むユーザ情報をサーバ１０に送信する（ステップＳ５０４）。なお、ユーザ情報の送信は、メッセージングアプリケーションをインストールする際のユーザ登録のタイミングで行われてもよいし、行われなくてもよい。

サーバ１０は、端末２０から受信したユーザの情報を、ユーザ情報３００に登録する（ステップＳ５０５）。そして、サーバ１０は、ユーザがメッセージングアプリケーションの利用を開始したことを示す情報として、現在日時の情報とユーザの端末の機種情報とを、利用期間情報に登録する（ステップＳ５０６）。

端末２０は、日付が変更されるごとに、メッセージングアプリケーションを起動したタイミングで、利用情報をサーバ１０に送信する（ステップＳ５０７）。

サーバ１０は、端末２０から利用情報を受信すると、利用履歴情報４００に、利用情報で示される機種情報と、利用情報を受信した受信日時を利用日時４０３として、登録し、利用履歴情報４００を更新する（ステップＳ５０８）。このように、ユーザがメッセージングアプリケーションを利用することで、ユーザが利用している機種の利用期間を示す情報の代替として、利用履歴情報４００を作成、更新することができる。

図６は、図５に示すやり取りを実現するための端末２０の動作例を示すフローチャートである。なお、上述と同様に、メッセージングアプリ―ションをすでにインストールしている端末２０であれば、以下のステップＳ６０１、Ｓ６０２の処理は不要であり、省略してもよいし、しなくてもよい。

図６に示すように、端末２０は、入出力部２３に対するユーザからの入力にしたがって、メッセージングアプリケーションのインストーラを要求するための要求情報と、通信Ｉ／Ｆ２２を介して、サーバ１０に送信する（ステップＳ６０１）。この要求情報に応じて、サーバ１０からは、メッセージングアプリケーションのインストーラを送信される。

端末２０の通信Ｉ／Ｆ２２は、サーバ１０から送信されたメッセージングアプリケーションのインストーラを受信し、制御部１２１に送信する。制御部２１は、ユーザからの入出力部２３に対する入力に従って、メッセージングアプリケーションのインストーラを実行する（ステップＳ６０２）。

端末２０は、通信Ｉ／Ｆ２２を介して、サーバ１０にユーザに関するユーザ情報を送信する（ステップＳ６０３）。このユーザ情報の送信は、前述の通り、ユーザがメッセージングアプリケーションを使用するためにサーバ１０に対してユーザ登録をすることによる送信であってもよいし、メッセージングアプリケーションの最初の起動時の送信であってもよい。このユーザ情報には、メッセージングアプリケーションでユーザが利用する名前及びユーザの端末２０の機種情報を含む。ユーザ情報には、その他に、ユーザの属性として、ユーザの年齢や性別、嗜好などの情報が含まれてもよいし、含まれなくてもよい。

制御部１１は、メッセージングアプリケーションを実行したか否かを判定する（ステップＳ６０４）。ここでいう実行とは、メッセージングアプリケーションが起動されていない状態から起動すること、元々起動されていたメッセージングアプリケーションを表示状態にすることとの両方の場合を含む。メッセージングアプリケーションを実行していない場合は（ステップＳ６０４のＮＯ）、メッセージングアプリケーションが実行されるまで待機する。

メッセージングアプリケーションを実行している場合は（ステップＳ６０４のＹＥＳ）、制御部１１は、そのメッセージングアプリケーションの実行が一日の中での最初の実行かどうかを判定する（ステップＳ６０５）。一日の中での最初の実行でない場合には（ステップＳ６０５のＮＯ）、ステップＳ６０４の処理に戻る。

メッセージングアプリケーションの実行が一日の中での最初の実行である場合には（ステップＳ６０５のＹＥＳ）、端末２０の制御部１１は、メッセージングアプリケーションを利用していることを示す情報として、ユーザＩＤと、端末２０の機種を示す機種情報とを含む利用情報を、通信Ｉ／Ｆ２２を介してサーバ１０に送信して（ステップＳ６０６）、ステップＳ６０４の処理に戻る。なお、図６に示す構成では、端末２０は、一日に一回利用情報をサーバ１０に送信する構成としているが、利用情報は、メッセージングアプリケーションを実行する都度送信する構成としてもよいし、そうでなくてもよい。この場合には、ステップＳ６０４の処理を省略することができる。また、利用情報は、端末２０からサーバ１０に定期的に送られればよく、一日である必要はなく、半日に一回でもよいし、そうでなくてもよい。また、あるいは、前回利用情報を送信してから所定時間（限定ではなく一例として、６時間）が経過していれば、再度送信するという構成をとってもよい。

次に、図７を用いてサーバ１０の動作例を説明する。図７は、図５に示すやり取りを実現するためのサーバ１０の動作例を示すフローチャートである。なお、上述と同様に、メッセージングアプリ―ションをすでにインストールしている端末２０であれば、以下のステップＳ７０１、Ｓ７０２の処理は不要であり、省略してもよいし、しなくてもよい。

図７に示すように、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４を介して、ユーザの端末２０からメッセージングアプリケーションのインストーラを要求する要求情報を受信しているか否かを判定する（ステップＳ７０１）。メッセージングアプリケーションのインストーラを要求する要求情報を受信していた場合には（ステップＳ７０１のＹＥＳ）、制御部１１は、メッセージングアプリケーションのインストーラを読み出して、通信Ｉ／Ｆ１４を介してユーザの端末２０に、メッセージングアプリケーションのインストーラを送信し（ステップＳ７０２）、処理を終了する。

一方、メッセージングアプリケーションのインストーラを要求する要求情報ではなく（ステップＳ７０１のＮＯ）、メッセージングアプリケーションを利用するユーザの端末２０からユーザ情報を受信していた場合には（ステップＳ７０３のＹＥＳ）、制御部１１の登録部１１２は、受信したユーザ情報が示す内容をユーザ情報３００に登録するとともに、そのユーザについての利用履歴情報を作成して（ステップＳ７０４）、処理を終了する。

また、メッセージングアプリケーションを利用するユーザの端末２０から、ユーザ情報ではなく（ステップＳ７０３のＮＯ）、利用情報を受信した場合には（ステップＳ７０５のＹＥＳ）、登録部１１２は、利用情報で示されるユーザＩＤで示されるユーザの利用履歴情報４００に、受信した利用情報で示される機種情報と利用日時とを、それぞれ、機種情報４０２と利用日時４０３に追加登録して、利用履歴情報を更新し（ステップＳ７０６）、処理を終了する。

次に、図８〜図１０を用いて、機種変更を行いそうな端末を特定して広告を送信する処理について説明する。図８は、サーバ１０と端末２０との間のやり取りの例を示すシーケンス図である。

図８に示すように、サーバ１０は、広告情報の送信要求を受け付ける（ステップＳ８０１）。サーバ１０は、限定ではなく一例として、サーバ１０のオペレータから、記憶部１５に記憶されている広告情報の送信要求を受け付けることとしてもよいし、そうでなくてもよい。あるいは、サーバ１０は、限定ではなく一例として、外部の装置（限定ではなく一例として、広告を配信したい広告主の端末）から、広告情報の送信要求を受け付けることとしてもよいし、そうでなくてもよい。

サーバ１０は、広告情報の送信要求を受け付けると、各ユーザについて、機種変更のタイミングかどうかを推定する（ステップＳ８０２）。そして、広告送信部１１４は、機種変更のタイミングであると推定されたユーザの端末２０に、広告情報を送信する（ステップＳ８０３）。

端末２０は、広告情報を受信すると、受信した広告情報を表示する（ステップＳ８０４）。

図９は、図８に示すやり取りを実現するためのサーバ１０の動作例を示すフローチャートである。

図９に示すように、広告送信部１１４は、広告情報の送信要求を受け付ける（ステップＳ９０１）。広告情報の送信要求は、入出力部１２を介したサーバ１０のオペレータにより入力されてもよいし、広告を送信したいと考えている他のユーザのサーバ等の情報処理装置から通信Ｉ／Ｆ１４を介して受け付けることとしてもよい。

制御部１１の推定部１１３は、機種変更のタイミングが到来している可能性の高いユーザを推定する（ステップ９０２）。限定ではなく一例として、推定部１１３は、利用履歴情報４００を参照して、ユーザが機種変更を行う周期を特定し、その周期の変わり目に来ている場合に、機種変更をする可能性が高いと推定することができる。また、推定部１１３は、限定ではなく一例として、現在の携帯電話機（スマホ）のキャリアとの契約は基本的には２年を単位にしていることが多いことから、最後に機種変更をしたとき、または、最初にメッセージングアプリケーションをインストールしたとき、から２年が近づいていれば、機種変更をする可能性が高いと推定することができる。推定部１１３は、機種変更をする可能性が高いと推定したユーザの情報を広告送信部１１４に送信する。なお、ここでは、推定部１１３は、機種変更をする可能性が高いとユーザを推定する例を示しているが、これは、契約の態様を変更する可能性が高いユーザを推定するものであってもよいし、そうでなくてもよい。

広告送信部１１４は、推定部１１３から伝達されたユーザの情報に基づく各ユーザの端末２０に、ステップＳ９０１で受け付けた広告情報を、通信Ｉ／Ｆ１４を介して、送信し（ステップＳ９０３）、処理を終了する。

図１０は、図８に示すやり取りを実現するための端末の動作例を示すフローチャートである。

図１０に示すように、端末２０の通信Ｉ／Ｆ２２は、サーバ１０から、広告情報を受信する（ステップＳ１００１）。通信Ｉ／Ｆ２２は、受信した広告情報を制御部２１に送信する。

制御部２１の表示処理部２１２は、受信した広告情報を、表示部２４に表示し（ステップＳ１００２）、処理を終了する。なお、広告情報の表示は、メッセージングアプリケーションのトークルーム上への表示であってもよいし、そうでなくてもよい。

＜推定処理の変形例１＞
上記実施形態では、ユーザの機種変更の周期や契約期間に基づいて機種変更、または契約態様を変更する可能性が高いユーザを特定する例を示したが、その他の手法を使って特定することでもできる。本変形例１では、学習モデルを用いてユーザが機種変更をする可能性が高いかを推定する手法について説明する。

変形例１に係る学習モデルは、サーバ１０の学習部１１５により生成されたものであってもよいし、外部の装置により生成されたものを記憶部１５に記憶したものであってもよい。ここでいう学習モデルは、機種変更を推定するための学習モデルである場合には、少なくともユーザが同じ機種の端末を利用している利用期間と、機種変更と、の関係を学習したモデルであり、利用期間の他に、ユーザの属性と併せて、機種変更との関係を学習したモデルであってよい。また、学習モデルは、契約態様の変更を推定するための学習モデルである場合には、少なくともユーザが同じ契約を継続した利用期間と、契約変更と、の関係を学習したモデルであり、利用期間の他に、ユーザの属性と併せて契約態様の変更との関係を学習したモデルであってよい。また、学習モデルは、機種変更と契約態様の変更の双方を推定するための学習モデルであってもよく、その場合に、少なくともユーザの利用期間（ここでいう利用期間は、同じ機種を利用し続けた期間か同じ契約を継続した期間かのいずれかとなる）と、機種変更または契約態様の変更との関係を学習したモデルであってよい。

図１１（ａ）は、学習モデルを生成するために用いる教師データ１１００のデータ構成例を示すデータ概念図である。

図１１（ａ）に示すように、教師データ１１００は、ユーザＩＤ１１００と、性別１１０２と、年代１１０３と、利用期間１１０４と、ＣＶフラグ１１０５とが対応付けられた情報であり、図１１（ａ）に示す教師データ１１００の各行が１つの教師データである。所定数以上（限定ではなく一例として、１００以上であるがこれに限定するものではない）の教師データがあれば学習モデルを生成することができる。教師データの数が多ければ多いほど、推定精度の高い学習モデルを生成することができる。

ユーザＩＤ１１００は、図３に示すユーザ情報３００のユーザＩＤ３０１と同様の情報である。なお、ユーザＩＤ１１００は、学習用の教師データとしては不要の情報であり、なくともよい。

性別１１０２は、ユーザＩＤ１１００に対応するユーザの性別を示す情報である。

年代１１０３は、ユーザＩＤ１１００に対応するユーザの年代を示す情報である。年代１１０３は、ユーザ情報３００の年代３０５に示される年代から導出される情報である。なお、ここでは年代として５歳区切りの情報としているが、これはその限りではなく、１０歳区切りとしてもよいし、年齢そのものでもよい。

利用期間１１０４は、ユーザＩＤ１１００に対応するユーザが同じ機種を利用している利用期間又は同じ契約態様を継続している利用期間の長さを示す情報である。

ＣＶフラグ１１０５は、コンバージョン、即ち、機種変更又は契約態様の変更を行ったか否かを示す情報であり、図１１（ａ）では、「０」、「１」で機種変更又は契約態様の変更を行ったか否かを示しており、ここでは、「０」は機種変更又は契約態様の変更をしていないことを意味し、「１」は機種変更又は契約態様の変更をしていることを意味することとするが、これは逆であってもよい。ＣＶフラグ１１０５は、学習における所謂ラベルに相当する。なお、学習モデルとして機種変更と契約態様の変更の双方を学習する場合には、ＣＶフラグ１１０５は、「０」で何の変更も行っていないことを示し、「１」で機種変更を行ったことを示し、「２」で契約態様の変更を行ったことを示すようにして学習を行うとよい。

学習モデルは、性別１１０２、年代１１０３、利用期間１１０４などのユーザの属性を示す情報と、機種変更をしたかどうかを示すＣＶフラグ１１０５との関係を学習したモデルとなる。なお、図１１（ａ）に示す性別１１０２や年代１１０３は必須ではなく、また、その他の情報として、ユーザの嗜好を示す情報が含まれていてもよい。

図１１（ｂ）は、推定結果の一例である推定結果情報１１１０を示している。ここでは、機種変更を行うかどうかの推定結果の例を示しているが、これは、通信の契約態様の変更を行うかどうかの推定結果の場合も同様である。推定部１１３は、入力として、機種変更を行うかどうかを推定する対象のユーザの属性を示す情報として、ユーザの年齢や性別、嗜好などの情報を、学習モデルに入力し、推定結果を得る。推定部１１３は、限定ではなく一例として、各ユーザが機種変更を行う可能性があるかどうかをパーセンテージで出力する。図１１（ｂ）に示すように、推定部１１３は、入力したユーザごとに、その推定結果を出力する。そして、出力したパーセンテージが、所定の閾値（限定ではなく一例として８０％）を超えている場合に、機種変更を行うと推定する。なお、推定部１１３は、教師データとして入力したユーザの属性全ての属性を入力として用いる必要はなく、その一部のみの入力であってもよい。

推定結果情報１１１０は、ユーザＩＤ１１１１と、ＣＶ確率１１１２と、が対応付けられた情報である。

ユーザＩＤ１１１１は、メッセージングアプリケーションを利用するユーザを一意に識別する識別情報であり、図３に示すユーザＩＤ３０１に相当する。なお、ユーザを一意に特定できるのであれば、ユーザＩＤ１１１１として、図３に示すユーザ名３０２が用いられてもよい。

ＣＶ確率１１１２は、ユーザＩＤ１１１１で示されるユーザが、現在、機種変更を行う可能性をパーセンテージで示した情報である。なお、ここではパーセンテージで示しているが、これは、パーセンテージによる区切り（限定ではなく一例として、０〜１９、２０〜３９、４０〜５９、６０〜７９、８０〜１００）で区分けして、「極低」、「低」、「中」、「高」、「極高」というように表現されてもよいし、単に、機種変更の可能性を、「有」、「無」の２値で表現することとしてもよい。

図１２は、サーバ１０の学習部１１５による学習処理の動作例を示すフローチャートである。図１２では、機種変更を行う可能性を推定するための学習モデルを生成する例を示すが、これは、契約態様の変更を行う可能性を推定するための学習モデルを生成する場合も同様であり、また、機種変更を行う可能性と契約態様の変更を行う可能性の双方を推定する場合の学習モデルの場合も同様である。

図１２に示すように、学習部１１５は、教師データとして、ユーザの情報に、機種変更を行ったかどうかを示す機種変更情報、即ち、ＣＶフラグ１１０５を対応付けたデータの入力を受け付ける（ステップＳ１２０１）。即ち。図１１に示す教師データ１１００の入力を受け付ける。

学習部１１５は、受け付けた教師データを用いて、ユーザの情報、少なくともユーザが同じ機種を使用している利用期間と、機種変更との関係を学習し、学習モデルを生成する（ステップＳ１２０２）。学習に用いるアルゴリズムは既存のアルゴリズムを用いることとしてよい。

学習部１１５は、学習により生成した学習モデルを記憶部１５に記憶し（ステップＳ１２０３）、処理を終了する。

次に、学習モデルを利用したユーザが機種変更を行う可能性があるかどうかを推定する推定処理について、図１３を用いて説明する。図１３は、サーバ１０の推定部１１３の動作例を示すフローチャートである。

図１３に示すように、推定部１１３は、機種変更を行う可能性があるかどうかを知りたいユーザそれぞれについてのユーザの情報を記憶部１５に記憶されているユーザ情報３００から取得する（ステップＳ１３０１）。なお、ここで推定部１１３が取得するユーザの情報は、ユーザ情報３００に含まれる全ての情報であってもよいし、一部のユーザの情報のみであってもよい。一部のユーザは、所定の条件を満たすユーザであってよく、所定の条件はサーバ１０のオペレータにより指定されることとしてもよいし、広告を配信する広告主により指定されることとしてもよい。所定の条件とは、限定ではなく一例として、性別であったり、年代であったりしてよい。

推定部１１３は、記憶部１５から、ユーザ情報、即ち、ユーザの属性と、機種変更との関係を学習した学習モデルを用いて、機種変更の可能性を推定する（ステップＳ１３０２）。即ち、推定部１１３は、記憶部１５から取得したユーザ情報３００に含まれるユーザ各々について、そのユーザの性別や年代、嗜好などの嗜好情報を、学習モデルに入力し、機種変更を行う可能性があるかどうかの情報の出力を得る。

推定部１１３は、推定した機種変更の可能性を示す推定結果情報１１１０を出力する（ステップＳ１３０３）。推定部１１３は、推定した各ユーザについての機種変更の可能性を示す推定結果情報を広告送信部１１４に送信し、処理を終了する。

広告送信部１１４は、推定部１１３により機種変更の可能性が高いと推定されたユーザに対して広告を送信する。

このように、推定部１１３は、ユーザの属性と、機種変更との関係を学習した学習モデルを用いて、広告を送信するその時々で、ユーザが機種変更を行うかどうかを推定することができる。

＜推定処理の変形例２＞
上記変形例１では、広告を送信するタイミングで、各ユーザが機種変更をする可能性が高いかどうか又は契約態様の変更を行う可能性が高いかどうかを推定する例を示した。本変形例２では、ユーザがいつ機種変更をする又は契約態様を変更する可能性が高いかを推定することで、広告情報を送信するタイミングを特定する例を説明する。

図１４（ａ）は、学習に用いる教師データのデータ構成例を示すデータ概念図である。図１４（ａ）に示す教師データ１４００は、ユーザＩＤ１４０１と、性別１４０２と、年齢１４０３と、利用期間１４０４と、が対応付けられた情報である。図１４（ａ）に示す教師データ１４００は、図１１に示した教師データ１１００と基本的に同様の構成を有し、ＣＶフラグ１１０５の有無において相違する。それぞれのデータの内容は、教師データ１１００と同様であるので説明を省略する。

一方で、本変形例２の場合、利用期間１４０４が、所謂教師データにおけるラベルとして機能する。ただし、この利用期間１４０４は、ユーザＩＤ１４０１で示されるユーザが機種変更を実行したとき、又は、契約態様の変更を行ったときに、それまで使用していた端末の利用期間または同じ契約態様を継続した利用期間を示している。したがって、図１４（ａ）に示す教師データを用いて学習モデルを作成した場合、ユーザについて、どのぐらいの利用期間で機種変更又は契約態様の変更を行う可能性があるか、その利用期間を推定することができる学習モデルとなる。

図１４（ａ）の例では、ユーザＩＤ１４０１が、「Ｕ００９２８０２」で示されるユーザは、「男」であり、その年代は「１０−１４」であり、「２３ヶ月」で機種を変更したこととなっている。

図１４（ｂ）は、教師データ１４００を用いて作成された学習モデルを用いた推定処理を行った場合の出力例としての推定結果情報１４１０を示している。図１４（ｂ）に示すように、推定結果情報１４１０は、ユーザＩＤ１４１１と、推定期間１４１２と、が対応付けられた情報である。

ユーザＩＤ１４１１は、メッセージングアプリケーションを利用するユーザを一意に識別する識別情報であり、図３に示すユーザＩＤ３０１に相当する。なお、ユーザを一意に特定できるのであれば、ユーザＩＤ１４１１として、図３に示すユーザ名３０２が用いられてもよい。

推定期間１４１２は、ユーザＩＤ１４１１で示さえるユーザが、どの程度の利用期間で機種変更または契約態様の変更を行う可能性がある期間を示す情報である。即ち、最後に機種変更又は契約態様の変更を行った、若しくは、はじめてメッセージングアプリケーションをインストールしてから、次に機種変更を行うまでの期間（推定された期間）を示す情報である。

図１４（ｂ）によれば、ユーザＩＤ１４１１が「Ｕ００９２８１０」で示されるユーザは、「２６ヶ月」で機種変更又は契約態様の変更を実行する可能性が高いと推定されている。

＜推定処理の変形例３＞
上記変形例１、２では、学習モデルを用いた推定の例を示したが、本変形例３では、学習モデルとは異なる推定を行う例を示す。即ち、変形例３では、各ユーザが通信事業者と契約している通信プランから、機種変更の可能性を推定する。

図１５は、各通信事業者の通信プランに関する契約情報１５００のデータ構成例を示すデータ概念図である。

契約情報１５００は、事業者情報１５０１と、プラン情報１５０２と、基本契約期間１５０３と、が対応付けられた情報である。

事業者情報１５０１は、電気通信事業者又は仮想移動体通信事業者を一意に特定可能な識別情報である。

プラン情報１５０２は、対応する事業者情報１５０１で示される通信事業者がユーザに提供可能なプランを識別するための識別情報である。なお、プランとは、電気通信事業者又は仮想移動体通信事業者が提供する通信サービスを利用するにあたっての条件のことであり、限定ではなく一例として、所定期間毎の利用料金や、通信速度、通信可能なデータ量などの条件が含まれてよい。

基本契約期間１５０３は、対応する事業者情報１５０１で示される通信事業者の、対応するプラン情報１５０２で示されるプランの内容で契約した場合に、定型される契約の基本契約期間の長さを示す情報である。

また、図示はしていないが、本変形例３の場合、ユーザ情報３００には、各ユーザについて、契約している通信事業者の情報、および、その通信事業者と契約しているプランを特定可能なプラン情報が含まれる。

これにより、推定部１１３は、ユーザの通信事業者と通信プランを特定することで、その基本契約期間を特定し、最後に機種変更又は契約態様の変更を行った日付け、もしくは、メッセージングアプリケーションをインストールした日付けからの経過日数が、基本契約期間が終了する間際かどうかで、機種変更を行う可能性又は契約態様の変更を行う可能性があるかを推定することができる。

以下、図１６を用いて、契約情報１５００を用いた機種変更を行う可能性があるユーザの推定処理について説明する。図１６は、サーバ１０の制御部１１の動作例を示すフローチャートである。

図１６に示すように、制御部１１の推定部１１３は、記憶部１５からユーザ情報を取得する（ステップＳ１６０１）。推定部１１３は、取得したユーザ情報から、メッセージングアプリケーションをインストールした日、又は、最後に機種変更を行った日、又は、最後に契約態様の変更を行った日のうち、現在に近い方の日にちを特定する（ステップＳ１６０２）。

推定部１１３は、記憶部１５が取得したユーザ情報の中から、ユーザが契約している通信事業者とそのプランとを特定する。そして、特定した事業者情報とプランから、契約情報１５００を参照して、基本契約期間を特定する（ステップＳ１６０３）。

推定部１１３は、特定した基本契約期間の終了まで所定日数以内であるか否かを判定する（ステップＳ１６０４）。即ち、取得したユーザ情報で示されるユーザの利用履歴情報４００を参照して、メッセージングアプリケーションをインストールした日、もしくは、最後に機種変更を行った日に、基本契約期間を加算した日が、現在から見て、所定日数以内に迫っているかどうかを判定する。

基本契約期間終了まで所定日数以内であると判定した場合には（ステップＳ１６０４のＹＥＳ）、推定部１１３は、ユーザ情報を広告送信部１１４に送信する。そして、広告送信部１１４は、受信したユーザ情報で示されるユーザに広告情報を、通信Ｉ／Ｆ１４を介して、送信し（ステップＳ１６０５）、処理を終了する。基本契約期間終了まで所定日数以内ではないと判定した場合には（ステップＳ１６０４のＮＯ）、そのまま処理を終了する。

なお、上記実施形態、変形例１〜３に示した推定手法は、適宜組み合わせて用いてもよい。ここでいう推定手法を組み合わせて用いるとは、それぞれの推定手法を用いて推定を行い、その推定結果を統合して、推定結果を出力することをいう。推定結果を統合するとは、限定ではなく一例として、変形例１に示した学習モデルによる推定結果と、変形例３に示した推定結果と、のうちのいずれかが機種変更又は契約態様の変更を行う可能性があると推定されたら、機種変更又は契約態様の変更を行うと推定するものとしてもよい。

また、あるいは、限定ではなく一例として、変形例１に示した推定による推定結果が７０％であったとして、変形例３に示した推定結果も機種変更を行う可能性があると推定された場合に、所定の重み値を加算する、あるいは、係数を乗じて、７０％の推定結果を、限定ではなく一例として８０％に引き上げて、その結果から機種変更又は契約態様の変更を行う可能性があるかを推定することとしてもよい。また、このとき、逆に、変形例３の推定結果が機種変更を行う可能性又は契約態様の変更を行う可能性がないとなった場合に、所定の重み値を減算する、あるいは、１以下の係数を乗じることとしてもよい。また、機種変更の可能性のみを推定することとしてもよいし、契約態様の変更の可能性のみを推定することとしてもよいし、双方を推定することとしてもよい。

＜広告の送信例＞
ここでは、メッセージングアプリケーションを利用するユーザに広告情報を送信する例として、企業等のオフィシャルアカウントを利用した広告配信の例を説明する。図１７は、通信システム１における各装置間のやり取りの例を示すシーケンス図である。なお、オフィシャルアカウントとは、メッセージングアプリケーションにおいて、所定の団体や、企業、個人が、不特定多数のユーザに対して、情報を発信するために用いられるアカウントであり、ユーザがオフィシャルアカウントに登録（友だちとして追加）することで、ユーザとオフィシャルアカウントとの間のトークルームが開設される。この開設されたトークルームを介して、団体や企業は、ユーザに情報（主として宣伝広告）を発信する。なお、ユーザがオフィシャルアカウントに登録していなくとも、団体や企業は、オフィシャルアカウントから各ユーザに広告情報を送信できてもよい。ここでは、機種変更を行う可能性が高いユーザに広告情報を送信する例を説明するが、これは、契約変更を行う可能性が高いユーザに送信するものであってもよい。

図１７に示すように、企業等に配される企業サーバ５０から、企業サーバ５０のオフィシャルアカウントに対して、広告情報が送信される（ステップＳ１７０１）。

サーバ１０は、広告情報を受信すると、上記実施形態、変形例１〜３に示したように機種変更を行う可能性が高いユーザを推定する（ステップＳ１７０２）。そして、サーバ１０は、機種変更の可能性が高いと推定されたユーザと、企業サーバ５０との間のオフィシャルアカウントのトークルームに対して、ステップＳ１７０１で受信した広告情報を送信する（ステップＳ１７０３）。そして、端末２０は、受信した広告情報をオフィシャルアカウントのトークルームに表示する（ステップＳ１７０４）。

なお、ステップＳ１７０１において、企業サーバ５０は、送信する広告情報に、機種変更を行う可能性が高いユーザに対する広告であるかを示すフラグを付しておき、このフラグを付している場合に推定部１１３による機種変更の可能性が高いユーザを推定する処理を行い、このフラグが付されていない場合には、推定部１１３による機種変更の可能性が高いユーザを推定することなくオフィシャルアカウントのトークルームに広告情報を送信するように構成してもよい。

図１８は、端末２０が受信した広告情報の表示例を示す画面図である。ここでは、図１７に示すやり取りの結果、企業サーバ５０のオフィシャルアカウントのトークルームに、広告情報１８００が表示されている例を示している。なお、広告情報１８００の表示は、オフィシャルアカウントのトークルームではなく、他のトークルームで表示されてもよいし、サーバ１０が配信する各種の情報（ニュース）の中の一つとして表示されてもよい。ここで、図１８に示すように、広告情報１８００は、機種変更に関連する広告であれば、より高い広告効果が見込める。限定ではなく一例として、機種変更に関連する広告は、新機種の案内であったり、新たな通信の契約プランの提示であったりしてよい。

ここで、端末に表示される広告情報には、ユーザにとって何らかの得となる特典情報が含まれてもよい。図１８の例でいえば、広告情報で示される端末を購入する際の割引券（クーポン）であったり、購入により何等かのサービスを受けるために利用可能なポイントが受け取れるものであってもよい。

サーバ１０は、広告情報を送信する際に、機種変更を行う可能性が高いユーザ全て又は契約態様を変更する可能性が高いユーザ全てに特典情報を付与して送信することにしてもよいし、しなくてもよい。即ち、推定部１１３が推定したユーザの一部のユーザにのみ特典情報を含む広告情報を送信することとしてもよい。また、その一部のユーザを選択する際の基準はどのようなものであってもよいが、限定ではなく一例として、ユーザが同じ機種を利用している利用期間又は同じ契約態様を継続している利用期間の長短によって定まるものであってもよく、また、利用期間の長さによって、異なる特典情報を含ませてもよい。また、利用期間が長ければ長いほど、ユーザにとってよりよい特典情報を含む広告情報を送信してもよい。即ち、ユーザが同じ機種を一定期間以上（限定ではなく一例として、２年以上）使用している、又は同じ契約態様を継続しているユーザには特典情報のある広告情報を送信し、端末を使用している利用期間又は同じ契約態様を継続している利用期間が、同一定期間を経過していないユーザには特典情報を含まない広告情報を送信することとしてもよい。また、あるいは、第１の一定期間以上（限定ではなく一例として１年以上）同じ機種を使用している又は同じ契約態様を継続しているユーザには、限定ではなく一例として一割引きの特典情報を含む広告情報を送信し、第１の一定期間よりも長い第２の一定期間以上（限定ではなく一例として３年以上）同じ機種を使用している又は同じ契約態様を継続しているユーザには、限定ではなく一例としてよりよい割引率の二割引きの特典情報を含む広告情報を送信することとしてもよい。

＜実施形態の効果＞
サーバ１０は、ユーザの端末２０から、メッセージングアプリケーションを利用している場合に、メッセージングアプリケーションを利用していることを示す利用情報を受信し、その利用履歴情報を記憶する。そして、サーバ１０は、利用履歴情報を参照して、適切なタイミングで広告情報を送信する。
したがって、サーバ１０は、ユーザがメッセージングアプリケーションを利用することにより取得できる利用履歴情報に基づいて、広告をうつことができる。

サーバ１０は、メッセージングアプリケーションが起動されたユーザの端末２０から、利用情報を取得し、蓄積する。利用情報には、ユーザの端末２０の端末情報が含まれており、その変化があった場合に、サーバ１０は、ユーザの端末について何らかの変化があったことを認識することができる。したがって、サーバ１０は、現在日時から、メッセージングアプリケーションをインストールした日、または、端末について何らかの変化があった日を、減算することで、現在まで同じ状態で端末を利用している利用期間を特定することができる。
これにより、サーバ１０は、ユーザが同じ状態で端末を利用している期間に基づいて、広告をうつことができる。

サーバ１０が、ユーザの端末から受信する利用情報に含まれる端末に関する情報は、端末の機種、あるいは、ユーザが契約している通信事業者に関する情報であってよい。通信事業者とは、電気通信事業者、仮想移動体通信事業者の双方を少なくとも含む。よって、サーバ１０は、利用情報に含まれる端末に関する情報が端末の機種に関する情報である場合には、ユーザが同じ機種の端末を利用している利用期間を特定できる。同様に、サーバ１０は、利用情報に含まれる端末に関する情報が、通信事業者に関する情報である場合には、同じ電気通信事業者あるいは同じ仮想移動体通信事業者を利用し続けている利用期間を特定できる。
サーバ１０は、これらの情報を利用することで、ユーザが同一機種の端末を利用している期間または同じ通信契約を継続している期間を特定することができる。したがって、サーバ１０は、ユーザが機種変更あるいは契約態様の変更を行う可能性があるかどうかを推定することができ、そのようなタイミングにおいて効果的な広告をうつことができる。

また、サーバ１０は、ユーザが同一の機種の端末を利用している期間が、予め定められた期間に近づいている場合に、機種変更を行う可能性が高いと推定して広告情報を送信することとしてもよい。
これにより、サーバ１０は、予め定めた期間との比較により、ユーザが機種変更を行う可能性が高いか否かを推定することができる。

また、サーバ１０は、予め定められた期間として、ユーザが契約しているキャリアのプランにより定まる基本契約期間に基づいて、ユーザが機種変更を行う可能性が高いかを推定することとしてもよい。
これにより、ユーザの基本契約期間の終わりに近づいている場合には、機種変更を行う可能性があるとして、ユーザに効果的に広告を提供することができる。

また、サーバ１０は、利用履歴情報を用いることで、ユーザによる機種変更の周期を特定し、その周期に基づいて、ユーザが機種変更を行う可能性が高いか否かを推定することとしてもよい。
これにより、サーバ１０は、周期的に機種変更を行うユーザに対して、効果的に広告情報を送信することができる。

また、サーバ１０が送信する広告情報は、機種変更に関する情報であってよい。
これにより、機種変更を行う可能性が高いユーザにとって効果が高いと見込まれる広告情報を送信することができる。

また、サーバ１０は、ユーザの属性と、ユーザが同一の機種を利用している利用期間との関係を学習した学習モデルを用いて、ユーザの属性を入力することで、ユーザが機種変更を行う可能性を推定することができる。
これにより、サーバ１０は、ユーザが同一の機種を使用している利用期間だけでなく、ユーザの各種の属性（限定ではなく一例として、年齢や性別など）を用いることで、より精度よく、機種変更を行う可能性を推定することができる。

また、サーバ１０は、企業サーバ５０から送信された広告情報を、企業サーバ５０と送信先のユーザとの間のオフィシャルアカウントのトークルームに送信することとしてもよい。
これにより、企業サーバ５０は、自社の広告を、ユーザが機種変更を行う可能性が高いタイミングで、ユーザに送付することができ、自社にとって得となる宣伝広告を行うことができる。

１ 通信システム
１０ サーバ
１１ 制御部
１１１ メッセージ処理部
１１２ 登録部
１１３ 推定部
１１４ 広告送信部
１１５ 学習部
１２ 入出力部
１３ 表示部
１４ 通信Ｉ／Ｆ（通信部）
１５ 記憶部
２０ 端末
２１ 制御部
２１１ メッセージ処理部
２１２ 表示処理部
２２ 通信Ｉ／Ｆ
２３ 入出力部
２３１ タッチパネル
２３２ マイク
２３３ スピーカ
２３４ カメラ
２４ 表示部（ディスプレイ）
２５ 位置情報取得部
２８ 記憶部
３０ ネットワーク

Claims (20)

1. 端末と通信するサーバによって実行されるプログラムであって、
   前記端末のアプリケーションによって取得された端末情報を前記サーバの通信部によって受信することと、
   前記端末情報に基づく、前記端末のユーザの利用期間に関する情報に基づいて、広告に関する広告情報を前記通信部によって前記端末に送信することとが前記サーバによって実行される。
2. 請求項１に記載のプログラムであって、
   前記利用期間に関する情報は、前記端末情報と、現在の日にちの情報とに基づく情報である。
3. 請求項１または請求項２に記載のプログラムであって、
   前記端末情報は、前記端末の機種情報、前記端末のユーザが利用する回線情報、および前記端末のユーザが利用する仮想移動体通信事業者の情報のうち、少なくとも一つを含む。
4. 請求項３に記載のプログラムであって、
   前記利用期間は、前記端末のユーザが前記端末を利用している期間、前記端末のユーザが利用している回線を利用している期間、および前記端末のユーザが利用する仮想移動体通信業者を利用している期間のうち、少なくとも一つを含む。
5. 請求項３または請求項４に記載のプログラムであって、
   前記利用期間に関する情報は、前記端末情報に基づく、前記端末の機種を変更した日にちの情報と、現在の日にちの情報とに基づく情報を含む。
6. 請求項３から請求項５に記載のプログラムであって、
   前記利用期間に関する情報は、前記端末情報に基づく、前記端末のユーザが利用する回線を変更した日にちの情報と、現在の日にちの情報とに基づく情報を含む。
7. 請求項３から請求項６のいずれか一項に記載のプログラムであって、
   前記利用期間に関する情報は、前記端末情報に基づく、前記端末のユーザが利用する仮想移動体通信事業者を変更した日にちの情報と、現在の日にちの情報とに基づく情報を含む。
8. 請求項１から請求項７のいずれか一項に記載のプログラムであって、
   前記広告情報は、前記利用期間に関する情報と、設定された期間とに基づき、前記通信部によって前記端末に送信される。
9. 請求項８に記載のプログラムであって、
   前記設定された期間は、前記端末情報に基づき変更される。
10. 請求項１から請求項９のいずれか一項に記載のプログラムであって、
    前記利用期間に基づき前記端末のユーザが取得可能な特典情報を前記広告情報に含めて前記端末に送信することが前記サーバに実行される。
11. 請求項１から請求項１０のいずれか一項に記載のプログラムであって、
    前記広告情報は、複数端末の各々から受信した複数の端末情報に基づく、前記複数端末各々のユーザの前記利用期間に関する情報に基づき、設定された期間よりも前記利用期間が長いユーザの端末に送信される。
12. 請求項３に記載のプログラムであって、
    前記広告情報は、前記利用期間に関する情報に基づく、前記端末のユーザの機種変更頻度、または機種変更の間隔に基づき、前記通信部によって前記端末に送信される。
13. 請求項３に記載のプログラムであって、
    前記広告情報は、前記利用期間に関する情報に基づく、前記端末のユーザが利用する回線の変更頻度、または回線の変更の間隔に基づき、前記通信部によって前記端末に送信される。
14. 請求項３に記載のプログラムであって、
    前記広告情報は、前記利用期間に関する情報に基づく、前記端末のユーザが利用する仮想移動体通信事業者の変更頻度、または仮想移動体通信事業者の変更の間隔に基づき、前記通信部によって前記端末に送信される。
15. 請求項１から請求項１４のいずれか一項に記載のプログラムであって、
    前記広告情報は、機種、回線、および仮想移動体通信事業者のうち少なくとも一つの変更に関する情報を含む。
16. 請求項１から請求項１５のいずれか一項に記載のプログラムであって、
    前記広告情報は、前記利用期間に関する情報と、前記端末のユーザの属性に関する情報とに基づいて、前記通信部によって前記端末に送信される。
17. 請求項１から請求項１６のいずれか一項に記載のプログラムであって、
    前記広告情報は、第１アカウントの前記端末のユーザと、第２アカウントの前記広告情報を送信するユーザとを含む、前記端末に表示されるチャットルームに含まれる。
18. 端末と通信するサーバの情報処理方法であって、
    前記端末のアプリケーションによって取得された端末情報を前記サーバの通信部によって受信することと、
    前記端末情報に基づく、前記端末のユーザの利用期間に関する情報に基づいて、広告に関する広告情報を前記通信部によって前記端末に送信することとを含む。
19. 端末と通信するサーバであって、
    前記端末のアプリケーションによって取得された端末情報を受信する通信部と、
    前記端末情報に基づく、前記端末のユーザの利用期間に関する情報に基づいて、広告に関する広告情報を前記通信部によって前記端末に送信する制御を行う制御部とを備える。
20. 端末と通信するサーバであって、
    メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサーを備え、
    前記プロセッサーは、
    前記端末のアプリケーションによって取得された端末情報を前記サーバの通信部によって受信することと、
    前記端末情報に基づく、前記端末のユーザの利用期間に関する情報に基づいて、広告に関する広告情報を前記通信部によって前記端末に送信することとを実行する。

Images