JP2004220203A - 情報通信端末装置及び情報通信システム - Google Patents
情報通信端末装置及び情報通信システム Download PDFInfo
- Publication number
- JP2004220203A JP2004220203A JP2003005064A JP2003005064A JP2004220203A JP 2004220203 A JP2004220203 A JP 2004220203A JP 2003005064 A JP2003005064 A JP 2003005064A JP 2003005064 A JP2003005064 A JP 2003005064A JP 2004220203 A JP2004220203 A JP 2004220203A
- Authority
- JP
- Japan
- Prior art keywords
- file
- data file
- format
- data
- file format
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Telephone Function (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
【課題】ファイル形式を正確に判定する。
【解決手段】ファイル形式判定部１ａは、ファイル保持部４２に保持されたデータファイル中のシグネチャに応じてファイル形式を判定する。ファイル処理部１ｂは、ファイル形式判定部１ａによって判定されたファイル形式に応じてファイル保持部４２に保持されているデータファイルを再生する。利用制限部２ａは、ファイル形式判定部１ａの判定結果及びデータファイルの拡張子に応じて当該データファイルの利用を制限する。
【選択図】 図１
【解決手段】ファイル形式判定部１ａは、ファイル保持部４２に保持されたデータファイル中のシグネチャに応じてファイル形式を判定する。ファイル処理部１ｂは、ファイル形式判定部１ａによって判定されたファイル形式に応じてファイル保持部４２に保持されているデータファイルを再生する。利用制限部２ａは、ファイル形式判定部１ａの判定結果及びデータファイルの拡張子に応じて当該データファイルの利用を制限する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、ファイル形式を正確に判定できる情報通信端末装置及び情報通信システムに関する。
【０００２】
【従来の技術】
ＨＴＴＰサーバからの応答（レスポンス）メッセージには、例えば図３に示すように、ＨＴＴＰヘッダが含まれており、このＨＴＴＰヘッダには、データ本体のファイル形式を示すコンテントタイプ（Ｃｏｎｔｅｎｔ ｔｙｐｅ）が含まれている。ＨＴＴＰサービスを利用するＷｅｂブラウザ等のクライアントアプリケーションは、このコンテントタイプによって、データ本体のファイル形式を判定することができるようになっている（例えば非特許文献１参照。）。
【０００３】
ところで、近年、ＨＴＴＰサービスを利用できる携帯電話端末装置が普及しているが、移動体通信網における通信速度がインターネット等の固定通信網に比較して遅いため、ＨＴＴＰヘッダ，タグ等による、レスポンスデータのサイズの増加が無視できないものとなる。また、ＭＰＵの性能上の制約からＨＴＴＰをそのまま実装することが困難である場合もあった。
【０００４】
このため、ＨＴＴＰプロトコルをそのまま実装するのではなく、ＨＴＴＰヘッダを省略し、さらに、ページ記述言語としてタグを短縮系で表現したＭＭＬ等のＨＴＭＬのサブセット仕様の言語が用いられている（例えば特許文献１参照。）。
【０００５】
このような携帯電話端末装置で通常のＨＴＴＰサーバによって提供されているサービスを利用する場合には、プロトコルとタグの変換を行うゲートウェイ装置が用いられている。
【０００６】
しかし、このような実装の携帯電話端末装置では、ＨＴＴＰヘッダが省略されているために上述のコンテントタイプが含まれておらず、コンテントタイプによってファイル形式を判定することができない（例えば特許文献２参照。）。このため、携帯電話端末装置側からＵＲＬを指定して要求（リクエスト）メッセージを送信する際等に、ＵＲＬ中のファイル名の拡張子によってファイル形式を判定していた。
【０００７】
【非特許文献１】
Ｊｏｎ Ｐｏｓｔｅｌ、「ＲＦＣ−２０６８」、［ｏｎｌｉｎｅ］、１９９７年１月１日、［平成１４年１１月１１日検索］、インターネット＜ＵＲＬ：ＨＴＴＰ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２０６８．ｔｘｔ＞、ｐ．２４〜２６
【特許文献１】
特開２０００−１５２３２７号（第６−９頁、第６図）
【特許文献２】
特開２００１−１９７５５３号（第６−７頁、第６図）
【０００８】
【発明が解決しようとする課題】
しかしながら、ＣＧＩ等を用いた動的なコンテンツ（例えば携帯電話端末装置側からの情報に応じた画像等）を利用する場合には、ＵＲＬ中にファイルの拡張子が含まれていない場合があり、このような場合には拡張子によってファイル形式を判定することができない。
【０００９】
最近のＭＰＵの性能の向上、移動体通信網における通信速度の向上等により、携帯電話端末装置にＨＴＴＰを実装することもできるようになりつつあるが、ＨＴＴＰを実装した場合でもコンテントタイプがワイルドカード（Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｏｃｔｅｔ−ｓｔｒｅａｍ等）である場合には、コンテントタイプのみでデータ本体のファイル形式を判定することはできない。
【００１０】
本発明は、上述のような課題に鑑みてなされたものであり、ファイル形式を正確に判定することができる情報通信端末装置及び情報通信システムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
上述の問題を解決するために、本発明に係る情報通信端末装置は、ファイル形式毎に固有の情報（シグネチャ）を含むデータファイルを移動体通信網を介して取得する取得手段と、取得手段が取得したデータファイル中のシグネチャに応じて当該データファイルのファイル形式を判定する判定手段とを備えることを特徴とする。この情報通信端末装置では、判定手段が、取得手段が取得したデータファイル中のシグネチャに応じて当該データファイルのファイル形式を判定することができる。
【００１２】
また、本発明に係る情報通信システムは、移動体通信網を介して、情報提供サーバ装置から情報通信端末装置にファイル形式毎に固有の情報（シグネチャ）を含むデータファイルを提供する情報通信システムであって、情報通信端末装置が、提供されたデータファイル中のシグネチャに応じて当該データファイルのファイル形式を判定する判定手段を備えることを特徴とする。
【００１３】
【発明の実施の形態】
本発明は、例えば携帯電話端末装置等の情報利用端末装置に、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）サービス等を移動体通信網を介して提供する情報通信システム等に適用することができる。
【００１４】
（構成）
この情報通信システムは、例えば図１に示すように、ページ記述データ等のデータファイルを提供するＨＴＴＰサーバ装置１０及びＰＵＳＨサーバ装置５０と、インターネット等のネットワーク２０側と移動体通信網３０側との間のプロトコル変換を行うゲートウェイ装置２５と、移動体通信網３０を介してサーバ装置１０と通信を行う携帯電話端末装置（情報通信端末装置）４０とを備えている。
【００１５】
ＨＴＴＰサーバ装置１０は、例えばＨＴＭＬ等のデータを提供するＨＴＴＰサーバ１１と、ＨＴＴＰサーバ１１が提供し得るファイル（データ）を保持するデータ保持部１２とを備えている。データ保持部１２には、文字情報，音楽等の音声情報，静止画・動画等の画像情報等がファイルとして格納されている。ＨＴＴＰサーバ１１は、携帯電話端末装置４０等のネットワーク２０経由で接続されている端末装置からの要求されたファイルをデータ保持部１２から読み出して送信する。
【００１６】
また、ＨＴＴＰサーバ１１は、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）処理部１１ａを有しており、例えばＪａｖａ（登録商標），Ｐｅｒｌ等の言語処理系（実行環境）１３によって実行される処理の結果に応じた動的なデータ（ファイル）を携帯電話端末装置４０等の端末装置に供給することもできるようになっている。
【００１７】
また、ＰＵＳＨサーバ装置５０は、ＭＭＬ等のデータを提供する情報提供サーバ５１と、情報提供サーバ５１が提供し得るファイル（データ）を保持するデータ保持部５２と、情報提供サーバ５１のＣＧＩ処理部５１ａからの指示に従って処理を実行する言語処理系（実行環境）５３とを備えている。
【００１８】
ネットワーク２０は、ＴＣＰ（Ｔｒａｎｓｆｅｒ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）によって通信を行うインターネット等のネットワークである。上述のＨＴＴＰサーバ１１は、このＴＣＰ／ＩＰ上で動作している。これに対し、情報提供サーバ５１は、ネットワーク２０を介さずに携帯電話端末装置４０と独自のプロトコルで通信を行うようになっている。
【００１９】
移動体通信網３０は、携帯電話端末装置４０との間の無線チャネルの割り当て等の処理を行う回線交換機３１と、携帯電話端末装置４０と間で無線通信を行う基地局装置３２ａ，３２ｂ，…，３２ｎと、データ通信用のパケットデータ等の交換処理を行うパケット交換機３３と、携帯電話端末装置４０に対してショートメッセージ，ページ記述データ等のＰＵＳＨ型の情報配信を行うショートメッセージセンタ（ＳＭＳＣ）３５とを備えている。
【００２０】
携帯電話端末装置４０は、基地局装置３２ａ〜３２ｎとの通信を制御する通信制御部４１と、ＨＴＴＰサーバ１１（５１）から供給されるデータファイルを保持するファイル保持部４２と、携帯電話端末装置４０全体の動作を制御するＭＰＵ４３と、ユーザからの指示を入力する操作キー４４と、液晶ディスプレイ等の表示画面を有する表示部４５と、他の携帯電話端末装置４０あるいは固定電話端末装置等との通話処理を実行する通話処理部４６等を備えている。
【００２１】
ファイル保持部４２は、例えば携帯電話端末装置４０に設けられたメモリ内の所定の領域として実現されている。
【００２２】
ＭＰＵ４３は、制御プログラムの実行により、ＨＴＴＰサーバ１１，情報提供サーバ５１から供給されるデータファイルの閲覧等を行うファイル閲覧処理部（Ｗｅｂブラウザ）１と、ファイル保持部４２に格納されているファイルの管理を行うファイル管理部２と、電子メールの送受信を行うメール処理部３等として機能する。
【００２３】
また、Ｗｅｂブラウザ１は、ファイル保持部４２に保持されたデータファイルのファイル形式を判定するファイル形式判定部１ａと、ファイル形式判定部１ａの判定結果に応じてデータファイルの再生等の処理を実行するファイル処理部１ｂとを備えている。このファイル処理部１ｂは、例えばテキストデータあるいは画像データをに応じた画像を表示部４５に表示させるデータを生成する表示機能、音声データを再生してスピーカ４７を駆動するためのデータを生成する音声再生機能等を備えている。
【００２４】
また、ファイル管理部２は、ファイル保持部４２に格納されているデータファイルの拡張子に応じた利用の制限を行う利用制限部２ａを備えている。この利用制限部２ａは、ＨＴＴＰサーバ装置１０あるいはＰＵＳＨサーバ装置５０等から提供されたデータファイルの識別子に応じて当該データファイルの転送可否等の利用制限を行う。
【００２５】
ところで、Ｗｅｂブラウザ１等による携帯電話端末装置４０と移動体通信網３０との間のデータ通信は、例えばＲＣＲ−ＳＴＤ２７（Ｊ版）で規定されているパケットによって行われている。この規格におけるパケット通信の伝送レートは、有線回線上の伝送レートに比較して低い。このため、規格どおりのＨＴＴＰを実装した場合には、タグ等の伝送時間が無視できないものになり、トラフィックの増加，レスポンスの低下等を招いてしまう。
【００２６】
このため、この情報通信システムでは、携帯電話端末装置４０のＷｅｂブラウザ１は、例えばページ記述データの記述言語としてＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で定義されているタグを省略形で表したＭＭＬ（Ｍｏｂｉｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いており、また、このＷｅｂブラウザ１にはＨＴＴＰは実装されていない。
【００２７】
このような仕様のＷｅｂブラウザ１と通常のＨＴＴＰを実装しているＨＴＴＰサーバ１１との間で通信を行うために、この情報通信システムでは、これらのプロトコル間の変換を行うゲートウェイ装置２５を設けている。このゲートウェイ装置２５は、例えばタグ，メッセージの変換等を示す所定の変換テーブルを持っており、携帯電話端末装置４０のＷｅｂブラウザ１と、ＨＴＴＰサーバ１１の間のメッセージの変換，タグの変換等の処理を行うようになっている。
【００２８】
具体的には、ＵＲＬを指定してＷｅｂブラウザ１がＨＴＴＰサーバ１１にファイルの要求（ＧＥＴメッセージ）を送信した場合（例えば図２中のＳ１０１〜Ｓ１０２）の、ＨＴＴＰサーバ１１からの応答メッセージ（Ｓ１０３）は、例えば図３に示すように、ＨＴＴＰの仕様で定義されているＨＴＴＰヘッダがそのまま付加されている。
【００２９】
これに対し、ゲートウェイ装置２５がＷｅｂブラウザ１に送信する応答メッセージ（図２中のＳ１０４）は、例えば図４に示すように、ＨＴＴＰヘッダが省略されてメッセージ全体のサイズが低減された状態となっている。なお、情報提供サーバ５１は、この図４に示す応答メッセージと同様のフォーマットの応答メッセージをＷｅｂブラウザ１に送信するようになっている。
【００３０】
また、ＨＴＴＰサーバ１１がＭＭＬ形式のページ記述データをＷｅｂブラウザ１に提供する場合には、ゲートウェイ装置２５は、タグの変換処理は行わない。あるいは、情報提供サーバ５１がＭＭＬ形式のページ記述データをＷｅｂブラウザ１に提供する場合には、ゲートウェイ装置２５を介さずに、上述のＳＭＳＣ３５を介して、例えばショートメールのメッセージと同様のプロトコルによって提供する。
【００３１】
（ファイル形式判定）
上述の図４に示すように、この情報通信システムでは、ＨＴＴＰヘッダ中のコンテントタイプ（Ｃｏｎｔｅｎｔ−Ｔｙｐｅ）がＷｅｂブラウザ１に供給されないため、コンテントタイプに基づいたファイル形式の判定を行うことができない。
【００３２】
このため、この情報通信システムでは、データファイルの先頭部分のシグネチャによってファイル形式を判定するようになっている。一般的な規格で定義されているファイル形式では、例えば図５（Ａ）に示すように、データファイルの先頭部分にシグネチャが格納されている。このシグネチャは、例えば図６に示すように、ファイル形式毎に異なる値に設定されるようになっている。
【００３３】
具体的には、例えばＰＮＧ形式のデータファイルではファイルの先頭８バイトが「８９５０４Ｅ４７０Ｄ０Ａ１Ａ０Ａ（１６進数、以下省略）」であり、ＭＮＧ形式のデータファイルではファイルの先頭８バイトが「８Ａ４Ｄ４Ｅ４７０Ｄ０Ａ１Ａ０Ａ」であり、ＪＮＧ形式のデータファイルではファイルの先頭８バイトが「８Ｂ４Ａ４Ｅ４７０Ｄ０Ａ１Ａ０Ａ」であり、ＪＰＥＧ形式のデータファイルではファイルの先頭２バイトが「ＦＦＤ８」であり、ＳＭＡＦ（Ｓｙｎｔｈｅｔｉｃ ｍｕｓｉｃ Ｍｏｂｉｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｆｏｒｍａｔ）形式のデータファイルではファイルの先頭４バイトが「４Ｄ４Ｄ４Ｄ４４」であり、ＨＴＭＬ形式のデータファイルではファイルの先頭６バイト（ＣＲ／ＬＦ，空白文字，ＤＴＤ宣言，コメント文を除く）が“＜ＨＴＭＬ＞”（大文字、小文字を区別しない）の文字を示すキャラクターコードであり、ＭＭＬは先頭３バイト（ＣＲ／ＬＦ，空白文字，コメント文を除く）が“＜ｎ＞”（ｎは１桁の自然数）の文字を示すキャラクターコードであり、ＺＩＰ形式のデータファイルではファイルの先頭２バイトが「５０４Ｂ」である。
【００３４】
これに対し、ＳＭＤのような独自に定義したファイル形式では、例えば図５（Ｂ）に示すように、ファイルの先頭部分には曲名を格納し、この後にシグネチャを格納するようにしている。具体的には、例えば着信メロディ等に用いられるＳＭＤ形式のデータファイルではファイルの先頭３１バイト以内に「１Ｂ２４４４」が含まれている。
【００３５】
（動作）
このため、ファイル形式判定部１ａにおけるファイル形式の判定処理では、まず、図５（Ｂ）に示すＳＭＤ形式のファイルの先頭部分にシグネチャがないデータファイルであるか否かの判定を行い（図７中のＳ１〜Ｓ２）、その後、図５（Ａ）に示すようなファイルの先頭部分にシグネチャがあるデータファイルのいずれであるかについて判定を行う。
【００３６】
以下の説明では、説明の簡略化のためにＷｅｂブラウザ１が扱うことができるファイル形式をＭＭＬ形式，ＰＮＧ形式，ＪＰＥＧ形式，ＳＭＤ形式，ＳＭＡＦ形式に限定した場合について説明するが、これらの形式に限定されるものではなく、Ｗｅｂブラウザ１が他のファイル形式のデータファイルを扱うことができるように構成することもできる。また、Ｗｅｂブラウザ１だけでなく、メール処理部３がファイル保持部４２に格納されてメッセージから受信メールに添付されているファイルを利用する場合等にも同様なファイル形式の判定方法を用いることができる。
【００３７】
ＨＴＴＰサーバ１１あるいは情報提供サーバ５１からＷｅｂブラウザ１に対するデータファイルの提供は、例えばユーザによるＵＲＬの入力，ＭＭＬ形式のデータファイル中における＜Ａ＞，＜ＩＭ＞，＜ＢＧＭ＞等のタグ中のＵＲＬの指示等に応じて、Ｗｅｂブラウザ１がＨＴＴＰサーバ１１あるいは情報提供サーバ５１に対して要求メッセージを送信（アップロード）し、これに対してＨＴＴＰサーバ１１あるいは情報提供サーバ５１が要求メッセージ中のＵＲＬで指示されたファイル名等に対応するデータファイルを応答メッセージとしてＷｅｂブラウザ１に送信することによって行われる。このように、送信された応答メッセージは通信制御部４１に供給され、通信制御部４１は応答メッセージ中のデータファイルをファイル保持部４２に格納する。
【００３８】
Ｗｅｂブラウザ１のファイル形式判定部１ａは、通信制御部４１がデータファイルをファイル保持部４２に格納すると（図７中のＳ１）、まず、ファイル保持部４２に保持されているデータファイルのシグネチャからＳＭＤ形式であるか否か、すなわちデータファイルの先頭３１バイト以内に「１Ｂ２４４４」が含まれているか否かを判定する（Ｓ２）。該当する場合には、ファイル形式判定部１ａは、当該データファイルがＳＭＤ形式であると判定し、例えば図８に示す処理を実行する。
【００３９】
ＳＭＤ形式でない場合には、ファイル形式判定部１ａは、ファイル保持部４２に保持されているデータファイルのシグネチャからＭＭＬ形式であるか否か、すなわち先頭３バイト（ＣＲ／ＬＦ，空白文字，コメント文を除く）が“＜ｎ＞”（ｎは１桁の自然数）の文字を示すキャラクターコードであるか否かを判定する（Ｓ３）。該当する場合には、ファイル形式判定部１ａは、当該データファイルがＭＭＬ形式であると判定し、Ｗｅｂブラウザ１はファイル保持部４２に保持されているデータファイルの解析を行い、必要な処理を実行する（Ｓ４）。
【００４０】
ファイル保持部４２に保持されているデータファイルがＳＭＤ形式でもＭＭＬ形式でもない場合には、ファイル形式判定部１ａは、データファイルのシグネチャからＰＮＧ形式であるか否か、すなわちデータファイルの先頭８バイトが「８９５０４Ｅ４７０Ｄ０Ａ１Ａ０Ａ」であるか否かを判定する（Ｓ５）。該当する場合には、ファイル形式判定部１ａは、当該データファイルがＰＮＧ形式であると判定し、例えば図９に示す処理を実行する。
【００４１】
ＰＮＧ形式でない場合には、ファイル形式判定部１ａは、データファイルのシグネチャからＪＰＥＧ形式であるか否か、すなわちデータファイルの先頭２バイトが「ＦＦＤ８」であるか否かを判定する（Ｓ６）。該当する場合には、ファイル形式判定部１ａは、当該データファイルがＪＰＥＧ形式であると判定し、例えば図１０に示す処理を実行する。
【００４２】
ＪＰＥＧ形式でない場合には、ファイル形式判定部１ａは、データファイルのシグネチャからＳＭＡＦ形式であるか否か、すなわちデータファイルの先頭４バイトが「４Ｄ４Ｄ４Ｄ４４」であるか否かを判定する（Ｓ７）。該当する場合には、ファイル形式判定部１ａは、当該データファイルがＳＭＡＦ形式であると判定し、例えば図１１に示す処理を実行する。
【００４３】
ＳＭＡＦ形式でない場合には、ファイル形式判定部１ａは、当該データファイルがＷｅｂブラウザ１が扱うことができない形式であると判定し、例えばＷｅｂブラウザ１が表示部４５に未対応のファイル形式であることを示すアイコン（例えば「？」）等の表示を行う（Ｓ８）。
【００４４】
さらに、上述のＭＭＬ形式，ＰＮＧ形式等のＷｅｂブラウザ１が利用することができるファイル形式である場合には、ファイル保持部４２に保持されているデータファイルの形式等を示す情報（プロパティ）を表示部４５に表示するようにしておき、Ｗｅｂブラウザ１が利用できないファイル形式である場合には、プロパティを表示しないように構成してもよい。これにより、Ｗｅｂブラウザ１が利用できるデータファイルについてのみユーザにファイル形式等の情報を提供することができ、無用な表示等を低減させることができる。
【００４５】
（効果）
以上説明したように、この情報通信システムでは、コンテンツタイプを識別する機能が実装されていない携帯電話端末装置４０であっても、データファイル中のシグネチャに基づいてファイル形式を正確に判定することができる。
【００４６】
ＨＴＴＰを実装していない端末装置でファイル形式を判定するためには、ファイル名の拡張子によってファイル形式を判定することも考えられるが、この場合は、例えばＣＧＩ等のように、拡張子が付いていない、あるいはワイルドカード等の拡張子によってはファイル形式を判定することができない場合がある。
【００４７】
これに対し、上述のように、ファイル中のシグネチャでファイル形式を判定するようにすれば、このような場合であっても、ファイル形式を正確に判定することができる。
【００４８】
ところで、上述の図５（Ａ）に示すように、ＳＭＤ形式のファイルの先頭部分は曲名等を示すテキスト情報である。このため、上述の図６中に示す他のファイル形式のシグネチャと同一になってしまう可能性がある。例えば曲名の先頭から４文字が“ＭＭＭＤ”であった場合、この文字列のキャラクターコードが「４Ｄ４Ｄ４Ｄ４４」となり、ＳＭＡＦ形式のファイルのシグネチャと同一になってしまう。あるいは、曲名の先頭から２文字が“ＰＫ”であった場合、この文字列のキャラクターコードが「５０４Ｂ」となり、ＺＩＰ形式のファイルのシグネチャと同一になってしまう。
【００４９】
これに対して、上述の図５（Ｂ）に示すように、ＰＮＧ形式，ＪＰＥＧ形式等のバイナリのデータファイルでは、シグネチャの後に、画像データの本体（同図中のデータ）が格納されているが、この部分のデータは画素データのＤＣＴ変換値等である。このため、ＳＭＤ形式のファイル中のシグネチャ部分に相当するデータが、ＳＭＤ形式のシグネチャと同一になる可能性があるが、ＳＭＤ形式におけるファイル名部分が他の形式シグネチャと同一になってしまう確率より極めて低い。
【００５０】
このため、上述のように、まず、ＳＭＤ形式のファイルの先頭３１バイト以内の部分にシグネチャがないデータファイルであるか否かの判定を行い、その後、ファイルの先頭部分にシグネチャがあるデータファイルのいずれであるかについて判定を行うことにより、判定の正確性を向上させることができる。
【００５１】
（ファイル利用制限）
上述の図７中のＳ２において、ファイル形式判定部１ａがファイル保持部４２に格納されているデータファイルがＳＭＤ形式であると判定した場合には、例えば図８に示すように、まず、ファイルが展開可能であるか否かを判定し（Ｓ１１）、展開不可能であれば表示部４５にその旨のメッセージ（例えば「不正なデータです」等）を表示させる（Ｓ１２）。データファイルを展開可能な場合には、ファイル形式判定部１ａは、プロパティとして当該データファイルがメロディファイルである旨を表示させる（Ｓ１３）。
【００５２】
この後、ファイル形式判定部１ａは、当該データファイルを取得する際に送信した要求メッセージ中のファイル名等から当該データファイルの拡張子に基づいてファイルの利用制限の有無を判定する（Ｓ１４〜Ｓ１８）。
【００５３】
具体的には、まず、拡張子が「．ｓｍｄ」であるか否かを判断し（Ｓ１４）、「．ｓｍｄ」である場合には利用制限を「転送可・登録保存可」として利用制限部２ａに通知する（Ｓ１５）。拡張子が「．ｓｍｄ」でなければ、拡張子が「．ｓｍｘ」であるか否かを判断し（Ｓ１６）、「．ｓｍｘ」である場合には利用制限を「転送不可・登録保存不可」として利用制限部２ａに通知する（Ｓ１７）。拡張子がこれらのいずれでもない場合には利用制限を「転送不可・登録保存可」として利用制限部２ａに通知する（Ｓ１８）。これにより、例えば「．ｃｇｉ」等の上述以外の拡張子のデータファイルを受信した場合には一律で「転送不可・登録保存可」となる。
【００５４】
また、上述の図７中のＳ５において、ファイル形式判定部１ａがファイル保持部４２に格納されているデータファイルがＰＮＧ形式であると判定した場合には、例えば図９に示すように、まず、ファイルが展開可能であるか否かを判定し（Ｓ２１）、展開不可能であれば表示部４５にその旨のメッセージ（例えばファイルが破壊されたことを示す破壊アイコン等）を表示させる（Ｓ２２）。データファイルを展開可能な場合には、ファイル形式判定部１ａは、プロパティとして当該データファイルがＰＮＧファイルである旨を表示させる（Ｓ２３）。
【００５５】
この後、ファイル形式判定部１ａは、当該データファイルの拡張子に基づいてファイルの利用制限の有無を判定する（Ｓ２４〜Ｓ２６）。具体的には、拡張子が「．ｐｎｇ」であるか否かを判断し（Ｓ２４）、「．ｐｎｇ」である場合には利用制限を「転送可・登録保存可、下位端末に転送可」として利用制限部２ａに通知する（Ｓ２５）。拡張子が「．ｐｎｇ」でなければ、利用制限を「転送不可・登録保存可、下位端末に転送不可」として利用制限部２ａに通知する（Ｓ２６）。これにより、例えば「．ｃｇｉ」等の上述以外の拡張子のデータファイルを受信した場合には一律で「転送不可・登録保存可、下位端末に転送不可」となる。
【００５６】
また、上述の図７中のＳ６において、ファイル形式判定部１ａがファイル保持部４２に格納されているデータファイルがＪＰＥＧ形式であると判定した場合には、例えば図１０に示すように、まず、ファイルが展開可能であるか否かを判定し（Ｓ３１）、展開不可能であれば表示部４５にその旨のメッセージ（例えばファイルが破壊されたことを示す破壊アイコン等）を表示させる（Ｓ３２）。データファイルを展開可能な場合には、ファイル形式判定部１ａは、プロパティとして当該データファイルがＪＰＥＧファイルである旨を表示させる（Ｓ３３）。
【００５７】
この後、ファイル形式判定部１ａは、当該データファイルの拡張子に基づいてファイルの利用制限の有無を判定する（Ｓ３４〜Ｓ３６）。具体的には、拡張子が「．ｊｐｇ」，「．ｊｐｅｇ」あるいは「．ｊｐｅ」のいずれかであるか否かを判断し（Ｓ３４）、これらの拡張子に該当する場合には利用制限を「転送可・登録保存可、下位端末に転送可」として利用制限部２ａに通知する（Ｓ３５）。データファイルの拡張子がこれらのいずれにも該当しなければ、利用制限を「転送不可・登録保存可、下位端末に転送不可」として利用制限部２ａに通知する（Ｓ３６）。これにより、例えば「．ｃｇｉ」等の上述以外の拡張子のデータファイルを受信した場合には一律で「転送不可・登録保存可、下位端末に転送不可」となる。
【００５８】
（効果）
上述のように、この情報通信システムでは、携帯電話端末装置４０において、ＰＮＧ形式，ＪＰＥＧ形式，ＳＭＤ形式のデータファイルの利用制限をこれらのデータファイルの拡張子によって決定するようにしたため、ＨＴＴＰサーバ１１あるいは情報提供サーバ５１において、データ保持部１２，５２にデータファイルを格納する際に当該データファイルの利用制限に応じた拡張子として保存すれば、携帯電話端末装置４０側における当該データファイルの利用を制限させることができる。すなわち、この情報通信システムでは、ＨＴＴＰを実装していない携帯電話端末装置であっても、データファイルの利用制限を容易に実現することができる。
【００５９】
この情報通信システムでは、上述のように、データファイルの利用制限を実現できるため、コンテンツの著作権保護に寄与することができる。具体的には、例えば有料で提供するコンテンツについては、「転送不可」とすることで複製等を制限することでき、試聴等の目的で無料で提供するコンテンツについてはさらに、「登録保存不可」とすれば、目的外の再利用を制限することができる。このように、利用形態に応じたコンテンツの利用の制限を実現することにより、著作権の保護の容易化に寄与することができる。
【００６０】
また、上述のＳＭＡＦ形式のデータファイルについては、当該データファイル中の転送制御部分によって利用制限を定義すれば、携帯電話端末装置４０側において、当該転送制御部分に応じた利用制限を実現することができる。
【００６１】
具体的には、例えばＳＭＡＦ形式のデータファイル中に、コンテンツのクラスを示すコンテンツクラス（Ｃｏｎｔｅｎｔｓ Ｃｌａｓｓ）とコンテンツの型を示すコンテンツタイプ（Ｃｏｎｔｅｎｔｓ Ｔｙｐｅ）が含まれている。コンテンツクラスの値は、定義されている値と、未定義の値（Ｒｅｓｅｒｖｅｄ）とがあり、定義されている値に対応するクラスはファイル処理部１ｂに実装されているものとする。
【００６２】
また、コンテンツタイプの値は、「００」〜「０Ｆ」及び「３０」〜「３３」がＳｃｏｒｅ Ｔｒａｃｋ ＣｈｕｎｋとＰＣＭ Ａｕｄｉｏ Ｔｒａｃｋ Ｃｈｕｎｋのデータを含む着信メロディに対応しており、「１０」〜「１Ｆ」及び「４０」〜「４２」が文字データとＳｃｏｒｅ Ｔｒａｃｋ Ｃｈｕｎｋ又はＰＣＭ Ａｕｄｉｏ Ｔｒａｃｋ ＣｈｕｎｋとＧｒａｐｈｉｃｓ Ｔｒａｃｋ Ｃｈｕｎｋのデータを含むカラオケ系に対応しており、「２０」〜「２Ｆ」及び「５０」〜「５３」がカラオケ系と同様のデータを含むＣＭ（コマーシャル）系に対応しており、これら以外の未使用値が予約（Ｒｅｓｅｒｖｅｄ）とされている。
【００６３】
また、ＳＭＡＦ形式のデータファイルには、コピー状態を示す１バイトのコピーステータス（Ｃｏｐｙ Ｓｔａｔｕｓ）が含まれている。このコピーステータスの最下位ビット（ｂ０）は転送の可否を示しており、値が“０”のときは転送可，“１”のときは転送不可の状態を示している。また、下から２ビット目（ｂ１）は保存の可否を示しており、値が“０”のときは保存可，“１”のときは保存不可の状態を示している。
【００６４】
上述の図７中のＳ７において、ファイル形式判定部１ａがファイル保持部４２に格納されているデータファイルがＳＭＡＦ形式であると判定した場合には、例えば図１１に示すように、まず、当該データファイル中のコンテンツクラスが「Ｒｅｓｅｒｖｅｄ」であるか否かを判定し（Ｓ４１）、「Ｒｅｓｅｒｖｅｄ」であるときは表示部４５に未対応である旨を表示させる（Ｓ４３）。
【００６５】
コンテンツクラスが「Ｒｅｓｅｒｖｅｄ」でない場合には、ファイル形式判定部１ａは、コンテンツタイプが、上述の着信メロディ，カラオケ系，ＣＭ系のいずれかに該当するか否か、すなわちファイル処理部１ｂで対応可能か否かを判定し（Ｓ４２）、対応可能でなければ表示部４５に未対応である旨を表示させる（Ｓ４３）。
【００６６】
対応可能である場合には、ファイル形式判定部１ａは、データファイル中のコピーステータスの下から２ビット目（ｂ１）が“１”であるか否かを確認する（Ｓ４４）。ｂ１が“１”であれば当該データファイルの利用制限を「登録保存不可」として利用制限部２ａに通知し（Ｓ４５）、そうでなければ利用制限を「登録保存可」として利用制限部２ａに通知する（Ｓ４６）。
【００６７】
さらに、ファイル形式判定部１ａは、コピーステータスの最下位ビット（ｂ０）が“１”であるか否かを確認する（Ｓ４７）。ｂ０が“１”であれば当該データファイルの利用制限を「転送不可」として利用制限部２ａに通知し（Ｓ４９）、そうでなければ利用制限を「転送可」として利用制限部２ａに通知する（Ｓ４８）。
【００６８】
上述のように利用制限が利用制限部２ａに通知されると、ファイル管理部２は、利用制限部２ａの指示に従ってファイル保持部４２に保持されたデータファイルの利用を制限する。
【００６９】
なお、上述のように利用制限のあるコンテンツをＨＴＴＰサーバ１１によって提供する場合には、ネットワーク２０に接続されている携帯電話端末装置４０以外の情報処理装置上で実行されるＷｅｂブラウザ等から利用されないように、ＨＴＴＰサーバ１１側において、相手が携帯電話端末装置４０である場合にのみ利用制限のあるデータファイルを送信するようにすることが望ましい。
【００７０】
（変形例）
ところで、ＨＴＴＰを実装している端末においても、サーバ側から通知されたファイル形式がコンテントタイプ「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｃｔｅｔ−ｓｔｒｅａｍ」あるいは「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｐｌａｉｎ」等のワイルドカードであった場合に、上述と同様に、供給されたファイルのシグネチャに応じてファイル判定処理を行うこともできる。
【００７１】
これらの「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｃｔｅｔ−ｓｔｒｅａｍ」あるいは「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｐｌａｉｎ」等のワイルドカードは、ＨＴＴＰサーバ側においてデフォルト（省略時）として設定される可能性があるため、ＨＴＴＰサーバ側で未設定のファイル形式のデータファイルのコンテントタイプとして指定される可能性がある。
【００７２】
このようなコンテントタイプが指定された場合には、Ｗｅｂブラウザでコンテントタイプによってファイル形式を判定することはできないが、上述のようにシグネチャによってファイル形式を判定すれば、実際のデータファイルのファイル形式をより正確に判定することができる。
【００７３】
なお、パーソナルコンピュータ等の汎用の情報処理装置では、ユーザがＷｅｂブラウザの設定を変更して、特定のファイル形式のデータファイルを表示するアプリケーションを選択したり、起動するアプリケーションを選択したりできる。しかしながら、小型の情報端末装置では、これらの設定の変更をするユーザインタフェースの実装が困難であったり、ＭＰＵの処理能力不足のためにＨＴＴＰを実装できない場合がある。このような場合に、本発明を適用すれば、データファイルのファイル形式を確実に判定することができ、データファイルの表示あるいは起動すべき適切な処理を容易に選択することができる。
【００７４】
【発明の効果】
本発明では、情報通信端末装置の判定手段が、取得手段が取得したデータファイル中のシグネチャに応じて当該データファイルのファイル形式を判定することができる。このため、移動体通信網における伝送プロトコル上でファイル形式を通知しなくても、情報通信端末装置側でファイル形式を正確に判定することができる。
【００７５】
さらに、情報通信端末装置に判定手段による判定結果及びデータファイルの拡張子に応じて当該データファイルの利用を制限する利用制限手段を設けることにより、拡張子に応じてデータファイルの利用制限を実現することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る情報通信システムの構成例を示す図である。
【図２】前記情報通信システムにおける携帯電話端末装置とサーバ装置の間の通信の例示すシーケンス図である。
【図３】前記サーバ装置からゲートウェイ装置に送信される応答メッセージの例を示す図である。
【図４】前記ゲートウェイ装置に前記携帯電話端末装置に送信される応答メッセージの例を示す図である。
【図５】前記携帯電話端末装置のＷｅｂブラウザが取得するデータファイルの構造の例を示す図である。
【図６】前記データファイル中のシグネチャの例を示す図である。
【図７】前記携帯電話端末装置のファイル形式判定部におけるファイル形式の判定処理の例を示すフローチャートである。
【図８】ファイル利用制限処理の詳細を示すフローチャートである。
【図９】ファイル利用制限処理の詳細を示すフローチャートである。
【図１０】ファイル利用制限処理の詳細を示すフローチャートである。
【図１１】ファイル利用制限処理の詳細を示すフローチャートである。
【符号の説明】
１…Ｗｅｂブラウザ、１ａ…ファイル形式判定部、１ｂ…ファイル処理部、２…ファイル管理部、２ａ…利用制限部、３…メール処理部、１０…ＨＴＴＰサーバ装置、１１…ＨＴＴＰサーバ、１２，５２…データ保持部、１３，５３…実行環境、２５…ゲートウェイ装置、３０…移動体通信網、３１…回線交換機、３３…パケット交換機、３５…ＳＭＳＣ、３２ａ，３２ｂ，…，３２ｎ…基地局装置、４０…携帯電話端末装置、４１…通信制御部、４２…ファイル保持部、５０…ＰＵＳＨサーバ装置、５１…情報提供サーバ
【発明の属する技術分野】
本発明は、ファイル形式を正確に判定できる情報通信端末装置及び情報通信システムに関する。
【０００２】
【従来の技術】
ＨＴＴＰサーバからの応答（レスポンス）メッセージには、例えば図３に示すように、ＨＴＴＰヘッダが含まれており、このＨＴＴＰヘッダには、データ本体のファイル形式を示すコンテントタイプ（Ｃｏｎｔｅｎｔ ｔｙｐｅ）が含まれている。ＨＴＴＰサービスを利用するＷｅｂブラウザ等のクライアントアプリケーションは、このコンテントタイプによって、データ本体のファイル形式を判定することができるようになっている（例えば非特許文献１参照。）。
【０００３】
ところで、近年、ＨＴＴＰサービスを利用できる携帯電話端末装置が普及しているが、移動体通信網における通信速度がインターネット等の固定通信網に比較して遅いため、ＨＴＴＰヘッダ，タグ等による、レスポンスデータのサイズの増加が無視できないものとなる。また、ＭＰＵの性能上の制約からＨＴＴＰをそのまま実装することが困難である場合もあった。
【０００４】
このため、ＨＴＴＰプロトコルをそのまま実装するのではなく、ＨＴＴＰヘッダを省略し、さらに、ページ記述言語としてタグを短縮系で表現したＭＭＬ等のＨＴＭＬのサブセット仕様の言語が用いられている（例えば特許文献１参照。）。
【０００５】
このような携帯電話端末装置で通常のＨＴＴＰサーバによって提供されているサービスを利用する場合には、プロトコルとタグの変換を行うゲートウェイ装置が用いられている。
【０００６】
しかし、このような実装の携帯電話端末装置では、ＨＴＴＰヘッダが省略されているために上述のコンテントタイプが含まれておらず、コンテントタイプによってファイル形式を判定することができない（例えば特許文献２参照。）。このため、携帯電話端末装置側からＵＲＬを指定して要求（リクエスト）メッセージを送信する際等に、ＵＲＬ中のファイル名の拡張子によってファイル形式を判定していた。
【０００７】
【非特許文献１】
Ｊｏｎ Ｐｏｓｔｅｌ、「ＲＦＣ−２０６８」、［ｏｎｌｉｎｅ］、１９９７年１月１日、［平成１４年１１月１１日検索］、インターネット＜ＵＲＬ：ＨＴＴＰ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２０６８．ｔｘｔ＞、ｐ．２４〜２６
【特許文献１】
特開２０００−１５２３２７号（第６−９頁、第６図）
【特許文献２】
特開２００１−１９７５５３号（第６−７頁、第６図）
【０００８】
【発明が解決しようとする課題】
しかしながら、ＣＧＩ等を用いた動的なコンテンツ（例えば携帯電話端末装置側からの情報に応じた画像等）を利用する場合には、ＵＲＬ中にファイルの拡張子が含まれていない場合があり、このような場合には拡張子によってファイル形式を判定することができない。
【０００９】
最近のＭＰＵの性能の向上、移動体通信網における通信速度の向上等により、携帯電話端末装置にＨＴＴＰを実装することもできるようになりつつあるが、ＨＴＴＰを実装した場合でもコンテントタイプがワイルドカード（Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｏｃｔｅｔ−ｓｔｒｅａｍ等）である場合には、コンテントタイプのみでデータ本体のファイル形式を判定することはできない。
【００１０】
本発明は、上述のような課題に鑑みてなされたものであり、ファイル形式を正確に判定することができる情報通信端末装置及び情報通信システムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
上述の問題を解決するために、本発明に係る情報通信端末装置は、ファイル形式毎に固有の情報（シグネチャ）を含むデータファイルを移動体通信網を介して取得する取得手段と、取得手段が取得したデータファイル中のシグネチャに応じて当該データファイルのファイル形式を判定する判定手段とを備えることを特徴とする。この情報通信端末装置では、判定手段が、取得手段が取得したデータファイル中のシグネチャに応じて当該データファイルのファイル形式を判定することができる。
【００１２】
また、本発明に係る情報通信システムは、移動体通信網を介して、情報提供サーバ装置から情報通信端末装置にファイル形式毎に固有の情報（シグネチャ）を含むデータファイルを提供する情報通信システムであって、情報通信端末装置が、提供されたデータファイル中のシグネチャに応じて当該データファイルのファイル形式を判定する判定手段を備えることを特徴とする。
【００１３】
【発明の実施の形態】
本発明は、例えば携帯電話端末装置等の情報利用端末装置に、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）サービス等を移動体通信網を介して提供する情報通信システム等に適用することができる。
【００１４】
（構成）
この情報通信システムは、例えば図１に示すように、ページ記述データ等のデータファイルを提供するＨＴＴＰサーバ装置１０及びＰＵＳＨサーバ装置５０と、インターネット等のネットワーク２０側と移動体通信網３０側との間のプロトコル変換を行うゲートウェイ装置２５と、移動体通信網３０を介してサーバ装置１０と通信を行う携帯電話端末装置（情報通信端末装置）４０とを備えている。
【００１５】
ＨＴＴＰサーバ装置１０は、例えばＨＴＭＬ等のデータを提供するＨＴＴＰサーバ１１と、ＨＴＴＰサーバ１１が提供し得るファイル（データ）を保持するデータ保持部１２とを備えている。データ保持部１２には、文字情報，音楽等の音声情報，静止画・動画等の画像情報等がファイルとして格納されている。ＨＴＴＰサーバ１１は、携帯電話端末装置４０等のネットワーク２０経由で接続されている端末装置からの要求されたファイルをデータ保持部１２から読み出して送信する。
【００１６】
また、ＨＴＴＰサーバ１１は、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）処理部１１ａを有しており、例えばＪａｖａ（登録商標），Ｐｅｒｌ等の言語処理系（実行環境）１３によって実行される処理の結果に応じた動的なデータ（ファイル）を携帯電話端末装置４０等の端末装置に供給することもできるようになっている。
【００１７】
また、ＰＵＳＨサーバ装置５０は、ＭＭＬ等のデータを提供する情報提供サーバ５１と、情報提供サーバ５１が提供し得るファイル（データ）を保持するデータ保持部５２と、情報提供サーバ５１のＣＧＩ処理部５１ａからの指示に従って処理を実行する言語処理系（実行環境）５３とを備えている。
【００１８】
ネットワーク２０は、ＴＣＰ（Ｔｒａｎｓｆｅｒ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）によって通信を行うインターネット等のネットワークである。上述のＨＴＴＰサーバ１１は、このＴＣＰ／ＩＰ上で動作している。これに対し、情報提供サーバ５１は、ネットワーク２０を介さずに携帯電話端末装置４０と独自のプロトコルで通信を行うようになっている。
【００１９】
移動体通信網３０は、携帯電話端末装置４０との間の無線チャネルの割り当て等の処理を行う回線交換機３１と、携帯電話端末装置４０と間で無線通信を行う基地局装置３２ａ，３２ｂ，…，３２ｎと、データ通信用のパケットデータ等の交換処理を行うパケット交換機３３と、携帯電話端末装置４０に対してショートメッセージ，ページ記述データ等のＰＵＳＨ型の情報配信を行うショートメッセージセンタ（ＳＭＳＣ）３５とを備えている。
【００２０】
携帯電話端末装置４０は、基地局装置３２ａ〜３２ｎとの通信を制御する通信制御部４１と、ＨＴＴＰサーバ１１（５１）から供給されるデータファイルを保持するファイル保持部４２と、携帯電話端末装置４０全体の動作を制御するＭＰＵ４３と、ユーザからの指示を入力する操作キー４４と、液晶ディスプレイ等の表示画面を有する表示部４５と、他の携帯電話端末装置４０あるいは固定電話端末装置等との通話処理を実行する通話処理部４６等を備えている。
【００２１】
ファイル保持部４２は、例えば携帯電話端末装置４０に設けられたメモリ内の所定の領域として実現されている。
【００２２】
ＭＰＵ４３は、制御プログラムの実行により、ＨＴＴＰサーバ１１，情報提供サーバ５１から供給されるデータファイルの閲覧等を行うファイル閲覧処理部（Ｗｅｂブラウザ）１と、ファイル保持部４２に格納されているファイルの管理を行うファイル管理部２と、電子メールの送受信を行うメール処理部３等として機能する。
【００２３】
また、Ｗｅｂブラウザ１は、ファイル保持部４２に保持されたデータファイルのファイル形式を判定するファイル形式判定部１ａと、ファイル形式判定部１ａの判定結果に応じてデータファイルの再生等の処理を実行するファイル処理部１ｂとを備えている。このファイル処理部１ｂは、例えばテキストデータあるいは画像データをに応じた画像を表示部４５に表示させるデータを生成する表示機能、音声データを再生してスピーカ４７を駆動するためのデータを生成する音声再生機能等を備えている。
【００２４】
また、ファイル管理部２は、ファイル保持部４２に格納されているデータファイルの拡張子に応じた利用の制限を行う利用制限部２ａを備えている。この利用制限部２ａは、ＨＴＴＰサーバ装置１０あるいはＰＵＳＨサーバ装置５０等から提供されたデータファイルの識別子に応じて当該データファイルの転送可否等の利用制限を行う。
【００２５】
ところで、Ｗｅｂブラウザ１等による携帯電話端末装置４０と移動体通信網３０との間のデータ通信は、例えばＲＣＲ−ＳＴＤ２７（Ｊ版）で規定されているパケットによって行われている。この規格におけるパケット通信の伝送レートは、有線回線上の伝送レートに比較して低い。このため、規格どおりのＨＴＴＰを実装した場合には、タグ等の伝送時間が無視できないものになり、トラフィックの増加，レスポンスの低下等を招いてしまう。
【００２６】
このため、この情報通信システムでは、携帯電話端末装置４０のＷｅｂブラウザ１は、例えばページ記述データの記述言語としてＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で定義されているタグを省略形で表したＭＭＬ（Ｍｏｂｉｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いており、また、このＷｅｂブラウザ１にはＨＴＴＰは実装されていない。
【００２７】
このような仕様のＷｅｂブラウザ１と通常のＨＴＴＰを実装しているＨＴＴＰサーバ１１との間で通信を行うために、この情報通信システムでは、これらのプロトコル間の変換を行うゲートウェイ装置２５を設けている。このゲートウェイ装置２５は、例えばタグ，メッセージの変換等を示す所定の変換テーブルを持っており、携帯電話端末装置４０のＷｅｂブラウザ１と、ＨＴＴＰサーバ１１の間のメッセージの変換，タグの変換等の処理を行うようになっている。
【００２８】
具体的には、ＵＲＬを指定してＷｅｂブラウザ１がＨＴＴＰサーバ１１にファイルの要求（ＧＥＴメッセージ）を送信した場合（例えば図２中のＳ１０１〜Ｓ１０２）の、ＨＴＴＰサーバ１１からの応答メッセージ（Ｓ１０３）は、例えば図３に示すように、ＨＴＴＰの仕様で定義されているＨＴＴＰヘッダがそのまま付加されている。
【００２９】
これに対し、ゲートウェイ装置２５がＷｅｂブラウザ１に送信する応答メッセージ（図２中のＳ１０４）は、例えば図４に示すように、ＨＴＴＰヘッダが省略されてメッセージ全体のサイズが低減された状態となっている。なお、情報提供サーバ５１は、この図４に示す応答メッセージと同様のフォーマットの応答メッセージをＷｅｂブラウザ１に送信するようになっている。
【００３０】
また、ＨＴＴＰサーバ１１がＭＭＬ形式のページ記述データをＷｅｂブラウザ１に提供する場合には、ゲートウェイ装置２５は、タグの変換処理は行わない。あるいは、情報提供サーバ５１がＭＭＬ形式のページ記述データをＷｅｂブラウザ１に提供する場合には、ゲートウェイ装置２５を介さずに、上述のＳＭＳＣ３５を介して、例えばショートメールのメッセージと同様のプロトコルによって提供する。
【００３１】
（ファイル形式判定）
上述の図４に示すように、この情報通信システムでは、ＨＴＴＰヘッダ中のコンテントタイプ（Ｃｏｎｔｅｎｔ−Ｔｙｐｅ）がＷｅｂブラウザ１に供給されないため、コンテントタイプに基づいたファイル形式の判定を行うことができない。
【００３２】
このため、この情報通信システムでは、データファイルの先頭部分のシグネチャによってファイル形式を判定するようになっている。一般的な規格で定義されているファイル形式では、例えば図５（Ａ）に示すように、データファイルの先頭部分にシグネチャが格納されている。このシグネチャは、例えば図６に示すように、ファイル形式毎に異なる値に設定されるようになっている。
【００３３】
具体的には、例えばＰＮＧ形式のデータファイルではファイルの先頭８バイトが「８９５０４Ｅ４７０Ｄ０Ａ１Ａ０Ａ（１６進数、以下省略）」であり、ＭＮＧ形式のデータファイルではファイルの先頭８バイトが「８Ａ４Ｄ４Ｅ４７０Ｄ０Ａ１Ａ０Ａ」であり、ＪＮＧ形式のデータファイルではファイルの先頭８バイトが「８Ｂ４Ａ４Ｅ４７０Ｄ０Ａ１Ａ０Ａ」であり、ＪＰＥＧ形式のデータファイルではファイルの先頭２バイトが「ＦＦＤ８」であり、ＳＭＡＦ（Ｓｙｎｔｈｅｔｉｃ ｍｕｓｉｃ Ｍｏｂｉｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｆｏｒｍａｔ）形式のデータファイルではファイルの先頭４バイトが「４Ｄ４Ｄ４Ｄ４４」であり、ＨＴＭＬ形式のデータファイルではファイルの先頭６バイト（ＣＲ／ＬＦ，空白文字，ＤＴＤ宣言，コメント文を除く）が“＜ＨＴＭＬ＞”（大文字、小文字を区別しない）の文字を示すキャラクターコードであり、ＭＭＬは先頭３バイト（ＣＲ／ＬＦ，空白文字，コメント文を除く）が“＜ｎ＞”（ｎは１桁の自然数）の文字を示すキャラクターコードであり、ＺＩＰ形式のデータファイルではファイルの先頭２バイトが「５０４Ｂ」である。
【００３４】
これに対し、ＳＭＤのような独自に定義したファイル形式では、例えば図５（Ｂ）に示すように、ファイルの先頭部分には曲名を格納し、この後にシグネチャを格納するようにしている。具体的には、例えば着信メロディ等に用いられるＳＭＤ形式のデータファイルではファイルの先頭３１バイト以内に「１Ｂ２４４４」が含まれている。
【００３５】
（動作）
このため、ファイル形式判定部１ａにおけるファイル形式の判定処理では、まず、図５（Ｂ）に示すＳＭＤ形式のファイルの先頭部分にシグネチャがないデータファイルであるか否かの判定を行い（図７中のＳ１〜Ｓ２）、その後、図５（Ａ）に示すようなファイルの先頭部分にシグネチャがあるデータファイルのいずれであるかについて判定を行う。
【００３６】
以下の説明では、説明の簡略化のためにＷｅｂブラウザ１が扱うことができるファイル形式をＭＭＬ形式，ＰＮＧ形式，ＪＰＥＧ形式，ＳＭＤ形式，ＳＭＡＦ形式に限定した場合について説明するが、これらの形式に限定されるものではなく、Ｗｅｂブラウザ１が他のファイル形式のデータファイルを扱うことができるように構成することもできる。また、Ｗｅｂブラウザ１だけでなく、メール処理部３がファイル保持部４２に格納されてメッセージから受信メールに添付されているファイルを利用する場合等にも同様なファイル形式の判定方法を用いることができる。
【００３７】
ＨＴＴＰサーバ１１あるいは情報提供サーバ５１からＷｅｂブラウザ１に対するデータファイルの提供は、例えばユーザによるＵＲＬの入力，ＭＭＬ形式のデータファイル中における＜Ａ＞，＜ＩＭ＞，＜ＢＧＭ＞等のタグ中のＵＲＬの指示等に応じて、Ｗｅｂブラウザ１がＨＴＴＰサーバ１１あるいは情報提供サーバ５１に対して要求メッセージを送信（アップロード）し、これに対してＨＴＴＰサーバ１１あるいは情報提供サーバ５１が要求メッセージ中のＵＲＬで指示されたファイル名等に対応するデータファイルを応答メッセージとしてＷｅｂブラウザ１に送信することによって行われる。このように、送信された応答メッセージは通信制御部４１に供給され、通信制御部４１は応答メッセージ中のデータファイルをファイル保持部４２に格納する。
【００３８】
Ｗｅｂブラウザ１のファイル形式判定部１ａは、通信制御部４１がデータファイルをファイル保持部４２に格納すると（図７中のＳ１）、まず、ファイル保持部４２に保持されているデータファイルのシグネチャからＳＭＤ形式であるか否か、すなわちデータファイルの先頭３１バイト以内に「１Ｂ２４４４」が含まれているか否かを判定する（Ｓ２）。該当する場合には、ファイル形式判定部１ａは、当該データファイルがＳＭＤ形式であると判定し、例えば図８に示す処理を実行する。
【００３９】
ＳＭＤ形式でない場合には、ファイル形式判定部１ａは、ファイル保持部４２に保持されているデータファイルのシグネチャからＭＭＬ形式であるか否か、すなわち先頭３バイト（ＣＲ／ＬＦ，空白文字，コメント文を除く）が“＜ｎ＞”（ｎは１桁の自然数）の文字を示すキャラクターコードであるか否かを判定する（Ｓ３）。該当する場合には、ファイル形式判定部１ａは、当該データファイルがＭＭＬ形式であると判定し、Ｗｅｂブラウザ１はファイル保持部４２に保持されているデータファイルの解析を行い、必要な処理を実行する（Ｓ４）。
【００４０】
ファイル保持部４２に保持されているデータファイルがＳＭＤ形式でもＭＭＬ形式でもない場合には、ファイル形式判定部１ａは、データファイルのシグネチャからＰＮＧ形式であるか否か、すなわちデータファイルの先頭８バイトが「８９５０４Ｅ４７０Ｄ０Ａ１Ａ０Ａ」であるか否かを判定する（Ｓ５）。該当する場合には、ファイル形式判定部１ａは、当該データファイルがＰＮＧ形式であると判定し、例えば図９に示す処理を実行する。
【００４１】
ＰＮＧ形式でない場合には、ファイル形式判定部１ａは、データファイルのシグネチャからＪＰＥＧ形式であるか否か、すなわちデータファイルの先頭２バイトが「ＦＦＤ８」であるか否かを判定する（Ｓ６）。該当する場合には、ファイル形式判定部１ａは、当該データファイルがＪＰＥＧ形式であると判定し、例えば図１０に示す処理を実行する。
【００４２】
ＪＰＥＧ形式でない場合には、ファイル形式判定部１ａは、データファイルのシグネチャからＳＭＡＦ形式であるか否か、すなわちデータファイルの先頭４バイトが「４Ｄ４Ｄ４Ｄ４４」であるか否かを判定する（Ｓ７）。該当する場合には、ファイル形式判定部１ａは、当該データファイルがＳＭＡＦ形式であると判定し、例えば図１１に示す処理を実行する。
【００４３】
ＳＭＡＦ形式でない場合には、ファイル形式判定部１ａは、当該データファイルがＷｅｂブラウザ１が扱うことができない形式であると判定し、例えばＷｅｂブラウザ１が表示部４５に未対応のファイル形式であることを示すアイコン（例えば「？」）等の表示を行う（Ｓ８）。
【００４４】
さらに、上述のＭＭＬ形式，ＰＮＧ形式等のＷｅｂブラウザ１が利用することができるファイル形式である場合には、ファイル保持部４２に保持されているデータファイルの形式等を示す情報（プロパティ）を表示部４５に表示するようにしておき、Ｗｅｂブラウザ１が利用できないファイル形式である場合には、プロパティを表示しないように構成してもよい。これにより、Ｗｅｂブラウザ１が利用できるデータファイルについてのみユーザにファイル形式等の情報を提供することができ、無用な表示等を低減させることができる。
【００４５】
（効果）
以上説明したように、この情報通信システムでは、コンテンツタイプを識別する機能が実装されていない携帯電話端末装置４０であっても、データファイル中のシグネチャに基づいてファイル形式を正確に判定することができる。
【００４６】
ＨＴＴＰを実装していない端末装置でファイル形式を判定するためには、ファイル名の拡張子によってファイル形式を判定することも考えられるが、この場合は、例えばＣＧＩ等のように、拡張子が付いていない、あるいはワイルドカード等の拡張子によってはファイル形式を判定することができない場合がある。
【００４７】
これに対し、上述のように、ファイル中のシグネチャでファイル形式を判定するようにすれば、このような場合であっても、ファイル形式を正確に判定することができる。
【００４８】
ところで、上述の図５（Ａ）に示すように、ＳＭＤ形式のファイルの先頭部分は曲名等を示すテキスト情報である。このため、上述の図６中に示す他のファイル形式のシグネチャと同一になってしまう可能性がある。例えば曲名の先頭から４文字が“ＭＭＭＤ”であった場合、この文字列のキャラクターコードが「４Ｄ４Ｄ４Ｄ４４」となり、ＳＭＡＦ形式のファイルのシグネチャと同一になってしまう。あるいは、曲名の先頭から２文字が“ＰＫ”であった場合、この文字列のキャラクターコードが「５０４Ｂ」となり、ＺＩＰ形式のファイルのシグネチャと同一になってしまう。
【００４９】
これに対して、上述の図５（Ｂ）に示すように、ＰＮＧ形式，ＪＰＥＧ形式等のバイナリのデータファイルでは、シグネチャの後に、画像データの本体（同図中のデータ）が格納されているが、この部分のデータは画素データのＤＣＴ変換値等である。このため、ＳＭＤ形式のファイル中のシグネチャ部分に相当するデータが、ＳＭＤ形式のシグネチャと同一になる可能性があるが、ＳＭＤ形式におけるファイル名部分が他の形式シグネチャと同一になってしまう確率より極めて低い。
【００５０】
このため、上述のように、まず、ＳＭＤ形式のファイルの先頭３１バイト以内の部分にシグネチャがないデータファイルであるか否かの判定を行い、その後、ファイルの先頭部分にシグネチャがあるデータファイルのいずれであるかについて判定を行うことにより、判定の正確性を向上させることができる。
【００５１】
（ファイル利用制限）
上述の図７中のＳ２において、ファイル形式判定部１ａがファイル保持部４２に格納されているデータファイルがＳＭＤ形式であると判定した場合には、例えば図８に示すように、まず、ファイルが展開可能であるか否かを判定し（Ｓ１１）、展開不可能であれば表示部４５にその旨のメッセージ（例えば「不正なデータです」等）を表示させる（Ｓ１２）。データファイルを展開可能な場合には、ファイル形式判定部１ａは、プロパティとして当該データファイルがメロディファイルである旨を表示させる（Ｓ１３）。
【００５２】
この後、ファイル形式判定部１ａは、当該データファイルを取得する際に送信した要求メッセージ中のファイル名等から当該データファイルの拡張子に基づいてファイルの利用制限の有無を判定する（Ｓ１４〜Ｓ１８）。
【００５３】
具体的には、まず、拡張子が「．ｓｍｄ」であるか否かを判断し（Ｓ１４）、「．ｓｍｄ」である場合には利用制限を「転送可・登録保存可」として利用制限部２ａに通知する（Ｓ１５）。拡張子が「．ｓｍｄ」でなければ、拡張子が「．ｓｍｘ」であるか否かを判断し（Ｓ１６）、「．ｓｍｘ」である場合には利用制限を「転送不可・登録保存不可」として利用制限部２ａに通知する（Ｓ１７）。拡張子がこれらのいずれでもない場合には利用制限を「転送不可・登録保存可」として利用制限部２ａに通知する（Ｓ１８）。これにより、例えば「．ｃｇｉ」等の上述以外の拡張子のデータファイルを受信した場合には一律で「転送不可・登録保存可」となる。
【００５４】
また、上述の図７中のＳ５において、ファイル形式判定部１ａがファイル保持部４２に格納されているデータファイルがＰＮＧ形式であると判定した場合には、例えば図９に示すように、まず、ファイルが展開可能であるか否かを判定し（Ｓ２１）、展開不可能であれば表示部４５にその旨のメッセージ（例えばファイルが破壊されたことを示す破壊アイコン等）を表示させる（Ｓ２２）。データファイルを展開可能な場合には、ファイル形式判定部１ａは、プロパティとして当該データファイルがＰＮＧファイルである旨を表示させる（Ｓ２３）。
【００５５】
この後、ファイル形式判定部１ａは、当該データファイルの拡張子に基づいてファイルの利用制限の有無を判定する（Ｓ２４〜Ｓ２６）。具体的には、拡張子が「．ｐｎｇ」であるか否かを判断し（Ｓ２４）、「．ｐｎｇ」である場合には利用制限を「転送可・登録保存可、下位端末に転送可」として利用制限部２ａに通知する（Ｓ２５）。拡張子が「．ｐｎｇ」でなければ、利用制限を「転送不可・登録保存可、下位端末に転送不可」として利用制限部２ａに通知する（Ｓ２６）。これにより、例えば「．ｃｇｉ」等の上述以外の拡張子のデータファイルを受信した場合には一律で「転送不可・登録保存可、下位端末に転送不可」となる。
【００５６】
また、上述の図７中のＳ６において、ファイル形式判定部１ａがファイル保持部４２に格納されているデータファイルがＪＰＥＧ形式であると判定した場合には、例えば図１０に示すように、まず、ファイルが展開可能であるか否かを判定し（Ｓ３１）、展開不可能であれば表示部４５にその旨のメッセージ（例えばファイルが破壊されたことを示す破壊アイコン等）を表示させる（Ｓ３２）。データファイルを展開可能な場合には、ファイル形式判定部１ａは、プロパティとして当該データファイルがＪＰＥＧファイルである旨を表示させる（Ｓ３３）。
【００５７】
この後、ファイル形式判定部１ａは、当該データファイルの拡張子に基づいてファイルの利用制限の有無を判定する（Ｓ３４〜Ｓ３６）。具体的には、拡張子が「．ｊｐｇ」，「．ｊｐｅｇ」あるいは「．ｊｐｅ」のいずれかであるか否かを判断し（Ｓ３４）、これらの拡張子に該当する場合には利用制限を「転送可・登録保存可、下位端末に転送可」として利用制限部２ａに通知する（Ｓ３５）。データファイルの拡張子がこれらのいずれにも該当しなければ、利用制限を「転送不可・登録保存可、下位端末に転送不可」として利用制限部２ａに通知する（Ｓ３６）。これにより、例えば「．ｃｇｉ」等の上述以外の拡張子のデータファイルを受信した場合には一律で「転送不可・登録保存可、下位端末に転送不可」となる。
【００５８】
（効果）
上述のように、この情報通信システムでは、携帯電話端末装置４０において、ＰＮＧ形式，ＪＰＥＧ形式，ＳＭＤ形式のデータファイルの利用制限をこれらのデータファイルの拡張子によって決定するようにしたため、ＨＴＴＰサーバ１１あるいは情報提供サーバ５１において、データ保持部１２，５２にデータファイルを格納する際に当該データファイルの利用制限に応じた拡張子として保存すれば、携帯電話端末装置４０側における当該データファイルの利用を制限させることができる。すなわち、この情報通信システムでは、ＨＴＴＰを実装していない携帯電話端末装置であっても、データファイルの利用制限を容易に実現することができる。
【００５９】
この情報通信システムでは、上述のように、データファイルの利用制限を実現できるため、コンテンツの著作権保護に寄与することができる。具体的には、例えば有料で提供するコンテンツについては、「転送不可」とすることで複製等を制限することでき、試聴等の目的で無料で提供するコンテンツについてはさらに、「登録保存不可」とすれば、目的外の再利用を制限することができる。このように、利用形態に応じたコンテンツの利用の制限を実現することにより、著作権の保護の容易化に寄与することができる。
【００６０】
また、上述のＳＭＡＦ形式のデータファイルについては、当該データファイル中の転送制御部分によって利用制限を定義すれば、携帯電話端末装置４０側において、当該転送制御部分に応じた利用制限を実現することができる。
【００６１】
具体的には、例えばＳＭＡＦ形式のデータファイル中に、コンテンツのクラスを示すコンテンツクラス（Ｃｏｎｔｅｎｔｓ Ｃｌａｓｓ）とコンテンツの型を示すコンテンツタイプ（Ｃｏｎｔｅｎｔｓ Ｔｙｐｅ）が含まれている。コンテンツクラスの値は、定義されている値と、未定義の値（Ｒｅｓｅｒｖｅｄ）とがあり、定義されている値に対応するクラスはファイル処理部１ｂに実装されているものとする。
【００６２】
また、コンテンツタイプの値は、「００」〜「０Ｆ」及び「３０」〜「３３」がＳｃｏｒｅ Ｔｒａｃｋ ＣｈｕｎｋとＰＣＭ Ａｕｄｉｏ Ｔｒａｃｋ Ｃｈｕｎｋのデータを含む着信メロディに対応しており、「１０」〜「１Ｆ」及び「４０」〜「４２」が文字データとＳｃｏｒｅ Ｔｒａｃｋ Ｃｈｕｎｋ又はＰＣＭ Ａｕｄｉｏ Ｔｒａｃｋ ＣｈｕｎｋとＧｒａｐｈｉｃｓ Ｔｒａｃｋ Ｃｈｕｎｋのデータを含むカラオケ系に対応しており、「２０」〜「２Ｆ」及び「５０」〜「５３」がカラオケ系と同様のデータを含むＣＭ（コマーシャル）系に対応しており、これら以外の未使用値が予約（Ｒｅｓｅｒｖｅｄ）とされている。
【００６３】
また、ＳＭＡＦ形式のデータファイルには、コピー状態を示す１バイトのコピーステータス（Ｃｏｐｙ Ｓｔａｔｕｓ）が含まれている。このコピーステータスの最下位ビット（ｂ０）は転送の可否を示しており、値が“０”のときは転送可，“１”のときは転送不可の状態を示している。また、下から２ビット目（ｂ１）は保存の可否を示しており、値が“０”のときは保存可，“１”のときは保存不可の状態を示している。
【００６４】
上述の図７中のＳ７において、ファイル形式判定部１ａがファイル保持部４２に格納されているデータファイルがＳＭＡＦ形式であると判定した場合には、例えば図１１に示すように、まず、当該データファイル中のコンテンツクラスが「Ｒｅｓｅｒｖｅｄ」であるか否かを判定し（Ｓ４１）、「Ｒｅｓｅｒｖｅｄ」であるときは表示部４５に未対応である旨を表示させる（Ｓ４３）。
【００６５】
コンテンツクラスが「Ｒｅｓｅｒｖｅｄ」でない場合には、ファイル形式判定部１ａは、コンテンツタイプが、上述の着信メロディ，カラオケ系，ＣＭ系のいずれかに該当するか否か、すなわちファイル処理部１ｂで対応可能か否かを判定し（Ｓ４２）、対応可能でなければ表示部４５に未対応である旨を表示させる（Ｓ４３）。
【００６６】
対応可能である場合には、ファイル形式判定部１ａは、データファイル中のコピーステータスの下から２ビット目（ｂ１）が“１”であるか否かを確認する（Ｓ４４）。ｂ１が“１”であれば当該データファイルの利用制限を「登録保存不可」として利用制限部２ａに通知し（Ｓ４５）、そうでなければ利用制限を「登録保存可」として利用制限部２ａに通知する（Ｓ４６）。
【００６７】
さらに、ファイル形式判定部１ａは、コピーステータスの最下位ビット（ｂ０）が“１”であるか否かを確認する（Ｓ４７）。ｂ０が“１”であれば当該データファイルの利用制限を「転送不可」として利用制限部２ａに通知し（Ｓ４９）、そうでなければ利用制限を「転送可」として利用制限部２ａに通知する（Ｓ４８）。
【００６８】
上述のように利用制限が利用制限部２ａに通知されると、ファイル管理部２は、利用制限部２ａの指示に従ってファイル保持部４２に保持されたデータファイルの利用を制限する。
【００６９】
なお、上述のように利用制限のあるコンテンツをＨＴＴＰサーバ１１によって提供する場合には、ネットワーク２０に接続されている携帯電話端末装置４０以外の情報処理装置上で実行されるＷｅｂブラウザ等から利用されないように、ＨＴＴＰサーバ１１側において、相手が携帯電話端末装置４０である場合にのみ利用制限のあるデータファイルを送信するようにすることが望ましい。
【００７０】
（変形例）
ところで、ＨＴＴＰを実装している端末においても、サーバ側から通知されたファイル形式がコンテントタイプ「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｃｔｅｔ−ｓｔｒｅａｍ」あるいは「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｐｌａｉｎ」等のワイルドカードであった場合に、上述と同様に、供給されたファイルのシグネチャに応じてファイル判定処理を行うこともできる。
【００７１】
これらの「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｏｃｔｅｔ−ｓｔｒｅａｍ」あるいは「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｐｌａｉｎ」等のワイルドカードは、ＨＴＴＰサーバ側においてデフォルト（省略時）として設定される可能性があるため、ＨＴＴＰサーバ側で未設定のファイル形式のデータファイルのコンテントタイプとして指定される可能性がある。
【００７２】
このようなコンテントタイプが指定された場合には、Ｗｅｂブラウザでコンテントタイプによってファイル形式を判定することはできないが、上述のようにシグネチャによってファイル形式を判定すれば、実際のデータファイルのファイル形式をより正確に判定することができる。
【００７３】
なお、パーソナルコンピュータ等の汎用の情報処理装置では、ユーザがＷｅｂブラウザの設定を変更して、特定のファイル形式のデータファイルを表示するアプリケーションを選択したり、起動するアプリケーションを選択したりできる。しかしながら、小型の情報端末装置では、これらの設定の変更をするユーザインタフェースの実装が困難であったり、ＭＰＵの処理能力不足のためにＨＴＴＰを実装できない場合がある。このような場合に、本発明を適用すれば、データファイルのファイル形式を確実に判定することができ、データファイルの表示あるいは起動すべき適切な処理を容易に選択することができる。
【００７４】
【発明の効果】
本発明では、情報通信端末装置の判定手段が、取得手段が取得したデータファイル中のシグネチャに応じて当該データファイルのファイル形式を判定することができる。このため、移動体通信網における伝送プロトコル上でファイル形式を通知しなくても、情報通信端末装置側でファイル形式を正確に判定することができる。
【００７５】
さらに、情報通信端末装置に判定手段による判定結果及びデータファイルの拡張子に応じて当該データファイルの利用を制限する利用制限手段を設けることにより、拡張子に応じてデータファイルの利用制限を実現することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る情報通信システムの構成例を示す図である。
【図２】前記情報通信システムにおける携帯電話端末装置とサーバ装置の間の通信の例示すシーケンス図である。
【図３】前記サーバ装置からゲートウェイ装置に送信される応答メッセージの例を示す図である。
【図４】前記ゲートウェイ装置に前記携帯電話端末装置に送信される応答メッセージの例を示す図である。
【図５】前記携帯電話端末装置のＷｅｂブラウザが取得するデータファイルの構造の例を示す図である。
【図６】前記データファイル中のシグネチャの例を示す図である。
【図７】前記携帯電話端末装置のファイル形式判定部におけるファイル形式の判定処理の例を示すフローチャートである。
【図８】ファイル利用制限処理の詳細を示すフローチャートである。
【図９】ファイル利用制限処理の詳細を示すフローチャートである。
【図１０】ファイル利用制限処理の詳細を示すフローチャートである。
【図１１】ファイル利用制限処理の詳細を示すフローチャートである。
【符号の説明】
１…Ｗｅｂブラウザ、１ａ…ファイル形式判定部、１ｂ…ファイル処理部、２…ファイル管理部、２ａ…利用制限部、３…メール処理部、１０…ＨＴＴＰサーバ装置、１１…ＨＴＴＰサーバ、１２，５２…データ保持部、１３，５３…実行環境、２５…ゲートウェイ装置、３０…移動体通信網、３１…回線交換機、３３…パケット交換機、３５…ＳＭＳＣ、３２ａ，３２ｂ，…，３２ｎ…基地局装置、４０…携帯電話端末装置、４１…通信制御部、４２…ファイル保持部、５０…ＰＵＳＨサーバ装置、５１…情報提供サーバ
Claims (5)
- ファイル形式毎に固有の情報（シグネチャ）を含むデータファイルを移動体通信網を介して取得する取得手段と、
該取得手段が取得したデータファイル中のシグネチャに応じて当該データファイルのファイル形式を判定する判定手段と
を備えることを特徴とする情報通信端末装置。 - 前記ファイル形式は、前記データファイルの先頭にシグネチャが含まれる第１のファイル形式群と、前記データファイルの途中にシグネチャが含まれる第２のファイル形式群とからなり、
前記判定手段は、第２のファイル形式群内のファイル形式であるか否かを判定した後に、第１のファイル形式群内のファイル形式であるか否かを判定して、前記ファイル形式の判定を行うことを特徴とする請求項１記載の情報通信端末装置。 - 前記データファイルには、予め利用制限状態に応じた拡張子を有するファイル名が付与されており、
前記判定手段による判定結果及び前記データファイルの拡張子に応じて当該データファイルの利用を制限する利用制限手段を備えることを特徴とする請求項１又は請求項２記載の情報通信端末装置。 - 移動体通信網を介して、情報提供サーバ装置から情報通信端末装置にファイル形式毎に固有の情報（シグネチャ）を含むデータファイルを提供する情報通信システムであって、
前記情報通信端末装置は、提供されたデータファイル中のシグネチャに応じて当該データファイルのファイル形式を判定する判定手段を備えることを特徴とする情報通信システム。 - 前記情報提供サーバ装置が提供する前記データファイルには、予め利用制限状態に応じた拡張子を有するファイル名が付与されており、
前記判定手段は、前記判定手段による判定結果及び前記データファイルの拡張子に応じて当該データファイルの利用を制限する利用制限手段を備えることを特徴とする請求項４記載の情報通信システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003005064A JP4005513B2 (ja) | 2003-01-10 | 2003-01-10 | 情報通信端末装置及び情報通信システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003005064A JP4005513B2 (ja) | 2003-01-10 | 2003-01-10 | 情報通信端末装置及び情報通信システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004220203A true JP2004220203A (ja) | 2004-08-05 |
| JP4005513B2 JP4005513B2 (ja) | 2007-11-07 |
Family
ID=32895828
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003005064A Expired - Fee Related JP4005513B2 (ja) | 2003-01-10 | 2003-01-10 | 情報通信端末装置及び情報通信システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4005513B2 (ja) |
-
2003
- 2003-01-10 JP JP2003005064A patent/JP4005513B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP4005513B2 (ja) | 2007-11-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4189627B2 (ja) | 画像サーバ並びに画像表示システム | |
| PT1240754E (pt) | Serviço de mensagens multimédia | |
| FI20011342A0 (fi) | Menetelmä ja laite tiedon hankkimiseksi | |
| JP2004531805A (ja) | 電気通信システムにおけるアプリケーション・データの同期 | |
| CN101730999B (zh) | 用于在通信设备之间共享公共位置相关信息的系统、方法及设备 | |
| JP2006048529A (ja) | ダウンロード方法、ダウンロードシステム、クライアント装置及びサーバ装置 | |
| JP2003091376A (ja) | ポータブルワイヤレスデバイスおよび印刷装置のリファレンスによる印刷プロトコル | |
| JP2001320424A (ja) | 無線端末 | |
| JP4303101B2 (ja) | 通信端末およびプログラム | |
| WO2006098245A1 (ja) | 情報処理端末、コンテンツ提供システム、コンテンツ提供方法およびコンテンツ提供プログラム | |
| JP4005513B2 (ja) | 情報通信端末装置及び情報通信システム | |
| JP3889737B2 (ja) | デジタル無線電話によるメッセージ通信システム | |
| US20060069790A1 (en) | Content presentation adaptation | |
| JP4436177B2 (ja) | 検索装置 | |
| JP4242821B2 (ja) | 移動体通信端末 | |
| JP4980563B2 (ja) | コンテンツ提供方法、コンテンツ取得時の通信方法、移動体通信端末、コンテンツ提供サーバ及び通信中継サーバ | |
| JP4416624B2 (ja) | 移動体通信端末 | |
| JP3786635B2 (ja) | 情報提供システム | |
| JP2006155506A (ja) | コンテンツ提供方法、移動体通信端末及びコンテンツ提供サーバ | |
| JP3615118B2 (ja) | 移動体通信端末装置 | |
| JP4527494B2 (ja) | 移動体通信端末 | |
| JP2006157417A (ja) | メディアオブジェクト提供方法、移動体通信端末及びメディアオブジェクト提供サーバ | |
| JP2004164663A (ja) | 受信システム | |
| JP2001159995A (ja) | ファイル転送方法、ファイル受信装置、及びファイル提供装置 | |
| JP2003280828A (ja) | ネットワークシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070529 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070726 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070821 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070823 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100831 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120831 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |