JPWO2006134691A1 - 情報処理装置、復旧装置、プログラム及び復旧方法 - Google Patents
情報処理装置、復旧装置、プログラム及び復旧方法 Download PDFInfo
- Publication number
- JPWO2006134691A1 JPWO2006134691A1 JP2007521111A JP2007521111A JPWO2006134691A1 JP WO2006134691 A1 JPWO2006134691 A1 JP WO2006134691A1 JP 2007521111 A JP2007521111 A JP 2007521111A JP 2007521111 A JP2007521111 A JP 2007521111A JP WO2006134691 A1 JPWO2006134691 A1 JP WO2006134691A1
- Authority
- JP
- Japan
- Prior art keywords
- domain
- recovery
- failure
- specific
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1479—Generic software techniques for error detection or fault masking
- G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/556—Detecting local intrusion or implementing counter-measures involving covert channels, i.e. data leakage between processes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/82—Protecting input, output or interconnection devices
- G06F21/85—Protecting input, output or interconnection devices interconnection devices, e.g. bus-connected or in-line devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1479—Generic software techniques for error detection or fault masking
- G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
- G06F11/1484—Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2113—Multi-level security, e.g. mandatory access control
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Debugging And Monitoring (AREA)
- Computer And Data Communications (AREA)
- Mobile Radio Communication Systems (AREA)
- Information Transfer Between Computers (AREA)
- Multi Processors (AREA)
Abstract
追加されたアプリケーションプログラム及びデバイスドライバによって障害が生じたドメインを、安全性、信頼性を確保して復旧する情報処理装置は、信頼度に基づいてそれぞれ分離された、メーラーやブラウザ等の基本処理を有する最高信頼度ドメイン１５０Ａと、中信頼度ドメイン１５０Ｂと、低信頼度ドメイン１５０Ｃとを備え、さらに、各ドメインから通知される障害の復旧要求及びドメイン毎に予め設定された復旧条件とに基づいて障害が発生したドメインに対して障害の復旧処理を行う復旧手段とを有する。最高信頼度ドメイン１５０Ａは、中信頼度ドメイン１５０Ｂや低信頼度ドメイン１５０Ｃへのデータ送信時にこれらのドメインの障害を検知し、ドメイン停止復旧手段４００を介して、これらのドメインを復旧する。
Description
本発明は、マルチプロセッサにより構成される情報処理装置に関し、特に外部から取得した追加処理を実行することが可能なプロセッサを有するドメインを備える情報処理装置、復旧装置、プログラム及び復旧方法に関する。
携帯電話機（ｍｏｂｉｌｅ ｐｈｏｎｅ）等の情報通信端末装置において、通常、該端末装置の基本性能を実現するための基本処理（例えば呼処理機能、インターネットアクセス用のブラウザ機能、電子メール機能、画面制御機能等）は、オペレーティングシステムとともに予めインストールされており、上記基本処理とは別の追加処理（プログラム）については、ユーザの操作等により、ネットワーク等外部から、該端末装置にダウンロードして実行、インストールが行われる。しかしながら、ダウンロードした追加処理を実行した場合、オペレーティングシステムや基本処理等は、該追加処理による攻撃に曝される可能性がある。
図４２は、ダウンロードされた追加処理を実行する情報通信端末装置の典型的な構成の一例を模式的に示す図である。図４２には、よく知られた典型的な装置構成がブロック図にて模式的に例示されている。以下では、追加処理が、ネイティブコード（提供者側でコンパイル、またはアセンブル処理されたバイナリコード）で提供されるアプリケーションプログラムやデバイスドライバ（デバイスへのアクセス要求、デバイスからの割り込み処理を行うソフトウェアであり、「Ｉ／Ｏドライバ」とも言う）である場合について説明する。
図４２に示す構成において、追加処理２３をダウンロードして実行したとき（追加処理２３がデバイスドライバの場合には、オペレーティングシステムに組み込んで実行したとき）、基本処理２２、オペレーティングシステム（「ＯＳ」という）２１、ＣＰＵ（Ｃｏｎｔｒｏｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０、メモリ５０、入出力デバイス（Ｉ／Ｏ）６０に対して、追加処理２３から、直接的に攻撃が行われる可能性がある。その理由は、基本処理２２、ＣＰＵ１０、ＯＳ２１、メモリ５０、あるいは入出力デバイス（Ｉ／Ｏ）に対する、追加処理２３からの攻撃を制限し、安全な実行環境を実現する手段が実装されていないためである。すなわち、図４２に示す構成の場合、追加処理２３は基本処理２２への処理要求、ＯＳ２１への処理依頼、ＣＰＵ１０、メモリ５０、及び入出力デバイス６０への処理要求を任意に発行することができ、ハードウェア、ソフトウェアの各種資源へのアクセスも自在とされている。このため、悪意の追加処理２３（あるいは、悪意は無くともウィルス等に感染した追加処理）は、無防備なＯＳ２１、基本処理２２等に対して攻撃自在とされる。
追加デバイスドライバが、例えばレジデント（常駐型）ドライバとしてＯＳ２１のカーネル内に組み込まれる場合があり、該デバイスドライバの信頼性は、ＯＳ２１の信頼性、及び性能にそのまま影響を及ぼすことになる。これは、デバイスドライバが、デバイスへの処理設定と、デバイスからの割り込み時にスケジューラから起動される割り込みサービスとを含み、割り込みサービスの実行時間（この間、再スケジュールは禁止される）は処理性能から特段に短い時間（例えばミリ秒以下）に制限されているという、デバイスドライバの特性からも、明らかである。つまり、追加デバイスドライバが仮に悪意の在るドライバである場合、情報処理装置の処理性能を容易に低下させることが出来る。これは、常駐型でなく、ローダブルドライバ（メモリに選択的にロード、アンロードされるドライバ）の場合も、同様である。このように、追加処理としてインストールされた悪意のあるドライバによって攻撃が行われた場合には、ＯＳ２１のカーネルが直接攻撃されることになり、致命的ともなる（実質的に動作不能となる）。
そこで、ダウンロードされた追加処理の実行環境に制限を与え、基本処理等を保護する設計方式が、従来より、各種提案されている。以下、いくつかの典型例に即して概説しておく。
図４３では、ソフトウェアによる追加処理の実行保護環境を提供する構成の一典型例を示す図である。図４３に示す例では、ネイティブコードの追加処理２３は、仮想マシン２４上で実行させる構成とされている。一例として、追加処理２３が、ＪＡＶＡ（登録商標）バイトコードで記述されているものとすると、ダウンロードされたＪＡＶＡ（登録商標）バイトコードは、仮想マシン２４をなすＪＶＭ（ＪＡＶＡ（登録商標）仮想マシン）上で実行される。
かかる構成において、基本処理２２やＯＳ２１等は、ソフト的に、追加処理２３とは分離され、その安全性が確保されることになる。すなわち、追加処理２３は、仮想マシン２４を介してのみ、ＯＳ２１、ＣＰＵ１０、メモリ５０、Ｉ／Ｏ６０等へアクセスが行われる。仮想マシン２４には、通常、ＯＳ２１のカーネルモードでの実行（例えば特権的な命令の実行）等を行う権限が付与されていず、このため、追加処理２３が、ＯＳ２１を直接的に操作することは出来ない。また、仮想マシン２４は、一般に、インタープリタ方式で追加処理２３の命令コードを実行するため、追加処理２３の命令・動作が適正であるか監視することが容易であり、例えば追加処理２３からのハードウェア資源及びソフトウェア資源に対する不当なアクセス（例えば多重のデータをネットワーク上あるいは画面上に出力する等）を制限することで、仮想マシン２４がソフト的な保護フィルタ、あるいは防護壁又は防護ゲートの役割を担うことも出来る。このように、仮想マシン２４を介して、基本処理２２、ＯＳ２１等は、追加処理２３とは、ソフト的には分離されている。
しかしながら、図４３に示した仮想マシン方式は、以下の問題点を有している。
ダウンロードされた追加処理２３から、仮想マシン２４の抜け（例えばセキュリティホール）への攻撃等がなされた場合、システムの安全性が損なわれることになる。
また、通常、ＪＡＶＡ（登録商標）仮想マシン等の仮想マシン２４は、ＪＡＶＡ（登録商標）バイトコード等の命令コードを、一命令ずつ解釈実行するインタープリタ方式であるため、その実行速度は遅い。
さらに、仮想マシン２４は、追加処理２３を実行する時、システムコールを発行することで、ＯＳ２１への処理依頼を行っているが、システムコールのオーバヘッドは大であることから、処理の実行は遅い。例えば仮想マシン２４において、追加処理２３の１つの命令に対応するシステ厶コールが１つ又は複数発行される。ユーザモードからのシステムコール発行によるシステムモードへのコンテクスト・スイッチング、ＯＳ２１のシステムコールエントリ部におけるシステムコールのパケットデータのデコード、パラメータ等の正
当性チェック（エラー検出処理）、処理の振分（ディスパッチ）さらに、処理終了時の処理結果の引渡し及びコンテクスト・スイッチング、カーネル空間からユーザ空間への切り替え等、一連の制御が行われ、オーバヘッドが大きい。
そして、図４３に示す構成の場合、追加処理２３として、デバイスドライバをＯＳ２１に組み込むことは出来ない。図４３からも明らかなように、仮想マシン２４はＯＳ２１の上層に位置している。仮想マシン２４は、追加処理２３のコードに基づき、ＯＳ２１に対して処理依頼を行い、ＯＳ２１から処理結果を受け取り、必要に応じて追加処理２３に返す構成とされており、追加処理をデバイスドライバとしてＯＳ２１内に組み込もうとすると、追加処理の実行を制御する仮想マシンも、ＯＳ２１内に組み込むことが必要となり、かかる構成は、図４３に示す仮想マシン方式では、原理的に不可能であるためである。
ソフトウェアによる別のセキュリティ管理方式として、例えば図４４に示すような構成も知られている。図４４に示すように、追加処理２３には、それが信頼できるものであることを証明するための証明書２５が添付されて、端末（情報処理装置）にダウンロードされる。端末側では、添付された証明書２５の内容をチェックし、添付された証明書２５が正しい証明書であると認証された場合に、ダウンロードされた追加処理２３のインストール、実行を許可する構成とされている。証明書２５としては、デジタル署名（ＩＴＵ−Ｔ ＸＳ０９）を用いても良い。例えば証明書２５には、証明される期間とその公開鍵、ＣＡ（認証局）のデジタル署名（証明される機関や公開鍵などをＣＡの秘密鍵で暗号化したもの）が格納され、証明書の認証を行う場合には、ＣＡのデジタル署名の部分を、ＣＡの公開鍵で解読して証明書のデータの内容と一致するか否か確認し、一致する場合に、証明書のデータを信頼しても良いと判断される。あるいは、証明書２５は、真正のベンダーを証明するものであれば、任意の証明書であっても良い。なお、デバイスドライバの署名機能（Ｄｒｉｖｅｒ Ｓｉｇｎｉｎｇ）は、例えばＷｉｎｄｏｗｓ（登録商標）２０００等にも実装されている。
図４４に示した方式の場合、追加処理２３はネイティブコードで提供することができ、図４３に示した仮想マシン方式と比べて、高速実行が可能である。また、追加処理２３として、アプリケーション、デバイスドライバの実行も可能である。しかしながら、システムの信頼性は、追加処理２３の安全性に全面的に依拠している。つまり、追加処理２３に事前に検知し得ない問題があると、システムに致命的損害をもたらす可能性もある。
図４５は、セキュリティ管理をハードウェアで行うプロセッサの構成を示す図である。図４５を参照すると、ＣＰＵ１１は、安全（セキュア）モード１２と、非安全（ノンセキュア）モード１３を有し、ダウンロードされた追加処理２３と該追加処理２３に対応したＯＳ２１Ｂは、もっぱらノンセキュアモード１３で実行される。そして、メモリ管理ユニット１４は、ノンセキュアモード１３で実行されるメモリの領域（アドレス空間）を、セキュアモード１２でアクセスされるメモリの領域と分離して管理し、ノンセキュアモード１３からセキュアモード１２のメモリ領域へのアクセスは禁止される。すなわち、メモリ管理ユニット１４は、ノンセキュアモード１３からのメモリのアクセス制御を行いノンセキュアモード１３からセキュアモード１２のメモリ領域へのアクセスを禁止する制御を行っている。
このように、図４５に示す構成においては、基本処理２２をセキュアモード１２で実行し、仮想的に、追加処理２３を実行するＣＰＵと別ＣＰＵに分離することで、安全性の向上を図っている。
しかしながら、セキュアモードとノンセキュアモードは、ＣＰＵ上で、時分割で実行されており、ノンセキュアモードから復帰しない場合には、セキュアモードでのシステムの動作は行われない。
また、ノンセキュアモードとセキュアモードを時分割処理しているため、その切替時、モード遷移等のオーバヘッドがかかる。
さらに、追加処理２３をデバイスドライバとし、ノンセキュアモードのＯＳ２１Ｂ内に組み込む場合、ドライバに悪意があると、セキュアモードに復帰することが出来なくなる可能性があり、システムに致命的な損害をもたらす可能性がある。
なお、図４５に示した構成と同様、システムメモリ中に分離域を設け、ノーマル実行モードと分離実行モードを構えたプロセッサとして、特表２００４−５００６６６号公報（文献１）の記載が参照される。文献１に記載の装置において、ノーマル実行モードは、プロセッサが非安全環境、すなわち分離実行モードによって提供されるセキュリティ機能がない通常の動作モードで動作するモードであり、ノーマル実行モードからは分離域へのアクセスが禁止され、分離実行モードでは、所定の分離命令の実行がサポートされる構成とされている。なお、かかる構成も、ノーマル実行モードと分離実行モードを時分割処理しているため、その切替時、モード遷移等のオーバヘッドがかかる。
また、２つのプロセッサユニットとスイッチユニットを備え、１つのプロセッサユニットが公共データ通信ネットワークと接続され、他方のプロセッサユニットは公共データ通信ネットワークと接続せず、データセキュリティ用ユニットとして機能する構成が開示されている（特表２００２−５４２５３７号公報（文献２）参照）。文献２に記載されるシステムでは、公共データ通信ネットワークに接続されるプロセッサユニットと、データセキュリティ用ユニットをスイッチで分離しており、データセキュリティ用ユニットの安全性を確保している。しかしながら、公共データ通信ネットワークに接続されるプロセッサユニットが、前述した追加処理（ネットワーク等からダウンロードされた追加処理）の実行により、攻撃されることの対策に関しては、いささかも考慮されていない。データセキュリティ用ユニットは安全であっても、公共データ通信ネットワークに接続されるプロセッサユニットは追加処理による攻撃に対する有効なセキュリティ機構は具備していない。このため、公共データ通信ネットワークに接続されるプロセッサユニットにセキュリティ管理を実現する場合、前述したいずれかの方式を採用する必要がある。
さらに、プロセッサ上で分離された実行プログラムあるいはオペレーティングシステムを同時に実行するシステムにおいて、不正なプログラムの実行環境を保護するために、第１のプログラムが実行される間、第１のプログラムのみが利用するメモリ空間が設定され、第１のプログラムとコンピュータの実行環境との通信は、共有メモリ空間の利用、専用の割り込み、あるいは専用のＩ／Ｏポートを含む単一のリンクを介して行われ、第１のプログラムは、制限された実行環境において、設定されたメモリ空間と単一のリンクを除いてプロセッサ上のリソースをアクセスすることが制限されるようにした構成が特表２００２−５３３７９１号公報（文献３）に記載されている。この文献３に記載された方法の場合、第１のプログラムは、設定されたメモリ空間と単一のリンク（共有メモリ空間の利用、専用の割り込み、あるいは専用のＩ／Ｏポート）を除いてプロセッサ上のリソースをアクセスすることが制限されるため、第１のプログラムを、デバイスドライバとして用いることは出来ず、デバイスドライバを含む追加処理に適用することは出来ない。
また、後述される本発明で用いられるプロセッサ間通信手段に関連する技術を開示した刊行物として、特開平６−３３２８６４号公報（文献４）には、マルチプロセッサシステムにおけるＣＰＵ間通信方式が開示されている。この文献４には、マルチプロセッサが共通メモリを利用してＣＰＵ間通信を行うにあたり、ＣＰＵ２がＣＰＵ１に割り込みを発生させる場合、ＣＰＵ１に対する固定領域における自己用のＣＰＵ間通信情報書き込み領域に、通信情報を書き込んで割り込みを発生し、ＣＰＵ１では、割り込みが発生すると、ＣＰＵ２に対応するＣＰＵ間通信情報書き込み領域をアクセスして割り込み処理を実行する構成がその従来技術として記載されており、さらに、共有メモリのアクセス回数を削減するようにした発明が記載されている。
さらに、特開２００１−１５４９９９号公報（文献５）では、プロセッサ診断回路が自プロセッサの起動時に故障を検出してサービスプロセッサに復旧を依頼し、サービスプロセッサがその復旧の処理を行う並列計算機システムを提案している。
文献１：特表２００４−５００６６６号公報
文献２：特表２００２−５４２５３７号公報
文献３：特表２００２−５３３７９１号公報
文献４：特開平６−３３２８６４号公報
文献５：特開２００１−１５４９９９号公報
上記したように、ダウンロードされた、悪意のある、もしくは過失の追加処理からの攻撃に対する安全性確保の対策を施した従来の装置は、処理性能の点、デバイスドライバの実行が不可である点、安全性確保に問題がある点等、実用上、各種課題が残されている。特に、図４３、及び図４５に示したように、情報処理装置に関して、装置外部から、追加デバイスドライバのダウンロードが不可である設計方式（アーキテクチャ）は、デバイスの追加、機能追加当が実質的に不可能であることを意味しており、この点で、可用性（ａｖａｉｌａｂｉｌｉｔｙ）が制限される。
一方、前述したように、追加デバイスドライバを例えばカーネルモードで動作させる場合には、ＯＳ、システムの信頼性に直接影響を及ぼすことから、特段の安全性確保、信頼性の向上が要請されている。
また、文献５に開示された技術を一例とする従来の並列計算機システムにおける復旧処理では、通知された復旧要求等がウィルスを含んでいる等の悪意のある要求に対しても処理を実行してしまうという問題点がある。
したがって、本発明の目的は、追加されたアプリケーションプログラム及びデバイスドライバによって障害が生じたドメインを、安全性、信頼性を確保して復旧する情報処理装置、復旧装置、プログラム及び復旧方法を提供することにある。
図４２は、ダウンロードされた追加処理を実行する情報通信端末装置の典型的な構成の一例を模式的に示す図である。図４２には、よく知られた典型的な装置構成がブロック図にて模式的に例示されている。以下では、追加処理が、ネイティブコード（提供者側でコンパイル、またはアセンブル処理されたバイナリコード）で提供されるアプリケーションプログラムやデバイスドライバ（デバイスへのアクセス要求、デバイスからの割り込み処理を行うソフトウェアであり、「Ｉ／Ｏドライバ」とも言う）である場合について説明する。
図４２に示す構成において、追加処理２３をダウンロードして実行したとき（追加処理２３がデバイスドライバの場合には、オペレーティングシステムに組み込んで実行したとき）、基本処理２２、オペレーティングシステム（「ＯＳ」という）２１、ＣＰＵ（Ｃｏｎｔｒｏｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０、メモリ５０、入出力デバイス（Ｉ／Ｏ）６０に対して、追加処理２３から、直接的に攻撃が行われる可能性がある。その理由は、基本処理２２、ＣＰＵ１０、ＯＳ２１、メモリ５０、あるいは入出力デバイス（Ｉ／Ｏ）に対する、追加処理２３からの攻撃を制限し、安全な実行環境を実現する手段が実装されていないためである。すなわち、図４２に示す構成の場合、追加処理２３は基本処理２２への処理要求、ＯＳ２１への処理依頼、ＣＰＵ１０、メモリ５０、及び入出力デバイス６０への処理要求を任意に発行することができ、ハードウェア、ソフトウェアの各種資源へのアクセスも自在とされている。このため、悪意の追加処理２３（あるいは、悪意は無くともウィルス等に感染した追加処理）は、無防備なＯＳ２１、基本処理２２等に対して攻撃自在とされる。
追加デバイスドライバが、例えばレジデント（常駐型）ドライバとしてＯＳ２１のカーネル内に組み込まれる場合があり、該デバイスドライバの信頼性は、ＯＳ２１の信頼性、及び性能にそのまま影響を及ぼすことになる。これは、デバイスドライバが、デバイスへの処理設定と、デバイスからの割り込み時にスケジューラから起動される割り込みサービスとを含み、割り込みサービスの実行時間（この間、再スケジュールは禁止される）は処理性能から特段に短い時間（例えばミリ秒以下）に制限されているという、デバイスドライバの特性からも、明らかである。つまり、追加デバイスドライバが仮に悪意の在るドライバである場合、情報処理装置の処理性能を容易に低下させることが出来る。これは、常駐型でなく、ローダブルドライバ（メモリに選択的にロード、アンロードされるドライバ）の場合も、同様である。このように、追加処理としてインストールされた悪意のあるドライバによって攻撃が行われた場合には、ＯＳ２１のカーネルが直接攻撃されることになり、致命的ともなる（実質的に動作不能となる）。
そこで、ダウンロードされた追加処理の実行環境に制限を与え、基本処理等を保護する設計方式が、従来より、各種提案されている。以下、いくつかの典型例に即して概説しておく。
図４３では、ソフトウェアによる追加処理の実行保護環境を提供する構成の一典型例を示す図である。図４３に示す例では、ネイティブコードの追加処理２３は、仮想マシン２４上で実行させる構成とされている。一例として、追加処理２３が、ＪＡＶＡ（登録商標）バイトコードで記述されているものとすると、ダウンロードされたＪＡＶＡ（登録商標）バイトコードは、仮想マシン２４をなすＪＶＭ（ＪＡＶＡ（登録商標）仮想マシン）上で実行される。
かかる構成において、基本処理２２やＯＳ２１等は、ソフト的に、追加処理２３とは分離され、その安全性が確保されることになる。すなわち、追加処理２３は、仮想マシン２４を介してのみ、ＯＳ２１、ＣＰＵ１０、メモリ５０、Ｉ／Ｏ６０等へアクセスが行われる。仮想マシン２４には、通常、ＯＳ２１のカーネルモードでの実行（例えば特権的な命令の実行）等を行う権限が付与されていず、このため、追加処理２３が、ＯＳ２１を直接的に操作することは出来ない。また、仮想マシン２４は、一般に、インタープリタ方式で追加処理２３の命令コードを実行するため、追加処理２３の命令・動作が適正であるか監視することが容易であり、例えば追加処理２３からのハードウェア資源及びソフトウェア資源に対する不当なアクセス（例えば多重のデータをネットワーク上あるいは画面上に出力する等）を制限することで、仮想マシン２４がソフト的な保護フィルタ、あるいは防護壁又は防護ゲートの役割を担うことも出来る。このように、仮想マシン２４を介して、基本処理２２、ＯＳ２１等は、追加処理２３とは、ソフト的には分離されている。
しかしながら、図４３に示した仮想マシン方式は、以下の問題点を有している。
ダウンロードされた追加処理２３から、仮想マシン２４の抜け（例えばセキュリティホール）への攻撃等がなされた場合、システムの安全性が損なわれることになる。
また、通常、ＪＡＶＡ（登録商標）仮想マシン等の仮想マシン２４は、ＪＡＶＡ（登録商標）バイトコード等の命令コードを、一命令ずつ解釈実行するインタープリタ方式であるため、その実行速度は遅い。
さらに、仮想マシン２４は、追加処理２３を実行する時、システムコールを発行することで、ＯＳ２１への処理依頼を行っているが、システムコールのオーバヘッドは大であることから、処理の実行は遅い。例えば仮想マシン２４において、追加処理２３の１つの命令に対応するシステ厶コールが１つ又は複数発行される。ユーザモードからのシステムコール発行によるシステムモードへのコンテクスト・スイッチング、ＯＳ２１のシステムコールエントリ部におけるシステムコールのパケットデータのデコード、パラメータ等の正
当性チェック（エラー検出処理）、処理の振分（ディスパッチ）さらに、処理終了時の処理結果の引渡し及びコンテクスト・スイッチング、カーネル空間からユーザ空間への切り替え等、一連の制御が行われ、オーバヘッドが大きい。
そして、図４３に示す構成の場合、追加処理２３として、デバイスドライバをＯＳ２１に組み込むことは出来ない。図４３からも明らかなように、仮想マシン２４はＯＳ２１の上層に位置している。仮想マシン２４は、追加処理２３のコードに基づき、ＯＳ２１に対して処理依頼を行い、ＯＳ２１から処理結果を受け取り、必要に応じて追加処理２３に返す構成とされており、追加処理をデバイスドライバとしてＯＳ２１内に組み込もうとすると、追加処理の実行を制御する仮想マシンも、ＯＳ２１内に組み込むことが必要となり、かかる構成は、図４３に示す仮想マシン方式では、原理的に不可能であるためである。
ソフトウェアによる別のセキュリティ管理方式として、例えば図４４に示すような構成も知られている。図４４に示すように、追加処理２３には、それが信頼できるものであることを証明するための証明書２５が添付されて、端末（情報処理装置）にダウンロードされる。端末側では、添付された証明書２５の内容をチェックし、添付された証明書２５が正しい証明書であると認証された場合に、ダウンロードされた追加処理２３のインストール、実行を許可する構成とされている。証明書２５としては、デジタル署名（ＩＴＵ−Ｔ ＸＳ０９）を用いても良い。例えば証明書２５には、証明される期間とその公開鍵、ＣＡ（認証局）のデジタル署名（証明される機関や公開鍵などをＣＡの秘密鍵で暗号化したもの）が格納され、証明書の認証を行う場合には、ＣＡのデジタル署名の部分を、ＣＡの公開鍵で解読して証明書のデータの内容と一致するか否か確認し、一致する場合に、証明書のデータを信頼しても良いと判断される。あるいは、証明書２５は、真正のベンダーを証明するものであれば、任意の証明書であっても良い。なお、デバイスドライバの署名機能（Ｄｒｉｖｅｒ Ｓｉｇｎｉｎｇ）は、例えばＷｉｎｄｏｗｓ（登録商標）２０００等にも実装されている。
図４４に示した方式の場合、追加処理２３はネイティブコードで提供することができ、図４３に示した仮想マシン方式と比べて、高速実行が可能である。また、追加処理２３として、アプリケーション、デバイスドライバの実行も可能である。しかしながら、システムの信頼性は、追加処理２３の安全性に全面的に依拠している。つまり、追加処理２３に事前に検知し得ない問題があると、システムに致命的損害をもたらす可能性もある。
図４５は、セキュリティ管理をハードウェアで行うプロセッサの構成を示す図である。図４５を参照すると、ＣＰＵ１１は、安全（セキュア）モード１２と、非安全（ノンセキュア）モード１３を有し、ダウンロードされた追加処理２３と該追加処理２３に対応したＯＳ２１Ｂは、もっぱらノンセキュアモード１３で実行される。そして、メモリ管理ユニット１４は、ノンセキュアモード１３で実行されるメモリの領域（アドレス空間）を、セキュアモード１２でアクセスされるメモリの領域と分離して管理し、ノンセキュアモード１３からセキュアモード１２のメモリ領域へのアクセスは禁止される。すなわち、メモリ管理ユニット１４は、ノンセキュアモード１３からのメモリのアクセス制御を行いノンセキュアモード１３からセキュアモード１２のメモリ領域へのアクセスを禁止する制御を行っている。
このように、図４５に示す構成においては、基本処理２２をセキュアモード１２で実行し、仮想的に、追加処理２３を実行するＣＰＵと別ＣＰＵに分離することで、安全性の向上を図っている。
しかしながら、セキュアモードとノンセキュアモードは、ＣＰＵ上で、時分割で実行されており、ノンセキュアモードから復帰しない場合には、セキュアモードでのシステムの動作は行われない。
また、ノンセキュアモードとセキュアモードを時分割処理しているため、その切替時、モード遷移等のオーバヘッドがかかる。
さらに、追加処理２３をデバイスドライバとし、ノンセキュアモードのＯＳ２１Ｂ内に組み込む場合、ドライバに悪意があると、セキュアモードに復帰することが出来なくなる可能性があり、システムに致命的な損害をもたらす可能性がある。
なお、図４５に示した構成と同様、システムメモリ中に分離域を設け、ノーマル実行モードと分離実行モードを構えたプロセッサとして、特表２００４−５００６６６号公報（文献１）の記載が参照される。文献１に記載の装置において、ノーマル実行モードは、プロセッサが非安全環境、すなわち分離実行モードによって提供されるセキュリティ機能がない通常の動作モードで動作するモードであり、ノーマル実行モードからは分離域へのアクセスが禁止され、分離実行モードでは、所定の分離命令の実行がサポートされる構成とされている。なお、かかる構成も、ノーマル実行モードと分離実行モードを時分割処理しているため、その切替時、モード遷移等のオーバヘッドがかかる。
また、２つのプロセッサユニットとスイッチユニットを備え、１つのプロセッサユニットが公共データ通信ネットワークと接続され、他方のプロセッサユニットは公共データ通信ネットワークと接続せず、データセキュリティ用ユニットとして機能する構成が開示されている（特表２００２−５４２５３７号公報（文献２）参照）。文献２に記載されるシステムでは、公共データ通信ネットワークに接続されるプロセッサユニットと、データセキュリティ用ユニットをスイッチで分離しており、データセキュリティ用ユニットの安全性を確保している。しかしながら、公共データ通信ネットワークに接続されるプロセッサユニットが、前述した追加処理（ネットワーク等からダウンロードされた追加処理）の実行により、攻撃されることの対策に関しては、いささかも考慮されていない。データセキュリティ用ユニットは安全であっても、公共データ通信ネットワークに接続されるプロセッサユニットは追加処理による攻撃に対する有効なセキュリティ機構は具備していない。このため、公共データ通信ネットワークに接続されるプロセッサユニットにセキュリティ管理を実現する場合、前述したいずれかの方式を採用する必要がある。
さらに、プロセッサ上で分離された実行プログラムあるいはオペレーティングシステムを同時に実行するシステムにおいて、不正なプログラムの実行環境を保護するために、第１のプログラムが実行される間、第１のプログラムのみが利用するメモリ空間が設定され、第１のプログラムとコンピュータの実行環境との通信は、共有メモリ空間の利用、専用の割り込み、あるいは専用のＩ／Ｏポートを含む単一のリンクを介して行われ、第１のプログラムは、制限された実行環境において、設定されたメモリ空間と単一のリンクを除いてプロセッサ上のリソースをアクセスすることが制限されるようにした構成が特表２００２−５３３７９１号公報（文献３）に記載されている。この文献３に記載された方法の場合、第１のプログラムは、設定されたメモリ空間と単一のリンク（共有メモリ空間の利用、専用の割り込み、あるいは専用のＩ／Ｏポート）を除いてプロセッサ上のリソースをアクセスすることが制限されるため、第１のプログラムを、デバイスドライバとして用いることは出来ず、デバイスドライバを含む追加処理に適用することは出来ない。
また、後述される本発明で用いられるプロセッサ間通信手段に関連する技術を開示した刊行物として、特開平６−３３２８６４号公報（文献４）には、マルチプロセッサシステムにおけるＣＰＵ間通信方式が開示されている。この文献４には、マルチプロセッサが共通メモリを利用してＣＰＵ間通信を行うにあたり、ＣＰＵ２がＣＰＵ１に割り込みを発生させる場合、ＣＰＵ１に対する固定領域における自己用のＣＰＵ間通信情報書き込み領域に、通信情報を書き込んで割り込みを発生し、ＣＰＵ１では、割り込みが発生すると、ＣＰＵ２に対応するＣＰＵ間通信情報書き込み領域をアクセスして割り込み処理を実行する構成がその従来技術として記載されており、さらに、共有メモリのアクセス回数を削減するようにした発明が記載されている。
さらに、特開２００１−１５４９９９号公報（文献５）では、プロセッサ診断回路が自プロセッサの起動時に故障を検出してサービスプロセッサに復旧を依頼し、サービスプロセッサがその復旧の処理を行う並列計算機システムを提案している。
文献１：特表２００４−５００６６６号公報
文献２：特表２００２−５４２５３７号公報
文献３：特表２００２−５３３７９１号公報
文献４：特開平６−３３２８６４号公報
文献５：特開２００１−１５４９９９号公報
上記したように、ダウンロードされた、悪意のある、もしくは過失の追加処理からの攻撃に対する安全性確保の対策を施した従来の装置は、処理性能の点、デバイスドライバの実行が不可である点、安全性確保に問題がある点等、実用上、各種課題が残されている。特に、図４３、及び図４５に示したように、情報処理装置に関して、装置外部から、追加デバイスドライバのダウンロードが不可である設計方式（アーキテクチャ）は、デバイスの追加、機能追加当が実質的に不可能であることを意味しており、この点で、可用性（ａｖａｉｌａｂｉｌｉｔｙ）が制限される。
一方、前述したように、追加デバイスドライバを例えばカーネルモードで動作させる場合には、ＯＳ、システムの信頼性に直接影響を及ぼすことから、特段の安全性確保、信頼性の向上が要請されている。
また、文献５に開示された技術を一例とする従来の並列計算機システムにおける復旧処理では、通知された復旧要求等がウィルスを含んでいる等の悪意のある要求に対しても処理を実行してしまうという問題点がある。
したがって、本発明の目的は、追加されたアプリケーションプログラム及びデバイスドライバによって障害が生じたドメインを、安全性、信頼性を確保して復旧する情報処理装置、復旧装置、プログラム及び復旧方法を提供することにある。
上記目的を達成するため本発明は、複数のプロセッサを備え、実行する処理内容に応じて、複数のプロセッサが複数のドメインを構成し、異なるドメイン間のプロセッサ同士は、通信手段を介して互いに通信し、ドメインから通知される障害の復旧要求と、前記ドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行う構成としている。
この構成により、各ドメインに発生した障害毎に復旧条件が設定されていることから、復旧条件を満たした復旧要求により障害が復旧される。
本発明の好ましい態様では、複数のドメインを、実行する処理内容に応じて、特定ドメインと、他のドメインとに分離して構成し、特定ドメイン又は他のドメインから通知される障害の復旧要求と、特定ドメイン及び他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行う構成としている。
この構成により、複数のドメインが、実行する処理内容に応じて、特定ドメインと、他のドメインとに分離して構成され、特定ドメイン又は他のドメインから通知される障害の復旧要求と、特定ドメイン及び他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うことから、特定ドメインと他のドメインとを異なる復旧条件により復旧することが可能となる。
本発明のさらに好ましい態様では、特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、他のドメインが、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、特定ドメインが、他のドメインにおける障害を、他のドメインへの通信手段によるデータ送信を介して検知し、復旧手段に対して障害の復旧要求を行う構成としている。
この構成により、ある一定のセキュリティレベル以上の処理を実行する特定ドメインと特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインとが分離して構成され、他のドメインで発生した障害を検知した、ある一定のセキュリティレベル以上の処理を実行する特定ドメインが、復旧手段を介して、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインを復旧する。
本発明の別の好ましい態様では、特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、他のドメインが、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、他のドメインが、何れかの他のドメインにおける障害を検知し、特定ドメインに他のドメインの障害の復旧要求を通知し、特定ドメインが、復旧手段に対して障害の復旧要求を行う構成としている。
この構成により、ある一定のセキュリティレベル以上の処理を実行する特定ドメインと特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインとが分離して構成され、他のドメインで発生した障害を通知された、ある一定のセキュリティレベル以上の処理を実行する特定ドメインが、復旧手段を介して、相対的にセキュリティレベルが低い処理を実行する他のドメインを復旧する。
本発明の別の好ましい態様では、特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、他のドメインが、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、他のドメインが、何れかの他のドメインにおける障害を検知し、特定ドメインに他のドメインの障害の復旧要求を通知し、特定ドメインが、他のドメインの障害を、他のドメインへの通信手段によるデータ送信を介して検知し、復旧手段に対して障害の復旧要求を行う構成としている。
この構成により、ある一定のセキュリティレベル以上の処理を実行する特定ドメインと特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインとが分離して構成され、他のドメインで発生した障害を通知された、ある一定のセキュリティレベル以上の処理を実行する特定ドメインが、障害を検知し、復旧手段を介して、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインを復旧する。
本発明のさらに好ましい態様では、復旧条件は、ドメインからの障害の復旧要求で示される処理内容毎に設定されたセキュリティレベルに基づいて定められており、復旧手段は、ドメインから通知された障害の復旧要求と、復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行う構成としている。
この構成により、処理内容毎に設定されたセキュリティレベルに基づいて定められた復旧条件を満たした復旧要求が受け付けられる。
本発明のさらに好ましい態様では、復旧手段は、ドメインから通知された障害の復旧要求の許否を判別する判別手段を備え、判別手段で許可された復旧要求に基づいて、障害が発生したドメインに対して障害の復旧処理を行う構成としている。
この構成により、判別手段で許可された復旧要求に基づいて障害の復旧処理が行われる。
本発明によれば、以下の効果が達成される。
第１の効果は、各ドメインに発生する障害が、予め設定された復旧条件を満たした復旧要求により復旧されることである。
その理由は、複数のプロセッサを備え、実行する処理内容に応じて、複数のプロセッサが複数のドメインを構成し、異なるドメイン間のプロセッサ同士は、通信手段を介して互いに通信し、ドメインから通知される障害の復旧要求と、ドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うので、各ドメインに発生する障害毎に予め設定された復旧条件を満たした復旧要求により障害が復旧されるからである。
第２の効果は、複数のドメインのうち、所定のドメインを、その他のドメインと異なる復旧条件により復旧することが可能となることである。
その理由は、複数のドメインを、実行する処理内容に応じて、特定ドメインと、他のドメインとに分離して構成し、特定ドメイン又は他のドメインから通知される障害の復旧要求と、特定ドメイン及び他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うからである。したがって、複数のドメインが、実行する処理内容に応じて、特定ドメインと、他のドメインとに分離して構成され、特定ドメイン又は他のドメインから通知される障害の復旧要求と、特定ドメイン及び他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うことから、特定ドメインと他のドメインとを異なる復旧条件により復旧することが可能となるからである。
第３の効果は、ある一定のセキュリティレベル以上の処理を実行するドメインのセキュリティを確保できることである。
その理由は、特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、他のドメインが、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、特定ドメインが、他のドメインにおける障害を、他のドメインへの通信手段によるデータ送信を介して検知し、復旧手段に対して障害の復旧要求を行うからである。したがって、ある一定のセキュリティレベル以上の処理を実行する特定ドメインと特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインとが分離して構成され、他のドメインで発生した障害を検知した、ある一定のセキュリティレベル以上の処理を実行する特定ドメインが、復旧手段を介して、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインを復旧するからである。
第４の効果は、情報処理装置の可用性が向上することである。
その理由は、セキュリティが確保された、ある一定のセキュリティレベル以上の処理を実行するドメインが、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインで発生した障害を検知して復旧手段を介して復旧するからである。
第５の効果は、各ドメインで発生した障害を、所定のセキュリティレベルを確保して復旧できることである。
その理由は、復旧条件が、ドメインからの障害の復旧要求で示される処理内容毎に設定されたセキュリティレベルに基づいて定められており、復旧手段が、ドメインから通知された障害の復旧要求と、復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うからである。したがって、処理内容毎に設定されたセキュリティレベルに基づいて定められた復旧条件を満たした復旧要求が受け付けられるからである。
この構成により、各ドメインに発生した障害毎に復旧条件が設定されていることから、復旧条件を満たした復旧要求により障害が復旧される。
本発明の好ましい態様では、複数のドメインを、実行する処理内容に応じて、特定ドメインと、他のドメインとに分離して構成し、特定ドメイン又は他のドメインから通知される障害の復旧要求と、特定ドメイン及び他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行う構成としている。
この構成により、複数のドメインが、実行する処理内容に応じて、特定ドメインと、他のドメインとに分離して構成され、特定ドメイン又は他のドメインから通知される障害の復旧要求と、特定ドメイン及び他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うことから、特定ドメインと他のドメインとを異なる復旧条件により復旧することが可能となる。
本発明のさらに好ましい態様では、特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、他のドメインが、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、特定ドメインが、他のドメインにおける障害を、他のドメインへの通信手段によるデータ送信を介して検知し、復旧手段に対して障害の復旧要求を行う構成としている。
この構成により、ある一定のセキュリティレベル以上の処理を実行する特定ドメインと特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインとが分離して構成され、他のドメインで発生した障害を検知した、ある一定のセキュリティレベル以上の処理を実行する特定ドメインが、復旧手段を介して、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインを復旧する。
本発明の別の好ましい態様では、特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、他のドメインが、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、他のドメインが、何れかの他のドメインにおける障害を検知し、特定ドメインに他のドメインの障害の復旧要求を通知し、特定ドメインが、復旧手段に対して障害の復旧要求を行う構成としている。
この構成により、ある一定のセキュリティレベル以上の処理を実行する特定ドメインと特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインとが分離して構成され、他のドメインで発生した障害を通知された、ある一定のセキュリティレベル以上の処理を実行する特定ドメインが、復旧手段を介して、相対的にセキュリティレベルが低い処理を実行する他のドメインを復旧する。
本発明の別の好ましい態様では、特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、他のドメインが、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、他のドメインが、何れかの他のドメインにおける障害を検知し、特定ドメインに他のドメインの障害の復旧要求を通知し、特定ドメインが、他のドメインの障害を、他のドメインへの通信手段によるデータ送信を介して検知し、復旧手段に対して障害の復旧要求を行う構成としている。
この構成により、ある一定のセキュリティレベル以上の処理を実行する特定ドメインと特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインとが分離して構成され、他のドメインで発生した障害を通知された、ある一定のセキュリティレベル以上の処理を実行する特定ドメインが、障害を検知し、復旧手段を介して、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインを復旧する。
本発明のさらに好ましい態様では、復旧条件は、ドメインからの障害の復旧要求で示される処理内容毎に設定されたセキュリティレベルに基づいて定められており、復旧手段は、ドメインから通知された障害の復旧要求と、復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行う構成としている。
この構成により、処理内容毎に設定されたセキュリティレベルに基づいて定められた復旧条件を満たした復旧要求が受け付けられる。
本発明のさらに好ましい態様では、復旧手段は、ドメインから通知された障害の復旧要求の許否を判別する判別手段を備え、判別手段で許可された復旧要求に基づいて、障害が発生したドメインに対して障害の復旧処理を行う構成としている。
この構成により、判別手段で許可された復旧要求に基づいて障害の復旧処理が行われる。
本発明によれば、以下の効果が達成される。
第１の効果は、各ドメインに発生する障害が、予め設定された復旧条件を満たした復旧要求により復旧されることである。
その理由は、複数のプロセッサを備え、実行する処理内容に応じて、複数のプロセッサが複数のドメインを構成し、異なるドメイン間のプロセッサ同士は、通信手段を介して互いに通信し、ドメインから通知される障害の復旧要求と、ドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うので、各ドメインに発生する障害毎に予め設定された復旧条件を満たした復旧要求により障害が復旧されるからである。
第２の効果は、複数のドメインのうち、所定のドメインを、その他のドメインと異なる復旧条件により復旧することが可能となることである。
その理由は、複数のドメインを、実行する処理内容に応じて、特定ドメインと、他のドメインとに分離して構成し、特定ドメイン又は他のドメインから通知される障害の復旧要求と、特定ドメイン及び他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うからである。したがって、複数のドメインが、実行する処理内容に応じて、特定ドメインと、他のドメインとに分離して構成され、特定ドメイン又は他のドメインから通知される障害の復旧要求と、特定ドメイン及び他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うことから、特定ドメインと他のドメインとを異なる復旧条件により復旧することが可能となるからである。
第３の効果は、ある一定のセキュリティレベル以上の処理を実行するドメインのセキュリティを確保できることである。
その理由は、特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、他のドメインが、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、特定ドメインが、他のドメインにおける障害を、他のドメインへの通信手段によるデータ送信を介して検知し、復旧手段に対して障害の復旧要求を行うからである。したがって、ある一定のセキュリティレベル以上の処理を実行する特定ドメインと特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインとが分離して構成され、他のドメインで発生した障害を検知した、ある一定のセキュリティレベル以上の処理を実行する特定ドメインが、復旧手段を介して、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する他のドメインを復旧するからである。
第４の効果は、情報処理装置の可用性が向上することである。
その理由は、セキュリティが確保された、ある一定のセキュリティレベル以上の処理を実行するドメインが、特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインで発生した障害を検知して復旧手段を介して復旧するからである。
第５の効果は、各ドメインで発生した障害を、所定のセキュリティレベルを確保して復旧できることである。
その理由は、復旧条件が、ドメインからの障害の復旧要求で示される処理内容毎に設定されたセキュリティレベルに基づいて定められており、復旧手段が、ドメインから通知された障害の復旧要求と、復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うからである。したがって、処理内容毎に設定されたセキュリティレベルに基づいて定められた復旧条件を満たした復旧要求が受け付けられるからである。
図１は、本発明の第１例の情報処理装置のハードウェア構成を示す図である。
図２は、第１例のプロセッサ間通信手段の構成を示す図である。
図３は、第１例のプロセッサ間通信手段の動作を説明するための図である。
図４は、第１例のアクセス制御手段の構成を示す図である。
図５は、第１例のアクセス制御手段のアクセス許可データの例を示す図である。
図６は、第１例のアクセス制御手段の動作を説明する図である。
図７は、第１例のアクセス制御手段３０の別構成を示す図である。
図８は、第１例のアクセス制御手段３０の別構成を示す図である。
図９は、本発明の第２例の情報処理装置のハードウェア構成を示す図である。
図１０は、本発明の第３例の情報処理装置のハードウェア構成を示す図である。
図１１は、第３例の情報処理装置の変形例のハードウェア構成を示す図である。
図１２は、第３例の情報処理装置のソフトウェア構成を示す図である。
図１３は、第３例の動作を説明するための図である。
図１４は、第３例の動作を説明するための図である。
図１５は、第３例の動作を説明するための図である。
図１６は、第３例の動作を説明するための図である。
図１７は、第３例の動作を説明するための図である。
図１８は、第３例の動作を説明するための図である。
図１９は、第３例の動作を説明するための図である。
図２０は、第３例の動作を説明するための図である。
図２１は、本発明の第４例の情報処理装置の構成を示す図である。
図２２は、第４例の動作を説明するための図である。
図２３は、第４例の動作を説明するための図である。
図２４は、本発明の第１の実施例による情報処理装置の構成を示す図である。
図２５は、本発明の第１の実施例において設定される信頼度の一例を示す図である。
図２６は、本発明の第１の実施例による情報処理装置のドメイン停止復旧手段４００の構成を示す図である。
図２７は、本発明の第１の実施例による情報処理装置の通信処理の内容（処理内容）と通信の階層構造との対応関係の一例を示す図である。
図２８は、本発明の第１の実施例による情報処理装置のハードウェア構成の一例を示すブロック図である。
図２９は、本発明の第１の実施例による情報処理装置の動作の一例を説明するための図である。
図３０は、本発明の第１の実施例による情報処理装置の動作の一例を説明するための図である。
図３１は、本発明の第１の実施例による情報処理装置の動作の一例を説明するための図である。
図３２は、本発明の第１の実施例による情報処理装置の動作の一例を説明するための図である。
図３３は、本発明の第１の実施例による情報処理装置の動作の一例を説明するための図である。
図３４は、本発明の第２の実施例による情報処理装置のドメイン停止復旧手段４００の構成を示す図である。
図３５は、本発明の第２の実施例による情報処理装置の動作の一例を説明するための図である。
図３６は、本発明の第２の実施例による情報処理装置の動作の一例を説明するための図である。
図３７は、本発明の第２の実施例による情報処理装置の動作の一例を説明するための図である。
図３８は、本発明の第３の実施例による情報処理装置のドメイン停止復旧手段４００の構成を示す図である。
図３９は、本発明の第３の実施例による情報処理装置の復旧処理許可データ４０４ａの内容の一例を示す図である。
図４０は、本発明の第３の実施例による情報処理装置の復旧処理制御手段４０４の動作の一例を説明するための図である。
図４１は、本発明の第４の実施例による情報処理装置のドメイン停止復旧手段４００の構成を示す図である。
図４２は、従来のシステム構成の一例を示す図である。
図４３は、従来のシステム構成の別の例を示す図である。
図４４は、従来のシステム構成の別の例を示す図である。
図４５は、従来のシステム構成のさらに別の例を示す図である。
１０，１０Ａ，１０Ｂ，１０Ｃ：ＣＰＵ、１１：ＣＰＵ、１２：セキュアモード、１３：非セキュアモード
１４：メモリ管理ユニット、１５：分離手段、２０，２０Ａ，２０Ｂ，２０Ｃ：ソフトウェア、２１，２１Ａ，２１Ｂ，２１Ｃ：ＯＳ、２２：基本処理、２３，２３Ｂ，２３Ｃ：追加処理、２４：仮想マシン、２５：証明書、３０：アクセス制御手段、３１：アクセス許可手段、３２：アクセス許可データ、３３：新アクセス許可データ３３、３４：アクセス許可データ更新手段３４、３５：アクセス監視手段、３６：学習手段、４０：プロセッサ間通信手段、４１：割り込み制御装置、４１０〜４１ｎ：ＣＰＵ＃０〜ＣＰＵ＃ｎ用割り込み制御装置、４２：共有メモリ、４２０〜４２ｎ：ＣＰＵ＃０〜ＣＰＵ＃ｎ用通信領域、５０，５０Ａ，５０Ｂ，５０Ｃ：メモリ、６０，６０Ａ，６０Ｂ，６０Ｃ：入出力デバイス（Ｉ／Ｏ）、７０Ａ：基本側バス、７０Ｂ：追加側バス、８０，８０Ａ，８０Ｂ：チップ、１００Ａ：基本ドメイン、１００Ｂ：Ｔｒｕｓｔｅｄ拡張ドメイン、１００Ｃ：Ｕｎｔｒｕｓｔｅｄ拡張ドメイン、１０１Ａ，１０１Ｂ，１０１Ｃ：ＯＳ、１０２Ａ：外部デバイス、１０２Ａ´：仮想外部デバイス、１０２Ｂ，１０２Ｃ：許可された外部デバイス、１０２Ｂ´，１０２Ｃ´：許可された仮想外部デバイス、１０３：専用ファイルシステム、１０３´：仮想専用ファイルシステム、１０４Ａ：ネイティブコードダウンロード管理機能、１０４Ｂ，１０４Ｃ：ネイティブコードダウンロード実行機能、１０５：セキュリティポリシデータベース、１１０：基本ソフト環境、１１１：基本アプリケーション、１１２：基本機能、１１３：基本ライブラリ、１２０Ａ，１２０Ｂ，１２０Ｃ：ダウンロードアプリケーション、１２１Ａ，１２１Ｂ，１２１Ｃ：ダウンロードドライバ、１５０Ａ：最高信頼度ドメイン、１５０Ｂ：中信頼度ドメイン、１５０Ｃ：低信頼度ドメイン、２００Ａ，２００Ｂ，２００Ｃ：仮想ＣＰＵ、２１０Ａ，２１０Ｂ，２１０Ｃ：仮想マシンモニタ、３０１，３０２，３０３：データ送信部、３０４，３０５：低信頼度ドメイン用データ送信部、３０６，３０７：中信頼度ドメイン用データ送信部、４００：ドメイン停止復旧手段、４０１：復旧要求受信手段、４０２：ドメイン停止復旧処理手段、４０３：停止確認手段、４０４：復旧処理制御手段、４０４ａ：復旧処理許可データ、４０４ｂ：復旧処理許可手段、４１１：割り込み指示部、４１２：割り込み状態保持部、４１３：割り込み取り消し部、４２１：通信キュー、４２２：排他制御領域
図２は、第１例のプロセッサ間通信手段の構成を示す図である。
図３は、第１例のプロセッサ間通信手段の動作を説明するための図である。
図４は、第１例のアクセス制御手段の構成を示す図である。
図５は、第１例のアクセス制御手段のアクセス許可データの例を示す図である。
図６は、第１例のアクセス制御手段の動作を説明する図である。
図７は、第１例のアクセス制御手段３０の別構成を示す図である。
図８は、第１例のアクセス制御手段３０の別構成を示す図である。
図９は、本発明の第２例の情報処理装置のハードウェア構成を示す図である。
図１０は、本発明の第３例の情報処理装置のハードウェア構成を示す図である。
図１１は、第３例の情報処理装置の変形例のハードウェア構成を示す図である。
図１２は、第３例の情報処理装置のソフトウェア構成を示す図である。
図１３は、第３例の動作を説明するための図である。
図１４は、第３例の動作を説明するための図である。
図１５は、第３例の動作を説明するための図である。
図１６は、第３例の動作を説明するための図である。
図１７は、第３例の動作を説明するための図である。
図１８は、第３例の動作を説明するための図である。
図１９は、第３例の動作を説明するための図である。
図２０は、第３例の動作を説明するための図である。
図２１は、本発明の第４例の情報処理装置の構成を示す図である。
図２２は、第４例の動作を説明するための図である。
図２３は、第４例の動作を説明するための図である。
図２４は、本発明の第１の実施例による情報処理装置の構成を示す図である。
図２５は、本発明の第１の実施例において設定される信頼度の一例を示す図である。
図２６は、本発明の第１の実施例による情報処理装置のドメイン停止復旧手段４００の構成を示す図である。
図２７は、本発明の第１の実施例による情報処理装置の通信処理の内容（処理内容）と通信の階層構造との対応関係の一例を示す図である。
図２８は、本発明の第１の実施例による情報処理装置のハードウェア構成の一例を示すブロック図である。
図２９は、本発明の第１の実施例による情報処理装置の動作の一例を説明するための図である。
図３０は、本発明の第１の実施例による情報処理装置の動作の一例を説明するための図である。
図３１は、本発明の第１の実施例による情報処理装置の動作の一例を説明するための図である。
図３２は、本発明の第１の実施例による情報処理装置の動作の一例を説明するための図である。
図３３は、本発明の第１の実施例による情報処理装置の動作の一例を説明するための図である。
図３４は、本発明の第２の実施例による情報処理装置のドメイン停止復旧手段４００の構成を示す図である。
図３５は、本発明の第２の実施例による情報処理装置の動作の一例を説明するための図である。
図３６は、本発明の第２の実施例による情報処理装置の動作の一例を説明するための図である。
図３７は、本発明の第２の実施例による情報処理装置の動作の一例を説明するための図である。
図３８は、本発明の第３の実施例による情報処理装置のドメイン停止復旧手段４００の構成を示す図である。
図３９は、本発明の第３の実施例による情報処理装置の復旧処理許可データ４０４ａの内容の一例を示す図である。
図４０は、本発明の第３の実施例による情報処理装置の復旧処理制御手段４０４の動作の一例を説明するための図である。
図４１は、本発明の第４の実施例による情報処理装置のドメイン停止復旧手段４００の構成を示す図である。
図４２は、従来のシステム構成の一例を示す図である。
図４３は、従来のシステム構成の別の例を示す図である。
図４４は、従来のシステム構成の別の例を示す図である。
図４５は、従来のシステム構成のさらに別の例を示す図である。
１０，１０Ａ，１０Ｂ，１０Ｃ：ＣＰＵ、１１：ＣＰＵ、１２：セキュアモード、１３：非セキュアモード
１４：メモリ管理ユニット、１５：分離手段、２０，２０Ａ，２０Ｂ，２０Ｃ：ソフトウェア、２１，２１Ａ，２１Ｂ，２１Ｃ：ＯＳ、２２：基本処理、２３，２３Ｂ，２３Ｃ：追加処理、２４：仮想マシン、２５：証明書、３０：アクセス制御手段、３１：アクセス許可手段、３２：アクセス許可データ、３３：新アクセス許可データ３３、３４：アクセス許可データ更新手段３４、３５：アクセス監視手段、３６：学習手段、４０：プロセッサ間通信手段、４１：割り込み制御装置、４１０〜４１ｎ：ＣＰＵ＃０〜ＣＰＵ＃ｎ用割り込み制御装置、４２：共有メモリ、４２０〜４２ｎ：ＣＰＵ＃０〜ＣＰＵ＃ｎ用通信領域、５０，５０Ａ，５０Ｂ，５０Ｃ：メモリ、６０，６０Ａ，６０Ｂ，６０Ｃ：入出力デバイス（Ｉ／Ｏ）、７０Ａ：基本側バス、７０Ｂ：追加側バス、８０，８０Ａ，８０Ｂ：チップ、１００Ａ：基本ドメイン、１００Ｂ：Ｔｒｕｓｔｅｄ拡張ドメイン、１００Ｃ：Ｕｎｔｒｕｓｔｅｄ拡張ドメイン、１０１Ａ，１０１Ｂ，１０１Ｃ：ＯＳ、１０２Ａ：外部デバイス、１０２Ａ´：仮想外部デバイス、１０２Ｂ，１０２Ｃ：許可された外部デバイス、１０２Ｂ´，１０２Ｃ´：許可された仮想外部デバイス、１０３：専用ファイルシステム、１０３´：仮想専用ファイルシステム、１０４Ａ：ネイティブコードダウンロード管理機能、１０４Ｂ，１０４Ｃ：ネイティブコードダウンロード実行機能、１０５：セキュリティポリシデータベース、１１０：基本ソフト環境、１１１：基本アプリケーション、１１２：基本機能、１１３：基本ライブラリ、１２０Ａ，１２０Ｂ，１２０Ｃ：ダウンロードアプリケーション、１２１Ａ，１２１Ｂ，１２１Ｃ：ダウンロードドライバ、１５０Ａ：最高信頼度ドメイン、１５０Ｂ：中信頼度ドメイン、１５０Ｃ：低信頼度ドメイン、２００Ａ，２００Ｂ，２００Ｃ：仮想ＣＰＵ、２１０Ａ，２１０Ｂ，２１０Ｃ：仮想マシンモニタ、３０１，３０２，３０３：データ送信部、３０４，３０５：低信頼度ドメイン用データ送信部、３０６，３０７：中信頼度ドメイン用データ送信部、４００：ドメイン停止復旧手段、４０１：復旧要求受信手段、４０２：ドメイン停止復旧処理手段、４０３：停止確認手段、４０４：復旧処理制御手段、４０４ａ：復旧処理許可データ、４０４ｂ：復旧処理許可手段、４１１：割り込み指示部、４１２：割り込み状態保持部、４１３：割り込み取り消し部、４２１：通信キュー、４２２：排他制御領域
まず、本発明を適用する情報処理装置の基本構成について説明する。
基本構成の第１例は、複数のＣＰＵを備えたマルチＣＰＵ構成の情報処理装置において、複数のＣＰＵを、実行するプログラム（処理）のセキュリティレベルに応じて、複数のドメイン（例えば基本ドメイン、信頼ドメイン、無信頼ドメイン等）に分ける。
基本ドメインは、ある一定のセキュリティレベル以上の処理を実行するドメインであり、信頼ドメインは、基本ドメインで実行する処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、無信頼ドメインは、信頼ドメインで実行する処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインとする。
または、基本ドメインの一定のセキュリティレベルの実行処理のそれぞれが、信頼ドメインの実行処理のセキュリティレベルと同じか、又は信頼ドメインの実行処理のセキュリティレベルより高く、そして基本ドメインの実行処理の集合として少なくとも１つセキュリティレベルの高い処理を含むドメインとしてもよい。
信頼ドメインは、信頼ドメインの一定のセキュリティレベルの実行処理のそれぞれが、無信頼ドメインの実行処理のセキュリティレベルと同じか、又は無信頼ドメインの実行処理のセキュリティレベルより高く、そして各ドメインの実行処理の集合として少なくとも１つセキュリティレベルの高い処理を含むドメインとしても良い。この場合には基本ドメインは信頼ドメインよりも相対的にセキュリティレベルの高い処理を行い、信頼ドメインは無信頼ドメインよりも相対的に高い処理が行われる。
各ドメインは、１つ又は複数のＣＰＵを含み、異なるドメイン間でのＣＰＵの通信を、プロセッサ間通信手段（例えば図１の４０）を介して行うとともに、追加処理等の低セキュリティの処理を実行するドメインに属するＣＰＵが、高セキュリティの処理を実行するドメインのメモリ及び入出力装置に対してアクセスする場合には、該アクセス要求は、アクセス制御手段（例えば図１の３０）によって、アクセスの許可／非許可が判別され、許可されたアクセスのみが行われる構成とされる。
かかる構成の第１例によれば、ダウンロードされた追加処理（デバイスドライバ、アプリケーションプログラムを含む）を、高セキュリティ・ドメインとはハードウェア的に別構成の低セキュリティ・ドメイン側のＣＰＵで実行することで、高セキュリティ・ドメインの安全性を確保している。
ここでいうダウンロードとは、携帯電話のキャリアが用意するデータ通信網や一般的な無線ＬＡＮ網だけではなく、ＳＤカードに代表される蓄積型メディア媒体、ＵＳＢに代表される有線通信・媒体といった接続を経由した情報装置へのダウンロードのことも含む。
そして、第１例によれば、高セキュリティ・ドメインと低セキュリティ・ドメインのＣＰＵを、スイッチ等で分離制御するのではなく、相互に通信可能とする、プロセッサ間通信手段を介して接続することで、安全性を保障しながら、高セキュリティ・ドメインと低セキュリティ・ドメインのＣＰＵ間の同期、協調動作も可能としている。
このプロセッサ間通信手段（図１の４０）は、一のドメインのＣＰＵから他のドメインのＣＰＵへデータ（コマンド）の受け渡しを行うものであり、他のドメインのＣＰＵへの直接的な攻撃等は行えない構成とされている。例えば低セキュリティ・ドメイン側のＣＰＵから高セキュリティ・ドメイン側のＣＰＵへデータを多量に送信し続けることで、高セキュリティ・ドメインのＣＰＵの性能劣化、バッファオーバーフロー等を生じさせようとしても、プロセッサ間通信手段で抑止され、該データは、高セキュリティ・ドメインのＣＰＵに伝達されない。
また、第１例において、アクセス制御手段（図１の３０）は、低セキュリティ・ドメイン側のＣＰＵに対して、予め許可されたメモリ空間、入出力デバイス等へ予め許可された形態によるアクセスのみを許可するアクセス制御を行う。これにより、ダウンロードされた追加処理からの高セキュリティ・ドメインへの攻撃を防ぐことが出来る。あるいは、アクセス制御手段が、必要に応じて、帯域、流量制御等を行うことで、ダウンロードされた追加処理からの高セキュリティ・ドメインへの各種攻撃を防ぐことが出来る。以下第１例に即して説明する。
図１は、第１例の構成を示す図である。図１を参照すると、基本処理２２及びＯＳ２１Ａからなるソフトウェア２０Ａを実行するＣＰＵ群１０Ａと、追加処理２３及び追加処理対応のＯＳ２１Ｂからなるソフトウェア２０Ｂを実行するＣＰＵ群１０Ｂと、ＣＰＵ群１０Ａ、１０Ｂ間で通信を行うプロセッサ間通信手段４０１、４０２と、ＣＰＵ群１０Ｂによるメモリ５０及び／又は入出力装置（Ｉ／Ｏ）６０へのアクセスを制御するアクセス制御手段３０と、を備えている。なお、図１には、ＣＰＵ群１０Ａ、ＣＰＵ群１０Ｂは、それぞれ複数（３台）のＣＰＵからなる構成として示されているが、各群とも１つのＣＰＵであっても良いことは勿論である。また、ＣＰＵ群１０Ａ、ＣＰＵ群１０Ｂにおいて、各群のＣＰＵの台数は等しくなくてもよいことは勿論である。以下では、ＣＰＵ群１０Ａ、ＣＰＵ群１０Ｂを、単にＣＰＵ１０Ａ、ＣＰＵ１０Ｂという。第１例において、ダウンロードされる追加処理２３は、バイナリ形式のネイティブコードよりなる。なお、ダウンロードされたソースプログラムを、コンパイル処理（アセンブル処理）してバイナリ形式としたものであってもよい。
第１例によれば、追加処理２３を実行するＣＰＵ１０Ｂを、基本処理２２を実行するＣＰＵ１０Ａと別に構え、ＣＰＵ１０Ａ、ＣＰＵ１０Ｂは、独立に動作可能であり、安全性を向上しながら、高速実行を可能とし、アプリケーションプログラム、デバイスドライバの実行を可能としている。なお、基本処理２２を実行するＣＰＵ１０Ａをマスターとし、追加処理２３を実行するＣＰＵ１０Ｂをスレーブとして構成し、スレーブ側はマスターの監督下で動作する構成としても良いことは勿論である。この場合、例えばＣＰＵ１０Ｂによる追加処理２３の実行は、ＣＰＵ１０Ａからプロセッサ間通信手段４０２を介してコマンドを受け取って行われる。
プロセッサ間通信手段４０１、４０２は、ＣＰＵ１０ＡとＣＰＵ１０Ｂ間でのデータの送受信を制御する。ＣＰＵ１０Ａ、１０Ｂは、独立に配設されていることから、それぞれの処理（プログラム）を並列に実行することが可能であるとともに、プロセッサ間通信手段４０１、４０２を介して、ＣＰＵ１０ＡとＣＰＵ１０Ｂ間における、同期処理、連携（強調）処理も可能としている。一例として、ユーザが表示装置の画面上から追加処理の実行を指示した場合、基本処理２２を実行するＣＰＵ１０Ａから、プロセッサ間通信手段４０１を解して、追加処理２３の起動要求が、ＣＰＵ１０Ｂに送信され、ＣＰＵ１０Ｂ上で追加処理２３が実行され、実行結果が、ＣＰＵ１０Ｂから、プロセッサ間通信手段４０２を介して、ＣＰＵ１０Ａに送信され、基本処理２２を構成する画面制御ルーチン等が、追加処理２３の実行結果を反映した情報をユーザに提示する、という具合である。
第１例では、ＣＰＵ１０Ｂで追加処理２３を実行する際、メモリ５０、入出力デバイス（Ｉ／Ｏ）６０へのアクセス要求が行われた場合、アクセス制御手段３０にて、当該アクセスに関する許諾の制御が行われ、許可されたアクセス要求のみが、メモリ５０、入出力デバイス（Ｉ／Ｏ）６０に対して実行される構成とされている。そして、ＣＰＵ１０Ｂにおいて、ＯＳ２１Ｂ上で追加処理２３を実行し、追加処理２３からの、基本処理２２あるいはＯＳ２１Ａへの処理要求が発行された場合、該要求は、プロセッサ間通信手段４０１を介して、ＣＰＵ１０Ａに通知される。すなわち、追加処理２３が、基本処理２２を、直接操作することは出来ない。例えば、悪意のある追加処理２３が、ＣＰＵ１０Ａに要求を頻発して発行して負荷を与え、ＣＰＵ１０Ａ側での基本処理の実行性能を著しく低下させようとしても、プロセッサ間通信手段４０１が、このような要求をＣＰＵ１０Ａ側に伝達しないように制御することで、上記攻撃からの防護が実現され、安全性が確保される。
なお、図１に示す例では、プロセッサ間通信手段４０１は、ＣＰＵ１０ＢからＣＰＵ１０Ａへの情報転送、プロセッサ間通信手段４０２は、ＣＰＵ１０ＡからＣＰＵ１０Ｂへの情報転送を制御している。あるいは、一台のプロセッサ間通信装置で双方向のデータの受け渡しを行うようにしても良いことは勿論である。第１例において、基本処理２２を実行する複数のＣＰＵ１０Ａ同士でＣＰＵ間の通信が必要な場合には、プロセッサ間通信手段４０を用いることなく、ＣＰＵ間の通信が行われる。また、追加処理２３を実行する複数のＣＰＵ１０Ｂについても同様である。ただし、後述するように、ＣＰＵ群１０Ｂを構成する複数のＣＰＵのいくつかをＣＰＵ群１０Ａの要素としてダイナミックに切り替える場合、ＣＰＵ群１０Ｂは、論理的にはＣＰＵ群１０Ａに属するが、ＣＰＵ間の通信は、プロセッサ間通信手段４０を介して行うようにしても良い。
第１例によれば、追加処理２３として、アプリケーションプログラム、デバイスドライバのダウンロード、インストール、実行が可能とされている。追加されたデバイスドライバは、ＯＳ２１Ｂに組み込まれ、ＣＰＵ１０Ｂ上で実行され、入出力デバイス６０へのアクセス制御は、アクセス制御手段３０の監視の下で実行される。
なお、携帯電話機、ＰＤＡ等の携帯型情報通信装置では、通常、図１における基本処理２２、ＯＳ２１Ａは、図示されない書き換え可能な不揮発性メモリ（ＥＥＰＲＯＭ：Ｅｌｅｃｔｒｉｃａｌｙ Ｐｒｏｇｒａｍｍａｂｌｅ ａｎｄ Ｅｒａｓａｂｌｅ ＲＯＭ）に格納され、ＣＰＵ１０Ａは、ＥＥＰＲＯＭから命令コードをフェッチしてデコードし実行する。すなわち、基本処理２２と追加処理２３を実行するそれぞれのＯＳ２１Ａ、２１Ｂが格納するメモリは、基本処理側と追加処理側で、ハードウェア的に分離されている。そして、基本処理、ＯＳ等の命令コードは、ＥＥＰＲＯＭに格納されたものが実行されるが、ＣＰＵ１０Ａ、１０Ｂで実行されるプログラムにより、初期化、参照、更新されるテーブル等のデータは、それぞれのＯＳ起動時に、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）よりなるメモリ５０に展開される。そして、ＣＰＵ１０Ｂについて、リード／ライトするメモリ領域をアクセス制御手段３０によって管理し、ＣＰＵ１０Ａで参照されるメモリ領域へのアクセスを制限している。携帯型情報通信端末とは別の一般の情報処理装置においても、同様にして、基本処理２２、ＯＳ２１ＡがロードされＣＰＵ１０Ａが命令コードをフェッチするメモリと、追加処理２３、ＯＳ２１ＢがロードされＣＰＵ１０Ｂが命令コードをフェッチするメモリとを別々に備えていても良いことは勿論である。あるいは、一般の情報処理装置において、メモリ５０に、基本処理２２、ＯＳ２１Ａがロードされる領域と、追加処理２３、ＯＳ２１Ｂがロードされる領域を分離して設け、ＣＰＵ１０Ｂのメモリ５０へのリード／ライトアクセスをアクセス制御手段３０によって管理するようにしても良い。この場合、ＣＰＵ１０Ａ、ＣＰＵ１０Ｂが参照のみするコードについては、共通のメモリ領域に格納し、アクセス制御手段３０によって、共通のメモリ領域を、該ＣＰＵ１０Ｂがリードのみ可とするようにアクセス制御しても良い。
また、携帯型情報処理装置において、搭載する電池残量が少なくなってきた場合には、基本処理を実行するＣＰＵ以外を強制的にシャットダウンする、実行する処理の信頼度に応じてより信頼度の低い処理を実行するＣＰＵを優先的にシャットダウンすることで電池残量の節約を行うことが可能である。これは例えば、電池残量を検出する手段と、検出結果を通知する手段によって得られる電池残量に関する情報に基づき、基本処理を行うＣＰＵ上で判断を行い、シャットダウンを実行する、といった処理により実現できる。
さらに、携帯型情報処理装置での資源、例えば外部との通信バンド幅や不揮発メモリ量等はより一層制限されているため、信頼度に応じて資源を確保する相対的な割合を変更することも可能である。これは、例えば、基本処理を行うＣＰＵにおいて、実行する処理の信頼度が高い場合には優先的に資源の確保を許容する、信頼度が低い場合には資源の制限をかける等の判断をすることにより実現される。
図２は、第１例におけるプロセッサ間通信手段のハードウェア構成の一例を示す図である。図２を参照すると、左右両側のＣＰＵ（基本処理を実行するＣＰＵと追加処理を実行するＣＰＵ）間に配設された、割り込み制御装置４１と共有メモリ４２の１セットで、図１のプロセッサ間通信手段４０１、４０２の全体を構成している。割り込み制御装置４１としては、ＣＰＵ＃０、ＣＰＵ＃１、・・・ＣＰＵ＃ｎ用のｎ個の割り込み制御装置４１０〜４１ｎを備え、各割り込み制御装置は、割り込み指示部４１１と、割り込み状態保持部４１２と、割り込み取り消し部４１３とを備えている。また、共有メモリ４２は、ＣＰＵ＃０、ＣＰＵ＃１、・・・ＣＰＵ＃ｎ用のｎ個の通信領域４２０〜４２ｎを備え、各通信領域は、送信情報（データ、メッセージ）をキューイング又はバッファリングする通信キュー４２１と、相互排他制御を行う排他制御領域４２２とを備えている。
例えばＣＰＵ＃０とＣＰＵ＃１の２つの領域を想定すると、ＣＰＵ＃１用の割り込み制御装置４１１と、ＣＰＵ＃１用の通信領域４２１とが、ＣＰＵ＃０からＣＰＵ＃１へプロセッサ間通信手段４０１を構成し、ＣＰＵ＃０用の割り込み制御装置４１０とＣＰＵ＃０用の通信領域４２０とが、ＣＰＵ＃１からＣＰＵ＃０へのプロセッサ間通信手段４０２を構成している。
割り込み制御装置４１と、共有メモリ４２は、ＣＰＵ＃０、ＣＰＵ＃１、・・・ＣＰＵ＃ｎと、バス接続する構成とされる。また、共有メモリ４２の通信キュー４２１には、送信データそのものでなく、送信データを格納するバッファポインタ（たとえばメモリ５０条でのバッファ領域アドレス）を設定するようにしても良い。
第１例では、共有メモリ４２におけるＣＰＵ＃ｉの排他制御領域４２２ｉは、ＣＰＵ＃ｉの通信領域４２ｉを、あるＣＰＵが既に占有している場合、他のＣＰＵがＣＰＵ＃ｉの通信領域４２ｉを使用することが無いようにする相互排他制御のために、設けられている。すなわち、ＣＰＵ＃ｉの排他制御領域４２２ｉは、ｍｕｔｅｘ等のセマフォ、フラグ等の同期管理情報の格納に用いられる。
共有メモリ４２に実装された相互排他制御機構により、送信ＣＰＵと受信ＣＰＵ間におけるデータの整合性（ｃｏｎｓｉｓｔｅｎｃｙ）が保証される。
また、相互排他制御機構により、送信側ＣＰＵは、排他制御領域４２２がロック状態のときは、送信ＣＰＵに対する割り込み要求をあげることが出来ず、これにより、送信ＣＰＵから受信ＣＰＵへの頻繁なデータ送信等、不当な割り込み発生を防ぐことが出来る。
なお、排他制御領域４２２としては、キューへの繋ぎ（エンキュー）、キューからの取り外し（デキュー）のロック管理として用いても良い。
図２において、割り込み制御装置４１を介してひとつの受信ＣＰＵへの多重割り込みを許可する構成とした場合、共有メモリ４２において、各ＣＰＵの通信領域における通信キュー４２１、排他制御領域４２２は、多重数分設けられることになる。
特に制限されないが、共有メモリ４２は、図１のメモリ５０の所定のメモリ領域を共有メモリとして用いても良いし、メモリ５０とは別に、プロセッサ間通信手段４０内に設ける構成としても良い。また、図示されないが、割り込み制御装置４１０〜４１ｎからの割り込み要求（Ｉｎｔｅｒｒｕｐｔ Ｒｅｑｕｅｓｔ）線は、パラレルに受信ＣＰＵに接続する構成としてもよいし（割り込み本数が増える）、あるいは、デイジーチェーン方式で接続する構成としても良い。
受信ＣＰＵは、割り込み制御装置４１からの割り込み要求を受理すると、これを割り込み制御装置４１に通知し、割り込み制御装置４１は、図示されないデータ線に割り込み装置番号（割り込みベクター情報）を転送し、受信ＣＰＵは、割り込み装置番号から割り込みベクターを生成し、スケジューラを介して、受信ＣＰＵで実行される割り込みサービスルーチンが起動され、割り込みサービスルーチンが、対応する共有メモリ４２の通信キューからデータを取得し、排他制御領域のｍｕｔｅｘ等のセマフォをリリース（アンロック）し、割り込みから復帰（Ｒｅｔｕｒｎ Ｆｒｏｍ Ｉｎｔｅｒｒｕｐｔ）するという一連の制御が行われる。
図３は、図２示した第１例のプロセッサ間通信手段の動作手順を説明するための図であり、ＣＰＵ＃ｋからＣＰＵ＃０へデータを転送する場合の手順が示されている。図３において、矢線脇の数字は、ステップ番号を表している。
ステップ１：送信ＣＰＵ＃ｋは、共有メモリ４２のＣＰＵ＃０の通信領域の排他制御領域をロックする。なお、共有メモリ４２のＣＰＵ＃０の通信領域の排他制御領域が他のＣＰＵによりロックされていることを示している場合、例えば該ロックが解除されるまで待機する。
ステップ２：送信ＣＰＵ＃ｋは、共有メモリ４２のＣＰＵ＃０の通信領域の排他制御領域をロックした後、共有メモリ４２のＣＰＵ＃０用通信領域の通信キューに、受信ＣＰＵ＃０に送信するデータを書きこむ。
ステップ３：送信ＣＰＵ＃ｋは、割り込み制御領域４１のＣＰＵ＃０用割り込み制御装置の割り込み指示部に、割り込み要求を通知する。
ステップ４：ＣＰＵ＃０用割り込み制御装置の割り込み指示部は、ＣＰＵ＃０用割り込み制御装置の割り込み状態保持部を更新し、「割り込み要求有り」に設定する。
ステップ５：ＣＰＵ＃０用割り込み制御装置の割り込み指示部は、受信ＣＰＵ＃０へ割り込みを行う。
ステップ６：受信ＣＰＵ＃０は、ＣＰＵ＃０用割り込み制御装置の割り込み指示部からの割り込みを受理し、共有メモリ４２のＣＰＵ＃０用通信領域の通信キューから、データを取り出す。このとき、受信ＣＰＵ＃０では、上記した割り込みサービスルーチンによる処理が行われる。
ステップ７：受信ＣＰＵ＃０は、共有メモリ４２のＣＰＵ＃０用通信領域の通信キューから、データを取得した後、ＣＰＵ＃０用割り込み取り消し部に、割り込み処理完了を通知する。
ステップ８：受信ＣＰＵ＃０からの取り込み処理完了通知を受けたＣＰＵ＃０用割り込み制御装置の割り込み指示部は、ＣＰＵ＃０用割り込み制御装置の割り込み状態保持部を
更新する。
ステップ９：受信ＣＰＵ＃０は、共有メモリ４２のＣＰＵ＃０の通信領域の排他制御領域をアンロックする。
第１例において、特定の受信ＣＰＵへの割り込み要求の集中を確認した場合、受診ＣＰＵへの割り込み要求を制御する等の流量制御、帯域制御を行うようにしても良い。すなわち、割り込み制御装置４１内に、送信ＣＰＵ側から受信ＣＰＵに対して、連続・多発して割り込み要求を上げることがないように制限するＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）保証機能を備えても良い。例えば、受信ＣＰＵへのデータの引渡しを伴わない割り込み要求は、排他制御の対象とされず、複数連続して発行することが出来る。そこで、受信ＣＰＵ側で割り込み処理が完了しない状態において、送信ＣＰＵ側からの割り込み要求が発生し、割り込み制御装置４１の割り込み状態保持部の「割り込み要求有り」が所定以上となった場合に、以降の送信ＣＰＵ側から割り込み要求を不許可とする制御が行うようにしてもよい。かかる構成により、例えば送信ＣＰＵが、受信ＣＰＵへのデータの引渡しを伴わない割り込み要求を多量に発生することで、受信ＣＰＵの性能を低下させるといった類の攻撃を抑えることが出来る。
図４は、図１に示した第１例のアクセス制御手段３０の構成を示す図である。図４を参照すると、このアクセス制御手段は３０は、基本側バス７０Ａを介して、基本処理（図１の２２）を実行するＣＰＵ１０Ａに接続詞、追加側バス７０Ｂを介して追加処理（図１の２３）を実行するＣＰＵ１０Ｂに接続するアクセス許可手段３１と、アクセス許可データ３２を格納した記憶手段を備えている。
アクセス許可データ３２は、ＣＰＵ１０Ａから読み出し・書き込みが可能とされる。アクセス許可手段３１からは読み出しのみが許可されている。そして、アクセス許可データ３２は、ＣＰＵ１０Ｂからは読み出しも書き込みも不可とされる。すなわち、アクセス許可データ３２とＣＰＵ１０Ｂの間にはデータバスが存在しない。
アクセス許可手段３１は、追加側バス７０Ｂのアドレス信号線、制御信号線に転送される、メモリ５０（図１参照）へのアクセスアドレス信号、及び制御信号（アクセスコマンド）から、アクセスの種別（リード／ライト）を判別し、アクセス許可データ３２の情報を参照して、当該アクセスが適正であるか否かを判別する。判別の結果、アクセスが不当と判断された場合、アクセス許可手段３１は、基本側バス７０Ａへのアクセスアドレス、制御信号（アクセスコマンド）の送出を行わず、これにより、ＣＰＵ１０Ｂ側から、基本側バス７０Ａへのアクセスは行われない。この場合、追加側バス７０Ｂにアクセスアドレスを送出したＣＰＵ１０Ｂ側では、バスエラー、あるいは、リード／ライトアドレスに対するメモリ５０等からの不応答により、該アクセスが失敗したことを知る。
アクセス許可手段３１は、入出力デバイス（Ｉ／Ｏ）６０がメモリマップドＩ／Ｏである場合には、追加側バス７０Ｂを監視し、アクセスアドレスが入出力デバイス対応のアドレスであることを検出し、データバス上に、Ｉ／Ｏコマンド（リード／ライト等）を検出した場合、該アクセスが適正であるかをアクセス許可データ３２の情報を参照して決定する。入出力デバイスがメモリマップドＩ／Ｏでない場合も、追加側バス７０Ｂに転送される入出力デバイスのデバイス番号、Ｉ／Ｏコマンドをデコードし、アクセス許可データ３２の情報を参照して、アクセスの可否を決定する。
なお、第１例において、アクセス制御手段３０は、単位時間あたりのデータ転送量の制御を行う帯域制約手段を備えてもよい。一例として、アクセス制御手段３０は、ＣＰＵ１０Ｂがアクセス動作中に、ＣＰＵ１０Ｂから追加側バス７０Ｂに転送されるデータ量を測定監視する手段を備え、例えば、単位時間あたり予め定められた閾値を超えるバイト数のデータが転送される場合、ＣＰＵ１０ＢからＣＰＵ１０Ａへのデータ転送を打ち切る制御を行うようにしてもよい。その際、ＣＰＵ１０Ｂが、ＣＰＵ１０Ａへのデータ転送がフェイルしたことを知ってリトライした場合にも、アクセス制御手段３０は、ＣＰＵ１０ＢからのデータをＣＰＵ１０Ａに転送することは行わない。あるいは、アクセス制御手段３０は、バッファを備え、ＣＰＵ１０Ｂから追加側バス７０Ｂに転送されるデータをバッファに蓄積し、ＣＰＵ１０Ａに転送されるデータの流量を制御する構成としてもよい。
図５は、第１例におけるアクセス許可データ３２の一例を示す図である。図５を参照すると、アクセス許可データは、追加処理を実行するＣＰＵ（図４の追加側バスに接続するＣＰＵ）と、アクセスが許可される範囲の始点アドレスと終点アドレスからなる許可範囲アドレスと、許可するアクセス種別（リード、リード／ライト、ライトの種別）がテーブル形式で格納されている。なお、許可範囲アドレスは、異なるＣＰＵで重複しても良い。図５に示す例では、２行目のＣＰＵ＃２、＃３の許可範囲アドレスは、０ｘＣ００００００から０ｘＦ００００００で、読み出し／書き込み可（Ｒ／Ｗ）あり、３行目のＣＰＵ＃３の許可範囲アドレスは、０ｘＥ００００００から０ｘＦ００００００であり、２行目と重複している。アドレス許可データの数、したがってテーブルのエントリ数は、その数が多いほど、きめ細かく、アクセス制御を行うことが出来る。なお、図５では、説明のため、Ｒ（読み出し可）、Ｗ（書き込み可）、Ｒ／Ｗ（読み出し／書き込み可）を例示したが、Ｒ（読み出し可）は、読み出しのみ可とし書き込みを不可とする情報であり、Ｗを書き込みを可（読み出しも可）とした場合には、Ｒ／Ｗは、不要とされる。また、読み出しが不可（書き込みも不可）のアドレス範囲は、アドレス許可データ３２には格納されない。図５に示す例では、アクセス許可データとして、アクセスが許可されたＣＰＵのそれぞれについて、アドレス範囲と、アクセス種別を有するが、アクセス許可データに、アクセス種別として、アクセス不可の情報をさらに設け、追加処理を実行するＣＰＵについて、アクセス不可のアドレス範囲を格納するようにしても良い。
図４のアクセス許可手段３１は、追加側のＣＰＵからのアクセス要求（アドレス、読み書きコマンド）を受け取り、アクセス許可データ３２の許可範囲アドレス、アクセス種別を参照して、許可されたアクセスの場合、該アクセスを許可する。一方、不許可の場合、アクセスを不許可とする。図５に示す例では、ＣＰＵ＃４の場合、始点アドレス１０００から終点アドレス２０００（ヘキサデシマル）とされ、アクセス種別は読み出し（Ｒ）とされる。ＣＰＵ＃２、＃３の場合、始点アドレス０ｘＣ００００００から終点アドレス０ｘＦ００００００（ヘキサデシマル）とされ、アクセス種別は読み出しと書き込み（Ｒ／Ｗ）とされる。ＣＰＵ＃３の場合、始点アドレス０ｘＥ００００００から終点アドレス０ｘＦ００００００（ヘキサデシマル）のアクセス種別は書き込み（Ｗ）とされる。
図６は、図４のアクセス制御手段３０の動作の一例を説明するための図である。図６において、矢線脇の番号は、ステップ番号を示している。
ステップ１：基本処理を実行するＣＰＵ１０Ａは、アクセス制御手段３０のアクセス許可データ３２に、全ての追加処理を実行するＣＰＵ１０Ｂが、あるアドレス範囲を読み出すことを禁止する。
ステップ２：ＣＰＵ１０Ｂが、追加処理２３の実行等により、読み出しが禁止されたアドレス範囲への読み出し要求を発行したとする。
ステップ３：アクセス許可手段３１は、アクセス許可データ３２を読み出し、該アクセス要求の適否をチェックする。
ステップ４：アクセス許可手段３１は、ＣＰＵ１０Ｂへエラーを返す。該アドレス範囲は、ＣＰＵ１０Ｂからの読み出しが禁止されているためである。
ステップ５：ＣＰＵ１０Ｂは、上記アドレス範囲とは別の範囲への読み出し要求を発行する。
ステップ６：アクセス許可手段３１は、アクセス許可データ３２を読み出してチェックする。
ステップ７：アクセス許可手段３１は、ＣＰＵ１０Ｂの読み出しのアクセス要求を許可し、基本側バス７０Ａに読み出し要求として発行する。
なお、第１例では、アクセス制御手段３０の構成として、アクセス許可手段３１と、アクセス許可データ３２を備え、アクセス許可情報に基づき、アクセス制御を行う例について説明したが、第１例にかかる構成のみに制限されるものでなく、アクセス許可のデータに変えて（反転し）、アクセス拒否データと、アクセス拒否手段を備えても良い。この場合、アクセス拒否手段は、追加処理を実行するＣＰＵ１０Ｂからのアクセスアドレスが、アクセス拒否データに、アクセス拒否が定義されたアドレス範囲に合致した場合に、アクセスを拒否する制御を行う。
第１例の変形例として、アクセス許可手段３１に、キャッシュを備えても良い。この場合、アクセス判定に用いたアクセスアドレス、アクセス許可データは、キャッシュに格納され、次回以降のアクセス制御の判定において、該当するアクセスアドレス（アドレス範囲）のアクセス許可データがキャッシュに存在するかを判定し、キャッシュヒットした場合、アクセス判定の高速化を実現している。キャッシュには、アクセスアドレスの範囲に対応するタグアドレス、アクセス許可データを備え、追加側バス７０Ｂのアクセスアドレスがキャッシュとヒットするか否か判定するキャッシュヒット判定回路を備えて構成される。
さらに、第１例の変形例として、アクセス制御手段３０が、新アクセス許可データ３３と、アクセス許可データ更新手段３４を備える構成としてもよい。図７を参照すると、アクセス制御手段３０は、図６に示した第１例に加えて、基本側バス７０Ａに接続するアクセス許可データ更新手段３４と新アクセス許可データ３３を格納した記憶手段を備えている。この２つの手段の機能について詳細を説明する。
新アクセス許可データ３３は、図６のアクセス許可データ３２と同じ特徴を持つのに加え、アクセス許可データ更新手段３４からのみの読み出しを許可する記憶手段である。
アクセス許可データ更新手段３４は、基本側バス７０Ａを通じたＣＰＵ１０Ａからの要求によって、新アクセス許可データ３３の内容をアトミックに新アクセス許可データ３４に上書きする。
なお、第１例の変形例において、アクセス許可データ３２の更新ではなく、新アクセス許可データ３３への切替を行う手段を設けてもよい。
このような構成によれば、アクセス許可データ３２の更新をＣＰＵによりアトミックに書き換えることが可能となるため、アクセス制御手段３０による保護すべき領域、制限すべき領域を動的に変更することが可能である。
また、図８は、第１例のアクセス制御手段３０の別構成を示す図である。図８を参照すると、このアクセス制御手段３０は、図６に示した第１例に加えて、追加側バス７０Ｂに接続するアクセス監視手段３５と学習手段３６を備えている。この手段の機能について詳細を説明する。
アクセス監視手段３５は、アクセス許可手段３１と同様に追加側バス７０Ｂを通じたＣＰＵ１０Ｂからのアクセス情報を取得する。
学習手段３６は、前記アクセス監視手段３５から提供されるアクセス情報に基づき、その参照が適切かどうかを判断する。例えば、ユーザ保護データに対する参照回数をカウントしておき、もしあらかじめ指定された閾値を越えた場合には、異常事態と認定し、アクセス監視手段３５にそのことを通知し、別途定められたルールに従ってアクセス許可データ３２を動的に変更する。また、場合によっては、基本側バス７０ＡにつながるＣＰＵ１０Ａに通知をし、異常時の処理を起動してもよい。
このような構成によれば、実際に参照されたパターンから信頼度が低いと思われるＣＰＵの動作を履歴情報として蓄積することで自律的に制限できるため、実動作におけるＣＰＵの動作状況に基づいたより安全な実行制御を行うことが可能となる。
また、アクセス制御手段３０の構成例としては、図６の構成に加えて、上記説明した新アクセス許可データ３３、アクセス許可データ更新手段３４、アクセス監視手段３５、学習手段３６のすべてを備える構成とすることも可能である。
図９は、基本構成の第２例の構成を示す図である。図９を参照すると、第２例は、図１の構成に加えて、追加処理側のソフトウェアとＯＳ、ＣＰＵをさらに１組追加したものである。すなわち、第２の追加処理側のＣＰＵ１０Ｃは、プロセッサ間通信手段を介して、第１の追加処理用のＣＰＵ１０Ｂと相互に通信する。また、第２の追加処理側のＣＰＵ１０Ｃは、第２のアクセス制御手段３０２を介して、基本側バス７０Ａに接続される。
各アクセス制御手段３０１、３０２の設定は、基本処理２２を実行するＣＰＵ１０Ａが設定する。すなわち、基本処理２２を実行するＣＰＵ１０Ａが、マスタープロセッサとして機能する。ＣＰＵ１０Ａにより、メモリ５０及び入出力デバイス（Ｉ／Ｏ）６０の集中的な管理が行われる。
第２の追加処理２３Ｃを実行するＣＰＵ１０Ｃは、第１の追加処理２３Ｂを実行するＣＰＵ１０Ｂに対してプロセッサ間通信手段４０３を介して通信（データ、コマンドの送信）を行い、第１の追加処理２３Ｂを実行するＣＰＵ１０Ｂは、基本処理２２を実行するＣＰＵ１０Ａに対してプロセッサ間通信手段４０１を介して通信（データ、コマンドの送信）を行う。また、第２の追加処理２３Ｃを実行するＣＰＵ１０Ｃは、第２のアクセス制御手段３０２の監視の下、メモリ５０、入出力デバイス（Ｉ／Ｏ）６０に対して許可されたアクセスのみを行い、第１の追加処理２３Ｂを実行するＣＰＵ１０Ｂは、第１のアクセス制御手段３０１の監視の下、メモリ５０、入出力デバイス（Ｉ／Ｏ）６０に対して許可されたアクセスのみを行い、第１のアクセス制御手段３０１、第２のアクセス制御手段３０２のアクセス許可データの設定は、すべてＣＰＵ１０Ａによって行われる。かかる構成により、集中的な管理が行われ、また、プロセッサ間通信手段４０により、ＣＰＵ間で処理の受け渡しが行われる。第２例においても、基本処理２２を実行するＣＰＵ１０Ａに対する、追加処理２３Ｂ、２３Ｃからの直接的な攻撃等は回避される。すなわち、前記第１例と同様に、追加処理２３Ｂ、２３Ｃは、基本処理２２を直接起動あるいはサブルーチン呼出しすることは出来ず、基本処理２２の起動要求は、例えばＣＰＵ１０ＣからＣＰＵ１０Ｂを介して、ＣＰＵ１０Ａに、プロセッサ間通信手段を介して伝達され、該要求を受け取ったＣＰＵ１０Ａでは、権限が付与されていないＣＰＵからの要求である場合、該要求を受理しない（この詳細については、後述するソフトウェアの実施例で詳述する）。このように、追加処理側のＣＰＵと基本処理側のＣＰＵに権限の階層が設けられるほか、プロセッサ間通信手段４０、及びアクセス制御手段３０というハードウェア機構を介することで、基本処理等の直接的な攻撃は、回避される。第２例におけるプロセッサ間通信手段４０１〜４０４は、図２に示した前記第１例の構成と同様とされ、アクセス制御手段３０１、３０２も、図４に示した前記第１例の構成と同様とされるため、その詳細構成、動作の説明は省略する。
図１０は、基本構成の第３例の構成を示す図である。図１０を参照すると、第３例は、図９に示した構成と同様に、図１の構成にさらに、追加処理側のＣＰＵ１０Ｃと、アクセス制御手段３０２を追加したものである。第３例は、図９に示した前記第２例と相違して、メモリと入出力デバイス（Ｉ／Ｏ）を、各組（ドメイン）のＣＰＵ群毎に用意している。
第２の追加処理ＣＰＵ１０Ｃは、許可されたメモリ５０Ｃ、入出力デバイス（Ｉ／Ｏ）６０Ｃには、アクセス制限なく自在にアクセスすることが出来る。第１の追加処理ＣＰＵ１０Ｂには、許可されたメモリ５０Ｂ、入出力デバイス（Ｉ／Ｏ）６０Ｂには、アクセス制限なくアクセスすることが出来る。
第２の追加処理側のＣＰＵ１０Ｃからの、基本処理側のメモリ５０Ａ、入出力デバイス（Ｉ／Ｏ）６０Ａへのアクセスは、第２のアクセス制御手段３０２及び第１のアクセス制御手段３０１の２段構成にて、アクセス制御が行われる。
第１の追加処理側のＣＰＵ１０Ｂからの、基本処理側のメモリ５０Ａ、入出力デバイス（Ｉ／Ｏ）６０へのアクセスは、第１のアクセス制御手段３０１により、アクセス許可が判定される。
第１のアクセス制御手段３０１のアクセス許可データ、第２のアクセス制御手段３０２のアクセス許可データは、基本処理のＣＰＵ１０Ａが設定する。第２のアクセス制御手段３０２のアクセス許可データは第１の追加処理のＣＰＵ１０Ｂが設定しても良い。第３例によれば、メモリ、入出力デバイス（Ｉ／Ｏ）をドメイン単位に分離し、ＣＰＵ間をプロセッサ間通信手段４０で多段に接続する構成としたことにより、追加処理による攻撃からの防護機能を高め、安全性を確保している。
図１１は、第３例の変形例を示す図であり、図１に示した第１例を２以上のチップにおいて適用した例である。図１１を参照すると、ＣＰＵ１０Ａ、１０Ｂ、１０Ｃ、１０Ｄとアクセス制御手段３０１の組み合わせからなるチップ８０を複数並べることに加えて、さらに個々のチップ８０間をアクセス制御手段３０３で結合する。すなわち、チップ８０Ａ、チップ８０Ｂ等を複数並べ、チップ８０Ａとチップ８０Ｂ間等をアクセス制御手段３０３で結合する。
ある一チップ８０内における一部のＣＰＵを基本処理実行用として設けることで、一チップ８０内のアクセス制御手段３０１によりアクセス制限を行うこともできるし、各チップ８０内の少なくとも一部のＣＰＵを基本処理実行用として設けることも可能である。
また、異なるチップ８０にまたがってドメインを構成し、各チップ８０間のアクセス制御手段３０３により実行を制御することも可能である。
いずれの場合でも、適切なアクセス制御手段３０の設定によって、複数のチップ８０間においても本発明を適用する情報処理装置の基本構成における実行制御を行うことが可能となる。
上記第３例では、主に、本発明のハードウェア構成について説明したが、本発明のソフトウェア構成について以下に説明する。
図１２は、本発明を実施するソフトウェア構成の一例を示す図であり、基本ドメインと、Ｔｒｕｓｔｅｄ（信頼）拡張ドメイン、Ｕｎｔｒｕｓｔｅｄ（無信頼）拡張ドメインを備えている。図１２のハードウェア構成としては、３つの群のＣＰＵを備えた、図１０の構成等を用いることが出来る。この場合、基本処理を実行する実行環境である基本ドメインは、図１０のソフト２０、ＯＳ２１Ａに対応し、Ｔｒｕｓｔｅｄ拡張ドメインは、図１０のソフト２０Ｂ、ＯＳ２１Ｂに対応し、Ｕｎｔｒｕｓｔｅｄ拡張ドメインは、図１０のソフト２０Ｃ、ＯＳ２１Ｃに対応させることが出来る。
図１２を参照すると、基本ドメイン１００Ａは、基本アプリケーションプログラム（「基本アプリケーション」という）１１１と、基本性能１１２を含む基本ソフト１１０と、ＯＳ１０１Ａと、専用ファイルシステム１０３と、外部デバイス１０２Ａを備え、ネイティブコードダウンロード管理機能１０４Ａと、セキュリティポリシデータベース１０５を備えている。特に制限されないが、基本機能１１２は、例えば、第３例の情報処理装置が携帯型情報通信端末である場合、発呼、着信処理等の呼処理、インターネットアクセス、画面処理等の、携帯型情報通信端末の基本性能を実現するもので、図１の基本処理２２に対応している。基本アプリケーション１１１は、基本機能１１２を呼び出して処理を行い、基本機能１１２は、ＯＳを介してファイルシステム、外部デバイスへのアクセスを行う。外部デバイスは、ワイヤレス通信インタフェース等の通信インタフェース、表示装置のインタフェース、キー、ポインティングデバイス等の入力インタフェース、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）メモリーカードインターフェース、サウンドインタフェース等を含む。
Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂは、ネイティブコードダウンロード実行機能１０４Ｂと、ダウンロードアプリケーションプログラム（「ダウンロードアプリケーション」という）１２０Ｂと、基本性能ライブラリ（ラッパー）１１３と、ＯＳ１０１Ｂと、許可された外部デバイス１０２Ｂを備えている。
ＯＳ１０１Ｂは、証明書付のダウンロードドライバ１２１Ｂを含む。証明書付のダウンロードドライバ１２１Ｂは、許可された外部デバイス１０２Ｂの入出力制御を行う。
Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃは、ネイティブコードダウンロード実行機能１０４Ｃと、ダウンロードアプリケーション１２０Ｃと、ＯＳ１０１Ｃと、許可された外部デバイス１０２Ｃを備えている。ＯＳ１０１Ｃに組み込まれるダウンロードドライバ１２１Ｃは、許可された外部デバイス１０２Ｃの入出力制御を行う。
基本ドメイン１００Ａの外部デバイス１０２Ａから入力され、ダウンロードされたファイルについて、ネイティブコードダウンロード管理機能１０４Ａが、セキュリティポリシデータベース１０５の内容を参照することで、信頼できる（信頼できる電子証明書付）ネイティブコードのアプリケーションを、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂに転送し、信頼できる（信頼できる電子証明書付）ネイティブコードのダウンロードドライバ１２１ＢのＯＳ１０１Ｂへの組み込みを行う。
また、ネイティブコードダウンロード管理機能１０４Ａは、信頼できない（例えば電子証明書無しであるか、証明書の内容が正しくない場合等）アプリケーションを、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ経由で、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃへ転送し、信頼できない（証明書無し）ダウンロードドライバのＵｎｔｒｕｓｔｅｄ拡張ドメインのＯＳ１０１Ｃへの組み込みを行う。
Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂからは、基本機能１１２の呼出しは許可されるが、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃからの基本機能１１２の呼び出しは、許可されない。ただし、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００ＣとＴｒｕｓｔｅｄ拡張ドメイン１００Ｂとの協働作業は可能である。
信頼できるドメインで動作するアプリケーションプログラムは、信頼できないドメインからのデータについて、ユーザの確認（ＯＫ）があった場合にのみ、基本機能１１２へ引き渡す。ユーザの確認無く、信頼できないドメインからのデータを、基本機能１１２に渡さない。なお、信頼できる拡張ドメイン１００Ｂから、直接、基本ドメイン１００Ａの基本機能１１２へ、処理要求を発行することは出来ない。
図１３は、図１２に示した第３例の動作を説明するための図であり、基本アプリケーションの実行を示す図である。図１３において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：基本ドメイン１００Ａの基本アプリケーション１１１は、基本機能１１２に、処理要求（例えば、アドレス帳の追加等）を発行する。
ステップ２：基本機能１１２は、ＯＳ１０１Ａを利用して、該当要求を処理する。
ステップ３：基本機能１１２は、基本アプリケーション１１１に要求の成否を通知する。
図１４は、図１２に示した第３例の動作を説明するための図であり、信頼アプリケーションのダウンロードの実行の様子を示す図である。図１４において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：基本ドメイン１００Ａ上の外部デバイス１０２Ａ（ネットワーク又はＳＤメモリカード等）からＯＳ１０１Ａにダウンロードデータが到着する。
ステップ２：ダウンロードデータは、基本機能１１２にて、属性情報等の情報から、追加アプリケーション（ダウンロードアプリケーション）と認識される。
ステップ３：基本機能１１２は、追加アプリケーションを、ネイティブコードダウンロード管理機能１０４Ａに渡し、ネイティブコードダウンロード管理機能１０４Ａは、セキュリティポリシデータベース１０５を参照して、追加アプリケーションに付随した電子証明書をチェックする。前述したように、例えば電子証明書には、公開鍵やデジタル署名（証明される機関や公開鍵などを秘密鍵で暗号化したもの）が格納され、ネイティブコードダウンロード管理機能１０４Ａが、証明書の認証を行う場合には、デジタル署名の部分を、公開鍵で解読して、証明書のデータの内容と一致するか否かを確認し、一致する場合に、証明書のデータを信頼してもよいと判断する。さらに、アプリケーションのダイジェストからなるデジタル署名を付随しておくことで、ダウンロードしたアプリケーションが改竄されていないかどうかチェックすることが出来る。
ステップ４：ネイティブコードダウンロード管理機能１０４Ａは、電子証明書とともに、ダウンロード情報を、セキュリティポリシデータベース１０５に保存する。
ステップ５：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、電子証明書のチェックの結果、正しい場合、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂに、ダウンロードアプリケーションを送信し、実行を要求する。基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａから、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂのデータの送信は、図９又は図１０のプロセッサ間通信手段４０を用いて行われる。
ステップ６：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂは、受け取ったダウンロードアプリケーションを実行するように制御する。
ステップ７：ダウンロードアプリケーションはＴｒｕｓｔｅｄ拡張ドメイン上で実行される。
図１５は、図１２に示した第３例の動作を説明するための図であり、信頼ドライバのダウンロード実行を示す図である。信頼ドライバとは、例えばダウンロードされたドライバに添付される電子証明書の照合結果が正しいドライバを言う。図１５において、各矢線に付された番号は、当該線を情報が転送される図轍鮒番号を表している。
ステップ１：基本ドメイン１００Ａ上の外部デバイス１０２Ａ（ネットワーク又はＳＤカード等）からＯＳ１０１Ａにダウンロードデータが到着する。
ステップ２：基本機能１１２にて、属性情報、自動インストール情報等から、ダウンロードデータは、追加デバイスドライバ（ダウンロードドライバ）であると認識する。
ステップ３：基本機能１１２は、受信したドライバを、ネイティブコードダウンロード管理機能１０４Ａに渡す。ネイティブコードダウンロード管理機能１０４Ａは、セキュリティポリシデータベース１０５を参照して、ダウンロードデータに付随した電子証明書をチェックする。
ステップ４：ネイティブコードダウンロード管理機能１０４Ａは、電子証明書とともに、ダウンロード情報をセキュリティポリシデータベース１０５に保存する。
ステップ５：ネイティブコードダウンロード管理機能１０４Ａは、Ｔｒｕｓｔｅｄ拡張ドメインのネイティブコードダウンロード実行機能１０４Ｂに対して、ダウンロードドライバを送信し、インストールの実行を要求する。基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａから、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂのデータの送信は、図９又は図１０のプロセッサ間通信手段４０を用いて行われる。
ステップ６：Ｔｒｕｓｔｅｄ拡張ドメインのネイティブコードダウンロード実行機能１０４Ｂは、受け取ったダウンロードドライバを自動インストールする。特に制限されないが、第３例において、ダウンロードドライバはインストールした後ＣＰＵを再起動してＯＳ１０１Ｂのある領域に組み込むレジデント型のドライバであっても良い。
ステップ７：Ｔｒｕｓｔｅｄ拡張ドメインのＯＳ１０１Ｂは、ダウンロードドライバをインストールされたことを、既に実行済みのアプリケーションに通知するか、表示する。
ステップ８：Ｔｒｕｓｔｅｄ拡張ドメインにおいて、既に実行済みのアプリケーション１０２Ｂは、インストールされたダウンロードドライバ１２１Ｂを参照する。
ステップ９：Ｔｒｕｓｔｅｄ拡張ドメインのＯＳ１０１Ｂにインストールされ、ロードされたダウンロードドライバ１２１Ｂは、許可された外部デバイス１０２Ｂをアクセスする。
ステップ１０：ダウンロードドライバ１２１Ｂは、ダウンロードアプリケーション１２１０Ｂに外部デバイス１０２Ｂからのデータを返す。
図１６は、図１２に示した第３例の動作を説明するための図であり、Ｔｒｕｓｔｅｄ拡張ドメインの信頼アプリケーション（ダウンロードアプリケーション）が、基本ドメインの基本機能を利用する場合の動作を示す図である。図１６において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂにおいて、ダウンロードアプリケーション１２０Ｂが、基本機能ライブラリ１１３へ、基本ドメイン１００Ａの基本機能１１２の処理を要求する。基本機能ライブラリ１１３は、基本ドメイン１００Ａの基本機能１１２の処理を実行するためのルーチンを集めたライブラリであり、ダウンロードアプリケーション１２０Ｂから起動される。
ステップ２：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３は、ダウンロードアプリケーション１２０Ｂが保有する電子証明書の鍵（公開鍵等）を用いて、要求を暗号化し、暗号化した要求を、基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａへ送信する。Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３から基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａへの要求の送信は、図９又は図１０のプロセッサ間通信手段４０を介して行われる。
ステップ３：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、受け取った要求を復号し、該要求を、電子証明書を利用して、要求送信元が適正であるか否か等のチェックを行う。なお、この例では、要求の暗号化と復号を用いて、要求をチェックしているが、アプリケーションと電子証明書の対応がとれる方法であれば、任意の方法を用いてよいことは勿論である。
ステップ４：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、要求のチェックの結果、ＯＫであれば、基本機能１１２へ要求を依頼する。
ステップ５：基本ドメイン１００Ａの基本機能１１２は、ネイティブコードダウンロード管理機能１０４Ａから受け渡された該要求を処理し、処理終了後、基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａへ、処理完了を通知する。
ステップ６：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３へ、処理の完了を通知する。基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４ＡからＴｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３への通知の送信は、図９又は図１０のプロセッサ間通信手段を介して行われる。
ステップ７：Ｔｒｕｓｔｅｄ拡張ドメイン基本機能ライブラリ１１３は、ダウンロードアプリケーション１２０Ｂに、要求に対する応答として処理の完了を通知する。
図１７は、図１２に示した第３例の動作を説明するための図であり、Ｕｎｔｒｕｓｔｅｄ拡張ドメインの無信頼アプリケーションのダウンロードの実行手順を示す図である。図１７において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：基本ドメイン１００Ａ上の外部デバイス１０２Ａ（ネットワーク又はＳＤカード等）から、ＯＳ１０１Ａにダウンロードデータが到着する。
ステップ２：基本ドメイン１００Ａの基本機能１１２では、属性情報等を解析し、ダウンロードデータをアプリケーション（ダウンロードアプリケーション）を認識する。
ステップ３：基本ドメイン１００Ａの基本機能１１２は、ダウンロードアプリケーションを、ネイティブコードダウンロード管理機能１０４Ａに渡す。ネイティブコードダウンロード管理機能１０４Ａでは、アプリケーションに、電子証明書が付随されていないか、あるいは電子証明書が正しくないと判別する。
ステップ４：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、セキュリティポリシデータベース１０５に、ダウンロード情報を保存する。
ステップ５：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、Ｔｒｕｓｔｅｄ拡張ドメインのネイティブコードダウンロード実行機能１０４Ｂに、ダウンロードされたアプリケーションを送信する。基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４ＡからＴｒｕｓｔｅｄ拡張ドメインのネイティブコードダウンロード実行機能１０４Ｂへのアプリケーションの送信は、図９又は図１０に示したプロセッサ間通信手段４０を介して行われる。
ステップ６：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂは、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃのネイティブコードダウンロード実行機能１０４Ｃにアプリケーションを送信し、実行を要求する。Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４ＢからＵｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃのネイティブコードダウンロード実行機能１０４Ｃへのアプリケーションの送信は、図９又は図１０に示したプロセッサ間通信手段４０を介して行われる。
ステップ７：Ｕｎｔｒｕｓｔｅｄ拡張ドメインのネイティブコードダウンロード実行機能１０４Ｃは、受信したダウンロードアプリケーション１２０Ｃの起動を行う。
ステップ８：ダウンロードアプリケーション１２０Ｃは、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃで動作を開始する。この場合、Ｕｎｔｒｕｓｔｅｄ拡張ドメインのダウンロードアプリケーション１２０Ｃは、Ｕｎｔｒｕｓｔｅｄ拡張ドメインのＯＳ１０１Ｃ上で動作し、許可された外部デバイス１０２Ｃへのアクセスのみが許可される。
図１８は、図１２に示した第３例の動作を説明するための図であり、無信頼ドライバのダウンロード実行の様子を示す図である。図１８において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：基本ドメイン１００Ａ上の外部デバイス１０２Ａ（ネットワーク又はＳＤカード等）から、ＯＳ１０１Ａにダウンロードデータが到着する。
ステップ２：基本機能１１２は、ダウンロードデータの到着で起動され、属性情報、インストール情報等のダウンロードデータを解析し、デバイスドライバ（ダウンロードドライバ）と認識する。
ステップ３：基本機能１１２は、ダウンロードドライバを、ネイティブコードダウンロード管理機能１０４Ａに渡し、ネイティブコードダウンロード管理機能１０４Ａは、ダウンロードドライバに電子証明書が添付されていないか、あるいは、電子証明書は添付されているが、電子証明書の内容が正しくないことが分かる。
ステップ４：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、ダウンロード情報のみをセキュリティポリシデータベース１０５に保存する。
ステップ５：ネイティブコードダウンロード管理機能１０４Ａは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂにダウンロードドライバを送信する。ネイティブコードダウンロード管理機能１０４ＡからＴｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂへのダウンロードドライバの送信は、図９又は図１０に示したプロセッサ間通信手段４０を介して行われる。
ステップ６：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂは、受け取ったダウンロードドライバを、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃのネイティブコードダウンロード実行機能１０４Ｃに転送する。Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４ＢからＵｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃのネイティブコードダウンロード実行機能１０４Ｃへのダウンロードドライバの転送は、図９又は図１０に示したプロセッサ間通信手段４０を介して行われる。
ステップ７：Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃのネイティブコードダウンロード実行機能１０４Ｃは、受信したダウンロードドライバ１２１Ｃをインストールする。
ステップ８：ＯＳ１０１Ｃは、ドライバ１２１Ｃがインストールされたことを、既に実行済みのアプリケーション１２０Ｃへ通知するか、画面に表示する（ユーザに通知する）。
ステップ９：Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃにおいて、既に実行済みのアプリケーション１２０Ｃは、インストールされたダウンロードドライバ１２１Ｃを参照する。
ステップ１０：Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃにおいて、インストールされたダウンロードドライバ１２１Ｃは、Ｕｎｔｒｕｓｔｅｄ拡張ドメインのＯＳ１０１Ｃを介して、許可された外部デバイス１０２Ｃをアクセスする。
ステップ１１：Ｕｎｔｒｕｓｔｅｄ拡張ドメインにおいて、ダウンロードドライバ１２１Ｃは、ダウンロードアプリケーション１２０Ｃに、外部デバイス１０２Ｃから取得したデータを返す。
図１９は、図１２に示した第３例の動作を説明するための図であり、信頼アプリケーションと無信頼アプリケーションの連携の様子を示す図である。図１９において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃ上のダウンロードアプリケーション１２０Ｃは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上のダウンロードアプリケーション１２０Ｂへデータを送信する。このデータの送信は、通常、図９又は図１０のプロセッサ間通信手段４０によって行われる。
ステップ２：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上のダウンロードアプリケーション１２０Ｂ」は、受け取ったデータによる処理を行い、基本機能ライブラリ１１３へ、Ｕｎｔｒｕｓｔｅｄ拡張ドメインと連携した情報を含む基本機能処理を要求する。
ステップ３：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上の基本機能ライブラリ１１３は、アプリケーションが保有する電子証明書を用いて、要求を暗号化し、基本ドメイン１００Ａ上のネイティブコードダウンロード管理機能１０４Ａへ送信する。この要求の送信は、通常、図９又は図１０のプロセッサ間通信手段４０によって行われる。
ステップ４：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、要求を復号し、該要求の安全性を、セキュリティポリシデータベース１０５に格納された電子証明書を利用してチェックする。チェックの結果、要求が正しい場合、ネイティブコードダウンロード管理機能１０４Ａは、基本アプリケーション１１１を介して、ユーザに確認を求める。基本アプリケーション１１１は、画面表示、入力のアプリケーションを含む。なお、この例では、要求の暗号化と復号を用いて、アプリケーションと電子証明書の対応をチェックしているが、アプリケーションと電子証明書との対応が取れる方法であれば、任意の方法を用いても良いことは勿論である。
ステップ５：ユーザからの確認として「ＮＯ」が入力されるとする。
ステップ６：ネイティブコードダウンロード管理機能１０４Ａは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３へ不許可を通知する。この不許可の通知は、通常、図９又は図１０のプロセッサ間通信手段４０によって行われる。
ステップ７：基本機能ライブラリ１１３は、ダウンロードアプリケーション１２０Ｂへ不許可を通知する。
ステップ８：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上のダウンロードアプリケーション１２０Ｂは、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃ上のダウンロードアプリケーション１２０Ｃに不許可を通知する。この不許可の通知は、通常、図９又は図１０のプロセッサ間通信手段４０によって行われる。
図２０は、図１２に示した第３例の動作を説明するための図であり、信頼アプリケーションと無信頼アプリケーションの連携を示す図である。図２０において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃ上のダウンロードアプリケーション１２０Ｃは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上のダウンロードアプリケーション１２０Ｂへデータを送信する。このデータの送信は、図９又は図１０等のプロセッサ間通信手段４０によって行われる。
ステップ２：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上のダウンロードアプリケーション１２０Ｂは、受け取ったデータによる処理を行い、基本機能ライブラリ１１３へ、Ｕｎｔｒｕｓｔｅｄと連携した情報を含む基本機能処理を要求する。
ステップ３：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３は、アプリケーション１２０Ｂｇａ保有する電子証明書を用いて、要求を暗号化し、基本ドメイン１００Ａ上のネイティブコードダウンロード管理機能１０４Ａへ送信する。この要求は、通常、図９又は図１０のプロセッサ間通信手段４０によって行われる。
ステップ４：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、要求を復号し、該要求の安全性を、セキュリティポリシデータベース１０５に格納される電子証明書を利用してチェックする。チェックの結果、要求が正しい場合、ネイティブコードダウンロード管理機能１０４Ａは、基本アプリケーション１１１を介してユーザに確認を求める。なお、この例では、要求の暗号化と復号を用いて、アプリケーションと電子証明書の対応をチェックしているが、アプリケーションと電子証明書との対応が取れる方法であれば、任意の方法を用いても良いことは勿論である。
ステップ５：この場合、ユーザの確認として「ＹＥＳ」が入力される。
ステップ６：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、基本機能１１２へ要求を依頼する。
ステップ７：基本機能１１２は、要求を処理し、ネイティブコードダウンロード管理機能１０４Ａに処理完了を通知する。
ステップ８：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３に完了を通知する。この完了通知は、図９又は図１０のプロセッサ間通信手段４０によって行われる。
ステップ９：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３は、ダウンロードアプリケーション１２０Ｂに完了を通知する。
ステップ１０：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのダウンロードアプリケーション１２０Ｂは、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃのダウンロードアプリケーション１２０Ｃに完了を通知する。この完了通知は、図９又は図１０のプロセッサ間通信手段４０によって行われる。
図２１は、基本構成の第４例の構成を示す図である。ＯＳとＣＰＵ間に仮想マシンモニタ（ＯＳとの間に設けられ、ＣＰＵで実行されるソフトウェア層）を備えている。これにより、ＣＰＵ、Ｉ／Ｏ、メモリ資源を仮想化している。仮想マシンモニタは、ＯＳとＣＰＵ間で、仮想ハードウェア（例えば仮想入出力デバイス）を、実際のハードウェアデバイスにマッピングする。基本ドメイン、Ｔｒｕｓｔｅｄ拡張ドメイン、Ｕｎｔｒｕｓｔｅｄ拡張ドメインのそれぞれについて、ＯＳは、仮想の専用ファイルシステム、仮想外部デバイスとの入出力（Ｉ／Ｏ）制御を行い、ＯＳとＣＰＵ間に、仮想ＣＰＵ２００Ａ、２００Ｂ、２００Ｃ、仮想マシンモニタ２１０Ａ、２１０Ｂ、２１０Ｃを備え、仮想の専用ファイルシステム１０３’、仮想外部デバイス１０２Ａ’、１０２Ｂ’、１０２Ｃ’を、対応する実ファイルシステム、実外部デバイスへマッピングする。
第４例によれば、図１０のハードウェア構成、図１２のソフトウェア構成と相違して、第４例において、例えば基本ドメインに対応する仮想ＣＰＵは固定でなく、Ｔｒｕｓｔｅｄ拡張ドメイン等のＣＰＵを、基本ドメインの仮想ＣＰＵとしてマッピングすることができる。なお、仮想マシンモニタは、その実装において、既存のＯＳ、アプリケーションプログラム、ＣＰＵ等の修正等は不要とされる。第４例によれば、各ドメインのＣＰＵの個数は可変とされ、仮想ＣＰＵを構成する。ソフトウェア構成としては、基本ドメイン、Ｔｒｕｓｔｅｄ拡張ドメイン、Ｕｎｔｒｕｓｔｅｄ拡張ドメインの構成は、デバイス、ファイルシステムが仮想デバイス、仮想ファイルシステムであることを除いて、図１２に示した構成と同様である。
図２２は、図２１に示した第４例の処理手順の一例を示す図である。図２２において、各矢線に付された番号は、ステップ番号を表している。
ステップ１：基本ドメイン１００Ａの仮想マシンモニタ２１０Ａは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上の仮想マシンモニタ２１０Ｂに対してＣＰＵの委譲を要求する。
ステップ２：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上の仮想マシンモニタ２１０Ｂは、仮想ＣＰＵ資源を減らす。
ステップ３：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上の仮想マシンモニタ２１０Ｂは、基本ドメイン１００Ａ上のＣＰＵ上の仮想マシンモニタ２１０Ａに委譲可能なＣＰＵを通知する。
ステップ４：基本ドメイン１００Ａ上の仮想マシンモニタ２１０Ａは、アクセス制御手段等の設定を行い、仮想ＣＰＵの数を増やす。
第４例によれば、別の群のＣＰＵを、基本ドメインのＣＰＵのように動作させることが出来る。なお、アプリケーションのダウンロード処理は、前記した第３例の処理動作（図１３乃至図２０）と同一であるため、その説明は省略する。
第４例の変形例として、仮想マシンモニタを、セキュアモードで動作させるようにしても良い。このようにすることで、安全性をさらに向上させることが出来る。
上記ソフトウェアの各例において、各ドメインのＣＰＵ群がマルチプロセッサとして動作する場合、キャッシュコヒーレンスを保つためのバス、仮想マルチプロセッサの無効化のために、ＴＬＢ（Ｔｒａｎｓｌａｔｉｏｎ Ｌｏｏｋａｓｉｄｅ Ｂｕｆｆｅｒ：アドレス管理ユニット内に設けられるアドレス変換表）の全エントリをフラッシュするシュートダウン等、ハードウェアで協調動作するチャネルについては、すべて、基本ドメイン１００Ａから、制御できるように構成されている。また、図２３に示すように、各ドメインのＣＰＵ群（例えば図１のマルチＣＰＵ構成のＣＰＵ群１０Ａ、１０Ｂ）を、分離手段１５を介して、複数に分業できる構成としても良い。これにより、例えばあるドメインのＣＰＵを他のドメインに委譲する際の制御が容易化し、さらに障害マルチプロセッサの分離（ｇｒａｃｅｆｕｌ ｄｅｇｒａｄｉｎｇ）等にも対応可能としている。
なお、前記第１例〜第４例では、ネットワーク等装置外部からネイティブコードの追加処理（アプリケーション、デバイスドライバ）をダウンロードして実行する情報通信端末装置を例に説明したが、本発明は、かかる情報通信端末装置に限定されるものでなく、任意の情報処理装置に適用可能である。
（第１の実施例）
上記において基本構成として示した情報処理装置のいずれかに対して本発明を適用した第１の実施例について説明する。基本構成で示したのと同様の構成及び動作については適宜説明を省略する。
（第１の実施例の構成）
図２４に示すように、本発明の第１の実施例による情報処理装置は、マルチプロセッサにより構成されており、最高信頼度ドメイン１５０Ａ、中信頼度ドメイン１５０Ｂ、低信頼度ドメイン１５０Ｃと、データ送信部３０１，３０２，３０３と、低信頼度ドメイン用データ送信部３０４，３０５と、中信頼度ドメイン用データ送信部３０６，３０７と、ドメイン停止復旧手段４００とを備え、ドメインからの復旧等の要求を通知されると、通知された要求に対応する処理を実行する機能を有し、または、その要求が正当な場合に、通知された要求に対応する処理を実行する機能を有する。
なお、本発明の第１の実施例による情報処理装置は、マルチプロセッサ上で各ドメインが有するシングルプロセッサ向けＯＳと既存のアプリケーションをそれらに改造を加えることなく動作させ、その既存のアプリケーションに対してマルチプロセッサによる並列処理を実現できるようにしたシングルプロセッサ向けＯＳによる並列処理システムにかかるものでもよい。
この場合には、シングルプロセッサ上でアプリケーションを動作させるよりも高速処理が可能となり、また、マルチプロセッサがそれぞれ独立したＯＳを備える並列処理システムよりも簡易な構成により並列処理が実現できる。
最高信頼度ドメイン１５０Ａは、前述の第２例の図９や第３例の図１０におけるソフトウェア２０ＡとＣＰＵ１０Ａとからなる構成や、第４例の図２１における基本ドメイン１００Ａと仮想ＣＰＵ２００Ａと仮想マシンモニタ２１０Ａとからなる構成に対応し、また、基本ドメイン１００Ａと同様に、基本アプリケーションや基本ソフトを有する。これら基本アプリケーションや基本ソフトとして、例えば、メーラー、ブラウザ、ｉモード（登録商標）や、アドレス帳の機能等を備えるものが挙げられる。
また、最高信頼度ドメイン１５０Ａは、自身が備えるＣＰＵ、ＯＳによって、中信頼度ドメイン１５０Ｂ及び低信頼度ドメイン１５０Ｃと、ドメインで発行された処理要求に関するデータや制御に関するデータ等を通信する機能を有する。
なお、最高信頼度ドメイン１５０Ａは、ある一定のセキュリティレベル以上の処理を実行するドメインであり、他のドメインと分離して設けられており、また、例えば、外部からダウンロードされたネイティブコードの実行は行わず、さらに、最も高い信頼度であることから、他の全てのドメインについて、停止状態等の障害を復旧することが可能である。
また、最高信頼度ドメイン１５０Ａは、最高信頼度ドメイン１５０Ａ以外への通信経路専用の低信頼度ドメイン用データ送信部３０４及び中信頼度ドメイン用データ送信部３０６と、最高信頼度ドメイン１５０Ａ以外のドメインからの通信経路専用のデータ送信部３０２，３０３とに接続しており、各ドメインへの通信経路がそれぞれ別に設けられていることから、最高信頼度ドメイン１５０Ａのみに各種データの書き込みが許可される。
中信頼度ドメイン１５０Ｂは、前述の第２例の図９や第３例の図１０におけるソフトウェア２０ＢとＣＰＵ１０Ｂとからなる構成や、第４例の図２１におけるＴｒｕｓｔｅｄ（信頼）拡張ドメイン１００Ｂと仮想ＣＰＵ２００Ｂと仮想マシンモニタ２１０Ｂとからなる構成に対応する。
また、中信頼度ドメイン１５０Ｂは、自身が備えるＣＰＵ、ＯＳによって、最高信頼度ドメイン１５０Ａ及び低信頼度ドメイン１５０Ｃと、ドメインで発行された処理要求に関するデータや制御に関するデータ等を通信する機能を有する。
なお、中信頼度ドメイン１５０Ｂは、最高信頼ドメイン１５０Ａで実行する処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、他のドメインと分離して設けられており、また、例えば、ダウンロードされたネイティブコードのうち、信頼できると保障されたコードのみを実行する。
低信頼度ドメイン１５０Ｃは、前述の第２例の図９や第３例の図１０におけるソフトウェア２０ＣとＣＰＵ１０Ｃとからなる構成や、第４例の図２１におけるＵｎｔｒｕｓｔｅｄ（無信頼）拡張ドメイン１００Ｃと仮想ＣＰＵ２００Ｃと仮想マシンモニタ２１０Ｃとからなる構成に対応する。
また、低信頼度ドメイン１５０Ｃは、自身が備えるＣＰＵ、ＯＳによって、最高信頼度ドメイン１５０Ａ及び中信頼度ドメイン１５０Ｂと、ドメインで発行された処理要求に関するデータや制御に関するデータ等を通信する機能を有する。
なお、低信頼度ドメイン１５０Ｃは、中信頼度ドメイン１５０Ｂで実行する処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、他のドメインと分離して設けられており、また、例えば、ダウンロードされたネイティブコードのうち、信頼できると保障されたコード以外のコードを実行する。
また、最高信頼度ドメイン１５０Ａ、中信頼度ドメイン１５０Ｂ、低信頼度ドメイン１５０Ｃは、以下のように形成してもよい。
最高信頼ドメイン１５０Ａは、最高信頼ドメイン１５０Ａのセキュリティレベルの実行処理のそれぞれが、中信頼度ドメイン１５０Ｂの実行処理のセキュリティレベルと同じか又は高く、そして基本ドメインの実行処理の集合として少なくとも１つセキュリティレベルの高い処理を含むドメインとし、中信頼ドメイン１５０Ｂは、中信頼度ドメイン１５０Ｂのセキュリティレベルの実行処理のそれぞれが、低信頼度ドメイン１５０Ｃの実行処理のセキュリティレベルと同じか又は高く、そして各ドメインの実行処理の集合として少なくとも１つセキュリティレベルの高い処理を含むドメインとし、低信頼度ドメイン１５０Ｃは、低信頼度ドメイン１５０Ｃのセキュリティレベルの実行処理のそれぞれが、中信頼度ドメイン１５０Ｂの実行処理のセキュリティレベルと同じか又は低く、そして各ドメインの実行処理の集合として少なくとも１つセキュリティレベルの低い処理を含むドメインとする。
この場合には、最高信頼度ドメイン１５０Ａは、中信頼度ドメイン１５０Ｂよりも相対的にセキュリティレベルの高い処理を行い、中信頼ドメイン１５０Ｂは、低信頼度ドメイン１５０Ｃよりも相対的に高い処理を行う。
本発明の第１の実施例における信頼度とは、処理ごとに付与されたセキュリティの度合いを示す電子証明書に基づき、あるセキュリティポリシーに従ってセキュリティレベルの段階ごとに設定されるものをいう。例えば、デジタル署名が付与された処理ごとに、あるセキュリティポリシーに基づきセキュリティレベルが設定される。
図２５は、機能重要度設定テーブル７００を示す図であり、本発明の第１の実施例において設定される信頼度の一例を示す。
図２５に示すように、信頼度は、例えば、階層的に、レベルＡ：パスワードが必要、レベルＢ：２度確認しない、レベルＣ：実行ごとに確認、レベルＤ：アクセスごとに確認、のように各レベルの重要度に応じたセキュリティレベルで設定される。
これを利用して、実行する機能に応じてドメインに信頼度を付与する。すなわち、ドメインによる障害の復旧要求の内容の重要度に応じて信頼度を設定する。
これにより、例えば、低信頼度ドメイン１５０Ｃからの復旧要求を一律には拒否せずに、軽微な障害についての復旧要求の場合にはこれを許諾するなど、柔軟な復旧処理が可能となる。
最高信頼度ドメイン１５０ＡにはレベルＡ、中信頼度ドメイン１５０ＢにはレベルＢ、低信頼度ドメイン１５０ＣにはレベルＣを配置するというように、一ドメインには同種のセキュリティレベルのみを配置してもよいが、柔軟な復旧処理を可能にする信頼度の設定として、例えば、図２５のように、最高信頼度ドメイン１５０Ａには実行する機能の重要度によってレベルＡ以上、レベルＢ以上、中信頼度ドメイン１５０Ｂにも実行する機能によってレベルＢ以上、レベルＣ以上、低信頼度ドメイン１５０Ｃにも実行する機能によってレベルＣ以上、レベルＤ以上という配置としても良い。
このように設定された信頼度は、例えば、最高信頼度ドメイン１５０Ａによって管理されていてもよく、この場合には、最高信頼度ドメイン１５０Ａの判断により、実行する機能や処理について信頼度に応じた優先順位を定めることができる。
このような設定が可能であればどんな証明書やどんなセキュリティポリシーに基づいて設定してもよく、実行する機能やドメイン数に応じて任意に設定することが可能である。
データ送信部３０１，３０２，３０３は、ドメインで発行された処理要求に関するデータや制御に関するデータ等を送信する機能を有し、構成例として例えば、共有メモリとプロセッサ間割込み、ＦＩＦＯやキュー、デュアルポートメモリーや、他にＬＡＮ等のネットワーク、有線通信や無線通信等からなる構成が挙げられ、データを送信する機能を有する従来の一般的な技術でよく、データ送信が可能であれば構成は特に制限されない。
データ送信部３０１，３０２，３０３で送信されるデータは、処理要求を発行した要求元ドメインを識別する情報、処理の対象となるドメインを識別する情報、処理の内容を識別する情報等を含み、また、場合により、処理の対象となるドメインの実際の障害状況に関する情報を含む。
なお、データ送信部３０１，３０２，３０３は、送信先ドメイン内の上位層へのエラー通知又はエラー処理を行う機構（不図示）を備える。送信先ドメインが復旧処理中のデータ送信においては、このような機構によりデータ送信完了までの無駄な待ちを排除する必要があるからである。
また、後述のデータ送信手段３０４ａ、３０５ａ、３０６ａ、３０７ａも同様である。
データ送信部３０１は、最高信頼度ドメイン１５０Ａで発行された、中信頼度ドメイン１５０Ｂや低信頼度ドメイン１５０Ｃの復旧等を要求する処理要求等を、ドメイン停止復旧手段４００に通知する機能を有する。
データ送信部３０２は、中信頼度ドメイン１５０Ｂで発行された、中信頼度ドメイン１５０Ｂや低信頼度ドメイン１５０Ｃの復旧等を要求する処理要求等を、最高信頼度ドメイン１５０Ａに通知する機能を有する。
データ送信部３０３は、低信頼度ドメイン１５０Ｃで発行された、中信頼度ドメイン１５０Ｂや低信頼度ドメイン１５０Ｃの復旧等を要求する処理要求等を、最高信頼度ドメイン１５０Ａに通知する機能を有する。
低信頼度ドメイン用データ送信部３０４，３０５は、それぞれデータ送信手段３０４ａ，３０５ａと、低信頼度ドメイン停止検知手段３０４ｂ，３０５ｂとを備え、対象ドメインである低信頼度ドメイン１５０Ｃへのデータ送信時に低信頼度ドメイン１５０Ｃが実際にどのような障害状況にあるかを検知する機能を有する。
中信頼度ドメイン用データ送信部３０６，３０７は、それぞれデータ送信手段３０６ａ，３０７ａと、中信頼度ドメイン停止検知手段３０６ｂ，３０７ｂとを備え、対象ドメインである中信頼度ドメイン１５０Ｂへのデータ送信時に中信頼度ドメイン１５０Ｂが実際にどのような障害状況にあるかを検知する機能を有する。
データ送信手段３０４ａ，３０５ａ，３０６ａ，３０７ａは、前述の通り、上記データ送信部３０１，３０２，３０３と同様の機能を有する。
低信頼度ドメイン停止検知手段３０４ｂ，３０５ｂは、データ送信手段３０４ａ又は３０５ａによって低信頼度ドメイン１５０Ｃにデータ送信をする際に、低信頼度ドメイン１５０Ｃが実際に停止状態であるか否かを検知する機能を有する。
この検知機能は、例えば、送信先ドメインである低信頼度ドメイン１５０Ｃに当該データが受信されているか否かを判断することによって、低信頼度ドメイン１５０Ｃが停止状態であるか否かを検知する。具体的には、当該データが低信頼度ドメイン１５０Ｃに受理されない時間や回数を計測することによって検知することができる。なお、最高信頼度ドメイン１５０Ａや、中信頼度ドメイン１５０Ｂの処理負担を増大させないために、当該検知処理に要する時間はより短時間であることが望ましい。
また、低信頼度ドメイン停止検知手段３０４ｂ，３０５ｂは、低信頼度ドメイン１５０Ｃが停止状態であることを検知すると、最高信頼度ドメイン１５０Ａに、低信頼度ドメイン１５０Ｃが停止状態であることを通知する。
中信頼度ドメイン停止検知手段３０６ｂは、低信頼度ドメイン停止検知手段３０４ｂ，３０５ｂと同様の構成及び機能を備え、データ送信手段３０６ａによって中信頼度ドメイン１５０Ｂにデータ送信をする際に、中信頼度ドメイン１５０Ｂ（の障害内容を検知）が実際に停止状態であるか否かを検知する機能を有する。
この検知機能は、例えば、送信先ドメインである中信頼度ドメイン１５０Ｂに当該データが受信されているか否かを判断することによって、中信頼度ドメイン１５０Ｂが停止状態であるか否かを検知する。具体的には、当該データが中信頼度ドメイン１５０Ｂに受理されない時間や回数を計測することによって判断することができる。なお、最高信頼度ドメイン１５０Ａの処理負担を増大させないために、当該検知処理に要する時間はより短時間であることが望ましい。
また、中信頼度ドメイン停止検知手段３０６ｂは、中信頼度ドメイン１５０Ｂが停止状態であることを確認すると、最高信頼度ドメイン１５０Ａに、中信頼度ドメイン１５０Ｂが停止状態であることを通知する。
なお、後述するように、中信頼度ドメイン停止検知手段３０６ｂは、中信頼度ドメイン１５０Ｂに対する復旧処理を許可するための権限を有する場合には、中信頼度ドメイン１５０Ｂが停止状態であることをドメイン停止復旧手段４００に直接通知し、ドメイン停止復旧手段４００を用いて中信頼度ドメイン１５０Ｂの復旧処理を行ってもよい。
この場合には、最高信頼度ドメイン１５０Ａが復旧処理の許可に関する処理を行わないことから、最高信頼度ドメイン１５０Ａの処理負担が軽くなるという効果を奏する。
一方、中信頼度ドメイン停止検知手段３０７ｂは、自ドメインより信頼度が高いドメインの停止を検知する手段であり、データ送信手段３０６ａによって中信頼度ドメイン１５０Ｂにデータ送信をする際に、中信頼度ドメイン１５０Ｂが実際に停止状態であるか否かを検知する機能を有する。
この検知機能は、例えば、送信先ドメインである中信頼度ドメイン１５０Ｂに当該データが受信されているか否かを判断することによって、中信頼度ドメイン１５０Ｂが停止状態であるか否かを検知する。具体的には、当該データが中信頼度ドメイン１５０Ｂに受理されない時間や回数を計測することによって判断することができる。なお、当該検知処理の時間が短いと、低信頼度ドメイン１５０Ｃが最高信頼度ドメイン１５０Ａに通知する情報の真偽についての信頼度が低いので、当該検知処理にはより長時間を設けることを必要とする。
また、中信頼度ドメイン停止検知手段３０７ｂは、中信頼度ドメイン１５０Ｂが停止状態であることを検知すると、最高信頼度ドメイン１５０Ａに、中信頼度ドメイン１５０Ｂが停止状態であることを通知する。
また、上記各ドメイン停止検知手段は、停止検知の対象となるドメインが実際に停止状態であるか否かを、例えば、以下の示すような方法によって検知することができる。
（１）送信元ドメインが、停止検知の対象となる送信先ドメインに定期的に送るチェックパケットの応答の有無を計測することによって検知できる。具体的には、応答のない時間や回数を計測する。また、計測する当該時間や回数は信頼度の差に応じて変更してもよい。
（２）送信先ドメインが表示する停止・暴走情報を計測することによって検知できる。具体的には、送信先ドメインが定期的に更新する情報が途絶えたことを計測する。
なお、上記における当該時間、回数や更新情報の計測頻度等をそれぞれ送信先ドメインよりも高い信頼度のドメインが設定可能としてもよい。ただし、最低閾値を超えての設定の変更はできないものとする。
上記各ドメイン停止検知手段は、上記各検知処理の手法や当該時間、回数や更新情報等を任意に組み合わせることによって、停止検知の対象となるドメインが実際に停止状態であるか否かを確認してもよい。
ドメイン停止復旧手段４００は、データ送信部３０１を介して最高信頼度ドメイン１５０Ａから通知された処理要求等に基づいて、対象となるドメイン内のＣＰＵのリセットやＯＳのリブート、ドメイン自体のリブートや、例えば、何月何日等の特定日時の環境へのロールバックや、あるいは、通信路の復旧やアプリの再起動等、復旧処理を含む様々な処理要求を実行する機能を有しており、さらに、最高信頼度ドメイン１５０Ａからのみアクセスできる構成になっており、最高信頼度ドメイン１５０Ａからの処理要求は無条件で受け入れる。
なお、ドメイン停止復旧手段４００は、最高信頼度ドメイン１５０Ａ以外のドメインから復旧処理等の処理要求がなされた場合、これらは全て拒否する。
すなわち、復旧条件は、個々のドメインの信頼度に応じて、そのドメインからの復旧要求の許可または拒否によって決定することができる。例えば、本実施例での復旧条件は、最高信頼度ドメインからの復旧要求を全て許可し、一方それ以外のドメインからの復旧要求を全て拒否する、と規定される。
図２６に、ドメイン停止復旧手段４００の構成を示す。
図２６が示すように、ドメイン停止復旧手段４００は、復旧要求受信手段４０１と、ドメイン停止復旧処理手段４０２とを備える。
復旧要求受信手段４０１は、最高信頼度ドメイン１５０Ａからデータ送信部３０１を介して復旧要求（処理要求）を受信し、この処理要求をドメイン停止復旧処理手段４０２に通知する機能を有する。
ドメイン停止復旧処理手段４０２は、復旧要求受信手段４０１から通知された処理要求に基づいて、何れのドメインが処理の対象となり、どのような処理要求がされたのか、その処理内容を識別し、該当するドメインに該当する処理内容を依頼をする。
例えば、最高信頼度ドメイン１５０Ａから通知された処理要求が、停止している中信頼度ドメイン１５０Ｂの復旧処理要求の場合、ドメイン停止復旧処理手段４０２は、停止している中信頼度ドメイン１５０Ｂに対して復旧処理を依頼をする。
なお、通信においては、各層において通信相手が規定されるので、それぞれの階層で検知された障害の種類によって処理内容が異なる。例えば、それぞれの階層で検知された停止の状態によって復旧内容が異なる。
図２７に、通信処理の内容（処理内容）とその階層構造との対応関係の一例を示す。
図２７が示すように、各ドメインの階層構造は、上の階層から順に、例えば、アプリケーション層、ライブラリ層、ＯＳ層、ＣＰＵ層と構成され、ドメイン停止復旧処理手段４０２は、予め定められた階層毎に対応する停止検知処理を実行して通信処理（復旧処理）を行う。
通信処理の内容（復旧処理内容）は、アプリケーション層でのアプリの再起動、ライブラリ層でのある時点へのロールバック、ＯＳ層でのＯＳリブート、ＣＰＵ層でのＣＰＵロールバックである。
なお、第１の実施例における情報処理装置を動作させるプログラムは、上記各部及び各手段で実現される機能を安定して実現する必要があるために、外部からダウンロードした追加処理の影響を受けることがない最高信頼度ドメイン１５０Ａで格納及び実行されることが好ましい。
ここで、第１の実施例による情報処理装置のハードウェア構成の説明をする。
図２８は、第１の実施例による情報処理装置のハードウェア構成の一例を示すブロック図である。
図２８を参照すると、第１の実施例による情報処理装置は、一般的なコンピュータ装置と同様のハードウェア構成を備えることによって実現することができ、複数のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）５０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等のメインメモリであるデータの作業領域やデータの一時退避領域に用いられる主記憶部５０２、インターネット６００を介してデータの送受信を行う通信部５０３、液晶ディスプレイ、プリンタやスピーカ等の提示部５０４、キー操作部等の入力部５０５、周辺機器と接続してデータの送受信を行うインタフェース部５０６、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、磁気ディスク、半導体メモリ等の不揮発性メモリから構成されるハードディスク装置である補助記憶部５０７、本情報処理装置の上記各構成要素を相互に接続するシステムバス５０８等を備えている。
第１の実施例による情報処理装置は、その動作を、情報処理装置内部にそのような機能を実現するプログラムを組み込んだ、ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等のハードウェア部品からなる回路部品を実装してハードウェア的に実現することは勿論として、上記した各手段及び各部の各機能を提供するプログラムを、コンピュータ処理装置上のＣＰＵ５０１で実行することにより、ソフトウェア的に実現することができる。
（第１の実施例の動作）
（最高信頼度ドメイン１５０Ａによる処理要求）
図２９は、図２４に示した第１の実施例の動作の一例を説明するための図であり、最高信頼度ドメイン１５０Ａによる中信頼度ドメイン１５０Ｂの停止検知・復旧処理を示す。図２９において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
まず、初期状態として、中信頼度ドメイン１５０Ｂが異常停止をしていることとする。
ステップ１：最高信頼度ドメイン１５０Ａが、中信頼度ドメイン停止検知機能付データ送信部３０６のデータ送信手段３０６ａを介して、中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ２：中信頼度ドメイン停止検知機能付データ送信部３０６の中信頼度ドメイン停止検知手段３０６ｂが、中信頼度ドメイン１５０Ｂの停止を検知する。
ステップ３：中信頼度ドメイン停止検知手段３０６ｂが中信頼度ドメイン１５０Ｂの停止を検知したことにより、最高信頼度ドメイン１５０Ａが、データ送信部３０１を介して、ドメイン停止復旧手段４００に中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ４：ドメイン停止復旧手段４００が、最高信頼度ドメイン１５０Ａからの復旧要求に基づいて、中信頼度ドメイン１５０Ｂを復旧する。
図３０は、図２４に示した第１の実施例の動作の一例を説明するための図であり、最高信頼度ドメイン１５０Ａによる低信頼度ドメイン１５０Ｃの停止検知・復旧処理を示す。図３０において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
まず、初期状態として、低信頼度ドメイン１５０Ｃが異常停止をしていることとする。
ステップ１：最高信頼度ドメイン１５０Ａが、低信頼度ドメイン停止検知機能付データ送信部３０４のデータ送信手段３０４ａを介して、低信頼度ドメイン１５０Ｃへデータを送信する。
ステップ２：低信頼度ドメイン停止検知機能付データ送信部３０４の中信頼度ドメイン停止検知手段３０４ｂが低信頼度ドメイン１５０Ｃの停止を検知する。
ステップ３：低信頼度ドメイン停止検知手段３０４ｂが低信頼度ドメイン１５０Ｃの停止を検知したことにより、最高信頼度ドメイン１５０Ａが、データ送信部３０１を介して、ドメイン停止復旧手段４００に低信頼度ドメイン１５０Ｃの復旧を要求する。
ステップ４：ドメイン停止復旧手段４００が、最高信頼度ドメイン１５０Ａからの復旧要求に基づいて、低信頼度ドメイン１５０Ｃを復旧する。
（中信頼度ドメイン１５０Ｂによる処理要求）
図３１は、図２４に示した第１の実施例の動作の一例を説明するための図であり、中信頼度ドメイン１５０Ｂによる低信頼度ドメイン１５０Ｃの停止検知・復旧処理を示す。図３１において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
まず、初期状態として、低信頼度ドメイン１５０Ｃが異常停止をしていることとする。
ステップ１：中信頼度ドメイン１５０Ｂが、低信頼度ドメイン停止検知機能付データ送信部３０５のデータ送信手段３０５ａを介して、低信頼度ドメイン１５０Ｃへデータを送信する。
ステップ２：低信頼度ドメイン停止検知機能付データ送信部３０５の低信頼度ドメイン停止検知手段３０５ｂが、低信頼度ドメイン１５０Ｃの停止を検知する。
ステップ３：低信頼度ドメイン停止検知手段３０５ｂが低信頼度ドメイン１５０Ｃの停止を検知したことにより、中信頼度ドメイン１５０Ｂが、データ送信部３０２を介して、最高信頼度ドメイン１５０Ａに低信頼度ドメイン１５０Ｃの復旧を要求する。
ステップ４：最高信頼度ドメイン１５０Ａが、データ送信部３０１を介して、ドメイン停止復旧手段４００に低信頼度ドメイン１５０Ｃの復旧を要求する。
ステップ５ドメイン停止復旧手段４００が、最高信頼度ドメイン１５０Ａからの復旧要求に基づいて、低信頼度ドメイン１５０Ｃを復旧する。
なお、ステップ３とステップ４との間において、最高信頼度ドメイン１５０Ａが、復旧を要求された上記低信頼度ドメイン１５０Ｃが実際に停止しているかを確認するために、低信頼度ドメイン停止検知機能付データ送信部３０４を用いて停止の有無を検知してもよい。
あるいは、ステップ４とステップ５との間において、ドメイン停止復旧手段４００が、復旧を要求された上記低信頼度ドメイン１５０Ｃが実際に停止しているかを確認するために、低信頼度ドメイン停止検知機能付データ送信部３０４を用いて停止の有無を検知してもよい。
（低信頼度ドメイン１５０Ｃによる処理要求）
図３２は、図２４に示した第１の実施例の動作の一例を説明するための図であり、低信頼度ドメイン１５０Ｃによる中信頼度ドメイン１５０Ｂの停止検知・復旧処理を示す。図３２において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
まず、初期状態として、中信頼度ドメイン１５０Ｂが異常停止をしていることとする。
ステップ１：低信頼度ドメイン１５０Ｃが、中信頼度ドメイン停止検知機能付データ送信部３０７のデータ送信手段３０７ａを介して、中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ２：中信頼度ドメイン停止検知機能付データ送信部３０７の中信頼度ドメイン停止検知手段３０７ｂが、中信頼度ドメイン１５０Ｂの停止を検知する。
ステップ３：中信頼度ドメイン停止検知手段３０７ｂが中信頼度ドメイン１５０Ｂの停止を検知したことにより、低信頼度ドメイン１５０Ｃが、データ送信部３０３を介して、最高信頼度ドメイン１５０Ａに中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ４：復旧要求元ドメインである低信頼度ドメイン１５０Ｃが、復旧対象ドメインである中信頼度ドメイン１５０Ｂより信頼度が低く、さらに、低信頼度であることから、最高信頼度ドメイン１５０Ａが、復旧要求の対象や内容の真偽を確認するため、中信頼度ドメイン停止検知機能付データ送信部３０６のデータ送信手段３０６ａを介して、中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ５：中信頼度ドメイン停止検知機能付データ送信部３０６の中信頼度ドメイン停止検知手段３０６ｂが、中信頼度ドメイン１５０Ｂの停止を検知することにより、実際に中信頼度ドメイン１５０Ｂが停止していることを確認する。
ステップ６：最高信頼度ドメイン１５０Ａが、実際に中信頼度ドメイン１５０Ｂが停止していることを確認したことにより、データ送信部３０１を介して、ドメイン停止復旧手段４００に中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ７：ドメイン停止復旧手段４００が、最高信頼度ドメイン１５０Ａからの復旧要求に基づいて、中信頼度ドメイン１５０Ｂを復旧する。
なお、ステップ４〜ステップ６において、最高信頼度ドメイン１５０Ａが当該確認処理を行わずに、ステップ６とステップ７との間において、ドメイン停止復旧手段４００が、復旧を要求された上記中信頼度ドメイン１５０Ｂが実際に停止しているかを確認するために、中信頼度ドメイン停止検知機能付データ送信部３０６を用いて停止の有無を検知してもよい。
（同一信頼度ドメインによる処理要求）
図３３は、図２４に示した第１の実施例の動作の一例を説明するための図であり、同一信頼度ドメイン内の停止検知・復旧処理の一例として、中信頼度ドメイン１５０Ｂによる他の中信頼度ドメイン１５０Ｂの停止検知・復旧処理を示す。図３３において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
まず、初期状態として、１群の中信頼度ドメイン１５０Ｂ内の少なくとも一つの中信頼度ドメイン１５０Ｂが異常停止をしていることとする。
ステップ１：停止していない他の中信頼度ドメイン１５０Ｂが、１群の中信頼度ドメイン１５０Ｂ内の上記中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ２：データ送信先の上記中信頼度ドメイン１５０Ｂの停止を検知する。なお、同一信頼度ドメイン内の停止検知処理は、信頼度が設定されていないドメインにおける同一ドメイン内の停止検知処理と同様である。従って、この様な停止検知処理は一般的な技術であるため、説明を省略する。
ステップ３：データ送信先の上記中信頼度ドメイン１５０Ｂの停止を検知したことにより、当該データの送信元である中信頼度ドメイン１５０Ｂが、データ送信部３０２を介して、最高信頼度ドメイン１５０Ａに上記停止状態の中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ４：最高信頼度ドメイン１５０Ａが、データ送信部３０１を介して、ドメイン停止復旧手段４００に上記停止状態の中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ５：ドメイン停止復旧手段４００が、最高信頼度ドメイン１５０Ａからの復旧要求に基づいて、上記停止状態の中信頼度ドメイン１５０Ｂを復旧する。
なお、ステップ３とステップ４との間において、最高信頼度ドメイン１５０Ａが、復旧を要求された上記停止状態の中信頼度ドメイン１５０Ｂが実際に停止しているかを確認するために、中信頼度ドメイン停止検知機能付データ送信部３０６を用いて停止の有無を検知してもよい。
あるいは、ステップ４とステップ５との間において、ドメイン停止復旧手段４００が、復旧を要求された上記停止状態の中信頼度ドメイン１５０Ｂが実際に停止しているかを確認するために、中信頼度ドメイン停止検知機能付データ送信部３０６を用いて停止の有無を検知してもよい。
（第１の実施例による効果）
このように、本発明の第１の実施例によれば、信頼度に基づいて各ドメインが分離されているので、メーラーやブラウザ等の基本処理を有する最高信頼度ドメイン１５０Ａが、最高信頼度ドメイン１５０Ａ以外のドメインからの攻撃等の影響を受けることがなく、最高信頼度ドメイン１５０Ａ以外のドメインが停止する際にも、情報処理装置のメーラーやブラウザ等の基本処理がフリーズしない。すなわち、信頼度が低いドメインからウィルスを含んでいる等の悪意のある処理要求や誤った復旧等の処理要求を受け付けないので、情報処理装置の基本処理がフリーズすることを防止することができる。
また、最高信頼度ドメイン１５０Ａは、最高信頼度ドメイン１５０Ａ以外への通信経路専用の低信頼度ドメイン用データ送信部３０４及び中信頼度ドメイン用データ送信部３０６と、最高信頼度ドメイン１５０Ａ以外のドメインからの通信経路専用のデータ送信部３０２，３０３とに接続しており、各ドメインへの通信経路がそれぞれ設けられていることから、最高信頼度ドメイン１５０Ａのみに各種データの書き込みが許可され、各ドメイン間の排他制御が不要となる。
さらに、ドメイン停止復旧停止手段によって、停止等の障害が生じた、最高信頼度ドメイン１５０Ａ以外のドメインを復旧できるので、最高信頼度ドメイン１５０Ａのセキュリティを確保すると共に、情報処理装置の継続した稼動を可能とする。
また、ウォッチドッグタイマ等による自発的なドメイン復旧では、データ送信先のドメインの復旧にかかる時間が読めないので、エラー対処によって性能が落ち、さらに、自発的なドメイン復旧が起動できない場合があるという問題を有するが、本発明の第１の実施例によれば、最高信頼度ドメイン１５０Ａが、低信頼度ドメイン用データ送信部３０４及び中信頼度ドメイン用データ送信部３０６によって、中信頼度ドメイン１５０Ｂや低信頼度ドメイン１５０Ｃへのデータ送信時にこれらのドメインで生じている障害を検知できるので、データ送信時に、これらの障害の復旧が可能となり、上記問題を回避できる。
さらにまた、最高信頼度ドメイン１５０Ａが、低信頼度ドメイン停止検知手段３０４ｂ及び中信頼度ドメイン停止検知手段という２種類の停止検知手段を備えるため、最高信頼度ドメイン１５０Ａによる停止検知処理について分散化でき、高速化を図ることができる。
また、最高信頼度ドメイン１５０Ａが、自身の判断により、信頼度に応じた優先順位に基づいて復旧処理を行えるので、必要な機能から優先的に復旧できる等、情報処理装置の適切な復旧が可能となる。例えば、障害が発生したあるドメインに対して複数の復旧要求が同時になされた場合でも、復旧要求の要求元のドメインの信頼度や、復旧要求が示す処理内容の信頼度に応じた優先順位の基づいて、柔軟で効率的な復旧処理が可能となる。また、不必要な復旧処理の発生を抑えることや、必要最低限のみの復旧処理を行うことも可能である。
（第２の実施例）
第２の実施例は、図２４に示した第１の実施例に対応し、第１の実施例と同様の構成を採用するが、ドメイン停止復旧手段４００が、各種ドメインで発行された要求を受信する停止確認手段４０３を有する点で相違する。
以下、上記の第１の実施例との相違点について主に説明し、第１の実施例と共通する構成要素については説明を省略する。
（第２の実施例の構成）
図３４は、第２の実施例によるドメイン停止復旧手段４００の構成を示す図である。
図３４に示すように、第２の実施例によるドメイン停止復旧手段４００は、停止確認手段４０３を備える点で第１の実施例と相違する。
停止確認手段４０３は、復旧要求受信手段４０１を介して、各種ドメインから通知された情報から、復旧要求（処理要求）を発行した要求元ドメインを識別する情報、処理の対象となるドメインを識別する情報、処理の内容を識別する情報等を取得し、低信頼度ドメイン用データ送信部３０４や中信頼度ドメイン用データ送信部３０６を用いて処理の対象となるドメインの実際の障害状況を検知し、取得した処理の内容の真偽を確認する機能を有する。
停止確認手段４０３は、このようにして、取得した処理の内容が正しいと確認した場合に、各種ドメインから通知された情報をドメイン停止復旧処理手段４０２に通知し、処理を要求する。
ドメイン停止復旧処理手段４０２は、停止確認手段から処理を要求されると、停止確認手段４０３から通知された情報に基づいて、処理の対象となるドメイン内の所定の手段に復旧等の処理を依頼する。
なお、第２の実施例では、ドメイン停止復旧手段４００が有する停止確認手段４０３が、低信頼度ドメイン用データ送信部３０４や中信頼度ドメイン用データ送信部３０６を備えていてもよいし、また、停止確認手段４０３が、ドメイン停止復旧手段４００の外部にあり、各種ドメインから通知された情報に基づいて上記検知処理を行い、ドメイン停止復旧手段４００内のドメイン停止復旧処理手段４０２に処理要求を行う構成としてもよい。
（第２の実施例の動作）
（中信頼度ドメイン１５０Ｂによる処理要求）
図３５は、図２４に示した第１の実施例において、図３４に示した停止復旧手段４００を備える場合の動作の一例を説明するための図であり、中信頼度ドメイン１５０Ｂによる低信頼度ドメイン１５０Ｃの停止検知・復旧処理を示す。図３５において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
なお、中信頼度ドメイン１５０Ｂが、データ送信部３０２を介して、ドメイン停止復旧手段４００に低信頼度ドメイン１５０Ｃの復旧を要求する点において、図２４に示した第１の実施例と相違する。
まず、初期状態として、低信頼度ドメイン１５０Ｃが異常停止をしており、かつ、中信頼度ドメイン１５０Ｂが、ドメイン停止復旧手段４００を利用でき、もしくは、ドメイン停止復旧手段４００を利用する権限を有することとする。
ステップ１：中信頼度ドメイン１５０Ｂが、低信頼度ドメイン停止検知機能付データ送信部３０５のデータ送信手段３０５ａを介して、低信頼度ドメイン１５０Ｃへデータを送信する。
ステップ２：低信頼度ドメイン停止検知機能付データ送信部３０５の低信頼度ドメイン停止検知手段３０５ｂが、低信頼度ドメイン１５０Ｃの停止を検知する。
ステップ３：低信頼度ドメイン停止検知手段３０５ｂが低信頼度ドメイン１５０Ｃの停止を検知したことにより、ドメイン停止復旧手段４００を利用できる中信頼度ドメイン１５０Ｂが、データ送信部３０２を介して、ドメイン停止復旧手段４００に低信頼度ドメイン１５０Ｃの復旧を要求する。
ステップ４：ドメイン停止復旧手段４００が、中信頼度ドメイン１５０Ｂからの復旧要求に基づいて、低信頼度ドメイン１５０Ｃを復旧する。
なお、ステップ３とステップ４との間において、ドメイン停止復旧手段４００が、復旧を要求された上記低信頼度ドメイン１５０Ｃが実際に停止しているかを確認するために、低信頼度ドメイン停止検知機能付データ送信部３０４を用いて停止の有無を検知してもよい。
また、ステップ３とステップ４との間において、原則的に、ドメイン停止復旧手段４００が、復旧を要求された上記低信頼度ドメイン１５０Ｃが実際に停止しているか等の障害を確認するために、低信頼度ドメイン停止検知機能付データ送信部３０４を用いて停止等の有無を検知し、中信頼度ドメイン１５０Ｂから復旧要求がなされた場合には、信頼度の設定に基づき、上記停止等の障害の有無を検知しないこととしてもよい。
（低信頼度ドメイン１５０Ｃによる処理要求）
図３６は、図２４に示した第１の実施例において、図３４に示した停止復旧手段４００を備える場合の動作の一例を説明するための図であり、低信頼度ドメイン１５０Ｃによる中信頼度ドメイン１５０Ｂの停止検知・復旧処理を示す。図３６において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
なお、低信頼度ドメイン１５０Ｃが、データ送信部３０３を介して、ドメイン停止復旧手段４００に中信頼度ドメイン１５０Ｂの復旧を要求し、ドメイン停止復旧手段４００が、中信頼度ドメイン停止検知機能付データ送信部３０７を用いて、中信頼度ドメイン１５０Ｂへのデータ送信及び中信頼度ドメイン１５０Ｂの停止を検知する点において、図２４に示した第１の実施例と相違する。
まず、初期状態として、中信頼度ドメイン１５０Ｂが異常停止をしており、かつ、低信頼度ドメイン１５０Ｃが、ドメイン停止復旧手段４００を利用でき、もしくは、ドメイン停止復旧手段４００を利用する権限を有することとする。
ステップ１：低信頼度ドメイン１５０Ｃが、中信頼度ドメイン停止検知機能付データ送信部３０７のデータ送信手段３０７ａを介して、中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ２：中信頼度ドメイン停止検知機能付データ送信部３０７の中信頼度ドメイン停止検知手段３０７ｂが、中信頼度ドメイン１５０Ｂの停止を検知する。
ステップ３：中信頼度ドメイン停止検知手段３０７ｂが中信頼度ドメイン１５０Ｂの停止を検知したことにより、低信頼度ドメイン１５０Ｃが、データ送信部３０３を介して、ドメイン停止復旧手段４００に中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ４：復旧要求元ドメインである低信頼度ドメイン１５０Ｃが、復旧対象ドメインである中信頼度ドメイン１５０Ｂより信頼度が低く、さらに、低信頼度であることから、ドメイン停止復旧手段４００が、復旧要求の対象や内容の真偽を確認するため、中信頼度ドメイン停止検知機能付データ送信部３０６のデータ送信手段３０６ａを介して、中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ５：中信頼度ドメイン停止検知機能付データ送信部３０６の中信頼度ドメイン停止検知手段３０６ｂが、中信頼度ドメイン１５０Ｂの停止を検知することにより、ドメイン停止復旧手段４００は、実際に中信頼度ドメイン１５０Ｂが停止していることを確認する。
ステップ６：ドメイン停止復旧手段４００は、実際に中信頼度ドメイン１５０Ｂが停止していることを確認したことにより、低信頼度ドメイン１５０Ｃからの復旧要求に基づいて、中信頼度ドメイン１５０Ｂを復旧する。
（同一信頼度ドメインによる処理要求）
図３７は、図２４に示した第１の実施例において、図３４に示した停止復旧手段４００を備える場合の動作の一例を説明するための図であり、同一信頼度ドメイン内の停止検知・復旧処理の一例として、中信頼度ドメイン１５０Ｂによる他の中信頼度ドメイン１５０Ｂの停止検知・復旧処理を示す。図３７において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
なお、中信頼度ドメイン１５０Ｂが、データ送信部３０２を介して、ドメイン停止復旧手段４００に他の中信頼度ドメイン１５０Ｂの復旧を要求する点において、図２４に示した第１の実施例と相違する。
まず、初期状態として、１群の中信頼度ドメイン１５０Ｂ内の少なくとも一つの中信頼度ドメイン１５０Ｂが、ドメイン停止復旧手段４００を利用でき、もしくは、ドメイン停止復旧手段４００を利用する権限を有することとする。
ステップ１：停止していない他の中信頼度ドメイン１５０Ｂが、１群の中信頼度ドメイン１５０Ｂ内の上記中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ２：データ送信先の上記中信頼度ドメイン１５０Ｂの停止を検知する。
ステップ３：データ送信先の上記中信頼度ドメイン１５０Ｂの停止を検知したことにより、ドメイン停止復旧手段４００を利用できる当該データの送信元である中信頼度ドメイン１５０Ｂが、データ送信部３０２を介して、ドメイン停止復旧手段４００に上記停止状態の中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ４：ドメイン停止復旧手段４００が、当該データの送信元である中信頼度ドメイン１５０Ｂからの復旧要求に基づいて、上記停止状態の中信頼度ドメイン１５０Ｂを復旧する。
なお、ステップ３とステップ４との間において、ドメイン停止復旧手段４００が、復旧を要求された上記中信頼度ドメイン１５０Ｂが実際に停止しているかを確認するために、中信頼度ドメイン停止検知機能付データ送信部３０６を用いて停止の有無を検知してもよい。
（第２の実施例による効果）
このように、本発明の第２の実施例によれば、停止確認手段４０３が、各種ドメインから通知された情報に基づいて上記検知処理を行う。従って、最高信頼度ドメイン１５０Ａが、中信頼度ドメイン１５０Ｂや低信頼度ドメイン１５０Ｃから処理要求を通知されても、処理の対象となるドメインの実際の障害状況を検知し、処理の内容の真偽を確認する必要がないので、最高信頼度ドメイン１５０Ａの処理負担が軽減されるという効果を奏する。
（第３の実施例）
第３の実施例は、図２４にお示した第１の実施例に対応し、第１の実施例と同様の構成を採用するが、ドメイン停止復旧手段４００が、各種ドメインで発行された要求を受信する復旧処理制御手段４０４を有する点で相違する。
以下、上記の第１の実施例との相違点について主に説明する。
（第３の実施例の構成）
図３８は、第３の実施例によるドメイン停止復旧手段４００の構成を示す図である。
図３８に示すように、本実施例によるドメイン停止復旧手段４００は、復旧処理制御手段４０４を備える点で第１の実施例と相違する。
以下、上記の第１の実施例との相違点について主に説明する。
復旧処理制御手段４０４は、図４のアクセス制御手段３０と同様の構成及び機能を有し、復旧処理許可データ４０４ａを格納した記憶手段と、復旧処理許可手段４０４ｂとを備え、復旧要求受信手段４０１を介して最高信頼度ドメイン１５０Ａ以外のドメインから通知された処理要求に対する許否を判別する機能を有する。
また、復旧処理制御手段４０４は、処理要求が通知された場合、許可された処理要求だけをドメイン停止復旧手段４００に通知する。
ここで、復旧要求受信手段４０１は、各ドメインから受信した復旧要求（処理要求）について、最高信頼度ドメイン１５０Ａから受信した復旧要求（処理要求）をドメイン停止復旧処理手段４０２に通知し、最高信頼度ドメイン１５０Ａ以外のドメインから受信した復旧要求（処理要求）を復旧処理許可手段４０４ｂに通知する。
復旧処理制御手段４０４は、低レベルのセキュリティしか要求されないドメインである、最高信頼度ドメイン１５０Ａ以外のドメインに対して、予め許可されたドメインへの予め許可された形態による処理要求のみを許可する制御を行う。
復旧処理許可データ４０４ａは、最高信頼度ドメイン１５０Ａ以外のドメインから通知される処理要求と、所定のドメインに対する所定の処理内容を関連付けて、最高信頼度ドメイン１５０Ａが予め設定したデータであり、最高信頼度ドメイン１５０Ａから読み出し・書き込みが可能である。また、復旧処理許可手段４０４ｂからは読み出しのみが許可されている。さらに、最高信頼度ドメイン１５０Ａ以外のドメインからは読み出しも書き込みも不可とされる。すなわち、復旧処理許可データ４０４ａと最高信頼度ドメイン１５０Ａ以外のドメインの間にはデータバスが存在しない。
図３９に、復旧処理許可データ４０４ａの内容の一例を示す。
図３９に示すように、復旧処理許可データ４０４ａは、復旧を要求する側のドメインである要求元ドメインに対して、復旧処理の対象となる復旧先ドメインとその復旧方法とを規定する。
要求元ドメインがドメイン＃１の場合、復旧先ドメイン及び復旧方法は無いことが規定されている。
要求元ドメインがドメイン＃２の場合、復旧先ドメインはドメイン＃１のみ、復旧方法はＯＳリブートのみであることが規定されている。
要求元ドメインがドメイン＃３の場合、復旧先ドメインはドメイン＃２のみ、復旧方法はリセット及びロールバックであることが規定されている。
復旧処理許可手段４０４ｂは、復旧要求受信手段を介して最高信頼度ドメイン１５０Ａ以外のドメインからの処理要求を受け取ると、復旧処理許可データ４０４ａの要求元ドメイン、復旧先ドメイン及び復旧方法を参照して、当該処理要求が該当するか否かによって、当該処理要求の許否を判断し、許可された処理要求の場合、当該処理要求をドメイン停止復旧手段４００に発行する機能を有する。一方、不許可の場合、復旧処理許可手段４０４ｂは、ドメイン停止復旧手段４００に当該発行をしない。
すなわち、復旧条件は、第１の実施例で述べた、個々のドメインの信頼度に応じて、そのドメインからの復旧要求の許可または拒否に加えて、復旧先ドメインや復旧処理等の処理内容によって決定することができる。例えば、本実施例での復旧条件は、ドメイン＃１からの復旧要求を全て拒否するという第１の実施例での条件設定に加えて、ドメイン＃２及びドメイン＃３からの復旧要求に対しては、各々復旧先ドメインと処理内容によって部分的に復旧要求を許可する、と規定される。このように、より細い復旧条件の設定が可能となることを特徴とする。
（第３の実施例の動作）
図４０は、復旧処理制御手段４０４の動作の一例を説明するための図である。図４０において、矢線脇の番号は、ステップ番号を示している。
まず、初期設定として、最高信頼度ドメイン１５０Ａが、復旧処理許可データ４０４ａの内容を規定する。
ステップ１：最高信頼度ドメイン１５０Ａ以外のドメインが、復旧処理許可データ４０４ａと合致しない処理要求を発行したとする。
ステップ２：復旧処理許可手段４０４ｂは、当該処理要求を取得することによって、復旧処理許可データ４０４ａを読み出し、当該処理要求の許否を判断する。
ステップ３：復旧処理許可手段４０４ｂは、最高信頼度ドメイン１５０Ａ以外のドメインへエラーを返す。当該処理要求は、復旧処理許可データ４０４ａと合致しないためである。
ステップ４：最高信頼度ドメイン１５０Ａ以外のドメインは、上記処理要求とは別の処理要求を発行する。
ステップ５：復旧処理許可手段４０４ｂは、当該処理要求を取得することによって、復旧処理許可データ４０４ａを読み出し、当該処理要求の許否を判断する。
ステップ６：復旧処理許可手段４０４ｂは、最高信頼度ドメイン１５０Ａ以外のドメインの当該処理要求を許可した場合、ドメイン停止復旧処理手段４０２に当該処理要求を発行する。
なお、第３の実施例では、復旧処理制御手段４０４の構成として、復旧処理許可データ４０４ａと、復旧処理許可手段４０４ｂとを備え復旧処理許可データ４０４ａに基づき、処理要求の制御を行う例について説明したが、本発明にかかる構成のみに制限されるものでなく、復旧処理許可データに変えて（反転し）、復旧処理拒否データと、復旧処理拒否手段を備えても良い。この場合、復旧処理拒否手段は、最高信頼度ドメイン１５０Ａ以外のドメインからの処理要求が、復旧処理拒否データによって復旧処理の拒否が定義された所定の要求元ドメイン、復旧拒否先ドメイン、復旧方法の何れか又は全部等において、所定の条件に合致した場合に、当該処理要求を拒否する制御を行う。
（第３の実施例による効果）
このように、本発明の第３の実施例によれば、復旧処理制御手段４０４の復旧処理許可手段４０４ｂが、復旧処理許可データ４０４ａに基づいて、予め許可されたドメインへ予め許可された形態による処理要求のみを許可する制御を行うので、最高信頼度ドメイン１５０Ａ以外のドメインがダウンロード等により外部から取得した追加処理による、高レベルのセキュリティを必要とする最高信頼度ドメイン１５０Ａへの各種攻撃を防ぐことが出来る。
また、復旧処理制御手段４０４が、ドメイン停止復旧手段４００の復旧処理を分散化するので、復旧処理の高速化が図れる。
なお、第３の実施例の変形例として、復旧処理許可手段４０４ｂに、キャッシュを備えても良い。この場合、処理要求の許否の判断に用いた、復旧処理許可データ４０４ａは、キャッシュに格納され、次回以降の処理要求の許否の判断において、該当する処理要求の復旧処理許可データ４０４ａがキャッシュに存在するかを判定し、キャッシュヒットした場合、処理要求の許否の判断の高速化を実現する。
（第４の実施例）
第４の実施例は、図２４に示した第１の実施例に対応し、第１の実施例と同様の構成を採用するが、ドメイン停止復旧手段４００が、停止確認手段４０３及び復旧処理制御手段４０４を有する点で相違する。
以下、上記の第１の実施例との相違点について主に説明する。
図４１は、第４の実施例によるドメイン停止復旧手段４００の構成を示す図である。
図４１に示すように、第４の実施例によるドメイン停止復旧手段４００は、停止確認手段４０３及び復旧処理制御手段４０４を備える点で第１の実施例と相違する。
ここで、停止確認手段４０３は、第２の実施例における停止確認手段４０３と同様の構成であり、また、復旧処理制御手段４０４は、第３の実施例における復旧処理制御手段４０４と同様の構成であるため、説明を省略する。
（第４の実施例の動作）
第４の実施例によるドメイン停止復旧手段４００は、復旧処理制御手段４０４が、第３の実施例と同様に最高信頼度ドメイン１５０Ａ以外のドメインからの処理要求について許否を判断し、停止確認手段４０３が、復旧処理制御手段４０４で許諾された処理要求を取得し、第２の実施例と同様に、取得した処理要求にかかる処理の内容の真偽を確認し、正しいと確認した場合に、取得した処理要求の情報をドメイン停止復旧処理手段４０２に通知する。
（第４の実施例による効果）
このように、本発明の第４の実施例によれば、復旧処理制御手段４０４の復旧処理許可手段４０４ｂが、復旧処理許可データ４０４ａに基づいて、予め許可されたドメインへ予め許可された形態による処理要求のみを許可する制御を行うので、最高信頼度ドメイン１５０Ａ以外のドメインがダウンロード等により外部から取得した追加処理による、高レベルのセキュリティを必要とする最高信頼度ドメイン１５０Ａへの各種攻撃を防ぐことが出来るので最高信頼度ドメイン１５０Ａのセキュリティが向上する。
また、復旧処理制御手段４０４が、ドメイン停止復旧手段４００の復旧処理を分散化するので、復旧処理の高速化が図れる。
さらに、停止確認手段４０３が、復旧処理許可手段４０４ｂによって許可された処理要求にかかる情報に基づいて上記検知処理を行う。従って、最高信頼度ドメイン１５０Ａが、中信頼度ドメイン１５０Ｂや低信頼度ドメイン１５０Ｃから処理要求を通知されても、処理の対象となるドメインの実際の障害状況を検知し、処理の内容の真偽を確認する必要がないので、最高信頼度ドメイン１５０Ａの処理負担が軽減されるという効果を奏するとともに、最高信頼度ドメイン１５０Ａのセキュリティを確保しつつ、実際にドメインで生じている障害を的確に復旧することができるという効果を奏する。
以上好ましい複数の実施例をあげて本発明を説明したが、本発明は必ずしも、上記実施例に限定されるものでなく、その技術的思想の範囲内において様々に変形して実施することができる。
例えば、本実施例では、３つドメインにより構成される情報処理装置の例で説明したが、ドメイン数は３つに限られず、本実施例で説明したように、各ドメインが分離されていれば、２つでもよく、また、４つ以上でもよい。
また、例えば、本実施例では、復旧処理制御手段４０４がドメイン停止復旧手段４００に設けられた構成で説明したが、復旧処理制御手段４０４が設けられる位置は停止復旧手段４００内に限定されず、停止復旧手段４００外でもよいし、最高信頼度ドメイン１５０Ａ内でもよいし、複数の位置に設けられていてもよい。復旧処理制御手段４０４が最高信頼度ドメイン１５０Ａ内に設けられた場合、最高信頼度ドメイン１５０Ａが、最高信頼度ドメイン１５０Ａ以外のドメインからの処理要求について許否を判断し、許諾した処理要求の情報をドメイン停止復旧処理手段４０２に通知してもよい。
基本構成の第１例は、複数のＣＰＵを備えたマルチＣＰＵ構成の情報処理装置において、複数のＣＰＵを、実行するプログラム（処理）のセキュリティレベルに応じて、複数のドメイン（例えば基本ドメイン、信頼ドメイン、無信頼ドメイン等）に分ける。
基本ドメインは、ある一定のセキュリティレベル以上の処理を実行するドメインであり、信頼ドメインは、基本ドメインで実行する処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、無信頼ドメインは、信頼ドメインで実行する処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインとする。
または、基本ドメインの一定のセキュリティレベルの実行処理のそれぞれが、信頼ドメインの実行処理のセキュリティレベルと同じか、又は信頼ドメインの実行処理のセキュリティレベルより高く、そして基本ドメインの実行処理の集合として少なくとも１つセキュリティレベルの高い処理を含むドメインとしてもよい。
信頼ドメインは、信頼ドメインの一定のセキュリティレベルの実行処理のそれぞれが、無信頼ドメインの実行処理のセキュリティレベルと同じか、又は無信頼ドメインの実行処理のセキュリティレベルより高く、そして各ドメインの実行処理の集合として少なくとも１つセキュリティレベルの高い処理を含むドメインとしても良い。この場合には基本ドメインは信頼ドメインよりも相対的にセキュリティレベルの高い処理を行い、信頼ドメインは無信頼ドメインよりも相対的に高い処理が行われる。
各ドメインは、１つ又は複数のＣＰＵを含み、異なるドメイン間でのＣＰＵの通信を、プロセッサ間通信手段（例えば図１の４０）を介して行うとともに、追加処理等の低セキュリティの処理を実行するドメインに属するＣＰＵが、高セキュリティの処理を実行するドメインのメモリ及び入出力装置に対してアクセスする場合には、該アクセス要求は、アクセス制御手段（例えば図１の３０）によって、アクセスの許可／非許可が判別され、許可されたアクセスのみが行われる構成とされる。
かかる構成の第１例によれば、ダウンロードされた追加処理（デバイスドライバ、アプリケーションプログラムを含む）を、高セキュリティ・ドメインとはハードウェア的に別構成の低セキュリティ・ドメイン側のＣＰＵで実行することで、高セキュリティ・ドメインの安全性を確保している。
ここでいうダウンロードとは、携帯電話のキャリアが用意するデータ通信網や一般的な無線ＬＡＮ網だけではなく、ＳＤカードに代表される蓄積型メディア媒体、ＵＳＢに代表される有線通信・媒体といった接続を経由した情報装置へのダウンロードのことも含む。
そして、第１例によれば、高セキュリティ・ドメインと低セキュリティ・ドメインのＣＰＵを、スイッチ等で分離制御するのではなく、相互に通信可能とする、プロセッサ間通信手段を介して接続することで、安全性を保障しながら、高セキュリティ・ドメインと低セキュリティ・ドメインのＣＰＵ間の同期、協調動作も可能としている。
このプロセッサ間通信手段（図１の４０）は、一のドメインのＣＰＵから他のドメインのＣＰＵへデータ（コマンド）の受け渡しを行うものであり、他のドメインのＣＰＵへの直接的な攻撃等は行えない構成とされている。例えば低セキュリティ・ドメイン側のＣＰＵから高セキュリティ・ドメイン側のＣＰＵへデータを多量に送信し続けることで、高セキュリティ・ドメインのＣＰＵの性能劣化、バッファオーバーフロー等を生じさせようとしても、プロセッサ間通信手段で抑止され、該データは、高セキュリティ・ドメインのＣＰＵに伝達されない。
また、第１例において、アクセス制御手段（図１の３０）は、低セキュリティ・ドメイン側のＣＰＵに対して、予め許可されたメモリ空間、入出力デバイス等へ予め許可された形態によるアクセスのみを許可するアクセス制御を行う。これにより、ダウンロードされた追加処理からの高セキュリティ・ドメインへの攻撃を防ぐことが出来る。あるいは、アクセス制御手段が、必要に応じて、帯域、流量制御等を行うことで、ダウンロードされた追加処理からの高セキュリティ・ドメインへの各種攻撃を防ぐことが出来る。以下第１例に即して説明する。
図１は、第１例の構成を示す図である。図１を参照すると、基本処理２２及びＯＳ２１Ａからなるソフトウェア２０Ａを実行するＣＰＵ群１０Ａと、追加処理２３及び追加処理対応のＯＳ２１Ｂからなるソフトウェア２０Ｂを実行するＣＰＵ群１０Ｂと、ＣＰＵ群１０Ａ、１０Ｂ間で通信を行うプロセッサ間通信手段４０１、４０２と、ＣＰＵ群１０Ｂによるメモリ５０及び／又は入出力装置（Ｉ／Ｏ）６０へのアクセスを制御するアクセス制御手段３０と、を備えている。なお、図１には、ＣＰＵ群１０Ａ、ＣＰＵ群１０Ｂは、それぞれ複数（３台）のＣＰＵからなる構成として示されているが、各群とも１つのＣＰＵであっても良いことは勿論である。また、ＣＰＵ群１０Ａ、ＣＰＵ群１０Ｂにおいて、各群のＣＰＵの台数は等しくなくてもよいことは勿論である。以下では、ＣＰＵ群１０Ａ、ＣＰＵ群１０Ｂを、単にＣＰＵ１０Ａ、ＣＰＵ１０Ｂという。第１例において、ダウンロードされる追加処理２３は、バイナリ形式のネイティブコードよりなる。なお、ダウンロードされたソースプログラムを、コンパイル処理（アセンブル処理）してバイナリ形式としたものであってもよい。
第１例によれば、追加処理２３を実行するＣＰＵ１０Ｂを、基本処理２２を実行するＣＰＵ１０Ａと別に構え、ＣＰＵ１０Ａ、ＣＰＵ１０Ｂは、独立に動作可能であり、安全性を向上しながら、高速実行を可能とし、アプリケーションプログラム、デバイスドライバの実行を可能としている。なお、基本処理２２を実行するＣＰＵ１０Ａをマスターとし、追加処理２３を実行するＣＰＵ１０Ｂをスレーブとして構成し、スレーブ側はマスターの監督下で動作する構成としても良いことは勿論である。この場合、例えばＣＰＵ１０Ｂによる追加処理２３の実行は、ＣＰＵ１０Ａからプロセッサ間通信手段４０２を介してコマンドを受け取って行われる。
プロセッサ間通信手段４０１、４０２は、ＣＰＵ１０ＡとＣＰＵ１０Ｂ間でのデータの送受信を制御する。ＣＰＵ１０Ａ、１０Ｂは、独立に配設されていることから、それぞれの処理（プログラム）を並列に実行することが可能であるとともに、プロセッサ間通信手段４０１、４０２を介して、ＣＰＵ１０ＡとＣＰＵ１０Ｂ間における、同期処理、連携（強調）処理も可能としている。一例として、ユーザが表示装置の画面上から追加処理の実行を指示した場合、基本処理２２を実行するＣＰＵ１０Ａから、プロセッサ間通信手段４０１を解して、追加処理２３の起動要求が、ＣＰＵ１０Ｂに送信され、ＣＰＵ１０Ｂ上で追加処理２３が実行され、実行結果が、ＣＰＵ１０Ｂから、プロセッサ間通信手段４０２を介して、ＣＰＵ１０Ａに送信され、基本処理２２を構成する画面制御ルーチン等が、追加処理２３の実行結果を反映した情報をユーザに提示する、という具合である。
第１例では、ＣＰＵ１０Ｂで追加処理２３を実行する際、メモリ５０、入出力デバイス（Ｉ／Ｏ）６０へのアクセス要求が行われた場合、アクセス制御手段３０にて、当該アクセスに関する許諾の制御が行われ、許可されたアクセス要求のみが、メモリ５０、入出力デバイス（Ｉ／Ｏ）６０に対して実行される構成とされている。そして、ＣＰＵ１０Ｂにおいて、ＯＳ２１Ｂ上で追加処理２３を実行し、追加処理２３からの、基本処理２２あるいはＯＳ２１Ａへの処理要求が発行された場合、該要求は、プロセッサ間通信手段４０１を介して、ＣＰＵ１０Ａに通知される。すなわち、追加処理２３が、基本処理２２を、直接操作することは出来ない。例えば、悪意のある追加処理２３が、ＣＰＵ１０Ａに要求を頻発して発行して負荷を与え、ＣＰＵ１０Ａ側での基本処理の実行性能を著しく低下させようとしても、プロセッサ間通信手段４０１が、このような要求をＣＰＵ１０Ａ側に伝達しないように制御することで、上記攻撃からの防護が実現され、安全性が確保される。
なお、図１に示す例では、プロセッサ間通信手段４０１は、ＣＰＵ１０ＢからＣＰＵ１０Ａへの情報転送、プロセッサ間通信手段４０２は、ＣＰＵ１０ＡからＣＰＵ１０Ｂへの情報転送を制御している。あるいは、一台のプロセッサ間通信装置で双方向のデータの受け渡しを行うようにしても良いことは勿論である。第１例において、基本処理２２を実行する複数のＣＰＵ１０Ａ同士でＣＰＵ間の通信が必要な場合には、プロセッサ間通信手段４０を用いることなく、ＣＰＵ間の通信が行われる。また、追加処理２３を実行する複数のＣＰＵ１０Ｂについても同様である。ただし、後述するように、ＣＰＵ群１０Ｂを構成する複数のＣＰＵのいくつかをＣＰＵ群１０Ａの要素としてダイナミックに切り替える場合、ＣＰＵ群１０Ｂは、論理的にはＣＰＵ群１０Ａに属するが、ＣＰＵ間の通信は、プロセッサ間通信手段４０を介して行うようにしても良い。
第１例によれば、追加処理２３として、アプリケーションプログラム、デバイスドライバのダウンロード、インストール、実行が可能とされている。追加されたデバイスドライバは、ＯＳ２１Ｂに組み込まれ、ＣＰＵ１０Ｂ上で実行され、入出力デバイス６０へのアクセス制御は、アクセス制御手段３０の監視の下で実行される。
なお、携帯電話機、ＰＤＡ等の携帯型情報通信装置では、通常、図１における基本処理２２、ＯＳ２１Ａは、図示されない書き換え可能な不揮発性メモリ（ＥＥＰＲＯＭ：Ｅｌｅｃｔｒｉｃａｌｙ Ｐｒｏｇｒａｍｍａｂｌｅ ａｎｄ Ｅｒａｓａｂｌｅ ＲＯＭ）に格納され、ＣＰＵ１０Ａは、ＥＥＰＲＯＭから命令コードをフェッチしてデコードし実行する。すなわち、基本処理２２と追加処理２３を実行するそれぞれのＯＳ２１Ａ、２１Ｂが格納するメモリは、基本処理側と追加処理側で、ハードウェア的に分離されている。そして、基本処理、ＯＳ等の命令コードは、ＥＥＰＲＯＭに格納されたものが実行されるが、ＣＰＵ１０Ａ、１０Ｂで実行されるプログラムにより、初期化、参照、更新されるテーブル等のデータは、それぞれのＯＳ起動時に、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）よりなるメモリ５０に展開される。そして、ＣＰＵ１０Ｂについて、リード／ライトするメモリ領域をアクセス制御手段３０によって管理し、ＣＰＵ１０Ａで参照されるメモリ領域へのアクセスを制限している。携帯型情報通信端末とは別の一般の情報処理装置においても、同様にして、基本処理２２、ＯＳ２１ＡがロードされＣＰＵ１０Ａが命令コードをフェッチするメモリと、追加処理２３、ＯＳ２１ＢがロードされＣＰＵ１０Ｂが命令コードをフェッチするメモリとを別々に備えていても良いことは勿論である。あるいは、一般の情報処理装置において、メモリ５０に、基本処理２２、ＯＳ２１Ａがロードされる領域と、追加処理２３、ＯＳ２１Ｂがロードされる領域を分離して設け、ＣＰＵ１０Ｂのメモリ５０へのリード／ライトアクセスをアクセス制御手段３０によって管理するようにしても良い。この場合、ＣＰＵ１０Ａ、ＣＰＵ１０Ｂが参照のみするコードについては、共通のメモリ領域に格納し、アクセス制御手段３０によって、共通のメモリ領域を、該ＣＰＵ１０Ｂがリードのみ可とするようにアクセス制御しても良い。
また、携帯型情報処理装置において、搭載する電池残量が少なくなってきた場合には、基本処理を実行するＣＰＵ以外を強制的にシャットダウンする、実行する処理の信頼度に応じてより信頼度の低い処理を実行するＣＰＵを優先的にシャットダウンすることで電池残量の節約を行うことが可能である。これは例えば、電池残量を検出する手段と、検出結果を通知する手段によって得られる電池残量に関する情報に基づき、基本処理を行うＣＰＵ上で判断を行い、シャットダウンを実行する、といった処理により実現できる。
さらに、携帯型情報処理装置での資源、例えば外部との通信バンド幅や不揮発メモリ量等はより一層制限されているため、信頼度に応じて資源を確保する相対的な割合を変更することも可能である。これは、例えば、基本処理を行うＣＰＵにおいて、実行する処理の信頼度が高い場合には優先的に資源の確保を許容する、信頼度が低い場合には資源の制限をかける等の判断をすることにより実現される。
図２は、第１例におけるプロセッサ間通信手段のハードウェア構成の一例を示す図である。図２を参照すると、左右両側のＣＰＵ（基本処理を実行するＣＰＵと追加処理を実行するＣＰＵ）間に配設された、割り込み制御装置４１と共有メモリ４２の１セットで、図１のプロセッサ間通信手段４０１、４０２の全体を構成している。割り込み制御装置４１としては、ＣＰＵ＃０、ＣＰＵ＃１、・・・ＣＰＵ＃ｎ用のｎ個の割り込み制御装置４１０〜４１ｎを備え、各割り込み制御装置は、割り込み指示部４１１と、割り込み状態保持部４１２と、割り込み取り消し部４１３とを備えている。また、共有メモリ４２は、ＣＰＵ＃０、ＣＰＵ＃１、・・・ＣＰＵ＃ｎ用のｎ個の通信領域４２０〜４２ｎを備え、各通信領域は、送信情報（データ、メッセージ）をキューイング又はバッファリングする通信キュー４２１と、相互排他制御を行う排他制御領域４２２とを備えている。
例えばＣＰＵ＃０とＣＰＵ＃１の２つの領域を想定すると、ＣＰＵ＃１用の割り込み制御装置４１１と、ＣＰＵ＃１用の通信領域４２１とが、ＣＰＵ＃０からＣＰＵ＃１へプロセッサ間通信手段４０１を構成し、ＣＰＵ＃０用の割り込み制御装置４１０とＣＰＵ＃０用の通信領域４２０とが、ＣＰＵ＃１からＣＰＵ＃０へのプロセッサ間通信手段４０２を構成している。
割り込み制御装置４１と、共有メモリ４２は、ＣＰＵ＃０、ＣＰＵ＃１、・・・ＣＰＵ＃ｎと、バス接続する構成とされる。また、共有メモリ４２の通信キュー４２１には、送信データそのものでなく、送信データを格納するバッファポインタ（たとえばメモリ５０条でのバッファ領域アドレス）を設定するようにしても良い。
第１例では、共有メモリ４２におけるＣＰＵ＃ｉの排他制御領域４２２ｉは、ＣＰＵ＃ｉの通信領域４２ｉを、あるＣＰＵが既に占有している場合、他のＣＰＵがＣＰＵ＃ｉの通信領域４２ｉを使用することが無いようにする相互排他制御のために、設けられている。すなわち、ＣＰＵ＃ｉの排他制御領域４２２ｉは、ｍｕｔｅｘ等のセマフォ、フラグ等の同期管理情報の格納に用いられる。
共有メモリ４２に実装された相互排他制御機構により、送信ＣＰＵと受信ＣＰＵ間におけるデータの整合性（ｃｏｎｓｉｓｔｅｎｃｙ）が保証される。
また、相互排他制御機構により、送信側ＣＰＵは、排他制御領域４２２がロック状態のときは、送信ＣＰＵに対する割り込み要求をあげることが出来ず、これにより、送信ＣＰＵから受信ＣＰＵへの頻繁なデータ送信等、不当な割り込み発生を防ぐことが出来る。
なお、排他制御領域４２２としては、キューへの繋ぎ（エンキュー）、キューからの取り外し（デキュー）のロック管理として用いても良い。
図２において、割り込み制御装置４１を介してひとつの受信ＣＰＵへの多重割り込みを許可する構成とした場合、共有メモリ４２において、各ＣＰＵの通信領域における通信キュー４２１、排他制御領域４２２は、多重数分設けられることになる。
特に制限されないが、共有メモリ４２は、図１のメモリ５０の所定のメモリ領域を共有メモリとして用いても良いし、メモリ５０とは別に、プロセッサ間通信手段４０内に設ける構成としても良い。また、図示されないが、割り込み制御装置４１０〜４１ｎからの割り込み要求（Ｉｎｔｅｒｒｕｐｔ Ｒｅｑｕｅｓｔ）線は、パラレルに受信ＣＰＵに接続する構成としてもよいし（割り込み本数が増える）、あるいは、デイジーチェーン方式で接続する構成としても良い。
受信ＣＰＵは、割り込み制御装置４１からの割り込み要求を受理すると、これを割り込み制御装置４１に通知し、割り込み制御装置４１は、図示されないデータ線に割り込み装置番号（割り込みベクター情報）を転送し、受信ＣＰＵは、割り込み装置番号から割り込みベクターを生成し、スケジューラを介して、受信ＣＰＵで実行される割り込みサービスルーチンが起動され、割り込みサービスルーチンが、対応する共有メモリ４２の通信キューからデータを取得し、排他制御領域のｍｕｔｅｘ等のセマフォをリリース（アンロック）し、割り込みから復帰（Ｒｅｔｕｒｎ Ｆｒｏｍ Ｉｎｔｅｒｒｕｐｔ）するという一連の制御が行われる。
図３は、図２示した第１例のプロセッサ間通信手段の動作手順を説明するための図であり、ＣＰＵ＃ｋからＣＰＵ＃０へデータを転送する場合の手順が示されている。図３において、矢線脇の数字は、ステップ番号を表している。
ステップ１：送信ＣＰＵ＃ｋは、共有メモリ４２のＣＰＵ＃０の通信領域の排他制御領域をロックする。なお、共有メモリ４２のＣＰＵ＃０の通信領域の排他制御領域が他のＣＰＵによりロックされていることを示している場合、例えば該ロックが解除されるまで待機する。
ステップ２：送信ＣＰＵ＃ｋは、共有メモリ４２のＣＰＵ＃０の通信領域の排他制御領域をロックした後、共有メモリ４２のＣＰＵ＃０用通信領域の通信キューに、受信ＣＰＵ＃０に送信するデータを書きこむ。
ステップ３：送信ＣＰＵ＃ｋは、割り込み制御領域４１のＣＰＵ＃０用割り込み制御装置の割り込み指示部に、割り込み要求を通知する。
ステップ４：ＣＰＵ＃０用割り込み制御装置の割り込み指示部は、ＣＰＵ＃０用割り込み制御装置の割り込み状態保持部を更新し、「割り込み要求有り」に設定する。
ステップ５：ＣＰＵ＃０用割り込み制御装置の割り込み指示部は、受信ＣＰＵ＃０へ割り込みを行う。
ステップ６：受信ＣＰＵ＃０は、ＣＰＵ＃０用割り込み制御装置の割り込み指示部からの割り込みを受理し、共有メモリ４２のＣＰＵ＃０用通信領域の通信キューから、データを取り出す。このとき、受信ＣＰＵ＃０では、上記した割り込みサービスルーチンによる処理が行われる。
ステップ７：受信ＣＰＵ＃０は、共有メモリ４２のＣＰＵ＃０用通信領域の通信キューから、データを取得した後、ＣＰＵ＃０用割り込み取り消し部に、割り込み処理完了を通知する。
ステップ８：受信ＣＰＵ＃０からの取り込み処理完了通知を受けたＣＰＵ＃０用割り込み制御装置の割り込み指示部は、ＣＰＵ＃０用割り込み制御装置の割り込み状態保持部を
更新する。
ステップ９：受信ＣＰＵ＃０は、共有メモリ４２のＣＰＵ＃０の通信領域の排他制御領域をアンロックする。
第１例において、特定の受信ＣＰＵへの割り込み要求の集中を確認した場合、受診ＣＰＵへの割り込み要求を制御する等の流量制御、帯域制御を行うようにしても良い。すなわち、割り込み制御装置４１内に、送信ＣＰＵ側から受信ＣＰＵに対して、連続・多発して割り込み要求を上げることがないように制限するＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）保証機能を備えても良い。例えば、受信ＣＰＵへのデータの引渡しを伴わない割り込み要求は、排他制御の対象とされず、複数連続して発行することが出来る。そこで、受信ＣＰＵ側で割り込み処理が完了しない状態において、送信ＣＰＵ側からの割り込み要求が発生し、割り込み制御装置４１の割り込み状態保持部の「割り込み要求有り」が所定以上となった場合に、以降の送信ＣＰＵ側から割り込み要求を不許可とする制御が行うようにしてもよい。かかる構成により、例えば送信ＣＰＵが、受信ＣＰＵへのデータの引渡しを伴わない割り込み要求を多量に発生することで、受信ＣＰＵの性能を低下させるといった類の攻撃を抑えることが出来る。
図４は、図１に示した第１例のアクセス制御手段３０の構成を示す図である。図４を参照すると、このアクセス制御手段は３０は、基本側バス７０Ａを介して、基本処理（図１の２２）を実行するＣＰＵ１０Ａに接続詞、追加側バス７０Ｂを介して追加処理（図１の２３）を実行するＣＰＵ１０Ｂに接続するアクセス許可手段３１と、アクセス許可データ３２を格納した記憶手段を備えている。
アクセス許可データ３２は、ＣＰＵ１０Ａから読み出し・書き込みが可能とされる。アクセス許可手段３１からは読み出しのみが許可されている。そして、アクセス許可データ３２は、ＣＰＵ１０Ｂからは読み出しも書き込みも不可とされる。すなわち、アクセス許可データ３２とＣＰＵ１０Ｂの間にはデータバスが存在しない。
アクセス許可手段３１は、追加側バス７０Ｂのアドレス信号線、制御信号線に転送される、メモリ５０（図１参照）へのアクセスアドレス信号、及び制御信号（アクセスコマンド）から、アクセスの種別（リード／ライト）を判別し、アクセス許可データ３２の情報を参照して、当該アクセスが適正であるか否かを判別する。判別の結果、アクセスが不当と判断された場合、アクセス許可手段３１は、基本側バス７０Ａへのアクセスアドレス、制御信号（アクセスコマンド）の送出を行わず、これにより、ＣＰＵ１０Ｂ側から、基本側バス７０Ａへのアクセスは行われない。この場合、追加側バス７０Ｂにアクセスアドレスを送出したＣＰＵ１０Ｂ側では、バスエラー、あるいは、リード／ライトアドレスに対するメモリ５０等からの不応答により、該アクセスが失敗したことを知る。
アクセス許可手段３１は、入出力デバイス（Ｉ／Ｏ）６０がメモリマップドＩ／Ｏである場合には、追加側バス７０Ｂを監視し、アクセスアドレスが入出力デバイス対応のアドレスであることを検出し、データバス上に、Ｉ／Ｏコマンド（リード／ライト等）を検出した場合、該アクセスが適正であるかをアクセス許可データ３２の情報を参照して決定する。入出力デバイスがメモリマップドＩ／Ｏでない場合も、追加側バス７０Ｂに転送される入出力デバイスのデバイス番号、Ｉ／Ｏコマンドをデコードし、アクセス許可データ３２の情報を参照して、アクセスの可否を決定する。
なお、第１例において、アクセス制御手段３０は、単位時間あたりのデータ転送量の制御を行う帯域制約手段を備えてもよい。一例として、アクセス制御手段３０は、ＣＰＵ１０Ｂがアクセス動作中に、ＣＰＵ１０Ｂから追加側バス７０Ｂに転送されるデータ量を測定監視する手段を備え、例えば、単位時間あたり予め定められた閾値を超えるバイト数のデータが転送される場合、ＣＰＵ１０ＢからＣＰＵ１０Ａへのデータ転送を打ち切る制御を行うようにしてもよい。その際、ＣＰＵ１０Ｂが、ＣＰＵ１０Ａへのデータ転送がフェイルしたことを知ってリトライした場合にも、アクセス制御手段３０は、ＣＰＵ１０ＢからのデータをＣＰＵ１０Ａに転送することは行わない。あるいは、アクセス制御手段３０は、バッファを備え、ＣＰＵ１０Ｂから追加側バス７０Ｂに転送されるデータをバッファに蓄積し、ＣＰＵ１０Ａに転送されるデータの流量を制御する構成としてもよい。
図５は、第１例におけるアクセス許可データ３２の一例を示す図である。図５を参照すると、アクセス許可データは、追加処理を実行するＣＰＵ（図４の追加側バスに接続するＣＰＵ）と、アクセスが許可される範囲の始点アドレスと終点アドレスからなる許可範囲アドレスと、許可するアクセス種別（リード、リード／ライト、ライトの種別）がテーブル形式で格納されている。なお、許可範囲アドレスは、異なるＣＰＵで重複しても良い。図５に示す例では、２行目のＣＰＵ＃２、＃３の許可範囲アドレスは、０ｘＣ００００００から０ｘＦ００００００で、読み出し／書き込み可（Ｒ／Ｗ）あり、３行目のＣＰＵ＃３の許可範囲アドレスは、０ｘＥ００００００から０ｘＦ００００００であり、２行目と重複している。アドレス許可データの数、したがってテーブルのエントリ数は、その数が多いほど、きめ細かく、アクセス制御を行うことが出来る。なお、図５では、説明のため、Ｒ（読み出し可）、Ｗ（書き込み可）、Ｒ／Ｗ（読み出し／書き込み可）を例示したが、Ｒ（読み出し可）は、読み出しのみ可とし書き込みを不可とする情報であり、Ｗを書き込みを可（読み出しも可）とした場合には、Ｒ／Ｗは、不要とされる。また、読み出しが不可（書き込みも不可）のアドレス範囲は、アドレス許可データ３２には格納されない。図５に示す例では、アクセス許可データとして、アクセスが許可されたＣＰＵのそれぞれについて、アドレス範囲と、アクセス種別を有するが、アクセス許可データに、アクセス種別として、アクセス不可の情報をさらに設け、追加処理を実行するＣＰＵについて、アクセス不可のアドレス範囲を格納するようにしても良い。
図４のアクセス許可手段３１は、追加側のＣＰＵからのアクセス要求（アドレス、読み書きコマンド）を受け取り、アクセス許可データ３２の許可範囲アドレス、アクセス種別を参照して、許可されたアクセスの場合、該アクセスを許可する。一方、不許可の場合、アクセスを不許可とする。図５に示す例では、ＣＰＵ＃４の場合、始点アドレス１０００から終点アドレス２０００（ヘキサデシマル）とされ、アクセス種別は読み出し（Ｒ）とされる。ＣＰＵ＃２、＃３の場合、始点アドレス０ｘＣ００００００から終点アドレス０ｘＦ００００００（ヘキサデシマル）とされ、アクセス種別は読み出しと書き込み（Ｒ／Ｗ）とされる。ＣＰＵ＃３の場合、始点アドレス０ｘＥ００００００から終点アドレス０ｘＦ００００００（ヘキサデシマル）のアクセス種別は書き込み（Ｗ）とされる。
図６は、図４のアクセス制御手段３０の動作の一例を説明するための図である。図６において、矢線脇の番号は、ステップ番号を示している。
ステップ１：基本処理を実行するＣＰＵ１０Ａは、アクセス制御手段３０のアクセス許可データ３２に、全ての追加処理を実行するＣＰＵ１０Ｂが、あるアドレス範囲を読み出すことを禁止する。
ステップ２：ＣＰＵ１０Ｂが、追加処理２３の実行等により、読み出しが禁止されたアドレス範囲への読み出し要求を発行したとする。
ステップ３：アクセス許可手段３１は、アクセス許可データ３２を読み出し、該アクセス要求の適否をチェックする。
ステップ４：アクセス許可手段３１は、ＣＰＵ１０Ｂへエラーを返す。該アドレス範囲は、ＣＰＵ１０Ｂからの読み出しが禁止されているためである。
ステップ５：ＣＰＵ１０Ｂは、上記アドレス範囲とは別の範囲への読み出し要求を発行する。
ステップ６：アクセス許可手段３１は、アクセス許可データ３２を読み出してチェックする。
ステップ７：アクセス許可手段３１は、ＣＰＵ１０Ｂの読み出しのアクセス要求を許可し、基本側バス７０Ａに読み出し要求として発行する。
なお、第１例では、アクセス制御手段３０の構成として、アクセス許可手段３１と、アクセス許可データ３２を備え、アクセス許可情報に基づき、アクセス制御を行う例について説明したが、第１例にかかる構成のみに制限されるものでなく、アクセス許可のデータに変えて（反転し）、アクセス拒否データと、アクセス拒否手段を備えても良い。この場合、アクセス拒否手段は、追加処理を実行するＣＰＵ１０Ｂからのアクセスアドレスが、アクセス拒否データに、アクセス拒否が定義されたアドレス範囲に合致した場合に、アクセスを拒否する制御を行う。
第１例の変形例として、アクセス許可手段３１に、キャッシュを備えても良い。この場合、アクセス判定に用いたアクセスアドレス、アクセス許可データは、キャッシュに格納され、次回以降のアクセス制御の判定において、該当するアクセスアドレス（アドレス範囲）のアクセス許可データがキャッシュに存在するかを判定し、キャッシュヒットした場合、アクセス判定の高速化を実現している。キャッシュには、アクセスアドレスの範囲に対応するタグアドレス、アクセス許可データを備え、追加側バス７０Ｂのアクセスアドレスがキャッシュとヒットするか否か判定するキャッシュヒット判定回路を備えて構成される。
さらに、第１例の変形例として、アクセス制御手段３０が、新アクセス許可データ３３と、アクセス許可データ更新手段３４を備える構成としてもよい。図７を参照すると、アクセス制御手段３０は、図６に示した第１例に加えて、基本側バス７０Ａに接続するアクセス許可データ更新手段３４と新アクセス許可データ３３を格納した記憶手段を備えている。この２つの手段の機能について詳細を説明する。
新アクセス許可データ３３は、図６のアクセス許可データ３２と同じ特徴を持つのに加え、アクセス許可データ更新手段３４からのみの読み出しを許可する記憶手段である。
アクセス許可データ更新手段３４は、基本側バス７０Ａを通じたＣＰＵ１０Ａからの要求によって、新アクセス許可データ３３の内容をアトミックに新アクセス許可データ３４に上書きする。
なお、第１例の変形例において、アクセス許可データ３２の更新ではなく、新アクセス許可データ３３への切替を行う手段を設けてもよい。
このような構成によれば、アクセス許可データ３２の更新をＣＰＵによりアトミックに書き換えることが可能となるため、アクセス制御手段３０による保護すべき領域、制限すべき領域を動的に変更することが可能である。
また、図８は、第１例のアクセス制御手段３０の別構成を示す図である。図８を参照すると、このアクセス制御手段３０は、図６に示した第１例に加えて、追加側バス７０Ｂに接続するアクセス監視手段３５と学習手段３６を備えている。この手段の機能について詳細を説明する。
アクセス監視手段３５は、アクセス許可手段３１と同様に追加側バス７０Ｂを通じたＣＰＵ１０Ｂからのアクセス情報を取得する。
学習手段３６は、前記アクセス監視手段３５から提供されるアクセス情報に基づき、その参照が適切かどうかを判断する。例えば、ユーザ保護データに対する参照回数をカウントしておき、もしあらかじめ指定された閾値を越えた場合には、異常事態と認定し、アクセス監視手段３５にそのことを通知し、別途定められたルールに従ってアクセス許可データ３２を動的に変更する。また、場合によっては、基本側バス７０ＡにつながるＣＰＵ１０Ａに通知をし、異常時の処理を起動してもよい。
このような構成によれば、実際に参照されたパターンから信頼度が低いと思われるＣＰＵの動作を履歴情報として蓄積することで自律的に制限できるため、実動作におけるＣＰＵの動作状況に基づいたより安全な実行制御を行うことが可能となる。
また、アクセス制御手段３０の構成例としては、図６の構成に加えて、上記説明した新アクセス許可データ３３、アクセス許可データ更新手段３４、アクセス監視手段３５、学習手段３６のすべてを備える構成とすることも可能である。
図９は、基本構成の第２例の構成を示す図である。図９を参照すると、第２例は、図１の構成に加えて、追加処理側のソフトウェアとＯＳ、ＣＰＵをさらに１組追加したものである。すなわち、第２の追加処理側のＣＰＵ１０Ｃは、プロセッサ間通信手段を介して、第１の追加処理用のＣＰＵ１０Ｂと相互に通信する。また、第２の追加処理側のＣＰＵ１０Ｃは、第２のアクセス制御手段３０２を介して、基本側バス７０Ａに接続される。
各アクセス制御手段３０１、３０２の設定は、基本処理２２を実行するＣＰＵ１０Ａが設定する。すなわち、基本処理２２を実行するＣＰＵ１０Ａが、マスタープロセッサとして機能する。ＣＰＵ１０Ａにより、メモリ５０及び入出力デバイス（Ｉ／Ｏ）６０の集中的な管理が行われる。
第２の追加処理２３Ｃを実行するＣＰＵ１０Ｃは、第１の追加処理２３Ｂを実行するＣＰＵ１０Ｂに対してプロセッサ間通信手段４０３を介して通信（データ、コマンドの送信）を行い、第１の追加処理２３Ｂを実行するＣＰＵ１０Ｂは、基本処理２２を実行するＣＰＵ１０Ａに対してプロセッサ間通信手段４０１を介して通信（データ、コマンドの送信）を行う。また、第２の追加処理２３Ｃを実行するＣＰＵ１０Ｃは、第２のアクセス制御手段３０２の監視の下、メモリ５０、入出力デバイス（Ｉ／Ｏ）６０に対して許可されたアクセスのみを行い、第１の追加処理２３Ｂを実行するＣＰＵ１０Ｂは、第１のアクセス制御手段３０１の監視の下、メモリ５０、入出力デバイス（Ｉ／Ｏ）６０に対して許可されたアクセスのみを行い、第１のアクセス制御手段３０１、第２のアクセス制御手段３０２のアクセス許可データの設定は、すべてＣＰＵ１０Ａによって行われる。かかる構成により、集中的な管理が行われ、また、プロセッサ間通信手段４０により、ＣＰＵ間で処理の受け渡しが行われる。第２例においても、基本処理２２を実行するＣＰＵ１０Ａに対する、追加処理２３Ｂ、２３Ｃからの直接的な攻撃等は回避される。すなわち、前記第１例と同様に、追加処理２３Ｂ、２３Ｃは、基本処理２２を直接起動あるいはサブルーチン呼出しすることは出来ず、基本処理２２の起動要求は、例えばＣＰＵ１０ＣからＣＰＵ１０Ｂを介して、ＣＰＵ１０Ａに、プロセッサ間通信手段を介して伝達され、該要求を受け取ったＣＰＵ１０Ａでは、権限が付与されていないＣＰＵからの要求である場合、該要求を受理しない（この詳細については、後述するソフトウェアの実施例で詳述する）。このように、追加処理側のＣＰＵと基本処理側のＣＰＵに権限の階層が設けられるほか、プロセッサ間通信手段４０、及びアクセス制御手段３０というハードウェア機構を介することで、基本処理等の直接的な攻撃は、回避される。第２例におけるプロセッサ間通信手段４０１〜４０４は、図２に示した前記第１例の構成と同様とされ、アクセス制御手段３０１、３０２も、図４に示した前記第１例の構成と同様とされるため、その詳細構成、動作の説明は省略する。
図１０は、基本構成の第３例の構成を示す図である。図１０を参照すると、第３例は、図９に示した構成と同様に、図１の構成にさらに、追加処理側のＣＰＵ１０Ｃと、アクセス制御手段３０２を追加したものである。第３例は、図９に示した前記第２例と相違して、メモリと入出力デバイス（Ｉ／Ｏ）を、各組（ドメイン）のＣＰＵ群毎に用意している。
第２の追加処理ＣＰＵ１０Ｃは、許可されたメモリ５０Ｃ、入出力デバイス（Ｉ／Ｏ）６０Ｃには、アクセス制限なく自在にアクセスすることが出来る。第１の追加処理ＣＰＵ１０Ｂには、許可されたメモリ５０Ｂ、入出力デバイス（Ｉ／Ｏ）６０Ｂには、アクセス制限なくアクセスすることが出来る。
第２の追加処理側のＣＰＵ１０Ｃからの、基本処理側のメモリ５０Ａ、入出力デバイス（Ｉ／Ｏ）６０Ａへのアクセスは、第２のアクセス制御手段３０２及び第１のアクセス制御手段３０１の２段構成にて、アクセス制御が行われる。
第１の追加処理側のＣＰＵ１０Ｂからの、基本処理側のメモリ５０Ａ、入出力デバイス（Ｉ／Ｏ）６０へのアクセスは、第１のアクセス制御手段３０１により、アクセス許可が判定される。
第１のアクセス制御手段３０１のアクセス許可データ、第２のアクセス制御手段３０２のアクセス許可データは、基本処理のＣＰＵ１０Ａが設定する。第２のアクセス制御手段３０２のアクセス許可データは第１の追加処理のＣＰＵ１０Ｂが設定しても良い。第３例によれば、メモリ、入出力デバイス（Ｉ／Ｏ）をドメイン単位に分離し、ＣＰＵ間をプロセッサ間通信手段４０で多段に接続する構成としたことにより、追加処理による攻撃からの防護機能を高め、安全性を確保している。
図１１は、第３例の変形例を示す図であり、図１に示した第１例を２以上のチップにおいて適用した例である。図１１を参照すると、ＣＰＵ１０Ａ、１０Ｂ、１０Ｃ、１０Ｄとアクセス制御手段３０１の組み合わせからなるチップ８０を複数並べることに加えて、さらに個々のチップ８０間をアクセス制御手段３０３で結合する。すなわち、チップ８０Ａ、チップ８０Ｂ等を複数並べ、チップ８０Ａとチップ８０Ｂ間等をアクセス制御手段３０３で結合する。
ある一チップ８０内における一部のＣＰＵを基本処理実行用として設けることで、一チップ８０内のアクセス制御手段３０１によりアクセス制限を行うこともできるし、各チップ８０内の少なくとも一部のＣＰＵを基本処理実行用として設けることも可能である。
また、異なるチップ８０にまたがってドメインを構成し、各チップ８０間のアクセス制御手段３０３により実行を制御することも可能である。
いずれの場合でも、適切なアクセス制御手段３０の設定によって、複数のチップ８０間においても本発明を適用する情報処理装置の基本構成における実行制御を行うことが可能となる。
上記第３例では、主に、本発明のハードウェア構成について説明したが、本発明のソフトウェア構成について以下に説明する。
図１２は、本発明を実施するソフトウェア構成の一例を示す図であり、基本ドメインと、Ｔｒｕｓｔｅｄ（信頼）拡張ドメイン、Ｕｎｔｒｕｓｔｅｄ（無信頼）拡張ドメインを備えている。図１２のハードウェア構成としては、３つの群のＣＰＵを備えた、図１０の構成等を用いることが出来る。この場合、基本処理を実行する実行環境である基本ドメインは、図１０のソフト２０、ＯＳ２１Ａに対応し、Ｔｒｕｓｔｅｄ拡張ドメインは、図１０のソフト２０Ｂ、ＯＳ２１Ｂに対応し、Ｕｎｔｒｕｓｔｅｄ拡張ドメインは、図１０のソフト２０Ｃ、ＯＳ２１Ｃに対応させることが出来る。
図１２を参照すると、基本ドメイン１００Ａは、基本アプリケーションプログラム（「基本アプリケーション」という）１１１と、基本性能１１２を含む基本ソフト１１０と、ＯＳ１０１Ａと、専用ファイルシステム１０３と、外部デバイス１０２Ａを備え、ネイティブコードダウンロード管理機能１０４Ａと、セキュリティポリシデータベース１０５を備えている。特に制限されないが、基本機能１１２は、例えば、第３例の情報処理装置が携帯型情報通信端末である場合、発呼、着信処理等の呼処理、インターネットアクセス、画面処理等の、携帯型情報通信端末の基本性能を実現するもので、図１の基本処理２２に対応している。基本アプリケーション１１１は、基本機能１１２を呼び出して処理を行い、基本機能１１２は、ＯＳを介してファイルシステム、外部デバイスへのアクセスを行う。外部デバイスは、ワイヤレス通信インタフェース等の通信インタフェース、表示装置のインタフェース、キー、ポインティングデバイス等の入力インタフェース、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）メモリーカードインターフェース、サウンドインタフェース等を含む。
Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂは、ネイティブコードダウンロード実行機能１０４Ｂと、ダウンロードアプリケーションプログラム（「ダウンロードアプリケーション」という）１２０Ｂと、基本性能ライブラリ（ラッパー）１１３と、ＯＳ１０１Ｂと、許可された外部デバイス１０２Ｂを備えている。
ＯＳ１０１Ｂは、証明書付のダウンロードドライバ１２１Ｂを含む。証明書付のダウンロードドライバ１２１Ｂは、許可された外部デバイス１０２Ｂの入出力制御を行う。
Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃは、ネイティブコードダウンロード実行機能１０４Ｃと、ダウンロードアプリケーション１２０Ｃと、ＯＳ１０１Ｃと、許可された外部デバイス１０２Ｃを備えている。ＯＳ１０１Ｃに組み込まれるダウンロードドライバ１２１Ｃは、許可された外部デバイス１０２Ｃの入出力制御を行う。
基本ドメイン１００Ａの外部デバイス１０２Ａから入力され、ダウンロードされたファイルについて、ネイティブコードダウンロード管理機能１０４Ａが、セキュリティポリシデータベース１０５の内容を参照することで、信頼できる（信頼できる電子証明書付）ネイティブコードのアプリケーションを、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂに転送し、信頼できる（信頼できる電子証明書付）ネイティブコードのダウンロードドライバ１２１ＢのＯＳ１０１Ｂへの組み込みを行う。
また、ネイティブコードダウンロード管理機能１０４Ａは、信頼できない（例えば電子証明書無しであるか、証明書の内容が正しくない場合等）アプリケーションを、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ経由で、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃへ転送し、信頼できない（証明書無し）ダウンロードドライバのＵｎｔｒｕｓｔｅｄ拡張ドメインのＯＳ１０１Ｃへの組み込みを行う。
Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂからは、基本機能１１２の呼出しは許可されるが、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃからの基本機能１１２の呼び出しは、許可されない。ただし、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００ＣとＴｒｕｓｔｅｄ拡張ドメイン１００Ｂとの協働作業は可能である。
信頼できるドメインで動作するアプリケーションプログラムは、信頼できないドメインからのデータについて、ユーザの確認（ＯＫ）があった場合にのみ、基本機能１１２へ引き渡す。ユーザの確認無く、信頼できないドメインからのデータを、基本機能１１２に渡さない。なお、信頼できる拡張ドメイン１００Ｂから、直接、基本ドメイン１００Ａの基本機能１１２へ、処理要求を発行することは出来ない。
図１３は、図１２に示した第３例の動作を説明するための図であり、基本アプリケーションの実行を示す図である。図１３において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：基本ドメイン１００Ａの基本アプリケーション１１１は、基本機能１１２に、処理要求（例えば、アドレス帳の追加等）を発行する。
ステップ２：基本機能１１２は、ＯＳ１０１Ａを利用して、該当要求を処理する。
ステップ３：基本機能１１２は、基本アプリケーション１１１に要求の成否を通知する。
図１４は、図１２に示した第３例の動作を説明するための図であり、信頼アプリケーションのダウンロードの実行の様子を示す図である。図１４において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：基本ドメイン１００Ａ上の外部デバイス１０２Ａ（ネットワーク又はＳＤメモリカード等）からＯＳ１０１Ａにダウンロードデータが到着する。
ステップ２：ダウンロードデータは、基本機能１１２にて、属性情報等の情報から、追加アプリケーション（ダウンロードアプリケーション）と認識される。
ステップ３：基本機能１１２は、追加アプリケーションを、ネイティブコードダウンロード管理機能１０４Ａに渡し、ネイティブコードダウンロード管理機能１０４Ａは、セキュリティポリシデータベース１０５を参照して、追加アプリケーションに付随した電子証明書をチェックする。前述したように、例えば電子証明書には、公開鍵やデジタル署名（証明される機関や公開鍵などを秘密鍵で暗号化したもの）が格納され、ネイティブコードダウンロード管理機能１０４Ａが、証明書の認証を行う場合には、デジタル署名の部分を、公開鍵で解読して、証明書のデータの内容と一致するか否かを確認し、一致する場合に、証明書のデータを信頼してもよいと判断する。さらに、アプリケーションのダイジェストからなるデジタル署名を付随しておくことで、ダウンロードしたアプリケーションが改竄されていないかどうかチェックすることが出来る。
ステップ４：ネイティブコードダウンロード管理機能１０４Ａは、電子証明書とともに、ダウンロード情報を、セキュリティポリシデータベース１０５に保存する。
ステップ５：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、電子証明書のチェックの結果、正しい場合、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂに、ダウンロードアプリケーションを送信し、実行を要求する。基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａから、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂのデータの送信は、図９又は図１０のプロセッサ間通信手段４０を用いて行われる。
ステップ６：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂは、受け取ったダウンロードアプリケーションを実行するように制御する。
ステップ７：ダウンロードアプリケーションはＴｒｕｓｔｅｄ拡張ドメイン上で実行される。
図１５は、図１２に示した第３例の動作を説明するための図であり、信頼ドライバのダウンロード実行を示す図である。信頼ドライバとは、例えばダウンロードされたドライバに添付される電子証明書の照合結果が正しいドライバを言う。図１５において、各矢線に付された番号は、当該線を情報が転送される図轍鮒番号を表している。
ステップ１：基本ドメイン１００Ａ上の外部デバイス１０２Ａ（ネットワーク又はＳＤカード等）からＯＳ１０１Ａにダウンロードデータが到着する。
ステップ２：基本機能１１２にて、属性情報、自動インストール情報等から、ダウンロードデータは、追加デバイスドライバ（ダウンロードドライバ）であると認識する。
ステップ３：基本機能１１２は、受信したドライバを、ネイティブコードダウンロード管理機能１０４Ａに渡す。ネイティブコードダウンロード管理機能１０４Ａは、セキュリティポリシデータベース１０５を参照して、ダウンロードデータに付随した電子証明書をチェックする。
ステップ４：ネイティブコードダウンロード管理機能１０４Ａは、電子証明書とともに、ダウンロード情報をセキュリティポリシデータベース１０５に保存する。
ステップ５：ネイティブコードダウンロード管理機能１０４Ａは、Ｔｒｕｓｔｅｄ拡張ドメインのネイティブコードダウンロード実行機能１０４Ｂに対して、ダウンロードドライバを送信し、インストールの実行を要求する。基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａから、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂのデータの送信は、図９又は図１０のプロセッサ間通信手段４０を用いて行われる。
ステップ６：Ｔｒｕｓｔｅｄ拡張ドメインのネイティブコードダウンロード実行機能１０４Ｂは、受け取ったダウンロードドライバを自動インストールする。特に制限されないが、第３例において、ダウンロードドライバはインストールした後ＣＰＵを再起動してＯＳ１０１Ｂのある領域に組み込むレジデント型のドライバであっても良い。
ステップ７：Ｔｒｕｓｔｅｄ拡張ドメインのＯＳ１０１Ｂは、ダウンロードドライバをインストールされたことを、既に実行済みのアプリケーションに通知するか、表示する。
ステップ８：Ｔｒｕｓｔｅｄ拡張ドメインにおいて、既に実行済みのアプリケーション１０２Ｂは、インストールされたダウンロードドライバ１２１Ｂを参照する。
ステップ９：Ｔｒｕｓｔｅｄ拡張ドメインのＯＳ１０１Ｂにインストールされ、ロードされたダウンロードドライバ１２１Ｂは、許可された外部デバイス１０２Ｂをアクセスする。
ステップ１０：ダウンロードドライバ１２１Ｂは、ダウンロードアプリケーション１２１０Ｂに外部デバイス１０２Ｂからのデータを返す。
図１６は、図１２に示した第３例の動作を説明するための図であり、Ｔｒｕｓｔｅｄ拡張ドメインの信頼アプリケーション（ダウンロードアプリケーション）が、基本ドメインの基本機能を利用する場合の動作を示す図である。図１６において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂにおいて、ダウンロードアプリケーション１２０Ｂが、基本機能ライブラリ１１３へ、基本ドメイン１００Ａの基本機能１１２の処理を要求する。基本機能ライブラリ１１３は、基本ドメイン１００Ａの基本機能１１２の処理を実行するためのルーチンを集めたライブラリであり、ダウンロードアプリケーション１２０Ｂから起動される。
ステップ２：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３は、ダウンロードアプリケーション１２０Ｂが保有する電子証明書の鍵（公開鍵等）を用いて、要求を暗号化し、暗号化した要求を、基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａへ送信する。Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３から基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａへの要求の送信は、図９又は図１０のプロセッサ間通信手段４０を介して行われる。
ステップ３：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、受け取った要求を復号し、該要求を、電子証明書を利用して、要求送信元が適正であるか否か等のチェックを行う。なお、この例では、要求の暗号化と復号を用いて、要求をチェックしているが、アプリケーションと電子証明書の対応がとれる方法であれば、任意の方法を用いてよいことは勿論である。
ステップ４：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、要求のチェックの結果、ＯＫであれば、基本機能１１２へ要求を依頼する。
ステップ５：基本ドメイン１００Ａの基本機能１１２は、ネイティブコードダウンロード管理機能１０４Ａから受け渡された該要求を処理し、処理終了後、基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａへ、処理完了を通知する。
ステップ６：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３へ、処理の完了を通知する。基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４ＡからＴｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３への通知の送信は、図９又は図１０のプロセッサ間通信手段を介して行われる。
ステップ７：Ｔｒｕｓｔｅｄ拡張ドメイン基本機能ライブラリ１１３は、ダウンロードアプリケーション１２０Ｂに、要求に対する応答として処理の完了を通知する。
図１７は、図１２に示した第３例の動作を説明するための図であり、Ｕｎｔｒｕｓｔｅｄ拡張ドメインの無信頼アプリケーションのダウンロードの実行手順を示す図である。図１７において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：基本ドメイン１００Ａ上の外部デバイス１０２Ａ（ネットワーク又はＳＤカード等）から、ＯＳ１０１Ａにダウンロードデータが到着する。
ステップ２：基本ドメイン１００Ａの基本機能１１２では、属性情報等を解析し、ダウンロードデータをアプリケーション（ダウンロードアプリケーション）を認識する。
ステップ３：基本ドメイン１００Ａの基本機能１１２は、ダウンロードアプリケーションを、ネイティブコードダウンロード管理機能１０４Ａに渡す。ネイティブコードダウンロード管理機能１０４Ａでは、アプリケーションに、電子証明書が付随されていないか、あるいは電子証明書が正しくないと判別する。
ステップ４：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、セキュリティポリシデータベース１０５に、ダウンロード情報を保存する。
ステップ５：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、Ｔｒｕｓｔｅｄ拡張ドメインのネイティブコードダウンロード実行機能１０４Ｂに、ダウンロードされたアプリケーションを送信する。基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４ＡからＴｒｕｓｔｅｄ拡張ドメインのネイティブコードダウンロード実行機能１０４Ｂへのアプリケーションの送信は、図９又は図１０に示したプロセッサ間通信手段４０を介して行われる。
ステップ６：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂは、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃのネイティブコードダウンロード実行機能１０４Ｃにアプリケーションを送信し、実行を要求する。Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４ＢからＵｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃのネイティブコードダウンロード実行機能１０４Ｃへのアプリケーションの送信は、図９又は図１０に示したプロセッサ間通信手段４０を介して行われる。
ステップ７：Ｕｎｔｒｕｓｔｅｄ拡張ドメインのネイティブコードダウンロード実行機能１０４Ｃは、受信したダウンロードアプリケーション１２０Ｃの起動を行う。
ステップ８：ダウンロードアプリケーション１２０Ｃは、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃで動作を開始する。この場合、Ｕｎｔｒｕｓｔｅｄ拡張ドメインのダウンロードアプリケーション１２０Ｃは、Ｕｎｔｒｕｓｔｅｄ拡張ドメインのＯＳ１０１Ｃ上で動作し、許可された外部デバイス１０２Ｃへのアクセスのみが許可される。
図１８は、図１２に示した第３例の動作を説明するための図であり、無信頼ドライバのダウンロード実行の様子を示す図である。図１８において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：基本ドメイン１００Ａ上の外部デバイス１０２Ａ（ネットワーク又はＳＤカード等）から、ＯＳ１０１Ａにダウンロードデータが到着する。
ステップ２：基本機能１１２は、ダウンロードデータの到着で起動され、属性情報、インストール情報等のダウンロードデータを解析し、デバイスドライバ（ダウンロードドライバ）と認識する。
ステップ３：基本機能１１２は、ダウンロードドライバを、ネイティブコードダウンロード管理機能１０４Ａに渡し、ネイティブコードダウンロード管理機能１０４Ａは、ダウンロードドライバに電子証明書が添付されていないか、あるいは、電子証明書は添付されているが、電子証明書の内容が正しくないことが分かる。
ステップ４：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、ダウンロード情報のみをセキュリティポリシデータベース１０５に保存する。
ステップ５：ネイティブコードダウンロード管理機能１０４Ａは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂにダウンロードドライバを送信する。ネイティブコードダウンロード管理機能１０４ＡからＴｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂへのダウンロードドライバの送信は、図９又は図１０に示したプロセッサ間通信手段４０を介して行われる。
ステップ６：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４Ｂは、受け取ったダウンロードドライバを、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃのネイティブコードダウンロード実行機能１０４Ｃに転送する。Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのネイティブコードダウンロード実行機能１０４ＢからＵｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃのネイティブコードダウンロード実行機能１０４Ｃへのダウンロードドライバの転送は、図９又は図１０に示したプロセッサ間通信手段４０を介して行われる。
ステップ７：Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃのネイティブコードダウンロード実行機能１０４Ｃは、受信したダウンロードドライバ１２１Ｃをインストールする。
ステップ８：ＯＳ１０１Ｃは、ドライバ１２１Ｃがインストールされたことを、既に実行済みのアプリケーション１２０Ｃへ通知するか、画面に表示する（ユーザに通知する）。
ステップ９：Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃにおいて、既に実行済みのアプリケーション１２０Ｃは、インストールされたダウンロードドライバ１２１Ｃを参照する。
ステップ１０：Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃにおいて、インストールされたダウンロードドライバ１２１Ｃは、Ｕｎｔｒｕｓｔｅｄ拡張ドメインのＯＳ１０１Ｃを介して、許可された外部デバイス１０２Ｃをアクセスする。
ステップ１１：Ｕｎｔｒｕｓｔｅｄ拡張ドメインにおいて、ダウンロードドライバ１２１Ｃは、ダウンロードアプリケーション１２０Ｃに、外部デバイス１０２Ｃから取得したデータを返す。
図１９は、図１２に示した第３例の動作を説明するための図であり、信頼アプリケーションと無信頼アプリケーションの連携の様子を示す図である。図１９において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃ上のダウンロードアプリケーション１２０Ｃは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上のダウンロードアプリケーション１２０Ｂへデータを送信する。このデータの送信は、通常、図９又は図１０のプロセッサ間通信手段４０によって行われる。
ステップ２：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上のダウンロードアプリケーション１２０Ｂ」は、受け取ったデータによる処理を行い、基本機能ライブラリ１１３へ、Ｕｎｔｒｕｓｔｅｄ拡張ドメインと連携した情報を含む基本機能処理を要求する。
ステップ３：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上の基本機能ライブラリ１１３は、アプリケーションが保有する電子証明書を用いて、要求を暗号化し、基本ドメイン１００Ａ上のネイティブコードダウンロード管理機能１０４Ａへ送信する。この要求の送信は、通常、図９又は図１０のプロセッサ間通信手段４０によって行われる。
ステップ４：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、要求を復号し、該要求の安全性を、セキュリティポリシデータベース１０５に格納された電子証明書を利用してチェックする。チェックの結果、要求が正しい場合、ネイティブコードダウンロード管理機能１０４Ａは、基本アプリケーション１１１を介して、ユーザに確認を求める。基本アプリケーション１１１は、画面表示、入力のアプリケーションを含む。なお、この例では、要求の暗号化と復号を用いて、アプリケーションと電子証明書の対応をチェックしているが、アプリケーションと電子証明書との対応が取れる方法であれば、任意の方法を用いても良いことは勿論である。
ステップ５：ユーザからの確認として「ＮＯ」が入力されるとする。
ステップ６：ネイティブコードダウンロード管理機能１０４Ａは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３へ不許可を通知する。この不許可の通知は、通常、図９又は図１０のプロセッサ間通信手段４０によって行われる。
ステップ７：基本機能ライブラリ１１３は、ダウンロードアプリケーション１２０Ｂへ不許可を通知する。
ステップ８：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上のダウンロードアプリケーション１２０Ｂは、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃ上のダウンロードアプリケーション１２０Ｃに不許可を通知する。この不許可の通知は、通常、図９又は図１０のプロセッサ間通信手段４０によって行われる。
図２０は、図１２に示した第３例の動作を説明するための図であり、信頼アプリケーションと無信頼アプリケーションの連携を示す図である。図２０において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
ステップ１：Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃ上のダウンロードアプリケーション１２０Ｃは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上のダウンロードアプリケーション１２０Ｂへデータを送信する。このデータの送信は、図９又は図１０等のプロセッサ間通信手段４０によって行われる。
ステップ２：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上のダウンロードアプリケーション１２０Ｂは、受け取ったデータによる処理を行い、基本機能ライブラリ１１３へ、Ｕｎｔｒｕｓｔｅｄと連携した情報を含む基本機能処理を要求する。
ステップ３：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３は、アプリケーション１２０Ｂｇａ保有する電子証明書を用いて、要求を暗号化し、基本ドメイン１００Ａ上のネイティブコードダウンロード管理機能１０４Ａへ送信する。この要求は、通常、図９又は図１０のプロセッサ間通信手段４０によって行われる。
ステップ４：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、要求を復号し、該要求の安全性を、セキュリティポリシデータベース１０５に格納される電子証明書を利用してチェックする。チェックの結果、要求が正しい場合、ネイティブコードダウンロード管理機能１０４Ａは、基本アプリケーション１１１を介してユーザに確認を求める。なお、この例では、要求の暗号化と復号を用いて、アプリケーションと電子証明書の対応をチェックしているが、アプリケーションと電子証明書との対応が取れる方法であれば、任意の方法を用いても良いことは勿論である。
ステップ５：この場合、ユーザの確認として「ＹＥＳ」が入力される。
ステップ６：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、基本機能１１２へ要求を依頼する。
ステップ７：基本機能１１２は、要求を処理し、ネイティブコードダウンロード管理機能１０４Ａに処理完了を通知する。
ステップ８：基本ドメイン１００Ａのネイティブコードダウンロード管理機能１０４Ａは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３に完了を通知する。この完了通知は、図９又は図１０のプロセッサ間通信手段４０によって行われる。
ステップ９：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂの基本機能ライブラリ１１３は、ダウンロードアプリケーション１２０Ｂに完了を通知する。
ステップ１０：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂのダウンロードアプリケーション１２０Ｂは、Ｕｎｔｒｕｓｔｅｄ拡張ドメイン１００Ｃのダウンロードアプリケーション１２０Ｃに完了を通知する。この完了通知は、図９又は図１０のプロセッサ間通信手段４０によって行われる。
図２１は、基本構成の第４例の構成を示す図である。ＯＳとＣＰＵ間に仮想マシンモニタ（ＯＳとの間に設けられ、ＣＰＵで実行されるソフトウェア層）を備えている。これにより、ＣＰＵ、Ｉ／Ｏ、メモリ資源を仮想化している。仮想マシンモニタは、ＯＳとＣＰＵ間で、仮想ハードウェア（例えば仮想入出力デバイス）を、実際のハードウェアデバイスにマッピングする。基本ドメイン、Ｔｒｕｓｔｅｄ拡張ドメイン、Ｕｎｔｒｕｓｔｅｄ拡張ドメインのそれぞれについて、ＯＳは、仮想の専用ファイルシステム、仮想外部デバイスとの入出力（Ｉ／Ｏ）制御を行い、ＯＳとＣＰＵ間に、仮想ＣＰＵ２００Ａ、２００Ｂ、２００Ｃ、仮想マシンモニタ２１０Ａ、２１０Ｂ、２１０Ｃを備え、仮想の専用ファイルシステム１０３’、仮想外部デバイス１０２Ａ’、１０２Ｂ’、１０２Ｃ’を、対応する実ファイルシステム、実外部デバイスへマッピングする。
第４例によれば、図１０のハードウェア構成、図１２のソフトウェア構成と相違して、第４例において、例えば基本ドメインに対応する仮想ＣＰＵは固定でなく、Ｔｒｕｓｔｅｄ拡張ドメイン等のＣＰＵを、基本ドメインの仮想ＣＰＵとしてマッピングすることができる。なお、仮想マシンモニタは、その実装において、既存のＯＳ、アプリケーションプログラム、ＣＰＵ等の修正等は不要とされる。第４例によれば、各ドメインのＣＰＵの個数は可変とされ、仮想ＣＰＵを構成する。ソフトウェア構成としては、基本ドメイン、Ｔｒｕｓｔｅｄ拡張ドメイン、Ｕｎｔｒｕｓｔｅｄ拡張ドメインの構成は、デバイス、ファイルシステムが仮想デバイス、仮想ファイルシステムであることを除いて、図１２に示した構成と同様である。
図２２は、図２１に示した第４例の処理手順の一例を示す図である。図２２において、各矢線に付された番号は、ステップ番号を表している。
ステップ１：基本ドメイン１００Ａの仮想マシンモニタ２１０Ａは、Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上の仮想マシンモニタ２１０Ｂに対してＣＰＵの委譲を要求する。
ステップ２：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上の仮想マシンモニタ２１０Ｂは、仮想ＣＰＵ資源を減らす。
ステップ３：Ｔｒｕｓｔｅｄ拡張ドメイン１００Ｂ上の仮想マシンモニタ２１０Ｂは、基本ドメイン１００Ａ上のＣＰＵ上の仮想マシンモニタ２１０Ａに委譲可能なＣＰＵを通知する。
ステップ４：基本ドメイン１００Ａ上の仮想マシンモニタ２１０Ａは、アクセス制御手段等の設定を行い、仮想ＣＰＵの数を増やす。
第４例によれば、別の群のＣＰＵを、基本ドメインのＣＰＵのように動作させることが出来る。なお、アプリケーションのダウンロード処理は、前記した第３例の処理動作（図１３乃至図２０）と同一であるため、その説明は省略する。
第４例の変形例として、仮想マシンモニタを、セキュアモードで動作させるようにしても良い。このようにすることで、安全性をさらに向上させることが出来る。
上記ソフトウェアの各例において、各ドメインのＣＰＵ群がマルチプロセッサとして動作する場合、キャッシュコヒーレンスを保つためのバス、仮想マルチプロセッサの無効化のために、ＴＬＢ（Ｔｒａｎｓｌａｔｉｏｎ Ｌｏｏｋａｓｉｄｅ Ｂｕｆｆｅｒ：アドレス管理ユニット内に設けられるアドレス変換表）の全エントリをフラッシュするシュートダウン等、ハードウェアで協調動作するチャネルについては、すべて、基本ドメイン１００Ａから、制御できるように構成されている。また、図２３に示すように、各ドメインのＣＰＵ群（例えば図１のマルチＣＰＵ構成のＣＰＵ群１０Ａ、１０Ｂ）を、分離手段１５を介して、複数に分業できる構成としても良い。これにより、例えばあるドメインのＣＰＵを他のドメインに委譲する際の制御が容易化し、さらに障害マルチプロセッサの分離（ｇｒａｃｅｆｕｌ ｄｅｇｒａｄｉｎｇ）等にも対応可能としている。
なお、前記第１例〜第４例では、ネットワーク等装置外部からネイティブコードの追加処理（アプリケーション、デバイスドライバ）をダウンロードして実行する情報通信端末装置を例に説明したが、本発明は、かかる情報通信端末装置に限定されるものでなく、任意の情報処理装置に適用可能である。
（第１の実施例）
上記において基本構成として示した情報処理装置のいずれかに対して本発明を適用した第１の実施例について説明する。基本構成で示したのと同様の構成及び動作については適宜説明を省略する。
（第１の実施例の構成）
図２４に示すように、本発明の第１の実施例による情報処理装置は、マルチプロセッサにより構成されており、最高信頼度ドメイン１５０Ａ、中信頼度ドメイン１５０Ｂ、低信頼度ドメイン１５０Ｃと、データ送信部３０１，３０２，３０３と、低信頼度ドメイン用データ送信部３０４，３０５と、中信頼度ドメイン用データ送信部３０６，３０７と、ドメイン停止復旧手段４００とを備え、ドメインからの復旧等の要求を通知されると、通知された要求に対応する処理を実行する機能を有し、または、その要求が正当な場合に、通知された要求に対応する処理を実行する機能を有する。
なお、本発明の第１の実施例による情報処理装置は、マルチプロセッサ上で各ドメインが有するシングルプロセッサ向けＯＳと既存のアプリケーションをそれらに改造を加えることなく動作させ、その既存のアプリケーションに対してマルチプロセッサによる並列処理を実現できるようにしたシングルプロセッサ向けＯＳによる並列処理システムにかかるものでもよい。
この場合には、シングルプロセッサ上でアプリケーションを動作させるよりも高速処理が可能となり、また、マルチプロセッサがそれぞれ独立したＯＳを備える並列処理システムよりも簡易な構成により並列処理が実現できる。
最高信頼度ドメイン１５０Ａは、前述の第２例の図９や第３例の図１０におけるソフトウェア２０ＡとＣＰＵ１０Ａとからなる構成や、第４例の図２１における基本ドメイン１００Ａと仮想ＣＰＵ２００Ａと仮想マシンモニタ２１０Ａとからなる構成に対応し、また、基本ドメイン１００Ａと同様に、基本アプリケーションや基本ソフトを有する。これら基本アプリケーションや基本ソフトとして、例えば、メーラー、ブラウザ、ｉモード（登録商標）や、アドレス帳の機能等を備えるものが挙げられる。
また、最高信頼度ドメイン１５０Ａは、自身が備えるＣＰＵ、ＯＳによって、中信頼度ドメイン１５０Ｂ及び低信頼度ドメイン１５０Ｃと、ドメインで発行された処理要求に関するデータや制御に関するデータ等を通信する機能を有する。
なお、最高信頼度ドメイン１５０Ａは、ある一定のセキュリティレベル以上の処理を実行するドメインであり、他のドメインと分離して設けられており、また、例えば、外部からダウンロードされたネイティブコードの実行は行わず、さらに、最も高い信頼度であることから、他の全てのドメインについて、停止状態等の障害を復旧することが可能である。
また、最高信頼度ドメイン１５０Ａは、最高信頼度ドメイン１５０Ａ以外への通信経路専用の低信頼度ドメイン用データ送信部３０４及び中信頼度ドメイン用データ送信部３０６と、最高信頼度ドメイン１５０Ａ以外のドメインからの通信経路専用のデータ送信部３０２，３０３とに接続しており、各ドメインへの通信経路がそれぞれ別に設けられていることから、最高信頼度ドメイン１５０Ａのみに各種データの書き込みが許可される。
中信頼度ドメイン１５０Ｂは、前述の第２例の図９や第３例の図１０におけるソフトウェア２０ＢとＣＰＵ１０Ｂとからなる構成や、第４例の図２１におけるＴｒｕｓｔｅｄ（信頼）拡張ドメイン１００Ｂと仮想ＣＰＵ２００Ｂと仮想マシンモニタ２１０Ｂとからなる構成に対応する。
また、中信頼度ドメイン１５０Ｂは、自身が備えるＣＰＵ、ＯＳによって、最高信頼度ドメイン１５０Ａ及び低信頼度ドメイン１５０Ｃと、ドメインで発行された処理要求に関するデータや制御に関するデータ等を通信する機能を有する。
なお、中信頼度ドメイン１５０Ｂは、最高信頼ドメイン１５０Ａで実行する処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、他のドメインと分離して設けられており、また、例えば、ダウンロードされたネイティブコードのうち、信頼できると保障されたコードのみを実行する。
低信頼度ドメイン１５０Ｃは、前述の第２例の図９や第３例の図１０におけるソフトウェア２０ＣとＣＰＵ１０Ｃとからなる構成や、第４例の図２１におけるＵｎｔｒｕｓｔｅｄ（無信頼）拡張ドメイン１００Ｃと仮想ＣＰＵ２００Ｃと仮想マシンモニタ２１０Ｃとからなる構成に対応する。
また、低信頼度ドメイン１５０Ｃは、自身が備えるＣＰＵ、ＯＳによって、最高信頼度ドメイン１５０Ａ及び中信頼度ドメイン１５０Ｂと、ドメインで発行された処理要求に関するデータや制御に関するデータ等を通信する機能を有する。
なお、低信頼度ドメイン１５０Ｃは、中信頼度ドメイン１５０Ｂで実行する処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、他のドメインと分離して設けられており、また、例えば、ダウンロードされたネイティブコードのうち、信頼できると保障されたコード以外のコードを実行する。
また、最高信頼度ドメイン１５０Ａ、中信頼度ドメイン１５０Ｂ、低信頼度ドメイン１５０Ｃは、以下のように形成してもよい。
最高信頼ドメイン１５０Ａは、最高信頼ドメイン１５０Ａのセキュリティレベルの実行処理のそれぞれが、中信頼度ドメイン１５０Ｂの実行処理のセキュリティレベルと同じか又は高く、そして基本ドメインの実行処理の集合として少なくとも１つセキュリティレベルの高い処理を含むドメインとし、中信頼ドメイン１５０Ｂは、中信頼度ドメイン１５０Ｂのセキュリティレベルの実行処理のそれぞれが、低信頼度ドメイン１５０Ｃの実行処理のセキュリティレベルと同じか又は高く、そして各ドメインの実行処理の集合として少なくとも１つセキュリティレベルの高い処理を含むドメインとし、低信頼度ドメイン１５０Ｃは、低信頼度ドメイン１５０Ｃのセキュリティレベルの実行処理のそれぞれが、中信頼度ドメイン１５０Ｂの実行処理のセキュリティレベルと同じか又は低く、そして各ドメインの実行処理の集合として少なくとも１つセキュリティレベルの低い処理を含むドメインとする。
この場合には、最高信頼度ドメイン１５０Ａは、中信頼度ドメイン１５０Ｂよりも相対的にセキュリティレベルの高い処理を行い、中信頼ドメイン１５０Ｂは、低信頼度ドメイン１５０Ｃよりも相対的に高い処理を行う。
本発明の第１の実施例における信頼度とは、処理ごとに付与されたセキュリティの度合いを示す電子証明書に基づき、あるセキュリティポリシーに従ってセキュリティレベルの段階ごとに設定されるものをいう。例えば、デジタル署名が付与された処理ごとに、あるセキュリティポリシーに基づきセキュリティレベルが設定される。
図２５は、機能重要度設定テーブル７００を示す図であり、本発明の第１の実施例において設定される信頼度の一例を示す。
図２５に示すように、信頼度は、例えば、階層的に、レベルＡ：パスワードが必要、レベルＢ：２度確認しない、レベルＣ：実行ごとに確認、レベルＤ：アクセスごとに確認、のように各レベルの重要度に応じたセキュリティレベルで設定される。
これを利用して、実行する機能に応じてドメインに信頼度を付与する。すなわち、ドメインによる障害の復旧要求の内容の重要度に応じて信頼度を設定する。
これにより、例えば、低信頼度ドメイン１５０Ｃからの復旧要求を一律には拒否せずに、軽微な障害についての復旧要求の場合にはこれを許諾するなど、柔軟な復旧処理が可能となる。
最高信頼度ドメイン１５０ＡにはレベルＡ、中信頼度ドメイン１５０ＢにはレベルＢ、低信頼度ドメイン１５０ＣにはレベルＣを配置するというように、一ドメインには同種のセキュリティレベルのみを配置してもよいが、柔軟な復旧処理を可能にする信頼度の設定として、例えば、図２５のように、最高信頼度ドメイン１５０Ａには実行する機能の重要度によってレベルＡ以上、レベルＢ以上、中信頼度ドメイン１５０Ｂにも実行する機能によってレベルＢ以上、レベルＣ以上、低信頼度ドメイン１５０Ｃにも実行する機能によってレベルＣ以上、レベルＤ以上という配置としても良い。
このように設定された信頼度は、例えば、最高信頼度ドメイン１５０Ａによって管理されていてもよく、この場合には、最高信頼度ドメイン１５０Ａの判断により、実行する機能や処理について信頼度に応じた優先順位を定めることができる。
このような設定が可能であればどんな証明書やどんなセキュリティポリシーに基づいて設定してもよく、実行する機能やドメイン数に応じて任意に設定することが可能である。
データ送信部３０１，３０２，３０３は、ドメインで発行された処理要求に関するデータや制御に関するデータ等を送信する機能を有し、構成例として例えば、共有メモリとプロセッサ間割込み、ＦＩＦＯやキュー、デュアルポートメモリーや、他にＬＡＮ等のネットワーク、有線通信や無線通信等からなる構成が挙げられ、データを送信する機能を有する従来の一般的な技術でよく、データ送信が可能であれば構成は特に制限されない。
データ送信部３０１，３０２，３０３で送信されるデータは、処理要求を発行した要求元ドメインを識別する情報、処理の対象となるドメインを識別する情報、処理の内容を識別する情報等を含み、また、場合により、処理の対象となるドメインの実際の障害状況に関する情報を含む。
なお、データ送信部３０１，３０２，３０３は、送信先ドメイン内の上位層へのエラー通知又はエラー処理を行う機構（不図示）を備える。送信先ドメインが復旧処理中のデータ送信においては、このような機構によりデータ送信完了までの無駄な待ちを排除する必要があるからである。
また、後述のデータ送信手段３０４ａ、３０５ａ、３０６ａ、３０７ａも同様である。
データ送信部３０１は、最高信頼度ドメイン１５０Ａで発行された、中信頼度ドメイン１５０Ｂや低信頼度ドメイン１５０Ｃの復旧等を要求する処理要求等を、ドメイン停止復旧手段４００に通知する機能を有する。
データ送信部３０２は、中信頼度ドメイン１５０Ｂで発行された、中信頼度ドメイン１５０Ｂや低信頼度ドメイン１５０Ｃの復旧等を要求する処理要求等を、最高信頼度ドメイン１５０Ａに通知する機能を有する。
データ送信部３０３は、低信頼度ドメイン１５０Ｃで発行された、中信頼度ドメイン１５０Ｂや低信頼度ドメイン１５０Ｃの復旧等を要求する処理要求等を、最高信頼度ドメイン１５０Ａに通知する機能を有する。
低信頼度ドメイン用データ送信部３０４，３０５は、それぞれデータ送信手段３０４ａ，３０５ａと、低信頼度ドメイン停止検知手段３０４ｂ，３０５ｂとを備え、対象ドメインである低信頼度ドメイン１５０Ｃへのデータ送信時に低信頼度ドメイン１５０Ｃが実際にどのような障害状況にあるかを検知する機能を有する。
中信頼度ドメイン用データ送信部３０６，３０７は、それぞれデータ送信手段３０６ａ，３０７ａと、中信頼度ドメイン停止検知手段３０６ｂ，３０７ｂとを備え、対象ドメインである中信頼度ドメイン１５０Ｂへのデータ送信時に中信頼度ドメイン１５０Ｂが実際にどのような障害状況にあるかを検知する機能を有する。
データ送信手段３０４ａ，３０５ａ，３０６ａ，３０７ａは、前述の通り、上記データ送信部３０１，３０２，３０３と同様の機能を有する。
低信頼度ドメイン停止検知手段３０４ｂ，３０５ｂは、データ送信手段３０４ａ又は３０５ａによって低信頼度ドメイン１５０Ｃにデータ送信をする際に、低信頼度ドメイン１５０Ｃが実際に停止状態であるか否かを検知する機能を有する。
この検知機能は、例えば、送信先ドメインである低信頼度ドメイン１５０Ｃに当該データが受信されているか否かを判断することによって、低信頼度ドメイン１５０Ｃが停止状態であるか否かを検知する。具体的には、当該データが低信頼度ドメイン１５０Ｃに受理されない時間や回数を計測することによって検知することができる。なお、最高信頼度ドメイン１５０Ａや、中信頼度ドメイン１５０Ｂの処理負担を増大させないために、当該検知処理に要する時間はより短時間であることが望ましい。
また、低信頼度ドメイン停止検知手段３０４ｂ，３０５ｂは、低信頼度ドメイン１５０Ｃが停止状態であることを検知すると、最高信頼度ドメイン１５０Ａに、低信頼度ドメイン１５０Ｃが停止状態であることを通知する。
中信頼度ドメイン停止検知手段３０６ｂは、低信頼度ドメイン停止検知手段３０４ｂ，３０５ｂと同様の構成及び機能を備え、データ送信手段３０６ａによって中信頼度ドメイン１５０Ｂにデータ送信をする際に、中信頼度ドメイン１５０Ｂ（の障害内容を検知）が実際に停止状態であるか否かを検知する機能を有する。
この検知機能は、例えば、送信先ドメインである中信頼度ドメイン１５０Ｂに当該データが受信されているか否かを判断することによって、中信頼度ドメイン１５０Ｂが停止状態であるか否かを検知する。具体的には、当該データが中信頼度ドメイン１５０Ｂに受理されない時間や回数を計測することによって判断することができる。なお、最高信頼度ドメイン１５０Ａの処理負担を増大させないために、当該検知処理に要する時間はより短時間であることが望ましい。
また、中信頼度ドメイン停止検知手段３０６ｂは、中信頼度ドメイン１５０Ｂが停止状態であることを確認すると、最高信頼度ドメイン１５０Ａに、中信頼度ドメイン１５０Ｂが停止状態であることを通知する。
なお、後述するように、中信頼度ドメイン停止検知手段３０６ｂは、中信頼度ドメイン１５０Ｂに対する復旧処理を許可するための権限を有する場合には、中信頼度ドメイン１５０Ｂが停止状態であることをドメイン停止復旧手段４００に直接通知し、ドメイン停止復旧手段４００を用いて中信頼度ドメイン１５０Ｂの復旧処理を行ってもよい。
この場合には、最高信頼度ドメイン１５０Ａが復旧処理の許可に関する処理を行わないことから、最高信頼度ドメイン１５０Ａの処理負担が軽くなるという効果を奏する。
一方、中信頼度ドメイン停止検知手段３０７ｂは、自ドメインより信頼度が高いドメインの停止を検知する手段であり、データ送信手段３０６ａによって中信頼度ドメイン１５０Ｂにデータ送信をする際に、中信頼度ドメイン１５０Ｂが実際に停止状態であるか否かを検知する機能を有する。
この検知機能は、例えば、送信先ドメインである中信頼度ドメイン１５０Ｂに当該データが受信されているか否かを判断することによって、中信頼度ドメイン１５０Ｂが停止状態であるか否かを検知する。具体的には、当該データが中信頼度ドメイン１５０Ｂに受理されない時間や回数を計測することによって判断することができる。なお、当該検知処理の時間が短いと、低信頼度ドメイン１５０Ｃが最高信頼度ドメイン１５０Ａに通知する情報の真偽についての信頼度が低いので、当該検知処理にはより長時間を設けることを必要とする。
また、中信頼度ドメイン停止検知手段３０７ｂは、中信頼度ドメイン１５０Ｂが停止状態であることを検知すると、最高信頼度ドメイン１５０Ａに、中信頼度ドメイン１５０Ｂが停止状態であることを通知する。
また、上記各ドメイン停止検知手段は、停止検知の対象となるドメインが実際に停止状態であるか否かを、例えば、以下の示すような方法によって検知することができる。
（１）送信元ドメインが、停止検知の対象となる送信先ドメインに定期的に送るチェックパケットの応答の有無を計測することによって検知できる。具体的には、応答のない時間や回数を計測する。また、計測する当該時間や回数は信頼度の差に応じて変更してもよい。
（２）送信先ドメインが表示する停止・暴走情報を計測することによって検知できる。具体的には、送信先ドメインが定期的に更新する情報が途絶えたことを計測する。
なお、上記における当該時間、回数や更新情報の計測頻度等をそれぞれ送信先ドメインよりも高い信頼度のドメインが設定可能としてもよい。ただし、最低閾値を超えての設定の変更はできないものとする。
上記各ドメイン停止検知手段は、上記各検知処理の手法や当該時間、回数や更新情報等を任意に組み合わせることによって、停止検知の対象となるドメインが実際に停止状態であるか否かを確認してもよい。
ドメイン停止復旧手段４００は、データ送信部３０１を介して最高信頼度ドメイン１５０Ａから通知された処理要求等に基づいて、対象となるドメイン内のＣＰＵのリセットやＯＳのリブート、ドメイン自体のリブートや、例えば、何月何日等の特定日時の環境へのロールバックや、あるいは、通信路の復旧やアプリの再起動等、復旧処理を含む様々な処理要求を実行する機能を有しており、さらに、最高信頼度ドメイン１５０Ａからのみアクセスできる構成になっており、最高信頼度ドメイン１５０Ａからの処理要求は無条件で受け入れる。
なお、ドメイン停止復旧手段４００は、最高信頼度ドメイン１５０Ａ以外のドメインから復旧処理等の処理要求がなされた場合、これらは全て拒否する。
すなわち、復旧条件は、個々のドメインの信頼度に応じて、そのドメインからの復旧要求の許可または拒否によって決定することができる。例えば、本実施例での復旧条件は、最高信頼度ドメインからの復旧要求を全て許可し、一方それ以外のドメインからの復旧要求を全て拒否する、と規定される。
図２６に、ドメイン停止復旧手段４００の構成を示す。
図２６が示すように、ドメイン停止復旧手段４００は、復旧要求受信手段４０１と、ドメイン停止復旧処理手段４０２とを備える。
復旧要求受信手段４０１は、最高信頼度ドメイン１５０Ａからデータ送信部３０１を介して復旧要求（処理要求）を受信し、この処理要求をドメイン停止復旧処理手段４０２に通知する機能を有する。
ドメイン停止復旧処理手段４０２は、復旧要求受信手段４０１から通知された処理要求に基づいて、何れのドメインが処理の対象となり、どのような処理要求がされたのか、その処理内容を識別し、該当するドメインに該当する処理内容を依頼をする。
例えば、最高信頼度ドメイン１５０Ａから通知された処理要求が、停止している中信頼度ドメイン１５０Ｂの復旧処理要求の場合、ドメイン停止復旧処理手段４０２は、停止している中信頼度ドメイン１５０Ｂに対して復旧処理を依頼をする。
なお、通信においては、各層において通信相手が規定されるので、それぞれの階層で検知された障害の種類によって処理内容が異なる。例えば、それぞれの階層で検知された停止の状態によって復旧内容が異なる。
図２７に、通信処理の内容（処理内容）とその階層構造との対応関係の一例を示す。
図２７が示すように、各ドメインの階層構造は、上の階層から順に、例えば、アプリケーション層、ライブラリ層、ＯＳ層、ＣＰＵ層と構成され、ドメイン停止復旧処理手段４０２は、予め定められた階層毎に対応する停止検知処理を実行して通信処理（復旧処理）を行う。
通信処理の内容（復旧処理内容）は、アプリケーション層でのアプリの再起動、ライブラリ層でのある時点へのロールバック、ＯＳ層でのＯＳリブート、ＣＰＵ層でのＣＰＵロールバックである。
なお、第１の実施例における情報処理装置を動作させるプログラムは、上記各部及び各手段で実現される機能を安定して実現する必要があるために、外部からダウンロードした追加処理の影響を受けることがない最高信頼度ドメイン１５０Ａで格納及び実行されることが好ましい。
ここで、第１の実施例による情報処理装置のハードウェア構成の説明をする。
図２８は、第１の実施例による情報処理装置のハードウェア構成の一例を示すブロック図である。
図２８を参照すると、第１の実施例による情報処理装置は、一般的なコンピュータ装置と同様のハードウェア構成を備えることによって実現することができ、複数のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）５０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等のメインメモリであるデータの作業領域やデータの一時退避領域に用いられる主記憶部５０２、インターネット６００を介してデータの送受信を行う通信部５０３、液晶ディスプレイ、プリンタやスピーカ等の提示部５０４、キー操作部等の入力部５０５、周辺機器と接続してデータの送受信を行うインタフェース部５０６、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、磁気ディスク、半導体メモリ等の不揮発性メモリから構成されるハードディスク装置である補助記憶部５０７、本情報処理装置の上記各構成要素を相互に接続するシステムバス５０８等を備えている。
第１の実施例による情報処理装置は、その動作を、情報処理装置内部にそのような機能を実現するプログラムを組み込んだ、ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等のハードウェア部品からなる回路部品を実装してハードウェア的に実現することは勿論として、上記した各手段及び各部の各機能を提供するプログラムを、コンピュータ処理装置上のＣＰＵ５０１で実行することにより、ソフトウェア的に実現することができる。
（第１の実施例の動作）
（最高信頼度ドメイン１５０Ａによる処理要求）
図２９は、図２４に示した第１の実施例の動作の一例を説明するための図であり、最高信頼度ドメイン１５０Ａによる中信頼度ドメイン１５０Ｂの停止検知・復旧処理を示す。図２９において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
まず、初期状態として、中信頼度ドメイン１５０Ｂが異常停止をしていることとする。
ステップ１：最高信頼度ドメイン１５０Ａが、中信頼度ドメイン停止検知機能付データ送信部３０６のデータ送信手段３０６ａを介して、中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ２：中信頼度ドメイン停止検知機能付データ送信部３０６の中信頼度ドメイン停止検知手段３０６ｂが、中信頼度ドメイン１５０Ｂの停止を検知する。
ステップ３：中信頼度ドメイン停止検知手段３０６ｂが中信頼度ドメイン１５０Ｂの停止を検知したことにより、最高信頼度ドメイン１５０Ａが、データ送信部３０１を介して、ドメイン停止復旧手段４００に中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ４：ドメイン停止復旧手段４００が、最高信頼度ドメイン１５０Ａからの復旧要求に基づいて、中信頼度ドメイン１５０Ｂを復旧する。
図３０は、図２４に示した第１の実施例の動作の一例を説明するための図であり、最高信頼度ドメイン１５０Ａによる低信頼度ドメイン１５０Ｃの停止検知・復旧処理を示す。図３０において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
まず、初期状態として、低信頼度ドメイン１５０Ｃが異常停止をしていることとする。
ステップ１：最高信頼度ドメイン１５０Ａが、低信頼度ドメイン停止検知機能付データ送信部３０４のデータ送信手段３０４ａを介して、低信頼度ドメイン１５０Ｃへデータを送信する。
ステップ２：低信頼度ドメイン停止検知機能付データ送信部３０４の中信頼度ドメイン停止検知手段３０４ｂが低信頼度ドメイン１５０Ｃの停止を検知する。
ステップ３：低信頼度ドメイン停止検知手段３０４ｂが低信頼度ドメイン１５０Ｃの停止を検知したことにより、最高信頼度ドメイン１５０Ａが、データ送信部３０１を介して、ドメイン停止復旧手段４００に低信頼度ドメイン１５０Ｃの復旧を要求する。
ステップ４：ドメイン停止復旧手段４００が、最高信頼度ドメイン１５０Ａからの復旧要求に基づいて、低信頼度ドメイン１５０Ｃを復旧する。
（中信頼度ドメイン１５０Ｂによる処理要求）
図３１は、図２４に示した第１の実施例の動作の一例を説明するための図であり、中信頼度ドメイン１５０Ｂによる低信頼度ドメイン１５０Ｃの停止検知・復旧処理を示す。図３１において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
まず、初期状態として、低信頼度ドメイン１５０Ｃが異常停止をしていることとする。
ステップ１：中信頼度ドメイン１５０Ｂが、低信頼度ドメイン停止検知機能付データ送信部３０５のデータ送信手段３０５ａを介して、低信頼度ドメイン１５０Ｃへデータを送信する。
ステップ２：低信頼度ドメイン停止検知機能付データ送信部３０５の低信頼度ドメイン停止検知手段３０５ｂが、低信頼度ドメイン１５０Ｃの停止を検知する。
ステップ３：低信頼度ドメイン停止検知手段３０５ｂが低信頼度ドメイン１５０Ｃの停止を検知したことにより、中信頼度ドメイン１５０Ｂが、データ送信部３０２を介して、最高信頼度ドメイン１５０Ａに低信頼度ドメイン１５０Ｃの復旧を要求する。
ステップ４：最高信頼度ドメイン１５０Ａが、データ送信部３０１を介して、ドメイン停止復旧手段４００に低信頼度ドメイン１５０Ｃの復旧を要求する。
ステップ５ドメイン停止復旧手段４００が、最高信頼度ドメイン１５０Ａからの復旧要求に基づいて、低信頼度ドメイン１５０Ｃを復旧する。
なお、ステップ３とステップ４との間において、最高信頼度ドメイン１５０Ａが、復旧を要求された上記低信頼度ドメイン１５０Ｃが実際に停止しているかを確認するために、低信頼度ドメイン停止検知機能付データ送信部３０４を用いて停止の有無を検知してもよい。
あるいは、ステップ４とステップ５との間において、ドメイン停止復旧手段４００が、復旧を要求された上記低信頼度ドメイン１５０Ｃが実際に停止しているかを確認するために、低信頼度ドメイン停止検知機能付データ送信部３０４を用いて停止の有無を検知してもよい。
（低信頼度ドメイン１５０Ｃによる処理要求）
図３２は、図２４に示した第１の実施例の動作の一例を説明するための図であり、低信頼度ドメイン１５０Ｃによる中信頼度ドメイン１５０Ｂの停止検知・復旧処理を示す。図３２において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
まず、初期状態として、中信頼度ドメイン１５０Ｂが異常停止をしていることとする。
ステップ１：低信頼度ドメイン１５０Ｃが、中信頼度ドメイン停止検知機能付データ送信部３０７のデータ送信手段３０７ａを介して、中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ２：中信頼度ドメイン停止検知機能付データ送信部３０７の中信頼度ドメイン停止検知手段３０７ｂが、中信頼度ドメイン１５０Ｂの停止を検知する。
ステップ３：中信頼度ドメイン停止検知手段３０７ｂが中信頼度ドメイン１５０Ｂの停止を検知したことにより、低信頼度ドメイン１５０Ｃが、データ送信部３０３を介して、最高信頼度ドメイン１５０Ａに中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ４：復旧要求元ドメインである低信頼度ドメイン１５０Ｃが、復旧対象ドメインである中信頼度ドメイン１５０Ｂより信頼度が低く、さらに、低信頼度であることから、最高信頼度ドメイン１５０Ａが、復旧要求の対象や内容の真偽を確認するため、中信頼度ドメイン停止検知機能付データ送信部３０６のデータ送信手段３０６ａを介して、中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ５：中信頼度ドメイン停止検知機能付データ送信部３０６の中信頼度ドメイン停止検知手段３０６ｂが、中信頼度ドメイン１５０Ｂの停止を検知することにより、実際に中信頼度ドメイン１５０Ｂが停止していることを確認する。
ステップ６：最高信頼度ドメイン１５０Ａが、実際に中信頼度ドメイン１５０Ｂが停止していることを確認したことにより、データ送信部３０１を介して、ドメイン停止復旧手段４００に中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ７：ドメイン停止復旧手段４００が、最高信頼度ドメイン１５０Ａからの復旧要求に基づいて、中信頼度ドメイン１５０Ｂを復旧する。
なお、ステップ４〜ステップ６において、最高信頼度ドメイン１５０Ａが当該確認処理を行わずに、ステップ６とステップ７との間において、ドメイン停止復旧手段４００が、復旧を要求された上記中信頼度ドメイン１５０Ｂが実際に停止しているかを確認するために、中信頼度ドメイン停止検知機能付データ送信部３０６を用いて停止の有無を検知してもよい。
（同一信頼度ドメインによる処理要求）
図３３は、図２４に示した第１の実施例の動作の一例を説明するための図であり、同一信頼度ドメイン内の停止検知・復旧処理の一例として、中信頼度ドメイン１５０Ｂによる他の中信頼度ドメイン１５０Ｂの停止検知・復旧処理を示す。図３３において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
まず、初期状態として、１群の中信頼度ドメイン１５０Ｂ内の少なくとも一つの中信頼度ドメイン１５０Ｂが異常停止をしていることとする。
ステップ１：停止していない他の中信頼度ドメイン１５０Ｂが、１群の中信頼度ドメイン１５０Ｂ内の上記中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ２：データ送信先の上記中信頼度ドメイン１５０Ｂの停止を検知する。なお、同一信頼度ドメイン内の停止検知処理は、信頼度が設定されていないドメインにおける同一ドメイン内の停止検知処理と同様である。従って、この様な停止検知処理は一般的な技術であるため、説明を省略する。
ステップ３：データ送信先の上記中信頼度ドメイン１５０Ｂの停止を検知したことにより、当該データの送信元である中信頼度ドメイン１５０Ｂが、データ送信部３０２を介して、最高信頼度ドメイン１５０Ａに上記停止状態の中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ４：最高信頼度ドメイン１５０Ａが、データ送信部３０１を介して、ドメイン停止復旧手段４００に上記停止状態の中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ５：ドメイン停止復旧手段４００が、最高信頼度ドメイン１５０Ａからの復旧要求に基づいて、上記停止状態の中信頼度ドメイン１５０Ｂを復旧する。
なお、ステップ３とステップ４との間において、最高信頼度ドメイン１５０Ａが、復旧を要求された上記停止状態の中信頼度ドメイン１５０Ｂが実際に停止しているかを確認するために、中信頼度ドメイン停止検知機能付データ送信部３０６を用いて停止の有無を検知してもよい。
あるいは、ステップ４とステップ５との間において、ドメイン停止復旧手段４００が、復旧を要求された上記停止状態の中信頼度ドメイン１５０Ｂが実際に停止しているかを確認するために、中信頼度ドメイン停止検知機能付データ送信部３０６を用いて停止の有無を検知してもよい。
（第１の実施例による効果）
このように、本発明の第１の実施例によれば、信頼度に基づいて各ドメインが分離されているので、メーラーやブラウザ等の基本処理を有する最高信頼度ドメイン１５０Ａが、最高信頼度ドメイン１５０Ａ以外のドメインからの攻撃等の影響を受けることがなく、最高信頼度ドメイン１５０Ａ以外のドメインが停止する際にも、情報処理装置のメーラーやブラウザ等の基本処理がフリーズしない。すなわち、信頼度が低いドメインからウィルスを含んでいる等の悪意のある処理要求や誤った復旧等の処理要求を受け付けないので、情報処理装置の基本処理がフリーズすることを防止することができる。
また、最高信頼度ドメイン１５０Ａは、最高信頼度ドメイン１５０Ａ以外への通信経路専用の低信頼度ドメイン用データ送信部３０４及び中信頼度ドメイン用データ送信部３０６と、最高信頼度ドメイン１５０Ａ以外のドメインからの通信経路専用のデータ送信部３０２，３０３とに接続しており、各ドメインへの通信経路がそれぞれ設けられていることから、最高信頼度ドメイン１５０Ａのみに各種データの書き込みが許可され、各ドメイン間の排他制御が不要となる。
さらに、ドメイン停止復旧停止手段によって、停止等の障害が生じた、最高信頼度ドメイン１５０Ａ以外のドメインを復旧できるので、最高信頼度ドメイン１５０Ａのセキュリティを確保すると共に、情報処理装置の継続した稼動を可能とする。
また、ウォッチドッグタイマ等による自発的なドメイン復旧では、データ送信先のドメインの復旧にかかる時間が読めないので、エラー対処によって性能が落ち、さらに、自発的なドメイン復旧が起動できない場合があるという問題を有するが、本発明の第１の実施例によれば、最高信頼度ドメイン１５０Ａが、低信頼度ドメイン用データ送信部３０４及び中信頼度ドメイン用データ送信部３０６によって、中信頼度ドメイン１５０Ｂや低信頼度ドメイン１５０Ｃへのデータ送信時にこれらのドメインで生じている障害を検知できるので、データ送信時に、これらの障害の復旧が可能となり、上記問題を回避できる。
さらにまた、最高信頼度ドメイン１５０Ａが、低信頼度ドメイン停止検知手段３０４ｂ及び中信頼度ドメイン停止検知手段という２種類の停止検知手段を備えるため、最高信頼度ドメイン１５０Ａによる停止検知処理について分散化でき、高速化を図ることができる。
また、最高信頼度ドメイン１５０Ａが、自身の判断により、信頼度に応じた優先順位に基づいて復旧処理を行えるので、必要な機能から優先的に復旧できる等、情報処理装置の適切な復旧が可能となる。例えば、障害が発生したあるドメインに対して複数の復旧要求が同時になされた場合でも、復旧要求の要求元のドメインの信頼度や、復旧要求が示す処理内容の信頼度に応じた優先順位の基づいて、柔軟で効率的な復旧処理が可能となる。また、不必要な復旧処理の発生を抑えることや、必要最低限のみの復旧処理を行うことも可能である。
（第２の実施例）
第２の実施例は、図２４に示した第１の実施例に対応し、第１の実施例と同様の構成を採用するが、ドメイン停止復旧手段４００が、各種ドメインで発行された要求を受信する停止確認手段４０３を有する点で相違する。
以下、上記の第１の実施例との相違点について主に説明し、第１の実施例と共通する構成要素については説明を省略する。
（第２の実施例の構成）
図３４は、第２の実施例によるドメイン停止復旧手段４００の構成を示す図である。
図３４に示すように、第２の実施例によるドメイン停止復旧手段４００は、停止確認手段４０３を備える点で第１の実施例と相違する。
停止確認手段４０３は、復旧要求受信手段４０１を介して、各種ドメインから通知された情報から、復旧要求（処理要求）を発行した要求元ドメインを識別する情報、処理の対象となるドメインを識別する情報、処理の内容を識別する情報等を取得し、低信頼度ドメイン用データ送信部３０４や中信頼度ドメイン用データ送信部３０６を用いて処理の対象となるドメインの実際の障害状況を検知し、取得した処理の内容の真偽を確認する機能を有する。
停止確認手段４０３は、このようにして、取得した処理の内容が正しいと確認した場合に、各種ドメインから通知された情報をドメイン停止復旧処理手段４０２に通知し、処理を要求する。
ドメイン停止復旧処理手段４０２は、停止確認手段から処理を要求されると、停止確認手段４０３から通知された情報に基づいて、処理の対象となるドメイン内の所定の手段に復旧等の処理を依頼する。
なお、第２の実施例では、ドメイン停止復旧手段４００が有する停止確認手段４０３が、低信頼度ドメイン用データ送信部３０４や中信頼度ドメイン用データ送信部３０６を備えていてもよいし、また、停止確認手段４０３が、ドメイン停止復旧手段４００の外部にあり、各種ドメインから通知された情報に基づいて上記検知処理を行い、ドメイン停止復旧手段４００内のドメイン停止復旧処理手段４０２に処理要求を行う構成としてもよい。
（第２の実施例の動作）
（中信頼度ドメイン１５０Ｂによる処理要求）
図３５は、図２４に示した第１の実施例において、図３４に示した停止復旧手段４００を備える場合の動作の一例を説明するための図であり、中信頼度ドメイン１５０Ｂによる低信頼度ドメイン１５０Ｃの停止検知・復旧処理を示す。図３５において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
なお、中信頼度ドメイン１５０Ｂが、データ送信部３０２を介して、ドメイン停止復旧手段４００に低信頼度ドメイン１５０Ｃの復旧を要求する点において、図２４に示した第１の実施例と相違する。
まず、初期状態として、低信頼度ドメイン１５０Ｃが異常停止をしており、かつ、中信頼度ドメイン１５０Ｂが、ドメイン停止復旧手段４００を利用でき、もしくは、ドメイン停止復旧手段４００を利用する権限を有することとする。
ステップ１：中信頼度ドメイン１５０Ｂが、低信頼度ドメイン停止検知機能付データ送信部３０５のデータ送信手段３０５ａを介して、低信頼度ドメイン１５０Ｃへデータを送信する。
ステップ２：低信頼度ドメイン停止検知機能付データ送信部３０５の低信頼度ドメイン停止検知手段３０５ｂが、低信頼度ドメイン１５０Ｃの停止を検知する。
ステップ３：低信頼度ドメイン停止検知手段３０５ｂが低信頼度ドメイン１５０Ｃの停止を検知したことにより、ドメイン停止復旧手段４００を利用できる中信頼度ドメイン１５０Ｂが、データ送信部３０２を介して、ドメイン停止復旧手段４００に低信頼度ドメイン１５０Ｃの復旧を要求する。
ステップ４：ドメイン停止復旧手段４００が、中信頼度ドメイン１５０Ｂからの復旧要求に基づいて、低信頼度ドメイン１５０Ｃを復旧する。
なお、ステップ３とステップ４との間において、ドメイン停止復旧手段４００が、復旧を要求された上記低信頼度ドメイン１５０Ｃが実際に停止しているかを確認するために、低信頼度ドメイン停止検知機能付データ送信部３０４を用いて停止の有無を検知してもよい。
また、ステップ３とステップ４との間において、原則的に、ドメイン停止復旧手段４００が、復旧を要求された上記低信頼度ドメイン１５０Ｃが実際に停止しているか等の障害を確認するために、低信頼度ドメイン停止検知機能付データ送信部３０４を用いて停止等の有無を検知し、中信頼度ドメイン１５０Ｂから復旧要求がなされた場合には、信頼度の設定に基づき、上記停止等の障害の有無を検知しないこととしてもよい。
（低信頼度ドメイン１５０Ｃによる処理要求）
図３６は、図２４に示した第１の実施例において、図３４に示した停止復旧手段４００を備える場合の動作の一例を説明するための図であり、低信頼度ドメイン１５０Ｃによる中信頼度ドメイン１５０Ｂの停止検知・復旧処理を示す。図３６において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
なお、低信頼度ドメイン１５０Ｃが、データ送信部３０３を介して、ドメイン停止復旧手段４００に中信頼度ドメイン１５０Ｂの復旧を要求し、ドメイン停止復旧手段４００が、中信頼度ドメイン停止検知機能付データ送信部３０７を用いて、中信頼度ドメイン１５０Ｂへのデータ送信及び中信頼度ドメイン１５０Ｂの停止を検知する点において、図２４に示した第１の実施例と相違する。
まず、初期状態として、中信頼度ドメイン１５０Ｂが異常停止をしており、かつ、低信頼度ドメイン１５０Ｃが、ドメイン停止復旧手段４００を利用でき、もしくは、ドメイン停止復旧手段４００を利用する権限を有することとする。
ステップ１：低信頼度ドメイン１５０Ｃが、中信頼度ドメイン停止検知機能付データ送信部３０７のデータ送信手段３０７ａを介して、中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ２：中信頼度ドメイン停止検知機能付データ送信部３０７の中信頼度ドメイン停止検知手段３０７ｂが、中信頼度ドメイン１５０Ｂの停止を検知する。
ステップ３：中信頼度ドメイン停止検知手段３０７ｂが中信頼度ドメイン１５０Ｂの停止を検知したことにより、低信頼度ドメイン１５０Ｃが、データ送信部３０３を介して、ドメイン停止復旧手段４００に中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ４：復旧要求元ドメインである低信頼度ドメイン１５０Ｃが、復旧対象ドメインである中信頼度ドメイン１５０Ｂより信頼度が低く、さらに、低信頼度であることから、ドメイン停止復旧手段４００が、復旧要求の対象や内容の真偽を確認するため、中信頼度ドメイン停止検知機能付データ送信部３０６のデータ送信手段３０６ａを介して、中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ５：中信頼度ドメイン停止検知機能付データ送信部３０６の中信頼度ドメイン停止検知手段３０６ｂが、中信頼度ドメイン１５０Ｂの停止を検知することにより、ドメイン停止復旧手段４００は、実際に中信頼度ドメイン１５０Ｂが停止していることを確認する。
ステップ６：ドメイン停止復旧手段４００は、実際に中信頼度ドメイン１５０Ｂが停止していることを確認したことにより、低信頼度ドメイン１５０Ｃからの復旧要求に基づいて、中信頼度ドメイン１５０Ｂを復旧する。
（同一信頼度ドメインによる処理要求）
図３７は、図２４に示した第１の実施例において、図３４に示した停止復旧手段４００を備える場合の動作の一例を説明するための図であり、同一信頼度ドメイン内の停止検知・復旧処理の一例として、中信頼度ドメイン１５０Ｂによる他の中信頼度ドメイン１５０Ｂの停止検知・復旧処理を示す。図３７において、各矢線に付された番号は、当該線を情報が転送されるステップ番号を表している。
なお、中信頼度ドメイン１５０Ｂが、データ送信部３０２を介して、ドメイン停止復旧手段４００に他の中信頼度ドメイン１５０Ｂの復旧を要求する点において、図２４に示した第１の実施例と相違する。
まず、初期状態として、１群の中信頼度ドメイン１５０Ｂ内の少なくとも一つの中信頼度ドメイン１５０Ｂが、ドメイン停止復旧手段４００を利用でき、もしくは、ドメイン停止復旧手段４００を利用する権限を有することとする。
ステップ１：停止していない他の中信頼度ドメイン１５０Ｂが、１群の中信頼度ドメイン１５０Ｂ内の上記中信頼度ドメイン１５０Ｂへデータを送信する。
ステップ２：データ送信先の上記中信頼度ドメイン１５０Ｂの停止を検知する。
ステップ３：データ送信先の上記中信頼度ドメイン１５０Ｂの停止を検知したことにより、ドメイン停止復旧手段４００を利用できる当該データの送信元である中信頼度ドメイン１５０Ｂが、データ送信部３０２を介して、ドメイン停止復旧手段４００に上記停止状態の中信頼度ドメイン１５０Ｂの復旧を要求する。
ステップ４：ドメイン停止復旧手段４００が、当該データの送信元である中信頼度ドメイン１５０Ｂからの復旧要求に基づいて、上記停止状態の中信頼度ドメイン１５０Ｂを復旧する。
なお、ステップ３とステップ４との間において、ドメイン停止復旧手段４００が、復旧を要求された上記中信頼度ドメイン１５０Ｂが実際に停止しているかを確認するために、中信頼度ドメイン停止検知機能付データ送信部３０６を用いて停止の有無を検知してもよい。
（第２の実施例による効果）
このように、本発明の第２の実施例によれば、停止確認手段４０３が、各種ドメインから通知された情報に基づいて上記検知処理を行う。従って、最高信頼度ドメイン１５０Ａが、中信頼度ドメイン１５０Ｂや低信頼度ドメイン１５０Ｃから処理要求を通知されても、処理の対象となるドメインの実際の障害状況を検知し、処理の内容の真偽を確認する必要がないので、最高信頼度ドメイン１５０Ａの処理負担が軽減されるという効果を奏する。
（第３の実施例）
第３の実施例は、図２４にお示した第１の実施例に対応し、第１の実施例と同様の構成を採用するが、ドメイン停止復旧手段４００が、各種ドメインで発行された要求を受信する復旧処理制御手段４０４を有する点で相違する。
以下、上記の第１の実施例との相違点について主に説明する。
（第３の実施例の構成）
図３８は、第３の実施例によるドメイン停止復旧手段４００の構成を示す図である。
図３８に示すように、本実施例によるドメイン停止復旧手段４００は、復旧処理制御手段４０４を備える点で第１の実施例と相違する。
以下、上記の第１の実施例との相違点について主に説明する。
復旧処理制御手段４０４は、図４のアクセス制御手段３０と同様の構成及び機能を有し、復旧処理許可データ４０４ａを格納した記憶手段と、復旧処理許可手段４０４ｂとを備え、復旧要求受信手段４０１を介して最高信頼度ドメイン１５０Ａ以外のドメインから通知された処理要求に対する許否を判別する機能を有する。
また、復旧処理制御手段４０４は、処理要求が通知された場合、許可された処理要求だけをドメイン停止復旧手段４００に通知する。
ここで、復旧要求受信手段４０１は、各ドメインから受信した復旧要求（処理要求）について、最高信頼度ドメイン１５０Ａから受信した復旧要求（処理要求）をドメイン停止復旧処理手段４０２に通知し、最高信頼度ドメイン１５０Ａ以外のドメインから受信した復旧要求（処理要求）を復旧処理許可手段４０４ｂに通知する。
復旧処理制御手段４０４は、低レベルのセキュリティしか要求されないドメインである、最高信頼度ドメイン１５０Ａ以外のドメインに対して、予め許可されたドメインへの予め許可された形態による処理要求のみを許可する制御を行う。
復旧処理許可データ４０４ａは、最高信頼度ドメイン１５０Ａ以外のドメインから通知される処理要求と、所定のドメインに対する所定の処理内容を関連付けて、最高信頼度ドメイン１５０Ａが予め設定したデータであり、最高信頼度ドメイン１５０Ａから読み出し・書き込みが可能である。また、復旧処理許可手段４０４ｂからは読み出しのみが許可されている。さらに、最高信頼度ドメイン１５０Ａ以外のドメインからは読み出しも書き込みも不可とされる。すなわち、復旧処理許可データ４０４ａと最高信頼度ドメイン１５０Ａ以外のドメインの間にはデータバスが存在しない。
図３９に、復旧処理許可データ４０４ａの内容の一例を示す。
図３９に示すように、復旧処理許可データ４０４ａは、復旧を要求する側のドメインである要求元ドメインに対して、復旧処理の対象となる復旧先ドメインとその復旧方法とを規定する。
要求元ドメインがドメイン＃１の場合、復旧先ドメイン及び復旧方法は無いことが規定されている。
要求元ドメインがドメイン＃２の場合、復旧先ドメインはドメイン＃１のみ、復旧方法はＯＳリブートのみであることが規定されている。
要求元ドメインがドメイン＃３の場合、復旧先ドメインはドメイン＃２のみ、復旧方法はリセット及びロールバックであることが規定されている。
復旧処理許可手段４０４ｂは、復旧要求受信手段を介して最高信頼度ドメイン１５０Ａ以外のドメインからの処理要求を受け取ると、復旧処理許可データ４０４ａの要求元ドメイン、復旧先ドメイン及び復旧方法を参照して、当該処理要求が該当するか否かによって、当該処理要求の許否を判断し、許可された処理要求の場合、当該処理要求をドメイン停止復旧手段４００に発行する機能を有する。一方、不許可の場合、復旧処理許可手段４０４ｂは、ドメイン停止復旧手段４００に当該発行をしない。
すなわち、復旧条件は、第１の実施例で述べた、個々のドメインの信頼度に応じて、そのドメインからの復旧要求の許可または拒否に加えて、復旧先ドメインや復旧処理等の処理内容によって決定することができる。例えば、本実施例での復旧条件は、ドメイン＃１からの復旧要求を全て拒否するという第１の実施例での条件設定に加えて、ドメイン＃２及びドメイン＃３からの復旧要求に対しては、各々復旧先ドメインと処理内容によって部分的に復旧要求を許可する、と規定される。このように、より細い復旧条件の設定が可能となることを特徴とする。
（第３の実施例の動作）
図４０は、復旧処理制御手段４０４の動作の一例を説明するための図である。図４０において、矢線脇の番号は、ステップ番号を示している。
まず、初期設定として、最高信頼度ドメイン１５０Ａが、復旧処理許可データ４０４ａの内容を規定する。
ステップ１：最高信頼度ドメイン１５０Ａ以外のドメインが、復旧処理許可データ４０４ａと合致しない処理要求を発行したとする。
ステップ２：復旧処理許可手段４０４ｂは、当該処理要求を取得することによって、復旧処理許可データ４０４ａを読み出し、当該処理要求の許否を判断する。
ステップ３：復旧処理許可手段４０４ｂは、最高信頼度ドメイン１５０Ａ以外のドメインへエラーを返す。当該処理要求は、復旧処理許可データ４０４ａと合致しないためである。
ステップ４：最高信頼度ドメイン１５０Ａ以外のドメインは、上記処理要求とは別の処理要求を発行する。
ステップ５：復旧処理許可手段４０４ｂは、当該処理要求を取得することによって、復旧処理許可データ４０４ａを読み出し、当該処理要求の許否を判断する。
ステップ６：復旧処理許可手段４０４ｂは、最高信頼度ドメイン１５０Ａ以外のドメインの当該処理要求を許可した場合、ドメイン停止復旧処理手段４０２に当該処理要求を発行する。
なお、第３の実施例では、復旧処理制御手段４０４の構成として、復旧処理許可データ４０４ａと、復旧処理許可手段４０４ｂとを備え復旧処理許可データ４０４ａに基づき、処理要求の制御を行う例について説明したが、本発明にかかる構成のみに制限されるものでなく、復旧処理許可データに変えて（反転し）、復旧処理拒否データと、復旧処理拒否手段を備えても良い。この場合、復旧処理拒否手段は、最高信頼度ドメイン１５０Ａ以外のドメインからの処理要求が、復旧処理拒否データによって復旧処理の拒否が定義された所定の要求元ドメイン、復旧拒否先ドメイン、復旧方法の何れか又は全部等において、所定の条件に合致した場合に、当該処理要求を拒否する制御を行う。
（第３の実施例による効果）
このように、本発明の第３の実施例によれば、復旧処理制御手段４０４の復旧処理許可手段４０４ｂが、復旧処理許可データ４０４ａに基づいて、予め許可されたドメインへ予め許可された形態による処理要求のみを許可する制御を行うので、最高信頼度ドメイン１５０Ａ以外のドメインがダウンロード等により外部から取得した追加処理による、高レベルのセキュリティを必要とする最高信頼度ドメイン１５０Ａへの各種攻撃を防ぐことが出来る。
また、復旧処理制御手段４０４が、ドメイン停止復旧手段４００の復旧処理を分散化するので、復旧処理の高速化が図れる。
なお、第３の実施例の変形例として、復旧処理許可手段４０４ｂに、キャッシュを備えても良い。この場合、処理要求の許否の判断に用いた、復旧処理許可データ４０４ａは、キャッシュに格納され、次回以降の処理要求の許否の判断において、該当する処理要求の復旧処理許可データ４０４ａがキャッシュに存在するかを判定し、キャッシュヒットした場合、処理要求の許否の判断の高速化を実現する。
（第４の実施例）
第４の実施例は、図２４に示した第１の実施例に対応し、第１の実施例と同様の構成を採用するが、ドメイン停止復旧手段４００が、停止確認手段４０３及び復旧処理制御手段４０４を有する点で相違する。
以下、上記の第１の実施例との相違点について主に説明する。
図４１は、第４の実施例によるドメイン停止復旧手段４００の構成を示す図である。
図４１に示すように、第４の実施例によるドメイン停止復旧手段４００は、停止確認手段４０３及び復旧処理制御手段４０４を備える点で第１の実施例と相違する。
ここで、停止確認手段４０３は、第２の実施例における停止確認手段４０３と同様の構成であり、また、復旧処理制御手段４０４は、第３の実施例における復旧処理制御手段４０４と同様の構成であるため、説明を省略する。
（第４の実施例の動作）
第４の実施例によるドメイン停止復旧手段４００は、復旧処理制御手段４０４が、第３の実施例と同様に最高信頼度ドメイン１５０Ａ以外のドメインからの処理要求について許否を判断し、停止確認手段４０３が、復旧処理制御手段４０４で許諾された処理要求を取得し、第２の実施例と同様に、取得した処理要求にかかる処理の内容の真偽を確認し、正しいと確認した場合に、取得した処理要求の情報をドメイン停止復旧処理手段４０２に通知する。
（第４の実施例による効果）
このように、本発明の第４の実施例によれば、復旧処理制御手段４０４の復旧処理許可手段４０４ｂが、復旧処理許可データ４０４ａに基づいて、予め許可されたドメインへ予め許可された形態による処理要求のみを許可する制御を行うので、最高信頼度ドメイン１５０Ａ以外のドメインがダウンロード等により外部から取得した追加処理による、高レベルのセキュリティを必要とする最高信頼度ドメイン１５０Ａへの各種攻撃を防ぐことが出来るので最高信頼度ドメイン１５０Ａのセキュリティが向上する。
また、復旧処理制御手段４０４が、ドメイン停止復旧手段４００の復旧処理を分散化するので、復旧処理の高速化が図れる。
さらに、停止確認手段４０３が、復旧処理許可手段４０４ｂによって許可された処理要求にかかる情報に基づいて上記検知処理を行う。従って、最高信頼度ドメイン１５０Ａが、中信頼度ドメイン１５０Ｂや低信頼度ドメイン１５０Ｃから処理要求を通知されても、処理の対象となるドメインの実際の障害状況を検知し、処理の内容の真偽を確認する必要がないので、最高信頼度ドメイン１５０Ａの処理負担が軽減されるという効果を奏するとともに、最高信頼度ドメイン１５０Ａのセキュリティを確保しつつ、実際にドメインで生じている障害を的確に復旧することができるという効果を奏する。
以上好ましい複数の実施例をあげて本発明を説明したが、本発明は必ずしも、上記実施例に限定されるものでなく、その技術的思想の範囲内において様々に変形して実施することができる。
例えば、本実施例では、３つドメインにより構成される情報処理装置の例で説明したが、ドメイン数は３つに限られず、本実施例で説明したように、各ドメインが分離されていれば、２つでもよく、また、４つ以上でもよい。
また、例えば、本実施例では、復旧処理制御手段４０４がドメイン停止復旧手段４００に設けられた構成で説明したが、復旧処理制御手段４０４が設けられる位置は停止復旧手段４００内に限定されず、停止復旧手段４００外でもよいし、最高信頼度ドメイン１５０Ａ内でもよいし、複数の位置に設けられていてもよい。復旧処理制御手段４０４が最高信頼度ドメイン１５０Ａ内に設けられた場合、最高信頼度ドメイン１５０Ａが、最高信頼度ドメイン１５０Ａ以外のドメインからの処理要求について許否を判断し、許諾した処理要求の情報をドメイン停止復旧処理手段４０２に通知してもよい。
Claims (65)
- 複数のプロセッサを備え、
実行する処理内容に応じて、前記複数のプロセッサが複数のドメインを構成し、
異なるドメイン間のプロセッサ同士は、通信手段を介して互いに通信し、
前記ドメインから通知される障害の復旧要求と、前記ドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行う復旧手段を有することを特徴とする情報処理装置。 - 前記複数のドメインを、実行する処理内容に応じて、特定ドメインと、他のドメインとに分離して構成し、
前記復旧手段は、前記特定ドメイン又は前記他のドメインから通知される障害の復旧要求と、前記特定ドメイン及び前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うことを特徴とする請求項２に記載の情報処理装置。 - 前記特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、前記他のドメインが、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、
前記特定ドメインが、前記他のドメインにおける障害を、前記他のドメインへの前記通信手段によるデータ送信を介して検知し、前記復旧手段に対して前記障害の復旧要求を行うことを特徴とする請求項２に記載の情報処理装置。 - 前記特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、前記他のドメインが、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、
前記他のドメインが、何れかの前記他のドメインにおける障害を検知し、前記特定ドメインに前記他のドメインの障害の復旧要求を通知し、
前記特定ドメインが、前記他のドメインの障害を、前記他のドメインへの前記通信手段によるデータ送信を介して検知し、前記復旧手段に対して前記障害の復旧要求を行うことを特徴とする請求項２に記載の情報処理装置。 - データ送信を介した障害の検知を、所定時間又は所定回数における前記データ送信先のドメインからの応答の有無によって行い、
前記特定ドメインが、前記ある一定のセキュリティレベル以上の処理として、基本処理を実行するドメインであり、
前記特定ドメインによる前記他のドメインへのデータ送信を介した障害の検知は、前記所定時間より短い時間を設定すること又は前記所定回数よりも少ない回数を設定することを特徴とする請求項３又は請求項４に記載の情報処理装置。 - 前記特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、前記他のドメインが、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、
前記他のドメインが、何れかの前記他のドメインにおける障害を検知し、前記特定ドメインに前記他のドメインの障害の復旧要求を通知し、
前記特定ドメインが、前記復旧手段に対して前記障害の復旧要求を行うことを特徴とする請求項２に記載の情報処理装置。 - 前記特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、前記他のドメインが、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、
前記他のドメインが、何れかの前記他のドメインにおける障害を検知し、前記特定ドメインを介さずに前記復旧手段に対して前記障害の復旧要求を行い、
前記復旧手段が、前記他のドメインから通知される前記障害の復旧要求と、前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生した前記他のドメインに対して障害の復旧処理を行うことを特徴とする請求項２に記載の情報処理装置。 - 前記復旧条件は、前記ドメインからの障害の復旧要求で示される処理内容毎に設定されたセキュリティレベルに基づいて定められており、
前記復旧手段は、前記ドメインから通知された障害の復旧要求と、前記復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うことを特徴とする請求項１から請求項７のいずれか１項に記載の情報処理装置。 - 前記他のドメインを、実行する処理内容に応じて、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第１ドメインと、前記第１ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第２ドメインとに分離して構成し、
前記第１ドメインが、前記第２ドメインにおける障害を、前記第２ドメインへの前記通信手段によるデータ送信を介して検知し、前記特定ドメインに前記第２ドメインの障害の復旧要求を通知し、
前記特定ドメインが、前記復旧手段に対して前記障害の復旧要求を行うことを特徴とする請求項６又は請求項８に記載の情報処理装置。 - 前記他のドメインを、実行する処理内容に応じて、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第１ドメインと、前記第１ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第２ドメインとに分離して構成し、
前記第１ドメインは、前記第２ドメインにおける障害を、前記第２ドメインへの前記通信手段によるデータ送信を介して検知し、前記特定ドメインを介さずに前記復旧手段に前記第２ドメインの障害の復旧要求を通知し、
前記復旧手段が、前記第１ドメインから通知される前記障害の復旧要求と、前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生した前記第２ドメインに対して障害の復旧処理を行うことを特徴とする請求項７又は請求項８に記載の情報処理装置。 - 前記他のドメインを、実行する処理内容に応じて、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第１ドメインと、前記第１ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第２ドメインとに分離して構成し、
前記第２ドメインが、前記第１ドメインにおける障害を、前記第１ドメインへの前記通信手段によるデータ送信によって検知し、前記特定ドメインに前記第１ドメインの障害の復旧要求を通知し、
前記特定ドメインが、第１ドメインの障害を、前記第１ドメインへの前記通信手段によるデータ送信を介して検知し、前記復旧手段に対して前記障害の復旧要求を行うことを特徴とする請求項４又は請求項８に記載の情報処理装置。 - 前記他のドメインを、実行する処理内容に応じて、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第１ドメインと、前記第１ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第２ドメインとに分離して構成し、
前記第２ドメインが、前記第１ドメインにおける障害を、前記第１ドメインへの前記通信手段によるデータ送信によって検知し、前記特定ドメインを介さずに前記復旧手段に前記第１ドメインの障害の復旧要求を通知し、
前記復旧手段が、第１ドメインの障害を、前記第１ドメインへの前記通信手段によるデータ送信を介して検知し、前記第２ドメインから通知される前記障害の復旧要求と、前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生した前記第１ドメインに対して障害の復旧処理を行うことを特徴とする請求項７又は請求項８に記載の情報処理装置。 - データ送信を介した障害の検知を、所定時間又は所定回数の前記データ送信先のドメインからの応答の有無によって行い、
前記第２ドメインによる前記第１ドメインへのデータ送信を介した障害の検知は、前記所定時間より長い時間を設定すること又は前記所定回数よりも多い回数を設定することを特徴とする請求項１１又は請求項１２に記載の情報処理装置。 - 前記復旧手段は、前記特定ドメインからの復旧要求を無条件で受け付け、前記他のドメインからの復旧要求は拒否することを特徴とする請求項２から請求項１３のいずれか１項に記載の情報処理装置。
- 前記復旧手段は、前記ドメインから障害の復旧要求が通知されると、復旧対象のドメインにおける障害を、前記復旧対象のドメインへのデータ送信を介して検知し、前記障害の復旧要求と、前記復旧条件とに基づいて、障害が発生した前記ドメインに対して障害の復旧処理を行うことを特徴とする請求項１から請求項１３のいずれか１項に記載の情報処理装置。
- 前記復旧手段は、
前記ドメインから通知された障害の復旧要求の許否を判別する判別手段を備え、
前記判別手段で許可された復旧要求に基づいて、障害が発生したドメインに対して障害の復旧処理を行うことを特徴とする請求項１から請求項１５のいずれか１項に記載の情報処理装置。 - 前記判別手段は、
前記ドメイン毎に設定された、障害の復旧に関するデータを備え、
前記ドメインより通知された障害の復旧要求と、前記データとに基づいて、前記障害の復旧要求の許否を判別することを特徴とする請求項１６に記載の情報処理装置。 - 前記データは、前記ドメインからの障害の復旧要求で示される処理内容毎に設定されたセキュリティレベルに基づいて設定されることを特徴とする請求項１７に記載の情報処理装置。
- 前記復旧手段は、
前記ドメインから通知された障害の復旧要求の許否を判別する判別手段を備え、
前記判別手段で許可された復旧要求に基づいて、前記復旧対象のドメインにおける障害を、前記復旧対象のドメインへのデータ送信を介して検知し、障害が発生した前記ドメインに対して障害の復旧処理を行うことを特徴とする請求項１から請求項１３のいずれか１項に記載の情報処理装置。 - 複数のプロセッサで構成される複数のドメインを有する情報処理装置上で、前記ドメインで発生した障害を復旧する復旧装置において、
実行する処理内容に応じて、前記複数のプロセッサが複数のドメインを構成し、
前記ドメインから通知される障害の復旧要求と、前記ドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行う復旧手段を有することを特徴とする復旧装置。 - 前記複数のドメインを、実行する処理内容に応じて、特定ドメインと、他のドメインとに分離して構成し、
前記復旧手段は、前記特定ドメイン又は前記他のドメインから通知される障害の復旧要求と、前記特定ドメイン及び前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うことを特徴とする請求項１９に記載の復旧装置。 - 前記復旧条件は、前記ドメインからの障害の復旧要求で示される処理内容毎に設定されたセキュリティレベルに基づいて定められており、
前記復旧手段は、前記ドメインから通知された障害の復旧要求と、前記復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うことを特徴とする請求項２０又は請求項２１に記載の復旧装置。 - 前記他のドメインが、実行する処理内容に応じて、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第１ドメインと、前記第１ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第２ドメインとに分離して構成し、
前記第２ドメインが、前記第１ドメインにおける障害を、前記第１ドメインへのデータ送信によって検知し、前記特定ドメインを介さずに前記復旧手段に前記第１ドメインの障害の復旧要求を通知すると、
前記復旧手段が、第１ドメインの障害を、前記第１ドメインへのデータ送信を介して検知し、前記第２ドメインから通知される前記障害の復旧要求と、前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生した前記第１ドメインに対して障害の復旧処理を行うことを特徴とする請求項２１又は請求項２２に記載の復旧装置。 - 前記復旧手段は、前記特定ドメインからの復旧要求を無条件で受け付け、前記他のドメインからの復旧要求は拒否することを特徴とする請求項２１から請求項２３のいずれか１項に記載の復旧装置。
- 前記復旧手段は、前記ドメインから障害の復旧要求が通知されると、復旧対象のドメインにおける障害を、前記復旧対象のドメインへのデータ送信を介して検知し、前記障害の復旧要求と、前記復旧条件とに基づいて、障害が発生した前記ドメインに対して障害の復旧処理を行うことを特徴とする請求項２０から請求項２２のいずれか１項に記載の復旧装置。
- 前記復旧手段は、
前記ドメインから通知された障害の復旧要求の許否を判別する判別手段を備え、
前記判別手段で許可された復旧要求に基づいて、障害が発生したドメインに対して障害
の復旧処理を行うことを特徴とする請求項２０から請求項２５のいずれか１項に記載の復旧装置。 - 前記判別手段は、
前記ドメイン毎に設定された、障害の復旧に関するデータを備え、
前記ドメインより通知された障害の復旧要求と、前記データとに基づいて、前記障害の復旧要求の許否を判別することを特徴とする請求項２６に記載の復旧装置。 - 前記データは、前記ドメインからの障害の復旧要求で示される処理内容毎に設定されたセキュリティレベルに基づいて設定されることを特徴とする請求項２７に記載の復旧装置。
- 前記復旧手段は、
前記ドメインから通知された障害の復旧要求の許否を判別する判別手段を備え、
前記判別手段で許可された復旧要求に基づいて、前記復旧対象のドメインにおける障害を、前記復旧対象のドメインへのデータ送信を介して検知し、障害が発生した前記ドメインに対して障害の復旧処理を行うことを特徴とする請求項２０から請求項２８のいずれか１項に記載の復旧装置。 - 複数のプロセッサで構成されるコンピュータ処理装置である情報処理装置上で実行され、前記情報処理装置の機能の復旧を実現するプログラムであって、
実行する処理内容に応じて、前記複数のプロセッサが複数のドメインを構成し、
異なるドメイン間のプロセッサ同士が互いに通信する通信機能と、
前記ドメインから通知される障害の復旧要求と、前記ドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行う復旧機能とを前記情報処理装置に持たせることを特徴とするプログラム。 - 前記複数のドメインを、実行する処理内容に応じて、特定ドメインと、他のドメインとに分離して構成し、
前記復旧機能が、前記特定ドメイン又は前記他のドメインから通知される障害の復旧要求と、前記特定ドメイン及び前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行う機能を前記情報処理装置に持たせることを特徴とする請求項３０に記載のプログラム。 - 前記特定ドメインがある一定のセキュリティレベル以上の処理を実行するドメインであり、前記他のドメインが、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、
前記特定ドメインが、前記他のドメインにおける障害を、前記他のドメインへの前記通信機能によるデータ送信を介して検知し、前記復旧機能に対して前記障害の復旧要求を行う機能を前記情報処理装置に持たせることを特徴とする請求項３０又は請求項３１に記載のプログラム。 - 前記特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、前記他のドメインが、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、
前記他のドメインが、何れかの前記他のドメインにおける障害を検知し、前記特定ドメインに前記他のドメインの障害の復旧要求を通知し、
前記特定ドメインが、前記他のドメインの障害を、前記他のドメインへの前記通信機能によるデータ送信を介して検知し、前記復旧機能に対して前記障害の復旧要求を行う機能を前記情報処理装置に持たせることを特徴とする請求項３０又は請求項３１に記載のプログラム。 - データ送信を介した障害の検知を、所定時間又は所定回数における前記データ送信先のドメインからの応答の有無によって行う機能と、
前記特定ドメインが、前記ある一定のセキュリティレベル以上の処理として、基本処理を実行する機能とを有し、
前記障害を検知する機能が、前記特定ドメインによる前記他のドメインへのデータ送信を介した障害を検知する場合に、前記所定時間より短い時間を設定すること又は前記所定回数よりも少ない回数を設定する機能を前記情報処理装置に持たせることを特徴とする請求項３２又は請求項３３に記載のプログラム。 - 前記特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、前記他のドメインが、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、
前記他のドメインが、何れかの前記他のドメインにおける障害を検知し、前記特定ドメインに前記他のドメインの障害の復旧要求を通知し、
前記特定ドメインが、前記復旧機能に対して前記障害の復旧要求を行う機能を前記情報処理装置に持たせることを特徴とする請求項３１に記載のプログラム。 - 前記特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、前記他のドメインが、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、
前記他のドメインが、何れかの前記他のドメインにおける障害を検知し、前記特定ドメインを介さずに前記復旧機能に対して前記障害の復旧要求を行い、
前記復旧機能が、前記他のドメインから通知される前記障害の復旧要求と、前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生した前記他のドメインに対して障害の復旧処理を行う機能を前記情報処理装置に持たせることを特徴とする請求項３１に記載のプログラム。 - 前記復旧条件は、前記ドメインからの障害の復旧要求で示される処理内容毎に設定されたセキュリティレベルに基づいて定められており、
前記復旧機能は、前記ドメインから通知された障害の復旧要求と、前記復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行う機能を前記情報処理装置に持たせることを特徴とする請求項３０から請求項３６のいずれか１項に記載のプログラム。 - 前記他のドメインを、実行する処理内容に応じて、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第１ドメインと、前記第１ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第２ドメインとに分離して構成し、
前記第１ドメインが、前記第２ドメインにおける障害を、前記第２ドメインへの前記通信機能によるデータ送信を介して検知し、前記特定ドメインに前記第２ドメインの障害の復旧要求を通知し、
前記特定ドメインが、前記復旧機能に対して前記障害の復旧要求を行う機能を前記情報処理装置に持たせることを特徴とする請求項３５又は請求項３７に記載のプログラム。 - 前記他のドメインを、実行する処理内容に応じて、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第１ドメインと、前記第１ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第２ドメインとに分離して構成し、
前記第１ドメインが、前記第２ドメインにおける障害を、前記第２ドメインへの前記通信機能によるデータ送信を介して検知し、前記特定ドメインを介さずに前記復旧機能に前記第２ドメインの障害の復旧要求を通知し、
前記復旧機能が、前記第１ドメインから通知される前記障害の復旧要求と、前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生した前記第２ドメインに対して障害の復旧処理を行う機能を前記情報処理装置に持たせることを特徴とする請求項３６又は請求項３７に記載のプログラム。 - 前記他のドメインを、実行する処理内容に応じて、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第１ドメインと、前記第１ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第２ドメインとに分離して構成し、
前記第２ドメインが、前記第１ドメインにおける障害を、前記第１ドメインへの前記通信機能によるデータ送信を介して検知し、前記特定ドメインに前記第１ドメインの障害の復旧要求を通知し、
前記特定ドメインが、第１ドメインの障害を、前記第１ドメインへの前記通信機能によるデータ送信を介して検知し、前記復旧機能に対して前記障害の復旧要求を行う機能を前記情報処理装置に持たせることを特徴とする請求項３３又は請求３７に記載のプログラム。 - 前記他のドメインを、実行する処理内容に応じて、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第１ドメインと、前記第１ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第２ドメインとに分離して構成し、
前記第２ドメインが、前記第１ドメインにおける障害を、前記第１ドメインへの前記通信機能によるデータ送信によって検知し、前記特定ドメインを介さずに前記復旧機能に前記第１ドメインの障害の復旧要求を通知し、
前記復旧機能が、第１ドメインの障害を、前記第１ドメインへの前記通信機能によるデータ送信を介して検知し、前記第２ドメインから通知される前記障害の復旧要求と、前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生した前記第１ドメインに対して障害の復旧処理を行う機能を前記情報処理装置に持たせることを特徴とする請求項３６又は請求項３７に記載のプログラム。 - データ送信を介した障害の検知を、所定時間又は所定回数の前記データ送信先のドメインからの応答の有無によって行う機能を有し、
前記障害を検知する機能が、前記第２ドメインによる前記第１ドメインへのデータ送信を介した障害の検知を行う場合に、前記所定時間より長い時間を設定すること又は前記所定回数よりも多い回数を設定する機能を前記情報処理装置に持たせることを特徴とする請求項４０又は請求項４１に記載のプログラム。 - 前記復旧機能は、前記特定ドメインからの復旧要求を無条件で受け付け、前記他のドメインからの復旧要求は拒否する機能を前記情報処理装置に持たせることを特徴とする請求項３１から請求項４２のいずれか１項に記載のプログラム。
- 前記復旧機能は、前記ドメインから障害の復旧要求が通知されると、復旧対象のドメインにおける障害を、前記復旧対象のドメインへのデータ送信を介して検知し、前記障害の復旧要求と、前記復旧条件とに基づいて、障害が発生した前記ドメインに対して障害の復旧処理を行う機能を前記情報処理装置に持たせることを特徴とする請求項３０から請求項４２のいずれか１項に記載のプログラム。
- 前記復旧機能が、
前記ドメインから通知された障害の復旧要求の許否を判別する判別機能を備え、
前記判別機能で許可された復旧要求に基づいて、障害が発生したドメインに対して障害の復旧処理を行う機能を前記情報処理装置に持たせることを特徴とする請求項３０から請求項４４のいずれか１項に記載のプログラム。 - 前記判別機能が、
前記ドメインより通知された障害の復旧要求と、前記ドメインの処理内容毎に設定されたセキュリティレベルとに基づいて、前記障害の復旧要求の許否を判別する機能を前記情報処理装置に持たせることを特徴とする請求項４５に記載のプログラム。 - 前記復旧機能が、
前記ドメインから通知された障害の復旧要求の拒否を判別する判別機能を備え、
前記判別機能で許可された復旧要求に基づいて、前記復旧対象のドメインにおける障害を、前記復旧対象のドメインへの前記通信機能によるデータ送信を介して検知し、障害が発生した前記ドメインに対して障害の復旧処理を行う機能を前記情報処理装置に持たせることを特徴とする請求項３０から請求項４２のいずれか１項に記載のプログラム。 - 複数のプロセッサで構成される情報処理装置の処理機能を復旧する復旧方法であって、
実行する処理内容に応じて、前記複数のプロセッサが複数のドメインを構成し、
異なるドメイン間のプロセッサ同士は、通信ステップを介して通信し、
前記ドメインから通知される障害の復旧要求と、前記ドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を、前記情報処理装置上の復旧手段で行う復旧ステップを有することを特徴とする復旧方法。 - 前記複数のドメインを、実行する処理内容に応じて、特定ドメインと、他のドメインとに分離して構成し、
前記復旧ステップで、前記特定ドメイン又は前記他のドメインから通知される障害の復旧要求と、前記特定ドメイン及び前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生したドメインに対して障害の復旧処理を行うことを特徴とする請求項４８に記載の復旧方法。 - 前記特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、前記他のドメインが、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、
前記特定ドメインが、前記他のドメインにおける障害を、前記他のドメインへの前記通信ステップによるデータ送信を介して検知する検知ステップと、
前記特定ドメインが、前記復旧手段に対して、前記検知ステップで検知した前記障害についての復旧要求を行うステップとを有することを特徴とする請求項４８又は請求項４９に記載の復旧方法。 - 前記特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、前記他のドメインが、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、
前記他のドメインが、何れかの前記他のドメインにおける障害を検知する検知ステップと、
前記他のドメインが、前記特定ドメインに、前記検知ステップで検知した前記他のドメインの障害についての復旧要求を通知する通知ステップと、
前記特定ドメインが、前記通知ステップで通知された前記他のドメインの障害を、前記他のドメインへの前記通信手段によるデータ送信を介して検知する検知ステップと、
前記特定ドメインが、前記復旧手段に対して、前記検知ステップで検知した前記障害についての復旧要求を行うステップとを有することを特徴とする請求項４８又は請求項４９に記載の復旧方法。 - データ送信を介した障害の検知を、所定時間又は所定回数における前記データ送信先のドメインからの応答の有無によって行うステップを有し、
前記特定ドメインが、前記ある一定のセキュリティレベル以上の処理として、基本処理を実行するドメインであり、
前記ステップは、前記特定ドメインによる前記他のドメインへのデータ送信を介した障害を検知する場合に、前記所定時間より短い時間又は前記所定回数よりも少ない回数で障害を検知することを特徴とする請求項５０又は請求項５１に記載の復旧方法。 - 前記特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、前記他のドメインが、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、
前記他のドメインが、何れかの前記他のドメインにおける障害を検知する検知ステップ
と、
前記他のドメインが、前記特定ドメインに、前記検知ステップで検知した前記他のドメインの障害についての復旧要求を通知する通知ステップと、
前記特定ドメインが、前記復旧手段に対して、前記通知ステップで通知された前記障害についての復旧要求を行うステップとを有することを特徴とする請求項４９に記載の復旧方法。 - 前記特定ドメインが、ある一定のセキュリティレベル以上の処理を実行するドメインであり、前記他のドメインが、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有するドメインであり、
前記他のドメインが、何れかの前記他のドメインにおける障害を検知する検知ステップと、
前記他のドメインが、前記特定ドメインを介さずに前記復旧手段に対して、前記検知ステップで検知した前記障害についての復旧要求を行うステップとを有し、
前記復旧ステップで、前記他のドメインから通知される前記障害の復旧要求と、前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生した前記他のドメインに対して障害の復旧処理を行うことを特徴とする請求項４９に記載の復旧方法。 - 前記復旧条件は、前記ドメインからの障害の復旧要求で示される処理内容毎に設定されたセキュリティレベルに基づいて定められており、
前記復旧ステップで、前記ドメインから通知された障害の復旧要求と、前記復旧条件とに基づいて、障害が発生した他のドメインに対して障害の復旧処理を行うことを特徴とする請求項４８から請求項５４のいずれか１項に記載の復旧方法。 - 前記他のドメインを、実行する処理内容に応じて、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第１ドメインと、前記第１ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第２ドメインとに分離して構成し、
前記第１ドメインが、前記第２ドメインにおける障害を、前記第２ドメインへの前記通信ステップによるデータ送信を介して検知する検知ステップと、
前記第１ドメインが、前記特定ドメインに、前記検知ステップで検知した前記第２ドメインの障害についての復旧要求を通知する通知ステップと、
前記特定ドメインが、前記復旧手段に対して、前記通知ステップで通知された前記障害についての復旧要求を行うステップとを有することを特徴とする請求項５３又は請求項５５に記載の復旧方法。 - 前記他のドメインを、実行する処理内容に応じて、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第１ドメインと、前記第１ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第２ドメインとに分離して構成し、
前記第１ドメインが、前記第２ドメインにおける障害を、前記第２ドメインへの前記通信ステップによるデータ送信を介して検知する検知ステップと、
前記特定ドメインが、前記特定ドメインを介さずに前記復旧手段に、前記検知ステップで検知した前記第２ドメインの障害についての復旧要求を通知する通知ステップとを有し
前記復旧ステップで、前記第１ドメインから通知される前記障害の復旧要求と、前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生した前記第２ドメインに対して障害の復旧処理を行うことを特徴とする請求項５４又は請求項５５に記載の復旧方法。 - 前記他のドメインを、実行する処理内容に応じて、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第１ドメインと、前記第１ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第２ドメインとに分離して構成し、
前記第２ドメインが、前記第１ドメインにおける障害を、前記第１ドメインへの通信ステップによるデータ送信を介して検知する検知ステップと、
前記第２ドメインが、前記特定ドメインに、前記検知ステップで検知した前記第１ドメインの障害についての復旧要求を通知する通知ステップと、
前記特定ドメインが、前記通知ステップで通知された第１ドメインの障害を、前記第１ドメインへの前記通信ステップによるデータ送信を介して検知する検知ステップと、
前記特定ドメインが、前記復旧手段に対して、前記検知ステップで検知した前記障害についての復旧要求を行うステップとを有することを特徴とする請求項５１又は請求項５５に記載の復旧方法。 - 前記他のドメインを、実行する処理内容に応じて、前記特定ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第１ドメインと、前記第１ドメインで実行される処理よりもセキュリティレベルの低い処理を少なくとも一以上有する第２ドメインとに分離して構成し、
前記第２ドメインが、前記第１ドメインにおける障害を、前記第１ドメインへの前記通信ステップによるデータ送信を介して検知する検知ステップと、
前記第２ドメインが、前記特定ドメインを介さずに前記復旧手段に、前記検知ステップで検知した前記第１ドメインの障害についての復旧要求を通知する通知ステップと、
前記復旧ステップで、第１ドメインの障害を、前記第１ドメインへの前記通信ステップによるデータ送信を介して検知し、前記第２ドメインから通知される前記障害の復旧要求と、前記他のドメイン毎に予め設定された復旧条件とに基づいて、障害が発生した前記第１ドメインに対して障害の復旧処理を行うことを特徴とする請求項５４又は請求項５５に記載の復旧方法。 - データ送信を介した障害の検知を、所定時間又は所定回数における前記データ送信先のドメインからの応答の有無によって行うステップを有し、
前記ステップは、前記第２ドメインによる前記第１ドメインへのデータ送信を介した障害を検知する場合に、前記所定時間より長い時間又は前記所定回数よりも多い回数で障害を検知することを特徴とする請求項５８又は請求項５９に記載の復旧方法。 - 前記復旧ステップで、前記特定ドメインからの復旧要求を無条件で受け付け、前記他のドメインからの復旧要求は拒否することを特徴とする請求項４９から請求項５０のいずれか１項に記載の復旧方法。
- 前記復旧手段が、前記ドメインから障害の復旧要求が通知されると、復旧対象のドメインにおける障害を、前記復旧対象のドメインへの前記通信ステップによるデータ送信を介して検知する検知ステップを有し、
前記検知ステップで検知した以降に、前記復旧ステップで、前記障害の復旧要求と、前記復旧条件とに基づいて、障害が発生した前記ドメインに対して障害の復旧処理を行うことを特徴とする請求項４８から請求項５０のいずれか１項に記載の復旧方法。 - 前記復旧ステップで、
前記復旧手段が前記ドメインから通知された障害の復旧要求の許否を判別する判別ステップで許可された復旧要求に基づいて、障害が発生したドメインに対して障害の復旧処理を行うことを特徴とする請求項４８から請求項６２のいずれか１項に記載の復旧方法。 - 前記判別ステップで、
前記ドメインより通知された障害の復旧要求と、前記ドメインの処理内容毎に設定されたセキュリティレベルとに基づいて、前記障害の復旧要求の許否を判別することを特徴とする請求項６３に記載の復旧方法。 - 前記復旧ステップで、
前記復旧手段が前記ドメインから通知された障害の復旧要求を判別する判別ステップで許可された復旧要求に基づいて、前記復旧対象のドメインにおける障害を、前記復旧対象のドメインへの前記通信ステップによるデータ送信を介して検知し、障害が発生した前記ドメインに対して障害の復旧処理を行うことを特徴とする請求項４８から請求項６０のいずれか１項に記載の復旧方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2005177811 | 2005-06-17 | ||
| JP2005177811 | 2005-06-17 | ||
| PCT/JP2006/303920 WO2006134691A1 (ja) | 2005-06-17 | 2006-02-23 | 情報処理装置、復旧装置、プログラム及び復旧方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2006134691A1 true JPWO2006134691A1 (ja) | 2009-01-08 |
| JP4556144B2 JP4556144B2 (ja) | 2010-10-06 |
Family
ID=37532060
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007521111A Expired - Fee Related JP4556144B2 (ja) | 2005-06-17 | 2006-02-23 | 情報処理装置、復旧装置、プログラム及び復旧方法 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US8365021B2 (ja) |
| JP (1) | JP4556144B2 (ja) |
| CN (1) | CN101198934B (ja) |
| WO (1) | WO2006134691A1 (ja) |
Families Citing this family (67)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9495538B2 (en) * | 2008-09-25 | 2016-11-15 | Symantec Corporation | Graduated enforcement of restrictions according to an application's reputation |
| WO2011104824A1 (ja) | 2010-02-23 | 2011-09-01 | 富士通株式会社 | マルチコアプロセッサシステム、制御プログラム、および制御方法 |
| US8555265B2 (en) | 2010-05-04 | 2013-10-08 | Google Inc. | Parallel processing of data |
| US9104837B1 (en) | 2012-06-18 | 2015-08-11 | Bromium, Inc. | Exposing subset of host file systems to restricted virtual machines based on upon performing user-initiated actions against host files |
| US9135038B1 (en) | 2010-05-28 | 2015-09-15 | Bromium, Inc. | Mapping free memory pages maintained by a guest operating system to a shared zero page within a machine frame |
| US9558051B1 (en) | 2010-05-28 | 2017-01-31 | Bormium, Inc. | Inter-process communication router within a virtualized environment |
| US9148428B1 (en) | 2011-05-25 | 2015-09-29 | Bromium, Inc. | Seamless management of untrusted data using virtual machines |
| US9767274B2 (en) | 2011-11-22 | 2017-09-19 | Bromium, Inc. | Approaches for efficient physical to virtual disk conversion |
| US10095530B1 (en) | 2010-05-28 | 2018-10-09 | Bromium, Inc. | Transferring control of potentially malicious bit sets to secure micro-virtual machine |
| US10310696B1 (en) | 2010-05-28 | 2019-06-04 | Bromium, Inc. | Supporting a consistent user interface within a virtualized environment |
| US9386021B1 (en) | 2011-05-25 | 2016-07-05 | Bromium, Inc. | Restricting network access to untrusted virtual machines |
| US8752047B2 (en) | 2010-05-28 | 2014-06-10 | Bromium, Inc. | Automated management of virtual machines to process untrusted data based on client policy information |
| US8972980B2 (en) | 2010-05-28 | 2015-03-03 | Bromium, Inc. | Automated provisioning of secure virtual execution environment using virtual machine templates based on requested activity |
| US9116733B2 (en) | 2010-05-28 | 2015-08-25 | Bromium, Inc. | Automated provisioning of secure virtual execution environment using virtual machine templates based on requested activity |
| US9239909B2 (en) | 2012-01-25 | 2016-01-19 | Bromium, Inc. | Approaches for protecting sensitive data within a guest operating system |
| US9069622B2 (en) | 2010-09-30 | 2015-06-30 | Microsoft Technology Licensing, Llc | Techniques for load balancing GPU enabled virtual machines |
| US8970603B2 (en) | 2010-09-30 | 2015-03-03 | Microsoft Technology Licensing, Llc | Dynamic virtual device failure recovery |
| US8931042B1 (en) * | 2010-12-10 | 2015-01-06 | CellSec, Inc. | Dividing a data processing device into separate security domains |
| US10511630B1 (en) * | 2010-12-10 | 2019-12-17 | CellSec, Inc. | Dividing a data processing device into separate security domains |
| US9105009B2 (en) | 2011-03-21 | 2015-08-11 | Microsoft Technology Licensing, Llc | Email-based automated recovery action in a hosted environment |
| US10546118B1 (en) | 2011-05-25 | 2020-01-28 | Hewlett-Packard Development Company, L.P. | Using a profile to provide selective access to resources in performing file operations |
| US9921860B1 (en) | 2011-05-25 | 2018-03-20 | Bromium, Inc. | Isolation of applications within a virtual machine |
| US10846396B1 (en) | 2011-05-25 | 2020-11-24 | Hewlett-Packard Development Company, L.P. | Downloading data in a dedicated virtual machine |
| US8839245B1 (en) | 2012-06-18 | 2014-09-16 | Bromium, Inc. | Transferring files using a virtualized application |
| US8923147B2 (en) * | 2011-10-03 | 2014-12-30 | Qualcomm Incorporated | Method and apparatus for filtering and processing received vehicle peer transmissions based on reliability information |
| JP5583857B2 (ja) * | 2011-11-04 | 2014-09-03 | エスケー プラネット カンパニー、リミテッド | セキュアドメインとノーマルドメインとの間の保安連動方法及び保安アプリケーションダウンロードの管理方法、管理サーバー、端末機、及びこれを適用した管理システム |
| US20130133024A1 (en) * | 2011-11-22 | 2013-05-23 | Microsoft Corporation | Auto-Approval of Recovery Actions Based on an Extensible Set of Conditions and Policies |
| US9460303B2 (en) | 2012-03-06 | 2016-10-04 | Microsoft Technology Licensing, Llc | Operating large scale systems and cloud services with zero-standing elevated permissions |
| US9245108B1 (en) | 2012-03-13 | 2016-01-26 | Bromium, Inc. | Dynamic adjustment of the file format to identify untrusted files |
| JP2013225208A (ja) * | 2012-04-20 | 2013-10-31 | Toyota Motor Corp | 情報処理装置、情報処理方法、及びプログラム |
| US9384026B1 (en) | 2012-06-18 | 2016-07-05 | Bromium, Inc. | Sharing and injecting cookies into virtual machines for retrieving requested web pages |
| US10095662B1 (en) | 2012-06-18 | 2018-10-09 | Bromium, Inc. | Synchronizing resources of a virtualized browser |
| US9734131B1 (en) | 2012-06-18 | 2017-08-15 | Bromium, Inc. | Synchronizing history data across a virtualized web browser |
| US9201850B1 (en) | 2012-06-18 | 2015-12-01 | Bromium, Inc. | Composing the display of a virtualized web browser |
| US11023088B2 (en) | 2012-06-18 | 2021-06-01 | Hewlett-Packard Development Company, L.P. | Composing the display of a virtualized web browser |
| US9727534B1 (en) | 2012-06-18 | 2017-08-08 | Bromium, Inc. | Synchronizing cookie data using a virtualized browser |
| US9294508B2 (en) | 2012-08-02 | 2016-03-22 | Cellsec Inc. | Automated multi-level federation and enforcement of information management policies in a device network |
| US10305937B2 (en) * | 2012-08-02 | 2019-05-28 | CellSec, Inc. | Dividing a data processing device into separate security domains |
| US9152577B2 (en) * | 2012-08-17 | 2015-10-06 | Broadcom Corporation | Security central processing unit management of a transcoder pipeline |
| US8881249B2 (en) | 2012-12-12 | 2014-11-04 | Microsoft Corporation | Scalable and automated secret management |
| US9141454B2 (en) * | 2012-12-27 | 2015-09-22 | Intel Corporation | Signaling software recoverable errors |
| US9292328B2 (en) | 2013-05-24 | 2016-03-22 | Bromium, Inc. | Management of supervisor mode execution protection (SMEP) by a hypervisor |
| US9483352B2 (en) * | 2013-09-27 | 2016-11-01 | Fisher-Rosemont Systems, Inc. | Process control systems and methods |
| US10599565B2 (en) | 2013-12-24 | 2020-03-24 | Hewlett-Packard Development Company, L.P. | Hypervisor managing memory addressed above four gigabytes |
| US10430614B2 (en) | 2014-01-31 | 2019-10-01 | Bromium, Inc. | Automatic initiation of execution analysis |
| AU2015240467B2 (en) | 2014-04-04 | 2019-07-11 | CellSec, Inc. | Method for authentication and assuring compliance of devices accessing external services |
| US9680873B1 (en) | 2014-06-30 | 2017-06-13 | Bromium, Inc. | Trusted network detection |
| US10311122B1 (en) | 2014-08-22 | 2019-06-04 | Bromium, Inc. | On-demand unprotected mode access |
| US9697141B2 (en) * | 2014-10-17 | 2017-07-04 | Sk Hynix Memory Solutions Inc. | LBA blocking table for SSD controller |
| US9762585B2 (en) | 2015-03-19 | 2017-09-12 | Microsoft Technology Licensing, Llc | Tenant lockbox |
| US10931682B2 (en) | 2015-06-30 | 2021-02-23 | Microsoft Technology Licensing, Llc | Privileged identity management |
| US9448887B1 (en) * | 2015-08-22 | 2016-09-20 | Weka.IO Ltd. | Distributed erasure coded virtual file system |
| CN105227366B (zh) * | 2015-10-15 | 2018-08-31 | 深圳市金证科技股份有限公司 | 维护分布式数据的一致性的方法及系统 |
| DE102017209806A1 (de) * | 2017-06-09 | 2018-12-13 | Robert Bosch Gmbh | Verfahren und Vorrichtung zum Erkennen von Angriffen auf einen Feldbus |
| US11301433B2 (en) | 2017-11-13 | 2022-04-12 | Weka.IO Ltd. | Metadata journal in a distributed storage system |
| US11061622B2 (en) | 2017-11-13 | 2021-07-13 | Weka.IO Ltd. | Tiering data strategy for a distributed storage system |
| US11262912B2 (en) | 2017-11-13 | 2022-03-01 | Weka.IO Ltd. | File operations in a distributed storage system |
| US10936405B2 (en) | 2017-11-13 | 2021-03-02 | Weka.IO Ltd. | Efficient networking for a distributed storage system |
| US11782875B2 (en) | 2017-11-13 | 2023-10-10 | Weka.IO Ltd. | Directory structure for a distributed storage system |
| US11216210B2 (en) | 2017-11-13 | 2022-01-04 | Weka.IO Ltd. | Flash registry with on-disk hashing |
| US11385980B2 (en) | 2017-11-13 | 2022-07-12 | Weka.IO Ltd. | Methods and systems for rapid failure recovery for a distributed storage system |
| US11561860B2 (en) | 2017-11-13 | 2023-01-24 | Weka.IO Ltd. | Methods and systems for power failure resistance for a distributed storage system |
| JP6776292B2 (ja) * | 2018-03-20 | 2020-10-28 | 株式会社東芝 | 情報処理装置、情報処理方法、およびプログラム |
| US11099925B2 (en) | 2018-07-10 | 2021-08-24 | EMC IP Holding Company LLC | Datacenter preemptive measures for improving protection using IoT sensors |
| US11106528B2 (en) * | 2018-10-10 | 2021-08-31 | EMC IP Holding Company LLC | Datacenter IoT-triggered preemptive measures using machine learning |
| US11741196B2 (en) | 2018-11-15 | 2023-08-29 | The Research Foundation For The State University Of New York | Detecting and preventing exploits of software vulnerability using instruction tags |
| CN115859252B (zh) * | 2023-02-27 | 2023-05-12 | 南京芯驰半导体科技有限公司 | 认证信息处理方法、装置、电子设备、存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04275663A (ja) * | 1991-03-04 | 1992-10-01 | Nec Corp | 障害プロセッサの判定方式 |
| JP2000276364A (ja) * | 1999-03-24 | 2000-10-06 | Oki Electric Ind Co Ltd | 障害復旧方法、中央処理装置及び中央処理システム |
| JP2004062535A (ja) * | 2002-07-29 | 2004-02-26 | Nec Corp | マルチプロセッサシステムの障害処理方法、マルチプロセッサシステム及びノード |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06332864A (ja) | 1993-05-27 | 1994-12-02 | Fujitsu Ltd | マルチプロセッサシステムにおけるｃｐｕ間通信方式 |
| US6718482B2 (en) * | 1997-09-12 | 2004-04-06 | Hitachi, Ltd. | Fault monitoring system |
| AU9094198A (en) | 1998-09-10 | 2000-04-03 | Sanctum Ltd. | Method and system for maintaining restricted operating environments for application programs or operating systems |
| FI109154B (fi) | 1999-04-16 | 2002-05-31 | Vesa Juhani Hukkanen | Laite ja menetelmä tietoturvallisuuden parantamiseksi |
| JP2001154999A (ja) | 1999-11-30 | 2001-06-08 | Hitachi Ltd | 並列計算機システム及びその立上げ処理方法 |
| US6507904B1 (en) | 2000-03-31 | 2003-01-14 | Intel Corporation | Executing isolated mode instructions in a secure system running in privilege rings |
| US7222268B2 (en) * | 2000-09-18 | 2007-05-22 | Enterasys Networks, Inc. | System resource availability manager |
| US6892331B2 (en) * | 2002-01-17 | 2005-05-10 | International Business Machines Corporation | Method and system for error detection in a managed application environment |
| US20060004667A1 (en) * | 2004-06-30 | 2006-01-05 | Microsoft Corporation | Systems and methods for collecting operating system license revenue using an emulated computing environment |
| US8788673B2 (en) * | 2004-09-13 | 2014-07-22 | Microsoft Corporation | Systems and methods for providing security through sessions |
| US7409719B2 (en) * | 2004-12-21 | 2008-08-05 | Microsoft Corporation | Computer security management, such as in a virtual machine or hardened operating system |
| BRPI0613956A2 (pt) * | 2005-06-28 | 2011-02-22 | Matsushita Electric Ind Co Ltd | método de verificação, dispositivo de processamento de informação, meio de gravação, sistema de verificação, programa de certificação e programa de verificação |
| JP4809209B2 (ja) * | 2006-12-28 | 2011-11-09 | 株式会社日立製作所 | サーバ仮想化環境における系切り替え方法及び計算機システム |
-
2006
- 2006-02-23 US US11/921,742 patent/US8365021B2/en active Active
- 2006-02-23 CN CN2006800210569A patent/CN101198934B/zh not_active Expired - Fee Related
- 2006-02-23 WO PCT/JP2006/303920 patent/WO2006134691A1/ja active Application Filing
- 2006-02-23 JP JP2007521111A patent/JP4556144B2/ja not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04275663A (ja) * | 1991-03-04 | 1992-10-01 | Nec Corp | 障害プロセッサの判定方式 |
| JP2000276364A (ja) * | 1999-03-24 | 2000-10-06 | Oki Electric Ind Co Ltd | 障害復旧方法、中央処理装置及び中央処理システム |
| JP2004062535A (ja) * | 2002-07-29 | 2004-02-26 | Nec Corp | マルチプロセッサシステムの障害処理方法、マルチプロセッサシステム及びノード |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2006134691A1 (ja) | 2006-12-21 |
| US8365021B2 (en) | 2013-01-29 |
| US20090119541A1 (en) | 2009-05-07 |
| JP4556144B2 (ja) | 2010-10-06 |
| CN101198934A (zh) | 2008-06-11 |
| CN101198934B (zh) | 2010-09-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4556144B2 (ja) | 情報処理装置、復旧装置、プログラム及び復旧方法 | |
| JP4811271B2 (ja) | 情報通信装置及びプログラム実行環境制御方法 | |
| CN109918919B (zh) | 认证变量的管理 | |
| JP4883459B2 (ja) | ポイントツーポイント相互接続システム上のセキュアな環境初期化命令の実行 | |
| US7073059B2 (en) | Secure machine platform that interfaces to operating systems and customized control programs | |
| US8458791B2 (en) | Hardware-implemented hypervisor for root-of-trust monitoring and control of computer system | |
| US10095862B2 (en) | System for executing code with blind hypervision mechanism | |
| US7730249B2 (en) | Device control apparatus that calls an operating system to control a device | |
| US20070266444A1 (en) | Method and System for Securing Data Stored in a Storage Device | |
| ES2615860T3 (es) | Sistema y procedimiento de aseguramiento de un ordenador que incluye un micronúcleo | |
| CN112818327A (zh) | 基于TrustZone的用户级代码和数据安全可信保护方法及装置 | |
| JP2010508572A (ja) | トラステッドプラットフォームモジュールを共有するためのシステム及び方法 | |
| JP2020042341A (ja) | プロセッシングデバイス及びソフトウェア実行制御方法 | |
| US11461490B1 (en) | Systems, methods, and devices for conditionally allowing processes to alter data on a storage device | |
| US20230098991A1 (en) | Systems, methods, and media for protecting applications from untrusted operating systems | |
| Wan | Hardware-Assisted Security Mechanisms on Arm-Based Multi-Core Processors | |
| Leroux | Secure by design: Using a microkernel rtos to build secure, fault-tolerant systems | |
| WO2006059335A1 (en) | Method and system for securing data stored in a storage device | |
| GB2412465A (en) | Resetting a register on receipt of a locality confirming message |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20091001 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091130 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100426 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100601 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100624 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100707 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4556144 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130730 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |