JP4332344B2 - Expiration date management method, expiration date management system, and management server - Google Patents

Description

Translated fromJapanese

【０００１】
【発明の属する技術分野】
本発明は、主としてネットワークを介して、利用期限（使用期限）付きのアプリケーション等を提供するシステムに関し、特にその利用期限を効果的に管理するシステムに関する。
【０００２】
【従来の技術】
【０００３】
近年、インターネット関連技術や移動体通信技術等の発達により、携帯電話端末、携帯情報端末等の移動端末を用いた電子商取引が普及してきている。（本明細書において、端末装置を単に端末という。）
【０００４】
例えば、コンピュータネットワーク上から情報端末上で動作するアプリケーション等をダウンロードさせ、それを有償または無償で一定期間（以下、利用期間という）に限り利用を認める電子商取引が検討されている。
【０００５】
ダウンロードしたアプリケーション等を利用期間内に限り利用を認めるために、例えば、利用期間の終了時に当該アプリケーション等の利用を禁止する仕組であるいわゆる「時限爆弾」その他の禁止手段をアプリケーション等に組み込むことが行われている（特許文献１参照）。この利用期限は、一般的には、端末にアプリケーション等をインストールした日時（端末側の時計（カレンダ）が示すもの）を起算点として予め定めた利用期間の日数等をカウントして算出されている。
【０００６】
また、使用回数に制限を設け、例えばアプリケーションを起動するたびにある計数値をインクリメントし、この計数値が所定値を超えたならば起動を制限する方法もある。
【０００７】
【特許文献１】
特開平１０−２２２５７９号公報
【非特許文献１】
野村総合研究所著、「ユビキタス・ネットワーク」、２０００年１２月２０日、野村総合研究所発刊
【０００８】
【発明が解決しようとする課題】
しかしながら、上記従来の技術においては、次のような問題があった。
【０００９】
例えば、ベンダが個々のアプリケーション等に禁止手段を組み込む必要があり、ベンダの負担となる。また、その利用期限は一律のものとならざるを得ない。
【００１０】
また、利用期間の起算点がクライアント側で決まるため、ベンダ側で起算点を決めることができない。このため、正確に利用期間を把握することが困難であり、また、正確に利用期間を守らせることも困難である。
【００１１】
利用回数に制限をつける場合、アプリケーション等の起動回数はサーバには分からないので端末においてのみ管理されることになり、サーバ側で利用期限を管理することが困難である。また、端末側で利用期限に関するデータの書換えを行うと、このデータが利用制限に関連していることが容易に推察され、これを不正に書き換えて利用制限を越えた不正使用が行われやすくなる。
【００１２】
さらに、従来のダウンロード販売（アプリケーション等をダウンロードするときに課金する方式）の場合、ダウンロードが途中で中断する場合があるため、ダウンロード完了を確認する必要がある。これはサーバ側では面倒な処理である。アプリケーション等のダウンロードが途中で中断した場合に備えて、一定期間再ダウンロードすることを認める場合もあるが、この期間を経過すればダウンロードできない。これでは、ユーザがお金を支払ったにも関わらずアプリケーション等を取得できないという事態が発生するおそれがある。
【００１３】
本発明はこのような背景においてなされたものであり、その目的は、端末に提供される利用期限付きのアプリケーション等の利用期限を、サーバおよび端末の双方で管理し、かつ、端末において確実に守らせることができるアプリケーション等利用期限管理システム、サーバおよびコンピュータプログラムを提供することにある。
【００１４】
本発明による他の目的は、サービスの登録会員の端末の追加、復旧を容易に可能とする端末管理方法を提供することにある。
【００１５】
本発明による別の目的は、アプリケーション等の利用期限の状況をユーザが迅速、容易に認識することができる、端末上で動作するコンピュータプログラムを提供することにある。
【００１６】
本発明によるさらに別の目的は、端末において本発明に係るサービスが利用できることをユーザに迅速容易に認識させることができる端末を提供することにある。
【００１７】
【課題を解決するための手段】
本発明によるアプリケーション等利用期限管理システムは、端末とサーバからなるシステムにおいて、サーバはアプリケーション等の少なくとも利用期限に関する利用期限属性をアプリケーション等とは別に端末に転送し、端末は前記利用期限属性を参照し利用期限を経過したならばアプリケーション等の利用を制限する利用期限管理手段を備えたことを特徴とする。
【００１８】
前記利用期限管理手段は、例えば、端末のアプリケーション等の実行環境の一部として提供される。
【００１９】
前記利用期限は、例えば、サーバと端末との間でのアプリケーション等の利用に関するアクションを起算点として所定の利用期間が満了するときであり、前記利用期限属性は、アクションが発生するたびに生成される。
【００２０】
サーバおよび端末は実質的に同一の時間軸上で利用期限を管理する。そのために、例えば、端末は、サーバへの接続時に、当該サーバと自己の現在時刻とが所定時間以上ずれているときに、自己の現在時刻をサーバの指示に応じてサーバの管理する時刻に合わせる。また、端末は、プリケーション等を利用したときの利用時刻を記録し、次にアプリケーション等を利用するとき、前記利用時刻を今回の利用時刻と比較し、両者の関係が予め定めた関係にある場合にはアプリケーション等の利用を制限する。
【００２１】
前記利用期限属性は当該アプリケーション等の入手先情報とともに端末に転送され、端末は前記入手先情報に基づいて当該アプリケーション等を入手する。一旦、入手先情報が得られれば、端末は利用の権利がある限り、当該アプリケーション等をいつでも入手できるので、前記アプリケーション等の入手の前に当該アプリケーションの利用権に対する課金を行うことができる。
【００２２】
また、端末は、サーバから取得し、内部に保存されているアプリケーション等を一覧表示し、その際、好ましくは、各アプリケーション等の利用期間の残量をグラフィカルに表示する。
【００２３】
サーバによる端末管理方法は、サーバの提供するサービスをユーザが端末から利用するための会員登録を行う際、ユーザの個人情報の入力を受けるステップと、当該ユーザに会員ＩＤを割り当てるステップと、当該端末に対して端末ＩＤを割り当てるステップと、前記端末ＩＤを当該会員ＩＤに対応付けてサーバ側で管理するステップと、前記会員ＩＤおよび端末ＩＤを前記端末に送信して端末内に格納させるステップとを備えたことを特徴とする。
【００２４】
これに加えて、端末からの接続を受けた際に、当該端末の機種ＩＤの送信を受け、この機種ＩＤが所定の機種ＩＤであることを確認するステップをさらに備えてもよい。
【００２５】
前記端末ＩＤは、好ましくは、当該ユーザが認識できないようにサーバおよび端末において管理されるものである。
【００２６】
サーバは、好ましくは、サーバの提供するサービスに対して端末が接続してきた際に、前記端末から前記会員ＩＤ、端末ＩＤおよびパスワードの入力を受け、サーバの管理する当該ユーザの会員ＩＤ、端末ＩＤおよびパスワードと対照してログインの可否を決定するステップとを備える。
【００２７】
前記会員ＩＤおよび端末ＩＤの入力はユーザの指示によらず端末が自動的に送信する。
【００２８】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００２９】
図１に、本実施の形態におけるシステムの概略構成を示す。本システムは、複数の端末１０、管理センタ２００、アプリベンダ３００、ストレージサービスサーバ４２０およびプリントサービスサーバ４３０により構成される。システムのこれらの構成要素間は、インターネット等のネットワークを介して相互に接続される。
【００３０】
管理センタ２００はアプリベンダ３００において開発されたアプリケーション等（アプリケーション、電子データ等）を管理し、端末１０のユーザの利用に供する。なお、本明細書中、アプリケーションを単にアプリともいう。管理センタ２００は、また、ストレージサービスサーバ４２０およびプリントサービスサーバ４３０が提供するストレージ提供サービスやプリントサービス等のネットワークサービスを端末１０のユーザに対して仲介する。
【００３１】
このような機能を達成するために、管理センタ２００は、インターネットのＷＷＷのためのポータルサイト２１０および管理サーバ２２０を備える。ポータルサイト２１０は課金管理部２１５を有し、有料のアプリ等やサービスに対して電子マネー等による課金を行う機能を有する。ポータルサイト２１０は、当然ながら、ウェブサーバおよび各種ＣＧＩ（図示せず）等を有する。管理サーバ２２０は、アプリベンダ３００から提供されるアプリ等を格納するアプリホルダ２２５、ストレージサービスサーバ４２０およびプリントサービスサーバ４３０の仲介となるネットワークサービスインタフェース２４０、およびこれらのアプリ等やサービスの管理を行う管理部２３０を有する。管理部２３０は、後述するように会員データベース（ＤＢ）１５０およびアプリデータベース２６０を備えている。図の例ではアプリ等として、Ｊａｖａ（登録商標）アプリを示している。
【００３２】
本実施の形態における端末１０は、いわゆるノンＰＣ端末と呼ばれる、パーソナルコンピュータ（以下、ＰＣという）以外のネットワーク端末である。ノンＰＣ端末は、ＰＣに比べて、（ａ）ＣＰＵの処理速度が遅い、（ｂ）実行メモリ（ＲＡＭ）の容量が小さい、（ｃ）ローカルストレージが小さい（ギガ単位のハードディスクではなく一般にメガ単位のフラッシュメモリが用いられている）、（ｃ）拡張性が低い（拡張ポートなどを持たない）、（ｄ）操作性が低い（キーボートとマウスではなく、テンキー、４方向カーソルキー、タッチパネル等で操作する）、（ｅ）表示画面が小さいなどの特徴を有する。このため、ノンＰＣ端末は、ＰＣに比べてハードウエアおよびソフトウエアの両面で制約が多い。ノンＰＣ端末は、具体的には、個人情報端末（Personal Digital Assistant：ＰＤＡ）を含む。ＰＤＡがＬＡＮインタフェース、モデム、無線通信機等の通信機能部を内蔵していてもよいし、コンパクトフラッシュ（登録商標）カードスロット等の拡張スロットを備え、これにＬＡＮカード、モデムカード、無線通信カード等の通信拡張カードを挿入し、通信を行うものであってもよい。ＰＤＡは、一般的には携帯可能なものであるが、机上等に据え置きで使うものも含まれる。ＰＤＡの中には腕時計に組み込まれたものも存在する。ノンＰＣ端末は、ネットワーク家電端末（ネット家電端末、インターネットアプライアンス（Internet Appliance）、情報家電端末とも呼ばれる）を包含する。ネットワーク家電端末は、コンピュータネットワーク（インターネットを含む）に接続する機能を有する家電機器である。ネットワーク家電端末は、具体的には、インターネットテレビ、デジタルテレビ、ＣＡＴＶ等のためのセットトップボックス、ゲーム機、固定電話、ＦＡＸ、プリンタ、複写機、スキャナのような通信と比較的関係が深い電子機器はもちろんのこと、冷蔵庫、電子レンジ、電気湯沸しポット、電気炊飯器、コーヒーメーカー、冷暖房装置などであってネットワークに接続可能な家電機器をも包含する。さらに、ノンＰＣ端末は、移動体通信機器を包含する。移動体（モバイル）通信機器とは、人または乗り物に付随して移動する端末機器であり、例えば、携帯電話、ＰＨＳ端末、カーナビゲーション端末、カーオーディオ機器、車載ラジオ、車載テレビ、車載ビデオ、デジタルカメラなどを含む。
【００３３】
端末１０は、ウェブを閲覧するためのブラウザ７０、アプリ等のダウンロードおよびファイル管理等を行うＪＡＭ(Java Application Manager)６４、ダウンロードされたアプリ等を保存するローカルストレージ６７、アプリ８０を実行するアプリ実行部６０を備える。なお、図における端末１０のブロック内のローカルストレージ６７はハードウェアであるが、それ以外のブロックはソフトウェアであり、ローカルストレージ６７内に格納されうる。
【００３４】
アプリ実行部６０は、本実施の形態では、ＪａｖａＶＭ(Java Virtual Machine)６１、クラスライブラリ６２、およびネットワークサービス対応のＡＰＩ（Application Program Interface）６６を有している。ＪａｖａＶＭ６１は、Ｊａｖａのバイトコードを実行するモジュールであり、図示しないＯＳ上で動作する。
【００３５】
ＪＡＭ６４は、Ｊａｒファイル、ＡＤＦ(Application Descriptor File)ファイル等のダウンロード、ＡＤＦファイルの解析等の管理を行い、ＪａｖａＶＭ６１とのメッセージのやりとりを行う。Ｊａｒファイルは、Ｊａｒ形式のＪａｖａアプリケーションであり、アプリ本体である。ＡＤＦファイルは、アプリ等の試用、購入、更新等（アプリ等の利用に関するアクション）に応じてＪａｒファイルをダウンロードするのに先立ってダウンロードされるアプリ属性データであり、Ｊａｒファイルのダウンロードの可否やオンライン課金の可否の判断、Ｊａｒファイルのコード署名の認証を行うために利用される。本実施の形態ではこのＡＤＦファイルに利用期限属性を付与する。この利用期限属性等の導入に伴う各種処理を行うための拡張部６５をＪＡＭ６４に設けている。
【００３６】
具体的には、拡張部６５は、ダウンロードされたアプリケーションの使用期限の管理、時計（カレンダ機能を含む）の管理、会員ＩＤおよび端末ＩＤ等の管理、課金に必要なセキュリティ機能（暗号化、アプリケーションのコード署名によるユーザのアクセス可能リソース（主にネットワークドメイン）の範囲の限定）、およびこれらの管理機能をユーザにガイドするためのユーザインタフェースを提供する。
【００３７】
ネットワークサービス対応のＡＰＩ６６は、ユーザが特定のアプリから、ファイル操作や印刷の要求を行ったときに、この要求をサーバ側のインタフェース２４０に連絡する機能を有する。
【００３８】
端末１０が利用するアプリは管理サーバ２２５内のアプリホルダ２２５からダウンロードする以外にも、アプリベンダ３００等から直接ダウンロードすることも可能である。
【００３９】
図２４に、端末１０の一例としての携帯電話機１０Ａの構成例を示す。この携帯電話機１０ＡはＣＰＵ１１０により制御される。このＣＰＵ１１０にはＲＡＭ１１１、ＲＯＭ１１２、無線通信部１１３、表示装置１１５、入力Ｉ／Ｏインタフェース１１６、および音声処理部１２０が接続される。ＲＡＭ１１１はＣＰＵ１１０に対してデータの一時記憶領域や作業領域を提供するメモリである。ＲＯＭ１１２はＣＰＵ１１０の実行する制御プログラムや各種のデータを格納する不揮発性のメモリである。ＲＯＭ１１２は、例えばフラッシュメモリのような再書き込み可能な不揮発性メモリを含んでもよい。本実施の形態のＪａｒファイルやＡＤＦファイルはＲＡＭ１１１および／またはＲＯＭ１１２に格納される。無線通信部１１３はアンテナ１１４を介して基地局との間で音声およびデータの無線通信を行う部位である。表示装置１１５は液晶ディスプレイを代表とする表示デバイスであり、その表示画面上にテキスト、画像等の各種情報を表示する。入力Ｉ／Ｏインタフェース１１６は、カーソルキー１１７、エンターキー１１８、ダイヤルキー１１９などに接続され、ユーザからの入力操作を受け付ける部位である。音声処理部１２０は、マイク１２１およびスピーカー１２２に接続され、ユーザの音声通話や音楽等の再生を行う部位である。データの符号化／復号化処理や音声処理はＣＰＵ１１０が行ってもよいし、別個のプロセッサ（図示せず）で行ってもよい。
【００４０】
図２５は、端末１０の他の例としてのＰＤＡ１０Ｂの構成例を示す。このＰＤＡ１０Ｂは、ＣＰＵ１３０により制御される。このＣＰＵ１３０にはＲＡＭ１３１、ＲＯＭ１３２、ＣＦカードインタフェース（Ｉ／Ｆ）１３３、表示装置１３５、入力Ｉ／Ｏインタフェース１３６が接続される。ＲＡＭ１３１およびＲＯＭ１３２は、携帯電話機のＲＡＭ１１１およびＲＯＭ１１２と同様である。ＣＦカードインタフェース（Ｉ／Ｆ）１３３は、無線通信機能を付加する無線通信カード１３４を装着するためのインタフェースであり、この無線通信カード１３４により基地局との通信が可能となる。表示装置１３５は、携帯電話機の表示装置１１５と同様の表示デバイスであるが、通常、その画面サイズは携帯電話機のそれより大きい。入力Ｉ／Ｏインタフェース１３６は、タッチパネル１３７やボタン１３８からに対するユーザ操作を受け付ける部位である。
【００４１】
いずれの端末においても、ユーザは、複数のメニュー項目から任意の一つを選択し、所望の画面へ移ることができる。メニュー項目の選択は、例えば、携帯電話機においては、カーソルを選択を望むメニュー項目へ移動させる。カーソルが指示するメニュー項目は、例えばハイライト表示により強調される。次に、エンターキーを押し下げることにより、現在カーソルが指示するメニュー項目が選択される。また、ＰＤＡの場合には、タッチパネルディスプレイ上でメニュー項目をペンでタップ（tap）することにより当該メニュー項目を選択することができる。
【００４２】
図２６に、本実施の形態におけるネットワーク構成の一例を示す。携帯電話機１０ＡやＰＤＡ１０Ｂは、基地局１４０を介して無線ネットワーク（Wireless Network）１４５に接続される。無線ネットワーク１４５は例えば携帯電話パケット通信網である。無線ネットワーク１４５はゲートウェイ(Gateway）１５５を介してインターネット１５７に接続される。ゲートウエイ１５５は、無線ネットワーク１４５とインターネット１５７との間でプロトコル変換を行うと共に、ユーザ毎に送受信したパケットに対して課金を行う。インターネット１５７には、管理サーバ２２０、課金サーバ２７０、およびアプリベンダ３００等の各種サーバが接続される。従って、端末１０と管理サーバ２２０、課金サーバ２７０及びアプリベンダ３００との間の通信は無線ネットワーク１４５、ゲートウエイ１５５、インターネット１５７を介して行われる。ゲートウェイ１５５での課金方式はこれに限定されるものではない。例えば通信を行った時間に対して課金を行うことも可能である。
【００４３】
図２に、本実施の形態におけるサービスのフローを説明する。
【００４４】
まず、アプリベンダ３００が開発したアプリ８０を管理センタ２００の管理サーバ２２０内の管理部２３０に登録し、アプリをアプリホルダ２２５内に格納する（▲１▼）。この際、必須ではないが、管理センタ２００の運用者はアプリの受託費用を徴収することができる。管理センタ２００はポータルサイト２１０において、端末１０のユーザから、本サービスの会員登録を受ける（▲２▼）。これと共に、電子商取引のために当該会員の決済口座２３５を開設する（▲３▼）。本実施の形態では決済の方法として電子マネーを用いるが、本発明はこれに限定されるものではない。
【００４５】
その後、会員であるユーザは端末１０からポータルサイト２１０にアクセスして、所望のアプリを選択してダウンロードする（▲４▼）。本実施の形態では、当初、利用期間を限って、アプリを無料でユーザの試用に供する（▲５▼）。ユーザはそのアプリを気に入れば、管理サーバ２２０に対して継続利用の登録（購入申込）を行うことができる（▲６▼）。この段階で初めてユーザは利用料の支払いを行う（▲７▼）。これによって、ユーザはそのアプリの正式な利用権利を取得する（▲８▼）。本実施の形態では、利用可能な期間の制限を設けるリースの形式でアプリを提供する。ここでリースとは、広く貸与の意味で用いており、レンタルと同意である。ユーザが保持する権利は、利用期限付きのアプリ等の利用権（ライセンス）である。言い換えれば、ある期間アプリ等を利用する権利を購入することである。これにより、ユーザはその利用期間に応じた対価を支払えば足り、必要に応じて利用期間を延長したり、利用期間経過後に再購入したりすることができる。利用料から管理センタ２００の手数料を減じたものがアプリベンダ３００に分配される（▲９▼）。アプリがネットワークサービス対応アプリの場合、そのアプリを実行することにより、ストレージサービスやプリントサービスを受けることができる。ストレージサービスは、ポータルサイト等で会員毎にストレージ領域を貸し出すサービスである。また、プリントサービスは、会員の提供するデジタル写真データ等の印刷出力を行うサービスである。これらのネットワークサービスにも利用期限が付加され、ユーザはその利用期間内に利用料を支払って当該サービスを受けることができる（１０，１１）。この利用料から管理センタ２００での手数料を減じたものがサービス事業者４００に分配される（１２）。
【００４６】
図３（ａ）に示すように、本発明の端末の基本モデルは、ＯＳ５０の上に配置されたアプリ等実行環境５２上でアプリ等が利用され、かつ、アプリ等実行環境５２に付随した期限管理機能５３が個々のアプリ等の利用期限の管理を行う。本実施の形態におけるアプリ等とは、上記Ｊａｖａアプリのようなアプリケーションプログラムやその構成要素の一部の他にも、テキスト、画像、動画、音楽、マークアップ言語ファイル等のようなＷｅｂコンテンツ等も含むものである。また、アプリ実行環境とは、ＯＳ上で実行され、アプリ等をユーザが利用するための環境を提供するプログラムまたはプログラム群をいう。アプリ等の利用には、閲覧、視聴、利用、実行等の種々の行為を含む。
【００４７】
図３（ｂ１）（ｂ２）（ｂ３）、（ｃ）〜（ｆ）は、種々のアプリ等の例と、その実行環境の例を示したものである。すなわち、図３（ｂ１）〜（ｂ３）は、アプリケーションプログラムとその実行環境を示す。図３（ｂ１）に示すように、Ｊａｖａアプリケーションについては、Ｊａｖａ仮想マシンがＪａｖａバイトコードを実行する。また、図３（ｂ２）に示すように、例えばＣ言語で作成され、コンパイルされたアプリケーション実行ファイル（いわゆる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（商標）等のローカル（近距離）での通信に適した手段を用いることができるが、特に限定されない。
【０１１３】
利用期限は、サーバが計算してＡＤＦファイルに記述する他に、サーバは起算点となる日時と利用期間とをアプリ属性データ中に利用期限属性として記述し、これらに基づいて端末側で利用期限を算出するようにしてもよい。
【０１１４】
端末の時計と管理サーバの時計の同期化の手段として、端末の時計を強制的に管理サーバの時計に合わせる例を示したが、管理サーバ以外の他のサーバにより端末の時計を合わせてもよい。さらに言えば、何らかの方法で端末の時計の適性化が保証されるのであれば、必ずしもサーバの時計に合わせる必要もない。結果として、サーバと端末とで実質的に同一時間軸上で利用期限が管理されれば足りる。
【０１１５】
端末はノンＰＣ端末を例として挙げたが、セキュリティの観点における所要の措置がとられれば、必ずしもノンＰＣ端末である必要はない。すなわち、ネットワーク（インターネットを含む）を介してサーバや他の端末とデータを双方向で交換する能力を有する装置（ネットワーク端末）であればよい。また、アプリ等の実行をシミュレーションするための端末エミュレータ（ＰＣ上で動作するブラウザ＋ＪａｖａＶＭ＋期限管理拡張）であってもよい。
【０１１６】
また、通信において用いるプロトコルは、所期の目的を達成できれば、必ずしも上記のものに限るものではない。
【０１１７】
アプリ等はネットワークを経由してダウンロードする例を示したが、例えば、デジタル放送などの放送網を介して配信元からブロードキャストされるデータを受信するようにしてもよい。
【０１１８】
試用アプリの機能は購入アプリに比べて一部の機能が制限されていてもよい。
【０１１９】
アプリ等の試用は必ずしも必須のものではなく、試用なしにいきなり購入を行うシステムであってもよい。
【０１２０】
アプリの実行はローカルで行う場合を示したが、対戦ゲーム等の場合のように、アプリの実行中の全体または一部においてオンライン状態となるものであってもよい
【０１２１】
各アプリ等の利用期間は一定である例を示したが、同じアプリであってもユーザにそのリース期間を選択させるようにしてもよい。その場合の課金は利用期間に応じて増減しうる。
【０１２２】
利用期間の残量に関するアイコン表示はプレイリストについてのみ説明したが、マイメニュー等、他の画面について行うことも可能である。
【０１２３】
機種ＩＤに応じて、端末に提供するアプリ等の種類や形式等を変更または選択するようにしてもよい。
【０１２４】
端末愛称は本質的には一人の会員が保有する複数の端末を相互に識別できれば足りるので、上記説明ではユーザに指定させるようにしたが、サーバ側が決定してもよい。また、必ずしも愛称は単なる識別情報であってもよい。
【０１２５】
【発明の効果】
本発明によれば、サーバ側から端末に提供される利用期限付きのアプリケーション等の利用期限を、サーバおよび端末の双方で管理することにより、端末において確実に守らせることができるようになる。
【０１２６】
また、ユーザに認識されない端末ＩＤをサーバ側から各端末に割り当てることにより、サービスの登録会員および端末の認証をより的確に行うことができるようになる。
【０１２７】
さらに、各端末に端末愛称を付与することにより、サービスの登録会員の端末の追加、復旧が容易となる。
【０１２８】
アプリケーション等の一覧表示において、アプリケーション等の利用期限の状況をアイコン表示することにより、ユーザが迅速、容易に認識することができるようになる。
【０１２９】
また、端末において本発明に係るサービスが利用できることを所定のマークを表示することにより、当該端末上で上記サービスが利用できることをユーザに迅速容易に認識させることができる。
【図面の簡単な説明】
【図１】 本発明の実施の形態におけるシステムの概略構成を示すブロック図である。
【図２】 本発明の実施の形態におけるサービスのフローを示すフローチャートである。
【図３】 本発明が適用されるアプリ等およびその実行環境を示す図である。
【図４】 本発明の実施の形態における会員データベースの構成例を示す図である。
【図５】 本発明の実施の形態における会員と会員ＩＤと端末ＩＤとマイメニューの関係を示す図である。
【図６】 本発明の実施の形態におけるアプリデータベースの構成例を示す図である。
【図７】 本発明の実施の形態におけるＡＤＦ情報の一例を示す図である。
【図８】 本発明の実施の形態における、ユーザ側から見た本サービス利用の流れを説明するフローチャートである。
【図９】 本発明の実施の形態における会員登録時の端末と管理サーバとの間のやりとりを示す処理シーケンス図である。
【図１０】 本発明の実施の形態における会員登録時の端末の画面遷移の例を示す図である。
【図１１】 本発明の実施の形態における端末登録時の端末の画面遷移の例を示す図である。
【図１２】 本発明の実施の形態において、会員登録を行ったユーザが本サービスを利用する際のログイン画面（ａ）とログイン後に表示されるトップメニュー（ｂ）を示す端末画面例を示す図である。
【図１３】 本発明の実施の形態において、アプリメニューからアプリ試用の申込を行う際のシステム各部の処理を示すシーケンス図である。
【図１４】 本発明の実施の形態におけるアプリメニュー（ａ）およびカテゴリ一覧（ｂ）の端末の画面例を示す図である。
【図１５】 本発明の実施の形態におけるマイメニューから利用期間の更新（購入も含む）を行う際の画面遷移の例を示す図である。
【図１６】 本発明の実施の形態におけるアプリ更新申込時のシステム各部の処理のシーケンス図である。
【図１７】 本発明の実施の形態における端末の内蔵する時計を自動的に修正する処理のシーケンス図である。
【図１８】 本発明の実施の形態における端末の外観（ａ）およびオフライン状態でのメニュー表示状態（ｂ）を示す図である。
【図１９】 本発明の実施の形態におけるプレイリスト画面（ａ）および各アプリの利用期間に関する属性マーク（アイコン）（ｂ）を示す図である。
【図２０】 本発明の実施の形態における各種の情報の表示画面例（ａ）〜（ｄ）を示す図である。
【図２１】 本発明の実施の形態において、アプリを実行する際に端末の時計をチェックする処理のフローチャートである。
【図２２】 本発明の実施の形態における表示マーク（アイコン）の表示された端末画面例を示す図である。
【図２３】 図１９のアイコン表示のための処理例のフローチャートである。
【図２４】 端末１０の一例としての携帯電話機１０Ａの構成例を示すブロック図である。
【図２５】 端末１０の他の例としてのＰＤＡ１０Ｂの構成例を示すブロック図である。
【図２６】 本発明の実施の形態におけるネットワーク構成の一例を示す図である。
【図２７】 図１６に対応した端末の動作を示すフローチャートである。
【図２８】 図１６に対応した管理サーバの動作を示すフローチャートである。
【図２９】 図２７に示したリトライＴｙｐｅＡ処理の端末における処理例を示すフローチャートである。
【図３０】 図２７に示したリトライＴｙｐｅＡ処理の管理サーバにおける処理例を示すフローチャートである。
【図３１】 図２７に示したリトライＴｙｐｅＢ処理の端末における処理例を示すフローチャートである。
【図３２】 図２７に示したリトライＴｙｐｅＢ処理の管理サーバにおける処理例を示すフローチャートである。
【図３３】 図２７に示したリトライＴｙｐｅＣ処理の端末における処理例を示すフローチャートである。
【図３４】 図２７に示したリトライＴｙｐｅＣ処理のダウンロードサイト（アプリベンダ）のサーバにおける処理例を示すフローチャートである。
【図３５】 本発明の実施の形態におけるＡＤＦ中の使用期間情報を使ったアプリの起動制御を示すフローチャートである。
【符号の説明】
５０…ＯＳ、５１…アプリ等、５２…アプリ実行環境、５３…期限管理機能、５５…ＡＤＦ、５６…表示マーク（アイコン）、６１…ＪａｖａＶＭ、６３…拡張部、６４…ＪＡＭ、６５…拡張部、６６…ネットワークサービス対応ＡＰＩ、６７…ローカルストレージ、７０…ブラウザ、８０…Ｊａｖａアプリ、２００…管理センサ、２１０…ポータルサイト、２１５…課金管理部、２２０…管理サーバ、２２５…アプリホルダ、２３０…管理部、２３５…決済口座、２４０…ネットワークサービスインタフェース、２５０…ユーザデータベース、２５３…マイメニュー、２６０…アプリデータベース、３００…アプリベンダ、４００…サービス事業者、４２０…ストレージサービスサーバ、４３０…プリントサービスサーバ[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a system that provides an application with a usage time limit (use time limit) mainly via a network, and more particularly to a system that effectively manages the use time limit.
[0002]
[Prior art]
[0003]
2. Description of the Related Art In recent years, electronic commerce using mobile terminals such as mobile phone terminals and portable information terminals has become widespread with the development of Internet-related technologies and mobile communication technologies. (In this specification, a terminal device is simply referred to as a terminal.)
[0004]
For example, electronic commerce is being studied in which an application or the like that runs on an information terminal is downloaded from a computer network and the use is allowed for a certain period (hereinafter referred to as a use period) for a fee or free of charge.
[0005]
In order to allow use of downloaded applications, etc. only within the usage period, for example, a so-called “time bomb”, which is a mechanism that prohibits use of the application, etc. at the end of the usage period, may be incorporated into the application, etc. (See Patent Document 1). This usage time limit is generally calculated by counting the number of days in a predetermined usage period, etc., starting from the date and time when the application or the like is installed on the terminal (as indicated by the clock (calendar) on the terminal side). .
[0006]
In addition, there is a method of limiting the number of times of use, for example, incrementing a certain count value every time the application is activated, and restricting activation if the counted value exceeds a predetermined value.
[0007]
[Patent Document 1]
JP-A-10-222579
[Non-Patent Document 1]
Published by Nomura Research Institute, "Ubiquitous Network", published on December 20, 2000
[0008]
[Problems to be solved by the invention]
However, the conventional technique has the following problems.
[0009]
For example, it is necessary for the vendor to incorporate prohibition means into individual applications, and this is a burden on the vendor. In addition, the period of use must be uniform.
[0010]
In addition, since the starting point of the usage period is determined on the client side, the starting point cannot be determined on the vendor side. For this reason, it is difficult to accurately grasp the usage period, and it is also difficult to accurately observe the usage period.
[0011]
In the case of limiting the number of times of use, since the server does not know how many times the application or the like has been activated, it is managed only at the terminal, and it is difficult to manage the use time limit on the server side. In addition, when data related to the expiration date is rewritten on the terminal side, it is easily guessed that this data is related to usage restrictions, and it becomes easy to perform unauthorized use exceeding the usage restrictions by illegally rewriting this data. .
[0012]
Furthermore, in the case of conventional download sales (a method in which charging is performed when downloading an application or the like), the download may be interrupted in the middle, and it is necessary to confirm the completion of the download. This is a troublesome process on the server side. There may be cases where re-downloading for a certain period of time is permitted in preparation for the case where downloading of an application or the like is interrupted in the middle, but downloading is not possible after this period. This may cause a situation in which the application cannot be acquired even though the user has paid for the money.
[0013]
The present invention has been made in such a background, and the purpose of the present invention is to manage the expiration date of an application with an expiration date provided to the terminal by both the server and the terminal and to ensure that the terminal is protected. Another object of the present invention is to provide an application expiration date management system, a server, and a computer program.
[0014]
Another object of the present invention is to provide a terminal management method capable of easily adding and restoring terminals of registered members of services.
[0015]
Another object of the present invention is to provide a computer program that operates on a terminal that allows a user to quickly and easily recognize the status of a usage period of an application or the like.
[0016]
Still another object of the present invention is to provide a terminal that allows a user to quickly and easily recognize that the service according to the present invention can be used in the terminal.
[0017]
[Means for Solving the Problems]
The application expiration date management system according to the present invention is a system composed of a terminal and a server. The server transfers an expiration date attribute related to at least the expiration date of the application to the terminal separately from the application, and the terminal refers to the expiration date attribute. When the expiration date has passed, the expiration date management means for limiting the use of the application or the like is provided.
[0018]
The usage time limit managing means is provided as part of an execution environment such as a terminal application.
[0019]
The expiration date is, for example, when a predetermined usage period expires starting from an action related to the use of an application or the like between the server and the terminal, and the expiration date attribute is generated each time an action occurs. The
[0020]
The server and the terminal manage the expiration date on substantially the same time axis. For this purpose, for example, when the terminal is connected to the server and the current time of the server is different from the current time by a predetermined time or more, the terminal adjusts the current time to the time managed by the server according to the server instruction. . In addition, the terminal records the use time when the application is used, and the next time the application is used, the use time is compared with the current use time, and the relationship between the two is determined in advance. In some cases, use of applications etc. is restricted.
[0021]
The usage time limit attribute is transferred to the terminal together with the acquisition destination information of the application or the like, and the terminal acquires the application or the like based on the acquisition destination information. Once the acquisition destination information is obtained, the terminal can obtain the application or the like at any time as long as the terminal has the right to use. Therefore, the user can charge for the use right of the application before obtaining the application or the like.
[0022]
In addition, the terminal displays a list of applications and the like acquired from the server and stored therein, and preferably displays the remaining amount of usage period of each application graphically.
[0023]
A terminal management method by a server includes a step of receiving input of personal information of a user when a user performs membership registration for using the service provided by the server from the terminal, a step of assigning a member ID to the user, and the terminal A step of assigning a terminal ID to the terminal, a step of managing the terminal ID in association with the member ID on the server side, and a step of transmitting the member ID and the terminal ID to the terminal and storing them in the terminal. It is characterized by having.
[0024]
In addition, when receiving a connection from a terminal, a step of receiving a transmission of the model ID of the terminal and confirming that the model ID is a predetermined model ID may be further included.
[0025]
The terminal ID is preferably managed in the server and the terminal so that the user cannot recognize the terminal ID.
[0026]
The server preferably receives an input of the member ID, terminal ID and password from the terminal when the terminal is connected to the service provided by the server, and the member ID and terminal ID of the user managed by the server And determining whether to log in against the password.
[0027]
The input of the member ID and the terminal ID is automatically transmitted by the terminal regardless of a user instruction.
[0028]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
[0029]
FIG. 1 shows a schematic configuration of a system in the present embodiment. This system includes a plurality ofterminals 10, amanagement center 200, anapplication vendor 300, astorage service server 420, and aprint service server 430. These components of the system are connected to each other via a network such as the Internet.
[0030]
Themanagement center 200 manages applications and the like (applications, electronic data, etc.) developed by theapplication vendor 300 and provides them to the user of the terminal 10. In the present specification, an application is also simply referred to as an application. Themanagement center 200 also mediates a network service such as a storage providing service and a print service provided by thestorage service server 420 and theprint service server 430 to the user of the terminal 10.
[0031]
In order to achieve such a function, themanagement center 200 includes aportal site 210 and amanagement server 220 for the Internet WWW. Theportal site 210 has a billing management unit 215 and has a function of charging billed applications and services with electronic money. Theportal site 210 naturally has a web server and various CGIs (not shown). Themanagement server 220 manages anapplication holder 225 that stores applications provided from theapplication vendor 300, anetwork service interface 240 that acts as an intermediary between thestorage service server 420 and theprint service server 430, and these applications and services. Amanagement unit 230 is included. Themanagement unit 230 includes a member database (DB) 150 and anapplication database 260 as described later. In the example of the figure, a Java (registered trademark) application is shown as an application.
[0032]
The terminal 10 in the present embodiment is a network terminal other than a personal computer (hereinafter referred to as a PC) called a so-called non-PC terminal. Non-PC terminals (a) CPU processing speed is slower than PCs, (b) Execution memory (RAM) capacity is small, (c) Local storage is small (generally in mega units rather than giga hard disks) (C) Low expandability (no expansion port, etc.), (d) Low operability (not on the keyboard and mouse, but on the numeric keypad, four-way cursor key, touch panel, etc. (E) The display screen is small. For this reason, non-PC terminals are more restricted in both hardware and software than PCs. The non-PC terminal specifically includes a personal information terminal (PDA). The PDA may incorporate a communication function unit such as a LAN interface, a modem, and a wireless communication device, or an expansion slot such as a compact flash (registered trademark) card slot, which includes a LAN card, a modem card, and a wireless communication card. A communication expansion card such as the above may be inserted to perform communication. PDAs are generally portable, but include those that are used stationary on a desk or the like. Some PDAs are built into watches. Non-PC terminals include network home appliance terminals (also called Internet home appliance terminals, Internet appliances, and information home appliance terminals). The network home appliance terminal is a home appliance having a function of connecting to a computer network (including the Internet). Network home appliances are electronic devices that have a relatively close relationship with communications such as set-top boxes, game machines, landline phones, fax machines, printers, copiers, and scanners for Internet TV, digital TV, CATV, etc. Of course, it includes household appliances that can be connected to a network, such as refrigerators, microwave ovens, electric kettles, electric rice cookers, coffee makers, and air conditioners. Further, the non-PC terminal includes a mobile communication device. A mobile (mobile) communication device is a terminal device that moves in association with a person or a vehicle. For example, a mobile phone, a PHS terminal, a car navigation terminal, a car audio device, an in-vehicle radio, an in-vehicle TV, an in-vehicle video, a digital Includes cameras.
[0033]
The terminal 10 includes abrowser 70 for browsing the web, a JAM (Java Application Manager) 64 for downloading applications and managing files, alocal storage 67 for storing downloaded applications, and an application execution for executing theapplication 80. The unit 60 is provided. Thelocal storage 67 in the block of the terminal 10 in the figure is hardware, but the other blocks are software and can be stored in thelocal storage 67.
[0034]
In the present embodiment, the application execution unit 60 includes a Java VM (Java Virtual Machine) 61, aclass library 62, and an API (Application Program Interface) 66 corresponding to a network service. TheJava VM 61 is a module that executes Java bytecode, and operates on an OS (not shown).
[0035]
TheJAM 64 manages the downloading of a Jar file, an ADF (Application Descriptor File) file, etc., the analysis of the ADF file, etc., and exchanges messages with theJava VM 61. The Jar file is a Java application in the Jar format and is an application body. The ADF file is application attribute data that is downloaded prior to downloading a Jar file in accordance with trial use, purchase, update, etc. of the application, etc. (actions related to use of the application, etc.). It is used to determine whether or not billing is possible and to authenticate the code signature of the Jar file. In this embodiment, an expiration date attribute is given to this ADF file. Anextension unit 65 is provided in theJAM 64 for performing various processes associated with the introduction of the usage period attribute.
[0036]
Specifically, theextension unit 65 manages the expiration date of the downloaded application, manages the clock (including the calendar function), manages the member ID and terminal ID, and the security functions (encryption, application necessary for billing) The user's accessible resources (mainly network domain) by code signing, and a user interface for guiding these management functions to the user.
[0037]
The network servicecompatible API 66 has a function of notifying aserver side interface 240 of this request when a user makes a file operation or print request from a specific application.
[0038]
In addition to downloading from theapplication holder 225 in themanagement server 225, the application used by the terminal 10 can also be downloaded directly from theapplication vendor 300 or the like.
[0039]
FIG. 24 shows a configuration example of amobile phone 10 </ b> A as an example of the terminal 10. Thecellular phone 10A is controlled by theCPU 110. ARAM 111, aROM 112, awireless communication unit 113, adisplay device 115, an input I /O interface 116, and asound processing unit 120 are connected to theCPU 110. TheRAM 111 is a memory that provides theCPU 110 with a temporary data storage area and a work area. TheROM 112 is a non-volatile memory that stores a control program executed by theCPU 110 and various data. TheROM 112 may include a rewritable nonvolatile memory such as a flash memory. The Jar file and ADF file of the present embodiment are stored in theRAM 111 and / or theROM 112. Thewireless communication unit 113 is a part that performs voice and data wireless communication with the base station via theantenna 114. Thedisplay device 115 is a display device typified by a liquid crystal display, and displays various types of information such as text and images on the display screen. The input I /O interface 116 is connected to thecursor key 117, theenter key 118, thedial key 119, and the like, and is a part that receives an input operation from the user. Theaudio processing unit 120 is a part that is connected to themicrophone 121 and thespeaker 122 and performs reproduction of a user's voice call or music. Data encoding / decoding processing and audio processing may be performed by theCPU 110 or a separate processor (not shown).
[0040]
FIG. 25 shows a configuration example of aPDA 10B as another example of the terminal 10. ThePDA 10B is controlled by theCPU 130. ARAM 131, aROM 132, a CF card interface (I / F) 133, adisplay device 135, and an input I /O interface 136 are connected to theCPU 130. TheRAM 131 and theROM 132 are the same as theRAM 111 and theROM 112 of the mobile phone. A CF card interface (I / F) 133 is an interface for mounting awireless communication card 134 to which a wireless communication function is added. Thewireless communication card 134 enables communication with a base station. Thedisplay device 135 is a display device similar to thedisplay device 115 of the mobile phone, but usually has a screen size larger than that of the mobile phone. The input I /O interface 136 is a part that receives a user operation from thetouch panel 137 or thebutton 138.
[0041]
In any terminal, the user can select an arbitrary one from a plurality of menu items and move to a desired screen. In selecting a menu item, for example, in a mobile phone, the cursor is moved to a menu item desired to be selected. The menu item indicated by the cursor is highlighted, for example, by highlighting. Next, by depressing the enter key, the menu item indicated by the current cursor is selected. In the case of a PDA, the menu item can be selected by tapping the menu item on the touch panel display with a pen.
[0042]
FIG. 26 shows an example of a network configuration in this embodiment. Thecellular phone 10 </ b> A and thePDA 10 </ b> B are connected to awireless network 145 through thebase station 140. Thewireless network 145 is, for example, a mobile phone packet communication network. Thewireless network 145 is connected to theInternet 157 via agateway 155. Thegateway 155 performs protocol conversion between thewireless network 145 and theInternet 157 and charges a packet transmitted / received for each user. Various servers such as amanagement server 220, abilling server 270, and anapplication vendor 300 are connected to theInternet 157. Accordingly, communication between the terminal 10 and themanagement server 220, thebilling server 270, and theapplication vendor 300 is performed via thewireless network 145, thegateway 155, and theInternet 157. The charging method at thegateway 155 is not limited to this. For example, it is possible to charge for the communication time.
[0043]
FIG. 2 illustrates a service flow in the present embodiment.
[0044]
First, theapplication 80 developed by theapplication vendor 300 is registered in themanagement unit 230 in themanagement server 220 of themanagement center 200, and the application is stored in the application holder 225 ((1)). At this time, although not essential, the operator of themanagement center 200 can collect the application commission fee. Themanagement center 200 receives membership registration of this service from the user of the terminal 10 in the portal site 210 ((2)). At the same time, the member'ssettlement account 235 is opened for electronic commerce ((3)). In this embodiment, electronic money is used as a settlement method, but the present invention is not limited to this.
[0045]
Thereafter, the user who is a member accesses theportal site 210 from the terminal 10 and selects and downloads a desired application ((4)). In the present embodiment, the application is initially used for a user's trial for a limited time (5). If the user likes the app, the user can register for continuous use (purchase application) to the management server 220 ((6)). At this stage, the user pays the usage fee for the first time (7). As a result, the user acquires the right to use the app ((8)). In the present embodiment, an application is provided in the form of a lease that provides a restriction on a usable period. Here, the term “lease” is widely used in the sense of lending, and it means rental and consent. The right held by the user is a usage right (license) of an application with a usage period. In other words, purchasing a right to use an application or the like for a certain period. As a result, the user only needs to pay the price corresponding to the usage period, and can extend the usage period if necessary or purchase again after the usage period has elapsed. The usage fee minus themanagement center 200 fee is distributed to the application vendor 300 ((9)). When the application is a network service compatible application, the storage service and the print service can be received by executing the application. The storage service is a service that lends a storage area for each member on a portal site or the like. The print service is a service for printing out digital photograph data and the like provided by the member. A usage time limit is added to these network services, and the user can receive the service by paying the usage fee within the usage period (10, 11). The usage fee minus the fee at themanagement center 200 is distributed to the service provider 400 (12).
[0046]
As shown in FIG. 3 (a), the basic model of the terminal of the present invention is that the application etc. is used on the application execution environment 52 arranged on theOS 50 and the time limit associated with the application execution environment 52 is attached. Themanagement function 53 manages the expiration date of each application. In this embodiment, the application or the like includes an application program such as the Java application and some of its constituent elements, as well as Web contents such as text, images, videos, music, and markup language files. Is included. The application execution environment refers to a program or a group of programs that are executed on the OS and provide an environment for a user to use an application or the like. Use of an application or the like includes various acts such as browsing, viewing, use, and execution.
[0047]
3 (b1), (b2), (b3), and (c) to (f) show examples of various applications and examples of their execution environments. That is, FIGS. 3B1 to 3B3 show application programs and their execution environments. As shown in FIG. 3 (b1), for the Java application, the Java virtual machine executes the Java bytecode. As shown in FIG. 3 (b2), an application execution file (so-called exe file) created and compiled in C language, for example, is loaded onto a memory by a loader and executed by the CPU. As shown in FIG. 3 (b3), the application execution file to be downloaded in this system may be a part of an application program executed together with other components.
[0048]
Further, as shown in FIGS. 3C to 3F, the download target in this system includes image data, moving image data, music data, and text data. The image data shown in FIG. 3C is expanded and displayed by a viewer corresponding to the format of the image data. If the image data is compressed, the viewer also performs decompression. Also, the moving image data shown in FIG. 3D is reproduced by a player corresponding to the moving image data format. Further, the music data shown in FIG. 3 (e) is compressed in a compression format such as mp3, for example, and the player expands and reproduces the music data. Furthermore, the display format of the text data shown in FIG. 3F is defined by, for example, a markup language represented by HTML. A text viewer like a browser displays text according to the definition.
[0049]
Themanagement server 220 of themanagement center 200 includes amember database 250 for managing member information of the service provided and anapplication database 260 for managing applications registered by the application vendor.
[0050]
FIG. 4 shows a configuration example of themember database 250 held and managed by themanagement unit 230 of themanagement server 220. In this example, amember information 251 record is created for each member at the time of member registration. Themember information 251 includes items of member ID, name, password, mail address, telephone number (telno), birthday, gender, address, member registration date, last login date, and deletion flag.
[0051]
At least oneterminal information 252 record is created for themember information 251. Theterminal information 252 is information related to a terminal used by the member to use the service, and in this example, includes items such as a member ID, a terminal ID, a terminal nickname, a terminal registration date and time, and a deletion flag. The member ID is member identification information that is uniquely assigned to the member when joining the service. The terminal ID is terminal identification information (for example, a serial number) in this service, and is uniquely assigned by the server at the time of terminal registration. The records of theterminal information 252 are created separately for the number of terminals registered by one member.
[0052]
AMy Menu 253 is created for each record of theterminal information 252 on a one-to-one basis. TheMy Menu 253 is for managing a specific application group selected by the user (member) from all the applications managed and provided by the management server, and holds the terminal ID and My Menu ID. Only members can view. In each MyMenu 253, a record ofMy App Information 254 is created for each app whenever a new trial or use of the app is started for the terminal. Myapplication information 254 includes items such as my menu ID, application ID (APPID) / revision number, use period end date, download (DL) number counter, purchase number counter, application deletion date and time. “Usage period end date” indicates the expiration date of the application. “Number of purchases” is the number of times the application is downloaded with payment, but does not necessarily match the “number of downloads”. This is because the download can be performed any number of times as long as it is valid.
[0053]
As can be seen from the structure of the member database, in this embodiment, as shown in FIG. 5, when one member uses this service on a plurality of terminals, a plurality of terminal IDs are assigned to one member ID. In addition, a My Menu is created independently for each terminal ID. For example, an application or the like purchased at the first terminal is registered only in the first menu My Menu and cannot be used from other terminals. In order to use the same application or the like on another terminal, it is necessary to purchase it separately on the other terminal. As described above, applications are not shared among all terminals, and the reason why the menu is assigned to each terminal is as follows. (1) Multiple users use the same terminal with a plurality of terminals under the name of one member. (2) When a member pays electronic money to a paid application, etc., and renews the expiration date, the information is communicated to all other terminals owned by the member. It is difficult, and (3) avoiding a problem that an application purchased from one terminal of a member does not work on another model. In order to cope with a failure or loss of a terminal in which an application or the like whose usage period still remains is registered, a “recovery” function of the terminal is provided as will be described later.
[0054]
FIG. 6 shows a configuration example of theapplication database 260 held and managed by themanagement unit 230. In this example, a newapplication management record 262 is added to theapplication menu 261 when a new application is registered. Theapplication management record 262 includes an application ID, its revision (revision number), vendor ID, application name (Name), application type (Javatype), application category ID, application registration date, trial period, lease unit period, unit price , A deletion flag, an application URL (source information), an application size, a screen size, and the like. The “application category ID” is used when listing applications by category in the application menu described later. “App main registration date and time” is the date and time when the vendor officially registered the application. The trial period is a period during which the application can be used, and is determined for each application. In the example in the figure, it is 3 days. The “lease unit period” indicates a period that can be used by one purchase (including renewal) by the user. “Unit price” is a charge for the one-time purchase. “Delete flag” is a flag that is set when the registration of this application is deleted. There may be a method of deleting the application management record itself when the registered application is deleted, but in this example, a deletion flag is provided to leave a history of application registration. The “application URL” is a URL (Uniform Resource Locator) that can be obtained from the application main body, and may be not only theapplication holder 225 in themanagement server 220 but also a server in the vendor. “Screen size” is data for designating the size of the display area for the application on the terminal. The screen size information is sent to the terminal as the application is downloaded, and is interpreted by the browser of the terminal to realize the designated display area size.
[0055]
In the present embodiment, it is assumed that a single purchase is performed only for “lease unit period”, but the lease unit period × n (n is 1 or more in one purchase) according to the user's selection. (Integer). In this case, for example, if the lease unit period is 10 days, the usage period is 10 × 3 = 30 days. At the same time, the billing is n times the unit price.
[0056]
FIG. 7 shows an example of ADF information 55 in the present embodiment. As described above, the ADF is a file created by the server and sent to the terminal prior to downloading the application by the terminal. The ADF information 55 includes an application name (Name), its revision (revision number), vendor ID, application URL, application size, extension version number (Extension-Version), expiration date (Expiration-Time), lease period, code signature ( Code-Signing), items such as screen size are included. Here, the extension version number (Extension-Version) and the expiration date (Expiration-Time) are data set by the server when the application is downloaded, and other data is copied from theapplication management record 262 of theapplication database 260 described above. Data. The “use period” is a copy of the “lease unit period” in FIG. 6, but if a plurality of lease unit periods can be designated as described above, it becomes a multiple of that period. In the present embodiment, the date and time data at which the usage period ends is specified as the usage time limit. In addition, the character string “, trial” is added to the expiration date data as an identifier for trial use.
[0057]
With reference to FIG. 8, the flow of using the service as viewed from the user side will be described.
[0058]
First, the user purchases a terminal for using this service (S71). In the present embodiment, the use of this service is restricted to a specific terminal model from the viewpoint of security or the like. The terminal model can be determined by the model ID embedded at the time of factory shipment. Even a terminal without a model ID can be determined using, for example, user agent information embedded in an HTTP header sent from the terminal to the server. (In this case, the terminal model is determined from the identifier of the browser installed in the terminal.) The user accesses the portal site from this terminal and performs member registration (S72). Next, electronic money is registered for electronic commerce, and electronic money is replenished in advance (S73). This is the initial process, and it is sufficient to execute it once.
[0059]
Thereafter, the process proceeds to normal processing. In the normal process, first, a desired application is selected from the portal site (S74), downloaded (S75), and tried (S76). In the present embodiment, downloading for trial use is permitted up to three times even after the trial period has elapsed (S77, S78). This can be determined based on the count values of the download count counter and purchase count counter of the My application information in theuser database 250 described above. If the user likes this application during trial use (S79), he / she can purchase this application and obtain an official usage right (S80). When it is necessary to allocate electronic money according to the usage fee at the time of purchase application (S81), the electronic money is replenished (S82). If the usage fee for electronic money is paid (S83), the usage period of this application is set (S84). Although not shown, the purchase operation of this application is possible even after the trial period has elapsed.
[0060]
A countdown of the usage period is started from the purchase of the application, and when the deadline comes (S85), a message to that effect is output when the application is activated (S86). On the other hand, if a repurchase instruction is issued (S87) and the usage fee is paid (S83), the usage period is set again (S84). Although not explicitly shown in the figure, this period of use can be extended before the expiration date. In that case, a new usage period is added to the previous remaining usage period.
[0061]
Hereinafter, specific operations of each part of the system in the present embodiment will be described with examples of screens.
[0062]
FIG. 9 is a processing sequence diagram showing an exchange between the terminal and the management server at the time of member registration. In the present embodiment, the management server performs data communication with the terminal via the Internet via the portal site. Typically, data communication is performed on the TCP / IP protocol using http (hyper text transfer protocol), https, or ftp (file transfer protocol). When using https, the communication contents are concealed using SSL (Secure Socket Layer). In order to limit the terminal using this service to a specific model, the management server receives the model ID from the terminal when the terminal is connected (S111), and confirms that the terminal is the terminal of the planned model. (S112). As will be described later, the registered terminal also transmits the member ID and terminal ID stored therein to the management server at the time of connection. If the management server has not received the model ID or if it has not received the planned model ID, the management server transmits a message indicating that the service cannot be provided (reject message) to the terminal (S113).
[0063]
If the model ID is OK, it is confirmed whether or not the member ID and the terminal ID are received (S114). If these IDs are received, the terminal user is requested to input a password, and if the password is OK, login is permitted (S115). Subsequent operations will be described later.
[0064]
If the member ID and the terminal ID are not received, the terminal is not registered in the service, and the registration selection screen (FIG. 10A) is transmitted to the terminal (S116). Although not shown, even if the management server receives the member ID and the terminal ID, the management server returns a rejection message even when the combination is not registered. Unregistered users select “Register new member” which is an anchor point for member registration. Anchor point is HTML (Hyper This is a part that is embedded in a markup language file represented by Text Markup Language) and linked to another file or site. When the user designates this anchor point, it is possible to move to the link destination described at the position in the markup language file or to execute the designated process. A user who has already registered as a member adds a new terminal to the use of this service, or acquires the acquired right of the registered terminal due to reasons such as damage or loss of the registered terminal. ) Takes over, select "From here" which is an anchor point for terminal registration.
[0065]
In response to the selection input by the user (S117), the management server determines whether it is member registration or terminal registration (S118). In the case of member registration, as shown in FIG. 10 (b), the user is requested to input personal information such as name, password, mail address, address and the above-mentioned terminal nickname, as shown in FIG. 10 (c). The member ID is assigned and registered in the member database (S134), and the user ID is notified to the user (S135). Then, an electronic money registration instruction is received from a member (S136), and electronic money registration processing such as opening an electronic money account is performed (S137). Further, a terminal ID is assigned to the terminal for the member, and the terminal ID is registered in the member database in association with the terminal nickname (S140). Thereafter, as shown in FIG. 10 (d), the user is notified of the registration result (S141) and solicited to move to the login screen.
[0066]
When terminal registration is instructed by the user (S118), as shown in FIG. 11A, the member ID and password are requested (S119), and the input is received (S120) to authenticate the member ( S121). If this authentication is not OK, a rejection message is returned (S122). If the authentication is OK, the user is allowed to select whether to add a terminal as shown in FIG. 11B or recover from a damaged terminal (or transfer from recovery) (S123, S124). In the case of adding a terminal (S125), the user inputs a new terminal nickname as shown in FIG. 11C (S126, S127), and the process proceeds to the terminal registration process (S140).
[0067]
If it is determined in step S125 that the terminal is restored, a restoration process is performed. Specifically, first, as shown in FIG. 11E, the user is made to select a terminal by the terminal nickname (S128), and the recovery target terminal is specified by the user's selection (S129). Next, the My App information 254 (FIG. 4) of the terminal is copied to the My Menu 253 (FIG. 4) of the new terminal (S130), and the deletion flag of the terminal information 252 (FIG. 4) of the instructed terminal nickname is turned ON. (S131). Thereafter, a terminal registration process (S140) similar to the above is performed.
[0068]
After the terminal registration process, the management server transmits a member ID, a terminal ID, a model ID, and a terminal nickname to the terminal (S141). Preferably, the member ID, the model ID, and the terminal nickname are displayed to let the user know the registered contents (S142). However, the terminal ID is also kept secret to the member himself and stored in the local storage in the terminal together with the member ID and the terminal nickname (S143). The terminal model targeted for this service does not provide a means for accessing these data to the user.
[0069]
FIG. 12 shows an example of a terminal screen showing a login screen (a) when a user who has registered as a member uses this service and a top menu (b) displayed after login. The top menu presents menu items such as “application menu”, “my menu”, “electronic money supplement”, “setting”, and “help” as anchor points. The “app menu” is a menu that presents all the apps provided by the service to the user and selects the user's desired app for trial use. As described above, the “My Menu” is a menu in which a specific application (My Application) group selected by the user from the application menu is registered, and the user can apply for this use (purchase), use period or from this screen. The usage period can be updated after the period. In the present embodiment, it is possible to apply for a trial application for a trial application after the usage period in My Menu has elapsed. (However, the number of retrials is limited.) Screen examples of the application menu and my menu will be described later. “Electronic money replenishment” is a menu item for replenishing electronic money prior to the application fee payment. “Setting” is a menu item for updating member information and certificate.
[0070]
FIG. 13 shows a processing sequence of each part of the system when an application trial application is made from the application menu. The management server transmits a top menu to the terminal (S211), receives a request for an application menu from the terminal (S212), and transmits the application menu (S213). When the user selects an application, information specifying the application is transmitted to the management server (S214). In response to this, the management server registers the app in the user's My Menu as a My App (S215). The management server further transmits an HTML file in which the GET_ADF command is embedded to the terminal (S216). This HTML file may be an arbitrary HTML file such as one for notifying the registration result of My application. The terminal interprets this HTML, and sends the embedded GET_ADF command to the management server to request transmission of the ADF file, regardless of the user's instruction (S217). In response to this, the management server receives and interprets the command, and creates an ADF as described in FIG. 7 for the application (S218). At this time, the expiration date incorporated in the ADF is calculated based on the trial period based on the date (or date / time) of the trial application, for example, based on the trial period. The created ADF is transmitted to the terminal (S219).
[0071]
The terminal stores the received ADF in the local storage and analyzes it (S220). Next, JAM is activated (S221). The JAM requests a Jar file that is the application main body from the site indicated by the application URL according to the description content of the ADF (S222). As described above, the application URL may be an application holder in the management server or an application vendor. The Jar file is transmitted from the application URL site to the terminal (S223). The terminal receives this file and stores it in the local storage (S224), and starts managing the expiration date (S225).
[0072]
FIG. 14A shows an example of an application menu transmitted from the management server and displayed on the terminal. In this example, the application menu has menu items such as “category list”, “new application list”, and “search for applications”. FIG. 14B shows an application list screen in which “game” is instructed from a category list screen (not shown) displayed in response to the category list instruction. In this example, the name of each game application, the trial period, and a brief description of the application are shown. When the user designates an arbitrary displayed application, downloading to the terminal is started as described with reference to FIG.
[0073]
An example of screen transition when updating the usage period (including purchase) from My Menu will be described with reference to FIG. FIG. 15A shows a screen example of the My Menu. In this example, menu items such as “download” and “update usage period” are shown.
[0074]
The menu item “download” is used when, for example, applying for a trial again for a trial application in the My Menu after the trial period has elapsed. When “Download” is selected, the screen shown in FIG. 15B is displayed, and the trial application can be downloaded again with a new ADF file, and the usage period can be updated. In this case, since it is a trial, there is no fee payment (charging from the management server side). During the download, the screen shown in FIG.
[0075]
When “update usage period” is selected, a list of applications once purchased is displayed as shown in FIG. 15C, and the user can instruct the update of any application. Here, “update” includes an extension of the use period of the application during the use period, and a repurchase application after the use period has elapsed. When extending the usage period, a new usage period is added to the remaining usage period. Further, since charging is performed at the time of “update”, as shown in FIG. 15D, the price information and the change in the balance of the electronic money are displayed, and the user is confirmed. If the confirmation is obtained, the application main body is downloaded to the terminal together with the new ADF file including the new usage time limit (FIG. 15 (e)).
[0076]
Although not shown, the menu item “Organize My Menu” may be provided in the My Menu of FIG. You can delete My Apps in My Menu.
[0077]
FIG. 16 shows a processing sequence of each part of the system at the time of application update application. When the user selects an arbitrary application for the My Menu sent from the management server to the terminal (S311) (S312), a purchase request is made to the management server along with information for specifying the application from the terminal (S313). The management server makes a billing request for the app to the user with respect to the billing server (S314), and the billing server performs a predetermined billing process accordingly (S315). When the predetermined billing process is performed, a billing OK notification is returned to the management server (S316). After the accounting process is completed, the management server updates the My Menu of the member's terminal (S317). This is the first phase of the application update application process.
[0078]
The management server further transmits an HTML file in which the GET_ADF command is embedded to the terminal (S318). The terminal interprets the HTML and sends a GET_ADF command to the management server to request transmission of the ADF file regardless of the user's instruction (S319). In response to this, the management server creates an ADF for the application (S320). At this time, the use time limit incorporated into the ADF is, for example, the date (or date and time) at the time of the purchase application as a starting point. When there is a remaining period, the usage period end date (or date and time) is calculated by adding the remaining periods. The created ADF is transmitted to the terminal (S321). This is the second phase of the application update application process.
[0079]
In the subsequent third phase, the terminal stores the received ADF in the local storage and analyzes it (S322). Next, JAM is activated (S323). The JAM requests a Jar file that is the application main body from the application URL site according to the description content of the ADF (S324). A Jar file is transmitted from the application URL site to the terminal (S325). The terminal receives this file and stores it in the local storage (S326), and starts managing the expiration date (S327).
[0080]
With such a configuration, the following effects can be obtained.
(1) When everything is performed normally, the purchase application, billing, and downloading of the application main body are performed in a series of procedures, and the user does not need any operation other than the purchase application and is not conscious of it.
(2) In the first phase, after the purchase application command is transmitted from the terminal to the management server, the process is performed only between the management server and the accounting server, so that the stability of the system is high. Further, the first phase is not interrupted due to a communication abnormality between the terminal and the server.
(3) Although an abnormality may occur in communication between the terminal and the management server, if the first phase is completed, the second phase and subsequent steps may be redone (if the user downloads from My Menu, ADF File and Jar file can be acquired.) Therefore, it is not necessary to generate a duplicate charge.
(4) In the second phase, the file to be received by the terminal is only the transmission of a relatively small file called an ADF file different from the application main body (Jar file), so the session including charging is interrupted due to a line failure or the like. Risk can be extremely low.
(5) In the third phase, if the size of the Jar file is large, a communication error may occur between the terminal and the vendor, and the Jar file may not be completely downloaded (in particular, the terminal may be mobile type (mobile) information) If it ’s a device). In this case, only the third phase can be redone (specifically, since there is an ADF, the app is displayed in the playlist but there is no substance, so the connection is made to the app URL here and the download is retried). If the application URL is other than the management server (for example, a vendor), the management server is not involved in the download re-execution, so the burden can be reduced. The benefits are greater when the data is large.
[0081]
In order to prevent double charging, when charging is made for the first time when the terminal confirms that the application (Jar file) has been completely downloaded, it is necessary to wait for charging from the first phase to the third phase. However, in this embodiment, such a need is not required, and the burden on the server is reduced. In other words, in this embodiment, as long as the first phase is completed, charging is not performed twice, and the management server does not need to confirm the end of the third phase.
[0082]
On the other hand, since it can be downloaded any number of times within the usage period, it can be said that the processing after the second phase is independent of the billing. Therefore, there is no risk of double charging, and the user can acquire the application. Therefore, when the storage device (local storage) inside the terminal is full (or there is no room), the data can be deleted without any worries, and if necessary, the second phase or later can be used. It becomes possible. Therefore, the site of the application URL can be used as if it is a “virtual storage” of the terminal.
[0083]
FIG. 27 is a flowchart showing the operation of the terminal corresponding to FIG. When a browser is started on the terminal and the service is logged in (S711), the My Menu transmitted from the management server is displayed (S712). Accordingly, the user receives a selection of an application to be purchased from the applications displayed on the My Menu (S713). When the application is selected, the terminal transmits a purchase request to the management server (S714). Thereafter, the terminal checks whether or not an error notification indicating that the accounting process has not been established has been received from the management server (S715). If there is a billing error notification, for example, a billing NG message such as “The billing procedure could not be completed. Please start the application purchase procedure from the beginning.” Is displayed, and the processing is stopped (S716). If there is no accounting error notification, the terminal receives an HTML file in which the GET_ADF command is embedded from the management server (S717). At this time, it is determined whether or not the HTML file is normally received (S718). When an error occurs in communication while receiving an HTML file, an error notification is sent from a TCP / IP protocol processing program in a lower layer than the browser. If the determination result in step S718 is No, for example, a retry Type A request message such as “Communication has been interrupted. Please connect to the My menu and download the application” is displayed, and the application is downloaded to the user. The user is prompted to perform the procedure (S719). This is a state in which the billing result is OK, but the process cannot be shifted to the phase 2, and the processing after the billing processing can be performed.
[0084]
On the other hand, when the HTML can be normally received, the terminal interprets the HTML (S720), and transmits the embedded GET_ADF command to the management server (S721). Thereafter, the terminal checks whether or not the ADF is normally received from the management server (S722, S723). In the case of No, for example, a retry type B request message such as “Communication has been interrupted. Please re-download the application” is displayed to prompt the user to re-download the application (S724). Here, the second phase cannot be completed normally, and it is necessary to start again from the place where the ADF file is received. Since HTML has already been received, this is used to start again from transmission of the GET_ADF command. Details of this point will be described later.
[0085]
On the other hand, if the ADF is successfully received, the JAM is activated (S725). The JAM connects to the application vendor site according to the ADF information, and requests a Jar file (S726). Next, a Jar file is received from the management server (S727). Thereafter, the terminal checks whether or not the Jar file has been normally received (S728). In case of No, for example, “Communication was interrupted while downloading the application. Please execute“ Get Latest Version ”from the playlist. "Retry Type C request message" is displayed, and the user is prompted to "get latest version" from the playlist (S729). Here, since the third phase has not been completed normally, it is necessary to start again from the place where the Jar file is received. Since the ADF has been received, the application information is displayed in the playlist, but the substance data cannot be acquired. Therefore, the JAR file reception request is redone using ADF. Details of this will be described later.
[0086]
Note that the redo process can be designed to be performed automatically. However, since the radio wave condition is considered to be a major factor for interrupting the process, it is preferable that the user moves to a place with a good radio wave condition and retry the process based on his / her own judgment. However, a process of retrying while watching the radio wave condition is also possible.
[0087]
FIG. 28 is a flowchart showing the operation of the management server corresponding to FIG. When there is a login from the terminal (S741), the management server transmits the user's My Menu to the terminal (S742). Thereafter, if there is a purchase request from the terminal (S743), a charging request is transmitted to the charging server (S744). Waiting for a response from the billing server (S745). If billing is not OK (S746, No), a “billing NG” notification is transmitted to the terminal (S747). If charging is OK, the My Menu is updated (S748), and HTML transmission is performed (S749). Thereafter, if there is an ADF request from the terminal (S750), an ADF is created (S752) and transmitted to the terminal (S753). If there is no ADF request for a predetermined time or more (S751), this process is terminated.
[0088]
It should be noted that after the HTML transmission in step S749, the processing may be stopped once and ADF creation / transmission may be performed when an ADF request is made.
[0089]
FIG. 29 and FIG. 30 show processing examples of the above-described retry type A processing in the terminal and the management server, respectively. In this type of retry, since the billing process has already been completed and the update of My Menu has been completed, the user logs in to the service from the terminal and selects the target application displayed on the My Menu, so that the HTML reception request or later Can be retried.
[0090]
More specifically, in FIG. 29, the terminal receives and displays the My Menu after service login (S761) (S762), and accepts a download selection from the user (S763). Therefore, a list of my apps is received and displayed (S764). When an application selection for download is received from the user (S765), a corresponding HTML request is transmitted (S766), and the corresponding HTML is received (S767). Next, it is checked whether the HTML reception has been completed normally (S768). If not normal, a retry type A request message as described above is displayed (S769). If normal, the HTML is interpreted (S770), and a GET_ADF command is transmitted (S771). Next, an ADF corresponding to this is received (S772), and it is checked whether or not the reception has been completed normally (S773). If not normal, the retry type B message as described above is displayed (S774). If it is normal, the JAM is activated (S775). The JAM connects to the application vendor site according to the ADF information, and requests a Jar file (S776). Next, a Jar file is received from the management server (S777). Thereafter, the terminal checks whether the Jar file has been normally received (S778). If No, the retry type C request message as described above is displayed (S779).
[0091]
In FIG. 30, when receiving a login from the terminal (S781), the management server transmits the user's My Menu (S782), and further transmits a My Application list (S783). Next, when a download request is received (S784), HTML is transmitted (S785). Thereafter, if there is an ADF request from the terminal (S787), an ADF is created (S788) and transmitted to the terminal (S789). If there is no ADF request for a predetermined time or more (S786), this process is terminated.
[0092]
FIG. 31 and FIG. 32 illustrate an example of the above-described retry type B process in the terminal and the management server, respectively. In this type, since the HTML reception is completed normally, the terminal has a GET_ADF command embedded in the HTML. Therefore, for example, an ADF re-request instruction button is embedded in the retry Type B processing message, and the user instructs this button to accept the ADF re-request instruction. As a result, if the terminal is offline, after connecting to the management server, the terminal interprets HTML and transmits a GET_ADF command to the management server. The management server always waits for a GET_ADF command, and upon receiving the GET_ADF command, creates an ADF and transmits it to the terminal.
[0093]
More specifically, in FIG. 31, when receiving an ADF re-request instruction from the user (S801), the terminal interprets the HTML (S802) and transmits a GET_ADF command (S803). Next, an ADF corresponding to this is received (S804), and it is checked whether or not the reception has been completed normally (S805). If not normal, the retry type B message as described above is displayed (S806). If it is normal, JAM is activated (S807). The JAM connects to the application vendor site according to the ADF information, and requests a Jar file (S808). Next, a Jar file is received from the management server (S809). Thereafter, the terminal checks whether or not the Jar file has been normally received (S810). In the case of No, a retry type C request message as described above is displayed (S811).
[0094]
In FIG. 32, if there is an ADF request from the terminal (S821), the management server creates an ADF (S823) and transmits it to the terminal (S824). If there is no ADF request for a predetermined time or more (S822), this process is terminated.
[0095]
FIG. 33 and FIG. 34 show an example of the above-described retry type C processing in the server of the terminal and the download site (application vendor), respectively. This process is the same as the latest version acquisition from the playlist. In this type of retry, since the ADF reception is completed, it is possible to refer to the playlist in the terminal. However, since only ADF information exists and there is no Jar file, there is no actual data. Therefore, the latest version acquisition process is executed to acquire the Jar file.
[0096]
More specifically, in FIG. 33, when the browser is activated by the user (S831) and the user receives a playlist selection from the menu (S832), the terminal displays a playlist screen (S833) (FIG. 18, 19). Thereafter, the target application is selected from the playlist (S834). The selected application is highlighted (for example, highlighted). In the state where the application is selected (S834), when “Get Latest Version” at the top of the playlist is instructed (S835), JAM is activated, and the ADF information is read by the extended term management function (S836). ), It is determined whether or not the time limit has been exceeded with reference to the usage period information (S837). If the time limit is exceeded, a download NG message is displayed (S839), and this process is terminated. The retry process usually does not exceed the deadline. If the time limit is not exceeded, a Jar request is transmitted to the application vendor site (S840), and Jar is received (S841). If Jar is not received within the predetermined time (S842), a retry TypeC request message is displayed as described above (S843), and this process is terminated.
[0097]
34, when the application vendor site server receives a Jar request from a terminal (S851), it transmits the Jar file to the terminal (S852).
[0098]
In the above, the retry type C process is performed by the same process as the acquisition of the latest version. However, the present invention is not limited to this, and a process specialized for retry can also be executed. In this case, it is not necessary to check the usage period. Further, when an application execution is instructed from a playlist, a retry operation may be automatically performed when there is no Jar file, that is, an application entity.
[0099]
FIG. 17 shows a processing sequence for automatically correcting the clock incorporated in the terminal in this embodiment. This process is executed when the terminal logs in to the management server. When the management server transmits an HTML file such as a top menu (S411), it includes a description of a specific MIME type. In response to this, the terminal browser activates a specific plug-in (S412). The plug-in requests a predetermined control file from the management server (S413). On the other hand, the management server includes the current date and time information in the control file and transmits it to the terminal (S414). The terminal plug-in compares the received current date and time with the current date and time of the clock in the terminal (S415). If there is an error of a predetermined time (for example, 5 minutes) or more, it is determined as an error and the terminal clock is managed. Correction is made to match the server date and time (S417). This control file may include the URL of the next page when the time check is OK, the URL of the error page when NG, and the like. Instead of using the above-mentioned specific MIME type, a description such as <embed src = “Getclock.cgi”> is embedded in the HTML file as an extension tag, and this is interpreted by the browser of the terminal. A control file containing information may be requested.
[0100]
FIG. 18A shows an example of the appearance of the terminal. FIG. 18B shows a menu display state when the terminal is offline. When the user selects “Playlist” from this menu, a playlist screen as shown in FIG. 19A is displayed. The playlist is a list of apps currently stored on the terminal. Each application is displayed with an attribute mark (icon) relating to the usage period. FIG. 19B shows five types of icons in the present embodiment. Theicon 81 indicates that the application is in a trial period.Icons 82 to 85 indicate the remaining amount in stages during the use period. That is, theicon 82 indicates that the usage period of the application remains almost. Theicon 83 indicates that more than half of the trial period remains. Theicon 84 indicates that the expiration date is about to expire. Theicon 85 indicates that the expiration date has already expired. Theicon 86 indicates that the icon has been downloaded from another portal site and has no expiration date. The use period of the trial application indicated by theicon 81 is usually a short period, and the use period of the application of theicon 86 is indefinite. In this sense, it can be said that both theicons 81 and 86 indicate the situation regarding the usage period of the application. With the icon display as a kind of such graphical display, the user can immediately recognize the situation regarding the usage period of each application. As described above, in the present embodiment, the remaining usage period attribute is described with reference to the usage period attribute described in the ADF, and the icon to be displayed corresponding to this is selected.
[0101]
FIG. 23 shows a processing example for icon display in FIG. This process is a part of the process executed when the playlist is displayed. First, a variable i for designating an application is initialized to 1 (S611), and the following processing is repeated for the number of applications. In subsequent step S612, the ADF of application i is checked (S612). Next, it is checked whether the expiration date Expiration-Time is included in the ADF (S613). If not included, this icon is an application with no expiration date, so theicon 86 is selected (S614). Thereafter, it is checked whether or not the variable i is the final application (S628). If the variable i is final, the process is terminated. If not final, the variable i is incremented (S615), and the process returns to step S612. If the use time limit is included in step S613, the remaining time is calculated based on the use time limit and the current date and time (S616). If there is no remaining time (that is, 0 or negative) (S617), theicon 85 is selected (S618), and the process proceeds to step S628. If there is a remaining time, it is checked whether or not the character string “, trial” is added to the expiration date Expiration-Time (S619). If added, since this application is a trial application, theicon 81 is selected (S620), and the process proceeds to step S628. If it is not a trial application, the unit of remaining time and usage period is converted (S621). For example, the time in days is converted into finer units (for example, seconds). This conversion process is not essential, but by performing this conversion, more accurate determination of the remaining amount can be performed. Next, D is a quotient obtained by dividing the remaining time by the usage period (S622). The value of D indicates the ratio of the remaining time per usage period. If D is less than 1/3 (S623), theicon 84 is selected (S624). If D is not less than 1/3 and less than 2/3 (S625), theicon 83 is selected (S626). Otherwise, theicon 82 is selected (S627). Such processing is repeated until the variable i is final (S628).
[0102]
For each application in the playlist of FIG. 20 (a), as shown in FIG. 20 (b), the member ID, model ID, and terminal nickname are confirmed as terminal information, or as shown in FIG. 20 (c) As detailed information, the name, version, and size of the application can be confirmed, and as shown in FIG. 20D, the expiration date of the application can be confirmed. The expiration date of the example shown in the figure indicates the date, but it may be specified up to the time in addition to the date.
[0103]
Note that the user can also delete any application in the playlist in order to effectively use the limited storage capacity in the terminal. At this time, the corresponding ADF file is also deleted. However, it is still registered as My App in the My Menu in the management server. Therefore, if the deleted app is a purchased app and the usage period remains, the user can acquire the ADF from the server and use the app if necessary within the usage period. It can be downloaded again for free. The same applies to an application or the like in which the main body or the ADF is damaged instead of being deleted.
[0104]
FIG. 35 is a flowchart showing application activation control using usage period information in the ADF. First, the browser is activated in response to an instruction from the user at the terminal (S861). When the user selects a playlist (S862), a playlist screen is displayed (S863). If there is an application activation instruction (S864), the current date and time are confirmed (S865), and ADF information is read (S866). Therefore, the use period (use deadline) of the application is compared with the current date and time (S867). If the usage time limit is exceeded, activation of the application is suppressed (S869). Otherwise, the application is activated (S870).
[0105]
FIG. 21 is a flowchart of processing for checking the clock of the terminal when the user executes the application downloaded to the terminal. As described above, the date and time of the clock built in the terminal is adjusted to the clock of the server, but it is conceivable that the paid application is illegally used by intentionally reversing the clock after the usage period has elapsed. In this embodiment, when an application is activated, the date and time of the previous application are compared with each other, and activation of the application is suppressed when it is detected that the progress of the clock is not natural.
[0106]
In FIG. 21, when the terminal (JAM) receives an activation instruction for an application in the playlist by the user (S511), first, the current date and time is confirmed from the clock in the terminal (S512). Next, the date and time when the application stored in the terminal was last activated is checked (S513). Therefore, the two dates and times are compared (S514), and if the current activation date / time is past the previous activation date / time, it is determined that the time is reversed, and the terminal then connects to the management server and the terminal clock is The application is inhibited from being activated until it is synchronized with the clock of the management server (S515). As a result, it is possible to prevent fraud in which the user intentionally corrects and executes the clock with an incorrect date and time after a certain application usage period has elapsed. When comparing the date and time in step S516, a retrograde of about several minutes may be allowed as an error. If the activation of the application is inhibited, a warning message to that effect is output to the user (S516). If it is determined in step S514 that there is no time reversal, the application is allowed to start (S517), and at that time the date and time is updated and recorded as the “previous start date and time” of the application.
[0107]
FIG. 22 is a diagram illustrating an example of a terminal screen on which display marks (icons) 56 are displayed. Thisdisplay mark 56 is an application that provides an execution environment that can use the service provided by the management server in the present embodiment (typically a browser, which incorporates the above-mentioned time limit management function extension). ) Indicates that the device is installed. As described above, the service according to the present invention may or may not be supported depending on the terminal model. Therefore, when thismark 56 is displayed, the user immediately indicates that the terminal is compatible with the service. Can be recognized. Thedisplay mark 56 is not limited to a simple display, and may be an activation icon for activating some process. For example, when this activation icon is clicked, a playlist may be displayed, or a user may connect to a portal site and log in to display a my menu. In addition, the design of an icon, the screen which displays an icon, and the position in the screen are not restricted to the example of illustration.
[0108]
A storage providing service and a print service provided by thestorage service server 420 and theprint service server 430 shown in FIG. 1 will be briefly described. The service provided by thestorage service server 420 is a service that leases to the user a storage area that the user can freely use in order to substantially expand the storage capacity of the user's terminal. The period can be limited. In this case, the application downloaded by the terminal is an application and / or data for using the service. The service provided by theprint service server 430 is processing software or the like for processing digital image data taken by a user as an application, for example, with a digital camera. It is possible to charge at the server, send print target data to the management server or another predetermined server, request print output, and receive the printed matter at a predetermined location (for example, at a store of a chain store). In these network services, a service URL that provides the service can be used instead of the application URL in the ADF.
[0109]
The effects of the embodiment described above are summarized as follows.
(1) The expiration date attribute indicating the expiration date of the application generated on the server operation side is transferred to the terminal separately from the application and the use and download of the application are controlled according to the expiration date attribute. It is no longer necessary to prepare a “time bomb”, and the expiration date intended by the server operator (portal site, vendor) can be set.
(2) By matching both clocks between the management server and the terminal, the expiration date can be managed on substantially the same time axis on the management server side and the terminal side.
(3) The terminal can perform restriction management of use even when an application or the like is executed locally according to the use time limit attribute. By (2) and (3), it is possible to make the user observe the expiration date of the application or the like in a stricter sense.
(4) Since the expiration date is managed on the terminal side, there is no need to connect to the server to confirm the expiration date. Therefore, it is possible to save time and effort for connecting to the server and waste of communication costs each time an application or the like is activated.
(5) Since the usage period attribute is generated every time an application transaction (trial, lease, etc.) occurs between the user and the server operation side, the usage period does not need to be uniform for each application. Furthermore, it is possible to set different conditions (such as a use period) for each exchange.
(6) Since the app itself can be obtained free of charge from the outside of the terminal at any time during the usage period, it is possible to delete the app without any worries even if the capacity of the storage device inside the terminal is limited. it can.
(7) At the time of billing associated with downloading of applications, etc., charging processing can be completed without downloading the actual main body of applications, etc. by ensuring that downloading of applications, etc. can be downloaded any number of times within the usage period. Can do. In other words, since it is only necessary to transfer extremely small data (ADF file) that is separate from the main body of the application etc. (not including the application etc.) from the management server side to the terminal, the probability that the process will be interrupted in the middle is not Compared to the probability that the download processing of the main body of an application or the like is interrupted, it is extremely small.
(8) Since stricter deadline management is possible, leasing of applications, etc. with a very short term (one day, one hour, etc.) has been realized while ensuring the safety permitted in actual economic activities. can do.
(9) When displaying a trial or leased application on the terminal, the numerical display is shown by graphically displaying the type (trial or lease) or the remaining status of the trial / use period with icons, etc. Compared with, the user can recognize the situation immediately and intuitively, which is convenient. From the application provider side, the user can be motivated to extend the usage period by visually indicating the remaining usage period.
(10) Since the server manages the application for which trial or lease is given for each user in the server, when the application information (ADF) in the terminal is damaged, the terminal is based on the information managed by the server. Side application information can be restored.
(11) When a user registers as a member, not only the member ID but also a terminal ID for identifying a terminal used for the service is assigned, and these IDs are stored in the terminal, and the terminal ID is also secretly managed by the user. Thus, by checking the terminal ID as well as the member ID and password at the time of login or the like, so-called impersonation of the member can be prevented.
(12) The terminal that can use the service is restricted to a specific terminal such as a personal computer (hereinafter referred to as a PC) referred to as a non-PC terminal by checking the model ID of the terminal at the time of login or the like on the management server side. can do. As a result, the terminal ID stored in the local storage or the like inside the terminal can be prevented from being read illegally, and the effect of (11) can be made more reliable.
(13) By assigning different terminal IDs to different terminals for the same member, it is possible to prevent fraud in which a plurality of users use the same paid application or the like using a plurality of terminals under the name of one member.
(14) By assigning a terminal nickname to each terminal, the target terminal can be specified at the time of “restoration” of the terminal in which an application or the like whose usage period still remains is registered.
[0110]
The preferred embodiments of the present invention have been described above, but various modifications and changes other than those mentioned above can be made within the scope of the claims.
[0111]
For example, to limit the activation of an application after the expiration of the usage period, there are some restrictions on the function, such as displaying an overlapping warning message such as “sample” or “expiration of the expiration date”, etc. It also includes restricting the use of some.
[0112]
Instead of the portal site, it may be a stationary information processing apparatus provided at a store or the like as a so-called multimedia kiosk (see Non-Patent Document 1). If this apparatus is equipped with a billing system such as a vending machine, it is possible to collect charges from the user using cash or a credit card. In this case, the communication between the multimedia kiosk and the terminal can use means suitable for local (short-distance) communication such as infrared rays and Bluetooth (trademark), but is not particularly limited.
[0113]
The expiration date is calculated by the server and described in the ADF file. The server also describes the date and time of use as the starting point and the usage period as the expiration date attribute in the application attribute data. May be calculated.
[0114]
As an example of synchronizing the clock of the terminal and the clock of the management server, the terminal clock is forcibly set to the clock of the management server. However, the clock of the terminal may be set by a server other than the management server. . Furthermore, if the suitability of the terminal clock is guaranteed in some way, it is not always necessary to match the server clock. As a result, it is sufficient if the expiration date is managed on substantially the same time axis between the server and the terminal.
[0115]
The terminal is exemplified as a non-PC terminal, but it is not always necessary to be a non-PC terminal if a necessary measure is taken from the viewpoint of security. In other words, any device (network terminal) having an ability to bidirectionally exchange data with a server or another terminal via a network (including the Internet) may be used. Further, it may be a terminal emulator (browser operating on a PC + Java VM + expiration management extension) for simulating the execution of an application or the like.
[0116]
The protocol used in communication is not necessarily limited to the above as long as the intended purpose can be achieved.
[0117]
Although the application etc. showed the example downloaded via a network, you may make it receive the data broadcast from a delivery origin via broadcasting networks, such as digital broadcasting, for example.
[0118]
Some functions of the trial application may be limited compared to the purchased application.
[0119]
The trial use of an application or the like is not necessarily essential, and a system that makes a purchase without trial is also possible.
[0120]
Although the execution of the application is shown to be performed locally, it may be online in all or part of the execution of the application, as in the case of a battle game or the like.
[0121]
Although an example in which the usage period of each application or the like is constant has been shown, the lease period may be selected by the user even for the same application. The billing in that case can be increased or decreased according to the usage period.
[0122]
Although the icon display regarding the remaining amount of the usage period has been described only for the playlist, it can also be performed for other screens such as My Menu.
[0123]
Depending on the model ID, the type or format of the application provided to the terminal may be changed or selected.
[0124]
Since the terminal nickname is essentially sufficient if a plurality of terminals held by one member can be identified from each other, in the above description, the user is allowed to specify, but the server side may decide. The nickname may be simply identification information.
[0125]
【The invention's effect】
ADVANTAGE OF THE INVENTION According to this invention, it becomes possible to make it ensure in a terminal by managing the use time limits, such as an application with a use time limit provided to a terminal from the server side by both a server and a terminal.
[0126]
Also, by assigning a terminal ID that is not recognized by the user to each terminal from the server side, it becomes possible to more accurately authenticate the registered member of the service and the terminal.
[0127]
Furthermore, by adding a terminal nickname to each terminal, it becomes easy to add and restore terminals of registered members of the service.
[0128]
In the list display of applications and the like, the status of the expiration date of use of applications and the like is displayed as an icon, so that the user can quickly and easily recognize.
[0129]
Further, by displaying a predetermined mark indicating that the service according to the present invention can be used at the terminal, it is possible to make the user quickly and easily recognize that the service can be used on the terminal.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a schematic configuration of a system in an embodiment of the present invention.
FIG. 2 is a flowchart showing a service flow in the embodiment of the present invention.
FIG. 3 is a diagram illustrating an application to which the present invention is applied and an execution environment thereof.
FIG. 4 is a diagram showing a configuration example of a member database in the embodiment of the present invention.
FIG. 5 is a diagram showing a relationship among members, member IDs, terminal IDs, and my menus in the embodiment of the present invention.
FIG. 6 is a diagram showing a configuration example of an application database according to the embodiment of the present invention.
FIG. 7 is a diagram showing an example of ADF information in the embodiment of the present invention.
FIG. 8 is a flowchart illustrating a flow of using the service as viewed from the user side in the embodiment of the present invention.
FIG. 9 is a processing sequence diagram showing an exchange between a terminal and a management server at the time of member registration in the embodiment of the present invention.
FIG. 10 is a diagram showing an example of screen transition of a terminal at the time of member registration in the embodiment of the present invention.
FIG. 11 is a diagram showing an example of screen transition of a terminal at the time of terminal registration in the embodiment of the present invention.
FIG. 12 is a diagram showing an example of a terminal screen showing a login screen (a) and a top menu (b) displayed after login when a user who has registered as a member uses the service in the embodiment of the present invention; is there.
FIG. 13 is a sequence diagram showing processing of each part of the system when an application trial application is made from the application menu in the embodiment of the present invention.
FIG. 14 is a diagram showing a screen example of the application menu (a) and category list (b) terminal in the embodiment of the present invention.
FIG. 15 is a diagram showing an example of screen transition when a usage period is updated (including purchase) from the My Menu according to the embodiment of the present invention.
FIG. 16 is a sequence diagram of processing in each part of the system at the time of application update application according to the embodiment of the present invention.
FIG. 17 is a sequence diagram of processing for automatically correcting a clock built in the terminal according to the embodiment of the present invention.
FIG. 18 is a diagram showing an appearance (a) of a terminal and a menu display state (b) in an offline state according to the embodiment of the present invention.
FIG. 19 is a diagram showing a play list screen (a) and attribute marks (icons) (b) relating to usage periods of each application in the embodiment of the present invention.
FIG. 20 is a diagram showing display screen examples (a) to (d) of various types of information according to the embodiment of the present invention.
FIG. 21 is a flowchart of processing for checking a clock of a terminal when an application is executed in the embodiment of the present invention.
FIG. 22 is a diagram showing an example of a terminal screen on which display marks (icons) are displayed according to the embodiment of the present invention.
FIG. 23 is a flowchart of a processing example for displaying icons in FIG. 19;
24 is a block diagram showing a configuration example of amobile phone 10A as an example of the terminal 10. FIG.
25 is a block diagram showing a configuration example of aPDA 10B as another example of the terminal 10. FIG.
FIG. 26 is a diagram showing an example of a network configuration in the embodiment of the present invention.
FIG. 27 is a flowchart showing the operation of the terminal corresponding to FIG. 16;
FIG. 28 is a flowchart showing the operation of the management server corresponding to FIG. 16;
FIG. 29 is a flowchart illustrating a processing example in the terminal of the retry type A process illustrated in FIG. 27;
30 is a flowchart illustrating a processing example in the management server of the retry type A process illustrated in FIG. 27;
FIG. 31 is a flowchart illustrating a processing example in the terminal of the retry type B process illustrated in FIG. 27;
32 is a flowchart illustrating a processing example in the management server of the retry type B process illustrated in FIG. 27;
FIG. 33 is a flowchart illustrating a processing example in the terminal of the retry TypeC process illustrated in FIG. 27;
34 is a flowchart showing an example of processing in the server of the download site (application vendor) of the retry TypeC process shown in FIG. 27. FIG.
FIG. 35 is a flowchart showing application activation control using usage period information in the ADF in the embodiment of the present invention.
[Explanation of symbols]
50 ... OS, 51 ... application, etc. 52 ... application execution environment, 53 ... time limit management function, 55 ... ADF, 56 ... display mark (icon), 61 ... JavaVM, 63 ... extension unit, 64 ... JAM, 65 ... extension unit , 66 ... API corresponding to network service, 67 ... Local storage, 70 ... Browser, 80 ... Java application, 200 ... Management sensor, 210 ... Portal site, 215 ... Charge management unit, 220 ... Management server, 225 ... Application holder, 230 ... Management unit, 235 ... payment account, 240 ... network service interface, 250 ... user database, 253 ... my menu, 260 ... application database, 300 ... application vendor, 400 ... service provider, 420 ... storage service server, 430 ... print service server

