JP2007213510A - クライアント装置及びインタフェース提示方法 - Google Patents

Abstract

【課題】コンテンツデータを毎回動的に生成してクライアントに送信することなく、ウエブサービスの持つ柔軟性を有したシステムを実現することができるようにする。
【解決手段】ユーザインタフェースの提示方法を記述するデータに基づいて、前記ユーザインタフェースをユーザに提示する手段と、前記提示方法を記述するデータに含まれるサービス開始を宣言する要素毎に、前記サーバに対して前記サービス開始を要求する手段と、前記サービス開始を要求する原因となったサービス開始を宣言する要素が持つ第１の識別子に対応付けて、前記サーバから受け取ったセッション管理の為の第２の識別子を管理する手段と、前記提示方法を記述するデータに含まれるサーバへのアクセスを宣言する要素に応じて、前記サーバにアクセスする際に、前記第１の識別子に対応する第２の識別子を得て、前記第２の識別子を前記サーバに渡す手段とを有するようにする。
【選択図】図１

Description

本発明はクライアント装置、インタフェース提示方法及びコンピュータプログラムに関し、特に、サーバが提供するサービスのユーザインタフェース（以下ＵＩと略す）を表示するクライアント装置（以下クライアントと略す）、及び、これらのサーバとクライアントから構成されるシステムにおいて、リモートサーバがクライアントからの接続に対してセッション管理を行う際に用いて好適な技術に関する。

リモートサーバ上のデータを閲覧したり、リモートサーバの持つ機能を操作したりする方法として、データ転送プロトコルにＨＴＴＰを、閲覧データや操作のＵＩの記述フォーマットにＨＴＭＬをそれぞれ用いたウエブサービスが広く用いられている。このウエブサービスの最大の利点は、クライアント側はウエブブラウザという単一のソフトウエアだけで、ＨＴＭＬの記述内容を変えることにより様々なアプリケーションを実現できることにある。

リモートサーバの提供するサービスによっては、複数のセッションが同一のクライアントからのものかどうかを判別するためのセッション管理が必要なものがある。例えば、オンラインショッピングサービスにおいて、個々の買い物に対応する複数のセッションが全て同じユーザからのものであることを判別する場合は、セッション管理が必要となる。また、複数クライアントで排他的に共有される機器の操作を提供するサービスにおいて、制御要求が制御権を取ったクライアントからのものかどうかを判別したりする場合などにも、セッション管理が必要となる。

ＨＴＴＰのようにサーバがセッション間の関連を状態として保持しない、いわゆるステートレスなセッションにおいては、最初のセッションの際にその後の一連のセッションに対する識別子をクライアントに渡す。そして、クライアントはその後のセッションで識別子をサーバ側に戻すことにより、それらのセッションが同一クライアントからのものであることをサーバに認識させる。

セッション識別子を渡す方法には、クライアントに渡すコンテンツデータの中身にセッション識別子を埋め込む方法が広く用いられている。図１５は、この従来のクライアント装置の構成の概略を示す図である。２００がクライアント装置であり、２０１はそのユーザである。２０２はサーバであり、２０３はユーザからの入力を受け付ける入力部である。２０４はユーザに表示を行う表示部であり、２０５はクライアント装置全体の制御を行う制御部である。２０６はサーバとの通信を行う通信部であり、２０７はサーバから送られるコンテンツデータであるＵＩ記述データである。また、２０８はそれに埋め込まれるセッションＩＤである。例えば、ＵＩ記述データ２０７はＨＴＭＬで記述されており、その中の次のセッション（リンク先）を示すＵＲＬや、ＦＯＲＭ要素内のＩＮＰＵＴ要素のＨＩＤＤＥＮ属性として、埋め込まれたセッション識別子がセッションＩＤ２０８である。

図１６は、この従来のクライアント装置の構成における処理の概略を示す図である。２１０は入力部２０３の、２１１は表示部２０４の、２１２は制御部２０５の、２１３はサーバ２０２のそれぞれオブジェクトである。

以下、図１６を用いて処理の流れを説明する。
制御部２１２がサーバ２１３にＵＩ記述データ２０７を要求し、サーバ２１３がセッションＩＤ２０８を含んだＵＩ記述データ２０７を返す。制御部２１２がＵＩ記述データ２０７に基づき表示部２１１にＵＩの表示を要求する。ユーザからの入力に従い、入力部２１０が制御部２１２に入力を通知すると、制御部２１２がサーバ２１３にステップＳ１で得たセッションＩＤ２０８と共にサーバ２１３に制御コマンドを送信する。

