JP3187701U

JP3187701U - 居住者生活支援システム

Info

Publication number: JP3187701U
Application number: JP2013005395U
Authority: JP
Inventors: 幸夫吉川
Original assignee: 株式会社ブロープロヴァンス
Priority date: 2013-09-18
Filing date: 2013-09-18
Publication date: 2013-12-12
Anticipated expiration: 2023-09-18

Abstract

【課題】医療情報、介護情報、学校情報などを一括してネットワーク化し、居住者に必要な安全な暮らしをサービスする居住者生活支援システムを提供する。
【解決手段】各種の情報の収集と蓄積を行い、居住者のためのデータ加工とデータチェックを実施するホストサーバ２と、通信回線を介して公的情報をホストサーバへ送受信する自治体サーバ３と、通信回線を介して生活関連情報をホストサーバへ送受信する各種の専門サーバ５と、自宅の電気製品の接続が集まる分電盤７に接続するデバイスユニット８とを備え、デバイスユニットは、通信回線を介してホストサーバと常時接続される。
【選択図】図１

Description

本考案は、医療情報、介護情報、学校情報などを一括してネットワーク化する居住者生活支援システムに関し、このネットワーク化において、居住者に必要な安全な暮らしのサービスを提供するとともに、地球に優しいクリーンなエネルギー環境の成立を推進する居住者生活支援システムに関する。

近年、特定の地域単位でエネルギー消費量を総合的に管理するＣＥＭＳ（コミュニティエネルギーマネジメントシステム）の促進が求められている。このＣＥＭＳの推進により、発生ＣＯ_２を削減して地球温暖化を防止し、地球に優しいクリーンなエネルギー環境を提供するとともに、居住者にとって最も必要な安全な暮らしのサービスが受けられるシステム（いわゆるスマートシティ）を実現することが可能になる。このような観点から、特開２０１１−５９９３９号では、エネルギー需要側から供給側へのリクエストを反映し、双方向でのエネルギー管理を実現する技術が提唱されている。

また、自宅における電気やガスなどの無駄な消費を抑制することにより、電力などのエネルギー使用状況の監視または需給を制御し、ひいては省エネルギーにつながる各種の技術も提案され、ＨＥＭＳ（ホームエネルギーマネジメントシステム）の推進がこの状況を加速させる一助になることが期待されている。例えば、特開２０１０−２１１７８０号では、データベースに保存する過去の電力エネルギー使用量となる実績値から日または月単位の電力エネルギー使用量の目標値を求め、さらに日単位や月単位などの長時間、長期間に亘る電力エネルギー使用量の予測値および目標値を高い精度で求めることにより、電力エネルギーを適切に監視する。

ＨＥＭＳの別の例として、特開２０１３−２０４８８号が存在する。特開２０１３−２０４８８号では、積算使用量を表示するガスメータの表示部を撮像することで得た画像を端末側処理装置に伝送し、画像認識手段で画像認識された画像データをデータ変換手段で数値データ化する。この数値データを格納手段に格納するとともに、出力手段を介してデータ解析手段に出力する。また、出力された数値データを公衆通信回線を介して、ホストコンピュータに伝送し、ホストコンピュータでデータ解析を行った後、端末側処理装置にフィードバックする。

特開２０１１−５９９３９号公報特開２０１０−２１１７８０号公報特開２０１３−２０４８８号公報

特開２０１１−５９９３９号に開示のエネルギー管理システムは、エネルギー需要側のシステムとエネルギー供給側のシステムとが合意した条件下において、負荷遮断の対象機器が定められる。この判定は、各システムに搭載の制御演算部が所定の演算処理を実行することによって定まる。それ故に、ユーザが望む負荷遮断の対象機器と、演算処理により決定される負荷遮断の対象機器とが一致するとは限らず、ユーザの意思が、負荷遮断の対象機器を選定する際に反映されないことがある。この管理システムは、特定の地域単位でエネルギー消費量を管理するＣＥＭＳに該当しない。

一方、特開２０１０−２１１７８０号におけるデータの読み取りは、撮像・送信されてきた画像を継続的に記憶し、記憶されている第１画像と所定時間後に送信されてきた第２画像とを比較して差分を検出し、この差分が所定の値以上であると判定されると第２画像を出力する。この方法では、送受信されるデータが画像データであることから、通信に要するデータ量が大きくなり、インターネットなどの回線において通信速度が遅くなる。特開２０１３−２０４８８号は、電気自動車などに搭載される車両用蓄電池を充電するための充電スタンドを分電盤に接続し、さらに風力や地熱発電のグリーン電力も分電盤に接続できる。この管理システムは、戸建て用としてシステム規模が非常に大きく、既設の建物に後付けするのが実際上困難であるうえに、特定の地域においてエネルギー消費量を総合的に管理するものでもない。

大手の家電メーカーやハウスメーカーは、ＣＥＭＳの促進およびＨＥＭＳの「見える化」と「制御」について開発を進めており、資源エネルギー庁におけスマートハウス標準化検討会や国家戦略室のグリーン政策大綱などでも検討されている。ＣＥＭＳに関しては、システムの規模が大きくなり、複雑化しすぎるのが課題である。また、ＨＥＭＳに関しては、家電製品を屋外から無線で制御できる機器が２０１３年から２０１４年にかけて順次製品化される見通しであり、その時点までは、屋外から無線で制御できる機器を使用しないエネルギー管理システムしか実施化することができない。

本考案は、既存のホームエネルギー管理システムなどに関する前記の問題点を改善するために提案されたものであり、特定の地域単位でエネルギー消費量を総合的に管理するＣＥＭＳの促進に寄与する居住者生活支援システムを提供することを目的としている。本考案の他の目的は、システムの全体構成が比較的単純であり、システム設置後にも拡張が可能である居住者生活支援システムを提供することである。本考案の他の目的は、居住者側において、必要とする設置機器数が比較的少なくて安価であり、既設の建物にも後付け可能である居住者生活支援システムを提供することである。

本考案に係る居住者生活支援システムは、全国の特定地域ごとに医療、介護、学校情報を含む生活関連情報をネットワーク化するとともに、居住者側では自宅で使用する電気やガスを含むエネルギー消費に関する加工情報を受信できる。本考案の居住者生活支援システムでは、各種の情報の収集と蓄積を行い、居住者のためのデータ加工とデータチェックを実施するホストサーバと、通信回線を介して公的情報をホストサーバへ送受信する自治体サーバと、通信回線を介して生活関連情報をホストサーバへ送受信する各種の専門サーバと、自宅の電気製品の接続が集まる分電盤に接続するデバイスユニットとを備え、該デバイスユニットは、公衆通信回線を介してホストサーバと常時接続される。

