CN117999773A - 数据通信系统、中心装置、主机装置、更新数据配置程序以及更新数据获取程序 - Google Patents

Abstract

数据通信系统1具备将更新数据配置于内容分发网络(CDN)的中心装置(2)、和将从CDN下载的更新数据安装于重编对象的电子控制装置的主机装置(4)。中心装置通过规定的加密方式对更新数据进行加密并配置于CDN，主机装置以分割流式传输方式从CDN下载进行了加密的更新数据。

Description

数据通信系统、中心装置、主机装置、更新数据配置程序以及 更新数据获取程序

相关申请的交叉引用

本申请主张于2021年9月30日申请的日本申请编号2021－161213的优先权，并在此引用其全部内容。

技术领域

本发明涉及数据通信系统、中心装置、主机装置、更新数据配置程序以及更新数据获取程序。

背景技术

近年来，随着驾驶辅助功能、自动驾驶功能等车辆控制的多样化，搭载于电子控制装置(以下，称为ECU(Electronic Control Unit))的车辆控制、诊断等应用程序的规模增大。另外，随着功能改善等所带来的升级，重编ECU的应用程序的机会也增加。重编也有称为程序更新的情况。另一方面，随着通信网络的发展等，联网汽车的技术也普及。根据这样的情况，例如在专利文献1公开了通过OTA(Over The Air：空中下载)的技术从中心装置向车辆侧的主机装置分发对更新数据进行了打包的更新数据包的技术。主机装置是总括ECU的应用程序的重编的装置。从中心装置向主机装置分发的更新数据例如包含自动驾驶、先进驾驶辅助系统(ADAS(Advanced Driver-Assistance Systems))、多媒体等的应用程序、数据。

专利文献1：日本特开2020－276424号公报

近年来，为了提高车辆的用户体验(以下，称为UX(User Experience))，从中心装置分发到主机装置的更新数据包的数据大小大容量化而成为几GB级以上。另外，也研究通过频繁地进行应用程序的更新来提高更新频率。在从中心装置向主机装置分发几GB级以上的大容量的数据大小的更新数据包的情况下，若主机装置的缓冲存储器的存储器容量不足，则在主机装置中，需要从中心装置通过流式传输方式下载以几KB单位进行分割的更新数据包，并通过流式传输方式将分割后的更新数据包转送至目标ECU。

然而，若通过云计算服务的内容分发网络(以下，称为CDN(Content DeliveryNetwork))服务进行验算，则与数据流量的费用相比，超文本传输协议(以下，称为HTTP(Hypertext Transfer Protocol))/安全超文本传输协议(以下，称为HTTPS(HypertextTransfer Protocol Secure))的范围请求的费用成为分发成本的支配项。为了使OTA的服务价格的竞争力提高抑制HTTPS的分发成本也非常重要。因此，期望在不对CDN建立HTTPS会话的情况下，通过流式传输方式从中心装置向主机装置安全地下载更新数据包。

发明内容

本公开的目的在于适当地抑制主机装置从中心装置下载更新数据时的分发成本。

根据本公开的一方式，具备将更新数据配置于内容分发网络(CDN)的中心装置、和将从CDN下载的更新数据安装于重编对象的电子控制装置的主机装置。中心装置通过规定的加密方式对更新数据进行加密。主机装置以分割流式传输方式从CDN下载进行了加密的更新数据。

在主机装置中，主机装置以分割流式传输方式从CDN下载进行了加密的更新数据。能够适当地抑制主机装置从中心装置下载更新数据时的分发成本。

根据本公开的一方式，具备将更新数据配置于内容分发网络(CDN)的中心装置、和将从CDN下载的更新数据安装于重编对象的电子控制装置的主机装置。具备能够储存更新数据的记录介质。中心装置通过规定的加密方式对更新数据进行加密并将更新数据配置于CDN。主机装置从CDN经由记录介质以一并储存方式下载进行了加密的更新数据。

在主机装置中，主机装置从CDN经由记录介质以一并储存方式下载进行了加密的更新数据。能够使更新数据的分发路径具有多样性，通过选择分发成本有优势的分发路径，能够适当地抑制主机装置从中心装置下载更新数据时的分发成本。

根据本公开的一方式，具备将更新数据配置于内容分发网络(CDN)的中心装置、和将从CDN下载的更新数据安装于重编对象的电子控制装置的主机装置。中心装置与多个运营商的CDN连接，通过规定的加密方式对更新数据进行加密，根据分发方式、分发区域、通信协议、分发数据大小中至少任意一个，从多个运营商的CDN中选定分发成本有优势的CDN，并将进行了加密的更新数据配置于该选定的CDN。

在中心装置中，通过规定的加密方式对更新数据进行加密，从分发成本不同的多个运营商的CDN中选定分发成本有优势的CDN，并将进行了加密的更新数据配置于该选定的CDN。能够适当地抑制主机装置从中心装置下载更新数据时的分发成本。

根据本公开的一方式，具备将更新数据配置于内容分发网络(CDN)的中心装置、和将从CDN下载的更新数据安装于重编对象的电子控制装置的主机装置。中心装置与多个运营商的CDN连接，根据分发方式、分发区域、通信协议、分发数据大小中至少任意一个，从多个运营商的CDN中选定分发成本有优势的CDN，不对更新数据进行加密，而将更新数据配置于该选定的CDN。主机装置在与CDN之间建立了传输层安全(TLS)的基础上，从该CDN下载更新数据。

在中心装置中，不对更新数据进行加密，而从分发成本不同的多个运营商的CDN中选定分发成本有优势的CDN，并将进行了加密的更新数据配置于该选定的CDN，在主机装置中，在与CDN之间建立了传输层安全(TLS)的基础上，从该CDN下载更新数据。能够适当地抑制主机装置从中心装置下载更新数据时的分发成本。

附图说明

在参照附图的同时通过下述的详细的记述，本发明的上述目的以及其它的目的、特征、优点变得更明确。该附图为如下。

图1是表示第一实施方式的系统整体中的处理的流程的图，

图2是OTA中心以及OTA主机的功能框图，

图3是说明CTR模式的加密处理的图，

图4是说明CTR模式的解密处理的图，

图5是表示CBC模式与CTR模式的优点以及缺点的比较的图，

图6是表示CBC模式与CTR模式的吞吐量的比较的图，

图7是说明CBC模式的解密处理的图，

图8是说明CTR模式的解密处理的图，

图9是表示OTA中心的处理的图，

图10是表示中心的处理的图，

图11是表示OTA中心的处理的图，

图12是表示OTA主机的处理的图，

图13是表示OTA主机的处理的图，

图14是表示OTA主机的处理的图，

图15是说明第二实施方式的OFB模式的加密处理的图，

图16是说明OFB模式的解密处理的图，

图17是表示CBC模式与OFB模式的优点以及缺点的比较的图，

图18是表示CBC模式与OFB模式的吞吐量的比较的图，

图19是说明CTR模式的解密处理的图，

图20是说明OFB模式的解密处理的图，

图21是表示OTA中心的处理的图，

图22是表示OTA中心的处理的图，

图23是表示OTA中心的处理的图，

图24是表示OTA主机的处理的图，

图25是表示OTA主机的处理的图，

图26是表示OTA主机的处理的图，

图27是表示第三实施方式的系统整体中的处理的流程的图，

图28是表示OTA中心的处理的图，

图29是表示OTA中心的处理的图，

图30是表示OTA中心的处理的图，

图31是表示OTA主机的处理的图，

图32是表示OTA主机的处理的图，

图33是表示OTA主机的处理的图，

图34是表示第四实施方式的系统整体中的处理的流程的图，

图35是OTA中心以及OTA主机的功能框图，

图36是表示OTA主机的处理的图，

图37是表示OTA主机的处理的图，

图38是表示OTA主机的处理的图，

图39是表示第五实施方式的OTA主机的处理的图，

图40是表示OTA主机的处理的图，

图41是表示OTA主机的处理的图，

图42是表示存储器容量与访问速度的关系的图，

图43是表示第六实施方式的系统整体中的处理的流程的图，

图44是OTA中心以及OTA主机的功能框图，

图45是表示发送RP元数据的方式的图，

图46是表示RP元数据的构成的图，

图47是表示RP元数据的构成的图，

图48是表示OTA中心的处理的图，

图49是表示OTA中心的处理的图，

图50是表示OTA中心的处理的图，

图51是表示OTA中心的处理的图，

图52是表示OTA主机的处理的图，

图53是表示OTA主机的处理的图，

图54是表示OTA主机的处理的图，

图55是表示第七实施方式的系统整体中的处理的流程的图，

图56是CCMP模式的功能，

图57是说明基于CCMP模式的吞吐量的估计的图，

图58是现有方式的功能框图，

图59是说明基于现有方式的吞吐量的估计的图，

图60是表示CCMP模式与现有方式的吞吐量的比较的图，

图61是OTA中心以及OTA主机的功能框图，

图62是表示OTA中心的处理的图，

图63是表示OTA中心的处理的图，

图64是表示OTA中心的处理的图，

图65是表示OTA主机的处理的图，

图66是表示OTA主机的处理的图，

图67是表示OTA主机的处理的图，

图68是表示第八实施方式的系统整体中的处理的流程的图，

图69是GCMP模式的功能框图，

图70是说明基于GCMP模式的吞吐量的估计的图，

图71是表示GCMP模式与现有方式的吞吐量的比较的图，

图72是表示OTA中心的处理的图，

图73是表示OTA中心的处理的图，

图74是表示OTA中心的处理的图，

图75是表示OTA主机的处理的图，

图76是表示OTA主机的处理的图，

图77是表示OTA主机的处理的图，

图78是表示第九实施方式的系统整体中的处理的流程的图，

图79是表示OTA中心的处理的图，

图80是表示OTA中心的处理的图，

图81是表示OTA中心的处理的图，

图82是表示OTA中心的处理的图，

图83是表示OTA主机的处理的图，

图84是表示OTA主机的处理的图，

图85是表示OTA主机的处理的图，

图86是表示OTA主机的处理的图，

图87是表示第十实施方式的系统整体中的处理的流程的图，

图88是表示CDN的成本比较的图，

图89是表示CDN的成本比较的图，

图90是表示各云服务的CDN价格表格的图，

图91是表示各云服务运营商的储存方式的价格表格的图，

图92是表示云服务运营商的流式传输方式中的每个流式传输大小的价格表格的图，

图93是表示各云服务运营商的流式传输方式中的每个流式传输大小的价格表格的图，

图94是OTA中心以及OTA主机的功能框图，

图95是表示OTA中心的处理的图，

图96是表示OTA中心的处理的图，

图97是表示OTA中心的处理的图，

图98是表示OTA中心的处理的图，

图99是表示第十一实施方式的系统整体中的处理的流程的图，

图100是表示能够通过DHE或者ECDHE共享密钥的公用密钥的图，

图101是表示OTA中心的处理的图，

图102是表示OTA中心的处理的图，

图103是表示OTA中心的处理的图，

图104是表示OTA中心的处理的图，

图105是表示OTA主机的处理的图，

图106是表示OTA主机的处理的图，

图107是表示OTA主机的处理的图，

图108是表示OTA主机的处理的图，

图109是表示第十二实施方式的系统整体中的处理的流程的图，

图110是表示OTA中心的处理的图，

图111是表示OTA中心的处理的图，

图112是表示OTA中心的处理的图，

图113是表示OTA主机的处理的图，

图114是表示OTA主机的处理的图，

图115是表示OTA主机的处理的图，

图116是表示第十三实施方式的系统整体中的处理的流程的图，

图117是说明CTR模式的加密处理的图，

图118是说明CTR模式的解密处理的图，

图119是表示OTA中心的处理的图，

图120是表示OTA中心的处理的图，

图121是表示OTA中心的处理的图，

图122是表示OTA主机的处理的图，

图123是表示OTA主机的处理的图，

图124是表示OTA主机的处理的图，

图125是表示第十四实施方式的系统整体中的处理的流程的图，

图126是说明AES专用密钥的图，

图127是表示OTA中心的处理的图，

图128是表示OTA中心的处理的图，

图129是表示OTA中心的处理的图，

图130是表示OTA主机的处理的图，

图131是表示OTA主机的处理的图，

图132是表示OTA主机的处理的图，

图133是表示第十五实施方式的系统整体中的处理的流程的图，

图134是表示OTA中心的处理的图，

图135是表示OTA中心的处理的图，

图136是表示OTA主机的处理的图，

图137是表示OTA主机的处理的图，

图138是表示第十六实施方式的系统整体中的处理的流程的图，图139是表示来自中间攻击者的攻击的图，

图140是表示附加数字签名的方式的图，

图141是表示OTA中心的处理的图，

图142是表示OTA中心的处理的图，

图143是表示OTA中心的处理的图，

图144是表示OTA主机的处理的图，

图145是表示OTA主机的处理的图，

图146是表示第十七实施方式的系统整体中的处理的流程的图，

图147是表示OTA中心的处理的图，

图148是表示OTA中心的处理的图，

图149是表示OTA主机的处理的图，

图150是表示OTA主机的处理的图，

图151是表示OTA主机的处理的图，

图152是表示第十八实施方式的系统整体中的处理的流程的图，

图153是表示各云服务的CDN价格表格的图，

图154是表示各云服务的CDN价格表格的图，

图155是表示各云服务运营商的储存方式的价格表格的图，

图156是表示各云服务运营商的储存方式的价格表格的图，

图157是表示各云服务运营商的流式传输方式中的每个流式传输大小的价格表格的图，

图158是表示各云服务运营商的流式传输方式中的每个流式传输大小的价格表格的图，

图159是表示各云服务运营商的流式传输方式中的每个流式传输大小的价格表格的图，

图160是表示各云服务运营商的流式传输方式中的每个流式传输大小的价格表格的图，

图161是表示各云服务运营商的质量信息的图，

图162是说明CDN供应商的选定的图，

图163是表示OTA中心的处理的图，

图164是表示OTA中心的处理的图，

图165是表示OTA中心的处理的图，

图166示出第十一实施方式的变形例，是表示系统整体中的处理的流程的一部分的图，

图167是表示系统整体中的处理的流程的一部分的图，

图168是表示系统整体中的处理的流程的一部分的图，

图169是表示系统整体中的处理的流程的一部分的图，

图170是表示OTA主机的处理的图，

图171是表示PC的处理的图，

图172是表示OTA中心的处理的图，

图173是表示OTA主机的处理的图，

图174示出第十二实施方式的变形例，是表示系统整体中的处理的流程的一部分的图，

图175是表示系统整体中的处理的流程的一部分的图，

图176是表示系统整体中的处理的流程的一部分的图，

图177是表示系统整体中的处理的流程的一部分的图，

图178是表示OTA主机的处理的图，

图179是表示PC的处理的图，

图180是表示OTA中心的处理的图，

图181是表示OTA主机的处理的图，

图182示出第十六实施方式的变形例，是表示系统整体中的处理的流程的一部分的图，

图183是表示系统整体中的处理的流程的一部分的图，

图184是表示系统整体中的处理的流程的一部分的图，

图185是表示系统整体中的处理的流程的一部分的图，

图186是表示OTA主机的处理的图，

图187是表示PC的处理的图，

图188是表示OTA中心的处理的图，

图189是表示OTA主机的处理的图，

图190是表示第十九实施方式的系统整体中的处理的流程的图，

图191是表示活动通知生成部的处理的图，

图192是表示CDN供应商选定部的处理的图，

图193是表示CDN供应商选定部的处理的图，

图194是表示第十九实施方式的第一变形例的系统整体中的处理的流程的图，

图195是表示CDN供应商选定部的处理的图，

图196是表示第十九实施方式的第二变形例的系统整体中的处理的流程的图，

图197是表示选择表格的图，

图198是表示CDN供应商选定部的处理的图，

图199是表示CDN供应商选定部的处理的图，

图200是表示性能测定部的处理的图，

图201是表示CDN服务器确认部的处理的图，

图202是表示第十九实施方式的第三变形例的系统整体中的处理的流程的图，

图203是表示日志发送部3a的处理的图，

图204是表示性能测定部的处理的图，

图205是表示性能测定部的处理的图，

图206示出第十九实施方式的第四变形例，是表示CDN供应商选定部7a的处理的图，

图207是表示活动通知生成部的处理的图，

图208是表示第十九实施方式的第五变形例的系统整体中的处理的流程的图，

图209是表示轮循(round robin)记录的图，

图210是表示CDN供应商选定部7a的处理的图，

图211是表示切换部的处理的图，

图212是表示第二十实施方式的系统整体中的处理的流程的图，

图213是表示计算方法的图，

图214是表示活动通知生成部的处理的图，

图215是表示CDN供应商选定部的处理的图，

图216是表示CDN供应商选定部的处理的图，

图217是表示CDN供应商选定部的处理的图，

图218是表示CDN供应商选定部的处理的图，

图219是表示CDN供应商选定部的处理的图，

图220是表示CDN供应商选定部的处理的图，

图221是表示CDN供应商选定部的处理的图，

图222是表示进展信息管理部的处理的图，

图223是表示CDN供应商选定部的处理的图，

图224是表示活动通知生成部的处理的图。

具体实施方式

以下，参照附图对多个实施方式进行说明。另外，在后续的实施方式中，有时对与先行的实施方式重复的内容省略说明。

(第一实施方式)

参照图1～图14对第一实施方式进行说明。如图1所示，数据通信系统1构成为具备OTA中心2、和搭载于车辆的车辆侧系统3，OTA中心2与车辆侧系统3能够进行数据通信。OTA中心2相当于中心装置。OTA中心2与车辆侧系统3处于一对多的关系，OTA中心2能够在与非特定的许多车辆侧系统3之间进行数据通信。

车辆侧系统3具备OTA主机4、和目标ECU5。OTA主机4相当于主机装置。OTA主机4和目标ECU5例如与CAN(Controller Area Network：控制器局域网)(注册商标)等车载网络连接，经由车载网络以能够进行数据通信的方式连接。车载网络也可以是LIN(LocalInterconnect Network：本地互联网)、FlexRay(注册商标)、CAN FD(CAN Flexible Datarate：可变速率的CAN)(注册商标)、Ethernet：以太网(注册商标)等。目标ECU5是成为应用程序的重编对象的ECU，例如可以是进行自动驾驶系统的控制的ECU、进行ADAS系统的控制的ECU、进行多媒体系统的控制的ECU等的任何一个。应用程序是与应用的执行相关的程序，例如包含应用程序、固件程序、操作系统程序。

OTA中心2具备数据包生成服务器6、和分发服务器7。数据包生成服务器6是具有对更新数据进行打包生成更新数据包的功能的服务器。更新数据包例如是将储存了更新数据的多个文件压缩并储存的zip文件。分发服务器7是具有将通过数据包生成服务器6生成的更新数据包分发给车辆侧系统3的功能的服务器。

