JP2011065385A

JP2011065385A - マークアップ言語文書変換装置、マークアップ言語文書変換方法、およびマークアップ言語文書変換プログラム

Info

Publication number: JP2011065385A
Application number: JP2009214964A
Authority: JP
Inventors: Shosuke Suehiro; 章介末廣
Original assignee: Access Co Ltd
Current assignee: Access Co Ltd
Priority date: 2009-09-16
Filing date: 2009-09-16
Publication date: 2011-03-31

Abstract

【課題】モバイル端末とｗｅｂサーバとの間に変換サーバが介在する場合にｗｅｂページ間の遷移に不具合が生じることを防止する。
【解決手段】変換サーバは、コンテンツサーバから受信したＭＬ文書がイベント属性付タグを含むフォームを含むかチェックする（Ｓ８３）。そうであれば、イベント属性付タグを、送信ボタンを構成するインプットタグに変更するとともに、イベント属性としてのクライアントサイドスクリプトをフォームの送信内容に埋め込んで（Ｓ８４）、クライアントへ送信する（Ｓ８６）。変換サーバは、クライアントからフォームの選択結果情報とともにクライアントサイドスクリプトを受信したとき、選択結果情報に基づいて当該スクリプトを実行する（Ｓ９０）。その結果、コンテンツサーバへ所定の要求および選択結果情報を送信する（Ｓ９１）。
【選択図】図３１

Description

本発明は、ｗｅｂサーバ（コンテンツサーバ）とクライアントとの間で、クライアントから要求されたマークアップ言語文書をｗｅｂサーバから受信して所定の変換を施してクライアントへ送信し、クライアントからの入力情報をｗｅｂサーバへ返信するマークアップ言語文書変換装置、マークアップ言語文書変換方法、およびマークアップ言語文書変換プログラムに関する。

近年、携帯電話端末や通信機能付きＰＤＡなどの移動通信端末装置では、インターネット上のＰＣ（パーソナルコンピュータ）用のｗｅｂサイトでのｗｅｂページを閲覧することができるようになってきている。移動通信端末装置を本明細書ではモバイル端末ともいう。

モバイル端末の表示画面のサイズは一律ではないが、通常、ＰＣ用の表示装置の表示画面に比べてその解像度（縦横画素数）は小さい。そのため、ＰＣ用ｗｅｂページをそのままモバイル端末の表示画面に表示させようとすると、表示されたｗｅｂページが垂直方向のみならず水平方向にも、画面から大きくはみ出し、水平、垂直両方向に頻繁にスクロール操作を行う必要が生じる。

このような問題に対して、特許文献１には、大サイズのｗｅｂページを解析してより小さいサイズのサブページに分割し、これをモバイル端末で閲覧する技術が開示されている。

特許文献２にはＰＣ用のｗｅｂページを解析して無線端末での表示に適した情報に変換する技術が開示されている。

米国特許第７２０３９０１号公報米国特許第７０４７０３３号公報

上記のような背景において本願出願人は特願２００７−３３９８７８号として、ＰＣ用ｗｅｂページなどに対応する第１マークアップ言語（ＭＬ： Markup Language）文書を、比較的忠実にモバイル用ｗｅｂページなどに対応する第２マークアップ言語文書に自動的に変換することができる技術を提案した。

この技術を種々のアプリケーションへ応用していくことを検討していく中で、１つのフォーム内で複数の送信ボタンを用いるような特定の状況でｗｅｂページ間の遷移に不具合が生じることが判明した。この一因は、モバイル用ｗｅｂページを表示するモバイル端末に搭載されたブラウザがＭＬ文書に埋め込まれたクライアントサイドスクリプトを実行する機能を備えていないことにある。

本発明はこのような背景において、モバイル端末とｗｅｂサーバとの間に変換サーバが介在する場合に特定の内容のｗｅｂページについてｗｅｂページ間の遷移に不具合が生じることを防止することを目的とする。

本発明によるマークアップ言語文書変換装置は、クライアントから要求されたマークアップ言語文書をコンテンツサーバから受信する手段と、受信したマークアップ言語文書がユーザに情報の入力を促すフォームを含み、かつ、このフォームが、所定のイベントに応じてクライアントサイドスクリプトを起動するイベント属性付タグを含むか否かをチェックする手段と、前記イベント属性付タグを、送信ボタンを構成するインプットタグに変更するとともに、前記イベント属性として記述されたクライアントサイドスクリプトを前記フォームの送信内容に埋め込む手段と、この変更後のマークアップ言語文書をクライアントへ送信する手段と、前記クライアントから前記フォームに対する選択結果情報とともに前記フォームの送信内容に埋め込まれたクライアントサイドスクリプトを受信する手段と、前記クライアントから受信した選択結果情報に基づいて前記クライアントサイドスクリプトを実行する手段と、前記クライアントサイドスクリプトの実行により前記コンテンツサーバへ所定の要求および前記選択結果情報を送信する手段とを備えたものである。

変換サーバは、クライアントから要求されたマークアップ言語文書にイベント属性付タグを含むフォームが含まれているかどうかをチェックし、そうであれば、イベント属性付タグを、送信ボタンを構成するインプットタグに変更する。これにより、どの送信ボタンが押下されたかの情報をサーバに送信することができるようになる。かつ、各イベント属性付タグに付随したクライアントサイドスクリプトをフォームの送信内容に埋め込むことにより、クライアントで実行すべき処理を変換サーバで代行して実行することができるようになる。

特に、前記イベント属性として記述されたクライアントサイドスクリプトを前記フォームの送信内容に埋め込む手段において、前記イベント属性付タグが複数存在する場合、前記フォームの送信内容において、各イベント属性付タグと当該クライアントサイドスクリプトとを対応づけておき、前記クライアントから前記クライアントサイドスクリプトを受信したとき、前記クライアントにおいていずれの送信ボタンが指示されたかに応じて、対応するクライアントサイドスクリプトを実行するようになすことができる。

また、前記イベント属性として記述されたクライアントサイドスクリプトを前記フォームの送信内容に埋め込む手段において、前記コンテンツサーバから次に取得するマークアップ言語文書として前記クライアントから要求されたマークアップ言語文書と同じ文書を指定する。これにより、変換サーバにおいて、クライアントでの当該マークアップ言語文書の状態を再現してクライアントの処理を不具合なく代行することができる。

前記コンテンツサーバから受信したコンテンツを一時的に保存する手段と、前記クライアントから要求されたマークアップ言語文書と同じ文書を要求する際、前記一時的に保存したコンテンツを利用する手段とをさらに備えてもよい。これにより、特定の状況でのウェブページ間の遷移を不具合なく実現することができる。

本発明のマークアップ言語文書変換方法は、クライアントから要求されたマークアップ言語文書をコンテンツサーバから受信するステップと、受信したマークアップ言語文書がユーザに情報の入力を促すフォームを含み、かつ、このフォームが、所定のイベントに応じてクライアントサイドスクリプトを起動するイベント属性付タグを含むか否かをチェックするステップと、前記イベント属性付タグを、送信ボタンを構成するインプットタグに変更するとともに、前記イベント属性として記述されたクライアントサイドスクリプトを前記フォームの送信内容に埋め込むステップと、この変更後のマークアップ言語文書をクライアントへ送信するステップと、前記クライアントから前記フォームに対する選択結果情報とともに前記フォームの送信内容に埋め込まれたクライアントサイドスクリプトを受信するステップと、前記クライアントから受信した選択結果情報に基づいて前記クライアントサイドスクリプトを実行するステップと、前記クライアントサイドスクリプトの実行により前記コンテンツサーバへ所定の要求および前記選択結果情報を送信するステップとを備えたものである。

本発明によるマークアップ言語文書変換装置は、他の見地によれば、クライアントから要求されたマークアップ言語文書をコンテンツサーバから受信する手段と、受信したマークアップ言語文書を一時的に保存する手段と、前記受信したマークアップ言語文書に所定の変換を施してクライアントへ送信する手段と、クライアントから、前記マークアップ言語文書に対するユーザの操作に応じてクライアントサイドスクリプトを起動する処理要求を受けたとき、前記一時保存されたマークアップ言語文書に対して当該要求された処理を実行する手段と、前記コンテンツサーバへ当該要求された処理の実行結果を送信する手段とを備えたものである。

本発明はまた、マークアップ言語文書変換方法をコンピュータに実行させるコンピュータプログラムとしてのマークアップ言語文書変換プログラムとして把握することも可能である。

本発明によれば、ＰＣ用ｗｅｂページをモバイル用ｗｅｂページに変換する際に、モバイル用端末などにおける制約に起因して正常なｗｅｂページ間の遷移ができなくなることを未然に防止することができる。

本発明の実施の形態におけるマークアップ言語文書変換システムの全体の概略の構成を示した図である。本発明における変換サーバの基本概念を説明するための図である。図２に示したブラウザエンジンの内部構成を示す図である。本発明の実施の形態における変換サーバの機能構成例を示す図である。出願人のホームページの概略画面を示した図である。図５に示したホームページの画面におけるブロック要素等の表示要素を示した図である。ＭＬ文書を構成する表示要素をツリー形式で模式的に示した図である。図６のＰＣ用ｗｅｂページがモバイル用に変換されてモバイル画面上に表示される様子を模式的に示した図である。ＰＣ用の第１のｗｅｂページから第２のｗｅｂページへ移行するｗｅｂページの遷移例を示した図である。図９に示した第１のｗｅｂページおよび第２のｗｅｂページにそれぞれ対応したＭＬ文書（ソースファイル）を表した図である。図９、図１０に関連したクライアントとコンテンツサーバとの間のやりとりを表したシーケンス図である。モバイル端末のクライアントとコンテンツサーバとの間に変換サーバが介在する場合のシーケンス図である。図１２における変換サーバによる変換結果画面を示した図である。図１３の変換結果画面に対応するＭＬ文書を示した図である。図１４におけるエラーを解消する方策を採用した場合のクライアント、変換サーバ、コンテンツサーバの間のシーケンス図である。図１５のシーケンス図における変換サーバによる変換結果ソースを示した図である。１つのフォーム内に送信ボタンが複数存在する場合のＰＣ用ブラウザでのｗｅｂページの画面遷移例を示した図である。図１７におけるｗｅｂページ４５０のＭＬ文書（2_1.php）を示した図である。図１７におけるｗｅｂページ４６０のＭＬ文書（2_2.php）とｗｅｂページ４７０のＭＬ文書（2_3.php）のそれぞれのＭＬ文書を示した図である。図１７のｗｅｂページの遷移に関連したクライアント（ＰＣ）とコンテンツサーバのやりとりを表したシーケンス図である。図１７のｗｅｂページに関するクライアントと変換サーバとコンテンツサーバの間のやりとりを表したシーケンス図である。図２１のシーケンス図における変換サーバによる変換結果画面を示した図である。図２２の画面の変換結果ソースを示した図である。本発明の実施の形態によるクライアント、変換サーバとコンテンツサーバの間のやりとりを表したシーケンス図である。図２４のシーケンス図における変換サーバによる変換結果画面を示した図である。図２５の画面の変換結果ソースを示した図である。図２６のＭＬ文書の中にあるfollowing_jsパラメータの説明図である。本発明の実施の形態における変換前ルールの一例を示した図である。図２４のシーケンス図に続く部分も含めたシーケンス図である。図２９で説明したような不具合を改良した場合のシーケンス図である。本発明の実施の形態における変換サーバの主要な処理のフローチャートである。

