特開 2023-170481 車載通信機及びプッシュサーバ

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023170481

(43)【公開日】2023-12-01

(54)【発明の名称】車載通信機及びプッシュサーバ

(51)【国際特許分類】

   H04L 67/55 20220101AFI20231124BHJP

【ＦＩ】

H04L67/55

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2022082281

(22)【出願日】2022-05-19

(71)【出願人】

【識別番号】000004260

【氏名又は名称】株式会社デンソー

(74)【代理人】

【識別番号】110000567

【氏名又は名称】弁理士法人サトー

(72)【発明者】

【氏名】生島 佳祐

(57)【要約】

【課題】プッシュサーバから送信されるプッシュデータの通知監視を行う際の待機電力を適切に抑制すると共に、プッシュサーバから送信されるプッシュデータを適切に受信する。
【解決手段】車載通信機４は、アプリサーバ２からプッシュデータの送信要求がプッシュサーバ３に受信されたことで当該プッシュサーバからプッシュデータを受信すると、その受信したプッシュデータを車載電子制御装置へ送信する。車載通信機４は、プッシュサーバからの起動要求の通知監視を、待機電力が第２方式よりも小さい第１方式で行う通知監視部４ａと、プッシュサーバからのプッシュデータの受信を、プッシュサーバから受信可能なプッシュデータのデータ長が第１方式よりも長い第２方式で行う受信制御部４ｂと、を備える。
【選択図】図１

【特許請求の範囲】

【請求項1】

アプリサーバからプッシュデータの送信要求がプッシュサーバに受信されたことで当該プッシュサーバからプッシュデータを受信すると、その受信したプッシュデータを車載電子制御装置へ送信する車載通信機（４）であって、
前記プッシュサーバからの起動要求の通知監視を、待機電力が第２方式よりも小さい第１方式で行う通知監視部（４ａ）と、
前記プッシュサーバからのプッシュデータの受信を、前記プッシュサーバから受信可能なプッシュデータのデータ長が前記第１方式よりも長い前記第２方式で行う受信制御部（４ｂ）と、を備える車載通信機。

【請求項2】

前記通知監視部は、前記プッシュサーバからの起動要求の通知監視を前記第１方式及び前記第２方式の何れで行っているかを示す通知監視情報を、自機を識別可能な機器識別情報と対応付けて前記プッシュサーバへ通知する請求項１に記載した車載通信機。

【請求項3】

前記通知監視部は、前記プッシュサーバとの前記第１方式の接続を確立し、前記プッシュサーバとの前記第２方式の接続を切断することで、前記プッシュサーバからの起動要求の通知監視を前記第１方式で行う請求項１又は２に記載した車載通信機。

【請求項4】

前記通知監視部は、待機電力の抑制条件が成立した場合に、前記プッシュサーバとの前記第１方式の接続を確立し、前記プッシュサーバとの前記第２方式の接続を切断する請求項３に記載した車載通信機。

【請求項5】

アプリサーバからプッシュデータの送信要求を受信すると、プッシュデータを車載通信機へ送信するプッシュサーバ（３）であって、
起動要求の前記車載通信機への通知を、前記車載通信機における待機電力が第２方式よりも小さい第１方式で行う通知制御部（３ａ）と、
プッシュデータの前記車載通信機への送信を、前記車載通信機へ送信可能なプッシュデータのデータ長が前記第１方式よりも長い前記第２方式で行う送信制御部（３ｂ）と、を備えるプッシュサーバ。

【請求項6】

起動要求の前記車載通信機への通知のリトライ回数を判定するリトライ回数判定部（３ｃ）と、
起動要求を前記車載通信機へ通知してからの経過時間を判定する経過時間判定部（３ｄ）と、を備え、
前記通知制御部は、起動要求の前記車載通信機への通知のリトライ回数が一定回数に達していないと判定され、起動要求を前記車載通信機へ通知してからの経過時間が一定時間に達したと判定されると、起動要求の前記車載通信機への通知のリトライを前記第１方式で行う請求項５に記載したプッシュサーバ。

