特許 7495595 サービス提供装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-05-28

(45)【発行日】2024-06-05

(54)【発明の名称】サービス提供装置

(51)【国際特許分類】

   G06Q 30/02 20230101AFI20240529BHJP

【ＦＩ】

G06Q30/02

【請求項の数】 9

(21)【出願番号】P 2020023647

(22)【出願日】2020-02-14

(65)【公開番号】P2021128615

(43)【公開日】2021-09-02

【審査請求日】2023-02-13

(73)【特許権者】

【識別番号】000220066

【氏名又は名称】テイ・エス テック株式会社

(74)【代理人】

【識別番号】100154380

【弁理士】

【氏名又は名称】西村 隆一

(74)【代理人】

【識別番号】100081972

【弁理士】

【氏名又は名称】吉田 豊

(72)【発明者】

【氏名】田中 真

【審査官】中野 修平

(56)【参考文献】

【文献】特開２０１９－１０５９６６（ＪＰ，Ａ）

【文献】特開２０１０－００８０７２（ＪＰ，Ａ）

【文献】国際公開第２０１２／１３１８３５（ＷＯ，Ａ１）

【文献】中国特許出願公開第１０７２１５３３０（ＣＮ，Ａ）

【文献】特開２０１０－１７８０７６（ＪＰ，Ａ）

【文献】特開２０２０－００９０７５（ＪＰ，Ａ）

【文献】特開２００５－２３３９７２（ＪＰ，Ａ）

【文献】国際公開第２０１７／１７９２８２（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

車両に搭載された複数のシートにそれぞれ設けられ、着座状態または非着座状態を検出する複数の着座センサと、
前記複数の着座センサによる検出結果に基づいて、前記車両の乗車人数を含む乗車情報を生成する情報生成部と、
前記情報生成部により生成された乗車情報に基づいて、前記車両のユーザに提供するサービスを決定するサービス決定部と、を備え、
前記サービス決定部は、前記情報生成部により生成された乗車情報に基づいて、前記車両のユーザに提案するアプリケーションプログラムおよび提案時期を決定し、前記情報生成部により生成されて記憶部に蓄積された乗車情報に基づいて、前記車両のユーザが前記車両から降車してから所定時間後の前記提案時期に、前記車両のユーザに前記アプリケーションプログラムを提案することを決定することを特徴とするサービス提供装置。

【請求項2】

請求項１に記載のサービス提供装置において、
前記車両の車内で、前記車両のユーザが携帯する携帯端末と通信する通信部をさらに備え、
前記サービス決定部は、前記通信部を介して入力された前記携帯端末からの情報と前記情報生成部により生成された乗車情報とに基づいて、前記車両のユーザに提供するサービスを決定することを特徴とするサービス提供装置。

【請求項3】

請求項２に記載のサービス提供装置において、
前記車両のユーザにユーザ情報の入力を要求する情報要求部と、
前記車両のユーザにより入力された前記ユーザ情報を取得する情報取得部と、をさらに備え、
前記情報要求部は、前記情報生成部により生成された乗車情報に基づいて、前記車両のユーザが前記車両に乗車している乗車時以外の非乗車時に、前記ユーザ情報の入力を要求し、
前記サービス決定部は、前記情報取得部により取得された前記ユーザ情報にさらに基づいて、前記車両のユーザに提供するサービスを決定することを特徴とするサービス提供装置。

【請求項4】

請求項３に記載のサービス提供装置において、
前記サービス決定部は、入力層と、複数の中間層と、出力層と、を有する予め学習されたニューラルネットワークを介して前記車両のユーザに提供するサービスを決定するように構成され、
前記入力層は、前記情報生成部により生成された乗車情報と、前記情報取得部により取得された前記ユーザ情報と、を取得し、
前記出力層は、前記車両のユーザに提供するサービスを出力することを特徴とするサービス提供装置。

【請求項5】

請求項４に記載のサービス提供装置において、
前記情報生成部により生成された乗車情報と、前記情報取得部により取得された前記ユーザ情報と、を記憶する記憶部と、
前記車両の車内で、前記サービス決定部により決定されたサービスを前記車両のユーザに提案するサービス提案部と、をさらに備え、
前記ユーザ情報は、前記サービス提案部により提案されたサービスが前記車両のユーザに受け入れられたか否かに関する受入情報を含み、
前記ニューラルネットワークは、前記記憶部に記憶された前記乗車情報および前記ユーザ情報に基づいて追加的に学習されることを特徴とするサービス提供装置。

【請求項6】

請求項１～４のいずれか１項に記載のサービス提供装置において、
前記車両の車内で、前記サービス決定部により決定されたサービスを前記車両のユーザに提案するサービス提案部をさらに備え、
前記サービス提案部は、前記情報生成部により生成された乗車情報に含まれる乗車人数が１人のときは音声のみにより前記サービス決定部により決定されたサービスを提案することを特徴とするサービス提供装置。

【請求項7】

請求項１～６のいずれか１項に記載のサービス提供装置において、
前記車両の車内に設けられたコントローラと、
前記車両の車外に設けられたサーバと、をさらに備え、
前記コントローラは、前記情報生成部を有し、
前記サーバは、前記サービス決定部を有することを特徴とするサービス提供装置。

【請求項8】

請求項７に記載のサービス提供装置において、
前記コントローラは、前記複数のシートのいずれかと一体的に設けられることを特徴とするサービス提供装置。

【請求項9】

車両に搭載された複数のシートにそれぞれ設けられ、着座状態または非着座状態を検出する複数の着座センサと、
前記複数の着座センサによる検出結果に基づいて、前記車両の乗車人数を含む乗車情報を生成する情報生成部と、
前記情報生成部により生成された乗車情報に基づいて、前記車両のユーザに提供するサービスを決定するサービス決定部と、を備え、
前記サービス決定部は、前記情報生成部により生成された乗車情報に基づいて、前記車両のユーザに提案するアプリケーションプログラムおよび提案時期を決定し、前記車両のユーザが前記車両に乗車してから所定時間後の前記提案時期に、前記車両を駐車可能な場所を検索する前記アプリケーションプログラムを提案することを決定することを特徴とするサービス提供装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、車両用シートの着座情報に基づいてサービスを提供するサービス提供装置に関する。

【背景技術】

【0002】

この種の装置として、従来、車両用シートに設けられた着座センサの検出結果に基づいて乗員のシートベルトの未着用警報を発するようにした装置が知られている（例えば、特許文献１参照）。特許文献１記載の装置では、着座センサとシートベルト着用センサとの検出結果に基づいて、乗員が着座しているシートに対応するシートベルトが着用されていないと判定されると、シートベルトの未着用警報を発する。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２００８－２３０４４６号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

上記特許文献１記載の装置では、着座センサの情報が単にシートベルトの未着用警報にのみ用いるが、他のサービスにも用いるようにすることがセンサ情報を有効利用する上では好ましい。

【課題を解決するための手段】

【0005】

