JP2022027058A - データ配信システム及びデータ配信方法 - Google Patents

Abstract

【課題】第三者機関が提供する複数のデータを取得し、自動車メーカが要求する任意の形式のデータに加工して配信する。【解決手段】車両向けコネクテッドサービスにおいて、データ配信システム（共通基盤）１０は、配信サーバ（ＯＥＭサーバ２０）から、データ収集依頼で取得対象とされる対象データ及びその取得先に関する要件を示す第１の要件情報と、対象データを配信サーバに配信する際に求められるデータフォーマットに関する要件を示す第２の要件情報と、を受信する命令受付部と、第１の要件情報から取得対象とされる対象データを第１の要件情報から取得先とされる第三者機関４０から取得するデータ取得部と、データ取得部が取得した対象データの夫々に対して、第２の要件情報に基づいて、データフォーマットの変換を行うデータ加工部と、データ加工部によるデータフォーマットの変換が行われた後の対象データを配信サーバに送信する配信部と、を備える。【選択図】図１

Description

本発明は、データ配信システム及びデータ配信方法に関し、車両にデータを配信する配信サーバに対して、複数の企業が保有する必要なデータを配信する車両向けのデータ配信システム及びデータ配信方法に適用して好適なものである。

現在、ＩｏＴ（Internet of Things）を利用したサービスが世の中に浸透するなかで、特に自動車とインターネットとが繋がる車両向けの「コネクテッドサービス」の技術進歩が目まぐるしい。自動車メーカがコネクテッドサービスを提供するにあたり、アプリケーションへの入力となり得るデータとして、ＯＥＭ（Original Equipment Manufacturer）や車両から収集されるプローブデータ（地図データ、位置情報、車部品の故障の有無、走行距離、速度等）の活用が現状としてある。

今後、車両向けのコネクテッドサービスはさらに多様化し、ユーザのニーズも複雑化していくことが想定され、ＯＥＭは第三者機関（third party）のデータを活用し、既存データと組み合わせることで付加価値を出して、新たなサービスを提供するシーンも出てくると考えられる。将来的にこれらの利用シーンを実現するためには、第三者機関から収集したデータを自動車メーカが要求する適切なデータに加工し提供する技術が必要となる。

このような利用シーンを実現する際に活用可能と考えられる従来技術として、例えば特許文献１には、車両に搭載されている車載器に必要な入力データを配信するために、フィルタ条件ファイルと１対１に紐付くデータを車両に配信する仕組みを有するデータ配信システムが開示されている。

特開２０１９－１６５４４４号公報

特許文献１に開示された技術によれば、上述した利用シーンの実現に際して、フィルタ条件の仕組みを活用することによって車両へのデータの配信制御が可能となる。しかしながら、車両向けのコネクテッドサービスにおいて上述した利用シーンを実現するためには、車両のデータ要求に対して、第三者機関から複数データを取得する仕組みと、取得した複数データを１つのデータに集約して車両が要求したデータ形式に加工する仕組みとが必要であり、特許文献１には、これらの仕組みについて開示されていない。

本発明は以上の点を考慮してなされたもので、第三者機関が提供する複数のデータを取得し、自動車メーカが要求する任意の形式のデータに加工して配信することが可能なデータ配信システム及びデータ配信方法を提案しようとするものである。

かかる課題を解決するため本発明においては、車両へのサービス提供元が所有する配信サーバからのデータ収集依頼に応じて、データを保有する１以上の第三者機関から１以上の対象データをそれぞれ取得し、前記配信サーバに配信するデータ配信システムであって、前記配信サーバから、前記データ収集依頼で取得対象とされる前記対象データ及びその取得先に関する要件を示す第１の要件情報と、前記対象データを前記配信サーバに配信する際に求められるデータフォーマットに関する要件を示す第２の要件情報と、を受信する命令受付部と、前記第１の要件情報から取得対象とされる前記対象データを、前記第１の要件情報から取得先とされる前記第三者機関から取得するデータ取得部と、前記データ取得部が取得した前記対象データのそれぞれに対して、前記第２の要件情報に基づいて、データフォーマットの変換を行うデータ加工部と、前記データ加工部による前記データフォーマットの変換が行われた後の前記対象データを前記配信サーバに送信する配信部と、を備えるデータ配信システムが提供される。

また、かかる課題を解決するため本発明においては、車両へのサービス提供元が所有する配信サーバからのデータ収集依頼に応じて、データを保有する１以上の第三者機関から１以上の対象データをそれぞれ取得し、前記配信サーバに配信するデータ配信システムによるデータ配信方法であって、前記配信サーバから、前記データ収集依頼で取得対象とされる前記対象データ及びその取得先に関する要件を示す第１の要件情報と、前記対象データを前記配信サーバに配信する際に求められるデータフォーマットに関する要件を示す第２の要件情報と、を受信する命令受付ステップと、前記命令受付ステップの後、前記第１の要件情報から取得対象とされる前記対象データを、前記第１の要件情報から取得先とされる前記第三者機関から取得するデータ取得ステップと、前記データ取得ステップで取得された前記対象データのそれぞれに対して、前記第２の要件情報に基づいて、データフォーマットの変換を行うデータ加工ステップと、前記データ加工ステップで前記データフォーマットの変換が行われた後の前記対象データを前記配信サーバに送信する配信ステップと、を備えるデータ配信方法が提供される。

本発明によれば、第三者機関が提供する複数のデータを取得し、自動車メーカが要求する任意の形式のデータに加工して配信することができる。