ここで、サーバ２１３が送信するコンテンツであるＵＩ記述データ２０７は、その表示結果の見た目が同じでも、毎回セッション識別子が異なる。このため、常にクライアントに対してコンテンツを動的に生成してクライアントに送信することが必要となった。

クライアントにセッション識別子方法として、米国Netscape Communications社が考案したCookieによる方法も広く用いられている。この手法を用いると、セッション識別子はCookieとしてコンテンツデータとは別にクライアントに渡すことができるため、セッション識別子をコンテンツデータに埋め込む必要はない。具体的には、サーバからのＨＴＴＰレスポンスのSet-Cookieヘッダに含まれるvalue=name形式のデータがCookieの本体で、クライアントが次回以降に同ヘッダ内のdomain、path属性にマッチするURLに対してＨＴＴＰリクエストを行う際に、このCookie本体のデータをCookieヘッダとして送信する仕組みになっている。

しかしながら、このCookieを使用して、同一クライアントが同一サーバに対して２種類のセッションを要求する場合には、２つを区別するためにサーバ側でpathを２種類用意する必要がある。例えば、ＨＴＭＬ内のFORM要素のACTION属性やIMG要素のSRC属性でサーバに接続する場合、それらの属性値であるURLが同じであるならば、いつも同じCookieをサーバに返すことになる。このため、URLを違える、すなわち、pathを２種類用意する必要があった。

一方、サーバとクライアントとの間でセッション識別子の交換の手順と、それを用いたサービスの手順を規定し、その手順に従ってクライアント上で動作するプログラムがそのサービスのＵＩを提供するという手法も一般的に用いられている。しかしながら、この場合、そのＵＩや対応するサービスはプログラムの仕様によって固定的である。それ故、前述のウエブサービスのようにコンテンツデータを変えるだけでいろいろなＵＩを実現したり、サービスを組み合わせて新たなアプリケーションを作り出したりするためには、新たなプログラムを開発する必要があった。

本発明は前述の問題点に鑑み、セッション管理が必要なサービスにおいて、コンテンツデータを毎回動的に生成してクライアントに送信することなく、かつ、ウエブサービスの持つ柔軟性を有したシステムを実現することができるようにすることを目的としている。

本発明は前記目的を達成するために、ネットワークを介して接続されたサーバが提供するサービスのユーザインタフェースをユーザに提示するクライアント装置であって、第１の識別子を属性として持ち指定したサーバとのサービス開始を宣言する要素と、前記第１の識別子を参照し前記サーバへのアクセスを宣言する要素とを含むユーザインタフェースの提示方法を記述するデータに基づいて、前記ユーザインタフェースをユーザに提示するユーザインタフェース提示手段と、前記ユーザインタフェースの提示方法を記述するデータに含まれるサービス開始を宣言する要素毎に、前記サーバに対して前記サービス開始を要求するサービス開始要求手段と、前記サービス開始要求手段が前記サーバから受け取ったセッション管理の為の第２の識別子を、前記サービス開始を要求する原因となったサービス開始を宣言する要素が持つ第１の識別子に対応付けて管理するセッション識別子管理手段と、前記ユーザインタフェースの提示方法を記述するデータに含まれるサーバへのアクセスを宣言する要素に応じて、前記サーバにアクセスする際に、前記サーバへのアクセスを宣言する要素が参照する第１の識別子に対応する第２の識別子を前記セッション識別子管理手段から得て、前記第２の識別子を前記サーバに渡すサーバアクセス手段とを有することを特徴とするクライアント装置等、を提供する。

本発明によれば、サーバがコンテンツデータを毎回動的に生成してクライアントに送信する必要がなく、クライアント側でコンテンツデータを入れ替えるだけでＵＩを柔軟に変更できる。

（第１の実施形態）
まず、本発明の第１の実施形態について図１〜図６を参照して説明する。
図１は、本実施形態に係るクライアント装置の概略構成を示すブロック図である。
図１において、１はクライアント装置である。２はユーザであり、表示部３に表示される情報に基づき入力装置で入力を行う。

