JP2020521209A - プラグイン関数プラットフォームおよび方法 - Google Patents

Abstract

【解決手段】サーバが仮想マシン内で実行し、クライアントデバイスからのユーザインターフェースコマンドに応答する軽量プラグイン関数の実行を容易にする。関数は、ユーザインターフェースを実装し得なくてもさらなる処理でコマンドを拡張し、リアルタイムでデータを生成し、任意のプログラミング言語で書かれうる任意のデータレポジトリまたはデータリソースにアクセスし、無限のストレージを有すると認識する。クライアントデバイスは、カスタムソフトウェアを有する必要がなく、標準的なアプリケーションを用いて、従来のファイル−フォルダユーザインターフェースを実装する。クライアントデバイス上に表示されるフォルダおよびファイルのコンテンツは、ユーザによって具体的に要求されるまで存在する必要がない。プラグイン関数は、独自のルートファイルシステムを有するが、ネットワークネームスペースを共有してよい。データが、フォルダ名またはマイクロウェブサーバを用いて関数に入力されてよい。２つの関数が、リモートコンピュータに接続されたデータベースを共有する。関数がより多くのスペースを必要とする時に、ローカルキャッシュに格納されたファイルがトランスペアレントにリモートストレージへ移動される。【選択図】図２

Description

本願は、２０１７年５月５日に出願された米国仮特許出願第６２／５０１，８２２号および２０１７年８月１１日に出願された米国特許出願第１５／６７５，１９３号の優先権を主張し、これらの出願は、その全体が参照によって本明細書に組み込まれる。

本発明は、一般に、エンドユーザまたはその他のプログラムのためのデータを操作するための関数の開発および実行に関する。特に、本発明は、ユーザインターフェースを実装しない場合でも従来のユーザインターフェースを拡張し、リアルタイムでデータを生成し、無限のストレージを有すると認識する軽量関数に関する。

ディスク上の従来のファイルシステム、オブジェクトストア、および、構造化されたデータベース、ならびに、ウェブサービスのようなその他のデータソースなど、幅広いタイプのデータリポジトリが、現在、利用されている。これらのデータリポジトリは、企業のデータセンタ内、クラウドストレージ内、モバイルデバイス上、企業内のコンピュータ上、レガシーデータベース内、ウェアラブルデバイス上など、基本的に、そこからデータを引き出すことができる任意の集中型または分散型の格納位置上に、配置されうる。さらに、これらのリポジトリの各々は、独自のウェブサイトと、上部に重ねられたアプリケーションとを有しうる。データソースが、文書変換など何らかの処理の結果であってもよい。さらに、ユーザが、処理または格納のために自身のデータをもたらしてもよい。

さらに、利用される多くのデータ型、そのデータへアクセスするための異なるチャネル、異なるユーザデバイス、異なるネットワーク接続、そして、まだ開発途上のインターネット・オブ・シングス全体に言及するまでもなく、ウェブ、クライアントサーバ、モバイルウェブなど、利用される多くの技術が存在する。また、ＥＲＭ、ＣＲＰなどのアプリケーションによって引き起こされる、正確なデータを正しいフォーマットでユーザに提供する際の課題もある（古いか、または、高価すぎて定期的に先行して準備できない複製または同期データが用いられる場合には問題になる）。ビッグデータも、莫大な量のデータと、人間が利用するためにその情報をユーザに提供する難しさとから、課題を持ち込む。

要するに、世界は、ますます多くなるデータ、データが格納される場所の増加、データにアクセスする方法の増加、および、データを提示する方法の増加に溺れている。多くの企業は、データをそれらのビジネスの実践でアクセス可能にするために、そのデータを転送および複製しようと試みるが、一般に、必要とされうるユーザインターフェースの数を特に考慮すると、これらの努力のレベルは上がりえない。結果として、所有の総コストは高まっており、企業は、より大量なデータだけではなく、各々が独自のユーザインターフェースを必要とするより多様かつ多数のレポジトリをも扱うために、単に現在の技術を使い続ける余裕がないか、または、使い続けることができない。実際、バックエンドデータをユーザに提示する所与のカスタムアプリケーションについて、ユーザインターフェースおよびユーザ体験がプロジェクト全体の９０％以上に至るまでのコストを掛けうると推定されており、エンドユーザが日常的に多数の異なるユーザインターフェースを快適に習得して利用することができないのはいうまでもない。

したがって、最小のコストおよび短い開発時間で、１または複数のソースまたはそれらのマッシュアップからのバックエンドエータへエンドユーザが簡単かつ直感的にアクセスできるようにする新たなプラットフォームおよび方法が望まれている。

以上を達成するために、本発明の目的に従って、様々な格納位置またはその他のＡＰＩエンドポイントに対してデータのリトリーブならびにデータの格納または送信を実行でき、それら自身は必ずしもユーザインターフェースを実装する必要がない軽量プラグイン関数をホストするプラットフォームが開示されている。

プラットフォームは、ファイル（コンテンツ）およびフォルダの生成がサーバ側のすぐに開発されたプラグイン関数によって駆動される間に、消費者（エンドユーザ）側で利用されるファイルシステムの周知の階層的なファイル／フォルダ提示など、既存のユーザインターフェースを利用する。したがって、プログラム可能なファイルサーバを用いたファイルシステムの仮想化の一形態が現れる。

本発明は、上述の不利点を様々な方法で克服する。一例として、前もってデータのダウンロード、格納、同期、計算、または、結合を先制的に行うのではなく、特定の用途のためにユーザによって必要とされるデータが、単に、その元々のデータリポジトリ内で存在する場所に残され、リアルタイムで必要になった時にのみリトリーブまたは生成される。ユーザによって具体的に要求された時にのみ、単純な軽量プラグイン関数を用いて、そのデータをリトリーブする、書き込む、処理する、または、他のデータと結合する。かかるプラグイン関数は、管理者機能または管理機能（認証および許可、リソースの配分、メトリクス、データストレージ管理、ネットワーク通信、など）を実行する必要がない。プラグイン関数は、ユーザアプリケーションにとって目下必要とされる特定の１または複数のデータリポジトリからのデータの読み込みまたはデータの書き込みに焦点を絞る。プラグイン関数は、適切な結果をユーザに提示するために、そのデータを処理するか、または、他のデータと結合してもよい。プラグイン関数は、任意のデータリポジトリまたはデータソースにアクセスでき、開発者が望む任意の方法でデータを処理および結合することができる。

さらに、コストを削減すると共に、迅速な開発および実装を可能にするために、プラグイン関数がユーザインターフェースを実装することを求めるのではなく、標準的なフォーマットでデータをユーザに提示する。具体的な一実施形態において、このフォーマットは、なじみのある階層ファイルシステムである。標準的なウェブベースプロトコルを用いてバックエンドデータをフォルダおよびファイルとして単に表すことによって、多くのビジネス利用のケースで役に立つことがわかる。換言すれば、ユーザは、自分の慣れたよく知っているフォルダおよびファイルを見る。これらのフォルダおよびファイルは、プラグインが実行する時に、オンザフライでリアルタイムに作成されうる。ユーザは、ファイルとして存在せず、コンピュータサーバのディスク上のどこにもディレクトリが存在することがなく、むしろ、必要に応じて、オンザフライでリアルタイムに、任意のアクセス可能なデータリポジトリまたはデータソースから計算される構造化された情報の階層ファイルシステムを見る。

本発明は、幅広いタイプのファイル（医用画像、写真、ビデオ、インボイス、財務記録、集計表、プレゼンテーション、データベース記録、デバイス出力、ビッグデータ、人工知能、など）を扱うことに適用できる。また、本発明は、金融、保険、工業、政治、石油およびガス、情報技術、メディアおよびエンターテイメント、エンジニアリング、ＣＡＤ／ＣＡＭなどの分野の幅広いビジネス利用のケースに適用できる。

第１実施形態において、方法およびシステムは、リモートコンピュータのプラグイン関数を用いて、クライアントコンピュータデバイス上にデータを読み込む。関数が実行して、クライアントデバイスのユーザインターフェースの階層内に表示されるコンテンツのリストを返すが、コンテンツは、どのストレージデバイスにもまだ存在しない。

第２実施形態において、方法およびシステムは、リモートコンピュータのプラグイン関数を用いて、クライアントコンピュータデバイス上にデータを読み込む。クライアントデバイスはファイルを選択し、関数が実行して、ファイルを作成し、クライアントデバイスで表示されるファイルのコンテンツを返す。

第３実施形態において、方法およびシステムは、リモートコンピュータのプラグイン関数を用いて、クライアントコンピュータデバイスからフォルダにファイルを書き込む。関数が実行し、ファイルをストレージに格納し、クライアントデバイス上のフォルダに表示するファイル名を返し、関数は、ユーザインターフェースを全く実装しない。

第４実施形態において、方法およびシステムは、コンピュータサーバ上で２つの関数を実行し、各関数は独自のルートファイルシステムを有し、２つの関数は同じネームスペースを共有する。各関数のための実行可能コードの層がフェッチされて解凍され、各関数が実行され、各関数は、仮想マシンの同じネットワークを用いて、リモート企業コンピュータからデータをリトリーブする。

第５実施形態において、方法およびシステムは、リモートユーザコンピュータデバイス上でユーザインターフェースを全く実行しないプラグイン関数を実行する。プラグイン関数は、サーバコンピュータ上のサーバプロセスによって呼び出され、その関数が実行する。関数は、ファイルを作成し、そのファイルを表示に向けてユーザコンピュータデバイスに送信する。

第６実施形態において、方法およびシステムは、フォルダ名を有する新規フォルダを作成するためのコマンドをユーザから最初に受信することによって、クライアントコンピュータデバイス上のデータを読み込む。新規フォルダを作成するため、および、そのフォルダをコンピュータデバイス上に表示するために、プラグイン関数が実行し、次いで、フォルダ名を入力として用いて、結果を生成する。

第７実施形態において、方法およびシステムは、フォルダ名を有する新規フォルダを作成するためのコマンドをユーザから最初に受信することによって、クライアントコンピュータデバイスからデータを書き出す。新規フォルダを作成するため、および、そのフォルダをコンピュータデバイス上に表示するために、プラグイン関数が実行する。関数が、コンピュータデバイス上でユーザによってフォルダに追加されたデジタルオブジェクトも受信した場合、そのデジタルオブジェクトを処理して、結果を生成する。

第８実施形態において、方法およびシステムは、クライアントコンピュータデバイスからメタデータを入力する。まず、プラグイン関数が、リモートコンピュータ上でデーモンモードで実行し、フォルダアイコンを含むユーザインターフェースをクライアントデバイス上に表示する。関数は、コンピュータデバイス上に表示するウェブページを送信し、ユーザによって入力されたメタデータ値を受信する。関数は、メタデータ値を用いて結果を生成するように実行する。

第９実施形態において、方法およびシステムは、クライアントコンピュータデバイスからメタデータを入力する。まず、リモートコンピュータが、フォルダ名を備えた新規フォルダを作成するためのコマンドをクライアントデバイスから受信する。プラグイン関数が実行し、そのフォルダ名を備えたフォルダを作成して、クライアントデバイス上で表示するためにそのフォルダを返す。メタデータ値がフォルダ名に割り当てられ、関数は、そのメタデータ値を用いて結果を生成するように実行する。

第１０実施形態において、方法およびシステムは、クライアントデバイスが２つのプラグイン関数を介してリモートデータベースにアクセスすることを可能にする。第１関数は、データベースとの接続を開く。クライアントデバイスは、第２関数を用いて、データベースへのアクセスを要求する。第２関数は、第１関数によって開かれた接続を用いてデータベースにアクセスし、クライアントデバイスに応答する。

第１１実施形態において、方法およびシステムは、クライアントデバイスからのユーザインターフェースコマンドに含まれないさらなるステップを実施するために、コンピュータサーバ上でプラグイン関数を実行する。コンピュータサーバは、パス名およびユーザインターフェースコマンドをクライアントデバイスから受信する。プラグイン関数が実行して、コマンドを実行すると共にさらなるステップを実行し、表示するために結果をクライアントデバイスに返す。

第１２実施形態において、方法およびシステムは、ファイルをプラグイン関数からローカルディスクに書き込む。一意ファイル名が、通常のフォルダ名から作成され、ディスク上でファイルを識別するために一意ファイル名を用いて、ファイルが、ローカルディスク上のファイルシステムのユーザフォルダに書き込まれる。

第１３実施形態において、方法およびシステムは、ローカルディスク上で利用可能なストレージスペースを増やすか否かを最初に決定することによって、ローカルディスクのスペースを管理する。増やす場合、ローカルディスクから削除されるファイルが選択され、そのファイルはリモートストレージにコピーされ、そのファイルによって利用されていたローカルディスク上のスペースが解放される。

本発明は、そのさらなる利点と共に、添付の図面に関連して行う以下の説明を参照することによって最も良く理解できる。

格納されたデータにアクセスするためにアプリケーションによって用いられる従来技術のシステムの一例を示す図。

図１に示した従来のシステムの不利点を克服する新規システムを示す図。

システムの１つの可能な実施例のよりハイレベルな図。

サーバのソフトウェアモジュールをさらに詳細に示すブロック図。

サーバの内の１サーバ内のテナント−シェア−プラグインオブジェクト階層のブロック図。

プラグイン関数を含む視覚化階層のブロック図。

プラグイン関数のためのルートファイルシステムがどのように作成されうるのかを示す図。

プラグイン関数がサーバ１５０上にどのように配備されるのかを記載するフローチャート。

プラグイン関数がどのようにデーモンモードで開始されるのかを記載するフローチャート。

データを読み出してユーザに表示するためにプラグイン関数が利用される一実施形態を記載するフローチャート。 データを読み出してユーザに表示するためにプラグイン関数が利用される一実施形態を記載するフローチャート。 データを読み出してユーザに表示するためにプラグイン関数が利用される一実施形態を記載するフローチャート。

エンドユーザデバイスが携帯電話である一実施形態を示す図。

スクリーン上の接続可能なサーバのリストを示す図。

ユーザに表示される”Ｅｓｏｐｔｒａ Ｄｅｍｏ”内のハイレベルフォルダを示す図。

３つの異なるフォルダを含む応答を示す図。

ユーザがアイコンをタップしたことに応答したデバイスのディスプレイを示す図。

ユーザがファイルをタップしたことに応答したデバイスのディスプレイを示す図。

データをアップロードした後にそのデータを処理するためにプラグイン関数が利用される一実施形態を記載するフローチャート。 データをアップロードした後にそのデータを処理するためにプラグイン関数が利用される一実施形態を記載するフローチャート。 データをアップロードした後にそのデータを処理するためにプラグイン関数が利用される一実施形態を記載するフローチャート。

ハイレベルフォルダの表示後、かつ、ユーザがフォルダの内の１つを選択する前のタブレットコンピュータを示す図。

ユーザがアイコンをタップし、プラグイン関数が実行されて、そのフォルダのコンテンツを返した後のタブレットを示す図。

工程８０６においてユーザがフォルダにアップロードするファイルをどのように選択するのかを示す図。

リフレッシュ要求後のタブレットを示しており、現在の”Ｗｏｒｄｓ”フォルダが、プラグイン関数の作成した新規フォルダ”Ｗｏｒｋｓ Ｓｈａｋｅｓｐｅａｒｅ”を含むことを示す図。

工程８３６および８３８の後のデバイスのディスプレイを示す図。

ファイルの頻度の部分的なリストを示す図。

引数がフォルダの名称を介してプラグイン関数に渡される一実施形態を記載するフローチャート。

ユーザが利用可能な関数７６８、７７０、および、７７１を示す携帯電話７６０の図。

フォルダ”Ｐｈｏｔｏ”が選択された後にデバイス７６０がどのようになるのかを示しており、フォルダ９２０（１つ上のレベルに移行するために用いられる）および子フォルダ”Ｑｕｅｒｉｅｓ”９２２が表示されている様子を示す図。

現在デバイス７６０がどのように見えるか、すなわち、新規サブフォルダ”ｂｅｌ”９３２を表示する様子を示す図。

プラグイン関数にアクセスして、データを追加、リトリーブ、および、表示するために用いられる任意のエンドユーザコンピュータデバイス２４２〜２４６を示す図。

キャッシングサブシステムのブロック図。

キャッシングサブシステムモジュールを実装するために用いられるインメモリキャシュオブジェクトの表現を示す図。

バックサイドキャッシングアーキテクチャのブロック図。

プラグイン関数にとって利用可能なフォルダの象徴的に示すブロック図。

プラグイン関数がローカルディスクにデータを書き込む一実施形態を記載するフローチャート。

データがキャッシュからリモートオブジェクトストアに移動される一実施形態を記載するフローチャート。

本発明の実施形態の実施に適したコンピュータシステムを示す図。 本発明の実施形態の実施に適したコンピュータシステムを示す図。

発明の詳細な説明

図１は、格納されたデータにアクセスするためにアプリケーションによって用いられる従来技術のシステムの一例１０を示す。かかるシステムは、対応するサーバコンピュータ３０〜３４と通信する任意の数のクライアントコンピュータ２０〜２４を含む。データ格納技術の一例は、ファイルサーバおよびファイルシステムを用いる。サーバコンピュータ３２は、なじみのあるフォルダおよびファイルを含む階層ファイル構造５０が格納された１または複数の物理ディスク４２と通信する。ファイルシステム５２（通例、カーネル内で実行する）が、ＡＰＩ５４（ＰＯＳＩＸなど）からディスクに格納されたフォルダおよびファイルの要求へとＡＰＩ呼び出しを変換する。次いで、ファイルサーバソフトウェア５６が、ファイルシステムを、ローカルに実行するかまたはネットワーク上のクライアントコンピュータでリモートに実行するアプリケーションによって利用できるようにする。例えば、ＮＦＳまたはＳＭＢなどのネットワーク通信プロトコル６２（クライアントは図示せず）が、アプリケーション７０（ブラウザなど）が実行中であるクライアントコンピュータ２２と通信するために用いられてよい。最終的に、アプリケーションがサーバコンピュータ上で自身のＡＰＩ呼び出しを行っているかのように、ディスク４２上のファイル構造が、クライアントマシン上のアプリケーションにとって利用可能になる。

別の例では、より新しいネットワークプロトコル６３（ＷｅｂＤＡＶなど）が、クライアントとサーバコンピュータとの間の通信に用いられてもよい。この例では、ＷｅｂＤＡＶサーバ５８が、サーバコンピュータ上で実行し、クライアントコンピュータ上の対応するＷｅｂＤＡＶクライアント５９とネットワークを介してそのプロトコルを用いて通信する。この場合も、最終的に、クライアントコンピュータ上のアプリケーションにとって、ディスク４２上のファイルシステムおよび対応するファイル構造が利用できるようになる。例えば、ＮＦＳまたはＷｅｂＤＡＶを用いたクライアントコンピュータからの様々な呼び出し（ｇｅｔ、ｐｕｔなど）は、ディスク上のファイル構造５０を露出させる（ｅｘｐｏｓｅ）ために用いられ、不利点は、データがアプリケーション７０にとってそのフォーマットのディスク上でのみ利用可能であることである。

もちろん、上述のように、利用される多くの他のタイプのデータ格納技術が存在しうる。サーバコンピュータ３０と適切なネットワーク接続６０を介して通信するクライアントコンピュータ２０も図示されている。このサーバコンピュータは、各々が適切なＡＰＩ ７４を備えた任意の数の仮想マシン７６を実装し、ＵＵＩＤによって各々識別されるデジタルオブジェクトを格納するために用いられるオブジェクトストア７８を実装する１または複数のディスク４０（クライアントは図示せず）と通信してよい。同様に、クライアントコンピュータ２０上で実行する適切なアプリケーション７１が、ＡＰＩ ７４を用いて、ディスク上でオブジェクトストレージを露出させる。再び、ネットワーク接続６０上での様々な呼び出しは、ディスク上のオブジェクトストレージを露出させるために用いられ、アプリケーションは、特定のタイプのストレージに限定される。

別のデータ格納技術は、データベースを利用する。クライアントコンピュータ２４は、適切なネットワーク接続６４を介してサーバコンピュータ３４へ通信する。このサーバコンピュータは、１または複数のディスク４４上のデータベースファイル８０内に構造化データを格納するデータベースソフトウェア８２と通信するのに適切なＡＰＩ ８４を備える。クライアントコンピュータ２４上で実行するアプリケーション７２が、ＡＰＩ ８４を用いて、ディスク上の構造化データベースを露出させる。ネットワーク接続６４を介しての呼び出しは、そのデータベースファイルをクライアントコンピュータ上のアプリケーションに露出させる。再び、アプリケーションは、構造化データベース内のデータの格納およびリトリーブに限定される。

上述のように、クライアントコンピュータまたはその他のデバイス上で実行する任意のアプリケーションは、異なる格納位置からデータをリトリーブするまたは異なる格納位置にデータを書き込む必要がある場合に、様々な異なるデータ格納技術に対処しなければならない。さらに、アプリケーションプログラマは、認証および許可、リソースの配分（ＣＰＵタイム、ディスクストレージ、など）、および、とりわけユーザインターフェースに対処するためのソフトウェアコードを（アプリケーションに応じて）書くという責任も持ちうる。実際、所与のアプリケーションのためのユーザインターフェースの設計および実装には、アプリケーションの開発コスト全体の９０％を上回るコストが掛かりうると見積もられている。

これらの既存のシステムの１つの不利点は、レイアウト（階層）およびコンテンツ（ファイルデータ）が、アクセスに先立ち、前もって知られて作成されていなければならないファイルおよびフォルダ構造に依存していることである。典型的には、ファイルサーバが、この目的のために利用される。このサーバには、ファイル（実際のコンテンツ）およびフォルダ（実際のレイアウト）が投入されるため、ファイルおよびフォルダを前もって閲覧またはその他の利用に向けて準備するには、かかるファイルおよびフォルダの何らかの形態の同期または複製が必要になり、スケジューリング、リソース、および、コストの結果と共にプリエンプティブ（バッチ）処理を伴う。

クラウドまたはモバイルアプリケーションにおいて、および、ウェブアプリケーションにおいて、この問題は部分的に対処され、それにより、ＵＲＬの背後にあるコンテンツが動的に生成されうるが、このソリューションは、クライアントＵＩまたはウェブＵＩアプリケーションの作成を必要とする。そして、このアプリケーションは、人間のユーザによるアクセスに限定される。ファイルシステムで作業する方法をすでに知りうるアプリケーション（マシンユーザ）は、仮にあったとしても、かかるウェブＵＩインターフェースを容易に使うことができない。

カスタムクライアントアプリケーションが、既存の制限または不利点を克服するために開発されうる。これは頻繁に起こり、結果として、多くの高価なクライアントアプリケーションが書かれることになる。プログラマは、バックエンドリポジトリのストレージおよびフォーマットに加えて、システムのすべての側面を扱わなければならない。これは、セキュリティ、リソース管理、配備、宣伝などを含み、アプリケーションデータのみに限ったものではない。したがって、既存のソリューションの主な不利点は、複雑さ、コスト、および、製品化までの時間の内の１つであり、これが、多くの重要であるがいくぶん戦略的なプロジェクトが決して始まらない理由である。バックエンドで利用可能なデータとフロントエンドで消費可能なデータとの間のギャップは広い。

したがって、クライアントコンピュータ２２またはその他のデバイスのために書かれたカスタムアプリケーションは、開発および実装するには（時間およびコストの観点で）極度に高価でありうる。カスタムアプリケーションは、ネットワーク通信６２、６３、６６、６８を用いて（どのデータが必要とされるかに応じて）異なるデータ格納位置と通信するように書かれなければならないだけではなく、どのデバイスが利用されているか、アプリケーションおよびデータの性質、ならびに、ユーザのニーズに応じて、カスタムユーザインターフェースをユーザに提供するように書かれなければならない。さらに、上述のように、プログラマは、管理機能（認証、許可、リソースの配分など）を実装する必要もありうる。このすべては、異なる位置からのデータを必要とすると共にカスタムユーザインターフェースを必要としうる新しいアプリケーションの開発に費用および時間が掛かることを意味する。

カスタムサーバアプリケーションが、通常はウェブサーバまたはＲＥＳＴ ＡＰＩサーバの形態で、存在し開発されている。ＲＥＳＴ ＡＰＩサーバは、クライアントアプリケーションがＲＥＳＴ ＡＰＩを用いるようプログラムされた場合にのみ有用である。これは、現在、主に、サーバに由来しブラウザで実行するウェブアプリケーションによってなされる。ブラウザアプリケーションについて、通常は、クライアント上にインストールされる必要のあるアプリケーションソフトウェアはないが、ソリューションは、ブラウザ内での利用に制限される。

したがって、新しい技術には、エンドユーザに情報を提示するためにデータの読み書きをする必要がありうるアプリケーションをアプリケーションプログラマが開発することを容易、迅速、安価にすることが望まれている。我々の新規システムは、中間の問題を解決し、開発者には、障壁を劇的に下げるサーバ側からのデータアクセスのみを気にするようにさせる。これは、迅速であるがサーバ上で管理された方法で市場に投入するためのより適時かつ戦術的なソリューションを可能にする。

システムの概説
ネットワーク通信プロトコル６０〜６８は、ネットワークを介して標準ＨＴＴＰ呼び出し（ｇｅｔ、ｐｕｔなど）をファイルサーバへ送信しており、標準ＨＴＴＰ応答を受信していることがわかる。さらに、新規システムが、クライアントコンピュータとデータリポジトリとの間に挿入されてよく、これらのＨＴＴＰ呼び出しを傍受することで、明らかな利点を提供することがわかる。

図２は、図１に示した従来のシステムの不利点を克服する新規システム１００を示す。一例として、図１の領域９０に示したハードウェアおよびソフトウェアのすべてが、図２の領域１９０に示すより単純なハードウェアに置き換えられる。さらに、クライアントコンピュータまたはデバイスのいずれにも必要とされるまたはイストールされるカスタムソフトウェアがなく、ＷｅｂＤＡＶクライアントまたはインターネットブラウザなど、プレゼンテーション層を実装するための標準的なアプリケーションソフトウェアがあればよい。ユーザインターフェースは、周知の階層構造（すなわち、従来のフォルダおよびファイル）が用いられる点で固定である。そして、アプリケーション開発者は、認証、許可、リソースの配分などの管理者機能または管理機能に関心を持つ必要がない。重要なことには、企業側から見ると、格納位置４０〜４８（またはその他のデータリポジトリまたはデータソース）内のデータは、単にそこに「静止」したままでありうる。アプリケーションプログラミングを容易にするために、データを元々の格納位置から中央位置へ移動させる必要はない。もちろん、データの定期的なバックアップは行われてよいが、任意のアプリケーションプログラミングを容易にするために、データを移動させる必要はない。

