JP2013541769A - 入力ツール呼出システム、方法およびプロキシ装置 - Google Patents

Abstract

入力ツール呼出システム、方法とプロキシ装置であって、インストール可能ＯＳがローカルＯＳの入力ツール、例えば、ローカルＯＳのソフトウェアキーボード、又はローカルＯＳの入力法、又はローカルＯＳのソフトウェアキーボードと入力法を呼び出し可能となり、入力操作が実行できるようになる。入力ツールがインストールされていないＯＳでさえ、ローカルＯＳの入力ツールを呼び出すことにより入力操作を実行でき、又、各ＯＳ毎に対する入力ツールの重複インストールによりシステムリソースが大量に消費される問題点も回避できるようになる。

Description

本出願は２０１０年０９月３０日に、中国特許局に出願した、出願番号が２０１０１０５０４１５１．２で、発明の名称が「入力ツール呼出システム、方法およびプロキシ装置」である中国特許出願願書の優先権を要求し、その開示の総ての内容を本出願に組み込む。
本発明は通信領域に関し、特に入力ツール呼出システム、方法およびプロキシ装置に関する。

技術の進化とともない、オペレーションシステム（以下はＯＳと略称する）は既に主流のスマート端末の必須のソフトウェア環境となり、もいよいよとスマート端末のＯＳ分野において、一台のスマート端末に複数のＯＳが共存するＯＳの融合も段々導入されてきた。スマート端末に共存する各ＯＳが相互に隔離されているため、各ＯＳには、ソフトウェアキーボードと入力法が独立にインストールされる必要がある。入力を必要とする場合、各ＯＳに対応するソフトウェアキーボードと入力法を選択して入力する。

スマート端末に複数のＯＳがインストールされる際、以下の問題点が存在する。
１、対応するソフトウェアキーボードと入力法がインストールされていないＯＳの場合、当該ＯＳを作動する際、入力操作ができない。
２、各ＯＳの可用性を確保するため、ＯＳごとにソフトウェアキーボードと入力法を独立にインストールする必要があることにより、端末領域はソフトウェアキーボードと入力法辞書の重複インストールにより大量に消費される。

本発明に係る実施形態によれば、対応するソフトウェアキーボードと入力法がインストールされていないＯＳにおいて、ＯＳを作動する際に入力操作ができないこと、及びシステム領域が入力ツールの重複インストールにより大量に消費されるという従来技術の問題点を解決する、入力ツール呼出システム、方法とプロキシ装置が提供される。

本発明に係る入力ツール呼出システムは
入力要求を開始するためのインストール可能ＯＳと、
前記入力要求を受信し、インストール可能ＯＳに利用可能な入力ツールがないと判断した場合、ローカルＯＳをトリガーするプロキシモジュールと、
プロキシモジュールにトリガーされると、自身の入力ツールを起動するローカルＯＳと
を含む。

本発明に係る入力ツールの呼出方法は、
インストール可能ＯＳからの入力要求を受信した場合、インストール可能ＯＳに利用可能な入力ツール利用可能な入力ツールがあるかどうかを判断するステップと、
インストール可能ＯＳに利用可能な入力ツールがないと判断した場合、ローカルＯＳ自身の入力ツールを起動して表示することをローカルＯＳに指示するステップと
を含む。

本発明に係るプロキシ装置は
インストール可能ＯＳからの入力要求を受信し、インストール可能ＯＳに利用可能な入力ツールがあるかどうかを判断する管理ユニットと、
インストール可能ＯＳに利用可能な入力ツールがない場合、ローカルＯＳをトリガーするプロキシユニットと
を含む。

本発明の実施形態に係る入力ツール呼出システム、方法とプロキシ装置により、インストール可能ＯＳはローカルＯＳの入力ツールを呼出可能となり、入力操作ができるようになる。本発明の技術案により、入力ツールがインストールされていないＯＳでさえ、ローカルＯＳの入力ツールを呼び出すことにより入力操作を実行でき、又、ＯＳ毎に対する入力ツールの重複インストールによりシステムリソースが大量に消費される問題点も回避できるようになる。

本発明の実施形態又は従来技術の技術案を明確に説明するため、以下は実施形態又は従来技術を記述するための図面を簡単に説明する。無論、下記の付図は本発明の一部の実施形態だけであり、本分野の技術者は創作的な労働を支払わない前提で、以下の付図により他の付図を取得することもできる。
本発明の第一の実施形態に係る入力ツール呼出システムの構造を示す図である。 本発明の第二の実施形態に係る入力ツール呼出方法のフロー図である。 本発明の第三の実施形態に係るソフトウェアキーボード呼出システムの構造を示す図である。 本発明の第四の実施形態に係るソフトウェアキーボード呼出方法のフロー図である。 本発明の第四の実施形態に係るソフトウェアキーボードを起動する際の通信フロー図である。 本発明の第五の実施形態に係る入力法呼出システムの構造を示す図である。 本発明の第六の実施形態に係る入力法呼出方法のフロー図である。 本発明の第六の実施形態に係る入力法を起動する際の通信フロー図である。 本発明の第七の実施形態に係るデータ入力システムの構造を示す図である。 本発明の第八の実施形態に係るデータ入方法のフロー図である。 本発明の第九の実施形態に係るプロキシ装置的の構造を示す図である。

