JP2018190468A - 算出装置、算出方法及び算出プログラム - Google Patents

Abstract

【課題】架電に対してユーザとの通話が成立する可能性を精度よく判定すること。【解決手段】本願に係る算出装置は、取得部と、判定部とを有する。取得部は、ユーザが利用する端末における利用状況を取得する。判定部は、取得部によって取得された利用状況と、架電に対するユーザの通話の可能性との関係性に基づいて、所定のタイミングにおけるユーザの通話の可能性スコアを算出する。例えば、取得部は、利用状況として、端末の位置情報を取得する。判定部は、位置情報に基づいて、ユーザの通話の可能性スコアを算出する。【選択図】図１

Description

本発明は、算出装置、算出方法及び算出プログラムに関する。

ユーザに提供されるサービスには、ユーザが電話に出るか否かによって、サービスの効率が変わるものがある。例えば、電話による通話を介して本人確認を行うことを条件とするようなサービスでは、ユーザが電話に出ない限りサービスの提供を行うことができず、不都合が生じ得る。また、サービス以外であっても、例えば電話で営業を行う事業者にとっては、架電に対してユーザとの通話が成立する可能性（以下、「通話可能性」と称する）が高いユーザに優先的に電話を掛けた方が、効率良く事業を進めることができる。

ここで、電話を掛ける処理（架電処理）を支援する技術として、電話を受けるユーザの要望を示した要望情報を受信しておき、受信した情報に基づいて呼制御を行う技術が提案されている。

特開２０１５−６９５３５号公報

しかしながら、上記の従来技術では、架電に対してユーザとの通話が成立する可能性を精度よく判定することは難しい。例えば、上記の従来技術では、架電されるタイミングに関する要望を予めユーザから受け付けることを要する。このため、上記の従来技術では、例えば、要望を受け付けていないユーザとの通話可能性を判定することや、リアルタイムに変化する状況に応じて通話可能性を判定することは難しい。

本願は、上記に鑑みてなされたものであって、架電に対してユーザとの通話が成立する可能性を精度よく判定することができる算出装置、算出方法及び算出プログラムを提供することを目的とする。

本願に係る算出装置は、ユーザが利用する端末における利用状況を取得する取得部と、前記取得部によって取得された利用状況と、架電に対するユーザの通話の可能性との関係性に基づいて、所定のタイミングにおける当該ユーザの通話の可能性スコアを算出する判定部と、を備えたことを特徴とする。

実施形態の一態様によれば、ユーザの通話可能性を精度よく判定することができるという効果を奏する。

図１は、実施形態に係る判定処理の一例を示す図である。 図２は、実施形態に係る判定処理システムの構成例を示す図である。 図３は、実施形態に係る判定装置の構成例を示す図である。 図４は、実施形態に係る属性テーブルの一例を示す図である。 図５は、実施形態に係るセンサテーブルの一例を示す図である。 図６は、実施形態に係るサービステーブルの一例を示す図である。 図７は、実施形態に係る定義テーブルの一例を示す図である。 図８は、実施形態に係る学習データテーブルの一例を示す図である。 図９は、実施形態に係るモデルテーブルの一例を示す図である。 図１０は、実施形態に係る架電態様記憶部の一例を示す図である。 図１１は、実施形態に係るユーザ端末の構成例を示す図である。 図１２は、実施形態に係る処理手順を示すフローチャート（１）である。 図１３は、実施形態に係る処理手順を示すフローチャート（２）である。 図１４は、実施形態に係る処理手順を示すフローチャート（３）である。 図１５は、判定装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願に係る判定装置、判定方法及び判定プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る判定装置、判定方法及び判定プログラムが限定されるものではない。また、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．判定処理の一例〕
まず、図１を用いて、実施形態に係る判定処理の一例について説明する。図１は、実施形態に係る判定処理の一例を示す図である。図１では、本願に係る判定装置１００によって、ユーザが所有する端末の利用状況と、架電に対してユーザが通話を行う可能性である通話可能性との関係性に基づいて、所定のタイミングにおける当該ユーザの通話可能性を判定する処理が行われる例を示す。

図１に示す判定装置１００は、ユーザに利用される端末（図１の例では、ユーザ端末１０）の利用状況を取得し、取得した利用状況とユーザの通話可能性との関係性に基づいて、所定のタイミングにおけるユーザの通話可能性を判定する処理を行うサーバ装置である。

図１に示すユーザ端末１０は、ユーザに利用されるスマートフォン等の情報処理端末である。また、図１に示すユーザＵ０１は、顧客に架電を行う者（以下、「架電業者」と称する）にとっての架電対象者の一例である。図１に示す例では、ユーザ端末１０は、ユーザＵ０１によって利用されるものとする。なお、図１での図示は省略しているが、実施形態に係るユーザ端末１０は１台に限らず、複数台存在していてもよい。すなわち、ユーザＵ０１は、複数台のユーザ端末１０を所持していてもよい。なお、以下では、ユーザをユーザ端末１０と読み替える場合がある。例えば、「ユーザＵ０１が判定装置１００にアクセスする」という記載は、実際には、「ユーザＵ０１が利用するユーザ端末１０が判定装置１００にアクセスする」という状況を示す場合がある。

なお、実施形態において、ユーザ端末１０の利用状況とは、例えばユーザ端末１０によって検知（センシング）されるセンシング情報や、ユーザ端末１０に対するユーザの操作に関する情報や、ネットワークを介してユーザに提供されるサービスの利用履歴等を含む。

また、ネットワークを介してユーザに提供されるサービスとは、例えば、インターネット等のネットワークを介して提供される種々のウェブサービス等である。実施形態では、サービスは、ウェブサーバ等であるサービスサーバ３０（図１での図示は省略する）によって提供される。一例として、サービスサーバ３０は、ユーザからログインを受け付けた場合に、当該ユーザ向けにカスタマイズされたポータルサイトを提供するポータルサービスを提供する。また、サービスサーバ３０は、検索サービスや、ショッピングサービスや、オークションサービスや、情報提供サービス（例えば地図情報サービスや、ナビゲーションサービスや、ニュースサービスや、天気予報サービス）や、タスク設定やスケジュールを登録するカレンダーサービス等の各種サービスを提供してもよい。なお、実施形態に係るサービスサーバ３０は１台に限らず、複数台存在し、各々が異なるサービスを提供してもよい。また、ユーザ端末１０の利用状況には、サービスを利用する際にユーザＵ０１が送受信した情報や、サービスを利用する際のユーザＵ０１のコンテキスト（context）に関する情報を含む。また、サービスにおける利用状況には、サービスを利用する際にユーザＵ０１サービスに対して登録した属性情報（例えば、ユーザＵ０１の年齢や性別、居住地、職種、勤務先等）が含まれてもよい。

図１に示す架電業者装置５０は、ユーザに対して架電を行う事業者によって利用される情報処理装置である。例えば、架電業者装置５０は、顧客である各ユーザの通話可能性に関する情報を判定装置１００から取得し、取得した通話可能性に基づいて呼制御を行う。具体的には、架電業者装置５０は、通話可能性が高いユーザから優先的に架電するよう呼制御を行う。なお、架電業者には、例えば、電話で営業を行う事業者や、督促を行う事業者や、電話で本人確認を行う事業者など、種々の事業者が含まれてよい。なお、実施形態では、架電業者が、携帯電話機能を有するユーザ端末１０に対して架電を行う例を示すが、架電業者は、ユーザＵ０１が自宅に設置した固定電話や、ユーザＵ０１の勤務先に架電してもよい。

図１に示す例において、判定装置１００は、ユーザＵ０１の通話可能性を判定し、判定した結果を架電業者に送信する。すなわち、判定装置１００は、架電業者がユーザＵ０１に架電しようとする際に、ユーザＵ０１が通話に出るか否かを示す可能性を事前に通知したり、ユーザＵ０１よりも通話可能性の高い他のユーザの情報を通知したりする。これにより、判定装置１００は、円滑な架電処理を可能にする。以下、図１を用いて、判定装置１００による実施形態に係る判定処理の流れについて説明する。

図１の例において、ユーザＵ０１は、ユーザ端末１０を携帯し、様々な状況でユーザ端末１０を利用するものとする。例えば、ユーザＵ０１は、歩行中にユーザ端末１０を操作したり、通勤電車内でユーザ端末１０の画面を閲覧したりする。また、ユーザ端末１０は、ユーザＵ０１から操作されなくとも、例えば、自宅や会社の移動においてユーザＵ０１に携帯されることで、位置情報や加速度情報や傾き情報など、種々の情報を取得する。すなわち、ユーザ端末１０は、日常的にユーザＵ０１から利用されることで、ユーザ端末１０における利用状況を取得する（ステップＳ１１）。

判定装置１００は、例えば、ユーザ端末１０に対して利用状況の送信を要求する。そして、判定装置１００は、要求に応答したユーザ端末１０から、ユーザ端末１０の利用状況を取得する（ステップＳ１２）。判定装置１００は、取得した利用状況を利用状況記憶部１２１に格納する。なお、判定装置１００は、ユーザ端末１０がサービスを利用するためにアクセスしたサービスサーバ３０を介して、ユーザ端末１０の利用状況を取得してもよい。

判定装置１００は、ユーザＵ０１の通話可能性を判定するために用いられるあらゆる利用状況を取得する。

判定装置１００は、例えば、利用状況として、ユーザ端末１０の位置情報を取得する。これは、ユーザＵ０１が自宅に所在する場合には通話可能性が相対的に高く、ユーザＵ０１が勤務時間中に勤務先に所在している場合や、電車や飛行機などでの移動中には、通話可能性が相対的に低くなると推定されることから、位置情報が、通話可能性の判定要素に成り得るからである。

具体的には、判定装置１００は、ユーザ端末１０が有するＧＰＳ（Global Positioning System）機能によって取得された位置情報を、所定時間ごと（例えば１分ごと）に取得する。なお、判定装置１００が取得する位置情報は、ＧＰＳ機能によって取得される位置情報に限られず、例えば、任意の情報機器にアクセスしたユーザ端末１０のＩＰアドレス等から推定される位置情報であってもよい。また、位置情報は、経度や緯度を示す具体的な数値であってもよいし、所定の地域を示す住所情報等であってもよい。この場合、判定装置１００は、例えば、位置情報と住所情報とを関連付けるための定義データベース等を参照し、取得した位置情報から住所情報を特定する。

なお、実施形態において、判定装置１００は、ユーザＵ０１の自宅や勤務先等の位置を種々の手法により特定してよい。例えば、判定装置１００は、ユーザＵ０１が所定のサービスにおいて登録したユーザ情報（例えば、サービスに対する会員登録においてサービス側に提示する情報など）に基づいて、ユーザＵ０１の住所や勤務先を特定してもよい。あるいは、判定装置１００は、ユーザ端末１０から継続的に取得した位置情報において、早朝や夜間に頻繁に観測される位置情報が示す位置を自宅と推定し、ユーザＵ０１の自宅の位置を特定してもよい。また、判定装置１００は、平日昼間に頻繁に観測される位置情報が示す位置を勤務先と推定し、ユーザＵ０１の勤務先の位置を特定してもよい。

また、判定装置１００は、ユーザ端末１０に対するユーザＵ０１の物理的な動作を示す動作情報を取得してもよい。具体的には、判定装置１００は、ユーザ端末１０が検知する加速度情報や、傾き情報や、ユーザ端末１０に対する圧力情報等を取得する。そして、判定装置１００は、例えば、ユーザ端末１０がユーザＵ０１の手に触れていることや、ユーザＵ０１が片手でユーザ端末１０を持って画面を閲覧しているといった利用状況を取得する。

また、判定装置１００は、ユーザ端末１０をユーザＵ０１が操作中であるか否かを示す操作情報を取得してもよい。具体的には、判定装置１００は、ユーザＵ０１がユーザ端末１０のタッチパネルを操作していることや、ユーザ端末１０にインストールされた任意のアプリケーションプログラム（以下、「アプリ」と表記する）を起動させていることや、アプリを操作していること等の利用状況を取得する。

また、判定装置１００は、ユーザ端末１０の周辺の環境情報を取得してもよい。例えば、判定装置１００は、ユーザ端末１０が有する照度センサによって取得された照度情報を取得する。具体的には、判定装置１００は、照度情報に基づいて、ユーザ端末１０が外気に置かれているか、もしくは、ユーザの鞄やポケットの中に置かれているか、といった利用状況を取得する。

また、判定装置１００は、ユーザ端末１０が音楽を再生中であり、かつ、ユーザ端末１０に音声出力装置（例えばイヤホンなど）が接続されているか否かを示す接続情報を取得してもよい。

例えば、ユーザＵ０１がユーザ端末１０を手に持っていたり、音楽を聴いていたり、鞄の中にしまっていなかったりといった利用状況が取得される場合、ユーザＵ０１は、電話がかかってきた場合に、ユーザ端末１０が手元にない場合と比較して、通話を行うことができる可能性が高いと推定される。このように、判定装置１００は、ユーザ端末１０が検知する種々の利用状況を取得することによって、ユーザＵ０１が電話を受け易い状況であるか否かを判定要素として、ユーザＵ０１の通話可能性を判定する。

なお、判定装置１００は、ユーザ端末１０の利用状況として、ユーザ端末１０を介して利用するサービスに関する利用状況を取得してもよい。具体的には、判定装置１００は、飲食店や交通機関や宿泊施設等の予約サービスにおいて、ユーザＵ０１が予約を行ったスケジュール情報を取得する。また、判定装置１００は、利用状況として、ショッピングサービスにおいてユーザＵ０１が商品を購入したことや、当該商品の配送日時を指定したスケジュール情報を取得する。

例えば、ユーザＵ０１が交通機関等を予約した時間帯は、ユーザＵ０１は何らかの交通機関を利用中である可能性が高いため、ユーザＵ０１が架電に対して通話を行う可能性は相対的に低いと推定される。また、ユーザＵ０１が商品の配送日時を指定した時間帯は、ユーザＵ０１は、例えば配送業者の到着を待つため在宅していたり、配送業者からの電話を待ったりするため、架電に対して通話を行う可能性は相対的に高いと推定される。

さらに、判定装置１００は、利用状況として、サービスを利用する際のユーザ端末１０の通信状況等を取得してもよい。例えば、判定装置１００は、ユーザ端末１０が、ユーザＵ０１の自宅に設置されているＩｏＴ（Internet of Things）機器と、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の近距離通信を行っているという状況を取得する。この場合、ユーザＵ０１は、通話の可能性が比較的高いといえる。そして、在宅しているタイミングにおいては、ユーザＵ０１は、外出中よりも電話を受ける可能性が高いと推定される。このように、判定装置１００は、通話可能性を判定するために用いられる種々の利用状況を取得する。

また、判定装置１００は、曜日や時間帯ごとに対応付けて、ユーザ端末１０の利用状況を所定期間（例えば１ヶ月や１年間など）に渡って継続的に取得してもよい。判定装置１００は、継続的に利用状況を取得することにより、ユーザ端末１０の利用状況を、曜日や時間帯ごとに対応付けて蓄積することができる。

