知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2025-04-07
(45)【発行日】2025-04-15
(54)【発明の名称】車両通信システム及び車載側システム
(51)【国際特許分類】
G06F 9/445 20180101AFI20250408BHJP
G06F 8/65 20180101ALI20250408BHJP
【ＦＩ】
G06F9/445
G06F8/65
【請求項の数】
14
(21)【出願番号】P 2023569141
(86)(22)【出願日】2022-11-07
(86)【国際出願番号】 JP2022041351
(87)【国際公開番号】W WO2023119909
(87)【国際公開日】2023-06-29
【審査請求日】2024-03-04
(31)【優先権主張番号】P 2021210817
(32)【優先日】2021-12-24
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】000004260
【氏名又は名称】株式会社デンソー
(74)【代理人】
【識別番号】110000567
【氏名又は名称】弁理士法人サトー
(72)【発明者】
【氏名】原田 雄三
(72)【発明者】
【氏名】吉見 英朗
(72)【発明者】
【氏名】小嶋 那央
【審査官】佐藤 直樹
(56)【参考文献】
【文献】特開２０１１－１４８３９８（ＪＰ，Ａ）
【文献】国際公開第２０１８／１０５６０９（ＷＯ，Ａ１）
【文献】特開２００６－２９３７３０（ＪＰ，Ａ）
【文献】米国特許出願公開第２０２０／００７３７８３（ＵＳ，Ａ１）
【文献】国際公開第２０２１／１６６６１７（ＷＯ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ９／４４５
Ｇ０６Ｆ ８／６５
(57)【特許請求の範囲】
【請求項1】
車両に搭載される電子制御装置（５２，５３）に書込むデータを管理し、無線通信により更新データを前記車両に送信するための複数の機能をアプリケーションプログラムにより実行するもので、一部の機能を実現するアプリケーションプログラムは、常にリソースが割り当てられて常駐型のプロセスとして実行されるサーバアーキテクチャを採用しており、
その他の機能のうち少なくとも一部を実現するアプリケーションプログラムは、イベントの発生を契機として起動され、オンデマンド方式により前記アプリケーションプログラムのコードの実行に対してリソースが動的に割り当てられ、
前記コードの実行が完了すれば、前記アプリケーションプログラムに割り当てられたリソースが開放されるサーバレスアーキテクチャを採用しており、
車両から車両構成情報を受信し、その車両に対するキャンペーン情報があるか否か判定するキャンペーン判定部（１５）と、
前記キャンペーン情報があれば、前記車両に対するキャンペーン通知情報を生成するキャンペーン生成部（１５）と、
前記キャンペーン情報の生成状態を管理するステータス管理部（１２、２０，４１、４３）と、
前記生成状態に応じて、前記キャンペーン通知情報を車両に配信するキャンペーン送信部（１１）とを備え、
前記キャンペーン判定部、前記ステータス管理部及び前記キャンペーン生成部の機能を実現するアプリケーションプログラムが、前記サーバレスアーキテクチャを採用しているセンタ装置と、
前記電子制御装置を含み、前記センタ装置と無線通信を行なう車載側システムとで構成される車両通信システムにおいて、
前記車載側システムが、車両情報を含む第１リクエストを前記センタ装置に送信すると、
前記キャンペーン送信部は、前記リクエストに対応するジョブＩＤを含む中間レスポンスを前記車載側システムに送信し、
前記車載側システムは、前記中間レスポンスを受信すると、前記第１リクエストに対応した最終レスポンスの応答要求を、前記ジョブＩＤを付与した第２リクエストとして前記センタ装置に送信する車両通信システム。
【請求項2】
車両に搭載される電子制御装置（５２，５３）に書込むデータを管理し、無線通信により更新データを前記車両に送信するための複数の機能をアプリケーションプログラムにより実行するもので、少なくとも一部の機能を実現するアプリケーションプログラムは、イベントの発生を契機として起動され、オンデマンド方式により前記アプリケーションプログラムのコードの実行に対してリソースが動的に割り当てられ、
前記コードの実行が完了すれば、前記アプリケーションプログラムに割り当てられたリソースが開放されるサーバレスアーキテクチャを採用しており、
車両から車両構成情報を受信し、その車両に対するキャンペーン情報があるか否か判定するキャンペーン判定部（１５）と、
前記キャンペーン情報があれば、前記車両に対するキャンペーン通知情報を生成するキャンペーン生成部（１５）と、
前記キャンペーン情報の生成状態を管理するステータス管理部（１２、２０，４１、４３）と、
前記生成状態に応じて、前記キャンペーン通知情報を車両に配信するキャンペーン送信部（１１、２０）とを備え、
前記キャンペーン判定部、前記ステータス管理部及び前記キャンペーン生成部の機能を実現するアプリケーションプログラムが、前記サーバレスアーキテクチャを採用しているセンタ装置と、
前記電子制御装置を含み、前記センタ装置と無線通信を行なう車載側システムとで構成される車両通信システムにおいて、
前記車載側システムが、車両情報を含む第１リクエストを前記センタ装置に送信すると、
前記キャンペーン送信部は、前記リクエストに対応するジョブＩＤを含む中間レスポンスを前記車載側システムに送信し、
前記車載側システムは、前記中間レスポンスを受信すると、前記第１リクエストに対応した最終レスポンスの応答要求を、前記ジョブＩＤを付与した第２リクエストとして前記センタ装置に送信する車両通信システム。
【請求項3】
前記車載側システムは、前記中間レスポンスを受信した後、所定時間が経過すると前記第２リクエストを前記センタ装置に送信する請求項１又は２記載の車両通信システム。【請求項4】
前記キャンペーン送信部は、前記中間レスポンスに、前記第２リクエストの送信条件を含む付加情報を含ませて前記車載側システムに送信し、前記車載側システムは、前記中間レスポンスを受信した後、前記送信条件を満たす状態になると前記第２リクエストを送信する請求項１記載の車両通信システム。
【請求項5】
前記送信条件は、前記車載側システムが前記中間レスポンスを受信してから前記第２リクエストの送信までの待機時間であって、前記車載側システムは、前記待機時間が経過すると前記第２リクエストを送信する請求項４記載の車両通信システム。
【請求項6】
前記送信条件は、前記第２リクエストの送信を許容するエリアの指定である請求項４記載の車両通信システム。【請求項7】
前記車載側システムは、前記第１リクエストに、前記車両において収集した車両構成情報にハッシュ関数を適用して求めたハッシュ値を含ませる請求項１記載の車両通信システム。
【請求項8】
前記キャンペーン送信部は、前記最終レスポンスとして、前記車両において収集された車両構成情報の全データの送信要求を含ませて前記車載側システムに送信し、前記車載側システムは、前記送信要求に応じて、前記第２リクエストに前記全データを含ませる請求項７記載の車両通信システム。
【請求項9】
前記キャンペーン送信部は、前記キャンペーン判定部の判定結果に応じて、前記最終レスポンスとして、前記車両に対するキャンペーン情報あり、又はキャンペーン情報なしを示す情報を前記車載側システムに送信する請求項７記載の車両通信システム。【請求項10】
前記キャンペーン判定部は、前記第１リクエストに対応する車両のＩＤ情報が、優先処理リストに登録されているか否かを判断し、前記優先処理リストに登録されていなければ、前記車両に対するキャンペーン情報があるか否かを判定することなく、前記最終レスポンスとして、キャンペーン情報なしを示す情報を、前記キャンペーン送信部を介して前記車載側システムに送信させる請求項９記載の車両通信システム。【請求項11】
前記車載側システムは、車両の乗員が入力操作を行うユーザインターフェース部を備え、前記ユーザインターフェース部において行われた入力操作に基づく処理が、前記センタ装置からの応答の受信を伴なうものである際に、前記応答の受信を待つことなく次のユーザインターフェース処理に進む請求項１記載の車両通信システム。
【請求項12】
前記車載側システムは、車両の乗員が入力操作を行うユーザインターフェース部を備え、前記ユーザインターフェース部において行われた入力操作に基づく処理が、前記センタ装置からの応答の受信を伴なうものである際に、前記応答を受信するか、又は所定時間が経過すると、次のユーザインターフェース処理に進む請求項１記載の車両通信システム。
【請求項13】
車両に搭載される電子制御装置（５２，５３）に書込むデータを管理し、無線通信により更新データを前記車両に送信するための複数の機能をアプリケーションプログラムにより実行するもので、一部の機能を実現するアプリケーションプログラムは、常にリソースが割り当てられて常駐型のプロセスとして実行されるサーバアーキテクチャを採用しており、
その他の機能のうち少なくとも一部を実現するアプリケーションプログラムは、イベントの発生を契機として起動され、オンデマンド方式により前記アプリケーションプログラムのコードの実行に対してリソースが動的に割り当てられ、前記コードの実行が完了すれば、前記アプリケーションプログラムに割り当てられたリソースが開放されるサーバレスアーキテクチャを採用しており、
車両から車両情報を受信し、その車両に対するキャンペーン情報があるか否か判定するキャンペーン判定部（１５）と、
前記キャンペーン情報があれば、前記車両に対するキャンペーン通知情報を生成するキャンペーン生成部（１５）と、
前記キャンペーン情報の生成状態を管理するステータス管理部（１２、２０，４１、４３）と、
前記生成状態に応じて、前記キャンペーン通知情報を車両に配信するキャンペーン送信部（１１）と、を備え、
前記キャンペーン判定部、前記ステータス管理部及び前記キャンペーン生成部の機能を実現するアプリケーションプログラムが、前記サーバレスアーキテクチャを採用しているセンタ装置と無線通信を行なう、前記電子制御装置を含む車載側システムであって、
車両情報を含む第１リクエストを前記センタ装置に送信し、
前記センタ装置より、前記リクエストに対応するジョブＩＤを含む中間レスポンスを受信し、
前記中間レスポンスを受信すると、前記第１リクエストに対応した最終レスポンスの応答要求を、前記ジョブＩＤを付与した第２リクエストとして前記センタ装置に送信する車載側システム。
【請求項14】
車両に搭載される電子制御装置（５２，５３）に書込むデータを管理し、無線通信により更新データを前記車両に送信するための複数の機能をアプリケーションプログラムにより実行するもので、少なくとも一部の機能を実現するアプリケーションプログラムは、イベントの発生を契機として起動され、オンデマンド方式により前記アプリケーションプログラムのコードの実行に対してリソースが動的に割り当てられ、前記コードの実行が完了すれば、前記アプリケーションプログラムに割り当てられたリソースが開放されるサーバレスアーキテクチャを採用しており、
車両から車両情報を受信し、その車両に対するキャンペーン情報があるか否か判定するキャンペーン判定部（１５）と、
前記キャンペーン情報があれば、前記車両に対するキャンペーン通知情報を生成するキャンペーン生成部（１５）と、
前記キャンペーン情報の生成状態を管理するステータス管理部（１２、２０，４１、４３）と、
前記生成状態に応じて、前記キャンペーン通知情報を車両に配信するキャンペーン送信部（１１、２０）と、を備え、
前記キャンペーン判定部、前記ステータス管理部及び前記キャンペーン生成部の機能を実現するアプリケーションプログラムが、前記サーバレスアーキテクチャを採用しているセンタ装置と無線通信を行なう、前記電子制御装置を含む車載側システムであって、
車両情報を含む第１リクエストを前記センタ装置に送信し、
前記センタ装置より、前記リクエストに対応するジョブＩＤを含む中間レスポンスを受信し、
前記中間レスポンスを受信すると、前記第１リクエストに対応した最終レスポンスの応答要求を、前記ジョブＩＤを付与した第２リクエストとして前記センタ装置に送信する車載側システム。
【発明の詳細な説明】
【関連出願の相互参照】
【0001】
本出願は、２０２１年１２月２４日に出願された日本出願番号２０２１－２１０８１７号に基づくもので、ここにその記載内容を援用する。
【技術分野】
【0002】
本開示は、車両通信システム及び車載側システムに関する。
【背景技術】
【0003】
近年、運転支援機能や自動運転機能等の車両制御の多様化に伴い、車両の電子制御装置（以下、ＥＣＵ（Electronic Control Unit）と称する）に搭載される車両制御や診断等のアプリプログラムの規模が増大している。また、機能改善等によるバージョンアップに伴い、ＥＣＵのアプリプログラムを書換える，所謂リプログを行う機会も増えつつある。一方、通信ネットワークの進展等に伴い、コネクッテッドカーの技術も普及している。このような事情から、例えば特許文献１には、サーバよりＥＣＵの更新プログラムをＯＴＡ（Over The Air）により車載装置に配信し、車両側で更新プログラムを書換える技術が開示されている。
【先行技術文献】
【特許文献】
【0004】
【文献】特開２０２０－２７６２４号公報
【発明の概要】
【0005】
特許文献１に開示されているセンタ装置を実際に構成しようとすると、例えば図５３に示すような構成となり、センタ装置を構成する各管理ブロック等は、一般にサーバを用いることを前提としたアーキテクチャにより実現されるもの、と想定される。尚、本願では、サーバを用いることを前提としてアプリケーションプログラムを実行させる環境又は構成を、「サーバアーキテクチャ」と称する。換言すれば、サーバアーキテクチャにおいては、アプリケーションプログラムには常にリソースが割り当てられており、当該プログラムは常駐型プロセスとして実行される。
【0006】
しかしながら、図５４に示すように、車両からセンタ装置が備えるサーバに対するアクセスは、日中に多くなり、夜間は少なくなると想定される。そのため、夜間にサーバを稼働させると、そのコストに無駄が多くなってしまう。
【0007】
また、法規的に、コネクッテッドカーに対応したセンタ装置は、各国毎に設置する必要がある。そのため、各国に対して同じ規模のシステムを構築すると、車両が少ない地域では、やはりサーバを稼働させるコストに無駄が多くなってしまう（図５５参照）。
【0008】
そこで、センタ装置側でアプリケーションプログラムを実行させる環境又は構成を、上記のサーバアーキテクチャに依らない、サーバレスアーキテクチャによって実現することを想定する。サーバレスアーキテクチャについては、「発明を実施するための形態」において詳述するが、オンデマンドでプログラムコードを実行するため、サーバを使用することなく、コンピューティングサービスを使用するものを言う。
【0009】
車両とセンタ装置との間で行われる通信は、基本的に、車両からのリクエストに応じた処理がセンタ装置で行われた後、車両にレスポンスを返す、といった流れになる。そして、サーバレスアーキテクチャを採用すると、処理が実行される毎にコンピューティングサービスにおける課金が発生する。したがって、課金の発生を如何にして抑制するか、ということが問題となる。また、車両とセンタ装置との間で行われる通信を効率的に行い、コンピューティングリソースの有効利用を図る必要がある。
【0010】
本開示は上記事情に鑑みてなされたものであり、その目的は、複数台の車両がセンタ装置と無線通信を行なう際に、サーバレスアーキテクチャの採用に伴い発生するコンピューティングリソースの消費を極力抑制できる車両通信システム及び車載側システムを提供することにある。
【0011】
請求項１又は２記載の車両通信システムによれば、センタ装置は、車両に搭載される電子制御装置に書込むデータを管理し、無線通信により更新データを前記車両に送信するための複数の機能をアプリケーションプログラムにより実行する。その際に、少なくとも一部の機能を実現するアプリケーションプログラムは、イベントの発生を契機として起動され、オンデマンド方式により前記アプリケーションプログラムのコードの実行に対してリソースが動的に割り当てられ、コードの実行が完了すれば、アプリケーションプログラムに割り当てられたリソースが開放されるサーバレスアーキテクチャを採用する。
【0012】
上述したように、車両からセンタ装置へのアクセスは時間帯によって多寡があると共に、車両の数自体も地域によって異なる。そして、少なくとも一部の機能を実現するアプリケーションプログラムにサーバレスアーキテクチャを採用すれば、車両からのアクセスが発生する毎に、リソースが動的に割り当てられてプログラムが起動され、コードの実行が完了すればリソースが開放されるようになる。したがって、常駐型のプロセスとして実行されるサーバアーキテクチャを採用する場合に比較して、コンピューティングリソースの消費を節約でき、結果としてインフラに掛かるランニングコストを低減させることができる。
【0013】
また、キャンペーン判定部は、車両から車両構成情報を受信し、その車両に対するキャンペーン情報があるか否か判定する。キャンペーン生成部は、キャンペーン情報があれば、前記車両に対するキャンペーン通知情報を生成する。ステータス管理部は、キャンペーン情報の生成状態を管理し、キャンペーン送信部は、前記生成状態に応じてキャンペーン通知情報を車両に配信する。そして、キャンペーン判定部、ステータス管理部及びキャンペーン生成部の機能を実現するアプリケーションプログラムがサーバレスアーキテクチャを採用している。
【0014】
例えば、コネクション管理を行う必要がある通信においても、ステータス管理部がキャンペーン情報の生成状態を管理するので、キャンペーン生成部及びキャンペーン送信部は、キャンペーン通知情報を車両に配信するまでの期間に稼働を継続する必要がなくなる。したがって、これらの機能をサーバレスアーキテクチャにより実現したことのメリットをより多く享受できる。
【0015】
そしてこの際に、車載側システムが、車両において収集した車両構成情報を含む第１リクエストをセンタ装置に送信すると、キャンペーン送信部は、そのリクエストに対応するジョブＩＤを含む中間レスポンスを車載側システムに送信する。また、車載側システムは、中間レスポンスを受信すると、第１リクエストに対応した最終レスポンスの応答要求を、ジョブＩＤを付与した第２リクエストとしてセンタ装置に送信する。
【0016】
すなわち、車載側システムは、センタ装置と通信を行なうに当たって、２回のリクエスト送信を行なえば良い。そして、センタ装置側では、それら２回のリクエスト送信の間に、要求された処理に対応したアプリケーションプログラムを起動して処理を実行させれば良い。これにより、サーバレスアーキテクチャを採用している外部のコンピュートサービスを利用する際においても、必要な処理を実行する期間だけ当該サービスを利用できるようになる。したがって、サービスの利用時間に応じて課金されるシステムであれば、センタ装置の運用コストを低減できる。
【図面の簡単な説明】
【0017】
本開示についての上記目的およびその他の目的、特徴や利点は、添付の図面を参照しながら下記の詳細な記述により、より明確になる。その図面は、
【発明を実施するための形態】
【0018】
（第１実施形態）
【0019】
以下、第１実施形態について説明する。図１に示すように、本実施形態のセンタ装置であるＯＴＡセンタ１は、配信システム２及び共通システム３を備えている。共通システム３においては、車両であるクルマ３１に配信するＥＣＵの更新プログラムやデータを含む配信パッケージが生成されて管理され、生成された配信パッケージは配信システム２を介して、無線通信により、すなわちＯＴＡによってクルマ３１に配信される。
【0020】
共通システム３がパッケージを生成する際には、外部のサーバシステムであるＯＥＭ（Original Equipment Manufacturer）バックオフィス４や、鍵管理センタ５との間で必要なデータの送受信が行われる。ＯＥＭバックオフィス４は、第１サーバ６～第４サーバ９等を備えている。これらのサーバ６～９は図５３に示すものと同様であり、それぞれ製造情報管理系、顧客管理系、テレマティクス契約、ＳＭＳ（Short Message Service）配信用のシステムである。鍵管理センタ５は、ＯＴＡに使用する鍵の発行や管理を行うシステムである第５サーバ１０を備えている。
【0021】
第１サーバ６～第５サーバ１０では、前述したサーバアーキテクチャが採用されており、アプリケーションプログラムには常にリソースが割り当てられ、当該プログラムは常駐型プロセスとして実行される。
【0022】
配信システム２のＡＰＩ（Application Programming Interface）ゲートウェイ部（１）１１は、クルマ３１やＯＴＡ運用者３４と無線通信を行う。ＡＰＩゲートウェイ部１１が受信したデータは、コンピュートサービス関数部（１）１２、キューイングバッファ部１３、コンピュートサービス関数部（２）１４、コンピュートサービス処理部（１）１５に順次転送される。コンピュートサービス関数部１２は、データベース部（１）１６にアクセスする。コンピュートサービス処理部１５は、ファイルストレージ部１８及びデータベース部（２）１９にアクセスする。データベース部１９には、プログラム更新が必要なクルマ３１に対応したソフトウェアの更新情報であるキャンペーン情報が格納されている。ＡＰＩゲートウェイ部１１は、クルマ３１、ＯＴＡ運用者３４、スマートフォン３２、ＰＣ３３などとの間でデータの入出力や指示と応答のやりとりをする。尚、ＡＰＩゲートウェイ部１１は、ＯＴＡ運用者３４又はＰＣ３３との間で有線通信を行っても良い。
【0023】
コンピュートサービス処理部１５が出力したデータは、コンピュートサービス関数部（３）２０を介してＡＰＩゲートウェイ部１１に出力される。ＣＤＮ（Contents Delivery Network）配信部２１は、ファイルストレージ部１８にアクセスし、ファイルストレージ部１８に格納されているデータをクルマ３１にＯＴＡにより配信する。ＣＤＮ配信部２１は、ネットワーク配信部の一例である。
【0024】
共通システム３のＡＰＩゲートウェイ部（２）２２は、配信システム２のコンピュートサービス処理部１５、並びに共通システム３が備えるコンピュートサービス処理部（２）２３及びコンピュートサービス関数部（４）２４とデータの入出力を行う。コンピュートサービス処理部２３は、データベース部（３）２５及びファイルストレージ部（３）２６にアクセスする。コンピュートサービス関数部２４は、ファイルストレージ部２６及びデータベース部（４）２７にアクセスする。また、ＡＰＩゲートウェイ部２２は、ＯＥＭバックオフィス４及び鍵管理センタ５が備える各サーバ６～１０にもアクセスする。ＡＰＩゲートウェイ部２２は、ＯＥＭバックオフィス４及び鍵管理センタ５が備える各サーバ６～１０との間でデータの入出力や指示と応答のやりとりをする。
【0025】
以上の構成において、コンピュートサービス関数部１２，１４，２０及び２４、並びにコンピュートサービス処理部１５及び２３は、サーバレスアーキテクチャを採用している。「サーバレスアーキテクチャ」は、イベントの発生を契機として起動され、オンデマンド方式によりアプリケーションプログラムのコードの実行に対してリソースが自動的に割り当てられる。そして、コードの実行が完了すれば、割り当てられたリソースが自動的に開放されるように構成され、前述の「サーバアーキテクチャ」に対向した設計思想に基づいている。
【0026】
また、「サーバレスアーキテクチャ」は、イベントの発生を契機として起動され、アプリケーションプログラムのコードの実行に対してリソースが動的に割り当てられ、コードの実行が完了すれば、割り当てられたリソースが開放される。尚、コードの実行が完了すれば、リソースが開放される。リソースの開放は、コードの実行完了後に直ちに開放しても良いし、実行完了後、所定時間、例えば１０秒間待機した後に開放しても良い。
【0027】
ここで、サーバレスアーキテクチャを構成するための４つの原則を挙げると、
・オンデマンドでプログラムコードを実行するため、サーバを使用することなく、コンピューティングサービスを使用する。
・目的が１つだけの、ストレートな関数とする。
・プッシュベースのイベント駆動型パイプラインを構成する。
・より厚く強力なフロントエンドを構成する。
といったものになる。
・オンデマンドでプログラムコードを実行するため、サーバを使用することなく、コンピューティングサービスを使用する。
・目的が１つだけの、ストレートな関数とする。
・プッシュベースのイベント駆動型パイプラインを構成する。
・より厚く強力なフロントエンドを構成する。
といったものになる。
【0028】
図２は、図１に示すセンタ装置１を、ＡＷＳ（Amazon Web Service）クラウドを利用して構成した場合の一例である。
・Amazon API Gateway：ＡＰＩゲートウェイ部１１、２２に相当する。
・AWS Lambda ：コンピュートサービス関数部１２、２０、２４に相当する。
・Amazon Kinesis ：キューイングバッファ部１３に相当する。
・Elastic Load Balancing：コンピュートサービス関数部１４に相当する。
・AWS Fargate ：コンピュートサービス処理部１５に相当する。
・Amazon S3 ：ファイルストレージ部１８及び２６に相当する。
・Amazon Aurora ：データベース部１９、２５及び２７に相当する。
・Amazon API Gateway：ＡＰＩゲートウェイ部１１、２２に相当する。
・AWS Lambda ：コンピュートサービス関数部１２、２０、２４に相当する。
・Amazon Kinesis ：キューイングバッファ部１３に相当する。
・Elastic Load Balancing：コンピュートサービス関数部１４に相当する。
・AWS Fargate ：コンピュートサービス処理部１５に相当する。
・Amazon S3 ：ファイルストレージ部１８及び２６に相当する。
・Amazon Aurora ：データベース部１９、２５及び２７に相当する。
【0029】
尚、ＣＤＮ７７はＣＤＮ配信部２１に相当するが、これはＣＤＮ７７（株）が提供しているサービスである。これをＡＷＳが提供しているAmazon CloudFrontサービスに置き換えてもよい。ＣＤＮ７７は世界中に分散配置されたキャッシュサーバである。また、AWS LambdaとAWS Fargateとは共にサーバーレスコンピューティングサービスであって、同等の機能を実現できる。よって、コンピュートサービス関数部１４とコンピュートサービス処理部１５とは、ブロック図としては何れかに集約しても良い。
【0030】
次に、本実施形態の作用について説明する。図３に示すように、「車両構成情報同期」のフェーズでは、クルマ３１において、例えば２週間毎に、イグニッションスイッチがＯＮされたタイミングで車両構成情報がＯＴＡセンタ１に送信される。車両構成情報は、車両に搭載されるＥＣＵのハードウェア及びソフトウェアに関する情報である。ＯＴＡセンタ１では、送信された車両構成情報を元に、ソフトウェアの更新について適用されるキャンペーン情報があるか否かをチェックする。そして、対応するキャンペーン情報がある場合には、そのキャンペーン情報をクルマ３１に送信する。また、クルマ３１により車両構成情報が送信された際に、当該情報を、ＯＴＡセンタ１側に保持されている前記クルマ３１の車両構成情報と比較して、新しい方の情報に更新する処理を、車両構成情報の同期処理と称する。車両構成情報は車両情報の一例である。
【0031】
「キャンペーン承諾＋ＤＬ承諾」のフェーズでは、キャンペーン情報を受信したクルマ３１のドライバが、車載装置の画面に表示されたダウンロードを承諾するためのボタンを押下すると、ＣＤＮ配信部２1からプログラム更新用のデータパッケージがダウンロードされる。そのダウンロード中は、ダウンロード処理の進捗率がクルマ３１からＯＴＡセンタ１に通知される。
【0032】
ダウンロードが完了して「インストール承諾」となり、インストールが実行されると、そのインストール処理の進捗率がクルマ３１からＯＴＡセンタ１に通知される。インストール処理が完了して、クルマ３１において「アクティベート実施」となり、アクティベートが完了すると、アクティベートの完了がＯＴＡセンタ１に通知される。
尚、「キャンペーン承諾＋ＤＬ承諾」と「インストール承諾」は、「キャンペーン承諾＋ＤＬ承諾」の際に、「インストール承諾」も含めてドライバから承諾を得ても良い。
尚、「キャンペーン承諾＋ＤＬ承諾」と「インストール承諾」は、「キャンペーン承諾＋ＤＬ承諾」の際に、「インストール承諾」も含めてドライバから承諾を得ても良い。
【0033】
以下、上記の各処理の詳細について説明する。
＜車両構成情報の受信→キャンペーン情報の送信＞
＜車両構成情報の受信→キャンペーン情報の送信＞
【0034】
図４に示すように、ＡＰＩゲートウェイ部１１が、クルマ３１から車両構成情報のＨＴＴＰＳ（Hypertext Transfer Protocol Secure）リクエストを受信する（Ｓ１）。そのリクエスト内容は、例えばＶＩＮ（Vehicle Identification Number）と、各ＥＣＵのハードウェアＩＤと、各ＥＣＵのソフトウェアＩＤなどである。次に、ＡＰＩゲートウェイ部１１はコンピュートサービス関数部１２を起動すると、受信した車両構成情報を当該関数部１２に渡す（Ｓ２）。
【0035】
コンピュートサービス関数部１２は、車両構成情報をキューイングバッファ部１３に渡す（Ｓ３）。キューイングバッファ部１３は、渡された車両構成情報を一定期間、例えば１秒又は数秒蓄積し、バッファリングする（Ｓ４）。ここで、コンピュートサービス関数部１２は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ５）。尚、コンピュートサービス関数部１２は、必要に応じて、ＡＰＩゲートウェイ部１１からＴＣＰポート番号を受け取り、共有メモリに保存しても良い。
【0036】
上記の一定期間が経過すると（Ｓ５Ａ）、キューイングバッファ部１３は、コンピュートサービス関数部１４を起動し、一定期間内に蓄積された車両構成情報をコンピュートサービス関数部１４に渡す（Ｓ６）。キューイングバッファ部１３は、アクセスバッファ制御部の一例である。コンピュートサービス関数部１４は、渡された車両構成情報の内容の一部を解釈し、適切な処理を実行できるコンピュートサービス処理部１５のコンテナアプリを起動すると、車両構成情報をコンピュートサービス処理部１５に渡す（Ｓ７）。
【0037】
ここで、コンテナとは、ホストＯＳ上に論理的な区画としてのコンテナを作り、アプリケーションを動作させるのに必要なライブラリやプログラム等を１つにまとめたものである。ＯＳのリソースを論理的に分離して、複数のコンテナで共有して使用する。コンテナにて実行されるアプリケーションを、コンテナアプリと称する。
【0038】
コンピュートサービス処理部１５は、データベース部１９にアクセスし、渡された車両構成情報に対応した、ソフトウェア更新情報であるキャンペーン情報が存在するか否かを判断する（Ｓ８）。キャンペーン情報が存在する場合、コンピュートサービス処理部１５は、クルマ３１に配信するキャンペーン情報を、データベース部１９を参照して生成する（Ｓ９）。ここで、コンピュートサービス処理部１５は、キャンペーン判定部及びキャンペーン生成部の一例である。また、コンピュートサービス関数部１４は第１コンピュートサービス部に相当し、コンピュートサービス処理部１５は第２コンピュートサービス部に相当する。
【0039】
コンピュートサービス処理部１５は、コンピュートサービス関数部２０を起動し、生成したキャンペーン情報を渡す（Ｓ１０）。ここで、コンピュートサービス処理部１５は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ１１）。ステップＳ８において、キャンペーンがなければ、クルマ３１に配信する「キャンペーンなし」を通知するキャンペーン情報を生成してから（Ｓ１２）、ステップＳ１０に移行する。
【0040】
コンピュートサービス関数部２０は、渡されたキャンペーン情報を対応するクルマ３１に配信するため、ＡＰＩゲートウェイ部１１に渡す。ここで、コンピュートサービス関数部２０は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ１４）。ＡＰＩゲートウェイ部１１は、クルマ３１にキャンペーン情報を含むＨＴＴＰＳレスポンスを送信する（Ｓ１５）。ＡＰＩゲートウェイ部１１は、キャンペーン送信部の一例である。
【0041】
尚、上記の処理において、コンピュートサービス関数部２０は、必要に応じて、コンピュートサービス関数部１２が保存したＴＣＰポート番号を共有メモリから取得し、そのＴＣＰポート番号に対するＨＴＴＰＳレスポンスを配信するように、ＡＰＩゲートウェイ部１１に要求するようにしても良い。
【0042】
＜キャンペーン情報の登録→ＣＤＮ配信部２１への配信パッケージの登録＞
【0043】
図５に示すように、ＯＴＡ運用者３４は、キャンペーン情報登録のＨＴＴＰＳリクエストを送信する（Ｓ２１）。ＡＰＩゲートウェイ部１１はコンピュートサービス関数部１２を起動すると、受信したキャンペーン情報を渡す（Ｓ２２）。
【0044】
コンピュートサービス関数部１２は、キャンペーン情報をキューイングバッファ部１３に渡す（Ｓ２３）。キューイングバッファ部１３は、渡されたキャンペーン情報を一定期間蓄積し、バッファリングする（Ｓ２４）。ここで、コンピュートサービス関数部１２は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ２５）。コンピュートサービス関数部１２は、キャンペーン登録部の一例であり、第５コンピュートサービス部に相当する。
【0045】
上記の一定期間が経過すると（Ｓ２５Ａ）、キューイングバッファ部１３は、コンピュートサービス関数部１４を起動し、一定期間内に蓄積されたキャンペーン情報をコンピュートサービス関数部１４に渡す（Ｓ２６）。コンピュートサービス関数部１４は、渡されたキャンペーン情報の内容の一部を解釈し、適切な処理を実行できるコンピュートサービス処理部１５のコンテナアプリを起動すると、キャンペーン情報をコンピュートサービス処理部１５に渡す（Ｓ２７）。
【0046】
コンピュートサービス処理部１５は、渡されたキャンペーン情報の中に含まれている対象車両と、更新対象のソフトウェアパッケージとの紐付けを行うため、データベース部１９にキャンペーン情報を登録する（Ｓ２８）。また、コンピュートサービス処理部１５は、コンピュートサービス関数部２０を起動し、キャンペーン情報の登録が完了した通知をＡＰＩゲートウェイ部１１に渡す（Ｓ３０）。コンピュートサービス処理部１５は、キャンペーン登録部の一例であり、第４コンピュートサービス部に相当する。
【0047】
次に、コンピュートサービス処理部１５は、ファイルストレージ部１８に、更新対象のソフトウェアパッケージとダウンロード用のＵＲＬ情報とを格納する（Ｓ３１）。ここで、コンピュートサービス処理部１５は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ３２）。そして、ファイルストレージ部１８は、ＣＤＮ配信部２１のオリジンサーバとして動作する（Ｓ３３）。コンピュートサービス処理部１５は、パッケージ配信部の一例であり、第３コンピュートサービス部に相当する。
【0048】
＜クルマからのデータアクセス→ＣＤＮから配信パッケージをクルマに送信＞
【0049】
図６に示すように、クルマ３１が、実際にはクルマ３１に搭載されているＤＣＭ（Data Communication Module）及びセントラルＥＣＵからなるＯＴＡマスタが、キャンペーン情報に含まれているダウンロードＵＲＬ情報を元に、ＣＤＮ配信部２１にアクセスする（Ｓ４１）。ＣＤＮ配信部２１は、クルマ３１から要求されたソフトウェアパッケージを、自身のキャッシュメモリに保持しているか否かを判断する（Ｓ４２）。キャッシュメモリに保持していれば、ＣＤＮ配信部２１は、クルマ３１にソフトウェアパッケージを送信する（Ｓ４３）。
【0050】
一方、要求されたソフトウェアパッケージをキャッシュメモリに保持していなければ、ＣＤＮ配信部２１は、オリジンサーバであるファイルストレージ部１８に、上記のソフトウェアパッケージを要求する（Ｓ４４）。すると、ファイルストレージ部１８は、要求されたソフトウェアパッケージをＣＤＮ配信部２１に送信する（Ｓ４５）。ＣＤＮ配信部２１は、ファイルストレージ部１８から受け取ったソフトウェアパッケージを、自身のキャッシュメモリに保持すると共に、クルマ３１に送信する（Ｓ４６）。
【0051】
＜ソフトウェア更新データの登録＞
図７に示すように、ＡＰＩゲートウェイ部２２は、ＯＥＭバックオフィス４の第１サーバ６から、ソフトウェア更新データ及びその関連情報の登録要求を、ＨＴＴＰＳリクエストとして受信する（Ｓ５１）。ＡＰＩゲートウェイ部２２は、コンピュートサービス関数部２４を起動して、ソフトウェア更新データ及び関連情報を渡す（Ｓ５２）。コンピュートサービス関数部２４は、ソフトウェア更新データ及び関連情報をファイルストレージ部２６に格納する（Ｓ５３）。
図７に示すように、ＡＰＩゲートウェイ部２２は、ＯＥＭバックオフィス４の第１サーバ６から、ソフトウェア更新データ及びその関連情報の登録要求を、ＨＴＴＰＳリクエストとして受信する（Ｓ５１）。ＡＰＩゲートウェイ部２２は、コンピュートサービス関数部２４を起動して、ソフトウェア更新データ及び関連情報を渡す（Ｓ５２）。コンピュートサービス関数部２４は、ソフトウェア更新データ及び関連情報をファイルストレージ部２６に格納する（Ｓ５３）。
【0052】
コンピュートサービス関数部２４は、ソフトウェア更新データ及び関連情報をどこに格納したのか参照できるように、データベース部２７に格納されている検索テーブルを更新する（Ｓ５４）。ここで、コンピュートサービス関数部２４は、処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ５５）。
【0053】
＜案件情報の登録→パッケージの生成＞
図８に示すように、ＯＴＡ運用者３４が、案件情報の登録を行うため、ＡＰＩゲートウェイ部１１に対して案件情報のＨＴＴＰＳリクエストを送信する（Ｓ６１）。案件情報は、ある配信パッケージを適用可能なＥＣＵのハードウェア情報やソフトウェア情報を纏めたものである。ＡＰＩゲートウェイ部１１は、コンピュートサービス関数部１２を起動すると、受信した案件情報を当該関数部１２に渡す（Ｓ６２）。
図８に示すように、ＯＴＡ運用者３４が、案件情報の登録を行うため、ＡＰＩゲートウェイ部１１に対して案件情報のＨＴＴＰＳリクエストを送信する（Ｓ６１）。案件情報は、ある配信パッケージを適用可能なＥＣＵのハードウェア情報やソフトウェア情報を纏めたものである。ＡＰＩゲートウェイ部１１は、コンピュートサービス関数部１２を起動すると、受信した案件情報を当該関数部１２に渡す（Ｓ６２）。
【0054】
コンピュートサービス関数部１２は、案件情報をキューイングバッファ部１３に渡す（Ｓ６３）。キューイングバッファ部１３は、渡された案件情報を一定期間蓄積し、バッファリングする（Ｓ６４）。コンピュートサービス関数部１２は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ６５）。尚、コンピュートサービス関数部１２は、必要に応じて、ＡＰＩゲートウェイ部１１からＴＣＰポート番号を受け取り、共有メモリに保存しておいても良い。
【0055】
上記の一定期間が経過すると、キューイングバッファ部１３は、コンピュートサービス関数部１４を起動し、一定期間内に蓄積された案件情報をコンピュートサービス関数部１４に渡す（Ｓ６６）。コンピュートサービス関数部１４は、渡された案件情報の内容の一部を解釈し、適切な処理を実行できるコンピュートサービス処理部１５のコンテナアプリを起動すると、案件情報をコンピュートサービス処理部１５に渡す（Ｓ６７）。
【0056】
コンピュートサービス処理部１５は、データベース部１９にアクセスし、渡された案件情報に含まれているソフトウェア更新対象情報を元に、ソフトウェアパッケージを生成するため、コンピュートサービス処理部２３のコンテナアプリを起動し、コンピュートサービス処理部２３にソフトウェア更新対象情報を渡す（Ｓ６８）。コンピュートサービス処理部１５は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ７０）。
【0057】
コンピュートサービス処理部２３は、渡されたソフトウェア更新対象情報を元に、ＡＰＩゲートウェイ部２２に対して、ソフトウェア更新データ要求のＨＴＴＰＳリクエストを送信する（Ｓ７１）。ＡＰＩゲートウェイ部２２は、コンピュートサービス関数部２４を起動し、ソフトウェア更新データ要求を渡す（Ｓ７２）。コンピュートサービス関数部２４は、データベース部２７を参照し、ソフトウェア更新データが格納されているファイルストレージ部２６のパス情報を取得する（Ｓ７３）。
【0058】
コンピュートサービス関数部２４は、取得したパス情報を元にファイルストレージ部２６にアクセスし、ソフトウェア更新データを取得する（Ｓ７４）。そして、取得したソフトウェア更新データをコンピュートサービス処理部２３に送信するため、ＡＰＩゲートウェイ部２２に渡す（Ｓ７５）。コンピュートサービス関数部２４は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ７６）。コンピュートサービス関数部２４は、データ管理部の一例である。
【0059】
ＡＰＩゲートウェイ部２２は、コンピュートサービス処理部２３に対して、ソフトウェア更新データを含んだソフトウェア更新応答のＨＴＴＰＳレスポンスを送信する（Ｓ７７）。コンピュートサービス処理部２３は、データベース部２５を参照して、対象車両のソフトウェアパッケージの構造を特定する（Ｓ７８）。そして、ソフトウェア更新データを、特定したソフトウェアパッケージの構造に合致するように加工し、ソフトウェアパッケージを生成する（Ｓ７９）。コンピュートサービス処理部２３は、生成したソフトウェアパッケージをファイルストレージ部２６に格納する（Ｓ８０）。コンピュートサービス処理部２３は、パッケージ生成部の一例である。
【0060】
コンピュートサービス処理部２３は、ソフトウェアパッケージが格納されているファイルストレージ部２６のパス情報をコンピュートサービス処理部１５に送信するため、ＡＰＩゲートウェイ部２２に渡す（Ｓ８１）。コンピュートサービス処理部２３は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ８２）。
【0061】
ＡＰＩゲートウェイ部２２は、コンピュートサービス処理部１５を起動し、ソフトウェアパッケージのパス情報を渡す（Ｓ８３）。コンピュートサービス処理部１５は、渡されたソフトウェアパッケージのパス情報を案件情報と紐付けて、データベース部１９に登録されている検索テーブルを更新する（Ｓ８４）。コンピュートサービス処理部１５は、コンピュートサービス関数部２０を起動して、案件登録完了情報を渡す（Ｓ８５）。コンピュートサービス処理部１５は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ８６）。
【0062】
コンピュートサービス関数部２０は、渡された案件登録完了情報をＯＴＡ運用者３４に返却するため、ＡＰＩゲートウェイ部１１に渡す（Ｓ８７）。コンピュートサービス関数部２０は処理を終了し、その処理を行うために占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ８８）。ＡＰＩゲートウェイ部１１は、ＯＴＡ運用者３４に対して案件登録完了情報のＨＴＴＰＳレスポンスを送信する（Ｓ８９）。
【0063】
尚、上記の処理において、コンピュートサービス関数部２０は、必要に応じて、コンピュートサービス関数部１２が保存したＴＣＰポート番号を共有メモリから取得し、そのＴＣＰポート番号に対するＨＴＴＰＳレスポンスを配信するように、ＡＰＩゲートウェイ部１１に要求するようにしても良い。
【0064】
次に、本実施形態の効果について説明する。図１０に示すように、キューイングバッファ部１３においては、各クルマ３１より送信される車両構成情報のストリームデータを一定量蓄積してから、次段のコンピュートサービス関数部１４及びコンピュートサービス処理部１５に渡すようになっている。上記の機能をAWS Fargateによって実現することを想定すると、処理の実行頻度を低減することによって、コンピューティングリソースの消費を節約できる。
【0065】
尚、図１０では各クルマ３１より送信される車両構成情報をバッファリングする例を示したが、ＯＴＡ運用者３４がキャンペーン登録を行う際や案件情報登録を行う際も同様に、キューイングバッファ部１３は一定量蓄積してから、次段のコンピュートサービス関数部１４及びコンピュートサービス処理部１５に渡すようになっている。
【0066】
また、図１１に示すように、従来のサーバモデルでは、アプリケーションプログラム及びサーバがリソースを占有した状態で常時稼働しており、１つのサーバで複数の処理を実行する。これに対して、本実施形態のように、サーバレスアーキテクチャを採用したモデルでは、各処理の要求が発生した際に対応するアプリケーションプログラムが起動され、処理が終了するとプログラムの実行は停止され、削除される。したがって、この時点で、処理に用いていたリソースは開放されることになる。
【0067】
その結果、図１２に示すように、従来のサーバモデルでは、実際に稼働したコストに比較して、サーバを常時稼働させることに伴う固定的なコストが余分にかかっている。また、サーバを予備的に冗長化すれば、さらにコストがかかってしまう。これに対して、本実施形態のようにサーバレスアーキテクチャを採用すれば、略実際に稼働したコストのみを負担するようになるから、インフラに掛かるランニングコストを大きく低減できる。
【0068】
以上のように本実施形態によれば、ＯＴＡセンタ１は、クルマ３１に搭載される複数のＥＣＵに書込むデータを管理し、無線通信により更新データをクルマ３１に送信するための複数の機能をアプリケーションプログラムにより実行する。その際に、少なくとも一部の機能を実現するアプリケーションプログラムは、イベントの発生を契機として起動され、オンデマンド方式によりアプリケーションプログラムのコードの実行に対してリソースが動的に割り当てられ、コードの実行が完了すれば、アプリケーションプログラムに割り当てられたリソースが開放されるサーバレスアーキテクチャを採用する。
【0069】
サーバレスアーキテクチャを採用したプログラムは、クルマ３１からのアクセスが発生する毎に、リソースが動的に割り当てられてプログラムが起動され、コードの実行が完了すればリソースが開放されるようになる。したがって、常駐型のプロセスとして実行されるサーバアーキテクチャを採用する場合に比較して、インフラのコンピューティングリソースの消費を節約でき、結果としてインフラに掛かるランニングコストを低減できる。
【0070】
（第２実施形態）
以下、第１実施形態と同一部分には同一符号を付して説明を省略し、異なる部分について説明する。クルマ３１とＯＴＡセンタ１との間の通信を、コネクション型の通信であるＴＣＰ（Transmission Control Protocol）によって行うことを想定すると、送受信間においてコネクション管理を行う必要がある。
以下、第１実施形態と同一部分には同一符号を付して説明を省略し、異なる部分について説明する。クルマ３１とＯＴＡセンタ１との間の通信を、コネクション型の通信であるＴＣＰ（Transmission Control Protocol）によって行うことを想定すると、送受信間においてコネクション管理を行う必要がある。
【0071】
先ず、コネクションを確立する際には、
・送信側から確立要求としてＳＹＮ（コネクションの確立要求）フラグが有効化されたＴＣＰパケットを送信する。
・受信側はこれに対するＡＣＫ（Acknowledge）と、同時に受信側からの接続確立要求としてＴＣＰヘッダのＳＹＮフラグを有効化して送信する。
・送信側が受信側からのＳＹＮに対するＡＣＫパケットを送信する。
といったハンドシェイク処理が必要となる。
・送信側から確立要求としてＳＹＮ（コネクションの確立要求）フラグが有効化されたＴＣＰパケットを送信する。
・受信側はこれに対するＡＣＫ（Acknowledge）と、同時に受信側からの接続確立要求としてＴＣＰヘッダのＳＹＮフラグを有効化して送信する。
・送信側が受信側からのＳＹＮに対するＡＣＫパケットを送信する。
といったハンドシェイク処理が必要となる。
【0072】
そして、コネクションを切断する際には、
・送信側は最初にＦＩＮ（コネクション終了要求）を送信する。
・受信側はＡＣＫを送信し、続けてＦＩＮを送信する。
・送信側はＦＩＮを受信して最後のＡＣＫを送った後、一定時間待ってコネクションを終了する。
といったハンドシェイク処理が必要となる。
・送信側は最初にＦＩＮ（コネクション終了要求）を送信する。
・受信側はＡＣＫを送信し、続けてＦＩＮを送信する。
・送信側はＦＩＮを受信して最後のＡＣＫを送った後、一定時間待ってコネクションを終了する。
といったハンドシェイク処理が必要となる。
【0073】
第１実施形態の構成において、上述したコネクション管理を行うことを考慮すると、図１に示すコンピュートサービス関数部１２及び２０を常に連動させる必要がある。また、コンピュートサービス関数部１２及び２０は、それぞれの後段の処理が完了して応答が返ってくるまでプロセスを稼働させておく必要があるため、サーバレスアーキテクチャを採用することによるメリットを最大限に享受できない。
【0074】
そこで、図１３に示すように、第２実施形態のＯＴＡセンタ１Ａでは、配信システム２Ａにおいて、コンピュートサービス関数部１２Ａとコンピュートサービス処理部１５Ａとの間に、データベース部４１を配置する。データベース部４１には、コンピュートサービス関数部２０Ａもアクセス可能である。以上において、コンピュートサービス関数部１２Ａ、２０Ａ及びデータベース部４１は、ステータス管理部の一例である。
【0075】
図１４は、図１３に示す構成を、ＡＷＳクラウドを利用して構成した場合の一例である。コンピュートサービス関数部１２Ａに相当するAWS Lambdaとコンピュートサービス処理部１５Ａに相当するAWS Fargateとの間に、データベース部１６Ａ及び４１に相当するAmazon Auroraを配置し、Amazon AuroraにおいてジョブＩＤを管理する。
【0076】
次に、第２実施形態の作用について説明する。
＜車両構成情報の受信→ジョブＩＤの送信とキャンペーン情報の送信＞
図１５に示すように、先ず、ステップＳ１及びＳ２を実行するが、ステップＳ１におけるリクエストは「情報リクエスト１」となる。このリクエストは、１台のクルマ３１からは例えば２週間毎又は月１回程度の発信があることを想定している。１台のクルマ３１から月１回の頻度で情報リクエスト１があると仮定すると、１０００万台のクルマ３１からは、１秒当たり８リクエスト程度の発信となる。
＜車両構成情報の受信→ジョブＩＤの送信とキャンペーン情報の送信＞
図１５に示すように、先ず、ステップＳ１及びＳ２を実行するが、ステップＳ１におけるリクエストは「情報リクエスト１」となる。このリクエストは、１台のクルマ３１からは例えば２週間毎又は月１回程度の発信があることを想定している。１台のクルマ３１から月１回の頻度で情報リクエスト１があると仮定すると、１０００万台のクルマ３１からは、１秒当たり８リクエスト程度の発信となる。
【0077】
続いて、コンピュートサービス関数部１２Ａは新たなジョブＩＤを発行し、そのジョブＩＤが処理中；Processingであることをデータベース部４１に登録する（Ｓ９１）。尚、ジョブＩＤは情報リクエスト１ごとに発行される。そして、そのジョブＩＤをＯＴＡセンタ１Ａの外部であるクルマ３１に返送するため、ジョブＩＤ情報をＡＰＩゲートウェイ部１１Ａに渡す。ジョブＩＤ情報は、例えば「ジョブＩＤ Ｎｏ．＝１」等である（Ｓ９２）。すると、ＡＰＩゲートウェイ部１１Ａはクルマ３１に、ジョブＩＤ情報の情報リクエストに対するＨＴＴＰＳレスポンスを送信する（Ｓ９３）。
【0078】
コンピュートサービス関数部１２Ａは、クルマ３１より受信した車両構成情報とジョブＩＤ情報をキューイングバッファ部１３Ａに渡す（Ｓ９４）。キューイングバッファ部１３Ａは、渡された車両構成情報とジョブＩＤ情報を一定期間、例えば数秒間蓄積し、バッファリングする（Ｓ９５）。
【0079】
ステップＳ５及びＳ５Ａを実行すると、キューイングバッファ部１３Ａは、コンピュートサービス関数部１４Ａを起動し、一定期間内に蓄積された車両構成情報及びジョブＩＤ情報をコンピュートサービス関数部１４Ａに渡す（Ｓ９６）。コンピュートサービス関数部１４Ａは、渡された車両構成情報及びジョブＩＤ情報の内容の一部を解釈し、適切な処理を実行できるコンピュートサービス処理部１５Ａのコンテナアプリを起動すると、車両構成情報及びジョブＩＤ情報をコンピュートサービス処理部１５Ａに渡す（Ｓ９７）。
【0080】
コンピュートサービス処理部１５Ａは、データベース部１９Ａにアクセスし、渡された車両構成情報及びジョブＩＤ情報に対応したキャンペーン情報が存在するか否かを判断する（Ｓ９８）。ここから、キャンペーン情報の有無に応じてステップＳ９、Ｓ１２を実行する。続くステップＳ９９において、コンピュートサービス処理部１５Ａは、上記のジョブＩＤの処理が終了；Finishedしたこと、及び生成されたキャンペーン情報をデータベース部４１に登録する。それから、ステップＳ１１を実行すると、処理を終了する。
【0081】
＜キャンペーン情報リクエストの受信→キャンペーン情報の生成状況チェックと
キャンペーン情報の送信＞
図１６に示すように、ＡＰＩゲートウェイ部１１Ａは、クルマ３１からキャンペーン情報のＨＴＴＰＳリクエスト；情報リクエスト２を受信すると（Ｓ１０１）、コンピュートサービス関数部２０Ａを起動して、受信したキャンペーン情報リクエストを渡す（Ｓ１０２）。そのリクエストには、ジョブＩＤ番号が含まれている。コンピュートサービス関数部２０Ａは、データベース部４１をチェックし、上記のジョブＩＤ番号の生成タスクのステータスが完了しているか否かを確認する（Ｓ１０３）。
キャンペーン情報の送信＞
図１６に示すように、ＡＰＩゲートウェイ部１１Ａは、クルマ３１からキャンペーン情報のＨＴＴＰＳリクエスト；情報リクエスト２を受信すると（Ｓ１０１）、コンピュートサービス関数部２０Ａを起動して、受信したキャンペーン情報リクエストを渡す（Ｓ１０２）。そのリクエストには、ジョブＩＤ番号が含まれている。コンピュートサービス関数部２０Ａは、データベース部４１をチェックし、上記のジョブＩＤ番号の生成タスクのステータスが完了しているか否かを確認する（Ｓ１０３）。
【0082】
キャンペーン生成のタスクが完了済みであれば、コンピュートサービス関数部２０Ａは、生成されたキャンペーン情報をデータベース部４１から取得して（Ｓ１０４）、ＡＰＩゲートウェイ部１１に渡す（Ｓ１０５）。ここで、コンピュートサービス関数部２０Ａは処理を終了し、占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ１０６）。ＡＰＩゲートウェイ部１１は、クルマ３１にキャンペーン情報リクエストのＨＴＴＰＳレスポンスを送信する（Ｓ１０７）。
【0083】
一方、キャンペーン生成のタスクが未完了であれば、コンピュートサービス関数部２０Ａは、キャンペーン情報の生成が未完であることを示すキャンペーン情報をＡＰＩゲートウェイ部１１Ａに渡してから（Ｓ１０８）、ステップＳ１０６に移行する。
【0084】
＜キャンペーン情報の登録（情報リクエスト１）→
ＣＤＮ配信部２１への配信パッケージの登録＞
図１７に示すように、ステップＳ２１及びＳ２２を実行すると（情報リクエスト１）、コンピュートサービス関数部１２Ａは、新たなジョブＩＤを発行し、そのジョブＩＤが処理中であることをデータベース部４１に登録する（Ｓ１１１）。続いて、ジョブＩＤ番号をＯＴＡ運用者３４に返却するため、ジョブＩＤ情報をＡＰＩゲートウェイ部１１Ａに渡す（Ｓ１１２）。
ＣＤＮ配信部２１への配信パッケージの登録＞
図１７に示すように、ステップＳ２１及びＳ２２を実行すると（情報リクエスト１）、コンピュートサービス関数部１２Ａは、新たなジョブＩＤを発行し、そのジョブＩＤが処理中であることをデータベース部４１に登録する（Ｓ１１１）。続いて、ジョブＩＤ番号をＯＴＡ運用者３４に返却するため、ジョブＩＤ情報をＡＰＩゲートウェイ部１１Ａに渡す（Ｓ１１２）。
【0085】
ＡＰＩゲートウェイ部１１Ａは、ＯＴＡ運用者３４に対し、キャンペーン情報リクエストのＨＴＴＰＳレスポンスを送信する（Ｓ１１３）。コンピュートサービス関数部１２Ａは、渡されたキャンペーン情報及びジョブＩＤ情報をキューイングバッファ部１３Ａに渡す（Ｓ１１４）。キューイングバッファ部１３Ａは、渡されたキャンペーン情報及びジョブＩＤ情報を一定期間蓄積し、バッファリングする（Ｓ１１５）。それから、ステップＳ２５及びＳ２５Ａを実行する。
【0086】
キューイングバッファ部１３Ａは、コンピュートサービス関数部１４Ａを起動し、一定期間内に蓄積されたキャンペーン情報及びジョブＩＤ情報をコンピュートサービス関数部１４Ａに渡す（Ｓ１１６）。コンピュートサービス関数部１４Ａは、渡されたキャンペーン情報及びジョブＩＤ情報の内容の一部を解釈し、適切な処理を実行できるコンピュートサービス処理部１５Ａのコンテナアプリを起動すると、キャンペーン情報をコンピュートサービス処理部１５Ａに渡す（Ｓ１１７）。
【0087】
コンピュートサービス処理部１５Ａは、渡されたキャンペーン情報及びジョブＩＤ情報の中に含まれている対象車両と、更新対象のソフトウェアパッケージとの紐付けを行うため、データベース部１９Ａにキャンペーン情報を登録する（Ｓ１１８）。次に、コンピュートサービス処理部１５Ａは、ステップＳ３１、Ｓ１１９、Ｓ３２及びＳ３３を実行する。ステップＳ１１９において、コンピュートサービス処理部１５Ａは、上記のジョブＩＤの処理が終了したことをデータベース部４１に登録する。
【0088】
＜キャンペーン情報の登録（情報リクエスト２）→
ＣＤＮ配信部２１への配信パッケージの登録＞
図１８に示すように、ＡＰＩゲートウェイ部１１Ａは、ＯＴＡ運用者３４からキャンペーン情報登録のＨＴＴＰＳリクエストを受信すると（Ｓ１２１）、コンピュートサービス関数部２０Ａを起動して、受信した登録リクエスト；情報リクエスト２を渡す（Ｓ１２２）。コンピュートサービス関数部２０Ａは、データベース部４１をチェックし、上記のジョブＩＤ番号の登録タスクのステータスが完了しているか否かを確認する（Ｓ１２３）。
ＣＤＮ配信部２１への配信パッケージの登録＞
図１８に示すように、ＡＰＩゲートウェイ部１１Ａは、ＯＴＡ運用者３４からキャンペーン情報登録のＨＴＴＰＳリクエストを受信すると（Ｓ１２１）、コンピュートサービス関数部２０Ａを起動して、受信した登録リクエスト；情報リクエスト２を渡す（Ｓ１２２）。コンピュートサービス関数部２０Ａは、データベース部４１をチェックし、上記のジョブＩＤ番号の登録タスクのステータスが完了しているか否かを確認する（Ｓ１２３）。
【0089】
キャンペーン登録のタスクが完了済みであれば、コンピュートサービス関数部２０Ａは、登録完了を示す情報をＡＰＩゲートウェイ部１１Ａに渡す（Ｓ１２４）。ここで、コンピュートサービス関数部２０Ａは処理を終了し、占有していたＣＰＵやメモリ等のリソースを開放する（Ｓ１２５）。ＡＰＩゲートウェイ部１１Ａは、 ＯＴＡ運用者３４にキャンペーン情報登録リクエストのＨＴＴＰＳレスポンスを送信する（Ｓ１２６）。
【0090】
一方、キャンペーン登録のタスクが未完了であれば、コンピュートサービス関数部２０Ａは、キャンペーン情報の登録が未完了であることを示すキャンペーン情報をＡＰＩゲートウェイ部１１Ａに渡してから（Ｓ１２７）、ステップＳ１２５に移行する。
【0091】
＜案件情報（情報リクエスト１）→パッケージの生成＞
図１９に示すように、ステップＳ６１及びＳ６２を実行すると（情報リクエスト１）、コンピュートサービス関数部１２は新たなジョブＩＤを発行し、そのジョブＩＤが処理中であることをデータベース部４１に登録する（Ｓ１３１）。そして、そのジョブＩＤをＯＴＡ運用者３４に返送するため、ジョブＩＤ情報をＡＰＩゲートウェイ部１１に渡す（Ｓ１３２）。すると、ＡＰＩゲートウェイ部１１はＯＴＡ運用者３４に、案件情報の情報リクエストに対するＨＴＴＰＳレスポンスを送信する（Ｓ１３３）。
図１９に示すように、ステップＳ６１及びＳ６２を実行すると（情報リクエスト１）、コンピュートサービス関数部１２は新たなジョブＩＤを発行し、そのジョブＩＤが処理中であることをデータベース部４１に登録する（Ｓ１３１）。そして、そのジョブＩＤをＯＴＡ運用者３４に返送するため、ジョブＩＤ情報をＡＰＩゲートウェイ部１１に渡す（Ｓ１３２）。すると、ＡＰＩゲートウェイ部１１はＯＴＡ運用者３４に、案件情報の情報リクエストに対するＨＴＴＰＳレスポンスを送信する（Ｓ１３３）。
【0092】
コンピュートサービス関数部１２Ａは、渡された案件情報とジョブＩＤ情報をキューイングバッファ部１３Ａに渡す（Ｓ１３４）。キューイングバッファ部１３Ａは、渡された案件情報とジョブＩＤ情報を一定期間、例えば数秒間蓄積し、バッファリングする（Ｓ１３５）。
【0093】
ステップＳ６５及びＳ６５Ａを実行すると、キューイングバッファ部１３Ａは、コンピュートサービス関数部１４Ａを起動し、一定期間内に蓄積された案件情報及びジョブＩＤ情報をコンピュートサービス関数部１４Ａに渡す（Ｓ１３６）。コンピュートサービス関数部１４Ａは、渡された案件情報及びジョブＩＤ情報の内容の一部を解釈し、適切な処理を実行できるコンピュートサービス処理部１５Ａのコンテナアプリを起動すると、案件情報及びジョブＩＤ情報をコンピュートサービス処理部１５Ａに渡す（Ｓ１３７）。
【0094】
コンピュートサービス処理部１５Ａは、渡された案件情報に含まれているソフトウェア更新情報を元に、ソフトウェアパッケージを生成するため、コンピュートサービス処理部２３のコンテナアプリを起動し、コンピュートサービス処理部２３にソフトウェア更新対象情報を渡す（Ｓ１３８）。
【0095】
以降はステップＳ７０～Ｓ８６を実行するが、ステップＳ８５に替えてステップＳ１３９を実行する。ステップＳ１３９において、コンピュートサービス処理部１５Ａは、ジョブＩＤの処理が終了したことをデータベース部４１に登録する。
【0096】
＜案件情報（情報リクエスト２）→パッケージの生成＞
図２０に示すように、ＡＰＩゲートウェイ部１１Ａは、ＯＴＡ運用者３４から案件情報登録のＨＴＴＰＳリクエスト；情報リクエスト２を受信すると（Ｓ１４１）、コンピュートサービス関数部２０Ａを起動し、受信した案件情報登録のリクエストを渡す（Ｓ１４２）。コンピュートサービス関数部２０Ａは、データベース部４１をチェックし、上記のリクエストに付されているジョブＩＤ番号のタスクのステータスが完了しているか確認する（Ｓ１４３）。
図２０に示すように、ＡＰＩゲートウェイ部１１Ａは、ＯＴＡ運用者３４から案件情報登録のＨＴＴＰＳリクエスト；情報リクエスト２を受信すると（Ｓ１４１）、コンピュートサービス関数部２０Ａを起動し、受信した案件情報登録のリクエストを渡す（Ｓ１４２）。コンピュートサービス関数部２０Ａは、データベース部４１をチェックし、上記のリクエストに付されているジョブＩＤ番号のタスクのステータスが完了しているか確認する（Ｓ１４３）。
【0097】
案件情報登録のタスクが完了済みであれば、コンピュートサービス関数部２０Ａは、案件情報登録完了の情報をＡＰＩゲートウェイ部１１Ａに渡すと（Ｓ１４４）、処理を終了して占有していたリソースを開放する（Ｓ１４５）。それから、ＡＰＩゲートウェイ部１１Ａは、ＯＴＡ運用者３４に対して案件情報登録リクエストのＨＴＴＰＳレスポンスを送信する（Ｓ１４６）。一方、案件情報登録のタスクが未完了であれば、コンピュートサービス関数部２０Ａは、ＯＴＡ運用者３４に送信する案件情報登録未完了の情報をＡＰＩゲートウェイ部１１に渡してから（Ｓ１４７）ステップＳ１４５に移行する。
【0098】
以上のように第２実施形態によれば、コンピュートサービス関数部１２Ａ、２０Ａ及びデータベース部４１により、クルマ３１から受信したリクエストにジョブＩＤ情報を付与すると共に、そのリクエストに対応した処理が、処理中であるか完了したかを示すステータスを管理して、処理が完了したリクエストに対してクルマ３１にレスポンスを返すようにした。これにより、コンピュートサービス関数部１２Ａ及び２０Ａは、リクエストに対応する処理が完了するまでの間に継続して起動させる必要がなくなるので、サーバレスアーキテクチャを採用したことによるメリットをより多く享受できるようになる。
【0099】
（第３実施形態）
第２実施形態の構成では、クルマ３１とＯＴＡセンタ１ＡのＡＰＩゲートウェイ部１１との間における通信トラフィックが増大するため、通信料の負担増加が懸念される。また、この構成では、クルマ３１側又はＯＴＡセンタ１Ａ側に設計ミス等があると、クルマ３１からの通信リトライが無限ループで発生し、ＯＴＡセンタ１Ａが過負荷状態に陥るおそれがある。
第２実施形態の構成では、クルマ３１とＯＴＡセンタ１ＡのＡＰＩゲートウェイ部１１との間における通信トラフィックが増大するため、通信料の負担増加が懸念される。また、この構成では、クルマ３１側又はＯＴＡセンタ１Ａ側に設計ミス等があると、クルマ３１からの通信リトライが無限ループで発生し、ＯＴＡセンタ１Ａが過負荷状態に陥るおそれがある。
【0100】
そこで、図２１に示すように、第３実施形態のＯＴＡセンタ１Ｂでは、第２実施形態の構成にコンピュートサービス関数部４２及び４３を追加している。コンピュートサービス関数部４３は、コンピュートサービス関数部４２及びデータベース部４１Ｂにアクセスし、コンピュートサービス関数部４２は、ＡＰＩゲートウェイ部１１Ｂにアクセスする。データベース部４１Ｂにおいて、ジョブＩＤ番号、ステータスと共にコネクションＩＤ番号を管理する。コンピュートサービス関数部２０Ｂは、配信先管理部の一例である。
【0101】
図２２は、図２１に示す構成を、ＡＷＳサービスを用いて構成した一例である。
・Amazon API Gateway：ＡＰＩゲートウェイ部１１Ｂに相当する。
・AWS Lambda ：コンピュートサービス関数部１２Ｂ、２０Ｂ、４２に相当する。
・AWS Fargate ：コンピュートサービス処理部１４Ｂ，１５Ｂに相当する。
・Amazon Aurora ：データベース部１９Ｂ、２５及び２７に相当する。
・CloudWatch ：コンピュートサービス関数部４３に相当する。
・Amazon API Gateway：ＡＰＩゲートウェイ部１１Ｂに相当する。
・AWS Lambda ：コンピュートサービス関数部１２Ｂ、２０Ｂ、４２に相当する。
・AWS Fargate ：コンピュートサービス処理部１４Ｂ，１５Ｂに相当する。
・Amazon Aurora ：データベース部１９Ｂ、２５及び２７に相当する。
・CloudWatch ：コンピュートサービス関数部４３に相当する。
【0102】
次に、第３実施形態の作用について説明する。
＜車両構成情報の受信→ジョブＩＤの送信とキャンペーン情報の送信＞
図２３に示すように、ステップＳ１及びＳ２を実行すると、コンピュートサービス関数部１２Ｂは新たなジョブＩＤを発行し、そのジョブＩＤが処理中であること、及びコネクションＩＤ番号をデータベース部４１Ｂに登録する（Ｓ１５１）。以降は、第２実施形態と同様に、ステップＳ９２～Ｓ１１を実行する。コネクションＩＤ番号は、所謂ＴＣＰポート番号である。尚、ＡＰＩゲートウェイ部１１Ｂは、ジョブＩＤは記憶していないが、クルマ３１との通信を行なった際のＴＣＰポート番号であるコネクションＩＤ番号は記憶している。
＜車両構成情報の受信→ジョブＩＤの送信とキャンペーン情報の送信＞
図２３に示すように、ステップＳ１及びＳ２を実行すると、コンピュートサービス関数部１２Ｂは新たなジョブＩＤを発行し、そのジョブＩＤが処理中であること、及びコネクションＩＤ番号をデータベース部４１Ｂに登録する（Ｓ１５１）。以降は、第２実施形態と同様に、ステップＳ９２～Ｓ１１を実行する。コネクションＩＤ番号は、所謂ＴＣＰポート番号である。尚、ＡＰＩゲートウェイ部１１Ｂは、ジョブＩＤは記憶していないが、クルマ３１との通信を行なった際のＴＣＰポート番号であるコネクションＩＤ番号は記憶している。
【0103】
＜キャンペーン情報リクエストの受信→キャンペーン情報の生成状況チェックと
キャンペーン情報の送信＞
図２４に示すように、ＡＰＩゲートウェイ部１１Ｂは、ステップＳ１０１を実行すると、コンピュートサービス関数部２０Ｂを起動して、受信したキャンペーン情報リクエストを渡す（Ｓ１５２）。そのリクエストには、ジョブＩＤ番号と共にコネクションＩＤ情報が含まれている。コンピュートサービス関数部２０Ｂは、データベース部４１ＢをジョブＩＤ番号で検索し、該当したジョブＩＤ番号のテーブルにコネクション情報を登録する（Ｓ１５３）。それから、ステップＳ１０６を実行する。
キャンペーン情報の送信＞
図２４に示すように、ＡＰＩゲートウェイ部１１Ｂは、ステップＳ１０１を実行すると、コンピュートサービス関数部２０Ｂを起動して、受信したキャンペーン情報リクエストを渡す（Ｓ１５２）。そのリクエストには、ジョブＩＤ番号と共にコネクションＩＤ情報が含まれている。コンピュートサービス関数部２０Ｂは、データベース部４１ＢをジョブＩＤ番号で検索し、該当したジョブＩＤ番号のテーブルにコネクション情報を登録する（Ｓ１５３）。それから、ステップＳ１０６を実行する。
【0104】
ステップＳ１５４～Ｓ１６０の処理は、周期的に、例えば数秒間毎に起動される。コンピュートサービス関数部４３は、ある周期で定期的にデータベース部４１Ｂをチェックし、新たにタスク完了したジョブＩＤ番号がないかを確認する（Ｓ１５４）。タスク完了したジョブＩＤ番号があれば、コンピュートサービス関数部４３は、そのジョブＩＤ番号のコネクションＩＤ情報とキャンペーン情報とをデータベース部４１Ｂから取得する（Ｓ１５５）。そして、取得したコネクションＩＤ情報及びキャンペーン情報をコンピュートサービス関数部４２に渡すと（Ｓ１５６）、コンピュートサービス関数部４３は、処理を終了し、占有していたリソースを開放する（Ｓ１５７）。
【0105】
続いて、コンピュートサービス関数部４２は、コネクションＩＤ情報及びキャンペーン情報をＡＰＩゲートウェイ部１１Ｂに渡す（Ｓ１５９）。ＡＰＩゲートウェイ部１１Ｂは、コネクションＩＤ情報を元に、情報を返却すべきクルマ３１を特定し、クルマ３１にキャンペーン情報リクエストに対するＨＴＴＰＳレスポンスを送信する（Ｓ１６０）。一方、ステップＳ１５４において、タスク完了したジョブＩＤ番号がなければ、ステップＳ１５７と同様の処理を行なってから（Ｓ１５８）処理を終了する。
【0106】
＜キャンペーン情報（情報リクエスト２）の登録→
ＣＤＮ配信部２１への配信パッケージの登録＞
情報リクエスト１については、第２実施形態と同様にステップＳ２１～Ｓ３３を実行する。尚、ステップＳ９１では、コンピュートサービス関数部１２Ａは新たなジョブＩＤを発行し、そのジョブＩＤが処理中；Processingであること、及びコネクションＩＤ番号をデータベース部４１に登録する。それから、図２５に示すように、ＡＰＩゲートウェイ部１１ＢはステップＳ１２１を実行すると、ステップＳ１５２，Ｓ１５３と同様の処理を実行した後（Ｓ１６１、Ｓ１６２）、ステップＳ１２５を実行する。ステップＳ１６３～Ｓ１６９の処理は、ステップＳ１５４～Ｓ１６０の処理と同様であるが、ステップＳ１６９におけるレスポンスの送信先は、ＯＴＡ運用者３４である。
ＣＤＮ配信部２１への配信パッケージの登録＞
情報リクエスト１については、第２実施形態と同様にステップＳ２１～Ｓ３３を実行する。尚、ステップＳ９１では、コンピュートサービス関数部１２Ａは新たなジョブＩＤを発行し、そのジョブＩＤが処理中；Processingであること、及びコネクションＩＤ番号をデータベース部４１に登録する。それから、図２５に示すように、ＡＰＩゲートウェイ部１１ＢはステップＳ１２１を実行すると、ステップＳ１５２，Ｓ１５３と同様の処理を実行した後（Ｓ１６１、Ｓ１６２）、ステップＳ１２５を実行する。ステップＳ１６３～Ｓ１６９の処理は、ステップＳ１５４～Ｓ１６０の処理と同様であるが、ステップＳ１６９におけるレスポンスの送信先は、ＯＴＡ運用者３４である。
【0107】
＜クルマからのデータアクセス→ＣＤＮから配信パッケージをクルマに送信＞
＜ソフトウェア更新データの登録＞
これらの処理は、第１実施形態と同様である。
＜案件情報の登録とパッケージの生成＞
この処理は、第２実施形態と同様である。
＜ソフトウェア更新データの登録＞
これらの処理は、第１実施形態と同様である。
＜案件情報の登録とパッケージの生成＞
この処理は、第２実施形態と同様である。
【0108】
＜案件情報の登録リクエストの受信→案件情報の登録状況チェックと
案件登録情報（結果）の送信＞
図２６に示すように、ステップＳ１７１、Ｓ１７２の処理はステップＳ１４１、Ｓ１４２と同様であるが、コンピュートサービス関数部２０Ｂに渡す情報には、コネクションＩＤ情報が含まれている。ステップＳ１７３～Ｓ１８１の処理は、図２４に示すステップＳ１５３～Ｓ１６０の処理を、キャンペーン情報に替えて案件情報について行うものである。
案件登録情報（結果）の送信＞
図２６に示すように、ステップＳ１７１、Ｓ１７２の処理はステップＳ１４１、Ｓ１４２と同様であるが、コンピュートサービス関数部２０Ｂに渡す情報には、コネクションＩＤ情報が含まれている。ステップＳ１７３～Ｓ１８１の処理は、図２４に示すステップＳ１５３～Ｓ１６０の処理を、キャンペーン情報に替えて案件情報について行うものである。
【0109】
以上のように第３実施形態によれば、コンピュートサービス関数部２０Ｂは、クルマ３１又はＯＴＡ運用者３４よりジョブ番号が付与されたリクエストを受信すると、そのジョブ番号に紐付けされたコネクション番号を付与してデータベース部４１Ｂに登録し、コンピュートサービス関数部４２、４３は、データベース部４１を参照することで処理が完了したリクエストがあれば、そのリクエストのジョブ番号に対応したコネクション番号に基づいてレスポンスの送信先となるクルマ３１又はＯＴＡ運用者３４を特定し、特定されたクルマ３１又はＯＴＡ運用者３４にＡＰＩゲートウェイ部１１Ｂを介してレスポンスを送信するようにした。これにより、クルマ３１又はＯＴＡ運用者３４がＡＰＩゲートウェイ部１１Ｂに当該ジョブ番号の処理が完了しているかを確認するため、繰り返しリクエストを送信するといったプロセスが不要となり、第２実施形態で発生していた通信を減らせるため、クルマ３１又はＯＴＡ運用者３４とＡＰＩゲートウェイ部１１Ｂとの間の通信トラフィック量を削減できる。
【0110】
（第４実施形態）
ここで、第３実施形態の構成について、キューイングバッファ部１３Ｂの後段に配置されるコンピュートサービス処理部１５Ｂに相当するAWS Fagateの処理負荷を、オートスケーリングにより調整することを想定する。この場合、通常はＥＣＳ（Elastic Container Service）のターゲット追跡スケーリングポリシーなどを利用して、ＥＣＳにおけるCloudWatchメトリクスとアラームとを利用してタスク数等を制御することになる。
ここで、第３実施形態の構成について、キューイングバッファ部１３Ｂの後段に配置されるコンピュートサービス処理部１５Ｂに相当するAWS Fagateの処理負荷を、オートスケーリングにより調整することを想定する。この場合、通常はＥＣＳ（Elastic Container Service）のターゲット追跡スケーリングポリシーなどを利用して、ＥＣＳにおけるCloudWatchメトリクスとアラームとを利用してタスク数等を制御することになる。
【0111】
すると、CloudWatchメトリクスからアラーム発報までにどうしてもタイムラグが存在するため、数秒単位でのスケーリングが難しく、基本的には分単位オーダーでのスケーリングとなってしまう。そのため、AWS Fargateを単に適用するだけのサーバーレス化では、図２７に示すように、クルマ３１からの通信トラフィックが突発的に急増した際に対応できない、という問題がある。
【0112】
そこで、図２８に示す第４実施形態のＯＴＡセンタ１Ｃでは、配信システム２Ｃにおいて、第３実施形態の構成にコンピュートサービス関数部４４を加えている。コンピュートサービス関数部１４Ｃはコンピュートサービス関数部４４にアクセスし、コンピュートサービス関数部４４はコンピュートサービス処理部１５Ｃにアクセスする。
【0113】
コンピュートサービス関数部４４は、スケールアウトを能動的に実行する。コンピュートサービス処理部１５Ｃに相当するAWS Fargateを高速にオートスケーリングさせるため、例えばStep Functionsを利用して、３秒毎に、データプレーンであるFargateタスクへのコネクション数を取得し、その結果に応じて、コントロールプレーンであるＥＣＳのタスク数の上限を引き上げる。これにより、コンピュートサービス処理部１５Ｃの処理能力を調整する。コンピュートサービス関数部４４は、処理能力調整部の一例である。
【0114】
図２９は、図２８に示すセンタ装置１Ｃを、ＡＷＳクラウドを利用して構成した場合の一例である。
・Amazon API Gateway：ＡＰＩゲートウェイ部１１Ｃに相当する。
・AWS Lambda ：コンピュートサービス関数部１２Ｃ、２０Ｃ、４２Ｃ、
４４に相当する。
・SQS ：キューイングバッファ部１３Ｃに相当する。
・AWS Step Functions：コンピュートサービス関数部１４Ｃに相当する。
・Amazon Aurora ：データベース部１６Ｃ、４１Ｃに相当する。
・CloudWatch ：コンピュートサービス関数部４３Ｃに相当する。
・Amazon API Gateway：ＡＰＩゲートウェイ部１１Ｃに相当する。
・AWS Lambda ：コンピュートサービス関数部１２Ｃ、２０Ｃ、４２Ｃ、
４４に相当する。
・SQS ：キューイングバッファ部１３Ｃに相当する。
・AWS Step Functions：コンピュートサービス関数部１４Ｃに相当する。
・Amazon Aurora ：データベース部１６Ｃ、４１Ｃに相当する。
・CloudWatch ：コンピュートサービス関数部４３Ｃに相当する。
【0115】
次に、第４実施形態の作用について説明する。
＜車両構成情報の受信→ＪＯＢ＿ＩＤの送信とキャンペーン情報の生成＞
図１５に示す第２実施形態と同様に、ステップＳ１～Ｓ５Ａを実行する。続いて、図３０に示すように、ステップＳ９６と同様の処理を実行すると（Ｓ１９１）、コンピュートサービス関数部１４Ｃは、コンピュートサービス関数部４４を起動する（Ｓ１９２）。コンピュートサービス関数部４４は、下記の（１）～（３）をチェックする（Ｓ１９２）。
・ コンピュートサービス処理部１５Ｃにおけるコンテナアプリの起動数
・ 各コンテナアプリの処理負荷率
・ キューイングバッファ部１３Ｃに滞留しているジョブＩＤの数
＜車両構成情報の受信→ＪＯＢ＿ＩＤの送信とキャンペーン情報の生成＞
図１５に示す第２実施形態と同様に、ステップＳ１～Ｓ５Ａを実行する。続いて、図３０に示すように、ステップＳ９６と同様の処理を実行すると（Ｓ１９１）、コンピュートサービス関数部１４Ｃは、コンピュートサービス関数部４４を起動する（Ｓ１９２）。コンピュートサービス関数部４４は、下記の（１）～（３）をチェックする（Ｓ１９２）。
・ コンピュートサービス処理部１５Ｃにおけるコンテナアプリの起動数
・ 各コンテナアプリの処理負荷率
・ キューイングバッファ部１３Ｃに滞留しているジョブＩＤの数
【0116】
続いて、コンピュートサービス関数部４４は、以下の条件の何れかを満足しているかをチェックする（Ｓ１９４）。
・上記（１）の起動数が既定の閾値を超えている
・上記（２）の負荷率が既定の閾値を超えている
・上記（３）のジョブＩＤ数が既定の閾値を超えている
・上記（１）の起動数が既定の閾値を超えている
・上記（２）の負荷率が既定の閾値を超えている
・上記（３）のジョブＩＤ数が既定の閾値を超えている
【0117】
何れかの条件で閾値を超えていれば、コンピュートサービス関数部４４は、コンピュートサービス処理部１５Ｃのコンテナアプリをスケールアウトさせるため、コンテナアプリを強制的に追加して起動する（Ｓ１９５）。
【0118】
次に、コンピュートサービス関数部１４Ｃは、コンピュートサービス処理部１５Ｃの起動させたコンテナアプリに車両構成情報とジョブＩＤとを渡す（Ｓ１９６）。それから、コンピュートサービス関数部１４Ｃ及び４４は、処理を終了して占有していたリソースを開放する（Ｓ１９７）。一方、ステップＳ１９４において、何れの条件でも閾値を超えていなければ、コンピュートサービス関数部１４Ｃは、コンピュートサービス処理部１５Ｃの既に起動済みであるコンテナアプリに車両構成情報とジョブＩＤとを渡してから（Ｓ１９８）ステップＳ１９７に移行する。以降は、図１５に示すステップＳ９８～Ｓ１１を実行する。
【0119】
以上のように第４実施形態によれば、コンピュートサービス関数部４４は、クルマ３１に対するキャンペーン通知情報を生成するコンピュートサービス処理部１５Ｃの処理負荷と、クルマ３１から受信した車両構成情報の数とを確認すると、コンピュートサービス処理部１５Ｃの処理能力の増減要否を判断し、必要に応じて処理能力を増減させる。これにより、クルマ３１又はＯＴＡ運用者３４との間の通信トラフィック量が急増した場合にも対応が可能となる。
【0120】
（第５実施形態）
第５実施形態では、開発コストの最適化を図った構成を示す。図３１に示すように、第５実施形態のＯＴＡセンタ１Ｄは、配信センタ２Ｄにおいて、第２実施形態の構成からキューイングバッファ部１３及びコンピュートサービス関数部１４を削除したものである。
第５実施形態では、開発コストの最適化を図った構成を示す。図３１に示すように、第５実施形態のＯＴＡセンタ１Ｄは、配信センタ２Ｄにおいて、第２実施形態の構成からキューイングバッファ部１３及びコンピュートサービス関数部１４を削除したものである。
【0121】
図３２は、図３１に示すセンタ装置１Ｄを、ＡＷＳクラウドを利用して構成した場合の一例である。
・Amazon API Gateway：ＡＰＩゲートウェイ部１１Ｄに相当する。
・AWS Lambda ：コンピュートサービス関数部２０Ｄ、４２Ｄに相当する。
・AWS Step Functions：コンピュートサービス関数部１２Ｄに相当する。
・Dynamo DB ：データベース部１６Ｄ、４１Ｄ及び
コンピュートサービス関数部４３Ｄに相当する。
・Amazon API Gateway：ＡＰＩゲートウェイ部１１Ｄに相当する。
・AWS Lambda ：コンピュートサービス関数部２０Ｄ、４２Ｄに相当する。
・AWS Step Functions：コンピュートサービス関数部１２Ｄに相当する。
・Dynamo DB ：データベース部１６Ｄ、４１Ｄ及び
コンピュートサービス関数部４３Ｄに相当する。
【0122】
次に、第５実施形態の作用について説明する。
＜車両構成情報の受信→ジョブＩＤの送信とキャンペーン情報の送信＞
図３３に示すように、ステップＳ１～Ｓ９３を実行すると、コンピュートサービス関数部１２Ｄは、適切な処理を実行できるコンピュートサービス処理部１５Ｄのコンテナアプリを起動して、コンピュートサービス処理部１５Ｄに車両構成情報を渡す（Ｓ２０１）。それから、ステップＳ５～Ｓ１１を実行する。
＜車両構成情報の受信→ジョブＩＤの送信とキャンペーン情報の送信＞
図３３に示すように、ステップＳ１～Ｓ９３を実行すると、コンピュートサービス関数部１２Ｄは、適切な処理を実行できるコンピュートサービス処理部１５Ｄのコンテナアプリを起動して、コンピュートサービス処理部１５Ｄに車両構成情報を渡す（Ｓ２０１）。それから、ステップＳ５～Ｓ１１を実行する。
【0123】
【0124】
＜キャンペーン情報の登録→ＣＤＮ配信部２１Ｄへの配信パッケージの登録＞
図３４に示すように、ステップＳ２１～Ｓ１１３を実行すると、コンピュートサービス関数部１２Ｄは、適切な処理を実行できるコンピュートサービス処理部１５Ｄのコンテナアプリを起動して、コンピュートサービス処理部１５Ｄに車両構成情報を渡す（Ｓ２０２）。それから、ステップＳ２５、Ｓ１１８、Ｓ３１～Ｓ３３を実行する。
図３４に示すように、ステップＳ２１～Ｓ１１３を実行すると、コンピュートサービス関数部１２Ｄは、適切な処理を実行できるコンピュートサービス処理部１５Ｄのコンテナアプリを起動して、コンピュートサービス処理部１５Ｄに車両構成情報を渡す（Ｓ２０２）。それから、ステップＳ２５、Ｓ１１８、Ｓ３１～Ｓ３３を実行する。
【0125】
＜キャンペーン情報の登録→ＣＤＮ配信部２１への配信パッケージの登録＞
これは、第２実施形態の図２５に示す処理と同様になる。
＜クルマからのデータアクセス→ＣＤＮから配信パッケージをクルマに送信＞
これは、第１実施形態の図６に示す処理と同様になる。
＜ソフトウェア更新データの登録＞
これは、第１実施形態の図７に示す処理と同様になる。
これは、第２実施形態の図２５に示す処理と同様になる。
＜クルマからのデータアクセス→ＣＤＮから配信パッケージをクルマに送信＞
これは、第１実施形態の図６に示す処理と同様になる。
＜ソフトウェア更新データの登録＞
これは、第１実施形態の図７に示す処理と同様になる。
【0126】
＜案件情報の登録→パッケージの生成＞
図３５に示すように、第２実施形態の図１９と同様にステップＳ６１～Ｓ１３３を実行すると、コンピュートサービス関数部１２Ｄは、適切な処理を実行できるコンピュートサービス処理部１５Ｄのコンテナアプリを起動して、コンピュートサービス処理部１５Ｄに車両構成情報を渡す（Ｓ２０３）。それから、ステップＳ６５、Ｓ１３８を実行すると、第２実施形態の図１９と同様に、Ｓ７０～Ｓ８６を実行する。
図３５に示すように、第２実施形態の図１９と同様にステップＳ６１～Ｓ１３３を実行すると、コンピュートサービス関数部１２Ｄは、適切な処理を実行できるコンピュートサービス処理部１５Ｄのコンテナアプリを起動して、コンピュートサービス処理部１５Ｄに車両構成情報を渡す（Ｓ２０３）。それから、ステップＳ６５、Ｓ１３８を実行すると、第２実施形態の図１９と同様に、Ｓ７０～Ｓ８６を実行する。
【0127】
【0128】
以上のように第５実施形態によればキューイングバッファ部１３及びコンピュートサービス関数部１４を削除することで、ＯＴＡセンタ１Ｄを低コストで構成できる。
【0129】
（第６実施形態）
第６実施形態では、セキュリティを強化するため、有効期限がある署名付きＵＲＬを使用する。この署名付きＵＲＬを用いると、ユーザがコンテンツへのアクセスを開始できる開始日時やアクセスできる日時又は期間を指定できると共に、コンテンツにアクセスできるユーザのＩＰアドレス又はＩＰアドレスの範囲を指定できる。上記の署名は、アクセス制御情報の一例である。
第６実施形態では、セキュリティを強化するため、有効期限がある署名付きＵＲＬを使用する。この署名付きＵＲＬを用いると、ユーザがコンテンツへのアクセスを開始できる開始日時やアクセスできる日時又は期間を指定できると共に、コンテンツにアクセスできるユーザのＩＰアドレス又はＩＰアドレスの範囲を指定できる。上記の署名は、アクセス制御情報の一例である。
【0130】
例えば、ＯＴＡセンタは秘密鍵を用いて署名付きＵＲＬを作成してクルマに返すと、クルマ側では、その署名付きＵＲＬを使用してＣＤＮからコンテンツのダウンロードやストリーミングを実行する。その際にＣＤＮは、パブリックキー；公開鍵を使用して署名を検証し、ファイルにアクセスするための資格がユーザにあることを検証する。
【0131】
図３６に示すように、第６実施形態のＯＴＡセンタ１Ｅは、配信システム２Ｅにおいて、第２実施形態の構成にコンピュートサービス関数部４５を追加したものである。コンピュートサービス関数部４５は、コンピュートサービス処理部１５Ｅにアクセスする。データベース部４１Ｅでは、有効期限と署名付きＵＲＬが管理されている。
【0132】
図３７は、図３６に示すセンタ装置１Ｅを、ＡＷＳクラウドを利用して構成した場合の一例である。
・Amazon API Gateway：ＡＰＩゲートウェイ部１１Ｅに相当する。
・AWS Lambda ：コンピュートサービス関数部１２Ｅ、１４Ｅ，２０Ｅ、
４５に相当する。
・AWS Step Functions：コンピュートサービス関数部１４Ｅに相当する。
・SQS ：キューイングバッファ部１３Ｅに相当する。
・Dynamo DB ：データベース部１６Ｅ，４１Ｅ及び
コンピュートサービス関数部４２Ｅに相当する。
・Amazon API Gateway：ＡＰＩゲートウェイ部１１Ｅに相当する。
・AWS Lambda ：コンピュートサービス関数部１２Ｅ、１４Ｅ，２０Ｅ、
４５に相当する。
・AWS Step Functions：コンピュートサービス関数部１４Ｅに相当する。
・SQS ：キューイングバッファ部１３Ｅに相当する。
・Dynamo DB ：データベース部１６Ｅ，４１Ｅ及び
コンピュートサービス関数部４２Ｅに相当する。
【0133】
次に、第６実施形態の作用について説明する。
＜車両構成情報の受信→ジョブＩＤの送信とキャンペーン情報の送信＞
先ず、第３実施形態の図２３に示す処理と同様に、ステップＳ１～Ｓ５、ステップＳ９２～Ｓ１１を実行する。続けて、図２４に示す処理と同様に、ステップＳ１０１～Ｓ１０６を実行する。それから、図３８に示すように、ステップＳ１５４を実行すると、コンピュートサービス関数部４３Ｅは、タスク完了したジョブＩＤ番号があれば、そのジョブＩＤ番号のコネクションＩＤ情報とキャンペーン情報、及び有効期限と署名付きＵＲＬをデータベース部４１Ｅから取得する（Ｓ２１１）。そして、取得した上記の各情報をコンピュートサービス関数部４２Ｅに渡すと（Ｓ２１２）、ステップＳ１５７を実行する。コンピュートサービス関数部４２Ｅは、上記の各情報をＡＰＩゲートウェイ部１１Ｅに渡すと（Ｓ２１３）、ステップＳ１６０を実行する。
＜車両構成情報の受信→ジョブＩＤの送信とキャンペーン情報の送信＞
先ず、第３実施形態の図２３に示す処理と同様に、ステップＳ１～Ｓ５、ステップＳ９２～Ｓ１１を実行する。続けて、図２４に示す処理と同様に、ステップＳ１０１～Ｓ１０６を実行する。それから、図３８に示すように、ステップＳ１５４を実行すると、コンピュートサービス関数部４３Ｅは、タスク完了したジョブＩＤ番号があれば、そのジョブＩＤ番号のコネクションＩＤ情報とキャンペーン情報、及び有効期限と署名付きＵＲＬをデータベース部４１Ｅから取得する（Ｓ２１１）。そして、取得した上記の各情報をコンピュートサービス関数部４２Ｅに渡すと（Ｓ２１２）、ステップＳ１５７を実行する。コンピュートサービス関数部４２Ｅは、上記の各情報をＡＰＩゲートウェイ部１１Ｅに渡すと（Ｓ２１３）、ステップＳ１６０を実行する。
【0134】
ステップＳ２１４～Ｓ２１７の処理は、周期的に実行される。コンピュートサービス関数部４５は、周期的にデータベース部４１Ｅをチェックし、有効期限が切れている署名付きＵＲＬがないかを確認する（Ｓ２１４）。有効期限が切れている署名付きＵＲＬがあれば、その署名付きＵＲＬに新たな有効期限を付したものを生成して（Ｓ２１５）、データベース部４１Ｅを更新する（Ｓ２１６）。それから、コンピュートサービス関数部４５は処理を終了し、占有していたリソースを開放する（Ｓ２１７）。
【0135】
＜キャンペーン情報の登録→ＣＤＮ配信部２１への配信パッケージの登録＞
これは、第３実施形態と同様の処理となる。
これは、第３実施形態と同様の処理となる。
【0136】
＜クルマからのデータアクセス→ＣＤＮから配信パッケージをクルマに送信＞
図３９に示すように、クルマ３１が、キャンペーン情報に含まれているダウンロードＵＲＬ情報と有効期限及び署名付きＵＲＬを元に、ＣＤＮ配信部２１にアクセスする（Ｓ２２１）。ＣＤＮ配信部２１は、有効期限と署名付きＵＲＬの署名が正しいか否かを、公開鍵を使用して検証する（Ｓ２２２）。検証結果がＯＫであれば、ＣＤＮ配信部２１は、有効期限が切れていないか検証し（Ｓ２２３）、有効期限が切れていなければステップＳ４２～Ｓ４６を実行する。一方、有効期限が切れていれば、ＣＤＮ配信部２１は、クルマ３１にエラーメッセージを送信する（Ｓ２２４）。
図３９に示すように、クルマ３１が、キャンペーン情報に含まれているダウンロードＵＲＬ情報と有効期限及び署名付きＵＲＬを元に、ＣＤＮ配信部２１にアクセスする（Ｓ２２１）。ＣＤＮ配信部２１は、有効期限と署名付きＵＲＬの署名が正しいか否かを、公開鍵を使用して検証する（Ｓ２２２）。検証結果がＯＫであれば、ＣＤＮ配信部２１は、有効期限が切れていないか検証し（Ｓ２２３）、有効期限が切れていなければステップＳ４２～Ｓ４６を実行する。一方、有効期限が切れていれば、ＣＤＮ配信部２１は、クルマ３１にエラーメッセージを送信する（Ｓ２２４）。
【0137】
＜ソフトウェア更新データの登録＞
＜案件情報の登録→パッケージの生成＞
＜案件情報登録リクエストの受信→案件情報の生成状況チェックと案件情報の送信＞
これらは、第３実施形態と同様の処理となる。
＜案件情報の登録→パッケージの生成＞
＜案件情報登録リクエストの受信→案件情報の生成状況チェックと案件情報の送信＞
これらは、第３実施形態と同様の処理となる。
【0138】
以上のように第６実施形態によれば、キャンペーン情報に、ダウンロードＵＲＬ情報と共に、有効期限及び署名付きＵＲＬを含め、ＯＴＡセンタ１Ｅ側で有効期限のチェックと署名の検証とを行うので、コンテンツへのアクセスを開始できる日時やアクセスできる日時を指定できると共に、コンテンツにアクセスできるユーザをＣＤＮ配信部２１にて限定することができる。したがって、クルマ３１との間で行う通信のセキュリティを向上させることができる。
尚、第１実施形態から第６実施形態では、ＯＴＡ運用者３４がＡＰＩゲートウェイ部１１にアクセスする場合や、ＯＥＭバックオフィス４からＡＰＩゲートウェイ部２２、鍵管理センタ５からＡＰＩゲートウェイ部２２にアクセスする場合は、サーバアーキテクチャを採用するプログラムにより処理しても良い。
尚、第１実施形態から第６実施形態では、ＯＴＡ運用者３４がＡＰＩゲートウェイ部１１にアクセスする場合や、ＯＥＭバックオフィス４からＡＰＩゲートウェイ部２２、鍵管理センタ５からＡＰＩゲートウェイ部２２にアクセスする場合は、サーバアーキテクチャを採用するプログラムにより処理しても良い。
【0139】
（第７実施形態）
第７実施形態は、ＯＴＡセンタ１等と無線通信を行う車載側システムの処理に係るものである。図４０及び図４１に示すように、クルマ３１Ａに搭載されている車載側システム５１は、ＯＴＡマスタ５２、ＥＣＵ５３（１）～５３（３）、ユーザインターフェース部５４等を備えている。ＯＴＡマスタ５２は、ダウンローダ５５及びインストーラ５６を有している。ＥＣＵ５３は、マイコン５７及びメモリ５８等を有しており、ユーザインターフェース部５４は、表示デバイス５９を有している。
第７実施形態は、ＯＴＡセンタ１等と無線通信を行う車載側システムの処理に係るものである。図４０及び図４１に示すように、クルマ３１Ａに搭載されている車載側システム５１は、ＯＴＡマスタ５２、ＥＣＵ５３（１）～５３（３）、ユーザインターフェース部５４等を備えている。ＯＴＡマスタ５２は、ダウンローダ５５及びインストーラ５６を有している。ＥＣＵ５３は、マイコン５７及びメモリ５８等を有しており、ユーザインターフェース部５４は、表示デバイス５９を有している。
【0140】
なお、車両側システムは以下の構成でもよい。車両側システムは、ＤＣＭとセントラルＥＣＵ（ＣＧＷとも呼ぶ）を備える。ＤＣＭとセントラルＥＣＵとは、バスを介してデータ通信可能に接続されている。バスは、イーサネットあるいはＣＡＮ（登録商標）バス、などである。
【0141】
ＯＴＡマスタ５２の機能の一部又は全部が、セントラルＥＣＵにおいて実現されても良い。一例としては、ＤＣＭはＣＤＮ２１やＯＴＡセンター１Ｆなどの外部とデータ通信のみ行い、ＯＴＡマスタ５２の機能の全てがセントラルＥＣＵにて実施されても良い。この場合、ＤＣＭは外部との無線通信を行うが、データをセントラルＥＣＵに転送する。あるいは、ＤＣＭは外部とデータ通信するのに加えて、ＯＴＡマスタ５２のダウンローダ５５として機能してもよい。ダウンローダ５５の機能とは、例えば、車両構成情報の生成、メタデータ検証、パッケージ検証、キャンペーン情報の検証である。あるいは、ＯＴＡマスタ５２の機能がＤＣＭにおいて実現されてもよい。この場合、セントラルＥＣＵにはＯＴＡマスタ５２以外の機能が実装される。又は、ＤＣＭとセントラルＥＣＵが一体化していても良い。
【0142】
すなわち、ＤＣＭの機能の一部又は全体をセントラルＥＣＵが有する構成でも良いし、セントラルＥＣＵの機能の一部又は全体をＤＣＭが有する構成でも良い。ＯＴＡマスタ５２において、ＤＣＭとセントラルＥＣＵとの機能分担がどのように構成されていても良い。ＯＴＡマスタ５２は、ＤＣＭ及びセントラルＥＣＵの２つのＥＣＵから構成されても良いし、ＤＣＭの機能とセントラルＥＣＵの機能とを有する１つの統合ＥＣＵで構成されても良い。
【0143】
図４１に示すＯＴＡセンタ１Ｆでは、第７実施形態の要旨に係る機能部分のみをブロック化して示している。ダウンローダ５５は、車両構成同期処理部６０及びキャンペーン通知受信部６１を備えている。図４２に示すように、車両構成同期処理部６０は、ＥＣＵ５３等が出力する各種のデータを車両構成情報として収集すると、収集した情報のフルデータにハッシュ関数を適用して得られるダイジェスト情報を生成する。車両情報のダイジェスト情報は、情報リクエスト１；第１リクエストと共にＯＴＡセンタ１Ｆに送信される。また、ＯＴＡセンタ１Ｆより、情報リクエスト１に対応したレスポンス応答；中間レスポンスを、ジョブＩＤ及び付加情報と共に受信する。
【0144】
付加情報には、車両側で処理を切り替えるためのパラメータ等が含まれており、そのパラメータを用いることで車両毎の処理やサービス毎の処理が行われる。また、付加情報には、後述するように、レスポンス応答を受信した時点から情報リクエスト２を送信するまでの送信条件である待機時間が含まれていても良い。
【0145】
キャンペーン通知受信部６１は、上記の付加情報に基づき、又はクルマ３１Ａに予め設定されている待機時間が経過したことを判断すると、ジョブＩＤを付した情報リクエスト２；第２リクエストを送信することでＯＴＡセンタ１Ｆにアクセスする。また、ＯＴＡセンタ１Ｆより、情報リクエスト２に対応したレスポンス応答；最終レスポンスを、キャンペーン情報と共に受信する。尚、レスポンス応答には、キャンペーンありとのキャンペーン情報、キャンペーンなしとのキャンペーン情報、フルデータの車両構成情報の送信要求、情報リクエスト１が処理完了前；言い換えると、処理中を含む。
【0146】
配信システム２Ｆには、サーバアーキテクチャを採用しているコンピュートサーバ部６２が追加されている。コンピュートサーバ部６２は、ＡＰＩゲートウェイ部１１Ｆ及びデータベース部４１Ｆとの間でデータ転送を行う。尚、第７実施形態においてクルマ３１Ａに搭載されている車載側システム５１は、第７実施形態以外の実施形態において説明されるＯＴＡセンタ１に対しても適用可能である。
【0147】
次に、第７実施形態の作用について説明する。
＜車両構成情報の送信→キャンペーン情報の受信；ＯＴＡマスタ側の処理＞
図４３に示すように、ＯＴＡマスタ５２は、クルマ３１Ａのイグニッションスイッチがオンされた際に、ＯＴＡセンタ１Ｆと車両構成情報の同期処理を最後に実施した日から、一定期間が変化したか否か、又は車両構成情報が変化したか否かを判断する（Ｓ２３１）。何れかが変化すると、ＯＴＡマスタ５２は、車両構成情報の同期処理に係るＨＴＴＰＳリクエスト；情報リクエスト１をＯＴＡセンタ１ＦのＡＰＩゲートウェイ部１１Ｆに送信する（Ｓ２３２）。又は、ステップＳ２３１として、ＯＴＡセンタ１Ｆからキャンペーンが或ることを示す通知を受信した場合にも、ステップＳＳ２３２に進む。
＜車両構成情報の送信→キャンペーン情報の受信；ＯＴＡマスタ側の処理＞
図４３に示すように、ＯＴＡマスタ５２は、クルマ３１Ａのイグニッションスイッチがオンされた際に、ＯＴＡセンタ１Ｆと車両構成情報の同期処理を最後に実施した日から、一定期間が変化したか否か、又は車両構成情報が変化したか否かを判断する（Ｓ２３１）。何れかが変化すると、ＯＴＡマスタ５２は、車両構成情報の同期処理に係るＨＴＴＰＳリクエスト；情報リクエスト１をＯＴＡセンタ１ＦのＡＰＩゲートウェイ部１１Ｆに送信する（Ｓ２３２）。又は、ステップＳ２３１として、ＯＴＡセンタ１Ｆからキャンペーンが或ることを示す通知を受信した場合にも、ステップＳＳ２３２に進む。
【0148】
ＯＴＡマスタ５２が、ＡＰＩゲートウェイ部１１Ｆから情報リクエスト１に対応したレスポンス応答をジョブＩＤ及び付加情報と共に受信すると（Ｓ２３３）、その付加情報に含まれている待機時間の経過待ちをする（Ｓ２３４）。待機時間が経過すると、ＯＴＡマスタ５２は、ＡＰＩゲートウェイ部１１ＦにジョブＩＤを付与した情報リクエスト２を送信し、キャンペーン情報を含むレスポンス応答を求める（Ｓ２３５）。尚、待機時間については、付加情報によって与えられるものに限らず、車載側システム５１に予め設定されていても良い。
【0149】
レスポンス応答を受信してそれが処理済みになると、キャンペーン情報の内容を判断する（Ｓ２３６，Ｓ２３７）。すなわち、更新対象となるキャンペーンが含まれているかや、車両構成情報のフルデータの送信が要求されているかなどを判断する。その内容に応じて、続くステップＳ２３８を経て分岐する。更新対象となるキャンペーンがあれば、先の実施形態と同様にダウンロード処理を行う（Ｓ２３９）。フルデータの送信要求があれば、車両構成情報の全データをＯＴＡセンタ１Ｆに送信する（Ｓ２４０）。
【0150】
次に、フルデータの送信が要求されている場合について説明する。
図４４に示すように、車両構成情報のフルデータを送信する際には、ステップＳ２３２におけるダイジェスト情報を、全データに替えてＨＴＴＰＳリクエストを送信する（Ｓ２４１）。以降のステップＳ２４２～Ｓ２４８の処理は、ステップＳ２３３～Ｓ２３９の処理と同様である。尚、ステップＳ２４１が情報リクエスト１に、ステップＳ２４２が中間レスポンス応答に、ステップＳ２４４が情報リクエスト２に、ステップＳ２４５が最終レスポンス応答に、それぞれ対応する。
図４４に示すように、車両構成情報のフルデータを送信する際には、ステップＳ２３２におけるダイジェスト情報を、全データに替えてＨＴＴＰＳリクエストを送信する（Ｓ２４１）。以降のステップＳ２４２～Ｓ２４８の処理は、ステップＳ２３３～Ｓ２３９の処理と同様である。尚、ステップＳ２４１が情報リクエスト１に、ステップＳ２４２が中間レスポンス応答に、ステップＳ２４４が情報リクエスト２に、ステップＳ２４５が最終レスポンス応答に、それぞれ対応する。
【0151】
＜車両構成情報の送信→キャンペーン情報の送信；ＯＴＡセンタ側の処理＞
図４５に示すように、情報リクエスト１の受信に対応した処理において、ＯＴＡセンタ１ＦのＡＰＩゲートウェイ部１１Ｆは、クルマ３１Ａ、モバイル３２又はＰＣ３３から、車両構成情報の同期に係るＨＴＴＰＳリクエストを受信する（Ｓ２５１）。すると、ＡＰＩゲートウェイ部１１Ｆは、上記のリクエストに含まれているＵＲＩ情報を元に、クルマ３１Ａ、モバイル３２又はＰＣ３３の何れかに振り分けを行う（Ｓ２５２）。
図４５に示すように、情報リクエスト１の受信に対応した処理において、ＯＴＡセンタ１ＦのＡＰＩゲートウェイ部１１Ｆは、クルマ３１Ａ、モバイル３２又はＰＣ３３から、車両構成情報の同期に係るＨＴＴＰＳリクエストを受信する（Ｓ２５１）。すると、ＡＰＩゲートウェイ部１１Ｆは、上記のリクエストに含まれているＵＲＩ情報を元に、クルマ３１Ａ、モバイル３２又はＰＣ３３の何れかに振り分けを行う（Ｓ２５２）。
【0152】
リクエストの送信元がクルマ３１Ａであれば、ＡＰＩゲートウェイ部１１Ｆは、コンピュートサービス関数部１２Ｆを起動して、受信した車両構成情報を渡す（Ｓ２５３）。コンピュートサービス関数部１２Ｆは、ジョブＩＤを発行し、当該ＩＤのジョブが処理中であることをデータベース部４１Ｆに登録すると（Ｓ２５５）、上記のジョブＩＤを付加情報と共にＡＰＩゲートウェイ部１１Ｆに渡す（Ｓ２５６）。ＡＰＩゲートウェイ部１１Ｆは、そのジョブＩＤ及び付加情報をクルマ３１Ａに渡す。これが中間レスポンス応答となる（Ｓ２５７）。
【0153】
次に、コンピュートサービス関数部１２Ｆは、適切な処理を実行できるコンピュートサービス処理部１５Ｆのコンテナアプリを起動して、車両構成情報を渡す（Ｓ２５８）。すると、コンピュートサービス関数部１２Ｆは処理を終了し、占有していたリソースを開放する（Ｓ２５９）。続いて、コンピュートサービス処理部１５Ｆは、受信した車両構成情報が、フルデータにハッシュ関数を適用して得られるハッシュ値；ダイジェスト値か、フルデータそのものかを判断する（Ｓ２６０、Ｓ２６１）。ダイジェスト値であれば、ＯＴＡセンタ１Ｆに登録されている値と一致するか否かを判断する（Ｓ２６２、Ｓ２６３）。
【0154】
双方の値が一致すれば、コンピュートサービス処理部１５Ｆは、渡された車両構成情報とジョブＩＤ情報に対して、ソフトウェア更新情報であるキャンペーンが存在するか、データベース部１９Ｆに格納されているキャンペーン情報を参照して判断する（Ｓ２６９）。対応するキャンペーン情報があれば、コンピュートサービス処理部１５Ｆは、クルマ３１Ａに配信するキャンペーン情報を、データベース部１９Ｆを参照して生成する（Ｓ２７０）。
【0155】
それから、コンピュートサービス処理部１５Ｆは、そのジョブＩＤに対応する処理が終了したこと、及び生成されたキャンペーン情報をデータベース部１９Ｆに登録する（Ｓ２７１）。すると、コンピュートサービス処理部１５Ｆは処理を終了し、占有していたリソースを開放する（Ｓ２７２）。ステップＳ２６９において、対応するキャンペーン情報がなければ、コンピュートサービス処理部１５Ｆは、対応するキャンペーン情報がないことを示すキャンペーン情報を生成して（Ｓ２７３）ステップＳ２７１に移行する。
【0156】
一方、ステップＳ２６３において、双方の値が不一致であれば、コンピュートサービス処理部１５Ｆは、そのジョブＩＤに対応する処理が終了したこと、及びフルデータの車両構成情報を要求したことをデータベース部４１Ｆに登録する（Ｓ２６４）。そして、ステップＳ２７２と同様の処理を行う（Ｓ２６５）。また、ステップＳ２６１において、受信した車両構成情報がフルデータであれば、ＯＴＡセンタ１Ｆに登録されている値と一致するか否かを判断する（Ｓ２６６、Ｓ２６７）。双方のデータが一致すれば、そのままステップＳ２６９に移行し、双方のデータが不一致であれば、ＯＴＡセンタ１Ｆ側の車両構成情報データベースを更新してから（Ｓ２６８）ステップＳ２６９に移行する。例えば、データベース部１９Ｆが車両構成情報データベースに相当する。
【0157】
ステップＳ２５２において、リクエストの送信元がスマートフォン３２又はＰＣ３３であれば、ＡＰＩゲートウェイ部１１Ｆは、コンピュートサーバ部６２に受信した車両構成情報を渡す（Ｓ２５４）。それから、図４６に示すステップＳ２７４に移行するが、以降のステップＳ２７４～Ｓ２８８の処理は、ステップＳ２５５～Ｓ２５７、Ｓ２６０～Ｓ２６４、Ｓ２６６～Ｓ２７３（Ｓ２７２を除く）でコンピュートサービス処理部１５Ｆが行った処理を、コンピュートサーバ部６２が実行するものである。
尚、リクエストの送信元がスマートフォン３２又はＰＣ３３の場合、スマートフォン３２又はＰＣ３３は、クルマ３１ＡのＯＴＡマスタ５２と通信することで車両構成情報のダイジェスト値及び車両構成情報のフルデータを予め取得し保存している。また、スマートフォン３２又はＰＣ３３は、車両構成情報のフルデータを予め取得し保存している。また、ステップＳ２５１にて、スマートフォン３２又はＰＣ３３が車両構成情報のフルデータをＡＰＩゲートウェイ部１１Ｆを送信する場合には、ステップＳ２６１では常にステップＳ２６６に移行する。
尚、リクエストの送信元がスマートフォン３２又はＰＣ３３の場合、スマートフォン３２又はＰＣ３３は、クルマ３１ＡのＯＴＡマスタ５２と通信することで車両構成情報のダイジェスト値及び車両構成情報のフルデータを予め取得し保存している。また、スマートフォン３２又はＰＣ３３は、車両構成情報のフルデータを予め取得し保存している。また、ステップＳ２５１にて、スマートフォン３２又はＰＣ３３が車両構成情報のフルデータをＡＰＩゲートウェイ部１１Ｆを送信する場合には、ステップＳ２６１では常にステップＳ２６６に移行する。
【0158】
＜車両構成情報の送信→キャンペーン情報の送信；ＯＴＡセンタ側の処理＞
図４７に示すステップＳ２９１～Ｓ２９４の処理は、ステップＳ２５１～Ｓ２５４の処理を情報リクエスト２の受信に対応して行うものである。続くステップＳ２９５において、コンピュートサービス関数部２０Ｆは、データベース部４１Ｆをチェックし、当該ジョブＩＤのタスクのステータスが完了しているか否かを確認する。前記タスクが完了済みであれば、コンピュートサービス関数部２０Ｆは、前記タスクの処理結果；キャンペーン情報をＡＰＩゲートウェイ部１１Ｆに渡す（Ｓ２９６）。尚、この時点でクルマ３１Ａに、車両構成情報のフルデータの送信を要求しても良い。すると、コンピュートサービス関数部２０Ｆは処理を終了し、占有していたリソースを開放する（Ｓ２９７）。ＡＰＩゲートウェイ部１１Ｆは、ＨＴＴＰＳレスポンスをクルマ３１Ａに渡す（Ｓ２９８）。これが２回目のレスポンス応答となる。
図４７に示すステップＳ２９１～Ｓ２９４の処理は、ステップＳ２５１～Ｓ２５４の処理を情報リクエスト２の受信に対応して行うものである。続くステップＳ２９５において、コンピュートサービス関数部２０Ｆは、データベース部４１Ｆをチェックし、当該ジョブＩＤのタスクのステータスが完了しているか否かを確認する。前記タスクが完了済みであれば、コンピュートサービス関数部２０Ｆは、前記タスクの処理結果；キャンペーン情報をＡＰＩゲートウェイ部１１Ｆに渡す（Ｓ２９６）。尚、この時点でクルマ３１Ａに、車両構成情報のフルデータの送信を要求しても良い。すると、コンピュートサービス関数部２０Ｆは処理を終了し、占有していたリソースを開放する（Ｓ２９７）。ＡＰＩゲートウェイ部１１Ｆは、ＨＴＴＰＳレスポンスをクルマ３１Ａに渡す（Ｓ２９８）。これが２回目のレスポンス応答となる。
【0159】
ステップＳ２９４に続くステップＳ３００～Ｓ３０２の処理は、ステップＳ２９５～Ｓ２９８（Ｓ２９７を除く）でコンピュートサービス処理部２０Ｆが行った処理を、コンピュートサーバ部６２が実行するものである。尚、ステップＳ３０２において、ＡＰＩゲートウェイ部１１Ｆは、ＨＴＴＰＳレスポンスをスマートフォン３２又はＰＣ３３に渡す。
【0160】
以上のように第７実施形態によれば、車載側システム５１が、クルマ３１Ａにおいて収集した車両構成情報を含む情報リクエスト１をＯＴＡセンタ１Ｆに送信すると、ＡＰＩゲートウェイ部１１Ｆは、そのリクエストに対応するジョブＩＤを含む中間のレスポンス応答を車載側システム５１に送信する。また、車載側システム５１は、上記のレスポンス応答を受信すると、情報リクエスト１に対応した最終レスポンスの応答要求を、ジョブＩＤを付与した情報リクエスト２としてＯＴＡセンタ１Ｆに送信する。
【0161】
すなわち、車載側システム５１は、ＯＴＡセンタ１Ｆと通信を行なうに当たって、２回の情報リクエスト送信を行なえば良い。そして、ＯＴＡセンタ１Ｆでは、それら２回のリクエスト送信の間に、要求された処理に対応したアプリケーションプログラムを起動して処理を実行させれば良い。これにより、サーバレスアーキテクチャを採用している外部のコンピュートサービスを利用する際においても、必要な処理を実行する期間だけ当該サービスを利用できるようになる。したがって、サービスの利用時間に応じて課金されるシステムであれば、ＯＴＡセンタ１Ｆの運用コストを低減できる。
【0162】
また、ＡＰＩゲートウェイ部１１Ｆは、中間のレスポンス応答に、情報リクエスト２の送信条件を含む付加情報を含ませて車載側システム５１に送信する。車載側システム５１は、上記のレスポンス応答を受信した後、前記送信条件を満たす状態になると情報リクエスト２を送信する。前記送信条件は、例えば、車載側システム５１が中間レスポンス応答を受信してから情報リクエスト２の送信までの待機時間であり、車載側システム５１は、その待機時間が経過すると情報リクエスト２を送信する。これにより、車載側システム５１は、ＯＴＡセンタ１Ｆ側が要求された処理を実行するのに必要と判断した時間だけ、情報リクエスト２の送信を待機することができる。
尚、コンピュートサーバ部６２を省略した構成も可能である。その場合、リクエストの送信元がモバイル３２又はＰＣ３３であっても、コンピュートサービス関数部１２Ｆが起動される。
尚、コンピュートサーバ部６２を省略した構成も可能である。その場合、リクエストの送信元がモバイル３２又はＰＣ３３であっても、コンピュートサービス関数部１２Ｆが起動される。
【0163】
（第８実施形態）
図４８に示す第８実施形態は、クルマ３１Ａに送信するキャンペーン情報がある場合において、クルマ３１Ａの乗員が、そのキャンペーンによるプログラム更新の承諾、ダウンロードの承諾、アクティベートの承諾を順次行うことを想定する。その際に、ＯＴＡセンタ１ＦとＯＴＡマスタ５２との間で行われる処理を示す。
図４８に示す第８実施形態は、クルマ３１Ａに送信するキャンペーン情報がある場合において、クルマ３１Ａの乗員が、そのキャンペーンによるプログラム更新の承諾、ダウンロードの承諾、アクティベートの承諾を順次行うことを想定する。その際に、ＯＴＡセンタ１ＦとＯＴＡマスタ５２との間で行われる処理を示す。
【0164】
ＯＴＡマスタ５２は、キャンペーンの内容を、ユーザインターフェース５４の表示デバイス５９に表示して、キャンペーン承諾ボタンの押下を乗員；ドライバに要求する（Ｓ３１１）。そして、ドライバによりキャンペーン承諾ボタンが押下されるまで待機する（Ｓ３１２）。当該承諾ボタンが押下されると、ＯＴＡマスタ５２は、キャンペーン承諾の結果をＯＴＡセンタ１Ｆに送信すると共に（Ｓ３１３）、ＯＴＡセンタ１Ｆからキャンペーン承諾のレスポンス応答を待ち受けして受信する（Ｓ３１４）。ステップＳ３１３、Ｓ３１５は並列処理となる。
【0165】
また、ＯＴＡマスタ５２は、ステップＳ３１３を実行すると、ステップＳ３１４と同様にキャンペーン承諾のレスポンス応答を待ち受けするが（Ｓ３１５）、ここでは所定時間が経過すれば、実際に応答を受信していない状態でも次の処理に移行する。尚、所定時間が経過する前に応答を受信すれば、次の処理に移行する。以降の処理においても同様に、ＯＴＡセンタ１Ｆからの応答を待ち受けする場合、所定時間が経過する前に応答を受信すれば、次の処理に移行する。
【0166】
続くステップＳ３１６では、ＯＴＡマスタ５２は、ダウンロード処理の所要時間等の内容を表示デバイス５９に表示して、ダウンロード承諾ボタンの押下をドライバに要求する。そして、ドライバによりダウンロード承諾ボタンが押下されるまで待機し（Ｓ３１７）、当該承諾ボタンが押下されると、ＯＴＡマスタ５２は、ダウンロード承諾の結果をＯＴＡセンタ１Ｆに送信すると共に（Ｓ３１８）、ＯＴＡセンタ１Ｆからダウンロード承諾のレスポンス応答を待ち受けして受信する（Ｓ３１９）。ステップＳ３１８、Ｓ３１９も並列処理となる。
【0167】
また、ＯＴＡマスタ５２は、ステップＳ３１８を実行すると、ステップＳ３１９と同様にダウンロード承諾のレスポンス応答を待ち受けするが（Ｓ３２０）、やはり所定時間が経過すれば、実際に応答を受信していない状態でも次の処理に移行する。続くステップＳ３２１で、ＯＴＡマスタ５２は、キャンペーン情報に含まれているダウンロードＵＲＬ情報を元にＣＤＮ配信部２１Ｆにアクセスし、ソフトウェアパッケージをダウンロードする。そして、ＯＴＡマスタ５２は、ダウンロード処理の進捗情報を表示デバイス５９に表示してドライバに示すと共に、ＯＴＡセンタ１Ｆにも進捗情報を送信する（Ｓ３２２）。
【0168】
ダウンロード処理が完了すると、ＯＴＡマスタ５２は、表示デバイス５９にアクティベート承諾ボタンを表示させて、その押下をドライバに要求する（Ｓ３２３）。そして、ドライバによりアクティベート承諾ボタンが押下されるまで待機し（Ｓ３２４）、当該承諾ボタンが押下されると、ＯＴＡマスタ５２は、アクティベート承諾の結果をＯＴＡセンタ１Ｆに送信すると共に（Ｓ３２５）、ＯＴＡセンタ１Ｆからアクティベート承諾のレスポンス応答を待ち受けして受信する（Ｓ３２６）。ステップＳ３２５、Ｓ３２６も並列処理となる。
【0169】
ＯＴＡマスタ５２は、ステップＳ３２５を実行すると、ステップＳ３２６と同様にアクティベート承諾のレスポンス応答を待ち受けするが（Ｓ３２５）、やはり所定時間が経過すれば、実際に応答を受信していない状態でも次の処理に移行する。続くステップＳ３２８において、ＯＴＡマスタ５２は、アクティベートが実行可能な適切なタイミングでアクティベートを実行する。
【0170】
以上のように第８実施形態によれば、車載側システム５１に、クルマ３１Ａの乗員が入力操作を行うユーザインターフェース部５４を備える。そして、ユーザインターフェース部５４において行われた入力操作に基づく処理が、ＯＴＡセンタ１Ｆからの応答の受信を伴なうものである際に、その応答を受信するか又は所定時間が経過すると、次のユーザインターフェース処理に進む。これにより、ＯＴＡセンタ１Ｆからの応答を受信するまでに比較的長い時間を要する際においても、乗員に、ユーザインターフェース処理の実行に遅滞が生じているように感じさせることを回避できる。
【0171】
（第９実施形態）
図４９に示す第９実施形態は第８実施形態の変形であり、図４８に示す処理から、ステップＳ３１５、Ｓ３２０、Ｓ３２７が除かれている。したがって、それらの処理において所定時間の経過待ちをすることなく、直ちに次の処理に移行する。また。ステップＳ３２８を実行すると、ＯＴＡマスタ５２は、各処理についてドライバによる承諾が得られているか否かを判断し（Ｓ３２９）、少なくとも１つの処理で承諾が得られていなければＯＴＡセンタ１Ｆにエラー通知を行う（Ｓ３３０）。
図４９に示す第９実施形態は第８実施形態の変形であり、図４８に示す処理から、ステップＳ３１５、Ｓ３２０、Ｓ３２７が除かれている。したがって、それらの処理において所定時間の経過待ちをすることなく、直ちに次の処理に移行する。また。ステップＳ３２８を実行すると、ＯＴＡマスタ５２は、各処理についてドライバによる承諾が得られているか否かを判断し（Ｓ３２９）、少なくとも１つの処理で承諾が得られていなければＯＴＡセンタ１Ｆにエラー通知を行う（Ｓ３３０）。
【0172】
（第１０実施形態）
第１０実施形態は、第７実施形態の変形であり、クルマ３１Ａの一部のドライバを事前にプレミアム会員としてＯＴＡセンタ１Ｆに登録しておくことで、プレミアム会員が行ったリクエストに対する処理を優先して行うケースを示す。
尚、プレミアム会員は現在の更新対象車両の一例であり、プレミアム会員のＶＩＮリストは現在の更新対象車両のＶＩＮリストの一例である。ＯＴＡセンタや配信システムへのアクセス集中を防ぐ目的で、更新対象車両の一部にのみキャンペーンありの情報を通知する。
第１０実施形態は、第７実施形態の変形であり、クルマ３１Ａの一部のドライバを事前にプレミアム会員としてＯＴＡセンタ１Ｆに登録しておくことで、プレミアム会員が行ったリクエストに対する処理を優先して行うケースを示す。
尚、プレミアム会員は現在の更新対象車両の一例であり、プレミアム会員のＶＩＮリストは現在の更新対象車両のＶＩＮリストの一例である。ＯＴＡセンタや配信システムへのアクセス集中を防ぐ目的で、更新対象車両の一部にのみキャンペーンありの情報を通知する。
【0173】
＜プレミアム会員のＶＩＮリスト登録＞
図５０に示すように、ＯＴＡセンタ１Ｆは、プレミアム会員のＶＩＮリストをＯＥＭバックオフィス４から受け取ると（Ｓ３３１）、そのリストをデータベース部４１Ｆに登録する（Ｓ３３２）。プレミアム会員のＶＩＮリストは、優先処理リストの一例である。尚、ＯＴＡセンタ１Ｆはプレミアム会員のＶＩＮリストの代わりに、クルマ３１Ａのオーナー情報に基づいて優先処理リストを作成しても良い。プレミアム会員のＶＩＮリストは、ソフトウェア更新の対象車両のＶＩＮリストの一例である。
図５０に示すように、ＯＴＡセンタ１Ｆは、プレミアム会員のＶＩＮリストをＯＥＭバックオフィス４から受け取ると（Ｓ３３１）、そのリストをデータベース部４１Ｆに登録する（Ｓ３３２）。プレミアム会員のＶＩＮリストは、優先処理リストの一例である。尚、ＯＴＡセンタ１Ｆはプレミアム会員のＶＩＮリストの代わりに、クルマ３１Ａのオーナー情報に基づいて優先処理リストを作成しても良い。プレミアム会員のＶＩＮリストは、ソフトウェア更新の対象車両のＶＩＮリストの一例である。
【0174】
ＯＥＭバックオフィス４で把握しているソフトウェア更新の対象車両のうちの一部；例えば、プレミアム会員を対象にしてソフトウェア更新を行うことが想定される。例えば、ソフトウェア更新の対象車両が１０００万台ある場合、クルマ３１ＡとＯＴＡセンタ１Ｆとの通信負荷やＯＴＡセンタ１Ｆでの処理負荷を考慮して、プレミアム会員に指定されているクルマ３１Ａのみを対象に、他車両より先にソフトウェア更新することが想定される。この場合、ＯＥＭバックオフィス４からＯＴＡセンタ１Ｆには、プレミアム会員に指定されているクルマ３１ＡのＶＩＮリストが登録される。非プレミアム会員については、この時点ではクルマ３１Ａ、スマートフォン３２又はＰＣ３３から車両構成情報同期のＨＴＴＰＳリスエストを送信しても、後述するステップＳ３３３又はＳ３４１にて、キャンペーン情報なしとして処理される。
【0175】
ＯＥＭバックオフィス４からＯＴＡセンタ１Ｆに登録されるＶＩＮリストは、ＯＥＭバックオフィス４からのＶＩＮリストの更新、あるいは、ＯＴＡセンタ１Ｆからの要求により更新される。これにより当初はソフトウェア更新できなかった非プレミアム会員のクルマ３１Ａは、ＶＩＮリストに登録されるようになりソフトウェア更新される。尚、ＯＥＭバックオフィス４からＯＴＡセンタ１ＦにＶＩＮリストが登録されない場合や、ブランクのＶＩＮリストが登録された場合は、全てのクルマ３１Ａをプレミアム会員として扱い、車両構成情報同期、キャンペーンの確認等が行われるようにしても良い。
【0176】
＜車両構成情報野送信→キャンペーン情報の送信；ＯＴＡセンタ側の処理＞
リクエストの送信元がクルマ３１Ａであれば、次のように処理する。
第７実施形態と同様にステップＳ２５１～Ｓ２５５を実行すると、図５１に示すように、コンピュートサービス関数部１２Ｆは、車両構成情報に含まれているＶＩＮがプレミアム会員のＶＩＮリストに含まれているか否かを判断する（Ｓ３３３）。当該リストに含まれていれば、ステップＳ２５６以降を実行する。ＶＩＮは車両のＩＤ情報の一例である。
リクエストの送信元がクルマ３１Ａであれば、次のように処理する。
第７実施形態と同様にステップＳ２５１～Ｓ２５５を実行すると、図５１に示すように、コンピュートサービス関数部１２Ｆは、車両構成情報に含まれているＶＩＮがプレミアム会員のＶＩＮリストに含まれているか否かを判断する（Ｓ３３３）。当該リストに含まれていれば、ステップＳ２５６以降を実行する。ＶＩＮは車両のＩＤ情報の一例である。
【0177】
ＶＩＮリストに含まれていなければ、コンピュートサービス関数部１２Ｆは、ジョブＩＤ及び付加情報をＡＰＩゲートウェイ部１１Ｆに渡すが、その付加情報には、以下の送信条件を含める（Ｓ３３４）。
・イグニッションスイッチがＯＮされた際に、ＯＴＡセンタ１Ｆにリクエストを送信するタイミング。例えば、毎回、翌日、Ｎ日後、停止等とする。但し、ＯＴＡセンタ１Ｆからのプッシュ通知があれば、それに応じて送信しても良い。
・今回収集する車両構成情報を、ＯＴＡセンタ１Ｆに送信することの有無。
例えば付加情報により、次にＯＴＡセンタ１Ｆにリクエストを送信する時を指定できる。また、次回のリクエストを送信時には車両構成情報を含めないように指示することもできる。ステップＳ３３５～Ｓ３４０の処理は、ステップＳ２５７～Ｓ２７２と同様である。
・イグニッションスイッチがＯＮされた際に、ＯＴＡセンタ１Ｆにリクエストを送信するタイミング。例えば、毎回、翌日、Ｎ日後、停止等とする。但し、ＯＴＡセンタ１Ｆからのプッシュ通知があれば、それに応じて送信しても良い。
・今回収集する車両構成情報を、ＯＴＡセンタ１Ｆに送信することの有無。
例えば付加情報により、次にＯＴＡセンタ１Ｆにリクエストを送信する時を指定できる。また、次回のリクエストを送信時には車両構成情報を含めないように指示することもできる。ステップＳ３３５～Ｓ３４０の処理は、ステップＳ２５７～Ｓ２７２と同様である。
【0178】
また、リクエストの送信元がスマートフォン３２又はＰＣ３３であれば、次のように処理する。
図５２に示すように、ステップＳ２７４を実行すると、コンピュートサーバ部６２は、ステップＳ３３３と同様の判断を行う（Ｓ３４１）。ＶＩＮがプレミアム会員のＶＩＮリストに含まれていれば、ステップＳ２７５以降を実行する。ＶＩＮリストに含まれていなければ、コンピュートサーバ部６２は、ステップＳ３３４と同様の判断を行う（Ｓ３４２）。続くステップＳ３４３～Ｓ３４５は、ステップＳ３３５、Ｓ３３８、Ｓ３３９と同様の処理であり、Ｓ３３８、Ｓ３３９ではコンピュートサーバ部６２が、コンピュートサービス関数部１２Ｆに替わって実行する。
図５２に示すように、ステップＳ２７４を実行すると、コンピュートサーバ部６２は、ステップＳ３３３と同様の判断を行う（Ｓ３４１）。ＶＩＮがプレミアム会員のＶＩＮリストに含まれていれば、ステップＳ２７５以降を実行する。ＶＩＮリストに含まれていなければ、コンピュートサーバ部６２は、ステップＳ３３４と同様の判断を行う（Ｓ３４２）。続くステップＳ３４３～Ｓ３４５は、ステップＳ３３５、Ｓ３３８、Ｓ３３９と同様の処理であり、Ｓ３３８、Ｓ３３９ではコンピュートサーバ部６２が、コンピュートサービス関数部１２Ｆに替わって実行する。
【0179】
以上のように第１０実施形態によれば、コンピュートサービス関数部１２Ｆは、情報リクエスト１に対応するクルマ３１ＡのＶＩＮがプレミアム会員のＶＩＮリストに登録されていなければ、クルマ３１Ａに対するキャンペーン情報があるか否かを判定することなく、そのリクエストに対する最終レスポンスとして、キャンペーン情報なしを示す情報を、ＡＰＩゲートウェイ部１１Ｆを介して車載側システム５１に送信させる。これにより、プレミアム会員として登録された一部のユーザに対し、優先的にキャンペーン情報を送信することができる。
【0180】
（第１１実施形態）
上記の実施形態では、情報リクエスト１として、車両構成情報のＨＴＴＰＳリクエスト、キャンペーン情報登録のＨＴＴＰＳリクエスト、案件情報登録のための案件情報のＨＴＴＰＳリクエストを説明したが、情報リクエスト１は、他の情報でも良い。情報リクエスト１は、例えば、ＶＩＮ（Vehicle Identification Number）などの車両を識別する情報でも良い。例えば、情報リクエスト１として、クルマ３１Ａ、スマートフォン３２又はＰＣ３３からＶＩＮがＯＴＡセンタに送信されても良い。車両識別情報は車両情報の一例である。ＯＴＡセンタから情報リクエスト２に対するレスポンス応答として、例えば、クルマ３１Ａに送信されるキャンペーン情報を説明している。情報リクエスト２はＯＴＡセンタがＯＴＡマスタ５２に要求する各種の指示でも良い。
上記の実施形態では、情報リクエスト１として、車両構成情報のＨＴＴＰＳリクエスト、キャンペーン情報登録のＨＴＴＰＳリクエスト、案件情報登録のための案件情報のＨＴＴＰＳリクエストを説明したが、情報リクエスト１は、他の情報でも良い。情報リクエスト１は、例えば、ＶＩＮ（Vehicle Identification Number）などの車両を識別する情報でも良い。例えば、情報リクエスト１として、クルマ３１Ａ、スマートフォン３２又はＰＣ３３からＶＩＮがＯＴＡセンタに送信されても良い。車両識別情報は車両情報の一例である。ＯＴＡセンタから情報リクエスト２に対するレスポンス応答として、例えば、クルマ３１Ａに送信されるキャンペーン情報を説明している。情報リクエスト２はＯＴＡセンタがＯＴＡマスタ５２に要求する各種の指示でも良い。
【0181】
（その他の実施形態）
サーバレスアーキテクチャを採用するアプリケーションプログラムは、ＡＷＳを利用するものに限らず、その他のクラウドコンピューティングサービスを利用しても良い。
情報携帯端末は、スマートフォンやパーソナルコンピュータに限らない。
ＯＴＡセンタが通信先とする外部は、車両やＯＴＡ運用者に限らない。
アクセス制御情報は、有効期限及び署名付きＵＲＬに限らない。
送信条件は、情報リクエスト２の送信を許容するエリア、例えば駐車場等であっても良い。
サーバレスアーキテクチャを採用するアプリケーションプログラムは、ＡＷＳを利用するものに限らず、その他のクラウドコンピューティングサービスを利用しても良い。
情報携帯端末は、スマートフォンやパーソナルコンピュータに限らない。
ＯＴＡセンタが通信先とする外部は、車両やＯＴＡ運用者に限らない。
アクセス制御情報は、有効期限及び署名付きＵＲＬに限らない。
送信条件は、情報リクエスト２の送信を許容するエリア、例えば駐車場等であっても良い。
【0182】
本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。
【0183】
各装置等が提供する手段および／または機能は、実体的なメモリ装置に記録されたソフトウェアおよびそれを実行するコンピュータ、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの組合せによって提供することができる。例えば、制御装置がハードウェアである電子回路によって提供される場合、それは多数の論理回路を含むデジタル回路、またはアナログ回路によって提供することができる。
【0184】
本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。
【図1】
【図2】
【図3】
【図4A】
【図4B】
【図5A】
【図5B】
【図6】
【図7】
【図8A】
【図8B】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15A】
【図15B】
【図16】
【図17A】
【図17B】
【図18】
【図19A】
【図19B】
【図20】
【図21】
【図22】
【図23】
【図24A】
【図24B】
【図25A】
【図25B】
【図26A】
【図26B】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38A】
【図38B】
【図39】
【図40】
【図41】
【図42】
【図43】
【図44】
【図45A】
【図45B】
【図45C】
【図46A】
【図46B】
【図47】
【図48A】
【図48B】
【図49A】
【図49B】
【図50】
【図51】
【図52】
【図53】
【図54】
【図55】
