JP2006178658A - 情報処理方法及びプログラム - Google Patents

Abstract

【課題】
ネットワーク・サービスの柔軟且つ迅速な提供を可能にする。
【解決手段】
本発明ではサービス提供ネットワーク5によりネットワーク・プラットフォームNP50を実現する。このNP50は、認証・認可、課金、クライアント(CT)管理といった共通機能と、セッション制御等の個別機能がオープンネットワーク1に接続されるCTに提供する。CTは、サービス管理インタフェースSMIを介してNPにおける機能を利用するためのサービスプログラムを作成/登録する。サービスプログラムを実行すると、サービス制御インタフェースSCIを介して特定の機能に対するサービス要求をNP50に送信すると共に、NP50の特定の機能から実行結果を取得する。サービスプログラムの実行主体及び保管主体は、初期段階においてトリガの検出主体等に基づき決定され、さらにCTにおいて実際に実行する際には処理能力の余裕等を考慮してNPに実行を委託する場合もある。
【選択図】図１

Description

本発明は、ネットワークサービスの提供技術に関する。

インターネットに接続されているサーバ上に用意されたアプリケーションを、複数のユーザに使用させるサービスが存在している。このようなサービスにおいて、サーバ上のプログラムの組み合わせ方（ユーザ側から見れば使い方）はサービスの提供者により予め決められており、ユーザは、サーバ上の複数のプログラムを自由に組み合わせて使用することはできない。

さらに、特開２００２−１８２９３７号公報には、クライアント端末とサーバとの間で少ないデータ量でもってダウンロードでき、所望のデータ処理を実行できるようにするための技術が開示されている。具体的には、クライアント端末で定義情報を入力し、サーバで設定情報を定義情報に対応して読み出してクライアント端末に送信し、設定情報に基づいて１又は複数の機能部品を呼び出す。機能部品は複数のデータ処理を共通の単位処理に分割しそこから抽出した処理ロジックを記述したものであって、クライアント端末又は処理サーバで１又は複数の機能部品に基づく処理ロジックによって単位処理プログラムを動的に生成し、生成された１又は複数の単位処理プログラムを設定情報に基づく条件に従って実行する。この技術では、単位処理プログラムの認可といった観点は存在していない。また、単位処理プログラムを複数種類実行する場合における問題などについては触れられていない。さらに、単位処理プログラムの実行主体及び保管主体についての考察もなされていない。
特開２００２−１８２９３７号公報

上で述べたような従来技術には、クライアント側でサーバ側に用意された任意の機能を組み合わせ、クライアント側でネットワークを介して機能の組み合わせにより実現される特定のサービスの提供を受ける際に、サービス提供の可否を判断したり、複数の組み合わせを識別したりすることについては考慮されていない。さらに、機能の組み合わせにより実現される特定のサービスの提供を受けるために規定されるプログラム（例えば上で述べた単位処理プログラム）の実行主体及び保管主体を固定すると、柔軟性の問題やサービス提供の迅速性の問題などが発生するが、このような問題についての検討はなされていない。従って、従来技術では、ネットワーク・サービスの柔軟且つ迅速な提供に問題がある。

従って、本発明の目的は、ネットワーク・サービスの柔軟且つ迅速な提供を可能にするための新規な技術を提供することである。

本発明の第１の態様に係る情報処理方法は、ネットワーク・プラットフォーム側で提供される機能のうちクライアントによって利用される機能の組み合わせが定義されているサービスプログラムに関する情報処理方法であって、サービスプログラムを解析して、サービスプログラムを起動させるトリガの検出がクライアント端末であるかネットワーク・プラットフォーム側であるか判断するステップと、サービスプログラムを起動させるトリガの検出がクライアント端末であると判断された場合、サービスプログラムとクライアント端末との関係に関する条件が満たされているか判断するステップと、条件が満たされていると判断された場合には、サービスプログラムの実行主体をクライアント端末として決定するステップとを含む。

このようにサービスプログラムの実行主体は、基本的にはトリガの検出主体とするが、クライアント端末がトリガの検出主体である場合には、サービスプログラムとクライアント端末との関係から実行主体が決定される。このようにサービスプログラムの実行主体を決定することにより、ネットワーク・サービスの柔軟且つ迅速な提供が可能となる。

例えば、上で述べた条件は、サービスプログラムにおいて単一のクライアント端末に関連する処理が規定されているという条件を含むようにしてもよい。例えば、単一のクライアント端末に関連する場合にはクライアント端末を実行主体とし、複数のクライアント端末に関連する場合にはネットワーク・プラットフォームを実行主体とするものである。

また、例えば上で述べた条件が、サービスプログラムがクライアント端末に生じさせる処理負荷と当該クライアント端末の処理能力との関係についての条件を含むようにしてもよい。例えば、クライアント端末の処理能力が低いのにサービスプログラムにより比較的大きい処理負荷が生じる場合には、クライアント端末では適切且つ迅速なネットワーク・サービスの提供ができないこともあるので、ネットワーク・プラットフォームを実行主体に決定する。

なお、サービスプログラムを起動させるトリガの検出がネットワーク・プラットフォーム側と判断された場合又は上記条件が満たされていないと判断された場合に、サービスプログラムの実行主体をネットワーク・プラットフォームとして決定するステップと、実行主体がネットワーク・プラットフォームであると決定されたサービスプログラムを、ネットワーク・プラットフォーム側に保管させるステップとをさらに含むようにしてもよい。このようにサービスプログラムの実行主体が保管主体となれば迅速な実行が可能となる。

本発明の第２の態様に係る情報処理方法は、ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせに関しクライアント側で定義され且つネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムに関する情報処理方法であって、特定のトリガを検出するステップと、特定のトリガに対応するサービスプログラムを特定するステップと、特定されたサービスプログラムの実行がクライアント端末に所定レベル以上影響を与えるか判断する判断ステップと、特定されたサービスプログラムの実行がクライアント端末に所定レベル以上影響を与えることがないと判断された場合には、当該特定されたサービスプログラムを実行させるステップとを含む。

このようにクライアント端末においてトリガを検出した場合には、原則としてクライアント端末が当該トリガに対応するサービスプログラムを実行するが、クライアント端末の場合には他のプログラムの処理により処理余力が少なくなっている場合もある。従って、さらにサービスプログラムを実行するとクライアント端末における処理実行に悪影響を及ぼす場合がある。従って、上で述べたようにサービスプログラムの実行がクライアント端末に所定レベル以上影響を与えることがないと判断された場合には、トリガを検出したクライアント端末においてサービスプログラムを実行するものである。

また、特定されたサービスプログラムがクライアント端末に所定レベル以上影響を与えると判断された場合には、特定のトリガに関するデータ及びサービスプログラムの識別情報を含む実行要求をネットワーク・プラットフォームに送信するステップと、ネットワーク・プラットフォームからサービスプログラムによる処理結果を受信するステップとをさらに含むようにしてもよい。このようにネットワーク・プラットフォームにサービスプログラムの実行を委任する場合もある。このようにすれば、クライアント端末における処理負荷を上げることなく、ネットワーク・サービスの提供を受けることができる。

また、特定されたサービスプログラムの実行がクライアント端末に所定レベル以上影響を与えることはないと判断された場合には、当該特定された前記サービスプログラムを保持しているか判断するステップと、特定されたサービスプログラムを保持していないと判断された場合には、ネットワーク・プラットフォームからダウンロードするステップとをさらに含むようにしてもよい。例えば、クライアントがいつも使用するクライアント端末ではないクライアント端末を使用している場合には、使用するサービスプログラムをネットワーク・プラットフォームからダウンロードできれば、利便性が向上する。すなわち、柔軟なサービスプログラムの実行が可能となる。

本発明の第３の態様に係る情報処理方法は、ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせに関しクライアント側で定義され且つネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムに関する情報処理方法であって、トリガを検出するステップと、検出されたトリガが取扱可能なトリガであるか判断する判断ステップと、検出されたトリガが取扱可能なトリガであると判断された場合、検出されたトリガに対応するサービスプログラムを特定するステップと、特定されたサービスプログラムを実行するステップとを含む。このようにすれば、適切にトリガを処理して、ネットワーク・サービスを適切に提供することができるようになる。

なお、上で述べた判断ステップが、検出されたトリガが、ネットワーク・プラットフォームを利用可能なクライアントに関連するトリガであるか判断するステップと、検出されたトリガがネットワーク・プラットフォームを利用可能なクライアントに関連するトリガであると判断された場合、検出されたトリガに関連するサービスプログラムが定義されているか確認するステップとを含むようにしてもよい。

本発明に係る情報処理方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。

本発明によれば、ネットワーク・サービスの柔軟且つ迅速な提供が可能となる。

［本発明の実施の形態における前提］
図１に本発明の一実施の形態に係るシステム概要図を示す。インターネット等のオープンネットワーク１には、複数のクライアント端末（ＣＴ：Client Terminal）が接続されている。また、オープンネットワーク１は、ゲートウェイ（ＧＷ：Gateway）３を介してサービス提供ネットワーク５に接続されている。サービス提供ネットワーク５においては、以下に説明するネットワーク・プラットフォーム（ＮＰ）５０が構築されている。

ネットワーク・プラットフォーム５０には、共通機能モジュールとして、認証・認可機能モジュール５０１と、課金機能モジュール５０２と、ＣＴ管理機能モジュール５０３とが設けられている。認証・認可機能モジュール５０１は、クライアント認証、端末認証、サービス認可等を行う。課金機能モジュール５０２は、例えばクライアント毎に機能モジュールの使用回数等の課金に必要なデータを収集し、例えばクライアント毎の課金データを生成する。ＣＴ管理機能モジュール５０３は、各機能モジュールの版数管理、クライアント端末の状態管理、クライアント端末への機能モジュールのダウンロード制御、及び以下で説明するサービスプログラムの登録確認、サービスＩＤの発行などを行う。

また、ネットワーク・プラットフォーム５０には、個別機能モジュールとして、セッション制御（例えばＳＩＰ（Session Initiation Protocol））を行うセッション制御機能モジュール５０４、クライアントのプレゼンス・データを管理するコンテキスト管理機能モジュール５０５、メディア変換機能モジュール５０６などの機能モジュールが設けられている。図１では３つの個別機能モジュールを示しているが、他の機能モジュールが設けられる場合もある。さらに、ネットワーク・プラットフォーム５０には、個別機能モジュール等が共通して使用するコモンアプリケーション＃１、＃２、＃３なども設けられている。

一方、クライアント端末には、１又は複数のサービスプログラムと、１又は複数のクライアント機能モジュールと、管理プログラムとが設けられている。図１の例では、クライアント端末７には、サービスプログラム＃１及び＃２と、クライアント機能モジュールＡ及びＢと、管理プログラム７１が設けられている。クライアント機能モジュールについては、ネットワーク・プラットフォーム５０からダウンロードした機能モジュールである場合もあれば、予めクライアント端末に用意されている機能モジュールの場合もある。また、クライアント端末９には、サービスプログラム＃３と、クライアント機能モジュールＣと、管理プログラム９１とが設けられている。

さらに、ネットワーク・プラットフォーム５０内には、コモンアプリケーションと個別機能モジュールとの間にＮＰ−ＡＰＩ（Application Program Interface）が規定されている。また、クライアント端末内には、サービスプログラムとクライアント機能モジュールとの間にＣＴ−ＡＰＩが規定されている。例えばクライアント端末においてサービスプログラムは、ＣＴ−ＡＰＩを介してクライアントの機能モジュールを用いるようになっている。さらに、クライアント端末とネットワーク・プラットフォーム５０との間に、サービス管理インターフェース（ＳＭＩ：Service Management Interface）と、サービス制御インターフェース（ＳＣＩ：Service Control Interface）とが規定されている。サービスプログラムは、ＳＣＩを介してクライアント端末のユーザが望むサービスが、ネットワーク・プラットフォーム５０から提供されるように、定義される。

次に、サービス管理インターフェースＳＭＩについて説明する。ネットワーク・プラットフォーム５０は、ネットワーク・プラットフォーム５０において公開している機能モジュールとその機能を実行する際に必要なパラメータをＳＭＩを介して公開しており、クライアント端末のユーザ又はクライアント・システムの構築者は、ＳＭＩを介してネットワーク・プラットフォーム５０から必要な情報を取得してサービスプログラム作成を行う。

ＳＭＩを介してやりとりされるパケットの形式は、例えば図２（ａ）に示すようなものである。すなわち、ＩＰアドレスなどのネットワーク・アドレスを含むパケット・ヘッダと、クライアントＩＤと、端末ＩＤと、動作データとが含まれる。動作データについては、クライアント端末からのパケットであれば例えばサービス要求内容（サービスプログラム登録要求、機能ダウンロード要求、版数管理要求、状態管理要求など）が含まれ、ネットワーク・プラットフォーム５０からのパケットであれば例えば処理結果や要求データが含まれる。また、ＳＣＩを介してやりとりされるパケットの形式は、例えば図２（ｂ）に示すようなものである。すなわち、ＩＰアドレスなどのネットワーク・アドレスを含むパケットヘッダと、クライアントＩＤと、端末ＩＤと、サービスプログラムのＩＤであるサービスＩＤと、動作データとを含む。動作データについては、クライアント端末からのパケットであれば例えば起動すべき機能モジュールのＩＤ及び必要なパラメータを含み、ネットワーク・プラットフォーム５０からのパケットであれば例えば処理結果が含まれる。

また、サービス提供ネットワーク５には、ＮＰ運用管理機能も用意されており、ＮＰ運用管理インターフェースを介してＮＰ運用管理機能によりネットワーク・プラットフォーム５０について各種管理を行う。なお、ＮＰ運用管理機能については本実施の形態の主要部ではないので、これ以上説明は行わない。

［サービスプログラムを実行するための構成］
図１に示したシステム概要は、ユーザによる指示に応じてクライアント端末７又は９において保持されているサービスプログラムを実行し、ネットワーク・プラットフォーム５０における機能モジュールに対して処理を依頼し、ネットワーク・プラットフォーム５０の機能モジュールから処理結果を受信するケースについて示している。しかし、このようにサービスプログラムの実行主体及び保管主体をクライアント端末に固定してしまうと柔軟性が損なわれる。すなわち、サービスプログラムの実行主体及び保管主体を固定的にクライアント端末としてしまうと、クライアント又はクライアント端末のコンテキスト（状態）によってサービスを受けるクライアント端末が一意に決まらないような場合がある。そうすると、サービスプログラムを最初に実行したクライアント端末がそのまま最終的な処理結果を受信するクライアント端末と一致しない場合があるため、クライアントは面倒な処理を実行させなければならない場合が生ずる。一方、ネットワーク・プラットフォーム５０が固定的に実行主体とすると、サービスプログラム実行のトリガがクライアント端末で発生した場合には、ネットワーク・プラットフォーム５０が当該トリガの処理を開始するのに時間がかかってしまう。さらに、サービスプログラムを固定的にクライアント端末に保管していると、当該クライアント端末の電源が落とされていると、外出先からサービスプログラムをダウンロードすることができなくなる。このように、サービスプログラムの実行主体及び保管主体を固定的にするのはサービス提供の柔軟性及び迅速性を損なうことになる。

そこで、（１）クライアント端末がサービスプログラムを保管しておき、クライアント端末が当該サービスプログラムを実行するケース、（２）ネットワーク・プラットフォーム５０がサービスプログラムを保管しておき、クライアント端末がダウンロードして実行するケース、（３）クライアント端末がサービスプログラムを保管しておき、ネットワーク・プラットフォーム５０がダウンロードして実行するケース、（４）ネットワーク・プラットフォーム５０がサービスプログラムを保持しておき、ネットワーク・プラットフォーム５０が当該サービスプログラムを実行するケースを全て取り扱えるようにする。

そのためネットワーク・プラットフォーム５０については図３に示すような機能を付加的に採用する。すなわち、ネットワーク・プラットフォーム５０は、サービスプログラム実行処理部５２０をさらに含む。なお、ＣＴ管理機能モジュール５０３については図１に示したものと同じであるが、その機能を詳細化している。サービスプログラム実行処理部５２０は、トリガ検出部５２０１と、サービスプログラム特定部５２０２と、サービスプログラムデータ格納部５２０３と、実行受託処理部５２０４と、ダウンロード部５２０５と、場合によっては実行主体決定部５２０６とを含む。また、ＣＴ管理機能モジュール５０３は、サービスプログラムチェック部５０３１と、サービスＩＤ管理部５０３３と、保管主体決定部５０３４と、実行主体決定部５０３５と、プロセッサ能力ＤＢ５０３６と、仕事量分析部５０３７とを有する。

サービスプログラム実行処理部５２０のトリガ検出部５２０１は、トリガを検出すると、当該トリガのデータをサービスプログラム特定部５２０２に出力する。サービスプログラム特定部５２０２は、サービスプログラムに関するデータ及びサービスプログラム自体を格納するサービスプログラムデータ格納部５２０３を参照して処理を実行し、特定されたサービスプログラムを実行させる。なお、ネットワーク・プラットフォーム５０に、特定されたサービスプログラムが保管されていない場合には、サービスプログラム特定部５２０２は、ダウンロード部５２０５に、必要なサービスプログラムを保管先からダウンロードさせる。また、サービスプログラム特定部５２０２は、場合によっては実行主体決定部５２０６に実行主体を決定するように指示する。実行主体決定部５２０６は、サービスプログラムデータ格納部５２０３を参照して実行主体を決定し、ネットワーク・プラットフォーム５０が実行主体であると判断すると、当該サービスプログラムを実行させる。なお、当該サービスプログラムが保管されていない場合には、ダウンロード部５２０５にダウンロードさせる。ダウンロード部５２０５は、サービスプログラムをダウンロードすると、当該サービスプログラムをサービスプログラムデータ格納部５２０３に格納し、実行させる。実行受託処理部５２０４は、クライアント端末から実行を委任された場合には、サービスプログラムデータ格納部５２０３から、実行を要求されたサービスプログラムを読み出して実行させる。但し、保持されていない場合には、当該サービスプログラムをダウンロード部５２０５にダウンロードさせ、実行させる。また、実行受託処理部５２０４は、サービスプログラムの処理結果を受け取り、必要があればクライアント端末に送信する。

ＣＴ管理機能モジュール５０３の保管主体決定部５０３４、実行主体決定部５０３５及び仕事量分析部５０３７は、サービスプログラムデータ格納部５２０３を参照して処理を実行する。また、保管主体決定部５０３４は、ネットワーク・プラットフォーム５０に保管すると判断されたサービスプログラムを、サービスプログラムデータ格納部５２０３に格納する。なお、実行主体決定部５０３５はさらに各端末の処理能力についてのデータを格納するプロセッサ能力ＤＢ５０３６を参照して処理を行う。

一方、クライアント端末７又は９についても図４に示すような機能を付加的に採用する。すなわち、クライアント端末（ここではクライアント端末７を例に説明する）は、サービスプログラム実行処理部７１０をさらに含む。なお、管理プログラム７１については図１に示したものと同じであるが、その機能を詳細化している。サービスプログラム実行処理部７１０は、トリガ検出部７１１と、サービスプログラム特定部７１２と、サービスプログラムデータ格納部７１７と、第２実行主体決定部７１３と、ダウンロード部７１４と、ＣＰＵ使用率取得部７１５と、ＣＰＵ使用率格納部７１６と、実行委任処理部７１８と、各端末の処理能力についてのデータを格納するプロセッサ能力ＤＢ７１９とを有する。管理プログラム７１は、サービスプログラム開発部７０１と、仕事量分析部７０２と、保管主体決定部７０３と、第１実行主体決定部７０４と、サービスＩＤ管理部７０５とを有する。

サービスプログラム実行処理部７１０のトリガ検出部７１１は、トリガを検出すると、サービスプログラム特定部７１２に当該トリガのデータを出力する。サービスプログラム特定部７１２は、サービスプログラムに関するデータ及びサービスプログラム自体を格納するサービスプログラムデータ格納部７１７を参照して処理を行い、実行すべきサービスプログラムを特定する。そして、サービスプログラム特定部７１２は、特定したサービスプログラムの識別情報及びトリガのデータを第２実行主体決定部７１３に出力する。また、ＣＰＵ使用率取得部７１５は、サービスプログラム特定部７１２からの指示に応じて、ＯＳ（Operating System）等からＣＰＵ使用率のデータを取得し、ＣＰＵ使用率格納部７１６に格納する。第２実行主体決定部７１３は、ＣＰＵ使用率格納部７１６とサービスプログラムデータ格納部７１７及びプロセッサ能力ＤＢ７１９を参照して処理を行い、特定されたサービスプログラムの実行主体を決定する。第２実行主体決定部７１３が、クライアント端末７においてサービスプログラムを実行すると判断した場合には、当該サービスプログラムを実行させる。但し、サービスプログラムデータ格納部７１７にサービスプログラムが格納されていない場合には、ダウンロード部７１４に当該サービスプログラムをネットワーク・プラットフォーム５０からダウンロードさせる。ダウンロード部７１４は、ダウンロードしたサービスプログラムを実行させる。なお、第２実行主体決定部７１３が、検出されたトリガに対応するサービスプログラムの実行主体をネットワーク・プラットフォーム５０と決定した場合には、実行委任処理部７１８に処理を実行させる。実行委任処理部７１８は、第２実行主体決定部７１３の指示に従って、トリガのデータ及びサービスプログラムのサービスＩＤをネットワーク・プラットフォーム５０に送信する。また、実行委任処理部７１８は、ネットワーク・プラットフォーム５０から処理結果を受信し、クライアント端末７に処理結果を提示するか、必要な機能モジュールに処理させる。

管理プログラム７１のサービスプログラム開発部７０１は、サービスプログラムを生成し、ネットワーク・プラットフォーム５０に対する登録処理などを実施する。仕事量分析部７０２は、サービスプログラムデータ格納部７１７を参照して処理を実施し、処理結果をサービスプログラムデータ格納部７１７に格納する。保管主体決定部７０３は、サービスプログラムデータ格納部７１７を参照して処理を行い、保管主体をクライアント端末７と判断した場合にはサービスプログラムをサービスプログラムデータ格納部７１７に格納する。サービスＩＤ管理部７０５は、サービスプログラムについてサービスＩＤを発行し、サービスプログラムデータ格納部７１７に格納する。第１実行主体決定部７０４は、サービスプログラムデータ格納部７１７及びプロセッサ能力ＤＢ７１９を参照して処理を実行し、処理結果をサービスプログラムデータ格納部７１７に格納する。

図３及び図４に示したネットワーク・プラットフォーム５０及びクライアント端末７又は９についての処理内容については、以下に詳細に説明する。

［サービスプログラムの作成時の処理］
サービスプログラムの作成時の処理については図５乃至図１４を用いて説明する。例えばクライアント端末７における管理プログラム７１のサービスプログラム開発部７０１は、ＳＭＩを介してサービスプログラム作成要求をネットワーク・プラットフォーム５０に送信する（ステップＳ１）。ネットワーク・プラットフォーム５０のＣＴ管理機能モジュール５０３は、クライアント端末７からサービスプログラム作成要求を受信し（ステップＳ３）、サービスプログラム作成要素データをＳＭＩを介してクライアント端末７に送信する（ステップＳ５）。クライアント端末７における管理プログラム７１のサービスプログラム開発部７０１は、ネットワーク・プラットフォーム５０からサービスプログラム作成要素データを受信し（ステップＳ７）、当該サービスプログラム作成要素データを用いてサービスプログラム作成画面を表示する（ステップＳ９）。例えば図６に示すような画面が表示される。図６の例では、サービスプログラム開発ウインドウと、サービスプログラムのロジックのテンプレート・ウインドウとが表示されている。サービスプログラム開発ウインドウには、ネットワーク・プラットフォーム５０において公開されている機能モジュールのリストが含まれ、ここではＳＩＰ、ＲＳＶＰ（Resource Reservation Setup Protocol）−ＴＥ（Traffic Engineering）、コンテキスト管理、ＲＦＩＤ（Radio Frequency-ID）ミドル、メディア変換などの項目が列挙されている。また、各項目をクリックすると、当該項目に係る機能モジュールの機能概要及び入力パラメータ情報が表示されるようになっている。なお、図６ではＳＩＰを選択した場合を示しており、機能概要及び入力パラメータについてはポップアップウインドウなどにて表示しても良い。テンプレート・ウインドウでは、典型的な処理ロジックが選択可能となっており、図６の例では第１段階で何らかの処理を行って、第２段階で条件を判断し、第３段階で条件によって異なる処理を行うというロジックの例が示されている。クライアント端末７のユーザは、サービスプログラム開発ウインドウに表示された内容を参照しつつ、テンプレート・ウインドウに今回作成するサービスプログラムのロジックに合致するロジックを表示させ、各ブロックで行う処理、使用する機能モジュールのＩＤ、必要なパラメータを入力する。

なお、クライアント端末７における管理プログラム７１のサービスプログラム開発部７０１は、必要な機能モジュールがクライアント端末７に存在するか確認する（ステップＳ１１）。もし、必要な機能モジュールがクライアント端末７に存在しないと判断した場合には、ネットワーク・プラットフォーム５０に対して必要な機能モジュールについて機能モジュール要求をＳＭＩを介して送信する（ステップＳ１３）。ネットワーク・プラットフォーム５０のＣＴ管理機能モジュール５０３は、クライアント端末７から機能モジュール要求を受信する（ステップＳ１５）。ネットワーク・プラットフォーム５０のＣＴ管理機能モジュール５０３は、受信した機能モジュール要求のパケットに含まれるクライアントＩＤ等から、要求に係る機能モジュールの送信可否を判断することもある。但し、ネットワーク・プラットフォーム５０を利用する上で必要な基本的な機能モジュールであれば、特にチェックする必要はない。ＣＴ管理機能モジュール５０３は、機能モジュール格納部５１１から要求に係る機能モジュールを読み出し、ＳＭＩを介してクライアント端末７に送信する（ステップＳ１７）。クライアント端末７における管理プログラム７１のサービスプログラム開発部７０１は、ネットワーク・プラットフォーム５０から要求機能モジュールを受信すると、クライアント端末の記憶装置に格納する（ステップＳ１９）。

ステップＳ１１において必要な機能モジュールがクライアント端末７に存在すると判断された場合及びステップＳ１９の後に、クライアント端末７における管理プログラム７１のサービスプログラム開発部７０１は、例えば図６に示したような画面において、ユーザからのサービスプログラム作成指示を受け付ける（ステップＳ２１）。ネットワーク・プラットフォーム５０において利用可能な機能モジュールのＩＤ及び必要な入力パラメータのセットが、ロジックを表すテンプレートのブロックにおいて指定されており、ロジックに必要な条件等のデータも指定される。処理は端子Ａを介して図７の処理に移行する。