３は表示部であり、液晶ディスプレイ、ディスプレイコントローラ、VRAM等のハードウエアとデバイスドライバやウィンドウシステム等のソフトウエアで構成される。また、４は入力部であり、ポインティングデバイス、Ｉ／Ｏコントローラ等のハードウエアとデバイスドライバ等のソフトウエアで構成される。

５はサーバであり、ネットワーク接続されたクライアント装置１に対して、ストリーム動画像の配信、および、ズーム等の配信画像データ内容の操作というサービスを提供する。６は通信部であり、ネットワークを介してサーバ５と接続されていて、サーバ５とのデータの送受信を行う。

７は制御部であり、クライアント装置１における処理の全体を制御する。８はＵＩ記述保持部であり、ＸＨＴＭＬで記述されたＵＩ記述データ９を保持している。１０はセッションテーブルであり、セッション管理部１１の処理に必要なデータを保持している。

図２は、本実施形態において、セッション管理部１１が行う処理に係る詳細を示す図である。
図２において、ＵＩ記述データ９は、ＸＭＬ要素１２から構成される。ＸＭＬ要素１２は、通常の要素の他にサービス開始要素１３、アクセス要素１４という特別な要素がある。サービス開始要素１３は、サーバ５が提供するサービスがセッション管理するセッション毎に存在する。例えば、動画像の配信要求と動画像データの操作についての複数のセッションが、サーバ５によって一つのものとしてセッション管理される場合には、これらに対して一つのサービス開始要素１３が記述される。

また、アクセス要素１４は動画像の配信要求や画像データの操作に対応する要素である。一連のセッションとしてセッション管理される１つ以上のアクセス要素１４は、それらが同じグループに属する事を示すため、全て同じサービス開始要素１３を要素ＩＤ１５によって参照する。

ここで、要素ＩＤ１５はＵＩ記述データ９内でユニークなＸＭＬのＩＤ属性であり、ＸＭＬのＩＤ属性の値として許されている範囲の任意の文字列をＵＩ記述データ９の都合で使用する事ができる。

一方、１６はセッションＩＤであり、サーバ５がセッション管理の為にCookieやその他のＨＴＴＰのレスポンスによりクライアントに発行するデータである。要素ＩＤ１５とセッションＩＤ１６とは一対一の関係であり、これらの組み合わせをエントリとしたセッションテーブル１０によって管理される。

図３は、ＵＩ記述データ９のＸＨＴＭＬのリストを示す図である。
図３において、１７はサービス開始要素１３であるsessionと言う名のsession要素である。session要素１７は、"ses1"という値のＩＤ属性と、サーバ５へのアクセス方法をURLで指定するhref属性とを持つ。

１８は、アクセス要素１４の一つである動画像ストリームの操作に対応するform要素である。Form要素１８は、action属性としてsession要素１７のＩＤ属性"ses1"を参照する事を示す"ptl:ses1?url=xxx"という値を持つ。１９は、アクセス要素１４の一つである動画像ストリームの表示に対応するobject要素である。object要素１９は、ストリームデータのソースを示すdata属性として１８と同じ"ptl:ses1?url=xxx"と言う値を持つ。ここで"ptl:"はプロトコルスキームとして本実施形態によってセッション管理された特別なプロトコルであることを示している。

この特別なプロトコルは後述するようにセッション管理方法と合わせて"ptl:ses1?"以下の"url=xxx"の値であるxxxで指定されるURLへのアクセスに変換される。Form要素１８とobject要素１９とは同じＩＤ属性"ses1"を参照しているので、操作および動画が同じものとしてセッション管理されることになる。

図４は、図３のＵＩ記述を図１で示すクライアント装置１により処理した結果の画面を示す図である。
図４において、２０は表示部３の液晶ディスプレイ画面全体であり、２１はobject要素１９に対応する動画ストリーム表示であり、２２と２３はform要素１８内の二つのinput要素に対応するボタンである。

図５は、図１の主要なクラスで行われる処理の流れを示す図である。
図５において、３０は入力部４の、３１は表示部３の、３２はＵＩ記述保持部８の、３３は制御部７の、３４はサーバ５の、それぞれオブジェクトである。