異なるＯＳが入力ツールを共有できないことによって生じる様々な問題点に対して、本発明の実施形態はローカルＯＳとインストール可能ＯＳの間の入力ツールの共有を実現し、前記入力ツールはソフトウェアキーボードと／又は入力法を含む。本発明の実施形態により、インストール可能ＯＳに対してソフトウェアキーボードと入力法を独立にインストールする必要がなくなり、ローカルＯＳのソフトウェアキーボードと入力法を呼び出すことにより入力を実行できる。又、ＯＳ間の切り替えがソフトウェアキーボードと入力法の切り替えを引き起こし、ユーザに不便をかけるという問題を除去し、ソフトウェアキーボードと入力法の重複インストールにより、大量な端末領域がソフトウェアキーボードと入力法辞書に使用され、システムリソースの浪費をもたらすことも解決できる。前記ローカルＯＳは端末設備が出荷時に持つＯＳを指し、前記インストール可能ＯＳはユーザーが端末設備を購入した後、自分でインストールできるＯＳのことを指す。

以下は付図と各実施形態に結合して本発明の技術案を詳細に紹介する。

第一の実施形態
本発明の第一の実施形態に係る入力ツール呼出システムの構造は図１に示すように、インストール可能ＯＳ０１とプロキシモジュール０２とローカルＯＳ０３とを含む。
前記インストール可能ＯＳ０１は入力要求を開始し、プロキシモジュール０２は前記入力要求を受信し、インストール可能ＯＳに利用可能な入力ツールがないと判断した場合、ローカルＯＳをトリガーし、ローカルＯＳ０３はプロキシモジュールのトリガーにより自身の入力ツールを起動する。

前記入力ツールはソフトウェアキーボード、又は入力法、又は入力法とソフトウェアキーボードを含む。

前記プロキシモジュール０２は管理ユニット０２１と擬似操作ユニット０２２とプロキシユニット０２３とを含む。
管理ユニット０２１は前記入力要求を受信し、インストール可能ＯＳに使用可能入力ツールがないと判断した場合、ローカルＯＳの入力ツールを介する入力データをインストール可能ＯＳに運用できる通路の確立を要求し、擬似操作ユニット０２２は管理ユニットから通路確立要求を受信した場合、当該要求を実行し、ローカルＯＳの入力ツールを介する入力イベントの検出開始を要求する。プロキシユニット０２３は擬似操作ユニットからの検出要求を受信した場合、当該要求を実行し、又、ローカルＯＳをトリガーする。

前記プロキシユニット０２３は、ローカルＯＳの入力ツールを介する入力データを検出した場合、前記データを前記擬似操作ユニットに転送する。

前記擬似操作ユニット０２２は又、確立された前記通路により受信された前記データをインストール可能ＯＳに運用する。

第二の実施形態
本発明の第二の実施形態に係る入力ツール呼出方法は図２に示すように、以下のステップを含む。
ステップ００１：インストール可能ＯＳからの入力要求を受信した場合、インストール可能ＯＳに使用可能入力ツールがあるかどうかを判断する。

本ステップにおいて、インストール可能ＯＳ上のソフトウェアインストールリストを検索するか、又は他の方法で、インストール可能ＯＳに使用可能入力ツールがあるかどうかを判断できる。例えば、インストール可能ＯＳのソフトウェアインストールリストにソフトウェアキーボードと／又は入力法ソフトウェアのインストール履歴を見つけた場合、インストール可能ＯＳに使用可能入力ツールがあると判断でき、逆の場合、インストール可能ＯＳに使用可能入力ツールがないと判断できる。

インストール可能ＯＳに使用可能入力ツールがある場合、当該入力ツールを使用し、又、第二の実施形態に係る呼出プロセスを終了し、インストール可能ＯＳに使用可能入力ツールがない場合、ステップ００２を継続する。前記入力ツールはソフトウェアキーボードと／又は入力法を含む。

ステップ００２：インストール可能ＯＳに使用可能入力ツールがないと判断した場合、ローカルＯＳ自身の入力ツールを起動することをローカルＯＳに指示する。

ローカルＯＳ自身の入力ツールを起動することをローカルＯＳに指示する際、ローカルＯＳの入力ツールを介する入力の検出を開始し、ローカルＯＳの入力ツールを介する入力データをインストール可能ＯＳに運用できる通路を確立する。

ローカルＯＳは受信された指示により自身の入力ツールを起動し、又、入力ツール起動成功メッセージを返し、自身の入力ツールが起動失敗の場合、入力ツール起動失敗メッセージを返し、第二の実施形態に係る呼出プロセスを終了する。

ステップ００３：ローカルＯＳの入力ツールを介する入力データを検出した場合、確立された前記通路により当該データをインストール可能ＯＳに運用する。

以下はソフトウェアキーボードを入力ツールとすることを例として、第三と第四の実施形態により、それぞれと本発明の第一と第二の実施形態に係る入力ツール呼出システム及び方法を詳細に記述する。

第三の実施形態
本発明の第三の実施形態に係るソフトウェアキーボード呼出システムは図３に示したように、インストール可能ＯＳ１１とプロキシモジュール１２とローカルＯＳ１３とを含む。
前記インストール可能ＯＳ１１は入力要求を開始し、プロキシモジュール１２は前記入力要求を受信し、又、インストール可能ＯＳに使用可能ソフトウェアキーボードがないと判断した場合、ローカルＯＳをトリガーし、ローカルＯＳ１３はプロキシモジュールからのトリガーにより自身のソフトウェアキーボードを起動して表示する。

前記プロキシモジュール１２はソフトウェアキーボード管理ユニット１２１と擬似ソフトウェアキーボードユニット１２２とソフトウェアキーボードプロキシユニット１２３とを含み、そのうち、
ソフトウェアキーボード管理ユニット１２１は前記入力要求を受信し、又、インストール可能ＯＳに使用可能ソフトウェアキーボードがないと判断した場合、ローカルＯＳのソフトウェアキーボードを介する入力データを受信した場合、当該データをインストール可能ＯＳに運用できる通路の確立を要求し、擬似ソフトウェアキーボードユニット１２２はソフトウェアキーボード管理ユニットからの通路確立要求を受信した場合、当該要求を実行し、又、ローカルＯＳのソフトウェアキーボードを介する入力の検出開始を要求し、ソフトウェアキーボードプロキシユニット１２３は擬似ソフトウェアキーボードユニットからの検出要求を受信した場合、当該要求を実行し、又、ローカルＯＳをトリガーする。