クライアントコンピュータ２２は、（ほとんどのオペレーティングシステムに含まれる）ＷｅｂＤＡＶクライアント５９、プレゼンテーションアプリケーション１７２、および、レンダリングアプリケーション１７４を備える。有利なことに、ユーザインターフェースは固定であり、標準的なものである。プレゼンテーションアプリケーション１７２は、フォルダおよびファイルが提示または表示されるクライアントコンピュータで実行する任意の標準的なアプリケーションであってよい。例えば、アプリケーション１７２は、フォルダおよびファイルを表示する一般的なブラウザ（例えば、Ｅｘｐｌｏｒｅｒ、Ｆｉｒｅｆｏｘ、Ｓａｆａｒｉ）であってよい。あるいは、プラグイン関数がクライアントコンピュータ上にマウントされたドライブアイコンの中でフォルダとして出現する実施形態において、ＷｅｂＤＡＶクライアント５９が用いられてもよい。ｉＯＳまたはＡｎｄｒｏｉｄオペレーティングシステムを用いるモバイルデバイスにおいて、多くのサードパーティＷｅｂＤＡＶブラウザアプリケーションが利用可能である。さらに、ＲＥＳＴ ＡＰＩを用いてサーバ１５０と通信すると共にフォルダおよびファイルを表示するカスタムアプリケーションが書かれてもよいが、カスタムアプリケーションを書く必要はない。一般に、ＨＴＴＰベースプロトコルを用いる任意のアプリケーション１７２が適している。

レンダリングアプリケーション１７４は、データを表示できるクライアントコンピュータ上で実行する任意の標準的なアプリケーションであってよい。例えば、プラグイン関数が実行され、ユーザがプレゼンテーションアプリケーションを用いてフォルダ内のファイルを閲覧すると、レンダリングアプリケーションは、そのファイルのコンテンツを開いて閲覧するために用いられてよい。例として、アプリケーション（ＰＤＦリーダ、Ｖｉｚａｂｌｅ、または、Ｅｘｃｅｌなど）が用いられてよい。アプリケーションは、ファイルを開く前に開かれてもよいし、ファイルをダブルクリックすることで、アプリケーションを開かせてもよい。

図２には、仮想マシン１３６を実行しているサーバコンピュータ１３２が示されている。仮想マシン内では、クライアントコンピュータ２２上のＷｅｂＤＡＶクライアント５９と通信する際に利用するＷｅｂＤＡＶ ＡＰＩ １５２を備えたサーバソフトウェア１５０が実行している。もちろん、その他のネットワーク通信プロトコルが、クライアントコンピュータとサーバコンピュータとの間の通信に用いられてもよく、例えば、プロトコルがＮＦＳであり、クライアントコンピュータがＮＦＳクライアントを含む場合、サーバ１５０は、ＮＦＳファイルサーバのためのＡＰＩを備える。ＨＴＴＰベース通信プロトコルが用いられることが好ましい。具体的な一実施形態において、ＷｅｂＤＡＶ ＡＰＩ １５２は、必ずしもＷｅｂＤＡＶサーバではなく、対応するクライアント（この場合、ＷｅｂＤＡＶクライアント７０）にＷｅｂＤＡＶサーバとデータ通信していると信じさせるように設計されたＡＰＩである。後に詳しく説明するように、ＷｅｂＤＡＶ ＡＰＩ １５２は、下にあるデータリポジトリ４０〜４８すべてを単一のデータリポジトリだけではなくクライアントコンピュータに露出させる。

また、サーバ１５０内には、後にフローチャートに示す本明細書に記載の機能を実行する複数のソフトウェアモジュールが備えられる。一般に、サーバ１５０は、クライアントコンピュータとデータリポジトリとの間でデータをやり取りし、管理者機能および管理機能を提供し、図に示し後述するプラグイン関数を配備および呼び出し、プラグイン関数を実行できる最適環境を提供する。

任意の数のプラグイン関数１６０〜１６２が、仮想マシンにロードされ、サーバ１５０によって配備および呼び出されてよく、企業またはエンドユーザに必要とされる任意の機能（例えば、任意のデータリポジトリへのデータの書き込みまたは任意のデータリポジトリからのデータの書き出し、データの結合、検索機能の実行、など）を提供するために実行される。プラグイン関数は、サーバソフトウェア１５０と一緒にコンパイルされないという意味で「プラグイン」ソフトウェアであり、特定の機能を実行するために、後に「プラグイン」されるよう意図されている。サーバ１５０は、プラグイン関数の配備をサポートするために、単一のエンティティ（例えば、Ｅｓｏｐｔｒａ ＮＶ）によって提供されるよう意図されているが、各プラグイン関数は、任意の他のプラグイン関数とは異なる目的を有してよく、各々が、異なるエンティティによって書かれてよい。プラグイン関数は、サーバ１５０から呼び出されるが、サーバへはコンパイルされず、別個のプロセスである。

一般に、プラグイン関数は、リトリーブしたデータを操作して、任意の形態でそのデータをコンピュータデバイスのユーザに提供することで、ユーザのデバイス上の任意の標準的なレンダリングアプリケーションがそのデータを表示できるようにしてよい。例えば、エンドユーザがＶｉｚａｂｌｅアプリケーションを好んでおり、そのアプリケーションがエンドユーザデバイス上で利用可能であることがわかっている場合、プラグイン関数は、ＣＳＶフォーマット（Ｖｉｚａｂｌｅアプリケーションによって選好される１つのフォーマット）でエンドユーザのためのファイルを作成するようプログラムされる。

図に示すように、各プラグイン関数は、（適切なプロトコルを用いて）上述のデータレポジトリおよびデータソース４０〜４４（オブジェクトストア、ファイルサービス、ファイルサーバ、データベース、リモートウェブサービスなど）と通信してよい。プラグイン関数が、（関数１６０の場合のように）単一のレボジトリのみと通信することを選択してもよいし、関数が、（関数１６２の場合のように）任意の数のリポジトリと通信してもよい。プラグイン関数が、単に処理関数を実行してもよく、データリポジトリと通信しないことも可能であり、また、処理されるデータがユーザによって提供される（例えば、後述の「Ｐｈｏｔｏ］の例を参照）ことも可能である。実際、特定のタスクを実行するためにプラグイン関数がどの計算を実行すべきかを支持するのは、プラグイン関数の開発者である。また、開発者は、どのデータリポジトリにアクセスするか、および、それらのリポジトリにアクセスするためにどのプロトコルが用いられるのかを決定する。したがって、プラグイン関数は、１つの特定のタイプのデータリポジトリ（ファイルサーバなど）のみを用いて組み込まれることはない。実際に、プラグイン関数は、仮想マシン上で実行できる任意の適切なプログラミング言語（Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標、以下同じ）、Ｐｙｔｈｏｎ、ＪａｖａＳｃｒｉｐｔ（登録商標、以下同じ）、Ｇｏ、Ｒｕｓｔ、Ｂａｓｈなど）で書かれてよい。

プラグイン関数によってアクセスされうるデータソースの他の例は、任意のウェブサービス４６、他のリモートアクセス可能なデータベースまたはプロセス４８、リアルタイムチャネル、ＡＩエンジン、（ストレージおよび処理の組みあわせである）ビッグデータストアおよびデータウェアハウス、ＩｏＴセンサネットワーク、などを含む。ウェブサービスの一例は、Ｇｏｏｇｌｅ社によって提供されるサービスまたは関数であり、そこでは、プラグイン関数が特定のデータセットを提供し、サービスが検索などを操作、変換、実行した後に、結果として得られるデータをプラグイン関数に返す。さらに、任意の適切なＡＰＩを用いて、プラグイン関数が、非標準的なデータベース４８（レガシーデータベースまたは多様なリモートプロセス４８など）にアクセスしてよい。

上記のシステムを用いることにより、プラグイン関数の開発者は、所望のデータにアクセスして、そのデータで計算または組みあわせを実行することだけに関心を持つだけでよく、管理者機能もユーザインターフェースの実装も気にする必要がない。上述のように、標準的な階層ファイルシステムユーザインターフェースが、ユーザに提示されており、これは、プラグイン関数の開発者が、ユーザインターフェース設計または実装を全く実行する必要がないことを意味する。図２に示すように、クライアントコンピュータ２２は、ＷｅｂＤＡＶクライアント５９と、プレゼンテーションアプリケーション１７２（ブラウザなど）と、を備える。クライアント５９は、標準ＨＴＴＰ呼び出し（ｇｅｔ、ｐｕｔなど）をＷｅｂＤＡＶ ＡＰＩ １５２へ送信し、それと引き替えに標準ＨＴＴＰ応答を受信する。

次いで、ブラウザは、（後に詳述するように）階層ファイルシステムのフォルダおよびファイルを表示し、特定のファイルが、任意の標準的なソフトウェアアプリケーション（ＰＤＦリーダ、Ｅｘｃｅｌ、Ｐｉｃｔｕｒｅ Ｖｉｅｗｅｒ、Ｖｉｚａｂｌｅ、Ｗｏｒｄ、ＰｏｗｅｒＰｏｉｎｔ、ＱｕｉｃｋＴｉｍｅなど）を用いて閲覧されてよい。クライアントコンピュータ上のフォルダおよびファイルの表示は、オペレーティングシステムによっては、自動的であってよい。Ｗｉｎｄｏｗ １０を実行するデスクトップコンピュータにおいて、例えば、ビルトインＷｅｂＤＡＶクライアントが表示を実行するが、ユーザは、Ｗｉｎｄｏｗｓ Ｆｉｌｅ Ｅｘｐｌｏｒｅｒを見るだけである。Ａｐｐｌｅオペレーティングシステムでは、明示的なマウントされたディスクが表示を実行する。ｉＯＳなどのモバイルオペレーティングシステムでは、例えば、アップロードまたはダウンロードを可能にするカバーの下でＷｅｂＤＡＶを利用する専門のオペレーティングシステムコンポーネントが存在する。表示は、必ずしもＨＴＴＰ応答に基づいて自動的になされなくてよく、一部の環境（オペレーティングシステム、ブラウザ）では、いくつかのデフォルトが適用される。Ｍｉｃｒｏｓｏｆｔの”Ｏｆｆｉｃｅ”アプリケーションは、Ｗｉｎｄｏｗｓオペレーティングシステムとよく統合されており、ＨＴＴＰ応答に基づいてさらなる機能（シングルサインオン認証など）を可能にする。

特に、特定のプラグイン関数によって提供される情報にアクセスして閲覧するために、クライアントコンピュータ上または任意のエンドユーザデバイス上で必要とされるカスタムソフトウェアはない。エンドユーザアプリケーションを提供するために、開発者は、単にプラグイン関数を書き、それはサーバ１５０内で実行され、実行の結果は、ファイルシステム階層内のクライアントコンピュータ上でエンドユーザに表示される。この固定ユーザインターフェースが従来のフォルダおよびファイルの例えとして記載されているが、階層構造の動的なグラフベースブラウザ（直線または曲線によって相互接続された様々なサイズのカラーボールまたは長方形）など、その他の形態の固定ユーザインターフェースが用いられてもよい。

図３は、システム１００の１つの可能な実施例のよりハイレベルな図２００を示す。任意の数のサーバ１５０ａ、１５０ｂ、１５０ｃが各々、専用ホストコンピュータ上、もしくは、例えば、クラウドコンピューティングプラットフォーム、企業内のデータセンタ、または、おそらくは特定のプラットフォーム（Ａｍａｚｏｎウェブサービス、Ａｚｕｒｅ、ＶＭｗａｒｅなど）の中のコンピュータサーバ上の仮想マシン内で実行する。上述のように、そして、以下で詳述するように、サーバ１５０ａは、プラグイン関数の実行を容易にすると共に様々なデータリポジトリとエンドユーザデバイスとの間の通信を支援するＥｓｏｐｔｒａ ＮＶから利用可能なコンパイル済ソフトウェアである。具体的な一実施形態において、サーバ１５０ａは、カーネルバージョン３．１６以降のＬｉｎｕｘ Ｘ８６＿６４システム上での利用のために実行可能な静的にコンパイルされたバイナリであり、Ｇｏプログラミング言語で書かれ、Ｄｅｂｉａｎ８．２オペレーティングシステム上で実行する。サーバは、ホストネットワーキングのオーナーシップを引き受け、独自のルーティングテーブルを作成し、ファイヤウォールルールを置き換え、仮想イーサネットアダプタ、Ｌｉｎｕｘブリッジ、および、複数の内部ネットワーク（シェアごとに１つ）を作成する。また、サーバは、実行前にコンパイルされるが、コンパイル済コードは、プラグイン関数を全く含まない。

プラグイン関数は、通例、企業の独自のデータベースに対する読み出しまたは書き込みを行うことが想定されるが、プラグイン関数が、将来の利用に向けて自身の専用格納位置にデータを単に書き込む必要がある可能性もある。そのことを考慮して、プラグイン関数がデータを書き込みデータを読み出すことができるキャッシュ２１０およびオブジェクトストア２２０も提供される。アクセスは、サーバ１５０ａのモジュールによって提供され、様々な方法で実施されてよい。キャッシュ２１０は、高速で一時的なストレージを提供するために、サーバ１５０ａに関連する仮想マシン上で実行する任意のプラグイン関数によって利用可能になっている。通例、キャッシュは、仮想マシンが実行するコンピュータサーバに直接接続されたローカルな物理ドライブである。

オブジェクトストア２２０は、典型的にはネットワーク接続を介してプラグイン関数に提供されるリモートストレージであるが、サーバ１５０ａと同じサービス内に配置されてもよい（例えば、サーバ１５０ａおよびオブジェクトストア２２０の両方が、ＡＷＳ内にホストされる）。オブジェクトストアは、データが格納されている場所（例えば、後の検索およびリトリーブに向けた写真のストレージ）に関してユーザまたは企業がとらわれない場合に、プラグイン関数が長期ストレージにデータを格納できるように提供される。適切なオブジェクトストアの例は、Ｃａｒｉｎｇｏ社のＳＷＡＲＭ、ＡｍａｚｏｎウェブサービスＳ３、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ Ｂｌｏｂストレージ、などを含む。

別のサーバコンピュータ内の仮想マシン上では、サーバ１５０の内のいずれかに対してさらなるサービスを提供する中央サーバソフトウェア２３０が実行している。例えば、このサーバは、ユーザおよび企業が、適切なプラグイン関数を検索し、サーバ１５０の内に１つにそれらをダウンロードした後に、それらを実行することを可能にするプラグイン関数”ｓｔｏｒｅ”にウェブインターフェースを提供してよい。それに応じて、リポジトリ２３４（ＧｉｔＨｕｂリポジトリなど）が、プラグイン関数のためのソースコードおよび実行可能なバイナリコードを格納する。このリポジトリから、プラグイン関数が選択され、次いで、実行に向けてサーバ１５０の内の１つに転送されてよい。再び、プラグイン関数は、サーバ１５０がホストされた仮想マシンの内の１つの仮想マシン上で実行または解釈できる任意の適切なプログラミング言語で書かれてよい。プラグイン関数が独自の孤立環境で実行される時に、インタプリタ型言語（例えば、ｂａｓｈまたはＪａｖａＳｃｒｉｐｔ）のためのランタイムが投入された場合、このコードをコンパイルおよび実行する代わりに解釈することが可能である。

プラグイン関数”ｓｔｏｒｅ”に加えて、中央サーバ２３０は、どのエンティティが、どれだけの頻度、そして、どれだけの期間にわたって（ＣＰＵサイクル、ネットワーク帯域幅、永続ストレージ容量、Ｉ／Ｏトランザクションなどを用いて）プラグイン関数を利用しているのかを、中央サーバが追跡し、利用について報告し、ユーザおよび企業にインボイスを送信することを可能にする利用計量サービスも提供する。

記載したＷｅｂＤＡＶインターフェースを介して、サーバ１５０の各々は、様々なエンドユーザコンピュータデバイス２４２〜２４６のいずれかと通信する。例えば、携帯電話２４２、タブレットコンピュータ２４４、もしくは、ラップトップまたはデスクトップコンピュータ２４６の各々が、フォルダを開く、フォルダを閉じる、ファイルおよびフォルダを開く、新規名称で新規フォルダを作成する、フォルダ間でファイルを移動する、など、一般に、ファイルシステム階層においてユーザが利用可能な従来の相互作用すべてに加えて、プラグイン関数によって提示されたファイルシステム階層を閲覧するために用いられてよい。

クライアントデバイスを利用する個人からコマンドを受信し、個人へ情報を表示することに加えて、プラグイン関数は、ＲＥＳＴインターフェースまたはＳＯＡＰ（ウェブサービス）インターフェースなどのＨＴＴＰベースプロトコルを用いてサーバコンピュータ２４８のアプリケーションと通信してもよい。図３に示すように、プラグイン関数は、ユーザへの表示のためにコンピュータデバイスと直接通信してデータを提供する代わりに（またはそれに加えて）、サーバコンピュータ２４８上で実行する任意の適切なアプリケーションまたはウェブサイトとサーバ１５０ｃを介して通信してもよい。この実施形態において、後に詳述するように、サーバ１５０ｃは、（個人とは対照的に）任意のソフトウェアアプリケーションがプラグイン関数に要求を送信できるように、ＲＥＳＴ ＡＰＩも提供する。例えば、企業のコンピュータサーバ上で実行するウェブサイトは、特定のデータにアクセスする必要がある場合があり、そのために、そのウェブサイトを実装するソフトウェアプログラムが、サーバ１５０ｃのＲＥＳＴ ＡＰＩを用いて、サーバ１５０ｃと共に実行するプラグイン関数に要求を送信し、そこから応答を受信してよい。

ＥＳＯＰＴＲＡサーバ
図４は、サーバ１５０のソフトウェアモジュールをさらに詳細に示すブロック図３００である。上述のように、サーバ１５０は、プラグイン関数を書く人が、自分の操作する必要があるデータに関心を持つだけでよく、より迅速かつ安価にプラグイン関数を書くことができるように、できる限り多くの管理者機能、管理機能、および、セキュリティ機能を扱う。そして、先に説明したように、プラグイン関数は、標準的な固定ユーザインターフェースが標準的なプレゼンテーションアプリケーションによってクライアントコンピュータ上に提供されるので、ユーザインターフェースを実装する必要がない。サーバ１５０は、その後、どのプラグイン関数の目的とも無関係な機能を提供し、その機能は、仮想マシン上で実行する任意のプラグイン関数によって用いられてよい。

ＷｅｂＤＡＶモジュール３０４が、任意のクライアントコンピュータのＷｅｂＤＡＶクライアント５９と通信するためのＡＰＩを提供し、クライアントコンピュータには、それが実際のＷｅｂＤＡＶサーバであるかのように見える。任意のＷｅｂＤＡＶサーバと同様に、モジュール３０４は、ＨＴＴＰを介して要求をリッスンし、また、通信６２を介して応答を送信する。このように、モジュール３０４は、クライアントコンピュータからプラグイン関数へのデータパスを提供する。ＷｅｂＤＡＶプロトコルは、ファイルシステム階層を提供し、例えば、ＷｅｂＤＡＶクライアントは、或る親フォルダに含まれるファイルおよびフォルダの情報の要求を送信し、その後、応答のファイルおよびフォルダを表示する。

ＷｅｂＤＡＶは、好ましいプロトコルであり、表示に向けてファイルシステム階層をプレゼンテーションアプリケーションに提供することができる。例として、ＨＴＴＰベースではないＮＦＳプロトコル（または同様のプロトコル）、もしくは、特定の性能または機能の理由で専用プロトコルを実装してよい。あるいは、Ｍｉｃｒｏｓｏｆｔ社のＯｎｅ Ｄｒｉｖｅサービスが用いられてもよいし、その他のサービスおよびプロトコル（Ｇｏｏｇｌｅ・Ｄｒｉｖｅ、ＤｒｏｐＢｏｘ、および、多くの同様のサービス）が用いられてもよい。一般に、どのプラグイン関数が実行しているのかに関わらず、プレゼンテーションアプリケーションがユーザに固定ユーザインターフェースを提示することを可能にする任意の適切な技術およびプロトコルが用いられてよい。

モジュールの上の層には、クライアントコンピュータとプラグイン関数との間のデータパスを提供し、ひいては、ユーザにデータを見えるようにするウェブサーバユーザインターフェースモジュール３０８が提供されている。モジュール３０８は、クライアントコンピュータ上のプレゼンテーションアプリケーション（ブラウザなど）と通信し、また、管理者コンピュータ３１０のブラウザとも通信する。管理者は、ＲＥＳＴ ＡＰＩと共にＣＬＩユーティリティなどのアプリケーションを用いて、モジュール３０８と通信する。モジュール３０４内には、専用ポート上で管理者のための制御パスを提供するサーバ側ＲＥＳＴ ＡＰＩも備えられている。このＡＰＩは、”ｓｔａｒｔ−ｕｐ ｓｈａｒｅ：シェアの開始”、”ｓｈｕｔｄｏｗｎ ｐｌｕｇ−ｉｎ ｆｕｎｃｔｉｏｎ：プラグイン関数のシャットダウン”、”ｃｒｅａｔｅ ｕｓｅｒ：ユーザの作成”などの典型的なコマンドを備える。

認証／許可モジュール３１２は、クライアントデバイスからの任意のユーザログインの認証、および、どのプラグイン関数を利用できるのかに関してのユーザの許可を扱う。このモジュールは、アイデンティティプロバイダ３１４（オープンＩＤコネクト、ＯＡｕｔｈ２パスワード、アクティブディレクトリ、Ｇｏｏｇｌｅ、Ｆａｃｅｂｏｏｋなど）のサービスを用いて、ユーザを認証してよく、企業のＬＤＡＰディレクトリ３１６を用いて、特定のユーザを許可してよい。このモジュールは、外部サービスに依存する代わりに、独自の認証および許可ソフトウェアを備えてもよい。

モジュール３１２のセントラルオブジェクトは、グループである。ユーザは、グループのメンバにされてよく、プラグイン関数は、（管理者によって決定されたように）グループに関連付けられ、したがって、グループを介して、ユーザが、特定の関数にアクセスする。サーバは、シェアごとに、ユーザおよびグループの管理のためのビルトインファシリティ（ＲＥＳＴ ＡＰＩおよびウェブＵＩ）を有する。この機能は、関数ではなく、モジュール３１２によって操作されるので、各関数は、すべての要求が適切に認証および許可されると仮定する。（管理者によって決定された）アイデンティティプロバイダに基づいたより高度な認証および許可が、サーバに構成されてもよい。アクティブディレクトリの場合、どのユーザがどのグループひいてはどの関数にアクセスしたのかを決定するのは、アクティブディレクトリ管理者であってよい。任意の１ユーザに見える関数のコレクションは、そのユーザがメンバであるグループに関連付けられた関数セットすべての累積（すなわち、和集合）である。したがって、各プラグイン関数は、ユーザの認証および許可に全く関わる必要も実施する必要もなく、任意の数のユーザに簡単な拡張性を提供する。

割り当て／メトリクスモジュール３２０は、リソースの配分、および、利用されているそれらのリソースの測定を提供する。例えば、仮想マシン上で実行するプラグイン関数の間でリソース（ＣＰＵ、メモリ、ストレージ、および、帯域幅など）を配分し、また、どの特定の個人または企業がこれらのリソースおよびプラグイン関数を利用しているのかを測定する。プラグイン関数をグルーピングして、それらを特定のユーザへ割り当てるためのテナント−シェア技術については、後述する。

オブジェクトストレージモジュール３２８は、ネットワークを介してオブジェクトストア２２０と通信し、プラグイン関数が長期間ストレージにデジタルオブジェクトを格納することを可能にし、プラグイン関数がそのストレージの管理に関与する必要がないように、そのストレージの管理面のすべてを扱う。キャッシングモジュール３２４は、ローカルネットワークを介してキャッシュ２１０と通信し、プラグイン関数が短期ストレージにファイルシステムを用いてファイルを格納することを可能にし、プラグイン関数がそのストレージの管理に関与する必要がないように、そのストレージの管理面のすべてを扱う。

仮想化モジュール３３２は、後に詳述するように、プラグイン関数が、全く依存関係になく、仮想マシン上で実行する他のプラグイン関数とコンフリクトしないように、Ｌｉｎｕｘカーネルのフィーチャを用いて、各プラグイン関数に分離をもたらす。

プラグイン関数階層および仮想化
図５は、サーバ１５０の内の１サーバ内の（オブジェクト指向プログラミングの意味での）テナント−シェア−プラグインオブジェクト階層のブロック図である。テナントクラスが、インスタンス化され、そのクラスの各インスタンスは、システム２００内のアカウントを表し、各テナント（テナント４１０またはテナント４４０など）は、異なるエンティティ（個人、企業、デパートメント、アドホックグループなど）を表し、これは、最終的に、サーバ１５０の任意の計測された利用量の責任を負う。テナント４１０は、サーバ１５０内に表されたものとしてのみ図示されているが、各テナントは、複数のサーバ１５０のいずれにおいて表されてもよく、これらの異なるサーバ上の様々なプラグイン関数の実行に責任を負ってよい。データの格納およびそのストレージの計測を容易にするために、各テナントインスタンスに関連付けられた一意識別子があり、この識別子は、オブジェクトストアに格納された任意のデジタルオブジェクトに対するプレフィックス（第１パスコンポーネント）としてそれを用いるなどして、テナントによって格納されたデータを追跡するために、様々な方法で用いられてよい。

上述のように、各テナントのテナントインスタンスは、実行時に存在し、プロパティの中でも特に、各テナントのシェアのリストを含む。テナントと同様に、シェアは、シェアインスタンス（シェア４２０およびシェア４３０など）を作成するためにインスタンス化されるシェアクラスがある論理概念である。テナントとは異なり、シェアは、テナント内に固有のものであり、シェアは、テナント間で共有できない。各シェアは、関数４２２および４２４を含むシェア４２０など、プラグイン関数の人為的なグルーピングを作成する。図に示すように、シェア４３０は、関数４３２および４３４を含む。プロパティの中でも特に、各シェアインスタンスは、それに関連するプラグイン関数のリストを含む。各シェアの一意識別子が、オブジェクトストア内のオブジェクトに名称をつける際に、第２パスコンポーネントとして用いられる。

シェアインスタンスは、エンドユーザのためのエントリポイントとしても用いられ、したがって、各シェアインスタンスは、そのシェアのＩＰアドレスおよびポートであるプロパティを有する。ＷｅｂＤＡＶモジュール３０４は、シェアとエンドユーザとの間の通信を容易にするために、シェアあたりに１つのＷｅｂＤＡＶリスナを提供する。単一のシェアに関連するすべてのプラグイン関数が、そのシェアのサブネットのＩＰアドレスを用いるので、それらはすべて、同じネットワーク上にある（すなわち、同じサブネット上にある）ように見え、これについては、後に詳述する。例えば、サーバ１５０およびプラグイン関数がパブリッククラウド内で実行する場合でも、ＶＰＮが、シェアを用いて、そのシェアのプラグイン関数による企業のファイヤウォール内のデータへの安全なアクセスを可能にし得る。

