JP7250413B1 - 非常時の情報伝達システム - Google Patents

Abstract

【課題】 非常時に潜在被害者に対して高確率で非常時情報を伝達し、非常時発生から少し時間経過後に起こる輻輳の発生確率を下げること。【解決手段】 個人情報にもとづいた関係の第二・第三ユーザに対し、非常時情報管理手段[CPU1]は、非常時モードにて個人情報を検知すると共に第二・第三ユーザが選択したモダリティを検知して強制変更して非常時情報を高確率で伝達。第二・第三ユーザが操作する第二・第三コミュニケータ[Com2・Com3]は、非常時情報管理手段[CPU1]から発信される非常時情報を受信出力する手段、ユーザ安否情報入力手段、ユーザ位置情報の把握機能をもつデバイス[31,32]からのユーザ位置情報受信手段を具備。非常時発生直後からユーザのリアルタイム安否情報およびリアルタイム位置情報からなる、少情報量のユーザ現状フラグ50を、第二・第三コミュニケータ[Com2・Com3]間で相互に通信し輻輳の発生確率を下げる。【選択図】 図９

Description

本発明は、非常時の情報伝達技術に関するもので、非常時は、地震や台風などによる大雨被害・強風被害、それに伴う河川の氾濫、火災など、いわゆる災害の発生時、パンデミック等で国家的防疫が急務のとき、あるいは諸外国から人的被害のおそれのある飛翔体の飛来、諸外国による武力行使が明確化して人的被害のおそれアリとなったときなど、常態を逸したすべての状況をふくむ。

非常時で、非常となった原因からひとりでも救済しひとりでも人間の安全を確保すること、そして、そのひとりの人間の安全確保が確実となったあとに、そのひとりは、非常となった原因とその現状を自身の安全確保保持で知りたがると共に、ひとりの親族・血族・姻族関係にある家族の安否と家族がどこにいるのか確認しようとするだろう。本発明は、そういったシチュエーションにて威力を発揮する技術に関する。

＜＜モダリティ＞＞
情報伝達技術用語である”モダリティ”について記載する。”モダリティ”はしばしば用いられるが、正式な定義はない。使い方として、感覚器の視覚・聴覚・触覚に感知される主に、光・音[声]・機械振動を区別するため、これらがモダリティの異なる計測対象である、といった記述が論文等に散見される。臭覚・味覚もモダリティの延長と考えられるが、計測技術が未確立のため臭覚・味覚に関しモダリティであるといった記述がされた論文等はまだ少ない。

ここで、光・音[声]・機械振動を大きなカテゴリーのM1とし、該M1にカテゴライズされるマイナーな種を、M2；サブモダリティ、さらに該サブモダリティM2についてユーザがどういった具合に選定したかの状態を、サブモダリティM2の”選定状態”M3と、それぞれ呼称する。それらの具体例を表１に明示する。

以下本明細書にていわゆるモダリティM1、と、その下位概念サブモダリティM2、と、該サブモダリティM2における選定状態M3は前記表に例示された意味をもつ。

＜本発明の目的＞
本発明の第１目的は、非常時に国/地方自治体/市町村の危機管理担当チームが、潜在的な被災者・被害者である住民に向けて高確率で非常時となるという予測通報、非常時の緊急避難の指示通報、非常時の状態の変化や終了予測などの伝達を円滑化するためのシステムの提案を目的とする。

ここで非常時予測は、観測手段による天候物理情報・敵国ミサイル発射準備など外交情報からの未来予測であるのできわめて高度な技術・経験を要する。同様に、避難指示も指示を出すことによる不利益と比較し、どのタイミングでどの程度の避難が最適であるかを考慮せねばならずきわめて高度な技術・経験を要する。非常時終了の判断も同様である。

しかしここで、非常時の予測通報・避難指示通報・非常時の終了判断などの情報発信準備ができたとしても、それらが潜在的な被災者・被害者である住民に伝達されるかどうかは、ちょうど電話のベルが鳴動しても受話器をとらないことと同様の問題がある。発明者らはここに注目し情報伝達が完遂される確率をあげることを第一目的とした。

そして非常時直後には、伝達すべき情報が被災者・被害者の安否確認や所在確認などへ変化する。この安否確認や所在確認を求める人数は膨大になる恐れがあり、いわゆる輻輳という現象が起こりやすい。発明者らはこの輻輳の起きる確率を減らすことを第二目的とした。

[補足] 前記第一目的で、「電話のベルが鳴動しても受話器をとらない」とは旧態の電話での表現である。受話は、受話器をとることであり、英語ではpick up であり、鳴動は、ベルのリンギング、callingを指す。旧態電話に対して、近年普及したスマートフォンでは受話器などないので、「応答」という一言で記述するしかなくわかりにくい。そのため明確化のために「ベル鳴動」や「受話器をとらない」と表現した。

＜先行技術調査＞
J-PLATPATならびにGoogleを利用して、本発明のキーワードである“個人情報”や”輻輳”が本発明の適用フィールドである災害時の通信に関して記載された情報伝達システムの先願特許、ならびに、本発明のキーワードである“個人情報”や”輻輳”が本発明の適用フィールドである災害時の通信に関して記載がある情報伝達システムに関する公開ウェッブのドキュメントを調査した。(調査の実施日は、2022年8月12日および同年８月25日)

調査の結果、本発明に関する先行技術、ならびに、本発明内容を示唆する記述を含む先願特許も公開ウェッブ情報も発見できなかった。ただし、本発明を説明するのに有効な特許群、非特許文献群を発見したので、本発明者らによる特許文献１とともに以下に記す。これらを詳細な説明にて引用する。

特許6952925号公報[概ね同一発明者による情報伝達System] 特許6952925号公報[GPS利用災害時安否確認システム] 特開2017-069593号公報[災害発生時の個人情報利用概念] 特開2013-222305号公報[災害時に要援護者の所在を伝達] 特開2015-012386号公報[複数通信システムで輻輳発生回避] 特開2013-187580号公報[少ない通信トラフィックで安否伝達] 特許7029757号公報[慶應・NTT]通信システム及び加入者線端局装置 特許6975748号公報[ソフトバンク]制御装置、プログラム、・・方法 特許6975748号公報[ソフトバンク]制御装置、プログラム、・・方法 特開2013-222305号公報[情・シス研究機構]災害時の個人情報利用技術 特務機関" Nerv"防災アプリ URL https://"Nerv".app/supporters.html スケジューリングアルゴリズムWeblio辞書、URL https://www.weblio.jp/wkpja/content/スケジューリング_スケジューリングアルゴリズム 読売新聞2022年8月12日朝刊特別面"防災ニッポン：就学前施設"

＜＜本案の技術分野＞＞
特許文献２は、GPS利用災害時安否確認システム、特許文献３および特許文献１０は、災害発生時の個人情報利用概念、特許文献４は、災害時に要援護者の所在を伝達する技術である。また、特許文献５は複数通信システム利用、特許文献６は少ない通信トラフィックで安否伝達して災害後の輻輳回避を意図した技術である。

また輻輳に関する技術の特許文献７から９も公知である。これらは、たとえば非特許文献２に詳しく説明されているスケジューリングアルゴリズムを応用すると有効である。

他方、非特許文献１は特務機関”Nerv”[ネルフ]の防災アプリであり、株式会社ゲヒルンが管理運営するサポーターズクラブ制度にて無広告で災害情報をユーザに提供するものである。この非特許文献１の技術が本案に近いものである。もちろん特許文献１から１０の技術も、本案と関係しており、本案はそれら技術を利用しているとされてよい。

非特許文献１のアプリのユーザは一般人であって特務機関”Nerv”の防災アプリを気に入ってダウンロードしたヒトで、そのヒトが持つスマホ等端末がコミュニケータである。該コミュニケータの表示例を図１に示す。[図１(a)は汎用画面、(b)(c)は2022年防災の日の非常事態速報]

”Nerv”の情報は、気象庁[防災気象情報・地震情報(緊急地震速報)]、消防庁[火災情報]等々から得たモノであり、これら情報提供するシステムを一括して”非常時情報統括管理システム[CPU-Em]”と仮称する。”Nerv”自体の操作はゲヒルン株式会社のスタッフが担っており、”Nerv”は半自動で”非常時情報統括管理システム[CPU-Em]”から得られる情報を整理してわかりやすい出力形態にするシステムであって、ハードウェアは中規模以上のコンピュータである。

＜＜本発明に至った経緯＞＞
本発明は、同時出願人先願である特許文献１の実用化にあたって、災害対策を目標として検討して発明に至った。一般に提供される形態は、非特許文献１の防災アプリ”Nerv”に例示されるモノと同様である。実用化検討の初期には教育、医療、および、商品販売の分野を実用化ターゲットとしていた[表２・表３参照]。本発明に至った経緯を説明する。

特に教育、医療の分野での実用化は極めてむずかしい。その理由のキーワードは、個人情報・プライバシーで、これらは個人の中で保護され一般公開を避けるべきものである。実用化の困難理由が個人情報・プライバシーであることを説明する。

表２のCase.Aは、強者である教師から弱者である生徒に情報伝達するケースである。この場合、教育熱心な教師であればあるほど質がよい生徒個人情報、多くの生徒個人情報をもっているだろう。したがって、何か生徒に連絡したいとき、その生徒の個人情報からわかる「これなら受話するだろう」呼出しをすれば、生徒が応答する確率は上がる。すなわち、第一から第二ユーザへの情報伝達の達成確率は上がる。

[再補足] 前補足同様、「受話するだろう」や「呼出し」は旧態の電話用語である。受話は、受話器をとることであり、英語ではpick up であり、呼出しは、ベルのリンギング、callingを指す。旧態電話に対して、スマートフォンでは受話器などないので「応答」という一言で記述するしかない。ここでは意味明確化のため「受話」や「呼出し」を用いて説明を続ける。

表２のCase.Bは、強者である医師や介護者から弱者である患者・被介護者に情報伝達するケースである。この場合、治療熱心な先生であればあるほど質がよい患者個人情報、多くの被介護者個人情報をもっているだろう。したがって、何か患者や被介護者に連絡したいとき、その患者・被介護者の個人情報からわかる「これなら受話するだろう」呼出し、たとえば患者を世話する若い看護師の声で呼び出しすれば患者が応答する確率は上がる。すなわち、第一ユーザから第二ユーザへの情報伝達の達成確率は上がる。

ここで問題はパワーハラスメントである。すなわち、強者である教師・医師・介護者に悪意をもつ弱者:生徒・患者・被介護者がいることは否定できない。この悪意をもつ者が、強者である教師・医師・介護者に対してパワハラされた、と言い出すことは否定できない。パワハラ主張が発生すると、ネット拡散され、風評被害を学校や医療法人に巻き起こす。そのため学校・医療法人の責任者はこの技術の導入許可などするはずがない。