以下、本発明の好適な実施の形態について図面を参照しながら詳細に説明する。

図１は、本実施の形態におけるマークアップ言語文書変換システムの全体の概略の構成を示している。

このシステムは、携帯電話端末や通信機能付きＰＤＡなどの移動通信端末装置であるモバイル端末１１０と、ｗｅｂコンテンツを提供するｗｅｂサーバ１２０（コンテンツサーバとも呼ぶ。ＰＣ用、モバイル用を問わない。）と、ＰＣ用ｗｅｂコンテンツを提供するＰＣ用ｗｅｂサーバ１３０と、本願発明のマークアップ言語文書変換装置に相当する変換サーバ１５０と、各サーバが接続されるインターネットのような通信ネットワーク１４０とにより構成される。

変換サーバ１５０は、ＰＣ用ｗｅｂページを構成するＰＣ用マークアップ言語（ＭＬ）文書（すなわち第１のマークアップ言語文書）を、リアルタイムに、モバイル用ｗｅｂページを構成するモバイル用ＭＬ文書（すなわち第２のマークアップ言語文書）に変換するためのサーバであり、トランスコーダともいう。通信ネットワーク１４０には、モバイル用パケット通信網とこれをインターネットに接続するゲートウェイ（図示せず）を含みうる。ｗｅｂサーバ１２０はインターネットではなくモバイル用パケット通信網に接続されたサーバであってもよい。

モバイル端末１１０のユーザの操作に従い、モバイル端末１１０のｗｅｂブラウザはｗｅｂサーバ１２０に対して特定のｗｅｂページを要求（リクエスト）する（１）。このリクエストにはモバイル端末のｗｅｂブラウザからユーザエージェント（ＵＡ）と呼ばれる情報が含めて送信される。

ｗｅｂサーバ１２０は、受け取ったユーザエージェント情報に基づいて当該モバイル端末の機種ＩＤを判別でき、これによりその機種の仕様情報を確認することができる。この仕様情報には、例えば、表示画面サイズや利用可能なメモリサイズ、一度に処理できるｗｅｂデータ量、サポートフォーマットなどが含まれる。このようなリクエストに対する応答（レスポンス）として、ｗｅｂサーバ１２０からモバイル端末１１０に対してリダイレクト（変換サーバ１５０のＵＲＬを含む）が返送される（２）。リダイレクトとは、ｗｅｂページを要求してきた端末がモバイル端末であることをそのユーザエージェント情報に基づいてｗｅｂサーバ１２０が認識したとき、アクセス先を自身から他の特定のサイト（ここでは変換サーバ１５０）へ移動させるためのレスポンスである。

モバイル端末１１０は、このリダイレクト情報を受けて、変換サーバ１５０へアクセスし、目的のＰＣ用ｗｅｂページをリクエストする（３）。すなわち、このリクエストにはＰＣ用ｗｅｂサーバ１３０のＵＲＬも含んでいる。

なお、リダイレクトによらず、モバイル端末１１０がモバイル用ｗｅｂページ内に組み込まれた変換サーバ１５０のＵＲＬから、または、ＵＲＬの手動入力に基づいて、変換サーバ１５０へ直接アクセスしてもよい。

変換サーバ１５０は、このようなリクエストを受けると、指定されたＰＣ用ｗｅｂサーバ１３０にアクセスして当該モバイル端末用に変換すべきＰＣ用マークアップ言語文書で記述されたＰＣ用ｗｅｂページをリクエストする（４）。さらに、ＰＣ用ｗｅｂサーバ１３０からそのレスポンスとして当該ＰＣ用ｗｅｂページのＭＬ文書を取得する（５）。変換サーバ１５０は、取得したＰＣ用ＭＬ文書ならびに必要に応じて取得されるそのＰＣ用ＭＬ文書に付随するデータおよびプログラムをレンダリングして、その結果に基づいてモバイル用ＭＬ文書を自動的に生成し、レスポンスとしてモバイル端末１１０へ返送する（６）。モバイル端末１１０は返送されたモバイル用ＭＬ文書を受信し、ｗｅｂブラウザにより処理し、必要な付随するデータおよびプログラムをさらに取得して、レンダリングを行い、その結果をモバイル用表示画面に表示する。「付随するデータおよびプログラム」とは、例えば、ＣＳＳなどのＭＬ文書から参照される修飾情報、画像（広告画像も含む）、JavaScript（登録商標）などのスクリプト、Ｆｌａｓｈなどのプラグイン用のデータ、等を含む。レンダリングとは、一般に数値データとして与えられた物体や図形に関する情報をデータ処理によって画像化することであり、本明細書では、ＨＴＭＬなどのマークアップ言語文書をｗｅｂブラウザが読み込んで種々のタグを解釈し、各種の表示要素を表示画面上のどこにどのように表示するかを確定し、表示用の描画データを生成することをいう。レンダリングにはＣＳＳの解析、JavaScriptなどの実行等も含む。

変換サーバ１５０は、好ましくは、リクエストを受けた端末の「一度に処理できるｗｅｂデータ量」に基づいて、これに対応する単位量毎に、モバイル用ＭＬ文書のデータを区切ることにより、ページ分割を行う。ページ分割の方法としては、任意の既存の手法を用いることができる。例えば、モバイル用ＭＬ文書内の各ページの最後に、次のページの内容にリンクした「次のページ」等の名称のアンカータグを設定する。なお、モバイル端末から変換サーバ１５０へのリクエストにもユーザエージェントが含まれており、変換サーバ１５０は、受け取ったユーザエージェント情報に基づいて当該モバイル端末の機種ＩＤを判別でき、これによりその機種の仕様情報を確認することができる。そのために、変換サーバ１５０は、図示しないが、機種ＩＤと機種の仕様情報との対応データを保持している。

図２は、本発明における変換サーバ１５０の基本概念を説明するための図である。変換サーバ１５０は、従来のｗｅｂブラウザのブラウザエンジンと同等の機能を有するブラウザエンジン２０と、変換処理部１６１と、前処理部１７０とを含む。ブラウザエンジン２０は、ＨＴＭＬファイルのようなＰＣ用ＭＬ文書１０を読み込んで、レンダリングを行う。その前処理として、前処理部１７０が本発明に係る処理を実行する。その具体的な処理内容については後に詳述する。ブラウザエンジン２０の処理結果として得られる、予め想定されている標準的な規定のサイズ（例えば縦６００画素×横８００画素）のＰＣ表示画面上に配置される表示要素としての各パーツおよびその親子関係の情報である描画ドキュメントツリーや、そのパーツの占有領域（ブロック）の配置座標情報は変換処理部１６１へ伝えられる。変換処理部１６１は、パーツの親子関係や配置座標情報に基づいて、パーツの配置をモバイル端末での表示に適したモバイル用ＭＬ文書（例えばｃＨＴＭＬ文書）を生成する。

図３は、図２に示したブラウザエンジン２０の内部構成を示す。ブラウザエンジン２０は、パーサ２１、ページメーカ２３、およびフォーマッタ２５の各機能を有する。パーサ２１は、表示対象のマークアップ言語（ＭＬ）文書１０の論理的な構造を解釈し、その構造に関するドキュメントツリー２２を生成する。ページメーカ２３は、ドキュメントツリー２２を基に、各タグで決められた表現形式（block, inline, table, list, itemなど）の情報を含むレイアウトツリー２４を生成する。このレイアウトツリー２４は、block, inline, tableなどがどのような順番に存在しているかを表している。但し、レイアウトツリー２４は、まだ、これらの要素が画面のどこにどのような幅と高さで表示されるか、文字列がどこで折り返されるか、等のレイアウトに関する情報までは含んでいない。フォーマッタ２５は、レイアウトツリー２４を基に、既知の表示画面幅などの実際の表示画面に関する情報を用いてレイアウトを行う。すなわち、レイアウトツリー２４を実際の表示画面に配置していき、文字の折り返しや、画面上の位置、幅、高さを決定する。この段階で、描画ドキュメントツリー（レンダリングツリーともいう）２６が生成される。本実施の形態では、描画ドキュメントツリー２６には各パーツのブロックの対角座標を含めている。

図４に、本実施の形態における変換サーバ１５０の機能構成例を示す。

トランスコーダエンジン１６０は、変換サーバ１５０の中枢部であり、ブラウザエンジン２０と変換処理部１６１とを含む。ブラウザエンジン２０の構成及び機能については上述したとおりである。変換処理部１６１は、ブラウザエンジン２０の処理結果を用いてＰＣ用ＭＬ文書をモバイル用ＭＬ文書に変換する処理を行う部位である。この具体的な処理手順については後述する。

コンテンツデータキャッシュ管理部１５８は、変換前のｗｅｂページのデータ（ＭＬ文書、JavaScript、ＣＳＳ、Ｃｏｏｋｉｅ、画像等）を一時的に保存するための装置である。

コンテンツ取得情報キャッシュ管理部１５７は、キャッシュのメタ情報として、各データの有効期限、対応ＵＲＬなどの情報を一時的に保存するための装置である。

