JP2011521341A - リソース管理のための方法および装置ならびに前記方法のための記録媒体 - Google Patents

Abstract

本発明のリソース管理方法は、
−リソース記述を含むことを意図されたカードのインスタンス化可能なモデルを記憶するステップ（９０）を含み、前記カードモデルは、新しいカードを作成するためにそのインスタンス化の間に、
・カード識別子、
・アドレスを含む少なくとも１つのアクセス経路、および
・各アクセス経路のための参照領域
の取得を強制し、参照領域は、リソースがアドレスである場合は、前記アドレスに対応する人にコンタクトする、または前記アドレスに対応する情報にアクセスするために参照領域によって指定されることが可能である複数のアプリケーションの中からどのコンピュータ・アプリケーションを実行するべきかを指定する。

Description

本発明は、リソースを管理するための方法および装置ならびにこの方法を実施するための記録媒体に関する。

リソースは、本明細書では、電子計算機のメモリに記憶されている実行可能なファイル、あるいはコンピュータ・アプリケーションが人にコンタクトする、または１つの情報にアクセスすることができるようにするアドレスである。

管理方法は、ユーザがこれらのリソースの１つを容易に見つけることができるようにするために、予め決められた基準に基づいてこれらのリソースを分類しソートすることを可能にする方法を指す。例えば、リソース管理方法は、具体的には、予め決められた基準に基づいてリソースを配列しフィルタリングすることを可能にする。

人々のアドレスを管理するための方法がある。これらの方法はまた、住所録管理方法として知られている。例えば、そのような方法は、マイクロソフト（登録商標）アウトルックとして知られているアプリケーションの中に存在する。この住所録の中のエントリ（「カード」）は、コンタクト先の電話番号、Ｅメールアドレス、および郵便の宛先など、コンタクト先の様々な可能なアドレスを含むように設計されている。このカードは、カードを使用することになっているアプリケーション専用のフォーマットで記録される。したがって、例えば、ユーザが、自分の住所録の中で選択したコンタクト先にＥメールを送信したいと思うときはいつでも、このタスクを実行するためにアウトルック・アプリケーションのみがカードのコンテンツを利用することができる。

さらに、他のリソースを管理するための他の多くの方法がある。例えば、ウェブページまたはＨＴＭＬ（ハイパー・テキスト・マークアップ言語）ページにつながるアドレスを管理するためにインターネット・ブラウザが使用されることが可能である。これらの方法は、ブックマーク管理という用語によってよりよく知られている。他のアプリケーションは、画像、オーディオ・ファイル、またはビデオ・ファイルを管理することを可能にする。しかし、これらの様々な管理方法は、相互に互換性がない。例えば、住所録の管理方法は、ウェブページ、画像、またはオーディオ・ファイルもしくはビデオ・ファイルへのショートカットをも管理することはできない。

しかし、リソースを使用するために実行されるべきコンピュータ・アプリケーションに関係なく、それぞれに異なるタイプのリソースを管理することを可能にするリソースを管理するための方法を有することが好ましい。

本発明は、この願望を満たすことを目指す。したがって、本発明の対象は、リソースの記述を含むことを意図されたカードのインスタンス化可能なモデルを電子計算機のメモリの中に保存することを含むリソース管理方法であって、前記カードモデルは、新しいカードを作成するためにインスタンス化された場合、
・すでに作成された全てのカードのセットの中からこのカードを識別するために使用されるカード識別子、
・リソースがアドレスである場合はアドレスを含み、リソースが実行可能なファイルである場合はアクセス経路を含む少なくとも１つのアクセス経路、および
・各アクセス経路のための参照領域であって、リソースがアドレスである場合は、前記アドレスに対応する人にコンタクトする、または前記アドレスに対応する情報にアクセスするために、参照領域によって指定されることが可能な複数のアプリケーションの中からどのコンピュータ・アプリケーションを実行するべきかを指定する参照領域
の取得を必要とする、リソース管理方法である。

本明細書で使用されるカードモデルは、ユーザによるそのカードの選択に応答してどのアプリケーションが実行されなければならないかを定義することを可能にする。したがって、リソースを管理するためのこの方法は、それぞれに異なるコンピュータ・アプリケーションによってしか使用されることが可能でないアドレスを、単一のカードモデルを用いて管理することを可能にする。したがって、ウェブページへのショートカット、ビデオ・ファイルもしくはオーディオ・ファイルへのアクセス経路、人のＥメールもしくは郵便の宛先、人々の電話番号など、様々なアドレスを管理するために単一のリソースマネージャを使用することが可能になる。