上記が回避されるのは情報源である第一と第二の逆転、すなわち表２のCase.A´に示す、弱者である生徒から強者である教師に情報伝達するケースである。この場合は、質問の際にお気に入り教師であればあるほど気にかけてくれるアピール方法を生徒がもっており、それは教師の個人情報だろう。したがって、何か教師に質問したいとき、その教師の個人情報からわかる「これなら質問に答えてくれるだろう」呼出しをすれば、教師が応答する確率は上がる。すなわち、第一から第二ユーザへの情報伝達の達成確率は上がる。

表２のCase.B´は、弱者である患者・被介護者から強者である医師・介護者に情報伝達する同様の逆転ケースである。これは医師の治療や介護者の介護法に対してセコンドオピニオンを得たことに関する質問などであり、医師・介護者が気にかけてくれるアピール方法を患者・被介護者がもっていたとして、それは医師・介護者の個人情報だろう。したがって、何か医師・被介護者に質問したいとき、その医師・介護者の個人情報からくる「これなら質問に答えてくれるだろう」呼出しをすれば、医師・介護者が応答する確率は上がる。すなわち、第一から第二ユーザへの情報伝達の達成確率は上がる。

表２のCase.A´、Case.B´は、弱者が強者への情報伝達なので、強者が弱者からパワハラされたという気持ちにはなりにくいだろう。しかし、ごくレアケースである教師勝りの生徒、たとえば、教師職に就いたばかりの若い新任教師とその教え子の場合、または、ある青年がケガして入院し、治療にあたるのが、これまた医師職に就いたばかり若い新任医師だった場合にはパワハラ的な問題発生は否めないだろう。

しかも、Case.A´、Case.B´ケースしかおこらないような何らかの人間関係の工夫をしておいても、数年もたてば、逆転Case.A、Case.Bケースでの情報伝達がなされ、前述同様のパワハラ問題が発生するという予想は否定できない。パワハラ発生で前述同様風評被害を学校や医療法人に巻き起こす。そのため、Case.A´、Case.B´ケースしかおこらないような工夫が考えられるとしても、学校や医療法人の責任者はこの技術の導入許可をするはずがない。

他方、表３のCase.C、Case.C´ケース、生産者[販売者]と消費者の関係に注目した。Case.Cの場合、たとえば安い新製品を消費者に早く確実に情報伝達したい生産者[販売者]にて、売れた場合のメリットと、安くてよい製品をいち早く購入できた消費者のメリットが、両者ともども利益状態(いわゆるWinWin)であり、パワハラ問題の発生は少ないと考えられる。また逆転のCase.C´の場合、購買した消費者側から生産者[販売者]への伝達で、たとえば購入商品の不備へのクレームのような情報伝達である。これは強者の生産者[販売者]の販売責任にむけて、弱者である消費者が権利主張するケースであり、ハラスメントにはなりにくいだろう。いわゆるクレーマに悩まされる販売者のケースもあるが、ハラスメント発生はいまのところ低確率だろう。

そこで、生産者[販売者]と消費者の関係における情報伝達にて特許文献１の技術適用をめざした。たとえば量販店の薄利多売商品や、ブランド品販売会社の高機能高額商品を消費者へ情報提供する場合に特許文献１の技術適用を量販店、ブランド品販売会社それぞれにアピールした。

ところが、ここでプログラマー不足という別の問題に直面した。特許文献１の技術はソフトウェアでありその実用化は、プログラマーによるプログラミングによってソフト技術を既存システムにインプリメントする。たとえば、販売者量販店が消費者向けにダウンロード勧誘しているスマホアプリ、すなわち量販店商品情報テキストをプッシュ出力させるアプリのプログラムを解読し、そこに特許文献1機能を割り込んで埋め込みプログラミングする。

こういったスマホアプリのプログラミングは現在Pythonで行うのが主流である。また、ブランド品販売会社では、Youtubeを利用して消費者向けの宣伝活動をしているが、この場合でも動画再生Pythonプログラムに特許文献１の機能を割込み埋め込むことになる。

この量販店・ブランド品販売会社に当技術のモデル化テストを提案した際、相手先責任者に希少なPythonプログラマーに対して、第三者アイデアにもとづいた改変を自社運営中システムに割込み埋め込むプログラミング作業をさせる判断を強いる。希少Pythonプログラマーは自社の主体的な方針にもとづいたプログラミング作業に激多忙。相手先責任者はOkするはずはない。

こういった状況はPythonプログラマーを有する何かを販売するスタートアップベンチャーでも顕著である。自らのアイデアでベンチャー立上げであり、わけのわからない第三者アイデアのプログラミング作業に希少なPythonプログラマーをアサインするはずはない。したがって、スタートアップベンチャーに当技術をアピールして連携してモデル化を行う、もまず無理である。

以上の経緯から、生産者[販売者]と消費者の関係における情報伝達にて特許文献１の技術適用もハードルが高いとみて、最後の最後に表３のCase.D、Case.D´ケース、典型的には災害時、一般的には非常時における情報伝達へ特許文献１技術の適用による実用化を検討するに至った。この検討過程により、特許文献1の実用化の先を単に見出したのではなく、この実用化の先[非常時における情報伝達]に起因する特別な技術特徴をもつ手段を兼備した本案発明に至った。

＜＜解決しようとする課題＞＞
本案の課題は以下の２つである。まず、非常時になったこと及びどんな非常であるか、また避難必要かといった非常時情報を伝達しようとしても、たとえば呼出しベルに対して受話器取らない。その受話器取り確率を上げて非常時情報をすこしでも高い確率で受信者におくること。
２つ目の課題は、非常時で救命された場合、そのヒトがどうするかというと家族の安否確認の電話、その電話集中のためしばしば起こる輻輳。この輻輳の発生確率を少しでも下げること、以上の２つである。

＜＜本案は特許文献1発祥、それとの相違＞＞
本発明は特許文献1の実用化検討から生まれたので類似しており共通点もある。そこで新規性/進歩性の判断材料である相違点を表４に示す。表４に示すように、本案では非特許文献にない第三コミュニケータを操作する第三ユーザが存在する。この第三ユーザを規定するものが、個人情報である。

特許文献１は、第一コミュニケータから第二コミュニケータへ情報伝達。対して本案は、非常時情報管理手段[CPU１]から個人情報にもとづいた第二・第三ユーザのコミュニケータへ情報伝達である。詳しくは後述する。

＜＜本案の理解を助ける記述＞＞
＜１ 登場人物とハードウェアデバイス、それらの符号＞
本発明にかかわる人物は、第一ユーザ・第二ユーザ・第三ユーザの三者である。第一ユーザは、非常時情報管理手段のオペレータであって、この非常時情報管理手段を符号CPU１で示す。そして、第一ユーザは非特許文献1の"Nerv"のスタッフ・オペレータと共通する人物である。つまり第一ユーザは非常時における情報提供をコントロールする者であり、ゲヒルンのスタッフと共通であり、非常時情報管理手段[CPU１]の操作者ということである。図４など図面では第一ユーザをUser１、第二ユーザ・第三ユーザをUser２・User３と略記する。

非常時情報管理手段[CPU１]は、災害など非常時における被害を極力避けるよう設計した設備に守られた中規模程度のコンピュータである。非常時情報管理手段[CPU１]は、第一ユーザ[User１]の持つ端末でコントロールされる。第一ユーザ[User１]は、操作端末で時々刻々と送られてくる非常時情報統括管理システム[CPU-Em]からの非常時情報をモニターしており(時刻ｔ０)、ある時刻ｔ１で非常時を判断する。そして、非常時情報管理手段[CPU１]に非常時をデジタル的に告げ、そのことが非常時モード開始である。[図４参照]

非常時モードで非常時情報を与えられるのが第二ユーザ・第三ユーザ[User２・User３]である。第二ユーザ[User２]と第三ユーザ[User３]とは、典型的には親族・血族・姻族関係にあるいわゆる親戚の関係であり個人情報にもとづいた登場人物である。その関係は、第二ユーザ[User２]の個人情報から閲覧できる姻戚・戸籍によって第三ユーザ[User３]にたどりつける。

このように第二ユーザ・第三ユーザ[User２・User３]をどうやって一般から抽出して登場させるのか疑問におもうだろう。その作業は、個人情報統括管理システム[CPU-Priv]が担う。この個人情報統括管理システム[CPU-Priv]については明細書最後のほう＜補足２・補足３＞で説明する。

＜３D動作チャート:図２参照＞
本発明は、動作要素の動作を変化させ情報をやりとりし、時間経過したのちにあるシステムとしての機能を完遂する。動作要素の動作をなすものは、前記ハードウェアデバイス CPU１、Com２、Com３である。あるハードウェアデバイスの動作の客体は、他のハードウェアデバイスであるとともに、個人情報を得る客体として、個人情報統括管理システム[CPU-Priv]。非常時情報を得る客体として、非常時情報統括管理システム[CPU-Em]がある。

こういったハードウェアデバイスの動作を時間軸で表す図２の３D動作チャートを用いる。この３D動作チャートは、いわゆるフローチャートと同様にシステムの動作・機能を記述するものである。

３D動作チャート例：図２の３Dの[x][y][z]軸は、それぞれ[x]軸＝時間軸ｔ、[y]軸＝ハードウェアデバイスのいずれかを離隔弁別する座標軸、[z]軸＝前記個人情報統括管理システム[CPU-Priv]、非常時情報統括管理システム[CPU-Em]、そして、動作指示する第一ユーザ[User１]・第二ユーザ[User２]・第三ユーザ[User３]の三人が、ハードウェアデバイスCPU１、Com２、Com３の上位にあることを示すためZ軸で上方位置に描くことにする。

図２(a)では、第二ユーザ[User２]・第三ユーザ[User３]のコミュニケータCom２、Com３が共にスマートフォンであることをイメージさせる絵を入れた。図２(b)では、第二ユーザ[User２]・第三ユーザ[User３]のコミュニケータCom２、Com３が共に図３を用いてあとで説明する固定型コミュニケータであることをイメージさせる絵を入れた。

ここで、Com２、Com３の一方はスマートフォンで他方が固定型コミュニケータであってよく、一方が固定型コミュニケータに加えて副コミュニケータとして固定型コミュニケータと通信できるスマートフォンも操作する、であってもよい。

これら図２(a)(b)にて、前記の[x][y][z]軸の説明を簡潔に[x]軸＝時刻、[y]軸＝コミュニケータまたは手段、[z]軸＝上位の手段またはシステムと図中記載したが、詳しくは前のほうに説明したとおりである。ここで[y]軸方向に、Com２,UPU1,Com1と配置したが、これはCPU１を動作客体の可能性があるCom２・Com３で挟んで描くほうが見栄えするからで配置に意味はない。

図２で、ハードウェアデバイスの動作図示を説明する。時刻ｔ２のCPU１にて、図中に”CPU１の動作”というパネル状記載がある。ここには具体的に時刻ｔ２でのCPU１の動作が記載される。この動作は図中”CPU１(ｔ２)”と示されている。”CPU１の動作”というパネル記載の左右に矢印があり、該矢印は矢印の先であるCom２とCom３が”CPU１の動作”パネル主体の動作客体であること示す。
同様にパネル内記載がないが、時刻ｔ４のCom２の動作[“Com２(ｔ４)”]を例示した。これら”CPU１(ｔ２)” “Com２(ｔ４)”は説明用の例で無意味である。