例如若随着功能改善等所带来的升级，而产生ECU的应用程序的重编要求，则OTA中心2向车辆侧系统3、用户所持有的智能手机等移动信息终端分发活动通知。OTA中心2以得到了来自用户的下载同意为条件，将更新数据包配置在内容分发网络(以下，称为CDN(Content Delivery Network))8，并经由CDN8将更新数据包分发给OTA主机4。或者在更新数据包已经配置于CDN8的情况下，OTA中心2以得到了来自用户的下载同意为条件，使更新数据包从CDN8分发到OTA主机4。

OTA主机4若从OTA中心2下载更新数据包，则以得到了来自用户的安装同意为条件，将更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5。将提供CDN8作为服务的运营商称为CDN供应商。另外，OTA主机4通过向CDN8的CDN服务器进行访问来获取更新数据包。

在本实施方式中，为了实现车辆侧系统3中的先进加密标准(以下，简称为AES(Advanced Encryption Standard))的解密处理的高速化，作为加密模式，不采用一般的块加密的密码块链接模式(以下，称为CBC模式(Cipher Block Chaining Mode))，而采用作为流式加密的代表的计数器模式(以下，称为CTR模式(Counter Mode))。在本实施方式中，OTA中心2通过AES密钥以CTR模式对更新数据包进行加密。另外，车辆侧系统3通过AES密钥以CTR模式对更新数据包进行加密。另外，OTA中心2对每个车辆具备RSA(Rivest-Shamir-Adleman cryptosystem：里维斯特-沙米尔-阿德曼密码系统)公开密钥。OTA主机4在车辆制造阶段被写入RSA秘密密钥。

如图2所示，OTA中心2具备公用密钥生成部2a、更新数据包加密部2b、公用密钥加密部2c、公用密钥储存部2d、加密数据包配置部2e、以及活动通知发送部2f，作为涉及加密的功能模块。更新数据包加密部2b相当于更新数据加密部。加密数据包配置部2e相当于加密数据配置部。通过具有CPU(Central Processing Unit：中央处理器)、RAM(RandomAccess Memory：随机存储器)、ROM(Read Only Memory：只读存储器)，I/O(Input/Output：输入输出)等的微型计算机的硬件以及软件的协作实现各部2a～2f。CPU通过执行储存于ROM的包含加密程序、更新数据配置程序、秘密信息共享程序等的各种程序，实现OTA中心2的功能。

公用密钥生成部2a生成AES密钥，作为用于加密更新数据包的公用密钥。数据包加密部2b通过生成的AES密钥以CTR模式对更新数据包进行加密。数据包加密部2b通过AES密钥执行对计数器值的AES块加密处理来对计数器值进行加密。数据包加密部2b对加密后的计数器值、和更新数据包进行异或(XOR)运算，将多个加密后的片断结合，生成通过AES密钥进行了加密的更新数据包。另外，计数器值例如是八位的数字，按照每一AES块增加“1”。

公用密钥加密部2c通过RSA公开密钥对AES密钥进行加密。公用密钥储存部2d将通过RSA公开密钥进行了加密的AES密钥储存在活动通知中。加密数据包配置部2e将通过AES密钥进行了加密的更新数据包配置于CDN8。活动通知发送部2f将储存了进行了加密的AES密钥的活动通知发送给重编对象的车辆侧系统3。活动通知发送部2f也可以将活动通知分发给用户所持有的智能手机等移动信息终端。

OTA主机4具备公用密钥获取部4a、公用密钥解密部4b、加密数据包获取部4c、块加密处理部4d、加密数据包解密部4e、以及安装处理部4f，作为涉及解密的功能模块。加密数据包获取部4c相当于加密数据获取部。加密数据包解密部4e相当于加密数据解密部。通过具有CPU、RAM、ROM、I/O等的微型计算机的硬件以及软件的协作实现各部4a～4f。CPU通过执行储存于ROM的包含解密程序、更新数据获取程序、秘密信息共享程序等的各种程序，实现OTA主机4的功能。

公用密钥获取部4a若由于在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取进行了加密的AES密钥。公用密钥解密部4b通过RSA秘密密钥对进行了加密的AES密钥进行解密取出AES密钥。加密数据包获取部4c从CDN8下载并获取进行了加密的更新数据包。此时，块加密处理部4d与加密数据包获取部4c从CDN8下载并获取进行了加密的更新数据包并行地，通过AES密钥执行计数器值的AES块加密处理来对计数器值进行加密。加密数据包解密部4e对进行了加密的计数器值、和从CDN8下载的进行了加密的更新数据包进行异或(以下，XOR(Exclusively-OR)运算进行解密。安装处理部4f将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5。

CTR模式的加密处理如图3所示，CTR模式的解密处理如图4所示。如图5所示，相对于作为CBC模式的缺点的“不能够进行加密以及解密的前准备”、“不能够进行加密的并列处理”，作为CTR模式的优点能够列举“能够进行加密以及解密的前准备，所以能够高速化”、“能够进行加密以及解密的并列处理”。即，作为通过采用CTR模式作为加密模式有助于吞吐量的提高的优点，如图6所示，与采用一般的块加密的CBC模式的情况相比较，能够使吞吐量大约提高40％。

如图7所示，在CBC模式的解密处理中，由于输入为密文，所以若不接收作为密文的更新数据包，则不能够开始解密处理。与此相对，如图8所示，在CTR模式的解密处理中，由于输入为计数器值，所以能够从接收作为密文的更新数据包之前开始解密处理。另外，由于相互没有依赖关系，所以也能够同时并列执行多个加密运算。

接下来，参照图9～图14对上述的构成的作用进行说明。

(1－1)OTA中心2的处理(参照图9～图11)

OTA中心2生成用于对更新数据包进行加密的AES密钥(A011，相当于公用密钥生成步骤)。OTA中心2通过生成的AES密钥以CTR模式对更新数据包进行加密(A012，相当于更新数据加密步骤)。OTA中心2通过RSA公开密钥对AES密钥进行加密(A013，相当于公用密钥加密步骤)。OTA中心2将通过RSA公开密钥进行了加密的AES密钥储存在活动通知中(A014，相当于公用密钥储存步骤)。OTA中心2将通过AES密钥进行了加密的更新数据包配置于CDN8(A015，相当于加密数据配置步骤)。将更新数据包配置于CDN8表示将更新数据包配置于CDN8的原始服务器。OTA中心2将储存了进行了加密的AES密钥的活动通知发送给重编对象的车辆侧系统3(A016，相当于活动通知发送步骤)。

(1－2)OTA主机4的处理(参照图12～图14)

OTA主机4若由于在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取AES密钥(B011，相当于公用密钥获取步骤)。OTA主机4通过RSA秘密密钥对进行了加密的AES密钥进行解密取出AES密钥(B012，相当于公用密钥解密步骤)。OTA主机4从CDN8下载并获取进行了加密的更新数据包(B013，相当于加密数据获取步骤)。

此时，OTA主机4与从CDN8下载并获取进行了加密的更新数据包并行地，通过AES密钥执行计数器值的AES块加密处理来对计数器值进行加密(B014，相当于块加密处理步骤)。OTA主机4对进行了加密的计数器值、和从CDN8下载的进行了加密的更新数据包进行XOR运算来进行解密(B015，相当于加密数据解密步骤)。OTA主机4将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B016，相当于安装处理步骤)。另外，不是通过CBC模式对更新数据包内的差分程序进行加密以及解密，而是通过CTR模式进行加密以及解密，从而对于目标ECU5中的解密处理也能够使吞吐量大约提高40％。

如以上说明的那样根据第一实施方式，能够得到以下的作用效果。

构成为采用CTR模式作为更新数据包的加密方式以及解密方式。相对于采用了CBC模式的以往技术，通过采用CTR模式，能够进行加密以及解密的前准备，能够进行加密以及解密的并列处理。由此，在OTA主机4从OTA中心2下载更新数据包时，能够享受CTR模式的优点，能够适当地提高吞吐量。

(第二实施方式)

参照图15～图26对第二实施方式进行说明。第一实施方式构成为采用CTR模式作为加密模式，但第二实施方式采用输出反馈模式(以下，称为OFB模式(Output-FeedBackmode))作为加密模式。

该情况下，数据包加密部2b通过生成的AES密钥以OFB模式对更新数据包进行加密。块加密处理部4d与加密数据包获取部4c从CDN8下载并获取进行了加密的更新数据包并行地，通过AES密钥执行基于IV(Initialization Vector：初始向量)值的AES流加密处理来对IV值进行加密。IV值是初始向量值，例如表示随机地生成的位串。加密数据包解密部4e对进行了加密的IV值、和从CDN8下载的进行了加密的更新数据包进行XOR运算来进行解密。

OFB模式的加密处理如图15所示，OFB模式的解密处理如图16所示。如图17所示，相对于作为CBC模式的缺点的“不能够进行加密以及解密的前准备”、“不能够进行加密的并列处理”，作为OFB模式的优点能够列举“能够进行加密以及解密的前准备，所以能够高速化”。即，作为采用OFB模式作为加密模式所带来的有助于吞吐量的提高的优点，如图18所示，与采用了一般的块加密的CBC模式的情况相比较，能够使吞吐量大约提高25％。

如图19所示，在CTR模式的解密处理中，由于输入为计数器值，所以能够从接收作为密文的更新数据包之前开始解密处理。另外，由于相互没有依赖关系，所以也能够同时并列执行多个加密运算。与此相对，如图20所示，在OFB模式的解密处理中，由于相互有依赖关系，所以不能够同时并列执行多个加密运算。但是，能够并列执行对进行了加密的IV值与进行了加密的更新数据包进行XOR运算来进行解密的处理。因此，在OFB模式的解密处理中，虽然不能够使吞吐量提高至在第一实施方式中进行了说明的CTR模式的解密处理的程度，但与采用了CBC模式的情况相比较，能够使吞吐量提高。

接下来，参照图21～图26对上述的构成的作用进行说明。

(2－1)OTA中心2的处理(参照图21～图23)

OTA中心2生成用于对更新数据包进行加密的AES密钥(A021，相当于公用密钥生成步骤)。OTA中心2通过生成的AES密钥以OFB模式对更新数据包进行加密(A022，相当于更新数据加密步骤)。OTA中心2通过RSA公开密钥对AES密钥进行加密(A023，相当于公用密钥加密步骤)。OTA中心2将通过RSA公开密钥进行了加密的AES密钥储存在活动通知中(A024，相当于公用密钥储存步骤)。OTA中心2将通过AES密钥进行了加密的更新数据包配置于CDN8(A025，相当于加密数据配置步骤)。OTA中心2将储存了进行了加密的AES密钥的活动通知发送到重编对象的车辆侧系统3(A026，相当于活动通知发送步骤)。

(2－2)OTA主机4的处理(参照图24～图26)

OTA主机4若由于在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取AES密钥(B021，相当于公用密钥获取步骤)。OTA主机4通过RSA秘密密钥对进行了加密的AES密钥进行解密取出AES密钥(B022，相当于公用密钥解密步骤)。OTA主机4从CDN8下载并获取进行了加密的更新数据包(B023，相当于加密数据获取步骤)。

此时，OTA主机4与从CDN8下载并获取进行了加密的更新数据包并行地，通过AES密钥执行基于IV值的AES流加密处理来对IV值进行加密(B024，相当于块加密处理步骤)。OTA主机4对进行了加密的IV值、和从CDN8下载的进行了加密的更新数据包进行XOR运算来进行解密(B025，相当于加密数据解密步骤)。OTA主机4将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B026，相当于安装处理步骤)。另外，不是通过CBC模式对更新数据包内的差分程序进行加密以及解密，而是通过OFB模式进行加密以及解密，从而对于目标ECU5中的解密处理也能够使吞吐量提高大约25％。

如以上说明的那样根据第二实施方式，能够得到以下的作用效果。

构成为采用OFB模式作为更新数据包的加密方式以及解密方式。相对于采用CBC模式的以往技术，通过采用OFB模式，能够进行加密以及解密的前准备。由此，在OTA主机4从OTA中心2下载更新数据包时，能够享受OFB模式的优点，能够适当地提高吞吐量。

(第三实施方式)

参照图27～图33对第三实施方式进行说明。第三实施方式采用超文本传输协议(以下，称为HTTP(Hypertext Transfer Protocol))，作为CDN8与OTA主机4之间的通信协议，通过向CDN8发送范围请求，并以流式传输方式下载更新数据包，与采用安全超文本传输协议(以下，称为HTTPS(Hypertext Transfer Protocol Secure))的情况相比实现分发成本的抑制。有根据CDN供应商，而在向CDN8的通信协议使用HTTP的情况和使用HTTPS的情况下CDN8的分发费用有差别的情况。在使用HTTPS的情况下，CDN8需要进行根据传输层安全(以下，称为TLS(Transport Layer Security))规定的握手处理、加密密钥交换处理、加密运算处理，而CDN8的CPU的处理负荷增大，所以HTTPS的分发费用成为与HTTP相比大约高三成的费用表格。因此，更新数据包的下载通过使用HTTP实现分发成本的抑制。在第三实施方式中，在从CDN8向车辆侧系统3分发更新数据包时不使用HTTPS。

该情况下，活动通知发送部2f在OTA中心4与OTA主机4之间建立了TLS通信之后，将储存了进行了加密的AES密钥的活动通知发送到重编对象的车辆侧系统3。公用密钥获取部4a若由于在建立了TLS通信之后，在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取AES密钥。加密数据包获取部4c向CDN8发送范围请求而指定下载对象的数据范围，通过流式传输方式从CDN8下载并获取进行了加密的更新数据包。安装处理部4f通过流式传输方式将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5。

另外，虽然在本实施方式中，对在OTA主机4中，通过流式传输方式从CDN8获取进行了加密的更新数据包的情况进行说明，但也可以通过储存方式从CDN8获取进行了加密的更新数据包。在流式传输方式中，在通信时包含报头信息，所以通过使用HTTP能够进一步抑制分发成本。

接下来，参照图28～图33对上述的构成的作用进行说明。

(3－1)OTA中心2的处理(参照图28～图30)

OTA中心2生成用于对更新数据包进行加密的AES密钥(A031)。OTA中心2通过生成的AES密钥以CTR模式对更新数据包进行加密(A032)。OTA中心2通过RSA公开密钥对AES密钥进行加密(A033)。OTA中心2将通过RSA公开密钥进行了加密的AES密钥储存在活动通知中(A034)。OTA中心2将通过AES密钥进行了加密的更新数据包配置于CDN8(A035)。OTA中心2在OTA中心4与OTA主机4之间建立了TLS通信之后，将储存了进行了加密的AES密钥的活动通知发送到重编对象的车辆侧系统3(A036)。

(3－2)OTA主机4的处理(参照图31～图33)

OTA主机4若由于在建立了TLS通信之后，在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取AES密钥(B031)。OTA主机4通过RSA秘密密钥对进行了加密的AES密钥进行解密取出AES密钥(B032)。OTA主机4向CDN8发送范围请求而指定下载对象的数据范围，通过流式传输方式从CDN8下载并获取进行了加密的更新数据包(B033)。即，OTA主机4通过指定下载对象的数据范围，通过分割流式传输方式从CDN8下载并获取更新数据包。

此时，OTA主机4与加密数据包获取部4c从CDN8下载并获取进行了加密的更新数据包并行地，通过AES密钥执行计数器值的AES块加密处理来对计数器值进行加密(B034)。OTA主机4对进行了加密的计数器值、和从CDN8下载的进行了加密的更新数据包进行XOR运算来进行解密(B035)。OTA主机4通过流式传输方式将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B036)。

如以上说明的那样根据第三实施方式，能够得到以下的作用效果。

构成为采用HTTP作为CDN8与OTA主机4之间的通信协议，OTA主机4通过向CDN8发送范围请求以流式传输方式从该CDN8下载更新数据包。由此，相对于采用HTTPS作为通信协议的以往技术，能够适当地抑制OTA主机4从OTA中心2下载更新数据包时的分发成本。

(第四实施方式)

参照图34～图38对第四实施方式进行说明。第四实施方式通过在得到来自用户的下载同意之前预先在后台执行全部的密钥流的计算，实现更新数据包的下载时的解密处理的高速化。

该情况下，如图35所示，OTA主机4除了公用密钥获取部4a、公用密钥解密部4b、加密数据包获取部4c、块加密处理部4d、加密数据包解密部4e、安装处理部4f之外，还具备密钥流计算部4g。密钥流计算部4g在得到来自用户的下载同意之前预先在后台执行全部的密钥流的计算。加密数据包获取部4c以得到了来自用户的下载同意为条件，从CDN8下载并获取进行了加密的更新数据包。加密数据包解密部4e对计算出的密钥流、和从CDN8下载的进行了加密的更新数据包进行XOR运算来进行解密。

接下来，参照图36～图38对上述的构成的作用进行说明。

(4－1)OTA中心2的处理

OTA中心2的处理与在第一实施方式中进行了说明的OTA中心2的处理(图9～图11)相同。

(4－2)OTA主机4的处理(参照图36～图38)

OTA主机4若由于在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取AES密钥(B041)。OTA主机4通过RSA秘密密钥对进行了加密的AES密钥进行解密取出AES密钥(B042)。OTA主机4在得到来自用户的下载同意之前预先在后台执行全部的密钥流的计算(B043)。对各个密钥流附加有识别信息，表示对进行了加密的更新数据包的应用顺序。

OTA主机4通过将活动通知分发到车辆侧系统3、用户所持有的智能手机等移动信息终端，在HMI(Human Machine Interface：人机界面)显示下载同意画面(B044)。OTA主机4以得到了来自用户的下载同意为条件，从CDN8下载并获取进行了加密的更新数据包(B045)。OTA主机4对预先计算出的密钥流、和从CDN8下载的进行了加密的更新数据包进行XOR运算来进行解密(B046)。OTA主机4将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B047)。

如以上说明的那样根据第四实施方式，能够得到以下的作用效果。

构成为在得到来自用户的下载同意之前预先在后台执行全部的密钥流的计算。由此，能够使OTA主机4中的更新数据包的解密处理高速化，能够提高OTA主机4从OTA中心2下载更新数据包时的吞吐量。

(第五实施方式)

参照图39～图42对第五实施方式进行说明。第四实施方式在得到来自用户的下载同意之前预先在后台执行全部的密钥流的计算，但第五实施方式在得到来自用户的下载同意之前预先在后台执行一部分的密钥流的计算。考虑CPU的缓冲存储器的存储器容量和AES加密运算的吞吐量来决定作为计算的对象的一部分的密钥流，成为能够保存于缓冲存储器的大小。