前記ソフトウェアキーボードプロキシユニット１２３は又、ローカルＯＳのソフトウェアキーボードを介する入力データを検出した場合、前記データを前記擬似ソフトウェアキーボードユニットに転送する。

前記擬似ソフトウェアキーボードユニット１２２は又、確立された前記通路により受信された前記データをインストール可能ＯＳに運用する。

第四の実施形態
本発明の第四の実施形態に係るソフトウェアキーボード呼出方法は、インストール可能ＯＳにおいてローカルＯＳのソフトウェアキーボードを呼び出す方法であり、この方法のフローは図４に示すように、以下のステップを含む。

ステップ１０１：インストール可能ＯＳからの入力要求を受信した場合、インストール可能ＯＳに使用可能ソフトウェアキーボードがあるかどうかを判断する。

ユーザーが端末のインストール可能ＯＳに入力操作を実行したい場合、インストール可能ＯＳはプロキシモジュールに対して入力要求を送信し、プロキシモジュールはインストール可能ＯＳに使用可能ソフトウェアキーボードがあるかどうかを判断し、ある場合、インストール可能ＯＳのソフトウェアキーボードを呼び出し、ローカルＯＳのソフトウェアキーボード呼出フローを終了し、逆の場合、ステップ１０２を継続する。

ステップ１０２：インストール可能ＯＳに使用可能ソフトウェアキーボードがないと判断した場合、ローカルＯＳ自身のソフトウェアキーボードを起動して表示することをローカルＯＳに指示する。

インストール可能ＯＳがローカルＯＳのソフトウェアキーボードを呼び出す必要があると判断した場合、プロキシモジュールはローカルＯＳ自身のソフトウェアキーボードを起動してインストール可能ＯＳに表示することをローカルＯＳに指示する。又、本ステップにおいてローカルＯＳのソフトウェアキーボードを介する入力の検出を開始し、その後にローカルＯＳのソフトウェアキーボードを介する入力データの受信が可能となり、又、入力データを受信した際に当該データをインストール可能ＯＳに運用する通路を確立し、その後にローカルＯＳのソフトウェアキーボードを介してインストール可能ＯＳに入力されるデータはインストール可能ＯＳに運用できるようになる。

ローカルＯＳはプロキシモジュールの指示により自身のソフトウェアキーボードを起動して表示し、ソフトウェアキーボード表示成功メッセージを返し、ソフトウェアキーボードが表示成功で、操作を継続できることをプロキシモジュールとインストール可能ＯＳに通知する。

ステップ１０３：ローカルＯＳのソフトウェアキーボードを介する入力データを検出した場合、確立された前記通路により当該データをインストール可能ＯＳに運用する。

ローカルＯＳのソフトウェアキーボード表示成功メッセージを受信後、ローカルＯＳのソフトウェアキーボードを介するインストール可能ＯＳ上の入力操作が実行可能となり、又、ステップ１０２で実現された入力データの検出と確立された通路により、ローカルＯＳのソフトウェアキーボードを介する入力データを受信し、受信データをインストール可能ＯＳに運用できる。

前記ソフトウェアキーボード呼出方法は、インストール可能ＯＳに使用可能入力法があるかないかには限らず、全てソフトウェアキーボードを介する入力を実現できる。インストール可能ＯＳに使用可能入力法がない場合、本実施形態に係るソフトウェアキーボード呼出方法により、インストール可能ＯＳはローカルＯＳのソフトウェアキーボードを介する入力データを受信でき、インストール可能ＯＳに使用可能入力法がある場合、本実施形態に係るソフトウェアキーボード呼出方法により、インストール可能ＯＳはローカルＯＳのソフトウェアキーボードと使用可能入力法を介する入力データを受信できる。

ステップ１０１とステップ１０２はローカルＯＳのソフトウェアキーボードの起動プロセスを実現し、ステップ１０３はローカルＯＳのソフトウェアキーボードの使用プロセスと見なされることができる。以下は第三の実施形態のソフトウェアキーボード呼出システムにおける各モジュールとユニットに結合して本発明の第四の実施形態に係るソフトウェアキーボード起動方法を詳細に説明する。ローカルＯＳのソフトウェアキーボードを起動する際、即ちステップ１０１〜ステップ１０２において、ローカルＯＳ、インストール可能ＯＳ及びプロキシモジュール内の各モジュール又はユニット間の通信プロセスは図５に示すように、以下のステップを含む。

第一段階：インストール可能ＯＳはソフトウェアキーボード管理ユニットに対して入力要求を送信する。

ユーザーは端末にインストール可能ＯＳを動作し、入力したい場合、インストール可能ＯＳはプロキシモジュールのソフトウェアキーボード管理ユニットに対して入力要求を送信する。

第二段階：ソフトウェアキーボード管理ユニットは、ローカルＯＳのソフトウェアキーボードを起動することを擬似ソフトウェアキーボードユニットに要求する。