そして、判定装置１００は、取得した利用状況に基づいて、ユーザＵ０１の通話可能性を判定する（ステップＳ１３）。例えば、判定装置１００は、取得された利用状況とユーザＵ０１の通話可能性との関係性を定義付けるための定義が記述されたデータベース（図１の例では、「定義ファイル」と表記する）を保持する。定義ファイルの内容は、例えば判定装置１００の管理者等によって設定される。

定義ファイルでは、ユーザ端末１０の利用状況と通話可能性との関係性が定義される。具体的には、定義ファイルには、判定の対象となる時間において、ユーザ端末１０において特定の利用状況が観測される場合に、通話の可能性がどのくらいあるかといった指標値（スコア）が定義付けられる。例えば、図１の例では、定義ファイルには、ある利用状況が観測される場合のユーザの通話可能性が「−１００」から「１００」までのスコアで示されるとする。この例では、スコアが大きいほど、ユーザＵ０１の通話可能性が高いことを示している。また、判定装置１００は、判定の対象となる所定のタイミング（以下、「対象日時」と表記する場合がある）において、複数の利用状況が観測される場合には、かかるスコアを加算して、判定対象となるユーザの通話可能性を判定するものとする。また、詳細は後述するが、スコアは必ずしも固定されたものではなく、例えば学習によって動的に変化するものであってもよい。また、スコアは全ユーザに対して共通するものではなく、ユーザごとに動的に変化するものであってもよい。また、スコアは、あくまで通話可能性を相対的に示すものであり、数値そのものが絶対的な意味を有しなくてもよい。

一例として、定義ファイルには、対象日時において、ユーザ端末１０から取得された位置情報が、ユーザＵ０１の自宅の位置を示す位置情報と一致、もしくは所定範囲内（例えば、自宅から数メートル以内の範囲等）である場合には、ユーザＵ０１の通話可能性を示すスコアが「４０」である、といった定義が記述される。これは、対象日時においてユーザＵ０１が在宅している場合には、外出中や勤務中と比較して、ユーザＵ０１が架電に対して通話を行う可能性が相対的に高いと推定されることを示している。

なお、定義ファイルには、判定を行ったタイミングと、実際に架電を行うタイミングにずれが生じる場合、実際に架電を行うタイミングにおいて推定される利用状況に関するスコアが記述されていてもよい。例えば、定義ファイルには、対象日時から所定時間前における、ユーザ端末１０から取得された位置情報が、ユーザＵ０１の自宅の位置から所定範囲内（例えば、その所定時間後にユーザＵ０１が自宅まで帰宅可能であると推定される範囲）である場合には、ユーザＵ０１の通話可能性を示すスコアが「２０」である、といった定義が記述されてもよい。これは、対象日時においてユーザＵ０１は在宅していないものの、実際に架電を行うタイミングでは、ユーザＵ０１が在宅している可能性もあるため、その状況を加味したスコアが定義されていることを示している。なお、これらのスコアは、ユーザＵ０１が所在する位置に応じて変動してもよい。例えば、対象日時から所定時間前において、ユーザ端末１０から取得された位置情報が、ユーザＵ０１の自宅の位置から極めて遠方（例えば海外の国など）を示す位置情報であるとする。この場合には、ユーザＵ０１が、対象日時において架電に対して通話する可能性は極めて低いことから、定義ファイルでは、当該状況に対応するスコアを「−１００」と定義してもよい。

また、別の例として、定義ファイルには、対象日時において、ユーザＵ０１が飲食店や宿泊施設の予約などのスケジュール情報を登録している場合、その対象日時におけるユーザＵ０１の通話可能性を示すスコアが「−１０」である、といった定義が記述されてもよい。これは、対象日時が、ユーザＵ０１が飲食店等を予約した時間と重複しているのであれば、その対象日時には、ユーザＵ０１が架電に応答する可能性が比較的低いと推定されるからである。

また、別の例として、定義ファイルには、対象日時において、ユーザＵ０１がショッピングサービスを利用して購入した商品の配送を指定した場合、その対象日時におけるユーザＵ０１の通話可能性を示すスコアが「３０」である、といった定義が記述される。これは、対象日時が、ユーザＵ０１が配送を指定した時間と重複しているのであれば、その対象日時には、ユーザＵ０１が在宅であり、また、架電に応答する可能性が比較的高いと推定されることを示している。このように、判定装置１００は、ユーザ端末１０の利用状況と、ユーザＵ０１の通話可能性との関係性を示す複数の定義を保持する。

そして、判定装置１００は、これらの定義ファイルに基づいて、判定対象とする時間におけるユーザＵ０１の通話可能性を判定する。例えば、判定装置１００は、架電業者から指定された時間を対象日時として、ユーザＵ０１の通話可能性を判定する。

例えば、判定装置１００は、架電業者から、「現時点から１０分後」におけるユーザＵ０１の通話可能性を判定することを依頼されたとする。この場合、判定装置１００は、ユーザＵ０１のサービスにおける利用状況のうち、通話可能性と関係性のある利用状況を抽出し、抽出した利用状況に対応するスコアを算出することで、現時点から１０分後におけるユーザＵ０１の通話可能性を判定する。

例えば、現時点におけるユーザＵ０１の位置情報が、ユーザＵ０１の自宅近傍を示すものや、１０分以内にユーザＵ０１が自宅まで帰宅可能であると推定される位置を示すものであったとする。この場合、判定装置１００は、ユーザＵ０１の通話可能性を示すスコアに、上記したスコアである「４０」、もしくは「２０」を加算する。また、ユーザＵ０１が、対象日時（すなわち、現時点から１０分後）において、ショッピングサービスを利用して購入した商品の配送を指定していたとする。この場合、判定装置１００は、ユーザＵ０１の通話可能性を示すスコアに、上記したスコアである「３０」を加算する。そして、ユーザＵ０１のサービスにおける利用状況であって、ユーザＵ０１の通話可能性を測るために用いられる利用状況は、上記以外には抽出されなかったとする。この場合、判定装置１００は、現時点から２時間後におけるユーザＵ０１の通話可能性を示すスコアを「７０」、もしくは「５０」と判定する。

そして、判定装置１００は、算出したスコアに基づいて判定されたユーザＵ０１の通話可能性を、架電業者に送信する（ステップＳ１４）。例えば、判定装置１００は、算出したスコアを正規化してパーセント表記した通話可能性を、架電業者が利用する架電業者装置５０に送信する。

架電業者は、判定装置１００から送信された通話可能性に基づいて、ユーザＵ０１に架電する（ステップＳ１５）。例えば、架電業者は、ユーザＵ０１の通話可能性が比較的高いという判定結果を判定装置１００から受信した場合、実際にユーザＵ０１に架電し、所定のサービスを提供する。あるいは、架電業者は、ユーザＵ０１の通話可能性が比較的低いという判定結果を判定装置１００から受信した場合、その対象日時ではなく、別の日時にユーザＵ０１に架電する対応をとってもよい。あるいは、架電業者は、ユーザＵ０１に代えて、ユーザＵ０１よりも通話可能性が高い別の顧客に架電するような対応をとってもよい。

なお、判定装置１００は、事前に定義された判定要素に基づいて通話可能性を判定するのみならず、所定の学習処理を行い、判定の精度を向上させてもよい。

例えば、ステップＳ１５において、架電業者は、実際にユーザＵ０１に架電した場合には、ユーザＵ０１が架電に応答したか否かという結果情報を取得することができる。言い換えれば、架電業者は、判定装置１００が判定した結果が正解であったか否かを示す結果情報を取得する。

この場合、架電業者は、例えば架電業者装置５０を介して、ユーザＵ０１が架電に応答したか否かを示す結果情報を判定装置１００に送信する（ステップＳ１６）。

判定装置１００は、架電業者から送信された結果情報に基づいて、ユーザＵ０１の通話可能性の判定に用いられた利用状況と、結果情報との相関性を学習する。そして、判定装置１００は、学習を反映し、ユーザＵ０１の通話可能性を判定するための算出式（モデル）を生成する（ステップＳ１７）。詳細は後述するが、一例として、判定装置１００は、ユーザＵ０１が架電に応答したか否かという結果情報を目的変数とし、判定において用いた各利用状況を説明変数として、回帰分析手法による学習を行う。これにより、判定装置１００は、ユーザＵ０１の通話可能性の判定において、どのような説明変数（利用状況）が寄与したかといった情報を導出することができる。判定装置１００は、生成したモデルをモデル記憶部１２５に格納する。

判定装置１００は、上記のモデルをユーザごとに生成する。仮に、ユーザＵ０１が在宅していたとしても架電に応答しない傾向にある場合には、ユーザＵ０１が在宅しているという利用状況は、通話可能性の判定に寄与する率が低いといえる。また、仮に、ユーザＵ０１が、サービスにおいてスケジュール登録したとしても、そのスケジュール通りに行動する傾向が弱い場合には、登録されたスケジュール情報は、通話可能性の判定に寄与する率が低いといえる。一方で、ユーザＵ０１が、勤務中であったとしても架電に応答する傾向にある場合には、ユーザＵ０１が勤務中であるという利用状況は、通話可能性の判定において負例側（架電に応答しない）ではなく、正例側（架電に応答する）に寄与するといえる。このように、通話可能性と利用状況との関係性は、各ユーザにおいて異なる結果に寄与する場合もある。このため、判定装置１００は、個人の行動の特性等をふまえて通話可能性が導出できるよう、各ユーザのモデルを生成する。この場合、判定装置１００は、結果情報を取得するたびに、モデル記憶部１２５に格納されているモデルを更新するようにしてもよい。

具体的には、判定装置１００は、学習の進行に合わせて、各ユーザに適用する定義ファイルを更新してもよい。例えば、上記のように、ユーザ端末１０から取得される位置情報が通話可能性の判定に寄与しないという傾向が強いユーザに関しては、判定装置１００は、学習結果に応じて、位置情報に対応するスコアが、他のユーザと比して低く算出されるような重みを付してもよい。あるいは、判定装置１００は、指定した配送日時において常に架電に応答するような傾向にあるユーザについては、それらの利用状況に対応するスコアが、他のユーザと比して高く算出されるような重みを付してもよい。すなわち、判定装置１００は、各ユーザに応じた重みが付されたスコアを用いて通話可能性を求めるモデルを、各ユーザに対して生成することができる。

また、判定装置１００は、曜日や時間帯を加味した判定を行ってもよい。仮に、対象日時に対応した利用状況がユーザＵ０１から取得できなかった場合でも、判定装置１００は、過去の同じ曜日や、過去の同じ時間帯における通話可能性を判定し、その結果情報を取得している可能性がある。この場合、判定装置１００は、例えば、過去の同じ曜日や、過去の同じ時間帯におけるユーザＵ０１の通話可能性を反映させて、対象日時におけるユーザＵ０１の通話可能性を判定してもよい。具体的には、判定装置１００は、ユーザＵ０１が、過去の同じ曜日や同じ時間帯に在宅していた場合、今回の対象日時において、通話可能性を相対的に高く算出するなどの調整を行ってもよい。

以上、図１を用いて説明してきたように、実施形態に係る判定装置１００は、ユーザＵ０１が利用する端末における利用状況を取得し、取得した利用状況と、架電に対してユーザが通話を行う可能性である通話可能性との関係性に基づいて、所定のタイミングにおけるユーザＵ０１の通話可能性を判定する。

このように、判定装置１００は、ユーザ端末１０における利用状況に基づいてユーザＵ０１の通話可能性を判定するため、架電業者に架電タイミングに関する要望を行ったり、架電タイミングの登録を行ったりせずとも、ユーザＵ０１の日常的な状況に基づいて、ユーザＵ０１の通話可能性を判定することができる。また、判定装置１００は、利用状況に基づいて判定を行うため、例えば、ユーザＵ０１がユーザ端末１０を手に持っているとか、アプリを操作しているといった、リアルタイムな情報を判定させて通話可能性を判定することができる。さらに、判定装置１００は、ユーザ端末１０を介して利用されたサービスの利用状況を加味して判定を行うこともできる。すなわち、判定装置１００は、スケジュールサービスにおいてユーザＵ０１がスケジュール登録していることや、ショッピングサービスにおいて配送日時を指定したことなど、架電しようとするタイミングにおいて、ユーザＵ０１がどのような状況にあるかを反映させて、通話可能性を判定することができる。これにより、判定装置１００は、架電に対してユーザＵ０１との通話が成立する可能性を精度よく判定することができる。以下、このような処理を行う判定装置１００、及び、判定装置１００を含む判定処理システム１の構成等について、詳細に説明する。

〔２．判定処理システムの構成〕
図２を用いて、実施形態に係る判定装置１００が含まれる判定処理システム１の構成について説明する。図２は、実施形態に係る判定処理システム１の構成例を示す図である。図２に例示するように、実施形態に係る判定処理システム１には、ユーザ端末１０と、サービスサーバ３０と、架電業者装置５０と、判定装置１００とが含まれる。これらの各種装置は、ネットワークＮを介して、有線又は無線により通信可能に接続される。なお、図２に示した判定処理システム１には、複数台のユーザ端末１０や、複数台のサービスサーバ３０や、複数台の架電業者装置５０が含まれてもよい。

ユーザ端末１０は、例えば、スマートフォンや、デスクトップ型ＰＣ（Personal Computer）や、ノート型ＰＣや、タブレット型端末や、携帯電話機、ＰＤＡ（Personal Digital Assistant）、ウェアラブルデバイス（Wearable Device）等の情報処理装置である。さらに、ユーザ端末１０には、情報処理機能を有する種々のスマート機器が含まれてもよい。例えば、ユーザ端末１０には、ＴＶ（Television）や設置型スピーカなどのスマート家電や、自動車などのスマートビークル（Smart vehicle）や、ドローン（drone）、家庭用ロボットなどが含まれてもよい。

例えば、ユーザ端末１０は、ユーザによる操作に従って、サービスサーバ３０にアクセスすることで、サービスサーバ３０から提供されるウェブサイトからウェブページを取得する。そして、ユーザ端末１０は、取得したウェブページを表示装置（例えば、液晶ディスプレイ）に表示する。また、ユーザ端末１０は、ユーザがサービスを利用する場合には、当該サービスに関する情報を検知し、検知した情報をサービス側に送信してもよい。例えば、ユーザ端末１０は、ユーザが所定のサービスを利用するタイミングで、検知した位置情報をサービスサーバ３０に送信するようにしてもよい。

サービスサーバ３０は、ユーザ端末１０からアクセスされた場合に、各種サービスを提供するサーバ装置である。サービスサーバ３０は、例えば、ポータルサイト、ニュースサイト、天気予報サイト、ショッピングサイト、オークションサイト、ファイナンス（株価）サイト、路線検索サイト、地図提供サイト、旅行情報サイト、飲食店紹介サイト、飲食店等の予約サイト、ウェブブログ、ＳＮＳ（Social Networking Service）などに関する各種ウェブページを介して、各種サービスを提供する。

