特開2019-194869IP Force 特許公報全文掲載

技術分野

各種センサを用いて情報を収集し、その情報に基づいて制御を行うM2M(Machine to Machine)応用技術またはIoT(Internet of Things)応用技術に関する。なお、以下の説明において、IoTという用語が単独で用いられる場合は、M2Mの意味合いを適宜含むものとする。

要約特許出願時に添付された[要約書]

【課題】多種多様なセンサからの情報処理を可能にする、情報機器または情報通信端末および、情報処理方法を提供する。
【解決手段】情報機器は、センサおよび/またはアクチエータを備えたユニット(IoT機器)が1以上存在するネットワークで用いられる。情報機器は、接続されたユニットのセンサおよび/またはアクチエータを制御する1以上のコンピュータプログラム(ジャバスクリプト、ジャバなど)を用いる。ユニットのセンサおよび/またはアクチエータの制御に使えるメソッドを記述したクラスを1以上含むライブラリ(標準ライブラリ/ユーザ定義ライブラリ)が用意される。このライブラリから取り出した1以上のクラスの組み合わせにより、1以上のコンピュータプログラムが生成される。情報機器は、生成された1以上のコンピュータプログラムにより、ユニットのセンサおよび/またはアクチエータを制御する。
【選択図】図38A

発明が解決しようとする課題[発明の詳細な説明]から抜粋

今までの標準化活動では、“センサ組み込み機器(デバイス)”から情報を収集し、その情報を統合的に活用してサービスの提供につなげる事を前提としている。また標準化の汎用性要求から、多種多様なあらゆるセンサから得られる情報を網羅的に取り扱える必要が有る。更に策定した標準規格の利用価値を長期間維持するには、センサ組み込み機器の将来的な技術進歩に対応して、機器に組み込むセンサ種類の拡張性にも対応できる必要が有る。このように互いに相反する(センサの)多様性と(標準規格の)汎用性との間の整合性確保自体が非常に難しいだけに止まらず、更にセンサを組み込んだ機器にまで汎用性と(センサの多様性に対応できる)柔軟性と拡張性を保証する所に標準化活動の本質的な矛盾が内在する。 現状の具体的な技術的課題は、下記の4点が上げられる。まず始めに、サービス提供に活用すべき情報収集の精度が、センサ組み込み機器毎の電源ON/OFFに大きく依存する。すなわち最適なサービス内容を選定するには、各種センサから得られる情報を統合して所定システム内の状態あるいはユーザの行動や状態を推定/判断する必要が有る。しかしネットワークシステム内で大部分の機器の電源が切られると、収集すべき情報の量が少な過ぎて前記推定/判断の精度が大幅に低下する問題が生じる。 次にセンサ組み込み機器が持つ機能に対する将来的変化への対応の難しさが有る。例えばテレビの機能は、以前は放送波を受信して映像を表示するだけに限定されたので、テレビ表示状態のみを把握できる通信規格を策定した場合を考える。それに対して現在では日本の高級テレビには録画機能が内蔵されている。更にネットワーク回線を利用したデータ通信機能を有する高級テレビも存在する。そして現在はそれ程普及して無いが、裸眼3DTV(3 Dimensional Television)では視聴するユーザの位置情報検出が可能になっている。更に将来は、(表示画面の輝度を最適に制御するため)テレビに明かりセンサが内蔵される可能性も有る。このようにテレビ機能が向上する毎に標準規格をバージョンアップするには、規格検討に時間が掛かり過ぎて対応が遅れる問題が有る。逆に将来のテレビ機能の拡張を見越して事前に規格内の対応項目を増やすと、規格自体が冗長となり機器内での対応制御が複雑化する。 3番目の技術的課題として、汎用性と拡張性を目指した現行通信規格は細かく階層化されるため、通信情報に重複や冗長性が生まれる。通信規格を階層化する事で、特定層の差し替えで多様な技術領域に対応できる反面、通信情報量の増大と処理の複雑化に繋がる。処理能力の高いプロセッサを搭載したパソコンやスマートフォンなどで通信する限り、通信情報量の増大や処理の複雑化は問題にならなかった。しかしこれらは、省電力や処理の簡素化要求には適さない。 最後の技術的課題として通信情報に汎用性を持たせると、大きな処理パワーが必要となり、高価格化と大電力化に繋がる。例えば通信情報をXML(Extensible Markup Language)形式で記述させて、通信情報の柔軟性と拡張性を持たせる通信方法が有る。しかしこの場合、受信側にXML解読機能(パーサー)が必要となり、受信側機能が複雑化する。一方通信情報として、機器の種類毎に異なる標準テーブルを持たせて機器の多様性に対応する通信方法も有る。しかしこの場合でも、同じ種類の高級機器まで対応できる標準テーブルが複雑となり、単機能機器での通信処理の負担が増大する。 本実施形態の課題の1つは、多種多様なセンサからの情報処理を可能にする、情報機器または情報通信端末および、情報処理方法を提供することである。