该情况下，密钥流计算部4g在得到来自用户的下载同意之前预先在后台执行一部分的密钥流的计算。密钥流计算部4g与加密数据包获取部4c从CDN8下载并获取进行了加密的更新数据包并行地，生成密钥流并追加到缓冲存储器。

接下来，参照图39～图42对上述的构成的作用进行说明。

(5－1)OTA中心2的处理

OTA中心2的处理与在第一实施方式进行了说明的OTA中心2的处理(图9～图11)相同。

(5－2)OTA主机4的处理(参照图39～图41)

OTA主机4若由于在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取AES密钥(B051)。OTA主机4通过RSA秘密密钥对进行了加密的AES密钥进行解密取出AES密钥(B052)。OTA主机4在得到来自用户的下载同意之前预先在后台执行一部分的密钥流的计算(B053)。

OTA主机4通过将活动通知分发到车辆侧系统3、用户所持有的智能手机等移动信息终端，在HMI显示下载同意画面(B054)。OTA主机4以得到了来自用户的下载同意为条件，从CDN8下载并获取进行了加密的更新数据包(B055)。OTA主机4对预先计算出的密钥流、和从CDN8下载的进行了加密的更新数据包进行XOR运算来进行解密(B056)。

此时，OTA主机4与从CDN8下载并获取进行了加密的更新数据包并行地，生成密钥流并追加到缓冲存储器(B057)，并计算剩余的密钥流。OTA主机4将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B058)。另外，存储器容量与访问速度的关系如图42所示，根据要求的访问速度来决定缓冲存储器的大小即可。

如以上说明的那样根据第五实施方式，能够得到以下的作用效果。

构成为在得到来自用户的下载同意之前预先在后台执行一部分的密钥流的计算。由此，能够节约OTA主机4的存储器使用量，并且使OTA主机4中的更新数据包的解密处理高速化，能够提高OTA主机4从OTA中心2下载更新数据包时的吞吐量。

(第六实施方式)

参照图43～图54对第六实施方式进行说明。第六实施方式通过使加密方式包含于重编策略元数据(以下，称为RP元数据)等并从OTA中心2发送到OTA主机4，由OTA主机4确定加密方式。从OTA中心2向OTA主机4发送的加密方式包含加密算法、加密密钥长度、加密模式、消息认证码(以下，称为MAC(Message Authentication Code))算法等。

RP元数据包含更新数据包的构成信息，即表示更新数据包的构成种类的信息，是用于通过由OTA主机4检查其数据内容来防止更新数据包的分发错误的数据。通过使RP元数据为分发、主机以及目标的三层结构，即使在转送方式、平台的类型、更新数据包的种类等增大的情况下，也能够灵活地定义它们并进行应对，能够进行目标ECU5的重编。另外，也可以通过使加密方式包含于下载元数据(以下，称为DL元数据)等并从OTA中心2发送到OTA主机4，由OTA主机4确定加密方式。DL元数据包含用于下载多个目标ECU5中的每一个的更新数据包的信息，是规定OTA主机4应该掌握的内容的数据。

如图44所示，OTA中心2除了公用密钥生成部2a、更新数据包加密部2b、公用密钥加密部2c、公用密钥储存部2d、加密数据包配置部2e、以及活动通知发送部2f之外，还具备RP元数据生成部2g、和RP元数据加密部2h。RP元数据生成部2g生成包含公用密钥加密方式的RP元数据。RP元数据加密部2h通过RSA公开密钥对RP元数据进行加密。

OTA主机4除了公用密钥获取部4a、公用密钥解密部4b、加密数据包获取部4c、块加密处理部4d、加密数据包解密部4e、以及安装处理部4f之外，还具备RP元数据获取部4h、RP元数据解密部4i、以及公用密钥加密方式确定部4j。RP元数据获取部4h从CDN8下载并获取进行了加密的RP元数据。RP元数据解密部4i通过RSA秘密密钥对进行了加密的RP元数据进行解密取出RP元数据。公用密钥加密方式确定部4j对RP元数据的内容进行解释确定公用密钥加密方式。

另外，到从CDN8向OTA中心2的更新数据包的分发为止的流程如以下那样。从OTA中心2向OTA主机4或者用户所持有的移动信息终端发送活动通知。其后，通过OTA主机4向CDN8进行访问，从CDN8向OTA主机4发送RP元数据以及DL元数据，从CDN8向OTA中心2分发更新数据包。

如图45所示，RP元数据以及DL元数据在更新数据包的下载之前从OTA中心2发送到OTA主机4。如图46～图47所示，RP元数据包含RP元数据版本、分发层、主机层、目标层的信息。各信息如以下那样。

(a)RP元数据版本

RP元数据的版本，例如是“1.0.0”、“2.0.0”等版本信息。

(b)分发层

(b－1)通信协议

与OTA中心2的通信所使用的协议，例如是表示Uptane(注册商标)、OMA－DM(OpenMobile Alliance-Device Management：开放移动联盟设备管理)等的信息。

(b－2)通信单元

更新数据包的分发路径，是表示表示为OTA主机4的蜂窝、智能手机、USB存储器等的信息。

(c)主机层

与OTA主机4相关的信息。

(c－1)PF

是表示OTA主机4的平台(PF)例如为AP(AUTOSAR Adaptive Platform：AUTOSAR自适应平台)、CP(AUTOSAR Classic Platform：AUTOSAR经典平台)、AGL(Automotive GradeLinux：汽车级Linux)、Android(注册商标)等的信息。对于用于分发与ECU的平台对应的更新数据包的数据包结构，在一般社团法人JASPAR的规格中，规定能够应用于在标准化组织AUTOSAR的静态OS上进行动作的经典平台(CP)的数据要求。另外，在AUTOSAR中，规定能够应用于在动态OS上进行动作的新的类型的自适应平台(AP)的数据要求。AGL是车载Linux(注册商标)，Android是Android Automotive OS。AP以及CP表示软件平台。软件平台也称为软件体系结构。在AP以及CP中，使用的操作系统、开发语言不同。在依据CP说明书进行动作的ECU和依据AP说明书进行动作的ECU中，能够接收的更新数据包的结构不同。这些更新数据包的结构的不同主要起因于ECU的处理性能的不同。一般而言，依据CP说明书进行动作的ECU的处理性能比较低，所以更新数据包所包含的规格数据等也以二进制数据记载，成为即使在处理性能较低的ECU中也容易进行解释以及处理的数据结构。另一方面，由于依据AP说明书进行动作的ECU的处理性能比较高，所以能够搭载对以某种语言记述的结构性的字符数据进行解析并转换为能够在程序中处理的数据结构的解析器功能，数据结构不是简单的二进制数据，而例如能够采用JSON(JavaScript Object Notation：JavaScript对象表示法)那样的面向对象的数据形式，所以成为灵活的数据结构。

(c－2)控制方式

基于根据特定的格式设定的参数进行处理的参数、没有特定的格式而以更自由的记载形式进行处理的脚本等信息。

(c－3)加密方式

包含加密算法、加密密钥长度、加密模式、Padding方式、加密密钥ID、签名算法、签名密钥ID、签名模式、散列算法、区域指定有无、偏移大小、保护数据大小的信息。

(d)目标层

与目标ECU5相关的信息。

(d－1)PF

与主机层相同。

(d－2)转送方式

储存方式、流式传输的任意一个。

(d－3)控制方式

与主机层相同。

(d－4)目标ID

选项。

(d－5)加密方式

与主机层相同。

接下来，参照图48～图54对上述的构成的作用进行说明。

(6－1)OTA中心2的处理(参照图48～图51)

OTA中心2生成用于对更新数据包进行加密的公用密钥(A061)。OTA中心2通过生成的公用密钥以特定的加密模式对更新数据包进行加密(A062)。OTA中心2通过RSA公开密钥对公用密钥进行加密(A063)。OTA中心2将通过RSA公开密钥进行了加密的公用密钥储存在活动通知中(A064)。OTA中心2生成包含公用密钥加密方式的RP元数据(A065)。OTA中心2通过RSA公开密钥对RP元数据进行加密(A066)。OTA中心2将通过公用密钥进行了加密的更新数据包和通过RSA公开密钥进行了加密的RP元数据配置于CDN8(A067)。OTA中心2将储存了进行了加密的公用密钥的活动通知发送到重编对象的车辆侧系统3(A068)。

(6－2)OTA主机4的处理(参照图52～图54)

OTA主机4若由于在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取公用密钥(B061)。OTA主机4通过RSA秘密密钥对进行了加密的公用密钥进行解密取出公用密钥(B062)。OTA主机4从CDN8下载并获取进行了加密的RP元数据(B063)。OTA主机4通过RSA秘密密钥对进行了加密的RP元数据进行解密取出RP元数据(B064)。OTA主机4对RP元数据的内容进行解释确定公用密钥加密方式(B065)。OTA主机4从CDN8下载并获取进行了加密的更新数据包(B066)。在此以后，若为采用CTR模式作为特定的加密模式的情况则OTA主机4进行在第一实施方式中进行了说明的步骤B014以后的处理，若为采用OFB模式作为特定的加密模式的情况则进行在第二实施方式中进行了说明的步骤B024以后的处理。在其以外的加密模式的情况下也相同，根据与加密模式对应的顺序，进行更新数据包的、解密、向目标ECU的数据的转送。

如以上进行说明的那样根据第六实施方式，能够得到以下的作用效果。

构成为使加密方式包含于RP元数据或者DL元数据并从OTA中心2发送到OTA主机4。由此，在OTA主机4中能够确定加密方式。

(第七实施方式)

参照图55～图67对第七实施方式进行说明。第七实施方式采用CCMP模式(Countermode with Cipher-block chaining Message authentication code Protocol：计数器模式密码块链信息认证码协议)作为通信路加密和数据篡改对策。

该情况下，如图56～图60所示，若对采用了CCMP模式的构成与作为现有方式采用了AES CBC－HMAC(Hashed Message Authentication Mode Code：散列消息认证码)SHA(Secure Hash Algorithm：安全散列算法)2的解密以及签名验证的构成进行比较，则虽然硬件加速器的处理时间都与主核的处理时间相比占支配地位，但通过采用CCMP模式能够使吞吐量提高。

如图61所示，OTA中心2除了公用密钥生成部2a、更新数据包加密部2b、公用密钥加密部2c、公用密钥储存部2d、加密数据包配置部2e、以及活动通知发送部2f之外，还具备MAC密钥生成部2i。MAC密钥生成部2i生成用于防止更新数据包的篡改的MAC。

OTA主机4除了公用密钥获取部4a、公用密钥解密部4b、加密数据包获取部4c、块加密处理部4d、加密数据包解密部4e、以及安装处理部4f之外，还具备MAC密钥获取部4k。MAC密钥获取部4k若由于在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取MAC密钥。

接下来，参照图62～图67对上述的构成的作用进行说明。

(7－1)OTA中心2的处理(参照图62～图64)

OTA中心2生成用于对更新数据包进行加密的AES密钥、和用于防止更新数据包的篡改的MAC密钥(A071)。OTA中心2通过生成的AES密钥和MAC密钥以CCMP模式对更新数据包进行加密，附加MAC(A072)。OTA中心2通过RSA公开密钥对AES密钥和MAC密钥进行加密(A073)。OTA中心2将通过RSA公开密钥进行了加密的AES密钥和MAC密钥储存在活动通知中(A074)。OTA中心2将通过AES密钥和MAC密钥进行了加密的更新数据包配置于CDN8(A075)。OTA中心2将储存了进行了加密的AES密钥和MAC密钥的活动通知发送到重编对象的车辆侧系统3(A076)。

(7－2)OTA主机4的处理(参照图65～图67)

OTA主机4若由于在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取AES密钥和MAC(B071)。OTA主机4通过RSA秘密密钥对进行了加密的AES密钥和MAC密钥进行解密取出AES密钥和MAC密钥(B017)。OTA主机4从CDN8下载并获取进行了加密的更新数据包(B073)。

此时，OTA主机4与从CDN8下载并获取进行了加密的更新数据包并行地，通过AES密钥执行计数器值的AES块加密处理对计数器值进行加密(B074)。OTA主机4对进行了加密的计数器值、和从CDN8下载的进行了加密的更新数据包进行XOR运算来进行解密(B075)。OTA主机4根据进行了解密的更新数据包的明文使用MAC密钥以AES－CBC模式生成MAC来进行验证(B076)。若MAC一致，则OTA主机4将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B077)。若MAC不一致，则OTA主机4结束处理。该情况下，OTA主机4也可以若由于MAC的不一致而结束处理，则记录表示由于MAC的不一致而结束了处理的日志，并且在未图示的HMI进行错误显示。或者，OTA主机4也可以对进行了加密的更新数据包进行XOR运算进行解密，与此同时将进行了解密的更新数据包转送至目标ECU5。该情况下，OTA主机4也可以构成为根据进行了解密的更新数据包的明文使用MAC密钥通过AES－CBC模式生成MAC并进行验证，在判定为MAC不一致的情况下，对目标ECU5通知安装的中止。

如以上说明的那样根据第七实施方式，能够得到以下的作用效果。

构成为采用CCMP模式作为OTA中心2与OTA主机4之间的通信路加密和数据篡改对策。通过采用CCMP模式，OTA主机4在从OTA中心2下载更新数据包时除了通信路加密之外还能够具备数据篡改对策。由此，能够提高安全，能够实现更安全的OTA分发。

(第八实施方式)

参照图68～图77对第八实施方式进行说明。第八实施方式采用GCMP模式(Galois/Counter Mode Protocol：伽罗瓦计数器模式协议)，作为通信路加密和数据篡改对策。

该情况下，如图69～图71所示，若对采用了GCMP模式的构成与采用了CCMP模式的构成、作为现有方式采用了AES CBC－HMAC SHA2的解密以及签名验证的构成进行比较，则虽然硬件加速器的处理时间都与主核的处理时间相比占支配地位，但通过采用GCMP模式能够使吞吐量进一步提高。

接下来，参照图72～图77对上述的构成的作用进行说明。

(8－1)OTA中心2的处理(参照图72～图74)

OTA中心2生成用于对更新数据包进行加密的AES密钥、和用于防止更新数据包的篡改的MAC密钥(A081)。OTA中心2通过生成的AES密钥和MAC密钥以GCMP模式对更新数据包进行加密，附加MAC(A082)。OTA中心2通过RSA公开密钥对AES密钥和MAC密钥进行加密(A083)。OTA中心2将通过RSA公开密钥进行了加密的AES密钥和MAC密钥储存在活动通知中(A084)。OTA中心2将通过AES密钥和MAC密钥进行了加密的更新数据包配置于CDN8(A085)。OTA中心2将储存了进行了加密的AES密钥和MAC密钥的活动通知发送至重编对象的车辆侧系统3(A086)。

(8－2)OTA主机4的处理(参照图75～图77)

OTA主机4若由于在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取AES密钥和MAC(B081)。OTA主机4通过RSA秘密密钥对进行了加密的AES密钥和MAC密钥进行解密取出AES密钥和MAC密钥(B082)。OTA主机4从CDN8下载并获取进行了加密的更新数据包(B083)。

此时，OTA主机4与从CDN8下载并获取进行了加密的更新数据包并行地，通过AES密钥执行计数器值的AES块加密处理来对计数器值进行加密(B084)。OTA主机4对进行了加密的计数器值、和从CDN8下载的进行了加密的更新数据包进行XOR运算来进行解密(B085)。OTA主机4根据进行了解密的更新数据包的明文使用MAC密钥以GMAC模式生成MAC并进行验证(B086)。若MAC一致，则OTA主机将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B087)。

如以上说明的那样根据第八实施方式，能够得到以下的作用效果。

构成为采用GCMP模式作为OTA中心2与OTA主机4之间的通信路加密和数据篡改对策。通过采用GCMP模式，OTA主机4在从OTA中心2下载更新数据包时除了通信路加密之外还能够具备数据篡改对策。由此，能够提高安全，能够实现更安全的OTA分发。

(第九实施方式)

参照图78～图86对第九实施方式进行说明。第九实施方式通过不仅采用CDN8，还采用智能手机、USB存储器等作为更新数据的分发路径，应对分发路径的多样性，来提高用户的OTA更新方式的自由度。智能手机、USB存储器相当于记录介质。其以后，例示智能手机、USB存储器作为存储介质进行说明，但也可以采用SD卡、微型SD卡、紧凑型闪存等作为存储介质。

接下来，参照图79～图86对上述的构成的作用进行说明。

(9－1)OTA中心2的处理(参照图79～图82)

OTA中心2生成用于对更新数据包进行加密的公用密钥(A091)。OTA中心2通过生成的公用密钥以特定的加密模式对更新数据包进行加密(A092)。OTA中心2通过RSA公开密钥对公用密钥进行加密(A093)。OTA中心2将通过RSA公开密钥进行了加密的公用密钥储存在活动通知中(A094)。OTA中心2生成包含公用密钥加密方式和分发路径的RP元数据(A095)。OTA中心2通过RSA公开密钥对RP元数据进行加密(A096)。OTA中心2将通过公用密钥进行了加密的更新数据包和通过RSA公开密钥进行了加密的RP元数据配置于CDN8(A097)。OTA中心2将储存了进行了加密的公用密钥的活动通知发送至重编对象的车辆侧系统3(A098)。

(9－2)OTA主机4的处理(参照图83～图86)

OTA主机4若由于在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取进行了加密的公用密钥(B091)。OTA主机4通过RSA秘密密钥对进行了加密的公用密钥进行解密取出公用密钥(B092)。OTA主机4从CDN8下载并获取进行了加密的RP元数据(B093)。OTA主机4通过RSA秘密密钥对进行了加密的RP元数据进行解密取出RP元数据(B094)。OTA主机4对RP元数据的内容进行解释确定公用密钥加密方式和分发路径(B095)。OTA主机4通过该确定出的分发路径获取进行了加密的更新数据包(B096)。即，OTA主机4在确定了智能手机作为分发路径的情况下，从CDN8经由智能手机以批量储存方式下载进行了加密的更新数据包。OTA主机4在确定了USB存储器作为分发路径的情况下，从CDN8经由USB存储器以批量储存方式下载进行了加密的更新数据包。其以后，若为采用了CTR模式作为特定的加密模式的情况则OTA主机4进行在第一实施方式进行了说明的步骤B014以后的处理，若为采用了OFB模式作为特定的加密模式的情况则进行在第二实施方式进行了说明的步骤B024以后的处理。

如以上说明的那样根据第九实施方式，能够得到以下的作用效果。

