JP5640138B2 - インプットメソッドエディタ - Google Patents

Description

本発明は、インプットメソッドエディタ（Input Method Editor（ＩＭＥ））に関する。

ＩＭＥは、テキストエディタ、ワープロソフト、アプリケーション（例えば、ウェブブラウザ等のテキストが入力されるアプリケーション）とともに使用され、所定の言語の文字入力を支援するコンピュータプログラムである。日本語、中国語など様々な言語用のＩＭＥがある。また、よく知られているＩＭＥとして、Microsoft社の「MS-IME」、Apple社の「ことえり」、ジャストシステム社の「ATOK」、Unix（登録商標）用のWnn、Canna、等がある。

［１．セキュリティ上の課題］
ＩＭＥは、イベント処理部、ＧＵＩ（グラフィカルユーザインタフェース）表示部、テキスト変換部を含む複数の機能からなる。これらの機能は、典型的に、一体構造のコンポーネント（特定の機能を持つソフトウェア部品）として実現される。Microsoft社のWindows（登録商標）では、このコンポーネントは１つのプロセスとして実行される形式ではなく、アプリケーションによってロードされる１つのＤＬＬ（ダイナミックリンクライブラリ）である。従って、このコンポーネントはアプリケーションと同じ権限で実行される。ＩＭＥコンポーネントがセキュリティホールを有すると、攻撃者は不正にホストアプリケーションの権限を獲得することができる。これは大きなセキュリティ上の懸念事項である。例えば、winlogon.exeのようなスクリーンロックプログラムがＩＭＥの脆弱性を利用して攻撃者によって攻撃されると、攻撃者はスクリーンをロックしたユーザの権限を用いて任意のプログラムを実行することができる。

［２．移植性に関する課題］
MS-IME（Windows（登録商標）のデフォルトのＩＭＥ）および「ことえり」（Macintosh（登録商標）のデフォルトのＩＭＥ）は一体構造の設計に基づく。すなわち、全てのコンポーネントは１つのバイナリファイルとして実装されている。この実装は国際化（インターナショナライゼーション、I18N）および移植をより困難にする。MS-IMEおよび「ことえり」は、中国語、日本語、韓国語について異なるＩＭＥ実装を有する。そのため、MS-IMEのコードはこれらの言語の間で共有されない。

Unix（登録商標）用のよく知られた日本語インプットメソッドであるWnnおよびCannaは、クライアント−サーバモデルを採用している。しかし、クライアントとサーバの間のプロトコルは状態を有し、日本語指向である。WnnおよびCannaのクライアントは、生のキー入力情報をサーバに送信しない。そのため、ＩＭＥクライアントの開発者は、クライアントとサーバの間で共有するセッション情報を注意深く管理しなければならない。これらのＩＭＥのプロトコルは日本語固有の情報をエンコードするので、そのプロトコルを、中国語および韓国語を含む他の言語に移植することをより困難にしている。

言語に依存せず、移植性を有するインプットメソッドを実装するための主な課題は次の通りである。

１つの課題は、ＩＭＥフレームワークの相違を吸収することが難しいことである。ＩＭＥを実装するために“インプットメソッドフレームワーク”を使用しなければならない。しかし、異なるオペレーティングシステムは異なるインプットメソッドフレームワークを提供する。例えば、Windows（登録商標）はIMM32/TSF（テキストサービスフレームワーク）を提供し、Macintosh（登録商標）はIMKitを提供する。これらのフレームワークのＡＰＩ（アプリケーションプログラムインタフェース）は異なる。インプットメソッドフレームワークの相違は、あるプラットフォームから他のプラットフォームにＩＭＥを移植することを困難にする。ジャストシステム社のみ、Windows（登録商標）／Macintosh（登録商標）／Linux（登録商標）上で動作するＩＭＥであるＡＴＯＫを販売している。オープンソースのＩＭＥ開発者を含め、他のＩＭＥ製造業者は、移植性のないＩＭＥフレームワークの制限の理由から、１つのプラットフォームに集中している。

もう１つの課題は、異なる言語におけるＩＭＥの使い勝手の差を吸収することが難しいことである。言語が異なると、ＩＭＥの使い勝手が異なる。ユーザは、完全な日本語テキストを入力するために３つの中間の状態（基本入力、事前編集、変換）を通る必要がある。一方、中国語のＩＭＥは２つのみの状態を有する。また、日本語ＩＭＥでは、異なるキー割り当て（key bindings）（MS-IME形式、ことえり形式、等）をサポートする必要がある。例えば、Ctrlキーを押したままdキーを押すことは、ことえり形式では“delete”（一文字削除）に対応する。全ての可能性のあるキー割り当てに拡張すると、その大きさは５００になる。中国語ＩＭＥではそのようなキー割り当てをサポートする必要はない。ＩＭＥの実装はラインエディタの実装と類似している。

上記１および２の課題を解決するためＩＭＥをクライアント−サーバモデルで実現することを考えると、下記３および４のような課題が生じる。

［３．バージョンの更新に関する課題］
クライアント−サーバモデルで設計されたＩＭＥは、ＩＭＥクライアントのみが新たなバージョンに更新され、古いバージョンのＩＭＥサーバがまだ動作している場合、またはその逆の場合に問題を有する。ＩＭＥクライアントプログラムが更新されても、既存のアプリケーションがまだ古いバージョンのＩＭＥクライアントを使用している（古いバージョンのＩＭＥクライアントプログラムを実行中である）場合、２つの異なるＩＭＥクライアントが１つのＩＭＥサーバにアクセスする場合が生じうる。新たなバージョンのＩＭＥクライアントが、古いバージョンのＩＭＥサーバとの間の古いバージョンの通信プロトコルをサポートしないとき、ＩＭＥクライアントは動作しない。古いバージョンのＩＭＥクライアントと新たなバージョンのＩＭＥサーバの間でも同じことが生じる。

このようなバージョンの不一致を防止する典型的な方法は、コンピュータの再起動、または、ログアウトして全てのアプリケーションを再度開始することである。これは、特に、ユーザに気付かれずにＩＭＥを更新することが期待されている場合、たいへん煩わしい。

［４．ＩＭＥサーバの異常終了に関する課題］
状態のないＩＭＥクライアントが各々のキー入力イベントをＩＭＥサーバに送信して出力情報を受信するクライアント−サーバ型のＩＭＥにおいて、入力セッションの間に、ＩＭＥサーバが異常終了して再起動されたとき、ユーザは意図しない出力を見ることになりうる。

いくつかの既存のＩＭＥはクライアント−サーバモデルで実装されている。しかし、これらの実装はサーバのクラッシュおよび再起動を考慮していない。

本発明は、第１に、プロセスを隔離した安全なＩＭＥの実装に関する。
第２に、言語に依存せず、移植性を有するインプットメソッド実装のための状態のないセッション管理に関する。
第３に、コンピュータの再起動なしでのＩＭＥバージョンの更新に関する。
第４に、セッションのプレイバックに関する。

［１．セキュリティ上の課題に対する解決手段］
本発明では、安全性の目的のために、ＩＭＥを複数のプロセス（一形態として、１つのクライアントＤＬＬと１つのサーバプロセス）に分離して機能をモジュール化する。複数のプロセスには、異なるセキュリティポリシーを適用し、サンドボックス、整合性レベルの変更のような異なる保護技術を適用することが可能である。