本発明の一実施形態に係るデータ配信システム１０を用いた車両向けコネクテッドサービス１の概略構成例を示す図である。 共通基盤１０の構成例を示すブロック図である。 ＥＣＵ向けのデータ取得要件表１７の一例を示す図である。 車両向けコネクテッドサービス１における全体処理の手順例を示すシーケンス図である。 データ取得処理の詳細な手順例を示すシーケンス図である。 データ取得処理における各種データの取り扱いのイメージを説明するための図である。 データ加工処理の詳細な手順例を示すシーケンス図である。 データ加工処理によるデータの変換イメージを説明するための図である。 ナビ向けのデータ取得要件表２７の一例を示す図である。

以下、図面を参照して、本発明の実施形態を詳述する。

図１は、本発明の一実施形態に係るデータ配信システム１０を用いた車両向けコネクテッドサービス１の概略構成例を示す図である。図１に示した車両向けコネクテッドサービス１は、数年後の実現が想定される次期コネクテッドサービスである。

本実施形態に係るデータ配信システム１０は、車両３０へのサービスの提供においてＯＥＭサーバ２０が車両３０向けに提供するデータを、第三者機関（third party）４０である企業Ａ～企業Ｄの企業サーバ４１～４４から収集してＯＥＭサーバ２０に配信（提供）するデータ配信システムであって、以降では共通基盤１０と称する。共通基盤１０は、物理的なサーバ及びデータベースから構成されてもよいし、クラウドで構成されてもよい。

ＯＥＭサーバ２０は、車両３０にサービスを提供するサービス提供元（主に自動車メーカ）が保有している配信サーバであって、車両３０及び共通基盤１０と通信可能に構成される。ＯＥＭサーバ２０は、車両３０からのアプリケーションの起動や利用の要求に応じて、当該アプリケーションに必要なデータを第三者機関４０の企業サーバ４１～４４から共通基盤１０を介して受け取り、車両３０に提供する役割を有する。なお、上記「アプリケーション」は、例えば、車両３０に搭載されたアプリケーションであって、「アプリケーションに必要なデータ」とは、例えば、当該アプリケーションを起動・利用する場合に、ＥＣＵ（Electronic Control Unit）等の車両３０の車載器が必要とするデータに相当する。また、ＯＥＭサーバ２０は、共通基盤１０から受け取った第三者機関４０のデータだけでなく、ＯＥＭサーバ２０等が保持する既存データとも組合せることによって、付加価値を追加してサービスを提供してもよい。

第三者機関４０は、本例では、企業Ａ～企業Ｄで構成されるとし、各企業の企業サーバ４１～４４（データベースと考えてもよい）が、車両３０が利用するアプリケーションで必要とされる様々なデータを保持し、共通基盤１０からの要求に応じてこれらのデータを共通基盤１０に提供する。第三者機関４０が提供する「データ」は、アプリケーションの起動や利用に必要なデータであって、具体的には例えば、セキュリティーパッチ、画像、音声、動画、気候データ、交通情報、または地図データ等である。

図１を参照しながら、車両向けコネクテッドサービス１のおおよその振る舞いを説明すると、まず、車両３０からＯＥＭサーバ２０に対して、アプリケーションの起動や利用の要求（以後、アプリ利用要求と称する）が依頼される。アプリ利用要求を受けたＯＥＭサーバ２０は、アプリ利用要求で求められているデータの収集を共通基盤１０に要求する（以後、データ収集依頼と称する）。データ収集依頼を受けた共通基盤は、複数の第三者機関４０（より厳密には企業サーバ４１～４４）から、データ収集依頼に応じたデータを取得及び加工した後、ＯＥＭサーバ２０に提供する。そして、共通基盤１０から提供された第三者機関のデータをＯＥＭサーバ２０が車両３０に配信することにより、車両３０からのアプリ利用要求に応える。

図２は、共通基盤１０の構成例を示すブロック図である。図２に示すように、共通基盤１０は、命令受付部１１、データ取得部１２、データ加工部１３、配信部１４、及びデータ記憶部１５を備えて構成される。

共通基盤１０の構成のうち、命令受付部１１、データ取得部１２、データ加工部１３、及び配信部１４の各機能部は、共通基盤１０が実装されるサーバ等のプロセッサ（例えばＣＰＵ（Central Processing Unit））が、所定のプログラムをメモリに読出して実行することによってそれぞれが有する機能が実現され、外部装置（ＯＥＭサーバ２０や第三者機関４０の企業サーバ４１～４４）とデータの送受信を行う際には、不図示のネットワークＩ／Ｆが用いられる。各機能部の詳細は、処理の説明で後述する。

共通基盤１０のデータ記憶部１５は、データベース等の記憶手段によって実現される。図２に示したように、データ記憶部１５は、具体的には、企業ＩＤマスタ１６及びデータ取得要件表１７を記憶する。

企業ＩＤマスタ１６は、各企業（ＯＥＭサーバ２０の企業、及び第三者機関４０の企業Ａ～企業Ｄを含む）にユニークに割り当てられた企業ＩＤを管理するマスタデータであって、共通基盤１０によって管理されるデータである。より具体的には、企業ＩＤマスタ１６には、共通基盤１０によるデータ収集のサービスを利用可能なＯＥＭサーバ２０の企業ＩＤが管理される他、共通基盤１０がデータ取得先として利用可能な第三者機関４０の企業ＩＤが管理される。なお、企業ＩＤは、企業を単位として割り当てられるのではなく、各企業の情報処理システムを単位として（具体的には例えば、ＯＥＭサーバ２０ごと、企業サーバ４１～４４ごとに）割り当てられてもよく、その場合、企業ＩＤマスタ１６は、各企業の情報処理システムに割り当てられた企業ＩＤを管理するマスタデータとなる。