本考案の居住者生活支援システムにおいて、専門サーバとして、医療関連、介護・福祉関連、学校関連、支払い関連、電気・ガス関連、小売店関連、デリバリー・宅配関連、イベント関連、防犯関連、建築関連、スポーツ関連、交通関連サーバのいずれかまたは全てのサーバを包含する。また、システム構築後に独立の専門サーバを追加する際に、該専門サーバを公衆通信回線に接続すると、ホストサーバのプログラムを変更するだけで独自の生活関連情報が追加される。

本考案の居住者生活支援システムにおいて、タブレットを含むモニタ機器が、自宅内でルータに無線ないし有線接続されるかまたは屋外において携帯通信機器が公衆通信回線に無線接続されることにより、これらの機器によって任意の生活関連情報を取得し、さらに自宅における過去、現在および未来の電気料金や使用電力量をリアルタイムに表示すると好ましい。生活支援システムに追加するビルダーサーバは、ホストサーバを経由して各種の生活関連情報を各居住者へ発信し、他社との差別化を図って「見える化」としての宣伝効果を高め、この生活関連情報には、各居住者への有益情報に相当する電子広告、通販、定期メンテナンスのお知らせを含み、この生活関連情報を各居住者のモニタ機器および屋外の携帯通信機器に表示することが望ましい。

本考案に係る居住者生活支援システムは、特定の自治体サーバがシステム内に存在することにより、特定の地域単位でエネルギー消費量を総合的に管理するＣＥＭＳの促進に寄与し、発生ＣＯ_２を削減して地球温暖化を防止することで地球に優しいクリーンなエネルギー環境を成立させる。本考案に係る居住者生活支援システムは、既存の通信設備などを利用するとシステムを比較的容易に構築できるうえに、システムの全体構成が比較的単純であってシステム設置後にも拡張が容易である。

本考案に係る居住者生活支援システムは、自宅におけるエネルギーの管理を可能にすることでクリーンなエネルギー環境の成立を加速させ、ＣＥＭＳ促進の一助となるＨＥＭＳを推進する。本考案に係る居住者生活支援システムは、受益者である居住者側において、該システムが必要とする機器数が比較的少ないので、その加入および機器設置が容易である。また、本考案に係る居住者生活支援システムは、居住者側では戸建ておよびマンションのいずれでも利用でき、既設の建物にも後付け可能であるのでシステムへ加入する際の障害が殆ど発生しない。

本考案に係る居住者生活支援システムを例示する概略説明図である。本考案の居住者生活支援システムを構築するデバイスユニットの概略構成を示すブロック図である。本考案で用いるモニター機器であるタブレットにおいて、電気代と電気使用量などを表示する初期画面例の平面図である。モニター機器であるタブレットにおいて、選択可能な項目を表示する画面例の平面図である。居住者の居住地を管轄する地方自治体の領域内に存在するデリバリー店舗を表示する画面例の平面図である。所定のデリバリー店舗において、適当なピザを選択できる画面例の平面図である。所定のデリバリー店舗において、ピザ選択を確認できる画面例の平面図である。モニター機器であるタブレットにおいて、月間のガス使用量のグラフを表示する画面例の平面図である。モニター機器であるタブレットにおいて、宣伝画面を表示する画面例の平面図である。図４の画面で「料金支払い」をクリックした際に、居住者生活支援システムにおける請求側サーバの請求タスクのフローチャートである。居住者生活支援システムにおける給付側サーバの給付タスクの第１のフローチャートである。図４の画面で「役所からのお知らせ」をクリックした際に、処理手順を示すフローチャートである。自治体におけるお知らせファイル作成手順を示すフローチャートである。図４の画面で「書類申請」をクリックした際に、申請者である居住者が申請書作成から申請完了までの処理手順を示すフローチャートである。電子申請システムが申請書受付から受付完了までの処理手順を示すフローチャートである。自動交付機が公文書を交付する処理手順を示すフローチャートである。

次に、本考案を図面によって説明すると、本考案の居住者生活支援システム１は、図１に例示するようなシステム構成であり、公衆通信回線であるインターネット回線１０に接続するサーバの一部を図示する。居住者生活支援システム１は、各種の情報の処理、収集と蓄積を行うホストサーバ２と、通信回線を介して公的情報をホストサーバ２へ送受信する自治体サーバ３と、通信回線を介して生活関連情報をホストサーバ２へ送受信する複数の専門サーバ５とを備え、該ホストサーバを経由して各種の生活関連情報を各居住者へ送信するビルダーサーバ６をシステム１に組み込む。一方、各居住者側には、自宅において電気製品の接続が集まる分電盤７に接続するデバイスユニット８を設置する。

ホストサーバ２には、専用通信回線を介して自治体サーバ３、複数の専門サーバ５およびビルダーサーバ６を直接接続しても、インターネット回線１０または他の公衆通信回線を介して接続してもよく、両回線が混在する構成でもよい。自治体サーバ３、複数の専門サーバ５およびビルダーサーバ６は、ルータ１１を経て居住者のモニター機器１２へ直接データを送信することなく、ホストサーバ２においてデータ加工とデータチェックを実施した後にモニター機器１２へ所定のデータを送信する。

自治体サーバ３は、都道府県または市町村を限界された範囲に分割し、居住者の居住地を管轄する地方公共団体が運営するサーバである。自治体サーバ３は、生活関連データとして住民へのお知らせ、当該自治体の役所の収支、市役所の位置、市長、助役、各吏員の氏名と担当業務、人口、面積、主要産業、戸籍や住民票などの公文書の発行などの各種の生活関連情報を包含する。自治体サーバ３は、ホストサーバ２を経由して生活関連データを居住者のモニター機器１２へ送信し、且つホストサーバ２を経由して居住者のモニター機器１２から必要情報を受信する。

専門サーバ５は、生活関連情報を提供する単独の法人または団体のサーバであり、組合の既存のサーバを利用することが可能である。専門サーバ５は、例えば、医療関連サーバ１４、介護・福祉関連サーバ１５、学校関連サーバ１６、支払い関連サーバ１８、電気・ガス関連サーバ２０、小売店関連サーバ２２、デリバリー・宅配関連サーバ２３、イベント関連サーバ２４を有し、図示しないけれども、さらに防犯関連サーバ、建築関連、スポーツ関連サーバ、交通関連サーバ、公文書取得関連サーバなどを包含する。専門サーバ５の一例として、支払い関連サーバ１８は、個々の銀行、信用金庫、信用組合の単独サーバであっても、これらの関連団体のサーバを組み込んでもよい。

