JP2020088512A - 通信装置、プログラム、通信方法 - Google Patents

Abstract

【課題】低コストで異なる通信方法に対応することができる車載装置を提供すること。【解決手段】本発明は、アプリケーション部１１と、ネットワークに接続できる携帯端末と通信をするための第１の通信プロトコル部２１と、ネットワークに接続するための第２の通信プロトコル部１３，１４と、前記第１の通信プロトコル部と前記第２の通信プロトコル部の間の通信を中継する中継部２０と、を有し、前記アプリケーション部は、自機を宛先に指定して前記第２の通信プロトコル部を用いた通信を行うことで、前記中継部にデータを送信し、前記中継部は前記第１の通信プロトコル部を介して、前記アプリケーション部から受け取った前記データを前記携帯端末５０へ送信することを特徴とする通信装置を提供する。【選択図】図３

Description

本発明は、通信装置、プログラム、及び、通信方法に関する。

インターネットなどのネットワークに接続する通信機能を有する車両や、通信機能を利用して車両の情報を送信したりネットワーク上の情報を取得したりする車両が増えている。一定の定義はないが通信機能を利用して種々のサービスを実現する車両をコネクテッドカーという。

ネットワークへの接続を実現する通信方法としては、車両に搭載された通信装置又は車載装置がネットワークへ接続する通信方法（以下、第１の通信方法）と、車載装置に通信機能を有するスマートフォンなどを接続する通信方法（以下、第２の通信方法）がある（例えば、特許文献１参照。）。特許文献１には中継サーバに車両データを送信する通信システムが開示されている。

第１の通信方法では車両に搭載されている通信装置にＳＩＭカード（Subscriber Identity Module Card）が装着される。また、車載装置にＳＩＭカードを装着可能にすることも実用化されつつあるか、又は、少なくとも検討されている。第２の通信方法ではスマートフォンにＳＩＭカードが装着されている。

第１の通信方法では、ユーザが車載装置にスマートフォンなどを接続する作業が不要であるため、ユーザの操作性という点では有利だが、通信費を車載装置のメーカが負担しなければならない（場合によってはユーザがスマートフォンとは別に通信費を負担する）。第２の通信方法では、少なくともメーカが通信費を負担する必要はないが、車載装置にスマートフォンなどを接続する作業が必要となる。このように、車載装置が第１の通信方法と第２の通信方法のどちらで通信する方が有利であるか現状では断定できず、車載装置としては第１の通信方法と第２の通信方法の両方に対応することが求められる可能性がある。

特開2018−093396号公報

しかしながら、従来の技術では車載装置が異なる通信方法に対応することがコスト増になるという問題があった。まず、第１の通信方法では車載装置がネットワークに接続するが、第２の通信方法では車載装置がスマートフォンと接続するため、車載装置としては処理が異なりそれぞれに対応した処理が必要になる。図１を用いて説明する。

図１は、車載装置が第１の通信方法と第２の通信方法でそれぞれ通信する場合のインタフェース設計を模式的に示す図である。図１（ａ）は第１の通信方法において車載装置が通信する通信インタフェースを示す。図１（ｂ）は第２の通信方法において車載装置が通信する通信インタフェースを示す。第１の通信方法では車載装置がネットワークを介してサーバと通信するが、ＴＣＰ/ＩＰプロトコル１０１など汎用的な通信プロトコルが使用される場合が多い。このため、図１（ａ）では一例としてＴＣＰ/ＩＰプロトコル１０１を示した。車載装置で動作するアプリケーションソフト１１はＴＣＰ/ＩＰプロトコル１０１のソケットに相当するＴＣＰ/ＩＰインタフェース１０２を介してＴＣＰ/ＩＰプロトコル１０１による通信制御でサーバと通信する。

第２の通信方法では、車載装置がスマートフォンと通信する。車載装置がスマートフォンを介してネットワークに接続する場合、テザリングという通信方法を利用できる場合があるが、テザリングの利用が困難なスマートフォンも存在する。このようなスマートフォンでは、車載装置がスマートフォンと通信するために、スマートフォンに独自の独自プロトコル２１が車載装置にインストールされていることが要請される。独自プロトコル２１の使用を回避して車載装置がスマートフォンと通信することも不可能ではないが、スマートフォンのメーカからの認証が得られず、車載装置がこのスマートフォンに対応している旨を公表できなくなる。

車載装置に独自プロトコル２１がインストールされている場合、車載装置のアプリケーションソフト１１は、独自プロトコル２１が提供する独自インタフェース１０３を介して独自プロトコル２１を呼び出す。独自インタフェース１０３はいわゆるＡＰＩ（Application Interface）である。独自プロトコル２１がスマートフォンと通信するので、アプリケーションソフト１１はスマートフォンを介してネットワーク（サーバ）に接続することができる。

したがって、車載装置のメーカが、第１の通信方法に対応していた車載装置を第２の通信方法に対応させる場合、又は、この逆に第２の通信方法に対応していた車載装置１０を第１の通信方法に対応させる場合、アプリケーションソフト１１のインタフェース設計を変更する必要があり、開発コストの増大を生じさせてしまう。

本発明は、上記課題に鑑み、低コストで異なる通信方法に対応することができる車載装置を提供することを目的とする。

上記課題に鑑み、本発明は、アプリケーション部と、ネットワークに接続できる携帯端末と通信をするための第１の通信プロトコル部と、ネットワークに接続するための第２の通信プロトコル部と、前記第１の通信プロトコル部と前記第２の通信プロトコル部の間の通信を中継する中継部と、を有し、前記アプリケーション部は、自機を宛先に指定して前記第２の通信プロトコル部を用いた通信を行うことで、前記中継部にデータを送信し、前記中継部は前記第１の通信プロトコル部を介して、前記アプリケーション部から受け取った前記データを前記携帯端末へ送信することを特徴とする通信装置を提供する。