【請求項7】

起動要求の前記車載通信機への通知のリトライ回数が一定回数に達したと判定されると、プッシュデータの送信失敗を示す送信失敗通知を前記アプリサーバへ通知する送信失敗通知部（３ｅ）を備える請求項６に記載したプッシュサーバ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、車載通信機及びプッシュサーバに関する。

【背景技術】

【0002】

車両外部から車載システムのアプリケーションへアクセスする遠隔要求サービスの一つとして、プッシュデータを送信するプッシュシステムが供されている。プッシュシステムは、クラウド側にアプリサーバ及びプッシュサーバが設けられ、車両側に車載通信機及び車載電子制御装置（以下、車載ＥＣＵ（Electronic Control Unit）と称する）が設けられる。プッシュサーバは、例えばスマートフォン端末等によりクラウド側のアプリケーションが起動され、アプリサーバからプッシュデータの送信要求を受信すると、プッシュデータを車載通信機へ送信する。車載通信機は、プッシュサーバから送信されたプッシュデータを車載ＥＣＵへ送信し、車載ＥＣＵに搭載されている車載システム側のアプリケーションへプッシュデータを伝達する（例えば特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１９－１９２９５３号公報

【発明の概要】

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

【0004】

車載通信機では、プッシュサーバから送信されるプッシュデータの受信監視を行う際の待機電力が小さいことが望ましい。特に駐車期間が長く、車両バッテリの残容量を確保する必要がある場合には、待機電力が極めて小さいことが望ましい。しかしながら、待機電力が比較的小さい方式では、プッシュサーバから受信可能なプッシュデータのデータ長が短い問題がある。

【0005】

本発明は、上記した事情に鑑みてなされたものであり、その目的は、待機電力を適切に抑制すると共に、プッシュサーバから送信されるプッシュデータを適切に受信することができる車載通信機、プッシュデータを車載通信機へ適切に送信することができるプッッシュサーバを提供することにある。

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

【0006】

請求項１に記載した車載通信機（４）によれば、アプリサーバからプッシュデータの送信要求がプッシュサーバに受信されたことで当該プッシュサーバからプッシュデータを受信すると、その受信したプッシュデータを車載電子制御装置へ送信する。通知監視部（４ａ）は、プッシュサーバからの起動要求の通知監視を、待機電力が第２方式よりも小さい第１方式で行う。受信制御部（４ｂ）は、プッシュサーバからのプッシュデータの受信を、プッシュサーバから受信可能なプッシュデータのデータ長が第１方式よりも長い第２方式で行う。

【0007】

プッシュサーバからの起動要求の通知監視を第１方式で行い、プッシュサーバからのプッシュデータの受信を第２方式で行うようにした。起動要求の通知監視を、待機電力が第２方式よりも小さい第１方式で行うことで、待機電力を適切に抑制することができる。プッシュサーバからのプッシュデータの受信を、プッシュサーバから受信可能なプッシュデータのデータ長が第１方式よりも長い第２方式で行うことで、プッシュサーバから送信されるプッシュデータを適切に受信することができる。これにより、待機電力を適切に抑制すると共に、プッシュサーバから送信されるプッシュデータを適切に受信することができる。

【0008】

請求項５に記載したプッシュサーバ（３）によれば、アプリサーバからプッシュデータの送信要求を受信すると、プッシュデータを車載通信機へ送信する。通知制御部（３ａ）は、起動要求の車載通信機への通知を、車載通信機における待機電力が第２方式よりも小さい第１方式で行う。プッシュデータ送信制御部（３ｂ）は、プッシュデータの車載通信機への送信を、車載通信機へ送信可能なプッシュデータのデータ長が第１方式よりも長い第２方式で行う。

【0009】

起動要求の車載通信機への通知を第１方式で行い、プッシュデータの車載通信機への送信を第２方式で行うようにした。プッシュデータの車載通信機への送信を、車載通信機へ送信可能なプッシュデータのデータ長が第１方式よりも長い第２方式で行うことで、プッシュデータを車載通信機へ適切に送信することができる。