居住者生活支援システム１に有益な生活関連情報を補充する際には、所定の専用サーバを追加するとともに、該サーバからデータを送受信できるようにホストサーバ２のプログラムを変更する。専門サーバ５は、ホストサーバ２を経由して生活関連データを居住者のモニター機器１２へ送信し、且つホストサーバ２を経由して居住者のモニター機器１２から必要情報を受信する。

ビルダーサーバ６は、契約企業が他社との差別化を図り、「見える化」としての宣伝効果を高めるために、電子広告、通販、定期メンテナンスのお知らせなどの有益情報を発信する。ビルダーサーバ６は、ホストサーバ２を経由して各種の有益情報を居住者のモニター機器１２へ自動的に発信するけれども、居住者のモニター機器１２から情報を直接受信することはない。

図２は、各居住者の自宅内に設置するデバイスユニット８の構成を概略的に示す。デバイスユニット８は、プログラマブルコンピュータを含み、図示するようにＣＰＵ２８、ＲＯＭ３０、ＲＡＭ３２および入出力ポート３４を備え、これらはアドレスバス、データバスおよび制御バスなどのバス３６を介して互いに接続される。さらに、デバイスユニット８は、通常、バス型ＬＡＮチップ３８を含み、該チップからインターネット回線１０を経てホストサーバ２および各専門サーバ５とビルダーサーバ６が接続され、該ホストサーバと生活関連情報などの授受を行う。

デバイスユニット８について、ＲＯＭ３０には、自宅への電力供給を制御するプログラムおよび該プログラムを実行するための各種の情報などが保存されている。ＲＯＭ３０に保存されたプログラムは、ＲＡＭ３２などに展開してＣＰＵ２８が実行することにより、自宅へ供給する電力の供給制御や、その他の各種制御を行うようになっている。さらに、入出力ポート３４には、分電盤７用の電力センサ４０、水道用のパルスセンサ４２、ガス用の流量センサ４４などを接続できる。

電力センサ４０（図１）は、簡易計測モードを使うことにより、分電盤７の電線に電流センサ（ＣＴ）を接続するだけで使用でき、既設の設備でも電源オフすることなく電力計測が可能である。電流センサ（ＣＴ）は、分電盤７のような単相３線式や三相３線式を計測する場合には２個必要である。２個の電流センサ（ＣＴ）は、同じ定格容量のものを使用し、接続の際には、先に電流センサ（ＣＴ）の２次側を電力センサ４０の本体に接続し、ついでその１次側を分電盤７の電線に配線する。

デバイスユニット８の一例として、該デバイスユニットをデバイスサーバ（公序良俗違反につき、不掲載）（図示しない）で構成すると好ましい。このデバイスサーバは、小型の正方形サイズの中にＣＰＵ、メモリー、バス型ＬＡＮチップなどのハードウェア、さらにＲＴＯＳ、ＴＣＰ／ＩＰプロトコル、セキュリティ対応ＷＥＢサーバ、ＳＮＭＰｖ２ｃなどのソフトウェアを組み込んでいる。このデバイスサーバは、内部に３２ビットのＣＰＵを持っているため、他の機器のホストＣＰＵリソースをほとんど使用することなく、その機器本体とネットワークに接続でき、ＴＣＰ／ＩＰを実装したり、処理能力の高いＣＰＵへ載せかえるなどの基本設計を見直す必要がない。

デバイスユニット８には、プログラマブルなＲＳ−２３２／ＲＳ−４８５／ＲＳ−４２２マルチプロトコルトランシーバであるデバイス（公序良俗違反につき、不掲載）を取り付けると好ましく、このデバイスは、２Ｔｘ／２ＲｘＲＳ−２３２インタフェースまたはシングルＲＳ−４８５／ＲＳ−４２２トランシーバとしてピンプログラマブルである。また、他のデバイスとして、ＲＳ−４８５およびＲＳ−４２２通信用の±１５ｋＶ、ＥＳＤ保護付き、＋３．３Ｖの低電力トランシーバであるデバイス（公序良俗違反につき、不掲載）を取り付けると好ましい。

図１において、ルータ１１は、通常、光回線終端装置２５を経てインターネット回線１０に接続する。ルータ１１には、入出力機器として、画面表示部および操作部を含むモニタ機器１２を無線または有線接続すればよく、さらにパソコン２６およびＴＶ機器などを任意に有線接続できる。モニタ機器１２として、図示のような市販のタブレット、タッチパネルまたはスマートフォンなどが適用できる。屋外では、スマートフォン２７や携帯電話機などを無線でインターネット回線１０に接続すればよい。

屋上設置された太陽光発電装置４６は、パワーコンディショナ４８を介してデバイスユニット８に接続される。太陽光発電装置４６で発電した直流電力は、パワーコンディショナ４８によって交流電力に変換され、分電盤７に供給されることで住宅に発電電力を供給できる。分電盤７には、太陽光以外の風力や地熱などの自然エネルギー利用の発電装置、太陽光発電を含む発電電力を蓄電する蓄電池などを接続してもよく、これらの電力を住宅に供給することが可能である。図示しないけれども、ハイブリッドまたは電気自動車などに搭載された車両用蓄電池を充電するために、充電スタンドを分電盤７に接続しておくと該分電盤から充電スタンドに電力を供給でき、一方、該車両用蓄電池から分電盤７に電力を供給することも可能である。

太陽光発電装置４６をデバイスユニット８に接続するには、パワーコンディショナ４８、売電用電気メータ４９および買電用電気メータ５０のいずれも電力センサ（ＣＴ）５２、５４、５６を経由させる。電力センサ（ＣＴ）５２、５４、５６は、各機器の電線に接続するだけで使用できる。使用する電流センサ（ＣＴ）は、単相２線式を計測する場合には１個でよい。

分電盤７は、電力センサ４０を経由してデバイスユニット８に接続しており、該電力センサは電力モニタまたはパワーメータとも称する。電力センサ４０、５２、５４、５６により、導入から計測・データ管理まで使用エネルギーの基本的な「見える化」を簡単に実施でき、計測データをデバイスユニット８とルータ１１を経てホストサーバ２に保存できるので、モニタ機器１２などで簡単にグラフ表示が可能になる。