从CDN8经由智能手机或者USB存储器等记录介质获取更新数据包。能够使更新数据包的分发路径具有多样性，能够选择分发成本、可用性优越的分发路径。由此，能够适当地抑制OTA主机4从OTA中心2下载更新数据包时的分发成本，并且提高用户体验价值。另外，在上述的实施方式中，OTA主机4在步骤B095中对RP元数据的内容进行解释确定公用密钥加密方式和分发路径，但在RP元数据记载有多个分发路径的情况下，也可以能够从多个分发路径中选择任意一个。

(第十实施方式)

参照图87～图98对第十实施方式进行说明。第十实施方式根据分发方式、作为分发区域的OTA对象区域、分发数据大小动态地选定多个CDN供应商作为更新数据包的向CDN8的配置目的地，来抑制分发成本。CDN的成本比较如图88～图89所示。价格表格如图90～图93所示。各CDN供应商根据日本或者北美等分发区域、分发数据大小等而价格的优劣不同，例如若参照图90，则在一个月分发100TB的数据大小的情况下，在日本CDN2最便宜，但在北美或者EU则CDN1最便宜。基于该情况根据分发方式、OTA对象区域、分发数据大小选定分发成本最便宜的CDN供应商。

如图94所示，OTA中心2除了公用密钥生成部2a、更新数据包加密部2b、公用密钥加密部2c、公用密钥储存部2d、加密数据包配置部2e、以及活动通知发送部2f之外，还具备CDN供应商选定部2j。CDN供应商选定部2j参照CDN供应商管理数据库选定CDN供应商。

接下来，参照图95～图98对上述的构成的作用进行说明。

(10－1)OTA中心2的处理(参照图95～图98)

OTA中心2生成用于对更新数据包进行加密的AES密钥(A101)。OTA中心2通过生成的AES密钥以CTR模式对更新数据包进行加密(A102)。OTA中心2通过RSA公开密钥对AES密钥进行加密(A103)。OTA中心2将通过RSA公开密钥进行了加密的AES密钥储存在活动通知中(A104)。OTA中心2确定分发方式(A105)，确定OTA对象区域(A106)，确定分发数据大小(A107)，并从CDN供应商管理数据库以分发方式、OTA对象区域以及分发数据大小为关键词参照价格表格(A108)。该情况下，OTA中心2也可以以储存方式、流式传输方式等分发方式、日本、北美、EU(European Union：欧盟)等OTA对象区域、GB、TB、PB等分发数据大小中至少任意一个为关键词参照价格表格。OTA中心2按照区域选定分发成本最小的CDN供应商，并将通过AES密钥进行了加密的更新数据包配置于该选定的CDN8(A109，相当于CDN供应商选定步骤)。或者，OTA中心2也可以将通过AES密钥进行了加密的更新数据包配置于各CDN8。OTA中心2将储存了进行了加密的AES密钥、和用于能够访问选定的CDN供应商的更新数据包的数据储存目的地或者URI信息的活动通知发送到重编对象的车辆侧系统3(A110)。

(10－2)OTA主机4的处理

OTA主机4的处理与在第一实施方式中进行了说明的OTA主机4的处理(图12～图14)相同。

如以上说明的那样根据第十实施方式，能够得到以下的作用效果。

构成为参照CDN供应商管理数据库，根据分发方式、OTA对象区域以及分发数据大小从分发成本不同的多个CDN8中选定分发成本优越的CDN8，并将更新数据包配置于该选定的CDN8。能够适当地抑制OTA主机4从OTA中心2下载更新数据包时的分发成本。另外，通过在OTA中心2对更新数据包进行加密，在原理上即使对中途路径零信任，在安全上也没有妨碍。因此，没有在CDN8的边缘侧对更新数据进行加密的必要性，能够削减CDN8的处理负荷、安全功能。到更新数据包从OTA中心2到达OTA主机4为止，即使在中途路径数据篡改或者CDN8受到DDoS攻击，作为OTA系统也没有影响，介于中途路径的系统能够不需要智能的安全对策，例如网络应用防火墙、TLS通信、限定成为分发对象的OTA主机4的带签名的URL等多层防御的安全辅助对策。由此，能够以原价为基础降低OTA系统的运行成本，无论在哪个系统构成中都能够抑制分发成本。

(第十一实施方式)

参照图99～图108对第十一实施方式进行说明。第十一实施方式在OTA中心2与OTA主机4之间的密钥配送采用迪菲-赫尔曼密钥共享(以下，称为DHE(Diffie-Hellman keyexchange))或者椭圆曲线迪菲-赫尔曼密钥共享(以下，称为ECDHE(Elliptic curveDiffie-Hellman key exchange))，并且在OTA中心2中基于共享的按照每个车辆不同的秘密信息对AES密钥进行加密并分发给OTA主机4，从而在享受能够确保ECDHE的前向保密性这样的优点的同时，分发能够应用于CDN8的各车辆型号或者特定的车辆组能够应用的更新数据包。

如图100所示，两者根据随机数(＝秘密密钥：a、b)生成并交换各自的公开密钥(A、B)，并与自身的秘密密钥组合进行计算，从而秘密地共享秘密信息(S)。秘密密钥以及公开密钥对(a/A、b/B)在共享了秘密信息(S)之后能够废除，不需要在OTA中心2和OTA主机4双方储存于HSM(硬件安全模型)，所以能够非常安全地共享秘密信息(S)。该共享的秘密信息(S)能够有效利用于公用密钥加密的密钥等，但由于原始数据为随机数(a、b)，所以在每个OTA主机为不同的密钥。

接下来，参照图101～图108对上述的构成的作用进行说明。

(11－1)OTA中心2的处理(参照图101～图104)

OTA中心2生成用于对更新数据包进行加密的AES密钥(A111)。OTA中心2通过生成的AES密钥以CTR模式对更新数据包进行加密(A112)。OTA中心2根据随机数生成ECDHE的密钥对(A113)。OTA中心2通过ECDHE的算法与OTA主机4共享秘密密钥(A114，相当于秘密信息共享步骤)。OTA中心2通过秘密密钥对AES密钥进行加密(A115)。OTA中心2将通过秘密密钥进行了加密的AES密钥储存在活动通知中(A116)。OTA中心2将通过AES密钥进行了加密的更新数据包配置于CDN8(A117)。OTA中心2将储存了进行了加密的AES密钥的活动通知发送到重编对象的车辆侧系统3(A118，相当于加密密钥分发步骤)。

这里，对步骤A114进行说明。若车辆的点火开关接通，且从上次的车辆构成信息的同步起经过规定期间，则OTA主机4向搭载于车辆的ECU询问程序版本而收集车辆构成信息。或者OTA主机4若从OTA中心2接收与活动相关的推送通知，则向ECU询问程序版本而收集车辆构成信息。OTA主机4若收集车辆构成信息，则在与OTA中心2之间建立TLS通信，将车辆构成信息发送到OTA中心2。此时，OTA主机4在收集车辆构成信息的同时，生成ECDHE的密钥对，若在与OTA中心2之间建立TLS通信，则将密钥对中OTA主机4的公开密钥发送到OTA中心2。另外，OTA主机4收集车辆构成信息的工序也能够应用于其它的实施方式。OTA中心2基于从OTA主机4获取的OTA主机4的公开密钥和OTA中心2的秘密密钥获取ECDHE的算法的秘密密钥。

(11－2)OTA主机4的处理(参照图105～图108)

OTA主机4根据随机数生成ECDHE的密钥对(B111)。OTA主机4通过ECDHE的算法与OTA中心2共享秘密密钥(B112，相当于秘密信息共享步骤)。OTA主机4若由于在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取AES密钥(B113)。OTA主机4通过秘密密钥对进行了加密的AES密钥进行解密取出AES密钥(B114)。OTA主机4从CDN8下载并获取进行了加密的更新数据包(B115)。

此时，OTA主机4与从CDN8下载并获取进行了加密的更新数据包并行地，通过AES密钥执行计数器值的AES块加密处理对计数器值进行加密(B116)。OTA主机4对进行了加密的计数器值、和从CDN8下载的进行了加密的更新数据包进行XOR运算来进行解密(B117)。OTA主机4将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B118)。

如以上说明的那样根据第十一实施方式，能够得到以下的作用效果。

构成为OTA中心2与OTA主机4之间的密钥配送采用DHE或者ECDHE，在OTA中心2中基于共享的按照每个车辆不同的秘密信息对AES密钥进行加密并分发给OTA主机4。由此，能够在适当地确保ECDHE的前向保密性的同时，适当地实现基于CDN8的更新数据的高效的分发。

(第十一实施方式的变形例)

参照图166～图173对第十一实施方式的变形例进行说明。在第十一实施方式中，以无线通信装置搭载于车辆，OTA主机4能够经由无线通信线路与OTA中心2、CDN8发送接收数据为前提进行了说明。然而，也有无线通信装置未搭载于车辆的情况、用户不喜欢使用无线通信线路的情况。在第十一实施方式的变形例中，对OTA主机4不经由无线通信线路与OTA中心2、CDN8发送接收数据，而取而代之例如使用SD卡等存储介质实施程序更新的状况进行说明。

OTA主机4以及OTA中心2与外部的数据转送使用存储介质。OTA主机4与存储介质之间的数据转送使用设置于车辆的用于存储介质的端口。设置于车辆的端口例如是设置于车辆导航装置、中心显示器装置、其它的车辆控制装置的端口等。

将存储介质与个人计算机(以下，称为PC)连接来进行OTA中心2与存储介质之间的数据转送。例如将存储介质与PC连接，向OTA中心2或者CDN8的网站进行访问，通过对PC进行操作将保存于存储介质的数据上传到OTA中心2，或者通过对PC进行操作将保存于OTA中心2的数据下载到存储介质。另外，也能够代替PC而使用与存储介质对应的智能手机、平板终端等。也将与存储介质对应的PC、智能手机、平板终端等称为操作终端。

参照图166～图169，对使用了SD卡作为存储介质的情况进行说明。该情况下，按照从OTA主机4向SD卡11的数据的转送、从SD卡11向OTA中心2的数据的上传、从OTA中心2向SD卡11的数据的下载、从SD卡11向OTA主机4的数据的转送的顺序进行处理。

参照图166，对从OTA主机4向SD卡11的数据的转送进行说明。OTA主机4从目标ECU5获取软件版本信息等，将该获取的软件版本信息等作为车辆构成信息转送并保存于SD卡11。OTA主机4根据随机数生成ECDHE的密钥对，并将ECDHE公开密钥转送并保存到SD卡11。SD卡11保存从OTA主机4转送的车辆构成信息以及OTA主机4的ECDHE公开密钥。

参照图167，对从连接了SD卡11的PC向OTA中心2的数据的上传进行说明。PC若连接SD卡11，则读出保存于SD卡11的车辆构成信息以及OTA主机4的ECDHE公开密钥，并将该读出的车辆构成信息以及OTA主机4的ECDHE公开密钥上传至OTA中心2。上传到OTA中心2的车辆构成信息在PKG生成服务器6中使用于活动有无的判定。上传到OTA中心2的OTA主机4的ECDHE公开密钥在分发服务器7中基于ECDHE的算法共享秘密密钥。该情况下的秘密密钥是按照每个车辆不同的秘密密钥。

参照图168，对从OTA中心2向SD卡11的数据的下载进行说明。这里示出有活动的情况。OTA中心2将通过AES密钥进行了加密的更新数据包下载并保存到SD卡11。OTA中心2根据随机数生成ECDHE的密钥对，并将应该与OTA主机4共享的密钥(OTA中心2的ECDHE公开密钥)下载并保存到SD卡11。OTA中心2将储存了进行了加密的AES密钥的活动通知下载并保存到SD卡11。SD卡11保存从OTA中心2下载的更新数据包、OTA中心2的ECDHE公开密钥以及进行了加密的AES密钥。

参照图169，对从SD卡11向OTA主机4的数据的转送进行说明。OTA主机4从SD卡11读出并获取保存于SD卡11的进行了加密的更新数据包、OTA中心2的ECDHE公开密钥以及进行了加密的AES密钥。

接下来，参照图170～图174对上述的构成的作用进行说明。

(11－3)OTA主机4的处理(参照图170)

若SD卡11与车辆侧系统3连接，且满足规定条件，则OTA主机4向目标ECU5要求软件版本信息等构成信息的发送，并获取从目标ECU5发送的软件版本信息等构成信息作为车辆构成信息(B1111)。OTA主机4若获取车辆构成信息，则将该获取的车辆构成信息转送并保存到SD卡11(B1112)。OTA主机4根据随机数生成ECDHE的密钥对(B1113)。该情况下，密钥对包含OTA主机4的ECDHE公开密钥和ECDHE秘密密钥。OTA主机4将OTA主机4的ECDHE公开密钥转送并保存到SD卡11(B1114)。SD卡11若像这样保存车辆构成信息以及OTA主机4的ECDHE公开密钥，则解除与车辆侧系统3的连接，并与PC连接。

(11－4)PC的处理(参照图171)

PC若连接SD卡11，则读出保存于SD卡11的车辆构成信息以及OTA主机4的ECDHE公开密钥，并将该读出的车辆构成信息以及OTA主机4的ECDHE公开密钥上传至OTA中心2(C1111)。PC等待从OTA中心2接收OTA主机4的ECDHE公开密钥、储存AES密钥的活动通知、进行了加密的更新数据包，并且等待没有活动的通知的接收(C1112、C1113)。PC若判定为从OTA中心2接收了OTA主机4的ECDHE公开密钥、储存AES密钥的活动通知、进行了加密的更新数据包(C1112：是)，或者若判定为接收了没有活动的通知(C1113：是)，则结束处理。

(11－5)OTA中心2的处理(参照图172)

OTA中心2生成用于对更新数据包进行加密的AES密钥，并通过AES密钥以CTR模式对更新数据包进行加密。OTA中心2获取从连接有SD卡11的PC上传的车辆构成信息以及OTA主机4的ECDHE公开密钥(A1111)。OTA中心2基于车辆构成信息判定是否有活动(A1112)。OTA中心2若判定为没有活动(A1112：否)，则向PC发送没有活动的通知(A1113)，并结束处理。

OTA中心2若判定为有活动(A1112：是)，则根据随机数生成ECDHE的密钥对(A1114)。该情况下，密钥对为OTA中心2的ECDHE公开密钥和ECDHE秘密密钥。OTA中心2将OTA中心2的ECDHE公开密钥下载并保存到SD卡11(A1115)。OTA中心2根据OTA中心2的ECDHE秘密密钥和OTA主机4的ECDHE公开密钥生成ECDHE公用密钥(秘密密钥)(A1116)，并通过该生成的ECDHE公用密钥(秘密密钥)对AES密钥进行加密(A1117)。OTA中心2将该进行了加密的AES密钥储存于活动通知，并将储存了该进行了加密的AES密钥的活动通知下载并保存到SD卡11(A1118)。OTA中心2将进行了加密的更新数据包下载并保存到SD卡11(A1119)。

(11－6)OTA主机4的处理(参照图173)

若SD卡11与车辆侧系统3连接，则OTA主机4从SD卡11获取OTA中心2的ECDHE公开密钥、活动通知、更新数据包(B1121)。OTA主机4根据OTA主机4的ECDHE秘密密钥和OTA中心2的ECDHE公开密钥生成ECDHE公用密钥(秘密密钥)(B1122)。OTA主机4从活动通知取出进行了加密的AES密钥，并通过ECDHE公用密钥(秘密密钥)进行解密(B1123)。OTA主机4通过AES密钥执行计数器值的AES块加密处理来对计数器值进行加密(B1124)。OTA主机4对进行了加密的计数器值与进行了加密的更新数据包进行XOR运算来进行解密(B1125)。OTA主机4将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B1126)。

根据这样的构成，能够不依赖于车辆侧系统3的无线通信功能，而在适当地确保ECDHE的前向保密性的同时，适当地实现基于CDN8的更新数据的高效的分发。另外，通过抑制OTA主机4与SD卡11之间的数据转送、OTA中心2与SD卡11之间的上传、下载的次数，能够提高对于用户来说的便利性。

(第十二实施方式)

参照图109～图115对第十二实施方式进行说明。第十二实施方式在ECDHE的密钥共享中，通过使OTA中心2生成的随机数a为每个车辆型号的随机数(基于特定的规则的随机数)，并利用每个车辆型号的固定值，计数值，或者OTA主机4的软件版本的散列值的任意一个，或者它们的组合作为在OTA主机4生成的随机数b，在每个车辆型号共用通过ECDHE共享的秘密密钥，在享受确保ECDHE的前向保密性的优点的同时，省略配送密钥的处理，对各车辆型号或者特定的车辆组能够应用的加密数据包进行CDN分发。

接下来，参照图110～图115对上述的构成的作用进行说明。

(12－1)OTA中心2的处理(参照图110～图112)

OTA中心2根据在每个车辆型号或者每个车辆组共用的随机数生成ECDHE的密钥对(A121)。OTA中心2通过ECDHE的算法与OTA主机4共享秘密密钥(A122，相当于秘密信息共享步骤)。在本实施方式中，通过ECDHE的算法与OTA主机4共享的秘密密钥作为用于对更新数据包进行加密的AES密钥使用。并且，OTA主机4使用与OTA中心2共享的秘密密钥，作为用于对进行了加密的更新数据包进行解密的AES密钥。OTA中心2生成用于对更新数据包进行加密的AES密钥(A123)。OTA中心2通过生成的AES密钥以CTR模式对更新数据包进行加密(A124)。OTA中心2将通过AES密钥进行了加密的更新数据包配置于CDN8(A125)。OTA中心2将储存了进行了加密的AES密钥的活动通知发送到重编对象的车辆侧系统3(A126，相当于加密密钥分发步骤)。

(12－2)OTA主机4的处理(参照图113～图115)

OTA主机4根据在上述进行了说明的根据特定的规则生成的随机数生成ECDHE的密钥对(B121)。OTA中心2通过ECDHE的算法与OTA中心2共享秘密密钥(B122，相当于秘密信息共享步骤)。OTA主机4从CDN8下载并获取进行了加密的更新数据包(B123)。

此时，OTA主机4与从CDN8下载并获取进行了加密的更新数据包并行地，通过AES密钥执行计数器值的AES块加密处理来对计数器值进行加密(B124)。OTA主机4对进行了加密的计数器值、和从CDN8下载的进行了加密的更新数据包进行XOR运算来进行解密(B125)。OTA主机4将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B126)。

如以上说明的那样根据第十二实施方式，能够得到以下的作用效果。

构成为OTA中心2与OTA主机4之间的密钥配送采用DHE或者ECDHE，在每个车辆型号共用通过ECDHE共享的秘密密钥。由此，能够在适当地确保ECDHE的前向保密性的同时，与第十一实施方式相比简化密钥配送的工作，并且适当地实现基于CDN8的更新数据的高效的分发。

(第十二实施方式的变形例)

