JP3692290B2

JP3692290B2 - データ取得方法および端末

Info

Publication number: JP3692290B2
Application number: JP2000358046A
Authority: JP
Inventors: 和宏山田; 正明山本; 孝朗平松; 恭子井上; 大神谷; 江利子大関; 元紀徳田; 達郎大井; 豊鷲見
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2000-11-24
Filing date: 2000-11-24
Publication date: 2005-09-07
Anticipated expiration: 2020-11-24
Also published as: CN1395704A; DE60126421T2; TWI222817B; JP2002163111A; BR0107377A; NZ519408A; AU2406202A; KR100436687B1; NO20023491L; CN1198432C; EP1338971A1; US20030097373A1; DE60126421D1; CA2394294C; WO2002042918A1; EP1338971A4; PL356885A1; CA2394294A1; AU2002224062B8; HK1056024A1

Description

【０００１】
【発明の属する技術分野】
本発明は、ネットワークを介してデータを取得するデータ取得方法と、この方法を用いてデータを取得する端末とに関する。
【０００２】
【従来の技術】
インターネット等のネットワークを介したデータの取得（ダウンロード）が広く行われている。このようなデータの取得では、通常、データは端末において再利用可能に格納される。なお、本明細書において、「再利用可能」とは、再起動された端末において再起動前に取得したデータを新たに取得することなく利用できることを意味している。すなわち、再利用可能なデータは例えばハードディスク等の不揮発性メモリに格納される。
【０００３】
また、近年、端末においてデータを再利用不可能に取得することも行われている。このように取得されるデータとしてはＪａｖａアプレットが挙げられる。ＪａｖａアプレットはＪａｖａのプログラム（Ｊａｖａアプリケーション）の一種であり、ネットワークを介して再利用不可能に取得され、ＨＴＭＬ（Hyper Text Markup Language）により記述されたページを閲覧するブラウザおよびＪａｖａ仮想マシン上で実行される。データを再利用不可能に取得する方法としては、例えば、取得したデータをＲＡＭ（Random Access Memory）等の揮発性メモリに格納し、端末の再起動前に揮発性メモリ上のデータが消去されるようにする方法が挙げられる。
【０００４】
なお、一般に、Ｊａｖａアプリケーションには、Ｊａｖａアプレットと異なり、再利用可能に取得されるものも存在する。また、予め端末の不揮発性メモリに格納され、ネットワークからの取得を必要としないＪａｖａアプリケーションも存在する。しかし、本発明はネットワークからのデータ取得を前提としていることから、本明細書における「Ｊａｖａアプリケーション」はネットワークから取得されるものとする。
【０００５】
【発明が解決しようとする課題】
ところで、再利用可能にせよ不可能にせよ、データの取得はファイル単位で行われるのが普通である。例えば、１つのファイルからなるＪａｖａアプリケーションを取得は１回のデータ交換（トランザクション）により実現される。すなわち、利用者が端末を操作してＪａｖａアプリケーションの取得を指示すると、即座に当該Ｊａｖａアプリケーションの取得が開始され、Ｊａｖａアプリケーション全体の取得が完了するまで、端末には例えばファイルを取得中である旨が表示されることになる。
【０００６】
このような取得形態では、Ｊａｖａアプリケーションのサイズ等の属性情報を端末の利用者が取得開始前に知ることができず、端末の動作が使用者の予想を超えた長時間にわたって制限されてしまう虞がある。このことは特にブラウザを搭載した携帯電話機等の通信帯域や処理能力が著しく制限された端末において極めて重大である。もちろん、Ｊａｖａアプリケーションのファイル名やサイズ等の属性情報をページに記述し、利用者に対して当該Ｊａｖａアプリケーションの取得前に必要な属性情報を通知するようにしてもよいが、誤記や悪意により、不正な属性情報が利用者に通知される虞もある。
【０００７】
そこで、Ｊａｖａアプリケーションを、属性情報を有するＡＤＦとデータ実体を有するＪａｒとの２つのファイルに分離し、端末においてはこれらを順に取得することで上述の不都合を回避することが提案されている。なお、Ｊａｒは一つまたは複数のファイルを一つにまとめた形式のファイルであり、Ｊａｒ単独でも、ある程度の取得時間の短縮が図られている。しかしながら、ＡＤＦとＪａｒの２つのファイルに分割した場合にセキュリティの確保が困難になることについては全く留意されていないのが実情である。
【０００８】
本発明は上述した事情に鑑みて為されたものであり、分割されたデータの取得時に十分に高いセキュリティを確保することができるデータ取得方法および端末を提供することを目的としている。
【０００９】
【課題を解決するための手段】
上述した課題を解決するために、請求項１に記載のデータ取得方法は、ネットワークを介して通信可能な端末においてデータの属性情報を格納した第１のデータ単位と前記データの実体を格納した第２のデータ単位とを前記ネットワーク側から受信することにより前記データを取得するデータ取得方法であって、前記第１のデータ単位を受信する第１受信ステップと、前記第１受信ステップにおいて使用された通信方式と前記第２のデータ単位の受信時に使用される通信方式とに基づいて前記データの取得の可否を判定する判定ステップと、前記判定ステップにおける判定結果が「可」の場合には前記第２のデータ単位を受信し、「否」の場合には前記第２のデータ単位を受信しない第２受信ステップとを有することを特徴としている。
【００１０】
さらに、上記方法において、前記判定ステップでは、前記第２のデータ単位の受信時に使用される通信方式の安全性が前記第１受信ステップにおいて使用された通信方式の安全性よりも低い場合には前記データの取得を「否」とする、ようにしてもよいし（請求項２）、前記判定ステップでは、前記第１受信ステップにおいて使用された通信方式と前記第２のデータ単位の受信時に使用される通信方式とが不一致の場合には前記データの取得を「否」とする、ようにしてもよい（請求項３）。
【００１１】
また、請求項４に記載のデータ取得方法は、請求項１乃至３のいずれかに記載のデータ取得方法において、前記データを前記端末にて実行可能なコンピュータプログラムとすることを特徴としている。さらに、請求項４に記載のデータ取得方法において、前記コンピュータプログラムを、通信を行うコンピュータプログラムとしてもよい（請求項５）。
さらに、請求項６に記載のデータ取得方法は、請求項１乃至５のいずれかに記載のデータ取得方法において、前記端末を携帯電話機とすることを特徴としている。
【００１２】
また、請求項７に記載の端末は、データの属性情報を格納した第１のデータ単位と前記データの実体を格納した第２のデータ単位とをネットワーク側から受信することにより前記データを取得する端末であって、前記第１のデータ単位を受信する第１受信手段と、前記第１受信手段による前記第１のデータ単位の受信時に使用された通信方式と前記第２のデータ単位の受信時に使用される通信方式とに基づいて前記データの取得の可否を判定する判定手段と、前記判定手段による判定結果が「可」の場合には前記第２のデータ単位を受信し、「否」の場合には前記第２のデータ単位を受信しない第２受信手段とを具備することを特徴としている。
【００１３】
【発明の実施の形態】
以下、図面を参照して、本発明の実施形態について説明する。
【００１４】
＜基本思想＞
まず、本実施形態におけるデータ取得方法の基本思想について説明する。
図１は本実施形態に係る端末の基本的な状態遷移を示す図であり、この図に示すように、Ｊａｖａアプリケーションの取得および実行において、端末の状態は状態Ａ、Ｂ、Ｃ、Ｄの順に遷移する。すなわち、まず、端末はＪａｖａアプリケーションを取得するためのページの取得要求をネットワークへ送出し、該当するページを取得する（状態Ａ）。この状態において、利用者が端末を操作して当該ページに記述されたＪａｖａアプリケーションを取得する旨の指示を入力すると、端末は当該指示に応じた取得要求をネットワークへ送出し、該当するＪａｖａアプリケーションのＡＤＦを再利用可能に取得する（状態Ｂ）。次に、端末は当該ＡＤＦに対応したＪａｒの取得要求をネットワークへ送出し、該当するＪａｒを再利用可能に取得する（状態Ｃ）。次に、利用者が端末を操作し、取得したＪａｖａアプリケーション（Ｊａｒが内包したプログラム）の実行を指示すると、端末において該当するＪａｖａアプリケーションが実行される。
【００１５】
基本的な状態遷移は上述の通りであるが、各状態に至る通信方式に応じて条件が加わる。例えば、状態Ａ〜Ｃまで同一の通信方式の通信が行われる場合と、状態Ａまでは暗号化されていない通常の通信方式の通信が行われ、以後、状態ＣまではＳＳＬ（Secure Sockets Layer）による暗号化通信方式の通信が行われる場合とでは端末の動作が異なる。このような条件に応じた端末の動作について以下に説明する。
【００１６】
図２は本実施形態に係る端末の状態の遷移パターンを示す図であり、この図に示すように、端末の状態遷移のパターンとしては遷移パターンＰ１〜Ｐ８が考えられる。遷移パターンＰ１〜Ｐ８は状態Ａ〜Ｃの各通信方式（通常／ＳＳＬ）の順列の全バリエーション（２×２×２＝８通り）である。
【００１７】
図３は本実施形態に係る端末の表示メッセージを示す図である。この図においては、遷移パターンＰ１〜Ｐ８に対応して、状態Ａから状態Ｂへの遷移開始時の表示メッセージと、状態Ｂから状態Ｃへの遷移開始時の表示メッセージとが示されており、これらの表示メッセージから端末の動作を特定することができる。また、この図には、各遷移パターンに対応して、状態Ａから状態Ｂへの遷移形式と、状態Ｂから状態Ｃへの遷移形式とが対応付けられており、表示メッセージは、通信パターンと各遷移形式に対応している。ただし、遷移形式に依存せずに表示メッセージが決まることもあり、そのような遷移形式の欄には「−」が記載されている。なお、遷移形式はデータ交換形式であり、トランザクションをクローズしないkeep-alive（キープアライブ）形式と、トランザクションをクローズする非keep-alive形式とがある。非keep-alive形式はＨＴＴＰ（HyperText Transfer Protocol）における通常の形式であり、keep-alive形式はＳＳＬに対応したＨＴＴＰＳにおいて通常の形式である。
【００１８】
本実施形態ではこの図に示す動作が実現されており、その動作については後に詳述することから、ここでは図の見方を説明する目的で動作の一例を説明する。例えば、遷移パターンＰ６（状態Ａ〜Ｃにおける通信形式が共通してＳＳＬの遷移パターン）に着目すると、状態Ａから状態Ｂへの遷移形式が非keep-aliveの場合、状態Ａから状態Ｂへの遷移開始時の表示メッセージは「ＳＳＬ通信を開始します」となり、さらに状態Ｂから状態Ｃへの遷移形式がkeep-aliveの場合、状態Ｂから状態Ｃへの遷移開始時の表示は行われない。
【００１９】
この図において最も特徴的な点は、遷移パターンＰ３およびＰ４については状態Ｂから状態Ｃへの遷移を不許可とする点である。図２に示されるように、遷移パターンＰ３およびＰ４では、状態Ｂの通信方式がＳＳＬであり、かつ状態Ｃの通信方式が通常である。すなわち、本実施形態では、暗号化通信方式の通信によりＡＤＦを取得し、続いて通常の通信方式の通信によりＪａｒを取得するような取得パターンを許容していない。このようにしている理由について以下に説明する。
【００２０】
通常、Ｊａｖａアプリケーションをネットワークから取得した場合、このＪａｖａアプリケーションの通信方式は自身の取得時の通信方式となる。例えば、ＳＳＬの通信により取得されたＪａｖａアプリケーションを実行し、このＪａｖａアプリケーションがネットワーク経由で通信する場合、その通信方式はＳＳＬに限定される。このような前提があるため、端末側では、Ｊａｖａアプリケーションの取得時の通信方式がＳＳＬであれば、以後、当該Ｊａｖａアプリケーションが通信を行ったとしても利用者の個人情報等が平文で送信されることはない、と判断できる。
【００２１】
ところで、本実施形態のように、ＡＤＦおよびＪａｒを使用してＪａｖａアプリケーションをネットワークから取得する場合、当該ＪａｖａアプリケーションはＪａｒの取得時の通信方式で通信を行うことになる。すなわち、遷移パターンＰ３およびＰ４のように、ＡＤＦ取得時の通信方式がＳＳＬであり、かつＪａｒ取得時の通信方式が通常の場合には、当該Ｊａｒに内包されたＪａｖａアプリケーションは通常の通信方式で通信を行うことになる。
【００２２】
しかしながら、利用者は、ＡＤＦ取得時の通信方式がＳＳＬであればＪａｒ取得時の通信方式もＳＳＬであろう、と推定しがちであり、利用者の個人情報等が利用者の意に反して平文で送信されてしまう虞がある。このような事態を回避するために、図３に示すように、遷移パターンＰ３およびＰ４において状態Ｂから状態Ｃへの遷移が許容されていないのである。なお、図２において、遷移パターンＰ１およびＰ２でも状態Ｂの通信方式と状態Ｃの通信方式は異なっているが、端末において実行されたＪａｖａアプリケーションが送信するデータは利用者が意図しているよりも強力に保護されることになるため、本実施形態ではこれらの遷移パターンを許容している。
【００２３】
＜構成＞
次に、本実施形態に係る端末Ｔを用いたデータ配信システムについて説明する。
図４は端末Ｔを用いたデータ配信システムの構成を示すブロック図であり、この図に示すように、本データ配信システムは、ＷＷＷ（World Wide Web）の利用を端末Ｔに許容したシステムである。
【００２４】
この図において、端末Ｔは移動パケット通信網ＭＰＮのパケット通信サービスを受ける端末であり、移動パケット通信網ＭＰＮ及び図示せぬ移動電話網に無線接続される携帯電話機である。移動電話網は一般的な移動電話の通話サービスを提供する網であり、端末Ｔは当該通話サービスを受けることができる。端末Ｔの詳細な機能及び構成については後述する。
【００２５】
移動パケット通信網ＭＰＮは、複数の基地局ＢＳ、複数のパケット加入者処理装置ＰＳ、ゲートウェイサーバＧＷＳ、及びこれらを接続する通信回線によって構成されている。
【００２６】
基地局ＢＳは、地上を例えば半径５００ｍ等の範囲で分割した所定間隔で配置されており、各々が形成する無線ゾーンに在圏した端末Ｔとの間で無線通信を行う。
【００２７】
パケット加入者処理装置ＰＳは、複数の基地局ＢＳを収容するパケット加入者交換局に備えられたコンピュータシステムであり、端末Ｔからのパケット交換要求を受け付けるとともに、受け付けたパケットを他のパケット加入者処理装置ＰＳ及び配下の基地局ＢＳの少なくとも一方を介して宛先の端末Ｔへ中継する。
【００２８】
ゲートウェイサーバＧＷＳは、移動パケット通信網ＭＰＮとインターネットＩＮＥＴ等の他網とを相互接続するための移動パケット関門中継交換局に備えられたコンピュータシステムであり、ネットワーク間で異なる通信プロトコルの変換を行う。ここでいう通信プロトコルの変換とは、具体的には、移動パケット通信網ＭＰＮが従う移動パケット通信網用の伝送プロトコルと、インターネットＩＮＥＴが従う伝送プロトコルとの相互変換をいう。
【００２９】
なお、インターネットＩＮＥＴが従う伝送プロトコルには、ネットワーク層及びトランスポート層のＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）とこのＴＣＰ／ＩＰ上で実現されるＨＴＴＰやＨＴＴＰＳ等のプロトコルが含まれており、移動パケット通信網ＭＰＮが従う伝送プロトコルには、ＴＣＰ／ＩＰを簡素化したプロトコル（以後、ＴＬ）とＨＴＴＰ（およびＨＴＴＰＳ）に相当するプロトコル（以後、ＡＬ）とが含まれている。すなわち、端末ＴはＡＬ上でＷＷＷを利用することになる。
【００３０】
また、ゲートウェイサーバＧＷＳは、端末ＴからＨＴＴＰ（あるいはＨＴＴＰＳ）のＧＥＴ要求を受け取ると、当該ＧＥＴ要求に含まれるＵＲＬ（Uniform Resource Locator）を調べ、当該ＵＲＬがインターネットＩＮＥＴ上の一般的なＵＲＬである場合には、インターネットＩＮＥＴへ当該ＧＥＴ要求を転送し、このＧＥＴ要求に対応してインターネットＩＮＥＴから送信されてきた応答を当該端末Ｔへ返送する。なお、ＧＥＴ要求に含まれるＵＲＬが自身内のリソース位置を示すものの場合には、ゲートウェイサーバＧＷＳは、当該ＧＥＴ要求に対応して該当リソースを端末Ｔへ返送する。
【００３１】
ＩＰサーバＷはインターネットＩＮＥＴに接続されたサーバであり、ＷＷＷを利用するクライアントに対してＷＷＷサービスを提供する。具体的には、ＩＰサーバＷは、インターネットＩＮＥＴ経由でＨＴＴＰ（あるいはＨＴＴＰＳ）のＧＥＴ要求を受け取ると、当該ＧＥＴ要求に含まれるＵＲＬで特定されるリソース（本実施形態では著作物ファイル）を返送する。なお、本実施形態においては、ＩＰサーバＷはＪａｖａアプリケーションを配信するものであり、ＩＰサーバＷと端末Ｔとの間の全ての通信はＨＴＴＰ（およびＨＴＴＰＳ）およびＡＬにより行われるようになっている。また、ＩＰサーバＷおよび端末Ｔは共に、ＨＴＴＰ（およびＨＴＴＰＳ）におけるkeep-alive／非keep-aliveとＨＴＴＰＳにおけるＳＳＬに対応している。
【００３２】
次に、端末Ｔの構成について説明する。ただし、ここでは、本発明に直接的に関連する要部の構成について説明する。
図５は端末Ｔの要部の構成を示すブロック図であり、この図に示すように、端末Ｔは、基地局ＢＳとの無線通信を行う送受信部（例えばアンテナ、無線部、送信機、受信機等を有する）１１、発音するための発音部（例えば音源やスピーカ等から構成される）１２、数字入力、文字入力等の入力操作が行われる、キーパッド等を備えた入力部１３、所定サイズの表示領域を有する液晶ディスプレイ１４、これら各部を制御する制御部１５を内蔵している。
【００３３】
制御部１５は各種制御を行うＣＰＵ（Central Processing Unit）１５１と、ＣＰＵ１５１に実行されるブラウザ、Ｊａｖａ仮想マシンを実現するソフトウェア、端末Ｔの制御プログラム等のソフトウェア、ゲートウェイサーバＧＷＳとの接続に必要な情報、および後述する処理テーブルＰＴ１，ＰＴ２等を格納したＲＯＭ（Read Only Memory）１５２と、受信したデータや利用者の設定内容（例えばＪａｒの自動取得の可否）等を再利用可能に格納するフラッシュメモリ１５３と、受信したデータを再利用不可能に格納するとともにＣＰＵ１５１のワークメモリとして使用されるＲＡＭ（Random Access Memory)１５４とを内蔵している。
【００３４】
ＣＰＵ１５１は、図示せぬ電源が投入されると、ＲＯＭ１５２に格納された制御プログラムを読み出して実行し、制御プログラムおよび入力部１３から入力される利用者の指示に従ってＲＯＭ１５２、ＳＲＡＭ１５３、ＲＡＭ１５４、各部１１〜１３、及び液晶ディスプレイ１４を制御する。また、ＣＰＵ１５１は、入力部１３から入力される利用者の指示に従って、ブラウザを起動し、このブラウザ上で入力部１３からの指示に応じた通信を行う機能を有する。さらに、ＣＰＵ１５１は、ＲＯＭ１５２に格納された処理テーブルＰＴ１，ＰＴ２（図６参照）に基づいて通信処理を制御する機能を有する。この機能による具体的な動作については後述する。
【００３５】
また、ＣＰＵ１５１は、ＳＲＡＭ１５３に格納したデータをＪａｖａアプリケーションとして実行する際にＪａｖａ仮想マシンを起動し、このＪａｖａ仮想マシン上で当該Ｊａｖａアプリケーションを実行する機能を有する。さらに、ＣＰＵ１５１は、ＲＡＭ１５４に格納したデータをＪａｖａアプリケーション（Ｊａｖａアプレット）として実行する際にＪａｖａ仮想マシンおよびブラウザを起動し、これらの上で当該Ｊａｖａアプリケーションを実行する機能を有する。
【００３６】
端末Ｔによるデータの取得は、まず、ＣＰＵ１５１がＲＯＭ１５２に格納されたブラウザを読み出し当該ブラウザを実行することにより、ＲＯＭ１５２に格納されたホームＵＲＬ（最初にアクセスすべきゲートウェイＧＷＳ上のリソース位置）からＨＴＭＬデータを取得し、このデータに基づいて、液晶ディスプレイ１５に対話画面（ページ）を表示させ、この対話画面を視認した利用者が入力部１３を操作することで行われる。
【００３７】
＜Ｊａｖａアプリケーション取得動作＞
図７はＪａｖａアプリケーションの取得時に端末Ｔが行う処理の流れを示すフローチャートであり、以下、主に図２、図３、図６および図７を参照し、端末ＴがＪａｖａアプリケーションをＩＰサーバＷから取得する動作について、遷移パターン毎に説明する。ただし、以降の説明において、遷移パターン間で重複する説明は極力省略されている。なお、端末Ｔにおいては既にブラウザが起動されているものとする。また、取得対象のＪａｖａアプリケーションの取得形態としては再利用可能／再利用不可能があるが、ここでは説明が繁雑になるのを避けるために、再利用可能に取得する例についてのみ説明する。
【００３８】
▲１▼遷移パターンＰ１の場合
図２に示されるように、遷移パターンＰ１の通信方式は、状態Ａおよび状態Ｂでは通常、状態ＣではＳＳＬとなる。
まず、端末Ｔは所望のＪａｖａアプリケーションを取得するためのページ（以後、ダウンロードページ）を取得する（ステップＳ１）。具体的には、端末ＴのＣＰＵ１５１（図５参照）が、入力部１３から入力された利用者の指示に基づいて送受信部１１を制御し、送受信部１１が当該指示に応じたＨＴＴＰ（あるいはＨＴＴＰＳ）のＧＥＴ要求をＩＰサーバＷ（図４参照）へ送信する。これに応答して、所望のダウンロードページのＨＴＭＬデータがＩＰサーバＷから返送される。このＨＴＭＬデータは送受信部１１に受信され、送受信部１１からＣＰＵ１５１へ渡される。ＣＰＵ１５１は当該ＨＴＭＬデータをＲＡＭ１５４に格納し、更にこれを解釈・実行することでユーザインタフェースを提供する。この結果、液晶ディスプレイ１４には当該ユーザインタフェースによる画面が表示される。
【００３９】
次に、端末Ｔは、利用者による指示の入力を待ち（ステップＳ２）、ここで入力された指示が所望のＪａｖａアプリケーションの取得指示でない場合には取得処理を終了する（ステップＳ３）。具体的には、端末ＴのＣＰＵ１５１は入力部１３から入力された指示と現在のユーザインタフェースとに基づいて利用者の指示内容を特定し、他のページの取得指示が入力された場合や図示せぬ電源の切断が指示された場合等の、Ｊａｖａアプリケーションの取得とは異なる内容の指示が入力された場合には取得処理を終了する。
【００４０】
逆に、ステップＳ２において入力された指示が所望のＪａｖａアプリケーションの取得を求めるものである場合には（ステップＳ３）、状態Ａから状態Ｂへの遷移パターンおよび遷移形式が特定され（ステップＳ４）、特定結果に応じた処理が行われるとともに、該当するＡＤＦが取得される（ステップＳ５）。ここでは、状態ＡおよびＢの通信方式は通常であることから、処理テーブルＰＴ１に従って、通常通信を継続してＡＤＦを取得する処理が行われる。この際、液晶ディスプレイ１４には表示メッセージとして「取得中」が表示される。なお、図６の処理テーブルＰＴ１から明らかなように、このケースでは遷移形式に関わらず処理内容が決定される。また、状態Ｂの通信方式はステップＳ４において端末ＴがＩＰサーバＷと通信することにより判明する。
【００４１】
ＡＤＦの取得が完了すると、Ｊａｒの自動取得が許可されていない場合には（ステップＳ６）、端末Ｔは継続してＪａｒを取得するか否かを利用者に問い合わせ（ステップＳ７）、この問い合わせに応じてＪａｒの取得を継続する旨の指示が入力されると（ステップＳ８）、ステップＳ９の処理へ進む。逆にＪａｒの取得を中断する旨の指示が入力されると中断処理が行われ（ステップＳ１２）、処理はステップＳ１に戻る。また、Ｊａｒの自動取得が許可されている場合には（ステップＳ６）、処理は即座にステップＳ９へ進む。
【００４２】
なお、端末Ｔは自動取得の許可／不許可を設定する機能を有し、ＣＰＵ１５１は入力部１３から入力された指示に応じてフラッシュメモリ１５３の所定ビットをセット／リセットする。したがって、当該ビットを参照することにより、ＣＰＵ１５１は自動取得の許可／不許可を知ることができる。また、ステップＳ９の中断処理では、ＣＰＵ１５１はフラッシュメモリ１５３に格納された該当するＡＤＦを破棄し、フラッシュメモリ１５３の記憶容量を有効に活用するようにしている。
【００４３】
次に、状態Ｂから状態Ｃへの遷移パターンおよび遷移形式が特定され（ステップＳ９）、特定結果に応じてＪａｒの取得処理が行われる（ステップＳ１０，Ｓ１１）。ここでは、状態Ｂの通信方式は通常であり、かつ状態Ｃの通信方式はＳＳＬであることから、処理テーブルＰＴ２に従い、新規にＳＳＬ通信を開始してＪａｒを取得する処理となる。この際、液晶ディスプレイ１４には表示メッセージとして「ＳＳＬ通信を開始します（認証中）」が表示される。このように、図３の遷移パターンＰ１に対応した処理が正しく行われる。なお、図６の処理テーブルＰＴ２から明らかなように、このケースでは遷移形式に関わらず処理内容が決定される。また、状態Ｃの通信方式はステップＳ９において端末ＴがＩＰサーバＷと通信することにより判明する。
【００４４】
▲２▼遷移パターンＰ２の場合
図２に示されるように、遷移パターンＰ２の通信方式は、状態Ｂでは通常、状態ＡおよびＣではＳＳＬとなる。
まず、ステップＳ１〜Ｓ５において、遷移パターンＰ１の場合と同様の処理が行われる。ただし、ここでは、状態Ａの通信方式はＳＳＬであり、かつ状態Ｂの通信方式は通常であることから、処理テーブルＰＴ１に従い、ＳＳＬ通信を終了し、通常通信によりＡＤＦを取得する処理が行われる。この際、液晶ディスプレイ１４には表示メッセージとして「ＳＳＬページを終了します」が表示される。
【００４５】
また、ステップＳ９以降においては、状態Ｂの通信方式は通常であり、かつ状態Ｃの通信方式はＳＳＬであることから、遷移パターンＰ１の場合と同一の処理が行われる。このように、図３の遷移パターンＰ２に対応した処理が正しく行われる。
【００４６】
▲３▼遷移パターンＰ３の場合
図２に示されるように、遷移パターンＰ３の通信方式は、状態ＡおよびＣでは通常、状態ＢではＳＳＬとなる。
まず、ステップＳ１〜Ｓ５において、遷移パターンＰ１の場合と同様の処理が行われる。ただし、ここでは、状態Ａの通信方式は通常であり、かつ状態Ｂの通信方式はＳＳＬであることから、処理テーブルＰＴ１に従い、新規にＳＳＬ通信を開始してＡＤＦを取得する処理となる。この際、液晶ディスプレイ１４には表示メッセージとして「ＳＳＬ通信を開始します（認証中）」が表示される。なお、たとえ遷移方式がkeep-aliveであったとしても、セッションをクローズすることなく通常の通信方式からＳＳＬの通信方式へ変更することは不可能であることから、ここでは、遷移形式に関わらず、新規にＳＳＬ通信を開始することになる。
【００４７】
次に、状態Ｂから状態Ｃへの遷移パターンおよび遷移形式が特定される（ステップＳ９）。ここでは、状態Ｂの通信方式はＳＳＬであり、かつ状態Ｃの通信方式は通常であることから、ステップＳ１０の判断結果が「ＹＥＳ」となり、処理はステップＳ１２の中断処理を経てステップＳ１に戻る。すなわち、所望のＪａｖａアプリケーションは取得されず、図３の遷移パターンＰ３に対応した処理が正しく行われる。
【００４８】
▲４▼遷移パターンＰ４の場合
図２に示されるように、遷移パターンＰ４の通信方式は、状態Ｃでは通常、状態ＡおよびＢではＳＳＬとなる。
まず、ステップＳ１〜Ｓ５において、遷移パターンＰ１の場合と同様の処理が行われる。ただし、ここでは、状態ＡおよびＢの通信方式はＳＳＬであることから、状態Ａから状態Ｂへの遷移形式に従った処理が行われる。すなわち、遷移形式が非keep-aliveの場合にはＳＳＬ通信を開始してＡＤＦを取得する処理が行われ、keep-aliveの場合にはＳＳＬ通信を継続してＡＤＦを取得する処理が行われる。なお、前者の場合には、液晶ディスプレイ１４に「ＳＳＬ通信を開始します」が表示され、後者の場合には、液晶ディスプレイ１４にメッセージは表示されない。keep-aliveの場合にメッセージが表示されないのは、ＳＳＬ通信のトランザクションが新たに開始される訳ではない為である。
【００４９】
また、状態Ｂの通信方式はＳＳＬであり、かつ状態Ｃの通信方式は通常であることから、遷移パターンＰ３の場合と同一の処理が行われる。このように、図３の遷移パターンＰ４に対応した処理が正しく行われる。
【００５０】
▲５▼遷移パターンＰ５の場合
図２に示されるように、遷移パターンＰ５の通信方式は、状態Ａでは通常、状態ＢおよびＣではＳＳＬとなる。
まず、ステップＳ１〜Ｓ５において、遷移パターンＰ３の場合と同一の処理が行われる。次に、ステップＳ９以降の処理においては、状態ＢおよびＣの通信方式がＳＳＬであることから、図６の処理テーブルＰＴ２に基づいて、状態Ｂから状態Ｃへの遷移形式に従った処理が行われる。すなわち、遷移形式が非keep-aliveの場合にはＳＳＬ通信を開始してＪａｒを取得する処理が行われ、keep-aliveの場合にはＳＳＬ通信を継続してＪａｒを取得する処理が行われる。なお、前者の場合には、液晶ディスプレイ１４に「ＳＳＬ通信を開始します」が表示され、後者の場合には、液晶ディスプレイ１４にメッセージは表示されない。このように、図３の遷移パターンＰ５に対応した処理が正しく行われる。
【００５１】
▲６▼遷移パターンＰ６の場合
図２に示されるように、遷移パターンＰ６の通信方式は、状態Ａ、ＢおよびＣにおいてＳＳＬとなる。
まず、ステップＳ１〜Ｓ５において、遷移パターンＰ４の場合と同一の処理が行われる。次に、ステップＳ９以降の処理においては、遷移パターンＰ５の場合と同一の処理が行われる。このように、図３の遷移パターンＰ６に対応した処理が正しく行われる。
【００５２】
▲７▼遷移パターンＰ７の場合
図２に示されるように、遷移パターンＰ７の通信方式は、状態Ａ、ＢおよびＣにおいて通常となる。
まず、ステップＳ１〜Ｓ５において、遷移パターンＰ１の場合と同一の処理が行われる。次に、ステップＳ９以降の処理においては、状態ＢおよびＣの通信方式が通常であることから、図６の処理テーブルＰＴ２に従い、通常通信を継続してＪａｒを取得する処理が行われる。この際、液晶ディスプレイ１４には表示メッセージとして「取得中」が表示される。このように、図３の遷移パターンＰ７に対応した処理が正しく行われる。
【００５３】
▲８▼遷移パターンＰ８の場合
図２に示されるように、遷移パターンＰ８の通信方式は、状態ＡではＳＳＬ、状態ＢおよびＣでは通常となる。
まず、ステップＳ１〜Ｓ５において、遷移パターンＰ２の場合と同一の処理が行われる。次に、ステップＳ９以降の処理においては、遷移パターンＰ７の場合と同一の処理が行われる。このように、図３の遷移パターンＰ８に対応した処理が正しく行われる。
【００５４】
＜補足＞
以上説明したように、本実施形態によれば、図２および図３に示す全ての遷移パターンに対応した処理が正しく行われ、暗号化通信方式の通信によりＡＤＦを取得し、続いて通常の通信方式の通信によりＪａｒを取得するようなＪａｖａアプリケーションの取得パターンを排除することができる。
【００５５】
また、上述した実施形態では、端末を携帯電話機としている点も効果的である。携帯電話機のデータ処理能力はノート型のコンピュータ等に比較して低く、その通信路の帯域も有線通信に比較して狭いため、従来の技術では利用者の想定を超えた長時間にわたって端末の動作が制限されてしまう事態が発生する可能性が高い。しかし、本実施形態においては、ＪａｖａアプリケーションをＡＤＦとＪａｒとに分割して取得できるようにし、かつＡＤＦの属性情報を参照した利用者がＪａｒの取得を継続するか否かを決定できるようにしたため、そのような事態を確実に回避することができる。
【００５６】
なお、上述した実施形態では、取得したＪａｖａアプリケーションを再利用可能に取得する例を示したが、再利用不可能に取得することも可能である。
また、上述した実施形態では、取得するデータとしてＪａｖａアプリケーションを例示したが、これに限らず、他のプログラムやデータであってもよい。要するに、本発明は、２つの単位に分割された何らかのデータをネットワークから取得する場合に適用可能である。
【００５７】
また、上述した実施形態では、図２の遷移パターンＰ１およびＰ２を許容しているが、これらを不許可とするようにしてもよい。すなわち、状態Ｂの通信方式と状態Ｃの通信方式が不一致となる取得パターンを許容しないようにしてもよい。
また、上述した実施形態では、端末として携帯電話機を例示したが、本発明はこれに限定されるものではなく、有線または無線のネットワークを介して通信を行うことができる端末に適用可能である。
【００５８】
また、上述した実施形態では、図２の遷移パターンＰ３およびＰ４を例外なく許容しないが、本発明はこれに限定されるものではない。例えば、図２の遷移パターンＰ３およびＰ４の場合には取得の可否を利用者に問い合わせ、利用者が許可した場合にはＪａｒを受信・格納するようにしてもよいし、Ｊａｖａアプリケーションの種類をＡＤＦに包含させ、図２の遷移パターンＰ３およびＰ４であっても対象のＪａｖａアプリケーションが通信を行わない種類のアプリケーションであればＪａｒを受信・格納するようにしてもよい。
【００５９】
また、上述した実施形態では、ＨＴＴＰ（およびＨＴＴＰＳ）およびＡＬを用いてデータを転送する例を挙げたが、本発明においては、暗号化通信を実現できる任意の通信プロトコルを採用可能である。もちろん、keep-aliveおよび非keep-aliveに対応した任意の通信プロトコルであってもよいし、これらに対応していない通信プロトコルであってもよい。
【００６０】
また、上述した実施形態では、ゲートウェイサーバＧＷＳにおいて通信プロトコルを変換する例を示したが、これはあくまで一例である。例えば、端末においてＨＴＴＰ（およびＨＴＴＰＳ）およびＳＳＬを処理できるようにし、端末とＩＰサーバとの間で直接的に通信するようにしてもよいし、複数回の変換を経て通信するようにしてもよい。
【００６１】
なお、言うまでもないが、本発明は上述した具体的な態様に限定されるのもではなく、特許請求の範囲に記載された範囲内で任意の態様を包含するものである。
【００６２】
【発明の効果】
以上説明したように、本発明によれば、端末において、データの属性情報を格納した第１のデータ単位の受信時に使用された通信方式と当該データの実体を格納した第２のデータ単位の受信時に使用される通信方式とに基づいて第２のデータ単位の受信の可否が決まる。これにより、例えば、通信方式が第１のデータ単位の受信時と第２のデータ単位の受信時とで不適切に切り換わる場合にデータの取得を不許可とすることができる。つまり、分割されたデータの取得時に十分に高い安全性（セキュリティ）を確保することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係る端末の基本的な状態遷移を示す図である。
【図２】同端末の状態の遷移パターンを示す図である。
【図３】同端末の表示メッセージを示す図である。
【図４】同端末を用いたデータ配信システムの構成を示すブロック図である。
【図５】同端末の要部の構成を示すブロック図である。
【図６】同端末内の処理テーブルＰＴ１およびＰＴ２の構成を示す概念図である。
【図７】Ｊａｖａアプリケーションの取得時に同端末が行う処理の流れを示すフローチャートである。
【符号の説明】
１１…送受信部、１２…発音部、１３…入力部、１４…液晶ディスプレイ、１５…制御部、１５１…ＣＰＵ、１５２…ＲＯＭ、１５３…フラッシュメモリ、１５４…ＲＡＭ、Ａ〜Ｄ…状態、ＢＳ…基地局、ＧＷＳ…ゲートウェイサーバ、ＩＮＥＴ…インターネット、ＭＰＮ…移動パケット通信網、ＰＳ…パケット加入者処理装置、ＰＴ１，ＰＴ２…処理テーブル、Ｔ…端末、Ｗ…ＩＰサーバ。