そして、クライアント端末７における管理プログラム７１のサービスプログラム開発部７０１は、受け付けた入力データに従ってサービスプログラムを生成し、記憶装置に格納する（ステップＳ２３）。そして、管理プログラム７１のサービスプログラム開発部７０１は、サービスプログラムを含むサービスプログラム登録要求を、ネットワーク・プラットフォーム５０に送信する（ステップＳ２５）。ネットワーク・プラットフォーム５０におけるＣＴ管理機能モジュール５０３のサービスプログラムチェック部５０３１は、クライアント端末７からサービスプログラムを含むサービスプログラム登録要求を受信し、記憶装置に格納する（ステップＳ２７）。そして、ＣＴ管理機能モジュール５０３のサービスプログラムチェック部５０３１は、クライアントデータ格納部５１３を参照して、受信したサービスプログラムに対するチェック処理を実施する（ステップＳ２９）。

例えば、クライアントデータ格納部５１３には、図８に示すようなデータが格納されている。図８の例では、クライアントＩＤに対応して利用可能な機能モジュールのＩＤが登録されている。このような簡単なテーブルではなく、クライアントの所属が定義されたテーブルと、所属と利用可能な機能モジュールのＩＤとの対応テーブルとを組み合わせる場合もある。ＣＴ管理機能モジュール５０３のサービスプログラムチェック部５０３１は、サービスプログラム登録要求に含まれるクライアントＩＤを用いて図８に示すようなテーブルを検索して利用可能な機能モジュールのＩＤを特定し、サービスプログラムにおいて規定されている全機能モジュールが利用可能か、すなわちサービスプログラムの利用を認可できるか判断する（ステップＳ３１）。

もし、利用不可能な機能モジュールがサービスプログラム中に規定されている場合には、ＣＴ管理機能モジュール５０３のサービスプログラムチェック部５０３１は、登録拒否通知をクライアント端末７に送信する。クライアント端末７における管理プログラム７１のサービスプログラム開発部７０１は、ネットワーク・プラットフォーム５０から登録拒否通知を受信し、表示装置に表示する（ステップＳ３３）。これにて作成したサービスプログラムに問題があることを認識することができる。

一方、クライアント端末７から受信したサービスプログラムにおいて規定されている全機能モジュールが利用可能であると判断された場合には、ＣＴ管理機能モジュール５０３のサービスＩＤ管理部５０３３は、当該サービスプログラムに対してサービスＩＤを発行し、クライアントデータ格納部５１３に登録する（ステップＳ３５）。例えば、図９に示すように、クライアントＩＤに対応してサービスＩＤが登録される。なお、サービスプログラム自体又は定義されている全機能モジュールのＩＤ群をクライアントデータ格納部５１３又は他のデータ格納部にクライアントＩＤに対応付けて認証・認可処理のために登録するようにしても良い。サービスＩＤについては、ネットワーク・プラットフォーム５０においてサービスＩＤがユニークである場合、又はクライアント又はクライアントの集合毎にユニークである場合があるが、いずれの方式を採用することも可能である。

次に、主に実行主体決定部５０３５は、サービスプログラムを解析し、さらにプロセッサ能力ＤＢ５０３６を参照して、実行主体決定処理を実施する（ステップＳ３７）。ネットワーク・プラットフォーム５０における実行主体決定処理については図１０を用いて説明する。実行主体決定部５０３５は、サービスのトリガの検出がクライアント端末であるか判断する（ステップＳ５１）。トリガの検出がクライアント端末である場合とは、例えばトリガが特に規定されていない場合、すなわちユーザに指示によってサービスプログラムが実行される場合や、ＩＣタグ（ＲＦＩＤ等とも呼ぶ）の読み出しなどセンサによる検出又は測定などが定義されている場合、その他クライアント端末で発生する特有のイベントがトリガとして規定されている場合である。もし、サービスのトリガの検出がクライアント端末により行われるとは判断されなかった場合には、ネットワーク・プラットフォーム５０を実行主体として指定し、サービスプログラムデータ格納部５２０３に格納する（ステップＳ６３）。なおこの際、サービスプログラムを起動させるトリガについてのデータと実行主体の指定とサービスプログラムの登録を要求したクライアントのＩＤとをサービスＩＤに対応づけて格納する。

サービスプログラムデータ格納部５２０３に格納されるデータの一例を図１１に示す。図１１に示したデータテーブルは、サービスＩＤの列と、起動トリガの列と、当該サービスプログラムの登録を要求したクライアントのＩＤの列と、保管主体の列と、実行主体の列とを含む。すなわち、サービスプログラム毎に、起動トリガ、登録クライアント、保管主体（保管先ネットワークアドレスを含む）及び実行主体が登録され、実際のトリガ検出時に用いる。なお、登録クライアントについては、サービスプログラムの実行を許可されている者が登録されるようにしてもよい。

一方、サービスのトリガの検出がクライアント端末により行われると判断された場合には、当該サービスプログラムが複数のクライアント端末に関係しているか判断する（ステップＳ５３）。サービスプログラムが複数のクライアント端末に関係するという場合は、例えばクライアントのコンテキスト（状態）に応じてデータの送信先のクライアント端末を変更するような場合である。サービスプログラムが複数のクライアント端末に関係すると判断された場合には、ネットワーク・プラットフォーム５０を実行主体に指定し、サービスプログラムデータ格納部５２０３に登録する（ステップＳ６３）。

一方、サービスプログラムが単一のクライアント端末にのみ関係していると判断された場合には、仕事量分析部５０３７は、受信したサービスプログラムを解析して、当該サービスプログラムの仕事量を算出し、例えばメインメモリなどの記憶装置に格納する（ステップＳ５５）。ここでサービスプログラムの仕事量とは、本実施の形態ではサービスプログラムのステップ数Ｎi（例えばアセンブラ言語レベルでのステップ数。但し、サービスプログラムがコンパイルされない言語で記述される場合には当該言語におけるステップ数の場合もある）と、状態遷移数Ｎsと、利用する機能モジュールの種類数Ｎfとを重み付けして加算した値を用いる。例えば、仕事量をｆ(Ｎi，Ｎs，Ｎf)という関数で表すとすると、ｆ(Ｎi，Ｎs，Ｎf)＝ａＮi＋ｂＮs＋ｃＮfと表される。なお、Ｎiが支配的な要素として、係数を決定しておく。ｂ＝ｃ＝０としてもよい。仕事量分析部５０３７は、サービスプログラムを解析して、上で述べたようにサービスプログラムのステップ数Ｎiと、状態遷移数Ｎsと、種類数Ｎfとを計数し、上で述べた式に従って仕事量ｆ(Ｎi，Ｎs，Ｎf)を算出し、記憶装置に格納する。そして、仕事量分析部５０３７は、実行主体決定部５０３５に、算出した仕事量ｆ(Ｎi，Ｎs，Ｎf)のデータを出力する。

実行主体決定部５０３５は、プロセッサ能力ＤＢ５０３６を参照し、クライアント端末のプロセッサ能力Ｐpのデータを読み出す。クライアント端末の種別については、パケットに含まれる端末ＩＤから特定する（例えば端末ＩＤに種別コードが含まれる）ようにしてもよいし、別途ステップＳ２５において送信されるパケットに端末種別データが含まれる場合もある。そして、実行主体決定部５０３５は、クライアント端末の性能を表すプロセッサ能力とサービスプログラムの仕事量とを用いてクライアント端末の無負荷時性能Ｐuを算出し、記憶装置に格納する（ステップＳ５７）。無負荷時性能Ｐuは、そのクライアント端末において実行している他のプログラムが無く、そのサービスプログラムだけを実行する際に、単位時間でどの程度の量の仕事を処理することができるかを表す。すなわち、Ｐu＝Ｐp／ｆ(Ｎi，Ｎs，Ｎf)を算出し、記憶装置に格納する。

そして、実行主体決定部５０３５は、クライアント端末の無負荷時性能Ｐuが所定の閾値Ｊ１以上であるか判断する（ステップＳ５９）。もし、クライアント端末の無負荷時性能Ｐuが所定の閾値Ｊ１以上であると判断された場合には、クライアント端末を実行主体に指定し、サービスプログラムデータ格納部５２０３に格納する（ステップＳ６１）。

このように、トリガの検出場所及びクライアント端末とサービスプログラムとの関係に従って、実行主体を決定する。サービスプログラムの登録時においては、トリガが実際に検出された際のクライアント端末の状態は分からないので、上で述べたような判断基準にて実行主体を決定することにより、サービスプログラムの登録時における実行主体の最適化が図られている。

図７の説明に戻って、次に、保管主体決定部５０３４は、保管主体決定処理を実施する（ステップＳ３９）。この保管主体決定処理については図１２を用いて説明する。基本的にサービスプログラムは、サービス実行主体と同じ所に保管しておくと、サービスプログラムをダウンロードする必要がなく、迅速性の面で優れる。そこで、保管主体決定部５０３４は、サービスプログラムデータ格納部５２０３を参照して、当該サービスプログラムの実行主体がクライアント端末に設定されているか確認する（ステップＳ７１）。サービスプログラムの実行主体がクライアント端末ではなくネットワーク・プラットフォーム５０である場合には、ネットワーク・プラットフォーム５０において保管した方がサービスプログラムの迅速な実行が可能となるので、ネットワーク・プラットフォーム５０を保管先に指定し、サービスプログラムデータ格納部５２０３に格納する（ステップＳ７３）。さらに、サービスプログラム自体についてもサービスプログラムデータ格納部５２０３に格納する。

一方、サービスプログラムの実行主体がクライアント端末である場合には、クライアントに対して使用状況を問い合わせる（ステップＳ７５）。保管主体決定処理をネットワーク・プラットフォーム５０で実行する際には、クライアント端末に対して「本サービスプログラムを他人と共用するか」及び「外出先から頻繁にネットワーク・プラットフォーム５０にアクセスするか」という質問を表示させ、クライアントに対して回答を促すようなデータを送信する。クライアント端末は、当該データを受信し、表示装置に表示して、クライアントに回答を求める。クライアントは上で述べたような質問にＹｅｓ又はＮｏで回答して、クライアント端末は回答データをネットワーク・プラットフォーム５０に返信する。

保管主体決定部５０３４は、クライアント端末から回答データを受信し、記憶装置に格納する。そしてステップＳ７７以降の処理を実施する。すなわち、回答データに基づき、当該サービスプログラムを他人と共用するか判断する（ステップＳ７７）。本サービスプログラムを他人と共用するという回答がなされていれば、ネットワーク・プラットフォーム５０及びクライアント端末を保管先に指定し、サービスプログラムデータ格納部５２０３に格納する（ステップＳ８３）。なお、クライアント端末を保管先に指定する場合には、当該クライアント端末のネットワーク・アドレスも登録しておく。場合によってはクライアント端末からダウンロードしなければならない場合もあるからである。サービスプログラム自体についてもサービスプログラムデータ格納部５２０３に格納する。

一方本サービスプログラムを他人と共用しないという回答がなされていれば、回答データに基づき、クライアントが外出先からネットワーク・プラットフォーム５０に頻繁にアクセスするか判断する（ステップＳ７９）。外出先からネットワーク・プラットフォーム５０に頻繁にアクセスするという回答がなされていれば、ネットワーク・プラットフォーム５０及びクライアント端末を保管先に指定し、サービスプログラムデータ格納部５２０３に格納する（ステップＳ８３）。さらに、サービスプログラム自体についてもサービスプログラムデータ格納部５２０３に格納する。一方、外出先からネットワーク・プラットフォーム５０にあまりアクセスしないという回答がなされていれば、クライアント端末を保管先に指定し、サービスプログラムデータ格納部５２０３に格納する（ステップＳ８１）。

このようにサービスプログラムの実行主体に応じて保管先を決定することにより、迅速な実行が可能となり、高性能なサービス処理が可能となる。更に、想定される使用状況を考慮して保管先を決定することにより、利便性が向上する。例えば、複数人がサービスプログラムを共用する場合に、サービスプログラムをネットワーク・プラットフォーム５０に保管することで、ある端末だけに保管する場合に比べダウンロードが容易になる。またサービスプログラムを外出先から頻繁に利用する場合も、サービスプログラムをネットワーク・プラットフォーム５０に保管することで、容易にダウンロードし、その場でそのサービスプログラムを実行させることが可能になる。

図７の処理の説明に戻って、ＣＴ管理機能モジュール５０３は、サービスプログラムデータ格納部５２０３を参照して、実行主体の指定（ＮＰ又はＣＴ）、保管主体の指定（ＣＴ／ＮＰ／ＣＴ及びＮＰ）及びサービスＩＤを含む登録完了通知を生成し、クライアント端末７に送信する（ステップＳ４１）。