低コストで異なる通信方法に対応することができる車載装置を提供することができる。

車載装置が第１の通信方法と第２の通信方法でそれぞれ通信する場合のインタフェース設計を模式的に示す図である。 従来のソフトウェア構成例を示す図である。 本実施形態の車載装置のソフトウェア構成と通信経路を説明する図である。 サーバと車載装置が通信する通信システムの一例の構成図である。 車載装置が有する機能をブロック状に示す機能ブロック図の一例である。 ＯＳＩ参照モデル（ＴＣＰ/ＩＰ）モデルを説明する図の一例である。 サーバのＵＲＬ及びＨＴＴＰリクエストの一例を説明する図である。 経路ＣでミドルウェアがＨＴＴＰリクエストを送信する一例の手順を示すフローチャート図である。 ＨＴＴＰレスポンスの一例を示す図である。 車載装置のソフトウェア構成と受信時の通信経路の一例を説明する図である。 ＨＴＴＰレスポンスの受信時におけるミドルウェアの処理を説明する一例のフローチャート図である。 アプリケーションソフトがＳＩＭカードの装着を検出した場合に経路を切り替える一例の手順を示すフローチャート図である。

以下、本発明を実施するための形態について図面を参照しながら説明する。

＜通信方法の概略＞
まず、本実施形態の通信方法を説明するにあたって従来のソフトウェア構成を説明する。図２は、従来のソフトウェア構成例を示す図である。図２（ａ）は第１の通信方法で通信する場合のソフトウェア構成例である。上位層から、アプリケーションソフト１１、ＨＴＴＰクライアント１２、ＴＣＰソフト１３、ＩＰソフト１４、及び、ドライバソフト１５の階層構造を有している。アプリケーションソフト１１はＨＴＴＰクライアント１２を呼び出して、ＨＴＴＰクライアント１２はＴＣＰソフト１３を呼び出し、ＴＣＰソフト１３はＩＰソフト１４を呼び出し、ＩＰソフト１４はドライバソフト１５を呼び出して、サーバ３０と通信する。

図２（ｂ）は第２の通信方法で通信する場合のソフトウェア構成例である。上位層から、アプリケーションソフト１１、スマートフォン５０に独自の独自プロトコル２１、及び、ドライバソフト２２の階層構造を有している。アプリケーションソフト１１は独自プロトコル２１を呼び出して、独自プロトコル２１はドライバソフト２２を呼び出してスマートフォン５０と通信する。スマートフォン５０はサーバ３０と通信する。

なお、図２（ａ）のソフトウェア構成ではＨＴＴＰクライアント１２がある分だけ図１（ａ）と異なっているが、これは図１（ａ）ではＨＴＴＰクライアント１２が省略されているか、又は、アプリケーションソフト１１がＨＴＴＰクライアント１２の機能を有しているためである。図２（ａ）（ｂ）においても、第１の通信方法と第２の通信方法を切り替えるためには、車載装置１０のメーカ等が、アプリケーションソフト１１とＨＴＴＰクライアント１２の通信インタフェースを、アプリケーションソフト１１と独自プロトコル２１の通信インタフェースに変更する作業が必要である。したがって、開発コストの増大を生じさせてしまう点では同じである。

そこで、本実施形態では、図３に示すようなソフトウェア構成を採用することで、図１、図２で説明した課題を解決する。図３は、本実施形態の車載装置１０のソフトウェア構成と通信経路を説明する図である。

（１）まず、車載装置１０が自機に装着されたＳＩＭカードを使って、又は、車両に搭載されたＳＩＭカード内蔵の通信装置を使って、サーバ３０と通信する場合を説明する。この通信経路を経路Ａとする。この場合、アプリケーションソフト１１は従来（図２（ａ））と同様に、ＨＴＴＰクライアント１２、ＴＣＰソフト１３、ＩＰソフト１４、及び、ドライバソフト１５を経由してサーバ３０と通信する。

（２）次に、車載装置１０がスマートフォン５０を介してサーバ３０と通信する場合を説明する。この通信経路を経路Ｂとする。アプリケーションソフト１１は、ループバックアドレスを宛先のＩＰアドレスに指定する。ループバックアドレスはローカルホストとも呼ばれるが、自分自身を示すＩＰアドレスである。したがって、アプリケーションソフト１１から送信され、ＨＴＴＰクライアント１２、ＴＣＰソフト１３、及び、ＩＰソフト１４を経由したＨＴＴＰリクエストは、ＩＰソフト１４により自分（車載装置１０）宛であると判断され、予め決まっているミドルウェア２０のＴＣＰのポート番号に対応したソケットに書き込まれる。本実施形態ではミドルウェア２０がＲＡＷソケット２１０を使用する。したがって、ＩＰヘッダとＴＣＰヘッダでカプセル化されたままである。

ミドルウェア２０がスマートフォン５０と通信する通信経路を経路Ｃとする。ミドルウェア２０はＨＴＴＰリクエストの宛先のＩＰアドレスを、サーバ３０のＩＰアドレスに変更し、更に、スマートフォン５０の独自プロトコル２１に対応した独自インタフェース１０３を介して独自プロトコル２１を呼び出す。独自プロトコル２１はドライバソフト２２を介してＨＴＴＰリクエストをスマートフォン５０に送信する。スマートフォン５０はサーバ３０のＩＰアドレスを宛先とするＨＴＴＰリクエストをサーバ３０に送信する。

