(57)【要約】【課題】複数の通信方式に合わせたアプリケーションの設計を不要とする通信制御装置を提供する。【解決手段】複数の通信方式に対応する通信制御装置であって、複数の通信方式でデータを送受信する複数の通信部と、複数の通信方式のそれぞれに応じた通信部固有情報を記憶する記憶部と、複数の通信部に共通に設けられ、複数の通信部から選択された通信部に対応した通信部固有情報を参照して、データの送受信を制御する制御部とを備える通信制御装置を提供する。【選択図】図１Ａ
2020088700.tif 000002
【特許請求の範囲】
【請求項１】
複数の通信方式に対応する通信制御装置であって、
前記複数の通信方式でデータを送受信する複数の通信部と、
前記複数の通信方式のそれぞれに応じた通信部固有情報を記憶する記憶部と、
前記複数の通信部に共通に設けられ、前記複数の通信部から選択された通信部に対応した前記通信部固有情報を参照して、前記データの送受信を制御する制御部と
を備える通信制御装置。
【請求項２】
前記制御部は、前記複数の通信方式によらず共通のＡＰＩを用いて、前記データの送受信を制御する
請求項１に記載の通信制御装置。
【請求項３】
前記記憶部は、前記通信部固有情報として、前記複数の通信方式のそれぞれに対応したＡＰＩ固有情報およびドライバ固有情報を記憶し、
前記ＡＰＩ固有情報は、前記複数の通信方式毎のサービス名を含み、
前記ドライバ固有情報は、前記複数の通信方式毎の通信関連情報を含む
請求項１または２に記載の通信制御装置。
【請求項４】
前記制御部は、
前記複数の通信部に共通に設けられ、前記選択された通信部の通信方式の前記サービス名を前記ＡＰＩ固有情報から選択する共通ＡＰＩ部と、
前記複数の通信部に共通に設けられ、前記選択された通信部の前記通信関連情報を前記ドライバ固有情報から選択する共通ドライバ部と
を含む請求項３に記載の通信制御装置。
【請求項５】
予め定められたアプリケーションを実行する実行部と、
前記実行部が取得したデータを送受信する、請求項１から４のいずれか一項に記載の通信制御装置と、
を備える通信装置。
【請求項６】
複数の通信方式でデータを送受信する複数の通信部を有する通信制御装置を用いた通信制御方法であって、
前記複数の通信方式のそれぞれに対応した通信部固有情報を記憶するステップと、
前記複数の通信部から選択された通信部に対応した前記通信部固有情報を参照して、前記データの送受信を制御するステップと
を備える通信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信制御装置、通信装置および通信制御方法に関する。
【背景技術】
【０００２】
従来、アプリケーションで得られた情報を、ＬＰＷＡ（Ｌｏｗ  Ｐｏｗｅｒ  Ｗｉｄｅ  Ａｒｅａ）ネットワークを用いて、低消費電力かつ広範囲に送受信する通信制御装置が知られている（例えば、特許文献１参照）。
特許文献１  特許第６３３６６８９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００３】
しかしながら、従来の通信制御装置では、複数の通信方式を用いて通信する場合に、各通信方式に合わせたアプリケーションの設計が必要であった。
【課題を解決するための手段】
【０００４】
本発明の第１の態様においては、複数の通信方式に対応する通信制御装置であって、複数の通信方式でデータを送受信する複数の通信部と、複数の通信方式のそれぞれに応じた通信部固有情報を記憶する記憶部と、複数の通信部に共通に設けられ、複数の通信部から選択された通信部に対応した通信部固有情報を参照して、データの送受信を制御する制御部とを備える通信制御装置を提供する。
【０００５】
本発明の第２の態様においては、予め定められたアプリケーションを実行する実行部と、実行部が取得したデータを送受信する、本発明の第１の態様に係る通信制御装置と、を備える通信装置を提供する。
【０００６】
本発明の第３の態様においては、複数の通信方式でデータを送受信する複数の通信部を有する通信制御装置を用いた通信制御方法であって、複数の通信方式のそれぞれに対応した通信部固有情報を記憶するステップと、複数の通信部から選択された通信部に対応した通信部固有情報を参照して、データの送受信を制御するステップとを備える通信制御方法を提供する。
【０００７】
なお、上記の発明の概要は、本発明の特徴の全てを列挙したものではない。また、これらの特徴群のサブコンビネーションもまた、発明となりうる。
【図面の簡単な説明】
【０００８】
【図１Ａ】通信装置３００の構成の概要を示す。
【図１Ｂ】通信制御装置１００の動作のフローチャートの一例を示す。
【図２Ａ】通信装置３００のより具体的な構成の一例を示す。
【図２Ｂ】通信制御装置１００がデータを送信する場合のより具体的な動作の一例を示す。
【図２Ｃ】通信制御装置１００がデータを送信する場合のより具体的な動作の一例を示す。
【図３】実施例に係る通信制御装置１００を用いる場合のアプリケーション処理の一例を示す。
【図４Ａ】比較例に係る通信装置５００の構成を示す。
【図４Ｂ】比較例に係る通信装置５００のアプリケーション処理の一例を示す。
【発明を実施するための形態】
【０００９】
以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではない。また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
【００１０】
図１Ａは、通信装置３００の構成の概要を示す。通信装置３００は、通信制御装置１００および実行部２００を備える。一例において、通信装置３００は、ＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）等の機器を構成する。通信装置３００は、スマートホームや工業等の様々な用途に用いられ得る。
【００１１】
実行部２００は、所定のアプリケーションを実行する。一例において、実行部２００は、アプリケーションとしてセンサ処理を実行する。この場合、実行部２００は、任意の情報を検出する検出素子を有する。例えば、実行部２００は、予め定められた物理量を検出する。実行部２００は、検出した物理量に相当する信号を出力する。例えば、実行部２００は、流量、圧力、振動、温度、光、色、磁気、速度、加速度を検出する。本例では、実行部２００がセンサ処理のアプリケーションを実行する場合について説明するが、これに限られない。
【００１２】
通信制御装置１００は、実行部２００が取得したデータを送受信する。通信制御装置１００は、実行部２００が検出した信号をサーバ等に送信する。また、通信制御装置１００は、サーバ等から任意のデータを受信して、実行部２００に送信してもよい。通信制御装置１００は、複数の通信方式に対応する。通信方式には、通信部毎のＡＰＩ方式やドライバ方式が含まれてよい。
【００１３】
通信制御装置１００は、制御部１０と、記憶部２０と、複数の通信部３０とを備える。本例の通信制御装置１００は、複数の通信部３０の中から選択した通信部３０を用いてデータを送受信する。
【００１４】
制御部１０は、複数の通信部３０に共通に設けられる。制御部１０は、複数の通信部３０から選択された通信部３０に対応した通信部固有情報を参照して、データの送受信を制御する。一例において、制御部１０は、複数の通信方式に対して共通のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｔｅｒｆａｃｅ）を用いて、データの送受信を制御する。複数の通信方式に対して共通のＡＰＩを用いることにより、制御部１０は、いずれの通信部３０を選択したかによらず、同一のＡＰＩで動作することができる。即ち、実行部２００は、通信方式に応じた処理をアプリケーションで意識せずに実行できる。
【００１５】
記憶部２０は、複数の通信方式のそれぞれに対応した通信部固有情報を記憶する。通信部固有情報とは、通信部３０による通信に必要な情報であって、それぞれの通信部３０に固有の情報を指す。例えば、通信部固有情報には、複数の通信方式毎のサービス名および通信関連情報が含まれる。通信関連情報には、通信記述方式、通信速度およびパリティビット長等の通信に必要な情報が含まれる。
【００１６】
通信部３０は、通信制御装置１００の外部とデータを送受信する。例えば、通信部３０は、通信制御装置１００の外部に設けられたサーバや装置とデータを送受信する。本例の通信部３０は、複数の通信部３０ａ〜通信部３０ｃを含む。通信部３０は、記憶部２０に記憶された通信部固有情報に基づいてデータを送受信する。複数の通信部３０は、複数の通信方式にそれぞれ対応する。
【００１７】
一例において、通信部３０は、ＬＰＷＡ（Ｌｏｗ  Ｐｏｗｅｒ  Ｗｉｄｅ  Ａｒｅａ）（省電力広域）方式で通信する。ＬＰＷＡ方式は、消費電力を抑えて遠距離通信を実現できるので、ＩｏＴ向け無線通信方式として用いることができる。ＬＰＷＡ方式の中にも複数のＡＰＩ方式が存在し、通信部３０の製造会社ごとにもドライバ方式が異なる。
【００１８】
通信制御装置１００は、通信部３０によらず共通のＡＰＩを用いることにより、選択された通信部３０によらず共通のデータを送受信することができる。したがって、通信方式が変更となった場合であっても、アプリケーション自体を変更する必要がない。よって、アプリケーションの設計者は、通信部３０に固有の内容を意識せずに設計することができる。これにより、複数の通信方式に対応する場合において、ソフトウェア作成の効率化を実現することができる。
【００１９】
図１Ｂは、通信制御装置１００の動作のフローチャートの一例を示す。同図は、通信制御装置１００の動作のフローチャートの一例であり、これに限られない。
【００２０】
ステップＳ１００において、記憶部２０は、複数の通信方式のそれぞれに対応した通信部固有情報を記憶する。記憶部２０は、通信部３０の追加や削除に応じて、通信部固有情報を追加または削除してよい。
【００２１】
ステップＳ１０２において、複数の通信部３０から選択された通信部３０に対応した通信部固有情報を参照して、データの送受信を制御する。通信制御装置１００は、データの送信と受信の一方を実行してもよいし、両方を実行してもよい。
【００２２】
図２Ａは、通信装置３００のより具体的な構成の一例を示す。同図では、通信装置３００が複数の通信部３０のいずれかによりデータを送受信する場合について示す。本例の制御部１０は、共通ＡＰＩ部１２および共通ドライバ部１４を備える。本例の記憶部２０は、ＡＰＩ記憶領域２２およびドライバ記憶領域２４を有する。
【００２３】
通信部３０は、複数の通信部３０ａ〜通信部３０ｃを有する。複数の通信部３０ａ〜通信部３０ｃは、それぞれ異なる通信方式に対応している。通信部３０ａは、Ａ社製であり、Ｘ方式の通信方式に対応している。通信部３０ｂは、Ｂ社製であり、Ｙ方式の通信方式に対応している。通信部３０ｃは、Ｃ社製であり、Ｚ方式の通信方式に対応している。
【００２４】
共通ＡＰＩ部１２は、複数の通信部３０ａ〜通信部３０ｃに共通に設けられる。即ち、共通ＡＰＩ部１２は、複数の通信方式に共通なＡＰＩにより動作する。共通ＡＰＩ部１２は、選択された通信部３０の通信方式に対応するＡＰＩ固有情報を用いて動作する。本例の共通ＡＰＩ部１２は、ＡＰＩ固有情報として、選択された通信部３０の通信方式に対応するサービス名を記憶部２０から参照する。このように、共通ＡＰＩ部１２は、ＡＰＩ固有情報を参照することにより複数の通信部３０に共通のＡＰＩに対応することができる。
【００２５】
共通ドライバ部１４は、複数の通信部３０ａ〜通信部３０ｃに共通に設けられる。即ち、共通ドライバ部１４は、複数の通信方式に共通に設けられる。共通ドライバ部１４は、選択された通信部３０の通信方式に対応するドライバ固有情報を用いて動作する。本例の共通ドライバ部１４は、ドライバ固有情報として、選択された通信部３０の通信方式に対応する通信関連情報を記憶部２０から参照する。このように、共通ドライバ部１４は、ドライバ固有情報を参照することにより複数の通信部３０に共通のＡＰＩに対応することができる。
【００２６】
ＡＰＩ記憶領域２２は、共通ＡＰＩ部１２が参照する通信部固有情報が記憶された領域である。本例のＡＰＩ記憶領域２２は、通信部固有情報として、複数の通信方式のそれぞれに対応したＡＰＩ固有情報を記憶している。ＡＰＩ固有情報には、複数の通信部３０毎に固有の情報であって通信方式ごとに異なるＡＰＩに関する情報が含まれる。例えば、ＡＰＩ固有情報には、複数の通信部３０毎のサービス名が含まれる。本例のＡＰＩ記憶領域２２は、Ｘ方式のＡＰＩ固有情報およびＹ方式のＡＰＩ固有情報を記憶している。
【００２７】
ドライバ記憶領域２４は、共通ドライバ部１４が参照する通信部固有情報が記憶された領域である。本例のドライバ記憶領域２４は、通信部固有情報として、複数の通信方式のそれぞれに対応したドライバ固有情報を記憶している。ドライバ固有情報には、複数の通信部３０毎に固有の情報であって製造会社ごとに異なる情報が含まれる。例えば、ドライバ固有情報には、複数の通信部３０毎の通信関連情報が含まれる。本例のドライバ記憶領域２４は、Ａ社のドライバ固有情報およびＢ社のドライバ固有情報を記憶している。
【００２８】
図２Ｂは、通信制御装置１００がデータを送信する場合のより具体的な動作の一例を示す。本例では、Ｘ方式でＡ社製の通信部３０ａが選択されている。本例の通信制御装置１００は、共通のＡＰＩを用いて、データ「１２３４５６７８」を送信する。なお、本例では、Ｃ言語の関数イメージにより説明するが、ソフトウェアの言語、記述方法などはこれに限定されない。
【００２９】
実行部２００は、共通のＡＰＩにより、データ「１２３４５６７８」を通信制御装置１００に送信する。例えば、実行部２００は、データ送信用の共通のＡＰＩとして、ＤａｔａＳｅｎｄ（）を用いる。実行部２００は、通信方式によらず共通のＡＰＩを使用することができる。即ち、実行部２００は、通信制御装置１００での通信方式に応じたＡＰＩをそれぞれ設定する必要がない。よって、実行部２００の開発者が通信部３０の通信方式を意識する必要がないので、実行部２００におけるアプリケーションの開発コストが低減する。
【００３０】
共通ＡＰＩ部１２は、実行部２００で実行されたアプリケーションがデータを送信しようとする場合に、ＤａｔａＳｅｎｄ（）という共通のＡＰＩに応じて動作することができる。共通ＡＰＩ部１２は、ＤａｔａＳｅｎｄ（）が入力された場合に、ＡＰＩ記憶領域２２から、データ送信サービスに対応するサービス名を参照する。
【００３１】
ＡＰＩ記憶領域２２は、選択された通信部３０に応じて使用するサービス名を記憶している。例えば、ＡＰＩ記憶領域２２は、Ｘ方式のデータ送信サービス名として"ＳＦ"を記憶している。よって、共通ＡＰＩ部１２は、Ｘ方式の場合、ＳｅｎｄＤｒｖ（"ＳＦ＝"，１２３４５６７８）を生成する。
【００３２】
共通ドライバ部１４は、データ送信サービス用の共通のＡＰＩを使用する。本例の共通ドライバ部１４は、共通のＡＰＩとして、ＳｅｎｄＤｒｖ（）を使用する。共通ドライバ部１４は、ＳｅｎｄＤｒｖ（）が入力された場合に、ドライバ記憶領域２４から、選択された通信部３０に対応する通信関連情報を参照する。
【００３３】
ドライバ記憶領域２４は、選択された通信部３０に応じて使用する通信関連情報を記憶している。本例のドライバ記憶領域２４は、通信部固有情報として、シリアル通信に使用するＳｔａｒｔ  ＤｅｌｉｍｉｔｅｒおよびＥｎｄ  Ｄｅｌｏｍｉｔｅｒを記憶している。例えば、ドライバ記憶領域２４は、Ａ社のＳｔａｒｔ  Ｄｅｌｉｍｉｔｅｒとして、"ＡＴ＄"を記憶し、Ａ社のＥｎｄ  Ｄｅｌｉｍｉｔｅｒとして、"ＣＲ・ＬＦ"を記憶している。よって、共通ドライバ部１４は、Ａ社の通信部３０ａが選択された場合に、"ＡＴ＄  ＳＦ＝  １２３４５６７８  ＣＲ・ＬＦ"を生成して通信部３０ａに提供する。
【００３４】
図２Ｃは、通信制御装置１００がデータを送信する場合のより具体的な動作の一例を示す。本例では、Ｙ方式でＢ社製の通信部３０ｂが選択されている点で図２Ｂの場合と相違する。
【００３５】
ＡＰＩ記憶領域２２は、選択された通信部３０に応じて使用するサービス名を記憶している。例えば、ＡＰＩ記憶領域２２は、Ｙ方式のデータ送信サービス名として"ＳＥＮＤ"を記憶している。よって、共通ＡＰＩ部１２は、Ｙ方式の場合、ＳｅｎｄＤｒｖ（"ＳＥＮＤ＝"，１２３４５６７８）を生成する。
【００３６】
ドライバ記憶領域２４は、選択された通信部３０に応じて使用する通信関連情報を記憶している。本例のドライバ記憶領域２４は、通信部固有情報として、シリアル通信に使用するＳｔａｒｔＤｅｌｉｍｉｔｅｒ，  ＥｎｄＤｅｌｏｍｉｔｅｒを記憶している。例えば、ドライバ記憶領域２４は、Ｂ社のＳｔａｒｔ  Ｄｅｌｉｍｉｔｅｒとして"ＡＴ＋"を記憶し、Ｂ社のＥｎｄ  Ｄｅｌｉｍｉｔｅｒとして、"ＣＲ"を記憶している。よって、共通ドライバ部１４は、Ｂ社の通信部３０ｂが選択された場合に、"ＡＴ＋  ＳＥＮＤ＝  １２３４５６７８  ＣＲ"を生成して通信部３０ｂに提供する。
【００３７】
なお、本例では、説明を簡略化するために、ドライバ記憶領域２４がＳｔａｒｔＤｅｌｉｍｉｔｅｒおよびＥｎｄ  Ｄｅｌｉｍｉｔｅｒを記憶する場合について説明している。但し、ドライバ記憶領域２４は、通信関連情報として、通信速度、誤り検出符号のパリティビット長など通信部３０とのインタフェースに必要な他の情報を保持してよい。この場合であっても、共通ドライバ部１４は、図２Ｂおよび図２Ｃで説明した場合と同様に、選択された通信部３０に応じた通信関連情報を参照すればよい。
【００３８】
また、図２Ｂおよび図２Ｃでは、通信制御装置１００がデータを送信する場合について説明したが、通信制御装置１００がデータを受信する場合には、これらと逆のルートで処理が行われる。例えば、データの受信動作時、通信制御装置１００は、送信時と受信時とでドライバのデリミタを固定とし、送信用のサービス名から受信用のサービス名に変更する。この場合、受信時に共通のＡＰＩは、ＤａｔａＲｃｖ（）である。これにより、通信制御装置１００は、センサ処理などのアプリケーションにおいて、様々な方式のデータを受信することができる。
【００３９】
本例の通信制御装置１００は、通信方式を変更する場合や、通信部３０を追加または削除する場合においても、ＡＰＩ記憶領域２２およびドライバ記憶領域２４を修正すればよい。したがって、アプリケーション、ＡＰＩおよびドライバ等を変更する必要がない。これにより、ソフトウェア全体の見直しや修正が不要となるため、ソフトウェア作成および検証作業量を大幅に削減することができる。
【００４０】
図３は、実施例に係る通信制御装置１００を用いる場合のアプリケーション処理の一例を示す。通信制御装置１００を用いることにより、アプリケーション側での処理が簡略化されることを示す。
【００４１】
実行部２００は、任意のアプリケーション処理を開始する。本例では、実行部２００がアプリケーションとしてセンサ処理する場合について説明する。ステップＳ２００において、実行部２００がセンサ処理を開始して、データを取得する。ステップＳ２０２において、複数の通信部３０に共通のＡＰＩを用いて、データを通信制御装置１００に出力する。ステップＳ２０２では、選択された通信部３０に応じてＡＰＩを変更することなくデータを出力することができる。即ち、設計者は、通信方式を考慮することなく、アプリケーションを設計することができる。このように、通信制御装置１００を用いることで、アプリケーション側での処理が簡略化される。
【００４２】
図４Ａは、比較例に係る通信装置５００の構成を示す。通信装置５００は、実行部５０２と、専用ＡＰＩ部５１２と、専用ドライバ部５１４と、通信部５３０とを備える。
【００４３】
通信装置５００は、複数の通信部５３０ａ〜通信部５３０ｃを備える。通信部５３０ａは、Ａ社製であり、Ｘ方式の通信方式に対応している。通信部５３０ｂは、Ｂ社製であり、Ｙ方式の通信方式に対応している。通信部５３０ｃは、Ｃ社製であり、Ｚ方式の通信方式に対応している。
【００４４】
専用ＡＰＩ部５１２は、複数の専用ＡＰＩ部５１２ａ〜専用ＡＰＩ部５１２ｃで構成される。専用ＡＰＩ部５１２ａは、通信部５３０ａに対応して設けられ、Ｘ方式の通信方式に対応している。専用ＡＰＩ部５１２ｂは、通信部５３０ｂに対応して設けられ、Ｙ方式の通信方式に対応している。専用ＡＰＩ部５１２ｃは、通信部５３０ｃに対応して設けられ、Ｚ方式の通信方式に対応している。
【００４５】
専用ドライバ部５１４は、複数の専用ドライバ部５１４ａ〜専用ドライバ部５１４ｃで構成される。専用ドライバ部５１４ａは、Ａ社製の通信部専用であり、通信部５３０ａに対応して設けられる。専用ドライバ部５１４ｂは、Ｂ社製の通信部専用であり、通信部５３０ａに対応して設けられる。専用ドライバ部５１４ｃは、Ｃ社製の通信部専用であり、通信部５３０ａに対応して設けられる。
【００４６】
図４Ｂは、比較例に係る通信装置５００のアプリケーション処理の一例を示す。比較例のアプリケーション処理では、図３の実施例に係るアプリケーション処理と比較して、処理が煩雑となる。
【００４７】
ステップＳ５００において、実行部５０２がセンサ処理を開始して、データを取得する。ステップＳ５０２において、実行部５０２は、選択した通信部５３０に応じたＡＰＩ方式を選択する。本例の実行部５０２は、Ｘ方式、Ｙ方式およびＺ方式のうち、選択された通信部５３０の方式に対応するＡＰＩ方式を設定する。即ち、実行部５０２は、選択される可能性のある全てのＡＰＩ方式を事前に用意しておく必要がある。
【００４８】
ステップＳ５０４において、選択した通信部５３０に応じたドライバ方式を選択する。本例の実行部５０２は、Ａ社製、Ｂ社製およびＣ社製のうち、選択された通信部５３０に対応するドライバ方式を設定する。即ち、実行部５０２は、選択される可能性のある全てのドライバ方式を事前に用意しておく必要がある。ステップＳ５０６において、実行部５０２は、設定したＡＰＩ方式およびドライバ方式に応じた形式でデータを出力する。
【００４９】
このように、実行部５０２は、通信方式毎にＡＰＩを用意し、通信部５３０を提供する各社毎の異なるドライバ方式に対応する必要がある。このため、比較例においては、通信方式毎に、通信のためのプログラムおよび通信部にアクセスするためのドライバを作成し、用意する必要がある。また、通信装置５００では、アプリケーション側でＡＰＩ方式やドライバ方式等を選択した通信部５３０に応じて設定する必要があるので、アプリケーションの設計に通信側の知識が必要となる。
【００５０】
一方、実施例に係る通信制御装置１００は、通信部３０によらず共通のＡＰＩを用いることにより、選択された通信部３０によらず共通のＡＰＩでデータを送受信することができる。したがって、通信方式が変更となった場合であっても、アプリケーション自体を変更する必要がない。よって、アプリケーションの設計者は、通信部３０に固有の内容を意識せずに設計することができる。これにより、複数の通信方式に対応する場合であっても、ソフトウェア作成の効率化を実現することができる。
【００５１】
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【００５２】
特許請求の範囲、明細書、および図面中において示した装置、システム、プログラム、および方法における動作、手順、ステップ、および段階等の各処理の実行順序は、特段「より前に」、「先立って」等と明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り、任意の順序で実現しうることに留意すべきである。特許請求の範囲、明細書、および図面中の動作フローに関して、便宜上「まず、」、「次に、」等を用いて説明したとしても、この順で実施することが必須であることを意味するものではない。
【符号の説明】
【００５３】
１０・・・制御部、１２・・・共通ＡＰＩ部、１４・・・共通ドライバ部、２０・・・記憶部、２２・・・ＡＰＩ記憶領域、２４・・・ドライバ記憶領域、３０・・・通信部、１００・・・通信制御装置、２００・・・実行部、３００・・・通信装置、５００・・・通信装置、５０２・・・実行部、５１２・・・専用ＡＰＩ部、５１４・・・専用ドライバ部、５３０・・・通信部
【図１Ａ】
2020088700.tif 000003
【図１Ｂ】
2020088700.tif 000004
【図２Ａ】
2020088700.tif 000005
【図２Ｂ】
2020088700.tif 000006
【図２Ｃ】
2020088700.tif 000007
【図３】
2020088700.tif 000008
【図４Ａ】
2020088700.tif 000009
【図４Ｂ】
2020088700.tif 000010