さて、本発明を以下に列挙する。列挙のあと前述の３D動作チャートを用いて詳しく説明する。[図４～図７]
本発明は[請求項１]、第一ユーザの端末操作による非常時情報管理手段と、個人情報にもとづいた関係にある第二ユーザと第三ユーザにおいて、非常時に 第二ユーザが操作する第二コミュニケータと、 第三ユーザが操作する第三コミュニケータに非常情報を伝達するシステムであって、 前記非常時情報管理手段は、第一ユーザの端末操作により、第二および第三ユーザの個人情報を検知できる非常時モードとなり、 第二ユーザが操作する第二コミュニケータは、複数のモダリティに対応したひとつ以上の物理情報出力手段、複数のモダリティから少なくともひとつを出力として選択するモダリティ選択手段を具備し、第二ユーザが前記選択手段で出力として選択したモダリティに対応した前記物理情報出力手段で物理情報が出力されるものであり、第三ユーザが操作する第三コミュニケータも、複数のモダリティに対応したひとつ以上の物理情報出力手段、複数のモダリティから少なくともひとつを出力として選択するモダリティ選択手段を具備し、第三ユーザが前記選択手段で出力として選択したモダリティに対応した前記物理情報出力手段で物理情報が出力されるものであって、前記非常時情報管理手段は、前記非常時モードにおいて、前記モダリティ選択手段で選択されたモダリティを検知して該モダリティを前記個人情報にもとづいて強制変更するモダリティ変更手段を具備し、該モダリティ変更手段で第二または第三ユーザが選択したモダリティが他のモダリティに変更され、該モダリティに対応した前記物理情報出力手段で物理情報が出力されるものである、システムである。

本発明は[請求項２]前記の、複数のモダリティのひとつが、該モダリティに属する複数のサブモダリティからなり、前記モダリティ選択手段の選択が、ひとつのモダリティに属する複数のサブモダリティからひとつを選ぶことが前記の選択に含まれると共に、前記モダリティ選択手段の選択が、複数のサブモダリティの選定状態のなかからひとつを選ぶことも前記の選択に含まれるものであり、前記モダリティ変更手段の変更が、ひとつのモダリティに属する複数のサブモダリティ間の変更、および、前記モダリティ変更手段の変更が、ひとつのサブモダリティ選定状態から他の選定状態への変更することも前記の変更に含まれるものであり、かつまた、前記モダリティ変更手段の変更が、第二ユーザがモダリティを選択していないときに複数のモダリティのひとつを選択することも前記の変更に含まれるものである、システムである。

本発明は[請求項３]、第一ユーザの端末操作による非常時情報管理手段と、第二ユーザが操作する第二コミュニケータと、第三ユーザが操作する第三コミュニケータによる非常時に情報を伝達するシステムであって、前記非常時情報管理手段は、第一ユーザの端末操作により、第二および第三ユーザの個人情報を検知できる非常時モードとなり、第二および第三コミュニケータは、次の１項から３項に記載された手段を具備するもので、該１項から３項は、
１項 前記非常時モードにて、前記非常時情報管理手段から発信される非常時情報を受信する非常時情報受信手段、および、該受信手段で受信した非常時情報を出力する非常時情報出力手段、
２項 前記非常時モードにて、ユーザの安否情報をユーザが入力するユーザ安否情報入力手段、
３項 前記非常時モードにて、ユーザの位置情報を把握する機能をもつ位置情報把握デバイスからユーザ位置情報を受信するユーザ位置情報受信手段、であって、前記非常時情報管理手段が、前記非常時モードにて、前記２項に記載されたユーザの安否情報、および、前記３項に記載されたユーザの位置情報を組み合わせた、非常時のユーザ現状フラグを、第二コミュニケータと第三コミュニケータとで相互に通信するユーザ現状フラグ通信手段を具備した、システムである。

本発明は[請求項４]、前記のユーザ現状フラグ通信手段が、前記の第二または第三ユーザの個人情報にもとづいてスケジューリングするスケジューリングアルゴリズムによって、前記の非常時のユーザ現状フラグを相互に通信する、システムである。

本発明は[請求項５]、前に記載されたシステムにおいて、前記個人情報が、リアルタイムで変化する個人の位置情報、および／または、リアルタイムで変化する個人の安否情報をふくむものである、システムである。

本発明は[請求項６]、前に記載されたシステムにおいて、第一ユーザの端末操作によって前記非常時情報管理手段が第二および第三ユーザの個人情報を検知できる非常時モードとなった後に、第一ユーザが端末操作によって、前記非常時モードから第二および第三ユーザの個人情報が検知できず、該個人情報利用できない常態モードに戻すと共に、次のAからC項に記載された情報を第二または第三コミュニケータに伝達するもので、該AからC項は、
A項 検知した第二および第三ユーザの個人情報、
B項 A項の個人情報を用いて前記非常時情報管理手段が行った情報処理の情報、
C項 B項の情報処理で出力された物理的な情報、である、システムである。

本発明は[請求項７]、前に記載されたシステムにおいて、第二または第三コミュニケータに前記非常時情報管理手段による第二および第三ユーザの個人情報検知をできないようにして該個人情報が利用できる状態を解除する個人情報利用解除手段が兼備され、第一ユーザの端末操作によって前記非常時情報管理手段が第二および第三ユーザの個人情報を検知できる非常時モードとなった後に、前記個人情報利用解除手段を操作できる第二または第三ユーザが該個人情報利用解除手段によって、前記非常時モードを、第二および第三ユーザの個人情報検知ができず、該個人情報利用できない常態モードに戻すと共に、次のAからC項に記載された情報を第二または第三コミュニケータに伝達するもので、該AからC項は、
A項 検知した第二および第三ユーザの個人情報、
B項 A項の個人情報を用いて前記非常時情報管理手段が行った情報処理の情報、
C項 B項の情報処理で出力された物理的な情報、である、システムである。

＜＜固定タイプの Com２,Com３、図３の説明＞＞
図２でCom２,Com３が携帯可搬式のスマートフォン・携帯電話であってよい一方で、屋内自室などに置く固定タイプのコミュニケータでもよいとした。そして、これらの混合使用、すなわちUser２/User３の一方または両方が、携帯可搬式のスマートフォン・携帯電話および屋内自室などに置く固定タイプのコミュニケータの両方を操作してもよい。たとえば、スマートフォン・携帯電話を主に操作する主コミュニケータ、固定タイプコミュニケータを置いておくだけの副コミュニケータとしてもよく、主・副逆転した使い方でもよい。

スマートフォンであれば、これから図３で説明するすべての手段は内蔵されており、かつ、マンマシンインタフェースのスイッチ等入力手段、物理出力で操作者に情報認知させる出力手段はソフト的に実現可能である。

図３(b)は図３(a)と実質的に同じもので図３(b)は当コミュニケータ設計時に各手段等を文字表現したもので参考である。図３(a)(b)のデバイスは、User２/User３の一方または両方が操作する第二コミュニケータ/第三コミュニケータ[Com２/Com３]の候補である。これを操作せず、たとえば携帯可搬式のスマートフォン・携帯電話だけを第二コミュニケータ/第三コミュニケータ[Com２/Com３]としてもよい。

図３のデバイスには、以下のものが内蔵されており図３では具体的に描かれていない。すなわち、非常時情報受信手段１１、非常時のとき発音するスピーカ１４、非常時のとき振動するバイブレータ１５、そして、ユーザ位置情報を受信する手段３３であって、これらはデバイス内に内蔵されている。

非常時情報受信手段１１はCPU１からの非常時信号を受信する。非常時でないときは、非常時でないとき光る緑LED１２が点灯しているが、非常時信号受信後は非常時のとき光る赤LED１３が点灯、これは点滅もする。

同様に、内蔵された１４，１５が発音・振動することもある。これら物理出力のアレンジがモダリティのアレンジであって、個人情報にもとづいてユーザが気づきやすいモダリティに各個人が想像できないような意外性のあるアレンジに強制変更して非常時情報をより確実に伝達する[請求項１]。

図３(a)の２１から２３はユーザ安否情報をユーザ入力する手段であって、２１がユーザは安心安全のとき押す丸印スイッチ、２２がユーザは安全/危機の中間状態のとき押す三角印スイッチ、２３がユーザは危機で支援求むとき押すバツ印スイッチである。非常時にこれらの３つのOn/Offでユーザの安否に関する最少情報量とする。スマートフォン操作者には同様の３つのOn/Offタッチスイッチを表示するアプリを作成しておき、そのアプリをダウンロードしてもらえばよい。

図３(a)の３１、３２はユーザの位置情報を把握する機能をもつデバイスであって、図３が示す屋内の居室などに置く固定タイプのコミュニケータとは別の外部デバイスである。外部にある理由は、ユーザが固定タイプのコミュニケータから離れており、ユーザ位置が固定タイプのコミュニケータの位置ではないことが多いからである。

具体的には、ユーザが操作するスマートフォンや携帯機器３１である。ここで３１はユーザが主に使う主コミュニケータで屋内自室などに置く固定タイプのコミュニケータが普段は使わない副コミュニケータであってもよい。

図３(a)の３２は、ユーザ体表・体内に接触・埋設された電波発生器[ICタグなど]であり、近年高齢者徘徊問題のためにヒトである高齢者にもこういったデバイスを体表・体内に接触・埋設してユーザ位置情報を発信するようにしてもよい。そしてCom２/Com３に内蔵されたユーザ位置情報を受信する手段３３がユーザ位置を遠隔把握する。

図３(a)の４１はCPU１が発信する非常時情報を受信するアンテナであり、４２は３１,３２が発信する位置情報を受信するアンテナである。

＜＜３D動作チャート図４による説明＞＞
本案システムの動作を図４から図７で説明する。まずは図４にて、時刻ｔ０は非常時でない常態[通常の常態]の時刻であり、本案システムにとって動作準備期間の時刻といえる。この準備は図５に示したので図５の説明で触れるが、かかる準備とは、個人情報統括管理システム[CPU-Priv]に個人情報を蓄積記憶してもらう準備である。この個人情報準備については本明細書の説明の最後のほう＜補足２・補足３＞にて詳しく述べる。

図４の時刻ｔ０では、第一ユーザ[User１]が非常時情報統括管理システム[CPU-Em]が配信する非常情報等をwatching[監視]して潜在的に発生する非常時について考慮している。そして非常時と判断すると、第一ユーザ[User１]が端末操作により、第二および第三ユーザ[User１＆User２]の個人情報を検知できる非常時モードとなる。