図３のような構成によれば、アプリケーションソフト１１は経路Ａを使用するか又は経路Ｂを使用するかを、宛先のＩＰアドレスを切り替えることで選択できるようになる。したがって、経路Ａを使用する場合と経路Ｂを使用する場合とで、アプリケーションソフト１１の変更は生じないか又は殆ど生じない。生じるとしても宛先のＩＰアドレスをサーバ３０とするか又はローカルホストとするかという最小限の変更でよい。また、ユーザによるＳＩＭカードの装着を検出して、宛先のＩＰアドレスを変更する機能をアプリケーションソフト１１が有していれば、アプリケーションソフト１１の変更は生じない。したがって、低コストで異なる通信方法に対応することができる車載装置１０を提供することができる。

＜用語について＞
ＳＩＭカードとは「Subscriber Identity Module Card」と英語で表記され、日本語では「加入者識別モジュールカード」という。ＳＩＭカードには、どの携帯電話会社を使っているかといった契約情報、携帯電話会社が提供する通信システムの加入者を特定する固有番号などが記録されている。ＳＩＭカードは識別情報記憶カードの一例である。

アプリケーション部は、種々のアプリケーションソフトであり、本実施形態ではアプリケーションソフト１１という用語で説明する。

第１の通信プロトコル部は、車載装置１０がスマートフォン５０と通信をするための通信プロトコルであり、本実施形態では独自プロトコル２１という用語で説明する。

第２の通信プロトコル部は、車載装置１０がネットワークに接続するための通信プロトコルであり、本実施形態ではＴＣＰソフト１３、ＩＰソフト１４という用語で説明する。ＴＣＰソフト１３はＵＤＰソフトでもよい。

＜システム構成例＞
図４はサーバ３０と車載装置１０が通信する通信システム１００の一例の構成図を示す。車載装置１０は車両に搭載された装置である。本実施形態の車載装置１０はサーバ３０と通信する機能を有していればよく、通信装置と称してもよい。ただし、ナビゲーション機能、及び、ＡＶ(Audio Visual)の再生機能の少なくとも一方の機能を有していてもよい。ナビゲーション機能は、出発地から目的地までの経路を検索して道路地図に設定し、ディスプレイに表示された電子地図に経路と現在地を表示したり、経路に基づいて進路変更の手前で音声案内や電子地図上のアニメーションなどで適切な進路を案内したりする機能である。ＡＶ機能とは、ラジオ・テレビで放送されたコンテンツ又はＤＶＤなどの記憶媒体に記憶されたコンテンツを再生したり、カメラで撮像した周囲の映像を表示したりする機能である。

これらの機能を有する車載装置１０は、ナビゲーション装置、チューナー、カーオーディオなどと呼ばれる場合がある。なお、ナビゲーション機能を有さずに、主にＡＶ機能と通信機能を有する装置をディスプレイオーディオという。ディスプレイオーディオは、スマートフォン５０などの端末装置との通信によりナビゲーションの機能を提供する。この場合、スマートフォン５０に搭載されるアプリがナビ画面等を生成し、このアプリが生成するナビ画面をディスプレイオーディオが通信で取得して表示する。スマートフォン５０で動作するこのようなアプリとしてCarPlay（登録商標）やAndroid Auto（登録商標）等が知られている。

また、車載装置１０の機能のうち経路の検索を図４のサーバ３０が行い、サーバ３０が経路及び地図データを車載装置１０に提供する形態も存在する。

車載装置１０は、車載された状態と携帯可能な状態の切り替えが可能であってよい。つまり、車載装置１０は、車両８に対し脱着可能であってよい。

本実施形態のサーバ３０は、車載装置１０と通信しうる情報処理装置である。通信する対象であれば具体的に提供する機能はどのようなものでもよい。例えば、経路検索や地図データを送信するサーバ３０、ユーザの音声データを認識して音声の認識結果を提供するサーバ３０、ユーザが検索した情報を返すサーバ３０、及び、各種のＷｅｂサーバが含まれる。

車両８にはスマートフォン５０が搭載されている場合と搭載されない場合がある。スマートフォン５０が搭載される場合、スマートフォン５０は基地局９に接続する機能を有する携帯端末であればよく、スマートフォン５０には限らない。例えば、ＳＩＭカードの装着が可能な、タブレット端末、ノートＰＣ、モバイルルータ、ＰＤＡ（Personal Digital Assistant）などでもよい。

＜機能について＞
図５を用いて、車載装置１０の機能について説明する。図５は、車載装置１０が有する機能をブロック状に示す機能ブロック図の一例である。車載装置１０は、アプリケーションソフト１１、ＨＴＴＰクライアント１２、ＴＣＰソフト１３、ＩＰソフト１４、ドライバソフト１５、ミドルウェア２０、独自プロトコル２１、ドライバソフト２２、遠距離通信部１６、近距離通信部２３、及び、ＳＩＭカード装着検出部１７を有している。

なお、車載装置１０が一般に有している可能性がある、ＧＰＳ受信機、自律航法用センサ、タッチパネル付きのディスプレイ、スピーカ、マイク、チューナー、及び、ＨＵＤ（Head Up Display）等については省略されている。また、車載装置１０はＣＰＵやＲＡＭなど一般的な情報処理装置の機能を有しているものとする。

まず、アプリケーションソフト１１は、何らかの通信を必要とするソフトウェアであればよい。例えば、ブラウザアプリ、ニュースアプリ、天気アプリ、動画再生アプリ、など様々なソフトウェアが考えられる。また、アプリケーションソフト１１は１つであるとは限らず複数ある場合が多い。

ＨＴＴＰクライアント１２はＨＴＴＰリクエストを生成し、ＨＴＴＰレスポンスを取得するソフトウェアである。現在のアプリケーションソフト１１はＨＴＴＰクライアント１２の機能を含む場合があり、アプリケーションソフト１１にＨＴＴＰクライアント１２が含まれる構成でもよい。