この方法の実施形態は、以下の特徴の１つまたは複数を備えることができる。
−参照領域は、リソースが実行可能なファイルである場合は、記述されたリソースがアクセス経路によって示された位置に配置された実行可能なファイルであることを指定する。
−本方法は、それぞれ第１のアドレスおよび第２のアドレスを記述するためにカードモデルをインスタンス化することにより第１の新しいカードおよび第２の新しいカードの作成を備え、これらの第１のアドレスおよび第２のアドレスのそれぞれの参照領域は、それぞれ第１のコンピュータ・アプリケーションおよび第２のコンピュータ・アプリケーションを指定し、第１のコンピュータ・アプリケーションは、第２のアドレスに対応する人にコンタクトすることも、または情報にアクセスすることもできない。
−インスタンス化可能なモデルはまた、新しいカードを作成するためにインスタンス化された場合、少なくとも１つのタグの名前および値を自由に定義することを可能にする。
−インスタンス化可能なモデルはまた、新しいカードを作成するためにインスタンス化された場合、作成されたカードがユーザに提示されたときはいつでも別のカードのコンテンツを作成されたカードに参照により組み込むために、作成されたカードから別のカードへのリンクを含むことを意図されたフィールドを作成することを可能にする。
−インスタンス化可能なモデルはまた、新しいカードを作成するためにインスタンス化された場合、作成されたカードが複数の参照領域を含むときはいつでもデフォルト・参照領域を定義することを可能にし、デフォルト・参照領域は、ユーザによるそのカードの選択に応答してデフォルトで実行されるべきコンピュータ・アプリケーションを指定する。
−モデルのインスタンス化によって新しいカードが作成された場合、参照領域は、電話をかけるためのアプリケーション、Ｅメールを送信するためのアプリケーション、オーディオ・ファイルまたはビデオ・ファイルを再生するためのアプリケーション、ＨＴＭＬページを表示するためのアプリケーション、およびＲＳＳフィードを表示するためのアプリケーションを備えるグループから選択された実行するべきコンピュータ・アプリケーションを指定することができる。

管理方法のこれらの実施形態は、以下の利点をさらに示す。
−コンピュータ・アプリケーションの実行可能なファイルを記述するために使用されることも可能であるカードモデルを有することは、管理方法をいかなるタイプのリソースにも容易に適応させることを可能にする。
−ユーザがカードによって記述されたリソースに関係なしにタグの名前および値を自由に定義することができるようにするインスタンス化可能なモデルを有することは、それによって、相互に互換性がないコンピュータ・アプリケーションによって使用されることが可能なそれぞれに異なるタイプのリソースを選択することができるように共通の探索基準を定義することを可能にする。
−他のカードのコンテンツを参照により組み込むことを可能にするインスタンス化可能なモデルを有することは、情報が複製されないようにし、これは、結局、作成されたカードを記憶するために必要とされる記憶空間のサイズを限定する。
−デフォルト・参照領域を定義することができるようにするインスタンス化可能なモデルを有することは、これらのカードの使用を簡単にすることを可能にする。

本発明の他の対象は、これらの命令が電子計算機によって実行されたときはいつでも前述のリソース管理方法を実行するための命令を含む情報記録媒体である。

最後に、本発明の他の対象は、リソースの記述を含むことを意図されたカードのインスタンス化可能なモデルを含む電子メモリを備えるリソース管理装置であって、このカードモデルは、新しいカードを作成するためにそのインスタンス化の間に、
・すでに作成されているすべてのカードのセットの中からこのカードを識別するために使用されるカード識別子、
・リソースがアドレスである場合はアドレスを含み、リソースが実行可能なファイルである場合はアクセス経路を含む少なくとも１つのアクセス経路、および
・各アクセス経路のための参照領域であって、リソースがアドレスである場合は、前記アドレスに対応する人にコンタクトする、または前記アドレスに対応する情報にアクセスするために、参照領域によって指定されることが可能である複数のアプリケーションの中からどのコンピュータ・アプリケーションを実行するべきかを指定する参照領域
の取得を強制する、リソース管理装置である。

本発明は、図面に関連して非限定的な例としてのみ提供される以下の説明を読めばよりよく理解されるであろう。

リソース管理装置を組み込んだ電気通信システムの概略図である。 図１のリソース管理装置の中で使用されるカードのインスタンス化可能なモデルの概略図である。 図２のモデルをインスタンス化することにより作成される複数のカードの図である。 図２のモデルをインスタンス化することにより作成される別のカードの図である。 図１の装置を使用したリソース管理方法の流れ図である。

図１は、ユーザが他のユーザにコンタクトする、または情報にアクセスすることができるようにする電気通信システム２を示す。その目的のために、これらのユーザは通信端末を使用する。

図１を簡単にするために、１つの通信端末４のみが図示されている。その他の通信端末の主な特徴は、端末４の以下の説明から推論されることが可能である。