参照图174～图181对第十二实施方式的变形例进行说明。在第十二实施方式的变形例中，也与第十一实施方式的变形例相同，对OTA主机4不经由无线通信线路与OTA中心2、CDN8发送接收数据，而取而代之例如使用SD卡等存储介质实施程序更新的状况进行说明。

参照图174，对从OTA主机4向SD卡11的数据的转送进行说明。OTA主机4从目标ECU5获取软件版本信息等，并将该获取的软件版本信息等作为车辆构成信息转送并保存于SD卡11。OTA主机4利用每个车辆型号的固定值，计数值，或者OTA主机4的软件版本的散列值的任意一个，或者它们的组合生成在每个车辆型号共用的ECDHE的密钥对，并将应该与OTA中心2共享的密钥(OTA主机4的ECDHE公开密钥)转送并保存到SD卡11。每个车辆型号的固定值、计数值，或者OTA主机4的软件版本的散列值的任意一个，或者它们的组合相当于特定的规则。SD卡11保存从OTA主机4转送的车辆构成信息以及OTA主机4的ECDHE公开密钥。

参照图175，对从连接了SD卡11的PC向OTA中心2的数据的上传进行说明。PC若连接SD卡11，则读出保存于SD卡11的车辆构成信息以及OTA主机4的ECDHE公开密钥，并将该读出的车辆构成信息以及OTA主机4的ECDHE公开密钥上传至OTA中心2。上传到OTA中心2的车辆构成信息在PKG生成服务器6中使用于活动有无的判定。另外，上传到OTA中心2的OTA主机4的ECDHE公开密钥在分发服务器7中基于ECDHE的算法共享秘密密钥。该情况下的秘密密钥是每个车辆型号共用的秘密密钥。

参照图176，对从OTA中心2向SD卡11的数据的下载进行说明。OTA中心2根据在每个车辆型号或者每个车辆组共用的随机数生成ECDHE的密钥对，并将应该与OTA主机4共享的密钥(OTA中心2的ECDHE公开密钥)下载并保存到SD卡11。OTA中心2通过使用通过ECDHE共享的秘密密钥作为AES密钥来对更新数据包进行加密，并将进行了加密的更新数据包下载并保存到SD卡11。SD卡11保存从OTA中心2下载的OTA中心2的ECDHE公开密钥、更新数据包。

参照图177，对从SD卡11向OTA主机4的数据的转送进行说明。OTA主机4读出并获取保存于SD卡11的进行了加密的更新数据包以及OTA中心2的ECDHE公开密钥。OTA主机4基于ECDHE的算法共享秘密密钥。OTA主机4使用通过ECDHE共享的秘密密钥作为AES密钥，对进行了加密的更新数据包进行解密。

接下来，参照图178～图181对上述的构成的作用进行说明。

(12－3)OTA主机4的处理(参照图178)

若SD卡11与车辆侧系统3连接，且满足规定条件，则OTA主机4向目标ECU5要求软件版本信息等构成信息的发送，并获取从目标ECU5发送的软件版本信息等构成信息作为车辆构成信息(B1211)。OTA主机4若获取车辆构成信息，则将该获取的车辆构成信息转送并保存至SD卡11(B1212)。OTA主机4根据基于特定的规则生成的随机数生成ECDHE的密钥对(B1213)。该情况下，密钥对包含OTA主机4的ECDHE公开密钥和ECDHE秘密密钥。OTA主机4将OTA主机4的ECDHE公开密钥转送并保存至SD卡11(B1214)。ECDHE的密钥对与第十二实施方式相同是根据特定的规则生成的随机数且在每个车辆型号共用。SD卡11若像这样保存车辆构成信息以及OTA主机4的ECDHE公开密钥，则解除与车辆侧系统3的连接，并与PC连接。

(12－4)PC的处理(参照图179)

PC若连接SD卡11，则读出保存于SD卡11的车辆构成信息以及OTA主机4的ECDHE公开密钥，并将该读出的车辆构成信息以及OTA主机4的ECDHE公开密钥上传至OTA中心2(C1211)。PC等待从OTA中心2接收储存OTA主机4的ECDHE公开密钥的活动通知、进行了加密的更新数据包，并且等待没有活动的通知的接收(C1212，C1213)。PC若判定为从OTA中心2接收了储存OTA主机4的ECDHE公开密钥的活动通知、进行了加密的更新数据包(C1212：是)，或者若判定为接收了没有活动的通知(C1213：是)，则结束处理。

(12－5)OTA中心2的处理(参照图180)

OTA中心2获取从连接SD卡11的PC上传的车辆构成信息以及OTA主机4的ECDHE公开密钥(A1211)。OTA中心2基于车辆构成信息判定是否有活动(A1212)。OTA中心2若判定为没有活动(A1212：否)，则向PC发送没有活动的通知(A1213)，并结束处理。

OTA中心2若判定为有活动(A1212：是)，则根据在每个车辆型号或者每个车辆组共用的随机数生成ECDHE的密钥对(A1214)。该情况下，密钥对是OTA中心2的ECDHE公开密钥和ECDHE秘密密钥。OTA中心2将OTA中心2的ECDHE公开密钥下载并保存到SD卡11(A1215)。OTA中心2根据OTA中心2的ECDHE秘密密钥和OTA主机4的ECDHE公开密钥生成ECDHE公用密钥(秘密密钥)(A1216)，并通过该生成的ECDHE公用密钥(秘密密钥)对更新数据包进行加密(A1217)。OTA中心2将进行了加密的更新数据包下载并保存至SD卡11(A1218)。

(12－6)OTA主机4的处理(参照图181)

若SD卡11与车辆侧系统3连接，则OTA主机4从SD卡11获取OTA中心2的ECDHE公开密钥、更新数据包(B1221)。OTA主机4根据OTA主机4的ECDHE秘密密钥和OTA中心2的ECDHE公开密钥生成ECDHE公用密钥(秘密密钥)(B1222)。OTA主机4通过AES密钥执行计数器值的AES块加密处理来对计数器值进行加密(B1223)。OTA主机4对进行了加密的计数器值和进行了加密的更新数据包进行XOR运算来进行解密(B1224)。OTA主机4将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B1225)。

根据这样的构成，能够不依赖于车辆侧系统3的无线通信功能，而在适当地确保ECDHE的前向保密性的同时，与第十一实施方式相比简化密钥配送的工作，并且适当地实现基于CDN8的更新数据的高效的分发。另外，通过抑制OTA主机4与SD卡11之间的数据转送、OTA中心2与SD卡11之间的上传、下载的次数，能够提高对于用户来说的便利性。

(第十三实施方式)

参照图116～图124对第十三实施方式进行说明。第十三实施方式并不是简单地应用CTR模式，而通过对计数器值进行研究，使之更安全。具体而言，通过在OTA中心2与OTA主机4之间首次通信的活动通知中加入Nonce，在计数器值加入Nonce，实现CTR模式的安全化。CTR模式的加入Nonce的加密处理如图117所示，CTR模式的加入Nonce的解密处理如图118所示。

接下来，参照图119～图124对上述的构成的作用进行说明。

(13－1)OTA中心2的处理(参照图119～图121)

OTA中心2生成用于对更新数据包进行加密的AES密钥(A131)。OTA中心2生成基于随机数的Nonce(A132)。OTA中心2通过生成的AES密钥和Nonce以CTR模式对更新数据包进行加密(A133)。OTA中心2通过RSA公开密钥对AES密钥进行加密(A134)。也可以OTA中心2在通过RSA公开密钥对AES密钥进行加密的同时，也通过RSA公开密钥对Nonce进行加密。OTA中心2将通过RSA公开密钥进行了加密的AES密钥和Nonce储存在活动通知中(A135)。OTA中心2将通过AES密钥进行了加密的更新数据包配置于CDN8(A136)。OTA中心2将储存了进行了加密的AES密钥和Nonce的活动通知发送到重编对象的车辆侧系统3(A137)。

(13－2)OTA主机4的处理(参照图122～图124)

OTA主机4若由于在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取AES密钥和Nonce(B131)。OTA主机4通过RSA秘密密钥对进行了加密的AES密钥进行解密取出AES密钥(B132)。OTA主机4从CDN8下载并获取进行了加密的更新数据包(B133)。OTA主机4通过AES密钥和Nonce对从CDN8下载的进行了加密的更新数据包进行解密(B134)。OTA主机4将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B135)。

如以上说明的那样根据第十三实施方式，能够得到以下的作用效果。

构成为在OTA中心2与OTA主机4之间首次通信的活动通知中加入Nonce，在计数器值加入Nonce。由此，通过在计数器值加入Nonce，能够实现CTR模式的安全化。

(第十四实施方式)

参照图125～图132对第十四实施方式进行说明。第十四实施方式对于用于加密的密钥，为了缩小密钥危险化时的影响范围，不在全部的车辆使用共用的密钥，而使用按照特定的车辆组的单位个体化的派生密钥，从而在维持CDN8的分发缓存效率的同时使密钥泄漏时的损失局部化，更安全地进行OTA分发。如图126所示，针对同一车辆型号以及年款将VIN编号划分为多个，且每个分区使用不同的AES专用密钥。例如按照VIN编号AAA～CCC、VIN编号DDD～KKK、VIN编号SSS～ZZZ进行划分，使用不同的AES专用密钥。专用密钥数据库例如包含OEM码、车辆型号、年款、AES主密钥、种子值、根据VIN编号划分的AES专用密钥。

接下来，参照图127～图132对上述的构成的作用进行说明。

(14－1)OTA中心2的处理(参照图127～图129)

OTA中心2根据AES主密钥和种子值生成用于对更新数据包进行加密的AES专用密钥(A141)。种子值例如是随机数、计数器值、时间戳等。OTA中心2通过生成的AES专用密钥之一和Nonce以CTR模式对更新数据包进行加密(A142)。OTA中心2通过RSA公开密钥对AES专用密钥进行加密(A143)。OTA中心2将通过RSA公开密钥进行了加密的AES专用密钥和Nonce储存在活动通知中(A144)。OTA中心2将通过AES专用密钥之一和Nonce进行了加密的更新数据包配置于CDN8(A145)。OTA中心2将储存了进行了加密的AES专用密钥和Nonce的活动通知发送到重编对象的车辆侧系统3(A146)。

(14－2)OTA主机4的处理(参照图130～图132)

OTA主机4若由于在OTA主机4接收了从OTA中心2发送的活动通知而获取活动通知，则从该获取的活动通知中获取AES专用密钥和Nonce(B141)。OTA主机4通过RSA秘密密钥对进行了加密的AES专用密钥进行解密取出AES专用密钥(B142)。OTA主机4从CDN8下载并获取进行了加密的更新数据包(B143)。OTA主机4通过AES专用密钥和Nonce对从CDN8下载的进行了加密的更新数据包进行解密(B144)。OTA主机4将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B145)。

如以上说明的那样根据第十四实施方式，能够得到以下的作用效果。

构成为对于用于加密的密钥来说并不在全部的车辆中使用共用的密钥，而使用按照特定的车辆组的单位进行了个体化的派生密钥。能够在维持CDN8的分发缓存效率的同时使密钥泄漏时的损失局部化。由此，能够提高OTA主机4从OTA中心2下载更新数据包时的安全性，能够实现更安全的OTA分发。

(第十五实施方式)

参照图133～图137对第十五实施方式进行说明。第十五实施方式防备作为最差的事态的秘密密钥泄漏的情况而附加密钥版本在OTA中心2中进行管理，并且在OTA主机的HSM区域储存密钥更新用密钥以能够在OTA进行密钥更新。OTA中心2管理AES密钥的加密所使用的RSA公开密钥和其解密所使用的RSA秘密密钥的版本信息。通过管理版本信息，在更新RSA秘密密钥以及RSA公开密钥时不会降级。OTA中心2和OTA主机4具备在秘密密钥的更新时使用的密钥更新用密钥。在OTA中心2中，在秘密密钥泄漏时或者以定期间隔生成新的秘密密钥对，并且使用密钥更新用密钥生成密钥更新数据包，并将密钥更新数据包发送至OTA主机4，从而实现秘密密钥的密钥更新。

接下来，参照图134～图137对上述的构成的作用进行说明。

(15－1)OTA中心2的处理(参照图134～图135)

OTA中心2生成新RSA秘密密钥和新RSA公开密钥的新的密钥对(A151)。OTA中心2通过密钥更新用密钥以CTR模式对生成的新RSA秘密密钥进行加密以及MAC运算，生成密钥更新数据包(A152)。OTA中心2将旧RSA公开密钥切换为新RSA公开密钥(A153)。OTA中心2将密钥更新数据包发送到重编对象的车辆侧系统3(A154)。

(15－2)OTA主机4的处理(参照图136～图137)

OTA主机4获取密钥更新数据包，通过密钥更新用密钥以CTR模式对新RSA秘密密钥进行解密以及MAC验证(B151)。OTA主机4将旧RSA秘密密钥切换为进行了解密的新RSA秘密密钥(B152)。

如以上说明的那样根据第十五实施方式，能够得到以下的作用效果。

构成为在秘密密钥泄漏时或者以定期间隔生成新的秘密密钥对，并且使用密钥更新用密钥生成密钥更新数据包，并将密钥更新数据包发送到OTA主机4。由此，通过进行秘密密钥的密钥更新，能够提高OTA主机4从OTA中心2下载更新数据包时的安全性，能够实现更安全的OTA分发。

(第十六实施方式)

参照图138～图145对第十六实施方式进行说明。第十六实施方式在ECDHE的密钥共享时，为了对抗中间人攻击而安全地对附加数字签名且能够应用于加密数据包的密钥实现OTA中心2与OTA主机4之间的密钥共享。如图139～图140所示，DHE对于来自中间攻击者的攻击较脆弱，但通过附加数字签名对抗来自中间攻击者的攻击。作为数字签名使用使用了RSA或者椭圆曲线DSA的加密算法的数字签名。

接下来，参照图141～图145对上述的构成的作用进行说明。

(16－1)OTA中心2的处理(参照图141～图143)

OTA中心2根据按照车辆型号或者按照车辆组制成的随机数生成ECDHE的密钥对(A161)。OTA中心2通过RSA秘密密钥对ECDHE密钥附加数字签名(A162)。这里，虽然是RSA秘密密钥，但并不限定于RSA秘密密钥，只要是公开密钥加密方式则能够代替，例如也可以是ECDSA(Elliptic Curve Digital Signature Algorithm：椭圆曲线数字签名算法)秘密密钥。OTA中心2将附加了数字签名的ECDHE公开密钥发送到重编对象的车辆侧系统3(A163)。OTA中心2通过ECDHE的算法与OTA主机4共享秘密密钥(A164)。OTA中心2生成用于对更新数据包进行加密的AES密钥(A165)。OTA中心2通过生成的AES密钥以CTR模式对更新数据包进行加密(A166)。OTA中心2将通过AES密钥进行了加密的更新数据包配置于CDN8(A167)。OTA中心2将储存了进行了加密的AES密钥的活动通知发送到重编对象的车辆侧系统3(A168)。

(16－2)OTA主机4的处理(参照图144～图145)

OTA主机4根据基于特定的规则生成的随机数生成ECDHE的密钥对(B161)。OTA主机4通过RSA公开密钥对从OTA中心2接收的ECDHE公开密钥进行数字签名验证(B162)。这里也与OTA中心2相同，并不限定于RSA公开密钥，只要是公开密钥加密方式则能够代替，例如也可以是ECDSA公开密钥。若验证结果正确，则OTA主机4通过ECDHE的算法与OTA中心2共享秘密密钥(B163)。其以后，OTA主机4进行在第十一实施方式中进行了说明的步骤B113以后的处理。

如以上说明的那样根据第十六实施方式，能够得到以下的作用效果。

构成为在ECDHE的密钥共享时附加数字签名。由此，通过附加数字签名，能够对抗来自中间攻击者的攻击，能够实现更安全的OTA分发。

(第十六实施方式的变形例)

参照图182～图189对第十六实施方式的变形例进行说明。在第十六实施方式的变形例中，也与第十一实施方式以及第十二实施方式的变形例相同，对OTA主机4不经由无线通信线路与OTA中心2、CDN8发送接收数据，而取而代之例如使用SD卡等存储介质实施程序更新的状况进行说明。第十六实施方式的变形例中的与第十二实施方式的变形例的主要的不同在于通过利用公开密钥加密方式的密钥对OTA中心2的ECDHE公开密钥实施数字签名来对抗来自中间攻击者的攻击这一点。

在图182～图185中，分别示出从OTA主机4向SD卡11的数据的转送、从连接了SD卡11的PC向OTA中心2的数据的上传、从OTA中心2向SD卡11的数据的下载、从SD卡11向OTA主机4的数据的转送。与第十二实施方式的变形例的主要的不同如图184所示，OTA中心2通过公开密钥加密方式的密钥，例如RSA秘密密钥或者ECDSA秘密密钥对应该与OTA主机4共享的密钥(OTA中心2的ECDHE公开密钥)附加数字签名。OTA中心2将带签名的ECDHE公开密钥转送并保存到SD卡11。另外，如图185所示，OTA主机4从SD卡11读出带签名的ECDHE公开密钥，并使用保存于车辆侧系统3的RSA公开密钥进行验证。

接下来，参照图186～图189对上述的构成的作用进行说明。

(16－3)OTA主机4的处理(参照图186)

若SD卡11与车辆侧系统3连接，且满足规定条件，则OTA主机4向目标ECU5要求软件版本信息等构成信息的发送，并获取从目标ECU5发送的软件版本信息等构成信息作为车辆构成信息(B1611)。OTA主机4若获取车辆构成信息，则将该获取的车辆构成信息转送并保存至SD卡11(B1612)。OTA主机4根据基于特定的规则生成的随机数生成ECDHE的密钥对(B1613)。该情况下，密钥对包含OTA主机4的ECDHE公开密钥和ECDHE秘密密钥。OTA主机4将OTA主机4的ECDHE公开密钥转送并保存至SD卡11(B1614)。ECDHE的密钥对与第十二实施方式相同是根据特定的规则生成的随机数且对每个车辆型号共用。SD卡11若像这样保存车辆构成信息以及OTA主机4的ECDHE公开密钥，则解除与车辆侧系统3的连接，并与PC连接。

(16－4)PC的处理(参照图187)

PC若连接SD卡11，则读出保存于SD卡11的车辆构成信息以及OTA主机4的ECDHE公开密钥，并将该读出的车辆构成信息以及OTA主机4的ECDHE公开密钥上传至OTA中心2(C1611)。PC等待从OTA中心2接收储存OTA主机4的ECDHE公开密钥的活动通知、进行了加密的更新数据包，并且等待没有活动的通知的接收(C1612，C1613)。PC若判定为从OTA中心2接收了储存OTA主机4的ECDHE公开密钥的活动通知、进行了加密的更新数据包(C1612：是)，或者若判定为接收了没有活动的通知(C1613：是)，则结束处理。

