特表2024-543393 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ ダイムラー・アクチェンゲゼルシャフトの特許一覧

特表2024-543393車両内のハードウェア環境及びソフトウェア環境における支払システム

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

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

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

(11)【公表番号】

(43)【公表日】2024-11-21

(54)【発明の名称】車両内のハードウェア環境及びソフトウェア環境における支払システム

(51)【国際特許分類】

G06Q 20/30 20120101AFI20241114BHJP

G06Q 20/12 20120101ALI20241114BHJP

【ＦＩ】

G06Q20/30

G06Q20/12

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024527456

(86)(22)【出願日】2022-10-24

(85)【翻訳文提出日】2024-06-25

(86)【国際出願番号】 EP2022079533

(87)【国際公開番号】W WO2023088640

(87)【国際公開日】2023-05-25

(31)【優先権主張番号】102021005678.7

(32)【優先日】2021-11-16

(33)【優先権主張国・地域又は機関】DE

(81)【指定国・地域】

(71)【出願人】

【識別番号】598051819

【氏名又は名称】メルセデス・ベンツグループアクチェンゲゼルシャフト

【氏名又は名称原語表記】Ｍｅｒｃｅｄｅｓ－ＢｅｎｚＧｒｏｕｐＡＧ

【住所又は居所原語表記】Ｍｅｒｃｅｄｅｓｓｔｒａｓｓｅ１２０，７０３７２Ｓｔｕｔｔｇａｒｔ，Ｇｅｒｍａｎｙ

(74)【代理人】

【識別番号】100090583

【弁理士】

【氏名又は名称】田中清

(74)【代理人】

【識別番号】100098110

【弁理士】

【氏名又は名称】村山みどり

(72)【発明者】

【氏名】イェルク・エックハルト

(72)【発明者】

【氏名】マルティーン・ケプラー

【テーマコード（参考）】

5L020

【Ｆターム（参考）】

5L020AA27

5L020AA62

(57)【要約】

本発明は、車両（８）内のハードウェア環境及びソフトウェア環境における支払システム（１）に関し、車両（８）内の制御装置又はアプリケーションに有料のアップデート又は有料のサービスを提供するものである。本発明は、通信が、バックエンド（７）から中央の通信モジュール（６）を経由して車両（８）内のユーザインタフェース（４）に至る、静的で普遍的且つ抽象化されたインタフェース（５ａ）を介して、事前に定義された形で行われるものであり、アプリケーション（３）とユーザインタフェース（４）との間の静的で普遍的且つ抽象化されたインタフェース（２）を介して、任意の支払サービスがマッピング可能とされ、アプリケーション（３）と通信モジュール（６）とバックエンド（７）との間で動的なアプリケーション依存インタフェース（５ｂ）を介して、支払プロセスが処理可能とされ、且つ支払プロセス及びユーザインタラクションに必要とされる全ての情報が伝送可能とされることを特徴とする。

【特許請求の範囲】

【請求項1】

車両（８）内のハードウェア環境及びソフトウェア環境における支払システム（１）であって、
前記車両（８）内の制御装置又はアプリケーションに有料のアップデート又は有料のサービスを提供する、前記支払システム（１）において、
通信が、バックエンド（７）から中央の通信モジュール（６）を経由して前記車両（８）内のユーザインタフェース（４）に至る、静的で普遍的且つ抽象化されたインタフェース（５ａ）を介して、事前に定義された形で行われるものであり、
前記アプリケーション（３）と前記ユーザインタフェース（４）との間の静的で普遍的且つ抽象化されたインタフェース（２）を介して、任意の支払サービスがマッピング可能とされ、
前記アプリケーション（３）と前記通信モジュール（６）と前記バックエンド（７）との間で動的なアプリケーション依存インタフェース（５ｂ）を介して、支払プロセスが処理可能とされ、且つ前記支払プロセス及びユーザインタラクションに必要とされる全ての情報が伝送可能とされることを特徴とする、前記支払システム。