所望に応じて、他の家電機器であるエアコン５８や冷蔵庫６０なども電力センサ（ＣＴ）を経由して分電盤７に接続すると、該電力センサを経由してデバイスユニット８に接続でき、個々の家電機器について使用電気量、使用金額などがモニタ機器１２などで簡単にグラフ表示が可能になる。パワーコンディショナ４８、エアコン５８および冷蔵庫６０は、図示しないけれども、分電盤７に電気接続するのは当然である。パワーコンディショナ４８、エアコン５８および冷蔵庫６０などの家電機器が無線接続可能な機器であるならば、各家電機器をルータ１１に無線接続できるので、居住者はモニタ機器１２などを用いてこれらの家電機器を容易にリモート制御できる。

水道６２またはガス６４をデバイスユニット８に接続するには、水道管に取り付けたパルスセンサ４２またはガス管に組み込んだ流量センサ４４を経由させる。パルスセンサ４２および流量センサ４４は、通常、配管自体に組み込まれるため、建物の新築時に設置することが好ましい。

一方、既設の建物において、水道やガスの使用量などをモニタ表示させるには、図示しないけれども、赤外線カメラを既設の建物に後付けし、該カメラによって家庭用に設置されたガスメータの指示数を読み取ればよい。ＣＣＤカメラなどの赤外線カメラは、家庭のガス供給路に設置された積算表示型のガスメータの表示窓に対応させて配置し、該カメラでガスメータの表示窓に表示されている数値を撮影し、該カメラで撮影した映像をデバイスユニット８に伝送する。

デバイスユニット８は、前記の赤外線カメラから伝送された画像を取り込み、ＲＯＭ３０に格納されたＯＣＲプログラムに従って、取り込まれた画像を認識し、画像認識された画像データを数値データに変換する。変換した数値データはＲＡＭ３２に保存するとともに、入出力ポート３４とルータ１１を介してホストサーバ２へ伝送される。

ホストサーバ２は、インターネット回線１０を介して、自治体サーバ３、各専門サーバ５およびビルダーサーバ６から各種の生活関連情報を受信するとともに、居住者からの要求を自治体サーバ３や各専門サーバ５に送信し、さらにデバイスユニット８から送信される各種データの収集と蓄積を行い、最適の「見える化」のためのデータ加工と推移チェックなどを実施する。また、例えば、生活支援のために、各居住者の使用エネルギーを確認しながら、より適したエネルギーの削減法を提案できる。

この「見える化」は、図３および図８に例示するような電気、ガス、水道の使用量、使用金額だけでなく、その前年対比、目標値の設定、削減結果の評価、時間毎／日、日々毎／月、月々毎／年などをそれぞれ表示し、さらにＣＯ_２の目標削減量も表示できる。個々の数値データは、インターネット回線１０を介して、データ管理及びウエブ閲覧サービスを行うホストサーバ２に送信される。

自宅内では、所定の機器用の電力センサ４０、５２、５４、５６、パルスセンサ４２および流量センサ４４は、デバイスユニット８へ個々の数値データを常時出力する。個々の数値データは、さらにデータ管理およびウエブ閲覧サービスを行うホストサーバ２に送信され、該ホストサーバでデータ解析を行った後に、その解析結果をホストサーバ２の記憶手段に格納する。この格納された解析データは、各居住者の出力要求により、インターネット回線１０を経て任意に閲覧できる。

この出力要求は、モニタ機器１２、パソコン２６または屋外のスマートフォン２７などから可能であり、抽出された解析後の出力データは自宅のモニタ機器１２、パソコン２６、ＴＶ機器および屋外のスマートフォン２７で確認できる。家電機器が無線接続可能な機器であれば、モニタ機器１２などによってルータ１１を介して家電機器をリモート制御できるので、使用電気量の調整、停電時間の増減、太陽光発電装置４６の電力の自宅への供給量などを任意に調整できる。

モニタ機器１２では、ルータ１１を介してホストサーバ２と送受信可能であり、該ホストサーバを経て自治体サーバ３、各専門サーバ５およびビルダーサーバ６から、天気予報、お知らせ、広告などの各種の生活関連情報を受信して画面表示ができ、さらに居住者からの要求を自治体サーバ３や各専門サーバ５へ送信できる。また、太陽光発電装置４６の発電量の予測などを行うために、天気情報をホストサーバ２が取得して加工し、その加工データをデバイスユニット８へ送り、取得した天気データを参照することにより、太陽光発電装置４６による発電電力量の予測を行うことも可能である。

モニタ機器１２がタブレットである場合に、その画面表示の一例を図３から図９において説明する。図３はタブレットを起動したときの初期画面６６であり、分電盤７から電力センサ４０を経由してデバイスユニット８で該当月の電気使用量を計算し、さらにホストサーバ２で使用済みの電気代、ＣＯ₂排出量、該当月の予想電気代を算出して表示する。この際に、ガス使用量も検出可能ならば、表示名は「今月の光熱費は」になる。次に、画面６６の「ＪＳＣ」６８をクリックすると、図４の画面７０を表示する。画面７０に示す各項目は一例であり、項目数が多くなるならば複数の画面に分けて表示してもよい。

図４の画面７０において、それぞれの項目を選択してクリックすると、通常、ホストサーバ２を経由して自治体サーバ３、個々の専門サーバ５やビルダーサーバ６に接続されることになる。例えば、「デリバリー宅配」７２を選択してクリックすると、図５の画面７４を表示する。図５の画面７４は、居住者の居住地を管轄する地方自治体の領域内に存在する店舗を表示し、ホストサーバ２を経由してデリバリー・宅配関連サーバ２３（図１）にアクセスすることで表示可能になる。

図５の画面７４において、所望の店舗を選択してクリックすると、図６の画面７６を表示する。図６の画面７６において、適当なピザを選択して「注文する」をクリックすると、サイズ、生地を選択し且つ数量を記入できる画面（図示しない）が表示され、これらを選択・記入を完了すれば、図７の確認画面７８を表示する。確認画面７８では、お届け先の変更が可能であり、所望のピザの注文を確定できる。

また、図３の初期画面６６において、「詳しく見る」８０をクリックすると、図８の画面８２を表示し、日々の使用量が確認可能である。但し、画面８２はガス使用量のグラフであり、図８および図９ともに図３と表示年月日が異なる。また、初期画面６６において、「お知らせ」８４をクリックすると、ホストサーバ２を経由してビルダーサーバ６と接続し、図９の宣伝画面８６を表示する。ビルダーサーバ６は、宣伝画面８６以外にも、契約企業のお得情報、通販情報、定期メンテナンスのお知らせなどを発信し、これを画面に表示できる。