ソフトウェアキーボード管理ユニットはインストール可能ＯＳからの入力要求を受信した場合、インストール可能ＯＳに使用可能ソフトウェアキーボードがあるかどうかを判断し、ある場合、使用可能ソフトウェアキーボードのポップアップを要求し、逆の場合、インストール可能ＯＳがローカルＯＳのソフトウェアキーボードを呼び出す必要があると判断できる。ローカルＯＳのソフトウェアキーボードを使用する前、まず、プロキシモジュールの擬似ソフトウェアキーボードユニットにより、ローカルＯＳのソフトウェアキーボードとインストール可能ＯＳのソフトウェアキーボードを整合しておく必要がある。この後、ローカルＯＳのソフトウェアキーボードを介する操作がインストール可能ＯＳに運用できるようになる。そのため、ソフトウェアキーボード管理ユニットは擬似ソフトウェアキーボードユニットに対してローカルＯＳのソフトウェアキーボード起動要求を送信し、インストール可能ＯＳとローカルＯＳのソフトウェアキーボードを整合することを擬似ソフトウェアキーボードユニットに通知する。

第三段階：擬似ソフトウェアキーボードユニットはソフトウェアキーボードプロキシユニットに対してＩＰＣ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｃｅｓｓ Ｃｏｎｎｅｃｔｉｏｎ、ＩＰＣ）要求を送信する。

擬似ソフトウェアキーボードユニットは整合を完成後、ソフトウェアキーボードプロキシユニットに対してＩＰＣ要求を送信し、インストール可能ＯＳがこれからローカルＯＳのソフトウェアキーボードを呼び出すことをソフトウェアキーボードプロキシユニットに通知する。ソフトウェアキーボードプロキシユニットは擬似ソフトウェアキーボードユニットからのＩＰＣ要求を受信後、ローカルＯＳのソフトウェアキーボードとインストール可能ＯＳのソフトウェアキーボードの接続を実現し、その後、インストール可能ＯＳはローカルＯＳのソフトウェアキーボードを介する操作を受信できるようになる。

第四段階：ソフトウェアキーボードプロキシユニットはローカルＯＳのソフトウェアキーボードを起動して表示することをローカルＯＳに指示する。

ソフトウェアキーボードプロキシユニットは接続を完成後、ローカルＯＳ自身のソフトウェアキーボードを起動して表示し、インストール可能ＯＳに提供することをローカルＯＳに指示する。

第五段階：ローカルＯＳはソフトウェアキーボードを起動して表示し、ソフトウェアキーボード表示成功メッセージをソフトウェアキーボードプロキシユニットに返す。

ローカルＯＳは自身のソフトウェアキーボードを起動して表示した後、ソフトウェアキーボード表示成功メッセージをソフトウェアキーボードプロキシユニットに返し、ローカルＯＳとインストール可能ＯＳのソフトウェアキーボードの接続成功をソフトウェアキーボードプロキシユニットに通知する。

第六段階：ソフトウェアキーボードプロキシユニットは受信されたソフトウェアキーボード表示成功メッセージを擬似ソフトウェアキーボードユニットに返す。

本ステップはローカルＯＳとインストール可能ＯＳの整合成功を擬似ソフトウェアキーボードユニットに通知する。

第七段階：擬似ソフトウェアキーボードユニットは受信されたソフトウェアキーボード表示成功メッセージをソフトウェアキーボード管理ユニットに返す。

本ステップはインストール可能ＯＳがローカルＯＳのソフトウェアキーボードを呼び出す可能になるということをソフトウェアキーボード管理ユニットに通知する。

第八段階：ソフトウェアキーボード管理ユニットは受信されたソフトウェアキーボード表示成功メッセージをインストール可能ＯＳに返す。

本ステップはインストール可能ＯＳに対して、受信されたソフトウェアキーボード表示成功メッセージにより、表示されたソフトウェアキーボードを利用して簡単な入力を実行でき、又はローカルＯＳのソフトウェアキーボードと使用可能入力法を利用して入力操作を実行できることを通知する。

以下は入力法を入力ツールとすることを例として、それぞれと、第五と第六の実施形態により、本発明の第一と第二の実施形態に係る入力ツール呼出システムと方法を詳細に説明する。

第五の実施形態
本発明の第五の実施形態に係る入力法呼出システムは図６に示すように、インストール可能ＯＳ２１とプロキシモジュール２２とローカルＯＳ２３とを含む。
前記インストール可能ＯＳ２１は入力要求を開始し、プロキシモジュール２２前記入力要求を受信し、インストール可能ＯＳに使用可能入力法がないと判断した場合、ローカルＯＳをトリガーし、ローカルＯＳ２３はプロキシモジュールのトリガーにより自身の入力法を起動する。

前記ローカルＯＳ２３はプロキシモジュールのトリガーにより、入力法の動作パラメータを設定してから当該入力法を起動する。

前記プロキシモジュール２２は入力法管理ユニット２２１と擬似入力法ユニット２２２と入力法プロキシユニット２２３とを含む。
前記入力法管理ユニット２２１は前記入力要求を受信し、又、インストール可能ＯＳに使用可能入力法がないと判断した場合、ローカルＯＳの入力法を介する入力データを受信時に当該データをインストール可能ＯＳに運用できる通路の確立を要求し、擬似入力法ユニット２２２は入力法管理ユニットからの通路確立要求を受信した場合、当該要求を実行し、データを入力するための画面を作成し、又、当該画面におけるローカルＯＳの入力法を介する入力の検出開始を要求し、入力法プロキシユニット２２３は擬似入力法ユニットからの検出要求を受信した場合、当該要求を実行し、又、ローカルＯＳをトリガーする。

前記入力法プロキシユニット２２３は又、前記画面にローカルＯＳの入力法を介する入力データを検出した場合、前記データを前記擬似入力法ユニットに転送し、
前記擬似入力法ユニット２２２は又、確立された前記通路により受信された前記データをインストール可能ＯＳに運用する。

第六の実施形態
本発明の第六の実施形態に係る入力法呼出方法は、インストール可能ＯＳにおいてローカルＯＳの入力法を呼び出す方法であり、この方法のフローは図７に示すように以下のステップを含む。