クライアント端末７における管理プログラム７１のサービスプログラム開発部７０１は、ネットワーク・プラットフォーム５０から、実行主体の指定、保管主体の指定及びサービスＩＤを含む登録完了通知を受信し（ステップＳ４３）、サービスＩＤと実行主体及び保管主体の指定データとをサービスプログラムデータ格納部７１７に格納する（ステップＳ４５）。サービスプログラムデータ格納部７１７に格納されるデータの一例を図１３に示す。図１３のデータテーブルは、サービスＩＤの列と、サービスプログラムのステップ数Ｎiの列と、サービスプログラムの状態遷移数Ｎsの列と、サービスプログラムの利用機能モジュール数Ｎfの列と、起動トリガの列と、登録クライアントの列と、保管主体の列と、実行主体の列とを含む。サービスプログラム開発部７０１は、受信したサービスＩＤと実行主体及び保管主体の指定データを、サービスＩＤの列、保管主体の列及び実行主体の列に登録する。なお、実行主体がクライアント端末である場合には、この段階にて仕事量分析部７０２にサービスプログラムを解析させ、Ｎi、Ｎs及びＮfを計数させ、サービスプログラムデータ格納部７１７に格納させるようにしてもよい。そうすれば、トリガが発生した際にサービスプログラムを解析する必要が無くなるためである。さらに、実行主体がクライアント端末である場合には、サービスプログラム開発部７０１は、サービスプログラムを解析し、当該サービスプログラムの起動トリガ及び登録クライアントＩＤについても、それぞれ起動トリガの列及び登録クライアントの列に登録する。

そして、サービスプログラム開発部７０１は、サービスプログラムデータ格納部７１７に格納された保管主体のデータに従って、クライアント端末が保管先に指定されている場合には、登録されたサービスプログラムをサービスプログラムデータ格納部７１７に格納する（ステップＳ４７）。

以上のような処理を実施することにより、サービスプログラムの実行準備が完了する。なお、ネットワーク・プラットフォーム５０において実行主体を決定する場合には、仕事量（ｆ(Ｎi，Ｎs，Ｎf)）をクライアント端末７において計算することがないので、例えばステップＳ４５の後に、仕事量分析部７０２が仕事量（ｆ(Ｎi，Ｎs，Ｎf)）を算出し、サービスプログラムデータ格納部７１７に格納するようにしてもよい。そうすれば、トリガが発生した際にサービスプログラムを解析する必要が無くなるためである。

上で述べた例では実行主体及び保管主体の決定並びにサービスＩＤの発行をネットワーク・プラットフォーム５０において決定する例を示したが、必ずネットワーク・プラットフォーム５０において実行しなければならないわけでない。

次にサービスプログラムの実行主体及び保管主体の決定並びにサービスＩＤの発行をクライアント端末において行う場合について説明する。なお、図５に示した処理については同様であるから、端子Ａ以降の処理について図１４を用いて説明する。

クライアント端末７における管理プログラム７１のサービスプログラム開発部７０１は、受け付けた入力データに従ってサービスプログラムを生成し、記憶装置に格納する（ステップＳ９１）。そして、管理プログラム７１のサービスプログラム開発部７０１は、サービスＩＤ管理部７０５にサービスプログラムに対するサービスＩＤを発行させる（ステップＳ９３）。サービスＩＤ管理部７０５は、発行したサービスＩＤを記憶装置に格納する。そして、サービスプログラム開発部７０１は、発行したサービスＩＤ及び生成したサービスプログラムを含むサービスプログラム登録要求を、ネットワーク・プラットフォーム５０に送信する（ステップＳ９５）。ネットワーク・プラットフォーム５０におけるＣＴ管理機能モジュール５０３のサービスプログラムチェック部５０３１は、クライアント端末７からサービスＩＤ及びサービスプログラムを含むサービスプログラム登録要求を受信し、記憶装置に格納する（ステップＳ９７）。そして、ＣＴ管理機能モジュール５０３のサービスプログラムチェック部５０３１は、クライアントデータ格納部５１３を参照して、受信したサービスプログラムに対するチェック処理を実施する（ステップＳ９９）。

例えば、クライアントデータ格納部５１３は、図８に示すようなデータが格納されている。ＣＴ管理機能モジュール５０３のサービスプログラムチェック部５０３１は、サービスプログラム登録要求に含まれるクライアントＩＤを用いて図８に示すようなテーブルを検索して利用可能な機能モジュールのＩＤを特定し、サービスプログラムにおいて規定されている全機能モジュールが利用可能か、すなわちサービスプログラムの利用を認可できるか判断する（ステップＳ１０１）。

もし、利用不可能な機能モジュールがサービスプログラム中に規定されている場合には、ＣＴ管理機能モジュール５０３のサービスプログラムチェック部５０３１は、登録拒否通知をクライアント端末７に送信する。クライアント端末７における管理プログラム７１のサービスプログラム開発部７０１は、ネットワーク・プラットフォーム５０から登録拒否通知を受信し、表示装置に表示する（ステップＳ１０３）。これにて作成したサービスプログラムに問題があることを認識することができる。

一方、クライアント端末７から受信したサービスプログラムにおいて規定されている全機能モジュールが利用可能であると判断された場合には、ＣＴ管理機能モジュール５０３のサービスＩＤ管理部５０３３は、受信した当該サービスプログラムのサービスＩＤをクライアントデータ格納部５１３及びサービスプログラムデータ格納部５２０３に登録する（ステップＳ１０５）。例えば、図９に示すように、クライアントＩＤに対応してサービスＩＤが登録される。また図１１に示すデータテーブルにレコードを生成し、サービスＩＤを登録する。なお、サービスプログラム自体又は定義されている全機能モジュールのＩＤ群をクライアントデータ格納部５１３又は他のデータ格納部にクライアントＩＤに対応付けて認証・認可のために登録するようにしても良い。

サービスプログラムチェック部５０３１は、サービスＩＤの登録完了通知を生成し、クライアント端末７に送信する（ステップＳ１０７）。クライアント端末７のサービスプログラム開発部７０１は、ネットワーク・プラットフォーム５０からサービスＩＤの登録完了通知を受信し、サービスプログラムデータ格納部７１７に登録する（ステップＳ１０９）。サービスプログラムデータ格納部７１７に登録されるデータは図１３に示したようなデータであり、ここではサービスＩＤ及び登録クライアントＩＤが登録される。

次に、サービスプログラム開発部７０１は、第１実行主体決定部７０４に実行主体決定処理を実施させる（ステップＳ１１１）。第１実施主体決定部７０４による実行主体決定処理は、基本的には図１０に示した処理と同様であるが、ステップＳ１１１の場合には、サービスプログラムデータ格納部７１７と、第１実行主体決定部７０４と、仕事量分析部７０２と、プロセッサ能力ＤＢ７１９を用いて実施される。そして、サービスプログラムデータ格納部７１７に格納されるデータは、図１３に示したようなデータであって、ステップＳ１１１における実行主体決定処理において、Ｎi、Ｎs、Ｎf、起動トリガ及び実行主体が登録される。

さらに、保管主体決定部７０３は、保管主体決定処理を実施する（ステップＳ１１３）。保管主体決定部７０３による保管主体決定処理は、基本的には図１２に示した処理と同様であるが、ステップＳ１１３の場合には、サービスプログラムデータ格納部７１７と、保管主体決定部７０３とを用いて実施される。また、使用状況の問い合わせについては、保管主体決定部７０３がクライアントに対して直接行う。なお、ステップＳ１１３における保管主体決定処理において、サービスプログラムデータ格納部７１７に保管主体が登録される。

そして、サービスプログラム開発部７０１は、サービスプログラムデータ格納部７１７を参照して、実行主体及び保管主体の指定データをネットワーク・プラットフォーム５０に送信する（ステップＳ１１５）。なお、サービスＩＤも送信することによりサービスプログラムを識別する。ネットワーク・プラットフォーム５０におけるＣＴ管理機能モジュール５０３は、実行主体及び保管主体の指定データを受信し、同じく受信したサービスＩＤに対応してサービスプログラムデータ格納部５２０３に登録する（ステップＳ１１７）。そして、ＣＴ管理機能モジュール５０３は、保管主体の指定データに基づいて、保管主体がネットワーク・プラットフォーム５０であれば、ステップＳ９７で受信し記憶装置に格納されたサービスプログラムをサービスプログラムデータ格納部５２０３に格納する（ステップＳ１２１）。

一方、クライアント端末７における管理プログラム７１の保管主体決定部７０３は、保管主体の指定データに基づき、保管主体がクライアント端末であれば、ステップＳ９１で生成し記憶装置に格納されたサービスプログラムをサービスプログラムデータ格納部７１７に格納する（ステップＳ１１９）。

このような処理に置換してもサービスプログラムの実行準備を実行することができるようになる。

また、このようにすれば、ＳＣＩを介してネットワーク・プラットフォーム５０に対してサービスを要求する際に、図２（ｂ）に示すようなパケットを生成して送信することができ、ネットワーク・プラットフォーム５０からは、ユーザにカスタマイズされたサービスプログラムにおいて規定されたサービスを受けることができるようになる。

なお、図５の処理フローでは、クライアント端末のための機能モジュールをステップＳ１１乃至Ｓ１９で必要であればダウンロードするような構成を示したが、例えばクライアント端末が登録完了通知を受信した後に、サービスプログラムの実行に必要となる機能モジュールをさらにダウンロードするようにしても良い。また、ステップＳ１１乃至Ｓ１９を実施せず、登録完了通知を受信した後にサービスプログラムの実行に必要となる機能モジュールをダウンロードするようにしても良い。

［サービスプログラムの実行処理］
次に、クライアント端末においてトリガを検出して処理を開始する場合について図１５を用いて説明する。クライアント端末７におけるサービスプログラム実行処理部７１０のトリガ検出部７１１は、トリガとなるイベントの発生を探索しており、何らかのトリガが発生すると、当該トリガのデータを取得する（ステップＳ１３１）。そしてトリガ検出部７１１は、当該トリガのデータをサービスプログラム特定部７１２に出力する。サービスプログラム特定部７１２は、サービスプログラムデータ格納部７１７を参照して、実行すべきサービスプログラムを特定する（ステップＳ１３３）。例えば図１３における起動トリガの列を探索して、検出されたトリガに合致するサービスプログラムが登録されているか判断する（ステップＳ１３５）。なお、現在クライアント端末７を使用しているクライアントが登録クライアント（許可クライアント）であるかをさらに確認するようにしてもよい。

ここで、検出されたトリガに対応して実行すべきサービスプログラムが登録されていないと判断された場合には処理を終了する。一方、実行すべきサービスプログラムが登録されていると判断された場合には、第２実行主体決定部７１３は、プロセッサ能力ＤＢ７１９を検索して本クライアント端末のプロセッサ能力を読み出し、サービスプログラムデータ格納部７１７から実行すべきサービスプログラムのステップ数Ｎi、状態遷移数Ｎs及び利用する機能モジュール数Ｎfを読み出し、上で述べたような方法で無負荷時性能を算出し、記憶装置に格納する（ステップＳ１３７）。もしＮi，Ｎs及びＮfが未計数の場合には、仕事量分析部７０２に計数させた上で、第２実行主体決定部７１３に無負荷時性能を算出させるようにしてもよい。また、図１３では無負荷時性能の値については登録されていないが、例えばサービスプログラムの登録時に算出した値を登録しておき、ステップＳ１３７において当該値を読み出すようにしてもよい。そして、無負荷時性能が所定の閾値以下であるか判断する（ステップＳ１３９）。

もし無負荷時性能が所定の閾値以下であると判断された場合には、クライアント端末７では当該サービスプログラムを実行させると、クライアント端末７の通常の動作に悪影響を及ぼしたり、もしくは処理に多くの時間がかかるなど、満足する性能が得られない可能性があるため、サービスプログラム登録段階で、ネットワーク・プラットフォーム５０に実行を委託することになる。従って、第２実行主体決定部７１３は実行委任処理部７１８にネットワーク・プラットフォーム５０に対する実行委任処理を実施させる。すなわち、実行委任処理部７１８は、検出されたトリガのデータ及び実行すべきサービスプログラムのサービスＩＤを含む実行委任要求を生成し、ネットワーク・プラットフォーム５０に送信する（ステップＳ１５５）。

これ以降の処理については図１６を用いて説明する。ネットワーク・プラットフォーム５０におけるサービスプログラム実行処理部５２０の実行受託処理部５２０４は、トリガのデータ及び実行すべきサービスプログラムのサービスＩＤを含む実行委託要求を受信する（ステップＳ１６１）。そして、実行受託処理部５２０４は、サービスプログラムデータ格納部５２０３を参照して、サービスＩＤで特定されるサービスプログラムを保持しているか確認する（ステップＳ１６３）。もし保持しているようであればステップＳ１６９に移行する。一方、サービスプログラムを保持していないと判断された場合には、サービスプログラムデータ格納部５２０３を参照して、当該サービスプログラムの保管主体のデータ（保持しているクライアント端末のネットワーク・アドレス）からサービスプログラムの保管先を特定し、サービスＩＤを含むサービスプログラム要求をサービスプログラム保管先に送信する（ステップＳ１６５）。クライアント端末７が保管先である場合には、管理プログラム７１はサービスプログラムデータ格納部７１７からサービスＩＤに対応するサービスプログラムのデータを読み出し、ネットワーク・プラットフォーム５０に送信する。ネットワーク・プラットフォーム５０の実行受託処理部５２０４は、サービスプログラムを受信し、サービスプログラムデータ格納部５２０３を格納する（ステップＳ１６７）。

ステップＳ１６７の後に又はステップＳ１６３でサービスプログラムを保持していると判断された場合には、実行受託処理部５２０４は、実行を委任されたサービスプログラムを実行させる（ステップＳ１６９）。サービスプログラムは、ネットワーク・プラットフォーム５０に設けられている機能モジュールを用いて実行を行い、サービスプログラムの処理結果を実行受託処理部５２０４に出力する。実行受託処理部５２０４は、サービスプログラムの処理結果を取得し（ステップＳ１７１）、当該処理結果を実行委任元のクライアント端末７に送信する（ステップＳ１７３）。そして元の処理に戻る。