処理例１
次に、図４の画面７０に示す項目に関する具体的な処理に基づいて説明するが、これらの処理例はあくまで参考であり、本考案がこの処理例に限定されるものではない。居住者が画面７０（図４）の「料金支払い」８８をクリックした場合には、この処理において、料金を支払う居住者に年金（給付金）を給付する自治体（支払い機関）から、電気料金やガス料金などの料金を電力会社やガス会社などの料金請求機関に直接支払う場合である。また、年金以外の給付金から支払う場合でもよく、例えば、支払い機関が取引銀行であり、毎月の給与から公共料金などを引き落とす場合などにも適用できる。

居住者生活支援システム１を電気料金の支払いシステムとして利用する場合、ホストサーバ２においてプログラム演算を行うとともに、自治体サーバ３が支払い側サーバであり、専門サーバ５に属する電気・ガス関連サーバ２０（図１）が請求側サーバに相当する。図示しないけれども、この請求側サーバには、企業データベースと、請求側受付プロセスと、請求プロセスと、支払取消プロセスとで構成する。一方、この支払い側サーバは、居住者データベースと、給付側受付プロセスと、給付プロセスとで構成する。

モニター機器１２における画面７０の「料金支払い」８８をクリックすると、ホストサーバ２を経て請求側サーバにアクセスし、本サービスの申込情報を送信すると、請求側受付プロセスによって受付の可否を判断する。この際に、申込情報の中の契約番号を企業データベース中の契約番号と比較・確認し、本サービスを受けられる居住者であるか否かを判断する。受付できない場合には、モニター機器１２へ受付不可のメッセージを送信する。一方、受付可能な場合には、支払い側サーバに申請情報を送信するとともに申込情報を記憶する。この申込情報には、居住者の年金番号が含まれ、申請情報には電力会社名と当該居住者の契約番号を含んで送信する。

次に、給付側受付プロセスによって、サービス提供の可否を判断する。つまり、申請情報を送信した電力会社とのサービス提供契約の有無や、申請情報中の年金番号が後述する居住者データベース中の年金番号と一致するか否かに基づいて、本サービスを居住者に提供できるか否かを判断する。サービス提供できない場合には、ホストサーバ２を提供不可のメッセージを送信し、請求側サーバの請求側受付プロセスから居住者のモニター機器１２へ提供不可のメッセージを送信する。

一方、サービスを提供可能な場合には、支払い月を決定する。電力会社への支払いは、請求側サーバからの支払い請求ごとに毎月または２ヶ月ごとに行うか選択可能であり、給付側受付プロセスは、電力会社名に基づいて支払い月を決定する。この処理形態では、給付月ごとに支払うものとして説明する。次に、申請情報に基づいて、サービス提供を登録する。つまり、居住者データベース中の契約番号に、申請情報中の契約番号を記憶する。ついで、請求側サーバに登録済みのメッセージを送信する。このメッセージには、居住者の年金番号と支払い月（請求月）とを含み、請求側受付プロセスによって、企業データベース中の年金番号と請求月とに、それぞれ年金番号と支払い月とを記憶することで、サービス提供の登録をする。そして、請求側受付プロセスからモニター機器１２に登録済みのメッセージを送信する。

前記の請求プロセスは、毎月起動され、各居住者（需要家）に対して請求書を作成して発送する処理を行うとともに、予め登録された居住者、つまり本サービスの提供を受ける居住者に対する電気料金の支払い請求を支払い側サーバに送信する処理である。この請求プロセスは、図１０に示すフローチャートに基づいている。図１０において、各居住者の電力使用量に基づいて電気料金を計算するホストサーバ２から、Ｓ１において各居住者（各契約番号）の電気料金リストを取得する。次に、Ｓ２において電気料金リスト中の最初の居住者データを企業データベースから取得する。Ｓ３において当該居住者が本サービスの提供を受けるか否かを判断することにより、当該居住者の年金番号が無効か否かを確認し、無効の場合には、Ｓ４において通常の料金請求書を作成する。

一方、本サービスの提供を受ける場合には、当該月が請求月であるか否かを、Ｓ５において当該居住者の請求月によって判断する。請求月でない場合には、当該居住者の契約番号とともに、Ｓ６において請求月でない旨をホストサーバ２に送信（通知）する。これにより、ホストサーバ２は、当該居住者の当該月の電気料金を次回の電気料金に積算する。

当該月が請求月である場合には、Ｓ７において請求リストにデータを追加し、請求リストの年金番号に、当該居住者の年金番号を記憶し、契約番号に当該居住者の契約番号を記憶する。また、請求金額に電気料金リスト中の電気料金を記憶し、請求対象年月に当該月を記憶する。次に、Ｓ８において振込済みの請求書を作成する。振込済みの請求書は、「電気料金請求書」として、請求額や契約番号などが記載されているとともに、「この電気料金は、お客さまの年金から直接お支払いして頂きますので振込みは不要です」と付記している。

支払い処理が終了すると、Ｓ９において、作成した各請求書を発送処理し、各請求書を発送するコンピュータやサーバへ各請求書と発送指令とを送信する。また、Ｓ１０において、作成した請求リストを支払い側サーバに送信する。この請求リストに基づいて、支払い側サーバによって、この請求金額が受給者データベースの請求金額に記憶され、この請求対象年月が受給者データベースの請求対象年月に記憶される。

この請求プロセスでは、本サービスの提供を受ける居住者に対して請求書を発送することで、支払い側サーバによる支払い処理の前に、年金から電気料金が支払われる旨を居住者に通知する。また、この請求プロセスでは、当該月が請求月であるか否かを判断することで、請求月と年金の給付月とを一致させる。つまり、年金の給付月にのみ、支払い側サーバに支払い請求する。

また、支払取消プロセスは、居住者のモニター機器１２から当該月については本サービスを受けない旨の通知を受けた場合、または支払い側サーバから後述するような不払いリストを受信した場合に、本サービスを適用しない処理である。居住者から上記通知を受けた場合、本サービス適用の取消が可能か否かを判断する。通知受信日と支払い処理日とを比較して、支払い側サーバによる取消が可能か否かを判断する。そして、取消ができない場合には、居住者のモニター機器１２に取消ができない旨のメッセージを送信する。