図４の時刻ｔ１は、第一ユーザ[User１]が非常時情報統括管理システム[CPU-Em]の非常情報等から非常時と判断した時刻であって、時刻ｔ１にて第一ユーザ[User１]が非常時情報管理手段[CPU１]に対し、直前の常態モードから非常時モードに変更する指示をする。

時刻ｔ２で非常時情報管理手段[CPU１]は個人情報統括管理システム[CPU-Priv]に個人情報にもとづいた関係にある第二ユーザと第三ユーザ[User２/User３]のアサインをリクエストし、問題なければ第二ユーザと第三ユーザ[User２/User３]がアサインされ個人情報から非常時情報管理手段[CPU１]と第二・第三コミュニケータ[Com２・Com３]との情報伝達路が確立する。

時刻ｔ３では、図４に示すように非常時情報統括管理システム[CPU-Em]の非常時情報を第二・第三コミュニケータ[Com２・Com３]が受信する。ここで注意したいのは、図４にモダリティ強制変更とあるように、矢印の図示を略すが、このモダリティ強制変更は非常時情報管理手段[CPU１]が動作介在して行うものである。

それゆえ、非常時情報統括管理システム[CPU-Em]の非常時情報がそのまま第二・第三コミュニケータ[Com２・Com３]に受信されるのではなく、非常時情報管理手段[CPU１]が動作介在して、第二・第三コミュニケータ[Com２・Com３]の個人情報にもとづいて情報をアレンジする。

第二・第三コミュニケータ[Com２・Com３]は複数のモダリティに対応したひとつ以上の物理情報出力手段、複数のモダリティから少なくともひとつを出力として選択するモダリティ選択手段を具備しており、第二ユーザ・第三ユーザ[User２・User３]が前記選択手段で出力として選択したモダリティに対応した前記物理情報出力手段で物理情報が出力される。

ここで物理情報出力手段は、図３で例示した非常時でないとき光る緑LED１２、非常時のとき光り点滅もする赤LED１３、非常時のとき発音するスピーカ１４[Com２/Com３に内蔵]、非常時のとき振動するバイブレータ１５[Com２/Com３に内蔵]であり、どのように光るか、どのように発音するか、どのように振動するか、は第二ユーザ・第三ユーザ[User２・User３]が選択できる。選択の手段は可変抵抗に接続されたボリューム型スイッチなどである。スマートフォンの場合は画像で操作者に示され指タッチで変化も画像で示されるソフトスイッチである。

このようなモダリティ選択手段で選択されたモダリティを遠隔で検知する検知手段、および検知したモダリティを第二ユーザ・第三ユーザ[User２・User３]の個人情報にもとづいて強制変更するモダリティ変更手段を非常時情報管理手段[CPU１]が具備している。

このモダリティ変更手段が前記の非常時情報管理手段[CPU１]が動作介在して、第二・第三コミュニケータ[Com２・Com３]の個人情報にもとづいて情報をアレンジするのアレンジを実行する手段である。
モダリティ変更手段の動作はプログラムとして記述され、該動作がソフト的に実現される。

かかるプログラムの動作のポイントは、第二ユーザ・第三ユーザ[User２・User３]が選択したモダリティが他のモダリティに変更されることであって、該モダリティに対応した前記物理情報出力手段で物理情報が出力される[請求項１]。

たとえば、非常時のとき光る赤LED１３が、選択していないリズムで点滅する、非常時のとき発音するスピーカ１４が、選択していない音声を出す、非常時のとき振動するバイブレータ１５が振動すると選択していないのに振動するなどである。

これらの意外な物理出力発生は前記表１で定義したモダリティの強制変更によって起こされる。モダリティは詳しくは次のとおり。すなわち[請求項２]、モダリティのひとつが、該モダリティに属する複数のサブモダリティからなり、前記モダリティ選択手段の選択が、ひとつのモダリティに属する複数のサブモダリティからひとつを選ぶことが前記の選択に含まれると共に、前記モダリティ選択手段の選択が、複数のサブモダリティの選定状態のなかからひとつを選ぶことも前記の選択に含まれるものであり、前記モダリティ変更手段の変更が、ひとつのモダリティに属する複数のサブモダリティ間の変更、および、前記モダリティ変更手段の変更が、ひとつのサブモダリティ選定状態から他の選定状態への変更することも前記の変更に含まれるものであり、かつまた、前記モダリティ変更手段の変更が、第二ユーザまたは第三ユーザがモダリティを選択していないときに複数のモダリティのひとつを選択することも前記の変更に含まれるものである。

一方、図５の時刻ｔ３部分に示されているように時刻ｔ３では、第二ユーザ・第三ユーザ[User２・User３]リアルタイム個人情報を個人情報統括管理システム[CPU-Priv]にUploadすることも開始される。このリアルタイム情報は、リアルタイムで変化する個人の位置情報、リアルタイムで変化する個人の安否情報をふくむものであって[請求項５]、個人情報統括管理システム[CPU-Priv]に記憶される。この記憶動作を含む個人情報統括管理システム[CPU-Priv]の動作全貌は、明細書最後のほうの＜補足２・補足３＞を参照されたい。

ここまで説明した本案システムの効果について表５に特許文献１との対比から具体的に示した。すなわち特許文献１の進歩である表５(ａ)からの進歩[より顕著な効果]は、二人[第二・第三ユーザ]の個人情報関係にもとづいたモダリティ変更、たとえば夫婦なら共通の関心事である子息に関する音・画像・振動をもちいて受話確率を二人同時にアップできるという特許文献1では得られない効果が得られることである。[表５(ｂ)]

また、本案システムにおいて[請求項５]、個人情報が、リアルタイムで変化する個人の存在する位置、および／または、リアルタイムで変化する個人の安否をふくむものであるので、ユーザのリアルタイム位置とその時その位置の地震予想震度や台風予測経路との比較で避難必要性を判定し、特に二人のリアルタイム個人位置が近接していると判定され、かつ、リアルタイム非常事態原因位置と近接とも判定されれば二人協働避難を推奨した音・画像・振動にモダリティ変更して救命確率をあげる特許文献1では得られない効果が得られる。[表５(ｃ)]

繰り返しになるが、ユーザのリアルタイム位置とその時その位置の地震予想震度や台風予測経路との比較で避難必要性を判定、特に二人位置が近接していれば協働避難を推奨した音・画像・振動にモダリティ変更して救命確率をあげる特許文献1では得られない効果が得られる。[表５(ｃ)]

さらにまた、ユーザのリアルタイム安否にもとづいた行動、たとえば二人の一方が健全で、他方が重症のときは健全な一方に重症な他方の救助行動を推奨した音・画像・振動にモダリティ変更して他方の救命確率をあげる特許文献1では得られない効果が得られる。[表５(ｄ)]

図４の説明途中であるが、図５のｔ３について先行して触れる。
すなわち、図５の時刻ｔ３には、第二ユーザ・第三ユーザ[User２・User３]リアルタイム個人情報が個人情報統括管理システム[CPU-Priv]にUploadされることが示されている。これは、図３で示した２１から２３、すなわちユーザ安否情報をユーザ入力する手段であるユーザが安心安全のとき押す丸印スイッチ２１、ユーザが安全/危機の中間状態のとき押す三角印スイッチ２２、ユーザが危機で支援求むとき押すバツ印スイッチ２３をユーザが自己分析して入力した結果がUploadされるということである。

また、図３で示した３１、３２、４２すなわち、ユーザが操作するスマートフォンや携帯機器３１、ユーザの位置情報を把握する機能をもつデバイス３２、そして３１,３２が発信する位置情報を受信するアンテナ４２のセットでリアルタイム個人位置情報が第二・第三コミュニケータ[Com２・Com３]にて受信されるので、図５の時刻ｔ３にて、この位置情報も個人情報統括管理システム[CPU-Priv]にUploadされる。

＜＜３D動作チャート図５による説明＞＞
図５の時刻ｔ３の動作説明は終わりである。この時刻ｔ３は図４と図５で概ね同時刻であって動作も概ね同時に行われる。
図５の時刻ｔ０でも同様の概ね同時動作が行われる。図４の時刻ｔ０では、第一ユーザ[User１]が非常時情報統括管理システム[CPU-Em]の情報を監視[waｔｃhing]して非常時に相当するか否かを検討している、に対して、図５の時刻ｔ０では、第二・第三コミュニケータ[Com２・Com３]の個人情報を個人情報統括管理システム[CPU-Priv]に非常時での利用条件をつけて登録リクエストする、である。

図５時刻ｔ０記載は正しくはない。第二・第三コミュニケータ[Com２・Com３]の個人情報などないからだ。正しくは、第二ユーザ・第三ユーザ[User２・User３]が、その個人情報を個人情報統括管理システム[CPU-Priv]に非常時での利用条件をつけて登録リクエストする、であって、第二ユーザ・第三ユーザ[User２・User３]が、自ら自分の第二・第三コミュニケータ[Com２・Com３]を使って上記リクエスト操作をする代表的なリクエスト操作例を描いている。

前記登録リクエストは、何度も記載している明細書最後のほうの＜補足２・補足３＞の個人情報統括管理システム[CPU-Priv]動作に関するもので、図１０の”anyuser”Q２が第二ユーザ・第三ユーザ[User２・User３]である。

図５の説明に戻って、図５ｔ１は図４ｔ１と同じ。図５ｔ２も図４ｔ２と同じ。図５ｔ３と図４ｔ３のダブル動作は説明済みである。

＜＜３D動作チャート図６図７による説明＞＞
図６図７はペア図であって、図６は[請求項６]、非常時モードとなった後に、第一ユーザ[User１]の端末操作によって、非常時モードから第二ユーザ・第三ユーザ[User２・User３]の個人情報を検知できない常態モードに戻す、の動作を、時刻“Down loading Stop ｔ４”,“Up loading Stop ｔ４”すなわち“ｔ４-Dx”“ｔ４-Ux”と記した。

ここで言う常態モードに戻すと、“Down loading”も““Up loading”も中止[Stop]される。つまり、“Down loading”は、非常時モードにて実行される非常時情報の“Down loading”であり、“Up loading”も、非常時モードにて実行される第二ユーザ・第三ユーザ[User２・User３]のリアルタイム安否情報・リアルタイム位置情報の“Up loading”であるので、実行条件である非常時モードが解除されれば当然中止[Stop]される。

そして図６図７ペア図の他方、図７は[請求項７]、非常時モードとなった後に、新たに兼備するとした個人情報利用解除手段[６０]を第二または第三ユーザが操作して、非常時モードから第二ユーザ・第三ユーザ[User２・User３]の個人情報を検知できない常態モードに戻す、の動作を、時刻“Down loading Stop ｔ４”,“Up loading Stop ｔ４”すなわち“ｔ４-Dx”“ｔ４-Ux”と記した。

新たに兼備する個人情報利用解除手段[６０]の図示は省略する。例えば図３のデバイスであれば、非常時情報出力手段１２から１５の近傍に物理スイッチとして配設すればよいし、スマートフォンであれば、ソフトスイッチを本案システムアプリのプログラムに追記すればよい。