ステップ２０１：インストール可能ＯＳからの入力要求を受信した場合、インストール可能ＯＳに使用可能入力法があるかどうかを判断する。

第一の実施形態に似たように、インストール可能ＯＳからの入力要求を受信した場合、プロキシモジュールは先ず、インストール可能ＯＳに使用可能入力法があるかどうかを判断し、ある場合、インストール可能ＯＳの入力法を呼び出して入力操作を実行し、ローカルＯＳ入力法の呼出フローを終了し、逆の場合、ステップ２０２を継続する。

ステップ２０２：インストール可能ＯＳに使用可能入力法がないと判断した場合、ローカルＯＳ自身の入力法を起動することをローカルＯＳに指示する。

インストール可能ＯＳがローカルＯＳの入力法を呼び出す必要があると判断した場合、プロキシモジュールはローカルＯＳ自身の入力法を起動することをローカルＯＳに指示する。入力法を起動する際、プロキシモジュールはデータを入力するための画面を作成してインストール可能ＯＳに表示し、又、当該画面におけるローカルＯＳの入力法を介する入力の検出を開始し、インストール可能ＯＳにローカルＯＳの入力法を介する当該画面内の入力データを受信させるようにする。又、入力データを受信時に当該データをインストール可能ＯＳに運用できる通路を確立し、ローカルＯＳの入力法を介する前記画面における入力データをインストール可能ＯＳに運用できるようにする。

ローカルＯＳは自身の入力法を起動する指示を受信した場合、自身の入力法を設定する。前記設定は各種の入力法のインストール、アンインストール、及び順序の切り替え設定など、入力法の各動作パラメータを設定することである。設定を完了してから自身の入力法を起動し、入力法起動成功メッセージを返し、入力法が起動成功で、操作を継続できることをプロキシモジュールとインストール可能ＯＳに通知する。

ステップ２０３：前記画面にローカルＯＳ入力法を介する入力データを検出した場合、確立された前記通路により当該データをインストール可能ＯＳに運用する。

ローカルＯＳ入力法の起動成功メッセージを受信後、ローカルＯＳの入力法によりポップアップ画面に入力操作を実行でき、又、ステップ２０２で実現された入力の検出と確立された通路により、ローカルＯＳの入力法を介する入力データを受信でき、受信されたデータをインストール可能ＯＳに運用する。

ステップ２０１とステップ２０２はローカルＯＳの入力法を起動するプロセスを実現し、ステップ２０３はローカルＯＳ入力法の使用プロセスと見なされることができる。以下は第五の実施形態に係る入力法呼出システムにおける各モジュールとユニットに結合し、第六の実施形態に係る入力法起動方法を詳細に説明する。ローカルＯＳの入力法を起動する際、即ち、ステップ２０１〜ステップ２０２において、ローカルＯＳ、インストール可能ＯＳとプロキシモジュールにおける各モジュール又はユニット間の通信プロセスは図８に示すように、以下のステップを含む。

第一段階：インストール可能ＯＳは入力法管理ユニットに対して入力要求を開始する。

ユーザーは端末にインストール可能ＯＳを動作し、入力したい場合、インストール可能ＯＳはプロキシモジュールの入力法管理ユニットに対して入力要求を開始する。

第二段階：入力法管理ユニットは擬似入力法ユニットに対してローカルＯＳの入力法を起動することを要求する。

ローカルＯＳの入力法とインストール可能ＯＳの入力法の整合はプロキシモジュールにおける擬似入力法ユニットにより実現されるため、入力法管理ユニットはインストール可能ＯＳからの入力要求を受信し、インストール可能ＯＳに使用可能入力法がないと判断した場合、擬似入力法ユニットに対してローカルＯＳの入力法を起動することを要求し、擬似入力法ユニットは入力法管理ユニットからの要求を受信した場合、ローカルＯＳとインストール可能ＯＳの入力法を整合し、ローカルＯＳの入力法を介する入力内容をインストール可能ＯＳに運用できるようにする。

第三段階：擬似入力法ユニットは入力法プロキシユニットに対してローカルＯＳの入力法を起動することを要求する。

擬似入力法ユニットは整合を完成後、入力法プロキシユニットに対してローカルＯＳの入力法を起動することを要求する。入力法プロキシユニットは当該要求を受信した場合、ローカルＯＳの入力法とインストール可能ＯＳの入力法の接続を完成し、インストール可能ＯＳにローカルＯＳの入力法を介する入力内容を受信させるようにする。

説明したいのは、入力法プロキシユニットは前記要求を受信した後、インストール可能ＯＳに操作画面をポップアップする。その後のローカルＯＳの入力法を介する入力は全て当該画面において完成される。

第四段階：入力法プロキシユニットはローカルＯＳに対してローカルＯＳの入力法を起動することを指示する。

入力法プロキシユニットは接続を完成後、入力法を起動してインストール可能ＯＳに提供することをローカルＯＳに指示する。

第五段階：ローカルＯＳは自身の入力法を起動し、入力法起動完了メッセージを入力法プロキシユニットに返す。

入力法を起動する前、設定する必要がある。例えば、ローカルＯＳの入力法のインストール、アンインストール、順序の切り替え設定などを行う。そのため、ローカルＯＳは自身の入力法を設定してから起動し、入力法起動完了メッセージを入力法プロキシユニットに返し、ローカルＯＳとインストール可能ＯＳの入力法の接続成功を入力法プロキシユニットに通知する。

第六段階：入力法プロキシユニットは受信された入力法起動完了メッセージを擬似入力法ユニットに返す。

本ステップはローカルＯＳとインストール可能ＯＳの入力法整合成功を擬似入力法ユニットに通知する。

第七段階：擬似入力法ユニットは受信された入力法起動完了メッセージを入力法管理ユニットに返す。