このようにサービスプログラムの処理をクライアント端末において行わずにネットワーク・プラットフォーム５０に実行させることができるため、クライアント端末の処理負荷を上げることなくネットワーク・サービスを受けることができるようになる。

図１５の説明に戻って、実行委任処理部７１８は、ネットワーク・プラットフォーム５０からサービスプログラムの処理結果を受信し、必要であれば対応する機能モジュールを起動する（ステップＳ１５７）。例えば、ＨＴＭＬ形式で処理結果を受信した場合には、ウェブ（Ｗｅｂ）ブラウザを起動させ、表示させる。メール形式であればメールクライアントを起動させ、メールを表示させる。その他実行委任処理部７１８が、自ら処理結果を表示させるようにしてもよい。

一方ステップＳ１３９において無負荷時性能が所定の閾値を上回っていると判断された場合には、第２実行主体決定部７１３は、ＣＰＵ使用率取得部７１５にＯＳなどからＣＰＵ使用率を取得させ、ＣＰＵ使用率格納部７１６に格納させる（ステップＳ１４１）。その後、第２実行主体決定部７１３は、ＣＰＵ使用率格納部７１６とサービスプログラムデータ格納部７１７とプロセッサ能力ＤＢ７１９とを参照して、ＣＰＵ使用率とプロセッサ能力と仕事量算出の基となるデータ（Ｎi，Ｎs及びＮf）とを取得し、それらのデータから実負荷時性能を算出し、記憶装置に格納する（ステップS１４３）。ここではクライアント端末において既に実行されている他のジョブを考慮し、プロセッサの余剰能力をベースにサービスプログラムの実行が与える影響を分析しなければならない。従って、まずプロセッサ余剰能力Ｐr＝プロセッサ能力Ｐp×（１−ＣＰＵ使用率）と定義する。そして、クライアント端末の実負荷時性能Ｐｌを、Ｐr／ｆ(Ｎi，Ｎs，Ｎf)＝Ｐr／（ａＮi＋ｂＮs＋ｃＮf）と定義する。

そして第２実行主体決定部７１３は、実負荷時性能Ｐｌが所定の閾値（ステップＳ１３９における閾値とは異なる場合もある）以下であるか判断する（ステップＳ１４５）。実負荷時性能Ｐｌが所定の閾値以下と判断された場合には、ステップＳ１５５に移行して、当該サービスプログラムの実行をネットワーク・プラットフォーム５０に委託する。一方、実負荷時性能Ｐｌが所定の閾値を上回っていると判断された場合には、第２実行主体決定部７１３は、サービスプログラムデータ格納部７１７を参照して、実行すべきサービスプログラムを保持しているか判断する（ステップＳ１４７）。もし、保持していないと判断された場合には、第２実行主体決定部７１３は、ダウンロード部７１４にネットワーク・プラットフォーム５０に対して実行すべきサービスプログラムのサービスＩＤを含むサービスプログラム要求を送信させる（ステップＳ１４９）。

ネットワーク・プラットフォーム５０のＣＴ管理機能モジュール５０３は、サービスプログラム要求をクライアント端末から受信すると、サービスプログラムデータ格納部５２０３から読み出し、要求元のクライアント端末に返信する。これに対して、ダウンロード部７１４は、ネットワーク・プラットフォーム５０からサービスプログラムを受信し、サービスプログラムデータ格納部７１７に格納する（ステップＳ１５１）。そして、第２実行主体決定部７１３又はダウンロード部７１４は、サービスプログラムを実行させる（ステップＳ１５３）。この後はサービスプログラムを通常通り実行すればよい。

上で述べたような条件を満たせば迅速且つ適切にクライアント端末においてサービスプログラムを実行することができる。また、条件を満たしていない場合においても、ネットワーク・プラットフォーム５０に実行を委託することができるため、クライアントはクライアント端末に処理余裕がない場合でもネットワーク・サービスを受けることができる。

なお、クライアントがいつも使用していないクライアント端末を使用する際に、特定のサービスプログラムを実行させる指示を行うと、当該クライアント端末のサービスプログラムデータ格納部７１７には特定のサービスプログラムのデータが登録されていない場合もあるが、このような場合サービスプログラムはユーザにより指定されるので、ステップＳ１３５からステップＳ１３７に移行するものとする。

次に、ネットワーク・プラットフォーム５０においてトリガが検出された場合の処理について図１７を用いて説明する。ネットワーク・プラットフォーム５０におけるサービスプログラム実行処理部５２０のトリガ検出部５２０１は、トリガとなるイベントの発生を探索しており、何らかのトリガが発生すると、当該トリガのデータを取得する（ステップＳ１８１）。そしてトリガ検出部５２０１は、当該トリガのデータをサービスプログラム特定部５２０２に出力する。サービスプログラム特定部５２０２は、サービスプログラムデータ格納部５２０３又はクライアントデータ格納部５１３を参照して、検出されたトリガが登録クライアントについてのトリガであるか判断する（ステップＳ１８３）。例えば図１１のようなデータテーブルにおける登録クライアントの列に登録されているクライアントであるか、若しくは図８又は図９に示すようなデータテーブルにおけるクライアントＩＤの列に登録されているクライアントであるかを判断する。もし、検出されたトリガが登録クライアントについてのトリガではないと判断された場合には処理を終了する。

一方、検出されたトリガが登録クライアントについてのトリガであると判断された場合には、サービスプログラム特定部５２０２は、サービスプログラムデータ格納部５２０３を参照して、当該検出されたトリガに関連するサービスプログラムが定義されているか判断する（ステップＳ１８５）。例えば、図１１のデータテーブルにおいて起動トリガの列に、検出されたトリガが登録されているか否かで判断する。もし、検出されたトリガに関連するサービスプログラムが定義されていないと判断された場合には、処理を終了する。そして、検出されたトリガに関連するサービスプログラムが定義されていると判断された場合には、サービスプログラム特定部５２０２は、実行すべきサービスプログラム（例えば検出されたトリガに対応するサービスＩＤ及びクライアントＩＤから特定）を保持しているか確認する（ステップＳ１８７）。

もし実行すべきサービスプログラムを保持している場合にはステップＳ１９３に移行する。一方、実行すべきサービスプログラムを保持していない場合には、サービスプログラム特定部５２０２は、ダウンロード部５２０５にダウンロードさせる。すなわち、ダウンロード部５２０５は、サービスプログラムデータ格納部５２０３に格納されている保管主体のデータから保管先を特定し、サービスプログラム要求を当該保管先に送信する（ステップＳ１８９）。クライアント端末７が保管先であれば、クライアント端末７の管理プログラム７１が、サービスプログラムデータ格納部７１７から、要求されたサービスプログラムを読み出し、ネットワーク・プラットフォーム５０に送信する。ダウンロード部５２０５は、クライアント端末７から要求に係るサービスプログラムを受信し、サービスプログラムデータ格納部５２０３に格納する（ステップＳ１９１）。

ステップＳ１８７において実行すべきサービスプログラムを保持していると判断された場合、又はステップＳ１９１の後に、サービスプログラムを実行させる（ステップＳ１９３）。必要に応じてサービスプログラムの処理結果はクライアント端末に送信される。

このようにすれば、迅速且つ適切にネットワーク・プラットフォーム５０においてサービスプログラムを実行することができる。なお、実行主体決定部５２０６については、再度クライアント端末又はネットワーク・プラットフォーム５０における特定のサーバの状態を調査してクライアント端末又は特定のサーバにおいてサービスプログラムを実行すべきか判断するようにしてもよいが、通常ネットワーク・プラットフォーム５０についてはクライアント端末より処理能力の余裕があるため、実行主体決定部５２０６を用いた処理を行わずともよい。

［サービスプログラムの具体的な処理態様］
（１）クライアント端末におけるサービスプログラムの実行（クライアント指示あり）
次に、クライアント端末７においてクライアントにより特定のサービスプログラムの実行が指示され、そのままクライアント端末７において特定のサービスプログラムを実行する場合について説明する。なお、最初に、図１８乃至図２０を用いて、前提となる、メッセージ及びパケットの組立、分解、及び振分方法について説明する。

図１８で示すように、サービスプログラム＃１又はサービスプログラム＃２は、動作データ（例えば特定の機能モジュールの起動要求及び必要なパラメータ）を生成すると、動作データをメッセージ組み立て機能モジュール７２に出力する。メッセージ組み立て機能モジュール７２に出力されるデータは、図１９（１）に示されるようなデータである。基本的には、動作データだけであるが、サービスプログラムを識別するために動作データと共にサービスＩＤが出力される場合もある。メッセージ組み立て機能モジュール７２は、さらに端末ＩＤ及びクライアントＩＤを付加してパケット組立部７３に出力する。すなわち、図１９（２）に示すようなデータがメッセージとして構成される。なお、メッセージ組立機能モジュール７２とパケット組立部７３とのインターフェースは、通常の通信インターフェースであり、パケット組立部７３は、特定の通信プロトコルに従って例えばネットワーク・アドレスを含むパケットヘッダを付加する。図１９（３）に示されるようなデータが生成される。

次に、ネットワーク・プラットフォーム５０においては、パケット分解部５２１が、特定の通信プロトコルに従ってクライアント端末からのパケットを受信して、当該パケットに含まれるメッセージ（動作データ、サービスＩＤ、端末ＩＤ及びクライアントＩＤ）を抽出し、通信インターフェースを介してメッセージ分解機能モジュール５２２に出力する。メッセージは図１９（４）に示されるようなデータである。メッセージ分解機能モジュール５２２は、メッセージを受け取ると、クライアントＩＤ、端末ＩＤ、サービスＩＤ及び動作データを分解して、クライアントＩＤ、端末ＩＤ、サービスＩＤを認証・認可機能モジュール５０１及び課金機能モジュール５０２に出力する。なお、応答の返信のため、パケット分解部５２１が、パケットヘッダに含まれるネットワーク・アドレスをメッセージ分解機能モジュール５２２に出力し、メッセージ分解機能モジュール５２２において、クライアントＩＤ、端末ＩＤ又はサービスＩＤに対応してネットワーク・アドレスを記憶装置に格納しておく場合もある。

認証・認可機能モジュール５０１は、クライアントデータ格納部５１３を参照して、クライアントＩＤ及びサービスＩＤを用いてサービス認可を行う。但し、従来どおり、クライアントＩＤ及び端末ＩＤにてネットワーク・プラットフォーム５０の利用可否を判断し、別途クライアントＩＤとパスワードなどのデータにより本人認証を行う。また、課金機能モジュール５０２は、主にクライアントＩＤを用いて課金処理を実施する。なお、サービスＩＤ等をさらに用いて課金処理を実施する場合もある。そうすると、例えば使用する機能毎に料金が異なる場合には、サービスＩＤから利用した機能を特定して機能毎の利用状況を特定して、請求を行うことができる。なお、端末ＩＤについては、複数の端末に同一のＩＤを付与したり、端末ＩＤにより特定のグループに属する端末であることを特定することができるため、端末ＩＤも、あるユーザグループが１つの端末を使用するときの課金に用いる場合もある。さらに、不特定多数のユーザの利用を想定した公共端末等の場合には、あるクライアントが定義したサービスを実行することを認可するか否かを端末ＩＤを用いて判断するようにしても良い。

なお、認証・認可機能モジュール５０１は、さらに、クライアントデータ格納部５１３を参照して、図８に示すようなクライアントＩＤと利用可能な機能モジュールのＩＤとの対応付けに基づき、動作データにおいて指定されている起動機能モジュールの利用可否を判断するようにしても良い。この際、起動機能モジュールの特定については、認証・認可機能モジュール５０１が行っても良いし、以下で述べるメッセージディスパッチャ５２３によって行っても良い。又は、図８のようなデータではなく、クライアントＩＤと登録サービスプログラム又は登録サービスプログラムにおいて定義されている全機能モジュールのＩＤ群との対応付けから判断する場合もある。

そして、クライアントＩＤ及びサービスＩＤによるサービス認可が得られると、メッセージ分解機能モジュール５２２は、図１９（５）及び（６）に示すように、動作データのみ、又は動作データ及びサービスＩＤをメッセージディスパッチャ５２３に出力する。メッセージディスパッチャ５２３は、動作データを解析して出力先の機能モジュールを特定して、当該機能モジュールに動作データを出力する。図１９（５）及び（６）に示すように、この際メッセージディスパッチャ５２３は、どのサービスプログラムによる要求であるかを識別するためサービスＩＤを付加して出力する場合もある。

なお、メッセージディスパッチャ５２３が、クライアントデータ格納部５１３（図８等）を参照して、動作データにおいて指定されている利用機能モジュールの利用可否を判断するようにしても良い。また、基本的には動作データには、利用（すなわち起動）される機能モジュールの指定が含まれるが、機能モジュールの指定を含まないようにして必要なパラメータのみを含むようにしても良い。このような場合には、例えばクライアントＩＤ及びサービスＩＤとサービスプログラム自体又はサービスプログラムにおいて定義されている全機能モジュールのＩＤ群との対応付けをサービスプログラムデータ格納部５２０３に登録しておき、クライアントＩＤ及びサービスＩＤにより特定されるサービスプログラムにおける状態を動作データに含まれるパラメータにて特定し、当該サービスプログラムにおける状態に応じてパラメータを出力すべき機能モジュールを特定するようにしてもよい。