＜＜３D動作チャート図８による説明＞＞
図８は、非常時モードから常態モードに戻る際、前述の“Down loading”も“Up loading”も共に中止[Stop]することを×印で示し、その中止時刻は、それぞれ時刻“Down loading Stop ｔ４”である“ｔ４-Dx”と時刻“Up loading Stop ｔ４”すなわち “ｔ４-Ux”である(図６図７と同様)。
そして、“ｔ４-Dx”“ｔ４-Ux”に続く時刻ｔ５にて、次のAからC項に記載された情報を第二または第三コミュニケータ[Com２またはCom３]に伝達する。

ここでAからC項とは、A項 検知した第二および第三ユーザ[User２・User３]の個人情報、B項 A項の個人情報を用いて非常時情報管理手段[CPU１]が行った情報処理の情報、C項 B項の情報処理で出力された物理的な情報、である。

このことは、近年法整備された個人情報のトレーサビリティ確保要項に明記された、「個人情報を使った場合、どんな情報をどう使ったのかの記録を確保し数年間保存すること」、と概ね同様である。ただし、この個人情報のトレーサビリティ確保には、個人情報を使った主体の義務を明記しているが、個人情報を使われた客体、第二ユーザまたは第三ユーザ[User２またはUser３]への情報伝達の明記はない。
本案システムでは、第二または第三コミュニケータ[Com２またはCom３]という操作デバイスを通じて個人情報を使われた客体、第二ユーザまたは第三ユーザ[User２またはUser３]へトレーサブルな情報が伝達される。

また、非常時という具体的イベント直後に個人情報の利用がトレーサブルな情報を伝達すること、および、その伝達対象が個人情報を使われた客体、つまり個人情報所有者本人であることは有効で便利である。すなわち利用がなされた具体的イベント直後にその利用実態記録の本人へ伝達がきちんと行われる。このことは、近年重視される個人情報問題への具体的で有効な提案であると考える。

上記の情報伝達操作は、個人情報統括管理システム[CPU-Priv]の機能の一部で、これまた何度も書くように明細書最後のほうの＜補足２・補足３＞に記載される。その記載が引用する図１０(a)において前記のトレーサビリティの確保は個人情報利用情報記憶手段Ｐ５から個人情報利用情報送信手段Ｐ６経由して個人情報の所有者Q３への情報の流れとして示されている。

＜＜３D動作チャート図９による説明＞＞
図９は、時刻ｔ３と時刻ｔ４の間の動作であって本案システムの、少ない情報量で非常時当初なら必要十分の非常時のユーザ現状フラグ[５０]を、第二コミュニケータ[Com２]と第三コミュニケータ[Com３]とで相互通信するユーザ現状フラグ通信を示す[請求項３]。ここで時刻ｔ３は、第二ユーザ・第三ユーザ[User２・User３]が非常時の状況下でリアルタイム個人情報を個人情報統括管理システム[CPU-Priv]にUpload開始許可される時刻、時刻ｔ４は、非常時が常態化された時刻である。

リアルタイム個人情報のUploadは、第二ユーザ・第三ユーザ[User２・User３]から非常時情報管理手段[CPU１]に行ってもよい。ただし、リアルタイム個人情報は前記のトレーサビリティ確保対象なので、非常時情報管理手段[CPU１]から個人情報統括管理システム[CPU-Priv]に転送して、個人情報統括管理システム[CPU-Priv]で非常時全時間のリアルタイム個人情報をまとめて記憶する、でよい。

または、個人情報統括管理システム[CPU-Priv]でのまとめを省き、非常時情報管理手段[CPU１]が非常時全時間のリアルタイム個人情報をまとめて記憶する、でもよい。

図９時刻ｔａで、第二ユーザ[User２]が非常時の状況下でリアルタイム個人情報を個人情報統括管理システム[CPU-Priv]にUploadし、図９時刻ｔｂで、第三ユーザ[User３]がリアルタイム個人情報を個人情報統括管理システム[CPU-Priv]にUploadし、この両者第二ユーザ・第三ユーザ[User２・User３] のUploadが、繰り返され[ｔａ→ｔｂ→ｔａ→ｔｂ→・・・] 非常時が常態化される時刻ｔ４に至る。

ここで、本案システムの、少ない情報量で非常時当初なら必要十分の非常時のユーザ現状フラグ[５０]とは、前記第二ユーザ・第三ユーザ[User２・User３] のUploadデータであって、第二ユーザ・第三ユーザ[User２・User３] それぞれが以下のように作成される。すなわち、非常時モードにて、ユーザの安否情報をユーザが入力するユーザ安否情報入力手段によるユーザのリアルタイム安否情報、および非常時モードにて、ユーザの位置情報を把握する機能をもつ位置情報把握デバイスからユーザ位置情報を受信するユーザ位置情報受信手段によるユーザのリアルタイム位置情報を組み合わせたデータである。

この組み合わせデータを、非常時のユーザ現状フラグ[５０]と呼ぶ。ユーザ現状フラグ[５０]のデータ量は、非常状況における個人安否や個人位置を音声でしゃべるときの音声データのデータ量と比較すると確実に少ない。

すなわち、音声品質を落としても音声１５秒のデータ量はメガビットオーダとなる。[ 標本化周波数(Sampling Rate)を10kHz、量子化数(Bit Rate)を8ビットとして１秒間に10000×8で80キロビット、１５秒で1.2メガビット ]
それに対して、ユーザ現状フラグ[５０]では、リアルタイム安否データが〇△×で数ビット、リアルタイム位置が緯度経度の数値で緯度経度それぞれに18-19桁の精度の8バイト[64bit]に補足情報を加えた100ビットあれば充分である。よって、100キロビットオーダの音声に対して、2-300ビットなのでデータ量はきわめて少ない。

図９は、時刻ｔ３と時刻ｔ４の間の動作であって本案システムの、少ない情報量で非常時当初なら必要十分の非常時のユーザ現状フラグ[５０]を、第二コミュニケータ[Com２]と第三コミュニケータ[Com３]とで相互通信するユーザ現状フラグ通信を示す。
このユーザ現状フラグ通信の効果を確認するため簡単な効果検証シミュレーションを想定し、その結果を表６に示す。

表６は、第二ユーザ・第三ユーザ[User２・User３]の安否情報をユーザ入力する手段、丸印スイッチ２１[〇]、三角印スイッチ２２[△]、バツ印スイッチ２３[×]の押し状態が第二ユーザでは、すべて丸印スイッチ２１[〇]であり、第三ユーザは、表中に示すcaseＡにて印スイッチ２１[〇]、caseＢにて三角印スイッチ２２[△]、caseＣにてバツ印スイッチ２３[×]であるときのシミュレーションである。
caseＡで、従来電話[通話時間合計25秒、情報量相互合計２MBit]、caseＢで、従来電話[通話時間合計25秒、情報量相互合計２MBit] 、caseＣで、従来電話[通話時間合計100秒、情報量相互合計８MBit]。
それらに対して本案システムは[通信時間合計10m秒、情報量相互合計300Bit]である。

このようにデータ量は確かに少ないが、ニュアンスや気持ちといった情報量には差があるので注意が必要である。しかし、非常時の開始時刻ｔ１から短時間でユーザがリアルタイム安否入力をすれば、その時点でユーザ現状フラグ[５０]の通信がなされるので速報の意味は十分にある。

そして非常時の開始時刻ｔ１から十分時間経過したのち、ユーザが気持ちを込めた情報交換を電話等でする際に相手の位置がユーザ現状フラグ[５０]通信でわかっていれば電話通話時間も短時間になるだろう。また、相手が行方不明になった場合にも、その状況がユーザ現状フラグ[５０]通信でわかれば、捜索開始など適切な対応がより早く実施されるだろう。

＜１ ハードウェア構成その1：スマホ＞
このシステムを構築するときユーザが操作するデバイス、すなわち第二・第三コミュニケータ[Com２・Com３]構成の第１例は、ともにスマートフォンの構成である。これは既説明の図２(a)に例示される。システムはスマートフォンにダウンロードするアプリにてソフト的に実現される。つまりPythonプログラムに本案を入れ込めばよい。

かかるプログラムで、スマートフォンに下記の機能デバイスについて、その機能がユーザに判読できるよう表示させ、ユーザはその機能を表示から認知し、該表示に関わる情報を理解したうえで、なにか入力したいときその情報入力であることが表示されたソフトスイッチ画像のスイッチ位置をタッチ入力する。

ここで機能デバイスは、以下のデバイス１からデバイス３である。すなわち、
機能デバイス１：非常時であるかないかを表示するデバイス、たとえば赤・緑LED等、そして非常時のとき発音・振動するスピーカ・バイブレータ等、
機能デバイス２：ユーザ安否情報をユーザ入力するデバイス、ここで安否情報は安全・ちょっと安全かつちょっと危機・危機常態で支援求む、といった３段階、またはそれ以上の段階数でユーザが自らの状況を自己判断し選択してONするソフトスイッチ、
機能デバイス３：ユーザ位置情報をユーザのリアルタイム位置として把握する位置情報把握デバイス。

そして、スマートフォンにダウンロードするアプリに前記の機能デバイス２で入力されるユーザのリアルタイム安否情報と共に、前記の機能デバイス３で把握されるリアルタイム位置データを非常時のユーザ現状フラグ[リアルタイム安否/位置の個人情報daｔａ-seｔ５０]として非常時情報管理手段[CPU１]へ発信する非常時のユーザ現状フラグ通信デバイス５１[図示略]をPythonプログラミングする。

＜２ ハードウェア構成その2：固定型デバイス＞
構成の第２例は、図２(b)で例示される第二・第三コミュニケータ[Com２・Com３]が共に固定型の構成で、その具体例は図３で示し同図を説明する箇所で説明した。固定型とは携帯されて移動する型に対して自宅の部屋に静置する型である。

固定型デバイスの図３説明を補足すると、固定型デバイスの重要部品は、発光体１２、１３を含む内蔵されていて図示できない非常時のとき発音するスピーカ１４、非常時のとき振動するバイブレータ１５の非常時情報出力手段１２から１５である。これら出力手段が個人情報にもとづいて出力のモダリティを強制変更される。

また、固定型は自宅などの個人情報からたどることができる位置に静置されるので、GPSデバイスのような位置情報把握手段は必ずしも必要ない。しかし当然ながらユーザは自宅に固定されないので、ユーザが持つ可搬式のスマートフォン３１や、ユーザ体表に接触または体内埋め込みタイプも含むユーザ位置情報発信手段３３もユーザリアルタイム位置情報を得るため重要である。固定型はこれらリアルタイム位置情報を得る手段と組合せて使用される。

また、固定型には、前述のユーザ現状フラグ[５０]の通信状態を表示する手段(LED等)、あるいは前述の個人情報利用解除手段[６０]が兼備されてもよい。