ここで、「サンドボックス」とは、保護された領域内でプログラムを動作させ、その領域の外へ影響が及ぶのを防止する技術である。
また、「整合性レベル」とは、Microsoft社のWindows Vista（Windowsは登録商標）で導入されたセキュリティ上の概念である。この整合性レベルは、高・中・低と分かれており、それによって、下記のように、ファイルシステムにどこまでアクセスできるかが決まる。
高：%ProgramFiles%やHKLMへの書き込みが可能（管理者権限）。
中：%UserProfile%やHKCUへの書き込みが可能（ユーザ権限）。
低：専用の場所にのみ書き込みが可能。

本発明では、ＩＭＥコンポーネントを、イベント処理部、ＧＵＩ表示部、テキスト変換部の３つに分けた。Windows（登録商標）において、イベント処理部とＧＵＩ表示部は１つのＤＬＬコンポーネントであるが、複雑さを軽減するために機能を制限した。テキスト変換部はより低い整合性レベルで、サンドボックス内で実行される隔離されたプロセスである。なお、テキスト変換部は、ＧＵＩ表示部に表示内容を指示するための表示情報を生成および送信する機能を含む。

例えば、Windows（登録商標）において、「高」整合性レベルを有するシステムツールが本発明によるＩＭＥコンポーネントをロードするとき、ＩＭＥコンポーネントも「高」整合性レベルで実行されるが、これはイベント処理部とＧＵＩ表示部のみである。テキスト変換部は「低」整合性レベルで、サンドボックス内で実行される。さらに、イベント処理部およびＧＵＩ表示部は、テキスト変換部との接続をポリシーに従って停止することができる。

Apple社のMacintosh（登録商標）では、イベント処理部は１つのプロセスであるので、問題はWindows（登録商標）より簡単である。イベント処理部の権限は制御することができる。本発明では、イベント処理部とテキスト変換部を分離することによってテキスト変換部をサンドボックス内に配置して機能を制限することができる。

［２．移植性に関する課題に対する解決手段］
ＩＭＥの移植性および国際化を向上させるＩＭＥアーキテクチャを開示する。ＩＭＥを実装するために、各々のオペレーティングシステムが提供するＩＭＥフレームワークを使用しなければならない。これらのフレームワークの違いはＩＭＥの移植を困難にする。また、言語が異なるとＩＭＥの使い勝手が異なる。ＩＭＥアーキテクチャを言語から独立にすることは困難であることが知られている。本発明では、基本的に、ＩＭＥをクライアントとサーバの２つのコンポーネントに分離する。また、本発明では、クライアントとサーバの間で状態のないプロトコルを使用する。クライアントとサーバは、ＩＰＣ（プロセス間通信）またはＲＰＣ（リモートプロシージャコール（遠隔手続き呼び出し））を用いて互いに通信する。言語に依存する全てのＩＭＥモデルがサーバ内に実装され、これはＩＭＥフレームワークに依存する必要がない。プロトコルは状態がないので、クライアントの役割を簡単にすることができ、クライアントはユーザのキー入力イベントを受信してサーバに送信し、サーバからの表示情報に従って表示する。単にサーバ部分を置き換えることによって新たな言語のための新たなＩＭＥを実現することができる。

［３．バージョンの更新に関する課題に対する解決手段］
本発明は、コンピュータの再起動なしで実現されたＩＭＥを更新する技術である。新たなバージョンのＩＭＥクライアントが古いバージョンのＩＭＥサーバと互換性のある通信プロトコルを有するとき、この更新はユーザに気付かれずに行われる。新たなバージョンのプロトコルが古いバージョンのプロトコルと互換性がないとき、それを検出し、どのように処理すべきかユーザに回答を促す。

［４．ＩＭＥサーバの異常終了に関する課題に対する解決手段］
ＩＭＥサーバインスタンスが異常終了したときでも、ＩＭＥクライアントは、以前のキー入力イベントを新たに実行されたサーバに再送することによって、現在のユーザセッションをシームレスに継続することができる。

本発明によるＩＭＥは次のような効果を奏する。

＜セキュリティ＞
ＩＭＥ ＤＬＬはアプリケーションと同じセキュリティレベルで動作する。もし、ＩＭＥ ＤＬＬがセキュリティホールを有し、アプリケーションが高いセキュリティレベル（Windows Vista（Windowsは登録商標）において「高」整合性レベルとも呼ばれる）で動作しているならば、悪意のあるユーザ／アプリケーションは、セキュリティホールを利用して、ユーザの個人データ（ユーザ履歴データ）を取得し、それを外部のサーバに送信するような悪意のある操作を行うことも可能である。これに対し、本発明によるクライアント−サーバモデルは、悪意のあるユーザ／アプリケーションからユーザデータを保護することができる。本発明によるＩＭＥサーバは隔離されているので、制限されたサンドボックス環境内でプロセスを起動することができる。サンドボックス化されたＩＭＥサーバは、ローカルコンピュータにおいて安全でないリソースにアクセスすることができない。

＜移植性＞
異なるオペレーティングシステムは、異なるＩＭＥフレームワークを有する。ＩＭＥをプラットフォームから独立にするために、これらのＩＭＥフレームワークへの依存を最小にすることが望ましい。コアの変換エンジンを１つの独立したプロセスとして分離することは、移植性のために役立つ。

＜ロバスト性＞
アプリケーションがクラッシュすると、そのアプリケーションに結合しているＩＭＥは同時にkillされる（プログラムの実行が終了させられる）。ＩＭＥがユーザ履歴または任意の変更可能なデータをローカルファイルシステムに同期させている間のアプリケーションのクラッシュは災難である。従来のＩＭＥの設計は、このような場合に弱い。意図しないアプリケーションのクラッシュのために、時々、ＩＭＥ辞書が破壊されることがある。本発明では、そのような心配はない。本発明によるＩＭＥクライアントＤＬＬは状態のある動作をせず、ＩＭＥクライアントＤＬＬがkillされても、セッション情報はＩＭＥサーバ内に残っている。そのため、ユーザデータを安全にローカルファイルシステムに同期させることができる。

＜プロセスに渡るロックを行わない＞
１つのアプリケーションは、１つのＩＭＥ ＤＬＬのインスタンスを生成する。従来は、複数のＩＭＥインスタンスが存在し、辞書およびユーザ履歴のような共有リソースを使用していることが常に生じるので、ＩＭＥ ＤＬＬは共有リソースの同時使用を防止するために、プロセスに渡る相互排除ロックを使用しなければならない。これに対し、本発明によるＩＭＥサーバはユーザごとに単一のプロセスであるので、システム自身はプロセスに渡るロックを行う必要がなく、これはＩＭＥを従来のシステムよりずっと簡単にする。

本発明によるＩＭＥアーキテクチャを表わす図である。 従来のＩＭＥアーキテクチャを表わす図である。 本発明によるＩＭＥアーキテクチャの概要を表わす図である。 名前付きパイプのパス名が表示されたウィンドウを表わす。 名前付きパイプのアクセス権が表示されたウィンドウを表わす。 バージョンの相違による動作を表わす図である。

以下、本発明の実施の形態について、詳細に説明する。

クライアント−サーバモデルで実装されたＩＭＥの実行形式ファイルは、ＩＭＥクライアントプログラムとＩＭＥサーバプログラムを含む。ＩＭＥクライアントは、ＩＭＥクライアントプログラムがコンピュータに読み込まれ、このプログラムに含まれる命令をコンピュータが実行することにより実現されると考えることができ、ＩＭＥサーバは、ＩＭＥサーバプログラムがコンピュータに読み込まれ、このプログラムに含まれる命令をコンピュータが実行することにより実現されると考えることができる。
また、説明中のアプリケーションは、アプリケーションプログラムがコンピュータに読み込まれ、このプログラムに含まれる命令をコンピュータが実行することにより構築される情報処理装置と考えることができる。
なお、説明中のＤＬＬ（ダイナミックリンクライブラリ）は、プログラムそのものを意味する場合と、ＤＬＬがコンピュータに読み込まれ、このプログラムに含まれる命令をコンピュータが実行することにより実現されるものを意味する場合がある。