端末４は、情報伝送ネットワーク６を用いて他の人々にコンタクトすることを可能にする。例えば、このネットワーク６は、インターネット・ネットワークを備える。

ここで、端末４は、電話８との電話呼を確立する、またはコンピュータワークステーション１０にＥメールを送信することができる。

端末４はまた、リモート・オーディオ・ファイル・サーバ１２上に保存されているオーディオ・ファイル、およびリモート・インターネット・サーバ１４上に保存されているＨＴＭＬページなど様々な情報にアクセスすることができる。

端末４は、図５の方法を実施するために情報記録媒体上に保存されている命令を実行することができる電子計算機の助けを借りて構成される。ここに記載されている特定の状況では、端末４は、電子メモリ２２に接続されている中央処理ユニット２０を備えたコンピュータである。中央処理ユニット２０はまた、モニタ２４およびキーボード２６を備えたヒューマン−マシン・インターフェースに接続されている。

例えば、中央処理ユニット２０は、メモリ２２の中に保存されているコンピュータ・アプリケーション命令を実行することができる電子計算機２８を備える。

ここで、メモリ２２は、以下のコンピュータ・アプリケーションに対応する実行可能なファイルを備える。
−電話８を呼び出すためのモジュール、およびネットワーク６を用いてＳＭＳ（ショート・メッセージ・サービス）メッセージを送信するためのモジュールを有する電話アプリケーション３０、
−受信側にＥメールを送信することができるアプリケーション３２、
−サーバ１４などのインターネットサーバ上に保存されている情報にアクセスすることができるインターネット・ブラウザ３４、
−ミュージック・ファイルを再生することができるモジュール、ビデオ・ファイルを再生するためのモジュール、およびローカル・メモリの中にまたはサーバ１２などのリモート・ファイル・サーバ上に保存されている画像を表示するためのモジュールを有するコンピュータ・アプリケーション３６。

メモリ２２はまた、図５の方法を実行するために必要な命令３８を備える。したがって、これらの命令３８と計算機２８の組合せは、端末４の中に実装されたリソース管理装置を形成する。

最後に、メモリ２２はまた、図５の方法を実行するために必要とされる様々な情報を備える。具体的には、メモリ２２は、
−インスタンス化可能なカードモデル４０、
−タグ名のリスト４２、
−参照領域名のリスト４６、
−デフォルト・参照領域名のリスト４８、および
−端末４についての情報および端末４のユーザについての情報を記憶するための領域５０
を備える。

図２は、インスタンス化可能なカードモデル４０の一例を示す。このモデルは、
−すでに作成されたその他のカードの全ての中から、作成されたカードを識別することを可能にする単一の識別子を含むことを意図されたＷＣＡＲＤ−ＩＤフィールド、
−カードの名前を含むことを意図されたＷＣＡＲＤ−ＮＡＭＥフィールド、
−リソースへのアクセス経路ならびにそのリソースに関連する参照領域を含むことを意図されたＡＤＤＲＥＳＳセクション、
−作成されたカードが複数のアクセス経路を備える場合はデフォルト参照領域が何であるかを示すことを意図されたＷＣＡＲＤ−ＤＯＭＡＩＮフィールド、および
−１つまたは複数のタグを含むことを意図されたＴＡＧセクション
を備える。

通常、ＷＣＡＲＤ−ＩＤフィールドのコンテンツは、このモデルがインスタンス化されると自動的に書き込まれる。

ＷＣＡＲＤ−ＮＡＭＥフィールドは、そのモデルをインスタンス化することにより新しいカードが作成されたときにユーザによって手動で書き込まれてもよく、あるいはモデルのその他のフィールドのコンテンツに基づいて自動的に書き込まれてもよい。