本発明の一態様であるサービス提供装置は、車両に搭載された複数のシートにそれぞれ設けられ、着座状態または非着座状態を検出する複数の着座センサと、複数の着座センサによる検出結果に基づいて、車両の乗車人数を含む乗車情報を生成する情報生成部と、情報生成部により生成された乗車情報に基づいて、車両のユーザに提供するサービスを決定するサービス決定部とを備える。サービス決定部は、情報生成部により生成された乗車情報に基づいて、車両のユーザに提案するアプリケーションプログラムおよび提案時期を決定し、情報生成部により生成されて記憶部に蓄積された乗車情報に基づいて、車両のユーザが車両から降車してから所定時間後の提案時期に、車両のユーザにアプリケーションプログラムを提案することを決定する。
本発明の他の態様であるサービス提供装置は、車両に搭載された複数のシートにそれぞれ設けられ、着座状態または非着座状態を検出する複数の着座センサと、複数の着座センサによる検出結果に基づいて、車両の乗車人数を含む乗車情報を生成する情報生成部と、情報生成部により生成された乗車情報に基づいて、車両のユーザに提供するサービスを決定するサービス決定部と、を備える。サービス決定部は、情報生成部により生成された乗車情報に基づいて、車両のユーザに提案するアプリケーションプログラムおよび提案時期を決定し、車両のユーザが車両に乗車してから所定時間後の提案時期に、車両を駐車可能な場所を検索するアプリケーションプログラムを提案することを決定する。

【発明の効果】

【0006】

本発明によれば、着座センサの情報を種々のサービスに有効利用することができる。

【図面の簡単な説明】

【0007】

【図1】車両に搭載されるシートベルトリマインダの構成を概略的に示す図。

【図2】着座センサにより検出される着座情報について説明するための図。

【図3】本発明の第１実施形態に係るサービス提供装置の全体構成を概略的に示す図。

【図4A】図３の車両の各座席に搭載されるシートの一例を示す斜視図。

【図4B】図４Ａの変形例を示す図。

【図5A】図３の車両の車内における座席配置の一例を示す平面図。

【図5B】図５Ａの変形例を示す図。

【図5C】図５Ｂの変形例を示す図。

【図6A】本発明の第１実施形態に係るサービス提供装置の全体構成を示すブロック図。

【図6B】図４Ａの変形例を示す図。

【図7】本発明の第１実施形態に係るコンシェルジュアプリを起動中の携帯端末の画面表示の一例を示す図。

【図8】図６Ａのサービス決定部により決定されるサービスについて説明するための図。

【図9】複数名乗車の場合に、図６Ａのサービス決定部により決定されるサービスについて説明するための図。

【図10A】ユーザが非運転者であることを確認するときの、図７と同様の図。

【図10B】ユーザが非運転者であることを確認した後の、図７と同様の図。

【図10C】非運転者のユーザにサービスを提案するときの、図７と同様の図。

【図11】本発明の第２実施形態に係るサービス提供装置の全体構成を示すブロック図。

【図12】図１１の情報要求部によるユーザ情報の入力の要求について説明するための図。

【図13】図１１のサービス決定部により決定されるサービスについて説明するための図。

【図14A】図１１のサービス決定部について説明するための図。

【図14B】図１４Ａの変形例を示す図。

【図15】本発明の第３実施形態に係るユーザ情報について説明するための図。

【図16】本発明の第４実施形態に係るコンシェルジュアプリを非起動中の携帯端末の画面表示の一例を示す図。

【図17】本発明の第５実施形態に係る車両の運転席に搭載されるシートの一例を示す斜視図。

【図18】本発明の第６実施形態に係るサービス提供装置の全体構成を示すブロック図。

【図19A】図１８のタッチセンサの配置の一例を示す図。

【図19B】図１８のタッチセンサの配置の別の例を示す図。

【図20】本発明の第７実施形態に係るサービス提供装置の全体構成を示すブロック図。

【図21】図２０の出力部の一例を示す図。

【発明を実施するための形態】

【0008】

－第１実施形態－
以下、図１～図１０Ｃを参照して、本発明の第１実施形態について説明する。第１実施形態に係るサービス提供装置は、複数の座席を有する乗用車（以下、車両）の運転者を含む乗員（以下、ユーザ）に対し、ユーザの携帯端末上で動作するアプリケーションプログラム（以下、アプリ）を提案するサービスを提供する。

【0009】

図１は、車両に搭載されるシートベルトリマインダ２００の構成を概略的に示す図である。図１に示すように、車両には、一般に、運転者を含む乗員がシートベルトを装着していないことを運転者に報知する警報装置（シートベルトリマインダ）２００が搭載される。シートベルトリマインダ２００は、車両用コントローラ２０１により主に構成され、各座席のシートに設けられた着座センサ２０２およびシートベルトセンサ２０３からの信号に基づいてインストルメントパネルに設けられた警告灯２０４などを介して警報を行う。

【0010】

今後のシートベルトリマインダの保安基準では後部座席を含むすべての座席がシートベルトリマインダによる警報の対象となるため、今後、すべての車両のすべての座席のシートに着座センサを搭載することが推奨される。

【0011】

図２は、着座センサにより検出される着座情報について説明するための図であり、２シータ車両における着座情報の時間変化の一例を示す。図２の例では、車両の始動から停止までの２回のドライビングサイクルｔ１～ｔ２，ｔ３～ｔ４が示される。図２に示すように、着座センサは、ドライビングサイクル中は所定の周期で各座席の着座状態または非着座状態を検出して検出結果を示す信号を出力する（時刻ｔ１～ｔ２、時刻ｔ３～ｔ４）。一方、ドライビングサイクル以外は検出を行わず、信号を出力しない（時刻ｔ１以前、時刻ｔ２～ｔ３、時刻ｔ４以降）。

【0012】

図２に示すように、車両に搭載された複数の着座センサからの信号は、乗車人数の時間変化を含むその車両の乗車状態を示している。すなわち、図２の例では、時刻ｔ１以前、時刻ｔ２～ｔ３および時刻ｔ４以降が非乗車状態、時刻ｔ１～ｔ２および時刻ｔ３～ｔ４が単独乗車状態を示している。このような車両全体の乗車状態に関する時系列の情報を、以下では「乗車情報」と称する。

【0013】

このような乗車情報は、車両の利用状況を示す車両情報としてだけでなく、その車両を利用するユーザのライフスタイルを示すユーザ情報としても活用することができる。特に、ユーザごとに長期にわたって蓄積された乗車情報は、ユーザが車両を利用する時間帯や曜日、自宅などの拠点から出発するときの人数などの、車両の利用パターンを示す有用なユーザ情報として扱うことができる。

【0014】

そこで、第１実施形態では、このような乗車情報を車両のユーザに対応付け、ユーザの携帯端末上で動作する様々なアプリの中から適当なものを選択してユーザに提案することで乗車情報を有効利用するよう、以下のようにサービス提供装置を構成する。

【0015】

図３は、第１実施形態に係るサービス提供装置１００の全体構成を概略的に示す図である。図３に示すように、サービス提供装置１００は、車両１に搭載された複数のシート２，３にそれぞれ設けられた着座センサ４，５と、車内に設けられたコントローラ１０と、車両１を利用するユーザの携帯端末２０と、サーバ３０とを有する。

【0016】

図４Ａおよび図４Ｂは、車両１の各座席に搭載されるシートの一例を示す斜視図であり、右ハンドルの車両１の運転席に搭載されるシート２の一例を示す。図４Ａおよび図４Ｂでは、シート２に着席した乗員（運転者）を基準にして、図示のように、前側および後側、車外側および車内側、上側および下側を定義する。シート２は、内部にシートフレームを有し、シートフレームを覆うようにウレタン樹脂製のパッドとパッドの表面の表皮とを有する。

【0017】

図４Ａに示すように、乗員が着座するシート２の着座面の表皮の下側には、圧力センサなどにより構成されて乗員の着座状態または非着座状態を検出する着座センサ４と、電子制御装置（ＥＣＵ）により構成されるコントローラ１０とが設けられる。図４Ｂに示すように、シート２の背もたれ部にも着座センサ４を設けてもよい。この場合、乗員の着座状態または非着座状態の検出精度を向上することができる。

