JP6957558B2 - 情報機器または情報通信端末および、情報処理方法 - Google Patents

情報機器または情報通信端末および、情報処理方法 Download PDF

Info

Publication number
JP6957558B2
JP6957558B2 JP2019104636A JP2019104636A JP6957558B2 JP 6957558 B2 JP6957558 B2 JP 6957558B2 JP 2019104636 A JP2019104636 A JP 2019104636A JP 2019104636 A JP2019104636 A JP 2019104636A JP 6957558 B2 JP6957558 B2 JP 6957558B2
Authority
JP
Japan
Prior art keywords
information
communication
module
unit
system controller
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019104636A
Other languages
English (en)
Other versions
JP2019194869A (ja
Inventor
安東 秀夫
文彦 村上
拓実 原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Toshiba Digital Solutions Corp
Original Assignee
Toshiba Corp
Toshiba Digital Solutions Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from JP2017510592A external-priority patent/JPWO2017056194A1/ja
Application filed by Toshiba Corp, Toshiba Digital Solutions Corp filed Critical Toshiba Corp
Priority to JP2019104636A priority Critical patent/JP6957558B2/ja
Publication of JP2019194869A publication Critical patent/JP2019194869A/ja
Priority to JP2021163239A priority patent/JP7224415B2/ja
Application granted granted Critical
Publication of JP6957558B2 publication Critical patent/JP6957558B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Computer And Data Communications (AREA)
  • Stored Programmes (AREA)

Description

本発明の実施形態は、各種センサを用いて情報を収集し、その情報に基づいて制御を行うM2M(Machine to Machine)応用技術またはIoT(Internet of Things)応用技術に関する。なお、以下の説明において、IoTという用語が単独で用いられる場合は、M2Mの意味合いを適宜含むものとする。
M2MまたはIoT応用技術分野に関して、世界的な標準化作業が進められている(D. Boswarthick et. al.: M2M Communications: A Systems Approach (2012, John Wiley & Sons Ltd.)を参照)。ここでは、あらゆる多種多様なセンサから得られる情報を網羅的に統合して管理し、その結果を多様なサービスに適応するための汎用的な規格策定を目指している。
中野徹,"Javaを搭載した産業用ネットワークコンピュータの実装と応用",Interface,CQ出版株式会社,1999年09月01日,第25巻,第9号,pp.105-116 長瀬嘉秀,外2名,"実装ベースの詳細設計とサンプルプログラム",Interface,CQ出版株式会社,1998年12月01日,第24巻,第12号,pp.163-170 竹内康博,"JavaプラットフォームPDA『PocketCosmo』の提案",月刊バーコード,日本工業出版株式会社,2003年06月02日,第16巻,第7号,pp.8-13 浜本階生,"つながるJava 第1回 Google Web Toolkit",WEB+DB PRESS,(株)技術評論社,2010年08月01日,第57巻,pp.130-137
今までの標準化活動では、“センサ組み込み機器(デバイス)”から情報を収集し、その情報を統合的に活用してサービスの提供につなげる事を前提としている。また標準化の汎用性要求から、多種多様なあらゆるセンサから得られる情報を網羅的に取り扱える必要が有る。更に策定した標準規格の利用価値を長期間維持するには、センサ組み込み機器の将来的な技術進歩に対応して、機器に組み込むセンサ種類の拡張性にも対応できる必要が有る。このように互いに相反する(センサの)多様性と(標準規格の)汎用性との間の整合性確保自体が非常に難しいだけに止まらず、更にセンサを組み込んだ機器にまで汎用性と(センサの多様性に対応できる)柔軟性と拡張性を保証する所に標準化活動の本質的な矛盾が内在する。
現状の具体的な技術的課題は、下記の4点が上げられる。まず始めに、サービス提供に活用すべき情報収集の精度が、センサ組み込み機器毎の電源ON/OFFに大きく依存する。すなわち最適なサービス内容を選定するには、各種センサから得られる情報を統合して所定システム内の状態あるいはユーザの行動や状態を推定/判断する必要が有る。しかし上記ネットワークシステム内で大部分の機器の電源が切られると、収集すべき情報の量が少な過ぎて前記推定/判断の精度が大幅に低下する問題が生じる。
次にセンサ組み込み機器が持つ機能に対する将来的変化への対応の難しさが有る。例えばテレビの機能は、以前は放送波を受信して映像を表示するだけに限定されたので、テレビ表示状態のみを把握できる通信規格を策定した場合を考える。それに対して現在では日本の高級テレビには録画機能が内蔵されている。更にネットワーク回線を利用したデータ通信機能を有する高級テレビも存在する。そして現在はそれ程普及して無いが、裸眼3DTV(3 Dimensional Television)では視聴するユーザの位置情報検出が可能になっている。更に将来は、(表示画面の輝度を最適に制御するため)テレビに明かりセンサが内蔵される可能性も有る。このようにテレビ機能が向上する毎に標準規格をバージョンアップするには、規格検討に時間が掛かり過ぎて対応が遅れる問題が有る。逆に将来のテレビ機能の拡張を見越して事前に規格内の対応項目を増やすと、規格自体が冗長となり機器内での対応制御が複雑化する。
3番目の技術的課題として、汎用性と拡張性を目指した現行通信規格は細かく階層化されるため、通信情報に重複や冗長性が生まれる。通信規格を階層化する事で、特定層の差し替えで多様な技術領域に対応できる反面、通信情報量の増大と処理の複雑化に繋がる。処理能力の高いプロセッサを搭載したパソコンやスマートフォンなどで通信する限り、通信情報量の増大や処理の複雑化は問題にならなかった。しかしこれらは、省電力や処理の簡素化要求には適さない。
最後の技術的課題として通信情報に汎用性を持たせると、大きな処理パワーが必要となり、高価格化と大電力化に繋がる。例えば通信情報をXML(Extensible Markup Language)形式で記述させて、通信情報の柔軟性と拡張性を持たせる通信方法が有る。しかしこの場合、受信側にXML解読機能(パーサー)が必要となり、受信側機能が複雑化する。一方通信情報として、機器の種類毎に異なる標準テーブルを持たせて機器の多様性に対応する通信方法も有る。しかしこの場合でも、同じ種類の高級機器まで対応できる標準テーブルが複雑となり、単機能機器での通信処理の負担が増大する。
本実施形態の課題の1つは、多種多様なセンサからの情報処理を可能にする、情報機器または情報通信端末および、情報処理方法を提供することである。
一実施形態に係る情報機器(スマートフォンなど)は、センサおよび/またはアクチエータを備えたユニット(IoT機器)が1以上存在するネットワークで用いられる。前記情報機器は、前記1以上のユニットのいずれかに接続可能に構成される。前記情報機器は、接続された前記ユニットのセンサおよび/またはアクチエータを制御する1以上のコンピュータプログラム(ジャバスクリプト、ジャバなど)を用いるように構成される。この実施形態では、前記ユニットのセンサおよび/またはアクチエータの制御に使えるメソッドを記述したクラスを1以上含むライブラリ(標準ライブラリ/ユーザ定義ライブラリ)が、用意される。このライブラリから取り出した1以上のクラスの組み合わせ(UD_PGC)により、前記1以上のコンピュータプログラム(ジャバスクリプト、ジャバなど)が生成される。前記情報機器は、前記生成された1以上のコンピュータプログラムにより、前記ユニットのセンサおよび/またはアクチエータを制御する。
そして、前記情報機器はジャババイトコードを生成するプログラム言語と前記ジャババイトコード以外のコードを使うアプリケーションを利用可能に構成され、
前記ジャババイトコードを生成するプログラム言語をジャバとするとき、1以上のジャバのクラスと1以上のジャバスクリプトのライブラリが用意され、1以上のジャバのクラスと1以上のジャバスクリプトを組合わせることによって、前記ジャバスクリプトを介して、前記ジャババイトコードを生成するプログラム言語と、前記ジャババイトコード以外のコードを使うアプリケーションとの間の橋渡しを可能とするように構成されている。
また、他の実施形態では、インターネット通信で用いられるマークアップ言語(HTML5またはその将来版)がジャバスクリプトおよび/またはジャバのコードをマークアップできるように構成される。前記マークアップ言語(HTML)の要素(記述内容)に対応した情報表示は、情報通信端末(スマートフォン、タブレット、PC、インターネット対応デジタルTVなど)のウェブブラウザ上で行われる。
本実施形態システム内の広域ネットワーク構造説明図。 本実施形態システム内のローカルなネットワーク構造説明図。 ユニットの実施形態説明図(1)。 ユニットの実施形態説明図(2)。 複合モジュールの実施形態説明図(1)。 複合モジュールの実施形態説明図(2)。 複合モジュールの実施形態説明図(3)。 複合モジュールの実施形態説明図(4)。 複合モジュールの実施形態説明図(5)。 複合モジュールの実施形態説明図(6)。 センサ/通信モジュール内の具体的構造説明図。 駆動/通信モジュール内の具体的構造を示す第1の実施形態。 駆動/通信モジュール内の具体的構造を示す第2の実施形態。 駆動/通信モジュール内の具体的構造を示す第3の実施形態。 駆動/通信モジュール内の具体的構造を示す第4の実施形態。 通信モジュール内の具体的な構造説明図。 通信モジュール内の具体的構造の他の実施例説明図。 ローカルなネットワーク構造に関する他の実施例説明図。 ローカルなネットワーク構造に関する別の実施例説明図。 ローカルなネットワーク構造に関する応用例。 本実施形態システムの基本的なアプリ/通信レイヤー構造説明図。 通信ミドルウェア層で交信される情報の概要説明図。 本実施形態におけるネットワーク回線内の送信データ構造説明図。 物理層ヘッダとMAC層ヘッダ内のデータ構造説明図。 本実施形態におけるIEEE拡張アドレスの詳細説明図。 IPV6ヘッダ内のデータ構造説明図。 C−フォーマットにおける通信ミドルウェアデータ構造説明図。 E−フォーマットにおける通信ミドルウェアデータ構造説明図。 A−フォーマットにおける通信ミドルウェアデータ構造説明図。 基本的なアプリ/通信レイヤー構造に関する応用例説明図。 アプリ/通信レイヤー構造に関する他の実施例(1)説明図。 アプリ/通信レイヤー構造に関する他の実施例(2)説明図。 コンピュータシステムにおけるデバイスドライバ周辺説明図。 システム内ユニットの管理/制御領域周辺の説明図。 システム内ユニットの管理/制御関係の他の実施例説明図。 ソフト的に見たシステム内ユニットの管理/制御方法の説明図。 既存ファイルシステムと本実施形態でのユニット管理方法との比較。 ユニット管理疑似ドライブ内構造の表示例説明図。 複合モジュール対応フォルダ内構造の表示例説明図。 センサ/通信モジュール対応フォルダ内構造の表示例説明図。 センサ/通信モジュールにおけるセンサ情報の表示例説明図。 機器や各種モジュールのセクション内位置管理ルーチンの説明図。 本実施形態システムで管理されるアドレステーブル例の説明図。 セクション区分け例説明図。 センシングやサービスに関連する空間的単位セクションの説明図。 システムコントローラ内での基本処理フロー説明図。 セクション内で固定配置された機器や複合モジュールからの情報収集と推定/判断方法説明図。 本実施形態における推定/判断方法説明図。 通信情報の時系列変化例説明図。 セクション単位でのサービス提供方法例の説明図。 セクション間で移動可能な機器や複合モジュールからの情報収集と推定/判断方法説明図。 機器や各種モジュールの位置モニタ方法説明図。 本実施形態における電波発信元の方向検出部の構造説明図。 本実施形態におけるステルス板の構造説明図。 本実施形態における電波発信元の方向検出原理説明図。 社会インフラ分野でのセクション区分け例説明図。 異なるミドルウェア層間での複合モジュール適用例を示す説明図。 異なるシステム間で複合モジュールが適用する例を示す説明図。 複合モジュールが適用された一例を示す説明図。 複合モジュールが適用された他の例を示す説明図。 複合モジュールが適用されたまた他の例を示す説明図。 複合モジュールが適用されたまた他の例を示す説明図。 複合モジュールが適用されたまた他の例を示す説明図。 複合モジュールが適用されたまた他の例を示す説明図。 複合モジュールが適用されたまた他の例を示す説明図。 複合モジュールが適用されたまた他の例を示す説明図。 一実施の形態において使用される管理ファイルおよびデータファイルのファイル管理構造を説明する図。 一実施の形態において使用される管理ファイルおよびデータファイルのファイル管理構造を説明する図。 ファイル管理された特定ユニットをインターネット経由で遠隔操作する一例を説明する図。 遠隔操作操作対象の画像を含むWebページの一例を説明する図。 Webページで操作対象を遠隔操作する場合の操作画面の一例を説明する図。 インターネット経由で操作対象を遠隔操作する手順の一例を説明する図。 操作情報の送信側にスマートフォンなどの通信端末を用いて、受信側のネットワークに接続された複数操作対象のうちの特定操作対象を遠隔操作する一例を説明する図。 操作情報の送信側にスマートフォンなどの通信端末を用いて、受信側のネットワークに接続された複数操作対象のうちの特定操作対象を遠隔操作する一例を説明する図。 操作情報の送受双方にスマートフォンなどの通信端末を用いて、特定の操作対象を遠隔操作する一例を説明する図。 操作情報の送受双方にスマートフォンなどの通信端末を用いて、特定の操作対象を遠隔操作する一例を説明する図。
以下、図面を参照しながら実施形態を説明する。まず始めに、本実施形態の説明内容に関する章と節の構成を下記の目次にて示す。
第1章 本実施形態における全体システム概要
1.1節 本実施形態システム全体の概説
1.2節 ユニットの形態説明
1.3節 複合モジュール内の構成説明
1.4節 センサ/通信モジュール内の構造説明
1.5節 駆動/通信モジュール内の構造説明
1.6節 通信モジュール内の構造例の説明
1.7節 本実施形態における広域ネットワークシステム全体構造の説明
1.8節 本実施形態におけるローカルなネットワークシステム構造の説明
1.9節 ローカルなネットワークシステム内での複合モジュールの活用例
第2章 通信情報の階層構造とデータ構造の概要
2.1節 本実施形態におけるネットワーク通信関連機能の階層構造
2.2節 通信関連機能の階層構造とネットワーク回線上の通信情報との関係
2.3節 物理層とメディア・アクセス層でのZ−フォーマットのデータ構造
2.4節 インターネット・プロトコル・バージョン6層のデータ構造
2.5節 通信ミドルウェア層でのC−フォーマットのデータ構造
2.6節 通信ミドルウェア層でのE−フォーマットのデータ構造
2.7節 通信ミドルウェア層でのA−フォーマットのデータ構造
2.8節 本実施形態システムで使用されるアドレステーブルとその活用例
第3章 ユニット毎の管理/表示方法
3.1節 基本的なユニット管理方法に関する概説
3.2節 ユニット管理手段
3.3節 具体的なユニット管理例と表示例
第4章 本実施形態システム内でのセクション概要
4.1節 本実施形態システム内でのセクションの位置付け
4.2節 各種モジュールや各種機器のセクション内配置場所の管理方法
4.3節 セクション毎の情報収集からサービス提供までの処理方法
4.4節 各種モジュールや各種機器のセクション間移動追跡方法
4.5節 ユニット(複合モジュールや機器)の異なるシステム間での適合性
第5章 応用分野毎の適用例
5.1節 民生分野への適用例
5.1.1節 広域ネットワークシステムの民生分野への適用例
5.1.2節 複合モジュールの民生分野適用例
5.1.3節 セクション分割方法の民生分野への適用例
5.2節 社会インフラ分野への適用例
5.2.1節 広域ネットワークシステムの社会インフラ分野への適用例
5.2.2節 複合モジュールの社会インフラ分野への適用例
5.2.3節 セクション分割方法の社会インフラ分野への適用例
5.3節 ヘルスケア分野への適用例
5.3.1節 広域ネットワークシステムのヘルスケア分野への適用例
5.3.2節 複合モジュールのヘルスケア分野への適用例
5.3.3節 セクション分割方法のヘルスケア分野への適用例
次に上記目次に従い、以下に章/節毎の説明を行う。
第1章 本実施形態における全体システム概要
1.1節 本実施形態システム全体の概説
まず始めに、図1と図2を用いて本実施形態システム全体の概要説明を行う。本実施形態システム全体の中で広域ネットワークシステム全体構造を図1に示し、その広域ネットワークシステム内の一部を構成するローカルなネットワークシステムの構造を図2に示す。また図1で説明する実施形態やサービス内容、新規に生じる効果は、図2に示す実施形態システムにもそっくりそのまま適用される。また同様に、図2を用いて説明する(あるいは図8A〜図8B、図9を用いて後述する)実施形態やサービス内容、新規に生じる効果も、図1の広域ネットワークシステム全体にも適用される。
図1において、所定の商品や情報を取り扱う元締め機関や組織を卸売業者A_1102、B1/2_1104−1/2と呼ぶ。また所定のサービスを提供する組織または集団をサービスプロバイダA〜C_1112−1〜3と呼ぶ。ここでサービスプロバイダA〜C_1112−1〜3毎に1台以上のサーバ1〜n_1116−1〜nを所持している。また本実施形態システムでは上記サーバ1〜n_1116−1〜nを、クラウドサーバまたはクラウドとも呼ぶ。そしてこのサービスプロバイダA〜C_1112−1〜3は類似した商品(または情報)を取り扱う卸売業者B1_1104−1及び(または)卸売業者B2_1104−2から商品(または情報)を入手し、各ドメイン1〜3_1122−1〜3に対してサービスを提供する。ここでドメイン1〜3_1122−1〜3は所定のネットワーク空間を示し、1個のドメイン2_1122−2は1個または複数のシステムα_1132、β_1134から構成される。所でこれ以降の説明では、上記のシステムα_1132、β_1134に対する別の呼び名として、ネットワークシステムあるいはクライアントシステムと呼ぶ事が有る。従ってこれ以降の説明で出てくる“ネットワークシステム”あるいは“クライアントシステム”と言う名称は、上記の“システムα_1132、β_1134”と同義語を意味する。また上述したように、複数の異なるシステムα_1132、β_1134から1個のドメイン2_1122−2が構成されても良い。従ってこれ以降の説明文中では、上記のドメイン2_1122−2を複合クライアントシステムと呼ぶ場合が有る。それゆえ今後の説明文中で出てくる“複合クライアント”と言う呼び名は、“ドメイン2_1122−2”と同義語を示す。
所で卸売業者A_1102、B1/2_1104−1/2とサービスプロバイダA〜C_1112−1〜3及びドメイン1〜3_1122−1〜3間はそれぞれネットワーク接続されている。またそれだけでなく、それぞれのサービスプロバイダA〜C_1112−1〜3間も互いにネットワーク接続され、互いに情報共有または資源の連携融通1114が可能となっている。
図1に示したシステムα_1132とは、内部が互いにネットワークで接続された最小のネットワークシステム単位を意味する。また前記システムα_1132内には、1個のシステムコントローラα_1126が設置される場合が多い。そしてこのシステムコントローラα_1126が、前記(ネットワーク)システム内を管理または運営する。所で最小のネットワークシステム単位である1個のシステムβ_1134は、1個のシステムコントローラβ_1128のみで構成されても良い。また同一ドメイン2_1122−2を構成するシステムα_1132とシステムβ_1134間は、互いに物理的に離れた場所に存在しても良い。更に同一ドメインドメイン2_1122−2内での異なるシステムα_1132とβ_1134間での連携処理も可能になっている。
本実施形態システムでは、同一システムα_1132内におけるユーザに提供する所定のサービス単位をセクション1〜m_1142−1〜mと定義する。またそれに限らず、同一システムα_1132内で収集される情報の統合または管理、制御に関係する単位をセクション1〜m_1142−1〜mと定義しても良い。そして当然の事ながら、同一セクション1〜m_1142−1〜mでユーザへのサービス単位と情報の統合/管理/制御単位を兼用しても良い。このようにセクション1〜m_1142−1〜m単位でサービス提供や情報収集/情報管理する事で、サービス提供や情報収集/管理の効率を上げる効果やユーザに対する利便性が向上する効果が生まれる。
図1のシステムα_1132が形成するローカルなネットワークシステムの構造を図2に示す。システムコントローラα_1126内にプロセッサ1230とメモリ部1232が内蔵され、通信モジュール1202−3を介してシステムα_1132内でのネットワーク通信が行われる。またそれと並行してシステムコントローラα_1126は、同じ通信モジュール1202−3を介して外部との間でのネットワーク通信も可能となっている。
そして本実施形態システムでは、ネットワークシステムα_1132内において上記システムコントローラα_1126以外のネットワーク通信機能を有する基本単位をユニット1〜7_1290−1〜7と定義する。そして本実施形態では、ネットワークシステムα_1132内で点在する所定の各種機能がユニット単位で管理または制御される。それによりユニットの物理的形態に関わらず、同一ネットワークシステムα_1132内での各種機能の統合的な管理/制御が容易となる。所で各ユニット1〜7_1290−1〜7におけるネットワーク通信機能を実現する形態として図2では、ユニット1〜7_1290−1〜7毎に通信モジュール1202−4〜10を内蔵する例を示している。しかしネットワーク通信機能を実現する手段としてはそれに限らず、例えば所定モジュール内の一部あるいは機器内の一部にネットワーク通信機能を有しても良い。あるいは特定ソフト内の機能の一部としてネットワーク通信機能が実現されていても良い。
本実施形態システムでは基本的に、ネットワークシステムα_1132内でのネットワーク通信の管理/運営/制御をシステムコントローラα_1126が担う。そしてこのシステムコントローラα_1126は、図2に示すように物理的にネットワークシステムα_1132内に設置される場合が多い。そしてこの場合には、図2内の各ユニット1〜7_1290−1〜7は個別に直接上記システムコントローラα_1126との間の情報通信が可能となっている。しかしそれに限らず図9で後述するように、物理的にネットワークシステムα_1132外に設置されたシステムコントローラβ_1128がネットワークシステムα_1132内でのネットワーク通信の管理/運営/制御を行っても良い。またそれに限らず、システムコントローラα_1126またはシステムコントローラβ_1128の管理の元で、異なるユニット1〜7_1290−1〜7相互間での単独の情報通信も行える。
1.2節 ユニットの形態説明
システムコントローラα_1126により、システムα_1132内で点在する所定の各種機能がユニット単位で管理または制御される特徴を前節で既に説明した。すなわち図2が示すように同一のネットワークシステムα_1132内では多種の機能実現手段が多数点在するため、従来はそれらの統合的な管理や制御に多大な煩雑さが伴っていた。更に各種機能を実現するユニットの物理的形態は、機器1250や複合モジュール1295(この複合モジュールの説明は1.3節で後述)、センサモジュール1260、駆動モジュール1270など多種多様に亘る。そのため、統合的な管理や制御は一層複雑さが増大する。
その煩雑さ増大の対策として本実施形態システムでは、ネットワークシステムα_1132内に点在する多種多様な機能実現手段に対してネットワーク通信機能を基準とした(個々のネットワーク通信機能の実現手段を基本的な単位とした)ユニットとして管理/制御する所に特徴が有る。すなわち最小限のネットワーク通信機能と連携して実現可能な単一機能あるいは多種機能の集合をユニットと言う共通・一般化した概念で括る。また上述したように個別のユニット毎には多様な物理的形態を取り得るが、具体的な物理形態に拠らない共通・一般化したユニットを基本単位として管理または制御ないしは情報収集を行う。このようにネットワークシステムα_1132内での管理単位(または制御/情報収集単位)として個別機能や物理形態に依存しないユニットを定義する事で、システムコントローラα_1126またはシステムコントローラβ_1128によるネットワークシステムα_1132内の管理または制御/情報収集を大幅に簡素化できる効果が有る。(なおユニットを用いた具体的な管理/制御例は第3章で後述する。)
所でユニットの具体的な物理形態例として、図2に示すように機器(Device)1_1250−1全体をユニット4_1290−4に対応させても良いし、単独で存在する複合モジュール1_1295−1、7_1295−7全体をユニット1_1290−1、7_1290−7に対応させても良い。またそれに限らず、機器2_1250−2や機器5_1250−5内の一部を構成する複合モジュール6_1295−6、2_1295−2、3_1295−3をそれぞれユニット6_1290−6、2_1290−2、3_1290−3に対応させても良い。所で図2ではユニット2_1290−2とユニット3_1290−3が、通信モジュール1202−10の所で重複している。このように本実施例では、異なるユニット2_1290−2と3_1290−3との間での一部重複が許容される。また更に異なるユニット間の包含関係(一方のユニットが他方のユニット内に完全に包含される状態)が有っても良い。
図2では具体的な一例を示したが、一般的にユニットが取り得る形態を図3Aを用いて説明する。図3A(a)に示すユニット形態では、ネットワーク通信機能を有する機器(Device)1250全体が1個のユニット1290に対応する。ここでこの機器1250が複雑な多機能を有する場合、上記ユニット1290も同様に複雑な多機能を有する基本単位としてネットワークシステムα_1132内で管理あるいは制御/情報収集される。
一方図3A(b)のように、ネットワークシステムα_1132内に単独で存在する複合モジュール1295(具体的内容は1.3節で後述)を1個のユニット1290に対応させても良い。更に他の管理形態(または制御/情報収集単位形態)として、特定の機器1250(単独でネットワーク通信機能を持っても持たなくても良い)に所定の複合モジュール1295を付加あるいは接続して増設を行った全体を図3A(c)のように1個のユニット1290と見なしても良い。
図2で示した機器5_1250−5内で規定されるユニット形態を、図3Bを用いて分かり易く説明する。図3Bが示すように機器5_1250−5内には、センサ機能を有する1個のセンサモジュール1260−9と、互いに異なる駆動機能または稼働機能を有する2個の駆動モジュール1_1270−5、2_1270−6が内蔵されている。更にネットワークシステムα_1132内でシステムコントローラα_1126との間でのネットワーク通信機能を有する通信モジュール1202−10も組み込まれている。そして機器5_1250−5内では、これらのモジュールの動作を統合的に制御すると共に、これらモジュールの状態情報やそこから得られるセンサ情報を統合的に収集及び管理するデバイスコントローラ1240−3を有する。ここでデバイスコントローラ1240−3が獲得または独自に生成した情報は、メモリ部1246内に保存可能となっている。
前述したようにネットワークシステムα_1132内での最適な管理または制御/情報収集の基準単位として、システムコントローラα_1126またはシステムコントローラβ_1128は適正にユニット形態を設定(定義)できる。例えばシステムコントローラα_1126またはシステムコントローラβ_1128がネットワーク経由で(すなわち通信モジュール1202−10を介して)機器5_1250−5内の個々のセンサ機能と駆動(稼働)機能を詳細に制御/情報収集したい場合には、図3B(a)が示すようにユニット2_1290−2を設定する。この場合にはユニット2_1290−2は、センサモジュール1260−9と2個の駆動モジュール1_1270−5、2_1270−6及び通信モジュール1202−10から構成される。そしてシステムコントローラα_1126(またはシステムコントローラβ_1128)は、ユニット2_1290−2内の個々のモジュールに対して細かな制御が可能となる。
それに対して図3B(b)が示すように、ユニット3_1290−3は通信モジュール1202−10とデバイスコントローラ1240−3のみから構成される。従ってシステムコントローラα_1126(またはシステムコントローラβ_1128)がユニット3_1290−3と情報通信する場合には、機器5_1250−5全体を統合した高度な制御または統合的な情報の収集が可能となる。そしてユニット3_1290−3との間の情報通信には、ユニット2_1290−2との間で情報通信する時のようなモジュール個々に対する細かな情報通信処理が不要となる。従ってユニット3_1290−3を設定(定義)すると、システムコントローラα_1126(またはシステムコントローラβ_1128)内での処理が大幅に簡素化されて処理効率が向上する。上記のようにユニット1290の形態(構成)が変わると、システムコントローラα_1126(システムコントローラβ_1128)から見たユニット1290との間の通信情報内容が変化する。
所で前述したようにユニットは、最小限のネットワーク通信機能と連携して実現する所定機能の形態を取る。従って上記ユニット内には最小限のネットワーク通信機能を有する。このネットワーク通信機能の実現形態の一例として図3Bのように通信モジュール1202−10を構成した場合には、上記ユニット内には通信モジュール1202−10が含まれる事になる。その結果として図3B(c)が示すように、通信モジュール1202−10を共通部分としてユニット2_1290−2とユニット3_1290−3間で重複している。
上記のように同一機能部で重複した異なるユニットを複数設定可能にするなどネットワークシステムα_1132内でユニット1290の具体的形態を柔軟に設定可能にすると、システムコントローラα_1126(またはシステムコントローラβ_1128)の管理(または制御/情報収集)の自由度が向上する効果が生まれる。
1.3節 複合モジュール内の構成説明
ユニット1295の一形態として、図3A(b)では複合モジュール1295の構成を示した。本実施形態では複合モジュールを、通信機能と通信機能以外の他機能が実現可能な機能モジュールと定義する。特に前記他機能の実現に、通信機能が関与する所に特徴が有る。そして前記他機能に関する外部(複合モジュール1295の外)との間の情報通信が、この通信機能を経由して行われる。すなわち複合モジュール1295内の通信機能を利用して、複合モジュール1295が有する特定機能を実施した結果えられた情報を外部(複合モジュール1295の外)から収集が可能となる。また他方では複合モジュール1295内の通信機能を利用して、複合モジュール1295が有する特定機能への外部(複合モジュール1295の外)からの制御を行っても良い。
ここで前記他機能の具体例として、センサ機能や駆動(または稼働)機能、制御(プロセス)機能、メモリ機能、表示機能などが上げられる。しかしそれに限らず、通信機能以外のいかなる機能を複合モジュールが有しても良い。特にセンサ機能を有する複合モジュールをセンサ/通信モジュール1460と呼び、駆動(または稼働)機能を有する複合モジュールを駆動/通信モジュール1470と呼ぶ。更に制御(プロセス)機能を有する複合モジュールをプロセッサ/通信モジュール1465、メモリ機能を有する複合モジュールをメモリ/通信モジュール1475、表示機能を有する複合モジュールを表示/通信モジュール1478と呼ぶ。
次にここで説明する複合モジュールと、1.2節で説明したユニットとの違いを説明する。複合モジュール1295は所定モジュールとして、機器1290の一部を構成する事が出来る。またネットワークシステム内で、複合モジュール1295が単独で存在しても良い。それに対してユニット1290は、機器1290や複合モジュール1295あるいはその組み合わせ形態などの各種形態を共通・一般化したネットワークシステム内での管理/制御/情報収集の基本単位を意味している。従って図3A(b)が示すように、1個のユニット1290内に1個以上の複合モジュール1295が含まれ得る包含関係に有る。その具体例として機器1290がユニット1290の一形態に対応するのに比べ、複合モジュール1295はあくまでも機器1290の一部を構成するに過ぎない。ここで上記の包含関係において、上述した通信機能の実現手段はユニット1290内と共に複合モジュール1295内にも共通に所有される。所で1.2節内ではシステムコントローラα_1126はユニット1290に含まれないと説明した。それに対しシステムコントローラα_1126内の一部を複合モジュール1295に設定可能な所にも、ユニット1290との大きな違いが有る。
複合モジュール内における通信機能と他機能の実現手段は、ソフト(プログラム)あるいはハード(回路)のいずれでも良く、またソフトとハードの複合で実現(一部をハードで実現すると共に残りをソフトで実現)しても良い。またソフト/ハードいずれにおいても上記の通信機能と他機能が分離される必要は無く、ソフト上またはハード上で両機能実現手段が混在する、あるいは一部の重複や包含関係が有っても良い。更にソフト上またはハード上で必ずしも両機能の実現手段が直接的に結合されている必要も無い。すなわち通信機能の実現手段と他機能の実現手段がハード上あるいはプログラム上で大きく離れた位置に分離配置され、何らかのリンク手段を用いて両機能の実現手段が協調処理できる構成でも良い。
説明の便宜上で複合モジュール内の構成を、図4A〜図4Fではブロック構造で示す。このブロックは所定回路(ハード)でも良いし、所定の纏まりを持ったプログラム(ソフト)でも良い。また各ブロック間は必ずしもソフト上またはハード上で分離される必要は無く、上述したようにブロック間で混在/分散的点在/一部重複(兼用)/包含関係などが有っても良い。
基本的な複合モジュール1295の構成を図4Aに示す。複合モジュール1295内の通信機能を実現する手段として、通信モジュール1660を所有する。所で図4A(a)では無線信号送受信用のアンテナ1480を別配置とし、通信モジュール1660と接続する構成を示している。一方図4A(b)では無線信号送受信用のアンテナは通信モジュール内に内蔵されてアンテナ内蔵通信モジュール1666を構成する。更にこのアンテナ内蔵通信モジュール1666は、通信機能以外の他機能を実現する他機能モジュール(通信以外の機能)1440と機能的に接続される(両者が連携して機能する)構造を有する。所で図4A(b)に示すように必ずしもアンテナ内蔵通信モジュール1666と他機能モジュール1440とが直接接続されている必要は無く、何らかの形で両者の機能との間にリンクが形成されていれば良い。そのリンク形成の一例として図4A(a)に示すように、互いに遠隔距離に分離配置された通信モジュール1660と他機能モジュール(通信以外の機能)1440とが遠距離ケーブルなどで連結可能な構成を有し、両者が遠隔連携1444しても良い。(例えばソフトで複合モジュールを構成しており、通信モジュール1660を構成するプログラムと他機能モジュール1440を構成するプログラムが互いに遠隔地のサーバ上に配置された場合、遠隔連携1444に対応するリンクデータ(URL(Uniform Resource Locator)など))を介して両プログラムが協調処理しても良い。)例えば地下や水中深い場所や鉄骨ビル内の奥まった場所など無線の送受信(アンテナ1480を用いた通信モジュール1660による通信機能実現)が不可能な特殊環境下で他機能モジュール(通信以外の機能)1440を動作させたい場合、上記遠隔連携1444に拠り特殊環境下でも複合モジュール1295を安定に機能させられる効果が有る。また複合モジュールの構成として図4Aの構成以外を禁止しておらず、例えばアンテナ内蔵通信モジュール1666と他機能モジュール(通信以外の機能)1440とが遠隔配置され、両者間が遠距離ケーブルなどで遠隔連携1444しても良い。
複合モジュール1295の一例としてセンサ/通信モジュール1460を用いた時の構成実施例を図4Bに示す。図4Aの他機能モジュール(通信以外の機能)1440の部分が、図4Bではセンサモジュール1260となっている。このセンサモジュール1260とは、所定システムα_1132内での定量的または定性的な情報収集機能または信号検出機能を持ったセンサ機能部を意味する。そしてこのセンサモジュール1260は所定システムα_1132内に設置できる又は移動(携帯)可能な属性を有し、対応するシステム_1132内の状態測定や観測に寄与できる。
具体的にセンシングする対象物の例として、体温や脈拍、心拍、呼吸数などの人体共通情報、人の表情や個々の顔形状や容姿、背丈や幅等のサイズ情報などの識別可能情報、照度(明るさ)や加速度、気温、湿度、電力/電流/電圧、(水やガスなどの)流量などの物理情報、所定セクション1142内の所在人数や混雑状況あるいは人感検出情報、人や車の往来状況などの動き情報、構造物の温度や歪、形状、ひび割れ数や内部の空洞容積などの構造物情報などが上げられるが、それに限らずあらゆるセンシング可能な対象を対応させても良い。
複合モジュール1295の次の一例として駆動/通信モジュール1470を用いた時の構成実施例を図4Cに示す。図4Aの他機能モジュール(通信以外の機能)1440の部分が、図4Cでは駆動モジュール1670となっている。また外付けアンテナ1480と通信モジュール1660とが接続可能(図4C(b))でも良いし、無線信号送受信用のアンテナが含まれたアンテナ内蔵通信モジュール1666で構成(図4C(a))されても良い。また図4C(a)の実施例ではアンテナ内蔵通信モジュール1666と駆動モジュール1670間が互いに遠隔地に配置され、遠隔ケーブルなどを介して両社が遠隔連携1444できる構成になっている。しかしそれに限らず、外付けアンテナ1480と接続可能な通信モジュール1660と駆動モジュール1670間が遠隔連携1444する構成でも良い。
ここで定義される駆動モジュール1670とは、特定サービスを提供するためのサービス提供関連機能部あるいはシステムα_1132内の所定の状態変化の制御に利用される状態変化制御機能部を意味する。ここで駆動モジュールの用語内に使用する“駆動(Actuator)”の単語は、実際の動きを伴う可動部や稼動部のみに限定するように誤解され易いが、決して動きを伴う必用は無い。従って上記駆動モジュールの具体的機能例として、音声や画像などの表示機能や明かりの照度や匂いの強さを維持する機能やそれを変更させる機能、あるいはそれらを制御するための情報伝達経路の一部を担う所定情報送信機能(リモコン機能など)や情報通信中継機能、あるいは(所定機器1250の)遠隔操作機能などを対応させても良い。
今まで説明したセンサ/通信モジュール1460や駆動/通信モジュール1470は、システムコントローラα_1126(またはシステムコントローラβ_1128)からの制御に応じて比較的受動的に情報通信する場合が多い。それに対して図4Dに示すプロセッサ/通信モジュール1465は、相対的に自発的あるいは能動的な機能を発揮する。本実施形態では前記プロセッサ/通信モジュール1465内での制御(プロセス)機能実現手段として機器1250内のデバイスコントローラ1240だけで無く、システムコントローラα_1126内のプロセッサ1230(図2)やシステムコントローラβ_1128内のプロセッサ1734(図17A/B)が含まれても良い。特にシステムコントローラα_1126内やシステムコントローラβ_1128内の通信モジュール1202−3では、システムα_1132やシステムβ_1134の外部に設置された装置(例えばサーバα_1116−n)との間の情報通信が可能となる。ここで複合モジュール1295としてはシステムα_1132(またはシステムβ_1134)内の情報通信機能が最低限要求される。従って図4Dでは通信モジュール1202−3内を機能的に同一システム内対応通信モジュール1752とシステム外対応通信モジュール1758に分離し、この同一システム内対応通信モジュール1752のみがプロセッサ/通信モジュール1465を構成する形を取る。しかしそれに限らず、プロセッサ/通信モジュール1465内にシステム外対応通信モジュール1758が含まれても良い。また設定(定義)されたプロセッサ/通信モジュール1465が機器1250内に存在する時には、機器1250内に前記のシステム外対応通信モジュール1758が元々含まれない場合が多い。
ネットワークシステムα_1132(あるいはβ_1134)内で上記プロセッサ/通信モジュール1465が相対的に自発的あるいは能動的な機能を発揮する場合には、図10A/Bを用いて後述する管理情報(テーブル)関連情報の記録領域1740内に記録された情報を活用する場合が多い。従ってプロセッサ/通信モジュール1465に自発的/能動的な機能発揮が要求される場合には、プロセッサ/通信モジュール1465内には機器1250内のメモリ部1242、1246の一部やシステムコントローラα_1126内のメモリ部1232の一部(図2)あるいはシステムコントローラβ_1128内のメモリ部1248の一部(図17A/B)が含まれても良い。
例えば図2の機器1_1250−1内のメモリ部1242に記録された情報をシステムコントローラα_1126が読み出す場合、一般にはシステムコントローラα_1126内のプロセッサ1230と機器1_1250−1内のデバイスコントローラ1240−1との間で取り交わす高度な通信情報の交換が必要となる。それに比べて図4Eに示すように、メモリ部1242、1246、1232、1248内の管理情報(テーブル)関連情報の記録領域1740と同一システム内対応通信モジュール1752のみから構成されるメモリ/通信モジュール1475を持つ事で、システムコントローラα_1126(またはシステムコントローラβ_1128)から非常に簡素化された通信プロトコルでメモリ/通信モジュール1475との間で直接情報通信が可能となる。従ってメモリ/通信モジュール1475により、その中の管理情報(テーブル)関連情報の記録領域1740内に記録された情報の通信簡素化が図れる効果が有る。
図4A内の他機能モジュール1440が実現する機能として、図4B〜図4Eでは単機能例のみを説明した。しかしそれに限らず図4Fに示すように、1個の複合モジュール1295内で異なる複数の機能を実現しても良い。例えば複合モジュール1295内で異なる複数のセンス機能(センサモジュール1_1260−1、2_1260−2が対応)と異なる複数の駆動(稼働)機能(駆動モジュール1_1670−1、21670−2が対応)、及び制御(プロセス)機能(プロセッサ1230、1734またはデバイスコントローラ1240が対応)、メモリ機能(メモリ部1232、1248が対応)、及び表示機能(表示モジュール1226)を同時に実現しても良い。また図4Fに示した実施例のように、アンテナ1480と通信モジュール1660が接続された場所から大きく離れた場所にセンサモジュール1_1260−1と駆動モジュール1670−2が個々に配置され、遠距離ケーブルなどを利用して遠隔連携1444できる構造を取っても良い。
なお図4Fでは通信以外の機能を有する他機能モジュール個々に対し、個別に通信モジュール1660から配線接続されている。しかし他機能モジュール毎に接続される代わりに、通信モジュール1660と多数の他機能モジュールが共通のバスラインに接続されても良い。そしてこの場合には、セレクタ作用またはアドレス指定に拠り時変的に通信モジュール1660と直接接続される他機能モジュールが切り替わる。
1.4節 センサ/通信モジュール内の構造説明
図4Bで概説したセンサ/通信モジュール1460内のより具体的で詳細な構造例を図5に示す。基本的な構造として、センサモジュール1260で得られたセンサ信号または検出情報が通信モジュール1660に転送される。このセンサ信号または検出情報は通信モジュール1660を経由してシステムコントローラα_1126内の通信モジュール1202−3(図2)に送信される。ここで図10Aと図10Bを用いて第2章で後述するC−フォーマットなどに準拠した通信ミドルウェア層APL02で通信される情報の処理も、図5内の通信モジュール1660内で実行される。
一方、上記センサモジュール1260や通信モジュール1660に供給される電力は、蓄電モジュール(電池)1554から得る。更に図5のセンサ/通信モジュール1460には光電変換機能を有する(太陽光)発電モジュール(太陽電池)1552が内蔵されており、この光電変換機能を持った(太陽光)発電モジュール(太陽電池)1552内で発生した電力が蓄電モジュール(電池)1554内に蓄えられる。図5では電力発生手段として光電変換機能を有する(太陽光)発電モジュール(太陽電池)1552を記載しているが、それ以外の何らかのエネルギー変換手段を代わりに使用しても良い。上記の光電変換素子以外のエネルギー変換手段として、例えば熱電対などのような熱−電気変換手段を使用しても良い。このような熱−電気変換手段が内蔵されたセンサ/通信モジュール1460をエンドユーザが装着し、エンドユーザの体温を利用した発電によりセンサ/通信モジュール1460を作動させても良い。更に他の実施例として、図2のシステムコントローラα_1126内の通信モジュール1202−3から通信モジュール1660が受け取る無線のエネルギーを電力に変換して蓄えても良く、また後述する近接場通信モジュール1560が外部から受け取る近接場エネルギーを電力に変換して蓄えても良い。このようにセンサ/通信モジュール1460内に(太陽光)発電モジュール1552などのエネルギー変換手段と蓄電モジュール(電池)1554を内蔵する事で、外部からの電力供給なしに長期に亘るセンサ/通信モジュール1460の動作が可能となる。
所でセンサモジュール1260を用いて光や外界温度あるいは外界湿度を測定する場合、またはセンサモジュール1260が人感センサなどに対応する場合には、このセンサモジュール1260が機器1_1250−1、2_1250−2、5_1250−5(図2)の表面に露出される形で実装される。またそれと同時に、前記(太陽光)発電モジュール(太陽電池)1552も機器1_1250−1、2_1250−2、5_1250−5の表面に露出される形で実装される。
所でセンサ/通信モジュール1460を長期間暗所に放置すると蓄電モジュール(電池)1554の蓄電量が減少して、充分な電力量をセンサモジュール1260や通信モジュール1660に供給出来ない危険が有る。それに対して蓄電モジュール(電池)1554の出力電圧または蓄電モジュール(電池)1554内の蓄電量が所定の基準値より低下すると、適宜通信モジュール1660を経由して図2のシステムコントローラα_1126に通知される。具体的には図14を用いて第2章内で詳細に説明するように、“バッテリ残量が少ない”との情報を“アラーム通知”の形で特定のセンサ/通信モジュール1460からシステムコントローラα_1126に通知される。そしてシステムコントローラα_1126内のプロセッサ1230が前記特定のセンサ/通信モジュール1460に内蔵された蓄電モジュール(電池)1554の蓄電量減少を検知すると、ユーザI/F部1234を介してエンドユーザに通知する。このように蓄電モジュール(電池)1554の出力電圧または蓄電量がシステムコントローラα_1126に適宜通知される事で、蓄電量減少に拠る特定のセンサ/通信モジュール1460の動作停止が防止でき、本実施形態システム全体の動作安定性を確保できる効果が有る。
図5に示したセンサ/通信モジュール1460内では、近接場無線通信が可能な近接場通信モジュール1560も内蔵されている。ここで使用される近接無線転送技術として、例えば TransferJet や非接触型ICカード規格の FeliCa(登録商標)(FelicityとCardを組み合わせた造語)などを適用しても良い。この近接場通信モジュール1560の利用方法として前述した外部からの電力供給の他に、下記に説明するような初期設定時のセンサ/通信モジュール1460の設置場所検出に利用しても良い。具体的には、センサ/通信モジュールに対応する複合モジュール7_1295−7を図2に示す本実施形態システム内に単独設置した時(またはセンサ/通信モジュールに対応した複合モジュール6_1295−6を内蔵した機器2_1250−2を設置した時)の初期設定として、GPS(Global Positioning System)機能が内蔵された携帯形外部機器(図示して無い)を近付けて近接場通信モジュール1560と通信を行う。この時の前記GPS位置情報を通信モジュール1202−3経由でシステムコントローラα_1126に通知する。その結果、センサ/通信モジュールに対応した複合モジュール7_1295−7単体(またはセンサ/通信モジュールに対応した複合モジュール6_1295−6を内蔵した機器2_1250−2)が設置された位置情報がシステムコントローラα_1126に登録される。この登録情報は、例えば第2章内で説明される図23形式の情報として、システムコントローラα_1126内のメモリ部1232(図2)内に格納される。このようにGPS機能を内蔵し携帯形外部機器による近接場通信で初期設定する事でセンサ/通信モジュール1460の設置位置が分かるため、エンドユーザに対する木目細かなサービス提供が可能になる効果が生まれる。
1.5節 駆動/通信モジュール内の構造説明
図4Cで概説した駆動/通信モジュール1470内のより具体的で詳細な構造例を図6A〜図6Dに示す。外部から制御可能な駆動/通信モジュール1470を機器1250内の回路の一部(回路内部品)として使用する場合、回路部品機能としては『ON/OFFスイッチ』または『所定電圧出力』か『可変な抵抗値』の機能を利用する場合が多い。本実施形態では上記標準的な(回路内で最も多く使われる)機能をモジュールとして特定機器1250内に提供する。それにより、対応機器1250の低価格化と組み立て容易性を向上させた所に特徴が有る。例として上述した機能の中で、『可変な抵抗値』の機能を提供する駆動/通信モジュール1470内構造を図6Aに、そして『ON/OFFスイッチ』の機能を提供する駆動/通信モジュール1470内構造を図6B、『所定電圧出力』の機能を提供する駆動/通信モジュール1470内構造を図6Cに示す。この中で『可変な抵抗値』の機能と『ON/OFFスイッチ』の機能を提供するためには、入力端子1602と出力端子1604が必要となる。その両端子間に可変抵抗部1610を配置して両社間の可変抵抗値を設定可能にした構造が図6Aとなる。一方図6Bでは、両端子間に導通/切断切り替え部1614を設置して両者間のON/OFFスイッチを構成している。可変抵抗部1610と導通/切断切り替え部1614の具体的な回路素子としてCMOS(Complementary Metal-oxide-Semiconductor)形のFET(Field-effect Transistor)素子を使用しても良い。ここでガンマー特性(可変抵抗部1610または導通/切断切り替え部1614に印加する入力電圧に対する入力端子1602と出力端子1604間の抵抗値特性)がなだらかな素子(印加する入力電圧値を大きく変えても抵抗値の変化が緩やかな素子)を可変抵抗部1610に使用し、ガンマー特性が急峻な素子(所定閾値前後での僅かな入力電圧の変化で抵抗値が“0”に近い導通状態から抵抗値が“非常に大きな”切断状態まで急激に変化する素子)を導通/切断切り替え部1614に使用できる。しかし本実施形態では上記CMOS形のFET素子に限らず、何らかの制御により可変な抵抗値を提供する機能またはON/OFFスイッチの機能を提供するあらゆる回路素子回路素子を使用しても良い。一方『所定電圧』を出力する端子は図6Cに示すように、電圧出力端子1606の単一端子で良い。この端子が出力する出力電圧は、駆動モジュール1670内の所定電圧発生部1618の出力に接続されている。この所定電圧発生部1618内の具体的な回路例として本実施形態では、駆動/通信モジュール1470内部で発生する定電圧源あるいは外部から供給される定電圧(例えば電源電圧)からグランドライン(アースライン)との間に接続された可変抵抗器から中間電圧を抽出し、その抽出電圧を電流供給バッファー回路(外部インピーダンスが低い場合でも出力電圧を維持するために比較的大きな外部電流を供給可能な電子回路)で維持する方式を採用する。しかしそれに限らず、所定電圧の発生と維持が可能なあらゆる方式または回路を使用しても良い。
図6A〜図6Cいずれにおいても設定値は、駆動モジュール1670の外に位置する通信モジュール1660から与えられる。ここで駆動/通信モジュール1470の電源が切断されても設定値が変化しないように、設定値の記憶部分を内部に所有する所に本実施形態の特徴が有る。この記憶部分に該当する箇所が図6Aにおける設定抵抗値記憶部1620、図6Bにおける設定状態記憶部1624そして図6Cにおける設定電圧記憶部1628となる。これらはいずれも一例としてNAND(Not And)メモリなどの不揮発性半導体メモリで構成される。しかしそれに限らず、あらゆる不揮発性メモリで上記記憶部分を構成しても良い。すなわち図6A〜図6Cいずれにおいても、通信モジュール1660から通知された設定値は設定抵抗値記憶部1620または設定状態記憶部1624、設定電圧記憶部1628に一度通達され、それらの記憶部分に不揮発的に記憶される。同時にそれらの記憶部分から記憶された設定値が出力されて、可変抵抗部1610や導通/切断切り替え部1614あるいは所定電圧発生部1618の動作を制御する。
所で図2の機器1_1250−1や5_1250−5などの制御や設定状態変更に駆動モジュール1270−1、1270−6が利用される場合、これらの駆動モジュール1270−1、1270−6の具体的な形態として既存の赤外線通信を利用したリモコンの拡張形態を採用しても良い。すなわち機器1_1250−1内の駆動モジュール1270−1と通信モジュール1202−4とで駆動/通信モジュール1470(複合モジュール1295の一種)を構成し、“新形リモコン”として機器1_1250−1の外部の離れた位置に配置可能にする。同様に、機器5_1250−5内の駆動モジュール1270−5と通信モジュール1202−10の一部とで駆動/通信モジュール1470(複合モジュール1295の一種)を構成し、“新形リモコン”として機器5_1250−5の外部の離れた位置に配置可能にしても良い。具体的なイメージ例として、エアコンやテレビ、照明設備などに付属している従来形の赤外線通信を利用したリモコンの拡張系(代替え品)としてこの“新形リモコン”を使用しても良い。
この利用方法に適合した駆動/通信モジュール1470内構造を図6Dに示す。図6Dに示した実施形態では、“ON/OFFの切り替え”などの2値状態間での遷移の制御(状態設定の変更)と“多値情報による細かな状態設定の変更”に関する制御の両方の対応を可能としている。またネットワークシステムα_1132内で交換される通信情報を受信した通信モジュール1660からの2値状態間での遷移の制御(状態設定の変更)は、設定状態記憶部1624内に保存または更新される。一方、通信モジュール1660から送られる“多値情報による細かな状態設定の変更”に関する制御情報は、設定電圧記憶部1628内に格納あるいは更新される。
そして設定状態記憶部1624内と設定電圧記憶部1628内に保存または更新された情報はフォーマット変換部1644でフォーマット変換された後、赤外線発光駆動回路1648を経由して赤外線発光素子1608で発光変調され、機器1_1250−1または5_1250−5内のリモコン対応赤外線受光部に到達する。これに拠りエアコンやテレビ、照明設備などの多くの既存の機器1_1250−1または5_1250−5の本体を交換せずに、既存の赤外線通信リモコンを図6Dに示した駆動/通信モジュール1470に交換するだけで安価かつ容易に既存機器1250をネットワークシステムα_1132内に組み込める効果が有る。
ここで既存のリモコンに要求される最低限必要な機能では、機器1250を制御した時の状態を必ずしも記憶しなくても良い。しかし設定状態記憶部1624と設定電圧記憶部1628が駆動/通信モジュール1460内の駆動モジュール1670に内蔵されているため、システムコントローラα_1126が後で通信モジュール1660を介して制御履歴が確認できる効果が有る。なお上記設定状態記憶部1624と設定電圧記憶部1628には、上述と同様にNAND(Not And)メモリあるいは他の不揮発性メモリを使用しても良い。
ここでシステムコントローラα_1126と上記駆動/通信モジュール1470間で送信される通信情報として、第2章で詳細に後述するC−フォーマットを使っても良い。以下ではC−フォーマットに基付いて図2のシステムコントローラα_1126との間で交換される通信情報の駆動/通信モジュール1470内での転送方法を説明する。しかしそれに限らずA−フォーマットやE−フォーマットあるいはそれ以外の任意のフォーマットでシステムコントローラα_1126との間で情報通信処理を行っても良い。
まず始めにシステムコントローラα_1126から既存の機器1250に対する動作開始の(電源をONにする)指令を出す(コマンド発行する)場合には、システムコントローラα_1126から対応する駆動/通信モジュール1470への通信情報(図14(d))内の交信アクセス制御情報1830を[111](リセット指示)とし、多値送信データ部CTMDTを[0000]に設定すると共に2値送信データ部CT2DTの値を[1](ON)に設定する。そして通信モジュール1660がその情報を受信すると、駆動モジュール1670内の設定状態記憶部1624内に[1](電源ON)の情報が転送/記憶される。またその情報は前記設定状態記憶部1624を通過してフォーマット変換部1644に通知され、既存リモコンでの電源ONを示す情報に変換される。そしてその変換後の情報が赤外線発光駆動回路1648に転送され、赤外線発光素子1608の発光が制御される。そして上記変換後の情報が既存の機器1250に伝えられて、機器1250の電源が入る。
所で図14(d)に示したC−フォーマットでは、例えばエアコンの設定温度変更や照明設備の照度変更などに対応した多値情報の変更設定(リセット)も一緒に行える。この場合には、システムコントローラα_1126から駆動/通信モジュール1470への通信情報(図14(d))内の交信アクセス制御情報1830を[111](リセット指示)とし、多値送信データ部CTMDTを[0000]以外に設定する。この場合、多値送信データ部CTMDTと2値送信データ部CT2DTを合わせた5ビット情報に於いて、0%から100%までの間をそれぞれ[00010]から[11111]の値に割り当てる。次に通信モジュール1660がその情報を受信すると、変更後の設定値が百分率変換される。その百分率変換後の情報は、今度は設定電圧記憶部1628へ転送/記憶される。またその情報は前記設定電圧記憶部1628を通過してフォーマット変換部1644に通知され、既存リモコンでの状態設定変更値を示す情報に変換される。そしてその変換後の情報が赤外線発光駆動回路1648を動作させて、赤外線発光素子1608の発光を制御し、既存の機器1250の設定状態が変更される。
次にシステムコントローラα_1126が駆動/通信モジュール1470内で既に設定している状態を確認する方法を説明する。この場合は最初に交信アクセス制御情報1830を[011](レスポンス(データ)要求)に設定した通信情報をシステムコントローラα_1126から駆動/通信モジュール1470へ通信する。そして図6D内の通信モジュール1660がシステムコントローラα_1126からのレスポンス(データ)要求を受け取ると、設定状態記憶部1624と設定電圧記憶部1628内に既に記憶されている情報を読み出す。そしてその結果を図14(d)内の2値送信データ部CT2DTまたは多値送信データ部CTMDT内に設定する。ここで駆動/通信モジュール1470からシステムコントローラα_1126へ通信する通信情報内の交信アクセス制御情報1830は[010](レスポンス回答)と設定される。
本実施形態における駆動/通信モジュール1470の動作説明の容易性を意識し、今まで駆動/通信モジュール1470の動作をハード(電気回路)の形で開示した。しかしそれに限らず、本実施形態システムではソフトモジュールとして駆動/通信モジュール1470を形成しても良い。但しこのようにソフトモジュールで駆動/通信モジュール1470を形成した場合にも、図6Aから図6Dに示すような入出力端子1602、1604または電圧出力端子1606あるいは赤外線発光素子1608は設置されている。以下にソフトモジュールを利用した場合の説明を行う。図2の通信モジュール1202−4〜10や図6A〜図6Dの通信モジュール1660内には、図7Aや図7Bが示すようにプロセッサ1960、1736が内蔵され、所定の通信制御プログラムに従って通信制御処理を行っている。この通信制御プログラムとしては、上記プロセッサ1960、1736内で実行可能な任意のプログラム言語が対応する。
これ以降は通信制御全体のプログラムを“メインプログラム”と呼び、このメインプログラムから呼び出す所定の小プログラムの塊を“サブプログラムモジュール”と呼んで説明を行う。しかしそれに限らず、OS(Operation System)に依存しないJava(登録商標)スクリプトまたはHTML/HTML5に対応するJavaアプレットも視野に入れてJavaで使用する用語も併記して説明する。図6A〜図6D内の通信モジュール1660に内蔵されたプロセッサを処理させるメインプログラム(クラス(Class))の中では、駆動モジュール1670に対応したサブプログラムモジュール(所定メソッド(Method))に沿った処理が実行される。このサブプログラムモジュール(所定メソッド)内では、サブプログラムモジュール(所定メソッド(Method))の中に予め設定された設定値に基付いて入出力端子1602、1604または電圧出力端子1606に対する対応処理が実行される。そして図2のシステムコントローラα_1126から駆動/通信モジュール1470への設定変更指令が通達(コマンド発行)されると、メインプログラム(クラス(Class))の中で“設定値変更”の処理をする別のサブプログラムモジュール(別メソッド)を呼び出して設定値変更処理を行う。その後は、その変更された設定値に基付いて入出力端子1602、1604または電圧出力端子1606に対する対応処理が実行される。
所で上記の説明では複合モジュール1295の一種に含まれる駆動/通信モジュール1470を例として説明した。しかしそれに限らず、センサ/通信モジュール1460やプロセッサ/通信モジュール1465、メモリ/通信モジュール1475などのあらゆる複合モジュール1295を上述したソフトモジュールで実現しても良い。
また説明上の簡素化のために図6A〜図6Dでの記載を省略したが、図6A〜図6Dに示した駆動/通信モジュール1470内に、図5と同様に(太陽光)発電モジュール1552などのエネルギー変換手段や蓄電モジュール(電池)1554、近接場通信モジュール1560を内蔵させても良い。
1.6節 通信モジュール内の構造例の説明
図4A〜図4Fに示した複合モジュールを構成するアンテナ1480外付け形の通信モジュール1660内の構造例を図7Aと図7Bに示す。なお図4A〜図4E内のアンテナ内蔵通信モジュール1666や同一システム内対応通信モジュール1752内の構造例では、図7Aまたは図7Bに示した通信モジュール1660の中に同一システム内での通信に対応したアンテナ1480が内蔵される。
所で図2のシステムコントローラα_1126(あるいはシステムコントローラβ_1128)や機器1_1250−1または機器5_1250−5内のデバイスコントローラ1240−1、1240−3、そして単独で存在する複合モジュール1_1295−1、7_1295−7の中で共通して同一の通信モジュール1660が使える構造を持つように工夫されている所に本実施形態の大きな特徴が有る。このように同一なネットワークシステムα_1132内の多くの構成メンバ(システムコントローラα_1126(あるいはシステムコントローラβ_1128)とユニット1290)間で同一構造の通信モジュール1660を共用する事で、量産効果を用いて通信モジュール1660のコストを下げられる効果が有る。
上記の特徴を実現する具体的方法として、図4B〜図4Fに示したあらゆる複合モジュール1295で共通する機能を前記通信モジュール1660内に持たせる。ここで図4B〜図4Fに示したあらゆる複合モジュール1295で共通する機能とは、
1〕同一なネットワークシステムα_1132内で使用される共通な通信プロトコルをサポートする
2〕通信機能以外の他機能に関係したあらゆる情報の情報通信に対応する
の2点が上げられる。所で1.2節と1.3節で説明したようにユニット1290や複合モジュール1295の中では、通信モジュール1660が必ず通信以外の機能を有する他機能モジュールと接続されるため、特に〔2〕の機能が重要となる。
そして上記の〔1〕と〔2〕を実現する機能を、前記通信モジュール1660内に持たせている。具体的には、図7Aの通信制御部1700で上記の〔1〕の機能が主に実現される。また図7Aのインターフェース部1710内で、上記〔2〕の機能が主に実現される。図7Aでは分かり易いように機能毎に通信制御部1700/インターフェース部1710と領域を分けて記載した。しかしそれに限らず、上記2点を実施する回路が混在しても良いし、同一回路で一部の機能が兼用されても良い。
また通信モジュール1660に汎用性を持たせて多くの複合モジュール1295内で共用可能にする方法として本実施形態では、他機能モジュール1440との間のインターフェース部(I/F部)の構造にも特徴を持たせている。具体的には他機能モジュール1440との間の接続部をコンテンツ情報I/F部1950とアドレス情報I/F部1940に分離させ、接続相手となる他機能モジュール1440の種類に応じて接続方法を可変とする。それにより多種類の他機能モジュール1440に対する汎用性が向上し、多目的の(多種多様な)複合モジュール1295に適用できる効果が生まれる。
上記の特徴に関して、以下で詳細に説明する。複合モジュール1295として図4Bや図5に示した単機能のセンサ/通信モジュール1460、あるいは図4Cや図6A〜図6Dで示した単機能の駆動/通信モジュール1670の形態を取った場合、複合モジュール1295固有のアドレス情報とシステムコントローラα_1126(またはシステムコントローラβ_1128)のアドレス情報のみ記憶していればネットワークシステムα_1132内の情報通信が成立する。従って他機能モジュール1440(図4A)として1個のセンサモジュール1260のみ(図4B)または1個の駆動モジュール1670のみ(図4C)と接続する場合には、図7Aのアドレス情報I/F部1940は使用しない。
一方、図4Dのような形態でプロセッサ/通信モジュール1465内の一部としてシステムコントローラα_1126(あるいはシステムコントローラβ_1128)の中で使用する場合には、ネットワークシステムα_1132内での通信相手となるユニット1290(または複合モジュール1295)毎にアドレス情報が異なる。従って図4Dのプロセッサ1230、1734からバスライン1490を経由して通信相手のアドレス情報が同一システム内対応通信モジュール1752内に通知される。そしてこの時には、上記のアドレス情報伝達手段(情報伝達入出力端子)としてアドレス情報I/F部1940が使用される。
また図4Eのようにメモリ/通信モジュール1475内で使用する場合には、メモリ部1242、1246、1232、1248内で管理情報(テーブル)関連情報の記録領域1740が格納されているアドレス範囲をバスライン1490を経由して同一システム内対応通信モジュール1752から指定される必要が有る。このように図4Dが示すプロセッサ/通信モジュール1465内や図4Eが示すメモリ/通信モジュール1475内では、図7Aのコンテンツ情報I/F部1950とアドレス情報I/F部1940の両方がバスライン1490に接続される。
一方1.3節の最後で、図4Fの代わりに共通のバスラインを利用して複数の他機能モジュールに接続する方法を説明した。この場合には、アドレス情報I/F部1940内の一部で通信モジュール1660と直接接続される他機能モジュールの対応アドレスを指定する。それにより通信モジュール1660と直接接続される他機能モジュールを時変的に切り替える事が可能となる。
ネットワークシステムα_1132内でのネットワーク通信に使用する通信媒体(communication media)として無線(wireless)を使用する場合、送信側ではアンテナ1480に電流を流して電波を発信し、受信側では前記アンテナ1480に流れる微弱電流を検波して信号検出する。そしてアンテナ1480に対応した電流供給と信号検波の両方を情報通信実行部3016内で行う。
一方、情報通信実行部3016からアンテナ1480を介して他の通信モジュール1660との間で交換される通信情報内は、図11(a)の構造を持つ。(なお図11に示した通信情報に関する詳細説明は、2.2節で後述する。)そしてその中の図11(b)に示す通信ミドルウェアデータAPLDT(と拡張データEXDT)は、図7Aのインターフェース部1710内で処理される。すなわち前記通信ミドルウェアデータAPLDT(と拡張データEXDT)はコンテンツ抽出部1938内で解析され、必要な情報がコンテンツ情報I/F部1950を経由して他機能モジュール1440に伝達される。その具体的な一例として図11(b)の通信ミドルウェアデータAPLDT(と拡張データEXDT)内に機器1250や駆動/通信モジュール1470に対する状態設定変更情報(制御情報)が含まれる場合には、その具体的内容がコンテンツ抽出部1938内で解読され、その解読結果がコンテンツ情報I/F部1950を経由して駆動モジュール1670に通知される。そしてその通知内容に対応して駆動モジュール1670の動作(または状態設定変更)が開始される。
また他機能モジュール1440からコンテンツ情報I/F部1950を経由して入力された情報は、コンテンツ設定部1934内でフォーマット変換されて通信ミドルウェアデータAPLDT(と拡張データEXDT)が生成される。その具体的な一例としてコンテンツ情報I/F1950の接続先がセンサモジュール1260の場合、センサモジュール1260内で得られたセンサ情報がコンテンツ設定部1934内で通信ミドルウェアデータAPLDT(と拡張データEXDT)に変換される。そしてその通信情報は情報通信実行部3016とアンテナ1480を経由してシステムコントローラα_1126(またはシステムコントローラβ_1128)に通信される。
図11(a)の構造内の図11(c)から図11(f)の情報は、図7Aの通信制御部1700内で処理される。すなわち物理層フレーム生成部1914内では図11(c)から図11(f)の情報を生成し、コンテンツ設定部1934内で生成される図11(b)の情報と合成して情報通信実行部3016に転送して通信情報の送信が行われる。一方通信情報の受信では、物理層フレーム解析部1918内で図11(a)の構造を持つ通信情報内の解析が行われ、そこで抽出された図11(b)の情報がコンテンツ抽出部1938へ送られる。
また送信時にアドレス情報I/F部1940が接続されている場合には、アドレス情報I/F部1940を経由して送信相手のアドレス情報が通知される。そして図11(a)のフォーマットに準拠したアドレス情報がアドレス情報生成部1924内で生成され、物理層フレーム生成部1914内で図11(a)の通信情報が生成される。
そして受信時にアドレス情報I/F部1940が接続されている場合には、物理層フレーム解析部1918内で図11(c)から図11(f)の情報が選別され、アドレス情報抽出部1928内に転送される。そしてこのアドレス情報抽出部1928内で所定のアドレス情報のみが抽出されてアドレス情報I/F部1940へ渡される。
この通信モジュール1660が単機能のセンサ/通信モジュール1460内で使用される場合には、アドレス情報I/F部1940を使用しない代わりに、アドレス情報生成部1924内で送信相手のシステムコントローラα_1126(システムコントローラβ_1128)のアドレス情報を事前に記憶している。それにより、センス情報が自動的にシステムコントローラα_1126(システムコントローラβ_1128)宛に通信可能となっている。
またこの通信モジュール1660が単機能の駆動/通信モジュール1470内で使用される場合には、アドレス情報I/F部1940を使用しない代わりに、アドレス情報抽出部1928内で自分自身のアドレス情報を事前に記憶している。すなわち情報通信実行部3016内で検波する無線情報は全て物理層フレーム解析部1918を経由してコンテンツ抽出部1938とアドレス情報抽出部1928に各対応情報が転送される。そしてこのアドレス情報抽出部1928内で抽出された受信側アドレス情報が自分自身のアドレス情報に一致するか逐次判定する。ここで受信側アドレス情報が自分自身のアドレス情報に一致しない場合には、コンテンツ抽出部1938に一時保存された情報は適宜破棄される。そして受信側アドレス情報が自分自身のアドレス情報に一致した時のみ、該当する複合モジュール1295に対する通信情報と判断してコンテンツ抽出部1938内に一時保存された情報がコンテンツ情報I/F1950へ転送される。
上述した一連の処理は、プロセッサ1960により制御される。所で図7Aではプロセッサ1960の接続ラインの記載を省略したが、プロセッサ1736が直接バスラインBUSなどに接続される図7Bの配線でも良いし、プロセッサ1960と各部が個々に直接接続されても良い。
通信モジュール1660内の他の実施形態を図7Bに示す。図7Bでは、通信モジュール1660内にメモリ部1790が内蔵されている所に大きな特徴が有る。それにより、上記通信モジュール1660を内蔵したユニット1290を他のシステム内に移動させた時(例えばシステムα_1132内からシステムβ_1134内に移動させた時)に、異なるシステムへシームレスに適合容易となる効果が生まれる。
所で図7Bの外部モジュール接続部1778が図7Aのコンテンツ情報I/F部1950とアドレス情報I/F部1940に対応する。また図7Bの信号処理部1780は、図7Aのコンテンツ抽出部1938とコンテンツ設定部1934に対応する。またそれに限らず図7Bの信号処理部1780は更に、図7Aのアドレス情報抽出部1928とアドレス情報生成部1924も含めて対応させても良いし、また更に情報通信実行部3016、物理層フレーム解析部1918、物理層フレーム生成部1914まで含めて対応させても良い。
図7Bに示した通信モジュール1660は図4Aに示すように、通信以外の機能を有する他機能モジュール1440に付着、埋設、接着、或いは装着して利用される。そして上記通信モジュール1660の付着、埋設、接着、或いは装着により複合モジュール1295を構成する。そして図3A(b)または(c)に示すように、この複合モジュール1295を含むユニット1290が構成される。そしてこのユニット1290としては、部品、製品、商品、装置、材料、商品などの各種の形態を取る事が出来る。従って上記通信モジュール1660は、あらゆる部品、製品、商品、装置、材料、商品など(ユニット1290)の被一体化物に付着、埋設、接着、或いは装着して利用される。
上記の通信モジュール1660は、具体的には、絶縁基板1660−1上に集積化技術を利用して構築された各種機能ブロックを有する。通信モジュール1660は、無線1770の送受信を行うためのアンテナANT_1772を接続するためのアンテナ接続部1774を備える。ここでアンテナANT_1772は、通信モジュール1660の絶縁基板1660−1上に構成されてもよい。そして上記の通信モジュール1660は外部モジュール接続部1778を備え、この外部モジュール接続部1778を介して例えば複数の他機能モジュール1766−1、1766−2、・・・1766−nに接続することができる。他機能モジュール1766−1、1766−2、・・・1766−nの例は、センサモジュール1260及び又は駆動モジュール1670、プロセッサモジュール1680、メモリモジュール1680、表示モジュール1226などが上げられる。
他機能モジュール1766−1−1766−nにおいて利用されるセンサモジュール1260としては各種のセンサがある。センサは、温度検出、湿度検出、圧力検出、歪検出、水質検出(科学的反応を利用するもの、ろ過を利用するものなど)、ガス検出(科学的反応を利用するもの)、明暗検出、超音波検出、色検出、脈拍検出などを行うセンサがあり、通信モジュール1660の使用環境に応じて選択的に1つ又は複数が設定される。またオーダーに応じて、異なる種類のセンサが組み合わせて用意されてもよい。センサは、無線(電波、赤外線、超音波など)を介して外部モジュール接続部1778に接続されるものもある。
また他機能モジュール1766−1−1766−nにおいて利用される駆動モジュール1670の具体的形態として、電気的スイッチ、機械的スイッチ、発光体、発熱体、変位物体(形状記憶媒体)、伸縮体(ゴム)など利用目的に応じて任意に選択される。
ここで他機能モジュール1766−1、1766−2、・・・1766−nは、1つ又は複数が絶縁基板1660−1上に構成されてもよい。また幾つかの他機能モジュールはオプションにより、外部モジュール接続部1778を介して追加接続されてもよい。
また通信モジュール1660は、電源供給部1776を有し、電源供給部1776を介して電源に接続されることができる。電源は通信モジュール1660から離れた位置に配置されても良い。また電源装着部が絶縁基板1660−1に設けられ、電源が通信モジュール1660と一体化されてもよい。
ところで、電源(図示せず)に電力を蓄積するための方式は、下記に記載される各種の方式が可能である。その方式の一例として、太陽光により発電する発電素子からの電流が蓄積部にチャージされる方式がある。そしてこの方式は、図5内の(太陽光)発電モジュール1552と蓄電モジュール(電池)1554の組み合わせに対応する。また他の方式として、電磁波の影響でコイルに誘起した電流が蓄電部にチャージされる方式がある。そしてこの方式は、図5内の近接場通信モジュール1560と蓄電モジュール(電池)1554の組み合わせに対応する。さらに機械的振動が圧電素子に与えられることにより、圧電素子に生じた電圧が電流変換されて蓄電部にチャージされる方式がある。機械的振動は、例えば、音による圧力・振動、気体(風、ガスなど)による圧力・振動、液体(水、油)などによる圧力・振動、などが選択的に利用できる。通信モジュール1660の使用環境に応じて、いずれか1つの方式又は、複数の方式の組み合わせが選択される。
アンテナ接続部1774、外部モジュール接続部1778、電源供給部は、信号処理部1780に接続されている。また通信モジュール1660内部では、バスBUSを介して、プロセッサ1736、メモリ部1790及び信号処理部1780が相互通信できるように接続されている。ここでメモリ部1790のアプリケーション保存部1792に格納されているアプリケーションに基付き、プロセッサ1736が通信モジュール1660の全体的な動作を制御する。
そして上記のプロセッサ1736と信号処理部1780ではアプリケーションに基づいて動作し、センサモジュール1260からの出力の取り込み、駆動モジュール1670や表示モジュール1226への制御信号出力、プロセッサモジュール1666との連携制御処理、メモリモジュール1690に対する記録情報の入出力処理、アンテナANT_1772へ送信信号の供給、アンテナANT_からの受信信号の取り込み、メモリ部1790へのデータ書き込み処理あるいは、メモリ部1790からのデータ読み出し処理などを実行する。
所でメモリ部1790の内部は、アプリケーション変更ソフトウェア格納部1791、セキュリティ対象データ格納部1799を有する。更にメモリ部1790内部は、駆動モジュール管理データ格納部1792、センサモジュール管理データ格納部1796、自己属性データ格納部1793、寿命管理データ格納部1794、稼働期間管理データ格納部1795を備える。
そしてメモリ部1790内部の駆動モジュール管理データ格納部1792は、外部モジュール接続部1778を介して接続されている駆動モジュール1670の管理データを格納している。またセンサモジュール管理データ格納部1796は、外部モジュール接続部1778を介して接続されているセンサモジュール1260の管理データを格納している。
例えば、通信モジュール1660の点検時、或いは工場出荷時に通信モジュール1660が点検される場合がある。点検時に検査装置(図示せず)が通信モジュール1660に対してアンテナANT_1772を介して所定のコマンドを与えた場合、駆動モジュール管理データ格納部1792内に格納されている駆動モジュール1670の管理データ及び/あるいは、センサモジュール管理データ格納部1796内に格納されているセンサモジュール1260の管理データが読み出される。読み出された管理データは、アンテナANT_1772を介して検査装置に送信される。これにより検査装置は、通信モジュール1660のセンシング能力や駆動能力を知ることができる。
なお図7B内での記載を省いたが、メモリ部1790の内部にプロセッサモジュール1680の管理データを格納するプロセッサモジュール管理データ格納部、メモリモジュール1690の管理データを格納するメモリモジュール管理データ格納部、あるいは表示モジュール1226の管理データを格納する表示モジュール管理データ格納部が設定されても良い。
所で本実施形態システムでは図1に示すように、同一ドメイン2_1122−2内に異なる複数のシステム(システムα_1132とシステムβ_1134)が形成されている。また同様にドメイン1_1122−1やドメイン3_1122−3内も、各々1個以上のシステム(複数システムの場合が多い)が形成されている。更に例えば民生分野対応や社会インフラ分野対応、ヘルスケア分野対応など、システム毎の適用対象分野の違いやシステム使用目的の違いも許容される。そして図7Bの通信モジュール1660を内蔵した複合モジュール1295またはユニット1290が互いに適用対象分野や使用目的が異なる複数のシステム内を跨って移動しても、システム個々に応じた最適動作が可能となっている。すなわち同一ドメイン2_1122−2内の異なるシステムα_1132とシステムβ_1134の間、あるいは異なるドメイン1_1122−1、2_1122−2、3_1122−3内の異なるシステム間を上記複合モジュール1295またはユニット1290が移動した場合、それが所属するシステムα_1132(またはシステムβ_1134)の適用対象分野や使用目的に応じて最適化可能なように上記の複合モジュール1295またはユニット1290の動作が適宜切り替わる所に本実施形態の大きな特徴が有る。そしてその特徴を可能にするため、メモリ部1790内部に、アプリケーション保存部1792、アプリケーション変更ソフトウェア格納部(アプリケーション変更ソフト)1791、セキュリティ対象データ格納部1799または自己属性データ格納部1793、寿命管理データ格納部1794、稼働期間管理データ格納部1795の少なくともいずれかを備える。そしてそれにより、本実施形態における複合モジュール1295またはユニット1290の柔軟なシステム適合性確保と汎用的な使用が可能となる効果が有る。
所で既に説明したように、図7Bに示した通信モジュール1660、1202を組み込んで複合モジュール1295(図4参照)または機器1250(図2参照)を構成してユニット1290(図3A)とする。そしてこのユニット1290にした段階で、外部からの無線電波を用いて上記のアプリケーション保存部1792とセキュリティ対象データ格納部1799、自己属性データ格納部1793、寿命管理データ格納部1794、稼働期間管理データ格納部1795の少なくともいずれかに情報を予め記録しても良い。またそれに限らず、上記ユニット1290をユーザが購入した後に実行されるチェックイン処理もしくはプラグイン処理時(4.2節で後述)に、システムコントローラα_1126が上記の情報を書き込んでも良い。
上記アプリケーション変更ソフトウェア格納部1791は、通信モジュール1660の動作を制御するアプリケーションに修正、変更などの都合が生じた場合に利用される。例えばこの通信モジュール1660を内蔵した複合モジュール1295またはユニット1290が従来とは異なるシステム内に移動した場合(例えばシステムβ_1134内からシステムα_1132内に移動した場合)、4.2節で後述するように所属システムが変わる度に“プラグイン処理”が実行される。そして移動前のシステムβ_1134と移動後のシステムα_1132との間で適用対象分野や使用目的が大きく異なる場合には、移動後のシステムα_1132を管理/制御/運営するシステムコントローラα_1126(あるいはシステムコントローラβ_1128)から図2の通信モジュール1202−3を経由して新しいアプリケーションを実行するソフトウェアが送られて来る。そしてこの新しいアプリケーションを実行するソフトウェアが、前述したアプリケーション変更ソフトウェア格納部(アプリケーション変更ソフト)1791に適宜保存される。そしてその新しいアプリケーションを実行するソフトウェアに基付いてプロセッサ1736の処理が実行されるため、複合モジュール1295またはユニット1290が全く適用対象分野や使用目的が異なるシステムα_1132に移動した時に、そのシステムα_1132に最適な動作が可能となる。
ここで通信モジュール1660が新しいアプリケーションを要求する場合と、外部(例えばシステムコントローラα_1126)からアプリケーション変更命令が与えられる場合がある。アプリケーションの変更タイミングは、通信モジュール1660が製造されて工場から出荷される場合、或いは使用されている途中で動作モードを切換える必要が生じた場合、通信モジュール1660の使用環境が変更された場合(システムα_1132、β_1134間の移動など)、通信モジュール1660の使用期間が満了となった場合など多々のケースが考えられる。このようにメモリ部1790内部に、アプリケーション変更ソフトウェア格納部(アプリケーション変更ソフト)1791を備える事で、上記の使用環境の変化や使用目的に応じて通信モジュール1660が自由にアプリケーションを変更、追加、或いは更新することができる。
一方図7Bメモリ部1790内のアプリケーション保存部1792は、システム変更に依存しない共通なアプリケーションソフトウェアが入っている。従って上記通信モジュール1660を内蔵した複合モジュール1295またはユニット1290が異なるシステム間を移動しても、上記アプリケーション保存部1792内に予め保存されている共通なアプリケーションソフトウェアは変更されずに保存/継続使用される。
なお上記のアプリケーション変更ソフトウェア格納部(アプリケーション変更ソフト)1791とアプリケーション保存部1792に格納されるアプリケーションソフトウェアは、(機械語を含む)所定のプログラム言語やスクリプト言語で記述されている。そしてそのアプリケーションソフトウェア3050は図18Bを用いて後述するように所定のOS_3030に対応した(あるいは所定の)APIコマンド3045を含んでも良い。またそれに限らず、図19Aと図19Bを用いて後述するようにJavaスクリプトで記述されても、あるいは機械語及びその類似言語で記述されても良い。更にHTML(Hyper-text Markup Language)やXML(Extensible Markup Language)などのWeb関連言語で記述されても良い。
セキュリティ対象データ格納部1799は、重要度の高い例えば個人情報などを格納する場合に利用する事ができる。またセキュリティ対象データ格納部1799は、個人的に任意のデータを格納する部分として利用されてもよい。
例えば、通信モジュール1660が使用される場面として、病院において個人のカルテホルダーに該通信モジュール1660が埋設されることがある。このような場合には、個人情報(氏名、年齢、病名、診察経過)などをセキュリティ対象データ格納部1799に格納してもよい。所で上記カルテホルダーは必ずしも永久に使用されず、破棄されても良い。またそれに限らず、新しいカルテホルダーに交換される場合がある。このような場合には、古いカルテホルダーの通信モジュール内のセキュリティ対象データは消去される必要がある。
セキュリティ対象データの消去タイミングは、各種の方法が可能である。例えば、一定期間以上通信モジュール1660がシステムコントローラα_1126と交信しなかった場合がある。この場合には通信モジュール1660が独自に破棄された又は交換されたと判断し、セキュリティ対象データの消去処理を実行する。またシステムコントローラα_1126が積極的に通信モジュール1660にセキュリティ対象データの消去を要求する場合がある。さらに通信モジュール1660に接続されているセンサモジュール1260が特定の雰囲気及び又は検出要素(例えば、圧力、熱、湿度、液体など)を検出した場合に、セキュリティ対象データの消去処理を実行しても良い。すなわちこのように特定の雰囲気及び又は検出要素(例えば、圧力、熱、湿度、液体など)をセンサモジュール1260が検出した場合、通常の自己の使用環境とは異なる環境に変化したとプロセッサ1736が自動判別してセキュリティ対象データの消去処理が実行される。またそれに限らず、所定の各種条件が成立した時にセキュリティ対象データの消去処理が実行されても良い。
一方例えば古いカルテホルダーが新しいカルテホルダーに交換されて古いカルテホルダーのセキュリティ対象データを新しいカルテホルダーにムーブする必要が生じた場合などは、システムコントローラα_1126がセキュリティ対象データの承継或いは受け渡しなどの制御を行っても良い。
自己属性データ格納部1793内には、通信モジュール1660が例えば付着、接着、搭載或いは埋設されるユニット(製品、部品、材料、商品など)の取り扱い(ハンドリング)に関する属性データが格納されている。その具体的な属性データには、対応するユニットの識別データ(商品名、部品名、製品名など)や、その製造場所や製造メーカなど識別データが含まれても良い。
例えば通信モジュール1660が含まれる複合モジュール1295(あるいはユニット1290)がアルミ製の飲料缶に接着或いは埋設されている場合がある。アルミ製の飲料缶は、使用後は破棄され、リサイクル工場へ搬送される。ここで属性データとして“接着或いは埋設されている対象物の材料がアルミ製”と言う情報が保存されていれば、リサイクル工場内で自動的に飲料缶をアルミ処理部へ分類処理することができる。この場合にはリサイクル工場全体がシステムα_1132に対応し、リサイクル工場内の分類装置がシステムコントローラα_1126に対応する。そしてシステムコントローラα_1126に対応した上記分類装置が特定のコマンドを通信モジュール1660に送信して、自己属性データを読み取る。そしてその自己属性データに基付いて飲料缶が何製であるかを判断できる。
一方上記通信モジュール1660が含まれる複合モジュール1295(あるいはユニット1290)がプラスチック製の飲料ボトルに埋設されている場合がある。この場合には、分類装置が特定のコマンドを通信モジュール1660に送信して、自己属性データを読み取り、飲料缶がプラスチック製であることを検出する。これにより分類装置は、容易に自動的に飲料缶をブラスチック処理部へ分類処理することができる。所で上記の例に限らず、上記通信モジュール1660が含まれる複合モジュール1295(あるいはユニット1290)が付着、埋設、接着、或いは装着されたあらゆる被一体化物(部品、製品、商品、装置、材料、商品など)に関して自己属性データが利用されても良い。
所で上記通信モジュール1660が含まれる複合モジュール1295(あるいはユニット1290)が異なるシステム間で跨って移動した場合、それが配置された環境が移り変わる場合がある。そしてその環境変化に応じて上記自己属性データの内容が進行的に変化しても良い。例えば上記飲料缶が店頭に陳列されている場合には、上記自己属性データとして飲料缶の販売価格や店頭内の陳列場所、あるいは商品カテゴリーがメモリ部1790内に保存されても良い。そしてこの場合には、店頭内を管理するシステムコントローラα_1126が前記の自己属性データを利用して在庫管理や顧客に対する決算処理を行っても良い。
また他の例として、魚に張り付けたタグとして複合モジュール1295(あるいはユニット1290)を使用する場合を説明する。海で吊り上げた魚は漁船で港へ運ばれ、港のセリ市場で業者に買い取られ、車で搬送され、スーパーマーケットの店頭に陳列され、消費者により購入される。
上記魚と一体化されたタグ(複合モジュール1295/ユニット1290)内のセンサモジュール1260として品質管理のための温度センサと湿度センサが設置されている場合を説明する。この時の自己属性データとしてはは、適切な温度の範囲データ、適切な湿度の範囲データ、そして賞味期間データが格納されている。ここで漁船の乗組員や市場管理者が上記自己属性データを入力する。
魚の搬送途中或いは保管時に周囲環境の温度や湿度が適切な範囲を超えた場合、通信モジュール1660は漁船内あるいは搬送トラック内に設置されたシステムコントローラα_1126に対して第1の警告信号を出力することができる。また賞味期間が近づいた場合や賞味期間が過ぎた場合にも、アンテナ1772を介して第2の警告信号、第3の警告信号を出力することができる。
また店頭陳列時には、自己属性データとして販売価格や店頭内の陳列場所、あるいは商品カテゴリーなどが追加される。この場合には上記の自己属性データが、店頭内に設置された別のシステムコントローラα_1126から自動的にメモリ部1790内に保存される。そしてこの自己属性データを利用して、在庫管理や顧客に対する決算処理が行える。
上記のように複合モジュール1295/ユニット1290が配置される(所属する)システムの移動に応じ、そのシステムα_1132を管理/制御/運営するシステムコントローラα_1126から自動的に上記の自己属性データ1793の追記あるいは更新できる所にも本実施形態システムの特徴が有る。それに拠り、対応する複合モジュール1295やユニット1290活用の柔軟性と汎用性が大きく向上する効果が有る。すなわち上記の追記/更新された自己属性データを利用する事で、システムα_1132に最適な処理をシステムコントローラα_1126が実行できる。
またそれに限らず、通信モジュール1660が特定のコマンド(リクエスト信号)に応答し、通信モジュール1660が存在することの応答信号を出力するためのデータとして、前記自己属性データが利用されてもよい。例えば、通信モジュール1660が、手術器具、或いは、航空機や列車の点検工具内に埋設される場合がある。この場合には作業現場を特定のシステムα_1132と見なし、作業現場に設置されたシステムコントローラα_1126から通信モジュール1660に応答回答を要求する。そして作業現場(システムα_1132)内での応答回答の有無で、作業現場へ手術器具や点検工具などの忘れ物の有無が判明する。このように自己属性データに関する情報通信処理を利用して、手術後や点検後の忘れ物の有無判定が可能となる。
上記以外の自己属性データ1793の利用例として、この領域に対応ユニット1290(または複合モジュール1295や機器1250)の所有者情報を記録しても良い。この自己属性データ1793が記録されたユニット1290(または複合モジュール1295や機器1250)の市販時には、上述したように店頭に陳列される。この時には陳列された店舗内が1個のシステムβ_1134に対応する。そしてユーザが上記ユニット1290(または複合モジュール1295や機器1250)を購入すると、それを自宅に移動する。すると購入したユーザの自宅内がシステムα_1132に対応する(図1参照)。従って上記ユニット1290(または複合モジュール1295や機器1250)の購入前後で、このユニット1290が配置されるシステムが変化する。そしてこのユニット1290がユーザの自宅内に配置されると、新たなシステムα_1132内を管理/運営/情報収集するシステムコントローラα_1126が4.2節で後述するチェックイン処理を行う。この時に、システムコントローラα_1126が上記自己属性データ1793の一部に所有者に関するユーザ情報を記録する。このユーザ情報としては所有者名に限らず、ユーザのID情報やユーザの住所情報や電話番号情報、メールアドレス情報などのいずれでも良い。このように自己属性データ1793の一部に記録されたユーザ情報を記録しておくと、対応するユニット1290を外で置き忘れた時に、探し易くなる効果が有る。
上記の所有者とは、ユニット1290の直接の持ち主に限らない。すなわち前記ユニット1290(または複合モジュール1295や機器1250)の使用に関係する人あるいは組織や企業も含まれる。またこの自己属性データ1793が記録された複合モジュール1295が設置あるいは挿入、混入された商品や部品、材料の利用に関係する人あるいは組織や企業でも良い。
その一例として、この自己属性データ1793が記録された複合モジュール1295が挿入あるいは混入された錠剤あるいは粉末状の薬の説明をする。例えば病院や施設または自宅で上記の薬を飲んだ時、システムコントローラα_1126が飲んだ人の名前と飲んだ日時を前記自己属性データ1793内に記録する。またこの自己属性データ1793内には、予め薬の名前も記録してある。するとこの薬を飲んだユーザの外出先でも、外出先に設置されたシステムコントローラβ_1134が「誰が何時に何の薬を飲んだか?」を管理できる。持病を持っている人に取って、定期的な服薬は非常に重要で有るが忘れ易い。上記のようにシステムコントローラβ_1134が常時服薬状況を管理すれば、飲み忘れが起き辛い効果が生まれる。
上記のように自己属性データ1793として互いに関連する複数の情報を記録する事で、自己属性データ1793が記録された複合モジュール1295(ユニット1290)に利用状況を高い精度で管理し易くなる効果が生まれる。
通信モジュール1660が内蔵された複合モジュール1295(またはユニット1290)の寿命を管理する寿命管理データを、寿命管理データ格納部1794内に格納することができる。この寿命管理データは、通信モジュール1660が内蔵された複合モジュール1295(またはユニット1290)が用済みとなる寿命期間を示している。そしてこの寿命期間が経過したとき、通信モジュール1660が自動的に動作を収束し停止する。これにより、寿命期間後に不要な電波を出射することはない。
例えば上述した廃棄後の飲料缶や料理後の魚に関しては、対応するタグ(複合モジュール1295/ユニット1290)の使用は不要となる。上記のようにメモリ部1790内に寿命管理データ格納部1794を持ち、寿命期間後に自動的に活動停止させる事で、システムα_1132内の不要な電波発生が防げる。そして不要な電波発生を防止する事で、システムα_1132内での情報通信効率が向上する効果が生まれる。
通信モジュール1660の稼働期間を設定するためのデータを稼働期間管理データ格納部1795内に格納できる。使用環境、使用条件に応じて通信モジュール1660の稼働期間やスリープ期間を持つ方が、節電効果が上がり、周囲デバイスとの干渉防止効果も出る。上記稼働期間管理データとして、例えば時間単位で稼働期間とスリープ期間を設定する、あるいはセンサ出力に応じて稼働期間とスリープ期間を設定することができる。
1.7節 本実施形態における広域ネットワークシステム全体構造の説明
既に1.1節で本実施形態システムの概説を行った。それに対して本節では、図1を用いて本実施形態における広域ネットワークシステム全体の構造を詳細に説明する。図1が示すようにサービスプロバイダB_1112−2は、類似した商品(または情報)を取り扱う卸売業者B1_1104−1及び(または)卸売業者B2_1104−2から商品(または情報)を入手し、サービスを提供する。
ここで卸売業者A_1102、B1/2_1104−1/2とは、所定の商品や情報を取り扱う元締め機関や組織を意味する。前記機関や組織の具体例として、例えば財団法人や業務法人等の私的営利組織に関係した業者に限らず、国家や地方自治体、公団や公益法人などの公的組織まで対応させても良い。従ってサービスプロバイダA〜C_1112−1〜3から見た前記卸売業者の位置付けは、『商取引相手』のみに限らず、『所定サービス委託先』や『所定サービスの指導や許認可相手』まで対応させても良い。例えば前記卸売業者がサービスプロバイダA〜C_1112−1〜3の商取引相手に相当した場合の卸売業者が取り扱う商品として、電力、ガス、水道、ガソリンなどの公共消費材に限らず、一般消費材や貨幣、債券、貴金属などの流動資産や不動産などの固定資産を対応させても良いし、また通常のインターネットでの入手が困難な商品価値の有る情報(市場調査情報や特定個人や特定地域に特化した情報(非常に狭い地域に限定した気象情報や交通情報など))を対象としても良い。
次に本実施形態システムに於けるサービスプロバイダA〜C_1112−1〜3とは、所定のサービスを提供する組織または集団を意味する。特にこのサービスプロバイダA〜C_1112−1〜3は、『所定サービスに関する統合的管理』を行う特徴も有る。またサービスプロバイダが提供するサービスは、後述するセンサモジュール1260から得られた情報を利用した、あらゆる種類のサービスを対応させても良い。特に後述するドメイン1〜3_1122−1〜3内のセンサモジュールからネットワーク経由で得た情報やそれに関係した情報の一部がこのサービスプロバイダB_1112−2内のサーバn_1116−nに伝達され、それに基付いてサービスプロバイダB_1112−2が所定サービスを提供できる所に特徴が有る。このように本実施形態システムでは、サービスプロバイダA〜C_1112−1〜3によるドメイン1〜3_1122−1〜3内からの商品や情報の吸い上げ操作が可能となっている。更にこのサービスプロバイダB_1112−2は複数のサーバ1〜n_1116−1〜nを所有し、サーバ1〜n_1116−1〜n毎にデータベース1118−1〜nを管理している。またサーバ1〜n_1116−1〜n間では連携した分散処理が行われ、処理の高速化が図られている。図1では省略されているが、サービスプロバイダA_1112−1内やサービスプロバイダC_1112−3内にも同様にサーバやそれに対応したデータベースが設置されている。
サービスプロバイダの具体的な実働の一つとして、卸売業者A_1102または卸売業者B1/2_1104−1/2から卸された商品や情報をドメイン1〜3_1122−1〜3内に流通(流入と流出両方が含まれる)させる。この具体的なサービス例を以下に示す。
α〕卸売業者A_1102や卸売業者B1/2_1104−1/2が扱う商品や情報のエンドユーザへの小売りサービス
β〕卸売業者A_1102や卸売業者B1/2_1104−1/2が扱う商品や情報を独自に加工し、その加工結果を利用してエンドユーザへ提供するサービス
γ〕センサモジュールから得られた情報に基付いて最適と判断されたサービスを提供
δ〕上記〔α〕〜〔γ〕の組み合わせ
ここでサービスプロバイダが取り扱う商品として電力、ガス、水道、ガソリンなどの公共消費材の小売りに限らず、一般消費材の小売り、流動資産や固定資産の小売りなどを対象としても良い。またそれに限らず取り扱う情報(商品)として、通常のインターネットでの入手が困難な商品価値の有る情報(市場調査情報や特定個人や特定地域に特化した情報(非常に狭い地域に限定した気象情報や交通情報など))を商品として取り扱っても良い。
一方サービスプロバイダA_1112−1は、卸売業者B1/2_1104−1/2とは異なる商品(または情報)を卸売業者A_1102から入手し、別の種類のサービスを提供する。ここでサービスプロバイダA_1112−1とサービスプロバイダB_1112−2間、あるいはサービスプロバイダB_1112−2とサービスプロバイダC_1112−3間は互いに情報共有または資源の連携融通1114を行い、サービスの効率化と高度化を図っている。またサービスプロバイダA_1112−1内には、卸売業者A_1102から入手した商品を貯蔵する所定商品貯蔵部1154が設置されている。そして図1に示したサービスプロバイダA_1112−1内の所定商品生成部1152では、卸売業者A_1102からの入手対象の商品を材料にして新商品の製造を行う、または卸売業者A_1102から入手した商品(または情報)を加工して新たな商品(または新たな情報)を生み出す。図1では省略されているが、サービスプロバイダB_1112−2やサービスプロバイダC_1112−3内にも所定商品貯蔵部1154や所定商品生成部1152が設置されている。
図1に示した所定商品生成部1152とは、独自な付加価値が付与された独自商品を生成する場所を意味する。そしてその独自商品生成の具体的な形態例として、卸売業者A_1102から仕入れた原材料の加工処理が上げられる。例えば製造業では製品製造工場などが前記所定商品生成部1152に対応する。また本実施形態ではそれに限らず、例えば太陽電池や風力発電機や火力発電機、地熱発電機などを所有した電力発電所またはその関連周辺機器としての変電所や送電所などを対応させても良い。また本実施形態システムは上記に限らず、ガソリンの精錬所や貯水設備など他の公共消費材の生産場所なども上記所定商品生成部1152の形態例に対応させられる。更にそれ以外の別の商品形態として、“サービスプロバイダA内で創出される独自情報”を生成する場所を上記所定商品生成部1152に対応させても良い。例えばインターネット上に公開されている各種情報を分析した結果新たに得られた分析情報として例えば市場動向情報や気象予測情報なども上記商品の一形態に対応する。
所で図1に示した所定商品貯蔵部1154では、以下のいずれかの商品(情報を含む)の一時的貯蔵を行う。
α〕卸売業者A_1102または卸売業者B1/2_1104−1/2から卸された商品や情報
β〕上記所定商品生成部1152で生成した商品や情報
γ〕ドメイン1〜3_1122−1〜3から吸い上げた商品や情報
δ〕上記〔α〕〜〔γ〕の組み合わせ
例えば一時的貯蔵を行う商品が電力の場合には、上記所定商品貯蔵部1154は蓄電池と充電/放電量モニタ部(システムα_1132内のスマートメータ1124に対応)、充電/放電量制御部から構成される。一方一時的貯蔵を行う商品が上水や都市ガスの場合には、水やガスタンクと貯蔵/放出量モニタ部、貯蔵/放出量制御部から構成される。
上述したサービスプロバイダA〜C_1112−1〜3からサービスの提供を受ける側は、後述するドメイン2_1122−2あるいはその中システムα_1132(詳細は後述)となる。そしてそのサービス提供の対価をサービスプロバイダA〜C_1112−1〜3に直接支払うシステムとなっている。ここで図1が示すように、サービスプロバイダB_1112−2内のサーバn_1116−nとサービスプロバイダA_1112−1内の所定商品貯蔵部1154は、ドメイン2_1122−2とシステムα_1132内に設置されたスマートメータ1124や後述するシステムコントローラα_1126と直接ネットワーク接続されている。また図1の破線で記載されるように、スマートメータ1124は、卸売業者A_1102ともネットワーク接続され、直接に情報通信できる。所で図1では、スマートメータ1124の測定値を通信伝達する相手はサービスプロバイダB_1112−2内のサーバn_1116−n、同一システムα_1132内のシステムコントローラα_1126または卸売業者A_1102になっている。しかしそれに限らず、同一ドメイン2_1122−2内に存在するが異なるシステムβ_1134内に属したシステムコントローラβ_1134あるいは同一ドメイン2_1122−2内の他の機器に、このスマートメータ1124の測定値を通信伝達しても良い。
このスマートメータ1124とは、ドメイン2_1122−2(あるいはシステムα_1126)の内部と外部との間で出入りする(類似した)商品毎の出入り量を所定の時間間隔毎に測定する機器(Device)を意味する。主に電力メータ、ガスメータ、上水道メータ、下水道メータなどの公共消費材に関する出入り量の測定を指し、特に外部から内部へ流入する(または内部で消費する)量と並行して内部から外部へ流出する(例えば外部へ販売する)量も測定値として収集可能な特徴を有する。しかし本実施形態システムでは前記の公共消費材の出入り量に限らず、例えば通信販売などで購入する一般消費材や流動資産、あるいは特定の情報の出入り量を上記スマートメータ1124で測定し、その結果を通信伝達しても良い。
特に本実施形態システムではスマートメータ1124内に通信モジュール1202−1が内蔵され(図8A)、スマートメータの測定値が所定時間毎に通信伝達する機能を有する。また更に上記通信伝達する時間間隔は、サーバn_1116−n、システムコントローラα_1126または卸売業者A_1102などが適宜変更できる。またスマートメータ1124から得られる測定値を通信伝達するタイミングは前記所定時間毎に限らず、システムコントローラα_1126やサーバn_1116−nあるいは卸売業者A_1102の要求に応じて適宜通信伝達しても良い。またそれに限らず、スマートメータ1124が外部への通信伝達が必要と自発的に判断した時に通信伝達しても良い。
このスマートメータ1124を利用した、サービスプロバイダA1102が提供するサービス形態の実施例を以下に説明する。この実施例では、サービスプロバイダA1102内の所定商品貯蔵部1154内に事前に貯蔵された所定商品や所定情報がシステムコントローラα_1126またはスマートメータ1124を経由してドメイン2_1122−2内(あるいはシステムα_1132内)に供給される。逆にドメイン2_1122−2(あるいはシステムα_1132内)内に残った余剰商品がスマートメータ1124を経由して所定商品貯蔵部1154に戻されても良い。この場合には、所定商品貯蔵部1154からドメイン2_1122−2内(あるいはシステムα_1132内)に供給され商品量とスマートメータ1124を経由して所定商品貯蔵部1154に戻された商品量の差分値が使用された商品量としてサービスプロバイダA_1112−1から料金請求される。
またそれと並行して、卸売業者A_1102や卸売業者B1/2_1104−1/2が所有または管理するインフラや配送システムを利用して商品(または情報)を直接受け取っても良い。すなわち図1の卸売業者A_1102からスマートメータ1124につながった破線に従い、スマートメータ1124を経由してドメイン2_1122−2内あるいはその中のシステムα_1132内で卸売業者A_1102が取り扱う商品(または情報)の供給を直接受けても良い。またこの場合には、同時にドメイン2_1122−2内で供給を受けた商品(または情報)の内容と量に関する情報がスマートメータ1124から逐次サービスプロバイダB_1112−2内のサーバn_1116−nへ通知され、その通知情報に基付いて定期的にサービスプロバイダB_1112−2からユーザに料金請求される。ここで、ドメイン2_1122−2内あるいはシステムα_1132内に所定商品を供給するための窓口となるスマートメータ1124に向けた卸売業者A_1102からの商品供給経路が複数(卸売業者A_1102からスマートメータ1124に向かう“破線”の直接経路とサービスプロバイダA_1112−1を経由する経路)存在する事でサービスプロバイダA_1112−1に拠る新たな独自サービスが提供できる所に、図1に示した本実施形態システムの特徴が有る。なお、この特徴を活かして生じる独自効果は、5.2.1節で詳細に説明する。
次に上記サービスプロバイダA〜C_1112−1〜3から広域ネットワークを経由してサービスの提供が受けられるドメイン2_1122−2あるいはその中システムα_1132の説明をする。図1が示すように、1個のドメイン2_1122−2は1個以上のシステムα/β_1132/1134から構成され、システムα/β_1132/1134内には個々にシステムコントローラα/β_1126/1128が設置されている。またシステムコントローラα/β_1126/1128間またはスマートメータ1124との間は直接的あるいはサーバn_1116−nを介してネットワーク接続され、相互間の情報通信が可能となっている。そしてシステムα_1132内は複数のセクション1〜m_1142−1〜mへの分割が許容される(セクションに関しては、第4章で詳細に説明する)。
上述したように本実施形態システムでは同時に複数の異なるシステム(クライアントシステム)の共存を許容する所に特徴が有る。すなわち図2に記載した内容も加味すると、情報を取得もしくは作成して通信する機能を有するユニット1290と、前記ユニット1290からの前記情報を取得し管理するシステムコントローラα_1126(及びβ_1128)とを備えたクライアントシステムα_1132(及びβ_1134)を複数(クライアントシステムα_1126とクライアントシステムβ_1134の複数)含む複合クライアントシステム(図1のドメイン2_1122−2に対応)であって、前記複合クライアントシステム(ドメイン2_1122−2)に含まれるクライアントシステムα_1132を管理する前記システムコントローラα_1126は複数存在する複数のユニット1295−1〜−7を管理対象であるセクション(図2におけるセクション1_1142−1とセクション2_1142−1及びセクションm_1142−m)に区分し、各ユニットが属する該セクションに関する情報(図23のセクション情報)を保持する。
所で上記のドメイン1〜3_1122−1〜3とは、1個または互いに連携した複数のシステムから構成されたネットワーク空間を意味する。特に本実施形態システムでのドメインは、『各種状態観測の対象となるネットワーク空間』または『所定の動作や実行を行う対象または(特定サービスに関係した)運営実行の対象となるネットワーク空間』に対応する。ここで特定ドメイン内に参加して活動するためには、ドメイン固有の識別情報ID(Identification Information)と独自なパスワードを必要とする場合が有る。所で1個のシステムα/β_1132/1134を物理的または地理的に近接した特定領域に対応させた場合には、1個のドメイン1〜3_1122−1〜3は前記物理的または地理的な空間を超越した特定集団の構成メンバが管理/使用するネットワーク上の所定領域に対応する。
次に上記のシステムα_1132とは、内部が互いにネットワークで接続され、内部に1個のシステムコントローラα_1126が設置された最小のネットワークシステム単位を意味する。またこのネットワークシステムは、前述したシステムコントローラα_1126により管理または運営される。特に一人または複数の特定ユーザに関連した物理的または地理的に近接した特定領域(例えば一人または複数の特定ユーザの所定時間内での行動範囲内で規定される領域)として、1個のシステムα_1132の物理的または地理的範囲を位置付けても良い。また本実施形態システムにおける1個のシステムα_1132は、具体的にはPAN(Personal Area Network)やLAN(Local Area Network)、MAN(Metropolitan Area Network)、WAN(Wide Area Network)などで所定識別情報により特定されたネットワーク単位に対応付ける事が出来る。例えばIEEE(Institute of Electrical and Electronic Engineers)802.15.4では個々のPANに対して個別の識別情報PANID(Personal Area Network Identifier)の設定が規定されているが、この特定のPANIDで規定された1個のPANを、本実施形態における1システムに対応付けても良い。また別の具体例な表現としては、1システムを1戸(Home)、1台の車内、1台の携帯端末周辺空間や1台の業務環境(Work Station Area)などに対応付けても良い。
また上述したシステムコントローラα/β_1126/1128とは、1システム内に1台以上配置され、上記システムα/β_1132/1134に相当するネットワークシステム内での通信制御や通信状態の管理や運営を行う機器を指す。また上述したように、上記システムコントローラα/β_1126/1128を介してシステムα/β_1132/1134外の広域ネットワーク(サービスプロバイダA〜C_1112−1〜3と情報通信時に利用するネットワーク)にも接続されている。また上記システムコントローラα/β_1126/1128は、同一システムα/β_1132/1134内の1個以上のセンサモジュール(図8A、図9を用いて後述するセンサモジュール1260)から得られる信号や情報を収集して適正な処理を行うためのプロセッサを内蔵する。システムコントローラの具体例としては1台のPC(Personal Computer)、スマートホンやタブレット、携帯電話などの携帯端末、プロセッサ内蔵の分電盤やプロセッサ内蔵の冷蔵庫、あるいはテレビまたは録画可能なレコーダや音声のみを記録する録音機などを対応させても良い。またスマートメータ1124内部にプロセッサを内蔵させて、スマートメータ1124自体にシステムコントローラα_1126の機能を持たせても良いし、あるいはエアコンやテレビ、照明器具などのリモコン内にプロセッサと通信モジュール(図8A、図9を用いて後述する通信モジュール1202)を内蔵させてシステムコントローラとして使用しても良い。しかしそれに限らず本実施形態では、システム内のセンサモジュールから得られる信号や情報を収集してユーザに適正なサービスを提供するためのプログラムが設定されたあらゆるプロセッサ内蔵機をシステムコントローラに対応させても良い。また物理的に複数の機器(Devices)の組み合わせ/連携動作に拠り1個のシステムコントローラを構成しても良い。
特に内部にプロセッサと通信モジュールを内蔵させてシステムコントローラとして使用したリモコンを壁や棚の上にネジ留め等の固定あるいは移動可能な形で一時的に配置させると、独自の使い方(とそれにより生じる効果)が生まれる。但しこの場合、エアコンやテレビ、照明器具などの本体機器と赤外線通信が可能な場所に固定あるいは配置する必用が有る。更に部屋の中の至る所に、温度センサや風力センサ、あるいは短距離の人感センサなどに関係したセンサ/通信モジュール(図8Bを用いて後述)を設置し、上記リモコン(システムコントローラα_1126)との間のシステムα_1132内通信を可能にする。これにより部屋内の複数ユーザが居る場所のみの温度を優先的に精度良く制御する、あるいは裸眼テレビの表示方法を複数ユーザの居場所で同時に立体的に見えるように表示方法を制御するなどユーザに対する効率の良いサービスを提供できる。これにより、既存のリモコンのみを上記システムコントローラ機能付きリモコンに交換するだけで既に設置済みの既存の(エアコンやテレビ、照明器具などの)本体機器を交換せずに今までよりも効率良く動作させられる効果が生まれる。
従来のM2M(Machine to Machine)またはIoT(Internet of Things)と呼ばれる技術では、各戸の家庭内センサモジュールから得られる全ての信号や情報をクラウドサーバ(図1のサーバn_1116−nに相当)が収集し、クラウドサーバから直接エンドユーザにサービスを提供する場合が多かった。この場合には、システムコントローラα_1126は図9に示すゲートウェイやルータとしてネットワーク上の信号や情報の伝達を中継するだけの機能を担っていた。このような従来技術では
(1) 比較的公共性が有るサーバn_1116−nに容易にユーザの個人情報が伝達されるため、ユーザの個人情報保護の視点から問題が有る
(2) システムコントローラα_1126またはスマートメータ1124とサーバn_1116−n間の通信回線にトラブルが生じるとエンドユーザへのサービスが滞ると言うシステム全体としての脆弱性が有る
との課題が有った。本実施形態ではシステムコントローラα_1126はゲートウェイやルータとしてネットワーク上の信号や情報の伝達中継機能に限らず、内蔵されたプロセッサにより収集されたセンサモジュールからの信号や情報の判定あるいは統合や加工もしくはそれらに基付くユーザへの独自サービスを含めた特定処理を行う所に特徴が有る。それにより本実施形態では
(1) サーバn_1116−nへの個々の信号または情報の送信可否判定をシステムコントローラα_1126が独自に行うため、ユーザの個人情報保護が保たれる
(2) センサモジュールから収集した信号や情報に基付き、システムコントローラα_1126判断によりユーザへの独自サービスを提供できる、しかもこのサービスはサーバn_1116−nとの通信回線トラブル有無に関わらず実行可能なため、システム全体の堅牢性が向上する などの効果が生じる。特に本実施形態におけるシステムコントローラα_1126は、センサモジュール1260から得られる情報を統合してユーザの行動(ユーザの有無や睡眠/覚醒等の行動)や状況(例えばユーザが子供/大人か?の状況)を判定/推定し、更にユーザの要求推定まで行えられる機能を持つ所に特徴が有る。それによりサーバn_1116−nが無い状態でも、独自にドメイン2_1122−2内でユーザに対する快適なサービス提供が可能となる効果が生まれる。
また本実施形態システムでは、同一ドメイン2_1122−2内で複数のシステムコントローラα/β_1126/8間での協調作業が可能な所に大きな特徴が有る。従って1台のシステムコントローラα_1126は、同一ドメイン2_1122−2内に存在する全てのセンサモジュール(図示して無いが、システムβ_1134内に配置されたセンサモジュールも含む)から得られる信号や情報の収集が可能である。その結果上記システムコントローラα_1126は同一ドメイン2_1122−2内の情報を統合利用して、システムα_1132内の最適なサービスをユーザに提供できる効果が有る。
この同一ドメイン2_1122−2内での複数のシステムコントローラα/β_1126/8間の強調作業形態として本実施形態システムでは、図1が示すように例えば無線通信などを利用してシステムコントローラα/β_1126/8間で直接情報交換を行うネットワーク経路と、例えばインターネット経路を利用してサーバn_1116−nを介してシステムコントローラα/β_1126/8間が間接的に情報交換を行うネットワーク経路の2通り存在する所に特徴が有る。それにより、ユーザが多彩なサービスを受けられる効果が生まれる。例えば自宅PCであるシステムコントローラα_1126とスマートホンやタブレットなどの携帯端末が相当するシステムコントローラβ_1128が物理的に近い位置にある場合には、WLAN(Wireless Local Area Network)やWPAN(Wireless Personal Local Area Network)を経由して高速に情報交換できる。一方途中に有線を含むインターネット回線を使う事で、両者が物理的にどんなに離れていても互いの情報交換が保証される効果が有る。また一方、両者が直接的に情報交換する事で、サーバn_1116−nを関与せず独自でプライベートなサービスが得られるため、個人の秘密情報が比較的公共性を持つサーバn_1116−nへ漏洩する危険性を防止できる。一方サーバn_1116−nは別のネットワーク経路を利用して、例えば地域の気象予測情報や交通渋滞情報などのドメイン2_1122−2内では獲得できない情報を取得できる。そのためサーバn_1116−nを介してシステムコントローラα/β_1126/8間が間接的に情報交換を行う事で、サーバn_1116−n独自が所有する情報も活用した多彩なサービスをユーザに提供できる。このように適宜ネットワーク通信経路を切り替える事で、ユーザが望むより多彩なサービスを提供できる効果も生まれる。ここで前述したようにシステムコントローラα_1126自体でユーザの行動や状態を推定またはユーザの欲求/要求を推定できるため、システムコントローラα_1126の独自判断によりシステムコントローラα/β_1126/8間の接続経路を切り替えられる。
1.8節 本実施形態におけるローカルなネットワークシステム構造の説明
1.1節では既に、図1に記載したドメイン2_1122−2の中に含まれるシステムα_1132内で構成されるローカルなネットワークシステム内の構造例に関して図2を用いて概説した。本1.8節では前述した図2以外の他の実施形態システムの応用例に付いて、図8A〜図9を用いて説明する。
図8Aに示す実施形態での各機器(Device)1250−1〜3は通信モジュール1202−4〜6が内蔵され、同一システムα_1132内での情報通信が可能となっている。また機器(Device)1250−1〜3内でセンサモジュール1260−1〜5または駆動(Actuator)モジュール1270−1が内蔵されている。それに比べて図8Bでは、通信モジュール1202−4〜6とセンサモジュール1260−1〜5間の関連状態をセンサ/通信モジュール1460−1〜5と言う概念で把握または管理する。同様に通信モジュール1202と駆動モジュール1270間の関連状態を駆動/通信モジュール1470−1〜2と言う概念で把握または管理する。またそれに限らずに1.3節で説明したように、プロセッサ/通信モジュール1465、メモリ/通信モジュール1475、表示/通信モジュール1478などの概念まで総称した複合モジュール1295と言う考え方で統合的に管理される。所で図8Bのセンサ/通信モジュール1460−5のように、1個の複合モジュールが単体で存在しても良い。
本実施形態システムでは、1システム内(例えばシステムα_1132内)でトータル的に使用する電気やガス、上水道/下水道などの公共消費材の所定時間毎の使用量(または積算量)を自動測定し、その測定データを定期的に自動送信するスマートメータ1124が設置されている。実際には電気やガス、上水道/下水道などの公共消費材毎に個々に異なるスマートメータ1124が設置されているが、図8A/Bでは代表として1個のスマートメータ1124のみを記載している。また上記に限らず、後述するセクション1_1142−1、2_1142−2毎の上記公共消費材の使用量(または積算量)を自動測定/自動送信しても良い。
上記スマートメータ1124内の詳細な構造は図8Aや図9に示すように、流入量モニタ部1208(例えば買電量計量部)とは別に放出量モニタ部1206(例えば売電量計量部)が設置されている。そしてこの放出量モニタ部1206を用いて、システムα_1132内での公共消費材の余剰分の卸売業者A_1102への放出(売電)量の計測を行う。そしてスマートメータ1124内で得られた各計量値(または積算値)は、通信モジュール1202−1を介してサーバn_1116−nへ定期的に報告される。またそれと並行して卸売業者A_1102へも報告される。
図8Aあるいは図9で示す通信モジュール1202とは、有線や無線などを利用した情報の通信が可能な通信機能部を示す。この通信機能部が対応する有線通信としては、ローカルな映像信号伝送線や音声信号伝達線から始まり、電話線やインターネットに関連したイーサーネット(Ethernet)(登録商標)対応通信に至るあらゆる通信方式が関係しても良い。また上記通信機能部が対応する無線通信としては、ZigBee(登録商標)、Bluetooth(登録商標)、UWB(Ultra Wide Band)、Z-Waveなどの近距離無線方式、Wi−Fi(Wireless Fidelity)、EnOceanなどの中距離無線方式、2G/PDC、GSM(登録商標)(Second Generation / Personal Digital Cellular, Global System for Mobile Communications)や3G/CDMA(Third Generation / Code Division Multiple Access)、WiMAX(World wide Interoperability for Microwave Access)などの遠距離無線のあらゆる無線通信方式が関係しても良い。
特に本実施形態システムでは図10Aを用いて後述するように、通信モジュール1202、1660内での最低限必要なプロセス処理の実行機能を持つ。それにより第2章で後述するような図11から図15Bまでの構造を有する通信プロトコル(通信情報)の処理と実行が、上記通信モジュール1202、1660内でプロセス処理される。このプロセス処理として例えば、特定OSを必要としないJavaスクリプトなどの汎用性を持った基本的(標準的)アプリケーションに準拠したプロセス処理が対応しても良い。またそれに限らず、ECMA Script に対応したプロセス処理、あるいはHTML(Hyper-text Markup Language)やHTML5の解読機能やそれに対応したJavaアプレットの実行が対応しても良い。更に上述した既存の汎用スクリプトに限らず、独自のプロセス方式を採用しても良い。
図8Aと図9ではシステムコントローラα_1126及びスマートメータ1124、各種機器(Device)1250内に共通して上記通信モジュール1202が内蔵され、互いの情報通信が可能となっている。一方図8Aと図9に示すように、各種機器(Device)1250内にはセンサモジュール1260または駆動(Actuator)モジュール1270が内蔵される。
図8Aが示す本実施形態システムでは、同一システムα_1132内に設置された複数の機器(Device)1250−1〜3は、それぞれ内蔵された通信モジュール1202−4〜6と通信モジュール1202−3を経由してシステムコントローラα_1126との間で情報通信する。ここで図8Aのように、1個以上(複数)のセンサモジュール1260−3〜5のみを内蔵する機器1250−2〜3と、1個以上(複数)のセンサモジュール1260−1〜2と駆動モジュール1270−1の両方を内蔵する機器1250−1、及び図示して無いが駆動モジュール1270のみを内蔵する機器1250の存在が許される。一方図8Aが示す実施例形態では、デバイスコントローラ1240−1を内蔵し、センサモジュール1260−1〜2と駆動モジュール1270−1に関する履歴情報を逐次格納/管理できるメモリ部1242を所有する機器1250−1とそれらを所有しない機器1250−2〜3の混在配置が可能となっている。
所で図1を用いて1.7節内で説明したサービスプロバイダA_1112−1内と同様に、システムα_1132内で所定商品生成部1152相当機能または所定商品貯蔵部1154相当機能を所有する事で、上記公共消費材の余剰分の確保と一時的な保持が可能となる。図8A/Bでは所定商品貯蔵部1154に相当する機能の例として、(カー)バッテリ1220の使用例を示している。しかしそれに限らず、本実施形態システムでは所定商品生成部1152または所定商品貯蔵部1154の機能を有するいかなる機器(Device)をシステムα_1132内に設置しても良い。例えばビル単位や地域単位でバッテリセンターや貯水漕(などの貯蔵機器)を設置し、ビル内や地域内で発生した公共消費材の余剰分の一時的な保持を行っても良い。
図8A/Bでは具体例として便宜上、(カー)バッテリ1220の使用例を説明する。またここでは1台の車内空間を、後述する1個のセクション1_1142−1に対応させる。そのため、車内で検出されるあらゆる情報(例えばガソリン消費料やエンジンの回転数、車内温度や乗車している人個々の人体情報など)がセンサモジュール1222で検出され、その結果が通信モジュール1202−2を経由してシステムコントローラα_1126に伝えられる。同様にこのセクション1_1142−1内(車内)には(カー)バッテリ1220への充電量を測定する流入量モニタ部1218と(カー)バッテリ1220から外部に放出(売電)される電力量を測定する放出量モニタ部1216が設置され、各測定値は通信モジュール1202−2を経由してシステムコントローラα_1126に伝えられる。特に本実施形態システムでは、(カー)バッテリ1220から外部に放出(売電)される電力量を精度良くコントロールできる放出量制御部1212と(カー)バッテリ1220に充電される電力量を精度良くコントロールできる流入量制御部1214が設置されている。いずれも通信モジュール1202−2と3を経由してシステムコントローラα_1126と接続されている。そのためシステムコントローラα_1126は、この放出量モニタ部1216で逐次測定される放出(売電)電力量を放出量制御部1212にフィードバックして精度良く外部に放出(売電)される電力量を制御できる。同様にシステムコントローラは、この流入量モニタ部1218で逐次測定される流入(買電)電力量を流入量制御部1214にフィードバックして精度良く(カー)バッテリ1220に充電される電力量を制御する。
既に1.7節で上記システムコントローラα_1126が、対応するシステムα_1132(ネットワークシステム)内での通信制御や通信状態の管理や運営を行う説明をした。図8Aが示すように、このシステムコントローラα_1126はプロセッサ1230を内蔵する。このプロセッサ1230は同一ドメイン2_1122−2内の全てのセンサモジュール1222、1260−1〜5からの情報を収集し、メモリ部1232に逐次履歴情報として格納する。また駆動モジュール1270−1に対する命令情報も同様に履歴情報として格納する。更にこのシステムコントローラα_1126内にユーザI/F部1234を持ち、ユーザからの要求の直接入力やユーザに対する現状の進行状態の表示などが可能となっている。しかしそれに限らず、ユーザI/F部1234がシステムコントローラα_1126の外部に設置され、通信モジュール1202−3を介して接続されても良い。
特に本実施形態システムではドメイン2_1122−2内の全てのセンサモジュール1222、1260−1〜5と駆動モジュール1270−1に関する情報を全てサーバn_1116−nに自動転送するのでは無く、システムコントローラα_1126(内のプロセッサ1230)が自律的に取捨選択して必要な情報のみをサーバn_1116−nに送信する所に大きな特徴が有る。それによりユーザの個人情報保護が守られる効果が生まれる。また上記のような情報の取捨選択に限らず、上記情報から一部の加工や解析を行い、その結果のみをサーバn_1116−nに通知しても良い。それにより必要最低限の情報のみをサーバn_1116−nが収集できるため、サービスプロバイダB_1116−1内で行う統合的管理処理の効率を上げる効果も有る。
更に本実施形態システムでは、システムコントローラα_1126(内のプロセッサ1230)が通信モジュール1202−3を経由してサーバn_1116−nから独自情報を収集してメモリ部1232に格納できる。この独自情報とは、例えば交通渋滞情報や地域の気象予測情報、公共消費材の時変価格情報などドメイン2_1122−2内からは得られない情報を意味する。このようにしてメモリ部1232に蓄積された情報をシステムコントローラα_1126(内のプロセッサ1230)が分析/解析し、エンドユーザの行動や状態あるいは要求を推定/判断する。そしてこの推定/判断した内容に基付き、システムコントローラα_1126(内のプロセッサ1230)がシステムα_1132(あるいはドメイン2_1122−1)内を制御し、エンドユーザに対して最適なサービスを提供する。このサービス提供方法の一例として、図8A内の駆動モジュール1270−1を遠隔操作しても良い。このように独自にシステムコントローラα_1126(内のプロセッサ1230)が、センサモジュール1222、1260−1〜5やサーバn_1116−nから収集した情報と駆動モジュール1270−1への命令履歴を統合的に分析/解析するため、従来は難しかったドメイン2_1122−2内でのユーザに対するきめ細かなサービスの提供など独自のサービスを提供できる効果が有る。更にこのようなドメイン2_1122−2内独自のサービスはシステムトラブルに拠るサーバn_1116−nとの通信不能状態でも安定に提供できるため、エンドユーザに提供するサービスの堅牢性を確保できる。
図8Aに示した本実施形態システムの応用例を図9に示す。図9ではスマートメータ1124とルータ(ゲートウェイ)1300を除くドメイン2_1122−2内の全ての機器1250−1&4にプロセッサ1330又はデバイスコントローラ1240−1〜2が内蔵され、バッテリを内蔵したルータ(ゲートウェイ)1300を介してサーバn_1116−nとの間での直接的な情報交換が可能となっている。
ここでセクション1_1142−1(1台の車内)に内蔵されたプロセッサ1330は(カー)バッテリ1220から充電/放電される電力量の制御に限らず、例えば車内の空調管理や燃費的に効率の良いエンジンの燃焼制御等のあらゆる制御を行い、これらの関連情報がルータ(ゲートウェイ)1300を経由して(あるいは直接的に)サーバn_1116−nへ送信可能となっている。また全ての通信モジュール1202−1〜7はルータ(ゲートウェイ)1300を経由してサーバn_1116−nとネットワーク接続されている。ここで図9に示す応用例ではルータ(ゲートウェイ)1300は一切の判別や取捨選択を行わず、機器1250−1/4からの情報全てをサーバn_1116−nに自動転送する所が図8Aのシステムコントローラα_1126とは機能的な大きな違いが有る。
一方図9に示す応用例では、ドメイン2_1122−2内の全ての機器1250−1/4内にメモリ部1244、1246が内蔵されている。そしてセンサモジュール1260−1〜7で時々刻々と検出される信号や情報が時系列的にメモリ部1244、1246に逐次格納される。またデバイスコントローラ1240−1〜2から駆動モジュール1270−1〜3に適宜発行される命令情報も、逐次メモリ部1244、1246に格納される。そしてこのメモリ部1244、1246に格納された情報を利用して、デバイスコントローラ1240−1〜2はエンドユーザに対する機器1250−1〜4単位での独自サービスが提供できる。このサービス提供時には、メモリ部1244、1246内に格納された時々刻々と変化するセンサモジュール1260−1〜7からの検出信号や測定情報の履歴を利用し、デバイスコントローラ1240−1/2内でエンドユーザの行動や状態あるいは要求を推定/判断し、駆動モジュール1270−1〜3を制御する(詳細は4.2節〜4.4節内で後述)。
そして図9に示す応用例の特徴は、『ネットワーク通信システムα_1132(が形成する物理的空間領域)の外から、対応するネットワーク通信システムα_1132全体の管理または制御が行われる』あるいは『ネットワーク通信システムα_1132(が形成する物理的空間領域)内に配置され、対応するネットワーク通信システムα_1132全体の管理または制御を行うシステムコントローラα_1126を持たない』所に有る。このような視点から見ると、バッテリ内蔵のルータ(ゲートウェイ)1300を介してシステムα_1132内の機器1250−1、4との間で形成される同一システム内ネットワーク回線1782内での情報通信の管理や運営を、サーバn_1116−nの代わりにシステムα_1132から物理的に離れた位置に設置されたシステムコントローラβ_1128が行っても良い。
そして更なる応用例として、図2または図8A/Bに示す実施形態システムと図9の実施形態システムとの間の“混合形態”を取っても良い。この場合のシステムα_1132内外の中継手段として、システムコントローラα_1126とバッテリ内蔵のルータ(ゲートウェイ)1300の両方を持っても良い。またネットワーク通信システムα_1132全体の管理や運営あるいは制御を、このシステムコントローラα_1126とシステムコントローラβ_1128の両方が協調して行っても良いし、通常はシステムコントローラα_1126のみが行っても良い。そしてこのシステムコントローラα_1126とこのシステムコントローラβ_1128間は頻繁に情報交換を行い、セクション1_1142−1〜m_1142−m毎の情報収集やユーザへのサービス提供に必要な全ての情報は両社間で共有する。この場合には、システムコントローラα_1126内のメモリ部1232内に保存されている関連ファイルがミラーリングにより、システムコントローラβ_1128内の対応メモリ部1248内と適宜相互コピーされる。所でこのセクション1_1142−1〜m_1142−m毎の情報収集やユーザへのサービス提供に必要な情報の一例で有る図23のアドレステーブル、図27の推定/判断照合表や図28の時系列情報追跡表の説明は、後述する。このようにシステムコントローラα_1126、β_1128間で適宜情報共有を行う事で、途中で管理/運営や制御の主体が入れ替わっても(あるいは混在しても)混線せずに安定なシステムα_1132内での処理が継続する。またそれに限らず、システムコントローラα_1126とサーバn_1116−nが協調してネットワーク通信システムα_1132全体の管理や運営あるいは制御を行っても良い。そしてこの場合には上記と同様に(ミラーリングなどを利用して)、セクション1_1142−1〜m_1142−m毎の情報収集やユーザへのサービス提供に必要な全ての情報をシステムコントローラα_1126とサーバn_1116−n間で共用しても良い。このように異なる位置に配置された複数の装置でネットワーク通信システムα_1132全体の管理や運営あるいは制御を行う事で、緊急時の対応など柔軟に行えるのでネットワーク通信システムα_1132の安定性と信頼性が向上する効果が有る。例えば何らかの不測の事態でシステムコントローラα_1126がシャットダウンした場合、あるいはヘッドクラッシュなどによりメモリ部1232内に保存された情報が全て破壊されても、緊急対応として自動的にシステムコントローラβ_1128やサーバn_1116−nに切り替わり、ユーザに一切のストレスを与える事無く引き続き安定にシステムα_1132の処理が継続できる。またそれだけで無く、例えばユーザが離れた場所からシステムコントローラβ_1128を操作してネットワーク通信システムα_1132からの情報収集やネットワーク通信システムα_1132内の制御が行えるため、ユーザの利便性が向上する。またこの場合のシステムα_1132内では、デバイスコントローラ1240やメモリ部1242を内蔵する機器1250−1、4や、デバイスコントローラ1240やメモリ部1242を持たない機器1250−2、3あるいは後述する例えばセンサ/通信モジュール1460や駆動/通信モジュール1470を総称した複合モジュールが混在しても良い。
上述した“混合形態”に関する補足説明をする。図5に示すように、ネットワークシステムα_1132内に配置された複合モジュール1295(またはユニット1290)が蓄電モジュール(電池)1554を所持する場合が多い。それゆえに仮にシステムα_1132内で停電が発生したとしても、複合モジュール1295(またはユニット1290)の多くは影響を受けずに動作し続ける。更に図9の実施形態システムでは、システムα_1132内外の情報通信を中継するルータ(ゲートウェイ)1300にバッテリが内蔵されているため、ネットワークシステムα_1132内の停電の影響を受けない。従って停電や故障などの不測自体発生時にネットワークシステムα_1132内の管理/制御をバックアップする手段を設定すれば、停電や故障などの不測自体の影響を受けずにシステムα_1132内の情報通信が滞り無く継続する。
既に1.1節内で“唯一のシステムコントローラα_1126がネットワークシステムα_1132内の情報通信の管理/制御/運営/情報収集を行う”と説明したように、通常時のネットワークシステムα_1132内での情報通信の管理/制御/運営/情報収集は、システムコントローラα_1126が行う。しかし停電や故障などの不測自体発生時には、システムコントローラβ_1128がネットワークシステムα_1132内での情報通信の管理/制御/運営/情報収集の臨時代行を行う。所で通常時には、システムコントローラβ_1128をネットワークシステムα_1132内に所属する1個のユニット1290として扱っても良い。
また既に1.1節内で図1と図2を用いて説明したように、ネットワークシステムα_1132内の情報通信の管理/制御/運営/情報収集を行うシステムコントローラα_1126はネットワークシステムα_1132内の各ユニット1290とネットワークシステム内の情報通信を行うと共に、ネットワークシステムα_1132外に存在するサーバn_1116−n(クラウドもしくはクラウドサーバ)との間でシステム外の情報通信を行う。そして停電や故障などの不測自体発生時にシステムコントローラβ_1128がシステムコントローラα_1126の臨時代行を行う場合、臨時代行前と同じ通信情報フォーマットで各ユニット1290及びサーバn_1116−nとの間の情報通信が望まれる。なぜなら、同一の通信情報フォーマットを使用する事でスムーズかつシームレスに臨時代行処理が行える。
図10Aを用いて2.1節で後述するように、システムコントローラα_1126と複合モジュール1295間の通信ミドルウェア層APL02における通信情報はC−フォーマットを使用できる。一方では、システムコントローラα_1126とサーバn_1116−n(クラウドもしくはクラウドサーバ)間の通信ミドルウェア層APL06における通信情報は、A−フォーマットまたはE−フォーマット、W−フォーマットなどを使用しても良い。従ってシステムコントローラα_1126に代わってシステムコントローラβ_1128が代行処理を行う場合には、同様の情報通信を行うのが望ましい。すなわちシステムコントローラβ_1128と複合モジュール1295間の通信ミドルウェア層APL02における通信情報はC−フォーマットを使用し、サーバn_1116−n(クラウドもしくはクラウドサーバ)との通信情報にはA−フォーマットまたはE−フォーマット、W−フォーマットなどを使用する。
このようにして図10Aや図17Aを用いて2.1節で後述する内容と、上記に説明した本実施形態システムを組み合わせて生じるクライアントシステムの特徴を下記に纏める。すなわちこのクライアントシステム(システムα_1132)は(図10Aのシステムコントローラα_1126あるいは図17Aのルータ(ゲートウェイ)1300やシステムコントローラβ_1128を経由して)外部のクラウド(図1のサーバn_1116−1)と接続可能で有り、更にこのクライアントシステム(システムα_1132)は独自に取得もしくは作成した情報を通信する機能を有したユニット1290(または複合モジュール1295)からの前記情報を取得し管理する第1のシステムコントローラα_1126と前記ユニット1290(または複合モジュール1295)からの前記情報を取得し管理する前記第1のシステムコントローラα_1126とは異なる第2のシステムコントローラβ_1128とを備え、前記第1のシステムコントローラα_1126が複数のユニット1290(または複合モジュール1295)をセクション1142(図1)に区分して管理し、各ユニットが属する該セクションに関する情報(4.3節で後述する図23のアドレステーブルまたは図28の時系列情報追跡表)を保持する電子機器システムであって、前記第2のシステムコントローラβ_1128と前記複数のユニット1290(または複合モジュール1295)との間の通信は第1のデータフォーマット(図17AのC−フォーマット)を用いるとともに、前記第2のシステムコントローラβ_1128と前記クラウド(図1のサーバn_1116−1)との間の通信は第2のデータフォーマット(図17BのA/E/W−フォーマット)を用いる特徴が有る。
所で通常時にはシステムコントローラβ_1134が、システムコントローラα_1126が管理/制御/運営/情報収集を行うネットワークシステムα_1132に属する1個のユニット1290と扱っても良い事を既に説明した。また本実施形態システムでは、ネットワークシステムα_1132を介して(経由して)同一ネットワークシステム1132内の異なるユニット1290間の情報通信が可能となっている。そして上述したようにシステムコントローラα_1126とユニット1290間で情報通信する場合には、通信ミドルウェア層APL02における通信情報はC−フォーマットを使用できる。従ってシステムコントローラα_1126とシステムコントローラβ_1128間で情報通信する場合にも、通信ミドルウェア層APL02における通信情報にC−フォーマットを使用した方がシステムコントローラα_1126の管理/制御/運営/情報収集が容易となる効果が生まれる。
一方ではシステムコントローラβ_1134がサーバn_1116−n(クラウドまたはクラウドサーバ)との間で通常時に情報通信する時でも、通信ミドルウェア層APL06での通信情報にA−フォーマットまたはE−フォーマット、W−フォーマットを使用するのが望ましい。それにより停電や故障などでシステムコントローラα_1126の使用が不可能となった場合に、ネットワークシステムα_1132の管理/制御/運営/情報収集に関する臨時代行処理がスムーズかつシームレスに行える効果が生まれる。
この内容を言い換えると、下記のように表現できる。すなわちこのクライアントシステム(システムα_1132)は(図10Aのシステムコントローラα_1126あるいは図17Aのルータ(ゲートウェイ)1300やシステムコントローラβ_1128を経由して)外部のクラウド(図1のサーバn_1116−1)と接続可能で有り、更に独自に取得もしくは作成した情報を通信する機能を有したユニット1290(または複合モジュール1295)からの前記情報を取得し管理する第1のシステムコントローラα_1126と前記ユニット1290(または複合モジュール1295)からの前記情報を取得し管理する前記第1のシステムコントローラα_1126とは異なる第2のシステムコントローラβ_1128とを備え、前記第2のシステムコントローラβ_1128は、前記第1のシステムコントローラα_1126を介して前記複数のユニット1290との間の通信を、第1のデータフォーマット(C−フォーマットなど)を用いて行うとともに、前記第2のシステムコントローラβ_1128と前記クラウド(図1のサーバn_1116−n)との間の通信に第2のデータフォーマット(図17BのA/E/W−フォーマット)を用いる特徴が有る。
所で今までの言い換えは、比較的システムコントローラα_1126とシステムコントローラβ_1128の協調処理や代替え処理を意識した場合が多かった。しかしそれに限らず、始めからシステムコントローラα_1126が存在しない図9単独の実施形態システムの特徴に関しても下記のように記述できる。すなわちこのクライアントシステム(システムα_1132)は(図10Aのシステムコントローラα_1126あるいは図17Aのルータ(ゲートウェイ)1300やシステムコントローラβ_1128を経由して)外部のクラウド(図1のサーバn_1116−1)と接続可能で有り、更に独自に取得もしくは作成した情報を通信する機能を有したユニット1290(または複合モジュール1295)と前記ユニット1290(図9の機器1250)からの前記情報を取得し管理するシステムコントローラβ_1128と前記ユニット1290(図9の機器1250)と前記システムコントローラβ_1128との間で通信する機能を有するゲートウェイ1300とを備え、前記システムコントローラβ_1128は複数のユニット1290(図9の機器1250)をセクション1_1142−1、2_1142−2に区分して管理すると共に各ユニット1290(図9の機器1250)が属する該セクション1_1142−1、2_1142−2に関する情報(4.3節で後述する図23のアドレステーブルまたは図28の時系列情報追跡表)を保持する電子機器システムであって、前記システムコントローラβ_1128と前記複数のユニット1290(図9の機器1250)との間の通信に第1のデータフォーマット(C−フォーマットなど)を用いるとともに、前記システムコントローラβ_1128と前記クラウド(図1のサーバn_1116−n)との間の通信には第2のデータフォーマット(図17BのA/E/W−フォーマット)を用いる特徴が有る。
1.9節 ローカルなネットワークシステム内での複合モジュールの活用例
図8Aまたは図9に示した実施形態では、図8Aのシステムコントローラα_1126または図9のサーバn_1116−nの基本的な通信相手は機器1250−1〜4となっている。そして従来は機器毎に基本機能が予め決まっていたので、機器毎の基本機能に適合したネットワーク通信情報(第2章で説明する通信ミドルウェア層APLにおける通信プロトコルまたは交換情報1810)の内容が標準規格上で予め規定されていた。しかし時代の移り変わりに従って各機器が進化/発展して多様化すると、時々刻々変化する機器毎の装備機能への標準規格の高速適応が難しくなる。例えばテレビの基本機能は、“放送波を受信し、そのコンテンツをユーザへ表示”に有る。しかし現在の日本の高級テレビでは上記の基本機能に限らず、ネットワーク回線を利用したデータ通信機能あるいは録画機能も内蔵されている。また現在はそれ程普及して無いが、裸眼3DTV(3 Dimensional Television)は視聴するユーザの位置情報を検出する機能も内蔵されている。更に将来は、(表示画面の輝度を最適に制御するため)テレビに明かりセンサが内蔵される可能性も有る。このような機器毎の多様化と拡張性を考慮して機器との1250−1〜4との通信情報形式(交換情報1810)または通信プロトコルに汎用性を持たせると、通信情報を解読するための高性能なデバイスコントローラ1240−1〜2を内蔵した機器1250−1〜4の高価格化に繋がる弊害が生じる。すなわち図8Aの機器1250−2または機器1250−3では汎用性を持った複雑な通信情報を解読するのは難しく、解読とその解読結果に応じた機器内での多様な制御を行うためのデバイスコントローラ1240の内蔵が必用となる。
その対策として図8Bでは、機器1450−1〜4内あるいは機器外の単独状態で複合モジュール1295に属するセンサ/通信モジュール1460−1〜5または駆動/通信モジュール1470−1〜2の設置を可能としている。
ここで説明の便宜上、図8Bの全ての機器1450−1〜4は複合モジュール1295に属するセンサ/通信モジュール1460−1〜4と駆動/通信モジュール1470−1〜2を内蔵した構造になっている。しかしそれに限らず、図3A(c)に示した実施形態を取っても良い。すなわち例えば図8Aや図9に示した機器1250−1〜4内に、上記の複合モジュール1295(センサ/通信モジュール1460または駆動/通信モジュール1470)が付加的に内蔵されても良い。この場合に機器毎の基本機能(例えば前例での“放送波を受信し、そのコンテンツをユーザへ表示”する機能)に関する情報通信は、図8Aや図9に示した機器1250−1〜4内で対応する。そして新たに発展して多様化して追加された新規機能に関する情報通信は、新たに付加的に内蔵された複合モジュール1295、1460、1470が直接担う。そして高度に多様化/進化した機器1250が所有する機能全体に関しては、システムコントローラα_1126内で統合的に管理/把握と制御を行う。これにより、従来の既存機器への新規機能追加時の拡張性(組み込みセンサ/駆動種類の拡張性)を容易する新たな効果が生まれる。更に上記複合モジュール1295、1460、1470毎の機能は非常に限定されて簡素化されるため、上記複合モジュール1295、1460、1470が外部との間で交換する通信情報を大幅に簡素化できる更なる効果も生まれる。このように外部との間で交換する通信情報が大幅に簡素化されると、複雑な通信情報を解読/制御するための高性能なデバイスコントローラ1240−1〜2の内蔵が不要となり、上記複合モジュール1295、1460、1470の低価格化と小形化が容易となる。
図8Bの記載例では、セクション2_1142−2内に機器1450−1と機器1450−2が配置され、セクションm_1142−m内に機器1450−3〜4が配置されている。しかし各機器1450−1〜4の設置場所は必ずしも固定されている必用は無く、特定機器1450−1〜4のいずれかをエンドユーザが運搬して別のセクション内にずらしても良い。
また図8Bの実施形態システムでは同様に、スマートメータ1124内や(例えば1台の車内全体に対応した)セクション1_1142−1内でもセンサモジュールや駆動モジュールが個々に通信モジュールと一体化されている。その結果として図8Bでのスマートメータ1124内が示すように、放出量モニタ/通信モジュール1406や流入量モニタ/通信モジュール1408が構成され、個々にシステムコントローラα_1126やサーバn_1116−nとネットワーク接続されている。また同様にセクション1_1142−1は放出量モニタ/通信モジュール1416や流入量モニタ/通信モジュール1418、放出量制御/通信モジュール1412、流入量制御/通信モジュール1414から構成され、それぞれが個々に通信モジュール1202−3を経由してシステムコントローラα_1126(内のプロセッサ1230)とネットワーク接続されている。ここで放出量モニタ/通信モジュール1406や流入量モニタ/通信モジュール1408及び放出量モニタ/通信モジュール1416や流入量モニタ/通信モジュール1418がセンサ/通信モジュール1460に対応する。また放出量制御/通信モジュール1412と流入量制御/通信モジュール1414が、駆動/通信モジュール1470に対応する。 この場合には、システムα_1132内のセンサ/通信モジュール1460−1〜5または放出量モニタ/通信モジュール1406、1416や流入量モニタ/通信モジュール1408、1418から得られる全ての検出信号や測定情報をシステムコントローラα_1126が一括して収集(及びメモリ部1232への格納)する。またシステムα_1132内の全ての駆動/通信モジュール1470−1〜2及び放出量制御/通信モジュール1412と流入量制御/通信モジュール1414に対し、システムコントローラα_1126が一括して制御(指令の発令)する。その結果、単一のシステムコントローラα_1126により、システムα_1132内のあらゆる機器1450−1〜5に対する効率良い統合的な管理と制御及びエンドユーザに対する質の高いサービス提供が可能となる。
更に図8Bに示した実施形態システム例では、機器1450−1〜5を非常に安価に製造できる効果が有る。すなわち汎用性を持った標準的な複合モジュール1460、1470を多量に量産化する事で、この複合モジュール1460、1470を大幅に安価に製造できる。そしてこの複合モジュール1295、1460、1470間を繋ぐ新規なインターフェース部を一切必要とせず、単なる物理的な配置レベルで非常に容易かつ安価に対応機器1450−1〜5に組み込める。そして駆動/通信モジュール1470−1〜2の安価供給が可能になると、機器1450−1〜5内に組み込む駆動/通信モジュール1470−1〜2の数を図8B例よりも増やせる。また更に機器1450−1〜5に対する複合モジュール1295、1460、1470の組み込み方法としてネジ止め固定に限らず、例えばエンドユーザによる両面テープや粘着テープなどを用いた暫定的固定を行っても良い。つまり図8Bに示した例では、機器1450−1と機器1450−3に1個ずつのセンサ/通信モジュール1460−4〜5が内蔵され、機器1450−2内では複数のセンサ/通信モジュール1460−2〜3が内蔵されている。しかし上述した方法を用いれば、エンドユーザが特定のセンサ/通信モジュール1460−2〜5を別の機器1450に付け直す事が容易となる。
所で図8Bに示した本実施形態システムでは、センサ/通信モジュール1460−5が機器1450内に内蔵されない代わりに特定セクション1142内(あるいはドメイン1122内)の任意の場所に単独で設置されている。このようなセンサ/通信モジュール1460−5(あるいは複合モジュール1295、1460、1470)単独での設置方法として、例えばユーザがテープや接着剤または画鋲等の固定部材を用いてセンサ/通信モジュール1460(あるいは複合モジュール1295、1460、1470)を壁や屋根や床に固定しても良いし、塗料に混ぜて壁や屋根や床に塗り込んでも良い。更に図示して無いが、(例えばエアコンやテレビ、照明設備を制御するリモコンなどの形態として)駆動/通信モジュール1470が特定セクション1142内(あるいはドメイン1122内)の任意の場所に単独で設置されても良い。
また本実施形態システムの他の実施例として複合モジュール1295、1460、1470をユーザと共に移動可能とし、その複合モジュール1295、1460、1470の位置変化履歴を計測してユーザの行動履歴情報を収集しても良い。更に(図示して無いが)駆動/通信モジュール1470をユーザと共に移動可能とし、特定セクション1142内(あるいはドメイン1122内)の任意なユーザが居る場所から(例えばエアコンやテレビ、照明設備を制御するなどの)上記セクション1142内での状態変化(例えば空調や明るさの変化)の制御を行っても良い。ここでユーザと共に複合モジュール1295、1460、1470を移動可能にする方法として、例えばメガネ、タイピン、靴、財布などのユーザが常日頃から身に着ける携帯品にテープや接着剤で一時的に固定あるいは付着させる。あるいはネジなどで強固に固定しても良く、また携帯品内部に組み込んでも良い。
第2章 通信情報の階層構造とデータ構造の概要
第1章では図1〜図9を用いて、本実施形態システム全体の構造説明を行った。本第2章では、第1章で説明した本実施形態内で互いに通信される通信情報のデータ構造(通信プロトコル内容)の特徴と詳細内容に関する説明を行う。
2.1節 本実施形態におけるネットワーク通信関連機能の階層構造
本実施形態で利用されるネットワーク通信に関しては、図10A/B及び図16〜図17Bに示すように機能毎の階層構造を持つ所に大きな特徴が有る。この階層構造の中で図10A/B及び図16図〜17Bに示した最下層の物理的な機能に対応する物理層PHY02、PHY06で、ネットワーク通信に必要な物理的な通信媒体(communication media)に関する規定を行う。この物理的な通信媒体の具体例として有線(cabled or wired)のイーサーネット(Ethernet)を利用する場合は、上記物理層PHY06の標準規格で規定された形状や特性を持ったケーブルとコネクタを使用する。一方この物理的な通信媒体として無線(wireless)を使用する場合には、この物理層PHY02、PHY06の標準規格で規定された周波数やチャネル、変調方式、基本通信フレーム構成などに適合させる。
この物理層PHY02、PHY06の上位に位置する通信媒体(communication media)上でのアクセス機能に対応するメディア・アクセス層MAC02、MAC06では、ネットワークに接続されたノード(図8Aの機器1250あるいは図8Bの複合モジュール1460、1470)との間で通信情報を正しく伝達するために必要な情報を規定している。また最上位の拡張アプリケーション層EXL06と通信ミドルウェア層APL06、APL02では、ネットワーク通信を利用した様々なサービス提供(通信を利用した各種サービス提供機能に対応)を規定する。
このように機能毎に対応する階層構造を持たせる事で通信相手の特性や性能に応じて、階層毎に最適なフォーマットの選択/組み合わせが可能となる。その結果、本実施形態システム全体として(図8Bに示す複合モジュール1460、1470の)低価格化と同時に(図8Aに示す機器1250との間の)通信情報の高機能化を達成できる効果が生まれる。この効果の具体例を以下に説明する。まず物理層PHY02とメディア・アクセス層MAC02では、複合モジュール1460、1470に要求される“省電力化”に最適な近距離無線対応のZ−フォーマット(詳細は2.3節で後述)を採用できる。更に複合モジュール1460、1470に要求される“低価格化”に最適化させるため、通信ミドルウェア層APL02に“通信情報が簡素化”されたC−フォーマット(詳細は2.5節で後述)を採用しても良い。一方サーバn_1116−nや機器1250−1との間で要求される通信の高機能化に適合させるため、通信ミドルウェア層APL06に同時に複数情報の通信が可能なA−フォーマット(詳細は2.7節で後述)やE−フォーマット(詳細は2.6節で後述)あるいはW−フォーマットを使用し、更に拡張アプリケーション層EXL06の通信情報も利用しても良い。
また上記の階層構造を持つ通信情報の中間階層(メディア・アクセス層MAC02、MAC06よりも上位の階層で、通信ミドルウェア層APL02、APL06よりも下位の階層)としてインターネット通信(internet protocol)機能に対応するインターネット・プロトコル・バージョン6層IPv6で規定された情報を“共通”に通信可能な所に、本実施形態の次の特徴が有る。ここで“共通に通信可能”とは、図1から図8Bに示す全ての本実施形態システム内でネットワークに接続された全てのノード(ネットワーク通信の通信元と通信先に対応した通信対象物を意味し、本実施形態での具体例としては図8Aの機器1250、サーバn_1116−n、卸売業者A_1102あるいは図8Bの複合モジュール1460、1470などが対応する)に対する通信時に共通的にインターネット・プロトコル・バージョン6層IPv6で規定された通信情報(詳細は2.4節で後述)を通信しても良い事を意味する。この状況を別の方法で説明すると、以下のようになる。すなわち図10Aに示すように、後述するシステム外ネットワーク回線1788と同一システム内ネットワーク回線1782(詳細内容は後述)で使用する(送信する)通信情報内には、共通して同一のインターネット・プロトコル・バージョン6層IPv6に対応した標準規格で規定される情報を含んでも良い。ここで前記インターネット・プロトコル・バージョン6層IPv6ではインターネット上の通信プロトコルを規定し、インターネット上でのアドレス管理と通信ルート管理を行う。従ってこのインターネット・プロトコル・バージョン6層IPv6で規定された標準規格では、卸売業者A_1102やサーバn_1116−n、システムコントローラα_1126、機器1250−1、複合モジュール1460、1470などのノードの種類に拠らず、あらゆるノード(通信対象物)に対してそれぞれ独自のIPアドレス(Internet Protocol Addresses)設定が可能となっている。このように本実施形態システムにおける同一ドメイン2_1122−2内の異なるシステム間の通信時(図1におけるシステムα_1132とシステムβ_1134との間の通信時)に、上記IPアドレスを利用する事で通信相手の管理が大幅に簡素化される効果が生まれる(詳細は2.8節内で後述)。その効果の具体例として例えば、海外の出張先(図1のシステムβ_1134の所在場所に対応)からスマートホンやタブレットなどの携帯端末(図1のシステムコントローラβ_1128に対応)を使った自宅内(図1のシステムα_1132の所在場所に対応)のセンサ/通信モジュール1460からの必要な情報収集、あるいは駆動/通信モジュール1470の操作が可能となり、ユーザの利便性が大幅に向上する。またこの時は、出張先(システムβ_1134)と自宅内(システムα_1132)が他の外部からの侵入が不可能な同一ドメイン2_1122−2内で守られているため、充分強固なセキュリティ保護がなされている。
まず始めに図8Bに示した実施形態システムモデルを使い、ネットワーク通信に関連した機能毎の階層構造(アーキテクチャ)を図10Aに示す。所で図10Aや図10Bでは図8Bに示した実施形態システムモデルを意識したため、右端のネットワーク・ノードとして複合モジュール1460、1470を記載した。更に同一システム内ネットワーク回線1782内に配置された右端のネットワーク・ノードとして複合モジュール1460、1470の代わりに、図8A内で記載したデバイスコントローラ1240−1を内蔵しない機器1250−2、3内の通信モジュール1202−5、6(とセンサモジュール1260−3〜5)を対応させても良い。
ここで図10Aの左側は、図8Bのサーバn_1116−nとシステムコントローラα_1126間での通信に関連した機能毎の階層構造(アーキテクチャ)を示す。また図10Aの右側は、図8Bのシステムコントローラα_1126と各複合モジュール1460、1470との間での通信に関連した機能毎の階層構造(アーキテクチャ)を示す。
所で図1が示すように本実施形態システムでは、システムコントローラα_1126が所属するシステムα_1132が存在する領域の物理的に外側の場所にサーバn_1116−nの設置が可能となっている。従って図10Aの左側が示すようにサーバn_1116−nとシステムコントローラα_1126間での通信は、システム外ネットワーク回線1788を利用する。そしてこのシステム外ネットワーク回線1788では、有線(cabled or wired)または無線(wireless)を経由したインターネット回線を使用しても良い。しかしそれに限らず、LAN(Local Area Network)などのような相対的に狭い範囲内で使用されるネットワーク回線の使用も可能となっている。
そして上記の有線を利用した物理的な通信メディア(communication media)として、光ケーブル(fiberoptic cables)を使っても良い。しかしそれに限らず上記有線に対応した物理的な他のメディアとして、電線(electric cords)や電話回線(telephone wires)あるいは電力配線(power lines)などの信号電送手段のいずれを使用しても良い。また上記伝送される信号形態として、アナログ信号とデジタル信号のどちらを使用しても良い。このような通信媒体の物理形態やその中に送信される信号形態の違いだけでなく、通信回線管理会社や通信を管理/監督する国や地域に拠っても物理層PHY06での通信規格が異なる。従って本実施形態システムでは、実在する線(line)を経由した物理層PHY06でのあらゆる通信規格を総称して“L−フォーマット”と呼ぶ。一方システム外ネットワーク回線1788として物理層PHY06で無線を利用した場合、遠距離無線方式の2G(Second Generation)や3G(Third Generation)、あるいはWiMAX(World Wide Interoperability for Microwave Access)の通信規格を利用しても良い。更にそれに限らず、本実施形態システムでは中距離無線方式まで含めたあらゆる無線通信規格に準拠した通信情報を使用できる。そしてこれら遠距離無線方式から中距離無線方式まで含めたあらゆる無線通信規格を総称して、ここでは“G−フォーマット”と呼ぶ。
それに比較すると図8Bに示す全ての複合モジュール1460、1470は、システムコントローラα_1126が管理するシステムα_1132内に共通に配置されている。そしてこのシステムα_1132の物理的な形成範囲は、比較的狭い領域内に限定されている。従って図10Aの同一システム内ネットワーク回線1782を利用して、前記のシステムコントローラα_1126と複合モジュール1460、1470との間の情報通信が行われる。そして前述したシステム外ネットワーク回線1788で使われる“G−フォーマット”や“L−フォーマット”の通信規格と区別するため、同一システム内ネットワーク回線1782内で通信される情報の物理層PHY02で利用される通信規格を総称して“Z−フォーマット”と呼ぶ。本実施形態システムでは、上記同一システム内ネットワーク回線1782として無線と有線のいずれ(あるいはその混在)を使用しても良い。
一方図10Aに示したメディア・アクセス層MAC02/06で使用される規格は、物理層PHY02/06と共に同一の規格策定団体で検討/提案される場合が多い。従ってサーバn_1116−2とシステムコントローラα_1126間のシステム外ネットワーク回線1788上で伝送されるメディア・アクセス層MAC06内では、物理層PHY06に合わせて“L−フォーマット”または“G−フォーマット”が使用できる。そして同様にシステムコントローラα_1126と複合モジュール1460、1470との間の同一システム内ネットワーク回線1782上で伝送されるメディア・アクセス層MAC02内で、“Z−フォーマット”が使用できる。しかしそれに限らず、例えば物理層PHY02にZ−フォーマットを使用し、メディア・アクセス層MAC02にL−フォーマットやG−フォーマットを使用しても良い。またそれ以外として物理層PHY06にL−フォーマットやG−フォーマットを使用し、メディア・アクセス層MAC06にZ−フォーマットを使用しても良い。
所で上述した物理層PHY06からインターネット・プロトコル・バージョン6層IPv6までの各機能に関係する情報の処理(主に通信制御処理)は、サーバn_1116−nとシステムコントローラα_1126内では通信モジュール1768、1202−3が実行する。所で図5と図66で内部構造を説明した複合モジュール1460、1470内の通信モジュール1660の中は、共通して少なくとも機能的には通信制御部1700とインターフェース部1710に機能分けしても良い。そしてこの通信制御部1700の中で、物理層PHY02からインターネット・プロトコル・バージョン6層IPv6までの各機能に関係する情報の処理(主に通信制御処理)が行われる。
今までの物理層PHY06からインターネット・プロトコル・バージョン6層IPv6までの各機能に関係する情報は主に通信制御に関係し、例えば機器1450の機能、動作や性能とは関係が薄かった。それに対して図10Aの通信ミドルウェア層APL02、APL06と拡張アプリケーション層EXL06は、ネットワーク通信を利用した多様なサービス提供機能に関係する。そして通信ミドルウェア層APL06と拡張アプリケーション層EXL06の機能に関係する通信情報の処理(主にユーザに対するサービス提供に関連した処理)は、サーバn_1116−nとシステムコントローラα_1126内ではプロセッサ1738、1230が実行する。それに対して同一システム内ネットワーク回線1782を介して通信される通信ミドルウェア層APL02の機能に関連した情報は、複合モジュール1460、1470内では、通信モジュール1660内のインターフェース部1710の中で処理される。このように複合モジュール1460、1470では高価なプロセッサを使わず、同一システム内ネットワーク回線1782を介して通信される全ての通信情報を上記通信モジュール1660内で処理可能な所に本実施形態システムの特徴が有る。このように高価なプロセッサの内蔵を不要とする事で、複合モジュール1460、1470を安価に提供できる効果が生まれる。
所でシステム外ネットワーク回線1788を介して通信する情報の中で、特にサーバn_1116−nとシステムコントローラα_1126の両方にインストールされる特定のアプリケーションソフトウェア上でのみ使用可能な独自情報を拡張アプリケーション層EXL06内に格納して通信出来る所に本実施形態システムの大きな特徴が有る。それによりサーバn_1116−nとシステムコントローラα_1126の両方にインストールされるアプリケーションソフトウェア間での差別化が可能となる。そしてその結果として競争原理に基付く各社のアプリケーションソフトウェア間で切磋琢磨した開発が促進されてアプリケーションソフトウェア技術の進歩を促進できると共に、ユーザの利便性も向上する効果が生まれる。また更に拡張アプリケーション層EXL06内に格納する独自情報を利用する事で、アプリケーションソフトウェアがユーザに対して提供するサービスの質が向上する効果も有る。所で図8Aや図9に示す機器1250−1、2が所有する性能や追加拡張機能が将来的に向上/発展すると、それに合わせて通信ミドルウェア層APL06で使用するA−やE−、W−フォーマットの標準規格を逐次バージョンアップする必用が出る。しかし標準規格のバージョンアップには非常に煩雑な作業が必用となるため、この規格バージョンアップが機器1250−1、2の性能向上や機能の追加拡張に追従し辛いと言う問題が生じる。それに対してアプリケーションソフトウェアのベンダーが上記拡張アプリケーション層EXL06を活用する事で、規格バージョンアップを待たずに機器1250−1、2の性能向上や機能の追加拡張に容易に対応できる効果も有る。このように拡張アプリケーション層EXL06内に格納して通信する情報は特定のソフトベンダに拠り自由に設定できるため、ここでの通信情報の記述形式は世界標準として予め規定する必用が無い。
それに比べて通信ミドルウェア層APL02/APL06のサービス提供機能に関係する通信情報は、例えばA−やE−、W−、C−フォーマットなどの規定化されたフォーマットに則った情報を使用しても良い。このように通信ミドルウェア層APL02/APL06のサービス提供機能に関係する通信情報が所定の標準フォーマットに準拠する場合、サーバ1116間とシステムコントローラ1126/1128間、及び複合モジュール1460、1470間の相互互換性が取り易くなる効果が生まれる。
図2が示したようにサーバn_1116−nとシステムコントローラα_1126は共に大容量のメモリ部1232(とデータベース1118−n)を持ち、高速で強力なプロセッサ1738/1230を持てる。従って両者間で送信される通信ミドルウェア層APL06内に、多様なサービス提供に対応した多彩で多量な通信情報を設定できる。それに比べて複合モジュール1460、1470内では、多様なサービス提供に対応できるプロセッサの内蔵は難しい。従って上記状況に対応して本実施形態システムでは、複合モジュール1460、1470との情報通信には通信ミドルウェア層APL06内で使用するフォーマット(A−フォーマットやE−フォーマット、W−フォーマットなど)とは異なるフォーマット(C−フォーマットなど)を通信ミドルウェア層APL02内で使用しても良い。特に通信ミドルウェア層APL02内で使用するC−フォーマット(詳細は2.5節で後述)を相対的に簡素化する事で、複合モジュール1460、1470内での処理の負担を軽減させて低価格化を可能にするばかりで無く、相対的な処理速度の向上と処理時間の短縮を図る事で内蔵された蓄電モジュール(電池)1554の消費量を低減できる効果が生まれる。しかし本実施形態システムではそれに限らず、複合モジュール1460、1470との情報通信にA−フォーマットやE−フォーマット、あるいはW−フォーマットなどを使用しても良い。
ここで同一システム内ネットワーク回線1782を用いた通信情報に含まれる通信ミドルウェア層APL02内で使用される情報とシステム外ネットワーク回線1788を用いた通信情報に含まれる通信ミドルウェア層APL06内で使用される情報との間の切り替え(変換)処理は、システムコントローラα_1126内で処理される。所で本実施形態システムの通信ミドルウェア層APL02、APL06内において、同一システム内ネットワーク回線1782内で使用される通信情報とシステム外ネットワーク回線1788内で使用される通信情報は必ずしも完全に一致する必要は無く、両者の通信情報間で一部異なっても良い。この処理方法に付いて、以下に説明する。既に1.1節内と1.7節内で説明し、更に図8Bが示すように、ネットワークシステムα_1132内のネットワーク通信の管理と運営はシステムコントローラα_1126が行っている。そして同一システム内ネットワーク回線1782を通じて逐次リアルタイムで入手される全てのセンサ/通信モジュール1460で検出された情報と駆動/通信モジュール1470で制御(設定)された全ての状態の情報は、管理情報1744としてシステムコントローラα_1126内のメモリ部1232内に適宜保存される。ここで上記の管理情報1744は、管理テーブルとしてテーブル形式で保存されても良い。更に図8Aと図8Bが混在した形態を取る場合には、上記システムコントローラα_1126は同時に全ての機器1250の情報(検出情報や現状の状態情報など)も上記管理情報1744の一部として保存される。そしてこのシステムコントローラα_1126は、上記管理情報1744の中でユーザの個人情報が保護された範囲の特定情報のみを抜粋して、システム内ネットワーク回線1788を経由してサーバn_1116−nに情報通信する。そしてサーバn_1116−nに通信された情報は、サーバn_1116が管理する管理情報1748(テーブル形式の情報にしても良い)としてデータベース1118−n内に保存される。このようにシステムコントローラα_1126が通信ミドルウェア層APL02内で使用される通信情報とAPL06内で使用される通信情報間の変換(情報の切り替え)を行う事で、ユーザのセキュリティが保護されるだけで無く、最低限必要な情報を事前に選別されて受け取る事でサーバn_1116−nの処理も簡素化される効果が生まれる。
以上で説明した内容と、1.1節で既に説明した本実施形態システム全体概説内容を組み合わせたクライアントシステムとして、下記の特徴が生じる。すなわち
外部のクラウド(図1のサーバn_1116−n)と接続可能であって、情報を管理するシステムコントローラα_1126と、このシステムコントローラα_1126に提供する情報を取得もしくは作成して送信する機能を有するユニット(図2のユニット1_1290−1〜7_1290−7)とを備え、
このシステムコントローラα_1126は、複数存在する複数のユニットを管理対象であるセクション(図1のセクション1_1142−1〜m_1142−m)に区分し、各ユニットが属する該セクションに関する情報を保持する電子機器システムであって、
前記システムコントローラと前記複数のユニット(の一種である複合モジュール1295、1460、1470)との間の通信は、第1のデータフォーマット(図10AのC−フォーマットまたはZ−フォーマットが対応)を用いるとともに、前記システムコントローラα_1126と前記クラウド(図10Aのサーバn_1116−n)との間の通信は、第2のデータフォーマット(A/E/W−フォーマットまたはL/Gフォーマットが対応)を用いる。特に前記第1のデータフォーマットと前記第2のデータフォーマットとは異なるデータフォーマットとなる。
そして2.2節で後述するように、前記第1のデータフォーマットは、ヘッダ(図11の物理層ヘッダPHYHDが対応)と、第1のデータ(図11のMAC層ヘッダMACHDからTCPヘッダTCPHDまでのデータ)と、前記第1のデータに加えて、第2のデータ(通信ミドルウェアデータAPLDT)とからなる。
また上記のシステムコントローラα_1126を挟んで上記の特徴を持った通信情報の通信処理を実行する場合には、下記の特徴が有る。すなわち前記システムコントローラα_1126は前記ユニット(の一種である複合モジュール1295、1460、1470)から得られた通信情報を前記第2のデータフォーマット(図10AのA/E/W−フォーマットまたはL/Gフォーマット)に変換して前記クラウド(サーバn_1116−n)に送信するとともに、前記クラウド(サーバn_1116−n)から通信された情報を前記第1のデータフォーマット(C−フォーマットまたはZ−フォーマット)に変更して前記ユニットユニット(の一種である複合モジュール1295、1460、1470)に送信する。
ここで前記ユニットは前記システムコントローラに提供する情報を送信する機能(図4Aに示した通信モジュール1660が担う)と、前記情報として外部環境情報『例えば、温度,照度等』を検出する機能(図4Bのセンサモジュール1260が担う)、若しくは前記送信する情報の基となる前記ユニット自体の状態を変化させる状態変化機能(図4Cの駆動モジュール1670が担う)とを備える。従って前記ユニットは、前記通信する機能の一環として前記第1のデータフォーマットの情報を取得若しくは作成する。
所で説明の便宜を考慮して図4A〜図4Cでは通信モジュール1660とセンサモジュール1260、駆動モジュール1670間は分離して記載した。しかしそれに限らず本実施形態では、互いに兼用あるいは一部の機能が重複しても良い。そのバイには、前記ユニット内においては、前記検出する機能若しくは前記状態変化機能と前記通信する機能が兼用する事になる。
また上記通信モジュール1660内で図7Aの構造を取った場合、図7Aで記載したプロセッサ1960を使わずに全て機能回路の組み合わせで通信モジュール1660の機能を実現しても良い。この場合には、前記ユニット内で前記情報を処理するCPU(Central Processing Unit)を持たないことになる。
次に同じ通信ミドルウェア層APL02、APL06内において、同一システム内ネットワーク回線1782内とシステム外ネットワーク回線1788内で使用(送信)される各通信情報間の特徴比較の説明に関して図10Bを用いて行う。システム外ネットワーク回路1788を経由してシステムコントローラα_1126とサーバn_1116−n間での通信に、A−フォーマットまたはE−フォーマットに準拠した通信情報を使用しても良い。所で本実施形態システムにおいてA−フォーマットには、『通信ミドルウェア層APLに関係する通信情報として、広義のテキスト形式で記述』されるあらゆるフォーマットが含まれる。一方2.6節で後述するようにE−フォーマットには、通信ミドルウェアデータAPLDTの領域(2.2節参照)内の『予め規定された所定領域内に設定コードを格納』する形式を利用したあらゆるフォーマットが含まれる。特に前記A−フォーマットやEフォーマットでは、“複数内容の情報(information including plural items)を一度に通信(送信)可能”な特徴が有る。所でこの情報通信に利用するシステム外ネットワーク回路1788は、他のユーザの使用状況により一時的にネットワーク回線が混雑するリスクが有る。従ってシステムコントローラα_1126とサーバn_1116−n間で非常に頻繁に通信を繰り返す方式を採用すると、ネットワーク回線が異常に混雑する時期だけ両社間の通信が停滞する危険性を持つ。それに比べて本実施形態に示すように複数内容の情報を一度に通信可能なフォーマットを採用する事で、両者間の通信頻度を減らして通信停滞のリスクを減らせる効果が有る。しかし本実施形態システムではそれに限らず、システムコントローラα_1126とサーバn_1116−n間での通信にC−フォーマットやW−フォーマットに準拠した通信情報を使用しても良い。
上記のA−フォーマットまたはE−フォーマットでは、システムコントローラα_1126とサーバn_1116−n間で通信される交換情報1810の種別に応じて予め定められたテンプレート形式の複数のテーブルが規定されている。そしてテンプレートとして予め設定されたどのタイプのテーブルを採用するか?を示す情報が、交換情報の種別識別情報1840として前記交換情報1810内に含まれる。このように通信される交換情報(テーブル)1810をシステムコントローラα_1126とサーバn_1116−n間で共有化する事で、両社間での情報処理の効率化を図っている。すなわち上記交換情報(テーブル)1810の処理ルーチンを含むアプリケーションソフトウェアをシステムコントローラα_1126とサーバn_1116−nの両方にインストールする事で、ユーザに対する高度なサービス提供が可能となる。
一方受信相手に通知する交換情報(テーブル)1810の使用目的を示す情報は、交信アクセス制御情報1830として上記交換情報(テーブル)1810内に含まれる。例えばE−フォーマットにおける上記交信アクセス制御情報1830として、受信相手に対する“書き込み要求”、“読み出し要求”、“通知要求”、“書き込み・読み出し要求”や、“書き込み応答”、“通知”、“読み出し応答”、“通知応答”、“書き込み・読み出し応答”などに対応したコードがそれぞれ設定されている。またA−フォーマットにおける上記交信アクセス制御情報1830では、(受信相手への状態設定指示または送信元状態の受信相手への通知を意味する)“記録専用(WRITEONLY)”や(受信相手の現状の状態に関する回答要求を意味する)“再生専用(READONLY)”、あるいは“記録・再生(READWRITE)”などを交換情報(テーブル)1810内にXML(Extensible Markup Language)形式で記述可能になっている。
図10Bでは図示して無いが、システム外ネットワーク回線1788を経由して情報通信する他の方法として、World Wide Web を利用しても良い。この方法が図10AのW−フォーマットに対応し、サーバn_1116−nあるいはシステムコントローラα_1126がWebサーバの機能も持つ。この場合には通信情報の送信側(サーバn_1116−nあるいはシステムコントローラα_1126のいずれか)がURL(Uniform Resource Location)に拠り受信相手(サーバn_1116−nかシステムコントローラα_1126の反対側)を指定し、ホームページ内のフォーム形式(Form)で指定された書き込み欄内に自動的に通信情報を書き込む。そして情報通信が完了すると、受信側がPHP(Hypertext Preprocessor を再帰的に略した用語)やJavaアプレットで事前に設定したプログラムに従って受信情報(あるいはその処理結果)を管理情報1744または1748に保存する。ここで同一ホームページ内にフォーム形式で指定された書き込み欄を複数設ける事で“複数内容の情報を一度に通信(送信)可能”な状況の設定が可能となり、W−フォーマットでも上述した効果を発揮できる。従って本実施形態システムにおけるW−フォーマットには、『受信側が予め指定した書き込み欄に、送信側が記入して情報通信』を行うあらゆるフォーマットが含まれる。またそれに限らず、『HTMLもしくはHTML5に固有な“タグ”が記載』されたあらゆるフォーマットもW−フォーマットとして分類しても良い。
上述したようにシステム外ネットワーク回線1788を経由したサーバn_1116−nとシステムコントローラα_1126間の情報通信では、通信頻度を減らす工夫がなされている。それに比べて同一システム内ネットワーク回線1782ではネットワークシステム内での通信回線の管理と運営をシステムコントローラα_1126が行うため、ネットワーク回線が混雑して通信が停滞するリスクは生じない。それよりも複合モジュール1460、1470の低価格化と小形化に適合させるため、前記複合モジュール1460、1470に対する通信ミドルウェア層APL02における通信情報の簡素化が図られている。具体例として、図10Bに示すケース1〜ケース3のいずれかの情報通信を行う事が出来る。このケース1では、例えばシステムコントローラα_1126から駆動/通信モジュールに対する設定状態変更(状態制御)の指令(コマンド発行)1852を行い、その指令1852の実行結果を駆動/通信モジュールから回答する。一方ケース2ではセンサ/通信モジュール1460によるセンス情報(検出情報)の収集を目的として、システムコントローラα_1126から回答要求(リクエスト)1872を発行し、その応答(レスポンス)1874としてセンサ/通信モジュール1460がセンス情報(検出情報)を回答する。またセンサ/通信モジュール1460が任意のタイミング(あるいは事前に設定された定期的なタイミング)でセンス情報(検出情報)をシステムコントローラα_1126に通知する場合には、ケース3のように定期的/非定期的報告1894を行っても良い。
なお本実施形態システムでは情報通信方法として上記に限らず、他の通信方法を使用しても良い。例えば図8Aに示すようにシステムα_1132内にデバイスコントローラ1240−1とメモリ部1242を内蔵する機器1250−1が設置された場合、この機器1250−1とシステムコントローラα_1126間での同一システム内ネットワーク回線1782上での情報通信には、図16が示すようにA−フォーマットまたはE−フォーマット、W−フォーマットに準拠した通信ミドルウェア層APL06や拡張アプリケーション層EXL06を利用しても良い。この場合の実施形態例としては、上記拡張アプリケーション層EXL06を活用できるアプリケーションソフトウェアをサーバn_1116−n内に事前にインストールしても良い。そして(図8Aに記載された)ユーザI/F部1234を介してユーザの許諾を得た後、システムコントローラα_1126が自動的に上記アプリケーションソフトウェアをシステムコントローラα_1126自身と対応する機器1250の両方に自動的にインストール処理を行っても良い。この時にはシステムコントローラα_1126がサーバn_1116−nにアクセスし、データベース1118−n内に予め保存されたアプリケーションソフトウェアの転送を行う。このようにシステムコントローラα_1126を中継してシステム外ネットワーク回路1788と同一システム内ネットワーク回路1782が接続されて対応機器1250までアプリケーションソフトウェアの自動インストールを可能にすることで、ユーザへの負担を掛けずに上記拡張アプリケーション層EXL06が活用可能な環境が自動構築出来るため、新規に機能拡張された最新機器1250のネットワークシステム内での対応容易性と柔軟性を確保できる効果が生まれる。所で本実施形態システムでは上記に限らず、例えば図16に示すシステムコントローラα_1126と機器1250間の通信ミドルウェア層APL06での情報通信に、C−フォーマットに準拠した通信情報を使用しても良い。
なお図9に示すようにルータ(ゲートウェイ)1300を経由して機器1250−1、4とサーバn_1116−nが直接接続されている場合には、図16でのシステムコントローラα_1126に代わってルータ(ゲートウェイ)1300が機器1250とサーバn_1116−nの間に配置される。この場合の拡張アプリケーション層EXL06と通信ミドルウェア層APL06では、システム外ネットワーク回路1788内と同一システム内ネットワーク回路1782内共に同一の通信情報が利用される。更にこの場合には機器1250とサーバn_1116−nそれぞれに独自のIPアドレスが設定されているため、インターネット・プロトコル・バージョン6層内に設定された送信側IPアドレス情報SIPADRSと受信側IPアドレス情報DIPADRS(詳細は図13を用いて2.4節内で後述)を利用して機器1250とサーバn_1116−n間で直接情報通信が行える。またこの場合の機器1250とサーバn_1116−n間の通信ミドルウェア層APL06での情報通信には、主にE−フォーマットまたはA−フォーマットに準拠した通信情報を使用する。しかし本実施形態システムではそれに限らず、C−フォーマットやW−フォーマットを使用しても良い。このようにシステム外ネットワーク回路1788内と同一システム内ネットワーク回路1782内共に同一の通信情報が利用される事で、ルータ(ゲートウェイ)1300の中継処理の負担を大幅に低減できる効果が有る。但し物理層PHY02、PHY06とメディア・アクセス層MAC02、MAC06では異なるフォーマットを使用(図16の例では、同一システム内のネットワーク回線1782ではZ−フォーマットを使用し、システム外ネットワーク回線1788ではL−フォーマットまたはG−フォーマットを使用)しても良い。そしてこの場合には、ルータ(ゲートウェイ)1300内でフォーマット変換がなされる。
一方図1に示すように、同一ドメイン2_1122−2内に所属するが異なるシステムα_1132とβ_1134に属するシステムコントローラα_1126とβ_1128間で情報通信する場合には、図10Aの左側に示したシステムコントローラα_1126とサーバn_1116−n間と同様な通信方法を使用しても良い。この場合には、物理層PHY06から拡張アプリケーション層EXL06に至る全てのレイヤーでシステム外ネットワーク回線1688上と同じ通信情報を使用しても良い。この場合には上述内容と同様に、システムコントローラβ_1128に対してもアプリケーションソフトウェアの自動インストールを行っても良い。従ってこの場合の通信ミドルウェア層APL06での情報通信には、主にE−フォーマットまたはA−フォーマットに準拠した通信情報を使用する。しかし本実施形態システムではそれに限らず、C−フォーマットやW−フォーマットを使用しても良い。そしてこの場合の物理層PHY06とメディア・アクセス層MAC06で使用するフォーマットは、
○システムα_1132とβ_1134間の距離が離れている場合にはL−フォーマットやG−フォーマットを使用し、
○システムα_1132とβ_1134間の距離が近付いた場合にはZ−フォーマットを使用しても良い。ここでL−フォーマットやG−フォーマットでは世界中の至る所での情報通信が可能な反面、相対的に通信時間が掛かり、Z−フォーマットでは通信範囲が限定される代わりに相対的な通信時間が短い特徴が有る。従って両者間の距離に応じて使用するフォーマットを切り替える事で、適宜両フォーマット間の利点を使える効果が生まれる。
また本実施形態システムの応用例として図1と図8Bが混在する場合を考える。この場合には異なるシステムβ_1134内のシステムコントローラβ_1128(図1)からシステムα_1132内の複合モジュール1460、1470に直接アクセスしても良い。この場合の通信方法は、図10Aのサーバn_1116−nの代わりに図1に示したシステムコントローラβ_1128を配置し、図10Aのシステム外ネットワーク回線の代わりに同一ドメイン内ネットワーク回線に書き換えた形になる。従ってこの場合には、同一ドメイン内ネットワーク回線2082内の通信情報としてL−フォーマットやG−フォーマットあるいはA−フォーマットやE−フォーマット、Wフォーマットを使用しても良い。更に本実施形態システムではこれに限らず、例えばZ−フォーマットやC−フォーマットを使用しても良い。また上記と同様に、(システムα_1132内の)複合モジュールと上記システムコントローラβ_1128間の距離に応じてZ−フォーマットとL/G−フォーマット間で自動的にフォーマットの切り替えを行っても良い。所でこの場合のインターネット・プロトコル・バージョン6層IPv6を利用した詳細方法に付いては2.8節で詳細に後述する。
2.2節 通信関連機能の階層構造とネットワーク回線上の通信情報との関係
図10A及び図16〜図17Bに示した機能別階層構造と、実際のネットワーク回線内で通信される具体的な通信情報内容との関係を図11に示す。ネットワーク通信媒体(network communication media)が有線と無線のいずれの場合でも、これらの物理的な通信媒体上で1つの塊を単位として通信情報が間欠的に送信される。そしてこの塊が、図11(f)の物理層フレームPPDUに相当する。ここでシングルチャネル(シングルコレスポンダ)の場合には、上記ネットワーク通信媒体上で上記塊(物理層フレームPPDU)の送信時には他の通信情報の通信が出来ない。従って上記塊(物理層フレームPPDU)のサイズが大き過ぎると、上記ネットワーク通信媒体の占有時間が長くなり、他の通信を阻害する危険が有る。上記問題を解決するために本実施形態システムでは、1個の物理層フレームPPDUのデータサイズを127バイト以下に設定している。それによりネットワークシステム内での1個の物理層フレームPPDU通信による他の情報通信を阻害する弊害を軽減させる効果が有る。またこの1個の物理層フレームPPDU内は図11(a)が示すように、送信側から受信側へ向けた送信順(前からの順番あるいは情報を送り出すタイミングが早い順)に物理層ヘッダPHYHD、MAC層ヘッダMACHD、IPv6ヘッダIPv6HD、TCPヘッダTCPHD、通信ミドルウェアデータAPLDT、拡張データEXDT、誤チェックCRCの順番で構成される。一方このデータ配置を図11(f)の視点から見ると、“物理層フレームPPDU内の先頭に物理層ヘッダPHYHDが配置され、その後ろに物理層データまたは物理層ペイロードPSDUが続き、そしてこの物理層データ/ペイロードPSDU内に順次MAC層ヘッダMACHD、IPv6ヘッダIPv6HD、TCPヘッダTCPHD、通信ミドルウェアデータAPLDT、拡張データEXDT、誤チェックCRCが格納される”とも言える。
所で図10Aと図16〜図17Bが示す物理層PHY02、PHY06内では、物理層フレームPPDU全体の処理を行う。ここでこの物理層PHY02、PHY06とは、“物理的な通信メディアに対処する機能”を抽象化した概念を示している。それに対して物理層PHY02、PHY06からインターネット・プロトコル・バージョン6層IPv6までの各機能に対応した実際の処理は、通信モジュール1768、1202−3や通信制御部1700(図10A)の内部で実行される。所で本2.2節では階層毎の機能とネットワーク回線上で通信される通信情報との関係を説明し易くするため、細かく階層毎の情報引き渡し手順を説明する。しかしそれに限らず階層毎の情報引き渡しを一部省略して通信情報を作成しても良い。例えば送信時に通信モジュール1768、1202−3や通信制御部1700(図10A)の内部では、通信ミドルウェア層APL02、APL06から与えられた(実体的には図10Aのプロセッサ1230、1738または通信モジュール1660内のインターフェース部から与えられた)通信ミドルウェアデータAPLDTと拡張データEXDT(あるいは通信ミドルウェアデータAPLDTのみ)から図11(a)に示す情報(データ構造)を直接作成してネットワーク回線1782、1788から発信(送信)しても良い。また受信時には通信モジュール1768、1202−3や通信制御部1700(図10A)の内部で、ネットワーク回線1782、1788から必要な物理層フレームPPDUのみを選択抽出し、通信ミドルウェアデータAPLDTと拡張データEXDT(あるいは通信ミドルウェアデータAPLDTのみ)を抜き出して通信ミドルウェア層APL02、APL06(実体的には図10Aのプロセッサ1230、1738または通信モジュール1660内のインターフェース部)へ渡しても良い。
前記物理層PHY02、PHY06が担う詳細な受信側の機能として、受信した物理層フレームPPDU内の先頭位置に配置された物理層ヘッダPHYHDの内容を識別し、その直後に配置された物理層データまたは物理層ペイロードPSDU全体をメディア・アクセス層MAC02、MAC06へ引き渡す。従ってメディア・アクセス層MAC02、MAC06から見ると、この物理層データまたは物理層ペイロードPSDU全体がMAC層フレームMPDUに相当する。一方前記物理層PHY02、PHY06が担う詳細な送信側の機能としては、メディア・アクセス層MAC02、MAC06から受け取ったMAC層フレームMPDUを物理層データまたは物理層ペイロードPSDUに格納し、物理層ヘッダPHYHDを先頭に付加して構成した物理層フレームPPDUをネットワーク回線1782、1788で送信する。
所で図11(e)が示すようにMAC層フレームMPDU内は、先頭から順にMAC層ヘッダMACHD、MAC層データ/ペイロードMSDU、そして誤チェックCRCから構成されている。そしてメディア・アクセス層MAC02、MAC06内では受信時に、物理層PHY02、PHY06から渡されたMAC層フレームMPDU内のMAC層ヘッダMACHDに格納された通信情報を利用して通信媒体上のアクセス対応制御を行う。具体的には対応する機器1250や複合モジュール1460、1470またはシステムコントローラα_1126が関係するMAC層データ/ペイロードMSDUのみを取り出し、インターネット・プロトコル・バージョン6層_IPv6へ渡す。一方送信時には、インターネット・プロトコル・バージョン6層_IPv6から渡された情報をMAC層データ/ペイロードMSDU内に格納し、MAC層ヘッダMACHDを付加したMAC層フレームMPDUを構成してMAC層フレームMPDU側に渡す。
MAC層フレームMPDU内の最後端位置に付加された誤チェックCRC(図11(e))を利用して、MAC層フレームMPDU内のデータエラー有無のチェック(あるいはデータエラー発生箇所の抽出)が可能となる。本実施形態における誤チェックCRCとして具体的には、CRC(Cyclic Redundancy Checksum)コードを使用している。これはMAC層フレームMPDU内のバイナリー表示(“1”か“0”の繋がり)したMAC層ヘッダMACHDとMAC層データ/ペイロードMSDU全体を所定コードで割り算を行った時のバイナリー表示での剰余値(余り)として算出される。そして送信時には上記の方法で算出した誤チェックCRCを、MAC層フレームMPDU内の最後端位置に付加する。また受信時には得られたMAC層ヘッダMACHDとMAC層データ/ペイロードMSDU全体を前記のコードで割り算を行った時の剰余値と受信時に得られた誤チェックCRCを比較する。両社が一致すれば“エラー無し”と見なす。もし仮に“エラー有り”の場合には、受信時に得られた誤チェックCRCから逆演算を行ってエラー箇所を抽出できる。ここでエラー訂正能力(すなわちこの誤チェックCRCを含むエラー訂正対象データ全体(ここではMAC層フレームMPDU全体)内でのエラー訂正可能領域のサイズ)は、誤チェックCRCのデータサイズで決定される。従って誤チェックCRCのデータサイズを固定した場合、この誤チェックCRCを含むエラー訂正対象データ(MAC層フレームMPDU)全体のデータサイズが小さい方が相対的なエラー訂正能力が上がるので、(エラー訂正まで考慮に入れた場合の)MAC層フレームMPDUのデータ信頼性が向上する。
上記状況も考慮して、図11(e)が示すようにMAC層フレーム内の最後端位置に誤チェックCRCを配置した所に本実施形態の特徴が有る。図12Aを用いて2.3節で説明するように、物理層ヘッダPHYHD内には比較的ロバスト性の高い情報が多く含まれている。すなわち仮に前記物理層ヘッダPHYHD内にエラービットが多少混入しても、何らかの手段で自動補正した対応が可能となる。それに対してメディア・アクセス層MAC02、MAC06以上で取り扱うMAC層フレームMPDU内の情報に要求されるデータ精度は非常に高い。従って比較的ロバスト性の高い物理層ヘッダPHYHDを外してMAC層フレーム全体に対するエラー訂正機能を付加して相対的なエラー訂正能力を向上させることで、通信情報(物理層フレームPPDU)全体の信頼性を相対的に向上させられる効果が有る。
次に図11(d)が示すように、先頭にIPv6ヘッダIPv6HDを配置し、その直後に続くIPv6データ/ペイロードIPv6DUから構成される情報がMAC層データ/ペイロードMSDU内に格納される。そしてインターネット・プロトコル・バージョン6層IPv6では送信時に、TCPヘッダTCPHDと通信ミドルウェアデータAPLDT、拡張データEXDTの組をIPv6データ/ペイロードIPv6DU内に格納し、IPv6ヘッダIPv6HDを付加してメディア・アクセス層MAC02、MAC06へ渡す。また受信時にはメディア・アクセス層MAC02、MAC06から渡されたMAC層データ/ペイロードMSDU内からIPv6ヘッダIPv6HDを抽出して独自処理を行った後、最終的には通信ミドルウェアデータAPLDTと拡張データEXDT(または通信ミドルウェアデータAPLDTのみ)を通信ミドルウェア層APL02、APL06側へ渡す。
そして図11(b)に示す通信ミドルウェアデータAPLDTと拡張データEXDT(または通信ミドルウェアデータAPLDTのみ)は、通信ミドルウェア層APL02、APL06内で処理される。ここで通信ミドルウェア層APL02、APL06が担うネットワーク通信を利用した様々なサービス提供機能に関しては、図10Aや図16〜図17Bが示すプロセッサ1230、1738、2030やデバイスコントローラ1240または通信モジュール1660内のインターフェース部が行う各種処理により実現される。
2.3節 物理層とメディア・アクセス層でのZフォーマットのデータ構造
同一システム内ネットワーク回路1782に対応した物理層PHY02やメディア・アクセス層MAC02で使用可能なZ−フォーマット(図10Aと図16参照)に基付いた、物理ヘッダPHYHDとMAC層ヘッダMACHD内の具体的なデータ構造例を図12Aに示す。所で下記に説明するZ−フォーマットはあくまで本実施形態システム内で使用される一例に過ぎず、同一システム内ネットワーク回路1782に対応した他のフォーマットを使用しても良い。また上記の物理層PHY02やメディア・アクセス層MAC02などの階層構造に限定せず、同一システム内ネットワーク回路1782上で通信される情報として階層構造を持たない情報や別の階層構造に対応した情報を利用しても良い。
始めに図12A(c)のデータ構造は、図11(a)の内容をそのまま転記した。そして図12A(b)が示すように物理層ヘッダPHYHD内は、最初の5バイトで配置された同期ヘッダSYNCと、その直後に1バイト分配置された物理層データ/ペイロードの長さ情報LPSDUから構成される。従ってこの物理層ヘッダPHYHDのデータサイズは6バイト(5+1)となる。所でこの物理層データ/ペイロードの長さ情報LPSDUとは、図11(f)の物理層データ/ペイロードPSDUのデータサイズを表し、バイト単位で設定される。既に2.2節の冒頭で説明したように、物理層フレームPPDU全体の最大データサイズを127バイトに設定している。従ってこの物理層データ/ペイロードの長さ情報LPSDU内には、121バイト(127−6)以下の値が設定される。
次に図12A(a)が示すように前記の同期ヘッダSYNCは、最初に配置される5バイトのプリアンブルPRMと次に1バイトの物理層フレーム開始情報SFDから構成される。そしてこのプリアンブルPRMとして、[00000000h](ここで“h”は16進数(hexadecimal)の値を示している)が設定される。ここで信号変調に直接スペクトラム拡散(Direct Sequence Spread Spectrum)方式を採用しているため、全て“0”の上記プリアンブルPRM部から同期信号が得られる。そして前記物理層フレーム開始情報SFDの領域内には、[A7h]が設定される。そして16進数の値で示した[A7h]を2進数表示に変換すると、“10100111”となる。
図10Aの通信モジュール1660内の通信制御部1700または通信モジュール1768、1202−3、あるいは図16〜図17Bの通信モジュール1202−4、2002内での前記物理層ヘッダPHYHD内通信情報の利用方法を説明する。主に前記物理層ヘッダPHYHD内通信情報は、受信側のチップ同期合わせとビット同期合わせに利用される。すなわち上記通信モジュールには、周波数と位相が自動的に同期可能な発振器(PLL回路:Phase Lock Loop Circuit)が内蔵されている。そしてこの発振器(PLL回路)は、上記プリアンブルPRMに合わせて周波数と位相を自動的に同期させる(チップ同期)。次に例えばパターンマッチングなどの手法により前記物理層フレーム開始情報SFDの位置を検出し、(1)物理層PHY02にZ−フォーマットを使用している事を認識すると共に、バイナリービット1/0の連続の中からMAC層ヘッダMACHDの開始ビット位置の検出(ビット同期)を行う。
図12A(d)が示すようにMAC層ヘッダMACHD内は、送信側から受信側へ向けた送信順(前からの順番あるいは情報を送り出すタイミングが早い順)に、MAC層フレームの制御情報MACNTL、MAC層のシーケンス番号MASQNM、アドレス情報MADRSのそれぞれを格納する領域から構成される。
最初のMAC層フレームの制御情報MACNTLの領域内には、MAC層フレームMPDU(図11(f))全体を制御する情報が2バイトで格納される。そしてMAC層フレームの制御情報MACNTL内の詳細情報として、最初の3ビットにMAC層フレームMPDUのタイプを示す情報が格納される。ここで具体的なタイプとしては、“ビーコン”、“データ”、“ACK(Acknowledgement)”や“コマンドのフレーム・タイプ”などの識別情報が格納される。そして次の1ビットには、セキュリティの有無情報が格納される。更に次の1ビットには、ペンディング・データの有無情報が格納され、その直後の1ビットには、前記のAcknowledgementメッセージ要求の有無情報が格納される。
そしてその次の1ビットで、該当する情報通信はPAN(Private Area Network)内部での通信に限定されるか?複数のPANをまたがった通信か?を示す情報が格納される。既に図1または図8Aを用いて説明したように本実施形態システムでは、1個のPANを1個のシステムα_1132に対応しても良いし、1個のセクション1142に対応しても良い。従ってどちらに対応させるかに応じて、上記情報の設定方法を変えても良い。しかし同一ドメイン内ネットワーク回線2082内での情報通信にZ−フォーマットを使用する場合には、この情報領域には“複数のPANをまたがった通信”に対応した情報を格納しても良い。なぜなら図1が示すように本実施形態システムでは、同一ドメイン2_1122−2内でシステムコントローラα_1126とシステムコントローラβ_1128間の距離が大きく離れる(1個のPANからはみ出す)状況を許容する。従ってこの場合には上記格納領域内には、“複数のPANをまたがった通信”に対応した情報を格納する。一方携帯可能なシステムコントローラβ_1128を移動させてシステムコントローラα_1126に近付けた場合(同一PAN内に移動させた場合)には、上記格納領域内には、“PAN内部での通信”に対応した情報を格納する。
そしてその直後の2ビットとMAC層フレームの制御情報MACNTL(2バイト)内最後の2ビットには、受信側と送信側のそれぞれのアドレス・モード情報を格納する。ここでZ−フォーマットとしてはIEEE拡張アドレスDEXADRS、SEXADRSを指定しても良いし、短縮アドレスを指定しても良い。所で本実施形態システムでは図12A(e)に示すように、上記のアドレス・モード情報として受信側と送信側共にIEEE拡張アドレスDEXADRS、SEXADRSを使用する所に特徴が有る。本実施形態システムでは図8Aに示すようにシステムコントローラα_1126や機器1250−1〜3に内蔵された通信モジュール1202−3〜6を介してネットワーク通信するだけで無く、図8Bに示すようにセンサ/通信モジュール1460−1〜5や駆動/通信モジュール1470−1、2などの複合モジュールを介してネットワーク通信が可能となっている。そのため本実施形態システムではこのアドレス・モードに前記IEEE拡張アドレスDEXADRS、SEXADRSを使用してメディア・アクセス層MAC02のレベルで通信モジュール1202−3〜4か?または複合モジュール1460−1〜5、1470−1、2か?の識別を容易にする(詳細は図12B(e)を用いて後述)事で、(1)受信側での通信ミドルウェア層APL02の高速切り替え(C−フォーマットか?それ以外のフォーマットか?)を可能とし、(2)万が一発生する送信側のエラー(通信モジュール1202−3〜4か?または複合モジュール1460−1〜5、1470−1、2か?の御認識)の発見を容易にする効果が生じる。
次に図12A(d)に記載したデータサイズが1バイトのMAC層のシーケンス番号MASQNMの情報格納領域に関する説明を行う。前述したように本実施形態システムでは、物理層フレームPPDU全体のデータサイズを127バイト以下に設定している。そのため通信ミドルウェアデータAPLDTと拡張データEXDT(図11(b)参照)を合わせたデータサイズが大きくなると、この情報の通信(送信)に1個の物理層フレームPPDUのみは足らなくなる。特に通信ミドルウェア層APL06としてA−フォーマットやE−フォーマットを使用すると、この危険性が高くなる。その対策として本実施形態システムでは、上記通信ミドルウェアデータAPLDTと拡張データEXDTを256個(2の8乗)の物理層フレームPPDUに分割して送信(通信)可能にしている。具体的には通信ミドルウェアデータAPLDTと拡張データEXDTを複数に分割してネットワーク回線上に順次送信(通信)する。またこの場合には、図11(a)に示した物理層ヘッダPHYHDとIPv6ヘッダIPv6HD(及びTCPヘッダTCP)は全て同一の情報内容となる。そしてネットワーク回線上の送信(通信)順に合わせて前記MAC層のシーケンス番号MASQNMの領域内に“0”から始まる1ずつ加算した値(インクリメントされた値)を格納する。その結果として上記通信ミドルウェアデータAPLDTと拡張データEXDTの分割送信順が確定するので、万が一ネットワークトラブルで物理層フレームPPDUの受信順が入れ替わっても安定に情報通信が可能となる効果が有る。
次の図12Bの(c)に示したデータ構造は図12A(e)と全く同じなので、図12Bを用いてMACヘッダMACHD内のアドレス情報MADRSの説明を行う。所で図1に示した本実施形態システムでは、1個のシステムα_1132を唯一のPAN(Private Area Network)で形成しても良いし、複数のPANの組み合わせで形成しても良い。またそれに限らず、同一システムα_1132内の各セクション1142−1〜mを1個以上のPANで形成しても良い。このように1個のシステムα_1132が複数のPANで構成される場合、システムコントローラα_1126は上記の複数PANの管理を行う必用が有る。そして同一システムα_1132内で異なるPANをまたがった情報通信が行われる。この状況にも対応できるように、前記システムコントローラα_1126がPAN毎にPAN固有の識別情報を割り当て、図12B(c)に示すように受信側と送信側のノードが含まれるPANに関するPAN固有の識別情報DPANID、SPANIDを格納する領域をアドレス情報MADRS格納領域内に設定している。
受信側と送信側共にIEEE拡張アドレスDEXADRS、SEXADRS内は、1バイトの拡大IEEE拡張アドレスEXEXADRSと8バイトのIEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEの各情報の格納領域から構成される。ここでこのIEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEとは、全世界のIEEE802.15.4標準規格に準拠する全ての通信モジュール1202−3〜6やセンサ/通信モジュール1460−1〜5や駆動/通信モジュール1470−1、2などの複合モジュール毎に予め割り当てられたユニークな番号を意味する。そしてこのユニークな番号は、異なる通信モジュールや複合モジュール間では世界レベルで重複しない。所でこのユニークな番号は、前記通信モジュール1202−3〜6や複合モジュールの出荷前にアサインされるが、それに限らず直接IEEEへ申請してユニークな番号を取得しても良い。そしてIEEEないしは所定の公式機関でこのユニークな番号を発行する時、上記ユニーク番号の発行機関では特に複合モジュールに関しては個々の性能や機能、及びそれに合わせたC−フォーマットで通信する時の通信情報の種類(カテゴリーや情報通信に使用するテンプレートタイプ)などの情報を入手する。従ってこのIEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEの情報から対象とする複合モジュール個々の機能や性能が分かるだけで無く、C−フォーマットを用いた通信情報の種類まで公式的に予想できるため、通信ミドルウェア層APL02での対応処理の事前準備を高速かつ簡単に行える効果が有る。
次に本実施形態システムにおける拡大IEEE拡張アドレスEXEXADRS(Expanded IEEE Extension Address)内のデータ構造例を図12B(e)に示す。この中の最初の1ビットはモジュール構造情報MSTを格納できる領域になっている。そしてこの1ビットが[0]の時はシステムコントローラα_1126内や機器1250−1〜3に内蔵された通信モジュール1202−3〜6を表す。一方このビットが[1]の時は該当するノードが複合モジュール構造になっている事を示す。更に次の1ビット領域に格納される情報は複合モジュール構造情報CMSTを意味する。そしてこのビットが[0]の時は該当するノードがセンサ/通信モジュールを示し、このビットが[1]の時は該当するノードが駆動/通信モジュールを示す。
所でセンサ/通信モジュールから送信されるセンス情報は、2値の光レベル(照明がONかOFFか)や多値の光レベル(照度に対応)から始まり、人感や温度など多種多様に亘る。また図6A〜図6Dを用いて1.5節で説明したように、駆動/通信モジュールを制御する情報もON/OFFの2値や多値、あるいは機器のリモコン制御情報など多種多様に亘っている。そのため本実施形態システムでは、ノードとして対応する上記センサ/通信モジュール1460や駆動/通信モジュール1470の種類を識別する情報が、6ビットで複合モジュール種類識別情報CMTIDとして記録できる領域を設けている。所でこの複合モジュール1460、1470毎にその種類を識別する情報CNTIDを設定する方法に対し、機器1250の種別を識別する方法としてA−フォーマットでは <table> Element 内の number 属性を利用し(図15Bを用いた2.7節内説明を参照)、E−フォーマットでは交換情報の種別識別情報EPC(図15A(f)を用いた2.6節内説明を参照)を利用している。従ってこの複合モジュール種類識別情報CMTIDを、図10B内に示した交換情報の種別識別情報1840として使用しても良い。それによりA−フォーマットやE−フォーマットと同様に、この複合モジュール種類識別情報CMTIDを利用する事でC−フォーマットに準拠した多値/2値送信データ部CTMDT、CT2DT(図14(d)を用いて2.5節内で後述)に格納されるデータの意味解釈が容易となる効果が有る。更にこのモジュール構造情報MSTと複合モジュール構造情報CMSTそして複合モジュール種類識別情報CMTIDをIEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEから予想される対象ノード機能と比較する事で、アドレス情報MADRSの読み取り精度とその信頼性が向上する効果も生まれる。すなわちこのモジュール構造情報MSTと複合モジュール構造情報CMSTそして複合モジュール種類識別情報CMTIDの格納領域に対して送信側が万が一誤って別の情報を記録した場合、あるいは受信側での再生時に誤って再生情報のビットシフト(誤再生)を起こした場合、上記の比較で誤り検知が容易に行える。(この場合には受信側から送信側に対してアラーム通知を行う。その一例として図14(d)の交信アクセス制御情報1830で[000]を設定し、多値送信データ部CTMDTと2値送信データ部CT2DTを合わせて[00011]を設定する。詳細は2.5節で後述する。)
2.4節 インターネット・プロトコル・バージョン6層のデータ構造
本2.4節では、インターネット・プロトコル・バージョン6層IPv6に対応した通信情報内のデータ構造に関して図13を用いて説明する。ここでは図13(b)が示す各16バイトで記述される送信側及び受信側のIPアドレス情報SIPADRS、DIPADRSを格納する領域を持つ所に大きな特徴が有る。このIPアドレスは、世界中の全ての通信モジュールと複合モジュール個々に別々に設定される。そして世界中の全ての通信モジュールと複合モジュール個々に設定されたIPアドレスは、互いに重複する事が無い。従って本実施形態システム内でIPv6ヘッダIPv6HD(図13(a))を含む情報の通信を可能にする事で、同一のドメイン2_1122−2(図1)内に入れれば、世界中のどこからでも特定の通信モジュールや特定の複合モジュールとの間で情報通信が可能となる効果が生まれる。
上記IPv6ヘッダIPv6HD内で図13(b)に示す最初の8バイト領域内に、IPパケット関連情報IPPKTが格納される。またその中は図13(c)のように、先頭情報SIPHD、IPv6データ/ペイロード長さ情報LIPv6DU、IPv6ヘッダの直後に続くヘッダタイプの識別情報NXHD及び通過可能ノード残数情報HPLMTのそれぞれが格納される領域から構成され、それぞれ前記の順番で配置される。このIPv6データ/ペイロード長さ情報LIPv6DUは図11(d)に示すIPv6データ/ペイロードIPv6DUのデータサイズを示し、この情報を格納する領域は2バイトのサイズを有する。
次に前記のIPv6ヘッダの直後に続くヘッダタイプの識別情報NXHDの説明を行う。図11(a)が示すように、1個の物理層フレームPPDU内で各種ヘッダが順次格納される。そして前記のIPv6ヘッダの直後に続くヘッダタイプの識別情報NXHDにより、IPv6ヘッダIPv6HDの直後に続くヘッダタイプを指定する。従って図11(a)に記載した例では、IPv6ヘッダの直後に続くヘッダタイプの識別情報NXHDとして“TCPヘッダTCPHD”が指定される。そしてこのIPv6ヘッダの直後に続くヘッダタイプの識別情報NXHDにより、通信ネットワーク上(インターネット上)の通信経路設定方法の指定が可能となる。所で本実施形態システムでは前記物理層フレームPPDU内に格納される情報内容は図11(a)に限らず、別の情報を格納しても良い。例えば他の応用例として、IPv6ヘッダIPv6HDの直後に別のタイプのヘッダ情報を配置しても良い。具体例として図13が示すTCP(Trasmission Control Protocol)の代わりにUDP(User Datagram Protocol)を使い、IPv6ヘッダIPv6HDの直後にUDPヘッダを配置しても良い。また更なる応用例として、IPv6ヘッダIPv6HDの直後に直接通信ミドルウェアデータAPLDTを配置/格納しても良い。例えばこの通信ミドルウェアデータAPLDTとしてE−フォーマットを使用する場合には、図15A(b)を用いて2.6節で後述するように、この通信ミドルウェアデータAPLDTの最初にE−フォーマットヘッダE−HDの情報が配置/格納される。従ってこの場合には、前記のIPv6ヘッダの直後に続くヘッダタイプの識別情報NXHDにより“E−フォーマットヘッダE−HD”を識別する情報が指定される。
図10Aに示すシステム外ネットワーク回線1788を使ったサーバn_1116−nとシステムコントローラα_1126間の情報通信や同一ドメイン内ネットワーク回線2082を使ったシステムコントローラα_1126とシステムコントローラβ_1128間の情報通信では、図10Aに記載したように両者間で直接情報通信される場合が少なく、多くの場合システム外ネットワーク回線1788途中や同一ドメイン内ネットワーク回線2082の途中で複数の中継点(中継ノード)を経由して情報通信される。そして送信側ノードと受信側ノード間で許容される通信回路途中での中継点(中継ノード)の最大数を、図13(c)の通過可能ノード残数情報HPLMTがゼロを含む正数値(integer)で示している。例えば上記の両者間で情報通信する場合、送信側ノード内で最初に上記通過可能ノード残数情報HPLMTの値を設定する。次にこの通信情報が通信回路途中の中継点(中継ノード)を通過する(中継される)度に、上記通過可能ノード残数情報HPLMTの値が“1”だけ減算(decrement)される(すなわち中継点(中継ノード)を1回通過すると、通過前の通過可能ノード残数情報HPLMTの値から“1”だけ差し引いた値として通過後の通過可能ノード残数情報HPLMTの値に更新される)。そして上記の通過可能ノード残数情報HPLMTの値が“0”になった時点で、ネットワーク上での情報通信が中止(discard)される。所でこの通過可能ノード残数情報HPLMTは1バイトで記述されるので、最大256個(2の8乗)までの中継点(中継ノード)の経由が可能となる。
しかしこの中継点(中継ノード)の数が増える程、送信側から受信側に到達するまでの通信所用時間(情報伝達までの所要時間)が長くなる。それに対して例えば“アラーム通知”など急を要する情報伝達では、通信時間を短くする必用が有る。所でこの中継点(中継ノード)での情報転送時間を考慮すると、中継点(中継ノード)の数は100以下、望ましくは10以下に設定する必用が有る。従って本実施形態システムにおいてシステム外ネットワーク回線1788や同一ドメイン内ネットワーク回線2082を利用した情報通信では、送信側での通過可能ノード残数情報HPLMTの設定値を100以下、望ましくは10以下に設定する所に特徴が有る。当然本実施形態システムに適用されるシステム外ネットワーク回線1788途中や同一ドメイン内ネットワーク回線2082の途中で経由する中継点(中継ノード)内で再設定(更新)される通過可能ノード残数情報HPLMTの値も100以下、望ましくは10以下となる。このように通過可能ノード残数情報HPLMTの値が小さくなると、システム外ネットワーク回線1788や同一ドメイン内ネットワーク回線2082途中の中継点(中継ノード)に配置されたルータが自動的に受信側ノードへ到達する最短経路を探し、途中での情報通信中止を防止する。上記によりサーバn_1116−nとシステムコントローラα_1126間あるいはシステムコントローラα_1126とシステムコントローラβ_1128間での通信所用時間の短縮化が図れ、“アラーム通知”など急を要する情報の迅速な通信が可能になる効果が有る。
一方本実施形態システムにおける同一システム内ネットワーク回線1782を用いた情報通信形態として、図10Aに示すシステムコントローラα_1126と複合モジュール1460、1470間の情報通信と図16に示すシステムコントローラα_1126と機器1260間の情報通信が可能となる。そして図1のように複数のセクション1142が1個のシステムを構成し、例えばセクション1142毎に異なるPAN(Personal Area Network)を使用した場合、複数のPANを跨ったネットワーク通信が必用となる。そしてこの場合、隣接する異なるPANを通信情報が越える毎に中継点(中継ノード)での情報転送処理が必用となる。従って本実施形態システムでは同一システム内ネットワーク回線1782を用いた情報通信でも、送信側ノードと受信側ノード間で中継する中継点(中継ノード)の上限値を規定する必用が有る。所で図5が示すように本実施形態システムで使用される複合モジュールは、内蔵された蓄電モジュール(電池)1554から電源供給を受ける。そして中継点(中継ノード)として通信情報の転送処理を行う度に、蓄電モジュール(電池)1554内に蓄えられた電力が消費される。従って同一システム内ネットワーク回線1782を用いた情報通信では、可能な限り中継点(中継ノード)での通信情報転送回数を減らす必用が有る。ここで1回の通信情報の転送に消費される電力量と蓄電モジュール(電池)1554の蓄電量との関係を考慮すると、途中の中継点(中継ノード)の数は30以下、望ましくは10以下に設定するのが適正となる。従って本実施形態システムで同一システム内ネットワーク回線1782上で情報通信を行う場合には、上記通過可能ノード残数情報HPLMTの値を30以下、望ましくは10以下に送信側ノード内で設定する所に大きな特徴が有る。それにより複合モジュールに内蔵された蓄電モジュール1554内蓄電量の不必用な浪費を防止し、長期に亘り安定的に本実施形態システム内でのネットワーク通信を維持できる効果が有る。
図13(d)が示すようにIPv6ヘッダIPv6HD内の先頭情報SIPHDの領域は、バージョン情報IPVRS、交信クラス情報IPCLS、そして通信種別ラベル情報IPLBLのそれぞれが格納される領域から構成され、そして先頭から上記の順に配置されている。ここでバージョン情報IPVRSが格納される領域は4ビットで構成され、インターネット・プロトコル・バージョン番号として“6”(2進法記述では“0110”)の値が格納される。
そして前述したIPv6データ/ペイロード長さ情報LIPv6DUが格納される領域の直前に設定され、2.5バイトで構成される領域に、通信種別ラベル情報IPLBLが格納される。所で通信ミドルウェアデータAPLDTと拡張データEXDT(図11(b))を合わせたデータサイズが大きくなった場合には、それらを分割して複数の物理層フレームPPDU内に分散配置(格納)して通信する方法を、2.3節で説明した。この時に複数の物理層フレームPPDU間の送信順が分かるように、MAC層ヘッダMACHD内のMAC層のシーケンス番号MASQNMの領域内に順次インクリメントした値を格納する方法を説明した。それと並行して本実施形態システムでは、複数の異なるIPv6データ/ペイロードIPv6DU(図11(d)参照)内に分散して格納した場合に同一の通信ミドルウェアデータAPLDT(及び拡張データEXDT)全体を識別するために、上記の通信種別ラベル情報IPLBLを使用する。所でこの通信種別ラベル情報IPLBLの内容は、送信側ノード内で最初に(ネットワーク通信する前に)設定される。従って同一のサービス提供に関連した通信ミドルウェアデータAPLDT(と拡張データEXDT)の一纏まりの(一連の)通信情報内容を複数のIPv6データ/ペイロードIPv6DU内に分散配置(格納)して通信する場合には、対応する全ての通信種別ラベル情報IPLBLの格納領域内に同一のラベル情報が共通に格納されて通信される。所で本実施形態システムでは図10Aに示すシステム外ネットワーク回線1788を使ったサーバn_1116−nとシステムコントローラα_1126間の情報通信や図16に示す同一システム内ネットワーク回線1782を使ったシステムコントローラα_1126と機器1250間の情報通信、あるいは同一ドメイン内ネットワーク回線2082を使ったシステムコントローラα_1126とシステムコントローラβ_1128間の情報通信が可能となっている。そして異なるサービス提供に関連した通信ミドルウェアデータAPLDT(と拡張データEXDT)毎に“通信種別ラベル情報IPLBL”の内容を変える事で、複数の異なるサービス提供に関する通信ミドルウェアデータAPLDT(と拡張データEXDT)を同時に両者間での通信可能となる効果が生まれる。その結果、サーバn_1116−nとシステムコントローラα_1126間(あるいはシステムコントローラα_1126と機器1250間、またはシステムコントローラα_1126とシステムコントローラβ_1128間)で同時に複数の異なるサービス提供に関する情報通信ができるので、ユーザに対する多彩なサービスを同時に提供できる。また更にこの“通信種別ラベル情報IPLBL”と前述したMAC層ヘッダMACHD内のMAC層のシーケンス番号MASQNMの情報を組み合わせる事で、受信時の通信情報の信頼性確認精度が更に向上する別の効果も生まれる。また他の応用例として、同一のサービス提供に関連した通信ミドルウェアデータAPLDT(と拡張データEXDT)に対して“通信種別ラベル情報IPLBL”内に共通に格納される同一情報を“暗号鍵”に利用しても良い。
所で図13(d)に記載された交信クラス情報IPCLSは、ネットワーク通信時の交信クラスを示すために用いられる。特にこの交信クラス情報IPCLSは、図10Aにおけるインターネット・プロトコル・バージョン6層IPv6より上位層(すなわち通信ミドルウェア層APL02、APL06や拡張アプリケーション層EXL06)で主に使用するケースを想定している。既に2.3節内で図12B(d)(e)を用いて拡大IEEE拡張アドレスEXEXADRSの説明を行った。そして本実施形態システムの応用例として、
○受信側および送信側におけるIEEE拡張アドレスDEXADRS、SEXADRS内の拡大IEEE拡張アドレスEXEXADRSの格納領域を廃止する
○受信側および送信側におけるIEEE拡張アドレスDEXADRS、SEXADRSの格納領域内は、それぞれIEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEの情報のみを格納する
(すなわち受信側および送信側におけるIEEE拡張アドレスDEXADRS、SEXADRSは、それぞれIEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEに一致させる)
○上記の交信クラス情報IPCLSの格納領域内にIEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEの情報を格納する
(すなわち上記の交信クラス情報IPCLSを、IEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEに一致させる)
を行っても良い。
既に2.2節内で図10Aを用いて説明したように、インターネット・プロトコル・バージョン6層IPv6の機能は、通信モジュール1768、1202−3または通信モジュール1660内の通信制御部1700が担う。そして通信ミドルウェア層APL02、APL06と拡張アプリケーション層EXL06に対応したサービス提供機能は、プロセッサ1738、1230または通信モジュール1660内のインターフェース部1710が担う。従って、図11におけるIPv6ヘッダIPv6HD内を含めたTCPヘッダTCPHD以前の情報は、通信モジュール1768、1202−3または通信モジュール1660内の通信制御部1700内で処理される。また同様に通信ミドルウェアデータAPLDT(と拡張データEXDT)は、プロセッサ1738、1230または通信モジュール1660内のインターフェース部1710内で処理される。そして物理層フレームPPDUを受信した時には、始めに通信モジュール1768、1202−3または通信モジュール1660内の通信制御部1700内で上記の交信クラス情報IPCLSを処理した後に、通信ミドルウェアデータAPLDT(と拡張データEXDT)をプロセッサ1738、1230または通信モジュール1660内のインターフェース部1710側に引き渡す。従って図12B(d)(e)で説明した拡大IEEE拡張アドレスEXEXADRSをIPv6ヘッダIPv6HD内(の交信クラス情報IPCLS格納領域)に格納する事で、通信ミドルウェアデータAPLDT(と拡張データEXDT)を受け取る前にプロセッサ1738、1230または通信モジュール1660内で事前に複合モジュールの対応準備が可能となる。それにより、複合モジュールから送信された通信情報に対するシステムコントローラα_1126の処理速度が向上する効果が生まれる。
2.5節 通信ミドルウェア層でのC−フォーマットのデータ構造
本実施形態システム内で使用される“C−フォーマット”は、2.1節で図10Aを用いて説明した同一システム内ネットワーク回線1782上で複合モジュール1460、1470に対して情報通信される通信ミドルウェア層APL02内で使用する事を主眼としている。またそれに限らず、2.1節内の最後に説明したように、異なるシステムβ_1134内のシステムコントローラβ_1128とシステムα_1132内の通信モジュール1460、1470間の情報通信時にこのC−フォーマットを使用しても良い。更に機器1250との情報通信にも使用しても良い。ここでこのC−フォーマットでは拡張アプリケーション層EXL06(図10A参照)を規定せず、通信ミドルウェア層APL02内でのみ使用する。
そして通信モジュール1460、1470への処理負担を極力軽減するため、C−フォーマットのデータ構造を極力簡素化した所に特徴が有る。そしてデータ構造を簡素化する具体的方法として、図11(a)内の物理層ヘッダPHYHDからTCPヘッダTCPHDに至る領域内の情報重複を最大限避けたデータ構造にしている。(詳細内容とその効果は後述する。)その具体的な一例として、通信ミドルウェアデータAPLDT内にこの通信ミドルウェアデータAPLDTのサイズ情報を持つ代わりに、IPv6ヘッダIPv6HD内のIPv6データ/ペイロード長さ情報LIPv6DUを兼用させている。ここでこのIPv6データ/ペイロード長さ情報LIPv6DUは、図11(d)におけるIPv6データ/ペイロードIPv6DUのデータサイズを示している。そしてTCPヘッダTCPHDのデータサイズは予め決まっているので、図14(c)(d)が示すように、このIPv6データ/ペイロード長さ情報LIPv6DUから自動的に通信ミドルウェアデータAPLDTのデータサイズが決まる。C−フォーマットにおける通信ミドルウェアデータAPLDTの基本的なデータサイズは、1バイトに規定されている。しかし複合モジュール1460、1470との間での通信情報内容に拠っては、図14(d)に示すように最後部に拡張送信データCEDTを付加して通信ミドルウェアデータAPLDTのデータサイズを1バイトより拡張しても良い。
図10Bを用いて2.1節内で既に説明したように、A−フォーマットまたはE−フォーマットでは情報通信に使用される交換情報(テーブル)1810内に交換アクセス制御情報1830が含まれている。そしてC−フォーマットでもこの交換アクセス制御情報1830が“3ビット形式”で格納可能になっている。特に3ビットで記述(=8種類の制御情報を記述)する事で、多様な交換アクセス制御情報1830の識別が可能になる効果が有る。具体的な制御方法として、図10Bのケース1に記載した指令(コマンド発行)1852時には、この交換アクセス制御情報1830として[111]のリセット指示を設定する。そして結果報告(ステータス)1854を回答する場合には、この交換アクセス制御情報1830として[010]のレスポンス回答またはレポート通知または[001]のアクノーリッジメント通知を設定する。
本実施形態システムでは、センサ/通信モジュール1460内のセンサ部でアナログ検出した信号を2値情報に変換して情報通信する場合の閾値(2値信号に変換する時の基準レベル)を外部から設定可能になっている。この閾値を設定する場合には、図10Bのケース1内の指令(コマンド発行)1852に対応して交換アクセス制御情報1830として[110]の閾値レベル設定指示を設定する。
一方図10Bケース2の回答要求(リクエスト)1872に対応して、この交換アクセス制御情報1830として[011]のレスポンス(データ)要求を設定する。そしてその応答(レスポンス)1874では、この交換アクセス制御情報1830として[010]のレスポンス回答/レポート通知を設定する。
また図10Bにおけるケース3の複合モジュール1460、1470側から自主的に行う定期的/非定期的報告1894に対応して、この交換アクセス制御情報1830として[010]のレスポンス回答/レポート通知を設定する。そして複合モジュール1460、1470で異常を発見した場合には、上記の非定期的報告として交換アクセス制御情報1830に[000]を設定してアラーム通知を行う。また複合モジュール1460、1470側から自主的に定期的報告を行う場合には、システムコントローラα_1126側から定期的に報告する時間間隔(インターバル)が設定できる。この場合には、この交換アクセス制御情報1830に[101]を設定してレポートのインターバルに関する指示を行う。
例えば図8Aのスマートメータ1124として、例えば使用電力量(公共消費材)を上記指定された時間間隔(インターバル)でシステムコントローラα_1126やサーバn_1116−nまたは卸売業者A_1102にレポートする場合を考える。この場合、瞬間的な使用電力量(公共消費材)の瞬時値をレポートする方法と所定期間毎に積算した値をレポートする方法が有る。この状況に対応して本実施形態システムでは、この交換アクセス制御情報1830に[100]を設定してデータ蓄積インターバルに関する指示を行う。ここで、この交換アクセス制御情報1830の格納領域の直後に設定された送信データを格納する領域に[00000]を指定した場合には、瞬時的な使用量(電力量などの公共消費材の使用量)を指定された時間間隔(インターバル)毎に複合モジュールからレポートする。
図14(d)が示すように、この交換アクセス制御情報1830の格納領域の直後に設定された4ビットで構成された多値送信データ部CTMDTの格納領域と1ビットで構成された2値送信データ部CT2DTの格納領域により、2値または多値の送信データが送信される。ここで送信データが2値と多値のいずれかを示す特別の情報格納領域を持たず、上記送信データにより2値/多値の識別をさせる所に特徴が有る。すなわち送信データが2値の場合には、4ビットの多値送信データ部CTMDTの値を全て“0”(すなわち[0000])に設定する。ここでON状態またはOK状態を示す場合には、この2値送信データ部CT2DTに[1]を設定する。またOFF状態またはNG(No)状態を示す場合には、この2値送信データ部CT2DTに[0]を設定する。一方複合モジュール1460、1470に異常事態が発生し、システムコントローラα_1126に対してアラーム通知(この交換アクセス制御情報1830に[000]が設定)する場合の送信データ設定方法を説明する。この場合には、上記多値送信データ部CTMDTに[0000]を設定する。そして複合モジュール1460、1470の異常事態として、センサの検出異常または駆動部の駆動系統異常(制御不能/制御困難)の場合には、この2値送信データ部CT2DTに[1]を設定する。所で図5が示すように、センサ/通信モジュール1460または駆動/通信モジュール内には蓄電モジュール(電池)1554が内蔵されているため、蓄電量の枯渇(残量切れ)のリスクが常に有る。従ってこの蓄電モジュール(電池)1554内の残量が少なくなると、この2値送信データ部CT2DTに[0]を設定してシステムコントローラα_1126に対してバッテリ残量の減少を通知する。
一方で多値を送信データとして情報通信する場合には、多値送信データ部CTMDTと2値送信データ部CT2DTを合わせた5ビット信号で、多値を表現する。例えば送信データとして0%から100%までの多値情報を格納する場合、0%から100%までの多値を30分割した値に変換して[00010](=0%に相当)から[11111](=100%に相当)の値で表現する。しかし本実施形態システムではそれに限らず、多値送信データ部CTMDTと2値送信データ部CT2DTの組み合わせで、他の方法で多値情報を表現しても良い。また例えば気温や湿度の検出や照明設備の照度変更など30分割された値では表現が不足される高精度なセンス情報の通信や閾値あるいは制御値の高精度設定などでは、2値送信データ部CT2DTを格納する領域の直後に拡張送信データCEDTを格納する領域を追加して多値情報の表現精度を上げる事が出来る。またこの時の多値の表現に使用するビット数は、前述したようにIPv6ヘッダIPv6HD内のIPv6データ/ペイロード長さ情報LIPv6DUに拠り示される。
このように特に2値/多値の識別子を持たず、送信データの内容で2値/多値の識別をさせる事で、通信ミドルウェアデータAPLDTのデータサイズを小さくできる効果が生まれる。そしてその結果として、同一システム内ネットワーク回線1782上での情報通信渋滞(混雑)を緩和すると共に、複合モジュール1460、1470内(の特に図10Aに示すインターフェース部1710内)の処理の簡素化と複合モジュール1460、1470の低価格化が図れる。
また多値で表現された送信データの意味を示す情報も、C−フォーマットに準拠した通信ミドルウェアデータAPLDT内に格納する領域を持たない。その代わりに、前記多値で表現された送信データの意味を示す情報として、図12B(d)のIEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEの情報を活用する所に本実施形態システムの特徴が有る。既に2.3節内で説明したように、このIEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEの発行機関では、上記アドレスに対応した複合モジュール1460、1470の機能と性能を把握している。そしてこの情報をインターネット上で公開する事で、このIEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEに対応した複合モジュールに対応した送信データの意味が分かる。更に図12B(e)を用いた2.3節内の説明と図13(d)を用いた2.4節内の説明から、MAC層ヘッダMACHD内の受信側と送信側におけるIEEE拡張アドレスDEXADRS、SEXADRSの中あるいはIPv6ヘッダIPv6HD内の交信クラス情報IPCLSの中に複合モジュール種類識別情報CMTIDが格納可能になっている。したがって前述したIEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEとこの複合モジュール種類識別情報CMTIDを組み合わせる事で、複合モジュール1460、1470との間で通信される(例えば多値で表現される)送信データCTMDT、CT2DT、CEDTの意味とその解釈方法を精度良く理解できる。このように送信データCTMDT、CT2DT、CEDTの意味とその解釈に利用できるので、上記の複合モジュール種類識別情報CMTIDは複合モジュール1460、1470毎に対応した交換情報の種別識別情報1840(図10B参照)に関係する。すなわち上記の複合モジュール種類識別情報CMTIDを、2.7節で後述するA−フォーマットにおける <table> Element 内の number attribute(図15B(b)参照)と同じ目的で使用できる。一方この交換情報の種別識別情報1840は、E−フォーマットでは交換情報の種別識別情報EPC(図15A(f)を用いた2.6節内説明を参照)に対応する。このようにE−フォーマット及びA−フォーマットのいずれも、図10Bの交換情報の種別識別情報1840が通信ミドルウェアデータAPLDT内に含まれている。
上記のE−フォーマットやA−フォーマットと比べてC−フォーマットでは、図10Bの交換情報の種別識別情報1840に関連する情報としてMAC層ヘッダMACHD内の情報(図12B(e)の複合モジュール種類識別情報CMTID)あるいはIPv6ヘッダIPv6HD内の情報(2.4節内説明に拠る図13(d)交信クラス情報内情報)を利用できる所に大きな特徴が有る。既に2.2節で説明したように受信時には、図10Aの下層側に位置する階層から順に通信情報の処理を行う。従って比較的下層側に位置するメディア・アクセス層MAC02の機能レベルあるいはインターネット・プロトコル・バージョン6層IPv6の機能レベルで対象ノードがセンサ/通信モジュール1460か?または駆動/通信モジュール1470か?の識別のみならず、複合モジュールの種類も事前に分かると、通信ミドルウェアデータAPLDTが(図10Aに示す)通信モジュール1660内の通信制御部1700からインターフェース部1710に渡される前に、事前にインターフェース部1710内でC−フォーマット対応準備が行える効果が生まれる。それにより、受信側での通信情報処理の高速化が図れる。
また上記のようにC−フォーマットでは他の階層で規定される情報の兼用利用を行い、通信ミドルウェアデータAPLDTのデータサイズの最小化を図っている。それにより同一システム内ネットワーク回線1782上での情報通信渋滞(混雑)を緩和すると共に、複合モジュール1460、1470内(の特に図10Aに示すインターフェース部1710内)の処理の簡素化と複合モジュール1460、1470の低価格化が図れる。
次に上記に説明した方法に沿ったC−フォーマットにおける通信ミドルウェアデータAPLDTの具体的データ例を示す。たとえばシステムコントローラα_1126から駆動/通信モジュール1470に対して“動作停止”の指令(コマンド発行)1852(図10B)を行う場合、上記交信アクセス制御情報1830に“[111]リセット指示”を設定すると共に、多値送信データ部CTMDTに“[0000]2値データ指定”、そして2値送信データ部CT2DTに“[0]OFF指定”を設定する。またセンサ/通信モジュール1460からシステムコントローラα_1126に対して例えば公共消費材の現在までの既使用量が50%の状況を通知(レポート)する場合、上記交信アクセス制御情報1830に“[010]レポート通知”を設定すると共に、多値送信データ部CTMDTと2値送信データ部CT2DTを一緒にした5ビット領域に“[10001]50%”を設定する。
また別の具体的データ例を示す。既に4.3節で、
○ 指が太い大柄の大人では、タッチパッドや静電容量式ボタンの感度が低くても、安定したユーザ入力が可能 な反面、
○ 指の細い子供や女性では、タッチパッドや静電容量式ボタンの感度を上げないと応答しない 説明をした。それに対応し、4.3節に従ってユーザ状態(指の太さ)を推定/判断した後に、タッチパッドや静電容量式ボタンに対応したセンサ/通信モジュール1460に対してシステムコントローラα_1126から感度設定する一例を示す。この場合には、上記交信アクセス制御情報1830に“[110]閾値レベル設定指示”を設定する。そしてタッチパッドまたは静電容量式ボタンの感度を25%から73%に上げる場合を考える。すると多値送信データ部CTMDTと2値送信データ部CT2DTを組み合わせた5ビット領域に、73%に対応した[11000]を指定する。
上記の実施例では、ON/OFF等の2値情報の通信のタイミングと状態設定などの多値情報の通信タイミングを分け、多値送信データ部CTMDT内に設定された情報が[0000]の可否で通信情報の2値か?多値か?の識別をさせている。しかしそれに限らず他の実施例として、ON/OFF等の2値データと状態設定などの多値データを同時タイミングで一緒に通信しても良い。この場合には2値送信データ部CT2DTに1ビットの2値を設定し、多値送信データ部CTMDT内の4ビットで多値を設定しても良い。このように例えば“動作を開始させると同時に(例えば設定温度などの)状態設定値を指定する”など、2値データと状態設定などの多値データを同時タイミングで一緒に通信する事で、システムコントローラα_1126と複合モジュール1460、1470間の情報通信頻度が下げられ、同一システム内ネットワーク回線1782(図10A)内の通信混雑を緩和できる効果が生まれる。
所でIEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEとこの複合モジュール種類識別情報CMTIDを組み合わせて通信精度と通信安定性を高められる事を既に説明した。そして万が一システムコントローラα_1126内でエラーが発生し、通信相手の複合モジュール1460、1470の機能を取り違えた場合、上記の両者の情報間を比較する事でこのエラーを発見できる。仮に複合モジュール1460、1470側でこのシステムコントローラα_1126内でのエラーを発見した場合、本実施形態システムでは、そのエラーを複合モジュール1460、1470からシステムコントローラα_1126に通知できる機能がサポートされている。この場合には、図14(d)の交信アクセス制御情報1830に“[000]アラーム通知”を設定する。そして次の多値送信データ部CTMDTと2値送信データ部CT2DTを組み合わせた5ビット領域に[00011]を設定して対象誤認識通知を知らせる。このように本実施形態システムではシステムコントローラα_1126内発生したエラーを複合モジュール1460、1470または機器1250から通知する機能をサポートする事で、同一システム内ネットワーク回線1782上の情報通信の安定性と信頼性が向上する効果が有る。
2.6節 通信ミドルウェア層でのE−フォーマットのデータ構造
本実施形態システム内で使用される“E−フォーマット”は2.1節で図16を用いて説明したように、主に機器1250やサーバn_1116−nに対して情報通信される通信ミドルウェア層APL06内で使用する事を主眼としている。またそれに限らず、異なるシステムコントローラα_1126、β_1128間の情報通信に使用しても良く、また複合モジュール1460、1470との情報通信に使用しても良い。また既に図10Bを用いて2.1節で説明したように、E−フォーマットでは基本的に送信側ノードと受信側ノード間での交換情報(テーブル)1810の交換処理により情報通信を行う。従ってこの交換情報(テーブル)1810(またはその一部)が、図11(a)に示した通信ミドルウェアデータAPLDT内の一部としてIPv6データ/ペイロードIPv6DU内に格納される。2.7節で後述するようにA−フォーマットでは広義のテキスト形式で記述される特徴が有る。それに比べるとE−フォーマットは予め設定された所定領域に対応情報を設定コードで格納する形式を取る特徴が有る。従ってE−フォーマットとは『通信ミドルウェアデータAPLDTの領域内の所定領域に設定コードを格納』するフォーマットと定義する。従って本実施形態システムにおいて、予め設定された所定領域に設定コードを順次格納するあらゆるフォーマットがE−フォーマットに含まれる。
E−フォーマットに基付く通信ミドルウェア層データAPLDTの先頭には、図15A(b)が示すE−フォーマットヘッダE−HDが2バイト領域内に格納される。そしてこのE−フォーマットヘッダE−HDの値は、[1081h](“h”は16進数(hexadecimal)の値を示し、2進数表示では[0001000010000001])に設定される。そして次の2バイト領域には、要求送信と応答受信間の関連付け用識別情報TIDが格納される。所でこの要求送信と応答受信間の関連付け用識別情報TIDとは、回答要求(リクエスト)送信側が応答(レスポンス)受信時に事前に送信した回答要求(リクエスト)と受信した応答(レスポンス)間の関連付けを図るためのパラメータを意味する。(この回答要求(リクエスト)1872に対する応答(レスポンス)1874のシーケンスは、図10Bのケース2で示したシーケンスに対応する。)そしてこの領域に格納されるコードは、回答要求(リクエスト)送信側ノードが適宜任意に指定できる。次に前記回答要求(リクエスト)の受信側ノードがその応答(レスポンス)をする時には、この領域内に前回の回答要求(リクエスト)送信側ノードが設定したコードと同一のコードを格納する。そしてこの要求送信と応答受信間の関連付け用識別情報TIDの一致度判定に拠り、受信情報が前回の回答要求(リクエスト)の応答(レスポンス)を示すか否かを判断する。
そして図15A(b)が示す次の領域内に格納されるE−フォーマットデータE−DTが、図10Bを用いて2.1節で説明した交換情報1810に相当する。そして図15A(c)のように、このE−フォーマットデータE−DT内は3バイトの送信側機器の識別情報SEOJ、3バイトの受信側機器の識別情報DEOJ、1バイトの交信アクセス制御情報ESV、制御/処理関連情報CM1から構成され、前述した順に配置される。ここで前記1バイトの交信アクセス制御情報ESVは、図10Bを用いて2.1節で説明した交信アクセス制御情報1830に相当する。
また図15A(d)が示すように、この送信側機器の識別情報SEOJと受信側機器の識別情報DEOJ共に1バイトの機器種別グループコードDTGC、1バイトの機器種別コードDTC、1バイトの同一種別内機器識別コードDIDCから構成され、前述した順に配置される。この機器種別グループコードDTGCとは機器種別のグループを現し、例えばセンサー関連機器グループや空調関連機器グループ、住宅・設備関連機器グループ、調理・家事関連機器グループ等どのグループに対象機器が含まれるかを示す。次の機器種別コードDTCとは、例えばテレビ、エアコンなどの機器種別を表す。所で同一システムα_1132内に同一な機器種別に該当する異なる複数の機器1250が設置されている場合(例えば1件の住宅内に複数のエアコンが設置されている場合)、機器1250毎の識別を行うために前記の同一種別内機器識別コードDIDCが設定される。
所で機器1250の一例としてエアコンを考えた場合、“設定温度”や“設定風量”、“設定風向”、“設定タイマー時間(自動ON/自動OFF)”など複数項目に関する設定状態が存在するとともに、複数項目に対して同時に設定変更(状態変更制御)が可能となっている。従って図10Bに示す交換情報(テーブル)1810内では、単一の機器でさえ『複数の項目に関する状態』あるいは『複数の項目に関する同時設定変更指示(状態変更制御情報)』が定義され、それらの情報が一覧の形での記述できるようになっている。従って図15A(c)の制御/処理関連情報内には、図15A(e)が示すように複数項目に関して同時に状態情報の収集や設定変更に対応した状態変更制御が可能となっている。そして同時に収集すべき状態情報の項目数あるいは同時に状態変更制御(設定変更)を行う項目数が、制御/処理数NCMで1バイトで記述される。そしてその制御/処理数NCMで設定した項目数だけ、初回からn回目に亘る制御/処理情報CM−1〜nが前記の順番に配置されている。
そして各制御/処理情報CM−1〜nは図15A(f)が示すように、1バイトの交換情報の種別識別情報EPC、1バイトの個別交換情報のデータサイズPDC、個別交換情報EDTから構成され、前記の順番に配置されている。そして各機器1250に対応した項目毎に格納する“収集すべき状態情報”や“回答する状態情報”、あるいは“状態変更(設定変更)制御情報”が、前述した個別交換情報EDTとして格納される。また個別交換情報EDT毎のデータサイズ情報が、前記個別交換情報のデータサイズPDCとして格納される。
所で対応する機器1250の種別に拠りより(すなわち上述した機器種別コードDTCの内容に拠り)、状態を表す項目内容や状態変更制御(設定変更)対象の項目内容が異なる。従ってE−フォーマットでは対応する機器1250の種別(機器種別コードDTCの内容)毎に状態を収集すべき情報の項目と情報表現形式、または状態変更制御(設定変更)すべき項目と制御情報の表現形式を予め決め、その項目毎の表現形式に沿ったテンプレートと項目コード(テンプレートコード)を事前に準備している。そして対応する機器1250の種別(機器種別コードDTCの内容)毎に設定された項目コードが、前記の交換情報の種別識別情報EPCとして格納される。またこの交換情報の種別識別情報EPCが、図10Bに示した交換情報の種別識別情報1840に相当する。
ここでシステムコントローラα_1126から制御して家庭用エアコンの設定変更(状態変更制御)する場合を一例に取り、交換情報(テーブル)1810に対応したE−フォーマットデータE−DT内の情報の説明を行う。所でE−フォーマットでの設定変更(状態変更制御)の指令(コマンド発行)は、2.1節で説明した中の“書き込み要求”に対応する。従って図15A(c)の交信アクセス制御情報ESV(1830)として、[60h](=応答不要時)または[61h](=応答要時)が設定される。(また参考までに記載すると、交信アクセス制御情報ESV(1830)の設定コードとして“読み出し要求”時には[62h]、“通知”時には[73h]、“読み出し応答”時には[72h]がそれぞれ対応する。)そして家庭用エアコンの機器種別グループコードDTGCは、空調関連機器グループを意味する[01h]が該当する。また機器種別コードDTCは、[30h]となる。ここでシステムα_1132内の1台目のエアコンに割り当てた場合の同一機種別機器識別コードDIDCは[01h]となる。従ってシステムコントローラα_1126からこの家庭用エアコンに状態変更制御の指令1852(図10Bのケース1に対応)を行う場合には、図15A(c)内の受信側機器の識別情報は[013001h]となる。そしてシステムコントローラα_1126から制御して該当するエアコンを動作状態に変更する場合には、交換情報の種別識別情報EPCは[80h]、個別交換情報のデータサイズは[01h](=1バイト)、個別交換情報EDTは[30h]となる。従ってこれらの情報を組み合わせた初回の制御/処理情報CM−1は[800130h]で表せる。次にnかいめの制御/処理として設定温度を26℃に設定変更する場合には、交換情報の種別識別情報EPCは[B3h]、個別交換情報のデータサイズは[01h](=1バイト)、個別交換情報EDTは26℃を意味する[1Ah]となる。従ってこれらの情報を組み合わせたn回目の制御/処理情報CM−nは[B3011A]と表現される。
2.7節 通信ミドルウェア層でのA−フォーマットのデータ構造
本実施形態システム内で使用される“A−フォーマット”は2.1節で図16を用いて説明したように、主に機器1250やサーバn_1116−nに対して情報通信される通信ミドルウェア層APL06内で使用する事を主眼としている。またそれに限らず、異なるシステムコントローラα_1126、β_1128間の情報通信に使用しても良く、また複合モジュール1460、1470との情報通信に使用しても良い。また既に図10Bを用いて2.1節で説明したように、A−フォーマットでは基本的に送信側ノードと受信側ノード間での交換情報(テーブル)1810の交換処理により情報通信を行う。従ってこの交換情報(テーブル)1810(またはその一部)が、図11(a)に示した通信ミドルウェアデータAPLDT内の一部としてIPv6データ/ペイロードIPv6DU内に格納される。
A−フォーマットでは図15Bに一例を示すように、通信ミドルウェアデータAPLDTとしてXML(Extensible Markup Language)形式で記述されても良い。本明細書では上記XMLやHTML(Hypertext Markup Language)などテキストベースで内容を記述する方法を“広義のテキスト形式”と呼ぶ。例えばHTMLでは記述文中に必ずタグの記載が有る。しかしここで言う“広義のテキスト形式”では必ずしも上記のタグ記述は必須ではなく、広義の意味で何らかのテキスト形式の記述が有れば“広義のテキスト形式”に含まれる。従って例えばJavaアプレットやJavaスクリプト、あるいはC言語などのプログラムも上記の広義のテキスト形式に含まれる。このように通信ミドルウェアデータAPLDTを広義のテキスト形式で記述する事で、通信ミドルウェアデータAPLDTとしての汎用性や拡張性を確保できる効果が有る。従って本実施形態システムにおけるA−フォーマットとは、『通信ミドルウェア層APLに関係する通信情報として、広義のテキスト形式で記述されるフォーマット』と定義する。そして前記広義のテキスト形式で記述されるあらゆるフォーマットが、このA−フォーマットに含まれる。そして図10Bのテーブル形式で構成される交換情報(テーブル)1810は、図15B(b)における“<table> Element 領域”(<table - > から </table> までの範囲)が相当しても良い。
またA−フォーマットでは上記 <table> Element の親エレメント(Parent Element)として、Root Element である <tdl> Element が設定されても良い。(ここで上記の<tdl> とは、transferring data language を意味する。)また図15B(b)内で記載されるように、前記 <tdl> Element の属性情報(Attribute)として date 属性(date attribute)により該当テーブルの作成日を記述しても良い。ここで図15B(b)の記述では、該当テーブルの作成日が“2014年12月25日”となっている。
そして図15B(b)が示すように、上記 <table> Element 内の number 属性(number attribute)あるいは name 属性(name attribute)が、図10Bに示した交換情報の種別識別情報1840に相当する。所でA−フォーマットで記述された通信ミドルウェアデータAPLDT内では、2.6節で説明したE−フォーマットのように機器種別グループコードDTGCや機器種別コードDTCに対応した情報を表出って示す場所は無い。その代わりに、機器1250内の状態を収集すべき情報の項目と情報表現形式、または機器1250の状態変更制御(設定変更)すべき項目と制御情報の表現形式を予め規定したテーブルのテンプレートが、対応する機器種別毎に細かく設定されている。そしてこの機器種別毎に細かく設定されたテーブルのテンプレート毎にテーブル番号とそのテーブル名が指定されている。この一例として図15B(b)内で『number="02"』と記述しているように、number 属性が指定した数値で対応するテーブルのテンプレート番号を直接指定しても良い。従って上記の number 属性あるいは name 属性を対応する <table> Element 内に記述する事で、自動的にテーブルのテンプレートに合わせた通信ミドルウェアデータAPLDT内記述が可能となる。またそれに限らず本実施形態システムでは、情報交換用テーブルに使用される標準テンプレートの選択用に使える上記交換情報の種別識別情報1840に他の記述文を対応させても良い。また上記の number 属性で数値を指定する事で機器1250の種別に応じたテーブルのテンプレートを関連付ける方法と同様に、複合モジュール1460、1470の種類に応じた情報交換用標準テンプレート呼び出しには図12B(e)の複合モジュール種類識別情報CMTIDを利用しても良い(詳細内容は2.5節参照)。
所でA−フォーマットに準拠した通信ミドルウェアデータAPLDT内の通信情報記載例として図15B(b)では、図1のスマートメータ1124内で周期的に積算した使用電力量を“積算電流値(Ampere)”で電力供給サービスを行うサービスプロバイダB_1112−2(内のサーバn_1116−n)に通知する記述例を示している。また図1で示したように、このスマートメータ1124はシステムコントローラα_1126や卸売業者A1102ともネットワーク回線がつながっているので、このシステムコントローラα_1126や卸売業者A1102へ向けて上記通信情報を通信しても良い。一方このスマートメータ1124が設置された場所に拠り(すなわち一般家庭内やビルまたは工場に対応して)供給される電圧値が予め決まっているので、積算電力量の代わりに積算電流値を通知する。そして図15B(b)の記述例に限らず、あらゆる機器1250またはあらゆる複合モジュール1460、1470との情報通信に“広義のテキスト形式”で記述した情報を使用しても良い。
図15B(b)に示す積算電流値の通知の一例として、A−フォーマットではテンプレートとして“テーブル番号が2”で、テーブル・テンプレート名が“Device Nameplate Table”の標準テーブル(テーブル・テンプレート)を使用しても良い。またA−フォーマットでは Table を略して“TBL”と記述しても良い。従って <table> Element 内の number 属性として『number="02"』と記述し、name 属性として『name="DEVICE_NAMEPLATE_TBL』と記述する。
既に1.7節内で説明したようにスマートメータ1124のタイプとして、“電力使用量”に限らず“ガスの使用量”や“上水の使用量”、“下水の排出量”など多種類の公共消費材毎の使用状況を通知するスマートメータ1124が存在する。それに対して図15B(b)の記述例では“電気の使用量を測定する”と言う意味で、type 属性には『type="E_ELECTRIC_DEVICE_RCD"』と記述している。所で前記の“RCD”は、packedRecord のRecord を意味している。既に2.2節で説明したように、図15B(b)で記述された通信ミドルウェア層データAPDLT(の一部)は、MAC層データ/ペイロードMSDU内に梱包(packing)されて通信される。従って“上記通信ミドルウェア層データAPDLT(の一部)を梱包(packing)して物理層フレームPPDU内に記録(record)して通信する”と言う意味で、“packedRecord”と言う表現が使われる。従って<packedRecord> Element 内の number 属性でも上記と同じ単語を用いて『name="E_ELECTRIC_DEVICE_RCD"』と記述される。
既に図10Bを用いた2.1節内の説明で、このA−フォーマットと2.6節で説明したE−フォーマットのいずれも交換情報(テーブル)1810内に交信アクセス制御情報1830が含まれる事を示した。そしてこの交信アクセス制御情報1830を、<table> Element 内あるいは後述する <set> Element 内の accessibility attribute に対応させられる。この accessibility attribute により READWRITE 、READONLY 、WRITEONLY のいずれかを受信側ノードに要求できる。ここで READ とは、受信側ノード(例えば機器1250や複合モジュール1460、1470など)の状態を読み取り、その読み取った情報を回答させる(あるいはセンス情報を通知させる)指示を意味し、E−フォーマットでの“読み出し要求”などに対応する。また WRITE とは受信ノード側への情報回答や状態変更設定の指示を意味し、E−フォーマットでの“通知”や“読み出し応答”、あるいは“書き込み要求”に対応する。そして READWRITE とは、図10Bケース2の回答要求(リクエスト)1872/応答(レスポンス)1874のシーケンス対応を受信側ノードに指示する場合に使用する。またそれに限らず本実施形態システムでは、他の記述文を上記交信アクセス制御情報1830に対応させても良い。そして図15B(b)の例ではスマートメータ1124で測定した“積算電流値(Ampere)”の情報を受信側ノード(例えばサーバn_1116−nやコントローラα_1126または卸売業者A1102)に通知するので、accessibility="WRITEONLY" を指定している。
また図15B(b)に示した実施例における要素(Element)とは、『センス対象情報や検出対象の状態情報あるいは制御(設定変更)の対象とする状態情報などの個々の項目』を示している。従って図10Bの交換情報の種別識別情報1840で指定した情報内容(<table> Element 内の number attribute または name attribute で指定した情報内容)に合わせて選択されるテーブルのテンプレート内で事前に指定されている項目毎に個々の <element> Element 内で設定記述される。
所で“テーブル番号が2”で事前に設定されているテーブルのテンプレートの中で、『type="E_ELECTRIC_DEVICE_RCD"』で規定されているテーブル・テンプレートでは、<packedRecord> Element の中で規定される個々の項目として、“E_KH”(周期的に積算された電力量)、“E_KT”(テストパルス出力量)、“E_INPUT_SCALAR”(通信情報の単位を規定し、センサから入力された値を“何分の一”に圧縮するか?を示す)、“E_ELEMENT”(スマートメータのローカル番号)、“E_VOLTS”(瞬時の電圧値/送電系の電圧変動をリアルタイムでモニタ可能)や“E_AMPS”(周期的に積算した電流値)などが事前に準備されている。そして図15B(b)に示す記述例では、その中の“E_KH”と“E_AMPS”のみを<element> Element を利用して規定する。
まず name attribute で“E_KH”を指定した <element> Element により、「この通信情報が周期的に積算された電力量を通知」する事を宣言している。規格上は <element name="E_KH"> の情報だけで“E_KH”が何を意味しているか分かる。しかし規格書を参照しなくても交換情報(テーブル)1810の内容が理解できるように、<description> Element が設定されている。このように広義のテキスト形式で記述できるA−フォーマット内で“広義のテキストにより補足説明が可能な機能”を持つ所にもA−フォーマットの特徴が有る。それに拠り規格書の参照無しに記述内容が理解できるので、受信側ノードで交換情報(テーブル)1810の理解が容易になる効果が有る。
A−フォーマットの一例として、<set> Element を用いて数値設定を行っている。しかしそれに限らず、別の記述方法で数値設定を行っても良い。また <set> Element 使用に先立ち、name attribute で“E_KH”を指定した <element> Element 内で“E_AMPS_RCD”のタイプを規定(<element name="E_AMPS" type="E_AMPS_RCD")して、「“周期的に積算した電流値”の項目をMAC層データ/ペイロードMSDU内に packedRecord して通知する」事を明示する。その後、同じ“E_AMPS_RCD”の名称を利用して <set> Element を定義している。
スマートメータ1124が測定した“周期的な積算電流値”は、<enum> Element(enum とは、Electrical numerator を意味する)内の value attribute で設定する。(ここでスマートメータ1124が、value="$$$$" の $$$$ の所に測定値を自動的に代入する。)またここで設定した数値を意味する変数名“E_AMPS”を、<enumerator> Element 内の name attribute で指定している。
所でA−フォーマット内での“補足説明する機能”として、既に<description> Element を説明した。しかし上記に限らず、label attribute や text attribute を利用して補足説明を行っても良い。
2.8節 本実施形態システムで使用されるアドレステーブルとその活用例
上記の2.3節から2.7節での説明内容から、同一モジュールに対して階層毎に異なるアドレスが重複して設定される事が分かる。例えば図8Aのセンサモジュール1260−1や駆動モジュール1270−1、あるいは図8Bの駆動/通信モジュール1470−2やセンサ/通信モジュール1460−5に対して設定され得る各種アドレスの一覧を示すアドレステーブル内のデータ構造例を図23に示す。なおこのアドレステーブルの使用方法として、本2.8節内の説明内容以外に4.2節で説明した方法で利用しても良い。
所で図23では、図8Bの駆動/通信モジュール1470−2やセンサ/通信モジュール1460−5に重複されて設定されている各種アドレスを同一の縦の列内に纏めて記述されている。また図8Aの機器1250−1に内蔵されたセンサモジュール1260−1や駆動モジュール1270−1に重複されて設定されている各種アドレスも同一の縦の列内に纏めて記述されている。所で図23のアドレステーブル内のアドレス項目の一つに含まれるIEEE拡張アドレスEXADRSは通信モジュールチップ1202−4に対して付与される(2.3節参照)。従って図23のセンサモジュール1260−1と駆動モジュール1270−1に対応したIEEE拡張アドレスEXADRSは、同一機器1250−1に内蔵された通信モジュールチップ1202−4に関するアドレスが設定されている。
図23のアドレステーブル内に記載されたアドレス項目の中でメディア・アクセス層MAC02では2.3節で説明したように、IEEE拡張アドレスEXADRSが個々に設定される。次にインターネット・プロトコル・バージョン6層IPv6では2.4節で説明したように、IPアドレスIPADRS(送信側IPアドレス情報SIPADRS/受信側IPアドレス情報DIPADRS)が個々に設定される。一方通信ミドルウェア層APL06では2.6節で説明したE−フォーマットに準拠して、同一種別内機器種別コードDIDCが設定される。
そして上記一覧に各モジュールが現在配置されているセクション情報を加えた図23の一覧表をシステムコントローラβ_1134やシステムコントローラα_1126内のメモリ部1232内に所持する所に、本実施形態システムの特徴が有る。それにより、
(1) 効率良くかつ精度良くサービスの提供が行え、
(2) システムコントローラβ_1134やシステムコントローラα_1126内でのフォーマット変換が容易に行え、
(3) 送信側ノードや通信経路途中のノード内で発生するエラーの検出が容易となるので、情報通信の信頼性が向上する
と言う効果が生まれる。
第4章で説明したように本実施形態システムでは、セクション1_1142−1〜m_1142−m毎にサービス提供が行える。従って上記サービスの一形態として同一セクション1142単位で複数機器1250や複数の駆動/通信モジュール1470の状態を制御する(設定状態を変更する)場合に、図23の情報を活用して状態制御(設定状態の変更)対象の機器1250や駆動/通信モジュール1470の選択が非常に容易となる。
また2.1節で説明したように、異なるネットワーク回線(同一システム内ネットワーク回線1782/システム外ネットワーク回線1788/同一ドメイン内ネットワーク回線2082)を跨って情報通信する場合、途中でフォーマット変更を行う事が有る。この場合に図23の情報を利用する事で、フォーマット変換がスムーズかつ精度良く行える。
ここではシステムα_1132内に配置された機器1250または複合モジュール1460、1470と異なるシステムβ_1134に配置されたシステムコントローラβ_1128間の情報通信を一例として具体的な説明を行う。そしてこの情報通信途中で、中継するシステムコントローラα_1126内でフォーマット変換を行う場合の説明を行う。しかしそれに限らず本実施形態システムにおいて、あらゆる形態のネットワーク通信に図23の情報を使用しても良い。この前提条件として、システムコントローラα_1126とβ_1128共に図23の情報がメモリ部1232内に予め保存されている場合を想定する。もし仮にシステムコントローラβ_1128の配置位置がシステムα_1132から大きく離れた場合でも、システムコントローラβ_1128は図23の情報を利用してシステムα_1132内からどのような情報が収集でき、どのような状態制御(状態設定の変更)が行えるかが分かる。また本実施形態システムでは全ての情報通信にインターネット・プロトコル・バージョン6層IPv6を使用するので、システムコントローラβ_1128と全ての機器1250と複合モジュール1460、1470にはIPアドレス情報IPADRSが事前に設定されている。
始めに上記の情報通信途中にシステムコントローラα_1126内で通信ミドルウェア層APL02、APL06に関してC−フォーマットからE−フォーマットへのフォーマット変換を行う方法の説明を行う。既に2.5節で説明したように、C−フォーマット自体には一切のアドレス情報を持たないので、このC−フォーマット情報からはE−フォーマットで設定が必要な情報は得られない。しかし図23に示すように図23内にE−フォーマットに関係した情報が予め記録されている。従ってシステムコントローラα_1126内(具体的にはプロセッサ1230内)で、ここに記載されている機器種別グループコードDTGCや機器種別コードDTC、同一種別内機器識別コードDIDCを利用してE−フォーマットに準拠した情報を作成する。
逆にA−フォーマットやE−フォーマットあるいはW−フォーマットからC−フォーマットに変換した場合の説明をする。既に2.5節で説明したように、複合モジュール1460、1470がC−フォーマットを使用する場合には、通信ミドルウェア層APL02以外の階層で規定される図12B(d)(e)の拡大IEEE拡張アドレスEXEXADRSを使用する。しかし図23内に記載されている複合モジュール1460、1470毎のIEEE拡張アドレスEXADRSを活用することで、C−フォーマットに対応した処理がスムーズに行える。もし万が一上記IEEE拡張アドレスEXADRS内に拡大IEEE拡張アドレスEXEXADRSが含まれないフォーマットを使用していた場合には、IEEE802.15.4準拠のチップ毎設定アドレスADRSIEEEを用いてインターネット経由で対応する複合モジュール1460、1470の属性情報を入手できる。しかしこれに限らず、他の方法を利用しても良い。つまり本実施形態システムでは全ての情報通信にインターネット・プロトコル・バージョン6層IPv6を共通使用する特徴を生かし、(C−フォーマット以外を用いた情報通信時にも)2.4節で説明したように図13(d)の交信クラス情報IPCLS内に図12B(d)の拡大IEEE拡張アドレスEXEXADRSの情報を事前に格納しても良い。
次に物理層PHY02、PHY06やメディア・アクセス層MAC02、MAC06に関して、システムコントローラα_1126内(具体的にはプロセッサ1230内)でフォーマットの変更を行う方法に付いて説明する。この場合には、インターネット・プロトコル・バージョン6層IPv6で指定する共通のIPアドレスIPADRSを基準に図23の情報を利用して、物理層とメディア・アクセス層のみの付け替えを行う。つまり本実施形態システムでは途中の通信回線経路に拠らず共通に、IPv6ヘッダIPV6HD内に送信側IPアドレス情報SIPADRSと受信側IPアドレス情報DIPADRS(図13(b)参照)が格納されている。従って図23内情報に対して上記受信側IPアドレス情報DIPADRSを参照すると、Z−フォーマットで使用される受信側のPAN固有情報PANIDやIEEE拡張アドレスEXEADRSが抽出できる。
最後に図23の情報を利用する事で、ネットワーク回線を利用した情報通信の信頼性が向上する説明を行う。情報の送信側ノードや通信経路途中で情報を中継するノード(システムコントローラα_1126を含む)内で万が一のエラーが発生した場合、図12A〜図15Bに記載した通信情報の一部に不適切な情報が混入する危険性が有る。これが起きるとネットワークシステム内での情報通信が阻害される。この問題に対してシステムコントローラα_1126、β1128内で図23の情報を利用した通信情報の検証を逐次行う事で、通信情報のエラー発生有無やエラー箇所の特定が非常に容易に行える。その結果として、情報通信の信頼性が向上する効果が生まれる。
第3章 ユニット毎の管理/表示方法
3.1節 基本的なユニット管理方法に関する概説
図1と図2を用いて1.1節で説明したように、本実施形態システムでは、
『ドメイン/システム/セクション/ユニット/機器または複合モジュール』
と言う階層構造を有する。すなわちドメイン2_1122−2は1個以上のシステムα_1132から構成され、1個のシステム内はセクション1142に分割可能となっている。そしてそのセクション1142毎にユニット1290が配置される。またこのユニット1290の具体的形態として、機器1250単体や複合モジュール1295単体あるいはその混在系が許容される。そして更にシステムα_1132内のネットワーク通信を管理または制御、情報収集するシステムコントローラα_1126が存在し、この上記ユニット1290を管理する。所で停電や故障などの不測自体に対応可能なように、適宜別のシステムコントローラβ_1128の代替え的な管理/制御/情報収集も可能となっている。そして更にこの代替え可能なシステムコントローラβ_1128に関して、“移動可能”または“少なくとも一時的に対応するシステムα_1132外の配置”が許容される。
上記の階層構造に基付くユニットの管理方法として、『システムα_1132毎にそこに所属するユニットを管理する』所に本実施形態システムの特徴が有る。上述したように、システムコントローラα_1126(またはシステムコントローラβ_1128)がシステム毎のネットワーク通信を管理/制御/情報収集する。従って上述したように『同一システムα_1132内に含まれる全てのユニット1290をシステムα_1132単位で一括管理』する事で、システムコントローラα_1126(またはシステムコントローラβ_1128)のネットワーク通信の管理/制御/情報収集に関する利便性が向上する効果が有る。
またそれだけに限らず、4.2節で後述する“プラグイン処理”や“プラグアウト処理”あるいは“チェックイン処理”を利用して『システムα_1132に出入りするユニット1290に合わせて、システムα_1132内で管理対象となるユニット1290が切り替わる』所も次なる特徴が有る。すなわち特定のユニット1290がシステムα_1132内に入ると、システムコントローラα_1126(またはシステムコントローラβ_1128)がそれを自動的に検出し、その特定ユニット1290をシステムコントローラα_1126(またはシステムコントローラβ_1128)の管理対象ユニット1290として自動登録する。逆に別の所定ユニット1290がシステムα_1132から外に出ると、システムコントローラα_1126(またはシステムコントローラβ_1128)がそれを自動的に検出し、その別の所定ユニット1290をシステムコントローラα_1126(またはシステムコントローラβ_1128)の管理対象ユニット1290から自動的に削除する。
それにより特定システムα_1132に対する複数ユニット1290の頻繁な出入りが有っても、安定かつ高い信頼性を確保したまま特定システムα_1132内のネットワーク通信管理が行える効果が有る。
例えば従来のコンピュータシステムに外付けハードディスク装置や外付け光ディスク装置またはUSBメモリ装置などが接続されると、『新たな追加ドライブ』(例えばDドライブやEドライブなど)として自動認識(プラグイン処理)されて“ドライブ管理”される。ここで同一システムα_1132内に所属するユニット1290の数が少数の場合には、上記のようにユニット1290毎に個々のドライブとして管理されても良い。しかし本実施形態システムでは、同一システムα_1132内での多量なユニット1290の所属を許容する。仮に上述したように同一システムα_1132内で追加されるユニット1290毎に“Dドライブ”、“Eドライブ”‥ と逐次ドライブ追加すると、“Zドライブ”を越えた段階でドライブ管理が破綻する。このように従来技術を利用したユニット1290管理を試みると
A〕同一システムα_1132内のユニット1290数の増大に対応できない
と言う問題が有る。同様にドライブ管理に限らずネットワーク通信制御などのポート割付まで考えると、
B〕ユニット1290増大に、対応するポート割付けも破綻する
と言う更なる関連問題も生じる。この〔A〕と〔B〕の問題点回避を目指して独自な斬新的対策を試みると、
C〕従来のコンピュータシステム上の管理方法との互換性が崩れる
と言う更なる問題が生じる。
上記〔A〕〜〔C〕の課題を同時に解決する方法として本実施形態では、
『コンピュータのネットワークを経由したファイル管理に類似した手法でユニットを管理する』所に大きな特徴が有る。そして『1ユニット1290≒1擬似的なファイル』と見なす。ここでユニット1290を管理するシステムコントローラα_1126(またはシステムコントローラβ_1128)から見た“ユニット1290からの所定情報収集(例えばセンサ情報の収集)”の処理を、“ユニット1290からの情報再生(READ)処理”として管理する。同様にユニット1290を管理するシステムコントローラα_1126(またはシステムコントローラβ_1128)から見た“ユニット1290に対する設定状態の変更(制御)”の処理を、“ユニット1290に対する変更後の設定状態情報(制御したい内容)の書き込み(WRITE)処理”として管理する。
所でコンピュータのネットワークを経由したファイル管理では、ネットワーク上のファイル保存場所指定用に“URL(Uniform Resource Locator)の指定”を行う場合が多い。しかしユニット1290の存在場所は同一システムα_1132内と決まっているので、本実施形態では『URL指定の代わりに管理対象となるシステムα_1132を1個のドライブまたはフォルダ、ディレクトリとして割り当てる』所にも特徴が有る。上記〔A〕のようにユニット1290毎に個別ドライブを割り当てると、ユニット1290数の増大への対応は難しくなる。しかし上述したように『1システムα_1132に対して唯一のドライブまたはフォルダ、ディレクトリのみを割り当て』する事で、ユニット1290数の増大に柔軟に対応できるばかりで無く、ポート割付にも破綻が起きず、従来コンピュータ世界での管理方法との互換性が確保できる効果が生まれる。
次に上記の基本概念に対する実現手法の説明を行う。コンピュータネットワークを利用したアプリケーションソフト上で上記の“ユニット1290管理方法”を適用させるため、新たな『ユニット管理対応API(Application Interface)』を定義する方法が有る。またそれに限らず新たな『ユニット管理対応組み込み関数や参照/利用可能なサブプログラム』を定義しても良い。ここで前記の別プログラムから参照/利用可能なサブプログラムとして“サブルーチン”と呼ばれるプログラムを用いても良い。また上述した組み込み関数として“ファンクション”と呼ばれるプログラムやJavaスクリプトで特定アプリソフト(特定クラス)内で組み込み活用される所定の“メソッド”と呼ばれるプログラムでも良い。
3.2節 ユニット管理手段
3.1節で説明したユニット管理の基本概念を実現する手段として、上記のアプリケーションソフト対応以外に下記に示すハードウェア上での工夫も行う。
従来のコンピュータシステム周辺のハードウェア構成とソフトウェア階層構造を図18Aに示す。コンピュータに内蔵されたプロセッサ3010は、バスライン3012を経由して通信制御部3028や記録媒体制御部3024と接続されている。ここでプロセッサ3010と記録媒体制御部3024との間の情報通信は、直接バスライン3012に接続している接続部3018を介してデバイスドライブ(通称デバドラ)対応コマンド/ステータス情報が相互通信される。そして記録媒体制御部3024がその内容を解読し、直接記録媒体(ハード部)3014を駆動する。所でこの記録媒体(ハード部)3014の具体例として、ハードディスクや光ディスク、USBメモリなどが上げられる。
一方では情報通信実行部3016はネットワーク通信を実際に実行する部分を示し、通信媒体の有線/無線に応じた通信手段を有する。そしてこの情報通信実行部3016に対しても、上述したのと同様な方法でプロセッサ3010から制御される。
ソフトウェアから見た従来のコンピュータ制御としては、OS(Operating System)層3030内に記録媒体(ハード部)3014の制御に関与するデバイスドライバ領域3022や情報通信実行部3016の制御に関与する通信ドライバ領域3026が含まれる。一方でアプリケーションソフト3050は、OS層3030に対してAPI(Application Programming Interface)コマンド3045を発行してアプリケーションソフト3050の実行処理を行う。
上述した従来形に比べてシステムコントローラα_1126(あるいはシステムコントローラβ_1128)は図10Aに示すように、システム外ネットワーク回線1788を用いた情報通信制御と同一システム内ネットワーク回線1782を用いた情報通信制御の両方を行う所に大きな特徴が有る。そしてそれを可能にするために図18Bに示すように、システム外接続対応情報通信実行部3017とシステム内接続対応情報通信実行部3015の両方を所持している。所で説明の便宜上、図18Bでは両者を物理的に分離して記述している。しかしそれに限らずシステム外接続対応情報通信実行部3017とシステム内接続対応情報通信実行部3015間の一部が重複/兼用される構造を取っても良いし、一方が他方に略包含される広義の包含関係を持っても良い。
図18Bのシステム外接続対応情報通信実行部3017とシステム内接続対応情報通信実行部3015は無線電波の(検波を含む)送受信部あるいは有線通信の通信情報送受信部を意味している。従ってそれらを制御するシステム外接続対応通信制御部3029やシステム内接続対応通信制御部3021が存在する。また説明の便宜上、OS層3030内にシステム外接続対応通信ドライバ領域3027に対応した所定プログラム領域とシステム内接続対応通信ドライバ領域3025に対応した所定プログラム領域が存在するように記載した。しかし実際には独立したサブプログラムが存在する必要は無く、両者の一部が兼用される場合や、両者の中のいずれかのプログラムステップがBIOS(Basic Input/Output System)制御領域3020に対応したプログラム領域と重複/兼用しても良い。
3.1節で説明した動作概要を実現する手段として図18Bの実施例では、仮想的デバイスドライバ領域(ユニット毎に擬似的なファイルとして管理するため、記録装置に対応した“デバイスドライバ”と言う用語を使用)に対応するシステム内ユニットの管理/制御領域3034を(物理上現実的もしくは仮想的に)形成させる。そしてこのシステム内ユニットの管理/制御領域3034は、システム内接続対応通信ドライバ領域3025に対応する制御プログラムを含めたハードウェア構造のプロセッサ3010(の少なくとも一部)、及びシステム内接続対応通信制御部3021、そして両者をつなぐバスライン3012(接続部3018を含む)から構成される。
このシステム内ユニットの管理/制御領域3034内の構成は、図4Dで説明したプロセッサ/通信モジュール1465に対応している。つまり1.3節内で既に説明したように、システムコントローラα_1126(またはシステムコントローラβ_1128)内の同一システム内ネットワーク回線1782を利用したネットワーク通信に関与する部分はプロセッサ/通信モジュール1465と呼ばれる複合モジュール1295を構成している。
所で仮に同一システム内ネットワーク回線1782と言う特殊回線を使用してもネットワーク通信に関与する部分は、従来技術的には図18の通信制御部3028や通信ドライバ領域3026の一部と見なすべきと考えられる。しかし3.1節内で説明したように『1ユニット1290≒1擬似的なファイル』と見なしてユニット1290を管理する場合には、上述したシステム内ユニットの管理/制御領域3034は図18A内のデバイスドライバ領域3022に機能的に近い。従って図18Bの実施形態例では、システム内ユニットの管理/制御領域3034内の少なくとも一部はOS層3030内のデバイスドライブ領域3022内に含まれる。このように図18Bを記載したように、『既存のデバイスドライバ領域3022内に相当する制御プログラムの一部をユニット1290管理に兼用活用』しても良い。またそれに限らず、既存のBIOS制御領域3020に対応した制御プログラムの一部をユニット1290管理に兼用活用しても良い(すなわち前記BIOS制御領域3020に対応した制御プログラムの一部をシステム内ユニットの管理/制御領域3034に含めても良い)。
図18Bの実施形態例では、システムコントローラα_1126(またはシステムコントローラβ_1128)内で所定のOS(Operating System)を使用する場合を説明した。しかしそれに限らず、一切の既存OSを使わずにシステムコントローラα_1126(またはシステムコントローラβ_1128)の実行処理を行っても良い。
図19A及び図19Bに示した実施形態応用例では、Javaスクリプトを用いてユニット1290の管理を行う手段を示した。このJavaスクリプトでは所定のOS(Operating System)を使う代わりにJVM(Java(登録商標) Virtual Machine)を対応するプロセッサ3010毎に設置している。ここで実行するプログラム環境はクラス郡3160から構成され、アプリケーションクラス3158内の例えばメインメソッド3148がユーザ要求に応じて実行される。ここでクラス郡3160には、Javaスクリプトで記述された各種プログラムが含まれる。
図19Aにおいてプロセッサ3010とシステム内接続対応情報通信実行部3015がハードウェア部を意味している。そしてこのシステム内接続対応情報通信実行部3015の動作は、システム内接続対応通信制御部3021で制御される。
所で従来技術では、上記クラス郡3160内でファイル管理に関与するプログラムは複数のファイルクラス内インスタンスメソッド郡3144から構成されたファイルクラス3154内に格納されている。それに対して実施形態応用例では、前記クラス郡3160内にユニット1290管理用のシステム内ユニットの管理/制御クラス3150を新規設定する。そしてこのシステム内ユニットの管理/制御クラス3150内には、ユニットの管理/制御関連メソッド郡3140が格納される領域が存在する。ここで、ユニット1290の管理/制御に関係する各々細分化された動作処理を実行するプログラムが各種メソッドとして存在する。そしてこれら各種メソッドの集合体をメソッド郡と呼ばれ、上記ユニットの管理/制御関連メソッド郡3140を構成する。
次にアプリケーションクラス3158内のメインメソッド3148に記述されたプログラム3188とユニットの管理/制御関連メソッド郡3140との関係を、図19Bを用いて説明する。
アプリケーションクラス3158の起動時に、予め指定されたファイルクラス3154と本実施形態応用例で新規に提案するシステム内ユニットの管理/制御クラス3150の組み込み処理3174、3170(インポート処理)を行う。そして組み込まれた(インポートされた)ファイルクラス3154内に含まれているファイルクラス内インスタンスメソッド郡3144とシステム内ユニットの管理/制御クラス3150内に含まれているユニットの管理/制御関連メソッド郡3140をアプリケーションクラス3158内から使用可能となる。
次にメインメソッド3148に記述されたプログラムステップ3188内からファイルクラス内インスタンスメソッド群3144内の所定メソッドを参照3194して、効率良くファイルシステムに関する実行処理が行える。同様にメインメソッド3148に記述された別のプログラムステップ3188からユニットの管理/制御関連メソッド群3140内に含まれた特定メソッドを参照3190して、効率良くユニット1290に関する管理/制御/情報収集が行える。
本実施形態応用例では、ユーザとは異なる所定組織が予め上記のシステム内ユニットの管理/制御クラス3150に対応したプログラムを作成し、インターネット経由でシステムコントローラα_1126(またはシステムコントローラβ_1128)に対して適宜追加インストールする。またメインメソッド4148内でユニットの管理/制御関連メソッド群3140内の特定メソッドを参照3190するプログラムステップ3188は1行(多くて数行)なため、非常に簡単にアプリケーションクラス3158内のユニット1290の管理/制御/情報収集の対応が可能となる。上記の方法を利用する事で、システムコントローラα_1126(またはシステムコントローラβ_1128)のソフトウェア開発者の負担をほとんど掛けずにユニット1290の管理/制御/情報収集手段の組み込みが容易に行える効果が有る。
図20に既存のファイルシステムと本実施形態におけるユニット管理方法との比較を示す。基本的な管理情報の保管場所が既存のファイルシステムでは記憶媒体内に対し、本実施形態におけるユニット管理方法ではシステムコントローラα_1126内のメモリ部1232内に保存される所が異なる。次にコンテンツ(ファイルシステムでは所定ファイル/ユニット管理では所定ユニット)へのアクセス方法の説明をする。既存のファイルシステムではファイル名(ファイルが保存されているURLを含む)を指定し、ファイル内の所定情報が記録されている範囲をファイル内の相対アドレス範囲で指定する。それに比べて本実施形態におけるユニット管理方法では、対応ユニットのアドレス指定を行う。所でこの指定されるアドレスとは、図23のアドレステーブル内に記載されたアドレス(例えばIPアドレスIPADRSやIEEE拡張アドレスEXADRS)を意味する。なお本実施形態におけるユニット管理方法ではユニット1290が所有する情報(変更対象の設定状態情報やセンサ情報)の情報サイズが相対的に小さいため、1個のユニット1290全体としての情報読み出し/書き込みを行う。そのため既存のファイルシステムと比べて管理/制御/情報収集が大幅に簡素化される効果が有る。
そしてファイル全体またはユニット1290全体を管理する管理情報として既存のファイルシステムではFAT(File Allocation Table)やUDF(Universal Disk Format)などのファイル管理情報が対応し、本実施形態におけるユニット管理方法では図23のアドレステーブルが対応する。所で読み取り/変更対象情報は既存のファイルシステムではファイル内のコンテンツ(データ)に対して、本実施形態におけるユニット管理方法ではセンサ情報や各種状態情報/(変更対象の)設定状況が相当する。また本実施形態におけるユニット管理方法ではそれだけに限らず、図10Bに示した交換情報(テーブル)1810も読み取り/変更対象情報に含まれる。
所で全コンテンツ内容を一覧する機能の有無に、既存のファイルシステムと本実施形態におけるユニット管理方法の大きな違いが有る。すなわち既存のファイルシステムでは前述したファイル管理情報で“ファイル名一覧”は知れるが、全体のファイル内容を容易に知る手段が無い。従って全てのファイル内容の把握が必要な場合には、全ファイルを逐次開けてコンテンツ内容を新規に集計する必要が有り、非常に手間が掛かる。それに比べて本実施形態におけるユニット管理方法では図28の時系列情報追跡表が有るため、瞬時に全体のユニット1290の内容を把握できる。このように本実施形態におけるユニット管理方法では独自に全体のユニット1290の内容を把握できる手段を有するため、システムα_1132内の全ユニット1290の管理/制御/情報収集が迅速かつ容易に行える効果が有る。
3.3節 具体的なユニット管理例と表示例
多くの場合、システムコントローラα_1126(あるいはシステムコントローラβ_1128)が自動的にユニット1290からの情報収集や制御を行う。しかしユーザが手動で特定ユニット1290に対する制御や特定ユニット1290からの情報収集をしたい場合が生じる。その場合に図2に示したシステムコントローラα_1126内のユーザI/F部1234に表示されるユニット1290の管理画面表示例を下記に説明する。所で下記には表示画面例として説明するがそれに限らず、システムコントローラα_1126(あるいはシステムコントローラβ_1128)に拠るユニット1290毎の管理方法として同様の方法を用いても良い。
3.1節で既に説明したように、『1システムα_1132に対して唯一のドライブまたはフォルダ、ディレクトリのみを割り当て』する所に本実施形態の特徴が有る。そしてその状況を図21Aに示す。そしてシステムα_1132内の複数ユニット1290に対して各種の階層構造(フォルダとしての階層構造もしくはディレクトリ構造としての階層構造)を持たせる事で、管理をし易くしている。
図21A(a)はユニット1290の内容毎に階層化(フォルダ/ディレクトリ分割)した例を示し、図21(b)は同一システムα_1132内で分割されたセクション1142毎に階層化(フォルダ/ディレクトリ分割)した例を示している。しかしそれに限らず、ユーザの利便性に合わせて適宜適正に階層化(フォルダ/ディレクトリ分割)できる。
ここでは図21A(a)の階層化(フォルダ/ディレクトリ分割)に従って、下層に移動した時の表示/管理例を図21B〜図21Dに示す。図21A(a)の表示/管理例では、図23のアドレステーブル、図27の推定/判断照合表や図28の時系列情報追跡表が纏まって保存されている一覧データ用フォルダ2610とユニット1290の形態毎に分けたフォルダが、ユニット管理擬似ドライブに対応した“Tドライブ”内に配置されている。既に図3Aを用いて1.2節で説明したように、ユニット1290の形態として“機器1250単独”と“複合モジュール1295単独”、“両者の混合形態”、“それ以外”が存在する。そしてそれに合わせて図21A(a)では、機器対応フォルダ2612と複合モジュール対応フォルダ2614を配置している。
次にその中で複合モジュール対応フォルダ2614の中の表示内容(内部構造)例を、図21Bに示す。既に1.3節で説明したように、複合モジュール1295の形態としてセンサ/通信モジュール1460や駆動/通信モジュール1470、プロセッサ/通信モジュール1465、メモリ/通信モジュール1475、表示/通信モジュール1478などの形態が許容される。従ってそれに対応して図21Bでは、センサ/通信モジュール対応フォルダ2622や駆動/通信モジュール対応フォルダ2624、プロセッサ/通信モジュール対応フォルダ2626、メモリ/通信モジュール対応フォルダ2628、他機能/通信モジュール対応フォルダ2630が配置され、それに従って各々管理される。
更にその中でセンサ/通信モジュール対応フォルダ2622内の表示内容(内部構造)例を、図21Cに示す。既に2.5節内で説明したように、センサ/通信モジュール1460が検出して獲得するセンサ情報は、2値情報の場合と多値情報の場合の2種類存在する。従ってそれに対応して図21Cでは、2値データ対応フォルダ2634と多値データ対応フォルダ2638が配置され、それに応じて管理される。
最後の図21D(a)は、2値データ対応フォルダ2634内に属する全センサ/通信モジュール1460が擬似的ファイルとして配列されている。このように表示/管理する事で、非常に簡易的な方法で1個のユニット1290単位で管理/制御/情報収集が行える効果が有る。そしてセンサ/通信モジュール2_1460−2で検出/獲得するセンサ情報内容は、従来のファイルを開くように例えばクリックする事で図21D(b)のようにユーザに表示できる。所で駆動/通信モジュール1470内を開くと、現状の設定状況が表示される。そして駆動/通信モジュール1470などの制御(設定状態変更)が可能なユニット1290に関する図21D(b)の表示領域内に別の数値を貼り付け(挿入)する事で、容易に制御(設定状態変更)が行える。このような表示方法及び管理方法を採用する事で、ユーザの特定ユニット1290に対する制御(設定状態変更)処理が非常に簡易かつ迅速に行える効果が有る。
第4章 本実施形態システム内でのセクション概要
この第4章では最初に本実施形態システムにおける“セクション”の基本概念の説明を行う。そしてそのセクションの概念を用いた情報の収集方法やサービス提供方法の説明を行う。そして最後に送信側ノードから発する電波を用いた送信側ノードの位置検出方法とそれを利用したサービスに関する説明を行う。
4.1節 本実施形態システム内でのセクションの位置付け
本実施形態システムにおける“セクション”とは、『システム内で収集される情報の統合または管理に関係する単位』と『システム内で行うサービス提供に関する単位』の少なくともいずれかと定義する。従って上記セクションに対応した単位を、収集される情報の統合/管理目的と同時にサービス提供目的の両方に兼用して利用しても良い。またこのように両方の目的を兼用する場合には、収集される情報の統合/管理結果に連携して(あるいは情報の統合/管理結果に基付いて)ユーザに対するサービス提供を行っても良い。
また上記の単位として、同一システム内での情報収集やサービス提供に関する機能に関連した纏まりを意味しても良い。またそれに限らず上記の単位の別形態として、同一システム内での所定の空間的関連上の纏まりを意味しても良い。そしてこの空間的関連上の纏まりの具体的な内容として、同一システム内での所定の連続空間上の纏まりを対応させても良い。しかしそれに限らず上記空間的関連上の纏まりの具体的な内容として、例えば離散的(飛び石状態)に分布する連続空間の纏まりの所定の集合体を対応させても良い。そしてこの場合には、同一システムα_1132内で互いに異なるセクション1_1122−1とセクション2_1122−2間の分散分布状態が互いに混在した状態になっても良い。
そして図1が示すように、同一システムα_1132内は1個以上のセクションから構成される。従ってシステムα_1132全体が1個のセクション1_1122−1と空間的に完全に重なっても良いし、複数のセクション1_1122−1〜m_1122−mに分割されても良い。またそれに限らず、複数の異なるセクション1_1122−1〜m_1122−m間の一部が、互いに空間的に重なっても良い。
まず始めに図25に示す一例を用いて、上記セクションの位置付けを説明する。この図25では、一戸の建物が2部屋に間切りされている状況を示している。そして部屋毎にセクション1_1122−1(左側の部屋)とセクション2_1122−2(右側の部屋)と言う空間的単位を割り付ける。ここで図25(a)のように左側の部屋内(セクション1_1122−1内)では照明器具が点灯状態となり、右側の部屋内(セクション2_1122−2内)では照明器具が消えている(消灯状態)状態を考える。そして複数の光センサ(光検出機能を持つセンサモジュール1260を機器1250に内蔵(図1)しても良いし、図8Bのようにセンサ/通信モジュール1460を構成しても良い)を両セクション1_1122−1、2_1122−2内に配置した状態を想定する。すると(システムコントローラα_1126が)セクション1_1122−1内に配置された光センサから得られるセンサ情報を統合/管理すると、全てのセンサ情報から大きな光量検出情報が得られる。一方セクション2_1122−2内に配置された全ての光センサからは、小さな光量検出情報しか得られない。このようにセクション1_1122−1と2_1122−2内から得られるセンサ情報に共通性が現れる。そしてセクション1_1122−1、2_1122−2毎に得られる各種センサ情報を統合あるいは管理して各セクション1_1122−1、2_1122−2内の状態を推定/判断する所に本実施形態システムの大きな特徴が有る。そして同一セクション1122内の状態を推定/判断するのに、このセクション1122から収集した複数の情報を統合または管理した結果を用いて前記推定/判断の精度が向上する効果が生まれる。
次に非常に寒冷な外気環境下において、図25(b)のようにセクション1_1122−1内に設置されたエアコンのみを動かして空調させた場合を考える。この場合にはセクション2_1122−2内では空調が働いて無いため、右側の部屋内に居るユーザに対して“暖かさのサービス”は提供されない。しかし左側の部屋内の何処に居ても、ユーザに対して“暖かさの提供サービス”が行われている。このように同一セクション1122内で同じサービスが共通に提供できる場合が多い。このように本実施形態システムではユーザに対する『セクション1122毎のサービス提供を制御』する事で、同一システムα_1132内でのユーザに対するサービス管理が容易になる効果が生まれる。更にシステムα_1132全体で提供するサービスと比べてセクション1〜m_1142−1〜m単位でサービスを実施する事でユーザに対する木目細かなサービスが提供でき、エンドユーザの満足度を向上できる効果が有る。
ここではセクションの説明として“部屋”の例を使ったが本実施例形態システムではそれに限らず、上述した定義に合致したあらゆる空間的単位をセクションに該当させても良い。
所で本実施形態システムでは、ネットワークシステムα_1132内のネットワーク通信を制御/管理/情報収集するシステムコントローラα_1126が、上記システムα_1132内を各セクション1_1142−1〜m_1142−mに区分しても良い。ここで上述したように、システムコントローラα_1126が “同時に暗くなった範囲”や“同時に明るくなった範囲”あるいは“同時に温度が上昇または降下した範囲”などを自動的に検出する事で、自動的にセクション1_1142−1〜m_1142−mに区分できる。またそれ以外として、カメラなどによる撮影結果を基にして区分しても良い。しかしそれに限らず、ユーザによる直接指定によりセクション1_1142−1〜m_1142−mへの区分を行っても良い。
4.2節 各種モジュールや各種機器のセクション内配置場所の管理方法
4.1節から4.3節までの例で説明したように、システムコントローラα_1126が対応するシステムα_1132内の情報を収集してセクション1_1142−1〜m_1142−m毎の状態を推定/判断するには、各ユニット1290(機器1250や複合モジュール1295、1460、1470)がそれぞれどのセクション1_1142−1〜m_1142−m内に配置されているかを事前に知っておく必用が有る。そしてそれを可能にするため、同一システムα_1132内に存在する1個以上のユニット1290(機器1250や複合モジュール1295、1460、1470)毎に配置されているセクション1_1142−1〜m_1142−m情報を管理する所に大きな特徴が有る。そしてこの特徴に関して別な表現をすると、下記のようになる。すなわち独自に取得もしくは作成を行って(図4Aの他機能モジュール1440の機能が対応)得られた情報を通信する機能(図4Aの通信モジュール1660が担う)を有する複数のユニット1290(図2)と、前記複数のユニット1290からの前記情報を取得し管理するシステムコントローラα_1126(図1)とを備え、前記システムコントローラα_1126は前記ユニット1290毎にセクション1_1142−1〜m_1142−mに区分して管理し、各ユニット1290が属する前記セクション1_1142−1〜m_1142−mに関する情報を前記システムコントローラα_1126が保持する。
一方上記の特徴をシステムα_1132(クライアントシステム)の観点から見ると、前記クライアントシステムとしての特徴は下記のように表現できる。すなわちこのクライアントシステム(システムα_1132)は外部のクラウド(サーバn_1116−n)と接続可能であって、情報を管理するシステムコントローラα_1126と前記システムコントローラα_1126に提供する情報を取得もしくは作成して送信する機能を有するユニット1290とを備え、前記システムコントローラα_1126は、ユニット1290をセクション1_1142−1〜m_1142−mに区分して管理し、各ユニット1290が属する該セクションに関する情報を保持することを特徴する。
所で上記のユニット1290毎に属するセクションに関する情報として、後述する図23のアドレステーブルが対応する。
従って本4.2節では、上記の特徴を実現するための管理方法を中心に説明する。 なお下記の説明では、図2や図8A/Bが示すシステムα_1132内に設置されたシステムコントローラα_1126がネットワーク通信システムα_1132内の管理と運営あるいは制御を行うシステムモデルを前提として説明する。しかしそれに限らず下記の説明内容を、図9のシステムα_1132の外に設置されたシステムコントローラβ_1128あるいはサーバn_1116−nがルータ(ゲートウェア)1300を経由して上記ネットワーク通信システムα_1132内の管理と運営あるいは制御を行うシステムモデルに適合させても良い。またこの場合には、下記説明文中のシステムコントローラα_1126の部分をシステムコントローラβ_1128あるいはサーバn_1116−nに置き換えれば良い。
セクション1_1142−1〜m_1142−m毎に配置されたユニット1290(機器1250や複合モジュール1295、1460、1470)を管理するため、後述する図23のアドレステーブルが図2に示すシステムコントローラα_1126内のメモリ部1232(そして図1のシステムコントローラβ_1128内)に事前に記録されている。ここで図23のアドレステーブル内記載例は、同一システムα_1132内で図8Bのセンサ/通信モジュール1460−1〜5や駆動/通信モジュール1470−1〜2と図8Aの機器1250−1〜3が混在配置された例を示している。所で本実施形態システムでは図8Aに示すように、1台の機器1250−1内に複数のセンサモジュール1260−1、2の内蔵が許容される。そして各センサモジュール1260−1、2からは、それぞれ種類の異なるセンサ情報が得られる。従って各種の情報を収集してセクション1142毎の状態を推定/判断するには、アドレステーブルで機器1250−1〜3の設置場所を管理するのでは無く、この機器1250−1〜3に内蔵された個々のセンサモジュール1260−1〜5や個々の駆動モジュール1270−1が設置されたセクション1_1142−1〜m_1142−mの情報を管理するのが望ましい。
図23のアドレステーブル内記載例では、“セクション情報”に関係した横一列にセンサモジュール1260−1と駆動モジュール1270−1、駆動/通信モジュール1470−2、センサ/通信モジュール1460−5が配置されたセクション場所が纏めて記載されている。ここから、センサモジュール1260−1がセクション2_1142−2内に配置されている事が分かる。そして本実施形態システムでは上記アドレステーブルの作成とメンテナンスを通して、セクション1142毎に配置された各種複合モジュール1460、1470や各センサモジュール1260と各駆動モジュール1270の管理をリアルタイムで行う。しかし本実施形態システムでは上記方法に限らず、システムコントローラα_1126が管理可能なあらゆる配置場所の管理方法を行っても良い。
所で本実施形態システムでは同時に複数の異なるシステム(クライアントシステム)の共存を許容する所に特徴が有る。そしてその特徴と図2に記載した内容も加味した結果と上記の上述したアドレステーブル(図23)を組み合わせて新たに生じた特徴として下記の内容を明記できる。すなわちクライアントシステム(システムα_1132)は外部のクラウド(サーバn_1116−n)と接続可能で有り、独自に取得もしくは作成した情報を通信する機能(図4Aの通信モジュール1660が担う)を有するユニット1290と、前記ユニット1290からの前記情報を取得し管理するシステムコントローラα_1126とを備えたクライアントシステムα_1132を複数(クライアントシステムα_1126とクライアントシステムβ_1134の複数)含む複合クライアントシステム(図1のドメイン2_1122−2に対応)であって、独自に取得もしくは作成した前記情報を前記システムコントローラα_1126へ送信が可能であり、前記複合クライアントシステム(ドメイン2_1122−2)に含まれるクライアントシステムα_1132を管理する前記システムコントローラα_1126は複数のユニット1295−1〜−7をセクション(図2におけるセクション1_1142−1とセクション2_1142−1及びセクションm_1142−m)に区分して管理し、各ユニットが属する該セクションに関する情報(図23のアドレステーブル)を保持する特徴を持つ。
次に上記アドレステーブルの作成方法及びメンテナンス方法を図22に示す。まず始めのStep101として、同一システム_1132内でのセクション1_1142−1〜m_1142−mの定義を行う。ここで本実施形態システムでは、最初にセクション定義(Step101)を行い、それに基付いてセクション1142毎の配置情報設定または配置情報の管理(Step102またはStep103)を行う所に大きな特徴が有る。このように最初に定義したセクション分割状態に合わせて各種モジュールや各種機器の配置場所を管理する事で、リアルタイムでのセクション毎の状態推定や判断が容易になる効果が有る。またそれだけでなく、各種モジュールや各種機器の配置場所を管理し易いと言う別の効果も生まれる。
特に5.2.3節で後述するように、社会インフラ分野では同一地域内で複数の異なるセクション定義方法が存在し得る。すなわち図35の例では、地図上での住所の番地毎に各セクション1142を設定する代わりに、水道管の配管に沿ってセクション1142を分割する方法や配電電力線の配線経路に沿ってセクション1142を分割する方法など複数の定義方法が存在し得る。従って社会インフラ分野では、例えば地図情報などの何らかの基準情報を基に、使用目的毎に独自にセクション1142の分割方法を定義するのが望ましい。
一方民生分野では、セクション1142の定義方法として例えば『一戸(1件屋)内での部屋割り』のようにユーザの定義に従い、自動的にセクション定義を行っても良い。例えばユーザがGPS(Global Positioning System)機能を有したビデオカメラ(あるいはカメラ内蔵スマートホンやタブレット、または携帯電話)を持って自宅内を撮影し、その撮影映像を自動解析する事で図24に示すようなセクション1142の定義が自動的に行える。上記例では、セクション1142の定義方法をユーザが指定する形になっている。しかし本実施形態ではそれに限らず、例えば予めデフォルトで『部屋割りによりセクション1142分割が定義』されても良い。このようにデフォルト設定する事で、Step101の段階でのユーザ負担を軽減できる効果が有る。あるいは上記デフォルトのセクション分割方法に沿って自動的にセクション分割した後、ユーザが図8Aのシステムコントローラα_1126内のユーザI/F部1234を利用してセクション分割方法を一部修正しても良い。また他の方法として、個々の部屋の中心位置情報を上記GPS機能で入力し、その入力結果を解析して自動的にセクション定義を行っても良い。そして本実施形態では上記の方法に限らず、あらゆる方法でセクション1_1142−1〜m_1142−mの物理空間的位置情報を入手しても良い。例えば上述した方法では、このセクション定義に何らかのユーザの人手を必用とする。しかしユーザの人手を一切掛けずにセクション1_1142−1〜m_1142−mの物理空間的位置情報を入手しても良い。その具体的方法の一例として、カメラとGPS機能を内蔵したロボットクリーナーで所定住宅内の部屋(セクション1142)を跨って掃除をさせながら部屋割りとそれぞれの位置情報を測定しても良い。この方法を利用すると、ユーザに一切の負担を掛けずに非常に簡易的にセクション1_1142−1〜m_1142−mの物理空間的位置情報が入手できる効果が有る。
また本実施形態の他の応用例として、最初にセクション定義(Step101)を行わず、各種ユニット1290(複合モジュール1295、1460、1470や機器1250)から得られた情報を利用して自動的にセクション定義を行っても良い。すなわちシステムα_1132内に配置された各種複合モジュール1460、1470や各種機器1250の少なくとも一部を始めに作動させ、作動させた後にセクション1142の分割を行う。これにより同一システム内でのセクション定義(Step101)をユーザが意識しないので、ユーザの心理的負担を軽減できる効果が有る。上記方法の具体的内容を以下に説明する。後述するように、初期設定(Step102)や移動位置の自動追跡(Step103)により各種複合モジュール1460、1470や各種機器1250の配置情報をシステムコントローラα_1126はリアルタイムで把握できる。また図25(a)を用いて4.1節で説明したようにユーザが行動してセクション2_1142−2内の状態が変化すると、その中に配置された複合モジュール1460、1470や機器1250から同期して状態変化関連情報が得られる。従ってシステムα_1132内に配置されたユニット1290(複合モジュール1295、1460、1470や機器1250)から得られた情報(センス情報や状態設定制御情報など)の変化に対する同期性を見る事で、各種複合モジュール1460、1470や各種機器1250配置場所の関連性が予想できる。そしてこの同期性検出を時間経過に従って複数回繰り返す事で、精度良く同じセクション1142内に配置されたユニット1290(複合モジュール1295、1460、1470や機器1250)の位置関係を推定/判断できる。そしてシステムコントローラα_1126は、その推定/判断結果を図23のアドレステーブル内のセクション情報欄に記入する。
次に図22のStep102に対応した各種ユニット1290(複合モジュール1295、1460、1470や機器1250)の初期設定方法(Check-in method)に付いて説明する。図5のセンサ/通信モジュール1460内構造では、例えば近接無線転送技術のTransferJetや非接触型ICカード規格のFeliCa(FelicityとCardを組み合わせた造語)などの近接場無線に対応した近接場通信モジュール1560が内蔵されても良い。また図示してないが、駆動/通信モジュール1670や機器1250内にも同様な近接場通信モジュール1560を内蔵しても良い。そして本実施形態システムの一実施例における複合モジュール1460、1470または機器1250を新規に設置した時のシステムα_1132内での初期設定時に、GPS(Global Positioning System)機能が内蔵された携帯形外部機器(図示して無い)を近付けて前記近接場通信モジュール1560との通信を行っても良い。所でこの携帯形外部機器は上記の近接場無線対応の近接場通信モジュール1560と共に、同一システム内ネットワーク回線1782(図10Aを用いた2.1節説明内容参照)を経由してシステムコントローラα_1126との間で情報通信可能な通信モジュール1202も内蔵している。そしてこの初期設定時に前記システムコントローラα_1126が新規の(初期設定対象の)複合モジュール1460、1470または機器1250のIPアドレス情報IPADRS(詳細は図13を用いた2.4節の説明内容を参照)を自動登録する。またこの近接場通信時には前記システムコントローラα_1126から新規の複合モジュール1460、1470または機器1250に対して(1)この新規登録したIPアドレス情報IPADRS、(2)システムコントローラα_1126側のIPアドレス情報IPADRS、(3)現在の携帯形外部機器が存在する場所のPAN固有の識別情報PANID(図12Aを用いた2.3節内説明参照)、(4)システムコントローラα_1126が設置されている場所に対応したPAN固有の識別情報PANID、(5)システムコントローラα_1126が所有するIEEE拡張アドレスEXADRSの各情報を送信する。そして更にこの近接場通信を利用して、新規の(初期設定対象の)複合モジュール1460、1470または機器1250からシステムコントローラα_1126へ向けて(6)自分が所有するIEEE拡張アドレスEXADRSの情報を送信する。このように初期設定(Step102)の段階で近接場通信などの手段を利用して両者間の情報交換する事で、同一システム内ネットワーク回線1782を利用した情報通信の準備が整う。ここでは初期設定時の情報交換方法の一例として、上記近接場通信を利用した方法を説明した。しかし本実施形態システムではそれに限らず、他の手段で初期設定時の情報交換を行っても良い。あるいはそれ以外の方法による初期設定方法として後述するように、最初に暫定的なアドレスを利用した同一システム内ネットワーク回線1782上での暫定的通信を行って正規なアドレス交換を行っても良い。従ってこのような近接場通信を行う代わりに、前記のGPS機能付き携帯形外部機器を単に近付けても良い。そしてこの時に前記の携帯形外部機器から得られたGPS位置情報を、対応するユニット1290(複合モジュール1295、1460、1470または機器1250)の配置場所情報としてシステムコントローラα_1126が自動的に認識する。一方このシステムコントローラα_1126は上記のGPS情報と、Step101のセクション定義で事前に得られたセクション1_1142−1〜m_1142−m毎のGPS範囲情報とを比較する。そしてその比較結果に基付いて新規に配置したユニット1290(複合モジュール1295、1460、1470または機器1250)がどのセクション1_1142−1〜m_1142−m内に配置されているかを自動的に推定/判断し、その結果を図23のアドレステーブル内の該当箇所内に登録する。またその結果を図8AのユーザI/F部1234で表示してユーザに通知し、正誤の確認をユーザにしてもらうと共に必用に応じてユーザに修正登録をしてもらう。
上記の実施例ではユニット1290(機器1250や複合モジュール1295)の初期設定(Step102)にユーザ操作が必用となる。しかし本実施形態ではそれに限らず、自動的に初期設定(Step102)を行っても良い。その具体的実施の一例を説明する。本実施形態ではユーザが途中でユニット1290(複合モジュール1295、1460、1470や機器1250)の配置場所の移動を想定し、Step103のようにユニット1290(複合モジュール1295、1460、1470や機器1250)の自動追跡が可能となっている。ここでこの自動追跡には、4.4節で後述する方法を利用する。従って初期設定時に前記自動追跡技術を使用して、システムコントローラα_1126が初期設定対象のユニット1290(複合モジュール1295、1460、1470または機器1250)の位置をモニタする。そしてその結果得られた配置場所情報と前述したセクション1_1142−1〜m_1142−m毎のGPS範囲情報とを比較し、新規設定対象のユニット1290(複合モジュール1295、1460、1470または機器1250)が該当するセクション1142を自動的に推定/判断し、図23のアドレステーブル内の該当箇所内に登録する。
また初期設定対象のユニット1290(複合モジュール1295、1460、1470または機器1250)が最初に同一システム内ネットワーク回線1782上で暫定的な通信を行う場合には、図12A(e)内(詳細は2.3節を参照)のα)送信側におけるPAN固有の識別情報SPANID、β)受信側におけるPAN固有の識別情報DPANID、γ)受信側におけるIEEE拡張アドレスDEXADRS、及び図13(b)内(2.4節)のδ)送信側IPアドレス情報SIPADRS、ε)受信側IPアドレス情報DIPADRSの各情報格納領域内をブランクにするか又はZ−フォーマット(2.1節参照)で予め定められたデフォルト値を格納しても良い。このように初期設定対象のユニット1290(複合モジュール1295、1460、1470または機器1250)からの初回の暫定的通信を受信すれば、このデフォルト値(あるいはブランク状態)を利用してシステムコントロールα_1126から初期設定対象のユニット1290(複合モジュール1295、1460、1470または機器1250)に対する情報通信を開始できる。そしてこの次にシステムコントロールα_1126から送信される通信情報の内での前述したα)初期設定対象側におけるPAN固有の識別情報SPANIDとδ)初期設定対象側のIPアドレス情報SIPADRSに関しては、通信ミドルウェアデータAPLDT格納領域(図11を用いた2.2節の説明参照)内に格納して送信しても良い。この場合でも初期設定対象のユニット1290(複合モジュール1295、1460、1470または機器1250)がシステムα_1132内に配置されている事が分かっているので、誤って別のドメイン1122内で初期設定される危険性が無い。上記の方法では初期設定時にユーザが関与しないので、ユーザに負担を掛けずに自動で初期設定操作が行える効果が有る。
上記説明のように『初期設定時に初期設定対象物の位置を検出する』所に本実施形態の大きな特徴が有る。それによりシステムコントローラα_1126内で対応するシステムα_1132内そしてそれに関連するドメイン2_1122−2内に配置される事を確認できるので、誤って初期設定対象物を別のドメイン1_1122−1あるいは別のシステムβ_1134内で初期設定(登録)する危険性が無い効果が有る。更に初期設定方法に拠ってはユーザの人手が全く掛からないので、ユーザの精神的負担が軽減できるだけで無く、人的ミスが防げるために初期設定処理の信頼性が向上する効果も有る。更に本実施形態では、『初期設定時に初期設定対象物のセクション帰属状態も規定する』所に次の特徴が有る。それにより初期設定直後でも、初期設定対象物を活用したセクション単位でのサービス提供が出来る効果が有る。
所でここでは新規購入したユニット1290(複合モジュール1295、1460、1470または機器1250)がドメイン2_1122−2内で使用可能な状況にする処理を『初期設定』と定義し、特に『Check-in』と呼んでも良い。一方で初期設定後のユニット1290(複合モジュール1295、1460、1470または機器1250)が一度ドメイン2_1142−2の外に出た後、再度同じドメイン2_1142−2内に再び入り、システムα_1132またはシステムβ_1134内でのネットワーク通信可能な状態に復活させる処理を『プラグイン』と定義しても良い。
このようなプラグイン対象のユニット1290(複合モジュール1295、1460、1470または機器1250)は、事前に設定された“δ)プラグイン側のIPアドレス情報SIPADRS”と、同一ドメイン2_1122−2中に帰属するいずれかのシステムコントローラα_1126またはβ_1128に関する“ε)相手のシステムコントローラに設定されたIPアドレス情報DIPADRS”の情報を知っている。従って図10Aを使って2.1節で説明したように、ネットワーク通信にインターネット・プロトコル・バージョン6層IPv6を使用する限り、このプラグイン対象のユニット1290(複合モジュール1295、1460、1470または機器1250)が世界中の何処に有ってもネットワーク通信は原理的には可能となる。
従って本実施形態システムでは、プラグイン対象のユニット1290(複合モジュール1295、1460、1470または機器1250)が同じドメイン2_1122−2に帰属するいずれかのシステムα_1132、β_1134が規定する物理的領域内に配置されているか否かで、自動的なプラグイン処理を行っても良い。具体的にはシステムα_1132、β_1134が前述した初期設定と同じ方法で、プラグインの対象とするユニット1290(複合モジュール1295、1460、1470または機器1250)の配置場所を調べる。すなわちシステムコントローラα_1132、β_1134は常に同一システム内のネットワーク回線1782(図10A、図16を用いた2.1節説明参照)上での情報通信状況を監視し、図23のアドレステーブル内に登録されたユニット1290(機器1250(内のセンサモジュール1260や駆動モジュール1270)や複合モジュール1295、1460、1470)以外からの情報通信が無い事を常に確認し続ける。そして図23のアドレステーブル内に登録されたユニット1290(機器1250(内のセンサモジュール1260や駆動モジュール1270)や複合モジュール1295、1460、1470)以外からの情報通信を発見した時には、送信側のIPアドレス情報SIPADRSの内容を確認する。そしてこの送信側のIPアドレス情報SIPADRSの内容が過去にシステムα_1132、β_1134内で使用された情報なら、プラグイン処理を開始する。またそれ以外の情報なら、初期設定処理を開始する。つまりシステムコントローラα_1126、β_1128は、システムα_1132、β_1134内のユニット1290(機器1250(内のセンサモジュール1260や駆動モジュール1270)や複合モジュール1295、1460、1470)の配置場所を常に管理している。そしてプラグイン対象のユニット1290(複合モジュール1295、1460、1470または機器1250)が同じドメイン2_1122−2に帰属するいずれかのシステムα_1132、β_1134が規定する物理的領域内に入り込む事を自動検知し、自動的にプラグイン処理を行う。このプラグイン処理の途中で、ユーザI/F部1234を利用してユーザにプラグイン可否の確認を行っても良い。そしてプラグイン処理の最終段階で、プラグインを行ったユニット1290(複合モジュール1295、1460、1470または機器1250)に関連する情報を図23のアドレステーブル内に追記処理する。このようにシステムコントローラα_1126、β_1128がプラグイン対象物の位置に応じて自動的にプラグイン処理を開始するため、ユーザの手作業は一切必要無い。これによりユーザの負担を掛けずに非常に簡易的に“プラグイン”処理が実行できる効果が有る。
以上に説明したプラグイン処理を第1章で説明したシステムα_1126(クライアントシステム)の視点から見ると、下記の特徴を示す事ができる。すなわち本実施形態システムにおけるクライアントシステム(システムα_1126)は情報を取得もしくは作成して通信する機能を有するユニット1290と前記ユニットからの前記情報を取得し管理するシステムコントローラα_1126とを備え、前記システムコントローラα_1126が複数のユニット1290それぞれをセクション1_1142−1〜m_1142−mに区分して管理し、各ユニット1290が属する該セクション1_1142−1〜m_1142−mに関する情報(図23のアドレステーブル)を保持するとともに、前記ユニットに関する情報(図21D)を保持するものであって、前記各ユニット1290が属する該セクション1_1142−1〜m_1142−mに関する情報(図23のアドレステーブル)に既に登録されている前記ユニット1290とは異なる新たなユニットを登録する場合には、(1)新たな登録が必要となる前記新ユニットが上述した情報(図23のアドレステーブル)に既に登録されているか否かを事前チェックし、(2)上述した情報(図23のアドレステーブル)内に前記新ユニットが登録されて無い事を確認し、(3)上述した情報(図23のアドレステーブル)内に前記新ユニットを登録し、更に(4)前記新ユニットがいずれのセクション1_1142−1〜m_1142−mに属するかをチェックし、(5)上述した情報(図23のアドレステーブル)内に前記新ユニットが属するセクションに関する情報を付与することを特徴とする。
また特に上記のアドレステーブルとして前記複数のユニット1290に関して第1のセクションに関する情報(すなわち第1のセクションに属するユニット1290の情報)及び前記第2のセクションに関する情報(すなわち第2のセクションに属するユニット1290の情報)を含む所に特徴が有る。
また更に上記のアドレステーブルに関して前記情報が時系列情報として記録されている所にも次なる特徴が有る。
そして上記に特徴を明確化したように、特に本実施形態では『対象物の位置を検出してプラグイン』を行える所に大きな特徴が有る。そして更に『プラグイン時に対象物のセクション帰属状態も規定する』所に次の特徴が有る。そしてそれらの特徴による効果は、前述した初期設定時の効果と一致する。
また本実施形態に対応したプラグイン処理が行われたか否かは、上記のシステムコントローラα_1126が管理する(図2が示すシステムコントローラα_1126内のメモリ部1232内に保存された)アドレステーブル(図23)内の記載内容変化を解読する事で容易に判断が可能となる。
また別の確認方法としては、ち新規登録対象のユニット1290(複合モジュール1295、1460、1470または機器1250)を上記システムα_1132の外から中へ移動させた時の、この新規登録対象ユニット1290から送信される通信情報内容の変化を調べても良い。すなわち例えば始めに上記ユニット1290(複合モジュール1295、1460、1470または機器1250)を別のドメイン1_1122−1に配置させる。するとドメイン1_1122−1内に配置された新規登録対象ユニット1290から送信される通信情報内の受信側IPアドレス情報DIPADRS(図13(b)/2.4節)が、上記システムα_1132に対応した受信側IPアドレス情報DIPADRSとは異なるアドレスが格納されている。同様にメディア・アクセス層MAC02、MAC06内で設定される受信側アドレス(図10A&図16&図11/2.2節)も、システムα_1132とは異なる情報が格納されている。その後この新規登録対象ユニット1290(複合モジュール1295、1460、1470または機器1250)を上記システムα_1132内に移動させ、プラグイン処理が終わった後の上記対応アドレスを確認する。プラグイン処理が完了後に上記新規登録対象ユニット1290(複合モジュール1295、1460、1470または機器1250)から送信される通信情報内での受信側IPアドレス情報DIPADRSは、システムα_1132(あるいは図9のシステムではシステムコントローラβ_1128)と一致する。またメディア・アクセス層MAC02、MAC06内で設定される受信側アドレス(例えば2.3節に関連した図12A(e)の受信側におけるPAN固有の識別情報DPANIDや受信側におけるIEEE拡張アドレスDEXADRS)も、システムα_1132(あるいは図9のシステムではシステムコントローラβ_1128)と一致する。
また参考までに、上記プラグイン処理途中での通信情報内のアドレス情報の変化を下記に説明する。まずは予め別のドメイン1_1122−1内でネットワーク接続されていた新規登録対象ユニット1290(複合モジュール1295、1460、1470または機器1250)の配置場所を移動させた直後の説明から始める。もしこの新規登録対象ユニット1290が機器1250−1の場合には、新規登録対象ユニット1290内にGPS機能が搭載されるため、機器1250自体が配置場所移動を認識できる。そしてかつて(今回のプラグイン処理前に)このシステムα_1132内に配置された経験が有る場合には、対応機器1250−1内部のメモリ部1242内にシステムコントローラαのIPアドレス情報IPADRSとメディア・アクセス層MAC02、MAC06内で設定されるアドレスが保存されている。従って対応機器1250−1はこの情報を利用して、システムコントローラαに対する情報通信を行う。なお今後は図13(b)に記載の送信側IPアドレス情報SIPADRSと受信側IPアドレス情報DIPADRSを総称する場合には、単にIPアドレス情報IPADRSと表現する。同様に図12A(e)に記載の受信側におけるIEEE拡張アドレスDEXADRSと送信側におけるIEEE拡張アドレスSEXADRSを総称して呼ぶ場合には、IEEE拡張アドレスEXADRSと記述する。
一方で、対応機器1250−1が以前にこのシステムα_1132内に配置された経験が無い場合には、送信側IPアドレス情報SIPADRSや送信側におけるIEEE拡張アドレスSEXADRSなどメディア・アクセス層MAC02、MAC06内で設定されるアドレス領域内をブランクにするか、あるいは所定のダミー情報を格納してシステムα_1132内で情報通信し、システムコントローラα_に対して初期設定処理(図22のStep102)を促す。
所で上記の新規登録対象ユニット1290が複合モジュール1295、1460、1470の場合には基本的にGPS機能を持たない。従ってこの場合の新規登録対象ユニット1290(複合モジュール1295、1460、1470)は、配置場所が移動された事を知らない。そのためこの新規登録対象ユニット1290(複合モジュール1295、1460、1470)は配置場所移動後も、別のドメイン1_1122−1内に配置されていた時と同様の通信情報をシステムα_1132内で送信する。
システムコントローラα_1126(あるいはβ_1128)は、常にシステムα_1132内での通信情報の監視を行っている。従って同一システム内ネットワーク回線1782(図10A、図16)上で通信される物理層フレームPPDU(図11(f))内に想定外のIPアドレス情報IPADRSやIEEE拡張アドレスEXADRSなどのメディア・アクセス層MAC02、MAC06内で設定されるアドレス情報が格納されている事を発見すると、4.4節(と図31〜図34)で後述する方法で、該当する物理層フレームPPDUの送信元の場所を確認する。そして対象となる送信元の場所が(図22のStep101のセクション定義結果に基付いて)ステップα_1126の領域内の場合には、初期設定処理(Step102)あるいはプラグイン処理を開始する。
この初期設定とプラグインのいずれの処理も、メディア・アクセス層MAC02、MAC06内で設定され上記の物理層フレームPPDU内に格納された送信側のアドレス(送信側におけるIEEE拡張アドレスSEXADRSなど)を利用して、システムコントローラα_1126(あるいはβ_1128)から新規登録対象ユニット1290(複合モジュール1295、1460、1470)に向けて情報通信(送信)する。そしてこの情報を受け取る事で、受信側の新規登録対象ユニット1290(複合モジュール1295、1460、1470)はシステムコントローラα_1126(あるいはβ_1128)のIPアドレスIPADRSやメディア・アクセス層MAC02、MAC06内のアドレス(、及び初期設定時には受信側に設定されたIPアドレスIPADRS)を知る。
そしてその次のステップとして、新規登録対象(初期設定/プラグイン対象)のユニット1290(複合モジュール1295、1460、1470または機器1250−1)は上記の受信情報を利用して、システムコントローラα_1126(あるいはβ_1128)への送信を行う。この結果として初期設定/プラグイン対象のユニット1290(複合モジュール1295、1460、1470または機器1250−1)は正しいアドレス情報の取得が行われた事を確認できる。そしてシステムコントローラα_1126(あるいはβ_1128)は、新規登録対象(初期設定/プラグイン対象)のユニット1290(複合モジュール1295、1460、1470または機器1250−1)から送信される通信情報内記載内容を確認して正しく初期設定またはプラグイン処理がなされた事を確認した後に、図23のアドレステーブル内への正規登録処理を行う。
本実施形態では図8Bを用いて1.8節で説明したように、センサ/通信モジュール1460−5などの複合モジュール1295が単独で存在できる。あるいは特定の商品や部品内に挿入または混入した形で存在しても良い。従ってこの複合モジュール1295をユーザが携帯して移動が可能となる。そのためユーザに携帯された特定複合モジュール1295、1460、1470(または機器1250)も、初期設定後に異なるセクション1142間での移動が可能となる。すなわち単独で存在あるいは商品や部品内に挿入または混入した形で存在した形でユーザと一緒に移動可能な複合モジュール1295、1460、1470(または機器1250)は、図22のStep103のように移動位置を自動追跡され、図22のStep104が示すように移動後の現存場所が帰属するセクションの割り出しを繰り返し行えるようになっている。そして最新の配置情報に基付きセクション1_1142−1〜m_1142−m毎の複合モジュール1460、1470や機器1250からのセンス情報や状態情報を収集してユーザへのサービス提供(Step105)する事で、セクション1_1142−1〜m_1142−m毎の状態把握精度が向上し、ユーザの満足度が向上する効果が生まれる。
次に図22のStep103に記載した、ユニット1290(機器1250や複合モジュール1295、1460、1470)の移動位置の自動追跡方法に関する詳細説明を行う。このステップ103では4.4節で後述するように、対象のユニット1290(機器1250や複合モジュール1295、1460、1470)から送信される無線電波の送信元の位置検出の技術を利用しても良い。すなわちシステムα_1132内でのネットワーク回線1782(図10Aまたは図16)の物理的なメディア(通信媒体)として無線(wireless)を使用する場合には、ユニット1290(機器1250や複合モジュール1295、1460、1470)から無線電波を送信してシステムコントローラα_1126への情報通信が行われる。そしてシステムコントローラα_1126内で通信情報を解析する(例えば後述するように図13(b)内の送信側IPアドレス情報や送信側におけるIEEE拡張アドレスSEXADRSを抽出して図23のアドレステーブルを参照する)事で、物理層フレームPPDU(図11)毎にシステムα_1132内のどのユニット1290(機器1250や複合モジュール1295、1460、1470)から無線電波が送信されているかがリアルタイムで判別できる。それと同時に4.4節で後述する無線電波の送信元の位置検出技術を利用すると、物理層フレームPPDU毎にリアルタイムで無線電波送信元の物理的な位置情報が入手できる。こうして物理層フレームPPDU毎に両者の情報を突き合わせると、ユニット1290(機器1250毎あるいは複合モジュール1295、1460、1470)毎の物理的な位置情報が判明する。
このようにしてシステムコントローラα_1126は上記物理層フレームPPDUを受信する毎に、(前述した初期設定と同じ方法で)個々のユニット1290(機器1250や複合モジュール1295、1460、1470)が所属する(その中に配置された)セクション1_1142−1〜m_1142−mを判別する。そして判別した結果と図23のアドレステーブル内の記載内容と逐次比較する。そして比較結果に違いが無い場合には、『対応する機器1250や複合モジュール1460、1470はセクション1142を超えた移動をして無い』と見なして上記アドレステーブルの書き換えは行わない。一方比較結果に違いが見付かった場合には、特定の機器1250か特定の複合モジュール1460、1470がセクション1142を超えて移動したと見なして上記アドレステーブルを書き換えると共に、次のStep104へ進んでも良い。このように本実施形態では、『セクション1142に関係した情報(アドレステーブルなど)を所有』する所に大きな特徴が有る。そしてユニット1290(機器や複合モジュール)の移動位置自動追跡ステップ(Step103)では、上記セクション1142に関係した情報を利用してセクション1142を超えた移動の有無判定を行う。そしてStep103ではユニット1290(機器1250や複合モジュール1295、1460、1470)毎の配置場所管理をセクション1142単位で行うため、例えばユニット1290(機器1250や複合モジュール1295、1460、1470)が同一セクション1142内で僅かに移動しても『セクション1142を超えた移動をして無い』と見なしてアドレステーブルの書き換えなどの所定処理を行わない。これにより効率の良い情報収集とユーザに対するサービス提供が行える効果が有る。この効果を説明するため、ユニット1290(機器や複合モジュール)の僅かな移動に対して逐次フィーバックする方法と比較する。例えば特定の携帯形複合モジュールをユーザが身に着けた場合、ユーザが同一セクション1142内で移動する機会は頻繁に発生する。そしてこのユーザが僅かに移動する毎に(アドレステーブルの更新や次のStep104への移行処理などの)フィードバック処理を行うと、システムコントローラα_1126内での処理が非常に煩雑となる。一方4.1節内で図25(a)を用いて説明したように、同一セクション1142内でユニット1290(機器や複合モジュール)が僅かに移動しても、得られるセンサ情報内容に変化が起きない場合が多い。更に図25(b)で説明したように、ユーザに対してセクション1142単位でサービスを提供する場合が多い。従ってユーザが僅かに移動する毎にフィードバックを行っても、ユーザへ提供するサービス質の向上効率が余り上がらない。
図22のStep103によるユニット1290(機器や複合モジュール)の移動位置の自動追跡の結果、セクション1142を超えて移動したユニット1290(機器1250や複合モジュール1295、1460、1470)が発生した場合には、次のStep104へと進む。従ってセクション1142を超えた移動が無い場合には、このStep104を飛ばしてStep105へ進んでも良い。所でStep104内の具体的な“配置場所が移動したユニット1290(機器や複合モジュール)の現存位置が帰属するセクションの割り出し処理”とは、アドレステーブルの修正処理とシステムコントローラα_1126内で行われるセクション1_1142−1〜m_1142−m毎に配置されるユニット1290(機器1250や複合モジュール1295、1460、1470)の組み換え処理を意味している。
ここでこのアドレステーブルの修正時には所定枠内(セル内)の変更のみを行い、縦の列単位での並び替えは行わない。そしてセクション1_1142−1〜m_1142−m単位での状態管理やセンサ情報収集の効率を上げるため、システムコントローラα_1126のプロセッサ1230内の一時記憶領域に上記アドレステーブルをコピーし、セクション1_1142−1〜m_1142−m毎に配置されるユニット1290(機器1250や複合モジュール1295、1460、1470)の組み換え(縦の列単位での並び替え)処理を行っている。
また図22Step105内では、セクション1_1142−1〜m_1142−m毎に“対象となるユニット1290(機器や複合モジュール)からのセンサ/状態情報の収集またはユーザへのサービス提供”を行う。なおその具体的内容として、図26A〜図30を用いて4.2節で説明した方法を利用する。
その後は適宜ユニット1290(機器や複合モジュール)の移動位置の自動追跡(Step103)を行い、上記の一連の処理を繰り返す。
所で本実施形態システムでは、移動位置の自動追跡を利用して自動的に特定のユニット1290(機器1250や複合モジュール1295、1460、1470)に対する“プラグアウト”処理をしても良い。すなわちStep101で定義した各セクション1_1142−1〜m_1142−mの物理的領域範囲の外に出たユニット1290(機器1250や複合モジュール1295、1460、1470)を発見した場合には、“該当するネットワーク通信システムα_1132の管理対象外”になったと見なしてアドレステーブルからの該当項目(対応する縦の列全体)の暫定的削除を行う。但し将来の“再プラグイン”処理に柔軟に対応できるよう、暫定的に削除したユニット1290(機器1250または複合モジュール1295、1460、1470)のIPアドレスIPADRSとIEEE拡張アドレスEXADRSの情報はメモリ部1232(図8Aのシステムコントローラα_1126内)に記録しておく。ここで“プラグアウト”処理を行う直前に、ユーザI/F部1234(図8Aのシステムコントローラα_1126内)に表示してユーザへプラグアウト可否の問い合わせを行っても良い。
上記のプラグアウト処理の特徴をシステムα_1132(クライアントシステム)の視点で説明すると、下記の通りとなる。すなわち本実施形態システムであるクライアントシステムは情報を取得もしくは作成して通信する機能を有するユニット1290と前記ユニット1290からの前記情報を取得し管理するシステムコントローラα_1126とを備え、前記システムコントローラα_1126は複数のユニット1290をそれぞれセクション1_1142−1〜m_1142−mに区分して管理し、各ユニットが属する該セクションに関する情報(図23のアドレステーブル)を保持するとともに、前記ユニットに関する情報(図21D)を保持する。また前記ユニットからの前記情報の再取得できない場合には、前記システムコントローラα_1126は各ユニットが属する該セクションに関する前記情報(図23のアドレステーブル)の管理の対象から一旦外すことを特徴とする。
一方上述した再プラグイン処理では更なるクライアントシステムの特徴として上記に追加して前記ユニットからの前記情報の再取得ができた場合には、前記システムコントローラα_1126は各ユニットが属する該セクションに関する前記情報(図23のアドレステーブル)の管理対象とすることになる。
また上記のプラグアウト処理に関しても、アドレステーブルとして前記複数のユニット1290に関して第1のセクションに関する情報(すなわち第1のセクションに属するユニット1290の情報)及び前記第2のセクションに関する情報(すなわち第2のセクションに属するユニット1290の情報)を含む所に特徴が有る。
また更に上記のプラグアウト処理に関係してアドレステーブル内に前記情報が時系列情報として記録されている所にも次なる特徴が有る。
所で予めシステムα_1132内に配置されていたユニット1290(複合モジュール1295、1460、1470または機器1250)をシステムα_1132の外に移動させた後のシステムコントローラα_1126(あるいはβ_1128)からの通信履歴を調べることで、この“プラグアウト”処理の実行可否が分かる。すなわち“プラグアウト”処理が行われた場合、ユニット1290(複合モジュール1295、1460、1470または機器1250)をシステムα_1132の外に移動させた所定期間後は、このユニット1290(複合モジュール1295、1460、1470または機器1250)に対するシステムコントローラα_1126(あるいはβ_1128)からの情報通信は無い通信履歴となる。
すなわちネットワーク通信システムα_1132内の管理や運営、制御を行うシステムコントローラα_1126(あるいはβ_1128)は、同一システム内ネットワーク回線1782上での通信情報は、図11(f)の物理層フレームPPDU単位で送信元の配置位置をモニタしている。そしてシステムα_1132の外から物理層フレームPPDUが送信された場合には、(ユーザに確認した)直後に図23のアドレステーブルから該当するユニット1290(複合モジュール1295、1460、1470または機器1250)を削除してプラグアウト処理が完了する。一度プラグアウト処理が完了すると再度プラグイン処理を行うまで、システムコントローラα_1126(あるいはβ_1128)から該当するユニット1290(複合モジュール1295、1460、1470または機器1250)への情報通信は無い。
一方でタイミング的な関係で、システムα_1126の外に特定のユニット1290(複合モジュール1295、1460、1470または機器1250)が移動した事情をシステムコントローラα_1126(あるいはβ_1128)が一時的に認知しない場合が有る。この場合には、システムコントローラα_1126(あるいはβ_1128)から該当するユニット1290(複合モジュール1295、1460、1470または機器1250)宛てに情報通信する。しかしこの場合にはシステムコントローラα_1126(あるいはβ_1128)への回答が来ない。そして回答が来ない場合には再度情報通信を行い、2回連続して回答が来ない場合には、図23のアドレステーブル内の該当箇所を削除してプラグアウト処理が完了する。所で上記プラグアウト処理の途中で、システムコントローラα_1126内のユーザI/F部1234(図8A&図8B)を介してユーザへの問い合わせを行っても良い。
所でシステムα_1126の外に特定のユニット1290(複合モジュール1295、1460、1470または機器1250)を移動させてからプラグアウトを完了させる間での所要時間が長過ぎると、4.3節で後述するシステムα_1132やユーザの行動/要求の推定/判断精度が低下する。ここで状態変化に対応したサービス提供までの遅れ時間として、一般的ユーザは5分や10分程度までの遅れは許容する。また気の長いユーザなら15分程度の遅れは許容する。しかし遅れが1時間を超すと、ほとんどのユーザは不満に感じる。従って本実施形態システムにおいては、システムα_1126の外に特定のユニット1290(複合モジュール1295、1460、1470または機器1250)を移動させてからプラグアウトを完了させるまでの所要時間として15分以下、望ましくは5分以下としている。また上記の理由から、最悪の場合でも1時間以下とする。
このように『システムα_1132の物理的範囲の外に出たユニット1290(複合モジュール1295、1460、1470または機器1250)をプラグアウトする』所に大きな特徴が有る。このようにプラグアウト判定にユニット1290(複合モジュール1295、1460、1470または機器1250)の配置場所を利用する事で、ユーザに負担を掛けずに高い信頼性を保ちながら簡単にプラグイン操作が出来る効果が有る。すなわち同一システム内ネットワーク回線1782(図16)の物理的な通信媒体(communication media)に無線(wireless)を使う場合、誤って隣接する別ドメイン1122内のネットワーク通信回線と混線して個人情報保護機能が低下する恐れが有った。そして上記の危険性を回避するため、ユーザによる煩雑な初期設定処理やプラグイン/プラグアウト処理が必用となっていた。それに対し上述したように自動検出される配置位置情報を利用してユーザに負担を掛けずに初期設定処理やプラグイン/プラグアウト処理が行えると、隣接する別のネットワーク通信回線との混線が防げ、セキュリティ確保と個人情報保護機能確保が保証できる別効果も生まれる。
所で今まではシステムα_1132内に配置されたシステムコントローラα_1126が、図22に示す一連の処理を行うように説明した。しかしそれに限らず例えば1.8節内で説明した図8Aから図8Bが混在する形態を利用し、このシステムα_1132の空間的配置上外部に配置されたシステムコントローラβ_1128やサーバn_1116−nが図22の操作を行っても良い。
4.3節 セクション毎の情報収集からサービス提供までの処理方法
本4.3節では、図22のStep105に関係する“センサ/状態情報の収集からユーザへのサービス提供”に至る具体的処理内容の説明を行う。特にシステムα_1132(クライアントシステム)の視点から見た本4.3節で説明する特徴は下記の通りとなる。すなわち本実施形態システムであるクライアントシステムは 情報を取得もしくは作成して通信する機能を有するユニット1290と前記ユニットからの前記情報を取得し管理するシステムコントローラα_1126を備え、 前記システムコントローラα_1126は複数のユニット1290毎にセクション1_1142−1〜m_1142−mに区分して管理し、各ユニットが属する該セクションに関する情報(図23のアドレステーブル)を保持する。また1個のユニット1290からの状態変化情報が前記システムコントローラα_1126に通信され、その状態変化情報に基付いて前記同一セクション1142内の他の複数ユニット1290ユニットに対する制御が行なわれる特徴が有る。更に前記システムコントローラα_1126は、1個のユニット1290からの所定時刻毎の状態変化を用いて、前記同一セクション内の他のユニットの制御が行われる所に他の特徴が有る。
またそれだけでなく、上記特徴を図1示すサーバn_1116−n(クラウド)との関係から見ると、サーバクライアントシステムとして前記システムコントローラα_1126が外部のクラウド(サーバn_1116−n)に接続されており、前記システムコントローラα_1126は1個のユニット1290からの状態変化が前記システムコントローラα_1126に通信されるとともに前記クラウド(サーバn_1116−n)に送信する。そして前記クラウド(サーバn_1116−n)からの情報に基付いて前記同一セクション内の他のユニット1290に対して制御がなされる特徴が有る。
つまり本4.3節で説明される内容には、『収集した複数の情報を基にサービスの提供を行う』所に大きな特徴が有る。例えば収集した単一情報のみでは現状の状態あるいはユーザの行動や要求の推定/判断精度が落ちるため、ユーザが満足するサービス提供が難しい問題が有る。しかしここで説明するように、『複数情報を利用』する事で推定/判断の精度が上がるため、提供するサービスによるユーザ満足度が向上する効果が有る。
また一方では、『サービス提供時に、連携して複数の状態変更制御(設定状態の変更)を実施する』所にも大きな特徴が有る。ユーザの行動や要求に対応したサービス提供形態として、同一システムα_1132内での複数の状態変更制御(設定条件の変更)をすると、ユーザに対する木目細かな変更状態の提供ができるため、ユーザ満足度が向上する効果が生まれる。
システムα_1132から各種情報を収集し、サービス提供するまでのシステムコントローラα_1126内での処理プロセスを図26Aに示す。ここで図26Aのプロセスは、図2やまたは図8A/Bに示した実施形態システムを前提としている。しかしそれに限らず、図9のように上記システムα_1132の外に配置されたシステムコントローラβ_1128が情報収集/サービス提供を行っても良い。この場合には、下記の説明内のシステムコントローラα_1126をシステムコントローラβ_1128に変更する必用が有る。
まず始めにサーバn_1116−nまたはシステムコントローラβ_1128からのサービス実行依頼(Step110)を受けると、システムコントローラα_1126がシステムα_1132内からの情報収集(Step111)を開始する。ここで上記収集すべき情報は、センサ/通信モジュール1460からのセンサ情報に限らず、機器1250内の各種センサモジュール1260からのセンサ情報、駆動/通信モジュール1470内での現在の設定状態情報、機器1250(内の主に駆動モジュール1270)に対する現在の設定状態情報が含まれる。更にそれのみならずStep112に示すように、システムコントローラα_1126はサーバn_1116−nまたはシステムコントローラβ_1128から情報収集しても良い。このように一連の情報収集が完了すると、システムコントローラα_1126内で全ての収集した情報の統合整理を行い、必用な情報を内部のメモリ部1232内に保存する(Step113)。
そして次のステップとして同一システムα_1132内の状態を推定し、判断(Step114)する。またその推定/判断した状態に基付き、ユーザの現在の行動内容の推定と判断(Step115)を行う。ここで前記Step114の状態の推定/判断またはStep115のユーザの現在の行動に対する推定/判断には、例えばユーザの身長や身に付けている服や装飾品の色などのユーザ個々の状態の推定/判断も行われる。このユーザ状態を推定/判断が後のユーザへのサービス提供(Step119)に影響を与える一例として、タッチパッドや静電容量式ボタンの感度設定が上げられる。例えば指が太い大柄の大人では、タッチパッドや静電容量式ボタンの感度が低くても、安定したユーザ入力が可能となる。それに対して指の細い子供や女性ではタッチパッドや静電容量式ボタンの感度を上げないと対応できない場合が有る。従ってユーザ状態の推定/判断結果が、ユーザへのサービス提供に影響を与える。所でユーザの指の太さを推定/判断した後の、タッチパッドや静電容量式ボタンの感度設定変更には、2.5節で説明した通信情報を変更する。
そして上記のシステムα_1132内の状態/判断(Step114)結果とユーザの現在の行動推定/判断(Step115)結果を基に、ユーザの将来の行動予測(Step116)とユーザの要求推定/予測(Step117)を行う。
その後、上記一連の推定/予測結果をユーザI/F部1234(図8A、図8B)に表示し、ユーザへの問い合わせと確認(Step118)を行う。仮に上記一連の推定/予測結果が間違って場合には、Step114のシステムα_1132内状態の推定/予測からやり直す。またユーザへの確認内容が正しかった場合には、Step119のユーザへのサービスを提供する。そして適宜このユーザへのサービス提供までの一連の処理プロセスを繰り返す。また必用なタイミングで、サーバn_1116−nまたはシステムコントローラβ_1128に対して、上記のサービス提供を通知する(Step109)。
所で図26AのStep114〜Step117で実行される各種推定/判断処理は、Step111またはStep112で収集した複数情報を利用する所に本実施形態の特徴が有る。そして単一情報のみを使った推定/判断よりも、複数情報を用いることで推定/判断の精度が向上する効果が有る。その状況に関して、図26Bを用いて詳細に説明する。
システムα_1132内で状態が変化する場合や、ユーザが行動する場合には、
○ ユニット1290(機器1250や複合モジュール1295、1460、1470)のどれかが、セクション1142を跨って移動する状況や
○ ユニット1290(機器1250や複合モジュール1295、1460、1470)から得られる各種情報の内容が変化する状況
が発生する場合が多い。従ってシステムα_1132の中で、上記に該当するセクション1142だけ選択し、その該当セクション1142内だけ前述した一連の推定/判断処理を行うと、システムコントローラα_1126内での処理効率が上がる。そして上記2状況のいずれかが発生しているセクション1142を見つける処理が、図26BのStep120に対応する。またその該当セクション1142内に配置されているユニット1290(機器1250や複合モジュール1295、1460、1470)を抽出する作業が、Step121に対応する。ここでこのStep121では、図23のアドレステーブルを利用する。
そしてこのアドレステーブル内に記載されたセンサモジュール1260、駆動モジュール1270、センサ/通信モジュール1460、駆動/通信モジュール1470の中から、同一セクション1142内に配置された複数のモジュールに対して情報収集する。その具体例としては図10Bのケース2が示すように、システムコントローラα_1126から対象となる複数のモジュールに対してそれぞれ回答要求(リクエスト)1872を送信し、それに対する応答(レスポンス)1874を得る。
特に図26Bに示したユーザへのサービス提供方法としては、該当セクション1142毎に行った推定/決定結果に非適合する状態を自動抽出し、その非適合部分に対して状態変更制御や設定状態変更指示を行って適合処理する。このサービス提供方法の一例を以下に示す。例えば“ユーザが今まで居た部屋の照明とテレビを消して部屋を出て外出しようとした”時に、“照明を消された部屋のエアコンが動作状態のまま”の状態を非適合状態と自動抽出し、適合処理として“自動的にエアコンの動作状態を制御する”方法などが上げられる。ここで特に重要なのは、“ユーザが今まで居た部屋内のテレビを消した”と言う単一情報では“今後ユーザが何をしたいかが予想し辛い”所に有る。しかしそれに加えて更に“部屋の照明を消す”という同一セクション1142内の複数情報を収集する事で、推定/決定の精度が向上する。さらに本実施形態では上記のように『推定/決定した結果に非適合する状態を抽出』する事で、ユーザに対する効率の良いサービス提供が行える効果が有る。
そして上記の“ユーザが今まで居た部屋内のテレビを消す”と“ユーザが部屋の照明を消す”の例が、特定セクション内に配置されたユニット1290(機器1250や複合モジュール1295、1460、1470)からの各種センス情報収集と現在の状態情報の収集(Step122)に対応する。そして同一セクション1142内の複数情報を収集(Step122)した後、対応するセクション内の状態推定/決定(Step123)、ユーザ行動の推定/判断(Step125)とユーザ要求の推定/判断(Step127)を行う。そしてそれぞれの推定/判断結果に不適合する情報を抽出(Step124、126、128)し、抽出した不適合情報を推定/判断結果に適合させるための状態変化制御方法(設定状態の変更方法)をユーザに問い合わせる(Step129)。このユーザへの問い合わせは、システムコントローラα_1126内のユーザI/F部1234への表示を利用しても良い。ここでユーザに否定された場合には、収集した複数情報を用いた推定/判断(Step123、125、127)から再度やり直す。
ユーザへの問い合わせの結果としてユーザからの許諾を得た段階で、機器に内蔵された駆動モジュール1270または駆動/通信モジュール1470内の駆動モジュール1270に指令1852(図10Bのケース1)を与えて対応セクション1142内の状態変化を制御(状態の設定変更)してユーザへのサービス提供を行う(Step130)。
図26BのStep120に関連して、
○ セクション1142を跨って移動するユニット1290(機器1250や複合モジュール1295、1460、1470)の抽出 や
○ ユニット1290(機器1250や複合モジュール1295、1460、1470)から得られ、その内容が変化した情報の抽出に、
図27/図28(b)の時系列情報追跡表の左側を使用しても良い。この時系列情報追跡表とは、システムコントローラα_1126が収集した各種情報の履歴とそれに基付いて行った各種推定/判断の履歴を経過時刻2310に沿って時系列的に一覧表の形式で記録した情報で、適時追記してシステムコントローラα_1126内のメモリ部1232内に保存される。そして図27/図28(b)の記載例では図8Aの機器1250−1内での各種センサモジュール1260−1、2から得られる各種センサ情報または駆動モジュール1270−1に設定された状態(設定値)が、状態Aなどの形で全て記載されている。またこの機器1250−1が配置されているセクションの番号も記載されている。一方ではセンス情報として有無の2値で得られるセンサ/通信モジュール1460−5のセンス情報も、この時系列情報追跡表の左側に記載される。また4.4節で後述する方法で位置検出された結果得られる、このセンサ/通信モジュール1460−5が配置されるセクション番号も一緒に記載されている。
例えばこのセンサ/通信モジュール1460−5に光検出センサモジュールが内蔵され、このセンサ/通信モジュール1460−5を装着したユーザは照明が付いているセクション2_1142−2から照明が消えているセクション5_1142−5に移動した場合の例で説明する。この場合には経過時刻2310が“t3”の時点では、このセンサ/通信モジュール1460−5はセクション2_1142−2の中に配置されている。またこのセンサ/通信モジュール1460−5が検出する光情報は“有”になる。そして経過時刻2310が“t3”から“t4”の間にユーザが移動すると、移動後の前記センサ/通信モジュール1460−5はセクション5_1142−5の中に配置されている。またこの時に検出する光情報は“無”に変わる。このように時系列情報追跡表を使うと、機器1250や複合モジュール1460、1470のセクション1142を跨った移動や収集情報内容の変化の抽出が容易に行える。
所で図26AのStep114〜117と図26BのStep123,125、127で行う推定/判断処理には、図27/図28(a)の推定/判断照合表を使用する。まず例えば“所定のセクション内は使用状態”などのセクション1142毎の状態項目2320に関する推定/判断結果の候補を状態α、状態β・・・と事前に設定し、この推定/判断照合表の横の行方向に順次記載する。一方では例えば“エアコン動作が動作中”や“エアコンのタイマー設定時間”など、機器1250−1から情報として収集される状態を状態A、状態B・・・とし、この推定/判断照合表の縦の列方向に順次記載する。また更に例えば“明かりの有無”を検出するセンサ/通信モジュール1460−5から検出されるセンサ情報などセンサ情報や、駆動/通信モジュール1470−2で現在の状態を表す状態設定値も、この推定/判断照合表の縦の列方向に順次記載する。そして両者間の相関係数値が、この推定/判断照合表内の該当セル内に記載されている。この相関係数値として例えば、“エアコン動作が活動中”の状態Aと“所定のセクション内は使用状態”などの状態項目2320内の状態αとの間に正の相関が有る場合には、その相関係数値として“80”が該当セル内に記載される。さらにセンサ/通信モジュール1460−5から得られる同一セクション1142内での“明かりが有る”情報と“所定のセクション内は使用状態”などの状態項目2320内の状態αとの間に正の相関が有る場合にも、その相関係数値として“57”が該当セル内に記載される。一方では負の相関(逆相関)が有る場合には、相関係数として負値が該当セル内に記載される場合が有る。
そしてセクション1142内での状態推定/判断時には、各状態α、β、・・毎に同一列内の相関係数の合計を算出し、状態確率2330の値に対応させる。そして最も合計値が高い状態α、β、・が、該当するセクション1142内での状態を示すと推定/判断する。このように同一列内の相関係数の合計値を算出する事で、唯一の収集情報では無く、同一セクション1142内の複数の収集情報を利用できる。そのように複数の収集情報を利用する事で多角的な推定/判断が出来るだけで無く、推定/判断の精度が上がる効果が有る。
同様にユーザの行動項目2440に関する推定/判断結果の候補を行動α、行動β・・・と事前に設定し、この推定/判断照合表の横の行方向に順次記載する。更にユーザの要求項目2360に関する推定/判断結果の候補も要求α、要求β・・・と事前に設定し、この推定/判断照合表の横の行方向に順次記載する。更に上記と同様に各相関係数値を該当セル内に記入する。
更に経過時刻2310としてt1、t2、t3、・・毎に各行動α、βの列及び要求α、βの列毎に相関係数の合計値を算出し、行動確率2350や要求確率2370の値として図27/図28(b)時系列情報追跡表の右側の該当箇所に逐次記入する。
そして上記の時系列情報追跡表を利用する事で、リアルタイムでセクション1142内での状態やユーザの行動や要求を推定/判断できる。例えば図27/図28(b)に示した例で、この時系列情報追跡表を用いたサービス提供方法の一例を説明する。例えばユーザがセンサ/通信モジュール1460−5を携帯したまま、照明が付いているセクション2_1142−2から照明が消えているセクション5_1142−5に移動した場合を考える。この場合セクション2_1142−2内の照明が付いたままなので、セクション2_1142−2内の“該当セクション内は使用状態”を表す状態αの状態確率2330の値に変化は余り見られない。それに比べると“ユーザの移動”に対応した行動αの行動確率2350はt3とt4の間に4%から87%への急上昇している。その結果、“t3とt4の間にユーザが移動した”と推定/判断できる。さらに“セクション5_1142−5の照明を付けたい”と言う要求に対応した要求αの要求確率も、t3とt4の間に4%から98%へ急上昇している。
そしてこの時系列情報追跡表を活用すると、例えば“セクション5_1142−5の照明を付けたい”と言う図26BのStep127に示したユーザ要求の推定/判断の結果が得られる。所でこのユーザ要求に不適合な情報として、センサ/通信モジュール1460−5から“セクション5_1142−5内は明かりが無い”と言う情報が得られる。そしてその対応として、Step130のユーザへのサービス提供を行う。この具体的内容としては、“セクション5_1142−5内の照明を付ける”作用をする駆動/通信モジュール1470−2に対してシステムコントローラα_1126から設定状態変更の指令(コマンド発行)1852(図10B参照)が出される。
上記では主にセクション1142毎の内部での状態推定/判断や、セクション1142毎に収集した情報を基にしたユーザ行動の推定/判断やユーザ要求の推定/判断に関する説明を行った。しかしそれに限らず他の実施形態として、例えばシステムα_1132全体の状態に関して推定や判断を行っても良いし、あるいはシステムα_1132全体から収集した情報を基にユーザ行動の推定/判断やユーザ要求の推定/判断を行っても良い。
次に図26AのStep119または図26BのStep130に記載したユーザへのサービス提供方法に付いて、図29を用いて説明する。まず図26BのStep124、126、128で行った不適合情報の抽出結果に基付き、対応するセクション1142内のユニット1290(機器1250や複合モジュール1295、1460、1470)内での状態変更制御候補の抽出(Step141)を行う。その後でユーザへの問い合わせ(Step129)をした後に、Step142からStep143に示すように順次設定状態の変更(状態変化制御)を実行する。
ここで上述した例としてユーザ移動先のセクション5_1142−5で照明が消えている場合、エアコンやテレビも停止状態になっている事が有る。従って図26BのStep124、126、128で不適合情報を抽出した場合、同一セクション5_1142−5で複数項目に関して設定状態の変更(状態変化制御)を行う必用が有る。その場合には図29のStep142からStep143に示すように、上記複数項目に関して順次設定状態の変更(状態変化制御)を行うか、その中の一部の項目に対して同時に設定状態の変更(状態変化制御)を行う所に大きな特徴が有る。その結果、同一セクション5_1142−5内での最適環境設定までの時簡を短縮できる効果が有る。
所でこのように複数項目に関して順次または同時に設定状態の変更(状態変化制御)を行う場合には図10Bのケース1が示すように、同一のシステムコントローラα_1126から複数のユニット1290(駆動/通信モジュール1470あるいは機器1250)に対して順次または同時に複数の指令(コマンド発行)1852に対応した情報通信を行う。所で複数の各指令(コマンド発行)1852に対応した通信情報を示す各物理層フレームPPDU(図11(f))内では、全て送信側IPアドレス情報SIPADRS(図13(b))の内容と、通信ミドルウェア層APL02、APL06内の送信側アドレス情報(例えば図12A(e)の送信側におけるPAN固有の識別情報SPANIDと送信側におけるIEEE拡張アドレスSEXADRSの内容)が一致している。また更に図12A(e)の受信側におけるPAN固有の識別情報DPANIDなど一部受信側の情報も一致している場合が有る。
従って複数項目に関して順次または同時に設定状態の変更(状態変化制御)を行う場合には、システムコントローラα_1126(あるいは図9に示すシステムにおけるシステムコントローラβ_1128)内で途中に別の処理を入れず、纏めて上記に対応する指令(コマンド発行)1852に対応した情報通信を行うのが望ましい。このように纏めて情報通信を行うと、上述した共通情報のコピー処理で異なる複数の通信情報を作成できる。従って上記の方法を使う事でシステムコントローラα_1126(あるいは図9に示すシステムにおけるシステムコントローラβ_1128)の処理効率が向上する効果が有る。
既に4.2節内で、「状態変化に対応したサービス提供までの遅れ時間として、一般的ユーザは5分や10分程度までの遅れは許容する。また気の長いユーザなら15分程度の遅れは許容する。しかし遅れが1時間を超すと、ほとんどのユーザは不満に感じる」状況を説明した、従って本実施形態システムにおいては、複数項目に関するサービスを順次行う場合には、続けて提供するサービス間の時間差として15分以下、望ましくは5分以下とし、最悪でも1時間以内とする。それによりユーザに与えるストレスを最小限に食い止める効果が有る。
上記では主にセクション1142毎のサービス提供を中心に説明して来た。しかしそれに限らず他の実施形態として、例えばシステムα_1132全体を纏めてサービス提供しても良い。
既に上記では「ユーザがセンサ/通信モジュール1460−5を携帯したまま、照明が付いているセクション2_1142−2から照明が消えているセクション5_1142−5に移動した」例を上げてサービス提供方法に付いて説明した。それに関し、特定のユニット1290(機器1250や複合モジュール1295、1460、1470)が異なるセクション1142間を跨って移動した場合の処理方法に関する補足説明を行う。
この場合には図30のStepが示すように、上記ユニット1290(機器1250や複合モジュール1295、1460、1470)の移動前後のセクション情報を抽出する必用が有る。この抽出には、前述した図27/図28(b)の時系列情報追跡表が役立つ。ここで図27/図28(b)のセンサ/通信モジュール1460−5のセクション列では、経過時刻2310t3とt3の間で“2”から“5”に変化している。この変化場所を探す事で、容易に移動前後のセクション情報が抽出できる。この場合には特に移動前後のセクションに関してサービス提供する場合が多い。従って特定のユニット1290(機器1250や複合モジュール1295、1460、1470)が移動した前後のセクション2_1122−2と5_1122−5の両方内に対して同時または順次にサービス提供する所に本実施形態システムの特徴が有る。このようにシステムコントローラα_1126(あるいは図9のシステムに対応した場合のシステムコントローラβ_1128)は移動前後のセクション2_1122−2、5_1122−5を集中的にサービス提供する事で、効率良くユーザに対するサービス提供が行える。ここで図30のStep155からStep158に至る一連の処理プロセスは、図26B内での処理プロセスと一致している。更に図30のStep151が示すように、移動前セクション2_1122−2内に配置されたユニット1290(機器1250や複合モジュール1295、1460、1470)の抽出を行う。そして同様の処理プロセスを経て、移動前セクション2_1122−2内に対してもユーザへのサービス提供(Step130)を行う。また既に上述したように、移動前セクション2_1122−2内でも複数項目に関して順次または同時に設定状態の変更(状態変化制御)を行っても良い。
また前後のセクション2_1122−2と5_1122−5の両方内に対して同時または順次にサービス提供する場合も上述したように、システムコントローラα_1126(あるいは図9に示すシステムにおけるシステムコントローラβ_1128)内で途中に別の処理を入れず、纏めて上記に対応する指令(コマンド発行)1852に対応した情報通信を行うのが望ましい。このように纏めて情報通信を行うと、上述した共通情報のコピー処理で異なる複数の通信情報を作成できる。従って上記の方法を使う事でシステムコントローラα_1126(あるいは図9に示すシステムにおけるシステムコントローラβ_1128)の処理効率が向上する効果が有る。
4.4節 各種モジュールや各種機器のセクション間移動追跡方法
本4.4節では、機器1250に内蔵された通信モジュール1202や複合モジュールに内蔵された通信モジュール1660が配置された位置を検出する方法に付いて説明する。
所で図10Aの同一システムネットワーク回線1782上で使用される物理的な通信媒体(communication media)に無線(wireless)を使用する場合、上記通信モジュール1202、1660から無線電波が放出される時期が存在する。そしてこのタイミングを利用し、『無線電波の放出位置から通信モジュール1202、1660あるいはそれらが内蔵される装置や複合モジュールの位置を検出する』所に本実施形態の特徴が有る。従来の装置位置の検出方法としてGPS技術が知られている。しかしこの技術を採用する限り、装置に搭載するGPS関連部品だけ高価になる。それに比べて上記の方法では位置検出に必要な付加部品が一切不要なため、通信モジュール1202、1660(あるいはそれらが内蔵される装置や複合モジュール)の低価格化と小形化が可能になる効果が有る。
また位置情報を知る上記のGPS技術以外に、ビーコン(Beacon)と言う技術が知られている。GPS技術では、人工衛星から出射される電波を利用している。それに比べて上記のビーコン技術では、例えば Bluetooth と呼ばれる近距離無線規格で使われる地上の無線電波を利用する。すなわち地上の複数箇所に上記の近距離無線電波を送信する機器が複数台設置され、それぞれの機器から送信される近距離無線電波を受信して、相対的な受信場所を算出する。しかしこの方法でも受信側で位置を割り出す回路が必要となるため、受信機の回路規模が増大して受信機の大形化と価格上昇が発生する。それに比べて本実施形態システムでは位置検出が必要となる複合モジュール1295(またはユニット1290)内での自主的な位置検出が不要なため、対象となる複合モジュール1295(またはユニット1290)の低価格化と小形化が可能となる。
本実施形態における位置検出原理を図31に示す。ここで上記無線電波を受信して送信元の位置を検出するシステムコントローラα_1126や機器1250−1、4には、それぞれGPS機能が内蔵されている。そのため、システムコントローラα_1126や機器1250−1、4の設置場所は予め分かっている。そしてこれらシステムコントローラα_1126や機器1250−1、4が受信する時の無線電波特性を利用して、無線電波の放出位置を測定する。
そして位置検出に関与する受信側(システムコントローラα_1126や機器1250−1、4)での『無線電波の受信時期(受信タイミング)を位置検出に利用』する所に次の特徴が有る。そして『複数の無線電波送信元が存在するネットワーク通信システムにおいて、無線電波の受信時期(受信タイミング)を利用して送信元を識別』する。あるいは『複数の無線電波送信元が存在するネットワーク通信システムにおいて、通信情報内容を利用して送信元を識別』すると言っても良い。例えば図31の記載例において、センサ/通信モジュール1460−5と駆動/通信モジュール1470−3では、無線電波を放出するタイミングが互いに異なる。従って受信タイミングに拠り、センサ/通信モジュール1460−5と駆動/通信モジュール1470−3のどちらから放出された無線電波かが識別できる。このように無線電波の受信タイミングを位置検出に利用する事で、同時期に異なる複数位置の検出が行え、位置検出の効率が向上する効果が有る。一方本実施形態における位置検出方法は上記に限らず、他の方法としてビーコン(Bluetooth Smart規格に準拠)からの信号を利用しても良い。
具体的な無線電波の送信元識別方法を説明する。同一システムネットワーク回線1782上では、図11(f)に示す物理層フレームPPDUの塊単位で情報通信する。ここで異なる複数の送信元から送信される物理層フレームPPDUが同時期に重複しないように、システムコントローラα_1126が上記のシステムネットワーク回線1782上を制御あるいは管理している。
また上記1個の物理層フレームPPDU内には送信元を示すアドレス情報が格納されている。具体例として2.4節で説明した図13(b)の送信側IPアドレス情報SIPADRSを送信元識別に利用できる。またそれに限らず、MAC層ヘッダMACHD(図11(a))内に格納された情報として、例えば2.3節で説明した図12A(e)の送信側におけるIEEE拡張アドレスSEXADRSを送信元識別に利用しても良い。従って無線電波の受信側で受信時の無線電波特性を測定すると共に、対応する物理層フレームPPDU内に記載された送信元アドレス情報を解読する。これにより、無線電波送信元毎の無線電波特性を取得できる。
更に『同時に受信した複数箇所での無線電波特性を比較して、送信元の位置情報を算出』する所に、更なる特徴が有る。このように複数箇所での無線電波特性を利用する事で、位置検出精度が向上する効果が有る。ここで送信元の位置検出に利用する無線電波特性として、“電波強度”を利用する方法が有る。すなわち理想状態では、受信場所での電波強度は送信元との距離の二乗に反比例する。従ってシステムコントローラα_1126及び機器1250−1、4毎の受信電波強度を比較すると、センサ/通信モジュール1460−5や駆動/通信モジュール1470−3の相対位置情報が推定できる。
また送信元の位置検出に利用する他の無線電波特性として、“電波位相”を利用しても良い。すなわち送信元と受信相手の距離に応じて受信時の無線電波の位相が異なるので、この現象を位置検出に利用する。そしてシステムコントローラα_1126及び機器1250−1、4が同時に受信した時の無線電波の位相を比較する事で、センサ/通信モジュール1460−5や駆動/通信モジュール1470−3の相対位置情報が推定できる。
しかし上記に限らず、送信元の位置検出に利用する別の無線電波特性として、“電波の進行方向”を利用しても良い。この電波の進行方向を検出する方法として、『電波の進行方向に対して検出感度が異なる複数の受信部から得られる各検出信号を比較して、電波の進行方向を測定』する所に本実施形態の特徴が有る。また更にここで得られた送信元から放出された無線電波の進行方向から、『三角法を用いて位置検出』する所に、次の特徴が有る。この実施形態を利用すると、非常に安価な設備で精度良く送信元の位置検出が出来る効果が有る。また本実施形態で位置検出に利用する無線電波特性として“電波の進行方向”のみに限定せず、受信強度や受信時の位相あるいは他の無線電波特性と組み合わせても良い。
例えば図31のシステムコントローラα_1126と機器1250−1が個々に、センサ/通信モジュール1460−5から送信される無線電波の進行方向が検出できれば、『三角法』を利用して容易かつ精度良く送信元の位置検出が出来る。ここで三角法を使用する限り、上記無線電波の受信点は最低2点有れば位置検出可能となる。所で (1)システムコントローラα_1126がシステムネットワーク回線1782上の情報通信の管理/運営/制御を行う、(2)システムコントローラα_1126は常に物理層フレームPPDU内の情報解析を行う、(3)無線電波特性の検出場所と送信元位置の算出場所は物理的に近い方が効率良い との理由から、このシステムコントローラα_1126が上記の無線電波受信点の一つを担うのが望ましい。そして別の無線電波受信点としてGPS機能が内蔵された一般的な機器1250を使用しても良いし、送信元位置検出用専用装置を設置しても良い。
次に図32(b)を用いて、原理的な電波の進行方向測定方法を説明する。一例として地上波受信などに用いられるポラボラアンテナ2760の検出感度には、受信電波の方向依存性が有る。例えば検出信号αが得られるポラボラアンテナ2760は、受信電波がAの方向から来る時に最も検出感度が高く、BやCの方向から来る受信電波に対する検出感度は低い。このようにポラボラアンテナ2760は、『電波の進行方向に対して検出感度が異なる』特性を有する。一方では検出信号βが得られるポラボラアンテナ2760は受信電波がBの方向から来る時に最も検出感度が高く、検出信号γが得られるポラボラアンテナ2760は受信電波がCの方向から来る時に最も検出感度が高い。従って任意の方向から到着する受信電波を3個のポラボラアンテナ2760で同時に受けて、検出信号α、β、γ間の強度を比較する事で、原理的には受信電波の進行方向を予測できる。この受信電波の進行方向を予測する処理が、『複数の受信部から得られる各検出信号を比較して電波の進行方向を測定する』方法に対応する。
より方向精度の高い方向検出用アンテナ構造を図32(a)に示す。この基本構造は、略三角錐または略四角錐形状に構成されたステルス板2730から構成されている。そしてこの略三角錐または略四角錐の側面に、十字形にアンテナ2710−1が配置されている。このアンテナ2710−1は、互いに直交した一組のアンテナから構成される。ここで図32(a)の実線で示すように、ステルス板2730の一つの側面上に一組だけの十字形に直交したアンテナ2710−1のみを配置しても良い。またそれに限らず、図32(b)の破線で示すように、ステルス板2730の一つの側面上に複数組の十字形に直交したアンテナ2710−1〜3を配置しても良い。ここで図32(b)の破線示したアンテナ2710−2、3は、十字形に直交したアンテナ2710−1に対して30度ずつ回転して取り付けられている。この十字形に配置されたアンテナ2710−1を用いて、A)システム内ネットワーク回線1782上の通信情報の受信と、B)送信元の位置検出 の両方を行う。ここで十字形に配置された各アンテナ2710−1〜3の間には、アンプ及び信号処理回路2720が配置されている。また各アンプ及び信号処理回路2720からは、個々に検出信号α、β、γ、δが得られる。所できちんと三角錐や四角錐の形状になっている必要は無く、複数のステルス板2730側面が互いに異なる方向を向いていれば良い。
所で図32(a)におけるステルス板2730の側面上に配置された十字形アンテナ2710の検出感度には受信方向依存性が有る。従って一組の十字形アンテナ2710が、上記の『電波の進行方向に対して検出感度が異なる受信部』に対応する。そして各アンプ及び信号処理回路2720から得られる個々の検出信号α、β、γ、δ間の比較が、上記の『各検出信号の比較』に対応する。
図32(a)の1個の側面を拡大した図を図33(a)に示す。十字形アンテナ2710の裏側に配置されたステルス板2730は、(1)十字形アンテナ2710への裏側からの電波の侵入を防止し、(2)十字形アンテナ2710を通過した電波を吸収する役目を果たす。このように『電波の進行方向を検出するアンテナ2710』の裏側にステルス板2730を配置する事で、検出精度を低下させる不要な電波の反射を抑えて送信元の位置検出精度を向上させる効果が有る。この効果を発揮するため、図33(b)のように前記ステルス板2730は2層構造を持つ。この奥側の層は表面が微細な凹凸構造を持つ金属板層2734から構成されている。このように奥側に金属板層を配置する事で強固に電波の透過を防止して、裏側からの十字形アンテナ2710への電波の侵入を防止している。
しかし金属板層2734表面では電波の反射が起きる。従ってここで反射された電波が十字形アンテナ2710へ入らないように、数々の工夫がなされている。その一つの工夫が、図33(c)のように、略三角錐または略四角錐形状の側面を曲面にしている。このように曲面にする事で、略平行入射した入射電波2800の進行方向を入射位置で変化させる。更に金属板層2734の表面に微細な凹凸構造を持たせて、略平行入射した入射電波2800を乱反射させている。
所で上記ステルス板2730の本来の目的(2)は、電波を反射させる事では無く電波を吸収させる所に有る。この機能(2)を実現するため、ステルス板2730内の表面が微細な凹凸構造を持つ金属板層2734の上部に表裏面共に微細な凹凸構造を持つ弱導電性有機層2738を配置している。この表裏面共に微細な凹凸構造を持つ弱導電性有機層2738の詳細な構造として、金属粉を有機層で固めた構造にしても良いし、全体を弱導電性有機物で形成しても良い。そしてこの弱導電性有機層2738内で入射電波2800を吸収させる。しかしこの弱導電性有機層2738内だけでは完全に入射電波2800を吸収できないので、凹凸形状した表面上で入射電波2800を乱反射させている。更に表裏面共に微細な凹凸構造を持つ弱導電性有機層2738と表面が微細な凹凸構造を持つ金属板層2734との間で乱反射効率を上げると共に、ここで乱反射した電波を弱導電性有機層2738内で吸収させて十字形アンテナ2710に到達するのを防いでいる。
図32(a)に示した十字形アンテナ2710−1の詳細構造と検出信号特性に関する原理に付いて、図34を用いて説明する。上記十字形アンテナ2710の内部構造は図34(a)に示すように、横方向(X方向)に配置した2本のアンテナ2710間を抵抗器2920で接続した構造と、縦方向(Y方向)に配置した2本のアンテナ2710間を抵抗器2920で接続した構造から組み合わされている。所で2本のアンテナ2710間の接続には抵抗器2920のみで無く、信号検出の周波数特性を向上させるためにコンデンサやインダクタンスを適正に配置しても良い。そしてアンプ及び信号処理回路2720内は、各抵抗器2920間に発生した電圧差を検出する電圧差分器2940−1、2と、それぞれから得られる各信号を加算する加算器2960から構成されている。
例えば図32(b)のように横軸(X軸)に対して偏波面がθだけ傾き、電場振幅Aを持つ無線電波が、前記の十字形アンテナ2710に対して垂直方向に通過した場合、電圧差分器2940−1からは
A2ei2ωtcos2θ (1)
の信号が得られ、電圧差分器2940−2からは
A2ei2ωtsin2θ (2)
が得られる。この(1)式と(2)式では、検出信号の位相項を複素数表示で表している。従って上記の各信号を加算した加算器2960からの出力信号は
A2ei2ωt (3)
となる。この(3)式に偏波面の傾き角θが現れない所に大きな特徴が有る。すなわち前記の十字形アンテナ2710に対して無線電波が垂直方向に通過する限り、得られる検出信号は偏波面の傾き角θに依存せずに一定特性が得られる事が分かる。
更に図34(c)が示すように、前記の十字形アンテナ2710の垂直方向からξだけ傾いた角度で無線電波が通過した時の加算器2960からの出力信号は
A2ei2ωtsin2ξ (4)
で与えられる。そして上記(4)式は、前記の十字形アンテナ2710に対する無線電波の進行方向(十字形アンテナ2710の垂直方向からの傾き角)に拠って上記加算器2960の出力信号が変化する事を示している。従って図32(a)のように互いに異なる方向を向くステルス板2710上に配置された各十字形アンテナ2710から得られる(加算器2960の)出力信号α、β、γ、δ間を比較し、上記(4)式を適用する事で、無線電波の進行方向を算出できる。
所で図34(c)において傾き角ξが特に小さい場合には、出力信号量に無線電波の振動面依存性が大きく出易い。その弊害を軽減するため、図32(a)の破線で示した互いに回転角を持つ十字形アンテナ2710−2、3の組を複数配置している。そして個々の十字形アンテナ2710−1〜3で得られる出力信号の中で、他の出力信号と大きく異なる出力信号のみ破棄し、残りの2出力信号の平均を取る事で、傾き角ξが小さい場合の検出信号誤差を軽減できる。
上記の(3)式が示すように、アンテナ2710間を直角に配置すると(偏波面の影響を受けずに)効率良く無線電波の進行方向を測定できる。しかしそれに限らず(無線電波の進行方向算出時に何らかの補正を加えるなら)、アンテナ2710間を任意の角度で配置しても良い。さらにアンテナ2710の形状として上述した直線形状に限らず、図34(d)のような“リーフ形状”など他の形状を取っても良い。
なお無線電波の進行方向から送信元の位置検出を行う方法では、壁や天井などの無線電波の進行経路途中での反射により検出精度が低下する場合が有る。この対策として、異なる複数の周波数帯の無線電波を位置検出に利用しても良い。例えば近距離無線通信に使用される基準周波数として、2.4GHzと915MHzや950MHz、868MHzの周波数帯が地域によって使用可能となっている。従って例えば上記の異なる基準周波数での無線通信を並行して行っても良い。所で壁や天井などの無線電波の進行経路途中での反射特性は、使用する基準周波数により変化する。そのため異なる基準周波数での無線通信を使用したそれぞれの位置検出結果を比較すれば、送信元の位置検出精度が向上する。
また位置検出に三角法を用いると、基本的には2箇所で無線電波の進行方向を測定するだけで送信元の位置検出が可能な事を前述した。しかし無線電波の進行経路途中での反射による位置検出精度低下防止を考慮して、3箇所以上の受信点で無線電波の進行方向を測定しても良い。このように3箇所以上の受信点での測定結果を比較して、送信元の位置検出精度と信頼性を上げる。更に上記のいずれか一方のみで無く、位置検出用の受信点の増設と使用する基準周波数を増やす方法を組み合わせても良い。このように上記の工夫により、送信元の位置検出精度が向上する効果が有る。
4.5節 ユニット(複合モジュールや機器)の異なるシステム間での適合性
本実施形態システムにおけるシステムα_1132は、民生分野に適用したシステムやヘルスケア分野に適用したシステムから社会インフラ分野に適用したシステムに至る幅広い範囲でのネットワーク通信システムに適用できる特徴が有る。更に本実施形態システムでは4.2節で説明したように、ユニット1290(機器1250や複合モジュール1295、1460、1470)のシステムα_1132内への初期設定(Check-in)やプラグイン、プラグアウトが非常に簡単に行える特徴が有る。そして上記の特徴を組み合わせると、本実施形態システムでは『ユニット1290(機器1250や複合モジュール1295、1460、1470)を種類の異なる複数のシステム内に容易に組み込んで使用可能』な新たな特徴が生まれる。そして更に『同一のユニット1290(機器1250や複合モジュール1295、1460、1470)を異なる複数のシステムに跨って転用(流用)可能』にもなる。
従って本実施形態システムを利用する事で、非常に幅広い適用分野に対するユニット1290(機器1250や複合モジュール1295、1460、1470)の汎用性が確保できる効果が生まれる。特に複合モジュール1295、1460、1470が非常に幅広い適用分野への汎用性を持つと、量産効果による複合モジュール1295、1460、1470の低価格化が容易となる。そして更に低価格な複合モジュール1295、1460、1470が異なる複数のシステムに跨って使用出来るので、複合モジュール1295、1460、1470の使い勝手が大幅に向上する効果も生まれる。
同一のユニット1290(機器1250や複合モジュール1295、1460、1470)が跨って使用される複数のシステムα_1132とシステムβ_1134間の関係は、図1に示すように同一ドメイン2_1122−2内に含まれても良い。しかしそれに限らず、上記複数のシステムα_1132とシステムβ_1134間は、それぞれ別のドメイン1_1122−1とドメイン2_1122−2に所属しても良い。
本4.5節では、複数の異なるシステムα_1132とシステムβ_1134間でのユニット1290(機器1250や複合モジュール1295、1460、1470)の初期設定(Check-in)やプラグイン、プラグアウト方法に付いて説明する。
始めに上記システムα_1132とシステムβ_1134間で機能が異なる場合に付いて説明する。この場合には、システムα_1132内のシステムコントローラα_1126とシステムβ_1134内のシステムコントローラβ_1128が個々にユニット1290(機器1250や複合モジュール1295、1460、1470)に対するシステム適合/非適合の識別処理を行う。所でこのシステム適合/非適合の識別対象が機器1250の場合には、図16あるいは図17Bを用いて2.1節で説明したように通信ミドルウェア層APL06で交換情報1810(図10B参照)を交換して識別する。一方このシステム適合/非適合の識別対象が複合モジュール1295、1460、1470の場合には、図10Aを用いて2.1節で説明したように、メディア・アクセス層MAC02内の通信情報を利用して識別する。例えば図12A(e)を用いて2.3節で説明したように、複合モジュール1295、1460、1470から送信される通信情報内に含まれる送信側におけるIEEE拡張アドレスSEXADRSを利用しても良い。この場合には、得られたIEEE拡張アドレスSEXADRSの情報からインターネット経由でサーバn_1116−nにアクセスして複合モジュール1295、1460、1470の素性情報を入手し、システム適合/非適合の識別を行っても良い。
上記の処理の結果、対応するユニット1290(機器1250や複合モジュール1295、1460、1470)がシステム適合と判断された場合、ユーザI/F部1234(図2や図9あるいは図8A/B)を介してエンドユーザに対応システムに組み込んで良いか確認する。
始めに上記システムα_1132とシステムβ_1134間で機能が一致する場合には、4.2節で説明したように、ユニット1290(機器1250や複合モジュール1295、1460、1470)が配置された場所情報を利用してシステム適合/非適合の識別を行う。
次に同一のユニット1290(機器1250や複合モジュール1295、1460、1470)が複数のシステムα_1132やシステムβ_1134等に跨って使用される場合に発生する状況と、その対処方法に付いて説明する。ユニット1290の例として複合モジュール1295がシステムコントローラβ_1128との間で情報通信する場合に使用される通信ミドルウェア層APL02として、図17Aに示すようにC−フォーマットを使用しても良い。またそれに限らず、通信ミドルウェア層APL02として他のフォーマットを複合モジュール1295との間の情報通信に使用しても良い。一方、ユニット1290の他の例として機器1250がシステムコントローラβ_1128との間で情報通信する場合に使用される通信ミドルウェア層APL06は、図17Bに示すようにA−フォーマットあるいはE−フォーマット、W−フォーマットを使用しても良く、また更に拡張アプリケーション層EXL06を使用しても良い。このように通信ミドルウェア層APL02、APL06で使用されるフォーマットは、使用されるユニット1290(機器1250や複合モジュール1295、3583)に拠って異なる状況が許容される。
図36Aは、種々のユニット1290(複合モジュール3583)と相互通信が可能なシステムコントローラ3581の構成例を示す。図36Aでは説明の容易性から、各種処理実行部をハード形態の繋がりで示した。このようにシステムコントローラ3581内の構造がハード形態の繋がりから構成されても良い。またそれに限らず図2に示すようにシステムコントローラα_1126内がプロセッサ1230とメモリ部1232から構成されている場合には、図36Aに示すインターネット接続部3581a〜インターネット整合データ出力部3581gがプロセッサ1230内で実行される処理フローに対応する。
ユニットあるいはその一例である複合モジュール3583としては、それぞれ異なるメーカにより開発された複数の複合モジュール3583が存在する。そして更に複合モジュール3583毎に通信ミドルウェア層APL02上で異なるフォーマット(規格)の使用が許容される。そのためには同一のシステムコントローラ3581が種々の複合モジュールと相互通信が可能なように、通信ミドルウェア層APL02上での異なる複数のフォーマット(第1の通信規格〜第nの通信規格)への対応が可能になっている特徴が有る。それを可能にするため、システムコントローラ3581内の通信規格認識部3581c内で異なる通信規格を識別し、識別結果に応じて通信規格に応じた適正な処理を行う。それに拠りシステムコントローラ3581の対応汎用性が向上し、異なるメーカにより開発された複数の異なる複合モジュール3583との間の情報通信が可能になる効果が生まれる。
所で2.1節の中で説明した通信ミドルウェア層APL02、APL06で使用される各種フォーマットには、
○A−フォーマットは『広義のテキスト形式で記述』されており、
○C−フォーマットは『コマンド/リクエスト/レスポンス/ステータス』形式
○E−フォーマットは『予め規定された所定領域内に設定コードを格納』する形式
○W−フォーマットは『指定欄に送信側が記入』形式または『HTML/HTML5固有“タグ”が記載』されている
の特徴が有る。従って通信ミドルウェア層APL02、APL06に記載された情報(図11の通信ミドルウェアデータAPLDT内に記載された情報)を解析し、上記のどの特徴に該当するかを判断する事で該当する通信規格を識別できる。
図17Aの実施例が示すように、複合モジュール3583はアクセスポイント3584a及び又は基地局3584bを介してインターネット3585と接続される。ここで図36Aにおけるインターネット3585が、図17Aのシステム外ネットワーク回線1788に対応する。また図37Aでは記載を省略したが、インターネット3585とシステムコントローラ3581内のインターネット接続部3581aとの間に、図17Aのバッテリ内蔵のルータ(ゲートウェイ)1300が設置されている。
所で複合モジュール3583内は、たとえば図4B(a)または(b)のようにセンサモジュール1260を有し、センサモジュール1260からの検出信号を送信する場合もある。あるいは複合モジュール3583内の通信モジュール1660の中の自己属性データ格納領域1793(図7B)に識別データが保存され、この情報(あるいは複合モジュール3583自体のアドレス(例えば図13のIPアドレスSIPADRS,DIPADRS))を利用してインターネット3584、基地局3584bを介して外部からアクセスされる場合もある。
また1.6節内で説明したように、図7Aあるいは図7Bの構造を有する通信モジュール1660は、システムコントローラ3581、α_1126内の通信モジュール1202−3(図2)の一部でも兼用される。従って図36Aのインターネット接続部3581aは、図7Aの情報通信実行部3016に対応する。また同様に図36Aのプロトコル認識部3581bは、図7Aの物理層フレーム解析部1918に対応し、図36Aのデータ検出部3581dは、図7Aのコンテンツ抽出部1938に対応する。更に図36Aのインターネット整合データ出力部3581gは、図7Aの物理層フレーム生成部1914に対応する。また図36Aの通信規格認識部3581cと通信規格整合フォーマット設定部3581fは、いずれも図7Bの信号処理部1780とプロセッサ1736の組み合わせ部に対応する。所で図36Aのデータ処理部3581e内で行われる処理は、図2ではプロセッサ1230内で実行される。
そして図17A示すように複合モジュール3583、1295は、インターネット3585を介してシステムコントローラ3581(システムコントローラβ_1128)と接続可能である。この時に使用される通信情報は、図11に示す構造を有する。またその中には図13が示すように、送信側IPアドレス情報SIPADRSと受信側IPアドレス情報DIPADRSが格納されている。
インターネット接続部3581aで受信された受信信号は、プロトコル認識部3581bで解析される。プロトコル認識部3581b内で、図11内のIPv6ヘッダIPv6HDと通信ミドルウェアデータAPLDT(及び拡張データEXDT)が個々に抽出される。その後、前記抽出された通信ミドルウェアデータAPLDT(及び拡張データEXDT)が通信規格認識部3581c内で解析される。
そして通信規格認識部3581cは、あらかじめ各種の通信規格のフォーマットを解析するためのデータ処理ルーチンを備える。したがって、通信規格認識部3581cは、複合モジュールがA/E/W−フォーマット(図17B)のいずれを採用しているのか、あるいはC−フォーマット(図17A)を採用しているのかを容易に判断することができる。そして該当する通信規格が認識された後、データ検出部3581dで抽出されたコンテンツ(例えばセンサ検出データ)データ処理部3581eに入力される。
一方本実施形態では受信した通信情報内の通信ミドルウェアデータAPLDT(及び拡張データEXDT)が準拠している通信規格を自動判別した後、その通信規格に準拠したフォーマットで通信ミドルウェアデータAPLDT(及び拡張データEXDT)の内容を生成して、送信相手のユニット1290に応答を送信する所に次の特徴が有る。具体的には前述した通信規格認識部3581c内で識別した通信規格(通信ミドルウェア層APL02、APL06のフォーマット)の情報に基付き、通信規格整合フォーマット設定部3581f内で通信ミドルウェアデータAPLDT(及び拡張データEXDT)を生成する。それに拠りシステムコントローラ3581が、異なるメーカが開発した異なる複数のユニット1290(または複合モジュール1295)との間に安定に情報通信が行える効果が生まれる。
すなわち前述したように通信規格認識部3581c内で、対応するユニット1290(あるいは複合モジュール3583)が使用する通信ミドルウェア層APL02、APL06(及び拡張アプリケーション層EXL06)上での通信規格はすでに認識されている。従ってその情報に基付き、通信規格整合フォーマット設定部3581fではデータ処理部3581eからの送信データを通信ミドルウェアデータAPLDT(図11)及び必要に応じて拡張データEXDTに変換する。その結果、送信(返信)相手のユニット1290(あるいは複合モジュール3583)が通信ミドルウェアデータAPLDT(及び拡張データEXDT)を認識可能となる。そして所定のデータフォーマットの送信データは、インターネット整合データ出力部3581gに入力される。
図36Bは、上記した複合モジュール3583(またはユニット1290)が、種々の異なるエリアに移動する例を示している。ここでエリア毎に、異なるネットワークシステムα_1132、β_1134が構成される。従ってエリア毎にネットワークシステム内でのネットワーク通信を制御/管理/情報収集するシステムコントローラ3581−1、3581−2、3581−3が設置されている。ここで各エリアに配置されるシステムコントローラ3581−1、システムコントローラ3581−2、システムコントローラ3581−3は、それぞれ図36Aのシステムコントローラ3581と同じ構成を有する。
上述したように全てのシステムコントローラ3581−1、3581−2、3581−3が通信ミドルウェア層APL02、APL06(及び拡張アプリケーション層EXL06)上の異なるフォーマット(通信規格)に柔軟に対応する。従って複合モジュール3583(あるいはユニット1290)は、いずれのエリアに移動してもシステムコントローラ3581−1、3581−2、3581−3との相互通信が可能となる。
第5章 応用分野毎の適用例
5.1節 民生分野への適用例
5.1.1節 広域ネットワークシステムの民生分野への適用例
図1に示した広域ネットワークシステムの民生分野(Consumer Electronics Technology)への適用例を考えた場合、卸売業者B1_1104−1とサービスプロバイダB_1112−2、システムα_1132間で流通する商品として“特定情報”を対応させても良い。例えばサービスプロバイダB_1112−2が気象庁や警察署や道路交通公団などの卸売業者B1_1104−1から素材としての広域の気象情報や事故情報あるいは道路の渋滞情報を収集し、それを加工して地域毎に役立つ情報をインターネット上に公開する。そして一般のエンドユーザが手持ちのパソコン(システムコントローラα_1126)を操作してこの情報の閲覧サービスを受けても良い。
また民生分野への適用例として、図1に示す1個のドメイン1〜3_1122−1〜3を家族(独身者の場合には一人で1家庭を構成すると見なす)またはビジネスや趣味/地域に関係した特定集団を構成するメンバ(単独個人も含む)のネットワーク上の所定活動領域に対応させても良い。また前記の特定集団としてSNS(Social Network Service)上での特定メンバが1個の特定ドメイン1〜3_1122−1〜3を形成しても良い。
また別の具体例として図1のシステムα_1132を個人ユーザの自宅内で構成されるPANに対応させた場合、システムβ_1134が同一ユーザの外出先でのネットワーク環境(特定のPAN環境またはLAN環境)に対応させる事ができる。この場合には、外出先でユーザが所有するスマートホンやタブレットなどの携帯端末がシステムコントローラβ_1128に対応する。しかしこのシステムβ_1134を単なる1台の携帯端末のみに対応させるだけで無く、システムコントローラβ_1128が繋がったローカルな(物理的または地理的に近接した特定領域内で構築される)ネットワーク空間全体をシステムβ_1134全体に対応させても良い。そしてドメイン2_1122−2内のシステムα_1132とシステムβ_1134の関係を示す一例としては、外出先のシステムβ_1134の中からユーザが上記携帯端末(システムコントローラβ_1128)を操作してドメイン固有の識別情報ID(Identification Information)と独自パスワードでドメイン2_1122−2内に入り、自宅内で構築されているシステムα_1132内の特定機器を制御する方法、あるいは自宅(システムα_1132)内の所定のセンサモジュールからの情報に基付く独自サービス(例えば自宅の冷蔵庫内に保存されている食材情報から夕食レシピの提案を外出先で得るなど)を受ける方法が有る。
5.1.2節 複合モジュールの民生分野適用例
民生分野への適用例として上記センサ/通信モジュール1460や上記駆動/通信モジュール1470を目覚ましや懐中電灯、歯ブラシ、ヘアドライヤーなど既存の小物家電に付着させ、安価に上記小物家電の機能を飛躍的に向上できる効果が有る。ここで上記センサ/通信モジュール1460や上記駆動/通信モジュール1470を既存の小物家電に付着させる方法として必ずしもネジ止めなど固定する必用は無く、例えば両面テープや接着剤を利用した一時的付着させても良い。例えばこれら小物家電に各種のセンサ/通信モジュール1460を取り付ける(付着させる)だけで、非常に簡単にこれらの小物家電に各種センサ機能を付加できる。そしてこれらのセンサ/通信モジュール1460で検出された各種情報は、システムコントローラα_1126内で集約される。更にこれら小物家電に例えば音声や光を発生する駆動/通信モジュール1470を取り付ける(付着させる)だけで、非常に簡単にこれらの小物家電に新たな付加機能を付加できる。ここでこれらの付加機能は、システムコントローラα_1126により統合的に制御される。そして新たな付加機能が付加された小物家電が、ユーザの行動や状態に応じた最適なサービス提供が行える。たとえばユーザが朝の目覚めが悪いと、目覚まし時計が人間の声で強く警告するサービスを提供できる。あるいはユーザが特定の小物家電を置き忘れた場合、または家の中で無くした場合、小物家電自体がユーザに居場所を知らせるサービスを提供できる。
他の適用例を以下に説明する。例えばセクション2_1142−2(部屋)内の至る所に温度センサや風力センサ、音感センサ、光センサあるいは短距離の人感センサなどの機能を有したセンサ/通信モジュール1460を設置し、システムコントローラα_1126との間のシステムα_1132内通信を可能にする。それと同時に、エアコンやテレビ、照明器具などの機器を制御するリモコン内に駆動/通信モジュール1470を内蔵させて、このリモコン経由でシステムコントローラα_1126からのエアコンやテレビ、照明器具などの機器を制御可能とする。それにより、セクション2_1142−2内の細部に亘る温度や風力、音声、光輝度(照度)、人の動きの分布特性をシステムコントローラα_1126が詳細に把握できる。そしてその把握結果に基付き、ユーザに対して最適な条件で上記機器の制御を行う。特に広い部屋内では冷暖房効果の偏りが大きいため、場所による温度や風力の高低が激しい傾向が有る。それに対して上記サービス方法を適用することで、広い部屋内に住むユーザの満足度が大幅に向上する。そしてこの方法を用いると、設置済みの既存の(エアコンやテレビ、照明器具などの)本体機器を交換する必用無しに、既存のリモコンのみを上記駆動/通信モジュール1470内蔵リモコンに交換するだけで効率良く多くのユーザの満足度を向上させられる効果が生まれる。
所で駆動/通信モジュール1470内蔵リモコンを図8Bの駆動/通信モジュール1470−2内蔵機器1450−4として使用する場合の通信には、図25を用いて第2章で説明するような非常に簡素化された通信情報の通信が可能なC−フォーマットを使用しても良い。しかしそれに限らず上記リモコン構造を、図8Aのように内部に駆動モジュール1270−1と通信モジュール1202−4、デバイスコントローラ1240−1を内蔵した機器1250−1のレベルまで向上させても良い。そしてこの場合には、システムコントローラα_1126との間のシステムα_1132内通信に後述するA−フォーマットやE−フォーマットを使用しても良い。
次に更なる別の応用例を示す。図37Bは、購買者により購入されたミルク3506が冷蔵庫3521内に格納された様子を示している。ミルク3506の容器には、複合モジュール3523が装着されている。そしてこの複合モジュール3523は、シールにより覆われてミルク容器の外側に固定されている。一方では、冷蔵庫3521の内部にシステムコントローラ3522が設置されており、このシステムコントローラ3522は複合モジュール3523と相互通信することができる。
所で上記複合モジュール3523内にはアンテナ内蔵通信モジュール1666が存在し(図4A(b))、その通信モジュール1666内に自己属性データ1793が保存可能となっている。そしてシステムコントローラ3522は複合モジュール3523に対して自己属性データ1793の内容返信を要求することができる。その結果として、システムコントローラ3522は自己属性データに含まれる“賞味期間データ”をチェックすることができる。そしてシステムコントローラ3522内には現在の日付データを有しているので、前記獲得した賞味期間データと日付データを比較し、ミルクの賞味期間のエンドが近づいている程度を測定することができる。つまり例えばシステムコントローラ3522は、賞味期限が1週間以内、4日以内、2日以内、1日以内、あるいは賞味期限が過ぎ去った場合をそれぞれ検出できる。
またそれだけに限らず、システムコントローラ3522は冷蔵庫3521内の商品、食材などに設けられている複合モジュール3523からそれぞれの自己属性データ1793を受け取ることができる。それによりシステムコントローラ3522はネットワーク内の通信回線を利用して、冷蔵庫3521に設けられている表示器3525に冷蔵庫内に収納されている食材、商品などのリストデータを表示できる。そしてその表示器3525を見た冷蔵庫3521の利用者は、先のミルク3506の賞味期間の状況を確認できる。そしてシステムコントローラ3522からの制御に基付き、表示器3525上に色を変えてミルク3506の賞味期間の状況を表示できる。例えば、該ミルク3506の賞味期限が1週間以内の時は「緑」、4日以内の時は「青」、2日以内の時は「黄」、1日以内の時は「ピンク」、賞味期限が過ぎ去った時は「赤」と、それぞれ表示しても良い。なおこの表示方法として色を変化させる代わりに、バー表示や警告文字表示など種々の表示方法を利用しても良い。また自己属性データ1793内に商品購入日付データや購入した店の識別データが含まれる場合は、これらのデータを表示器3525に表示しても良い。
靴3505のヒール部に複合モジュール3531が埋設された例を図37Cに示す。この複合モジュール3531内には、圧力センサや湿度センサなどが内蔵されている。そしてユーザの帰宅時に、前記複合モジュール3531と自宅のシステムコントローラ3532と相互通信を行い、複合モジュール3531内に予め記録された歩数データや湿度データをシステムコントローラ3532が読み取る事ができる。これにより、システムコントローラ3532はユーザの一日分の歩数を計算できる。またそれに限らず、現在の靴3505内の湿度情報も入手できる。そしてその結果を利用して、例えばスマートホン3533にユーザの一日の歩数や靴の湿度を表示できる。
5.1.3節 セクション分割方法の民生分野への適用例
本5.1.3節では、セクション分割方法の民生分野への応用例を説明する。図24の例では、一戸の宅地全体をシステムα_1132に対応させた場合のセクション1_1142−1〜m_1142−mの分割例を示している。所で図25では部屋毎にセクション1_1142−1〜m_1142−mを対応させて説明した。それに比べて図24では若干広い概念に対応させ、宅地内の庭も1個のセクション10_1142−10に対応させている。また図8A〜図8Bと同様に図24でも、車内空間を1セクション1_1142−1に対応させている。そして図8A〜図8Bと同様に図24でもスマートメータ1124の配置場所をセクションの対象から外しているが、それに限らずスマートメータ1124の配置場所を特定の独立したセクションとして規定しても良い。またトイレや風呂場を含めて部屋毎にセクション3_1142−3〜8_1142−8を割り当てている。しかし本実施形態システムではかならずしも部屋毎にセクション分割する必用は無く、例えば内部が複数の部屋に間切りされている“離れ全体”を1個のセクション2_1142−2に割り当てても良い。また物置などユーザが在駐する頻度が少ない空間領域をセクション9_1142−9に対応させても良い。
またセクション1142毎に収集した情報の統合や管理の結果の活用例として、システムコントローラα_1126(内のプロセッサ1230)がエンドユーザの有無や行動/状態(エンドユーザが起きているか?寝ているか?や、エンドユーザが大人か?子供か?など)をセクション1〜m_1142−1〜m単位で推定あるいは判断しても良い。また収集した情報の統合や管理の単位として前記のようにセクション1〜m_1142−1〜m単位に限らず、例えばシステムα〜β_1132〜1134単位(例えば一戸の宅地内にユーザが何人在宅しているかを推定/判断するなど)で行っても良い。
そしてユーザへのサービス提供方法の一例として、セクション1〜m_1142−1〜m単位でのエアコン温度設定や照明のオン/オフ制御、あるいは照明の明るさ制御やTV/ラジオ/オーディオデッキなどの出力音量調整などを行っても良い。そしてセクション1142単位での木目細かなサービス提供をすることで、システムα〜β_1132〜1134内で消費電力が節約(省エネ対応)できる効果も有る。
5.2節 社会インフラ分野への適用例
5.2.1節 広域ネットワークシステムの社会インフラ分野への適用例
図1に示した広域ネットワークシステムを社会インフラ分野(Social Infrastructure Technology)へ適用した場合には、国家や地方自治体、公団や公益法人などの公共機関も卸売業者A_1102、B1/2_1104−1/2に対応する。そしてこの卸売業者A_1102、B1/2_1104−1/2が取り扱う情報(商品)として、本籍/住民票や納税履歴など国民や県民/都民/府民/市民に関する個人情報を対応させても良い。あるいは道路公団や住宅公団が取り扱う情報(商品)として、道路の渋滞情報や事故発生情報、または地域毎の土地代(地価)や住宅情報なども対応させても良い。特に社会インフラ分野へ適用した場合には、卸売業者A_1102、B1/2_1104−1/2が所有あるいは管理/運営する独自の独自インフラ(例えば送電線、上下水道配管や都市ガス配管など)や商品の配送システム(電車やトラックなどを利用した配送手段)を利用できる特徴が有る。
まず始めに、国家や地方自治体、公団や公益法人などの公的組織からの委託を基に行うサービス提供例として、鉄道や交通インフラに関するサービス例を示す。システムコントローラα_1126からサーバn_1116−nに道路や鉄橋、トンネル、線路などの地域毎の劣化情報が定期的に通知される。するとサービスプロバイダB_1112−2内で全てのサーバ1〜n_1116−1〜nの情報を統合して将来の修繕計画の立案あるいは異常警告を発令し、委託元の国家や地方自治体、公的組織(卸売業者A/B_1102/1104に対応)に答申(通知)する。また別例として鉄道や交通、郵政、運搬、航空管制などのシステムの統合的管理例の説明をする。システムコントローラα_1126からサーバn_1116−nに定期的に通知される各種運行状況や事故発生情報を統合的に管理し、必要に応じた運行変更指示をサービスプロバイダB_1112−2からシステムコントローラα_1126やシステムコントローラβ_1128宛に通知する。これらのサービスを提供するサービスプロバイダB_1112−2は、具体的には特定の社会インフラ管理組織や社会システム管理組織(営利企業または公益法人)が対応する。また上記に限らず、例えばNPO法人やNPO組織をサービスプロバイダB_1112−2に対応させても良い。
上記のサービス提供例では、単一のサービスプロバイダ1112のみが提供するサービス方法を説明した。しかし本実施形態システム例ではそれに限らず、複数のサービスプロバイダA/B_1112/1114が互いに連携してサービスを提供しても良い。すなわち既に図1を用いた1.7節の説明で、サービスプロバイダA_1112−1とサービスプロバイダB_1112−2間、あるいはサービスプロバイダB_1112−2とサービスプロバイダC_1112−3間は互いに情報共有または資源の連携融通1114を行い、サービスの効率化と高度化を図れる事を示した。この仕組みにスマートメータ1124で得た情報を組み合わせる事で、公共消費材の新たな有効利用や有効転用が図れる効果が生まれる。その一例として、卸売業者A_1102のインフラや配送システムを利用して電力供給を受けて電力小売り業者のサービスプロバイダA_1112−1に電力量を支払い、卸売業者B1_1104−1のインフラや配送システムを利用して上水供給を受け卸売業者B2_1104−2のインフラや配送システムを利用して下水処理を行い、上下水道小売り業者のサービスプロバイダB_1112−2に上下水道の使用量を支払う場合を考える。サービスプロバイダB内のサーバn_1116−nに対応したデータベース1118−n内には、スマートメータ1124から得られた情報としてシステムα1132内のリアルタイムな貯蔵水量(上水道を経由して供給された水量と下水道を経由して排出された水量との差分)や上水の水圧情報が収集されている。そして電力小売り業者であるサービスプロバイダA_1112−1から特定時間帯における“電力使用料の瞬間的急上昇情報”や“電力量使用制限要求”を受け取ると、上下水道小売り業者であるサービスプロバイダB_1112−2内のサーバn_1116−nはデータベース1118−n内の保存情報を読み出して、対象となるシステムα_1132内での現在の貯蔵水量や上水の水圧から水力発電の可否を判定する。その判定結果として対象システムα_1132内での水力発電が可能の場合には、サーバn_1116−nからシステムコントローラα_1126に対してシステムα_1132内での“水力発電への切り替え”提案を行う。これによりシステムα_1132内での電力料金の低価格化が実現できるだけで無く、地域の使用電力量超過の危険を回避できる効果が生まれる。
次に上述した内容とは異なる別のサービス提供形態に付いて説明する。本実施形態システムでは、ドメイン2_1122−2内あるいはシステムα_1132内に所定商品を供給するための窓口となるスマートメータ1124に向けた卸売業者A_1102からの商品供給経路が複数(図1の卸売業者A_1102からスマートメータ1124に向かう“破線”の直接経路とサービスプロバイダA_1112−1を経由する経路)存在する事を、1.7節で説明した。この特徴を活かしてサービスプロバイダA_1112−1がドメイン2_1122−2内あるいはシステムα_1132内に対して行うサービス提供方法の具体例と、それにより生じる独自効果を以下に説明する。ここではサービスに関係する商品として使用地域や使用日時で料金が変化する電力、ガス、水道、ガソリンなどの公共消費材を例に上げる。しかしそれに限らず他のサービスや商品(例えば一般消費材や流動資産、固定資産などのネットワークを利用した売買や特定情報の流通など)に関しても適応させても良い。例えば夏場/冬場や昼間など使用料金が高い時にドメイン2_1122−2内あるいはシステムα_1132内で公共消費材を使用する場合、スマートメータ1124で計量した卸売業者A_1102からの使用量と同等量を所定商品貯蔵部1154(例えば蓄電池や水/ガスタンク)から卸売業者A_1102へ戻す。逆に冷暖房設備の使用が不要な時期や夜間など使用料金が安い時に卸売業者A1102から公共消費材を購入して所定商品貯蔵部1154に貯蔵する。これにより実質的な公共消費材に対するエンドユーザ(ドメイン2_1122−2内あるいはシステムα_1132内のユーザ)が支払う使用料金を安くできる。そして同時にサービスプロバイダA_1112−1は、公共消費材使用料金の低価格化分(利鞘)の一部を報酬として受け取る事ができる。更に上記方法により、広域的に見た場合の公共消費材使用量(卸売業者A_1102が供給する商品(公共消費材の)量)の平滑化(季節や時間による公共消費材使用量の一時的な増減量を減らす)が図れる新たな効果が生まれる。
そして上記のようにスマートメータ1124で計量した公共消費材の使用量と同等量を所定商品貯蔵部1154から卸売業者A_1102へ戻す場合には、充電/放電量制御部または貯蔵/放出量制御部での高い制御精度が要求される。前記高い制御精度を達成するため本実施形態システムでは、充電/放電量モニタ部または貯蔵/放出量モニタ部(図1での記載を省略したが、所定商品貯蔵部1154内に存在する、図8A、図9を用いて後述する流入量モニタ部1218と放出量モニタ部1216に相当する部分)からの検出情報(検出信号)に基付いた充電/放電量制御部または貯蔵/放出量制御部(同様に、流入量制御部1214と放出量制御部1212に相当する部分)での充電/放電量または貯蔵/放出量のリアルタイムフィードバックを行なう。またそれのみに限らず必要に応じて、所定期間毎の充電/放電量または貯蔵/放出量の累計蓄積量を適宜算出して所定の目標値と比較し、その目標値との間の差分値に応じた量を次の所定期間における充電/放電量または貯蔵/放出量にフィードバックを掛けても良い。上記の制御方法の実施により所定期間毎の累計蓄積量の制御精度が向上し、公共消費材売買における損失(制御量不足に拠る売買益のずれ額)を最小限に抑えられる効果が有る。
所で広域ネットワークシステムを社会インフラ分野へ適用する場合には、図1に示した1個のドメイン1〜3_1122−1〜3を特定の社会インフラ全体または特定の社会システム全体に対応させても良い。例えば所定集団(特定法人または特定法人グループ)毎の鉄道や交通、郵政、航空管制、運搬事業、公共消費材生産事業などの運営や状態観測単位、あるいはそれ以外のあらゆる社会インフラや社会システムを運営及び状態観測する単位を各ドメイン1〜3_1122−1〜3に対応付けても良い。また更に地域毎の分散活動をネットワークで統合された特定コミュニティや所定組織または所定法人の活動に関する運営や状態観測の大きな纏まりを各ドメイン1〜3_1122−1〜3に対応付けても良い。
一方図1に示す1個のシステムα/β_1132/1134を、1個のビルや地域に対応させても良い。すなわち省電力システム(Energy Management System)の対象として規模サイズ毎にHEMS(Home Energy Management System)、BEMS(Building Energy Management System)やCEMS(Community Energy Management System)と呼ばれるが、本実施形態システムにおける1個のシステムα/β_1132/1134を上記HEMSまたはBEMSやCEMSの1管理単位に対応付けても良い。
更に上記以外の具体的な対応方法としてのドメイン1122とシステムα/β_1132/1134との関係例を説明する。例えばドメイン1122が特定鉄道会社の運行運営や状態観測に対応させた場合、自動改札システム、発券システム、定期券発行システム、電車毎の運行状況管理システム、線路の破損状況自動管理システム、電車内の破損状況管理システム、プラットフォームの劣化管理システム、電車毎の電力供給状況管理システム、電車内/プラットフォーム上での異常警告システム、車内痴漢逮捕システム、乗員/駅の係員の勤務管理・給与支払いシステム、給与支払い/経理システムなどを各システム1132〜4に対応させても良い。またドメイン1122が交通や運送事業の運営及び状態管理に対応させた場合には、道路や鉄橋、トンネルの劣化管理システム、路上事故発生情報管理システム、渋滞管理システム、運搬手段(トラックなど)の破損状況管理システム、(高速道路などの)ゲート管理システム(ETC管理システムを含む)、従業員の出退勤管理システム、給与支払い経理システムなどを各システム1132〜4に対応させても良い。
一方1.7節で、1個のシステムα_1132を物理的または地理的に近接した特定領域に対応させた場合に、1ドメイン2_1122−2を前記物理的または地理的な空間を超越したネットワーク上領域に対応させられると説明した。それに従って道路や鉄橋、トンネルの劣化管理システム全体を1個のドメイン2_1122−2に対応させた場合に、地域毎に設定した道路や鉄橋、トンネルの劣化管理単位を個々のシステムα/β_1132/1134に対応させても良い。
5.2.2節 複合モジュールの社会インフラ分野への適用例
本実施形態システムを社会システムや社会インフラに適用する場合、センサ/通信モジュール1460を信号機や道路、高速道路などの出入り口ゲートあるいは公共的な掲示板(電子掲示板も含む)の一部またはその周辺に配置して人や車の往来状況や渋滞状況をシステムコントローラα_1126が把握し、必要な情報のみをサーバn_1116−nに通知しても良い。そしてこの場合の機器1450は、信号機や電子的なゲート、電子掲示板などに対応させても良い。またこの場合の、第4章で後述するセクションは上記信号機や電子的ゲート、電子掲示板周辺の所定領域あるいは特定範囲内の道路に対応させても良い。
特に上述したセンサ/通信モジュール1460は軽量/小形/省電力(外部からの電源供給が不要)に対応容易な特徴を有する。従ってそのメリットを利用し、各種センサ/通信モジュール1460を道路や橋桁、トンネル内あるいは(上下水道などの)配管部に多数設置し、道路や橋桁、トンネル内あるいは配管部内の劣化箇所の長期間モニタが容易となる。そしてここで得られた各種センス情報は、システムコントローラα_1126内で例えば変化成分のみの検出など必用な情報のみの抽出が可能となるので、サーバn_1116−n側での解析やデータ処理が容易となる。
上記センサ/通信モジュール1460を社会インフラ分野へ適用する他の例として、スーパーマーケットやコンビニエンスストア、デパートなどの店舗内でカートに上記センサ/通信モジュール1460を取り付け、店舗内顧客の行動履歴情報を収集しても良い。そして収集した顧客の行動履歴から例えば“顧客が長く滞在する売り場”や“顧客が廻る順番”を抽出し、店舗内の商品陳列などのマーケティング(市場調査)に反映させる事で店舗の売り上げ向上に貢献できる効果が生まれる。
一方、例えば特にオフィスや病院、大型店舗などの広い部屋内では冷暖房効果の偏りが大きいため、場所による温度や風力の高低が激しい傾向が有る。従って5.1.2節と同様にオフィスや病院、大型店舗などの至る所に温度センサや風力センサ、音感センサ、光センサあるいは短距離の人感センサなどの機能を有したセンサ/通信モジュール1460を設置する事で広い部屋内での冷暖房効果の偏りが大幅に軽減され、多くの顧客の満足度が向上する効果が有る。
複合モジュール1295が具体的に利用された他の応用実施形態を説明する。図4A(a)または(b)が示すように、あらゆる複合モジュール1295は通信モジュール1660を含む。また1.6節内で図7Bを用いて説明したように、前記通信モジュール1660内には自己属性データ保存領域1793が存在する。そして複合モジュール1295を装備している製品或いは商品或いは部品などは、その使用局面に応じて自己属性データ1793の内容が変化及び又は切り替えされる。ここで言う使用局面とは、前記製品或いは商品或いは部品などの存在領域の変化(すなわち図37Bに示すように複合モジュール1295が配置されるシステムの変化)、或いは経過時間の変化、或いは条件の変化などを含む。そして前記複合モジュール1295がセンサ/通信モジュール1460として使われる場合は、センサとの組み合わせに拠る種々の使用環境での周囲状態を監視することができる。
図37Aは、例えばスーパーマーケットの店内領域3501と、キャッシュレジスタ領域3502と、スーパーマーケットの出口領域3503を模式的に示している。ここでは上記スーパーマーケットの店内が、1個の独立したシステムα_1132に対応する(図1参照)。そして図37A内のキャッシュレジスタ3511a,2511bが、システムコントローラα_1126として動作する。そして上記システムα_1132内では、商品として靴3505、ミルク3506、バッグ3507が販売されているものとする。
ここで靴3505とミルク3506、バッグ3507のそれぞれには、複合モジュール1295としてセンサ/通信モジュール1460が搭載されている。この具体的な搭載方法として、シート状のセンサ/通信モジュール1460(複合モジュール1295)が粘着剤によって個々に貼り付けられている。またそれに限らず、靴3505やミルク3506、バッグ3507内に挿入(または混入)されていても良い。そして前記の自己属性データ1793の一部は、盗難防止フラグ(例えば“1”)を有するものとする。そして購買者が精算を済ませた時に、キャッシュレジスタ領域3502のキャッシュレジスタ3511a,或いは2511bからの制御に基付いて前記盗難防止フラグの情報が消去される。具体的には例えばキャッシュレジスタ3511aが商品の値段が示されているバーコードを読み取った時に、読み取り完了信号を該商品内の複合モジュール1295(またはセンサ/通信モジュール1460あるいはユニット1290)に送信する。そして対応する複合モジュール1295(またはセンサ/通信モジュール1460あるいはユニット1290)は、読み取り完了信号の受信時に精算が終了したと判断しして盗難防止フラグを消去し“0”とする。更にキャッシュレジスタ3511a,2511bは、前記の自己属性データ保存領域1793内にスーパーマーケットの識別データや精算が行われた日付データを追加することができる。
ここで仮に盗難防止フラグが消去されないまま(精算が行われないまま)スーパーマーケットの出口領域3503を商品が通過すると、自動的に警報が出力される。すなわちスーパーマーケットの出口領域3503には警報出力可能な監視装置3512が設置されている。4.4節で説明したように本実施形態システムでは、全ての複合モジュール1295(またはセンサ/通信モジュール1460)の位置がリアルタイムで検出可能となっている。従って前記複合モジュール1295(またはセンサ/通信モジュール1460)のスーパーマーケットの出口領域3503通過時には自動的にシステムコントローラα_1126(キャッシュレジスタ3511a,2511b)との間で情報通信がなされる。そして盗難防止フラグが“1”の場合には、監視装置から警報が出力される。反対に盗難防止フラグが”0”の場合は、監視装置3512から警報が出力されることはない。
上記の実施形態システム例ではキャッシュレジスタ3511a、3511bに店員が配置され、自己属性データ保存領域1793内に盗難防止フラグが保存されている例を示した。しかしそれに限らず、自己属性データ保存領域1793内に対象商品の販売価格が予め記録されても良い。そして販売価格が予め記録された複合モジュール1295(またはセンサ/通信モジュール1460あるいはユニット1290)がスーパーマーケットの出口領域3503を通過すると、自動的に購買者が支払う支払い金額の合計値が表示される。一方で購買者が身に着けている装着品(ネクタイピンやネックレスなど)内にも同様に複合モジュール1295(またはセンサ/通信モジュール1460あるいはユニット1290)が搭載され、購買者が無人のキャッシュレジスタ3511a、3511bを通過すると支払いの合計金額が購買者の銀行口座から自動的に引き落とされる。なおそれを可能にするため、購買者の装着品内に搭載された複合モジュール1295(またはセンサ/通信モジュール1460あるいはユニット1290)内の自己属性データ保存領域1793に購買者の銀行口座番号とパスワードが予め記録されている。
購買者への課金情報が記録された複合モジュール1295(またはセンサ/通信モジュール1460あるいはユニット1290)は上記のように装着品内に搭載される代わりに、5.3.2節で後述するように飲み込む等の方法で購買者の体内に存在しても良い。
上述したように複合モジュール1295(またはセンサ/通信モジュール1460)を利用する事で盗難防止が図られるだけで無く、店員不要の自動課金が可能となる。それにより人件費の大幅な節約が図れ、スーパーマーケットの利益向上に役立つ効果が有る。
例えばビルディングの壁やトンネルの壁、橋などを支える鉄骨の腐食状況を検査するシステムに複合モジュールを使用する例を、図37Dに示す。例えばトンネルなどの検査対象の壁3540の裏側を、鉄骨3541a,3541b,3541c,・・・が支えている。鉄骨3541a、3541b、3541cのそれぞれの表面には複合モジュール3542、3543が取り付けられている。図30Dでは、鉄骨3541aに取り付けられている通信モジュール3542、3543が図面上に表れている。所で検査対象の壁3540が無線電波に対してシールド効果を有する場合には、複合モジュール1295内の通信モジュール1660に対して外付けでアンテナ1480が設置される(図4A(a))。そしてこの外付けアンテナ1480は、無線電波の送受信が可能な位置に配置される。すなわち図37Dの例では、複合モジュール3542、3543のアンテナ3542a、3543bが検査対象の壁3540を貫通するリード線を介して検査対象の壁3540の外側の表面に導出されている。
所で上記複合モジュール(センサ/通信モジュール)3542、3543内のセンサモジュール1260(図4B(a))は、鉄骨3541a、3541b、3541cの表面に絶縁膜を介して密着されている。所で鉄骨3541a、3541b、3541cの表面が錆びて盛り上がると、接着膜が破れてセンサモジュール1260が直接的に錆と接触するようになる。そしてセンサモジュール1260が錆に接触すると、センサモジュール1260内の抵抗値が低下する。従って上記のセンサモジュール1260内の抵抗値を知る事で、鉄骨3541a、3541b、3541c表面の錆び状態が分かる。
今まで説明した実施形態システム例では多くの場合、システムコントローラ1126、3546が固定系に設置され、移動可能なのはユニット1290(または複合モジュール1295)側が多かった。それに比べて図37D(及び後述する図37E)の実施形態システム例ではユニット1290(または複合モジュール1295)側が固定され、システムコントローラ1126、3546が移動可能となっている所に特徴が有る。例えば非常に広範囲な領域のセンサ情報を一度に入手したい場合や、システムの事情でシステムコントローラα_1126の設置が難しい場合が有る。この場合には上述したようにユニット1290(または複合モジュール1295)を固定系に設置し、システムコントローラ1126、3546を移動させて各ユニット1290(または複合モジュール1295)のセンサ情報を収集する。これに拠り、非常に広範囲な領域のセンサ情報の入手が容易になる効果が有る。
本実施形態システムでは4.5節で説明したように、同一のユニット1290(または複合モジュール1295)が複数の異なるシステムに適合可能となっている。従ってこの場合でも、異なる用途で使用される複数の異なるシステムコントローラ1126、3546が移動する度に、固定されたユニット1290(または複合モジュール1295)が用途毎の適正動作が可能となっている。
図37Dの実施形態システム例では、点検自動車3545の一部(図37Dの図では点検自動車3545の屋根部)にシステムコントローラ3546が設置され、複合モジュールのアンテナ3542a、3543bの近傍を通過する。そして複合モジュールのアンテナ3542a、3543bの近傍を通過する毎に、システムコントローラ3546から各複合モジュール(ユニット)3542、3543に対して「センサモジュール1260内の抵抗値回答」のコマンドリクエストを送信する。そしてリクエストコマンドに応答して、各複合モジュール(ユニット)3542、3543からシステムコントローラ3546に対して「センサモジュール1260内の抵抗値」が適宜回答される。それによりシステムコントローラ3546は、全ての鉄骨3541a、3541b、3541cに対する錆状態を点検できる。このようにして定期的な錆点検が容易にかつ精度良く行える。なお上記の錆検出方法はあくまで一例に過ぎず、他の検出手段を用いて錆を検出しても良い。
このように錆点検した結果として許容範囲外のセンサモジュール1260内の抵抗値低下が検出された場合には、システムコントローラ3546、1126からインターネットを経由して図1のサーバn_1116−nに錆劣化した所定の鉄骨3541の情報が通知される。なおこの場合には、図1の卸売業者B1_1104−1が政府または道路公団に対応する。そして前記の政府または道路公団から委託を受けた壁のメンテナンス業者が、サービスプロバイダB_1112−2に対応する。そして上記サーバn_1116−n内に蓄えられた錆劣化した鉄骨3541の情報に基付いて前記の壁のメンテナンス業者が修繕計画を策定して、道路公団(卸売業者B1_1104−1)に対して修繕予算の申請を行う。
例えばガス管、水道管、消火栓管などの漏れ検出に複合モジュール1295またはユニット1290が使用される実施形態システムの応用例を図37Eに示す。ガス管、水道管、消火栓管などは、道路に沿って地中に配置される場合が多い。そこで、ガス管、水道管、消火栓管などの管3548の表面上に複合モジュール(ユニット)3549を取り付ける。ここで複合モジュール(ユニット)3549に内蔵され、ガス管や水道管、消火栓管などの漏れ検出に利用されるセンサモジュール1260としては、ガスセンサや湿気(水)センサ、音センサ、振動センサなどが組み合わせられた複合センサが組み込まれても良い。
図37Dと同様に図37Eでも、点検自動車3545内にシステムコントローラ3546が搭載(図37Eでは点検自動車3545の底面上にシステムコントローラ3546が搭載)されており、定期的に漏れ点検を行う。図37Dと同様にシステムコントローラ3546のリクエストコマンドに応じて、センサモジュール1260からの検出データがシステムコントローラ3546に返信される。システムコントローラ3546は各複合モジュール(ユニット)3549からのセンサ情報を収集して解析する事で、ガス漏れや水漏れなどの場所を判定できる。また図37Eの実施形態システムでも図37Dと同様に、非常に容易な方法で広範囲の異常箇所を発見できる効果が有る。なおシステムコントローラ3546は点検自動車3545に搭載する代わりに、管の設置ラインに沿って固定設置されてもよい。
温室栽培装置に複合モジュール(ユニット)が適用される例を図37Fに示す。所で温室栽培装置は、例えば温室ハウス、ビニールハウスなどと称される場合もある。温室ハウス3550内には、例えばシステムコントローラ3551や監視カメラ3552が設置されている。そしてこの監視カメラ3552が温室ハウス3550内の植物の状態を撮像し、撮像した映像信号を栽培者(オーナー)が所有するモニタに送信することができる。
温室ハウス2550内には、例えば人参、大根或いはごぼうなどの野菜が栽培されているものとする。このような野菜の場合、地中の成長具合は外部から見ただけでは判断できない。そこで図37Fに示す実施形態システムでは、複数の複合モジュール(ユニット)を内蔵したバー状の監視装置3553a,3553b,3553c,・・・・が地中に配置されている。
図37Fの右側は、代表としてバー状の監視装置3553cの拡大図が示して有る。ここでバー状の監視装置3553c内に五角形で示した部分は監視装置3553cの取り付け板であり、地中に差込み易く先端が尖った形状となっている。そしてこの取り付け板の長手方向に、複数の複合モジュール(ユニット)FC1〜FC5、FD1〜FD5が装備されている。またこの複合モジュール(ユニット)FC1〜FC5内は、例えば超音波の送受信に拠り近傍物質のサイズが測定可能なセンサモジュール1260を搭載している。また、複合モジュール(ユニット)FD1〜FD5は、例えば湿度の測定を行うことができる湿度センサを含むセンサモジュール1260を搭載している。そして複合モジュール(ユニット)FC1〜FC5から得られる測定結果で、近接している野菜(人参、或いは大根)の成長(長さ)情報を収集する。所で近接している野菜(人参、或いは大根)の成長(長さ)情報を収集する方法は超音波に限らず、例えば波長が700nmから2500nm範囲に含まれる近赤外線を用いてイメージングしても良い。また複合モジュール(ユニット)FD1〜FD5から得られる湿度の測定データは、地中内の水分の状況を監視するのに有効となる。そして複合モジュール(ユニット)FC1〜FC5、FD1〜FD5に拠り得られる計測データは、アンテナANTを介して、システムコントローラ3551へ送信される。
上記の複合モジュール(ユニット)FC1〜FC5、FD1〜FD5の出力データはシステムコントローラ3551で集計される。そしてこの集計結果は適宜モニタに表示されるため、監視者が容易に収穫時期の判断ができる。またそれに限らず複合モジュール(ユニット)FD1〜FD5から得られる湿度の測定データの集計結果をモニタ監視することで、監視者は適切な散水時期が分かる。このようにして、野菜の良好な成長を監視することができる。
さらに温室ハウス3550の内部には、例えば赤外線センサ及び又は高周波高感度マイクを内蔵した複合モジュール(ユニット)3554が配置されている。この複合モジュール(ユニット)3554は周期的に稼働する事で、例えば野菜に取り付く害虫類や昆虫類の存在を監視できる。
また他の実施形態システムを示す応用例として、図37Gと図37Hでは複数の異なる種類の複合モジュール(ユニット)を組み合わせて監視する例を示す。特に図37Gでは『通常では有り得ない組み合わせを検出』する所に特徴が有る。これに拠り、精度良くまた効率良く異常検出できる効果が生まれる。また図37Hでは『複数の異なる識別データ間の関連付けを検出』する所に特徴が有る。それに拠り、状態の検出精度が向上する効果が生まれる。これらのように複数の異なる種類の複合モジュール(ユニット)からのセンサ情報を同時に入手する事で、状態変化の検出精度を向上させる効果が有る。
まず始めに図37Gを用いて『通常では有り得ない組み合わせを検出』する方法に付いて説明する。例えば病院や学校(小学校、中学校、高校、大学)、警察署、皇居周辺などで凶器が存在した場合(具体的には金属探知機を用いた金属反応の検出など)、システムコンピュータは、ありえない物体の組み合わせとして検出することができる。その具体的一例として図37Gでは、病院内の一室を示している。この部屋には、例えば患者用ベッド3560、医療器具の箱3561が備えられている。ここで患者用ベッド3560内には、複合モジュール(ユニット)3560aが取り付けられている。また医療器具の箱3561にも同様に、複合モジュール(ユニット)3561aが取り付けられている。そしてこの複合モジュール(ユニット)3560a内の自己属性データ1793(図7B)として、ベッド3560の識別データを記憶している。そして外部に設置されたシステムコントローラ3562からの要求に応じて、適宜ベッド3560の識別データを回答送信可能になっている。一方では複合モジュール(ユニット)3561a内の自己属性データ1793(図7B)として、医療器具の箱3561の識別データを記憶している。そして外部に設置されたシステムコントローラ3562からの要求に応じて、医療器具の箱3561の識別データを回答送信可能となっている。これに拠りシステムコントローラ3562は、常に病室に存在する製品の組み合わせを把握できる。このようにしてシステムコントローラ3562は、病室内の存在を許される各種製品のデータベースを備えている。
ここで病室に刃物などの凶器3565が持ち込まれたとする。この刃物などの凶器3565内にも複合モジュール(ユニット)3565aが内蔵されている。そしてこの複合モジュール(ユニット)3565aが予め保存されている自己属性データ1793(製品の識別データ)を送信すると、システムコントローラ3562が病室内の存在を許していない製品が現れたことを認識する。その結果、システムコントローラ3562が迅速に異常状態を警備室、監視質、或いは警備会社に通報できる。
上記の例は病室の例を示したがそれに限らず、同様な考え方を皇居や大統領官邸、首相官邸の周辺の警備範囲、学校(小学校、中学校、高校、大学など)、警察署など種々のエリアや施設内で適用できる。
複数の異なる複合モジュール1295(またはユニット1290)から得られる複数種類のセンス情報を組み合わせて監視する他の例を図37Hに示す。ここでは乗客3570が、空港3567から空港3568へ飛行機3569で移動する例を示した。ここで例えばパスポートやバッグ、帽子、靴などの乗客の所持品内には複合モジュール(ユニット)3570aが内蔵され、またこの複合モジュール(ユニット)3570a内の自己属性データ保存領域1793(図7B参照)に該当する識別データが予め記録されている。またこの乗客が所有するキャリーバッグ3573にも同様に、複合モジュール(ユニット)3573aが接着されている。そしてこの複合モジュール(ユニット)3573a内の自己属性データ保存領域1793にも、キャリーバッグの識別データが予め記録されている。
そして乗客3570の飛行機3569への搭乗時に、システムコントローラ3571が乗客の所持品(手荷物)3572とキャリーバッグ3573の識別データを収集する。そしてこれら複数の識別データ(乗客の所持品3572の識別データとキャリーバッグ3573の識別データ)は関連付けられて、乗客3570の必須の組み合わせ識別データとしてシステムコントローラ3571に認識される。
一方、乗客3570の移動先の空港3568にも別のシステムコントローラ3572が予め設置されている。そして乗客3570が移動先の空港3568に到着すると、この乗客3570に関連付けられた複数の識別データ(乗客の所持品3572の識別データとキャリーバッグ3573の識別データ)が、インターネット経由で移動元のシステムコントローラ3571から移動先に設置されたシステムコントローラ3572へ自動転送される。そしてシステムコントローラ3572は独自にパスポートやバッグ、帽子、靴などの乗客の所持品内に内蔵された複合モジュール(ユニット)3570aとキャリーバッグ3573に内蔵された複合モジュール(ユニット)3573aにアクセスして、それぞれの識別データ(乗客の所持品3572の識別データとキャリーバッグ3573の識別データ)を取得する。
次に複合モジュール(ユニット)3570a、3573aから取得した複数の識別データと移動元のシステムコントローラ3571から入手した複数の識別データ(乗客の所持品3572の識別データとキャリーバッグ3573の識別データ)を照合する。それにより移動先のシステムコントローラ3572は、乗客3570の持ち物が正常に空港3567から空港3568へ運ばれたかどうかを判断することができる。
5.2.3節 セクション分割方法の社会インフラ分野への適用例
本5.2.3節では、社会インフラ分野でのセクション分割を適応させた場合のセクション分割例に付いて説明する。この社会インフラ分野でのセクション分割単位は、5.1.3節で説明した規模より大きくなる傾向が有る。
例えばビル内の間切り(部屋)毎やフロア毎に個々のセクション1142を対応させた場合、民間住宅内部屋の平均サイズよりビル内の間切り領域の平均サイズの方が大きくなる。また集合住宅内の戸別に各セクション1142を割り当てても良い。
そして社会インフラ分野にセクション分割を適応させた場合、分割するセクション構造に階層を持たせても良い。例えば上記の集合住宅を例に取った場合、第1の上位階層として戸別に上位のセクション分割を対応させ、更にその各戸内での部屋割りに応じて下位のセクション分割を対応させても良い。同様に所定の地域に対応して区分け規模毎に階層化したセクションを対応させても良い。例えば日本では、日本国が都や府、県の単位で分割され(前記の単位に合わせて上位のセクションを対応させ)、東京都は複数の区と市に分割されている。また県によっては複数の市や郡に分割させている。そしてこの分割に合わせて中位のセクションを対応させ、番地毎に下位のセクションを対応させても良い。
所で図35は特定地域の地図を模式的に示した図となっている。上記のように番地毎に個々のセクション1142を対応させても良い。またそれに限らず、所定の機能に対応させてセクション1142の分割をしても良い。その一例を説明する。日本では主要幹線道路直下の地下に水道管や(電話線や光ファイバーなどの)有線の通信回線を設置する事が有る。また主要幹線道路に沿って上空に電力供給線を設置する場合が有る。このように主要幹線道路や上下水道の配管、配電電力線や有線の通信回線に沿って地域毎あるいは所定間隔毎にセクション1_1142−1〜4_1142−4の分割1900を行っても良い。また本実施形態システムでは上記セクション1142内に複数のセンサモジュール1260またはセンサ/通信モジュール1460を配置し、そこから得られるセンサ情報をセクション1142毎に統合または管理する事で、セクション1142単位での道路上の劣化場所の抽出や上下水道の水漏れ箇所の探索、あるいは配電電力線や有線の通信回線の断線箇所探索が可能となる。その結果、より詳細な道路上の劣化場所の抽出や上下水道の水漏れ箇所の探索/配電電力線や有線の通信回線の断線箇所探索が容易となる。
また高速道路など主要幹線道路の渋滞状況把握に関しても上記と同様に主要幹線道路に沿って地域毎あるいは所定間隔毎にセクション1_1142−1〜4_1142−4の分割1900を行っても良い。そしてセクション1142毎の渋滞状況を表示すると、渋滞状況の的確な把握が容易となる。それと比較的類似した内容として、所定地域内の混雑状況把握にセクション1142の分割手法を利用しても良い。すなわちサッカーや野球の試合やコンサートなどのイベント開催時に、イベント会場周辺を複数セクション1142に分割し、このセクション単位で人通りの混雑状態を把握すると、通行人の誘導や警察官の配置をより効率的に行える。
このように本実施形態システムでは情報収集結果に関してセクション1142単位の統合や管理を行う事で広い地域全体の状況把握をし易くするばかりでなく、社会インフラ系のメンテナンス処理の利便性が上がる効果が生まれる。
上記の主要幹線道路の渋滞状況把握に若干類似した社会インフラ分野での適用例として、物流管理対応が上げられる。例えば魚介類の鮮度を保ったまま遠隔地へ輸送するには、輸送時間が短くなる空輸方法が有る。しかし輸送費用削減の視点から、車両による遠隔地輸送で鮮度を長期間確保する方法も検討されている。そしてその検討の結果として魚介類、野菜や果実の鮮度確保には、輸送時の温度管理が重要な事が分かっている。
すなわち魚介類、野菜や果実内部での酸化反応速度や腐食速度は周囲温度に依存するので、この観点からは魚介類、野菜や果実の保存温度は低く設定するのが望ましい。一方で魚を氷点下環境に設置すると、体内の血液が氷結して膨張するので明らかな鮮度低下が生じる。また野菜や果実でも同様に、表面に付着した水分や内部の含有水分の氷結による体積膨張が明らかな鮮度低下を及ぼす。従って車両による遠隔地輸送では、冷蔵車内の魚介類、野菜や果実の温度を“0±1℃”の範囲に保つ必用が有る。
そのため魚介類、野菜や果実の梱包容器内に温度センサを設置し、個々の梱包容器から得られる温度情報に基付いて冷蔵車内の空調を制御できる。この場合の温度センサが、センサ/通信モジュール1460に対応する。そしてセクション1142を『1台毎の冷蔵車内環境』に対応させられる。
しかし本実施形態システムでは上記に限らず、他のセクション分割方法を採用しても良い。本実施形態システムでは4.4節で説明したように、個々のセンサ/通信モジュール1460が発信する無線電波の放出元の位置検出が可能となっている。従って温度を検出するセンサ/通信モジュール1460に対する位置検出技術を利用して、魚介類、野菜や果実の梱包容器毎の輸送場所をリアルタイムで追跡できる。更に2.3節の説明内容から図12A(e)の送信側におけるIEEE拡張アドレスSEXADRS(あるいは2.4節で説明した送信側IPアドレス情報SIPADRS)を用いて、各梱包容器の識別が可能となる。従って上記技術を組み合わせると、魚介類、野菜や果実の梱包容器毎の輸送経路や所用輸送時間を管理できるだけで無く、この梱包容器を格納した冷蔵車の輸送経路途中での交通渋滞などによる輸送遅滞をリアルタイムで管理できる。その結果、この車両輸送前の梱包容器の事前保存時間を加味して交通渋滞回避可否をこの冷蔵車に指示しても良い。
上記の物流管理に本実施形態システムを適用した場合、後述する図10Aの同一システム内ネットワーク回線1782に使用する物理的な通信媒体(communication media)の選定方法が重要となる。例えば中距離無線に対応したIEEE(Institute of Electrical and Electronics Engineers)802.11n規格では、有効セル半径が数100mと言われる。従ってこの物理的な通信媒体として中距離無線を採用した場合には、各システムα_1132、β_1134の物理的サイズを1km以下に設定する必用が有る。一方遠距離無線に対応したIEEE802.16e−2005のセル半径が1〜3kmとなっている。従ってこの物理的な通信媒体として中距離無線を採用した場合には、各システムα_1132、β_1134の物理的サイズを3km前後に設定するのが望ましい。
そして上記サイズの各システムα_1132、β_1134内で、輸送経路(例えば図35の主要幹線道路)に沿って空間的に多分割してセクション1_1142−1〜m_1142−mを定義しても良い。このように魚介類、野菜や果実の梱包容器毎の輸送場所をセクション1_1142−1〜m_1142−m毎に管理すると、例えば輸送経路途中での交通渋滞による配送遅延原因場所が細かく把握できる効果が有る。そしてその結果を他の配送車に通知して交通渋滞箇所回避を指示すれば、他の配送車のスムーズな輸送が可能となる。
上記の物流管理への本実施形態システム適用方法に関する別の応用例を以下に説明する。この応用例では、4.2節で説明した“複合モジュールの位置検出を利用した簡易的なプラグイン/プラグアウト方法”を利用する。所でこの場合には、同一システム内ネットワーク回線1782(図10A)の物理的な通信媒体には近距離無線を採用する。
ここで温度を検出するセンサ/通信モジュール1460を内蔵した魚介類、野菜や果実の梱包容器の出荷前に保存しておく大形冷蔵庫内をシステムα_1132に対応させる。またこの中の空間内は細かく分割されてセクション1_1142−1〜m_1142−mが定義されているので、この梱包容器の大形冷蔵庫内の保管場所は自動で管理されている。そしてこの梱包容器が出荷されると、上記大形冷蔵庫の外に出される。それによりシステムα_1132からの自動的なプラグアウト処理されると共に出荷日時がシステムコントローラα_1126内で管理される。
次にこの梱包容器を輸送する冷蔵車内の荷台空間内をシステムβ_1134に対応させる。またこの中の空間内も細かくセクション1142定義されている。この中に設置されたシステムコントローラβ_1128が上記センサ/通信モジュール1460から温度情報を収集して、冷蔵車内のエアコン制御を行う。
所で4.4節の方法では無線通信に対応した通信モジュール1202部分の配置場所のみを検出しており、センサ/通信モジュール1460内のセンサモジュール1260部の位置や駆動/通信モジュール1470内の駆動モジュール1270部の位置を検出して無い。従って上記冷蔵車内の温度管理精度が高く、梱包容器毎の温度管理が必ずしも必要でない場合には、上記センサ/通信モジュール1460の代わりに近距離無線通信に対応した通信モジュール1202単体を使用しても良い。
そしてこの冷蔵車の配送先の倉庫(大形冷蔵庫)内をシステムγに対応させる。このシステムγ内に実装されているシステムコントローラγは、前述したシステムコントローラα_1126、β_1128と情報共有しているので、配送遅延情報や出荷前の倉庫内事前保存所要時間、輸送時の内部温度などの情報から梱包容器内の魚介類、野菜や果実の鮮度が予測できる。このようにして配送後の鮮度が予測出来るので、対応する魚介類、野菜や果実の値付け容易性やその後の配送先選別容易性が向上する効果が生まれる。
更に上記“複合モジュールの位置検出を利用した簡易的なプラグイン/プラグアウト方法”を利用した他の応用例として、『ゲート通過時や商品購入時の自動決済』に利用しても良い。またこの応用例で使用する複合モジュールとしては、音声入力対応のセンサ/通信モジュール1460を使用しても良い。所で現在日本では、非接触型ICカード規格のFeliCa(FelicityとCardを組み合わせた造語)などの近接場無線を、所定部屋の出入り口での入出管理や鉄道関連の改札機(ゲート)通過時の改札処理あるいや商品購入時の自動決済に利用している。しかし上記非接触型ICカードの通信に近接場無線通信を使用するため、ユーザが使用する度に上記非接触型ICカードを携帯時の保管場所から取り出す手間が掛かる。
それに対して近接場無線通信から近距離無線通信(あるいは中距離無線通信)に変更すれば、ユーザは使用時に鞄やバッグ、ポケット等の携帯(保管)場所から取り出す手間が省けるメリットが生まれる。そしてここでのセンサ/通信モジュール1460−5が実装されたパッケージの物理的形状は必ずしもカードの必用は無く、例えばネックレスやネクタイピンなど携帯し易い自由な形状が許される。そして所定部屋入り口扉前近傍や鉄道関連の改札機(ゲート)の通過入り口近傍または自動販売機や店舗の購入窓口近傍のみにシステムα_1132領域を設定する。所で4.4節の方法では無線通信に対応した通信モジュール1202部分の配置場所のみを検出しており、センサ/通信モジュール1460内のセンサモジュール1260部の位置や駆動/通信モジュール1470内の駆動モジュール1270部の位置を検出して無い。従って所定部屋入り口扉や鉄道関連の改札機(ゲート)の通行管理などに関しては、上記センサ/通信モジュール1460−5の代わりに無線通信に対応した通信モジュール1202単体を使用しても良い。
そしてユーザが所定入り口扉前や改札機(ゲート)の通過口の直前に来た時、あるいは自動販売機や店舗の購入窓口に近付いた時点で自動的に『プラグイン処理』(4.2節)が行われる。その後ユーザがその場を離れると自動的に『プラグアウト処理』が行われるが、ユーザのゲート(出入り口扉や改札機)の通過履歴や購入決済履歴はシステムコントローラα_1126が管理している。更にこのセンサ/通信モジュール1460−5の位置検出(4.2節参照)を利用して、ユーザのプラットフォームから線路上への異常落下などの緊急事態も自動的に認識できる。
特に所定入り口扉前や改札機(ゲート)の通過口では、通過するユーザが個人照合用に所定場所へ手をかざしても良いし、指を置いても良い。そしてこの場合の個人認証方法として手相の照合や指紋照合に限らず、手のひらや指表面近傍で反射した近赤外光を利用した静脈パターンの撮像により本人照合を行っても良い。更に手や指を使わず、顔認識により本人照合を行っても良い。ここではユーザの個人照合に先立ち、ユーザが所定入り口扉前や改札機(ゲート)の通過口の直前に来た段階で上記のプラグイン処理を行う。そしてこのプラグイン直後にセンサ/通信モジュール1460−5または通信モジュール1202の固有な識別情報(例えば図12A(e)のIEEE拡張アドレスEXADRSなど)を利用し、システムコントローラα_1126(図8Aあるいは図8B参照)はサーバn_1116−nにアクセスして事前に個人照合(認証)用の情報(手相/指紋/静脈パターン/顔パターンなど)を入手して置く。そして事前に入手した個人照合(認証)用情報と所定入り口扉前や改札機(ゲート)の通過口で入手した情報とを照合する。ここで照合情報と合致したユーザのみを入り口扉や改札機(ゲート)を通過させるとともに、前記照合情報を破棄する。このようにプラグイン直後にシステムコントローラα_1126が事前に個人照合(認証)用情報を入手するので、迅速な個人照合(認証)が行える効果が有る。
また電子決済時にユーザの確認が必要な場合には、ユーザに許諾を示す音声(許諾単語など)を発してもらう。そしてセンサ/通信モジュール1460−5からの音声(または発生単語)情報を図8Bのシステムコントローラα_1126が受け取ると、サーバn_1116−nからの情報を利用して“ユーザの声紋照合”が行われる。そして上記の声紋と、センサ/通信モジュール1460−5が所有するIPアドレス情報(図13(b))またはIEEE拡張アドレスEXADRSに対応した情報との間の照合確認による個人認証が行われる。次にこのシステムコントローラα_1126が音声認識技術によりユーザが発した単語が“電子決済への合意意志”を示すか否かを推定/判断しても良い。そして上記全ての確認が完了すると、システムコントローラα_1126とユーザの銀行口座管理に関係するサーバn_1116−n間の通信が行われ、電子決済が完了する。
上記に説明した“物流管理”/“ゲート通過管理”/“商品購入時の電子決済”のいずれにも本実施携帯システムを応用すると、対応するセンサ/通信モジュール1460−5を非常に安価に製造して多量に流通できる効果が有る。従来位置検出に使用するGPS(Global Positioning System)関連部品は非常に高価なため、多量な流通が難しかった。それに比べて本実施形態ではセンサ/通信モジュール1460−5が通常放出する無線電波を利用して位置検出するため、このセンサ/通信モジュール1460−5の位置検出のために追加する費用が掛からない。そのため、このセンサ/通信モジュール1460−5が非常に安価に製造できる。
今までの社会インフラ分野での適用例として、主にセンサ/通信モジュール1460の活用を中心に説明した。しかしそれに限らず、駆動/通信モジュール1470を移動制御部に内蔵させた移動ロボットへの遠隔操作に利用しても良い。例えばホテルや集合住宅地の部屋毎にセクション1_1142−1〜m_1142−mを定義する。そしてこの駆動/通信モジュール1470の位置検出技術を用いてシステムコントローラα_1126が制御し、この移動ロボットを所定の部屋の入り口まで移動させる。この移動ロボットに所定部屋内の掃除をさせても良いし、所定荷物を運搬させても良い。
また上記の適用例以外として、農業にも適用出来る。すなわち植物工場内では、例えば生育する植物の種類毎に異なるシステムα_1132、β_1134に分けてそれぞれ異なる生育条件で生育する。更に同種植物の生育場所毎にセクション1142に分割し、このセクション毎に光の照明量や水分の供給/補給量、温度、湿度管理をすると共に、植物の生育状態管理を行っても良い。
5.3節 ヘルスケア分野への適用例
5.3.1節 広域ネットワークシステムのヘルスケア分野への適用例
図1に示した広域ネットワークシステムのヘルスケア分野への適用例としては例えば、国家に対応する卸売業者B1_1104−1の委託を受け、特定な公的機関に相当するサービスプロバイダB_1112−2が病院や地域の医療機関に相当するシステムα_1132から患者の病名と症状や患者個々の遺伝子情報を収集し、全国的な病気に関する情報の収集と整理を行う方法を想定できる。この場合、この公的機関(サービスプロバイダB_1112−2)が病院や地域の医療機関(システムα_1132)内のデータベースを管理するシステムコントローラα_1126にネットワーク経由でアクセスし、自動的に必要な情報を収集する。その結果得られた解析結果は国家(卸売業者B1_1104−1)に報告され、インターネット経由または新聞/雑誌などの報道手段により国民に公開される。
5.3.2節 複合モジュールのヘルスケア分野への適用例
図5の構造を有するセンサ/通信モジュール1460は、軽量、小形、省電力(外部からの電源供給が不要)、低価格と言う多数のメリットを有する。そのためこれらのメリットを生かし、センサ/通信モジュール1460を移動するユーザの人体に直接装着する事が出来る。具体的な装着方法として、腕時計や眼鏡やネクタイピンなどのように装着部材を利用して上記センサ/通信モジュール1460を人体に直接的に装着しても良いし、あるいは衣服に固定しても良い。そして温度センサや脈拍センサ、呼吸センサ(加速度センサ)、血流中の酸素濃度センサなどと組み合わせたセンサ/通信モジュール1460を患者や健常人に装着してもらい、リアルタイムで健康状態をトレースできる効果が有る。更に病室単位あるいは個人の居室単位に設置したシステムコントローラα_1126によりリアルタイムで検出結果を解析し、異常時のみ医者や看護婦に通知する事で患者や健常人に対する効率の良いケアが実現できる効果が有る。更に必用な情報のみ選別して病院毎に設置されたサーバn_1116−n(図1)に通信できるので、サーバn_1116−n内でのデータ管理やデータ処理の効率も上がる効果が有る。
上記に説明した方法は、複合モジュールを人体に直接装着する方法を説明した。しかしそれに限らず、複合モジュール(例えば図2の複合モジュール7_1295−7)を人体内に直接挿入/侵入あるいは埋め込んでも良い。この場合には複合モジュール7_1295−7がネットワークシステムα_1132内に単独で設置される代わりに、人体(特定ユーザ)内に組み込まれて人体(特定ユーザ)と共に移動する形態を取る。所で上述した複合モジュールを人体に装着する方法では、複合モジュールの脱着時にユーザへの精神的負担を掛ける(ユーザが面倒に感じる)。それに比べて後述するように予め複合モジュールを人体内に挿入/侵入/埋め込みする(組み込む)事で、複合モジュール脱着の負担をユーザに掛けずにユーザ関連情報をシステムコントローラα_1126側で適宜入手できる効果が有る。
まず始めに複合モジュールの人体内への埋め込み方法を説明する。患者に対する切開手術直後の縫合箇所近傍に、図4A(b)に示した複合モジュール1295を埋め込む方法が有る。ここで手術後経過として、切開部位あるいは患部摘出(切断)部位が化膿する危険性や内出血する危険性が有る。そのため患部摘出(切断)部位の化膿発生や内出血を一刻でも早く発見して善処する事が、手術後の処置として重要となる。所で切開部位あるいは患部摘出(切断)部位にバイ菌が混入して化膿した場合には、化膿箇所のpH値(水素イオン指数)が変化する。従って縫合箇所に埋め込む複合モジュール1295として、pH値を検出するpHセンサモジュールや血液センサモジュールが内蔵されたセンサ/通信モジュール1460を使用しても良い。
またこの場合、手術後の経過観察する期間はそれ程長く無くて良い。よれゆえ1.6節内で説明したように、図7B内の寿命管理データ1794あるいは稼動期間管理データ1795を利用して手術後経過観察期間のみセンサ/通信モジュール1460が稼動する制御を行っても良い。またそれに限らず、図5に示したセンサ/通信モジュール1460内の蓄電モジュール(電池)1554の耐用期間(電池寿命)を予め短く設定し、手術後経過観察期間が過ぎたら電池寿命に拠りセンサ/通信モジュール1460が動作不能にしても良い。それにより手術後経過観察期間以降の複合モジュール1295(センサ/通信モジュール1460)からの不要な無線電波発信を防止し、ネットワークシステムα_1132内のネットワーク通信を制御/管理するシステムコントローラα_1126の負担を軽減できる効果が生まれる。
次に複合モジュールの人体内へ挿入する方法あるいは侵入させる方法に付いて説明する。この場合には図4A(b)の形態を取る複合モジュール1295をカプセルの中に封入し、ユーザに水や清涼飲料水などと共に前記カプセルを飲み込んでもらう。例えば前記カプセルが混入した清涼飲料水の販売価格を安くする事で、ユーザへの精神的負担を軽減しながら複合モジュール1295を体内に侵入させられる。またそれに限らず、例えば持病持ちのユーザが定期的に薬剤を飲む時に、一緒に前記カプセルを飲み込んでもらっても良い。そして複合モジュール1295内蔵の前記カプセルはトイレなどで排泄されるまでユーザの体内に留まり、ユーザ情報を発信し続ける事が可能となる。また上述したように寿命管理データ1794や稼動期間管理データ1795あるいは蓄電モジュール(電池)1554の電池寿命を活用して、排泄後の複合モジュール1295からの不必要な無線電波発信を防止できる。
所でこの方法の活用例としては、ユーザの健康管理や発病/発症の早期発見あるいはユーザの日常での運動状態管理などが上げられる。まずユーザの健康管理や発病/発症に関する早期発見への応用例を説明する。この場合には、図4A(b)の通信以外の機能を有する他機能モジュール1440として図4B(b)のセンサモジュール1260を使用する。そしてこのセンサモジュール1260の一例として、体内の体温を測定する温度センサモジュールを利用しても良い。
従来インフルエンザに掛かっている患者の早期発見方法として、例えば空港ゲートなどに赤外線を用いたユーザの体表面温度を測定するセンサを設置する方法が有る。しかしユーザがインフルエンザ発症により体温上昇する前(すなわち発症直前)に設置された温度センサを通過した場合には、インフルエンザ患者を見逃す危険性が有る。それに比べて温度センサモジュール1260内蔵のカプセルを用いて経時的に体温変化を追跡する事で、インフルエンザ患者の発見精度が向上する効果が有る。
また上記カプセルに内蔵させるセンサモジュール1260の他の例として、血糖値測定可能なセンサモジュールを使用しても良い。この方法は、血液中から得られる近赤外光スペクトルパターンから、血液中の糖質含有量を測定する。糖尿病患者は健常者と比べて、血糖値(血液中の糖質含有量)が高くなる傾向が有る。そして糖尿病患者の血糖値が許容範囲を超えた時、投薬などの迅速な対応が必要となる。従って血糖センサモジュールを内蔵したカプセルが患者の体内で常時血糖値をモニタする事で、迅速な血糖値異常の発見が可能となり、糖尿病患者の治療効果が上がる。
従来病院や施設では、看護師が定期的に入院患者の体温や血糖値を測定していた。それに比べて複合モジュール1295内蔵カプセルを定期的に入院患者に服用してもらう事で、患者病状の急変に対して即座に処置できるだけで無く、体温や血糖値測定に掛かる人件費節約に拠る病院運営や施設運営の効率化も図れる効果が有る。更に図31〜図34を用いて4.4節で説明した方法で複合モジュール1295の位置検出を組み合わせる事で、病院内や施設内での認知症患者の徘徊を検出できる効果も有る。
また上記の複合モジュール1295内の自己属性データ1793の一部として“薬を飲んだ人の名前”も“薬の名前”と一緒に記録しても良い(1.6節内該当箇所参照)。ここで病院や施設に設置された関しカメラで常時モニタし、入院患者や入居者が指定の薬を飲んだタイミングを管理する。そして入院患者や入居者が指定の薬を飲んだ時に、システムコントローラα_1126が複合モジュール1295内に上記の情報を記録する。これにより入院患者や入居者の服薬状況を常時管理できるので、飲み忘れ防止に役立つ効果が生まれる。
次にユーザの日常での運動状態管理への活用例の説明をする。この場合には、上記カプセルに内蔵させるセンサモジュール1260として加速度センサを使用しても良い。そして体内に組み込まれた加速度センサ出力と上述した複合モジュール1295の位置検出情報を組み合わせる事で、ユーザの運動状態がリアルタイムで逐次モニタできる。そして管理したユーザの日常での運動量が所定目標値に対して未達の場合には、システムコントローラα_1126内のユーザI/F部1234あるいはシステムコントローラβ_1128内の表示部から対処方法の提案がユーザに対して呈示される。
また図37Gを用いて説明した『通常では有り得ない組み合わせの検出』を薬の飲み合わせ可否判定に利用する実施形態システム例を下記に説明する。一般的に複数の薬が組み合わせて患者に処方される場合が多い。この場合の異なる薬の飲み合わせ可否の自動判定が可能となる。例えば薬の錠剤内にそれぞれ複合モジュール1295(ユニット1290)を混入させる。前述したように前記複合モジュール1295(ユニット1290)は人体に無害な材質で構成されたカプセル内に封入する。そして患者のトイレでの排泄と同時に前記カプセル毎体外に出せば、前記複合モジュール1295(ユニット1290)が人体に影響を及ぼす事は無い。このように薬の錠剤内に混入させた複合モジュール1295(ユニット1290)内蔵カプセルも、前述した同様の方法で体外に出た段階で無線電波放出を停止させる。
所で前記複合モジュール1295(ユニット1290)は、図4Aが示すように通信モジュール1660を含む。また図7Bのように、この通信モジュール1660内に自己属性データ1793が予め記録させている。そして本実施形態システム例では、この自己属性データ1793内に薬の識別データが格納されている。
所で図2が示すように、処方された複数の薬の検査を行う専用の薬検査用システムコントローラα_1126内のメモリ部1232に、予め組み合わせ可能な薬のデータテーブル及び健康上問題となる薬の組み合わせを示したデータテーブルが記録されている。そして患者あるいは調剤した薬剤師が処方された複数の薬を持って前述した薬検査用システムコントローラα_1126の前を通過した瞬間に、高速かつ容易に薬の組み合わせ可否が判別できる。
本実施形態システムでは4.4節で説明したように、全てのユニット1290あるいは複合モジュール1295の配置場所がリアルタイムで検出可能となっている。従って薬剤に混入させた複合モジュール1295(ユニット1290)が所定場所を通過すると、薬検査用システムコントローラα_1126が適宜その状況を検出する。そして薬検査用システムコントローラα_1126から薬剤に混入させた複合モジュール1295(ユニット1290)に対して自己属性データ1793(薬の識別データ)回答を要求する事で、薬検査用システムコントローラα_1126は処方された複数の薬の内容を適宜監視できる。薬検査用システムコントローラα_1126が収集した薬剤情報を上述したデータテーブルと参照させる事で、容易に飲み合わせが不適合な薬剤の組み合わせを抽出できる。そして不適正な薬剤の組み合わせが見付かった場合には、適宜ユーザあるいは薬剤師に対してディスプレイ或いは音声で警告を発する。
従来も調剤薬局毎あるいは病院の医局毎に健康上問題となる薬の組み合わせを示したデータテーブルが管理されている。また日本では患者各自専用の『薬手帳』が存在し、患者の過去に服用した薬剤履歴が分かるシステムになっている。従ってその薬手帳を利用する事で、薬剤師は不適正な薬の飲み合わせの判別が容易となるっている。従って前記データテーブルと前記の薬手帳を参照する事で、容易に不適合な薬の飲み合わせの確認が可能となる。しかし調剤薬局や病院の医局が非常に混雑して薬を待つ患者が多くなった場合には、薬剤師がその都度データテーブルを参照する時間を持つ余裕が無くなる。その場合には薬剤師の記憶に頼って不適正な薬の飲み合わせ判別が行われる機会が多くなる。その結果、薬剤師の記憶違いで不本意にも不適正な薬の組み合わせを処方するリスクが皆無とは言えない。
上述した本実施形態システム応用例を利用すると、薬剤師による手作業でのデータテーブル参照が不要となる。その結果として調剤薬局の調剤効率が大幅に向上するだけで無く、非常に高速でかつ精度良く薬の飲み合わせが自動的にチェックできる効果が生まれる。また薬局や病院の医局では人手(薬剤師)による調剤を行うため、どうしても調剤ミスのリスクが伴う。それに対して本実施形態システム応用例を利用する事で、高精度で調剤ミスの検出が可能となる。その結果、患者の服薬に対する安心度も大幅に向上する効果も生まれる。
なお本5.3.2節では複合モジュール1295(またはユニット1290)を体内に入れる方法として、複合モジュール1295(またはユニット1290)をカプセル内に内蔵させる方法で説明した。しかしそれに限らず、あらゆる手段を用いても良い。例えばカプセル内に入れる代わりに1チップ(もしくはハイブリッドチップ)で構成された複合モジュール1295(またはユニット1290)を、人体に無害な材質でラミネート(あるいはコーティング)しても良い。
5.3.3節 セクション分割方法のヘルスケア分野への適用例
セクション分割方法のヘルスケア分野への適用例として、5.2.3節と同様に病棟のフロア単位や病室単位にセクション1142の分割を行っても良いし、また病棟の医科単位でのセクション1142の区分けを行ってもよい。そして本実施形態システムでは、ここから得られた各種センサ情報をこのセクション1142毎に統合/管理しても良い。それにより階層別セクション毎の状況把握として、例えばナースコール頻度や急に症状が悪化する患者の発生頻度を把握できる。そしてその把握結果をナースなどの人員配置計画に反映する事で、病院内での患者ケアサービスの質を向上できる効果が有る。
一方ヘルスケア分野への応用例として、一体の人体内の部位毎にセクション1_1142−1〜m_1142−mに分割しても良い。ここで人体に関するセンス情報として、局所的な体温や局所的な発汗量、局所的な骨格筋の緊張割合、局所的な血管内の酸素濃度変化、局所的な脈拍状態など多種多様なセンス情報が得られる。これらの各種センス情報をセクション1142毎に統合/管理する事で、リアルタイムで異常箇所が把握し易いため、急激な症状悪化部位の抽出や患者の病状把握が容易となる効果が有る。
以下の説明において、図1〜図37Hで用いられた参照符号と同一または共通部分を含む参照符号は、互いに同等または対応する構成に付されている。同一または共通部分を含む参照符号を持つものは、同様に構成できるものとする。例えば、図21A〜21Dで用いられた参照符号(2600、2614、2622、2634など)は図38Bでも用いられている。図が異なっていても、同じ参照符号が付されたものは同様に構成でき、あるいは互いに置換できる。また、図21Aの参照符号2600と図28Bの参照符号2600aは共通部分(2600)を含んでいる。これは、図21Aのユニット管理擬似ドライブ(2600)が図38Bのユニット管理擬似ドライブファイルa(2600a)に対応または関連することを示唆している。
図2その他の実施形態に示されるサーバ1116−nおよび/またはシステムコントローラ1126は、システムコントローラ1126へ直接または間接的に接続されるユニット(デバイス、複合モジュールなど)をファイル管理するとともに、使用する(または使用され得る)コンピュータプログラム等をファイル管理することができる。そのための管理ファイル/データファイル4000の一例が、図38Aおよび図38Bに示されている。サーバおよび/またはシステムコントローラは、この管理ファイル/データファイル4000(またはそのコピー)を、持つことができる。
図38Aおよび図38Bは、一実施の形態において使用される管理ファイルおよびデータファイルのファイル管理構造を説明する図である。図38Aにおいて、管理ファイル/データファイル4000のルートディレクトリには、管理情報ファイル(MNGR.IFO)4100、クラスライブラリ(サブルーチン、マクロ、アルゴリズムなどのライブラリ)4200、プログラム言語変換ソフトファイル4300、フォーマット変換プログラムファイル4400、アプリケーションプログラムファイル4500などを配置できる。
管理情報ファイル4100内には、1以上のユニット(1〜n)の位置情報を格納したフォルダ4102と、これらのユニットの一部または全部を制御するプログラムの管理情報を格納したフォルダ4104が設けられている。1以上のユニットがインターネット上に存在するときは、その位置情報としてURLをフォルダ4102で用いることができる。(なお、ユニットの具体例については、図2、図39その他に図示されたユニット、あるいは図10Aその他に図示された複合モジュールを参照。また、各種のモジュールと各種の情報/コードとの対応関係例については、図23等を参照。)
フォルダ4104のプログラム管理情報は、各プログラムを識別するプログラム番号や各プログラムの対応情報を含むことができる。この対応情報により、各プログラムと、そのプログラムに適合するセンサおよび/またはそのプログラムに適合するアクチエータとの適合性(相性)などを示すことができる。
ここで、対応情報の具体例を挙げる。フォルダ4104のプログラム管理情報は、管理されている1以上のプログラムのプログラム番号(プログラムのID)と、そのプログラムに適合するセンサおよび/またはアクチエータの対応関係を示す対応表を含むことができる。例えば、多数のプログラム中に温度制御プログラム(プログラム番号a)があり、多数のセンサの中に温度センサ(デバイスID=b)があり、多数のアクチエータの中にヒーター(デバイスID=c)ががあったとする。その場合は対応表のプログラム番号aの行にデバイスID=bとデバイスID=cが記載される。あるいは、多数のプログラム中に照明制御プログラム(プログラム番号x)があり、多数のセンサの中にフォトダイオード(デバイスID=y)があり、多数のアクチエータの中にLEDライト(デバイスID=z)があったとする。その場合は、対応表のプログラム番号xの行にデバイスID=yとデバイスID=zが記載される。このような記載により、例えば、「ID=yのフォトダイオードとID=zのLEDライトは番号xのプログラムに適合する」あるいは「番号xのプログラムにはID=yのフォトダイオードとID=zのLEDライトを使用できる」といったことを、対応情報(対応表)で示すことができる。
フォルダ4104のプログラム管理情報で管理されるプログラムには、予め用意されたオリジナルプログラムと、使途に応じて後に作成されたユーザ定義プログラム(オプション)が含まれる。例えばインターネットなどからダウンロードするJavaアプリケーション(アプレット)は、後に入手するプログラムであっても、ユーザが作成したプログラムではなくて予め用意されたプログラムであれば、オプション扱いでオリジナルプログラムに分類できる。一方、Javaアプリケーション(アプレット)が使途に応じてユーザにより作成されたプログラムなら、ユーザ定義プログラムに分類できる。
なお、アプレットは、ほぼ完全なJava環境であり、オブジェクト指向プログラミングにより高機能なアプリケーションを作成できる。アプレットをHTMLに埋め込むことにより、高機能アプリケーションをWeb配信できる。
アプレットをHTMLに埋め込む技術とは異なるが、HTML内にジャバのコードを埋め込んでおき、Webサーバで動的にWebページを生成してクライアントに返す技術として、Java Server Page(JSP)がある。JSPはサーブレットの機能の1つとして実装されるが、HTML内に記述される点でサーブレットと違いがある。サーブレットではJavaのプログラムコードの中にHTMLコードが混在しているが、JSPではプログラムコードとHTMLコードが極力分離されている。具体的には、JSPでは、ジャバのコードを"<%"と"%>"の記号で囲んだ部分に記述してHTMLコードから分離している(すなわち、HTMLの記述はそのままで、ジャバのコードが埋め込まれる)。HTMLの中でその分離された部分のスクリプトが断片的に見えることがあるため、この記法をスクリプトレットと呼ぶこともある。定義されたカスタムライブラリを用いて、スクリプトレットを使わずに独自のタグでジャバのコードを埋め込むことも可能である。つまり、HTML内には、JavaScript(登録商標)に限らず、ジャバのコードを埋め込むこともできる。
ユーザ定義プログラムは、既存のライブラリを利用して作成できる。Javaを用いてユーザ定義プログラムを作成する場合は、クラスライブラリ4200内のJavaクラスライブラリ4210を利用できる。Javaには、豊富なクラスライブラリが標準ライブラリ4212として存在する。もし標準ライブラリ4212中に所望のクラスライブラリがないときは、ユーザが独自にJavaで所望のクラスライブラリ(サブルーチン、マクロ、グローバル変数など)を作成し、それをユーザ定義ライブラリ4214(オプション)に登録できる。あるいは、標準ライブラリ4212に含まれる2以上の任意のクラスの内容(メソッドまたは関数)を組み合わせて、その組合せをユーザ定義ライブラリ4214に登録できる。このような標準ライブラリ4212およびユーザ定義ライブラリ4214を含むJavaクラスライブラリ4210を利用して、ユーザ定義プログラムを適宜作成できる。例えば、クラスライブラリに含まれる2以上のmathクラスを組合せて、ある数値演算を行うユーザ定義プログラムを作成できる。
ここで、Javaのクラスについて簡単に述べておく。クラスとは、データ(属性)と手続き(振る舞い:メソッド)を1つにまとめたものである。クラスがプログラムの基本単位となる。クラスを雛形にして生成されたオブジェクトを、Javaではインスタンスという。
Javaのクラスには、抽象クラス(abstract class)と、ファイナルクラス(final class)と、パブリッククラス(public class)の3種類がある。抽象クラスは不完全なクラス(共通機能を実装し個別機能は抽象的に定義するクラス)であり、ファイナルクラス(final class)はサブクラスが存在しないクラスであり、パブリッククラス(public class)は他のパッケージからアクセスできるクラスである。
Javaのメソッドには、静的なものと非静的なものがある。静的メソッド(static method)は、呼び出す際にインスタンスを必要としない。static修飾されない非静的メソッドは呼び出す際にインスタンスが必要となる。静的メソッドはインスタンスではなく「クラスに属するメソッド」のため、インスタンスを作らずに直接呼び出すことができる。静的メソッドは、インスタンスと関係ないため、自クラスのインスタンスに格納されている普通のフィールド(非staticフィールド)にはアクセスできず、同じく普通のメソッド(非staticメソッド)を呼び出すこともできない。staticからアクセスできるのはstaticだけ、ということになる。
Javaのクラスライブラリ4210とは異なるが、JavaScriptにもライブラリ(種々な処理を行うサブルーチン群などのライブラリ)4220が存在する。Javaクラスライブラリ4210と同様に、JavaScriptのライブラリ4220も、デフォルトで用意された標準ライブラリ4222と、ユーザが作成したユーザ定義ライブラリ4224(オプション)を持つことができる。クラスライブラリ4200はさらに、その他の言語(C++、PHPなど)のライブラリ4230を、オプションで持つことができる。
プログラム言語変換ソフトファイル4300は、変換ソフトウエアを1以上含むことができる。この変換ソフトウエアにより、あるプログラミング言語のコードを、別のプログラミング言語のコードに変換できる。プログラム言語変換ソフトファイル4300に複数の変換ソフトウエアが格納されているときは、個々の変換ソフトウエアのユニークな名称または個々の変換ソフトウエアに付与されたユニークなIDにより、所望の変換ソフトウエアをファイル4300から呼び出して使用できる。
上記変換ソフトウエアの一例として、Google Web Toolkit(GWT)がある(最新版のJava8に対応したGWT2.7は、インターネットから入手できる)。GWTに含まれるクロスコンパイラを用いて、Javaで記述したプログラムをJavaScriptなどに変換できる。具体的には、ジャバのコード(Javaで作成されたソースコードまたはバイトコード)を、GWTを用いて、HTML(HTML5 + JavaScript + CSS3)またはAjax(Asynchronous JavaScript + XML)のコードに変換できる。GWTは、ホステッドモードとウェブモードで動作する。ホステッドモードでは、プログラムはJavaバイトコード(JBC)としてJava Virtual Machine(JVM)上で動作する。ウェブモードでは、HTML+JavaScript(元はJavaのソースコード)として動作する。このような変換ソフトウエア(GWT)を、プログラム言語変換ソフトファイル4300に格納しておくことができる。
なお、Javaでは、GWTのJavaScript Native Interface(JSNI)を利用できる。GWTのJSNIを使うことによって、Javaクラスと並列にJavaScriptを作成できるようになり、クライアントサイドの(Webアプリの)メソッドを、Javaで実装できるようになる。換言すると、JavaScript(ブラウザのネイティブ言語)を介して、ジャバのコードとJavaScriptのコードとの間で情報交換できるようになる。すなわち、Javaバイトコードを生成するプログラム言語(Javaなど)と、Javaバイトコード以外のコードを使うアプリケーション(Ajaxなど)との間の橋渡しが、JavaScriptを介して可能になる(このことは、あるHTML文書内で、JavaScriptとJavaバイトコードを、単得または相互に利用し得ることを示唆している)。そうすると、既存のJavaScriptをJavaで囲い込む(ラップする)ことができ、あるいは、JavaScriptからJavaの豊富なライブラリ4210を利用する途が開ける。
Javaでは、Java Native Interface(JNI)を利用することもできる。JNIは、Javaプラットフォームにおいて、Java言語で記述されたプログラムと、他の言語(CやC++など)で記述された実際のCPU/MPU上で動作するネイティブコードとを連携させるインターフェース仕様である。JNIは、Java言語からネイティブコードを利用するインターフェースと、逆にネイティブコードからJavaバイトコードを動作させるための、JVMを利用するインターフェースを持つ。JNIとC++を使うことで、Javaバイトコードの一部(例えば、動画のエンコード/デコードのような高速処理を必要とする部分)を部分的にネイティブコードに置き換えて、Javaバイトコードだけ(あるいはJavaScriptとJavaバイトコードだけ)の場合よりも総合的な処理速度を高める、といったアプローチが可能になる。
なお、Javaクラスライブラリ4210に含まれるライブラリの一部または全てを、GWTのような変換プログラムを用いて、JavaScriptのライブラリに変換することも可能である。変換後のライブラリは、JavaScriptライブラリ4220内のユーザ定義ライブラリ4222に登録できる。
本願の実施形態では、以下のフォーマット(詳細は既述)を採用できる:
(01)「テキスト」形式で記述されるA−フォーマット;
(02)「コマンド/リクエスト/レスポンス/ステータス」形式で記述されるC−フォーマット;
(03)「所定領域内に設定コードを格納する」形式で記述されるE−フォーマット;
(04)「指定された欄に送信側で情報入力する」形式または、「マークアップ言語(HTML/HTML5)の“タグ”を記載する」形式で記述されるW−フォーマット。
管理ファイル/データファイル4000のルートディレクトリには、フォーマット変換プログラムファイル4400が配置されている。例えばUSBやBluetoothで送受されたデータをIPフォーマットに変換してインターネットで送信する従来技術は存在する。これと同様に、例えばCフォーマット(コマンド/リクエスト/レスポンス/ステータスなどの記述を用いるフォーマット)をWフォーマット(開始タグと終了タグでマークアップされたJavaScriptなどによりCフォーマットの処理内容を記述したフォーマット)に変換(あるいはその逆方向に変換)することができる。何を何に変換するのかが明確であれば、あるフォーマットのデータ(データ構造が明確な或るデータ)を、対応する内容を持った他のフォーマットのデータ(データ構造が明確な他のデータ)に変換するソフトウエアを作成することは、当業者なら可能である。(そのようなソフトウエアは、既存のプログラム言語、例えばJava、JavaScript、C++などを用いて作成できる。)
フォーマット変換の種類の数に応じて、1以上のフォーマット変換プログラムを、フォーマット変換プログラムファイル4400に格納しておくことができる。例えば、Cフォーマットの情報(コマンド/リクエスト/レスポンス/ステータスなどの記述)をWフォーマットの情報(開始タグと終了タグでマークアップされた記述)が含むように変換するときは、そのための変換プログラムをファイル4400から読み出して使用できる。あるいは、Wフォーマットの情報の一部(マークアップされた記述内でCフォーマットに変換できる情報部分)をCフォーマットに変換するときは、そのための変換プログラムをファイル4400から読み出して使用できる。
管理ファイル/データファイル4000のルートディレクトリには、アプリケーションプログラムファイル4500が配置されている。アプリケーションプログラムファイル4500は、オリジナルプログラムを格納するフォルダ4510と、ユーザ定義プログラムを格納するフォルダ4520を含んでいる。オリジナルプログラムおよびユーザ定義プログラムは、管理情報ファイル4100内のフォルダ4104に格納された管理情報により管理される。
オリジナルプログラムフォルダ4510内のオリジナルプログラムには、予めシステムに組み込まれたプログラムの他に、ネットからダウンロードするなどして後天的に得た種々なアプリケーション(アプレットなど)も含まれ得る。(オリジナルプログラムには、JavaScriptを用いたスクリプトを含めることもできる。)
ユーザ定義プログラムフォルダ4520内のユーザ定義プログラムには、オリジナルプログラムにはないユーザが作成したプログラムが含まれる。具体的には、Javaの標準ライブラリ4212および/またはユーザ定義ライブラリ4214から、目的に応じたクラス(所望のメソッドまたは関数が記載されているクラス)を1つまたはそれ以上取り出し、それらを繋ぎ合わせることで、ユーザ定義プログラムチェーン45221を作成できる。(取り出したクラスが1つしかない場合でも、その1つのクラスの記述内容を変更してユーザ定義プログラムチェーンとすることができる。)
例えば、m個のセンサ出力のうち値の大きなn個のセンサ出力を取り出したいときは、m個のセンサ出力を「大きさ順にソートする」メソッドが記述されたクラスC1と、ソート結果の値を「上位値から順にn個取り出す」メソッドが記述されたクラスC2を用い、プログラム本文にC1+C2に相当する記述を含むJavaのソースコードを作成する(C1とC2は標準ライブラリ4212またはユーザ定義ライブラリ4214にあるものとする)。この「C1とC2の繋がり」を示す情報を、ここでは1番目のユーザ定義プログラムチェーンUD_PGC1とする。(あるいは、クラスC1を「m個のセンサ出力を大きさ順にソートし、ソート結果の値を上位値から順にn個取り出す」という記述内容に変更してUD_PGC1を作成してもよい。)
同様に、所望の処理内容に応じた1以上のクラスCiの繋がりで、p番目のユーザ定義プログラムチェーンUD_PGCpを生成できる。ここで、クラスCiのサフィクス"i"はクラスを識別するIDで、"i"の値を指定すればそのクラスをJavaクラスライブラリ4210(4212または4214)から呼び出すことができる。
もし、ユーザ定義プログラムチェーンUD_PGCiが、「C3+C4+JSk」のように、Javaのクラス(C3、C4)以外にJavaScriptのライブラリの一部(JSk)も含んでいるときは、サフィクス"k"の値を指定することで、そのJavaScriptのライブラリJSkをJavaScriptライブラリ4220(4222または4224)から呼び出すことができる。(GWTに関連して前述したように、JavaScriptを介して、Javaバイトコードを生成するプログラム言語と、Javaバイトコード以外のコードを使うアプリケーションとの間の橋渡しが可能となっている。)
生成されたp個のユーザ定義プログラムチェーン(UD_PGC1〜UD_PGCp)45221〜4522pは、ユーザ定義プログラムフォルダ4520に格納される。格納された任意のユーザ定義プログラムチェーンUD_PGCj(j=1〜p)は、"j"の値を指定すればユーザ定義プログラムフォルダ4520から呼び出すことができる。呼び出されたユーザ定義プログラムチェーンUD_PGCjがJavaプログラムの場合、適宜、プログラム言語変換ソフトファイル4300内の変換ソフトウエア(GWTなど)を用いてJavaScript(あるいはHTMLやAjaxなど)に変換できる。変換したJavaScriptなどは、ユニークなプログラム名を付与して、そのプログラムで使用される関連情報とともにユーザ定義プログラムフォルダ4520内に格納することができる。
例えば、図22の処理をJavaScriptで記述し(あるいはJavaで記述したあとGWTなどによりJavaScriptに変換し)、そのJavaScriptに或るプログラム名(あるいはID)を付けて関連情報(例えば、図23、図27、図28その他の情報)とともにユーザ定義プログラムフォルダ4520内に格納できる。
また、図26A、図26Bの処理をJavaScriptで記述し(あるいはJavaで記述したあとGWTなどによりJavaScriptに変換し)、そのJavaScriptに別のプログラム名(あるいはID)を付けて関連情報(例えば、図23、図27、図28その他の情報)とともにユーザ定義プログラムフォルダ4520内に格納できる。
同様に、図29、図30の処理をJavaScriptで記述し(あるいはJavaで記述したあとGWTなどによりJavaScriptに変換し)、そのJavaScriptに他のプログラム名(あるいはID)を付けてユーザ定義プログラムフォルダ4520内に格納できる。
図38Bにおいて、管理ファイル/データファイル4000のルートディレクトリには、ユニットファイル4600、ユニット管理擬似ドライブファイルa2600a、およびユニット管理擬似ドライブファイルb2600bを配置できる。
ユニットファイル4600は、n個のユニットフォルダ4610−1〜4610−nを持つことができる。各ユニットフォルダ4610−1〜4610−nは、それぞれ、自分のセンサ4612−1〜4612−Nおよび/または自分のアクチエータ4614−1〜4614−Nを、擬似的なファイルとして持っている。(全てのユニットフォルダがセンサとアクチエータの双方を持っているとは限らず、その一方だけを持っている場合もある。また、1つのユニットフォルダが複数のセンサおよび/または複数のアクチエータを持つ場合もある。そのため、ユニットフォルダの数nは、ユニットファイル4600が管理するセンサの数またはアクチエータの数と、必ずしも一致しない。)
センサ4612−1〜4612−Nおよび/またはアクチエータ4614−1〜4614−Nの論理的存在は管理ファイル/データファイル4000内にあるが、これらのセンサおよび/またはアクチエータの物理的存在は遠隔地にあってもよい(物理的な遠近の程度は問わない)。そこで、ユニークなURL(例えば://www.……….Un)を用いて個々のユニットフォルダ(例えば4610−n)にネット経由でアクセスできるようにしている。すなわち、ネット経由で接続されたセンサ4612−N(擬似的ファイル)から情報を読み出し、あるいは、ネット経由で接続されたアクチエータ4614−N(擬似的ファイル)へ情報(動作指令など)を書き込むことができる。各ユニットフォルダのユニークなURLは、管理情報ファイル4100内の位置情報4102で管理することができる。
管理ファイル/データファイル4000のルートディレクトリにはさらに、ユニット管理擬似ドライブファイル2600aおよびユニット管理擬似ドライブファイル2600bが配置されている。これらのファイル2600aおよび2600bは、図21Aの(a)(b)で示したユニット管理擬似ドライブを、擬似的なファイルとして管理するファイルである。これらのファイル2600aおよび2600b内の情報は、アプリケーションプログラムファイル4500内のプログラム(Javaおよび/またはJavaScript)が、適宜利用できるようになっている。
ユニット管理擬似ドライブファイル2600a内には、一覧データ用フォルダ2610と機器対応フォルダ2612と複合モジュール対応フォルダ2614が格納されている。複合モジュール対応フォルダ2614内には、センサ/通信モジュール対応フォルダ2622と駆動/通信モジュール対応フォルダ2624とプロセッサ/通信モジュール対応フォルダ2626とメモリー/通信モジュール対応フォルダ2628と他機能/通信モジュール対応フォルダ2630が格納される(図21B参照)。センサ/通信モジュール対応フォルダ2622内には、2値データフォルダ2634と他値データフォルダ2638が格納される(図21C参照)。また、ユニット管理擬似ドライブファイル2600b内には、セクション1〜m内のユニット管理用フォルダ2616が格納されている。
なお、図38Aおよび図38Bのルートディレクトリにある管理情報ファイル4100以外の情報ファイル(4200〜4500、2600a、2600b)の一部または全部は、管理情報ファイル4100の下のサブディレクトリに配置されてもよい。
図38Aおよび図38Bの構成に関係した事項を、以下で整理する。管理情報ファイル4100は、1以上のユニット1〜nの位置情報4102および、プログラムの管理情報4104を含んでいる。ユニット1〜nの位置情報4102は、それらがシステム外部のネットワーク(インターネット)上に存在する場合は、URLによって示される。ユニット1〜nがシステム内部に存在する場合は、それらの位置情報には、IPアドレスなどの論理アドレス、および/またはMACアドレスなどの物理アドレスを用いることができる。
管理情報4104で管理されるプログラムには、デフォルトで用意されたオリジナルプログラムと、ユーザが独自に定義(または作成)したユーザ定義プログラムがある。オリジナルプログラムおよびユーザ定義プログラムは、アプリケーションプログラムファイル4500に格納しておくことができる。
管理ファイル/データファイル4000のルートディレクトリには、個別処理を扱うクラスライブラリ4200が配置されている。このライブラリ4200は、アプリケーションプログラムが呼び出して利用することができる、多種多様なライブラリを含む。図38Aの例では、Javaのクラスライブラリ4210と、JavaScriptのライブラリ4220が用意されている。さらに、オプションとして、クラスライブラリ4200は、JavaやJavaScript以外の言語(C++、PHPなど)のライブラリ4230も含むことができる。
Javaクラスライブラリ(JCL)4210は、Javaアプリケーションが実行時に呼び出せる動的ロード可能なライブラリ群である。Javaプラットフォームは特定のオペレーテイングシステム(OS)に依存していないので、JavaアプリケーションはOSが持つライブラリに依存できない。そのため、Javaプラットフォームは、現代のOSが提供している様々な機能を含む標準クラスライブラリ群を提供している。そのような標準クラスライブラリ群が、標準ライブラリ4212に格納され、自由に利用できるようになっている。
また、標準クラスライブラリ群にない機能(メソッド)が必要な場合、ユーザはJava言語によりユーザ所望のクラスを独自に作成(定義)することができる。あるいは、標準クラスライブラリ群から取り出した既存のクラスを幾つかを組み合わせて、新たにユーザ定義クラスを作成できる。ユーザが作成(定義)したクラスはユーザ定義ライブラリ4214に格納されて、適宜利用できるようになる。
Javaクラスライブラリ(JCL)4210は、Javaプラットフォーム内で次の役割を担っている:
(1)コンテナクラス群や正規表現処理などの機能群を、プログラマに提供する;
(2)ネットワークアクセスやファイルアクセスのようなハードウエアやOSに依存するタスクに対して、抽象クラス(abstract class)とインターフェース(interface)を提供する;
(3)Javaアプリケーションが期待する特定機能を完備していないプラットフォームに対しては、JCLを用いて欠けている特定機能をエミュレートしたり、JCLを用いて特定機能の有無をチェックする一貫した方法を提供する。
JavaScriptには、「クラス」という言語仕様は存在しないが、クラスを実現するために必要な言語仕様(function, this, call, new演算子, prototype chain, プロパティ:prototype)は存在する。そのため、実質的には、JavaScriptはJavaのクラスライブラリと同様なライブラリを持つことができる。デフォルトで用意された既存ライブラリを標準ライブラリとし、ユーザが独自に作成したライブラリをユーザ定義ライブラリとするならば、JavaScriptライブラリ4220にも、標準ライブラリ4222とユーザ定義ライブラリ4224を用意できる。
JavaScriptでは、"function"で「関数」を定義している。JavaScriptでは、"this"で「ある関数が呼び出された際にその関数を格納していたオブジェクト」を指す。JavaScriptでは、"call"は全ての関数が持っているプロパティであり、関数として呼び出すことができる。"call"を呼ぶと、callの第一引数として渡されたオブジェクトがthisにセットされて元の関数が呼び出される(第二引数以降は元の関数の引数として渡される)。JavaScriptでは、"new"は任意の関数と一緒に呼び出される。newと一緒に関数を呼び出すと、まず空のオブジェクトが生成され、次に関数が呼び出される。その際、関数内のthisが、生成されたオブジェクトを指す。関数が実行された後に生成されたオブジェクトは、newの実行結果として返される。
また、JavaScriptでは、"prototype chain"により、参照されたプロパティをオブジェクトが持っていなかった場合に、他のオブジェクトのプロパティを参照する。つまり、オブジェクトのプロパティが参照された際にそのプロパティをオブジェクト自身が保持していないときは、代わりにプロトタイプのオブジェクトのプロパティが参照される。プロトタイプのオブジェクトがそのプロパティを保持していないときは、さらにプロトタイプのプロトタイプが参照される。このように、プロトタイプとしてオブジェクトが鎖状に繋がれてそれらが順番に参照されることから、"prototype chain"と呼ばれる。JavaScriptでは、関数の"prototype"プロパティを使ってもプロトタイプを設定できる。この"prototype"プロパティにより、オブジェクトの直接のプロトタイプではなくて、「そのオブジェクトがコンストラクタとして利用された際に作成される新しいオブジェクト」のプロトタイプを決める。JavaScriptでメソッドを定義するときには、コンストラクタ関数のprototypeオブジェクトに関数を定義する。また、メソッド内から他のメソッドを呼び出す場合は「this.<メソッド名>(引数)」という記述を用いる。
実施形態の説明では、JavaScriptを、様々なECMA Scriptの実装を含んだ幅広い意味で用いている。その意味で、主要なWebブラウザが実装しているスクリプト言語は全てJavaScriptであるといえる。実施形態の説明では、特に断りが無い限り、Webブラウザが実装しているスクリプト言語は全てJavaScriptで代表することにする。
Webブラウザは、JavaScriptとCascading Style Sheets(CSS)が埋め込まれたHTML(HTML5 + JavaScript + CSS)で記述された処理、またはAjax(Asynchronous JavaScript + XML)で記述された処理を実行できる。このブラウザは、<script>と</script>で囲まれた内部をJavaScriptコードと認識して実行する。
HTML5 + JavaScriptのコードは、そのコード形式で直接記述する以外に、対応するJava言語のソースコード(またはJavaバイトコード)を変換ソフトウエアで変換しても得られる。この変換ソフトウエアの一例として、Google Web Toolkit(GWT)がある。
なお、CSSはレベル分けされており、現行レベルは3(つまりCSS3)である。将来的には、レベル3よりさらに機能拡張されたレベル4またはそれ以上のレベルが勧告されると予想される。HTML5で用いられる現行のCSS3では、2D/3Dのアニメーションなども扱うことができる。
ユニット管理擬似ドライブファイル2600aおよびユニット管理擬似ドライブファイル2600bは、図21Aの(a)(b)で示されるようなユニット管理擬似ドライブを、擬似的なファイルとして管理するファイルである。これらのファイル2600aおよび2600b内の情報は、アプリケーションプログラムファイル4500内のプログラム(Java、JavaScriptなど)が、適宜利用できるようになっている。
アプリケーションプログラムファイル4500内に所望のプログラムがないときに、ユーザ定義プログラム(制御プログラム)を作成する別の例を以下に示す。(ここでは制御プログラムの作成にJavaを用いて説明するが、制御プログラム作成にJavaScriptを用いてもよいし、GWTなどによりJavaプログラムをJavaScriptに変換することもできる。)
この制御プログラムは、例えば図2のシステム内で利用できる。図2において、システムコントローラ1126で管理される1以上のユニット1290−n各々には、所定のインターフェースを介して、1以上のデバイス(1以上のセンサ1260および/または1以上のアクチエータ1270)が、適宜、有線または無線で接続される。(ここで、nは任意の整数であり、図2の例では1〜7を示している。以下、任意整数の「−n」は省略する。)
各ユニット1290はUPnPサポートを搭載したシステムを採用しており、各ユニット1290のデバイスコントローラ1240は、新たに接続されたデバイス(センサおよび/またはアクチエータ)を、プラグ&プレイ(UPnP: Universal Plug and Play)で自動的に、自身のシステムに取り込む。このUPnPサポートを搭載したシステムは、新たなデバイスネットワークにおいて、中央コントローラやゲートウェイなど、さまざまな役割を果たすことができる。各ユニットとそこに接続される1以上のデバイスとの間で、小規模なUPnPネットワークが形成される。
(01)例えば、床上を任意方向に自由に動き回れるユニット1290を想定してみる。このユニット1290は、センサ1260およびアクチエータ1270として、位置センサ(図示せず)S0および全方向ボール車輪アクチエータ(図示せず)A0を予め装備している。このユニット1290に、画像センサ(図示しないカラーカメラ)S1および照明アクチエータ(図示しないRGB個別駆動のLED照明)A1が新たにUPnP接続されたとする。
(02)ユニット1290で稼動する既存の制御プログラムが新たに接続されたセンサS1およびアクチエータA1を想定していない場合、その制御プログラムではS1およびA1を用いた制御ができない。そこで、UPnPでS1およびA1が検出されると、ユニット1290のシステムは、該当ユニットの機能(位置検出機能と、撮影機能と、照明機能と、床上を任意方向に自由に動き回れる機能)に整合する範囲で、S1およびA1を用いた制御プログラムの候補を、システムコントローラ1126が持つアプリケーションプログラムファイル4500から探す。(このプログラム候補検索には、図38Aの管理情報4104が持つ対応情報を利用できる。)このプログラム候補は、例えば「暗くなったら所定の明るさになるまでLED照明し、照明後のホワイトバランスが崩れていたらホワイトバランスが取れるようにRGBの駆動割合を制御する」内容のプログラムであるとする。
(03)所望の制御プログラムの候補がシステムコントローラ1126のアプリケーションプログラムファイル4600から見つからないときは、同様なプログラムを、システムコントローラ1126に繋がっているサーバ1116へ探しに行くことができる(処理内容の文字列「照明制御、ホワイトバランス制御」をキーワードにして、Web検索エンジンと同様な手法で検索できる)。それでも所望の制御プログラム候補が見つからないときは、別のサーバ1116まで探しに行くこともできる(種々なプログラムを多数含むライブラリを持つクラウドサーバのURLが既知のときは、そのURLでプログラムライブラリを持つクラウドサーバにアクセスしてもよい)。
(04)「暗くなったら所定の明るさになるまでLED照明し、かつ、照明後のホワイトバランスが崩れていたらホワイトバランスが取れるようにRGBの駆動割合を制御する」ことに該当する単独の制御プログラムが見つかったなら、その制御プログラムを採用する。
(05)「暗くなったら所定の明るさになるまでLED照明し、かつ、照明後のホワイトバランスが崩れていたらホワイトバランスが取れるようにRGBの駆動割合を制御する」ことに該当する単独の制御プログラムはみつからないが、「所定の明るさになるように照明を制御する」という小規模プログラムと、「ホワイトバランスが取れるように3原色光源の駆動割合を制御する」という小規模プログラムが、1つまたは複数の既存ライブラリ(例えば図38Aのユーザ定義ライブラリ4214)から見つかったとする。
その場合は、見つかった小規模プログラム(サブルーチンまたはクラス)の組合せで新たなプログラムを作成することができる。具体的には、新たなプログラムの新規クラスにおいて、1つまたは複数のライブラリから「所定の明るさになるように照明制御する」クラスと「ホワイトバランスが取れるように3原色光源の駆動割合を制御する」クラスをインポートする。そして、「(暗くなったら)所定の明るさになるまでLED照明し、その明るさ制御は、(所定の色温度に対して)ホワイトバランスが取れるようにRGBの駆動割合を制御する」というメソッドまたは関数を新規クラス内で記述して、新たな制御プログラムを作成する(ウィザード形式によるメソッドまたは関数のユーザ選択を用いることで、新たな制御プログラムの作成を支援することができる)。
上述した新たな制御プログラムの記述内容は、形式的には、例えば以下のようになる(具体的なコーディングの記述は省略):
public class NewControlProgram{
public static void main(String[]args)
{
//周囲の明るさを検出し、明るさが所定値未満なら所定の明るさになるまでRGBの3LEDを均等に駆動(或るクラスの処理内容)
//3LED照明によるホワイトバランスが正常なホワイトバランスポイントからずれているなら、正常なホワイトバランスポイントに収斂するようにR(赤)およびB(青)のLEDを個別に駆動(別のクラスの処理内容)


新たな制御プログラムが作成されたら、それをJVMが実行できるバイトコード(JBC)にコンパイルする。このコンパイルが成功(エラー出ず)し、コンパイルされたJBCが該当ユニットのJVMで所望の動きをしたら、そのJBC(および/またはコンパイル前のソースコード)をそのユニットの制御プログラムの1つとして、そのユニットのプログラムライブラリ(図38Aの例ではアプリケーションプログラムファイル4500内のユーザ定義プログラムフォルダ4520)に、プログラム名および/またはプログラムIDとともに登録する。また、その制御プログラムをそのユニット以外のJVMでも利用可能にするときは、システムコントローラ(フォグサーバ)1126および/またはサーバ(クラウドサーバ)1116にその制御プログラム(JBCおよび/またはソースコード)をアップロードし、アップロード先のプログラムライブラリに、プログラム名および/またはプログラムIDとともに登録する。このアップロードおよび登録は、作成した制御プログラムの動作確認後、自動的に、またはユーザが手動で、行うことができる。
もし、作成したプログラムにバグがあり、所望の動きをしてくれないときは、ユーザ(プログラマ)が手作業でそのプログラムのソースコードを修正する手段を用意しておくことができる。例えば、システムコントローラ(フォグサーバ)1126にJavaの統合開発環境(IDE:Integrated Development Environment)をインストールしておき、そこでソースコードの記述/修正/デバッギングができるようにする。この統合開発環境には、プラグインとして様々な機能を組み込むことができ、プラグイン次第で、Javaのみならず、C++、PHP、JavaScriptなど多様な言語に対応可能となる。この統合開発環境の一例として、Eclipseがある(Java8に対応したEclipse 4.4 (Luna)は、インターネットから入手できる)。
図39は、ファイル管理された特定ユニットをインターネット経由で遠隔操作する一例を説明する図である。ここでは、接続元の通信端末としてWebブラウザを持つスマートフォン5000を想定する。スマートフォン5000のブラウザから接続先のURL(例えば://www.……….U04)を入力して送信すると、スマートフォン5000は、サーバ(またはシステムコントローラ)6000を介して、例えば第4ユニット4611−4に接続される。(この接続にはWeb Socketとして知られるアプリケーションインターフェースを利用できる。Web Socket接続では、サーバとブラウザの間で双方向通信が実現される。)スマートフォン5000とサーバ6000との間の情報通信にはW−フォーマットを使用でき、サーバ6000と第4ユニット4611−4との間の情報通信にはC−フォーマットを使用できる。
サーバ6000はデータベース用の大容量ストレージ6100を持っている。このデータベースには、管理ファイル/データファイル4000で利用されるあらゆるデータを格納しておくことができる。スマートフォン5000のWebブラウザで使用されるHTML5では、SQL言語によってストレージ6100内のデータベースにアクセスできる。
なお、サーバ6000は、図1他のシステムコントローラ(1126、1128)またはサーバn(1116−1〜1116−n)に対応させることができ、構成上の相互利用が可能である。例えば、図2のシステムコントローラ1126の構成を、図39のサーバ6000に適用できる(この場合、図2のメモリー部1232を、図39の管理ファイル/データファイル4000とデータベース用ストレージ6100のために使用できる)。
上記のWeb Socket接続に伴い、サーバ6000の管理ファイル/データファイル4000中のアプリケーションプログラムファイル4500から、第4ユニット4611−4が持つセンサ(イメージセンサIS1、光センサLS1〜LS4)およびアクチエータ(回転テーブル用ステッピングモータTA1)に適合したプログラム(JavaまたはJavaScript)が呼び出される。(呼び出されたプログラムがユーザの要求に合致しないときは、ユーザはアプリケーションプログラムファイル4500から別のアプリケーションを探すことができる。)
ここでは、呼び出されたプログラムが、HTML5内のJavaScriptで記述された、AjaxによるWebアプリケーションであるとする。このWebアプリケーションが起動すると、スマートフォン5000のブラウザのWebページ上に、接続先ユニット4に属する制御対象(回転テーブルに載った観葉植物)のカメラ画像PLIを含むウィンドウ5100と、接続先ユニット4の制御対象を接続元から操作するためのタッチ操作画面を含むウィンドウ5200が表示される。
上記Webアプリケーションにより、ユニット4のイメージセンサIS1が捉えた観葉植物PLの画像PLIがスマートフォン5000のウィンドウ5100に表示される。同時に、観葉植物PLを載せた回転テーブルTT1の回転方向をタッチパネル操作する仮想ダイヤルVDが、スマートフォン5000のウィンドウ5200に表示される。ウィンドウ5200には、光センサLS1〜LS4の検出結果から推定される来光方向のアイコンLD、および/または回転テーブルTT1の回転を来光方向に自動的に向ける指令を出すオートボタンのアイコンBTNを表示してもよい。
仮想ダイヤルVDの操作量に対応した指令(時計回りまたは反時計回りにダイヤルがどれくらい回されたかを示す)はユニット4内部のローカル制御用コンピュータLC1に送られる。コンピュータLC1は、送られてきた指令に基づき回転テーブル用ステッピングモータTA1を指示された方向に指示された量だけ回転させる。
オートボタンのアイコンBTNがタップされると、対応する指令(回転テーブルTT1の所定位置を来光方向に向ける指令)が、ユニット4内部のローカル制御用コンピュータLC1に送られる。コンピュータLC1は、送られてきた指令に基づき、回転テーブルTT1の所定位置が来光方向に収束するようにステッピングモータTA1を駆動する自動制御を開始する。
この制御において、例えば光センサLS2の検出照度が一番大きく、二番目に大きい検出照度がLS1から得られていたなら、回転テーブルTT1の回転軸からみて、センサLS2の方向とセンサLS1の方向との間に来光方向があると推定する。次に、LS2の検出照度とLS1の検出照度の相対的な比率から、来光方向がセンサLS2の方向とセンサLS1の方向との間のどの程度の角度位置にあるか推定する。例えば、LS2の検出照度とLS1の検出照度の相対的な比率(LS2/LS1)が略1であれば、来光方向は回転テーブルTT1の回転軸からみてセンサLS1方向とセンサLS2方向の中間にあると判断し、回転テーブルTT1の所定位置(観葉植物PLに最も光を当てたい方向に対応)をLS1方向とLS2方向の中間に対応する回転位置まで回転させる。また、LS2の検出照度とLS1の検出照度の相対的な比率(LS2/LS1)が1より大きい数値Nxならば、来光方向はセンサLS1とLS2の中間よりもLS2寄りにあると判断し、回転テーブルTT1の所定位置(観葉植物PLに最も光を当てたい方向に対応)をNxに対応する回転位置まで回転させる。このような自動制御が働いているうちは、時間経過に伴い来光方向が変わっても、回転テーブルTT1の所定位置が来光方向に追従して自動的に変わる。
このような自動制御は、例えばJava言語でプログラミングできる。(そのJavaコードをGWTなどにより例えばAjaxのコードに変換して、Webアプリケーションとして使用できる。)そのような自動制御プログラムは、ユニット4のコンピュータLC1が事前に持っていてもよいし、図38のアプリケーションプログラムファイル4500からユニット4のコンピュータLC1にダウンロードしてもよい。あるいは、そのような自動制御プログラムをサーバ6000のコンピュータ(図示せず)で実行し、実行結果(回転テーブルTT1をどの方向にどれだけ回転させるかの指令)をユニット4のコンピュータLC1に送ることにより、ユニット4のステッピングモータTA1を制御するようにしてもよい。
図40は、遠隔操作操作対象(観葉植物PL)の画像を含むWebページ5100aの一例を説明する図である。(図39のウィンドウ5100は図40のWebページ5100aの一部を例示している。)このWebページは、例えば以下のようなHTMLドキュメントで記述できる。
<article id="post-0">
<header>
<hgroup>
<h1>スマホでリモコン</h1>
<h2>観葉植物</h2>
</hgroup>
</header>
<section>
<p>家の観葉植物です。<br />日差しの良い方に向けます。</p>
<figure>
<img class="alignleft size-medium wp-image-20"
title="my plant" src="http://examples.com/blog/images/pl.jpg"
alt="" width="300" height="225" />
<figcaption>
向き調整中<br />
</figcaption>
</figure>
</section>
<footer>
<p>Posted by <address><a href="profile.html">A-man</a></addreess></p>
</footer>
</article>
図41は、操作対象を遠隔操作する場合の操作画面を含むWebページ5200aの一例を説明する図である。(図39のウィンドウ5200は図41のWebページ5200aの一部を例示している。)このWebページは、例えば以下のようなHTMLドキュメントで記述できる。
<article id="post-1">
<header>
<hgroup>
<h1>スマホでリモコン</h1><h2>観葉植物</h2>
</hgroup>
</header>
<section>
<p>観葉植物を載せたテーブルを回転させています。</p>
<figure>
<img class="alignleft size-medium wp-image-20"
title="my plant" src="http://examples.com/blog/images/pc.jpg"
alt="" width="300" height="225" />
<figcaption>
ダイヤル操作中<br />
</figcaption>
</figure>
</section>
<programcode type="bytecode/java">
//ジャバのコードを用いた処理
</programcode>
<script type="text/javascript">
function {
//4つの光センサ出力を取得し出力が最も大きい2つのセンサ位置から来光方向推定
}
function {
//ダイヤル操作の回転方向および回転量に応じた指令を出力
}
function {
//指令に基づき、回転テーブルの特定位置が推定来光方向を向くようにステップモータを回転させる
}
</script>
<footer>
<p>Posted by <address><a href="profile.html">A-man</a></addreess></p>
</footer>
</article>
上記の例では、<programcode>と</programcode>で挟まれたジャバのコードの具体的内容を省略しているが、当業者ならJava言語などで適切なソースコードを記載し、それをJavaの統合開発環境(Eclipsなど)によりJavaバイトコード(JBC)にコンパイルできる。なお、ブラウザが<programcode>と</programcode>で挟まれたJBCを実行できないとき(Java仮想マシンJVMが走っていないときなど)は、<programcode>と</programcode>で挟まれた記述は無視される。(上記のタグ<programcode>および</programcode>は単なる例示であり、別の文字列を含むタグが用いられてもよい。)
また、上記の例では、<script>と</script>で挟まれたJavaScriptの具体的内容を省略しているが、当業者なら、目的の処理内容に応じて、適切なJavaScriptを記述できる。(あるいはJava言語で適切なソースコードを記載し、それをGWTなどによりJavaScriptにクロスコンパイルできる。)
図42は、インターネット経由で操作対象を遠隔操作する手順の一例を説明する図である。図43Aおよび図43Bは、操作情報の送信側にスマートフォンなどの通信端末を用いて、受信側のネットワークに接続された複数操作対象のうちの特定操作対象を遠隔操作する一例を説明する図である。
図43Aのスマートフォン5000のホーム画面において、ホームボタン(アイコン)5000hは起動スイッチと兼任している。ユーザがホームボタン5000hをダブルタップすると、システムが起動し、システム起動直後に指紋センサエリア(図示せず)がスマートフォン5000の画面に表示される。ユーザがこの指紋センサエリアに例えば右手の親指の腹をタッチすると、その指紋が、例えばFIDO(Fast IDentity Online)規格に基づき指紋認証される。(FIDOは一例でありこれに限定されない。また指紋認証機能はスキップすることもできる。)スマートフォン5000には仮想マシン(JVMなど)が実装されており、JVMで実行されるJavaアプリケーションの1つとして、指紋認証プログラムを図38Aのアプリケーションプログラムファイル4500に格納しておくことができる。指紋認証処理により正規ユーザが操作していると判定されたら(あるいは指紋認証がスキップされたら)、図43Aの左側に例示されるように種々なアイコンが画面表示される。
いま、ユーザが、Webブラウザのアイコン5000bをダブルタップしたとする。すると、画面表示は、図43Aの右側に例示されるように、そのスマートフォン5000にインストールされているWebブラウザの画面(プロバイダのホーム画面)に切り替わる。このホーム画面から、例えばAjaxやHTML5を利用するアプリケーションが、ユーザ操作により起動する(図42のST1002)。
図43A右側のホーム画面には、検索キーワード入力枠5302、登録済URL1の縮小画像(例えば、家のペットたちの画像)5304、登録済URL2の縮小画像(例えば、ビデオレコーダのEPG予約の画像)5304、登録済URL3の縮小画像(例えば、療養中の祖母の画像)5306、ソフトウエアキーボードアイコン5410などが表示される。
ユーザの指が例えば登録済URL1の縮小画像(家のペットたち)5304にタッチすると、スマートフォン5000は、図43Bの右側に例示されるような、家のペットたちを管理するユニット(6610〜6630)の1つに、Web上のサーバ(6200または6300)を介して接続される(図42のST1004)。この接続により、スマートフォン5000は、接続先のユニット(例えば6610)から、1以上のセンサ情報(カメラ映像やマイク音声の情報)を獲得する(図42のST1006)。
獲得したセンサ情報(カメラ映像やマイク音声の情報)に基づいて、Webブラウザの画面(図43B左側のサイト画面)上で、接続先ユニットが扱う対象物の画面が表示される(図42のST1008)。例えば、ユーザがWebブラウザの画面(図43B左側)上で愛犬の縮小画像のアイコン5410にタッチすると、接続先の愛犬管理ユニット6610が選択され、接続先の愛犬管理ユニット6610のカメラで撮影した愛犬の食器画像6612がスマートフォン5000の画面5400で表示される。また、食器付近のライブ音声(ユニット6610側のマイクで集音)が、適宜スマートフォン5000の内蔵スピーカから発せられる。
さらに、接続先の愛犬管理ユニット6610から獲得した情報(そのユニットでどのようなアクチエータが動作可能なのかといった情報)に基づいて、そのユニットに対応した操作画面がスマートフォン5000の画面5400で表示される(図42のST1010)。ユーザは、例えばカメラ撮影された愛犬の食器画像から、食器に餌がないことがわかったら、ユニット6610のアクチエータ(例えば愛犬の食器に所定の餌を自動供給する装置)6614に指令を送ることができる。この指令は、例えば「餌をやる」といった音声により行い、それを音声認識することで、行なうことができる(音声認識結果を示す文字列を、スマートフォン5000の画面5400内で表示できる)。あるいは、愛犬の食器画像から食器に餌がないことが検知されたら、餌供給を指令する登録済のスクリプト(命令)を自動選択してもよい。
こうして得られた指令またはスクリプト)は、表示中ユニット6610へ指令を送信するアイコン5540をダブルタップすることで、スマートフォン5000からユニット6610へ送信できる(図42のST1012)。こうして送信された指令に基づいて、接続先のユニット6610のアクチエータ6614が作動し、愛犬の食器に所定の餌が供給される(図42のST1014)。適量の餌が愛犬の食器に供給されたかどうかは、愛犬の食器画像6612をスマートフォン5000の画面5400で確認できる。
現在接続中のユニット6610に対する処理が終了していないとき(例えば、供給した餌が不足気味だとユーザが気づいたとき)は(図42のST1016NO)、処理を繰り返す(ST1006〜ST1014)。現在接続中のユニット6610に対する処理が終了したときは(図42のST1016YES)、そのユニット6610との接続を切る(図42のST1018)。
別のユニット(小鳥管理ユニット6620や金魚管理ユニット6630)に対して「給水」や「給餌/浄水」をしたいときは(図42のST1020NO)、ユニット6610の場合と同様な処理(ST1004〜ST1018)を別のユニットに対して再度行う。ユニットの切り替えは、図43B左側に例示された「インコの縮小画像」アイコン5420または「金魚の縮小画像」アイコン5430をタップすることで、行える。所望のユニットに対する処理が全て終了したときは、ブラウザまたはアプリケーションを終了する(図42のST1020YES)。
管理ユニット6610〜6630各々とサーバ6300との間の近距離通信には、第1フォーマット(C−フォーマット)を用いることができる。(この近距離通信には、USBやBluetoothなどを利用できる。)管理ユニット6610〜6630が間接的に接続されたクラウドサーバ6200とスマートフォン5000との間の遠距離通信には、第2フォーマット(A−、E−、またはW−フォーマット)を用いることができる。(この遠距離通信には、例えば4G−LTEなどを利用できる。)管理ユニット6610〜6630が直接的に接続されたホームネットワークサーバ(フォグサーバ)6300とスマートフォン5000との間の近距離通信には、第2フォーマット(A−、E−、またはW−フォーマット)を用いることができる。(この近距離通信には、Wi−FiやZigBeeなどを利用できる。)第2フォーマットが用いられる場合は、HTML5、Ajax、Web Socket接続などを利用することができる。
なお、管理ユニット6610〜6630各々は、スマートフォン5000側へ画像情報を提供する画像センサ(CCDカメラなど)6612〜6632、スマートフォン5000側から制御されるアクチエータ6614〜6634、メモリ6616〜6636、仮想マシンを構成するマイクロコンピュータ(MPU/CPU)6618〜6638を、適宜具備することができる。
また、ホームネットワークサーバ(フォグサーバまたはシステムコントローラ/フォーマットコンバータ)6300は、図38A/図38Bの情報などを格納する管理情報メモリ6306と、メモリ6306の格納情報その他を利用して種々な処理を行う仮想マシン(JVM)6308を、適宜具備することができる。
図44Aおよび図44Bは、操作情報の送受双方にスマートフォンなどの通信端末を用いて、特定の操作対象を遠隔操作する一例を説明する図である。図43Aの場合と同様に、図44Aのスマートフォン5000のホーム画面において、ホームボタン5000hがダブルタップされると、スマートフォン5000のシステムが起動しする。指紋認証処理などにより正規ユーザがスマートフォン5000を操作していると判定されたら(あるいは認証処理がスキップされていたら)、図44Aの左側に図示するように種々なアプリケーションのアイコンが画面表示される。
いま、ユーザがリモコンアプリのアイコン5000aをダブルタップしたとする。すると、そのスマートフォン5000にインストールされているリモートコントロールアプリケーション(アプレットなどのJavaアプリケーション)が起動する。すると、スマートフォン5000の画面表示は、図44Aの右側に例示されるように、接続先を選択する画面に切り替わる。この選択画面には、新規に電話番号を入力する入力枠、複数の登録済電話番号帳L1、L2、…、送信済電話番号リストT1、受信済電話番号リストR1などが表示される。リモートコントロールしたい対象は、新規電話番号入力枠、あるいは登録済電話番号帳の1つを用いて選択できる。
ここでは、リモートコントロールしたい対象が、登録済電話番号帳L1に登録されている電話番号(または接続先を指定する情報)で特定されるスマートフォン5600に接続された観葉植物4611(図44B右側参照)であるとする。なお、スマートフォン5000および5600のいずれにも、Javaバイトコードを実行する仮想マシン(Java Virtual Machine:JVM、Android(登録商標) RunTime:ARTなど)および必要なメモリが実装されているものとする。
図44Aの右側の画面の登録済電話番号帳L1から、図44B右側のスマートフォン5600が指定されると、スマートフォン5000はサーバ6400を介してスマートフォン5600に無線接続される。この接続では、前述した第2フォーマット(A−、E−、またはW−フォーマット)を用いることができ、HTML5、Ajax、Web Socket接続などを利用することができる。この接続(遠距離通信)には、IP−TVなどの電話回線が利用されてもよい。
ここで、サーバ6400は、ユーザに対してリモートコントロールその他のサービスを行うプロバイダーまたは、通信の基地局であってもよい。このサーバ6400は、図43Bのシステムコントローラ/フォーマットコンバータ6300と同様な機能を内包することができる。
スマートフォン5000がスマートフォン5600に接続されると、スマートフォン5600にインストールされた観葉植物制御アプリケーションが起動する。(この観葉植物制御アプリケーションは、JVMやARTで動作するJavaアプリケーションの1つ。)このアプリケーションが起動すると、接続先のスマートフォン5600から接続元のスマートフォン5000へ、制御対象である観葉植物4611の画像および、この観葉植物の現状に関する情報(回転テーブルの回転位置、来光方向などの情報)が送られる。すると、接続元スマートフォン5000のウィンドウ5100において観葉植物4611の画像が表示され、ウィンドウ5200において観葉植物4611を載せた回転テーブルを操作するためのタッチ操作画面が表示される。ウィンドウ5100および5200で表示される内容は、図39で説明したものと同様である。
なお、スマートフォン5600と観葉植物4611を載せた回転テーブルユニットとの間の近距離接続には、前述した第1フォーマット(C−フォーマット)を用いることができ、USBやBluetoothなどを利用することができる。
一方、接続先スマートフォン5600では、そのウィンドウ5700に接続元スマートフォン5000を操作しているユーザの名称(略称)とそのライブ映像が表示され、および/またはユーザのライブ音声がスマートフォン5600のスピーカから発音される。(スマートフォン5600側でのユーザ映像および/またはユーザ音声の提供は、必要なときだけ行えばよい。)
接続先スマートフォン5600のウィンドウ5800には、制御直前の観葉植物4611の画像と、スマートフォン5000側の操作画面を用いた制御直後の観葉植物4611の画像を表示できる。制御直前および制御直後の画像を適宜出せるようにしておくと、接続元スマートフォン5000のユーザ(例えば外出中の夫)がリモートコントロール操作した結果観葉植物4611の回転位置がどのように変化したのかが、接続先スマートフォン5600を時々にしか見ない接続先スマートフォン5600のユーザ(例えば家にいる妻)にもわかるようになる。つまり、接続先のユーザが気づかないうちに接続元のユーザにより行われたリモートコントロールの結果を、接続先のユーザが後から確認できる。
また、図44Bの観葉植物4611が図43Bの愛犬管理ユニット6610であった場合を想定してみる。外出先の夫がスマートフォン5000によりリモートコントロール操作で愛犬に給餌をした直後に愛犬が餌を全て食べてしまったとすると、その後に買い物から戻った妻が愛犬に再び給餌してしまう恐れがある。このような二重給餌は、図44Bのウィンドウ5800の画像(給餌直前の画像と給餌直後の画像)を見比べた上で現在の愛犬の食器を見れば、回避できる。
種々な実施形態に関連する事項ついて、さらに説明する。
<ネットワーク上での機器の自動接続について>
インターネットを含め、ネットワーク上での機器接続は、既存技術(例えばUniversal Plug & Play:UPnP)を利用して自動化できる。UPnPは、機器を接続しただけでその機器がネットワークに参加することを可能にするプロトコルである。UPnPを用いれば、機器自身がネットワークパラメータを正しく設定でき、ネットワーク上にどのような機器が存在しているのか、また他の機器がどんな機能を持ったものなのかを知ることができる。(UPnPで自動接続され得るネットワーク上の機器の例としては、図2のシステムコントローラαと1以上のユニット、あるいは各ユニットにおけるデバイスコントローラと1以上のセンサ/駆動モジュールがある。)
ここで、UPnPのデバイス・アーキテクチャについて、簡単に述べておく。UPnPでは、各種機能を持ったデバイスと、そのデバイスに対して制御を行うコントロールポイントが定義される。デバイスは、自身の持つ機能をXML形式で公開しており、コントロールポイントは、公開されたデバイス機能を参照して、必要な機能を利用できるようになっている。
UPnPの仕様では、大きく分けて、(1)アドレッシング、(2)ディスカバリー、(3)ディスクリプション、(4)コントロール、(5)イベント通知、(6)プレゼンテーションが定義されている。(1)アドレッシングでは、機器がネットワークに参加した際にアドレスを取得する方法が規定される。(2)ディスカバリーでは、所定のプロトコルを用いてネットワーク上のデバイス検出を行う。具体的には、ネットワークに参加したデバイスはマルチキャストパケット(NOTIFYメソッド)の送出を行い、コントロールポイントはそのパケットを受け取ってデバイスを検出する。またコントロールポイント側からマルチキャストパケット(M_SEARCHメソッド)を用いて問合せを行うと、デバイスはそれに応答する。(3)ディスクリプションは、デバイスが提供できる機能および情報を記述したXMLファイルである。このディスクリプションには、デバイス自身が持つサービスなどについて記述したデバイスディスクリプションと、各サービスが持つアクションなどについて記述したサービスディスクリプションの2種類がある。(4)コントロールでは、サービスの持つ機能を呼び出すアクション(メッセージ)と、デバイスの状態変数を問合せるクエリー(メッセージ)が用いられる。これらのメッセージにはXMLによる記述が利用される。(5)イベント通知とは、「デバイスに対して特定の状態変数を指定してイベント購読要求が行われると、その状態変数が変化する度に出される通知」のことである。(6)プレゼンテーションでは、webブラウザからデバイスの状態の確認あるいはその制御を行うことができる。
<開示された主なフォーマットについて>
実施形態で開示したA−フォーマットは「広義のテキスト形式」をカバーし、C−フォーマットは「コマンド/リクエスト/レスポンス/ステータス形式」をカバーし、E−フォーマットは「所定領域内に設定コードを格納する形式」をカバーし、W−フォーマットは「指定欄に送信側を記入する形式」または「HTML/HTML5固有“タグ”が記載された形式」をカバーしている。これらのフォーマットは、第1のデータフォーマットまたは第2のデータフォーマットに分類される。
<フォーマット変換について>
例えば図1および図2の実施形態において、システムコントローラβ_1128は、システムコントローラα_1126を介して、複数のユニット1290との間の通信(システム内通信)を、第1のデータフォーマット(C−フォーマットなど)を用いて行う。また、システムコントローラβ_1128とクラウド(例えばサーバn_1116−n)との間の通信(システム外通信)には、第2のデータフォーマット(図17BのA−/E−/W−フォーマット)が用いられる。このような異種フォーマットを用いた通信を実現するために、システムコントローラα_1126またはシステムコントローラβ_1128は、第1フォーマットの情報を第2フォーマットの情報へ変換(あるいはその逆の変換)するコンバータを持つことができる。このコンバータを利用して、第1フォーマットのデータと、それに対応する第2フォーマットのデータを、異なる方法で通信できるようになる。(例えば、Bluetoothフォーマットで送られてきたデータに対応する内容のデータをZigBeeフォーマットで転送できる。逆にZigBeeフォーマットで送られてきたデータに対応する内容のデータをBluetoothフォーマットで転送することもできる。)
ここで、C−フォーマット(第1のデータフォーマットの一例)は、例えば図10Aの通信ミドルウエア層APL02で用いられる“通信情報が簡素化”されたフォーマット(図14および2.5節等を参照)である。C−フォーマットでの情報通信プロトコルはシンプルなものであり、例えば図10Bのケース1〜ケース3に見られるような、「コマンド/リクエスト/レスポンス/ステータス形式」で具現できる。
また、A−フォーマット(第2のデータフォーマットの一例)は、例えば図10Aの通信ミドルウエア層APL06で用いられるフォーマット(図15Bおよび2.7節等を参照)であり、同時に複数情報アイテムの通信が可能なフォーマットである。なお、第2のデータフォーマットとして、E−フォーマット(図15Aおよび2.6節等を参照)あるいはW−フォーマット(図10A等を参照)が用いられても良い。第2のデータフォーマットには、図10Aの拡張アプリケーション層EXL06の通信情報も利用できる。
図10Aに示すようなシステム外ネットワーク回線1788を経由した情報通信にWorld Wide Web(適宜Webと略記)が利用される場合では、第2のデータフォーマットとしてW−フォーマットが適している。W−フォーマットが採用される場合、図1のサーバn_1116−nあるいはシステムコントローラα_1126は、Webサーバの機能を併せ持つ。この場合、通信情報の送信側(例えば図10Aのサーバn)は、受信相手(例えばシステムコントローラαへ接続される特定複合モジュール)をURLにより指定し、Webページ内のフォーム形式で指定された書き込み欄(特定複合モジュール用の書き込み欄)内に通信情報を自動的に書き込む。その書き込み情報の通信が完了すると、受信側(例えば図10Aのシステムコントローラα)は所定のプログラム(例えばPHPあるいはJavaのプログラム)に従って受信情報(あるいはその処理結果)を管理情報(例えば図10Aの1744)に保存する。(送信側が例えばシステムコントローラαであれば、受信側はサーバnとなり、受信情報あるいはその処理結果は管理情報1748に保存される。)
同一Webページ内にフォーム形式で指定された書き込み欄を複数設ける(複数の複合モジュールそれぞれに対して書き込み欄を設けるなど)ことで、“複数情報内容の一括通信(送信)”を可能とする設定が、W−フォーマットでもできるようになる。すなわち、この実施形態で開示するW−フォーマットには、「受信側が予め指定した1または複数の書き込み欄に、送信側が所要の情報を記入して、情報通信を行う」あらゆるフォーマットが含まれる。さらに、「HTMLもしくはHTML5に固有な“タグ”が記載された」あらゆるフォーマットもW−フォーマットでカバーされる。
このように、複数内容の情報アイテムを一括して通信可能なフォーマットを採用すると、送信側と受信側の間の通信頻度が減少し、通信停滞のリスクを減らすことができる。この一括通信にAjax(Asynchronous JavaScript + XML)の非同期通信技術を利用することもできる。そうすれば、一括通信される情報による変更がWebページの一部に留まるなら、その通信が行われるたびにWebページ全体を書き替える必要はなく、書き込み情報によって変更が必要になった箇所のみの変更で済む。すると、一括通信による通信頻度の減少に加えて、一度の一括通信における通信情報量も減り、通信停滞のリスクをさらに減らすことができる。
なお、HTML5では、一括通信される複数の情報アイテムの中に、動画を扱うvideo要素、音声を扱うaudio要素、および2D/3Dグラフィックスを扱うCanvas要素に関係した、情報アイテムを含ませることができる。video要素の情報量は大きいので、動画を含む通信では、W−フォーマット(一括通信による通信頻度の減少が可能であり、Ajaxによる非同期通信が利用できる)は、Web通信の世界で利用価値が高い。
第1のデータフォーマットの情報通信(主に近距離通信)には、例えば、有線通信であればUSBを利用でき、無線であればBluetoothあるいはZigBeeを利用できる。また、第2のデータフォーマットの情報通信(主に中〜遠距離通信)には、例えば、中距離無線通信に適したWi−Fi、あるいは遠距離無線通信に対応したWiMAXを利用できる。第2のデータフォーマットの情報通信には、光ケーブル通信あるいは、携帯電話の無線通信技術(4G−LTEなど)が利用されてもよい。
第2のデータフォーマットとしてW−フォーマットが用いられる場合では、HTML5あるいはAjaxを利用できる(この場合、HTML5対応のWebブラウザが使用される)。HTML5を用いた情報通信では情報保護要素(フォーム送信時に秘密鍵と公開鍵を発行するkeygen要素)を利用できる。例えば、C−フォーマット(第1のデータフォーマット)によりクライアントデバイス(複合モジュールなど)側から送られてきた個人情報を情報保護要素で保護し、保護された情報をW−フォーマット(第2のデータフォーマット)によりインターネット経由でサーバ側へ送出することができる。
第1のデータフォーマット(C−フォーマットなど)と第2のデータフォーマット(W−フォーマットなど)は、共通の情報内容を伝送し得るものではあるが、フォーマット自体は異なっている。そのため、実施形態では、第1のデータフォーマット(C−フォーマットなど)を第2のデータフォーマット(W−フォーマットなど)に変換する(あるいはその逆の変換をする)ことが適宜行われる。このフォーマット変換は、MPEG−2の信号をMPEG−4の信号に変換することや、DVD−VRの信号をBD−AVの信号に変換することのように、信号のコンテンツ(ビデオプログラム)は共通でもその属性等(著作権保護方法、伝送パケット構成、平均伝送レートなど)が異なり得るような変換をカバーしている。
<プログラミング言語について>
[1]実施形態におけるプログラミング言語の第1の例として、充実したライブラリ(クラスライブラリ)を持つJava言語がある(2015年時点で最新版はJava8)。Java言語で書かれたソースコードをコンパイルしたJavaバイトコードは、Java仮想マシンJava Virtual Machine(JVM)で実行される。
Javaバイトコードを生成できるプログラミング言語はJava以外にも存在する(例えばScalable language:Scala)。また、Javaバイトコードを実行する仮想マシンとしては、JVM以外にも存在する(例えばAndroid RunTime:ART)。実施形態の説明では、特に断りが無い限り、Javaバイトコードを実行する仮想マシンは全てJVMで代表することにする。
[2]実施形態におけるプログラミング言語の第2の例として、JavaScriptがある。JavaScriptで書かれたプログラムコードの主な実行環境としては、Webブラウザがある。Webブラウザで実行できるプログラムコードは、JavaScript以外にも存在する(Webブラウザに読み込まれてJVMで実行されるJavaバイトコードなど)。JVMがあれば、Javaアプレットなどのアプリケーションも実行できる。
実施形態の説明では、JavaScriptを、様々なECMA Scriptの実装を含んだ幅広い意味で用いている。その意味で、主要なWebブラウザが実装しているスクリプト言語は全てJavaScriptであるといえる。実施形態の説明では、特に断りが無い限り、Webブラウザが実装しているスクリプト言語は全てJavaScriptで代表することにする。
Webブラウザは、JavaScriptとCascading Style Sheets(CSS)が埋め込まれたHTML(HTML5+JavaScript+CSS)で記述された処理、またはAjax(Asynchronous JavaScript+XML)で記述された処理を実行できる。Webブラウザは、<script>と</script>で囲まれた内部をJavaScriptコードと認識して実行する。
[3]実施形態において利用可能なプログラミング言語の他例として、Hypertext Preprocessor(PHP:由来はPersonal Home Page)がある。PHPは、Webサーバ上でPHPスクリプトを実行し、実行結果をWebブラウザへ送信することに使用される。PHPは、「<?PHP」と「?>」で囲まれた内部をPHPコードと認識して実行し、それ以外の部分は全てHTMLコードとしてそのまま出力する。
[4]実施形態において利用可能なプログラミング言語の他例として、Javaサーブレットがある。Javaサーブレットは、Java Server Pages(JSP)を機能の1つとして持つ。JSPは、HTML内に埋め込まれたJavaコードをWebサーバのJVMが実行することによりWebサーバ側で動的にWebページを生成して、生成したページをクライアントに返すことに使用される。
[5]実施形態において利用可能なプログラミング言語のさらに他の例として、C言語(C/C++など)がある。実際のCPU/MPU上で動作する高速なネイティブコードはC言語で記述できる。例えばJava Native Interface(JNI)を利用すれば、C++のネイティブコードをJava言語から利用できるようになる。
[6]あるプログラミング言語のコードは、別のプログラミング言語のコードに変換できる。例えばジャバのコード(ソースコードまたはJavaバイトコード)は、Google Web Toolkit(GWT)などのツールキットを用いて、HTML(HTML5+JavaScript+CSS3)またはAjax(Asynchronous JavaScript+XML)のコードに変換できる。つまり、HTML5+JavaScriptのコードは、そのコード形式で直接記述する以外に、対応するJava言語のソースコード(またはJavaバイトコード)をGWTなどの変換ソフトウエアで変換しても得られる。
<Javaクラスライブラリ(Java Class Library:JCL)について>
Javaクラスライブラリ(JCL)はJavaアプリケーションが実行時に呼び出せる動的ロード可能なライブラリ群である。Javaプラットフォームは特定のOSに依存していないので、アプリケーションはOSの持つライブラリなどに依存できない。その代わり、Javaプラットフォームでは現代のOSが一般に提供している機能を含む標準クラスライブラリ群を包括的に提供している。
JCLはほぼ全体がJavaで書かれているが、ハードウェアやOSに直接アクセスする必要のある部分はその限りではない(例えば、入出力、ビットマップグラフィックス)。そのようなアクセスを行うクラスでは、OSのApplication Programming Interface(API)のための「包み(ラッパー)」としてJava Native Interface(JNI)を使用できる。
JCLのほぼ全体が単一のJavaアーカイブファイル"rt.jar"に格納されており、JCLはJava Runtime Environment(JRE)やJava Development Kit(JDK)の一部として配布されている。Javaクラスライブラリ(rt.jar)はデフォルトのブートストラップクラスパスに置かれ、アプリケーションがいちいちクラスパスを指定する必要はない。ランタイムではJCLを探すのにブートストラップクラスローダが使われる。
JCLの機能には、パッケージでカプセル化されたクラス群を通してアクセスできる。カプセル化されたパッケージには、以下のものが含まれる:
*java.langのパッケージは、言語とランタイムシステムに密接に関連した基本的なクラスおよびインターフェース群を含む。
*ファイルシステムやネットワークにアクセスする機能はjava.io、java.nio、java.netというパッケージを通して提供する。ネットワークでもStream Control Transmission Protocol(SCTP)に関してはcom.sun.nio.sctpが提供する。
*java.mathのパッケージは、任意精度の整数および小数の演算を提供する。
*コレクションとユーティリティのパッケージは、組み込みのコレクションデータ構造とユーティリティクラスを提供するもので、正規表現、並行計算、ロギング、データ圧縮などを扱う。
*GUIと2Dグラフィックスのパッケージでは、Abstract Window Toolkit(AWT)パッケージ(java.awt)が、ネイティブOSに依存したGUIと2DグラフィックスAPIを提供している。Swingパッケージ(javax.swing)はAWTをベースとしてOS非依存のウィジェット・ツールキットとルック・アンド・フィールを提供する。また、編集可能および編集不可能なテキストコンポーネントも用意している。
*サウンドのパッケージは、サウンドデータの読み書き、再生や合成のためのクラスおよびインターフェース群を提供する。
*テキストのパッケージでは、java.textがテキスト、日付、数値、メッセージを扱う。
*イメージパッケージのパッケージでは、java.awt.imageとjavax.imageioがイメージの読み書きや修正のためのAPIを提供する。
*XMLのパッケージでは、Simple API for XML(SAX)、Document Object Model(DOM)、Streaming API for XML(StAX)、XML Stylesheet Language Transformations(XSLT)、XML Path Language(XPath)などのAPIにより、Simple Object Access Protocol(SOAP)やJava API for XML Web Services (JAX−WS)といったWebサービスを可能にする。
*Common Object Request Broker Architecture(CORBA)およびRemote Method Invocation API(RMI−API:組み込みのObject Request Brokerを含む)のパッケージ。
*セキュリティ機能を提供するjava.securityのパッケージと暗号サービスを提供するjavax.cryptoのパッケージ。
*データベースのパッケージでは、java.sqlがStructured English Query Language(SQL)データベースへのアクセスを提供する。
*スクリプトエンジンへのアクセスでは、javax.scriptのパッケージにより、任意の対応するスクリプト言語へのアクセスを提供する。
*アプレットのパッケージでは、java.appletによりアプリケーションをネットワーク経由でダウンロードして保護されたサンドボックス内で動作可能とする。
*JavaBeansのパッケージでは、java.beansにより、再利用可能なコンポーネント群を操作する手段を提供する。
*イントロスペクションとリフレクションのパッケージでは、java.lang.Class がクラスを表すが、MethodやConstructorといった他のクラスはjava.lang.reflect にある。
<Javaプログラムにおける正規表現処理の簡単な例>
正規表現を利用する場合、まず「何にマッチさせるのか」を定義するパターンを作成する。そして、対象文字列が作成したパターンにマッチするかどうかをチェックする。
(プログラム例:RegexSample)
import java.util.regex.Pattern; //"java.util.regex"パッケージから"Pattern"クラスをインポート
import java.util.regex.Matcher; //"java.util.regex"パッケージから"Matcher"クラスをインポート
public class RegexSample{
public static void main(String args[]){
String str = "12A3B5"; //判定する対象文字列
Pattern p = Pattern.compile("^[0-9]*$"); //判定するパターン、すなわち「何にマッチするのか(判定対象文字列が半角の数字のみかどうか)」を定義するパターン
Matcher m = p.matcher(str); // 対象文字列が定義パターンにマッチするか
System.out.println(m.find()); //
}
}
(RegexSampleの実行結果)
判定対象文字列は半角数字以外を含むので"false"となる。もし、判定対象文字列が"12346789"だとすれば、定対象文字列は全て半角数字なので、実行結果は"true"となる。
<実施形態において利用可能なmathクラスの例>
JCLは種々なクラスのライブラリを含むが、mathクラスの一部を例にとってもう少し詳しく説明する。mathクラスは、指数関数、対数関数、平方根、三角関数などの、基本的な数値処理を実行するためのクラスライブラリである。(なお、JavaScriptにも類似の関数ライブラリが用意されている。)
mathクラスはjava.langパッケージに含まれているため、mathクラスを利用するのにimport文は必要ない。またmathクラスのメソッドは全てstaticメソッドとなっているため、mathクラスのオブジェクトを作成しなくてもmathクラスを使う事ができる。(static修飾子が付いているMathクラスのメソッドは、インスタンスを作らなくても使用できる。)
mathクラスは、以下のメソッド(関数)を含む:
[*絶対値を求める関数"abs"]
public static double abs(double a) // doubule型引数aの絶対値を返す。
public static float abs(float a) // float型引数aの絶対値を返す。
public static int abs(int a) // int型引数aの絶対値を返す。
public static long abs(long a) // long型引数aの絶対値を返す。
(プログラム例:mathabs)
class mathabs{
public static void main(String args[]){
for (int i = -1 ; i < 2 ; i++){
System.out.println(i + "の絶対値は" + Math.abs(i) + "です。");
}
}
}
(mathabsの実行結果)
−1の絶対値は1です。
0の絶対値は0です。
1の絶対値は1です。
[*どちらか大きい値を取得する関数"max"(比較する2つの値は同じ型)]
public static double max(double a, double b) // doubule型引数aおよびbうち、いずれか大きい方(正の無限大に近い方)を返す。2つの引数が同じ場合は、その同じ値を返す。
public static float max(float a, float b) // float型引数aおよびbうち、いずれか大きい方(正の無限大に近い方)を返す。2つの引数が同じ場合は、その同じ値を返す。
public static int max(int a, int b) // int型引数aおよびbうち、いずれか大きい方(正の無限大に近い方)を返す。2つの引数が同じ場合は、その同じ値を返す。
public static long max(long a, long b) // long型引数aおよびbうち、いずれか大きい方(正の無限大に近い方)を返す。2つの引数が同じ場合は、その同じ値を返す。
(プログラム例:mathmax)
class mathmax{
public static void main(String args[]){
int a = 7;
int b = 5;
System.out.println("「" + a + "」と「" + b + "」では、");
System.out.println("「" + Math.max(a, b) + "」の方が大きい。");
}
}
(mathmaxの実行結果)
「7」と「5」では、
「7」の方が大きい。
[*どちらか小さい値を取得する関数"min"(比較する2つの値は同じ型)]
public static double min (double a, double b) // doubule型引数aおよびbうち、いずれか小さい方(負の無限大に近い方)を返す。2つの引数が同じ場合は、その同じ値を返す。
public static float min (float a, float b) // float型引数aおよびbうち、いずれか小さい方(負の無限大に近い方)を返す。2つの引数が同じ場合は、その同じ値を返す。
public static int min (int a, int b) // int型引数aおよびbうち、いずれか小さい方(負の無限大に近い方)を返す。2つの引数が同じ場合は、その同じ値を返す。
public static long min (long a, long b) // long型引数aおよびbうち、いずれか小さい方(負の無限大に近い方)を返す。2つの引数が同じ場合は、その同じ値を返す。
(プログラム例:mathmin)
class mathmin{
public static void main(String args[]){
int a = 7;
int b = 5;
System.out.println("「" + a + "」と「" + b + "」では");
System.out.println("「" + Math.min(a, b) + "」の方が小さい。");
}
}
(mathminの実行結果)
「7」と「5」では、
「5」の方が小さい。
[*平方根と立方根を求める関数"sqrt, cbrt"]
public static double sqrt(double a) // doubule型引数aの平方根を返す。
public static double cbrt(double a) // doubule型引数aの立方根を返す。
(プログラム例:mathsqrtcbrt)
class mathsqrtcbrt{
public static void main(String args[]){
double a = 9d;
double b = 216d;
System.out.println("「" + a + "」の平方根は");
System.out.println("「" + Math.sqrt(a) + "」です。");
System.out.println("「" + b + "」の立方根は");
System.out.println("「" + Math.cbrt(b) + "」です。");
}
}
(mathsqrtcbrtの実行結果)
「9.0」の平方根は
「3.0」です。
「216.0」の立方根は
「6.0」です。
[*累乗した値を求める関数"pow"]
public static double pow (double a, double b) // doubule型の1番目の引数(基数)aを、doubule型の2番目の引数(指数)bの値分だけ累乗した値を返す。
(プログラム例:mathpow)
class mathpow{
public static void main(String args[]){
double a = 2d;
double b = 3d;
System.out.println("「" + a + "」の「" + b + "」乗は");
System.out.println("「" + Math.pow(a, b) + "」です。");
}
}
(mathpowの実行結果)
「2.0」の「3.0」乗は
「8.0」です。
[*対数を求める関数"log, log10, log1p"]
public static double log(double a) // 底をeとする、doubule型引数aの自然対数値を返す(a=e^(X)に対してX=ln(a)のX値を返す)。
public static double log10(double b) // 底を10とする、doubule型引数bの対数値を返す(b=10^(X)に対してX=log10(b)のX値を返す)。
public static double log1p(double c) // doubule型引数cと1の合計の自然対数値を返す((1+c)=e^(X)に対してX=ln(1+c)のX値を返す)。
(プログラム例:mathlog)
class mathlog{
public static void main(String args[]){
double a = 39d;
double b = 1000d;
double c = 0.1d;
System.out.println("「" + a + "」の自然対数は");
System.out.println("「" + Math.log(a) + "」です。");
System.out.println("「" + b + "」を根とする対数は");
System.out.println("「" + Math.log10(b) + "」です。");
System.out.println("「" + c + "+1」を真数とする自然対数は");
System.out.println("「" + Math.log1p(c) + "」です。");
}
}
(mathlogの実行結果)
「39.0」の自然対数は
「3.6635616461296463」です。
「1000」を根とする対数は
「3.0」です。
「0.1+1」を真数とする対数は
「0.09531017980432487」です。
[*切り上げ/切り捨て/四捨五入を求める関数"ceil, floor, round"("round"メソッドでは引数の型と戻り値の型が異なる)]
public static double ceil(double a) // doubule型引数aの値以上で、計算上の整数と等しい、最小の(負の無限大にもっとも近い) double値を返す(切上げ)。
public static double floor(double a) // doubule型引数aの値以下で、計算上の整数と等しい、最大の(正の無限大にもっとも近い) double値を返す(切捨て)。
public static long round(double a) // doubule型引数aの値にもっとも近いlong値を返す(四捨五入)。
public static long round(float a) // doubule型引数aの値にもっとも近いint値を返す(四捨五入)。
(プログラム例:mathceilfloorround)
class mathround{
public static void main(String args[]){
double a = 1.23d;
double b = 3.78d;
double c = -0.34d;
double d = -3.78d;
System.out.println("「" + a + "」に対して");
System.out.println("切り上げは「" + Math.ceil(a) + "」");
System.out.println("切り捨ては「" + Math.floor(a) + "」");
System.out.println("四捨五入は「" + Math.round(a) + "」です。");
System.out.println("「" + b + "」に対して");
System.out.println("切り上げは「" + Math.ceil(b) + "」");
System.out.println("切り捨ては「" + Math.floor(b) + "」");
System.out.println("四捨五入は「" + Math.round(b) + "」です。");
System.out.println("「" + c + "」に対して");
System.out.println("切り上げは「" + Math.ceil(c) + "」");
System.out.println("切り捨ては「" + Math.floor(c) + "」");
System.out.println("四捨五入は「" + Math.round(c) + "」です。");
System.out.println("「" + d + "」に対して");
System.out.println("切り上げは「" + Math.ceil(d) + "」");
System.out.println("切り捨ては「" + Math.floor(d) + "」");
System.out.println("四捨五入は「" + Math.round(d) + "」です。");
}
}
(mathceilfloorroundの実行結果)
「1.23」に対して
切り上げは「2.0」
切り捨ては「1.0」
四捨五入は「1」です。
「3.78」に対して
切り上げは「4.0」
切り捨ては「3.0」
四捨五入は「4」です。
「-0.34」に対して
切り上げは「-0.0」
切り捨ては「-1.0」
四捨五入は「0」です。
「-3.78」に対して
切り上げは「-3.0」
切り捨ては「-4.0」
四捨五入は「-4」です。
<Javaクラスライブラリの一部におけるmathクラスの代表的な関数の纏め>
関数例01:static double abs(double a) … double値の絶対値を返す。
関数例02:static float abs(float a) … float値の絶対値を返す。
関数例03:static int abs(int a) … int値の絶対値を返す。
関数例04:static long abs(long a) … long値の絶対値を返す。
関数例05:static double max(double a, double b) … 2つのdouble値のうち大きい方を返す。
関数例06:static float max(float a, float b) … 2つのfloat値のうち大きい方を返す。
関数例07:static int max(int a, int b) … 2つのint値のうち大きい方を返す。
関数例08:static long max(long a, long b) … 2つのlong値のうち大きい方を返す。
関数例09:static double min(double a, double b) … 2つのdouble値のうち小さい方を返す。
関数例10:static float min(float a, float b) … 2つのfloat値のうち小さい方を返す。
関数例11:static int min(int a, int b) … 2つのint値のうち小さい方を返す。
関数例12:static long min(long a, long b) … 2つのlong値のうち小さい方を返す。
関数例13:static double sqrt(double a) … double値の平方根を返す。
関数例14:static double cbrt(double a) … double値の立方根を返す。
関数例15:static double pow(double a, double b) … 1番目の引数aを、2番目の引数bで累乗した値を返す。
関数例16:static double log(double a) … double値aの自然対数値(底はe)を返す。
関数例17:static double log10(double b) … double値bの対数値(底は10)を返す。
関数例18:static double log1p(double c) … (double値c + 1)の自然対数値(底はe)を返す。
関数例19:static double exp(double a) … オイラー数 e をdouble値で累乗した値を返す。
関数例20:static double ceil(double a) … 引数の値以上で、計算上の整数と等しい、最小の(負の無限大にもっとも近い)double値を返す(切り上げ)。
関数例21:static double floor(double a) … 引数の値以下で、計算上の整数と等しい、最大の(無限大にもっとも近い)double値を返す(切り捨て)。
関数例22:static double rint(double a) … 引数の値にもっとも近く、計算上の整数に等しいdouble値を返す(四捨五入)。
関数例23:static long round(double a) … 引数にもっとも近いlongを返す(四捨五入)。
関数例24:static int round(float a) … 引数にもっとも近いintを返す(四捨五入)。
関数例25:static double IEEEremainder(double f1, double f2) … IEEE 754標準に従って、2個の引数について剰余を計算する。
関数例26:static double random() … 0.0以上で1.0より小さい正の符号の付いたdouble値を返す。
関数例27:static double toDegrees(double angrad) … ラジアンで計測した角度を、相当する度に変換する。
関数例28:static double toRadians(double angdeg) … 度で計測した角度を、相当するラジアンに変換する。
関数例29:static double sin(double a) … 指定された角度のサインを返す。
関数例30:static double cos(double a) … 指定された角度のコサインを返す。
関数例31:static double tan(double a) … 指定された角度のタンジェントを返す。
関数例32:static double asin(double a) … 指定された角度のアークサインを、−π/2〜π/2の範囲で返す。
関数例33:static double acos(double a) … 指定された角度のアークコサインを、0.0〜πの範囲で返す。
関数例34:static double atan(double a) … 指定された角度のアークタンジェントを、−π/2〜π/2の範囲で返す。
関数例35:static double atan2(double y, double x) … 直交座標(x, y)を極座標(r, theta)に変換する。
ここでは具体例を記載しないが、Java以外のプログラミング言語(C/C++やJavaScriptなど)にもJavaと同様なライブラリが用意されており、また、Javaのライブラリを利用できるJava以外の言語もある。
Javaの関数ライブラリはユーザが作成することもできる。ユーザが自作した関数をユーザ定義関数とする。ユーザ定義関数を作成できるプログラミング言語はJavaに限られない。CやPHPなどの言語でもユーザ定義関数を作成可能であるが、ここではJavaのユーザ定義関数を例にとって説明する。
Javaクラスライブラリに含まれる種々なメソッド(関数)は、適宜組み合わせることができる。例えばMathクラスでみると、「累乗」を扱う"static double pow"と「対数」を扱う"static double log10"を組み合わせることができる。具体的には、"static double pow(double a, double b)"で「aのb乗(a^b)」の値yを獲得し、"static double log10(double y)"でyの対数値xを獲得できる。結果的にはx =log10(y) =log10(a^b) =b*log10(a)となり、log10(a)のb倍を示すxが得られる(このような組合せ関数は、図38Aのユーザ定義ライブラリ4214に登録できる)。
この組合せ関数(x = b*log10(a))において、log10(a)に係数b=20を掛けて20*log10(a)とした場合、a=10、b=20なら20*log10(a)=20となる。仮にデシベル(dB)を単位として用いるなら、a=10は20dBに換算される。一方、係数b=10を掛けて10*log10(a)とした場合、a=10、b=10なら10*log10(a)=10となり、a=10は10dBに換算される。つまり、b=20ではaが10倍大きくなると20dBのダイナミックレンジがあり、b=10ではaが10倍大きくなってもダイナミックレンジは10dBに縮小される。(ここで、ダイナミックレンジとは、所定範囲内での最小値と最大値との比に対応し、デシベルdBで表せば最小値から最大値までの変化幅を示す。パラメータaの対数変化が「傾きbの直線関数」であれば、傾きbが大きいほど、所定範囲内でのデシベル変化幅が大きくなる。)
例えばaがセンサAで検出した等比級数変化のパラメータであり、bがセンサBの検出結果に対応して変化できる制御パラメータであるとする。すると、等比変化パラメータaの対数(直線的な変化)の傾きをパラメータbの大きさで制御したものがxになる。具体例をあげると、マイクAで拾ったロックコンサート会場のPublic Address(PA)音量のダイナミックレンジを、マイクBで拾った会場ノイズレベル(聴衆の興奮度で変る)に応じて制御できる。
より具体的には、会場ノイズが大きいときはPA音のダイナミックレンジを小さくして(マイクBの検出結果の逆数を制御パラメータとすることで会場ノイズが大きいほどbの値を小さくして)弱音部分の音圧レベルを相対的に上げる。例えば、元は最大音圧レベルが100dBSPL(Sound Pressure Level)で最小音圧レベルが80dBSPLであったものを、最大音圧レベルは100dBSPLのままで最小音圧レベルを90dBSPLに上げる。これにより、弱音部分の音圧が小さくなりすぎず、会場ノイズが大きくても聴衆は弱音を聴きやすくなる。逆に、会場ノイズが小さいときはPA音のダイナミックレンジを大きくして(bの値を大きくして)弱音部分の音圧レベルを相対的に下げる。例えば最大音圧レベルは100dBSPLのままで最小音圧レベルを70dBSPLに下げる。これにより、ピアニシモ部分が静かに会場に響くようにPA制御できる。
あるいは、パラメータaが音圧レベルを示すものであれば、パラメータbは既知の特性曲線(例えばFletcher and MunsonあるいはRobinson and Dadsonの等ラウドネス曲線)を示すものでもよい。
上記の例ではパラメータa、bとも同種のセンサ(マイク)であったが、これらは異種のセンサでもよい。例えばパラメータaを光センサAの検出結果から生成し、パラメータbを温度センサBの検出結果から生成してもよい。この場合、周囲が明るいときは温度変化のダイナミックレンジを大きくし、周囲が暗くなるにつれて温度変化のダイナミックレンジが小さくなる(例えばエアコンを用いた自動温度制御における制御目標の上限と下限の範囲を狭くする)ような制御が可能となる。
このように、複数の同種または異種センサの出力如何で結果が変化する新規メソッド(既存ライブラリにない新関数)を作成できる。換言すると、あるセンサの検出特性を別のセンサの特性でモディファイするような新関数を用意して、異種センサの組合せにより”個々のセンサでは得られない新たな機能を持った”新種のセンサを創生できる。こうして作成された新規メソッド(新たなユーザ定義関数)は、ユーザ関数ライブラリに登録できる。
上述したように、Java言語の豊富なライブラリを利用して、種々なプログラミングができる。プログラムを構成する個々の手順はJavaのクラスファイルに対応させることができる。各クラスファイルは、個々の手順に対応するJavaのバイトコードを含むファイルである。
Javaのバイトコードは、任意のコンピュータ上に実装されたJava仮想マシン(Java Virtual Machine:JVM)あるいはJVMに対応する他の仮想マシン(Android RunTime:ARTなど)で実行できる。Javaバイトコードは、Java以外のプログラミング言語(Scalable language:Scalaなど)でも生成できる。
また、Javaバイトコードは、適切なコンパイラ(Google Web Toolkit:GWTなどに含まれるコンパイラ)を用いて、Webブラウザでの実行に適したコード(HTML5+JavaScriptのコードなど)に変換できる。Javaバイトコードは、GWTなどを用いて、Ajax(Asynchronous JavaScript + XML)を用いた(HTML5対応の)Webアプリに変換できる。
GWTは、Javaを使ってWeb用のAjaxアプリを開発できるオープンソースのJavaソフトウエア開発フレームワークである。Ajaxは、Webブラウザ内で非同期通信とインターフェースを構築する際に用いることができる。Ajaxを用いれば、画面遷移を伴わない動的ウェブページ(非同期通信の結果に応じて、ページの一部をダイナミックHTMLで動的に書き替えること)を実現できる。
GWTは、
GWT Java-to-JavaScript Compiler(Javaで書かれたプログラム(アプリ)をJavaScript(アプリ)に変換するコンパイラ);
GWT Hosted Web Browser(Webアプリ開発時に、JavaScriptへ変換することなくJavaバイトコードのままJVM上で動作させる特殊なブラウザ);
JREエミュレーションライブラリ(Javaの標準クラスライブラリでよく使われるクラス(java.langパッケージおよびjava.utilパッケージの一部のクラス)をJavaScriptで実装したライブラリで、ジャバのコードをJavaScriptのコードにコンパイルする際に使用される);
GWT Web UIクラスライブラリ(ウィジェット生成用のカスタムインターフェースとクラス群)
といった、複数のコンポーネントを持っている。(Widgetとは、グラフィカルユーザインターフェースのパーツの総称であり、画面表示上のウィンドウ、ボタン、テキストボックス、チェックボックスなどを含む。)
<実施形態において利用可能なJava8の型の例(以下の例は、適宜組み合わせてプログラム作成に利用できる)>
[java.io]
* UncheckedIOException…IOExceptionを非チェック例外でラップする。
[java.lang]
* FunctionalInterface…「インタフェース型の宣言を、Java言語仕様に定義されている関数型インタフェースとする」ことを示す。
[java.lang.annotation]
* Native…定数値を定義するフィールドがネイティブコードから参照される可能性があることを示す。
* Repeatable…注釈型java.lang.annotation.Repeatableは、宣言に(メタ)注釈を付ける注釈型が繰返し可能であることを示すために使用される。
[java.lang.invoke]
* MethodHandleInfo…メソッド取扱情報。
[java.lang.reflect]
* Executable…MethodおよびConstructorに共通する機能のための共有スーパークラス。
* Parameter…メソッドパラメータに関する情報。
* MalformedParametersException…java.lang.reflectパッケージがクラスファイルからメソッドパラメータの読取りを試みて、1つ以上のパラメータの型式が不正であると判断した場合に用いられる。
[java.net]
* URLPermission…ある特定のURLで定義され、ある特定のユーザ設定可能なリクエストメソッドおよびリクエストヘッダのセットで使われるリソースまたはリソースセットへのアクセス権を表す。
[java.security]
* KeyStore.Entry.Attribute…キーストアエントリに関連付けられた属性。
* DomainLoadStoreParameter…キーストアドメイン内のキーストアを指定する構成データ。
* PKCS12Attribute…PKCS12キーストアエントリに関連付けられた属性。
[java.security.cert]
* CertPathChecker…CertPathの各Certificateに対して1つ以上のチェックを実行する。
* PKIXRevocationChecker…証明書の失効ステータスをPKIXアルゴリズムで確認するためのPKIXCertPathChecker。
[java.sql]
* DriverAction…DriverがDriverManagerからの通知を希望する場合に実装する必要があるインタフェース。
* SQLType…JDBC型またはベンダー固有データ型と呼ばれる汎用SQL型を識別するために使用されるオブジェクト。
* JDBCType…JDBC型と呼ばれる、汎用SQL型を識別するために使用する定数を定義する。
[java.time]
* Clock…タイムゾーンを使用して現在の時点、日付および時間へのアクセスを提供するクロック。
* Duration…時間ベースの時間(「23.4秒」など)。
* Instant…時系列の時点。
* LocalDate…ISO-8601暦体系のタイムゾーンのない日付(2015-09-30など)。
* LocalDateTime…ISO-8601暦体系のタイムゾーンのない日付/時間(2015-09-30T11:16:40など)。
* LocalTime…ISO-8601暦体系における、タイムゾーンのない時間(11:16:40など)。
* MonthDay…ISO-8601暦体系における月日(--09-30など)。
* OffsetDateTime…ISO-8601暦体系におけるUTC/グリニッジからのオフセット付きの日時(2015-09-30T11:16:40+01:00など)。
* OffsetTime…ISO-8601暦体系におけるUTC/グリニッジからのオフセット付きの時間(11:16:40+01:00など)。
* Period…ISO-8601暦体系における日付ベースの時間の量(「1年2か月と3日」など)。
* Year…ISO-8601暦体系における年(2015など)。
* YearMonth…ISO-8601暦体系における年月(2015-09など)。
* ZonedDateTime…ISO-8601の暦体系によるタイムゾーン付きの日付/時間(2015-09-30T11:16:40+01:00 Europe/Parisなど)。
* ZoneId…タイムゾーンID(ヨーロッパ/パリなど)。
* ZoneOffset…グリニッジ/UTCからのタイムゾーンオフセット(+01:00など)。
* DayOfWeek…「曜日」(「Tuesday」など)。
* Month…「月」(「July」など)。
* DateTimeException…日付/時間の計算時の問題を示すために投入される例外。
[java.time.chrono]
* ChronoLocalDate…任意の暦で時またはタイムゾーンのない日付。
* ChronoLocalDateTime…任意の暦のタイムゾーンのない日付/時間。
* Chronology…日付の編成と識別に使用される暦体系。
* ChronoPeriod…任意の暦での「3年、4か月、5日」などの、日付ベースの時間の量。
* ChronoZonedDateTime…任意の暦のタイムゾーン付きの日付/時間。
* Era…時系列の紀元。
* AbstractChronology…日付の編成と識別に使用される暦体系の抽象実装。
* IsoChronology…ISO暦体系。
* JapaneseChronology…和暦体系。
* JapaneseDate…和暦体系の日付。
* JapaneseEra…和暦体系の紀元。
* IsoEra…ISO暦体系の紀元。
[java.time.format]
* DateTimeFormatter…日付/時間オブジェクトの出力および解析のためのフォーマッタ。
* DateTimeFormatterBuilder…日付/時間フォーマッタを作成するためのビルダー。
* DecimalStyle…日付と時間の書式設定で使用されるローカライズされた10進スタイル。
* FormatStyle…ローカライズされた日付、時間または日付/時間フォーマッタのスタイルの列挙。
* ResolverStyle…日付と時間の様々な解決方法の列挙。
* SignStyle…正および負の記号を処理する方法の列挙。
* DateTimeParseException…解析中にエラーが発生した場合に投入される例外。
[java.time.temporal]
* Temporal…時間的オブジェクト(日付、時間、オフセット、またはそれらのなんらかの組合せなど)への読取り/書込みアクセスを定義するフレームワークレベルのインタフェース。
* TemporalAccessor…時間的オブジェクト(日付、時間、オフセット、またはそれらのなんらかの組合せなど)への読取り専用アクセスを定義するフレームワークレベルのインタフェース。
* TemporalAdjuster…時間的オブジェクトを調整する。
* TemporalAmount…「7時間」、「9日間」、「3年4か月」などの時間量を定義するフレームワークレベルのインタフェース。
* TemporalField…月、時刻などの日付/時間のフィールド。
* TemporalQuery…時間的オブジェクトを照会する。
* TemporalUnit…日間、時間などの日付/時間の単位。
* IsoFields…四半期、暦週の基準年など、ISO-8601暦体系に固有のフィールドと単位。
* ValueRange…日付/時間フィールドの有効な値の範囲。
* WeekFields…曜日、「月の週番号」、および「年の週番号」フィールドのローカライズされた定義。
* ChronoField…フィールドの標準セット。
* ChronoUnit…日付期間の単位の標準セット。
* UnsupportedTemporalTypeException…ChronoFieldまたはChronoUnitがTemporalクラスでサポートされていないことを示す。
[java.time.zone]
* ZoneOffsetTransition…ローカル時系列内の不連続によって生じる2つのオフセット間の遷移。
* ZoneOffsetTransitionRule…遷移の作成方法を表すルール。
* ZoneRules…単一タイムゾーンのゾーンオフセットがどのように変化するかを定義するルール。
* ZoneRulesProvider…システムへのタイムゾーンルールのプロバイダ。
* ZoneRulesException…タイムゾーン構成の問題を示すために投入される。
[java.util]
* PrimitiveIterator…Iteratorのプリミティブ特化に使用するベースタイプ。
* PrimitiveIterator.OfDouble…double値に特化されたイテレータ。
* PrimitiveIterator.OfInt…int値に特化されたイテレータ。
* PrimitiveIterator.OfLong…long値に特化されたイテレータ。
* Spliterator…ソースの要素をトラバースおよびパーティション化するためのオブジェクト。
* Spliterator.OfDouble…double値に特化されたスプリッテレータ。
* Spliterator.OfInt…int値に特化されたスプリッテレータ。
* Spliterator.OfLong…long値に特化されたスプリッテレータ。
* Spliterator.OfPrimitive…プリミティブ値に特化されたスプリッテレータ。
* Base64…Base64エンコーディングスキーム用のエンコーダおよびデコーダを取得するためのstaticメソッドのみで構成されたクラス。
* Base64.Decoder…RFC4648およびRFC2045に指定されているBase64エンコーディングスキームを使用してバイトデータをデコードするためのデコーダを実装するクラス。
* Base64.Encoder…RFC4648およびRFC2045に指定されているBase64エンコーディングスキームを使用してバイトデータをエンコードするためのエンコーダを実装するクラス。
* Calendar.Builder…各種の日付/時間パラメータからCalendarを作成するために使用される。
* DoubleSummaryStatistics…カウント数、最小、最大、合計、平均などの統計情報(double値)を収集するための状態オブジェクト。
* IntSummaryStatistics…カウント数、最小、最大、合計、平均などの統計情報(int値)を収集するための状態オブジェクト。
* Locale.LanguageRange…RFC4647の言語タグの照合に定義されている言語範囲を表すクラス。
* LongSummaryStatistics…カウント数、最小、最大、合計、平均などの統計情報(long値)を収集するための状態オブジェクト。
* Optional…null以外の値が含まれている場合も含まれていない場合もあるコンテナオブジェクト。
* OptionalDouble…double値が含まれている場合も含まれていない場合もあるコンテナオブジェクト。
* OptionalInt…int値が含まれている場合も含まれていない場合もあるコンテナオブジェクト。
* OptionalLong…long値が含まれている場合も含まれていない場合もあるコンテナオブジェクト。
* Spliterators…Spliteratorとそのプリミティブ特化であるSpliterator.OfInt、Spliterator.OfLongおよびSpliterator.OfDoubleのインスタンスを操作または作成するためのstaticクラスおよびメソッド。
* Spliterators.AbstractDoubleSpliterator…制限付きの並列処理を許可するためにtrySplitを実装する抽象Spliterator.OfDouble。
* Spliterators.AbstractIntSpliterator…制限付きの並列処理を許可するためにtrySplitを実装する抽象Spliterator.OfInt。
* Spliterators.AbstractLongSpliterator…制限付きの並列処理を許可するためにtrySplitを実装する抽象Spliterator.OfLong。
* Spliterators.AbstractSpliterator…制限付きの並列処理を許可するためにtrySplitを実装する抽象Spliterator。
* SplittableRandom…サブタスクを生成する可能性がある独立した並列計算に使用可能な、一様乱数値のジェネレータ。
* StringJoiner…デリミタで区切られ、指定された接頭辞から始まり指定された接尾辞で終わる文字のシーケンスを構築するために使用される。
* Locale.FilteringMode…場所マッチング用のフィルタリングモードを選択するための定数を提供する。
[java.util.concurrent]
* CompletableFuture.AsynchronousCompletionTask…asyncメソッドによって生成された非同期タスクを識別するマーカーインタフェース。
* CompletionStage…CompletionStageが完了したときにアクションの実行または値の計算を行う、非同期の可能性がある計算ステージ。
* CompletableFuture…(その値とステータスを設定して)明示的に完了できるFutureであり、その完了時に発生する依存関数およびアクションをサポートし、CompletionStageとして使用できる。
* ConcurrentHashMap.KeySetView…キーのセットとしてのConcurrentHashMapのビューであり、共通の値にマップすることによって、その追加が有効化される。
* CountedCompleter…トリガーされた時点で保留中のアクションが残っていない場合に実行される完了アクションを含むForkJoinTask。
* CompletionException…結果またはタスクを完了する過程でエラーまたはその他の例外が検出されたときに投入される。
[java.util.concurrent.atomic]
* DoubleAccumulator…指定された関数を使用して更新される、処理中のdouble値を一緒に保持する1つ以上の変数。
* DoubleAdder…初期値ゼロのdoubleの合計を一緒に保持する1つ以上の変数。
* LongAccumulator…指定された関数を使用して更新される、処理中のlong値を一緒に保持する1つ以上の変数。
* LongAdder…初期値ゼロのlongの合計を一緒に保持する1つ以上の変数。
[java.util.concurrent.locks]
* StampedLock…読取り/書込みアクセスを制御する3つのモードを持つ機能ベースのロック。
[java.util.function]
* BiConsumer…2つの入力引数を受け取って結果を返さないオペレーションを表す。
* BiFunction…2つの引数を受け取って結果を生成する関数を表す。
* BinaryOperator…同じ型の2つのオペランドに作用してオペランドと同じ型の結果を生成する演算を表す。
* BiPredicate…2つの引数の述語(boolean値関数)を表す。
* BooleanSupplier…boolean値の結果のサプライヤを表す。
* Consumer…単一の入力引数を受け取って結果を返さないオペレーションを表す。
* DoubleBinaryOperator…2つのdouble値オペランドに作用してdouble値の結果を生成する演算を表す。
* DoubleConsumer…単一のdouble値引数を受け取って結果を返さないオペレーションを表す。
* DoubleFunction…1つのdouble値引数を受け取って結果を生成する関数を表す。
* DoublePredicate…1つのdouble値引数の述語(boolean値関数)を表す。
* DoubleSupplier…double値の結果のサプライヤを表す。
* DoubleToIntFunction…1つのdouble値引数を受け取ってint値の結果を生成する関数を表す。
* DoubleToLongFunction…1つのdouble値引数を受け取ってlong値の結果を生成する関数を表す。
* DoubleUnaryOperator…単一のdouble値オペランドに作用してdouble値の結果を生成する演算を表す。
* Function…1つの引数を受け取って結果を生成する関数を表す。
* IntBinaryOperator…2つのint値オペランドに作用してint値の結果を生成する演算を表す。
* IntConsumer…単一のint値引数を受け取って結果を返さないオペレーションを表す。
* IntFunction…1つのint値引数を受け取って結果を生成する関数を表す。
* IntPredicate…1つのint値引数の述語(boolean値関数)を表す。
* IntSupplier…int値の結果のサプライヤを表す。
* IntToDoubleFunction…1つのint値引数を受け取ってdouble値の結果を生成する関数を表す。
* IntToLongFunction…1つのint値引数を受け取ってlong値の結果を生成する関数を表す。
* IntUnaryOperator…単一のint値オペランドに作用してint値の結果を生成する演算を表す。
* LongBinaryOperator…2つのlong値オペランドに作用してlong値の結果を生成する演算を表す。
* LongConsumer…単一のlong値引数を受け取って結果を返さないオペレーションを表す。
* LongFunction…1つのlong値引数を受け取って結果を生成する関数を表す。
* LongPredicate…1つのlong値引数の述語(boolean値関数)を表す。
* LongSupplier…long値の結果のサプライヤを表す。
* LongToDoubleFunction…1つのlong値引数を受け取ってdouble値の結果を生成する関数を表す。
* LongToIntFunction…1つのlong値引数を受け取ってint値の結果を生成する関数を表す。
* LongUnaryOperator…単一のlong値オペランドに作用してlong値の結果を生成する演算を表す。
* ObjDoubleConsumer…オブジェクト値とdouble値の引数を受け取って結果を返さないオペレーションを表す。
* ObjIntConsumer…オブジェクト値とint値の引数を受け取って結果を返さないオペレーションを表す。
* ObjLongConsumer…オブジェクト値とlong値の引数を受け取って結果を返さないオペレーションを表す。
* Predicate…1つの引数の述語(boolean値関数)を表す。
* Supplier…結果のサプライヤを表す。
* ToDoubleBiFunction…2つの引数を受け取ってdouble値の結果を生成する関数を表す。
* ToDoubleFunction…double値の結果を生成する関数を表す。
* ToIntBiFunction…2つの引数を受け取ってint値の結果を生成する関数を表す。
* ToIntFunction…int値の結果を生成する関数を表す。
* ToLongBiFunction…2つの引数を受け取ってlong値の結果を生成する関数を表す。
* ToLongFunction…long値の結果を生成する関数を表す。
* UnaryOperator…単一のオペランドに作用してオペランドと同じ型の結果を生成する演算を表す。
[java.util.spi]
* ResourceBundleControlProvider…ResourceBundle.Controlの実装を提供するサービスプロバイダのインタフェース。
* CalendarDataProvider…場所(ロケール)に依存するCalendarパラメータを提供するサービスプロバイダの抽象クラス。
* CalendarNameProvider…Calendarフィールド値のローカライズされた文字列表現(表示名)を提供するサービスプロバイダの抽象クラス。
[java.util.stream]
* BaseStream…順次および並列の集約操作をサポートする要素シーケンスであるストリームの基底インタフェース。
* Collector…可変結果コンテナに入力要素を蓄積し、オプションですべての入力要素が処理された後で蓄積された結果を最終的な表現に変換する、可変リダクション操作。
* DoubleStream…順次および並列の集約操作をサポートするプリミティブdouble値要素のシーケンス。
* DoubleStream.Builder…DoubleStreamの可変ビルダー。
* IntStream…順次および並列の集約操作をサポートするプリミティブint値要素のシーケンス。
* IntStream.Builder…IntStreamの可変ビルダー。
* LongStream…順次および並列の集約操作をサポートするプリミティブlong値要素のシーケンス。
* LongStream.Builder…LongStreamの可変ビルダー。
* Stream…順次および並列の集約操作をサポートする要素のシーケンス。
* Stream.Builder…Streamの可変ビルダー。
* Collectors…要素をコレクションに蓄積したり、さまざまな条件に従って要素を要約するなど、有用な各種リダクション操作を実装したもの。
* StreamSupport…ストリームを作成および操作するための低レベルのユーティリティメソッド。
[javax.lang.model]
* AnnotatedConstruct…注釈付け可能な構文を表す。
[javax.lang.model.type]
* IntersectionType…共通部分型を表す。
[javax.lang.model.util]
* AbstractAnnotationValueVisitor8…RELEASE_8ソースバージョンに適したデフォルトの動作を持つ、注釈値のスケルトンビジター。
* AbstractElementVisitor8…RELEASE_8ソースバージョンに適したデフォルトの動作を持つ、プログラム要素のスケルトンビジター。
* AbstractTypeVisitor8…RELEASE_8ソースバージョンに適したデフォルトの動作を持つ、型のスケルトンビジター。
* ElementKindVisitor8
RELEASE_8ソースバージョンに適したデフォルトの動作を持つ、種類に基づくプログラム要素のビジター。
* ElementScanner8…RELEASE_8ソースバージョンに適したデフォルトの動作を持つ、プログラム要素のスキャンビジター。
* SimpleAnnotationValueVisitor8…RELEASE_8ソースバージョンに適したデフォルトの動作を持つ、注釈値の単純なビジター。
* SimpleElementVisitor8…RELEASE_8ソースバージョンに適したデフォルトの動作を持つ、プログラム要素の単純なビジター。
* SimpleTypeVisitor8…RELEASE_7ソースバージョンに適したデフォルトの動作を持つ、単純な型のビジター。
* TypeKindVisitor8…RELEASE_8ソースバージョンに適したデフォルトの動作を持つ、種類に基づく型のビジター。
[javax.net.ssl]
* SNIHostName…このクラスのインスタンスは、Server Name Indication (SNI)拡張のhost_nameタイプのサーバー名を表す。
* SNIMatcher…このクラスのインスタンスは、SNIServerNameインスタンスに対してマッチング操作を実行するマッチャを表す。
* SNIServerName…このクラスのインスタンスは、Server Name Indication (SNI)拡張のサーバー名を表す。
* StandardConstants…標準定数の定義
[javax.xml.validation]
* SchemaFactoryConfigurationError…スキーマファクトリの構成で問題が存在する場合に投入される。
<実施形態において利用可能なJava8のメソッドの例(以下の例は、適宜組み合わせて、ユーザ定義クラスまたはユーザ定義プログラムの作成に利用できる)>
{java.awt}
[KeyboardFocusManager]
* clearFocusOwner:public void clearFocusOwner()…フォーカスの所有者が存在し、呼出し側スレッドと同じコンテキストにある場合は、Javaレベルとネイティブレベルの両方でフォーカスの所有者をクリアする。それ以外の場合、このメソッドは何も行わずに復帰する。
{java.io}
[BufferedReader]
* lines:public Stream<String> lines()…Streamを返す。要素はBufferedReaderから読み込まれる行。
{java.lang}
[CharSequence]
* chars:
default IntStream chars()…このシーケンスのchar値をゼロ拡張したintを含む、ストリームを返す。
* codePoints:default IntStream codePoints()…このシーケンスからコードポイント値のストリームを返す。
[Iterable]
* forEach:default void forEach(Consumer<? super T> action)…Iterableの各要素に対して指定されたアクションを、すべての要素が処理されるか、アクションが例外を投入するまで実行する。
* spliterator:default Spliterator<T> spliterator()…このIterableによって記述される要素に対するSpliteratorを作成する。
[Boolean]
* hashCode:public static int hashCode(boolean value)…Boolean.hashCode()との互換性がある、boolean値のハッシュコードを返す。
* logicalAnd:public static boolean logicalAnd(boolean a, boolean b)…指定されたbooleanオペランドに論理積演算子を適用した結果を返す。
* logicalOr:public static boolean logicalOr(boolean a, boolean b)…指定されたbooleanオペランドに論理和演算子を適用した結果を返す。
* logicalXor:public static boolean logicalXor(boolean a, boolean b)…指定されたbooleanオペランドに排他的論理和演算子を適用した結果を返す。
[Byte]
* hashCode:public static int hashCode(byte value)…Byte.hashCode()との互換性がある、byte値のハッシュコードを返す。
* toUnsignedInt:public static int toUnsignedInt(byte x)…符号なし変換によって、その引数をintに変換する。
* toUnsignedLong:public static long toUnsignedLong(byte x)…符号なし変換によって、その引数をlongに変換する。
[Character]
* hashCode:public static int hashCode(char value)…Character.hashCode()との互換性がある、char値のハッシュコードを返す。
[Class]
* getAnnotatedInterfaces:public AnnotatedType[] getAnnotatedInterfaces()…Classオブジェクトによって表されるエンティティのスーパーインタフェースを指定する型の使用を表すAnnotatedTypeオブジェクトの配列を返す。
* getAnnotatedSuperclass:public AnnotatedType getAnnotatedSuperclass()…Classオブジェクトによって表されるエンティティのスーパークラスを指定する型の使用を表すAnnotatedTypeオブジェクトを返す。
* getAnnotationsByType:public <A extends Annotation> A[] getAnnotationsByType(Class<A> annotationClass)…この要素に関連付けられている注釈を返す。
* getDeclaredAnnotation:public <A extends Annotation> A getDeclaredAnnotation(Class<A> annotationClass)…直接存在する場合は、この要素の指定された型の注釈を返し、そうでない場合はnullを返す。
* getDeclaredAnnotationsByType:public <A extends Annotation> A[] getDeclaredAnnotationsByType(Class<A> annotationClass)…直接存在するか間接的に存在する場合は、この要素の指定された型の注釈を返す。
* getTypeName:public String getTypeName()…この型の名前に関する情報提供文字列を返す。
* toGenericString:public String toGenericString()…修飾子と型パラメータに関する情報を含む、このClassを記述する文字列を返す。
[Double]
* hashCode:public static int hashCode(double value)…Double.hashCode()との互換性がある、double値のハッシュコードを返す。
* isFinite:public static boolean isFinite(double d)…引数が有限の浮動小数点値である場合はtrueを返し、そうでない場合(NaNおよび無限大の引数の場合)はfalseを返す。
* max:public static double max(double a, double b)…Math.maxを呼び出した場合と同様に、2つのdouble値の大きいほうを返す。
* min:public static double min(double a, double b)…Math.minを呼び出した場合と同様に、2つのdouble値の小さいほうを返す。
* sum:public static double sum(double a, double b)…+演算子のように、2つのdouble値を加算する。
[Float]
* hashCode:public static int hashCode(float value)…Float.hashCode()との互換性がある、float値のハッシュコードを返す。
* isFinite:public static boolean isFinite(float f)…引数が有限の浮動小数点値である場合はtrueを返し、そうでない場合(NaNおよび無限大の引数の場合)はfalseを返す。
* max:public static float max(float a, float b)…Math.maxを呼び出した場合と同様に、2つのfloat値の大きいほうを返す。
* min:public static float min(float a, float b)…Math.minを呼び出した場合と同様に、2つのfloat値の小さいほうを返す。
* sum:public static float sum(float a, float b)…+演算子のように、2つのfloat値を加算する。
[Integer]
* compareUnsigned:public static int compareUnsigned(int x, int y)…2つのint値を符号なしとして処理して数値的に比較する。
* divideUnsigned:public static int divideUnsigned(int dividend, int divisor)…第1引数を第2引数で除算した、符号なしの商を返す。各引数と結果は符号なしの値として解釈される。
* hashCode:public static int hashCode(int value)…Integer.hashCode()との互換性がある、int値のハッシュコードを返す。
* max:public static int max(int a, int b)…Math.maxを呼び出した場合と同様に、2つのint値の大きいほうを返す。
* min:public static int min(int a, int b)…Math.minを呼び出した場合と同様に、2つのint値の小さいほうを返す。
* parseUnsignedInt:public static int parseUnsignedInt(String s) throws NumberFormatException…文字列の引数を符号なし10進数の整数として構文解析する。
* parseUnsignedInt:public static int parseUnsignedInt(String s, int radix) throws NumberFormatException…2番目の引数に指定された基数をもとにして、文字列の引数を符号なし整数として構文解析する。
* remainderUnsigned:public static int remainderUnsigned(int dividend, int divisor)…第1引数を第2引数で割った、符号なしの余りを返す。各引数と結果は符号なしの値として解釈される。
* sum:public static int sum(int a, int b)…+演算子のように、2つの整数を加算する。
* toUnsignedLong:public static long toUnsignedLong(int x)…符号なし変換によって、その引数をlongに変換する。
* toUnsignedString:public static String toUnsignedString(int i)…引数の文字列表現を、符号なし10進値として返す。
* toUnsignedString:public static String toUnsignedString(int i, int radix)…1番目の引数の文字列表現を、2番目の引数で指定された基数の符号なし整数値として返す。
[Long]
* compareUnsigned:public static int compareUnsigned(long x, long y)…2つのlong値を符号なしとして処理して数値的に比較する。
* divideUnsigned:public static long divideUnsigned(long dividend, long divisor)…第1引数を第2引数で除算した、符号なしの商を返す。各引数と結果は符号なしの値として解釈される。
* hashCode:public static int hashCode(long value)…Long.hashCode()との互換性がある、long値のハッシュコードを返す。
* max:public static long max(long a, long b)…Math.maxを呼び出した場合と同様に、2つのlong値の大きいほうを返す。
* min:public static long min(long a, long b)…Math.minを呼び出した場合と同様に、2つのlong値の小さいほうを返す。
* parseUnsignedLong:public static long parseUnsignedLong(String s) throws NumberFormatException…文字列の引数を符号なし10進数のlongとして構文解析する。
* parseUnsignedLong:public static long parseUnsignedLong(String s, int radix) throws NumberFormatException…2番目の引数に指定された基数をもとにして、文字列の引数を符号なしlongとして構文解析する。
* remainderUnsigned:public static long remainderUnsigned(long dividend, long divisor)…第1引数を第2引数で割った符号なしの余りを返す。各引数と結果は符号なしの値として解釈される。
* sum:public static long sum(long a, long b)…+演算子のように、2つのlong値を加算する。
* toUnsignedString:public static String toUnsignedString(long i)…引数の文字列表現を、符号なし10進値として返す。
* toUnsignedString:public static String toUnsignedString(long i, int radix)…1番目の引数の文字列表現を、2番目の引数で指定された基数の符号なし整数値として返す。
[Math]
* addExact:public static int addExact(int x, int y)…引数の合計を返す。結果がintをオーバーフローする場合は例外を投入する。
* addExact:public static long addExact(long x, long y)…引数の合計を返す。その結果がlongをオーバーフローする場合は例外を投入する。
* decrementExact:public static int decrementExact(int a)…引数を1だけ減分したものを返す。結果がintをオーバーフローする場合は例外を投入する。
* decrementExact:public static long decrementExact(long a)…引数を1だけ減分したものを返す。結果がlongをオーバーフローする場合は例外を投入する。
* floorDiv:public static int floorDiv(int x, int y)…商代数以下の最大(正の無限大にもっとも近い)int値を返す。
* floorDiv:public static long floorDiv(long x, long y)…商代数以下の最大(正の無限大にもっとも近い)long値を返す。
* floorMod:public static int floorMod(int x, int y)…int引数のフロアモジュラスを返す。
* floorMod:public static long floorMod(long x, long y)…long引数のフロアモジュラスを返す。
* incrementExact:public static int incrementExact(int a)…引数を1だけ増分して返す。結果がintをオーバーフローした場合は例外を投入する。
* incrementExact:public static long incrementExact(long a)…引数を1だけ増分して返す。結果がlongをオーバーフローした場合は例外を投入する。
* multiplyExact:public static int multiplyExact(int x, int y)…引数の積を返す。結果がintをオーバーフローした場合は例外を投入する。
* multiplyExact:public static long multiplyExact(long x, long y)…引数の積を返す。結果がlongをオーバーフローした場合は例外を投入する。
* negateExact:public static int negateExact(int a)…引数の否定を返す。結果がintをオーバーフローした場合は例外を投入する。
* negateExact:public static long negateExact(long a)…引数の否定を返す。結果がlongをオーバーフローした場合は例外を投入する。
* nextDown:public static double nextDown(double d)…負の無限大方向でdに隣接する浮動小数点値を返す。
* nextDown:public static float nextDown(float f)…負の無限大方向でfに隣接する浮動小数点値を返す。
* subtractExact:public static int subtractExact(int x, int y)…引数の差分を返す。結果がintをオーバーフローした場合は例外を投入する。
* subtractExact:public static long subtractExact(long x, long y)…引数の差分を返す。結果がlongをオーバーフローした場合は例外を投入する。
* toIntExact:public static int toIntExact(long value)…long引数の値を返す。その値がintに収まらない場合は例外を投入する。
[Package]
* getAnnotationsByType:public <A extends Annotation> A[] getAnnotationsByType(Class<A> annotationClass)…この要素に関連付けられている注釈を返す。
* getDeclaredAnnotation:public <A extends Annotation> A getDeclaredAnnotation(Class<A> annotationClass)…直接存在する場合は、この要素の指定された型の注釈を返し、そうでない場合はnullを返す。
* getDeclaredAnnotationsByType:public <A extends Annotation> A[] getDeclaredAnnotationsByType(Class<A> annotationClass)…直接存在するか間接的に存在する場合は、この要素の指定された型の注釈を返す。
[Process]
* destroyForcibly:public Process destroyForcibly()…サブプロセスを終了する。
* isAlive:public boolean isAlive()…このProcessが表すサブプロセスが生存しているかどうかを判定する。
* waitFor:public boolean waitFor(long timeout, TimeUnit unit) throws InterruptedException…必要に応じて、このProcessオブジェクトが表すサブプロセスが終了するか、指定された待機時間が経過するまで、現在のスレッドを待機させる。
[Short]
* hashCode:public static int hashCode(short value)…Short.hashCode()との互換性がある、short値のハッシュコードを返す。
* toUnsignedInt:public static int toUnsignedInt(short x)…符号なし変換によって、その引数をintに変換する。
* toUnsignedLong:public static long toUnsignedLong(short x)…符号なし変換によって、その引数をlongに変換する。
[StrictMath]
* addExact:public static int addExact(int x, int y)…引数の合計を返す。結果がintをオーバーフローする場合は例外を投入する。
* addExact:public static long addExact(long x, long y)…引数の合計を返す。その結果がlongをオーバーフローする場合は例外を投入する。
* floorDiv:public static int floorDiv(int x, int y)…商代数以下の最大(正の無限大にもっとも近い)int値を返す。
* floorDiv:public static long floorDiv(long x, long y)…商代数以下の最大(正の無限大にもっとも近い)long値を返す。
* floorMod:public static int floorMod(int x, int y)…int引数のフロアモジュラスを返す。
* floorMod:public static long floorMod(long x, long y)…long引数のフロアモジュラスを返する。
* multiplyExact:public static int multiplyExact(int x, int y)…引数の積を返す。結果がintをオーバーフローした場合は例外をスローする。
* multiplyExact:public static long multiplyExact(long x, long y)…引数の積を返す。結果がlongをオーバーフローした場合は例外をスローする。
* nextDown:public static double nextDown(double d)…負の無限大方向でdに隣接する浮動小数点値を返す。
* nextDown:public static float nextDown(float f)…負の無限大方向でfに隣接する浮動小数点値を返す。
* subtractExact:public static int subtractExact(int x, int y)…引数の差分を返す。結果がintをオーバーフローした場合は例外をスローする。
* subtractExact:public static long subtractExact(long x, long y)…引数の差分を返す。結果がlongをオーバーフローした場合は例外をスローする。
* toIntExact:public static int toIntExact(long value)…long引数の値を返す。その値がintに収まらない場合は例外をスローする。
[String]
* join:public static String join(CharSequence delimiter, CharSequence... elements)…指定されたdelimiterのコピーを使用して結合されたCharSequence要素のコピーからなる新しいStringを返す。
* join:public static String join(CharSequence delimiter, Iterable<? extends CharSequence> elements)…指定されたdelimiterのコピーを使用して結合されたCharSequence関連要素のコピーからなる新しいStringを返す。
[ThreadLocal]
* withInitial:public static <S> ThreadLocal<S> withInitial(Supplier<? extends S> supplier)…スレッドローカル変数を作成する。
{java.lang.invoke}
[MethodHandles]
* reflectAs:public static <T extends Member> T reflectAs(Class<T> expected, MethodHandle target)…直接メソッドハンドルの未チェックの解読を実行する。
[MethodHandles.Lookup]
* revealDirect:public MethodHandleInfo revealDirect(MethodHandle target)…この参照オブジェクトまたは類似のオブジェクトによって作成された直接メソッドハンドルを解読する。
{java.lang.management}
[LockInfo]
* from:public static LockInfo from(CompositeData cd)…指定されたCompositeDataによって表されるLockInfoオブジェクトを返す。
{java.lang.reflect}
[AnnotatedElement]
* getAnnotationsByType:default <T extends Annotation> T[] getAnnotationsByType(Class<T> annotationClass)…この要素に関連付けられている注釈を返す。
* getDeclaredAnnotation:default <T extends Annotation> T getDeclaredAnnotation(Class<T> annotationClass)…直接存在する場合は、この要素の指定された型の注釈を返し、そうでない場合はnullを返す。
* getDeclaredAnnotationsByType:default <T extends Annotation> T[] getDeclaredAnnotationsByType(Class<T> annotationClass)…直接存在するか間接的に存在する場合は、この要素の指定された型の注釈を返す。
[Type]
* getTypeName:default String getTypeName()…型パラメータに関する情報を含む、この型を記述する文字列を返す。
[TypeVariable]
* getAnnotatedBounds:AnnotatedType[] getAnnotatedBounds()…TypeVariableによって表される型パラメータの上限を示す型の使用を表すAnnotatedType オブジェクトの配列を返す。
[AccessibleObject]
* getAnnotationsByType:public <T extends Annotation> T[] getAnnotationsByType(Class<T> annotationClass)…この要素に関連付けられている注釈を返す。
* getDeclaredAnnotation:public <T extends Annotation> T getDeclaredAnnotation(Class<T> annotationClass)…直接存在する場合は、この要素の指定された型の注釈を返し、そうでない場合はnullを返す。
* getDeclaredAnnotationsByType:public <T extends Annotation> T[] getDeclaredAnnotationsByType(Class<T> annotationClass)…直接存在するか間接的に存在する場合は、この要素の指定された型の注釈を返す。
[Constructor]
* getAnnotatedReceiverType:public AnnotatedType getAnnotatedReceiverType()…このExecutableオブジェクトによって表されるメソッドまたはコンストラクタのレシーバの型を指定する型の使用を表すAnnotatedTypeオブジェクトを返す。
* getAnnotatedReturnType:public AnnotatedType getAnnotatedReturnType()…このExecutableによって表されるメソッドまたはコンストラクタの戻り型を指定する型の使用を表すAnnotatedTypeオブジェクトを返す。
[Executable]
* getAnnotatedExceptionTypes:public AnnotatedType[] getAnnotatedExceptionTypes()…このExecutableによって表されるメソッドまたはコンストラクタの宣言された例外を指定する型の使用を表すAnnotatedTypeオブジェクトの配列を返す。
* getAnnotatedParameterTypes:public AnnotatedType[] getAnnotatedParameterTypes()…このExecutableによって表されるメソッドまたはコンストラクタの仮パラメータ型を指定する型の使用を表すAnnotatedTypeオブジェクトの配列を返す。
* getAnnotatedReceiverType:public AnnotatedType getAnnotatedReceiverType()…このExecutableオブジェクトによって表されるメソッドまたはコンストラクタのレシーバの型を指定する型の使用を表すAnnotatedTypeオブジェクトを返す。
* getAnnotatedReturnType:public abstract AnnotatedType getAnnotatedReturnType()…このExecutableによって表されるメソッドまたはコンストラクタの戻り型を指定する型の使用を表すAnnotatedTypeオブジェクトを返す。
* getAnnotationsByType:public <T extends Annotation> T[] getAnnotationsByType(Class<T> annotationClass)…この要素に関連付けられている注釈を返す。
* getParameterCount:public int getParameterCount()…このオブジェクトによって表される実行可能要素の仮パラメータ(明示的に宣言されているか、暗黙的に宣言されているか、そのいずれでもないかに関係なく)の数を返す。
* getParameters:public Parameter[] getParameters()…
このオブジェクトによって表される基本となる実行可能要素に対するすべてのパラメータを表すParameterオブジェクトの配列を返す。
[Field]
* getAnnotatedType:public AnnotatedType getAnnotatedType()…このFieldによって表されるフィールドの宣言型を指定する型の使用を表すAnnotatedTypeオブジェクトを返す。
* getAnnotationsByType:public <T extends Annotation> T[] getAnnotationsByType(Class<T> annotationClass)…この要素に関連付けられている注釈を返す。
[Method]
* getAnnotatedReturnType:public AnnotatedType getAnnotatedReturnType()…このExecutableによって表されるメソッドまたはコンストラクタの戻り型を指定する型の使用を表すAnnotatedTypeオブジェクトを返す。
* isDefault:public boolean isDefault()…このメソッドがデフォルトメソッドである場合はtrueを返し、そうでない場合はfalseを返す。
[Modifier]
* parameterModifiers:public static int parameterModifiers()…パラメータに適用可能なソース言語修飾子の論理和となるint値を返す。
{java.math}
[BigInteger]
* byteValueExact:public byte byteValueExact()…このBigIntegerをbyteに変換し、失われた情報がないかどうかを確認する。
* intValueExact:public int intValueExact()…このBigIntegerをintに変換し、失われた情報がないかどうかを確認する。
* longValueExact:public long longValueExact()…このBigIntegerをlongに変換し、失われた情報がないかどうかを確認する。
* shortValueExact:public short shortValueExact()…このBigIntegerをshortに変換して、失われた情報がないかどうかを確認する。
{java.nio.file}
[Files]
* find:public static Stream<Path> find(Path start, int maxDepth, BiPredicate<Path,BasicFileAttributes> matcher, FileVisitOption... options) throws IOException…指定された開始ファイルをルートとするファイルツリー内でファイルを検索することでPathが遅延設定されるStreamを返す(IOExceptionをスロー)。
* lines:public static Stream<String> lines(Path path) throws IOException…ファイル内のすべての行をStreamとして読み取る(IOExceptionをスロー)。
* lines:public static Stream<String> lines(Path path, Charset cs) throws IOException…ファイル内のすべての行でCharset csをStreamとして読み取る(IOExceptionをスロー)。
* list:public static Stream<Path> list(Path dir) throws IOException…ディレクトリ内のエントリを要素に持つ遅延設定Streamを返す(IOExceptionをスロー)。
* newBufferedReader:public static BufferedReader newBufferedReader(Path path) throws IOException…ファイルを読込み用に開き、効率的な方法でファイルからテキストを読み込むBufferedReaderを返す(IOExceptionをスロー)。
* newBufferedWriter:public static BufferedWriter newBufferedWriter(Path path, OpenOption... options) throws IOException…ファイルを書込み用に開くか作成し、効率的な方法でファイルにテキストを書き込むBufferedWriterを返す(IOExceptionをスロー)。
* readAllLines:public static List<String> readAllLines(Path path) throws IOException…ファイルからすべての行を読み取る(IOExceptionをスロー)。
* walk:public static Stream<Path> walk(Path start, FileVisitOption... options) throws IOException…指定された開始ファイルをルートとするファイルツリーを参照することでPathが遅延移入されるStreamを返す(IOExceptionをスロー)。
* walk:public static Stream<Path> walk(Path start, int maxDepth, FileVisitOption... options) throws IOException…指定された開始ファイルをルートとするファイルツリーを参照することでPathがintが最大デプスで遅延移入されるStreamを返す(IOExceptionをスロー)。
* write:public static Path write(Path path, Iterable<? extends CharSequence> lines, OpenOption... options) throws IOException…テキスト行をファイルに書き込む(IOExceptionをスロー)。
{java.nio.file.attribute}
[FileTime]
* from:public static FileTime from(Instant instant)…時系列上で、指定されたInstantオブジェクトと同じ時点の値を表すFileTimeを返す。
* toInstant:public Instant toInstant()…このFileTimeオブジェクトをInstantに変換する。
{java.security}
[KeyStore.Entry]
* getAttributes:default Set<KeyStore.Entry.Attribute> getAttributes()…エントリに関連付けられている属性を取得する。
[Principal]
* implies:default boolean implies(Subject subject)…指定されたサブジェクトがこのサブジェクトに含まれている場合はtrueを返す。
[AccessController]
* doPrivileged:public static <T> T doPrivileged(PrivilegedAction<T> action, AccessControlContext context, Permission... perms)…指定されたAccessControlContextによって許可および制限される特権と、指定されたPermission引数によって制限される特権範囲を使用して、指定されたPrivilegedActionを実行する。
* doPrivileged:public static <T> T doPrivileged(PrivilegedExceptionAction<T> action, AccessControlContext context, Permission... perms) throws PrivilegedActionException…指定されたAccessControlContextによって許可および制限される特権と、指定されたPermission引数によって制限される特権範囲を使用して、指定されたPrivilegedExceptionActionを実行する(PrivilegedActionExceptionをスロー)。
* doPrivilegedWithCombiner:public static <T> T doPrivilegedWithCombiner(PrivilegedAction<T> action, AccessControlContext context, Permission... perms)…指定されたAccessControlContextによって許可および制限される特権と、指定されたPermission引数によって制限される特権範囲を使用して、指定されたPrivilegedActionを実行する。
* doPrivilegedWithCombiner:public static <T> T doPrivilegedWithCombiner(PrivilegedExceptionAction<T> action, AccessControlContext context, Permission... perms) throws PrivilegedActionException…指定されたAccessControlContextによって許可および制限される特権と、指定されたPermission引数によって制限される特権範囲を使用して、指定されたPrivilegedExceptionActionを実行する(PrivilegedActionExceptionをスロー)。
[KeyStore.PasswordProtection]
* getProtectionAlgorithm:public String getProtectionAlgorithm()…保護アルゴリズムの名前を取得する。
* getProtectionParameters:public AlgorithmParameterSpec getProtectionParameters()…保護アルゴリズムに対して指定されたパラメータを取得する。
[KeyStore.PrivateKeyEntry]
* getAttributes:public Set<KeyStore.PrivateKeyEntry.Attribute> getAttributes()…プライベートキーエントリに関連付けられている属性を取得する。
[KeyStore.SecretKeyEntry]
* getAttributes:public Set<KeyStore.SecretKeyEntry.Attribute> getAttributes()…シークレットキーエントリに関連付けられている属性を取得する。
[KeyStore.TrustedCertificateEntry]
* getAttributes:public Set<KeyStore.TrustedCertificateEntry.Attribute> getAttributes()…信頼性を保証するエントリに関連付けられている属性を取得する。
[Provider]
* compute:public Object compute(Object key, BiFunction<? super Object,? super Object,? extends Object> remappingFunction)…指定されたキーと現在マップされている値に対するマッピングの計算を試みる(現在のマッピングが存在しない場合はnull)。
* computeIfAbsent:public Object computeIfAbsent(Object key, Function<? super Object,? extends Object> mappingFunction)…指定されたキーがまだ値に関連付けられていない(またはnullにマップされている)場合、指定されたマッピング関数を使用してその値の計算を試行し、nullでない場合はそれをこのマップに入力する。
* computeIfPresent:public Object computeIfPresent(Object key, BiFunction<? super Object,? super Object,? extends Object> remappingFunction)…指定されたキーの値が存在していてnull以外の場合、キーと現在マップされている値から新しいマッピングの計算を試みる。
* forEach:public void forEach(BiConsumer<? super Object,? super Object> action)…このマップのすべてのエントリの処理が完了するかアクションから例外がスローされるまで、各エントリに対して指定されたアクションを実行する。
* getOrDefault:public Object getOrDefault(Object key, Object defaultValue)…指定されたキーがマップされている値を返す。このマップにそのキーのマッピングが含まれていない場合はdefaultValueを返す。
* merge:public Object merge(Object key, Object value, BiFunction<? super Object,? super Object,? extends Object> remappingFunction)…指定されたキーがまだ値と関連付けられていないかnullと関連付けられている場合、指定された値に関連付ける。
* putIfAbsent:public Object putIfAbsent(Object key, Object value)…指定されたキーがまだ値に関連付けられていない(または、nullにマップされている)場合は、それを指定された値に関連付けてnullを返す。それ以外の場合は、現在の値を返す。
* remove:public boolean remove(Object key, Object value)…指定された値に指定されたキーが現在マッピングされている場合にのみ、そのキーのエントリを削除する。
* replace:public Object replace(Object key, Object value)…指定されたキーがなんらかの値に現在マッピングされている場合にのみ、そのキーのエントリを置換する。
* replace:public boolean replace(Object key, Object oldValue, Object newValue)…指定されたキーが指定された値に現在マッピングされている場合にのみ、そのキーのエントリを置換する。
* replaceAll:public void replaceAll(BiFunction<? super Object,? super Object,? extends Object> function)…すべてのエントリが処理されるか、または関数が例外をスローするまで、エントリセットイテレータによってエントリが返される順に、各エントリの値を、そのエントリで指定された関数を呼び出した結果で置換する。
[SecureRandom]
* getInstanceStrong:public static SecureRandom getInstanceStrong() throws NoSuchAlgorithmException securerandom.strongAlgorithmsSecurity…プロパティで指定されたアルゴリズムまたはプロバイダを使用して選択されたSecureRandomオブジェクトを返す。
{java.security.cert}
[Certificate]
* verify:public void verify(PublicKey key, Provider sigProvider) throws CertificateException, NoSuchAlgorithmException, InvalidKeyException, SignatureException…指定された公開鍵に対応する非公開鍵を使って、この証明書が署名されたことを検証する。
[CertPathBuilder]
* getRevocationChecker:public final CertPathChecker getRevocationChecker()…カプセル化されたCertPathBuilderSpi実装が証明書の失効ステータスをチェックするために使用するCertPathCheckerを返す。
[CertPathBuilderSpi]
* engineGetRevocationChecker:public CertPathChecker engineGetRevocationChecker()…この実装が証明書の失効ステータスをチェックするために使用するCertPathCheckerを返す。
[CertPathValidator]
* getRevocationChecker:public final CertPathChecker getRevocationChecker()…カプセル化されたCertPathValidatorSpi実装が証明書の失効ステータスをチェックするために使用するCertPathCheckerを返す。
[CertPathValidatorSpi]
* engineGetRevocationChecker:public CertPathChecker engineGetRevocationChecker()…この実装が証明書の失効ステータスをチェックするために使用するCertPathCheckerを返す。
[X509Certificate]
* verify:public void verify(PublicKey key, Provider sigProvider) throws CertificateException, NoSuchAlgorithmException, InvalidKeyException, SignatureException…指定された公開鍵に対応する非公開鍵を使って、この証明書が署名されたことを検証する。
[X509CRL]
* verify:
public void verify(PublicKey key, Provider sigProvider) throws CRLException, NoSuchAlgorithmException, InvalidKeyException, SignatureException…指定された公開鍵に対応する非公開鍵を使って、このCRLが署名されたことを検証する。
{java.sql}
[CallableStatement]
* registerOutParameter:default void registerOutParameter(int parameterIndex, SQLType sqlType) throws SQLException…int parameterIndexのOUTパラメータをSQLT型sqlTypeとして登録する(SQLExceptionをスロー)。
* registerOutParameter:default void registerOutParameter(String parameterName, SQLType sqlType) throws SQLException…parameterNameという名前のOUTパラメータをSQLT型sqlTypeとして登録する(SQLExceptionをスロー)。
* setObject:default void setObject(String parameterName, Object x, SQLType targetSqlType) throws SQLException…指定されたパラメータの値を、指定されたオブジェクトで設定する(SQLExceptionをスロー)。
* setObject:default void setObject(String parameterName, Object x, SQLType targetSqlType, int scaleOrLength) throws SQLException…指定されたパラメータの値を、指定されたオブジェクトで設定する(SQLExceptionをスロー)。
[DatabaseMetaData]
* getMaxLogicalLobSize:default long getMaxLogicalLobSize() throws SQLException…このデータベースでLOBの論理サイズとして許容される最大バイト数を取得する(SQLExceptionをスロー)。
* supportsRefCursors:default boolean supportsRefCursors() throws SQLException…このデータベースによってREF CURSORがサポートされるかどうかを取得する(SQLExceptionをスロー)。
[DriverAction]
* deregister:void deregister()…登録解除されたことをJDBCドライバに通知するためにDriverManager.deregisterDriver(Driver)によって呼び出されるメソッド。
[PreparedStatement]
* executeLargeUpdate:default long executeLargeUpdate() throws SQLException…このPreparedStatementオブジェクトのSQL文を実行する(SQLExceptionをスロー)。それはSQLデータ操作言語(DML)文(INSERT文、UPDATE文、DELETE文など)であるか、DDL文のような何も返さないSQL文でなければならない。
* setObject:default void setObject(int parameterIndex, Object x, SQLType targetSqlType) throws SQLException…指定されたパラメータの値を、指定されたオブジェクトで設定する(SQLExceptionをスロー)。
* setObject:default void setObject(int parameterIndex, Object x, SQLType targetSqlType, int scaleOrLength) throws SQLException…指定されたパラメータの値を、指定されたオブジェクトで設定する(SQLExceptionをスロー)。
[ResultSet]
* updateObject:default void updateObject(int columnIndex, Object x, SQLType targetSqlType) throws SQLException…指定された列をObject値で更新する(SQLExceptionをスロー)。
* updateObject:default void updateObject(int columnIndex, Object x, SQLType targetSqlType, int scaleOrLength) throws SQLException…指定された列をObject値で更新する(SQLExceptionをスロー)。
* updateObject:default void updateObject(String columnLabel, Object x, SQLType targetSqlType) throws SQLException…指定された列をObject値で更新する(SQLExceptionをスロー)。
* updateObject:default void updateObject(String columnLabel, Object x, SQLType targetSqlType, int scaleOrLength) throws SQLException…指定された列をObject値で更新する(SQLExceptionをスロー)。
[SQLInput]
* readObject:default <T> T readObject(Class<T> type) throws SQLException…ストリーム内の次の属性を読み込み、それをJavaプログラミング言語のObjectとして返す(SQLExceptionをスロー)。
[SQLOutput]
* writeObject:default void writeObject(Object x, SQLType targetSqlType) throws SQLException…指定されたオブジェクトに格納されたデータをストリームに書き込む(SQLExceptionをスロー)。
[Statement]
* executeLargeBatch:default long[] executeLargeBatch() throws SQLException…コマンドのバッチをデータベースに送信して実行し、すべてのコマンドが正常に実行されると、更新カウントの配列を返す(SQLExceptionをスロー)。
* executeLargeUpdate:default long executeLargeUpdate(String sql) throws SQLException…指定されたSQL文を実行する(SQLExceptionをスロー)。SQL文は、INSERT文、UPDATE文、DELETE文、またはSQL DDL文のような何も返さないSQL文の場合がある。
* executeLargeUpdate:default long executeLargeUpdate(String sql, int autoGeneratedKeys) throws SQLException…指定されたSQL文を実行し、このStatementオブジェクトによって生成された自動生成キーを検索可能にするかどうかについて指定されたフラグでドライバに通知する(SQLExceptionをスロー)。
* executeLargeUpdate:default long executeLargeUpdate(String sql, int[] columnIndexes) throws SQLException…指定されたSQL文を実行し、指定された配列で示された自動生成キーを検索可能にすることをドライバに通知する(SQLExceptionをスロー)。
* executeLargeUpdate:default long executeLargeUpdate(String sql, String[] columnNames) throws SQLException…指定されたSQL文を実行し、指定された配列で示された自動生成キーを検索可能にすることをドライバに通知する(SQLExceptionをスロー)。
* getLargeMaxRows:default long getLargeMaxRows() throws SQLException…このStatementオブジェクトによって生成されるResultSetオブジェクトに含めることのできる最大行数を取得する(SQLExceptionをスロー)。
* getLargeUpdateCount:default long getLargeUpdateCount() throws SQLException…更新カウントとして現在の結果を取得する。結果がResultSetオブジェクトであるか、または結果がない場合は−1を返す(SQLExceptionをスロー)。
* setLargeMaxRows:default void setLargeMaxRows(long max) throws SQLException…このStatementオブジェクトで作成された任意のResultSetオブジェクトが含むことのできる最大行数の制限値を、指定された数に設定する(SQLExceptionをスロー)。
[Date]
* toLocalDate:public LocalDate toLocalDate()…このDateオブジェクトをLocalDateに変換する。
* valueOf:public static Date valueOf(LocalDate date)…指定されたLocalDateと同じ年、月、および月間通算日の値を持つDateのインスタンスをLocalDateオブジェクトから取得する。
[DriverManager]
* registerDriver:public static void registerDriver(Driver driver, DriverAction da) throws SQLException…指定されたドライバをDriverManagerに登録する(SQLExceptionをスロー)。
[Time]
* toLocalTime:public LocalTime toLocalTime()…このTimeオブジェクトをLocalTimeに変換する。
* valueOf:public static Time valueOf(LocalTime time)…指定されたLocalTimeと同じ時、分、および秒の時間値を持つTimeのインスタンスをLocalTimeオブジェクトから取得する。
[Timestamp]
* from:public static Timestamp from(Instant instant)…InstantオブジェクトからTimestampのインスタンスを取得する。
* toInstant:public Instant toInstant()…このTimestampオブジェクトをInstantに変換する。
* toLocalDateTime:public LocalDateTime toLocalDateTime()…このTimestampオブジェクトをLocalDateTimeに変換する。
* valueOf:public static Timestamp valueOf(LocalDateTime dateTime)…指定されたLocalDateTimeと同じ年、月、「月の日」、時、分、秒およびナノ秒の日付/時間値を持つTimestampのインスタンスをLocalDateTimeオブジェクトから取得する。
[BatchUpdateException]
* getLargeUpdateCounts:public long[] getLargeUpdateCounts()…バッチ更新内の更新文のうち、この例外が発生するまでに正常に実行されたものすべてに対する更新カウントを取り出す。
{java.util}
[Collection]
* parallelStream:default Stream<E> parallelStream()…このコレクションをソースとして、潜在的に並列のStreamを返す。
* removeIf:default boolean removeIf(Predicate<? super E> filter)…指定された述語を満たすこのコレクションの要素をすべて削除する。
* spliterator:default Spliterator<E> spliterator()…このコレクション内の要素に対するSpliteratorを作成する。
* stream:default Stream<E> stream()…このコレクションをソースとして使用して、逐次的なStreamを返す。
[Comparator]
* comparing:static <T,U extends Comparable<? super U>> Comparator<T> comparing(Function<? super T,? extends U> keyExtractor)…型TからComparableソートキーを抽出する関数を受け取り、そのソートキーで比較するComparatorを返す。
* comparing:static <T,U> Comparator<T> comparing(Function<? super T,? extends U> keyExtractor, Comparator<? super U> keyComparator)…型Tからソートキーを抽出する関数を受け取り、指定されたComparatorを使ってそのソートキーで比較するComparatorを返す。
* comparingDouble:static <T> Comparator<T> comparingDouble(ToDoubleFunction<? super T> keyExtractor)…型Tからdoubleソートキーを抽出する関数を受け取り、そのソートキーで比較するComparatorを返す。
* comparingInt:static <T> Comparator<T> comparingInt(ToIntFunction<? super T> keyExtractor)…型Tからintソートキーを抽出する関数を受け取り、そのソートキーで比較するComparatorを返す。
* comparingLong:static <T> Comparator<T> comparingLong(ToLongFunction<? super T> keyExtractor)…型Tからlongソートキーを抽出する関数を受け取り、そのソートキーで比較するComparatorを返す。
* naturalOrder:static <T extends Comparable<? super T>> Comparator<T> naturalOrder()…自然な順序でComparableオブジェクトを比較するコンパレータを返す。
* nullsFirst:static <T> Comparator<T> nullsFirst(Comparator<? super T> comparator)…nullをnull以外より小さいとみなす、nullフレンドリのコンパレータを返す。
* nullsLast:static <T> Comparator<T> nullsLast(Comparator<? super T> comparator)…nullをnull以外より大きいとみなす、nullフレンドリのコンパレータを返す。
* reversed:default Comparator<T> reversed()…予約されたデフォルトコンパレータを返す。
* reverseOrder:static <T extends Comparable<? super T>> Comparator<T> reverseOrder()…自然順序付けの逆を義務付けるコンパレータを返す。
* thenComparing:default Comparator<T> thenComparing(Comparator<? super T> other)…辞書式順序コンパレータをもう一方のコンパレータとともに返す。
* thenComparing:default <U extends Comparable<? super U>> Comparator<T> thenComparing(Function<? super T,? extends U> keyExtractor)…Comparableソートキーを抽出する関数を含む辞書式順序コンパレータを返す。
* thenComparing:default <U> Comparator<T> thenComparing(Function<? super T,? extends U> keyExtractor, Comparator<? super U> keyComparator)…指定されたComparatorで比較されるキーを抽出する関数を含む辞書式順序コンパレータを返す。
* thenComparingDouble:default Comparator<T> thenComparingDouble(ToDoubleFunction<? super T> keyExtractor)…doubleソートキーを抽出する関数を含む辞書式順序コンパレータを返す。
* thenComparingInt:default Comparator<T> thenComparingInt(ToIntFunction<? super T> keyExtractor)…intソートキーを抽出する関数を含む辞書式順序コンパレータを返す。
* thenComparingLong:default Comparator<T> thenComparingLong(ToLongFunction<? super T> keyExtractor)…longソートキーを抽出する関数を含む辞書式順序コンパレータを返す。
[Iterator]
* forEachRemaining:default void forEachRemaining(Consumer<? super E> action)…すべての要素の処理が完了するかアクションから例外がスローされるまで、残りの各要素に対して指定されたアクションを実行する。
[List]
* replaceAll:default void replaceAll(UnaryOperator<E> operator)…このリストの各要素を、その要素に演算子を適用した結果で置換する。
* sort:default void sort(Comparator<? super E> c)…指定されたComparatorを使用して要素を比較することにより、このリストをソートする。
* spliterator:default Spliterator<E> spliterator()…このリスト内の要素に対するSpliteratorを作成する。
[Map]
* compute:default V compute(K key, BiFunction<? super K,? super V,? extends V> remappingFunction)…指定されたキーと現在マップされている値に対するマッピングの計算を試みる(現在のマッピングが存在しない場合はnull)。
* computeIfAbsent:default V computeIfAbsent(K key, Function<? super K,? extends V> mappingFunction)…指定されたキーがまだ値に関連付けられていない(またはnullにマップされている)場合、指定されたマッピング関数を使用してその値の計算を試行し、nullでない場合はそれをこのマップに入力する。
* computeIfPresent:default V computeIfPresent(K key, BiFunction<? super K,? super V,? extends V> remappingFunction)…指定されたキーの値が存在していてnull以外の場合、キーと現在マップされている値から新しいマッピングの計算を試みる。
* forEach:default void forEach(BiConsumer<? super K,? super V> action)…このマップのすべてのエントリの処理が完了するかアクションから例外がスローされるまで、各エントリに対して指定されたアクションを実行する。
* getOrDefault:default V getOrDefault(Object key, V defaultValue)…指定されたキーがマップされている値を返す。このマップにそのキーのマッピングが含まれていない場合はdefaultValueを返す。
* merge:default V merge(K key, V value, BiFunction<? super V,? super V,? extends V> remappingFunction)…指定されたキーがまだ値と関連付けられていないかnullと関連付けられている場合、指定されたnull以外の値に関連付ける。
* putIfAbsent:default V putIfAbsent(K key, V value)…指定されたキーがまだ値に関連付けられていない(または、nullにマップされている)場合は、それを指定された値に関連付けてnullを返す。それ以外の場合は、現在の値を返す。
* remove:default boolean remove(Object key, Object value)…指定された値に指定されたキーが現在マッピングされている場合にのみ、そのキーのエントリを削除する。
* replace:default V replace(K key, V value)…指定されたキーがなんらかの値に現在マッピングされている場合にのみ、そのキーのエントリを置換する。
* replace:default boolean replace(K key, V oldValue, V newValue)…指定されたキーが指定された値に現在マッピングされている場合にのみ、そのキーのエントリを置換する。
* replaceAll:default void replaceAll(BiFunction<? super K,? super V,? extends V> function)…すべてのエントリが処理されるか、または関数が例外をスローするまで、各エントリの値を、そのエントリで指定された関数を呼び出した結果で置換する。
[Map.Entry]
* comparingByKey:static <K extends Comparable<? super K>,V> Comparator<Map.Entry<K,V>> comparingByKey()…キーの自然順序でMap.Entryを比較するコンパレータを返す。
* comparingByKey:static <K,V> Comparator<Map.Entry<K,V>> comparingByKey(Comparator<? super K> cmp)…指定されたComparatorを使用してキーでMap.Entryを比較するコンパレータを返す。
* comparingByValue:static <K,V extends Comparable<? super V>> Comparator<Map.Entry<K,V>> comparingByValue()…値の自然順序でMap.Entryを比較するコンパレータを返す。
* comparingByValue:static <K,V> Comparator<Map.Entry<K,V>> comparingByValue(Comparator<? super V> cmp)…指定されたComparatorを使用して値でMap.Entryを比較するコンパレータを返す。
[Set]
* spliterator:default Spliterator<E> spliterator()…このセット内の要素に対するSpliteratorを作成する。
[SortedSet]
* spliterator:default Spliterator<E> spliterator()…このソートセット内の要素に対するSpliteratorを作成する。
[ArrayDeque]
* spliterator:public Spliterator<E> spliterator()…この両端キュー内の要素に対する遅延バインディングおよびフェイルファスト Spliteratorを作成する。
[ArrayList]
* spliterator:public Spliterator<E> spliterator()…このリスト内の要素に対する遅延バインディングおよびフェイルファスト Spliteratorを作成する。
[Arrays]
* parallelPrefix:public static void parallelPrefix(double[] array, DoubleBinaryOperator op)…指定された関数を使用して、指定された配列の各要素をその場で並列に累積する。
* parallelPrefix:public static void parallelPrefix(double[] array, int fromIndex, int toIndex, DoubleBinaryOperator op)…配列の指定された部分範囲に対してparallelPrefix(double[], DoubleBinaryOperator)を実行する。
* parallelPrefix:public static void parallelPrefix(int[] array, IntBinaryOperator op)…指定された関数を使用して、指定された配列の各要素をその場で並列に累積する。
* parallelPrefix:public static void parallelPrefix(int[] array, int fromIndex, int toIndex, IntBinaryOperator op)…配列の指定された部分範囲に対してparallelPrefix(int[], IntBinaryOperator)を実行する。
* parallelPrefix:public static void parallelPrefix(long[] array, int fromIndex, int toIndex, LongBinaryOperator op)…配列の指定された部分範囲に対してparallelPrefix(long[], LongBinaryOperator)を実行する。
* parallelPrefix:public static void parallelPrefix(long[] array, LongBinaryOperator op)…指定された関数を使用して、指定された配列の各要素をその場で並列に累積する。
* parallelPrefix:public static <T> void parallelPrefix(T[] array, BinaryOperator<T> op)…指定された関数を使用して、指定された配列の各要素をその場で並列に累積する。
* parallelPrefix:public static <T> void parallelPrefix(T[] array, int fromIndex, int toIndex, BinaryOperator<T> op)…配列の指定された部分範囲に対してparallelPrefix(Object[], BinaryOperator)を実行する。
* parallelSetAll:public static void parallelSetAll(double[] array, IntToDoubleFunction generator)…指定されたジェネレータ関数を使用して指定された配列の各要素を計算することで、すべての要素を並列に設定する。
* parallelSetAll:public static void parallelSetAll(int[] array, IntUnaryOperator generator)…指定されたジェネレータ関数を使用して指定された配列の各要素を計算することで、すべての要素を並列に設定する。
* parallelSetAll:public static void parallelSetAll(long[] array, IntToLongFunction generator)…指定されたジェネレータ関数を使用して指定された配列の各要素を計算することで、すべての要素を並列に設定する。
* parallelSetAll:public static <T> void parallelSetAll(T[] array, IntFunction<? extends T> generator)…指定されたジェネレータ関数を使用して指定された配列の各要素を計算することで、すべての要素を並列に設定する。
* parallelSort:public static void parallelSort(byte[] a)…指定された配列を数値の昇順でソートする。
* parallelSort:public static void parallelSort(byte[] a, int fromIndex, int toIndex)…配列の指定された範囲を数値の昇順でソートする。
* parallelSort:public static void parallelSort(char[] a)…指定された配列を数値の昇順でソートする。
* parallelSort:public static void parallelSort(char[] a, int fromIndex, int toIndex)…配列の指定された範囲を数値の昇順でソートする。
* parallelSort:public static void parallelSort(double[] a)…指定された配列を数値の昇順でソートする。
* parallelSort:public static void parallelSort(double[] a, int fromIndex, int toIndex)…配列の指定された範囲を数値の昇順でソートする。
* parallelSort:public static void parallelSort(float[] a)…指定された配列を数値の昇順でソートする。
* parallelSort:public static void parallelSort(float[] a, int fromIndex, int toIndex)…配列の指定された範囲を数値の昇順でソートする。
* parallelSort:public static void parallelSort(int[] a)…指定された配列を数値の昇順でソートする。
* parallelSort:public static void parallelSort(int[] a, int fromIndex, int toIndex)…配列の指定された範囲を数値の昇順でソートする。
* parallelSort:public static void parallelSort(long[] a)…指定された配列を数値の昇順でソートする。
* parallelSort:public static void parallelSort(long[] a, int fromIndex, int toIndex)…配列の指定された範囲を数値の昇順でソートする。
* parallelSort:public static void parallelSort(short[] a)…指定された配列を数値の昇順でソートする。
* parallelSort:public static void parallelSort(short[] a, int fromIndex, int toIndex)…配列の指定された範囲を数値の昇順でソートする。
* parallelSort:public static <T extends Comparable<? super T>> void parallelSort(T[] a)…指定されたオブジェクト配列を、その要素の自然順序付けに従って昇順にソートする。
* parallelSort:public static <T> void parallelSort(T[] a, Comparator<? super T> cmp)…指定されたコンパレータが示す順序に従って、指定されたオブジェクトの配列をソートする。
* parallelSort:public static <T extends Comparable<? super T>> void parallelSort(T[] a, int fromIndex, int toIndex)…指定されたオブジェクト配列の指定された範囲を、その要素の自然順序付けに従って昇順にソートする。
* parallelSort:public static <T> void parallelSort(T[] a, int fromIndex, int toIndex, Comparator<? super T> cmp)…指定されたコンパレータの順番に従って、指定されたオブジェクトの配列の指定範囲を昇順でソートする。
* setAll:public static void setAll(double[] array, IntToDoubleFunction generator)…指定されたジェネレータ関数を使用して指定された配列の各要素を計算することで、すべての要素を設定する。
* setAll:public static void setAll(int[] array, IntUnaryOperator generator)…指定されたジェネレータ関数を使用して指定された配列の各要素を計算することで、すべての要素を設定する。
* setAll:public static void setAll(long[] array, IntToLongFunction generator)…指定されたジェネレータ関数を使用して指定された配列の各要素を計算することで、すべての要素を設定する。
* setAll:public static <T> void setAll(T[] array, IntFunction<? extends T> generator)…指定されたジェネレータ関数を使用して指定された配列の各要素を計算することで、すべての要素を設定する。
* spliterator:public static Spliterator.OfDouble spliterator(double[] array)…指定された配列のすべてに適用されるSpliterator.OfDoubleを返す。
* spliterator:public static Spliterator.OfDouble spliterator(double[] array, int startInclusive, int endExclusive)…指定された配列の指定された範囲に適用されるSpliterator.OfDoubleを返す。
* spliterator:public static Spliterator.OfInt spliterator(int[] array)…指定された配列のすべてに適用されるSpliterator.OfIntを返す。
* spliterator:public static Spliterator.OfInt spliterator(int[] array, int startInclusive, int endExclusive)…指定された配列の指定された範囲に適用されるSpliterator.OfIntを返す。
* spliterator:public static Spliterator.OfLong spliterator(long[] array)…指定された配列のすべてに適用されるSpliterator.OfLongを返す。
* spliterator:public static Spliterator.OfLong spliterator(long[] array, int startInclusive, int endExclusive)…指定された配列の指定された範囲に適用されるSpliterator.OfLongを返す。
* spliterator:public static <T> Spliterator<T> spliterator(T[] array)…指定された配列のすべてに適用されるSpliteratorを返す。
* spliterator:public static <T> Spliterator<T> spliterator(T[] array, int startInclusive, int endExclusive)…指定された配列の指定された範囲に適用されるSpliteratorを返す。
* stream:public static DoubleStream stream(double[] array)…指定された配列をソースとして使用して、逐次的なDoubleStreamを返す。
* stream:public static DoubleStream stream(double[] array, int startInclusive, int endExclusive)…指定された配列の指定された範囲をソースとして使用して、逐次的なDoubleStreamを返す。
* stream:public static IntStream stream(int[] array)…指定された配列をソースとして使用して、逐次的なIntStreamを返す。
* stream:public static IntStream stream(int[] array, int startInclusive, int endExclusive)…指定された配列の指定された範囲をソースとして使用して、逐次的なIntStreamを返す。
* stream:public static LongStream stream(long[] array)…指定された配列をソースとして使用して、逐次的なLongStreamを返す。
* stream:public static LongStream stream(long[] array, int startInclusive, int endExclusive)…指定された配列の指定された範囲をソースとして使用して、逐次的なLongStreamを返す。
* stream:public static <T> Stream<T> stream(T[] array)…指定された配列をソースとして使用して、逐次的なStreamを返す。
* stream:public static <T> Stream<T> stream(T[] array, int startInclusive, int endExclusive)…指定された配列の指定された範囲をソースとして使用して、逐次的なStreamを返す。
[BitSet]
* stream:public IntStream stream()…このBitSetにビットが設定状態で保持されているインデックスのストリームを返す。
[Calendar]
* getAvailableCalendarTypes:public static Set<String> getAvailableCalendarTypes()…実行環境でCalendarによってサポートされるすべてのカレンダタイプを含む変更不可能なSetを返す。
* getCalendarType:public String getCalendarType()…このCalendarのカレンダタイプを返す。
* toInstant:public final Instant toInstant()…このオブジェクトをInstantに変換する。
[Collections]
* checkedNavigableMap:public static <K,V> NavigableMap<K,V> checkedNavigableMap(NavigableMap<K,V> m, Class<K> keyType, Class<V> valueType)…指定されたナビゲート可能マップの動的に型保証されたビューを返す。
* checkedNavigableSet:public static <E> NavigableSet<E> checkedNavigableSet(NavigableSet<E> s, Class<E> type)…指定されたナビゲート可能セットの動的に型保証されたビューを返す。
* checkedQueue:public static <E> Queue<E> checkedQueue(Queue<E> queue, Class<E> type)…指定されたキューの動的に型保証されたビューを返す。
* emptyNavigableMap:public static final <K,V> NavigableMap<K,V> emptyNavigableMap()…空のナビゲート可能マップ(不変)を返す。
* emptyNavigableSet:public static <E> NavigableSet<E> emptyNavigableSet()…空のナビゲート可能セット(不変)を返す。
* emptySortedMap:public static final <K,V> SortedMap<K,V> emptySortedMap()…空のソートマップ(不変)を返す。
* emptySortedSet:public static <E> SortedSet<E> emptySortedSet()…空のソートセット(不変)を返す。
* synchronizedNavigableMap:public static <K,V> NavigableMap<K,V> synchronizedNavigableMap(NavigableMap<K,V> m)…指定されたナビゲート可能マップに連動する同期(スレッドセーフな)ナビゲート可能マップを返す。
* synchronizedNavigableSet:public static <T> NavigableSet<T> synchronizedNavigableSet(NavigableSet<T> s)…指定されたナビゲート可能セットに連動する同期(スレッドセーフな)ナビゲート可能セットを返す。
* unmodifiableNavigableMap:public static <K,V> NavigableMap<K,V> unmodifiableNavigableMap(NavigableMap<K,? extends V> m)…指定されたナビゲート可能マップの変更不可能なビューを返す。
* unmodifiableNavigableSet:public static <T> NavigableSet<T> unmodifiableNavigableSet(NavigableSet<T> s)…指定されたナビゲート可能セットの変更不可能なビューを返す。
[Date]
* from:public static Date from(Instant instant)…InstantオブジェクトからDateのインスタンスを取得する。
* toInstant:public Instant toInstant()…このDateオブジェクトをInstantに変換する。
[GregorianCalendar]
* from:public static GregorianCalendar from(ZonedDateTime zdt)…ZonedDateTimeオブジェクトからデフォルトのロケールを使ってGregorianCalendarのインスタンスを取得する。
* getCalendarType:public String getCalendarType()…カレンダタイプとして"gregory"を返す。
* toZonedDateTime:public ZonedDateTime toZonedDateTime()…このオブジェクトを、時系列上でこのGregorianCalendarと同じ時点を表すZonedDateTimeに変換する。
[HashSet]
* spliterator:public Spliterator<E> spliterator()…このセット内の要素に対する遅延バインディングおよびフェイルファスト Spliteratorを作成する。
[LinkedHashSet]
* spliterator:public Spliterator<E> spliterator()…このセット内の要素に対する遅延バインディングおよびフェイルファスト Spliteratorを作成する。
[LinkedList]
* spliterator:public Spliterator<E> spliterator()…このリスト内の要素に対する遅延バインディングおよびフェイルファスト Spliteratorを作成する。
[Locale]
* filter:public static List<Locale> filter(List<Locale.LanguageRange> priorityList, Collection<Locale> locales)…RFC 4647に定義されているフィルタリングメカニズムを使用して、一致するLocaleインスタンスのリストを返す。
* filter:public static List<Locale> filter(List<Locale.LanguageRange> priorityList, Collection<Locale> locales, Locale.FilteringMode mode)…RFC 4647に定義されているフィルタリングメカニズムを使用して、一致するLocaleインスタンスのリストを返す。
* filterTags:public static List<String> filterTags(List<Locale.LanguageRange> priorityList, Collection<String> tags)…RFC 4647に定義されている基本フィルタリングメカニズムを使用して、一致する言語タグのリストを返す。
* filterTags:public static List<String> filterTags(List<Locale.LanguageRange> priorityList, Collection<String> tags, Locale.FilteringMode mode)…RFC 4647に定義されている基本フィルタリングメカニズムを使用して、一致する言語タグのリストを返す。
* hasExtensions:public boolean hasExtensions()…このLocaleが拡張を持つ場合、trueを返す。
* lookup:public static Locale lookup(List<Locale.LanguageRange> priorityList, Collection<Locale> locales)…RFC 4647で定義されている検索メカニズムを使用して、最も一致する言語タグのLocaleインスタンスを返す。
* lookupTag:public static String lookupTag(List<Locale.LanguageRange> priorityList, Collection<String> tags)…RFC 4647で定義されている検索メカニズムを使用して、最も一致する言語タグを返す。
* stripExtensions:public Locale stripExtensions()…このLocaleのコピーを、拡張を除いて返す。
[Objects]
* isNull:public static boolean isNull(Object obj)…指定された参照がnullの場合はtrueを返す。それ以外の場合はfalseを返す。
* nonNull:public static boolean nonNull(Object obj)…指定された参照がnull以外の場合はtrueを返す。それ以外の場合はfalseを返す。
* requireNonNull:public static <T> T requireNonNull(T obj, Supplier<String> messageSupplier)…指定されたオブジェクト参照がnullでないことを確認し、nullの場合はカスタマイズされたNullPointerExceptionをスローする。
[PriorityQueue]
* spliterator:public final Spliterator<E> spliterator()…このキュー内の要素に対する遅延バインディングおよびフェイルファスト Spliteratorを作成する。
[Random]
* doubles:public DoubleStream doubles()…0以上から1未満までの擬似乱数double値を含む、事実上無制限のストリームを返す。
* doubles:public DoubleStream doubles(double randomNumberOrigin, double randomNumberBound)…指定された起点(含む)と境界(含まない)に準拠した擬似乱数double値を含む、事実上無制限のストリームを返す。
* doubles:public DoubleStream doubles(long streamSize)…0以上から1未満までの擬似乱数double値を、指定されたstreamSize数だけ生成するストリームを返す。
* doubles:public DoubleStream doubles(long streamSize, double randomNumberOrigin, double randomNumberBound)…指定された起点(含む)と境界(含まない)に準拠した擬似乱数double値を、指定されたstreamSize数だけ生成するストリームを返す。
* ints:public IntStream ints()…擬似乱数int値を含む、事実上無制限のストリームを返す。
* ints:public IntStream ints(int randomNumberOrigin, int randomNumberBound)…指定された起点(含む)と境界(含まない)に準拠した擬似乱数int値を含む、事実上無制限のストリームを返す。
* ints:public IntStream ints(long streamSize)…擬似乱数int値を、指定されたstreamSize数だけ生成するストリームを返す。
* ints:public IntStream ints(long streamSize, int randomNumberOrigin, int randomNumberBound)…指定された起点(含む)と境界(含まない)に準拠した擬似乱数int値を、指定されたstreamSize数だけ生成するストリームを返す。
* longs:public LongStream longs()…擬似乱数long値を含む、事実上無制限のストリームを返す。
* longs:public LongStream longs(long streamSize)…擬似乱数long値を、指定されたstreamSize数だけ生成するストリームを返す。
* longs:public LongStream longs(long randomNumberOrigin, long randomNumberBound)…指定された起点(含む)と境界(含まない)に準拠した擬似乱数long値を含む、事実上無制限のストリームを返す。
* longs:public LongStream longs(long streamSize, long randomNumberOrigin, long randomNumberBound)…指定された起点(含む)と境界(含まない)に準拠した擬似乱数longを、指定されたstreamSize数だけ生成するストリームを返す。
[ResourceBundle]
* getBaseBundleName:public String getBaseBundleName()…既知の場合はこのバンドルのベース名を返す。不明の場合はnullを返す。
[TimeZone]
* getTimeZone:public static TimeZone getTimeZone(ZoneId zoneId)…指定されたzoneIdのTimeZoneを取得する。
* toZoneId:public ZoneId toZoneId()…このTimeZoneオブジェクトをZoneIdに変換する。
[TreeSet]
* spliterator:public Spliterator<E> spliterator()…このセット内の要素に対する遅延バインディングおよびフェイルファスト Spliteratorを作成する。
[Vector]
* spliterator:public Spliterator<E> spliterator()…このリスト内の要素に対する遅延バインディングおよびフェイルファスト Spliteratorを作成する。
{java.util.concurrent}
[ConcurrentMap]
* compute:default V compute(K key, BiFunction<? super K,? super V,? extends V> remappingFunction)…指定されたキーと現在マップされている値に対するマッピングの計算を試みます(現在のマッピングが存在しない場合はnull)。
* computeIfAbsent:default V computeIfAbsent(K key, Function<? super K,? extends V> mappingFunction)…指定されたキーがまだ値に関連付けられていない(またはnullにマップされている)場合、指定されたマッピング関数を使用してその値の計算を試行し、nullでない場合はそれをこのマップに入力する。
* computeIfPresent:default V computeIfPresent(K key, BiFunction<? super K,? super V,? extends V> remappingFunction)…指定されたキーの値が存在していてnull以外の場合、キーと現在マップされている値から新しいマッピングの計算を試みる。
* forEach:default void forEach(BiConsumer<? super K,? super V> action)…このマップのすべてのエントリの処理が完了するかアクションから例外がスローされるまで、各エントリに対して指定されたアクションを実行する。
* getOrDefault:default V getOrDefault(Object key, V defaultValue)…指定されたキーがマップされている値を返す。このマップにそのキーのマッピングが含まれていない場合はdefaultValueを返す。
* merge:default V merge(K key, V value, BiFunction<? super V,? super V,? extends V> remappingFunction)…指定されたキーがまだ値と関連付けられていないかnullと関連付けられている場合、指定されたnull以外の値に関連付ける。
* replaceAll:default void replaceAll(BiFunction<? super K,? super V,? extends V> function)…すべてのエントリが処理されるか、または関数が例外をスローするまで、各エントリの値を、そのエントリで指定された関数を呼び出した結果で置換する。
[ArrayBlockingQueue]
* spliterator:public Spliterator<E> spliterator()…このキュー内の要素に対するSpliteratorを返す。
[ConcurrentHashMap]
* forEach:public void forEach(long parallelismThreshold, BiConsumer<? super K,? super V> action)…各(key, value)に対して指定されたアクションを実行する。
* forEach:public <U> void forEach(long parallelismThreshold, BiFunction<? super K,? super V,? extends U> transformer, Consumer<? super U> action)…各(キー, 値)のnullでない各変換に対し、指定されたアクションを実行する。
* forEachEntry:public void forEachEntry(long parallelismThreshold, Consumer<? super Map.Entry<K,V>> action)…各エントリに対して指定されたアクションを実行する。
* forEachEntry:public <U> void forEachEntry(long parallelismThreshold, Function<Map.Entry<K,V>,? extends U> transformer, Consumer<? super U> action)…各エントリのnull以外の各変換に対して指定されたアクションを実行する。
* forEachKey:public void forEachKey(long parallelismThreshold, Consumer<? super K> action)…各キーに対して指定されたアクションを実行する。
* forEachKey:public <U> void forEachKey(long parallelismThreshold, Function<? super K,? extends U> transformer, Consumer<? super U> action)…各キーのnull以外の各変換に対して指定されたアクションを実行する。
* forEachValue:public void forEachValue(long parallelismThreshold, Consumer<? super V> action)…各値に対して指定されたアクションを実行する。
* forEachValue:public <U> void forEachValue(long parallelismThreshold, Function<? super V,? extends U> transformer, Consumer<? super U> action)…各値のnull以外の各変換に対して指定されたアクションを実行する。
* mappingCount:public long mappingCount()…マッピングの数を返す。
* newKeySet:public static <K> ConcurrentHashMap.KeySetView<K,Boolean> newKeySet()…指定された型からBoolean.TRUEへの、ConcurrentHashMapに連動する新しいSetを作成する。
* newKeySet:public static <K> ConcurrentHashMap.KeySetView<K,Boolean> newKeySet(int initialCapacity)…指定された型からBoolean.TRUEへの、ConcurrentHashMapに連動する新しいSetを作成する。
* reduce:public <U> U reduce(long parallelismThreshold, BiFunction<? super K,? super V,? extends U> transformer, BiFunction<? super U,? super U,? extends U> reducer)…指定されたリデューサを使用して値を結合することにより、すべての(キー、値)ペアの指定された変換の累積結果を返す。結果がない場合はnullを返す。
* reduceEntries:public Map.Entry<K,V> reduceEntries(long parallelismThreshold, BiFunction<Map.Entry<K,V>,Map.Entry<K,V>,? extends Map.Entry<K,V>> reducer)…指定されたリデューサを使用して値を結合することにより、すべてのエントリの累積結果を返す。結果がない場合はnullを返す。
* reduceEntries:public <U> U reduceEntries(long parallelismThreshold, Function<Map.Entry<K,V>,? extends U> transformer, BiFunction<? super U,? super U,? extends U> reducer)…指定されたリデューサを使用して値を結合することにより、すべてのエントリの指定された変換の累積結果を返す。結果がない場合はnullを返す。
* reduceEntriesToDouble:public double reduceEntriesToDouble(long parallelismThreshold, ToDoubleFunction<Map.Entry<K,V>> transformer, double basis, DoubleBinaryOperator reducer)…指定されたリデューサを使用して値を結合し、指定された基準を識別値として使用して、すべてのエントリの指定された変換の累積結果を返す。
* reduceEntriesToInt:public int reduceEntriesToInt(long parallelismThreshold, ToIntFunction<Map.Entry<K,V>> transformer, int basis, IntBinaryOperator reducer)…指定されたリデューサを使用して値を結合し、指定された基準を識別値として使用して、すべてのエントリの指定された変換の累積結果を返す。
* reduceEntriesToLong:public long reduceEntriesToLong(long parallelismThreshold, ToLongFunction<Map.Entry<K,V>> transformer, long basis, LongBinaryOperator reducer)…指定されたリデューサを使用して値を結合し、指定された基準を識別値として使用して、すべてのエントリの指定された変換の累積結果を返す。
* reduceKeys:public K reduceKeys(long parallelismThreshold, BiFunction<? super K,? super K,? extends K> reducer)…指定されたリデューサを使用して値を結合することにより、すべてのキーの累積結果を返す。結果がない場合はnullを返す。
* reduceKeys:public <U> U reduceKeys(long parallelismThreshold, Function<? super K,? extends U> transformer, BiFunction<? super U,? super U,? extends U> reducer)…指定されたリデューサを使用して値を結合することにより、すべてのキーの指定された変換の累積結果を返す。結果がない場合はnullを返す。
* reduceKeysToDouble:public double reduceKeysToDouble(long parallelismThreshold, ToDoubleFunction<? super K> transformer, double basis, DoubleBinaryOperator reducer)…指定されたリデューサを使用して値を結合し、指定された基準を識別値として使用して、すべてのキーの指定された変換の累積結果を返す。
* reduceKeysToInt:public int reduceKeysToInt(long parallelismThreshold, ToIntFunction<? super K> transformer, int basis, IntBinaryOperator reducer)…指定されたリデューサを使用して値を結合し、指定された基準を識別値として使用して、すべてのキーの指定された変換の累積結果を返す。
* reduceKeysToLong:public long reduceKeysToLong(long parallelismThreshold, ToLongFunction<? super K> transformer, long basis, LongBinaryOperator reducer)…指定されたリデューサを使用して値を結合し、指定された基準を識別値として使用して、すべてのキーの指定された変換の累積結果を返す。
* reduceToDouble:public double reduceToDouble(long parallelismThreshold, ToDoubleBiFunction<? super K,? super V> transformer, double basis, DoubleBinaryOperator reducer)…指定されたリデューサを使用して値を結合し、指定された基準を識別値として使用して、すべての(キー、値)ペアの指定された変換の累積結果を返す。
* reduceToInt:public int reduceToInt(long parallelismThreshold, ToIntBiFunction<? super K,? super V> transformer, int basis, IntBinaryOperator reducer)…指定されたリデューサを使用して値を結合し、指定された基準を識別値として使用して、すべての(キー、値)ペアの指定された変換の累積結果を返す。
* reduceToLong:public long reduceToLong(long parallelismThreshold, ToLongBiFunction<? super K,? super V> transformer, long basis, LongBinaryOperator reducer)…指定されたリデューサを使用して値を結合し、指定された基準を識別値として使用して、すべての(キー、値)ペアの指定された変換の累積結果を返す。
* reduceValues:public V reduceValues(long parallelismThreshold, BiFunction<? super V,? super V,? extends V> reducer)…指定されたリデューサを使用して値を結合することにより、すべての値の累積結果を返す。結果がない場合はnullを返す。
* reduceValues:public <U> U reduceValues(long parallelismThreshold, Function<? super V,? extends U> transformer, BiFunction<? super U,? super U,? extends U> reducer)…指定されたリデューサを使用して値を結合することにより、すべての値の指定された変換の累積結果を返す。結果がない場合はnullを返す。
* reduceValuesToDouble:public double reduceValuesToDouble(long parallelismThreshold, ToDoubleFunction<? super V> transformer, double basis, DoubleBinaryOperator reducer)…指定されたリデューサを使用して値を結合し、指定された基準を識別値として使用して、すべての値の指定された変換の累積結果を返す。
* reduceValuesToInt:public int reduceValuesToInt(long parallelismThreshold, ToIntFunction<? super V> transformer, int basis, IntBinaryOperator reducer)…指定されたリデューサを使用して値を結合し、指定された基準を識別値として使用して、すべての値の指定された変換の累積結果を返す。
* reduceValuesToLong:public long reduceValuesToLong(long parallelismThreshold, ToLongFunction<? super V> transformer, long basis, LongBinaryOperator reducer)…指定されたリデューサを使用して値を結合し、指定された基準を識別値として使用して、すべての値の指定された変換の累積結果を返す。
* search:public <U> U search(long parallelismThreshold, BiFunction<? super K,? super V,? extends U> searchFunction)…指定された検索関数を各(キー、値)に適用し、nullでない結果を返す。存在しない場合はnullを返す。
* searchEntries:public <U> U searchEntries(long parallelismThreshold, Function<Map.Entry<K,V>,? extends U> searchFunction)…各エントリに指定された検索関数を適用したnull以外の結果を返す。結果がない場合はnullを返す。
* searchKeys:public <U> U searchKeys(long parallelismThreshold, Function<? super K,? extends U> searchFunction)…各キーに指定された検索関数を適用したnull以外の結果を返す。結果がない場合はnullを返す。
* searchValues:public <U> U searchValues(long parallelismThreshold, Function<? super V,? extends U> searchFunction)…各値に指定された検索関数を適用したnull以外の結果を返す。結果がない場合はnullを返す。
[ConcurrentLinkedDeque]
* spliterator:public Spliterator<E> spliterator()…この両端キュー内の要素に対するSpliteratorを返す。
[ConcurrentLinkedQueue]
* spliterator:public Spliterator<E> spliterator()…このキュー内の要素に対するSpliteratorを返す。
[ConcurrentSkipListMap]
* compute:public V compute(K key, BiFunction<? super K,? super V,? extends V> remappingFunction)…指定されたキーと現在マップされている値に対するマッピングの計算を試みる(現在のマッピングが存在しない場合はnull)。
* computeIfAbsent:public V computeIfAbsent(K key, Function<? super K,? extends V> mappingFunction)…指定されたキーがまだ値に関連付けられていない場合、指定されたマッピング関数を使用してその値の計算を試行し、nullでない場合はそれをこのマップに入力する。
* computeIfPresent:public V computeIfPresent(K key, BiFunction<? super K,? super V,? extends V> remappingFunction)…指定されたキーの値が存在する場合、キーと現在マップされている値から新しいマッピングの計算を試みる。
* getOrDefault:public V getOrDefault(Object key, V defaultValue)…指定されたキーがマップされる値を返す。このマップにそのキーのマッピングが含まれていない場合は、指定されたdefaultValueを返す。
* merge:public V merge(K key, V value, BiFunction<? super V,? super V,? extends V> remappingFunction)…指定されたキーがまだ値と関連付けられていない場合は、指定された値に関連付ける。
[ConcurrentSkipListSet]
* spliterator:public Spliterator<E> spliterator()…このセット内の要素に対するSpliteratorを返す。
[CopyOnWriteArrayList]
* spliterator:public Spliterator<E> spliterator()…このリスト内の要素に対するSpliteratorを返す。
[CopyOnWriteArraySet]
* spliterator:public Spliterator<E> spliterator()…このセット内の要素に対するSpliteratorを、これらの要素が追加された順序で返す。
[Executors]
* newWorkStealingPool:public static ExecutorService newWorkStealingPool()…すべての使用可能なプロセッサをターゲット並列性レベルとして使用して、work-stealingスレッドプールを作成する。
* newWorkStealingPool:public static ExecutorService newWorkStealingPool(int parallelism)…指定された並列性レベルをサポートするのに十分な数のスレッドを保持するスレッドプールを作成し、場合によっては競合を減らすために複数のキューを使用する。
[ForkJoinPool]
* commonPool:public static ForkJoinPool commonPool()…共通プールインスタンスを返す。
* getCommonPoolParallelism:public static int getCommonPoolParallelism()…共通プールのターゲット並列性レベルを返す。
[ForkJoinTask]
* compareAndSetForkJoinTaskTag:public final boolean compareAndSetForkJoinTaskTag(short e, short tag)…このタスクのタグ値を原子的に条件付きで設定する。
* getForkJoinTaskTag:public final short getForkJoinTaskTag()…このタスクのタグを返す。
* quietlyComplete:public final void quietlyComplete()…値を設定せずにこのタスクを正常に完了する。
* setForkJoinTaskTag:public final short setForkJoinTaskTag(short tag)…このタスクのタグ値を原子的に設定する。
[LinkedBlockingDeque]
* spliterator:public Spliterator<E> spliterator()…この両端キュー内の要素に対するSpliteratorを返す。
[LinkedBlockingQueue]
* spliterator:public Spliterator<E> spliterator()…このキュー内の要素に対するSpliteratorを返す。
[LinkedTransferQueue]
* spliterator:public Spliterator<E> spliterator()…このキュー内の要素に対するSpliteratorを返す。
[PriorityBlockingQueue]
* spliterator:public Spliterator<E> spliterator()…このキュー内の要素に対するSpliteratorを返す。
[SynchronousQueue]
* spliterator:public Spliterator<E> spliterator()…Spliterator.trySplit()を呼び出すと常にnullが返される、空のスプリッテレータを返す。
[ThreadLocalRandom]
* doubles:public DoubleStream doubles()…0以上から1未満までの擬似乱数double値を含む事実上無限のストリームを返す。
* doubles:public DoubleStream doubles(double randomNumberOrigin, double randomNumberBound)…指定された起点(含む)と境界(含まない)に準拠した擬似乱数double値を含む事実上無限のストリームを返す。
* doubles:public DoubleStream doubles(long streamSize)…0以上から1未満までの擬似乱数double値を、streamSizeに指定された数だけ生成するストリームを返す。
* doubles:public DoubleStream doubles(long streamSize, double randomNumberOrigin, double randomNumberBound)…指定された起点(含む)と境界(含まない)に準拠した擬似乱数double値を、streamSizeに指定された数だけ生成するストリームを返す。
* ints:public IntStream ints()…擬似乱数int値を含む事実上無限のストリームを返す。
* ints:public IntStream ints(int randomNumberOrigin, int randomNumberBound)…指定された起点(含む)と境界(含まない)に準拠した擬似乱数int値を含む、事実上無限のストリームを返す。
* ints:public IntStream ints(long streamSize)…擬似乱数int値をstreamSizeに指定された数だけ生成するストリームを返す。
* ints:public IntStream ints(long streamSize, int randomNumberOrigin, int randomNumberBound)…指定された起点(含む)と境界(含まない)に準拠した擬似乱数int値をstreamSizeに指定された数だけ生成するストリームを返す。
* longs:public LongStream longs()…擬似乱数long値を含む事実上無限のストリームを返す。
* longs:public LongStream longs(long streamSize)…擬似乱数long値をstreamSizeに指定された数だけ生成するストリームを返す。
* longs:public LongStream longs(long randomNumberOrigin, long randomNumberBound)…指定された起点(含む)と境界(含まない)に準拠した擬似乱数long値を含む、事実上無限のストリームを返す。
* longs:public LongStream longs(long streamSize, long randomNumberOrigin, long randomNumberBound)…指定された起点(含む)と境界(含まない)に準拠した擬似乱数longをstreamSizeに指定された数だけ生成するストリームを返す。
{java.util.concurrent.atomic}
このパッケージ"ava.util.concurrent.atomic"は、単一の変数に対するロックフリーでスレッドセーブなプログラミングをサポートするクラスの、小規模なツールキットである。(なお、"atomic(原子的)"は、「微小な」という意味合いを含んでいる)。
[AtomicInteger]
* accumulateAndGet:public final int accumulateAndGet(int x, IntBinaryOperator accumulatorFunction)…現在の値を、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、更新された値を返す。
* getAndAccumulate:public final int getAndAccumulate(int x, IntBinaryOperator accumulatorFunction)…現在の値を、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、前の値を返す。
* getAndUpdate:public final int getAndUpdate(IntUnaryOperator updateFunction)…現在の値を、指定された関数を適用した結果で原子的に更新し、前の値を返す。
* updateAndGet:public final int updateAndGet(IntUnaryOperator updateFunction)…現在の値を、指定された関数を適用した結果で原子的に更新し、更新された値を返す。
[AtomicIntegerArray]
* accumulateAndGet:public final int accumulateAndGet(int i, int x, IntBinaryOperator accumulatorFunction)…インデックスiにある要素を、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、更新された値を返す。
* getAndAccumulate:public final int getAndAccumulate(int i, int x, IntBinaryOperator accumulatorFunction)…インデックスiにある要素を、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、前の値を返す。
* getAndUpdate:public final int getAndUpdate(int i, IntUnaryOperator updateFunction)…インデックスiにある要素を、指定された関数を適用した結果で原子的に更新し、前の値を返す。
* updateAndGet:public final int updateAndGet(int i, IntUnaryOperator updateFunction)…インデックスiにある要素を、指定された関数を適用した結果で原子的に更新し、更新された値を返す。
[AtomicIntegerFieldUpdater]
* accumulateAndGet:public final int accumulateAndGet(T obj, int x, IntBinaryOperator accumulatorFunction)…このアップデータが管理する指定されたオブジェクトのフィールドを、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、更新された値を返す。
* getAndAccumulate:public final int getAndAccumulate(T obj, int x, IntBinaryOperator accumulatorFunction)…このアップデータが管理する指定されたオブジェクトのフィールドを、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、前の値を返す。
* getAndUpdate:public final int getAndUpdate(T obj, IntUnaryOperator updateFunction)…このアップデータが管理する指定されたオブジェクトのフィールドを、指定された関数を適用した結果で原子的に更新し、前の値を返す。
* updateAndGet:public final int updateAndGet(T obj, IntUnaryOperator updateFunction)…このアップデータが管理する指定されたオブジェクトのフィールドを、指定された関数を適用した結果で原子的に更新し、更新された値を返す。
[AtomicLong]
* accumulateAndGet:public final long accumulateAndGet(long x, LongBinaryOperator accumulatorFunction)…現在の値を、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、更新された値を返す。
* getAndAccumulate:public final long getAndAccumulate(long x, LongBinaryOperator accumulatorFunction)…現在の値を、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、前の値を返す。
* getAndUpdate:public final long getAndUpdate(LongUnaryOperator updateFunction)…現在の値を、指定された関数を適用した結果で原子的に更新し、前の値を返す。
* updateAndGet:public final long updateAndGet(LongUnaryOperator updateFunction)…現在の値を、指定された関数を適用した結果で原子的に更新し、更新された値を返す。
[AtomicLongArray]
* accumulateAndGet:public final long accumulateAndGet(int i, long x, LongBinaryOperator accumulatorFunction)…インデックスiにある要素を、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、更新された値を返す。
* getAndAccumulate:public final long getAndAccumulate(int i, long x, LongBinaryOperator accumulatorFunction)…インデックスiにある要素を、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、前の値を返す。
* getAndUpdate:public final long getAndUpdate(int i, LongUnaryOperator updateFunction)…インデックスiにある要素を、指定された関数を適用した結果で原子的に更新し、前の値を返す。
* updateAndGet:public final long updateAndGet(int i, LongUnaryOperator updateFunction)…インデックスiにある要素を、指定された関数を適用した結果で原子的に更新し、更新された値を返す。
[AtomicLongFieldUpdater]
* accumulateAndGet:public final long accumulateAndGet(T obj, long x, LongBinaryOperator accumulatorFunction)…このアップデータが管理する指定されたオブジェクトのフィールドを、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、更新された値を返す。
* getAndAccumulate:public final long getAndAccumulate(T obj, long x, LongBinaryOperator accumulatorFunction)…このアップデータが管理する指定されたオブジェクトのフィールドを、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、前の値を返す。
* getAndUpdate:public final long getAndUpdate(T obj, LongUnaryOperator updateFunction)…このアップデータが管理する指定されたオブジェクトのフィールドを、指定された関数を適用した結果で原子的に更新し、前の値を返す。
* updateAndGet:public final long updateAndGet(T obj, LongUnaryOperator updateFunction)…このアップデータが管理する指定されたオブジェクトのフィールドを、指定された関数を適用した結果で原子的に更新し、更新された値を返す。
[AtomicReference]
* accumulateAndGet:public final V accumulateAndGet(V x, BinaryOperator<V> accumulatorFunction)…現在の値を、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、更新された値を返す。
* getAndAccumulate:public final V getAndAccumulate(V x, BinaryOperator<V> accumulatorFunction)…現在の値を、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、前の値を返す。
* getAndUpdate:public final V getAndUpdate(UnaryOperator<V> updateFunction)…現在の値を、指定された関数を適用した結果で原子的に更新し、前の値を返す。
* updateAndGet:public final V updateAndGet(UnaryOperator<V> updateFunction)…現在の値を、指定された関数を適用した結果で原子的に更新し、更新された値を返す。
[AtomicReferenceArray]
* accumulateAndGet:public final E accumulateAndGet(int i, E x, BinaryOperator<E> accumulatorFunction)…インデックスiにある要素を、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、更新された値を返す。
* getAndAccumulate:public final E getAndAccumulate(int i, E x, BinaryOperator<E> accumulatorFunction)…インデックスiにある要素を、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、前の値を返す。
* getAndUpdate:public final E getAndUpdate(int i, UnaryOperator<E> updateFunction)…インデックスiにある要素を、指定された関数を適用した結果で原子的に更新し、前の値を返す。
* updateAndGet:public final E updateAndGet(int i, UnaryOperator<E> updateFunction)…インデックスiにある要素を、指定された関数を適用した結果で原子的に更新し、更新された値を返す。
[AtomicReferenceFieldUpdater]
* accumulateAndGet:public final V accumulateAndGet(T obj, V x, BinaryOperator<V> accumulatorFunction)…このアップデータが管理する指定されたオブジェクトのフィールドを、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、更新された値を返す。
* getAndAccumulate:public final V getAndAccumulate(T obj, V x, BinaryOperator<V> accumulatorFunction)…このアップデータが管理する指定されたオブジェクトのフィールドを、指定された関数を現在の値と指定された値に適用した結果で原子的に更新し、前の値を返す。
* getAndUpdate:public final V getAndUpdate(T obj, UnaryOperator<V> updateFunction)…このアップデータが管理する指定されたオブジェクトのフィールドを、指定された関数を適用した結果で原子的に更新し、前の値を返す。
* updateAndGet:public final V updateAndGet(T obj, UnaryOperator<V> updateFunction)…このアップデータが管理する指定されたオブジェクトのフィールドを、指定された関数を適用した結果で原子的に更新し、更新された値を返す。
{java.util.logging}
[Logger]
* config:public void config(Supplier<String> msgSupplier)…メッセージが実際にログに記録されるロギングレベルである場合にのみ構築される、CONFIGメッセージのログを記録する。
* fine:public void fine(Supplier<String> msgSupplier)…メッセージが実際にログに記録されるロギングレベルである場合にのみ構築される、FINEメッセージのログを記録する。
* finer:public void finer(Supplier<String> msgSupplier)…メッセージが実際にログに記録されるロギングレベルである場合にのみ構築される、FINERメッセージのログを記録する。
* finest:public void finest(Supplier<String> msgSupplier)…メッセージが実際にログに記録されるロギングレベルである場合にのみ構築される、FINESTメッセージのログを記録する。
* information:public void info(Supplier<String> msgSupplier)…メッセージが実際にログに記録されるロギングレベルである場合にのみ構築される、INFOメッセージのログを記録する。
* log:public void log(Level level, Throwable thrown, Supplier<String> msgSupplier)…関連するThrowable情報を含む、遅延構築されたメッセージのログを記録する。
* logp:public void logp(Level level, String sourceClass, String sourceMethod, Supplier<String> msgSupplier)…ソースクラスとメソッドを指定する、引数のない遅延構築されたメッセージのログを記録する。
* logp:public void logp(Level level, String sourceClass, String sourceMethod, Throwable thrown, Supplier<String> msgSupplier)…ソースクラスとメソッドを指定し、関連するThrowable情報を含む遅延構築されたメッセージのログを記録する。
* logrb:public void logrb(Level level, String sourceClass, String sourceMethod, ResourceBundle bundle, String msg, Object... params)…ソースクラス、メソッド、およびリソースバンドルを指定し、メッセージパラメータのオプションのリストを含むメッセージのログを記録する。
* logrb:public void logrb(Level level, String sourceClass, String sourceMethod, ResourceBundle bundle, String msg, Throwable thrown)…ソースクラス、メソッド、およびリソースバンドルを指定し、関連するThrowable情報を含むメッセージのログを記録する。
* setResourceBundle:public void setResourceBundle(ResourceBundle bundle)…このロガーのリソースバンドルを設定する。
* severe:public void severe(Supplier<String> msgSupplier)…メッセージが実際にログに記録されるロギングレベルである場合にのみ構築される、SEVEREメッセージのログを記録する。
* warning:public void warning(Supplier<String> msgSupplier)…メッセージが実際にログに記録されるロギングレベルである場合にのみ構築される、WARNINGメッセージのログを記録する。
{java.util.regex}
[Matcher]
* end:public int end(String name)…前回のマッチ操作で、指定された名前付きの前方参照を行う正規表現グループによって前方参照された部分シーケンスの、最後の文字の後のオフセットを返す。
* start:public int start(String name)…前回のマッチ操作で指定された名前付き前方参照グループによって前方参照された部分シーケンスの開始インデックスを返す。
[Pattern]
* asPredicate:public Predicate<String> asPredicate()…文字列とマッチするために使用できるプレディケートを作成する。
* splitAsStream:public Stream<String> splitAsStream(CharSequence input)…このパターンのマッチに基づいて、指定された入力シーケンスからストリームを作成する。
{java.util.spi}
[LocaleServiceProvider]
* isSupportedLocale:public boolean isSupportedLocale(Locale locale)…指定されたlocaleがこのロケールサービスプロバイダでサポートされる場合はtrueを返す。
[TimeZoneNameProvider]
* getGenericDisplayName:public String getGenericDisplayName(String ID, int style, Locale locale)…指定されたタイムゾーンIDのジェネリック名を、指定されたlocaleのユーザへの表示に適した形式で返す。
{java.util.zip}
[Adler32]
* update:public void update(ByteBuffer buffer)…チェックサムを指定されたバッファからのバイト数で更新する。
[CRC32]
* update:public void update(ByteBuffer buffer)…チェックサムを指定されたバッファからのバイト数で更新する。
[ZipEntry]
* getCreationTime:public FileTime getCreationTime()…エントリの作成時間を返す。
* getLastAccessTime:public FileTime getLastAccessTime()…エントリの最終アクセス時間を返す。
* getLastModifiedTime:public FileTime getLastModifiedTime()…エントリの最終変更時間を返す。
* setCreationTime:public ZipEntry setCreationTime(FileTime time)…エントリの作成時間を設定する。
* setLastAccessTime:public ZipEntry setLastAccessTime(FileTime time)…エントリの最終アクセス時間を設定する。
* setLastModifiedTime:public ZipEntry setLastModifiedTime(FileTime time)…エントリの最終変更時間を設定する。
[ZipFile]
* stream:public Stream<? extends ZipEntry> stream()…ZIPファイルのエントリに対する順序付けされたStreamを返す。
{javax.crypto.spec}
[PBEParameterSpec]
* getParameterSpec:public AlgorithmParameterSpec getParameterSpec()…暗号アルゴリズムのパラメータ仕様を返す。
{javax.lang.model.element}
[ExecutableElement]
* getReceiverType:TypeMirror getReceiverType()…この実行可能ファイルのレシーバの型を返す。実行可能ファイルにレシーバの型がない場合は、種類NONEを持つNoTypeを返す。
* isDefault:boolean isDefault()…このメソッドがデフォルトメソッドである場合はtrueを返し、そうでない場合はfalseを返す。
{javax.lang.model.type}
[ExecutableType]
* getReceiverType:TypeMirror getReceiverType()…この実行可能ファイルのレシーバの型を返す。実行可能ファイルにレシーバの型がない場合は、種類NONEを持つNoTypeを返す。
[TypeVisitor]
* visitIntersection:R visitIntersection(IntersectionType t, P p)…共通部分型をビジットする。
{javax.lang.model.util}
[Elements]
* isFunctionalInterface:boolean isFunctionalInterface(TypeElement type)…この型要素が関数型インタフェースである場合はtrueを返し、そうでない場合はfalseを返す。
[AbstractTypeVisitor6]
* visitIntersection:public R visitIntersection(IntersectionType t, P p)…visitUnknownを呼び出すことでIntersectionType要素をビジットする。
{javax.net.ssl}
[ExtendedSSLSession]
* getRequestedServerNames:public List<SNIServerName> getRequestedServerNames()…要求されたServer Name Indication (SNI)拡張のすべてのSNIServerNameを含むListを取得する。
[SSLParameters]
* getServerNames:public final List<SNIServerName> getServerNames()…Server Name Indication (SNI)パラメータのすべてのSNIServerNameを含むList(何も設定されていない場合はnull)を返す。
* getSNIMatchers:public final Collection<SNIMatcher> getSNIMatchers()…Server Name Indication (SNI)パラメータのすべてのSNIMatcherを含むCollection(何も設定されていない場合はnull)を返す。
* getUseCipherSuitesOrder:public final boolean getUseCipherSuitesOrder()…暗号化方式群のローカル設定を適用する必要があるかどうかを返す。
* setServerNames:public final void setServerNames(List<SNIServerName> serverNames)…Server Name Indication (SNI)パラメータの必要なSNIServerNameを設定する。
* setSNIMatchers:public final void setSNIMatchers(Collection<SNIMatcher> matchers)…Server Name Indication (SNI)パラメータのSNIMatcherを設定する。
* setUseCipherSuitesOrder:public final void setUseCipherSuitesOrder(boolean honorOrder)…暗号化方式群のローカル設定を適用する必要があるかどうかを設定する。
[SSLSocketFactory]
* createSocket:public Socket createSocket(Socket s, InputStream consumed, boolean autoClose) throws IOException…既存の接続済ソケットの上位サーバーモードSocketで、そのSocketのベースとなるInputStreamからすでに使用/削除されたデータを読み取れるものを作成する。
{javax.security.auth.kerberos}
[KeyTab]
* getInstance:public static KeyTab getInstance(KerberosPrincipal princ)…指定されたサービス主体にバインドされたデフォルトのKeyTabインスタンスを返す。
* getInstance:public static KeyTab getInstance(KerberosPrincipal princ, File file)…指定されたサービス主体にバインドされたFileオブジェクトからKeyTabインスタンスを返す。
* getPrincipal:public KerberosPrincipal getPrincipal()…このKeyTabオブジェクトがバインドされているサービス主体を返す。
* getUnboundInstance:public static KeyTab getUnboundInstance()…バインドされていないデフォルトのKeyTabインスタンスを返す。
* getUnboundInstance:public static KeyTab getUnboundInstance(File file)…Fileオブジェクトから、バインドされていないKeyTabインスタンスを返す。
* isBound:public boolean isBound()…キータブが主体にバインドされているかどうかを返す。
上記で例示したクラス群を含めて、Javaクラスライブラリは豊富なクラスファイルを含んでいる。このJavaクラスライブラリに含まれる種々なクラスのメソッドまたは関数を適宜組み合わせることで、例えば、図22のStep101〜Step105、図26AのStep109〜Step119、図26BのStep120〜Step130、図29のStep141〜Step143、図30のStep129〜Step158で示したStep各々の処理を実現できる。すなわち、図22などで例示したStepの組合せに対応するプログラムはJava言語で記述できる(JavaScriptその他のプログラミング言語で記述することも可能)。Java言語で記述したプログラム(元はJavaのソースコード)から生成したJavaバイトコードは、GWTなどを用いて、対応するWebアプリまたは対応するJavaScriptに変換できる。また、JavaScript Native Interface(JSNI)などを用いて、JavaScriptのコードとJavaのソースコードを組み合わせることもできる。そうすると、Javaのソースコードに適宜JavaScriptを書き込むことにより、そのソースコードに対応したWebアプリの機能拡張や処理内容の変更といったことが可能になる。
<セキュリティについて>
*各フォグサーバとクラウドサーバ間のインターネット通信におけるセキュリティの一例(公開鍵方式を利用)
HTML5には、フォーム機能強化のため、ユーザが操作できる以下の要素が追加されている:
「処理の進行状況を表すprogress要素」、
「規定範囲の測定結果を表すmeter要素」、
「操作メニューの各コマンドを指定するcommand要素」、
「追加で得ることのできる詳細情報を示すdetails要素」、
「details要素の内容の要約を示すsummary要素」、
「フォーム送信時に秘密鍵と公開鍵を発行するkeygen要素」、
「計算結果を示すoutput要素」。
クラウドサーバ(例えば図2の1116−nまたは図43Bの6200)は、自身を特定するユニークな識別コードID01(公開情報)を持っているものとする。(クラウドサーバのURLをID01として利用してもよい。)識別コードID01(全部またはその一部)を利用して、クラウドサーバ用の公開鍵を作成できる。
フォグサーバ(例えば図2の1126または図43Bの6300)も、自身を特定するユニークな識別コードID02(公開可能な情報)を持っているものとする。(フォグサーバのURLまたはそのフォグサーバの管理者のemailアドレスをID02として利用してもよい。)フォグサーバはさらに、フォグサーバ毎に異なるユニークな秘密鍵(非公開情報)を持っている。
フォグサーバの識別コードID02と秘密鍵は、クラウドサーバに事前登録される。どのフォグサーバも、クラウドサーバ用の公開鍵で暗号化した情報をクラウドサーバへインターネット経由で送れる。クラウドサーバは、情報送付元のフォグサーバのID02に基づいて事前登録された秘密鍵を取り出し、送られてきた情報を復号できる。
クラウドサーバは、自己の公開鍵で暗号化した情報を、特定のフォグサーバ(ID02)へインターネット経由で送ることができる。特定のフォグサーバは、自己の秘密鍵を用いて、送られてきた情報を復号できる。
*各ユニットとフォグサーバ間の中〜短距離通信(ミドルウエア)におけるセキュリティの一例(公開鍵方式を利用)
フォグサーバ(例えば図2の1126または図43Bの6300)は、自身を特定するユニークな識別コードID02(公開情報)を持っているものとする。フォグサーバがインターネット上にあるときは、フォグサーバのURLをID02として利用してもよい。識別コードID02(全部またはその一部)を利用して、公開鍵を作成できる。
各ユニット(例えば図2の1290−4または図43Bの6610)は、自身を特定するユニークな識別コードID03(公開可能な情報)を持っているものとする。識別コードID03をそのユニットの論理アドレスに利用してもよい。
各ユニットのデバイスコントローラ(またはメモリ)内には、そのコントローラ独自のユニークな識別コードID04(非公開情報)が記録されているものとする。例えば個々のコントローラLSIの製造番号(シリアルナンバー)の一部または全部を識別コードID04の作成に利用できる。識別コードID04(全部またはその一部)を利用して秘密鍵を作成できる。
各ユニットのデバイス(センサまたはアクチエータ)は自身を特定するユニークな識別コードID05(非公開情報)を持っているものとする。個々のデバイスの製造番号(シリアルナンバー)等を用いて識別コードID05を作成できる。識別コードID05(全部またはその一部)も秘密鍵の作成に利用できる。
フォグサーバには、予め各ユニットの識別コード(ID03)とそのユニットに属する秘密鍵(ID04および/またはID05)が事前登録される。各ユニットがフォグサーバにアクセスする際はフォグサーバの識別コードID02(公開情報)を利用できる。フォグサーバが各ユニットにアクセスする際は、各ユニットの識別コードID03を利用できる。
ユニットがフォグサーバへ(中〜短距離無線通信で)情報提供する場合は、公開鍵(ID02)を用いて提供情報を暗号化するとともに、その復号化には秘密鍵(ID04および/またはID05)が必要となるようにして、第3者による提供情報の解読を阻止する。
具体的には、ユニットがフォグサーバへ情報を暗号化して送るときはID02を利用した公開鍵で暗号化する。どのユニットも、目的のフォグサーバへ、公開鍵で暗号化した情報を送ることができる。送られた暗号化情報は、公開鍵では復号できない。しかし、目的のフォグサーバは、事前登録された非公開の秘密鍵(ID04および/またはID05)を用いて、ユニットから送られてきた暗号化情報を復号できる。
*フォグサーバから特定のユニットへ秘密情報を送るときは、フォグサーバは特定ユニットに秘密鍵を事前登録しておく(公開可能なID2は秘密鍵に使わず、秘密鍵は別に用意する)。そして、公開鍵方式で暗号化された情報を、フォグサーバから特定のユニットへ送る。特定ユニットは、事前登録された秘密鍵を用いて、送られてきた暗号化情報を復号できる。
なお、Java8のクラスライブラリには、"X509Certificate"というクラスを含むセキュリティ系のパッケージ(java.security.cert)がある。例えばこの"X509Certificate"を用いて、「指定された公開鍵に対応する非公開鍵(秘密鍵)を使って証明書が署名されたことを検証する」プログラムを作成できる。
フォグサーバは、秘密を要しない情報については、暗号化せずに通信できる。この場合、暗号化/復号化のプロセスがない分、通信時間を短縮できる。
*各ユニットとデバイス間の極短距離通信(ミドルウエア)におけるセキュリティの一例(公開鍵方式以外を利用)
ユニットのデバイスコントローラとそこにUPnPで接続された1以上のデバイス(センサやアクチエータ)との間の短距離通信(例えば、有効通達距離が10m以内のClass2 Bluetoothまたは、有効通達距離が1m以内のClass2 Bluetooth)は、第3者に傍受される危険性が比較的小さいと考えられる。そこで、そのような短距離通信では、セキュリティの強固さよりも通信速度を重視することも考えられる(暗号化/復号化の処理に時間をかけない)。具体的には、非公開情報(ID04またはID05)の一部を利用したパスコードを通信パケットのヘッダの一部に記載するだけとし、正しいパスコードを含むヘッダを持つパケット群だけで、情報漏洩を防ぎたい情報の通信を行う。このような比較的簡単な方法で、第3者への情報漏洩の可能性を下げることができる。
パスコードとしては、例えば、"0"と"1"が混在するユニークなNビットパターン+非公開情報(ID04またはID05)の末尾Mビットを集めた合計N+Mビットのパスコード(オールゼロにもオール1にもならないビットコード)を生成する。このパスコードは通信開始前に予め通信元から通信先へ(適宜スクランブルして)届けられているとする(このパスコードは個々の通信が行われる都度、変更できる)。通信先は、通信元から送られてきたパケット群のビットストリームから、パスコードにマッチするヘッダを持ったパケットだけを抽出して、必要な情報(情報漏洩を防ぎたい情報)を受け取る。ここで抽出されなかったパケット群は、秘密を要しない情報の転送に利用できる。
各デバイスコントローラと、そこにUPnPで接続される1以上のデバイスとの間の通信が有線による専用回線により行なわれるときは、その専用回線から第3者への不測の情報漏洩はないものとする。その場合は上記パケットヘッダのパスコードはオールゼロ(またはオール1)とし、セキュリティチェックのプロセスをスキップすることができる。
デバイスコントローラを内蔵するユニットにデバイスが物理的に直結され、デバイスコントローラへ該デバイスがUPnPで論理的に自動接続されるようになっているときも、その接続部分から第3者へ情報漏洩する恐れは殆どないものとする。この場合も、上記パケットヘッダにパスコードを設けなくてよい(または、パスコードをオールゼロまたはオール1としてセキュリティチェックを無効にする)。
<出願当初請求項の内容と実施形態との対応関係例>
[1]<情報機器(スマートフォン、タブレット、PC、デジタルTVなど)>
一実施形態では、センサおよび/またはアクチエータを備えたユニット(IoT機器)が1以上存在するネットワークで用いられる情報機器(スマートフォンなど)が、前記1以上のユニットのいずれかに接続可能に構成される。前記情報機器は、接続された前記ユニットのセンサおよび/またはアクチエータを制御する1以上のコンピュータプログラム(ジャバスクリプト、ジャバなど)を用いるように構成される。前記ユニットのセンサおよび/またはアクチエータの制御に使えるメソッドを記述したクラスを1以上含むライブラリ(標準ライブラリ/ユーザ定義ライブラリ)から取り出した1以上のクラスの組み合わせ(UD_PGC)により、前記1以上のコンピュータプログラムが生成される。前記情報機器は、前記生成された1以上のコンピュータプログラムにより、前記ユニットのセンサおよび/またはアクチエータを制御するように構成される。
[2]<情報通信端末(スマートフォン、タブレット、PC、デジタルTVなど)>
一実施形態では、インターネット通信で用いられるマークアップ言語(HTML)がジャバスクリプトおよび/またはジャバのコード(ジャババイトコードまたはそのソースコード)をマークアップできるように構成される。一実施形態に係る情報通信端末は、前記マークアップ言語の要素(記述内容)に対応した情報表示(図39の5200など)を行うブラウザを備える。
[3]上記[1]において、前記ジャバスクリプトは、ジャバスクリプト言語で直接記述するか、あるいは、ジャババイトコードまたはそのソースコードを所定のクロスコンパイラでコンパイルすることで得られる。
[4]上記[1]において、情報通信端末は、ジャババイトコードを実行する仮想マシンを備える。
[5]上記[1]において、情報通信端末は、前記情報表示はウェブページで行われ、前記マークアップ言語(HTML)の要素を前記ウェブページでどのように表示(修飾)するのかを指示するカスケーディングスタイルシート(CSS)が前記マークアップ言語とともに用いられる。
[6]上記[1]において、センサおよび/またはアクチエータを備えたユニットが1以上存在する場合を想定する。その場合、情報通信端末は、前記情報通信端末はサーバを介して前記1以上のユニットのいずれかに接続可能に構成される。前記情報通信端末に接続された前記ユニットのセンサおよび/またはアクチエータは、前記ジャバスクリプトおよび/またはジャバのコードを用いて制御できる。
[7]上記[6]において、前記1以上のユニットはファイル管理(図38)される。前記1以上のユニットへの情報書込み(制御指令の書込)または前記1以上のユニットからの情報読出し(制御結果の読取)は、前記ジャバスクリプトおよび/またはジャバのコードにより行うことができる。
[8]一実施形態に係る方法は、センサおよび/またはアクチエータを備えたユニットが1以上存在するネットワークで用いられる。この方法では、前記ユニットのセンサおよび/またはアクチエータの制御に使えるメソッドを記述したクラスを1以上含むライブラリから取り出した1以上のクラスの組み合わせにより、1以上のコンピュータプログラムが生成される。そして、前記生成された1以上のコンピュータプログラムにより、前記ユニットのセンサおよび/またはアクチエータが制御される。
[9]インターネット通信で用いられるマークアップ言語(HTML)の要素(記述内容)を用いてウェブブラウザ上で情報表示を行う方法において、前記マークアップ言語(例えばHTML5またはその将来版)は、ジャバスクリプトおよび/またはジャバのコードをマークアップする。
[10]上記[9]において、前記ジャバスクリプトは、ジャバスクリプト言語で直接記述するか、あるいは、ジャババイトコードまたはそのソースコードを所定のクロスコンパイラでコンパイルすることで得られる。
[11]上記[10]において、前記ジャババイトコードは仮想マシンで実行される。
この発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。なお、開示された複数の実施形態のうちのある実施形態の一部あるいは全部と、開示された複数の実施形態のうちの別の実施形態の一部あるいは全部を、組み合わせることも、発明の範囲や要旨に含まれる。
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・・・プロセッサ/通信モジュール対応フォルダ。

Claims (7)

  1. センサおよび/またはアクチエータを備えたユニットが1以上存在するネットワークで
    用いられる情報機器において、
    前記情報機器は、前記1以上のユニットのいずれかに接続可能に構成され、
    前記情報機器が、接続された前記ユニットのセンサおよび/またはアクチエータを制御
    する1以上のコンピュータプログラムを用いるように構成され、
    前記ユニットのセンサおよび/またはアクチエータの制御に使えるメソッドを記述した
    クラスを1以上含むライブラリから取り出した1以上のクラスの組み合わせにより、前記
    1以上のコンピュータプログラムが生成され、
    前記生成された1以上のコンピュータプログラムにより、前記ユニットのセンサおよび
    /またはアクチエータを制御するように構成され、
    前記情報機器はジャババイトコードを生成するプログラム言語と前記ジャババイトコー
    ド以外のコードを使うアプリケーションを利用可能に構成され、
    前記ジャババイトコードを生成するプログラム言語をジャバとするとき、1以上のジャ
    バのクラスと1以上のジャバスクリプトのライブラリが用意され、
    1以上のジャバのクラスと1以上のジャバスクリプトを組み合わせたユーザ定義プログラムを1以上含むユーザ定義ライブラリが用意され、前記ユーザ定義プログラムのいずれかを用いることによって、前記ジャバスクリプトを介して、前記ジャババイトコードを生成するプログラム言語と、前記ジャババイトコード以外のコードを使うアプリケーションとの間の橋渡しを可能とするように構成された情報機器。
  2. インターネット通信で用いられるマークアップ言語がジャバスクリプトおよび/または
    ジャバのコードをマークアップできるように構成され、前記マークアップ言語の要素に対
    応した情報表示を行うブラウザを備えた情報通信端末において、
    センサおよび/またはアクチエータを備えたユニットが1以上存在する場合、前記情報
    通信端末はサーバを介して前記1以上のユニットのいずれかに接続可能に構成され、前記
    情報通信端末に接続された前記ユニットのセンサおよび/またはアクチエータを、前記ジ
    ャバスクリプトおよび/またはジャバのコードを用いて制御するように構成し、
    前記ジャバのコードをジャババイトコードとするとき、1以上のジャバのクラスと1以
    上のジャバスクリプトのライブラリを用意し、
    1以上のジャバのクラスと1以上のジャバスクリプトを組み合わせたユーザ定義プログラムを1以上含むユーザ定義ライブラリが用意され、前記ユーザ定義プログラムのいずれかを用いることによって、前記ジャバスクリプトを介して、前記ジャババイトコードを生成するプログラム言語と、前記ジャババイトコード以外のコードを使うアプリケーションとの間の橋渡しを可能とするように構成した情報通信端末。
  3. 前記ジャバスクリプトは、ジャバスクリプト言語で直接記述するか、あるいは、ジャバ
    バイトコードまたはそのソースコードを所定のクロスコンパイラでコンパイルすることで
    得られる請求項2の情報通信端末。
  4. ジャババイトコードを実行する仮想マシンを備えた請求項2の情報通信端末。
  5. 前記情報表示はウェブページで行われ、前記マークアップ言語の要素を前記ウェブペー
    ジでどのように表示するのかを指示するカスケーディングスタイルシートが前記マークア
    ップ言語とともに用いられる請求項2の情報通信端末。
  6. 前記1以上のユニットはファイル管理され、前記1以上のユニットへの情報書込みまた
    は前記1以上のユニットからの情報読出しが前記ジャバスクリプトおよび/またはジャバ
    のコードにより行われる請求項2の情報通信端末。
  7. センサおよび/またはアクチエータを備えたユニットが1以上存在するネットワークで
    用いられる方法であって、
    前記ユニットのセンサおよび/またはアクチエータの制御に使えるメソッドを記述した
    クラスを1以上含むライブラリから取り出した1以上のクラスの組み合わせにより、1以
    上のコンピュータプログラムを生成し、
    前記生成した1以上のコンピュータプログラムにより、前記ユニットのセンサおよび/
    またはアクチエータを制御する情報処理方法において、
    前記情報処理方法はジャババイトコードを生成するプログラム言語と前記ジャババイト
    コード以外のコードを使うアプリケーションを利用可能に構成され、
    前記ジャババイトコードを生成するプログラム言語をジャバとするとき、1以上のジャ
    バのクラスと1以上のジャバスクリプトのライブラリが用意され、
    1以上のジャバのクラスと1以上のジャバスクリプトを組み合わせたユーザ定義プログラムを1以上含むユーザ定義ライブラリが用意され、前記ユーザ定義プログラムのいずれかを用いることによって、前記ジャバスクリプトを介して、前記ジャババイトコードを生成するプログラム言語と、前記ジャババイトコード以外のコードを使うアプリケーションとの間の橋渡しを可能とするように構成された情報処理方法。
JP2019104636A 2015-09-29 2019-06-04 情報機器または情報通信端末および、情報処理方法 Active JP6957558B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2019104636A JP6957558B2 (ja) 2015-09-29 2019-06-04 情報機器または情報通信端末および、情報処理方法
JP2021163239A JP7224415B2 (ja) 2015-09-29 2021-10-04 情報機器または情報通信端末および、情報処理方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017510592A JPWO2017056194A1 (ja) 2015-09-29 2015-09-29 情報機器または情報通信端末および、情報処理方法
JP2019104636A JP6957558B2 (ja) 2015-09-29 2019-06-04 情報機器または情報通信端末および、情報処理方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2017510592A Division JPWO2017056194A1 (ja) 2015-09-29 2015-09-29 情報機器または情報通信端末および、情報処理方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2021163239A Division JP7224415B2 (ja) 2015-09-29 2021-10-04 情報機器または情報通信端末および、情報処理方法

Publications (2)

Publication Number Publication Date
JP2019194869A JP2019194869A (ja) 2019-11-07
JP6957558B2 true JP6957558B2 (ja) 2021-11-02

Family

ID=68469014

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019104636A Active JP6957558B2 (ja) 2015-09-29 2019-06-04 情報機器または情報通信端末および、情報処理方法

Country Status (1)

Country Link
JP (1) JP6957558B2 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111787049A (zh) * 2020-05-09 2020-10-16 苏州中科中霖电子科技有限公司 一种基于设备对象的物联网设备管理方法与系统
CN111857646A (zh) * 2020-08-05 2020-10-30 上海茂声智能科技有限公司 一种快速实现语音交互功能的系统
CN112148265B (zh) * 2020-09-29 2023-06-30 华能新能源股份有限公司 一种气象观测数据格式转换系统和方法
CN112153752A (zh) * 2020-09-29 2020-12-29 王喻 一种基于5g固定群组的上下行解耦的随机接入方法
CN112396292B (zh) * 2020-10-22 2024-03-29 国网浙江省电力有限公司嘉兴供电公司 一种基于物联网及边缘计算的变电站设备风险管控系统
CN112565005B (zh) * 2020-11-26 2022-05-13 北京北信源软件股份有限公司 网络串线检测方法及装置、设备及介质
CN112507321A (zh) * 2020-12-29 2021-03-16 珠海优特智厨科技有限公司 电子菜谱的权限控制方法、设备及计算机可读存储介质
CN113434191B (zh) * 2021-07-01 2023-06-16 青岛海尔科技有限公司 设备功能的处理方法和装置、存储介质及电子装置
CN114429704A (zh) * 2021-12-28 2022-05-03 盐城市大丰燃气设备有限公司 一种燃气智能控制系统及方法
WO2024101969A2 (ko) * 2022-11-10 2024-05-16 주식회사 윌로그 소정 공간에 배치된 센싱 장치, 및 이의 연동 방법
WO2024101970A1 (ko) * 2022-11-10 2024-05-16 주식회사 윌로그 다중 영역 센싱 가능한 멀티 모달 기반 전자 장치, 및 이의 동작 방법

Also Published As

Publication number Publication date
JP2019194869A (ja) 2019-11-07

Similar Documents

Publication Publication Date Title
JP6957558B2 (ja) 情報機器または情報通信端末および、情報処理方法
US10691089B2 (en) Information processing apparatus or information communication terminal, and information processing method
US11936744B2 (en) Client system, combination client system and server client system
US20230266728A1 (en) Electronic appliance control method and electronic appliance control device
Shammar et al. The Internet of Things (IoT): a survey of techniques, operating systems, and trends
Hassan Internet of things A to Z: technologies and applications
Behmann et al. Collaborative internet of things (C-IoT): For future smart connected life and business
Lakhwani et al. Internet of Things (IoT): Principles, paradigms and applications of IoT
CN105453075A (zh) 无线触发的智能媒体向导
JP2019053760A (ja) セキュリティデータ管理システムによる管理方法及び管理システム
JP7417687B2 (ja) 電子ユニット管理方法及び電子ユニット管理システム
JP6448481B2 (ja) センサ情報に基づいてサービスを行うデバイスおよび方法
Prabhu Design and Construction of an RFID-enabled Infrastructure: The Next Avatar of the Internet
Khatoon et al. Importance of semantic interoperability in smart agriculture systems
JP7224415B2 (ja) 情報機器または情報通信端末および、情報処理方法
JP7505058B2 (ja) 情報機器または情報通信端末および、情報処理方法
JP6437688B2 (ja) アプリケーション指定に対応するユニット
JP6929982B2 (ja) ユニットの制御方法およびユニット、システムコントローラ、クライアントシステム
JP6951487B2 (ja) 電子ユニット管理方法及び電子ユニット管理システム
JP6668428B2 (ja) ユニットの制御方法
JP6567746B2 (ja) クライアントシステム
JP2023175955A (ja) インフラ管理システム、インフラ管理方法
Kumar An Urban Sensing Architecture as Essential Infrastructure for Future Smart Cities Research
Aldakar A Wireless Sensor Network for Environmental Monitoring System

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190604

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200825

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201021

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210323

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210507

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210907

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20211006

R150 Certificate of patent or registration of utility model

Ref document number: 6957558

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150