サービス処理方法及びプログラム
【課題】
ネットワーク・サービスの柔軟且つ適切な提供を可能にする。
【解決手段】
本発明では、サービス提供ネットワーク5によりネットワーク・プラットフォームＮＰ50を実現する。このＮＰ50は、認証・認可、課金、クライアント(CT)管理といった共通機能と、セッション制御などの個別機能がオープンネットワーク1に接続されるＣＴに提供される。ＣＴは、サービス管理インターフェースＳＭＩを介してＮＰにおける機能を利用するためのサービスプログラムを作成・登録する。そして、サービスプログラムを実行することにより、サービス制御インターフェースＳＣＩを介して特定の機能に対するサービス要求をＮＰ50に送信すると共に、ＮＰ50の特定の機能から実行結果を取得する。
ネットワーク・サービスの柔軟且つ適切な提供を可能にする。
【解決手段】
本発明では、サービス提供ネットワーク5によりネットワーク・プラットフォームＮＰ50を実現する。このＮＰ50は、認証・認可、課金、クライアント(CT)管理といった共通機能と、セッション制御などの個別機能がオープンネットワーク1に接続されるＣＴに提供される。ＣＴは、サービス管理インターフェースＳＭＩを介してＮＰにおける機能を利用するためのサービスプログラムを作成・登録する。そして、サービスプログラムを実行することにより、サービス制御インターフェースＳＣＩを介して特定の機能に対するサービス要求をＮＰ50に送信すると共に、ＮＰ50の特定の機能から実行結果を取得する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークサービスの提供技術に関する。
【背景技術】
【０００２】
インターネットに接続されているサーバ上に用意されたアプリケーションを、複数のユーザに使用させるサービスが存在している。このようなサービスにおいて、サーバ上のプログラムの組み合わせ方（ユーザ側から見れば使い方）はサービスの提供者により予め決められており、ユーザは、サーバ上の複数のプログラムを自由に組み合わせて使用することはできない。
【０００３】
例えば特開２０００−２３６３２６号公報には、ソフトウェアのメンテナンスを不要とし、相互通信サービスの利用時におけるソフトウェアの起動に関する制御等を不要とするための技術が開示されている。具体的には、クライアントはサーバアクセス用及び個人認証用の最小限のモジュールを保持する軽装端末とし、サーバは、軽装端末の動作に必要な共通ミドルウェア及びアプリケーションソフトウェアを保持するとともに、これらを管理する管理プログラムを有する管理サーバと、軽装端末との間で個人認証を行う認証サーバとして、各軽装端末は電源投入時及びサービス利用時に必要なソフトウェアを管理サーバからダウンロードするものである。このように必要なプログラムをクライアントにダウンロードするだけでは、多様なサービスの提供は不可能である。
【０００４】
また、例えば特開２０００−３４７９５８号公報には、データ通信量を低減させるとともに、コンピュータメモリの使用容量を節約するための技術が開示されている。具体的には、サーバが、クライアントに提供するプログラムを機能毎に分割して格納し、当該機能毎に分割して格納されているプログラムをクライアントが機能毎に選択できる。そして、当該選択されたプログラムのみがサーバからクライアントに対して提供されるように構成している。このため、必要な機能に関する印刷制御プログラムのみを選択して、クライアント側にダウンロードでき、サーバからクライアントへのデータ通信量を低減させることができるとともに、プログラムがダウンロードされるコンピュータのメモリ使用容量を節約することができる。この技術においては、クライアントによって規定されるプログラムの組み合わせについて何らの特徴付けはなされていない。
【０００５】
さらに、特開２００２−１８２９３７号公報には、クライアント端末とサーバとの間で少ないデータ量でもってダウンロードでき、所望のデータ処理を実行できるようにするための技術が開示されている。具体的には、クライアント端末で定義情報を入力し、サーバで設定情報を定義情報に対応して読み出してクライアント端末に送信し、設定情報に基づいて１又は複数の機能部品を呼び出す。機能部品は複数のデータ処理を共通の単位処理に分割しそこから抽出した処理ロジックを記述したものであって、クライアント端末又は処理サーバで１又は複数の機能部品に基づく処理ロジックによって単位処理プログラムを動的に生成し、生成された１又は複数の単位処理プログラムを設定情報に基づく条件に従って実行する。この技術では、単位処理プログラムの認可といった観点は存在していない。また、単位処理プログラムを複数種類実行する場合における問題などについては触れられていない。
【特許文献１】特開２０００−２３６３２６号公報
【特許文献２】特開２０００−３４７９５８号公報
【特許文献３】特開２００２−１８２９３７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上で述べたような従来技術には、クライアント側でサーバ側に用意された任意の機能を組み合わせ、クライアント側でネットワークを介して機能の組み合わせにつきサービスの提供を受ける際に、サービス提供の可否を判断したり、複数の組み合わせを識別したりすることについては考慮されていない。従って、ネットワーク・サービスの柔軟且つ適切な提供に問題がある。
【０００７】
従って、本発明の目的は、ネットワーク・サービスの柔軟且つ適切な提供を可能にするための新規な技術を提供することである。
【課題を解決するための手段】
【０００８】
本発明の第１の態様に係るサービス処理方法は、ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせに関しクライアント側で定義され且つネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムを実行しているクライアント端末から、サービスプログラムの識別情報とクライアントの識別情報と特定の機能の要求動作の指定とを含むメッセージを受信するステップと、クライアントの識別情報とサービスプログラムの識別情報とが対応付けられて格納されているデータ格納部を参照して、受信されたメッセージに含まれるサービスプログラムの識別情報及びクライアントの識別情報の対応付けが登録されているか確認する確認ステップと、確認ステップにおいて確認が取れた場合に、メッセージにおいて要求された、ネットワーク・プラットフォーム側における特定の機能による処理を実施し、処理結果及びサービスプログラムの識別情報を含む応答をクライアント端末に送信するステップとを含む。
【０００９】
このようにサービスプログラムの識別情報がサービス要求に含まれるので、メッセージへの応答の可否を確認することができ、さらに複数のサービス・プログラムが実行されている場合であっても識別して処理を進めることができる。なお、サービスプログラムの識別情報以外の要素をさらに用いて機能利用の可否を確認しても良い。
【００１０】
また、ネットワーク・プラットフォーム側に未登録のサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信するステップと、受信したサービスプログラムを解析し、サービスプログラム内に定義されている全機能をクライアントが利用可能か判断する判断ステップと、サービスプログラム内に定義されている全機能をクライアントが利用可能と判断された場合には、サービスプログラムに対して発行された識別情報をクライアントの識別情報と対応付けてデータ格納部に格納するステップと、サービスプログラムの識別情報を含む登録完了通知をクライアント端末に送信するステップとをさらに含むようにしてもよい。
【００１１】
このようにサービスプログラムにおいて定義されている全機能が利用可能かが予め確認されているので、サービス実行時にはサービスプログラムの識別情報を用いた確認が可能となる。
【００１２】
さらに、上で述べた判断ステップにおいて、クライアントの識別情報に対応して利用可能な機能の識別情報が格納されているクライアントデータ格納部をサービスプログラム登録要求に含まれるクライアントの識別情報を用いて検索し、サービスプログラムに定義されている全機能が抽出されるか判断するようにしてもよい。このようにすれば、容易にサービスプログラムの確認を行うことができるようになる。
【００１３】
また本発明の第２の態様に係る情報処理方法は、ネットワーク・プラットフォーム側で提供される機能のうちクライアントによって利用される機能の組み合わせが定義されているサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信するステップと、受信したサービスプログラムを解析し、サービスプログラム内に定義されている全機能をクライアントが利用可能か判断する判断ステップと、サービスプログラム内に定義されている全機能をクライアントが利用可能と判断された場合には、サービスプログラムに対して発行された識別情報を、クライアントの識別情報と対応付けてデータ格納部に格納するステップと、サービスプログラムの識別情報を含む登録完了通知をクライアント端末に送信するステップとを含む。このような処理を実施すれば、自動的にサービスプログラムの確認を行うことができるようになる。
【００１４】
本発明に係るサービス処理方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
【発明の効果】
【００１５】
本発明によれば、ネットワーク・サービスの柔軟且つ適切な提供が可能となる。
【発明を実施するための最良の形態】
【００１６】
図１に本発明の一実施の形態に係るシステム概要図を示す。インターネット等のオープンネットワーク１には、複数のクライアント端末（ＣＴ：Client Terminal）が接続されている。また、オープンネットワーク１は、ゲートウェイ（ＧＷ：Gateway）３を介してサービス提供ネットワーク５に接続されている。サービス提供ネットワーク５においては、以下に説明するネットワーク・プラットフォーム（ＮＰ）５０が構築されている。
【００１７】
ネットワーク・プラットフォーム５０には、共通機能モジュールとして、認証・認可機能モジュール５０１と、課金機能モジュール５０２と、ＣＴ管理機能モジュール５０３とが設けられている。認証・認可機能モジュール５０１は、クライアント認証、端末認証、サービス認可等を行う。課金機能モジュール５０２は、例えばクライアント毎に機能モジュールの使用回数等の課金に必要なデータを収集し、例えばクライアント毎の課金データを生成する。ＣＴ管理機能モジュール５０３は、各機能モジュールの版数管理、クライアント端末の状態管理、クライアント端末への機能モジュールのダウンロード制御、及び以下で説明するサービスプログラムの登録確認、サービスＩＤの発行などを行う。
【００１８】
また、ネットワーク・プラットフォーム５０には、個別機能モジュールとして、セッション制御（例えばＳＩＰ（Session Initiation Protocol））を行うセッション制御機能モジュール５０４、クライアントのプレゼンス・データを管理するコンテキスト管理機能モジュール５０５、メディア変換機能モジュール５０６などの機能モジュールが設けられている。図１では３つの個別機能モジュールを示しているが、他の機能モジュールが設けられる場合もある。さらに、ネットワーク・プラットフォーム５０には、個別機能モジュール等が共通して使用するコモンアプリケーション＃１、＃２、＃３なども設けられている。
【００１９】
一方、クライアント端末には、１又は複数のサービスプログラムと、１又は複数のクライアント機能モジュールと、管理プログラムとが設けられている。図１の例では、クライアント端末７には、サービスプログラム＃１及び＃２と、クライアント機能モジュールＡ及びＢと、管理プログラム７１が設けられている。クライアント機能モジュールについては、ネットワーク・プラットフォーム５０からダウンロードした機能モジュールである場合もあれば、予めクライアント端末に用意されている機能モジュールの場合もある。また、クライアント端末９には、サービスプログラム＃３と、クライアント機能モジュールＣと、管理プログラム９１とが設けられている。
【００２０】
さらに、ネットワーク・プラットフォーム５０内には、コモンアプリケーションと個別機能モジュールとの間にＮＰ−ＡＰＩ（Application Program Interface）が規定されている。また、クライアント端末内には、サービスプログラムとクライアント機能モジュールとの間にＣＴ−ＡＰＩが規定されている。例えばクライアント端末においてサービスプログラムは、ＣＴ−ＡＰＩを介してクライアントの機能モジュールを用いるようになっている。さらに、クライアント端末とネットワーク・プラットフォーム５０との間に、サービス管理インターフェース（ＳＭＩ：Service Management Interface）と、サービス制御インターフェース（ＳＣＩ：Service Control Interface）とが規定されている。サービスプログラムは、ＳＣＩを介してクライアント端末のユーザが望むサービスが、ネットワーク・プラットフォーム５０から提供されるように、定義される。
【００２１】
次に、サービス管理インターフェースＳＭＩについて説明する。ネットワーク・プラットフォーム５０は、ネットワーク・プラットフォーム５０において公開している機能モジュールとその機能を実行する際に必要なパラメータをＳＭＩを介して公開しており、クライアント端末のユーザ又はクライアント・システムの構築者は、ＳＭＩを介してネットワーク・プラットフォーム５０から必要な情報を取得してサービスプログラム作成を行う。
【００２２】
ＳＭＩを介してやりとりされるパケットの形式は、例えば図２（ａ）に示すようなものである。すなわち、ＩＰアドレスなどのネットワーク・アドレスを含むパケット・ヘッダと、クライアントＩＤと、端末ＩＤと、動作データとが含まれる。動作データについては、クライアント端末からのパケットであれば例えばサービス要求内容（サービスプログラム登録要求、機能ダウンロード要求、版数管理要求、状態管理要求など）が含まれ、ネットワーク・プラットフォーム５０からのパケットであれば例えば処理結果や要求データが含まれる。また、ＳＣＩを介してやりとりされるパケットの形式は、例えば図２（ｂ）に示すようなものである。すなわち、ＩＰアドレスなどのネットワーク・アドレスを含むパケットヘッダと、クライアントＩＤと、端末ＩＤと、サービスプログラムのＩＤであるサービスＩＤと、動作データとを含む。動作データについては、クライアント端末からのパケットであれば例えば起動すべき機能モジュールのＩＤ及び必要なパラメータを含み、ネットワーク・プラットフォーム５０からのパケットであれば例えば処理結果が含まれる。
【００２３】
また、サービス提供ネットワーク５には、ＮＰ運用管理機能も用意されており、ＮＰ運用管理インターフェースを介してＮＰ運用管理機能によりネットワーク・プラットフォーム５０について各種管理を行う。なお、ＮＰ運用管理機能については本実施の形態の主要部ではないので、これ以上説明は行わない。
【００２４】
サービスプログラムの作成及び登録については図３乃至図７を用いて説明する。例えばクライアント端末７における管理プログラム７１は、ＳＭＩを介してサービスプログラム作成要求をネットワーク・プラットフォーム５０に送信する（ステップＳ１）。ネットワーク・プラットフォーム５０のＣＴ管理機能モジュール５０３は、クライアント端末７からサービスプログラム作成要求を受信し（ステップＳ３）、サービスプログラム作成要素データをＳＭＩを介してクライアント端末７に送信する（ステップＳ５）。クライアント端末７の管理プログラム７１は、ネットワーク・プラットフォーム５０からサービスプログラム作成要素データを受信し（ステップＳ７）、当該サービスプログラム作成要素データを用いてサービスプログラム作成画面を表示する（ステップＳ９）。例えば図４に示すような画面が表示される。図４の例では、サービスプログラム開発ウインドウと、サービスプログラムのロジックのテンプレート・ウインドウとが表示されている。サービスプログラム開発ウインドウには、ネットワーク・プラットフォーム５０において公開されている機能モジュールのリストが含まれ、ここではＳＩＰ、ＲＳＶＰ（Resource Reservation Setup Protocol）−ＴＥ（Traffic Engineering）、コンテキスト管理、ＲＦＩＤ（Radio Frequency-ID）ミドル、メディア変換などの項目が列挙されている。また、各項目をクリックすると、当該項目に係る機能モジュールの機能概要及び入力パラメータ情報が表示されるようになっている。なお、図４ではＳＩＰを選択した場合を示しており、機能概要及び入力パラメータについてはポップアップウインドウなどにて表示しても良い。テンプレート・ウインドウでは、典型的な処理ロジックが選択可能となっており、図４の例では第１段階で何らかの処理を行って、第２段階で条件を判断し、第３段階で条件によって異なる処理を行うというロジックの例が示されている。クライアント端末７のユーザは、サービスプログラム開発ウインドウに表示された内容を参照しつつ、テンプレート・ウインドウに今回作成するサービスプログラムのロジックに合致するロジックを表示させ、各ブロックで行う処理、使用する機能モジュールのＩＤ、必要なパラメータを入力する。
【００２５】
なお、クライアント端末７の管理プログラム７１は、必要な機能モジュールがクライアント端末７に存在するか確認する（ステップＳ１１）。もし、必要な機能モジュールがクライアント端末７に存在しないと判断した場合には、ネットワーク・プラットフォーム５０に対して必要な機能モジュールについて機能モジュール要求をＳＭＩを介して送信する（ステップＳ１３）。ネットワーク・プラットフォーム５０のＣＴ管理機能モジュール５０３は、クライアント端末７から機能モジュール要求を受信する（ステップＳ１５）。ネットワーク・プラットフォーム５０のＣＴ管理機能モジュール５０３は、受信した機能モジュール要求のパケットに含まれるクライアントＩＤ等から、要求に係る機能モジュールの送信可否を判断することもある。但し、ネットワーク・プラットフォーム５０を利用する上で必要な基本的な機能モジュールであれば、特にチェックする必要はない。ＣＴ管理機能モジュール５０３は、機能モジュール格納部５１１から要求に係る機能モジュールを読み出し、ＳＭＩを介してクライアント端末７に送信する（ステップＳ１７）。クライアント端末７の管理プログラム７１は、ネットワーク・プラットフォーム５０から要求機能モジュールを受信すると、クライアント端末の記憶装置に格納する（ステップＳ１９）。
【００２６】
ステップＳ１１において必要な機能モジュールがクライアント端末７に存在すると判断された場合及びステップＳ１９の後に、クライアント端末７の管理プログラム７１は、例えば図４に示したような画面において、ユーザからのサービスプログラム作成指示を受け付ける（ステップＳ２１）。ネットワーク・プラットフォーム５０において利用可能な機能モジュールのＩＤ及び必要な入力パラメータのセットが、ロジックを表すテンプレートのブロックにおいて指定されており、ロジックに必要な条件等のデータも指定される。処理は端子Ａを介して図５の処理に移行する。
【００２７】
そして、クライアント端末７の管理プログラム７１は、受け付けた入力データに従ってサービスプログラムを生成し、クライアント端末７の記憶装置に格納する（ステップＳ２３）。そして、管理プログラム７１は、サービスプログラムを含むサービスプログラム登録要求を、ネットワーク・プラットフォーム５０に送信する（ステップＳ２５）。ネットワーク・プラットフォーム５０のＣＴ管理機能モジュール５０３は、クライアント端末７からサービスプログラムを含むサービスプログラム登録要求を受信し、記憶装置に格納する（ステップＳ２７）。そして、ＣＴ管理機能モジュール５０３は、クライアントデータ格納部５１３を参照して、受信したサービスプログラムに対するチェック処理を実施する（ステップＳ２９）。例えば、クライアントデータ格納部５１３には、図６に示すようなデータが格納されている。図６の例では、クライアントＩＤに対応して利用可能な機能モジュールのＩＤが登録されている。このような簡単なテーブルではなく、クライアントの所属が定義されたテーブルと、所属と利用可能な機能モジュールのＩＤとの対応テーブルとを組み合わせる場合もある。サービスプログラム登録要求に含まれるクライアントＩＤを用いて図６に示すようなテーブルを検索して利用可能な機能モジュールのＩＤを特定し、サービスプログラムにおいて規定されている全機能モジュールが利用可能か、すなわちサービスプログラムの利用を認可できるか判断する（ステップＳ３１）。もし、利用不可能な機能モジュールがサービスプログラム中に規定されている場合には、ＣＴ管理機能モジュール５０３は、登録拒否通知をクライアント端末７に送信する。クライアント端末７の管理プログラム７１は、ネットワーク・プラットフォーム５０から登録拒否通知を受信し、表示装置に表示する（ステップＳ３３）。これにて作成したサービスプログラムに問題があることを認識することができる。
【００２８】
一方、クライアント端末７から受信したサービスプログラムにおいて規定されている全機能モジュールが利用可能であると判断された場合には、ＣＴ管理機能モジュール５０３は、当該サービスプログラムに対してサービスＩＤを発行し、クライアントデータ格納部５１３に登録する（ステップＳ３５）。例えば、図７に示すように、クライアントＩＤに対応してサービスＩＤが登録される。なお、サービスプログラム自体又は定義されている全機能モジュールのＩＤ群をクライアントデータ格納部５１３又は他のデータ格納部にクライアントＩＤに対応付けて登録するようにしても良い。サービスＩＤについては、ネットワーク・プラットフォーム５０全体においてサービスＩＤがユニークである場合、又はクライアント又はクライアントの集合毎にユニークである場合がある。前者の場合には、ネットワーク・プラットフォーム側でサービスＩＤを発行・管理する必要がある。後者は、クライアントＩＤ毎にそれぞれサービスＩＤを発行・管理し、両ＩＤを組み合わせてサービスプログラムを特定する場合である。この場合は、クライアント側でサービスＩＤを発行し、それをネットワーク・プラットフォーム側に登録することが可能になる為、後者の方が分散管理がしやすいといえる。そして、ＣＴ管理機能モジュール５０３は、発行されたサービスＩＤを含む登録完了通知をクライアント端末７にＳＭＩを介して送信する（ステップＳ３７）。
【００２９】
クライアント端末７の管理プログラム７１は、ネットワーク・プラットフォーム５０からサービスＩＤを含む登録完了通知を受信し、受信されたサービスＩＤを含むサービスプログラムを、利用可能なサービスプログラムとしてクライアント端末７の記憶装置に格納する（ステップＳ３９）。このようにすれば、ＳＣＩを介してネットワーク・プラットフォーム５０に対してサービスを要求する際に、図２（ｂ）に示すようなパケットを生成して送信することができ、ネットワーク・プラットフォーム５０からは、ユーザにカスタマイズされたサービスプログラムにおいて規定されたサービスを受けることができるようになる。
【００３０】
なお、図３及び図５の処理フローでは、クライアント端末のための機能モジュールをステップＳ１１乃至Ｓ１９で必要であればダウンロードするような構成を示したが、例えば登録完了通知を受信した後に、サービスプログラムの実行に必要となる機能モジュールをさらにダウンロードするようにしても良い。また、ステップＳ１１乃至Ｓ１９を実施せず、登録完了通知を受信した後にサービスプログラムの実行に必要となる機能モジュールをダウンロードするようにしても良い。
【００３１】
ここで、サービスプログラムについて説明を加えておく。サービスプログラムについては、サービスプログラムを実行させるクライアントに許可された機能モジュールを利用する限りにおいて自由に構成することができる。図８（ａ）に示すように、サービス＃ａとして、まず状況理解（例えば機能モジュール＃ｃの起動）を実施し（Ｓ１００１）、状況理解の結果として状況＃Ｘであるか状況＃Ｙのいずれであるかを判定し（Ｓ１００３）、状況＃Ｙであれば機能モジュール＃ｂを起動し（Ｓ１００５）、その後結果待ちとするか、状況＃Ｘであれば機能モジュール＃ａを起動し（Ｓ１００７）、状況理解（例えば機能モジュール＃ｃの起動）を実施し（Ｓ１００９）、状況理解の結果として状況＃Ｚであるか状況＃Ｗであるかを判定し（Ｓ１０１１）、状況＃Ｚであれば機能モジュール＃ａを起動し（Ｓ１０１５）、その後結果待ちとするか、状況＃Ｗであれば機能モジュール＃ｂを起動し（Ｓ１０１３）、その後結果待ちとするような定義が行われている。このように、必要な機能の利用及び必要なパラメータの設定を全て行うようにしても良いし、Ｓ１００７乃至Ｓ１０１５について別途サービス＃ｂと定義済みであれば、図８（ａ）のブロック８０１の代わりに、図８（ｂ）に示すようにサービス＃ｂ起動（Ｓ１０２１）の規定を行っても良い。
【００３２】
次に、図９乃至図１２を用いて、本実施の形態におけるメッセージ及びパケットの組立、分解、及び振分方法について説明する。なお、ここではＳＣＩを介した通信について説明する。図９で示すように、サービスプログラム＃１又はサービスプログラム＃２は、動作データ（例えば特定の機能モジュールの起動要求及び必要なパラメータ）を生成すると、動作データをメッセージ組み立て機能モジュール７２に出力する。メッセージ組み立て機能モジュール７２に出力されるデータは、図１０（１）に示されるようなデータである。基本的には、動作データだけであるが、サービスプログラムを識別するために動作データと共にサービスＩＤが出力される場合もある。メッセージ組み立て機能モジュール７２は、さらに端末ＩＤ及びクライアントＩＤを付加してパケット組立部７３に出力する。すなわち、図１０（２）に示すようなデータがメッセージとして構成される。なお、メッセージ組立機能モジュール７２とパケット組立部７３とのインターフェースは、通常の通信インターフェースであり、パケット組立部７３は、特定の通信プロトコルに従って例えば図１０（３）に示すようなネットワーク・アドレスを含むパケットヘッダを付加する。
【００３３】
次に、ネットワーク・プラットフォーム５０においては、パケット分解部５２１が、特定の通信プロトコルに従ってクライアント端末からのパケットを受信して、当該パケットに含まれるメッセージ（動作データ、サービスＩＤ、端末ＩＤ及びクライアントＩＤ）を抽出し、通信インターフェースを介してメッセージ分解機能モジュール５２２に出力する。メッセージは図１０（４）に示されるようなデータである。メッセージ分解機能モジュール５２２は、メッセージを受け取ると、クライアントＩＤ、端末ＩＤ、サービスＩＤ及び動作データを分解して、クライアントＩＤ、端末ＩＤ、サービスＩＤを認証・認可機能モジュール５０１及び課金機能モジュール５０２に出力する。なお、応答の返信のため、パケット分解部５２１が、パケットヘッダに含まれるネットワーク・アドレスをメッセージ分解機能モジュール５２２に出力し、メッセージ分解機能モジュール５２２において、クライアントＩＤ、端末ＩＤ又はサービスＩＤに対応してネットワーク・アドレスを記憶装置に格納しておく場合もある。
【００３４】
認証・認可機能モジュール５０１は、クライアントデータ格納部５１３を参照して、クライアントＩＤ及びサービスＩＤを用いてサービス認可を行う。但し、従来どおり、クライアントＩＤ及び端末ＩＤにてネットワーク・プラットフォーム５０の利用可否を判断し、別途クライアントＩＤとパスワードなどのデータにより本人認証を行う。また、課金機能モジュール５０２は、主にクライアントＩＤを用いて課金処理を実施する。なお、サービスＩＤ等をさらに用いて課金処理を実施する場合もある。そうすると、例えば使用する機能毎に料金が異なる場合には、サービスＩＤから利用した機能を特定して機能毎の利用状況を特定して、請求を行うことができる。なお、端末ＩＤについては、複数の端末に同一のＩＤを付与したり、端末ＩＤにより特定のグループに属する端末であることを特定することができるため、端末ＩＤも、あるユーザグループが１つの端末を使用するときの課金に用いる場合もある。さらに、不特定多数のユーザの利用を想定した公共端末等の場合には、あるクライアントが定義したサービスを実行することを認可するか否かを端末ＩＤを用いて判断するようにしても良い。例えば、公共端末をある特定のサービス提供用に限定したいようなケースにおいては、端末ＩＤに対して、そのサービス、すなわちサービスプログラムだけを実行するようにすることも可能である。
【００３５】
なお、認証・認可機能モジュール５０１は、さらに、クライアントデータ格納部５１３を参照して、図６に示すようなクライアントＩＤと利用可能な機能モジュールのＩＤとの対応付けに基づき、動作データにおいて指定されている起動機能モジュールの利用可否を判断するようにしても良い。この際、起動機能モジュールの特定については、認証・認可機能モジュール５０１が行っても良いし、以下で述べるメッセージディスパッチャ５２３によって行っても良い。又は、図６のようなデータではなく、クライアントＩＤと登録サービスプログラム又は登録サービスプログラムにおいて定義されている全機能モジュールのＩＤ群との対応付けから判断する場合もある。
【００３６】
そして、クライアントＩＤ及びサービスＩＤによるサービス認可が得られると、メッセージ分解機能モジュール５２２は、図１０（５）及び（６）に示すように、動作データのみ、又は動作データ及びサービスＩＤをメッセージディスパッチャ５２３に出力する。メッセージディスパッチャ５２３は、動作データを解析して出力先の機能モジュールを特定して、当該機能モジュールに動作データを出力する。図１０（５）及び（６）に示すように、この際メッセージディスパッチャ５２３は、どのサービスプログラムによる要求であるかを識別するためサービスＩＤを付加して出力する場合もある。
【００３７】
なお、メッセージディスパッチャ５２３が、クライアントデータ格納部５１３（図６等）を参照して、動作データにおいて指定されている利用機能モジュールの利用可否を判断するようにしても良い。また、基本的には動作データには、利用（すなわち起動）される機能モジュールの指定が含まれるが、機能モジュールの指定を含まないようにして必要なパラメータのみを含むようにしても良い。このような場合には、例えばクライアントＩＤ及びサービスＩＤとサービスプログラム自体又はサービスプログラムにおいて定義されている全機能モジュールのＩＤ群との対応付けをサービスプログラムデータ格納部５１４に登録しておき、クライアントＩＤ及びサービスＩＤにより特定されるサービスプログラムにおける状態を動作データに含まれるパラメータにて特定し、当該サービスプログラムにおける状態に応じてパラメータを出力すべき機能モジュールを特定するようにしてもよい。
【００３８】
このようにしてクライアント端末におけるサービスプログラムの要求がネットワーク・プラットフォーム５０における適切な機能モジュールに伝達される。
【００３９】
次に、ネットワーク・プラットフォーム５０からクライアント端末に応答を返す場合の処理を図１１を用いて説明する。まず、ネットワーク・プラットフォーム５０における機能モジュール＃１又は機能モジュール＃２は動作データ（処理結果）又は動作データ及びサービスＩＤをメッセージ組み立て機能モジュール５２４に出力する。出力されるデータは、図１０（１）と同様である。また、メッセージ組み立て機能モジュール５２４は、要求元クライアントを特定し、端末ＩＤ、クライアントＩＤをさらに付加してメッセージを構成し、パケット組立部５２５に出力する。構成されたメッセージは、図１０（２）に示したようなデータである。要求元クライアントの特定については、図９のメッセージ分解機能モジュール５２２及びメッセージディスパッチャ５２３と連携することにより行うか、又は図７に示したデータ及びクライアントＩＤに対応して端末ＩＤ等が格納されているクライアントデータ格納部５１３を利用するなどにて行われる。そして、パケット組立部５２５は、クライアントＩＤ又は端末ＩＤに対応するネットワーク・アドレスを含むパケットヘッダを含むパケットを生成して、クライアント端末に送信する。送信されるパケットは、図１０（３）と同様である。
【００４０】
クライアント端末においては、パケット分解部７４は、図１０（３）のようなパケットを受信すると、パケットヘッダを取り除き、メッセージ部分をメッセージ分解機能モジュール７５に出力する。メッセージ部分の構成は図１０（４）と同様である。そして、メッセージ分解機能モジュール７５は、メッセージに含まれる動作データ、又は動作データ及びサービスＩＤを抽出し、メッセージディスパッチャ７６に出力する。この段階で出力されるデータは、図１０（５）又は（６）と同様である。メッセージディスパッチャ７６は、動作データを解析するか又はサービスＩＤに従って、サービスプログラム＃１又はサービスプログラム＃２に動作データ又は動作データ及びサービスＩＤを出力する。
【００４１】
このような処理を行うことにより、動作データが適切にクライアント端末とネットワーク・プラットフォーム間でやり取りされるようになる。なお、ネットワーク・アドレスと機能モジュールとは直接関係付けられていないので、ネットワーク・プラットフォーム５０における機能モジュールの追加や変更をわざわざクライアント端末に通知する必要はないというメリットもある。
【００４２】
なお、図９乃至図１１では、ネットワーク・プラットフォーム５０に１つのネットワーク・アドレスを割り当てておき、ネットワーク・プラットフォーム５０においてメッセージの分解及び振分を行っていた。しかし、図１２に示すように、ネットワーク・プラットフォーム５０内の各機能モジュールにネットワーク・アドレス（ＮＡ）を割り当てておき、クライアント端末のパケット組立部７９において、メッセージの宛先となる機能モジュール（ここでは機能モジュール＃ｂ）のＮＡを含むパケットヘッダを当該メッセージに付加してパケット１２０２を構成し、ネットワーク機器１２０１において、パケット１２０２の宛先ネットワーク・アドレスに基づき、ネットワーク・プラットフォーム５０の指定された機能モジュール（ここでは＃ｂ）にパケット１２０２を転送するようにしてもよい。なお、課金や認証・認可の処理が必要であるため、パケット１２０２が認証・認可機能モジュール５０１と課金機能モジュール５０２とにコピーされて転送される場合もある。
【００４３】
なお、図１２のような構成を採用しても良いが、クライアント端末側では、メッセージを分析してネットワーク・プラットフォーム５０における機能モジュールを特定し、当該機能モジュールのネットワーク・アドレスを特定する機能が必要となる。但し、この方がネットワーク・プラットフォーム５０側の処理負荷は下がる。一方、ネットワーク・プラットフォーム５０における内部機構を外部に公開する必要があり、機能モジュールの追加や変更毎にクライアント端末に通知して設定の変更などを行う必要がある。図９乃至図１１のような構成を採用するか、図１２のような構成を採用するかは、ネットワーク全体の構成を踏まえて決定される。
【００４４】
次に、図９乃至図１２に示したメッセージ及びパケットの組立、分解、及び振分方法を前提に、図１３乃至図１７を用いて、メッセージのやりとりについての具体的な処理フローを説明する。ここでは、例えばクライアント端末７におけるサービスプログラム＃１において、図１３に示すようなロジックが定義されているものとする。このサービスプログラムの例においては、クライアント端末７のユーザが広告配信を行うために、まず配信先の相手の状況を問い合わせ（状況理解）、相手の状況に応じて異なる配信方法で広告を送付する処理を行うものを想定している。すなわち、最初に特定の端末（又はユーザ）についての状況理解としてコンテキスト管理を行う機能モジュール＃ｃに対して問い合わせを行い、問い合わせへの応答に基づき状況判定を行い、特定の端末の状況が状況＃Ｘであれば機能モジュール＃ａを起動し、状況＃Ｙであれば機能モジュール＃ｂが起動されるように、サービスプログラム＃１が規定されているものとする。また、サービスＩＤが＃０７０３であり、端末ＩＤが＃９３６であり、クライアントＩＤが＃５３１であるものとする。
【００４５】
そうすると、クライアント端末７のサービスプログラム＃１等は、特定の端末についての状況理解を行うため、機能モジュール＃ｃの起動要求メッセージを生成し、メインメモリ等の記憶装置に格納する（ステップＳ５１）。起動要求メッセージには、クライアントＩＤ”＃５３１”と端末ＩＤ”＃９３６”とサービスＩＤ”＃０７０３”と機能モジュール＃ｃの起動要求と特定の端末の識別情報（又は特定のユーザの識別情報）が含まれる。そして、クライアント端末７のパケット組立部７３は、生成された起動要求メッセージと宛先ネットワーク・アドレスを含むパケットを生成し、ネットワーク・プラットフォーム５０に送信する（ステップＳ５３）。例えば、図１５の（１）に示すようなパケットが生成され、送信される。
【００４６】
一方ネットワーク・プラットフォーム５０のパケット分解部５２１は、クライアント端末７から機能モジュール＃ｃの起動要求メッセージを含むパケットを受信し、記憶装置に格納する（ステップＳ５５）。そして、パケットから機能モジュール＃ｃの起動要求メッセージを抽出する（ステップＳ５７）。また、上でも述べたように、メッセージ分解機能モジュール５２２は、起動要求メッセージに含まれるクライアントＩＤ、端末ＩＤ、サービスＩＤを抽出し、認証・認可機能モジュール５０１及び課金機能モジュール５０２に出力する。認証・認可機能モジュール５０１は、クライアントＩＤ及び端末ＩＤについて確認を行い、課金機能モジュール５０２は、課金処理を実施する（ステップＳ５９）。さらに、認証・認可機能モジュール５０１は、サービスＩＤ及びクライアントＩＤを用いて当該機能モジュール＃ｃの起動要求を認可できるか確認する（ステップＳ６１）。もし、ステップＳ５９又はＳ６１で問題が検出されれば、クライアント端末７に対して要求処理を実施できない旨のメッセージを返信する。一方、ステップＳ５９及びＳ６１で問題が検出されない場合には、メッセージ分解機能モジュール５２２から動作データ（ここでは機能モジュール＃ｃの起動要求及びパラメータ）又は動作データ及びサービスＩＤがメッセージディスパッチャ５２３に出力され、メッセージディスパッチャ５２３は、動作データを解析し、当該動作データを機能モジュール＃ｃにディスパッチする（ステップＳ６３）。なお、起動であれば、必要なパラメータを渡して起動させる。
【００４７】
上でも述べたが、機能モジュール＃ｃを起動する前に、機能モジュール＃ｃ自体の利用可否（起動可否）を判断するようにしても良い。この場合には、クライアントデータ格納部５１３内の図６のようなデータを参照して判断しても良いし、さらに上で述べたようにサービスプログラムデータ格納部５１４に格納された、クライアントＩＤとサービスプログラム自体又はサービスプログラムに規定されている機能モジュールのＩＤ群との対応付けを参照して判断しても良い。
【００４８】
機能モジュール＃ｃは、動作データに基づき処理を行い（ステップＳ６５）、実行結果（ここでは”機能＃ｃ実行結果：状況Ｙ”（例えばユーザＡは携帯電話機を持って電車に乗っている））を含む動作データを生成し、当該動作データ又は動作データ及びサービスＩＤを、メッセージ組み立て機能モジュール５２４に出力する。メッセージ組み立て機能モジュール５２４は、クライアントＩＤ”＃５３１”、端末ＩＤ”＃９３６”及びサービスＩＤ”＃０７０３”を付加してメッセージを生成し（ステップＳ６７）、パケット組立部５２５は、実行結果を含むメッセージにパケットヘッダを付加してパケットを生成し、クライアント端末７に送信する（ステップＳ６９）。本ステップで送信されるパケットは、例えば図１５（２）のようなパケットである。
【００４９】
クライアント端末７のパケット分解部７４は、ネットワーク・プラットフォーム５０から実行結果メッセージを含むパケットを受信し、例えばメインメモリ等の記憶装置に格納する（ステップＳ７１）。処理は端子Ｂを介して図１６に移行する。そして、パケット分解部７４は、実行結果メッセージ部分を抽出してメッセージ分解機能モジュール７５に出力する（ステップＳ７３）。メッセージ分解機能モジュール７５は、実行結果メッセージから実行結果を含む動作データ又は動作データ及びサービスＩＤを抽出し、メッセージディスパッチャ７６に出力し、メッセージディスパチャ７６は、動作データを動作データの要求元であるサービスプログラム＃１に出力する。
【００５０】
サービスプログラム＃１は、動作データに含まれる実行結果を解析し、図１３のようなサービスプログラムであれば状況判定を行う（ステップＳ７５）。図１５（２）の例では、状況＃Ｙであることが分かるので、機能モジュール＃ｂを起動させることになる。例えば、ＳＩＰを用いてＶｏＩＰ（Voice Over IP）にて発呼する。従って、サービスプログラム＃１は、解析結果に従って、機能モジュール＃ｂの起動要求メッセージを生成し（ステップＳ７７）、メインメモリ等の記憶装置に格納する。起動要求メッセージには、クライアントＩＤ”＃５３１”と端末ＩＤ”＃９３６”とサービスＩＤ”＃０７０３”と機能モジュール＃ｂの起動要求と発呼先ＳＩＰ−ＵＲＬ等のパラメータとが含まれる。そして、クライアント端末７のパケット組立部７３は、生成された起動要求メッセージと宛先ネットワーク・アドレスを含むパケットを生成し、ネットワーク・プラットフォーム５０に送信する（ステップＳ７９）。例えば、図１５の（３）に示すようなパケットが生成され、送信される。
【００５１】
一方ネットワーク・プラットフォーム５０のパケット分解部５２１は、クライアント端末７から機能モジュール＃ｂの起動要求メッセージを含むパケットを受信し、記憶装置に格納する（ステップＳ８１）。そして、パケットから機能モジュール＃ｂの起動要求メッセージを抽出する（ステップＳ８３）。また、上でも述べたように、メッセージ分解機能モジュール５２２は、起動要求メッセージに含まれるクライアントＩＤ、端末ＩＤ、サービスＩＤを抽出し、認証・認可機能モジュール５０１及び課金機能モジュール５０２に出力する。認証・認可機能モジュール５０１は、クライアントＩＤ及び端末ＩＤについて確認を行い、課金機能モジュール５０２は、課金処理を実施する（ステップＳ８５）。さらに、認証・認可機能モジュール５０１は、サービスＩＤ及びクライアントＩＤを用いて当該機能モジュール＃ｂの起動要求を認可できるか確認する（ステップＳ８７）。もし、ステップＳ８５又はＳ８７で問題が検出されれば、クライアント端末７に対して要求処理を実施できない旨のメッセージを返信する。一方、ステップＳ８５及びＳ８７で問題が検出されない場合には、メッセージ分解機能モジュール５２２から動作データ（ここでは機能モジュール＃ｂの起動要求及びパラメータ）又は動作データ及びサービスＩＤがメッセージディスパッチャ５２３に出力され、メッセージディスパッチャ５２３は、動作データを解析し、当該動作データを機能モジュール＃ｂにディスパッチする（ステップＳ８９）。なお、起動であれば、必要なパラメータを渡して起動させる。上でも述べたようにこの段階においても機能起動の可否を判断するようにしても良い。
【００５２】
機能モジュール＃ｂは、動作データに基づき処理を行い（ステップＳ９１）、実行結果（ここでは”機能＃ｂ実行結果”）を含む動作データを生成し、当該動作データ又は動作データ及びサービスＩＤを、メッセージ組み立て機能モジュール５２４に出力する。処理は端子Ｃを介して図１７の処理に移行する。
【００５３】
そして、メッセージ組み立て機能モジュール５２４は、クライアントＩＤ”＃５３１”、端末ＩＤ”＃９３６”及びサービスＩＤ”＃０７０３”を付加してメッセージを生成し（ステップＳ９３）、パケット組立部５２５は、実行結果を含むメッセージにパケットヘッダを付加してパケットを生成し、クライアント端末７に送信する（ステップＳ９５）。本ステップで送信されるパケットは、例えば図１５（４）のようなパケットである。
【００５４】
クライアント端末７のパケット分解部７４は、ネットワーク・プラットフォーム５０から実行結果メッセージを含むパケットを受信し、例えばメインメモリ等の記憶装置に格納する（ステップＳ９７）。そして、パケット分解部７４は、実行結果メッセージ部分を抽出してメッセージ分解機能モジュール７５に出力する（ステップＳ９９）。メッセージ分解機能モジュール７５は、実行結果メッセージから実行結果を含む動作データ又は動作データ及びサービスＩＤを抽出し、メッセージディスパッチャ７６に出力し、メッセージディスパッチャ７６は、動作データを動作データの要求元であるサービスプログラム＃１に出力する。
【００５５】
サービスプログラム＃１は、動作データに含まれる実行結果を解析し（ステップＳ１０１）、解析結果に従って必要な処理を実施する（ステップＳ１０３）。
【００５６】
このようにサービスＩＤが付加されたメッセージがやりとりされて、サービスプログラムに従って処理が行われていく。
【００５７】
また、上で述べたようなネットワークサービス提供のための各種ＡＰＩが用意されており、クライアント端末のユーザ又はソフトウエア開発者は、必要に応じて機能モジュールを組み合わせて使用するようなサービスプログラムを作成することができる。また、サービスプログラムは、クライアント端末だけではなくネットワーク・プラットフォーム５０側などネットワーク上に保存しておくことができ、必要に応じてダウンロードして、ユーザは自らの端末を使用しているがごとく他の端末を用いて所定のサービスを利用することも可能である。さらに、特定のサービスを利用する場合にはサービスプログラムだけを用意すればよいので、特定のサービス全体をシステム化するより開発工数及び期間を減らすことができる。また、サービスプログラム自身の更新は容易であり、ネットワーク・プラットフォーム５０側の機能モジュールが更新されれば全てのクライアントが改良された機能を利用可能となる。さらに、必要に応じてクライアント端末には機能モジュールをダウンロードできるため、元々機能をあまり有さない端末であっても多様な、また高度なサービスを利用することができるようになる。
【００５８】
また、本実施の形態ではサービスＩＤを含むメッセージ（ネットワーク上ではパケット）を交換するようになっているが、これによりクライアント端末では、複数のサービスプログラムを同時に実行させることができるようになる。すなわち、どのサービスプログラムについてのメッセージなのか、どのサービスプログラムについての処理なのかを識別することができる。
【００５９】
さらに、ネットワーク・プラットフォーム５０側でサービスプログラム又はサービスプログラムによって規定されている状態を管理していれば、サービスＩＤを見ればいずれの機能モジュールに動作データを振り分けるべきかを判断することができるようになる。さらに、サービスＩＤを用いたサービス認可を行うことも可能となる。さらに、サービスプログラム登録時にネットワーク・プラットフォーム５０側で機能の使用可否を判断し、許可された場合にサービスＩＤを割り当てれば、以降はサービスＩＤで機能の使用許可を判断することが可能になる。すなわち、メッセージ毎に機能の使用許可を判断する必要は無くなり、ネットワーク・プラットフォーム５０側ではサービスＩＤとクライアントＩＤの対応テーブルだけをチェックしてサービス許可を行えるので、処理の簡単化が図れる。
【００６０】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、ＳＭＩを介したサービスプログラムの作成処理について説明したが、別途ネットワーク・プラットフォーム５０において提供される機能モジュールの詳細などを入手することができれば、別途入手した情報に基づきサービスプログラムを作成するようにしても良い。また、サービスプログラムの登録についてもネットワークを介さずに、別途確認及び登録するような手順を採用する場合もある。
【００６１】
また、ネットワーク・プラットフォーム５０は、１台のコンピュータにより実現せずに複数台のコンピュータにより機能分担したり、一部の機能については並列又は分散処理を実施する場合もある。
【００６２】
また、サービス認可についてはメッセージに他のデータ（例えば、サービスプログラムの改ざんがなされていないことを照明するデータ（ハッシュ値又は電子証明書など））を付加して確認する場合もある。
【００６３】
さらに、ネットワーク・プラットフォーム５０における機能モジュール毎に、利用可能なクライアントを規定しておき、クライアントＩＤと動作データに含まれる利用機能モジュールＩＤとを用いて、機能モジュール毎に利用の可否を判断するようにしてもよい。また、図６に示したようなクライアントＩＤと機能モジュールＩＤとの対応テーブルのみを用いて機能モジュールの利用可否を判断しても良い。
【００６４】
なお、ネットワーク・プラットフォーム５０を実現する１又は複数のコンピュータ及びクライアント端末は、コンピュータ装置であって、図１８に示すように、メモリ２５０１（記憶装置）とＣＰＵ２５０３（処理装置）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施の形態における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施の形態では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【００６５】
（付記１）
ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせに関し前記クライアント側で定義され且つ前記ネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムを実行しているクライアント端末から、前記サービスプログラムの識別情報とクライアントの識別情報と特定の機能の要求動作の指定とを含むメッセージを受信するステップと、
クライアントの識別情報とサービスプログラムの識別情報とが対応付けられて格納されているデータ格納部を参照して、受信された前記メッセージに含まれる前記サービスプログラムの識別情報及び前記クライアントの識別情報の対応付けが登録されているか確認する確認ステップと、
前記確認ステップにおいて確認が取れた場合に、前記メッセージにおいて要求された、前記ネットワーク・プラットフォーム側における前記特定の機能による処理を実施し、処理結果及び前記サービスプログラムの識別情報を含む応答を前記クライアント端末に送信するステップと、
を含み、コンピュータにより実行されるサービス処理方法。
【００６６】
（付記２）
前記ネットワーク・プラットフォーム側に未登録のサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信するステップと、
受信した前記サービスプログラムを解析し、前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能か判断する判断ステップと、
前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能と判断された場合には、前記サービスプログラムに対して発行された識別情報を前記クライアントの識別情報と対応付けて前記データ格納部に格納するステップと、
前記サービスプログラムの識別情報を含む登録完了通知を前記クライアント端末に送信するステップと、
をさらに含む付記１記載のサービス処理方法。
【００６７】
（付記３）
前記判断ステップにおいて、
前記クライアントの識別情報に対応して利用可能な機能の識別情報が格納されているクライアントデータ格納部を前記サービスプログラム登録要求に含まれる前記クライアントの識別情報を用いて検索し、前記サービスプログラムに定義されている全機能が抽出されるか判断する
ことを特徴とする付記２記載のサービス処理方法。
【００６８】
（付記４）
前記メッセージが、前記ネットワーク・プラットフォーム側における前記特定の機能において必要とされるパラメータを含むことを特徴とする付記１記載のサービス処理方法。
【００６９】
（付記５）
前記メッセージに含まれる、前記サービスプログラムの識別情報と、保持している、当該サービスプログラムからのサービス要求の処理状態とを用いて、前記ネットワーク・プラットフォーム側における特定の機能を特定するステップ
をさらに含む付記４記載のサービス処理方法。
【００７０】
（付記６）
前記メッセージが、前記ネットワーク・プラットフォーム側における特定の機能の指定及び当該特定の機能において必要とされるパラメータを含むことを特徴とする付記１記載のサービス処理方法。
【００７１】
（付記７）
前記メッセージにおいて指定された、前記ネットワーク・プラットフォーム側における特定の機能について利用可否を判断するステップ
をさらに含む付記６記載のサービス処理方法。
【００７２】
（付記８）
前記ネットワーク・プラットフォーム側で提供される機能が複数あり、当該複数の機能のそれぞれは、ネットワークを介して接続されている複数のコンピュータのいずれかにおいて実現されており、
前記メッセージが、前記ネットワーク・プラットフォーム側において前記特定の機能を実現しているコンピュータのネットワーク・アドレスを含むことを特徴とする付記１記載のサービス処理方法。
【００７３】
（付記９）
前記ネットワーク・プラットフォーム側で提供される機能が複数あり、当該複数の機能のそれぞれは、ネットワークを介して接続されている複数のコンピュータのいずれかにおいて実現されており、
前記メッセージにおいて要求された、前記ネットワーク・プラットフォーム側における前記特定の機能を実現しているコンピュータを特定し、当該特定されたコンピュータに前記特定の機能による処理を依頼するステップ
をさらに含むことを特徴とする付記１記載のサービス処理方法。
【００７４】
（付記１０）
ネットワーク・プラットフォーム側で提供される機能のうちクライアントによって利用される機能の組み合わせが定義されているサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信するステップと、
受信した前記サービスプログラムを解析し、前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能か判断する判断ステップと、
前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能と判断された場合には、前記サービスプログラムに対して発行された識別情報を、前記クライアントの識別情報と対応付けてデータ格納部に格納するステップと、
前記サービスプログラムの識別情報を含む登録完了通知を前記クライアント端末に送信するステップと、
を含み、コンピュータにより実行されるサービス処理方法。
【００７５】
（付記１１）
前記サービスプログラムの識別情報が、前記ネットワーク・プラットフォーム側において発行されるか、または前記クライアントの側において発行されるものであることを特徴とする付記１０記載のサービス処理方法。
【００７６】
（付記１２）
前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能と判断された場合には、前記サービスプログラムの識別情報に対応して利用可能とされた機能の識別情報を第２データ格納部に格納するステップ
をさらに含む付記１０記載のサービス処理方法。
【００７７】
（付記１３）
付記１乃至１２記載のサービス処理方法をコンピュータに実行させるためのプログラム。
【００７８】
（付記１４）
ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせに関し前記クライアント側で定義され且つ前記ネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムを実行しているクライアント端末から、前記サービスプログラムの識別情報とクライアントの識別情報と特定の機能の要求動作の指定とを含むメッセージを受信する手段と、
クライアントの識別情報とサービスプログラムの識別情報とが対応付けられて格納されているデータ格納部を参照して、受信された前記メッセージに含まれる前記サービスプログラムの識別情報及び前記クライアントの識別情報の対応付けが登録されているか確認する確認手段と、
前記確認ステップにおいて確認が取れた場合に、前記メッセージにおいて要求された、前記ネットワーク・プラットフォーム側における前記特定の機能による処理を実施し、処理結果及び前記サービスプログラムの識別情報を含む応答を前記クライアント端末に送信する手段と、
を有するサービス処理装置。
【００７９】
（付記１５）
ネットワーク・プラットフォーム側で提供される機能のうちクライアントによって利用される機能の組み合わせが定義されているサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信する手段と、
受信した前記サービスプログラムを解析し、前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能か判断する判断手段と、
前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能と判断された場合には、前記サービスプログラムに対して発行された識別情報を、前記クライアントの識別情報と対応付けてデータ格納部に格納する手段と、
前記サービスプログラムの識別情報を含む登録完了通知を前記クライアント端末に送信する手段と、
を有するサービス処理装置。
【図面の簡単な説明】
【００８０】
【図１】本発明の一実施の形態におけるシステム概要図である。
【図２】（ａ）はＳＭＩを介してやりとりされるパケットの一例を示す図であり、（ｂ）はＳＣＩを介してやりとりされるパケットの一例を示す図である。
【図３】サービスプログラム登録処理の処理フローを示す図である。
【図４】サービスプログラム作成時にクライアント端末に表示される画面の一例を示す図である。
【図５】サービスプログラム登録処理の処理フローの第２の部分を示す図である。
【図６】クライアントデータ格納部に格納されるデータの一例を示す図である。
【図７】クライアントデータ格納部に格納されるデータの一例を示す図である。
【図８】（ａ）及び（ｂ）は、サービスプログラムの一例を示す図である。
【図９】クライアント端末からネットワーク・プラットフォームに送られるデータの処理概要を示す図である。
【図１０】（１）乃至（６）は各段階におけるデータの一例を示す図である。
【図１１】ネットワーク・プラットフォームからクライアント端末に送られるデータの処理概要を示す図である。
【図１２】図９の他の例を示す図である。
【図１３】サービスプログラムの一例を示す図である。
【図１４】ＳＣＩを介してサービスを利用する際の処理フローを示す図である。
【図１５】（１）乃至（４）はＳＣＩを介してサービスを利用する際に送信されるデータの一例を示す図である。
【図１６】ＳＣＩを介してサービスを利用する際の処理フローを示す図である。
【図１７】ＳＣＩを介してサービスを利用する際の処理フローを示す図である。
【図１８】コンピュータの機能ブロック図である。
【符号の説明】
【００８１】
１ オープンネットワーク ３ ゲートウェイ ５ サービス提供ネットワーク
７，９ クライアント端末 ５０ ネットワーク・プラットフォーム
７１，９１ 管理プログラム
５０１ 認証・認可機能モジュール ５０２ 課金機能モジュール
５０３ クライアント管理機能モジュール ５０４ セッション制御機能モジュール
５０５ コンテキスト管理機能モジュール ５０６ メディア変換機能モジュール
【技術分野】
【０００１】
本発明は、ネットワークサービスの提供技術に関する。
【背景技術】
【０００２】
インターネットに接続されているサーバ上に用意されたアプリケーションを、複数のユーザに使用させるサービスが存在している。このようなサービスにおいて、サーバ上のプログラムの組み合わせ方（ユーザ側から見れば使い方）はサービスの提供者により予め決められており、ユーザは、サーバ上の複数のプログラムを自由に組み合わせて使用することはできない。
【０００３】
例えば特開２０００−２３６３２６号公報には、ソフトウェアのメンテナンスを不要とし、相互通信サービスの利用時におけるソフトウェアの起動に関する制御等を不要とするための技術が開示されている。具体的には、クライアントはサーバアクセス用及び個人認証用の最小限のモジュールを保持する軽装端末とし、サーバは、軽装端末の動作に必要な共通ミドルウェア及びアプリケーションソフトウェアを保持するとともに、これらを管理する管理プログラムを有する管理サーバと、軽装端末との間で個人認証を行う認証サーバとして、各軽装端末は電源投入時及びサービス利用時に必要なソフトウェアを管理サーバからダウンロードするものである。このように必要なプログラムをクライアントにダウンロードするだけでは、多様なサービスの提供は不可能である。
【０００４】
また、例えば特開２０００−３４７９５８号公報には、データ通信量を低減させるとともに、コンピュータメモリの使用容量を節約するための技術が開示されている。具体的には、サーバが、クライアントに提供するプログラムを機能毎に分割して格納し、当該機能毎に分割して格納されているプログラムをクライアントが機能毎に選択できる。そして、当該選択されたプログラムのみがサーバからクライアントに対して提供されるように構成している。このため、必要な機能に関する印刷制御プログラムのみを選択して、クライアント側にダウンロードでき、サーバからクライアントへのデータ通信量を低減させることができるとともに、プログラムがダウンロードされるコンピュータのメモリ使用容量を節約することができる。この技術においては、クライアントによって規定されるプログラムの組み合わせについて何らの特徴付けはなされていない。
【０００５】
さらに、特開２００２−１８２９３７号公報には、クライアント端末とサーバとの間で少ないデータ量でもってダウンロードでき、所望のデータ処理を実行できるようにするための技術が開示されている。具体的には、クライアント端末で定義情報を入力し、サーバで設定情報を定義情報に対応して読み出してクライアント端末に送信し、設定情報に基づいて１又は複数の機能部品を呼び出す。機能部品は複数のデータ処理を共通の単位処理に分割しそこから抽出した処理ロジックを記述したものであって、クライアント端末又は処理サーバで１又は複数の機能部品に基づく処理ロジックによって単位処理プログラムを動的に生成し、生成された１又は複数の単位処理プログラムを設定情報に基づく条件に従って実行する。この技術では、単位処理プログラムの認可といった観点は存在していない。また、単位処理プログラムを複数種類実行する場合における問題などについては触れられていない。
【特許文献１】特開２０００−２３６３２６号公報
【特許文献２】特開２０００−３４７９５８号公報
【特許文献３】特開２００２−１８２９３７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上で述べたような従来技術には、クライアント側でサーバ側に用意された任意の機能を組み合わせ、クライアント側でネットワークを介して機能の組み合わせにつきサービスの提供を受ける際に、サービス提供の可否を判断したり、複数の組み合わせを識別したりすることについては考慮されていない。従って、ネットワーク・サービスの柔軟且つ適切な提供に問題がある。
【０００７】
従って、本発明の目的は、ネットワーク・サービスの柔軟且つ適切な提供を可能にするための新規な技術を提供することである。
【課題を解決するための手段】
【０００８】
本発明の第１の態様に係るサービス処理方法は、ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせに関しクライアント側で定義され且つネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムを実行しているクライアント端末から、サービスプログラムの識別情報とクライアントの識別情報と特定の機能の要求動作の指定とを含むメッセージを受信するステップと、クライアントの識別情報とサービスプログラムの識別情報とが対応付けられて格納されているデータ格納部を参照して、受信されたメッセージに含まれるサービスプログラムの識別情報及びクライアントの識別情報の対応付けが登録されているか確認する確認ステップと、確認ステップにおいて確認が取れた場合に、メッセージにおいて要求された、ネットワーク・プラットフォーム側における特定の機能による処理を実施し、処理結果及びサービスプログラムの識別情報を含む応答をクライアント端末に送信するステップとを含む。
【０００９】
このようにサービスプログラムの識別情報がサービス要求に含まれるので、メッセージへの応答の可否を確認することができ、さらに複数のサービス・プログラムが実行されている場合であっても識別して処理を進めることができる。なお、サービスプログラムの識別情報以外の要素をさらに用いて機能利用の可否を確認しても良い。
【００１０】
また、ネットワーク・プラットフォーム側に未登録のサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信するステップと、受信したサービスプログラムを解析し、サービスプログラム内に定義されている全機能をクライアントが利用可能か判断する判断ステップと、サービスプログラム内に定義されている全機能をクライアントが利用可能と判断された場合には、サービスプログラムに対して発行された識別情報をクライアントの識別情報と対応付けてデータ格納部に格納するステップと、サービスプログラムの識別情報を含む登録完了通知をクライアント端末に送信するステップとをさらに含むようにしてもよい。
【００１１】
このようにサービスプログラムにおいて定義されている全機能が利用可能かが予め確認されているので、サービス実行時にはサービスプログラムの識別情報を用いた確認が可能となる。
【００１２】
さらに、上で述べた判断ステップにおいて、クライアントの識別情報に対応して利用可能な機能の識別情報が格納されているクライアントデータ格納部をサービスプログラム登録要求に含まれるクライアントの識別情報を用いて検索し、サービスプログラムに定義されている全機能が抽出されるか判断するようにしてもよい。このようにすれば、容易にサービスプログラムの確認を行うことができるようになる。
【００１３】
また本発明の第２の態様に係る情報処理方法は、ネットワーク・プラットフォーム側で提供される機能のうちクライアントによって利用される機能の組み合わせが定義されているサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信するステップと、受信したサービスプログラムを解析し、サービスプログラム内に定義されている全機能をクライアントが利用可能か判断する判断ステップと、サービスプログラム内に定義されている全機能をクライアントが利用可能と判断された場合には、サービスプログラムに対して発行された識別情報を、クライアントの識別情報と対応付けてデータ格納部に格納するステップと、サービスプログラムの識別情報を含む登録完了通知をクライアント端末に送信するステップとを含む。このような処理を実施すれば、自動的にサービスプログラムの確認を行うことができるようになる。
【００１４】
本発明に係るサービス処理方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
【発明の効果】
【００１５】
本発明によれば、ネットワーク・サービスの柔軟且つ適切な提供が可能となる。
【発明を実施するための最良の形態】
【００１６】
図１に本発明の一実施の形態に係るシステム概要図を示す。インターネット等のオープンネットワーク１には、複数のクライアント端末（ＣＴ：Client Terminal）が接続されている。また、オープンネットワーク１は、ゲートウェイ（ＧＷ：Gateway）３を介してサービス提供ネットワーク５に接続されている。サービス提供ネットワーク５においては、以下に説明するネットワーク・プラットフォーム（ＮＰ）５０が構築されている。
【００１７】
ネットワーク・プラットフォーム５０には、共通機能モジュールとして、認証・認可機能モジュール５０１と、課金機能モジュール５０２と、ＣＴ管理機能モジュール５０３とが設けられている。認証・認可機能モジュール５０１は、クライアント認証、端末認証、サービス認可等を行う。課金機能モジュール５０２は、例えばクライアント毎に機能モジュールの使用回数等の課金に必要なデータを収集し、例えばクライアント毎の課金データを生成する。ＣＴ管理機能モジュール５０３は、各機能モジュールの版数管理、クライアント端末の状態管理、クライアント端末への機能モジュールのダウンロード制御、及び以下で説明するサービスプログラムの登録確認、サービスＩＤの発行などを行う。
【００１８】
また、ネットワーク・プラットフォーム５０には、個別機能モジュールとして、セッション制御（例えばＳＩＰ（Session Initiation Protocol））を行うセッション制御機能モジュール５０４、クライアントのプレゼンス・データを管理するコンテキスト管理機能モジュール５０５、メディア変換機能モジュール５０６などの機能モジュールが設けられている。図１では３つの個別機能モジュールを示しているが、他の機能モジュールが設けられる場合もある。さらに、ネットワーク・プラットフォーム５０には、個別機能モジュール等が共通して使用するコモンアプリケーション＃１、＃２、＃３なども設けられている。
【００１９】
一方、クライアント端末には、１又は複数のサービスプログラムと、１又は複数のクライアント機能モジュールと、管理プログラムとが設けられている。図１の例では、クライアント端末７には、サービスプログラム＃１及び＃２と、クライアント機能モジュールＡ及びＢと、管理プログラム７１が設けられている。クライアント機能モジュールについては、ネットワーク・プラットフォーム５０からダウンロードした機能モジュールである場合もあれば、予めクライアント端末に用意されている機能モジュールの場合もある。また、クライアント端末９には、サービスプログラム＃３と、クライアント機能モジュールＣと、管理プログラム９１とが設けられている。
【００２０】
さらに、ネットワーク・プラットフォーム５０内には、コモンアプリケーションと個別機能モジュールとの間にＮＰ−ＡＰＩ（Application Program Interface）が規定されている。また、クライアント端末内には、サービスプログラムとクライアント機能モジュールとの間にＣＴ−ＡＰＩが規定されている。例えばクライアント端末においてサービスプログラムは、ＣＴ−ＡＰＩを介してクライアントの機能モジュールを用いるようになっている。さらに、クライアント端末とネットワーク・プラットフォーム５０との間に、サービス管理インターフェース（ＳＭＩ：Service Management Interface）と、サービス制御インターフェース（ＳＣＩ：Service Control Interface）とが規定されている。サービスプログラムは、ＳＣＩを介してクライアント端末のユーザが望むサービスが、ネットワーク・プラットフォーム５０から提供されるように、定義される。
【００２１】
次に、サービス管理インターフェースＳＭＩについて説明する。ネットワーク・プラットフォーム５０は、ネットワーク・プラットフォーム５０において公開している機能モジュールとその機能を実行する際に必要なパラメータをＳＭＩを介して公開しており、クライアント端末のユーザ又はクライアント・システムの構築者は、ＳＭＩを介してネットワーク・プラットフォーム５０から必要な情報を取得してサービスプログラム作成を行う。
【００２２】
ＳＭＩを介してやりとりされるパケットの形式は、例えば図２（ａ）に示すようなものである。すなわち、ＩＰアドレスなどのネットワーク・アドレスを含むパケット・ヘッダと、クライアントＩＤと、端末ＩＤと、動作データとが含まれる。動作データについては、クライアント端末からのパケットであれば例えばサービス要求内容（サービスプログラム登録要求、機能ダウンロード要求、版数管理要求、状態管理要求など）が含まれ、ネットワーク・プラットフォーム５０からのパケットであれば例えば処理結果や要求データが含まれる。また、ＳＣＩを介してやりとりされるパケットの形式は、例えば図２（ｂ）に示すようなものである。すなわち、ＩＰアドレスなどのネットワーク・アドレスを含むパケットヘッダと、クライアントＩＤと、端末ＩＤと、サービスプログラムのＩＤであるサービスＩＤと、動作データとを含む。動作データについては、クライアント端末からのパケットであれば例えば起動すべき機能モジュールのＩＤ及び必要なパラメータを含み、ネットワーク・プラットフォーム５０からのパケットであれば例えば処理結果が含まれる。
【００２３】
また、サービス提供ネットワーク５には、ＮＰ運用管理機能も用意されており、ＮＰ運用管理インターフェースを介してＮＰ運用管理機能によりネットワーク・プラットフォーム５０について各種管理を行う。なお、ＮＰ運用管理機能については本実施の形態の主要部ではないので、これ以上説明は行わない。
【００２４】
サービスプログラムの作成及び登録については図３乃至図７を用いて説明する。例えばクライアント端末７における管理プログラム７１は、ＳＭＩを介してサービスプログラム作成要求をネットワーク・プラットフォーム５０に送信する（ステップＳ１）。ネットワーク・プラットフォーム５０のＣＴ管理機能モジュール５０３は、クライアント端末７からサービスプログラム作成要求を受信し（ステップＳ３）、サービスプログラム作成要素データをＳＭＩを介してクライアント端末７に送信する（ステップＳ５）。クライアント端末７の管理プログラム７１は、ネットワーク・プラットフォーム５０からサービスプログラム作成要素データを受信し（ステップＳ７）、当該サービスプログラム作成要素データを用いてサービスプログラム作成画面を表示する（ステップＳ９）。例えば図４に示すような画面が表示される。図４の例では、サービスプログラム開発ウインドウと、サービスプログラムのロジックのテンプレート・ウインドウとが表示されている。サービスプログラム開発ウインドウには、ネットワーク・プラットフォーム５０において公開されている機能モジュールのリストが含まれ、ここではＳＩＰ、ＲＳＶＰ（Resource Reservation Setup Protocol）−ＴＥ（Traffic Engineering）、コンテキスト管理、ＲＦＩＤ（Radio Frequency-ID）ミドル、メディア変換などの項目が列挙されている。また、各項目をクリックすると、当該項目に係る機能モジュールの機能概要及び入力パラメータ情報が表示されるようになっている。なお、図４ではＳＩＰを選択した場合を示しており、機能概要及び入力パラメータについてはポップアップウインドウなどにて表示しても良い。テンプレート・ウインドウでは、典型的な処理ロジックが選択可能となっており、図４の例では第１段階で何らかの処理を行って、第２段階で条件を判断し、第３段階で条件によって異なる処理を行うというロジックの例が示されている。クライアント端末７のユーザは、サービスプログラム開発ウインドウに表示された内容を参照しつつ、テンプレート・ウインドウに今回作成するサービスプログラムのロジックに合致するロジックを表示させ、各ブロックで行う処理、使用する機能モジュールのＩＤ、必要なパラメータを入力する。
【００２５】
なお、クライアント端末７の管理プログラム７１は、必要な機能モジュールがクライアント端末７に存在するか確認する（ステップＳ１１）。もし、必要な機能モジュールがクライアント端末７に存在しないと判断した場合には、ネットワーク・プラットフォーム５０に対して必要な機能モジュールについて機能モジュール要求をＳＭＩを介して送信する（ステップＳ１３）。ネットワーク・プラットフォーム５０のＣＴ管理機能モジュール５０３は、クライアント端末７から機能モジュール要求を受信する（ステップＳ１５）。ネットワーク・プラットフォーム５０のＣＴ管理機能モジュール５０３は、受信した機能モジュール要求のパケットに含まれるクライアントＩＤ等から、要求に係る機能モジュールの送信可否を判断することもある。但し、ネットワーク・プラットフォーム５０を利用する上で必要な基本的な機能モジュールであれば、特にチェックする必要はない。ＣＴ管理機能モジュール５０３は、機能モジュール格納部５１１から要求に係る機能モジュールを読み出し、ＳＭＩを介してクライアント端末７に送信する（ステップＳ１７）。クライアント端末７の管理プログラム７１は、ネットワーク・プラットフォーム５０から要求機能モジュールを受信すると、クライアント端末の記憶装置に格納する（ステップＳ１９）。
【００２６】
ステップＳ１１において必要な機能モジュールがクライアント端末７に存在すると判断された場合及びステップＳ１９の後に、クライアント端末７の管理プログラム７１は、例えば図４に示したような画面において、ユーザからのサービスプログラム作成指示を受け付ける（ステップＳ２１）。ネットワーク・プラットフォーム５０において利用可能な機能モジュールのＩＤ及び必要な入力パラメータのセットが、ロジックを表すテンプレートのブロックにおいて指定されており、ロジックに必要な条件等のデータも指定される。処理は端子Ａを介して図５の処理に移行する。
【００２７】
そして、クライアント端末７の管理プログラム７１は、受け付けた入力データに従ってサービスプログラムを生成し、クライアント端末７の記憶装置に格納する（ステップＳ２３）。そして、管理プログラム７１は、サービスプログラムを含むサービスプログラム登録要求を、ネットワーク・プラットフォーム５０に送信する（ステップＳ２５）。ネットワーク・プラットフォーム５０のＣＴ管理機能モジュール５０３は、クライアント端末７からサービスプログラムを含むサービスプログラム登録要求を受信し、記憶装置に格納する（ステップＳ２７）。そして、ＣＴ管理機能モジュール５０３は、クライアントデータ格納部５１３を参照して、受信したサービスプログラムに対するチェック処理を実施する（ステップＳ２９）。例えば、クライアントデータ格納部５１３には、図６に示すようなデータが格納されている。図６の例では、クライアントＩＤに対応して利用可能な機能モジュールのＩＤが登録されている。このような簡単なテーブルではなく、クライアントの所属が定義されたテーブルと、所属と利用可能な機能モジュールのＩＤとの対応テーブルとを組み合わせる場合もある。サービスプログラム登録要求に含まれるクライアントＩＤを用いて図６に示すようなテーブルを検索して利用可能な機能モジュールのＩＤを特定し、サービスプログラムにおいて規定されている全機能モジュールが利用可能か、すなわちサービスプログラムの利用を認可できるか判断する（ステップＳ３１）。もし、利用不可能な機能モジュールがサービスプログラム中に規定されている場合には、ＣＴ管理機能モジュール５０３は、登録拒否通知をクライアント端末７に送信する。クライアント端末７の管理プログラム７１は、ネットワーク・プラットフォーム５０から登録拒否通知を受信し、表示装置に表示する（ステップＳ３３）。これにて作成したサービスプログラムに問題があることを認識することができる。
【００２８】
一方、クライアント端末７から受信したサービスプログラムにおいて規定されている全機能モジュールが利用可能であると判断された場合には、ＣＴ管理機能モジュール５０３は、当該サービスプログラムに対してサービスＩＤを発行し、クライアントデータ格納部５１３に登録する（ステップＳ３５）。例えば、図７に示すように、クライアントＩＤに対応してサービスＩＤが登録される。なお、サービスプログラム自体又は定義されている全機能モジュールのＩＤ群をクライアントデータ格納部５１３又は他のデータ格納部にクライアントＩＤに対応付けて登録するようにしても良い。サービスＩＤについては、ネットワーク・プラットフォーム５０全体においてサービスＩＤがユニークである場合、又はクライアント又はクライアントの集合毎にユニークである場合がある。前者の場合には、ネットワーク・プラットフォーム側でサービスＩＤを発行・管理する必要がある。後者は、クライアントＩＤ毎にそれぞれサービスＩＤを発行・管理し、両ＩＤを組み合わせてサービスプログラムを特定する場合である。この場合は、クライアント側でサービスＩＤを発行し、それをネットワーク・プラットフォーム側に登録することが可能になる為、後者の方が分散管理がしやすいといえる。そして、ＣＴ管理機能モジュール５０３は、発行されたサービスＩＤを含む登録完了通知をクライアント端末７にＳＭＩを介して送信する（ステップＳ３７）。
【００２９】
クライアント端末７の管理プログラム７１は、ネットワーク・プラットフォーム５０からサービスＩＤを含む登録完了通知を受信し、受信されたサービスＩＤを含むサービスプログラムを、利用可能なサービスプログラムとしてクライアント端末７の記憶装置に格納する（ステップＳ３９）。このようにすれば、ＳＣＩを介してネットワーク・プラットフォーム５０に対してサービスを要求する際に、図２（ｂ）に示すようなパケットを生成して送信することができ、ネットワーク・プラットフォーム５０からは、ユーザにカスタマイズされたサービスプログラムにおいて規定されたサービスを受けることができるようになる。
【００３０】
なお、図３及び図５の処理フローでは、クライアント端末のための機能モジュールをステップＳ１１乃至Ｓ１９で必要であればダウンロードするような構成を示したが、例えば登録完了通知を受信した後に、サービスプログラムの実行に必要となる機能モジュールをさらにダウンロードするようにしても良い。また、ステップＳ１１乃至Ｓ１９を実施せず、登録完了通知を受信した後にサービスプログラムの実行に必要となる機能モジュールをダウンロードするようにしても良い。
【００３１】
ここで、サービスプログラムについて説明を加えておく。サービスプログラムについては、サービスプログラムを実行させるクライアントに許可された機能モジュールを利用する限りにおいて自由に構成することができる。図８（ａ）に示すように、サービス＃ａとして、まず状況理解（例えば機能モジュール＃ｃの起動）を実施し（Ｓ１００１）、状況理解の結果として状況＃Ｘであるか状況＃Ｙのいずれであるかを判定し（Ｓ１００３）、状況＃Ｙであれば機能モジュール＃ｂを起動し（Ｓ１００５）、その後結果待ちとするか、状況＃Ｘであれば機能モジュール＃ａを起動し（Ｓ１００７）、状況理解（例えば機能モジュール＃ｃの起動）を実施し（Ｓ１００９）、状況理解の結果として状況＃Ｚであるか状況＃Ｗであるかを判定し（Ｓ１０１１）、状況＃Ｚであれば機能モジュール＃ａを起動し（Ｓ１０１５）、その後結果待ちとするか、状況＃Ｗであれば機能モジュール＃ｂを起動し（Ｓ１０１３）、その後結果待ちとするような定義が行われている。このように、必要な機能の利用及び必要なパラメータの設定を全て行うようにしても良いし、Ｓ１００７乃至Ｓ１０１５について別途サービス＃ｂと定義済みであれば、図８（ａ）のブロック８０１の代わりに、図８（ｂ）に示すようにサービス＃ｂ起動（Ｓ１０２１）の規定を行っても良い。
【００３２】
次に、図９乃至図１２を用いて、本実施の形態におけるメッセージ及びパケットの組立、分解、及び振分方法について説明する。なお、ここではＳＣＩを介した通信について説明する。図９で示すように、サービスプログラム＃１又はサービスプログラム＃２は、動作データ（例えば特定の機能モジュールの起動要求及び必要なパラメータ）を生成すると、動作データをメッセージ組み立て機能モジュール７２に出力する。メッセージ組み立て機能モジュール７２に出力されるデータは、図１０（１）に示されるようなデータである。基本的には、動作データだけであるが、サービスプログラムを識別するために動作データと共にサービスＩＤが出力される場合もある。メッセージ組み立て機能モジュール７２は、さらに端末ＩＤ及びクライアントＩＤを付加してパケット組立部７３に出力する。すなわち、図１０（２）に示すようなデータがメッセージとして構成される。なお、メッセージ組立機能モジュール７２とパケット組立部７３とのインターフェースは、通常の通信インターフェースであり、パケット組立部７３は、特定の通信プロトコルに従って例えば図１０（３）に示すようなネットワーク・アドレスを含むパケットヘッダを付加する。
【００３３】
次に、ネットワーク・プラットフォーム５０においては、パケット分解部５２１が、特定の通信プロトコルに従ってクライアント端末からのパケットを受信して、当該パケットに含まれるメッセージ（動作データ、サービスＩＤ、端末ＩＤ及びクライアントＩＤ）を抽出し、通信インターフェースを介してメッセージ分解機能モジュール５２２に出力する。メッセージは図１０（４）に示されるようなデータである。メッセージ分解機能モジュール５２２は、メッセージを受け取ると、クライアントＩＤ、端末ＩＤ、サービスＩＤ及び動作データを分解して、クライアントＩＤ、端末ＩＤ、サービスＩＤを認証・認可機能モジュール５０１及び課金機能モジュール５０２に出力する。なお、応答の返信のため、パケット分解部５２１が、パケットヘッダに含まれるネットワーク・アドレスをメッセージ分解機能モジュール５２２に出力し、メッセージ分解機能モジュール５２２において、クライアントＩＤ、端末ＩＤ又はサービスＩＤに対応してネットワーク・アドレスを記憶装置に格納しておく場合もある。
【００３４】
認証・認可機能モジュール５０１は、クライアントデータ格納部５１３を参照して、クライアントＩＤ及びサービスＩＤを用いてサービス認可を行う。但し、従来どおり、クライアントＩＤ及び端末ＩＤにてネットワーク・プラットフォーム５０の利用可否を判断し、別途クライアントＩＤとパスワードなどのデータにより本人認証を行う。また、課金機能モジュール５０２は、主にクライアントＩＤを用いて課金処理を実施する。なお、サービスＩＤ等をさらに用いて課金処理を実施する場合もある。そうすると、例えば使用する機能毎に料金が異なる場合には、サービスＩＤから利用した機能を特定して機能毎の利用状況を特定して、請求を行うことができる。なお、端末ＩＤについては、複数の端末に同一のＩＤを付与したり、端末ＩＤにより特定のグループに属する端末であることを特定することができるため、端末ＩＤも、あるユーザグループが１つの端末を使用するときの課金に用いる場合もある。さらに、不特定多数のユーザの利用を想定した公共端末等の場合には、あるクライアントが定義したサービスを実行することを認可するか否かを端末ＩＤを用いて判断するようにしても良い。例えば、公共端末をある特定のサービス提供用に限定したいようなケースにおいては、端末ＩＤに対して、そのサービス、すなわちサービスプログラムだけを実行するようにすることも可能である。
【００３５】
なお、認証・認可機能モジュール５０１は、さらに、クライアントデータ格納部５１３を参照して、図６に示すようなクライアントＩＤと利用可能な機能モジュールのＩＤとの対応付けに基づき、動作データにおいて指定されている起動機能モジュールの利用可否を判断するようにしても良い。この際、起動機能モジュールの特定については、認証・認可機能モジュール５０１が行っても良いし、以下で述べるメッセージディスパッチャ５２３によって行っても良い。又は、図６のようなデータではなく、クライアントＩＤと登録サービスプログラム又は登録サービスプログラムにおいて定義されている全機能モジュールのＩＤ群との対応付けから判断する場合もある。
【００３６】
そして、クライアントＩＤ及びサービスＩＤによるサービス認可が得られると、メッセージ分解機能モジュール５２２は、図１０（５）及び（６）に示すように、動作データのみ、又は動作データ及びサービスＩＤをメッセージディスパッチャ５２３に出力する。メッセージディスパッチャ５２３は、動作データを解析して出力先の機能モジュールを特定して、当該機能モジュールに動作データを出力する。図１０（５）及び（６）に示すように、この際メッセージディスパッチャ５２３は、どのサービスプログラムによる要求であるかを識別するためサービスＩＤを付加して出力する場合もある。
【００３７】
なお、メッセージディスパッチャ５２３が、クライアントデータ格納部５１３（図６等）を参照して、動作データにおいて指定されている利用機能モジュールの利用可否を判断するようにしても良い。また、基本的には動作データには、利用（すなわち起動）される機能モジュールの指定が含まれるが、機能モジュールの指定を含まないようにして必要なパラメータのみを含むようにしても良い。このような場合には、例えばクライアントＩＤ及びサービスＩＤとサービスプログラム自体又はサービスプログラムにおいて定義されている全機能モジュールのＩＤ群との対応付けをサービスプログラムデータ格納部５１４に登録しておき、クライアントＩＤ及びサービスＩＤにより特定されるサービスプログラムにおける状態を動作データに含まれるパラメータにて特定し、当該サービスプログラムにおける状態に応じてパラメータを出力すべき機能モジュールを特定するようにしてもよい。
【００３８】
このようにしてクライアント端末におけるサービスプログラムの要求がネットワーク・プラットフォーム５０における適切な機能モジュールに伝達される。
【００３９】
次に、ネットワーク・プラットフォーム５０からクライアント端末に応答を返す場合の処理を図１１を用いて説明する。まず、ネットワーク・プラットフォーム５０における機能モジュール＃１又は機能モジュール＃２は動作データ（処理結果）又は動作データ及びサービスＩＤをメッセージ組み立て機能モジュール５２４に出力する。出力されるデータは、図１０（１）と同様である。また、メッセージ組み立て機能モジュール５２４は、要求元クライアントを特定し、端末ＩＤ、クライアントＩＤをさらに付加してメッセージを構成し、パケット組立部５２５に出力する。構成されたメッセージは、図１０（２）に示したようなデータである。要求元クライアントの特定については、図９のメッセージ分解機能モジュール５２２及びメッセージディスパッチャ５２３と連携することにより行うか、又は図７に示したデータ及びクライアントＩＤに対応して端末ＩＤ等が格納されているクライアントデータ格納部５１３を利用するなどにて行われる。そして、パケット組立部５２５は、クライアントＩＤ又は端末ＩＤに対応するネットワーク・アドレスを含むパケットヘッダを含むパケットを生成して、クライアント端末に送信する。送信されるパケットは、図１０（３）と同様である。
【００４０】
クライアント端末においては、パケット分解部７４は、図１０（３）のようなパケットを受信すると、パケットヘッダを取り除き、メッセージ部分をメッセージ分解機能モジュール７５に出力する。メッセージ部分の構成は図１０（４）と同様である。そして、メッセージ分解機能モジュール７５は、メッセージに含まれる動作データ、又は動作データ及びサービスＩＤを抽出し、メッセージディスパッチャ７６に出力する。この段階で出力されるデータは、図１０（５）又は（６）と同様である。メッセージディスパッチャ７６は、動作データを解析するか又はサービスＩＤに従って、サービスプログラム＃１又はサービスプログラム＃２に動作データ又は動作データ及びサービスＩＤを出力する。
【００４１】
このような処理を行うことにより、動作データが適切にクライアント端末とネットワーク・プラットフォーム間でやり取りされるようになる。なお、ネットワーク・アドレスと機能モジュールとは直接関係付けられていないので、ネットワーク・プラットフォーム５０における機能モジュールの追加や変更をわざわざクライアント端末に通知する必要はないというメリットもある。
【００４２】
なお、図９乃至図１１では、ネットワーク・プラットフォーム５０に１つのネットワーク・アドレスを割り当てておき、ネットワーク・プラットフォーム５０においてメッセージの分解及び振分を行っていた。しかし、図１２に示すように、ネットワーク・プラットフォーム５０内の各機能モジュールにネットワーク・アドレス（ＮＡ）を割り当てておき、クライアント端末のパケット組立部７９において、メッセージの宛先となる機能モジュール（ここでは機能モジュール＃ｂ）のＮＡを含むパケットヘッダを当該メッセージに付加してパケット１２０２を構成し、ネットワーク機器１２０１において、パケット１２０２の宛先ネットワーク・アドレスに基づき、ネットワーク・プラットフォーム５０の指定された機能モジュール（ここでは＃ｂ）にパケット１２０２を転送するようにしてもよい。なお、課金や認証・認可の処理が必要であるため、パケット１２０２が認証・認可機能モジュール５０１と課金機能モジュール５０２とにコピーされて転送される場合もある。
【００４３】
なお、図１２のような構成を採用しても良いが、クライアント端末側では、メッセージを分析してネットワーク・プラットフォーム５０における機能モジュールを特定し、当該機能モジュールのネットワーク・アドレスを特定する機能が必要となる。但し、この方がネットワーク・プラットフォーム５０側の処理負荷は下がる。一方、ネットワーク・プラットフォーム５０における内部機構を外部に公開する必要があり、機能モジュールの追加や変更毎にクライアント端末に通知して設定の変更などを行う必要がある。図９乃至図１１のような構成を採用するか、図１２のような構成を採用するかは、ネットワーク全体の構成を踏まえて決定される。
【００４４】
次に、図９乃至図１２に示したメッセージ及びパケットの組立、分解、及び振分方法を前提に、図１３乃至図１７を用いて、メッセージのやりとりについての具体的な処理フローを説明する。ここでは、例えばクライアント端末７におけるサービスプログラム＃１において、図１３に示すようなロジックが定義されているものとする。このサービスプログラムの例においては、クライアント端末７のユーザが広告配信を行うために、まず配信先の相手の状況を問い合わせ（状況理解）、相手の状況に応じて異なる配信方法で広告を送付する処理を行うものを想定している。すなわち、最初に特定の端末（又はユーザ）についての状況理解としてコンテキスト管理を行う機能モジュール＃ｃに対して問い合わせを行い、問い合わせへの応答に基づき状況判定を行い、特定の端末の状況が状況＃Ｘであれば機能モジュール＃ａを起動し、状況＃Ｙであれば機能モジュール＃ｂが起動されるように、サービスプログラム＃１が規定されているものとする。また、サービスＩＤが＃０７０３であり、端末ＩＤが＃９３６であり、クライアントＩＤが＃５３１であるものとする。
【００４５】
そうすると、クライアント端末７のサービスプログラム＃１等は、特定の端末についての状況理解を行うため、機能モジュール＃ｃの起動要求メッセージを生成し、メインメモリ等の記憶装置に格納する（ステップＳ５１）。起動要求メッセージには、クライアントＩＤ”＃５３１”と端末ＩＤ”＃９３６”とサービスＩＤ”＃０７０３”と機能モジュール＃ｃの起動要求と特定の端末の識別情報（又は特定のユーザの識別情報）が含まれる。そして、クライアント端末７のパケット組立部７３は、生成された起動要求メッセージと宛先ネットワーク・アドレスを含むパケットを生成し、ネットワーク・プラットフォーム５０に送信する（ステップＳ５３）。例えば、図１５の（１）に示すようなパケットが生成され、送信される。
【００４６】
一方ネットワーク・プラットフォーム５０のパケット分解部５２１は、クライアント端末７から機能モジュール＃ｃの起動要求メッセージを含むパケットを受信し、記憶装置に格納する（ステップＳ５５）。そして、パケットから機能モジュール＃ｃの起動要求メッセージを抽出する（ステップＳ５７）。また、上でも述べたように、メッセージ分解機能モジュール５２２は、起動要求メッセージに含まれるクライアントＩＤ、端末ＩＤ、サービスＩＤを抽出し、認証・認可機能モジュール５０１及び課金機能モジュール５０２に出力する。認証・認可機能モジュール５０１は、クライアントＩＤ及び端末ＩＤについて確認を行い、課金機能モジュール５０２は、課金処理を実施する（ステップＳ５９）。さらに、認証・認可機能モジュール５０１は、サービスＩＤ及びクライアントＩＤを用いて当該機能モジュール＃ｃの起動要求を認可できるか確認する（ステップＳ６１）。もし、ステップＳ５９又はＳ６１で問題が検出されれば、クライアント端末７に対して要求処理を実施できない旨のメッセージを返信する。一方、ステップＳ５９及びＳ６１で問題が検出されない場合には、メッセージ分解機能モジュール５２２から動作データ（ここでは機能モジュール＃ｃの起動要求及びパラメータ）又は動作データ及びサービスＩＤがメッセージディスパッチャ５２３に出力され、メッセージディスパッチャ５２３は、動作データを解析し、当該動作データを機能モジュール＃ｃにディスパッチする（ステップＳ６３）。なお、起動であれば、必要なパラメータを渡して起動させる。
【００４７】
上でも述べたが、機能モジュール＃ｃを起動する前に、機能モジュール＃ｃ自体の利用可否（起動可否）を判断するようにしても良い。この場合には、クライアントデータ格納部５１３内の図６のようなデータを参照して判断しても良いし、さらに上で述べたようにサービスプログラムデータ格納部５１４に格納された、クライアントＩＤとサービスプログラム自体又はサービスプログラムに規定されている機能モジュールのＩＤ群との対応付けを参照して判断しても良い。
【００４８】
機能モジュール＃ｃは、動作データに基づき処理を行い（ステップＳ６５）、実行結果（ここでは”機能＃ｃ実行結果：状況Ｙ”（例えばユーザＡは携帯電話機を持って電車に乗っている））を含む動作データを生成し、当該動作データ又は動作データ及びサービスＩＤを、メッセージ組み立て機能モジュール５２４に出力する。メッセージ組み立て機能モジュール５２４は、クライアントＩＤ”＃５３１”、端末ＩＤ”＃９３６”及びサービスＩＤ”＃０７０３”を付加してメッセージを生成し（ステップＳ６７）、パケット組立部５２５は、実行結果を含むメッセージにパケットヘッダを付加してパケットを生成し、クライアント端末７に送信する（ステップＳ６９）。本ステップで送信されるパケットは、例えば図１５（２）のようなパケットである。
【００４９】
クライアント端末７のパケット分解部７４は、ネットワーク・プラットフォーム５０から実行結果メッセージを含むパケットを受信し、例えばメインメモリ等の記憶装置に格納する（ステップＳ７１）。処理は端子Ｂを介して図１６に移行する。そして、パケット分解部７４は、実行結果メッセージ部分を抽出してメッセージ分解機能モジュール７５に出力する（ステップＳ７３）。メッセージ分解機能モジュール７５は、実行結果メッセージから実行結果を含む動作データ又は動作データ及びサービスＩＤを抽出し、メッセージディスパッチャ７６に出力し、メッセージディスパチャ７６は、動作データを動作データの要求元であるサービスプログラム＃１に出力する。
【００５０】
サービスプログラム＃１は、動作データに含まれる実行結果を解析し、図１３のようなサービスプログラムであれば状況判定を行う（ステップＳ７５）。図１５（２）の例では、状況＃Ｙであることが分かるので、機能モジュール＃ｂを起動させることになる。例えば、ＳＩＰを用いてＶｏＩＰ（Voice Over IP）にて発呼する。従って、サービスプログラム＃１は、解析結果に従って、機能モジュール＃ｂの起動要求メッセージを生成し（ステップＳ７７）、メインメモリ等の記憶装置に格納する。起動要求メッセージには、クライアントＩＤ”＃５３１”と端末ＩＤ”＃９３６”とサービスＩＤ”＃０７０３”と機能モジュール＃ｂの起動要求と発呼先ＳＩＰ−ＵＲＬ等のパラメータとが含まれる。そして、クライアント端末７のパケット組立部７３は、生成された起動要求メッセージと宛先ネットワーク・アドレスを含むパケットを生成し、ネットワーク・プラットフォーム５０に送信する（ステップＳ７９）。例えば、図１５の（３）に示すようなパケットが生成され、送信される。
【００５１】
一方ネットワーク・プラットフォーム５０のパケット分解部５２１は、クライアント端末７から機能モジュール＃ｂの起動要求メッセージを含むパケットを受信し、記憶装置に格納する（ステップＳ８１）。そして、パケットから機能モジュール＃ｂの起動要求メッセージを抽出する（ステップＳ８３）。また、上でも述べたように、メッセージ分解機能モジュール５２２は、起動要求メッセージに含まれるクライアントＩＤ、端末ＩＤ、サービスＩＤを抽出し、認証・認可機能モジュール５０１及び課金機能モジュール５０２に出力する。認証・認可機能モジュール５０１は、クライアントＩＤ及び端末ＩＤについて確認を行い、課金機能モジュール５０２は、課金処理を実施する（ステップＳ８５）。さらに、認証・認可機能モジュール５０１は、サービスＩＤ及びクライアントＩＤを用いて当該機能モジュール＃ｂの起動要求を認可できるか確認する（ステップＳ８７）。もし、ステップＳ８５又はＳ８７で問題が検出されれば、クライアント端末７に対して要求処理を実施できない旨のメッセージを返信する。一方、ステップＳ８５及びＳ８７で問題が検出されない場合には、メッセージ分解機能モジュール５２２から動作データ（ここでは機能モジュール＃ｂの起動要求及びパラメータ）又は動作データ及びサービスＩＤがメッセージディスパッチャ５２３に出力され、メッセージディスパッチャ５２３は、動作データを解析し、当該動作データを機能モジュール＃ｂにディスパッチする（ステップＳ８９）。なお、起動であれば、必要なパラメータを渡して起動させる。上でも述べたようにこの段階においても機能起動の可否を判断するようにしても良い。
【００５２】
機能モジュール＃ｂは、動作データに基づき処理を行い（ステップＳ９１）、実行結果（ここでは”機能＃ｂ実行結果”）を含む動作データを生成し、当該動作データ又は動作データ及びサービスＩＤを、メッセージ組み立て機能モジュール５２４に出力する。処理は端子Ｃを介して図１７の処理に移行する。
【００５３】
そして、メッセージ組み立て機能モジュール５２４は、クライアントＩＤ”＃５３１”、端末ＩＤ”＃９３６”及びサービスＩＤ”＃０７０３”を付加してメッセージを生成し（ステップＳ９３）、パケット組立部５２５は、実行結果を含むメッセージにパケットヘッダを付加してパケットを生成し、クライアント端末７に送信する（ステップＳ９５）。本ステップで送信されるパケットは、例えば図１５（４）のようなパケットである。
【００５４】
クライアント端末７のパケット分解部７４は、ネットワーク・プラットフォーム５０から実行結果メッセージを含むパケットを受信し、例えばメインメモリ等の記憶装置に格納する（ステップＳ９７）。そして、パケット分解部７４は、実行結果メッセージ部分を抽出してメッセージ分解機能モジュール７５に出力する（ステップＳ９９）。メッセージ分解機能モジュール７５は、実行結果メッセージから実行結果を含む動作データ又は動作データ及びサービスＩＤを抽出し、メッセージディスパッチャ７６に出力し、メッセージディスパッチャ７６は、動作データを動作データの要求元であるサービスプログラム＃１に出力する。
【００５５】
サービスプログラム＃１は、動作データに含まれる実行結果を解析し（ステップＳ１０１）、解析結果に従って必要な処理を実施する（ステップＳ１０３）。
【００５６】
このようにサービスＩＤが付加されたメッセージがやりとりされて、サービスプログラムに従って処理が行われていく。
【００５７】
また、上で述べたようなネットワークサービス提供のための各種ＡＰＩが用意されており、クライアント端末のユーザ又はソフトウエア開発者は、必要に応じて機能モジュールを組み合わせて使用するようなサービスプログラムを作成することができる。また、サービスプログラムは、クライアント端末だけではなくネットワーク・プラットフォーム５０側などネットワーク上に保存しておくことができ、必要に応じてダウンロードして、ユーザは自らの端末を使用しているがごとく他の端末を用いて所定のサービスを利用することも可能である。さらに、特定のサービスを利用する場合にはサービスプログラムだけを用意すればよいので、特定のサービス全体をシステム化するより開発工数及び期間を減らすことができる。また、サービスプログラム自身の更新は容易であり、ネットワーク・プラットフォーム５０側の機能モジュールが更新されれば全てのクライアントが改良された機能を利用可能となる。さらに、必要に応じてクライアント端末には機能モジュールをダウンロードできるため、元々機能をあまり有さない端末であっても多様な、また高度なサービスを利用することができるようになる。
【００５８】
また、本実施の形態ではサービスＩＤを含むメッセージ（ネットワーク上ではパケット）を交換するようになっているが、これによりクライアント端末では、複数のサービスプログラムを同時に実行させることができるようになる。すなわち、どのサービスプログラムについてのメッセージなのか、どのサービスプログラムについての処理なのかを識別することができる。
【００５９】
さらに、ネットワーク・プラットフォーム５０側でサービスプログラム又はサービスプログラムによって規定されている状態を管理していれば、サービスＩＤを見ればいずれの機能モジュールに動作データを振り分けるべきかを判断することができるようになる。さらに、サービスＩＤを用いたサービス認可を行うことも可能となる。さらに、サービスプログラム登録時にネットワーク・プラットフォーム５０側で機能の使用可否を判断し、許可された場合にサービスＩＤを割り当てれば、以降はサービスＩＤで機能の使用許可を判断することが可能になる。すなわち、メッセージ毎に機能の使用許可を判断する必要は無くなり、ネットワーク・プラットフォーム５０側ではサービスＩＤとクライアントＩＤの対応テーブルだけをチェックしてサービス許可を行えるので、処理の簡単化が図れる。
【００６０】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、ＳＭＩを介したサービスプログラムの作成処理について説明したが、別途ネットワーク・プラットフォーム５０において提供される機能モジュールの詳細などを入手することができれば、別途入手した情報に基づきサービスプログラムを作成するようにしても良い。また、サービスプログラムの登録についてもネットワークを介さずに、別途確認及び登録するような手順を採用する場合もある。
【００６１】
また、ネットワーク・プラットフォーム５０は、１台のコンピュータにより実現せずに複数台のコンピュータにより機能分担したり、一部の機能については並列又は分散処理を実施する場合もある。
【００６２】
また、サービス認可についてはメッセージに他のデータ（例えば、サービスプログラムの改ざんがなされていないことを照明するデータ（ハッシュ値又は電子証明書など））を付加して確認する場合もある。
【００６３】
さらに、ネットワーク・プラットフォーム５０における機能モジュール毎に、利用可能なクライアントを規定しておき、クライアントＩＤと動作データに含まれる利用機能モジュールＩＤとを用いて、機能モジュール毎に利用の可否を判断するようにしてもよい。また、図６に示したようなクライアントＩＤと機能モジュールＩＤとの対応テーブルのみを用いて機能モジュールの利用可否を判断しても良い。
【００６４】
なお、ネットワーク・プラットフォーム５０を実現する１又は複数のコンピュータ及びクライアント端末は、コンピュータ装置であって、図１８に示すように、メモリ２５０１（記憶装置）とＣＰＵ２５０３（処理装置）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施の形態における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施の形態では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【００６５】
（付記１）
ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせに関し前記クライアント側で定義され且つ前記ネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムを実行しているクライアント端末から、前記サービスプログラムの識別情報とクライアントの識別情報と特定の機能の要求動作の指定とを含むメッセージを受信するステップと、
クライアントの識別情報とサービスプログラムの識別情報とが対応付けられて格納されているデータ格納部を参照して、受信された前記メッセージに含まれる前記サービスプログラムの識別情報及び前記クライアントの識別情報の対応付けが登録されているか確認する確認ステップと、
前記確認ステップにおいて確認が取れた場合に、前記メッセージにおいて要求された、前記ネットワーク・プラットフォーム側における前記特定の機能による処理を実施し、処理結果及び前記サービスプログラムの識別情報を含む応答を前記クライアント端末に送信するステップと、
を含み、コンピュータにより実行されるサービス処理方法。
【００６６】
（付記２）
前記ネットワーク・プラットフォーム側に未登録のサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信するステップと、
受信した前記サービスプログラムを解析し、前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能か判断する判断ステップと、
前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能と判断された場合には、前記サービスプログラムに対して発行された識別情報を前記クライアントの識別情報と対応付けて前記データ格納部に格納するステップと、
前記サービスプログラムの識別情報を含む登録完了通知を前記クライアント端末に送信するステップと、
をさらに含む付記１記載のサービス処理方法。
【００６７】
（付記３）
前記判断ステップにおいて、
前記クライアントの識別情報に対応して利用可能な機能の識別情報が格納されているクライアントデータ格納部を前記サービスプログラム登録要求に含まれる前記クライアントの識別情報を用いて検索し、前記サービスプログラムに定義されている全機能が抽出されるか判断する
ことを特徴とする付記２記載のサービス処理方法。
【００６８】
（付記４）
前記メッセージが、前記ネットワーク・プラットフォーム側における前記特定の機能において必要とされるパラメータを含むことを特徴とする付記１記載のサービス処理方法。
【００６９】
（付記５）
前記メッセージに含まれる、前記サービスプログラムの識別情報と、保持している、当該サービスプログラムからのサービス要求の処理状態とを用いて、前記ネットワーク・プラットフォーム側における特定の機能を特定するステップ
をさらに含む付記４記載のサービス処理方法。
【００７０】
（付記６）
前記メッセージが、前記ネットワーク・プラットフォーム側における特定の機能の指定及び当該特定の機能において必要とされるパラメータを含むことを特徴とする付記１記載のサービス処理方法。
【００７１】
（付記７）
前記メッセージにおいて指定された、前記ネットワーク・プラットフォーム側における特定の機能について利用可否を判断するステップ
をさらに含む付記６記載のサービス処理方法。
【００７２】
（付記８）
前記ネットワーク・プラットフォーム側で提供される機能が複数あり、当該複数の機能のそれぞれは、ネットワークを介して接続されている複数のコンピュータのいずれかにおいて実現されており、
前記メッセージが、前記ネットワーク・プラットフォーム側において前記特定の機能を実現しているコンピュータのネットワーク・アドレスを含むことを特徴とする付記１記載のサービス処理方法。
【００７３】
（付記９）
前記ネットワーク・プラットフォーム側で提供される機能が複数あり、当該複数の機能のそれぞれは、ネットワークを介して接続されている複数のコンピュータのいずれかにおいて実現されており、
前記メッセージにおいて要求された、前記ネットワーク・プラットフォーム側における前記特定の機能を実現しているコンピュータを特定し、当該特定されたコンピュータに前記特定の機能による処理を依頼するステップ
をさらに含むことを特徴とする付記１記載のサービス処理方法。
【００７４】
（付記１０）
ネットワーク・プラットフォーム側で提供される機能のうちクライアントによって利用される機能の組み合わせが定義されているサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信するステップと、
受信した前記サービスプログラムを解析し、前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能か判断する判断ステップと、
前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能と判断された場合には、前記サービスプログラムに対して発行された識別情報を、前記クライアントの識別情報と対応付けてデータ格納部に格納するステップと、
前記サービスプログラムの識別情報を含む登録完了通知を前記クライアント端末に送信するステップと、
を含み、コンピュータにより実行されるサービス処理方法。
【００７５】
（付記１１）
前記サービスプログラムの識別情報が、前記ネットワーク・プラットフォーム側において発行されるか、または前記クライアントの側において発行されるものであることを特徴とする付記１０記載のサービス処理方法。
【００７６】
（付記１２）
前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能と判断された場合には、前記サービスプログラムの識別情報に対応して利用可能とされた機能の識別情報を第２データ格納部に格納するステップ
をさらに含む付記１０記載のサービス処理方法。
【００７７】
（付記１３）
付記１乃至１２記載のサービス処理方法をコンピュータに実行させるためのプログラム。
【００７８】
（付記１４）
ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせに関し前記クライアント側で定義され且つ前記ネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムを実行しているクライアント端末から、前記サービスプログラムの識別情報とクライアントの識別情報と特定の機能の要求動作の指定とを含むメッセージを受信する手段と、
クライアントの識別情報とサービスプログラムの識別情報とが対応付けられて格納されているデータ格納部を参照して、受信された前記メッセージに含まれる前記サービスプログラムの識別情報及び前記クライアントの識別情報の対応付けが登録されているか確認する確認手段と、
前記確認ステップにおいて確認が取れた場合に、前記メッセージにおいて要求された、前記ネットワーク・プラットフォーム側における前記特定の機能による処理を実施し、処理結果及び前記サービスプログラムの識別情報を含む応答を前記クライアント端末に送信する手段と、
を有するサービス処理装置。
【００７９】
（付記１５）
ネットワーク・プラットフォーム側で提供される機能のうちクライアントによって利用される機能の組み合わせが定義されているサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信する手段と、
受信した前記サービスプログラムを解析し、前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能か判断する判断手段と、
前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能と判断された場合には、前記サービスプログラムに対して発行された識別情報を、前記クライアントの識別情報と対応付けてデータ格納部に格納する手段と、
前記サービスプログラムの識別情報を含む登録完了通知を前記クライアント端末に送信する手段と、
を有するサービス処理装置。
【図面の簡単な説明】
【００８０】
【図１】本発明の一実施の形態におけるシステム概要図である。
【図２】（ａ）はＳＭＩを介してやりとりされるパケットの一例を示す図であり、（ｂ）はＳＣＩを介してやりとりされるパケットの一例を示す図である。
【図３】サービスプログラム登録処理の処理フローを示す図である。
【図４】サービスプログラム作成時にクライアント端末に表示される画面の一例を示す図である。
【図５】サービスプログラム登録処理の処理フローの第２の部分を示す図である。
【図６】クライアントデータ格納部に格納されるデータの一例を示す図である。
【図７】クライアントデータ格納部に格納されるデータの一例を示す図である。
【図８】（ａ）及び（ｂ）は、サービスプログラムの一例を示す図である。
【図９】クライアント端末からネットワーク・プラットフォームに送られるデータの処理概要を示す図である。
【図１０】（１）乃至（６）は各段階におけるデータの一例を示す図である。
【図１１】ネットワーク・プラットフォームからクライアント端末に送られるデータの処理概要を示す図である。
【図１２】図９の他の例を示す図である。
【図１３】サービスプログラムの一例を示す図である。
【図１４】ＳＣＩを介してサービスを利用する際の処理フローを示す図である。
【図１５】（１）乃至（４）はＳＣＩを介してサービスを利用する際に送信されるデータの一例を示す図である。
【図１６】ＳＣＩを介してサービスを利用する際の処理フローを示す図である。
【図１７】ＳＣＩを介してサービスを利用する際の処理フローを示す図である。
【図１８】コンピュータの機能ブロック図である。
【符号の説明】
【００８１】
１ オープンネットワーク ３ ゲートウェイ ５ サービス提供ネットワーク
７，９ クライアント端末 ５０ ネットワーク・プラットフォーム
７１，９１ 管理プログラム
５０１ 認証・認可機能モジュール ５０２ 課金機能モジュール
５０３ クライアント管理機能モジュール ５０４ セッション制御機能モジュール
５０５ コンテキスト管理機能モジュール ５０６ メディア変換機能モジュール
【特許請求の範囲】
【請求項１】
ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせに関し前記クライアント側で定義され且つ前記ネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムを実行しているクライアント端末から、前記サービスプログラムの識別情報とクライアントの識別情報と特定の機能の要求動作の指定とを含むメッセージを受信するステップと、
クライアントの識別情報とサービスプログラムの識別情報とが対応付けられて格納されているデータ格納部を参照して、受信された前記メッセージに含まれる前記サービスプログラムの識別情報及び前記クライアントの識別情報の対応付けが登録されているか確認する確認ステップと、
前記確認ステップにおいて確認が取れた場合に、前記メッセージにおいて要求された、前記ネットワーク・プラットフォーム側における前記特定の機能による処理を実施し、処理結果及び前記サービスプログラムの識別情報を含む応答を前記クライアント端末に送信するステップと、
を含み、コンピュータにより実行されるサービス処理方法。
【請求項２】
前記ネットワーク・プラットフォーム側に未登録のサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信するステップと、
受信した前記サービスプログラムを解析し、前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能か判断する判断ステップと、
前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能と判断された場合には、前記サービスプログラムに対して発行された識別情報を前記クライアントの識別情報と対応付けて前記データ格納部に格納するステップと、
前記サービスプログラムの識別情報を含む登録完了通知を前記クライアント端末に送信するステップと、
をさらに含む請求項１記載のサービス処理方法。
【請求項３】
前記判断ステップにおいて、
前記クライアントの識別情報に対応して利用可能な機能の識別情報が格納されているクライアントデータ格納部を前記サービスプログラム登録要求に含まれる前記クライアントの識別情報を用いて検索し、前記サービスプログラムに定義されている全機能が抽出されるか判断する
ことを特徴とする請求項２記載のサービス処理方法。
【請求項４】
ネットワーク・プラットフォーム側で提供される機能のうちクライアントによって利用される機能の組み合わせが定義されているサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信するステップと、
受信した前記サービスプログラムを解析し、前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能か判断する判断ステップと、
前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能と判断された場合には、前記サービスプログラムに対して発行された識別情報を、前記クライアントの識別情報と対応付けてデータ格納部に格納するステップと、
前記サービスプログラムの識別情報を含む登録完了通知を前記クライアント端末に送信するステップと、
を含み、コンピュータにより実行されるサービス処理方法。
【請求項５】
請求項１乃至４記載のサービス処理方法をコンピュータに実行させるためのプログラム。
【請求項１】
ネットワーク・プラットフォーム側で提供される機能のうちクライアント側に利用許可された機能の組み合わせに関し前記クライアント側で定義され且つ前記ネットワーク・プラットフォーム側に識別情報が登録されているサービスプログラムを実行しているクライアント端末から、前記サービスプログラムの識別情報とクライアントの識別情報と特定の機能の要求動作の指定とを含むメッセージを受信するステップと、
クライアントの識別情報とサービスプログラムの識別情報とが対応付けられて格納されているデータ格納部を参照して、受信された前記メッセージに含まれる前記サービスプログラムの識別情報及び前記クライアントの識別情報の対応付けが登録されているか確認する確認ステップと、
前記確認ステップにおいて確認が取れた場合に、前記メッセージにおいて要求された、前記ネットワーク・プラットフォーム側における前記特定の機能による処理を実施し、処理結果及び前記サービスプログラムの識別情報を含む応答を前記クライアント端末に送信するステップと、
を含み、コンピュータにより実行されるサービス処理方法。
【請求項２】
前記ネットワーク・プラットフォーム側に未登録のサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信するステップと、
受信した前記サービスプログラムを解析し、前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能か判断する判断ステップと、
前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能と判断された場合には、前記サービスプログラムに対して発行された識別情報を前記クライアントの識別情報と対応付けて前記データ格納部に格納するステップと、
前記サービスプログラムの識別情報を含む登録完了通知を前記クライアント端末に送信するステップと、
をさらに含む請求項１記載のサービス処理方法。
【請求項３】
前記判断ステップにおいて、
前記クライアントの識別情報に対応して利用可能な機能の識別情報が格納されているクライアントデータ格納部を前記サービスプログラム登録要求に含まれる前記クライアントの識別情報を用いて検索し、前記サービスプログラムに定義されている全機能が抽出されるか判断する
ことを特徴とする請求項２記載のサービス処理方法。
【請求項４】
ネットワーク・プラットフォーム側で提供される機能のうちクライアントによって利用される機能の組み合わせが定義されているサービスプログラムとクライアントの識別情報とを含むサービスプログラム登録要求をクライアント端末から受信するステップと、
受信した前記サービスプログラムを解析し、前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能か判断する判断ステップと、
前記サービスプログラム内に定義されている全機能を前記クライアントが利用可能と判断された場合には、前記サービスプログラムに対して発行された識別情報を、前記クライアントの識別情報と対応付けてデータ格納部に格納するステップと、
前記サービスプログラムの識別情報を含む登録完了通知を前記クライアント端末に送信するステップと、
を含み、コンピュータにより実行されるサービス処理方法。
【請求項５】
請求項１乃至４記載のサービス処理方法をコンピュータに実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２００６−１６４１３５（Ｐ２００６−１６４１３５Ａ）
【公開日】平成１８年６月２２日（２００６．６．２２）
【国際特許分類】
【出願番号】特願２００４−３５８０４２（Ｐ２００４−３５８０４２）
【出願日】平成１６年１２月１０日（２００４．１２．１０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成１８年６月２２日（２００６．６．２２）
【国際特許分類】
【出願日】平成１６年１２月１０日（２００４．１２．１０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]