【0018】

なお、着座センサ４として圧力に応じて連続的に抵抗値が変化するセンサを用いる場合は、着座状態、非着座状態の検出に加え、乗員の体重を推定することができる。この場合、例えば、複数の乗員のそれぞれを体重の推定値に基づいて特定し、各乗員に応じたサービスを提供することもできる。例えば、ユーザ情報に基づいて体重５０ｋｇの乗員Ａと体重４５ｋｇの乗員Ｂが乗車した場合、圧力センサにより推定される体重が５０ｋｇの乗員は乗員Ａであり、圧力センサにより推定される体重が４５ｋｇの乗員は乗員Ｂであると判定することができる。これにより、乗車人数や乗車位置に加えて各座席に着座している乗員個人を特定することができ、各乗員に応じたサービスを提供することができる。

【0019】

着座センサ４は、有線または無線によりコントローラ１０に接続され、乗員の着座状態または非着座状態の検出結果を示す信号（着座情報）を所定時間（例えば、５分間）ごとに送信する。なお、着座センサ４からの信号に代えてシートベルトセンサからの信号を着座情報として用いてもよい。

【0020】

図５Ａ～図５Ｃは、車両１の車内における座席配置の一例を示す平面図であり、運転席を含む複数の座席の配置例を示す。図５Ａ～図５Ｃでは、図示のように車両１の前後方向および左右方向を定義する。前後方向は車両１の長さ方向に相当し、左右方向は車幅方向に相当する。図５Ａ～図５Ｃに示すように、車両１には運転席のシート２と非運転席のシート３とを含む複数（図５Ａ～図５Ｃでは５つ）のシート２，３が搭載される。図５Ａ～図５Ｃの例では、前部座席として運転席のシート２の他に助手席のシート３ａが設けられるとともに、後部座席として左右のシート３ｂ，３ｃと、シート３ｂ，３ｃの間に配置されるシート３ｄとが設けられる。

【0021】

図５Ａ～図５Ｃに示すように、非運転席のシート３ａ～３ｄには、運転席のシート２（図４Ａ、図４Ｂ）と同様に、圧力センサなどにより構成されて乗員の着座状態または非着座状態を検出する着座センサ５ａ～５ｄがそれぞれ設けられる。着座センサ５ａ～５ｄは、それぞれ有線または無線により運転席のシート２に設けられたコントローラ１０に接続され、乗員の着座状態または非着座状態の検出結果を示す信号（着座情報）を所定時間（例えば、５分間）ごとに送信する。なお、着座センサ５（５ａ～５ｄ）からの信号に代えてシートベルトセンサからの信号を着座情報として用いてもよい。

【0022】

図５Ａの例では、着座センサ４，５（５ａ～５ｄ）は、無線によりコントローラ１０に接続される。一方、図５Ｂの例では、着座センサ４，（５ａ～５ｄ）は、物理信号線１０１を介して、ＳＲＳ（Supplemental Restraint System）の動作を制御するとともにシートベルトリマインダとして機能する車両用コントローラ１０２に接続される。車両用コントローラ１０２は、さらにＣＡＮ（Controller Area Network）通信線１０３を介してコントローラ１０に接続される。ＣＡＮ通信線に代えてＬＩＮ（Local Interconnect Network）通信線などを用いてもよい。また、図５Ｃに示すように、ＣＡＮ通信線１０３を介してコントローラ１０に接続されるカーナビゲーションユニット１０４と、コントローラ１０とを、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＷｉ－Ｆｉ（登録商標）などの近距離無線通信により接続してもよい。

【0023】

図６Ａは、第１実施形態に係るサービス提供装置１００の全体構成を示すブロック図である。図６Ａに示すように、サービス提供装置１００は、着座センサ４，５（５ａ～５ｄ）と、コントローラ１０と、車両１を利用するユーザの携帯端末２０と、サーバ３０とを有する。コントローラ１０と携帯端末２０とは、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＷｉ－Ｆｉ（登録商標）などの近距離無線通信により互いに接続可能に構成される。コントローラ１０と携帯端末２０とは、ＵＳＢケーブルなどにより有線接続されてもよい。携帯端末２０とサーバ３０とは、インターネット網や携帯電話網等に代表される公衆無線通信網を含むネットワーク６に接続され、ネットワーク６を介して互いに通信可能に構成される。

【0024】

コントローラ１０と携帯端末２０とを有線接続する場合は、図６Ｂに例示するように、シート２にＵＳＢポート１０５を設けてもよい。図６Ｂは、ＵＳＢポート１０５の配置の一例を示す図である。図６Ｂに示すように、ＵＳＢポート１０５は、例えばシート２の車内側の台座部分に設けられる。ＵＳＢポート１０５と市販のＵＳＢケーブルを介してコントローラ１０と携帯端末２０とを接続することにより、コントローラ１０と携帯端末２０との間におけるデータの送受信やコントローラ１０から携帯端末２０への給電（携帯端末２０の充電）が可能になる。

【0025】

図３および図６Ａには、便宜上、コントローラ１０と携帯端末２０とがそれぞれ１つずつ示されるが、複数の車両１のそれぞれの車内に設けられたコントローラ１０と複数のユーザのそれぞれの携帯端末２０とを含んでサービス提供装置１００が構成されてもよい。また、図３および図６Ａでは、単一のサーバ３０が示されるが、図６Ａのサーバ３０に示す機能を、複数のサーバに分散させてもよい。

【0026】

図６Ａに示すように、コントローラ１０は、通信部１１と、動作回路としてのＣＰＵなどの演算部１２と、ＲＯＭ，ＲＡＭなどの記憶部１３と、その他の周辺回路（インターフェース回路等）とを含んで構成される。

【0027】

通信部１１は、車両１の車内での近距離無線接続または有線接続により携帯端末２０との通信接続が確立されると、携帯端末２０との間でデータ通信可能に構成される。例えば、ユーザが自身の携帯端末２０を操作して接続設定を行う、あるいは携帯端末２０とコントローラ１０とをケーブルにより接続すると、携帯端末２０とコントローラ１０との間の通信接続が確立される。

【0028】

演算部１２は、機能的構成として、情報取得部１４と、情報生成部１５と、情報出力部１６とを有する。記憶部１３には、演算部１２で実行される制御プログラムなどが記憶されるとともに、車両１の車種や最大乗車定員の情報を含む車両情報が記憶される。

【0029】

情報取得部１４は、着座センサ４，５から入力される信号を読み込むことで、車両１の各座席の着座情報を取得する。情報生成部１５は、情報取得部１４により取得された各座席の着座情報に基づいて、車両１の乗車人数を含む乗車情報を生成する。情報出力部１６は、情報生成部１５により生成された乗車情報を、記憶部１３に記憶された車両情報とともに、通信部１１を介して所定時間（例えば、５分間）ごとに携帯端末２０に送信する。

【0030】

なお、情報生成部１５は、所定時間（例えば、５分間）以内の非着座状態を無視して乗車情報を生成してもよい。すなわち、情報取得部１４により着座状態が取得されていた座席について非着座状態が取得された場合、所定時間以内に再び着座状態が取得されたときは、着座状態が継続していたものとして乗車情報を生成する。一方、情報取得部１４により着座状態が取得されていた座席について非着座状態が取得された後、所定時間以内に着座状態が取得されないときは、非着座状態が取得された時刻に非着座状態に変化したものとして乗車情報を生成する。これにより、自動販売機での買物や電話、トイレなどの目的で乗員が一時的に降車した場合でも乗車を継続しているものとして乗車情報を生成することができ、乗車情報を安定して生成することができる。