テナントおよびシェアと同様に、プラグイン関数のためのクラスがあり、各プラグイン関数は、関連のランタイムオブジェクトを有する。１つのシェアが、任意の数の異なるプラグイン関数と関連付けられてよいが、所与のプラグイン関数が、異なるシェアのコンテキスト内で実行されてもよい（例えば、関数４２２が、シェア４２０のコンテキスト内と、シェア４５０のコンテキスト内で実行する）ことに注意されたい。シェアによるプラグイン関数のグルーピングは、後に説明するように仮想化技術の利用を容易にする。プラグイン関数を呼び出すのはシェアであり、そのプラグイン関数がリモートネットワークベースのサービスに働きかけることを可能にするためにソースネットワークアドレス変換を実行するのもシェアである。プラグイン関数の名称は、シェア内のルートフォルダの名称である。

各テナント（すなわち、各個人、企業など）についての情報、各シェアについての情報、および、各プラグイン関数についての情報を含む構成ファイルも存在する。具体的には、サーバが、各テナント、シェア、および、プラグイン関数に対して１つずつのファイルを含む．ｙａｍｌ構成ファイルのツリーを維持する。この．ｙａｍｌファイルは、管理者によって間接的に（例えば、ＣＬＩを介して）制御パスＲＥＳＴ ＡＰＩ呼び出しを行った結果として作成および更新される。

図６は、プラグイン関数を含む視覚化階層４６０のブロック図である。当技術分野で周知のように、ハイパーバイザ１３４が、任意の数の仮想マシン１３６をホストするために、物理マシン１３２上で実行してよい。先に説明したように、サーバ１５０は、それが呼び出す任意の数のプラグイン関数４２２、４２４と共に、この仮想マシン内で実行する。

実行中に各プラグイン関数に対して分離を提供するために、本発明は、現在利用されている仮想化技術とは異なるＬｉｎｕｘカーネルから利用可能な仮想化技術を利用する（ただし、新規の方法で）。通例は、実行中に完全な分離を提供するために、プロセスが、コンフリクトなしにプロセスが実行することを可能にするいわゆるソフトウェア「コンテナ」内で実行するよう構成される。コンテナを実装する一般的なソフトウェアアプリケーション（Ｄｏｃｋｅｒ）は、コンテナ内の各プロセスが、独自のルートファイルシステム（ＲＦＳ）を有するだけでなく、各プロセスが独自の排他的なネームスペースを有することを必要とする。しかしながら、本発明は、本発明の目的に従って利点を提供するために、異なる方法で分離を実施する。

ソフトウェアコンテナと同様に、各プラグイン関数４２２、４２４は、独自のルートファイルシステム（ＲＦＳ）を備えたサーバ１５０によって呼び出され、したがって、仮想マシン内にインストールされた他のプロセスとのコンフリクトを防ぐために必要とする分離を各プラグイン関数に提供する。しかし、現在の技術とは異なり、各プラグイン関数は、独自のネームスペースを提供されない。それは、シェアのネットワークネームスペース内にネストされたネットワークネームスペースを取得して、そのシェアと他のネームスペース（プロセス（ＰＩＤ）ネームスペースなど）を共有する。

本発明の目的の１つは、企業によるプラグイン関数の開発を容易にすることであり、その企業の様々なデータリポジトリにアクセスするために、および、プラグイン関数の開発に掛かる費用および時間を削減するために、プラグイン関数ごとの非共有ネームスペースが不利になることがわかる。企業がファイヤウォールの背後の自身のデータベースの１つにアクセスするために必要なプラグイン関数一式の例を考える。単一のプラグイン関数がそのデータベースにアクセスすることを可能にするようにＶＰＮが設定された場合、プラグイン関数がＶＰＮを利用するのを可能にするために特定の量のネットワーキングが必要とされる。一式のプラグイン関数が第１プラグイン関数と同じネットワークネームスペースを共有することを可能にすることにより、一式全体が、ネットワークを共有し、すべての関数が、ＶＰＮを利用できる。この結果は、Ｄｏｃｋｅｒで行うなど、分離のために従来のソフトウェアコンテナを用いても実現できない。ソフトウェアコンテナを用いた場合、各関数は、独自の排他的なネームスペースを有することになり、ネットワーキングは、各関数のために個別に設定される必要があるため、各関数の開発者の作業が多くなり、関数の開発が困難になる。

より具体的には、ネットワークネームスペースを共有するために、サーバは、ソフトウェアブリッジおよびファイヤウォールベースのソフトウェアルーティング（ｉｐｔａｂｌｅｓ）で内部ソフトウェア定義ネットワークを作成する。各シェアは、独自のサブネット（すなわち、そのシェアのためのプライベートネットワーク）を有する。シェアのプラグイン関数はすべて、そのシェアのサブネットに接続される。サーバのホストコンピュータのＩＰアドレスは、外部世界へのゲートウェイであり、内部では、本当のＴＣＰ／ＩＰネットワークのように見え、ソフトウェア定義ネットワークとして構築される。したがって、シェアが、ネットワークデバイスのように見えるプラグイン関数を備えた独自のネットワークを有するかのように見える。ネットワークは、（１９２．１６８．Ｙ．Ｚ／１６である）ホームネットワークによく似た非インターネットルーティングネットワーク１０．Ｘ．Ｙ．Ｚ／８である。ファイヤウォールは、ＳＮＡＴ（Ｓｏｕｒｃｅ ＮＡＴｔｉｎｇ）を用いて、インターネットへのこのネットワークアクセスを与える。

したがって、本発明の一実施形態は、特定のシェア内のプラグイン関数がネットワークネームスペースを共有することを可能にし、例えば、関数４２２および４２４がネームスペース４８０を共有し、実質的には、それらがすべて、同じネットワーク４９０上にあることを意味する。より具体的には、ネームスペースを共有するプラグイン関数が、ＩＰスタックを共有し、プロセス識別子のセットも共有する。したがって、シェアの概念は、プラグイン関数が共通のネットワークネームスペースなど様々なネームスペースを共有できるようにプラグイン関数をグループ化することを可能にする。サーバは、仮想イーサネットペア（ｖｅｔｈペア）を用いて、分離されたネットワークを作成し、各シェアとホストコンピュータとの間および各プラグイン関数とシェアとの間にｖｅｔｈペアを作成する。したがって、シェアのプラグイン関数は、同じサブネット上にある。

具体的な一実施形態において、サーバは、Ｌｉｎｕｘ上で動作し、Ｌｉｎｕｘは、複数のネームスペースを提供する。この実施形態において、今、Ｎｅｔｗｏｒｋ、ＰＩＤ、ＵＴＳ、および、Ｃｏｎｔｒｏｌ Ｇｒｏｕｐｓを利用する。各シェアは、独自のＮｅｔｗｏｒｋ、ＵＴＳ、および、ＰＩＤネームスペースを有する。また、各プラグイン関数は、さらなるネストされたネットワークネームスペースを有する。テナント、シェア、および、プラグイン関数は各々、会計および割り当ての管理のための対応する”ｃｇｒｏｕｐ”を有する。ネットワークネームスペースは、効果的に、別個のＩＰスタックのように見える。プロセスネームスペースは、効果的に、別個のセットのプロセス識別子のように見える。

各プラグイン関数に独自のＲＦＳを提供し、プラグイン関数がネームスペースを共有するためにグループ化されることを可能にすることが、好ましい実施形態であるが、本発明は、各プラグイン関数が独自のネームスペースを割り当てられる従来のソフトウェアコンテナを用いて実施されてもよいと考えられる。

図７は、プラグイン関数のためのルートファイルシステムがどのように作成されうるのかを示す図５００である。上述のように、サーバ１５０に関連する仮想マシン上で実行する各プラグイン関数は、分離を提供するために、独自のルートファイルシステムを有する。仮想マシンが実行しているサーバコンピュータ１３２の物理ディスク５１０上のローカルフォルダが示されている。ルートファイルシステムは、”Ｐｌｕｇ−ｉｎ Ｒｏｏｔｆｓ”５２０という名称のそのディスク上のフォルダに解凍される。

好ましくは、ルートファイルシステムは、複数の層に構築され、第１層は、Ｃ＃、Ｐｈｙｔｈｏｎ、または、Ｊａｖａファイルなど、特定のプログラミング言語のためのベース層を典型的に含むベースルートファイルシステム５３０である。このベース層は、その特定のプログラミング言語で書かれた任意のプラグイン関数によって必要とされるコードを含むので、典型的には、サーバ１５０に関与するエンティティによってローカルディスク上に提供される。一例として言語Ｐｈｙｔｏｎを用いると、このベース層は、Ｐｈｙｔｏｎランタイム環境のためのコンパイル済コードを含み、典型的には、ｚｉｐファイル”ｂａｓｅ．ｔａｒ．ｇｚ”に格納される。ルートファイルシステムは、単純であってもよいし、Ｊａｖａ仮想マシンくらい高度であってもよい。

第２層は、依存層５４０であり、典型的には、１または複数のプラグイン関数が必要とする特定のプログラミング言語における追加のライブラリを含む。この第２層は、多くの関連プラグイン関数（単独の企業によってまたはシステムインテグレータによって作成された関連プラグイン関数など）が必要とする依存を含む可能性があるので、企業またはシステムインテグレータによって作成され、特定のプログラミング言語で書かれた関連プラグイン関数による利用に向けてリポジトリ２３４に格納される可能性がある。この層は、プラグイン関数のためのホストフォルダ内でベース層の上に解凍される。Ｐｙｔｈｏｎプラグイン関数については、この層は、Ｐｙｔｈｏｎクラスおよびライブラリを含み、典型的には、ｚｉｐファイル”ｅｐｅｎｄｅｎｃｉｅｓ．ｔａｒ．ｇｚ”に格納される。

第３層は、プラグイン関数５５０のための実際のコードであり、仮想マシン上で実行できる任意の適切なプログラミング言語で書かれている。プラグイン関数は、非常に特殊なデータ操作タスクのために書かれ、したがって、そのバイナリコードは、リポジトリ２３４に格納される。Ｐｙｔｈｏｎについては、これは、タスクを実行する実際のＰｙｔｈｏｎコードである。

以下にさらに詳細に説明するように、プラグイン関数が配備されると、これらの層が、時間５０１〜５０３に１つずつ重なって、物理ディスク上のフォルダ５２０へ解凍される。集合的に、これらの層は、プラグイン関数のためのルートファイルシステムを提供する。

プラグイン関数の配備
図８Ａは、プラグイン関数がサーバ１５０にどのように配備されるのか、すなわち、すぐに実行できるようにサーバ１５０上にプラグイン関数を配置するのに必要な工程、を示すフローチャートである。プラグイン関数を実際に書くことに加えて、プラグイン関数の配備は、管理者によってまたはサーバ１５０によって自動的に対処されるため、開発者の負担が取り除かれる。上述のように、サーバの管理のためにサーバ１５０内に制御パスＲＥＳＴ ＡＰＩが存在する。クライアント側の管理アプリケーションを開発するためのＳＤＫが、ＬｉｎｕｘコンソールまたはＢａｓｈスクリプトで用いられるＣＬＩ管理ツールである別個の実行可能ファイルを開発するために用いられる。ＣＬＩ（またはＳＤＫまたは生ＲＥＳＴ ＡＰＩ）を用いて、管理者は、層をアップロードする、様々なプロパティを設定するなど、テナントシェアプラグイン関数の階層をナビゲートおよび管理する。配備後に、層が解凍され、ルートファイルシステムは、サーバのディスク上のフォルダに実際にインストールされる。こうして、プラグイン関数は、ユーザＨＴＴＰ要求でトリガされたサーバによる呼び出しの準備が整う。この配備の詳細は、以下の通りである。

図８Ａの第１工程６０４において、開発者が、特定のデータ操作タスクを実行するために適切なプログラミング言語でプラグイン関数を書く。各プラグイン関数は、上述のように、リポジトリ２３４に格納されてよく、異なる層を備えてよく、各層は、”．ｚｉｐ”ファイルとして格納されることが好ましい。

クライアントコンピュータ上での標準的なファイルシステム階層の提示を容易にするために、各プラグイン関数は、プラグイン関数のＡＰＩを形成するコマンドセットのサブセットを実装する。すべてのコマンドが必ずしも実装される必要はなく、プラグイン関数は、他のコマンドが要求されないので、それらの他のコマンドを実装しないことが好ましい。このＡＰＩのコマンドを実装することにより、関数は、クライアントコンピュータ上のプレゼンテーション層におけるユーザ動作（例えば、フォルダを開く、フォルダの名前を変える、など）、すなわち、フォルダおよびファイルと相互作用する際のユーザによく知られた動作、をサポートする。関数は、開発者が望むような他の機能で各コマンドを拡張してもよい。

表１は、ＡＰＩのそれらのコマンド、コマンドをＷｅｂＤＡＶクライアントからプラグイン関数に送信させるクライアントコンピュータ上のプレゼンテーションアプリケーション内での特定のユーザ動作、クライアントコンピュータ上に表示される結果、および、（コマンドを拡張するために関数が行いうる動作の中でも特に）プラグイン関数がコマンドを実装するために行いうる動作、を挙げたものである。有利なことに、プラグイン関数は、開発者のニーズに応じて、例えば、どのフォルダが開かれるまたは除去されるか、フォルダの名称、エンティティがどこへ移動されるか、などを用いて、これらの標準的なユーザインターフェースコマンドの１つから通常期待されるものに加えて、他の動作を行ってもよい。例えば、ファイル（またはフォルダ）をフォルダに移動させると、そのファイルに関連付けられたユーザの名称をフォルダに関連付けられたグループに追加する動作も行われ、または、他の処理が、フォルダまたはファイルの名称に基づいて行われてもよい。もしくは、ファイルまたはフォルダの除去が、コンテキストに応じた時間の長さだけ遅延され、または、他の処理が、フォルダまたはファイルの名称またはコンテンツに基づいて行われる。もしくは、ファイルの削除時に、他のクリーンアップタスク（コピーの保存、データベースの更新など）が実行される。したがって、ユーザがファイルシステム階層の従来のユーザインターフェースで期待する単純な機能をはるかに超えうる機能で、標準的なファイル／フォルダユーザインターフェース意味論が拡張される。プラグイン関数の必要なフォーマットは、バイナリである実際のファイルデータを除けば、ＪＳＯＮ要求および応答本文である。

工程６０８において、管理者は、適切なネットワーク接続６９を介して、上述の階層を用いて（典型的には、スクリプトまたはコマンドを用いて）、特定のサーバ１５０のためのテナント、シェア、および、プラグイン関数を定義する。これらのエンティティの各々は、プロパティを有し、各プラグイン関数のプロパティは、一意識別子、どの層が関数を構成するか、および、各層のＵＲＬまたはコンテンツアドレス、を含む。ＵＲＬまたはコンテンツアドレスは、サーバ１５０が後にプラグイン関数を見つけてリトリーブすることを可能にする。次に、工程６１２において、サーバは、各テナント、シェア、および、プラグイン関数のための構成ファイルをディスク上に（例えば、管理者からのスクリプトを用いて）自動的に作成し、各々をメモリ内でランタイムオブジェクトとしてインスタンス化する。各ランタイムオブジェクトは、適切なプロパティを備えており、例えば、各シェアは、上述のように、関連するプラグイン関数の間でのネームスペースの共有を実施するために、ネットワーキングプロパティを備える。これらのメカニズムを通して、サーバ１５０は、そのテナントおよびシェア、ならびに、どのプラグイン関数が利用されるかを知る。工程６１６において、各プラグイン関数について、サーバ１５０は、関数の各層をフェッチして、サーバ１５０のローカルディスク上のルートファイルシステムフォルダへ解凍する。この工程は、サーバ上の各シェアに対して行われる。

次に、工程６２０において、サーバは、特定のプラグイン関数が”ｓｔａｒｔ”コマンドを実装するか否かを判定する。この工程において、サーバは、”ｏｐｔｉｏｎｓ”コマンドで関数にクエリし、関数は、それが実装するコマンド（例えば、ｇｅｔ、ｐｕｔ、ｌｉｓｔなど）を返す。上述のように、関数は、「コマンドライン」モード、すなわち、呼び出された時に関数が実行してその後終了する一時的なモードで実行してもよいし、「デーモン」モード、すなわち、実行された時にプロセスが関数に対して作成され、プロセスが実行し続けるモードで実行してもよい。”ｓｔａｒｔ”を実装する関数は、デーモンモードで実行しうる。関数がこのコマンドを実装する場合、工程６２４で、サーバは、デーモンモードで関数を呼び出す（後述の図８Ｂ）。実装しない場合、以下でさらに詳細に説明するように、制御は、サーバおよびプラグイン関数がユーザからの関数呼び出しの任意の要求を待つ工程６２８に進む。関数は、デーモンとして実行する関数については工程６２４でローカルディスク上のルートファイルシステムフォルダから仮想マシンへロードされ、例えば、工程７２０において関数がコマンドモードで実行される度に繰り返しロードされる。

図８Ｂは、プラグイン関数についてデーモンモードの利用を記載するフローチャートである。この技術は、デーモンモードでプラグイン関数を起動して、関数が連続的に実行することを可能にし、これは、プラグイン関数だけのためのユーザインターフェースを実装するプラグイン関数に固有のマイクロウェブサーバを提供するものである。また、デーモンモードの利用は、プラグイン関数が、さらなる利点となるデータベースへの連続的な接続を維持することも可能にする。

デーモンモードは、プラグイン関数によって実装される任意のコマンド（データの読み出しまたは書き込みなど）と併せて用いられてもよいし、プラグイン関数のためのメタデータまたはその他の命令を収集するために前もって用いられてもよい。デーモンモードでのプラグイン関数の実行は、関数が長期間（例えば、サーバ１５０が実行している限り）実行し続けることを可能にし、プラグイン関数が、マイクロウェブサーバを介してユーザから入力を収集するまたはデータベース接続を維持することを可能にする。

工程６４０において、プラグイン関数は、上述したように配備され、工程６４２において、サーバは、工程６２４に関して上述したように、プロセスを作成し、そのプロセス内でデーモンとしてプラグイン関数を実行する。この時点で、プラグイン関数は、連続的に実行しており、ユーザ要求を待つ以外に、さらなる明示的な動作を行う必要はない。ただし、有利なことに、連続的に実行しているプラグイン関数は、工程６４４または工程６５４で始まる以下に記載の２つの任意選択的な目的で用いられてもよい。

工程６４４において、プラグイン関数は、ユーザがそのプラグイン関数に入力を提供することを特に可能にするシングルページウェブアプリケーションを実装するマイクロウェブサーバを作成する。シングルページウェブアプリケーションは、開発者の望む任意のフォーマットを有してよく、任意の入力データを要求してよい。この内部ウェブサーバは、ユーザがアクセスできない内部ポートでリッスンしている。サーバは、クライアントデバイス上に表示される単一のアイコン（「ギア」アイコン、「設定」ボタン、または、ユーザ入力が利用可能であることを示すその他のアイコンなど）をクライアントデバイスに返す。工程６４６において、ユーザは、このアイコンを選択することによって、ひいては、サーバにそのポートで送信される標準”ｇｅｔ”ＨＴＴＰ要求を作成することによって、（例えば、クライアントデバイス上のブラウザを介して）マイクロウェブサーバにナビゲートする。次に、サーバは、この要求を、内部ポートでリッスンしているプラグイン関数に渡す。

次に、工程６４８において、マイクロウェブサーバは、クライアントデバイス上に表示されたシングルウェブページアプリケーションに応答する。工程６５０において、ユーザは、ウェブページ上で要求されたメタデータ（クエリ、タグ、ラベル、キーワード、ユーザ情報、アップロード時刻など）を入力する。入力すると、このデータは、クライアントデバイスからサーバ１５０への”ｐｕｔ”要求を用いて、プラグイン関数のファイルに書き込まれる。このファイルは、ユーザには見えない隠しファイルであるが、メタデータ、命令などを含むものとしてプラグイン関数に知られた特別なファイル名を有する。通例、このファイルは、後述するバックエンドキャッシュ技術を用いて、キャッシュ２１０に格納される。次いで、プラグイン関数は、このファイル内のメタデータを用いて、検索を実行する、ファイルを格納する、または、プラグイン関数の処理を他の方法で変更する。

別のオプションとして、工程６５４において、デーモン関数はデータベース、（ローカルまたはリモートデータベースもしくは接続プールなど）への接続を開き、その接続を維持する。データベースの任意の適切なＡＰＩが用いられてよく、目標は、できる限り長く接続を維持することである。データベースへの接続を開いて維持するには、比較的長い時間がかかり、パフォーマンスに影響するので、他のプラグイン関数によって利用されうる接続を開いて維持すれば（つまり、それらの関数自身は開いて維持する必要がない）、これらのプラグイン関数のための応答時間が大幅に高速化する。通例は、工程６４２において実行し始めたのと同じプラグイン関数が、コマンドラインモードで異なるプロセスにおいて再び（または何度も）呼び出されて実行されうる。次いで、この他のプラグイン関数は、工程６５４でデーモン関数によって確立されたデータベースへのオープン接続を利用してよい。デーモン関数と同じではないプラグイン関数が、オープン接続を利用してもよい。

したがって、工程６５６において、デーモン関数は、特定のＲＥＳＴ ＡＰＩ要求のためのリスナを開始する。一般に、プラグイン関数が同じホスト上で互いに通信することを可能にするために、プロセス間の通信技術が必要である。様々な技術が用いられてよいが、この例では、デーモン関数はＲＥＳＴサーバを実装しており、任意の他のプラグイン関数がコマンドラインモードで、ＲＥＳＴクライアントとして機能する。今、デーモン関数は、データベースへの接続に関して他のプラグイン関数からの任意の要求に応答できる。

工程６５８において、他のプラグイン関数は、ＲＥＳＴ ＡＰＩを介してデータベースに関する要求をデーモンプラグイン関数に送信し、応答を待つ。この要求は、データベースの任意の要求（データベースからのデータの読み出しまたはデータベースへのデータの書き込みなど）であってよい。これらのプラグイン関数の１または複数の開発者は、任意の数のプラグイン関数が単一のデーモンプラグイン関数によって確立されたオープン接続を利用することを可能にするために、このプロセス間の通信技術を利用するように関数を書いている。工程６６０において、デーモン関数は、要求を受信し、そのオープン接続を用いてデータベースにアクセスし、他の関数によって要求された（場合に応じて）読み出しまたは書き込みを実行し、データベースから結果（要求されたデータまたは書き込みの確認など）を受信する。次いで、工程６６２において、デーモン関数は、ＲＥＳＴ ＡＰＩを介してこの結果を他のプラグイン関数へ中継する。

もちろん、プラグイン関数は、様々な他の理由のためにデーモンモードで開始されてもよい。例えば、連続的なバックグラウンド処理が必要な場合、または、ユーザによって要求された後の或る時点に書き込みを実行することが有利である場合、プラグイン関数は、それらの利点を提供するためにデーモンモードで開始されてよい。

プラグイン関数を用いたデータの読み出し
図９Ａ〜図９Ｃは、データを読み出してユーザに表示するためにプラグイン関数が利用される一実施形態を記載するフローチャートである。”の例では、プラグイン関数”ＥＯＤ”が、前もって作成され、リポジトリ２３４に格納されており、上述のようにサーバコンピュータ１３２内に配備されている。関数ＥＯＤ（終値を表す）は、ユーザにフォルダを提示し、そのフォルダが開かれると、様々な証券取引所のフォルダを表示し、それらのフォルダの各々が開かれると、様々な商品のいずれかの終値をリストするファイルを表示する。本発明の１つの利点は、ユーザの知る限り、ユーザが行うことは、フォルダを開いてファイルを選択することだけであり、すなわち、プラグイン関数が裏で実際に実行して、情報を収集し、フォルダおよびファイルをオンザフライで作成し、リアルタイムでユーザにデータを表示していることに、ユーザが気付かないことである。ユーザには、ハイレベルＥＯＤフォルダの中のフォルダおよびファイルが最初から永久的にどこかに存在するように見えるが、これらのフォルダおよびファイルは、ＥＯＤプラグイン関数が実行するまで作成されず、作成される場合にも、ファイル閲覧インターフェースに表示するかまたはエンドユーザアプリケーション内にレンダリングするためにすぐに必要とされるフォルダおよびファイルのみである。

本発明の一実施形態の１つの利点によると、これらの例で示したフォルダおよびファイルの階層は、プラグイン関数が実行してその階層を生成するまではメモリまたはストレージのどこにも実際に存在せず、その後、すぐに必要とされるサブセットだけを生成する。従来のファイルサーバとは異なり、開発者は、この階層および特定のファイルを事前に作成する必要がなく、階層およびファイルコンテンツは、必要な時、すなわち、ユーザがフォルダを開くためにタップした時、または、ファイルのコンテンツを見るためにファイルをタップした時に、プラグイン関数によって生成されればよい。ユーザインターフェースは、ファイルのアイコンおよびファイル名を表示してよいが、そのファイルの実際のデータは、まだ生成もリトリーブもされておらず、ユーザが具体的にそれを要求するまで、プラグイン関数は、データの生成もリトリーブも行う必要がない。有利なことに、プラグイン関数が作成する階層は、望むだけ深くまたは広くすることが可能であり、実際的に制限がない。ファイルサーバの従来の階層は、利用可能なディスクスペースによって制限される。

図１０Ａ〜図１０Ｆは、プラグイン関数にアクセスしてデータをリトリーブおよび表示するためにユーザが利用しているエンドユーザコンピュータデバイス２４２〜２４６を示す。この例において、コンピュータデバイスは、携帯電話であるが、様々なエンドユーザコンピュータデバイスのいずれであってもよい。実際、デバイスは、アプリケーションが、後述のデータをナビゲート、リトリーブ、および、表示するために、ＲＥＳＴインターフェースを用いてサーバ１５０と相互作用しているコンピュータ２４８であってよく、その場合、以下のユーザに起因する動作は、アプリケーションによって実行されてよい。以下の説明では、ユーザが指を使ってタッチスクリーン上で選択を行うよう記載されているが、コンピュータマウス、スタイラス、トラックパッド、音声コマンドなど、任意の他の適切な入力デバイスが用いられてもよい。

第１工程７０２において、ユーザは、認証／許可モジュール３１２を用いて、適切なサーバ１５０にログインする。上述のように、エンドユーザデバイスに応じて、ユーザは、コンピュータの標準ブラウザを用いて、コンピュータスクリーン上に表示されたマウント済みのドライブアイコンを用いて、または、ＷｅｂＤＡＶプロコトルを用いて、サーバ１５０にアクセスしてよい。このプロトコルは、ほとんどのコンピュータに組み込まれており、モバイルデバイス上でアプリケーションとしても利用可能である。

図１０Ａは、エンドユーザデバイスが携帯電話７６０である一実施形態を示しており、携帯電話７６０上では、アプリケーションＷｅｂＤＡＶ Ｎａｖ＋７６２（ＷｅｂＤＡＶプロトコルの実装例）が実行中であり、よく知られたフォルダとして現れている。この例において、ユーザは、サーバによってすでに認証されている（ユーザ名／パスワードダイアログボックスの提示によるか、それらの項目両方を格納する予め埋められたプロフィールを用いることによる）。アイコン７６２を選択すると、アプリケーションは、接続できるサーバのリストを提示し、スクリーンは、図１０Ｂに示すようになる。この例では、”Ｅｓｏｐｔｒａ Ｄｅｍｏ”という名称のサーバ１５０への単一の接続７６４だけが利用可能である。