ＴＣＰソフト１３はＴＣＰという通信プロトコルに関する処理を行うソフトウェアであり、ＩＰソフト１４はＩＰという通信プロトコルに関する処理を行うソフトウェアである。ＴＣＰソフト１３は主に通信相手との間にＴＣＰコネクションを作る。そして、エラーチェック、応答確認に基づく再送制御、シーケンス番号に基づくデータの整列等を行う。ただし、経路Ｂが使用される場合、通信相手のＴＣＰが存在しないのでこれらの制御は必要ない。

ＩＰソフト１４は、ＩＰアドレスに基づいて適切なルーターに向けてパケットを送信するルーティングを行う。また、通信対象のデータを所定のパケットに分割して送信する。また受信時にはネットワークから自分宛のパケットを取り出して、パケットを再構築してＴＣＰソフト１３に渡す。

ドライバソフト１５は、遠距離通信部１６を実現する通信方式に応じたデバイスドライバである。遠距離通信部１６を実現する通信方式として３Ｇ、４Ｇ、５Ｇ、ＬＴＥなどが使用される場合、ドライバソフト１５はこれらに対応したデバイスドライバである。遠距離通信部１６は、３Ｇ、４Ｇ、５Ｇ、ＬＴＥなどの通信方式によりデータ通信を行い、サーバ３０とデータの送受信を行う。

ミドルウェア２０は、ループバックアドレスを宛先のＩＰアドレスとするＨＴＴＰリクエストを受信し、宛先のＩＰアドレスをサーバ３０のＩＰアドレスに変更するソフトウェアである。ミドルウェア２０はＲＡＷソケット２１０を使用して、ＩＰヘッダとＴＣＰヘッダでカプセル化されたままのＨＴＴＰリクエストを取り扱う。

データの受信時には、独自プロトコルから取得したＨＴＴＰレスポンス（ＩＰヘッダとＴＣＰヘッダでカプセル化された）をＲＡＷソケット２１０に書き込めばよい。ミドルウェア２０はこのようにデータを中継する中継部の機能を有する。

独自プロトコル２１は、スマートフォン５０に独自の通信処理を行うソフトウェアである。独自プロトコル２１はスマートフォン５０のメーカから提供される。処理内容はスマートフォン５０によって様々でよいが、本実施形態ではＴＣＰ／ＩＰと同等の処理を行うものとして説明する。

ドライバソフト２２は近距離通信部２３を実現する通信方式に応じたデバイスドライバである。近距離通信部２３を実現する通信方式としてBluetooth（登録商標）、ＵＳＢ、又は、Ｗｉ−Ｆｉなどが使用される場合、ドライバソフト２２はこれらに対応したデバイスドライバである。

近距離通信部２３は、Bluetooth（登録商標）、ＵＳＢ、又は、Ｗｉ−Ｆｉなどの通信方式によりデータ通信を行い、スマートフォン５０とデータの送受信を行う。

ＳＩＭカード装着検出部１７は車載装置１０のＳＩＭカードスロットにＳＩＭカードが装着されていることを検出する。ＳＩＭカードが装着されているか否かをアプリケーションソフト１１に通知することができる。

＜ＯＳＩ参照モデル（ＴＣＰ/ＩＰ）モデル＞
ＯＳＩ参照モデルはＩＳＯ（国際標準化機構）が定めた、ネットワーク機器のメーカが異なっても相互通信するための統一規格をいう。ＯＳＩ参照モデルは、コンピュータなどのネットワーク機器の通信機能を階層構造で分割したネットワークモデルで、通信プロトコルを７つの階層に分けて定義している。一般には、７つの階層の一部を統合して扱う「ＴＣＰ/ＩＰモデル」がデファクトスタンダードとなっている。

図６（ａ）は「ＴＣＰ/ＩＰモデル」を模式的に示す。上位層からアプリケーション層、トランスポート層、インターネット層、及び、ネットワークインタフェース層の４つの階層を有している。また、各階層には代表的な通信プロトコルが対応付けられている。ネットワークモデルをこのような階層構造とすることで、各階層の通信プロトコルは上位又は下位で使用される通信プロトコルの影響を受けずに通信できる。

ネットワークインタフェース層では直接接続されたノード間の通信について規定され、また、ビット列を電気信号に変換する変換方法について規定されている。インターネット層は、ＩＰアドレスに基づいてネットワークとネットワークを相互通信するための規定を定めている。トランスポート層はノード間のデータ転送の信頼性を確保するための規定を定めている。アプリケーション層は、通信プログラム間の論理的な経路の制御、及び、文字コードなどのデータの表現形式の規定を定めている。

図６（ｂ）はデータのカプセル化と非カプセル化を説明する図である。各階層の通信プロトコルは各階層の規定に従ったデータを送信するために、第４層から第１層の順で送り主や宛先などの情報（ヘッダ）を梱包していく。ヘッダを付すことをカプセル化といい、受信時にヘッダを除去することを非カプセル化という。ただし、ＲＡＷソケット２１０が使用された場合は、カプセル化と非カプセルは行われない。

図６（ｂ）の例では、送信時にアプリケーションソフト１１が作成したデータに、アプリケーション層（ＨＴＴＰクライアント１２）がＨＴＴＰヘッダを付し、トランスポート層（ＴＣＰソフト１３）がＴＣＰヘッダを付し、インターネット層（ＩＰソフト１４）がＩＰヘッダを付し、ネットワークインタフェース層（ドライバソフト１５）が物理ヘッダを付す。なお、物理ヘッダは実際の通信経路によって様々であり、例えば無線ＬＡＮのイーサネットフレーム（登録商標）のヘッダ、Bluetooth（登録商標）のヘッダなどである。受信時には第１層から第４層の順に各階層の通信プロトコルがヘッダを除去する。