本ステップはローカルＯＳの入力法の起動成功を入力法管理ユニットに通知し、インストール可能ＯＳはローカルＯＳの入力法を呼び出す可能となる。

第八段階：入力法管理ユニットは受信された入力法起動完了メッセージをインストール可能ＯＳに送信する。

本ステップはローカルＯＳの入力法を使用して入力を実行できることをインストール可能ＯＳに指示する。インストール可能ＯＳに入力法起動完了メッセージを送信後、インストール可能ＯＳ上のポップアップ画面により入力操作を実行できるようになる。

以下はソフトウェアキーボードと入力法を入力ツールとすることを例として、第七と第八の実施形態により、本発明の第一と第二の実施形態に係る入力ツール呼出システムと方法をそれぞれと詳細に説明する。

本発明の第三と第五の実施形態に係るソフトウェアキーボード呼出システムと入力法呼出システムはそれぞれとインストール可能ＯＳとローカルＯＳの間のソフトウェアキーボード共有、及びインストール可能ＯＳとローカルＯＳの間の入力法共有を独立に実現できる。又、本発明の第三と第五の実施形態に係るシステムを１つに整合し、インストール可能ＯＳからローカルＯＳのソフトウェアキーボードとローカルＯＳの入力法の両方も呼び出し可能のシステムを取得できる。以下は第七の実施形態により、ローカルＯＳとインストール可能ＯＳにソフトウェアキーボードと入力法を共有させるシステムを詳細に説明する。

第七の実施形態
本発明の第七の実施形態に係るソフトウェアキーボードと入力法の呼出システムは図９に示すように、インストール可能ＯＳ３１とプロキシモジュール３２とローカルＯＳ３３とを含む。
インストール可能ＯＳ３１は入力要求を開始し、プロキシモジュール３２は前記入力要求を受信し、インストール可能ＯＳに使用可能ソフトウェアキーボードと使用可能入力法がないと判断した場合、ローカルＯＳをトリガーし、ローカルＯＳ３３はプロキシモジュールからのトリガーにより自身のソフトウェアキーボードを起動して表示し、自身の入力法を起動する。

前記ローカルＯＳ３３はプロキシモジュールからのトリガーにより自身のソフトウェアキーボードを起動して表示し、又、プロキシモジュールのトリガーにより入力法の動作パラメータを設定してから当該入力法を起動する。

前記プロキシモジュール３２は入力管理ユニット３２１と擬似ソフトウェアキーボードユニット３２２とソフトウェアキーボードプロキシユニット３２３と擬似入力法ユニット３２４と入力法プロキシユニット３２５とを含み、そのうち、
入力管理ユニット３２１は前記入力要求を受信し、又、インストール可能ＯＳに使用可能ソフトウェアキーボードと使用可能入力法がないと判断した場合、ローカルＯＳのソフトウェアキーボードと入力法を介する入力データを受信時に当該データをインストール可能ＯＳに運用できる通路の確立を要求し、擬似ソフトウェアキーボードユニット３２２は入力管理ユニットからの通路確立要求を受信した場合、第一通路を確立し、ローカルＯＳのソフトウェアキーボードと入力法を介する入力の検出開始を要求し、ソフトウェアキーボードプロキシユニット３２３は擬似ソフトウェアキーボードユニットからの検出要求を受信した場合、当該要求を実行し、又、ローカルＯＳをトリガーし、擬似入力法ユニット３２４は入力管理ユニットからの通路確立要求を受信した場合、第二通路を確立し、データを入力するための画面を作成し、又、当該画面におけるローカルＯＳの入力法とソフトウェアキーボードを介する入力データの検出開始を要求し、入力法プロキシユニット３２５は擬似入力法ユニットからの検出要求を受信した場合、当該要求を実行し、又、ローカルＯＳをトリガーする。

前記ソフトウェアキーボードプロキシユニット３２３は又、ローカルＯＳのソフトウェアキーボードと入力法を介する入力データを検出した場合、前記データを前記擬似ソフトウェアキーボードユニットに転送する。

前記擬似ソフトウェアキーボードユニット３２２は又、確立された前記第一通路により受信されたデータをインストール可能ＯＳに運用する。

前記入力法プロキシユニット３２５は又、前記画面にローカルＯＳの入力法とソフトウェアキーボードを介する入力データを検出した場合、前記データを前記擬似入力法ユニットに転送する。
前記擬似入力法ユニット３２４は又、確立された前記第二通路により受信されたデータをインストール可能ＯＳに運用する。

本発明の第七の実施形態における入力管理ユニットは第三の実施形態におけるソフトウェアキーボード管理ユニットと第五の実施形態における入力法管理ユニットの整合体と見なされることができる。当該入力管理ユニットは当該ソフトウェアキーボード管理ユニットと当該入力法管理ユニットの機能を同時に実現できる。

第七の実施形態におけるプロキシモジュール内の入力管理ユニットを除外する他のユニットは、第三と第五の実施形態内の対応するユニットと同じ機能を持つものと見なされることができる。同様に、第三と第五の実施形態内の関連ユニットも、第七の実施形態内の対応するユニットの機能を実現できる。

第八の実施形態
本発明の第八の実施形態はソフトウェアキーボードと入力法の呼出方法を提供し、本実施形態に係るデータ入力方法のフローは図１０に示すように、以下のステップを含む。

ステップ３０１：インストール可能ＯＳからの入力要求を受信した場合、インストール可能ＯＳに使用可能ソフトウェアキーボードと使用可能入力法があるかどうかを判断する。