本発明によるＩＭＥは、複数のプラットフォームにおいて実現可能であるが、以下、主にWindows（登録商標）を例に説明する。

セキュリティ上の課題を解決する観点から、第１実施例を説明する。

＜ＩＭＥアーキテクチャ＞
図１に示すように、一実施形態によるＩＭＥクライアントはWindows（登録商標）上の共有ライブラリ（ＤＬＬ）として実現される。このＤＬＬは、図２に示す、変換機能を含んでいた従来のＤＬＬと比較してサイズが小さい。図１の点線内は、サンドボックス内で動作する、ユーザ毎に単一のＩＭＥサーバである。移植性があり、大域的な相互排除はなく、ロバストである。一方、図２に示す従来のＩＭＥアーキテクチャでは、アプリケーションの権限で動作し、変換機能は移植性がなく、共有リソースはプロセスに渡る相互排除ロックが必要であり、管理が難しかった。

アプリケーションがユーザによって起動されるとき、ＩＭＥ ＤＬＬはコンピュータのメモリに読み込まれ、アプリケーションと結合される。アプリケーションは“ＩＭＥフレームワーク”を通してＩＭＥを呼び出す。Windows（登録商標）上のＩＭＥフレームワークとしてIMM32およびTSFが利用可能である。ＩＭＥ開発者はＩＭＥフレームワーク上で変換ロジックを実現しなければならない。図２に示すように、MS-IMEおよびATOKのようなよく知られたＩＭＥは、ＤＬＬ内にコアのＩＭＥ変換ロジックを有する。これらの標準的なＩＭＥと異なり、本発明によるＩＭＥは、ローカルなクライアント−サーバモデルを採用する。コアの変換ロジックは、アプリケーションから隔離された１つの独立したプロセスとして実行される。アプリケーションに結合されたＤＬＬ（以下、ＩＭＥクライアントＤＬＬと呼ぶ。）は、状態のない表示機能を実現する。すなわち、ＩＭＥクライアントＤＬＬは、候補のウィンドウを表示し、テキストを強調表示し、ユーザからのマウス／キーボードイベントを取得する役割のみを果たす。ＩＭＥクライアントＤＬＬはＩＰＣ（プロセス間通信）を介してほとんど全てのキーボード／マウスイベントをＩＭＥサーバプロセスに送信し、表示情報を取得する。

本発明によるＩＭＥは、移植性のあるクライアント−サーバモデルを採用する。ここで、クライアント−サーバは、ＯＳ上のローカルなサーバであって、クライアントの変換リクエストに対してサービスを提供する。遠隔のコンピュータ上のサーバプロセスではないが、オンラインでの変換も実現可能である。また、Windows（登録商標）、Macintosh（登録商標）、Linux（登録商標）をサポートする場合、クライアントはプラットフォームに固有のいくらかのコードが必要であるが、サーバはできる限りプラットフォームから独立にすることができる。

図３に示すように、サーバは、プラットフォームから独立であり、可能な限り全ての処理を行う。
クライアントは、プラットフォームに固有のフレームワーク（例えば、Windows（登録商標）用のIMM32またはTSF）を用いて実現される。クライアントは、状態のないイベントリスナおよびＧＵＩ表示部を有するシンクライアントである（Windows（登録商標）においては、イベントリスナとＧＵＩ表示部も分離されている）。
クライアントはサーバに全てのキー入力イベントを送信し、サーバはクライアントに表示情報を返送する(Windows（登録商標）においては、サーバから送信された表示情報に、座標などの描画情報を付与して、ＧＵＩ表示部で表示している)。

＜サンドボックスライブラリ＞
本発明によるＩＭＥサーバプロセスは、安全なサンドボックス内で起動される。これは、Google Chrome（Google社が開発したウェブブラウザ）のために使用されるサンドボックスライブラリを使用することができる。
ＩＭＥサーバプロセスのサンドボックス内での起動に関するプログラムコードの例を以下に示す。

wchar_t mozc_server_path[MAX_PATH];
if (S_OK != ::SHGetFolderPathW(NULL,
CSIDL_PROGRAM_FILES,
NULL,
SHGFP_TYPE_CURRENT,
mozc_server_path)) {
LOG(ERROR) << "cannot find Program and Files";
return false;
}
wcsncat_s(mozc_server_path, MAX_PATH,
L"\\Google\\Mozc\\mozc_server.exe",
_TRUNCATE);
HANDLE job_handle = 0;
// Create a Job inside restricted sandbox environment.
const DWORD err_code = sandbox::StartRestrictedProcessInJob(
mozc_server_path,
sandbox::USER_INTERACTIVE, // main token
sandbox::USER_INTERACTIVE, // impersonate token
sandbox::JOB_LOCKDOWN, // job token
sandbox::INTEGRITY_LEVEL_LOW, // integritiy level
&job_handle);
if (ERROR_SUCCESS != err_code) {
LOG(ERROR) << "cannot launch mozc_server: " << ::GetLastError();
return false;
}

sandbox::StartRestrictedProcessInJob()はサンドボックスでプロセスを開始させる便利な静的メソッドである。このメソッドは３つのパラメータ、main_token_level、impersonate_token_level、job_token_levelを受け取る。本発明の実装においては、Windows Vista（Windowsは登録商標）以後に導入された整合性レベルを設定できるように、元のコードを修正した。

＜ＩＭＥサーバが通常のプロセスとして起動されることを防止する＞
ＩＭＥサーバが通常のプロセスとして起動されることを防止するために、ＩＭＥサーバは、最初に、自身のプロセスが正しいサンドボックス環境内で実行されているかをチェックする。より詳しくは、次の健全性チェック（sanity check）が実行される。戻り値がServerUtil::DENYであるとき、ＩＭＥサーバプロセスは起動されない。
健全性チェックに関するプログラムコードの例を以下に示す。

HANDLE hToken = NULL;
// Open process token,
if (!::OpenProcessToken(::GetCurrentProcess(), TOKEN_QUERY, &hToken)) {
return ServerUtil::DENY;
}
// If CurrentProcess doesn't have RESTRICTED token, return ServerUtil::DENY
if (!::IsTokenRestricted(hToken)) {
::CloseHandle(hToken);
return ServerUtil::DENY;
}
TOKEN_STATISTICS ts;
DWORD dwSize = 0;
// Use token logon LUID instead of user SID, for brevity and safety
if (!::GetTokenInformation(hToken, TokenStatistics,
(LPVOID)&ts, sizeof(ts), &dwSize)) {
::CloseHandle(hToken);
return ServerUtil::DENY;
}
::CloseHandle(hToken);
// Do not execute the server if i'm system
const LUID SystemLuid = SYSTEM_LUID;
const LUID LocalServiceLuid = LOCALSERVICE_LUID;
const LUID NetworkServiceLuid = NETWORKSERVICE_LUID;
if (EqualLuid(SystemLuid, ts.AuthenticationId) ||
EqualLuid(LocalServiceLuid, ts.AuthenticationId) ||
EqualLuid(NetworkServiceLuid, ts.AuthenticationId)) {
return ServerUtil::DENY;
}
OSVERSIONINFO osi = { 0 };
osi.dwOSVersionInfoSize = sizeof(osi);
if (!::GetVersionEx(&osi)) {
return ServerUtil::DENY;
}
// Vista or later (Check the current session id is not 0)
if (osi.dwMajorVersion >= 6) {
// SessionId == 0 is special env.
DWORD dwSessionId = 0;
if (!::ProcessIdToSessionId(::GetCurrentProcessId(), &dwSessionId) ||
dwSessionId == 0) {
return ServerUtil::DENY;
}
}
// mozc_server's main thread is impersonated.
if (!::RevertToSelf()) {
return ServerUtil::DENY;
}
// OK my process is inside a safe environment!
return ServerUtil::NORMAL;