(16－5)OTA中心2的处理(参照图188)

OTA中心2获取从连接SD卡11的PC上传的车辆构成信息以及OTA主机4的ECDHE公开密钥(A1611)。OTA中心2基于车辆构成信息判定是否有活动(A1612)。OTA中心2若判定为没有活动(A1612：否)，则向PC发送没有活动的通知(A1613)，并结束处理。

OTA中心2若判定为有活动(A1612：是)，则根据在每个车辆型号或者每个车辆组共用的随机数生成ECDHE的密钥对(A1614)。该情况下，密钥对是OTA中心2的ECDHE公开密钥和ECDHE秘密密钥。OTA中心2通过RSA秘密密钥对OTA中心2的ECDHE公开密钥进行签名(A1615)，并将签名完毕的OTA中心2的ECDHE公开密钥下载并保存至SD卡11(A1616)。OTA中心2根据OTA中心2的ECDHE秘密密钥和OTA主机4的ECDHE公开密钥生成ECDHE公用密钥(秘密密钥)(A1617)，并通过该生成的ECDHE公用密钥(秘密密钥)对更新数据包进行加密(A1618)。OTA中心2将进行了加密的更新数据包下载并保存到SD卡11(A1619)。

(16－6)OTA主机4的处理(参照图189)

若SD卡11与车辆侧系统3连接，则OTA主机4从SD卡11获取签名完毕的OTA中心2的ECDHE公开密钥、更新数据包(B1621)。OTA主机4通过RSA公开密钥对签名完毕的OTA中心2的ECDHE公开密钥进行验证(B1622)。OTA主机4判定验证结果是否正常(B1623)，若判定为验证结果不正常而异常(B1623：否)，则进行错误通知(B1624)。

OTA主机4若判定为验证结果正常(B1623：是)，则根据OTA主机4的ECDHE秘密密钥和OTA中心2的ECDHE公开密钥生成ECDHE公用密钥(秘密密钥)(B1625)。OTA主机4通过AES密钥执行计数器值的AES块加密处理来对计数器值进行加密(B1626)。OTA主机4对进行了加密的计数器值、和进行了加密的更新数据包进行XOR运算来进行解密(B1627)。OTA主机4将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B1628)。

根据这样的构成，能够不依赖于车辆侧系统3的无线通信功能，而对抗来自中间攻击者的攻击，能够实现更安全的OTA分发。另外，通过抑制OTA主机4与SD卡11之间的数据转送、OTA中心2与SD卡11之间的上传、下载的次数，能够提高对于用户来说的便利性。

(第十七实施方式)

参照图146～图151对第十七实施方式进行说明。第十实施方式构成为按照区域从多个CDN供应商选定分发成本最小的CDN供应商，但第十七实施方式构成为静态地从多个CDN供应商选定能够降低分发成本的CDN供应商。具体而言，第十实施方式在OTA中心2对更新数据包进行加密之后，根据分发方式、OTA对象区域、分发数据大小使分发成本最小，然而第十七实施方式不在OTA中心2对更新数据包进行加密，而在通过TLS通信保护CDN8与OTA主机4之间之后，根据分发方式、OTA对象区域、分发数据大小使分发成本最小。

接下来，参照图147～图151对上述的构成的作用进行说明。

(17－1)OTA中心2的处理(参照图147～图148)

OTA中心2确定分发方式(A171)，确定OTA对象区域(A172)，确定对车辆的通信协议是否使用TLS(A173)，确定分发数据大小(A174)，并以分发方式、OTA对象区域、通信协议以及分发数据大小为关键词从CDN供应商管理数据库参照价格表格(A175)。该情况下，也可以OTA中心2以分发方式、OTA对象区域、通信协议以及分发数据大小中至少任意一个为关键词参照价格表格。OTA中心2按照区域选定分发成本最小的CDN供应商，并将更新数据包配置于该选定的CDN8(A176)。OTA中心2将活动通知发送到重编对象的车辆侧系统3(A177)。

(17－2)OTA主机4的处理(参照图149～图151)

OTA主机4通过在OTA主机4接收从OTA中心2发送的活动通知而获取活动通知(B171)。OTA主机4为了获取更新数据包而与活动通知所记载的CDN供应商建立TLS通信(B172)。另外，若在活动通知记载有URI信息，则也可以不记载CDN供应商的信息。OTA主机4在建立了TLS通信之后，通过TLS通信协议交换AES的公用密钥。协商选择AES－CTR模式作为加密模式。OTA主机4基于URI信息从CDN8下载并获取通过TLS的AES公用密钥进行了加密的更新数据包(B173，相当于更新数据获取步骤)。

此时，OTA主机4与从CDN8下载并获取进行了加密的更新数据包并行地，通过AES密钥执行计数器值的AES块加密处理对计数器值进行加密(B174)。OTA主机4对进行了加密的计数器值、和从CDN8下载的进行了加密的更新数据包进行XOR运算来进行解密(B175)。OTA主机4将进行了解密的更新数据包转送至目标ECU5，将更新数据包安装于目标ECU5(B176)。

如以上说明的那样根据第十七实施方式，能够得到以下的作用效果。

构成为不在OTA中心2对更新数据包进行加密，而在通过TLS通信保护CDN8与OTA主机4之间之后，根据分发方式、OTA对象区域、通信协议以及分发数据大小使分发成本最小。由此，能够适当地抑制OTA主机4从OTA中心2下载更新数据包时的分发成本。

(第十八实施方式)

参照图152～图165第十八实施方式进行说明。第十八实施方式不仅考虑分发成本，而在综合地考虑CDN供应商的吞吐量、响应延迟时间等的基础上，选定最佳的CDN供应商，并且定期地检查CDN供应商的价格表格和质量特性，始终将CDN供应商管理数据库保持为最新的状态，始终选定在市场上最具有竞争优势性的CDN供应商。价格表格如图153～图160所示，各云服务运营商的质量信息如图161所示。如图162所示，若对CDN供应商A与CDN供应商B进行比较，则在分发成本这一点CDN供应商B优于CDN供应商A，但在吞吐量的加权以及响应延迟时间的加权这一点CDN供应商A优于CDN供应商B。若不仅考虑分发成本，而综合地考虑CDN供应商的吞吐量、响应延迟时间等，则能够导出不应该选定仅分发成本有优势的CDN供应商B，而应该选定在综合地考虑了CDN供应商的吞吐量、响应延迟时间等的基础上占优势的CDN供应商A的结论。

接下来，参照图163～图165对上述的构成的作用进行说明。

(18－1)OTA中心2的处理(参照图163～图165)

OTA中心2确定分发方式(A181)，确定OTA对象区域(A182)，并以分发方式以及OTA对象区域为关键词从CDN供应商管理数据库参照价格表格(A183)。该情况下，OTA中心2也可以以分发方式以及OTA对象区域中至少任意一个为关键词参照价格表格。OTA中心2从CDN供应商管理数据库确定各CDN供应商的质量特性(A184)。OTA中心2基于每个区域的CDN供应商的分发成本以及质量特性，根据登记于CDN供应商选定逻辑数据库的CDN供应商选定逻辑按照区域选定最佳的CDN供应商，并将通过AES密钥进行了加密的更新数据包配置于该选定的CDN8(A185)。OTA中心2将储存了进行了加密的AES密钥的活动通知发送到重编对象的车辆侧系统3(A186)。

OTA中心2从网站自动获取各CDN供应商的价格表格，并更新CDN供应商管理数据库(A187)。OTA中心2测量各CDN供应商的吞吐量以及响应延迟时间，并更新CDN供应商管理数据库(A188)。例如分发服务器7定期地浏览各CDN供应商的网站并下载最新的价格表格。或者，分发服务器7在CDN供应商分发网站的更新信息的情况下，通过登录该分发服务，下载最新的价格表格。

(18－2)OTA主机4的处理

OTA主机4的处理与在第一实施方式中进行了说明的OTA主机4的处理(图12～图14)相同。

如以上说明的那样根据第十八实施方式，能够得到以下的作用效果。

不仅考虑分发成本，而在综合地考虑CDN供应商的吞吐量、响应延迟时间等的基础上，选定最佳的CDN供应商，并且定期地检查CDN供应商的价格表格和质量特性，始终将CDN供应商管理数据库保持为最新的状态，始终选定在市场上最具有竞争优势性的CDN供应商。由此，能够适当地抑制OTA主机4从OTA中心2下载更新数据包时的分发成本。

另外，作为CDN的质量特性，并不限定于吞吐量、响应延迟时间，也能够考虑内容的缓存命中率、过去的故障实绩等，能够使它们包含于CDN供应商管理数据库。另外，也能够定期地重新实施OTA中心2的连接目的地的CDN供应商的追加、删除，而与具有市场竞争力的CDN供应商连接。

(第十九实施方式)

参照图90、图190～图193对第十九实施方式进行说明。上述的第十实施方式构成为按照区域从多个CDN供应商选定分发成本最小的CDN供应商。在第十九实施方式中，对CDN供应商的选定进行具体的说明。在第十九实施方式中，根据分发数据大小、作为分发区域的OTA对象区域(有时也称为地区(region))、分发方式从多个CDN供应商中动态地选定分发成本最小的CDN供应商，作为更新数据包的向CDN8的配置目的地。在第十九实施方式中，参照在上述的图90中进行了例示的价格表格进行说明。价格表格也可以是与图90不同的样式。

如图190所示，在OTA中心2中，分发服务器7除了CDN供应商管理DB之外，还具备CDN供应商选定部7a、数据保存部7b、活动通知生成部7c、以及CDN分发部7d。CDN供应商选定部7a基于CDN供应商的选定所需要的信息亦即选定信息以及更新数据包的信息选定CDN供应商。在选定信息包含有与对象活动的数据大小、对象活动的分发对象车辆的台数、地区、分发方式相关的信息等。数据保存部7b除了保存活动信息之外，还保存能够识别通过CDN供应商选定部7a选定的CDN供应商的识别信息。在识别信息例如包含有CDN供应商的名称、确定CDN供应商的识别编号或者表示CDN供应商的URL等。活动通知生成部7c从数据保存部7b获取信息并生成分发给车辆等的活动通知。

CDN分发部7d具备与各CDN供应商对应的储存区域。例如储存区域具备储存区域A、储存区域B、储存区域C。CDN分发部7d的各储存区域与CDN服务器同步。即，CDN分发部7d例如在使数据从CDN服务器A分发到车辆侧系统3的情况下，将数据配置于储存区域A并转送至CDN服务器A。CDN服务器A若从CDN分发部7d转送数据，则将该转送的数据分发给车辆侧系统3。有时CDN分发部7d的各储存区域称为各CDN服务器的原始服务器。

接下来，参照图191～图193对上述的构成的作用进行说明。另外，OTA中心2的更新数据包的加密等处理与第十实施方式或者其它的实施方式相同。另外，OTA主机4的处理与第一实施方式或者其它的实施方式相同。在第十九实施方式中，主要对CDN供应商的选定进行说明。

(19－1)活动通知生成部7c的处理(参照图191)

若产生活动，则活动通知生成部7c例如从OEM服务器等外部获取活动信息(A191)。在活动信息包含有与对象活动的数据大小、对象活动的分发对象车辆的台数、地区、分发方式相关的信息。活动通知生成部7c将该获取的活动信息保存于数据保存部7b(A192)。有时将保存活动信息称为配置活动信息。

活动通知生成部7c向CDN供应商选定部7a通知CDN供应商的选定要求(A193)，并对来自CDN供应商选定部7a的选定通知的获取进行待机。活动通知生成部7c若从CDN供应商选定部7a获取选定通知(A194)，则访问数据保存部7b，获取通过该CDN供应商选定部7a选定的CDN供应商的识别信息(A195)。

活动通知生成部7c基于CDN供应商的识别信息生成包含该选定的CDN的URL的参数文件作为活动通知(A196)。活动通知生成部7c将该生成的活动通知分发给车辆侧系统3(A197)。

(19－2)CDN供应商选定部7a的处理(参照图192～图193)

CDN供应商选定部7a若获取从活动通知生成部7通知的CDN供应商的选定要求(A1911)，则访问数据保存部7b，获取选定信息(A1912)，并移至第一CDN选定处理(A1913)。

CDN供应商选定部7a若开始第一CDN选定处理，则计算表示从CDN服务器向更新对象车辆分发的数据大小的分发数据大小(A1921)。具体而言，CDN供应商选定部7a将对象活动的数据大小与该对象活动的分发对象车辆的台数相乘，计算预定从CDN服务器分发的分发数据大小。

CDN供应商选定部7a对每个CDN供应商反复以后的处理(A1922～A1929)。CDN供应商选定部7a基于先前计算出的分发数据大小以及与地区相关的地区信息从CDN供应商管理DB获取费用信息(A1923)。CDN供应商选定部7a例如在以北美为对象的30TB的活动的情况下，获取“北美”地区的“～10TB”和“～40TB”的费用信息。也可以对全部的数据大小获取费用信息。

CDN供应商选定部7a基于分发数据大小参照费用信息，计算分发收费额(A1924)。分发收费额的计算有按照CDN供应商而不同的可能性，根据CDN供应商中的分发收费额的计算方法决定。例如在根据图90的价格表格计算CDN1分发收费额的情况下，在地区为“北美”，分发数据大小为30TB的情况下，参照“～10TB”和“～40TB”的价格表格。

CDN供应商选定部7a判定研究对象的CDN供应商是否是进行与请求数对应的收费的CDN供应商(A1925)。CDN供应商选定部7a若判定为是不进行与请求数对应的收费的CDN供应商(A1925：否)，则将分发收费额决定为CDN供应商的收费额(A1928)，并结束该CDN供应商的收费额的计算，计算下一个CDN供应商的收费额。

CDN供应商选定部7a若判定为是进行与请求数对应的收费的CDN供应商(A1925：是)，则计算请求数(A1926)。请求数根据分发方式而不同。在分发方式为储存方式的情况下，将活动的分发对象车辆的台数作为请求数。在分发方式为流式传输方式的情况下，将对象活动的数据大小除以流式传输时的组块大小，并与活动的分发对象车辆的台数相乘来计算请求数。

CDN供应商选定部7a若计算出请求数，则基于该计算出的请求数计算收费额(有时称为请求收费额)(A1927)。请求收费额是每个请求的收费额与请求数的乘积。CDN供应商选定部7a将分发收费额与请求收费额相加后的合计金额决定为CDN供应商的收费额(A1928)，并结束研究对象的CDN供应商的收费额的计算，计算下一个CDN供应商的收费额。

CDN供应商选定部7a若对全部的CDN供应商计算出收费额，则选定分发成本最小的CDN供应商，即收费额最便宜的CDN供应商(A1930)，并结束第一CDN选定处理。CDN供应商选定部7a若结束第一CDN选定处理，则将其选定结果即选定的CDN供应商的识别信息保存于数据保存部7b(A1914)，并将选定结果通知给活动通知生成部7c(A1915)。

如以上说明的那样根据第十九实施方式，能够得到以下的作用效果。

构成为在分发服务器7中，参照CDN供应商管理DB，根据分发方式、OTA对象区域以及分发数据大小从分发成本不同的多个CDN8中选定分发成本有优势的CDN8，并将更新数据包配置于该选定的CDN8。由此，能够适当地抑制OTA主机4从OTA中心2下载更新数据包时的分发成本。

(第十九实施方式的变形例)

参照图194～图211对第十九实施方式的变形例进行说明。这里，对第一变形例～第五变形例进行说明。

(第十九实施方式的第一变形例)

参照图194～图195对第十九实施方式的第一变形例进行说明。第一变形例构成为通过使用DNS(域名系统)服务器，不变更向车辆侧系统3分发的活动通知所包含的CDN服务器的URL。在第十九实施方式中，对每个活动选定分发成本最小的CDN供应商。在活动通知包含有CDN服务器的URL。因此，若分发成本最小的CDN供应商变更，则活动通知所记载的URL变更。活动通知生成部7c每当生成活动通知则需要访问数据保存部7b获取CDN供应商的信息。

与此相对，在第一变形例中，通过更新通过DNS设定部7e登记于DNS的URL和IP地址的转换信息，活动通知生成部7c能够始终在活动通知记载相同的URL。在分发成本最小的CDN供应商变更的情况下，通过变更DNS服务器12的信息，车辆侧系统3能够访问选定的CDN服务器。换句话说，在第十九实施方式中，各CDN服务器具有固有的IP地址，具有固有的URL。与此相对，在第一变形例中，特征在于各CDN服务器虽然具有固有的IP地址，但具有在CDN服务器中共用的URL。

如图194所示，在OTA中心2，分发服务器7除了CDN供应商管理DB、CDN供应商选定部7a、数据保存部7b、活动通知生成部7c、以及CDN分发部7d之外，还具备DNS设定部7e。以下主要对与第十九实施方式不同的点进行说明。

DNS服务器12是提供对域名与IP地址进行转换的结构的服务器。在车辆侧系统3接收的活动通知包含有为了下载数据而访问的CDN服务器的URL。车辆侧系统3若接收活动通知，则向DNS服务器12询问该接收的活动通知所示出的URL。DNS服务器12将对于获取了询问的URL的IP地址发送至车辆侧系统3，或者将连接目的地转送到根据IP地址指定的地址。

DNS设定部7e保存CDN供应商的识别信息和IP地址。若通过CDN供应商选定部7a选定CDN供应商，则DNS设定部7e向DNS服务器12发送IP地址设定要求，设定在DNS的登记信息。

接下来，参照图195对上述的构成的作用进行说明。

(19－3)CDN供应商选定部7a的处理(参照图195)

CDN供应商选定部7a若结束第一CDN选定处理，并将选定结果保存于数据保存部7b(A1914)，则使IP地址设定要求从DNS设定部7e发送到DNS服务器12，通过DNS设定部7e设定在DNS的登记信息(A1931)。由此，即使CDN供应商变更，分发到车辆侧系统3的活动通知所包含的URL也不变更。在车辆侧系统3访问根据URL示出的CDN服务器时，DNS服务器12获取IP地址的询问，并将选定的CDN服务器的IP地址发送给车辆侧系统3。

另外，DNS设定部7e也可以获取DNS服务器12的信息，或者保存上一次的向DNS服务器12的设定信息，在登记于DNS服务器12的CDN服务器与CDN供应商选定部7a选定的CDN服务器不同的情况下，向DNS服务器12发送IP地址的更新要求。活动通知生成部7c若从CDN供应商选定部7a获取选定通知，则生成包含固定的URL的活动通知。

