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