このようにしてクライアント端末におけるサービスプログラムの要求がネットワーク・プラットフォーム５０における適切な機能モジュールに伝達される。

次に、ネットワーク・プラットフォーム５０からクライアント端末に応答を返す場合の処理を図２０を用いて説明する。まず、ネットワーク・プラットフォーム５０における機能モジュール＃１又は機能モジュール＃２は動作データ（処理結果）又は動作データ及びサービスＩＤをメッセージ組み立て機能モジュール５２４に出力する。出力されるデータは、図１９（１）と同様である。また、メッセージ組み立て機能モジュール５２４は、要求元クライアントを特定し、端末ＩＤ、クライアントＩＤをさらに付加してメッセージを構成し、パケット組立部５２５に出力する。構成されたメッセージは、図１９（２）に示したようなデータである。要求元クライアントの特定については、図１８のメッセージ分解機能モジュール５２２及びメッセージディスパッチャ５２３と連携することにより行うか、又は図９に示したデータ及びクライアントＩＤに対応して端末ＩＤ等が格納されているクライアントデータ格納部５１３を利用するなどにて行われる。そして、パケット組立部５２５は、クライアントＩＤ又は端末ＩＤに対応するネットワーク・アドレスを含むパケットヘッダを含むパケットを生成して、クライアント端末に送信する。送信されるパケットは、図１９（３）と同様である。

クライアント端末においては、パケット分解部７４は、図１９（３）のようなパケットを受信すると、パケットヘッダを取り除き、メッセージ部分をメッセージ分解機能モジュール７５に出力する。メッセージ部分の構成は図１９（４）と同様である。そして、メッセージ分解機能モジュール７５は、メッセージに含まれる動作データ、又は動作データ及びサービスＩＤを抽出し、メッセージディスパッチャ７６に出力する。この段階で出力されるデータは、図１９（５）又は（６）と同様である。メッセージディスパッチャ７６は、動作データを解析するか又はサービスＩＤに従って、サービスプログラム＃１又はサービスプログラム＃２に動作データ又は動作データ及びサービスＩＤを出力する。

このような処理を行うことにより、動作データが適切にクライアント端末とネットワーク・プラットフォーム間でやり取りされるようになる。なお、ネットワーク・アドレスと機能モジュールとは直接関係付けられていないので、ネットワーク・プラットフォーム５０における機能モジュールの追加や変更をわざわざクライアント端末に通知する必要はないというメリットもある。

次に、図１８乃至図２０に示したメッセージ及びパケットの組立、分解、及び振分方法を前提に、図２１乃至図２５を用いて、上でも述べたようにクライアントがクライアント端末７に対して特定のサービスプログラムの実行を指示した場合における、メッセージのやりとりについての具体的な処理フローを説明する。ここでは、例えばクライアント端末７におけるサービスプログラム＃１において、図２１に示すようなロジックが定義されているものとする。すなわち、最初に特定の端末（又はユーザ）についての状況理解としてコンテキスト管理機能モジュール＃ｃに対して問い合わせを行い、問い合わせへの応答に基づき状況判定を行い、特定の端末の状況が状況＃Ｘであれば機能モジュール＃ａを起動し、状況＃Ｙであれば機能モジュール＃ｂが起動されるように、サービスプログラム＃１が規定されているものとする。また、サービスＩＤが＃０７０３であり、端末ＩＤが＃９３６であり、クライアントＩＤが＃５３１であるものとする。

そうすると、クライアント端末７のサービスプログラム＃１等は、特定の端末についての状況理解を行うため、機能モジュール＃ｃの起動要求メッセージを生成し、メインメモリ等の記憶装置に格納する（ステップＳ２５１）。起動要求メッセージには、クライアントＩＤ”＃５３１”と端末ＩＤ”＃９３６”とサービスＩＤ”＃０７０３”と機能モジュール＃ｃの起動要求と特定の端末の識別情報（又は特定のユーザの識別情報）が含まれる。そして、クライアント端末７のパケット組立部７３は、生成された起動要求メッセージと宛先ネットワーク・アドレスを含むパケットを生成し、ネットワーク・プラットフォーム５０に送信する（ステップＳ２５３）。例えば、図２３の（１）に示すようなパケットが生成され、送信される。

一方ネットワーク・プラットフォーム５０のパケット分解部５２１は、クライアント端末７から機能モジュール＃ｃの起動要求メッセージを含むパケットを受信し、記憶装置に格納する（ステップＳ２５５）。そして、パケットから機能モジュール＃ｃの起動要求メッセージを抽出する（ステップＳ２５７）。また、上でも述べたように、メッセージ分解機能モジュール５２２は、起動要求メッセージに含まれるクライアントＩＤ、端末ＩＤ、サービスＩＤを抽出し、認証・認可機能モジュール５０１及び課金機能モジュール５０２に出力する。認証・認可機能モジュール５０１は、クライアントＩＤ及び端末ＩＤについて確認を行い、課金機能モジュール５０２は、課金処理を実施する（ステップＳ２５９）。さらに、認証・認可機能モジュール５０１は、サービスＩＤ及びクライアントＩＤを用いて当該機能モジュール＃ｃの起動要求を認可できるか確認する（ステップＳ２６１）。もし、ステップＳ２５９又はＳ２６１で問題が検出されれば、クライアント端末７に対して要求処理を実施できない旨のメッセージを返信する。一方、ステップＳ２５９及びＳ２６１で問題が検出されない場合には、メッセージ分解機能モジュール５２２から動作データ（ここでは機能モジュール＃ｃの起動要求及びパラメータ）又は動作データ及びサービスＩＤがメッセージディスパッチャ５２３に出力され、メッセージディスパッチャ５２３は、動作データを解析し、当該動作データを機能モジュール＃ｃにディスパッチする（ステップＳ２６３）。なお、起動であれば、必要なパラメータを渡して起動させる。

上でも述べたが、機能モジュール＃ｃを起動する前に、機能モジュール＃ｃ自体の利用可否（起動可否）を判断するようにしても良い。この場合には、クライアントデータ格納部５１３内の図８のようなデータを参照して判断しても良いし、さらに上で述べたようにサービスプログラムデータ格納部５２０３に格納された、クライアントＩＤとサービスプログラム自体又はサービスプログラムに規定されている機能モジュールのＩＤ群との対応付けを参照して判断しても良い。

機能モジュール＃ｃは、動作データに基づき処理を行い（ステップＳ２６５）、実行結果（ここでは”機能＃ｃ実行結果：状況Ｙ”（例えばユーザＡは携帯電話機を持って電車に乗っている））を含む動作データを生成し、当該動作データ又は動作データ及びサービスＩＤを、メッセージ組み立て機能モジュール５２４に出力する。メッセージ組み立て機能モジュール５２４は、クライアントＩＤ”＃５３１”、端末ＩＤ”＃９３６”及びサービスＩＤ”＃０７０３”を付加してメッセージを生成し（ステップＳ２６７）、パケット組立部５２５は、実行結果を含むメッセージにパケットヘッダを付加してパケットを生成し、クライアント端末７に送信する（ステップＳ２６９）。本ステップで送信されるパケットは、例えば図２３（２）のようなパケットである。

クライアント端末７のパケット分解部７４は、ネットワーク・プラットフォーム５０から実行結果メッセージを含むパケットを受信し、例えばメインメモリ等の記憶装置に格納する（ステップＳ２７１）。処理は端子Ｂを介して図２４に移行する。そして、パケット分解部７４は、実行結果メッセージ部分を抽出してメッセージ分解機能モジュール７５に出力する（ステップＳ２７３）。メッセージ分解機能モジュール７５は、実行結果メッセージから実行結果を含む動作データ又は動作データ及びサービスＩＤを抽出し、メッセージディスパッチャ７６に出力し、メッセージディスパチャ７６は、動作データを動作データの要求元であるサービスプログラム＃１に出力する。

サービスプログラム＃１は、動作データに含まれる実行結果を解析し、図２１のようなサービスプログラムであれば状況判定を行う（ステップＳ２７５）。図２３（２）の例では、状況＃Ｙであることが分かるので、機能モジュール＃ｂを起動させることになる。例えば、ＳＩＰを用いてＶｏＩＰ（Voice Over IP）にて発呼する。従って、サービスプログラム＃１は、解析結果に従って、機能モジュール＃ｂの起動要求メッセージを生成し（ステップＳ２７７）、メインメモリ等の記憶装置に格納する。起動要求メッセージには、クライアントＩＤ”＃５３１”と端末ＩＤ”＃９３６”とサービスＩＤ”＃０７０３”と機能モジュール＃ｂの起動要求と発呼先ＳＩＰ−ＵＲＬ等のパラメータとが含まれる。そして、クライアント端末７のパケット組立部７３は、生成された起動要求メッセージと宛先ネットワーク・アドレスを含むパケットを生成し、ネットワーク・プラットフォーム５０に送信する（ステップＳ２７９）。例えば、図２３の（３）に示すようなパケットが生成され、送信される。

一方ネットワーク・プラットフォーム５０のパケット分解部５２１は、クライアント端末７から機能モジュール＃ｂの起動要求メッセージを含むパケットを受信し、記憶装置に格納する（ステップＳ２８１）。そして、パケットから機能モジュール＃ｂの起動要求メッセージを抽出する（ステップＳ２８３）。また、上でも述べたように、メッセージ分解機能モジュール５２２は、起動要求メッセージに含まれるクライアントＩＤ、端末ＩＤ、サービスＩＤを抽出し、認証・認可機能モジュール５０１及び課金機能モジュール５０２に出力する。認証・認可機能モジュール５０１は、クライアントＩＤ及び端末ＩＤについて確認を行い、課金機能モジュール５０２は、課金処理を実施する（ステップＳ２８５）。さらに、認証・認可機能モジュール５０１は、サービスＩＤ及びクライアントＩＤを用いて当該機能モジュール＃ｂの起動要求を認可できるか確認する（ステップＳ２８７）。もし、ステップＳ２８５又はＳ２８７で問題が検出されれば、クライアント端末７に対して要求処理を実施できない旨のメッセージを返信する。一方、ステップＳ２８５及びＳ２８７で問題が検出されない場合には、メッセージ分解機能モジュール５２２から動作データ（ここでは機能モジュール＃ｂの起動要求及びパラメータ）又は動作データ及びサービスＩＤがメッセージディスパッチャ５２３に出力され、メッセージディスパッチャ５２３は、動作データを解析し、当該動作データを機能モジュール＃ｂにディスパッチする（ステップＳ２８９）。なお、起動であれば、必要なパラメータを渡して起動させる。上でも述べたようにこの段階にても機能起動の可否を判断するようにしても良い。

機能モジュール＃ｂは、動作データに基づき処理を行い（ステップＳ２９１）、実行結果（ここでは”機能＃ｂ実行結果”）を含む動作データを生成し、当該動作データ又は動作データ及びサービスＩＤを、メッセージ組み立て機能モジュール５２４に出力する。処理は端子Ｃを介して図２５の処理に移行する。

そして、メッセージ組み立て機能モジュール５２４は、クライアントＩＤ”＃５３１”、端末ＩＤ”＃９３６”及びサービスＩＤ”＃０７０３”を付加してメッセージを生成し（ステップＳ２９３）、パケット組立部５２５は、実行結果を含むメッセージにパケットヘッダを付加してパケットを生成し、クライアント端末７に送信する（ステップＳ２９５）。本ステップで送信されるパケットは、例えば図２３（４）のようなパケットである。

クライアント端末７のパケット分解部７４は、ネットワーク・プラットフォーム５０から実行結果メッセージを含むパケットを受信し、例えばメインメモリ等の記憶装置に格納する（ステップＳ２９７）。そして、パケット分解部７４は、実行結果メッセージ部分を抽出してメッセージ分解機能モジュール７５に出力する（ステップＳ２９９）。メッセージ分解機能モジュール７５は、実行結果メッセージから実行結果を含む動作データ又は動作データ及びサービスＩＤを抽出し、メッセージディスパッチャ７６に出力し、メッセージディスパッチャ７６は、動作データを動作データの要求元であるサービスプログラム＃１に出力する。

サービスプログラム＃１は、動作データに含まれる実行結果を解析し（ステップＳ３０１）、解析結果に従って必要な処理を実施する（ステップＳ３０３）。

このようにサービスＩＤが付加されたメッセージがやりとりされて、サービスプログラムに従って処理が行われていく。

（２）クライアント端末におけるサービスプログラムの実行（クライアントの指示なし）
次に図２６及び図２７を用いて、サービスプログラム実行処理部７１０が動作することによりクライアント端末７においてサービスプログラムが実行される場合の処理を説明する。クライアント端末であるＰＤＡ（Personal Digital Assistant）は、そのプロセッサの処理能力が低いが、ＲＦＩＤ（Radio Frequency ID。ＩＣタグとも呼ぶ）リーダを有しており、当該ＲＦＩＤリーダによりＩＤを読み取ることによりサービスプログラムが実行されるものとする。サービスプログラムは、図２６に示すようなロジックを含むプログラムであるものとする。すなわち、まずＩＤを読み取り、ＩＤに対応するＵＲＬ（Uniform Resource Locator）が既知であるか判断する。もし、ＩＤに対応するＵＲＬを既に保持している場合にはサーバアクセスを実施する。一方、ＩＤに対応するＵＲＬを保持していない場合、アドレス解決処理を実施し、取得したアドレスを用いてサーバにアクセスする。