また、サービスサーバ３０は、サービスにおけるユーザ端末１０の利用状況を取得してもよい。例えば、サービスサーバ３０がポータルサイトに係るサービスを提供する場合には、サービスサーバ３０は、利用状況として、ユーザの登録情報（性別や年齢等の属性情報）や、ログイン時の位置情報等を取得する。また、サービスサーバ３０がショッピングサイトやオークションサイト等の購買に係るサービスを提供する場合には、サービスサーバ３０は、利用状況として、ユーザが商品を購入する頻度や購入価格、また、商品の配送として指定する日時等の情報を取得する。また、サービスサーバ３０は、上記以外のサービスにおいても、ユーザがサービスを利用するたびに、サービスにおける様々な利用状況を取得する。また、サービスサーバ３０は、サービスにおけるユーザ端末１０の利用状況を判定装置１００に送信してもよい。

架電業者装置５０は、架電業者によって利用される情報処理装置である。なお、架電業者装置５０は、架電業者の各々の勤務者が利用する端末であってもよいし、架電業者側に設置されたサーバであってもよい。また、架電業者装置５０は、１台の装置として構成されるのではなく、サーバと端末の組合せ等であってもよい。

架電業者装置５０は、例えば、判定装置１００から送信されるユーザごとの通話可能性を受信する。また、架電業者装置５０は、架電業者による操作に従って、実際にユーザが架電に応答したか否かを示す結果情報を判定装置１００に送信してもよい。

判定装置１００は、ユーザが利用するユーザ端末１０における利用状況を取得し、取得した利用状況と、架電に対してユーザが通話を行う可能性である通話可能性との関係性に基づいて、所定のタイミングにおけるユーザＵ０１の通話可能性を判定するサーバ装置である。なお、判定装置１００は、ユーザにサービスを提供するサービスサーバ３０としての機能を兼ねていてもよい。

〔３．判定装置の構成〕
次に、図３を用いて、実施形態に係る判定装置１００の構成について説明する。図３は、実施形態に係る判定装置１００の構成例を示す図である。図３に示すように、判定装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、判定装置１００は、判定装置１００を利用する管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。

（通信部１１０について）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。かかる通信部１１０は、ネットワークＮと有線又は無線で接続され、ネットワークＮを介して、ユーザ端末１０や、サービスサーバ３０や、架電業者装置５０との間で情報の送受信を行う。

（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。記憶部１２０は、利用状況記憶部１２１と、モデル記憶部１２５と、架電態様記憶部１２９とを有する。

（利用状況記憶部１２１について）
利用状況記憶部１２１は、ユーザ端末１０の利用状況に関する情報を記憶する。図３に示すように、利用状況記憶部１２１は、情報を記憶するデータテーブルとして、属性テーブル１２２と、センサテーブル１２３Ａと、サービステーブル１２３Ｂと、定義テーブル１２４とを有する。

（属性テーブル１２２について）
属性テーブル１２２は、ユーザの属性情報を記憶する。図４に、実施形態に係る属性テーブル１２２の一例を示す。図４は、実施形態に係る属性テーブル１２２の一例を示す図である。図４に示した例では、属性テーブル１２２は、「ユーザＩＤ」、「所有端末ＩＤ」、「電話番号」、「電話種別」、「性別」、「年齢」、「自宅位置」、「職種」、「勤務時間」といった項目を有する。

「ユーザＩＤ」は、ユーザを識別する識別情報である。「所有端末ＩＤ」は、ユーザが利用するユーザ端末１０を識別する識別情報である。所有端末ＩＤは、例えば、ユーザ端末１０を利用してサービスにアクセスした際に、当該ユーザ端末１０の固有の識別情報（デバイスＩＤ等）がサービスサーバ３０等によって認識されることにより、取得される。あるいは、所有端末ＩＤは、サービスを利用するユーザがサービス側に登録を行うことによってサービス側に取得されてもよい。

なお、所有端末ＩＤとして登録される情報には、端末の種別が含まれてもよい。具体的には、所有端末ＩＤとして登録される情報には、その端末が、ユーザに携帯される端末（スマートフォンやウェアラブルデバイス）であるか、あるいは、一般的には携帯されない端末（自宅に設置されるスピーカなどのＩｏＴ機器や、デスクトップパソコンなど）であるか、といった情報が含まれてもよい。また、所有端末ＩＤとして登録される情報には、その端末が架電に対する応答機能（例えば電話番号のような、呼制御に応答するための識別情報を有するとともに、通話機能を有すること）を有するか否かといった情報が含まれてもよい。なお、本明細書中では、図４に示したような識別情報を参照符号として用いる場合がある。例えば、ユーザＩＤ「Ｕ０１」によって識別されるユーザを「ユーザＵ０１」と表記する場合がある。

「電話番号」は、ユーザの電話番号を示す。「電話種別」は、登録されている電話番号が、携帯電話のものであるか、固定電話であるか、勤務先の電話であるか、といった種別を示す。なお、電話番号は、各ユーザに対して１つのみ登録されるのではなく、複数の電話番号が登録されていてもよい。

「性別」は、サービスを利用するユーザの性別を示す。「年齢」は、ユーザの年齢を示す。「自宅位置」は、ユーザの自宅が所在する位置を示す。なお、「自宅位置」には、具体的な住所ではなく、ユーザの自宅に対応する位置情報（例えば、経度及び緯度）が記憶されてもよい。「職種」は、ユーザの職種を示す。「勤務時間」は、ユーザの勤務時間を示す。なお、職種や勤務時間は、ユーザがサービスに登録を行うことでサービス側に取得された情報であってもよいし、ユーザ端末１０の利用状況に基づいて推定された情報であってもよい。例えば、判定装置１００は、ユーザ端末１０から送信される位置情報のうち、平日昼間に頻繁に観測される位置情報に基づいて、ユーザＵ０１の勤務先の位置を特定する。さらに、判定装置１００は、サービスが保持する地図情報等に基づいて、当該位置に所在する会社名や、会社が属する職種等を特定する。そして、判定装置１００は、特定した情報をユーザと対応付けて、属性テーブル１２２に記憶する。

すなわち、図４に示したデータの一例は、ユーザＩＤ「Ｕ０１」で識別されるユーザＵ０１に関する属性情報であり、ユーザＵ０１が利用するユーザ端末１０は、所有端末ＩＤ「Ａ０１」や「Ａ０２」で識別されることを示している。また、登録されているユーザＵ０１の電話番号が「ＸＸＸＸ」であり、その電話番号に対応する電話種別が「携帯電話」であることを示している。また、ユーザＵ０１の性別は「男性」であり、年齢は「３０歳代」であり、住所は「Ａ県・・・」であり、職種は「会社員（日勤）」であり、勤務時間は「９時〜１７時」であることを示している。

なお、属性テーブル１２２に記憶される属性情報は、必ずしも正確な情報でなくともよい。例えば、判定装置１００は、ユーザ端末１０の利用状況から推定される「推定性別」や「推定年齢」等を属性テーブル１２２に記憶してもよい。

（センサテーブル１２３Ａについて）
続いて、図５に、実施形態に係るセンサテーブル１２３Ａの一例を示す。図５は、実施形態に係るセンサテーブル１２３Ａの一例を示す図である。センサテーブル１２３Ａは、ユーザ端末１０の利用状況のうち、ユーザ端末１０によって検知される情報であるセンシング情報を記憶する。図５に示した例では、センサテーブル１２３Ａは、「ユーザＩＤ」、「センサログＩＤ」、「取得日時」、「センシング情報」、「取得内容」といった項目を有する。

「ユーザＩＤ」は、図４に示した同様の項目と対応する。「センサログＩＤ」は、検知されたセンシング情報を識別する識別情報を示す。「取得日時」は、センサログが取得された日時を示す。なお、判定装置１００は、センシング情報を一定時間ごと（例えば、１分毎や１０分毎）に取得してもよいし、ユーザがサービスを利用したタイミングや、所定のアプリが起動されたタイミングや、特定のコンテキストが観測されたタイミング（ユーザＵ０１が自宅や会社を訪れたタイミングなど）等に取得してもよい。

「センシング情報」は、ユーザ端末１０によって検知された情報の種別を示す。「取得内容」は、取得されたセンシング情報の具体的な内容を示す。なお、図５に示した例では、取得内容を「ＳＥ０１」といった概念的な表記で示しているが、実際には、センシング情報が位置情報である場合には、具体的な緯度や経度を示す位置情報や、住所や地域を示す情報が記憶される。

また、センシング情報が物理・加速度情報であれば、取得内容には、ユーザ端末１０の傾き情報や、加速度情報の具体的な数値等が記憶される。なお、物理・加速度情報として、具体的な数値のみならず、数値から推定されるユーザ端末１０の利用状況が記憶されてもよい。具体的には、物理・加速度情報には、「ユーザがユーザ端末１０に触れている」ことや、「ユーザがユーザ端末１０を手に持っている」こと等の、状況を示す情報が記憶されてもよい。

また、センシング情報がアプリ操作であれば、取得内容には、ユーザが起動させたアプリの数や、アプリの名称や、アプリのカテゴリ等が記憶されてもよい。また、アプリ操作には、ユーザがアプリを操作するためにユーザ端末１０を操作する操作情報等が記憶されてもよい。

また、センシング情報が照度情報であれば、取得内容には、具体的な照度の数値等が記憶される。なお、図５では図示を省略しているが、ユーザ端末１０が検知する情報は、照度に限らず、温度や湿度であってもよい。

すなわち、図５に示したデータの一例では、ユーザ端末１０が検知した情報のログとして、センサログＩＤ「Ｂ０１」で識別されるセンサログＢ０１が記憶されていることを示している。また、センサログＢ０１は、取得日時が「２０１７年４月２５日 １２：００」であり、センシング情報が「位置情報」であり、その取得内容は「ＳＥ０１」であることを示している。

（サービステーブル１２３Ｂについて）
続いて、図６に、実施形態に係るサービステーブル１２３Ｂの一例を示す。図６は、実施形態に係るサービステーブル１２３Ｂの一例を示す図である。サービステーブル１２３Ｂは、サービスにおけるユーザ端末１０の利用状況を記憶する。図６に示した例では、サービステーブル１２３Ｂは、「ユーザＩＤ」、「サービス利用ログＩＤ」、「取得日時」、「サービス」、「情報種別」、「取得情報」、「曜日情報」といった項目を有する。

「ユーザＩＤ」は、図４に示した同様の項目と対応する。「サービス利用ログＩＤ」は、ユーザがサービスを利用した行動履歴（ログ）を識別する識別情報を示す。「取得日時」は、ユーザの利用ログが取得された日時を示す。例えば、取得日時は、ユーザがサービスにログインした日時や、ユーザがサービスにスケジュールを登録した日時や、飲食店への予約を登録した日時等である。このため、取得日時は、通話可能性の判定対象となる日時とは関係のない場合もある。例えば、スケジュール情報の場合、スケジュールが登録されたタイミングではなく、スケジュールとして登録された日程が、通話可能性の判定対象となる日時と関係を有する。

「サービス」は、ユーザが利用したサービスの種別を示す。「情報種別」は、利用状況として取得された情報の種別を示す。「取得情報」は、取得された利用状況の具体的な内容を示す。すなわち、取得情報は、ユーザの通話可能性を判定する際の、通話可能性の判定対象となる日時との関係を示す情報を含む場合がある。例えば、スケジュール情報の場合、スケジュールとして登録された日程が、通話可能性の判定対象となる日時と関係を有することになる。なお、図６に示した例では、取得情報の一部を「Ｃ０１」といった概念的な表記で示しているが、実際には、取得情報が位置情報である場合には、具体的な緯度や経度を示す位置情報や、住所や地域を示す情報が記憶される。「曜日情報」は、利用状況のうち、通話可能性の判定対象となる日時と関係を有する曜日を示す。

すなわち、図６に示したデータの一例では、ユーザＵ０１のサービスにおけるログとして、サービス利用ログＩＤ「ＳＢ０１」で識別されるサービス利用ログＳＢ０１が記憶されていることを示している。また、サービス利用ログＳＢ０１は、取得日時が「２０１７年４月２０日 １５：００」であり、「地図・交通」に関するサービスにおけるログであり、利用状況として取得された情報種別は「位置情報」であり、その取得情報は「Ｃ０１」であることを示している。また、サービス利用ログＳＢ０１として取得された情報が、通話可能性の判定対象となる曜日は「木」曜日であることを示している。

（定義テーブル１２４について）
続いて、図７に、実施形態に係る定義テーブル１２４の一例を示す。図７は、実施形態に係る定義テーブル１２４の一例を示す図である。定義テーブル１２４は、通話可能性と利用状況との関係性を定義した情報を記憶する。例えば、定義テーブル１２４に記憶される情報とは、図１の説明で示した定義ファイルに記述された情報に対応する。図７に示した例では、定義テーブル１２４は、「定義ＩＤ」、「判定要素」、「利用状況」、「スコア」といった項目を有する。

「定義ＩＤ」は、各定義を識別する識別情報を示す。「判定要素」は、判定要素として用いられる利用状況の種別を示す。「利用状況」は、具体的な利用状況の内容を示す。「スコア」は、判定対象の日時において、定義された利用状況が取得された場合に、ユーザの通話可能性を示すスコアとして加算される数値を示す。

すなわち、図７に示したデータの一例では、定義ＩＤ「Ｋ０１」で識別される定義Ｋ０１は、判定要素が「センシング」に係るものであり、対象日時において、「端末を手に持っている」という利用状況が取得された場合には、そのユーザの通話可能性を示すスコアとして「６０」を加算することを示している。

また、他の例として、定義Ｋ１１は、判定要素が「サービス」に係るものであり、対象日時において、例えば位置情報に基づいて「在宅している」という利用状況が取得された場合には、そのユーザの通話可能性を示すスコアとして「４０」を加算することを示している。なお、位置情報は、地図情報サービスやナビアプリ等のサービスによって取得されてもよいし、ユーザ端末１０のセンシングによって取得されてもよい。

また、他の例として、定義Ｋ２１は、判定要素が「設定・履歴」に係るものであり、「架電対象が携帯端末である」という状況であれば、そのユーザの通話可能性を示すスコアとして「１０」を加算することを示している。また、定義Ｋ２２は、判定要素が「設定・履歴」に係るものであり、「架電対象が固定電話である」という状況であれば、そのユーザの通話可能性を示すスコアとして「−１０」を加算することを示している。これは、一般に、固定電話よりも携帯電話の方がユーザは電話に出易いことを示している。なお、後述するように、定義テーブル１２４に定義されたスコアは、判定装置１００による学習処理を経て変化する場合もありうる。

（モデル記憶部１２５について）
モデル記憶部１２５は、利用状況と通話可能性との関係性に関する学習と、学習の結果として生成されたモデルに関する情報を記憶する。図３に示すように、モデル記憶部１２５は、情報を記憶するデータテーブルとして、学習データテーブル１２６と、モデルテーブル１２７とを含む。