以下、図５を用いて処理の流れを説明する。
まず、制御部３３がＵＩ記述保持部３２にＵＩ記述データ９を要求してそれを受け取る。そして、制御部３３は受け取ったＵＩ記述データ９を解析し、サービス開始要素１３が含まれていたら、サーバ３４に対して一連のセッションに対してのサービス開始を要求する。

サーバ３４は、サービス開始要求に対してユニークなセッションＩＤ１６を発行して返す。なお、これらの通信は通信部６を介して行われる（以下も同様）。そして、制御部３３はセッションテーブル１０に、受け取ったセッションＩＤ１６と、サービス開始要素１３の要素ＩＤ１５とを登録する。

次に、制御部３３は、ＵＩ記述データ９にアクセス要素１４の動画ストリーム表示要素があった場合、サーバ３４に動画ストリームの要求をする。その際、受け取ったセッションＩＤ１６を通知する。そして、制御部３３はＵＩ記述データ９に従ったＵＩを表示部３１に表示させる。そして、サーバ３４はストリームデータを送信する。１フレーム受け取った制御部３３は、表示部３１に表示の更新を行わせる。

ユーザが入力部３０のポインティングデバイスを用いて、２２あるいは２３のボタンをクリックすると、制御部３３にクリックが通知される。すると、制御部３３は、ボタンに対応するコマンドをサーバ３４に送信する。この場合も受け取ったセッションＩＤ１６を通知する。ユーザから入力部４を介して終了指示が合った場合、制御部３３はサーバ３４に対して、開始したサービスをセッションＩＤ１６で指定することにより、サービスの終了を要求する。

図６は、図５における動画像ストリーム要求や動画像ストリーム操作で制御部７がサーバ５にアクセスする処理の詳細を示す図である。
図６において、３５は制御部７の、３６はセッション管理部１１の、３７はセッションテーブル１１の、３８は通信部６の、それぞれオブジェクトである。

以下、図６を用いて処理の流れを説明する。
制御部３５は、セッション管理部３６に対して、サービス開始要素１３を指定してサーバ５でのサービス開始を要求する。セッション管理部３６がサービス開始要素１３のhref属性の値であるURLに対するアクセスを通信部３８に要求する。次に、通信部３８は、URLで指定されたサーバ５に対してアクセスし、セッションＩＤ１６を含むCookie等のデータを返す。

次に、セッション管理部３６は、受け取ったデータからセッションＩＤ１６を取り出し、セッションテーブル３７に対してサービス開始要素１３の要素ＩＤとセッションＩＤ１６とCookie等のセッション管理の方法とを組にして登録する。そして、制御部３５は、セッション管理部３６に対してアクセス要素１４を指定してサーバ５へのアクセスを要求する。

次に、セッション管理部３６は、指定されたアクセス要素１４の属性である"ptl:ID?url=xxx"から、参照する要素ＩＤ１５を取り出し、セッションテーブル３７を検索して要素ＩＤ１５に対応するセッションＩＤ１６とセッション管理の方法とを得る。

セッション管理部３６がアクセス要素の属性文字列の"url=xxx"からURLを取り出し、これとセッションＩＤ１６およびセッション管理の方法からサーバ５へのアクセス方法を決定する。決定されたアクセス方法に基づき通信部３８にサーバアクセスを要求する。サーバ５からのリプライは制御部３５によって処理される。

以上説明したように、本実施形態によれば、クライアントは図３で示すＵＩ記述データを処理することにより、サーバが採用するセッション管理に基づき図４で示すＵＩをユーザに表示することができ、ユーザがＵＩを操作することによりサーバの操作を行うことができる。

（第２の実施形態）
次に、本発明の第２の実施形態を、図７〜図１１を用いて説明する。本実施形態ではクライアント装置の構成は第１の実施形態と同じであるが、ＵＩ記述データ９が図３で示すものとは異なる。第１の実施形態と同様な部分については説明を省略する。

図７は、本実施形態のＵＩ記述データ９の例を示す図である。
図７において、４０と４１は別のサーバに対してのsession要素である。また、４２と４３はsession要素４０の指定するサーバに対してのストリーム動画像操作とストリーム動画像表示のためのアクセス要素である。また、４４と４５はsession要素４１の指定するサーバに対してのストリーム動画像操作とストリーム動画像表示のためのアクセス要素である。

すなわち、図７は図４と異なり、複数のサーバに対してのサービスが混在しているが、各々"sec1"と"sec2"と言う要素ＩＤ１５によって二つにグルーピングされている。さらに、４６は後述のＵＩ記述データ切り替えの為のＵＩコントロールに対応する部分である。

図８は、図７のＵＩ記述データ９を図１で示すクライアント装置１により処理した結果の画面を示す図である。
図８において、５０は表示部３の液晶ディスプレイ画面全体であり、５１はそれぞれsession要素４０で指定したサーバに対するストリーム表示である。５２及び５３は、二つのボタンである。また、５４は、アクセス要素４４で指定したサーバに対するストリーム表示である。そして、５５及び５６は、二つのボタンである。また、５７はＵＩコントロールに対応する部分４６に対応するＵＩ記述データ９の切り替えの為のボタンである。

図９は、図８のボタン５７をユーザがクリックしてＵＩ記述データ９が切り替わった後の画面を示す図である。図９の６０〜６７はそれぞれ図８の５０〜５７に対応するが、二つのサーバに対応する画面が縦に並んでいるところが図８とは異なる。

図１０は、本実施形態における複数のサーバへのアクセスの処理を示す図である。
図１０において、７０は入力部３の、７１は表示部３の、７２はＵＩ記述保持部８の、７３は制御部７の、それぞれオブジェクトであり、７４と７５は二つのサーバのオブジェクトである。

以下、図１０を用いて処理の流れを説明する。
まず、制御部７３がＵＩ記述保持部７２にＵＩ記述データ９を要求してそれを受け取る。そして、制御部７３は受け取ったＵＩ記述データ９を解析し、サービス開始要素１３が含まれていたら、サーバ７４に対して一連のセッションに対してのサービス開始を要求する。

次に、サーバ７４はサービス開始要求に対してユニークなセッションＩＤ１６を発行して返す。なお、これらの通信は通信部６を介して行われる（以下も同様）。制御部７３はセッションテーブル１０に、受け取ったセッションＩＤ１６と、サービス開始要素１３の要素ＩＤ１５とを登録する。また、ＵＩ記述データ９内に別のサーバ７５へのサービス開始要素１３が含まれていた場合、そのサーバ７５に対しても同様の処理を行う。そして、制御部７３はサーバ７５から受け取ったセッションＩＤ１６についても同様の処理を行う。

制御部７３はＵＩ記述データ９にアクセス要素１４の動画ストリーム表示要素があった場合、サーバ７４に動画ストリームの要求をする。その際、受け取ったセッションＩＤ１６を通知する。そして、制御部７３はサーバ７５に対しても同様の処理を行う。

次に、制御部７３はＵＩ記述データ９に従ったＵＩを表示部７１に表示させる。サーバ７４はストリームデータを送信する。そして、１フレーム受け取った制御部７３は、表示部７１に表示の更新を行わせる。また、サーバ７５からストリームデータが送信された場合も、制御部７３は同様の処理を行う。

ユーザが入力部７０のポインティングデバイスを用いて、５２あるいは５３のボタンをクリックすると、制御部７３にクリックが通知される。制御部７３は、ボタンに対応するコマンドをサーバ７４に送信する。この場合も受け取ったセッションＩＤ１６を通知する。また、ユーザが５５あるいは５６のボタンをクリックした場合は、サーバ７５に対して同様の処理を行われる。そして、サーバ７５からも同様の処理が行われる。

ユーザから入力部７０を介して終了指示が合った場合、制御部７３はサーバ７４に対して、開始したサービスをセッションＩＤ１６で指定することにより、サービスの終了を要求する。また、サーバ７５に対しても同様の処理が行われる。

図１１は、図８と図９のＵＩ切り替えに係る処理の流れを示す図である。図１１において、７０〜７５は図１０と同じである。以下、図１１を用いて処理の流れを説明する。
まず、制御部７３がＵＩ記述保持部７２にＵＩ記述データ９を要求してそれを受け取る。
そして、制御部７３はサーバ７４に対して一連のセッションに対してのサービス開始を要求する。さらに、制御部７３はサーバ７５に対してもサービス開始を要求する。

次に、制御部７３はＵＩ記述データ９に従ったＵＩを表示部７１に表示させる。そして、ユーザが入力部７０のポインティングデバイスを用いて、ボタン５７をクリックすると、制御部７３にクリックが通知される。なお、ボタン５７は図７のボタン４６に対応しており、ＵＩ記述保持部７２が保持する別のＵＩ記述データ９に切り替える処理を呼び出す。