【図面の簡単な説明】

【0010】

【図1】第１実施形態を示し、プッシュシステムの全体構成を示す図

【図2】車載通信機及びプッシュサーバの機能ブロック図

【図3】シーケンス図

【図4】シーケンス図

【図5】シーケンス図

【図6】シーケンス図

【図7】第２実施形態を示し、車載通信機及びプッシュサーバの機能ブロック図

【図8】シーケンス図

【図9】シーケンス図

【図10】シーケンス図

【図11】第３実施形態を示すシーケンス図

【図12】シーケンス図

【図13】シーケンス図

【図14】第４実施形態を示すシーケンス図

【図15】シーケンス図

【図16】シーケンス図

【図17】シーケンス図

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

【0011】

以下、複数の実施形態について図面を参照して説明する。複数の実施形態において共通する部分については説明を省略することがある。
（第１実施形態）
第１実施形態について図１から図６を参照して説明する。図１に示すプッシュシステム１は、クラウド側に設けられているアプリサーバ２及びプッシュサーバ３と、車両側に設けられている車載通信機４及び車載ＥＣＵ５とを備える。車載ＥＣＵ５には遠隔要求サービスを実現するためのアプリケーション６が搭載されている。プッシュシステム１は、アプリサーバ２からアプリケーション６へプッシュデータの送信を可能にするシステムである。

【0012】

例えばユーザが遠隔による乗車前のエアコン開始やドアロック等のアプリをスマートフォン等の端末で起動させて所定操作を行うと、エアコン開始やドアロックを命令するプッシュデータの送信要求がアプリサーバ２からプッシュサーバ３へ送信され、プッシュデータが車載通信機４を経由して車載ＥＣＵ５へ送信され、エアコン開始やドアロック等を実現させるアプリケーション６に伝達される。

【0013】

図１では、クラウド側において、複数のアプリサーバ２に対して一つのプッシュサーバ３が設けられている構成を例示しているが、複数のアプリサーバ２に対して複数のプッシュサーバ３が設けられている構成であっても良い。又、車両側において、複数の車載ＥＣＵ５に対して一つの車載通信機４が設けられている構成を例示しているが、複数の車載ＥＣＵ５に対して複数の車載通信機４が設けられている構成であっても良い。

【0014】

プッシュシステム１にはオートモーティブ無線通信プラットフォーム７が採用されている。オートモーティブ無線通信プラットフォーム７は、クラウド側のＡＣＰクラウド８及び車両側のＡＣＰエンジン９により機能が実現され、いつでも、どこでも、アプリサーバ２とアプリケーション６との間のセキュアな接続を可能にする。詳述すると、車載ＥＣＵ５は、例えば車両が駐車中の場合には電源がオフ状態となり、電源状態が互いに異なっている。又、各車両では車載ＥＣＵ５を含むシステム構成が互いに異なっている。オートモーティブ無線通信プラットフォーム７は、このような車載ＥＣＵ５の電源状態の違い及び各車両のシステム構成の違いをアプリサーバ２側から隠蔽する。その結果、車両毎の単位で全ての車載ＥＣＵ５があたかも車外のネットワークに常時接続されているような擬似的な常時接続が実現可能となる。

【0015】

以下、オートモーティブ無線通信プラットフォーム７が搭載されるクラウド側のシステム及び車両側の車載システムについて説明する。
（１）クラウド側のシステム
最初に、車両側の車載システムについて説明する。アプリサーバ２は、プッシュデータの送信要求元として機能するサーバである。アプリサーバ２は、アプリケーション６を識別するアプリＩＤ及びトークンの少なくとも一方を管理する。アプリサーバ２は、プッシュデータの送信要求をプッシュサーバ３へ送信する場合に、アプリケーション６へ送信するメッセージ本体と共に、アプリＩＤ又はトークンを要求情報として提供する。アプリサーバ２は、要求情報としてトークンを用いる場合には、プッシュデータの送信先と対応付けられたトークンを読み出す。トークンは、プッシュサーバ３及び車載システム等においてプッシュデータの送信先を決定するキー情報となる。