【0031】

携帯端末２０は、車両１のユーザにより携帯して使用されるスマートフォンやタブレット端末、携帯電話、ウェアラブル端末など、出力部としてのディスプレイやスピーカを有する各種携帯端末により構成される。携帯端末２０は、通信部２１と、入力部２２と、出力部２３と、動作回路としてのＣＰＵなどの演算部２４と、ＲＯＭ，ＲＡＭなどの記憶部２５と、その他の周辺回路（インターフェース回路等）とを含んで構成される。

【0032】

通信部２１は、車両１の車内での近距離無線接続または有線接続によりコントローラ１０との通信接続が確立されると、コントローラ１０との間でデータ通信可能に構成される。また、ネットワーク６を介してサーバ３０を含む各種の外部機器と無線通信可能に構成される。

【0033】

入力部２２は、ユーザの入力操作を受け付けるタッチパネルやテンキーなど、あるいはユーザの音声入力を受け付けるマイクにより構成される。出力部２３は、画面表示を行うディスプレイや音声出力を行うスピーカにより構成される。

【0034】

演算部２４は、通信部２１を介して携帯端末２０の外部から受信した信号、入力部２２を介して入力された信号、および記憶部２５に記憶された各種のデータに基づいて所定の処理を実行し、出力部２３および記憶部２５に制御信号を出力する。

【0035】

記憶部２５には、演算部２４が実行するアプリのデータや他のデータが記憶される。例えば、通信部２１を介してコントローラ１０から受信した車両１の車両情報および乗車情報のデータが一時的に記憶される。記憶された車両１の車両情報および乗車情報は、後述するユーザＩＤとともに、演算部２４での処理により、通信部２１を介して所定時間（例えば、５分間）ごとにサーバ３０に送信される。

【0036】

ユーザは、ネットワーク６を介して各種の事業者のサーバなどを含む外部機器にアクセスし、事業者により提供される様々なアプリの中から好みのものを選択して、自身の携帯端末２０にインストールすることができる。例えば、飲食店を検索するグルメアプリやユーザ同士の出会いを仲介するマッチングアプリなどをインストールすることができる。携帯端末２０にインストールされたアプリのデータは、記憶部２５に記憶される。

【0037】

第１実施形態では、携帯端末２０上で動作する様々なアプリの中から適当なものを選択して起動やインストールを提案するコンシェルジュサービスを提供するコンシェルジュアプリが、携帯端末２０にインストールされる。携帯端末２０にコンシェルジュアプリがインストールされると、携帯端末２０のユーザに対してコンシェルジュサービスのユーザＩＤが発行され、ユーザがコンシェルジュサービスに会員登録される。これにより、以後、ユーザに対し、携帯端末２０にインストールされたコンシェルジュアプリを介してコンシェルジュサービスが提供される。コンシェルジュサービスのユーザＩＤは、コンシェルジュアプリのデータとともに携帯端末２０の記憶部２５に記憶される。

【0038】

コンシェルジュアプリのデータは、携帯端末２０の記憶部２５だけでなくサーバ３０の記憶部３３にも記憶され、コンシェルジュアプリの機能は、アプリケーションプログラミングインタフェース（ＡＰＩ）により、携帯端末２０側とサーバ３０側とで提供される。例えば、画面表示や音声出力、入力の受け付けなどの機能が携帯端末２０側で提供され、画面表示や音声出力される情報の決定、入力された情報の処理などの機能がサーバ３０側で提供される。

【0039】

図７は、コンシェルジュアプリを起動中の携帯端末２０の画面表示の一例を示す図であり、コンシェルジュサービスのコンシェルジュキャラクタ（以下、コンシェルジュ）２６の表示態様の一例を示す。コンシェルジュ２６は、コンシェルジュアプリの起動中に携帯端末２０のディスプレイ（出力部）２３に表示され、ユーザ情報に基づいて選択したアプリを画面表示または音声出力により提案する。コンシェルジュ２６によるアプリの提案には、新たなアプリのインストールの提案、インストール済みのアプリの起動および起動の提案が含まれる。

【0040】

図７に示すようなコンシェルジュ２６の表示態様（例えば、性別、服装）や提案時の言葉遣い（例えば、言語、方言）などは、予め定められたパターンの中からユーザ設定によって選択され、サーバ３０側で制御される。これにより、ユーザがコンシェルジュ２６に対して親しみを感じやすくすることができる。

【0041】

サーバ３０は、通信部３１と、動作回路としてのＣＰＵなどの演算部３２と、ＲＯＭ，ＲＡＭなどの記憶部３３と、その他の周辺回路（インターフェース回路等）とを含んで構成される。通信部３１は、ネットワーク６を介して携帯端末２０と無線通信可能に構成される。演算部３２は、機能的構成として、情報取得部３４と、サービス決定部３５とを有する。記憶部３３には、コンシェルジュアプリのデータが記憶されるとともに、ユーザごとのユーザ情報がユーザＩＤに対応付けて記憶される。

【0042】

情報取得部３４は、携帯端末２０からユーザＩＤとともに送信される車両１の車両情報および時系列の乗車情報を、ユーザＩＤに対応するユーザ情報として取得する。情報取得部３４により取得されたユーザ情報は、ユーザＩＤに対応付けて記憶部３３に記憶される。すなわち、図３に示すように、ユーザが車両１に乗車中は車内でコントローラ１０と携帯端末２０との通信接続が確立され、コントローラ１０から送信される車両１の車両情報および乗車情報が、携帯端末２０を介して、ユーザＩＤとともにサーバ３０に送信される。これにより、車両１の乗車情報を、車両１を利用するユーザのユーザ情報として活用することができる。

【0043】

サービス決定部３５は、情報取得部３４により取得された時系列の乗車情報を含むユーザ情報に基づいて、車両１のユーザに提供するサービスを決定する。具体的には、ユーザに起動やインストールを提案するアプリを選択するとともに、提案するタイミングを決定する。

【0044】

図８、図９は、サービス決定部３５により決定されるサービスについて説明するための図である。図８の例では、時刻ｔ１１において、ユーザが運転者として単独で２シータの車両１に乗車する。このような乗車情報が取得されると、サービス決定部３５は、乗車時刻ｔ１１から所定時間（例えば、１時間）後の時刻ｔ１２に、音声出力により飲食店を検索するグルメアプリの起動を提案することを決定する。この場合、時刻ｔ１２において、携帯端末２０のスピーカ（出力部）２３を介して、例えば「そろそろカフェで休憩されてはどうでしょう？」などの音声出力がコンシェルジュ２６からユーザへの提案として行われる。

【0045】

コンシェルジュ２６から音声出力による提案が行われると、音声出力後の所定時間（例えば、１０秒間）、ユーザは携帯端末２０のマイク（入力部）２２を介して提案を受け入れる、あるいは断る旨を音声入力することができる。「はい」、「お願い」、「よろしく」などの肯定的なフレーズが音声入力されると提案が受け入れられたものと認識され、「いいえ」、「結構です」、「また今度」などの否定的なフレーズが音声入力されると提案が断られたものと認識される。所定時間内に音声入力が認識されない場合は、再度の提案が行われる、あるいは、提案が断られたものと認識される。

【0046】