そして、制御部７３はサーバ７４に対してサービスの終了を要求する。さらに、制御部７３はサーバ７５に対してサービスの終了を要求する。制御部７３はＵＩ記述保持部７２に新しいＵＩ記述データ９を要求してそれを受け取る。以下繰り返す。

以上説明したように、本実施形態によれば、クライアントは同時に二つ以上のサーバに対して各々別のセッション管理手法で接続し、それらのサーバが提供するサービスを一つに合成したＵＩを自らが保持するＵＩ記述によってユーザに表示することができる。なお、図７における二つのsession要素４０、４１は別のサーバを指定しているが、これらは二つとも同じサーバを指定しても良い。サーバ側が同じクライアントからの複数同時アクセスを許し、それらについて別のセッション管理を行う場合には、同じサーバに対して上述の説明と同様の効果が得られる。

（第３の実施形態）
続いて、本発明の第３の実施形態を、図１２〜図１４を用いて説明する。第１の実施形態と同様な部分については説明を省略する。
図１２は、本実施形態に係るクライアント装置の概略構成を示すブロック図である。
図１２において、８０はクライアント装置である。８１はユーザであり、表示部８２に表示される情報に基づき入力部８３で入力を行う。

表示部８２は液晶ディスプレイ、ディスプレイコントローラ、VRAM等のハードウエアとデバイスドライバやウィンドウシステム等のソフトウエアで構成される。また、入力部８３はポインティングデバイス、Ｉ／Ｏコントローラ等のハードウエアとデバイスドライバ等のソフトウエアで構成される。

８４はサーバであり、ネットワーク接続されたクライアント装置８０に対して、ストリーム動画像の配信、および、ズーム等の配信画像データ内容の操作というサービスを提供する。８６は通信部であり、ネットワークを介してサーバ８４と接続されていて、サーバ８４とのデータの送受信を行う。８７は制御部であり、クライアント装置８０における処理の全体を制御する。

８５は、様々なＵＩ記述データ８８をクライアント装置８０に提供するＵＩ記述サーバであり、クライアント装置８０は通信部８６を介してＸＨＴＭＬで記述されたＵＩ記述データ８８を受信する。９０はセッションテーブルであり、セッション管理部８９の処理に必要なデータを保持している。

図１３は、本実施形態における処理の概略を示す図である。１００はＵＩ記述サーバ８５の、１０１はもう一つのＵＩ記述サーバ８５の、１０２は制御部８７の、１０３はサーバ８４のそれぞれオブジェクトである。

以下、図１３を用いて処理の流れを説明する。
まず、制御部１０２が通信部８６を介してＵＩ記述サーバ１０１にＵＩ記述データ８８を要求し、ＵＩ記述サーバ１０１はそれを返す。そして、制御部１０２は、得られたＵＩ記述データ８８に従い、サーバ１０３に対してサービス開始要求を行い、サーバ１０３がセッションＩＤ１６を返す。

次に、制御部１０２は、サーバ１０３に対してストリーム要求を行う。そして、サーバ１０３は、ストリームデータを送信する。次に、制御部１０３がユーザに指示に従って制御コマンドをサーバ１０３に送る。ユーザがＵＩ記述データ８８の変更を指定すると（ＵＩ記述サーバのURLを指定）、サーバ１０３に対してセッション終了要求を行う。また、制御部１０３は、指定されたＵＩ記述サーバに対して最初と同様の処理を行う。図１３において、ＵＩ記述サーバは二つあることになっているが、これは二つである必要はなく、一つでも、三つ以上でも基本的な処理が同じであることは言うまでもない。

図１４は、ＵＩ記述サーバ８５とサーバ８４とに対してクライアント装置が複数ある場合の処理の概略を示す図である。図１４において、１０４はＵＩ記述サーバ８５の、１０５は第１のクライアント装置の制御部８７の、１０６は第２のクライアント装置の制御部８７の、１０７はサーバ８４のそれぞれオブジェクトである。