工程７０４において、ユーザは、接続７６４を選択することによってサーバ１５０の特定のシェア（シェア４２０など）にアクセスする。この例では、ＷｅｂＤＡＶプロトコルを用いて、デバイス７６０とシェア４２０との間の接続が確立される。別の例では、図５に示したものなど、標準ブラウザに入力されたＵＲＬが、直接的にシェアにアクセスしてもよい。シェアは、技術的にはエンドポイント（すなわち、サーバ１５０のエントリポイント）であるので、いずれもネットワークにおいて同じネームスペースを共有する関数４２２および４２４など、そのシェアに関連付けられたプラグイン関数のグループを識別することができる。アプリケーションからサーバへの要求は、シェアのルート（／）に送信されたＷｅｂＤＡＶプロトコルのｖｅｒｂ”ｐｒｏｐｆｉｎｄ”を用いて、シェアのコンテンツをリスト化する。そのシェアのＷｅｂＤＡＶリスナは、そのシェアのプラグイン関数をそれぞれ表すフォルダ名のリストを返す。

次に、工程７０６において、７６４を選択したことに応答して、”Ｅｓｏｐｔｒａ Ｄｅｍｏ”内のハイレベルフォルダがユーザに表示され、図１０Ｃに示すようになる。選択されると、サーバ１５０は、そのシェア内で利用可能なプラグイン関数の名称を表示し、それらのプラグイン関数は、ログインした特定のユーザによって利用可能である。３つのハイレベルフォルダＥＯＤ７６８、Ｗｏｒｄｓ７７０、および、Ｐｈｏｔｏ７７１が示されている。領域７６６は、現在の階層を表示しており、すなわち、フォルダ７６８、７７０、および、７７１が”Ｅｓｏｐｔｒａ Ｄｅｍｏ”という名称のシェア内にある。これらのプラグイン関数は、図８Ａに記載したように、先に配備されているので、サーバは、どのプラグイン関数を表示するかを知っている。特定のシェアのすべてのプラグイン関数が、ログインしてそのシェアに接続するすべてのユーザによって利用可能でなくてもよい。例えば、シェア４２０へログインするユーザが、関数４２２へのアクセス権だけを有し、関数４２４へはアクセスできなくてもよい。ユーザが認証されると、サーバは、ユーザがメンバであるグループのリストを集める。ユーザは、（管理者によって直接割り当てられた）グループの直接のメンバであってもよいし、アイデンティティプロバイダ（例えば、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ）を介した間接的なメンバであってもよい。すべてのグループが知られると、サーバは、最も広いセットの許可（すなわち、各グループに関連付けられた関数のリスト）を集め、読み出し／書き込みアクセスプロパティを含む唯一のセットを計算する。したがって、サーバは、シェアのどのユーザがグループを介して間接的にどのプラグイン関数にアクセスできるのかを判定する。

どのプラグイン関数が特定のユーザに見えるのかを制限できれば、ハイレベルフォルダ内のすべてのファイルおよびフォルダが典型的に、ハイレベルフォルダを開いた任意のユーザに見える従来のファイルサーバよりも有利である。特定のユーザだけにアクセスを制限することにより、或る特定のユーザが関数リストの独自のビューを見ることになり、各関数内で、そのユーザに固有のファイル／フォルダ階層を作成することができる（すなわち、特定のファイルまたはフォルダが、ユーザに固有またはユーザの役割（グループメンバーシップ）に固有であってよい）という利点がある。ユーザが誰であるかによって、より多い、より少ない、または、異なるファイルを見せることができるため、ファイルサーバがユーザにとって特別かつ排他的に作成されたかのように見せることができる。別の利点は、見るべきではないファイルおよびフォルダ名（メタデータ）を単に見えないようにできることである。

この時点で、関数７６８、７７０、または、７７１はどれも、データの収集も、それらが行うようプログラムされた関数の実行も開始しておらず、ユーザが知る限り、これらは、実行する関数ではなく、単に、ユーザが見たいデータを含むフォルダの名称である。もちろん、アイコン７６８、７７０、および、７７１、ならびに、これらのフォルダの名称でさえも、異なる形態を取ってもよく、異なる名称を有してもよく、必ずしも、従来のフォルダまたはファイルのように見える必要はなく、また、対応するプラグイン関数の正確な名称を有する必要もない。しかしながら、ユーザは、フォルダ”ＥＯＤ”が、様々な証券取引所のサブフォルダを含んでおり、これらの証券取引所のフォルダ内に、様々な株式、債権、および、商品の終値をリストする様々なファイルがあることを知っている。ただし、ユーザは、初めて”Ｅｓｏｐｔｒａ Ｄｅｍｏ”７６４を選択して、フォルダＥＯＤ７６８を見た時に、フォルダＥＯＤ７６８のサブフォルダおよびファイルがまだ存在せず、どのストレージにも格納されていないことに気づく必要はない。

ユーザは、特定の商品の終値を見たいと思うので、工程７０８でフォルダ７６８を選択する。選択されると、プラグイン関数ＥＯＤが工程７１０で呼び出され、次いで、工程７１２において、図１０Ｄに関連して後に詳述するように、フォルダ７６８のサブフォルダがユーザに表示される。ユーザは、ユーザの非常に慣れている動作（フォルダを選択する、ダブルクリックするなどして、フォルダを開く動作）を単に実行しているだけであるが、実際に起きていることは、プラグイン関数が呼び出され、実行を開始し、表示される階層に以前は存在していなかったデータを収集して表示し始めることであるのだと、おそらくは気付かない。ユーザが実際にデータを要求するまで、所望のデータの収集、処理、および、格納が行われる必要がないことが利点である。

図９Ｂは、ユーザがフォルダを選択した時、ファイルを選択した時、または、ユーザインターフェース上で別の同様の動作を行った時に、プラグイン関数がどのように呼び出されるのかを記載するフローチャートである。ユーザ動作およびコンテキストに応じて、後述のＷｅｂＤＡＶ要求は、プラグイン関数が処理する以下のコマンドのいずれかを含んでよい。ｓｔａｔ、ｌｉｓｔ、ｇｅｔ、ｐｕｔ、ｍｋｄｉｒ、ｒｅｍｏｖｅ、および、ｍｏｖｅ。例えば、ユーザは、フォルダをタップすると、フォルダが開かれ、そのコンテンツが表示され、ひいては、コマンド”ｌｉｓｔ”が送信されることを期待する。ユーザは、ファイルを選択またはダブルクリックすると、ファイルが開かれ、そのコンテンツが表示され、ひいては、コマンド”ｇｅｔ”が送信されることを期待する。ユーザがファイルをアップロードすると、コマンド”ｐｕｔ”が送信され、ユーザがフォルダを作成すると、コマンド”ｍｋｄｉｒ”が送信され、ユーザがファイルまたはフォルダを削除すると、コマンド”ｒｅｍｏｖｅ”が送信される。ファイルをフォルダにドラッグすることで、コマンド”ｍｏｖｅ”が送信される。ユーザが気づき得ないこと（またはユーザが聞いた可能性のあること）は、プラグイン関数が、従来のものではない他の処理、すなわち、標準的なユーザインターフェースコマンドの一部として通常は期待されない他の処理で、この期待された視覚的ユーザインターフェースを拡張している場合があることである。

ユーザは、図１０Ｃのアイコン７６８をタップする時、フォルダが開かれ、あらゆるコンテンツが表示されることを望んでおり、したがって、クライアントデバイス７６０は、そのＷｅｂＤＡＶクライアント５９を介して、工程７１６でＷｅｂＤＡＶ要求を生成する。これは、フォルダＥＯＤを開くための要求であり、フォルダＥＯＤは、単に”／ＥＯＤ”であるパスのコンポーネントと共に”ｌｉｓｔ”コマンドを含む。要求は、サーバ１５０のＷｅｂＤＡＶモジュール３０４で受信され、シェア４２０にダイレクトされる。工程６１２で説明したように、シェア４２０は、ランタイムオブジェクトである。ユーザが、上記のコマンドおよびパスを生成するために、ユーザインターフェース上で動作を実行していることが本明細書で記載されているが、実際には、少なくとも、要求に必要とされるのは、任意のフォルダおよびファイル名、ならびに、関連コマンド（”ｐｕｔ”、”ｇｅｔ”、”ｌｉｓｔ”など）を含むパスである。ユーザが特定の動作を実行することは、厳密には必要ではない。

すべての要求は、要求行と、関連パス（例えば、”／ＥＯＤ”）、コマンド（例えば、”ｌｉｓｔ”）、および、１セットのヘッダ（そのうちの１つは、ホスト名またはＩＰアドレスである）との組みあわせを用いるＨＴＴＰ要求である。これは、有線で実際に送信されるものである。その前に、アプリケーション（ＨＴＴＰクライアント）は、シェア（ホスト：ＵＲＬのポート部分）との接続を確立している。したがって、効果的に、ＵＲＬは、複数部分に分割される。

次に、工程７１８において、シェアは、キャッシュ２１０がこの要求についてこの特定のユーザのこのプラグイン関数に対して有効であるか否か、すなわち、プラグイン関数が実行されるべきか、または、プラグイン関数の最後の実行からキャッシュに格納された結果が再び利用されうるのかを判定する。最初に、シェアは、パス名の第１コンポーネント”ＥＯＤ”を、そのシェアに関連付けられたプラグイン関数の名称と比較することによって、要求がどのプラグイン関数に宛てられたのかを判定する。第２に、シェアは、キャッシュがこのユーザに対して有効であるか否かを判定する。各ユーザは、キャッシュ内にフォルダを有しており、そのフォルダ内の各ファイルまたはフォルダは、関数によって設定された有効期限タイムスタンプを有するので、シェアは、そのタイムスタンプによって有効性を判定する。また、シェアは、最後の類似の要求から経過した時間に基づいて、キャッシュがこの要求に対して有効であるか否かを判定する。パス（この例では、”／ＥＯＤ”）に基づいて、シェアは、これが最初の要求であるのか、または、要求が以前になされていたのかを判定する。最初の要求（プラグイン関数が、このパスに対する要求にまだ応答していないことを示す）である場合、または、キャッシュの期限が切れている場合、制御は、工程７２０に進む。最初１の要求ではなく、かつ、キャッシュが失効していない場合、制御は、工程７２８に進む。

工程７２０において、プラグイン関数は、コンピュータおよびオペレーティングシステムに応じて、様々な方法で操作されうる実行を開始する。一実施形態では、プロセスが、サーバ１５０によってオペレーティングシステム内で最初に作成され、プロセスは、特定のネームスペースに加わり、カーネルを用いて、”ｊａｉｌｒｏｏｔ”へのシステムコールがなされる。次いで、プラグイン関数コードは、このプロセス内で実行を開始する。次いで、サーバ１５０は、関数を呼び出し、ユーザからのコマンド（例えば、”ｌｉｓｔ”）とパス名とを渡す。上で説明したように、プラグイン関数は、任意のタイプのデータ収集、データ処理、または、データ書き込みタスクを実行するように書かれてよい。この例において、ＥＯＤ関数は、ハイレベルＥＯＤフォルダが開かれた時に、証券取引所および商品取引所を含むフォルダを表示するように書かれている。したがって、ＥＯＤ関数は、”ｌｉｓｔ”コマンドを入力し、図１０Ｄにおいて最終的に表示されるデータを生成する。

”ｌｉｓｔ”コマンドへの応答の生成が完了すると、工程７２２において、プラグイン関数は、さらに、標準および拡張メタデータを生成する。標準メタデータは、フォルダおよびファイルに関連するメタデータ、すなわち、アイテムがフォルダであるかファイルであるか、日付、時刻など、応答を見る時にデバイスのユーザに有用な典型的な情報、を含む。拡張メタデータも生成され、拡張メタデータは、この特定の要求（パスおよびコマンド）のためのキャッシュがどれだけの期間有効かについての期限を含む。換言すると、”／ＥＯＤ，ｌｉｓｔ”は、”ＥＯＤ，ｓｔａｔ”とは異なる要求である。

あるタイプの拡張メタデータは、フラグ、タイムスタンプ、および、その他のメタデータであり、最近生成されたデータが特定のユーザのためのキャッシュ内で有効である期間を示す。例えば、図１０Ｄは、３つの異なるフォルダを含む応答を示しており、ＥＯＤ関数の開発者が毎週様々な取引所をリストするための関数をプログラムした場合には、期限は、１週間であってよい。したがって、この工程で期限メタデータを生成することにより、サーバ１５０は、キャッシュがまだ有効であるか否かを、工程７１８で判定できる。第２のタイプの拡張メタデータは、キャッシュ内のファイルに配置されたフラグに関連しており、ファイルがユーザによって編集可能であるか否かまたは除去可能であるか否かを示す。かかるメタデータは、プラグイン関数に有用であり、プラグイン関数がユーザコマンドを解釈するのに役立つ。これらのフラグは、ブラウザウェブＵＩで用いられ、ＵＩをレンダリングする、もしくは、ファイルまたはフォルダに対して許可された動作を無効にする（グレイメニューアイテム）のに役立つ。１つの重要なフラグは、アイテムが仮想ファイル（すなわち、関数によって所有されるファイル）である時に設定される「仮想ビット」であり、アイテムがユーザによってアップロード（所有）されたファイル（すなわち、非仮想ファイル）である時には消去される。

次に、工程７２４において、プラグイン関数は、サーバ１５０のための自身の応答（生成されたメタデータを含む）をフォーマットする。プラグイン関数は、それが望む任意のタスクを実行できる場合でも、特定のコマンド（”ｌｉｓｔ”コマンドなど）に応答する場合、そのコマンドへの応答を特定のフォーマットにする。この例において、”ｌｉｓｔ”コマンドへの応答は、名称のリスト、名称がファイルであるかフォルダである、および、メタデータ（日付、時刻など）を提供する。具体的な一実施形態において、このリストは、ＪＳＯＮアレイとして提供される。

工程７２６において、サーバは、キャッシュ２１０にこの応答を保存する。この時点で、応答は、メモリ内およびキャッシュ内に存在しているが、キャッシュが有効である限りにおいてのみ存在しうる。応答は、サーバがキャッシュにスペースが必要であると判断した時に、キャッシュから除去されてよい。応答（または任意のデータ）が、キャッシュの内部フォーマットで格納され、応答は、一実施形態では、一意識別子と、ファイル、サブフォルダ、および、その他の項目メタデータの名称を含む１セットのメタデータファイル（”ロースタ（ｒｏｓｔｅｒ）”ファイル）（フォルダごとに１つずつ）とを備えたオブジェクトのコレクションである。ロースタファイルも、一意識別子を備えたオブジェクトである。この内部フォーマットは、バックエンドオブジェクトストアリポジトリでの利用を容易にするために特に作成されるが、もちろん、その他の内部フォーマットが用いられてもよい。キャッシュおよびオブジェクトストアについては、後に詳述する。

次いで、工程７３０において、サーバは、クライアントデバイスにこの応答を中継して返し、この時点で、デバイスのスクリーンは、図１０Ｄに示すようになる。領域７６６は、閲覧中の現在の階層をまだリストしており、アイコン７７２は、親フォルダ７６８であること、および、１つ上のレベルへ移行できることを表し、３つのサブフォルダ、すなわち、Ａｍｓｔｅｒｄａｍ Ｃｏｍｍｏｄｉｔｉｅｓ（アムステルダム商品取引所）７７４、Ａｍｅｒｉｃａｎ ｓｔｏｃｋ ｅｘｃｈａｎｇｅ（アメリカン証券取引所）、および、Ｈｏｎｇ Ｋｏｎｇ ｓｔｏｃｋ ｅｘｃｈａｎｇｅ（香港証券取引所）、が表示されている。ここで、工程７２８に戻ると、キャッシュが有効であった場合、工程７２８において、サーバは、キャッシュ内のデータからこの応答を生成することができ、制御は、キャッシュからの同じ応答がクライアントデバイスに表示される工程７３０に進む。最後に、プラグイン関数は、アイコン７６８へのユーザタップに応答してその関数を実行したので、工程７３２において終了する。

ここで、図９Ａの工程７１２に戻ると、ユーザがアイコン７６８をタップしたことに応答して、サブフォルダが、図１０Ｄに示すようにデバイス上に表示される。プラグイン関数がこれらの３つのフォルダを作成したところであり、それらのフォルダが表示されたところであるが、この時点では、フォルダはコンテンツを全く持たないことに注意されたい。換言すると、コンテンツは、プラグイン関数が、ユーザ動作に応答して再び呼び出された時に作成される。この例を単純化するために、フォルダ７７４は、それが属する実際の取引所（すなわち、ユーロネクスト・アムステルダム）の代わりに表示されている。より複雑な例においては、アイコン７６８をタップすると、フォルダ”ＥｕｒｏＮｅｘｔ Ａｍｓｔｅｒｄａｍ（ユーロネクスト・アムステルダム）”も表示され、これがタップされると、フォルダ”Ａｍｓｔｅｒｄａｍ Ｃｏｍｍｏｄｉｔｉｅｓ”７７４を表示する。

次に、工程７４０において、ユーザは、アムステルダム商品取引所の終値を見ようとし、アイコン７７４をタップする。ユーザがこのアイコンをタップすると、工程７４２において、プラグイン関数が、図９Ｂに記載したように再び呼び出される。ただし、今回は、ＷｅｂＤＡＶ要求が、パス名”／ＥＯＤ／Ａｍｓｔｅｒｄａｍ Ｃｏｍｍｏｄｉｔｉｅｓ”と、フォルダを開くためのコマンド（すなわち、”ｌｉｓｔ”コマンド）」とを含み、それらは両方ともプラグイン関数に提供される。図９Ｂに記載したように、キャッシュがその要求に対して有効である場合、応答はキャッシュから生成され、そうでない場合、プラグイン関数が応答を生成する。

図１０Ｅは、ユーザがアイコン７７４をタップしたことに応答したデバイス７６０のディスプレイを示す。工程７４４は、このサブフォルダのコンテンツを表示し、図に示されているのは、このサブフォルダ内に含まれる２つのファイル、すなわち、ＣＳＶフォーマットのファイル７７８およびＴＸＴフォーマットのファイル７８０である。ファイル７７８は０バイト７８２を有しており、この時点でそのファイル（および他方のファイル）が空であることを示していることに注意されたい。各ファイルの名称およびタイプが表示されていても、プラグイン関数がこれらのファイルに投入するためのデータをまだ生成もリトリーブもしていないので、これらのファイルは空である。

次に、工程７４６において、ユーザは、これらのファイルの１つを、そのコンテンツを見たいので選択する。ユーザは、任意の適切なインターフェース（タッチスクリーン上の指、コンピュータマウス、トラックパッドなど）を用いてファイルを選択し、当技術分野で周知のように、デバイス７６０は、ユーザが、ファイルを開くのにどのアプリケーションを用いるのかを選択することを可能にするインターフェースを提供する。したがって、工程７４８において、デフォルトアプリケーションが、デバイスによって提供されてもよいし、ユーザが、開くのに適切なアプリケーションを選択してもよい。例えば、ファイルの選択時に、デフォルトテキストエディタが、自動的にファイルを開いてもよいし、ユーザが、標準的なインターフェースウィンドウ（”Ｏｐｅｎ Ｗｉｔｈ”ウィンドウなど）を用いて、より高度なアプリケーション（ＣＳＶフォーマットを必要とする”Ｖｉｚａｂｌｅ”など）を選択することを許容されてもよい。いずれの場合でも、アプリケーションが開かれ、（すでに実行中でなければ）実行を開始する。

次に、工程７５０において、アプリケーションは、ファイルコンテンツの要求をトリガすることによって、選択されたファイル７７８のコンテンツを要求し、プラグイン関数は、図９Ｂに記載したように、工程７５２で再び呼び出される。ただし、今回は、ＷｅｂＤＡＶ要求が、パス名”ＥＯＤ／Ａｍｓｔｅｒｄａｍ Ｃｏｍｍｏｄｉｔｉｅｓ／ｈｉｓｔｏｒｙ．ＣＳＶ”と、ファイルコンテンツを読み込むためのコマンド（すなわち、”ｇｅｔ”コマンド）とを含み、それらは両方ともプラグイン関数に提供される。図９Ｂに記載したように、キャッシュがこの要求に対して有効である場合、応答はキャッシュから生成され、そうでない場合、プラグイン関数が応答を生成する。したがって、ファイルのコンテンツがまだ生成またはリトリーブされていない場合、プラグイン関数は、この時にファイルコンテンツを生成またはリトリーブする。フォルダコンテンツをリストした上記の工程７１０および７４２とは異なり、工程７５２は、”ｇｅｔ”コマンドを含んでおり、これは、プラグイン関数が、ＣＳＶフォーマットで工程７２４において応答をフォーマットしてよく、工程７３９においてクライアントに返される応答は、ファイルの実際のコンテンツになることを意味する。この例において、ＥＯＤプラグイン関数は、ファイル７７８〜７８０の親フォルダがタップされた時にそれらのファイルを提示するように書かれており、クライアントデバイス上の適切なアプリケーション（”Ｖｉｚａｂｌｅ”など）がファイルフォーマットを利用してデータをレンダリングできるように、ファイル７７８が選択された時にＣＳＶフォーマットでファイル７７８のデータを生成するように書かれている。この例において、関数は、ファイルを生成するためにデータを収集する必要があり、開発者によってプログラムされたように、データリポジトリにアクセスすることによってそれを行う。

図１０Ｆは、ユーザがファイル７７８をタップしたことに応答したデバイス７６０のディスプレイを示す。工程７５４において、工程７４８で開かれたアプリケーションは、工程７８４に示すように、ファイルのコンテンツを表示する。列７８６は日付をリスト化し、列７８８は、特定の商品についてのその日の終値をリストする。ファイルデータ７８４は、そのデータが工程７５２でプラグイン関数によって生成またはリトリーブされるまで、ファイル７７８内には存在しなかったことに注意されたい。変形例において、プラグイン関数は、フォルダ７７４がタップされた時にデータをリトリーブしてファイル７８４を作成し、そのキャッシュ内にファイル７８４を格納するようにプログラムされてもよい。

プラグイン関数を用いたデータの書き込み
図１１Ａ〜図１１Ｃは、データをアップロードした後にそのデータを処理するためにプラグイン関数が利用される一実施形態を記載するフローチャートである。この例では、プラグイン関数”Ｗｏｒｄｓ”が、前もって作成され、リポジトリ２３４に格納されており、上述のようにサーバコンピュータ１３２内に配備されている。関数Ｗｏｒｄｓは、フォルダをユーザに提示し、テキストファイルがそのフォルダにアップロードされた時に、そのテキストファイルを格納し、単語頻度を計算し、結果を含む２つの新たなファイルを作成する。上述のように、本発明の１つの利点は、ユーザの知る限り、ユーザが行うことは、フォルダを開いてファイルを追加することだけであり、すなわち、プラグイン関数が裏で実際に実行して、フォルダおよびファイルをオンザフライで作成し、リアルタイムでユーザにデータを表示していることに、ユーザが気付かないことである。フォルダ内に特定のファイルが存在するようにユーザには見えるが、これらのファイルは、ユーザがファイルを追加してプラグイン関数が実行するまで作成されない。

図１２Ａ〜図１２Ｆは、プラグイン関数にアクセスして、データを追加、リトリーブ、および、表示するためにユーザが利用しているエンドユーザコンピュータデバイス２４２〜２４６を示す。この例において、コンピュータデバイスは、タブレットコンピュータであるが、様々なエンドユーザコンピュータデバイスのいずれであってもよい。実際、デバイスは、アプリケーションが、後述のデータをナビゲート、アップロード、リトリーブ、および、表示するために、ＲＥＳＴインターフェースを用いてサーバ１５０と相互作用しているコンピュータ２４８であってよく、その場合、以下のユーザに起因する動作は、アプリケーションによって実行されてよい。以下の説明では、ユーザが指を使ってタッチスクリーン上で選択を行うよう記載されているが、コンピュータマウス、スタイラス、トラックパッドなど、任意の他の適切な入力デバイスが用いられてもよい。

最初の工程８０２において、ユーザは、工程７０２〜７０４で上述したように、サーバ１５０のシェアにログインおよびアクセスする。この例では、ＷｅｂＤＡＶ Ｎａｖ＋アプリケーションを用いたナビゲーションを説明しているが、コンピュータ上の標準ブラウザが、ナビゲーションを実行するために用いられてもよい。工程８０４において、シェアのハイレベルフォルダ（プラグイン関数を表す）がユーザに表示され、ユーザがそれらのフォルダの内の１つを選択し、そのフォルダのコンテンツが表示される。この工程は、以下の変更を加えて工程７０６〜７１２について上述したように実行されてよい。

図１２Ａは、ハイレベルフォルダの表示後で、ユーザがフォルダの内の１つを選択する前のタブレットコンピュータ８６０を示す。ＥＯＤフォルダ７６８、Ｗｏｒｄｓフォルダ７７０、および、Ｐｈｏｔｏフォルダ７７１が示されており、それぞれのプラグイン関数を表している。図１２Ｂは、ユーザがアイコン７７０をタップし、プラグイン関数が実行されて、そのフォルダのコンテンツを返した後のタブレット８６０を示す。この例において、この時点でのフォルダは空であり、アイコン８５０は、親フォルダであること、および、フォルダ階層の１つ上のレベルへ移行できることを表す。この例では、ファイルが、開かれたばかりのフォルダ７７０にアップロードされる。しかしながら、開いたフォルダが文脈を提供するのだが、ファイルをアップロードする前にフォルダを開くことは必須ではない。

図１２Ｃは、工程８０６においてユーザがフォルダ７７０にアップロードするファイルをどのように選択するのかを示す。ファイルの選択は、標準ブラウザを用いてアップロードされるローカルファイルにナビゲートする、ファイルをクリックまたはドラッグする、もしくは、任意のブラウザまたはオペレーティングシステム内にあるダイアログボックスを用いる、など、様々な方法で実行されてよい。ファイルは、タブレットコンピュータにローカルであってもよいし、任意のリモートサーバから来てもよい。この例において、ユーザは、リモートファイルを選択するための特定のサービス（ｉＣｌｏｕｄドライブ、Ｇｏｏｇｌｅドライブ、ＯｎｅＤｒｉｖｅ、Ｄｒｏｐｂｏｘなどであるが、そのウィンドウは示されていない）を選択するために、アイコン８５２を選択し、Ｄｒｏｐｂｏｘサービスを選択した結果として、ダイアログボックス８５４がスクリーン上に現れている。この例において、Ｄｒｏｐｂｏｘアカウント内には唯一、ファイル”Ｗｏｒｋｓ Ｓｈａｋｅｓｐｅａｒｅ．ｔｘｔ”８５３があり、ユーザは、指、マウス、スタイラスなどを用いてそれを選択する。