【0016】

プッシュサーバ３は、プッシュデータの送信元であり、オートモーティブ無線通信プラットフォーム７のクラウド側の機能を実現するＡＣＰクラウド８として機能する構成を含む。プッシュサーバ３は、プロセッサ１０と、ＲＡＭ１１と、記憶媒体１２とを有するマイクロコントローラを主体として備える。プッシュサーバ３は、記憶媒体１２に格納されている制御プログラムをプロセッサ１０により実行して各種動作を行い、オートモーティブ無線通信プラットフォーム７のクラウド側の機能を実現する。

【0017】

プッシュサーバ３は、移動体通信網を介した無線通信による通信回線を車載通信機４との間で接続し、通信回線を接続している状態でプッシュデータを車載通信機４へ送信可能である。移動体通信網は、例えば携帯電話網、Ｗｉ－Ｆｉ（登録商標）及びＶ２Ｘ（Vehicle-to-Anything）等を含む。プッシュサーバ３は、アプリサーバ２からプッシュデータの送信要求を受信すると、プッシュデータの送信先となる車載通信機４を選択し、プッシュデータを当該送信先として選択した車載通信機４へ送信する。

【0018】

プッシュサーバ３は、ＴＬＳ（Transport Layer Security）処理等により通信相手の認証、通信内容の暗号化及び改竄の検出等の機能を提供すると共に、ＴＣＰ／ＩＰ、ＵＤＰ／ＩＰ及びこれら以外のプロトコルを用いたデータ通信の機能を提供し、アプリサーバ２及び車載通信機４との間のセキュアなデータ通信を可能とする。

【0019】

プッシュサーバ３は、プッシュデータの送信を所定時間内においてリトライすることが可能である。プッシュデータを送信する場合に、車載システムの応答が直ちに必要なシーンと、プッシュデータが通知先に届けば良いシーンとが存在し、要求されるレスポンスに応じたリトライ期限が設定される。プッシュサーバ３は、プッシュデータの送信が失敗すると、プッシュデータの内容に応じて設定されたリトライ期限に基づいてリトライ期限の経過前となる所定時間内においてプッシュデータの送信をリトライする。プッシュサーバ３は、プッシュデータの送信が失敗したままリトライ期限が経過すると、プッシュデータの送信に失敗したと判定し、プッシュデータの送信を終了する。

【0020】

（２）車両側の車載システム
次に、車両側の車載システムについて説明する。車載通信機４は、ＴＣＵ（Telematics Control Unit）又はＤＣＭ（Data Communication Module）等と呼称され、プッシュデータの送信先であり、オートモーティブ無線通信プラットフォーム７の車両側の機能を実現するＡＣＰエンジン９として機能する構成を含む。車載通信機４は、プロセッサ１３と、ＲＡＭ１４と、記憶媒体１５とを有するマイクロコントローラを主体として備える。車載通信機４は、記憶媒体１５に格納されている制御プログラムをプロセッサ１３により実行して各種動作を行い、オートモーティブ無線通信プラットフォーム７の車両側の機能を実現する。

【0021】

車載通信機４は、車内ネットワークを通じて複数の車載ＥＣＵ５と接続されている。車内ネットワークは、例えばイーサーネット（Ｅｔｈｅｒｎｅｔ）（登録商標）、ＣＡＮ（Controller Area Network）（登録商標）、ＦＬＥＸＲＡＹ（登録商標）、ＣＸＰＩ（Clock Extension Peripheral Interface）（登録商標）、ＬＩＮ（Local. Interconnect Network）等である。車内ネットワークは、パワートレイン系、シャシ系、ボディ系、マルチメディア系、安全系等の系統毎に設けられている。

【0022】