コンシェルジュ２６による提案が受け入れられると、サービス決定部３５により決定されたグルメアプリが起動され、乗車人数や位置情報などのユーザ情報に応じて、付近にある駐車場付きの飲食店が検索される。検索結果は、音声出力によりユーザに通知される。さらに、ユーザからの音声入力に応じて飲食店の予約が行われてもよい。なお、コンシェルジュ２６からの提案が断られると、例えば「それでは、また改めまして」などの音声出力がなされる。

【0047】

図９の例では、時刻ｔ２１において、ユーザが複数名（図では、４名）で５シータの車両１に乗車する。この場合、ユーザは非運転者（同乗者）であることも、運転者であることも考えられる。このような乗車情報が取得されると、サービス決定部３５は、乗車時刻ｔ２１から所定時間（例えば、２時間）後の時刻ｔ２２に、単独乗車の場合と同様に、音声出力により飲食店を検索するグルメアプリの起動を提案することを決定する。この場合、時刻ｔ２２において、例えば「そろそろ皆様で休憩されてはどうでしょう？」などの音声出力が行われる。

【0048】

さらに、サービス決定部３５は、乗車時刻ｔ２１から所定時間（例えば、３時間）後の時刻ｔ２３に、音声出力により観光スポットを検索する旅行アプリの起動を提案することを決定する。この場合、時刻ｔ２３において、例えば「近くの観光スポットをご案内しましょうか？」などの音声出力がコンシェルジュ２６からユーザへの提案として行われる。

【0049】

コンシェルジュ２６からの提案は、ユーザ自身が車両１の運転者である可能性がある場合には音声出力により行われるため、ユーザは携帯端末２０のディスプレイ（出力部）２３を見る必要がなく、ユーザによる車両１の安全運転を妨げることがない。また、通知音による抽象的な報知ではなく、具体的な提案内容が音声情報として提供されるため、ユーザの運転に対する集中力を低下させることがない。また、運転中の適当なタイミングで休憩が提案されるため、ユーザによる車両１の安全運転を促進することができる。

【0050】

ユーザが車両１に乗車中にコンシェルジュ２６が提案するアプリは、駐車場を検索する駐車場アプリであってもよい。例えば、グルメアプリや旅行アプリと併せて駐車場アプリを起動し、駐車場を併設していない飲食店や観光スポットとともに最寄りの駐車場を検索、予約するようにしてもよい。この場合、特に単独乗車のユーザによる車両１の安全運転を支援することができる。

【0051】

ユーザが車両１に乗車中にコンシェルジュ２６が提案するアプリは、オンラインゲーム用のゲームアプリであってもよい。特定のエリア（携帯端末２０の位置情報が所定の緯度経度の範囲内）で特別なアイテムが入手できるようなゲームアプリを利用するユーザによっては、ゲームのことが気になって安全運転を怠るおそれがある。例えば、特定のエリアでユーザが車両１に乗車中に、コンシェルジュ２６が代わりにゲームアプリを起動することを提案するようにしてもよい。この場合、ゲーム好きのユーザが単独乗車している場合であっても、安心して安全運転を継続することができる。

【0052】

図１０Ａ～図１０Ｃは、コンシェルジュアプリを起動中の携帯端末２０の画面表示の一例を示す図であり、ユーザが車両１に乗車し、車内でコントローラ１０と携帯端末２０との通信接続が確立された直後の画面表示の一例を示す。ユーザが複数名で車両１に乗車し、図９の例に示すような乗車情報が取得されると、図１０Ａに示すように、携帯端末２０のディスプレイ（出力部）２３にコンシェルジュ２６が表示され、画面表示によりユーザが非運転者であるか否かを確認する。このときの画面表示には、非運転者であるか否かの回答を入力するための確認ボタン２７ａも含まれる。図１０Ａの確認画面は、コントローラ１０と携帯端末２０との通信接続の確立後の所定時間（例えば、１０秒間）のみ表示される。

【0053】

図１０Ａの確認画面が表示され、ユーザが携帯端末２０のタッチパネル（入力部）２２を介して非運転者であることを確認する「はい」の確認ボタン２７ａをタッチすると、ユーザが非運転者であると認識される（図１０Ｂ）。一方、図１０Ａの確認画面が表示され、ユーザが非運転者ではないことを示す「いいえ」の確認ボタン２７ａをタッチする、あるいは確認画面の表示中に確認ボタン２７ａをタッチしない場合は、ユーザが運転者であると認識される。

【0054】

ユーザが非運転者であることが確認されると、以後のドライビングサイクル中のコンシェルジュサービスが画面表示により提供される。すなわち、図９の時刻ｔ２２，ｔ２３において音声出力に代えて、図１０Ｃのような画面表示がコンシェルジュ２６からユーザへの提案として行われる。このように、ユーザ自身が車両１の運転者ではなく同乗者（非運転者）であることが確認されると画面出力により提案が行われるため、ユーザは、例えば旅行アプリの起動後に検索される観光スポットなどの詳細情報を画面表示により確認することができる。

【0055】

本発明の第１実施形態によれば以下のような作用効果を奏することができる。
（１）サービス提供装置１００は、車両１に搭載された複数のシート２，３（３ａ～３ｄ）にそれぞれ設けられ、着座状態または非着座状態を検出する複数の着座センサ４，５（５ａ～５ｄ）と、複数の着座センサ４，５による検出結果に基づいて、車両１の乗車人数を含む乗車情報を生成する情報生成部１５と、情報生成部１５により生成された乗車情報に基づいて、車両１のユーザに提供するサービスを決定するサービス決定部３５とを備える（図３、図５Ａ～図５Ｃ、図６Ａ）。これにより、着座センサ４，５の情報を種々のサービスに有効利用することができる。

【0056】

（２）サービス提供装置１００は、車両１の車内で、車両１のユーザが携帯する携帯端末２０と通信する通信部１１をさらに備える（図６Ａ）。サービス決定部３５は、通信部１１を介して入力された携帯端末２０からの情報と情報生成部１５により生成された乗車情報とに基づいて、車両１のユーザに提供するサービスを決定する。これにより、車両１の乗車情報を、車両１を利用するユーザのユーザ情報として活用することができる。

【0057】

（３）サービス提供装置１００は、車両１の車内で、サービス決定部３５により決定されたサービスを車両１のユーザに提案する出力部２３をさらに備える（図６Ａ）。出力部２３は、情報生成部１５により生成された乗車情報に含まれる乗車人数が１人のときは音声のみによりサービス決定部３５により決定されたサービスを提案する。すなわち、ユーザが車両１の運転者である場合には音声出力によりサービスが提案されるため、ユーザによる車両１の安全運転を妨げることがない。

【0058】

（４）サービス提供装置１００は、車両１の車内に設けられたコントローラ１０と、車両１の車外に設けられたサーバ３０とをさらに備える（図６Ａ）。コントローラ１０は、情報生成部１５を有する（図６Ａ）。サーバ３０は、サービス決定部３５を有する（図６Ａ）。これにより、コントローラ１０側で生成された時系列の乗車情報を含むユーザ情報がサーバ３０側でユーザＩＤに対応付けて蓄積されるため、コントローラ１０の構成を簡易にすることができる。

【0059】

（５）コントローラ１０は、複数のシート２，３のいずれかと一体的に設けられる（図３～図５Ｃ）。これにより、シート２，３に設けられたコントローラ１０と、シート２，３を利用するユーザの携帯端末２０との間の通信接続が確立されると、ユーザが車両１に乗車したことを認識することができる。

【0060】

（６）サービス決定部３５は、情報生成部１５により生成された乗車情報に基づいて、車両１のユーザに提案するアプリおよびタイミングを決定する。これにより、ユーザによる車両１の乗車時間に応じた適当なアプリを選択し、適当なタイミングで提案するサービスを提供することができる。