セッション管理部１５２は、ｗｅｂサイトにアクセスした時にセッションを管理するための装置である。ユーザが継続的にそのサイトを使えるように，そのユーザの状態をページに埋め込むことがｗｅｂの世界ではしばしばある。埋め込む場所はＵＲＬクエリ内やＣｏｏｋｉｅ内である。このような動作はセッションと呼ばれる。

トランスコーダフロントエンド１６２は、ＨＴＭＬ埋め込み型のサーバサイドスクリプト言語を用いてＣＧＩ（Common Gateway Interface：コモン・ゲートウェイ・インタフェース）のような機能を実現するサーバサイドスクリプト処理部である。ＣＧＩとは、ｗｅｂサーバ上でユーザプログラムを動作させるための仕組みであり、そのユーザプログラムがサーバサイドスクリプトである。トランスコーダフロントエンド１６２は、端末においてユーザが何かをクリックしたり、ユーザに情報の入力を促すフォームフォームで何かを送信したときに、それに基づいてプログラムを実行し、新たなＭＬの記述を生成してブラウザに対して送信する。スクリプト言語としては本実施の形態ではＰＨＰ(PHP: Hypertext Preprocessor)を使用しているが、これに限るものではない。

前処理部１７０は、トランスコーダフロントエンド１６２およびトランスコーダエンジン１６０と接続され、後述するような本願発明に係る処理を実行する。

変換結果キャッシュ管理部１５６は、変換処理部１６１での変換結果であるモバイル用ＭＬ文書を一時的に保存する装置である。

ｈｔｔｐｄ(Hyper Text Transfer Protocol Daemon)１５４はｈｔｔｐデーモンと呼ばれるｗｅｂサーバのプログラムであり、ユーザからの要求に応じてサーバ内に蓄積されたコンテンツを送信したり、サーバサイドスクリプトを起動したりするためのものである。

なお、変換サーバ１５０のハードウェア構成は特に示さないが、ＣＰＵ、主記憶装置、外部記憶装置、通信装置、各種入出力装置、等、既存のハードウェア構成により実現される。

以下、本実施の形態における変換サーバ１５０の動作を、具体的なｗｅｂページ例を示して説明する。

図５は出願人のホームページの概略画面を示している。

ＭＬ文書は各種のタグを含むテキストで記述されており、ｗｅｂページを構成する表示要素は主として「ブロック要素」と「インライン要素」に分類される。

ブロック要素は、文書の骨組みとなる要素で、例えば見出しや段落などである。このタイプの要素は与えられた領域の横幅一杯の領域を持ち、要素の前後には自動的に改行が入る。ブラウザの画面上で、ブロック要素の占有する領域は、文字列や画像等のある部分だけではなく、それらを含む矩形の(ブロック状の)領域である。具体的には、見出し(h1〜h6)、(意味)段落(p)、章/意味段落(div)、区切り線(hr)、引用(blockquote)、テーブル(table)等がブロック要素である。リスト(ul/ol/dl)及びその項目(li/dt/dd)もブロック要素である。

インライン要素は、文章中の一部として扱われる要素(例えばリンクや文字の強調など)である。このタイプの要素は行の一部として扱われるので、要素の前後には改行は入らない。具体的には、リンク/アンカー(a)、語・文節・文単位の強調(em/strong)、プログラムの出力結果(samp)、プログラムのソースコード(code)、引用元の明示(cite)、強制改行(br)等がインライン要素である。画像(img)もインライン要素に含まれる。

ブロック要素の中には、別のブロック要素やインライン要素が入り得る。インライン要素の中には、別のインライン要素が入りうる。インライン要素の中には、ブロック要素は入らない。

多くのタグは開始タグ＜＞と終了タグ＜／＞から構成される。開始タグと終了タグの間の他のタグが含まれる、すなわち入れ子状態となりうる。入れ子関係にあるタグのうち外側のタグが「親」、内側がタグが「子」となる。

上述したように、ブラウザエンジン２０はＭＬ文書を読み込んで、解釈し、レンダリングを行う。その結果として、図６に示すように、ブロック要素等の表示要素（すなわちパーツ）毎にその表示位置（配置座標）およびサイズ（矩形占有領域の対角座標）が求められる。図７にその様子をツリー形式で模式的に示す。この図における「ブロック」は図６に示した各表示要素のブロックに対応している。各ブロックには、（Ｘ１，Ｙ１，Ｘ２，Ｙ２）の形式の対角座標が定められている。（Ｘ１，Ｙ１）は矩形状のブロックの左上角の座標であり、（Ｘ２，Ｙ２）はブロックの右下角の座標である。

図７の描画ドキュメントツリーは、ＣＳＳを解釈した後の結果に基づくものである。ＭＬ文書中にJavaScriptが含まれ、それにより表示要素が決定される場合には、その実行結果をも反映したものである。

変換処理部１６１は、パーツの親子関係や座標情報に基づいて、パーツの配置をモバイル端末での表示に適して組み替える。この組み替えに際して、モバイル端末の表示画面では水平方向のスクロールは行わなくて済むようなｗｅｂページ構成が望ましい。そこで、複数のパーツを画面の横方向（水平方向）に羅列すると、モバイル端末の表示画面からはみ出してしまうような場合には、複数のパーツの横並びを縦並びに変更する。例えば、図６の上部のブロック２１１、ブロック２２１〜２２９、ブロック２３１〜２３７は、図８の位置３００に示すように縦並びに配置を変更する。図８は図６のＰＣ用ｗｅｂページがモバイル用に変換されてモバイル画面上に表示される様子を模式的に示した図である。実際には、図８の内容の全体がモバイル画面内に収まるわけではなく、縦方向にはページ送りおよび／またはスクロール操作により隠れた部分をモバイル画面上に移動させて見ることができる。横方向についてはページの幅全体がモバイル画面に収まることを想定している。

一つの画像（イメージ）の横幅がモバイル表示画面サイズより大きいものについては、その横幅がモバイル表示画面サイズに収まるように、全体の画像サイズを縮小するよう最適化する。図６の画像２４１（画像Ａ）は最適化された画像２４１’（画像Ａ’）として、図８の位置３００の直下の位置３４０に配置されている。

図６のブロック２５１〜２５６は元々縦並びで、すべてモバイル表示画面サイズに収まるため、図８の位置３４０の直下の位置３５０に配置している。

図６の画像のブロック２５７は、その横幅がモバイル表示画面サイズに収まるので、図８の位置３５０の直下の位置３５５に配置している。

図６のブロック２６１〜２６５についても、同様に、図８の位置３５５の直下の位置３６０に配置している。

図６のブロック２７１〜２７２については、同様に、図８の位置３６０の直下の位置（図示省略）に配置する。

図６の画像のブロック２８１についてはその横幅がモバイル表示画面サイズに収まるので、図８のブロック２７２の直下の位置に配置する。なお、画像の配置位置はその親のブロック要素の座標により決まる。画像を縮小または拡大する場合にはその画像サイズを参照する。

図６のブロック２９１についてはブロック２８１の直下の位置に配置する。このブロック２９１は縦横比が大きいので後述する「折り畳み」を行うことができるが、折り畳んでも情報量が変わらないので、ここでは折り畳まないものとしている。モバイル表示画面の横幅より文字列が長い場合は、ブラウザの機能により折り返して表示される。

図６のブロック２９２〜２９５については、全体としてモバイル表示画面サイズに収まるので、ブロック２９１の直下の位置に配置する。但し、ブロック２９２〜２９５を縦並びに配置替えしてもよい。

複数のパーツをモバイル表示画面用に上から順に配置していく際に、ＰＣ用画面上でのパーツをどのような順でピックアップしていくかについては、予め定めた規則に従う。上述した例では、ＰＣ画面上の複数のパーツは、最上部の左から右に順次選択していき、右端に達したらその下に移動して、左から右に順次選択していく。

ただし、複数の小パーツが、モバイル画面の横幅に収まる一つの大ブロックに含まれる場合にはそれらの小パーツを一体として扱う。（図６のブロック２５２〜２５６等）同じ横幅サイズで、縦並びに並んでいる複数のパーツはそれらの上から下まで選択したあと、右へ移動する。（ブロック２５１、（２５２〜２５６）、２５７等）

なお、このような規則はあくまで例示であり、本発明はこれに限定されるものではない。

ところで、ＰＣ用ｗｅｂページにおいていわゆるナビゲーションと呼ばれるような横長の記述部（図６のブロック２３１〜２３７）は図８から判るように、初期状態でモバイル画面で縦に並べるとモバイル画面の大半を占有して煩わしく感じられる場合がある。

そこで、図８の最上部に示すように、モバイル画面上に[Close this section]という指示部を設けて、そのマイナスマーク２１０ａをモバイル端末のユーザが指示すると、縦並びになっている複数の要素の一群をまとめて１つの要素に代表させる仕組みを設ける。この仕組みを「折り畳み」と呼ぶ。一つの要素であっても、大サイズの場合により小さい要素で代替表示することも可能である。このような処理も折り畳みに含まれる。

このようなシステムを用いれば、自動的に、ＰＣ用ｗｅｂページを比較的忠実にモバイル用ｗｅｂページに変換し、ＰＣ用コンテンツをモバイル端末等で閲覧可能とすることができる。

しかも、そのためにコンテンツプロバイダ（通常、企業）ではＰＣ用ｗｅｂページ毎にそれに対応するモバイル用のｗｅｂページを別途用意しておく必要がなくなる。その結果、ＰＣ用コンテンツとモバイル用コンテンツの双方を作成し、かつ双方を同様にメンテナンス（同期）しなければならない、という煩雑な処理負担から当該コンテンツプロバイダを開放することができる。

ところで、このシステムは業務用アプリケーションなどの特定の用途において改善すべき点がある。以下、そのような課題について説明した後、その解決法について説明する。

図９は、ＰＣ用の第１のｗｅｂページ４１０から第２のｗｅｂページ４２０へ移行するｗｅｂページの遷移例を示している。第１のｗｅｂページ４１０のＭＬ文書のファイル名を1_1.phpとし、第２のｗｅｂページ４２０のＭＬ文書のファイル名を1_2.phpとしている。拡張子ｐｈｐはＰＨＰスクリプトを含むＨＴＭＬファイルを表している。第１のｗｅｂページ４１０は、チェックボックス４１３，４１４のようなユーザに情報の選択を促す入力要素（inpuタグ：インプットタグ）と、その選択結果情報をｗｅｂサーバへ送信するための送信(submit)ボタン（ＯＫボタン）４１１とを含むフォームを有する。第２のｗｅｂページ４２０は、第１のｗｅｂページ４１０でのユーザの選択結果をユーザに知らしめるページを表している。

図１０は、図９に示した第１のｗｅｂページ４１０および第２のｗｅｂページ４２０にそれぞれ対応したＭＬ文書（ソースファイル）５１０，５２０を表している。

ＭＬ文書５１０内のスクリプト記述部分５１１はクライアントサイドスクリプトの一例としてのJavaScriptを示している。この例では、_doClick(v)という関数を定めている。関数内の各部の意味は次のとおりである。なお、本明細書において、「クライアントサイドスクリプト」とは、コンテンツサーバでは実行されず、クライアントまたは変換サーバで実行されるスクリプトをいう。

var form = document._Memo; // 変数formに、_Memoという名前のオブジェクトを代入
form._Click.value = v; // formオジェクトが保持しているinputタグの中の_Clickという名前のオブジェクトのvalue属性に、引数vを上書き
form.submit(); // formオブジェクトのsubmit関数を呼びだして、formをJavaScriptから実行する
return false; // 通常submit()がうまく動作すればここには到達しないが、失敗した場合にfalseを返す

ＭＬ文書５１０の本文内のフォームを定義するフォーム記述部分５１３内には、formタグ５１４、hiddenタイプのinputタグ５１５およびsubmitタイプのinputタグ５１６、checkboxタイプのinputタグ５１７，５１８を含んでいる。

formタグ５１４は、methodとしてＰＯＳＴを指定し、actionとして所定のサーバサイドスクリプトを指定し、nameとして_MEMOを指定し、onsubmit属性として_doClick('1_2')というクライアントスクリプトを指定している。

hiddenタイプのinputタグ５１５では、ユーザには見せないがサーバに送信すべき入力情報としての_Clickという名前のオブジェクトのvalue属性の値０を初期値として設定している。submitタイプのinputタグ５１６はＯＫというラベルの送信ボタンを設定している。checkboxタイプのinputタグ５１７，５１８はユーザに情報（選択肢）の選択を促す選択手段を構成している。

上記ＯＫボタンの押下に応じて、送信直前にonsubmit属性内で関数_doClickが呼び出され、次の画面ＩＤ（すなわち文書ＩＤ、ここでは1_2)が_Clickに設定され、フォームに関連した各種の入力データの送信が行われる。

ＭＬ文書（1_2.php）５２０は、サーバサイドスクリプト部分５２１を含んでいる。このサーバサイドスクリプト部分５２１では、_doClick関数で_Clickに適切な画面ＩＤが設定されていれば、入力（選択）情報を出力し、そうでなければ、再度の選択の指示を出力するよう規定されている。

図１１は、図９、図１０に関連したクライアントとコンテンツサーバとの間のやりとりを表したシーケンス図である。

クライアントは、コンテンツサーバに対してｈｔｔｐプロトコルに則ったＧＥＴメソッドのリクエストにより、チェックボックス付フォームを含むＭＬ文書である1_1.phpを要求し（Ｓ１１）、その文書の返送を受ける（Ｓ２１）。次いでクライアントは、ユーザによるチェックボックスのチェックおよびＯＫボタンの押下の操作を受け付ける（Ｓ１２）。この受け付け後に、フォームのonsubmit属性で関数_doClick(1_2)を実行する（Ｓ１３）。その結果、_Clickに1_2を設定し（Ｓ１４）、チェックボックスの選択結果を含めてsubmit関数を実行する（Ｓ１５）。その結果、クライアントはコンテンツサーバに対して、ＰＯＳＴメソッドにより、次に要求する文書ＩＤ（1_2.php）、_Clickの設定値、選択結果をコンテンツサーバへ送信する（Ｓ１６）。図の例ではチェックボックスの一つ「太郎」が選択された場合を示している。コンテンツサーバは、その受信内容に応じて、次の画面の文書を返送する（Ｓ２２）。

図１２は、クライアントがモバイル端末であり、このクライアントとコンテンツサーバとの間に上記変換サーバが介在する場合の相互のやりとりを表したシーケンス図を示している。変換対象のＭＬ文書は、図９に示したｗｅｂページ４１０のＭＬ文書としている。

クライアントは、変換サーバ経由でコンテンツサーバに1_1.phpのＭＬ文書を要求する（Ｓ１０１，Ｓ１１１）。コンテンツサーバは当該文書を変換サーバに返送する（Ｓ１２１）。変換サーバはこの文書をモバイル用に変換してクライアントへ送信する（Ｓ１１２）。その変換結果画面４３０を図１３に示す。この画面には、図９に示したｗｅｂページ４１０の画面と同様、送信ボタン４３１と、チェックボックス４３３，４３４がフォームとして含まれている。なお、簡単な画面例なので図面上明確ではないが、この画面はＰＣ用ｗｅｂページをモバイル用のｗｅｂページに変換したものである。

クライアントは、ユーザによるチェック操作およびＯＫボタンの押下の操作を受け付けて（Ｓ１０２）、チェックボックス内容を含んだＰＯＳＴを行う（Ｓ１０３）。すなわち、記述q.phpにより、サーバに対して所定のコンテンツの変換（ＰＣ用ＭＬ文書からモバイル用ＭＬ文書への変換）を行うとともに、必要であればスクリプトの実行を要求する。変換の対象となるコンテンツはｕｒｌ=で指定し、スクリプト実行はfollowing_js=で指定する。Ｓ１０３ではfollowing_js= は指定していない。また、選択結果（checkKojin=太郎）も変換サーバへ送信する。変換サーバは、これに応じて、コンテンツサーバへ1_2.phpを要求し、選択結果（「太郎」）を知らせる（Ｓ１１３）。このとき、_Clickが設定されていないので、コンテンツサーバはエラーと判定する（Ｓ１２２）。その結果、コンテンツサーバは変換サーバ経由で、クライアントに対して「個人を選択してください。」という再度の選択の指示を返送する（Ｓ１２３，Ｓ１１４）。

図１４は図１３の変換結果画面４３０に対応するＭＬ文書５３０を示している。図１０の文書５１０と比較して分かるように、図１４のＭＬ文書５３０ではクライアントサイドスクリプト５１１が変換サーバにて削除されている。これに伴ってフォームのonsubmit属性も削除されている。これはモバイル端末のブラウザでの制約でそのようなスクリプトの実行機能がないことに基づいている。ＰＯＳＴ先のactionURLは1_2.phpとしている。その結果、変換サーバ、ひいてはコンテンツサーバ側で、上記のような_doClick関数で求めた_Clickの値が得られず、チェックボックスの選択結果も確認ができない。そのため、上記のようにエラーと判定される。

この問題を解決するため、送信ボタンのonsubmit属性で実行すべきJavaScriptの内容（図１０の文書５１０内のformタグ５１４の記述を参照）を送信ボタンの送信内容としてフォームのＰＯＳＴの記述内に埋め込むことにより、_doClick関数を変換サーバに実行させる方策が考えられる。

図１５にそのような方策を採用した場合のクライアント、変換サーバ、コンテンツサーバの間のシーケンス図を示す。

クライアントは、変換サーバ経由でコンテンツサーバにＭＬ文書1_1.phpを要求する（Ｓ２０１，Ｓ２１１）。コンテンツサーバは当該文書を変換サーバに返送する（Ｓ２２１）。変換サーバはこの文書をモバイル用に変換してクライアントへ送信する（Ｓ２１２）。その変換結果画面は図１３に示した画面４３０と同じである。但し、その変換結果ソースは図１６に示すようなＭＬ文書５４０となる。すなわち、form action５４１およびｕｒｌに続けて、実行すべきスクリプトとしてfollowing_js=の後に、変換サーバで実行すべき関数_doClick ('1_2')を指定している。