＜送信時の通信＞
続いて、図３を参照して、車載装置１０がデータをサーバ３０に送信する際の通信方法について補足する。この通信方法は車載装置１０が有する図３のプログラム階層の全体又は一部のプログラムにより実現される。

（１）経路Ａの場合は、ネットワークを介した通常の通信と同様である。ＨＴＴＰクライアント１２とＴＣＰソフト１３はソケット通信によりサーバ３０と通信する。ソケット通信とは、アプリケーションソフト１１とＴＣＰ/ＩＰを結ぶインタフェースとしてソケット(Socket)を使用する通信方法であり、ＴＣＰ/ＩＰ通信では一般的な通信方法である。ＨＴＴＰクライアント１２はソケット生成、ソケット接続要求、データの受信/送信、及び、ソケットの切断を行う。ＨＴＴＰクライアント１２は相手との接続に関知せず、ソケットを通信インタフェースとする。サーバ３０との接続はＴＣＰソフト１３が確立する。アプリケーションソフト１１はソケット生成時にサーバ３０のＩＰアドレスとポート番号を指定する。したがって、ソケットはサーバ３０のＩＰアドレス及びポート番号と対応付けられている。車載装置１０のＩＰアドレスとアプリケーションソフト１１のポート番号はＴＣＰソフト１３が自動で付与する。

ＨＴＴＰクライアント１２は図７で説明するようなＨＴＴＰリクエストを、作成したソケットに書き込む。ＴＣＰソフト１３は例えばスリーウェイハンドシェイクのような接続手順でサーバ３０のＴＣＰソフトとコネクションを確立する。そして、ＴＣＰヘッダを付与したＨＴＴＰリクエストをＩＰソフト１４に渡す。ＩＰソフト１４はＨＴＴＰリクエストをパケットに分割し、更にＩＰヘッダを付与してドライバソフト１５に渡す。ドライバソフト１５は更に物理ヘッダを付与して伝送経路からデータを送信する。

（２）経路Ｂの場合、少なくともＴＣＰソフト１３までの処理は経路Ａと同様である。しかし、ＨＴＴＰクライアント１２が指定する宛先のＩＰアドレスはローカルホスト（ループバックアドレス）であり、ポート番号はミドルウェア２０を指定するポート番号である。また、ＨＴＴＰクライアント１２はＨＴＴＰリクエストの一部にサーバ３０のＩＰアドレス（ＵＲＬ）及びポート番号を付加する。付加する方法としては次述するクエストリングやＨＴＴＰメッセージのボディ部に書き込む方法がある。

なお、図３ではＨＴＴＰリクエストがＩＰソフト１４まで到達してからミドルウェア２０に届いているが、ＨＴＴＰリクエストは少なくともＴＣＰソフト１３まで到達すればよい。

ＨＴＴＰリクエストは、ＴＣＰソフト１３及びＩＰソフト１４で順次カプセル化されるが、ＨＴＴＰクライアント１２はループバックアドレスを宛先のＩＰアドレスに指定しミドルウェアのポート番号を指定しているので、ＴＣＰソフト１３はミドルウェア２０が作成したＲＡＷソケット２１０にＨＴＴＰリクエストを書き込む。ＲＡＷソケット２１０であるため、ＩＰソフト１４及びＴＣＰソフト１３は非カプセル化を行わない。なお、ＨＴＴＰリクエストを受信するという意味で、ミドルウェア２０は最小限のＷｅｂサーバの機能を有している。

ミドルウェア２０はＲＡＷソケット２１０からＨＴＴＰリクエストを取得し、ＨＴＴＰリクエストの宛先のＩＰアドレスをローカルホストからサーバ３０のＩＰアドレスに変更し、宛先のポート番号をミドルウェア２０のポート番号からサーバ３０のＩＰアドレスに変更する。ミドルウェア２０は、スマートフォン５０の独自プロトコル２１に対応した独自インタフェース１０３を介して独自プロトコル２１を呼び出して、ＨＴＴＰリクエストを独自プロトコル２１に渡す。ここでもＴＣＰヘッダとＩＰヘッダがついたまま、ＨＴＴＰリクエストが独自プロトコル２１に渡される。独自プロトコル２１はドライバソフト２２にＨＴＴＰリクエストを送信する。

なお、独自プロトコル２１がどのような処理を行うかは独自プロトコル２１に依存するものとする。

＜ＨＴＴＰリクエストの一例＞
図７を用いて、ＨＴＴＰリクエストについて説明する。図７はサーバ３０のＵＲＬ及びＨＴＴＰリクエストの一例である。例えば、ユーザが任意のサーバ３０にアクセスする場合、サーバ３０のＵＲＬをアプリケーションソフト１１に指示する。図７（ａ）はユーザが指示するＵＲＬの一例である。
http://www.server.com:80/index.html
「http」はスキームといい、ＨＴＴＰという通信プロトコルを使用していることを示している。「www」をホスト名といい、「server.com」をドメイン名という。ドメイン名により任意のサーバ３０を一意に指定できる。「80」はサーバ３０のポート番号であり、通常、Ｗｅｂサーバのポート番号は８０なので省略される場合もある。「index.html」はパスといい、要求するＨＴＭＬファイルがどこにあるかをパス（path）とファイル名で示す。

図７（ｂ）は、経路Ａにおいて図７（ａ）のＵＲＬが指示された場合に、ＨＴＴＰクライアント１２が作成するＨＴＴＰリクエストの一例である。なお、説明の便宜上、ＨＴＴＰリクエストの一部を省略している。
GET /index.html HTTP1.1
Host: www.server.com:80
「GET」はＨＴＴＰのメソッドの１つであり、ファイルを取得するメソッドである。「/index.html」は図７（ａ）のパスであり、「HTTP1.1」はＨＴＴＰのバージョンである。「Host: www.server.com:80」はサーバ３０のドメインとポート番号である。なお、「www.server.com」はＤＮＳサーバによりＩＰアドレスに変換される。