ＡＤＤＲＥＳＳセクションは、１つまたは複数のアクセス経路を含むことを意図される。アクセス経路は、リソースがアドレスである場合は、コンタクトされるべき人のアドレス、またはアクセスされるべき１つの情報のアドレスである。リソースが実行可能なファイルである場合は、アクセス経路は、その実行可能なファイルのアクセス経路に対応する。アクセス経路の値は、ＡＤＤＲＥＳＳ−ＶＡＬＵＥフィールドに保存される。各アクセス経路は、参照領域６０に関連づけられる。ここでは、参照領域６０は、ＡＤＤＲＥＳＳ−ＤＯＭＡＩＮ−ＮＡＭＥフィールドおよびＡＤＤＲＥＳＳ−ＤＯＭＡＩＮ−ＳＥＲＶＩＣ−ＬＩＳＴフィールドの助けを借りて定義される。ＡＤＤＲＥＳＳ−ＤＯＭＡＩＮ−ＮＡＭＥフィールドは、参照領域の名前を含むように設計される。モデル４０がインスタンス化された場合、この名前はリスト４６からのみ選択されることが可能である。例えば、ここでは、リスト４６は、以下の名前を備える。
−アクセス経路がここでは電話番号であることを示すための「ＴＥＬＥＣＯＭ−ＰＨＯＮＥ」、
−アクセス経路のコンテンツがＥメールアドレスであることを示すための「ＩＮＴＥＲＮＥＴ−Ｅ−ＭＡＩＬ」、
−アクセス経路がＨＴＭＬページのＵＲＬ（ユニフォーム・リソース・ロケータ）であることを示すための「ＩＮＴＥＲＮＥＴ−ＷＥＢ」、
−アクセス経路がＲＳＳ（「リーチ・サイト・サマリ（Ｒｅａｃｈ Ｓｉｔｅ Ｓｕｍｍａｒｙ）」もしくは「ＲＤＦサイト・サマリ」または「リアリー・シンプル・シンジケーション」）フィードに対応することを示すための「ＩＮＴＥＲＮＥＴ−ＲＳＳ」、
−アクセス経路がオーディオ・ファイルにアクセスするための経路であることを示すための「ＦＩＬＥ−ＭＵＳＩＣ」、
−アクセス経路がピクチャを含むファイルにアクセスするための経路であることを示すための「ＦＩＬＥ−ＰＩＣＴＵＲＥ」、および
−アクセス経路がコンピュータ・アプリケーションの実行可能なファイルにアクセスするための経路であることを示すための「ＦＩＬＥ−ＡＰＰＬＩＣＡＴＩＯＮ」。

ＡＤＤＲＥＳＳ−ＤＯＭＡＩＮ−ＳＥＲＶＩＣＥ−ＬＩＳＴフィールドは、ＡＤＤＲＥＳＳ−ＶＡＬＵＥフィールドのコンテンツを使用することができるコンピュータ・アプリケーションのリストを含む。ここでは、ＡＤＤＲＥＳＳ−ＤＯＭＡＩＮ−ＳＥＲＶＩＣＥ−ＬＩＳＴフィールドのコンテンツは、ＡＤＤＲＥＳＳ−ＤＯＭＡＩＮ−ＮＡＭＥフィールドの会議の機能である。例えば、ＡＤＤＲＥＳＳ−ＤＯＭＡＩＮ−ＳＥＲＶＩＣＥ−ＬＩＳＴフィールドのコンテンツは、以下の表の助けを借りて定義される。

したがって、参照領域６０は、ＡＤＤＲＥＳＳ−ＶＡＬＵＥフィールドのコンテンツを使用するためにどのコンピュータ・アプリケーション（１つまたは複数）が実行されなければならないかを定義する。複数のアプリケーションが可能であるときはいつでも、実行されることが可能であるそれぞれに異なるアプリケーションの中からユーザ自身が選択することができるように、メッセージが表示される。

ここで、アプリケーション「ＰＬＡＹＥＲ−ＰＨＯＮＥ」および「ＰＬＡＹＥＲ−ＳＭＳ−ＳＥＮＤ」は、それぞれ、電話をかけ、ＳＭＳを送信することができるアプリケーション３０のモジュールに対応する。アプリケーション「ＰＬＡＹＥＲ−Ｅ−ＭＡＩＬ−ＳＥＮＤ」は、アプリケーション３２に対応する。アプリケーション「ＰＬＡＹＥＲ−ＷＥＢ」は、アプリケーション３４に対応する。アプリケーション「ＰＬＡＹＥＲ−ＲＳＳ」は、ＲＳＳフィードに加入し、それを読み出すために使用されるアプリケーション３４の特定のモジュールに対応する。アプリケーション「ＰＬＡＹＥＲ−ＭＵＳＩＣ」、「ＰＬＡＹＥＲ−ＰＩＣＴＵＲＥ」および「ＰＬＡＹＥＲ−ＶＩＤＥＯ」は、アプリケーション３６のそれぞれのモジュールに対応する。

各アクセス経路はまた、ＡＤＤＲＥＳＳ−ＰＬＡＹＥＲ−ＳＴＡＴＵＳフィールドに関連づけられる。このフィールドのコンテンツは、実行可能なファイルへのアクセス経路とアドレスに対応するアクセス経路とを区別することを可能にする。例えば、このアクセス経路は、アクセス経路が実行可能なファイルへのアクセス経路である場合はデータ「Ｙ」を備え、そうでない場合は値「Ｎ」を備える。

アクセス経路が実行可能なファイルへのアクセス経路であるときはいつでも、２つの追加のフィールド、ＡＤＤＲＥＳＳ−ＰＬＡＹＥＲ−ＤＶＩＣＥおよびＡＤＤＲＥＳＳ−ＰＬＡＹＥＲ−ＳＹＮＴＡＸが完成されなければならない。ＡＤＤＲＥＳＳ−ＰＬＡＹＥＲ−ＤＥＶＩＣＥフィールドは、実行可能なファイルがそこで実行されることが可能であるオペレーティングシステム（１つまたは複数）を示す。