＜クライアント−サーバのＩＰＣ＞
Windows（登録商標）環境でクライアント／サーバを実現するために、ＣＯＭ（Component Object Model）を使用することが推奨されている。しかし、Windows Vista（Windowsは登録商標）の場合、アプリケーションが「高」整合性レベルで起動されると、本発明によるＩＭＥ ＣＯＭサーバも「高」整合性レベルで起動される。「低」整合性レベル、「中」整合性レベルの場合も同様である。従って、Windows Vista（Windowsは登録商標）の場合、異なる整合性レベルを有する３つのＩＭＥサーバ（ＣＯＭインスタンス）が同時に起動される。本発明によるクライアント−サーバモデルにおいて、ユーザ当たり１つのＩＭＥサーバインスタンスは強い制約であり、複数のインスタンスを許容する次善策は望まない。

＜ＩＰＣモデル＞
一実施形態によるＩＭＥは、単一スレッド、単一接続モデルを採用する。ＩＭＥサーバは１つのポートのみオープンし、ＩＭＥクライアントからの複数の接続を処理する。このモデルを採用する主な理由は、簡単さと良好な移植性である。ほとんど全てのプラットフォームが単一スレッド、単一接続のＩＰＣをサポートしている。

＜ＩＰＣの細分性（granularity）＞
ＩＭＥクライアントは、全てのキー入力イベント（例えば、‘A’のキーを押した。）をサーバに送信し、そのキー入力イベントに対応する表示情報（例えば、‘A’は、下線を付して日本語“あ”として表示せよ。）を取得する。接続は状態がない。一般に、ＩＰＣ接続の持続時間はたいへん短い。ＩＭＥサーバが表示情報の応答を完了すると、即座に接続を閉じて、他の接続を待つ。

＜ＩＰＣタイムアウト＞
単一接続／単一スレッドモデルの課題の１つは、悪意のあるユーザがＩＭＥサーバに接続して何も行わないならば、ＩＭＥサーバはブロックされる（処理の進行を妨げられる）ことである。また、逆の場合も生じうる。悪意のあるＩＭＥサーバがＩＭＥクライアントに何も応答を送信しないならば、ＩＭＥクライアントはブロックされる。
このような場合を防止するために、ＩＰＣ接続はタイムアウトを実行すべきである。サーバ／クライアントがある時間内（例えば、５００ミリ秒以内）にメッセージを送信しないならば、サーバ／クライアントは現在の接続を終了する。Windows（登録商標）において、そのようなタイムアウトは、オーバーラップＩ／Ｏ（Overlapped I/O）を使用することによって容易に実現される。
タイムアウトに関するプログラムコードの例を以下に示す。

bool SendIPCMessage(HANDLE handle,
const char *buf, size_t buf_length, int timeout) {
if (buf_length == 0) {
return false;
}
OVERLAPPED Overlapped;
::ZeroMemory(&Overlapped, sizeof(Overlapped));
bool error = false;
while (buf_length > 0) {
if (!::WriteFile(handle, buf,
static_cast<DWORD>(buf_length), NULL, &Overlapped) &&
ERROR_IO_PENDING != ::GetLastError()) {
error = true;
break;
}
if (WAIT_OBJECT_0 != ::WaitForSingleObject(handle, timeout)) {
LOG(WARNING) << "Write timeout: " << timeout;
error = true;
break;
}
DWORD size = 0;
if (!::GetOverlappedResult(handle, &Overlapped, &size, TRUE)) {
error = true;
break;
}
buf_length -= size;
buf += size;
}
return !error;
}

＜名前付きパイプのパス名＞
実行されるプログラム同士がコンピュータ内部でデータをやり取りするプロセス間通信の方式の１つに名前付きパイプがある。
名前付きパイプのパス名は他のユーザから予測不可能であるべきである。そうでないと、悪意のあるユーザは、有効なＩＭＥサーバが開始する前に、偽物の名前付きパイプのＩＭＥサーバを生成することができる。さらに、悪意のあるユーザは、ＩＭＥサーバがパス名を生成するためにユーザ名を使用していると、それを発見することができるので、パス名の生成にユーザ名を使用することは安全ではない。

一実施形態によるＩＭＥでは、１２８ビットのランダムなパス名を使用する。下記のGetSecureRandomSequence()はパス名を生成するために使用される。標準的なrand()関数は、その結果が予測可能でありうるので、安全ではない。
パス名の生成に関するプログラムコードの例を以下に示す。

bool Util::GetSecureRandomSequence(char *buf, size_t buf_size) {
memset(buf, '\0', buf_size);
HCRYPTPROV hprov;
if (!::CryptAcquireContext(&hprov,
NULL,
NULL,
PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT)) {
return false;
}
if (!::CryptGenRandom(hprov,
static_cast(buf_size),
reinterpret_cast(buf))) {
::CryptReleaseContext(hprov, 0);
return false;
}
::CryptReleaseContext(hprov, 0);
}

図４は、Windows（登録商標）においてコンピュータが管理しているプロセスを一覧表示するprocess explorerのウィンドウを表わす。ウィンドウ内の下部の太線で囲まれた部分を見ると、名前付きパイプのパス名に乱数列が使用されていることが分かる。

＜ＩＭＥクライアントＤＬＬがパス名を知る方法＞
ＩＭＥサーバが名前付きパイプのパス名を生成すると、そのパス名をユーザプロファイルディレクトリ内に保存する。ユーザプロファイルディレクトリの場所は、例えば、次の通りである。なお、<user>はユーザ名を表わし、<IME>はＩＭＥに付与した固有の名称を表わす。
Windows XP（Windowsは登録商標）の場合
c:\Document Setting\<user>\Local Settings\Application Data\google\<IME>
Windows Vista（Windowsは登録商標）またはWindows 7（Windowsは登録商標）の場合
c:\Users\<user>\AppData\LocalLow\google\<IME>
Linux（登録商標）またはMacintosh（登録商標）の場合
~/.<IME>/

このユーザディレクトリ内のキーを共有することは、基本的に安全であるが、いくらかのセキュリティ上の懸念事項が存在する。Windows Vista（Windowsは登録商標）においてLocalLowフォルダは最も安全でない場所と考えられている。「中」／「高」整合性レベルで実行される任意のプロセスは、LocalLowフォルダ内のデータを信用すべきでない。

もう１つの懸念事項は、ＩＭＥサーバが起動される前に、悪意のあるアプリケーションがファイル内に偽物のパス名を保存できることである。ＩＭＥクライアントＤＬＬは、悪意のある偽物のＩＭＥサーバに接続しうる。悪意のあるアプリケーションが同じユーザアカウントで実行されると、そのようなシナリオから保護することができない。しかし、最低ラインは、異なるユーザアカウントで実行される悪意のあるユーザ／アプリケーションからセキュリティを保護すべきであるということである。いくつかのオペレーティングシステムは、ＩＭＥクライアントＤＬＬが有効なＩＭＥサーバに接続していることを知ることが可能な、プラットフォームに依存している方法を提供しているので、それを最大限利用することができる。その利用例を以下に示す。

