(57)【要約】資源が制約されたモバイル計算装置のソフトウェアプログラムを開発する方法は、システムをモデル化することを可能にする３つの必須コード型のコードから成るライブラリを使用する工程を含み、３つのコード型は、（ａ）２つのエンドの間の生２進データの送信を定義する第１の再利用可能オブジェクト、（ｂ）順序付き名前／値対を定義する第２の再利用可能オブジェクト、及び（ｃ）第１及び第２のオブジェクト又はそのいずれかを処理するタスクをどのように書き込み、作成、呼び出し又は使用すべきかを定義する抽象ＡＰＩ定義である。この非常に高いレベルの抽象化は、驚くべきことに、出願人により解析されたほぼ全てのシステムに適用できることがわかっている。従って、本発明により、「プリミティブ」の小さな（慎重に制限された）コアライブラリを一旦構築すれば、様々に異なるアプリケーションにより基礎的要素として非常に多くの回数にわたり再利用することが可能になる。高レベル抽象化を定義するコードの再利用はコードサイズを全体として相当に大きく縮小し（モバイル計算装置にとっての主要な技術的利点）、新たなプログラムの開発をスピードアップする（モバイル計算装置用のプログラム開発という急速に変化する世界における主要な技術的利点）。
2005506631.tif 000002
【特許請求の範囲】
【請求項１】
資源が制約されたモバイル計算装置のソフトウェアプログラムを開発する方法であって、システムをモデル化することを可能にする３つの必須コード型のコードからなるライブラリを使用する工程を含み、前記３つのコード型は、
（ａ）２つのエンドの間の生２進データの送信を定義する第１の再利用可能オブジェクトと、
（ｂ）順序付き名前／値対を定義する第２の再利用可能オブジェクトと、
（ｃ）第１及び第２のオブジェクト又はそのいずれかを処理するタスクをどのように書き込み、作成し、呼び出し又は使用すべきかを定義する抽象ＡＰＩ定義である方法。
【請求項２】
前記３つの必須コード方のうちの一部又は全ては複数の異なるプログラムを迅速に開発することを可能にするために再利用可能である請求項１記載の方法。
【請求項３】
前記再利用可能オブジェクト及び前記タスクはモバイル計算装置のＲＯＭに焼き付けられる請求項１記載の方法。
【請求項４】
プログラムが追加コードに定義済みタスクを達成することを要求し、その追加コードは再利用可能タスクとして実装され、ＲＯＭに焼き付けられるか又はＲＡＭで実行される請求項３記載の方法。
【請求項５】
タスクは、そのタスクが実行時に他のどのタスクを必要とするかに関する決定を行う請求項１記載の方法。
【請求項６】
他のタスクは最初の出荷後に装置に追加される請求項５記載の方法。
【請求項７】
前記第１のオブジェクトは、
（ａ）単方向、
（ｂ）プロセス間／スレッド間能力、
（ｃ）バッファ付き、
（ｄ）２進データを処理し、コンテンツ／フォーマットを認識しない、
（ｅ）無限又は有限コンテンツ長を扱う、という特性を有するパイプとして実現される請求項１記載の方法。
【請求項８】
前記第２のオブジェクトは、
（ａ）名前／値対を含み、
（ｂ）名前は大文字と小文字とが区別され、
（ｃ）値は、ストリング、２進「ブロブ」、パイプエンド及び他のバンドルを含み、
（ｄ）複製が許可され、
（ｅ）順序付き、という特性を有するバンドルとして実現される請求項１記載の方法。
【請求項９】
タスクはＡＰＩにより、
（ａ）名前を有し、従って、その名前を指定することによりインスタンスを作成でき、
（ｂ）最初に作成されるときに実行中ではなく、
（ｃ）呼び出されるべきタスクの名前を指定することにより、タスクのインスタンスが作成され、
（ｄ）一旦作成された後は起動可能であり、
（ｅ）実際の起動の通知が提供され、
（ｆ）「リターンコード」により中止することができ、
（ｇ）終了及びリターンコードを「オーナ」に通知することができるという特性を有するものとして定義される請求項１記載の方法。
【請求項１０】
前記第１及び第２のオブジェクトを作成して所有し、かつ前記タスクを開始して所有するマネージャプロセスを使用する過程を含む請求項１記載の方法。
【請求項１１】
前記オブジェクト及び前記タスクを作成又は制御するマネージャプロセスが存在する請求項１記載の方法。
【請求項１２】
前記マネージャプロセスは、オブジェクトに対するアクセスをクライアントセッションに要求させる請求項１１記載の方法。
【請求項１３】
前記マネージャプロセスはオブジェクトをアクセスするための視覚付与を実行する請求項１２記載の方法。
【請求項１４】
前記クライアントセッションは、別のクライアントセッションがオブジェクトをアクセスするための資格付与を変更することを前記マネージャプロセスに要求する請求項１３記載の方法。
【請求項１５】
前記マネージャプロセスはオブジェクトをハンドルによって外部に公開する請求項１２記載の方法。
【請求項１６】
請求項１から１５の方法を使用して開発されたプログラムによってプログラミングされたモバイル計算装置。
【請求項１７】
請求項１から１５の方法を使用して開発されたソフトウェアプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パーソナルオーガナイザ、携帯電話及びコミュニケータなどの資源が制約されたモバイル計算装置のソフトウェアプログラムを開発する方法に関する。
【背景技術】
【０００２】
モバイル計算装置では、（ａ）最小限のサイズを占有してコストのかかるＲＯＭ占有を低減し、かつ（ｂ）迅速に実行して電力消費を最小にすることがプログラムに要求され、プログラム開発担当者には過酷な設計制約が課される。従来、この装置で実行されるオペレーティングシステムでは、アプリケーションコードサイズを最小にするように設計された様々なコード作成技法が不可欠である（例えば、モバイル計算装置に関してSymbian  ＯＳを最適化するために設計された、ＰＣＴ／ＧＢ９８／０１７１７に記載されている記述子技法を参照）。しかし、この分野で仕事をしているプログラム開発担当者は、通常、依然として、モバイル計算装置と同じ制約を受けることのないＰＣや他の装置におけるプログラムの作成に適した開発方法を用いている。
【０００３】
例えば、モバイル計算装置用のウェブサーバを作成する場合、あるプログラマは、通常、（ａ）ＨＴＴＰ要求を解析するためのコード、及び（ｂ）ＨＴＴＰ応答として戻されるべきＨＴＭＬコンテンツをフェッチ／生成するための追加コードを作成する。別のプログラマは、ＷＡＰ又はＯＢＥＸコンテンツとして利用されるべきＷＡＰ又はＯＢＥＸサーバを書き込んでいる場合、（ａ）ＷＡＰ又はＯＢＥＸ要求を解析するためのコード、及び（ｂ）戻されるべきコンテンツをフェッチ／生成するための追加コードを作成する。従って、ウェブと、ＷＡＰと、ＯＢＥＸとでは要求フォーマット及びデータフォーマットが異なるため、データ要求を実行し、ファンクションをフェッチするために多くの場合に異なるコードが作成されることになる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
異なるアプリケーションによって共有可能なコードライブラリにより、不要な重複に理論上は対処できるであろうが、現在のプログラム開発方法論によれば、現在のプログラム開発方法論では、これは実現されていないであろうというのが実務上の現実である。なぜなら、開発担当者はウェブサーバとＯＢＥＸサーバとが共通して何を有しているかを明確に見通すことが不可能であるためである。言い換えれば、現在のソフトウェア開発方法論は、開発担当者が様々に異なるプロセスの間で共通しているものが何であるかを見通し、従って、それらのプロセスにまたがって再利用可能であるコードの作成を可能にする十分に深い（すなわち、最も単純な）レベルの抽象化を課すことができていない。
【０００５】
これまで、コンピュータ科学は様々な深さでソフトウェアプロセスの抽象化を提示してきた。おそらく、それらのうちで最も有名であるのは、「０」又は「１」とラベル付けされた複数のセクションに分割された無限のテープを走査する読み取り／書き込みヘッドを具備するチューリングマシンである。チューリングマシンはコンピュータ科学の歴史及び精神の哲学における画期的な出来事であるが、現実の世界の装置のためのプログラムを設計するに際して実際にはほとんど役に立たない。
【０００６】
本発明が扱う技術的問題は、資源が制約されたモバイル計算装置に関してプログラムを迅速且つ効率良く開発することを可能にする新たなソフトウェア開発方法をいかにして考案するかということである。
【課題を解決するための手段】
【０００７】
本発明の第１の面においては、資源が制約されたモバイル計算装置のソフトウェアプログラムを開発する方法は、システムをモデル化することを可能にする３つの必須コード型のコードから成るライブラリを使用する工程を含み、前記３つのコード型は、
（ａ）書き込みエンドと読出しエンドとの間の生２進データの送信を定義する第１の再利用可能オブジェクトと、
（ｂ）順序付き名前／値対を定義する第２の再利用可能オブジェクトと、
（ｃ）第１及び第２又はそのいずれかのオブジェクトを処理するタスクをどのように書き込み、作成、呼び出し又は使用すべきかを定義する抽象ＡＰＩ定義とである。
【０００８】
この請求の範囲において使用されている技術用語はその通常の意味に従って解釈されるべきである。オブジェクトは、個別のエンティティとして処理できる何らかの変数である。タスク（ＡＰＩの定義に従った「モジュール」又はコンポーネントの１つの型である）は、ＤＬＬなどの実行可能コードの自己完結型名前付きブロック、又はスクリプトである。その役割は第１及び第２のオブジェクトを処理することである。
【０００９】
この非常に高いレベルの抽象化は、驚くべきことに、出願人により解析されたほぼ全てのシステムに当てはまることがわかっている。従って、本発明により、基本ビルディングブロック、すなわち、「プリミティブ」の小さな（慎重に制限された）コアライブラリを一旦構築すれば、様々に異なるアプリケーションにおいて非常に多くの回数にわたり再利用することができる。高レベル抽象化を定義するコードの再利用は、コードサイズを全体として相当縮小し（モバイル計算装置にとって主要な技術的利点）、新たなプログラムの開発をスピードアップする（モバイル計算装置用のプログラム開発という急速に変化する世界における主要な技術的利点）。
【００１０】
そこで、アプリケーション開発担当者は、完成したアプリケーションを配信するために追加コード、すなわち、「グルー」論理を作成すること（元来の全体的な問題と比較すると取るに足りない場合が多い。）に集中できる。「グルー」論理又はコードはプリミティブに基づいており、コードをある所定のシステム又は目的に固有なものにするレベルを表現する（ただし、それ自体は再利用可能であっても良い）。これにより、アプリケーション開発は迅速で、効率良く、着実なものになる。
【００１１】
総じて、３つのプリミティブと関連する非常に高レベルの抽象化を強制することにより、実際に、少数の先に定義したプリミティブを使用して非常に様々に異なる（任意の複雑さを有する）システムを構築できることがわかっている。これらのプリミティブはごくわずかなコード空間しか占めていない。これは、共通プリミティブ（すなわち、ウェブサーバ、ＷＡＰサーバ及びＯＢＥＸサーバなどのいくつかのアプリケーションに共通する。）をＲＯＭに焼き付けることが可能であることを意味している。更に、それらのプリミティブを、資源を効率的に利用して呼び出すことができる。
【００１２】
出願人が知っている他のどのソフトウェア開発方法論、計算環境、オペレーティングシステム又は言語も、これと同じほど厳格な汎用高レベル抽象化方式を課していない。先に定義した３つの必須コード型は最適であることがわかっている。更に別のコード型を追加し、その仕様が必須であると指定することは、３つの必須コード型の基礎に基づいているために本発明の範囲内には入っているが、一般にそれほど最適とは言えない。
【００１３】
本発明の商用の実施品は英国ロンドンのIntuwave Limitedから入手可能である。これはmStreamと呼ばれている。mStreamの場合、第１のオブジェクトは「パイプ」と呼ばれる。第２のオブジェクトは「バンドル」と呼ばれる。mStreamは、パイプ及びバンドル又はそのいずれかを処理するタスクをいかにして書き込み、作成し、呼び出し又は使用すべきかを定義する抽象ＡＰＩ定義に従った「タスク」（「パイププロセッサ」としても知られている。）を実現するために使用することができるライブラリのセットを含む。
【００１４】
mStreamを使用して、m-Surfと呼ばれるウェブサーバが構築されている。m-Surfでは、第１のプリミティブオブジェクト（パイプ）は、構文解析されていないコンテンツデータがいかにして図１のＡからＦを介してトンネリングされるかを定義する（Ａ、Ｂの各々はパイプである。パイプおよび関連するグルー論理の集合体はパイプラインである）。第２のプリミティブオブジェクトすなわちバンドルは、構造化要求がいかにしてシステムを通して渡されて行くかを定義し、最後のＡＰＩプリミティブはタスク（及び他の非タスク）モジュールがいかにして書き込まれ、呼び出されるかを定義する。
【００１５】
第１のグルーコードは、ＴＣＰ／ＩＰと第１のオブジェクト（「パイプＡ」）との間で変換するTcpListener１である。ＴＣＰリスナ１はタスクとして実現されることが可能であろう（グルー論理は一般にタスクとして実現されるが、従来のモジュールであっても良い）。別のグルーコードはIHttpSvr２として実現される。これはパイプＡからデータを読み取り、そのデータをＨＴＴＰとして解釈し、第２のオブジェクト、すなわち、ＨＴＴＰ要求を表現する要求バンドル３を別のパイプ、すなわち、内部に追加的な復号されたコンテンツを持つパイプＢと共に出力する。追加のグルーコードLocalUrlResolver４はＨＴＴＰ要求及びパイプＢを定義する要求バンドル３を受け取り、その要求をいかにして実行／サービスすべきかを決定する。このグルーコードLocalUrlResolver４はＨＴＴＰ応答を応答バンドル５として戻すが、この応答バンドルはその後にIHttpSvr２に返送され、IHttpSvr２はＨＴＴＰ応答を別のパイプ、すなわち、パイプＦを介して第１のグルー論理であるTcpListenerに戻すべきデータとして符号化し、その後、TcpListener１はデータをＴＣＰによって出力送信する。図１は、実際にはLocalUrlResolver４がその動作を実行するために他のパイプ、グルー論理などを使用していても良いことを指示するために、「他のプロセッサ６」も示している。
【００１６】
これをＯＢＥＸサーバに変形するために、IHttpSvr２はＯＢＥＸ要求を処理するであろう（従って、それはIOBEXSvrになるであろう）。（LocalUrlResolver４は新たな要求パラメータに対応するために拡張されても良いであろう。TcpListener１は、赤外線又はBluetoothを介してＯＢＥＸメッセージを受信できるコンポーネントと置き換えられても良いであろう）。しかし、パイプライン概念は要求されているデータの性質に関して中立であるため、同じシステム相互接続構造が使用される。最終結果は、様々に異なる必要条件に適応するために容易に変更できる、すなわち、単におそらくはグルー論理の単一のアイテム（すなわち、IHttpSvr2）を変更するだけで全く新しいアプリケーションを開発することができるモジュラーシステムである。また、実際には、IHttpSvr2、LocalUrlResolver４及び可能であれば他のプロセス６以外の全てのコンポーネントはモバイル計算装置のＲＯＭに焼き付けられる。追加されなければならない（且つＲＡＭで実行される）グルー論理は非常にコード効率が良く、通常、IHttpSvr２、LocalUrlResolver４及びもしあれば組み合わされた他のプロセス６の全てに対して１００ＫＢである。
【００１７】
TcpListener１のグルー論理はＲＯＭにあるので、本来は再利用可能である。原理上、他のグルー論理もＲＯＭに入れることができ、再利用可能とすることができる。例えば、図１に示すmSurfウェブサーバ全体をＲＯＭで実現することが可能であろう。その場合、単純にＲＯＭベース資源を利用できるIOBEXSvrコンポーネントを供給することにより、この上にＯＢＥＸサーバを構築することができるであろう。これはＲＡＭに対して非常にコード効率が高いといえるであろう（おそらくは３０ＫＢを追加する）。
【００１８】
LocalUrlResolver４は他のどのプロセッサ６を実行時に呼び出すべきかに関して決定する。呼び出し可能なプロセッサ６の既存のプールに対して、プラグインとして実現された新たなパイププロセッサ６を追加することにより、機能性を拡張できる。一例として、ウェブサーバは、当初、ユーザがアドレスブック中の連絡先を見て回ることを可能にする、他のプロセッサ６において定義された機能をつけて出荷することが可能であろう。ユーザが写真を見ることを可能にする新たなパイププロセッサ（呼び出し可能なプロセッサ６の一部を形成する。）がその後に定義され、m-Surfに対してアクセス可能にされても良いであろう。この新たなパイププロセッサは当初の出荷の後に（例えば、赤外線、Bluetooth（ＲＴＭ）、ＧＰＲＳなどにより）ダウンロード可能としたものとできるであろう。これにより、実際には、当初の装置出荷の後に広範囲にわたるシステムの拡張を提供でき、従って、ユーザがそのモバイル計算装置に新たな特徴及び機能を容易に追加することが可能になるであろう。
【００１９】
また、本発明はコード効率の良いアクセスコントロール（すなわち、細心の注意を払うべきセンシティブデータに対するアクセスを制御すること。）を実現することを可能にする。従来、セキュア（保護された）アプリケーションにはメモリの保護エリアが割り当てられている。これにより、様々に異なるアプリケーションがセキュアアプリケーションにより制御されているデータを直接に見ることが防止される。その代わりに、セキュアアプリケーションは、共有しようとするデータをコピーして送信する。しかし、この結果、同じデータの複数のコピーが作成されることになる。本発明の１つの実装においては、パイプ及びバンドルを作成して所有し、且つタスクを開始して所有するのはマネージャプロセスである。センシティブデータを取り扱う場合、マネージャプロセスは、そのセンシティブデータを含むバンドル又はパイプのエンド又はブロブ（ｂｌｏｂ）又はストリングを指示する小さなハンドル（通常は４バイトの長さ）を要求側エンティティへ送信する。従って、小さなハンドルを使用してオブジェクトを露出させることができる。これは不必要なデータ複製を回避する。また、データハンドルはきわめてサイズが小さいため、その転送は非常に速い。そこで、要求側エンティティは、関心を持っていないデータを伴うバンドル全体ではなく、必要としているデータ項目のみをバンドルから読み取ることを要求することができる。
【００２０】
アクセスコントロールは、装置のオペレーティングシステムにより生成された独自の通信セッション固有ＩＤにより識別されるべき要求側クライアントセッションによって実行される（例えば、Symbian OSの中の特徴）。そこで、マネージャプロセスは、要求側クライアントセッション（独自ＩＤにより識別された）が操作／検査されるべきプリミティブを作成した（又はその他の方法により制御する）アプリケーションにより必要な読み取り／書き込み権を付与されたか否かを検査する。尚、マネージャは、どのクライアントに許可を与えるべきかを選択する際に許可側クライアントに補助を全く与えず、単に許可付与側により決定が下されることを強制するだけである。
【００２１】
本発明のその他の詳細は添付の請求の範囲に特定して記載されている。
【００２２】
本発明の第２の面においては、上述の本発明による方法を使用して開発されたプログラムによってプログラミングされた場合のモバイル計算装置がある。
【００２３】
本発明の第３の面においては、上述の本発明による方法を使用して開発されたソフトウェアプログラムがある。
【００２４】
添付の図面を参照して本発明を説明する。
【発明を実施するための最良の形態】
【００２５】
本発明の商用の１つの実施品は英国ロンドンのIntuwave Limitedから入手可能である。これはmStreamと呼ばれている。mStreamはモバイル計算装置の主要なＯＳであるSymbianプラットフォームに合わせて実現された。Ｍｉｃｒｏｓｏｆt  Ｗｉｎ  ＣＥに対するポートも実現されている。mStreamでは、第１のオブジェクトは「パイプ」と呼ばれる。第２のオブジェクトは「バンドル」と呼ばれる。mStreamは、パイプ及びバンドル又はそのいずれかを処理するタスクをいかにして書き込み、作成し、呼び出し又は使用すべきかを定義する抽象ＡＰＩ定義に従った「タスク」（「パイププロセッサ」としても知られている）を実現するために使用できるライブラリのセットを含む。
【００２６】
＜パイプ＞
パイプは、２つのエンドの間で生２進データの送信を、そのデータの順序を維持しつつ定義するオブジェクトである。従って、パイプは送信媒体の最高の（すなわち、最も単純な）レベルの抽象化である。そのため、パイプは、ＦＴＰ又はＳＯＡＰのような要求／応答送信システムとは異なり、パイプが通過させるデータについて何も知っている必要がない。
【００２７】
（パイプ必須特性の概要）
・単方向：パイプは１つの方向にのみデータを転送する。明示書き込みエンドと、読み取りエンドとが存在する。２つのエンドは、いずれも、他方のエンドへ転送もすることなくプロセス又はスレッドへ渡されることが可能であろう。これにより、プロセス又はスレッドへの通信、あるいはプロセス又はスレッドからの通信が可能になる。
・プロセス間／スレッド間：２つのエンドは異なるプロセス又はスレッドにあっても良く、プロセッサ間及びスレッド間の２進データ転送が可能になる。
・バッファ付き：パイプは、データがパイプに書き込まれるとき、読み取り側がそのデータを読み出すまでデータを吸収し、保持することができるように、事前定義済みの容量を有する。バッファ量は固定されている。
・２進（コンテンツ／フォーマットは認識しない。）：パイプはデータが事前定義済みの構造に従うことを要求しない。
・無限／有限コンテンツ長さ：パイプは有限である必要がない（いくつかのパイプ、すなわち、書き込み側にデータエンドポイントを定義することを要求するパイプとは異なる）。必要に応じて、パイプは有限であっても良く、その場合、任意の事前定義済みの期待コンテンツ長さを有する。例えば、ディスクからｘＭＢのサイズのファイルを読み取っていることを考えても良い。その場合、パイプはｘＭＢのコンテンツを期待することを告げられることができ、その量のデータを過ぎた後に閉鎖する（閉鎖が早すぎる、又は過剰であるならば、エラーをフラグにより指示する）。パイプは、全てのコンテンツが送信され終わったことを受信側が推測できるように閉鎖しても良い。
【００２８】
＜バンドル＞
バンドルは、順序付き名前／値対を定義するオブジェクトである。従って、バンドルは構造化コンテンツの最高レベルの抽象化である。バンドルは事前定義済みのフィールドを持たない形式であると考えることができる。この形式は、名前／値対を挿入することにより占有される。バンドルは単一のオブジェクトとしてパイプの周囲を通過することができる。
【００２９】
（必須バンドル特性の概要）
・名前／値対を含む：各々の値は関連する名前を有し、その値は名前を指定することにより獲得できる。
・名前は大文字と小文字とを区別する：言語の中にはこれを要求するものがある（例えば、Ｃ＋＋）。大文字と小文字とを区別しなのは特殊であり、必須特徴ではない。
・値は以下のものを含む。
【００３０】
−ストリング（例えば、ユニコード／ＵＴＦ８）：値をＵＣＳ２として追加でき（ユニコードテキストストリングを表現する方法）、ＵＴＦ８として検索できる（又はその逆）
−２進「ブロブ」（２進大型オブジェクト、すなわち任意のサイズの２進データ）
−パイプ終わり
−その他のバンドル。
・複製が許可される：同じ名前を有するバンドルの中に２つ以上の項目が存在していることが可能である。
・順序付き：名前／値対が追加される順序は維持され、従って、複製の要求されるインスタンスを指定することができる（例えば、同じ名前を有する第１又は第２）。
【００３１】
バンドルは構造化データであり、パイプは生２進データのみを送信するため、バンドルが修正されずにパイプに沿って送信されることは不可能である。従って、バンドルは、パイプで送信されることが可能であるバイト列（例えば、ＸＭＬファイル又は２進符号）に変換され、他方のエンドでバンドルに再変換される必要がある。同様に、バンドルは何らかのグルー論理を使用してＸＭＬに変換／直列化され、その後、ＸＭＬのみを読み取ることができるレガシーコンポーネント（又はmStream外の何らかのもの）へ送信されることが可能である。
【００３２】
また、パイプエンドをバンドルに値として追加することができる（例えば、パイプのエンドポイントをバンドルで定義することが可能であろう）。パイプエンドのようなオブジェクトをバンドル内に有することは、それらをセーブ又は直列化するために何らかの種類のグルー論理を使用できないことを意味しているであろう。
【００３３】
＜タスク／「パイププロセッサ」＞
タスクは、パイプ及びバンドルを操作するコードのユニットである。mStreamは、それらのコードのユニットをいかにして書き込まなければならないか及びいかにして呼び出さなければならないかを指定するＡＰＩを定義する。これはオペレーション（必然的にパイプ及び／又はバンドルにおけるオペレーション）の最高レベルの抽象化である。
【００３４】
（必須特性の概要）
・処理を実行するコード：例えば、ＤＬＬ（ダイナミックリンクとライブラリ、すなわち既知の機能を呼び出すことにより呼び出されるコード）、スクリプト（何らかの他のコードにより実行時に解釈されるテキストファイルであり、開発担当者によってスクリプトファイルを変更することが可能）又は実行ファイル（独自の処理空間で実行される独立型コンパイルドコード）。
・タスクは名前を有し、従って、その名前を指定することによりインスタンスを作成できる。
・非実行：タスクが作成されるとき、当初、タスクは非実行（すなわち、休眠状態又はサスペンデッド）。
・タスクのインスタンスは以下のものを指定して作成される。
【００３５】
−呼び出されるべきタスクの名前。
【００３６】
−コマンドライン（オプション）：オプションの起動パラメータを含むテキストストリング。
【００３７】
−パスされるべき２つのパイプの「読み取り」エンド（オプション−０、１又は２つの読み取りエンドへのパスが可能であろう）。
【００３８】
−パスされるべき２つのパイプの「書き込み」エンド（オプション−０、１又は２つの書き込みエンドへのパスが可能であろう）。
【００３９】
−値を読み取ることができるバンドル−入力バンドル（オプション）。
【００４０】
−必要な何かを書き込むことができるバンドル−結果バンドルプレースホルダ（オプション）。
・起動可能：一旦作成されたならば、起動可能である。
【００４１】
−実際の起動の通知は「オーナ」又はクリエータに提供される。
・「リターンコード」によって停止できる。
【００４２】
−「オーナ」は完了及びリターンコードの通知を受けることができる。
【００４３】
これら３つのコアプリミティブに加えてマネージャプロセスが存在する。マネージャプロセスは、
・オブジェクトを作成して、所有し、
・それらのオブジェクトに対するアクセスコントロールを共有して、実行し、
・タスクを起動し、所有し、監視する。
【００４４】
＜タスク／パイププロセッサのインプリメンテーション＞
・概念上はｃ＋＋、スクリプト、cgi、javaなどであることが可能である。
・概念上は１つのインプリメンテーションに２つの部分がある。
【００４５】
−いくつかの項目について動作しているタスクの「インスタンス」
・いくつかのインスタンスが異なる項目のセットによって同時に実行していても良い。
【００４６】
・インスタンスは同じまたは異なるスレッドまたはプロセスで実行していても良い。
【００４７】
・インスタンスが終了したとき、関連するタスクは結果コードによって完了される。
【００４８】
−名前付きプロセッサごとの単一の「グループ」／ファクトリオブジェクト
・実行すべき「次の」タスクの詳細を検索し、
・そのタスクを実行するためにインスタンスを使用する。
・名前付きプロセッサは、以下のようなファクトリ型アーキテクチャに匹敵する。
【００４９】
−標準ＥＰＯＣサーバ／セッションアーキテクチャ
−ＣＯＭ／ＯＬＥクラスファクトリ
−ＭＤＩユーザインタフェースなど
＜オブジェクトライフサイクル＞
・オブジェクトは、
−mStreamマネージャプロセスの中で、
−「クライアントセッション」の要求に応じて、
−３２ビットハンドルと関連して、
作成される。
・mStreamにおいて、各クライアントセッションは、
−固有の３２ビット識別子、
−セッションが使用しているオブジェクトのリスト
を有する。
・クライアントセッションがある１つのオブジェクトによって終了されたとき、クライアントセッションはハンドルを「解放する」。
【００５０】
−オブジェクトが使用されていない場合、オブジェクトは削除される。
【００５１】
−セッションが終了するたびに、マネージャはそのオブジェクトの全てを解放する。
【００５２】
＜オブジェクトの共有及びアクセスコントロール＞
・セッションは、「ハンドル」と関連するオブジェクトに対してマネージャがオペレーションを実行することを要求することにより、オブジェクトを「使用」する。
・マネージャは全てのセッションに関して「使用済み／所有／既知」ハンドルのリストを保持する。
【００５３】
−オペレーションはセッションの「使用済み」リストにあるオブジェクトに対してのみ許容される。
【００５４】
−このリストのハンドルごとに許容されるオペレーションは指定される。
・オブジェクトをリストに追加するための限られた方法。
【００５５】
−オブジェクトを作成する。
【００５６】
−別のmStreamオペレーションの結果としてハンドルを受信する。
【００５７】
−マネージャに対する要求によってそれを明示して共有する別のセッションにより、
・第１のセッションは「can_share」許可を有するオブジェクトのみを共有して良い。
【００５８】
・第１のセッションはそれ自体が既に有している許可のみを付与することができる。
【００５９】
・第１のセッションは共有すべきセッションのＩＤを指定する。
【００６０】
・第１のセッションはどのセッションを信用／共有すべきかの選択に関して責務を負う。
【００６１】
＜ユニコード＞
ストリーム及びパイプは２進データを取り扱う。従って、幅の狭いテキストは８ビットであるので、容易に送信が可能である。しかし、ユニコードは２バイト又は４バイトの幅であってもよい。そのため、データをバイトポインタにキャスティングするという問題、更にはバイトの順序付けという問題が存在する。また、場合によっては、データは欧文文字セットから来るもの、すなわち、ＨＴＴＰ要求などになることもある。これを考慮に入れると、mStream Symbianインプリメンテーションの一部である例及びヘルパＤＬＬは、データをパイプに書き込むときはユニコードデータ（usc２）をＵＴＦ８に変換し、パイプから読み取るときにはＵＴＦ８からＵＣＳ２に戻し変換する。これは強制ではなく、パイププロセッサの作者は、使用したいどのような符号化でも使用することを完全に許されている。パイプの双方のエンドが同じ符号化を使用していると仮定すれば、問題は全くない。mStreamはＵＴＦ８ストリングとＵＣＳ２ストリングとを相互に変換し、等価の符号化を等価のストリングとして扱う。
【００６２】
＜サービスフレームワーク＞
バンドルは複雑な構造化データを表現することができるので、サービス要求メッセージ及び応答メッセージをモデル化するためにバンドルを使用することが可能である。それらのメッセージはグルー論理により符号化され、パイプに沿って別のプロセッサへ送信されることができ、別のプロセッサはそれらをターゲットプロセッサへ送り出す。これと同じグルー論理を使用して、バンドルをファイルに残存させるか、又は人間が読み取ることができる形態で紙に印刷することが可能になるように、バンドルを符号化することもできる。選択される符号化はＸＭＬのように規格に基づいているか、又は独自開発のものであって良い。メッセージを表現するバンドルは、サブメッセージとルーティング情報とを含むことができる。これらのサブバンドル及び値の可視度及び編集可能度は、いくつかのメッセージが読み取り専用である一方で、別のメッセージは修正可能であるように、フレームワークにより制限されることが可能である。フレームワークは、更に、バンドルのオリジネータに関する信用証明情報（ｃｒｅｄｅｎｔｉａｌ）を提供するために使用されても良い。
【００６３】
＜パイププロセッサの使用例＞
パイププロセッサがその入力データ（コマンドラインストリーム及びバンドル）によって何を実行するか、及びパイププロセッサが出力（ストリーム及びバンドルまたはそのいずれか）として何を生成するかは、完全にパイププロセッサの開発担当者に任されている。パイププロセッサは全てのバンドルの入力出力ストリームを使用する必要はない。例えば、パイププロセッサはその標準入力ストリーム及び出力ストリームを取り扱うだけであっても良い。そのようなパイププロセッサはフィルタ又は要求／応答プロセッサとして使用することが可能であろう。パイププロセッサは入力バンドル及び出力バンドルを操作するだけであっても良く、ＲＰＣ呼び出しを実行するために使用されることが可能であろう。パイププロセッサの論理図は図３に示されている。
【００６４】
mStreamは任意の数のパイププロセッサを取り扱うことができ、そのため、パイププロセッサは多種多様な方法で使用されることが可能である。最も単純なレベルでは、図４に示すように、アプリケーションは何らかの作業を実行するためにパイププロセッサを呼び出し、標準入力（stdin）に接続されたパイプを介して何らかのデータをそのパイププロセッサへ送り出し、パイププロセッサがその標準出力パイプ（stdout）で生成したデータを収集することができるであろう。
【００６５】
これより複雑なスキーマはパイププロセッサを使用するであろうが、更にパイププロセッサに作業を委託し、そのパイププロセッサは別のパイププロセッサに作業を委託し、それが継続されて行く。これは図５に示されている。尚、この例では全てのモジュールがバンドルを共有するようにセットアップされていることに注意する。
【００６６】
これに代わる構成は、図６に示すように、パイプライン中の先行するプロセッサにより生成されたデータを後続するプロセッサがフィルタリングし、変換するようなパイプラインであっても良いであろう。
【００６７】
そのような構造は、図７に示すように、プラグアーキテクチャを伴うウェブサーバを構成するように使用されることも可能であろう。プラグインは、必要に応じて、ポスティングされたデータ又は生成されたＨＴＭＬ又はjpg又は他のコンテンツをＵＲＬに従って読み取る複数のパイププロセッサである。ＵＲＬはパイププロセッサに対するコマンドラインとして、また、プラグインに渡される入力バンドル中の値として指定されることが可能であろう。
【００６８】
このようなスキーマは、図８に示すように、プラグインをコンソール（すなわち、コンソールアプリケーション）を介して個別に試験できるという利点を有する。
【００６９】
同じコンポーネントを、図９に示すように、ローカルホストデータと、フェッチするために生成されるＨＴＴＰ要求を必要とした遠隔データとの相違を理解するスマートブラウザの一部として使用することも可能であろう。
【００７０】
＜mStreamインプリメンテーションの詳細−コアモジュール＞
mStreamManは、マルチパートシステムに対して基本的要素として使用できるいくつかのオブジェクトを提供するライブラリである。これは何らかの特定のアーキテクチャを指示するのではなく、非同期アクティブオブジェクトと、同期ブロッキングスレッド実行の双方を支援する。mStreamManはSymbianのeStLibを支援し、プロセス外実行ファイルの使用により、stdioストリームを使用する標準Ｃ／Ｃ＋＋コードのコンパイル（最小限の変更を伴う。）及び使用を可能にする。
【００７１】
mStreamインプリメンテーションは下記のコアモジュールから構成されている。
【００７２】
mStreamMan−これは、処理空間において全てのmStreamオブジェクトを管理する「サーバ」プロセスである。また、プロセスマネージャからオペレーションを要求するためにクライアントが使用できるファンクションのセットを含む。このファンクションのセットはプラットフォーム中立であるので、これを使用して開発されたシステムは他のオペレーティングシステムにおいてリコンパイルされるのは自明である。
【００７３】
mStreamClient−これは、マネージャプロセスからオペレーションを要求するためにmStreamのクライアントが使用するlib／ＤＤＬである。提示されるＡＰＩは記述子及びアクティブプロジェクトなどの標準Symbianパラメータを使用する。そこで、このようなコードはプラットフォーム中立ＡＰＩよりポートするのが困難であるが、Symbian利用開発担当者にとってはこれを実現するほうがより慣れ親しんだ方法である。
【００７４】
mStreamLegacy−このＤＤＬは、ポリモーフィックＤＬＬとしてパイププロセッサに書き込むための基礎として開発担当者が使用できる基本クラスのセットを提供する。
【００７５】
mStreamExe−このＤＬＬは、別個のプロセス／実行可能としてパイププロセッサに書き込むために開発担当者が使用できるユーティリティクラスのセットを提供する。
【００７６】
mStreamStdLib−このlibは、mStream  ＡＰＩが標準Ｃ i/o libとして現れるようにmStream  ＡＰＩを包む。パイプは標準入力／出力ストリームにマッピングされ、バンドルは従来のgetenv(), putenvファンクションを使用してアクセスできる環境として表現される。このモジュールは、既存の標準Ｃ＋＋／Ｃコードをタスクとしてコンパイルするための単純な方法を提供するためにeStdLibと共に使用することが意図されている。
【００７７】
他に、コアmStream ＡＰＩ及びファシリティの上に構築することをIntuwaveが規定するＤＬＬ／モジュールが存在する。
【００７８】
mStreamObjects−このＤＬＬはメッセージ通過をシミュレートするクラスのセットとしてmStreamクライアントＡＰＩをラップし、サービスフレームワークを提供する。このＤＬＬを使用して、開発担当者は現実にはパイププロセッサである「ウェブサービス」を作成することができる。
【００７９】
mStreamShell−このパイププロセッサは単純なコマンドラインプロセッサとして動作することができる。入力ストリームを読み取り、それを構文解析して、限られた数のオペレーションを実行することができる。それらのうちでもっとも有用であるのは、ユーザ指定引数を渡し、オプションとしてこれらの子プロセッサからの入力をファイルから、もしくは出力をファイル又は他のプロセッサへリダイレクトする他のパイププロセッサを呼び出すことである。また、このパイププロセッサはファイルからのコマンドを解析することもでき、そのため、スクリプトを処理するために使用可能である。
【００８０】
mConsoleは単純なコンソール型アプリケーションである。これにより、ユーザはキーボード／キーパッドを使用して入力を打ち込むことができ、それらの文字を選択されたパイププロセッサへ送信する。そこで、パイププロセッサはその出力パイプを介して文字を戻し、コンソールアプリケーションはそれを捕捉して、画面へリダイレクトする。この使用パターンはタスクをコメントラインインタプリタとして取り扱っている。全てのタスクが人間が読み取り可能なコンテンツを読み取る又は書き込むとは限らず、従って、この方式で実際に使用されるのは一部のタスクのみであろうということは自明である。
【００８１】
mStreamScriptは、呼び出しスクリプトをパイププロセッサとして許可するＤＬＬである。mStreamScriptは、これを、名前付きスクリプトのスクリプト言語及びその言語を解釈するパイププロセッサを識別することにより実行する。そこで、識別されたプロセッサは呼び出され、元来のスクリプトを渡す。しかし、クライアントは、元来のスクリプトファイルの名前を使用してタスクを呼び出したことを認識しているのみである。クライアントは、それが実際には特定のスクリプトを解釈する別のプロセッサであることを認識する必要はない。
【００８２】
TcpListenerは、入って来るネットワーク接続を求めて複数のＴＣＰポートを監視するように構成された再利用可能コンポーネントである。そのような接続が作成されると、その入力及び出力は事前構成済みプロセッサの新たなインスタンスに向けてリダイレクトされる。プロセッサ自体は、ＴＣＰから入力を受信していることを知る必要はない。TcpListenerは、その接続に関する情報を使用することをオプションとして希望するのであれば、何らかの情報をその入力バンドルによってプロセッサへ送信する。TcpListenerそれ自体はパイププロセッサではない；必要不可欠なものではなく、インプリメンテーション上の１つの選択肢である。
【００８３】
mStreamTcpは、指定されたＴＣＰポート及びアドレスに接続するために使用できるパイププロセッサである。これは、ａ）入って来るコネクションではなく、出て行くコネクションに対応すること、及びｂ）それ自体はタスクを作成せず、おそらくは別のタスクに既に付随していた入力／出力パイプによって事前に作成されていることを除いて、tcplistenerと同様の役割を実行する。尚、mStreamTcpはどのプロセッサがそのi/oパイプに接続されるかを知らず、単にそのパイプで送られるデータと、開始することを求められていたＴＣＰストリームとの間の中継として動作することに注意する。
【００８４】
mStreamEchoは、入力パイプから読み取り、同じデータを出力パイプに書き込むパイププロセッサである。すなわち、送信されて来るものを全てエコーバックするである。その代表的な役割は、試験の一部としてのそれである。すなわち、試験では何らかのデータをパイプラインを介してmStreamEchoへ送信し、その後、戻されて来るデータを受信する。パイプラインの所期の挙動が与えられると、戻りデータは期待されるフォーマット（通常は本来送信されたのと同じ）を有することになり、戻りデータは妥当性が確認でき、パイプラインにおけるタスクの妥当性をも推論することができる。
【００８５】
＜TcpListener、mStreamTcp及びmSTreamEchoを使用するソースコードの例＞
2005506631.tif 000003
2005506631.tif 000004
【００８６】
＜mStreamを使用する異なるプログラムの例＞
（mSurf）
mSurf（図１を参照）は、SymbianプラットフォームのためのIntuwave Ltdによるモバイル計算装置用のウェブサーバの１つのインプリメンテーションである（例えば、ＰＣＴ／ＧＢ０２／００３９１５を参照）。これはmStreamに基づいている。mStreamは、実際にはmSurfインプリメンテーションの中で繰り返し現れるオブジェクトの認識を経て作成されている。mSurfウェブサーバは１つのウェブ要求をサービスする動作をはるかに単純なモジュールから成るパイプラインに分割する。その第１は、通常はポート８０に入って来るＴＣＰコネクションを監視するTcpListener１である。このモジュールはＴＣＰデータストリームを、選択されたモジュールに渡されて、そこから取り出される１対のパイプＡ及びＦに変換する。この場合、第２のモジュールはIhttpSvr２と呼ばれるパイププロセッサである。このパイププロセッサは入力データストリームを読み取り、ＨＴＴＰ要求ヘッダ及びコンテンツを解析する。これは、要求ヘッダに相当するバンドル３と、復号されたコンテンツに相当するパイプＢとを作成する。これら２つは、次に、応答バンドル及び応答パイプＣを作成するという責務を負う、LocalUrlResolver４と呼ばれる第３のパイププロセッサに渡される。応答はiHttpSvr２によりＨＴＴＰフォーマットの応答に戻され、この応答はパイプにより第１のモジュールであるTcpListener１へ返送され、元の要求側に戻される。既に述べたLocalUrlResolver４プロセッサ自体は要求をサービスするために他のパイププロセッサを使用する。
【００８７】
尚、セキュアソケットを使用して監視した別のモジュールを、第１のモジュール１、又はファイル又は他のソースから要求を受信したモジュールと置き換えることもできる。そのような置き換えはパイプラインのその他の部分には影響を及ぼさないであろう。また、ＷＡＰ又はＯｂｅｘ要求をサービスしたプロセッサを、先に説明したように、第２のモジュールと置き換えることができる。最後に、ローカルで要求を解決する第３のモジュールを異なる規則を使用する別のモジュールと置き換えることも可能であろう。それらのモジュールの各々は他のシステムを形成するために使用されるか、又は組み合わされることが可能であろう。
【００８８】
IHttpSvr２モジュールは、多重化を実行し、何らかのファイアウォールを介してトンネリングすることが可能なＨＴＴＰベースのＶＰＮソリューションを作成するために使用されるモジュールと組み合わせることが可能であろう。TcpListener１モジュールは以下の例で示すように再利用されている。
【００８９】
（例−mView）
mViewは、デスクトップユーザがSymbian装置を制御することを可能にするシステムである。モバイル計算装置には、スクリーン上の画像を獲得し、それを圧縮するプロセッサが存在する。そこで、遠隔の場所にいるデスクトップユーザはこのViewEngineプロセッサに接続して、それらの圧縮されたスナップショットをデスクトップコンピュータに表示すべく検索することができる。同様に、デスクトップアプリケーションは、キーボード及びマウス／ペンの動きをmViewEngineプロセッサへ送信することができ、その場合、それらの動きは、まるでモバイル装置のユーザが現実の装置でそれらのキーを押したかのように扱われる。この遠隔制御の挙動は単純であるが、タスクとして実現することにより、デスクトップコンピュータとモバイル装置とがどのように接続される場合でも使用することができる。
【００９０】
１つの構成においては、ＰＣは装置のTcpListenerに接続でき、そこで、TcpListenerは、図１０に示すように、データを通常通りにパイプを介してmViewEngineプロセッサへ送信する。別の構成では、図１１に示すように、装置はmStreamTcpを使用してデスクトップへ出て行くコネクションを作成し、次に、これをmViewEngineプロセッサのインスタンスの入力／出力パイプに接合することができる。別の構成においては、デスクトップ及び装置は共に中継ステーションに接続できる。装置のセットアップコードは、mStreamTcpに中継ノードとの通信を開始させ、次に、一旦実行されたならば、適切なパイプをmViewEngineに渡すことができる。装置を接続するために使用されるネットワークトポロジに関わらず、エンジンの機能は不変のままである。
【００９１】
（例−Symbianコネクト）
図２に示すように、Symbianコネクトの場合、TcpListenerモジュールはデスクトップＰＣにより使用するためにサービスにそれぞれ接続されているいくつかのＴＣＰポートを監視するために使用される。標準SymbianコンポーネントはＰＰＰコネクションを作成するために使用される。そこで、デスクトップＰＣは、使用することを希望するサービスに接続し、次に、２進データのサービス特定パケットを読み取るまたは書き込むことによりそれらのサービスと通信する。それらのパイププロセッサのうちの１つであるEcTcpAdapterは、それらのデータのパケットを要求に変換し、その後、要求はＰＰＰと呼ばれる別のプロトコルスタックに作成されているレガシ相互接続サービスに渡される。パイプを介して送信される１つの符号から別のフォーマットへのこの翻訳は、より古いレガシーコードに対するアダプタとしてプロセッサをいかにして使用できるかの一例である。それらと同じサービスがセキュアソケット層を介して、あるいは更にhttpトンネルをも介して公開されることを阻止するものは何もない。サービス層の機能を提供するプロセッサはネットワーキング層に関する条件付けを何も行わない。
【００９２】
（例−マルチプレクサ）
既に述べたようなプロセッサのデザインは、グループの概念とインスタンスの概念とを含む。プロセッサのこれら２つの部分はいずれも資源を所有することができる。いくつかのインスタンスが同時に存在することは可能であり、インスタンスは、それぞれ、別個のパイプを使用して他のモジュール及びタスクと通信することができる。各々のインスタンスは、通常、グループ（同じプロセッサインプリメンテーションの一部である）をアクセスできるため、インスタンスは「グループ」オブジェクトの資源を共有することが可能である。それらの資源の共有は共同のものであり、厳密な詳細はインプリメンテーションによって異なる。いくつかのインスタンスは資源に対して最高の優先度のアクセスを獲得するかもしれないし、あるいは各インスタンスが排他的アクセスを有するタイムスロットを獲得するかもしれない。これらの「グループ」オブジェクト資源は、他のモジュールと通信するために使用されるべき他のパイプエンドを含んでいても良い。従って、「インスタンス」により使用されるパイプのコンテンツは、そのグループにより所有される１つ以上の他のパイプエンドに沿って多重化されることが可能である。戻りデータは同様にして逆多重化される。構築するには高価であるが、安価に使用できる資源であるネットワーク接続を再利用するために、その実装を採用することが可能である。TcpListener１と共に、ＨＴＴＰサーバ又はＨＴＴＰクライアントモジュールと組み合わせれば、ポート８０でファイアウォールを介してトンネリングすることができるであろうＶＰＮ型ソリューションを作成することが可能である。尚、そのようなソリューションは、フレームの代わりの符号化を使用するために容易に修正できるであろうし、システムのその他の部分に影響を及ぼさずに別のベアラにＨＴＴＰの使用を切り替えることが可能であろう。
【図面の簡単な説明】
【００９３】
【図１】mSurfと呼ばれる本発明の１つのインプリメンテーションの概略図である。
【図２】Symbian Connectにおける１つのインプリメンテーションの概略図である。
【図３】タスクの概略図である。
【図４】タスクの概略図である。
【図５】タスクの概略図である。
【図６】タスクの概略図である。
【図７】タスクの概略図である。
【図８】タスクの概略図である。
【図９】タスクの概略図である。
【図１０】mViewと呼ばれる１つのインプリメンテーションの概略図である。
【図１１】mViewと呼ばれる１つのインプリメンテーションの概略図である。
【図１】
2005506631.tif 000005
【図２】
2005506631.tif 000006
【図３】
2005506631.tif 000007
【図４】
2005506631.tif 000008
【図５】
2005506631.tif 000009
【図６】
2005506631.tif 000010
【図７】
2005506631.tif 000011
【図８】
2005506631.tif 000012
【図９】
2005506631.tif 000013
【図１０】
2005506631.tif 000014
【図１１】
2005506631.tif 000015
【国際公開パンフレット】
2005506631.tif 000016
2005506631.tif 000017
2005506631.tif 000018
2005506631.tif 000019
2005506631.tif 000020
2005506631.tif 000021
2005506631.tif 000022
2005506631.tif 000023
2005506631.tif 000024
2005506631.tif 000025
2005506631.tif 000026
2005506631.tif 000027
2005506631.tif 000028
2005506631.tif 000029
2005506631.tif 000030
2005506631.tif 000031
2005506631.tif 000032
2005506631.tif 000033
2005506631.tif 000034
2005506631.tif 000035
2005506631.tif 000036
2005506631.tif 000037
2005506631.tif 000038
2005506631.tif 000039
2005506631.tif 000040
2005506631.tif 000041
2005506631.tif 000042
2005506631.tif 000043
2005506631.tif 000044
2005506631.tif 000045
2005506631.tif 000046
2005506631.tif 000047
2005506631.tif 000048
2005506631.tif 000049
【国際公開パンフレット（コレクトバージョン）】
2005506631.tif 000050
【国際調査報告】
2005506631.tif 000051
2005506631.tif 000052