以下、図１４を用いて処理の流れを説明する。
第２のクライアント装置の制御部１０６がＵＩ記述サーバ１０４にＵＩ記述データ８８の要求を行い、ＵＩ記述サーバ１０４はそれを返す。そして、第２のクライアント装置の制御部１０６は、受け取ったＵＩ記述データ８８に従い、サーバ１０７にサービスの開始要求を行い、サーバ１０７はセッションＩＤ１６を返す。

次に、第１のクライアント装置の制御部１０６がＵＩ記述サーバ１０４にＵＩ記述データ８８の要求を行い、ＵＩ記述サーバ１０４はそれを返す。そして、第１のクライアント装置の制御部１０６が受け取ったＵＩ記述データ８８に従い、サーバ１０７にサービスの開始要求を行い、サーバ１０７はセッションＩＤ１６を返す。

以上説明したように、本実施形態によれば、必要に応じてＵＩ記述データ８８をＵＩ記述サーバ８５から受信するため、クライアント装置８０は複数のＵＩ記述データ８８を一度に保持する必要はない。また、ＵＩ記述サーバ８５によってＵＩが一元管理されるため、複数のクライアント装置で同じＵＩを実現することができる。

（本発明に係る他の実施形態）
上述した実施形態においては、ＵＩ記述データとしてＸＨＴＭＬを使用していたが、これはＸＨＴＭＬに限定されるわけでなく、例えばSVG等のその他の記述形式を用いても本発明を適用できることは言うまでもない。また、上述した実施形態においては、ＵＩとしてＧＵＩを取り上げたが、ＵＩ記述データとしてVoiceXML等を用いれば、マルチモーダルなＵＩに本発明を適用できることは言うまでもない。

前述した本発明の実施形態におけるクライアント装置を構成する各手段、並びにインタフェース提示方法の各工程は、コンピュータのＲＡＭやＲＯＭなどに記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記録媒体は本発明に含まれる。

また、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システムまたは装置に直接、または遠隔から供給する。そして、そのシステムまたは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスクなどがある。さらに、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ）などもある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する方法がある。そして、前記ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、その他の方法として、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記録媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。さらに、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、その他の方法として、まず記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。そして、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。

本発明の第１の実施形態に係るクライアント装置の概略構成を示すブロック図である。 本発明の第１の実施形態におけるセッション管理部が行う処理に係る詳細を示す図である。 本発明の第１の実施形態に係るＵＩ記述データの一例のＸＨＴＭＬのリストを示す図である。 本発明の第１の実施形態において、図３のＵＩ記述をクライアント装置により処理した結果の画面を示す図である。 本発明の第１の実施形態の主要なクラスで行われる処理の流れを示す図である。 本発明の第１の実施形態において、動画像ストリーム要求や動画像ストリーム操作で制御部がサーバにアクセスする処理の詳細を示す図である。 本発明の第２の実施形態に係るＵＩ記述データの一例のＸＨＴＭＬのリストを示す図である。 本発明の第２の実施形態において、図７のＵＩ記述をクライアント装置により処理した結果の画面を示す図である。 本発明の第２の実施形態において、ボタンをユーザがクリックしてＵＩ記述データが切り替わった後の画面を示す図である。 本発明の第２の実施形態において、複数のサーバへのアクセスの処理を示す図である。 本発明の第２の実施形態において、図８と図９のＵＩ切り替えに係る処理の流れを示す図である。 本発明の第３の実施形態に係るクライアント装置の概略構成を示すブロック図である。 本発明の第３の実施形態における処理の概略を示す図である。 本発明の第３の実施形態において、クライアント装置が複数場合ある場合の処理の概略を示す図である。 従来のクライアント装置の概略構成を示すブロック図である。 従来のクライアント装置の処理の概略を示す図である。

符号の説明

１ クライアント装置
２ ユーザ
３ 表示部
４ 入力部
５ サーバ
６ 通信部
７ 制御部
８ ＵＩ記述保持部
９ ＵＩ記述データ
１０ セッションテーブル
１１ セッション管理部
１２ ＸＭＬ要素
１３ サービス開始要素
１４ アクセス要素
１５ 要素ＩＤ
１６ セッションＩＤ
１７ session要素
１８ form要素
１９ object要素
２０ 液晶ディスプレイ画面全体
２１ 動画ストリーム表示
２２ ボタン
２３ ボタン

Claims (10)