課題を解決するための手段[発明の詳細な説明]から抜粋

一情報機器(スマートフォンなど)は、センサおよび/またはアクチエータを備えたユニット(IoT機器)が1以上存在するネットワークで用いられる。前記情報機器は、前記1以上のユニットのいずれかに接続可能に構成される。前記情報機器は、接続された前記ユニットのセンサおよび/またはアクチエータを制御する1以上のコンピュータプログラム(ジャバスクリプト、ジャバなど)を用いるように構成される。・・・ 続きを知財ポータルサイト IP Force にログインして見る

この発明についての権利主張の範囲[特許請求の範囲]

知財ポータルサイト IP Force にログインして確認する (無料)

この特許公報に記載されている図面[図面の簡単な説明]から抜粋

【図1】本実施形態システム内の広域ネットワーク構造説明図。

【図2】本実施形態システム内のローカルなネットワーク構造説明図。

【図3A】ユニットの実施形態説明図(1)。

【図3B】ユニットの実施形態説明図(2)。

【図4A】複合モジュールの実施形態説明図(1)。

【図4B】複合モジュールの実施形態説明図(2)。

【図4C】複合モジュールの実施形態説明図(3)。

【図4D】複合モジュールの実施形態説明図(4)。

【図4E】複合モジュールの実施形態説明図(5)。

【図4F】複合モジュールの実施形態説明図(6)。

【図5】センサ/通信モジュール内の具体的構造説明図。

【図6A】駆動/通信モジュール内の具体的構造を示す第1の実施形態。

【図6B】駆動/通信モジュール内の具体的構造を示す第2の実施形態。

【図6C】駆動/通信モジュール内の具体的構造を示す第3の実施形態。

【図6D】駆動/通信モジュール内の具体的構造を示す第4の実施形態。

【図7A】通信モジュール内の具体的な構造説明図。

【図7B】通信モジュール内の具体的構造の他の実施例説明図。

【図8A】ローカルなネットワーク構造に関する他の実施例説明図。

【図8B】ローカルなネットワーク構造に関する別の実施例説明図。

【図9】ローカルなネットワーク構造に関する応用例。

【図10A】本実施形態システムの基本的なアプリ/通信レイヤー構造説明図。

【図10B】通信ミドルウェア層で交信される情報の概要説明図。

【図11】本実施形態におけるネットワーク回線内の送信データ構造説明図。

【図12A】物理層ヘッダとMAC層ヘッダ内のデータ構造説明図。

【図12B】本実施形態におけるIEEE拡張アドレスの詳細説明図。

【図13】IPV6ヘッダ内のデータ構造説明図。

【図14】C−フォーマットにおける通信ミドルウェアデータ構造説明図。

【図15A】E−フォーマットにおける通信ミドルウェアデータ構造説明図。

【図15B】A−フォーマットにおける通信ミドルウェアデータ構造説明図。

【図16】基本的なアプリ/通信レイヤー構造に関する応用例説明図。

【図17A】アプリ/通信レイヤー構造に関する他の実施例(1)説明図。

【図17B】アプリ/通信レイヤー構造に関する他の実施例(2)説明図。

【図18A】コンピュータシステムにおけるデバイスドライバ周辺説明図。

【図18B】システム内ユニットの管理/制御領域周辺の説明図。

【図19A】システム内ユニットの管理/制御関係の他の実施例説明図。

【図19B】ソフト的に見たシステム内ユニットの管理/制御方法の説明図。

【図20】既存ファイルシステムと本実施形態でのユニット管理方法との比較。

【図21A】ユニット管理疑似ドライブ内構造の表示例説明図。

【図21B】複合モジュール対応フォルダ内構造の表示例説明図。

【図21C】センサ/通信モジュール対応フォルダ内構造の表示例説明図。

【図21D】センサ/通信モジュールにおけるセンサ情報の表示例説明図。

【図22】機器や各種モジュールのセクション内位置管理ルーチンの説明図。

【図23】本実施形態システムで管理されるアドレステーブル例の説明図。

【図24】セクション区分け例説明図。

【図25】センシングやサービスに関連する空間的単位セクションの説明図。

【図26A】システムコントローラ内での基本処理フロー説明図。

【図26B】セクション内で固定配置された機器や複合モジュールからの情報収集と推定/判断方法説明図。

【図27】本実施形態における推定/判断方法説明図。

【図28】通信情報の時系列変化例説明図。

【図29】セクション単位でのサービス提供方法例の説明図。

【図30】セクション間で移動可能な機器や複合モジュールからの情報収集と推定/判断方法説明図。

【図31】機器や各種モジュールの位置モニタ方法説明図。

【図32】本実施形態における電波発信元の方向検出部の構造説明図。

【図33】本実施形態におけるステルス板の構造説明図。

【図34】本実施形態における電波発信元の方向検出原理説明図。

【図35】社会インフラ分野でのセクション区分け例説明図。

【図36A】異なるミドルウェア層間での複合モジュール適用例を示す説明図。

【図36B】異なるシステム間で複合モジュールが適用する例を示す説明図。

【図37A】複合モジュールが適用された一例を示す説明図。

【図37B】複合モジュールが適用された他の例を示す説明図。

【図37C】複合モジュールが適用されたまた他の例を示す説明図。

【図37D】複合モジュールが適用されたまた他の例を示す説明図。

【図37E】複合モジュールが適用されたまた他の例を示す説明図。

【図37F】複合モジュールが適用されたまた他の例を示す説明図。

【図37G】複合モジュールが適用されたまた他の例を示す説明図。

【図37H】複合モジュールが適用されたまた他の例を示す説明図。

【図38A】一実施の形態において使用される管理ファイルおよびデータファイルのファイル管理構造を説明する図。

【図38B】一実施の形態において使用される管理ファイルおよびデータファイルのファイル管理構造を説明する図。

【図39】ファイル管理された特定ユニットをインターネット経由で遠隔操作する一例を説明する図。

【図40】遠隔操作操作対象の画像を含むWebページの一例を説明する図。

【図41】Webページで操作対象を遠隔操作する場合の操作画面の一例を説明する図。

【図42】インターネット経由で操作対象を遠隔操作する手順の一例を説明する図。

【図43A】操作情報の送信側にスマートフォンなどの通信端末を用いて、受信側のネットワークに接続された複数操作対象のうちの特定操作対象を遠隔操作する一例を説明する図。

【図43B】操作情報の送信側にスマートフォンなどの通信端末を用いて、受信側のネットワークに接続された複数操作対象のうちの特定操作対象を遠隔操作する一例を説明する図。

【図44A】操作情報の送受双方にスマートフォンなどの通信端末を用いて、特定の操作対象を遠隔操作する一例を説明する図。

【図44B】操作情報の送受双方にスマートフォンなどの通信端末を用いて、特定の操作対象を遠隔操作する一例を説明する図。

選択図 図38A出願人が指定した本件の代表的な図

4000・・・管理ファイル/データファイル、4100・・・管理情報ファイル、   4102・・・1以上のユニット(1〜n)の位置情報を格納したフォルダ、   4104・・・プログラムの管理情報を格納したフォルダ、4200・・・クラスライブラリ、4210・・・Javaクラスライブラリ、4212・・・デフォルトで用意された標準ライブラリ、4214・・・ユーザ定義ライブラリ(オプション)、   4220・・・JavaScriptのライブラリ、4222・・・デフォルトで用意された標準ライブラリ、4224・・・ユーザ定義ライブラリ(オプション)、   4230・・・その他の言語のライブラリ、4300・・・プログラム言語変換ソフトファイル、   4400・・・フォーマット変換プログラムファイル、4500・・・アプリケーションプログラムファイル、4510・・・オリジナルプログラムフォルダ、4520・・・ユーザ定義プログラムフォルダ、45221・・・ユーザ定義プログラムチェーン、   4522p・・・ユーザ定義プログラムチェーン、4600・・・ユニットファイル、   4610−1、4610−2・・・ユニットフォルダ、4612−1、4612−N・・・センサ、4614−1、4614−N・・・アクチエータ、2600a・・・ユニット管理擬似ドライブファイルa、2612・・・機器対応フォルダ、2614・・・複合モジュール対応フォルダ、2622・・・センサ/通信モジュール対応フォルダ、2624・・・駆動/通信モジュール対応フォルダ、2626・・・プロセッサ/通信モジュール対応フォルダ。

全ての図面はログインすると無料で閲覧できます。ログイン・ユーザー登録

[広告欄]

ログインすれば広告は減ります

ログインすれば広告は減ります