ＡＤＤＲＥＳＳ−ＰＬＡＹＥＲ−ＳＹＮＴＡＸフィールドは、アプリケーションが実行されるときはいつでも、そのアプリケーションに送信されなければならない１つまたは複数のパラメータのフォーマットを記述する。通常、問題のパラメータ（１つまたは複数）は、カードのＡＤＤＲＥＳＳ−ＶＡＬＵＥフィールドの中に含まれる。

ＡＤＤＲＥＳＳセクションは、１つまたは複数のアクセス経路の記述を含む。ＡＤＤＲＥＳＳセクションが複数のアクセス経路の記述を含む場合は、ＷＣＡＲＤ−ＤＯＭＡＩＮ領域は、モデル４０をインスタンス化することにより作成されたカードがユーザによって選択されたときにどのアクセス経路をデフォルトで使用するべきかを定義することを可能にする。ここで、そのＷＣＡＲＤ−ＤＯＭＡＩＮフィールドのコンテンツは、例えば、リスト４８から選択される。簡単にするために、ここでは、このリスト４８は、カードが人のアドレスを記述していることを示すことを可能にする「ＰＥＲＳＯＮ」値を追加で備えること以外は、リスト４６と同一である。ここで、値「ＰＥＲＳＯＮ」は、この人と連絡するために使用するべきデフォルト・アプリケーションは「ＰＬＡＹＥＲ−ＰＨＯＮＥ」であることを示す。

ＴＡＧセクションは、モデル４０がインスタンス化された場合１つまたは複数のタグを定義するために使用される。例えば、これらのタグは、１つまたは複数の作成されたカードを探索するための基準として役立つことを意図される。

ここで、各タグは以下のフィールドを使用して定義される。
−定義されたタグ・タイプを示すＴＡＧ−ＴＹＰＥフィールド、
−タグの名前を含むことを意図されたＴＡＧ−ＮＡＭＥフィールド、および
−タグの値を含むことを意図されたＴＡＧ−ＶＡＬＵＥフィールド。

ここで、モデル４０は、ＴＡＧ−ＴＹＰＥフィールドのコンテンツが予め決められたリストから選択されることを必要とするように設計される。例えば、この予め決められたリストは、以下の３つの値、「ＤＯＭＡＩＮ」、「ＳＹＳＴＥＭ」、および「ＵＳＥＲ」を含む。ＴＡＧ−ＴＹＰＥフィールドの値が「ＤＯＭＡＩＮ」であるときはいつでも、ＴＡＧ−ＮＡＭＥフィールドの値はリスト４２からのみ選択されることが可能である。ここで、リスト４２は、ＷＣＡＲＤ−ＤＯＭＡＩＮフィールドの中に含まれている値に基づいてＴＡＧ−ＮＡＭＥフィールドのために可能な値を関連づける。例えば、ＷＣＡＲＤ−ＤＯＭＡＩＮフィールドの値が「ＰＥＲＳＯＮ」である場合は、ＴＡＧ−ＮＡＭＥフィールドの値は、以下のリスト、｛「ＬＡＳＴ ＮＡＭＥ」、「ＦＩＲＳＴ ＮＡＭＥ」、「ＤＡＴＥ ＯＦ ＢＩＲＴＨ」など｝から選択されなければならない。

ＷＣＡＲＤ−ＤＯＭＡＩＮフィールドが値「ＦＩＬＥ−ＭＵＳＩＣ」である場合は、ＴＡＧ−ＮＡＭＥフィールドのコンテンツは、以下のリスト、｛「ＴＹＰＥ ＯＦ ＥＮＣＯＤＩＮＧ」、「ＴＹＰＥ ＯＦ ＦＩＬＥ」など｝から選択されなければならない。

ＴＡＧ−ＴＹＰＥフィールドのコンテンツが「ＳＹＳＴＥＭ」である場合は、それは名前および値がリソース管理装置によって自動的に決定されるタグである。例えば、それは、作成されたカードのコンテンツの直近の改訂日がいつであったかを示すためのタグでよい。

最後に、ＴＡＧ−ＴＹＰＥフィールドのコンテンツが「ＵＳＥＲ」である場合は、ＴＡＧ−ＮＡＭＥフィールドおよびＴＡＧ−ＶＡＬＵＥフィールドのコンテンツは、カードがモデル４０のインスタンス化によって作成している場合は、ユーザによって自由に選択されてよい。