＜３ ハードウェア構成その3：その１・その２の組み合わせ＞
本案システムの第二・第三コミュニケータ[Com２・Com３]のハードウェア構成は、前記その１で説明したスマートフォンの構成と前記その２で説明した固定型の組み合わせでもよい。たとえば、第二ユーザ[User２]の第二コミュニケータ[Com２]が前記その１で説明したスマートフォンの構成で、第三ユーザ[User３]の第三コミュニケータ[Com３]が前記その２で説明した固定型であるという構成でよい。

また、第二・第三コミュニケータ[Com２・Com３]の一方の構成が、前記その１で説明したスマートフォンと前記その２で説明した固定型とを、正コミュニケータ・副コミュニケータとして両方を操作する構成でもよい。

＜＜スケジューリングアルゴリズム その序＞＞
さて、前記のユーザ現状フラグ通信手段であるが、第二ユーザ・第三ユーザ[User２・User３]の個人情報にもとづいてスケジューリングするスケジューリングアルゴリズムによって、前記の非常時のユーザ現状フラグを相互に通信するのが好適である [請求項４] 。
表題で”その序”とした理由は、ここの記述が後述＜補足１＞の序論といえるからである。

ユーザ現状フラグ通信手段がユーザ現状フラグを相互に通信する際に、スケジューリングアルゴリズムの＜固定優先度プリエンプティブ・スケジューリング＞を直接的に適用すると有効である。また、一度直接的に＜固定優先度プリエンプティブ・スケジューリング＞を適用したのち、間接的にその他のスケジューリングアルゴリズムを適用するのも好適である。

＜固定優先度プリエンプティブ・スケジューリング＞、およびその他のスケジューリングアルゴリズムについて＜補足１＞に後述する。

＜＜リアルタイム個人情報＞＞
本案システムにおいて、前記個人情報が、リアルタイムで変化する個人の存在する位置、および／または、リアルタイムで変化する個人の安否をふくむものであるのが好適である[請求項５]。

リアルタイムで変化する個人の存在する位置とリアルタイムで変化する個人の安否を、リアルタイム個人情報と定義づける。すなわち、個人情報は免許証・保険証・住基台帳・マイナンバーカード記載の内容を指すのが一般的であるが、本案システムにおいて、上記リアルタイム個人情報を定義し、非常時における有効活用法を提案した。

＜＜個人情報トレーサブルのための工夫＞＞
本案システムにおいて、非常時から常態時へ戻す主体を二通り提案した。その第一は、第一ユーザが端末操作で戻すケースであり、その第二は、第二または第三ユーザが戻すケースである。後者ケースの場合には、第二または第三コミュニケータに前記非常時情報管理手段による第二および第三ユーザの個人情報検知をできないようにして該個人情報が利用できる状態を解除する個人情報利用解除手段の兼備を要する。

第一ケースの常態モード化は第一ユーザが実施、第二ケースの常態モード化は、第一第二ユーザが自己判断で個人情報はもう使わないでほしいとしてリクエストができるものである。

これら二つのケース共に、個人情報トレーサブルのための工夫も提案した。すなわち、第一のケースで第一ユーザが端末操作で非常時情報管理手段[CPU１]を常態モードに戻す場合も、第二のケースで第二または第三ユーザが兼備された個人情報利用解除手段で、非常時情報管理手段[CPU１]を常態モードに戻す場合も、次のAからC項に記載された情報を第二または第三コミュニケータに伝達する。

ここで、該AからC項は、A項 検知した第二および第三ユーザの個人情報、B項 A項の個人情報を用いて前記非常時情報管理手段が行った情報処理の情報、C項 B項の情報処理で出力された物理的な情報であり、これらは、個人情報の利用に対するトレーサビリティ確保のため近年法制化された項目である。

＜＜補足１ スケジューリングアルゴリズムについて＞＞
前記＜＜スケジューリングアルゴリズム その序＞＞の記述を補足して、公知の技術であるスケジューリングアルゴリズムを説明する。スケジューリングアルゴリズムは、ポリシーに従って同時かつ非同期に要求されるリソースを分配するアルゴリズムである。以下は、非特許文献２の記述を転載したものである。
[００]
スケジューリングアルゴリズムは多彩で多くの応用向けに開発がなされており、少なくとも、スレッドやプロセスにCPU時間を分配するスケジューリングアルゴリズム、パケットのトラフィックを制御するルーターのスケジューリングアルゴリズム、ハードディスクへのリード/ライト要求に関するスケジューリングアルゴリズム、プリンターのスプーリングのスケジューリングアルゴリズムなどがある。
[０１]
スケジューリングアルゴリズムの主要な目的は、リソーススタベーションを無くし、リソースの使用者間で公平さを保証することである。スケジューリングは、未処理の要求のどれに資源を割り当てるかを決定する。
[０２]
多彩なスケジューリングアルゴリズムの一部である、FIFO、最小残余時間優先、その他を紹介する。
＜FIFO＞
FIFOは最も単純なスケジューリングアルゴリズムで、キューイングをベースとしている。実行可能キューにプロセスが到着した順番にプロセスをキューイングし、先頭から順に実行する。FIFOはFCFS (Firsｔｃome, First-Served) とも呼称され、コンテキストスイッチはプロセス終了時にしか発生せず、キューの再編成も必要とされないので、スケジューリングのオーバーヘッドは最小である。長くかかるプロセスがCPUを占有することがあるので、スループットは低くなりうる。同じ理由で、ターンアラウンド時間、待ち時間、応答時間は長くなる可能性がある。優先順位付けは行わないので、プロセスのデッドラインを満たすのは難しい。優先順位付けを行わないということは、全てのプロセスが結局は完了するという意味で、スタベーションは発生しないと言える。一部プロセスが完了しない環境では、スタベーションがありうる。
[０３]
＜最小残余時間優先＞
最小残余時間優先(SRT)方式は、最短ジョブ優先(SJF)方式とも似ている。このスケジューリング戦略では、キュー内で残り処理時間の推定値が最も短いプロセスをスケジューラが選択する。これはプロセスの完了までにかかる時間についての高度な知識または評価を必要とする。あるプロセスを実行中に別のもっと短いプロセスが到着すると、動作中のプロセスは中断され(プリエンプション)、そのプロセスを2つの別々の計算ブロックに分けることになる。これはコンテキストスイッチを追加することになり、オーバーヘッドが増えることを意味する。スケジューラはキュー上の適当な位置に新たなプロセスを置かなければならず、これもオーバーヘッドを生じる。多くの場合でスループットを最大化するよう設計されている。プロセスが要求する計算資源が大きいほど、待ち時間と応答時間が増大する。ターンアラウンド時間は待ち時間と処理時間の総和なので、長くかかるプロセスは特に大きく影響を受ける。全体としての待ち時間の総和はFIFOと同程度だが、長くかかるプロセスの完了まで他のプロセスを待たせる必要はない。デッドラインに対する配慮は全くない。プログラマはプロセスがなるべく短時間で終了するよう気をつけるぐらいしかできない。スタベーションは発生しうる。特に小さなプロセスが多数動作するシステムで発生しやすい。
[０４]
＜固定優先度プリエンプティブ・スケジューリング＞
固定優先度プリエンプティブ・スケジューリング(FCFS)は、全てのプロセスに固定の優先度を付与し、その優先度順にプロセスをキューイングする。新たに高優先度のプロセスが到着すると、現に実行中だった低優先度のプロセスは中断される。オーバーヘッドは最小でもないし、極端に大きくもない。スループットの面ではFIFOスケジューリングと大差ない。待ち時間と応答時間はプロセスの優先度に左右される。高優先度のプロセスほど待ち時間と応答時間が小さくなる。デッドラインは優先度をうまく設定することで満たすことができる。低優先度プロセスではスタベーションが発生しうる。
[０５]
＜ラウンドロビン・スケジューリング＞
このスケジューラは各プロセスにある一定時間単位を割り当て、次々にその割り当てを実行させる。オーバーヘッドは比較的大きく、特に割り当てる時間単位を短くするほど大きくなる。スループットはFCFSとSJFの中間で、短いジョブはFCFSより早く完了し、長いプロセスはSJFより早く完了する。平均応答時間はよくない。待ち時間はプロセス数に依存し、平均プロセス長（時間）には依存しない。待ち時間は比較的長いので、純粋なラウンドロビンでデッドラインを守るのは難しい。優先度を設定していないので、スタベーションは決して発生しない。時間単位を割り当てる順序は、FCFSと同様プロセスの到着順である。
[０６]
＜多段キュースケジューリング＞
これは、プロセスを容易に複数のグループに分類できる場合に使われる、例えば典型的な分類はフォアグラウンド(対話型)プロセスとバックグラウンド(バッチ)プロセスである。このように分けると、それぞれ応答時間の要求がグループによって異なるので、スケジューリングに求められることがグループによって異なる。
[０７]
以上のスケジューリングアルゴリズム例を表７にまとめる。
[表７] スケジューリングアルゴリズムのまとめ

以上説明したスケジューリングアルゴリズムは、特許文献７－９に直接・間接的に応用され輻輳の発生確率を下げるものであり、本案システムにおいても前述のユーザ現状フラグ通信手段が、第二ユーザ・第三ユーザ[User２・User３]の個人情報にもとづいてスケジューリングする際に直接・間接的に応用して非常時のユーザ現状フラグを効率よく相互に通信できる。したがってこの通信効率化により輻輳の発生確率を下げる効果が得られる[請求項４] 。

＜＜補足２ 個人情報統括管理システム[CPU-Priv]の動作説明＞＞
個人情報統括管理システム[CPU-Priv]の概要を図１０(a)で説明する。個人情報登録にかかわる部分ＰＸについては後述する。

図１０(a)でＰ１は個人情報受信手段、Ｐ２は個人情報記憶手段、Ｐ３は個人情報利用リクエスト受信手段、Ｐ４は個人情報利用リクエスト許可判定手段、Ｐ５は個人情報利用情報記憶手段、Ｐ６は個人情報利用情報送信手段であって、Q１は不特定の個人、Q２は個人情報の利用者、Q３は個人情報の所有者である。

時刻ｔ０、すなわち常態時にて、不特定の個人Q１が非常時に利用する条件を許諾し、個人情報受信手段Ｐ１に自らの個人情報を送信する。これを受信したＰ１は個人情報記憶手段Ｐ２に利用条件が許諾された個人情報として記憶する。

その後非常時にて、非常時情報管理手段[CPU１]が図１０(a)での個人情報の利用者Q２として個人情報利用リクエスト受信手段Ｐ３に利用リクエストする。該リクエストが妥当か否かを個人情報利用リクエスト許可判定手段Ｐ４が判定し、利用に問題がない個人情報を個人情報記憶手段Ｐ２から選別し、個人情報間の関係性アリを考慮した第二ユーザ・第三ユーザ[User２・User３]の紐づけを含めて非常時情報管理手段[CPU１]に渡す。