次に図２７を用いてシステム全体の処理の流れを説明する。クライアント端末であるＰＤＡのＲＦＩＤリーダにおいてＩＤを読み取ると、サービスプログラム実行処理部７１０のトリガ検出部７１１は、トリガ発生を検出し、サービスプログラム特定部７１２はサービスプログラムデータ格納部７１７を参照して実行すべきサービスプログラムを特定する。ここでは図２６に示したようなサービスプログラムが特定されるものとする。そして、当該サービスプログラムがサービスプログラムデータ格納部７１７に格納されていると、サービスプログラム特定部７１２は、サービスプログラムを実行させる。ここでは読み取ったＩＤに対応するＵＲＬが不明であるものとする。そうすると、サービスプログラムにおけるアドレス解決処理として、読み取ったＩＤ及びアドレス解決処理モジュール５３１のＩＤを含むメッセージをネットワーク・プラットフォーム５０に送信する（ステップ（１））。ネットワーク・プラットフォーム５０のアドレス解決機能モジュール５３１は、クライアント端末であるＰＤＡから受信したＩＤを受け取り、ｕｃｏｄｅ解決サーバにＩＤを含むサイト検索要求を送信する（ステップ（２））。ｕｃｏｄｅ解決サーバは、ＩＤを基にＵＲＬを検索し、ＵＲＬを含む応答メッセージをネットワーク・プラットフォーム５０に返信する（ステップ（３））。ネットワーク・プラットフォーム５０のアドレス解決機能モジュール５３１は、ｕｃｏｄｅ解決サーバからＵＲＬを含む応答メッセージを受信し、処理結果としてＵＲＬを含むメッセージをクライアント端末であるＰＤＡに返信する（ステップ（４））。クライアント端末であるＰＤＡにおけるサービスプログラムは、ネットワーク・プラットフォーム５０からＵＲＬを含むメッセージを受信すると、ＵＲＬに基づくサーバアクセスを実施する。例えば、受信したＵＲＬ及びＨＴＴＰ（Hyper Text Transfer Protocol）機能モジュール５３２のＩＤを含むメッセージをネットワーク・プラットフォーム５０に送信する（ステップ（５））。

ネットワーク・プラットフォーム５０のＨＴＴＰ（Hyper Text Transfer Protocol）機能モジュール５３２は、クライアント端末であるＰＤＡからＵＲＬを受信し、ＵＲＬで指定されるＷｅｂサーバに対してＧＥＴメッセージを送信する（ステップ（６））。Ｗｅｂサーバは、ネットワーク・プラットフォーム５０からＧＥＴリクエストを受信し、当該ＧＥＴリクエストに対するレスポンスとしてＨＴＭＬファイル等を、ネットワーク・プラットフォーム５０に返信する（ステップ（７））。ネットワーク・プラットフォーム５０のＨＴＴＰ機能モジュール５３２は、ＷｅｂサーバからＨＴＭＬファイル等を含むレスポンスを受信し、さらにクライアント端末であるＰＤＡに転送する（ステップ（８））。クライアント端末であるＰＤＡのサービスプログラムは、ネットワーク・プラットフォーム５０からＨＴＭＬファイル等のレスポンスを受信すると、Ｗｅｂブラウザなどの機能モジュールを起動させ、受信したＨＴＭＬファイルなどを表示させる。

このようにクライアント端末においてトリガが発生した場合にサービスプログラムをクライアント端末で実行し、ネットワーク・プラットフォーム５０からネットワーク・サービスとして、アドレス解決及びＨＴＴＰ機能の提供を受けることができる。

（３）クライアント端末からのネットワーク・プラットフォームへのサービスプログラムの実行委託
次にクライアント端末であるＰＤＡの余剰処理能力が足りないために、ＰＤＡが有するＲＦＩＤリーダによりＩＤを読み取った場合に、クライアント端末であるＰＤＡでは当該読み取ったＩＤを処理するサービスプログラムを実行できない場合を図２８を用いて説明する。

クライアント端末であるＰＤＡのＲＦＩＤリーダにおいてＩＤを読み取ると、サービスプログラム実行処理部７１０のトリガ検出部７１１はトリガ発生を検出し、サービスプログラム特定部７１２はサービスプログラムデータ格納部７１７を参照して実行すべきサービスプログラムを特定する。ここでは図２６に示したようなサービスプログラムが特定されるものとする。そして、第２実行主体決定部７１３は、実負荷時性能が所定の閾値以下であると判断し、実行委任処理部７１８を起動する。実行委任処理部７１８は、検出されたトリガのデータ及び当該トリガを取り扱うサービスプログラムのサービスＩＤを含む実行委託要求メッセージをネットワーク・プラットフォーム５０に送信する（ステップ（１））。

ネットワーク・プラットフォーム５０におけるサービスプログラム実行処理部５２０の実行受託処理部５２０４は、クライアント端末であるＰＤＡから、検出されたトリガのデータ及びサービスプログラムのサービスＩＤを含む実行委任要求を受信すると、サービスプログラムデータ格納部５２０３を参照してサービスＩＤで特定されるサービスプログラムを保持しているか確認する。そしてサービスＩＤで特定されるサービスプログラムを保持していない場合には、実行受託処理部５２０４はダウンロード部５２０５に保管先のクライアント端末であるＰＤＡに対して実行すべきサービスプログラムのサービスＩＤを含むサービスプログラム要求を送信させる（ステップ（２））。クライアント端末であるＰＤＡにおける管理プログラム７１は、サービスプログラム要求を受信すると、サービスプログラムデータ格納部７１７から要求に係るサービスプログラムを読み出し、ネットワーク・プラットフォーム５０に返信する（ステップ（３））。ネットワーク・プラットフォーム５０におけるサービスプログラム実行処理部５２０のダウンロード部５２０５は、クライアント端末であるＰＤＡからサービスプログラムを受信する。そして、実行受託処理部５２０４は、サービスプログラム５３３を実行させると共に、当該サービスプログラム５３３に対して予め受信しているトリガのデータをサービスプログラム５３３に出力する（ステップ（４））。

サービスプログラム５３３は、図２６に示したロジックに従って、アドレス解決機能モジュール５３１を起動すると共に、トリガのデータであるＲＦＩＤのＩＤを出力する（ステップ（５））。アドレス解決機能モジュール５３１は、サービスプログラム５３３からＩＤを受け取り、ｕｃｏｄｅ解決サーバにＩＤを含むサイト検索要求を送信する（ステップ（７））。ｕｃｏｄｅ解決サーバは、受信したＩＤを基にＵＲＬを検索し、ＵＲＬを含む応答メッセージをネットワーク・プラットフォーム５０に返信する（ステップ（８））。ネットワーク・プラットフォーム５０のアドレス解決機能モジュール５３１は、ｕｃｏｄｅ解決サーバからＵＲＬを含む応答メッセージを受信し、処理結果としてＵＲＬをサービスプログラムに出力する（ステップ（９））。ネットワーク・プラットフォーム５０において実行されているサービスプログラム５３３は、アドレス解決機能モジュール５３１からＵＲＬを受信すると、ＵＲＬに基づくサーバアクセスを実施する。例えば、ＨＴＴＰ機能モジュール５３２を起動すると共に、受け取ったＵＲＬを出力する（ステップ（１０））。

ネットワーク・プラットフォーム５０のＨＴＴＰ機能モジュール５３２は、ＵＲＬを受け取り、ＵＲＬで指定されるＷｅｂサーバに対してＧＥＴメッセージを送信する（ステップ（１１））。Ｗｅｂサーバは、ネットワーク・プラットフォーム５０からＧＥＴリクエストを受信し、当該ＧＥＴリクエストに対するレスポンスとしてＨＴＭＬファイル等を、ネットワーク・プラットフォーム５０に返信する（ステップ（１２））。ＨＴＴＰ機能モジュール５３２は、ＷｅｂサーバからＨＴＭＬファイル等を含むレスポンスを受信し、サービスプログラムに出力する（ステップ（１３））。ネットワーク・プラットフォーム５０において実行されているサービスプログラム５３３は、ＨＴＭＬファイル等のレスポンスを受け取ると、処理結果であるＨＴＭＬファイル等のレスポンスを実行受託処理部５２０４に出力する（ステップ（１４））。

実行受託処理部５２０４は、サービスプログラムから処理結果であるＨＴＭＬファイル等のレスポンスをクライアント端末であるＰＤＡに送信する（ステップ（１５））。クライアント端末であるＰＤＡの実行委任処理部７１８は、処理結果であるＨＴＭＬファイル等のレスポンスを受信し、Ｗｅｂブラウザなどの機能モジュールを起動させ、受信したＨＴＭＬファイルなどを表示させる。

このようにＰＤＡ等のクライアント端末が他のジョブで処理余力を有しない場合であっても、ネットワーク・プラットフォーム５０に実行を委託することができ、ネットワーク・プラットフォーム５０では委託されたサービスプログラムの実行を行い、処理結果をＰＤＡ等のクライアント端末に返すことができる。すなわち、クライアント端末でサービスプログラムを実行したのと同様の処理結果を得ることができる。

なお、アドレス解決機能モジュール５３１の処理結果であるＵＲＬをサービスプログラム５３３に一旦戻し、サービスプログラム５３３からＨＴＴＰ機能モジュール５３２を起動させる構成を示しているが、アドレス解決機能モジュール５３１の機能としてアドレス解決機能モジュール５３１がＨＴＴＰ機能モジュール５３２と直接やりとりを行うようにしてもよい。これは図２７についてのケースでも同様である。

（４）ネットワーク・プラットフォーム５０においてトリガを検出し、サービスプログラムを実行する場合
例えば図２９のようなサービスプログラムの場合には、ネットワーク・プラットフォーム５０におけるサービスプログラム実行処理部５２０のトリガ検出部５２０１がトリガである電話の着信を検出し、サービスプログラム特定部５２０２がサービスプログラムを実行させる。

図２９の例では、特定のクライアントについての着信に応じて、当該特定のクライアントについてのコンテキスト取得（状態取得）処理を実施する。その結果として、特定のクライアントが在席中であって話中であれば、留守番電話機能モジュール等にメッセージの蓄積処理を行わせる。一方、特定のクライアントが在席中であって取り込み中であれば、メール送信機能モジュール等にメール送信処理を行わせる。さらに、特定のクライアントが在席中であって取り込み中でもない場合には、特定のクライアントの電話機に着信させるため例えばＳＩＰ機能モジュールに処理を実施させる。一方、特定のクライアントが在席中ではなく離席中である場合には、メール送信機能モジュール等にメール送信処理を行わせる。また、特定のクライアントが在席中ではなく外出中（離席中ではない）であり、本日が休日であれば、留守番電話機能モジュール等にメッセージの蓄積処理を行わせる。一方、特定のクライアントが在席中ではなく外出中であり、本日が平日であれば、転送機能モジュール等に、予め定められた特定のクライアントの携帯電話機に着信を転送させる。

このような場合には、ネットワーク・プラットフォーム５０においてサービスプログラムの処理は完結しており、特定のクライアントのクライアント端末では、サービスプログラムとは関係なく保持している機能モジュールを用いてネットワーク・サービスの提供を受ける。

以上のように、ネットワークサービス提供のための各種ＡＰＩが用意されており、クライアント端末のユーザ又はソフトウエア開発者は、必要に応じて機能モジュールを組み合わせて使用するようなサービスプログラムを作成することができる。さらに、特定のサービスを利用する場合にはサービスプログラムだけを用意すればよいので、特定のサービス全体をシステム化するより開発工数及び期間を減らすことができる。また、サービスプログラム自身の更新は容易であり、ネットワーク・プラットフォーム５０側の機能モジュールが更新されれば全てのクライアントが改良された機能を利用可能となる。さらに、必要に応じてクライアント端末には機能モジュールをダウンロードできるため、元々機能をあまり有さない端末であっても多様な、また高度なサービスを利用することができるようになる。

また、サービスプログラムの実行主体は、サービスプログラムの登録（定義）時に、サービスプログラムとクライアント端末との関係から、クライアント端末又はネットワーク・プラットフォーム５０に設定される。しかし、サービスプログラムの実行時に再度他のジョブなどに悪影響を及ぼすことなく実行可能であるかを確認して、さらに実行主体を決定するため、サービスプログラムの適切な実行を行うことができる。また、保管主体についても、トリガの検出場所、クライアント端末又はサービスプログラムの使用状況に応じて決定されるため、柔軟且つ適切な実行も可能となる。

なお、クライアントが複数のクライアント端末を使用しているような場合、ネットワーク・プラットフォーム５０の所定のストレージに使用するサービスプログラムを保管しておき、クライアントの指示により、現在使用中のクライアント端末にダウンロードしてから当該サービスプログラムを実行させるようにしても良い。

以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、ＳＭＩを介したサービスプログラムの作成処理について説明したが、別途ネットワーク・プラットフォーム５０において提供される機能モジュールの詳細などを入手することができれば、別途入手した情報に基づきサービスプログラムを作成するようにしても良い。また、サービスプログラムの登録についてもネットワークを介さずに、別途確認及び登録するような手順を採用する場合もある。