（学習データテーブル１２６について）
学習データテーブル１２６は、通話可能性を判定するモデルを生成するための学習に関する情報を記憶する。図８に、実施形態に係る学習データテーブル１２６の一例を示す。図８は、実施形態に係る学習データテーブル１２６の一例を示す図である。図８に示した例では、学習データテーブル１２６は、「学習データＩＤ」、「ユーザＩＤ」、「対象日時」、「対象曜日」、「架電結果情報（目的変数）」、「利用状況データ（説明変数）」といった項目を有する。

「学習データＩＤ」は、モデルを生成するための学習データを識別する識別情報を示す。なお、学習データは、例えばユーザごとに蓄積される。「ユーザＩＤ」は、図４に示した同様の項目に対応する。

「対象日時」は、通話可能性を判定した対象となった日時を示す。「対象曜日」は、通話可能性を判定した対象となった曜日を示す。

「架電結果情報（目的変数）」は、判定対象の日時において正解か不正解かを示した結果情報である。例えば、判定を行った日時において、ユーザが架電に応答して通話が行われたのであれば、架電結果情報には「１」が記憶される。一方、判定を行った日時において、ユーザが架電に対応して応答せず、通話が行われなかったのであれば、架電結果情報には「０」が記憶される。なお、結果情報は、上記の例に限らず、例えば、判定装置１００がユーザの通話可能性を「あり」か「なし」かで判定したような場合には、結果情報には、その判定が正解であったか（この場合「１」が記憶される）、あるいは不正解であったか（この場合、「０」が記憶される）、という判定の正否に関する情報が記憶されてもよい。

「利用状況データ（説明変数）」は、判定対象の日時におけるユーザ端末１０の利用状況データを示す。なお、図８の例では、利用状況データを「Ｇ０１」といったように概念的に表記しているが、実際には、利用状況データには、ユーザ端末１０の複数の利用状況が羅列されたデータが記憶される。すなわち、利用状況データは、ユーザ端末１０の利用状況から抽出された特徴情報の集合体であり、ユーザの通話可能性を判定するために用いられた全ての利用状況が含まれるものである。

すなわち、図８に示したデータの一例では、学習データＩＤ「Ｅ０１」で識別される学習データＥ０１は、学習の対象がユーザＵ０１であることを示している。そして、学習データＥ０１に含まれる学習データの一例は、判定の対象日時が「２０１７年４月１３日 １２：００」であり、対象曜日が「木」曜日であり、利用状況データが「Ｇ０１」であり、その際の架電結果情報が「１」であったことを示している。より具体的には、ユーザＵ０１において、対象日時における利用状況データが「Ｇ０１」である場合に、ユーザＵ０１は架電に応答して通話を行ったことを示している。

（モデルテーブル１２７について）
次に、図９に、実施形態に係るモデルテーブル１２７の一例を示す。図９は、実施形態に係るモデルテーブル１２７の一例を示す図である。図９に示すように、モデルテーブル１２７は、「モデルＩＤ」、「ユーザＩＤ」といった項目を有する。

「モデルＩＤ」は、モデルを識別する識別情報を示す。「ユーザＩＤ」は、モデルに対応するユーザを識別する識別情報を示す。

すなわち、図９に示したデータの一例では、モデルＩＤ「Ｍ０１」によって識別されるモデルＭ０１は、ユーザＵ０１に対応したモデルであり、モデルＩＤ「Ｍ０２」によって識別されるモデルＭ０２は、ユーザＵ０２に対応するモデルであることを示している。図９に示されるように、モデルは、ユーザごとに生成される。

（架電態様記憶部１２９について）
架電態様記憶部１２９は、判定装置１００から架電業者に提供される情報であって、ユーザに架電する態様に関する情報を記憶する。例えば、架電態様記憶部１２９に記憶される情報は、架電業者に対して各ユーザの通話可能性を示すリストであり、どの日程に架電をすべきかを架電業者が認識するための情報である。図１０に、実施形態に係る架電態様記憶部１２９の一例を示す。図１０は、実施形態に係る架電態様記憶部１２９の一例を示す図である。図１０に示すように、架電態様記憶部１２９は、「架電業者ＩＤ」、「対象日時」、「架電対象ユーザＩＤ」、「通話可能性」といった項目を有する。

「架電業者ＩＤ」は、架電を行う架電業者を識別する識別情報を示す。図１０で示した架電業者とは、例えば、ユーザから所定の申込みを受け付けた際にユーザの本人確認のためにユーザに電話を行う事業者や、電話で営業を行う事業者や、督促を行う事業者など、種々の事業者である。

「対象日時」は、ユーザの通話可能性を判定する対象となる日時を示す。例えば、対象日時は、サービスからの要求に基づき設定される。具体的には、判定装置１００は、架電業者から、「２０１７年４月３０日 １２：００」における各ユーザの通話可能性の判定について要求を受け付けた場合に、対象日時を「２０１７年４月３０日 １２：００」に設定して、通話可能性の判定を行う。

なお、対象日時は、判定処理を行うタイミングそのものではなく、判定結果を出す締め切り時間であってもよい。例えば、図１０の例では、判定装置１００は、「２０１７年４月３０日 １２：００」の直前まで、ユーザ端末１０の利用状況の取得と、通話可能性の判定を繰り返し行っており、最終的に「２０１７年４月３０日 １２：００」の時点において、ユーザの通話可能性の判定結果を出すようにしてもよい。

「架電対象ユーザＩＤ」は、架電の対象となるユーザを識別する識別情報を示す。「通話可能性」は、ユーザごとの通話可能性を示す。例えば、「通話可能性」は、判定装置１００が算出したスコア等を正規化し、パーセント表記された数値が記憶される。なお、通話可能性には、必ずしも固定された数値が記憶されるのではなく、判定日時が経過するまで、取得された利用状況に基づいて判定処理が行われる度に更新されてもよい。

すなわち、図１０に示したデータの一例では、架電業者ＩＤ「Ｈ０１」で識別される架電業者Ｈ０１の顧客ユーザに関して、対象日時「２０１７年４月３０日 １２：００」における通話可能性の判定を行った例を示している。そして、判定の結果として、例えば、架電対象ユーザＩＤ「Ｕ１３」で識別されるユーザＵ１３の通話可能性は「８５」％であり、ユーザＵ０８の通話可能性は「８３」％であることが導出されたことを示している。

（制御部１３０について）
図３に戻って説明を続ける。制御部１３０は、例えば、コントローラ（controller）であり、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、判定装置１００内部の記憶装置に記憶されている各種プログラム（判定プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、コントローラであり、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

図３に示すように、制御部１３０は、取得部１３１と、判定部１３２と、生成部１３３と、決定部１３４と、送信部１３５とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図３に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図３に示した接続関係に限られず、他の接続関係であってもよい。

（取得部１３１について）
取得部１３１は、各種情報を取得する。例えば、取得部１３１は、ユーザが利用するユーザ端末１０における利用状況を取得する。

具体的には、取得部１３１は、ユーザ端末１０から、ユーザ端末１０が検知する情報を取得する。例えば、取得部１３１は、ユーザ端末１０の位置情報を取得する。また、取得部１３１は、ユーザの自宅の位置を示す位置情報や、勤務先の位置を示す位置情報等、ユーザの拠点となる位置を示す位置情報を取得してもよい。例えば、取得部１３１は、サービスに登録された情報に基づいて、ユーザの自宅や勤務先等を特定し、特定された位置の位置情報を取得する。

また、取得部１３１は、取得された位置情報が示す位置から、ユーザの自宅まで当該ユーザが移動した場合に経過すると推定される時間情報を取得してもよい。例えば、取得部１３１は、ユーザが所在する現在地を示す位置情報と、当該ユーザの自宅を示す位置情報との距離情報を取得することで、ユーザが移動した場合に経過すると推定される時間情報を取得する。この場合、取得部１３１は、例えば、位置情報の推移からユーザの移動手段を推定し、推定した移動手段が採用されたと仮定して、移動に掛かる時間を推定してもよい。これにより、取得部１３１は、対象日時において、ユーザが在宅であるか否かを推定し、その情報を通話可能性の判定に用いることができる。

また、取得部１３１は、ユーザが利用するサービスによっては、より精度の高い時間情報を取得することもできる。例えば、ユーザ端末１０においてカーナビアプリが実行されている場合には、取得部１３１は、カーナビアプリを提供するサービスサーバ３０や、カーナビアプリが実行されているユーザ端末１０から、ユーザが自宅まで移動した場合に経過すると推定される時間情報を取得することができる。

また、取得部１３１は、利用状況として、ユーザ端末１０に対するユーザの物理的な動作を示す動作情報を取得する。具体的には、取得部１３１は、ユーザがユーザ端末１０に触れているといった動作情報や、ユーザがユーザ端末１０を手に持っているといった動作情報を取得する。

なお、取得部１３１は、ユーザ端末１０によって検知される加速度情報や傾き情報から、上記のようなユーザの動作を推定し、推定した情報を取得してもよい。このような推定には、種々の既知の技術が用いられてもよい。

また、取得部１３１は、利用状況として、ユーザ端末１０をユーザが操作中であるか否かを示す操作情報を取得してもよい。例えば、取得部１３１は、ユーザ端末１０がタッチパネルを搭載している場合には、タッチパネルに対してユーザが操作を行っていること等の操作情報を取得する。

また、取得部１３１は、利用状況として、ユーザ端末１０における加速度、もしくは、ユーザ端末１０の移動速度を取得する。なお、取得部１３１は、加速度や移動速度の具体的な数値のみならず、ユーザが電車や飛行機で移動していることなど、加速度や移動速度から推定されるコンテキストを取得してもよい。この場合、取得部１３１は、取得した位置情報と、サービスが提供する地図情報等を組み合わせて、ユーザが線路上を移動していると推定される際には、「ユーザが電車に乗っている」というコンテキストにあること等を推定してもよい。

また、取得部１３１は、利用状況として、ユーザ端末１０の周辺における照度情報を取得してもよい。なお、取得部１３１は、ユーザ端末１０の周辺の照度情報に基づいて、ユーザ端末１０が鞄の中にあることなど、照度情報から推定されるコンテキストを取得してもよい。

また、取得部１３１は、利用状況として、ユーザ端末１０に音声出力装置が接続されているか否かを示す接続情報を取得してもよい。また、取得部１３１は、ユーザ端末１０において音楽が再生されているといった利用状況を合わせて取得してもよい。イヤホン等の音声出力装置が接続されている場合、ユーザは、ユーザ端末１０に掛かってくる着信音を知覚する可能性が高いといえる。このため、ユーザ端末１０に音声出力装置が接続されており、さらに、音楽が再生されているような場合は、ユーザは、架電に応答する確率が高くなると推定される。

また、取得部１３１は、利用状況として、ユーザ端末１０におけるアプリ操作に関する情報であるアプリ操作情報を取得してもよい。例えば、ユーザがアプリを操作している場合には、ユーザ端末１０の表示画面等を見ている状況が推定されるため、ユーザは、ユーザ端末１０への架電を知覚する可能性が高いといえる。このため、ユーザ端末１０がアプリを操作している場合、ユーザは、架電に応答する確率が高くなると推定される。

また、取得部１３１は、ユーザが操作しているアプリを識別する識別情報、又は、アプリのカテゴリを取得してもよい。例えば、ユーザは、アプリの種別やカテゴリによって、架電に応答する確率が変わる可能性がある。例えば、集中してゲームアプリ等を操作するユーザは、アプリの操作中には架電に応答しない可能性がある。このように、ユーザごとに、アプリの種別やカテゴリとの関係性を取得することで、後述する判定部１３２は、より精度よく通話可能性を判定することができる。

また、取得部１３１は、利用状況として、ユーザ端末１０を介してユーザが利用したサービスに関する利用情報を取得してもよい。具体的には、取得部１３１は、ネットワークを介して利用可能なサービスであって、例えば、ユーザ端末１０を介して利用するウェブサービスにおける利用状況を取得する。なお、サービスはウェブサービスに限らず、例えば、ユーザ端末１０にインストールされたアプリを介して利用されるサービスであってもよい。

例えば、取得部１３１は、購買に係るサービス（例えば、ショッピングサービスやオークションサービス等）の利用において、ユーザが指定した配送日程に関する情報を取得してもよい。例えば、取得部１３１は、ユーザが商品を注文した場合に、配送日時として指定した日程に関する情報を取得する。

また、取得部１３１は、スケジュール管理に関するサービス（例えば、カレンダーサービスやタスク管理サービス等）の利用において、ユーザが登録したスケジュール情報を取得してもよい。例えば、取得部１３１は、サービスにおいてユーザが登録した所定の予定をスケジュール情報として取得する。

なお、取得部１３１は、スケジュール情報として、日程に関する情報のみならず、種々の情報を取得してもよい。例えば、取得部１３１は、スケジュールに場所が登録されている場合には、その場所に関する位置情報を取得してもよい。この場合、後述する判定処理において、例えばスケジュール登録された場所がユーザの自宅等であれば、登録された日時においてユーザの通話可能性を比較的高いと判定することができる。あるいは、スケジュール登録された場所がユーザの自宅以外であれば、登録された日時においてユーザの通話可能性を比較的低いと判定することができる。

また、取得部１３１は、交通機関、旅行、飲食施設、もしくは宿泊施設の少なくともいずれか一つの予約に係るサービスの利用において、ユーザが予約した予約日程に関する情報を取得してもよい。なお、取得部１３１は、予約情報として、上記のスケジュール情報と同様に、位置情報をあわせて取得してもよい。

また、取得部１３１は、サービスにおける利用状況として、ユーザがサービスに登録した属性情報のうち、ユーザの職種又は勤務時間に関する情報を取得してもよい。

また、取得部１３１は、サービスの利用に用いられる情報機器であって、ユーザの自宅に設置された情報機器における通信状況に関する情報を取得してもよい。例えば、取得部１３１は、ユーザが携帯するユーザ端末１０と、ユーザの自宅に設置されたＩｏＴ機器との間で近距離通信が行われているといった通信状況に関する情報を取得する。なお、取得部１３１は、自宅に限られず、様々な場所に設置された情報機器やアクセスポイントとの通信状況を取得してもよい。これにより、取得部１３１は、ユーザが外出している場合であっても、どのような位置において通信を行っているかといった情報を取得できるので、結果として、ユーザが所在する位置を取得することができる。

なお、取得部１３１は、上記で例示した以外の利用状況においても、通話可能性の判定要素に用いられるあらゆる利用状況を適宜取得してもよい。取得部１３１は、取得した情報を利用状況記憶部１２１に格納する。

（判定部１３２について）
判定部１３２は、取得部１３１によって取得された利用状況と、ユーザの通話可能性との関係性に基づいて、所定のタイミングにおける当該ユーザの通話可能性を判定する。判定部１３２は、例えば、ユーザ端末１０の利用状況と、通話可能性との関係性を定義付けた情報が記述された定義テーブル１２４を参照して、ユーザの通話可能性を判定する。