図１５に戻り、クライアントは、ユーザによるチェック操作およびＯＫボタンの押下の操作を受け付けて（Ｓ２０２）、チェックボックス内容を含んだＰＯＳＴを行う。すなわち、サーバに対して変換対象のｕｒｌ(1_1.php）の変換を要求するとともに選択結果（「太郎」）に加えて、上記following_js=_doClick('1_2')を変換サーバへ送信する（Ｓ２０３）。

変換サーバは、このＰＯＳＴ内容を受信し、指定されたＵＲＬの文書、すなわち先に要求されたと同じ文書1_1.phpを要求して入手する（Ｓ２１３，Ｓ２２２）。このＭＬ文書は、変換サーバにてクライアントで実行すべきであった処理を代替的に実行するために必要となるからである。

そこで、変換サーバは、ＰＯＳＴ内容をＦＯＲＭに適用する（Ｓ２１４）。すなわち、フォーム内の全てのinputタグについてそのタイプ毎にＰＯＳＴの内容を反映させる。

次いで、変換サーバはfollowing_jsパラメータのJavaScriptを実行する（Ｓ２１５）。図１５の例では関数_doClick ('1_2')を実行し、_Clickに'1_2'を設定する（Ｓ２１６）。また、チェックボックス内容を含んだsubmit関数を実行する（Ｓ２１７）。

その後、変換サーバは、次に要求する文書ＩＤ（ここでは1_2.php）、_Clickの設定値（ここでは’1_2’）および選択結果（ここでは「太郎」）をコンテンツサーバへ送信する（Ｓ２１８）。

コンテンツサーバでは、＿Clickが設定されているので、ＯＫと判定し（Ｓ２２３）、要求された文書1_2.phpを変換サーバへ返送する（Ｓ２２４）。

このようにフォームのＰＯＳＴ内容に含められるクライアントサイドスクリプトとして、変換サーバで実行すべき関数を指定することにより、上記のようなチェックボックスの選択結果の確認ができないという問題は解決される。

しかし、特定の状況においてなお問題が生じることが判明した。すなわち、そのような場合として、１つのフォーム内に送信ボタンが複数存在する場合を考慮する。図１７はそのような場合の例として、まず、ＰＣ用ブラウザでのｗｅｂページの画面遷移例を示す。

一般に１つのフォーム内に複数の送信ボタンを設ける場合、onsubmit属性を送信ボタン毎に用意できず、またクライアントで押下された送信ボタンの区別ができないため、送信ボタン毎に別の処理を実行することができないという問題がある。そこで、所定のイベントに応じてクライアントサイドスクリプトを起動するイベント属性付のアンカータグとして、例えばonclick属性付のアンカータグを用いることにより、送信ボタンと同様の機能を実現する手法が考えられる。onclick属性とは、ＭＬ文書内のアンカータグ等の要素に対してマウスなどのポインティングデバイスのいわゆるクリック操作を行った等の所定のイベントの発生時に起動するスクリプト（クライアントサイドスクリプト）を指定するイベント属性（イベントハンドラ）である。複数のアンカータグの各々にスクリプトの異なるonclick属性を付加しておくことにより、別々の処理を行うonsubmit属性の複数の送信ボタンと同等の機能が実現できる。

図１７はそのようなonclick属性付のアンカータグを用いた具体的なｗｅｂページの遷移例を示している。ＰＣ用のｗｅｂページ４５０を構成するＭＬ文書（2_1.php）では、フォーム内に、アンカータグに対応するアンカーポイント４５１，４５２を用いて、キャンセルボタンとＯＫボタンが構成されている。このキャンセルボタンは、単に端末においてformの入力内容をサーバに問い合わせることなくクリアするためのものではなく、サーバに問い合わせてから画面を一つ戻すことを想定している。また、この例において階層の上位の選択肢を提示するチェックボックス４５４，４５５も設けられている。ＰＣ用のＭＬ文書（2_2.php）のｗｅｂページ４６０は、ｗｅｂページ４５０から移行するｗｅｂページである。このｗｅｂページ上には、ｗｅｂページ４５０上のアンカーポイント４５１，４５２と同様のアンカーポイント４６１，４６２と、下位の選択肢を提示する他のチェックボックス４５４，４５５が設けられている。続くＭＬ文書（2_3.php）４７０は、上位と下位の選択肢の選択結果をユーザが確認するための画面である。

図１８は、ｗｅｂページ４５０のＭＬ文書（2_1.php）５５０を示している。

スクリプト記述部５５１はクライアントサイドスクリプトの一例としてのJavaScriptであり、図１０のＭＬ文書（ソースファイル）５１０内のスクリプト記述部分５１１と同様の関数を定義した部分である。フォームタグ部分５５２はフォームのmethodおよびactionを定めた部分である。inputタグ５５３は、type="hidden"で_Clickというオブジェクトの初期値を定めた部分である。tableタグ５５５４はアンカータグとしてのボタン名を配列するテーブルデータを定めた部分である。onclik属性付のアンカータグ部分５５５，５５６はテーブルデータに含まれる形で、それぞれ、「キャンセル」と「ＯＫ」という文字列がクリック対象文字列として割り当てられている。inputタグ５５８，５５９は、この例で上位の選択肢を提示するチェックボックスを構成している。

図１９は、ｗｅｂページ４６０のＭＬ文書（2_2.php）とｗｅｂページ４７０のＭＬ文書（2_3.php）のそれぞれのＭＬ文書５６０，５７０を示している。

図１９のＭＬ文書５６０の要素５６１〜５６６、５６８，５６９は図１８のＭＬ文書５５０の要素５５１〜５５６、５５８，５５９と同様である。異なる点は、ＭＬ文書５６０が、追加的に要素５６７を有する点である。この要素５６７は、_Clickに'2_2'が設定されているとき、checkJyouiというオブジェクトにＰＯＳＴされてきたcheckJyouiの値を設定するものである。ここではhiddenタイプのinputタグを用いている。

図１９のｗｅｂページ４７０のＭＬ文書（2_3.php）は、ユーザにより選択された上位と下位の選択肢に応じて、その結果を出力するためのものである。具体的には、_Clickに'2_3'が設定され、かつ、checkJyouiとcheckKaiにそれぞれ値が設定されている場合、図１７のＭＬ文書４７０のようなメッセージを出力するものである。

図２０は、図１７のｗｅｂページ４５０，４６０，４７０の遷移に関連したクライアント（ＰＣ）とコンテンツサーバのやりとりを表したシーケンス図である。

クライアントは、コンテンツサーバに対して、チェックボックス付フォームを含むＭＬ文書である2_1.phpの要求（Ｓ３１）を要求し、その文書の返送を受ける（Ｓ５１）。次いでクライアントは、ユーザによる上位の選択肢についてのチェックボックスのチェックおよびＯＫボタンの押下の操作を受け付ける（Ｓ３２）。この受け付け後に、onclick属性による_doClick(2_2)を実行する（Ｓ３３）。この_doClick関数の実行の結果、_Clickに2_2を設定し（Ｓ３４）、チェックボックス内容を含んだsubmit関数を実行する（Ｓ３５）。その結果、クライアントはコンテンツサーバに対して、ＰＯＳＴメソッドにより、次に要求する文書ＩＤ（2_2.php）、_Clickの設定値（2_2）、および選択結果（checkJyoui＝東京支店）をコンテンツサーバへ送信する（Ｓ３６）。図の例では「東京支店」が選択された場合を示している。コンテンツサーバは、その受信内容に応じて、次の画面の文書2_2.phpを返送する（Ｓ５２）。その際、図１９に示した要素５６７の働きにより、checkJyouiに「東京支店」が設定された状況で返送される。

クライアントは、さらに、ユーザによる下位の選択肢についてのチェックボックスのチェックおよびＯＫボタンの押下の操作を受け付ける（Ｓ３７）。この受け付け後に、onclick属性による_doClick(2_3)を実行する（Ｓ３８）。この_doClick関数の実行の結果、_Clickに2_3を設定し（Ｓ３９）、チェックボックス内容を含んだsubmit関数を実行する（Ｓ４０）。その結果、クライアントはコンテンツサーバに対して、ＰＯＳＴメソッドにより、次に要求する文書ＩＤ（2_3.php）、_Clickの設定値（2_3）、および選択結果（前回の選択結果checkJyoui＝東京支店、および今回の選択結果checkKai=千代田区総合支社）をコンテンツサーバへ送信する（Ｓ４１）。図の例では「千代田区総合支社」が選択された場合を示している。コンテンツサーバは、その受信内容に応じて、次のｗｅｂページ４７０の文書2_3.phpを返送する（Ｓ５３）。

次に図１７に示したＰＣ用のｗｅｂページ４５０，４６０，４７０を、変換サーバを介してモバイル用ＭＬ文書に変換する場合について、説明する。図２１は、その際のクライアントと変換サーバとコンテンツサーバの間のやりとりを表したシーケンス図である。

クライアントは、変換サーバ経由でコンテンツサーバに対して、ＭＬ文書2_1.php（図１８のＭＬ文書５５０）を要求する（Ｓ３０１，Ｓ３１１）。コンテンツサーバは当該文書を変換サーバに返送する（Ｓ３２１）。変換サーバはこの文書をモバイル用に変換してクライアントへ送信する（Ｓ３１２）。その変換結果画面は図２２に示した画面４８０である。この画面では、アンカータグによるキャンセルボタン４８１およびアンカータグによるＯＫボタン４８２、およびチェックボックス４８４，４８５が含まれている。

図２２の画面４８０の変換結果ソースは図２３に示すようなＭＬ文書５８０となる。すなわち、form action５８１として、変換対象のURL2_2.phpの変換を要求し、メソッドをPOSTとしている。

hiddenタイプのinputタグ５８２で_Clickの初期値を設定している。

また、キャンセルボタンのアンカータグ要素５８３として、ｕｒｌ2_1.phpの変換を要求するとともに、following_js=の後に、変換サーバで実行すべき関数_doClick('2_1')を指定している。同様に、ＯＫボタンのアンカータグ要素５８４として、ｕｒｌ2_1.phpの変換を要求するとともに、following_js=の後に、変換サーバで実行すべき関数_doClick('2_2')を指定している。

チェックボックスタイプのinputタグ５８５，５８６はそれぞれ上位および下位の選択肢を提示している。

図２１に戻り、クライアントは、ユーザによるチェック操作およびＯＫボタンの押下の操作を受け付けて（Ｓ３０２）、FORMの内容は関係なく、onclick属性の関数を実行する（Ｓ３０３）。すなわち、サーバに対してｕｒｌ(2_1.php）の変換を要求すると共に、following_jsパラメータを変換サーバへ送信する（Ｓ３０４）。

変換サーバは、この内容を受信し、指定されたＵＲＬの文書、すなわち先に要求されたと同じ文書2_1.phpを要求して入手する（Ｓ３１３，Ｓ３２２）。これは、変換サーバにてクライアントで実行すべきであった処理を代替的に実行するために必要となるからである。

そこで、変換サーバは、fillowing_jsパラメータのJavaScriptを実行する（Ｓ３１４）。ついで、doClick関数で、_Clickに'2_2'を設定する（Ｓ３１５）。また、チェックボックス内容が欠落したまま、submit関数を実行する（Ｓ３１６）。

その後、変換サーバは、次に要求する文書ＩＤ（ここでは2_2.php）、_Clickの設定値（2_2)をコンテンツサーバへ送信する（Ｓ３１７）。しかし、選択結果が通知されないので、コンテンツサーバはＮＧと判定する（Ｓ３２３）。

チェックボックス内容が欠落するのは、doClick関数をモバイルブラウザが実行できないということ、加えて、ＯＫボタンが押下されて送信（submit）ボタンでformの内容を送るのではなく、アンカータグに付随したオンクリック属性に基づく送信なのでフォーム入力内容が送信されないことが理由である。

図２４は、本発明の実施の形態によるクライアント、変換サーバとコンテンツサーバの間のやりとりを表したシーケンス図である。

クライアントは、変換サーバ経由でコンテンツサーバに対して、ＭＬ文書2_1.php（図１８のＭＬ文書５５０）を要求する（Ｓ４０１，Ｓ４１１）。コンテンツサーバは当該文書を変換サーバに返送する（Ｓ４２１）。ここで、変換サーバはこの文書をそのままモバイル用に変換してクライアントへ送信するのではなく、変換前に予め定めた所定のルール（「変換前ルール」と呼ぶ）を適用する（Ｓ４１２）。その後、図示しないが、変換サーバは上述したようなモバイル用ＭＬ文書への変換処理を実行する。このような処理後のＭＬ文書をクライアントへ送信する（Ｓ４１３）。その変換結果画面は、図２５に示したモバイル端末上の変換結果画面４９０である。この画面でのキャンセルボタン４９１およびＯＫボタン４９２は、アンカータグによるものではなく、inputタグによる送信(submit)ボタンとしてのinput要素である。この画面には上記と同様のチェックボックス４９４，４９５も含まれている。

図２５の画面４９０の変換結果ソースは図２６に示すようなＭＬ文書５９０となる。すなわち、form action５９１として、URL（2_1.php）の変換を要求している。また、following_js=の後に付加するfollowing_jsパラメータ５９２として、前記変換前ルールにより、元のページのonclick属性に基づいて送信ボタンとJavaScriptとの対応関係を示す対応テーブルを作成し、onsubmit属性のJavaScript内に埋め込んでいる。

inputタグ５９３は、hiddenタイプのinput要素であり、_Clickの初期値を設定している。inputタグ５９４は、submitタイプのinput要素であり、name="dummy"、id="onclick1"として「キャンセル」という送信ボタンを定めている。inputタグ５９５は、submitタイプのinput要素であり、name="dummy"、id="onclick2"として「ＯＫ」という送信ボタンを定めている。id="onclick1"等のid属性は、form内容に応じて、変換前ルールでonclick属性の内容をonsubmit内容の対応テーブルに移す（すなわち、id属性をキーとして、onclick属性の中身を値として、対応テーブルに追加する）際のキーとして用いる。

input要素５９８はcheckboxタイプのinput要素であり、checkJyouiというnameの選択肢として「東京支店」を提示している。同様に、input要素５９９はcheckboxタイプのinput要素であり、checkJyouiというnameの選択肢として「システム保守」を提示している。

図２７はＭＬ文書５９０の中にあるfollowing_jsパラメータ５９２の説明図である。following_jsパラメータ５９２の表記は複数のJavaScriptが一連に連結されてＵＲＬエンコードされたものである。ＵＲＬエンコードとは、URIにASCIIの非予約文字以外の文字データを用いる場合に"%xx"(xxは１６進数）という形式でコードを表記することをいう。この表記では、直ちに理解できないので、読みやすくした形で示したのが図２７の下部のJavaScript文書５９２ａである。その記述部分５９２１が上記対応テーブルを表している。この例では、上記ｉｄのonclick1と、onclick2とがそれぞれ関数_doClick(\'2_1\')と関数_doClick(\'2_2\')に対応することを示している。記述部分５９２３では、上記対応テーブルのいずれかのエントリ（項目）が上記マーク内容と一致したとき、evalで当該関数を実行することを規定している。

図２４に戻り、クライアントは、ユーザによるチェック操作およびＯＫボタンの押下の操作を受け付けて（Ｓ４０２）、変換サーバへのＰＯＳＴを実行する。すなわち、サーバに対してｕｒｌ(2_1.php）の変換を要求するとともに、following_jsパラメータ５９２および選択結果（checkJyoui=東京支店）を変換サーバへ送信する（Ｓ４０３）。

変換サーバは、この内容を受信し、指定されたＵＲＬの文書、すなわち先に要求されたと同じ文書2_1.phpを要求して入手する（Ｓ４１４，Ｓ４２２）。上述のように、これは、変換サーバにてクライアントで実行すべきであった処理を代替的に実行するために必要となるからである。

そこで、変換サーバは、再度、変換前のルールを適用する（Ｓ４１５）。これは、ステップＳ４１２で変換前ルールを適用した直後の状態のＭＬ文書(2_1.php）を得るためである。本来クライアントで実行されるべき処理を変換サーバで代替的に実行するために、クライアントにおいて得たＭＬ文書を再現するためである。

そこで、変換サーバは、ＰＯＳＴ内容をＦＯＲＭに反映させて、どの送信ボタンが押下されたかについてもマークを行う（Ｓ４１６）。すなわち、フォーム内の全てのinput要素についてそのタイプ毎にＰＯＳＴの内容を反映させる。

次いで、変換サーバは上記following_jsパラメータで記述されたonsubmit属性を実行することにより、上記マークされた送信ボタンに対応した関数を実行する（Ｓ４１７）。その結果、次の所定のＭＬ文書の指定(2_2.php)、_Clickの設定値(2_2)、およびチェック内容（checkJyoui=東京支店）をコンテンツサーバへ送信する（Ｓ４１８）。

上記ステップＳ４１６におけるPOSTの内容をFORMに反映させるという処理では、クライアントから変換サーバにPOSTされた内容を使って、以下のようなJavaScriptを変換サーバ内で自動生成し、最初の変換前ルールを適用した結果の状態の変換サーバ上のFORMにPOST内容を反映させる。

/* ここから自動生成(1) */
var target_form=document.forms._Memo; /* 対象FORM */
var hash={'__Click': [],'dummy': [],'checkJyoui': [],}; /* POST内容反映配列 */
hash['__Click'].push('0'); /* __Clickの反映 */
hash['dummy'].push('OK'); /* dummyの反映 */
hash['checkJyoui'].push('%E6%9D%B1%E4%BA%AC%E6%94%AF%E5%BA%97'); /* checkJyouiの反映 */
/* ここまで自動生成(1) */
/* ここから定型(1) */
var elems = target_form.elements;
/* form内の全てのinput要素について */
for (var i=0; hash && i＜elems.length; i++) {
/* 一度checkboxのチェックをクリア */
if ('checkbox' == elems.item(i).type) {
elems.item(i).checked = false;
}
/* 反映したいinputがformに存在するかチェック */
var new_values = hash[elems.item(i).name];
if (undefined == new_values) {
continue;
}
if (0 == new_values.length) {
continue;
}
var new_value = new_values[0];
if (undefined == new_value) {
continue;
}
/* 反映したいinputをtypeごとに処理分け */
switch (elems.item(i).type) {
case 'select-one': /* 単一select */
{
var options = elems.item(i).options;
/* select内の全てのinputについて、一致する最初のものをselectedに */
for (var j=0; j＜options.length; j++) {
var old_value = options[j].getAttribute('value');
if (null == old_value) {
old_value = options[j].firstChild.nodeValue.replace(/^[ ]+|[ ]+$/g, '');
}
if (new_value == old_value) {
elems.item(i).selectedIndex = j;
new_values.shift();
break;
}
}
}
break;
case 'select-multiple': /* 複数select */
{
var options = elems.item(i).options;
var survived_values = [];
for (var j=0; j＜options.length; j++) {
options[j].selected = false;
}
/* select内の全てのinputについて、一致する全てのものをselectedに */
for (var j in new_values) {
var k=0;
for (; k＜options.length; k++) {
var old_value = options[k].getAttribute('value');
if (null == old_value) {
old_value = options[k].firstChild.nodeValue.replace(/^[ ]+|[ ]+$/g, '');
}
if (!options[k].selected && new_values[j] == old_value) {
options[k].selected = true;
break;
}
}
if (options.length == k) {
survived_values.push(new_values[j]);
}
}
hash[elems.item(i).name] = survived_values;
}
break;
case 'radio': /* ラジオボタン */
if (new_value == elems.item(i).value) {
elems.item(i).click(); /* クリック */
new_values.shift();
}
break;
case 'checkbox': /* チェックボックス */
if (new_value == elems.item(i).value) {
elems.item(i).checked = true; /* チェック */
new_values.shift();
}
break;
case 'text': /* テキスト */
case 'textarea': /* テキストエリア */
case 'password': /* パスワード */
case 'hidden': /* 隠し属性 */
elems.item(i).value=new_value;
new_values.shift();
break;
case 'submit': /* サブミット */
if (new_value == elems.item(i).value) {
/* nft属性でマーキング */
attr = elems.item(i).getAttribute('nft');
if (null == attr) {
attr = '';
}
attr += 'click:1;';
elems.item(i).setAttribute('nft', attr);
new_values.shift();
}
break;
case 'image': /* 画像 */
case 'button': /* ボタン */
case 'reset': /* リセット */
/* 反映不要*/
new_values.shift();
break;
default:
break;
}
}
/* ここまで定型(1) */
/* ここからページごと自動生成(2) */
var ok = (＜onsubmit属性の実行＞);
/* ここまでページごと自動生成(2) */
if (false != ok) {
target_form.submit(); /* submitを実行し、変換サーバからコンテンツサーバに送信 */
}

図２８は上記変換前ルールの一例としてのスクリプトを変換前ルール６００として示したものである。

最初の関数は、次の作用を有する。
* - 指定ノード子孫のonclickの内容をテーブル化する
* - onclick2onsubmitから呼出され、内部で再帰呼び出しして引数ノードの全ての子孫について実行する
また、その引数は次の作用を有する。
* - in_elem はDOMノードで、in_elemの全子孫を辿って、onclickの内容を、in_mapに格納。
* - in_map は(onclick＜count＞, onclickの内容)のハッシュテーブル。
* - count は、現在何番目のonclickかを示すIDのためのカウント。

各行についてコメントを示すと以下のとおりである。
function _onclick2onsubmit(in_elem, in_map, count) {
var child = in_elem.firstChild; /* in_elemの最初の子ノード */
while (child) { /* 子ノードがある限り */
var input = null;
var sibling = child.nextSibling;
if ('A' == child.nodeName) { /* aタグの場合 */
var onclick = child.getAttribute('onclick'); /* onclick属性の中身のスクリプト *
if (onclick) { /* onclick属性がある場合 */
count++; /* テーブルのエントリ番号のインクリメント */
var id = 'onclick'+count; /* id属性の自動付与 */
input = document.createElement('input'); /* inputタグの新規作成 */
input.setAttribute('type', 'submit'); /* type属性はsubmit */
input.setAttribute('name', 'dummy'); /* name属性はdummy */
input.setAttribute('value', child.innerText); /* value属性はもとのaタグの内部のテキスト */
input.setAttribute('id', id); /* id属性はonclick＜エントリー番号＞ */
onclick = onclick.replace(/^return /g, ''); /* スクリプトの不要な文字の削除 */
in_map[id] = onclick.replace(/\'/g, '\\\''); /* スクリプトのクォートのエスケープ後、テーブルにonclick＜エントリー番号＞で追加 */
}
}
count = _onclick2onsubmit(child, in_map, count); /* 再帰呼出 */
if (input) {
child.parentNode.replaceChild(input, child); /* aタグを新規作成したinputタグで置換 */
}
child = sibling; /* 次の子ノード */
}
return count; /* エントリ番号を返す */
}

次の関数は、次の作用を有する。
* - 指定form子孫のonclickの内容をテーブル化したスクリプトを作成し、onsubmit属性に埋め込む

その引数は次の作用を有する。
* - frmは指定フォームのDOMオブジェクト
* - hookはonsubmit属性に埋め込む際に先頭に追加するスクリプト
各行にコメントを付加すれば次のとおりである。

次に図２９に、図２４のシーケンス図に続く部分も含めたシーケンス図を示す。図２４に示したように、フォームを含むｗｅｂページが単独で用いられる場合には特に問題は生じないが、フォームを含む複数のｗｅｂページが有機的に連続する場合に生じる不具合について説明する。

ステップＳ４０１〜Ｓ４０３、Ｓ４１１〜Ｓ４１８、Ｓ４２１〜Ｓ４２２は、図２４に示した同ステップと同じであり、説明を省略する。

コンテンツサーバは、変換サーバからＰＯＳＴを受けると（Ｓ４１８）、ＭＬ文書2_2.phpに対してcheckJyouiの選択結果を埋め込んだものを変換サーバへ送信する（Ｓ４２３）。これは図１９のＭＬ文書５６２内の要素５６７の働きによる。

これに対して変換サーバは、変換前ルールを適用する（Ｓ４１９）。その後、図示しないが、変換サーバは上述したようなモバイル用ＭＬ文書への変換処理を実行する。このような処理後のＭＬ文書をクライアントへ送信する（Ｓ４３０）。

クライアントは、ＭＬ文書2_2.phpの画面に対するユーザによるチェック操作およびＯＫボタンの押下の操作を受け付けて（Ｓ４０４）、変換サーバへのＰＯＳＴを実行する。すなわち、サーバに対してｕｒｌ(2_2.php）の変換を要求するとともに、following_jsパラメータ５９２および選択結果（checkJyoui=東京支店＆checkKai=千代田区総合支社）を変換サーバへ送信する（Ｓ４０５）。checkJyouiは今回の画面での入力ではなく、ステップＳ４２３での設定値が残存しているものである。

変換サーバは、この内容を受信し、指定されたＵＲＬの文書、すなわち先に要求されたと同じ文書2_2.phpを要求して入手する（Ｓ４３１，Ｓ４２５）。

そこで、変換サーバは、再度、変換前のルールを適用する（Ｓ４３２）。これは、ステップＳ４１９で変換前ルールを適用した直後の状態のＭＬ文書(2_2.php）を得るためである。

そこで、変換サーバは、ＰＯＳＴ内容をＦＯＲＭに反映させて、どの送信ボタンが押下されたかについてもマークを行う（Ｓ４３３）。すなわち、フォーム内の全てのinput要素についてそのタイプ毎にＰＯＳＴの内容を反映させる。

次いで、変換サーバは、フォームのＰＯＳＴ（送信）内容として埋め込まれているonsubmit属性（アンカータグのｏｎｃｌｉｃｋ属性として記述されたJavaScript（クライアントサイドスクリプト）をフォーム内に集約したもの）を実行することにより、上記マークされた送信ボタンに対応した関数を実行する（Ｓ４３４）。その結果、次の所定のＭＬ文書の指定(2_3.php)、_Clickの設定値(2_3)、およびチェック内容（checkKai=千代田区総合支社）をコンテンツサーバへ送信する（Ｓ４１８）。これを受けたコンテンツサーバは選択結果としてcheckJyouiの設定値が欠落しているために、ＮＧと判定する（Ｓ４２６)。これによりＭＬ文書2_3.phpで「上位組織と下位組織を選択してください。」という画面をクライアントに表示させる（Ｓ４２７，Ｓ４３６）。

ステップＳ４２６で選択結果情報としてcheckJyouiの設定値が欠落していたのは、ステップＳ４０５で変換サーバがクライアントから上位と下位の選択結果を受信しておきながら、ステップＳ４３１においてコンテンツサーバにＭＬ文書2_2.phpをＧＥＴリクエストで再要求したため、コンテンツサーバにcheckJyouiの設定値が伝わらず、コンテンツサーバからcheckJyouiに設定値を埋め込んでないＭＬ文書が返送されたためである。

図３０にこのような不具合を改良した場合のシーケンス図を示す。図２９に示したと同様のステップには同じ参照符号を付して重複した説明は省略する。図３０では図２９のステップＳ４１４，Ｓ４２２を削除し、その代わりに変換サーバの処理としてステップＳ４１３の後にステップＳ４１３ａを追加している。また、変換サーバはコンテンツサーバから一旦受信したＭＬ文書をオフラインキャッシュとして変換サーバ内部（図４のコンテンツデータキャッシュ管理部１５８）に保存しておく。このステップＳ４１３ａではオフラインキャッシュからＭＬ文書2_1.phpを再読み込みする。また、ステップＳ４３１，Ｓ４２５を削除し、変換サーバの処理としてステップＳ４３０の後にステップＳ４３０ａを追加する。このステップＳ４３０ａではオフラインキャッシュから選択結果（checkHyoui）の入ったＭＬ文書2_2.phpを再読み込みする。その結果、ステップＳ４２６では「ＯＫ」と判定し、続くステップＳ４２７ではクライアントへ確認画面2_3.phpで「上位組織は〜です、下位組織は〜です。」というメッセージを返す（Ｓ４２７，Ｓ４３６）。なお、ステップＳ４１３ａの段階ではキャッシュからの読み出しでなくても問題は生じないが、Ｓ４１３ａとＳ４３０ａで共通の処理とすることにより複雑な例外処理を不要とすることができる。

図３１に、本実施の形態における変換サーバの主要な処理のフローチャートを示す。

クライアントからＭＬ文書の要求を受領し（Ｓ８１）、これに応じてコンテンツサーバに当該ＭＬ文書を要求し、受領する（Ｓ８２）。このＭＬ文書がフォームを含み、フォーム内にonclick属性（イベント属性）付のアンカータグを有するかどうかをチェックする（Ｓ８３)。onclick属性付のアンカータグを有しない場合は、図示の後続の処理を省略する。onclick属性付のアンカータグを有する場合、そのＭＬ文書に対して変換前ルールを適用する（Ｓ８４）。これにより、当該アンカータグをsubmit属性付のinputボタン（送信ボタン）に変更する（Ｓ８４)。さらにこのＭＬ文書をモバイル用ＭＬ文書に変換し（Ｓ８５）、クライアントへ送信する（Ｓ８６）。

クライアントからフォームに対する入力結果の返信を受信したとき（Ｓ８７）、変換サーバはコンテンツサーバから直前に入手されている同ＭＬ文書をオフラインキャッシュから再入手する（Ｓ８８）。さらにこのＭＬ文書に対して上記と同様に変換前ルールを適用する（Ｓ８９）。この適用後のＭＬ文書に対してＰＯＳＴ内容を反映させ、押下された送信（submit）ボタンが何であるかをマークし、送信ボタンのＰＯＳＴの記述内に埋め込まれているonsubmit属性を実行することにより、当該マークされた送信ボタンに対応した関数を上記対応テーブルから確認して、当該関数を実行する（Ｓ９０）。その結果をコンテンツサーバへ送信する（Ｓ９１）。

なお、本発明によるマークアップ言語文書変換装置は、他の見地によれば、次のような構成をとることもできる。すなわち、クライアントから要求されたマークアップ言語文書をコンテンツサーバから受信し、受信したマークアップ言語文書を一時的に保存し、前記受信したマークアップ言語文書に所定の変換を施してクライアントへ送信する。クライアントから、前記マークアップ言語文書に対するユーザの操作に応じてクライアントサイドスクリプトを起動する処理要求を受けたとき、前記一時保存されたマークアップ言語文書に対して当該要求された処理を実行し、前記コンテンツサーバへ当該要求された処理の実行結果を送信する。

タグのonsubmit属性やonclick属性などのイベント属性を用いて第１の画面から第２の画面に遷移する場合、変換サーバはコンテンツサーバから受信した第１の画面のPC用ML文書をモバイル用ML文書に一旦変換し、その後、ユーザアクションに応じて再度第１の画面のML文書を読み込んで当該属性中のクライアントサイドサーバを実行して、第２の画面へ遷移する。そのような場合、第１の画面のML文書を２回読み込んだ後、第２の画面へ移行することになる。その場合に、上述のように、２回目の第１の画面のML文書を再度コンテンツサーバに再度要求した受信したのでは、ML文書の内容が所期の状態になっていないため、画面遷移がうまくいかない場合がある。例えば２回目の第１の画面のPC用ML文書が一意なURLで特定できず取得できない場合がある。その一例としては第１の画面のPC用ML文書のURLが同じであっても、クライアントからPOSTするデータによってそのML文書の画面が変わる場合が挙げられる。

この構成では変換サーバにおける位弁護属性に基づく画面遷移の際に、同じML文書を２度読みする際に２度目は一時保存してあるML文書を利用することにより、図３０で上述したような選択情報等が埋め込まれた状態のML文書を有効に残して利用することができ、その結果として、コンテンツサーバとクライアントとの間に変換サーバが介在しても所期の画面遷移を達成することが可能となる。

以上、本発明の好適な実施の形態について説明したが、上記で言及した以外にも種々の変形、変更を行うことが可能である。

また、ユーザに選択肢を提示フォームのinput要素としてチェックボックスのみを示したが、本発明が適用可能なinput要素は「チェックボックス」に限定されるものではなく、ラジオボタンのような他の選択ボタンも含みうる。また、本発明は選択メニュー等の他のinput要素にも適用可能である。

上記の説明では、変換サーバでの変換対象としてイベント属性付のアンカータグを例として挙げたが、本発明が適用されるタグはアンカータグに限るものではなく、イベント属性が付与されうる任意のタグを含みうる。

変換サーバは１台としたが、複数台設けて、負荷を分散するようにしてもよい。

本発明のマークアップ言語文書変換装置は、通信ネットワーク上の変換サーバとして説明したが、通信ネットワークに接続されない単体の装置であってもよい。あるいは、ホームサーバ（ホームゲートウェイ）に搭載され、ホームネットワークでつながれた他の家電機器などに、本発明のマークアップ言語文書変換の機能を適用することも可能である。

ｗｅｂブラウザ上で動作するクライアントサイドスクリプトの一例としてJavaScriptを挙げたが、ＥＣＭＡＳｃｒｉｐｔ等の他のスクリプトにも本発明は適用可能である。

本発明はＰＣ用ＭＬ文書をモバイル用ＭＬ文書に変換することを前提として説明したが、受信端末において上記のような制約がある場合等には必ずしもモバイル用ＭＬ文書に変換することは必須ではない。

上記実施の形態で説明した機能をコンピュータで実現するためのコンピュータプログラムおよびプログラムをコンピュータ読み取り可能に格納した記録媒体も本願発明に含まれる。

２０…ブラウザエンジン、１１０…モバイル端末、１２０…ｗｅｂサーバ、１３０…ＰＣ用ｗｅｂサーバ、１４０…通信ネットワーク、１５０…変換サーバ、１５２…セッション管理部、１５６…変換結果キャッシュ管理部、１５７…コンテンツ取得情報キャッシュ管理部、１５８…コンテンツデータキャッシュ管理部、１６０…トランスコーダエンジン、１６１…変換処理部、１６２…トランスコーダフロントエンド、１７０…前処理部、２４１…画像、４１０…ｗｅｂページ、４１３，４１４…チェックボックス、４２０…ｗｅｂページ、４３０…変換結果画面、４３１…送信ボタン、４３３，４３４…チェックボックス、４５０，４６０，４７０…ｗｅｂページ、４５１，４５２…アンカーポイント、４５４，４５５…チェックボックス、４６１，４６２…アンカーポイント、４８１…キャンセルボタン、４８２…ＯＫボタン、４８４，４８５…チェックボックス、４９０…変換結果画面、４９１…キャンセルボタン、４９２…ＯＫボタン、４９４，４９５…チェックボックス、５１０，５２０，５３０，５４０，５５０…ＭＬ文書、５１１…スクリプト記述部分、５１３…フォーム記述部分、５１４…ｆｏｒｍタグ、５１５〜５１８…inputタグ、５２１…サーバサイドスクリプト部分、５５１…スクリプト記述部、５５２…フォームタグ部分、５５３…inputタグ、５５５，５５６…アンカータグ部分、５５８，５５９…inputタグ、５６０…ML文書、５６０，５７０…ＭＬ文書、５６６…要素、５８０…ＭＬ文書、５８２…input要素、５８３，５８４…アンカータグ要素、５９０…ＭＬ文書、５９２…パラメータ、５９２ａ…ＭＬ文書、６００…変換前ルール

Claims

クライアントから要求されたマークアップ言語文書をコンテンツサーバから受信する手段と、
受信したマークアップ言語文書がユーザに情報の入力を促すフォームを含み、かつ、このフォームが、所定のイベントに応じてクライアントサイドスクリプトを起動するイベント属性付タグを含むか否かをチェックする手段と、
前記イベント属性付タグを、送信ボタンを構成するインプットタグに変更するとともに、前記イベント属性として記述されたクライアントサイドスクリプトを前記フォームの送信内容に埋め込む手段と、
この変更後のマークアップ言語文書をクライアントへ送信する手段と、
前記クライアントから前記フォームに対する選択結果情報とともに前記フォームの送信内容に埋め込まれたクライアントサイドスクリプトを受信する手段と、
前記クライアントから受信した選択結果情報に基づいて前記クライアントサイドスクリプトを実行する手段と、
前記クライアントサイドスクリプトの実行により前記コンテンツサーバへ所定の要求および前記選択結果情報を送信する手段と
を備えたマークアップ言語文書変換装置。
前記イベント属性として記述されたクライアントサイドスクリプトを前記フォームの送信内容に埋め込む手段において、前記イベント属性付タグが複数存在する場合、前記フォームの送信内容において、各イベント属性付タグと当該クライアントサイドスクリプトとを対応づけておき、前記クライアントから前記クライアントサイドスクリプトを受信したとき、前記クライアントにおいていずれの送信ボタンが指示されたかに応じて、対応するクライアントサイドスクリプトを実行する請求項１に記載のマークアップ言語文書変換装置。
前記イベント属性として記述されたクライアントサイドスクリプトを前記フォームの送信内容に埋め込む手段において、前記コンテンツサーバから次に取得するマークアップ言語文書として前記クライアントから要求されたマークアップ言語文書と同じ文書を指定する請求項１または２に記載のマークアップ言語文書変換装置。
前記コンテンツサーバから受信したコンテンツを一時的に保存する手段と、前記クライアントから要求されたマークアップ言語文書と同じ文書を要求する際、前記一時的に保存したコンテンツを利用する手段とをさらに備えた請求項３に記載のマークアップ言語文書変換装置。
クライアントから要求されたマークアップ言語文書をコンテンツサーバから受信するステップと、
受信したマークアップ言語文書がユーザに情報の入力を促すフォームを含み、かつ、このフォームが、所定のイベントに応じてクライアントサイドスクリプトを起動するイベント属性付タグを含むか否かをチェックするステップと、
前記イベント属性付タグを、送信ボタンを構成するインプットタグに変更するとともに、前記イベント属性として記述されたクライアントサイドスクリプトを前記フォームの送信内容に埋め込むステップと、
この変更後のマークアップ言語文書をクライアントへ送信するステップと、
前記クライアントから前記フォームに対する選択結果情報とともに前記フォームの送信内容に埋め込まれたクライアントサイドスクリプトを受信するステップと、
前記クライアントから受信した選択結果情報に基づいて前記クライアントサイドスクリプトを実行するステップと、
前記クライアントサイドスクリプトの実行により前記コンテンツサーバへ所定の要求および前記選択結果情報を送信するステップと
を備えたマークアップ言語文書変換方法。
前記イベント属性として記述されたクライアントサイドスクリプトを前記フォームの送信内容に埋め込むステップにおいて、前記イベント属性付タグが複数存在する場合、前記フォームの送信内容において、各イベント属性付タグと当該クライアントサイドスクリプトとを対応づけておき、前記クライアントから前記クライアントサイドスクリプトを受信したとき、前記クライアントにおいていずれの送信ボタンが指示されたかに応じて、対応するクライアントサイドスクリプトを実行する請求項５に記載のマークアップ言語文書変換方法。
前記イベント属性として記述されたクライアントサイドスクリプトを前記フォームの送信内容に埋め込むステップにおいて、前記コンテンツサーバから次に取得するマークアップ言語文書として前記クライアントから要求されたマークアップ言語文書と同じ文書を指定する請求項５または６に記載のマークアップ言語文書変換方法。
前記コンテンツサーバから受信したコンテンツを一時的に保存するステップと、前記クライアントから要求されたマークアップ言語文書と同じ文書を要求する際、前記一時的に保存したコンテンツを利用するステップとを更に備えた請求項７に記載のマークアップ言語文書変換方法。
クライアントから要求されたマークアップ言語文書をコンテンツサーバから受信するステップと、
受信したマークアップ言語文書がユーザに情報の入力を促すフォームを含み、かつ、このフォームが、所定のイベントに応じてクライアントサイドスクリプトを起動するイベント属性付タグを含むか否かをチェックするステップと、
前記イベント属性付タグを、送信ボタンを構成するインプットタグに変更するとともに、前記イベント属性として記述されたクライアントサイドスクリプトを前記フォームの送信内容に埋め込むステップと、
この変更後のマークアップ言語文書をクライアントへ送信するステップと、
前記クライアントから前記フォームに対する選択結果情報とともに前記フォームの送信内容に埋め込まれたクライアントサイドスクリプトを受信するステップと、
前記クライアントから受信した選択結果情報に基づいて前記クライアントサイドスクリプトを実行するステップと、
前記クライアントサイドスクリプトの実行により前記コンテンツサーバへ所定の要求および前記選択結果情報を送信するステップと
をコンピュータに実行させるマークアップ言語文書変換プログラム。
クライアントから要求されたマークアップ言語文書をコンテンツサーバから受信する手段と、
受信したマークアップ言語文書を一時的に保存する手段と、
前記受信したマークアップ言語文書に所定の変換を施してクライアントへ送信する手段と、
クライアントから、前記マークアップ言語文書に対するユーザの操作に応じてクライアントサイドスクリプトを起動する処理要求を受けたとき、前記一時保存されたマークアップ言語文書に対して当該要求された処理を実行する手段と、
前記コンテンツサーバへ当該要求された処理の実行結果および所定の要求を送信する手段と
を備えたマークアップ言語文書変換装置。
クライアントから要求されたマークアップ言語文書をコンテンツサーバから受信するステップと、
受信したマークアップ言語文書を一時的に保存するステップと、
前記受信したマークアップ言語文書に所定の変換を施してクライアントへ送信するステップと、
クライアントから、前記マークアップ言語文書に対するユーザの操作に応じてクライアントサイドスクリプトを起動する処理要求を受けたとき、前記一時保存されたマークアップ言語文書に対して当該要求された処理を実行するステップと、
前記コンテンツサーバへ当該要求された処理の実行結果および所定の要求を送信するステップと
を備えたマークアップ言語文書変換方法。
クライアントから要求されたマークアップ言語文書をコンテンツサーバから受信するステップと、
受信したマークアップ言語文書を一時的に保存するステップと、
前記受信したマークアップ言語文書に所定の変換を施してクライアントへ送信するステップと、
クライアントから、前記マークアップ言語文書に対するユーザの操作に応じてクライアントサイドスクリプトを起動する処理要求を受けたとき、前記一時保存されたマークアップ言語文書に対して当該要求された処理を実行するステップと、
前記コンテンツサーバへ当該要求された処理の実行結果および所定の要求を送信するステップと
をコンピュータに実行させるマークアップ言語文書変換プログラム。