一方、取消ができる場合には、当該居住者の当該月については、本サービスを適用しない旨を支払い側サーバに送信する。そして、居住者データベースの請求金額および請求対象年月に既にデータが記憶されている場合には、支払い側サーバによって、データが削除される。次に、当該居住者に対して通常の料金請求書を作成し、前記のようにこの料金請求書を発送処理する。一方、支払い側サーバから不払いリストを受信した場合、不払いリスト中のすべての居住者に対して別の請求書を作成する。この別の請求書は、通常の料金請求書に、「この電気料金をお客さまの年金から直接支払うことができませんでした」と付記し、この請求書を発送処理する。

給付プロセスは、年金受給者に対して年金の給付プロセスを行う処理である。受給者が本サービスの提供を受ける場合には、当該居住者（受給者）に給付される年金額と、当該居住者が支払うべき電気料金の額とに基づいて、年金から電気料金の支払いが可能な場合に、電気料金を電力会社に支払う処理をし、年金から電気料金を差し引いた残年金を受給者に給付する処理をする処理であり、図１１に示すフローチャートに基づいている。

図１１において、各受給者への年金給付額を計算する年金計算サーバから、Ｓ２１において各受給者の年金給付額リストを取得する。次に、Ｓ２２において、年金給付額リスト中の最初の受給者の受給者情報（データ）を居住者データベースから取得する。そして、Ｓ２３において当該居住者が、本サービスの提供を受けるか否かを判断する。つまり、当該居住者の契約番号が無効か否かを確認し、提供を受けない（無効の場合）には、Ｓ２４において通常の給付書を作成し、年金の振込みを通知する。

一方、本サービスの提供を受ける場合には、Ｓ２５において当該月に電気料金の支払いが必要か否かを判断する。つまり、当該居住者の請求対象年月が当該月であるか否かを判断し、支払いが必要でない場合には、Ｓ２４において前記と同様の給付書を作成する。一方、支払いが必要な場合には、Ｓ２６において年金から電気料金の支払いが可能か否かを判断する。すなわち、年金給付額リスト中の年金給付額と請求金額とを比較して、年金給付額が請求金額の金額以上であれば、支払い可能と判断する。支払いができない場合には、Ｓ２７において不払いリストにデータを追加する。この不払いリストでは契約番号と年金番号とに、それぞれ当該居住者の契約番号と年金番号とを記憶し、請求金額と請求対象年月とに、それぞれ請求金額と請求対象年月とを記憶する。Ｓ２８では、当該居住者に対して別の給付書を作成する。別の給付書は、通常の給付書に「年金から電気料金をお支払いすることができませんでしたので、貴殿から直接お支払い下さい」と付記している。

これに対して、年金から電気料金の支払いが可能な場合には、Ｓ２９において支払いリストに当該居住者のデータを追加する。この支払いリストは、前記の不払いリストと同様のデータ構成であり、当該居住者（受給者）の契約番号と、年金番号と、請求金額と、請求対象年月とを記憶したものである。次に、Ｓ３０において当該年金給付額から電気料金（請求金額）を差し引いて残年金を算出し、Ｓ３１において差引済みの給付書を作成する。差引済みの給付書は、通常の給付書に電気料金を記し、さらに残年金（差引振込額）を記載している。

居住者に対する処理が終了した場合には、Ｓ３４において、作成した３種の給付書をそれぞれ発送処理し、３種の給付書を発送するコンピュータやサーバに、各給付書と発送指令とを送信する。Ｓ３５において、受給者に年金または残年金を給付（振込み）処理をするので、年金を振込み処理する支払い側サーバに、各給付書と振込み指令とを送信する。次に、Ｓ３６において、作成した支払いリストと不払いリストとを請求側サーバに送信し、Ｓ３７において電力会社への支払い処理を行い、料金を振込み処理する支払い側サーバに、支払いリストと振込み指令とを送信することにより、電力会社に電気料金が振り込まれる。

このような構成の料金支払いシステムの処理動作および料金支払い方法について、居住者が、請求側サーバにアクセスして本サービスの申込情報を送信すると、前記のように請求側受付プロセスと給付側受付プロセスとによって、申込が受け付けられて登録される。請求側サーバにおいて、毎月定期的に請求プロセスが起動され、本サービスが適用されない居住者に対しては、電力会社から通常の料金請求書が送られる。一方、本サービスが適用される居住者に対しては、電力会社から振込済みの請求書が送られるとともに、作成した請求リストが支払い側サーバに送信される。

次に、支払い側サーバにおいて、給付月の２ヶ月ごとに給付プロセスが起動され、前記のように本サービスが適用されない受給者に対しては、自治体から別の給付書が送られる。一方、本サービスが適用される居住者に対しては、自治体から差引済みまたは別の給付書が送られ、支払いリストと不払いリストとが請求側サーバに送信され、自治体から電力会社に電気料金が支払われる。

一方、不払いリストを請求側サーバが受信すると、支払取消プロセスが起動され、不払いリストに載っている居住者に対して、前記のような別の請求書が送られる。さらに、居住者から当該月については本サービスを受けない旨の通知を受けた場合にも、支払取消プロセス２４が起動され、本サービス適用の取消が可能な場合には、当該居住者に対して振込み要の請求書が送られる。振込み要の請求書または別の請求書を受け取った居住者は、自らで電気料金を電力会社に支払う。

この料金支払いシステムによると、本サービスが適用される居住者（受給者）に対しては、年金から電気料金の支払いが可能な場合に、自治体から電力会社に電気料金が支払われ、自治体から受給者に残給付金が給付される。この場合、自治体から電力会社に自動的かつ直接的に電気料金が支払われるため、居住者が振込みや窓口持参などを行う必要がなく、支払い忘れも発生しない。

処理例２
画面７０の「役所からのお知らせ」９０をクリックした処理について、自治体からのお知らせを居住者宛てに自動作成して送付する例を概略的に説明する。図１２において、情報請求者である居住者が、モニター機器１２から画面７０の「お知らせ」９０をクリックすると、Ｓ４０においてホストサーバ２を経て自治体サーバ３にアクセスする。この「役所からのお知らせ」は、モニター機器１２を稼働した際に、図３の画面６６において自動的に表示できるようにしてもよい。