１．ＩＭＥサーバはＩＰＣのパス名を保持するファイルをロックする。オペレーティングシステムがファイルロックの所有者を知る方法を提供するならば、それを使用することができる。
Windows（登録商標）の場合、所有者を知るための文書化されていない方法が存在するようであるが信頼できないので、それは使用しない。
Macintosh（登録商標）の場合、そのようなＡＰＩは存在しない。
Linux（登録商標）の場合、Linux（登録商標）のファイルロックは単に勧告のロックである。ファイルロックそれ自体は信頼できない。

２．オペレーティングシステムが、ＩＰＣの相手のプロセスＩＤを提供するならば、それを使用することができる。
Windows Vista（Windowsは登録商標）の場合、相手のプロセスＩＤを知るＡＰＩが存在するので、それを使用することができる（http://msdn.microsoft.com/en-us/library/aa365446(VS.85).aspx）。
Windows XP（Windowsは登録商標）の場合、同等なＡＰＩは存在しない。
Macintosh（登録商標）の場合、同等なＡＰＩは存在しない。
Linux（登録商標）の場合、Unix Domainソケット（Unixは登録商標）を用いて相手のpidを知ることができる。/proc/<pid>/execを読み出すことによって、パスを知ることができる。

３．ＩＰＣを介してＰＩＤを送信する。
Windows XP（Windowsは登録商標）、Macintosh（登録商標）は、相手のpidを知るためのサポートはないので、ＩＰＣを介してＰＩＤを送信することができる。これは、不慮の攻撃を防止することができる。

＜サーバ接続は単一であるべきである＞
CreateNamedPipeのデフォルトパラメータを用いた、同じパス名を有する複数のNamedPipeサーバのインスタンス（プロセス）は許容される。これは致命的なセキュリティホールとなりうる。悪意のあるアプリケーションは、同じパス名を使用することによって偽物のＩＭＥサーバを容易に生成することができる。複数のインスタンス生成を防止するために、Windows XP（Windowsは登録商標）以降にFILE_FLAG_FIRST_PIPE_INSTANCEフラグが導入された。詳細は
http://msdn.microsoft.com/en-us/library/aa365150(VS.85).aspx
を参照。Microsoft社によればフラグを設定することが強く推奨される。
http://support.microsoft.com/kb/308403/en
を参照。

＜CreateNamedPipe()に適切なセキュリティ属性を渡す＞
名前付きパイプは有効なユーザのみからアクセスされるべきである。有効なセキュリティ属性をCreateNamedPipe APIに渡す。図５に示すように、これは、ローカルシステム、管理者、および、現在のユーザからのアクセスを許可する。他のユーザからのアクセスは許可されない。MakeSecurityAttributes関数の実装を知るためには
http://s/?fileprint=//depot/google3/experimental/mozc/third_party/sandbox/security_attributes.cc
を参照。
CreateNamedPipe APIの呼び出しに関するプログラムコードの例を以下に示す。

SECURITY_ATTRIBUTES SecurityAttributes;
if (!sandbox::MakeSecurityAttributes(&SecurityAttributes)) {
LOG(ERROR) << "Cannot make SecurityAttributes";
return;
}
// Create a named pipe.
wstring wserver_address;
Util::UTF8ToWide(server_address.c_str(), &wserver_address);
handle_ = ::CreateNamedPipe(wserver_address.c_str(),
PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED |
FILE_FLAG_FIRST_PIPE_INSTANCE,
PIPE_TYPE_MESSAGE |
PIPE_READMODE_MESSAGE |
PIPE_WAIT,
(num_connections <= 0 ?
PIPE_UNLIMITED_INSTANCES : num_connections),
sizeof(request_),
sizeof(response_),
0,
&SecurityAttributes);
if (handle_ == INVALID_HANDLE_VALUE) {
LOG(FATAL) << "CreateNamedPipe failed" << ::GetLastError();
return;
}

＜なりすましを防止する＞
名前付きパイプのなりすましを不可能にしなければならない。そうでなければ、悪意のあるＩＭＥサーバはクライアント接続をなりすますことができ、クライアント権限で悪意のあるコードを実行することができる。名前付きパイプのなりすましを不可能にするために“SECURITY_SQOS_PRESENT|SECURITY_IDENTIFICATION|SECURITY_EFFECTIVE_ONLY”フラグをCreateFile APIに渡す。CreateFile APIの呼び出しに関するプログラムコードの例を以下に示す。

// Connecting to mozc server
handle_ = ::CreateFile(wserver_address.c_str(),
GENERIC_READ | GENERIC_WRITE,
0, NULL, OPEN_EXISTING,
FILE_FLAG_OVERLAPPED |
SECURITY_SQOS_PRESENT |
SECURITY_IDENTIFICATION |
SECURITY_EFFECTIVE_ONLY,
NULL);

これらのフラグを渡すことで、悪意のあるＩＭＥサーバはクライアント接続をなりすますことができない。

＜セッション管理＞
次に、本発明によるＩＭＥサーバが複数のアプリケーションからの複数の変換リクエストをどのように管理するかを説明する。１つのアプリケーションは、現在の入力モード、現在の変換状態、等を保持する１つのセッションをオープンする。全てのセッションが互いに隔離されていることを保証しなければならない。

＜セッション管理プロトコル＞
ＩＭＥクライアントＤＬＬは、最初に、セッションＩＤをＩＭＥサーバに要求する。セッションはこのセッションＩＤを用いて管理される。例えば、キー入力イベント‘a’がセッションＩＤとともに送信される。ＩＭＥサーバは、セッションＩＤを見ることによってどのアプリケーション（セッション）が‘a’のキーを受信したかを知ることができる。もはや現在のセッションにアクセスする必要がないならば、ＩＭＥクライアントはDeleteSessionリクエストを呼び出すことができる。
ＩＭＥクライアント＞CreateSession
ＩＭＥサーバ ＞Your session id is 123
ＩＭＥクライアント＞SendKey 123 ‘a’
ＩＭＥサーバ ＞...
...
ＩＭＥクライアント＞DeleteSession 123
セッションメッセージは、protocol buffer 2（オープンソースのプロトコルバッファ）を使用することによって平文のバイト列に符号化される。

＜他のプロセスから自分のセッション情報を隠蔽する＞
セッションＩＤは、他のアプリケーションから予測不可能であるべきである。そうでなければ、悪意のあるクライアントは、偽物のリクエストを送信し、間接的にセッション情報を編集することができる。ＩＭＥサーバは上述したCreateRandomSequence関数を用いてランダムなセッションＩＤ（符号なし６４ビット整数）を生成する。総当たり攻撃によって有効なＩＤを取得することは可能であるが、予測可能なセッションＩＤ（連続したＩＤ、等）を使用するよりずっと安全である。

＜ＤｏＳ（Denial of Service）攻撃を防止する＞
悪意のあるクライアントが膨大な数の偽物のCreateSessionリクエストを送信すると、ＩＭＥサーバはヒープメモリを消費し、結局、クラッシュする。そのような場合を防止するために、全てのセッションＩＤは、一種の固定のＬＲＵ（least recently used）キャッシュによって管理される。例えば、サイズは６４に設定される。有効なセッションのサイズが６４に到達すると、ＩＭＥサーバは最も古いセッションを削除する。この処理は、CreateSessionリクエストへの全てのＤｏＳ攻撃を常に阻止するとは限らないが、少なくとも意図しないメモリ消費を防止することができる。それに加えて、ＤｏＳ攻撃を止めるために次の処理を追加することができる。
・CreateSessionが呼び出されたとき、１秒（１秒は任意である。）以内に他のCreateSessionを要求することができない。
・ＩＭＥクライアントが、３０秒間、（SendKeyのような）リクエストを送信しないとき、セッションは自動的に削除される。この処理はゾンビセッションを消去する。
・ＩＭＥクライアントが、CreateSessionの後に、２分間、リクエストを送信しないとき、セッションは自動的に消去される。
・ＩＭＥクライアントＤＬＬは、ＩＭＥサーバによってセッションが消去されたときでも、変換を維持するために十分にロバストであるべきである。