例えば、判定部１３２は、ユーザの位置情報に基づいて、ユーザの通話可能性を判定する。一例として、判定部１３２は、対象日時において、取得部１３１によって取得された位置情報が、ユーザの自宅の位置を示す位置情報であるか否かに基づいて、ユーザの通話可能性を判定する。具体的には、判定部１３２は、ユーザ端末１０から取得されたユーザの位置情報がユーザの自宅近傍を示している場合には、ユーザの通話可能性を比較的高く判定する。

あるいは、判定部１３２は、ユーザの位置情報が、ユーザの勤務先等を示している場合には、一般にユーザは架電に応答することが難しいと考えられることから、ユーザの通話可能性を比較的低く判定してもよい。

また、判定部１３２は、取得された位置情報が示す位置から、ユーザの自宅までユーザが移動した場合に経過すると推定される時間情報が取得された場合には、時間情報に基づいて、所定時間後におけるユーザの通話可能性を判定してもよい。すなわち、判定部１３２は、現時点で、対象日時においてユーザが自宅に所在するという情報が得られなくとも、例えば、現時点から対象日時までに、移動によってユーザが自宅に到達可能な範囲に所在するという情報が得られれば、所定時間後（すなわち、対象日時）におけるユーザの通話可能性を高く判定する。

また、判定部１３２は、ユーザ端末１０が検知する情報に基づいて通話可能性を判定してもよい。例えば、判定部１３２は、ユーザ端末１０に対するユーザの物理的な動作を示す動作情報に基づいて、ユーザの通話可能性を判定してもよい。例えば、判定部１３２は、ユーザ端末１０が検知した傾き情報や圧力情報等に基づいて、ユーザがユーザ端末１０を手に持っているという状況が取得された場合には、ユーザの通話可能性を比較的高く判定してもよい。

また、判定部１３２は、ユーザ端末１０をユーザが操作中であるか否かを示す操作情報に基づいて、ユーザの通話可能性を判定してもよい。例えば、判定部１３２は、ユーザ端末１０をユーザが操作中である場合、ユーザが架電に応答する確率が高いため、ユーザの通話可能性を比較的高く判定してもよい。

また、判定部１３２は、ユーザ端末１０における加速度、もしくは、ユーザ端末１０の移動速度に基づいて、ユーザの通話可能性を判定してもよい。例えば、判定部１３２は、ユーザ端末１０が検知した加速度や速度情報等に基づいて、ユーザのコンテキストを推定する。そして、判定部１３２は、ユーザが歩行中である場合には、ユーザが電車や自動車や飛行機等に乗っている場合よりも、通話可能性を比較的高く判定してもよい。

また、判定部１３２は、ユーザ端末１０の周辺における照度情報に基づいて、ユーザの通話可能性を判定してもよい。例えば、判定部１３２は、ユーザ端末１０が鞄の中にあると想定される状況よりも、外の環境と同じ照度が観測される状況の方が、ユーザが架電に応答する確率が高いと想定して、ユーザの通話可能性を比較的高く判定してもよい。

また、判定部１３２は、ユーザ端末１０に音声出力装置が接続されているか否かを示す接続情報に基づいて、ユーザの通話可能性を判定してもよい。例えば、判定部１３２は、ユーザがユーザ端末１０を利用して音楽を聞いている場合には、ユーザが架電に応答する確率が高いため、通話可能性を比較的高く判定してもよい。

また、判定部１３２は、ユーザ端末１０におけるアプリ操作に関する情報であるアプリ操作情報に基づいて、ユーザの通話可能性を判定してもよい。例えば、判定部１３２は、ユーザがアプリを操作中である場合、ユーザが画面に注目している可能性が高く、架電に応答する確率が高いと想定されることから、ユーザの通話可能性を比較的高く判定してもよい。

また、判定部１３２は、ユーザが操作しているアプリを識別する識別情報、又は、アプリのカテゴリに基づいて、ユーザの通話可能性を判定してもよい。例えば、ユーザは、アプリの種別やカテゴリによって、架電に応答する確率が変わる可能性がある。例えば、集中してゲームアプリ等を操作するユーザは、アプリの操作中には架電に応答しない可能性がある。このため、判定部１３２は、例えば、判定対象とするユーザが当該ゲームアプリを起動している場合には、当該ユーザの通話可能性を比較的低く判定してもよい。

また、判定部１３２は、利用状況として、ユーザ端末１０を介してユーザが利用したサービスに関する利用情報を取得してもよい。

例えば、判定部１３２は、購買に係るサービスの利用においてユーザが指定した配送日程に関する情報が取得された場合には、配送日程に関する情報に基づいて、ユーザの通話可能性を判定してもよい。一般に、ユーザが配送日程を指定した日時は、そのユーザは架電に応答する可能性が高いといえる。このため、判定部１３２は、配送日程に関する情報に基づいて判定処理を行うことで、ユーザの通話可能性を精度よく判定することができる。

また、判定部１３２は、スケジュール管理に関するサービスの利用において、ユーザの登録したスケジュール情報が取得された場合には、スケジュール情報に基づいて、ユーザの通話可能性を判定してもよい。一般に、ユーザがスケジュールを登録した場合、そのユーザが在宅である可能性が低く、通話可能性も低くなると推定される。このため、判定部１３２は、スケジュール情報に基づいて判定処理を行うことで、ユーザの通話可能性を精度よく判定することができる。

また、判定部１３２は、交通機関、旅行、飲食施設、もしくは宿泊施設の少なくともいずれか一つの予約に係るサービスの利用において、ユーザの予約した予約日程に関する情報が取得された場合には、予約日程に関する情報に基づいて、ユーザの通話可能性を判定してもよい。

また、判定部１３２は、ユーザの職種又は勤務時間に関する情報に基づいて、ユーザの通話可能性を判定してもよい。例えば、判定部１３２は、ユーザの職種又は勤務時間に基づいて、ユーザが勤務中である時間帯を特定し、特定した時間においては通話可能性が比較的低いと判定する。また、判定部１３２は、ユーザの自宅と勤務先の位置情報に基づいて、ユーザの通勤時間を推定してもよい。さらに、判定部１３２は、推定した通勤時間と、ユーザの勤務時間とに基づいて、ユーザが出社するタイミングや、帰宅するタイミングを推定してもよい。そして、判定部１３２は、ユーザが自宅から離れていると推定される時間においては通話可能性を低く判定し、ユーザが勤務先から自宅に戻ってきていると推定される時間においては通話可能性を高く判定してもよい。

また、判定部１３２は、サービスの利用に用いられる情報機器であって、ユーザの自宅に設置された情報機器における通信状況に関する情報が取得された場合には、通信状況に関する情報に基づいて、ユーザの通話可能性を判定してもよい。一般に、ユーザが携帯すると想定されるユーザ端末１０と、自宅に設置された情報機器との近距離通信等が行われている場合には、ユーザは在宅していると推測される。このため、判定部１３２は、自宅に設置された情報機器との通信状況に基づいて判定処理を行うことで、ユーザの通話可能性を精度よく判定することができる。

判定部１３２は、判定処理において、上記したような利用状況を適宜組み合わせて判定処理を行ってもよい。例えば、判定部１３２は、判定対象の日時において、判定に用いることのできる利用状況が重複している場合には、重複した利用状況に対応するスコアを加算して、ユーザの通話可能性を判定する。判定部１３２は、ユーザの行動を示すと想定される複数の利用状況に基づいて判定を行うことで、判定の精度を向上させることができる。

なお、判定部１３２は、所定の学習処理を経て生成部１３３によって生成されるモデルであって、ユーザごとに生成されたモデルを用いて、ユーザの通話可能性を判定してもよい。

また、判定部１３２は、過去の架電の応答履歴に基づいて、ユーザの通話可能性を判定してもよい。例えば、判定部１３２は、曜日ごとにユーザの通話可能性を判定してもよい。また、判定部１３２は、時間帯ごとにユーザの通話可能性を判定してもよい。

すなわち、判定対象の日時において、過去の同じ曜日におけるユーザの応答履歴が存在する場合には、応答履歴の傾向に基づいて、判定部１３２は、ユーザが在宅しているか否かを推定してもよい。同様に、判定対象の日時において、過去の同じ時間帯（例えば、判定対象の日時の前後１０分に対応する時間帯）におけるユーザの応答履歴が存在する場合には、応答履歴の傾向に基づいて、判定部１３２は、今回の判定のタイミングにおいてもユーザが応答するか否かを推定してもよい。なお、後述するように、判定部１３２は、生成部１３３が生成したモデルを用いて判定処理を行うことで、上記のような過去のユーザの在宅傾向等を加味した判定を行うことができる。

なお、判定部１３２は、架電業者から要求を受け付けたことを契機として、その架電業者の顧客となるユーザの通話可能性を判定してもよいし、常時、不特定のユーザの通話可能性を判定していてもよい。

例えば、判定部１３２は、架電業者から要求を受け付けて判定を行う場合、例えば、判定対象とするユーザのリストや、判定対象とする日時に関する情報を取得する。そして、判定部１３２は、要求を受け付けたことを契機として、判定対象とする日時における、判定対象とするユーザの通話可能性を判定する。例えば、判定部１３２は、「現時点から１時間後」に、架電を行おうとする架電業者から要求を受け付ける。この場合、判定部１３２は、「現時点から１時間後」を判定対象の日時（図１０で示す「対象日時」に対応）と設定する。そして、判定部１３２は、架電業者の顧客ユーザを対象として、通話可能性を判定する。

（生成部１３３について）
生成部１３３は、取得部１３１によって取得された利用状況と、ユーザへの架電に対して当該ユーザが通話を行ったか否かを示す結果情報との関係性を学習することにより、当該ユーザの通話可能性を算出するモデルを生成する。具体的には、生成部１３３は、判定対象に用いた利用状況と、その判定における結果情報とに基づいて、どのような利用状況が、ユーザが架電に対して応答したか否かという結果に寄与していたのか、といった傾向を学習する。

例えば、利用状況に対して事前に定義された通話可能性のスコアは、ユーザによっては、異なるスコアの方が適切な場合がありうる。具体的には、判定対象のユーザが、在宅であるという状況の方が架電に応答する可能性が低かったり、勤務中であるという状況の架電に応答する可能性が高かったりする場合がある。このように、各ユーザについて同じ利用状況が取得される場合でも、それぞれのユーザによって、通話可能性を判定するために寄与する利用状況は異なることが想定される。

そこで、生成部１３３は、実際にユーザが架電に応答したか否かといった結果情報（すなわち、正解データ）を取得し、判定に用いた利用状況と結果との関係性を学習することで、学習を反映させたモデルをユーザごとに生成する。そして、判定部１３２は、生成部１３３によって生成されたモデルを用いて判定を行う。これにより、判定部１３２は、より判定の精度を向上させることができる。

以下に、モデル生成について具体的に説明する。なお、以下で示す学習手法やモデルは一例であり、生成部１３３は、既知の様々な手法を用いて、どのようなモデルを生成してもよい。すなわち、生成部１３３は、実施形態に係る判定処理に対して、ユーザが架電に応答したか否かという結果をフィードバックすることが可能であれば、いずれの学習手法を用いてもよい。

例えば、生成部１３３は、判定対象の日時において、ユーザが架電に応答したか否かを示した結果情報を、回帰分析における目的変数とする。そして、生成部１３３は、判定に用いられた各種利用状況を、回帰分析における説明変数とする。そして、生成部１３３は、目的変数と説明変数とを用いて、通話可能性を判定するためのモデルを生成する。なお、以下に説明する例では、図７で示した定義テーブル１２４に記載された利用状況を処理に用いるが、各スコアの数値については考慮しないものとする。また、以下では、架電に対してユーザが応答した例を正例とし、ユーザが応答しなかった例を負例として学習を行う例を示す。

例えば、生成部１３３は、実際にユーザが架電に応答したか否かと、判定に用いた利用状況との関係を示す式を生成する。さらに、生成部１３３は、各々の利用状況が、ユーザが架電に応答するという事象に対して、どのような重みを有するかを算出する。これにより、生成部１３３は、ユーザが架電に応答するという事象に対して、個々の説明変数がどのくらい寄与するのかといった情報を得ることができる。例えば、生成部１３３は、ユーザの一例であるユーザＵ０１に関するモデルを生成する場合には、下記式（１）を作成する。

ｙ_{（ユーザＵ０１）} ＝ ω_１・ｘ_１ ＋ ω_２・ｘ_２ ＋ ω_３・ｘ_３ ・・・＋ ω_Ｎ・ｘ_Ｎ ・・・（１）（Ｎは任意の数）

上記式（１）において、「ｙ_{（ユーザＵ０１）}」は、「ユーザＵ０１が実際に架電に応答したか否か」という事象を示す。例えば、上記式（１）の例では、「ｙ」を、「１」（応答した）か、「−１」（応答しなかった）で表すものとする。なお、生成部１３３は、算出を容易にするため、適宜、ｙの値として「−１」と「１」以外の数値を用いてもよい。

また、上記式（１）において、「ｘ」は、説明変数であり、ユーザ端末１０の利用状況に対応する。具体的には、上記式（１）における「ｘ_１」は、ユーザＵ０１の位置情報（より具体的には、「在宅していることを示す位置情報」）であるものとする。例えば、「ｘ_１」は、判定対象の日時において、ユーザＵ０１の自宅近傍の位置情報が取得されているか否かを示す。

また、上記式（１）における「ｘ_２」は、ユーザ端末１０を操作している操作情報であるものとする。例えば、「ｘ_２」は、判定対象の日時において、ユーザＵ０１がユーザ端末１０を操作しているか否かという操作の有無を示す。

また、上記式（１）における「ｘ_３」は、サービスにおけるユーザＵ０１の配送日程に関する情報である。例えば、「ｘ_３」は、判定対象の日時において、ユーザＵ０１が商品の配送の指定を行っているか否かを示す。すなわち、上記式（１）の右辺は、図７で示したような、ユーザ端末１０の各種利用状況の有無に対応する。

また、上記式（１）において、「ω」は、「ｘ」の係数であり、所定の重み値を示す。具体的には、「ω_１」は、「ｘ_１」の重み値であり、「ω_２」は、「ｘ_２」の重み値であり、「ω_３」は、「ｘ_３」の重み値である。このように、上記式（１）は、利用状況に対応する説明変数「ｘ」と、所定の重み値「ω」とを含む変数（例えば、「ω_１・ｘ_１」）を組合せることにより作成される。

例えば、判定対象の日時を、仮に「Ｔ１」とする。そして、Ｔ１において、ユーザＵ０１のサービスにおける利用状況として取得された情報が、「在宅していることを示す位置情報」と、「配送日程の指定」であったものとする。また、Ｔ１において、「操作情報」という説明変数に対応する利用状況は取得されなかったものとする。そして、Ｔ１では、結果としてユーザＵ０１が「架電に応答した」という結果が得られたとする。この場合、上記式（１）は、下記式（２）のように示される。

ｙ（＝１）_{（ユーザＵ０１、Ｔ１）} ＝ ω_１・ｘ_１（在宅していることを示す位置情報＝１） ＋ ω_２・ｘ_２（操作情報＝０） ＋ ω_３・ｘ_３（配送日程の指定＝１） ・・・（２）

