<法的事項の遵守>
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
本開示に係る端末による送信または受信に係る状況を確認できる表示方法等を実施するための実施形態について、図面を参照して説明する。
<システム構成>
図1は、本開示の一実施形態に係る通信システム1の構成を示す。図1に開示されるように、通信システム1では、ネットワーク30を介してサーバ10と、端末20(端末20A,端末20B,端末20C)とが接続される。サーバ10は、ネットワーク30を介してユーザが所有する端末20に、端末20間でのメッセージの送受信を実現するサービスを提供する。なお、ネットワーク30に接続される端末20の数は限定されない。
ネットワーク30は、1以上の端末20と、1以上のサーバ10とを接続する役割を担う。すなわち、ネットワーク30は、端末20がサーバ10に接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
ネットワーク30のうちの1つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク30は、限定でなく例として、アドホック・ネットワーク(ad hoc network)、イントラネット、エクストラネット、仮想プライベート・ネットワーク(virtual private network:VPN)、ローカル・エリア・ネットワーク(local area network:LAN)、ワイヤレスLAN(wireless LAN:WLAN)、広域ネットワーク(wide area network:WAN)、ワイヤレスWAN(wireless WAN:WWAN)、大都市圏ネットワーク(metropolitan area network:MAN)、インターネットの一部、公衆交換電話網(Public Switched Telephone Network:PSTN)の一部、携帯電話網、ISDN(integrated service digital networks)、無線LAN、LTE(long term evolution)、CDMA(code division multiple access)、ブルートゥース(Bluetooth(登録商標))、衛星通信など、または、これらの2つ以上の組合せを含むことができる。ネットワーク30は、1つまたは複数のネットワーク30を含むことができる。
端末20(端末20A,端末20B,端末20C)は、各実施形態において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末20は、限定ではなく例として、スマートフォン、携帯電話(フィーチャーフォン)、コンピュータ(限定でなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定でなく例として、PDA(personal digital assistant)、電子メールクライアントなど)、ウェアラブル端末(メガネ型デバイス、時計型デバイスなど)、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末20は情報処理端末と表現されてもよい。
端末20A、端末20Bおよび端末20Cの構成は基本的には同一であるため、以下の説明においては、端末20について説明する。また、必要に応じて、ユーザXが利用する端末を端末20Xと表現し、ユーザXまたは端末20Xに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Xと表現する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
サーバ10は、端末20に対して、所定のサービスを提供する機能を備える。サーバ10は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ10は、限定でなく例として、サーバ装置、コンピュータ(限定でなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定でなく例として、PDA、電子メールクライアントなど)、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ10は情報処理装置と表現されてもよい。サーバ10と端末20とを区別する必要がない場合は、サーバ10と端末20とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
<ハードウェア(HW)構成>
図1を用いて、通信システム1に含まれる各装置のHW構成について説明する。
(1)端末のHW構成
端末20は、制御部21(CPU:central processing unit(中央処理装置))、記憶部28、通信I/F22(インタフェース)、入出力部23、表示部24、位置情報取得部25を備える。端末20のHWの各構成要素は、限定でなく例として、バスBを介して相互に接続される。なお、端末20のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末20は、マイク232、カメラ234、位置情報取得部25等、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
通信I/F22は、ネットワーク30を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F22は、ネットワーク30を介して、サーバ10との通信を実行する機能を有する。通信I/F22は、各種データを制御部21からの指示に従って、サーバ10に送信する。また、通信I/F22は、サーバ10から送信された各種データを受信し、制御部21に伝達する。また、通信I/F22を単に通信部と表現する場合もある。また、通信I/F22が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部23は、端末20に対する各種操作を入力する装置、および、端末20で処理された処理結果を出力する装置を含む。入出力部23は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
入力部は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部21に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定でなく例として、タッチパネル231、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ234(動画像を介した操作入力)、マイク232(音声による操作入力)を含む。
出力部は、制御部21で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定でなく例として、 タッチパネル、タッチディスプレイ、スピーカ233(音声出力)、レンズ(限定でなく例として3D(three dimensions)出力や、ホログラム出力)、プリンターなどを含む。
表示部24は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部24は、限定でなく例として、タッチパネル、タッチディスプレイ、モニタ(限定でなく例として、液晶ディスプレイやOELD(organic electroluminescence display))、ヘッドマウントディスプレイ(HDM:Head Mounted Display)、プロジェクションマッピング、ホログラム、空気中など(真空であってもよいし、そうでなくてもよい)に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部24は、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。
入出力部23がタッチパネルの場合、入出力部23と表示部24とは、略同一の大きさおよび形状で対向して配置されていてもよい。
制御部21は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
制御部21は、限定でなく例として、中央処理装置(CPU)、マイクロプロセッサ(microprocessor)、プロセッサコア(processor core)、マルチプロセッサ(multiprocessor)、ASIC(application-specific integrated circuit)、FPGA(field programmable gate array)を含む。
記憶部28は、端末20が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部28は、限定でなく例として、HDD(hard disk drive)、SSD(solid state drive)、フラッシュメモリ、RAM(random access memory)、ROM(read only memory)など各種の記憶媒体を含む。また、記憶部28は、メモリ(memory)と表現されてもよいし、されなくてもよい。
端末20は、プログラムPを記憶部28に記憶し、このプログラムPを実行することで、制御部21が、制御部21に含まれる各部としての処理を実行する。つまり、記憶部28に記憶されるプログラムPは、端末20に、制御部21が実行する各機能を実現させる。また、このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
マイク232は、音声データの入力に利用される。スピーカ233は、音声データの出力に利用される。カメラ234は、動画像データの取得に利用される。
(2)サーバのHW構成
サーバ10は、制御部11(CPU)、記憶部15、通信I/F14(インタフェース)、入出力部12、表示部13を備える。サーバ10のHWの各構成要素は、限定でなく例として、バスBを介して相互に接続される。なお、サーバ10のHWは、サーバ10のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ10のHWは、表示部13を取り外すような構成であってもよいし、そうでなくてもよい。
制御部11は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
制御部11は、代表的には中央処理装置(CPU)、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ASIC、FPGAであってもよいし、そうでなくてもよい。本開示において、制御部11は、これらに限定されない。
記憶部15は、サーバ10が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部15は、HDD、SSD、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部15は、これらに限定されない。また、記憶部15は、メモリ(memory)と表現されてもよいし、されなくてもよい。
通信I/F14は、ネットワーク30を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F14は、ネットワーク30を介して、端末20との通信を実行する機能を有する。通信I/F14は、各種データを制御部11からの指示に従って、端末20に送信する。また、通信I/F14は、端末20から送信された各種データを受信し、制御部11に伝達する。また、通信I/F14を単に通信部と表現する場合もある。また、通信I/F14が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部12は、サーバ10に対する各種操作を入力する装置により実現される。入出力部12は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部11に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部12は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部12、限定でなく例として、タッチパネルやカメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部12は、これらに限定されない。
表示部13は、代表的にはモニタ(限定でなく例として、液晶ディスプレイやOELD(organic electroluminescence display))で実現される。なお、表示部13は、ヘッドマウントディスプレイ(HDM)などであってもよいし、そうでなくてもよい。なお、これらの表示部13は、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。ただし、本開示において、表示部13は、これらに限定されない。
サーバ10は、プログラムPを記憶部15に記憶し、このプログラムPを実行することで、制御部11が、制御部11に含まれる各部としての処理を実行する。つまり、記憶部15に記憶されるプログラムPは、サーバ10に、制御部11が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
本開示の各実施形態においては、端末20および/または、サーバ10のCPUがプログラムPを実行することにより、実現するものとして説明する。
なお、端末20の制御部21、および/または、サーバ10の制御部11は、制御回路を有するCPUだけでなく、集積回路(IC(Integrated Circuit)チップ、LSI(Large Scale Integration))等に形成された論理回路(ハードウェア)や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、1または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を1つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、LSIは、集積度の違いにより、VLSI、スーパーLSI、ウルトラLSIなどと呼称されることもある。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
また、本開示の各実施形態のプログラムP(限定ではなく、例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムPを記憶可能である。また、プログラムPは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムPとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であってもよいし、そうでなくてもよい。
記憶媒体は、1つまたは複数の半導体ベースの、または他の集積回路(IC)(限定でなく例として、フィールド・プログラマブル・ゲート・アレイ(FPGA)または特定用途向けIC(ASIC)など)、ハード・ディスク・ドライブ(HDD)、ハイブリッド・ハード・ドライブ(HHD)、光ディスク、光ディスクドライブ(ODD)、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ(FDD)、磁気テープ、固体ドライブ(SSD)、RAMドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの2つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムPを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ(memory)と表現されてもよいし、されなくてもよい。
サーバ10および/または端末20は、記憶媒体に記憶されたプログラムPを読み出し、読み出したプログラムPを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
また、本開示のプログラムPDDは、当該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ10および/または端末20に提供されてもよいし、されなくてもよい。サーバ10および/または端末20は、限定でなく例として、インターネット等を介してダウンロードしたプログラムPを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
また、本開示の各実施形態は、プログラムPが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
サーバ10および/または端末20における処理の少なくとも一部は、1以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末20における処理の少なくとも一部を、サーバ10により行う構成としてもよいし、そうでなくてもよい。この場合、端末20の制御部21の各機能部の処理のうち少なくとも一部の処理を、サーバ10で行う構成としてもよいし、そうでなくてもよい。
サーバ10における処理の少なくとも一部を、端末20により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ10の制御部11の各機能部の処理のうち少なくとも一部の処理を、端末20で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
なお、本開示のプログラムは、限定でなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのオブジェクト指向プログラミング言語、HTML5などのマークアップ言語などを用いて実装される。
<実施形態>
本実施形態に係るサーバ10は、ユーザが端末の機種変更を行いそうなタイミングや通信の契約の態様(以下、契約態様と記載する)を変更するタイミングを推定し、そのタイミングに効果的な広告情報を送信することで、広告としての宣伝効果を向上させる。
ここで端末の機種変更とは、通信事業者を変更することなく端末を新たな端末に変更すること、通信事業者を変更したうえで端末を新たな端末に変更することを含む。
また、契約態様を変更するとは、ユーザが利用している通信事業者そのものを変更すること、通信事業者を変更せずに通信事業者と契約している通信プランを変更することを含む。
通信事業者とは、一般的にキャリアと呼称される、電話通信やメッセージ等の通信サービスを提供する電気通信事業者、および、仮想移動体通信事業者(MVNO:Mobile Virtual Network Operator)と呼称される、無線通信回線設備を開設・運用せずに移動体通信サービスを行う事業者を含む。
図2を用いて、サーバ10によるユーザの端末の機種変更を行いそうなタイミングの推定例を説明する。なお、ここでは、機種変更を行いそうなタイミングとしているが、これは、上述の通り、契約態様の変更を行いそうなタイミングであってもよいし、そうでなくてもよい。
図2に示すように、ユーザ40は、自身の端末20に、2017年2月8日に、メッセージングアプリケーションをインストールする。メッセージングアプリケーションは、サーバ10を介して、複数のユーザ間でコンテンツのやり取りを行うための通信ツールであり、各ユーザ間のコンテンツのやり取りは、トークルームで行われる。
コンテンツとは、メッセージングアプリケーション上でトークルームを介してユーザによりやり取りされるデータのことであり、ユーザが自身の端末20を利用して入力した文字情報(テキストデータ)、写真やスタンプなどを含む画像情報(例えば、ユーザがいる場所の写真)、音声ファイル、動画ファイル、データファイルなど各種のファイル情報、広告情報を含むが、これらに限定するものではない。
トークルームとは、限定ではなく一例として、サーバ10が提供するメッセージングサービスにおいて、メッセージングサービスを利用するユーザ同士によって、送受信されたコンテンツをユーザの端末に表示可能にするユーザインターフェースである。トークルームは、チャットルームと呼称されてもよい。
メッセージングアプリケーションがインストールされてから、期間T1をあけて、2017年11月20に、ユーザ40は、端末20の機種変更を行って、メッセージングアプリケーションのアカウントの引継ぎを行う。
アカウントの引継ぎとは、新たな端末で、以前と同じアカウントでメッセージングアプリケーションを利用できるようにするための設定である。そして、期間T2が経過した2018年9月14日に、ユーザ40は、再度、機種変更とメッセージングアプリケーションのアカウントの引継ぎを行う。サーバ10は、端末20からメッセージングアプリケーションを利用している(実行している)ことを示す利用情報を適宜受信する。ここでいう利用情報は、ユーザを特定可能な情報と、ユーザが利用している端末の機種情報とが含まれてもよいし、そうでなくてもよい。したがって、サーバ10は、日々サーバ10に送信される利用情報の履歴をとっておくことで、受信した利用情報に含まれる機種情報の変化を確認することで機種変更を行ったタイミングを推定できる。なお、契約態様の変更のタイミングを推定する場合には、利用情報には、機種情報に代えて(あるいは、機種情報に加えて)、通信事業者の情報や契約プランの情報が含まれてもよいし、そうでなくてもよい。
そして、サーバ10は、ユーザが現在同一の機種を利用している利用期間T3から機種変更を行う可能性が高いかを推定する。限定ではなく一例として、サーバ10は、期間T1と期間T2とから、現在ユーザ40が機種変更を行う可能性が高いか、あるいは、期間T3を推定し、機種変更を行う可能性が高い場合に、広告情報を送信する。
広告情報とは、企業、店舗あるいは人物などを紹介、宣伝し、情報伝達を行うものをいう。広告情報は、上述したメッセージ、スタンプ、動画、静止画等であってもよいし、そうでなくてもよい。広告を行う広告主は、サーバ10であってもよいし、サーバ10以外の企業や店舗、人物であってもよい。また、この広告は、機種変更に関連する情報であってよい。本実施形態の場合、特に、機種変更に関連する広告であると、広告として高い宣伝効果が見込める。限定ではなく一例として、端末の新機種を紹介する広告が挙げられる。
以下、ユーザが機種変更を行う可能性が高いかどうかの推定処理と広告情報の送信について詳細に説明する。なお、本実施形態においては、ユーザが機種変更を行う可能性が高いかをどうかを推定する場合について詳述する。契約態様を変更する可能性が高いかどうかを推定する手法については、代替として必要となる情報、処理について適宜説明する。
(1)ユーザの端末の機能構成
図1に示すように、端末20の制御部21は、メッセージ処理部211と、表示処理部212と、を備える。
メッセージ処理部211は、サーバ10が提供するメッセージングサービスから提供されるメッセージングアプリケーションに従って、ユーザからの入力および/または通信I/F12が受信したメッセージを含むコンテンツの入力を受け付けて、表示処理部212に表示するように指示する。なお、ユーザからの入力を受け付けた場合には、その受け付けた入力内容を通信I/F22にサーバ10に宛てて送信するように指示する。また、ここでメッセージ処理部211が処理する対象として、トークルームに対してユーザが入力したテキストメッセージに限らず、写真やスタンプなどを含む画像情報、音声ファイル、動画ファイル、データファイルなどを含んでよい。また、メッセージ処理部211は、メッセージングアプリケーションの一日の中での最初の起動時に、通信I/F22を介して、サーバ10にメッセージングアプリケーションを利用していることを示す利用情報を送信する。利用情報は、少なくともユーザIDと、端末20の機種情報とを含む。なお、ここでいう最初の起動時は、メッセージングアプリケーションを実行すること、並びに、実行されていてスリープ状態のメッセージングアプリケーションを表示することの、双方の場合を含む。なお、契約態様の変更の可能性が高いかどうかを推定する場合には、利用情報には、端末20の機種情報に代えて(あるいは、加えて)、ユーザが契約している通信事業者の情報や契約している通信プランを識別する通信プラン情報が含まれる。
表示処理部212は、サーバ10が提供するメッセージングサービスから提供されるメッセージングアプリケーションに従って、ユーザからの入力および/または通信I/F12が受信したメッセージを含むコンテンツの入力を受け付けて、表示部24の表示領域に表示するように指示する。なお、ユーザからの入力を受け付けた場合には、その受け付けた入力内容を通信I/F22にサーバ10に宛てて送信するように指示する。表示処理部212は、サーバ10からの指示に従って、トークルームに表示する各メッセージについて、指定された表示態様、または、メッセージを送信した端末の場所に基づく表示態様でメッセージ(コンテンツ)を表示することとしてもよいし、そうしなくてもよい。表示処理部212は、広告情報を表示する。
以上が、端末20の機能構成である。
(2)サーバの機能構成
図1に示すように、サーバ10の制御部11は、メッセージ処理部111と、登録部112と、推定部113と、広告送信部114と、を備える。また、制御部11は、学習部115を備えていてもよい。
メッセージ処理部111は、各ユーザ間のやり取りを行うためのトークルームを管理する機能を備える。メッセージ処理部111は、サーバ10が提供するメッセージングサービスの提供を受ける端末間のコンテンツを含むコンテンツのやり取りを中継する。即ち、あるユーザからトークルームへのコンテンツが送信された場合に、そのトークルームを特定し、トークルームに属する他のユーザにコンテンツを送信する。
登録部112は、ユーザが端末にメッセージングアプリケーションをインストールした際に、ユーザの端末から送信されるユーザ自身の情報を、記憶部15に登録する。
推定部113は、ユーザが端末を利用している利用期間を特定可能な利用履歴情報400を参照して、ユーザが機種変更を行うタイミングかどうかを推定する。推定部113による推定は、現在機種変更を行う可能性があるかどうかを推定するものであってもよいし、次にいつ機種変更を行う可能性がある日時を推定するものであってもよい。また、推定部113は、ユーザが、利用している端末の通信の契約情報を含む利用履歴情報を参照して、契約態様を変更するタイミングかどうかを推定する。
広告送信部114は、推定部113による推定に基づき、機種変更を行う可能性があるユーザの端末に、広告を送信する。
学習部115は、少なくともユーザが同じ機種の端末を利用している利用期間を含むユーザの属性を示す情報と、そのユーザが機種変更を行ったかどうか、又は、契約態様を変更したかどうかを示すコンバージョン情報とが対応付けられた情報を教師データとして学習を行い、ユーザの同じ機種の利用期間又は同じ契約態様の利用期間とコンバージョンとの関係を示す学習モデルを生成する。学習のアルゴリズムは既存のアルゴリズムを利用してよい。また、学習部115は、所定のタイミング(限定ではなく一例として、所定数の教師データとなる利用履歴情報が蓄積されたタイミングであってもよいし、予め定められた期間毎(限定ではなく一例として3ヶ月毎)で適宜、記憶部15に記憶されている学習モデルを更新することとしてもよい。メッセージングアプリケーションの利用履歴の情報は、日を追うごとに蓄積されていくので、より多くの教師データの元となるデータが蓄積されることになる。したがって、その追加された履歴データを利用して、学習モデルの更新を行うこととしてもよい。
なお、図示はしていないが、サーバ10の記憶部15は、後述するユーザ情報300や利用履歴情報400を記憶している。また、記憶部15は、学習部115あるいは他の装置により生成されたユーザが機種変更を行うかどうかを推定するために用いる学習モデルを記憶していてもよい。
<データ>
図3は、ユーザ情報300の構成例を示すデータ概念図である。ユーザ情報300は、メッセージングアプリケーションを利用している各ユーザに関する情報であり、各ユーザに関するものであって、サーバ10が収集可能な情報であれば、どのような情報が含まれてもよい。
図3に示すように、ユーザ情報300は、ユーザID301と、ユーザ名302と、機種情報303と、契約情報304と、年代305と、性別306と、エリア307と、嗜好308とが対応付けられた情報である。ユーザ情報300に含まれる各情報は、ユーザがメッセージングアプリケーションをダウンロードする際にユーザにより登録される情報であってもよいし、ユーザがメッセージングアプリケーションを使用する上でサーバ10が取得できる情報であってもよい。
ユーザID301は、通信システム1上で各ユーザを一意に識別するための識別情報である。
ユーザ名302は、ユーザID301に対応するユーザの名称を示す情報である。ユーザ名302は、本名であってもよいし、本名ではなく、便宜上の呼称、即ち、ニックネームやハンドルネームであってもよい。
機種情報303は、ユーザID301に対応するユーザが保持する端末の機種を示す情報であって、ユーザがメッセージングアプリケーションをインストールした端末の機種を示す情報である。機種情報303は、ユーザがメッセージングアプリケーションをインストールし、そのメッセージングアプリケーションが起動されて、情報がユーザの端末20からサーバ10に送信されることで取得することができる。なお、機種情報303に代えて、各端末固有の端末ID(シリアルナンバー)を用いることとしてもよい。
契約情報304は、ユーザID301に対応するユーザが保持する端末を利用して通信を行うために契約している通信事業者を示す情報である。通信事業者は、電気通事業者及び仮想移動体通信事業者を含む。また、契約情報304は、更に、契約しているプランを示す情報も含まれてもよいし、含まなくともよい。
年代305は、ユーザID301に対応するユーザの年齢が含まれる年代を示す情報である。年代305は、ユーザにより入力される情報であってよく、ユーザの年代ではなく、ユーザの正確な年齢を示す情報であってもよい。また、あるいは、年代305は、ユーザの生年月日で代替されてもよい。
性別306は、ユーザID301に対応するユーザの性別を示す情報である。性別306は、ユーザにより入力される情報である。
エリア307は、ユーザID301に対応するユーザが高頻度で滞在している地域を示す情報である。図3では、一例として都道府県を示しているが、これは都道府県の単位である必要はなく市町村の単位であってもよいし、逆に、関東、東北などの地方を示す情報であってもよい。また、あるいは、地図の経緯度の範囲で示されるセグメントの情報であってもよい。エリア307は、ユーザが起動したメッセージングアプリケーションの機能として保持されユーザからの許可がある場合に実行が許容される位置情報取得機能により取得された位置情報から特定することができる。
嗜好308は、ユーザID301に対応するユーザの嗜好、趣味、関心を示すものを示す情報である。嗜好308は、ユーザにより入力されてもよいし、ユーザがアクセスしたニュースやウェブサイトなどから特定されてもよい。
図3の例で言えば、ユーザID301が「U0092801」のユーザは、ユーザ名が、「A山A夫」であり、使用している端末の機種は、「kphone」であり、契約している通信事業者は、「A社」であり、年代は「35~39」であり、性別は「男」であり、よくいるエリアは「東京」であり、嗜好の情報として、「株、金融、切手、…」が対応付けられている。
なお、図3には、図示していないが、ユーザ情報300には、その他のユーザに関連する情報が含まれてもよい。また、サーバ10によるメッセージングアプリケーションの運用上必須ではない情報、限定ではなく一例として年代305や性別306などの情報は含まれていなくてもよい。
図4は、ユーザがメッセージングアプリケーションを利用している日時であって、どの機種の端末を利用してメッセージングアプリケーションを運用しているかを示す利用履歴情報400の構成例を示すデータ概念図である。図4に示すように利用履歴情報400は、ユーザID401と、機種情報402と、利用日時403とが対応付けられた情報である。
ユーザID401は、通信システム1上で各ユーザを一意に識別するための識別情報であり、図3に示すユーザID301と同じ内容の情報である。
機種情報402は、ユーザID401に対応するユーザが保持する端末の機種を示す情報であって、図3に示す機種情報303と同じ内容の情報である。
利用日時403は、ユーザID401で示されるユーザが、対応する機種情報402で示される端末を利用して、メッセージングアプリケーションを利用した日時を示す情報である。メッセージングアプリケーションは、一日の最初にメッセージングアプリケーションを開いたとき(起動したとき、複数のアプリを並列起動しておいたものの中からメッセージングアプリケーションを選択して表示したとき)に、メッセージングアプリケーションが開かれたことを示す情報を、ユーザが利用している端末の機種を示す機種情報とともに送信されたものを取得することで得られる。
利用履歴情報400があることにより、ユーザがいつからいつまで同じ機種を利用していたかを特定することができる。図4に示す例で言えば、ユーザID401が「U0092801」で示されるユーザは、メッセージングアプリケーションを「2017/2/8」から利用しており、そのとき利用していた端末は「kphone」である。図4の、同ユーザの利用履歴情報によれば、「2017/11/19」から「2017/11/20」の間で、機種情報が「kphone」から「Galactic 8」に変化をしており、メッセージングアプリケーションを使用している端末が変更されたことが理解できる。したがって、このユーザがこのタイミングで、機種変更を行ったと理解できる。また同様に、「2018/9/16」から「2018/9/17」の間で、機種情報が「Galactic 8」から「Galactic 9」に変化していることから、ここでも機種変更を行ったと理解できる。よって、同ユーザは、メッセージングアプリケーションを利用し始めてから、約9ヶ月で最初の機種変更を行い、その約9か月後に再度機種変更を行っていることになる。また、このユーザが、「Galactic 9」に機種を変更してから、更なる機種の変更を行っていない場合には、現在日時から、「Galactic 9」に切り替えた日付けの「2018/9/17」を減じることで、「Galactic 9」の利用期間を算出することができる。
なお、図4に示す利用履歴情報400の利用日時403は、図3に示すユーザ情報300に含まれてもよい。即ち、ユーザ情報300と利用履歴情報400とは一つのデータベースとして構成されてもよい。また、契約態様の変更の可能性を推定する場合には、利用履歴情報400は、機種情報402に代えて、契約情報を保持した利用履歴情報を用いてもよいし、そうでなくてもよい。契約情報は、図3に示す契約情報304と同様の情報であり、利用情報に含まれる情報であってもよいし、そうでなくてもよい。契約情報について内容の変化があった場合に、通信事業者の変更あるいは通信プランの変更が行われたと推定することができる。
<動作>
まず、ユーザが機種変更を行うかどうかを判定するための判断材料となる情報の収集のための処理について、図5~図7を用いて説明する。図5は、通信システム1における端末20とサーバ10との間のやり取りの例を示すシーケンス図である。図5に示すやり取りは、ユーザが端末20を利用してメッセージングアプリケーションをインストールする際のやり取りを示している。なお、メッセージングアプリ―ションをすでにインストールしている端末20であれば、以下のステップS501~S503の処理は不要であり、省略してもよいし、しなくてもよい。
図5に示すように、端末20は、ユーザの指示に基づき、メッセージアプリケーションのインストーラを要求する要求情報をサーバ10に送信する(ステップS501)。
サーバ10は、端末20からのメッセージングアプリケーションのインストーラの要求を受け付けて、当該インストーラを、端末20に送信する(ステップS502)。
端末20は、サーバ10からメッセージングアプリケーションのインストーラを受信すると、ユーザの指示にしたがって、メッセージングアプリケーションのインストールを実行する(ステップS503)。
端末20は、メッセージングアプリケーションを起動し、ユーザに関する情報を含むユーザ情報をサーバ10に送信する(ステップS504)。なお、ユーザ情報の送信は、メッセージングアプリケーションをインストールする際のユーザ登録のタイミングで行われてもよいし、行われなくてもよい。
サーバ10は、端末20から受信したユーザの情報を、ユーザ情報300に登録する(ステップS505)。そして、サーバ10は、ユーザがメッセージングアプリケーションの利用を開始したことを示す情報として、現在日時の情報とユーザの端末の機種情報とを、利用期間情報に登録する(ステップS506)。
端末20は、日付が変更されるごとに、メッセージングアプリケーションを起動したタイミングで、利用情報をサーバ10に送信する(ステップS507)。
サーバ10は、端末20から利用情報を受信すると、利用履歴情報400に、利用情報で示される機種情報と、利用情報を受信した受信日時を利用日時403として、登録し、利用履歴情報400を更新する(ステップS508)。このように、ユーザがメッセージングアプリケーションを利用することで、ユーザが利用している機種の利用期間を示す情報の代替として、利用履歴情報400を作成、更新することができる。
図6は、図5に示すやり取りを実現するための端末20の動作例を示すフローチャートである。なお、上述と同様に、メッセージングアプリ―ションをすでにインストールしている端末20であれば、以下のステップS601、S602の処理は不要であり、省略してもよいし、しなくてもよい。
図6に示すように、端末20は、入出力部23に対するユーザからの入力にしたがって、メッセージングアプリケーションのインストーラを要求するための要求情報と、通信I/F22を介して、サーバ10に送信する(ステップS601)。この要求情報に応じて、サーバ10からは、メッセージングアプリケーションのインストーラを送信される。
端末20の通信I/F22は、サーバ10から送信されたメッセージングアプリケーションのインストーラを受信し、制御部121に送信する。制御部21は、ユーザからの入出力部23に対する入力に従って、メッセージングアプリケーションのインストーラを実行する(ステップS602)。
端末20は、通信I/F22を介して、サーバ10にユーザに関するユーザ情報を送信する(ステップS603)。このユーザ情報の送信は、前述の通り、ユーザがメッセージングアプリケーションを使用するためにサーバ10に対してユーザ登録をすることによる送信であってもよいし、メッセージングアプリケーションの最初の起動時の送信であってもよい。このユーザ情報には、メッセージングアプリケーションでユーザが利用する名前及びユーザの端末20の機種情報を含む。ユーザ情報には、その他に、ユーザの属性として、ユーザの年齢や性別、嗜好などの情報が含まれてもよいし、含まれなくてもよい。
制御部11は、メッセージングアプリケーションを実行したか否かを判定する(ステップS604)。ここでいう実行とは、メッセージングアプリケーションが起動されていない状態から起動すること、元々起動されていたメッセージングアプリケーションを表示状態にすることとの両方の場合を含む。メッセージングアプリケーションを実行していない場合は(ステップS604のNO)、メッセージングアプリケーションが実行されるまで待機する。
メッセージングアプリケーションを実行している場合は(ステップS604のYES)、制御部11は、そのメッセージングアプリケーションの実行が一日の中での最初の実行かどうかを判定する(ステップS605)。一日の中での最初の実行でない場合には(ステップS605のNO)、ステップS604の処理に戻る。
メッセージングアプリケーションの実行が一日の中での最初の実行である場合には(ステップS605のYES)、端末20の制御部11は、メッセージングアプリケーションを利用していることを示す情報として、ユーザIDと、端末20の機種を示す機種情報とを含む利用情報を、通信I/F22を介してサーバ10に送信して(ステップS606)、ステップS604の処理に戻る。なお、図6に示す構成では、端末20は、一日に一回利用情報をサーバ10に送信する構成としているが、利用情報は、メッセージングアプリケーションを実行する都度送信する構成としてもよいし、そうでなくてもよい。この場合には、ステップS604の処理を省略することができる。また、利用情報は、端末20からサーバ10に定期的に送られればよく、一日である必要はなく、半日に一回でもよいし、そうでなくてもよい。また、あるいは、前回利用情報を送信してから所定時間(限定ではなく一例として、6時間)が経過していれば、再度送信するという構成をとってもよい。
次に、図7を用いてサーバ10の動作例を説明する。図7は、図5に示すやり取りを実現するためのサーバ10の動作例を示すフローチャートである。なお、上述と同様に、メッセージングアプリ―ションをすでにインストールしている端末20であれば、以下のステップS701、S702の処理は不要であり、省略してもよいし、しなくてもよい。
図7に示すように、サーバ10の制御部11は、通信I/F14を介して、ユーザの端末20からメッセージングアプリケーションのインストーラを要求する要求情報を受信しているか否かを判定する(ステップS701)。メッセージングアプリケーションのインストーラを要求する要求情報を受信していた場合には(ステップS701のYES)、制御部11は、メッセージングアプリケーションのインストーラを読み出して、通信I/F14を介してユーザの端末20に、メッセージングアプリケーションのインストーラを送信し(ステップS702)、処理を終了する。
一方、メッセージングアプリケーションのインストーラを要求する要求情報ではなく(ステップS701のNO)、メッセージングアプリケーションを利用するユーザの端末20からユーザ情報を受信していた場合には(ステップS703のYES)、制御部11の登録部112は、受信したユーザ情報が示す内容をユーザ情報300に登録するとともに、そのユーザについての利用履歴情報を作成して(ステップS704)、処理を終了する。
また、メッセージングアプリケーションを利用するユーザの端末20から、ユーザ情報ではなく(ステップS703のNO)、利用情報を受信した場合には(ステップS705のYES)、登録部112は、利用情報で示されるユーザIDで示されるユーザの利用履歴情報400に、受信した利用情報で示される機種情報と利用日時とを、それぞれ、機種情報402と利用日時403に追加登録して、利用履歴情報を更新し(ステップS706)、処理を終了する。
次に、図8~図10を用いて、機種変更を行いそうな端末を特定して広告を送信する処理について説明する。図8は、サーバ10と端末20との間のやり取りの例を示すシーケンス図である。
図8に示すように、サーバ10は、広告情報の送信要求を受け付ける(ステップS801)。サーバ10は、限定ではなく一例として、サーバ10のオペレータから、記憶部15に記憶されている広告情報の送信要求を受け付けることとしてもよいし、そうでなくてもよい。あるいは、サーバ10は、限定ではなく一例として、外部の装置(限定ではなく一例として、広告を配信したい広告主の端末)から、広告情報の送信要求を受け付けることとしてもよいし、そうでなくてもよい。
サーバ10は、広告情報の送信要求を受け付けると、各ユーザについて、機種変更のタイミングかどうかを推定する(ステップS802)。そして、広告送信部114は、機種変更のタイミングであると推定されたユーザの端末20に、広告情報を送信する(ステップS803)。
端末20は、広告情報を受信すると、受信した広告情報を表示する(ステップS804)。
図9は、図8に示すやり取りを実現するためのサーバ10の動作例を示すフローチャートである。
図9に示すように、広告送信部114は、広告情報の送信要求を受け付ける(ステップS901)。広告情報の送信要求は、入出力部12を介したサーバ10のオペレータにより入力されてもよいし、広告を送信したいと考えている他のユーザのサーバ等の情報処理装置から通信I/F14を介して受け付けることとしてもよい。
制御部11の推定部113は、機種変更のタイミングが到来している可能性の高いユーザを推定する(ステップ902)。限定ではなく一例として、推定部113は、利用履歴情報400を参照して、ユーザが機種変更を行う周期を特定し、その周期の変わり目に来ている場合に、機種変更をする可能性が高いと推定することができる。また、推定部113は、限定ではなく一例として、現在の携帯電話機(スマホ)のキャリアとの契約は基本的には2年を単位にしていることが多いことから、最後に機種変更をしたとき、または、最初にメッセージングアプリケーションをインストールしたとき、から2年が近づいていれば、機種変更をする可能性が高いと推定することができる。推定部113は、機種変更をする可能性が高いと推定したユーザの情報を広告送信部114に送信する。なお、ここでは、推定部113は、機種変更をする可能性が高いとユーザを推定する例を示しているが、これは、契約の態様を変更する可能性が高いユーザを推定するものであってもよいし、そうでなくてもよい。
広告送信部114は、推定部113から伝達されたユーザの情報に基づく各ユーザの端末20に、ステップS901で受け付けた広告情報を、通信I/F14を介して、送信し(ステップS903)、処理を終了する。
図10は、図8に示すやり取りを実現するための端末の動作例を示すフローチャートである。
図10に示すように、端末20の通信I/F22は、サーバ10から、広告情報を受信する(ステップS1001)。通信I/F22は、受信した広告情報を制御部21に送信する。
制御部21の表示処理部212は、受信した広告情報を、表示部24に表示し(ステップS1002)、処理を終了する。なお、広告情報の表示は、メッセージングアプリケーションのトークルーム上への表示であってもよいし、そうでなくてもよい。
<推定処理の変形例1>
上記実施形態では、ユーザの機種変更の周期や契約期間に基づいて機種変更、または契約態様を変更する可能性が高いユーザを特定する例を示したが、その他の手法を使って特定することでもできる。本変形例1では、学習モデルを用いてユーザが機種変更をする可能性が高いかを推定する手法について説明する。
変形例1に係る学習モデルは、サーバ10の学習部115により生成されたものであってもよいし、外部の装置により生成されたものを記憶部15に記憶したものであってもよい。ここでいう学習モデルは、機種変更を推定するための学習モデルである場合には、少なくともユーザが同じ機種の端末を利用している利用期間と、機種変更と、の関係を学習したモデルであり、利用期間の他に、ユーザの属性と併せて、機種変更との関係を学習したモデルであってよい。また、学習モデルは、契約態様の変更を推定するための学習モデルである場合には、少なくともユーザが同じ契約を継続した利用期間と、契約変更と、の関係を学習したモデルであり、利用期間の他に、ユーザの属性と併せて契約態様の変更との関係を学習したモデルであってよい。また、学習モデルは、機種変更と契約態様の変更の双方を推定するための学習モデルであってもよく、その場合に、少なくともユーザの利用期間(ここでいう利用期間は、同じ機種を利用し続けた期間か同じ契約を継続した期間かのいずれかとなる)と、機種変更または契約態様の変更との関係を学習したモデルであってよい。
図11(a)は、学習モデルを生成するために用いる教師データ1100のデータ構成例を示すデータ概念図である。
図11(a)に示すように、教師データ1100は、ユーザID1100と、性別1102と、年代1103と、利用期間1104と、CVフラグ1105とが対応付けられた情報であり、図11(a)に示す教師データ1100の各行が1つの教師データである。所定数以上(限定ではなく一例として、100以上であるがこれに限定するものではない)の教師データがあれば学習モデルを生成することができる。教師データの数が多ければ多いほど、推定精度の高い学習モデルを生成することができる。
ユーザID1100は、図3に示すユーザ情報300のユーザID301と同様の情報である。なお、ユーザID1100は、学習用の教師データとしては不要の情報であり、なくともよい。
性別1102は、ユーザID1100に対応するユーザの性別を示す情報である。
年代1103は、ユーザID1100に対応するユーザの年代を示す情報である。年代1103は、ユーザ情報300の年代305に示される年代から導出される情報である。なお、ここでは年代として5歳区切りの情報としているが、これはその限りではなく、10歳区切りとしてもよいし、年齢そのものでもよい。
利用期間1104は、ユーザID1100に対応するユーザが同じ機種を利用している利用期間又は同じ契約態様を継続している利用期間の長さを示す情報である。
CVフラグ1105は、コンバージョン、即ち、機種変更又は契約態様の変更を行ったか否かを示す情報であり、図11(a)では、「0」、「1」で機種変更又は契約態様の変更を行ったか否かを示しており、ここでは、「0」は機種変更又は契約態様の変更をしていないことを意味し、「1」は機種変更又は契約態様の変更をしていることを意味することとするが、これは逆であってもよい。CVフラグ1105は、学習における所謂ラベルに相当する。なお、学習モデルとして機種変更と契約態様の変更の双方を学習する場合には、CVフラグ1105は、「0」で何の変更も行っていないことを示し、「1」で機種変更を行ったことを示し、「2」で契約態様の変更を行ったことを示すようにして学習を行うとよい。
学習モデルは、性別1102、年代1103、利用期間1104などのユーザの属性を示す情報と、機種変更をしたかどうかを示すCVフラグ1105との関係を学習したモデルとなる。なお、図11(a)に示す性別1102や年代1103は必須ではなく、また、その他の情報として、ユーザの嗜好を示す情報が含まれていてもよい。
図11(b)は、推定結果の一例である推定結果情報1110を示している。ここでは、機種変更を行うかどうかの推定結果の例を示しているが、これは、通信の契約態様の変更を行うかどうかの推定結果の場合も同様である。推定部113は、入力として、機種変更を行うかどうかを推定する対象のユーザの属性を示す情報として、ユーザの年齢や性別、嗜好などの情報を、学習モデルに入力し、推定結果を得る。推定部113は、限定ではなく一例として、各ユーザが機種変更を行う可能性があるかどうかをパーセンテージで出力する。図11(b)に示すように、推定部113は、入力したユーザごとに、その推定結果を出力する。そして、出力したパーセンテージが、所定の閾値(限定ではなく一例として80%)を超えている場合に、機種変更を行うと推定する。なお、推定部113は、教師データとして入力したユーザの属性全ての属性を入力として用いる必要はなく、その一部のみの入力であってもよい。
推定結果情報1110は、ユーザID1111と、CV確率1112と、が対応付けられた情報である。
ユーザID1111は、メッセージングアプリケーションを利用するユーザを一意に識別する識別情報であり、図3に示すユーザID301に相当する。なお、ユーザを一意に特定できるのであれば、ユーザID1111として、図3に示すユーザ名302が用いられてもよい。
CV確率1112は、ユーザID1111で示されるユーザが、現在、機種変更を行う可能性をパーセンテージで示した情報である。なお、ここではパーセンテージで示しているが、これは、パーセンテージによる区切り(限定ではなく一例として、0~19、20~39、40~59、60~79、80~100)で区分けして、「極低」、「低」、「中」、「高」、「極高」というように表現されてもよいし、単に、機種変更の可能性を、「有」、「無」の2値で表現することとしてもよい。
図12は、サーバ10の学習部115による学習処理の動作例を示すフローチャートである。図12では、機種変更を行う可能性を推定するための学習モデルを生成する例を示すが、これは、契約態様の変更を行う可能性を推定するための学習モデルを生成する場合も同様であり、また、機種変更を行う可能性と契約態様の変更を行う可能性の双方を推定する場合の学習モデルの場合も同様である。
図12に示すように、学習部115は、教師データとして、ユーザの情報に、機種変更を行ったかどうかを示す機種変更情報、即ち、CVフラグ1105を対応付けたデータの入力を受け付ける(ステップS1201)。即ち。図11に示す教師データ1100の入力を受け付ける。
学習部115は、受け付けた教師データを用いて、ユーザの情報、少なくともユーザが同じ機種を使用している利用期間と、機種変更との関係を学習し、学習モデルを生成する(ステップS1202)。学習に用いるアルゴリズムは既存のアルゴリズムを用いることとしてよい。
学習部115は、学習により生成した学習モデルを記憶部15に記憶し(ステップS1203)、処理を終了する。
次に、学習モデルを利用したユーザが機種変更を行う可能性があるかどうかを推定する推定処理について、図13を用いて説明する。図13は、サーバ10の推定部113の動作例を示すフローチャートである。
図13に示すように、推定部113は、機種変更を行う可能性があるかどうかを知りたいユーザそれぞれについてのユーザの情報を記憶部15に記憶されているユーザ情報300から取得する(ステップS1301)。なお、ここで推定部113が取得するユーザの情報は、ユーザ情報300に含まれる全ての情報であってもよいし、一部のユーザの情報のみであってもよい。一部のユーザは、所定の条件を満たすユーザであってよく、所定の条件はサーバ10のオペレータにより指定されることとしてもよいし、広告を配信する広告主により指定されることとしてもよい。所定の条件とは、限定ではなく一例として、性別であったり、年代であったりしてよい。
推定部113は、記憶部15から、ユーザ情報、即ち、ユーザの属性と、機種変更との関係を学習した学習モデルを用いて、機種変更の可能性を推定する(ステップS1302)。即ち、推定部113は、記憶部15から取得したユーザ情報300に含まれるユーザ各々について、そのユーザの性別や年代、嗜好などの嗜好情報を、学習モデルに入力し、機種変更を行う可能性があるかどうかの情報の出力を得る。
推定部113は、推定した機種変更の可能性を示す推定結果情報1110を出力する(ステップS1303)。推定部113は、推定した各ユーザについての機種変更の可能性を示す推定結果情報を広告送信部114に送信し、処理を終了する。
広告送信部114は、推定部113により機種変更の可能性が高いと推定されたユーザに対して広告を送信する。
このように、推定部113は、ユーザの属性と、機種変更との関係を学習した学習モデルを用いて、広告を送信するその時々で、ユーザが機種変更を行うかどうかを推定することができる。
<推定処理の変形例2>
上記変形例1では、広告を送信するタイミングで、各ユーザが機種変更をする可能性が高いかどうか又は契約態様の変更を行う可能性が高いかどうかを推定する例を示した。本変形例2では、ユーザがいつ機種変更をする又は契約態様を変更する可能性が高いかを推定することで、広告情報を送信するタイミングを特定する例を説明する。
図14(a)は、学習に用いる教師データのデータ構成例を示すデータ概念図である。図14(a)に示す教師データ1400は、ユーザID1401と、性別1402と、年齢1403と、利用期間1404と、が対応付けられた情報である。図14(a)に示す教師データ1400は、図11に示した教師データ1100と基本的に同様の構成を有し、CVフラグ1105の有無において相違する。それぞれのデータの内容は、教師データ1100と同様であるので説明を省略する。
一方で、本変形例2の場合、利用期間1404が、所謂教師データにおけるラベルとして機能する。ただし、この利用期間1404は、ユーザID1401で示されるユーザが機種変更を実行したとき、又は、契約態様の変更を行ったときに、それまで使用していた端末の利用期間または同じ契約態様を継続した利用期間を示している。したがって、図14(a)に示す教師データを用いて学習モデルを作成した場合、ユーザについて、どのぐらいの利用期間で機種変更又は契約態様の変更を行う可能性があるか、その利用期間を推定することができる学習モデルとなる。
図14(a)の例では、ユーザID1401が、「U0092802」で示されるユーザは、「男」であり、その年代は「10-14」であり、「23ヶ月」で機種を変更したこととなっている。
図14(b)は、教師データ1400を用いて作成された学習モデルを用いた推定処理を行った場合の出力例としての推定結果情報1410を示している。図14(b)に示すように、推定結果情報1410は、ユーザID1411と、推定期間1412と、が対応付けられた情報である。
ユーザID1411は、メッセージングアプリケーションを利用するユーザを一意に識別する識別情報であり、図3に示すユーザID301に相当する。なお、ユーザを一意に特定できるのであれば、ユーザID1411として、図3に示すユーザ名302が用いられてもよい。
推定期間1412は、ユーザID1411で示さえるユーザが、どの程度の利用期間で機種変更または契約態様の変更を行う可能性がある期間を示す情報である。即ち、最後に機種変更又は契約態様の変更を行った、若しくは、はじめてメッセージングアプリケーションをインストールしてから、次に機種変更を行うまでの期間(推定された期間)を示す情報である。
図14(b)によれば、ユーザID1411が「U0092810」で示されるユーザは、「26ヶ月」で機種変更又は契約態様の変更を実行する可能性が高いと推定されている。
<推定処理の変形例3>
上記変形例1、2では、学習モデルを用いた推定の例を示したが、本変形例3では、学習モデルとは異なる推定を行う例を示す。即ち、変形例3では、各ユーザが通信事業者と契約している通信プランから、機種変更の可能性を推定する。
図15は、各通信事業者の通信プランに関する契約情報1500のデータ構成例を示すデータ概念図である。
契約情報1500は、事業者情報1501と、プラン情報1502と、基本契約期間1503と、が対応付けられた情報である。
事業者情報1501は、電気通信事業者又は仮想移動体通信事業者を一意に特定可能な識別情報である。
プラン情報1502は、対応する事業者情報1501で示される通信事業者がユーザに提供可能なプランを識別するための識別情報である。なお、プランとは、電気通信事業者又は仮想移動体通信事業者が提供する通信サービスを利用するにあたっての条件のことであり、限定ではなく一例として、所定期間毎の利用料金や、通信速度、通信可能なデータ量などの条件が含まれてよい。
基本契約期間1503は、対応する事業者情報1501で示される通信事業者の、対応するプラン情報1502で示されるプランの内容で契約した場合に、定型される契約の基本契約期間の長さを示す情報である。
また、図示はしていないが、本変形例3の場合、ユーザ情報300には、各ユーザについて、契約している通信事業者の情報、および、その通信事業者と契約しているプランを特定可能なプラン情報が含まれる。
これにより、推定部113は、ユーザの通信事業者と通信プランを特定することで、その基本契約期間を特定し、最後に機種変更又は契約態様の変更を行った日付け、もしくは、メッセージングアプリケーションをインストールした日付けからの経過日数が、基本契約期間が終了する間際かどうかで、機種変更を行う可能性又は契約態様の変更を行う可能性があるかを推定することができる。
以下、図16を用いて、契約情報1500を用いた機種変更を行う可能性があるユーザの推定処理について説明する。図16は、サーバ10の制御部11の動作例を示すフローチャートである。
図16に示すように、制御部11の推定部113は、記憶部15からユーザ情報を取得する(ステップS1601)。推定部113は、取得したユーザ情報から、メッセージングアプリケーションをインストールした日、又は、最後に機種変更を行った日、又は、最後に契約態様の変更を行った日のうち、現在に近い方の日にちを特定する(ステップS1602)。
推定部113は、記憶部15が取得したユーザ情報の中から、ユーザが契約している通信事業者とそのプランとを特定する。そして、特定した事業者情報とプランから、契約情報1500を参照して、基本契約期間を特定する(ステップS1603)。
推定部113は、特定した基本契約期間の終了まで所定日数以内であるか否かを判定する(ステップS1604)。即ち、取得したユーザ情報で示されるユーザの利用履歴情報400を参照して、メッセージングアプリケーションをインストールした日、もしくは、最後に機種変更を行った日に、基本契約期間を加算した日が、現在から見て、所定日数以内に迫っているかどうかを判定する。
基本契約期間終了まで所定日数以内であると判定した場合には(ステップS1604のYES)、推定部113は、ユーザ情報を広告送信部114に送信する。そして、広告送信部114は、受信したユーザ情報で示されるユーザに広告情報を、通信I/F14を介して、送信し(ステップS1605)、処理を終了する。基本契約期間終了まで所定日数以内ではないと判定した場合には(ステップS1604のNO)、そのまま処理を終了する。
なお、上記実施形態、変形例1~3に示した推定手法は、適宜組み合わせて用いてもよい。ここでいう推定手法を組み合わせて用いるとは、それぞれの推定手法を用いて推定を行い、その推定結果を統合して、推定結果を出力することをいう。推定結果を統合するとは、限定ではなく一例として、変形例1に示した学習モデルによる推定結果と、変形例3に示した推定結果と、のうちのいずれかが機種変更又は契約態様の変更を行う可能性があると推定されたら、機種変更又は契約態様の変更を行うと推定するものとしてもよい。
また、あるいは、限定ではなく一例として、変形例1に示した推定による推定結果が70%であったとして、変形例3に示した推定結果も機種変更を行う可能性があると推定された場合に、所定の重み値を加算する、あるいは、係数を乗じて、70%の推定結果を、限定ではなく一例として80%に引き上げて、その結果から機種変更又は契約態様の変更を行う可能性があるかを推定することとしてもよい。また、このとき、逆に、変形例3の推定結果が機種変更を行う可能性又は契約態様の変更を行う可能性がないとなった場合に、所定の重み値を減算する、あるいは、1以下の係数を乗じることとしてもよい。また、機種変更の可能性のみを推定することとしてもよいし、契約態様の変更の可能性のみを推定することとしてもよいし、双方を推定することとしてもよい。
<広告の送信例>
ここでは、メッセージングアプリケーションを利用するユーザに広告情報を送信する例として、企業等のオフィシャルアカウントを利用した広告配信の例を説明する。図17は、通信システム1における各装置間のやり取りの例を示すシーケンス図である。なお、オフィシャルアカウントとは、メッセージングアプリケーションにおいて、所定の団体や、企業、個人が、不特定多数のユーザに対して、情報を発信するために用いられるアカウントであり、ユーザがオフィシャルアカウントに登録(友だちとして追加)することで、ユーザとオフィシャルアカウントとの間のトークルームが開設される。この開設されたトークルームを介して、団体や企業は、ユーザに情報(主として宣伝広告)を発信する。なお、ユーザがオフィシャルアカウントに登録していなくとも、団体や企業は、オフィシャルアカウントから各ユーザに広告情報を送信できてもよい。ここでは、機種変更を行う可能性が高いユーザに広告情報を送信する例を説明するが、これは、契約変更を行う可能性が高いユーザに送信するものであってもよい。
図17に示すように、企業等に配される企業サーバ50から、企業サーバ50のオフィシャルアカウントに対して、広告情報が送信される(ステップS1701)。
サーバ10は、広告情報を受信すると、上記実施形態、変形例1~3に示したように機種変更を行う可能性が高いユーザを推定する(ステップS1702)。そして、サーバ10は、機種変更の可能性が高いと推定されたユーザと、企業サーバ50との間のオフィシャルアカウントのトークルームに対して、ステップS1701で受信した広告情報を送信する(ステップS1703)。そして、端末20は、受信した広告情報をオフィシャルアカウントのトークルームに表示する(ステップS1704)。
なお、ステップS1701において、企業サーバ50は、送信する広告情報に、機種変更を行う可能性が高いユーザに対する広告であるかを示すフラグを付しておき、このフラグを付している場合に推定部113による機種変更の可能性が高いユーザを推定する処理を行い、このフラグが付されていない場合には、推定部113による機種変更の可能性が高いユーザを推定することなくオフィシャルアカウントのトークルームに広告情報を送信するように構成してもよい。
図18は、端末20が受信した広告情報の表示例を示す画面図である。ここでは、図17に示すやり取りの結果、企業サーバ50のオフィシャルアカウントのトークルームに、広告情報1800が表示されている例を示している。なお、広告情報1800の表示は、オフィシャルアカウントのトークルームではなく、他のトークルームで表示されてもよいし、サーバ10が配信する各種の情報(ニュース)の中の一つとして表示されてもよい。ここで、図18に示すように、広告情報1800は、機種変更に関連する広告であれば、より高い広告効果が見込める。限定ではなく一例として、機種変更に関連する広告は、新機種の案内であったり、新たな通信の契約プランの提示であったりしてよい。
ここで、端末に表示される広告情報には、ユーザにとって何らかの得となる特典情報が含まれてもよい。図18の例でいえば、広告情報で示される端末を購入する際の割引券(クーポン)であったり、購入により何等かのサービスを受けるために利用可能なポイントが受け取れるものであってもよい。
サーバ10は、広告情報を送信する際に、機種変更を行う可能性が高いユーザ全て又は契約態様を変更する可能性が高いユーザ全てに特典情報を付与して送信することにしてもよいし、しなくてもよい。即ち、推定部113が推定したユーザの一部のユーザにのみ特典情報を含む広告情報を送信することとしてもよい。また、その一部のユーザを選択する際の基準はどのようなものであってもよいが、限定ではなく一例として、ユーザが同じ機種を利用している利用期間又は同じ契約態様を継続している利用期間の長短によって定まるものであってもよく、また、利用期間の長さによって、異なる特典情報を含ませてもよい。また、利用期間が長ければ長いほど、ユーザにとってよりよい特典情報を含む広告情報を送信してもよい。即ち、ユーザが同じ機種を一定期間以上(限定ではなく一例として、2年以上)使用している、又は同じ契約態様を継続しているユーザには特典情報のある広告情報を送信し、端末を使用している利用期間又は同じ契約態様を継続している利用期間が、同一定期間を経過していないユーザには特典情報を含まない広告情報を送信することとしてもよい。また、あるいは、第1の一定期間以上(限定ではなく一例として1年以上)同じ機種を使用している又は同じ契約態様を継続しているユーザには、限定ではなく一例として一割引きの特典情報を含む広告情報を送信し、第1の一定期間よりも長い第2の一定期間以上(限定ではなく一例として3年以上)同じ機種を使用している又は同じ契約態様を継続しているユーザには、限定ではなく一例としてよりよい割引率の二割引きの特典情報を含む広告情報を送信することとしてもよい。
<実施形態の効果>
サーバ10は、ユーザの端末20から、メッセージングアプリケーションを利用している場合に、メッセージングアプリケーションを利用していることを示す利用情報を受信し、その利用履歴情報を記憶する。そして、サーバ10は、利用履歴情報を参照して、適切なタイミングで広告情報を送信する。
したがって、サーバ10は、ユーザがメッセージングアプリケーションを利用することにより取得できる利用履歴情報に基づいて、広告をうつことができる。
サーバ10は、メッセージングアプリケーションが起動されたユーザの端末20から、利用情報を取得し、蓄積する。利用情報には、ユーザの端末20の端末情報が含まれており、その変化があった場合に、サーバ10は、ユーザの端末について何らかの変化があったことを認識することができる。したがって、サーバ10は、現在日時から、メッセージングアプリケーションをインストールした日、または、端末について何らかの変化があった日を、減算することで、現在まで同じ状態で端末を利用している利用期間を特定することができる。
これにより、サーバ10は、ユーザが同じ状態で端末を利用している期間に基づいて、広告をうつことができる。
サーバ10が、ユーザの端末から受信する利用情報に含まれる端末に関する情報は、端末の機種、あるいは、ユーザが契約している通信事業者に関する情報であってよい。通信事業者とは、電気通信事業者、仮想移動体通信事業者の双方を少なくとも含む。よって、サーバ10は、利用情報に含まれる端末に関する情報が端末の機種に関する情報である場合には、ユーザが同じ機種の端末を利用している利用期間を特定できる。同様に、サーバ10は、利用情報に含まれる端末に関する情報が、通信事業者に関する情報である場合には、同じ電気通信事業者あるいは同じ仮想移動体通信事業者を利用し続けている利用期間を特定できる。
サーバ10は、これらの情報を利用することで、ユーザが同一機種の端末を利用している期間または同じ通信契約を継続している期間を特定することができる。したがって、サーバ10は、ユーザが機種変更あるいは契約態様の変更を行う可能性があるかどうかを推定することができ、そのようなタイミングにおいて効果的な広告をうつことができる。
また、サーバ10は、ユーザが同一の機種の端末を利用している期間が、予め定められた期間に近づいている場合に、機種変更を行う可能性が高いと推定して広告情報を送信することとしてもよい。
これにより、サーバ10は、予め定めた期間との比較により、ユーザが機種変更を行う可能性が高いか否かを推定することができる。
また、サーバ10は、予め定められた期間として、ユーザが契約しているキャリアのプランにより定まる基本契約期間に基づいて、ユーザが機種変更を行う可能性が高いかを推定することとしてもよい。
これにより、ユーザの基本契約期間の終わりに近づいている場合には、機種変更を行う可能性があるとして、ユーザに効果的に広告を提供することができる。
また、サーバ10は、利用履歴情報を用いることで、ユーザによる機種変更の周期を特定し、その周期に基づいて、ユーザが機種変更を行う可能性が高いか否かを推定することとしてもよい。
これにより、サーバ10は、周期的に機種変更を行うユーザに対して、効果的に広告情報を送信することができる。
また、サーバ10が送信する広告情報は、機種変更に関する情報であってよい。
これにより、機種変更を行う可能性が高いユーザにとって効果が高いと見込まれる広告情報を送信することができる。
また、サーバ10は、ユーザの属性と、ユーザが同一の機種を利用している利用期間との関係を学習した学習モデルを用いて、ユーザの属性を入力することで、ユーザが機種変更を行う可能性を推定することができる。
これにより、サーバ10は、ユーザが同一の機種を使用している利用期間だけでなく、ユーザの各種の属性(限定ではなく一例として、年齢や性別など)を用いることで、より精度よく、機種変更を行う可能性を推定することができる。
また、サーバ10は、企業サーバ50から送信された広告情報を、企業サーバ50と送信先のユーザとの間のオフィシャルアカウントのトークルームに送信することとしてもよい。
これにより、企業サーバ50は、自社の広告を、ユーザが機種変更を行う可能性が高いタイミングで、ユーザに送付することができ、自社にとって得となる宣伝広告を行うことができる。