データ取得要件表１７は、ＯＥＭサーバ２０からのデータ収集依頼に応じて共通基盤１０が第三者機関４０から取得する必要があるデータの情報や、取得後のデータの変換方式の情報について定めた要件表であり、例えばテーブル形式のデータで実現される。データ取得要件表１７のフォーマットは、共通基盤１０を利用するユーザと、共通基盤１０を構築するベンダとの間で仕様の取り決めを行うことで、柔軟にフォーマットの変換ができるように構成されることが好ましい。そして、データ取得要件表１７の内容は、通常は、共通基盤１０とＯＥＭサーバ２０との間で取り決められ、共通基盤１０及びＯＥＭサーバ２０の双方で保持される。そして、アプリケーション側の仕様変更等によって、アプリ利用要求に対応して必要なデータ等が変わる場合（具体的には例えば、特定のデータについて取得の要・不要が変更される場合等）には、ＯＥＭサーバ２０においてデータ取得要件表１７のデータフォーマットの要件がカスタマイズされ、カスタマイズ後のデータ取得要件表１７が共通基盤１０に送信されてデータ記憶部１５に格納されることで、共通基盤１０とＯＥＭサーバ２０との間で同一内容のデータ取得要件表１７を保持することができる。

図３は、ＥＣＵ向けのデータ取得要件表１７の一例を示す図である。図３に示したように、データ取得要件表１７には、あるアプリケーション（アプリ）を起動または利用する際に必要なデータについて、車両３０におけるデータの使用主体のモジュール１７１（例えばＥＣＵ１、ＥＣＵ２）ごとに要件が登録され、さらに、これらのデータ要件は、共通基盤１０によるデータ取得の取得対象とされるデータとその取得先に関する要件を含む情報（要求データ１７２）と、共通基盤１０が取得したデータをＯＥＭサーバ２０に配信する際に求められるデータフォーマットに関する要件を含む情報（データ変換方式１７３）と、に大別できる。

図３に示したデータ取得要件表１７において、要求データ１７２は、データ名称１７２１、データの中身１７２２、フラグ１７２３、取得先企業コード１７２４、及びラベル１７２５の項目から構成される。

このうち、データ名称１７２１には、当該レコードの対象データの名称を示す情報が保持される。データ名称１７２１に保持されるデータの名称には、当該対象データの取得先の第三者機関４０の企業と共通基盤１０またはＯＥＭサーバ２０のユーザとの間で事前に取り決められたデータ名称が用いられる。また、データの中身１７２２には、当該対象データがデータ取得要求によって第三者機関４０から提供された場合に、その実データが埋め込まれる。

フラグ１７２３には、当該レコードの対象データがデータの取得元であるＯＥＭサーバ２０が取得したいデータであるか否か（すなわち、データ取得が必要であるか否か）を示すフラグ情報が保持される。具体的には例えば、取得対象のデータである場合は「１」のフラグが設定され、取得対象外のデータである場合は「０」のフラグが設定される。詳細は後述するが、フラグ１７２３は、データ取得部１２による制御に利用される。

取得先企業コード１７２４には、当該レコードの対象データのデータ取得先となる第三者機関４０（企業Ａ～企業Ｄ）の企業コードを示す情報が保持される。本例では、企業Ａの企業コードを「ａａａａ」、企業Ｂの企業コードを「ｂｂｂｂ」、企業Ｃの企業コードを「ｃｃｃｃ」、企業Ｄの企業コードを「ｄｄｄｄ」とする。上記例のように、企業コードは企業ごと（より厳密には、各企業が保有する企業サーバ４１～４４ごと）にユニークなコードが割り当てられることで、企業コードから一意にデータ取得先の第三者機関４０（厳密には企業サーバ４１～４４）を特定することができる。詳細は後述するが、取得先企業コード１７２４は、データ取得部１２による制御に利用される。

ラベル１７２５には、データ取得先の第三者機関４０（企業サーバ４１～４４）が管理しているデータベースから当該レコードの対象データを検索するためのキー情報として用いられる、ラベル情報が保持される。ラベル情報は特定の形態に限定されるものではないが、例えば、対象データの名称やデータ内容に関する検索ワードのような情報であってもよいし、また例えば、上記データベースにおける対象データの格納先を特定／絞り込みできるアドレス情報等であってもよい。詳細は後述するが、データ取得要求の際に、データ取得部１２が、取得先企業コード１７２４で示される取得先の第三者機関４０（企業サーバ４１～４４）に、ラベル１７２５に保持されるラベル情報を添えて送付することにより、データ取得要求を受領した第三者機関４０（例えば企業サーバ４１）は、対象データの検索を実施することができる。

また、図３に示したデータ取得要件表１７において、データ変換方式１７３は、データ名称１７３１、データ形式１７３２、データ桁数１７３３、文字コード１７３４、及び暗号化形式１７３５の項目から構成される。上述したように、データ変換方式１７３は、データ取得要求によって第三者機関４０（企業サーバ４１～４４）から取得したデータ（取得データ）に対して共通基盤１０のデータ加工部１３が実施する、データ変換（データ加工）に関する要件を定めたものであり、図３の場合は、取得データに文字データを想定した構成例が示されている。