車載通信機４は、移動体通信網を介した無線通信による通信回線をプッシュサーバ３との間で接続し、通信回線を接続している状態で車載通信機４からプッシュデータを受信可能である。車載通信機４は、プッシュサーバ３からプッシュデータを受信すると、送信先となる車載ＥＣＵ５を選択し、プッシュデータを当該送信先として選択した車載ＥＣＵ５へ送信する。

【0023】

車載通信機４は、ＴＬＳ処理等により通信相手の認証、通信内容の暗号化及び改竄の検出等の機能を提供すると共に、ＴＣＰ／ＩＰ、ＵＤＰ／ＩＰ及びこれら以外のプロトコルを用いたデータ通信の機能を提供する。車載通信機４とプッシュサーバ３との間及び車載通信機４と車載ＥＣＵ５との間は、それぞれセキュアなデータ通信を可能とする場合がある。

【0024】

車載通信機４は、例えば駐車中等であり、車両の主電源がオフ、具体的には、所謂イグニッションがオフの状態である場合でも、通信ネットワークに接続されたオンラインの状態を維持可能である。車載通信機４は、プッシュサーバ３との間での無線通信を介した接続状態と、車内ネットワークにおけるプッシュデータの送信の進捗状態とを監視する。車載通信機４は、プッシュサーバ３と連携し、車載通信機４とプッシュサーバ３との間の相互接続確認を可能にする。車載通信機４とプッシュサーバ３との間の相互接続確認は死活監視と称する場合もある。

【0025】

車載通信機４は、プッシュデータが送信先に到達しなかった場合には、プッシュデータの送信の失敗を当該失敗と対応付けられる理由情報と共へ送信元へ通知する。一例として、車載通信機４は、プッシュデータの送信先となるアプリケーション６又は車載ＥＣＵ５が車内ネットワークに存在しない場合には、このような理由情報と対応付けてプッシュデータの送信の失敗を送信元であるプッシュサーバ３へ通知する。又、車載通信機４は、アプリケーション６へのプッシュデータの送信が失敗した場合には、このような理由情報と対応付けてプッシュデータの送信の失敗を送信元であるプッシュサーバ３へ通知する。

【0026】

車載通信機４は、プッシュデータの送信先となる車載ＥＣＵ５に関するＥＣＵ情報として送信先情報及びステータス情報を特定する。送信先情報は送信先情報と称する場合もある。送信先情報は、複数の車載ＥＣＵ５の中からプッシュデータの送信先となる車載ＥＣＵ５を特定可能な情報である。車載通信機４は、アプリＩＤ又はトークンを参照して送信先情報を取得する。ステータス情報は、送信先として特定された車載ＥＣＵ５の電源状態（オンオフ状態）を特定可能な情報である。詳述すると、ここでの電源オフの状態とは、イグニッションのオフ等により車載ＥＣＵ５が起動状態から休止状態等に遷移した状態である。このとき、車載ＥＣＵ５は、省電力で起動要求を受信可能である一方、データ通信が不能な状態となる。車載通信機４は、ステータス情報に基づいて送信先として特定した車載ＥＣＵ５の電源がオフ状態である場合に、当該車載ＥＣＵ５を起動させて電源をオン状態（起動状態）にする起動処理を行う。

【0027】

車載ＥＣＵ５は、一つ又は複数のアプリケーション６を搭載しており、アプリケーションを実行可能である。車載ＥＣＵ５は、プロセッサ（図示せず）と、ＲＡＭ（図示せず）と、記憶媒体（図示せず）とを有するマイクロコントローラを主体として備える。車載ＥＣＵ５は、記憶媒体に格納されている制御プログラムをプロセッサにより実行して各種動作を行い、プッシュサーバ３から送信されるプッシュデータの最終的な送信先となるエンドＥＣＵとして動作する。車載ＥＣＵ５は、車載通信機４から送信されたプッシュデータを受信すると、プッシュデータと対応付けられているアプリＩＤ又はトークンと一致する登録情報を特定し、複数のアプリケーション６の中からプッシュデータの送信先となるアプリケーション６を特定し、プッシュデータを当該送信先として特定したアプリケーション６へ送信する。