上記式（２）で示されるように、利用状況が取得されなかった「ｘ_２」については「０」の値が代入される。この場合、少なくとも正例（ｙ＝１）の判定に寄与していた情報は、「在宅していることを示す位置情報」か、「配送日程の指定」である。

また、判定対象の日時を、仮に「Ｔ２」とする。そして、Ｔ２において、ユーザＵ０１のサービスにおける利用状況として取得された情報が、「在宅していることを示す位置情報」と、「操作情報」であったものとする。また、Ｔ２において、「配送日程の指定」という説明変数に対応する利用状況は取得されなかったものとする。そして、Ｔ２では、結果としてユーザＵ０１が「架電に応答しなかった」という結果が得られたとする。この場合、上記式（１）は、下記式（３）のように示される。

ｙ（＝１）_{（ユーザＵ０１、Ｔ２）} ＝ ω_１・ｘ_１（在宅していることを示す位置情報＝１） ＋ ω_２・ｘ_２（操作情報＝１） ＋ ω_３・ｘ_３（配送日程の指定＝０） ・・・（３）

上記式（３）で示されるように、利用状況が取得されなかった「ｘ_３」については「０」の値が代入される。この場合、少なくとも負例（ｙ＝−１）の判定に寄与していた情報は、「在宅していることを示す位置情報」と、「操作情報」である。

そして、生成部１３３は、上記式（２）や（３）のように、判定対象の日時ごとに式を生成し、生成した式を回帰分析のサンプルとする。そして、生成部１３３は、サンプルとなる式の演算処理を行うことにより、所定の重み値「ω」に対応する値を導出する。また、生成部１３３は、上記式（２）のようなサンプルとなる式を随時生成する。そして、生成部１３３は、生成した式の増加に従い、回帰的に上記式（２）や（３）を満たすような所定の重み値「ω」を決定する。言い換えれば、生成部１３３は、所定の説明変数が目的変数「ｙ」に与える影響を示す重み値「ω」を決定する。

仮に、ユーザＵ０１が「架電に応答した」という事象に対して、「在宅していることを示す位置情報」が他の変数と比較して寄与しているのであれば、「在宅していることを示す位置情報」に対応する重み値「ω_１」の値は、他の変数と比較して大きな正の値が算出されると推定される。このことは、ユーザＵ０１が在宅している場合には、ユーザＵ０１は、比較的架電に応答する傾向にあるユーザであることを示している。

また、仮に、ユーザＵ０１が「架電に応答しなかった」という事象に対して、「操作情報」が他の変数と比較して寄与しているのであれば、「操作情報」に対応する重み値「ω_２」の値は、他の変数と比較して大きな負の値が算出されると推定される。このことは、ユーザＵ０１がユーザ端末１０を操作している場合には、ユーザＵ０１は、比較的架電に応答しにくい傾向にあるユーザであることを示している。

また、仮に、ユーザＵ０１が「架電に応答した」という事象に対して、「配送日程の指定」が他の変数と比較して寄与しているのであれば、「配送日程の指定」に対応する重み値「ω_３」の値は、他の変数と比較して大きな正の値が算出されると推定される。このことは、ユーザＵ０１が商品等の配送日程を指定した日時においては、ユーザＵ０１は、比較的架電に応答する傾向にあるユーザであることを示している。また、仮に、ユーザＵ０１の架電の応答の事象に対して、「配送日程の指定」が他の変数と比較して寄与していないのであれば、「配送日程の指定」に対応する重み値「ω_３」の値は、学習が進むにつれ、「０」へと漸近していくと推定される。

なお、上記の例では、説明変数として３種類の利用状況を示したが、実際には、上記式（２）や（３）には、取得部１３１が取得した種々の利用状況に対応した種々の説明変数が含まれる。すなわち、生成部１３３は、図５や図６や図７等で例示したような、利用状況から抽出される種々の情報を説明変数として、モデルを生成する。

上記のようにして、生成部１３３は、ユーザが架電に応答するか否かという事象と、ユーザ端末１０の利用状況とを関連付けるモデルを生成する。なお、上記式（２）を用いた算出処理では、左辺を「１」や「−１」とするのではなく、所定の誤差を想定し、かかる誤差との差異を２乗した値が最小値となるよう近似する最小二乗法などの手法を用いて、「ω」の最適解を算出してもよい。

また、生成部１３３は、生成したモデルに、利用状況から抽出される情報を代入する場合には、「配送日程の指定」などの「有る」か「無し」かによって判定される変数については、「１」や「０」の数値を代入する。また、生成部１３３は、位置情報などの動的な値に関しては、例えば、自宅までの距離に応じた数値を適宜代入するようにしてもよい。例えば、生成部１３３は、既知の手法に従い、位置情報などの説明変数となりうる利用状況を示す情報を、モデルで扱うことができるよう正規化するなど、様々な既知の手法を応用してもよい。

また、生成部１３３は、モデルを生成した後に、取得部１３１が新たな利用状況を取得した場合には、随時、モデルを更新してもよい。これにより、生成部１３３は、ユーザの通話可能性を判定するためのモデルを最適化していくことができる。

また、生成部１３３は、上記のように、利用状況と通話可能性との関係性を学習した場合に、学習結果を定義テーブル１２４に反映させるようにしてもよい。上記のように、生成部１３３は、各々の利用状況が、ユーザが架電に応答するか否かに対して寄与する値（この例では、重み値ω）を、正の値か負の値で示すことができる。このため、生成部１３３は、算出した重み値に基づいて、各利用状況に対応するスコアを算出することで、例えば予め定義されていなかった利用状況についても、適切なスコアを付与することができる。より具体的には、学習に応じて、ユーザが架電に応答するという判定に寄与する利用状況には正のスコアを付与され、ユーザが架電に応答しないという判定に寄与する利用状況には負のスコアを付与される。

生成部１３３は、学習に関する情報や生成したモデルをモデル記憶部１２５に格納する。そして、判定部１３２は、学習の結果、重み値が代入された上記式（１）のようなモデルを用いて判定を行ってもよいし、ユーザに応じてスコアが定義された（調整された）定義テーブル１２４の情報を用いて判定を行ってもよい。

なお、生成部１３３は、必ずしも架電業者によって架電された際の結果情報を正解データとしなくてもよい。例えば、生成部１３３は、判定対象のユーザに類似する属性を有する他のユーザの結果情報や、同じ架電業者の顧客ユーザ同士の結果情報に基づいて、判定対象のユーザのモデルを生成してもよい。これにより、生成部１３３は、実際にユーザに架電がされなくても学習を行うことができるため、結果情報のサンプル数の不足を補うことができる。

（決定部１３４について）
決定部１３４は、判定部１３２によって判定されたユーザの通話可能性に基づいて、当該ユーザに対する架電の態様を決定する。

例えば、決定部１３４は、架電の態様として、架電業者の全顧客ユーザの通話可能性に基づいて、判定対象のユーザへ架電する順番を決定する。具体的には、決定部１３４は、判定対象の日時において、架電業者の顧客ユーザにおける通話可能性を高い順にソートする。そして、決定部１３４は、ソートした情報をリストとして、送信可能なファイルを作成する。

また、決定部１３４は、判定対象とされたユーザについて、どのタイミングで架電すればよいかといった日程を決定してもよい。すなわち、決定部１３４は、判定部１３２が判定したいくつかの判定対象日時において、当該ユーザの通話可能性の高い日時を抽出する。そして、決定部１３４は、通話可能性の高い日時を順にソートすることで、当該ユーザに対して、どのようなタイミング（日程）で架電すべきであるかを決定する。

決定部１３４は、所定のサービスを提供する態様を決定した場合、決定した情報を送信部１３５に送る。

（送信部１３５について）
送信部１３５は、所定のサービスを提供する提供者に、決定部１３４によって決定された態様に関する情報を送信する。

例えば、送信部１３５は、ある時間帯において、架電業者が顧客ユーザに架電すべきユーザの順番を示したリストを架電業者に送信する。あるいは、送信部１３５は、あるユーザに関して、架電するタイミングとして適切な日程を示したリストを架電業者に送信する。

〔４．ユーザ端末の構成〕
次に、図１１を用いて、実施形態に係るユーザ端末１０の構成について説明する。図１１は、実施形態に係るユーザ端末１０の構成例を示す図である。図１１に示すように、ユーザ端末１０は、通信部１１と、入力部１２と、表示部１３と、検知部１４と、記憶部１５と、制御部１６とを有する。なお、ユーザ端末１０が有する各処理部の接続関係は、図１１に示した接続関係に限られず、他の接続関係であってもよい。

通信部１１は、ネットワークＮと有線又は無線で接続され、サービスサーバ３０や判定装置１００との間で情報の送受信を行う。例えば、通信部１１は、ＮＩＣ等によって実現される。

入力部１２は、ユーザから各種操作を受け付ける入力装置である。例えば、入力部１２は、ユーザ端末１０に備えられた操作キー等によって実現される。また、入力部１２には、画像を撮影するための撮像装置（カメラ等）や、音声を集音する集音機器（マイク等）が含まれてもよい。

表示部１３は、各種情報を表示するための表示装置である。例えば、表示部１３は、液晶ディスプレイ等によって実現される。なお、ユーザ端末１０にタッチパネルが採用される場合には、入力部１２の一部と表示部１３とは一体化される。

検知部１４は、ユーザ端末１０に対する各種操作や、ユーザ端末１０の周囲の環境情報等を検知する。例えば、検知部１４は、各種情報を検知するセンサやアンテナにより実現される。具体的には、検知部１４は、ユーザ端末１０と接続されている機器に関する通信状況や、ユーザ端末１０の周囲の照度や騒音、ユーザ端末１０の物理的な動き、ユーザ端末１０の位置情報等を検知する。

例えば、検知部１４は、入力部１２に入力された情報に基づいて、ユーザの操作を検知する。すなわち、検知部１４は、入力部１２に画面をタッチする操作の入力があったことや、音声の入力があったこと等を検知する。また、検知部１４は、ユーザによって所定のアプリが起動されたことを検知してもよい。かかるアプリがユーザ端末１０内の撮像機能（例えば、カメラ）を動作させるアプリである場合、検知部１４は、ユーザによって撮像機能が利用されていることを検知する。また、検知部１４は、ユーザ端末１０内に備えられた加速度センサやジャイロセンサ等で検知されたデータに基づき、ユーザ端末１０自体が動かされているといった操作を検知してもよい。例えば、検知部１４は、ジャイロセンサ等で検知されたデータに基づき、ユーザ端末１０の傾き情報を検知するとともに、ユーザ端末１０がユーザの手の中にあることや、ユーザが片手でユーザ端末１０を取り扱っていること等を検知する。

また、検知部１４は、ユーザ端末１０の現在位置を検知する。具体的には、検知部１４は、ＧＰＳ（Global Positioning System）衛星から送出される電波を受信し、受信した電波に基づいてユーザ端末１０の現在位置を示す位置情報（例えば、緯度及び経度）を取得する。

なお、検知部１４は、ＧＰＳ以外の種々の手法により位置情報を取得してもよい。例えば、ユーザ端末１０が駅改札や商店等で使用される非接触型ＩＣカードと同等の機能を備えている場合（もしくは、ユーザ端末１０が非接触型ＩＣカードの履歴を読み取る機能を備えている場合）、ユーザ端末１０によって駅での乗車料金の決済等が行われた情報とともに、使用された位置が記録される。検知部１４は、かかる情報を検知し、位置情報として取得する。また、検知部１４は、ユーザ端末１０が特定のアクセスポイントと通信を行う際には、アクセスポイントから取得可能な位置情報を検知してもよい。また、位置情報は、ユーザ端末１０が備える光学式センサや、赤外線センサや、磁気センサ等によって取得されてもよい。

また、検知部１４は、ユーザ端末１０に接続される外部装置を検知する。例えば、検知部１４は、外部装置との相互の通信パケットのやり取りや、外部装置が発する信号等に基づいて、外部装置を検知する。具体的には、検知部１４は、外部装置が利用しているＷｉｆｉやＢｌｕｅｔｏｏｔｈ等の電波を検知する。また、検知部１４は、外部装置と通信が確立する場合に、外部装置との接続の種類を検知してもよい。例えば、検知部１４は、外部装置と有線で接続されているか、無線通信で接続されているかを検知する。また、検知部１４は、無線通信で用いられている通信方式等を検知してもよい。また、検知部１４は、外部装置が発する電波を検知する電波センサや、電磁波を検知する電磁波センサ等によって取得される情報に基づいて、外部装置を検知してもよい。外部装置の一例は、ユーザ端末１０を利用するユーザが利用する他のデバイス（他のユーザ端末１０）であり、例えば、ウェアラブルデバイスや、設置型のＩｏＴ機器等である。

また、検知部１４は、ユーザ端末１０における環境を検知する。検知部１４は、ユーザ端末１０に備えられた各種センサや機能を利用し、環境に関する情報を検知する。例えば、検知部１４は、ユーザ端末１０の周囲の音を収集するマイクロフォンや、ユーザ端末１０の周囲の照度を検知する照度センサや、ユーザ端末１０の物理的な動きを検知する加速度センサ（又は、ジャイロセンサなど）や、ユーザ端末１０の周囲の湿度を検知する湿度センサや、ユーザ端末１０の所在位置における磁場を検知する地磁気センサ等を利用する。そして、検知部１４は、各種センサを用いて、種々の情報を検知する。例えば、検知部１４は、ユーザ端末１０の周囲における騒音レベルや、ユーザ端末１０の周囲の照度レベルを検知する。さらに、検知部１４は、カメラで撮影された写真や映像に基づいて周囲の環境情報を検知してもよい。

また、ユーザ端末１０は、検知部１４によって検知された情報に基づいて、ユーザ端末１０のコンテキストを示すコンテキスト情報を取得するようにしてもよい。上述のように、ユーザ端末１０は、内蔵された各種センサ（検知部１４）により、位置、加速度、温度、重力、回転（角速度）、照度、地磁気、圧力、近接、湿度、回転ベクトルといった、種々の物理量をコンテキスト情報として取得する。また、ユーザ端末１０は、内蔵する通信機能を利用して、各種装置との接続状況（例えば、通信の確立に関する情報や、利用している通信規格）などを、コンテキスト情報として取得してもよい。

（記憶部１５について）
記憶部１５は、各種情報を記憶する。記憶部１５は、例えば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。記憶部１５には、サービス情報記憶部１５１が含まれる。

サービス情報記憶部１５１は、例えば、ユーザが利用したサービスに関する情報を記憶する。具体的には、サービス情報記憶部１５１は、ユーザが利用したサービスにおける行動履歴（ログ）を記憶する。例えば、サービス情報記憶部１５１は、ユーザ端末１０内にインストールされたアプリの使用履歴を記憶する。なお、ユーザ端末１０は、例えば判定装置１００の指示に従い、一定時間ごとに、サービス情報記憶部１５１に記憶された情報を判定装置１００にアップロードするようにしてもよい。