居住者は、Ｓ４１においてモニター機器１２からパスワードを入力し、お知らせ情報提供の依頼を行うと、Ｓ４２において自治体サーバ３で居住者の本人確認を行う。居住者の本人確認ができたら、自治体サーバ３は、Ｓ４３においてお知らせファイルを作成する。ファイル作成後、自治体サーバ３は、Ｓ４４においてお知らせファイルのデータを、モニター機器１２に出力する。住民がセッション内に接続を中断したら、Ｓ４５とＳ４７において、自治体サーバ３はお知らせファイルのデータを削除する。住民がセッション内に接続を中断しなければ、一定時間の経過後に、自治体サーバ３は、Ｓ４６とＳ４７において接続を中断してお知らせファイルのデータを削除する。

このお知らせファイルとは、居住者の氏名と、メッセージを有するデータテーブルである。この作成方法（Ｓ４３）を図１３で概略的に説明する。自治体サーバ３は、Ｓ５０において居住者の住民基本台帳カードの氏名、性別、住所、生年月日、住民票コードの５情報を読み込む。次に、Ｓ５１において居住者条件別メッセージの一覧テーブル（図示しない）の１行目を読み込む。この一覧テーブルとは、一連のお知らせ先の条件およびお知らせ先の要求と、表示メッセージと、表示期間と、登録吏員の部署名と、さらに登録吏員の氏名を有するデータテーブルである。

自治体サーバ３は、居住者が、読み込んだ行の条件を満たすかを住民条件参照用インターフェイスに参照しに行く（Ｓ５２）。自治体サーバ３は、Ｓ５３において条件確認結果データファイルを参照し、Ｓ５４において住民条件別メッセージ一覧テーブルの１行目の全条件が「満たす」である場合は、住民条件別メッセージ一覧テーブルの当該行のメッセージをお知らせファイル１０に書き込む。この全条件が「満たす」でない場合は書き込まない。自治体サーバ３は、Ｓ５５において条件確認結果データファイルの全ての行が終わるまで次の行を読み込み、Ｓ５４を繰り返す。この結果、Ｓ５６においてお知らせファイルが完成する。

処理例３
画面７０の「書類申請」９２をクリックした処理について、申請者である居住者は、「書類申請」９２をクリックしてから、図１４において、申請受付画面から申請用ＩＤおよびパスワードを用いてログインし（Ｓ６０）、自治体サーバ３からホストサーバ２を経て所望の申請書を表示させる（Ｓ６１）。複数枚の申請をする場合は、申請書を1通以上作成する（Ｓ６２）。作成した申請書の記入項目で、公文書の受取場所と受取方法を選択する（Ｓ６３）。Ｓ６４において本人確認を行い、モニター機器１２から申請している場合には、自動的に本人確認は完了することになる。

この本人確認において、Ｓ６４で申請書に公的個人認証を用いて電子署名を付加してもよい。電子署名を付加する場合には、ＩＣカードリーダライタに所定のＩＣカードを挿入する（Ｓ６５）。モニター機器１２には、居住者からの申請を受付けた電子申請システムの受付機能より、Ｓ６６で受付番号が付与される。複数枚を申請をした場合は、複数の受付番号が付与されることになり、居住者の申請は完了となる。この本人確認において、ＩＣカードは自治体が発行する住民基本台帳カードであっても、銀行カードやクレジットカードなどでもよい。

申請書の受取場所は、郵送や本庁／出張所を選択してもよく、自動交付機を選択してもよい。受取方法は、一括受取または個別受取を選択できる。一括受取とは、複数の公文書を請求した場合、複数の公文書が暗号化公文書データベースに揃ってから居住者に連絡をする設定のことである。

図１５は、申請書を受付けたホストサーバ２の電子申請システムにおいて受付から受付完了までの処理を示す。この電子申請システムでは、Ｓ７０で受付機能で申請を受付け、Ｓ７１で審査支援機能で形式審査し、Ｓ７２で認証基盤連携機能を活用して署名・証明書の検証を行い、すべての確認がとれた場合は、受付番号を付与し、申請を受付けた旨の通知と共にモニター機器１２に送信する（Ｓ７３）。Ｓ７４において、申請データは、申請データ配信機能を介して、公文書を発行する各自治体サーバ３の市業務システムにデータを配信する。Ｓ７１、Ｓ７２において、審査が完了しなかった場合は、居住者に申請データを差し戻しまたは、補正指示、職権訂正により修正の依頼を行なう（Ｓ７５）。申請データは申請データデータベースに、利用者情報はホストサーバ２の利用者情報データベース（図示しない）に保存される。

図１６は、居住者が、自動交付機から公文書を取得する際の処理を示す。居住者は、モニター機器１２において電子申請システムより公文書が交付できる状態になった旨の通知を受け、公文書を取得するために、自動交付機を利用することとする。居住者は本人確認のためのＩＤとパスワードを用いてログインする（Ｓ８０）。Ｓ８１において、この自動交付機にログインすると画面上に登録情報が表示されるため、その登録情報が正しいならば居住者は公文書を取得すればよい（Ｓ８３）。

ＩＣカードが必要な場合には、Ｓ８２で所定のＩＣカードリーダライタに挿入する。通常、暗号化公文書データベースから自動交付機にデータを送る場合は、公文書データ配信機能を用いている。公文書を取得する場合、公文書は暗号化されているので、ＩＣカードに格納された秘密鍵を用いて復号して公文書を取得する事になる（Ｓ８４）。

この際に、公文書を取得するための手数料が払われていないならば、自動交付機の徴収機能を用いて入金してもよい（Ｓ８５）。居住者が自動交付機で公文書を取得すると、該自動交付機から自治体サーバ３に、履歴受信機能を介して履歴情報を送る（Ｓ８６）。好ましくは、居住者が自動交付機から公文書を取得する際に、住民基本台帳カードなどを用いて公的個人認証を利用する。公文書を作成した時に用いた公開鍵に対応した秘密鍵があれば、該秘密鍵を使わないと復元できないため、この秘密鍵を持つ本人以外には暗号化された公文書を復号して取得されることがない。

処理例４
居住者の自宅における最小設置例では、モニタ機器１２、デバイスサーバ（公序良俗違反につき、不掲載）であるデバイスユニット８、電力センサ（公序良俗違反につき、不掲載）４０、２個の電流センサ（ＣＴ）および各種の線材で構成する。このシステムは、新築、既設の建物を問わずに適用でき、電気使用状況の監視専用である。既設のルータ１１は無線送信機能を有し、ホストサーバ２は構築されていると仮定する。