Claims (26)

Translated fromJapanese

ネットワークを介して接続される端末と管理サーバとを含むネットワークシステムにおいて、管理サーバから端末へダウンロードされたアプリケーション等の利用期限を管理する利用期限管理方法であって、
前記管理サーバで管理され前記端末がダウンロード可能なアプリケーション等を表した第１のメニューを前記管理サーバが前記端末に提示するステップと、
前記端末のユーザにより前記第１のメニュー上の複数のアプリケーション等から選択された一つのアプリケーション等の利用期限に関する利用期限属性を当該アプリケーション等の入手先情報とともに前記管理サーバが前記端末に送信し、当該入手先情報に基づいて当該アプリケーション等を当該端末にダウンロードさせるステップと、
前記選択されたアプリケーション等について、前記管理サーバが、当該アプリケーション等の利用期限を管理するためのレコードを生成し、端末単位に当該端末についてダウンロードされた１以上のアプリケーション等の利用期限をそれぞれの前記レコードに基づいて管理するステップと、
前記端末において、受信した前記利用期限属性に基づいて、利用期限を越えたアプリケーション等の利用を抑止させるステップと、
管理サーバが、一つの端末からの要求に応じて、当該端末について更新対象のアプリケーション等およびその利用期限に関する情報を第２のメニューとして当該端末に提示するステップと、
管理サーバが、前記端末からいずれかのアプリケーション等の利用期限の満了の前後にかかわらず当該アプリケーション等の利用期限の更新の要求に応じて、当該レコードを更新するステップと、
管理サーバが、更新されたレコードのアプリケーション等の新たな利用期限属性を当該端末へ送信するステップと
を備えたことを特徴とする利用期限管理方法。In a network system including a terminal and a management server connected via a network, an expiration date management method for managing an expiration date of an application downloaded from the management server to the terminal,
The management server presenting the terminal with a first menu representing an application or the like that is managed by the management server and can be downloaded by the terminal;
The management server transmits a usage time limit attribute related to a usage time limit of one application selected from a plurality of applications on the first menu by the user of the terminal together with the acquisition destination information of the application to the terminal, Downloading the application etc. to the terminal based on thesource information ;
For the selected application or the like, the management server generates a record for managing theexpiration date of such the application, each of the downloaded for the terminal to the terminal unit 1 or moreexpiration date of application, etc. Managing based on records,
In the terminal, based on the received expiration date attribute, the step of suppressing the use of an application that has exceeded the expiration date;
The management server presenting, as a second menu, information on the application to be updated and the expiration date of the application to the terminal in response to a request from one terminal;
A step in which the management server updates the record in response to a request for updating the expiration date of the application, etc., before or after the expiration of the expiration date of any application, etc. from the terminal;
A management server comprising: a step of transmitting a new usage period attribute such as an application of the updated record to the terminal.請求項１に記載の利用期限管理方法であって、前記管理サーバは、前記アプリケーション等をダウンロードした端末に対して、当該アプリケーション等の前記利用期限属性で定まる利用期間の間、当該アプリケーション等を再ダウンロードすることを許容する
ことを特徴とする利用期限管理方法。The usage time limit management method according to claim 1, wherein the management server re-applies the application etc. to a terminal that has downloaded the application etc. during a usage period determined by the usage time limit attribute of the application etc. An expiration date management method characterized by allowing downloading. 請求項１または２に記載の利用期限管理方法であって、前記第２のメニューは、各アプリケーション等についての利用期間の残り時間の表示を含む利用期限管理方法。  3. The expiration date management method according to claim 1 or 2, wherein the second menu includes a display of a remaining period of the usage period for each application or the like. 請求項１または２に記載の利用期限管理方法であって、前記利用期限の更新の要求時点で前記利用期間が残存する場合、前記利用期限属性においてその利用期間に残存期間を加算する利用期限管理方法。  3. The expiration date management method according to claim 1 or 2, wherein, when the usage period remains at the time of request for updating the usage period, the usage period management adds the remaining period to the usage period in the usage period attribute. Method. 請求項１または２に記載の利用期限管理方法であって、前記第１のメニューは、前記アプリケーション等毎に前記利用期限属性で定まる利用期間の表示を含む利用期限管理方法。  3. The expiration date management method according to claim 1, wherein the first menu includes a display of a usage period determined by the expiration date attribute for each application or the like. 請求項１または２に記載の利用期限管理方法であって、前記端末は各アプリケーション等の利用時にその日時と前回利用時の日時とを比較し、時間が逆行していると判断される場合、当該アプリケーション等の利用を抑止する利用期限管理方法。  The use period management method according to claim 1 or 2, wherein the terminal compares the date and time with the date and time of the previous use when using each application, and when it is determined that the time is reversed, A usage time limit management method for suppressing the use of the application. 請求項１または２に記載の利用期限管理方法であって、前記レコードは、当該端末のユーザの会員ＩＤに対応づけられている利用期限管理方法。  3. The expiration date management method according to claim 1 or 2, wherein the record is associated with a member ID of a user of the terminal. 請求項１または２に記載の利用期限管理方法であって、前記第１のメニューはカテゴリ別に構成されている利用期限管理方法。  3. The expiration date management method according to claim 1 or 2, wherein the first menu is configured for each category. 請求項１または２に記載の利用期限管理方法であって、前記アプリケーション等の利用期限の更新は、電子マネーによる使用料の支払いがあったことを条件とし、前記端末に前記新たな利用期限属性を送信することにより行われる利用期限管理方法。3. The expiration date management method according to claim 1 or 2, wherein the update of theexpiration date of the application or the like is performed on the condition that the usage fee is paid by electronic money, and the new expiration date attribute is assigned to the terminal. Expiration date management method performed by sending. ネットワークを介して接続される端末と管理サーバとを含むネットワークシステムにおいて、管理サーバから端末へダウンロードされたアプリケーション等の利用期限を管理する利用期限管理システムであって、
前記管理サーバが、前記管理サーバにより管理され前記端末がダウンロード可能なアプリケーション等を表した第１のメニューを前記端末に提示し、
前記管理サーバは、前記端末のユーザにより前記第１のメニュー上の複数のアプリケーション等から選択された一つのアプリケーション等の利用期限に関する利用期限属性を当該アプリケーション等の入手先情報とともに前記管理サーバが前記端末に送信し、当該入手先情報に基づいて当該アプリケーション等を当該端末にダウンロードさせ、
前記選択されたアプリケーション等について、前記管理サーバが、前記管理サーバに当該アプリケーション等の利用期限を管理するためのレコードを生成し、端末単位に当該端末についてダウンロードされた１以上のアプリケーション等の利用期限をそれぞれの前記レコードに基づいて管理し、
前記端末は、受信した前記利用期限属性に基づいて、利用期限を越えたアプリケーション等の利用を抑止し、
一つの端末からの要求に応じて、前記管理サーバが、当該端末について更新対象のアプリケーション等およびその利用期限に関する情報を第２のメニューとして当該端末に提示し、
前記管理サーバが、前記端末からいずれかのアプリケーション等の利用期限の満了の前後にかかわらず当該アプリケーション等の利用期限の更新の要求に応じて、当該レコードを更新し、更新されたレコードのアプリケーション等の新たな利用期限属性を当該端末へ送信する
ことを特徴とする利用期限管理システム。In a network system including a terminal and a management server connected via a network, an expiration date management system for managing an expiration date of an application downloaded from the management server to the terminal,
The management server presents to the terminal a first menu representing an application or the like that is managed by the management server and can be downloaded by the terminal;
The management server includes a use time limit attribute related to a use time limit of one application selected from a plurality of applications on the first menu by a user of theterminal together with the acquisition destination information of the application etc. Send to the terminal, download the application etc. to the terminal based on thesource information ,
For the selected application or the like, the management server, the management server generates a record for managing theexpiration date of such the application,the expiration date of such one or more applications that have been downloaded for the terminal to the terminal unit Based on each said record,
The terminal suppresses the use of an application or the like that has exceeded the expiration date based onthe received expiration date attribute,
In response to a request from one terminal, the management server presents information related to the application to be updated and the expiration date for the terminal as a second menu to the terminal,
The management server updates the record in response to a request for updating the expiration date of the application, etc. before and after the expiration of the expiration date of any application, etc. from the terminal, and the application of the updated record, etc. An expiration date management system, characterized in that a new expiration date attribute is transmitted to the terminal. 請求項１０に記載の利用期限管理システムであって、前記管理サーバは、前記アプリケーション等をダウンロードした端末に対して、当該アプリケーション等の前記利用期限属性で定まる利用期間の間、前記選択されたアプリケーション等を再ダウンロードすることを許容する利用期限管理システム。11. The usage time limit management system according to claim10 , wherein the management server selects the selected application during a usage period determined by the usage time limit attribute of the application or the like for the terminal that has downloaded the application or the like. Expiration date management system that allows re-downloading etc. 請求項１０または１１に記載の利用期限管理システムであって、前記第２のメニューは、各アプリケーション等についての利用期間の残り時間の表示を含む利用期限管理システム。12. The expiration date management system according to claim10 or11 , wherein the second menu includes a display of a remaining usage period time for each application or the like. 請求項１０または１１に記載の利用期限管理システムであって、前記利用期限の更新の要求時点で前記利用期間が残存する場合、前記利用期限属性においてその利用期間に残存期間を加算することを特徴とする利用期限管理システム。12. The usage period management system according to claim10 or11 , wherein when the usage period remains at the time of request for updating the usage period, the remaining period is added to the usage period in the usage period attribute. Expiration date management system. 請求項１０または１１に記載の利用期限管理システムであって、前記第１のメニューは、前記アプリケーション等毎に前記利用期限属性で定まる利用期間の表示を含む利用期限管理システム。12. The expiration date management system according to claim10 or11 , wherein the first menu includes a display of a usage period determined by the expiration date attribute for each application or the like. 請求項１０または１１に記載の利用期限管理システムであって、前記端末は各アプリケーション等の利用時にその日時と前回利用時の日時とを比較し、時間が逆行していると判断される場合、当該アプリケーション等の利用を抑止する利用期限管理システム。The use period management system according to claim10 or11 , wherein the terminal compares the date and time with the date and time of the previous use when using each application or the like, and when it is determined that the time is reversed, Expiration date management system that suppresses the use of the application. 請求項１０または１１に記載の利用期限管理システムであって、前記レコードは、当該端末のユーザの会員ＩＤに対応づけられている利用期限管理システム。12. The expiration date management system according to claim10 or11 , wherein the record is associated with a member ID of a user of the terminal. 請求項１０または１１に記載の利用期限管理システムであって、前記第１のメニューはカテゴリ別に構成されている利用期限管理システム。A usage period management system according to claim10 or11, wherein the first menu expiration date management system configured by category. 請求項１０または１１に記載の利用期限管理システムであって、前記アプリケーション等の利用期限の更新は、電子マネーによる使用料の支払いがあったことを条件とし、前記端末に前記新たな利用期限属性を送信することにより行われる利用期限管理システム。12. The expiration date management system according to claim10 or11 , wherein the update of theexpiration date of the application or the like is performed on the condition that the usage fee has been paid by electronic money, and the new expiration date attribute is assigned to the terminal. Expiration date management system that is performed by sending 端末を含むネットワークシステムにおいてアプリーションのダウンロードを管理する管理サーバであって、
前記管理サーバにより管理され前記端末がダウンロード可能なアプリケーション等を表した第１のメニューを前記端末に提示する手段と、
前記端末に、当該ユーザにより前記第１のメニュー上の複数のアプリケーション等から選択された一つのアプリケーション等についてその利用期限を越えた利用を抑止させるために利用期限に関する利用期限属性を送信するとともに当該アプリケーション等の入手先情報を送信し、当該入手先情報に基づいて当該アプリケーション等を当該端末にダウンロードさせる手段と、
前記選択されたアプリケーション等について、前記管理サーバに当該アプリケーション等の利用期限を管理するためのレコードを生成し、端末単位に当該端末についてダウンロードされた１以上のアプリケーション等の利用期限をそれぞれの前記レコードに基づいて管理する手段と、
一つの端末からの要求に応じて、当該端末について更新対象のアプリケーション等およびその利用期限に関する情報を第２のメニューとして当該端末に提示する手段と、
前記端末からいずれかのアプリケーション等の利用期限の満了の前後にかかわらず当該アプリケーション等の利用期限の更新の要求に応じて、当該レコードを更新する手段と、
更新されたレコードのアプリケーション等の新たな利用期限属性を当該端末へ送信する手段とを備えた
ことを特徴とする管理サーバ。A management server for managing application downloads in a network system including a terminal;
Means for presenting to the terminal afirst menu that is managed by the management server and represents an application or the like that can be downloaded by the terminal;
The terminaltransmits a usage time limit attribute related to a usage time limitin order to deter usage beyond the usage time limit for one application selected from a plurality of applications onthe first menu by the user. Meansfor transmitting the applicationsource informationand causing the terminal to download the application based on thesource information ;
For the selected application or the like, the management server generates a record for managing theexpiration date of such the application, each of the recordsusage period, such as one or more applications that have been downloaded for the terminal to the terminal unitMeans to manage based on
In response to a request fromone terminal, a means for presenting information related to the application to be updated and the expiration date for the terminal to the terminal as a second menu;
Means for updating the record in response to a request for updating the expiration date of the application, etc. before or after expiration of the expiration date of any application, etc. from the terminal;
A management server comprising means for transmitting a new usage time limit attribute such as an application of an updated record to the terminal. 請求項１９に記載の管理サーバであって、前記管理サーバは、前記アプリケーション等をダウンロードした端末に対して、当該アプリケーション等の前記利用期限属性で定まる利用期間の間、前記選択されたアプリケーション等を再ダウンロードすることを許容する管理サーバ。20. The management server according to claim19 , wherein the management server sends the selected application or the like to a terminal that has downloaded the application or the like for a usage period determined by the usage period attribute of the application or the like. A management server that allows re-downloading. 請求項１９または２０に記載の管理サーバであって、前記第２のメニューは、各アプリケーション等についての利用期間の残り時間の表示を含む管理サーバ。21. The management server according to claim19 or20 , wherein the second menu includes a display of a remaining time of a usage period for each application or the like. 請求項１９または２０に記載の管理サーバであって、前記利用期限の更新の要求時点で前記利用期間が残存する場合、前記利用期限属性においてその利用期間に残存期間を加算する管理サーバ。21. The management server according to claim19 or20 , wherein when the usage period remains at the time when the usage period is updated, the management server adds the remaining period to the usage period in the usage period attribute. 請求項１９または２０に記載の管理サーバであって、前記第１のメニューは、前記アプリケーション等毎に前記利用期限属性で定まる利用期間の表示を含む管理サーバ。21. The management server according to claim19 or20 , wherein the first menu includes a display of a usage period determined by the usage time limit attribute for each application or the like. 請求項１９または２０に記載の管理サーバであって、前記レコードは、当該端末のユーザの会員ＩＤに対応づけられている管理サーバ。21. The management server according to claim19 or20 , wherein the record is associated with a member ID of a user of the terminal. 請求項１９または２０に記載の管理サーバであって、前記第１のメニューはカテゴリ別に構成されている管理サーバ。21. The management server according to claim19 or20 , wherein the first menu is configured by category. 請求項１９または２０に記載の管理サーバであって、端末における前記アプリケーション等の利用期限の更新は、電子マネーによる使用料の支払いがあったことを条件とし、前記端末に新たな利用期限属性を送信することにより行われる管理サーバ。21. The management server according to claim19 or20 , wherein the update of theusage period of the application or the like on the terminal is performed on condition that the usage fee has been paid by electronic money, and a new usage period attribute is set on the terminal. Management server that is performed by sending.

Images