制御部１６は、コントローラであり、例えば、ＣＰＵやＭＰＵ等によって、ユーザ端末１０内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１６は、コントローラであり、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

制御部１６は、ユーザ端末１０において行われる各種処理を制御する。図１１に示すように、制御部１６は、受信部１６１と、取得部１６２と、送信部１６３とを有し、以下に説明する情報処理の機能や作用を実現または実行する。

受信部１６１は、各種情報を受信する。例えば、受信部１６１は、サービスサーバ３０や判定装置１００から送信される情報を受信する。また、受信部１６１は、検知部１４が検知する各種情報を受信する。

取得部１６２は、各種情報やデータを取得する。例えば、取得部１６２は、サービスサーバ３０にアクセスすることで、ユーザが閲覧を所望するウェブページを取得する。また、取得部１６２は、アプリのダウンロードサイト等を介して、各種アプリに関する情報を取得する。

送信部１６３は、各種情報を送信する。例えば、送信部１６３は、検知部１４によって検知されたユーザ端末１０の利用状況に関する情報を、サービスサーバ３０や判定装置１００に送信する。また、送信部１６３は、記憶部１５等を参照し、ユーザ端末１０に蓄積されたユーザ端末１０の利用状況に関する情報を判定装置１００に送信する。

〔５．処理手順〕
次に、図１２乃至図１４を用いて、実施形態に係る判定装置１００による処理の手順について説明する。まず、図１２を用いて、通話可能性を判定する処理手順を説明する。図１２は、実施形態に係る処理手順を示すフローチャート（１）である。

図１２に示すように、判定装置１００は、ユーザ端末１０の利用状況を取得する（ステップＳ１０１）。そして、判定装置１００は、設定された対象日時（通話可能性を判定するタイミング）が到来したか否かを判定する（ステップＳ１０２）。設定された対象日時が到来していない場合には（ステップＳ１０２；Ｎｏ）、判定装置１００は、設定された対象日時が到来するまで待機し、ユーザ端末１０の利用状況を取得する処理を継続する。

一方、設定された対象日時が到来した場合には（ステップＳ１０２；Ｙｅｓ）、判定装置１００は、例えば定義テーブル１２４等を参照することで、利用状況と通話可能性との関係性を参照する（ステップＳ１０３）。

続けて、判定装置１００は、参照した情報に基づいて、ユーザごとに、通話可能性を示す指標値となるスコアを算出する（ステップＳ１０４）。そして、判定装置１００は、算出したスコアに基づいて、ユーザの通話可能性を判定する（ステップＳ１０５）。さらに、判定装置１００は、判定結果に基づいて、ユーザに対する架電の態様を決定する（ステップＳ１０６）。続けて、判定装置１００は、決定した態様を架電業者に送信する（ステップＳ１０７）。

次に、図１３を用いて、モデル生成に関する処理手順を説明する。図１３は、実施形態に係る処理手順を示すフローチャート（２）である。

判定装置１００は、架電が行われた後に、当該架電に関する結果情報を取得する（ステップＳ２０１）。そして、判定装置１００は、学習に充分な結果情報が蓄積されたか否かを判定する（ステップＳ２０２）。学習に充分な結果情報が蓄積されていない場合（ステップＳ２０２；Ｎｏ）、判定装置１００は、結果情報を取得する処理を継続する。

一方、学習に充分な結果情報が蓄積された場合（ステップＳ２０２；Ｙｅｓ）、判定装置１００は、学習結果に基づいて、ユーザごとのモデルを生成する（ステップＳ２０３）。そして、判定装置１００は、生成したモデルをユーザごとに対応付けて、記憶部１２０内に格納する（ステップＳ２０４）。

次に、図１４を用いて、モデル更新に関する処理手順を説明する。図１４は、実施形態に係る処理手順を示すフローチャート（３）である。

判定装置１００は、例えば架電業者から、判定の要求を受け付けたか否かを判定する（ステップＳ３０１）。判定の要求を受け付けていない場合（ステップＳ３０１；Ｎｏ）、判定装置１００は、判定の要求を受け付けるまで待機する。

一方、判定の要求を受け付けた場合（ステップＳ３０１；Ｙｅｓ）、判定装置１００は、判定に用いる利用状況を取得する（ステップＳ３０２）。そして、判定装置１００は、取得した利用状況をモデルに入力して、ユーザに対応したモデルを用いて、当該ユーザの通話可能性を判定する（ステップＳ３０３）。

その後、判定装置１００は、結果情報を取得したか否かを判定する（ステップＳ３０４）。結果情報を取得していない場合（ステップＳ３０４；Ｎｏ）、判定装置１００は、取得するまで待機する。一方、結果状況を取得した場合（ステップＳ３０４；Ｙｅｓ）、判定装置１００は、取得した結果情報に基づいて、モデルを更新する（ステップＳ３０５）。判定装置１００は、ステップＳ３０１からステップＳ３０５の処理を繰り返すことで、ユーザごとに最適化されたモデルを生成する。

〔６．変形例〕
上述した判定装置１００は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、判定装置１００の他の実施形態について説明する。

〔６−１．利用状況〕
判定装置１００は、上述した実施形態において例示した利用状況以外に、種々の利用状況を取得してもよい。

例えば、判定装置１００は、サービスにおける利用状況として、ユーザのＳＮＳへの書き込みや、ＳＮＳへの投稿情報を取得してもよい。例えば、ＳＮＳへの書き込みや投稿情報には、ユーザ端末１０の位置情報が含まれる場合がある。

また、判定装置１００は、テキスト解析等を用いて、ＳＮＳへの書き込み等からスケジュール情報を取得してもよい。例えば、ＳＮＳの書き込みには、「２０日にＡＡＡ県に行っています」や、「１５日にはＢＢＢ県に行っていました」といったテキストが含まれる場合がある。判定装置１００は、形態素解析等を用いて、これらのテキストをスケジュール情報に変換し、これらのテキストに基づいてスケジュール情報を取得してもよい。例えば、ユーザは、何らかのスケジュールが予定されている場合には、当該日時において、架電に応答する可能性が低くなる可能性がある。判定装置１００は、ＳＮＳの書き込みや投稿等から、かかる情報を取得し、取得した情報を判定要素として用いてもよい。

また、判定装置１００は、サービスにおける利用状況として、路線検索サービスにおける検索履歴等を取得してもよい。例えば、ユーザが、自宅から離れた地域の路線について検索を行った場合、その検索に係る日時においては、ユーザが自宅にいない可能性が高いと推定できる。このため、判定装置１００は、路線検索のログを通話可能性の判定処理の一要素として用いてもよい。

また、判定装置１００は、サービスにおける利用状況として、天気情報サービスにおける検索履歴等を取得してもよい。例えば、ユーザが、自宅から離れた地域の数日後の天気について検索を行った場合、その検索に係る日時においては、ユーザが自宅にいない可能性が高いと推定できる。このため、判定装置１００は、天気情報サービスのログを通話可能性の判定処理の一要素として用いてもよい。

また、判定装置１００は、ユーザ端末１０で起動されているアプリに関する情報を取得してもよい。例えば、ユーザが、カーナビアプリを起動している場合には、ユーザは架電に応答できない可能性が高いと推定できる。あるいは、ユーザが、自宅に設置された家電を操作するアプリを起動している場合には、ユーザは自宅にいる可能性が高いと推定できる。このように、判定装置１００は、アプリの起動や操作情報に基づいて、通話可能性を判定してもよい。

〔６−２．全体情報の利用〕
上記実施形態では、ユーザごとの利用状況を用いて、ユーザに対応したモデルを生成する例を示した。ここで、判定装置１００は、ユーザ個人の情報のみならず、判定対象となったユーザの全体から取得される傾向等を反映させた判定処理を行ってもよい。

例えば、通話可能性の判定において、利用状況のうち、どのような情報がより寄与するか否かは、個人ごとに傾向があるとともに、ユーザ全体においても傾向があると想定される。このため、判定装置１００は、特定のユーザの学習を、他のユーザにおける利用状況と結果情報との関係性を利用して行ってもよい。

例えば、判定装置１００は、判定対象となるユーザと類似する属性を有するユーザを抽出する。具体的には、判定装置１００は、判定対象となるユーザと、性別や年齢や居住地等が類似するユーザを抽出する。そして、判定装置１００は、抽出したユーザから取得された利用状況と結果情報との関係性を示す式を生成する。そして、判定装置１００は、生成した式を、判定対象となるユーザの学習に利用する。これにより、判定装置１００は、個人のユーザのみならず、全体の傾向が反映されたモデルを生成することができる。

〔６−３．通話可能性〕
実施形態では、通話可能性をパーセント表記する例を示したが、判定装置１００は、必ずしも通話可能性をパーセントのような割合で示すことを要しない。例えば、判定装置１００は、具体的な数値で通話可能性を示さず、架電対象とされる全ユーザにおける相対的な通話可能性（例えば、架電する順番など）を示すだけでもよい。

〔６−４．ユーザ端末〕
上記実施形態では、図１１を用いてユーザ端末１０の構成例を示したが、ユーザ端末１０は、図１１で示した構成を必ずしも全て有していなくてもよい。ユーザ端末１０には、上述のように、スマートフォンやタブレット端末のようなスマートデバイスのみならず、通信機能を有する眼鏡型端末や、あるいは、ユーザの心拍を記憶する心拍測定器など、種々のウェアラブルデバイスが含まれる。この場合、ユーザ端末１０は、必ずしもユーザから入力を受け付けるのではなく、自動的にユーザのサービスにおける利用状況を取得し、取得した情報を通信ネットワークに送信するなどの機能を持ちうる。すなわち、ユーザ端末１０は、いわゆるＩｏＴを実現するような、所定の通信機能を有するデバイスであれば、必ずしも図１１で示した構成を有していなくてもよい。

〔７．ハードウェア構成〕
上述してきた実施形態に係る判定装置１００やユーザ端末１０は、例えば図１５に示すような構成のコンピュータ１０００によって実現される。以下、判定装置１００を例に挙げて説明する。図１５は、判定装置１００の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に記憶されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を記憶する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（図２に示したネットワークＮに対応）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを、通信網５００を介して他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して生成したデータを出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に記憶されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が実施形態に係る判定装置１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。また、ＨＤＤ１４００には、記憶部１２０内のデータが記憶される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から通信網５００を介してこれらのプログラムを取得してもよい。

〔８．その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図３に示した判定部１３２と、決定部１３４とは統合されてもよい。また、例えば、記憶部１２０に記憶される情報は、ネットワークＮを介して、外部に備えられた所定の記憶装置に記憶されてもよい。

また、上記実施形態では、判定装置１００が、例えば、利用状況を取得する取得処理と、通話可能性を判定する判定処理と、モデルを生成する生成処理とを行う例を示した。しかし、上述した判定装置１００は、取得処理を行う取得装置と、判定処理を行う判定装置と、生成処理を行う生成装置とに分離されてもよい。この場合、取得装置は、少なくとも取得部１３１を有する。判定装置は、少なくとも判定部１３２を有する。生成装置は、少なくとも生成部１３３を有する。そして、上記の判定装置１００による処理は、受付装置と、判定装置と、配信装置との各装置を有する判定処理システム１によって実現される。

また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

〔９．効果〕
上述してきたように、実施形態に係る判定装置１００は、取得部１３１と、判定部１３２とを有する。取得部１３１は、ユーザが利用するユーザ端末１０における利用状況を取得する。判定部１３２は、取得部１３１によって取得された利用状況と、架電に対してユーザが通話を行う可能性である通話可能性との関係性に基づいて、所定のタイミングにおけるユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、ユーザ端末１０における利用状況に基づいてユーザの通話可能性を判定することで、架電業者に対して架電タイミングに関する要望を行ったり、架電タイミングの登録を行ったりせずとも、ユーザの日常的な状況に基づいて、ユーザの通話可能性を判定することができる。また、判定装置１００は、ユーザ端末１０の利用状況に基づいて判定を行うことで、リアルタイムな情報を判定させて通話可能性を判定することができる。これにより、判定装置１００は、架電に対してユーザとの通話が成立する可能性を精度よく判定することができる。

また、実施形態に係る判定装置１００は、取得部１３１によって取得された利用状況と、ユーザへの架電に対してユーザが通話を行ったか否かを示す結果情報との関係性を学習することにより、ユーザの通話可能性を算出するモデルを生成する生成部１３３をさらに備える。判定部１３２は、生成部１３３によって生成されたモデルを用いて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、予め定義された関係性のみならず、学習によって通話可能性の結果が反映されたモデルを用いてユーザの通話可能性を判定してもよい。これにより、判定装置１００は、ユーザの通話可能性を精度よく判定することができる。

また、判定部１３２は、所定のタイミングの曜日に基づいて、ユーザの通話可能性を判定する。また、判定部１３２は、所定のタイミングの時間帯に基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、曜日や時間帯ごとに通話可能性を判定する。これにより、判定装置１００は、過去のユーザの行動履歴等に基づいて判定を行うことができるため、判定の精度を向上させることができる。

また、取得部１３１は、利用状況として、ユーザ端末１０の位置情報を取得する。判定部１３２は、位置情報に基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、位置情報のような、ユーザの日常的な行動情報に基づいて、ユーザの通話可能性を判定することができる。これにより、判定装置１００は、架電業者に対する架電タイミングの登録のような負担をユーザに掛けさせることなく、判定処理を行うことができる。

また、判定部１３２は、取得部１３１によって取得された位置情報が、ユーザの自宅の位置を示す位置情報であるか否かに基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、ユーザが在宅するか否かを位置情報に基づいて判定し、そのうえでユーザの通話可能性を判定する。これにより、判定装置１００は、判定精度を向上させることができる。

また、取得部１３１は、位置情報が示す位置からユーザの自宅までユーザが移動した場合に経過すると推定される時間情報を取得する。判定部１３２は、時間情報に基づいて、所定のタイミングにおけるユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、判定対象となるタイミングの位置情報に限らず、判定の前に取得された位置情報から、ユーザの在宅可能性を判定したうえで、ユーザの通話可能性を判定してもよい。すなわち、判定装置１００は、判定のタイミングのみならず、様々なタイミングで取得された利用状況に基づいて判定を行うことができる。

また、取得部１３１は、利用状況として、ユーザ端末１０に対するユーザの物理的な動作を示す動作情報を取得する。判定部１３２は、動作情報に基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、ユーザの日常的な動作に基づいて通話可能性を判定してもよい。すなわち、判定装置１００は、ユーザに意識的に何らかの行動を採らせるのではなく、ユーザの自然な行動を判定要素として用いることができるため、ユーザにとって負担のない判定処理を行うことができる。

また、取得部１３１は、利用状況として、ユーザ端末１０をユーザが操作中であるか否かを示す操作情報を取得する。判定部１３２は、操作情報に基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、ユーザが着信を受ける可能性が高いと想定される状況に基づいて通話可能性を判定することで、判定の精度を向上させることができる。