ＴＣＰソフト１３はＨＴＴＰクライアント１２が作成してソケットに書き込んだ図７（ｂ）のＨＴＴＰリクエストを、ソケットから受け取りサーバ３０とコネクションを確立する。

続いて、経路Ｂを使用する場合を説明する。経路Ｂを使用する場合もユーザが指示するＵＲＬは図７（ａ）と同様でよい。しかし、アプリケーションソフト１１は、経路Ｂが使用されることを検出しているか又はそのように設定されているため、ＵＲＬを変更する。

図７（ｃ）は、経路Ｂが使用される場合にアプリケーションソフト１１が設定を変更したＵＲＬを示す。
http://localhost:8080/middleware.jsp?=www.server.com:80/index.html
「localhost」はループバックアドレスを意味する。具体的には「127.0.0.1」であるためこの値に変更してもよい。「8080」はミドルウェア２０のポート番号であり、ミドルウェア２０が待ち受けるＲＡＷソケット２１０を意味する。「middleware.jsp」はミドルウェア２０を指定する情報である。「middleware.jsp」ミドルウェア２０を意味するソフトウェアのファイル名であり、「middleware.jsp」の指定によりミドルウェア２０が実行される。「?」以降をクエストリングといい、サーバ３０にパラメータを渡したい場合に任意の情報が設定できるようになっている。本実施形態では、ドメイン名が「localhost」に変更されているので、クエストリングによりサーバ３０のＵＲＬである「www.server.com:80/index.html」がクエストリングによりミドルウェア２０に通知されている。なお、このようにクエストリングによりサーバ３０のＵＲＬを通知するのでなく、ＨＴＴＰリクエストのボディ部にサーバ３０のＵＲＬを付加してもよい。

図７（ｄ）は経路Ｂにおいて、図７（ｃ）のＵＲＬが指示された場合に、ＨＴＴＰクライアント１２が作成するＨＴＴＰリクエストの一例である。
GET /middleware.jsp?=www.server.com:80/index.html HTTP/1.1
Host: localhost:8080
ＴＣＰソフト１３、ＩＰソフト１４は図７（ｄ）のＨＴＴＰリクエストをＨＴＴＰクライアント１２から受け取ると、それぞれヘッダでカプセル化する。一方、「Host: localhost」でループバックアドレスが指定されていることを検出し、また、「8080」でmiddleware.jspが待ち受けているＲＡＷソケット２１０のポート番号が分かるので、ＲＡＷソケット２１０に、
「GET /middleware.jsp?=www.server.com:80/index.html HTTP/1.1」
を書き込む。ミドルウェア２０は、ＲＡＷソケット２１０を監視しているのでＨＴＴＰリクエストを検出することができる。

＜ミドルウェアの処理＞
続いて、図８を用いてミドルウェア２０の処理を説明する。図８は、経路Ｃでミドルウェア２０がＨＴＴＰリクエストを送信する一例の手順を示すフローチャート図である。

ミドルウェア２０は監視しているポート番号（8080）のＲＡＷソケット２１０から図７（ｄ）で説明したＨＴＴＰリクエストを読み取る（Ｓ１）。

次に、ミドルウェア２０は、ＨＴＴＰリクエストを解析してサーバ３０のＵＲＬ、及び、ＨＴＴＰメソッドを取り出す（Ｓ２）。ＨＴＴＰメソッドはＨＴＴＰリクエストの先頭に記述されている。サーバ３０のＵＲＬは「？」以降に記述されている。このようにＨＴＴＰリクエストを解析することをパースといい、一般的なＷｅｂサーバで行われている。

次に、ミドルウェア２０は、サーバ３０のＵＲＬを宛先とするＨＴＴＰリクエストを作成する（Ｓ３）。ＨＴＴＰリクエストは例えば以下のようになる。
GET /index.html HTTP/1.1
Host: www.server.com:80
「GET」はＨＴＴＰメソッドをそのまま使用すればよい。「/index.html」はサーバ３０のＵＲＬのパスである。HTTP/1.1はそのまま使用できる。「www.server.com:80」はクエストリングに含まれるホスト名、ドメイン名、及び、ポート番号である。

次に、ミドルウェア２０は、独自プロトコル２１の独自インタフェース１０３を呼び出し、ＨＴＴＰリクエストを独自プロトコル２１に出力する（Ｓ４）。

＜ＨＴＴＰレスポンス＞
図９は、ＨＴＴＰレスポンスの一例を示す。ＨＴＴＰレスポンスはＨＴＴＰリクエストに対する応答としてサーバ３０から送信される。サーバ３０のＷｅｂアプリ等が送信するＨＴＴＰレスポンスは、レスポンス行２０１、ヘッダ２０２、及び、メッセージボディ２０３から構成されている。レスポンス行２０１は、通信が成功したか、失敗したかをステータスで示す。図９では「200」が通信の成功を示す。ヘッダ２０２は図６（ｂ）のＨＴＴＰヘッダである。メッセージボディ２０３は例えばＨＴＭＬデータなど、アプリケーションソフト１１が要求した情報である。

なお、サーバ３０からスマートフォン５０に送信されるデータには図６に示したように各階層のヘッダが付加されている。

＜受信時の通信＞
続いて、図１０を用いて車載装置１０がＨＴＴＰレスポンスを受信する場合の通信について説明する。図１０は、本実施形態の車載装置１０のソフトウェア構成と受信時の通信経路を説明する図である。