次に、移植性の課題を解決する観点から、第２実施例を説明する。

本発明では、ＩＭＥの機能を実現するために、クライアント−サーバモデルを採用する。その理由の１つは移植性である。本発明によるＩＭＥサーバは、ＩＭＥのコアとなる機能をできる限り移植性を有するようにコーディングし、その機能を１つのプロセスに配置することによって、各種の動作環境（Windows（登録商標）、Macintosh（登録商標）、Linux（登録商標））で動作可能となり、オペレーティングシステムの機能を知る必要がなく、それ自身の方法で機能を提供する。ＩＭＥサーバのいくつかのルーチンは、ＩＭＥサーバのインタフェースを覆い隠し、各々のオペレーティングシステムのＩＭＥ ＡＰＩを処理する。

ＩＭＥサーバは全てのＩＭＥ機能を処理する。これは、ローマ字−かな変換（または他の入力方法）、Ｆ７のようなメタコマンド、かな−漢字変換、ユーザ履歴学習、注釈、予測入力、および、他の任意の機能を提供する。ＩＭＥクライアントはユーザとの相互作用を処理する。ＩＭＥクライアントはイベントリスナおよびＧＵＩ表示機能の役割を果たすと考えることができる。

すなわち、本発明によるＩＭＥサーバはプラットフォームに依存せず、可能な限り全てを処理する機能豊富なサーバ（fat server）である。これに対し、ＩＭＥクライアントは、プラットフォーム固有のフレームワーク（例えば、Windows（登録商標）についてIMM32またはTSF）を用いて実装され、状態のないイベントリスナおよびＧＵＩ表示機能の役割を果たし、全てのキー入力イベントをＩＭＥサーバに送信し、ＩＭＥサーバから返送される表示情報を用いて表示するシンクライアントである。

ユーザがテキストを入力するテキストアプリケーションがただ１つであっても、ユーザのデスクトップ上に複数のアプリケーションが存在可能であり、ユーザは、しばしば、テキストを入力している間でもフォーカスするアプリケーションを切り換える。従って、各テキストアプリケーションについての入力状態を保持することが望ましい。本発明によるＩＭＥサーバは、複数のリクエストを受け入れ、それらを処理することができる。各々の入力状態を“セッション”と呼び、セッションは番号であるセッションＩＤによって識別される。

本発明によるＩＭＥサーバは、キープアライブ接続をサポートしない。本発明によるＩＭＥクライアントは、ＩＭＥサーバへの接続を生成し、コマンドを送信し、応答を受信し、そして、切断する。従って、各々のコマンドはセッションＩＤを含まなければならない。１つの例外は“CreateSession”と呼ぶコマンドである。ＩＭＥクライアントがセッションＩＤなしでこのコマンドを呼び出すと、ＩＭＥサーバはセッションを生成し、セッションＩＤをＩＭＥクライアントに返送する。

＜サーバプロセスの起動＞
ＩＭＥクライアントはＩＭＥサーバを共有する。ＩＭＥサーバがまだ起動されていないと、ＩＭＥクライアントはＩＭＥサーバを起動する。各々のユーザは、各々のＩＭＥサーバに接続する。ユーザはＩＭＥサーバを共有しない。複数のコンピュータは、そのうちの１つのコンピュータ上のＩＭＥサーバを共有しない。従って、クライアント−サーバ接続は１つのコンピュータ内で閉じている。１つのコンピュータが複数のデスクトップを有するときでも、１つのＩＭＥサーバが存在する。ＩＭＥサーバは、ユーザ履歴のようなデータをユーザのホームディレクトリに保存することが可能である。しかし、この場合、例えば、ＮＦＳ（ネットワークファイルシステム）を使用して複数のコンピュータの間でそのホームディレクトリを共有するようなことは行うべきでない。

・１ログインユーザに対して、１つのＩＭＥサーバプロセス。
・１つのコンピュータ上の複数のデスクトップに対して、１つのＩＭＥサーバプロセス。なお、１つのユーザプロファイルに２つのコンピュータがアクセスした場合は検討を要する。
・１つのＩＭＥサーバプロセスに対して、１つの変換部インスタンス。すなわち、変換部は単一のものである。
・１サーバプロセスに対して、複数接続。
・接続はワンショットであり、キープアライブは行わない。
・コンテキスト（セッション）はセッションＩＤによって管理される。
・２つのアプリケーションが同じセッションＩＤを使用するとき、ＩＭＥサーバは１つのスレッドなので、セッションＩＤをロックする必要はない。
・ＩＭＥサーバは単一のスレッドである。
・変換部における全てのメソッドはスレッドセーフでなければならない。排他的な動作が存在するならば、ロックを行う。

このＩＭＥアーキテクチャは、“ＩＭＥクライアント”および“ＩＭＥサーバ”の２つのコンポーネントからなる。ＩＭＥクライアントおよびＩＭＥサーバは、異なるコンテキスト、例えば、異なるプロセス、および／または、異なるコンピュータで実行される。

＜ＩＭＥクライアント＞
ＩＭＥクライアントは、各々のオペレーティングシステムが提供するＩＭＥフレームワーク上で実現される。ＩＭＥクライアントが行うのは、ユーザのキー入力イベント（例えば、“a”のキーが押された。）を取得すること、このキー入力イベントをＩＭＥサーバに送信すること、ＩＭＥサーバはクライアントが送信したキー入力イベントに対応する表示情報（例えば、下線を付して日本語“あ”を表示せよ。）を返送するので、それを表示すること、のみである。ＩＭＥクライアントは状態を管理しない。

本発明によるＩＭＥクライアントの役割は限られているので、ＩＭＥフレームワークへの依存度は他のＩＭＥクライアントよりずっと小さい。本発明によるＩＭＥクライアントの実装は他のＩＭＥクライアントより容易である。

ＩＭＥクライアントは、ユーザが適切な候補を選択する候補のリストを表示する。ＩＭＥクライアントは、このリストを表示するために任意の実装を使用することができる。ウェブアプリケーションについては、Ajax（Asynchronous JavaScript + XML（JavaScriptは登録商標））およびJavaScript（JavaScriptは登録商標）を使用することができる。

＜ＩＭＥサーバ＞
ＩＭＥサーバは、ＩＭＥクライアントと異なるプロセスで実行される。接続のためにＲＰＣを使用するならば、ＩＭＥサーバは異なるコンピュータで実行されうる。ＩＭＥサーバは、任意のＩＭＥフレームワーク上で実装する必要がないので、ＩＭＥサーバの実装はより移植性が高くなる。異なるプラットフォーム上で動作する、異なるＩＭＥクライアントは同一のＩＭＥサーバに接続することができる。ＩＭＥサーバは、全てのキー入力イベントを処理し、表示情報をＩＭＥクライアントに返送する。表示情報は、アプリケーションに表示すべき現在の（部分的に）変換された日本語テキストおよび候補ウィンドウの内容を含む。