データ名称１７３１は、取得データの名称を示す情報が保持され、これは、要求データ１７２の対応するレコードのデータ名称１７２１と同じである。そして、データ形式１７３２、データ桁数１７３３、文字コード１７３４、及び暗号化形式１７３５は、取得データに対してデータ加工部１３が実施するデータ変換のフォーマット（データの形式、データの桁数、データ内の文字コード、データに掛けられる暗号化の形式）がそれぞれ保持される。

詳細は後述するが、データ加工部１３は、このようなデータ変換方式１７３の要件に則った形式に取得データを加工することにより、複数の第三者機関４０（企業サーバ４１～４４）からフォーマットの異なる取得データが取得された場合であっても、取得データごとのデータ変換を経て、複数の取得データの形式を揃えたりすることができる。

なお、本実施形態に係る共通基盤１０において、第三者機関４０から入力されるデータ（取得データ）は、上記例のような文字データに限定されず、画像データや音声データ等であることも想定される。そのため、データ取得要件表１７は、各種のデータの形式に沿った変換方式で変換できるようにすることが好ましい。また、データ取得要件表１７における各要件の登録内容（保持情報）は、ユーザの要件に合わせて柔軟にカスタマイズ可能とする。

図４は、車両向けコネクテッドサービス１における全体処理の手順例を示すシーケンス図である。図４では、一例として、企業Ａの企業サーバ４１と企業Ｂの企業サーバ４２からデータを取得する場合について、全体的な処理手順が示されている。

図４によればまず、車両３０から所定のアプリケーションの起動や利用の要求（アプリ利用要求）がＯＥＭサーバ２０に送信される（ステップＳ１０１）。アプリ利用要求を受信したＯＥＭサーバ２０は、独自に車両３０と通信して、車両３０や車両ユーザの認証を行い（ステップＳ１０２）、認証及び認可の結果を車両３０に通知する（ステップＳ１０３）。そして上記通知後、ＯＥＭサーバ２０が、必要なデータの収集要求（データ収集依頼）を共通基盤１０に送信する（ステップＳ１０４）。より詳細には、ステップＳ１０４において、ＯＥＭサーバ２０は、データ収集依頼の命令とともに（または命令に含めて）、自サーバの企業ＩＤとデータ取得要件表１７を共通基盤１０に送信し、共通基盤１０の命令受付部１１がこれらを受信する。なお、命令受付部１１は、ステップＳ１０４で新たなデータ取得要件表１７を受信した場合、これをデータ記憶部１５に記憶する。

次に、共通基盤１０の命令受付部１１は、ステップＳ１０４で受信したＯＥＭサーバ２０の企業ＩＤを用いてＯＥＭサーバ２０の認証を行い（ステップＳ１０５）、認証及び認可の結果をＯＥＭサーバ２０に通知する（ステップＳ１０６）。より具体的には、ステップＳ１０５において、命令受付部１１は、ステップＳ１０４で受信したＯＥＭサーバ２０の企業ＩＤを、共通基盤１０のデータ記憶部１５に保持されている企業ＩＤマスタ１６と突合することによって、ＯＥＭサーバ２０が共通基盤１０によるサービスを利用可能であるか認証する。そして、ステップＳ１０５の認証によってＯＥＭサーバ２０の利用を認可した場合に、命令受付部１１は、ステップＳ１０６において認証及び認可の結果をＯＥＭサーバ２０に通知するとともに、ステップＳ１０４で受信したデータ取得要件表１７をデータ取得部１２に送信する。

次に、共通基盤１０では、データ取得部１２が、命令受付部１１から受領したデータ取得要件表１７に基づいて、第三者機関４０（本例では、企業Ａの企業サーバ４１と企業Ｂの企業サーバ４２）に対してデータの取得要求（データ取得要求）を行う（ステップＳ１０７，Ｓ１０８）。ステップＳ１０７，Ｓ１０８でデータ取得要求を受け取った第三者機関４０の企業サーバ４１，４２は、自身が管理しているデータベースから要求に沿ったデータを取得して共通基盤１０のデータ取得部１２に提供する（ステップＳ１０９，Ｓ１１０）。

次に、共通基盤１０のデータ取得部１２は、第三者機関４０の企業サーバ４１，４２からそれぞれ提供されたデータに対してデータの集約（グルーピング）を実施する（ステップＳ１１１）。ステップＳ１１１におけるデータの集約は、第三者機関４０から提供された複数のデータを、ＯＥＭサーバ２０を保有する企業（サービス提供元）が車両３０に提供するサービスに基づいたグループごとに、集約（グルーピング）することを意味する。「サービス提供元が車両３０に提供するサービスに基づいたグループ」とは、例えば、アプリケーション単位のグループを意味し、具体的には図３に示したデータ取得要件表１７の場合、モジュール１７１として管理される「ＥＣＵ１」や「ＥＣＵ２」に相当する。したがって、図３を参照しながら詳述すると、ステップＳ１１１においてデータ取得部１２は、第三者機関４０から提供された各データを、データ取得要件表１７のモジュール１７１ごとに、第三者機関４０から提供された各データをデータの中身１７２２に登録することによって、データを集約（グルーピング）する。その後、データ取得部１２は、データ集約後のデータ取得要件表１７をデータ加工部１３に送付する。なお、上述したデータ取得部１２及び第三者機関４０（企業サーバ４１，４２）を中心に実行されるステップＳ１０７～Ｓ１１１の処理（データ取得処理）については、図５，図６を参照しながら詳細を後述する。

