(57)【要約】      （修正有）【課題】緊急イベントの処理の迅速性を高め、処理コストや設備コストを増加させることなく、緊急イベント処理の迅速性を高める。【解決手段】イベント情報１２を受けると、緊急処理プログラム８は、ＯＳ上でイベント情報を処理する通常処理プログラム６をスキップしてイベント情報１２が緊急イベントであるかを判断し、イベント情報１２が緊急イベントであれば、緊急イベント情報が送出され、デバイス制御部１０の通常処理プログラム６の出力に用いる通常処理チャネル１４から緊急処理プログラム８の出力に用いる緊急処理チャネル１６に切り換えられ、緊急イベント出力が緊急処理チャネル１６から送出される。【選択図】図１
2013196192.tif 000002
【特許請求の範囲】
【請求項１】
イベント情報を受け、該イベント情報をＯＳ（Operating System）上で処理する通常処理プログラムと、
前記通常処理プログラムをスキップして前記イベント情報が緊急イベントであるかを判断し、前記イベント情報が緊急イベントであれば、緊急イベント出力を生成する緊急処理プログラムと、
前記通常処理プログラムの出力に用いる通常処理チャネルと、前記緊急処理プログラムの出力に用いる緊急処理チャネルとを持ち、前記緊急イベントである場合に前記通常処理チャネルから前記緊急処理チャネルに切り換え、前記緊急処理プログラムから受けた前記緊急イベント出力を前記緊急処理チャネルから送出する制御部と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記通常処理プログラムの処理で前記緊急イベント出力の送出ができる場合、前記緊急イベント出力を送出中の前記緊急処理チャネルを前記通常処理チャネルに切り換え、前記通常処理プログラムから前記緊急イベント出力を送出する、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
さらに、前記緊急イベントの処理を解除する解除手段と、
を備えることを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
さらに、前記制御部から送出される前記緊急イベント出力で駆動するデバイスと、
を備えることを特徴とする請求項１ないし３のいずれかに記載の情報処理装置。
【請求項５】
イベント情報によりデバイスを動作させる情報処理装置のプログラムであって、
前記イベント情報を受け、該イベント情報をＯＳ（Operating System）上の通常処理プログラムで処理し、
前記通常処理プログラムの処理をスキップして前記イベント情報が緊急イベントであるかを判断し、イベント情報が緊急イベントであれば、緊急イベント出力を生成し、
前記通常処理プログラムの出力に用いる通常処理チャネルと、前記緊急処理のプログラムの出力に用いる緊急処理チャネルとが設定され、前記緊急イベントである場合に前記通常処理チャネルから前記緊急処理チャネルに切り換え、前記緊急処理プログラムから受けた前記緊急イベント出力を前記該緊急処理チャネルから送出する、
処理を前記情報処理装置に実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、緊急地震速報など、リアルタイム性が要求されるイベント情報を処理する情報処理装置およびそのプログラムに関する。
【背景技術】
【０００２】
緊急地震速報など、緊急性のあるイベント情報はユーザに迅速に伝えられることが必要である。緊急性のあるイベント情報が断続的に繰り返される場合にも、各イベント情報が間断なく順次にユーザに通知されることも必要である。つまり、イベント情報を受けた時点と、ユーザが認識し得る時点との間に時間差が無いことが必要である。
【０００３】
このようにリアルタイム性が要求されるイベント情報の処理に関し、事件信号の検出時に実行中のオペレーションから、別のオペレーションに切り替えることが知られている（たとえば、特許文献１）。また、リアルタイムＯＳ（Operating System）で実行されるタスクを事務処理ＯＳで実行されるタスクよりも優先させ、１つの入出力装置を複数のＯＳが共有することが知られている（たとえば、特許文献２）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−７３０２５号公報
【特許文献２】特開２０００−３３０８０６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
緊急地震速報などの緊急イベントはたとえば、携帯端末装置に通知される。図２１は、この携帯端末装置２００を示している。緊急イベント２０２を受信すると、緊急イベント２０２を制御プログラム２０３の受信ハンドラ２０４で受け、アプリケーションプログラム（以下「アプリケーション」と称する）２０６の緊急イベント用アプリ（アプリケーションプログラム）２０８に通知される。受信ハンドラ２０４はファームウェアプログラムである。アプリケーション２０６はＯＳ（Operating System）上で実行されるプログラムである。緊急イベント用アプリ２０８の起動は、他の通常イベントを処理する複数のアプリ（アプリケーションプログラム）２１２（ＡＰＰ１）、アプリ２１４（ＡＰＰ２）と同様にスケジューラ２１０で管理されている。
【０００６】
この緊急イベント用アプリ２０８の処理出力がデバイス制御部２１６を通して通知デバイス２１８に与えられる。通知デバイス２１８はユーザに対してメッセージを発する。通知デバイス２１８がディスプレイやＬＥＤ（Light Emitting Diode）であれば、その緊急イベント２０２のメッセージ表示が出力される。通知デバイス２１８がスピーカやバイブレータであれば緊急イベント２０２が音声や振動として出力される。
【０００７】
斯かる構成では、緊急イベント用アプリ２０８を起動する優先度を上げたとしても、既に起動中のアプリ２１２、２１４の動作による影響を受けるなど、緊急イベント２０２の受信からユーザ通知までに時間を要する。
【０００８】
また、ユーザへの通知デバイス２１８を制御するデバイス制御部２１６ではアプリ２１２またはアプリ２１４が実行していれば、緊急イベント２０２の処理が阻まれる。つまり、緊急イベント２０２を受信しても、アプリ２１２またはアプリ２１４が実行中であれば、その処理の終了を待って緊急イベント用アプリ２０８を実行するか、その処理を中断して緊急イベント用アプリ２０８の実行に切り替える必要がある。アプリ２１２またはアプリ２１４が実行していなくても、スケジューラ２１０の管理下での起動が必要である。このような処理を経なければ、緊急イベント２０２の処理出力がデバイス制御部２１６に提供されないし、このような処理を経て通知デバイス２１８が駆動される。緊急イベント２０２を受信しても、通知デバイス２１８に緊急イベント２０２が通知されるまでには、既述のような処理を経なければならない。
【０００９】
また、緊急イベント２０２の第一報に続いて第二報が連続して到来した場合には、第一報の処理が完了しなければ、第二報の処理ができないことになる。単一の緊急イベント２０２の処理時間による遅延が、連続した緊急イベント２０２では加重され、緊急性が損なわれる。
【００１０】
このようにスケジューリング処理を介在させた処理では、緊急イベントの緊急性がその分だけ損なわれ、処理の即時性が阻害される。
【００１１】
また、リアルタイム性を向上させるために、通常アプリ実行用ＯＳとは別に緊急イベント実行用ＯＳ（リアルタイムＯＳなど）を用いる処理（たとえば、特許文献２）では、緊急イベント発生時、通常アプリ実行用ＯＳから緊急イベント実行用ＯＳに切り替えている。このような処理ではシステム構築用のコストアップや、ＯＳコンテキスト切換え時にオーバーヘッドが生じるなどの課題がある。
【００１２】
そこで、本開示の情報処理装置およびそのプログラムの目的は、上記課題に鑑み、緊急イベントの処理の迅速性を高めることにある。
【００１３】
また、本開示の情報処理装置およびそのプログラムの他の目的は、上記課題に鑑み、処理コストや設備コストを増加させることなく、緊急イベント処理の迅速性を高めることにある。
【課題を解決するための手段】
【００１４】
本開示の構成は、通常処理プログラム、緊急処理プログラムおよび制御部を備える。通常処理プログラムは、イベント情報を受け、ＯＳ（Operating System）上で前記イベント情報を処理する。緊急処理プログラムは、前記通常処理プログラムをスキップして前記イベント情報が緊急イベントであるかを判断し、前記イベント情報が緊急イベントであれば、緊急イベント出力を生成する。制御部は、前記通常処理プログラムの出力に用いる通常処理チャネルと、前記緊急処理プログラムの出力に用いる緊急処理チャネルとを備えている。前記イベント情報が緊急イベントである場合に前記通常処理チャネルから前記緊急処理チャネルに切り換えられる。制御部は、前記緊急処理プログラムからダイレクトに受けた前記緊急イベント出力を前記緊急処理チャネルから送出する。
【発明の効果】
【００１５】
本開示の情報処理装置およびそのプログラムによれば、次のいずれかの効果が得られる。
【００１６】
(1) ＯＳ上でイベント情報を処理する通常処理プログラムの処理をスキップしてイベント情報が緊急地震速報などの緊急イベントであるかを判断し、緊急イベント出力を送出するので、緊急イベントの処理を高速化できる。
【００１７】
(2) 緊急イベントの受信からデバイス動作までの時間を短縮できる。
【００１８】
(3) ＯＳ上で実行される通常処理プログラムの処理のスキップ化と、緊急イベント出力のダイレクト処理により、処理コストや設備コストを増加させることなく、緊急イベント処理を迅速化できる。
【００１９】
そして、本発明の他の目的、特徴及び利点は、添付図面及び各実施の形態を参照することにより、一層明確になるであろう。
【図面の簡単な説明】
【００２０】
【図１】第１の実施の形態に係る制御プログラムを示す図である。
【図２】制御プログラムの処理手順を示すフローチャートである。
【図３】第２の実施の形態に係る制御プログラムを示す図である。
【図４】緊急イベント処理の構成例を示す図である。
【図５】緊急イベント処理から通常イベント処理へと切替えた場合の構成例を示す図である。
【図６】通常イベント処理の構成例を示す図である。
【図７】携帯端末装置のハードウェア構成を示す図である。
【図８】携帯端末装置の一例を示す図である。
【図９】受信データフォーマットの一例を示す図である。
【図１０】緊急イベントのユーザ通知の一例を示す図である。
【図１１】緊急イベントの処理手順の一例を示すフローチャートである。
【図１２】緊急処理出力の一例を示すフローチャートである。
【図１３】通常アプリ入出力ＣＨへの切替え処理の一例を示すフローチャートである。
【図１４】緊急イベント処理の解除の処理手順を示すフローチャートである。
【図１５】緊急イベント処理の処理シーケンスを示す図である。
【図１６】緊急イベントが輻輳した場合の処理シーケンスを示す図である。
【図１７】通常イベント処理の処理シーケンスを示す図である。
【図１８】緊急イベント処理の高速化を示す図である。
【図１９】第３の実施の形態に係るカメラ起動の処理手順の一例を示すフローチャートである。
【図２０】他の実施の形態に係る緊急イベント処理の構成例を示す図である。
【図２１】従来の携帯端末装置での緊急イベントの処理を示す図である。
【発明を実施するための形態】
【００２１】
〔第１の実施の形態〕
【００２２】
＜制御プログラム＞
【００２３】
図１は、第１の実施の形態に係る制御プログラムを示している。図１に示す構成は一例であって、斯かる構成に本開示の情報処理装置およびそのプログラムが限定されるものではない。
【００２４】
この制御プログラム２は、本開示の情報処理装置で実行されるプログラムの一例であり、情報処理装置としてたとえば、携帯端末装置４（図７）で実行される。この制御プログラム２には通常処理プログラム６、緊急処理プログラム８およびデバイス制御部１０が含まれている。
【００２５】
イベント情報１２には緊急情報のほか、各種の処理情報が含まれる。ここで、緊急情報とは緊急地震速報など、リアルタイム性が要求される情報である。
【００２６】
このイベント情報１２の受信などの生起により、このイベント情報１２が通常処理プログラム６および緊急処理プログラム８の双方に加えられる。通常処理プログラム６は、基本ソフトウェアの一例である。すなわち、通常処理プログラム６はＯＳ（Operating System）上で実行される。この通常処理プログラム６では、イベント情報１２を受け、イベント情報１２を受けた順に通常イベント情報を生成する。つまり、通常イベント情報はスケジューリング処理下で生成される。この場合、イベント情報１２が緊急イベント情報であったとしても、通常処理プログラム６では通常の順次処理で処理される場合であってもよいし、緊急イベント情報を優先的に処理してもよい。いずれにしても、通常処理プログラム６の実行はＯＳ上で実行される。
【００２７】
緊急処理プログラム８は、通常処理プログラム６と異なり、既述のＯＳ上で処理されるアプリケーションプログラムではなく、ファームウェアプログラムである。つまり、既述のスケジューリング処理と無関係にイベント情報１２を処理する。
【００２８】
イベント情報１２を受けた緊急処理プログラム８では、イベント情報１２が緊急イベント情報であるかを判断する。イベント情報１２が緊急イベントであれば、緊急イベント情報を送出する。
【００２９】
デバイス制御部１０は既述の通常イベント情報または緊急イベント情報に基づき、通知デバイスを駆動するデバイスドライバであり、イベント通知出力などの出力を発する出力部の一例である。通知デバイスはディスプレイ、ＬＥＤ、バイブレータ、カメラ、スピーカなどで構成される。このデバイス制御部１０は、通常処理チャネル１４と緊急処理チャネル１６とを有する。通常処理チャネル１４は、通常処理プログラム６に対する入出力を担当する。また、緊急処理チャネル１６は、通常処理チャネル１４と独立し、緊急処理プログラム８に対する入出力を担当する。
【００３０】
これら通常処理チャネル１４と緊急処理チャネル１６とを切り替えるため、チャネル切替え機能１８を備える。このチャネル切替え機能１８は、緊急処理プログラム８からダイレクトに緊急イベント情報を受け、通常処理チャネル１４から緊急処理チャネル１６に切り替える。イベント情報１２が緊急イベントである場合には、デバイス制御部１０の入出力が緊急処理チャネル１６で実行される。つまり、緊急イベント情報の処理出力が緊急処理チャネル１６から発せられる。
【００３１】
斯かる構成では、イベント情報１２が緊急イベント情報でなければ、通常処理プログラム６のスケジューリング処理（順次処理）に委ねられる。この場合、通常処理プログラム６で生成された通常イベント情報がデバイス制御部１０に入力される。通常イベント情報が通常処理チャネル１４から発せられる。
【００３２】
これに対し、イベント情報１２が緊急イベント情報であれば、緊急処理プログラム８から緊急イベント情報が送出される。緊急イベント情報は、ダイレクトにデバイス制御部１０に入力される。つまり、通常処理プログラム６によるスケジューリング処理をスキップする。緊急イベント情報がデバイス制御部１０に加えられると、チャネル切替え機能１８により、通常処理チャネル１４から緊急処理チャネル１６に切り替えられる。これにより、緊急イベント情報の処理出力が緊急処理チャネル１６から発せられる。
【００３３】
＜制御プログラム２の処理手順＞
【００３４】
図２は、制御プログラム２の処理手順を示している。この処理手順は本開示の情報処理装置のプログラムの一例である。
【００３５】
イベント情報１２を受信する（Ｓ１１）と、このイベント情報１２が通常処理プログラム６および緊急処理プログラム８に渡される。
【００３６】
緊急処理プログラム８では、通常処理プログラム６をスキップしてイベント情報１２を判断する（Ｓ１２）。イベント情報１２が緊急イベント情報であれば（Ｓ１３のＹＥＳ）、緊急処理プログラム８が緊急イベント情報を送出する（Ｓ１４）。イベント情報１２が緊急イベント情報でなければ（Ｓ１３のＮＯ）、緊急処理プログラム８の処理はＳ１１に戻る。
【００３７】
緊急イベント情報はデバイス制御部１０にダイレクトに入力される（Ｓ１５）。緊急イベント情報を受けると、緊急イベント情報を契機にチャネル切替え機能１８が動作し、通常処理チャネル１４から緊急処理チャネル１６にチャネル切替えを実行する（Ｓ１６）。デバイス制御部１０では、緊急処理チャネル１６により処理を行い（Ｓ１７）、緊急イベント情報の出力処理が実行される（Ｓ１８）。
【００３８】
通常処理プログラム６では、イベント情報１２により通常処理が実行される（Ｓ１９）。通常処理プログラム６の処理では、イベント情報１２に緊急イベント情報が含まれていても、緊急イベント情報に無関係に通常イベント情報が送出される。この通常イベント情報はスケジューリング処理により順次に処理される。その処理結果は、デバイス制御部１０に入力される。デバイス制御部１０では、通常処理チャネル１４により入出力処理が実行される（Ｓ２０）。この場合、通常イベント情報が送出される（Ｓ２１）。
【００３９】
このように、通常時には処理が通常処理プログラム６のスケジューリング処理に委ねられる。これに対し、緊急時には、通常処理プログラム６のスケジューリング処理に委ねることなく、通常処理プログラム６の処理をスキップした高速処理が実行される。この結果、緊急イベント情報の処理の高速化が図られる。
【００４０】
〔第２の実施の形態〕
【００４１】
＜制御プログラム＞
【００４２】
図３は、第２の実施の形態に係る制御プログラムを示している。図３に示す構成は一例であって、斯かる構成に本開示の情報処理装置およびそのプログラムが限定されるものではない。図３において、図１と同一部分には同一符号を付してある。
【００４３】
この制御プログラム２では、アプリケーションプログラム２２（以下「アプリケーション２２」と称する）、受信ハンドラ２４、緊急イベント受信ハンドラ２６、ユーザ通知制御機能２８およびデバイス制御部１０が含まれている。この制御プログラム２は携帯端末装置４のＣＰＵ４８（図７）で実行される。
【００４４】
アプリケーション２２は、既述の通常処理プログラム６の一例である。このアプリケーション２２にはイベント情報１２が受信ハンドラ２４を通して通知される。このアプリケーション２２にはスケジューラ３０、複数のアプリ３２−１（ＡＰＰ１）、３２−２（ＡＰＰ２）・・・３２−Ｎ（ＡＰＰＮ）、緊急イベント処理アプリ３４が設置されている。スケジューラ３０は通知されたイベント情報１２をスケジューリング処理により、アプリ３２−１、３２−２・・・３２−Ｎ、緊急イベント処理アプリ３４に配付する。アプリ３２−１、３２−２・・・３２−Ｎは対応するイベント情報１２を処理するプログラムである。緊急イベント処理アプリ３４は、緊急イベントを処理するプログラムである。これらアプリ３２−１、３２−２・・・３２−Ｎおよび緊急イベント処理アプリ３４はＯＳ上で処理され、スケジューラ３０による順次処理で実行される。緊急イベント処理アプリ３４では、緊急イベント処理をする通常イベント情報が生成され、ユーザ通知制御機能２８に出力する。
【００４５】
受信ハンドラ２４は通知デバイス３６（図７）などの周辺機器の制御に用いられるプログラムである。この受信ハンドラ２４は、アプリケーション２２と異なり、ファームウェアプログラムである。この受信ハンドラ２４には緊急イベント判別機能３８を備えている。この緊急イベント判別機能３８は既述の緊急処理プログラム８（図１）の一部を構成する。この緊急イベント判別機能３８は受信ハンドラ２４が受信したイベント情報１２が緊急イベントであるか否かを判別する。この判別にはイベント情報１２に含まれる緊急情報が用いられる（図９）。イベント情報１２が緊急イベント情報であれば、その判別結果としてイベント情報１２が緊急イベント受信ハンドラ２６に通知される。
【００４６】
緊急イベント受信ハンドラ２６は、受信ハンドラ２４と同様に通知デバイス３６（図７）などの周辺機器の制御に用いられるプログラムである。この緊急イベント受信ハンドラ２６は、アプリケーション２２と異なり、ファームウェアプログラムである。この緊急イベント受信ハンドラ２６には緊急イベントに基づく緊急イベント情報の生成機能を備えている。この生成機能により生成された緊急イベント情報はユーザ通知制御機能２８に渡される。この緊急イベント情報は後述するように緊急イベント処理アプリ３４を制御するスケジューラ３０にも通知される。
【００４７】
ユーザ通知制御機能２８は、受信ハンドラ２４および緊急イベント受信ハンドラ２６と同様にファームウェアプログラムで構成される。このユーザ通知制御機能２８は、緊急イベント受信ハンドラ２６から受けた緊急イベント情報をデバイス制御部１０に出力する。緊急イベント処理ＣＨ４２を起動している場合、通常アプリ入出力ＣＨ４０から呼び出しがあった場合の通知内容をユーザ通知制御機能２８に保留する。
【００４８】
デバイス情報制御部１０は、受信ハンドラ２４および緊急イベント受信ハンドラ２６と同様にファームウェアプログラムで構成される。このデバイス制御部１０には、既述の通常イベント情報、緊急イベント情報のいずれかまたは双方が入力される。これらは同時または異なる時期に加えられる。
【００４９】
デバイス制御部１０には、通常アプリ入出力チャネル（ＣＨ）４０と、緊急イベント処理チャネル（ＣＨ）４２とが設けられている。通常アプリ入出力ＣＨ４０は既述の通常処理チャネル１４（図１）の一例である。この通常アプリ入出力ＣＨ４０は、アプリケーション２２側の入出力処理に用いられる。緊急イベント処理ＣＨ４２は既述の緊急処理チャネル１６（図１）の一例である。この緊急イベント処理ＣＨ４２は緊急イベント受信ハンドラ２６側の緊急イベント処理の入出力に用いられる。
【００５０】
このデバイス制御部１０には、チャネル切替え機能４４が備えられている。このチャネル切替え機能４４は、緊急イベント受信ハンドラ２６で生成された緊急イベント情報をユーザ通知制御機能２８から受け、チャネル切替えを行う。この緊急イベント情報の受信を契機に通常アプリ入出力ＣＨ４０から緊急イベント処理ＣＨ４２に切り替えられる。
【００５１】
なお、緊急イベント処理アプリ３４に緊急イベント情報が通知された場合には、それを契機として緊急イベント処理アプリ３４の処理情報が通常アプリ入出力ＣＨ４０から通常イベント出力が送出される。
【００５２】
(1) 緊急イベント処理
【００５３】
図４は、制御プログラム２の緊急イベント処理を示している。図４において、図３と同一部分には同一符号を付し、機能部分を太線で強調して表示している。
【００５４】
イベント情報１２が緊急地震速報などの緊急イベント情報であれば、緊急イベントの処理をアプリケーション２２から分離した処理が実行される。これにより、イベント情報１２の受信時、緊急イベント処理の即時実行が可能となる。この緊急イベントの処理を以下に列挙する。
【００５５】
ａ）  受信ハンドラ２４がイベント情報１２を受信する。緊急イベント判別機能３８により、イベント情報１２が緊急イベント情報であるかを判別する。緊急イベント情報を受信すると、その受信を契機に緊急イベント受信ハンドラ２６が起動する。
【００５６】
ｂ）  緊急イベント情報が通知された緊急イベント受信ハンドラ２６からダイレクトにユーザ通知制御機能２８が呼び出される。このとき、アプリケーション２２の処理の同期を取るため、アプリケーション２２の緊急イベント処理アプリ３４にも緊急イベント情報が通知される。
【００５７】
ｃ）  ユーザ通知制御機能２８からチャネル切替え選択機能４４を介して緊急イベント処理ＣＨ４２の起動を行い、緊急イベントの処理を実行する。緊急イベント処理ＣＨ４２で実行された処理出力は通知デバイス３６（図７）に出力される。
【００５８】
このような通常アプリ入出力ＣＨ４０と分離された緊急イベント処理ＣＨ４２が用意された処理では次のような利点がある。
【００５９】
通常アプリであるアプリ３２−１、３２−２・・・３２−Ｎ、緊急イベント処理アプリ３４の処理に対し、緊急イベント処理の割込みが可能となる。つまり、各通知デバイス３６などのデバイスが通常アプリ入出力ＣＨ４０から起動されている場合に、緊急イベント処理ＣＨ４２からの呼び出しを行う。これにより、通常処理に割り込んで緊急イベント処理ＣＨ４２での実行を優先させることができる。この割り込み処理で緊急イベント処理を高速化できる。
【００６０】
緊急イベント処理ＣＨ４２から起動されている場合には、緊急イベント処理ＣＨ４２の起動を優先する。緊急イベント処理ＣＨ４２から起動されている場合に通常アプリ入出力ＣＨ４０から呼び出しがあった場合、通常アプリ入出力ＣＨ４０側の通知内容はユーザ通知制御機能２８に保留する。この場合、緊急イベント処理ＣＨ４２の処理が完了した後、通常アプリ入出力ＣＨ４０側の処理を再開させる。これにより、緊急イベントを優先して処理し、緊急イベントの優先性とともに、通知などの処理の信頼性が高められる。
【００６１】
(2) 緊急イベント処理から通常イベント処理への遷移
【００６２】
図５は、制御プログラム２の緊急イベント処理から通常アプリ処理への遷移を示している。図５において、図３と同一部分には同一符号を付し、機能部分を太線で強調して表示している。
【００６３】
この処理（緊急イベント処理から通常イベント処理への遷移）は、既述の緊急イベント情報が緊急イベント受信ハンドラ２６からアプリケーション２２の緊急イベント処理アプリ３４に通知されている際の処理である。既述の通り、緊急イベント情報はアプリケーション２２内の緊急イベント処理アプリ３４に通知される。
【００６４】
ａ）緊急イベント処理アプリ３４は、アプリケーション２２における処理により実行される。つまり、他に起動するアプリも無く、デバイス制御の準備が整えば、動作準備の完了となる。この時点で、緊急イベント処理アプリ３４からユーザ通知制御機能２８に準備完了を通知する。この時点では、先行している緊急イベント処理ＣＨ４２の処理に基本ソフトのアプリケーション２２側の緊急イベント処理アプリ３４が追いつき、緊急イベント処理アプリ３４でも同等の緊急イベントの通知が可能である。
【００６５】
ｂ）ユーザ通知制御機能２８からチャネル切替え機能４４に通知し、デバイス制御のためのチャネルを緊急イベント処理ＣＨ４２から通常アプリ入出力ＣＨ４０へ復帰させる。これにより、緊急イベント処理アプリ３４からの緊急イベントは通常アプリ入出力ＣＨ４０から出力される。ユーザ通知制御機能２８に既述の保留イベントがあれば、そのイベント出力も通常アプリ入出力ＣＨ４０から出力される。
【００６６】
ｃ）このようなチャネル切替えにより、通常動作となる。このとき、緊急イベント処理ＣＨ４２は、通常アプリ入出力ＣＨ４０に対する緊急イベントの先行処理の役割を終え、その後の緊急イベントの処理に備える。
【００６７】
(3) 通常イベント処理
【００６８】
図６は、制御プログラム２の通常イベント処理を示している。図６において、図３と同一部分には同一符号を付し、機能部分を太線で強調して表示している。
【００６９】
イベント情報１２が通常イベントであれば、その通常イベントが受信ハンドラ２４からアプリケーション２２に通知される。アプリケーション２２ではスケジューラ３０によるスケジューリング処理による通常処理が実行される。これにより、受信イベントに該当するアプリ３２−１、３２−２・・・３２−Ｎのいずれかが選択される。たとえば、アプリ３２−Ｎを起動した場合には、アプリ３２−Ｎからデバイス制御部１０の通常アプリ入出力ＣＨ４０で入出力が行われ、デバイス制御が実行される。
【００７０】
＜携帯端末装置４のハードウェア＞
【００７１】
図７は、携帯端末装置４のハードウェア構成の一例を示している。図７に示す携帯端末装置４は、携帯電話機やスマートフォンなどの通信機能を備える電子機器である。
【００７２】
この携帯端末装置４は既述の制御プログラム２の実行手段である。イベント情報１２を受け、緊急イベントの迅速処理を実行する。この携帯端末装置４の構成は以下の通りである。
【００７３】
無線部４６はＣＰＵ（Central Processing Unit ）４８により制御される。無線部４６はアンテナ５０を備え、基地局と無線通信を行う。この無線部４６では、緊急地震速報などのリアルタイム性を要求されるイベント情報１２を無線により受信する。
【００７４】
ＣＰＵ４８は、メモリ５２に格納された既述の制御プログラム２によりイベント処理を実行する実行主体である。つまり、制御プログラム２の実行により、ユーザ通知制御機能２８やデバイス制御部１０など各種の機能を実現する制御部を構成する。ＣＰＵ４８が実行するイベント処理には緊急イベントの解除処理も含まれる。このＣＰＵ４８には既述の無線部４６のほか、各種の機能部がバス５４により接続されている。
【００７５】
メモリ５２はたとえば、ＲＯＭ（Read-Only Memory）などの記録媒体で構成されている。記録媒体にはキャッシュメモリやハードディスクなどの記録素子が用いられる。このメモリ５２にはプログラム記憶部５６およびデータ記憶部５８を備える。プログラム記憶部５６には既述のＯＳや制御プログラム２が格納されている。データ記憶部５８には各種のデータが格納される。ＲＡＭ（Random-Access Memory）６０はワークエリアとして用いられる。既述の制御プログラム２のファームウェアプログラムは別個のプログラム記憶部に記憶してもよい。
【００７６】
入力部６２は情報入力手段の一例である。この入力部６２では無線部４６からの通知イベント以外のイベント情報１２などの入力に用いられる。つまり、解除処理の入力手段でもある。この入力部６２にはたとえば、キーボード、マウスのほか、タッチパネル（図８）であってもよい。また、この情報入力手段は、音声入出力部６４に接続されたマイクロフォン６６で構成してもよいし、カメラ６８のシャッターボタンであってもよい。
【００７７】
表示部７０は、イベント情報１２を通知する通知デバイス３６の一例である。この表示部７０はＣＰＵ４８により表示制御されるたとえば、ＬＣＤ（Liquid Crystal Display）で構成される。この表示部７０は既述の緊急イベント情報を表示する。この表示部７０の表示画面には既述のタッチパネルを設置してもよい。このようなタッチパネルであれば、情報表示を確認しながら、情報入力が行える。
【００７８】
ＬＥＤ表示部７２は、イベント情報１２を通知する通知デバイス３６の一例である。このＬＥＤ表示部７２はＣＰＵ４８により点灯制御されるたとえば、ＬＥＤ（Light Emitting Diode）を用いたインジケータである。このＬＥＤ表示部７２は既述の緊急イベント情報により点灯する。
【００７９】
バイブレータ７４は、イベント情報１２を通知する通知デバイス３６の一例である。このバイブレータ７４は、ＣＰＵ４８により駆動制御され、振動を発生する。
【００８０】
音声入出力部６４は、音声入力または音声出力に用いられる。音声入出力部６４には既述のマイクロフォン６６が接続されるとともに、スピーカ７６が接続されている。スピーカ７６は、イベント情報１２を通知する通知デバイス３６の一例である。この音声入出力部６４は、ＣＰＵ４８により駆動制御され、スピーカ７６により緊急地震速報などの通知イベントを音声に変換して出力する。
【００８１】
カメラ６８は被写体を撮影する撮像素子を備え、既述のＣＰＵ４８で制御される。画像の取得はシャッターボタンの操作によって実行される。このシャッターボタンの操作入力は既述のイベント情報１２の一態様である。
【００８２】
図８は、携帯端末装置４の構成の一例を示している。図８において、図７と同一部分には同一符号を付してある。この携帯端末装置４はたとえば、スマートフォンやタブレット端末で構成される。
【００８３】
この携帯端末装置４には長方形状の筐体７８が備えられている。この筐体７８の前面には表示部７０の表示パネル８０が設置され、その表面には既述のタッチパネル８２が設置されている。表示パネル８０の下側には入力部６２が設置されている。この入力部６２には、中央に決定キー８４を備えたカーソルキー８６が設置されている。このカーソルキー８６の下側には複数の記号キー８８が配置されている。
【００８４】
筐体７８には図示しないが、既述のＬＥＤ表示部７２、バイブレータ７４、マイクロフォン６６、スピーカ７６およびカメラ６８などの通知デバイス３６が設置されている。
【００８５】
＜イベント情報１２の受信データフォーマット＞
【００８６】
図９は、イベント情報１２のデータフォーマットを示している。図９のＡに示すデータフォーマット９０では、ヘッダ部９２とデータ部９４を備える。データ部９２はデータ部９２の識別情報で構成される。この例では、データ部９２は、イベント識別子Ａ、発信日時Ｂ、発信者Ｃ、データ種別Ｄ、その他の情報Ｅ、Ｆで構成されている。
【００８７】
イベント識別子Ａは、データ部９４のデータの緊急性を表す情報を示している。通常イベントであれば、「０」、緊急イベントであれば、「１」を割り当てる。発信日時Ｂは、イベント情報１２を発信する日時を示す情報である。発信者Ｃはイベント情報１２の発信源、所有者などの所属を表す情報である。データ種別Ｄは、データ部９４と通知デバイス３６との関係情報である。この関係情報の一例としてメッセージ表示、デバイス制御がある。データ種別Ｄがメッセージ表示であれば、データ部９４に定義されたメッセージを通知デバイス３６に表示する。デバイス制御であれば、データ部９４に定義されたデバイス制御情報により、通知デバイス３６を起動する。通知デバイス３６の起動としてはたとえば、カメラ６８の起動である。
【００８８】
データ部９４はイベント情報１２の根幹部分である。このデー部９４には、通知対象である通知デバイス３６の定義、駆動情報や制御情報が表示される。
【００８９】
図９のＢは、通常イベントのデータフォーマット９０を示している。イベント識別子Ａ＝０が定義されている。このイベント情報１２は緊急イベントではない。通常アプリの処理対象である。
【００９０】
図９のＣは、緊急イベントのデータフォーマット９０を示している。イベント識別子Ａ＝１が定義されている。このイベント情報１２は緊急イベントである。緊急処理の対象である。
【００９１】
このようなデータフォーマット９０をイベント情報１２に用いれば、ヘッダ部９２にあるイベント識別子Ａが「０」か「１」かにより、緊急イベントか否かを判別することができる。
【００９２】
＜緊急イベント処理の出力形態＞
【００９３】
図１０は、緊急イベント処理の出力形態の一例を示している。緊急イベントの一例である地震が発生した場合である。携帯端末装置４は、緊急イベントとしてＳＭＳ受信により、緊急イベント情報を受信する。これにより、携帯端末装置４は、既述の緊急イベント処理を実行し、ユーザ通知として緊急メッセージ９６を出力する。この緊急メッセージ９６の出力形態は通知デバイス３６によって異なる。表示部７０では表示出力として「緊急地震速報○○で地震発生。強い揺れに備えてください。」が表示されている。ＬＥＤ表示部７２では、地震速報の受信により瞬時に点灯し、ユーザ通知として警報表示９８が発せられる。バイブレータ７４では、地震速報の受信により瞬時に振動を開始し、ユーザ通知として警報振動１００が発せられる。スピーカ７６では、ユーザ通知として音声メッセージ１０２が発せられる。音声メッセージ１０２は警報音であってもよい。
【００９４】
ユーザは、緊急イベントの発生から瞬時に緊急イベントの発生を認識できる。しかも、緊急イベントの発生を多用な通知形態により認識できる。
【００９５】
＜緊急イベント処理の処理手順＞
【００９６】
図１１は、緊急イベント処理の処理手順の一例を示している。この処理手順は本開示の情報処理装置のプログラムで実行される処理の一例である。
【００９７】
図１１に示す処理手順では、携帯端末装置４がイベント情報１２を受信する（Ｓ１０１）。このイベント情報１２は通常処理であるアプリケーション２２の処理の前（優先して）に緊急イベント判別機能３８で判断される（Ｓ１０２）。つまり、この判断はアプリケーション２２の処理をスキップして実行する。しかも、ＯＳ上ではなく、ファームウエアプログラムで実行する。
【００９８】
イベント情報１２が緊急イベントでなければ（Ｓ１０２のＮＯ）、通常アプリ処理に移行する。この処理は、アプリケーション２２による処理である。
【００９９】
イベント情報１２が緊急イベントであれば（Ｓ１０２のＹＥＳ）、このイベント情報１２がユーザ通知制御機能２８に通知される（Ｓ１０３）。このユーザ通知制御機能２８は、緊急イベントであることをデバイス制御部１０に通知する（Ｓ１０４）。デバイス制御部１０では緊急イベントの通知を契機とし、チャネル切替え機能４４によりチャネル切替えが実行される（Ｓ１０５）。この場合、緊急イベントであるから、処理チャネルが緊急イベント処理ＣＨ４２に切替えられる。したがって、この緊急イベント処理ＣＨ４２から緊急処理出力が発せられる（Ｓ１０６）。
【０１００】
この緊急イベント処理において、緊急イベント処理の解除か否かが判断される（Ｓ１０７）。この緊急イベント処理の解除は、入力部６２からの解除入力に基づき、ＣＰＵ４８が実行する。緊急イベント処理を解除しない場合には（Ｓ１０７のＮＯ）、緊急イベント処理ＣＨ４２から緊急処理出力が継続して発せられる。緊急処理出力はたとえば、イベント情報１２が終了するまで継続する。
【０１０１】
緊急イベント処理を解除する場合には（Ｓ１０７のＹＥＳ）、緊急イベントの解除が実行される（Ｓ１０８）。これにより、緊急イベント処理ＣＨ４２から緊急処理出力が解除される。緊急イベント処理の解除を実行した後、Ｓ１０１に戻る。
【０１０２】
この緊急イベント処理において、イベント情報１２が緊急イベントであると判断した場合には（Ｓ１０２のＹＥＳ）、Ｓ１０３への移行と同時に緊急イベント処理アプリ３４に緊急イベントであることを通知する（Ｓ１０９）。この通知は緊急イベント受信ハンドラ２６が行う。緊急イベント処理アプリ３４では、緊急イベントの動作が可能であるかを判断する（Ｓ１１０）。緊急イベント処理アプリ３４で緊急イベントの処理が可能であれば、ユーザ通知制御機能２８から動作可能であることをデバイス制御部１０に通知する。これにより、通常アプリ入出力ＣＨ４０への切替え処理が実行される（Ｓ１１１）。
【０１０３】
＜緊急処理出力（Ｓ１０６）の処理手順＞
【０１０４】
図１２は、緊急処理出力（Ｓ１０６）の処理手順の一例を示している。緊急処理出力（Ｓ１０６）では、緊急表示（メッセージ表示）出力（Ｓ１０６−１）、ＬＥＤ表示部７２の点灯（Ｓ１０６−２）、バイブレータ７４による振動出力（Ｓ１０６−３）、スピーカ７６による音声出力や警報（Ｓ１０６−４）が含まれる。これらのいずれか一つでもよいし、二以上でもよい。また、他の緊急処理出力としてたとえば、骨伝導手段などを併用してもよい。
【０１０５】
＜通常アプリ入出力ＣＨへの切替え処理（Ｓ１１１）の処理手順＞
【０１０６】
図１３は、Ｓ１１１の処理（通常アプリ入出力ＣＨへの切替え処理）の処理手順を示している。
【０１０７】
この処理手順は緊急イベント処理アプリ３４の動作可能である報告を受けた場合の完了時の処理である。つまり、表示部７０に緊急メッセージが表示中である場合の処理である。
【０１０８】
この処理手順では、緊急イベント処理アプリ３４で緊急メッセージが表示中であるか否かを判断する（Ｓ１２１）。緊急メッセージが表示中でなければ（Ｓ１２１のＮＯ）、この処理を終了し、Ｓ１１１にリターンする。つまり、アプリケーション２２での動作は可能であっても、メッセージ表示中でなければ（Ｓ１２１のＮＯ）、ユーザ指示により通知受領（すなわち、メッセージ消去）の処理が実行された場合である。この場合には、既に通常アプリ入出力ＣＨ４０への切替え済みであり、何の処理も行わない。
【０１０９】
緊急メッセージが表示中であれば（Ｓ１２１のＹＥＳ）、緊急イベント処理アプリ３４からユーザ通知制御機能２８に緊急メッセージが表示中であることを通知する（Ｓ１２２）。この通知を受けたユーザ通知制御機能２８からデバイス制御部１０に緊急メッセージが通知される（Ｓ１２３）。これにより、デバイス制御部１０では、現在出力中の緊急イベント処理ＣＨ４２から通常アプリ入出力ＣＨ４０に切替えられる（Ｓ１２４）。したがって、この通常アプリ入出力処理ＣＨ４０から緊急イベント処理アプリ３４の緊急処理出力が発せられる（Ｓ１２５）。
【０１１０】
このＳ１２５における緊急処理出力は、既述の緊急処理出力（Ｓ１０６：図１１）と同様である。
【０１１１】
この緊急イベント処理アプリ３４の緊急イベント処理において、緊急イベント処理の解除か否かが判断される（Ｓ１２６）。この緊急イベント処理の解除は、ユーザ指示に基づき、ＣＰＵ４８が実行する。緊急イベント処理を解除しない場合には（Ｓ１２６のＮＯ）、通常アプリ入出力ＣＨ４０から緊急処理出力が継続して発せられる。緊急処理出力はたとえば、イベント情報１２が終了するまで継続することは既述の通りである。
【０１１２】
緊急イベント処理を解除する場合には（Ｓ１２６のＹＥＳ）、メッセージクローズの処理が実行され（Ｓ１２７）、Ｓ１１１にリターンする。
【０１１３】
斯かる処理手順によれば、アプリケーション２２により動作可能となったので、引き続いて通常アプリ入出力ＣＨ４０でユーザ通知を継承する。これにより、緊急イベント処理ＣＨ４２が開放される。この開放によって、緊急イベント処理ＣＨ４２は、次の緊急イベントの到来に備えることができる。
【０１１４】
＜緊急イベント処理の解除（Ｓ１０８）の処理手順＞
【０１１５】
図１４は、緊急イベント処理の解除（Ｓ１０８：図１１）の処理手順の一例を示している。この処理手順はメッセージクローズの後、通常アプリ入出力ＣＨ４０への切替え処理である。
【０１１６】
この処理手順では、メッセージクローズの処理を行なう（Ｓ１３１）。このメッセージクローズをユーザ通知制御機能２８に通知する（Ｓ１３２）。これを受け、デバイス制御部１０にメッセージクローズが通知される（Ｓ１３３）。これにより、デバイス制御部１０では、現在出力中の緊急イベント処理ＣＨ４２から通常アプリ入出力ＣＨ４０に切替えを行い（Ｓ１３４）、Ｓ１０８（図１１）にリターンする。
【０１１７】
緊急イベント処理ＣＨ４２による緊急メッセージの表示中にユーザ操作でダイヤログがクローズされた場合には、係る緊急イベント処理の終了となる。これにより、通常アプリ入出力ＣＨ４０への切替えを行う。
【０１１８】
＜緊急イベント処理の処理シーケンス＞
【０１１９】
図１５は、緊急イベント処理の処理シーケンスを示す図である。受信ハンドラ２４がイベント情報１２を受信する（Ｓ２０１）。このイベント情報１２は緊急イベント受信ハンドラ２６に通知される（Ｓ２０２）。緊急イベント受信ハンドラ２６は、イベント情報１２が緊急イベントであるかの判別を行う。この判別はアプリケーション２２の処理をスキップして実行される。イベント情報１２が緊急イベントであれば、緊急イベント受信ハンドラ２６からダイレクトに、つまり、アプリケーション２２、緊急イベント処理アプリ３４をスキップしてユーザ通知制御機能２８に通知される（Ｓ２０３）。この処理は即時に実行される。ユーザ通知制御機能２８は、緊急イベントであることをデバイス制御部１０に通知する（Ｓ２０４）。これにより、デバイス制御部１０では緊急イベント処理ＣＨ４２に切り替え、この緊急イベント処理ＣＨ４２から緊急イベントが緊急メッセージなどによりユーザに通知される（Ｓ２０５）。
【０１２０】
緊急イベント受信ハンドラ２６が緊急イベントであることを判断した場合には、ユーザ通知制御機能２８への通知と同時に、緊急イベント情報を即時にアプリケーション２２に通知する（Ｓ２０６）。
【０１２１】
アプリケーション２２ではスケジューラ３０のスケジューリング制御により、アプリ起動が実行される（Ｓ２０７）。これにより、緊急イベント処理アプリ３４の起動が指示される（Ｓ２０８）。
【０１２２】
緊急イベント処理アプリ３４の起動準備が完了すると、その起動準備の完了を表す通知がユーザ通知制御機能２８に通知される（Ｓ２０９）。この通知を受けたユーザ通知制御機能２８は、デバイス制御部１０に対し、実行中の緊急イベント処理ＣＨ４２から通常アプリ入出力ＣＨ４０に制御を戻す指示を発する（Ｓ２１０）。
【０１２３】
これにより、デバイス制御部１０では通常アプリ入出力ＣＨ４０に戻す処理を行う。この結果、ユーザ通知が通常アプリ入出力ＣＨ４０に切り替えられる。したがって、既述の緊急イベントとして緊急メッセージなどのユーザ通知が通常アプリ入出力ＣＨ４０に引き継がれる。緊急イベント処理ＣＨ４２のタスクが解除され、緊急イベント処理ＣＨ４２は次の緊急イベントの到来に備えることができる。
【０１２４】
＜緊急イベントが輻輳した場合の処理シーケンス＞
【０１２５】
図１６は、緊急イベントが輻輳した場合の処理シーケンスを示す図である。この処理手順では、２つのイベント情報１２−１、１２−２を受信し、これらが共に緊急イベントである場合の処理である。イベント情報１２−１に係る緊急イベントを緊急イベント〔Ｉ〕、イベント情報１２−２に係る緊急イベントを緊急イベント〔II〕とする。
【０１２６】
この処理手順では、受信ハンドラ２４がイベント情報１２−１を受信する（Ｓ３１１）。受信ハンドラ２４では、緊急イベント判別機能３８で緊急イベントか否かが判断される。イベント情報１２−１が緊急イベントである場合、その緊急イベント情報が緊急イベント受信ハンドラ２６に通知される（Ｓ３１２）。この緊急イベント情報は緊急イベント受信ハンドラ２６からユーザ通知制御機能２８に通知される（Ｓ３１３）。ユーザ通知制御機能２８は緊急イベント情報をデバイス制御部１０に通知する（Ｓ３１４）。デバイス制御部１０では緊急イベント処理ＣＨ４２から緊急イベント処理出力が通知デバイス３６に送出され、ユーザ通知が実行される（Ｓ３１５）。
【０１２７】
既述したように、緊急イベント受信ハンドラ２６では、緊急イベント〔Ｉ〕を受信した際に、即時にアプリケーション２２のスケジューラ３０に通知する（Ｓ３１６）。スケジューラ３０では、スケジューリング制御によりアプリ起動にタスクが移される。
【０１２８】
また、この処理手順では、受信ハンドラ２４がイベント情報１２−２を受信する（Ｓ３２１）。受信ハンドラ２４では、緊急イベント判別機能３８で緊急イベントか否かが判断される。イベント情報１２−２が緊急イベントである場合、その緊急イベント情報が緊急イベント受信ハンドラ２６に通知される（Ｓ３２２）。この緊急イベント情報は緊急イベント受信ハンドラ２６からユーザ通知制御機能２８に通知される（Ｓ３２３）。ユーザ通知制御機能２８は緊急イベント情報をデバイス制御部１０に通知する（Ｓ３２４）。デバイス制御部１０では緊急イベント処理ＣＨ４２から緊急イベント処理出力が通知デバイス３６に送出され、ユーザ通知が実行される（Ｓ３２５）。この場合、緊急イベント〔Ｉ〕のユーザ通知を破棄し、ユーザ通知を緊急イベント〔II〕に切り替える。
【０１２９】
この場合も、緊急イベント受信ハンドラ２６では、緊急イベント〔II〕を受信した際に、即時にアプリケーション２２のスケジューラ３０に通知する（Ｓ３２６）。スケジューラ３０では、スケジューリング制御によりアプリ起動にタスクが移される。緊急イベント〔II〕はアプリケーション２２の緊急イベント処理アプリ３４に通知される（Ｓ３２７）。
【０１３０】
緊急イベント処理アプリ３４は起動準備を完了すると、その通知をユーザ通知制御機能２８に発する（Ｓ３２８）。ユーザ通知制御機能２８はデバイス制御部１０に通知し（Ｓ３２９）、通常アプリ入出力ＣＨ４０に制御を戻す処理を行う。
【０１３１】
この場合、緊急イベント処理アプリ３４はイベントが〔Ｉ〕、〔II〕の順できたことが分かるので、通知デバイス３６による表示を引き継ぎ、つまり、最新のイベント情報から順に表示する（この場合、緊急イベント〔II〕→緊急イベント〔Ｉ〕の順である）。
【０１３２】
緊急イベント処理アプリ３４からの出力はデバイス制御部１０に通知され（Ｓ３３０）、最新の緊急イベント〔II〕のメッセージ表示が引き継がれる（Ｓ３３１）。
【０１３３】
また、緊急イベント処理アプリ３４は連続してデバイス制御部１０に通知を行う（Ｓ３３２）。この場合、緊急イベント〔II〕の表示がユーザ操作などでクローズした後、緊急イベント〔Ｉ〕の再表示を行う（Ｓ３３３）。
【０１３４】
＜通常イベントの処理シーケンス＞
【０１３５】
図１７は、通常イベントの処理シーケンスを示す図である。受信ハンドラ２４がイベント情報１２を受信する（Ｓ４０１）。受信ハンドラ２４では緊急イベント判別機能３８によりイベント情報１２が通常イベントか緊急イベントかを判別する。イベント情報１２が通常イベントであれば、この通常イベント情報は受信ハンドラ２４からアプリケーション２２に通知される（Ｓ４０２）。アプリケーション２２ではスケジューラ３０によるスケジューリング制御により、アプリ３２−１、３２−２・・・３２−Ｎからアプリが選択される。このタスク制御において、担当するアプリが起動中であれば、到来した通常イベントの処理は起動中の処理完了まで待機状態となる（Ｓ４０３）。その処理が完了すれば、通常イベントの処理の指示がユーザ通知制御機能２８に指示される（Ｓ４０４）。
【０１３６】
ユーザ通知制御機能２８は、通常イベントであることをデバイス制御部１０に通知する（Ｓ４０５）。その場合、出力対象である通知デバイス３６が使用中であれば、その処理終了まで待機状態となる。デバイス制御部１０では通常アプリ入出力ＣＨ４０よりユーザ通知を行う（Ｓ４０６）。
【０１３７】
＜イベント情報の処理結果＞
【０１３８】
図１８は、イベント情報の処理結果を示している。図１８のＡはイベント情報１２の継続受信を示し、Ａ１、Ａ３が通常イベント、Ａ２、Ａ４が緊急イベントである。
【０１３９】
図１８のＢは、アプリケーション２２による通常イベント処理である。Ｂ１はたとえば、アプリ３２−１の処理、Ｂ２、Ｂ４は緊急イベント処理アプリ３４による処理、Ｂ３はたとえば、アプリ３２−２の処理である。
【０１４０】
図１８のＣは緊急イベント処理ＣＨ４２が担当する緊急イベント処理を示している。Ｃ１は緊急イベントＡ２に対応している。Ｃ２は緊急イベントＡ４に対応している。
【０１４１】
緊急イベントＡ２は既述した処理により緊急イベント処理ＣＨ４２からユーザ通知が実行される（Ｓ１）。その実行中にアプリケーション２２側の緊急イベント処理アプリ３４の動作準備が完了すると（Ｓ２）、緊急イベント処理ＣＨ４２のユーザ通知は緊急イベント処理アプリ３４に移され（Ｓ３）、通常アプリ入出力ＣＨ４０に引き継がれる。このような処理は、緊急イベントＡ４においても同様である。
【０１４２】
緊急イベントＡ２の受信から緊急イベント処理ＣＨ４２の実行開始時点をｔ１、アプリケーション２２側の緊急イベント処理アプリ３４の動作準備の完了時点をｔ２とする。緊急イベント処理アプリ３４の動作準備の完了時点ｔ２を基準にすれば、ダイレクトアクセスによる緊急イベント処理ＣＨ４２の実行開始時点ｔ１は時間Δｔだけ迅速化されている。つまり、緊急イベントの処理が高速化される。
【０１４３】
しかも、緊急イベントの通知処理は緊急イベント処理アプリ３４の動作準備の完了により、緊急イベント処理アプリ３４に移され、通常アプリ入出力ＣＨ４０に引き継がれる。これにより、緊急イベント処理ＣＨ４２は次の緊急イベントを受信および処理するために待機することができる。この結果、緊急イベントの処理が滞ることは無い。
【０１４４】
＜第２の実施の形態の効果＞
【０１４５】
スマートフォン端末など、緊急地震速報の受信時、ユーザへの通知を迅速化でき、イベント情報に即応でき、有用である。
【０１４６】
〔第３の実施の形態〕
【０１４７】
＜制御プログラム＞
【０１４８】
図１９は、第３の実施の形態に係る制御プログラムの処理手順を示している。この処理手順は一例であって、斯かる構成に本開示の情報処理装置のプログラムが限定されるものではない。
【０１４９】
この処理手順は、緊急イベント処理をカメラ起動に応用したものである。この処理手順ではカメラ６８の起動の場合にシャッター押下で緊急イベントの通知を行う。これにより、緊急イベントと同様となり、他のアプリケーション２２にて通知デバイス３６としてカメラ６８を使用している場合や、スケジューラ３０によるアプリケーション２２の起動待ちを介することなく、迅速なカメラ起動を実現する。これにより、どのようなアプリ３２−１、３２−２・・・３２−Ｎが起動中であっても、最速処理でシャッターを切ることができる。
【０１５０】
図１９に示す処理手順では、カメラ６８のシャッター押下（Ｓ５０１）により、イベント情報１２をデータフォーマットにて通知する（Ｓ５０２）。カメラ６８のシャッターは既述の決定キー８４でもよく、筐体７８の側面にあるシャッターボタンでもよい。
【０１５１】
イベント情報１２が緊急イベントか否かを判別する（Ｓ５０３）。イベント情報１２が緊急イベントでなければ（Ｓ５０３のＮＯ）、この処理を終了する。
【０１５２】
イベント情報１２が緊急イベントであれば（Ｓ５０３のＹＥＳ）、その緊急イベント情報をユーザ通知制御機能２８に通知し（Ｓ５０４）、デバイス制御部１０によるデバイス制御を実行する（Ｓ５０５）。つまり、チャネル切替えを行う。
【０１５３】
これにより、緊急イベント処理ＣＨ４２へ切り替え（Ｓ５０６）、カメラ６８を起動する（Ｓ５０７）。これにより、撮像している被写体の画像をメモリ５２のデータ記憶部５８に取り込む。
【０１５４】
このカメラ６８の起動はユーザ通知制御機能２８に通知され（Ｓ５０８）、デバイス制御を行う（Ｓ５０９）。カメラ６８の起動準備が完了していれば、通常アプリ入出力ＣＨ４０への切り替えを行い（Ｓ５１０）、この処理を終了する。
【０１５５】
このようにカメラ６８の起動においても、緊急イベントの処理によりシャッターチャンスに即応できる。通常のカメラアプリの起動準備が完了すれば、通常アプリ入出力ＣＨ４０での画像取込みを行い、緊急イベント処理ＣＨ４２を待機状態にし、次の緊急イベントの処理に備える。
【０１５６】
＜第３の実施の形態の効果＞
【０１５７】
写真撮影時、シャッター押下にてリアルタイムに処理を行うことができ、シャッターチャンスに即応できる。
【０１５８】
〔他の実施の形態〕
【０１５９】
(1) 上記実施の形態では、緊急イベント受信ハンドラ２６の緊急イベント情報をスケジューラ３０に通知しているが、これに限定されない。図２０に示すように、緊急イベント受信ハンドラ２６の緊急イベント情報を緊急イベント処理アプリ３４に通知し、スケジューラ３０による処理を回避してもよい。このようにすれば、スケジューラ３０による処理時間を削減でき、処理の高速化に寄与する。
【０１６０】
(2) 上記実施の形態では、情報処理装置として携帯端末装置４を例示したが、これに限定されない。スマートフォン、タブレット端末などの他、情報処理装置としてたとえば、電子ゲーム機など、緊急イベントを処理可能な電子機器であってもよい。
【０１６１】
(3) 上記実施の形態では、イベント情報１２の受領として無線による受信を例示したが、これに限定されない。携帯端末装置４や他の情報処理装置内で生起するイベントをイベント情報として用いてもよい。
【０１６２】
以上説明したように、情報処理装置およびそのプログラムの最も好ましい実施の形態等について説明したが、本発明は、上記記載に限定されるものではない。特許請求の範囲に記載され、又は発明を実施するための形態に開示された発明の要旨に基づき、当業者において様々な変形や変更が可能である。斯かる変形や変更が、本発明の範囲に含まれることは言うまでもない。
【符号の説明】
【０１６３】
２  制御プログラム
４  携帯端末装置
６  通常処理プログラム
８  緊急処理プログラム
１０  デバイス制御部
１２  イベント情報
１４  通常処理チャネル
１６  緊急処理チャネル
２２  アプリケーション
２４  受信ハンドラ
２６  緊急イベント受信ハンドラ
２８  ユーザ通知制御機能
３０  スケジューラ
３２−１、３２−２・・・３２−Ｎ  アプリ
３４  緊急イベント処理アプリ
３６  通知デバイス
３８  緊急イベント判別機能
４０  通常アプリ入出力ＣＨ
４２  緊急イベント処理ＣＨ
４４  チャネル切替え機能
４６  無線部
４８  ＣＰＵ
５０  アンテナ
５２  メモリ
５４  バス
５６  プログラム記憶部
５８  データ記憶部
６０  ＲＡＭ
６２  入力部
６４  音声入出力部
６６  マイクロフォン
６８  カメラ
７０  表示部
７２  ＬＥＤ表示部
７４  バイブレータ
７６  スピーカ
８０  表示パネル
８２  タッチパネル
８４  決定キー
９０  データフォーマット
９２  ヘッダ部
９４  データ部
９６  緊急メッセージ
９８  警報表示
１００  警報振動
１０２  音声メッセージ
【図１】
2013196192.tif 000003
【図２】
2013196192.tif 000004
【図３】
2013196192.tif 000005
【図４】
2013196192.tif 000006
【図５】
2013196192.tif 000007
【図６】
2013196192.tif 000008
【図７】
2013196192.tif 000009
【図８】
2013196192.tif 000010
【図９】
2013196192.tif 000011
【図１０】
2013196192.tif 000012
【図１１】
2013196192.tif 000013
【図１２】
2013196192.tif 000014
【図１３】
2013196192.tif 000015
【図１４】
2013196192.tif 000016
【図１５】
2013196192.tif 000017
【図１６】
2013196192.tif 000018
【図１７】
2013196192.tif 000019
【図１８】
2013196192.tif 000020
【図１９】
2013196192.tif 000021
【図２０】
2013196192.tif 000022
【図２１】
2013196192.tif 000023