（１）車載装置１０が経路Ａで通信する場合、サーバ３０から送信されたＨＴＴＰレスポンスを、ドライバソフト１５、ＩＰソフト１４、及びＴＣＰソフト１３が順に非カプセル化し、ＴＣＰソフト１３はサーバ３０が宛先として設定したポート番号（送信時にＴＣＰソフト１３が付与したアプリケーションソフト１１のポート番号）のソケットにＨＴＴＰレスポンスを書き込む。ＨＴＴＰクライアント１２は作成したソケットにＨＴＴＰレスポンスが書き込まれたことを検出するとＨＴＴＰレスポンスをソケットから読み取り、アプリケーションソフト１１に渡す。このように、アプリケーションソフト１１が送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスがソケットで対応付けられ、アプリケーションソフト１１がＨＴＴＰレスポンスを受信できる。

（２）経路Ｃで通信する場合、サーバ３０から送信されたＨＴＴＰレスポンスを、スマートフォン５０が車載装置１０に転送する。独自プロトコル２１はドライバソフト２２から物理ヘッダが除去されたＨＴＴＰレスポンスを受信する。また、独自プロトコル２１は、ＩＰソフト１４及びＴＣＰソフト１３のヘッダについては非カプセル化せず、独自インタフェース１０３を介してミドルウェア２０にＨＴＴＰレスポンスを渡す。

ミドルウェア２０はＲＡＷソケット２１０にＩＰヘッダとＴＣＰヘッダついたままのＨＴＴＰレスポンスを書き込む。ＴＣＰソフト１３とＩＰソフト１４はＨＴＴＰレスポンスを送信しようとするが、ＲＡＷソケット２１０のＨＴＴＰレスポンスにはＩＰヘッダとＴＣＰヘッダを付けない。一方、ＴＣＰヘッダの宛先のＩＰアドレスは車載装置であり、宛先のポート番号はアプリケーションソフト１１である。このため、ＩＰソフト１４とＴＣＰソフト１３は受信のプロセスとして非カプセル化を行って、ＩＰアドレスとポート番号で特定されるソケット（送信時と同じソケット）にＨＴＴＰレスポンスを書き込む。

ＨＴＴＰクライアント１２は作成したソケットにＨＴＴＰレスポンスが書き込まれたことを検出するとＨＴＴＰレスポンスをソケットから読み取り、アプリケーションソフト１１に渡す。したがって、経路Ａと同様に、アプリケーションソフト１１がＨＴＴＰリクエストを受信できる。

＜受信時のミドルウェアの機能＞
図１１は、ＨＴＴＰレスポンスの受信時におけるミドルウェア２０の処理を説明する一例のフローチャート図である。

まず、ミドルウェア２０は独自プロトコル２１から、ＩＰヘッダとＴＣＰヘッダが付いたままのＨＴＴＰリクエストを受け取る（Ｓ１１）。どのように受け取るかはミドルウェア２０と独自プロトコル２１の独自インタフェース１０３に依存するが、ミドルウェア２０は独自プロトコル２１にポーリングしてもよいし、独自プロトコル２１から通知を受けてもよい。

次に、ミドルウェア２０はＲＡＷソケット２１０にＩＰヘッダとＴＣＰヘッダが付いたままのＨＴＴＰリクエストを書き込む（Ｓ１２）。これにより、通常の通信と同様に、ＨＴＴＰクライアント１２がＨＴＴＰレスポンスを受信できる。

＜ＳＩＭカードの装着を検出した場合の経路の切り替え＞
車載装置１０にＳＩＭカードが装着された場合に、ユーザなどが車載装置１０にインストールされているアプリケーションソフト１１を更新（インストール）してもよいが、アプリケーションソフト１１が内部的に経路を切り替える機能を有しているとアプリケーションソフト１１の更新が不要になる。

図１２は、アプリケーションソフト１１がＳＩＭカードの装着を検出した場合に経路を切り替える一例の手順を示すフローチャート図である。図１２の処理は例えば、アプリケーションソフト１１の起動時又はＨＴＴＰリクエストの送信時に行われる。

アプリケーションソフト１１は、ＳＩＭカードが装着されているか否かを判断する（Ｓ２１）。すなわち、ＳＩＭカード装着検出部１７にＳＩＭカードの装着の有無を問い合わせてＳＩＭカードが装着されているか否かを判断する。

ステップＳ２１の判断がＹｅｓの場合、アプリケーションソフト１１は経路Ａを設定する（Ｓ２２）。すなわち、以下のように宛先のＩＰアドレス、ポート番号を設定する。

宛先のＩＰアドレス：サーバ３０のＩＰアドレス
宛先のポート番号：サーバ３０のポート番号
車載装置１０のＩＰアドレス：携帯電話会社などから配布されたＩＰアドレス
アプリケーションソフト１１のポート番号：任意
ステップＳ２２の判断がＮｏの場合、アプリケーションソフト１１は経路Ｂを設定する（Ｓ２３）。すなわち、以下のように宛先のＩＰアドレス、ポート番号を設定する。

宛先のＩＰアドレス：ローカルホスト
宛先のポート番号：ミドルウェア２０のポート番号
車載装置１０のＩＰアドレス：携帯電話会社などから配布されたＩＰアドレス
アプリケーションソフト１１のポート番号：任意
クエストリング又はボディ部：サーバ３０のＩＰアドレス及びポート番号
このように、アプリケーションソフト１１が自動的に経路を選択することで、車載装置１０の出荷後のアプリケーションソフト１１の更新の必要性を低減できる。

＜まとめ＞
以上説明したように、本実施形態の車載装置１０では、経路Ａを使用する場合と経路Ｂを使用する場合とで、アプリケーションソフト１１の変更は生じないか又は殆ど生じないので、低コストで異なる通信方法に対応することができる。