【請求項2】

データが前記ユーザインタフェース（４）に伝送され、前記データは、事前定義されたデータ構造に応じて及び所定の方式に従い解釈され、処理され及び表示されることを特徴とする、請求項１に記載の支払システム（１）。

【請求項3】

利用規約が提供され、必要に応じて顧客によって確認されることを特徴とする、請求項１又は２に記載の支払システム（１）。

【請求項4】

前記有料のサービスが、事前定義された表示構造に応じた特定の特徴に基づいて表示されることを特徴とする、請求項１から３のいずれか一項に記載の支払システム（１）。

【請求項5】

購入プロセス又は支払プロセスについて顧客による確認が行われるものであり、前記確認は、ラジオボタンを介して行うことができ、又は選択リストとして表示することができることを特徴とする、請求項１から４のいずれか１項に記載の支払システム（１）。

【請求項6】

購入完了後に、前記支払システムを介して前記支払プロセスが開始されることを特徴とする、請求項１から５のいずれか一項に記載の支払システム（１）。

【請求項7】

前記支払プロセスの開始後に、購入した有料のサービスが有効になることを特徴とする、請求項６に記載の支払システム（１）。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、請求項１の上位概念により詳細に定義されているような、車両内のハードウェア環境及びソフトウェア環境における支払システムに関する。

【背景技術】

【0002】

基本的に、車両に表示され、且つ支払プロセスをトリガすることができる支払システムが、従来技術から公知である。
例えば、特許文献１には、外部から無線により支払注文を受理し、車両から処理を行うことを可能にする車両支払システムが記載されている。

【0003】

しかしながら、公知の支払システムは、既知の１つの適用事例に限定されていて、カスタマイズされている。従って、車両内のユーザインタフェース（ＵＩ）を用いる視覚化並びに操作を、実装に先立って規定する必要がある。これは、関与する全ての制御装置の必要な情報を、適用事例に合わせて提供して表示するためには、関与する制御装置の通信関係を実装前に適合させなければならないことに拠る。

【0004】

支払プロセスとして、例えば、電気自動車を充電する際の充電プロセスの支払が考えられる。更には、他のサービスについても同様に、この支払プロセスによって支払うことができる。例えば、通行料金のためのステッカー、特にスイス又はオーストリアのビネットのような商品の代金を、この種の支払システムを用いて車両から支払うことができる。公知の支払システムでは、どのような支払プロセスを実施することになるかをユーザインタフェースが事前に確定する必要があることは欠点である。例えば、ここで問題となっている充電プロセスは、特定数のキロワット時で特定の購入価格となる充電プロセスであり、この特定の購入価格は特定の合計金額で支払われれることが確定されなければならない。更に、ユーザインタフェースは、例えば特定の購入価格で所定の有効期間、例えば１年間有効な通行料金のステッカーの支払を行うかどうかを事前に確定しなければならない。この場合、プロセス毎に異なるデータ、異なる視覚化、並びに異なる選択オプションが利用される。
従って、公知の支払システムでは、有料のサービス又は有料のアプリケーションが事前に分かっていないと、それに応じたユーザインタフェースを設計できないという欠点がある。更に、支払プロセスのサービスを利用できるようにするためには、通信相手においても実装が行われていなければならない。ここでは、例えば、通信レイヤ（ＮＣＤ）の長期の指定期日も順守されるべきである。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】ＷＯ２０１５／０１６９２９Ａ１

【発明の概要】

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

【0006】

本発明の課題は、上記の欠点を克服する、車両用の支払システムを提供することである。

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

【0007】

本発明によれば、この課題は、請求項１に記載の特徴、またここでは特に請求項１の特徴部分に記載の特徴を備えた支払システムによって解決される。有利な構成及び発展形態は、請求項１に従属する請求項から明らかになる。

【0008】