【0061】

（７）サービス決定部３５は、情報生成部１５により生成された乗車情報に基づいて、車両１のユーザが車両１に乗車してから所定時間後に、車両１を駐車可能な場所を検索するアプリを提案することを決定する。これにより、ユーザによる車両１の乗車時間に応じた適当なタイミングで休憩を提案することができ、車両１の安全運転を促進することができる。

【0062】

－第２実施形態－
図１１～図１３を参照して本発明の第２実施形態について説明する。第２実施形態では、乗車情報に加えてさらに、ユーザの属性や嗜好などの情報がユーザ情報として用いられる。以下では、第１実施形態との相違点を主に説明する。

【0063】

図１１は、第２実施形態に係るサービス提供装置１００Ａの全体構成を示すブロック図である。図１１に示すように、サーバ３０Ａの演算部３２Ａは、機能的構成として、さらに情報要求部３６を有する。情報要求部３６は、コンシェルジュ２６（携帯端末２０の出力部２３）を介してユーザにユーザ情報の入力を要求する。

【0064】

図１２は、情報要求部３６によるユーザ情報の入力の要求について説明するための図であり、コンシェルジュアプリの起動中にユーザ情報の入力を要求するコンシェルジュ２６の一例を示す。図１２に示すように、情報要求部３６は、日常会話としてコンシェルジュ２６からユーザに年齢や性別、居住エリア、趣味などを尋ねる形式により、様々なユーザ情報の入力を要求する。コンシェルジュ２６からユーザ情報の入力が要求されると、その後の所定時間（例えば、１分間）、ユーザは携帯端末２０の入力部２２を介してユーザ情報を入力することができる。

【0065】

図１２の例では、コンシェルジュ２６からユーザに対し、飲食店のジャンルについてのユーザ情報の入力が要求される。このときの画面表示には、ユーザ情報を入力するための入力欄２７ｃも含まれる。この場合、ユーザは、携帯端末２０のタッチパネル（入力部）２２を操作して入力欄２７ｃから飲食店のジャンルを選択することで、コンシェルジュ２６との日常会話としてユーザ情報を入力することができる。

【0066】

コンシェルジュ２６（携帯端末２０の入力部２２）を介して入力されたユーザ情報は、携帯端末２０の通信部２１を介してユーザＩＤとともにサーバ３０に送信され、サーバ３０の情報取得部３４により取得され、ユーザＩＤに対応付けて記憶部３３に記憶される。

【0067】

図１３は、サービス決定部３５により決定されるサービスについて説明するための図である。サービス決定部３５は、ユーザ情報に基づいて、車両１のユーザのライフスタイル全般を支援するようなアプリを提案する。このような提案は、乗車情報に加えてユーザの年齢などを含むユーザ情報に基づいて、予め定められた提案モデルに当てはめることで行われる。例えば、２０代男性が所定期間（例えば、４週間）、休日の度に単独で車両１を利用している場合は婚活用のマッチングアプリを提案するなどの提案モデルが予め定められる。

【0068】

図１３の例では、２０代男性のユーザについて、図８のようなドライビングサイクルごとの乗車情報が蓄積され、４週間、休日の度に単独で車両１に乗車している乗車情報が蓄積されている。このような乗車情報が蓄積された状態で最新のドライビングサイクルｔ３１～ｔ３２の乗車情報が取得されると、サービス決定部３５は、降車時刻ｔ３２から所定時間（例えば、２時間）後の時刻ｔ３３に婚活用のマッチングアプリの起動を提案することを決定する。

【0069】

この場合、時刻ｔ３３において、コンシェルジュ２６（携帯端末２０の出力部２３）を介して、例えば「一緒にドライブに行く方を探してみませんか？」などの提案が行われる。コンシェルジュ２６による提案が受け入れられると、サービス決定部３５により決定された婚活用のマッチングアプリが起動される。

【0070】

コンシェルジュ２６を介して提案するアプリがユーザ自身による複雑な入力操作などを必要とする場合、サービス決定部３５は、ユーザが車両１に乗車していない非乗車時、例えば、降車時刻ｔ３２から所定時間後の時刻ｔ３３にアプリを提案することを決定する。したがって、ユーザが車両１に乗車しているときに携帯端末２０に対する入力操作を要求することがなく、ユーザによる車両１の安全運転を妨げることがない。

【0071】

さらに、サービス決定部３５は、ユーザがマッチングアプリに登録する情報に、ユーザによる車両１の乗車情報に基づくコンシェルジュ２６からの保証コメントを付けることを提案してもよい。例えば、ユーザによる車両１の利用頻度が高い場合は、ユーザがドライブ好きであることを保証するコメントを付ける。車両１の車種についてのコメントを付けてもよい。これにより、趣味の合うユーザとマッチングされる可能性が高まるとともに、コンシェルジュアプリによる保証を付すことでユーザ自身の信用度を向上することができる。

【0072】

例えば、婚活用のマッチングアプリの場合には、単独乗車での車両１の利用頻度が高い旨のコメントを付すことで、ユーザが単身であることを保証することができる。また、宅配バイト用のマッチングアプリの場合には、ユーザが利用する車両１の車種や利用頻度の情報を付すことで、ユーザ自身の運転経験についての信用度を向上することができる。

【0073】

図１４Ａおよび図１４Ｂは、サービス決定部３５について説明するための図であり、図１４Ａは、予め定められた提案モデルとしてのニューラルネットワーク３５０の階層を示す。また、図１４Ｂは、予め定められた提案モデルとしてＸｇｂｏｏｓｔ（eXtreme Gradient Boosting）を用いる場合の図１４Ａの変形例である。

【0074】

図１４Ａに示すように、サービス決定部３５は、入力層３６１と、複数の中間層３６２と、出力層３６３とを有するニューラルネットワーク３６０を介して提案内容を決定するように構成される。入力層３６１は、情報生成部１５により生成された乗車情報と、情報取得部３４により取得されたユーザ情報とを取得し、出力層３６３は、車両１のユーザに提供するサービスを出力する。

【0075】

入力層３６１により取得される情報には、例えば、現在または直近のドライビングサイクルにおける情報として、乗車時間、乗車人数、車種、乗車時刻（時間帯）、乗車中の位置（地域）、季節、曜日、気温、湿度、天候などが含まれる。また、現在の情報として、乗車中であるか非乗車中であるか、現在の位置（地域）、季節、曜日、気温、湿度、天候、および性別、年齢、職業などのユーザ情報などが含まれる。これらの情報は、定量化された値（入力値）として入力層３６１により取得される。出力層３６３により出力される情報には、決定されたサービス（アプリ）の情報と提案時刻の情報とが含まれる。これらの情報は、定性化される前の数値（出力値）として出力層３６３により出力される。提案モデルとしてユーザによる車両１の利用パターン、ユーザの年齢や性別、居住エリア、趣味などの様々なパラメータに応じて提案するアプリおよびタイミングを予め定めておくことで、広範なユーザ情報に基づいて適当なサービスを提供することができる。

【0076】

図１４Ｂに示すように、ＸＧＢｏｏｓｔを用いる場合は、並列した条件分岐による複数（図１４Ｂでは２個）の決定木１０６ａ，１０６ｂを用いて複数のスコア値が算出され、各決定木１０６ａ，１０６ｂのスコア値の合計値として出力値が算出される。例えば、毎週末に単独で車両１を利用している男性についての出力値は、決定木１０６ａによるスコア１と、決定木１０６ｂによるスコア４との合計値（スコア４＋スコア５）として算出される。図１４ＢのようにＸＧＢｏｏｓｔを用いる場合は、複数の決定木１０６ａ，１０６ｂで条件分岐を行うことで、図１４Ａのようにニューラルネットワークを用いる場合に比して、演算量を抑制することができる。