その時刻がｔ２であって個人情報統括管理システム[CPU-Priv]によって記憶される個人情報群のなかから第二ユーザ・第三ユーザ[User２・User３]がアサインされ、第二ユーザ・第三ユーザ[User２・User３]が情報受信可能な第二・第三コミュニケータ[Com２・Com３]との通信路も個人情報から判明し、非常時情報管理手段[CPU１]と第二・第三コミュニケータ[Com２・Com３]との通信路が確保された。これら個人情報を利用した情報は、個人情報利用情報記憶手段Ｐ５に記憶される。

その後、図１０(a)で図示は省かれているが、時刻ｔ３からｔ４間は、第二ユーザ・第三ユーザ[User２・User３]リアルタイム個人情報が個人情報統括管理システム[CPU-Priv]に送信され、その情報も個人情報利用情報記憶手段Ｐ５に記憶される。

非常時が常態化された時刻ｔ４にて、個人情報利用情報記憶手段Ｐ５に記憶された第二ユーザ・第三ユーザ[User２・User３]個人情報利用情報は、個人情報利用情報送信手段Ｐ６によって個人情報の所有者Q３である第二ユーザ・第三ユーザ[User２・User３]本人らへと送信される。

＜＜補足３ 個人情報統括管理システム[CPU-Priv]の問題点＞＞
＜個人情報のアサインを考える＞
補足２で説明した個人情報統括管理システム[CPU-Priv]における個人情報が正しいかの検証、正しければシステムに登録、すなわち第二ユーザ・第三ユーザ[User２・User３]をアサインすることを考える。
そもそも第二ユーザ・第三ユーザ[User２・User３]の個人情報であるが、これはどのように検証されるのか。
可能性としては、公知の公的な個人情報管理データベース[CPU-Priv-X]と連携して自動検証、または、個人自ら申告した情報内容を住民基本台帳のデータ、免許証・保険証の情報のデータベースのデータ、マイナポータルシステムから得られるデータと照合して一致することでの検証であろう。

検証作業を含む個人情報統括管理システム[CPU-Priv]の動作は図１０(ｂ)を参照して以下である。まず、不特定の個人Q１が、個人情報受信手段Ｐ１に登録アクションをした際、個人情報統括管理システム[CPU-Priv]は、
(１) 登録アクションをした個人申告を前記公的な個人情報管理データベース[CPU-X]に問合せて検証依頼してその結果を待つ[図１０(ｂ)のｔ０１]、あるいは、
(１‘) たとえば住民基本台帳、免許証、保険証、マイナンバーカード等のデータベースのデータと閲覧できる姻戚・戸籍等の閲覧情報のデータと照合して一致で検証する[図１０(ｂ)のｔ０２]。
(２) 個人情報統括管理システム[CPU-Priv]は、登録アクションをした個人に対して非常時での個人情報利用許諾可否を送信、その許諾返信が登録アクションをした個人から受信された場合、本案システムでの第二ユーザ[User２]と認知する[図１０(ｂ)のｔ０３]。
(３) (２)で認知した第二ユーザ[User２]の個人情報から同様に(１)(１‘)(２)の手順で第三ユーザ[User３]を認知する。

以上の動作は図１０(b)の、ＰＸすなわちUser2/User3個人情報登録にかかわる全体、ＰＹすなわち User2/User3データ検証手段/閲覧して照合する手段、ｔ０１すなわちCPU-Priv-Xと連携して自動検証の動作、ｔ０２すなわち個人情報を個人情報から閲覧できる姻戚・戸籍等の閲覧情報と照合の動作、ｔ０３すなわち ｔ０１/ｔ０２にてUser2アサイン、User2情報からUser3アサインする動作で示される。

＜個人情報統括管理システム[CPU-Priv]の欠点＞
ここで第三ユーザ[User３]は、前記の(３)の、(２)で認知した第二ユーザ[User２]の個人情報から同様に(１)(１‘)(２)の手順で第三ユーザ[User３]を認知する手順で認知されるのだが、いわゆる血縁関係のあるものしか認知されないという欠点がある。さらに、全ての血縁関係が認知される保証はない。

個人情報とは、通常は免許証・保険証・住基台帳・マイナンバーカードに記載されたものであって、これら情報から閲覧できる姻戚・戸籍等によって、親族・血族・姻族関係にあるいわゆる親戚の関係にたどりつける可能性はあるものの、それは保証されない。つまり第二ユーザ[User２]の個人情報から姻戚・戸籍等を閲覧し、親族・血族・姻族関係にある全ての親戚の関係人物にたどりつく操作は、現状ではデジタル化されつくしてはおらず自動化困難、つまり手作業に頼らざるを得ないケースがある。

＜＜補足４ 改良型個人情報統括管理システム[CPU-Priv-S]の動作説明＞＞
＜希望登録個人情報[ID-S]＞
前記欠点を補うべく改良型個人情報統括管理システム[CPU-Priv-S]を創案した。すなわち、個人情報統括管理システム[CPU-Priv]方式では、第三ユーザ[User３]は閲覧できる姻戚・戸籍等によって、親族・血族・姻族関係にあるいわゆる親戚の関係者として登録できる可能性はあるものの全ての親戚の関係にある者の登録は保証されない。

そこで、創案とは希望登録個人情報[ID-S]、すなわち個人が自己責任で”関係”を希望申告する方式の提案である。すなわち個人が”関係”を拡張できるようにするシステムである。この個人によって拡張された個人情報を”希望登録個人情報[ID-S]”と呼ぶことにする。

＜改良型個人情報統括管理システム[CPU-Priv-S]の動作＞
希望登録個人情報[ID-S]を使った改良型個人情報統括管理システム[CPU-Priv-S]の動作は以下の(１)～(３)、と(A)、(B)である。 [図１１参照 [図１０(b)と対比]]
(１) 個人が改良型個人情報統括管理システム[CPU-Priv-S]の申請者登録と希望関係者の登録申請受付手段[S１]に登録申告アクションをする。その登録申告には希望する関係者の登録希望である希望登録個人情報[ID-S]が含まれる。その内容は以下である、すなわち
・関係者は何者か
・関係者との情報伝達において本人と該関係者間で定めたコールアップシグナルがどのようなものか
・関係者が複数の場合、それら関係者群の順位を示すのが好適である。該順位は登録希望個人が決めるのがよいが、他の決定者としてもそれが情報として記録されていればよい。ここで他の決定者は、関係者群と相互認証することは必ずしも必要としない。
(２) 改良型個人情報統括管理システム[CPU-Priv-S]は、申請者個人情報記憶手段[S２]と適切な申告であるか否か判定する判定手段[S３]を具備し、該判定手段[S３]は、希望者と希望関係の対象者との相互認証を行う。
(３) 改良型個人情報統括管理システム[CPU-Priv-S]は、(２)の相互認証のOKを得た対象者を前記申請者個人情報記憶手段[S２]に希望関係者の申告内容と共に記憶する。

図１１の着色部が、改良型の特徴である。つまり、任意の個人が第二ユーザ [User２]の候補として、登録申請をする際に、希望登録個人情報[ID-S]を付加して申請する。その希望登録個人情報[ID-S]によって第三ユーザ[User３]の候補をシステムに示し、相互認証することが特徴である。

＜第二ユーザ[User２]と第三ユーザ[User３]の認知＞
(A) 改良型個人情報統括管理システム[CPU-Priv-S]は、登録アクションをした個人について補足３の個人情報統括管理システム[CPU-Priv-S]の個人検証動作に準じた検証で合格した個人を本案システムの第二ユーザ[User２]を認知する。
(B) 改良型個人情報統括管理システム[CPU-Priv-S]は、動作(３)で記憶した希望関係者の申告内容から希望関係者個人について補足３の個人情報統括管理システム[CPU-Priv-S]の個人検証動作に準じた検証で合格した個人を本案システムの第三ユーザ[User３]を認知する。

前記(A)(B)は、補足２に記載した個人情報統括管理システム[CPU-Priv]とまったく変わらない。
個人情報統括管理システム[CPU-Priv]と同様、図１１の右側に位置するＰＸ[User2/User3個人情報登録にかかわる全体]、とりわけＰＹ[User2/User3データ検証手段/閲覧して照合する手段]の部分が、前記(A)(B)の手順を第二ユーザ[User２]向けと第三ユーザ[User３]に行う。

改良型個人情報統括管理システム[CPU-Priv-S]とした効果を表８の最右欄に示す。すなわち、いわゆる親戚だけが安否を心配する相手、どこにいるのか位置を知りたい相手ではない。たとえば恋人、親友、非親戚なのに一生涯のトモダチなどで、こういった関係の相手に"関係"を拡張できた。

この"関係"拡張の効果は、補足２[CPU-Priv]では通知できなかった恋人や友人の非常時通報を伝達でき、補足２[CPU-Priv]では通知できなかった恋人や友人の安否、位置を認知できる。さらに輻輳発生時のデータが増え、輻輳予測精度が上がる効果も期待できる。

また、拡張された関係者との情報伝達において本人と該関係者間で定めたコールアップシグナルがどのようなものか決めておけば、複数の関係者をアサインした際に、どの関係者であるかを特定することができる。

さらにまた、ひとりの第二ユーザに対する希望関係第三が複数者なら、その複数者の希望関係群に優先順位を個人情報として設定するとよい。たとえば、結婚したい異性が第一優先、ほかの単なる友達異性は優先下げて、フラグ５０通信の順番に利用する。すなわち、ユーザ現状フラグ通信手段の通信スケジューリングに利用できる。

図１２に参考図として改良型個人情報統括管理システム[CPU-Priv-S]のユーザ登録から効果の一部までのイメージを描いた。この参考図にて、左の女性の恋人が右の男性であり、この図の時点で親戚関係にない。このような親戚関係にない相手に対して記述の有効な情報伝達ができる。この参考図に記載された有効な情報伝達の内容と効果については既に説明したので割愛する。

＜＜補足５ 非常時の多元化[多数化]＞＞
ここまでは、第一ユーザがたったひとつの”非常時”を決定し、他のユーザに伝達することを説明した。しかし、非常時もピンからキリまである。非常時のたびに個人情報が上位システムに開放されるのは好ましくない。ピンキリ非常時を複数の非常時モードに切り分けることが好ましい。すなわち、たとえば非常時が軽微な非常時“序”と“破”を加えた、４段階：１常態 ２非常時”序” ３非常時“破” ４非常時”真”・・・などと多元化[多数化]して、非常時の種と地域[場所]の事情に対応した強弱づけしてもよい。その場合コミュニケータのボタンも非常時の多元化個数に合わせた数を具備すればよい。

＜＜補足６ 第二第三コミュニケータの安否申告スイッチ数増加＞＞
絶望的に重篤な非常時100からほぼ安心安全な非常時ゼロまで101段階を想定し、安否申告スイッチも〇△×の3つのみでなく数を多くし、それらをハードウェア的に物理スイッチ増設またはソフトウェア的グラフィカルスイッチ数を増やした画像表示としてユーザに利用させてもよい。また、補足５で述べた非常時の多元化[多数化]に対して第二第三ユーザが第一ユーザに対し、かかる非常時の多元化[多数化]の改善を相談できるようないわゆるSNS的な情報交換窓口をネット上に展開してシステムレベルアップしてもよい。