本発明による支払システムの中核では、通信が、バックエンドから中央の通信モジュールを経由して車両のユーザインタフェースに至る、静的で普遍的且つ抽象化されたインタフェースを介して、事前に定義された形で行われるものであり、アプリケーションとユーザインタフェースとの間の静的で普遍的且つ抽象化されたインタフェースを介して、任意の支払サービスがマッピング可能とされ、アプリケーションと通信モジュールとバックエンドとの間で動的なアプリケーション依存インタフェースを介して、支払プロセスが処理可能とされ、且つ支払プロセス及びユーザインタラクションに必要とされる全ての情報が伝送可能とされる。

【0009】

支払システムは、車両内のハードウェア環境及びソフトウェア環境において設けられており、これは車両内の制御装置又はアプリケーションに有料のアップデート又は有料のサービスを提供するためである。

【0010】

従って、本発明によれば、有線の車両ネットワーク内の他の制御装置及びアプリケーションが固有の有料のサービスを処理できるようする支払システムを車両に統合することができる。このことは、車両ネットワーク通信における適合を行わずとも、汎用的な事前定義されたインタフェースを使用して行うことができる。換言すると、本発明によれば、汎用的なインタフェースを有する車両において、機敏で動的な支払システムが提供される。新規の有料サービス及び／又はアプリケーションの導入が、支払システム及びそのインタフェースの適合を行う必要なく可能である。従って、本発明によれば、有料のサービス及び／又はアプリケーションが、一般的に有効なインタフェースに関連付けられている。

【0011】

本発明による支払システムによって、車両ネットワーク内の希少なリソースの効率的な構成を達成することができる。例えば、サービスドメインの分離／カプセル化によってサービス開発が大幅に加速され、また労力及びコストが大幅に削減されるので、新規のサービスを導入したり変更したりしても、車両通信（ＮＣＤ）、ヘッドユニットソフトウェア／ＵＩソフトウェア、支払通信ラインの変更は不要である。従って、提案される支払システムは、支払サービス毎のインタフェースの変更を必要とせずに、新規の支払サービスを柔軟に導入することができる。

【0012】

アプリケーションとユーザインタフェースとの間の静的で普遍的且つ抽象化されたインタフェースは、車両支払通信ラインとも呼ぶことができる。この通信ラインに沿った通信は事前定義されており、好適には、通信内容に関して簡潔且つ効率的である、静的、普遍的及び／又は抽象化されたフォーマットに従う。特に、通信ラインは、任意の支払サービスをマッピングするように形成されている。ここでは、特定の支払プロセスを特徴付けるために、例えばＵＵＩＤ（Universally unique identifier）を利用することができる。プロセスＵＵＩＤとも称されるこの種のＵＵＩＤは、好適には、支払サービスによって提供され、また支払プロセスによって要求される。１つの別の実施形態では、サービスに対して複数の支払オプションが存在する場合、支払プロセスのためのプロセスＵＵＩＤの構造的下位に、種々の支払オプションのためのオプションＵＵＩＤを設けることができる。いずれの場合にも、支払プロセスが完了した際に、サービスを有効化するために、プロセスＵＵＩＤ及び／又はオプションＵＵＩＤを用いて、支払プロセスが成功したことを支払サービスにシグナリングすることができる。１つの別の実施形態では、有利には、ユーザインタフェースから支払サービスに対して少なくとも１回のフィードバックを行うことができ、その際に、例えばエラーメッセージや、不感帯（dead zone）などでの一時的に使用できない接続に関する情報を示すことができる。同様に、エラーメッセージを介して、プロセスの中断を示すことができる。

【0013】