【0028】

車載ＥＣＵ５は、暗号処理機能を提供し、車載通信機４とアプリケーション６との間のセキュアなデータ通信を可能とする。車載ＥＣＵ５は、車載通信機４とは異なり、車両の電源がオフ状態である場合には、消費電力抑制のため原則的にオフ状態とされる。このとき、車載ＥＣＵ５は、通信ネットワークへの接続も切断された状態となる。尚、一部の車載ＥＣＵ５には、アプリケーション６が搭載されていなくても良い。又、車載通信機４は、車載ＥＣＵ５を兼ねる構成として車載システムに設けられ、アプリケーション６を搭載可能であっても良い。

【0029】

上記した構成では、前述したように、プッシュサーバ３から送信されるプッシュデータの通知監視を行う際の待機電力が小さいことが望ましい。特に駐車期間が長く、車両バッテリの残容量を確保する必要がある場合には、待機電力が極めて小さいことが望ましい。しかしながら、待機電力が比較的小さい方式では、プッシュサーバ３から受信可能なプッシュデータのデータ長が短かったりセキュリティ対策の制約が大きかったりする問題がある。この点に関し、本実施形態では、車載通信機４及びプッシュサーバ３は、それぞれ以下に示す機能を備える。

【0030】

本実施形態では、第１方式はショートメッセージサービス（以下、ＳＭＳ（Short Message Service）方式と称する）であり、第２方式はＭＱＴＴ（Message Queuing Telemetry Transport）方式である。ＳＭＳ方式は、待機電力がＭＱＴＴ方式よりも小さいが、通信可能なプッシュデータのデータ長がＭＱＴＴ方式よりも短く、且つセキュリティ対策の制約がＭＱＴＴ方式よりも大きい。ＭＱＴＴ方式は、通信可能なプッシュデータのデータ長がＳＭＳ方式よりも長く、且つセキュリティ対策の制約がＳＭＳ方式よりも小さいが、待機電力がＳＭＳ方式よりも大きい。即ち、ＳＭＳ方式とＭＱＴＴ方式とを比較すると、待機電力の点ではＳＭＳ方式が優位であり、通信可能なプッシュデータのデータ長及びセキュリティ対策の制約の点ではＭＱＴＴ方式が優位である。

【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】

プッシュサーバ３のプロセッサ１０及び車載通信機４のプロセッサ１３は、それぞれＣＰＵ（Central Processing Unit）等の演算コアを少なくとも一つ含む構成である。各プロセッサ１０，１３を含む処理回路は、ＦＰＧＡ（Field-Programmable Gate Array）及びＡＳＩＣ（Application-Specific Integrated Circuit）を主体とした構成であっても良い。

【0065】

プッシュサーバ３の記憶媒体１２及び車載通信機４の記憶媒体１５は、それぞれ不揮発性の記憶媒体を含む構成である。各記憶媒体１２，１５の形態は、適宜変更されても良く、例えば各記憶媒体１２，１５は、回路基板上に設けられた構成に限定されず、メモリカード等の形態で提供され、スロット部に挿入されることでプッシュサーバ３及び車載通信機４の処理回路に電気的に接続される構成であって良い。更に、各記憶媒体１２，１５は、プログラムのコピー基となる光学ディスクやハードディスクドライブ等であっても良い。

【0066】

本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することにより提供された専用コンピュータにより実現されても良い。或いは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウェア論理回路によりプロセッサを構成することにより提供された専用コンピュータにより実現されても良い。若しくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路により構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより実現されても良い。又、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていても良い。

【符号の説明】

【0067】

図面中、１はプッシュシステム、２はアプリサーバ、３はプッシュサーバ、３ａは通知制御部、３ｂは送信制御部、３ｃはリトライ回数判定部、３ｄは経過時間判定部、３ｅは送信失敗通知部、４は車載通信機、４ａは通知監視部、４ｂは受信制御部、５は車載ＥＣＵ、６はアプリケーションである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】