端末管理方法およびサーバ
【課題】サービスの登録会員の端末の追加、復旧を容易に可能とする端末管理方法を提供する。
【解決手段】サーバ２００は、自己の提供するサービスをユーザが端末から利用するための会員登録を行う際、ユーザの個人情報の入力を受け、当該ユーザに会員ＩＤを割り当てる。さらに、端末１０に対して端末ＩＤを割り当てて、端末ＩＤを当該会員ＩＤに対応付けてサーバ側で管理する。また、会員ＩＤおよび端末ＩＤを端末１０に送信して端末内に格納させる。
【解決手段】サーバ２００は、自己の提供するサービスをユーザが端末から利用するための会員登録を行う際、ユーザの個人情報の入力を受け、当該ユーザに会員ＩＤを割り当てる。さらに、端末１０に対して端末ＩＤを割り当てて、端末ＩＤを当該会員ＩＤに対応付けてサーバ側で管理する。また、会員ＩＤおよび端末ＩＤを端末１０に送信して端末内に格納させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、主としてネットワークを介して、利用期限（使用期限）付きのアプリケーション等を提供するシステムに関し、特にその利用期限を効果的に管理する方法およびサーバに関する。
【背景技術】
【０００２】
近年、インターネット関連技術や移動体通信技術等の発達により、携帯電話端末、携帯情報端末等の移動端末を用いた電子商取引が普及してきている。（本明細書において、端末装置を単に端末という。）
【０００３】
例えば、コンピュータネットワーク上から情報端末上で動作するアプリケーション等をダウンロードさせ、それを有償または無償で一定期間（以下、利用期間という）に限り利用を認める電子商取引が検討されている。
【０００４】
ダウンロードしたアプリケーション等を利用期間内に限り利用を認めるために、例えば、利用期間の終了時に当該アプリケーション等の利用を禁止する仕組であるいわゆる「時限爆弾」その他の禁止手段をアプリケーション等に組み込むことが行われている（特許文献１参照）。この利用期限は、一般的には、端末にアプリケーション等をインストールした日時（端末側の時計（カレンダ）が示すもの）を起算点として予め定めた利用期間の日数等をカウントして算出されている。
【０００５】
また、使用回数に制限を設け、例えばアプリケーションを起動するたびにある計数値をインクリメントし、この計数値が所定値を超えたならば起動を制限する方法もある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平１０−２２２５７９号公報
【非特許文献】
【０００７】
【非特許文献１】野村総合研究所著、「ユビキタス・ネットワーク」、２０００年１２月２０日、野村総合研究所発刊
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記従来の技術においては、次のような問題があった。
【０００９】
例えば、ベンダが個々のアプリケーション等に禁止手段を組み込む必要があり、ベンダの負担となる。また、その利用期限は一律のものとならざるを得ない。
【００１０】
また、利用期間の起算点がクライアント側で決まるため、ベンダ側で起算点を決めることができない。このため、正確に利用期間を把握することが困難であり、また、正確に利用期間を守らせることも困難である。
【００１１】
利用回数に制限をつける場合、アプリケーション等の起動回数はサーバには分からないので端末においてのみ管理されることになり、サーバ側で利用期限を管理することが困難である。また、端末側で利用期限に関するデータの書換えを行うと、このデータが利用制限に関連していることが容易に推察され、これを不正に書き換えて利用制限を越えた不正使用が行われやすくなる。
【００１２】
さらに、従来のダウンロード販売（アプリケーション等をダウンロードするときに課金する方式）の場合、ダウンロードが途中で中断する場合があるため、ダウンロード完了を確認する必要がある。これはサーバ側では面倒な処理である。アプリケーション等のダウンロードが途中で中断した場合に備えて、一定期間再ダウンロードすることを認める場合もあるが、この期間を経過すればダウンロードできない。これでは、ユーザがお金を支払ったにも関わらずアプリケーション等を取得できないという事態が発生するおそれがある。
【００１３】
本発明はこのような背景においてなされたものであり、その目的は、ユーザに認識されない端末ＩＤをサーバ側から各端末に割り当てることにより、サービスの登録会員および端末の認証をより的確に行うことにある。端末に提供される利用期限付きのアプリケーション等の利用期限を、サーバおよび端末の双方で管理し、かつ、端末において確実に守らせることができるアプリケーション等利用期限管理システム、サーバおよびコンピュータプログラムを提供することにある。
【００１４】
本発明による他の目的は、サービスの登録会員の端末の追加、復旧を容易に可能とする端末管理方法を提供することにある。
【００１５】
本発明による別の目的は、アプリケーション等の利用期限の状況をユーザが迅速、容易に認識することができる、端末上で動作するコンピュータプログラムを提供することにある。
【００１６】
本発明によるさらに別の目的は、端末において本発明に係るサービスが利用できることをユーザに迅速容易に認識させることができる端末を提供することにある。
【課題を解決するための手段】
【００１７】
本発明によるアプリケーション等利用期限管理システムは、端末とサーバからなるシステムにおいて、サーバはアプリケーション等の少なくとも利用期限に関する利用期限属性をアプリケーション等とは別に端末に転送し、端末は前記利用期限属性を参照し利用期限を経過したならばアプリケーション等の利用を制限する利用期限管理手段を備えたことを特徴とする。
【００１８】
前記利用期限管理手段は、例えば、端末のアプリケーション等の実行環境の一部として提供される。
【００１９】
前記利用期限は、例えば、サーバと端末との間でのアプリケーション等の利用に関するアクションを起算点として所定の利用期間が満了するときであり、前記利用期限属性は、アクションが発生するたびに生成される。
【００２０】
サーバおよび端末は実質的に同一の時間軸上で利用期限を管理する。そのために、例えば、端末は、サーバへの接続時に、当該サーバと自己の現在時刻とが所定時間以上ずれているときに、自己の現在時刻をサーバの指示に応じてサーバの管理する時刻に合わせる。また、端末は、アプリケーション等を利用したときの利用時刻を記録し、次にアプリケーション等を利用するとき、前記利用時刻を今回の利用時刻と比較し、両者の関係が予め定めた関係にある場合にはアプリケーション等の利用を制限する。
【００２１】
前記利用期限属性は当該アプリケーション等の入手先情報とともに端末に転送され、端末は前記入手先情報に基づいて当該アプリケーション等を入手する。一旦、入手先情報が得られれば、端末は利用の権利がある限り、当該アプリケーション等をいつでも入手できるので、前記アプリケーション等の入手の前に当該アプリケーションの利用権に対する課金を行うことができる。
【００２２】
また、端末は、サーバから取得し、内部に保存されているアプリケーション等を一覧表示し、その際、好ましくは、各アプリケーション等の利用期間の残量をグラフィカルに表示する。
【００２３】
サーバによる端末管理方法は、サーバの提供するサービスをユーザが端末から利用するための会員登録を行う際、ユーザの個人情報の入力を受けるステップと、当該ユーザに会員ＩＤを割り当てるステップと、当該端末に対して端末ＩＤを割り当てるステップと、前記端末ＩＤを当該会員ＩＤに対応付けてサーバ側で管理するステップと、前記会員ＩＤおよび端末ＩＤを前記端末に送信して端末内に格納させるステップとを備えたことを特徴とする。
【００２４】
これに加えて、端末からの接続を受けた際に、当該端末の機種ＩＤの送信を受け、この機種ＩＤが所定の機種ＩＤであることを確認するステップをさらに備えてもよい。
【００２５】
前記端末ＩＤは、好ましくは、当該ユーザが認識できないようにサーバおよび端末において管理されるものである。
【００２６】
サーバは、好ましくは、サーバの提供するサービスに対して端末が接続してきた際に、前記端末から前記会員ＩＤ、端末ＩＤおよびパスワードの入力を受け、サーバの管理する当該ユーザの会員ＩＤ、端末ＩＤおよびパスワードと対照してログインの可否を決定するステップとを備える。
【００２７】
前記会員ＩＤおよび端末ＩＤの入力はユーザの指示によらず端末が自動的に送信する。
【００２８】
本発明によるサーバは、会員登録を受けたユーザの端末を管理するサーバであって、ユーザの個人情報の入力を受ける手段と、当該ユーザに会員ＩＤを割り当てる手段と、当該端末に対して端末ＩＤを割り当てる手段と、前記端末ＩＤを当該会員ＩＤに対応付けてサーバ側で管理するデータベースと、前記会員ＩＤおよび端末ＩＤを端末内に格納させるために前記端末に送信する手段とを備えたことを特徴とする。
【発明の効果】
【００２９】
本発明によれば、サーバ側から端末に提供される利用期限付きのアプリケーション等の利用期限を、サーバおよび端末の双方で管理することにより、端末において確実に守らせることができるようになる。
【００３０】
また、ユーザに認識されない端末ＩＤをサーバ側から各端末に割り当てることにより、サービスの登録会員および端末の認証をより的確に行うことができるようになる。
【００３１】
さらに、各端末に端末愛称を付与することにより、サービスの登録会員の端末の追加、復旧が容易となる。
【００３２】
アプリケーション等の一覧表示において、アプリケーション等の利用期限の状況をアイコン表示することにより、ユーザが迅速、容易に認識することができるようになる。
【００３３】
また、端末において本発明に係るサービスが利用できることを所定のマークを表示することにより、当該端末上で上記サービスが利用できることをユーザに迅速容易に認識させることができる。
【図面の簡単な説明】
【００３４】
【図１】本発明の実施の形態におけるシステムの概略構成を示すブロック図である。
【図２】本発明の実施の形態におけるサービスのフローを示すフローチャートである。
【図３】本発明が適用されるアプリ等およびその実行環境を示す図である。
【図４】本発明の実施の形態における会員データベースの構成例を示す図である。
【図５】本発明の実施の形態における会員と会員ＩＤと端末ＩＤとマイメニューの関係を示す図である。
【図６】本発明の実施の形態におけるアプリデータベースの構成例を示す図である。
【図７】本発明の実施の形態におけるＡＤＦ情報の一例を示す図である。
【図８】本発明の実施の形態における、ユーザ側から見た本サービス利用の流れを説明するフローチャートである。
【図９】本発明の実施の形態における会員登録時の端末と管理サーバとの間のやりとりを示す処理シーケンス図である。
【図１０】本発明の実施の形態における会員登録時の端末の画面遷移の例を示す図である。
【図１１】本発明の実施の形態における端末登録時の端末の画面遷移の例を示す図である。
【図１２】本発明の実施の形態において、会員登録を行ったユーザが本サービスを利用する際のログイン画面（ａ）とログイン後に表示されるトップメニュー（ｂ）を示す端末画面例を示す図である。
【図１３】本発明の実施の形態において、アプリメニューからアプリ試用の申込を行う際のシステム各部の処理を示すシーケンス図である。
【図１４】本発明の実施の形態におけるアプリメニュー（ａ）およびカテゴリ一覧（ｂ）の端末の画面例を示す図である。
【図１５】本発明の実施の形態におけるマイメニューから利用期間の更新（購入も含む）を行う際の画面遷移の例を示す図である。
【図１６】本発明の実施の形態におけるアプリ更新申込時のシステム各部の処理のシーケンス図である。
【図１７】本発明の実施の形態における端末の内蔵する時計を自動的に修正する処理のシーケンス図である。
【図１８】本発明の実施の形態における端末の外観（ａ）およびオフライン状態でのメニュー表示状態（ｂ）を示す図である。
【図１９】本発明の実施の形態におけるプレイリスト画面（ａ）および各アプリの利用期間に関する属性マーク（アイコン）（ｂ）を示す図である。
【図２０】本発明の実施の形態における各種の情報の表示画面例（ａ）〜（ｄ）を示す図である。
【図２１】本発明の実施の形態において、アプリを実行する際に端末の時計をチェックする処理のフローチャートである。
【図２２】本発明の実施の形態における表示マーク（アイコン）の表示された端末画面例を示す図である。
【図２３】図１９のアイコン表示のための処理例のフローチャートである。
【図２４】端末１０の一例としての携帯電話機１０Ａの構成例を示すブロック図である。
【図２５】端末１０の他の例としてのＰＤＡ１０Ｂの構成例を示すブロック図である。
【図２６】本発明の実施の形態におけるネットワーク構成の一例を示す図である。
【図２７】図１６に対応した端末の動作を示すフローチャートである。
【図２８】図１６に対応した管理サーバの動作を示すフローチャートである。
【図２９】図２７に示したリトライＴｙｐｅＡ処理の端末における処理例を示すフローチャートである。
【図３０】図２７に示したリトライＴｙｐｅＡ処理の管理サーバにおける処理例を示すフローチャートである。
【図３１】図２７に示したリトライＴｙｐｅＢ処理の端末における処理例を示すフローチャートである。
【図３２】図２７に示したリトライＴｙｐｅＢ処理の管理サーバにおける処理例を示すフローチャートである。
【図３３】図２７に示したリトライＴｙｐｅＣ処理の端末における処理例を示すフローチャートである。
【図３４】図２７に示したリトライＴｙｐｅＣ処理のダウンロードサイト（アプリベンダ）のサーバにおける処理例を示すフローチャートである。
【図３５】本発明の実施の形態におけるＡＤＦ中の使用期間情報を使ったアプリの起動制御を示すフローチャートである。
【発明を実施するための形態】
【００３５】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００３６】
図１に、本実施の形態におけるシステムの概略構成を示す。本システムは、複数の端末１０、管理センタ２００、アプリベンダ３００、ストレージサービスサーバ４２０およびプリントサービスサーバ４３０により構成される。システムのこれらの構成要素間は、インターネット等のネットワークを介して相互に接続される。
【００３７】
管理センタ２００はアプリベンダ３００において開発されたアプリケーション等（アプリケーション、電子データ等）を管理し、端末１０のユーザの利用に供する。なお、本明細書中、アプリケーションを単にアプリともいう。管理センタ２００は、また、ストレージサービスサーバ４２０およびプリントサービスサーバ４３０が提供するストレージ提供サービスやプリントサービス等のネットワークサービスを端末１０のユーザに対して仲介する。
【００３８】
このような機能を達成するために、管理センタ２００は、インターネットのＷＷＷのためのポータルサイト２１０および管理サーバ２２０を備える。ポータルサイト２１０は課金管理部２１５を有し、有料のアプリ等やサービスに対して電子マネー等による課金を行う機能を有する。ポータルサイト２１０は、当然ながら、ウェブサーバおよび各種ＣＧＩ（図示せず）等を有する。管理サーバ２２０は、アプリベンダ３００から提供されるアプリ等を格納するアプリホルダ２２５、ストレージサービスサーバ４２０およびプリントサービスサーバ４３０の仲介となるネットワークサービスインタフェース２４０、およびこれらのアプリ等やサービスの管理を行う管理部２３０を有する。管理部２３０は、後述するように会員データベース（ＤＢ）１５０およびアプリデータベース２６０を備えている。図の例ではアプリ等として、Ｊａｖａ（登録商標）アプリを示している。
【００３９】
本実施の形態における端末１０は、いわゆるノンＰＣ端末と呼ばれる、パーソナルコンピュータ（以下、ＰＣという）以外のネットワーク端末である。ノンＰＣ端末は、ＰＣに比べて、（ａ）ＣＰＵの処理速度が遅い、（ｂ）実行メモリ（ＲＡＭ）の容量が小さい、（ｃ）ローカルストレージが小さい（ギガ単位のハードディスクではなく一般にメガ単位のフラッシュメモリが用いられている）、（ｃ）拡張性が低い（拡張ポートなどを持たない）、（ｄ）操作性が低い（キーボートとマウスではなく、テンキー、４方向カーソルキー、タッチパネル等で操作する）、（ｅ）表示画面が小さいなどの特徴を有する。このため、ノンＰＣ端末は、ＰＣに比べてハードウエアおよびソフトウエアの両面で制約が多い。ノンＰＣ端末は、具体的には、個人情報端末（Personal Digital Assistant：ＰＤＡ）を含む。ＰＤＡがＬＡＮインタフェース、モデム、無線通信機等の通信機能部を内蔵していてもよいし、コンパクトフラッシュ（登録商標）カードスロット等の拡張スロットを備え、これにＬＡＮカード、モデムカード、無線通信カード等の通信拡張カードを挿入し、通信を行うものであってもよい。ＰＤＡは、一般的には携帯可能なものであるが、机上等に据え置きで使うものも含まれる。ＰＤＡの中には腕時計に組み込まれたものも存在する。ノンＰＣ端末は、ネットワーク家電端末（ネット家電端末、インターネットアプライアンス（Internet Appliance）、情報家電端末とも呼ばれる）を包含する。ネットワーク家電端末は、コンピュータネットワーク（インターネットを含む）に接続する機能を有する家電機器である。ネットワーク家電端末は、具体的には、インターネットテレビ、デジタルテレビ、ＣＡＴＶ等のためのセットトップボックス、ゲーム機、固定電話、ＦＡＸ、プリンタ、複写機、スキャナのような通信と比較的関係が深い電子機器はもちろんのこと、冷蔵庫、電子レンジ、電気湯沸しポット、電気炊飯器、コーヒーメーカー、冷暖房装置などであってネットワークに接続可能な家電機器をも包含する。さらに、ノンＰＣ端末は、移動体通信機器を包含する。移動体（モバイル）通信機器とは、人または乗り物に付随して移動する端末機器であり、例えば、携帯電話、ＰＨＳ端末、カーナビゲーション端末、カーオーディオ機器、車載ラジオ、車載テレビ、車載ビデオ、デジタルカメラなどを含む。
【００４０】
端末１０は、ウェブを閲覧するためのブラウザ７０、アプリ等のダウンロードおよびファイル管理等を行うＪＡＭ(Java Application Manager)６４、ダウンロードされたアプリ等を保存するローカルストレージ６７、アプリ８０を実行するアプリ実行部６０を備える。なお、図における端末１０のブロック内のローカルストレージ６７はハードウェアであるが、それ以外のブロックはソフトウェアであり、ローカルストレージ６７内に格納されうる。
【００４１】
アプリ実行部６０は、本実施の形態では、ＪａｖａＶＭ(Java Virtual Machine)６１、クラスライブラリ６２、およびネットワークサービス対応のＡＰＩ（Application Program Interface）６６を有している。ＪａｖａＶＭ６１は、Ｊａｖａのバイトコードを実行するモジュールであり、図示しないＯＳ上で動作する。
【００４２】
ＪＡＭ６４は、Ｊａｒファイル、ＡＤＦ(Application Descriptor File)ファイル等のダウンロード、ＡＤＦファイルの解析等の管理を行い、ＪａｖａＶＭ６１とのメッセージのやりとりを行う。Ｊａｒファイルは、Ｊａｒ形式のＪａｖａアプリケーションであり、アプリ本体である。ＡＤＦファイルは、アプリ等の試用、購入、更新等（アプリ等の利用に関するアクション）に応じてＪａｒファイルをダウンロードするのに先立ってダウンロードされるアプリ属性データであり、Ｊａｒファイルのダウンロードの可否やオンライン課金の可否の判断、Ｊａｒファイルのコード署名の認証を行うために利用される。本実施の形態ではこのＡＤＦファイルに利用期限属性を付与する。この利用期限属性等の導入に伴う各種処理を行うための拡張部６５をＪＡＭ６４に設けている。
【００４３】
具体的には、拡張部６５は、ダウンロードされたアプリケーションの使用期限の管理、時計（カレンダ機能を含む）の管理、会員ＩＤおよび端末ＩＤ等の管理、課金に必要なセキュリティ機能（暗号化、アプリケーションのコード署名によるユーザのアクセス可能リソース（主にネットワークドメイン）の範囲の限定）、およびこれらの管理機能をユーザにガイドするためのユーザインタフェースを提供する。
【００４４】
ネットワークサービス対応のＡＰＩ６６は、ユーザが特定のアプリから、ファイル操作や印刷の要求を行ったときに、この要求をサーバ側のインタフェース２４０に連絡する機能を有する。
【００４５】
端末１０が利用するアプリは管理サーバ２２５内のアプリホルダ２２５からダウンロードする以外にも、アプリベンダ３００等から直接ダウンロードすることも可能である。
【００４６】
図２４に、端末１０の一例としての携帯電話機１０Ａの構成例を示す。この携帯電話機１０ＡはＣＰＵ１１０により制御される。このＣＰＵ１１０にはＲＡＭ１１１、ＲＯＭ１１２、無線通信部１１３、表示装置１１５、入力Ｉ／Ｏインタフェース１１６、および音声処理部１２０が接続される。ＲＡＭ１１１はＣＰＵ１１０に対してデータの一時記憶領域や作業領域を提供するメモリである。ＲＯＭ１１２はＣＰＵ１１０の実行する制御プログラムや各種のデータを格納する不揮発性のメモリである。ＲＯＭ１１２は、例えばフラッシュメモリのような再書き込み可能な不揮発性メモリを含んでもよい。本実施の形態のＪａｒファイルやＡＤＦファイルはＲＡＭ１１１および／またはＲＯＭ１１２に格納される。無線通信部１１３はアンテナ１１４を介して基地局との間で音声およびデータの無線通信を行う部位である。表示装置１１５は液晶ディスプレイを代表とする表示デバイスであり、その表示画面上にテキスト、画像等の各種情報を表示する。入力Ｉ／Ｏインタフェース１１６は、カーソルキー１１７、エンターキー１１８、ダイヤルキー１１９などに接続され、ユーザからの入力操作を受け付ける部位である。音声処理部１２０は、マイク１２１およびスピーカー１２２に接続され、ユーザの音声通話や音楽等の再生を行う部位である。データの符号化／復号化処理や音声処理はＣＰＵ１１０が行ってもよいし、別個のプロセッサ（図示せず）で行ってもよい。
【００４７】
図２５は、端末１０の他の例としてのＰＤＡ１０Ｂの構成例を示す。このＰＤＡ１０Ｂは、ＣＰＵ１３０により制御される。このＣＰＵ１３０にはＲＡＭ１３１、ＲＯＭ１３２、ＣＦカードインタフェース（Ｉ／Ｆ）１３３、表示装置１３５、入力Ｉ／Ｏインタフェース１３６が接続される。ＲＡＭ１３１およびＲＯＭ１３２は、携帯電話機のＲＡＭ１１１およびＲＯＭ１１２と同様である。ＣＦカードインタフェース（Ｉ／Ｆ）１３３は、無線通信機能を付加する無線通信カード１３４を装着するためのインタフェースであり、この無線通信カード１３４により基地局との通信が可能となる。表示装置１３５は、携帯電話機の表示装置１１５と同様の表示デバイスであるが、通常、その画面サイズは携帯電話機のそれより大きい。入力Ｉ／Ｏインタフェース１３６は、タッチパネル１３７やボタン１３８からに対するユーザ操作を受け付ける部位である。
【００４８】
いずれの端末においても、ユーザは、複数のメニュー項目から任意の一つを選択し、所望の画面へ移ることができる。メニュー項目の選択は、例えば、携帯電話機においては、カーソルを選択を望むメニュー項目へ移動させる。カーソルが指示するメニュー項目は、例えばハイライト表示により強調される。次に、エンターキーを押し下げることにより、現在カーソルが指示するメニュー項目が選択される。また、ＰＤＡの場合には、タッチパネルディスプレイ上でメニュー項目をペンでタップ（tap）することにより当該メニュー項目を選択することができる。
【００４９】
図２６に、本実施の形態におけるネットワーク構成の一例を示す。携帯電話機１０ＡやＰＤＡ１０Ｂは、基地局１４０を介して無線ネットワーク（Wireless Network）１４５に接続される。無線ネットワーク１４５は例えば携帯電話パケット通信網である。無線ネットワーク１４５はゲートウェイ(Gateway）１５５を介してインターネット１５７に接続される。ゲートウエイ１５５は、無線ネットワーク１４５とインターネット１５７との間でプロトコル変換を行うと共に、ユーザ毎に送受信したパケットに対して課金を行う。インターネット１５７には、管理サーバ２２０、課金サーバ２７０、およびアプリベンダ３００等の各種サーバが接続される。従って、端末１０と管理サーバ２２０、課金サーバ２７０及びアプリベンダ３００との間の通信は無線ネットワーク１４５、ゲートウエイ１５５、インターネット１５７を介して行われる。ゲートウェイ１５５での課金方式はこれに限定されるものではない。例えば通信を行った時間に対して課金を行うことも可能である。
【００５０】
図２に、本実施の形態におけるサービスのフローを説明する。
【００５１】
まず、アプリベンダ３００が開発したアプリ８０を管理センタ２００の管理サーバ２２０内の管理部２３０に登録し、アプリをアプリホルダ２２５内に格納する（1）。この際、必須ではないが、管理センタ２００の運用者はアプリの受託費用を徴収することができる。管理センタ２００はポータルサイト２１０において、端末１０のユーザから、本サービスの会員登録を受ける（2）。これと共に、電子商取引のために当該会員の決済口座２３５を開設する（3）。本実施の形態では決済の方法として電子マネーを用いるが、本発明はこれに限定されるものではない。
【００５２】
その後、会員であるユーザは端末１０からポータルサイト２１０にアクセスして、所望のアプリを選択してダウンロードする（4）。本実施の形態では、当初、利用期間を限って、アプリを無料でユーザの試用に供する（5）。ユーザはそのアプリを気に入れば、管理サーバ２２０に対して継続利用の登録（購入申込）を行うことができる（6）。この段階で初めてユーザは利用料の支払いを行う（7）。これによって、ユーザはそのアプリの正式な利用権利を取得する（8）。本実施の形態では、利用可能な期間の制限を設けるリースの形式でアプリを提供する。ここでリースとは、広く貸与の意味で用いており、レンタルと同意である。ユーザが保持する権利は、利用期限付きのアプリ等の利用権（ライセンス）である。言い換えれば、ある期間アプリ等を利用する権利を購入することである。これにより、ユーザはその利用期間に応じた対価を支払えば足り、必要に応じて利用期間を延長したり、利用期間経過後に再購入したりすることができる。利用料から管理センタ２００の手数料を減じたものがアプリベンダ３００に分配される（9）。アプリがネットワークサービス対応アプリの場合、そのアプリを実行することにより、ストレージサービスやプリントサービスを受けることができる。ストレージサービスは、ポータルサイト等で会員毎にストレージ領域を貸し出すサービスである。また、プリントサービスは、会員の提供するデジタル写真データ等の印刷出力を行うサービスである。これらのネットワークサービスにも利用期限が付加され、ユーザはその利用期間内に利用料を支払って当該サービスを受けることができる（10，11）。この利用料から管理センタ２００での手数料を減じたものがサービス事業者４００に分配される（12）。
【００５３】
図３（ａ）に示すように、本発明の端末の基本モデルは、ＯＳ５０の上に配置されたアプリ等実行環境５２上でアプリ等が利用され、かつ、アプリ等実行環境５２に付随した期限管理機能５３が個々のアプリ等の利用期限の管理を行う。本実施の形態におけるアプリ等とは、上記Ｊａｖａアプリのようなアプリケーションプログラムやその構成要素の一部の他にも、テキスト、画像、動画、音楽、マークアップ言語ファイル等のようなＷｅｂコンテンツ等も含むものである。また、アプリ実行環境とは、ＯＳ上で実行され、アプリ等をユーザが利用するための環境を提供するプログラムまたはプログラム群をいう。アプリ等の利用には、閲覧、視聴、利用、実行等の種々の行為を含む。
【００５４】
図３（ｂ１）（ｂ２）（ｂ３）、（ｃ）〜（ｆ）は、種々のアプリ等の例と、その実行環境の例を示したものである。すなわち、図３（ｂ１）〜（ｂ３）は、アプリケーションプログラムとその実行環境を示す。図３（ｂ１）に示すように、Ｊａｖａアプリケーションについては、Ｊａｖａ仮想マシンがＪａｖａバイトコードを実行する。また、図３（ｂ２）に示すように、例えばＣ言語で作成され、コンパイルされたアプリケーション実行ファイル（いわゆるexe file）は、ローダーによりメモリ上にロードされ、ＣＰＵにより実行される。図３（ｂ３）に示すように、本システムでダウンロードの対象となるアプリケーション実行ファイルは、他のコンポーネントと共に実行されるアプリケーションプログラムの一部であってもよい。
【００５５】
また、図３（ｃ）〜（ｆ）に示すように、本システムにおけるダウンロードの対象には、画像データ、動画データ、音楽データおよびテキストデータが含まれる。図３（ｃ）に示す画像データは、画像データのフォーマットに対応したビュワーによって展開され、表示される。画像データが圧縮されている場合にはビュワーは伸張も行う。また、図３（ｄ）に示す動画データは、動画データのフォーマットに対応したプレイヤによって再生される。また、図３(ｅ)に示す音楽データは、例えばｍｐ３に代表されるような圧縮形式で圧縮されており、プレイヤは音楽データを伸張し、再生する。さらに、図３（ｆ）に示すテキストデータは、例えば、ＨＴＭＬに代表されるマークアップランゲージにより表示形式が定義されている。ブラウザのようなテキストビュワーは定義に従ってテキストを表示する。
【００５６】
管理センタ２００の管理サーバ２２０は、その提供するサービスの会員情報を管理する会員データベース２５０と、アプリベンダが登録したアプリ等を管理するアプリデータベース２６０を備えている。
【００５７】
図４は、管理サーバ２２０の管理部２３０が保持、管理する会員データベース２５０の構成例を示す。この例では、会員の登録時に各会員毎に会員情報２５１のレコードが作成される。会員情報２５１には、会員ＩＤ、氏名、パスワード、メールアドレス、電話番号（ｔｅｌｎｏ）、誕生日、性別、住所、会員登録日時、最終ログイン日時、抹消フラグの各項目を含む。
【００５８】
この会員情報２５１に対して少なくとも１つの端末情報２５２のレコードが作成される。端末情報２５２は会員が本サービスを利用するために利用する端末に関する情報であり、この例では、会員ＩＤ、端末ＩＤ、端末愛称、端末登録日時、抹消フラグ等の各項目を含む。会員ＩＤは、本サービスへの入会時に会員に一意に割り当てられる会員の識別情報である。端末ＩＤは、本サービスにおける端末の識別情報（例えば通し番号）であり、端末登録時にサーバが一意に割り当てるものである。端末情報２５２のレコードは、一人の会員が登録した端末の個数だけ別個に作成される。
【００５９】
端末情報２５２の各レコードには１対１にマイメニュー２５３が作成される。マイメニュー２５３は、管理サーバが管理、提供するすべてのアプリの中からユーザ（会員）が選択した特定のアプリ群を管理するためのものであり、その端末ＩＤおよびマイメニューＩＤを保持しており、当該会員のみに閲覧が許可される。各マイメニュー２５３には、当該端末に対して新たにアプリの試用または使用が開始されるたびにそのアプリについてマイアプリ情報２５４のレコードが作成される。マイアプリ情報２５４は、マイメニューＩＤ、アプリＩＤ（APPID)／レビジョン番号、利用期間終了日、ダウンロード（ＤＬ）回数カウンタ、購入回数カウンタ、アプリ削除日時等の各項目を含む。「利用期間終了日」がそのアプリの利用期限を示している。「購入回数」は料金支払いを伴うアプリのダウンロード回数であるが、「ダウンロード回数」とは必ずしも一致しない。ダウンロードは有効な利用期間中であれば何度でも行えるからである。
【００６０】
会員データベースの構造から分かるように、本実施の形態では図５に示すように、一人の会員が複数の端末で本サービスを利用する場合、一つの会員ＩＤに対して複数の端末ＩＤが付与され、さらに、その各端末ＩＤに対して独立にマイメニューが作成される。例えば、第１の端末において購入されたアプリ等は第１の端末のマイメニューのみに登録され、他の端末からは利用できない。他の端末で同じアプリ等を利用するには当該他の端末で別途購入する必要がある。このように、すべての端末でアプリ等を共有することはせず、端末毎にマイメニューを割り当てるようにした理由は、（１）複数のユーザが一人の会員名義で複数の端末を用いて同じ有料アプリ等を使用する不正を防止すること、（２）会員が有料アプリ等に電子マネーを支払って有効期限を更新させた場合にその情報を会員が持っている他の全ての端末に伝えるのが困難であること、（３）会員の一つの端末から購入したアプリ等が別の機種で動かない不具合を避けること、等である。なお、未だ利用期間の残存しているアプリ等を登録した端末の故障や紛失等に対処するためには、後述するように端末の「復旧」の機能を設けている。
【００６１】
図６は、管理部２３０が保持、管理するアプリデータベース２６０の構成例を示す。この例では、新たなアプリの登録時にアプリメニュー２６１に新たなアプリ管理レコード２６２が追加される。アプリ管理レコード２６２は、アプリＩＤ、そのリビジョン（改訂番号）、ベンダＩＤ、アプリ名称(Name)、アプリの型（Javatype)、アプリのカテゴリＩＤ、アプリ本登録日時、試用期間、リース単位期間、単価、削除フラグ、アプリＵＲＬ（入手先情報）、アプリサイズ、スクリーンサイズ等の項目を含んでいる。「アプリのカテゴリＩＤ」は後述するアプリメニューでのカテゴリ別のアプリの一覧時に利用される。「アプリ本登録日時」はベンダが正式にアプリを登録した日時である。試用期間はそのアプリの試用可能な期間であり、アプリ毎に、決定される。図の例では３日となっている。「リース単位期間」はユーザの１回の購入（更新も含む）で利用できる期間を示している。「単価」はその１回の購入の料金である。「削除フラグ」はこのアプリの登録を削除した場合に立てられるフラグである。登録アプリが削除された場合にアプリ管理レコード自体を削除する方法もありうるが、本例では削除フラグを設けて、アプリ登録の履歴を残している。「アプリＵＲＬ」は、このアプリ本体の入手できるＵＲＬ(Uniform Resource Locator)であり、管理サーバ２２０内のアプリホルダ２２５だけでなく、ベンダ内のサーバの場合もありうる。「スクリーンサイズ」は端末において当該アプリのための表示エリアのサイズを指定するためのデータである。スクリーンサイズ情報はアプリのダウンロードに伴って端末に送られ、端末のブラウザに解釈されて指定された表示エリアサイズが実現される+
。
【００６２】
本実施の形態では、１回の購入では「リース単位期間」のみの購入を行う場合を想定しているが、ユーザの選択により、１回の購入でリース単位期間×ｎ（ｎは１以上の整数）とすることも可能である。この場合、例えばリース単位期間が１０日ならば１０×３＝３０日という利用期間となる。同時に課金は単価のｎ倍となる。
【００６３】
図７に、本実施の形態におけるＡＤＦ情報５５の一例を示す。前述のようにＡＤＦは、端末によるアプリのダウンロードに先立ってサーバにより作成され端末に送られるファイルである。ＡＤＦ情報５５は、アプリ名称(Name)、そのリビジョン（改訂番号）、ベンダＩＤ、アプリＵＲＬ、アプリサイズ、拡張バージョン番号(Extension-Version)、利用期限(Expiration-Time)、リース期間、コード署名(Code-Signing)、スクリーンサイズ等の項目を含んでいる。ここに、拡張バージョン番号(Extension-Version)、利用期限(Expiration-Time)は、アプリのダウンロード時にサーバが設定するデータであり、他のデータは前述したアプリデータベース２６０の当該アプリ管理レコード２６２から複写されたデータである。「利用期間」は図６の「リース単位期間」の複写であるが、前述のようにリース単位期間を複数個指定できる場合にはその倍数の期間となる。本実施の形態では利用期限として、利用期間の終了する日時データを指定する。また、利用期限データには、試用の場合にはその識別子として“,trial”の文字列を付加する。
【００６４】
図８により、ユーザ側から見た本サービス利用の流れを説明する。
【００６５】
まず、ユーザは本サービス利用のための端末を購入する（Ｓ７１）。本実施の形態では、セキュリティ等の観点から、本サービスの利用を特定の端末機種に制限している。端末機種は、工場出荷時に埋め込まれている機種ＩＤにより判断することができる。機種ＩＤがない端末であっても、例えば、端末からサーバに送られるＨＴＴＰヘッダに埋め込まれたユーザエージェント情報を利用して判断することも可能である。（この場合、端末に搭載されたブラウザの識別子から端末機種を判断することになる。）ユーザはこの端末からポータルサイトにアクセスして、会員登録を行う（Ｓ７２）。ついで、電子商取引のために電子マネーの登録を行い、前もって電子マネーの補充を行っておく（Ｓ７３）。ここまでが初期処理であり、最初に一度実行すれば足りる。
【００６６】
その後、通常処理に移る。通常処理では、まず、ポータルサイトから所望のアプリを選択して（Ｓ７４）、ダウンロードし（Ｓ７５）、試用してみる（Ｓ７６）。本実施の形態では、試用期間経過後も３回まで試用のためのダウンロードを許容している（Ｓ７７，Ｓ７８）。これは、前述したユーザデータベース２５０のマイアプリ情報のダウンロード回数カウンタおよび購入回数カウンタの各カウント値に基づいて判断することができる。ユーザは試用中このアプリを気に入った場合（Ｓ７９）、このアプリを購入して正式な利用権を得ることができる（Ｓ８０）。購入申込時に、その使用料に応じて電子マネーの充当が必要な場合（Ｓ８１）、電子マネーの補充を行う（Ｓ８２）。電子マネーによる使用料を支払えば（Ｓ８３）、このアプリの利用期間が設定される（Ｓ８４）。なお、図示しないが、このアプリの購入動作は試用期間の経過後であっても可能である。
【００６７】
アプリの購入から利用期間のカウントダウンが開始され、期限が到来すると（Ｓ８５）、アプリの起動時にその旨がメッセージ出力される（Ｓ８６）。これに対して再購入の指示を行って（Ｓ８７）、使用料を払えば（Ｓ８３）、再度利用期間が設定される（Ｓ８４）。図では明記していないが、この利用期間の延長は、期限到来前にも行うことが可能である。その場合、前の残存利用期間に新たな利用期間が追加される形となる。
【００６８】
以下、本実施の形態におけるシステム各部の具体的な動作を、画面例を交えて説明する。
【００６９】
図９は、会員登録時の端末と管理サーバとの間のやりとりを示す処理シーケンス図である。本実施の形態では、管理サーバはポータルサイトを介してインターネットを経由して端末との間でデータ通信を行う。典型的には、ＴＣＰ／ＩＰプロトコル上でｈｔｔｐ(hyper text transfer protocol)もしくはｈｔｔｐｓまたはｆｔｐ(file transfer protocol)を利用してデータ通信を行う。ｈｔｔｐｓを利用する場合にはＳＳＬ(Secure Socket Layer)を用いて通信内容が秘匿される。本サービスを利用する端末は、特定の機種に限定するために、管理サーバは端末の接続時に端末から機種ＩＤを受信し（Ｓ１１１）、その端末が予定された機種の端末であることを確認する（Ｓ１１２）。また、後述するように登録済みの端末は内部に保存された会員ＩＤおよび端末ＩＤも、接続時に管理サーバへ送信する。管理サーバは、機種ＩＤを受信しなかった場合または受信しても予定された機種ＩＤではなかった場合、サービスの提供が行えない旨（拒絶メッセージ）を端末に送信する（Ｓ１１３）。
【００７０】
機種ＩＤがＯＫであれば、会員ＩＤおよび端末ＩＤの受信の有無を確認する（Ｓ１１４）。これらのＩＤ受信があれば、端末のユーザにパスワードの入力を求め、パスワードがＯＫであれば、ログインを許可する（Ｓ１１５）。これ以降の動作については後述する。
【００７１】
会員ＩＤおよび端末ＩＤを受信しなかった場合、その端末は本サービスに登録されていないので、登録選択画面（図１０（ａ））を端末へ送信する（Ｓ１１６）。図示しないが、管理サーバは、会員ＩＤおよび端末ＩＤを受信しても、その組み合わせが登録されていないものの場合にも拒絶メッセージを返送する。未会員登録のユーザは会員登録のためのアンカーポイントである「新規会員登録する」を選択する。アンカーポイントはＨＴＭＬ(Hyper Text Markup Language)を代表とするマークアップ言語ファイルに埋め込まれた、他のファイルやサイト等へリンクが張られた部分である。ユーザがこのアンカーポイントを指示することにより、マークアップ言語ファイル内のその位置に記載されたリンク先へ移行したり、指定された処理を実行したりすることができる。既に会員登録しているユーザが、新たな端末を本サービス利用に追加する、または、既登録端末が破損もしくは紛失した等の理由により既登録端末の既得権を新たな端末（または修理後の端末）が引き継ぐ場合には、端末登録のためのアンカーポイントである「こちらから」を選択する。
【００７２】
管理サーバはユーザの入力した選択に応じて（Ｓ１１７）、会員登録か端末登録かを判断する（Ｓ１１８）。会員登録の場合には、図１０（ｂ）に示すように、ユーザに氏名、パスワード、メールアドレス、住所および前述した端末愛称等の個人情報の入力を求め、図１０（ｃ）に示すように会員ＩＤの割り当てを行い、会員データベースに登録する（Ｓ１３４）とともに、この会員ＩＤをユーザに通知する（Ｓ１３５）。ついで、会員から電子マネー登録の指示を受け（Ｓ１３６）、電子マネー口座を開設する等の電子マネー登録処理を行う（Ｓ１３７）。さらに、当該会員に対する当該端末に端末ＩＤを割り当てて、前記端末愛称に対応づけて当該端末ＩＤを会員データベースに登録する（Ｓ１４０）。その後、図１０（ｄ）に示すようにユーザに登録結果を通知し（Ｓ１４１）、ログイン画面への移行を勧誘する。
【００７３】
ユーザから端末登録が指示された場合（Ｓ１１８）、図１１（ａ）に示すように会員ＩＤおよびパスワードの入力を求め（Ｓ１１９）、これらの入力を受けて（Ｓ１２０）、会員の認証を行う（Ｓ１２１）。この認証がＯＫでなければ、拒絶メッセージを返す（Ｓ１２２）。認証ＯＫであれば、図１１（ｂ）に示すような端末の追加か破損端末復旧（または復旧からの乗り換え）かをユーザに選択させる（Ｓ１２３，Ｓ１２４）。端末の追加の場合には（Ｓ１２５）、図１１（ｃ）のようにユーザに新たな端末愛称を入力させ（Ｓ１２６，Ｓ１２７）、上記端末登録処理（Ｓ１４０）へ移行する。
【００７４】
上記ステップＳ１２５で端末の復旧と判断された場合は、復旧処理を行う。具体的には、まず、図１１（ｅ）に示すようにユーザに端末愛称により端末を選択させ（Ｓ１２８）、ユーザの選択（Ｓ１２９）により復旧対象の端末を特定する。ついで、当該端末のマイアプリ情報２５４（図４）を新端末のマイメニュー２５３（図４）にコピーし（Ｓ１３０）、指示された端末愛称の端末の端末情報２５２（図４）の抹消フラグをＯＮにする（Ｓ１３１）。その後、前記と同様の端末登録処理（Ｓ１４０）を行う。
【００７５】
端末登録処理の後は、管理サーバは端末に対して会員ＩＤ、端末ＩＤ、機種ＩＤ、および端末愛称を送信する（Ｓ１４１）。好ましくは、ユーザに登録内容を知らしめるために、会員ＩＤ、機種ＩＤおよび端末愛称を表示する（Ｓ１４２）。但し、端末ＩＤは会員自身にも秘密にされ、会員ＩＤおよび端末愛称とともに、端末内のローカルストレージに保存される（Ｓ１４３）。本サービスの対象とする端末機種では、ユーザに対してこれらのデータにアクセスする手段は提供されていない。
【００７６】
図１２は、会員登録を行ったユーザが本サービスを利用する際のログイン画面（ａ）とログイン後に表示されるトップメニュー（ｂ）を示す端末画面例を示している。トップメニューは、「アプリメニュー」「マイメニュー」「電子マネー補充」「設定」「ヘルプ」等のメニュー項目をアンカーポイントとして提示している。「アプリメニュー」は、本サービスで提供されているすべてのアプリをユーザに提示し、ユーザの所望のアプリを試用のために選択させるメニューである。「マイメニュー」は、前述したように、アプリメニューからユーザが選択した特定のアプリ（マイアプリ）群を登録したメニューであり、ユーザは、この画面から本使用の申込（購入）、利用期間中または期間後の利用期間の更新を行うことができる。本実施の形態ではマイメニュー内の利用期間経過後の試用アプリの再試用の申込も可能である。（但し、再試用の回数は制限される。）アプリメニューおよびマイメニューの画面例については後述する。「電子マネー補充」は、アプリの料金支払いに先立って電子マネーを補充しておくためのメニュー項目である。「設定」は会員情報の更新や証明書の更新を行うためのメニュー項目である。
【００７７】
図１３は、アプリメニューからアプリ試用の申込を行う際のシステム各部の処理シーケンスを示す。管理サーバは、端末へトップメニューを送信し（Ｓ２１１）、端末からアプリメニューの要求を受けて（Ｓ２１２）、アプリメニューを送信する（Ｓ２１３）。ユーザがアプリを選択すると、そのアプリを特定する情報が管理サーバに送信される（Ｓ２１４）。これに応じて管理サーバはそのアプリを当該ユーザのマイメニューにマイアプリとして登録する（Ｓ２１５）。管理サーバはさらに、ＧＥＴ＿ＡＤＦコマンドを埋め込んだＨＴＭＬファイルを端末に送信する（Ｓ２１６）。このＨＴＭＬファイルはマイアプリの登録結果の通知を目的とするもの等、任意のＨＴＭＬファイルであってよい。端末はこのＨＴＭＬを解釈し、ユーザの指示によらず、埋め込んだＧＥＴ＿ＡＤＦコマンドを管理サーバに送信してＡＤＦファイルの送信を要求する（Ｓ２１７）。これに応じて、管理サーバは、そのコマンドを受信、解釈して、当該アプリについて、図７で説明したようなＡＤＦを作成する（Ｓ２１８）。このときＡＤＦ内に組み込む利用期限は、例えば試用申込時の日にち（または日時）を起算点として、試用期間に基づき試用期間終了日（または日時）を算出する。作成されたＡＤＦは、端末へ送信される（Ｓ２１９）。
【００７８】
端末は、受信したＡＤＦをローカルストレージに格納するとともに解析する（Ｓ２２０）。ついで、ＪＡＭを起動し（Ｓ２２１）。このＪＡＭがＡＤＦの記述内容に従ってアプリ本体であるＪａｒファイルを、アプリＵＲＬの示すサイトに対して要求する（Ｓ２２２）。前述のとおり、アプリＵＲＬは管理サーバ内のアプリホルダであっても、あるいはアプリベンダであってもよい。アプリＵＲＬのサイトから端末にＪａｒファイルが送信される（Ｓ２２３）。端末はこのファイルを受信してローカルストレージ内に格納する（Ｓ２２４）とともに、その利用期限の管理を開始する（Ｓ２２５）。
【００７９】
図１４（ａ）に管理サーバから送信されて端末に表示されるアプリメニューの例を示す。この例では、アプリメニューはアプリの「カテゴリ一覧」「新着アプリ一覧」「アプリの検索」等のメニュー項目を有する。図１４（ｂ）にカテゴリ一覧の指示に応じて表示されるカテゴリ一覧画面（図示せず）の中から「ゲーム」が指示されたアプリの一覧画面を示す。この例では、各ゲームアプリの名称、試用期間およびアプリの簡単な説明が示されている。ユーザが、表示された任意のアプリを指示すると、図１３で説明したように端末へのダウンロードが開始される。
【００８０】
図１５により、マイメニューから利用期間の更新（購入も含む）を行う際の画面遷移の例を説明する。図１５（ａ）はマイメニューの画面例を示す。この例では、「ダウンロード」「利用期間の更新」等のメニュー項目を示している。
【００８１】
メニュー項目「ダウンロード」は、マイメニュー中の例えば試用期間経過後の試用アプリについて再度の試用を申し込む場合に用いる。「ダウンロード」が選択されると、図１５（ｂ）のような画面となり、試用アプリを新たなＡＤＦファイルとともに再度ダウンロードして、その利用期間を更新することができる。この場合は試用なので料金の支払い（管理サーバ側からみれば課金）は生じない。ダウンロード中は図１５（ｅ）のような画面となる。
【００８２】
「利用期間の更新」が選択された場合には、図１５（ｃ）に示すように、一旦購入したアプリのリストが表示され、ユーザは任意のアプリの更新を指示することができる。ここに「更新」とは利用期間中のアプリの利用期間の延長、および、利用期間経過後の再度の購入申込を含む。利用期間の延長時には、残存した利用期間に新たな利用期間が加算される。また、この「更新」時には課金がなされるので、図１５（ｄ）に示すように、その価格情報および電子マネーの残高の変化が表示され、ユーザの確認をとる。確認がとれれば、新たな利用期限を含む新たなＡＤＦファイルとともにアプリ本体が端末にダウンロードされる（図１５（ｅ））。
【００８３】
なお、図示しないが、図１５（ａ）のマイメニューには「マイメニューの整理」のメニュー項目を設けてもよい。マイメニューの整理ではマイアプリの削除を行うことができる。
【００８４】
図１６に、アプリ更新申込時のシステム各部の処理シーケンスを示す。管理サーバから端末に送られた（Ｓ３１１）マイメニューに対してユーザが任意のアプリを選択すると（Ｓ３１２）、端末からそのアプリを特定する情報とともに購入要求が管理サーバになされる（Ｓ３１３）。管理サーバは課金サーバに対して当該ユーザに対する当該アプリの課金要求を行い（Ｓ３１４）、これに応じて課金サーバは所定の課金処理を行う（Ｓ３１５）。所定の課金処理がなされた場合、課金ＯＫの通知が管理サーバに戻される（Ｓ３１６）。管理サーバは、課金処理が完了した後、当該会員の当該端末のマイメニューを更新する（Ｓ３１７）。ここまでがアプリ更新申込処理の第１フェーズである。
【００８５】
管理サーバはさらに、ＧＥＴ＿ＡＤＦコマンドを埋め込んだＨＴＭＬファイルを端末に送信する（Ｓ３１８）。端末はこのＨＴＭＬを解釈し、ユーザの指示によらず、ＧＥＴ＿ＡＤＦコマンドを管理サーバに送信してＡＤＦファイルの送信を要求する（Ｓ３１９）。これに応じて、管理サーバは当該アプリについてＡＤＦを作成する（Ｓ３２０）。このときＡＤＦ内に組み込む利用期限は、例えば購入申込時の日にち（または日時）を起算点とする。残存期間がある場合には、それを加算して利用期間終了日（または日時）を算出する。作成されたＡＤＦは、端末へ送信される（Ｓ３２１）。ここまでがアプリ更新申込処理の第２フェーズである。
【００８６】
続く第３フェーズでは、端末は、受信したＡＤＦをローカルストレージに格納するとともに解析する（Ｓ３２２）。ついで、ＪＡＭを起動し（Ｓ３２３）。このＪＡＭがＡＤＦの記述内容に従ってアプリ本体であるＪａｒファイルをアプリＵＲＬのサイトに要求する（Ｓ３２４）。アプリＵＲＬサイトから端末にＪａｒファイルが送信される（Ｓ３２５）。端末はこのファイルを受信してローカルストレージ内に格納する（Ｓ３２６）とともに、その利用期限の管理を開始する（Ｓ３２７）。
【００８７】
このような構成により以下のような効果が得られる。
（１）全てが正常に行われる場合、購入申込、課金、アプリ本体のダウンロードまでが一連の手順で行われ、しかもユーザは購入申込以外の操作が不要であり、かつ、意識することも無い。
（２）第１フェーズでは、購入申込コマンドが端末から管理サーバへ送信された後は、管理サーバと課金サーバとの間だけで処理が行われるのでシステムの安定性が高い。また、端末とサーバとの間の通信異常により第１フェーズが途中で中断することはない。
（３）端末と管理サーバとの間の通信に異常が発生することが考えられるが、第１フェーズが完了していれば第２フェーズ以降をやり直せばよい（ユーザはマイメニューからダウンロードを行えばＡＤＦファイルおよびＪａｒファイルを取得できる。）従って、重複課金は発生しないで済む。
（４）第２フェーズでは、端末が受信すべきファイルはアプリ本体（Ｊａｒファイル）とは別のＡＤＦファイルという比較的小さなファイルの送信だけなので、課金を含むセッションが回線不良などで中断してしまう危険性を極めて低くできる。
（５）第３フェーズでは、Ｊａｒファイルのサイズが大きい場合、端末とベンダとの間で通信異常が発生し、Ｊａｒファイルを完全にダウンロードできないおそれがある（特に、端末が移動体型（モバイル）情報端末である場合）。この場合、第３フェーズのみやり直すことができる（具体的にはＡＤＦがあるのでプレイリストにアプリは表示されるが実体がないので、ここでアプリＵＲＬに接続しダウンロードを再トライする）。アプリＵＲＬが管理サーバ以外（例えばベンダ）である場合には、ダウンロードのやり直しには管理サーバは関与しないのでその負担を軽減することもできる。データが大きい場合にメリットはより大きくなる。
【００８８】
二重課金を防止するために、端末がアプリ（Ｊａｒファイル）を完全にダウンロードしたことを確認したときに初めて課金を行うような場合、第１フェーズから第３フェーズまでずっと課金を待っている必要があるが、本実施の形態では、そのような必要がなく、サーバの負担が軽減される。すなわち、本実施の形態では、第１フェーズさえ終わっていれば課金が二重に行われることは無く、第３フェーズの終了を管理サーバが確認する必要はない。
【００８９】
一方、利用期間内であれば何度でもダウンロードできるので、第２フェーズ以降の処理は課金とは独立しているといえる。したがって、二重課金が発生するおそれがなく、ユーザはアプリを取得できる。よって、端末内部の記憶装置（ローカルストレージ）が一杯になった（または余裕がなくなった）場合、何の心配も無くデータを削除し、必要になれば第２フェーズ以降を行えば済むという使い方が可能となる。したがって、アプリＵＲＬのサイトをあたかも端末の「仮想ストレージ」として利用できることになる。
【００９０】
図２７は、図１６に対応した端末の動作を示すフローチャートである。端末上でブラウザを起動し、サービスにログインすると（Ｓ７１１）、管理サーバから送信されたマイメニューを表示する（Ｓ７１２）。そこで、ユーザによる、マイメニューに表示されたアプリの中から購入するアプリの選択を受ける（Ｓ７１３）。アプリが選択されると、端末は、購入要求を管理サーバへ送信する（Ｓ７１４）。その後、端末は、管理サーバから課金処理が不成立であったことを示すエラー通知を受信したか否かチェックする（Ｓ７１５）。課金エラー通知があった場合は、例えば「課金手続きが完了できませんでした。アプリケーションの購入手続きを初めからおこなってください。」というような課金ＮＧメッセージを表示し、処理を中止する（Ｓ７１６）。課金エラー通知がない場合、端末は、管理サーバからＧＥＴ＿ＡＤＦコマンドを埋め込んだＨＴＭＬファイルを受信する（Ｓ７１７）。このときＨＴＭＬファイルを正常に受信したか否か判断する（Ｓ７１８）。ＨＴＭＬファイルを受信中に通信にエラーが発生した場合、ブラウザよりも下位レイヤのＴＣＰ／ＩＰプロトコル処理プログラムからエラー通知がある。ステップＳ７１８の判断結果がＮｏの場合、例えば「通信が中断しました。Ｍｙメニューに接続し、アプリケーションのダウンロード手続きを行ってください。」のようなリトライＴｙｐｅＡ要求メッセージを表示し、ユーザにアプリケーションのダウンロード手続きを行うように促す（Ｓ７１９）。これは、課金結果はＯＫであるが、フェーズ２へ移行できなかったので、課金処理より後の処理を行えば済む、という状態である。
【００９１】
一方、正常にＨＴＭＬを受信できた場合、端末はＨＴＭＬを解釈し（Ｓ７２０）、埋め込まれたＧＥＴ＿ＡＤＦコマンドを管理サーバへ送信する（Ｓ７２１）。その後、端末は、管理サーバからＡＤＦを正常に受信したか否かをチェックする（Ｓ７２２，Ｓ７２３）。Ｎｏの場合、例えば「通信が中断しました。アプリケーションの再ダウンロード手続を行ってください。」のようなリトライＴｙｐｅＢ要求メッセージを表示し、ユーザにアプリケーションの再ダウンロード手続きを行うように促す（Ｓ７２４）。ここでは、第２フェーズを正常に完了できず、ＡＤＦファイルを受信するところからやり直す必要がある。ＨＴＭＬは受信済みなので、これを利用してＧＥＴ＿ＡＤＦコマンドの送信からやり直す。この点の詳細は後述する。
【００９２】
一方、ＡＤＦを正常に受信できた場合、ＪＡＭを起動する（Ｓ７２５）。ＪＡＭは、ＡＤＦ情報に従ってアプリベンダのサイトに接続し、Ｊａｒファイルを要求する（Ｓ７２６）。次いで、管理サーバからＪａｒファイルの受信を行う（Ｓ７２７）。その後、端末はＪａｒファイルを正常に受信したか否かをチェックする（Ｓ７２８）。Ｎｏの場合、例えば「アプリケーションのダウンロード中に通信が中断しました。プレイリストから「最新版取得」を実行してください。」のようなリトライＴｙｐｅＣ要求メッセージを表示し、ユーザにプレイリストから『最新版取得』を行うように促す（Ｓ７２９）。ここでは、第３フェーズを正常に完了できていないので、Ｊａｒファイルを受信するところからやり直す必要がある。ＡＤＦは受信済みなので、プレイリストにはアプリ情報が表示されるが、実体データが取得できていない状態である。そこで、ＡＤＦを利用してＪＡＲファイルの受信要求からやり直す。この詳細については後述する。
【００９３】
なお、やり直しの処理は自動的に行うように設計することも可能である。しかし、処理中断の主要な要因としては電波状態が悪いことが考えられるので、ユーザが電波状態の良い場所へ移動して自らの判断で処理をリトライすることが好適であると考えられる。但し、電波状況をウオッチしながらリトライするという処理も可能である。
【００９４】
図２８は、図１６に対応した管理サーバの動作を示すフローチャートである。管理サーバは、端末からログインがあったとき（Ｓ７４１）、当該ユーザのマイメニューを当該端末へ送信する（Ｓ７４２）。その後、端末から購入要求があれば（Ｓ７４３）、課金サーバに対して課金要求を送信する（Ｓ７４４）。課金サーバからの応答を待ち（Ｓ７４５）、課金ＯＫでなければ（Ｓ７４６，Ｎｏ）、「課金ＮＧ」の通知を端末へ送信する（Ｓ７４７）。課金ＯＫであれば、マイメニューの更新を行って（Ｓ７４８）、ＨＴＭＬ送信を行う（Ｓ７４９）。その後、端末からＡＤＦ要求があれば（Ｓ７５０）、ＡＤＦを作成して（Ｓ７５２）、これを端末へ送信する（Ｓ７５３）。ＡＤＦ要求が所定時間以上なかったときには（Ｓ７５１）、本処理を終了する。
【００９５】
なお、ステップＳ７４９のＨＴＭＬ送信後に、一度処理を中止し、ＡＤＦ要求があった場合にＡＤＦ作成／送信を行うようにしてもよい。
【００９６】
図２９および図３０は、それぞれ端末および管理サーバにおける上述したリトライＴｙｐｅＡ処理の処理例を示す。このタイプのリトライでは、既に課金処理が終了し、マイメニューの更新が完了しているので、ユーザは、端末からサービスにログインし、マイメニューに表示された対象アプリを選択することにより、ＨＴＭＬ受信要求以降の処理をリトライすることができる。
【００９７】
より具体的には、図２９において、端末は、サービスログイン（Ｓ７６１）後にマイメニューを受信して表示し（Ｓ７６２）、ユーザからダウンロードの選択を受け付ける（Ｓ７６３）。そこで、マイアプリ一覧を受信して表示する（Ｓ７６４）。ユーザからダウンロード対象のアプリ選択を受けると（Ｓ７６５）、対応するＨＴＭＬ要求を送信し（Ｓ７６６）、対応するＨＴＭＬを受信する（Ｓ７６７）。ついで、このＨＴＭＬ受信が正常に完了したかをチェックする（Ｓ７６８）。正常でなければ、上述したようなリトライＴｙｐｅＡ要求メッセージを表示する（Ｓ７６９）。正常であれば、そのＨＴＭＬを解釈し（Ｓ７７０）、ＧＥＴ＿ＡＤＦコマンドを送信する（Ｓ７７１）。ついで、これに応じたＡＤＦを受信し（Ｓ７７２）、その受信が正常に完了したか否かをチェックする（Ｓ７７３）。正常でなければ、上述したようなリトライＴｙｐｅＢメッセージを表示する（Ｓ７７４）。正常であれば、ＪＡＭを起動する（Ｓ７７５）。ＪＡＭは、ＡＤＦ情報に従ってアプリベンダのサイトに接続し、Ｊａｒファイルを要求する（Ｓ７７６）。次いで、管理サーバからＪａｒファイルの受信を行う（Ｓ７７７）。その後、端末はＪａｒファイルを正常に受信したか否かをチェックする（Ｓ７７８）。Ｎｏの場合、上述したようなリトライＴｙｐｅＣ要求メッセージを表示する（Ｓ７７９）。
【００９８】
図３０において、管理サーバは、端末からのログインを受け付けると（Ｓ７８１）、当該ユーザのマイメニューを送信し（Ｓ７８２）、さらにマイアプリ一覧を送信する（Ｓ７８３）。ついでダウンロード要求を受信すると（Ｓ７８４）、ＨＴＭＬを送信する（Ｓ７８５）。その後、端末からＡＤＦ要求があれば（Ｓ７８７）、ＡＤＦを作成して（Ｓ７８８）、これを端末へ送信する（Ｓ７８９）。ＡＤＦ要求が所定時間以上なかったときには（Ｓ７８６）、本処理を終了する。
【００９９】
図３１および図３２は、それぞれ端末および管理サーバにおける上述のリトライＴｙｐｅＢ処理の一例を示している。このタイプでは、ＨＴＭＬ受信が正常に完了しているため、端末は、ＨＴＭＬに埋め込まれたＧＥＴ＿ＡＤＦコマンドを持っている状態である。従って、例えば、リトライＴｙｐｅＢ処理メッセージの中にＡＤＦ再要求の指示用のボタンを埋め込んでおき、このボタンをユーザが指示することで、ＡＤＦ再要求の指示を受け付ける。これによって、端末は、オフラインであれば管理サーバへの接続を行った後、ＨＴＭＬを解釈し、ＧＥＴ＿ＡＤＦコマンドを管理サーバへ送信する。管理サーバは常時ＧＥＴ＿ＡＤＦコマンドを待受けており、ＧＥＴ＿ＡＤＦコマンドを受信するとＡＤＦを作成し、端末へ送信する。
【０１００】
より具体的には、図３１において、端末は、ユーザからのＡＤＦ再要求の指示が受けたとき（Ｓ８０１）、前記ＨＴＭＬの解釈を行って（Ｓ８０２）、ＧＥＴ＿ＡＤＦコマンドを送信する（Ｓ８０３）。ついで、これに応じたＡＤＦを受信し（Ｓ８０４）、その受信が正常に完了したか否かをチェックする（Ｓ８０５）。正常でなければ、上述したようなリトライＴｙｐｅＢメッセージを表示する（Ｓ８０６）。正常であれば、ＪＡＭを起動する（Ｓ８０７）。ＪＡＭは、ＡＤＦ情報に従ってアプリベンダのサイトに接続し、Ｊａｒファイルを要求する（Ｓ８０８）。次いで、管理サーバからＪａｒファイルの受信を行う（Ｓ８０９）。その後、端末はＪａｒファイルを正常に受信したか否かをチェックする（Ｓ８１０）。Ｎｏの場合、上述したようなリトライＴｙｐｅＣ要求メッセージを表示する（Ｓ８１１）。
【０１０１】
図３２において、管理サーバは、端末からＡＤＦ要求があれば（Ｓ８２１）、ＡＤＦを作成して（Ｓ８２３）、これを端末へ送信する（Ｓ８２４）。ＡＤＦ要求が所定時間以上なかったときには（Ｓ８２２）、本処理を終了する。
【０１０２】
図３３および図３４は、それぞれ端末およびダウンロードサイト（アプリベンダ）のサーバにおける上述のリトライＴｙｐｅＣ処理の一例を示している。この処理はプレイリストからの最新版取得と同一の処理である。このタイプのリトライでは、ＡＤＦ受信が完了しているため、端末内のプレイリストを参照することが可能である。ただし、ＡＤＦ情報のみが存在しＪａｒファイルが無いので実体データが存在しない。そこで最新版取得の処理を実行し、Ｊａｒファイルを取得する。
【０１０３】
より具体的には図３３において、端末はユーザによりブラウザが起動され（Ｓ８３１）、ユーザによるメニューからのプレイリストの選択を受けると（Ｓ８３２）、プレイリスト画面を表示する（Ｓ８３３）（図１８、１９参照）。その後、プレイリストから対象のアプリの選択を受ける（Ｓ８３４）。選択されたアプリは強調表示（例えばハイライト表示）される。アプリが選択された状態で（Ｓ８３４）、プレイリスト上部の『最新版取得』が指示されると（Ｓ８３５）、ＪＡＭが起動し、拡張された期限管理機能によって、ＡＤＦ情報が読み出され（Ｓ８３６）、その中の使用期間情報を参照して期限超過か否か判定する（Ｓ８３７）。期限超過の場合には、ダウンロードＮＧメッセージを表示して（Ｓ８３９）、本処理を終了する。リトライ処理では期限超過することは通常ない。期限超過でない場合、Ｊａｒ要求をアプリベンダサイトへ送信し（Ｓ８４０）、Ｊａｒを受信する（Ｓ８４１）。所定時間内にＪａｒが受信されなかったときには（Ｓ８４２）、上述したようにリトライＴｙｐｅＣ要求メッセージを表示して（Ｓ８４３）、本処理を終了する。
【０１０４】
図３４において、アプリベンダサイトのサーバは、端末からＪａｒ要求を受けると（Ｓ８５１）、そのＪａｒファイルを当該端末に対して送信する（Ｓ８５２）。
【０１０５】
上記ではリトライＴｙｐｅＣの処理を最新版取得と同一の処理で行ったが、本発明はこれに限定されるものではなく、リトライに特化した処理を実行することも可能である。この場合、使用期間のチェックは不要である。また、プレイリストからアプリ実行を指示した際にＪａｒファイル、すなわちアプリの実体が無い場合に自動的にリトライ動作を行うようにしても良い。
【０１０６】
図１７は、本実施の形態において端末の内蔵する時計を自動的に修正する処理シーケンスを示す。この処理は端末が管理サーバに対してログインしたときに実行される。管理サーバはトップメニュー等のＨＴＭＬファイルを送信するとき（Ｓ４１１）、特定のＭＩＭＥタイプの記述を含めておく。端末は、これに応じて端末のブラウザは特定のプラグインを起動する（Ｓ４１２）。プラグインは管理サーバに所定の制御ファイルを要求する（Ｓ４１３）。これに対して管理サーバは制御ファイル内に現在日時情報を含めて端末に送信する（Ｓ４１４）。端末のプラグインは受信した現在日時と端末内の時計の現在日時とを比較し（Ｓ４１５）、所定時間（例えば５分）以上の誤差がある場合、エラーと判断して、端末の時計を管理サーバの日時に合わせるように修正する（Ｓ４１７）。この制御ファイル内には、時刻チェックのＯＫ時における次のページのＵＲＬおよびＮＧ時のエラーページのＵＲＬ等を含んでもよい。上記特定のＭＩＭＥタイプの利用の代わりに、ＨＴＭＬファイル内に拡張タグとして＜ｅｍｂｅｄ ｓｒｃ＝“Ｇｅｔｃｌｏｃｋ．ｃｇｉ”＞のような記述を埋め込んでおき、これを端末のブラウザで解釈することにより、現在日時情報を含む制御ファイルを要求してもよい。
【０１０７】
図１８（ａ）は端末の外観の一例を示す。図１８（ｂ）は、端末のオフライン状態でのメニュー表示状態を示している。ユーザがこのメニューから「プレイリスト」を選択すると、図１９（ａ）に示すようなプレイリスト画面が表示される。プレイリストは端末に現在保存されているアプリの一覧である。各アプリには利用期間に関する属性マーク（アイコン）が付加され、表示されている。図１９（ｂ）は本実施の形態における５種類のアイコンを示している。アイコン８１は、そのアプリが試用期間中であることを示している。アイコン８２〜８５は利用期間の段階的な残量を示している。すなわち、アイコン８２は、そのアプリの使用期間がほとんど残っていることを示している。アイコン８３は、試用期間が半分以上残っていることを示している。アイコン８４は、使用期限が切れかけていることを示している。アイコン８５は、既に使用期限が切れていることを示している。アイコン８６は、そのアイコンが他のポータルサイトからダウンロードされた使用期限のないものであることを示している。アイコン８１の示す試用アプリの利用期間は通常短期間であり、また、アイコン８６のアプリの利用期間は無期限である。この意味で、アイコン８１も８６も、アプリの利用期間に関する状況を示していると言える。このようなグラフィカルな表示の一種としてのアイコン表示により、ユーザは各アプリの利用期間に関する状況を即座に認識することができる。このように、本実施の形態では、ＡＤＦ中に記述された利用期限属性を参照し、利用期間の残量を算出し、これに対応する表示すべきアイコンを選択している。
【０１０８】
図２３に、図１９のアイコン表示のための処理例を示す。この処理はプレイリストの表示時に実行される処理の一部である。まず、アプリを指定するための変数ｉを１に初期化し（Ｓ６１１）、以下の処理をアプリの個数分繰り返す。続くステップＳ６１２ではアプリｉのＡＤＦをチェックする（Ｓ６１２）。ついで、ＡＤＦ内に利用期限Expiration-Timeが含まれているかを調べる（Ｓ６１３）。含まれていなければこのアイコンは利用期限のないアプリなので、アイコン８６を選択する（Ｓ６１４）。その後、変数ｉが最終のアプリかどうかをチェックし（Ｓ６２８）、最終であれば、処理を終了する。最終でなければ、変数ｉをインクリメントして（Ｓ６１５）、ステップＳ６１２に戻る。ステップＳ６１３で利用期限が含まれていれば、その利用期限と現在日時とに基づいて残存時間を算出する（Ｓ６１６）。残存時間がなし（すなわち０または負）であれば（Ｓ６１７）、アイコン８５を選択し（Ｓ６１８）、ステップＳ６２８へ進む。残存時間がある場合、利用期限Expiration-Timeに文字列“,trial”が付加されているかどうかをチェックする（Ｓ６１９）。付加されていれば、このアプリは試用アプリなのでアイコン８１を選択し（Ｓ６２０）、ステップＳ６２８へ進む。試用アプリでなければ、残存時間と利用期間の単位を変換する（Ｓ６２１）。例えば、日単位の時間をより細かい単位（例えば秒単位）に変換する。この変換処理は必須ではないが、これを行うことによって、より正確な残量の分類判定を行うことができる。ついで、残存時間を利用期間で割った商をＤとする（Ｓ６２２）。このＤの値は、利用期間あたりの残存時間の割合を示す。このＤが１／３未満であれば（Ｓ６２３）、アイコン８４を選択する（Ｓ６２４）。Ｄが１／３以上２／３未満であれば（Ｓ６２５）、アイコン８３を選択する（Ｓ６２６）。そうでなければ、アイコン８２を選択する（Ｓ６２７）。このような処理を変数ｉが最終となるまで繰り返す（Ｓ６２８）。
【０１０９】
図２０（ａ）のプレイリストの各アプリについて、図２０（ｂ）に示すように、端末情報として会員ＩＤ、機種ＩＤ、端末愛称を確認したり、図２０（ｃ）に示すように、アプリの詳細情報としてアプリの名称、バージョンやサイズを確認したり、図２０（ｄ）に示すように、そのアプリの使用期限を確認したりすることができる。図示した例の使用期限は年月日を示しているが、年月日に加えて時刻まで指定するようにしてもよい。
【０１１０】
なお、ユーザは、端末内の限られた記憶容量を有効に利用するために、プレイリスト中の任意のアプリを削除することも可能である。この際、対応するＡＤＦファイルも削除される。但し、管理サーバ内のマイメニューにはマイアプリとして登録されたままである。したがって、削除されたアプリが購入されたアプリで、その利用期間が残存している場合には、ユーザはその利用期間内であれば、必要となったときにサーバからＡＤＦを取得しそのアプリを無料で再ダウンロードすることができる。削除ではなく、本体またはＡＤＦが破損したアプリ等についても同様である。
【０１１１】
図３５は、ＡＤＦ中の使用期間情報を使ったアプリの起動制御を示すフローチャートである。まず、端末においてユーザに指示に応じてブラウザを起動する（Ｓ８６１）。ユーザによるプレイリストの選択があったとき（Ｓ８６２）、プレイリスト画面を表示する（Ｓ８６３）。アプリ起動指示があれば（Ｓ８６４）、現在日時を確認し（Ｓ８６５）、ＡＤＦ情報を読み出す（Ｓ８６６）。そこで、当該アプリの利用期間（利用期限）と現在日時とを比較する（Ｓ８６７）。利用期限を超過していれば、当該アプリの起動を抑止する（Ｓ８６９）。そうでなければ、当該アプリを起動する（Ｓ８７０）。
【０１１２】
図２１は、ユーザが端末にダウンロードしたアプリを実行する際に端末の時計をチェックする処理のフローチャートである。前述したように、端末に内蔵された時計の日時はサーバの時計に合わせられるが、利用期間経過後に時計を意図的に逆行させて不正に有料アプリを使用することが考えられる。本実施の形態では、アプリの起動時にその日時と前回の起動日時とを比較して、時計の進行が自然でないことを検知したときに、アプリの起動を抑止するようにしたものである。
【０１１３】
図２１において、端末（ＪＡＭ）がユーザによりプレイリスト中のアプリの起動指示を受けたとき（Ｓ５１１）、まず、端末内の時計から現在日時を確認する（Ｓ５１２）。ついで、端末内に保存してある当該アプリの前回起動時の日時を確認する（Ｓ５１３）。そこで、両日時を比較し（Ｓ５１４）、今回起動日時が前回起動日時よりも過去であったならば時間が逆行していると判断し、次に端末が管理サーバに接続して端末の時計が管理サーバの時計と同期されるまで当該アプリの起動を抑止する（Ｓ５１５）。これにより、あるアプリの利用期間経過後にユーザが意図的に時計を誤った日時に修正して実行するような不正を防止することができる。ステップＳ５１６での日時の比較時には誤差として数分程度の逆行は許容するようにしてもよい。アプリの起動を抑止した場合には、ユーザに対してその旨の警告メッセージを出力する（Ｓ５１６）。ステップＳ５１４で時間の逆行がないと判断されれば、当該アプリの起動を許容し（Ｓ５１７）、そのときに日時を当該アプリの「前回起動日時」として更新記録しておく。
【０１１４】
図２２は、表示マーク（アイコン）５６の表示された端末画面例を示す図である。この表示マーク５６は、本実施の形態において管理サーバが提供するサービスを利用することができる実行環境を提供するアプリケーション（典型的にはブラウザであり、上述した期限管理機能拡張が組み込まれているもの）がその端末に搭載されていることを示している。前述のように、本発明に係るサービスは端末機種により対応できる場合とできない場合がありうるので、このマーク５６が表示されていれば、ユーザはその端末が当該サービスに対応していることを直ちに認識することができる。この表示マーク５６は単なる表示にとどまらず、何かの処理を起動するための起動アイコンとしてもよい。例えば、この起動アイコンをクリックすると、プレイリストを表示したり、あるいは、ポータルサイトに接続してログインし、マイメニューを表示したりするようにしてもよい。なお、アイコンの図柄、アイコンを表示する画面およびその画面内の位置は図示の例に限るものではない。
【０１１５】
図１に示したストレージサービスサーバ４２０およびプリントサービスサーバ４３０が提供するストレージ提供サービスやプリントサービスについて簡単に説明する。ストレージサービスサーバ４２０が提供するサービスは、ユーザの端末の記憶容量を実質的に拡大するためにユーザが自由に利用できるストレージ領域をユーザにリースするサービスであり、上述のアプリ等と同様、そのリース期間を制限することができる。この場合に端末がダウンロードするアプリ等は、当該サービスを利用するためのアプリおよび／またはデータである。また、プリントサービスサーバ４３０が提供するサービスは、ユーザがアプリ等として例えばデジタルカメラで撮影したデジタル画像データを処理するための処理ソフトウェア等であり、管理サーバに対してその印刷の依頼を行って課金サーバでの課金を行い、プリント対象のデータを管理サーバまたは他の所定のサーバに送信して印刷出力を依頼し、所定の場所（例えばチェーン店の店頭）でその印刷物を受け取ることができる。なお、これらのネットワークサービスでは、ＡＤＦ内のアプリＵＲＬに代えて、当該サービスを提供するサービスＵＲＬを用いることができる。
【０１１６】
以上説明した実施の形態の効果をまとめると次のとおりである。
（１）サーバ運用側で生成したアプリ等の利用期限を示す利用期限属性をアプリケーション等とは別に端末に転送し、利用期限属性に従ってアプリケーション等の利用およびダウンロードを制御するので、アプリ等自体に“時限爆弾”を仕込む必要がなくなり、サーバ運用側（ポータルサイト、ベンダ）が意図する利用期限を設定することができる。
（２）管理サーバと端末との間で両者の時計を一致させることにより、管理サーバ側と端末側とで実質的に同一時間軸上で利用期限を管理できる。
（３）端末では、利用期限属性に従ってローカルにアプリ等を実行する際にも、その利用の制限管理を行うことができる。（２）および（３）によって、より厳密な意味でユーザにアプリ等の利用期限を守らせることができる。
（４）端末側で利用期限を管理するので利用期限の確認のためにサーバに接続する必要が無い。したがって、アプリ等の起動の都度、サーバに接続する手間および通信費の無駄が省ける。
（５）利用期限属性を、ユーザとサーバ運用側との間でのアプリの取引（試用、リース等）が発生するたびに生成するので、利用期間はアプリケーション等ごとに一律である必要がなくなる。さらに、やり取り毎に個別に異なる条件（利用期間等）を設定することもできる。
（６）アプリ本体は、その利用期間内であれば、端末外部からいつでも無料で入手できるので、端末内部の記憶装置の容量が限られていても何の心配も無くアプリ等を削除することができる。
（７）アプリ等のダウンロードに伴う課金時には、アプリ等のダウンロードは利用期間内に何度でもダウンロードできることを保証することにより、実際のアプリ等の本体のダウンロードを行うことなく課金処理を完了することができる。すなわち、管理サーバ側から端末にはアプリ等の本体とは別の（アプリ等の実体を含まない）極めて小さなデータ（ADFファイル）を転送するだけで済むので、その処理が途中で中断する確率はアプリ等の本体のダウンロード処理が中断する確率に比べて極めて小さい。
（８）より厳密な期限管理が可能であるため、極めて短期間（1日、1時間等）の利用期限を定めたアプリ等のリースを実際の経済活動で認められる安全性を確保しながら実現することができる。
（９）ユーザが試用中またはリース中のアプリ等を端末に表示する際に、種別（試用かリースか等）や試用・利用期間の残存状況をアイコン等でグラフィカルに表示することにより、数値表示に比べてユーザは即座に直感的にその状況を認識することができ、便利である。また、アプリ提供側からみれば、利用期間の残量を視覚的に明示することにより、ユーザに利用期間延長の動機付けを与えることができる。
（１０）サーバにおいてユーザ毎に試用やリースを受けているアプリを管理しているので、端末内のアプリ情報（ＡＤＦ）が損なわれたときなどに、サーバで管理している情報に基づいて端末側のアプリ情報を復元することができる。
（１１）ユーザの会員登録時に会員ＩＤのみならずサービスに利用する端末を識別するための端末ＩＤを付与し、これらのＩＤを端末内に保存するとともに、端末ＩＤはユーザにも秘密に管理することによって、ログイン時等に会員ＩＤおよびパスワードの他、端末ＩＤを確認することにより、会員へのいわゆるなりすましを防止することができる。
（１２）ログイン時等に端末の機種ＩＤを管理サーバ側で確認することにより、サービス利用可能な端末を、前述したノンＰＣ端末と呼ばれるパーソナルコンピュータ（以下、ＰＣという）などの特定の端末に制限することができる。これにより、端末内部のローカルストレージ等に記憶された端末ＩＤを不正に読み出されることを防止し、（１１）の効果をより確実なものにすることができる。
（１３）同じ会員についても異なる端末には異なる端末ＩＤを付与することにより、複数のユーザが一人の会員名義で複数の端末を用いて同じ有料アプリ等を使用する不正を防止することができる。
（１４）各端末に端末愛称を付与することにより、未だ利用期間の残存しているアプリ等を登録した端末の「復旧」の際に、目的の端末を特定することができる。
【０１１７】
以上、本発明の好適な実施の形態について説明したが、特許請求の範囲に記載した範囲内で、上記で言及した以外にも種々の変形、変更を行うことが可能である。
【０１１８】
例えば、利用期限経過後にアプリ等の起動等を制限することには、機能の一部制限、「サンプル」や「利用期限経過」のように警告メッセージをオーバーラップ表示することのように、アプリ等の利用を一部制限することも含まれる。
【０１１９】
ポータルサイトに代えて、いわゆるマルチメディア・キオスク（非特許文献１参照）と呼ばれるような、店頭等に備え付けられる据え置き型情報処理装置であってもよい。この装置に自動販売機のような課金システムを搭載していればユーザから現金やクレジットカードを用いて料金を徴収することも可能である。この場合、マルチメディア・キオスクと端末との間の通信は、例えば、赤外線、Bluetooth（商標）等のローカル（近距離）での通信に適した手段を用いることができるが、特に限定されない。
【０１２０】
利用期限は、サーバが計算してＡＤＦファイルに記述する他に、サーバは起算点となる日時と利用期間とをアプリ属性データ中に利用期限属性として記述し、これらに基づいて端末側で利用期限を算出するようにしてもよい。
【０１２１】
端末の時計と管理サーバの時計の同期化の手段として、端末の時計を強制的に管理サーバの時計に合わせる例を示したが、管理サーバ以外の他のサーバにより端末の時計を合わせてもよい。さらに言えば、何らかの方法で端末の時計の適性化が保証されるのであれば、必ずしもサーバの時計に合わせる必要もない。結果として、サーバと端末とで実質的に同一時間軸上で利用期限が管理されれば足りる。
【０１２２】
端末はノンＰＣ端末を例として挙げたが、セキュリティの観点における所要の措置がとられれば、必ずしもノンＰＣ端末である必要はない。すなわち、ネットワーク（インターネットを含む）を介してサーバや他の端末とデータを双方向で交換する能力を有する装置（ネットワーク端末）であればよい。また、アプリ等の実行をシミュレーションするための端末エミュレータ（ＰＣ上で動作するブラウザ＋ＪａｖａＶＭ＋期限管理拡張）であってもよい。
【０１２３】
また、通信において用いるプロトコルは、所期の目的を達成できれば、必ずしも上記のものに限るものではない。
【０１２４】
アプリ等はネットワークを経由してダウンロードする例を示したが、例えば、デジタル放送などの放送網を介して配信元からブロードキャストされるデータを受信するようにしてもよい。
【０１２５】
試用アプリの機能は購入アプリに比べて一部の機能が制限されていてもよい。
【０１２６】
アプリ等の試用は必ずしも必須のものではなく、試用なしにいきなり購入を行うシステムであってもよい。
【０１２７】
アプリの実行はローカルで行う場合を示したが、対戦ゲーム等の場合のように、アプリの実行中の全体または一部においてオンライン状態となるものであってもよい
【０１２８】
各アプリ等の利用期間は一定である例を示したが、同じアプリであってもユーザにそのリース期間を選択させるようにしてもよい。その場合の課金は利用期間に応じて増減しうる。
【０１２９】
利用期間の残量に関するアイコン表示はプレイリストについてのみ説明したが、マイメニュー等、他の画面について行うことも可能である。
【０１３０】
機種ＩＤに応じて、端末に提供するアプリ等の種類や形式等を変更または選択するようにしてもよい。
【０１３１】
端末愛称は本質的には一人の会員が保有する複数の端末を相互に識別できれば足りるので、上記説明ではユーザに指定させるようにしたが、サーバ側が決定してもよい。また、必ずしも愛称は単なる識別情報であってもよい。
【符号の説明】
【０１３２】
５０…ＯＳ、５１…アプリ等、５２…アプリ実行環境、５３…期限管理機能、５５…ＡＤＦ、５６…表示マーク（アイコン）、６１…ＪａｖａＶＭ、６３…拡張部、６４…ＪＡＭ、６５…拡張部、６６…ネットワークサービス対応ＡＰＩ、６７…ローカルストレージ、７０…ブラウザ、８０…Ｊａｖａアプリ、２００…管理センサ、２１０…ポータルサイト、２１５…課金管理部、２２０…管理サーバ、２２５…アプリホルダ、２３０…管理部、２３５…決済口座、２４０…ネットワークサービスインタフェース、２５０…ユーザデータベース、２５３…マイメニュー、２６０…アプリデータベース、３００…アプリベンダ、４００…サービス事業者、４２０…ストレージサービスサーバ、４３０…プリントサービスサーバ
【技術分野】
【０００１】
本発明は、主としてネットワークを介して、利用期限（使用期限）付きのアプリケーション等を提供するシステムに関し、特にその利用期限を効果的に管理する方法およびサーバに関する。
【背景技術】
【０００２】
近年、インターネット関連技術や移動体通信技術等の発達により、携帯電話端末、携帯情報端末等の移動端末を用いた電子商取引が普及してきている。（本明細書において、端末装置を単に端末という。）
【０００３】
例えば、コンピュータネットワーク上から情報端末上で動作するアプリケーション等をダウンロードさせ、それを有償または無償で一定期間（以下、利用期間という）に限り利用を認める電子商取引が検討されている。
【０００４】
ダウンロードしたアプリケーション等を利用期間内に限り利用を認めるために、例えば、利用期間の終了時に当該アプリケーション等の利用を禁止する仕組であるいわゆる「時限爆弾」その他の禁止手段をアプリケーション等に組み込むことが行われている（特許文献１参照）。この利用期限は、一般的には、端末にアプリケーション等をインストールした日時（端末側の時計（カレンダ）が示すもの）を起算点として予め定めた利用期間の日数等をカウントして算出されている。
【０００５】
また、使用回数に制限を設け、例えばアプリケーションを起動するたびにある計数値をインクリメントし、この計数値が所定値を超えたならば起動を制限する方法もある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平１０−２２２５７９号公報
【非特許文献】
【０００７】
【非特許文献１】野村総合研究所著、「ユビキタス・ネットワーク」、２０００年１２月２０日、野村総合研究所発刊
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記従来の技術においては、次のような問題があった。
【０００９】
例えば、ベンダが個々のアプリケーション等に禁止手段を組み込む必要があり、ベンダの負担となる。また、その利用期限は一律のものとならざるを得ない。
【００１０】
また、利用期間の起算点がクライアント側で決まるため、ベンダ側で起算点を決めることができない。このため、正確に利用期間を把握することが困難であり、また、正確に利用期間を守らせることも困難である。
【００１１】
利用回数に制限をつける場合、アプリケーション等の起動回数はサーバには分からないので端末においてのみ管理されることになり、サーバ側で利用期限を管理することが困難である。また、端末側で利用期限に関するデータの書換えを行うと、このデータが利用制限に関連していることが容易に推察され、これを不正に書き換えて利用制限を越えた不正使用が行われやすくなる。
【００１２】
さらに、従来のダウンロード販売（アプリケーション等をダウンロードするときに課金する方式）の場合、ダウンロードが途中で中断する場合があるため、ダウンロード完了を確認する必要がある。これはサーバ側では面倒な処理である。アプリケーション等のダウンロードが途中で中断した場合に備えて、一定期間再ダウンロードすることを認める場合もあるが、この期間を経過すればダウンロードできない。これでは、ユーザがお金を支払ったにも関わらずアプリケーション等を取得できないという事態が発生するおそれがある。
【００１３】
本発明はこのような背景においてなされたものであり、その目的は、ユーザに認識されない端末ＩＤをサーバ側から各端末に割り当てることにより、サービスの登録会員および端末の認証をより的確に行うことにある。端末に提供される利用期限付きのアプリケーション等の利用期限を、サーバおよび端末の双方で管理し、かつ、端末において確実に守らせることができるアプリケーション等利用期限管理システム、サーバおよびコンピュータプログラムを提供することにある。
【００１４】
本発明による他の目的は、サービスの登録会員の端末の追加、復旧を容易に可能とする端末管理方法を提供することにある。
【００１５】
本発明による別の目的は、アプリケーション等の利用期限の状況をユーザが迅速、容易に認識することができる、端末上で動作するコンピュータプログラムを提供することにある。
【００１６】
本発明によるさらに別の目的は、端末において本発明に係るサービスが利用できることをユーザに迅速容易に認識させることができる端末を提供することにある。
【課題を解決するための手段】
【００１７】
本発明によるアプリケーション等利用期限管理システムは、端末とサーバからなるシステムにおいて、サーバはアプリケーション等の少なくとも利用期限に関する利用期限属性をアプリケーション等とは別に端末に転送し、端末は前記利用期限属性を参照し利用期限を経過したならばアプリケーション等の利用を制限する利用期限管理手段を備えたことを特徴とする。
【００１８】
前記利用期限管理手段は、例えば、端末のアプリケーション等の実行環境の一部として提供される。
【００１９】
前記利用期限は、例えば、サーバと端末との間でのアプリケーション等の利用に関するアクションを起算点として所定の利用期間が満了するときであり、前記利用期限属性は、アクションが発生するたびに生成される。
【００２０】
サーバおよび端末は実質的に同一の時間軸上で利用期限を管理する。そのために、例えば、端末は、サーバへの接続時に、当該サーバと自己の現在時刻とが所定時間以上ずれているときに、自己の現在時刻をサーバの指示に応じてサーバの管理する時刻に合わせる。また、端末は、アプリケーション等を利用したときの利用時刻を記録し、次にアプリケーション等を利用するとき、前記利用時刻を今回の利用時刻と比較し、両者の関係が予め定めた関係にある場合にはアプリケーション等の利用を制限する。
【００２１】
前記利用期限属性は当該アプリケーション等の入手先情報とともに端末に転送され、端末は前記入手先情報に基づいて当該アプリケーション等を入手する。一旦、入手先情報が得られれば、端末は利用の権利がある限り、当該アプリケーション等をいつでも入手できるので、前記アプリケーション等の入手の前に当該アプリケーションの利用権に対する課金を行うことができる。
【００２２】
また、端末は、サーバから取得し、内部に保存されているアプリケーション等を一覧表示し、その際、好ましくは、各アプリケーション等の利用期間の残量をグラフィカルに表示する。
【００２３】
サーバによる端末管理方法は、サーバの提供するサービスをユーザが端末から利用するための会員登録を行う際、ユーザの個人情報の入力を受けるステップと、当該ユーザに会員ＩＤを割り当てるステップと、当該端末に対して端末ＩＤを割り当てるステップと、前記端末ＩＤを当該会員ＩＤに対応付けてサーバ側で管理するステップと、前記会員ＩＤおよび端末ＩＤを前記端末に送信して端末内に格納させるステップとを備えたことを特徴とする。
【００２４】
これに加えて、端末からの接続を受けた際に、当該端末の機種ＩＤの送信を受け、この機種ＩＤが所定の機種ＩＤであることを確認するステップをさらに備えてもよい。
【００２５】
前記端末ＩＤは、好ましくは、当該ユーザが認識できないようにサーバおよび端末において管理されるものである。
【００２６】
サーバは、好ましくは、サーバの提供するサービスに対して端末が接続してきた際に、前記端末から前記会員ＩＤ、端末ＩＤおよびパスワードの入力を受け、サーバの管理する当該ユーザの会員ＩＤ、端末ＩＤおよびパスワードと対照してログインの可否を決定するステップとを備える。
【００２７】
前記会員ＩＤおよび端末ＩＤの入力はユーザの指示によらず端末が自動的に送信する。
【００２８】
本発明によるサーバは、会員登録を受けたユーザの端末を管理するサーバであって、ユーザの個人情報の入力を受ける手段と、当該ユーザに会員ＩＤを割り当てる手段と、当該端末に対して端末ＩＤを割り当てる手段と、前記端末ＩＤを当該会員ＩＤに対応付けてサーバ側で管理するデータベースと、前記会員ＩＤおよび端末ＩＤを端末内に格納させるために前記端末に送信する手段とを備えたことを特徴とする。
【発明の効果】
【００２９】
本発明によれば、サーバ側から端末に提供される利用期限付きのアプリケーション等の利用期限を、サーバおよび端末の双方で管理することにより、端末において確実に守らせることができるようになる。
【００３０】
また、ユーザに認識されない端末ＩＤをサーバ側から各端末に割り当てることにより、サービスの登録会員および端末の認証をより的確に行うことができるようになる。
【００３１】
さらに、各端末に端末愛称を付与することにより、サービスの登録会員の端末の追加、復旧が容易となる。
【００３２】
アプリケーション等の一覧表示において、アプリケーション等の利用期限の状況をアイコン表示することにより、ユーザが迅速、容易に認識することができるようになる。
【００３３】
また、端末において本発明に係るサービスが利用できることを所定のマークを表示することにより、当該端末上で上記サービスが利用できることをユーザに迅速容易に認識させることができる。
【図面の簡単な説明】
【００３４】
【図１】本発明の実施の形態におけるシステムの概略構成を示すブロック図である。
【図２】本発明の実施の形態におけるサービスのフローを示すフローチャートである。
【図３】本発明が適用されるアプリ等およびその実行環境を示す図である。
【図４】本発明の実施の形態における会員データベースの構成例を示す図である。
【図５】本発明の実施の形態における会員と会員ＩＤと端末ＩＤとマイメニューの関係を示す図である。
【図６】本発明の実施の形態におけるアプリデータベースの構成例を示す図である。
【図７】本発明の実施の形態におけるＡＤＦ情報の一例を示す図である。
【図８】本発明の実施の形態における、ユーザ側から見た本サービス利用の流れを説明するフローチャートである。
【図９】本発明の実施の形態における会員登録時の端末と管理サーバとの間のやりとりを示す処理シーケンス図である。
【図１０】本発明の実施の形態における会員登録時の端末の画面遷移の例を示す図である。
【図１１】本発明の実施の形態における端末登録時の端末の画面遷移の例を示す図である。
【図１２】本発明の実施の形態において、会員登録を行ったユーザが本サービスを利用する際のログイン画面（ａ）とログイン後に表示されるトップメニュー（ｂ）を示す端末画面例を示す図である。
【図１３】本発明の実施の形態において、アプリメニューからアプリ試用の申込を行う際のシステム各部の処理を示すシーケンス図である。
【図１４】本発明の実施の形態におけるアプリメニュー（ａ）およびカテゴリ一覧（ｂ）の端末の画面例を示す図である。
【図１５】本発明の実施の形態におけるマイメニューから利用期間の更新（購入も含む）を行う際の画面遷移の例を示す図である。
【図１６】本発明の実施の形態におけるアプリ更新申込時のシステム各部の処理のシーケンス図である。
【図１７】本発明の実施の形態における端末の内蔵する時計を自動的に修正する処理のシーケンス図である。
【図１８】本発明の実施の形態における端末の外観（ａ）およびオフライン状態でのメニュー表示状態（ｂ）を示す図である。
【図１９】本発明の実施の形態におけるプレイリスト画面（ａ）および各アプリの利用期間に関する属性マーク（アイコン）（ｂ）を示す図である。
【図２０】本発明の実施の形態における各種の情報の表示画面例（ａ）〜（ｄ）を示す図である。
【図２１】本発明の実施の形態において、アプリを実行する際に端末の時計をチェックする処理のフローチャートである。
【図２２】本発明の実施の形態における表示マーク（アイコン）の表示された端末画面例を示す図である。
【図２３】図１９のアイコン表示のための処理例のフローチャートである。
【図２４】端末１０の一例としての携帯電話機１０Ａの構成例を示すブロック図である。
【図２５】端末１０の他の例としてのＰＤＡ１０Ｂの構成例を示すブロック図である。
【図２６】本発明の実施の形態におけるネットワーク構成の一例を示す図である。
【図２７】図１６に対応した端末の動作を示すフローチャートである。
【図２８】図１６に対応した管理サーバの動作を示すフローチャートである。
【図２９】図２７に示したリトライＴｙｐｅＡ処理の端末における処理例を示すフローチャートである。
【図３０】図２７に示したリトライＴｙｐｅＡ処理の管理サーバにおける処理例を示すフローチャートである。
【図３１】図２７に示したリトライＴｙｐｅＢ処理の端末における処理例を示すフローチャートである。
【図３２】図２７に示したリトライＴｙｐｅＢ処理の管理サーバにおける処理例を示すフローチャートである。
【図３３】図２７に示したリトライＴｙｐｅＣ処理の端末における処理例を示すフローチャートである。
【図３４】図２７に示したリトライＴｙｐｅＣ処理のダウンロードサイト（アプリベンダ）のサーバにおける処理例を示すフローチャートである。
【図３５】本発明の実施の形態におけるＡＤＦ中の使用期間情報を使ったアプリの起動制御を示すフローチャートである。
【発明を実施するための形態】
【００３５】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００３６】
図１に、本実施の形態におけるシステムの概略構成を示す。本システムは、複数の端末１０、管理センタ２００、アプリベンダ３００、ストレージサービスサーバ４２０およびプリントサービスサーバ４３０により構成される。システムのこれらの構成要素間は、インターネット等のネットワークを介して相互に接続される。
【００３７】
管理センタ２００はアプリベンダ３００において開発されたアプリケーション等（アプリケーション、電子データ等）を管理し、端末１０のユーザの利用に供する。なお、本明細書中、アプリケーションを単にアプリともいう。管理センタ２００は、また、ストレージサービスサーバ４２０およびプリントサービスサーバ４３０が提供するストレージ提供サービスやプリントサービス等のネットワークサービスを端末１０のユーザに対して仲介する。
【００３８】
このような機能を達成するために、管理センタ２００は、インターネットのＷＷＷのためのポータルサイト２１０および管理サーバ２２０を備える。ポータルサイト２１０は課金管理部２１５を有し、有料のアプリ等やサービスに対して電子マネー等による課金を行う機能を有する。ポータルサイト２１０は、当然ながら、ウェブサーバおよび各種ＣＧＩ（図示せず）等を有する。管理サーバ２２０は、アプリベンダ３００から提供されるアプリ等を格納するアプリホルダ２２５、ストレージサービスサーバ４２０およびプリントサービスサーバ４３０の仲介となるネットワークサービスインタフェース２４０、およびこれらのアプリ等やサービスの管理を行う管理部２３０を有する。管理部２３０は、後述するように会員データベース（ＤＢ）１５０およびアプリデータベース２６０を備えている。図の例ではアプリ等として、Ｊａｖａ（登録商標）アプリを示している。
【００３９】
本実施の形態における端末１０は、いわゆるノンＰＣ端末と呼ばれる、パーソナルコンピュータ（以下、ＰＣという）以外のネットワーク端末である。ノンＰＣ端末は、ＰＣに比べて、（ａ）ＣＰＵの処理速度が遅い、（ｂ）実行メモリ（ＲＡＭ）の容量が小さい、（ｃ）ローカルストレージが小さい（ギガ単位のハードディスクではなく一般にメガ単位のフラッシュメモリが用いられている）、（ｃ）拡張性が低い（拡張ポートなどを持たない）、（ｄ）操作性が低い（キーボートとマウスではなく、テンキー、４方向カーソルキー、タッチパネル等で操作する）、（ｅ）表示画面が小さいなどの特徴を有する。このため、ノンＰＣ端末は、ＰＣに比べてハードウエアおよびソフトウエアの両面で制約が多い。ノンＰＣ端末は、具体的には、個人情報端末（Personal Digital Assistant：ＰＤＡ）を含む。ＰＤＡがＬＡＮインタフェース、モデム、無線通信機等の通信機能部を内蔵していてもよいし、コンパクトフラッシュ（登録商標）カードスロット等の拡張スロットを備え、これにＬＡＮカード、モデムカード、無線通信カード等の通信拡張カードを挿入し、通信を行うものであってもよい。ＰＤＡは、一般的には携帯可能なものであるが、机上等に据え置きで使うものも含まれる。ＰＤＡの中には腕時計に組み込まれたものも存在する。ノンＰＣ端末は、ネットワーク家電端末（ネット家電端末、インターネットアプライアンス（Internet Appliance）、情報家電端末とも呼ばれる）を包含する。ネットワーク家電端末は、コンピュータネットワーク（インターネットを含む）に接続する機能を有する家電機器である。ネットワーク家電端末は、具体的には、インターネットテレビ、デジタルテレビ、ＣＡＴＶ等のためのセットトップボックス、ゲーム機、固定電話、ＦＡＸ、プリンタ、複写機、スキャナのような通信と比較的関係が深い電子機器はもちろんのこと、冷蔵庫、電子レンジ、電気湯沸しポット、電気炊飯器、コーヒーメーカー、冷暖房装置などであってネットワークに接続可能な家電機器をも包含する。さらに、ノンＰＣ端末は、移動体通信機器を包含する。移動体（モバイル）通信機器とは、人または乗り物に付随して移動する端末機器であり、例えば、携帯電話、ＰＨＳ端末、カーナビゲーション端末、カーオーディオ機器、車載ラジオ、車載テレビ、車載ビデオ、デジタルカメラなどを含む。
【００４０】
端末１０は、ウェブを閲覧するためのブラウザ７０、アプリ等のダウンロードおよびファイル管理等を行うＪＡＭ(Java Application Manager)６４、ダウンロードされたアプリ等を保存するローカルストレージ６７、アプリ８０を実行するアプリ実行部６０を備える。なお、図における端末１０のブロック内のローカルストレージ６７はハードウェアであるが、それ以外のブロックはソフトウェアであり、ローカルストレージ６７内に格納されうる。
【００４１】
アプリ実行部６０は、本実施の形態では、ＪａｖａＶＭ(Java Virtual Machine)６１、クラスライブラリ６２、およびネットワークサービス対応のＡＰＩ（Application Program Interface）６６を有している。ＪａｖａＶＭ６１は、Ｊａｖａのバイトコードを実行するモジュールであり、図示しないＯＳ上で動作する。
【００４２】
ＪＡＭ６４は、Ｊａｒファイル、ＡＤＦ(Application Descriptor File)ファイル等のダウンロード、ＡＤＦファイルの解析等の管理を行い、ＪａｖａＶＭ６１とのメッセージのやりとりを行う。Ｊａｒファイルは、Ｊａｒ形式のＪａｖａアプリケーションであり、アプリ本体である。ＡＤＦファイルは、アプリ等の試用、購入、更新等（アプリ等の利用に関するアクション）に応じてＪａｒファイルをダウンロードするのに先立ってダウンロードされるアプリ属性データであり、Ｊａｒファイルのダウンロードの可否やオンライン課金の可否の判断、Ｊａｒファイルのコード署名の認証を行うために利用される。本実施の形態ではこのＡＤＦファイルに利用期限属性を付与する。この利用期限属性等の導入に伴う各種処理を行うための拡張部６５をＪＡＭ６４に設けている。
【００４３】
具体的には、拡張部６５は、ダウンロードされたアプリケーションの使用期限の管理、時計（カレンダ機能を含む）の管理、会員ＩＤおよび端末ＩＤ等の管理、課金に必要なセキュリティ機能（暗号化、アプリケーションのコード署名によるユーザのアクセス可能リソース（主にネットワークドメイン）の範囲の限定）、およびこれらの管理機能をユーザにガイドするためのユーザインタフェースを提供する。
【００４４】
ネットワークサービス対応のＡＰＩ６６は、ユーザが特定のアプリから、ファイル操作や印刷の要求を行ったときに、この要求をサーバ側のインタフェース２４０に連絡する機能を有する。
【００４５】
端末１０が利用するアプリは管理サーバ２２５内のアプリホルダ２２５からダウンロードする以外にも、アプリベンダ３００等から直接ダウンロードすることも可能である。
【００４６】
図２４に、端末１０の一例としての携帯電話機１０Ａの構成例を示す。この携帯電話機１０ＡはＣＰＵ１１０により制御される。このＣＰＵ１１０にはＲＡＭ１１１、ＲＯＭ１１２、無線通信部１１３、表示装置１１５、入力Ｉ／Ｏインタフェース１１６、および音声処理部１２０が接続される。ＲＡＭ１１１はＣＰＵ１１０に対してデータの一時記憶領域や作業領域を提供するメモリである。ＲＯＭ１１２はＣＰＵ１１０の実行する制御プログラムや各種のデータを格納する不揮発性のメモリである。ＲＯＭ１１２は、例えばフラッシュメモリのような再書き込み可能な不揮発性メモリを含んでもよい。本実施の形態のＪａｒファイルやＡＤＦファイルはＲＡＭ１１１および／またはＲＯＭ１１２に格納される。無線通信部１１３はアンテナ１１４を介して基地局との間で音声およびデータの無線通信を行う部位である。表示装置１１５は液晶ディスプレイを代表とする表示デバイスであり、その表示画面上にテキスト、画像等の各種情報を表示する。入力Ｉ／Ｏインタフェース１１６は、カーソルキー１１７、エンターキー１１８、ダイヤルキー１１９などに接続され、ユーザからの入力操作を受け付ける部位である。音声処理部１２０は、マイク１２１およびスピーカー１２２に接続され、ユーザの音声通話や音楽等の再生を行う部位である。データの符号化／復号化処理や音声処理はＣＰＵ１１０が行ってもよいし、別個のプロセッサ（図示せず）で行ってもよい。
【００４７】
図２５は、端末１０の他の例としてのＰＤＡ１０Ｂの構成例を示す。このＰＤＡ１０Ｂは、ＣＰＵ１３０により制御される。このＣＰＵ１３０にはＲＡＭ１３１、ＲＯＭ１３２、ＣＦカードインタフェース（Ｉ／Ｆ）１３３、表示装置１３５、入力Ｉ／Ｏインタフェース１３６が接続される。ＲＡＭ１３１およびＲＯＭ１３２は、携帯電話機のＲＡＭ１１１およびＲＯＭ１１２と同様である。ＣＦカードインタフェース（Ｉ／Ｆ）１３３は、無線通信機能を付加する無線通信カード１３４を装着するためのインタフェースであり、この無線通信カード１３４により基地局との通信が可能となる。表示装置１３５は、携帯電話機の表示装置１１５と同様の表示デバイスであるが、通常、その画面サイズは携帯電話機のそれより大きい。入力Ｉ／Ｏインタフェース１３６は、タッチパネル１３７やボタン１３８からに対するユーザ操作を受け付ける部位である。
【００４８】
いずれの端末においても、ユーザは、複数のメニュー項目から任意の一つを選択し、所望の画面へ移ることができる。メニュー項目の選択は、例えば、携帯電話機においては、カーソルを選択を望むメニュー項目へ移動させる。カーソルが指示するメニュー項目は、例えばハイライト表示により強調される。次に、エンターキーを押し下げることにより、現在カーソルが指示するメニュー項目が選択される。また、ＰＤＡの場合には、タッチパネルディスプレイ上でメニュー項目をペンでタップ（tap）することにより当該メニュー項目を選択することができる。
【００４９】
図２６に、本実施の形態におけるネットワーク構成の一例を示す。携帯電話機１０ＡやＰＤＡ１０Ｂは、基地局１４０を介して無線ネットワーク（Wireless Network）１４５に接続される。無線ネットワーク１４５は例えば携帯電話パケット通信網である。無線ネットワーク１４５はゲートウェイ(Gateway）１５５を介してインターネット１５７に接続される。ゲートウエイ１５５は、無線ネットワーク１４５とインターネット１５７との間でプロトコル変換を行うと共に、ユーザ毎に送受信したパケットに対して課金を行う。インターネット１５７には、管理サーバ２２０、課金サーバ２７０、およびアプリベンダ３００等の各種サーバが接続される。従って、端末１０と管理サーバ２２０、課金サーバ２７０及びアプリベンダ３００との間の通信は無線ネットワーク１４５、ゲートウエイ１５５、インターネット１５７を介して行われる。ゲートウェイ１５５での課金方式はこれに限定されるものではない。例えば通信を行った時間に対して課金を行うことも可能である。
【００５０】
図２に、本実施の形態におけるサービスのフローを説明する。
【００５１】
まず、アプリベンダ３００が開発したアプリ８０を管理センタ２００の管理サーバ２２０内の管理部２３０に登録し、アプリをアプリホルダ２２５内に格納する（1）。この際、必須ではないが、管理センタ２００の運用者はアプリの受託費用を徴収することができる。管理センタ２００はポータルサイト２１０において、端末１０のユーザから、本サービスの会員登録を受ける（2）。これと共に、電子商取引のために当該会員の決済口座２３５を開設する（3）。本実施の形態では決済の方法として電子マネーを用いるが、本発明はこれに限定されるものではない。
【００５２】
その後、会員であるユーザは端末１０からポータルサイト２１０にアクセスして、所望のアプリを選択してダウンロードする（4）。本実施の形態では、当初、利用期間を限って、アプリを無料でユーザの試用に供する（5）。ユーザはそのアプリを気に入れば、管理サーバ２２０に対して継続利用の登録（購入申込）を行うことができる（6）。この段階で初めてユーザは利用料の支払いを行う（7）。これによって、ユーザはそのアプリの正式な利用権利を取得する（8）。本実施の形態では、利用可能な期間の制限を設けるリースの形式でアプリを提供する。ここでリースとは、広く貸与の意味で用いており、レンタルと同意である。ユーザが保持する権利は、利用期限付きのアプリ等の利用権（ライセンス）である。言い換えれば、ある期間アプリ等を利用する権利を購入することである。これにより、ユーザはその利用期間に応じた対価を支払えば足り、必要に応じて利用期間を延長したり、利用期間経過後に再購入したりすることができる。利用料から管理センタ２００の手数料を減じたものがアプリベンダ３００に分配される（9）。アプリがネットワークサービス対応アプリの場合、そのアプリを実行することにより、ストレージサービスやプリントサービスを受けることができる。ストレージサービスは、ポータルサイト等で会員毎にストレージ領域を貸し出すサービスである。また、プリントサービスは、会員の提供するデジタル写真データ等の印刷出力を行うサービスである。これらのネットワークサービスにも利用期限が付加され、ユーザはその利用期間内に利用料を支払って当該サービスを受けることができる（10，11）。この利用料から管理センタ２００での手数料を減じたものがサービス事業者４００に分配される（12）。
【００５３】
図３（ａ）に示すように、本発明の端末の基本モデルは、ＯＳ５０の上に配置されたアプリ等実行環境５２上でアプリ等が利用され、かつ、アプリ等実行環境５２に付随した期限管理機能５３が個々のアプリ等の利用期限の管理を行う。本実施の形態におけるアプリ等とは、上記Ｊａｖａアプリのようなアプリケーションプログラムやその構成要素の一部の他にも、テキスト、画像、動画、音楽、マークアップ言語ファイル等のようなＷｅｂコンテンツ等も含むものである。また、アプリ実行環境とは、ＯＳ上で実行され、アプリ等をユーザが利用するための環境を提供するプログラムまたはプログラム群をいう。アプリ等の利用には、閲覧、視聴、利用、実行等の種々の行為を含む。
【００５４】
図３（ｂ１）（ｂ２）（ｂ３）、（ｃ）〜（ｆ）は、種々のアプリ等の例と、その実行環境の例を示したものである。すなわち、図３（ｂ１）〜（ｂ３）は、アプリケーションプログラムとその実行環境を示す。図３（ｂ１）に示すように、Ｊａｖａアプリケーションについては、Ｊａｖａ仮想マシンがＪａｖａバイトコードを実行する。また、図３（ｂ２）に示すように、例えばＣ言語で作成され、コンパイルされたアプリケーション実行ファイル（いわゆるexe file）は、ローダーによりメモリ上にロードされ、ＣＰＵにより実行される。図３（ｂ３）に示すように、本システムでダウンロードの対象となるアプリケーション実行ファイルは、他のコンポーネントと共に実行されるアプリケーションプログラムの一部であってもよい。
【００５５】
また、図３（ｃ）〜（ｆ）に示すように、本システムにおけるダウンロードの対象には、画像データ、動画データ、音楽データおよびテキストデータが含まれる。図３（ｃ）に示す画像データは、画像データのフォーマットに対応したビュワーによって展開され、表示される。画像データが圧縮されている場合にはビュワーは伸張も行う。また、図３（ｄ）に示す動画データは、動画データのフォーマットに対応したプレイヤによって再生される。また、図３(ｅ)に示す音楽データは、例えばｍｐ３に代表されるような圧縮形式で圧縮されており、プレイヤは音楽データを伸張し、再生する。さらに、図３（ｆ）に示すテキストデータは、例えば、ＨＴＭＬに代表されるマークアップランゲージにより表示形式が定義されている。ブラウザのようなテキストビュワーは定義に従ってテキストを表示する。
【００５６】
管理センタ２００の管理サーバ２２０は、その提供するサービスの会員情報を管理する会員データベース２５０と、アプリベンダが登録したアプリ等を管理するアプリデータベース２６０を備えている。
【００５７】
図４は、管理サーバ２２０の管理部２３０が保持、管理する会員データベース２５０の構成例を示す。この例では、会員の登録時に各会員毎に会員情報２５１のレコードが作成される。会員情報２５１には、会員ＩＤ、氏名、パスワード、メールアドレス、電話番号（ｔｅｌｎｏ）、誕生日、性別、住所、会員登録日時、最終ログイン日時、抹消フラグの各項目を含む。
【００５８】
この会員情報２５１に対して少なくとも１つの端末情報２５２のレコードが作成される。端末情報２５２は会員が本サービスを利用するために利用する端末に関する情報であり、この例では、会員ＩＤ、端末ＩＤ、端末愛称、端末登録日時、抹消フラグ等の各項目を含む。会員ＩＤは、本サービスへの入会時に会員に一意に割り当てられる会員の識別情報である。端末ＩＤは、本サービスにおける端末の識別情報（例えば通し番号）であり、端末登録時にサーバが一意に割り当てるものである。端末情報２５２のレコードは、一人の会員が登録した端末の個数だけ別個に作成される。
【００５９】
端末情報２５２の各レコードには１対１にマイメニュー２５３が作成される。マイメニュー２５３は、管理サーバが管理、提供するすべてのアプリの中からユーザ（会員）が選択した特定のアプリ群を管理するためのものであり、その端末ＩＤおよびマイメニューＩＤを保持しており、当該会員のみに閲覧が許可される。各マイメニュー２５３には、当該端末に対して新たにアプリの試用または使用が開始されるたびにそのアプリについてマイアプリ情報２５４のレコードが作成される。マイアプリ情報２５４は、マイメニューＩＤ、アプリＩＤ（APPID)／レビジョン番号、利用期間終了日、ダウンロード（ＤＬ）回数カウンタ、購入回数カウンタ、アプリ削除日時等の各項目を含む。「利用期間終了日」がそのアプリの利用期限を示している。「購入回数」は料金支払いを伴うアプリのダウンロード回数であるが、「ダウンロード回数」とは必ずしも一致しない。ダウンロードは有効な利用期間中であれば何度でも行えるからである。
【００６０】
会員データベースの構造から分かるように、本実施の形態では図５に示すように、一人の会員が複数の端末で本サービスを利用する場合、一つの会員ＩＤに対して複数の端末ＩＤが付与され、さらに、その各端末ＩＤに対して独立にマイメニューが作成される。例えば、第１の端末において購入されたアプリ等は第１の端末のマイメニューのみに登録され、他の端末からは利用できない。他の端末で同じアプリ等を利用するには当該他の端末で別途購入する必要がある。このように、すべての端末でアプリ等を共有することはせず、端末毎にマイメニューを割り当てるようにした理由は、（１）複数のユーザが一人の会員名義で複数の端末を用いて同じ有料アプリ等を使用する不正を防止すること、（２）会員が有料アプリ等に電子マネーを支払って有効期限を更新させた場合にその情報を会員が持っている他の全ての端末に伝えるのが困難であること、（３）会員の一つの端末から購入したアプリ等が別の機種で動かない不具合を避けること、等である。なお、未だ利用期間の残存しているアプリ等を登録した端末の故障や紛失等に対処するためには、後述するように端末の「復旧」の機能を設けている。
【００６１】
図６は、管理部２３０が保持、管理するアプリデータベース２６０の構成例を示す。この例では、新たなアプリの登録時にアプリメニュー２６１に新たなアプリ管理レコード２６２が追加される。アプリ管理レコード２６２は、アプリＩＤ、そのリビジョン（改訂番号）、ベンダＩＤ、アプリ名称(Name)、アプリの型（Javatype)、アプリのカテゴリＩＤ、アプリ本登録日時、試用期間、リース単位期間、単価、削除フラグ、アプリＵＲＬ（入手先情報）、アプリサイズ、スクリーンサイズ等の項目を含んでいる。「アプリのカテゴリＩＤ」は後述するアプリメニューでのカテゴリ別のアプリの一覧時に利用される。「アプリ本登録日時」はベンダが正式にアプリを登録した日時である。試用期間はそのアプリの試用可能な期間であり、アプリ毎に、決定される。図の例では３日となっている。「リース単位期間」はユーザの１回の購入（更新も含む）で利用できる期間を示している。「単価」はその１回の購入の料金である。「削除フラグ」はこのアプリの登録を削除した場合に立てられるフラグである。登録アプリが削除された場合にアプリ管理レコード自体を削除する方法もありうるが、本例では削除フラグを設けて、アプリ登録の履歴を残している。「アプリＵＲＬ」は、このアプリ本体の入手できるＵＲＬ(Uniform Resource Locator)であり、管理サーバ２２０内のアプリホルダ２２５だけでなく、ベンダ内のサーバの場合もありうる。「スクリーンサイズ」は端末において当該アプリのための表示エリアのサイズを指定するためのデータである。スクリーンサイズ情報はアプリのダウンロードに伴って端末に送られ、端末のブラウザに解釈されて指定された表示エリアサイズが実現される+
。
【００６２】
本実施の形態では、１回の購入では「リース単位期間」のみの購入を行う場合を想定しているが、ユーザの選択により、１回の購入でリース単位期間×ｎ（ｎは１以上の整数）とすることも可能である。この場合、例えばリース単位期間が１０日ならば１０×３＝３０日という利用期間となる。同時に課金は単価のｎ倍となる。
【００６３】
図７に、本実施の形態におけるＡＤＦ情報５５の一例を示す。前述のようにＡＤＦは、端末によるアプリのダウンロードに先立ってサーバにより作成され端末に送られるファイルである。ＡＤＦ情報５５は、アプリ名称(Name)、そのリビジョン（改訂番号）、ベンダＩＤ、アプリＵＲＬ、アプリサイズ、拡張バージョン番号(Extension-Version)、利用期限(Expiration-Time)、リース期間、コード署名(Code-Signing)、スクリーンサイズ等の項目を含んでいる。ここに、拡張バージョン番号(Extension-Version)、利用期限(Expiration-Time)は、アプリのダウンロード時にサーバが設定するデータであり、他のデータは前述したアプリデータベース２６０の当該アプリ管理レコード２６２から複写されたデータである。「利用期間」は図６の「リース単位期間」の複写であるが、前述のようにリース単位期間を複数個指定できる場合にはその倍数の期間となる。本実施の形態では利用期限として、利用期間の終了する日時データを指定する。また、利用期限データには、試用の場合にはその識別子として“,trial”の文字列を付加する。
【００６４】
図８により、ユーザ側から見た本サービス利用の流れを説明する。
【００６５】
まず、ユーザは本サービス利用のための端末を購入する（Ｓ７１）。本実施の形態では、セキュリティ等の観点から、本サービスの利用を特定の端末機種に制限している。端末機種は、工場出荷時に埋め込まれている機種ＩＤにより判断することができる。機種ＩＤがない端末であっても、例えば、端末からサーバに送られるＨＴＴＰヘッダに埋め込まれたユーザエージェント情報を利用して判断することも可能である。（この場合、端末に搭載されたブラウザの識別子から端末機種を判断することになる。）ユーザはこの端末からポータルサイトにアクセスして、会員登録を行う（Ｓ７２）。ついで、電子商取引のために電子マネーの登録を行い、前もって電子マネーの補充を行っておく（Ｓ７３）。ここまでが初期処理であり、最初に一度実行すれば足りる。
【００６６】
その後、通常処理に移る。通常処理では、まず、ポータルサイトから所望のアプリを選択して（Ｓ７４）、ダウンロードし（Ｓ７５）、試用してみる（Ｓ７６）。本実施の形態では、試用期間経過後も３回まで試用のためのダウンロードを許容している（Ｓ７７，Ｓ７８）。これは、前述したユーザデータベース２５０のマイアプリ情報のダウンロード回数カウンタおよび購入回数カウンタの各カウント値に基づいて判断することができる。ユーザは試用中このアプリを気に入った場合（Ｓ７９）、このアプリを購入して正式な利用権を得ることができる（Ｓ８０）。購入申込時に、その使用料に応じて電子マネーの充当が必要な場合（Ｓ８１）、電子マネーの補充を行う（Ｓ８２）。電子マネーによる使用料を支払えば（Ｓ８３）、このアプリの利用期間が設定される（Ｓ８４）。なお、図示しないが、このアプリの購入動作は試用期間の経過後であっても可能である。
【００６７】
アプリの購入から利用期間のカウントダウンが開始され、期限が到来すると（Ｓ８５）、アプリの起動時にその旨がメッセージ出力される（Ｓ８６）。これに対して再購入の指示を行って（Ｓ８７）、使用料を払えば（Ｓ８３）、再度利用期間が設定される（Ｓ８４）。図では明記していないが、この利用期間の延長は、期限到来前にも行うことが可能である。その場合、前の残存利用期間に新たな利用期間が追加される形となる。
【００６８】
以下、本実施の形態におけるシステム各部の具体的な動作を、画面例を交えて説明する。
【００６９】
図９は、会員登録時の端末と管理サーバとの間のやりとりを示す処理シーケンス図である。本実施の形態では、管理サーバはポータルサイトを介してインターネットを経由して端末との間でデータ通信を行う。典型的には、ＴＣＰ／ＩＰプロトコル上でｈｔｔｐ(hyper text transfer protocol)もしくはｈｔｔｐｓまたはｆｔｐ(file transfer protocol)を利用してデータ通信を行う。ｈｔｔｐｓを利用する場合にはＳＳＬ(Secure Socket Layer)を用いて通信内容が秘匿される。本サービスを利用する端末は、特定の機種に限定するために、管理サーバは端末の接続時に端末から機種ＩＤを受信し（Ｓ１１１）、その端末が予定された機種の端末であることを確認する（Ｓ１１２）。また、後述するように登録済みの端末は内部に保存された会員ＩＤおよび端末ＩＤも、接続時に管理サーバへ送信する。管理サーバは、機種ＩＤを受信しなかった場合または受信しても予定された機種ＩＤではなかった場合、サービスの提供が行えない旨（拒絶メッセージ）を端末に送信する（Ｓ１１３）。
【００７０】
機種ＩＤがＯＫであれば、会員ＩＤおよび端末ＩＤの受信の有無を確認する（Ｓ１１４）。これらのＩＤ受信があれば、端末のユーザにパスワードの入力を求め、パスワードがＯＫであれば、ログインを許可する（Ｓ１１５）。これ以降の動作については後述する。
【００７１】
会員ＩＤおよび端末ＩＤを受信しなかった場合、その端末は本サービスに登録されていないので、登録選択画面（図１０（ａ））を端末へ送信する（Ｓ１１６）。図示しないが、管理サーバは、会員ＩＤおよび端末ＩＤを受信しても、その組み合わせが登録されていないものの場合にも拒絶メッセージを返送する。未会員登録のユーザは会員登録のためのアンカーポイントである「新規会員登録する」を選択する。アンカーポイントはＨＴＭＬ(Hyper Text Markup Language)を代表とするマークアップ言語ファイルに埋め込まれた、他のファイルやサイト等へリンクが張られた部分である。ユーザがこのアンカーポイントを指示することにより、マークアップ言語ファイル内のその位置に記載されたリンク先へ移行したり、指定された処理を実行したりすることができる。既に会員登録しているユーザが、新たな端末を本サービス利用に追加する、または、既登録端末が破損もしくは紛失した等の理由により既登録端末の既得権を新たな端末（または修理後の端末）が引き継ぐ場合には、端末登録のためのアンカーポイントである「こちらから」を選択する。
【００７２】
管理サーバはユーザの入力した選択に応じて（Ｓ１１７）、会員登録か端末登録かを判断する（Ｓ１１８）。会員登録の場合には、図１０（ｂ）に示すように、ユーザに氏名、パスワード、メールアドレス、住所および前述した端末愛称等の個人情報の入力を求め、図１０（ｃ）に示すように会員ＩＤの割り当てを行い、会員データベースに登録する（Ｓ１３４）とともに、この会員ＩＤをユーザに通知する（Ｓ１３５）。ついで、会員から電子マネー登録の指示を受け（Ｓ１３６）、電子マネー口座を開設する等の電子マネー登録処理を行う（Ｓ１３７）。さらに、当該会員に対する当該端末に端末ＩＤを割り当てて、前記端末愛称に対応づけて当該端末ＩＤを会員データベースに登録する（Ｓ１４０）。その後、図１０（ｄ）に示すようにユーザに登録結果を通知し（Ｓ１４１）、ログイン画面への移行を勧誘する。
【００７３】
ユーザから端末登録が指示された場合（Ｓ１１８）、図１１（ａ）に示すように会員ＩＤおよびパスワードの入力を求め（Ｓ１１９）、これらの入力を受けて（Ｓ１２０）、会員の認証を行う（Ｓ１２１）。この認証がＯＫでなければ、拒絶メッセージを返す（Ｓ１２２）。認証ＯＫであれば、図１１（ｂ）に示すような端末の追加か破損端末復旧（または復旧からの乗り換え）かをユーザに選択させる（Ｓ１２３，Ｓ１２４）。端末の追加の場合には（Ｓ１２５）、図１１（ｃ）のようにユーザに新たな端末愛称を入力させ（Ｓ１２６，Ｓ１２７）、上記端末登録処理（Ｓ１４０）へ移行する。
【００７４】
上記ステップＳ１２５で端末の復旧と判断された場合は、復旧処理を行う。具体的には、まず、図１１（ｅ）に示すようにユーザに端末愛称により端末を選択させ（Ｓ１２８）、ユーザの選択（Ｓ１２９）により復旧対象の端末を特定する。ついで、当該端末のマイアプリ情報２５４（図４）を新端末のマイメニュー２５３（図４）にコピーし（Ｓ１３０）、指示された端末愛称の端末の端末情報２５２（図４）の抹消フラグをＯＮにする（Ｓ１３１）。その後、前記と同様の端末登録処理（Ｓ１４０）を行う。
【００７５】
端末登録処理の後は、管理サーバは端末に対して会員ＩＤ、端末ＩＤ、機種ＩＤ、および端末愛称を送信する（Ｓ１４１）。好ましくは、ユーザに登録内容を知らしめるために、会員ＩＤ、機種ＩＤおよび端末愛称を表示する（Ｓ１４２）。但し、端末ＩＤは会員自身にも秘密にされ、会員ＩＤおよび端末愛称とともに、端末内のローカルストレージに保存される（Ｓ１４３）。本サービスの対象とする端末機種では、ユーザに対してこれらのデータにアクセスする手段は提供されていない。
【００７６】
図１２は、会員登録を行ったユーザが本サービスを利用する際のログイン画面（ａ）とログイン後に表示されるトップメニュー（ｂ）を示す端末画面例を示している。トップメニューは、「アプリメニュー」「マイメニュー」「電子マネー補充」「設定」「ヘルプ」等のメニュー項目をアンカーポイントとして提示している。「アプリメニュー」は、本サービスで提供されているすべてのアプリをユーザに提示し、ユーザの所望のアプリを試用のために選択させるメニューである。「マイメニュー」は、前述したように、アプリメニューからユーザが選択した特定のアプリ（マイアプリ）群を登録したメニューであり、ユーザは、この画面から本使用の申込（購入）、利用期間中または期間後の利用期間の更新を行うことができる。本実施の形態ではマイメニュー内の利用期間経過後の試用アプリの再試用の申込も可能である。（但し、再試用の回数は制限される。）アプリメニューおよびマイメニューの画面例については後述する。「電子マネー補充」は、アプリの料金支払いに先立って電子マネーを補充しておくためのメニュー項目である。「設定」は会員情報の更新や証明書の更新を行うためのメニュー項目である。
【００７７】
図１３は、アプリメニューからアプリ試用の申込を行う際のシステム各部の処理シーケンスを示す。管理サーバは、端末へトップメニューを送信し（Ｓ２１１）、端末からアプリメニューの要求を受けて（Ｓ２１２）、アプリメニューを送信する（Ｓ２１３）。ユーザがアプリを選択すると、そのアプリを特定する情報が管理サーバに送信される（Ｓ２１４）。これに応じて管理サーバはそのアプリを当該ユーザのマイメニューにマイアプリとして登録する（Ｓ２１５）。管理サーバはさらに、ＧＥＴ＿ＡＤＦコマンドを埋め込んだＨＴＭＬファイルを端末に送信する（Ｓ２１６）。このＨＴＭＬファイルはマイアプリの登録結果の通知を目的とするもの等、任意のＨＴＭＬファイルであってよい。端末はこのＨＴＭＬを解釈し、ユーザの指示によらず、埋め込んだＧＥＴ＿ＡＤＦコマンドを管理サーバに送信してＡＤＦファイルの送信を要求する（Ｓ２１７）。これに応じて、管理サーバは、そのコマンドを受信、解釈して、当該アプリについて、図７で説明したようなＡＤＦを作成する（Ｓ２１８）。このときＡＤＦ内に組み込む利用期限は、例えば試用申込時の日にち（または日時）を起算点として、試用期間に基づき試用期間終了日（または日時）を算出する。作成されたＡＤＦは、端末へ送信される（Ｓ２１９）。
【００７８】
端末は、受信したＡＤＦをローカルストレージに格納するとともに解析する（Ｓ２２０）。ついで、ＪＡＭを起動し（Ｓ２２１）。このＪＡＭがＡＤＦの記述内容に従ってアプリ本体であるＪａｒファイルを、アプリＵＲＬの示すサイトに対して要求する（Ｓ２２２）。前述のとおり、アプリＵＲＬは管理サーバ内のアプリホルダであっても、あるいはアプリベンダであってもよい。アプリＵＲＬのサイトから端末にＪａｒファイルが送信される（Ｓ２２３）。端末はこのファイルを受信してローカルストレージ内に格納する（Ｓ２２４）とともに、その利用期限の管理を開始する（Ｓ２２５）。
【００７９】
図１４（ａ）に管理サーバから送信されて端末に表示されるアプリメニューの例を示す。この例では、アプリメニューはアプリの「カテゴリ一覧」「新着アプリ一覧」「アプリの検索」等のメニュー項目を有する。図１４（ｂ）にカテゴリ一覧の指示に応じて表示されるカテゴリ一覧画面（図示せず）の中から「ゲーム」が指示されたアプリの一覧画面を示す。この例では、各ゲームアプリの名称、試用期間およびアプリの簡単な説明が示されている。ユーザが、表示された任意のアプリを指示すると、図１３で説明したように端末へのダウンロードが開始される。
【００８０】
図１５により、マイメニューから利用期間の更新（購入も含む）を行う際の画面遷移の例を説明する。図１５（ａ）はマイメニューの画面例を示す。この例では、「ダウンロード」「利用期間の更新」等のメニュー項目を示している。
【００８１】
メニュー項目「ダウンロード」は、マイメニュー中の例えば試用期間経過後の試用アプリについて再度の試用を申し込む場合に用いる。「ダウンロード」が選択されると、図１５（ｂ）のような画面となり、試用アプリを新たなＡＤＦファイルとともに再度ダウンロードして、その利用期間を更新することができる。この場合は試用なので料金の支払い（管理サーバ側からみれば課金）は生じない。ダウンロード中は図１５（ｅ）のような画面となる。
【００８２】
「利用期間の更新」が選択された場合には、図１５（ｃ）に示すように、一旦購入したアプリのリストが表示され、ユーザは任意のアプリの更新を指示することができる。ここに「更新」とは利用期間中のアプリの利用期間の延長、および、利用期間経過後の再度の購入申込を含む。利用期間の延長時には、残存した利用期間に新たな利用期間が加算される。また、この「更新」時には課金がなされるので、図１５（ｄ）に示すように、その価格情報および電子マネーの残高の変化が表示され、ユーザの確認をとる。確認がとれれば、新たな利用期限を含む新たなＡＤＦファイルとともにアプリ本体が端末にダウンロードされる（図１５（ｅ））。
【００８３】
なお、図示しないが、図１５（ａ）のマイメニューには「マイメニューの整理」のメニュー項目を設けてもよい。マイメニューの整理ではマイアプリの削除を行うことができる。
【００８４】
図１６に、アプリ更新申込時のシステム各部の処理シーケンスを示す。管理サーバから端末に送られた（Ｓ３１１）マイメニューに対してユーザが任意のアプリを選択すると（Ｓ３１２）、端末からそのアプリを特定する情報とともに購入要求が管理サーバになされる（Ｓ３１３）。管理サーバは課金サーバに対して当該ユーザに対する当該アプリの課金要求を行い（Ｓ３１４）、これに応じて課金サーバは所定の課金処理を行う（Ｓ３１５）。所定の課金処理がなされた場合、課金ＯＫの通知が管理サーバに戻される（Ｓ３１６）。管理サーバは、課金処理が完了した後、当該会員の当該端末のマイメニューを更新する（Ｓ３１７）。ここまでがアプリ更新申込処理の第１フェーズである。
【００８５】
管理サーバはさらに、ＧＥＴ＿ＡＤＦコマンドを埋め込んだＨＴＭＬファイルを端末に送信する（Ｓ３１８）。端末はこのＨＴＭＬを解釈し、ユーザの指示によらず、ＧＥＴ＿ＡＤＦコマンドを管理サーバに送信してＡＤＦファイルの送信を要求する（Ｓ３１９）。これに応じて、管理サーバは当該アプリについてＡＤＦを作成する（Ｓ３２０）。このときＡＤＦ内に組み込む利用期限は、例えば購入申込時の日にち（または日時）を起算点とする。残存期間がある場合には、それを加算して利用期間終了日（または日時）を算出する。作成されたＡＤＦは、端末へ送信される（Ｓ３２１）。ここまでがアプリ更新申込処理の第２フェーズである。
【００８６】
続く第３フェーズでは、端末は、受信したＡＤＦをローカルストレージに格納するとともに解析する（Ｓ３２２）。ついで、ＪＡＭを起動し（Ｓ３２３）。このＪＡＭがＡＤＦの記述内容に従ってアプリ本体であるＪａｒファイルをアプリＵＲＬのサイトに要求する（Ｓ３２４）。アプリＵＲＬサイトから端末にＪａｒファイルが送信される（Ｓ３２５）。端末はこのファイルを受信してローカルストレージ内に格納する（Ｓ３２６）とともに、その利用期限の管理を開始する（Ｓ３２７）。
【００８７】
このような構成により以下のような効果が得られる。
（１）全てが正常に行われる場合、購入申込、課金、アプリ本体のダウンロードまでが一連の手順で行われ、しかもユーザは購入申込以外の操作が不要であり、かつ、意識することも無い。
（２）第１フェーズでは、購入申込コマンドが端末から管理サーバへ送信された後は、管理サーバと課金サーバとの間だけで処理が行われるのでシステムの安定性が高い。また、端末とサーバとの間の通信異常により第１フェーズが途中で中断することはない。
（３）端末と管理サーバとの間の通信に異常が発生することが考えられるが、第１フェーズが完了していれば第２フェーズ以降をやり直せばよい（ユーザはマイメニューからダウンロードを行えばＡＤＦファイルおよびＪａｒファイルを取得できる。）従って、重複課金は発生しないで済む。
（４）第２フェーズでは、端末が受信すべきファイルはアプリ本体（Ｊａｒファイル）とは別のＡＤＦファイルという比較的小さなファイルの送信だけなので、課金を含むセッションが回線不良などで中断してしまう危険性を極めて低くできる。
（５）第３フェーズでは、Ｊａｒファイルのサイズが大きい場合、端末とベンダとの間で通信異常が発生し、Ｊａｒファイルを完全にダウンロードできないおそれがある（特に、端末が移動体型（モバイル）情報端末である場合）。この場合、第３フェーズのみやり直すことができる（具体的にはＡＤＦがあるのでプレイリストにアプリは表示されるが実体がないので、ここでアプリＵＲＬに接続しダウンロードを再トライする）。アプリＵＲＬが管理サーバ以外（例えばベンダ）である場合には、ダウンロードのやり直しには管理サーバは関与しないのでその負担を軽減することもできる。データが大きい場合にメリットはより大きくなる。
【００８８】
二重課金を防止するために、端末がアプリ（Ｊａｒファイル）を完全にダウンロードしたことを確認したときに初めて課金を行うような場合、第１フェーズから第３フェーズまでずっと課金を待っている必要があるが、本実施の形態では、そのような必要がなく、サーバの負担が軽減される。すなわち、本実施の形態では、第１フェーズさえ終わっていれば課金が二重に行われることは無く、第３フェーズの終了を管理サーバが確認する必要はない。
【００８９】
一方、利用期間内であれば何度でもダウンロードできるので、第２フェーズ以降の処理は課金とは独立しているといえる。したがって、二重課金が発生するおそれがなく、ユーザはアプリを取得できる。よって、端末内部の記憶装置（ローカルストレージ）が一杯になった（または余裕がなくなった）場合、何の心配も無くデータを削除し、必要になれば第２フェーズ以降を行えば済むという使い方が可能となる。したがって、アプリＵＲＬのサイトをあたかも端末の「仮想ストレージ」として利用できることになる。
【００９０】
図２７は、図１６に対応した端末の動作を示すフローチャートである。端末上でブラウザを起動し、サービスにログインすると（Ｓ７１１）、管理サーバから送信されたマイメニューを表示する（Ｓ７１２）。そこで、ユーザによる、マイメニューに表示されたアプリの中から購入するアプリの選択を受ける（Ｓ７１３）。アプリが選択されると、端末は、購入要求を管理サーバへ送信する（Ｓ７１４）。その後、端末は、管理サーバから課金処理が不成立であったことを示すエラー通知を受信したか否かチェックする（Ｓ７１５）。課金エラー通知があった場合は、例えば「課金手続きが完了できませんでした。アプリケーションの購入手続きを初めからおこなってください。」というような課金ＮＧメッセージを表示し、処理を中止する（Ｓ７１６）。課金エラー通知がない場合、端末は、管理サーバからＧＥＴ＿ＡＤＦコマンドを埋め込んだＨＴＭＬファイルを受信する（Ｓ７１７）。このときＨＴＭＬファイルを正常に受信したか否か判断する（Ｓ７１８）。ＨＴＭＬファイルを受信中に通信にエラーが発生した場合、ブラウザよりも下位レイヤのＴＣＰ／ＩＰプロトコル処理プログラムからエラー通知がある。ステップＳ７１８の判断結果がＮｏの場合、例えば「通信が中断しました。Ｍｙメニューに接続し、アプリケーションのダウンロード手続きを行ってください。」のようなリトライＴｙｐｅＡ要求メッセージを表示し、ユーザにアプリケーションのダウンロード手続きを行うように促す（Ｓ７１９）。これは、課金結果はＯＫであるが、フェーズ２へ移行できなかったので、課金処理より後の処理を行えば済む、という状態である。
【００９１】
一方、正常にＨＴＭＬを受信できた場合、端末はＨＴＭＬを解釈し（Ｓ７２０）、埋め込まれたＧＥＴ＿ＡＤＦコマンドを管理サーバへ送信する（Ｓ７２１）。その後、端末は、管理サーバからＡＤＦを正常に受信したか否かをチェックする（Ｓ７２２，Ｓ７２３）。Ｎｏの場合、例えば「通信が中断しました。アプリケーションの再ダウンロード手続を行ってください。」のようなリトライＴｙｐｅＢ要求メッセージを表示し、ユーザにアプリケーションの再ダウンロード手続きを行うように促す（Ｓ７２４）。ここでは、第２フェーズを正常に完了できず、ＡＤＦファイルを受信するところからやり直す必要がある。ＨＴＭＬは受信済みなので、これを利用してＧＥＴ＿ＡＤＦコマンドの送信からやり直す。この点の詳細は後述する。
【００９２】
一方、ＡＤＦを正常に受信できた場合、ＪＡＭを起動する（Ｓ７２５）。ＪＡＭは、ＡＤＦ情報に従ってアプリベンダのサイトに接続し、Ｊａｒファイルを要求する（Ｓ７２６）。次いで、管理サーバからＪａｒファイルの受信を行う（Ｓ７２７）。その後、端末はＪａｒファイルを正常に受信したか否かをチェックする（Ｓ７２８）。Ｎｏの場合、例えば「アプリケーションのダウンロード中に通信が中断しました。プレイリストから「最新版取得」を実行してください。」のようなリトライＴｙｐｅＣ要求メッセージを表示し、ユーザにプレイリストから『最新版取得』を行うように促す（Ｓ７２９）。ここでは、第３フェーズを正常に完了できていないので、Ｊａｒファイルを受信するところからやり直す必要がある。ＡＤＦは受信済みなので、プレイリストにはアプリ情報が表示されるが、実体データが取得できていない状態である。そこで、ＡＤＦを利用してＪＡＲファイルの受信要求からやり直す。この詳細については後述する。
【００９３】
なお、やり直しの処理は自動的に行うように設計することも可能である。しかし、処理中断の主要な要因としては電波状態が悪いことが考えられるので、ユーザが電波状態の良い場所へ移動して自らの判断で処理をリトライすることが好適であると考えられる。但し、電波状況をウオッチしながらリトライするという処理も可能である。
【００９４】
図２８は、図１６に対応した管理サーバの動作を示すフローチャートである。管理サーバは、端末からログインがあったとき（Ｓ７４１）、当該ユーザのマイメニューを当該端末へ送信する（Ｓ７４２）。その後、端末から購入要求があれば（Ｓ７４３）、課金サーバに対して課金要求を送信する（Ｓ７４４）。課金サーバからの応答を待ち（Ｓ７４５）、課金ＯＫでなければ（Ｓ７４６，Ｎｏ）、「課金ＮＧ」の通知を端末へ送信する（Ｓ７４７）。課金ＯＫであれば、マイメニューの更新を行って（Ｓ７４８）、ＨＴＭＬ送信を行う（Ｓ７４９）。その後、端末からＡＤＦ要求があれば（Ｓ７５０）、ＡＤＦを作成して（Ｓ７５２）、これを端末へ送信する（Ｓ７５３）。ＡＤＦ要求が所定時間以上なかったときには（Ｓ７５１）、本処理を終了する。
【００９５】
なお、ステップＳ７４９のＨＴＭＬ送信後に、一度処理を中止し、ＡＤＦ要求があった場合にＡＤＦ作成／送信を行うようにしてもよい。
【００９６】
図２９および図３０は、それぞれ端末および管理サーバにおける上述したリトライＴｙｐｅＡ処理の処理例を示す。このタイプのリトライでは、既に課金処理が終了し、マイメニューの更新が完了しているので、ユーザは、端末からサービスにログインし、マイメニューに表示された対象アプリを選択することにより、ＨＴＭＬ受信要求以降の処理をリトライすることができる。
【００９７】
より具体的には、図２９において、端末は、サービスログイン（Ｓ７６１）後にマイメニューを受信して表示し（Ｓ７６２）、ユーザからダウンロードの選択を受け付ける（Ｓ７６３）。そこで、マイアプリ一覧を受信して表示する（Ｓ７６４）。ユーザからダウンロード対象のアプリ選択を受けると（Ｓ７６５）、対応するＨＴＭＬ要求を送信し（Ｓ７６６）、対応するＨＴＭＬを受信する（Ｓ７６７）。ついで、このＨＴＭＬ受信が正常に完了したかをチェックする（Ｓ７６８）。正常でなければ、上述したようなリトライＴｙｐｅＡ要求メッセージを表示する（Ｓ７６９）。正常であれば、そのＨＴＭＬを解釈し（Ｓ７７０）、ＧＥＴ＿ＡＤＦコマンドを送信する（Ｓ７７１）。ついで、これに応じたＡＤＦを受信し（Ｓ７７２）、その受信が正常に完了したか否かをチェックする（Ｓ７７３）。正常でなければ、上述したようなリトライＴｙｐｅＢメッセージを表示する（Ｓ７７４）。正常であれば、ＪＡＭを起動する（Ｓ７７５）。ＪＡＭは、ＡＤＦ情報に従ってアプリベンダのサイトに接続し、Ｊａｒファイルを要求する（Ｓ７７６）。次いで、管理サーバからＪａｒファイルの受信を行う（Ｓ７７７）。その後、端末はＪａｒファイルを正常に受信したか否かをチェックする（Ｓ７７８）。Ｎｏの場合、上述したようなリトライＴｙｐｅＣ要求メッセージを表示する（Ｓ７７９）。
【００９８】
図３０において、管理サーバは、端末からのログインを受け付けると（Ｓ７８１）、当該ユーザのマイメニューを送信し（Ｓ７８２）、さらにマイアプリ一覧を送信する（Ｓ７８３）。ついでダウンロード要求を受信すると（Ｓ７８４）、ＨＴＭＬを送信する（Ｓ７８５）。その後、端末からＡＤＦ要求があれば（Ｓ７８７）、ＡＤＦを作成して（Ｓ７８８）、これを端末へ送信する（Ｓ７８９）。ＡＤＦ要求が所定時間以上なかったときには（Ｓ７８６）、本処理を終了する。
【００９９】
図３１および図３２は、それぞれ端末および管理サーバにおける上述のリトライＴｙｐｅＢ処理の一例を示している。このタイプでは、ＨＴＭＬ受信が正常に完了しているため、端末は、ＨＴＭＬに埋め込まれたＧＥＴ＿ＡＤＦコマンドを持っている状態である。従って、例えば、リトライＴｙｐｅＢ処理メッセージの中にＡＤＦ再要求の指示用のボタンを埋め込んでおき、このボタンをユーザが指示することで、ＡＤＦ再要求の指示を受け付ける。これによって、端末は、オフラインであれば管理サーバへの接続を行った後、ＨＴＭＬを解釈し、ＧＥＴ＿ＡＤＦコマンドを管理サーバへ送信する。管理サーバは常時ＧＥＴ＿ＡＤＦコマンドを待受けており、ＧＥＴ＿ＡＤＦコマンドを受信するとＡＤＦを作成し、端末へ送信する。
【０１００】
より具体的には、図３１において、端末は、ユーザからのＡＤＦ再要求の指示が受けたとき（Ｓ８０１）、前記ＨＴＭＬの解釈を行って（Ｓ８０２）、ＧＥＴ＿ＡＤＦコマンドを送信する（Ｓ８０３）。ついで、これに応じたＡＤＦを受信し（Ｓ８０４）、その受信が正常に完了したか否かをチェックする（Ｓ８０５）。正常でなければ、上述したようなリトライＴｙｐｅＢメッセージを表示する（Ｓ８０６）。正常であれば、ＪＡＭを起動する（Ｓ８０７）。ＪＡＭは、ＡＤＦ情報に従ってアプリベンダのサイトに接続し、Ｊａｒファイルを要求する（Ｓ８０８）。次いで、管理サーバからＪａｒファイルの受信を行う（Ｓ８０９）。その後、端末はＪａｒファイルを正常に受信したか否かをチェックする（Ｓ８１０）。Ｎｏの場合、上述したようなリトライＴｙｐｅＣ要求メッセージを表示する（Ｓ８１１）。
【０１０１】
図３２において、管理サーバは、端末からＡＤＦ要求があれば（Ｓ８２１）、ＡＤＦを作成して（Ｓ８２３）、これを端末へ送信する（Ｓ８２４）。ＡＤＦ要求が所定時間以上なかったときには（Ｓ８２２）、本処理を終了する。
【０１０２】
図３３および図３４は、それぞれ端末およびダウンロードサイト（アプリベンダ）のサーバにおける上述のリトライＴｙｐｅＣ処理の一例を示している。この処理はプレイリストからの最新版取得と同一の処理である。このタイプのリトライでは、ＡＤＦ受信が完了しているため、端末内のプレイリストを参照することが可能である。ただし、ＡＤＦ情報のみが存在しＪａｒファイルが無いので実体データが存在しない。そこで最新版取得の処理を実行し、Ｊａｒファイルを取得する。
【０１０３】
より具体的には図３３において、端末はユーザによりブラウザが起動され（Ｓ８３１）、ユーザによるメニューからのプレイリストの選択を受けると（Ｓ８３２）、プレイリスト画面を表示する（Ｓ８３３）（図１８、１９参照）。その後、プレイリストから対象のアプリの選択を受ける（Ｓ８３４）。選択されたアプリは強調表示（例えばハイライト表示）される。アプリが選択された状態で（Ｓ８３４）、プレイリスト上部の『最新版取得』が指示されると（Ｓ８３５）、ＪＡＭが起動し、拡張された期限管理機能によって、ＡＤＦ情報が読み出され（Ｓ８３６）、その中の使用期間情報を参照して期限超過か否か判定する（Ｓ８３７）。期限超過の場合には、ダウンロードＮＧメッセージを表示して（Ｓ８３９）、本処理を終了する。リトライ処理では期限超過することは通常ない。期限超過でない場合、Ｊａｒ要求をアプリベンダサイトへ送信し（Ｓ８４０）、Ｊａｒを受信する（Ｓ８４１）。所定時間内にＪａｒが受信されなかったときには（Ｓ８４２）、上述したようにリトライＴｙｐｅＣ要求メッセージを表示して（Ｓ８４３）、本処理を終了する。
【０１０４】
図３４において、アプリベンダサイトのサーバは、端末からＪａｒ要求を受けると（Ｓ８５１）、そのＪａｒファイルを当該端末に対して送信する（Ｓ８５２）。
【０１０５】
上記ではリトライＴｙｐｅＣの処理を最新版取得と同一の処理で行ったが、本発明はこれに限定されるものではなく、リトライに特化した処理を実行することも可能である。この場合、使用期間のチェックは不要である。また、プレイリストからアプリ実行を指示した際にＪａｒファイル、すなわちアプリの実体が無い場合に自動的にリトライ動作を行うようにしても良い。
【０１０６】
図１７は、本実施の形態において端末の内蔵する時計を自動的に修正する処理シーケンスを示す。この処理は端末が管理サーバに対してログインしたときに実行される。管理サーバはトップメニュー等のＨＴＭＬファイルを送信するとき（Ｓ４１１）、特定のＭＩＭＥタイプの記述を含めておく。端末は、これに応じて端末のブラウザは特定のプラグインを起動する（Ｓ４１２）。プラグインは管理サーバに所定の制御ファイルを要求する（Ｓ４１３）。これに対して管理サーバは制御ファイル内に現在日時情報を含めて端末に送信する（Ｓ４１４）。端末のプラグインは受信した現在日時と端末内の時計の現在日時とを比較し（Ｓ４１５）、所定時間（例えば５分）以上の誤差がある場合、エラーと判断して、端末の時計を管理サーバの日時に合わせるように修正する（Ｓ４１７）。この制御ファイル内には、時刻チェックのＯＫ時における次のページのＵＲＬおよびＮＧ時のエラーページのＵＲＬ等を含んでもよい。上記特定のＭＩＭＥタイプの利用の代わりに、ＨＴＭＬファイル内に拡張タグとして＜ｅｍｂｅｄ ｓｒｃ＝“Ｇｅｔｃｌｏｃｋ．ｃｇｉ”＞のような記述を埋め込んでおき、これを端末のブラウザで解釈することにより、現在日時情報を含む制御ファイルを要求してもよい。
【０１０７】
図１８（ａ）は端末の外観の一例を示す。図１８（ｂ）は、端末のオフライン状態でのメニュー表示状態を示している。ユーザがこのメニューから「プレイリスト」を選択すると、図１９（ａ）に示すようなプレイリスト画面が表示される。プレイリストは端末に現在保存されているアプリの一覧である。各アプリには利用期間に関する属性マーク（アイコン）が付加され、表示されている。図１９（ｂ）は本実施の形態における５種類のアイコンを示している。アイコン８１は、そのアプリが試用期間中であることを示している。アイコン８２〜８５は利用期間の段階的な残量を示している。すなわち、アイコン８２は、そのアプリの使用期間がほとんど残っていることを示している。アイコン８３は、試用期間が半分以上残っていることを示している。アイコン８４は、使用期限が切れかけていることを示している。アイコン８５は、既に使用期限が切れていることを示している。アイコン８６は、そのアイコンが他のポータルサイトからダウンロードされた使用期限のないものであることを示している。アイコン８１の示す試用アプリの利用期間は通常短期間であり、また、アイコン８６のアプリの利用期間は無期限である。この意味で、アイコン８１も８６も、アプリの利用期間に関する状況を示していると言える。このようなグラフィカルな表示の一種としてのアイコン表示により、ユーザは各アプリの利用期間に関する状況を即座に認識することができる。このように、本実施の形態では、ＡＤＦ中に記述された利用期限属性を参照し、利用期間の残量を算出し、これに対応する表示すべきアイコンを選択している。
【０１０８】
図２３に、図１９のアイコン表示のための処理例を示す。この処理はプレイリストの表示時に実行される処理の一部である。まず、アプリを指定するための変数ｉを１に初期化し（Ｓ６１１）、以下の処理をアプリの個数分繰り返す。続くステップＳ６１２ではアプリｉのＡＤＦをチェックする（Ｓ６１２）。ついで、ＡＤＦ内に利用期限Expiration-Timeが含まれているかを調べる（Ｓ６１３）。含まれていなければこのアイコンは利用期限のないアプリなので、アイコン８６を選択する（Ｓ６１４）。その後、変数ｉが最終のアプリかどうかをチェックし（Ｓ６２８）、最終であれば、処理を終了する。最終でなければ、変数ｉをインクリメントして（Ｓ６１５）、ステップＳ６１２に戻る。ステップＳ６１３で利用期限が含まれていれば、その利用期限と現在日時とに基づいて残存時間を算出する（Ｓ６１６）。残存時間がなし（すなわち０または負）であれば（Ｓ６１７）、アイコン８５を選択し（Ｓ６１８）、ステップＳ６２８へ進む。残存時間がある場合、利用期限Expiration-Timeに文字列“,trial”が付加されているかどうかをチェックする（Ｓ６１９）。付加されていれば、このアプリは試用アプリなのでアイコン８１を選択し（Ｓ６２０）、ステップＳ６２８へ進む。試用アプリでなければ、残存時間と利用期間の単位を変換する（Ｓ６２１）。例えば、日単位の時間をより細かい単位（例えば秒単位）に変換する。この変換処理は必須ではないが、これを行うことによって、より正確な残量の分類判定を行うことができる。ついで、残存時間を利用期間で割った商をＤとする（Ｓ６２２）。このＤの値は、利用期間あたりの残存時間の割合を示す。このＤが１／３未満であれば（Ｓ６２３）、アイコン８４を選択する（Ｓ６２４）。Ｄが１／３以上２／３未満であれば（Ｓ６２５）、アイコン８３を選択する（Ｓ６２６）。そうでなければ、アイコン８２を選択する（Ｓ６２７）。このような処理を変数ｉが最終となるまで繰り返す（Ｓ６２８）。
【０１０９】
図２０（ａ）のプレイリストの各アプリについて、図２０（ｂ）に示すように、端末情報として会員ＩＤ、機種ＩＤ、端末愛称を確認したり、図２０（ｃ）に示すように、アプリの詳細情報としてアプリの名称、バージョンやサイズを確認したり、図２０（ｄ）に示すように、そのアプリの使用期限を確認したりすることができる。図示した例の使用期限は年月日を示しているが、年月日に加えて時刻まで指定するようにしてもよい。
【０１１０】
なお、ユーザは、端末内の限られた記憶容量を有効に利用するために、プレイリスト中の任意のアプリを削除することも可能である。この際、対応するＡＤＦファイルも削除される。但し、管理サーバ内のマイメニューにはマイアプリとして登録されたままである。したがって、削除されたアプリが購入されたアプリで、その利用期間が残存している場合には、ユーザはその利用期間内であれば、必要となったときにサーバからＡＤＦを取得しそのアプリを無料で再ダウンロードすることができる。削除ではなく、本体またはＡＤＦが破損したアプリ等についても同様である。
【０１１１】
図３５は、ＡＤＦ中の使用期間情報を使ったアプリの起動制御を示すフローチャートである。まず、端末においてユーザに指示に応じてブラウザを起動する（Ｓ８６１）。ユーザによるプレイリストの選択があったとき（Ｓ８６２）、プレイリスト画面を表示する（Ｓ８６３）。アプリ起動指示があれば（Ｓ８６４）、現在日時を確認し（Ｓ８６５）、ＡＤＦ情報を読み出す（Ｓ８６６）。そこで、当該アプリの利用期間（利用期限）と現在日時とを比較する（Ｓ８６７）。利用期限を超過していれば、当該アプリの起動を抑止する（Ｓ８６９）。そうでなければ、当該アプリを起動する（Ｓ８７０）。
【０１１２】
図２１は、ユーザが端末にダウンロードしたアプリを実行する際に端末の時計をチェックする処理のフローチャートである。前述したように、端末に内蔵された時計の日時はサーバの時計に合わせられるが、利用期間経過後に時計を意図的に逆行させて不正に有料アプリを使用することが考えられる。本実施の形態では、アプリの起動時にその日時と前回の起動日時とを比較して、時計の進行が自然でないことを検知したときに、アプリの起動を抑止するようにしたものである。
【０１１３】
図２１において、端末（ＪＡＭ）がユーザによりプレイリスト中のアプリの起動指示を受けたとき（Ｓ５１１）、まず、端末内の時計から現在日時を確認する（Ｓ５１２）。ついで、端末内に保存してある当該アプリの前回起動時の日時を確認する（Ｓ５１３）。そこで、両日時を比較し（Ｓ５１４）、今回起動日時が前回起動日時よりも過去であったならば時間が逆行していると判断し、次に端末が管理サーバに接続して端末の時計が管理サーバの時計と同期されるまで当該アプリの起動を抑止する（Ｓ５１５）。これにより、あるアプリの利用期間経過後にユーザが意図的に時計を誤った日時に修正して実行するような不正を防止することができる。ステップＳ５１６での日時の比較時には誤差として数分程度の逆行は許容するようにしてもよい。アプリの起動を抑止した場合には、ユーザに対してその旨の警告メッセージを出力する（Ｓ５１６）。ステップＳ５１４で時間の逆行がないと判断されれば、当該アプリの起動を許容し（Ｓ５１７）、そのときに日時を当該アプリの「前回起動日時」として更新記録しておく。
【０１１４】
図２２は、表示マーク（アイコン）５６の表示された端末画面例を示す図である。この表示マーク５６は、本実施の形態において管理サーバが提供するサービスを利用することができる実行環境を提供するアプリケーション（典型的にはブラウザであり、上述した期限管理機能拡張が組み込まれているもの）がその端末に搭載されていることを示している。前述のように、本発明に係るサービスは端末機種により対応できる場合とできない場合がありうるので、このマーク５６が表示されていれば、ユーザはその端末が当該サービスに対応していることを直ちに認識することができる。この表示マーク５６は単なる表示にとどまらず、何かの処理を起動するための起動アイコンとしてもよい。例えば、この起動アイコンをクリックすると、プレイリストを表示したり、あるいは、ポータルサイトに接続してログインし、マイメニューを表示したりするようにしてもよい。なお、アイコンの図柄、アイコンを表示する画面およびその画面内の位置は図示の例に限るものではない。
【０１１５】
図１に示したストレージサービスサーバ４２０およびプリントサービスサーバ４３０が提供するストレージ提供サービスやプリントサービスについて簡単に説明する。ストレージサービスサーバ４２０が提供するサービスは、ユーザの端末の記憶容量を実質的に拡大するためにユーザが自由に利用できるストレージ領域をユーザにリースするサービスであり、上述のアプリ等と同様、そのリース期間を制限することができる。この場合に端末がダウンロードするアプリ等は、当該サービスを利用するためのアプリおよび／またはデータである。また、プリントサービスサーバ４３０が提供するサービスは、ユーザがアプリ等として例えばデジタルカメラで撮影したデジタル画像データを処理するための処理ソフトウェア等であり、管理サーバに対してその印刷の依頼を行って課金サーバでの課金を行い、プリント対象のデータを管理サーバまたは他の所定のサーバに送信して印刷出力を依頼し、所定の場所（例えばチェーン店の店頭）でその印刷物を受け取ることができる。なお、これらのネットワークサービスでは、ＡＤＦ内のアプリＵＲＬに代えて、当該サービスを提供するサービスＵＲＬを用いることができる。
【０１１６】
以上説明した実施の形態の効果をまとめると次のとおりである。
（１）サーバ運用側で生成したアプリ等の利用期限を示す利用期限属性をアプリケーション等とは別に端末に転送し、利用期限属性に従ってアプリケーション等の利用およびダウンロードを制御するので、アプリ等自体に“時限爆弾”を仕込む必要がなくなり、サーバ運用側（ポータルサイト、ベンダ）が意図する利用期限を設定することができる。
（２）管理サーバと端末との間で両者の時計を一致させることにより、管理サーバ側と端末側とで実質的に同一時間軸上で利用期限を管理できる。
（３）端末では、利用期限属性に従ってローカルにアプリ等を実行する際にも、その利用の制限管理を行うことができる。（２）および（３）によって、より厳密な意味でユーザにアプリ等の利用期限を守らせることができる。
（４）端末側で利用期限を管理するので利用期限の確認のためにサーバに接続する必要が無い。したがって、アプリ等の起動の都度、サーバに接続する手間および通信費の無駄が省ける。
（５）利用期限属性を、ユーザとサーバ運用側との間でのアプリの取引（試用、リース等）が発生するたびに生成するので、利用期間はアプリケーション等ごとに一律である必要がなくなる。さらに、やり取り毎に個別に異なる条件（利用期間等）を設定することもできる。
（６）アプリ本体は、その利用期間内であれば、端末外部からいつでも無料で入手できるので、端末内部の記憶装置の容量が限られていても何の心配も無くアプリ等を削除することができる。
（７）アプリ等のダウンロードに伴う課金時には、アプリ等のダウンロードは利用期間内に何度でもダウンロードできることを保証することにより、実際のアプリ等の本体のダウンロードを行うことなく課金処理を完了することができる。すなわち、管理サーバ側から端末にはアプリ等の本体とは別の（アプリ等の実体を含まない）極めて小さなデータ（ADFファイル）を転送するだけで済むので、その処理が途中で中断する確率はアプリ等の本体のダウンロード処理が中断する確率に比べて極めて小さい。
（８）より厳密な期限管理が可能であるため、極めて短期間（1日、1時間等）の利用期限を定めたアプリ等のリースを実際の経済活動で認められる安全性を確保しながら実現することができる。
（９）ユーザが試用中またはリース中のアプリ等を端末に表示する際に、種別（試用かリースか等）や試用・利用期間の残存状況をアイコン等でグラフィカルに表示することにより、数値表示に比べてユーザは即座に直感的にその状況を認識することができ、便利である。また、アプリ提供側からみれば、利用期間の残量を視覚的に明示することにより、ユーザに利用期間延長の動機付けを与えることができる。
（１０）サーバにおいてユーザ毎に試用やリースを受けているアプリを管理しているので、端末内のアプリ情報（ＡＤＦ）が損なわれたときなどに、サーバで管理している情報に基づいて端末側のアプリ情報を復元することができる。
（１１）ユーザの会員登録時に会員ＩＤのみならずサービスに利用する端末を識別するための端末ＩＤを付与し、これらのＩＤを端末内に保存するとともに、端末ＩＤはユーザにも秘密に管理することによって、ログイン時等に会員ＩＤおよびパスワードの他、端末ＩＤを確認することにより、会員へのいわゆるなりすましを防止することができる。
（１２）ログイン時等に端末の機種ＩＤを管理サーバ側で確認することにより、サービス利用可能な端末を、前述したノンＰＣ端末と呼ばれるパーソナルコンピュータ（以下、ＰＣという）などの特定の端末に制限することができる。これにより、端末内部のローカルストレージ等に記憶された端末ＩＤを不正に読み出されることを防止し、（１１）の効果をより確実なものにすることができる。
（１３）同じ会員についても異なる端末には異なる端末ＩＤを付与することにより、複数のユーザが一人の会員名義で複数の端末を用いて同じ有料アプリ等を使用する不正を防止することができる。
（１４）各端末に端末愛称を付与することにより、未だ利用期間の残存しているアプリ等を登録した端末の「復旧」の際に、目的の端末を特定することができる。
【０１１７】
以上、本発明の好適な実施の形態について説明したが、特許請求の範囲に記載した範囲内で、上記で言及した以外にも種々の変形、変更を行うことが可能である。
【０１１８】
例えば、利用期限経過後にアプリ等の起動等を制限することには、機能の一部制限、「サンプル」や「利用期限経過」のように警告メッセージをオーバーラップ表示することのように、アプリ等の利用を一部制限することも含まれる。
【０１１９】
ポータルサイトに代えて、いわゆるマルチメディア・キオスク（非特許文献１参照）と呼ばれるような、店頭等に備え付けられる据え置き型情報処理装置であってもよい。この装置に自動販売機のような課金システムを搭載していればユーザから現金やクレジットカードを用いて料金を徴収することも可能である。この場合、マルチメディア・キオスクと端末との間の通信は、例えば、赤外線、Bluetooth（商標）等のローカル（近距離）での通信に適した手段を用いることができるが、特に限定されない。
【０１２０】
利用期限は、サーバが計算してＡＤＦファイルに記述する他に、サーバは起算点となる日時と利用期間とをアプリ属性データ中に利用期限属性として記述し、これらに基づいて端末側で利用期限を算出するようにしてもよい。
【０１２１】
端末の時計と管理サーバの時計の同期化の手段として、端末の時計を強制的に管理サーバの時計に合わせる例を示したが、管理サーバ以外の他のサーバにより端末の時計を合わせてもよい。さらに言えば、何らかの方法で端末の時計の適性化が保証されるのであれば、必ずしもサーバの時計に合わせる必要もない。結果として、サーバと端末とで実質的に同一時間軸上で利用期限が管理されれば足りる。
【０１２２】
端末はノンＰＣ端末を例として挙げたが、セキュリティの観点における所要の措置がとられれば、必ずしもノンＰＣ端末である必要はない。すなわち、ネットワーク（インターネットを含む）を介してサーバや他の端末とデータを双方向で交換する能力を有する装置（ネットワーク端末）であればよい。また、アプリ等の実行をシミュレーションするための端末エミュレータ（ＰＣ上で動作するブラウザ＋ＪａｖａＶＭ＋期限管理拡張）であってもよい。
【０１２３】
また、通信において用いるプロトコルは、所期の目的を達成できれば、必ずしも上記のものに限るものではない。
【０１２４】
アプリ等はネットワークを経由してダウンロードする例を示したが、例えば、デジタル放送などの放送網を介して配信元からブロードキャストされるデータを受信するようにしてもよい。
【０１２５】
試用アプリの機能は購入アプリに比べて一部の機能が制限されていてもよい。
【０１２６】
アプリ等の試用は必ずしも必須のものではなく、試用なしにいきなり購入を行うシステムであってもよい。
【０１２７】
アプリの実行はローカルで行う場合を示したが、対戦ゲーム等の場合のように、アプリの実行中の全体または一部においてオンライン状態となるものであってもよい
【０１２８】
各アプリ等の利用期間は一定である例を示したが、同じアプリであってもユーザにそのリース期間を選択させるようにしてもよい。その場合の課金は利用期間に応じて増減しうる。
【０１２９】
利用期間の残量に関するアイコン表示はプレイリストについてのみ説明したが、マイメニュー等、他の画面について行うことも可能である。
【０１３０】
機種ＩＤに応じて、端末に提供するアプリ等の種類や形式等を変更または選択するようにしてもよい。
【０１３１】
端末愛称は本質的には一人の会員が保有する複数の端末を相互に識別できれば足りるので、上記説明ではユーザに指定させるようにしたが、サーバ側が決定してもよい。また、必ずしも愛称は単なる識別情報であってもよい。
【符号の説明】
【０１３２】
５０…ＯＳ、５１…アプリ等、５２…アプリ実行環境、５３…期限管理機能、５５…ＡＤＦ、５６…表示マーク（アイコン）、６１…ＪａｖａＶＭ、６３…拡張部、６４…ＪＡＭ、６５…拡張部、６６…ネットワークサービス対応ＡＰＩ、６７…ローカルストレージ、７０…ブラウザ、８０…Ｊａｖａアプリ、２００…管理センサ、２１０…ポータルサイト、２１５…課金管理部、２２０…管理サーバ、２２５…アプリホルダ、２３０…管理部、２３５…決済口座、２４０…ネットワークサービスインタフェース、２５０…ユーザデータベース、２５３…マイメニュー、２６０…アプリデータベース、３００…アプリベンダ、４００…サービス事業者、４２０…ストレージサービスサーバ、４３０…プリントサービスサーバ
【特許請求の範囲】
【請求項１】
サーバによる端末管理方法であって、
サーバの提供するサービスをユーザが端末から利用するための会員登録を行う際、
ユーザの個人情報の入力を受けるステップと、
当該ユーザに会員ＩＤを割り当てるステップと、
当該端末に対して端末ＩＤを割り当てるステップと、
前記端末ＩＤを当該会員ＩＤに対応付けてサーバ側で管理するステップと、
前記会員ＩＤおよび端末ＩＤを前記端末に送信して端末内に格納させるステップと、
を備えたことを特徴とする端末管理方法。
【請求項２】
前記端末ＩＤは当該ユーザが認識できないようにサーバおよび端末において管理されることを特徴とする請求項１記載の端末管理方法。
【請求項３】
端末からの接続を受けた際に、当該端末の機種ＩＤの送信を受け、この機種ＩＤが所定の機種ＩＤであることを確認するステップをさらに備えることを特徴とする請求項１または２記載の端末管理方法。
【請求項４】
サーバの提供するサービスに対して端末が接続してきた際に、前記端末から前記会員ＩＤ、端末ＩＤおよびパスワードの入力を受け、サーバの管理する当該ユーザの会員ＩＤ、端末ＩＤおよびパスワードと対照してログインの可否を決定するステップとを備える請求項３記載の端末管理方法。
【請求項５】
前記会員ＩＤおよび端末ＩＤの入力はユーザの指示によらず端末が自動的に送信することを特徴とする請求項４記載の端末管理方法。
【請求項６】
サーバの提供するサービスに対して端末が接続してきた際に、前記会員ＩＤ、端末ＩＤ、およびパスワードの入力がない場合、または、それらの入力情報が当該会員ＩＤについて登録されている端末ＩＤまたはパスワードと合致しない場合は、当該端末に対するサービスの提供を拒絶することを特徴とする請求項３または４記載の端末管理方法。
【請求項７】
前記会員登録の際、
ユーザから当該端末の愛称の入力を受けるステップをさらに備え、
前記端末ＩＤと端末愛称とを当該会員ＩＤに対応付けてサーバ側で管理するとともに、前記会員ＩＤ、端末ＩＤおよび端末愛称を前記端末に送信して端末内に格納させることを特徴とする請求項１記載の端末管理方法。
【請求項８】
サーバの提供するサービスに対して端末が接続してきた際に、当該端末から会員ＩＤおよび端末ＩＤの入力がない場合、会員ＩＤおよびパスワードの入力を求めるステップと、
これに応答してユーザから入力された会員ＩＤおよびパスワードが正当である場合、当該ユーザに対して端末の復旧か追加かを尋ねるステップと、
端末の復旧の場合、当該ユーザの会員ＩＤについての既存の端末愛称を指定させ、指定された端末愛称の端末ＩＤについての登録情報を当該新たな端末に対して引き継ぐステップと、
端末の追加の場合、ユーザから新たな端末愛称の入力を受けるとともに新たな端末ＩＤを割り当てて、当該新たな端末ＩＤおよび端末愛称を当該会員ＩＤに対応付けて管理するとともに、当該新たな端末に送信して端末内部に保存させるステップと、
をさらに備えたことを特徴とする請求項７記載の端末管理方法。
【請求項９】
各端末にインストールされた利用期限付きのアプリケーション等を管理する情報を、当該会員ＩＤの当該端末ＩＤに対応付けて、端末毎に管理するステップをさらに備えたことを特徴とする請求項１〜８のいずれかに記載の端末管理方法。
【請求項１０】
前記アプリケーション等を表したメニューを前記端末に提示するステップと、
前記端末のユーザにより前記メニュー上の複数のアプリケーション等から選択された一つのアプリケーション等の利用期限に関する利用期限属性を当該アプリケーション等の入手先情報とともに前記端末に送信し、当該利用期限属性に基づいて当該アプリケーション等を当該端末にダウンロードさせるステップと、
前記選択されたアプリケーション等について、当該アプリケーション等の利用権を管理するためのレコードを生成し、端末単位に当該端末についてダウンロードされた１以上のアプリケーション等の利用権をそれぞれの前記レコードに基づいて管理するステップと、
前記一つのアプリケーション等のダウンロードに伴って、その少なくとも利用期限に関する利用期限属性を前記端末に転送し、前記端末において、前記利用期限属性に基づいて、利用期限を越えたアプリケーション等の利用を抑止させるステップと
をさらに備えたことを特徴とする請求項９に記載の端末管理方法。
【請求項１１】
会員登録を受けたユーザの端末を管理するサーバであって、
ユーザの個人情報の入力を受ける手段と、
当該ユーザに会員ＩＤを割り当てる手段と、
当該端末に対して端末ＩＤを割り当てる手段と、
前記端末ＩＤを当該会員ＩＤに対応付けてサーバ側で管理するデータベースと、
前記会員ＩＤおよび端末ＩＤを端末内に格納させるために前記端末に送信する手段と
を備えたことを特徴とするサーバ。
【請求項１】
サーバによる端末管理方法であって、
サーバの提供するサービスをユーザが端末から利用するための会員登録を行う際、
ユーザの個人情報の入力を受けるステップと、
当該ユーザに会員ＩＤを割り当てるステップと、
当該端末に対して端末ＩＤを割り当てるステップと、
前記端末ＩＤを当該会員ＩＤに対応付けてサーバ側で管理するステップと、
前記会員ＩＤおよび端末ＩＤを前記端末に送信して端末内に格納させるステップと、
を備えたことを特徴とする端末管理方法。
【請求項２】
前記端末ＩＤは当該ユーザが認識できないようにサーバおよび端末において管理されることを特徴とする請求項１記載の端末管理方法。
【請求項３】
端末からの接続を受けた際に、当該端末の機種ＩＤの送信を受け、この機種ＩＤが所定の機種ＩＤであることを確認するステップをさらに備えることを特徴とする請求項１または２記載の端末管理方法。
【請求項４】
サーバの提供するサービスに対して端末が接続してきた際に、前記端末から前記会員ＩＤ、端末ＩＤおよびパスワードの入力を受け、サーバの管理する当該ユーザの会員ＩＤ、端末ＩＤおよびパスワードと対照してログインの可否を決定するステップとを備える請求項３記載の端末管理方法。
【請求項５】
前記会員ＩＤおよび端末ＩＤの入力はユーザの指示によらず端末が自動的に送信することを特徴とする請求項４記載の端末管理方法。
【請求項６】
サーバの提供するサービスに対して端末が接続してきた際に、前記会員ＩＤ、端末ＩＤ、およびパスワードの入力がない場合、または、それらの入力情報が当該会員ＩＤについて登録されている端末ＩＤまたはパスワードと合致しない場合は、当該端末に対するサービスの提供を拒絶することを特徴とする請求項３または４記載の端末管理方法。
【請求項７】
前記会員登録の際、
ユーザから当該端末の愛称の入力を受けるステップをさらに備え、
前記端末ＩＤと端末愛称とを当該会員ＩＤに対応付けてサーバ側で管理するとともに、前記会員ＩＤ、端末ＩＤおよび端末愛称を前記端末に送信して端末内に格納させることを特徴とする請求項１記載の端末管理方法。
【請求項８】
サーバの提供するサービスに対して端末が接続してきた際に、当該端末から会員ＩＤおよび端末ＩＤの入力がない場合、会員ＩＤおよびパスワードの入力を求めるステップと、
これに応答してユーザから入力された会員ＩＤおよびパスワードが正当である場合、当該ユーザに対して端末の復旧か追加かを尋ねるステップと、
端末の復旧の場合、当該ユーザの会員ＩＤについての既存の端末愛称を指定させ、指定された端末愛称の端末ＩＤについての登録情報を当該新たな端末に対して引き継ぐステップと、
端末の追加の場合、ユーザから新たな端末愛称の入力を受けるとともに新たな端末ＩＤを割り当てて、当該新たな端末ＩＤおよび端末愛称を当該会員ＩＤに対応付けて管理するとともに、当該新たな端末に送信して端末内部に保存させるステップと、
をさらに備えたことを特徴とする請求項７記載の端末管理方法。
【請求項９】
各端末にインストールされた利用期限付きのアプリケーション等を管理する情報を、当該会員ＩＤの当該端末ＩＤに対応付けて、端末毎に管理するステップをさらに備えたことを特徴とする請求項１〜８のいずれかに記載の端末管理方法。
【請求項１０】
前記アプリケーション等を表したメニューを前記端末に提示するステップと、
前記端末のユーザにより前記メニュー上の複数のアプリケーション等から選択された一つのアプリケーション等の利用期限に関する利用期限属性を当該アプリケーション等の入手先情報とともに前記端末に送信し、当該利用期限属性に基づいて当該アプリケーション等を当該端末にダウンロードさせるステップと、
前記選択されたアプリケーション等について、当該アプリケーション等の利用権を管理するためのレコードを生成し、端末単位に当該端末についてダウンロードされた１以上のアプリケーション等の利用権をそれぞれの前記レコードに基づいて管理するステップと、
前記一つのアプリケーション等のダウンロードに伴って、その少なくとも利用期限に関する利用期限属性を前記端末に転送し、前記端末において、前記利用期限属性に基づいて、利用期限を越えたアプリケーション等の利用を抑止させるステップと
をさらに備えたことを特徴とする請求項９に記載の端末管理方法。
【請求項１１】
会員登録を受けたユーザの端末を管理するサーバであって、
ユーザの個人情報の入力を受ける手段と、
当該ユーザに会員ＩＤを割り当てる手段と、
当該端末に対して端末ＩＤを割り当てる手段と、
前記端末ＩＤを当該会員ＩＤに対応付けてサーバ側で管理するデータベースと、
前記会員ＩＤおよび端末ＩＤを端末内に格納させるために前記端末に送信する手段と
を備えたことを特徴とするサーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【公開番号】特開２００９−１５１８１９（Ｐ２００９−１５１８１９Ａ）
【公開日】平成２１年７月９日（２００９．７．９）
【国際特許分類】
【出願番号】特願２００９−４５５１７（Ｐ２００９−４５５１７）
【出願日】平成２１年２月２７日（２００９．２．２７）
【分割の表示】特願２００２−３７１７０１（Ｐ２００２−３７１７０１）の分割
【原出願日】平成１４年１２月２４日（２００２．１２．２４）
【出願人】（５９１１１２５２２）株式会社ＡＣＣＥＳＳ (91)
【Ｆターム（参考）】
【公開日】平成２１年７月９日（２００９．７．９）
【国際特許分類】
【出願日】平成２１年２月２７日（２００９．２．２７）
【分割の表示】特願２００２−３７１７０１（Ｐ２００２−３７１７０１）の分割
【原出願日】平成１４年１２月２４日（２００２．１２．２４）
【出願人】（５９１１１２５２２）株式会社ＡＣＣＥＳＳ (91)
【Ｆターム（参考）】
[ Back to top ]