したがって、カードモデル４０は、カードがそのモデルをインスタンス化することにより作成される場合は、いくつかのフィールドの取得を必要とする。

図３は、モデル４０をインスタンス化することにより作成されたカード７０から７３の４つの例を示す。カード７０は、その名前が「ＡＴＴ」である会社を記述する。カード７０の識別子は「ＷＣＡＲＤ１」である。カード７０は、ＡＤＤＲＥＳＳセクションを有しない。他方、ＷＣＡＲＤ−ＤＯＭＡＩＮフィールドには、値「ＰＥＲＳＯＮ」が書き込まれている。カード７０は、会社ＡＴＴの郵便の宛先を定義するために使用されるタグ７６を備える。図３に示されている特定の状況では、「ＤＯＭＡＩＮ」タイプのタグは、その会社の郵便の宛先を定義するために使用されている。

カード７１はピクチャを記述する。このカードは、ＷＣＡＲＤ２識別子および「ＡＴＴロゴ」名、ならびに表示されるべきピクチャを含むファイルへのアクセス経路を備える。アクセス経路は、ＡＤＤＲＥＳＳ−ＶＡＬＵＥフィールドの中に含まれる。このアクセス経路は、ＡＤＤＲＥＳＳ−ＤＯＭＡＩＮ−ＮＡＭＥフィールドおよびＡＤＤＲＥＳＳ−ＳＥＲＶＩＣＥ−ＬＩＳＴフィールドの値によって定義された参照領域に関連づけられる。ここで、この参照領域は、そのピクチャを表示するために実行されるべきアプリケーションが「ＰＬＡＹＥＲ−ＰＩＣＴＵＲＥ」アプリケーションであることを示す。

カード７２は、サーバ１２などのリモート・サーバ上に保存されているオーディオ・ファイルを記述する。ここで、このカードは識別子「ＷＣＡＲＤ３」および名前「ＲＩＮＧ−ＭＵＳＩＣ」を有する。このカードはまた、サーバ１２上のオーディオ・ファイルへのアクセス経路ならびに参照領域を含む。ここで、参照領域は、このオーディオ・ファイルを聴くために実行されるべきアプリケーションがアプリケーション「ＰＬＡＹＥＲ−ＭＵＳＩＣ」であることを指定する。

さらに、ユーザは、その名前が「クラス」であり、その値が「Ｃ２」であるタグを自由に定義している。このタグは、ある意味で、ユーザがタグ７２を容易に見つけることができるようにすることを意図されたユーザによる注釈である。

タグ７３は、「トム」という名前の人を記述する。何人かの人々が電話またはＥメールによってコンタクトされることが可能である。したがって、カード７３は、電話番号を含む第１のアクセス経路、およびその人のＥメールアドレスを含む第２のアクセス経路を含む。これらのアクセス経路のそれぞれは、その人にコンタクトするために、電話またはＥメールのいずれかによって、どのアプリケーションが実行されるべきかを指定する参照領域に関連づけられる。より具体的には、アクセス経路が電話番号を含むときはいつでも、参照領域は、実行されるべきアプリケーションが「ＰＬＡＹＥＲ−ＰＨＯＮＥ」および「ＰＬＡＹＥＲ−ＳＭＳ−ＳＥＮＤ」であることを指定する。ユーザが自分の電話番号を使用することによりその人にコンタクトしようと努めているときに２つのアプリケーションが実行されることが可能であると仮定すると、自分の電話番号を使用してこの人にコンタクトするために実行されることが可能であるこれらの２つのアプリケーションの間から選択するようにユーザを促す画面が表示される。

Ｅメールアドレスでは、参照領域は、実行されるべきアプリケーションが「ＰＬＡＹＥＲ−Ｅ−ＭＡＩＬ−ＳＥＮＤ」であることを指定する。

最後に、カード７３はまた、５つのタグを備える。これらのタグの２つは、その人の姓および郵便の宛先を定義するために使用される。郵便の宛先を定義するタグの値はカード７０にある「ＷＣＡＲＤ１」識別子であることに留意されたい。したがって、この特定の状況では、その人の郵便の宛先は別のカードへの参照によって定義される。この状況では、その人に関する情報が表示されると、その人のアドレスはカード７０のコンテンツから取得される。

その他の定義されるタグは、ユーザによって自由に定義されるタグである。ここで、ユーザは、その名前が「ロゴ」であり、カード７１の中に含まれているロゴの記述がカード７３の中で繰り返される必要がないように、その値がカード７１への参照を備えるタグを定義している。

別のタグは、名前「ＲＩＮＧ」を担持し、その値は、カード７２の中にすでに含まれているオーディオ・ファイルのフル記述をカード７３に組み込む必要がないように、タグ７２への参照を備える。