Claims

ネットワークを介して通信可能な端末においてデータの属性情報を格納した第１のデータ単位と前記データの実体を格納した第２のデータ単位とを前記ネットワーク側から受信することにより前記データを取得するデータ取得方法であって、
前記第１のデータ単位を受信する第１受信ステップと、
前記第１受信ステップにおいて使用された通信方式と前記第２のデータ単位の受信時に使用される通信方式とに基づいて前記データの取得の可否を判定する判定ステップと、
前記判定ステップにおける判定結果が「可」の場合には前記第２のデータ単位を受信し、「否」の場合には前記第２のデータ単位を受信しない第２受信ステップと
を有することを特徴とするデータ取得方法。
請求項１に記載のデータ取得方法において、
前記判定ステップでは、前記第２のデータ単位の受信時に使用される通信方式の安全性が前記第１受信ステップにおいて使用された通信方式の安全性よりも低い場合には前記データの取得を「否」とする
ことを特徴とするデータ取得方法。
請求項１に記載のデータ取得方法において、
前記判定ステップでは、前記第１受信ステップにおいて使用された通信方式と前記第２のデータ単位の受信時に使用される通信方式とが不一致の場合には前記データの取得を「否」とする
ことを特徴とするデータ取得方法。
請求項１乃至３のいずれかに記載のデータ取得方法において、
前記データは前記端末にて実行可能なコンピュータプログラムである
ことを特徴とするデータ取得方法。
請求項４に記載のデータ取得方法において、
前記コンピュータプログラムは通信を行うコンピュータプログラムである
ことを特徴とするデータ取得方法。
請求項１乃至５のいずれかに記載のデータ取得方法において、
前記端末は携帯電話機である
ことを特徴とするデータ取得方法。
データの属性情報を格納した第１のデータ単位と前記データの実体を格納した第２のデータ単位とをネットワーク側から受信することにより前記データを取得する端末であって、
前記第１のデータ単位を受信する第１受信手段と、
前記第１受信手段による前記第１のデータ単位の受信時に使用された通信方式と前記第２のデータ単位の受信時に使用される通信方式とに基づいて前記データの取得の可否を判定する判定手段と、
前記判定手段による判定結果が「可」の場合には前記第２のデータ単位を受信し、「否」の場合には前記第２のデータ単位を受信しない第２受信手段と
を具備することを特徴とする端末。