アプリケーションと通信モジュールとバックエンドとの間の動的なアプリケーション依存インタフェースは、サービスドメイン通信ラインとも呼ぶことができる。好適には、この通信ライン又はこの通信は、完全にサービス開発者のドメイン内にある、及び／又は制御下にある。好適には、このインタフェースを介して、支払プロセス及びユーザインタラクションに必要とされる全ての情報がバックエンドに伝送される。特に、このラインに沿ったインタフェースを適切に設計することによって、伝送されるデータコンテンツは、将来のサービスに対していつでも柔軟に対応できるよう、柔軟に適応、補完及び／又は拡張することができる。換言すれば、このインタフェースは好適には、動的なインタフェースであるので、ＮＣＤを変更することなく、これまで知られていなかった別のサービスも伝送することができる。１つの実施形態では、例えば、事前定義されていないコンテンツを有するデータコンテナを使用することができる。１つの好適な実施形態では、サービスに対する具体的な支払プロセスへのコンテンツの対応付けを、プロセスＵＵＩＤを用いて、及び／又はバックエンドにおいては付加的に車両識別番号（ＶＩＮ）を使用して、特にオプションＵＵＩＤを使用して行うことができる。

【0014】

１つの実施形態では、サービスドメイン通信ラインにおいて、サービスの情報をバックエンドに送信することができるか、又はサービスに適合させて、サービスのバックエンド側において直接的に提供することができる。情報は、例えばアイコン及び／又は画像であってもよい。同様に、フォント、フォントサイズ、フォントカラー及び／又はフォント属性が含まれていてもよい。好適には、サービス並びに具体的な支払プロセス、即ち、もたらされた成果も表される。更には、数量、単位、単位当りのコスト、合計コスト、通貨名、通貨略称、適切に関連付けられたテキストセグメント又はアイコンを示すことができる。１つの実施形態において複数のオプションが利用できる場合、オプションＵＵＩＤを参照として使用して、種々のアイコン、画像、サービス並びに具体的な支払プロセスの名称、数量、単位、単位当りのコスト、合計コスト、通貨名、通貨略称、適切に関連付けられたテキストセグメント及び／又はアイコンを示すことができる。複数のオプションが存在する場合、データは、それらのオプションが排他的であるか否か、例えばラジオボタンによって選択可能であるか否か、又は複数のオプションが同時に選択可能であるべきか否かについての情報を提供することができる。更には、コンテンツのフォーマット及び／又は表示についての情報を含むことができる。同様に、オプションとして、情報は、確認が必要な場合にオプションＵＵＩＤを有することができる利用規約の情報であってもよい。同様に、確認が必要とされるメニューポイントの情報、例えば「有料の注文」の際のメニューポイントの情報が含まれていてもよい。

【0015】

支払プロセスが処理され、支払プロセスに必要な全ての情報が伝送される場合、これは、支払システム通信ラインにおいて行うことができる。これは、好適には、関与するコンポーネントの内の１つ、特にユーザインタフェースについて変更を実施する必要なく、所定の固定の構造において、種々の要件を有する多数の異なるサービスをカバーすることができるように、汎用のインタフェースとして設計されている。１つの実施形態では、その種のデータ構造に対して、ＪＳＯＮオブジェクト、ＹＡＭＬ構造、及び／又はウェブページ記述言語、特にＨＴＭＬを使用することができる。サービスに対する具体的な支払プロセスへのコンテンツの対応付けを、サービスドメイン通信ラインに関して既に説明したように、プロセスＵＵＩＤを用いて、且つバックエンドにおいては、特に付加的に車両識別番号（ＶＩＮ）及び／又はオプションＵＵＩＤを用いて行うことができる。この場合、サービスドメイン通信ラインに関して既に説明したように行われてもよい。特に、情報は同じであってもよい。

【0016】

好適には、データがユーザインタフェースに伝送され、データは、事前定義されたデータ構造に応じて、及び所定の方式に従い解釈され、処理され及び表示され、それによってデータが顧客に提供される。

【0017】