根据这样的构成，除了得到与第十九实施方式相同的作用效果之外，还能够使活动通知所包含的CDN的URL信息始终相同，能够提高安全。

(第十九实施方式的第二变形例)

参照图196～图201对第十九实施方式的第二变形例进行说明。即使选择更新数据包的分发成本最小的CDN供应商，也有由于CDN服务器的维护、故障、访问集中等而通信速度变慢的担心。本申请发明者们关注于基于分发成本和分发性能选择CDN供应商。

在第二变形例中，在车辆侧系统3为了获取与活动通知所示出的URL对应的IP地址而询问DNS服务器12时，DNS服务器12确认CDN服务器的分发状况，若判定为不可分发，则向车辆侧系统3回答分发成本其次便宜的CDN服务器的IP地址。

如图196所示，在OTA中心2，分发服务器7除了CDN供应商管理DB、CDN供应商选定部7a、数据保存部7b、活动通知生成部7c、CDN分发部7d、以及DNS设定部7e之外，还具备性能测定部7f。DNS服务器12具备CDN服务器确认部12a。在CDN分发部7d的储存区域配置有用于测定CDN服务器的性能的测试文件。性能测定部7f向CDN服务器发送测试文件的分发要求，使测试文件从CDN服务器分发，并测定测试文件的分发所需要的时间作为分发时间。分发时间例如是从开始测试文件的分发的时刻起到确定了测试文件的接收完成的时刻为止的时间。

如图197所示，CDN供应商管理DB具备CDN服务器的选择表格。选择表格包含通过CDN供应商选定部7a决定的成本位次、和通过性能测定部7f判定出的分发标志。

性能测定部7f对各CDN服务器根据测试文件的分发所需要的时间计算响应速度，并将基于该计算出的响应速度的判定结果输入到选择表格。性能测定部7f在响应速度在规定值以上的情况下，将该CDN服务器的分发标志设定为打开(TRUE)，在响应速度小于规定值的情况下，将该CDN服务器的分发标志设定为关闭(FALSE)。

CDN服务器确认部12a在从车辆侧系统3获取了与URL对应的IP地址的询问时，判定根据URL指定的CDN服务器是否为能够分发的状态，若判定为不可分发，则回答其它的CDN服务器的IP地址。

接下来，参照图198～图201对上述的构成的作用进行说明。

(19－4)CDN供应商选定部7a的处理(参照图198～图199)

CDN供应商选定部7a若在第一CDN选定处理中，对每个CDN供应商计算出收费额(A1921～A1929)，则决定CDN供应商的成本位次(A1951)。即，CDN供应商选定部7a将分发成本最小的CDN供应商的位次决定为第一位，将分发成本其次便宜的CDN供应商的位次决定为第二位。CDN供应商选定部7a若将选定结果保存于数据保存部7b(A1914)，则在CDN供应商管理DB的选择表格保存成本位次(A1941)。

(19－5)性能测定部7f的处理(参照图200)

性能测定部7f对每个CDN供应商反复以后的处理(A1961～A1966)。性能测定部7f在分发服务器7启动中以恒定间隔或者通过分发服务器7的管理者在任意的时刻执行以后的处理。

性能测定部7f访问CDN服务器(A1962)，向CDN服务器发送测试文件的分发要求。性能测定部7f基于测试文件的分发所需要的时间计算响应速度，并判定该计算出的响应速度是否在规定值以上(A1963)。另外，也可以不计算响应速度而将分发所需要的时间与规定值比较，也可以将每个单位时间的分发数据大小与规定值进行比较。

性能测定部7f若判定为响应速度在规定值以上(A1963：是)，则判定为该CDN服务器是能够利用于分发的服务器，将分发标志设定为打开(A1964)。性能测定部7f若判定为该计算出的响应速度小于规定值(A1963：否)，则判定为该CDN服务器是不能够利用于分发的服务器，而将分发标志设定为关闭(A1965)。

(19－6)CDN服务器确认部12a的处理(参照图201)

在活动通知示出为了下载更新数据而访问的URL。车辆侧系统3对DNS服务器12询问为了下载更新数据包应该访问的IP地址。

CDN服务器确认部12a从车辆侧系统3对活动通知示出的URL获取IP地址的询问(A1971)。CDN服务器确认部12a向分发服务器7的CDN供应商管理DB查询活动通知所示出的CDN服务器的分发状况(A1972)。该情况下，CDN服务器相当于数据获取预定的CDN供应商，分发状况相当于分发标志。CDN服务器确认部12a若从分发服务器获取数据获取预定的CDN供应商的分发标志，则判定数据获取预定的CDN供应商是否能够使用(A1973)。即，CDN服务器确认部12a判定该获取的分发标志是打开或者关闭的哪一个。

CDN服务器确认部12a若判定为分发标志打开(A1973：是)，则向车辆侧系统3回答与该CDN供应商对应的IP地址，或者将与车辆侧系统3的连接转送至该IP地址，切换为与活动通知的URL对应的CDN供应商(A1974)。CDN服务器确认部12a若判定为分发标志关闭(A1973：否)，则将成本位次其次高的CDN供应商作为下一个优先级的CDN供应商，将下一个优先级的CDN供应商设定为数据获取预定的CDN供应商(A1975)，并返回到步骤A1973。

根据这样的构成，能够在尽量抑制分发成本的同时，选择正常运转的CDN服务器。另外，CDN服务器确认部12a也可以每经过恒定期间，则访问CDN供应商管理DB，要求选择表格的发送。该情况下，在从车辆侧系统3获取了IP地址的询问的情况下，也可以代替访问CDN供应商管理DB，而参照CDN服务器确认部12a保持的选择表格来判定数据获取预定的CDN供应商是否能够使用。另外，除了在尽量抑制分发成本的同时，选择正常运转的CDN服务器之外，还能够减少DNS服务器12与分发服务器7之间的通信。

(第十九实施方式的第三变形例)

参照图202～图205对第十九实施方式的第三变形例进行说明。第三变形例在分发服务器7中，性能测定部7f基于来自车辆侧系统3的日志信息测定并评价CDN服务器的性能。另外，DNS服务器12从车辆侧系统3获取了对URL的IP地址的询问的情况下的动作与第二变形例相同。在第三变形例中也与第二变形例相同，CDN供应商管理DB具备选择表格。

车辆侧系统3具备日志发送部3a。若结束从CDN服务器的更新数据的下载，则日志发送部3a向分发服务器7的性能测定部7f发送包含表示下载所需要的时间的下载时间的与下载相关的日志信息。与下载相关的日志信息也可以除了下载时间之外，还包含下载的数据包的识别信息、数据大小、下载中的最大吞吐量等信息。

性能测定部7f若从日志发送部3a接收与下载相关的日志信息，则根据下载时间计算吞吐量，并将基于该计算出的吞吐量的判定结果输入到选择表格。性能测定部7f在吞吐量在规定值以上的情况下，将该CDN服务器的分发标志设定为打开(TRUE)，在吞吐量小于规定值的情况下，将该CDN服务器的分发标志设定为关闭(FALSE)。

接下来，参照图203～图205对上述的构成的作用进行说明。

(19－8)日志发送部3a的处理(参照图203)

若结束从CDN服务器的更新数据包的下载(A1981)，则日志发送部3a向分发服务器7发送包含表示下载所需要的时间的下载时间的与下载相关的日志信息(A1982)。

(19－9)性能判定部7f的处理(参照图204)

性能判定部7f若从日志发送部3a接收与下载相关的日志信息(A1991)，则根据下载时间计算吞吐量(A1992)，并判定该计算出的吞吐量是否在规定值以上(A1993)。

性能测定部7f若判定为该计算出的吞吐量在规定值以上(A1993：是)，则判定为该CDN服务器是能够利用于分发的服务器，将分发标志设定为打开(A1994)。性能测定部7f若判定为该计算出的吞吐量小于规定值(A1993：否)，则判定为该CDN服务器是不能够利用于分发的服务器，而将分发标志设定为关闭(A1995)。

(19－10)性能判定部7f的处理(参照图205)

性能判定部7f定期地进行将分发标志关闭的CDN服务器的恢复处理。性能测定部7f向CDN供应商管理DB通知分发标志设定为关闭的CDN服务器的信息要求，确定分发标志设定为关闭的CDN服务器(A19101)，并对每个CDN供应商反复以后的处理(A19102～A19107)。性能测定部7f在分发服务器7启动中，以恒定间隔或者通过分发服务器7的管理者在任意的时刻执行以后的处理。

性能测定部7f向CDN服务器通知测试文件的分发要求，根据从CDN服务器分发的文件的下载时间计算吞吐量(A19103)，并判定该计算出的吞吐量是否在规定值以上(A19104)。

性能测定部7f若判定为该计算出的吞吐量在规定值以上(A19104：是)，则将该分发标志从关闭变更为打开(A19105)。性能测定部7f若判定为该计算出的吞吐量小于规定值(A19104：否)，则维持该分发标志的关闭(A19106)。另外，性能测定部7f也可以在分发服务器的系统启动时或者每隔规定期间，将CDN供应商管理DB的设定为关闭的分发标志打开。

若像这样构成，则与为了确定CDN服务器的响应而向CDN服务器发送测试文件的分发要求的第二变形例不同，不需要向CDN服务器发送测试文件的分发要求，能够抑制对通信网络的负荷、成本。另外，也可以通过在车辆侧系统3设置测定更新数据包的下载速度的功能，若判定为吞吐量小于规定值，则将连接变更为其它的CDN服务器。

也可以在从分发服务器7分发的活动通知中除了最初连接的CDN服务器的URL之外，还包含在该CDN服务器的吞吐量较低的情况下连接的预备的CDN服务器的URL。预备的CDN服务器例如是分发成本其次便宜的CDN服务器、预先决定的预备的CDN服务器。在指定多个CDN服务器作为预备的CDN服务器的情况下，也可以附加表示连接顺序的信息。

车辆侧系统3若开始更新数据包的下载，则测定吞吐量，确认是否得到规定值以上的吞吐量。车辆侧系统3若判定为未得到规定值以上的吞吐量，则向DNS服务器12对活动通知所示出的预备的CDN服务器的URL询问IP地址，并将连接从最初的CDN服务器变更为新的CDN服务器。另外，由于在分发的数据中对每个数据包附加有识别信息，所以即使在更新数据包的下载的中途变更CDN服务器也能够继续下载更新数据包。

(第十九实施方式的第四变形例)

参照图206～图207对第十九实施方式的第四变形例进行说明。第四变形例通过CDN供应商选定部7a选定多个CDN供应商，活动通知生成部7c对每个CDN供应商生成多个活动通知。在向车辆侧系统3分发活动通知时采用轮循方式指定不同的CDN服务器。

(19－11)活动通知生成部7c的处理(参照图206)

活动通知生成部7c若获取CDN供应商的信息(A195)，则对每个CDN供应商生成活动通知(A19111)。即，活动通知生成部7c对一个活动生成两个以上的活动通知。活动通知生成部7c以CDN服务器以轮循方式变更的方式分发活动通知(A19112)。活动通知生成部7c例如在选择了CDN11和CDN12两个CDN服务器的情况下，在分发活动通知时，对最初的车辆分发包含CDN11的URL的活动通知，对下一个车辆分发包含CDN12的URL的活动通知，对更下一个车辆分发包含CDN11的URL的活动通知。

(19－12)CDN供应商选定部7a的处理(参照图207)

CDN供应商选定部7a在第十九实施方式中选定分发成本最小的CDN供应商，但在第四变形例中按照分发成本从低到高的顺序选定多个CDN供应商(A19121)。

根据这样的构成，能够在抑制从CDN服务器的分发成本的同时，防止访问集中于特定的CDN服务器，通过防止访问的集中，能够防止吞吐量的降低。

(第十九实施方式的第五变形例)

参照图208～图211对第十九实施方式的第五变形例进行说明。第四变形例选择抑制分发成本的多个CDN供应商，生成CDN服务器的信息不同的多个活动通知，并以CDN服务器以轮循方式变更的方式向车辆侧系统3分发活动通知。与此相对，第五变形例选择抑制分发成本的多个CDN供应商，生成一个活动通知，并分发给车辆侧系统3。在DNS服务器12从车辆侧系统3获取了与活动通知所示出的URL对应的IP地址的询问时，按照车辆侧系统3变更回答给车辆侧系统3的CDN服务器。换句话说，在DNS服务器12中，以轮循方式选择CDN服务器。

如图208所示，DNS服务器12具备切换部12b。切换部12b在从车辆侧系统3获取了IP地址的询问时，以轮循方式依次变更回答给车辆侧系统3的IP地址。分发服务器具备DNS设定部7e。第五变形例的DNS设定部7e将图209所示的轮循记录发送给DNS服务器12。

(19－13)CDN供应商选定部7a的处理(参照图210)

CDN供应商选定部7a与第四变形例相同按照分发成本从低到高的顺序选定多个CDN供应商(A19121)，设定轮循记录(A19131)。

(19－14)切换部12b的处理(参照图211)

DNS服务器12若从车辆侧系统3获取IP地址的询问(A19141)，则参照轮循记录(A19142)，将与记载的CDN服务器对应的IP地址发送给车辆侧系统3(A19143)。DNS服务器12每当从车辆侧系统3获取IP地址的询问则反复上述的处理，若从其它的车辆侧系统3获取IP地址的询问，则参照轮循记录，将与和上次不同的CDN服务器对应的IP地址发送到车辆侧系统3。即，DNS服务器12根据轮循方式依次将CDN服务器的IP地址发送到车辆侧系统3。

根据这样的构成，能够在抑制从CDN服务器的分发成本的同时，防止访问集中于特定的CDN服务器，通过防止访问的集中，能够防止吞吐量的降低。

(第二十实施方式)

参照图212～图224对第二十实施方式进行说明。

第二十实施方式在能够对规定期间的多个活动获取信息的情况下，根据分发方式、作为分发区域的OTA对象区域、分发数据大小动态地选定多个CDN供应商，作为更新数据包的向CDN8的配置目的地，来抑制分发成本。规定期间例如是下个月。

在上述的第十九实施方式中，对一个活动选定分发成本最小的CDN供应商。然而，活动也假定从OEM服务器登记预定在规定期间例如下个月开始分发的多个活动。在像这样预先对多个活动获取各活动的与数据大小、分发对象车辆的台数、OTA对象区域、分发方式相关的信息的情况下，有与如第十九实施方式那样对每个活动选定了CDN供应商的情况不同的CDN供应商成为分发成本最小的CDN供应商的可能性。

如图212所示，OTA中心2具备CDN供应商管理DB、CDN供应商选定部7a、数据保存部7b、活动通知生成部7c、CDN分发部7d、以及进展信息管理部7g。进展信息管理部7g保持表示在规定期间内以何种程度将活动分发到车辆侧系统3的预测值。活动登记于OTA中心2，即使像车辆侧系统3分发了活动通知，也不一定全部的车辆立即应用活动，从CDN服务器下载更新数据包。进展信息管理部7g为了更正确地预测从CDN服务器向车辆侧系统3的更新数据包的分发数据大小而保存预测值。虽然在本实施方式中，使规定期间为一个月进行说明，但也可以是其它的期间。

参照图213，对第二十实施方式中的计算方法进行说明。在第二十实施方式中如后述那样通过三种计算方法计算CDN供应商的收费额。在第一计算方法中，在各活动中选定分发成本最小的CDN供应商。该情况下，有按照活动选定不同的CDN供应商的可能性。在图213中，例示对活动1选定CDN1，对活动2选定CDN2，对活动3选定CDN3的情况。

在第二计算方法中，计算全部的活动的分发总数据大小，并基于该计算出的全部的活动的分发总数据大小选定分发成本最小的CDN供应商。该情况下，在全部的活动中选定同一CDN供应商。在图213中，例示对活动1～3选定CDN1的情况。在第三计算方法中，计算每种分发方式的活动的分发总数据大小，并基于该计算出的每种分发方式的活动的分发总数据大小选定分发成本最小的CDN供应商。作为每种分发方式，分别对流式传输方式和储存方式选定CDN供应商。在图213中，例示在活动1与活动2、3中分发方式不同，对活动1选定CDN1，对活动2、3选定CDN2的情况。

接下来，参照图214～图224对上述的构成的作用进行说明。

(20－1)活动通知生成部7c的处理(参照图214)

活动通知生成部7c例如从OEM服务器等外部获取预定分发的活动信息(A201)。在预定分发的活动信息包含有与分发开始日、对象活动的数据大小、对象活动的分发对象车辆的台数、地区、分发方式相关的信息。活动通知生成部7c将该获取的活动信息保存于数据保存部7b(A202)。

活动通知生成部7c向CDN供应商选定部7a通知CDN供应商的选定要求(A203)，并等待从CDN供应商选定部7a的选定通知的获取。活动通知生成部7c若从CDN供应商选定部7a获取选定通知(A204)，则访问数据保存部7b，获取通过该CDN供应商选定部7a选定的CDN供应商的识别信息(A205)。

活动通知生成部7c基于CDN供应商的识别信息生成包含该选定的CDN的URL的参数文件作为预定分发的活动通知(A206)。活动通知生成部7c将该生成的预定分发的活动通知分发到车辆侧系统3(A207)。

(20－2)CDN供应商选定部7a的处理(参照图215～图221)

CDN供应商选定部7a若获取从活动通知生成部7通知的CDN供应商的选定要求(A2011)，则向数据保存部7b进行访问，获取选定信息(A2012)。该情况下，在选定信息包含有预定分发的全部的对象活动的数据大小、分发对象车辆的台数、地区、分发方式、各活动的分发开始日的信息。

CDN供应商选定部7a从进展信息管理部7g获取分发预测值(A2013)。CDN供应商选定部7a对每个活动计算分发数据大小(A2014)。具体而言，CDN供应商选定部7a将活动的数据大小、活动的分发对象车辆的台数以及分发预测值相乘，并进一步乘以与分发期间对应的修正值。根据活动，有将分发开始日设定为下月下旬的情况等分发期间较短的情况，所以通过与分发期间对应的修正值进行调整。例如若为推迟分发开始日的结果是分发期间只有十天的情况，则三十天中十天为能够分发的期间所以设定0.3等作为修正值。

CDN供应商选定部7a移至第二CDN选定处理(A2015)。CDN供应商选定部7a若开始第二CDN选定处理，则依次移至基于第一计算方法的收费额的计算处理、基于第二计算方法的收费额的计算处理、以及基于第三计算方法的收费额的计算处理(A2021～A2023)。