デバイスユニット８に電力センサ４０を接続し、ついで２個の電流センサ（ＣＴ）の２次側を電力センサ４０の本体に接続してから、２個の電流センサ（ＣＴ）の１次側を分電盤７の電線に配線する。デバイスユニット８をルータ１１に無線接続し、各種のプログラム設定を行った後には、モニタ機器１２のタブレットにおいて使用電気量、使用金額などが表示可能になる。

処理例５
居住者の自宅における別の設置例では、モニタ機器１２、デバイスサーバ（公序良俗違反につき、不掲載）であるデバイスユニット８、電力センサ（公序良俗違反につき、不掲載）４０、２個の電流センサ（ＣＴ）、赤外線カメラ、Ｌ字形のカメラステイ（図示しない）および各種の線材で構成する。このシステムは、既設の建物に適用でき、電気およびガスの使用状況の監視用である。既設のルータ１１は無線送信機能を有し、ホストサーバ２は構築されていると仮定する。

既設の建物に後付けする際に、前記の赤外線カメラをカメラステイに取り付け、該カメラが積算表示のガスメータの表示窓を常時撮影できるように、該ガスメータに近接させて固定するとともに、該カメラをデバイスユニット８にコード接続する。次に、デバイスユニット８に電力センサ４０を接続し、ついで２個の電流センサ（ＣＴ）の２次側を電力センサ４０の本体に接続してから、２個の電流センサ（ＣＴ）の１次側を分電盤７の電線に配線する。デバイスユニット８をルータ１１に無線接続し、各種のプログラム設定を行った後に、モニタ機器１２のタブレットにおいて使用電気量およびガス量、電気やガスの使用金額などが表示可能になる。

１居住者生活支援システム
２ホストサーバ
３自治体サーバ
５専門サーバ
６ビルダーサーバ
７分電盤
８デバイスユニット
１０インターネット回線
１１ルータ

デバイスユニット８の一例として、該デバイスユニットを３２ビット高速ＭＰＵを使用したセキュアＳＳＬ／ＳＳＨ搭載組込み用デバイスサーバ（図示しない）で構成すると好ましい。このデバイスサーバは、小型の正方形サイズの中にＣＰＵ、メモリー、バス型ＬＡＮチップなどのハードウェア、さらにＲＴＯＳ、ＴＣＰ／ＩＰプロトコル、セキュリティ対応ＷＥＢサーバ、ＳＮＭＰｖ２ｃなどのソフトウェアを組み込んでいる。このデバイスサーバは、内部に３２ビットのＣＰＵを持っているため、他の機器のホストＣＰＵリソースをほとんど使用することなく、その機器本体とネットワークに接続でき、ＴＣＰ／ＩＰを実装したり、処理能力の高いＣＰＵへ載せかえるなどの基本設計を見直す必要がない。

デバイスユニット８には、プログラマブルなＲＳ−２３２／ＲＳ−４８５／ＲＳ−４２２マルチプロトコルトランシーバであるデバイスを取り付けると好ましく、このデバイスは、２Ｔｘ／２ＲｘＲＳ−２３２インタフェースまたはシングルＲＳ−４８５／ＲＳ−４２２トランシーバとしてピンプログラマブルである。また、他のデバイスとして、ＲＳ−４８５およびＲＳ−４２２通信用の±１５ｋＶ、ＥＳＤ保護付き、＋３．３Ｖの低電力トランシーバであるデバイスを取り付けると好ましい。

処理例４
居住者の自宅における最小設置例では、モニタ機器１２、３２ビット高速ＭＰＵを使用したセキュアＳＳＬ／ＳＳＨ搭載組込み用デバイスサーバであるデバイスユニット８、ネットワーク対応で電力計測機能を有する電力センサ４０、２個の電流センサ（ＣＴ）および各種の線材で構成する。このシステムは、新築、既設の建物を問わずに適用でき、電気使用状況の監視専用である。既設のルータ１１は無線送信機能を有し、ホストサーバ２は構築されていると仮定する。

処理例５
居住者の自宅における別の設置例では、モニタ機器１２、３２ビット高速ＭＰＵを使用したセキュアＳＳＬ／ＳＳＨ搭載組込み用デバイスサーバであるデバイスユニット８、ネットワーク対応で電力計測機能を有する電力センサ４０、２個の電流センサ（ＣＴ）、赤外線カメラ、Ｌ字形のカメラステイ（図示しない）および各種の線材で構成する。このシステムは、既設の建物に適用でき、電気およびガスの使用状況の監視用である。既設のルータ１１は無線送信機能を有し、ホストサーバ２は構築されていると仮定する。

Claims

全国の特定地域ごとに医療、介護、学校情報を含む生活関連情報をネットワーク化するとともに、居住者側では自宅で使用する電気やガスを含むエネルギー消費に関する加工情報を受信できる居住者生活支援システムであって、各種の情報の収集と蓄積を行い、居住者のためのデータ加工とデータチェックを実施するホストサーバと、通信回線を介して公的情報をホストサーバへ送受信する自治体サーバと、通信回線を介して生活関連情報をホストサーバへ送受信する各種の専門サーバと、自宅の電気製品の接続が集まる分電盤に接続するデバイスユニットとを備え、該デバイスユニットは、通信回線を介してホストサーバと常時接続される居住者生活支援システム。
専門サーバとして、医療関連、介護・福祉関連、学校関連、支払い関連、電気・ガス関連、小売店関連、デリバリー・宅配関連、イベント関連、防犯関連、建築関連、スポーツ関連、交通関連サーバのいずれかまたは全てのサーバを包含する請求項１記載の生活支援システム。
システム構築後に独立の専門サーバを追加する際に、該専門サーバを公衆通信回線に接続すると、ホストサーバのプログラムを変更するだけで独自の生活関連情報が追加される請求項１記載の生活支援システム。
タブレットを含むモニタ機器が、自宅内でルータに無線ないし有線接続されるかまたは屋外において携帯通信機器が公衆通信回線に無線接続されることにより、これらの機器によって任意の生活関連情報を取得し、さらに自宅における過去、現在および未来の電気料金や使用電力量をリアルタイムに表示する請求項１記載の生活支援システム。
生活支援システムに追加するビルダーサーバは、ホストサーバを経由して各種の生活関連情報を各居住者へ発信し、他社との差別化を図って「見える化」としての宣伝効果を高め、この生活関連情報には、各居住者への有益情報に相当する電子広告、通販、定期メンテナンスのお知らせを含み、この生活関連情報を各居住者のモニタ機器および屋外の携帯通信機器に表示する請求項１記載の生活支援システム。