【0077】

第２実施形態は、第１実施形態で述べた作用効果に加え、以下のような作用効果を奏する。すなわち、サービス提供装置１００は、車両１のユーザにユーザ情報の入力を要求する情報要求部３６と、車両１のユーザにより入力されたユーザ情報を取得する情報取得部３４とをさらに備える（図６Ａ）。情報要求部３６は、情報生成部１５により生成された乗車情報に基づいて、車両１のユーザが車両１に乗車している乗車時以外の非乗車時に、ユーザ情報の入力を要求する。サービス決定部３５は、情報取得部３４により取得されたユーザ情報にさらに基づいて、車両１のユーザに提供するサービスを決定する。

【0078】

例えば、ユーザ自身による複雑な入力操作などを必要とするアプリを提案する場合は、ユーザが車両１に乗車していない非乗車時に提案する。したがって、ユーザが車両１に乗車しているときに携帯端末２０に対する入力操作を要求することがなく、ユーザによる車両１の安全運転を妨げることがない。

【0079】

サービス決定部３５は、入力層３６１と、複数の中間層３６２と、出力層３６３とを有する予め学習されたニューラルネットワーク３６０を介して車両１のユーザに提供するサービスを決定するように構成される（図１４Ａ、図１４Ｂ）。入力層３６１は、情報生成部１５により生成された乗車情報と、情報取得部３４により取得されたユーザ情報とを取得する。出力層３６３は、車両１のユーザに提供するサービスを出力する。これにより、広範なユーザ情報に基づいて適当なサービスを提供することができる。

【0080】

サービス決定部３５は、情報生成部１５により生成されて記憶部３３に蓄積された乗車情報に基づいて、車両１のユーザが車両１から降車してから所定時間後に、車両１のユーザにアプリを提案することを決定する。広範なユーザ情報に基づいて適当なアプリを提案することで、ユーザのライフスタイル全般を支援することができる。

【0081】

－第３実施形態－
図１５を参照して本発明の第３実施形態について説明する。第３実施形態では、第２実施形態のサービス決定部３５（図１１）を構成するニューラルネットワーク３６０（図１４Ａ、図１４Ｂ）が、追加的に取得される教師データに基づいて学習され、提案モデルが更新される。すなわち、ニューラルネットワーク３６０における重み変数が更新される。以下では、第２実施形態との相違点を主に説明する。

【0082】

コンシェルジュ２６から画面表示や音声出力による提案が行われると、ユーザは携帯端末２０のタッチパネルやマイク（入力部）２２を介して提案を受け入れる、あるいは断る旨を入力することができる。例えば、図１０Ｃのように、コンシェルジュ２６からの提案の画面表示に回答ボタン２７ｂが含まれる場合は、ユーザが携帯端末２０のタッチパネル（入力部）２２を介して「見てみる」の回答ボタン２７ｂをタッチすると、提案が受け入れられたと認識される。また、ユーザが「断る」の回答ボタン２７ｂをタッチする、あるいは所定時間内に入力を行わずに提案を無視すると、提案が断られたと認識される。

【0083】

このような、ユーザが提案を受け入れたか否かに関する受入情報は、ユーザＩＤとともに、ユーザ情報として、携帯端末２０の通信部２１を介してサーバ３０Ａに送信される（図１１）。携帯端末２０からサーバ３０Ａに送信された受入情報は、情報取得部３４により取得され、ユーザＩＤに対応付けてユーザ情報として記憶部３３に記憶、蓄積される（図１１）。

【0084】

このようにサーバ３０Ａの記憶部３３に蓄積された受入情報は、ニューラルネットワーク３６０（図１４Ａ、図１４Ｂ）の追加的な教師データとして用いられ、これによりニューラルネットワーク３６０が追加的に学習されて提案モデルが更新される。これにより、ユーザの好みに合った、より受け入れやすいサービスを提案することができる。なお、このような提案モデルの学習は、ユーザごとに行ってもよく、ユーザグループごとに行ってもよい。例えば、コンシェルジュサービスの複数のユーザを世代や地域ごとに複数のグループに分類し、グループごとに提案モデルの学習を行ってもよい。

【0085】

図１５は、情報取得部３４が取得するユーザ情報について説明するための図であり、追加的な教師データの別の例を示す。追加的な教師データとして用いられるユーザ情報には、受入情報に加え、コンシェルジュサービスからの提案によらずにユーザが利用したアプリの情報が含まれてもよい。この場合、携帯端末２０において起動されたアプリの情報が乗車情報との関連で取得される。

【0086】

図１５の例では、時刻ｔ４１においてユーザが運転者として単独で５シータの車両１に乗車した後、時刻ｔ４２において追加的に３名の同乗者が車両１に乗車して乗員が４名に増加する。また、時刻ｔ４５において車両１から１名の同乗者が降車して乗員が３名に減少し、時刻ｔ４６において車両１からさらに２名の同乗者が降車してユーザの単独乗車に戻る。さらに、時刻ｔ４７においてユーザが車両１から降車した後、時刻ｔ４８においてユーザがコンシェルジュサービスからの提案によらずに特定のアプリ（例えば、婚活用のマッチングアプリ）を起動する。

【0087】

このように、ユーザがコンシェルジュサービスからの提案によらずに特定のアプリを起動すると、一連の情報が追加的な教師データとして抽出される。具体的には、ユーザが起動したアプリの情報と、アプリを起動した時刻ｔ４８の直前のドライビングサイクルｔ４４～ｔ４７の乗車情報とが、追加的な教師データとして抽出され、提案モデルの追加的な学習に用いられる。これにより、例えば、学習前の提案モデルでは車両１を単独利用した場合のみ提案される婚活用のマッチングアプリを、学習後の提案モデルではドライビングサイクル中に乗員数が減少した場合にも提案することができる。

【0088】

第３実施形態は、第２実施形態で述べた作用効果に加え、以下のような作用効果を奏する。すなわち、サービス提供装置１００は、情報生成部１５により生成された乗車情報と、情報取得部３４により取得されたユーザ情報とを記憶する記憶部３３と、車両１の車内で、サービス決定部３５により決定されたサービスを車両１のユーザに提案する出力部２３とをさらに備える（図１１）。ユーザ情報は、出力部２３を介して提案されたサービスが車両１のユーザに受け入れられたか否かに関する受入情報を含む。ニューラルネットワーク３６０は、記憶部３３に記憶された乗車情報およびユーザ情報に基づいて追加的に学習される。これにより、ユーザがより受け入れやすい適当なアプリを提案することができる。

【0089】

－第４実施形態－
図１６を参照して本発明の第４実施形態について説明する。第４実施形態では、コンシェルジュアプリの非起動中にもコンシェルジュサービスからの提案が行われる。以下では、第１実施形態との相違点を主に説明する。

【0090】

図１６は、コンシェルジュアプリを非起動中の携帯端末２０の画面表示の一例を示す図であり、携帯端末２０のロック画面に表示されるコンシェルジュサービスからの通知の一例を示す。サービス決定部３５（図６Ａ）により決定されたアプリの提案時刻（例えば、図９の時刻ｔ２２）にユーザの携帯端末２０でコンシェルジュアプリが起動されていない場合、コンシェルジュ２６からの提案内容がロック画面に表示される。例えば、図１６に示すように、携帯端末２０のロック画面にコンシェルジュアプリからのプッシュ通知２８として表示される。