選択されると、スクリーン上でナビゲートするために用いられるアプリケーション（標準ブラウザ、または、この例におけるＷｅｂＤＡＶＮａｖ＋アプリケーションなど）は、工程８０８でファイルをＷｏｒｄｓフォルダ７７０に書き込む。アプリケーションは、ファイルのコンテンツを読み出し、”Ｗｏｒｄｓ／Ｗｏｒｋｓ Ｓｈａｋｅｓｐｅａｒｅ．ｔｘｔ”である関連パス名へのそれらのコンテンツの”ｐｕｔ”動作をトリガする。次いで、パス名および”ｐｕｔ”コマンドは、サーバ１５０によって受信され、工程８１０でプラグイン関数”Ｗｏｒｄｓ”にダイレクトされる。

図１１Ｂは、ユーザが”ｐｕｔ”コマンドなどでユーザインターフェースを用いてアップロードされるファイルを選択した時に、プラグイン関数がどのように呼び出されるかについて記載するフローチャートである。ユーザが（例えば、選択する、ドラッグする、ダイアログボックスを用いるなどして）ファイルをフォルダ内に入れる時、そのユーザは、ファイルがそのフォルダに移動または書き込まれることを期待し、したがって、この例では、コマンド”ｐｕｔ”が送信される。それに応じて、クライアントデバイス８６０は、そのＷｅｂＤＡＶクライアントを用いて、工程８１４でＷｅｂＤＡＶ要求を生成する。これは、ファイル８５３をＷｏｒｄｓフォルダに配置するための要求であり、その要求は、上記のパス名と共に”ｐｕｔ”コマンドと、ファイルの実際のコンテンツとを含む。要求は、サーバ１５０のＷｅｂＤＡＶモジュール３０４で受信され、プラグイン関数”Ｗｏｒｄｓ”を含むシェア４３０にダイレクトされる。ユーザが、上記のコマンドおよびパスを生成するために、ユーザインターフェース上で動作を実行していることが本明細書で記載されているが、実際には、少なくとも、要求に必要とされるのは、任意のフォルダおよびファイル名、ならびに、関連コマンド（”ｐｕｔ”、”ｇｅｔ”、”ｌｉｓｔ”など）を含むパスである。ユーザが特定の動作を実行することは、厳密には必要ではない。

次に、工程８１６で、サーバは、（例えば、工程８１８などで）後の要求で用いるために、（フロントサイドキャッシングを用いて）受信ファイルをそのキャッシュ２１０に書き込む。ファイルは、ユーザによってアップロードされるまで、実際にはキャッシュ内に存在しない。工程８１８において、プラグイン関数”Ｗｏｒｄｓ”は、実行を開始し、標準的な入力を用いて工程８２０においてサーバを介してキャッシュからファイルを読み出す。工程８２２において、関数は、任意選択的に、その選択の格納位置にアップロードしたファイルを書き込む。図２に示したように、プラグイン関数の開発者は、開発者がコードを書き込む人物であるため、所望の任意の格納位置４０〜４８（およびその他）に書き込んでよい。この例において、開発者は、２つの新規ファイルをさらに含む新規フォルダ（”Ｗｏｒｋｓ Ｓｈａｋｅｓｐｅａｒｅ”）の中にそのファイルを配置したいとも思っているため、新規フォルダの中のストレージにそのファイルを書き込む。この新規フォルダにファイルを書き込むのは開発者の選択であり、ファイルは、この時点で（バックサイドキャッシング、プラグイン関数ストレージを用いて）キャッシュに存在する。

もちろん、開発者は、任意の数のフォルダ内にファイルをネストさせる、任意の数の新規フォルダおよび新規ファイルを作成するなど、このファイルの格納をどのように操作したいのかに関して完全な決定権を有しており、開発者は、新規フォルダの中にファイルを配置することも任意の新規ファイルを作成することもなしに、単にファイルをディスクに書き込んでもよい。

工程８２４において、プラグイン関数は、すべての単語の頻度分析を生成するためにファイル内のデータを処理して、２つの新規ファイル（ＣＳＶファイルおよびＰＤＦファイル）を作成し、各ファイルは、オリジナルファイル内の各単語の頻度を含む。次いで、工程８２６において、関数は、これら２つの新規ファイルをオリジナルテキストファイル８５３も格納された新規フォルダ内の格納位置に書き込む。開発者は、異なる位置にこれら２つの新規ファイルを書き込むよう選んでもよい。この例において、プラグイン関数の開発者は、オリジナルファイルの書き込み時に、オリジナルファイルの処理および２つの新規ファイルの作成を実行するよう選択した。もちろん、２つの新規ファイルの作成は、開発者によって選択された別の時、例えば、読み込み時、（工程７４６〜７５４で行われたように）ユーザが表示されるファイルを選択した時に、行われてもよい。通例、新規ファイルを作成するためのオリジナルファイルまたはデータの処理は、オリジナルファイルが書き込まれた後またはユーザがオリジナルファイルの読み込みを要求した時に行われてよい。図１０Ａ〜図１０Ｆの例では、データが日々変化することから、開発者は、ユーザがファイルを要求した時にのみファイルのコンテンツを生成するよう選択している。現在の例において、新規ファイル内の頻度は変化しないので、オリジナルファイルが書き込まれた時に、それら２つの新規ファイルを作成するのが適切である。

次に、工程８２８において、サーバは、書き込みが成功したことを示す応答を工程８０８のアプリケーションに送信する。通例、この応答は、成功を示すコードまたは発生した特定のエラーを示すコードからなる。工程８３０において、プラグイン関数は、そのタスクを実行し終わったため終了する。ここで、図１１Ａに戻ると、工程８３４において、アプリケーション（ＷｅｂＤＡＶ Ｎａｖ＋アプリケーションまたはブラウザのいずれか）は、フォルダ”Ｗｏｒｄｓ”を、そのフォルダのパス名とコマンド”ｌｉｓｔ”とを含む要求をトリガすることによってリフレッシュする。通例、ブラウザは、現在のフォルダをリフレッシュするために、”ｐｕｔ”要求後に”ｌｉｓｔ”要求を実施するが、各ブラウザが、この機能を異なって実施してもよい。工程８３４は、パスおよび”ｌｉｓｔ”コマンドについて図９Ｂに記載したように実行される。

図１２Ｄは、リフレッシュ要求後のタブレット８６０を示しており、現在の”Ｗｏｒｄｓ”フォルダが、プラグイン関数の作成した新規フォルダ”Ｗｏｒｋｓ Ｓｈａｋｅｓｐｅａｒｅ”８５５を含むことを示す。ユーザは通常、ファイル８５３が現れることを期待するが、この例では、プラグイン関数は、そのファイルを書き込むだけではなく、２つの新規ファイルを作成して、新規フォルダ８５５にそれらのすべてのファイルを配置していることに注意されたい。次に、工程８３６において、ユーザは、結果を見たいと思い、デバイス上のフォルダ８５５を選択する。この動作は、図９Ｂで説明したように、パス名”Ｗｏｒｄｓ／Ｗｏｒｋｓ Ｓｈａｋｅｓｐｅａｒｅ”および”ｌｉｓｔ”コマンドを含む別の要求をトリガし、その結果として、デバイス８６０上でこの新規フォルダのコンテンツを表示する工程８３８につながる。

図１２Ｅは、工程８３６および８３８の後のデバイス８６０のディスプレイを示す。プラグイン関数が格納位置に格納した３つのファイル、すなわち、オリジナルのアップロードされたファイルであるファイル８５３、ＣＳＶフォーマットの頻度であるファイル８６２、および、ＰＤＦフォーマットの頻度であるファイル８６４、が表示されている。８６６および８６７において、これらのファイル両方が、具体的なサイズを有しており、これは、それらが実際に存在してディスクに書き込まれたことを意味し、ファイルのファイル名が現れているが、ユーザがファイルの１つを選択するまでファイルコンテンツは実際には存在しなかった図１０Ｅの例とは異なることに注意されたい。開発者は、ファイルがユーザによって選択された時にのみ、これらのファイル８６２〜８６４を作成するよう選択してもよい。

次に、工程８４０において、ユーザは、ファイル８６４を見たいと思い、ユーザの指を用いてそのファイルを選択する。その選択時に、図９Ｂで説明したように、パス名”Ｗｏｒｄｓ／Ｗｏｒｋｓ Ｓｈａｋｅｓｐｅａｒｅ／Ｗｏｒｋｓ Ｓｈａｋｅｓｐｅａｒｅ．ｐｄｆ”および”ｇｅｔ”コマンドを含む別の要求がトリガされ、その結果として、デバイス８６０上でその新規ファイルのコンテンツを表示する工程８４２につながる。図１２Ｆは、そのファイルの頻度の部分的なリストを示す。

プラグイン関数を用いたその他のデータ読み込みおよびデータ書き込みの例
プラグイン関数を用いたデータの読み込みの他の例は、以下を含む。ＳＱＬデータベースクエリから全体的または部分的にＥｘｃｅｌファイルを作成する工程、集められたフラグメント、画像、および、テキスト検索から提示文書を作成する工程、ならびに、ストリームされるビデオを静止画ｍｐ４ファイルから作る工程。プラグイン関数を用いてデータを書き込む別の例は、情報をファイルに追加することを可能にする。例えば、インボイスを表すファイルがドラッグされ、プラグイン関数を表すコンピュータデバイス上のフォルダ（フォルダ７７０など）にドロップ（または他の方法でアップロード）された時に、プラグイン関数は自動的に、タイムスタンプをそのファイルに追加する。タイムスタンプは、ファイルに直接挿入されてもメタデータとして追加されてもよく、次いで、ファイルは、オブジェクトストアにオブジェクトとして格納され、格納されたオブジェクトは、後に、時刻と日付で検索できる。また、プラグイン関数は、インボイスを異なるフォーマットに変換する、そのデータを解析する、インボイスをカテゴリで分けて異なるフォルダに格納する、などしてもよい。

プラグイン関数への入力の提供
上記で言及し図示したように、本発明の様々な実施形態は、従来のファイル／フォルダユーザインターフェースを用いて、ユーザに単純でなじみのあるインターフェースを提供すると共に、特定のユーザインターフェースを実装する必要性からプラグイン関数の開発者を解放する。ファイル／フォルダインターフェースの利用は、ユーザがプラグイン関数に引数を入力する機会をあまり提供することがない。

したがって、さらなる実施形態は、ユーザがプラグイン関数に引数を提供することを可能にする。図８Ｂに関して上述した１つの技術は、デーモンモードでプラグイン関数を起動して、関数が連続的に実行することを可能にするための技術であり、これは、プラグイン関数だけのためのユーザインターフェースを実装するプラグイン関数に固有のマイクロウェブサーバを提供するものである。また、デーモンモードの利用は、プラグイン関数が、さらなる利点となるデータベースへの連続的な接続を維持することも可能にする。（すぐ下に記載する）別の技術は、実際にプラグイン関数への引数である名称を有するフォルダを作成する技術である。ユーザが機能的に重要な名称でフォルダを作成するのを可能にすることは、プラグイン関数の機能を強化すると共にエンドユーザがユーザの環境をカスタマイズすることを可能にする本発明の重要なデフォルトのユーザインターフェース要素である。

図１３は、引数がフォルダの名称を介してプラグイン関数に渡される一実施形態を記載するフローチャートである。この例では、プラグイン関数”Ｐｈｏｔｏ”が、前もって作成され、リポジトリ２３４に格納されており、上述のようにサーバコンピュータ１３２内に配備されている。関数Ｐｈｏｔｏは、任意の写真、ビデオなどをアップロード、タグ付け、格納、ならびに、後の検索、ダウンロード、および、表示に利用可能にすることのできるフォルダをユーザに提示する。上述したように、本発明の１つの利点は、ユーザの知る限り、ユーザが行うことは、写真をアップロードすること、フォルダを開くこと、フォルダを作成することなどだけであり、プラグイン関数が裏で実際に実行して、写真にタグ付けし、それらを格納し、検索語を作成して、写真を検索していることに、ユーザが気付かないことである。特定の写真が実際に特定のフォルダ内に存在するようにユーザには見えるが、ユーザがフォルダを選択するまで写真は検索および発見されず、ユーザが写真を選択するまで写真はリトリーブされない。

図１４Ａ〜図１４Ｄは、プラグイン関数にアクセスして、データを追加、リトリーブ、および、表示するために用いられる任意のエンドユーザコンピュータデバイス２４２〜２４６を示す。この例において、コンピュータデバイスは、携帯電話であるが、様々なエンドユーザコンピュータデバイスのいずれであってもよい。ユーザは、ユーザの電話７６０でベルギーのヘールの町で写真を撮り、後にリトリーブできるようにその写真をストレージにアップロードしようとする。もちろん、ユーザが、アップロードされた数百または数千（もしくはそれより多く）の写真を撮影していてもよいし、任意の数の他のユーザが、任意のユーザによる後のリトリーブに向けて同じ格納位置に格納されるようにＰｈｏｔｏ関数を用いて写真をアップロードすることも可能である。

図１４Ａは、ユーザが利用可能な関数７６８、７７０、および、７７１を示す携帯電話７６０の図を示す。関数Ｐｈｏｔｏ７７１は、ユーザにとって、任意の数の写真、ビデオ、または、同様のファイルをドラッグ、ドロップ、アップロードなどできるなじみのあるフォルダに見える。もちろん、別の実施形態において、任意のタイプのデジタルオブジェクト（文書など）が、本明細書で記載の技術を用いて後にリトリーブするためにフォルダ７７１に配置されてもよい。ユーザは、ユーザがフォルダ内に写真を配置した後にそれらを検索する時に、バックグラウンドでプラグイン関数が実行していることに気付く必要はない。デバイス７６０または別のコンピュータデバイスによって提供される標準ユーザインターフェースを用いて、フォルダ７７１に写真を配置するために、ドラッグ、ドロップ、選択など、様々な技術のどれがユーザによって用いられてもよい。具体的な一実施形態において、ユーザは、ログインして、ハイレベルフォルダを表示し、フォルダ７７１を選択し、ヘールの写真をそのフォルダにアップロードするために、図１１Ａの工程８０２〜８２４を実施してよい。写真は、ユーザの電話、Ｄｒｏｐｂｏｘなどのアーカイブ、または、任意の他のリモート位置に由来してよい。

工程８０２〜８２４は、この例のために変形されてよい。ユーザは、写真をフォルダ内に配置する前に（上述したように）フォルダ７７１を最初に開いてもよいし、図１４Ａに示すような状態のフォルダ７７１に、単にドラッグまたは他の方法で写真を配置してもよい。特に、プラグイン関数”Ｐｈｏｔｏ”が入力写真を処理する工程８２４は、以下のように変形される。関数は、写真を受信し、位置（例えば、Ｘ−Ｙ座標、経度、緯度など）のようなメタデータと、タイムスタンプとを抽出する。次に、関数は、バックエンドサービス（Ｇｏｏｇｌｅ位置サービスなど）に位置データを送信し、バックエンドサービスは、位置データを取り込んで、写真が撮られた場所（例えば、”ベルギーのヘール”）を示す文字列を返す。次いで、関数は、この場所の文字列を取り込んで、オブジェクトストア２２０内に写真と共にメタデータとして格納する。この時点で、写真は格納されており、以下で記載するように検索およびリトリーブに利用可能である。もちろん、プラグイン関数”Ｐｈｏｔｏ”は、開発者の望む任意の他の処理工程を取ってもよく、同じ方法で（少なくとも）数千枚の写真を格納してもよい。そして、プラグイン関数によって生成またはリトリーブされた任意のその他の様々なメタデータが、写真またはその他のデジタルオブジェクトと共に格納されてもよい。

後に、ユーザ（または任意のその他のユーザ）が、写真の撮影場所を示す検索語を用いて、関数”Ｐｈｏｔｏ”によって格納された全写真を検索したくなる。したがって、ユーザは、工程７０２〜７０６または８０２〜８０４に記載したように、ログインしてユーザのデバイスで利用可能なフォルダ（すなわち関数）を見るための工程を行う。図１４Ａは、ユーザのデバイス７６０がフォルダＰｈｏｔｏ７７１をどのように表示するのかを示す。

図１３の工程９０２において、ユーザは、写真を見つけるための検索語を提供するために、フォルダＰｈｏｔｏ７７１内の適切なフォルダにナビゲートする。ユーザは、図１４Ａのフォルダ７７１を選択し、そのファブフォルダが、工程７０８〜７１２で上述したのと同様に表示される。図１４Ｂは、フォルダ”Ｐｈｏｔｏ”が選択された後にデバイス７６０がどのようになるのかを示しており、フォルダ９２０（１つ上のレベルに移行するために用いられる）および子フォルダ”Ｑｕｅｒｉｅｓ”９２２が表示されている。関数の開発者は、フォルダ”Ｐｈｏｔｏ”内に永久的に存在し、その名称が検索語として用いられるサブフォルダを保持するように、フォルダ”Ｑｕｅｒｉｅｓ”を作成している。プラグイン関数”Ｐｈｏｔｏ”は、任意のかかるサブフォルダの名称が実際に、写真を見つけるために用いられる検索語であることを知っている（むしろ、開発者が知っている）。もちろん、開発者は、フォルダ”Ｑｕｅｒｉｅｓ”を省いて、ユーザがフォルダ”Ｐｈｏｔｏ”の中にサブフォルダを直接作成することを可能にしてもよい。

次に、工程９０４において、ユーザは、ベルギーで撮影した任意の写真を見つけるために、ストレージに保存されたすべての写真の検索の実行しようとする。したがって、ユーザは、”Ｃｒｅａｔｅ Ｆｏｌｄｅｒ（フォルダの作成）”オプション９２６を選択するために、オプションドロップダウンメニュー９２４を開く。新規フォルダが、デバイス、オペレーティングシステム、および、プレゼンテーションアプリケーションに応じて、様々な標準ユーザインターフェース技術を用いて特定のコンピュータデバイス上で作成されてよい。ユーザは、ブラウザ内のボタンをクリックする、オペレーティングシステム内、または、ディスクドライブアイコン上、フォルダ内で”右クリック”を実行する、などしてよい。この例において、ユーザは、メニュー９２４を見るために、ＷｅｂＤＡＶ Ｎａｖ＋アプリケーション内のオプションを選択する。ユーザは、”Ｑｕｅｒｉｅｓ”フォルダを開いた後にその中に新規フォルダを作成するようにも選択してもよいが、この例の文脈では、任意の新規フォルダがフォルダ９２２内に作成される。

ユーザがオプション９２６を選択すると、ユーザが検索語を入力することを可能にする空白のサブウィンドウ９２８が開く。ユーザは、格納された写真すべてに検索語として用いる新規サブフォルダの名称として文字”ｂｅｌ”をタイプする。次いで、ユーザは、「リターン」を押すか、または、他の方法で入力を終え、”Ｃｒｅａｔｅ Ｆｏｌｄｅｒ”コマンドおよび名称”ｂｅｌ”が、プラグイン関数”Ｐｈｏｔｏ”に送信される。

工程７１０、７１６〜７３２、および、７１２において、”ｌｉｓｔ”コマンドがパスと共にプラグイン関数に送信されたのと同様に、工程９０６において、クライアントデバイスは、パス”Ｐｈｏｔｏ／Ｑｕｅｒｉｅｓ／ｂｅｌ”と共に”ｍｋｄｉｒ”コマンドをプラグイン関数に送信し、プラグイン関数は、このコマンドおよびパスを、”ｂｅｌ”と名付けた”Ｑｕｅｒｉｅｓ”の下の新規フォルダを作成する要求として解釈する。また、関数は、文字列”ｂｅｌ”が検索のための引数としても用いられることを知っている。したがって、サーバによって生成される応答は、”Ｑｕｅｒｉｅｓ”の下のこの新規サブフォルダのリスト化である。図１４Ｃは、この時点でデバイス７６０がどのようになるか、すなわち、新規サブフォルダ”ｂｅｌ”９３２を表示する様子を示す。そのユーザに関する限り、サブフォルダ”ｂｅｌ”は今、文字列”ｂｅｌ”を含む場所で撮影されて以前に格納されたすべての写真を含む。ただし、具体的な一実施形態において、プラグイン関数が行ったことは、サブフォルダ”ｂｅｌ”を作成してそのキャッシュに格納したことだけである。サブフォルダは、ユーザがまだサブフォルダを選択またはその他の方法で開いていないので、まだ写真を全く含まない。しかしながら、別の実施形態において、このサブフォルダには、以下に記載するように、サブフォルダが作成された時にこの工程で適切な写真が投入されてもよい。例えば、プラグイン関数は、（ユーザがサブフォルダを開く前に）サブフォルダ”ｂｅｌ”が作成された時に写真を検索してリトリーブし、そのキャッシュに写真を格納する。この実施形態は、ユーザが開かない写真をリトリーブしうるので、効率が悪い。

工程９０８において、ユーザは、ベルギーで撮影したすべての写真を見たいと思い、したがって、フォルダ９３２を選択する。このフォルダが開かれ、プラグイン関数が工程９１０で再び実行し、プラグイン関数”Ｐｈｏｔｏ”に独特な方法で引数”ｂｅｌ”を用いて処理が行われることを除けば、工程７４０〜７４４に関して上述したのと同様に、結果が返される。関数が実行され、パス”ｐｈｏｔｏ／Ｑｕｅｒｉｅｓ／ｂｅｌ”およびコマンド”ｌｉｓｔ”を受信すると、検索語”ｂｅｌ”を含むメタデータの場所文字列を有するストレージ内のすべての写真の名称を返さなければならない、したがって、サブフォルダの名称を引数として用いて写真の名称を返さなければならないことを知る。関数は、開発者が関数をどのようにプログラムしたかに応じて、写真の名称、サムネイル、ＪＰＥＧファイル全体、などを返してよい。

好ましくは、関数は、名称のリストを提示するのに十分な情報を返すが、必要な時に後で写真をすばやくリトリーブするために、写真のコンテンツアドレス（ＵＵＩＤ−汎用一意識別子）またはＵＲＬなど、何らかの内部情報も格納してよい。したがって、プラグイン関数は、サムネイルなど、写真についての中間（メタ）情報を格納できるが、返されるリストは、名称、サイズ、修正日またはＰＯＳＩＸモードフラグ、保存時刻、および、リソースなど、基本的なプロパティを含むだけでよい。変形例において、関数の開発者によっては、関数が、”ｂｅｌ”引数に応答して実際の写真を返すことが可能であるが、これは必須ではない。

したがって、関数は、上述したベルギー（Ｂｅｌｇｉｕｍ）のヘールで撮影された写真の名称と、検索語を含む任意のその他の写真（ベラルーシ（Ｂｅｌａｒｕｓ）で撮影された写真など）の名称とを返す。ユーザは、サブフォルダ”Ｂｅｌｇｉｕｍ”と名付けることによって、ベルギーでの写真だけを排他的に検索できる。フローは、写真名がクライアントデバイスに返されると終了する。図１４Ｄは、写真の名称が返されるとデバイス７６０がどのようになるのかを示す。図示されていないが、ユーザは、この時点で、任意のファイルを開く技術（図１０Ｅまたは１２Ｅに関して上述した技術など）を用いて、ダウンロードするかまたは表示のために開く写真９３４を選択してよい。したがって、写真は、実際に選択されるまでユーザデバイスにダウンロードされる必要がなく、選択された時点で”ｇｅｔ”が実行される。

もちろん、ユーザがフォルダ（または、さらに言うなら文書）を作成し、プラグイン関数の利用および実行の際にメタデータとして機能的に利用される名称をそれに与える多くの他の状況がある。例えば、周知のＩＭＤＢ国際ムービーデータベースへの公共のデータインターフェースを用いる関数”ｉＭＯＶ”においては、図１３および図１４に記載したのと同様のメカニズムが用いられる。ユーザが、”Ｂｅａｒ”という名称のフォルダを作成すると、タイトルにテキスト文字列”Ｂｅａｒ”を有するすべてのムービーのリストが、中に表示される。あるいは、名称”ＰＤＦ”を有するフォルダを備えた関数が、フォルダ内にドロップされたファイルをＰＤＦファイルへ変換するか、または、出力をＰＤＦファイルへ変換し、このように、プラグイン関数への引数として”ＰＤＦ”を利用する。

別の技術では、キー／値ペアの形態で（対象のフォルダ内の隠しファイルに格納された）関連メタデータプロパティを有するフォルダのエンドユーザによる作成を可能にする。プラグイン関数”Ｖａｃａｔｉｏｎｓ”内に、ユーザは、”２０１６”という名称のフォルダを作成する（工程９０２〜９０６を用いて、パス”／ｖａｃａｔｉｏｎｓ／２０１６”およびコマンド”ｍｋｄｉｒ”を送信する）。この例において、関数”Ｖａｃａｔｉｏｎｓ”は、ユーザによって指示されたように新規フォルダを作成し、ユーザによってフォルダにドラッグされた写真を受け入れ、写真にメタデータプロパティを追加し、その後、その写真をそのメタデータプロパティと共にオブジェクトストアに格納するようにプログラムされる。

新規フォルダ”２０１６”がユーザに返されると、マイクロウェブサーバが、工程６４４〜６５２のように作成され、ユーザは、その新規フォルダのためのメタデータプロパティ”ｖａｃａｔｉｏｎ ｔｙｐｅ”の値（”ｂｅａｃｈ”など）を入力することを許容され、すなわち、キー／値ペアは、”ｖａｃａｔｉｏｎ ｔｙｐｅ？／ｂｅａｃｈ”である。したがって、関数は、フォルダ”２０１６”に関連する値”ｂｅａｃｈ”を提供される。したがって、任意のオブジェクト（例えば、写真）がそのフォルダにアップロード（またはドラッグ）されると、そのオブジェクトは、値”ｂｅａｃｈ”で「スタンプされ」、”ｖａｃａｔｉｏｎ ｔｙｐｅ”＝”ｂｅａｃｈ”をそのオブジェクトのメタデータヘッダとして用いて、オブジェクト格納システム（例えば、Ｃａｒｉｎｇｏ Ｓｗａｒｍオブジェクトストア）に送信され、そこに格納される。関数は、フォルダ”Ｖａｃａｔｉｏｎｓ”にオブジェクトを格納せず（すなわち、フォルダを開いても何も表示されない）、オブジェクトは、ストレージに直接送信される。したがって、その後、そのメタデータプロパティは、オブジェクトストア内のオブジェクトをクエリするために利用できる。例えば、図１３に記載したような関数”Ｐｈｏｔｏｓ”または同様の関数は、検索文字列を入力するために用いられてよく、関数は、検索文字列を用いて、オブジェクトストア内のオブジェクトのメタデータヘッダを検索する。

オブジェクトの書き込みに関する変形例において、関数”Ｖａｃａｔｉｏｎｓ”は、図８Ｂのようにデーモンとして実行する必要はなく、ユーザは、メタデータプロパティの値”ｂｅａｃｈ”を提供するためにマイクロウェブサーバと相互作用する必要はない。関数”Ｖａｃａｔｉｏｎｓ”は、任意の作成されたサブフォルダの名称を、任意の追加された写真上に「スタンプされた」メタデータプロパティ値として用いるようプログラムされている。したがって、ユーザは、”Ｖａｃａｔｉｏｎｓ”の下のサブフォルダ”ｂｅａｃｈ”を作成し、関数によってプログラムされたように、キー”ｖａｃａｔｉｏｎ ｔｙｐｅ”＝｛ＰａｒｅｎｔＦｏｌｄｅｒ｝である。写真をフォルダ”ｂｅａｃｈ”にアップロードすると、その写真に関連するメタデータキー／値ペアは、”ｂｅａｃｈ”になり、次いで、Ｃａｒｉｎｇｏ Ｓｗａｒｍに格納された写真は、キー／値メタデータペアとして投入された”ｖａｃａｔｉｏｎ ｔｙｐｅ” ＝”ｂｅａｃｈ”を有することになる。