最後に、ユーザによって定義された最後のタグは、タグ７２の中ですでに使用されたものと同一の名前を意味する名前「クラス」を担持する。さらに、そのタグの値も、タグ７２の中のように「Ｃ２」である。したがって、ユーザが、その名前が「クラス」であり、その値が「Ｃ２」であるタグを含むカードを探索する場合は、ユーザは少なくともタグ７２および７３を見つける。したがって、ユーザは、まったく異なるタイプのリソースを記述するカードを選択し管理することができる。

図４は、モデル４０をインスタンス化することにより作成されたカード８０の一例を示す。このカード８０は、ＡＤＤＲＥＳＳ−ＶＡＬＵＥフィールドの中に含まれているアクセス経路を使用してメモリの中に配置されることが可能である実行可能なアプリケーションを記述する。この状況では、参照領域は、それが実行可能なファイルであることを示す。その目的のために、ＡＤＤＲＥＳＳ−ＤＯＭＡＩＮ−ＮＡＭＥフィールドは、値「ＦＩＬＥ−ＡＰＰＬＩＣＡＴＩＯＮ」を含む。さらに、ＡＤＤＲＥＳＳ−ＰＬＡＹＥＲ−ＳＴＡＴＵＴフィールドの値は、「Ｙ」に等しい。ここで、ＡＤＤＲＥＳＳ−ＰＬＡＹＥＲ−ＤＥＶＩＣＥフィールドは、このアプリケーションがそこで実行されなければならないオペレーティングシステムは、「ＷｉｎｄｏｗｓーＸＰ」（登録商標）オペレーティングシステムであり、パラメータのために特定のシンタックスは必要とされないことを示す。

ここでは、このカードの名前は「ＰＬＡＹＥＲ−ＰＨＯＮＥ」である。したがって、このカードは、カードのアクセス経路が電話番号を含む場合に実行されるべきアプリケーション「ＰＬＡＹＥＲ−ＰＨＯＮＥ」を記述する。

一例として、ユーザによって自由に定義されたタグは、カード８０のコンテンツに付加されている。このタグは、名前「クラス」を担持し、値「Ｃ３」を有する。

次に、システム２のオペレーションが、図５の方法に関してさらに詳細に説明される。

最初に、ステップ９０の間に、モデル４０は、カードを管理するために必要とされる様々なアプリケーションおよび情報と共にメモリ２２の中に保存される。次に、ステップ９２の間に、ユーザはモデル４０をインスタンス化することによりカードを作成する。各カードが作成されると、モデル４０は、ユーザによって入力されなければならない情報および情報のフォーマットを定義する。

複数のカードが作成された後は、ステップ９４の間に、ユーザはそれらのカードの１つを選択することができる。人にコンタクトする、または１つの情報にアクセスするためのアドレスを記述しているカードの選択に応答して、参照領域によって指定されたアプリケーションが実行される。ＡＤＤＲＥＳＳ−ＶＡＬＵＥフィールドのコンテンツは、コンタクトされるべき人への通話またはＳＭＳメッセージの送信の実行を自動的にトリガするために、あるいはアクセスされるべき情報の提示をトリガするために、その特定のアプリケーションにパラメータとして送信される。選択されたカードが実行可能なファイルを記述している場合は、この実行可能なファイルの実行は、そのカードの選択に応答して、自動的にトリガされる。

選択するカードの作成のステップと平行して、ユーザは、例えば、以下のステップを進めることができる。
−カードを編集および／または削除するステップ９６、および
−１つまたは複数のカードを探索するステップ９８。

ステップ９８の間に、カードは、いくつかのタグの名前および／または値などユーザによって指定された基準を使用して探索される。

したがって、モデル４０のおかげで、単一のアプリケーションを使用していかなるリソースをも管理することが可能であることが理解される。

他の多くの実施形態が可能である。例えば、端末４は、携帯電話でも、またはＰＤＡ（携帯情報端末）もしくは他の任意の通信端末などのパーソナルアシスタントでもよい。

モデル４０を使用して記述されることが可能であるリソースは、前述の説明で提供された諸例に限定されない。例えば、ビデオ・ファイル、文書、または他のファイルも、モデル４０をインスタンス化することにより取得されるカードによって記述されることが可能である。

同様に、様々なリスト４２、４６、および４８は、所望に応じて完成または変更されることが可能である。

Claims (9)