CDN供应商选定部7a在基于第一计算方法的收费额的计算处理中，对每个活动选定分发成本最小的CDN供应商。CDN供应商选定部7a若开始基于第一计算方法的收费额的计算处理，则对每个活动反复其以后的处理(A2031～A2041)，并且对每个CDN供应商反复(A2032～A2039)。CDN供应商选定部7a基于分发数据大小以及地区信息从CDN供应商管理DB获取费用信息(A2033)。CDN供应商选定部7a基于分发数据大小参照费用信息，计算分发收费额(A2034)。

CDN供应商选定部7a与第十九实施方式相同，判定研究对象的CDN供应商是否是进行与请求数对应的收费的CDN供应商，来决定CDN供应商的收费额(A2035～A2038)。CDN供应商选定部7a对每个CDN供应商并且对每个活动反复分发收费额的计算。另外，CDN供应商选定部7a若对一个活动计算全部的CDN供应商的收费额，则对该活动选定分发成本最小的CDN供应商(A2040)。

CDN供应商选定部7a若对全部的活动结束分发收费额的计算和CDN供应商的选定，则将全部的活动的分发收费额相加，计算总额(A2042)，并结束基于第一计算方法的收费额的计算处理，移至基于第二计算方法的收费额的计算处理。

CDN供应商选定部7a在基于第二计算方法的收费额的计算处理中，基于预定分发的全部的活动的总分发数据大小选定一个CDN供应商。CDN供应商选定部7a若开始基于第二计算方法的收费额的计算处理，则将各活动的分发数据大小相加，计算分发总数据大小(A2051)，并对每个CDN供应商反复其以后的处理(A2052～A2059)。CDN供应商选定部7a基于分发总数据大小以及地区信息从CDN供应商管理DB获取费用信息(A2053)。CDN供应商选定部7a基于分发总数据大小参照费用信息，计算分发收费额(A2054)。

CDN供应商选定部7a与第十九实施方式相同，判定研究对象的CDN供应商是否是进行与请求数对应的收费的CDN供应商，来决定CDN供应商的收费额(A2055～A2058)。CDN供应商选定部7a对每个CDN供应商反复分发收费额的计算。CDN供应商选定部7a选定分发成本最小的CDN供应商(A2060)。将预定分发的全部的活动的分发收费额相加，计算总额(A2061)，并结束基于第二计算方法的收费额的计算处理，移至基于第三计算方法的收费额的计算处理。

CDN供应商选定部7a在基于第三计算方法的收费额的计算处理中，按每种分发方式汇总活动的基础上选定CDN供应商。CDN供应商选定部7a若开始基于第三计算方法的收费额的计算处理，则判定预定分发的活动的分发方式是否全部相同(A2071)。CDN供应商选定部7a若判定为预定分发的活动的分发方式全部相同，即预定分发的活动全部为流式传输方式，或者全部为储存方式(A2071：是)，则与上述的基于第二计算方法的收费额的计算处理相同，所以结束基于第三计算方法的收费额的计算处理。

CDN供应商选定部7a若判定为预定分发的活动的分发方式并不全部相同，即作为预定分发的活动，流式传输方式和储存方式混在一起(A2071：否)，则根据分发方式对活动进行分组(A2072)，对于流式传输方式的组移至流式传输方式的收费额计算处理(A2073)，对于储存方式的组移至储存方式的收费额计算处理(A2074)。

CDN供应商选定部7a若开始流式传输方式的收费额计算处理，则计算通过流式传输方式分发的各活动的分发数据大小的合计值(A2081)，并对每个CDN供应商反复其以后的处理(A2082～A2089)。CDN供应商选定部7a基于分发数据大小的合计值以及地区信息从CDN供应商管理DB获取费用信息(A2083)。CDN供应商选定部7a基于分发数据大小的合计值参照费用信息，计算分发收费额(A2084)。

CDN供应商选定部7a与第十九实施方式相同，判定研究对象的CDN供应商是否是进行与请求数对应的收费的CDN供应商，来决定CDN供应商的收费额(A2085～A2088)。CDN供应商选定部7a对每个CDN供应商反复分发收费额的计算。CDN供应商选定部7a选定流式传输方式的分发成本最小的CDN供应商(A2090)，并结束流式传输方式的收费额计算处理。

另一方面，CDN供应商选定部7a若开始储存方式的收费额计算处理，则计算通过储存方式分发的各活动的分发数据大小的合计值(A2091)，并对每个CDN供应商反复其以后的处理(A2092～A2099)。CDN供应商选定部7a基于分发数据大小的合计值以及地区信息从CDN供应商管理DB获取费用信息(A2093)。CDN供应商选定部7a基于分发数据大小的合计值参照费用信息，计算分发收费额(A2094)。

CDN供应商选定部7a与第十九实施方式相同，判定研究对象的CDN供应商是否是进行与请求数对应的收费的CDN供应商，来决定CDN供应商的收费额(A2095～A2098)。CDN供应商选定部7a对每个CDN供应商反复分发收费额的计算。CDN供应商选定部7a选定储存方式的分发成本最小的CDN供应商(A20100)，并结束储存方式的收费额计算处理。

CDN供应商选定部7a若结束基于第一计算方法的收费额的计算处理、基于第二计算方法的收费额的计算处理、以及基于第三计算方法的收费额的计算处理，则决定分发成本最小的计算方法(A2024)，选定各活动的CDN供应商(A2025)，并结束第二CDN选定处理。CDN供应商选定部7a若结束第二CDN选定处理，则将其选定结果即识别选定的CDN供应商的识别信息保存于数据保存部7b(A2016)。这里，CDN供应商选定部7a将识别预定分发的活动的CDN供应商的识别信息保存于数据保存部7b。CDN供应商选定部7a向活动通知生成部7c通知选定通知(A2017)。

(20－3)进展信息管理部7g的处理(参照图222)

进展信息管理部7g保存表示在规定期间向车辆侧系统3分发何种程度的活动的预测值。假定根据从OEM服务器发送的实际的分发状况更新该预测值。

进展信息管理部7g从OEM服务器获取分发状况(A20111)。进展信息管理部7g判定分发状况与该保存的预测值之差是否在规定值以上(A20112)。进展信息管理部7g若判定为分发状况与该保存的预测值之差不在规定值以上(A20112：否)，则结束处理。

进展信息管理部7g若判定为分发状况与该保存的预测值之差在规定值以上(A20112：是)，则更新保存的预测值(A20113)，并向CDN供应商选定部7a通知预测值的更新(A20114)。进展信息管理部7g既可以对全部的活动具有共用的一个预测值，也可以按照每个活动或者按照每个更新对象车辆，按照活动的种类具有不同的预测值。

(20－4)CDN供应商选定部7a的处理(参照图223)

CDN供应商选定部7a若获取从进展信息管理部7g通知的预测值的更新(A20121)，则获取选定信息(A20122)，并从进展信息管理部7g获取分发预测值(A20123)，对每个活动计算分发数据大小(A20124)。该情况下，CDN供应商选定部7a在计算分发数据大小时，作为考虑了分发天数的修正值。

CDN供应商选定部7a移至第二CDN选定处理(A20125)，若结束第二CDN选定处理，则判定CDN供应商是否有变更(A20126)。CDN供应商选定部7a若判定为CDN供应商没有变更(A20126：否)，则结束处理。在CDN供应商有变更的情况下，更新数据保存部7b中的选定结果。CDN供应商选定部7a若判定为CDN供应商有变更(A20126：是)，则更新选定结果(A20127)，并向活动通知生成部7c发送CDN变更通知(A20128)。另外，CDN供应商选定部7a也可以以规定间隔确认保存于进展信息管理部7g的预测值是否变更。

(20－5)活动通知生成部7c的处理(参照图224)

活动通知生成部7c若获取从CDN供应商选定部7a通知的CDN变更通知(A20131)，则访问数据保存部7b，获取更新后的CDN供应商的信息(A20132)，并基于该获取的更新后的CDN供应商信息重新生成预定分发的活动通知(A20133)。

如以上说明的那样根据第二十实施方式，能够得到以下的作用效果。

构成为参照CDN供应商管理数据库，根据分发方式、OTA对象区域以及分发数据大小从分发成本不同的多个CDN8中选定分发成本有优势的CDN8，并将更新数据包配置于该选定的CDN8。能够适当地抑制OTA主机4从OTA中心2下载更新数据包时的分发成本。

(其它的实施方式)

在上述的实施方式中，未载明流式传输方式或者储存方式的实施方式能够应用于流式传输方式和储存方式的任何的方式。

在上述的一部分的实施方式中，记载了在建立了TLS通信的基础上从OTA中心2向OTA主机4发送活动通知。然而，也可以在全部的实施方式中，在建立了TLS通信的基础上从OTA中心2向OTA主机4发送活动通知。通过建立TLS通信，能够进一步提高安全。或者，也可以不建立TLS通信而从OTA中心2向OTA主机4发送活动通知。

本实施方式的车辆侧系统3也可以是以下的构成。车辆侧系统3也可以构成为具备DCM(数据通信模块)和CGW(中央网关)，DCM与CGW经由总线以能够进行数据通信的方式连接。CGW也称为中央ECU。总线例如可以是以太网、CAN(注册商标)总线等。

也可以在CGW中实现OTA主机4的功能的一部分或者整体。作为一个例子，也可以DCM与CDN8、OTA中心2等外部进行数据通信，在CGW中实施OTA主机4的功能的全部。该情况下，DCM将通过与外部的无线通信接收的全部的数据转送至CGW。或者，也可以DCM除了与外部进行数据通信之外，还作为OTA主机4的下载器发挥作用。下载器的功能例如是指车辆构成信息的生成、元数据验证、数据包验证、活动信息的验证。或者，也可以在DCM中实现OTA主机4的功能。该情况下，在CGW安装有OTA主机4以外的功能。或者，也可以DCM与CGW一体化。

也可以构成为CGW具有DCM的功能的一部分或者整体，也可以构成为DCM具有CGW的功能的一部分或者整体。即，在OTA主机4中，可以任意地构成DCM与CGW的功能分担。OTA主机4既可以由DCM以及CGW两个ECU构成，也可以由具有DCM的功能和CGW的功能的一个综合ECU构成。

本公开依据实施方式进行了记述，但应该理解本公开并不限定于该实施方式、结构。本公开也包含各种变形例、同等范围内的变形。除此之外，也将各种组合、方式，甚至其中仅包含一个要素、更多或者更少要素的其它的组合、方式纳入本公开的范畴、思想范围。

能够通过记录于实体的存储器装置的软件以及执行该软件的计算机，仅通过软件，仅通过硬件，或者通过它们的组合提供各装置等提供的方法、功能。例如在通过作为硬件的电子电路提供控制部的情况下，能够通过包含许多的逻辑电路的数字电路，或者模拟电路提供该控制部。

也可以由通过构成被编程为执行通过计算机程序具体化的一个或者多个功能的处理器以及存储器提供的专用计算机实现本公开所记载的控制部及其方法。或者，也可以由通过由一个以上的专用硬件逻辑电路构成处理器提供的专用计算机实现本公开所记载的控制部及其方法。另外，也可以由通过被编程为执行一个或者多个功能的处理器以及存储器与由一个以上的硬件逻辑电路构成的处理器的组合构成的一个以上的专用计算机实现本公开所记载的控制部及其方法。另外，计算机程序也可以作为能够通过计算机执行的指令，存储于计算机能够读取的非迁移有形记录介质。

Claims (17)

1.一种数据通信系统，具备中心装置(2)和主机装置(4)，上述中心装置将更新数据配置于内容分发网络(CDN)，上述主机装置将从上述CDN下载的上述更新数据安装于重编对象的电子控制装置，其中，

上述中心装置通过规定的加密方式对上述更新数据进行加密并配置于上述CDN，

上述主机装置以分割流式传输方式从上述CDN下载进行了上述加密的更新数据。

2.根据权利要求1所述的数据通信系统，其中，

上述主机装置通过超文本传输协议(HTTP)指定下载对象的数据范围，并以分割流式传输方式从上述CDN下载进行了上述加密的更新数据。

3.一种数据通信系统，具备中心装置(2)和主机装置(4)，上述中心装置将更新数据配置于内容分发网络(CDN)，上述主机装置将从上述CDN下载的上述更新数据安装于重编对象的电子控制装置，其中，

具备能够储存上述更新数据的记录介质，

上述中心装置通过规定的加密方式对上述更新数据进行加密并将上述更新数据配置于上述CDN，

上述主机装置从上述CDN经由上述记录介质以一并储存方式下载进行了上述加密的更新数据。

4.一种数据通信系统，具备中心装置(2)和主机装置(4)，上述中心装置将更新数据配置于内容分发网络，上述主机装置将从上述CDN下载的上述更新数据安装于重编对象的电子控制装置，其中，

上述中心装置与多个运营商的CDN连接，通过规定的加密方式对上述更新数据进行加密，根据分发方式、分发区域、通信协议、分发数据大小中至少任意一个，从多个运营商的CDN中选定分发成本有优势的CDN，并将进行了上述加密的更新数据配置于该选定的CDN。

5.一种数据通信系统，具备中心装置(2)和主机装置(4)，上述中心装置将更新数据配置于内容分发网络(CDN)，上述主机装置将从上述CDN下载的上述更新数据安装于重编对象的电子控制装置，其中，

上述中心装置与多个运营商的CDN连接，根据分发方式、分发区域、通信协议、分发数据大小中至少任意一个，从多个运营商的CDN中选定分发成本有优势的CDN，不对上述更新数据进行加密，而将上述更新数据配置于该选定的CDN，

上述主机装置在与上述CDN之间建立了传输层安全(TLS)的基础上，从该CDN下载上述更新数据。

6.一种数据通信系统，具备中心装置(2)和主机装置(4)，上述中心装置将更新数据配置于内容分发网络(CDN)，上述主机装置将从上述CDN下载的上述更新数据安装于重编对象的电子控制装置，其中，

上述中心装置与多个运营商的CDN连接，通过规定的加密方式对上述更新数据进行加密，根据分发方式、分发区域、通信协议、分发数据大小中至少任意一个，不仅根据分发成本，还与各运营商的CDN的通信吞吐量、响应延迟时间、缓存命中率、过去的故障实绩的质量性能中至少任意一个组合，综合地选择最佳的运营商的CDN，并将进行了上述加密的更新数据配置于该选择的CDN。

7.一种数据通信系统，具备中心装置(2)和主机装置(4)，上述中心装置将更新数据配置于内容分发网络(CDN)，上述主机装置将从上述CDN下载的上述更新数据安装于重编对象的电子控制装置，其中，

上述中心装置与多个运营商的CDN连接，定期地监视各运营商的CDN的分发成本，并更新各运营商的CDN的分发成本信息。

8.一种数据通信系统，具备中心装置(2)和主机装置(4)，上述中心装置将更新数据配置于内容分发网络(CDN)，上述主机装置将从上述CDN下载的上述更新数据安装于重编对象的电子控制装置，其中，

上述中心装置与多个运营商的CDN连接，定期地测量或者监视各运营商的CDN的吞吐量、响应延迟时间、缓存命中率、过去的故障实绩的质量特性中至少任意一个，并更新各运营商的CDN的质量特性信息。

9.一种数据通信系统，具备中心装置(2)和主机装置(4)，上述中心装置将更新数据配置于内容分发网络(CDN)，上述主机装置将从上述CDN下载的上述更新数据安装于重编对象的电子控制装置，其中，

上述中心装置定期地或者临时地重新进行成为连接目的地的各运营商的CDN的追加、删除，并基于分发成本、吞吐量、响应延迟时间、缓存命中率、过去的故障实绩中至少任意一个与有竞争力的运营商的CDN连接。

10.一种中心装置，是将更新数据配置于内容分发网络(CDN)的中心装置(2)，其中，具备：

公用密钥生成部(2a)，生成用于对更新数据进行加密的公用密钥；

更新数据加密部(2b)，通过上述公用密钥对上述更新数据进行加密；

公用密钥加密部(2c)，通过RSA公开密钥对上述公用密钥进行加密；

公用密钥储存部(2d)，将通过上述RSA公开密钥进行了加密的上述公用密钥储存在活动通知中；

CDN供应商选定部(2j)，根据分发方式、分发区域、通信协议、分发数据大小中至少任意一个，从多个运营商的CDN中选定分发成本有优势的CDN；

加密数据配置部(2e)，将通过上述公用密钥进行了加密的上述更新数据配置于该选定的CDN；以及

活动通知发送部(2f)，将储存了进行了加密的上述公用密钥的活动通知发送到重编对象的车辆侧系统。

11.根据权利要求10所述的中心装置，其中，

上述CDN供应商选定部基于更新数据的分发数据大小和分发区域，对每个CDN供应商计算分发成本。

12.根据权利要求11所述的中心装置，其中，

上述CDN供应商选定部判定是否为根据分发请求次数进行收费的CDN供应商，对于根据分发请求次数进行收费的CDN供应商，计算基于请求数的收费额，并将基于分发数据大小的收费额和基于请求数的收费额相加，来选定分发成本有优势的CDN。

13.根据权利要求10所述的中心装置，其中，

上述CDN供应商选定部对在规定期间预定分发的多个活动，基于更新数据的分发数据大小和分发区域，从多个运营商的CDN中选定分发成本有优势的CDN。

14.根据权利要求13所述的中心装置，其中，具备：

进展信息管理部(7g)，保持基于从CDN分发了更新数据的分发状况的预测值，

上述CDN供应商选定部考虑预测值来计算分发数据大小。

15.一种主机装置，是将从内容分发网络(CDN)下载的更新数据安装于重编对象的电子控制装置的主机装置(4)，其中，

在与上述CDN之间建立了传输层安全(TLS)的基础上，从该CDN下载并获取更新数据。

16.一种更新数据配置程序，其中，

使将更新数据配置于内容分发网络(CDN)的中心装置(2)执行：

公用密钥生成步骤，生成用于对更新数据进行加密的公用密钥；

更新数据加密步骤，通过上述公用密钥对上述更新数据进行加密；

公用密钥加密步骤，通过RSA公开密钥对上述公用密钥进行加密；

公用密钥储存步骤，将通过上述RSA公开密钥进行了加密的上述公用密钥储存在活动通知中；

CDN供应商选定步骤，根据分发方式、分发区域、通信协议、分发数据大小中至少任意一个，从多个运营商的CDN中选定分发成本有优势的CDN；

加密数据配置步骤，将通过上述公用密钥进行了加密的上述更新数据配置于该选定的CDN；以及

活动通知发送步骤，将储存了进行了加密的上述公用密钥的活动通知发送到重编对象的车辆侧系统。

17.一种更新数据获取程序，其中，

使将从内容分发网络(CDN)下载的更新数据安装于重编对象的电子控制装置的主机装置(4)执行：

更新数据获取步骤，在与上述CDN之间建立了传输层安全(TLS)的基础上，从该CDN下载并获取更新数据。