ユーザーは端末に入力操作を実行する際、インストール可能ＯＳはプロキシモジュールに対して入力要求を送信し、プロキシモジュールはインストール可能ＯＳに使用可能ソフトウェアキーボードと入力法があるかどうかを判断し、ある場合、インストール可能ＯＳのソフトウェアキーボードと入力法を呼び出して、ローカルＯＳのソフトウェアキーボードと入力法の呼出フローを終了し、逆の場合、ステップ３０２を継続する。

ステップ３０２：インストール可能ＯＳに使用可能ソフトウェアキーボードと使用可能入力法がないと判断した場合、ローカルＯＳ自身のソフトウェアキーボードを起動して表示し、ローカルＯＳ自身の入力法を起動することをローカルＯＳに要求する。

インストール可能ＯＳがローカルＯＳのソフトウェアキーボードと入力法を呼び出す必要があると判断した場合、プロキシモジュールはそれぞれと、ローカルＯＳ自身のソフトウェアキーボードを起動してインストール可能ＯＳに表示することと、ローカルＯＳ自身の入力法を起動することとをローカルＯＳに要求する。

ローカルＯＳ自身のソフトウェアキーボードを起動して表示することをローカルＯＳに指示する際、プロキシモジュールはローカルＯＳのソフトウェアキーボードを介する入力の検出を開始し、ローカルＯＳ自身の入力法を起動することをローカルＯＳに指示する際、プロキシモジュールはデータを入力するための画面を作成してインストール可能ＯＳに表示させ、又、当該画面におけるローカルＯＳの入力法を介する入力の検出を開始する。

ローカルＯＳに対してローカルＯＳ自身のソフトウェアキーボードを起動して表示することと、ローカルＯＳ自身の入力法を起動することを指示する際、プロキシモジュールは入力データを受信時に当該データをインストール可能ＯＳに運用できる通路を確立し、前記通路は以下の二種を含む。
ソフトウェアキーボードによりローカルＯＳのソフトウェアキーボードと入力法を介する入力を検出した場合、当該データをインストール可能ＯＳに運用できる第一通路を確立し、入力法により前記画面におけるローカルＯＳの入力法とソフトウェアキーボードを介する入力を検出した場合、当該データをインストール可能ＯＳに運用できる第二通路を確立する。

ローカルＯＳは自身のソフトウェアキーボードを起動して表示し、自身の入力法を起動し、又、ソフトウェアキーボード表示成功メッセージと入力法起動成功メッセージを返し、入力操作が可能になることをプロキシモジュールとインストール可能ＯＳに通知する。

ステップ３０３：ローカルＯＳの入力法とソフトウェアキーボードを介する入力データを検出した場合、確立された通路により当該データをインストール可能ＯＳに運用する。

プロキシモジュールはソフトウェアキーボードによりローカルＯＳのソフトウェアキーボードと入力法を介する入力を検出した場合、確立された前記第一通路により当該データをインストール可能ＯＳに運用できる。或いは、入力法によりローカルＯＳの入力法とソフトウェアキーボードを介する入力を前記画面に検出した場合、確立された前記第二通路により当該データをインストール可能ＯＳに運用できる。即ち、プロキシモジュールは任意の検出方法と対応する通路を選択して検出された入力データをインストール可能ＯＳに運用することができる。

ステップ３０１とステップ３０２はローカルＯＳのソフトウェアキーボードと入力法を起動するプロセスを実現し、ステップ３０３はローカルＯＳのソフトウェアキーボードと入力法を使用するプロセスと見なされることができる。第七の実施形態における入力管理ユニットはそれぞれと第三の実施形態におけるソフトウェアキーボード管理ユニットと第五の実施形態における入力法管理ユニットに相当でき、プロキシモジュールの他のユニットも同様に第三と第五の実施形態内の対応するユニットと同じ機能を持つものと見なされることができる。そのため、本発明の第七の実施形態における各モジュールとユニットにより本発明の第八の実施形態に係るローカルＯＳのソフトウェアキーボードと入力法の起動方法を実現する際、各モジュール・ユニット間の通信プロセスは、第四と第六の実施形態に係る各モジュール・ユニット間の通信プロセスと同じなので、ここで説明を省略する。

第七と第八の実施形態における第一通路と第二通路は同時確立することには限られない。即ち、プロキシモジュールはローカルＯＳ自身のソフトウェアキーボードを起動して表示し、又、自身の入力法をを起動することをローカルＯＳに指示すると同時に、第一通路のみを確立し、その後に確立された第一通路により受信データをインストール可能ＯＳに運用することができる。又は、ローカルＯＳ自身のソフトウェアキーボードを起動して表示し、又、ローカルＯＳ自身の入力法を起動することをローカルＯＳに指示すると同時に、第二通路のみを確立し、その後に確立された第二通路により受信データをインストール可能ＯＳに運用することもできる。更に又、指示を送信する際、第一通路と第二通路を同時に確立し、その後にどちらかの通路を選択して受信データをインストール可能ＯＳに運用することもできる。

第九の実施形態
本発明の第九の実施形態に係る設備の構造は図１１に示すように、管理ユニット４１とプロキシユニット４２とを含む。
前記管理ユニット４１はインストール可能ＯＳからの入力要求を受信し、インストール可能ＯＳに使用可能入力ツールがあるかどうかを判断し、プロキシユニット４２はインストール可能ＯＳに使用可能入力ツールがない場合、ローカルＯＳをトリガーする。

前記入力ツールはソフトウェアキーボードと／又は入力法を含む。

前記管理ユニット４１は前記入力要求を受信し、インストール可能ＯＳに使用可能入力ツールがないと判断した場合、ローカルＯＳの入力ツールを介する入力データをインストール可能ＯＳに運用できる通路の確立を要求する。