1. リソース管理方法であって、これらのリソースは、電子メモリの中に記憶されている実行可能なファイル、あるいはコンピュータ・アプリケーションが人にコンタクトする、または１つの情報にアクセスすることができるようにするアドレスである方法において、
   −リソースの記述を含むことを意図されたカードのインスタンス化可能なモデルを電子計算機のメモリの中に保存するステップ（９０）であって、前記カードモデルは、新しいカードを作成するためにインスタンス化された場合、
   ・すでに作成されている全てのカードのセットの中からこのカードを識別するために使用されるカード識別子、
   ・前記リソースがアドレスである場合はアドレスを含み、前記リソースが実行可能なファイルである場合はアクセス経路を含む少なくとも１つのアクセス経路（ＡＤＤＲＥＳＳ−ＶＡＬＵＥ）、および
   ・各アクセス経路のための参照領域（６０）であって、前記リソースがアドレスである場合は、前記アドレスに対応する人にコンタクトする、または前記アドレスに対応する情報にアクセスするために前記参照領域によって指定されることが可能な複数のアプリケーションの中からどのコンピュータ・アプリケーションを実行するべきかを指定する参照領域（６０）
   の取得を必要とする、
   ステップ（９０）を含むことを特徴とする方法。
2. 前記参照領域（６０）は、前記リソースが実行可能なファイルである場合は、前記記述されたリソースは前記アクセス経路によって示された位置に配置された実行可能なファイルであることを指定する、請求項１に記載の方法。
3. それぞれ第１のアドレスおよび第２のアドレスを記述するために前記カードモデルをインスタンス化することにより第１の新しいカードおよび第２の新しいカードを作成するステップ（９２）であって、これらの第１のアドレスおよび第２のアドレスの前記それぞれの参照領域は、それぞれ第１のコンピュータ・アプリケーションおよび第２のコンピュータ・アプリケーションを指定し、前記第１のコンピュータ・アプリケーションは、前記第２のアドレスに対応する人にコンタクトすることも、または情報にアクセスすることもできない、ステップ（９２）を備える請求項１または２に記載の方法。
4. 前記インスタンス化可能なモデルはまた、新しいカードを作成するためにインスタンス化された場合、少なくとも１つのタグ（ＴＡＧ）の名前および値を自由に定義することを可能にする、請求項１乃至３のいずれか１項に記載の方法。
5. 前記インスタンス化可能なモデルはまた、新しいカードを作成するためにインスタンス化された場合、前記作成されたカードがユーザに提示されたときはいつでも別のカードのコンテンツを前記作成されたカードに参照により組み込むために、前記作成されたカードから前記別のカードへのリンクを含むことを意図されたフィールドを作成することを可能にする、請求項１乃至４のいずれか１項に記載の方法。
6. 前記インスタンス化可能なモデルはまた、新しいカードを作成するためにインスタンス化された場合、前記作成されたカードが複数の参照領域を含むときはいつでもデフォルト参照領域（ＷＣＡＲＤ−ＤＯＭＡＩＮ）を定義することを可能にし、前記デフォルト参照領域は、ユーザによるそのカードの選択に応答してデフォルトで実行されるべき前記コンピュータ・アプリケーションを指定する、請求項１乃至５のいずれか１項に記載の方法。
7. 新しいカードが前記モデルの前記インスタンス化によって作成された場合、前記参照領域は、電話をかけるためのアプリケーション、Ｅメールを送信するためのアプリケーション、オーディオ・ファイルまたはビデオ・ファイルを再生するためのアプリケーション、ＨＴＭＬページを表示するためのアプリケーション、およびＲＳＳフィードを表示するためのアプリケーションを備えるグループから選択された実行するべきコンピュータ・アプリケーションを指定することができる、請求項１乃至６のいずれか１項に記載の方法。
8. 電子計算機によって実行された場合、請求項１乃至７のいずれか１項に記載の管理方法を実行するための命令を備えることを特徴とする情報記録媒体（２２）。
9. リソース管理装置であって、これらのリソースは、電子メモリの中に記憶されている実行可能なファイル、あるいはコンピュータ・アプリケーションが人にコンタクトする、または１つの情報にアクセスすることができるようにするアドレスであるリソース管理装置において、リソースの記述を含むことを意図されたカードのインスタンス化可能なモデルを含む電子メモリ（２２）を備え、このカードモデルは、新しいカードを作成するためにインスタンス化された場合、
   ・すでに作成されている全てのカードのセットの中からこのカードを識別するために使用されるカード識別子、
   ・前記リソースがアドレスである場合はアドレスを含み、前記リソースが実行可能なファイルである場合はアクセス経路を含む少なくとも１つのアクセス経路（ＡＤＤＲＥＳＳ−ＶＡＬＵＥ）、および
   ・各アクセス経路のための参照領域（６０）であって、前記リソースがアドレスである場合は、前記アドレスに対応する人にコンタクトするために、または前記アドレスに対応する前記情報にアクセスするために前記参照領域によって指定されることが可能な複数のアプリケーションからどのコンピュータ・アプリケーションを実行するべきかを指定する参照領域（６０）
   の取得を必要とすることを特徴とする、リソース管理装置。

Images