また、ネットワーク・プラットフォーム５０は、１台のコンピュータにより実現せずに複数台のコンピュータにより機能分担したり、一部の機能については並列又は分散処理を実施する場合もある。

また、サービス認可についてはメッセージに他のデータ（例えば、サービスプログラムの改ざんがなされていないことを照明するデータ（ハッシュ値又は電子証明書など））を付加して確認する場合もある。

さらに、ネットワーク・プラットフォーム５０における機能モジュール毎に、利用可能なクライアントを規定しておき、クライアントＩＤと動作データに含まれる利用機能モジュールＩＤとを用いて、機能モジュール毎に利用の可否を判断するようにしてもよい。また、図８に示したようなクライアントＩＤと機能モジュールＩＤとの対応テーブルのみを用いて機能モジュールの利用可否を判断しても良い。

さらに、図３及び図４に示した機能ブロック図は一例であって、必ずしも実際のプログラム・モジュールに対応しない場合もある。

なお、ネットワーク・プラットフォーム５０を実現する１又は複数のコンピュータ及びクライアント端末は、コンピュータ装置であって、図３０に示すように、メモリ２５０１（記憶装置）とＣＰＵ２５０３（処理装置）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施の形態における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施の形態では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

（付記１）
ネットワーク・プラットフォーム側で提供される機能のうちクライアントによって利用される機能の組み合わせ方が定義されているサービスプログラムに関する情報処理方法であって、
前記サービスプログラムを解析して、前記サービスプログラムを起動させるトリガの検出がクライアント端末であるかネットワーク・プラットフォーム側であるか判断するステップと、
前記サービスプログラムを起動させるトリガの検出がクライアント端末であると判断された場合、前記サービスプログラムとクライアント端末との関係に関する条件が満たされているか判断するステップと、
前記条件が満たされていると判断された場合には、前記サービスプログラムの実行主体をクライアント端末として決定するステップと、
を含み、コンピュータにより実行される情報処理方法。

（付記２）
前記条件が、前記サービスプログラムにおいて単一のクライアント端末に関連する処理が規定されているという条件を含むことを特徴とする付記１記載の情報処理方法。

（付記３）
前記条件が、前記サービスプログラムがクライアント端末に生じさせる処理負荷と当該クライアント端末の処理能力との関係についての条件を含むことを特徴とする付記１記載の情報処理方法。

（付記４）
前記クライアント端末の処理能力が、無負荷時の処理能力であることを特徴とする付記１記載の情報処理方法。

（付記５）
前記サービスプログラムを起動させるトリガの検出がネットワーク・プラットフォーム側と判断された場合又は前記条件が満たされていないと判断された場合に、前記サービスプログラムの実行主体をネットワーク・プラットフォームとして決定するステップと、
実行主体がネットワーク・プラットフォームであると決定されたサービスプログラムを、前記ネットワーク・プラットフォーム側に保管させるステップと、
をさらに含む付記１記載の情報処理方法。

（付記６）
前記サービスプログラムの実行主体をクライアント端末として決定した場合、当該サービスプログラム又は前記クライアント端末の想定される使用状況に関するデータに応じて、当該サービスプログラムの保管先をクライアント端末のみ又は当該クライアント端末及び前記ネットワーク・プラットフォームの両方のいずれかに決定するステップ
をさらに含む付記１記載の情報処理方法。

（付記７）
前記想定される使用状況に関するデータが、前記サービスプログラムの共用の有無と、前記サービスプログラム又は前記クライアント端末を複数箇所で使用するか否かとのうち少なくともいずれかのデータを含む付記６記載の情報処理方法。

（付記８）
ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせ方に関し前記クライアント側で定義され且つ前記ネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムに関する情報処理方法であって、
特定のトリガを検出するステップと、
前記特定のトリガに対応する前記サービスプログラムを特定するステップと、
特定された前記サービスプログラムの実行が前記クライアント端末に所定レベル以上影響を与えるか判断する判断ステップと、
特定された前記サービスプログラムの実行が前記クライアント端末に所定レベル以上影響を与えることがないと判断された場合には、当該特定された前記サービスプログラムを実行させるステップと、
を含み、クライアント端末により実行される情報処理方法。

（付記９）
特定された前記サービスプログラムが前記クライアント端末に所定レベル以上影響を与えると判断された場合には、前記特定のトリガに関するデータ及び前記サービスプログラムの識別情報を含む実行要求を前記ネットワーク・プラットフォームに送信するステップと、
前記ネットワーク・プラットフォームから前記サービスプログラムによる処理結果を受信するステップと、
をさらに含む付記８記載の情報処理方法。

（付記１０）
特定された前記サービスプログラムの実行が前記クライアント端末に所定レベル以上影響を与えることはないと判断された場合には、当該特定された前記サービスプログラムを保持しているか判断するステップと、
特定された前記サービスプログラムを保持していないと判断された場合には、前記ネットワーク・プラットフォームからダウンロードするステップと、
をさらに含む付記８記載の情報処理方法。

（付記１１）
前記判断ステップにおいて、
前記サービスプログラムが前記クライアント端末に生じさせる処理負荷と前記クライアント端末の処理能力との関係が所定の条件を満たしているか判断する
ことを特徴とする付記８記載の情報処理方法。

（付記１２）
前記クライアント端末の処理能力が、現在の余裕処理能力であることを特徴とする付記１１記載の情報処理方法。

（付記１３）
ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせ方に関し前記クライアント側で定義され且つ前記ネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムに関する情報処理方法であって、
トリガを検出するステップと、
検出された前記トリガが取扱可能なトリガであるか判断する判断ステップと、
検出された前記トリガが取扱可能なトリガであると判断された場合、検出された前記トリガに対応するサービスプログラムを特定するステップと、
特定された前記サービスプログラムを実行するステップと、
を含み、ネットワーク・プラットフォームにより実行される情報処理方法。

（付記１４）
前記判断ステップが、
検出された前記トリガが、前記ネットワーク・プラットフォームを利用可能なクライアントに関連するトリガであるか判断するステップと、
検出された前記トリガが前記ネットワーク・プラットフォームを利用可能なクライアントに関連するトリガであると判断された場合、検出された前記トリガに関連するサービスプログラムが定義されているか確認するステップと、
を含む付記１３記載の情報処理方法。

（付記１５）
付記１乃至１４のいずれか１つ記載の情報処理方法をコンピュータに実行させるためのプログラム。

（付記１６）
ネットワーク・プラットフォーム側で提供される機能のうちクライアントによって利用される機能の組み合わせ方が定義されているサービスプログラムに関する情報処理を行うコンピュータであって、
前記サービスプログラムを解析して、前記サービスプログラムを起動させるトリガの検出がクライアント端末であるかネットワーク・プラットフォーム側であるか判断する手段と、
前記サービスプログラムを起動させるトリガの検出がクライアント端末であると判断された場合、前記サービスプログラムとクライアント端末との関係に関する条件が満たされているか判断する手段と、
前記条件を満たしていると判断された場合には、前記サービスプログラムの実行主体をクライアント端末として決定する手段と、
を有するコンピュータ。

（付記１７）
ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせ方に関し前記クライアント側で定義され且つ前記ネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムに関する情報処理を実施する端末装置であって、
特定のトリガを検出する手段と、
前記特定のトリガに対応する前記サービスプログラムを特定する手段と、
特定された前記サービスプログラムの実行が前記クライアント端末に所定レベル以上影響を与えるか判断する判断手段と、
特定された前記サービスプログラムの実行が前記クライアント端末に所定レベル以上影響を与えることはないと判断された場合には、当該特定された前記サービスプログラムを実行させる手段と、
を有する端末装置。

（付記１８）
ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせ方に関し前記クライアント側で定義され且つ前記ネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムに関するコンピュータ・システムであって、
トリガを検出する手段と、
検出された前記トリガが取扱可能なトリガであるか判断する判断手段と、
検出された前記トリガが取扱可能なトリガであると判断された場合、検出された前記トリガに対応するサービスプログラムを特定する手段と、
特定された前記サービスプログラムを実行する手段と、
を有するコンピュータ・システム。

本発明の実施の形態に係る機能ブロック図である。 （ａ）はＳＭＩにおける標準パケット、（ｂ）はＳＣＩにおける標準パケットを表す図である。 ネットワーク・プラットフォームにおける機能ブロック図である。 クライアント端末における機能ブロック図である。 サービスプログラム登録処理の処理フローを示す図である。 サービスプログラム作成時にクライアント端末に表示される画面の一例を示す図である。 ネットワーク・プラットフォーム側で実行主体及び保管主体を決定する場合の処理フローを示す図である。 クライアントデータ格納部に格納されるデータの一例を示す図である。 クライアントデータ格納部に格納されるデータの一例を示す図である。 サービスプログラム登録時における実行主体決定処理の処理フローを示す図である。 ネットワーク・プラットフォーム側のサービスプログラムデータ格納部に格納されるデータの一例を示す図である。 保管主体決定処理の処理フローを示す図である。 クライアント端末におけるサービスプログラムデータ格納部に格納されるデータの一例を示す図である。 クライアント端末側で実行主体及び保管主体を決定する場合の処理フローを示す図である。 クライアント端末においてトリガを検出した場合の処理フローを示す図である。 ネットワーク・プラットフォーム側の実行受託処理の処理フローを示す図である。 ネットワーク・プラットフォーム側でトリガを検出した場合の処理フローを示す図である。 クライアント端末からネットワーク・プラットフォームに送られるデータの処理概要を示す図である。 （１）乃至（６）は各段階におけるデータの一例を示す図である。 ネットワーク・プラットフォームからクライアント端末に送られるデータの処理概要を示す図である。 サービスプログラムの一例を示す図である。 ＳＣＩを介してサービスを利用する際の処理フローを示す図である。 （１）乃至（４）はＳＣＩを介してサービスを利用する際に送信されるデータの一例を示す図である。 ＳＣＩを介してサービスを利用する際の処理フローを示す図である。 ＳＣＩを介してサービスを利用する際の処理フローを示す図である。 サービスプログラムのロジックの一例を示す図である。 クライアント端末であるＰＤＡにより図２６のサービスプログラムを処理する場合の処理フローを示す図である。 ネットワーク・プラットフォームに図２６のサービスプログラムの処理が委任された場合の処理フローを示す図である。 サービスプログラムのロジックの一例を示す図である。 コンピュータの機能ブロック図である。

符号の説明

１ オープンネットワーク ３ ゲートウェイ ５ サービス提供ネットワーク
７，９ クライアント端末 ５０ ネットワーク・プラットフォーム
７１，９１ 管理プログラム
５０１ 認証・認可機能モジュール ５０２ 課金機能モジュール
５０３ クライアント管理機能モジュール ５０４ セッション制御機能モジュール
５０５ コンテキスト管理機能モジュール ５０６ メディア変換機能モジュール

Claims (5)

1. ネットワーク・プラットフォーム側で提供される機能のうちクライアントによって利用される機能の組み合わせ方が定義されているサービスプログラムに関する情報処理方法であって、
   前記サービスプログラムを解析して、前記サービスプログラムを起動させるトリガの検出がクライアント端末であるかネットワーク・プラットフォーム側であるか判断するステップと、
   前記サービスプログラムを起動させるトリガの検出がクライアント端末であると判断された場合、前記サービスプログラムとクライアント端末との関係に関する条件が満たされているか判断するステップと、
   前記条件が満たされていると判断された場合には、前記サービスプログラムの実行主体をクライアント端末として決定するステップと、
   を含み、コンピュータにより実行される情報処理方法。
2. 前記サービスプログラムを起動させるトリガの検出がネットワーク・プラットフォーム側と判断された場合又は前記条件が満たされていないと判断された場合に、前記サービスプログラムの実行主体をネットワーク・プラットフォームとして決定するステップと、
   実行主体がネットワーク・プラットフォームであると決定されたサービスプログラムを、前記ネットワーク・プラットフォーム側に保管させるステップと、
   をさらに含む請求項１記載の情報処理方法。
3. ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせ方に関し前記クライアント側で定義され且つ前記ネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムに関する情報処理方法であって、
   特定のトリガを検出するステップと、
   前記特定のトリガに対応する前記サービスプログラムを特定するステップと、
   特定された前記サービスプログラムの実行が前記クライアント端末に所定レベル以上影響を与えるか判断する判断ステップと、
   特定された前記サービスプログラムの実行が前記クライアント端末に所定レベル以上影響を与えることがないと判断された場合には、当該特定された前記サービスプログラムを実行させるステップと、
   を含み、クライアント端末により実行される情報処理方法。
4. 特定された前記サービスプログラムが前記クライアント端末に所定レベル以上影響を与えると判断された場合には、前記特定のトリガに関するデータ及び前記サービスプログラムの識別情報を含む実行要求を前記ネットワーク・プラットフォームに送信するステップと、
   前記ネットワーク・プラットフォームから前記サービスプログラムによる処理結果を受信するステップと、
   をさらに含む請求項３記載の情報処理方法。
5. ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせ方に関し前記クライアント側で定義され且つ前記ネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムに関する情報処理方法であって、
   トリガを検出するステップと、
   検出された前記トリガが取扱可能なトリガであるか判断する判断ステップと、
   検出された前記トリガが取扱可能なトリガであると判断された場合、検出された前記トリガに対応するサービスプログラムを特定するステップと、
   特定された前記サービスプログラムを実行するステップと、
   を含み、ネットワーク・プラットフォームにより実行される情報処理方法。

Images