(57)【要約】      （修正有）【課題】起動時間を短縮できる情報処理装置を提供する。【解決手段】情報処理装置では、本体部１０と操作部２０とが並行起動する場合に、操作部２０はＯＳと併せてプログラム２４０も起動し、プログラム２４０による操作部２０の起動処理が完了した時点で、プログラム２４０から本体部１０へ準備完了通知が送信される２．１．１。本体部１０は、準備完了通知の受信に応じて、アプリケーション２２２への通知をプログラム２４０に送信し４．１、プログラム２４０は本体部１０から受信した通知を、ＯＳの起動完了後に起動したアプリケーション２２２へ送信する４．１．１。【選択図】図５
2020077354.tif 000002
【特許請求の範囲】
【請求項１】
本体部と、
操作部と、
前記操作部のＯＳと独立して動作可能に前記操作部内に設けられ、前記ＯＳより起動時間が短く、前記操作部の起動処理の一部を実施するプログラムと、
を備え、
前記本体部と前記操作部とが並行起動する場合に、前記操作部は前記ＯＳと併せて前記プログラムも起動し、前記プログラムによる前記操作部の起動処理が完了した時点で、前記プログラムから前記本体部へ準備完了通知を送信する、
情報処理装置。
【請求項２】
前記操作部の前記ＯＳ内に設けられ、前記ＯＳ上で動作し、前記本体部と前記操作部との間の接続を管理すると共に、前記操作部の起動処理を行うアプリケーションを備え、
前記本体部は、前記準備完了通知の受信に応じて、前記アプリケーションへの通知を前記プログラムに送信し、
前記プログラムは前記本体部から受信した前記通知を、前記ＯＳの起動完了後に起動した前記アプリケーションへ送信する、
請求項１に記載の情報処理装置。
【請求項３】
前記操作部は、前記ＯＳを起動するＯＳ起動部と、前記プログラムを起動するプログラム起動部と、を有し、
前記ＯＳは、前記ＯＳ上で作動する前記アプリケーションと、前記アプリケーションを起動するアプリケーション起動部と、を有し、
前記プログラムは、前記操作部の起動処理を行い前記準備完了通知を作成する起動処理部と、前記起動処理部が作成した前記準備完了通知を前記本体部に送信し、前記本体部から前記通知を受信して前記通知を前記アプリケーションに送信する通信部と、を有する、請求項２に記載の情報処理装置。
【請求項４】
前記プログラムが、前記本体部から受信した前記通知の内容を記憶する記憶部を有する、
請求項２または３に記載の情報処理装置。
【請求項５】
前記アプリケーションは、前記アプリケーションの起動処理が完了したときに起動完了通知を前記プログラムに送信し、
前記プログラムは、前記起動完了通知を受信した後に、前記本体部から受信した前記通知を前記アプリケーションに送信する、
請求項２〜４のいずれか１項に記載の情報処理装置。
【請求項６】
前記プログラムは、
前記プログラムの処理を実行する実行スレッドと、前記処理のうち前記アプリケーションの起動完了後に行う処理を蓄積する待ちスレッドと、を有し、
前記起動完了通知を前記アプリケーションから受信した後に、前記待ちスレッドに蓄積されていた処理を前記実行スレッドに実行させる、
請求項５に記載の情報処理装置。
【請求項７】
前記プログラムは、
前記本体部から受信した前記通知を前記アプリケーションに送信可能か否かを判断する送信不可判断部と、
前記送信不可判断部により送信不可と判断された前記通知を蓄積する通知蓄積部と、
を有し、
前記送信不可判断部は、前記起動完了通知を前記アプリケーションから受信するとき、前記通知を前記アプリケーションに送信可能との判断に切り替え、
前記プログラムは、前記送信不可判断部の判断の切り替えに応じて、前記通知蓄積部に蓄積されている前記通知を前記アプリケーションへ送信する、
請求項５または６に記載の情報処理装置。
【請求項８】
前記プログラムは、
前記送信不可判断部が前記本体部から受信した前記通知を前記アプリケーションに送信可能と判断する場合、前記通知を前記通知蓄積部に蓄積せずに前記アプリケーションへ送信する、
請求項７に記載の情報処理装置。
【請求項９】
前記プログラムは、前記本体部から受信した前記通知が前記アプリケーションへ送信する必要があるか否かを判断し、前記アプリケーションへ送信する必要があると判断した前記通知を前記通知蓄積部に蓄積する、
請求項７または８に記載の情報処理装置。
【請求項１０】
前記プログラムは、前記本体部から受信した前記通知から前記アプリケーションへ送信する必要がある情報のみを取り出して新たな通知を作成し、前記新たな通知を前記アプリケーションへ送信する、
請求項７または８に記載の情報処理装置。
【請求項１１】
本体部と、
操作部と、
前記操作部のＯＳと独立して動作可能に前記操作部内に設けられ、前記ＯＳより起動時間が短く、前記操作部の起動処理の一部を実施するプログラムと、
を備える情報処理装置の起動方法であって、
前記本体部と前記操作部とが並行起動する場合に、前記操作部が前記ＯＳと併せて前記プログラムを起動する起動ステップと、
前記起動ステップにて起動された前記プログラムが前記操作部の起動処理を実施する起動処理ステップと、
前記起動処理ステップにて実施された前記プログラムによる前記起動処理が完了した時点で、前記プログラムから前記本体部へ準備完了通知を送信する送信ステップと、
を含む、
情報処理装置の起動方法。
【請求項１２】
本体部と、操作部と、を備える情報処理装置の起動プログラムであって、
前記操作部のＯＳと独立して動作可能に前記操作部内に設けられ、前記ＯＳより起動時間が短く、前記操作部の起動処理の一部を実施するプログラムと、
前記本体部と前記操作部とが並行起動する場合に、前記操作部により前記ＯＳと併せて前記プログラムを起動する起動機能と、
前記起動機能により起動された前記プログラムが前記操作部の起動処理を実施する起動処理機能と、
前記起動処理機能により実施された前記プログラムによる前記起動処理が完了した時点で、前記プログラムから前記本体部へ準備完了通知を送信する送信機能と、
をコンピュータに実現させるための情報処理装置の起動プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理装置の起動方法、及び、情報処理装置の起動プログラムに関する。
【背景技術】
【０００２】
主要機能を備える本体部と、この本体部の機能を走査するための操作部とを備える情報処理装置において、本体部と操作部とが別のＣＰＵを持つ構成が知られている。このような情報処理装置では、例えば操作部に設けられるアプリケーションが操作部と本体部との接続を管理する。この情報処理装置では、起動時に以下の順番で起動処理が行われる。
（１）本体部と操作部がそれぞれ起動処理を開始
（２）本体部は操作部との接続が必要な処理の手前で、操作部のアプリケーションからの準備完了通知を待つ
（３）操作部のOS起動後にOS上のアプリケーションが起動し、アプリケーションが準備完了通知を本体部へ送信
（４）本体部は準備完了通知を受け取り、操作部と接続して起動処理を完了
【発明の概要】
【発明が解決しようとする課題】
【０００３】
操作部のアプリケーションは操作部用のＯＳ上で動くことから、操作部用ＯＳが立ち上がるまでアプリケーションは起動できず、それまで準備完了通知を送信できない。本体部は早くに準備完了通知の待ち状態になっており、処理を継続できないことで起動に余計な時間がかかるという問題があった。
【０００４】
本発明は、起動時間を短縮できることを目的とする。
【課題を解決するための手段】
【０００５】
上述した課題を解決するために、本発明の一観点に係る情報処理装置は、本体部と、操作部と、前記操作部のＯＳと独立して動作可能に前記操作部内に設けられ、前記ＯＳより起動時間が短く、前記操作部の起動処理の一部を実施するプログラムと、を備え、前記本体部と前記操作部とが並行起動する場合に、前記操作部は前記ＯＳと併せて前記プログラムも起動し、前記プログラムによる前記操作部の起動処理が完了した時点で、前記プログラムから前記本体部へ準備完了通知を送信する。
【発明の効果】
【０００６】
起動時間を短縮することができる。
【図面の簡単な説明】
【０００７】
【図１】実施形態に係る情報処理装置の全体構成図
【図２】操作部のハードウェア構成図
【図３】本体部のハードウェア構成図
【図４】情報処理装置の機能ブロック図
【図５】起動時の外部シーケンスについて説明する図
【図６】起動時の内部シーケンスについて説明する図
【図７】第１変形例における起動時のシーケンス図
【図８】第２変形例におけるアプリケーションとプログラムの間の処理シーケンス図
【図９】第３変形例の情報処理装置の機能ブロック図
【図１０】第３変形例における起動時の外部シーケンス図
【図１１Ａ】第３変形例における起動時の内部シーケンス図
【図１１Ｂ】第３変形例における起動時の内部シーケンス図
【図１２】第３変形例におけるアプリケーションとプログラムの間の処理シーケンス図
【図１３】キュー構造を利用した蓄積構造の例を示す模式図
【図１４】通知をアプリケーションへ送信するかの要否判断する場合の内部シーケンス図
【発明を実施するための形態】
【０００８】
以下、添付図面を参照しながら実施形態について説明する。説明の理解を容易にするため、各図面において同一の構成要素に対しては可能な限り同一の符号を付して、重複する説明は省略する。
【０００９】
［実施形態］
図１〜図６を参照して実施形態を説明する。図１は、実施形態に係る情報処理装置１の全体構成図である。
【００１０】
情報処理装置１は、例えば、ＭＦＰ（Ｍｕｌｔｉｆｕｎｃｔｉｏｎ  Ｐｅｒｉｐｈｅｒａｌ／Ｐｒｉｎｔｅｒ／Ｐｒｏｄｕｃｔ）と称される複合機、つまりファクシミリ、スキャナ、コピー、あるいはプリンタなどの画像処理機能、通信機能を有する装置である。図１に示すように、情報処理装置１は、本体部１０と、操作部２０とから成る単一の装置である。
【００１１】
本体部１０は、上記の画像処理機能や通信機能などの主要機能を備える。操作部２０は、ユーザによる本体部１０の各機能の操作を受け付ける。本体部１０と操作部２０とはそれぞれに別のＣＰＵ１１１，２１（第１、第２のＣＰＵ）を備えており、本体部１０はＣＰＵ１１１により動作し、操作部２０はＣＰＵ２１により動作する。本体部１０と操作部２０とはＵＳＢなどの通信方式で接続されている。
【００１２】
図２は、操作部２０のハードウェア構成図である。本実施形態では、操作部２０は一般的な情報処理端末と同様の構成を有する。即ち、操作部２０は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２１、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２２、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２３、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）２４及びＩ／Ｆ２５がバス２６を介して接続されている。また、Ｉ／Ｆ２５にはＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）２７及び操作入力部２８が接続されている。 
【００１３】
ＣＰＵ２１は演算手段であり、操作部２０の全体の動作を制御する。 
【００１４】
ＲＡＭ２２は、情報の高速な読み書きが可能な揮発性の記憶媒体であり、ＣＰＵ２１が情報を処理する際の作業領域として用いられる。 
【００１５】
ＲＯＭ２３は、読み出し専用の不揮発性記憶媒体であり、ファームウェア等のプログラムが格納されている。
【００１６】
ＨＤＤ２４は、情報の読み書きが可能な不揮発性の記憶媒体であり、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や各種の制御プログラム、アプリケーション・プログラム等が格納されている。
【００１７】
Ｉ／Ｆ２５は、バス２６と各種のハードウェアやネットワーク等を接続し制御する。
【００１８】
ＬＣＤ２７は、ユーザが状態を確認するための視覚的ユーザインタフェースである。
【００１９】
操作入力部２８は、キーボードやマウス等、ユーザが情報を入力するためのユーザインタフェースである。
【００２０】
図３は、本体部１０のハードウェア構成図である。図３に示すように、本体部１０は、コントローラ１１とエンジン部１５とをＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｆａｃｅ）バス１６で接続した構成となる。
【００２１】
コントローラ１１は、本体部１０全体の制御と描画、通信、操作部２０からの入力を制御する。
【００２２】
エンジン部１５は、ＰＣＩバス１６に接続可能なプリンタエンジンなどであり、たとえば白黒プロッタ、１ドラムカラープロッタ、４ドラムカラープロッタ、スキャナまたはファックスユニットなどである。なお、このエンジン部１５には、プロッタなどのいわゆるエンジン部分に加えて、誤差拡散やガンマ変換などの画像処理部分が含まれる。
【００２３】
コントローラ１１は、ＣＰＵ１１１と、ノースブリッジ（ＮＢ）１１３と、システムメモリ（ＭＥＭ―Ｐ）１１２と、サウスブリッジ（ＳＢ）１１４と、ローカルメモリ（ＭＥＭ―Ｃ）１１７と、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）１１６と、ハードディスクドライブ（ＨＤＤ）１１８とを有し、ノースブリッジ（ＮＢ）１１３とＡＳＩＣ１１６との間をＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ  Ｇｒａｐｈｉｃｓ  Ｐｏｒｔ）バス１１５で接続した構成となる。また、ＭＥＭ―Ｐ１１２は、ＲＯＭ１１２ａと、ＲＡＭ１１２ｂと、をさらに有する。
【００２４】
ＣＰＵ１１１は、本体部１０の全体制御をおこなうものであり、ＮＢ１１３、ＭＥＭ―Ｐ１１２およびＳＢ１１４からなるチップセットを有し、このチップセットを介して他の機器と接続される。
【００２５】
ＮＢ１１３は、ＣＰＵ１１１とＭＥＭ―Ｐ１１２、ＳＢ１１４、ＡＧＰバス１１５とを接続するためのブリッジであり、ＭＥＭ―Ｐ１１２に対する読み書きなどを制御するメモリコントローラと、ＰＣＩマスタおよびＡＧＰターゲットとを有する。
【００２６】
ＭＥＭ―Ｐ１１２は、プログラムやデータの格納用メモリ、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いるシステムメモリであり、ＲＯＭ１１２ａとＲＡＭ１１２ｂとからなる。
【００２７】
ＲＯＭ１１２ａは、プログラムやデータの格納用メモリとして用いる読み出し専用のメモリであり、ＲＡＭ１１２ｂは、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いる書き込みおよび読み出し可能なメモリである。
【００２８】
ＳＢ１１４は、ＮＢ１１３とＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。このＳＢ１１４は、ＰＣＩバスを介してＮＢ１３と接続されており、このＰＣＩバスには、ネットワークインターフェース（Ｉ／Ｆ）部なども接続される。
【００２９】
ＡＳＩＣ１１６は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）であり、ＡＧＰバス１１５、ＰＣＩバス１６、ＨＤＤ１１８およびＭＥＭ―Ｃ１１７をそれぞれ接続するブリッジの役割を有する。
【００３０】
このＡＳＩＣ１１６は、ＰＣＩターゲットおよびＡＧＰマスタと、ＡＳＩＣ１１６の中核をなすアービタ（ＡＲＢ）と、ＭＥＭ―Ｃ１１７を制御するメモリコントローラと、ハードウェアロジックなどにより画像データの回転などをおこなう複数のＤＭＡＣ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌｌｅｒ）と、エンジン部１５との間でＰＣＩバス１６を介したデータ転送をおこなうＰＣＩユニットとからなる。 
【００３１】
このＡＳＩＣ１１６には、ＰＣＩバス１６を介してＦＣＵ（Ｆａｃｓｉｍｉｌｅ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ）１２、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）１３、ＩＥＥＥ１３９４（ｔｈｅ  Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｅｎｇｉｎｅｅｒｓ  １３９４）インタフェース１４が接続される。 また、このＡＳＩＣ１６には、操作部２０も直接接続されている。 
【００３２】
ＭＥＭ―Ｃ１１７は、コピー用画像バッファ、符号バッファとして用いるローカルメモリである。 
【００３３】
ＨＤＤ１１８は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積を行うためのストレージである。 また、ＨＤＤ１１８は、本体部１０で実行されるアプリケーションのライセンスファイルを保存する。 
【００３４】
ＡＧＰバス１１５は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレーターカード用のバスインターフェースであり、ＭＥＭ―Ｐ１１２に高スループットで直接アクセスすることにより、グラフィックスアクセラレーターカードを高速にするものである。
【００３５】
図４は、情報処理装置１の機能ブロック図である。操作部２０はＯＳ（Ｏｐｅｒａｔｉｏｎ  Ｓｙｓｔｅｍ）起動部２１０、ＯＳ２２０、プログラム起動部２３０、プログラム２４０から構成される。
【００３６】
ＯＳ起動部２１０は、ＯＳ２２０を起動する。
【００３７】
ＯＳ２２０は、アプリケーション起動部２２１、アプリケーション２２２から構成される。アプリケーション起動部２２１は、アプリケーション２２２を起動させる。
【００３８】
アプリケーション２２２は、操作部２０のＯＳ２２０内に設けられ、ＯＳ２２０上で作動する。アプリケーション２２２は、本体部１０と操作部２０との間の接続を管理すると共に、操作部２０の起動処理を行う。アプリケーション２２２は、起動処理部２２３、通信部２２４から構成される。起動処理部２２３は、操作部２０の起動処理を実行する。通信部２２４を介して本体部１０からの通知を受け取り、起動処理に利用する。通信部２２４は、起動処理に必要な通知を本体部１０から受け取り、起動処理部２２３へ渡す。
【００３９】
プログラム起動部２３０は、プログラム２４０を起動する。
【００４０】
プログラム２４０は、操作部２０内にＯＳ２２０と分離して設けられ、ＯＳ２２０と独立して動作可能である。プログラム２４０は、ＯＳ２２０より起動時間が短く、アプリケーション２２２による操作部２０の起動処理の一部を実施する。プログラム２４０は、起動処理部２４１、通信部２４２から構成される。起動処理部２４１は、操作部２０の起動処理を実行する。プログラム２４０で実施すべき準備処理が完了したら、準備完了通知を作成して通信部２４２へ渡す。通信部２４２は、起動処理部２４１から受け取った準備完了通知を本体部１０へ送信する。また、通信部２４２は、本体部１０から受信した通知をアプリケーション２２２の通信部２２４へ渡す。
【００４１】
本体部１０は起動処理部１１０、通信部１２０から構成される。
【００４２】
起動処理部１１０は、本体部１０の起動に必要な処理を実行する。通信部１２０から準備完了通知を受信する。また、起動処理部１１０は、通信部１２０を経由し、操作部２０と起動処理に必要な通知の受け渡しを行う。
【００４３】
通信部１２０は、操作部２０のプログラム２４０の通信部２４２から準備完了通知を受信し、起動処理部１１０へ渡す。また、通信部１２０は、起動処理部１１０から受信した通知を操作部２０へ渡す。
【００４４】
図４に示す情報処理装置１の操作部２０のＯＳ起動部２１０、ＯＳ２２０、プログラム起動部２３０、プログラム２４０、アプリケーション起動部２２１、アプリケーション２２２、起動処理部２２３，２４１、通信部２２４，２４２の各機能は、操作部２０のＣＰＵ２１、ＲＡＭ２２等のハードウェア上に所定のコンピュータソフトウェア（起動プログラム）を読み込ませることにより、ＣＰＵ２１の制御のもとで各種ハードウェアを動作させるとともに、ＲＡＭ２２やＨＤＤ２４におけるデータの読み出し及び書き込みを行うことで実現される。また、本体部１０の起動処理部１１０、通信部１２０の機能は、本体部１０のＣＰＵ１１１、ＲＡＭ１１２ｂ等のハードウェア上に所定のコンピュータソフトウェア（起動プログラム）を読み込ませることにより、ＣＰＵ１１１の制御のもとで各種ハードウェアを動作させるとともに、ＲＡＭ１１２ｂやＨＤＤ１１８におけるデータの読み出し及び書き込みを行うことで実現される。すなわち、本実施形態の情報処理装置１の起動プログラムをコンピュータ上で実行させることで、情報処理装置１の操作部２０は、図４のＯＳ起動部２１０、ＯＳ２２０、プログラム起動部２３０、プログラム２４０、アプリケーション起動部２２１、アプリケーション２２２、起動処理部２２３，２４１、通信部２２４，２４２として機能し、情報処理装置１の本体部１０は、起動処理部１１０、通信部１２０として機能する。
【００４５】
図５、図６を参照して、情報処理装置１の起動方法について説明する。図５は、起動時の外部シーケンスについて説明する図である。図６は、起動時の内部シーケンスについて説明する図である。ここで、「外部シーケンス」とは情報処理装置１の外部から視たシーケンスであり、情報処理装置１の外部から各処理を確認可能なシーケンスである。一方、「内部シーケンス」とは、情報処理装置１の内部の機能（起動処理部２２３，２４１や通信部２２４，２４２など）で視たシーケンスである。
【００４６】
まず図５を参照して外部シーケンスについて、図中のシーケンス番号と対比させ説明する。
【００４７】
１：単独の起動処理
本体部１０は、まず単独でできる起動処理を実行する。単独でできる起動処理が完了したら、準備完了通知が来るのを待つ状態となる。
【００４８】
２：プログラム起動（起動ステップ、起動機能）
操作部２０のプログラム２４０が起動する。プログラム２４０はＯＳ２２０の外で動作することができる。
【００４９】
２．１：起動処理（起動処理ステップ、起動処理機能）
プログラム２４０は起動すると、次に操作部２０の起動処理を実行する。ここで、プログラム２４０で実行すべき操作部２０の起動処理とは、例えば、操作部２０が本体部１０と通信が可能になる最低限の処理を含む。
【００５０】
２．１．１：準備完了通知（送信ステップ、送信機能）
プログラム２４０は実行すべき起動処理が完了すると、準備完了通知を本体部１０へ送信する。
【００５１】
３．ＯＳ起動
操作部２０のＯＳ２２０が起動する。
【００５２】
３．１：アプリケーション起動
ＯＳ２２０の起動が完了すると、ＯＳ２２０上でアプリケーション２２２が起動する。
【００５３】
３．１．１：起動処理
アプリケーション２２２は、アプリケーション２２２の起動が完了すると、操作部２０の起動処理を実行する。ここで、アプリケーション２２２で実行すべき操作部２０の起動処理とは、シーケンス２．１でのプログラム２４０で実行された起動処理を除く他の処理を含む。
【００５４】
４：操作部との通信が必要な処理
本体部１０は、準備完了通知が来ると待ちを解除し、操作部２０との通信が必要な処理を実行する。
【００５５】
４．１：通信（通知ステップ、通知機能）
本体部１０は、操作部２０との通信が必要な処理の実行中に、操作部２０のプログラム２４０へ通知を送信する。
【００５６】
４．１．１：通信（通知送信ステップ、通知送信機能）
操作部２０のプログラム２４０は、通知を受信すると、アプリケーション２２２へ通知を送信する。
【００５７】
３．１．１．１：通知を利用
操作部２０のアプリケーション２２２は、受信した通知を起動処理に利用する。
【００５８】
次に図６を参照して内部シーケンスについて、図中のシーケンス番号と対比させ説明する。また以下の説明では、図４の機能ブロックと、図５の外部シーケンス図のシーケンス番号との対応を以下のフォーマットで記載する。
【００５９】
シーケンス番号：機能ブロック名
：シーケンス内容（外部シーケンス図のシーケンス番号）
【００６０】
１：起動処理部１１０：起動処理実行（１）
本体部１０の起動処理部１１０は、起動処理を実行する。単独でできる起動処理が完了したら、準備完了通知が来るのを待つ状態となる。
【００６１】
２：プログラム起動部２３０：プログラム起動（２）
操作部２０のプログラム起動部２３０は、プログラム２４０を起動する。
【００６２】
２．１：起動処理部２４１：起動処理実行（２．１）
プログラム２４０の起動処理部２４１は、操作部２０の起動処理を実行する。
【００６３】
２．１．１：起動処理部２４１：通信部へ準備完了通知を渡す（２．１．１）
プログラム２４０の起動処理部２４１は、プログラム２４０で実行すべき操作部２０の起動処理が完了すると、準備完了通知を通信部２４２へ渡す。ここで、プログラム２４０で実行すべき操作部２０の起動処理とは、例えば、操作部２０が本体部１０と通信が可能になる最低限の処理を含む。
【００６４】
２．１．１．１：通信部２４２：準備完了通知を送信（２．１．１）
プログラム２４０の通信部２４２は、準備完了通知を本体部１０へ送信する。
【００６５】
２．１．１．１．１：通信部１２０：準備完了通知を受信（２．１．１）
本体部１０の通信部１２０は、準備完了通知を受信する。
【００６６】
２．１．１．１．１．１：通信部１２０：準備完了通知を起動処理部へ渡す（２．１．１）
本体部１０の通信部１２０は、準備完了通知を起動処理部１１０へ渡す。
【００６７】
３．ＯＳ起動部２１０：ＯＳ起動（３）
操作部２０のＯＳ起動部２１０は、ＯＳ２２０を起動する。
【００６８】
３．１：アプリケーション起動部２２１：アプリケーション起動（３．１）
操作部２０のアプリケーション起動部２２１は、アプリケーション２２２を起動する。
【００６９】
３．１．１：起動処理部２２３：起動処理実行（３．１．１）
アプリケーション２２２の起動処理部２２３は、アプリケーション２２２で実行すべき操作部２０の起動処理を実行する。ここで、アプリケーション２２２で実行すべき操作部２０の起動処理とは、シーケンス２．２．１でのプログラム２４０で実行された起動処理を除く他の処理を含む。
【００７０】
４：起動処理部１１０：起動処理再開（４）
本体部１０の起動処理部１１０は、準備完了通知を受け取り、待ちを解除し起動処理を再開する。ここで再開する起動処理は、操作部２０との通信が必要な処理である。そのため、処理を再開するには、操作部２０が本体部１０と通信が可能になる最低限の処理（ここではシーケンス２．２．１の「プログラム２４０で実行すべき操作部２０の起動処理」を指す）を完了して、本体部１０との通信が可能になっている状態である必要がある。
本実施形態では、この準備完了通知の受け取りが早くなることで、この待ち時間をなくす、もしくは短縮できる。
【００７１】
４．１：起動処理部１１０：通知を通信部へ渡す（４．１）
本体部１０の起動処理部１１０は、操作部２０への通知を通信部１２０へ渡す。
【００７２】
４．１．１：通信部１２０：通知を送信（４．１）
本体部１０の通信部１２０は、通知を操作部２０の通信部２４２へ送信する。
【００７３】
４．１．１．１：通信部２４２：通知を受信（４．１）
操作部２０のプログラム２４０の通信部２４２は、本体部１０からの通知を受信する。
【００７４】
４．１．１．１．１：通信部２４２：通知を送信（４．１．１）
プログラム２４０の通信部２４２は、アプリケーション２２２の通信部２２４へ通知を送信する。この送信前や送信時にプログラム２４０で何らかの処理（例えば通知をアプリケーション向けに変換するなど）を実行しても良い。
【００７５】
３．１．１．１：通信部２２４：通知を起動処理部へ渡す（４．１．１）
アプリケーション２２２の通信部２２４は、通知を受信し、起動処理部２２３へ渡す。
【００７６】
３．１．１．１．１：起動処理部２２３：通知を利用（３．１．１．１）
アプリケーション２２２の起動処理部２２３は、受け取った通知を起動処理に利用する。この通知の内容は操作部２０の起動処理をする上で必要な本体部１０の持つパラメータなどの情報を含む。
【００７７】
なお、本実施形態では、本体部１０から操作部２０への方向の通知の送信について説明しているが、逆方向（操作部２０から本体部１０へ）の通知の送信も行ってよい。
【００７８】
本実施形態の効果を説明する。図５、図６を参照して説明したように、本実施形態の情報処理装置１では、本体部１０と操作部２０とが同時起動（並行起動状態が存在すればよく、必ずしも同時でなくてもよい）する場合に、操作部２０はＯＳ２２０と併せてプログラム２４０も起動し、プログラム２４０による操作部２０の起動処理が完了した時点で、プログラム２４０から本体部へ準備完了通知が送信される。本体部１０は、準備完了通知の受信に応じて、アプリケーション２２２への通知をプログラムに送信し、プログラム２４０は本体部１０から受信した通知を、ＯＳ２２０の起動完了後に起動したアプリケーション２２２へ送信する。
【００７９】
従来の本体部１０と操作部２０とが別のＣＰＵによって動作する装置では、装置起動時には、本体部１０が操作部２０との通信が必要な処理を行うためには、操作部２０のＯＳ２２０の起動が完了し、さらにＯＳ２２０内のアプリケーション２２２の起動が完了して、アプリケーション２２２から準備完了通知を受信するまで待機する必要があった。これに対して本実施形態では、上記構成により、アプリケーション２２２による操作部２０の起動処理の一部を担うプログラム２４０をＯＳ２２０から独立して動作可能に操作部２０内に設け、アプリケーション２２２の起動が完了する前にプログラム２４０が準備完了通知を前倒しで本体部１０に送信する。これにより、本体部１０では、従来の操作部２０にプログラム２４０を設けない構成と比べて、操作部２０から準備完了通知を早く受信できるので、「操作部との通信が必要な処理」を早く実施することが可能となり、「単独の起動処理」から「操作部との通信が必要な処理」までの待ち時間を無くす、または減らすことができる。この結果、起動時間を短縮することができる。
【００８０】
次に、上述のとおり、操作部２０はＯＳ２２０、アプリケーション２２２、プログラム２４０を備えるが、それぞれの具体的な形式について説明する。
【００８１】
ＯＳ２２０はＡｎｄｒｏｉｄやＷｉｎｄｏｗｓ、ｍａｃＯＳといった一般的なＯＳが想定される。本実施形態ではＯＳ２２０の形式はＡｎｄｒｏｉｄである。
【００８２】
アプリケーション２２２の形式はＯＳ２２０によって異なることが想定される。本実施形態のようにＯＳ２２０がＡｎｄｒｏｉｄの場合は、Ａｎｄｒｏｉｄ用アプリが一般的である。
【００８３】
プログラム２４０の形式は、アプリケーション２２２よりも起動が早い形式であることが条件となる。本実施形態ではｄｅａｍｏｎという一般的なバックグラウンドで動作するプログラム形式である。
【００８４】
アプリケーション２２２とプログラム２４０の間の通信は、プロセスが異なることからプロセス間での通信手段をとる必要がある。プロセス間通信の手段としては、一般的なＢｉｎｄｅｒ方式が想定され、他の手段を用いても良い。
【００８５】
プログラム２４０の処理は、もとは一つのアプリケーション２２２が実行する処理であったため、処理を分離した場合も通知にてパラメータを通知する手段が必要である。Ｂｉｎｄｅｒ方式はパラメータの通知が可能であるが、パラメータの通知が可能であれば他の方式を用いても良い。
【００８６】
操作部２０と本体部１０との間の通信はＵＳＢ接続や無線ＬＡＮといった一般的な接続手段が想定される。本実施形態の構成では操作部２０のプログラム２４０の通信部２４２が本体部１０の通信部１２０と通信を行うが、通信の頻度を減らすために本体部１０からの通知内容をプログラム２４０が内部で保管しておいてもよい。保管の手段としては、一般的なＣ言語やＣ＋＋などのファイル入出力手段によるファイル（記憶部）への書き出しが想定される。また、通知内容をアプリケーション２２２側で利用する場合は、プログラム２４０からアプリケーション２２２へ通知し、アプリケーション２２２側で保管することもまた可能である。
【００８７】
［第１変形例］
図７を参照して第１変形例を説明する。図７は、第１変形例における起動時のシーケンス図である。
【００８８】
本実施形態では、従来はアプリケーション２２２で完結していた処理（例えば操作部２０の起動処理）が、アプリケーション２２２とプログラム２４０に分かれる。このため、処理によっては、アプリケーション２２２とプログラム２４０との間で処理依頼の通知を送信、受信して処理を実施する必要がある。
【００８９】
プログラム２４０はアプリケーション２２２よりも早く起動するため、例えば図７に区間Ａで示すように、プログラム２４０からアプリケーション２２２へ処理依頼を送信しようとするタイミングで、まだアプリケーション２２２が起動していないというケースが発生する。しかしプログラム２４０がアプリケーション２２２の起動を待ち処理を完全に止めてしまうと、新たな待ちが発生して起動時間が長くなるという課題が発生する。
【００９０】
この課題を解決するため、第１変形例では、例えば図７に区間Ｂで示すように、アプリケーション２２２は起動後に、プログラム２４０へアプリケーション２２２の起動が完了をしたことを知らせる起動完了通知を送信し、プログラム２４０は起動完了通知をアプリケーション２２２から受信した後に、アプリケーション２２２へ処理依頼通知を送信する仕組みにする。
【００９１】
図７に示す処理を実施するために、アプリケーション２２２は例えば以下の機能を備えることができる。
・アプリケーション２２２の起動完了通知をプログラム２４０に送信する、通知送信部
・プログラム２４０からの処理依頼を受信する、通知受信部
・プログラム２４０からの処理依頼を受けて処理を実行する、処理実行部
【００９２】
同様に、プログラム２４０は、例えば以下の機能を備えることができる。
・アプリケーション２２２からの起動通知を受信する、通知受信部
【００９３】
［第２変形例］
【００９４】
図８を参照して第２変形例を説明する。図８は、第２変形例におけるアプリケーション２２２とプログラム２４０の間の処理シーケンス図である。
【００９５】
第１変形例で説明したアプリケーション２２２からの起動完了通知を待つことによって、プログラム２４０の処理が止まってしまうことが無いよう、第２変形例では図８に示すように、プログラム２４０内において処理を実行する「実行スレッド」と、アプリケーション２２２起動を待つ「待ちスレッド」とを分ける。
【００９６】
実行スレッドはアプリケーション２２２へ処理依頼したい場合に、例えば図８に区間Ｃで示すように、待ちスレッドへ一度処理の蓄積依頼をする。この処理により、実行スレッドは、そのままプログラム２４０の処理を続行することができ、アプリケーション２２２の起動待ちが発生しなくなる。
【００９７】
図８に示す処理を実施するために、プログラム２４０は例えば以下の機能を備えることができる。
・プログラム２４０の処理を実行し、アプリケーション２２２へ処理の蓄積依頼を行い、再開依頼を受け取り、送信依頼を行う、実行スレッド
・実行スレッドからの蓄積依頼を受けて蓄積し、アプリケーション２２２の起動通知を受けたら再開依頼を行う、待ちスレッド
・処理依頼通知、起動通知の送受信を行い、スレッドへ通知を渡す、送受信スレッド
・蓄積依頼を受け取った順番を保持して記憶し、起動通知を受けた際に順番通りに再開依頼を行う、蓄積手段
【００９８】
同様に、アプリケーション２２２は以下の機能を備えることができる。
・処理依頼通知、起動通知の送受信を行い、実効スレッドへ通知を渡す、送受信スレッド
・アプリケーション２２２起動処理を実行し、プログラム２４０からの処理依頼を受け取り処理を実行する、実行スレッド
【００９９】
［第３変形例］
図９〜図１４を参照して第３変形例を説明する。第３変形例は、第１変形例の特徴と第２変形例の特徴とを纏めて実施形態の構成に適用したものである。
【０１００】
図９は、第３変形例の情報処理装置１の機能ブロック図である。図９に示すように、第３変形例では、プログラム２４０が、通知蓄積部２４３と、送信不可判断部２４４とをさらに備える。
【０１０１】
アプリケーション２２２の通信部２２４は、上記実施形態の機能に加えて、アプリケーション２２２自体の起動が完了したとき、起動完了通知をプログラム２４０の通信部２４２へ送信する。
【０１０２】
プログラム２４０の通信部２４２は、起動処理部２４１から受け取った準備完了通知を本体部１０へ送信する。また、通信部２４２は、本体部１０から受信した通知を通知蓄積部２４３へ渡す。また、通信部２４２は、アプリケーション２２２の通信部２２４から受け取ったアプリケーション２２２の起動完了通知を送信不可判断部２４４へ渡す。
【０１０３】
プログラム２４０の通知蓄積部２４３は、定期的に送信不可判断部２４４の保持する判断の値を受け取り、値が「不可」の間は通信部２４２から受け取った通知を受け取った順に蓄積する。値が「可能」に変化したら、それまで蓄積していた通知を受け取った順に通信部２４２へ渡す。
【０１０４】
プログラム２４０の送信不可判断部２４４は、通信部２４２から判断を求められたときに内部で保持する値（「可能」「不可」のどちらか）を渡す。値の初期値は「不可」であり、プログラム２４０の通信部２４２から起動完了通知を受け取った時に「可能」に変化する。
【０１０５】
図１０は、第３変形例における起動時の外部シーケンス図である。図５を参照して説明した実施形態の外部シーケンス図との相違点のみを説明する。
【０１０６】
４．１．１：通知を蓄積
操作部２０のプログラム２４０は、アプリケーション２２２からの起動完了通知を受信していない間、ステップ４．１にて本体部１０から通知を受信したときには、その通知を蓄積する。
【０１０７】
４．１．２：送信以外の続けられる処理
操作部２０のプログラム２４０は、通知を蓄積した後、通知を送信する以外の続けられる処理を続行する。処理を続行することで、完全なアプリケーション起動待ち状態に陥るのを回避できる。
【０１０８】
３．１．１：起動完了通知
アプリケーション２２２は、ステップ３．１におけるアプリケーション２２２の起動が完了すると、起動完了通知をプログラム２４０に送信する。
【０１０９】
３．１．１．１：通知を送信
操作部２０のプログラム２４０は、アプリケーション２２２から起動完了通知を受信したら、ステップ４．１．１にて蓄積していた通知をアプリケーション２２２へ送信する。このとき、蓄積した順に通知を送信する。
【０１１０】
なお、図１０の「３．１．２：起動処理」と「３．１．２．１：通知を利用」は、図５の「３．１．１：起動処理」と「３．１．１．１：通知を利用」と同様の処理である。
【０１１１】
図１１Ａ，図１１Ｂは、第３変形例における起動時の内部シーケンス図である。図６を参照して説明した実施形態の内部シーケンス図との相違点のみを説明する。
【０１１２】
４．１．１．１．１：通信部２４２：通知蓄積部２４３へ通知を渡す（４．１．１）
操作部２０のプログラム２４０の通信部２４２は、ステップ４．１．１．１にて受信した通知を通知蓄積部２４３へ渡す。
【０１１３】
４．１．１．１．１．１：通知蓄積部２４３：送信不可判断部２４４から判断を受け取る（４．１．１）
操作部２０のプログラム２４０の通知蓄積部２４３は、送信不可判断部２４４から判断の値を受け取る。判断の初期値は「不可」であるため、ここでは「不可」が渡される。
【０１１４】
４．１．１．１．１．１．１：通知蓄積部２４３：通知を蓄積する（４．１．１）
操作部２０のプログラム２４０の通知蓄積部２４３は、「不可」の判断を受け取ったため通知を内部的に蓄積する。複数の通知を受信し順番に蓄積していく場合は、受信した順番を保持して蓄積する必要がある。この蓄積の方法としては、スレッド間のメッセージ送受信の仕組みでわざとメッセージを受信しないでおくことでメッセージキューに蓄積する方式や、一般的なデータ構造のキュー構造を実装して格納・取り出しを行う方式などの実施例が想定される。通知の蓄積の実施例については図１２、図１３を参照して後述する。
【０１１５】
３．１．１：通信部２２４：起動完了通知を送信（３．１．１）
操作部２０のアプリケーション２２２の通信部２２４は、ステップ３．１におけるアプリケーション２２２の起動が完了したら、アプリケーション２２２の起動完了通知をプログラム２４０へ送信する。この起動完了の判断基準は任意だが、通知を送信するために必要なプログラム２４０との通信準備が完了していることは必須条件となる。
【０１１６】
３．１．１．１：通信部２４２：起動完了通知を送信不可判断部２４４へ渡す（３．１．１．１）
操作部２０のプログラム２４０の通信部２４２は、アプリケーション２２２から起動完了通知を受信したら送信不可判断部２４４へ渡す。
【０１１７】
３．１．１．１．１：送信不可判断部２４４：判断を「可能」に変更する（３．１．１．１）
操作部２０のプログラム２４０の送信不可判断部２４４は、送信不可判断部２４４が内部的に持つ判断の値を「不可」から「可能」に変更する。
【０１１８】
３．１．１．１．２：通知蓄積部２４３：送信不可判断部２４４から判断を受け取る（３．１．１．１）
操作部２０のプログラム２４０の通知蓄積部２４３は、定期的に送信不可判断部２４４から判断を受け取って判断の値を確認する。
【０１１９】
３．１．１．１．２．１：通知蓄積部２４３：通知を取り出し通信部２４２へ渡す（３．１．１．１）
操作部２０のプログラム２４０の通知蓄積部２４３は、確認した判断が「可能」の場合、蓄積していた通知を取り出し通信部２４２へ渡す。
【０１２０】
３．１．１．１．２．２：通信部２４２：通知を送信する（３．１．１．１）
操作部２０のプログラム２４０の通信部２４２は、送信不可判断部２４４から受け取った判断が「可能」であった場合、蓄積していた通知をアプリケーション２２２へ送信する。蓄積していた通知の取り出しの実施例については図１２、図１３を参照して後述する。
【０１２１】
図１２、図１３を参照して、通知の蓄積方式の例について説明する。図１２は、第３変形例におけるアプリケーション２２２とプログラム２４０の間の処理シーケンス図である。
【０１２２】
図１２で用いる「メッセージ」とは、プロセス間やスレッド間でのやりとりに用いられ、送信関数と受信関数が用意されている。送信側が送信関数を用いてメッセージ送信すると、メッセージは一度メッセージキューと呼ばれる場所に蓄積される。受信側が受信関数を１回呼び出すと、メッセージキューに蓄積された順番に、メッセージを１個受信することができるという仕組みである。
【０１２３】
メッセージ管理の仕組みは、例えばＣ言語にあらかじめ用意されている一般的なメッセージ管理の仕組みなどでよい。例えばＣ言語では、snd_msg関数でメッセージ送信、rcv_msg関数でメッセージ受信ができる。
【０１２４】
図１２の例では、アプリケーション２２２の起動完了通知待ちの間、わざと通知送信処理のトリガーとなるメッセージを待ちスレッドが受信しないでおくことで、メッセージキューにメッセージが送信順に蓄積され、結果的に通知を蓄積したことと同義になる。
【０１２５】
以下、図１２のシーケンス図について詳しく説明する。
【０１２６】
１：起動完了通知待ち状態
起動完了通知待ちを行う専用のスレッドであるプログラム２４０の「待ちスレッド」は、まずアプリケーション２２２の起動完了通知待ち状態になる。これは機能ブロックの通知蓄積部２４３と送信不可判断部２４４に該当する。待ちスレッドは、待ち状態の間メッセージの受信関数を呼ばない。
【０１２７】
２：メッセージＡ
３：メッセージＢ
メインで処理を行うプログラム２４０の「実行スレッド」が、アプリケーション２２２へ通知送信をしたいため待ちスレッドへ通知送信処理のトリガーとなるメッセージを送信する。この例ではメッセージＡ（通知Ａの送信処理のトリガー）、メッセージＢ（通知Ｂの送信処理のトリガー）の順に２個送信している。実行スレッドは、機能ブロックの起動処理部２４１に該当する。
【０１２８】
４：アプリケーション起動
４．１：起動完了通知の送信
４．１．１：起動完了通知を渡す
アプリケーション２２２が起動完了すると、アプリケーション２２２はプログラム２４０へ起動完了通知を送信する。プログラム２４０の「送受信スレッド」は起動完了通知を受信すると、待ちスレッドへ起動完了通知を渡す。送受信スレッドは、機能ブロックの通信部２４２に該当する。
【０１２９】
５：メッセージ受信
６：再開依頼Ａ
６．１：通知送信依頼Ａ
６．１．１：通知Ａを送信
プログラム２４０の待ちスレッドは起動完了通知を受け取ると、待ち状態を解除し、メッセージの受信関数を呼ぶ。メッセージＡが最初にメッセージキューに蓄積されていたため、ここではメッセージＡを受信することになる。待ちスレッドはメッセージＡ（通知Ａの送信処理のトリガー）を受け取ったことで、実行スレッドに通知Ａの送信処理の再開依頼Ａをする。送信処理を再開した実行スレッドは送受信スレッドへ通知送信依頼Ａをする。送信スレッドは通知Ａをアプリケーション２２２へ送信する。
【０１３０】
７：メッセージ受信
８：再開依頼Ｂ
８．１：通知送信依頼Ｂ
８．１．１：通知Ｂを送信
プログラム２４０の待ちスレッドが次にメッセージ受信関数を呼ぶと、メッセージＢを受信する。その後はメッセージＡの処理と同様にメッセージＢについて処理を行い、通知Ｂをアプリケーション２２２へ送信する。
【０１３１】
図１３は、キュー構造を利用した蓄積構造の例を示す模式図である。図１２の例では、図１３に示すキュー構造と呼ばれる一般的なデータ構造を実装により実現する。キュー構造は格納されたデータについて、片方の端からデータを蓄積し、もう片方の端からデータを取り出す。この仕組みにより、蓄積した順番通りにデータを取り出すことができる構造である。
【０１３２】
このキュー構造実装部分は機能ブロックのプログラム２４０の通知蓄積部２４３に該当する。図１１の内部シーケンスのステップ「４．１．１．１．１．１．１：通知蓄積部：通知を蓄積する」でキュー構造に通知を蓄積し、ステップ「３．１．１．１．２．１：通知蓄積部：通知を取り出し通信部へ渡す」でキュー構造に蓄積していた通知を順番に取り出し、通信部２４２に渡し送信することとなる。
【０１３３】
なお、通知または通知の送信トリガーを蓄積する方法については、図１２、図１３に例示した方法以外の他の方法を用いてもよい。
【０１３４】
第３変形例の効果を説明する。プログラム２４０はアプリケーション２２２よりも早く起動するため、プログラム２４０からアプリケーション２２２へ処理依頼を送信しようとするタイミングで、まだアプリケーション２２２が起動していないというケースが発生し得る。しかしプログラム２４０がアプリケーション２２２の起動を待って処理を完全に止めてしまうと、新たな待ちが発生して起動時間が長くなる。これに対して第３変形例では、アプリケーション２２２は、アプリケーション２２２の起動処理が完了したときに起動完了通知をプログラム２４０に送信し、プログラム２４０は、起動完了通知を受信した後に、本体部１０から受信した通知をアプリケーション２２２に送信する。この構成により、上記の課題を解決でき、プログラム２４０はアプリケーション２２２の起動が完了した後に確実に通知を送信することが可能となる。また、プログラム２４０はアプリケーション２２２から起動完了通知を受信するまでは他の処理を実行できるので、プログラム２４０が待ち状態となるのを回避でき、起動時間を短縮化できる。
【０１３５】
また、第３変形例では、プログラム２４０は、プログラム２４０の処理を実行する実行スレッドと、処理のうちアプリケーション２２２の起動完了後に行う処理を蓄積する待ちスレッドと、を有する。プログラム２４０は、起動完了通知をアプリケーション２２２から受信した後に、待ちスレッドに蓄積されていた処理を実行スレッドに実行させる。この構成により、実行スレッドはアプリケーション２２２へ処理依頼したい場合に、待ちスレッドへ一度処理の蓄積依頼をし、そのままプログラム２４０の処理を続行することができる。これにより、アプリケーション２２２の起動完了通知を待つためにプログラム２４０の処理が止まってしまうことを防止でき、起動時間をさらに短縮化できる。
【０１３６】
また、第３変形例では、プログラム２４０は、本体部１０から受信した通知をアプリケーション２２２に送信可能か否かを判断する送信不可判断部２４４と、送信不可判断部２４４により送信不可と判断された通知を蓄積する通知蓄積部２４３と、を有する。送信不可判断部２４４は、起動完了通知をアプリケーション２２２から受信するとき、通知をアプリケーション２２２に送信可能との判断に切り替え、プログラム２４０は、送信不可判断部２４４の判断の切り替えに応じて、通知蓄積部２４３に蓄積されている通知をアプリケーション２２２へ送信する。
【０１３７】
この構成により、プログラム２４０は、アプリケーション２２２への通知の送信可否、すなわち、アプリケーション２２２の起動が完了したか否かを精度良く判断できるので、通知蓄積部２４３への通知の蓄積要否や、アプリケーション２２２への通知の送信可否の判断を精度よく行うことができる。これにより、プログラム２４０によるアプリケーション２２２への通知の送信処理をより効率よく行うことが可能となる。
【０１３８】
図１４は、通知をアプリケーションへ送信するかの要否判断する場合の内部シーケンス図である。
【０１３９】
本体部１０から受け取った通知の中には、アプリケーション２２２へ送信する必要のない、プログラム２４０だけで利用する通知も含まれる可能性がある。そのため、すべての通知をアプリケーション２２２へ送信するのではなく、アプリケーション２２２へ送信する必要のある通知かを判断して、必要ある通知のみ通知蓄積部２４３へ蓄積することも可能である。これにより、本体部１０からの通知のうち、アプリケーション２２２へ送信する必要がない（プログラム内の処理のみで利用する）通知について、通知蓄積部２４３への蓄積と、アプリケーション２２２への送信を省略でき、起動処理を早めることができる。
【０１４０】
概要の流れとしては、プログラム２４０の通信部２４２が本体部１０から通知を受信したとき、通信部２４２は通知を通知蓄積部２４３ではなく起動処理部２４１へ渡す。起動処理部２４１はアプリケーション２２２へ渡す必要がある通知内容か要否を判断し、渡す必要がなければプログラム２４０での起動処理に利用し、渡す必要があれば通知蓄積部２４３へ通知を渡す。通知蓄積部２４３は通常通りに送信不可判断部２４４からの判断「不可」に従い蓄積する、となる。
【０１４１】
このような要否判断を行う場合の処理について、図１１の内部シーケンス図から該当部分のみを抜粋した図１４を参照して説明する。
【０１４２】
４．１．１．１．１：通信部２４２：起動処理部２４１へ通知を渡す
プログラム２４０の通信部２４２は、ステップ４．１．１．１にて本体部１０から受信した通知を、起動処理部２４１へ渡す。
【０１４３】
４．１．１．１．１．１：起動処理部２４１：アプリケーション２２２への送信要否を判断
プログラム２４０の起動処理部２４１は、アプリケーション２２２へ渡す必要がある通知内容か要否を判断する。本ステップにてアプリケーション２２２へ送信する必要ある通知と判断した場合には、以降のステップに進む。
【０１４４】
４．１．１．１．１．２：起動処理部２４１：通知を通知蓄積部２４３へ渡す
プログラム２４０の起動処理部２４１は、アプリケーション２２２へ送信する必要がなければプログラム２４０での起動処理に利用し、アプリケーション２２２へ送信する必要があれば通知蓄積部２４３へ通知を渡す。
【０１４５】
４．１．１．１．１．３：通知蓄積部２４３；送信不可判断部２４４から判断を受け取る
４．１．１．１．１．３．１：通知蓄積部：通知を蓄積する
この蓄積のシーケンスは図１２のステップ４．１．１．１．１．１と、ステップ４．１．１．１．１．１．１から変更はない。
【０１４６】
なお、ステップ４．１．１．１．１．１においてアプリケーション２２２へ送信する必要ある通知と判断したとき、既に起動完了通知をアプリケーション２２２から受信済みの場合には、この通知を通知蓄積部２４３へ蓄積せずにアプリケーション２２２へ送信してもよい。これにより、既にアプリケーション２２２が起動完了している場合に、一度通知を蓄積する時間を省略でき、アプリケーション２２２へ通知をより早く送信することができる。
【０１４７】
また、プログラム２４０が、本体部１０から受信した通知からアプリケーション２２２へ送信する必要がある情報のみを取り出して新たな通知を作成し、作成した新たな通知をアプリケーション２２２へ送信する構成でもよい。これにより、アプリケーション２２２には不要な情報をプログラム２４０側で削ることで、送信データ量を減らすことができ、送信時間を短縮することができる。
【０１４８】
以上、具体例を参照しつつ本実施形態について説明した。しかし、本開示はこれらの具体例に限定されるものではない。これら具体例に、当業者が適宜設計変更を加えたものも、本開示の特徴を備えている限り、本開示の範囲に包含される。前述した各具体例が備える各要素およびその配置、条件、形状などは、例示したものに限定されるわけではなく適宜変更することができる。前述した各具体例が備える各要素は、技術的な矛盾が生じない限り、適宜組み合わせを変えることができる。
【符号の説明】
【０１４９】
１    情報処理装置
１０    本体部
１１１    ＣＰＵ（第１のＣＰＵ）
２０    操作部
２１    ＣＰＵ（第２のＣＰＵ）
２１０    ＯＳ起動部
２２０    ＯＳ
２２１    アプリケーション起動部
２２２    アプリケーション
２３０    プログラム起動部
２４０    プログラム
２４１    起動処理部
２４２    通信部
【先行技術文献】
【特許文献】
【０１５０】
【特許文献１】特開２００３−３３７７１１号公報
【特許文献２】特開２００５−２０２１０５号公報
【図１】
2020077354.tif 000003
【図２】
2020077354.tif 000004
【図３】
2020077354.tif 000005
【図４】
2020077354.tif 000006
【図５】
2020077354.tif 000007
【図６】
2020077354.tif 000008
【図７】
2020077354.tif 000009
【図８】
2020077354.tif 000010
【図９】
2020077354.tif 000011
【図１０】
2020077354.tif 000012
【図１１Ａ】
2020077354.tif 000013
【図１１Ｂ】
2020077354.tif 000014
【図１２】
2020077354.tif 000015
【図１３】
2020077354.tif 000016
【図１４】
2020077354.tif 000017