(57)【要約】【課題】多様な種類の業務を迅速に、且つ便利に処理できるように複数のソフトウェアの実行を制御する。【解決手段】複数のアプリケーションの実行のために参照される参照情報を収集し、更新する参照情報管理部と、所定の方法により使用者から入力又は伝達された使用者メッセージを受信し、受信された使用者メッセージから一つ又はそれ以上のコンポーネントを抽出し、抽出されたコンポーネントに基づいて使用者メッセージを解釈する使用者メッセージ前処理部と、使用者メッセージから解釈された事項に基づいて、使用者が要求する一つ又はそれ以上のアクションを特定するメッセージ処理部と、参照情報管理部によって管理される参照情報と、メッセージ処理部によって特定されたアクションとに基づいて、特定された夫々のアクションを遂行するために実行されるべきアプリケーションを選別し、選別されたアプリケーションを実行させるアプリ実行部とを含む。【選択図】      図１
2014026367.tif 000002
【特許請求の範囲】
【請求項１】
使用者から受信した使用者メッセージに基づいて複数のアプリケーションの実行を制御するソフトウェア実行制御装置において、
複数のアプリケーションの実行のために参照される参照情報を収集し、更新する参照情報管理部と、
所定の方法により使用者から入力又は伝達された使用者メッセージを受信し、上記受信された使用者メッセージから一つ又はそれ以上のコンポーネントを抽出し、抽出されたコンポーネントに基づいて上記使用者メッセージを解釈する使用者メッセージ前処理部と、
上記使用者メッセージから解釈された事項に基づいて、上記使用者が要求する一つ又はそれ以上のアクションを特定するメッセージ処理部と、
上記参照情報管理部によって管理される参照情報と、上記メッセージ処理部によって特定されたアクションとに基づいて、上記特定されたそれぞれのアクションを遂行するために実行されるべきアプリケーションを選別し、上記選別されたアプリケーションを実行させるアプリ実行部と、
を含むソフトウェア実行制御装置。
【請求項２】
上記使用者メッセージ前処理部は、
所定の方法により使用者から入力又は伝達された使用者メッセージを受信する使用者メッセージ受信モジュールと、
上記受信された使用者メッセージから一つ又はそれ以上のコンポーネントを抽出し、上記コンポーネントの各々は命令語又はエンティティである使用者メッセージ構造化モジュールと、
上記抽出された一つ又はそれ以上のコンポーネントに基づいて上記使用者メッセージが定形的メッセージであるかどうかを判断する使用者メッセージ解釈モジュールとを含み、
上記メッセージ処理部は、上記使用者メッセージ前処理部によって抽出された一つ又はそれ以上のコンポーネントに基づいてアクションを特定する、
請求項１記載のソフトウェア実行制御装置。
【請求項３】
上記メッセージ処理部は、
定形的メッセージと解釈された定形的使用者メッセージから一つ又はそれ以上のアクションを特定する定形的メッセージ処理モジュールと、
定形的メッセージではないと解釈された非定型的使用者メッセージから一つ又はそれ以上のアクションを特定する非定型的メッセージ処理モジュールと
を含む、請求項２記載のソフトウェア実行制御装置。
【請求項４】
上記参照情報管理部は、
一つ又はそれ以上の定形的メッセージの構造に関する情報と、上記定形的メッセージの各々に対応する一つ又はそれ以上のアクションの実行タイミングを規定するアクションフローとを、上記一つ又はそれ以上の定形的メッセージに対応付けて記録した定形的メッセージデータベースを構築して運用し、
上記使用者メッセージ解釈モジュールは、
上記使用者メッセージ構造化モジュールによって抽出された命令語の内容と個数、及びエンティティの種類とタイプを含むグループから選択された一つ又はそれ以上の情報及び上記定形的メッセージデータベースに記録された情報に基づいて、上記使用者メッセージが定形的メッセージであるかどうかを判断し、
上記定形的メッセージ処理モジュールは、
上記使用者メッセージ解釈モジュールによって上記使用者メッセージが定形的メッセージと判断されれば、上記定形的メッセージデータベースから上記定形的メッセージに対応付けて記録されたアクションフローを読み出す、
請求項３記載のソフトウェア実行制御装置。
【請求項５】
上記参照情報管理部は、
上記使用者メッセージによって遂行されるように要求された業務を構成する一つ又はそれ以上のアクション要求に対して、一つ又はそれ以上の同義語を対応付けて記録したアクション要求同義語データベースと、
上記アクション要求の各々を充足させるために遂行されるべき一つ又はそれ以上の対応作業を、上記アクション要求の各々に対応付けて記録した対応作業データベースと、
上記それぞれの対応作業の遂行に必要な一つ又はそれ以上のアクションを、上記対応作業の各々に対応付けて記録した対応作業−アクションデータベースを構築して運用し、
上記非定型的メッセージ処理モジュールは、
上記アクション要求同義語データベース、上記対応作業データベース及び上記対応作業−アクションデータベースの中で一つ又はそれ以上を参照して、上記使用者メッセージから抽出されたエンティティ又は命令語に対応する一つ又はそれ以上のアクションを特定し、上記特定されたアクションの実行タイミングを規定する、
請求項３記載のソフトウェア実行制御装置。
【請求項６】
上記参照情報管理部は、
上記使用者メッセージによって遂行されるように要求された業務を構成する一つ又はそれ以上のアクション要求に対して、一つ又はそれ以上の同義語を対応付けて記録したアクション要求同義語データベースと、
上記アクション要求の各々を充足させる一つ又はそれ以上のアクションを、上記アクション要求の各々に対応付けて記録したアクション要求−アクションデータベースを構築して運用し、
上記非定型的メッセージ処理モジュールは、
上記アクション要求同義語データベース及び上記アクション要求−アクションデータベースの中で一つ又はそれ以上を参照して、上記使用者メッセージから抽出されたエンティティ又は命令語に対応する一つ又はそれ以上のアクションを特定し、上記特定されたアクションの実行タイミングを規定する、
請求項３記載のソフトウェア実行制御装置。
【請求項７】
上記アプリ実行部は、上記実行させるべきアプリケーションの入力データのタイプおよびフォーマットに関する情報に基づいて、上記アプリケーションに入力されるべきデータのタイプ又はフォーマットを変更する、
請求項１記載のソフトウェア実行制御装置。
【請求項８】
上記アプリ実行部は、
上記実行させるべきアプリケーションのプロシージャに関する情報に基づいて、上記アプリケーションの実行を制御する制御信号を生成する、
請求項１記載のソフトウェア実行制御装置。
【請求項９】
上記アプリ実行部は、
上記使用者メッセージに対し選別されたアプリケーションの出力データの一部又は全てを組み合わせて、上記使用者又は上記使用者メッセージに基づいて決まった受信者に提供する一つ又はそれ以上の出力を生成する出力生成モジュールを更に含む、
請求項１記載のソフトウェア実行制御装置。
【請求項１０】
上記参照情報管理部は、
使用者別に一つ又はそれ以上の特性と、各特性別に複数の選択肢の優先順位及び加重値で構成された集合から選択された情報とを対応付けて記録した特性情報データベースを構築して運用し、
上記メッセージ処理部は、
上記特性情報データベースを参照して上記使用者メッセージに対応する一つ又はそれ以上のアクションを特定する、
請求項１乃至６の何れか１項記載のソフトウェア実行制御装置。
【請求項１１】
上記参照情報管理部は、
使用者別に一つ又はそれ以上の特性と、各特性別に複数の選択肢の優先順位及び加重値で構成された集合から選択された情報とを対応付けて記録した特性情報データベースを構築して運用し、
上記アプリ実行部は、
上記特性情報データベースを参照して上記アプリケーションを選別する、
請求項１乃至６の何れか１項記載のソフトウェア実行制御装置。
【請求項１２】
上記非定型的メッセージ処理モジュールは、
上記アクション要求のどれか一つに対応する複数のアクションが存在する場合、上記アクション要求に対応する上記複数のアクションの組合を生成し、上記組合の中で一つ又はそれ以上を選別する、
請求項５又は６記載のソフトウェア実行制御装置。
【請求項１３】
上記参照情報管理部は、
使用者別に特性と、各特性別に複数の選択肢の加重値情報を対応付けて記録した特性情報データベースを構築して運用し、
上記非定型的メッセージ処理モジュールは、
上記特性情報データベースを参照して、上記組合の各々を構成するアクションの加重値の合計及び積で構成された集合から選択された演算結果から選択された値に基づいて上記選別を遂行する、
請求項１２記載のソフトウェア実行制御装置。
【請求項１４】
ソフトウェア実行制御装置を利用して、使用者から受信した使用者メッセージに基づいて複数のアプリケーションの実行を制御するソフトウェア実行制御方法において、
複数のアプリケーションの実行のために参照される参照情報を収集し、更新する参照情報管理段階と、
所定の方法により使用者から入力又は伝達された使用者メッセージを受信し、上記受信された使用者メッセージから一つ又はそれ以上のコンポーネントを抽出し、抽出されたコンポーネントに基づいて上記使用者メッセージを解釈する使用者メッセージ前処理段階と、
上記使用者メッセージから解釈された事項に基づいて、上記使用者が要求する一つ又はそれ以上のアクションを特定するメッセージ処理段階と、
上記参照情報と、上記メッセージ処理段階で特定されたアクションとに基づいて、上記特定されたそれぞれのアクションを遂行するために実行されるべきアプリケーションを選別し、上記選別されたアプリケーションを実行させるアプリ実行段階と、
を含むソフトウェア実行制御方法。
【請求項１５】
上記使用者メッセージ前処理段階は、
所定の方法により使用者から入力又は伝達された使用者メッセージを受信する使用者メッセージ受信段階と、
上記受信された使用者メッセージから一つ又はそれ以上のコンポーネントを抽出し、上記コンポーネントの各々は命令語又はエンティティである使用者メッセージ構造化段階と、
上記抽出された一つ又はそれ以上のコンポーネントに基づいて上記使用者メッセージが定形的メッセージであるかどうかを判断する使用者メッセージ解釈段階とを含み、
上記メッセージ処理段階では、上記使用者メッセージ前処理段階で抽出された一つ又はそれ以上のコンポーネントに基づいてアクションを特定する、
請求項１４記載のソフトウェア実行制御方法。
【請求項１６】
上記メッセージ処理段階は、
上記使用者メッセージが定形的メッセージと解釈されれば、上記定形的使用者メッセージから一つ又はそれ以上のアクションを特定する定形的メッセージ処理段階と、
上記使用者メッセージが定形的メッセージでないと解釈されれば、上記非定型的使用者メッセージから一つ又はそれ以上のアクションを特定する非定型的メッセージ処理段階と
を含む、請求項１５記載のソフトウェア実行制御方法。
【請求項１７】
上記参照情報管理段階は、
一つ又はそれ以上の定形的メッセージの構造に関する情報と、上記定形的メッセージの各々に対応する一つ又はそれ以上のアクションの実行タイミングを規定するアクションフローとを、上記一つ又はそれ以上の定形的メッセージに対応付けて記録した定形的メッセージデータベースを構築して運用し、
上記使用者メッセージ解釈段階では、
上記使用者メッセージ構造化段階で抽出された命令語の内容と個数、及びエンティティの種類とタイプを含むグループから選択された一つ又はそれ以上の情報及び上記定形的メッセージデータベースに記録された情報に基づいて、上記使用者メッセージが定形的メッセージであるかどうかを判断し、
上記定形的メッセージ処理段階では、
上記使用者メッセージ解釈段階で上記使用者メッセージが定形的メッセージと判断されれば、上記定形的メッセージデータベースから上記定形的メッセージに対応付けて記録されたアクションフローを読み出す、
請求項１６記載のソフトウェア実行制御方法。
【請求項１８】
上記参照情報管理段階は、
上記使用者メッセージによって遂行されるように要求された業務を構成する一つ又はそれ以上のアクション要求に対して、一つ又はそれ以上の同義語を対応付けて記録したアクション要求同義語データベースと、
上記アクション要求の各々を充足させるために遂行されるべき一つ又はそれ以上の対応作業を、上記アクション要求の各々に対応付けて記録した対応作業データベースと、
上記それぞれの対応作業の遂行に必要な一つ又はそれ以上のアクションを、上記対応作業の各々に対応付けて記録した対応作業−アクションデータベースを構築して運用し、
上記非定型的メッセージ処理段階では、
上記アクション要求同義語データベース、上記対応作業データベース及び上記対応作業−アクションデータベースの中で一つ又はそれ以上を参照して、上記使用者メッセージから抽出されたエンティティ又は命令語に対応する一つ又はそれ以上のアクションを特定し、上記特定されたアクションの実行タイミングを規定する、
請求項１６記載のソフトウェア実行制御方法。
【請求項１９】
上記参照情報管理段階は、
上記使用者メッセージによって遂行されるように要求された業務を構成する一つ又はそれ以上のアクション要求に対して、一つ又はそれ以上の同義語を対応付けて記録したアクション要求同義語データベースと、
上記アクション要求の各々を充足させる一つ又はそれ以上のアクションを、上記アクション要求の各々に対応付けて記録したアクション要求−アクションデータベースを構築して運用し、
上記非定型的メッセージ処理段階では、
上記アクション要求同義語データベース及び上記アクション要求−アクションデータベースの中で一つ又はそれ以上を参照して、上記使用者メッセージから抽出されたエンティティ又は命令語に対応する一つ又はそれ以上のアクションを特定し、上記特定されたアクションの実行タイミングを規定する、
請求項１６記載のソフトウェア実行制御方法。
【請求項２０】
上記アプリ実行段階は、
上記実行させるべきアプリケーションの入力データのタイプおよびフォーマットに関する情報に基づいて、上記アプリケーションに入力されるべきデータのタイプ又はフォーマットを変更する段階を更に含む、
請求項１４記載のソフトウェア実行制御方法。
【請求項２１】
上記アプリ実行段階は、
上記実行させるべきアプリケーションのプロシージャに関する情報に基づいて、上記アプリケーションの実行を制御する制御信号を生成する段階を更に含む、
請求項１４記載のソフトウェア実行制御方法。
【請求項２２】
上記アプリ実行段階は、
上記使用者メッセージに対し選別されたアプリケーションの出力データの一部又は全てを組み合わせて、上記使用者又は上記使用者メッセージに基づいて決まった受信者に提供する一つ又はそれ以上の出力を生成する出力生成段階を更に含む、
請求項１４記載のソフトウェア実行制御方法。
【請求項２３】
上記参照情報管理段階は、
使用者別に一つ又はそれ以上の特性と、各特性別に複数の選択肢の優先順位及び加重値で構成された集合から選択された情報とを対応付けて記録した特性情報データベースを構築して運用し、
上記メッセージ処理段階では、
上記特性情報データベースを参照して上記使用者メッセージに対応する一つ又はそれ以上のアクションを特定する、
請求項１４乃至１９の何れか１項記載のソフトウェア実行制御方法。
【請求項２４】
上記参照情報管理段階は、
使用者別に一つ又はそれ以上の特性と、各特性別に複数の選択肢の優先順位及び加重値で構成された集合から選択された情報とを対応付けて記録した特性情報データベースを構築して運用し、
上記アプリ実行段階では、
上記特性情報データベースを参照して上記アプリケーションを選別する、
請求項１４乃至１９の何れか１項記載のソフトウェア実行制御方法。
【請求項２５】
上記非定型的メッセージ処理段階では、
上記アクション要求のどれか一つに対応する複数のアクションが存在する場合、上記アクション要求に対応する上記複数のアクションの組合を生成し、上記組合の中で一つ又はそれ以上を選別する、
請求項１８又は１９記載のソフトウェア実行制御方法。
【請求項２６】
上記参照情報管理段階は、
使用者別に特性と、各特性別に複数の選択肢の加重値情報を対応付けて記録した特性情報データベースを構築して運用し、
上記非定型的メッセージ処理段階では、
上記特性情報データベースを参照して、上記組合の各々を構成するアクションの加重値の合計及び積で構成された集合から選択された演算結果から選択された値に基づいて上記選別を遂行する、
請求項２５記載のソフトウェア実行制御方法。
【請求項２７】
使用者から受信した使用者メッセージに基づいて複数のアプリケーションを実行させるようにコンピュータを制御するためのプログラムにおいて、
上記コンピュータを、
複数のアプリケーションの実行のために参照される参照情報を収集し、更新する参照情報管理部、
所定の方法により使用者から入力又は伝達された使用者メッセージを受信し、上記受信された使用者メッセージから一つ又はそれ以上のコンポーネントを抽出し、抽出されたコンポーネントに基づいて上記使用者メッセージを解釈する使用者メッセージ前処理部、
上記使用者メッセージから解釈された事項に基づいて、上記使用者が要求する一つ又はそれ以上のアクションを特定するメッセージ処理部、及び
上記参照情報管理部によって管理される参照情報と、上記メッセージ処理部によって特定されたアクションとに基づいて、上記特定されたそれぞれのアクションを遂行するために実行されるべきアプリケーションを選別し、上記選別されたアプリケーションを実行させるアプリ実行部
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア実行制御装置及び実行制御方法と、その実行制御プログラムに関する。特に、本発明は、使用者のコンピュータシステムに保存されたソフトウェア、又は、外部のコンピュータシステム、例えば、サーバーに保存されたソフトウェアの実行を制御することによって、使用者が必要とする業務に柔軟に対応できるソフトウェア実行制御装置及び実行制御方法と、その実行制御プログラムに関する。
【背景技術】
【０００２】
中小自営業とフランチャイズ等を含む多様な規模と形態のレストランが存在する。このような多様なレストランを運営するためには、多様な種類の業務が遂行される必要があり、今までは通常的に業務の種類によって人が直接処理したり、市中に流通するソフトウェアを購入して処理したりしていた。例えば、店主は、市販された会計用ソフトウェアを購入して、自身のパソコンにインストールし、売り上げ情報を上記ソフトウェアに入力して実行させることによって、売り上げ情報を取得することができる。最近、パソコン、スマートフォン、タブレットPC、等のように、応用ソフトウェア（以下、『アプリケーション』又は簡略に『アプリ』とも呼ぶ）をダウンロードすることができたり、ウェブサーバーに接続してウェブサービスを利用することができる、高性能の、様々なコンピューティングシステムが開発されて広く普及されることに伴って、様々なレストラン業務用アプリケーションが 活発に開発されている。（例えば、特許文献１参照。）
【０００３】
レストランの店主や従業員は、特定業務のための専用アプリケーションに、予め決まった特定のタイプとフォーマットのデータを入力し、上記アプリケーションを実行させることによって、必要な業務を遂行する。店主や従業員は、自分が遂行しようとする業務のために、時々直接プログラム コードを作成してアプリケーションを開発する場合もありえるが、大部分ソフトウェア開発者に専用アプリケーションを開発させたり、ソフトウェア開発者又は開発会社の既に開発した市販用アプリケーションを購入して利用したりする。店主や従業員は、遂行しようとする業務が、一つのアプリケーションによって支援されない作業を含む場合には、上記作業を実行できる一つ又はそれ以上の追加的なアプリケーションを探して、そのアプリケーションを別に実行させたり、自分が直接その作業を行う。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開公報ＷＯ ９１/０８５４０ Ａ１
【発明の概要】
【発明が解決しようとする課題】
【０００５】
レストランビジネスにおいて、例えば、予約管理、帳簿作成、在庫管理、等多様な種類の業務が遂行される必要があり、このような多様な業務が互いに連携されなければならない場合も多い。しかし、このような多様な業務を処理するために、店主が各々自分の要求と状況に合う専用アプリケーションを開発することは、コストと時間面でかなり難しい。また、直接アプリケーションを開発するといっても、業務のプロセスや細部の事項に変動がある場合、これに対応するためには変動があるたびにアプリケーションのプログラムコードを変更したり、完全に新しく開発しなければならない問題もある。
【０００６】
ソフトウェア開発者によって開発された市販用アプリケーションを購入して使う場合には、そのアプリケーションが提供しない機能を追加したり、アプリケーションの機能又は動作を変更したりすることができない。従って、新たな機能が必要になる場合には別のアプリケーションを更に購入したり、必要な機能を含む専用アプリケーションを開発しなければならない。また、遂行されるべき業務のために要求される様々な機能を一つのアプリケーションが支援しない場合も多い。一つのアプリケーションが支援しない追加の機能のためには、この機能を支援する別のアプリケーションを実行させなければならないし、同じデータを重複して複数のアプリケーションに入力したり、入力データのフォーマットを事々に変更したりしなければならない不都合がある。更に、必要な機能を支援するアプリケーションを直接探しなければならないので、多くの時間が所要されるし、必要なアプリケーションを探せない場合は目標にする業務自体を行えなくなることもある。更に、特定業務のために開発されたアプリケーションでは、予定されていなかった業務を全然処理できないという問題点もある。
【０００７】
本発明の課題は、上記の従来技術の問題点を解決することである。具体的に、本発明は、レストランビジネスに必要な多様な種類の業務を迅速に、且つ便利に処理することができるように、複数のソフトウェアの実行を制御するソフトウェア実行制御装置及び実行制御方法と、その実行制御プログラムを提供することを目的とする。本発明の応用分野は、レストランに限定されなくて、病院、学校、書店、劇場、ショッピングセンター、テーマパーク等、本発明の技術思想が適用されることができるところであれば、その業種に制限がないことに注意しなければならない。
【課題を解決するための手段】
【０００８】
上記課題を解決する為に、本発明の１つの態様は、使用者から受信した使用者メッセージに基づいて複数のアプリケーションの実行を制御するソフトウェア実行制御装置において、複数のアプリケーションの実行のために参照される参照情報を収集し、更新する参照情報管理部と、所定の方法により使用者から入力又は伝達された使用者メッセージを受信し、上記受信された使用者メッセージから一つ又はそれ以上のコンポーネントを抽出し、抽出されたコンポーネントに基づいて上記使用者メッセージを解釈する使用者メッセージ前処理部と、上記使用者メッセージから解釈された事項に基づいて、上記使用者が要求する一つ又はそれ以上のアクションを特定するメッセージ処理部と、上記参照情報管理部によって管理される参照情報と、上記メッセージ処理部によって特定されたアクションとに基づいて、上記特定されたそれぞれのアクションを遂行するために実行されるべきアプリケーションを選別し、上記選別されたアプリケーションを実行させるアプリ実行部とを含むソフトウェア実行制御装置を提供する。
【０００９】
また、本発明の他の１つの態様は、ソフトウェア実行制御装置を利用して、使用者から受信した使用者メッセージに基づいて複数のアプリケーションの実行を制御するソフトウェア実行制御方法において、複数のアプリケーションの実行のために参照される参照情報を収集し、更新する参照情報管理段階と、所定の方法により使用者から入力又は伝達された使用者メッセージを受信し、上記受信された使用者メッセージから一つ又はそれ以上のコンポーネントを抽出し、抽出されたコンポーネントに基づいて上記使用者メッセージを解釈する使用者メッセージ前処理段階と、上記使用者メッセージから解釈された事項に基づいて、上記使用者が要求する一つ又はそれ以上のアクションを特定するメッセージ処理段階と、上記参照情報と、上記メッセージ処理段階で特定されたアクションとに基づいて、上記特定されたそれぞれのアクションを遂行するために実行されるべきアプリケーションを選別し、上記選別されたアプリケーションを実行させるアプリ実行段階とを含むソフトウェア実行制御方法を提供する。
【００１０】
また、本発明の他の１つの態様は、使用者から受信した使用者メッセージに基づいて複数のアプリケーションを実行させるようにコンピュータを制御するためのプログラムにおいて、上記コンピュータを、複数のアプリケーションの実行のために参照される参照情報を収集し、更新する参照情報管理部、所定の方法により使用者から入力又は伝達された使用者メッセージを受信し、上記受信された使用者メッセージから一つ又はそれ以上のコンポーネントを抽出し、抽出されたコンポーネントに基づいて上記使用者メッセージを解釈する使用者メッセージ前処理部、上記使用者メッセージから解釈された事項に基づいて、上記使用者が要求する一つ又はそれ以上のアクションを特定するメッセージ処理部、及び上記参照情報管理部によって管理される参照情報と、上記メッセージ処理部によって特定されたアクションとに基づいて、上記特定されたそれぞれのアクションを遂行するために実行されるべきアプリケーションを選別し、上記選別されたアプリケーションを実行させるアプリ実行部として機能させるためのプログラムを提供する。
【発明の効果】
【００１１】
本発明によれば、使用者が要求する業務を充足させるアクションフローを生成し、このアクションフローに従って一つ又は複数のアプリケーションを選別し、選別されたアプリケーションの実行を制御することによって、迅速に、且つ効率的に使用者が要求する多様な業務に対応するソフトウェア実行制御装置及び実行制御方法と、実行制御プログラムを提供することができる。従って、複雑な業務を構成する多様な動作を遂行する専用のアプリケーションを別に開発する必要がなく、複数のアプリケーションを様々に組み合わせて使用者が要求する多様な業務に対応することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施例によるソフトウェア実行制御装置の構成を概念的に示す図面である。
【図２】本発明のソフトウェア実行制御装置の使用者メッセージ前処理部、メッセージ処理部、アプリ実行部、及び、参照情報管理部の構成の一実施例を概念的に示す図面である。
【図３】本発明の一実施例によるソフトウェア実行制御方法を示すフローチャートである。
【図４】本発明の一実施例による構造化された使用者メッセージを示す図面である。
【図５】本発明の一実施例による構造化された使用者メッセージのエンティティ構造テーブルを示す図面である。
【図６】本発明の一実施例による構造化された使用者メッセージの命令語構造テーブルを示す図面である。
【図７】本発明の一実施例による定形的メッセージ データベースの構造を示す図面である。
【図８】図７に図示された定形的メッセージデータベースのレストラン用システムの実施例を示す図面である。
【図９】本発明の一実施例によるアクション要求同義語データベースの構造を示す図面である。
【図１０】本発明の一実施例による対応作業データベースの構造を示す図面である。
【図１１】本発明の一実施例による対応作業―アクションデータベースの構造を示す図面である。
【図１２】本発明の一実施例による使用者メッセージのコンポーネント別候補アクション目録を示す図面である。
【図１３】本発明の一実施例による特性情報データベースの構造を示す図面である。
【図１４】本発明の一実施例による使用者メッセージの候補アクションフロー目録を示す図面である。
【図１５】本発明の一実施例によるアクション−アプリデータベースの構造を示す図面である。
【図１６】本発明の一実施例によるアプリケーション特定方法を概念的に示す図面である。
【図１７】本発明の一実施例によるアプリケーションプロシージャデータベースの構造を示す図面である。
【図１８】本発明の一実施例によるアプリ実行プロセスにおいてアプリケーション間の入力及び出力データの関係を概念的に示す図面である。
【図１９】本発明の一実施例によるレストラン要約及び注文管理システムを概念的に示す図面である。
【発明を実施するための形態】
【００１３】
以下、添付図面を参照して本発明に係る実施の形態の例について詳細に説明する。勿論、本発明の技術的範囲が添付図面に示された例に限定されるものではない。
【００１４】
図１は、本発明の一実施例によるソフトウェア実行制御装置１００の構成を概念的に示す図面である。図１に示されたように、本発明の一実施例によれば、本発明のソフトウェア実行制御装置１００は、中央処理装置ＣＰＵ１０２と、基本入出力システムＢＩＯＳ(Basic Input Output System)１０４と、データやファイル等を保存するためのハードディスクやＣＤ‐ＲＯＭ等の記憶装置１０６と、メモリー１０８を含んで、ＵＳＢ、電源装置、ディスプレイデバイス等の各種ハードウェア１１０と、各種データや情報を相互関連づけて管理するデータベース１１２を含む。また、本発明のソフトウェア実行制御装置１００は、プログラミングインターフェース、各種ドライバー、ライブラリーなどのソフトウェア１２０と、オペレーティングシステム（ＯＳ）１２２とを含む。また、本発明のソフトウェア実行制御装置１００は、使用者から受信した使用者メッセージを構造化して解釈する使用者メッセージ前処理部２００と、上記使用者メッセージから使用者の要求を糾明して上記使用者の要求を充足させる作業やオペレーションを特定するアクションフローを生成するメッセージ処理部３００、上記アクションフローに対応するアプリケーションを選別し、選別されたアプリケーションの実行を制御するアプリ実行部４００と、複数のアプリケーションの実行のために参照される参照情報を収集して更新する参照情報管理部５００を更に含む。上記構成要素は、バス１４０によって相互接続される。図１は、本発明のソフトウェア実行制御装置１００の構成の一実施例であるだけで、実施例によっては、上記構成要素の中で一部を含まなかったり、他の構成要素を更に含んだりすることができる。
【００１５】
ソフトウェア実行制御装置１００には、メインフレーム、マイクロコンピュータ、ワークステーション、パソコン、等の典型的なコンピュータシステムは勿論、タブレット、ＰＤＡ、スマートフォン等、演算能力を持つハンドヘルドデバイスも含まれる。ソフトウェア実行制御装置１００のハードウェア的形態や構造、運営体系等のソフトウェア的アーキテクチャーに特別な制限はない。例えば、ソフトウェア実行制御装置１００は、ＰＯＳ（Ｐｏｉｎｔ  ｏｆ  Ｓａｌｅ）端末装置である。上記構成要素２００乃至５００の各々は、ロム（ＲＯＭ）、フラッシュメモリー、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ等の適合なハードウェアに記録されることができる純粋なソフトウェアとして具現されたり、論理回路等のハードウェアとソフトウェアとの組合として具現されたりすることもできる。また、上記構成要素２００乃至５００が全て一つのデバイス内に具現されることもできるが、複数のデバイスに分散されるように具現されることもできる。例えば、上記構成要素２００乃至５００の一部又は全部が、ネットワークで接続された外部サーバーに保存されることもできる。
【００１６】
構成要素２００乃至５００がソフトウェアとして具現される場合、これらはオブジェクティブシー（ｏｂｊｅｃｔｉｖｅ  Ｃ）、Ｃ＋＋、ジャバ（Ｊａｖａ（登録商標））等の言語を利用した客体指向型プログラミングによって具現されることができる。または、ベーシック（ＢＡＳＩＣ）、Ｃ等の言語を利用したプロシージャ型プログラミング（Ｐｒｏｃｅｄｕｒａｌ  Ｐｒｏｇｒａｍｍｉｎｇ）により具現されることもできる。図１は、構成要素２００乃至５００がＣＰＵ１０２等のハードウェアやＯＳ１２２から独立的に具現された実施例を示しているが、設計上の選択によってＯＳ１２２の一部として具現されたり、アプリケーションとして具現されることもできる。即ち、本発明が属する技術分野で通常の知識を持つ者であれば、本発明の技術思想の具現方式にはいかなる制限もないことを明確に理解することができる。構成要素２００乃至５００の細部的な構成及び動作に関しては、本明細書の全体にかけて、特に、以下で詳細に説明する。
【００１７】
多様な業務用アプリケーションは、上記ソフトウェア実行制御装置１００のメモリー１０８又は記憶装置１０６に保存されたり、外部サーバー（例えば、ウェブサーバー）のような独立的なコンピュータシステム１５０ａ、１５０ｂに保存されることができる。本明細書で、『アプリケーション』（又は、その略語である『アプリ』）という用語は、個別の応用ソフトウェアだけでなく、独立的な機能を遂行するソフトウェアの一部を示すこともでき、使用者端末デバイスにインストールされて独立的に実行されるアプリケーションだけでなく、サーブレット、アプレット、ウィジェット、ウェブサービス等、様々な形態で具現されることができる。即ち、アプリケーションの形態や 具現方式には特別な制限がない。それぞれのアプリケーションは、独立的に、又は、他のアプリケーションと相互連携して固有のフォーマットを持つ出力を生成する。上記アプリケーションがソフトウェア実行制御装置１００の内部に保存される場合には、特定ディレクトリの特定フォルダとして定義される位置情報に基づいて呼び出されることができる。アプリケーションが外部のコンピュータシステム１５０ａ、又は、１５０ｂに存在する場合には、例えば、ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）のような位置情報に基づいて呼び出されたり、探索されたりすることができる。
【００１８】
使用者メッセージ前処理部２００は、使用者メッセージから形式的部分を識別して、一つ又はそれ以上の使用者メッセージコンポーネントを抽出するために、上記使用者メッセージを構造化し、上記構造化されたメッセージを解釈して上記使用者メッセージが定形的メッセージなのか非定型的メッセージなのかを判断する。上記使用者メッセージのコンポーネントは、各々が独立的な情報を現わす単語として、内容により特定動作やオペレーションを指示する命令語と、命令語の遂行に活用される意味内容（人間、事物、事件、場所、時間、等）であるエンティティとに分類されることができる。定形的メッセージは、予め決まった内容と個数の命令語や、予め決まった種類、タイプ及び個数のエンティティを含む。上記使用者メッセージが定形的メッセージであれば、メッセージ処理部３００は、定形的メッセージとアクションフローとを対応づけて記録したデータベースを参照して、上記定形的メッセージに対応するアクションフローを読み出す。上記使用者メッセージが定形的メッセージでなければ、メッセージ処理部３００は上記使用者メッセージの要求を究明し、上記究明された要求を充足させる一連の、又は、並列的な作業やオペレーションの組合、即ち、アクションフローを生成する。上記アクションフローは、実行されるべきアクションの実行時点や実行順序の先後、即ち、実行タイミングを規定する。アプリ実行部４００は、上記メッセージ処理部によって生成されたアクションフローに含まれた各アクションに対応するアプリケーションを選別し、選別されたアプリケーションを実行させる。また、各々のアプリケーションに入力されるデータのタイプ及び／又はフォーマットを変換したり、各々のアプリケーションの実行を制御するための制御信号を生成する。尚、アプリ実行部は、選択的に、上記実行されたアプリケーションの出力データを組み合わせて上記使用者又は上記使用者メッセージに基づいて決まった受信者に提供する出力を生成することもできる。参照情報管理部５００は、メッセージ処理部３００とアプリ実行部４００が参照する各種参照情報を構築して運用する。参照情報管理部５００は、システム設計者、システム管理者、又は、使用者等から関連情報を受信したり、このような情報を定期に、又は、随時に収集して分類したりして、各種参照情報を更新することができる。
【００１９】
図２は、本発明のソフトウェア実行制御装置の使用者メッセージ前処理部２００、メッセージ処理部３００、アプリ実行部４００、及び、参照情報管理部５００の構成の一実施例を示す図面である。図２に示された実施例で、上記使用者メッセージ前処理部２００、メッセージ処理部３００、アプリ実行部４００、及び、参照情報管理部５００の各々は、上記の動作を実行する複数のモジュールを含むように具現される。本発明が属する技術分野で通常の知識を持つ者は、図２と異なる様々な具現方式が存在することができ、各モジュールの機能構成の広狭によって本発明の技術的範囲が限定されるのではないことを明確に理解することができる。
【００２０】
使用者メッセージ前処理部２００は、使用者メッセージ受信モジュール２０２と、使用者メッセージ構造化モジュール２０４と、使用者メッセージ解釈モジュール２０６とを含む。使用者が、ソフトウェア実行制御装置１００へ所定の業務の遂行を要請する内容の使用者メッセージを入力すれば、ソフトウェア実行制御装置１００が動作を開始する。所定の方法によって使用者からの使用者メッセージが入力、又は、伝達されると、上記使用者メッセージは使用者メッセージ受信モジュール２０２によって受信される。上記使用者メッセージは、ソフトウェア実行制御装置１００に有線、又は、無線で連結されたキーボード、マウス、又は、マイク等の入力装置（図示されていない）を通じて入力されることができる。ソフトウェア実行制御装置１００がディスプレイデバイスを含むならば、使用者がマウス等の入力装置を通じて上記使用者メッセージを入力することができるように、上記ディスプレイデバイスを通じてグラフィカルユーザインタフェースを提供することもできる。この場合、ディスプレイデバイスに表示された特定業務を指示するアイコンをマウスでクリックする方式も可能である。もし、マイクを通じて音声命令が入力された場合、使用者メッセージ受信モジュール２０２は、音声命令をテキストに変換して使用者メッセージ構造化モジュール２０４へ伝達する。また、ソフトウェア実行制御装置１００は、外部の通信デバイスから電子メール、携帯電話メッセージ等の形態で使用者要求を受信することもできる。このために、ソフトウェア実行制御装置１００は、予め特定された電子メールアドレス、電話番号等の固有な識別情報を持つことができる。例えば、使用者はソフトウェア実行制御装置１００に特定業務の遂行を要求するために、ソフトウェア実行制御装置１００とは別個の自分の携帯電話を利用して、ソフトウェア実行制御装置１００に予め指定されたメールアドレスに電子メールを送信することができる。この場合、使用者はソフトウェア実行装置１００から遠く離れた場所にいる時も、ソフトウェア実行制御装置１００に必要な業務を要請することができるので、非常に便利である。 
【００２１】
便宜性のために、使用者メッセージは使用者が日常的に使う言語である自然語で作成されることができる。使用者は、特定業務を遂行するためにどのアプリケーションを実行させるべきか、実行させるべき一つ又は複数のアプリケーションの入力のタイプやフォーマットが何であるか等を具体的に知っている必要はなくて、上記業務を自然語で記述すればいい。例えば、ソフトウェア実行制御装置１００がレストランに設置されたＰＯＳ端末装置であり、使用者がレストランを運営する店主の場合を仮定する。使用者が個人的な用務のためにレストランの外部にいる時、当日の売り上げを分かりたければ、自分の携帯電話で『今日の売り上げを知らせて下さい』という内容の電子メール又は携帯電話メッセージを上記ＰＯＳ端末装置へ伝送すればいい。この場合、後述のように、上記ＰＯＳ端末装置は上記使用者メッセージを処理して必要になるアプリケーションを識別し、識別されたアプリケーションを実行させる。次に、上記実行の結果として得られた当日の売り上げデータを適合した形態（例えば、テキストファイル）で生成して電子メール又は携帯電話メッセージとして使用者の携帯電話へ伝送する。このように、使用者メッセージを入力できる方法を多様化することによって、便宜性を向上させることができる。
【００２２】
使用者メッセージ構造化モジュール２０４は、使用者メッセージ受信モジュール２０２が受信した使用者メッセージに含まれている有意味なデータ（例えば、送信者の身元、送信日時、送信場所等）とメッセージ本文を抽出する。次に、使用者メッセージ（特に、形式的情報以外の本文の内容の部分）に対して、例えば、形態素分析を適用して、意味を持つ最小の単位である形態素に使用者メッセージを分離する。形態素分析方法は、言語の特性によって差があり、言語ごとに様々な種類の分析技術が存在する。どの形態素分析方法を採用するのかは、システム設計者の選択であり、必ず特定の方法を採用すべきことではない。続いて、上記使用者メッセージ構造化モジュール２０４は、使用者メッセージの各形態素に意味表紙を与えることによって、使用者メッセージを構造化する。形態素に意味表紙を与えるために、例えば、オントロジー（ｏｎｔｏｌｏｇｙ）マッピング技法が使われる．例えば、『５時』は時間、『○○会社』は企業という意味表紙が与えられる。また、使用者メッセージ構造化モジュール２０４は、例えば、六何の法則（５Ｗ１Ｈ）にしたがって使用者メッセージを構造化することによって、使用者メッセージが持つ全体的な意味を規定する。
【００２３】
例えば、上記使用者が電子メールの形で自分のメッセージを送信した場合に、上記使用者メッセージ構造化モジュール２０４は、上記使用者メッセージ受信モジュール２０２によって受信された電子メールから送信者の電子メールアドレスとメッセージ本文等を識別し、識別された電子メールアドレスから使用者が誰であるか、ソフトウェア実行制御装置１００にアクセスできる権限を持つ者であるかどうかを判断することができる。このために、予め使用者別に識別子（ＩＤ）、電子メールアドレス、携帯電話番号等の識別情報を記録した使用者データベースを構築しておくことが望ましい。もし、ソフトウェア実行制御装置１００に対するアクセス権限を持っていない者が使用者メッセージを送信した場合には、動作を終了する。この場合、ソフトウェア実行制御装置１００は、発信者、システム管理者、又は、権限を持った使用者中選択された者にその旨を通知するメッセージを送信することもできる。一方、上記使用者が正当な権限を持つ使用者であれば、上記のようなメッセージ分析を進行して使用者の要求内容をより一層正確に究明する。
【００２４】
次に、上記使用者メッセージ構造化モジュール２０４は、構造化された使用者メッセージから一つ又はそれ以上の使用者メッセージコンポーネント（以下、簡略に『コンポーネント』とも呼ぶ）であるエンティティと命令語とを抽出する。例えば、六何の法則により使用者メッセージを構造化した場合、５Ｈに該当するコンポーネントがエンティティであり、１Ｈに該当するコンポーネントが命令語である。通常、使用者メッセージは一つ又はそれ以上の命令語であるコンポーネントを含むことができる。構造化された使用者メッセージの実施例は図４に示される。図４の実施例で、例えば、使用者１の使用者メッセージｉはエンティティＥＮＴｉ１、ＥＮＴｉ２とＥＮＴｉ３、及び命令語ＣＯＭＭｉ１を含む。エンティティであるコンポーネントは、以後にアプリケーションを実行させる時に必要になる入力データとして利用されることができる。
【００２５】
次に、使用者メッセージが定形的なメッセージであるかどうかを判断するために、使用者メッセージ解釈モジュール２０６が上記構造化された使用者メッセージを解釈する。このために、上記構造化された使用者メッセージに関するエンティティ構造テーブルと命令語構造テーブルを生成することができる。エンティティ構造テーブルは、エンティティ別に種類とタイプを識別して保存し、命令語構造テーブルは、命令語の内容を識別して各命令語の個数を保存する。これによって、使用者メッセージがどんな種類のエンティティとどんな内容の命令語とを含んでいるのかを判別できる。使用者メッセージの解釈に関するもっと詳細な説明は図４乃至図６を参照して後述する。もし使用者メッセージが予め決まった種類及びタイプのエンティティと、予め決まった内容及び個数の命令語を含んでいれば、このメッセージは定形的メッセージと判断される。このために、定形的メッセージの構造(エンティティーの種類とタイプ、命令語の内容と個数)を、後述のような定形的メッセージデータベース５１０に記録しておき、現在入力された使用者メッセージの構造と上記データベースに保存された定形的メッセージの構造とを比較することによって、上記使用者メッセージが定形的メッセージであるかどうかを判断することができる。特に、使用者が要求できる多様な業務の中で、反復的に要求される可能性が高い業務に対しては、当該業務に対応する使用者メッセージの定形的構造を予め定形的メッセージデータベース５１０に記録しておくことが望ましい。
【００２６】
次に、メッセージ処理部３００は、各々が、使用者メッセージ解釈モジュール２０６によって定形的メッセージと判断された使用者メッセージと、非定型的メッセージと判断された使用者メッセージに対するアクションフローを生成する等の処理を行う定形的メッセージ処理モジュール３０２と非定型的メッセージ処理モジュール３０４とを含む。本明細書で、使用者の要求を充足させるために遂行されるべき作業として、その内容上お互いに独立的に区別されることができる最小単位の作業又は動作（オペレーション）を『アクション』と呼ぶ。特定メッセージを通じて使用者が要求している業務は一つのアクションで構成される場合もあるが、一定の順序で組合わせた二つ以上のアクションで構成される場合も多い。このように業務を構成する一つ又は複数のアクションの順次、又は、並列的な組合を『アクションフロー』と呼ぶ。アクションフローは、さらにまた、実行されるべきアクションの実行タイミング（実行の時点又は実行の順序）を規定する。レストランで本発明のソフトウェア実行制御装置１００を使う例を仮定してみれば、『予約情報登録』、『予約情報照会』、『予約情報削除』、『予約情報変更』等の各々がアクションに該当する。このようなアクションの各々は、一つのアプリケーション又はアプリケーションの一部によって遂行されることができる。本発明によれば、上記アクションはその内容上区分される最小単位の作業や動作として定義されるので、一つの使用者メッセージに対応して同じアクションが反復的に実行されることもできる。例えば、『予約情報照会』というアクションは、一人の顧客に関する特定の売り場での特定日の予約情報を問い合わせるように一回だけ実行されることもできるが、特定日の全ての売り場に対する全ての顧客の予約情報を一括に問い合わせるように数回にかけて反復的に実行されることもできる。
【００２７】
図７及び図８を参照して後述するように、定形的メッセージデータベース５１０は、一つ又はその以上の定形的メッセージと、各々の定形的メッセージに対して所定のアクションフローとを対応付けて記録する。このような定形的メッセージデータベース５１０を活用することによって、定形的メッセージ処理モジュール３０２は、実行時に定形的メッセージと解釈される使用者メッセージが存在する場合、上記定形的メッセージデータベース５１０から当該定形的メッセージに対応するアクションフローを読み出すことができる。もし一つの使用者メッセージが、二つ以上の定形的メッセージを含んでいれば、それぞれの定形的メッセージに対応するアクションフローを、順次に、又は、並列に組み合わせて当該使用者メッセージに対する最終的なアクションフローを生成することができる。これによって、使用者メッセージとして定形的メッセージが入力された場合には、単にデータベースに記録された情報を読み出すだけでアクションフローを迅速に、且つ、容易に生成することができる。
【００２８】
一方、非定型的メッセージ処理モジュール３０４は、定形的メッセージに該当しないと解釈された、即ち、非定型的メッセージと解釈された使用者メッセージに対して、上記使用者メッセージの各コンポーネントに対応するアクションを選別し、選別されたアクションを順次に、又は、並列に組み合わせて上記非定型的使用者メッセージの処理のためのアクションフローを生成する。上記各アクションの選別のためには、後述するアクション要求同義語データベース５２０、対応作業データベース５３０、対応作業−アクションデータベース５４０及び／又は特性情報データベース５５０が参照される。このような非定型的メッセージ処理モジュール３０４の動作に関しては、図９乃至図１４を参照して後述する。
【００２９】
次に、アプリ実行部４００は、アプリ選別モジュール４０２とアプリ実行制御モジュール４０４を含んでおり、実施例によって選択的に出力生成モジュール４０６を含むことができる。アプリ選別モジュール４０２は、メッセージ処理部３００によって生成されたアクションフローの各アクションに対応するアプリケーションを選別する。アプリ実行制御モジュール４０４は、上記選別されたアプリケーションの一部又は全部を実行させる。アプリ選別モジュール４０２は後述するアクション−アプリデータベース５６０を参照して、それぞれのアクションに対応するアプリケーションを選別することができる。アクション−アプリデータベース５６０は、独立的に遂行される単位作業又は動作（オペレーション）であるアクションの識別情報と、当該アクションを遂行するために必要になるアプリケーションの識別情報を対応づけて記録する。アクション−アプリデータベース５６０を参照した結果、一つのアクションを遂行するアプリケーションが複数個存在する場合には、後述する特性情報データベース５５０を参照してより適合したアプリケーションを選別する。上記選別されたアプリケーションを実行させるために、アプリ実行制御モジュール４０４は後述するアプリプロシージャデータベース５７０を参照して、アプリケーションを実行するために必要になる制御信号を生成する。また、アプリ実行制御モジュール４０４は、アプリ実行情報データベース５８０を参照して、必要な場合、アプリケーションの実行に必要なデータのタイプやフォーマットを変換する。
【００３０】
上記選別された全てのアプリケーションの実行が終了すれば、上記使用者又は上記使用者メッセージに基づいて決まった受信者に処理結果を伝送する。上記処理結果は、最後に実行されたアプリケーションの出力データ又は実行された全てのアプリケーションの出力データの一部又は全体でありうる。これは、使用者メッセージの要求内容によって変わる。必要な場合、使用者又は特定受信者に提供される上記出力データは、あらかじめ決まったタイプ、フォーマット又は出力方式により変換されることができる。または、出力生成モジュール４０６が実行された全てのアプリケーションの出力データの一部又は全部を組み合わせて処理結果を生成し、上記使用者又は特定受信者にあらかじめ決まったタイプ、フォーマット又は出力方式で、上記処理結果を提供することができる。出力生成モジュール４０６は、上記出力データの一部又は全部を複数の出力に分割したり、複数の出力データを一つ又は他の個数の出力に組合わせることもできる。上記使用者又は特定受信者に適合した出力のタイプ、フォーマット又は出力方式は特性情報データベース５５０を参照して決定されることもできる。
【００３１】
参照情報管理部５００は、定形的メッセージデータベース５１０と、アクション要求同義語データベース５２０と、対応作業データベース５３０と、対応作業−アクションデータベース５４０と、特性情報データベース５５０と、アクション−アプリデータベース５６０と、アプリプロシージャデータベース５７０と、アプリ実行情報データベース５８０と、参照情報運用モジュール５９０とを含む。上記データベース５１０乃至５８０のそれぞれの構造は、図７、図９、図１０、図１１、図１３、図１５、図１７及び図１８に各々図示されている。各データベースに関する詳細な内容は、対応する図面を参照して後述する。本実施例によれば、データベース５１０乃至５８０の全てが本発明のソフトウェア実行制御装置１００の参照情報管理部５００の内に構築されるように構成されている。しかし、本発明が属する技術分野で通常の知識を持つ者であれば、上記データベース５１０乃至５８０の一部又は全てが必ず上記ソフトウェア実行制御システム１００の内に構築されるべきことではないし、例えば、外部サーバー等に既に構築されているデータベースを活用することもできることを明確に理解することができる。
【００３２】
参照情報運用モジュール５９０は、上記データベース５２０乃至５８０を随時又は定期に構築して更新する。上記データベース５２０乃至５８０は、使用者の要求を処理する前にあらかじめ構築されることもできるし、処理の実行の際リアルタイムで構築されることもできる。上記データベース５２０乃至５８０に記録された情報は、システム設計者、システム管理者又は正当な権限を持つ使用者によって変更、追加又は削除されることができるし、このために、参照情報運用モジュール５９０は適合なインターフェースを提供することができる。尚、上記データベースに記録された情報は、時間の経過によって変わることがあるので、上記データベースが変わった情報を含むように参照情報運用モジュール５９０が定期又は随時に上記データベースを更新する。これによって、使用者の要求により一層適合するように対応できることになる。
【００３３】
例えば、参照情報運用モジュール５９０は、定期又は随時に、又は、システム管理者や使用者から指示がある時、ソフトウェア実行制御装置１００の内部又は外部の所定の領域を探索し、アプリケーションに関する情報を収集し、収集した情報に基づいてアクション−アプリデータベース５６０又は特性情報データベース５５０にアプリケーションの識別情報を登録したり、その変化を管理したりする。参照情報運用モジュール５９０は、新たなアプリケーションがあるのか、既存のアプリケーションの位置情報が変わったのか、アプリケーションがアップデートされたのか、又は、アプリケーションが削除されたのか等の変更内容を探知する。参照情報運用モジュール５９０はこの変更内容を参照して対応するデータベースに記録された情報を更新する。例えば、ソフトウェア実行制御装置１００の内部に保存されていたアプリケーションが異なるフォルダに移されたら、参照情報運用モジュール５９０がこれを探知してアクション−アプリデータベース５６０に記録された当該アプリケーションの位置情報を変更された位置情報に更新する。この時、同じ情報が複数のデータベースに記録されていれば、上記複数のデータベースを一括に更新することが望ましい。また、アプリケーションのアップデートバージョンがある場合には、アクション−アプリデータベース５６０のアプリケーション情報が上記アップデートバージョンの位置情報に更新される。
【００３４】
次に、図３を参照して本発明の一実施例によるソフトウェア実行制御方法を説明する。使用者が所定の業務を遂行することを要請する内容の使用者メッセージを本発明のソフトウェア実行制御装置１００へ入力、伝送又は伝達することで、本発明のプロセスが開始される（段階１０００）。ソフトウェア実行制御装置１００は、所定の方法によって入力されたり、伝送又は伝達された上記使用者メッセージを受信し（段階１００２）、上記使用者メッセージを構造化する（段階１００４）。例えば、上記使用者メッセージが自然語の形態で作成された場合は、上記受信された使用者メッセージに形態素分析方法を適用し、各形態素に意味表紙を与える。次に、ソフトウェア実行制御装置１００は、上記構造化された使用者メッセージから一つ又はそれ以上のコンポーネントであるエンティティ及び／又は命令語を抽出する（段階１００６）。次に、ソフトウェア実行制御装置１００は、上記構造化された使用者メッセージを解釈するために、抽出された命令語の内容と個数、エンティティの種類とタイプを識別する（段階１００８）。上記識別された情報に基づいて、上記使用者メッセージが定形的メッセージであるかどうかを判断する（段階１０１０）。このために定形的メッセージデータベース５１０を参照する。 
【００３５】
上記使用者メッセージが定形的メッセージである場合は（段階１０１０：Ｙｅｓ）、定形的メッセージデータベース５１０に当該定形的メッセージに対応して記録されたアクションフローを読み出すことで、上記使用者メッセージに対応するアクション フローを生成する（段階１０２０）。上記使用者メッセージが非定型的メッセージである場合は（段階１０１０：Ｎｏ）、上記使用者メッセージに内包された使用者の要求を究明するために、上記抽出されたコンポーネントに対応するアクション要求を選別し、上記選別されたアクション要求を充足させるアクションを選別し、上記選別されたアクションを順次に、又は、並列に組み合わせてアクションフローを生成する（段階１０４０）。上記生成されたアクションフローはキャッシュメモリー、バッファー、キュー（ｑｕｅｕｅ）等に保存されることができる。このように、上記使用者メッセージからアクションフローが生成されれば、アクションフローの各アクションを遂行するためのアプリケーションを選別する（段階１０６０）。このために、各アクションと、当該アクションを充足させるアプリケーションを対応付けて記録したアクション−アプリデータベース５６０を参照することができる。尚、一つのアクションに対応するアプリケーションが複数であれば、例えば、特性情報データベース５５０を参照して、その中で最も適合した一つのアプリケーションを選別することも可能である。
【００３６】
次に、ソフトウェア実行制御装置１００は、上記選別されたアプリケーションを呼出する（段階２０００）。各アプリケーションはその位置情報に基づいて呼び出しされることができる。次に、それぞれのアプリケーションに対して、当該アプリケーションが必要とする入力データのタイプとフォーマットとを確認する（段階２００２）。このために、各アプリケーションの識別情報と、当該アプリケーションの入力データのタイプ及びフォーマットとを対応づけて記録したアプリ実行情報データベース５８０を参照することができる。もし上記アプリケーションに入力されるべきデータのタイプ及びフォーマットが、当該アプリケーションの入力データのタイプ及びフォーマットと一致すれば（段階２００２：Ｙｅｓ）、上記データをそのままアプリケーションに入力してアプリケーションを実行させる（段階２００６）。もし入力されるべきデータのタイプやフォーマットが当該アプリケーションの入力データのタイプやフォーマットと一致しなければ（段階２００２：Ｎｏ）、上記データのタイプとフォーマットを上記入力データのタイプとフォーマットに合わせて変換する（段階２００４）。次に、上記ソフトウェア実行制御装置１００は上記アクションフローの全てのアクションのためのアプリケーションが実行されたかを確認する（段階２００８）。実行されるべきアプリケーションの中で一部がまだ実行されなかった場合は（段階２００８：Ｎｏ）、段階２０００に戻る。上記アクションフローに対応する全てのアプリケーションの実行が完了した場合（段階２００８：Ｙｅｓ）、全て又は一部のアプリケーションの出力データを使用者又は使用者メッセージに基づいて選定された特定受信者に提供し（段階２０１０）、当該使用者メッセージに対する処理プロセスを終了する（段階２０２０）。
【００３７】
次に、図４乃至図６を参照して、使用者メッセージの解釈に関してより一層詳細に説明する。図４は本発明の一実施例による構造化された使用者メッセージを示す。図５は本発明の一実施例による構造化された使用者メッセージのエンティティ構造テーブルを図示し、図６は本発明の一実施例による構造化された使用者メッセージの命令語構造テーブルを図示する。図４に示されたように、使用者１から受信された使用者メッセージｉは三個のエンティティＥＮＴｉ１、ＥＮＴｉ２及びＥＮＴｉ３と、一個の命令語ＣＯＭＭｉ１を含んでおり、使用者２から受信された使用者メッセージｊは二つのエンティティＥＮＴｊ１及びＥＮＴｊ２と、二つの命令語ＣＯＭＭｊ１及びＣＯＭＭｊ２を含む。使用者メッセージ解釈モジュール２０６は上記構造化された使用者メッセージからエンティティ構造テーブルと命令語構造テーブルを生成する。エンティティ構造テーブルは、図５に示されたように、上記使用者メッセージに含まれたエンティティ別に種類とデータタイプとを識別して保存する。例えば、エンティティの種類は、使用者メッセージ構造化モジュール２０４によって与えられた意味表紙に基づいて定められることができるし、名称、電話番号、日付、人数等を含むことができる。命令語構造テーブルは命令語の内容を識別して各命令語の個数を保存する。上記エンティティ構造テーブルと命令語構造テーブルによって、使用者メッセージがどんな種類のエンティティと、どんな内容の命令語を含んでいるのかを判別することができる。上記使用者メッセージの解釈方法は一つの実施例にすぎないし、本発明が属する技術分野で通常の知識を持つ者は多様な変形又は代案が存在することを明確に認識することができる。例えば、上記実施例では定形的メッセージがエンティティと命令語の両方を含む場合を説明したが、他の実施例によればエンティティだけを含む定形的メッセージがあり、また他の実施例によれば命令語だけを含む定形的メッセージがありえる。このような定形的メッセージの構造は設計上の選択事項にすぎないし、本発明が特定構成に限定されることではない。
【００３８】
次に、図７及び図８を参照して、定形的メッセージデータベース５１０に関して説明する。定形的メッセージデータベース５１０は定形的メッセージの識別情報（ＳｔｐＭＥＳ０１、ＳｔｐＭＥＳ０２、ＳｔｐＭＥＳ０３、ＳｔｐＭＥＳ０４）と、それぞれの定形的メッセージの構造と、それぞれの定形的メッセージを充足させるアクションフローを相互間に対応づけて記録する。例えば、定形的メッセージＳｔｐＭＥＳ０１は一つの命令語ＣＯＭＭ１１と、二つのエンティティＥＮＴ１１及びＥＮＴ１２とを含む構造を持ち、エンティティＥＮＴ１１の種類とタイプは各々Ｋｉｎｄ０１とＴｙｐｅ１１であり、エンティティＥＮＴ１２の種類とタイプは各々Ｋｉｎｄ０２とＴｙｐｅ１２である。受信された使用者メッセージが上記のような構造を持っていれば（即ち、命令語ＣＯＭＭ１１と、上記種類及びタイプのエンティティＥＮＴ１１及びＥＮＴ１２とを含む）、当該使用者メッセージは定形的メッセージＳｔｐＭＥＳ０１に該当する。従って、上記使用者メッセージに対するアクションフローは、ＡＣＴ１１＋ＡＣＴ１２＋ＡＣＴ１６として規定されることができる。このように、使用者メッセージが定形的メッセージと解釈された場合は、定形的メッセージデータベース５１０から当該定形的メッセージに対応づけて記録されたアクションフローを読み出すことで速かに対応することができる。
【００３９】
本発明が属する技術分野で通常の知識を持つ者は、図７に示された定形的メッセージデータベースは一つの実施例に過ぎないし、これに対する多様な変形や代案が存在することを認識することができる。定形的メッセージ データベース５１０は使用者又は事業体別に、又は、全ての使用者に対して統一して構築されることができることに注意する。この中でどんな方式と内容を選択することが望ましいかは、業種や業務の内容により変わることができるし、使用者の便宜性、システムの効率性等を考慮してシステム設計者が選択できる事項である。他の実施例では、一つの定形的メッセージに対応するアクションフローが複数個存在することもできる。このような実施例では、使用者の選択にしたがって、または、後述する特性情報データベース５５０に記録された特性情報を参照して複数のアクションフローの中で最も適合したアクションフローを選別することができる。
【００４０】
図８は、レストラン用システムの実施例に関する定形的メッセージデータベース５１０’を図示する。例えば、予約はレストランで非常に日常的に、且つ頻繁に要求される業務の一つであり、予約のための必須情報は予約日、予約時間、及び予約人数に限定されるので、上記業務に対する要請は定形化が可能である。図示のように、『新規予約』という定形的メッセージは『予約』という命令語と、日付、時間及び人数というエンティティを含む構造を持つ。例えば、図４の使用者メッセージiが『２０１２／０７／０１、６時、３人予約』であれば、使用者メッセージ解釈モジュール２０６は上記使用者メッセージが『予約』という命令語と、日付『２０１２／０７／０１』、時間『６時』、人数『３人』というエンティティを含むと解釈し、これを定形的メッセージデータベース５１０に記録された定形的メッセージの構造と比較する。これによって、上記使用者メッセージiが『新規予約』という定形的メッセージに該当すると判断することができる。従って、定形的メッセージデータベース５１０’で上記定形的メッセージに対応づけて記録されたアクションフローである『テーブル照会（予約を要請した日と時間に当該人数を収容できる空きテーブルがあるのかを照会）＋新規予約登録（予約情報を記録）＋携帯電話メッセージ（決まった受信者に予約完了を通知）』を読み出すことで、上記使用者メッセージに対するアクションフローを容易に生成することができる。上記三つのエンティティは上記アクションフローの遂行のために実行されるアプリケーションの入力データとして使われる。この場合、上記使用者メッセージが『今日６時３人予約』と記載されている場合にも『今日』という単語が、例えば『２０１２／０７／０１』という日付と解釈されることができるので、上記のような定形的メッセージとして処理できることは勿論である。
【００４１】
次に、 図９乃至図１３を参照して、本発明の一実施例による非定型的メッセージの処理に関して説明する。図９乃至図１１のそれぞれは、本発明の一実施例によるアクション要求同義語データベース５２０、対応作業データベース５３０、及び対応作業−アクションデータベース５４０を図示する。図１２は非定型的メッセージに対し生成されたコンポーネント別候補アクション目録の一実施例を図示する。図１３は特性情報データベース５５０の一実施例を図示する。
【００４２】
アクション要求同義語データベース５２０は、使用者メッセージによって遂行されるように要求された業務を構成する一つ又はそれ以上のアクション要求に対し一つ又はそれ以上の同義語を対応付けて記録する。本明細書で、所定のアプリケーション又はその一部によって遂行される作業やオペレーションを指し示すために使用者がしばしば使う代表的な命令語や単語をアクション要求と呼ぶ。上記アクション要求の同義語は使用者によって、又は、関連業界でアクション要求と同一又は類似の意味として実際よく使われていたり、使われる可能性がある単語である。次に、要求対応作業データベース５３０は、使用者メッセージが内包する使用者の要求を充足させるために遂行されるべき一つ又はそれ以上の対応作業を上記アクション要求の各々に対応づけて記録する。また、対応作業−アクションデータベース５４０は、それぞれの対応作業の遂行に必要な一つ又はそれ以上のアクションを上記対応作業の各々に対応づけて記録する。ここで、アクション要求同義語データベース５２０の上記アクション要求ＲＥＱ０１、ＲＥＱ０２、ＲＥＱ０３、ＲＥＱ０４と上記アクション要求同義語ＳＹＮ１１、ＳＹＮ１２等はシステム設計者、システム管理者、又は、使用者等によって選別されたものであり、事前に入力されたり非定型的メッセージの処理の際にリアルタイムで入力されることもできる。これは対応作業データベース５３０及び対応作業−アクションデータベース５４０に対しても同様である。
【００４３】
以下では、非定型的メッセージである使用者メッセージｊ（図４参照）に対し図１２に図示されたコンポーネント別候補アクション目録を生成する過程を説明する。図示のように、本実施例によれば上記使用者メッセージｊは二つのエンティティと二つの命令語とを含む。上記コンポーネントの中でＥＮＴｊ１とＥＮＴｊ２はその意味が明確に特定されるエンティティであると仮定する。この場合、コンポーネントＥＮＴｊ１とＥＮＴｊ２に対してはアクション要求を特定する必要がない。もしエンティティが何を示すのか不明確な場合には、このエンティティを明確に定義するためにこれに対するアクション要求を特定することができる。例えば、レストラン用システムの例で、『今日午後６時５人予約』という使用者メッセージが入力された場合、そのコンポーネントの中で『今日』、『午後６時』及び『５人』はエンティティに該当し、『予約』は命令語に該当する。上記エンティティの中で『今日』の意味が明確でなければ、『今日』が示す日付を明確に特定するためにアクション要求同義語データベース５２０を参照することができる。例えば、上記エンティティに対して『日付照会』というアクション要求が特定されることができる。一方、使用者メッセージに『それ』とか『その人』のような代名詞が含まれてエンティティを規定できない場合には、談話分析（ｄｉｓｃｏｕｒｓｅ  ａｎａｌｙｓｉｓ）が使われることもできる。『予約』という命令語に対してはアクション要求同義語データベース５２０を参照して、それに対応するアクション要求を特定する。
【００４４】
上記使用者メッセージjの二つの命令語ＣＯＭＭｊ１とＣＯＭＭｊ２とに対するアクション要求を特定するために、非定型的メッセージ処理モジュール３０４はアクション要求同義語データベース５２０を参照する。参照結果、命令語ＣＯＭＭｊ１は同義語ＳＹＮ１１とＳＹＮ２１に該当すると判断されたので、上記命令語ＣＯＭＭｊ１に対してはアクション要求ＲＥＱ０１とＲＥＱ０２を対応させる。命令語ＣＯＭＭｊ２は同義語ＳＹＮ３１に該当するので、上記命令語に対してはアクション要求ＲＥＱ０３が対応される。このように、アクション要求同義語データベース５２０を参照することによって、使用者メッセージの各コンポーネントに対しアクション要求を特定することができる。一方、アクション要求を特定するためにアクション要求同義語データベース５２０を必ず利用すべきことではないし、上記のように、アクション要求やその同義語がリアルタイムで入力されることもできる。この場合、非定型的メッセージ処理モジュール３０４は使用者又はシステム管理者等にインターフェースを提供して使用者やシステム管理者等がこれを決めるようにすることができる。または、非定型的メッセージ処理モジュール３０４はインターネット検索等を通して使用者メッセージの各コンポーネントに対応するアクション要求を究明することもできる。または、非定型的メッセージ処理モジュール３０４は、使用者にアクション要求を選択させたり、追加的な説明をさせるための質問メッセージを使用者に伝送するようにすることもできる。
【００４５】
次に、非定型的メッセージ処理モジュール３０４は上記各コンポーネントに対し特定されたそれぞれのアクション要求に対応する対応作業を選別するために、対応作業データベース５３０を参照する。図１０の実施例で、ＲＥＱ０１、ＲＥＱ０２とＲＥＱ０３の各々に対応する対応作業は複数個存在する。この中でより適合した対応作業を選別するために特性情報データベース５５０を参照したり、システム管理者や使用者等に直接対応作業を選択させたりすることができる。本実施例で、コンポーネントＣＯＭＭｊ１に対しては対応作業ＪＯＢ１１とＪＯＢ２１が、コンポーネントＣＯＭＭｊ２に対しては対応作業ＪＯＢ３１が選別される。一方、本実施例では、一つのアクション要求に対し一つの対応作業が選別されたが、複数の対応作業を選別することも可能である。
【００４６】
次に、非定型的メッセージ処理モジュール３０４は対応作業−アクションデータベース５４０を参照して、上記選別された対応作業の各々に対して最も適合したアクションを選別する。上記選別は特性情報データベース５５０を参照して行われたり、システム管理者や使用者等に直接選択させることができる。図１２の実施例では、コンポーネントＣＯＭＭｊ１に対し選別された対応作業ＪＯＢ１１とＪＯＢ２１の各々に対応して記録されたアクションの中で、より適合したアクションとしてＡＣＴ１１１とＡＣＴ１１２、ＡＣＴ２１１とＡＣＴ２１２が各々選別される。上記コンポーネントＣＯＭＭｊ２に対しては、ＡＣＴ３１１、ＡＣＴ３１２とＡＣＴ３１３が選別される。このように、使用者メッセージｊに対して図１２に図示されたコンポーネント別候補アクション目録を生成することができる。
【００４７】
アクション要求同義語データベース５２０、対応作業データベース５３０、対応作業−アクションデータベース５４０及び／又は、特性情報データベース５５０はシステム設計者、システム管理者、又は使用者等によって事前に又はリアルタイムで生成、追加、削除されることができる。また、上記データベースの全てが常に本発明のソフトウェア実行制御システム１００の内部に含まれるべきことではない。それだけではなく、上記データベースの中で少なくとも一部はシステム設計者、システム管理者又は使用者等によるリアルタイム指定又は入力方式などに代替されることもできる。
【００４８】
上記実施例はアクション要求からアクションを究明するために二つのデータベース５３０と５４０を使ったが、他の実施例では、一個のデータベース、即ち、アクション要求−アクションデータベースを利用することができる。即ち、アクション要求とアクションを直接対応づけて記録しておくことによって、各アクション要求に対するアクションを特定するために必要なプロセスを減らすことができる。この実施例でもアクション要求−アクションデータベースはシステム設計者、システム管理者、又は使用者等によって事前に又はリアルタイムで生成、追加、削除されることができる。上記データベースは常に本発明のソフトウェア実行制御システム１００の内部に含まれるべきことではないし、使用者又はシステム設計者やシステム管理者等によるリアルタイム指定又は入力方式等に代替されることもできる。
【００４９】
アクションを特定するために二つのデータベース、即ち、対応作業データベース５３０と対応作業−アクションデータベース５４０とを使う実施例は、一つのデータベースだけを使う実施例に比べてプロセシングが増加し、従って処理時間がもっと長くなりうる。しかし、上記二つのデータベースを使う場合、使用者の要求にもっと適合したアクションを選別する可能性が高くなるという利点がある。
【００５０】
もしコンポーネントに対応するアクションを特定できない場合には、実施例によって、ｉ）使用者メッセージを処理できないと判断してソフトウェア実行制御装置１００の動作を終了したり、又は、ｉｉ）過去に当該又は他の使用者が同一又は類似のメッセージを処理するためにアプリケーションを実行させた履歴（ｈｉｓｔｏｒｙ）情報を参照したり、ｉｉｉ）ウェブ検索等を通して収集された情報等を活用したりすることもできる。この場合の処理方式は、使用者の便宜性、システムの効率性等を考慮してシステム設計者が選択することができる。 
【００５１】
次に、図１３を参照して、特性情報データベース５５０に関して詳細に説明する。図示のように、特性情報データベース５５０は使用者別に多様な特性情報と各特性に関連した選択肢の加重値を対応づけて記録する。実施例によっては、各選択肢別に加重値を保存する代わりに、選択肢の相互間の優先順位だけを保存することもできる。複数の選択肢に対する加重値又は優先順位は、ｉ ）使用者、システム管理者又はシステム設計者等によって設定されたり、ｉｉ）過去の非定型的メッセージ処理に関する履歴情報を参照して決定されたり、ｉｉｉ）各選択肢の属性によって決定されたりすることができる。各特性の選択肢を選別するとき、それぞれの選択肢別に加重値又は優先順位が最も高いことだけを一つずつ選別して行くことも可能であり、特性別選択肢の組合の中で最も適合したものを選択するのも可能である。例えば、前者の場合において、非定型的メッセージのコンポーネント別に特定されたアクション要求に対して加重値が最も高い一つの対応作業を選別し、上記選別された対応作業に対して加重値が最も高い一つのアクションを選別する。後者の場合には、コンポーネント別に選別されたそれぞれの対応作業に対応するアクションの中で加重値が高い順に複数を選別し、選別されたアクションの組合の中で最も適合した一つ又は複数を選別する実施例が可能である。他の組合が可能であることは勿論である。特に、それぞれの組合に含まれた選択肢の加重値の合計又は積を求めて、その値が大きい順に一つ又はそれ以上の組合を選択することも可能である。
【００５２】
選択肢の属性によって加重値又は優先順位を決める場合において、一つのアクションに対応するアプリケーションの加重値又は優先順位を決める方法は、例えば、次のようなものがある。
【表１】
2014026367.tif 000003
上記表１に羅列された属性は例示にすぎないし、アプリケーションの優先度を決めるために上記属性の一部又は全てが異なる属性と一緒に使われる事もでき、全然異なる属性が使われることもできる。参照情報運用モジュール５９０は、随時又は定期に特性情報データベース５５０に記録された情報の変動事項に関する情報を収集し、収集された情報にもとづいて特性情報データベース５５０を更新することが望ましい。
【００５３】
以下ではレストラン分野の仮想事例を通じて非定型的メッセージからアクションを究明する過程を説明する。例えば、『午前１１時スタッフミーティングを１２時に遅らせる』という内容の使用者メッセージが入力された場合を仮定する。使用者メッセージ前処理部２００は上記使用者メッセージを受信した後、受信されたメッセージを構造化する。上記使用者メッセージ前処理部２００によって構造化された使用者メッセージのコンポーネントは『午前１１時』、『スタッフミーティング』及び『１２時』等の内容を持つ三つのエンティティと、『遅らせる』の内容を持つ一つの命令語に分類される。非定型的メッセージ処理モジュール３０４は、命令語コンポーネントである『遅らせる』に対応するアクションを究明するために、アクション要求同義語データベース５２０と、対応作業データベース５３０と、対応作業−アクションデータベース５４０とを参照して上記命令語『遅らせる』に対し最も適合したアクションを選別する。上記命令語に対し選別されたアクション要求、対応作業及びアクションは、次の表２に例示される。
【表２】
2014026367.tif 000004
すなわち、上記表２の例によれば、『遅らせる』という命令語に対しては『一定時間変更』、『電子メールで連絡』及び『携帯電話メッセージで連絡』のような三種類のアクションが選別されることができる。このように選別された三種類のアクションの全てを順次、又は、並列に実行することができる。本発明の他の実施例によれば、特性情報データベース５５０を参照して上記選別されたアクションの中で最も加重値が高いものを選別することによって、上記使用者メッセージに対する一つのアクションだけを究明することもできる。または、それぞれの対応作業に対して加重値が高いアクションを一つずつ選別することによって、二つのアクションを選別することも可能である。例えば、『遅らせる』というコンポーネントに対して、(日程時間変更＋電子メール)又は（日程時間変更＋携帯電話メッセージ）のアクションフローが生成されることができる。
【００５４】
次に、図１４を参照して非定型的メッセージのアクションフローを生成する方法に関して説明する。非定型的メッセージ処理モジュール３０４は、図１２のコンポーネント別候補アクション目録においてそれぞれのコンポーネントに対応するアクションを組み合わせたアクションフローを生成する。ＣＯＭＭｊ１に対して究明された複数のアクションと、ＣＯＭＭｊ２に対して究明されたそれぞれのアクションを組み合わせれば図１４のように複数のアクションフロー候補目録が生成される。本実施例では総１2個のアクションフロー候補が存在する。これらの中でより適合したアクションフローを選別するために、図１４の実施例はアクションフローを構成する各アクションの加重値をかけて、加重値の積の値が最も高い二つのアクションフローＰ１とＰ２を選別する。他の実施例では、加重値又は優先順位が最も高いアクションで構成された一つのアクションフローを選択する。また他の実施例では、コンポーネントＣＯＭＭｊ１に対して特定された二つの対応作業の各々に対しアクションを選別し、選別された二つのアクションをＣＯＭＭｊ２に対して選別されたアクションと組み合わせて（例えば、ＡＣＴ１１１＋ＡＣＴ２１１＋ＡＣＴ３１１）アクションフローを選別することも可能である。このように生成されたアクションフローは、使用者別に又は生成された順序により、キャッシュメモリー、バッファー、キュー等に保存され、保存された順に処理されたり、又は、緊急性があるアクションフローから先に処理される。他の順序で処理されることもできることは勿論である。
【００５５】
次に、図１５に図示された本発明の一実施例によるアクション−アプリデータベース５６０に関して説明する。アクション−アプリデータベース５６０は、各アクションの識別情報と、当該アクションを遂行するために必要なアプリケーションの識別情報を対応づけて記録する。上記アプリケーションの識別情報は各アプリケーションが保存されたフォルダ情報又はＵＲＬ等の位置情報を含む。アプリ選別モジュール４０２は、アクション−アプリデータベース５６０を参照してアクションフローを構成するそれぞれのアクションに対するアプリケーションを決める。一つのアクションに複数個のアプリケーションが対応した場合には、特性情報データベース５５０を参照してアプリケーションを選別したり、システム設計者、システム管理者、使用者等によって選択するようにすることも可能である。参照情報運用モジュール５９０はアクション−アプリデータベース５６０に記録されたアクションを追加、変更、又は削除する。例えば、システムの設計の時に予想できなかった新しいアクションが必要になる場合は、アクション−アプリデータベース５６０に新規アクションを追加する。このために、システム設計者、システム管理者、アプリケーション開発者、又は適合した権限を持つ使用者が新規アクションと、これを遂行するために必要なアプリケーションに関する識別情報であるアプリケーション識別情報とを直接入力するようにインターフェースを提供することができる。新規アクションが追加された場合に、参照情報運用モジュール５９０が上記新規アクションを遂行するために必要なアプリケーションを探索し、探索されたアプリケーション識別情報をアクション−アプリデータベース５６０に記録することができる。
【００５６】
図１６を参照して、アクションフローを構成するアクションの遂行に必要なアプリケーションを特定する方法に関して説明する。図１６の実施例で、使用者１のアクションフローＦ１はアクションＡＣＴ２１とＡＣＴ２４とを含む。アプリ選別モジュール４０２は先にＡＣＴ２１に対応するアプリケーションを決めるために、アクション−アプリデータベース５６０を参照する。ＡＣＴ２１に対応するアプリケーションが複数個存在するので、使用者１の特性情報データベース５５０ａからアクションＡＣＴ２１に対応するアプリケーションであるＡＰＰ２１１、ＡＰＰ２１２、及びＡＰＰ２１３の中で最も加重値が高いＡＰＰ２１１を選定する。アクションＡＣＴ２４に対しても同じ方法で、アプリケーションＡＰＰ２４２を選定する。本発明の他の実施例によれば、アプリ選別モジュール４０２は、それぞれのアクションに必要なアプリケーションをソフトウェア実行制御装置１００の内部の記憶装置１０６又は外部サーバー（図１の１５０ａ及び１５０ｂ）等で検索して選定することができる。これは特定のアクションに対応するアプリケーションの情報がアクション−アプリデータベース５６０に存在しない場合、又はアプリケーションの情報がアクション−アプリデータベース５６０に存在するがその有効性が確実ではない場合等に対応するために遂行されることができる。特定アクションの遂行に必要な新たなアプリケーションが検索された場合には、参照情報運用モジュール５９０に上記新たなアプリケーションの識別情報をアクション−アプリデータベース５６０に追加させることが望ましい。
【００５７】
次に、図１７及び図１８を参照して、アプリ実行制御モジュール４０４の動作に関して説明する。アプリ実行制御モジュール４０４はアプリケーションの実行を制御するために図１７に図示されたアプリプロシージャデータベース５７０を参照することができる。即ち、アプリ実行制御モジュール４０４はアプリプロシージャデータベース５７０から実行させるべきアプリケーションのプロシージャに関する情報を抽出し、これを参照して当該アプリケーションを実行するために必要な制御信号を生成する。例えば、連絡先管理アプリケーションであるＡＰＰ２１１のプロシージャは使用者認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）、名前入力（ｉｎｐｕｔ  Ｎａｍｅ）、電話番号検索（Ｐｈｏｎｅ＿ｎｏ  ｓｅａｒｃｈ）、検索された電話番号の出力（ｏｕｔｐｕｔ  Ｐｈｏｎｅ＿ｎｏ）として指定されている。アプリ実行制御モジュール４０４はＡＰＰ２１１を実行させるべき場合、上記プロシージャに必要な制御信号を生成してＡＰＰ２１１に提供する。また、アプリ実行制御モジュール４０４は実行されるべきそれぞれのアプリケーションの入力データのタイプとフォーマットを確認する。このため、上記のように、アプリケーション別に入力データのタイプとフォーマットを記録したアプリ実行情報データベース５８０を予め構築しておくことが望ましい。図１８にアプリ実行情報データベース５８０の一実施例が図示されている。もしアプリケーションに入力されるべきデータのタイプ及びフォーマットが、当該アプリケーションの入力データタイプ及びフォーマットと一致すれば、上記データをそのままアプリケーションに入力してアプリケーションを実行させることができる。もしアプリケーションに入力されるべきデータのタイプ及びフォーマットが、当該アプリケーションの入力データタイプ及びフォーマットと一致しなければ、上記データのタイプ及びフォーマットを当該アプリケーションの入力データタイプ及びフォーマットに合わせて変換する。
【００５８】
上記実行されるべきアプリケーションには、上記使用者メッセージに含まれたエンティティをその入力データとして提供することができる。または、先に実行された他のアプリケーションの出力データを当該アプリケーションの入力データとして提供する場合もある。この場合には、上記先に実行されたアプリケーションの出力データを当該アプリケーションが必要とするデータのタイプとフォーマットに従って変換する必要がある。
【００５９】
本発明の他の実施例によれば、上記アプリ実行制御モジュール４０４は、アプリ選別モジュール４０２によって選別されたアプリケーションをそのまま実行させることが適していない場合、又は、これを変形させることがより一層適合すると判断される場合、上記アプリケーションを修正して実行させることもできる。例えば、特定のアプリケーションの実行のために必要なデータの個数、タイプ又はフォーマットや、当該アプリケーションの実行の結果産出されるデータの個数、タイプ又はフォーマットや、又は当該アプリケーションに含まれたプロシージャの一部又は全てを変形することもできる。
【００６０】
上記アプリプロシージャデータベース５７０と、アプリ実行情報データベース５８０は、事前に及び／又はリアルタイムで、システム設計者、システム管理者及び／又は使用者等によって構築されたり、更新されたりすることができる。このため、参照情報運用モジュール５９０は必要なユーザインタフェースを生成して提供することができる。また、参照情報運用モジュール５９０は、随時又は定期にソフトウェア実行制御システム１００の内部又は外部から収集した情報を分類し、この情報をアプリプロシージャデータベース５７０とアプリ実行情報データベース５８０に記録することもできる。
【００６１】
次に、図１８を参照して、本発明の一実施例によるアプリケーション実行プロセスにおいてアプリケーション間の入力及び出力データの関係を説明する。上記のように、実行されるべきアプリケーションの入力データが、それより先に実行された他のアプリケーションの出力データである場合がある。図１８の左側に図示されたように、アプリ選別モジュール４０２によって使用者メッセージｋに対して実行させるべきアプリケーションＡＰＰ３１１とＡＰＰ２１１が特定されれば、アプリ実行制御モジュール４０４は先にＡＰＰ３１１を実行させる。このためにＡＰＰ３１１に規定されたタイプとフォーマットの入力データｉｎ０１とｉｎ０２とを入力する。また、ＡＰＰ３１１の実行が完了すると、ＡＰＰ２１１を実行させる。図示のように、アプリケーションＡＰＰ２１１の入力データとしてはアプリケーションＡＰＰ３１１の出力データが提供される。この場合、アプリ実行制御モジュール４０４はＡＰＰ３１１の出力データｏｕｔ０１のタイプとフォーマットをＡＰＰ２１１の入力データのタイプとフォーマットに一致させる。ここで、ＡＰＰ２１１の入力データのフィールド名とＡＰＰ３１１の出力データのフィールド名は、互いに異なることができる。ＡＰＰ２１１の入力データのタイプとフォーマットに従って変換されたＡＰＰ３１１の出力データｏｕｔ０１はＡＰＰ２１１に入力データとして提供される。アプリ実行制御モジュール４０４は、アプリプロシージャデータベース５７０を参照してＡＰＰ３１１とＡＰＰ２１１の制御信号を生成することによってＡＰＰ３１１とＡＰＰ２１１の実行を制御する。
【００６２】
上記のようなアプリケーション間の相互関係はデータベースとして構築されて使われることができる。上記例のように、特定アプリケーションの出力データと、異なるアプリケーションの入力データがお互いに関連した場合、この情報を予めデータベースに記録しておけばアプリケーションの実行制御が非常に容易になる。また、二つ以上のアプリケーションが共有しなければならないデータがあることを意味する情報を予めデータベースとして構築しておくことも望ましい。例えば、上記レストラン用システムの例で、金銭登録（ｃａｓｈ  ｒｅｇｉｓｔｅｒ）アプリケーションが保有した売り上げデータを、売り上げ管理アプリケーションが共有することが望ましい。これによって、売り上げデータはメモリーに重複して保存される必要がないので、メモリーの保存空間を節約することができる。
【００６３】
本発明のソフトウェア実行制御装置１００の構成要素２００乃至５００と、上記構成要素の各々に含まれたモジュールの構成は、上記実施例と異なることができる。例えば、使用者メッセージ前処理部２００に含まれたモジュール２０２乃至２０６は独立的な部（ｕｎｉｔ）として構成されることができるし、又は、モジュール２０２乃至２０６が一つのモジュールとして統合されることもできる。本発明が属する技術分野で通常の知識を持つ者は他の変形や代案が存在することを認識するはずだ。
【００６４】
以上、ソフトウェア実行制御装置とソフトウェア実行制御方法の実施例を通じて本発明を説明したが、本発明の技術思想はソフトウェア実行制御プログラムを記録したコンピュータで読むことができる記録媒体として具現されることもできる。上記ソフトウェア実行制御プログラムはコンピュータを、使用者から受信した使用者メッセージを構造化して解釈する使用者メッセージ前処理部と、上記使用者メッセージから抽出したコンポーネントからアクションフローを生成するメッセージ処理部と、上記アクションフローを構成するアクションを遂行するためのアプリケーションを選別して上記選別されたアプリケーションの実行を制御するアプリ実行部と、各種データベースを構築して運用する参照情報管理部として動作させる。本発明のソフトウェア実行制御プログラムの動作は上記のソフトウェア実行制御方法の各段階に対応するので、それに関する詳細な説明は省略する。
【００６５】
以下では、レストランの予約及び注文管理に適用された本発明の他の実施例に関して説明する。図１９は本発明の一実施例によるレストラン予約及び注文管理システムを概念的に示す図面である。レストラン用ソフトウェア実行制御装置３０１０は、使用者メッセージ前処理部と、使用者メッセージ処理部と、アプリ実行部と、参照情報管理部（図示されない）とを含んでおり、これらはそれぞれ図２に図示された実施例の使用者メッセージ前処理部２００、使用者メッセージ処理部３００、アプリ実行部４００と参照情報管理部５００に対応する。従って、これらの構成に関する詳細な説明は省略する。ＰＯＳ端末、パソコン、又はタブレット等のレストラン用ソフトウェア実行制御装置３０１０は、店主や顧客等から予約を要請する使用者メッセージを携帯電話メッセージや電子メールの形態で受ける。顧客が店主に予約を要請する携帯電話メッセージや電子メールを送れば、自動的にレストラン用ソフトウェア実行制御装置３０１０に伝えられるようにしても良い。
【００６６】
上記携帯電話メッセージや電子メールは定形的メッセージ又は非定型的メッセージである。レストラン用ソフトウェア実行制御装置３０１０は当該使用者メッセージが受信されると、これを構造化して定形的メッセージであるかどうかを判断する。もし上記使用者メッセージが定形的メッセージであれば、上記定形的メッセージ処理モジュール３０２は、定形的メッセージデータベース５１０を参照して当該メッセージに対応するアクションフローを読出、生成する。もし上記使用者メッセージが非定型的メッセージであれば、上記非定型的メッセージ処理モジュール３０４は、上記アクション要求同義語データベース５２０を参照して上記メッセージに対応するアクション要求を選別して、上記対応作業データベース５３０を参照して選別された各アクション要求に対して適合した対応作業を指定し、上記対応作業−アクションデータベース５４０を参照して適合したアクションフローを生成する。次に、このように生成されたアクションフローに対して上記アプリ選別モジュール４０２は、適合したアプリケーションを選別し、上記アプリ実行制御モジュール４０４は上記アクション−アプリデータベース５６０、アプリプロシージャデータベース５７０、アプリ実行情報データベース５８０の全て又は一部を参照して上記選別されたアプリケーションを実行させる。
【００６７】
具体的な例で、上記受信者メッセージに含まれた予約日、予約時間、人数等の情報によりテーブルを予約し、顧客名を含む顧客識別情報に基づいて当該顧客がよく注文する食べ物や飲み物に関する情報を上記特性情報データベース５５０から読み出して、読み出された情報に基づいて上記食べ物や飲み物の在庫を確認した後、在庫がない場合、購買の要請をする。もし、顧客の名前が使用者メッセージに含まれていなければ、店主に顧客名を問い合わせするようにすることができる。
【００６８】
次に、注文要請を処理する実施例に関して説明する。図示のように、レストラン予約及び注文管理システム３０００は有線又は無線で連結されたレストラン用ソフトウェア実行制御装置３０１０と、一つ又はそれ以上の顧客用タブレット３０２０と、一つ又はそれ以上の台所用タブレット３０３０と、一つ又はそれ以上のスタッフ用タブレット（図示されない）を含む。顧客用タブレット３０２０、台所用タブレット３０３０又はスタッフ用タブレット（図示されない）が複数個ある場合、各々は固有識別情報によって区別される。レストラン用ソフトウェア実行制御装置３０１０は注文情報管理アプリケーション、待機時間計算アプリケーション等を含んでおり、上記アプリケーションはレストラン用ソフトウェア実行制御装置３０１０の内部のメモリー又はスマートカード、コンパクトディスク等の記憶装置に記録されることができる。売り場内の各テーブルに配置された顧客用タブレット３０２０は注文要請アプリケーション、注文情報表示アプリケーション等を含む。台所に配置された台所用タブレット３０３０は料理プロセス管理アプリケーション等を含む。上記アプリケーションはレストラン用ソフトウェア実行制御装置３０１０、顧客用タブレット３０２０又は台所用タブレット３０３０に保存されることもできるし、外部サーバーに保存されることもできる。上記アプリケーションはウェブサービスも可能であることに注意する。
【００６９】
例えば、上記本発明のレストラン用ソフトウェア実行制御装置３０１０と接続された複数の顧客用タブレット３０２０の各々から注文情報、テーブル識別情報、顧客識別情報等を含む使用者メッセージが入力されれば、上記ソフトウェア実行制御装置３０１０は上記の過程を経て上記使用者メッセージに対応するアクションフローを生成し、選別されたアプリケーションを実行させる。それぞれの顧客用タブレット３０２０はディスプレイ及び注文情報を入力受けることができる入力部を含んでおり、サービスされるメニュー項目と注文要請アイコンとをディスプレイに表示する。顧客がテーブルに配置された顧客用タブレット３０２０に表示されたメニュー項目の中で注文したい項目を選択し、注文アイコンをクリック又はタッチすれば、上記入力部がこの情報を受信する。メニュー項目の選択や注文要請はマウスやタッチパッドを通じて入力されることもできるし、音声命令の形態も可能である。また、上記注文要請アプリケーションは顧客から名前を入力受ける等の方法で当該顧客の識別情報を取得したり、当該顧客が事前に予約をした場合には予約情報を参照して顧客識別情報を取得する。上記注文要請アプリケーションは顧客用タブレット３０２０の識別情報、上記入力部によって受信されたメニュー項目に関する情報及び顧客識別情報をレストラン用ソフトウェア実行制御装置３０１０へ送信する。レストラン用ソフトウェア実行制御装置３０１０は、注文という内容のデータと共に、顧客用タブレット３０２０の固有識別情報、選択されたメニュー項目、顧客識別情報等のデータを使用者メッセージとして受信する。
【００７０】
レストラン用ソフトウェア実行制御装置３０１０は、上記顧客識別情報に基づいて上記特性情報データベース５５０から食事性向（例えば、早いサービング、順次にサービング、余裕のあるサービング等）、好む味（例えば、塩辛い、普通、水っぽい等）等の情報を読み出す。顧客情報が保存されていなかった場合、店長又は担当ウェイターに、顧客との相談を行わせた後、カウンター又は別の場所に設置されたスタッフ用タブレット（図示されない）を使って関連情報を入力させることができる。レストラン用ソフトウェア実行制御装置３０１０は上記読み出された情報に基づいて複数の顧客用タブレット３０２０から注文されたメニュー項目の調理順序を定めて台所用タブレット３０３０に伝達する。例えば、早いサービングを選り好みする顧客が注文した料理が、余裕のあるサービングを選り好みする顧客が注文した料理より先に調理されるように、調理順序を調整することができる。台所用タブレット３０３０は注文されたメニュー項目の調理過程を所定の段階に分けて、実際料理進行状況によってどんな段階に進入したという情報を調理師に入力するようにして、この情報をレストラン用ソフトウェア実行制御装置３０１０へ送信する。レストラン用ソフトウェア実行制御装置３０１０は調理待機時間又は調理完了情報を顧客用タブレット３０２０へ伝送して、これを顧客が閲覧することができるようにする。
【００７１】
その他、本発明は上述した実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、上述した実施形態で実行される機能は可能な限り適宜組み合わせて実施しても良い。上述した実施形態には種々の段階が含まれており、開示される複数の構成要件による適宜の組み合せにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、効果が得られるのであれば、この構成要件が削除された構成が発明として抽出され得る。
【図１】
2014026367.tif 000005
【図２】
2014026367.tif 000006
【図３】
2014026367.tif 000007
【図４】
2014026367.tif 000008
【図５】
2014026367.tif 000009
【図６】
2014026367.tif 000010
【図７】
2014026367.tif 000011
【図８】
2014026367.tif 000012
【図９】
2014026367.tif 000013
【図１０】
2014026367.tif 000014
【図１１】
2014026367.tif 000015
【図１２】
2014026367.tif 000016
【図１３】
2014026367.tif 000017
【図１４】
2014026367.tif 000018
【図１５】
2014026367.tif 000019
【図１６】
2014026367.tif 000020
【図１７】
2014026367.tif 000021
【図１８】
2014026367.tif 000022
【図１９】
2014026367.tif 000023