ここで、ＩＭＥクライアントとＩＭＥサーバの間のプロトコルシーケンスの一例を示す。セッションＩＤは異なるＩＭＥクライアントを識別するために使用される。
１．ＩＭＥクライアント→ＩＭＥサーバ： 新たなセッションを生成せよ。
２．ＩＭＥサーバ→ＩＭＥクライアント： ＯＫ。あなたのセッションＩＤは１２３。
３．ＩＭＥクライアント→ＩＭＥサーバ： ‘a’が押された。ＩＤは１２３。
４．ＩＭＥサーバ→ＩＭＥクライアント： 現在の行に下線を付して“あ”と表示せよ。
５．ＩＭＥクライアント→ＩＭＥサーバ： ‘i’が押された。ＩＤは１２３。
６．ＩＭＥサーバ→ＩＭＥクライアント： 現在の行に下線を付して“あい”と表示せよ。
７．ＩＭＥクライアント→ＩＭＥサーバ： ‘ ’（空白）が押された。ＩＤは１２３。
８．ＩＭＥサーバ→ＩＭＥクライアント： 現在の行に“愛”と表示せよ。
９．ＩＭＥクライアント→ＩＭＥサーバ： ‘ ’（空白）が押された。ＩＤは１２３。
１０．ＩＭＥサーバ→ＩＭＥクライアント： 現在の行に“愛”と表示し、内容が［愛、合、あい、相、．．．］である候補ウィンドウを表示し、第１候補を強調表示せよ。
１１．ＩＭＥクライアント→ＩＭＥサーバ： “down”キーが押された。ＩＤは１２３。
１２．ＩＭＥサーバ→ＩＭＥクライアント： 現在の行に“合”と表示し、内容が［合、あい、相、．．．］である候補ウィンドウを表示し、第２候補を強調表示せよ。
１３．ＩＭＥクライアント→ＩＭＥサーバ： “enter”キーが押された。ＩＤは１２３。
１４．ＩＭＥサーバ→ＩＭＥクライアント： アプリケーションにテキスト“合”を送信せよ。
１５．・・・
１６．ＩＭＥクライアント→ＩＭＥサーバ： セッション１２３を消去する。
１７．ＩＭＥサーバ→ＩＭＥクライアント： ＯＫ。終了。

ステップ１において、ＩＭＥクライアントは新たなセッションを生成する。ＩＭＥサーバは新たなセッションＩＤを発行し、これは各ＩＭＥクライアントを識別するために使用される。ユーザが‘a’のキーを押すとその情報が直接にサーバに送信される。ＩＭＥサーバは、日本語のひらがな“あ”を現在の行に表示すべきであることを返送する。続いて、ユーザが‘i’のキーを押すと、ステップ６において、ＩＭＥサーバは“あい”を表示すべきであることを返送する。“あい”はステップ３およびステップ５で送信されたユーザのキー入力列に対応する。すなわち、“ai”が“あい”に対応する。

ＩＭＥクライアントについて、プロトコルは状態がないという意味で、ステップ３およびステップ５は全く独立である。日本語ＩＭＥにおいて、‘ ’（空白）は“変換”キーに割り当てられる。ステップ８において、ＩＭＥサーバは、発音が“ai”である、最も可能性のある日本語テキストを返送する。ステップ９において、ユーザは、再度、空白を押すことによって全ての可能性のある候補を展開することを試みる。ステップ１０において、ＩＭＥサーバは同じ発音“ai”を有する複数の全ての候補のリストを返送する。

他の言語についての新たなＩＭＥの実装は、上述したアーキテクチャを用いて容易である。言語に依存する全ての部分はＩＭＥサーバ内に実装されるので、ＩＭＥクライアントの実装を再利用することができる。ＩＭＥクライアントの実装を再利用することは移植性のために良い。

以上、ＩＰＣを用いたクライアント−サーバモデルの例を説明し、図１にＩＰＣに基づくアーキテクチャを示したが、ＩＰＣ部分をＲＰＣで置換することができる。

次に、バージョンの更新に関する課題を解決する観点から、第３実施例を説明する。

ＩＭＥクライアントとＩＭＥサーバに対して、ＩＭＥのバージョンとプロトコルのバージョンを付与する。ＩＭＥクライアントとＩＭＥサーバの一方のプロトコルのバージョンが更新されると、これらは通信することができない。プロトコルのバージョンの更新は、ＩＭＥのバージョンの更新と比較して頻度が少ない。すなわち、ＩＭＥのバージョンが更新されても、プロトコルのバージョンが更新されない場合も存在する。しかし、プロトコルのバージョンが更新されると、ＩＭＥのバージョンも更新される。
プロトコルのバージョンは、例えば、ファイル名「.session.ipc」のような.ipcファイルに保存される。.ipcファイルはprotobufでシリアライズしたメッセージである。プロトコルバッファ（http://code.google.com/p/protobug/）を更新したい場合、ipc/ipc.hファイルを修正する。列挙されたIPC_PROTOCOL_VERSIONフィールドが存在する。ＩＭＥクライアントおよびＩＭＥサーバのバージョンは、例えば、バイナリ実行形式ファイル内にエンコードされる。.ipcファイルにもＩＭＥクライアントおよびＩＭＥサーバのバージョンがエンコードされる。

本発明によるＩＭＥクライアントは、動作しているＩＭＥサーバとのプロトコルの互換性、動作しているＩＭＥサーバのバージョンをチェックする。ＩＭＥクライアントは、この互換性およびバージョンに基づいて動作を変更する。次の４つのケースがありうる。

＜ケース１＞
ＩＭＥクライアントのバージョンがＩＭＥサーバのバージョンと同じである場合、これは通常の場合であり、特別な動作はしない。
＜ケース２＞
ＩＭＥクライアントのバージョンがＩＭＥサーバのバージョンより新しい場合、ＩＭＥクライアントはＩＭＥサーバを再起動する。すなわち、ＩＭＥサーバプログラムの実行を停止させ、新たなプログラムバージョンのＩＭＥサーバプログラムをメモリに読み込ませ、実行させる。
＜ケース３＞
ＩＭＥクライアントのバージョンがＩＭＥサーバのバージョンより古く、プロトコルが互換性を有する場合、ＩＭＥクライアントはＩＭＥサーバとの接続を維持する。
＜ケース４＞
ＩＭＥクライアントのバージョンがＩＭＥサーバのバージョンより古く、プロトコルが互換性を有さない場合、ＩＭＥクライアントはＩＭＥサーバとの接続を中止する。

ケース１、２、３の場合、ＩＭＥサーバを安全に更新することができる。ケース４の場合、古いバージョンのＩＭＥクライアントは新たなバージョンのＩＭＥサーバに接続できないという問題を有する。しかし、これは、通常の更新に対して稀なケースとすることができる。新たなバージョンのＩＭＥサーバが新たなバージョンおよび古いバージョンの両方のプロトコルをサポートするならば、ケース４は生じない。

例えば、コンピュータの記憶装置に保存されたＩＭＥの実行形式ファイル（ＩＭＥクライアントプログラム（一形態としてＤＬＬ）とＩＭＥサーバプログラム）が更新された後にアプリケーションプログラムが実行されると、新たなバージョンのＩＭＥクライアントプログラムが実行される。新たなバージョンのＩＭＥクライアントは、ＩＭＥサーバのバージョン、および、プロトコルのバージョンをチェックする（図６（ａ））。
新たなバージョンのＩＭＥクライアントは、動作しているＩＭＥサーバのバージョンが古いことを検出すると、古いバージョンのサーバを停止させ、新たなバージョンのＩＭＥサーバを起動させる（図６（ｂ））。
一方、ＩＭＥの実行形式ファイルの更新以前からアプリケーションとともに動作しているＩＭＥクライアントは、動作しているＩＭＥサーバのバージョンがＩＭＥクライアントのバージョンより新しいことを検出すると、そのＩＭＥクライアントは、ＩＭＥサーバのプロトコルのバージョンを参照してプロトコルの互換性をチェックする（図６（ｃ））。
プロトコルが互換性を有するならば、そのＩＭＥクライアントは新たなバージョンのＩＭＥサーバに接続する（図６（ｄ））。そうでないならば、ＩＭＥクライアントは接続を中止し、ユーザにバージョンの不一致を知らせる（図６（ｅ））。

