(57)【特許請求の範囲】
【請求項１】
ネットワークを介して端末装置にウェブコンテンツを配信するサーバにおいて、
ウェブコンテンツの各ノードに、当該ウェブコンテンツの変換に対する注釈情報を付加するノード編集部と、
前記ウェブコンテンツを、前記ノード編集部により前記ノードに付加された注釈情報に基づいて、当該ウェブコンテンツを閲覧する前記端末装置における表示単位であるカードに分割するカード生成部と
を備えることを特徴とするサーバ。
【請求項２】
前記ノード編集部は、少なくとも、自ノードが親ノードから分離可能か否かを示す情報と、自ノードに記述された情報の提示方法を特定する情報とを、前記注釈情報として各ノードに付加することを特徴とする請求項１に記載のサーバ。
【請求項３】
前記カード生成部は、前記ウェブコンテンツを、ランダムにアクセスが可能な階層メニューをなすカードとシーケンシャルにアクセスされる一連のカード群とで構成されたツリー構造を持ったカード集合に変換することを特徴とする請求項１に記載のサーバ。
【請求項４】
ネットワークを介して端末装置に対し当該端末装置における表示単位であるカードに分割されたウェブコンテンツを配信するサーバにおいて、
前記端末装置から受信バッファの記憶容量に関する情報を取得する端末情報取得部と、
前記端末情報取得部にて取得された情報に基づいて前記受信バッファの記憶容量以内のデータサイズとなるように、前記端末装置から送信を要求されたカード及び当該カードからリンクされるカードを所定の規則に基づいて集めて前記端末装置への送信単位であるデックを生成するデック生成部と
を備えることを特徴とするサーバ。
【請求項５】
前記デック生成部は、前記端末装置から送信を要求されたカードがシーケンシャルにアクセスされるカードである場合、当該カードを含んでシーケンシャルにアクセスされる一連のカード群を集めて前記デックを生成することを特徴とする請求項４に記載のサーバ。
【請求項６】
前記デック生成部は、前記端末装置から送信を要求されたカードがランダムにアクセスされるカードである場合、当該カードを含むカード集合がなすツリー構造において当該カードからルートカードへ向かいながらパス上のカードを順次集めて前記デックを生成することを特徴とする請求項４に記載のサーバ。
【請求項７】
前記デック生成部は、前記端末装置から送信を要求されたカードがランダムにアクセスされるカードであり、かつ当該カードからルートカードへ向かうパス上の全てのカードを集めても前記受信バッファの記憶容量に達しない場合、さらに送信を要求された当該カードの子孫のカードを広さ優先で集めて前記デックに加えることを特徴とする請求項６に記載のサーバ。
【請求項８】
ツリー構造のウェブコンテンツを入力し、当該ウェブコンテンツの構造に基づき、当該ウェブコンテンツの各ノードに対し、自ノードが親ノードから分離可能か否かを示す情報と自ノードに記述された情報の提示方法を特定する情報とを対応づけるノード編集手段と、
前記ノード編集手段により前記情報を各ノードに付加された前記ウェブコンテンツを格納する記憶手段と
を備えることを特徴とするウェブコンテンツ編集装置。
【請求項９】
コンピュータを制御してウェブコンテンツを編集するプログラムにおいて、
ツリー構造を有するウェブコンテンツを入力し、当該ウェブコンテンツの各ノードに、当該ウェブコンテンツの分割方法に関する注釈情報を付加し、注釈情報が付加された当該ウェブコンテンツを記憶手段に格納する処理と、
前記記憶手段から前記ウェブコンテンツを読み出し、当該ウェブコンテンツのノードに付加された前記注釈情報に基づいて、当該ウェブコンテンツを分割する処理と
を前記コンピュータに実行させることを特徴とするプログラム。
【請求項１０】
コンピュータを制御して所定の端末装置にウェブコンテンツを提供するプログラムにおいて、
前記端末装置から受信バッファの記憶容量に関する情報を取得し、第１の記憶手段に格納する処理と、
前記第１の記憶手段から前記受信バッファの記憶容量に関する情報を読み出し、当該受信バッファの記憶容量以内のデータサイズとなるように、前記端末装置における表示単位であるカードに分割されたウェブコンテンツが格納された第２の記憶手段から、前記端末装置に送信を要求されたカード及び当該カードからリンクされるカードを所定の規則に基づいて読み出して、前記端末装置への送信単位であるデックを生成する処理と、
生成された前記デックを前記端末装置に送信する処理と
を前記コンピュータに実行させることを特徴とするプログラム。
【請求項１１】
コンピュータを制御してウェブコンテンツを編集するプログラムにおいて、
処理対象であるウェブコンテンツのツリー構造をディスプレイに表示する手段と、
表示された前記ウェブコンテンツにおける所定のノードの指定を受け付ける手段と、
指定された前記ノードに対し当該ウェブコンテンツの変換に対する注釈情報の入力を受け付けて当該ノードに付加する手段と、
ノードに注釈情報が付加された前記ウェブコンテンツを記憶装置に格納する手段として
前記コンピュータを機能させることを特徴とするプログラム。
【請求項１２】
コンピュータを用いてウェブコンテンツを編集するウェブコンテンツ編集方法において、
前記コンピュータの処理装置が、ウェブコンテンツを入力し、当該ウェブコンテンツの各ノードに、当該ノードの分割方法に関する注釈情報を付加し、注釈情報が付加された当該ウェブコンテンツを記憶手段に格納するステップと、
前記処理装置が、前記記憶手段から前記ウェブコンテンツを読み出し、当該ウェブコンテンツのノードに付加された前記注釈情報に基づいて、当該ウェブコンテンツを分割するステップと
を含むことを特徴とするウェブコンテンツ編集方法。
【請求項１３】
端末装置からの要求に応じてウェブコンテンツを提供するサーバにおけるウェブコンテンツ提供方法において、
前記サーバの受信手段が、前記端末装置から受信バッファの記憶容量に関する情報を受信するステップと、
前記サーバの処理装置が、前記端末装置における表示単位であるカードに切り分けられたウェブコンテンツを格納した記憶手段から、前記端末装置からの要求に対応するカード及び当該カードからリンクされるカードを含むカードを、前記受信バッファの記憶容量以内のデータサイズ分読み出してデックを生成するステップと、
前記サーバの送信手段が、生成された前記デックを前記端末装置に送信するステップと
を含むことを特徴とするウェブコンテンツ提供方法。
【請求項１４】
前記処理装置が、ウェブコンテンツを格納した記憶手段から、送信対象であるウェブコンテンツを読み出し、当該ウェブコンテンツを前記カードに分割して前記記憶手段に格納するステップをさらに含むことを特徴とする請求項１３に記載のウェブコンテンツ提供方法。
【請求項１５】
ネットワークに接続された端末装置と、当該ネットワークを介して当該端末装置にウェブコンテンツを提供するコンテンツサーバとを備えたネットワークシステムにおいて、
前記コンテンツサーバは、
ツリー構造を持つウェブコンテンツを生成するアプリケーションプログラムを実行するアプリケーション実行部と、
前記アプリケーション実行部にて生成されたウェブコンテンツを、当該ウェブコンテンツを閲覧する前記端末装置における表示単位であるカードに分割するカード生成部と、
前記端末装置から受信バッファの記憶容量に関する情報を取得する端末情報取得部と、
前記端末情報取得部にて取得された情報に基づいて前記受信バッファの記憶容量以内のデータサイズとなるように、前記端末装置から送信を要求されたカード及び当該カードからリンクされるカードを所定の規則に基づいて集めて前記端末装置への送信単位であるデックを生成するデック生成部と
を備えることを特徴とするネットワークシステム。
【請求項１６】
ネットワークに接続された端末装置に対し、当該ネットワークを介してウェブコンテンツを提供するウェブコンテンツ提供システムにおいて、
ＨＴＭＬ（Hypertext Markup Language）にて記述されたウェブコンテンツを格納した記憶手段と、
前記ウェブコンテンツの分割方法に関する注釈情報を、当該ウェブコンテンツのツリー構造における各ノードに対応づけて格納した外部注釈データベースと、前記端末装置からウェブコンテンツの送信要求を受け取り、当該要求されたウェブコンテンツを前記記憶手段から読み出し、当該ウェブコンテンツに関する注釈情報を前記外部注釈データベースから読み出し、読み出した当該注釈情報に基づいて当該ウェブコンテンツを分割し、分割された当該ウェブコンテンツを前記端末装置に送信するコンテンツ変換手段と
を備えることを特徴とするウェブコンテンツ提供システム。
【請求項１７】
統一表現で記述されたアプリケーションプログラムを、当該アプリケーションプログラムを利用する端末装置に対応した形式に変換する変換システムにおいて、
ツリー構造の統一表現で記述された前記アプリケーションプログラムを格納した第１の記憶手段と、
前記第１の記憶手段から前記端末装置に提供するアプリケーションプログラムを読み出し、ツリー構造の前記アプリケーションプログラムの各ノードに対して当該アプリケーションプログラムの分割に関する注釈情報を付加し、当該注釈情報に基づいて当該アプリケーションプログラムを画面分割する最適化手段と、
前記最適化手段にて最適化されたアプリケーションプログラムを格納する第２の記憶手段と、
前記第２の記憶手段から前記最適化されたアプリケーションプログラムを読み出し、当該アプリケーションプログラムの提供先である前記端末装置に対応した形式に変換する変換手段と
を備えることを特徴とする変換システム。
【請求項１８】
ネットワークを介してサーバに接続し、ウェブコンテンツを取得する端末装置において、
接続したサーバに対し、自装置の受信バッファの記憶容量に関する情報を送信する送信手段と、
前記送信手段にて前記サーバに送られた前記情報に基づいて生成された前記ウェブコンテンツを構成するデータセットを受信する受信手段と
を備えることを特徴とする端末装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークを介して端末装置にウェブコンテンツを配信するサーバに関し、特にＨＴＭＬ等で記述されたウェブコンテンツをＷＭＬ等の携帯端末に適した形式に変換して配信するサーバに関する。
【０００２】
【従来の技術】
今日、携帯電話やＰＤＡ（Personal Digital Assistant）などの携帯型情報端末（以下、携帯端末と称す）においても、インターネットに接続してウェブコンテンツ（以下、単にコンテンツと称す）を閲覧する機能を持ったものが普及してきている。
このような携帯端末は、一般的なネットワーク端末であるコンピュータ装置（デスクトップ型やノートブック型のパーソナルコンピュータ、ワークステーションなど）と比較して、コンテンツを表示する表示画面が小さく、受信バッファ（メモリ）の記憶容量も少ない。したがって、携帯端末に対してコンテンツを送信するウェブサーバは、送信先の端末の能力に合わせてコンテンツを変換する必要がある。
【０００３】
この種の携帯端末、特に無線端末に適したコンテンツ記述言語として、ＷＭＬ（Wireless Markup Language）やＨＤＭＬ（Handheld Device Markup Language）がある。これらの言語で記述されたコンテンツは、携帯端末における表示単位であるカード（Ｃａｒｄ）と複数のカードをまとめたデック（Ｄｅｃｋ）とで構成される。コンテンツは、このデックを単位として送受信される。
通常、コンテンツは、ＨＴＭＬなどを用いて記述され、ツリー状の構造を持っている。したがって、このコンテンツをＷＭＬやＨＤＭＬのデータファイルに変換して携帯端末に送信するためには、このツリー構造をカードとデックからなる構造に切り分けなければならない。
【０００４】
カードは、携帯端末の表示画面に実際に表示される物理的な表示単位であるため、表示内容が見やすいことや、ナビゲーションが携帯端末のユーザにとって直感的で操作しやすいことが重要である。
また、デックは、携帯端末に対して一度に送受信するデータの単位であるため、１つのデックに多くのカードをまとめることができれば、通信の回数を減少させることとなるため通信効率を向上させることができる。一方で、１デックのサイズは、送信先の携帯端末における受信バッファの記憶容量以下でなければならない。
【０００５】
ここで、携帯端末における表示画面のサイズや受信バッファの記憶容量は、装置の種類によって異なる場合が多いので、コンテンツのツリー構造をカードとデックからなる構造に変換する処理は、携帯端末からの送信要求時に動的に行われることが望ましい。
【０００６】
この種の変換処理における従来の一般的な手法として、まずコンテンツをべた書きのテキストに変換し、適当な文字数ごとにカードに切っていく方法がある。この手法は、例えばＫＤＤＩのＥＺ−ウェブサービス（ＨＤＭＬを使用）において、電子メールを表示する場合やＨＴＭＬで記述されたコンテンツをＨＤＭＬファイルに変換する場合などに使われている。
この手法では、元のコンテンツをその意味内容に関わらず機械的に切るため、不自然な切り方になる場合が多い。例えば、文章や単語の途中で切れたり、画面上の表示が行の途中で切れたりする場合がある。
また、サーバから携帯端末への送信は、作成されたカードの最初から連続的に行われることが多いので、コンテンツの一部だけを見ようとする場合であっても、最初から順に見ていかなければならず使用の便が悪い。
【０００７】
ツリー構造のコンテンツからカード及びデックを生成する従来技術としては、例えば、特開２０００−１９４６１２号公報に開示された技術がある。同公報には、特定のタグ（TABLE, IMG, FIELDSET, IFRAMEなど）に基づいてツリー構造のコンテンツを分割し、このツリー構造の論理的な順序を保存する技術が記載されている。また、テキストやイメージ、リンクなどのカテゴリに基づいてコンテンツ内部の情報を分類し、メニューとリンクを用いて表示を行う技術が記載されている。さらに、携帯端末における受信バッファの記憶容量を参酌してデックを生成することについても述べられている。
同種の他の従来技術として、例えば、Ｐｒｏ５社のソフトウェアであるｃ−Ｍａｇｉｃは、元のＨＴＭＬテキストをカードに分割する際に、特定のタグ（<br>, <p>, <table>, <form>など）で切るように工夫しているため、不自然な切れ方になる場合を減少させている。
【０００８】
また、ツリー構造のコンテンツからカード及びデックを生成する他の従来技術として、特開２０００−７６４７３号公報に開示された技術がある。同公報には、コンテンツの構造や特定のタグ情報を利用してインデックス情報を抽出しアウトラインページを作成するなどの処理により、元のコンテンツの構造情報を変換後のデータファイルに反映させる技術が記載されている。
【０００９】
【発明が解決しようとする課題】
上述したように、コンテンツを携帯電話やＰＤＡなどの携帯端末で閲覧する場合、表示画面のサイズや受信バッファの記憶容量における制約に対応するため、ウェブサーバなどにおいて、ツリー構造のコンテンツを携帯端末に適したカード及びデックからなる構造を持つデータファイルに変換する場合があった。
そしてこの場合、携帯端末における表示単位であるカードでは、表示内容が見やすいことや、ナビゲーションが携帯端末のユーザにとって直感的で操作しやすいことが要求される。また、サーバ、携帯端末間の通信単位であるデックでは、データサイズを携帯端末の受信バッファの記憶容量を超えない範囲でできるだけ多くのカードをまとめる（多くのデータを含む）ことが要求される。
さらに、コンテンツ通信の回数を減少させて通信効率を向上させるためには、単に１つのデックに多くのカードをまとめるのみならず、当該コンテンツの内容や元のツリー構造に基づいて、携帯端末からの再送信要求の発生が少なくなるように、当該コンテンツをカードへ切り分け、かつ１つのデックにまとめるカードを選択することが必要となる。
【００１０】
上述したように、コンテンツをべた書きのテキストに変換し、その後、適当な文字数ごとにカードに切っていくという単純な手法では、カードの内容が不自然な切り方となる場合があり、また、コンテンツの一部だけを見ようとする場合に使用の便が悪かった。
【００１１】
また、特開２０００−１９４６１２号公報に開示された従来技術は、コンテンツの分割において、当該コンテンツにおけるツリー構造の論理的な順序を保存するとしている。また、コンテンツ内部の情報を分類し表示を行うとしている。
しかしながら、コンテンツのカードへの分割方法に格別の工夫がされておらず、また、コンテンツ内部の情報の分類においても元のデータの構造に基づいていないため、生成されたカード及びデックからなるコンテンツは、携帯端末のユーザにとって使いやすいものとは言い得ない。
さらに、これらの手法は、固有のマークアップ言語に依存しているため、汎用性を欠く。
【００１２】
また、同様の従来技術であるＰｒｏ５社のｃ−Ｍａｇｉｃは、元のＨＴＭＬテキストを特定のタグにおいて切るように工夫されているため、不自然な切れ方になる場合が減少するが、コンテンツの一部を見ようとする場合にも当該コンテンツの最初から順に見ていかなければならず、やはり使い勝手が良いとは言い得ない。
また、ＨＴＭＬテキストを切る位置となるタグを指定していることにより、<table>タグなどの途中で元のＨＴＭＬテキストを切ることができないため、コンテンツが送信された場合に、１つのデックでも携帯端末の受信バッファをオーバーフローするという危険が新たに生じている。
【００１３】
さらにまた、特開２０００−７６４７３号公報に開示された従来技術は、ツリー構造のコンテンツからカード及びデックに変換する際に、コンテンツの構造情報を変換後のデータファイルに反映させることとしている。
しかしながら、その変換ルールは発見的手法を用いて導出されているため、特定の構造やタグ情報及びデータの種類（headingタグによる見出しが有効なものなど）に依存する。したがって、一般的な構造のコンテンツに適用することは難しい。
また、この手法では、評価値が所定の基準を満たすまで（受信バッファの容量制限を満たすなど）アルゴリズムの適用を繰り返すことになっているため、大量の要求を迅速に処理しなければならないウェブアプリケーションにとっては効率が悪い。
【００１４】
そこで本発明は、ツリー状に構成されたコンテンツをカードとデックという単位に分割して送信する場合において、送信先端末の条件やコンテンツの内容に応じて、送信先端末のユーザにとって使用しやすいカードを生成することを目的とする。
【００１５】
また、本発明は、かかるコンテンツの送信において、１デックのデータサイズが送信先端末の受信バッファの制限（バイト数）を満たしながら、デックの再送信が少なくなるように、最適なカードの集合を選択してデックを動的に構成することを他の目的とする。
【００１６】
【課題を解決するための手段】
上記の目的を達成する本発明は、ネットワークを介して端末装置にウェブコンテンツを配信するサーバにおいて、ウェブコンテンツの各ノードに、このウェブコンテンツの変換に対する注釈情報を付加するノード編集部と、このウェブコンテンツを、このノードに付加された注釈情報に基づいて、このウェブコンテンツを閲覧する前記端末装置における表示単位であるカードに分割するカード生成部とを備えることを特徴とする。
【００１７】
ここで、このノード編集部は、少なくとも、自ノードが親ノードから分離可能か否かを示す情報と、自ノードに記述された情報の提示方法を特定する情報とを、注釈情報として各ノードに付加する。これにより、ウェブコンテンツを、適切な内容を含むカードに分割することができる。
また、このカード生成部は、このウェブコンテンツを、ランダムにアクセスが可能な階層メニューをなすカードとシーケンシャルにアクセスされる一連のカード群とで構成されたツリー構造を持ったカード集合に変換する。
【００１８】
また、本発明は、ネットワークを介して端末装置に対しこの端末装置における表示単位であるカードに分割されたウェブコンテンツを配信するサーバにおいて、この端末装置から受信バッファの記憶容量に関する情報を取得する端末情報取得部と、取得された情報に基づいてこの端末装置における受信バッファの記憶容量以内のデータサイズとなるように、この端末装置から送信を要求されたカード及びこのカードからリンクされるカードを所定の規則に基づいて集めて端末装置への送信単位であるデックを生成するデック生成部とを備えることを特徴とする。
【００１９】
ここで、このデック生成部は、この端末装置から送信を要求されたカードがシーケンシャルにアクセスされるカードである場合、このカードを含んでシーケンシャルにアクセスされる一連のカード群を集めてデックを生成する。あるいは、この端末装置から送信を要求されたカードがランダムにアクセスされるカードである場合、このカードを含むカード集合がなすツリー構造においてこのカードからルートカードへ向かいながらパス上のカードを順次集めてデックを生成する。
【００２０】
さらに、このデック生成部は、この端末装置から送信を要求されたカードがランダムにアクセスされるカードであり、かつこのカードからルートカードへ向かうパス上の全てのカードを集めても端末装置の受信バッファの記憶容量に達しない場合、さらに送信を要求されたカードの子孫のカードを広さ優先で集めてデックに加える。
【００２１】
また、本発明は、次のように構成されたことを特徴とするウェブコンテンツ編集装置を提供する。すなわち、このウェブコンテンツ編集装置は、ツリー構造のウェブコンテンツを入力し、このウェブコンテンツの構造に基づき、このウェブコンテンツの各ノードに対し、自ノードが親ノードから分離可能か否かを示す情報と自ノードに記述された情報の提示方法を特定する情報とを対応づけるノード編集手段と、この情報を各ノードに付加されたウェブコンテンツを格納する記憶手段とを備えることを特徴とする。
【００２２】
さらにまた、本発明は、コンピュータを制御して、ウェブコンテンツの編集や配信を行うサーバとして動作させるプログラムとして、実現することができる。すなわち、コンピュータを制御して所定の端末装置にウェブコンテンツを提供するプログラムにおいて、この端末装置から受信バッファの記憶容量に関する情報を取得し、第１の記憶手段に格納する処理と、この受信バッファの記憶容量以内のデータサイズとなるように、端末装置における表示単位であるカードに分割されたウェブコンテンツが格納された第２の記憶手段から、この端末装置に送信を要求されたカード及び当該カードからリンクされるカードを所定の規則に基づいて読み出して、端末装置への送信単位であるデックを生成する処理と、生成されたデックを端末装置に送信する処理とを、このコンピュータに実行させることを特徴とする。
【００２３】
また、コンピュータを制御してウェブコンテンツを編集するプログラムにおいて、処理対象であるウェブコンテンツのツリー構造をディスプレイに表示する手段と、表示されたウェブコンテンツにおける所定のノードの指定を受け付ける手段と、指定されたノードに対しこのウェブコンテンツの変換に対する注釈情報の入力を受け付けてこのノードに付加する手段と、このノードに注釈情報が付加されたウェブコンテンツを記憶装置に格納する手段として、このコンピュータを機能させることを特徴とする。
このプログラムは、さらに、ディスプレイに表示されたツリー構造を用いたＧＵＩ（Graphical User Interface）などのインターフェイスを用いて注釈情報を付加するノードの指定を受け付けたり、注釈情報の入力を受け付けたりすることができる。
【００２４】
さらに、コンピュータを用いてウェブコンテンツを編集するウェブコンテンツ編集方法において、このコンピュータの処理装置が、ウェブコンテンツを入力し、このウェブコンテンツの各ノードに、このノードの分割方法に関する注釈情報を付加し、注釈情報が付加されたウェブコンテンツを記憶手段に格納するステップと、この処理装置が、記憶手段から処理対象のウェブコンテンツを読み出し、このウェブコンテンツのノードに付加された注釈情報に基づいて、このウェブコンテンツを分割するステップとを含むことを特徴とする。
【００２５】
さらにまた、本発明は、端末装置からの要求に応じてウェブコンテンツを提供するサーバにおけるウェブコンテンツ提供方法において、このサーバの受信手段が、端末装置から受信バッファの記憶容量に関する情報を受信するステップと、このサーバの処理装置が、端末装置における表示単位であるカードに切り分けられたウェブコンテンツを格納した記憶手段から、要求に対応するカード及びこのカードからリンクされるカードを含むカードを、受信バッファの記憶容量以内のデータサイズ分読み出してデックを生成するステップと、この送信手段が、生成されたデックをこの端末装置に送信するステップとを含むことを特徴とする。
【００２６】
ここで、この処理装置が、ウェブコンテンツを格納した記憶手段から、送信対象であるウェブコンテンツを読み出し、読み出したウェブコンテンツをカードに分割して、この記憶手段に格納するステップをさらに含む構成とすることができる。
【００２７】
さらに、本発明は、ネットワークに接続された端末装置と、このネットワークを介してこの端末装置にウェブコンテンツを提供するコンテンツサーバとを備えたネットワークシステムにおいて、コンテンツサーバは、ツリー構造を持つウェブコンテンツを生成するアプリケーションプログラムを実行するアプリケーション実行部と、このアプリケーション実行部にて生成されたウェブコンテンツを、このウェブコンテンツを閲覧する端末装置における表示単位であるカードに分割するカード生成部と、この端末装置から受信バッファの記憶容量に関する情報を取得する端末情報取得部と、取得された情報に基づいて受信バッファの記憶容量以内のデータサイズとなるように、この端末装置から送信を要求されたカード及び当該カードからリンクされるカードを所定の規則に基づいて集めて端末装置への送信単位であるデックを生成するデック生成部とを備えることを特徴とする。
【００２８】
また、本発明は、ネットワークに接続された端末装置に対し、このネットワークを介してウェブコンテンツを提供するウェブコンテンツ提供システムにおいて、ＨＴＭＬ（Hypertext Markup Language）にて記述されたウェブコンテンツを格納した記憶手段と、このウェブコンテンツの分割方法に関する注釈情報を、このウェブコンテンツのツリー構造における各ノードに対応づけて格納した外部注釈データベースと、この端末装置からウェブコンテンツの送信要求を受け取り、要求されたウェブコンテンツをこの記憶手段から読み出し、読み出されたウェブコンテンツに関する注釈情報をこの外部注釈データベースから読み出し、読み出した注釈情報に基づいてこのウェブコンテンツを分割し、分割されたこのウェブコンテンツを端末装置に送信するコンテンツ変換手段とを備えることを特徴とする。
【００２９】
さらに、本発明は、統一表現で記述されたアプリケーションプログラムを、このアプリケーションプログラムを利用する端末装置に対応した形式に変換する変換システムにおいて、ツリー構造の統一表現で記述されたアプリケーションプログラムを格納した第１の記憶手段と、この第１の記憶手段から端末装置に提供するアプリケーションプログラムを読み出し、ツリー構造のアプリケーションプログラムの各ノードに対してこのアプリケーションプログラムの分割に関する注釈情報を付加し、この注釈情報に基づいてアプリケーションプログラムを画面分割する最適化手段と、最適化手段にて最適化されたアプリケーションプログラムを格納する第２の記憶手段と、この最適化されたアプリケーションプログラムを読み出し、このアプリケーションプログラムの提供先である端末装置に対応した形式に変換する変換手段とを備えることを特徴とする。
【００３０】
また、本発明は、ネットワークを介してサーバに接続し、ウェブコンテンツを取得する端末装置において、接続したサーバに対し、自装置の受信バッファの記憶容量に関する情報を送信する送信手段と、この送信手段にてサーバに送られた情報に基づいて生成されたウェブコンテンツを構成するデータセットを受信する受信手段とを備えることを特徴とする。
【００３１】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいて、この発明を詳細に説明する。
図１は、本実施の形態を実現するシステム構成を示す図である。
図１に示すネットワークシステムは、ウェブコンテンツを配信するコンテンツサーバ１１０、ＷＭＬやＨＤＭＬで記述されたデータを表示するブラウザを備えた端末装置１２０、コンテンツサーバ１１０と端末装置１２０とを接続するネットワーク（インターネットや無線ネットなど）１３０とを備える。
【００３２】
コンテンツサーバ１１０は、ＨＴＭＬまたは他のマークアップ言語で記述されたコンテンツを格納した記憶部１１１と、記憶部１１１から読み出したコンテンツを端末装置１２０のブラウザに対応させて変換しネットワーク１３０を介して端末装置１２０に送信するコンテンツ配信部１１２とを備える。
なお、配信されるコンテンツは、予め記憶部１１１に格納されたものの他、他のウェブサーバから取得したコンテンツであっても良いし、記憶部１１１にウェブアプリケーションを格納しておき、当該ウェブアプリケーションの記述に基づいて動的に生成されたコンテンツであっても良い。このコンテンツは、ＤＯＭ（Document Object Model）またはＤＯＭに似た抽象的なツリー構造を内部表現とする。
【００３３】
端末装置１２０は、ネットワーク１３０を介してコンテンツサーバ１１０に接続するための送受信部１２１と、コンテンツサーバ１１０から送られたウェブコンテンツを一時的に格納する受信バッファ１２２と、受信バッファ１２２に格納されたウェブコンテンツを表示する表示部１２３とを備える。また、表示部１２３にウェブコンテンツを表示するため、カードと呼ばれる画面単位及びデックと呼ばれる送受信単位をサポートするブラウザを搭載する。このブラウザは、例えばＷＭＬやＨＤＭＬといったマークアップ言語に対応している。
カードは、端末装置１２０の図示しない表示部１２３の画面サイズに依存するが、たいていの場合、ブラウザにはスクロール機能が備わっているため、物理的な画面サイズがカードのサイズの制約になることは少ない。ただし、ユーザインターフェイスとして直接人間が操作する対象であるため、カードのサイズの決め方やそのナビゲーション方法が使い勝手に影響することが多い。
一方、デックは、コンテンツサーバ１１０と端末装置１２０との間におけるコンテンツの送受信の単位であり、端末装置１２０において受信したデックを蓄える必要があるため、当該端末装置１２０の受信バッファ１２２の容量がデックのデータサイズの制約となる。ただし、受信バッファ１２２の容量以内であればデックのデータサイズが大きい方が、コンテンツサーバ１１０と端末装置１２０との間の通信料を削減し、通信効率が良くなる。
【００３４】
端末装置１２０は、ネットワーク１３０を介してコンテンツサーバ１１０に接続すると、まず送受信部１２１からコンテンツサーバ１１０に対してデバイス情報（受信バッファ１２２の記憶容量など、詳細は後述）を送信する。そして、当該デバイス情報に基づいて生成されたデータセット（上述した複数のカードを含むデック）を受信して、カードにて構成されるウェブコンテンツを表示部１２３に表示する。
このウェブコンテンツの閲覧操作において、受信したデック内にあるカードへのナビゲーションでは、受信バッファ１２２内で処理（受信バッファ１２２内に存在するカードを表示）し、コンテンツサーバ１１０へデックの送信要求を出さない。一方、デック内に存在しないカードにアクセスしようとした場合は、コンテンツサーバ１１０に対して該当するカードの送信要求を出す。
コンテンツサーバ１１０は、端末装置１２０からカードの送信要求を受け取った場合、要求されたカードを含む新たなデックを生成し、当該端末装置１２０に送信する。
【００３５】
図１に示す例では、２台の端末装置１２０がネットワーク１３０に接続されているが、実際には、表示部１２３の画面サイズや受信バッファ１２２の記憶容量が異なる種々の端末装置１２０が接続されている。コンテンツサーバ１１０は、それら端末装置１２０の能力を事前に知ることができないため、コンテンツを個々の端末装置１２０の能力に合わせて変換する作業は、具体的に端末装置１２０から送信要求があってから動的に行う必要がある。
したがって、コンテンツサーバ１１０のコンテンツ配信部１１２は、記憶部１１１から読み出したツリー構造を持つコンテンツを、送信先である端末装置１２０の表示部１２３の画面サイズと受信バッファ１２２の記憶容量とに合わせてカードとデックという単位に分ける機能を要する。そして、この作業は、上述したユーザインターフェイスとしての使いやすさと通信効率とを考慮して行われることが必要である。
【００３６】
図２は、本実施の形態によるコンテンツサーバ１１０を実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
図２に示すコンピュータ装置は、ＣＰＵ（中央処理装置）１０１と、システムバスを介してＣＰＵ１０１に接続されたＭ／Ｂ（マザーボード）チップセット１０２及びメインメモリ１０３と、ＰＣＩバスなどの高速なバスを介してＭ／Ｂチップセット１０２に接続されたビデオカード１０４、ハードディスク１０５及びネットワークインターフェイス１０６と、さらにブリッジ回路１１０及びＩＳＡバスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフロッピーディスクドライブ１０７、キーボード１０８及びＩ／Ｏポート１０９とを備える。
図２に示すコンピュータ装置にて実現されるコンテンツサーバ１１０は、ネットワークインターフェイス１０６を介してネットワーク１３０に接続される。したがって、端末装置１２０とのデータの送受信においては、ネットワークインターフェイス１０６が送受信手段となる。また、メインメモリ１０３やハードディスク１０５が、図１に示した記憶部１１１に相当する。
なお、図２は本実施の形態による検索方法を実現するコンピュータ装置の構成を例示するに過ぎず、本実施の形態を適用可能であれば、他の種々のシステム構成を取ることが可能である。
【００３７】
本実施の形態は、図２に示したメインメモリ１０３に展開されたプログラムにてＣＰＵ１０１を制御することにより図１に示したコンテンツ配信部１１２としての機能を実現させ、ハードディスク１０５から読み出したツリー構造を持つコンテンツを、送信先である端末装置１２０の表示部１２３の画面サイズと受信バッファ１２２の記憶容量とに合わせてカードとデックという単位に分割する。
図３は、プログラム制御されたＣＰＵ１０１において、本実施の形態によるコンテンツの分割を行うための機能ブロックを示す図である。
図３を参照すると、本実施の形態は、端末装置１２０の能力に関する情報を取得する端末情報取得部１０と、ハードディスク１０５から読み出したツリー状のコンテンツの各ノードに注釈情報（以下、単に注釈と称す）を付けるノード編集部２０と、ノード編集部２０にてノードに付された注釈に基づいてツリー状のコンテンツを分割しカードを生成するカード生成部３０と、カード生成部３０にて生成されたカードを集めてデックを生成するデック生成部４０とを備える。
【００３８】
上述したように、これらの構成要素は、プログラム制御されたＣＰＵ１０１により実現される仮想的なソフトウェアブロックである。当該プログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記憶媒体に格納して配布したり、ネットワークを介して伝送したりすることにより提供することができる。本実施の形態は、図２に示したネットワークインターフェイス１０６やフロッピーディスクドライブ１０７、図示しないＣＤ−ＲＯＭドライブなどを介して当該プログラムを入力し、ハードディスク１０５に格納する。そして、ハードディスク１０５に格納されたプログラムをメインメモリ１０３に読み込んで展開し、ＣＰＵ１０１にて実行する。
【００３９】
図３に示した本実施の形態の構成において、端末情報取得部１０は、コンテンツの送信先である個々の端末装置１２０（送信要求を行った端末装置）のデバイス情報を取得する。取得されたデバイス情報はメインメモリ１０３に格納される。このデバイス情報は、送信するカード及びデックを生成するためのパラメータとなる。具体的には、例えば、コンテンツの分割単位の大きさの目安となる画面サイズ、コンテンツの分離を行うかどうかを判断する目安となる表示処理や通信速度の性能、デックの大きさの制限値となる受信バッファ１２２サイズなどである。
【００４０】
ノード編集部２０は、送信対象であるコンテンツを入力し、当該コンテンツのツリーのノードに、表示される情報の性質を表すような注釈を付ける。この注釈においては、まず当該ノードが表す情報が親ノードから分離可能かどうかを指定する。分離不可能なものは親ノードにその情報が組み込まれなければならないので、本実施の形態による分割対象にはならない。分離可能な場合、分離された情報がどのようにユーザからアクセスされるかを表す性質を注釈する。例えば、一部の情報のみが選択的にアクセスされるのか（ランダムアクセス）、それとも、全ての情報が順にアクセスされるのか（シーケンシャルアクセス）を指定する。この注釈の内容は、コンテンツを構成する要素の種類（ＸＭＬのタグの種類など）やデバイスの性能値などからノード編集部２０が自動的に決めることが可能である。これに加えて、コンテンツ作成時（あるいは動的なコンテンツの設計時）に開発者がコンテンツの意味内容などから適切な注釈を予め付けておくこともできる。また、コンテンツの表示テスト時に注釈を変更して、より適切な表示になるように調整することもできる。ノードに注釈が付されたコンテンツはメインメモリ１０３に格納される。
なお、この注釈については、後でさらに詳細に述べる。
【００４１】
カード生成部３０は、ノード編集部２０により注釈が付けられたコンテンツをメインメモリ１０３から読み出し、カードに分割する。このとき、ランダムアクセスの注釈が付けられたノードは、子ノードへのリンクを含むようなメニューのカードとして生成する。子供のノードに対してもさらにランダムアクセスの注釈が付いていれば、再帰的にメニューのカードを生成する。この結果、ランダムアクセスのノード集合は、全体として階層メニューの形式となる。シーケンシャルアクセスの注釈が付いたノードの場合は、その子孫のノードで単独の表示単位となるもの全てを元の順序が保存されるように並べる。その後、適当な大きさでカードに分割し、順にアクセスされるようにリンクを張る。シーケンシャルアクセスの場合、必要なら分離されたカードへのリンクを含むようなアウトラインカードを作成しても良い。
ランダムアクセス及びシーケンシャルアクセスのどちらの場合も、分離不可能な子ノードは全て親ノードのカードに埋め込むようにする。結果として、ランダムアクセスされるカードによる階層的なメニューとシーケンシャルアクセスされる一連のカード群とからなるツリー構造を持ったカード集合が生成される。このカードのツリーは、上述したように分離不可能なノードを１つのカードにまとめる操作が行われているため、元のコンテンツのツリー構造そのものではないが、その構造はある程度反映されている。また、各カードがランダムアクセスされるものか、シーケンシャルアクセスされるものかの区別は、当該カードに変換されたノードにしたがう。
なお、コンテンツのカード化アルゴリズムの詳細は後述する。
【００４２】
デック生成部４０は、端末装置１２０から所定のカードを要求された場合（最初のコンテンツの要求に対しては、カードのツリーのルートカードが要求されたとする）、適切なカードを集めてデックを生成し、当該要求を行った端末装置１２０に返送する。
ここで、デックの生成は次のように行う。すなわち、まずルートカードから要求されたカードまでのパス上にあるカードをデックに加え（「１つ上に戻る」というリンクをたどる）、さらに、要求されたカードから子孫のカードを広さ優先でデックに加えていく。ただし、要求されたカードがシーケンシャルアクセスのカードである場合は、これらのカードに先立って、要求された当該カードの次にアクセスされるカード（例えば、「次へ」というリンクをたどることで得られる）をまずデックに加える。
端末装置１２０の受信バッファ１２２の記憶容量に基づくデックのデータサイズ（制限容量）にさらに余裕があれば、親のカードに対しても同様な処理を繰り返して適用し、デックにカードを加えていく。各カードのデータサイズ（バイト数）の和が１デックの制限容量になるまでカードを加えていくことにより、端末装置１２０からの要求に対するデックを確定する。
なお、デック生成アルゴリズムの詳細は後述する。
【００４３】
次に、ノード編集部２０によってコンテンツの各ノードに付加される注釈について説明する。
本実施の形態では、ノードに付加する注釈を次のような情報とする。
・当該ノードは親ノードからカードとして分離可能かどうかを示す情報。
・（分離可能なノードにはさらに）当該ノードに記述された情報の提示方法。すなわち、情報に対してユーザがどのようにアクセスするか（ランダムアクセスかシーケンシャルアクセスか）を区別する情報。
・分割の単位。具体的には、分割された後のカードに含まれるべき情報の個数（コンテンツのツリーのノード数）を指定する情報。
ランダムアクセスの注釈が付加されるコンテンツの性質としては、次のようなものが考えられる。
１．必ずしも全てアクセスされない情報の集まり。
２．ユーザが任意の部分（カード）を選んで表示する。
３．複数部分（カード）の表示順序が任意。
４．ツリーの上下に移動する可能性が高い。
一方、シーケンシャルアクセスの注釈が付加されるコンテンツの性質としては、次のようなものが考えられる。
１．全ての情報がアクセスされるべきもの。
２．アクセスされる順番が決まっている。
３．任意の部分の検索や飛び越しなどのアクセスはあまり行われない。
４．ツリーの左右（アクセスする順番）に移動する可能性が高い。
これらの注釈は、上に述べたようなガイドラインに基づいて、事前にプログラマがコンテンツの意味を考慮して付加することもできるし、コンテンツの構造やタグの情報を利用してヒューリスティックス（発見的手法）を用いて自動的に付与することもできる。さらに、自動的に付けられた注釈に対し、アプリケーションのプログラマが部分修正をしても良い。
【００４４】
次に、カード生成部３０によるコンテンツのカード化アルゴリズムについて説明する。
図４は、ツリー構造のコンテンツをカードに分割する手順を説明するフローチャートである。
図４を参照すると、このアルゴリズムは、コンテンツのツリーのルートから再帰的に実行するようになっている。まず、メインメモリ１０３から読み出されたコンテンツのルートノードがカレントノードとして与えられ、ノードの探索（以下のステップ４０３〜４０８の処理）を行う（ステップ４０１）。再帰的な実行であるので、以下の処理による全てのノードの探索が終わっていれば、カード化のアルゴリズムを終了する（ステップ４０２）。
【００４５】
ノードの探索では、まず、自分のノード自身と子供のノード（子ノード）で分離不可能なものを作成するカード（カレントカード）の内容とする（ステップ４０３）。ここまでで、分離可能な子供が分離するだけの十分な数がない場合（例えば、分離可能な子供が０の場合、または１個しかないので分離しても意味がない場合）は、全ての情報を１つのカレントカードに組み込む。そして、これより下位のノードを探索する必要がないので、別のノードの探索に戻る（ステップ４０４、４０８）。
分離可能な子ノードが十分ある場合は、さらに、当該子ノードがランダムアクセスかシーケンシャルアクセスかを注釈によって判断する（ステップ４０５）。当該子ノードがシーケンシャルアクセスされるノードである場合は、当該子ノードを全て表示順にフラットに並べる。そして、カードのデータサイズの目安と各ノードの情報量とに基づき、各カードに含まれる情報料が等分になるようにグルーピングしてカードの列に変換する。生成された各カードには、次のカードへのリンクなどを生成する。また、シーケンシャルアクセスされるカード列については、カレントカードを、当該カード列のアウトラインを示すカードとし、各カードへのリンクを生成することができる。また、アウトラインカードを作成せずに、他のカードからシーケンシャルなカード列へのリンク先を当該カード列の一番目のカードとすることもできる（ステップ４０６）。
一方、分離可能な子ノードが十分あり、それらがランダムアクセスされるノードである場合、各子ノードへのリンクをメニューとしてカレントカードに含め、次に当該子ノードの任意の１つを新たなカレントノードとし（ステップ４０７）、ステップ４０２に戻って全てのノードの探索が完了したかどうかを判断し、分離したノードに対して、ステップ４０３以降のカード化アルゴリズムを再帰的に適用する。
以上のようにして、カードのツリーが生成される。
【００４６】
次に、デック生成部４０によるデック生成アルゴリズムについて説明する。
図５は、図４で生成されたカードを集めてデックを生成する手順を説明するフローチャートである。
図５を参照すると、まず、要求されたカードをメインメモリ１０３から読み出し、シーケンシャルアクセスのカードかどうかを判断する（ステップ５０１）。そして、シーケンシャルアクセスされるカードである場合は、カード内の情報の順序（参照される順序）にしたがって、デックの制限容量の範囲内で当該シーケンシャルにアクセスされる全てのカードをメインメモリ１０３から読み出し、デックに加える（ステップ５０２）。この時点でデックの制限容量に達したならば、デックの生成処理を終了する（ステップ５０３）。
【００４７】
ステップ５０１で要求されたカードがランダムアクセスのカードであると判断された場合、及びシーケンシャルアクセスのカードと判断され、かつ当該シーケンシャルにアクセスされる全てのカードをデックに加えても当該デックの制限容量に達しない場合は、次に、要求されたカードからルートカードに戻るパス上のカードをメインメモリ１０３から読み出し、当該デックに加える（ステップ５０４）。この時点でデックの制限容量に達したならば、デックの生成処理を終了する（ステップ５０５）。
ステップ５０４でカードを加えても未だデックの制限容量に達しない場合は、さらに要求されたカードの子孫のカードを広さ優先で（すなわちカードのツリーの浅い層に位置するカードを優先して）メインメモリ１０３から読み出し、当該デックに加える（ステップ５０５、５０６）。この時点でデックの制限容量に達したならば、デックの生成処理を終了する（ステップ５０７）。
ステップ５０６でカードを加えても未だデックの制限容量に達しない場合は、要求されたカードの親のカードを改めて要求されたカードとみなして、ルートカードに至るまで順次ステップ５０１から処理を繰り返す（ステップ５０７、５０８、５０９）。
【００４８】
なお、図４に示したアルゴリズムでカードを生成した場合、分離不可能なノードは１つのカードにまとめていくため、１つのカードのデータサイズが当該カードを要求した端末装置１２０の受信バッファ１２２の記憶容量を超えてしまう場合がある。この場合、当該受信バッファ１２２の記憶容量内に収まるように、当該カードを分割する必要がある。
図５に示すデックの生成過程において、ステップ５０２またはステップ５０４で最初に選択した（すなわち端末装置１２０から要求された）カードが当該端末装置１２０の受信バッファ１２２の記憶容量を超えている場合は、当該カードの分割が必要である。このカードの分割は、本来、本実施の形態に基づいて分割不可能な内容であるので、本実施の形態を離れ機械的に行われることとなる。具体的には、当該カードの内容をべた書きのテキストとみなし、字数等に基づいて単純に分割するといった既存の手法を取ることができる。
【００４９】
以上のようにして、ツリー状のコンテンツをカードとデックに分解した。なお、コンテンツの送信先である端末装置１２０の能力に合わせて（デバイス情報に基づいて）上記のようにコンテンツを変換する場合、必要な情報だけを選択する、情報の提示の順番を変更する、関連する情報をグループ化する（特に分割表示不可能な情報を１つにまとめる）などの処理が行われる場合がある。これらの処理は、既存の従来技術を用いて行うことが可能である。これらの変更結果は、コンテンツのツリーとして表すことができる。例えば、情報の選択は、子ノードへのリンクを削除することで行うことができる。また、情報提示の順番は、子ノードの順番で表現することができる。さらに、分割不可能な情報は、それらの情報を１つのノードに統一することで表現することができる。これらの変換処理は、端末情報取得部１０が端末装置１２０のデバイス情報を受け取った後、カードへの分割の前に実行する。不可分な情報の変換などを含むことを考慮すれば、ノード編集部２０によるノードへの注釈の付加が行われた後に実行しても良い。
【００５０】
次に、本実施の形態を具体的なネットワークシステムに適用した適用例を説明する。
図６は、本実施の形態が適用されるネットワークシステムの構成例を示す図である。
図６に示すネットワークシステムにおいて、コンテンツサーバ（ウェブアプリケーションサーバ）１１０は、ＸＭＬで記述されたウェブアプリケーションを実行するアプリケーション実行部１１３と、当該ウェブアプリケーションを実行して動的に生成されたコンテンツを、無線ネットワーク１３０を通じて端末装置１２０に配信するコンテンツ配信部１１４とを備える。なお、コンテンツ配信部１１４の機能は図３を参照して説明した図１のコンテンツサーバ１１０におけるコンテンツ配信部１１２と同様である。
コンテンツサーバ１１０と端末装置１２０との間でのコンテンツの送信は、ＷＡＰ（Wireless Application Protocol）にしたがって行われ、端末装置１２０は、ＷＭＬに対応したブラウザでカード化されたコンテンツを表示する。
また、端末装置１２０は、コンテンツサーバ１１０に接続すると、ＣＣ／ＰＰ（W3C, Composite Capabilities/Preference Profiles: Requirements and Architecture (Working Draft) http://www.w3.org/Mobile/CCPP/）などの記述方式を用いて、画面サイズや受信バッファ１２２のサイズなどのデバイス情報をコンテンツサーバ１１０に通知する。
【００５１】
本適用例では、ウェブアプリケーションとして、コンピュータ関連機器の製品検索と製品紹介を行うものを考える。いくつかの検索方法を用いて検索された製品は、カテゴリによって分類されて表示される。
図７は、ウェブアプリケーションによる製品検索の検索結果を示すツリー状のコンテンツ及びそのノードに注釈が付された状態の例を示す図である。
図７に示すコンテンツは、カテゴリに基づいて特定の１つの製品に関する情報を選んで閲覧するようなコンテンツである。図７を参照すると、製品紹介のノードは、まず、コンピュータ製品と周辺機器製品の２つのカテゴリに分けられる。さらに、コンピュータ製品は、ノートブック型パーソナルコンピュータ（図ではノートＰＣと表記）とデスクトップ型パーソナルコンピュータ（図ではデスクトップＰＣと表記）に分けられる。ここまでのノードは、ユーザが適当なカテゴリを選択してナビゲートしていくための情報であり、図示のように各ノードが分離可能でありかつランダムアクセスの注釈を付けることができる。
ノートブック型パーソナルコンピュータの下にある製品Ａのノードは、ユーザが全ての情報にアクセスする内容であるとして、シーケンシャルアクセスの注釈が付けられる。製品Ａのノードはさらに、製品名、特徴、スペックなどの詳細情報からなるが、そのなかで製品名と値段は基本的な情報であるので分離不可能という注釈が付けられる。
【００５２】
これらの注釈は、ＸＭＬで記述されたウェブアプリケーションの中に付加的情報として埋め込むことができる。例えば、タグの属性情報としてこれらの注釈を書くことができる。
図８は、付加的情報として注釈を埋め込んだＸＭＬ文書の例を示す図である。図８において、「LItem」は、構造を持つ情報を表すためのタグである。「LWord」「LText」は、実際の文字情報をあらわすタグであり、それぞれ、単語と文章とを記述する目的に使われる。各タグの属性において、「caption」は、情報の見出しを指定するものである。実際にコンテンツがＷＭＬに変換された場合は、各画面の見出しやリンクのタイトルとして使われる。
また、図８において、「category」属性が、カード及びデックへの分割に使われる注釈を記述するための属性である。「category」の値として、各注釈の内容をカンマで区切って記述する。注釈は、
outline=.., split=..
という形をしており、outline=yesの場合は分離可能、outline=noの場合は分離不可を表す。また、split=menuはランダムアクセス、split=seqはシーケンシャルアクセスのノードであることを表す。
【００５３】
図９は、以上の注釈に基づいて、図７のコンテンツに対し、図４に示したカード生成部３０によるカード化アルゴリズムを適用した例を示す図である。
図９において、破線で囲まれた範囲が１枚のカードである。図９を参照すると、ランダムアクセスのノードでは、各ノードがそれぞれ１つのカードになっている。したがって、端末装置１２０によってこのカードを閲覧するユーザは、製品のカテゴリに基づいてリンクをたどっていくことにより、目的の情報にたどり着くことができる。
一方、シーケンシャルアクセスのノードである製品Ａのノードでは、その下のノードである製品名、特徴、特徴１、特徴２、スペック、スペック１、スペック２、値段は、フラットに並べられる。ただし、製品名と値段とは分離不可能な情報(outline=no)であるので、アウトラインのカードにそのまま組み込まれる。また、特徴１及び特徴２は、情報量が比較的少ないので、合わせて１カードとしている。スペック１及びスペック２は、情報量が多いため、それぞれ１カードとしている。これらのカードは、順にアクセスされるようにリンク（図では矢印で示した）が張られる。また、分離されたカードは、製品Ａのアウトラインのカードからもリンクが張られる。
【００５４】
図１０は、図９に示したようにカード化されたコンテンツに対して、図５に示したデック生成部４０によるデック生成アルゴリズムを適用した例を示す図である。
図１０において、丸数字で表したノードは製品カテゴリのカード（ランダムアクセス）であり、四角の英字で表したノードは個々の製品情報のカード（シーケンシャルアクセス）である。
図１０（Ａ）に示すカードツリーを、カテゴリで辿っていって製品情報Ａ、Ｂ、Ｃのカードを順にアクセスし、その後、ルートカードまで戻ってさらに別の製品情報Ｄ、Ｅのカードをアクセスしていった場合のデック分割の様子を、図１０（Ｂ）に示した。この過程で、全部で４つのデックが生成され、コンテンツサーバ１１０から端末装置１２０へ送信されている。
【００５５】
具体的に説明すると、端末装置１２０のユーザがまずカード〔１〕にアクセスするため、当該カード〔１〕を含むデックの送信要求を行う。コンテンツサーバ１１０は、これに応じて、カード〔１〕〜〔５〕をまとめたデック１００１を作成し、端末装置１２０へ送信する。
端末装置１２０は、デック１００１を受信するとこれを受信バッファ１２２に格納し、アクセス対象であるカード〔１〕を表示部１２３に表示する。端末装置１２０のユーザは、当該デック１００１内で、カード〔２〕、〔４〕とたどり、次にカード〔Ａ〕にアクセスする。カード〔Ａ〕はデック１００１に含まれていないので、端末装置１２０はコンテンツサーバ１１０にカード〔Ａ〕を含むデックの送信要求を行う。コンテンツサーバ１１０は、これに応じて、カード〔１〕、〔２〕、〔４〕、〔Ａ〕、〔Ｂ〕をまとめたデック１００２を作成し、端末装置１２０へ送信する。
【００５６】
端末装置１２０は、デック１００２を受信すると、デック１００１を破棄して新たに受信したデック１００２を受信バッファ１２２に格納し、アクセス対象であるカード〔Ａ〕を表示部１２３に表示する。端末装置１２０のユーザは、当該デック１００２内で、さらにカード〔Ｂ〕を閲覧した後、カード〔Ｃ〕にアクセスする。カード〔Ｃ〕はデック１００２に含まれていないので、端末装置１２０はコンテンツサーバ１１０にカード〔Ｃ〕を含むデックの送信要求を行う。コンテンツサーバ１１０は、これに応じて、カード〔１〕、〔２〕、〔４〕、〔５〕、〔Ｃ〕をまとめたデック１００３を作成し、端末装置１２０へ送信する。
【００５７】
同様にして、端末装置１２０はデック１００３を受信バッファ１２２に格納し、カード〔Ｃ〕を表示部１２３に表示する。この後、ユーザは、デック１００３に含まれる各カードを閲覧し、さらにカード〔３〕にアクセスする。カード〔３〕はデック１００３に含まれていないので、カード〔１〕、〔３〕、〔Ｄ〕、〔Ｅ〕をまとめたデック１００４が作成される。端末装置１２０のユーザは、このデック１００４の中でカード〔Ｄ〕、〔Ｅ〕を閲覧する。
なお、これらの１デックのデータサイズは、端末装置１２０から送信されたデバイス情報に基づく受信バッファ１２２の容量制限から、５枚のカードまで含めることができると仮定している。
【００５８】
次に、このコンテンツのノードに対して開発者が注釈を付加する場合の編集ツールについて説明する。ノードに付加する注釈を編集するには、結果画面を見ながら編集を行うことが可能なツール（ソフトウェア）を用いる。このツールは、ウェブアプリケーションの実行装置であるコンテンツサーバ１１０と統合されており、図示しない表示装置に対してウェブアプリケーションの実行画面とＧＵＩによるコンテンツの編集画面とを自由に切り替えて表示し、ウェブアプリケーションの実行またはコンテンツの編集を行うことができるようになっている。
図１１は、コンテンツの編集画面であり、注釈を付けるノードを決定する画面の表示例を示す図である。
図１１に示す編集画面では、編集対象であるコンテンツのツリー１１０１が表示され、その中で注釈を付けたいノードを選択できるようになっている。すなわち、各ノード（各行に対応）の左端にラジオボタン１１０２が設けられており、ユーザは、注釈を付けようとする任意のノードを選択することができる。
【００５９】
注釈を付けるノードが決定されると、次に、注釈を付加する画面に移行する。
図１２は、コンテンツの編集画面であり、所望のノードに注釈を付加する画面の表示例を示す図である。
図１２に示す編集画面は、該当ノードのプレビュー領域１２０１、対象となるデバイスの表示・選択領域１２０２、及び注釈の表示・入力領域１２０３からなる。注釈の表示・入力領域１２０３における注釈名「AHint」の欄に、予めタグに設定されたoutline=yes, split=menuなどの文字列を書くことによって、分割可能性や情報提示方法の注釈を指定することができる。
以上のようにしてノードに注釈が付されると、当該コンテンツは、コンテンツサーバ１１０におけるメモリやハードディスクなどの記憶部１１１に格納され、後に端末装置１２０からの要求に応じてカード生成部３０に読み出され、その分割処理の際にノードに付された注釈が利用される。
【００６０】
図１３は、本実施の形態が適用されるネットワークシステムの他の構成例を示す図である。
図１３に示すネットワークシステムには、コンテンツサーバ１１０に対応するサーバとして、ＨＴＭＬで記述されたニュースコンテンツを、ＨＤＭＬブラウザを持つ端末装置１２０用に変換する変換器（トランスコーダ）１３０１が設置されている。ＨＴＭＬは書式が決まっているのでＸＭＬのように任意に注釈を付けることができない。そこで、この例では、ニュースコンテンツを記述するＨＴＭＬ文書の所望の場所を指示して注釈を対応づける外部注釈を用いる。トランスコーダ１３０１は、ニュースサーバ１３０２からニュースコンテンツを読み出し、外部注釈データベース１３０３から当該ニュースコンテンツのＨＴＭＬ文書に対応する外部注釈を取得して、これに基づいて当該ニュースコンテンツをＨＤＭＬに変換し端末装置１２０に送信する。
ニュースコンテンツを格納するニュースサーバ１３０２及び外部注釈を格納する外部注釈データベース１３０３は、トランスコーダ１３０１と共に１つのサーバを構成していても良いし、トランスコーダ１３０１とは別にネットワーク１３０上に設けられたサーバであっても良い。
【００６１】
ニュースサーバ１３０２に格納されたニュースコンテンツは、政治、経済、社会、娯楽といったカテゴリに分類されており、これらは、ランダムアクセスノードである。個々の記事は、見出し、小見出し、リード、本文といった構成要素からなるが、これらは全てシーケンシャルアクセスである。
これらのニュースコンテンツはＨＴＭＬで記述されており、トランスコーダ１３０１は適切なＨＴＭＬパーサを用いて当該ニュースコンテンツをツリー（ＤＯＭツリー）に変換することができる。このようなＤＯＭツリーに対して外部注釈をすることにより、当該ＤＯＭツリーのノードに注釈を付することができる。ここで、外部注釈は、ＸＰａｔｈ（W3C, XML Path Language (XPath) Version 1.0,  HYPERLINK "http://www.w3.org/Style/XSL/" http://www.w3.org/Style/XSL/）などを用いてニュースコンテンツのＨＴＭＬ文書における所望の場所をポイントし、対応する外部注釈を対応づけることにより行うことができる。この外部注釈は、外部注釈データベース１３０３に予め蓄積されており、端末装置１２０からの要求に応じてコンテンツを変換するときに使用される。
【００６２】
図１４は、ＨＴＭＬで記述されたニュースコンテンツに注釈を付ける様子を示す図である。
図１４に示すオリジナルのニュースコンテンツは、外部注釈によって図示のように注釈が付される。この例では、外部注釈もＸＭＬで記述されており、「AHint」というタグでカード・デックの分割のための注釈が表現される。注釈内容は、「op」という属性値に記述される。記述内容は図８を参照して説明した例と同様であるものとする。各注釈(<AHint>)がどのＨＴＭＬ要素を指しているかは、ＸＰａｔｈで記述される。図１４では、ＸＰａｔｈを右から左方向への矢印で示し、実際の表現の例を最初の２つの注釈のみ示している。
【００６３】
図１４に示されたノードのうち、「最新ニュース」、「スポーツ」は、ランダムアクセス（split=menu）のノードである。一方、「記事１」は、シーケンシャルアクセス（split=seq）である。「h1」、「h2」タグで表された大見出し、小見出しは、記事１の要素であり、しかも分離不可能（outline=no）の要素である。一方、記事のリード及び本文は、分離可能（outline=yes）である。
このような注釈は、トランスコーダ１３０１の開発者が図１４に示したような注釈言語を用いて手で記述しても良いし、ヒューリスティックス（発見的手法）を用いて自動的に記述しても良い。図１４の例では、「ul」タグに対しては分離可能かつランダムアクセス、「div」タグは分離可能かつシーケンシャルアクセス、「h1」及び「h2」タグは分離不可能、といったルールを作ることにより自動的に注釈を付けることができる。さらに、自動で付与した注釈を、トランスコーダ１３０１の開発者が部分的に書き換えて、最適化することも可能である。
【００６４】
図１５は、図１４のＸＭＬ文書がカード化されたコンテンツの例を示す図である。
図１５を参照すると、ニュースページのカードには、「最新ニュース」の他に「今日のニュース」、「昨日のニュース」といった選択肢がある。また「最新のニュース」のカードには、「スポーツ」の他に「政治」、「経済」といった選択肢がある。以下、選択肢を順にたどり、図１４に示した内容を示すカードが選択されている。
【００６５】
上述した２つの適用例では、ＸＭＬやＨＴＭＬで記述されたコンテンツをＷＭＬやＨＤＭＬに変換して配信する例を示した。しかしながら、本実施の形態で用いたコンテンツをカード化するアルゴリズムは、デックの概念が存在しない言語に対応した端末装置にコンテンツを送信するためのページ分割にも利用することができる。例えば、ＨＴＭＬページの分割や、端末上で動作するＪａｖａで記述されたＧＵＩプログラムに対しても、ツリー状のコンテンツを処理する場合には適用可能である。具体的には、所定のコンテンツを異なる複数の実行環境に対応させるフロントエンドアプリケーション開発モデルに本実施の形態を適用することができる。
【００６６】
図１６は、このような開発モデルの構成例を示す図である。
図１６に示す開発モデルは、統一形式で書かれたアプリケーションプログラムを所定のデバイスクラスに最適化する最適化装置１６０１と、最適化装置１６０１にて最適化されたプログラムを実行環境に適したフォーマット（あるいは端末プログラムコード）に変換する変換手段とを備える。この変換手段として、図１６には、ＨＴＭＬで記述されたコンテンツを生成するＨＴＭＬ生成器１６０２と、ＷＭＬやＨＤＭＬに対応したカードとデックとからなるコンテンツを生成するデック生成器１６０３と、Ｊａｖａプログラムを生成するＪａｖａプログラム生成器１６０４とを備える。
【００６７】
アプリケーションプログラムの統一表現は、ＤＯＭツリー等のツリー構造で表現され、かつ、端末装置１２０の種類や実行環境に依存しないプログラムである。このアプリケーションプログラム自体は、何らかのアプリケーション開発ツールを用いて作成される。アプリケーションプログラムの物理的な表現形式は、ＸＭＬを用いたタグ表現でも良いし、独自のアプリケーション記述言語を用いても良い。また、Ｊａｖａオブジェクトの一般的なファイル格納形式（Serialized Objects）でも良い。さらに、このアプリケーションプログラムには、同じ表現形式を用いて、本実施の形態によるカード分割に用いられる注釈が含まれている。
【００６８】
最適化装置１６０１は、この統一表現によるアプリケーションプログラムをメモリから読み込み、予め設定されたデバイスクラスで最適に表示できるように画面分割を行う。ここで、図４に示したカード化アルゴリズムが使用される。なお、デバイスクラスは、このアプリケーションプログラムを使用する端末装置１２０を、その画面サイズなどの分類要素に基づいて数種類のクラスに分けたものである。例えば、携帯電話のように非常に小さい画面を持つコンパクト画面クラス、それよりは大きいがやはり携帯端末の画面であるスモール画面クラス、それよりも大きい画面のテレビ画面クラス、さらに大きい画面の大画面クラスなどに分けることができる。なお、これらの最適化の基準は、上記表示部１２３の画面サイズの他、表示部１２３の解像度や通信速度など、アプリケーションプログラムを配信しようとする端末装置１２０の企画や仕様に応じて任意に設定することができる。
【００６９】
最適化されたアプリケーションプログラムは、さらに複数の実行環境から共有されるように一時的にメモリに格納される。このときの表現形式も統一表現と同じ形式が使われる。
ＨＴＭＬブラウザを持つパーソナルコンピュータなどの端末装置１２０でこのアプリケーションプログラムを表示させる場合は、ウェブサーバ１６１０上で動作するＨＴＭＬ生成器１６０２を用いてアプリケーションプログラムの変換を行う。すなわち、ＨＴＭＬ生成器１６０２は、メモリに格納されている最適化されたアプリケーションプログラムを読み込み、当該アプリケーションプログラムに対応するＨＴＭＬ文書を生成し、ＨＴＭＬブラウザを備えたパーソナルコンピュータなどの端末装置１２０に送信する。
また、ＷＭＬやＨＤＭＬに対応したブラウザを持つ端末装置１２０でこのアプリケーションプログラムを表示させる場合は、同じくウェブサーバ１６１０上で動作するデック生成器１６０３を用いてアプリケーションプログラムの変換を行う。この場合は、ＷＭＬやＨＤＭＬにデックの概念が存在するので、デックを生成してから変換を行う。このとき、個々の端末装置１２０から取得した受信バッファ１２２の容量制限などに基づいてデックを生成する。
さらに、同一の最適化プログラム表現を用いて、端末装置１２０上で動作するプログラムを生成することもできる。Ｊａｖａプログラム生成器１６０４は、メモリから最適化されたアプリケーションプログラム表現を読み込み、端末装置１２０上で動作するＪａｖａプログラムを生成する。生成されたＪａｖａプログラムをＪａｖａＶＭ（Virtual Machine）を搭載した端末装置１２０にダウンロードして実行することができる。
【００７０】
【発明の効果】
以上説明したように、本発明によれば、ツリー状に構成されたコンテンツをカードとデックという単位に分割して送信する場合において、送信先端末の条件やコンテンツの内容に応じて、送信先端末のユーザにとって使用しやすいカードを生成することができる。
【００７１】
また、本発明によれば、かかるコンテンツの送信において、１デックのデータサイズが送信先端末の受信バッファの制限（バイト数）を満たしながら、デックの再送信が少なくなるように、最適なカードの集合を選択してデックを動的に構成することができる。
【図面の簡単な説明】
【図１】  本実施の形態を実現するシステム構成を示す図である。
【図２】  本実施の形態によるコンテンツサーバを実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
【図３】  図２のプログラム制御されたＣＰＵにおいて、本実施の形態によるコンテンツの分割を行うための機能ブロックを示す図である。
【図４】  本実施の形態によりツリー構造のコンテンツをカードに分割する手順を説明するフローチャートである。
【図５】  本実施の形態によりカードを集めてデックを生成する手順を説明するフローチャートである。
【図６】  本実施の形態が適用されるネットワークシステムの構成例を示す図である。
【図７】  ウェブアプリケーションによる製品検索の検索結果を示すツリー状のコンテンツ及びそのノードに注釈が付された状態の例を示す図である。
【図８】  付加的情報として注釈を埋め込んだＸＭＬ文書の例を示す図である。
【図９】  図７のコンテンツに対し、本実施の形態のカード化アルゴリズムを適用した例を示す図である。
【図１０】  図９のカード化されたコンテンツに対し、本実施の形態のデック生成アルゴリズムを適用した例を示す図である。
【図１１】  本実施の形態によるコンテンツの編集画面であり、注釈を付けるノードを決定する画面の表示例を示す図である。
【図１２】  本実施の形態によるコンテンツの編集画面であり、所望のノードに注釈を付加する画面の表示例を示す図である。
【図１３】  本実施の形態が適用されるネットワークシステムの他の構成例を示す図である。
【図１４】  ＨＴＭＬで記述されたニュースコンテンツに注釈を付ける様子を示す図である。
【図１５】  図１４のＸＭＬ文書がカード化されたコンテンツの例を示す図である。
【図１６】  本実施の形態が適用されるフロントエンドアプリケーション開発モデルの構成例を示す図である。
【符号の説明】
１０…端末情報取得部、２０…ノード編集部、３０…カード生成部、４０…デック生成部、１１０…コンテンツサーバ、１１１…記憶部、１１２…コンテンツ配信部、１２０…端末装置、１３０…ネットワーク
【図１】
0003824298.tif 000002
【図２】
0003824298.tif 000003
【図３】
0003824298.tif 000004
【図４】
0003824298.tif 000005
【図５】
0003824298.tif 000006
【図６】
0003824298.tif 000007
【図７】
0003824298.tif 000008
【図８】
0003824298.tif 000009
【図９】
0003824298.tif 000010
【図１０】
0003824298.tif 000011
【図１１】
0003824298.tif 000012
【図１２】
0003824298.tif 000013
【図１３】
0003824298.tif 000014
【図１４】
0003824298.tif 000015
【図１５】
0003824298.tif 000016
【図１６】
0003824298.tif 000017