任意の数のユーザが、このようにタグ付けされた写真をオブジェクトストアへアップロードしてよく、任意の数のユーザが、プラグイン関数を用いてオブジェクトストア内の写真を検索してよい。本発明は、任意の数のユーザに対して容易に規模を変える。

同様の例において、プラグイン関数は、ユーザがテキスト文書をケース名または番号を備えたフォルダにドロップすることを可能にする。各文書は、自動的にその名または番号を「スタンプ」され、オブジェクトストアに格納される。任意の文書のリトリーブが、（図１３のように）検索文字列をフォルダ名として提供されたプラグイン関数または最小限のユーザ入力のためのマイクロウェブサーバを有するデーモンモードのプラグイン関数を用いて実行される。

キャッシングサブシステム
本発明の別の実施形態は、無限のストレージに見えるものを（プラグイン関数の開発者の観点から）提供するキャッシングサブシステムを提供し、したがって、ディスク容量がキャッシングサブシステムによって動的に割り当てられるので、ディスクがいっぱいになることを開発者が心配する必要がなくなる。

ディスクがいっぱいになることは、しばしば、管理者（および開発者）にとって困難な問題になる。通例、ディスク上のローカルフォルダは、限られた量のバイトスペース（すなわち、ファイルデータのためのスペース）、および、限られた量のアイノードスペース（ディスク上に格納できるファイルおよびフォルダの数（オブジェクト数の限界）を制限する）を有する。アプリケーションは、通常、ディスクがいっぱいになると、機能しなくなる以外にはほとんど選択肢がない。（ＣＰＵ、メモリ、および、帯域幅のような）ディスク容量は、管理者が注意深く管理する必要がある貴重なリソースであり、さもなければ、そのユーザアプリケーションが機能を停止する。ほとんどの場合、ディスクがいっぱいになると、アプリケーションは、ユーザにメッセージを表示する。一部の例では、アプリケーション（またはサーバー）は、単にクラッシュする。ホストによっては、管理者は、これに対処する選択肢をほとんど持っておらず、何もしないことが最適であり、例えば、ＬｉｎｕｘＬＶＭは、複数のディスクにわたってファイルシステムを拡張することを可能にするが、これは、スペアディスクと、これらのディスクを置く余分なサーバスペースがある時にだけ役立つ。多くの場合、高価なディスクアレイおよびｉＳＣＳＩが、問題解決のために用いられる。予測できない量のデータが収集および格納されるサービス（すなわち、サーバ）を実行している場合、この問題は、極度に困難になるか、莫大な費用が掛かるか、または、その両方である。オブジェクトストアは、非常に多くの拡張性があり、管理しやすく（拡大しやすく）、コスト効率のよいストレージリソースであるが、ファイルシステムインターフェースを持たない。

我々のソリューションは、アプリケーション（プラグイン関数またはサーバ１５０）とオブジェクトストレージとの間のバッファとしてローカルディスク２１０（例えば、高速ソリッドステートディスク）を利用し、プラグイン関数にファイルシステムインターフェースを提示しつつオブジェクト格納技術を用いて実際にファイルを格納することである。ファイルシステムの容量を最終的に決定するのは、バックエンドオブジェクトストアの容量であるが、我々の実装は、オペレーティングシステムが許容する限り大きくファイルシステムの容量を開発者に利用できるようにするものであり、これは、すべての実際的な目的にとっては無限である。もちろん、管理者はそれでも、オブジェクトストアの容量および利用を管理しなければならないが、この管理は、実際のサーバストレージまたはディスクのｉＳＣＳＩアレイよりもずっと容易であり、はるかにコスト効率がよい。

特に、後述するように、サーバ１５０の中のＦＵＳＥ（オープンソースライブラリ）を用いてファイルシステムを実装し、３つの既知のサブフォルダを備えたローカルフォルダが単に見えるファイルシステムをプラグイン関数プロセスに提示する。ＦＵＳＥは、Ｌｉｎｕｘファイルシステムを実装するが、その他のファイルシステムおよびインターフェースが用いられてもよい。プラグイン関数は、ＦＵＳＥを間接的かつトランスペアレントに利用し、開発者は、ＦＵＳＥに関して何も知る必要がない。

これらの関数からのファイルＩ／Ｏはすべて、ローカルディスクへの書き込みまたはローカルディスクからの読み出しを行う時に、専用のキャッシングサブシステムコードを用いて処理される。下層のローカルディスクにアクセスするので、キャッシングサブシステムモジュール１００２も、ディスクがどれだけ満たされたのかを見るために、ディスクの容量を管理することもできる。より多くのスペースを必要とする場合、モジュール１００２は、ファイルの「エビクト」（スワップアウト）を開始し、必要な時、すなわち、キャッシュ２１０に存在しないファイルがＦＵＳＥを介して要求された時に、ファイルを戻すことができるように、各ファイルのコピーがまだオブジェクトストア２２０内にあることを確認する。プラグイン関数は、このファイル管理には気付かない。したがって、最も長い間利用されていないファイルをキャッシュからエビクトするので、関数には、キャッシュの利用可能なストレージが無限に大きいように見せることができる。

この実施形態は、各プラグイン関数に無限のストレージを提供するのに役立ち、バックサイドキャッシングとして知られ、サーバ１５０によって利用される第２実施形態は、ユーザごとに独自のビューを提供し、フロントサイドキャッシングとしても知られる。フロントサイドおよびバックサイドキャッシングは、この「無限の」ストレージを利用できるアプリケーションである。それらは両方とも、ローカルディスクの一部をキャッシュとして利用するが、それらのファイルは、最終的にはリモートオブジェクトストア２２０内に格納されてよい。主な違いは、通例は、バックサイドキャッシングで格納されたファイルの方がフロントサイドキャッシングで格納されたファイルよりもキャッシュ内に長く存在することである。バックサイドファイルは、プラグイン関数の開発者によって決定されたように格納され、後述するように、必要に応じてオブジェクトストアに移動されてよい。フロントサイドファイルは、有効期限（例えば、（開発者によって決定されたように）２４時間）を有してよく、フロントサイドファイルが有効期限を有しており、まだ期限が切れていないがスペースが必要である場合に、かかるファイルは、一時的に、オブジェクトストアへスワップアウトされる。フロントサイドファイルがすでに期限切れである場合、エビクトされるとオブジェクトストアに格納されない。

キャッシングサブシステムのブロック図
図１５は、キャッシングサブシステム１０００のブロック図である。上述した仮想マシン１３６、サーバ１５０、キャッシュ２１０、および、オブジェクトストア２２０が示されている。ローカルな直接接続されたディスク２１０は、短期間の一時的なファイルストレージを提供する一方で、ネットワーク接続されたオブジェクトストア２２０は、いわゆる「バケット」内に長期間の永続的なストレージを提供する。一般に、キャッシュは、容量に制限があるが、実際的な目的にとっては、オブジェクトストレージ内のバケットは、プラグイン関数の観点からは無限の容量に見える。キャッシュは高速かつ高価である一方で、オブジェクトストレージは低速であるがコスト効率がよい。キャッシングサブシステムモジュール１００２は、後述の機能を実装するソフトウェアコードであり、他のサーバモジュールがファイルの読み出しまたは書き込みならびにフォルダの管理を行うためのＡＰＩを有する。プラグイン関数は、例えば、プラグイン関数が、ローカルまたはリモートディスク上の階層ファイルシステムにファイルを格納することを可能にするＡＰＩ（ＰＯＳＩＸなど）を利用する。ローカルフォルダ１００４は、仮想マシンホストに直接接続されたディスク２１０上にあるファイルシステム上の通常のフォルダである。ディスク技術は、高速Ｉ／Ｏおよび低遅延アクセスのためのタイプＳＳＤまたは等価物の技術であってよい。

キャッシングサブシステムモジュール１００２は、図４のキャッシングモジュール３２４およびオブジェクトストレージモジュール３２８を備える。上述のように、キャッシングモジュール３２４は、任意のプラグイン関数がファイルシステムを用いてキャッシュ２１０にファイルを格納できるように、ファイルシステムを実装するためにＦＵＳＥオープンソースソフトウェアを利用する。このファイルシステムを用いて、プラグイン関数は、ログインした特定のユーザのコンテキストで（一時ファイルのためのフォルダに加えて）２つのフォルダにアクセスできる。一方のフォルダは、プラグイン関数が特定のユーザのデータのみを書き込むことのできるユーザ固有のフォルダであり、もう一方のフォルダは、任意のユーザのためにプラグイン関数が利用できる関数固有のフォルダである。ユーザ固有のフォルダの利点は、ユーザのデータがうっかり上書きされないことが保証される点である。一実施例において、ファイルシステムは、オブジェクトストアおよびキャッシュの上の層に提供される。

オブジェクトストアモジュール３２８およびキャッシングモジュール３２４は、１または複数の特定のディスクがいっぱいになるか否かを追跡することなど、それぞれのデータリポジトリのすべての管理面を扱うので、各プラグイン関数は、プラグイン関数の観点からは、無限のストレージに見えるものを提供される。プラグイン関数の開発者は、その視点からはディスク容量の追跡を気にする必要はなく、データを無限に格納し続けてよい。より多くのディスクスペースが必要な場合、オブジェクトストレージモジュールまたはキャッシングモジュールのいずれかが、より多くのディスクスペースを割り当てる責任を負い、プラグイン関数は、このタスクを実行する必要がない。

図１６は、キャッシングサブシステムモジュール１００２を実装するために用いられるインメモリキャシュオブジェクト１００８の表現を示す。キャッシュオブジェクト（タイプＣａｃｈｅのクラスに対応するサーバメモリ内のＲＡＭのインスタンス化されたチャンクを意味する）は、ローカルフォルダプロパティおよびバックエンドオブジェクトストアプロパティを備えるよう構成される。インメモリキャシュオブジェクトは、内部コンポーネントが呼び出しを行うための呼び出し可能なＡＰＩ １０１０を有し、リモートオブジェクトストレージシステム（例えばオブジェクトストア２２０）のクライアントである１または複数のオブジェクトストレージプロキシオブジェクト１０１２、１０１３、および、１０１４を埋め込む。多くのかかるリモートシステムが存在しうるが、通例、一度にアクティブにされるのは、１つのリモートオブジェクトストレージシステムだけである。モジュールは、様々なタイプのリモートオブジェクトストア（Ａｍａｚｏｎ Ｓ３、Ｃａｒｉｎｇｏ Ｓｗａｒｍ、または、Ａｚｕｒｅ Ｂｌｏｂなど）をサポートする。リモートストア実装例は、キャッシュ実装を容易にするために、ストアインターフェースの背後では抽象的である。フロントサイドおよびバックサイドキャッシングの両方が、同じキャッシュオブジェクトのインスタンスを用いる。ＡＰＩ １０１０がファイルデータの書き込みに用いられると、キャッシュオブジェクト１００８は、次にローカルディスク２１０にファイルデータおよび関連メタデータを書き込む。動作が完了するとすぐに、動作（書き込みまたは読み出し）の結果が、呼び出し元に返される。バックグラウンドで、キャッシングサブシステムモジュールは、後述するように、必要に応じて新しいデータをリモートオブジェクトストアに書き込む。

サーバ１５０は、バックサイドキャッシングを利用するプラグイン関数とは異なり、ユーザ要求を処理する時に、ＡＰＩ １０１０をインラインで呼び出すことによって直接的にフロントサイドキャッシングを利用する。サーバは、通例、関数（ＧＥＴ）からリトリーブされた後、または、関数（ＰＵＴ）に進む前に、フロントサイドキャシングで文書を格納している。要求がエンドユーザによってなされ、ユーザが見るビューを反映するエンドユーザごとのフロントサイドキャッシュ部分がある。フロントサイドおよびバックサイドキャッシングは両方とも、キャッシュサブシステムモジュール内に実装され、サーバプロセス内で実行する。プラグイン関数プロセスは、サーバプロセスとは異なるので、ファイルシステムを介して（後述のカーネルおよびＦＵＳＥを介して）バックサイドキャッシングを利用可能にする。フロントサイドキャシングは、サーバによって直接アクセスされ、ＦＵＳＥ層を利用しない。フロントサイドキャッシングは、ＨＴＴＰ ＧＥＴ／ＰＵＴ要求を処理するパスにある。バックサイドキャッシングは、ファイルＩ／Ｏ要求を介して関数によって利用され、開発者の自由である。

図１７は、バックサイドキャッシングアーキテクチャのブロック図である。サーバ１５０、関数１６０、および、その他のコンポーネントが示されている。上述のように、サーバおよびプラグイン関数は、異なるプロセスである。関数が利用できるストレージを提供するのはサーバであるが、サーバは、マウントポイント１０２０を介して、ひいては、オペレーティングシステムのカーネルを介して、それを行う。Ｌｉｎｕｘカーネルの一部であり、サーバ１５０が自身のプロセス内に真のファイルシステムを実装することを可能にするＦＵＳＥ（ｆｉｌｅ ｓｙｓｔｅｍ ｉｎ ｕｓｅｒ ｓｐａｃｅ：ユーザ空間内のファイルシステム）オープンソース技術を利用する。ＦＵＳＥは、ユーザ空間部分１０２４およびカーネル空間部分１０２２を備える。

任意のプラグイン関数プロセス１６０にとっては、単に読み出しおよび書き込みできる１セットのフォルダが与えられているかのように見える。しかし、それらの読み出しおよび書き込みの要求を処理するのはサーバである。サーバは、これらのファイルシステム要求すべてを処理するので、その内部キャッシングサブシステムモジュールを用いて、マウントポイントがプラグイン関数プロセスの観点からは無限の容量を有するかのように見せることができる。関数の開発者もシステム管理者も、ディスクがいっぱいになることを心配する必要はなく、したがって、プラグイン関数を用いて開発者および管理者にとってのあらゆる障壁を下げようとする我々の試みに明らかな利点を提供する。

図１８は、プラグイン関数にとって利用可能なフォルダの象徴的に示すブロック図である。サーバ１５０は、モジュール１００２を介して、これらのフォルダをローカルキャッシュ２１０にマッピングし、キャッシュからリモートストレージ２２０にマッピングする。無限に見えるストレージ容量を提供することに加えて、サーバ１５０は、データへのアクセス制御も提供し、関数によって誤って上書きされないようにユーザデータを保護する。関数によって見られる無限ストレージは、１セットのフォルダを露出させる単一のマウントポイント１０２０である。マウントポイント１０２０は、関数１６０に、以下の３つのサブフォルダ１０３２、１０３４、および、１０３６を有するローカルフォルダ１００４を提示する：一時ファイル用サブフォルダ１０３２、関数所有状態のサブフォルダ１０３４（ユーザがＩ／Ｏ要求を行うのとは無関係に、関数がデータの書き込みまたはデータの読み出しを行うことができる関数によって所有された共有ファイル）、および、ユーザ所有状態のサブフォルダ１０３６（Ｉ／Ｏ要求を行うユーザによって所有されたフォルダであり、そのユーザによってのみアクセス可能であり、他の誰もアクセスできない）。各々が関数を呼び出す多くのユーザが存在しうるため、数多くのユーザフォルダ１０３６〜１０３８が示されている。特に、プラグイン関数は、”／ｍｎｔ／ｓｔｏｒａｇｅ”１００４およびこれらのサブフォルダを見る：
／ｍｎｔ／ｓｔｏｒａｇｅ／ｔｅｍｐｄｉｒ：一時ファイルのためのスクラッチ領域
／ｍｎｔ／ｓｔｏｒａｇｅ／ｆｕｎｃｔｉｏｎ：関数共有状態
／ｍｎｔ／ｓｔｏｒａｇｅ／ｐｒｉｖａｔｅ：ユーザごとのプライベート状態

このアーキテクチャの重要な結果は、各プラグイン関数が、同じマウントポイント１０２０と、それの同じ３つのフォルダ（一時ファイル、関数所有状態、および、ユーザ所有状態のためのフォルダ）とを見る一方で、関数の開発者は、ユーザが実際に誰なのかも、関数が実際に実行されているのかも気にする必要がないことである。関数は、単に、マウントポイントから読み出しまたはマウントポイントに書き込みできる。かかる階層も存在しうる古典的なファイルシステムまたはファイルサーバでは、ファイルおよびサブフォルダが、容易に上書きされうる。このアーキテクチャにおいて、可視状態のフォルダは、これらのフォルダが一定の周知の名称を有するにもかかわらず、真に一意的であり、要求およびその要求を行うユーザに依存する。関数固有またはユーザ固有の状態のみが、これらのフォルダ１０３４および１０３６に存在する。ユーザＸのために実行する関数が、ユーザＹに属するデータをリスト、読み込み、書き出し、または、上書きすることは不可能である。関数Ａが、関数Ｂの状態をリスト、読み込み、書き出し、または、上書きすることもできない。さらなる詳細を以下に提供する。以下に記載のパス名スキームは、関数がそのユーザのために実行されているユーザにとって、フォルダ／ｍｎｔ／ｓｔｏｒａｇｅ／ｐｒｉｖａｔｅが真にプライベートであることを保証する。したがって、ユーザのプライベートデータは、その関数が別のユーザのために実行している間に、上書きされることがない。

キャッシングサブシステムユーザファイルおよびプレフィックスパス名
各関数のプロセスは、要求を行うユーザのために呼び出される。例えば、関数にＰＵＴ要求をするユーザが、そのユーザのために関数を呼び出させる。これが意味するのは、要求を行うユーザにＵＩＤが対応し、アドレスされる関数にＧＩＤが対応するように、その関数プロセスのＵＩＤおよびＧＩＤプロパティが設定されることである。これらのＵＩＤ／ＧＩＤ番号は、一時的なものである。サーバが、ＧＩＤ番号を関数に割り当て、ＵＩＤ番号を認証されたユーザセッションに割り当てるが、これらの番号は、サーバおよびカーネル内のメモリにのみ存在する。それらは、永続的ではない。

サーバは、プラグイン関数のためのプロセスをフォークする時、そのプロセスのＵＩＤおよびＧＩＤプロパティを設定する。露出されたマウントポイントに対して関数プロセス内でなされる任意のファイルシステムコールが実行されるので、ＵＩＤ／ＧＩＤペアのために、各Ｉ／Ｏ要求について、そのペアは、ＦＵＳＥ層を通してサーバに返される。サーバに戻り、ユーザｕｕｉｄおよび関数ｕｕｉｄを見つけるために、ＵＩＤ／ＧＩＤペアに関する対応するランタイムオブジェクトを見つける。シェアｕｕｉｄおよびテナントｕｕｉｄと共に、サーバは、後述するように、キャッシュサブシステムおよび対応するリモートストレージに適切にアクセスするために必要な全情報を有する。

オブジェクトストレージシステムには、多くの欠点があり、ユーザデータファイルならびにファイル関連およびフォルダ関連のメタデータがキャッシングサブシステムによってオブジェクトストレージに直接書き込まれない理由になっている。オブジェクトストレージシステムは、オブジェクト階層を有するように見えるが、実際には、名称に可能な”／”文字を有するフラットネームスペースを提示する。さらに、オブジェクトストレージバケットは、ファイルシステムのような動作も意味論も持たず、通例は、”ｍｏｖｅ”または”ｒｅｎａｍｅ”動作を欠く。そして、ＰＯＳＩＸ拡張属性と同様のファイル関連メタデータ動作へのサポートがない。さらに、リモートバケットに格納される前に、データおよびメタデータを圧縮および暗号化できることが望ましい。関数、ユーザ、シェア、および、テナントのレベルの全ストレージを、しかも、同じバッキングオブジェクトストアをいずれもが用いる複数のサーバ全体にわたって、考慮できる必要もある。

キャッシングサブシステムモジュールは、これらの問題に対処する。データは、ローカル接続されたディスク上で暗号化および圧縮されずに存在するが、ファイルがリモートに格納される時、サーバは、それらをオブジェクトストレージに送信する前にすべてのファイルを最初に暗号化および圧縮する。ファイルがオブジェクトストレージから読み出される時に、逆の動作が実行される。

フォルダ情報ならびにファイルおよびフォルダのメタデータが、ロースタファイルにパッキングされる。ロースタファイルは、効率的な格納およびメタデータへの高速アクセスを可能にするカスタムバイナリフォーマットである。ロースタファイルは、エンティティ名、モード、作成タイムスタンプなど、標準的なＰＯＳＩＸ属性を含むが、サーバに固有のカスタムメタデータプロパティもエンコードする。ロースタファイルは、ファイルデータを全く含まない。各ユーザファイルは、個別に格納されるが、その真のファイル名（例えば、”Ｗｏｒｋｓ Ｓｈａｋｅｓｐｅａｒｅ”）は、ロースタファイルに記録され、システムが、リモートに格納する時に各ユーザファイルに用いる代替名（汎用一意識別子（ＵＵＩＤ）など）を利用することを可能にする。このソリューションの二次的な利点は、リモートに情報を格納する時に、ユーザデータおよびユーザメタデータの両方を機密にできることである。したがって、ロースタファイルは、ファイルおよびサブフォルダの名称と、ＵＵＩＤに対する名称のマッピングとを含むシリアライズされたフォルダである。それらは、バイナリシリアライゼーションフォーマットを利用し、オブジェクトストレージに格納する前に暗号化および圧縮される。キャッシングサブシステムモジュールも、必要とされるファイルシステムのような動作（”ｍｏｖｅ”および”ｒｅｎａｍｅ”など）を実装する。サブシステムＡＰＩ １０１０は、フォルダをまたぐ動作、標準および拡張メタデータの管理、および、ネームスペース動作など、すべてのファイルシステムのようなプロパティを提供する。

ローカルディスク２１０上およびリモートバケット２２０内には、ＵＵＩＤを名称としたオブジェクトのみが存在する。リモートオブジェクトが暗号化および圧縮される一方で、ローカルオブジェクトは復号され未圧縮であるが、ローカルディスク上でもオブジェクトストレージ内でも、ファイルの一意名は（ユーザファイルおよびロースタファイルの両方について）、同じＵＵＩＤを有する。すべてのファイルおよびフォルダ動作は、フォルダオブジェクトのコンテキストで行われる。任意のフォルダが、何らかの階層に属する。階層は、パスにプレフィックスを付けることによって形成された指定ルートから始まる。

オブジェクト（ユーザファイルおよびロースタファイル）をリモートバケット２２０に格納する時、フォルダ階層のためのルートを形成する４つのパスコンポーネントをオブジェクト名のプレフィックスにする。オブジェクト名の一例は、ＵＵＩＤに拡張子（“．ｆｏｌｄｅｒ”（ロースタファイル用）または“．ｆｉｌｅ”（ユーザファイル用）など）を追加したものである。オブジェクト名は、ローカルキャッシュに格納されてもオブジェクトストアに格納されても、４つのパスコンポーネントをプレフィックスとして付けられる。サーバに入る要求は、最初に認証および許可される。ユーザが誰であるかわかると、そのＵＵＩＤもわかり、要求は特定のシェアになされるので、そのシェアのＵＵＩＤ、および、そのシェアを所有するテナントのＵＵＩＤもわかる。各要求の第１パスコンポーネントは、関数ＵＵＩＤを提供する関数に対応する。したがって、各要求に対して、すべての４つのＵＵＩＤを見つけて、プレフィックスを形成することができる。最上位パスコンポーネントは、テナントＵＵＩＤである。次のパスコンポーネントは、シェアＵＵＩＤである。シェアＵＵＩＤの下には、関数ＵＵＩＤまたはユーザＵＵＩＤの組みあわせがある。可能なプレフィックス付きパスは：
ｔｅｎａｎｔ−ｕｕｉｄ／ｓｈａｒｅ−ｕｕｉｄ／ｕｓｅｒ−ｕｕｉｄ／ｕｓｅｒ−ｕｕｉｄ
ｔｅｎａｎｔ−ｕｕｉｄ／ｓｈａｒｅ−ｕｕｉｄ／ｆｕｎｃｔｉｏｎ−ｕｕｉｄ／ｆｕｎｃｔｉｏｎ−ｕｕｉｄ
ｔｅｎａｎｔ−ｕｕｉｄ／ｓｈａｒｅ−ｕｕｉｄ／ｆｕｎｃｔｉｏｎ−ｕｕｉｄ／ｕｓｅｒ−ｕｕｉｄ

２つの”ｕｓｅｒ−ｕｕｉｄ”を備えた最初のプレフィックスは、ユーザごとのフロントサイドキャッシングに関連するファイルおよびフォルダに用いられる。すべてのユーザが、関数ならびにそのファイルおよびフォルダの独自のビューを有する。このビューは、プレフィックス”ｔｅｎａｎｔ−ｕｕｉｄ／ｓｈａｒｅ−ｕｕｉｄ／ｕｓｅｒ−ｕｕｉｄ／ｕｓｅｒ−ｕｕｉｄ”を備えたキャッシュに格納される。

２つの他のプレフィックスは、バックサイドキャッシングに用いられる。関数によって見られる無限ストレージは、上述のように、３つの既知のフォルダのセットを露出させる単一のマウントポイントである。関数フォルダに書き込まれるオブジェクトは、ｔｅｎａｎｔ−ｕｕｉｄ／ｓｈａｒｅ−ｕｕｉｄ／ｆｕｎｃｔｉｏｎ−ｕｕｉｄ／ｆｕｎｃｔｉｏｎ−ｕｕｉｄパスをプレフィックスとして付けれ、一方、関数内のユーザごとのフォルダに書き込まれるオブジェクトは、ｔｅｎａｎｔ−ｕｕｉｄ／ｓｈａｒｅ−ｕｕｉｄ／ｆｕｎｃｔｉｏｎ−ｕｕｉｄ／ｕｓｅｒ−ｕｕｉｄパスをプレフィックスとして付けられる。３つのプレフィックスを用いて、サーバは、格納された様々なオブジェクトを考慮して、ユーザ、関数、シェア、または、テナントによって用いられるストレージなどの集計を計算することもできる。したがって、ファイル名がこれらのプレフィックスと共に、ローカルディスク上に格納されるかオブジェクトストア内に格納されるかに関わらず、そのファイルのためのＵＵＩＤを生成する。

有利なことに、関数は、ファイル名に追加される一意的なプレフィックス故に、（両方が同じ真のファイル名であったとしても、および、両方が同じユーザフォルダに書き込まれたとしても）別の関数によって書き込まれたファイルに上書きすることはできない。従来のファイルシステムは、アクセス制御（ＰＯＳＩＸ属性）を用いて、読み出し／書き込みアクセス制御の読み書きを組織化する。したがって、ファイル名は、フォルダ内で可視であってよいが、所有者以外の誰かによって読み書きされることはできない。この従来のファイルシステムの問題は、名称がまだ「可視」であり、この名称が「専有される」、すなわち、名称がもはや他の誰にとっても利用可能ではないことである。対照的に、本発明の実施形態において、各ユーザは、基本的に、独自のプライベートファイルシステムまたはプライベートフォルダを有する。