なお、図６において、「古いクライアント（サーバ）」とは、ＩＭＥのバージョンが古いＩＭＥクライアント（サーバ）プログラムをコンピュータ上で動作させたもの、「新しいクライアント（サーバ）」とは、ＩＭＥのバージョンが新しいＩＭＥクライアント（サーバ）プログラムをコンピュータ上で動作させたものを意味する。

上記の処理を、実行形式ファイルの更新において、プロトコルのバージョンとＩＭＥのバージョンが更新された場合と、ＩＭＥのバージョンのみ更新された場合に分けて詳細に説明する。

＜プロトコルのバージョンとＩＭＥのバージョンが更新された場合＞
１．Omaha（プログラムの新バージョンを自動でインストールするGoogle社のプログラム）は、コンピュータの記憶装置に保存されているＩＭＥクライアントＤＬＬおよびＩＭＥサーバプログラムを移動してファイル名を変更する。新たなＩＭＥクライアントＤＬＬおよびＩＭＥサーバプログラムがコンピュータの記憶装置に保存される。
２．新たに起動されたアプリケーションは、新たなバージョンのＩＭＥクライアントＤＬＬをメモリに読み込む。
３．ＩＭＥクライアントがCreateSessionコマンドを送出するとき、.ipcファイルをチェックすることによってプロトコルのバージョンの不一致を検出することができる。
４．ＩＭＥクライアントのバージョンがＩＭＥサーバ（実行中のＩＭＥサーバ）のバージョンより新しい場合、ＩＭＥクライアントはＩＭＥサーバをユーザに気付かれずに再起動する。再起動はCreateSessionコマンドを送出するときのみ実行される。
５．再起動後もプロトコルのバージョン、あるいは、ＩＭＥのバージョンが変わらないならば、エラーを示すダイアログウィンドウをコンピュータのディスプレイに表示する。
６．古いバージョンのＩＭＥクライアントＤＬＬをコンピュータのメモリに読み込んだ元のアプリケーションは新たなバージョンのＩＭＥサーバと通信することができない。この場合、すなわち、ＩＭＥクライアントのプロトコルのバージョンがＩＭＥサーバのバージョンより古い場合、ＩＭＥクライアントはエラーを示すダイアログウィンドウをコンピュータのディスプレイに表示する。

＜ＩＭＥのバージョンのみ更新された場合＞
１．Omahaは、コンピュータの記憶装置に保存されているＩＭＥクライアントＤＬＬおよびＩＭＥサーバプログラムを移動してファイル名を変更する。新たなＩＭＥクライアントＤＬＬおよびＩＭＥサーバプログラムがコンピュータの記憶装置に保存される。
２．新たに起動されたアプリケーションは、新たなバージョンのＩＭＥクライアントＤＬＬをメモリに読み込む。
３．ＩＭＥクライアントがCreateSessionコマンドを送出するとき、.ipcファイルをチェックすることによってプロトコルのバージョンの不一致を検出することができる。
４．プロトコルのバージョンが互換性を有するので、ＩＭＥクライアントはＩＭＥサーバを安全に再起動することができる。再起動はCreateSessionコマンドを送出するときのみ実行される。
５．再起動後もＩＭＥサーバのバージョンが変わらないならば、エラーを示すダイアログウィンドウをコンピュータのディスプレイに表示する。
６．古いバージョンのＩＭＥクライアントＤＬＬをコンピュータのメモリに読み込んだ元のアプリケーションは古いバージョンのＩＭＥクライアントプログラムを使用する。これは、他のアプリケーションがCreateSessionコマンドを送出するときＩＭＥサーバのみ更新され、すなわち、ユーザが何かキー入力している間はＩＭＥサーバが更新されないだけであるので、大きな問題ではない。また、互換性のあるプロトコルのバージョンはクライアント−サーバ間の通信が破壊されないことを保証する。

上記では、クライアントとサーバの対応関係を特定するために、プログラムのバージョン、プロトコルのバージョンを使用したが、他の情報を用いてもよい。

次に、ＩＭＥサーバの異常終了に関する課題を解決する観点から、第４実施例を説明する。

本発明は、ＩＭＥサーバを再起動する手段、ＩＭＥサーバの再起動を検出する手段、ＩＭＥサーバが再起動されたとき、ＩＭＥクライアントから以前のキー入力列を送信する手段、１回以上ＩＭＥサーバがクラッシュしたキー入力列を送信することによって引き起こされる無限ループを防止する手段、ＩＭＥサーバをクラッシュさせるキー入力列を記録する手段を備える。

本発明によるクライアント−サーバ型のＩＭＥにおいて、ＩＭＥサーバは状態を認識し、キー入力イベントを受信して表示情報を返送する。ＩＭＥクライアントは状態がなく、ユーザの各々のキー入力イベントを送信してサーバから表示情報を受信し、それを適切なユーザインタフェースに表示する。ユーザがＩＭＥをターンオンしたとき、ＩＭＥサーバは動作していなければならず、ＩＭＥサーバが異常終了したときでも、ＩＭＥサーバはＩＭＥクライアントから再起動される。本発明によるＩＭＥクライアントは、入力セッションの間、キー入力列を保持し、ＩＭＥサーバが再起動されたとき、それを再送する。

本発明は、ＩＭＥに利用することができる。

１、２、３ ・・・ アプリケーション

Claims (4)

1. コンピュータによって実施される方法であって、
   インプットメソッドエディタ（ＩＭＥ）クライアントにおいてキーイベントを生成するステップであって、前記ＩＭＥクライアントは、前記ＩＭＥクライアントがＩＭＥサーバへ発行する要求のみを保存するとともに各キーイベントに対して前記ＩＭＥサーバへの要求を発行するステートレスなＩＭＥクライアントである、ステップと、
   前記ＩＭＥクライアントがキーイベント列の中の前記キーイベントを記録するステップであって、前記キーイベント列は、前記キーイベントと、前記ＩＭＥサーバへ以前に送信された少なくとも１または２以上の以前のキーイベントとを保存する、ステップと、
   前記ＩＭＥクライアントと通信するＩＭＥサーバへ前記キーイベントを送信するステップであって、前記ＩＭＥサーバは、前記ＩＭＥサーバおよび前記ＩＭＥクライアント間の通信セッションの要求および応答の両方を保存するステートフルなサーバである、ステップと、
   前記ＩＭＥクライアントにおいて、前記ＩＭＥサーバが機能を停止したことを判定するステップと、
   前記ＩＭＥサーバが機能を停止したことの判定に応答して、ステートフルなサーバである第２のＩＭＥサーバとのセッションを確立するステップと、
   前記セッションの確立後に、前記記録されたキーイベント列を前記第２のＩＭＥサーバに送信するステップとを有する方法。
2. 前記第２のＩＭＥサーバは、前記ＩＭＥサーバを再起動することにより作られる請求項１に記載のコンピュータによって実施される方法。
3. 異常終了の結果として、前記ＩＭＥサーバが機能を停止する請求項１に記載のコンピュータによって実施される方法。
4. 前記キーイベント列を保持するステップをさらに有する請求項１に記載のコンピュータによって実施される方法。