本着想の非常に有利な発展形態によれば、利用規約が提供可能とされ、必要に応じて顧客によって確認される。この確認は、例えば記録することができ、また相応のオプションＵＵＩＤを用いて、支払システム通信ライン、サービスドメイン通信ライン、及び／又は車両支払通信ラインを介して、サービスに通信することができる。

【0018】

ここで、１つの有利な構成によれば、有料のサービスを、事前定義された表示構造に応じた特定の特徴に基づいて表示することができる。更には、購入プロセス及び支払プロセスのユーザによる確認を実施させ、それを記録し、またプロセスＵＵＩＤを用いて、支払システム通信ライン、サービスドメイン通信ライン、及び／又は車両支払通信ラインを介して、サービスに通信することができる。１つの別の実施形態では、このことは、支払プロセスの正常な完了後に初めて行うことができる。

【0019】

１つの別の有利な構成では、購入プロセス又は支払プロセスを顧客に確認させることができ、この確認を、ラジオボタンを介して行わせることができるか、又は選択リストとして表示することができる。このことは、サービスオプションの要件に応じて行われる。続いて、この確認を記録することができ、またオプションＵＵＩＤを用いて、支払システム通信ライン、サービスドメイン通信ライン、及び／又は車両支払通信ラインを介して、サービスに通信することができる。１つの別の実施形態では、このことは、支払プロセスの正常な完了後に初めて行うことができる。

【0020】

１つの有利な実施形態では、購入完了後に、支払システムを介して支払プロセスが開始可能とされる。

【0021】

１つの別の有利な実施形態では、支払プロセスの開始後に、購入した有料のサービスが有効とされ得る。１つの別の実施形態では、車両支払通信ラインにおいて支払プロセスの要求がシグナリングされた後に、所定時間内にバックエンドから情報が提供されない場合、又はコネクションが存在しない場合、ユーザインタフェースはそれに応じて、例えば情報を出力するか、又は指示「暫くお待ちください」を出力することによって反応することができる。

【0022】

更に、本発明による支払システムの別の利点は、残りの従属請求項からも生じ、また図面を参照しながら下記において詳細に説明する実施例に基づき明らかになる。

【図面の簡単な説明】

【0023】

【図1】支払システムの１つの可能な実施形態を概略図で示す。

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

【0024】

図１には、支払システム１の１つの可能な実施形態が概略図で示されている。この図には、車両８及びバックエンド７から成るシステム全体が示されている。バックエンド７を介して、例えば、支払プロセスをトリガするための外部の支払サービスプロバイダ８に接続することができる。車両８は、通信モジュール６を含み、この通信モジュール６は、特に制御装置として形成されており、またクラウドへの接続を提供することができる。ヘッドユニット１０も同様に車両８に含まれており、またヘッドユニット１０は、特に中央のテレマティックプラットフォームとして形成されており、この中央のテレマティックプラットフォームにおいて、ユーザインタフェース４を表示して、そのユーザインタフェース４の操作を行うこともできる。更に、別の制御装置、アプリケーション３、及び／又は有料のサービスを提供することができるサービスが車両８に組み込まれている。電子的な支払システム１１は、従って、支払サービスプロバイダ９、バックエンド７、通信モジュール６、ヘッドユニット７、並びにユーザインタフェース４の一部を含む。従って、車両４には、制御装置若しくはアプリケーション３において実行されるか、又は部分的にはバックエンド７においても実行される本来の有料のサービスがマッピングされている。それと共に、インタフェース５ａにおいて、バックエンド７からヘッドユニット１０までの支払システム通信ラインを形成することができる。別のサービスドメイン通信ラインは、インタフェース５ｂにおいて通信モジュール６を介してバックエンド７まで延びている。車両８内では、サービスからヘッドユニット１０を介してユーザインタフェース４まで延びる車両支払通信ライン２が形成されている。従って、サービス１２のドメイン全体は、有料の制御装置、有料のアプリケーション３、又は有料のサービスから通信モジュール６を介して延びており、またバックエンドの一部も含む。

【図1】