＜その他の適用例＞
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

例えば、本実施形態では、アプリケーション層の通信プロトコルをＨＴＴＰとして説明したが、アプリケーション層の通信プロトコルはＴＣＰ又はＵＤＰ上で動作するものであればよい。例えば、ＳＭＴＰ、ＰＯＰ３、ＦＴＰ、ＳＮＭＰ、Ｔｅｌｎｅｔなどでもよい。

また、図５などの構成例は、車載装置１０による処理の理解を容易にするために、主な機能に応じて分割したものである。処理単位の分割の仕方や名称によって本願発明が制限されることはない。車載装置１０の処理は、処理内容に応じて更に多くの処理単位に分割することもできる。また、１つの処理単位が更に多くの処理を含むように分割することもできる。

１０ 車載装置
２０ ミドルウェア
３０ サーバ
５０ スマートフォン
１００ 通信システム

Claims (9)

1. アプリケーション部と、
   ネットワークに接続できる携帯端末と通信をするための第１の通信プロトコル部と、
   ネットワークに接続するための第２の通信プロトコル部と、
   前記第１の通信プロトコル部と前記第２の通信プロトコル部の間の通信を中継する中継部と、を有し、
   前記アプリケーション部は、自機を宛先に指定して前記第２の通信プロトコル部を用いた通信を行うことで、前記中継部にデータを送信し、
   前記中継部は前記第１の通信プロトコル部を介して、前記アプリケーション部から受け取った前記データを前記携帯端末へ送信することを特徴とする通信装置。
2. 前記第２の通信プロトコル部が前記ネットワークと接続するための識別情報記憶カードが装着されていることを検出する検出部、を有し、
   前記識別情報記憶カードが装着されていることを前記検出部が検出した場合、
   前記アプリケーション部は、ネットワーク上の情報処理装置を宛先に指定して前記第２の通信プロトコル部を用いた通信を行うことで、前記中継部を介さずに、前記ネットワークに前記アプリケーション部から受け取ったデータを送信することを特徴とする請求項１に記載の通信装置。
3. 前記識別情報記憶カードが装着されていることを前記検出部が検出しない場合、
   前記アプリケーション部は、自機を宛先に指定して前記第２の通信プロトコル部を用いた通信を行うことで、前記中継部にデータを送信することを特徴とする請求項２に記載の通信装置。
4. 自機を宛先に指定して前記第２の通信プロトコル部を用いた通信を行う場合、前記アプリケーション部は、自機を宛先に指定して送信する前記データにネットワーク上の情報処理装置の宛先を付加し、
   前記中継部は、前記データの宛先を自機からネットワーク上の情報処理装置に変更し、前記第１の通信プロトコル部に前記データを送信することを特徴とする請求項３に記載の通信装置。
5. 前記第１の通信プロトコル部は、前記携帯端末と前記通信装置が通信するための独自プロトコルであり、
   前記第２の通信プロトコル部は、ＴＣＰ/ＩＰに関する処理を行うことを特徴とする請求項４に記載の通信装置。
6. 前記アプリケーション部は、自機を宛先に指定して前記第２の通信プロトコル部を用いた通信を行う場合、前記中継部のポート番号を指定し、
   前記中継部は、前記ポート番号で指定されるＲＡＷソケットから前記データを取得し、
   ＩＰヘッダとＴＣＰヘッダが付いている前記データを前記第１の通信プロトコル部に渡すことを特徴とする請求項５に記載の通信装置。
7. 前記中継部は、ＩＰヘッダとＴＣＰヘッダが付いている前記データを前記第１の通信プロトコル部から受け取り、ＩＰヘッダとＴＣＰヘッダが付いている前記データを前記ＲＡＷソケットに書き込み、
   前記第２の通信プロトコル部が前記ＲＡＷソケットから取得した前記データからＩＰヘッダとＴＣＰヘッダを除去して前記データをアプリケーション部に渡すことを特徴とする請求項６に記載の通信装置。
8. 情報処理装置を、
   アプリケーション部と、
   ネットワークに接続できる携帯端末と通信をするための第１の通信プロトコル部と、
   ネットワークに接続するための第２の通信プロトコル部と、
   前記第１の通信プロトコル部と前記第２の通信プロトコル部の間の通信を中継する中継部、として機能させ、
   前記アプリケーション部は、自機を宛先に指定して前記第２の通信プロトコル部を用いた通信を行うことで、前記中継部にデータを送信し、
   前記中継部は前記第１の通信プロトコル部を介して、前記アプリケーション部から受け取った前記データを前記携帯端末へ送信することを特徴とするプログラム。
9. ネットワークに接続できる携帯端末と通信をするための第１の通信プロトコル部、又は、ネットワークに接続するための第２の通信プロトコル部を用いて通信装置で動作するアプリケーション部がネットワークを介してデータを送信する通信方法であって、
   前記第２の通信プロトコル部が前記ネットワークと接続するための識別情報記憶カードが装着されていることを検出するステップと、
   前記識別情報記憶カードが装着されていることが検出されない場合、
   前記アプリケーション部は、自機を宛先に指定して前記第２の通信プロトコル部を用いた通信を行うことで、前記第１の通信プロトコル部と前記第２の通信プロトコル部の間の通信を中継する中継部にデータを送信するステップと、
   前記識別情報記憶カードが装着されていることが検出された場合、
   前記アプリケーション部は、ネットワーク上の情報処理装置を宛先に指定して前記第２の通信プロトコル部を用いた通信を行うことで、前記中継部を介さずに、前記ネットワークに前記アプリケーション部から受け取ったデータを送信するステップと、を有することを特徴とする通信方法。

Images