キャッシングサブシステムのフローチャート
図１９は、プラグイン関数がローカルディスクにデータを書き込む一実施形態を記載するフローチャートである。このフローは、どれだけのディスクスペースが利用可能かを気にする必要なしに、プラグイン関数が任意のデータをローカルディスク２１０上のキャッシュのフォルダに書き込むバックサイドキャッシングを記載する。第１工程１１４０において、ユーザは、工程７０２〜７０８または８０２〜８０４に記載したようにコンピュータデバイスにログインし、上述したように様々なプラグイン関数の内のいずれかを呼び出す。プラグイン関数は、実行を開始し、そのコードに従って、工程１１４２の或る時点に、データファイルを作成するか、ユーザによってアップロードされたデータを取得してもよく、または、何らかの他の方法で（例えば、データリポジトリまたはリモートサービスから）データファルを取得してもよい。工程８０６および８２４でも、例について上述した。このファイルは、”Ｗｏｒｋｓ Ｓｈａｋｅｓｐｅａｒｅ”などのファイルファイルの読み出しおよび書き込みのためにプラグイン関数によって利用される（そして、おそらくユーザに対して表示される）真のファイル名を持つことになる。

工程１１４４において、上述のように、サーバは、真のファイル名と４つのプリフィックスコンポーネントとを連結することによって完全なファイル名を作成する。したがって、完全なファイル名は、真のファイル名に対応する汎用一意識別子であり、両方とも、上述のように、ロースタファイルに関連して記録される。もちろん、真のファイル名に対応する汎用一意識別子が、当業者に周知のその他の方法で作成されてもよい。この工程は、ローカルディスク上のユーザフォルダにファイルが書き込まれることをプラグイン関数が要求した後の工程１１４８の後に実行されてもよい。

工程１１４６において、プラグイン関数は、このファイルをこのユーザに固有のフォルダに保存することを望み、フォルダ”／ｍｎｔ／ｓｔｏｒａｇｅ／ｐｒｉｖａｔｅ”にアクセスする。有利なことに、プラグイン関数（むしろ、関数の開発者）は、具体的にユーザが誰であるかを知る必要がない。プラグイン関数は、プラグイン関数が別のユーザによって呼び出された時でも、ファイルがうっかり上書きされないことを保証して、真のファイル名を用いてフォルダ”ｐｒｉｖａｔｅ”にファイルを単に書き込む。サーバによって実施される上述の命名規則は、ファイルがうっかり上書きされないことを保証する。

工程１１４８において、ファルの真のファイル名を用いて上述したように、プラグイン関数は、マウントポイントおよびＦＵＳＥファイルシステムを介して、このファイルをローカルディスク上のキャッシュ内のユーザ固有のフォルダ”ｐｒｉｖａｔｅ”に書き込む。ロースタファイルは、同様にこの時に書き込まれてもよいし、定期的に後で書き込まれてもよい。この時点で、モジュール１００２は、工程１１４４で上述したように、真のファイル名に基づいて完全なファイル名を作成してよい。次いで、ファイルは、汎用一意識別子であるその完全なファイル名を用いてモジュールによってキャッシュに書き込まれる。図１８に示したように、プラグイン関数１６０は、ユーザ固有のデータに利用可能な「プライベート」フォルダであるフォルダ１０３６にアクセスした。有利なことに、プラグイン関数１６０は、フォルダ１０３６にデータを書き込むたびに、その時にどのユーザがログインしていても、その他のユーザデータにうっかり上書きすることがない。

次に、或る時点で、関数は終了してよく、制御は、別のユーザがログインする工程１１４０に戻り、同じプラグイン関数が、キャッシュ（フォルダ１０３２〜１０３６のいずれか）にデータを書き込み続ける。または、制御が工程１１４２に戻り、関数は、同じユーザのためにキャッシュにデータを書き込み続ける。有利なことに、プラグイン関数（すなわち、その開発者）およびサーバ１５０の管理者は、どれだけ多くのデータがキャッシュに書き込まれても、キャッシュ内でどれだけのディスクスペースが利用可能であるかを気にする必要がない。工程１１５０において、キャッシングサブシステムモジュール１００２のバックグラウンドプロセスは、スペースが利用可能であるかを確かめるために継続的にチェックを行い、より多くのスペースがキャッシュ内で必要とされた場合に、ファイルをエビクトする。この工程については、図２０において以下でより詳細に説明する。

図２０は、データがキャッシュからリモートオブジェクトストアに移動される一実施形態を記載するフローチャートである。このフローは、プラグイン関数がキャッシュにデータを書き込もうとするたびにバックサイドキャッシング中に行われ、また、定期的に行われてもよいし、モジュール１００２の何らかの警告メカニズムまたはローカルディスク２１０上で利用可能なデータの監視メカニズムによってトリガされてもよい。さらに、このフローは、サーバ１５０がキャッシュにデータを書き込もうとした時に、フロントサイドキャシング中にも行われる。換言すると、エビクトが行われうる明確な時点が存在する。いくつかのファイルをエビクトすることで、いつでも少しのキャッシュスペースを解放するプロアクティブなバックグラウンドタスクがある。その他の可能性は、新しいデータを書き込まなければならないが十分なスペースが利用できないプレッシャーの大きい状況で利用されるオンデマンドエビクトである。

例えば、工程１１６０において、プラグイン関数は、工程１１４８で記載したように、ファイルをキャッシュに書き込むことを決定する。モジュール１００２は、この書き込みコマンドを傍受し、工程１１６２において、キャッシュ内に利用可能なスペースがあるか否かを工程１１６２で判定する。ファイルのサイズが、キャッシュ内の残りのディスクスペースと比較されてもよいし、残りのスペースが、所定の数（例えば、１ＭＢ）よりも少ない時に、利用可能なスペースがないと自動的に判定されてもよい。利用可能な物理的スペースに基づいて判定する代わりに、利用可能なアイノードスペースの量に基づいて判定がなされてよい。スペース（すなわち、物理的スペースもアイノードスペースの両方）が利用可能である場合、工程１１６４において、データは、プラグイン関数によって要求されたように、キャッシュに書き込まれる。

その一方で、キャッシュプレッシャー時、すなわち、キャッシュのデータスペースまたはアイノードスペースが尽きた時、最も長い間利用されていないファイルが、工程１１６６でキャッシュからエビクトされる。キャッシュ内で最も長い間利用されていないファイルは、例えば、そのＵＵＩＤを用いて、どのファイルが最も過去に書き込まれたのかまたは最も過去に読み出されたのか、に基づいて決定される。エビクトするファイルを選択する他の方法の中でも時に、エビクトに向けてランダムにファイルを選んでもよい。

或る程度の量のスペースがファイルの書き込みに必要である場合、または、或る程度の量のスペースを利用可能にしなければならない場合に、２以上のファイルが特定されてもよい。１または複数のファイルが特定されると、エビクトの前に、モジュール１００２は、工程１１６８において、エビクトされる１または複数のファイルのコピーがオブジェクトストレージ内にあることを確実にする。したがって、１または複数のファイルは、最初にオブジェクトストレージ２２０にコピーされ、最初に暗号化および圧縮される。上述のように、１つの例外がある、フロントサイドキャシングで格納されたファイルが、エビクトの対象として選択されても、期限が切れていれば、オブジェクトストレージへコピーされず、単に削除される。この動作を見る１つの方法は、ローカルファイルがキャッシュからリモートストレージにスワップアウトされるスワップ動作として見ることである。コピーされると、ローカルファイルは、ディスクから効果的に削除される。

工程１１７０において、エビクトされるファイルまたはフォルダによって利用されていたスペースは、キャッシュ内で解放される。次に、スペースが、プラグイン関数からの書き込み要求のために必要とされた場合に、工程１１６４において、データは、上述のようにキャシュに書き込まれる。ファイルが、オンデマンドエビクトではなく、バックグラウンドのプロアクティブなプロセスのためにエビクトされた場合、工程１１６４は、この時には実行されない。

スワップアウトされたファイルが、プラグイン関数（またはサーバ）によってしばらく後に必要とされた時、逆の動作が実行される。有利なことに、プラグイン関数が必要としうるファイルがローカルディスクから削除されて、今ではリモートオブジェクトストア内にあることは、プラグイン関数にとってトランスペアレントである。したがって、プラグイン関数は、単に、（工程１１４８において、ファイルをキャッシュに書き込むために用いたのと同じ真のファイル名およびフォルダ名を用いて）ユーザ固有のフォルダ１０３６から自身の必要とするファイルを読み出すよう要求する。真のファイル名に対応する完全なファイル名は、ロースタファイルからリトリーブされ（または、上述のように作成されてもよい）、読み出し要求は、上述のようにマウントポイント１０２０、ＦＵＳＥ １０２２、１０２４を通して渡され、モジュール１００２がその要求を受信する。モジュールは、所望のファイルがローカルキャッシュに存在しないと認識すると、完全なファイル名を用いて、リモートオブジェクトストア２２０内でファイルを検索して見つけ、その後、ファイルは、リモートオブジェクトストアからコピーされ、解凍、復号され、ディスク２１０上にローカルに格納される。ファイルは、オブジェクトストアから消去されても消去されなくてもよい。ディスク２１０上にローカルに格納されたファイルは、その後、要求側のプラグイン関数に返される。

したがって、このファイルエビクト処理は、バックグラウンドで自動的に起こり、関数またはサーバがファイルをキャッシュに書き込もうとした時にオンデマンドで必要に応じても起こるので、プラグイン関数もサーバも、キャッシュ内でどれだけのディスクスペースが利用可能であるのかを気にする必要がない。各々、ストレージが無限であるかのように、キャッシュにデータを書き込み続けてよい。

さらなる実施形態
本発明の方法実施形態の多くは、システムとして実施されてもよく、これらは以下を含む。

第１実施形態は、クライアントコンピュータデバイス上にデータを読み込むためのシステムを含み、システムは、以下の工程を実行するよう構成された装置を備える。コンピュータサーバからクライアントコンピュータデバイスへ、表示に向けて、情報のフォルダを表すアイコンを含むユーザインターフェスデータを送信する工程で、それにより、アイコンがクライアントコンピュータデバイス上に表示され工程、パス名と、フォルダを開くためのユーザインターフェース上でのユーザの選択を示すコマンドとを、コンピュータデバイスからリモートコンピュータで受信する工程、パス名およびコマンドを用いてリモートコンピュータのプラグイン関数を実行する工程、プラグイン関数からコンピュータデバイスへフォルダのコンテンツのリストを返す工程、それにより、フォルダのコンテンツがユーザインターフェース上で階層に表示され、コンテンツは、どのストレージデバイス上にもまだ存在しない工程。

第２実施形態は、クライアントコンピュータデバイス上にデータを読み込むためのシステムを含み、システムは、以下の工程を実行するよう構成された装置を備える。コンピュータサーバからクライアントコンピュータデバイスへ、表示に向けて、情報のファイルを表すアイコンを含むユーザインターフェスデータを送信する工程、それにより、アイコンがクライアントコンピュータデバイス上に表示され、ファイルは、どのストレージデバイス上にもまだ存在しない、パス名と、ファイルを開くためのユーザインターフェース上でのユーザの選択を示すコマンドとを、コンピュータデバイスからリモートコンピュータで受信する工程、ファイルを作成するために、パス名およびコマンドを用いてリモートコンピュータのプラグイン関数を実行する工程、プラグイン関数からコンピュータデバイスへファイルのコンテンツを返す工程、それにより、ファイルのコンテンツが、クライアントコンピュータデバイスのアプリケーションを用いてクライアントコンピュータデバイス上で表示される工程。

第３実施形態は、クライアントコンピュータデバイスからデータを書き出すためのシステムを含み、システムは、以下の工程を実行するよう構成された装置を備える。コンピュータサーバからクライアントコンピュータデバイスへ、表示に向けて、情報のフォルダを表すアイコンを含むユーザインターフェスデータを送信する工程、それにより、アイコンがクライアントコンピュータデバイス上に表示され工程、クライアントコンピュータデバイスから、パス名と、ファイルのコンテンツと、ファイルをフォルダに追加するためのユーザインターフェース上でのユーザの選択を示すコマンドとを、リモートコンピュータで受信する工程、パス名およびコマンドを用いてリモートコンピュータのプラグイン関数を実行して、ファイルをストレージに格納する工程、プラグイン関数は、ファイルをクライアントコンピュータデバイス上に表示するためのユーザインターフェースを全く実装せず、クライアントデバイス上でユーザインターフェースのフォルダ内に表示するために、プラグイン関数からコンピュータデバイスへファイルの名称を返す工程。

第４実施形態は、コンピュータサーバ上でプラグイン関数を実行するためのシステムを含み、システムは、以下の工程を実行するよう構成された装置を備える。第１および第２プラグイン関数のための実行可能コードの層をリポジトリからフェッチして、コンピュータサーバのローカルディスク上の前記プラグイン関数の各々のためのルートファイルシステムフォルダ内に層を解凍する工程、コンピュータサーバの仮想マシン上で実行するサーバプロセスによって、プラグイン関数の実行可能コードをロードして、プラグイン関数の各々を実行する工程、プラグイン関数の各々は、独自のルートファイルシステムを有し、プラグイン関数の各々は、同じネームスペースを共有し、第１プラグイン関数によって、仮想マシンのネットワークを用いて、リモート企業コンピュータから第１データをリトリーブする工程、第２プラグイン関数によって、仮想マシンのネットワークを用いて、リモート企業コンピュータから第２データをリトリーブする工程、第１および第２プラグイン関数の各々が、それぞれの第１および第２データを用いて、クライアントコンピュータデバイスに各々送信されるそれぞれの第１および第２データファイルを作成する工程。

第５実施形態は、コンピュータサーバ上でプラグイン関数を実行するためのシステムを含み、システムは、以下の工程を実行するよう構成された装置を備える。サーバコンピュータ上のサーバプロセスによってプラグイン関数を呼び出す工程、プラグイン関数は、独自のルートファイルシステムを持つが、独自のネームスペースを持たず、工程、コンピュータサーバ上でプラグイン関数を実行し、リモートユーザコンピュータデバイスからコマンドを受信する工程、データソースからデータを読み出す工程、データに基づいてファイルを作成し、ファイルの表示に向けてリモートユーザコンピュータデバイスにファイルを送信する工程、プラグイン関数は、リモートユーザコンピュータデバイス上にユーザインターフェースを全く実装しない。

第６実施形態は、クライアントコンピュータデバイス上にデータを読み込むためのシステムを含み、システムは、以下の工程を実行するよう構成された装置を備える。コンピュータサーバからクライアントコンピュータデバイスへ、表示に向けて、情報のフォルダを表すアイコンを含むユーザインターフェスデータを送信する工程、それにより、アイコンがクライアントコンピュータデバイス上に表示され工程、ユーザによって入力されたフォルダ名を有する新規フォルダを作成するためにユーザインターフェース上でユーザによってなされた選択を示すコンピュータデバイスからのコマンドをリモートコンピュータで受信する工程、リモートコンピュータのプラグイン関数を実行して、フォルダ名を有する新規フォルダを作成し、コンピュータデバイスのユーザインターフェース上で表示するために新規フォルダを返す工程、フォルダ名に依存する結果を生成するために、フォルダ名を入力として用いてプラグイン関数を実行する工程。

第７実施形態は、クライアントコンピュータデバイスからデータを書き出すためのシステムを含み、システムは、以下の工程を実行するよう構成された装置を備える。ユーザによって入力されたフォルダ名を有する新規フォルダを作成するためにユーザインターフェース上でユーザによってなされた選択を示すクライアントコンピュータデバイスからのコマンドをリモートコンピュータで受信する工程、リモートコンピュータのプラグイン関数を実行して、フォルダ名を有する新規フォルダを作成し、コンピュータデバイスのユーザインターフェース上で表示するために新規フォルダを返す工程、コンピュータデバイスのユーザインターフェースを用いてユーザによって新規フォルダに追加されたデジタルオブジェクトをリモートコンピュータで受信する工程、プラグイン関数を実行し、フォルダ名を用いてデジタルオブジェクトを処理することで、フォルダ名に依存する結果を生成する工程。

第８実施形態は、クライアントコンピュータデバイスからメタデータを入力するためのシステムを含み、システムは、以下の工程を実行するよう構成された装置を備える。リモートコンピュータのプラグイン関数をデーモンモードで実行して、プラグイン関数を表すフォルダアイコンとユーザ入力アイコンとを備えたユーザインターフェースをクライアントコンピュータデバイス上に表示する工程、ユーザインターフェース上でユーザによってなされたユーザ入力アイコンの選択を示すコンピュータデバイスからのコマンドをリモートコンピュータで受信する工程、プラグイン関数によって、コンピュータデバイス上に表示するウェブページを送信する工程、プラグイン関数によって、ユーザによってウェブページ上で入力されたメタデータ値を受信する工程、メタデータ値に依存する結果を生成するために、メタデータ値を入力として用いてプラグイン関数を実行する工程。

第９実施形態は、クライアントコンピュータデバイスからメタデータを入力するためのシステムを含み、システムは、以下の工程を実行するよう構成された装置を備える。ユーザによって入力されたフォルダ名を有する新規フォルダを作成するためにユーザインターフェース上でユーザによってなされた選択を示すクライアントコンピュータデバイスからのコマンドをリモートコンピュータで受信する工程、リモートコンピュータのプラグイン関数を実行して、フォルダ名を有する新規フォルダを作成し、コンピュータデバイスのユーザインターフェース上で表示するために新規フォルダを返す工程、ユーザによって入力されたフォルダ名にメタデータ値をプラグイン関数によって割り当てる工程、メタデータ値に依存する結果を生成するために、メタデータ値を入力として用いてプラグイン関数を実行する工程。

第１０実施形態は、クライアントコンピュータデバイスからデータベースと通信するためのシステムを含み、システムは、以下の工程を実行するよう構成された装置を備える。リモートコンピュータの第１プラグイン関数をデーモンモードで実行し、第１プラグイン関数によってデータベースとの接続を開く工程、リモートコンピュータの第２プラグイン関数を介して、データベースにアクセスするためのクライアントコンピュータデバイスからの要求をリモートコンピュータで受信する工程、リモートコンピュータの第２プラグイン関数を実行し、要求を実行中の第１プラグイン関数に送信する工程、要求で第１プラグイン関数によってデータベースにアクセスし、データベースから応答を受信する工程、応答を第１プラグイン関数から第２プラグイン関数に送信する工程、応答を第２プラグイン関数からクライアントコンピュータデバイスに送る工程。

第１１実施形態は、クライアントコンピュータデバイス上にデータを表示するためのシステムを含み、システムは、以下の工程を実行するよう構成された装置を備える。コンピュータサーバからクライアントコンピュータデバイスへ、表示に向けて、情報のフォルダを表すアイコンを含むユーザインターフェスデータを送信する工程、それにより、アイコンがクライアントコンピュータデバイス上に表示され、パス名と、ユーザインターフェースのアイコンに関する動作を示すクライアントコンピュータデバイスからのユーザインターフェースコマンドとを、コンピュータサーバで受信する工程、パス名およびユーザインターフェースコマンドを用いてコンピュータサーバのプラグイン関数を実行して、ユーザインターフェースコマンドを実行する工程、ユーザインターフェースコマンド内に含まれないさらなるステップを実行するために、プラグイン関数を実行する工程、表示するために、結果をクライアントコンピュータデバイスに返す工程。

第１２実施形態は、プラグイン関数からファイルシステムに書き込みを行うためのシステムを含み、システムは、以下の工程を実行するよう構成された装置を備える。リモートコンピュータデバイスの第１ユーザの要求に応じて、仮想マシンのプラグイン関数を実行する工程、ファイル名を有するファイルをプラグイン関数で受信する工程、プラグイン関数の識別子および第１ユーザの識別子に基づいて、ファイル名に対して一意ファイル名を作成する工程、コンピュータのローカルディスク上でファイルを識別するために一意ファイル名を用いて、プラグイン関数によってローカルディスク上のファイルシステムのユーザフォルダにファイルを書き込む工程。

第１３番目の実施形態は、コンピュータのローカルディスクのスペースを管理するためのシステムを含み、前記システムは、以下の工程を実行するよう配置された装置を含む。前記仮想マシンのサーバプロセスによって、前記ローカルディスク上で利用可能なストレージスペースをより多く作成するか否かを決定する工程、利用可能なより多くのストレージスペースを作成すると決定する時、前記ローカルディスクから除去される格納されたファイルを選択する工程、前記ローカルディスクからリモート記憶域へ前記格納されたファイルをコピーする工程、および、前記格納されたファイルによって使用されていた前記ローカルディスク上のスペースを解放する工程。

コンピュータシステム実施形態
図２１Ａおよび図２１Ｂは、本発明の実施形態の実施に適したコンピュータシステム１５００を示している。図１２Ａは、コンピュータシステムの物理的形態の一例を示している。もちろん、コンピュータシステムは、集積回路、プリント回路基板、小型ハンドヘルドデバイス（携帯電話、タブレット、または、ＰＤＡなど）、パーソナルコンピュータ、もすくは、スーパーコンピュータなど、多くの物理的形態を有してよい。コンピュータシステム１５００は、モニタ１５０２、ディスプレイ１５０４、筐体１５０６、ディスクドライブ１５０８、キーボード１５１０、および、マウス１５１２を備える。ディスク１５１４は、コンピュータシステム１５００とデータをやり取りするために用いられるコンピュータ読み取り可能な媒体である。

図２１Ｂは、コンピュータシステム１５００のブロック図の一例である。システムバス１５２０には、様々なサブシステムが取り付けられている。１または複数のプロセッサ１５２２（中央処理装置すなわちＣＰＵとも呼ぶ）が、メモリ１５２４などの記憶装置に接続されている。メモリ１５２４は、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリーメモリ（ＲＯＭ）を含む。当業者に周知のように、ＲＯＭは、ＣＰＵに対して単方向的にデータおよび命令を転送するよう機能し、ＲＡＭは、通例、双方向的にデータおよび命令を転送するために用いられる。これらの種類のメモリは両方とも、後に示す任意の適切なコンピュータ読み取り可能媒体を含んでよい。ＣＰＵ１５２２には、さらに、固定ディスク１５２６が、双方向的に接続されており、さらなるデータ記憶容量を提供している。固定ディスク１５２６は、後に示すコンピュータ読み取り可能媒体のいずれを含んでもよい。固定ディスク１５２６は、プログラム、データなどを格納するために用いられてよく、通例は、一次記憶装置よりも遅い場合があるがデータを永続的に保持する二次マスストレージ媒体（ハードディスク、ソリッドステートドライブ、ハイブリッドドライブ、フラッシュメモリなど）である。固定ディスク１５２６内に保持された情報は、必要に応じて、メモリ１５２４内の仮想メモリとして標準的な方法で組み込まれてよいことを理解されたい。リムーバブルディスク１５１４は、後に示すコンピュータ読み取り可能な媒体のいずれの形態を取ってもよい。

ＣＰＵ１５２２は、さらに、ディスプレイ１５０４、キーボード１５１０、マウス１５１２、および、スピーカ１５３０など、様々な入力／出力装置に接続されている。一般に、入力／出力装置は、ビデオディスプレイ、トラックボール、マウス、キーボード、マイク、タッチセンサ式ディスプレイ、トランスデューサ式カードリーダ、磁気または紙テープリーダ、タブレット、スタイラス、音声または手書き認識装置、バイオメトリクスリーダ、もしくは、他のコンピュータ、のいずれであってもよい。ＣＰＵ１５２２は、任意選択的に、ネットワークインターフェース１５４０を用いて、他のコンピュータや電気通信ネットワークに接続されてもよい。かかるネットワークインターフェースを用いて、ＣＰＵは、上述の方法の工程を実行する際に、ネットワークから情報を受信、または、ネットワークに情報を出力してよい。さらに、本発明の方法の実施形態は、ＣＰＵ１５２２単体で実行されてもよいし、インターネットなどのネットワークを介して、処理の一部を分担する遠隔ＣＰＵと協働で実行されてもよい。

さらに、本発明の実施形態は、コンピュータによって実現される様々な動作を実行するためのコンピュータコードを有するコンピュータ読み取り可能な媒体を備えたコンピュータストレージ製品に関する。媒体およびコンピュータコードは、本発明のために、特別に設計および構成されてもよいし、コンピュータソフトウェア分野における当業者にとって周知および利用可能なものであってもよい。コンピュータ読み取り可能な媒体の例としては、ハードディスク、フロッピーディスク、磁気テープなどの磁気媒体、ＣＤ−ＲＯＭ、ホログラフィック素子などの光学媒体、フロプティカルディスクなどの光磁気媒体、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能論理デバイス（ＰＬＤ）、ＲＯＭおよびＲＡＭなど、プログラムコードを格納および実行するよう特別に構成されたハードウェア装置、が挙げられるが、それらに限定されない。コンピュータコードの例としては、コンパイラによって生成されたコードなどのマシンコードや、インタープリタを用いてコンピュータによって実行される高級言語コードを含むファイルが挙げられる。

理解を深めるために、上述の発明について、ある程度詳しく説明したが、添付の特許請求の範囲内で、ある程度の変更や変形を行ってもよいことは明らかである。したがって、上述の実施形態は、例示的なものであって、限定的なものではないとみなされ、本発明は、本明細書に示した詳細事項に限定されず、添付の特許請求の範囲およびその等価物の範囲によって規定される。

Claims (88)

1. クライアントコンピュータデバイス上にデータを読み込む方法であって、
   コンピュータサーバからクライアントコンピュータデバイスへ、情報のフォルダを表す表示のためのアイコンを含むユーザインターフェスデータを送信し、それにより、前記アイコンが前記クライアントコンピュータデバイス上に表示され、
   前記フォルダを開くための前記ユーザインターフェース上でのユーザの選択を示すパス名およびコマンドを、前記コンピュータデバイスからリモートコンピュータで受信し、
   前記パス名および前記コマンドを用いて前記リモートコンピュータのプラグイン関数を実行し、
   前記プラグイン関数から前記コンピュータデバイスへ前記フォルダのコンテンツのリストを返し、それにより、前記フォルダの前記コンテンツが前記ユーザインターフェース上で階層に表示され、前記コンテンツは、どのストレージデバイス上にもまだ存在しない、方法。
2. 請求項１に記載の方法であって、前記コンテンツは、前記どのストレージデバイス上の前記階層にも存在しない、方法。
3. 請求項１に記載の方法であって、前記プラグイン関数は、前記リストのみを返し、前記ユーザインターフェースを実装しない、方法。
4. 請求項１に記載の方法であって、さらに、
   前記コンピュータデバイスのプレゼンテーションアプリケーションを用いて、前記階層に前記コンテンツを表示する、方法。