また、取得部１３１は、利用状況として、ユーザ端末１０における加速度、もしくは、ユーザ端末１０の移動速度を取得する。判定部１３２は、加速度もしくは移動速度に基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、ユーザが交通機関を利用しているか、あるいは、歩行中であるかといった、ユーザの状況（コンテキスト）に基づいて判定を行うことで、判定の精度を向上させることができる。

また、取得部１３１は、利用状況として、ユーザ端末１０の周辺における照度情報を取得する。判定部１３２は、照度情報に基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、ユーザがユーザ端末１０を取り扱っている状況を推定して判定を行うことで、判定の精度を向上させることができる。

また、取得部１３１は、利用状況として、ユーザ端末１０に音声出力装置が接続されているか否かを示す接続情報を取得する。判定部１３２は、接続情報に基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、ユーザがユーザ端末１０を利用して音楽を聴いているといった状況を加味して判定を行うことで、判定の精度を向上させることができる。

また、取得部１３１は、利用状況として、ユーザ端末１０におけるアプリ操作に関する情報であるアプリ操作情報を取得する。判定部１３２は、アプリ操作情報に基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、ユーザがアプリを操作しているという状況と、架電に応答する可能性とを判定要素とすることで、多様な判定要素を用いて、通話可能性を判定することができる。

また、取得部１３１は、ユーザが操作しているアプリを識別する識別情報、又は、アプリのカテゴリを取得する。判定部１３２は、アプリを識別する識別情報、又は、アプリのカテゴリに基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、アプリの種別やカテゴリ別に判定を行ってもよい。これにより、判定装置１００は、例えば、ビジネス系のアプリを操作しているユーザは電話に出易く、ゲーム系のアプリを操作している電話に出にくいなど、様々なユーザの行動に対応して、通話可能性を判定することができる。

また、取得部１３１は、利用状況として、ユーザ端末１０を介してユーザが利用したサービスに関する利用情報を取得する。

このように、実施形態に係る判定装置１００は、ユーザ端末１０自体の状況のみならず、ユーザ端末１０を介して利用されるサービスの利用状況に基づいて判定を行うことで、より多様な要素を用いて判定を行うことができる。

また、取得部１３１は、購買に係るサービスの利用において、ユーザが指定した配送日程に関する情報を取得する。判定部１３２は、配送日程に関する情報に基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、配送日程の指定など、架電に応答する可能性に影響を与えると想定される事象を加味して、ユーザの通話可能性を判定してもよい。これにより、判定装置１００は、ユーザの行動を的確に反映させた判定処理を行うことができる。

また、取得部１３１は、交通機関、旅行、飲食施設、もしくは宿泊施設の少なくともいずれか一つの予約に係るサービスの利用において、ユーザが予約した予約日程に関する情報を取得する。判定部１３２は、予約日程に関する情報に基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、予約情報など、架電に応答する可能性に影響を与えると想定される事象を加味して、ユーザの通話可能性を判定してもよい。これにより、判定装置１００は、ユーザの行動を的確に反映させた判定処理を行うことができる。

また、取得部１３１は、ユーザがサービスに登録した属性情報のうち、ユーザの職種又は勤務時間に関する情報を取得する。判定部１３２は、ユーザの職種又は勤務時間に基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、電話に出易い職種（外回りの営業職など）と、電話に出にくい職種（工場内での製作業務など）との相違を判定要素としたり、勤務時間を判定要素としたりすることができる。これにより、判定装置１００は、判定の精度を向上させることができる。

また、取得部１３１は、ユーザ端末１０と、ユーザの自宅に設置された情報機器における通信状況に関する情報を取得する。判定部１３２は、通信状況に関する情報に基づいて、ユーザの通話可能性を判定する。

このように、実施形態に係る判定装置１００は、ユーザ端末１０等の情報機器同士の通信状況を取得することにより、ユーザが在宅しているなどのユーザのコンテキストを推定し、推定した情報を反映させた判定を行うことができる。これにより、判定装置１００は、判定の精度を向上させることができる。

また、実施形態に係る判定装置１００は、判定部１３２によって判定されたユーザの通話可能性に基づいて、ユーザに対する架電の態様を決定する決定部１３４と、ユーザに架電する者に、決定部１３４によって決定された架電の態様を送信する送信部１３５と、をさらに備える。

このように、実施形態に係る判定装置１００は、判定結果を反映させた架電の態様を架電業者等に送信してもよい。これにより、判定装置１００は、架電に応答するか否かに応じて効率が変わるサービスを提供する事業者等に対して、有用な情報を提供することができる。

以上、本願の実施形態を図面に基づいて詳細に説明したが、これは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

１ 判定処理システム
１０ ユーザ端末
３０ サービスサーバ
５０ 架電業者装置
１００ 判定装置
１１０ 通信部
１２０ 記憶部
１２１ 利用状況記憶部
１２２ 属性テーブル
１２３Ａ センサテーブル
１２３Ｂ サービステーブル
１２４ 定義テーブル
１２５ モデル記憶部
１２６ 学習データテーブル
１２７ モデルテーブル
１２９ 架電態様記憶部
１３０ 制御部
１３１ 取得部
１３２ 判定部
１３３ 生成部
１３４ 決定部
１３５ 送信部

Claims (25)

1. ユーザが利用する端末における利用状況に関する情報であってユーザが携帯する当該端末を介して検知されるユーザの行動に関する情報を取得する取得部と、
   前記取得部によって取得された利用状況と、架電に対するユーザの通話の可能性との関係性に基づいて、所定のタイミングにおける当該ユーザの通話の可能性スコアを算出する判定部と、
   を備えたことを特徴とする算出装置。
2. 前記取得部によって取得された利用状況と、前記ユーザへの架電に対する当該ユーザの通話の結果情報との関係性を学習することにより、当該ユーザの通話の可能性スコアを算出するモデルを生成する生成部、
   をさらに備え、
   前記判定部は、
   前記生成部によって生成されたモデルを用いて、前記ユーザの通話の可能性スコアを算出する、
   ことを特徴とする請求項１に記載の算出装置。
3. ユーザが利用する端末における利用状況を取得する取得部と、
   前記取得部によって取得された利用状況と、架電に対するユーザの通話の可能性との関係性に基づいて、所定のタイミングにおける当該ユーザの通話の可能性スコアを算出する判定部と、
   前記取得部によって取得された利用状況と、各ユーザへの架電に対する当該各ユーザの通話の結果情報との関係性を学習することにより、各ユーザに対応したモデルであって当該各ユーザの通話の可能性スコアを算出するモデルを生成する生成部と、を備え、
   前記判定部は、
   前記生成部によって生成された各ユーザに対応するモデルを用いて、前記取得部によって取得された利用状況のうち各ユーザが当該端末を利用する個々の状況を示す情報に対応した個々の通話の可能性スコアを算出する、
   ことを特徴とする算出装置。
4. 前記判定部は、
   前記所定のタイミングの曜日に基づいて、前記ユーザの通話の可能性スコアを算出する、
   ことを特徴とする請求項１〜３のいずれか一つに記載の算出装置。
5. 前記判定部は、
   前記所定のタイミングの時間帯に基づいて、前記ユーザの通話の可能性スコアを算出する、
   ことを特徴とする請求項１〜４のいずれか一つに記載の算出装置。
6. 前記取得部は、
   前記利用状況として、前記端末の位置情報を取得し、
   前記判定部は、
   前記位置情報に対応するスコアに基づいて、前記ユーザの通話の可能性スコアを算出する、
   ことを特徴とする請求項１〜５のいずれか一つに記載の算出装置。
7. 前記判定部は、
   前記取得部によって取得された位置情報が、前記ユーザの自宅の位置を示す位置情報であるか否かに基づいて、前記ユーザの通話の可能性スコアを算出する、
   ことを特徴とする請求項６に記載の算出装置。
8. 前記取得部は、
   前記位置情報が示す位置から当該ユーザの自宅まで前記ユーザが移動した場合に経過すると推定される時間情報を取得し、
   前記判定部は、
   前記時間情報に対応するスコアに基づいて、前記所定のタイミングにおける前記ユーザの通話の可能性スコアを算出する、
   ことを特徴とする請求項７に記載の算出装置。
9. 前記取得部は、
   前記利用状況として、前記端末に対するユーザの物理的な動作を示す動作情報を取得し、
   前記判定部は、
   前記動作情報に対応するスコアに基づいて、前記ユーザの通話の可能性スコアを算出する、
   ことを特徴とする請求項１〜８のいずれか一つに記載の算出装置。
10. 前記取得部は、
    前記利用状況として、前記端末を前記ユーザが操作中であるか否かを示す操作情報を取得し、
    前記判定部は、
    前記操作情報に対応するスコアに基づいて、前記ユーザの通話の可能性スコアを算出する、
    ことを特徴とする請求項１〜９のいずれか一つに記載の算出装置。
11. 前記取得部は、
    前記利用状況として、前記端末における加速度、もしくは、前記端末の移動速度を取得し、
    前記判定部は、
    前記加速度もしくは移動速度に対応するスコアに基づいて、前記ユーザの通話の可能性スコアを算出する、
    ことを特徴とする請求項１〜１０のいずれか一つに記載の算出装置。
12. 前記取得部は、
    前記利用状況として、前記端末の周辺における照度情報を取得し、
    前記判定部は、
    前記照度情報に対応するスコアに基づいて、前記ユーザの通話の可能性スコアを算出する、
    ことを特徴とする請求項１〜１１のいずれか一つに記載の算出装置。
13. 前記取得部は、
    前記利用状況として、前記端末に音声出力装置が接続されているか否かを示す接続情報を取得し、
    前記判定部は、
    前記接続情報に対応するスコアに基づいて、前記ユーザの通話の可能性スコアを算出する、
    ことを特徴とする請求項１〜１２のいずれか一つに記載の算出装置。
14. 前記取得部は、
    前記利用状況として、前記端末におけるアプリ操作に関する情報であるアプリ操作情報を取得し、
    前記判定部は、
    前記アプリ操作情報に対応するスコアに基づいて、前記ユーザの通話の可能性スコアを算出する、
    ことを特徴とする請求項１〜１３のいずれか一つに記載の算出装置。
15. 前記取得部は、
    前記ユーザが操作しているアプリを識別する識別情報、又は、アプリのカテゴリを取得し、
    前記判定部は、
    前記アプリを識別する識別情報、又は、アプリのカテゴリに基づいて、前記ユーザの通話の可能性スコアを算出する、
    ことを特徴とする請求項１４に記載の算出装置。
16. 前記取得部は、
    前記利用状況として、前記端末を介して前記ユーザが利用したサービスに関する利用情報を取得する、
    ことを特徴とする請求項１〜１５のいずれか一つに記載の算出装置。
17. 前記取得部は、
    購買に係るサービスの利用において、前記ユーザが指定した配送日程に関する情報を取得し、
    前記判定部は、
    前記配送日程に関する情報に対応するスコアに基づいて、前記ユーザの通話の可能性スコアを算出する、
    ことを特徴とする請求項１６に記載の算出装置。
18. 前記取得部は、
    交通機関、旅行、飲食施設、もしくは宿泊施設の少なくともいずれか一つの予約に係るサービスの利用において、前記ユーザが予約した予約日程に関する情報を取得し、
    前記判定部は、
    前記予約日程に関する情報に対応するスコアに基づいて、前記ユーザの通話の可能性スコアを算出する、
    ことを特徴とする請求項１６又は１７に記載の算出装置。
19. 前記取得部は、
    前記ユーザがサービスに登録した属性情報のうち、前記ユーザの職種又は勤務時間に関する情報を取得し、
    前記判定部は、
    前記ユーザの職種又は勤務時間に対応するスコアに基づいて、当該ユーザの通話の可能性スコアを算出する、
    ことを特徴とする請求項１６〜１８のいずれか一つに記載の算出装置。
20. 前記取得部は、
    前記端末と、前記ユーザの自宅に設置された情報機器における通信状況に関する情報を取得し、
    前記判定部は、
    前記通信状況に関する情報に対応するスコアに基づいて、前記ユーザの通話の可能性スコアを算出する、
    ことを特徴とする請求項１〜１９のいずれか一つに記載の算出装置。
21. 前記判定部によって算出された前記ユーザの通話の可能性スコアに基づいて、当該ユーザに対する架電の態様を決定する決定部と、
    前記ユーザに架電する者に、前記決定部によって決定された架電の態様を送信する送信部と、
    をさらに備えたことを特徴とする請求項１〜２０のいずれか一つに記載の算出装置。
22. コンピュータが実行する判定方法であって、
    ユーザが利用する端末における利用状況に関する情報であってユーザが携帯する当該端末を介して検知されるユーザの行動に関する情報を取得する取得工程と、
    前記取得工程によって取得された利用状況と、架電に対するユーザの通話の可能性との関係性に基づいて、所定のタイミングにおける当該ユーザの通話の可能性スコアを算出する算出工程と、
    を含んだことを特徴とする算出方法。
23. ユーザが利用する端末における利用状況に関する情報であってユーザが携帯する当該端末を介して検知されるユーザの行動に関する情報を取得する取得手順と、
    前記取得手順によって取得された利用状況と、架電に対するユーザの通話の可能性との関係性に基づいて、所定のタイミングにおける当該ユーザの通話の可能性スコアを算出する算出手順と、
    をコンピュータに実行させることを特徴とする算出プログラム。
24. コンピュータが実行する判定方法であって、
    ユーザが利用する端末における利用状況を取得する取得工程と、
    前記取得工程によって取得された利用状況と、架電に対するユーザの通話の可能性との関係性に基づいて、所定のタイミングにおける当該ユーザの通話の可能性スコアを算出する算出工程と、
    前記取得工程によって取得された利用状況と、各ユーザへの架電に対する当該各ユーザの通話の結果情報との関係性を学習することにより、各ユーザに対応したモデルであって当該各ユーザの通話の可能性スコアを算出するモデルを生成する生成工程と、を含み、
    前記算出工程は、
    前記生成工程によって生成された各ユーザに対応するモデルを用いて、前記取得工程によって取得された利用状況のうち各ユーザが当該端末を利用する個々の状況を示す情報に対応した個々の通話の可能性スコアを算出する、
    ことを特徴とする算出方法。
25. ユーザが利用する端末における利用状況を取得する取得手順と、
    前記取得手順によって取得された利用状況と、架電に対するユーザの通話の可能性との関係性に基づいて、所定のタイミングにおける当該ユーザの通話の可能性スコアを算出する算出手順と、
    前記取得手順によって取得された利用状況と、各ユーザへの架電に対する当該各ユーザの通話の結果情報との関係性を学習することにより、各ユーザに対応したモデルであって当該各ユーザの通話の可能性スコアを算出するモデルを生成する生成手順と、をコンピュータに実行させ、
    前記算出手順は、
    前記生成手順によって生成された各ユーザに対応するモデルを用いて、前記取得手順によって取得された利用状況のうち各ユーザが当該端末を利用する個々の状況を示す情報に対応した個々の通話の可能性スコアを算出する、
    ことを特徴とする算出プログラム。

Images