次に、共通基盤１０のデータ加工部１３が、データ取得部１２から受領したデータ取得要件表１７に基づいて、集約されたデータに対するフォーマット変換（データ加工）を実施する（ステップＳ１１２）。そして、共通基盤１０の配信部１４が、ステップＳ１０４のデータ収集依頼に対する返答として、データ加工部１３による加工後のデータをＯＥＭサーバ２０に提供する（ステップＳ１１３）。なお、上述したデータ加工部１３によって実施されるステップＳ１１２の処理（データ加工処理）については、図７，図８を参照しながら詳細を後述する。

そして、ステップＳ１１３で共通基盤１０から提供されたデータを受領したＯＥＭサーバ２０は、独自の仕様に基づいてデータをパッケージングした後、車両３０にデータを配信する（ステップＳ１１４）。この結果、車両３０は、配信されたデータを用いて、アプリケーションの起動や利用を行うことができる（ステップＳ１１５）。

図５は、データ取得処理の詳細な手順例を示すシーケンス図である。図５に示すデータ取得処理は、図４のステップＳ１０７～Ｓ１１１の処理を詳細に示したものであり、主にデータ取得部１２及び第三者機関４０（例えば企業Ａの企業サーバ４１等）によって実行される。また、図６は、データ取得処理における各種データの取り扱いのイメージを説明するための図である。図６には、共通基盤１０（厳密にはデータ取得部１２）の他、図３で詳述したデータ取得要件表１７、及び第三者機関４０（企業Ａ～企業Ｄ）に保持されているデータが表されている。

以下、図５及び図６を参照しながら、データ取得処理の詳細な手順について説明する。なお、図５の説明では、簡略のため、第三者機関４０側の処理を企業Ａの企業サーバ４１に絞って説明するが、その他の第三者機関４０（企業サーバ４２～企業サーバ４４）における処理も、企業サーバ４１における処理と同様と考えてよい。

図５に示すデータ取得処理は、図４のステップＳ１０６において命令受付部１１が認証及び認可の結果をＯＥＭサーバ２０に通知し、ＯＥＭサーバ２０から受信したデータ取得要件表１７をデータ取得部１２に送信したあとから開始されている。

図５によればまず、共通基盤１０のデータ取得部１２は、命令受付部１１から送信されたデータ取得要件表１７を受領し（ステップＳ２０１）、受領したデータ取得要件表１７を参照する（ステップＳ２０２）。

次いでデータ取得部１２は、データ取得要件表１７から読み取ったデータの取得先の第三者機関４０（例えば企業サーバ４１）に対して、データの取得を要求する（ステップＳ２０３）。

ステップＳ２０３の処理について詳述する。まず、データ取得部１２は、データ取得要件表１７の要求データ１７２のフラグ１７２３を確認し、フラグ１７２３の値が「１」となっている場合に、当該レコードのデータ名称１７２１に示されるデータが取得対象のデータであると判断する。この場合、データ取得部１２はさらに、当該レコードの取得先企業コード１７２４に保持された企業コードを確認することにより、データ取得先の第三者機関４０（例えば企業Ａが保持する企業サーバ４１や企業Ｂが保持する企業サーバ４２）を特定することができる（図６のステップＳ２０３－１参照）。そして、データ取得部１２は、上記特定したデータ取得先に、当該レコードのラベル１７２５に保持されたラベル情報を添えて、データ取得要求を送付する（図６のステップＳ２０３－２参照）。ラベル情報は、第三者機関４０が内部で管理しているデータベースからどの情報を取得するかの検索キーとなり得る情報であり、このようなラベル情報を添えてデータ取得要求を送付することにより、第三者機関４０側では取得対象のデータの検索が可能となる。一方、データ取得要件表１７の要求データ１７２においてフラグ１７２３の値が「０」である場合は、当該レコードのデータ名称１７２１に示されるデータは取得対象外と判断できるため、データ取得部１２は、当該データに関してデータ取得要求の送付は行わない。

次に、データ取得先の第三者機関４０（例えば企業Ａの企業サーバ４１）が、ステップＳ２０３でデータ取得部１２から送付されたデータ取得要求及びラベル情報を受領し、データ取得要求を受け付ける（ステップＳ２０４）。次いで、第三者機関４０（例えば企業サーバ４１）は、受領したラベル情報を検索キーとして活用して、内部で管理しているデータベースから必要なデータ（取得データ）を選別し、これをデータ取得部１２に提供する（ステップＳ２０５）。なお、検索キーとして使用されるラベル情報のデータ数は、柔軟に変更できるものとする。

また、ステップＳ２０３～Ｓ２０５のデータのやり取りについては、一般的なセキュリティ対策が施されているとする。また、ステップＳ２０３において、データ取得部１２から他の第三者機関４０（例えば企業Ｂの企業サーバ４２）に対してもデータ取得要求が送付された場合は、当該第三者機関４０において同様に、取得データの選別及び提供が行われる。

次に、ステップＳ２０５で１以上の第三者機関４０（企業サーバ４１や企業サーバ４２）から取得データを受信したデータ取得部１２は、受信した各取得データを集約した上でデータ加工部１３に送付する（ステップＳ２０６）。