5. 請求項１に記載の方法であって、前記コンテンツは、少なくとも１つのファイルフォルダを含む、方法。
6. 請求項１に記載の方法であって、前記コンテンツは、まだ存在しない少なくとも１つのファイルを含む、方法。
7. 請求項１に記載の方法であって、前記コマンドは、ＨＴＴＰのｌｉｓｔコマンドである、方法。
8. 請求項１に記載の方法であって、前記リモートコンピュータのサーバのコンパイル済コードが、前記プラグイン関数を呼び出し、前記プラグイン関数は、前記コンパイル済コードの一部ではない、方法。
9. クライアントコンピュータデバイス上にデータを読み込む方法であって、
   コンピュータサーバからクライアントコンピュータデバイスへ、表示のための情報のファイルを表すアイコンを含むユーザインターフェスデータを送信し、それにより、前記アイコンが前記クライアントコンピュータデバイス上に表示され、前記ファイルは、どのストレージデバイス上にもまだ存在せず、
   前記ファイルを開くための前記ユーザインターフェース上でのユーザの選択を示すコマンドおよびパス名を、前記コンピュータデバイスからリモートコンピュータで受信し、
   前記ファイルを作成するために、前記パス名および前記コマンドを用いて前記リモートコンピュータのプラグイン関数を実行し、
   前記プラグイン関数から前記コンピュータデバイスへ前記ファイルのコンテンツを返し、それにより、前記ファイルの前記コンテンツが、前記クライアントコンピュータデバイスのアプリケーションを用いて前記クライアントコンピュータデバイス上で表示される、方法。
10. 請求項９に記載の方法であって、さらに、
    フォルダ内に前記ファイルアイコンを含む前記ユーザインターフェースの階層を表示する、方法。
11. 請求項９に記載の方法であって、前記プラグイン関数は、前記ファイルコンテンツのみを返し、前記ユーザインターフェースを実装しない、方法。
12. 請求項９に記載の方法であって、前記コマンドは、ＨＴＴＰのｇｅｔコマンドである、方法。
13. 請求項９に記載の方法であって、前記リモートコンピュータのサーバのコンパイル済コードが、前記プラグイン関数を呼び出し、前記プラグイン関数は、前記コンパイル済コードの一部ではない、方法。
14. クライアントコンピュータデバイスからデータを書き出す方法であって、
    コンピュータサーバからクライアントコンピュータデバイスへ、表示するための情報のフォルダを表すアイコンを含むユーザインターフェスデータを送信し、それにより、前記アイコンが前記クライアントコンピュータデバイス上に表示され、
    前記クライアントコンピュータデバイスから、前記ユーザインターフェース上でのユーザの選択を示す、パス名、ファイルのコンテンツとおよび前記ファイルを前記フォルダに追加するためのコマンドを、リモートコンピュータで受信し、
    前記パス名および前記コマンドを用いて前記リモートコンピュータのプラグイン関数を実行し、前記ファイルをストレージに格納し、前記プラグイン関数は、前記ファイルを前記クライアントコンピュータデバイス上に表示するためのユーザインターフェースを全く実装せず、
    前記クライアントデバイス上で前記ユーザインターフェースの前記フォルダ内に表示するために、前記プラグイン関数から前記コンピュータデバイスへ前記ファイルの名称を返す、方法。
15. 請求項１４に記載の方法であって、さらに、
    前記コンピュータデバイスのプレゼンテーションアプリケーションを用いて、前記ファイルの前記コンテンツを表示する、方法。
16. 請求項１４に記載の方法であって、前記コマンドは、ＨＴＴＰのｐｕｔコマンドである、方法。
17. 請求項１４に記載の方法であって、前記リモートコンピュータのサーバのコンパイル済コードが、前記プラグイン関数を呼び出し、前記プラグイン関数は、前記コンパイル済コードの一部ではない、方法。
18. 請求項１４に記載の方法であって、さらに、
    前記プラグイン関数が、前記ファイルに基づいて新規ファイルを作成し、
    前記新規ファイルをストレージに格納し、
    前記クライアントコンピュータデバイス上で前記ユーザインターフェースの前記フォルダ内に表示するために、前記プラグイン関数によって前記新規ファイルの名称を返す、方法。
19. コンピュータサーバ上でプラグイン関数を実行する方法であって、
    第１および第２プラグイン関数のための実行可能コードの層をリポジトリからフェッチし、前記コンピュータサーバのローカルディスク上の前記プラグイン関数の各々のためのルートファイルシステムフォルダ内に前記層を解凍し、
    前記コンピュータサーバの仮想マシン上で実行するサーバプロセスによって、前記プラグイン関数の前記実行可能コードをロードして、前記プラグイン関数の各々を実行し、前記プラグイン関数の各々は、独自のルートファイルシステムを有し、前記プラグイン関数の各々は、同じネームスペースを共有し、
    前記第１プラグイン関数によって、前記仮想マシンのネットワークを用いて、リモート企業コンピュータから第１データをリトリーブし、
    前記第２プラグイン関数によって、前記仮想マシンの前記ネットワークを用いて、リモート企業コンピュータから第２データをリトリーブし、
    前記第１および第２プラグイン関数の各々が、前記それぞれの第１および第２データを用いて、クライアントコンピュータデバイスに各々送信されるそれぞれの第１および第２データファイルを作成する、方法。
20. 請求項１９に記載の方法であって、前記プラグイン関数は、同じＩＰスタックを共有することによって前記同じネームスペースを共有する、方法。
21. 請求項１９に記載の方法であって、前記ネットワークは、サブネットである、方法。
22. 請求項１９に記載の方法であって、前記ネットワークは、前記サーバプロセスのシングルＶＰＮを利用する、方法。
23. 請求項１９に記載の方法であって、前記第１および第２プラグイン関数は、前記同じネットワークを用いて、前記リモート企業コンピュータのデータベースにアクセスする、方法。
24. コンピュータサーバ上でプラグイン関数を実行する方法であって、
    サーバコンピュータ上のサーバプロセスによってプラグイン関数を呼び出し、前記プラグイン関数は、独自のルートファイルシステムを持つが、独自のネームスペースを持たず、
    前記コンピュータサーバ上で前記プラグイン関数を実行し、リモートユーザコンピュータデバイスからコマンドを受信し、
    データソースからデータを読み出し、
    前記データに基づいてファイルを作成し、前記ファイルの表示に向けて前記リモートユーザコンピュータデバイスに前記ファイルを送信し、前記プラグイン関数は、前記リモートユーザコンピュータデバイス上にユーザインターフェースを全く実装しない、方法。
25. 請求項２４に記載の方法であって、前記プラグイン関数は、前記コンピュータサーバ上で実行する第２プラグイン関数とネームスペースを共有する、方法。
26. 請求項２４に記載の方法であって、さらに、
    前記リモートユーザコンピュータデバイスからファイル・フォルダ階層のパスを受信する、方法。
27. 請求項２４に記載の方法であって、さらに、
    プレゼンテーションアプリケーションを用いて、前記リモートユーザコンピュータデバイス上に前記ファイルを表示する、方法。
28. クライアントコンピュータデバイス上にデータを読み込む方法であって、
    コンピュータサーバからクライアントコンピュータデバイスへ、表示するための情報のフォルダを表すアイコンを含むユーザインターフェスデータを送信し、それにより、前記アイコンが前記クライアントコンピュータデバイス上に表示され、
    ユーザによって入力されたフォルダ名を有する新規フォルダを作成するために前記ユーザインターフェース上で前記ユーザによってなされた選択を示す前記コンピュータデバイスからのコマンドをリモートコンピュータで受信し、
    前記リモートコンピュータのプラグイン関数を実行して、前記フォルダ名を有する前記新規フォルダを作成し、前記コンピュータデバイスの前記ユーザインターフェース上で表示するために前記新規フォルダを返し、
    前記フォルダ名に依存する結果を生成するために、前記フォルダ名を入力として用いて前記プラグイン関数を実行する、方法。
29. 請求項２８に記載の方法であって、さらに、
    前記ユーザインターフェース上の階層内に前記新規フォルダを表示し、前記新規フォルダは、コンテンツを全く持たず、
    前記ユーザが前記新規フォルダを開く選択をしたことを示すコマンドを受信した後にのみ、前記フォルダ名を入力として用いて前記プラグイン関数を実行する、方法。
30. 請求項２８に記載の方法であって、さらに、
    前記ユーザインターフェース上の階層内に前記新規フォルダを表示し、
    前記ユーザが前記新規フォルダを開く選択をしたことを示すコマンドを受信する前に、前記フォルダ名を入力として用いて前記プラグイン関数を実行する、方法。
31. 請求項２９に記載の方法であって、さらに、
    前記プラグイン関数によって前記フォルダ名を検索語として利用し、前記検索語に基づいて少なくとも１つのデジタルオブジェクトを発見し、
    前記新規フォルダ内に表示するために、前記少なくとも１つのデジタルオブジェクトの識別子を前記コンピュータデバイスに送信する、方法。
32. 請求項３０に記載の方法であって、さらに、
    前記プラグイン関数によって前記フォルダ名を検索語として利用し、前記検索語に基づいて少なくとも１つのデジタルオブジェクトを発見し、
    前記少なくとも１つのデジタルオブジェクトを前記リモートコンピュータのキャッシュ内に格納する、方法。
33. 請求項３２に記載の方法であって、さらに、
    前記ユーザが前記新規フォルダを開く選択をしたことを示すコマンドを受信し、
    前記新規フォルダ内に表示するために、前記キャッシュから、前記少なくとも１つのデジタルオブジェクトの識別子を前記コンピュータデバイスに送信する、方法。
34. 請求項２９に記載の方法であって、さらに、
    前記検索語に基づいて、少なくとも１つのデジタルオブジェクトを作成し、
    前記新規フォルダ内に表示するために、前記少なくとも１つのデジタルオブジェクトの識別子を前記コンピュータデバイスに送信する、方法。
35. 請求項３０に記載の方法であって、さらに、
    前記検索語に基づいて、少なくとも１つのデジタルオブジェクトを作成し、
    前記少なくとも１つのデジタルオブジェクトを前記リモートコンピュータのキャッシュ内に格納する、方法。
36. クライアントコンピュータデバイスからデータを書き出す方法であって、
    ユーザによって入力されたフォルダ名を有する新規フォルダを作成するためにユーザインターフェース上で前記ユーザによってなされた選択を示すクライアントコンピュータデバイスからのコマンドをリモートコンピュータで受信し、
    前記リモートコンピュータのプラグイン関数を実行して、前記フォルダ名を有する前記新規フォルダを作成し、前記コンピュータデバイスの前記ユーザインターフェース上で表示するために前記新規フォルダを返し、
    前記コンピュータデバイスの前記ユーザインターフェースを用いて前記ユーザによって前記新規フォルダに追加されたデジタルオブジェクトを前記リモートコンピュータで受信し、
    前記プラグイン関数を実行し、前記フォルダ名を用いて前記デジタルオブジェクトを処理することで、前記フォルダ名に依存する結果を生成する、方法。
37. 請求項３６に記載の方法であって、さらに、
    親フォルダを表すアイコンを前記クライアントコンピュータデバイス上に表示し、
    前記親フォルダ内に前記新規フォルダを作成することを示す前記ユーザによる前記選択を受信する、方法。
38. 請求項３６に記載の方法であって、さらに、
    前記フォルダ名を用いて前記デジタルオブジェクトを格納するために、前記プラグイン関数を実行する、方法。
39. 請求項３６に記載の方法であって、さらに、
    前記フォルダ名を前記デジタルオブジェクトのメタデータとして追加して、前記メタデータと共に前記デジタルオブジェクトを格納するために、前記プラグイン関数を実行する、方法。
40. 請求項３６に記載の方法であって、さらに、
    前記フォルダ名を前記デジタルオブジェクトに挿入して、前記挿入されたフォルダ名と共に前記デジタルオブジェクトを格納するために、前記プラグイン関数を実行する、方法。
41. 請求項３６に記載の方法であって、前記新規フォルダは、前記追加されたデジタルオブジェクトを含まない、方法。
42. クライアントコンピュータデバイスからメタデータを入力する方法であって、
    リモートコンピュータのプラグイン関数をデーモンモードで実行して、前記プラグイン関数を表すフォルダアイコンとユーザ入力アイコンとを備えたユーザインターフェースをクライアントコンピュータデバイス上に表示し、
    前記ユーザインターフェース上でユーザによってなされた前記ユーザ入力アイコンの選択を示す前記コンピュータデバイスからのコマンドを前記リモートコンピュータで受信し、
    前記プラグイン関数によって、前記コンピュータデバイス上に表示するウェブページを送信し、
    前記プラグイン関数によって、前記ユーザによって前記ウェブページ上で入力されたメタデータ値を受信し、
    前記メタデータ値に依存する結果を生成するために、前記メタデータ値を入力として用いて前記プラグイン関数を実行する、方法。
43. 請求項４２に記載の方法であって、さらに、
    前記プラグイン関数によって前記メタデータ値を検索語として利用し、前記メタデータ値に基づいて少なくとも１つのデジタルオブジェクトを発見し、
    前記フォルダアイコン内に表示するために、前記少なくとも１つのデジタルオブジェクトの識別子を前記コンピュータデバイスに送信する、方法。
44. 請求項４２に記載の方法であって、さらに、
    前記コンピュータデバイスからデジタルオブジェクトを受信して、前記メタデータ値と共に前記デジタルオブジェクトを格納する、方法。
45. 請求項４２に記載の方法であって、さらに、
    前記リモートコンピュータのキャッシュ内の前記フォルダに関連するファイルに前記メタデータ値を格納し、
    前記ファイルは、前記コンピュータデバイスの前記ユーザには見えない、方法。
46. 請求項４２に記載の方法であって、さらに、
    前記ユーザ入力アイコンを表示すると共に前記ウェブページを表示するために、前記プラグイン関数によってマイクロウェブサーバを実装する、方法。
47. クライアントコンピュータデバイスからメタデータを入力する方法であって、
    ユーザによって入力されたフォルダ名を有する新規フォルダを作成するためにユーザインターフェース上で前記ユーザによってなされた選択を示すクライアントコンピュータデバイスからのコマンドをリモートコンピュータで受信し、
    前記リモートコンピュータのプラグイン関数を実行して、前記フォルダ名を有する前記新規フォルダを作成し、前記コンピュータデバイスの前記ユーザインターフェース上で表示するために前記新規フォルダを返し、
    前記ユーザによって入力された前記フォルダ名にメタデータ値を前記プラグイン関数によって割り当て、
    前記メタデータ値に依存する結果を生成するために、前記メタデータ値を入力として用いて前記プラグイン関数を実行する、方法。
48. 請求項４７に記載の方法であって、さらに、
    前記プラグイン関数によって前記メタデータ値を検索語として利用し、前記メタデータ値に基づいて少なくとも１つのデジタルオブジェクトを発見し、
    前記新規フォルダ内に表示するために、前記少なくとも１つのデジタルオブジェクトの識別子を前記コンピュータデバイスに送信する、方法。
49. 請求項４７に記載の方法であって、さらに、
    前記コンピュータデバイスの前記ユーザインターフェースを用いて前記ユーザによって前記新規フォルダに追加されたデジタルオブジェクトを前記リモートコンピュータで受信し、
    前記デジタルオブジェクトを前記メタデータ値と共に格納する、方法。
50. 請求項４７に記載の方法であって、さらに、
    前記リモートコンピュータのキャッシュ内の前記フォルダに関連するファイルに前記メタデータ値を格納し、前記ファイルは、前記コンピュータデバイスの前記ユーザには見えない、方法。
51. クライアントコンピュータデバイスからデータベースと通信する方法であって、
    リモートコンピュータの第１プラグイン関数をデーモンモードで実行し、前記第１プラグイン関数によってデータベースとの接続を開き、
    前記リモートコンピュータの第２プラグイン関数を介して、前記データベースにアクセスするための前記クライアントコンピュータデバイスからの要求を前記リモートコンピュータで受信し、
    前記リモートコンピュータの前記第２プラグイン関数を実行し、前記要求を前記実行中の第１プラグイン関数に送信し、
    前記要求で前記第１プラグイン関数によって前記データベースにアクセスし、前記データベースから応答を受信し、
    前記応答を前記第１プラグイン関数から前記第２プラグイン関数に送信し、
    前記応答を前記第２プラグイン関数から前記クライアントコンピュータデバイスに送る、方法。
52. 請求項５１に記載の方法であって、前記要求は、読み出し要求であり、前記応答は、デジタルオブジェクトである、方法。
53. 請求項５１に記載の方法であって、前記要求は、デジタルオブジェクトを含む書き込み要求であり、前記方法は、さらに、
    前記デジタルオブジェクトを前記データベースに書き込み、
    前記応答は、前記書き込みの肯定応答である、方法。
54. 請求項５１に記載の方法であって、前記第１および第２プラグイン関数は、同じ関数であり、異なるプロセスとして実行される、方法。
55. 請求項５１に記載の方法であって、前記第１および第２プラグイン関数は、同じネットワークネームスペースを共有する、方法。
56. クライアントコンピュータデバイス上にデータを表示する方法であって、
    コンピュータサーバからクライアントコンピュータデバイスへ、表示のための情報のフォルダを表すアイコンを含むユーザインターフェスデータを送信し、それにより、前記アイコンが前記クライアントコンピュータデバイス上に表示され、
    前記ユーザインターフェースの前記アイコンに関する動作を示す前記クライアントコンピュータデバイスからのパス名およびユーザインターフェースコマンドを、前記コンピュータサーバで受信し、
    前記パス名および前記ユーザインターフェースコマンドを用いて前記コンピュータサーバのプラグイン関数を実行して、前記ユーザインターフェースコマンドを実行し、
    前記ユーザインターフェースコマンド内に含まれないさらなるステップを実行するために、前記プラグイン関数を実行し、
    表示するために、結果を前記クライアントコンピュータデバイスに返す、方法。
57. 請求項５６に記載の方法であって、前記ユーザインターフェースコマンドは、情報の新規フォルダを作成するためのコマンドであり、前記方法は、さらに、
    前記クライアントコンピュータデバイスから前記新規フォルダの名称を受信し、前記名称を前記プラグイン関数への引数として用いて、前記さらなるステップを実行する、方法。
58. 請求項５６に記載の方法であって、前記ユーザインターフェースコマンドは、情報の新規ファイルを書き込むためのコマンドであり、前記方法は、さらに、
    前記新規ファイルを前記コンピュータサーバで受信し、
    前記新規ファイルに基づいてデータを作成して、前記さらなるステップを実行する、方法。
59. 請求項５８に記載の方法であって、さらに、
    表示するために、前記作成されたデータを前記クライアントコンピュータデバイスに返す、方法。
60. 請求項５８に記載の方法であって、さらに、
    前記作成されたデータを永久ストレージに書き込む、方法。
61. 請求項５６に記載の方法であって、前記ユーザインターフェースコマンドは、情報の新規ファイルを書き込むためのコマンドであり、前記方法は、さらに、
    前記新規ファイルを前記コンピュータサーバで受信し、
    前記フォルダ内以外のストレージに前記新規ファイルを書き込んで、前記さらなるステップを実行する、方法。
62. 請求項５６に記載の方法であって、前記ユーザインターフェースコマンドは、情報の新規ファイルを書き込むためのコマンドであり、前記方法は、さらに、
    前記新規ファイルを前記コンピュータサーバで受信し、
    前記フォルダに固有のメタデータと共に前記新規ファイルをストレージに書き込んで、前記さらなるステップを実行する、方法。
63. 請求項６２に記載の方法であって、前記メタデータは、前記フォルダの名称である、方法。
64. 請求項６２に記載の方法であって、前記メタデータは、前記クライアントコンピュータデバイスのユーザによって以前に入力されている、方法。
65. 請求項５６に記載の方法であって、前記ユーザインターフェースコマンドは、情報の前記フォルダを開くためのコマンドであり、前記方法は、さらに、
    前記フォルダのコンテンツを前記コンピュータサーバから前記クライアントコンピュータデバイスに返し、
    前記コンテンツは、まだ存在しないファイルの名称を含む、方法。
66. 請求項５６に記載の方法であって、前記ユーザインターフェースコマンドは、前記フォルダ内に存在するファイル名を有するファイルを読み込むためのコマンドであり、前記方法は、さらに、
    前記ファイルを作成して、前記さらなるステップを実行し、
    前記ファイルを前記クライアントコンピュータデバイスに返す、方法。
67. 請求項５６に記載の方法であって、前記ユーザインターフェースコマンドは、前記フォルダのファイルまたは前記フォルダを削除するためのコマンドであり、前記方法は、さらに、
    前記さらなるステップを実行するために、前記ファイルまたは前記フォルダの名称に基づいて、もしくは、前記ファイルまたは前記フォルダのコンテンツに基づいて、さらなる処理を実行する、方法。
68. 請求項５６に記載の方法であって、前記ユーザインターフェースコマンドは、前記フォルダまたはサブフォルダのファイルを移動させるためのコマンドであり、前記方法は、さらに、
    前記さらなるステップを実行するために、前記ファイルまたは前記フォルダの名称に基づいて、もしくは、前記ファイルまたは前記フォルダのコンテンツに基づいて、さらなる処理を実行する、方法。
69. コンピュータの仮想マシンにおいて、プラグイン関数からファイルシステムに書き込みを行う方法であって、
    リモートコンピュータデバイスの第１ユーザの要求に応じて、前記仮想マシンのプラグイン関数を実行し、
    ファイル名を有するファイルを前記プラグイン関数で受信し、
    前記プラグイン関数の識別子および前記第１ユーザの識別子に基づいて、前記ファイル名に対して一意ファイル名を作成し、
    前記コンピュータのローカルディスク上で前記ファイルを識別するために前記一意ファイル名を用いて、前記プラグイン関数によって前記ローカルディスク上のファイルシステムのユーザフォルダに前記ファイルを書き込む、方法。
70. 請求項６９に記載の方法であって、さらに、
    前記プラグイン関数が前記ローカルディスク上のディスクスペースを割り当てることなしに、前記プラグイン関数によってファイルを前記ローカルディスクに書き込む、方法。
71. 請求項７０に記載の方法であって、前記仮想マシンは、実行中のサーバプロセスを備え、前記方法は、さらに、
    前記サーバプロセスによって前記ローカルディスク上のスペースを割り当てる、方法。
72. 請求項７１に記載の方法であって、さらに、
    前記サーバプロセスによって、少なくとも１つのファイルを前記ローカルディスクからリモートオブジェクトストアにスワップアウトする、方法。
73. 請求項７２に記載の方法であって、前記少なくとも１つのファイルは、前記ローカルディスク上および前記リモートオブジェクトストア内で同じ一意名を有する、方法。
74. 請求項７０に記載の方法であって、前記仮想マシンは、実行中のサーバプロセスを備え、前記方法は、さらに、
    前記プラグイン関数の関与なしに、前記サーバプロセスによってファイルを前記ローカルディスクからリモートオブジェクトストアに移動させる、方法。
75. 請求項７０に記載の方法であって、前記プラグイン関数によって前記ローカルディスクに書き込まれる前記ファイルの量は、前記オブジェクトストアの容量によって制限される、方法。
76. 請求項７０に記載の方法であって、前記プラグイン関数によって前記ローカルディスクに書き込まれる前記ファイルの量は、前記コンピュータのオペレーティングシステムによって制限される、方法。
77. 請求項６９に記載の方法であって、前記ファイルの受信は、前記リモートコンピュータデバイスから前記ファイルを入力し、前記ファイルを作成し、リモートサービスから前記ファイルを入力し、または、既存のファイルを修正することを含む、方法。
78. 請求項６９に記載の方法であって、前記一意ファイル名は、前記ユーザの組織の識別子にも基づく、方法。
79. 請求項６９に記載の方法であって、さらに、
    第２リモートコンピュータデバイスの第２ユーザの要求に応じて、前記プラグイン関数を実行し、
    前記ファイルの前記ファイル名と同じ第２ファイル名を有する第２ファイルを前記コンピュータの前記ローカルディスク上で識別するために第２一意ファイル名を用いて、前記ローカルディスク上の前記ファイルシステムの前記ユーザフォルダに前記第２ファイルを書き込む、方法。
80. 請求項６９に記載の方法であって、さらに、
    前記ファイル名、前記プラグイン関数の前記識別子、および、前記第１ユーザの前記識別子を組み合わせることによって、前記一意ファイル名を作成する、方法。
81. コンピュータの仮想マシンにおいて、前記コンピュータのローカルディスクのスペースを管理する方法であって、
    前記ローカルディスク上で利用可能なストレージスペースを増やすか否かを、前記仮想マシンによって決定する工程と、
    利用可能なストレージスペースを増やすと決定された場合に、前記ローカルディスクから削除される格納ファイルを選択する工程と、
    前記格納ファイルを前記ローカルディスクからリモートストレージにコピーする工程と、
    前記格納ファイルによって利用されていた前記ローカルディスク上のスペースを解放する工程とを備える、方法。
82. 請求項８１に記載の方法であって、前記方法の前記工程は、バックグラウンドで実行し、前記決定する工程は、定期的に実行されるか、または、前記ローカルディスク上で利用可能なスペースが閾値数未満であると判定された時に実行される、方法。
83. 請求項８１に記載の方法であって、さらに、
    新規ファイルを前記ローカルディスクに書き込むための要求を前記仮想マシンの別のプロセスから受信する工程と、
    前記ローカルディスク上で利用可能なストレージスペースを増やすか否かを、前記要求に基づいて決定する工程と、
    前記スペースを解放する工程の後に、前記新規ファイルを前記ローカルディスクに書き込む工程と、
    を備える、方法。
84. 請求項８３に記載の方法であって、さらに、
    前記ローカルディスク上で利用可能なストレージスペースを増やすか否かを、利用可能なストレージスペースまたは前記ローカルディスク上で利用可能なアイノードスペースにも基づいて決定する工程を備える、方法。
85. 請求項８３に記載の方法であって、前記要求は、前記ローカルディスク上のファイルシステムのユーザフォルダに前記新規ファイルを書き込むための要求である、方法。
86. 請求項８１に記載の方法であって、さらに、
    前記決定する工程の前に、前記仮想マシンの別のプロセスによって、前記ローカルディスク上のファイルシステムのユーザフォルダに前記格納ファイルを書き込む工程と、
    前記コピーする工程の後に、前記ファイルシステムの前記ユーザフォルダから前記格納ファイルを要求することにより、前記仮想マシンの前記別のプロセスによって前記格納ファイルを読み出す工程と、
    前記サーバプロセスによって前記格納ファイルを前記リモートストレージから前記ローカルディスクに移動させる工程と、
    を備える、方法。
87. 請求項８１に記載の方法であって、さらに、
    前記格納ファイルが最も長い間利用されていないことに基づいて、前記格納ファイルを選択する工程を備える、方法。
88. 請求項８１に記載の方法であって、さらに、
    前記格納ファイルをリモートストレージにコピーして、前記ローカルディスクに前記格納ファイルを格納するために用いたのと同じ名称を用いて前記格納ファイルを格納する工程を備える、方法。

Images