＜＜補足７ 非常時通信インフラ見直し改善＞＞
本案では、輻輳の問題を通信する情報量の削減によって輻輳発生確率を低減する効果を狙った。他方、輻輳解決の方法として、いわゆる”キャリア”通信インフラにたよらずにその他の通信カテゴリーを利用することが提案されている。たとえば、衛星電話あるいはアマチュア無線の通信環境を非常時に開放することである。とはいえ、これらの他の通信環境にも通信容量の限界は存在する。

ここにおいて本案の、非常時における通信すべき情報量の低減という考え方の有効性は共通であるから、その他の通信カテゴリー利用においても本案の採用が期待される。
いずれにせよ、非常時ひとりでも多く命を救うためより良い通信環境へ改善する見直しは必須だろう。早急に内閣官房や総務省が音頭をとって通信環境を議論することを祈り、議論がなされ適切提案が出たなら鋭意応援いたしたい。

本文中に記載したので再記は略す。だだしひとつだけアピールするなら、非特許文献３の読売新聞記事にあるような就学前児童が非常事態に不特定地域や不特定施設への避難で、親や保護者が子供の居場所がわからないという尋常でない心配が起こる確率が減ると考える。本案システムでは被災者リアルタイム安否と共にリアルタイム位置情報を第二ユーザ・第三ユーザ[User２・User３]相互に伝達するので、親や保護者にいち早く子供の所在地を知らしめココロの安心を早期に確保、そして、万が一児童が危機にさらされていた場合の救命確率が少しでも大きくなるだろう。

ゲヒルン株式会社提供のNerv[ネルフ] 各要素構成と時間的動作変化を３Dチャートで説明 固定タイプの Com２,Com３の試作品 本案の非常時動作をCPU-Emに関して示す３Dチャート 本案の非常時動作をCPU-Privに関して示す３Dチャート User１判断による非常時の常態化での動作を示す３Dチャート 個人情報利用解除手段による常態化を示す[請求項７] 個人情報トレーサビリティを情報保有者へ伝達する操作 ユーザ現状フラグ通信手段の 個人情報統括管理システム[CPU-Priv]の構成 改良型個人情報統括管理システム[CPU-Priv-S]の構成 改良型個人情報統括管理システム[CPU-Priv-S]での登録と効果(参考図)

CPU-Em 非常時情報統括管理システム(Em: emergency)
CPU-Priv 個人情報統括管理システム(Priv: private)
CPU-Priv-S 改良型個人情報統括管理システム(S: Shin, Superior)
CPU-Priv-X 公知の公的な個人情報管理データベース
CPU-Priv-Y 閲覧できる姻戚・戸籍等の閲覧情報
User１ 第一ユーザ
User２ 第二ユーザ
User３ 第三ユーザ
CPU１ 非常時情報管理手段
Com２ 第二コミュニケータ
Com３ 第三コミュニケータ
(１１、１４、１５、３３は、Com２/Com３に内蔵)
１１ 非常時情報受信手段[Com２/Com３に内蔵]
１２から１５ 非常時情報出力手段
１２ 非常時でないとき光る緑LED
１３ 非常時のとき光る赤LED、点滅もする
１４ 非常時のとき発音するスピーカ[Com２/Com３に内蔵]
１５ 非常時のとき振動するバイブレータ[Com２/Com３に内蔵]
２１から２３ ユーザ安否情報をユーザ入力する手段
２１ ユーザが安心安全のとき押す丸印スイッチ
２２ ユーザが安全/危機の中間状態のとき押す三角印スイッチ
２３ ユーザが危機で支援求むとき押すバツ印スイッチ
３１から３２ ユーザの位置情報を把握する機能をもつデバイス
３１ ユーザが操作するスマートフォンや携帯機器
３１ ユーザがCom２も操作なら３１は主コミュニケータでCom２は副コミュニケータ
３２ ユーザ体表・体内に接触・埋設された電波発生器[ICタグなど]
３３ ユーザ位置情報を受信する手段[Com２/Com３に内蔵]
４１ CPU１が発信する非常時情報を受信するアンテナ
４２ ３１,３２が発信する位置情報を受信するアンテナ
５０ 非常時のユーザ現状フラグ[リアルタイム安否/位置の個人情報data-set]
５１ ユーザ現状フラグ通信手段[Com２/Com３に内蔵]
６０ 個人情報利用解除手段[図示は略す]
[x] 時刻の座標軸
[y] 要素[CPU１,Com２,Com３]を示す軸
[z] 要素に対する上位要素下位要素を示す軸
ｔ０ CPU-Privに個人情報管理委任・CPU-Emは非常時情報を発信
ｔ１ User１がCPU-Em情報等から非常時と判断した時刻
ｔ２ CPU-PrivによってUser２個人情報からUser３をアサイン
ｔ３ User２/User３のリアルタイム個人情報がCPU-PrivにUpload開始
ｔ４ 非常時が常態化された時刻
ｔ５ A項B項C項の情報をCom２またはCom３に伝達する
ｔａ ｔ３とｔ４の間に行うCom２からCom３へ通信するステップ時刻
ｔｂ ｔ３とｔ４の間に行うCom３からCom２へ通信するステップ時刻
ｔｃ ｔ３とｔ４の間に行うCom２・Com３相互通信の繰り返しステップ
ｔ０１ CPU-Priv-Xと連携して自動検証
ｔ０２ 個人情報を個人情報から閲覧できる姻戚・戸籍等の閲覧情報と照合
ｔ０３ ｔ０１/ｔ０２にてUser2アサイン、User2情報からUser3アサイン
Ｐ１ 個人情報受信手段
Ｐ２ 個人情報記憶手段
Ｐ３ 個人情報利用リクエスト受信手段
Ｐ４ 個人情報利用リクエスト許可判定手段
Ｐ５ 個人情報利用情報記憶手段
Ｐ６ 個人情報利用情報送信手段
ＰＸ User2/User3個人情報登録にかかわる全体
ＰＹ User2/User3データ検証手段/閲覧して照合する手段
Q１ 不特定の個人
Q２ 個人情報の利用者
Q３ 個人情報の所有者
S１ 申請者登録と希望関係者の登録申請受付手段
S２ 申請者個人情報記憶手段
S３ 申請者とその希望関係者との相互認証手段
S４ User２/User３認定手段
S５ 複数希望関係者[複数の第三ユーザ[User３]]の順位記憶手段

Claims (5)

1. 第一ユーザの端末操作による非常時情報管理手段と、個人情報にもとづいた関係にある第二ユーザと第三ユーザにおいて、非常時に
   第二ユーザが操作する第二コミュニケータと、
   第三ユーザが操作する第三コミュニケータに非常情報を伝達するシステムであって、
   前記非常時情報管理手段は、第一ユーザの端末操作により、
   第二および第三ユーザの個人情報を検知できる非常時モードとなり、
   第二ユーザが操作する第二コミュニケータは、複数のモダリティに対応したひとつ以上の物理情報出力手段、複数のモダリティから少なくともひとつを出力として選択するモダリティ選択手段を具備し、第二ユーザが前記モダリティ選択手段で出力として選択したモダリティに対応した前記物理情報出力手段で物理情報が出力されるものであり、
   第三ユーザが操作する第三コミュニケータも、複数のモダリティに対応したひとつ以上の物理情報出力手段、複数のモダリティから少なくともひとつを出力として選択するモダリティ選択手段を具備し、第三ユーザが前記モダリティ選択手段で出力として選択したモダリティに対応した前記物理情報出力手段で物理情報が出力されるものであって、
   前記非常時情報管理手段は、前記非常時モードにおいて、第二コミュニケータおよび第三コミュニケータのモダリティ選択手段で選択されたモダリティを検知して該モダリティを前記個人情報にもとづいて強制変更するモダリティ変更手段を具備し、該モダリティ変更手段で検知したモダリティがその他のモダリティに変更され、変更されたモダリティに対応した第二コミュニケータおよび第三コミュニケータの物理情報出力手段で物理情報が出力されるものである、システム
   
2. 前記の、複数のモダリティのひとつが、該モダリティに属する複数のサブモダリティからなり、第二コミュニケータおよび第三コミュニケータのモダリティ選択手段の選択が、ひとつのモダリティに属する複数のサブモダリティからひとつを選ぶことが前記の選択に含まれると共に、第二コミュニケータおよび第三コミュニケータのモダリティ選択手段の選択が、複数のサブモダリティの選定状態のなかからひとつを選ぶことも前記の選択に含まれるものであり、前記モダリティ変更手段の変更が、ひとつのモダリティに属する複数のサブモダリティ間の変更、および、前記モダリティ変更手段の変更が、ひとつのサブモダリティ選定状態から他の選定状態への変更に含まれるものであり、
   さらに加えて、前記モダリティ変更手段の変更が、第二ユーザまたは第三ユーザがモダリティを選択していないときに複数のモダリティのひとつを選択することも前記の変更に含まれるものである、請求項１に記載されたシステム。
   
3. 請求項１に記載されたシステムにおいて、前記個人情報が、
   リアルタイムで変化する個人の位置情報、および／または、リアルタイムで変化する個人の安否情報をふくむものである、システム。
   
4. 請求項１に記載されたシステムにおいて、
   第一ユーザの端末操作によって前記非常時情報管理手段が第二および第三ユーザの個人情報を検知できる非常時モードとなった後に、
   第一ユーザが端末操作で、前記非常時モードから第二および第三ユーザの個人情報が検知できず、第二および第三ユーザの個人情報の利用ができない常態モードに戻すと共に、次のAからC項に記載された情報を第二または第三コミュニケータに伝達するもので、該AからC項は、
   A項 検知した第二および第三ユーザの個人情報、
   B項 A項の個人情報を用いて前記非常時情報管理手段が行った情報処理の情報、
   C項 B項の情報処理で出力された物理的な情報、である、システム。
   
5. 請求項１に記載されたシステムにおいて、第二または第三コミュニケータに前記非常時情報管理手段による第二および第三ユーザの個人情報の検知ができないようにして第二および第三ユーザの個人情報が利用できる状態を解除する個人情報利用解除手段が兼備され、
   第一ユーザの端末操作によって前記非常時情報管理手段が第二および第三ユーザの個人情報を検知できる非常時モードとなった後に、
   前記個人情報利用解除手段を操作できる第二または第三ユーザが該個人情報利用解除手段で、前記非常時モードから第二および第三ユーザの個人情報の検知ができず、第二および第三ユーザの個人情報を利用できない常態モードに戻すと共に、次のAからC項に記載された情報を第二または第三コミュニケータに伝達するもので、該AからC項は、
   A項 検知した第二および第三ユーザの個人情報、
   B項 A項の個人情報を用いて前記非常時情報管理手段が行った情報処理の情報、
   C項 B項の情報処理で出力された物理的な情報、である、システム。
   
   

Images