前記設備は又、
管理ユニットからの通路確立要求を受信した場合、当該要求を実行し、ローカルＯＳの入力ツールを介する入力イベントの検出開始を要求する擬似操作ユニット４３を含み、
前記プロキシユニット４２は具体的に、擬似操作ユニットからの検出要求を受信した場合、当該要求を実行し、又、ローカルＯＳをトリガーする。

前記プロキシユニット４２は又、ローカルＯＳの入力ツールを介する入力データを検出した場合、前記データを前記擬似操作ユニットに転送する。

前記擬似操作ユニット４３は又、確立された前記通路により、受信された前記データをインストール可能ＯＳに運用する。

本実施形態に係るプロキシ装置は第一、第三、第五と第七の実施形態におけるプロキシモジュールと同じ機能を有するものと見なされることができる。第一、第三、第五と第七の実施形態におけるプロキシモジュールも本実施形態に係るプロキシ装置のような機能を有することができる。本実施形態に係るプロキシ装置は第一ないし第八の実施形態における入力ツール呼出システムと方法に適用できる。

無論、当業者により、上述した実施形態に記述された技術的な解決手段を改造し、又はその中の一部の技術要素を置換することもできる。そのような改造と置換は本発明の各実施形態の技術の範囲から逸脱するとは見なされない。

Claims (12)

1. 入力要求を開始するためのインストール可能ＯＳと、
   前記入力要求を受信し、インストール可能ＯＳに利用可能な入力ツールがないと判断した場合、ローカルＯＳをトリガーするプロキシモジュールと、
   プロキシモジュールにトリガーされると、自身の入力ツールを起動するローカルＯＳと
   を含むことを特徴とする入力ツール呼出システム。
2. 前記入力ツールは、
   ソフトウェアキーボード、又は
   入力法、又は
   ソフトウェアキーボード及び入力法
   を含むことを特徴とする請求項１記載の入力ツール呼出システム。
3. 前記プロキシモジュールは
   前記入力要求を受信し、インストール可能ＯＳに使用可能入力ツールがないと判断した場合、ローカルＯＳの入力ツールを介する入力データをインストール可能ＯＳに運用できる通路の確立を要求する管理ユニットと、
   管理ユニットからの通路確立要求を受信した場合、当該要求を実行し、ローカルＯＳの入力ツールを介する入力イベントの検出開始を要求する擬似操作ユニットと、
   擬似操作ユニットからの検出要求を受信した場合、当該要求を実行し、又、ローカルＯＳをトリガーするプロキシユニットと
   を含むことを特徴とする請求項２記載の入力ツール呼出システム。
4. 前記プロキシユニットは又、ローカルＯＳの入力ツールを介する入力データを検出した場合、前記データを前記擬似操作ユニットに転送し、
   前記擬似操作ユニットは又、確立された前記通路により受信された前記データをインストール可能ＯＳに運用する
   ことを特徴とする請求項３記載の入力ツール呼出システム。
5. インストール可能ＯＳからの入力要求を受信した場合、インストール可能ＯＳに利用可能な入力ツールがあるかどうかを判断するステップと、
   インストール可能ＯＳに使用可能入力ツールがないと判断した場合、ローカルＯＳ自身の入力ツールを起動することをローカルＯＳに指示するステップと、
   ことを特徴とする入力ツール呼出方法。
6. 前記入力ツールは
   ソフトウェアキーボード、又は
   入力法、又は
   ソフトウェアキーボードおよび入力法
   を含むことを特徴とする請求項５記載の入力ツール呼出方法。
7. ローカルＯＳにローカルＯＳ自身の入力ツールを起動することを指示するステップは、
   ローカルＯＳの入力ツールを介する入力の検出を開始し、受信されたローカルＯＳの入力ツールを介する入力データをインストール可能ＯＳに運用するステップと、
   ローカルＯＳは自身の入力ツールを起動し、入力ツール起動成功メッセージを返すステップと
   を含むことを特徴とする請求項６記載の入力ツール呼出方法。
8. ローカルＯＳにローカルＯＳ自身の入力ツールを起動することを指示した後に、
   ローカルＯＳの入力ツールを介する入力データを検出した場合、確立された前記通路により当該データをインストール可能ＯＳに運用するステップをさらに含むことを特徴とする請求項７記載の入力ツール呼出方法。
9. インストール可能ＯＳからの入力要求を受信し、インストール可能ＯＳに利用可能な入力ツールがあるかどうかを判断する管理ユニットと、
   インストール可能ＯＳに利用可能な入力ツールがない場合、ローカルＯＳをトリガーするプロキシユニットと
   を含むことを特徴とするプロキシ装置。
10. 前記入力ツールは
    ソフトウェアキーボード、又は
    入力法、又は
    ソフトウェアキーボードと入力法
    を含むことを特徴とする請求項９記載のプロキシ装置。
11. 前記管理ユニットは前記入力要求を受信し、インストール可能ＯＳに使用可能入力ツールがないと判断した場合、ローカルＯＳの入力ツールを介する入力データをインストール可能ＯＳに運用できる通路の確立を要求し、
    前記設備は、
    管理ユニットからの通路確立要求を受信した場合、当該要求を実行し、ローカルＯＳの入力ツールを介する入力イベントの検出開始を要求する擬似操作ユニットと、
    擬似操作ユニットからの検出要求を受信した場合、当該要求を実行し、又、ローカルＯＳをトリガーする前記プロキシユニットと
    をさらに含むことを特徴とする請求項１０記載のプロキシ装置。
12. 前記プロキシユニットは又、ローカルＯＳの入力ツールを介する入力データを検出した場合、前記データを前記擬似操作ユニットに転送し、
    前記擬似操作ユニットは又、確立された前記通路により受信された前記データをインストール可能ＯＳに運用する
    ことを特徴とする請求項１１記載のプロキシ装置。

Images