ステップＳ２０６の処理について詳述する。まず、取得データの集約として、データ取得部１２は、データ取得要件表１７において取得データに対応するレコードのデータの中身１７２２に、取得データの実データを埋め込む。このとき、予め定められたフォーマットに則って取得データをデータの中身１７２２に埋め込むようにしてもよい。また、データ取得要件表１７においてデータ取得要求の対象外のデータに対応するレコード（言い換えれば、フラグ１７２３の値が「０」であるレコード）のデータの中身１７２２には、例えば「ｎｕｌｌ」値を埋め込むとしてもよい（図６のＳ２０６も参照）。そして、各レコードのデータの中身１７２２に対する上記埋め込みが完了した後、データ取得部１２は、埋め込み後のデータ取得要件表１７を、データ加工部１３に送付する。

このようにステップＳ２０１～Ｓ２０６のデータ取得処理が行われることにより、共通基盤１０のデータ取得部１２は、データ取得要件表１７（より詳細には要求データ１７２）に基づいて、ＯＥＭサーバ２０によるデータ収集依頼（図４のステップＳ１０４）で所望されたデータを第三者機関４０から取得し、データ加工部１３に送ることができる。

図７は、データ加工処理の詳細な手順例を示すシーケンス図である。図７に示すデータ加工処理は、図４のステップＳ１１２の処理を詳細に示したものであり、データ加工部１３によって実行される。

図７に示すデータ加工処理は、図４のステップＳ１１１においてデータ取得部１２が第三者機関４０から取得したデータを集約（グルーピング）し、データ集約後のデータ取得要件表１７をデータ加工部１３に送信したあとから開始されている。

図７によればまず、データ加工部１３は、データ取得部１２から送信されたデータ取得要件表１７を受領し（ステップＳ３０１）、受領したデータ取得要件表１７を参照する（ステップＳ３０２）。

次いでデータ加工部１３は、データ取得要件表１７から読み取ったデータ変換方式に則って、データ取得部１２が第三者機関４０（企業サーバ４１～４４）から取得したデータを変換（加工）する（ステップＳ３０３）。上記のデータ変換方法は、図３に例示したデータ取得要件表１７において、データ変換方式１７３を構成するデータ名称１７３１以外の各項目（データ形式１７３２、データ桁数１７３３、文字コード１７３４、暗号化形式１７３５）の登録内容によって決定されるものであり、対象のデータごとに異なるデータ変換方式が登録されていてもよいし、モジュール１７１（例えばＥＣＵ１やＥＣＵ２）ごとに同一のデータ変換方式が登録されるとしてもよい。

図８は、データ加工処理によるデータの変換イメージを説明するための図である。図８には、図７のステップＳ３０３でデータ変換（データ加工）が行われる前のデータ取得要件表１７Ａ、及びデータ変換後のデータ取得要件表１７Ｂについて、データ変換の前後で変化する部分（具体的には、実データが埋め込まれるデータの中身１７２２）が示されている。なお、図８に記載されているデータ取得要件表１７Ａ，１７Ｂは、図３や図６に例示したデータ取得要件表１７と同様の構成を有する。また、データ取得要件表１７Ａは、図６においてＳ２０６の処理を経て集約（グルーピング）したデータ取得要件表１７の一部に対応するものであり、データの中身１７２２を例示したものである。

図８に示したデータ変換前のデータ取得要件表１７Ａとデータ変換後のデータ取得要件表１７Ｂとを比較すると、「ＥＣＵ１」、「ＥＣＵ２」何れの要求データ１７２においても、実データが埋め込まれている（ｎｕｌｌ以外の情報が保持されている）レコードにおけるデータの中身１７２２が、データ変換の前後で変化していることが分かる。具体的には例えば、「ＥＣＵ２」の「データＡ」の場合、データ変換前のデータ取得要件表１７Ａにおけるデータの中身１７２２は「○○○○」となっているが、データ変換後のデータ取得要件表１７Ｂにおけるデータの中身１７２２は「□□□□」となっている。これは、データＡに対応するレコードにおけるデータ変換方式１７３の登録内容に則ってデータ変換（データ加工）が行われたことにより、データＡの実データが「○○○○」から「□□□□」に変換（加工）されたことを意味する。一方、「ＥＣＵ１」の「データＡ」のように、データ取得要件表１７Ａにおけるデータの中身１７２２が取得対象外のデータを意味する「ｎｕｌｌ」であった場合には、データ取得要件表１７Ｂにおけるデータの中身１７２２も「ｎｕｌｌ」のままである。すなわち、取得対象外のデータに関しては、特段のデータ変換を行わないとしてもよい。かくして、図８に示したデータ取得要件表１７Ｂは、第三者機関４０から取得した複数の取得データについて、「ＥＣＵ１」や「ＥＣＵ２」といったモジュール１７１を単位として集約し、さらにデータ変換を行った結果を保持することができるものであり、換言すれば、複数の取得データを統合したデータを保持することができる。

図７の説明に戻る。上述したようにステップＳ３０３でデータ変換を行った後、データ加工部１３は、データ変換後の実データを埋め込んだデータ取得要件表１７（図８のデータ取得要件表１７Ｂに相当）を配信部１４に送付する（ステップＳ３０４）。

このようにステップＳ３０１～Ｓ３０４のデータ加工処理が行われることにより、共通基盤１０のデータ加工部１３は、データ取得要件表１７（より詳細にはデータ変換方式１７３）に基づいて、第三者機関４０から取得したデータを変換（加工）した上で配信部１４に送ることができる。すなわち、前述したデータ取得処理によって複数の第三者機関４０（企業サーバ４１～４４）からフォーマットの異なるデータが取得された場合であっても、データ加工処理が行われることにより、例えば「ＥＣＵ１」や「ＥＣＵ２」といったモジュール１７１ごとに取得データのフォーマットを統合したり、アプリケーションが取得データを利用する際に好適なフォーマットに取得データを変換したりすることができる。この結果、配信部１４は、アプリケーション（またはＯＥＭサーバ２０）にとって好適なフォーマットで、取得データをＯＥＭサーバ２０に配信することができる。