1. ネットワークを介して接続されたサーバが提供するサービスのユーザインタフェースをユーザに提示するクライアント装置であって、
   第１の識別子を属性として持ち指定したサーバとのサービス開始を宣言する要素と、前記第１の識別子を参照し前記サーバへのアクセスを宣言する要素とを含むユーザインタフェースの提示方法を記述するデータに基づいて、前記ユーザインタフェースをユーザに提示するユーザインタフェース提示手段と、
   前記ユーザインタフェースの提示方法を記述するデータに含まれるサービス開始を宣言する要素毎に、前記サーバに対して前記サービス開始を要求するサービス開始要求手段と、
   前記サービス開始要求手段が前記サーバから受け取ったセッション管理の為の第２の識別子を、前記サービス開始を要求する原因となったサービス開始を宣言する要素が持つ第１の識別子に対応付けて管理するセッション識別子管理手段と、
   前記ユーザインタフェースの提示方法を記述するデータに含まれるサーバへのアクセスを宣言する要素に応じて、前記サーバにアクセスする際に、前記サーバへのアクセスを宣言する要素が参照する第１の識別子に対応する第２の識別子を前記セッション識別子管理手段から得て、前記第２の識別子を前記サーバに渡すサーバアクセス手段とを有することを特徴とするクライアント装置。
2. 前記ユーザインタフェースの提示方法を記述するデータを保持する保持手段を有することを特徴とする請求項１に記載のクライアント装置。
3. 前記ユーザインタフェースの提示方法を記述するデータを他のサーバから受け取るデータ受取手段を有することを特徴とする請求項１に記載のクライアント装置。
4. 前記サーバへのアクセスを宣言する要素は、前記サーバに対するリモートコマンドを発行する要素と、加えて前記リモートコマンドのパラメータをユーザに入力させるパラメータ入力要素とから構成され、
   前記ユーザインタフェース提示手段は、前記リモートコマンドを発行する要素と、前記パラメータをユーザに入力させる要素とに対応するコントロールをユーザに提示することを特徴とする請求項１に記載のクライアント装置。
5. 前記サーバへのアクセスを宣言する要素は、前記サーバからのストリームデータへのアクセスの宣言であり、
   前記ユーザインタフェース提示手段は、前記サーバへのアクセスを宣言する要素に応じて、前記ストリームデータの再生を行うことを特徴とする請求項１に記載のクライアント装置。
6. 前記ユーザインタフェース提示手段が提示するユーザインタフェースは、グラフィカルユーザインタフェースであることを特徴とする請求項１に記載のクライアント装置。
7. 前記ユーザインタフェース提示手段が提示するユーザインタフェースは、音声を用いたユーザインタフェースであることを特徴とする請求項１に記載のクライアント装置。
8. 前記ユーザインタフェースの提示方法を記述するデータは、ＸＭＬをベースとしたマークアップ言語で記述されることを特徴とする請求項１に記載のクライアント装置。
9. ネットワークを介して接続されたサーバが提供するサービスのユーザインタフェースをユーザに提示するサーバ・クライアントシステムにおけるインタフェース提示方法であって、
   第１の識別子を属性として持ち指定したサーバとのサービス開始を宣言する要素と、前記第１の識別子を参照し前記サーバへのアクセスを宣言する要素とを含むユーザインタフェースの提示方法を記述するデータに基づいて、前記ユーザインタフェースをユーザに提示するユーザインタフェース提示工程と、
   前記ユーザインタフェースの提示方法を記述するデータに含まれるサービス開始を宣言する要素毎に、前記サーバに対して前記サービス開始を要求するサービス開始要求工程と、
   前記サービス開始要求工程において前記サーバから受け取ったセッション管理の為の第２の識別子を、前記サービス開始を要求する原因となったサービス開始を宣言する要素が持つ第１の識別子に対応付けて管理するセッション識別子管理工程と、
   前記ユーザインタフェースの提示方法を記述するデータに含まれるサーバへのアクセスを宣言する要素に応じて、前記サーバにアクセスする際に、前記サーバへのアクセスを宣言する要素が参照する第１の識別子に対応する第２の識別子を得て、前記第２の識別子を前記サーバに渡すサーバアクセス工程とを有することを特徴とするインタフェース提示方法。
10. 前記請求項９に記載の方法の各工程をコンピュータにて実施させることを特徴とするコンピュータプログラム。

Images