【0091】

図１６に示すように、プッシュ通知２８の表示内容には提案時刻と提案内容とが含まれるため、ユーザはコンシェルジュアプリからの提案内容を確認するか否かを容易に判断することができる。例えば、提案時刻から時間が経過していて車両１の現在の走行エリアが提案時刻の走行エリアから離れている場合には、そのまま提案を無視することができる。また、走行エリアが離れていない場合や提案内容が魅力的な場合には、より詳細な提案内容を確認することができる。

【0092】

－第５実施形態－
図１７を参照して本発明の第５実施形態について説明する。第５実施形態では、車両１のユーザに対し、車両１に装備されたシートヒータなどの遠隔操作が提案される。以下では、第１実施形態との相違点を主に説明する。

【0093】

図１７は、車両１の運転席に搭載されるシート２の一例を示す斜視図であり、シートヒータ７が装備されたシート２の一例を示す。図１７に示すように、乗員が着座するシート２の着座面などには、表皮と内部のパッドとの間に、電熱線などにより構成されて着座面を加温するシートヒータ７が設けられる。シートヒータ７は、電熱線に通電することでシート２の着座面を加温するが、気温が著しく低い場合などは温まるまでに時間を要する。

【0094】

サービス決定部３５（図６Ａ）は、情報生成部１５により生成されて記憶部３３に蓄積された乗車情報に基づいて、ユーザが車両１に乗車する前に遠隔操作でシートヒータ７による加温を開始することを提案する。このような提案は、例えば出勤などで毎日決まった時刻に、自宅に駐車した車両１に乗車するユーザに対し、ユーザの現在地周辺の気温が所定温度（例えば、３℃）以下のときに行う。ユーザの現在地周辺の気温は、気象情報および携帯端末２０の位置情報に基づいて決定することができる。

【0095】

この場合、乗車予定時刻の所定時間前（例えば、３０分前）になると、例えば、コンシェルジュアプリからのプッシュ通知２８として「今朝は寒いですね。車のエアコンやシートヒータを付けましょうか？」などの提案を行う。ユーザが提案を受け入れると、車両１のリモコンエンジンスタータを遠隔操作するアプリを起動して、乗車予定時刻の所定時間前（例えば、５分前）に遠隔操作で車両１を始動し、車両１のシートヒータ７やエアコンを起動する。これにより、ユーザが車両１に乗車するときの快適性を向上することができる。車両１のリアシートに駆動機構を設け、シートアレンジを遠隔操作するようにしてもよい。

【0096】

－第６実施形態－
図１８～図１９Ｂを参照して本発明の第６実施形態について説明する。第６実施形態では、シート２に、携帯端末２０の入力部２２を遠隔操作するためのタッチセンサ８が設けられる。以下では、第１実施形態との相違点を主に説明する。

【0097】

図１８は、第６実施形態に係るサービス提供装置１００Ｂの全体構成を示すブロック図である。図１８に示すように、タッチセンサ８は、有線または無線により携帯端末２０に接続され、携帯端末２０の入力部２２を遠隔操作する。タッチセンサ８は、静電容量センサなどにより構成され、タッチ操作やフリック操作などのユーザによる入力操作を受け付ける。

【0098】

図１９Ａ、図１９Ｂは、タッチセンサ８の配置の一例を示す図である。図１９Ａに示すように、タッチセンサ８は、例えばシート２の車内側の台座部分に設けられる。図１９Ｂに示すように、シート２がアームレストを有する場合は、アームレストの先端部にタッチセンサ８が設けられてもよい。ユーザは、コンシェルジュ２６からの提案を受け入れる、あるいは断る旨を入力するとき、携帯端末２０のマイク（入力部）２２による音声入力に代えて、タッチセンサ８による入力操作を行うことができる。例えば、所定時間（例えば、１秒）以内に１回のタッチ操作で提案を受け入れ、２回のタッチ操作で提案を断る旨を入力することができる。

【0099】

図１９Ａおよび図１９Ｂに示すように、シート２にはさらに、乗員（運転者）の頭部付近の背もたれ部の上部にケース２ａが設けられ、携帯端末２０を収容可能に構成される。これにより、携帯端末２０のスピーカ（出力部）２３からの音声出力をユーザにとって聴き取りやすくすることができる。また、運転中のユーザが携帯端末２０の画面を見ることを確実に防止することができる。

【0100】

また、ケース２ａの前面にＱＲコード（登録商標）などを貼り付け、携帯端末２０の撮影部によりＱＲコード（登録商標）を撮影することで携帯端末２０とコントローラ１０との通信接続を確立するようにしてもよい。これにより、車両１に乗車する複数のユーザがそれぞれ携帯端末２０を携帯している場合など、車内に複数の携帯端末２０が存在する場合でも、ユーザが希望する携帯端末２０を接続することができる。また、ユーザが運転者であることを容易に把握することができる。

【0101】

－第７実施形態－
図２０および図２１を参照して本発明の第７実施形態について説明する。図２０は、第７実施形態に係るサービス提供装置１００Ｃの全体構成を示すブロック図である。図２０に示すように、第７実施形態では、車両１の車両用コントローラ１０Ｃの一部が第１～第６実施形態のコントローラ１０として機能する。この場合、車両用コントローラ１０Ｃに接続され、車両１のインストルメントパネルに設けられたディスプレイやスピーカなどが出力部２３Ｃとして機能する。

【0102】

図２１は、出力部２３Ｃの一例を示す図である。図２１に示すように、コンシェルジュ２６からの提案は、車両１のディスプレイ（出力部）２３Ｃを介して画面表示により行われる、あるいは、車両１のスピーカ（出力部）２３Ｃを介して音声出力により行われる。この場合、車両１に乗車する複数のユーザがコンシェルジュ２６からの提案を共通の画面表示や音声出力を介して共有することができる。

【0103】

なお、車両１は、ユーザが所有する車両に限らず、シェアリングサービスやレンタカーサービスの貸出車両などであってもよい。

【0104】

以上の説明はあくまで一例であり、本発明の特徴を損なわない限り、上述した実施形態および変形例により本発明が限定されるものではない。上記実施形態と変形例の１つまたは複数を任意に組み合わせることも可能であり、変形例同士を組み合わせることも可能である。

【符号の説明】

【0105】

１ 車両、２，３（３ａ～３ｄ） シート、４，５（５ａ～５ｄ） 着座センサ、１０ コントローラ、１１ 通信部、１２ 演算部、１３ 記憶部、１４ 情報取得部、１５ 情報生成部、１６ 情報出力部、２０ 携帯端末、２１ 通信部、２２ 入力部、２３ 出力部、２４ 演算部、２５ 記憶部、２６ コンシェルジュキャラクタ（コンシェルジュ）、３０ サーバ、３１ 通信部、３２ 演算部、３３ 記憶部、３４ 情報取得部、３５ サービス決定部、３６ 情報要求部、１００ サービス提供装置、３６０ ニューラルネットワーク、３６１ 入力層、３６２ 中間層、３６３ 出力層

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5A】

【図5B】

【図5C】

【図6A】

【図6B】

【図7】

【図8】

【図9】

【図10A】

【図10B】

【図10C】

【図11】

【図12】

【図13】

【図14A】

【図14B】

【図15】

【図16】

【図17】

【図18】

【図19A】

【図19B】

【図20】

【図21】