なお、本説明では、データ取得処理において、データ取得部１２が、第三者機関４０から取得したデータ（取得データ）をデータ取得要件表１７のデータの中身１７２２に埋め込んだ上でデータ加工部１３にデータ取得要件表１７を送付し、データ加工処理において、データ加工部１３がデータ取得要件表１７のデータの中身１７２２に埋め込まれた取得データに対してデータ変換を行う方法を説明したが、本実施形態に係る共通基盤１０において取得データを扱う方法は上記方法に限定されない。具体的には例えば、データ取得要件表１７がデータの中身１７２２を持たない構成とした場合には、データ取得処理においてデータ取得部１２は第三者機関４０から取得した取得データを、データ取得要件表１７とともにデータ加工部１３に送付し、データ加工処理においてデータ加工部１３は、データ取得要件表１７に基づいて、別途送付された取得データに対してデータ変換を行う、としてもよい。

以上に説明したように、本実施形態に係る共通基盤１０（データ配信システム１０）は、車両３０が必要とするデータの要求に対して、ＯＥＭサーバ２０から受領したデータ取得要件表１７の要求データ１７２に記載された情報（データ取得の要否を示すフラグ、データ取得先の第三者機関４０の企業ＩＤ、データ取得先における検索キーとなるラベル情報）に基づいて、取得対象のデータを第三者機関４０（企業サーバ４１～４４）からそれぞれ取得することにより、第三者機関４０から複数データを取得する仕組みを実現することができる。この結果、共通基盤１０では、１以上の第三者機関４０から１以上のデータをそれぞれ取得することができるため、ＯＥＭサーバ２０が必要とする複数のデータを共通基盤１０でまとめて収集することが可能となる。

さらに、本実施形態に係る共通基盤１０（データ配信システム１０）は、第三者機関４０から取得した各データを集約し、これら集約された各データに対して、データ取得要件表１７のデータ変換方式１７３に記載された情報（データ形式、データ桁数、文字コード、暗号化形式）に基づいて、データ変換（データ加工）を実施することにより、取得した複数データを１つのデータに集約して車両が要求したデータ形式に加工する仕組みを実現することができる。この結果、共通基盤１０が収集したデータをＯＥＭサーバ２０に配信した際、ＯＥＭサーバ２０における処理負荷を軽減する効果が得られる。

かくして、本実施形態に係る共通基盤１０（データ配信システム１０）によれば、第三者機関４０（企業サーバ４１～４４）が提供する複数のデータを取得し、自動車メーカが要求する任意の形式のデータに加工してＯＥＭサーバ２０に配信する技術を実現することができる。

なお、上述した本実施形態の説明では、車両３０側でアプリケーションを起動または利用するときにＥＣＵ等が必要とするデータを、データ配信システム１０（共通基盤１０）が第三者機関４０から取得してＯＥＭサーバ２０に配信することを例としたが、本実施形態に係るデータ配信システム１０（共通基盤１０）を適用可能な範囲は、ＥＣＵ等の上記例に限定されるものではない。本実施形態に係る共通基盤１０は、他にも例えば、車両３０に搭載されたヒューマンマシンインタフェース（ＨＭＩ：Human Machine Interface）の装置を用いて、ユーザが第三者機関４０が提供するコンテンツ情報（第三者機関が独自に開発したアプリケーション）を取得しようとする場合にも適用可能である。

上記のＨＭＩを利用したデータ取得について、例えば、車両に搭載されているカーナビゲーションシステム（ナビ）を例にとって説明すると、まず、ユーザがナビの画面を操作して取得したいコンテンツ情報を選択することにより、選択したコンテンツ情報のデータ取得がＯＥＭサーバ２０に依頼される。このとき、車両向けコネクテッドサービス１は、図４のステップＳ１０１の「アプリ利用要求」を「コンテンツ情報のデータ取得依頼」に置き換えることにより、図４のシーケンス図に沿って以後の全体処理を進めることができる。

そしてコンテンツ情報のデータ取得依頼を受けたＯＥＭサーバ２０は、データ収集依頼の際に（図２のステップＳ１０４）、当該コンテンツ情報を取得するための要件が記載されたナビ向けのデータ取得要件表２７を共通基盤１０に送付する。図９は、ナビ向けのデータ取得要件表２７の一例を示す図である。図９に例示したデータ取得要件表２７は、図３に例示したＥＣＵ向けのデータ取得要件表１７と同様のデータ構成を有するため、詳細な説明は省略する。

そして、共通基盤１０はＯＥＭサーバ２０から受領したデータ取得要件表２７に基づいて、第三者機関４０からコンテンツ情報のデータ取得を行い（データ取得処理）、取得したコンテンツ情報に対してデータ変換を行った（データ加工処理）うえで、ＯＥＭサーバ２０にコンテンツ情報を配信することができる。なお、データ取得処理には図５のシーケンス図を流用可能であり、データ加工処理には、図７のシーケンス図を適用可能である。

以上に説明したように、本実施形態に係るデータ配信システム１０（共通基盤１０）を用いた車両向けコネクテッドサービス１によれば、ＨＭＩにおけるコンテンツ情報の配信の仕組みも実現することができる。

なお、本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、図面において制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実施には殆ど全ての構成が相互に接続されていると考えてもよい。

１ 車両向けコネクテッドサービス
１０ データ配信システム（共通基盤）
１１ 命令受付部
１２ データ取得部
１３ データ加工部
１４ 配信部
１５ データ記憶部
１６ 企業ＩＤマスタ
１７（１７Ａ，１７Ｂ），２７ データ取得要件表
２０ ＯＥＭサーバ
３０ 車両
４０ 第三者機関
４１～４４ 企業サーバ

Claims (8)

1. 車両へのサービス提供元が所有する配信サーバからのデータ収集依頼に応じて、データを保有する１以上の第三者機関から１以上の対象データをそれぞれ取得し、前記配信サーバに配信するデータ配信システムであって、
   前記配信サーバから、前記データ収集依頼で取得対象とされる前記対象データ及びその取得先に関する要件を示す第１の要件情報と、前記対象データを前記配信サーバに配信する際に求められるデータフォーマットに関する要件を示す第２の要件情報と、を受信する命令受付部と、
   前記第１の要件情報から取得対象とされる前記対象データを、前記第１の要件情報から取得先とされる前記第三者機関から取得するデータ取得部と、
   前記データ取得部が取得した前記対象データのそれぞれに対して、前記第２の要件情報に基づいて、データフォーマットの変換を行うデータ加工部と、
   前記データ加工部による前記データフォーマットの変換が行われた後の前記対象データを前記配信サーバに送信する配信部と、
   を備えることを特徴とするデータ配信システム。
2. 前記第１の要件情報には、取得先の前記第三者機関において取得対象の前記対象データを抽出する際に利用可能な検索キーとなるラベル情報がさらに含まれ、
   前記データ取得部は、前記取得先の前記第三者機関に前記対象データの取得を要求する際に、当該対象データの前記ラベル情報を合わせて送付する
   ことを特徴とする請求項１に記載のデータ配信システム。
3. 前記第１の要件情報では、前記データ収集依頼で取得対象とされる複数の前記対象データが、前記サービス提供元が提供するサービスに基づいたグループに分けて管理され、
   前記データ取得部は、前記第三者機関から取得した複数の前記対象データを前記グループごとに集約し、
   前記データ加工部は、前記データ取得部で集約された複数の前記対象データのそれぞれに対して、前記データフォーマットの変換を行う
   ことを特徴とする請求項１に記載のデータ配信システム。
4. 前記サービス提供元に予め割り当てられた企業識別子のマスタデータを保持するデータ記憶部をさらに備え、
   前記命令受付部は、前記配信サーバから前記サービス提供元の前記企業識別子が付された前記データ収集依頼を受信し、当該企業識別子を前記マスタデータと照合することによって前記サービス提供元の認証を行う
   ことを特徴とする請求項１に記載のデータ配信システム。
5. 前記マスタデータには、前記第三者機関を構成する各企業に予め割り当てられた企業識別子がさらに含まれ、
   前記第１の要件情報には、前記データ収集依頼で取得対象とされ得る複数の候補データについて取得対象であるか否かを制御するためのフラグ情報と、それぞれの前記候補データを保有する前記第三者機関の前記企業識別子と、がさらに含まれ、
   前記データ取得部は、前記第１の要件情報の前記フラグ情報に基づいて、前記データ収集依頼で取得対象とされる前記対象データを判断し、前記第１の要件情報において当該対象データに対応する前記企業識別子を前記マスタデータと照合することによって、当該対象データの取得先を判断する
   ことを特徴とする請求項４に記載のデータ配信システム。
6. 前記第１の要件情報及び前記第２の要件情報は、テーブル形式の要件表データによって管理され、
   前記要件表データは、さらに、前記データ取得部によって前記第三者機関から取得された前記対象データまたは前記データ加工部による前記データフォーマットの変換が行われた後の前記対象データを埋め込み可能とする
   ことを特徴とする請求項１に記載のデータ配信システム。
7. 前記車両の車載器によってアプリケーションの利用が要求される場合、または、前記車両に搭載されたヒューマンマシンインタフェースに対するユーザ操作を契機として前記第三者機関が提供するコンテンツ情報の利用が要求される場合に、前記命令受付部は、前記配信サーバからの前記データ収集依頼を受信する
   ことを特徴とする請求項１に記載のデータ配信システム。
8. 車両へのサービス提供元が所有する配信サーバからのデータ収集依頼に応じて、データを保有する１以上の第三者機関から１以上の対象データをそれぞれ取得し、前記配信サーバに配信するデータ配信システムによるデータ配信方法であって、
   前記配信サーバから、前記データ収集依頼で取得対象とされる前記対象データ及びその取得先に関する要件を示す第１の要件情報と、前記対象データを前記配信サーバに配信する際に求められるデータフォーマットに関する要件を示す第２の要件情報と、を受信する命令受付ステップと、
   前記命令受付ステップの後、前記第１の要件情報から取得対象とされる前記対象データを、前記第１の要件情報から取得先とされる前記第三者機関から取得するデータ取得ステップと、
   前記データ取得ステップで取得された前記対象データのそれぞれに対して、前記第２の要件情報に基づいて、データフォーマットの変換を行うデータ加工ステップと、
   前記データ加工ステップで前記データフォーマットの変換が行われた後の前記対象データを前記配信サーバに送信する配信ステップと、
   を備えることを特徴とするデータ配信方法。
   

Images