JPH11213012A - データ処理システムにおけるプロセッサ・インテンシブ・オペレーションを処理する方法及びシステム - Google Patents

Abstract

(57)【要約】 【課題】リクエストされたデータ検索オペレーションか
ら、特定の処理タスクが遂行される必要のあるオペレー
ションを識別し、その処理タスクを必要としないオペレ
ーションからそれらのオペレーションを分離するデータ
検索のためのシステム及び方法を提供する。 【解決手段】分離されたタスク・セットは独立した処理
のために別個に待ち行列化される。これは、そのタスク
の遂行を必要としないオペレーションが、そのタスクを
必要とするオペレーションを待つ必要をなくすという資
源スケジューリングが遂行されることを可能にする。こ
れは、そのタスクがイメージのディジタル透かし入れの
ようなプロセッサ・インテンシブ・タスクである場合の
利点である。特定の資源割り振り方法では、処理タスク
を必要とするオペレーションのセットが、循環的にリン
クされたリストにおいて待ち行列化され、しかる後、ス
ケジューラを使用して各システム・ユーザに対して資源
のラウンド・ロビン割り振りが順次実施される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はデータ処理システム
及び方法に関するものであり、更に詳しく云えば、コン
ピュータ・ベースのデータ検索システムのようなデータ
処理システムにおいてプロセッサの負荷の大きいプロセ
ッサ・インテンシブ・オペレーションを処理するための
方法及びシステムに関するものである。本発明は、デー
タ処理システムにおける資源を割り振るために有用であ
り、或いはデータ・アクセス遅延を減少させるためにも
有用である。

【０００２】

【従来の技術】分散ネットワークにおける多数のコンピ
ュータ端末の任意のものからアクセス可能であるデータ
・ライブラリはその技術分野ではよく知られている。イ
ンターネット、イントラネット、及びワールド・ワイド
・ウェブが人気を得ており、イメージ・システムが益々
広範に利用可能になるにつれて、イメージ及び他のデー
タ・オブジェクトのライブラリが複数のコンピュータに
記憶され、多くの人によるアクセスのためにインターネ
ット又はイントラネットを介して接続されている。例え
ば、個々の人が、インターネットに接続されたクライア
ント・コンピュータ上にインストールされたウェブ・ブ
ラウザを使用して、イメージのような必要なオブジェク
トのコピーをリクエストすることができる。

【０００３】多くのユーザにとってアクセス可能である
イメージのようなデータ・オブジェクトの作成は、悪意
のある関係者がサーバ上のイメージを偽造イメージと置
換するか或いは他に伝送されたイメージを傍受して置換
するための機会を作り出すことができる。更に、複雑な
イメージ編集ソフトウエアの開発と共に、任意のディジ
タル・イメージの内容の容易な変更を可能にするツール
が広く使用可能である。従って、ディジタル的に記憶さ
れたイメージの保全性は、安全機能が設けられてない場
合には問題となることがある。

【０００４】イメージのソース及び保全性の検証（即
ち、それに対する何らかの変更の検出）を可能にする透
かし入れ及びディジタル・シグニチャ技法、並びに、ユ
ーザがそのイメージへのアクセスを承認されていること
を（リクエスタがディジタル・シグニチャを知っている
場合にだけアクセスを可能にすることによって）チェッ
クし、その後に未承認のコピーを識別することを可能に
するための手段が開発されている。従って、透かし入れ
及びディジタル・シグニチャ技法は、イメージ所有者及
び許可者をには有益であり、イメージ・アクセスをリク
エストする者にとっても有益である。

【０００５】エンド・ユーザは、次のような場合、イメ
ージ・ファイルをリクエストした時にイメージのディジ
タル・シグニチャを指定してもよい。 （ａ）データ検索システムが、ファイルを配送する前に
これを必要とする場合、又は（ｂ）イメージがユーザに
配送される前に、ユーザがそのイメージの認証及び保全
性をチェックしたい場合、更に、データ検索サーバは、
たとえユーザがシグニチャを知る必要がない場合でも、
イメージの動的ディジタル・シグニチャ・チェックを行
うように適応可能である。

【０００６】ディジタル・シグニチャ・チェックに加え
て、サーバ・コンピュータは、それがオブジェクトのコ
ピーに対するリクエストを受ける時、すべての記憶され
たオブジェクトに対して、或いは、或るカテゴリのオブ
ジェクト又は或るカテゴリのリクエスタに対して、透か
し入れプロセスを動的に実行するように適応可能であ
る。この透かし入れは、その後の識別及び検証を可能に
する。ディジタル・イメージ・ライブラリに記憶された
イメージは透かしを持たないことがあるので、配布者又
はリクエスタの身元のような情報を組み込むためには、
コピーを分配する前にイメージを透かし入れすることが
望ましいかも知れない。

【０００７】透かし入れを動的に行う（即ち、通常の方
法であるオブジェクトがリポジトリに記憶される時又は
もっと早い時期ではなく、オブジェクトがリポジトリか
らリクエストされる時に）システムによって生じる問題
は、オブジェクトが分配されるのを待つ間、エンド・ユ
ーザが受けることのある時間遅れである。動的な透かし
入れは、オブジェクト検索における遅れの可能性に通じ
るコンピュータのプロセッサ・インテンシブ・オペレー
ションである。これらの遅延は、同時に処理されるリク
エストの数と共に増加する。

【０００８】そのような遅延は、シグニチャ・チェック
又は透かし入れを必要としないオブジェクトをリクエス
トしたユーザにとって特に望ましくないものと考えられ
る。それは、この場合、それらの検索及び配送オペレー
ションは比較的わずかな処理に関与するだけであるの
に、他のユーザに対するオブジェクトのディジタル透か
し入れによってかなり遅延させられることがあるためで
ある。

【０００９】

【発明が解決しようとする課題】本発明の第１の局面
は、データ検索のための方法及びシステムを提供するこ
とにある。

【００１０】本発明の第２の局面は、データ検索システ
ムのユーザ間でデータ処理資源を割り振るための方法及
びシステムを提供することにある。

【００１１】

【課題を解決するための手段】前記第１の局面に対する
方法は、データ検索システムによるデータ検索リクエス
トの受信に応答して、第１所定タスクが遂行されること
を必要とするリクエストされたデータ検索オペレーショ
ンを識別し、前記第１所定タスクが遂行されることを必
要とするデータ検索オペレーションだけを第１処理キュ
ーに入力し、前記第１所定タスクが遂行されることを必
要としないデータ検索オペレーションを、前記第１所定
タスクを遂行することなく処理し、前記第１処理タスク
の遂行を含む、前記第１処理キューにおけるデータ検索
オペレーションを処理することを含む。

【００１２】本発明によるデータ検索方法は、望ましく
は、更に、第２所定タスクを必要とするが前記第１所定
タスクを必要としないデータ検索オペレーションを前記
第１処理キューとは別個の第２処理キューに入力するこ
と、及び前記第１及び第２処理キューを独立して処理す
ることを含む。

【００１３】第１所定タスクは、望ましくは、透かし入
れプロセスの遂行である。プロセッサ・インテンシブで
ある検索及び透かし入れオペレーションから簡単な検索
を分離することによって、透かし入れを必要としない検
索オペレーション（従って、ユーザ）が、透かし入れを
必要とするデータ・オブジェクトをリクエストしたユー
ザの資源要求によって過度にインパクトを受けないよう
にすることが可能である。

【００１４】本発明の一実施例による方法及びシステム
は、透かし入れが必要であるかどうか及び第２の検索後
処理タスク（ディジタル・シグニチャ・チェック、或い
はＴＩＦＦフォーマットからＪＰＥＧフォーマットへの
変換のような）が必要であるかどうかの両方を各受信し
たリクエストに対して決定する。そこで、簡単なデータ
検索オペレーション及びシグニチャ・チェック付き検索
オペレーションがフォーマット変換付き検索オペレーシ
ョンから分離可能となり、これらのオペレーションすべ
てが透かし入れ付き検索オペレーションから分離され
る。

【００１５】本発明の別の実施例は、リクエストされた
オブジェクトのサイズ及びそれに関して遂行されるべき
特定のタスクの両方に従って処理オペレーションを分離
することが可能である。

【００１６】従って、リクエストされたデータ検索オペ
レーションは、その処理を実行するという予測された資
源要件に従って処理するために分離される。これは資源
割り振りの改良を促進し、プロセッサ・インテンシブで
ないオペレーションの場合に遭遇する遅延の減少を可能
にする。

【００１７】１つ又は複数の所定のタスクの遂行を必要
とするデータ検索オペレーションは、望ましくは、受信
されたリクエストから得られるデータ・オブジェクト識
別子とオブジェクト・タイプのテーブル及び各タイプに
対する必要な処理タスクとを比較することによって識別
される。

【００１８】第１及び第２処理キューは、望ましくは、
リクエストされたデータ検索オペレーションが加えられ
る循環的にリンクされたリストであり、それらデータ検
索オペレーションは、それらのエンド・ユーザ・リクエ
スタのＩＤに従ってインデックスされる。第１リング
（循環的にリンクされたリスト）における各ノードは、
プロセッサ・インテンシブな第１の検索後タスクを必要
とするそれぞれのユーザに対して遂行されるべきすべて
のオペレーションのリストを含み、第２リングにおける
各ノードは、第２の検索後タスクを必要とするそれぞれ
のユーザに対して遂行されるべきすべてのオペレーショ
ンのリストを含む。

【００１９】各循環的にリンクされたリストの独立した
処理は、望ましくは、それぞれのリンクされたリストに
おけるユーザのタスクが注意を払われる時にいつも各ユ
ーザに対して所定量の処理が遂行される場合、スケジュ
ーラの制御の下に「ラウンド・ロビン」を原則とする複
数のユーザの各々に対するサービスを伴う。この「所定
量の処理」は、望ましくは、各ユーザに対する等量の処
理時間（例えば、２秒のＣＰＵタイム）、或いは各ユー
ザに対する１つ又は複数のリクエストされたオブジェク
トのための１つ又は複数の特定の処理タスクの完了であ
る。別の方法として、種々のカテゴリのユーザに対し
て、所定量の、しかし異なる量の処理が遂行されてもよ
い。

【００２０】前記第２の局面に対する方法は、データ検
索システムおけるスケジューラにデータ検索リクエスト
を入力し、所定のプロセッサ・インテンシブ・タスク
（例えば、透かし入れ）の遂行を必要とするリクエスト
されたデータ検索オペレーションを識別し、リクエスト
されたデータ・オブジェクトをリポジトリから検索し、
前記所定のタスクの遂行を必要とし、エンド・ユーザ・
リクエストに従ってインデックスされるデータ検索オペ
レーションを第１の循環的にリンクされたリストに入力
し、前記所定のタスクの遂行を必要としないデータ検索
オペレーションを、前記所定のタスクを遂行することな
く処理し、事前定義された処理単位が各エンド・ユーザ
・リクエスタのために順次遂行されるように、前記所定
のタスクを遂行することを含む前記第１の循環的にリン
クされたリストにおけるデータ検索オペレーションを循
環シーケンスで処理することを含む。

【００２１】前記所定のプロセッサ・インテンシブ・タ
スクを必要としないデータ検索オペレーションの処理
は、単に、検索後処理を遂行することなくリクエスタへ
の配送を伴い得るものである。別の方法として或いは付
加的に、第１のプロセッサ・インテンシブ・タスクを必
要としないが、異なる検索後タスク（例えば、ＴＩＦＦ
フォーマットからＪＰＥＧフォーマットへの変換、又は
ディジタル・シグニチャ・チェック）を必要とするデー
タ検索オペレーションは、前記第１の循環的にリンクさ
れたリストとは別の第２の循環的にリンクされたリスト
に入力可能である。なお、第２リストにおけるオペレー
ションは、それらのエンド・ユーザ・リクエスタに従っ
てインデックスされる。そこで、各リストに対して、事
前定義の処理単位が各エンド・ユーザ・リクエスタのた
めに順次に遂行されるように、第２リストが第１リスト
の処理とは無関係に循環シーケンスで処理される。

【００２２】ディジタル・オブジェクト・ライブラリか
らのオブジェクトを待つことによりユーザが費やす時間
は、望ましくは、各プロセッサに対するＣＰＵインテン
シブな透かし入れプロセスを単に１つに制限することに
よっても減少する。複数のプロセッサ（１つ又は複数の
コンピュータにおける）が使用可能である場合、処理の
スループットに悪影響を与えることなく、それらを走ら
せるプロセッサと同じ数の透かし入れスレッドが存在す
るように、各々が透かし入れプロセスを走らせてもよ
い。

【００２３】各プロセッサに対して１つの透かし入れス
レッドに制限することは、単一のプロセッサ上で同時に
走る複数のプロセッサ・インテンシブ・スレッドに起因
する全体的なスループットの減少を回避することができ
る。これは、本発明の好適な実施例では、各プロセッサ
において１つのそのようなスレッドを開始するだけであ
って前の透かし入れオペレーションが完了した時だけ透
かし入れプロセスの入力キューから新しいタスクを得る
制御プロセスによって得られる。これは、リクエストが
受信されそしてそれを処理するために透かし入れプロセ
スの現在使用可能なインスタンスが存在しない時にいつ
も透かし入れプロセスの新しいインスタンスを呼び出す
という別の方法とは区別される。

【００２４】動的な透かし入れは非常にプロセッサ・イ
ンテンシブであるので、一時に１つのそのようなオペレ
ーションが効果的に処理可能である。同じプロセッサ上
で同時に走っている２つの透かし入れプロセスは、各プ
ロセスが直列的に走っている場合に要する長さの２倍以
上をそれらのタスクに取らせることになろう。それは、
プロセッサの使用が切り替えられる時にいつもわずかな
遅延が存在するためである。従って、ユーザは、そのユ
ーザがアクセスしたい２つのオブジェクトのうちのどち
らか１つにおいて遅延を受けるであろう。例えば、オブ
ジェクトが透かし入れのために１０秒を要する場合、単
一のプロセッサ上で２つの透かし入れスレッドを並列に
走らせることは、一時に１つずつそれらを透かし入れす
るために要する２１秒ではなく２４秒を要するであろ
う。

【００２５】各プロセッサ当たり１つの透かし入れスレ
ッドに制限することは、それが本発明の更なる局面に従
って実施される時に特に有利である。この更なる局面で
は、イメージは、ページ・セットにおけるページをハイ
アラーキ的配列で記憶される。なお、各ページはフル・
イメージ、サムネール（ｔｈｕｍｂｎａｉｌ）イメー
ジ、及びディジタル・シグニチャを含む。イメージを含
むページ・セットへのアクセスを求めるユーザのリクエ
ストに対するシステムの応答は、次のようなステップを
遂行することである。即ち、 （１）ページ・セットのページ内のすべてのサムネール
・イメージをリポジトリから検索し、それらのサムネー
ル・イメージをリクエスタに送る； （２）ページ・セットのページ内のすべてのフル・イメ
ージをリポジトリから検索し、前記フル・イメージのう
ちの選択された１つ又は複数のフル・イメージを求める
その後のユーザ・リクエストを予測してフル・イメージ
のディジタル・シグニチャ・チェック及び動的な透かし
入れを開始する。

【００２６】透かし入れは各プロセッサに対して単一の
スレッドによって行われるので、プロセッサを過負荷に
する可能性が減少し、透かし入れされたフル・イメージ
のうちの或るものが受容可能な時間内にサーバのキャッ
シュ・メモリにおいて使用可能となる可能性が増加す
る。

【００２７】更に、好適な実施例によれば、本発明は次
のような３つの機能の結合を利用する。即ち、（１）特
定のイメージに対するエンド・ユーザ・リクエストに先
だって透かし入れするためのフル・イメージをプリフェ
ッチすること、（２）特定のイメージのユーザ選択の前
に各プロセッサにおける単一のプロセスによってこれら
のフル・イメージの透かし入れを開始すること、（３）
イメージがエンド・ユーザによってサムネール・イメー
ジのセットから選択されたことに応答して透かし入れさ
れるべきイメージのキュー内のイメージをプロモートす
ること。従って、選択されたイメージは、現在進行中の
透かし入れタスクの終了に続いて処理するための次のイ
ン・ラインとなるようにプロモートされる。

【００２８】ユーザ選択に応答してプロモーションを可
能にすることによって、処理するためにイメージをプリ
フェッチしそして各プロセッサ上で走っているプロセッ
サ・インテンシブ・プロセスを１つに制限するシステム
では、ユーザ・アクセス遅延はかなり減少する。

【００２９】本発明による方法、データ検索システム、
及び資源マネージャは、コンピュータ読み取り可能な媒
体上に記憶されたコンピュータ読み取り可能なプログラ
ム・コードより成るコンピュータ・プログラム製品にお
いて実施可能である。

【００３０】本発明は、特に、コンピュータ・ベースの
イメージ・ライブラリによる使用に適しているが、デー
タ検索リクエストのうちの或るものは比較的遅い処置オ
ペレーションが遂行されることを必要とし、他のものは
それを必要としないというデータ検索システムによる任
意のデータ・オブジェクトの検索ために使用可能であ
る。「高速」検索リクエストの過度な遅延は、それらの
処理を「低速」検索リクエストの処理から分離すること
によって回避可能である。

【００３１】

【発明の実施の形態】本発明の実施例に従って本発明を
インプリメントするクライアント／サーバ分散データ検
索システムが図１に示される。サーバ・コンピュータ上
に導入されたデータ検索管理ソフトウエアを含むデータ
検索システム１０は、ディジタル・データ・リポジトリ
（ライブラリ）２０における記憶されたオブジェクトを
アクセスするように接続される。その技術分野では知ら
れているように、リポジトリは、データ検索システムの
サーバ・コンピュータに対する周辺装置であるディスク
記憶装置又は他のサーバ・コンピュータと関連したディ
スク記憶装置によって提供可能であり、或いはディジタ
ル・イメージ・ライブラリが複数の記憶システムに跨っ
て分散されてもよい。データ検索システムは、複数のラ
イブラリ又はリポジトリにアクセスするために分散ネッ
トワーク内に接続されてもよい。

【００３２】データ検索システム１０は１つ又は複数の
クライアント・システム３０に接続される。そのクライ
アント・システム３０から、ライブラリ・アクセスを求
めるエンド・ユーザ・リクエストが受信される。データ
検索システム１０は資源マネージャ１２を含む。なお、
その資源マネージャに関しては詳しく後述することにす
る。

【００３３】各クライアント・システムは、既知の "Ｎ
ｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ"（商標）ブラウ
ザのようなウェブ・ブラウザ・ソフトウエア３２を具備
している。データ検索システム１０は、ネットワークを
通して受信し且つウェブ・ブラウザ・リクエストに応答
するためのウェブ・サーバ・ソフトウエア３４を含む。
（好適な実施例では、クライアント、サーバ、及びデー
タリポジトリはイントラネットを通してコミュニケート
するが、これは、外部のエンド・ユーザによるアクセス
が必要とされる場合、インターネットを通して或いは任
意の適当なネットワークを通して同様に実施されてもよ
い）。

【００３４】クライアント・システム３０は、オブジェ
クト・コンテナ名及び関連のオブジェクト・メタデータ
を記憶するデータベース３６を含み、ユーザは、クライ
アント・リクエストを発生する時、そのデータベースか
ら名前を選択する。これらのオブジェクト・コンテナ名
は、ライブラリに記憶されたオブジェクト・コンテナを
識別するために使用される。クライアント・コンテナ名
は、ディジタル・データ・ライブラリにおいて使用され
るような実際に記憶されたオブジェクト名又はオブジェ
クト・コンテナ名ではない。それは、ディジタル・デー
タ・ライブラリにおけるオブジェクトへのエンド・ユー
ザのアクセスを、ウェブ・ブラウザ・リクエストに応答
してデータ検索システム１０により自動的に遂行される
データ検索オペレーションを通したアクセスに制限する
ことが、セキュリティ上の理由で及びシステムの複雑性
からユーザを遮蔽するためには望ましいためである。

【００３５】従って、第１セットの名前がクライアント
・データベース３６に記憶され、第２セットの名前がデ
ィジタル・データ・ライブラリ２０において使用され
る。又、そのデータ検索システムにおける名前インター
プリタ（ネーミング・システム）４６は、記憶されたオ
ブジェクトを識別するために、第１セットにおける名前
を解釈して第２セットにおける名前を得る。

【００３６】データ検索システム１０には、リクエスト
されたイメージに透かしを動的に施すための、即ち、イ
メージがリクエスタへ配送するためにライブラリから検
索される時にイメージに透かしを施すための透かし入れ
プロセス３８がある。伝統的なディジタル透かし入れ
は、ライブラリにオブジェクトを加える時に遂行される
か、又は透かし入れプロセスを完了するために要する時
間があまりクリティカルでない場合に検索に関係ない任
意の時間に遂行される。

【００３７】本発明は透かし入れ及び他のタスクの有利
なスケジューリングを提供するが、透かし入れプロセス
３８によって実施される透かし入れアルゴリズムの詳細
は本発明にとってクリティカルではなく、動的な透かし
入れに適した可視的な又は非可視的な任意の既知の透か
し入れアルゴリズムであってもよい。透かし入れプロセ
ス３８によって符号化された情報の性質も本発明にとっ
てクリティカルではないが、イメージ所有者の会社ロゴ
又はリクエストしたエンド・ユーザのＩＤ、或いはライ
ブラリからの検索の日付及び時刻を含んでもよい。

【００３８】サーバ１０における更なるプロセスはディ
ジタル・シグニチャ・チェック・プロセス（図示されて
いない）である。透かし入れプロセス及びディジタル・
シグニチャ・チェック・プロセスは資源マネージャ１２
と同じサーバ・コンピュータ上で走る必要はない（それ
らの機能が分散されてもよい）が、説明を簡単にするた
めに、本願では、単一のサーバ・コンピュータの使用を
述べることにする。本発明の好適な実施例ではサーバ上
で走る更なるプロセスは、ファイル・フォーマット変換
プロセス（図示されていない）である。イメージは、タ
グ・イメージ・ファイル・フォーマット（ＴＩＦＦ）で
イメージ・ライブラリにおいて保持される。それは、こ
れが高いイメージ品質を維持するためである。しかし、
ＴＩＦＦファイルは特別のビュアを必要とし、従って、
ＴＩＦＦファイルはエンド・ユーザに配送する前にＪＰ
ＥＧファイル・フォーマット（即ち、ジョイント・フォ
トグラフィック・エキスパート・グループ標準に適合し
たフォーマット）に変換される。そのフォーマットは更
に大きな圧縮を可能にし、通常のウェブ・ブラウザの制
御の下で表示可能である。

【００３９】次に、エンド・ユーザ・リクエストに応答
したシグニチャ・チェック、フォーマット変換、及びイ
メージの透かし入れに伴うオペレーションのシーケン
ス、及び透かし入れを伴う及び透かし入れなしのイメー
ジのエンド・ユーザへの配送を、図２乃至図１２を参照
して更に詳細に説明することにする。

【００４０】エンド・ユーザはクライアント・システム
３０におけるクライアント・データベース３６と対話
し、クライアント・オブジェクト・コンテナ名（クライ
アント・データベース３６に記憶された名前から選択さ
れた）を指定する選択によってクライアント・リクエス
ト１００を開始させる。エンド・ユーザの選択はクライ
アント・システムにおけるアプレット４０（Ｊａｖａプ
ログラミング言語で書かれた）を呼び出す。そのアプレ
ットは、ウェブ・ブラウザ３２を開始させ、クライアン
ト・コンテナ名を含む発生されたユニフォーム資源ロケ
ータ（ＵＲＬ）を伴うウェブ・ブラウザ・リクエストを
アセンブルする（ステップ１１０）。このリクエストは
イントラネットを通して、データ検索システム１０上で
走るウェブ・サーバ３４に送られる（ステップ１２
０）。

【００４１】サーバ・システム１０は、複数のデータ検
索及びイメージ・プロバイダ「サーブレット（ｓｅｒｖ
ｌｅｔ）」４４（即ち、ＵＲＬによって参照され、ウェ
ブ・サーバ上で走るＪａｖａアプレット）を走らせる。
それらのうちの第１のサーブレットは、受信したブラウ
ザ・リクエストをデータ検索システムの資源マネージャ
１２に送る（ステップ１３０）ためのものであり、第２
のサーブレットは、イメージをクライアントに送って処
理する（ステップ１４０）ためのものである。ウェブ・
サーバによって受信されたリクエストは、これらのサー
ブレットのうちの第１のものを介して資源マネージャ１
２に送られ、資源マネージャ１２における名前インター
プリタ４６は、その受信したリクエストのクライアント
・コンテナ名を、ディジタル・ライブラリが理解し得る
オブジェクト・コンテナ名に変換する（ステップ１５
０）。

【００４２】名前の変換を行ってしまうと、資源マネー
ジャは、先ず、キャッシュ・マネージャ５０をトリガし
て、そのリクエストされたデータ・オブジェクトがサー
バ・システム１０のローカル・キャッシュ・メモリ５２
において現在得られるものであるかどうかをチェックす
る（ステップ１６０）。リクエストしたクライアントへ
の配送に備えてオブジェクトが既にキャッシュに記憶さ
れている場合、それらのオブジェクトは単にイメージ・
プロバイダ・サーブレット４４に供給され、ウェブ・サ
ーバの機能を使用してクライアント・システムに配送さ
れる（ステップ１４０）。

【００４３】クライアント・データベースからのユーザ
選択に続いてクライアント・システムにおいて発生され
たリクエストに対する初期応答は、オブジェクトがキャ
ッシュ・メモリにおいて得られる時、後述するように、
サムネールのセット及びそれらのサムネールと関連した
フル・イメージに対するＵＲＬをクライアント・システ
ムに戻すことである。別の方法では、オブジェクトがデ
ータ・ライブラリから検索されなければならず、それら
の検索されたオブジェクトの多くは配送前に処理を必要
とするであろう。

【００４４】ウェブ・サーバは、表示を編成及び管理す
るために（レンダリング１７０）及びフレーム内のアク
セスされたイメージを印刷するために、第１の配送され
たデータオブジェクトと共にＪａｖａアプレット４２を
クライアント・システムに供給する。そのようなレンダ
ラ・アプレット４２のダウンローディングはその技術分
野では知られている。

【００４５】クライアント・システムのウェブ・ブラウ
ザは、アプレット４２によってレンダされたイメージの
プレゼンテーションを通常の方法で処理する。その技術
分野では知られているように、エンド・ユーザへのプレ
ゼンテーションのために発生されたページは、組み込ま
れたＵＲＬと共にイメージのサムネールのセットを含
み、それらのサムネールによって表されたフル・イメー
ジのうち、エンド・ユーザが受信することを望んでいる
ものをそのエンド・ユーザが選択することを可能にする
（ステップ１８０）。

【００４６】ディジタル・データ・ライブラリにおける
データ・オブジェクトの編成は、後述するように、検索
後の処理及びエンド・ユーザへのイメージの配送の効率
的なスケジューリングを容易にする。イメージ・オブジ
ェクトは、１つ又は複数のドキュメント・フォルダにお
けるハイアラーキ・グループのディジタル・データ・ラ
イブラリに記憶される。なお、各フォルダは、１つ又は
複数のページ（アネックス１．．．Ｎと呼ばれる）より
成る少なくとも１つのセット及び一般には複数のセット
を含む。アネックスにおける各ページは次のような付属
のオブジェクト、即ち、イメージ（ＴＩＦＦファイ
ル）、サムネール・イメージ（ＪＰＥＧファイル）、及
びディジタル・シグニチャを有する。このハイアラーキ
は次のように表される。 Doc=Folder { Annex=SET of Folder { Contains SET of Page [ Image TN Digital Sig ] } }

【００４７】クライアント・データベースとのユーザ対
話に応答してクライアント・システムから最初に受信さ
れたリクエストにおけるオブジェクト・コンテナ名は、
アネックス・レベル（実際には、そのシステム内では一
意的であると仮定されるフォルダＩＤ及びアネックスＩ
Ｄの組合せ）でオブジェクト識別子に変換されされるで
あろう。従って、リクエストされたデータ検索の期待さ
れる結果は、単一のデータ・オブジェクトではなくペー
ジのセットになるであろう。これは、それらのオブジェ
クトのうちの個々のものがエンド・ユーザによって選択
されてしまう前にアネックス内のオブジェクトの検索後
の処理を始める機会をデータ検索システムに与える。そ
れは、選択の後のユーザ待ち時間を減少させる助けとな
る。これについては後で更に説明することにする。

【００４８】１つ又は複数のリクエストされたオブジェ
クトがサーバ・キャッシュ・メモリにおいて得られない
時、資源マネージャはその受信されたリクエストをキュ
ー・マネージャ４８に送る（ステップ１９０）。そのキ
ュー・マネージャは、リクエストしたエンド・ユーザの
ＩＤ及びリクエストされたアネックスの名前をそのリク
エストから得る。そこで、その受信されたリクエスト
は、遂行されるべきデータ検索オペレーションのリスト
（単一のＦＩＦＯキュー）に置かれる。

【００４９】キュー・マネージャ４８は、このリストを
ネーム・インタープリタ４６から受信する時、そのリス
トにおける各エレメントに対するフラッグをチェックす
る（ステップ２００）。それらのフラッグは、エレメン
トが（前のリクエストに応答して）処理のために既に待
ち行列化されているかどうかを表す。このチェック（ス
テップ２００）がリストにおける非未処理の検索オペレ
ーションの存在を決定する場合、キュー・マネージャ
は、リスト全体を資源マネージャのディジタル・データ
・ライブラリ接続コンポーネント５４に供給する（ステ
ップ２１０）。データ・ライブラリ接続コンポーネント
５４は、結果ベクトル（データ検索の結果をキュー・マ
ネージャに戻すためのホルダである当初はエンプティの
リスト或いはアレイ）を作成し（ステップ２２０）、リ
ストにおける非未処理のエレメントを識別するために各
リスト・エレメントをチェックし（ステップ２３０）、
しかる後、これらの非未処理のエレメントを処理のため
に除去する（ステップ２４０）。

【００５０】次に、ディジタル・データ・ライブラリ接
続コンポーネントは、現在必要とされるアネックスにお
ける如何なるサムネールもキャッシュ・メモリにおいて
得られないかどうかを決定し（ステップ２５０）、キャ
ッシュ・メモリにないサムネールをリポジトリ２０から
検索する（ステップ２６０）。次に、データ・ライブラ
リ接続コンポーネントは、このアネックスにおける如何
なるフル・イメージもキャッシュ・メモリにおいて得ら
れないかどうかを決定し（ステップ２７０）、キャッシ
ュ・メモリにないフル・イメージをリポジトリから検索
する（ステップ２８０）。

【００５１】前述のように、クライアント・データベー
スに対するインターフェースとのユーザ対話に応答して
クライアント・システムにおいて自動的に発生されたリ
クエストは、アネックスの内容（即ち、イメージ・オブ
ジェクト、サムネール・オブジェクト、及びディジタル
・シグニチャ・オブジェクトを付加されたページのセッ
ト）の検索を導くであろう。実際には、これは、既にキ
ャッシュ・メモリにあるものに関する３つのチェック及
びページ・セットの３つのスキャンを伴う。それら３つ
の別個のスキャンの１つは未だキャッシュにないそのセ
ットにおけるすべてのサムネールを検索し、もう１つは
キャッシュにないすべてのフル・イメージを検索し、も
う１つはキャッシュにないすべてのシグニチャを検索す
る。

【００５２】そこで、データ・ライブラリ接続コンポー
ネントは、それの検索スキャンの結果をそのリクエスト
に対するそれの結果に加える（ステップ２８０）。リス
トに更なるデータ検索オペレーション（又は「エレメン
ト」）が存在する場合（ステップ２９０）、データ・ラ
イブラリ接続コンポーネントはそのリストから次のエレ
メントを取り出して処理し、すべてのエレメントが処理
されてしまうまでこれを繰り返す。そこで、データ・ラ
イブラリ接続コンポーネントはそれらの結果ベクトルを
キュー・マネージャに戻す（ステップ３００）。

【００５３】次に、キュー・マネージャは、ユーザのリ
クエストが満たされる前にそのユーザが受ける遅延を最
小にしながら、特に、有用な処理資源を必要としないリ
クエストに対する遅延を最小にしながら、種々のエンド
・ユーザの間の処理資源の公平な割り振りを保証すると
いう方法でその受信した結果ベクトルを処理する。これ
に関しては、次に、更に詳しく説明することにする。

【００５４】キュー・マネージャ４８は、遂行されるべ
き種々の検索後（ｐｏｓｔ−ｒｅｔｒｉｅｖａｌ）処理
のタスクのための異なるタイプのイメージを分離すると
いう方法を実施する。この方法は、本発明の種々の実施
方法に対するシステム管理者によって修正可能であり、
次表のように表される。

【表１】

【００５５】キュー・マネージャ４８は結果ベクトルに
おけるフラッグを通してサムネールを識別し、受信した
結果ベクトルからサムネール・イメージを分離し、これ
らを、更に処理することなくキャッシュ・マネージャ５
０に送る（ステップ３１０）。キャッシュは、サムネー
ルが使用可能であることをイメージ・プロバイダ・サー
ブレット４４に直接に応答する（ステップ３２０）。そ
こで、イメージ・プロバイダ・サーブレットは、ユーザ
のリクエストと関連したサムネールを含むファイルを検
索し（ステップ３３０）、それらサムネール・イメージ
をクライアント・システムに供給する（ステップ１４
０）。クライアント・システムにおいて、それらはエン
ド・ユーザへの表示のためにレンダされる（ステップ１
７０）。そこで、ユーザはその表示されたサムネールか
ら所望のメイン・イメージを選択し、リクエストする
（ステップ１８０）。

【００５６】結果ベクトルにおける残りのデータ・オブ
ジェクトはフル・イメージ及びそれらの関連のディジタ
ル・シグニチャである。これらは、検索後処理のジョブ
の入力リストを形成する。キュー・マネージャはこのリ
ストの先頭から第１ジョブを取り出し（ステップ３４
０）、承認されたユーザのルックアップ・テーブルとリ
クエスタＩＤを比較して、透かし入れが必要とされるか
どうかを決定する（ステップ３５０）。そのテーブルに
おいて一致がない場合、透かし入れが必要とされる。必
要とされる処理に従って、処理されるべきデータ・オブ
ジェクトが２つの循環的にリンクされたリストの１つに
置かれる（ステップ３８０、４１０）。循環的にリンク
されたリストは図１３において概略的に表される。

【００５７】承認されたユーザとしてのリクエストが透
かし入れを必要としないことを確認する一致が存在する
場合、シグニチャ・チェック及びフォーマット変換のた
めにオブジェクトが検索される循環的にリンクされたリ
ストに、そのデータ・オブジェクトは置かれるべきであ
る。遂行されるべき処理オペレーションは透かし入れに
比べて相対的に速いので、この循環的にリンクされたリ
ストを「高速リング」と呼ぶことにする。ユーザが既に
この高速リングにおけるエントリを有するかどうかのチ
ェックが行われる（ステップ３９０）。その結果が肯定
である場合、このデータ・オブジェクトを処理するとい
うジョブが高速リング内のユーザのジョブ・キューに加
えられる（ステップ４１０）。その結果が否定である場
合、高速リングにおけるエントリは、ユーザのキューに
ジョブを加える前に作成される（ステップ４００）。

【００５８】ＩＤルックアップ・テーブルにおいて一致
が存在しない場合、ユーザが「低速リング」（透かし入
れを必要とするジョブの循環的にリンクされたリスト）
においてエントリを有するかどうかのチェックが行われ
る（ステップ３６０）。その結果が否定である場合、エ
ントリが作成される（ステップ３７０）。そこで、その
処理ジョブが低速リングにおけるユーザのキューに加え
られる（ステップ３８０）。

【００５９】キュー・マネージャは、検索後処理の入力
リストからオブジェクトを取り出しそしてそのリストに
それ以上のジョブがなくなるまで高速リング又は低速リ
ングのうちの適切な一方におけるそれぞれのユーザのキ
ューにそのオブジェクトを入れるという動作を続ける。

【００６０】その高速キュー又は低速キューにジョブが
加えられる時にはいつも、処理するための作業が得られ
たことを、適切なワーカ・スレッド３８に対するワーク
・スケジューラが通知される（ステップ４３０）。ワー
ク・スケジューラは、使用可能なワーカ・スレッドをワ
ーク項目に割り当てる動作を管理するキュー・マネージ
ャ４８のコンポーネントであり、ワーカ・キューからワ
ーカ・スレッドを取り出し、それを新たに発生されたワ
ーク・リストに割り当てる（ステップ４４０）。高速リ
ング及び低速リングに対して別々のワーク・スケジュー
ラが走る。

【００６１】従って、それぞれのワーク・スケジューラ
は、行われるべきワーク及び現在のユーザにとって使用
可能なワーカ・プロセス３８が存在するかどうかの決定
を行う（ステップ４５０）。その決定の結果が否定であ
る場合、使用可能なワークの通知又は使用可能なワーカ
・スレッドの通知が受信されるまで、ワーク・スケジュ
ーラは休止する（ステップ４６０）。その結果が肯定で
ある場合、ワーク・スケジューラは、それぞれのワーカ
・スレッドによって遂行されるべきタスクのリストを作
成する。なお、それらのタスクはユーザＩＤによってイ
ンデックスされる。

【００６２】ワーカ・スレッドは、ワーカ・スケジュー
ラによって制御される資源割り振りスケジュールに従っ
てそれの処理タスクを遂行するであろう。ワーク・スケ
ジューラは、システム管理者からの命令に従って、特定
の処理資源「ポイント」をユーザＩＤの関数として割り
当てる。これらのポイントは、特定のユーザのリクエス
トが処理される時にはいつも、その特定のユーザのため
に遂行されるべき処理の量を決定する。即ち、システム
管理者は、循環的にリンクされたリストの処理シーケン
スが各ユーザに対して進行する時にいつも、そのユーザ
のために遂行されるべき処理量を決定した。この割り振
りは、高速タスク及び低速タスクの各々に対して別々に
行われる。

【００６３】異なるユーザ・グループの各々が低速処理
に対してＮ、Ｐ、又はＱポイントを割り当てられ、高速
処理に対してｎ、ｐ、又はｑポイントを割り当てられて
いるものと仮定する。低速ジョブの処理中、ワーク・ス
ケジューラは、低速キューに対するユーザの割り振られ
たポイント及びリストにおける次のジョブに対するアト
リビュート・ポイントＭを決定し（ステップ４６０）、
関連のユーザのポイント割り振りをポイントＭだけデク
レメントする（ステップ４７０）。一般に、アトリビュ
ートされたポイントは、各タスク・タイプに対する一定
の数のポイント、或いは「コスト」であるが、処理され
るべきデータ・オブジェクトのサイズに従って可変数の
ポイントであってもよい。これらのコストは、使用中の
関連のハードウエア及びソフトウエアのパフォーマンス
を反映しなければならない。

【００６４】ユーザがＮポイント（Ｎ≧Ｍ）を有する場
合、Ｍポイント・ジョブはユーザの処理オペレーション
・キューから除去され、ワーカ・スレッドに対する「予
定ワーク（ｗｏｒｋ ｔｏ ｄｏ）」リストに加えられ
る（ステップ４８０）。そのユーザがそれらのＮポイン
トからの残りのポイントを有し、そのユーザのための遂
行されるべき更なる処理タスクが存在する場合（決定ブ
ロック４９０）、スケジューラはそのユーザのキューに
おける次のジョブに進み、次のジョブにとって使用可能
な十分なポイント（Ｑポイントを必要とするジョブに対
しては、Ｑよりも大きいか又はＱに等しいＮ−Ｍであ
る）が存在するかどうかを決定する。それぞれのリング
におけるそのユーザのキューにそれ以上のジョブが存在
しない場合、そのリングにおけるユーザのエントリは除
去される（ステップ５００）。ユーザが残りのポイント
を全く持たないか、又はそのユーザのキューにおける次
のジョブにとって不十分なポイントしか持たない場合、
スケジューラはリングにおける次のユーザに進み（ステ
ップ５１０）、そして現在キュー内にワークを有するユ
ーザを相互にサービスした後、そのユーザのキューに戻
るだけであろう。従って、ワーク・スケジューラは順序
づけられた「予定ワーク」リストを構成し、これをワー
カ・プロセスに供給する。図１３は、番号１乃至９によ
って表された処理のシーケンス例を持った循環的にリン
クされたリストを示す。この例では、各ユーザのポイン
トは、そのユーザのキューがサービスされる時にいつも
２つの小型のオブジェクトにとって十分であるが、大き
いオブジェクト（９）はそのユーザに対する他のオブジ
ェクトと共には処理され得ない。

【００６５】高速リング又は低速リングのそれぞれに関
連したワーカ・プロセス３８はそれのワーク・マネージ
ャ５６に新しいワークを受容するために（例えば、それ
がキャッシュへの転送のために前の結果ベクトルをワー
ク・マネージャ５６に送った（ステップ５３０）後に）
そのワーカの可用性を通知し（ステップ５２０）、一
方、そのワーク・マネージャはそれをそれぞれのワーク
・スケジューラに通知する（ステップ５２５）。そこ
で、スケジューラからの「予定ワーク」リストの受信時
に、ワーカ・プロセス３８は、それの処理結果を保持す
るための新しいエンプティ結果ベクトルを作成する（ス
テップ５４０）。それは、ワーク項目がそのリストに残
っているかどうかをチェックし（ステップ５５０）、そ
れが残っている場合には、シグニチャ・チェックが必要
であるかどうかをチェックする（ステップ５６０）。ほ
とんどの場合、シグニチャ・チェックは必要とされるで
あろう。そのシグニチャ・チェックが行われる（ステッ
プ５７０）。これは、情報がクライアント・データベー
スから得られたオリジナル・リクエスト内の情報に基づ
く期待されたディジタル・シグニチャの計算、及びイメ
ージと関連してデータ・ライブラリから検索されたディ
ジタル・シグニチャとの比較を必要とする。

【００６６】イメージがそれのシグニチャ・チェックを
失敗する場合、それは「失敗した」としてマークされ
（ステップ５９０）、ワーカ・スレッドはリストにおけ
る次の項目に移る。低速リングのためのワーカ・スレッ
ドの場合、シグニチャ・チェックが終わると、次に、透
かし入れが必要であるかどうかの決定が行われる（ステ
ップ６００）。それが肯定である場合、必要な透かしイ
メージが得られるかどうかの決定が行われる（ステップ
６１０）。それが否定である場合、透かしイメージが生
成される（ステップ６２０）。ロッキング・ステップが
完了し得ない場合の削除を可能にするために、透かし入
れプロセス３８のコンポーネントを構成する透かしイメ
ージ「クリーナ」スレッドがこの段階で呼び出される。
そこで、透かしイメージがロックされて削除を回避し
（ステップ６３０）、通常の透かし入れアルゴリズムを
使用してイメージ・オブジェクトに適用される（ステッ
プ６４０）。

【００６７】ワーカ・スレッドによるその後の処理ステ
ップは、透かしタイプ・スレッド及び高速リングを処理
するワーカ・スレッドに対するものと同じである。更に
何らかの処理タスクが必要とされるかどうかに関する決
定が次に行われる（ステップ６５０）。本実施例では、
すべてのフル・イメージがＴＩＦＦフォーマットからＪ
ＰＥＧフォーマットへの変換を必要とし、従って、（通
常の方法を使用して）この変換が行われる（ステップ６
６０）。

【００６８】そこで処理ジョブは終了したものとして或
いは失敗したものとしてマークされる（ステップ６７
０）。終了した場合には、イメージ・サイズが記録さ
れ、ワーカ・スレッドは次のジョブに進む。「予定ワー
ク」リストに更なるワーク項目が存在しない時、ワーカ
・スレッドはワーカ・マネージャ５６に結果ベクトルを
送る（ステップ５３０）。ワーカ・マネージャはその結
果を受信し（ステップ６８０）、それらをキャッシュ・
マネージャ５０に送り、キャッシュ・マネージャはその
結果をサーバ・システムのキャッシュ・メモリに記憶す
る。

【００６９】この時点からは、次のリクエストがエンド
・ユーザから受信される場合、処理されたイメージがキ
ャッシュにおいて得られ、従って、遅れることなくエン
ド・ユーザに表示するためにクライアント・システムに
配送される。そのような検索後処理及び処理されたイメ
ージのキャッシュへの配送は、リクエストが個々の選択
されたフル・イメージに対して供給される前に、或るイ
メージ又はすべてのイメージに対して、システム・パフ
ォーマンス及び同時ユーザ・リクエストの数次第で終了
可能であることは当業者には明らかであろう。

【００７０】従って、透かし処理及びローカル・キャッ
シュ・メモリにおける透かし入れされたイメージの記憶
は、エンド・ユーザがそれらに配送されるべき特定のフ
ル・イメージを選択する前に、関連のフル・イメージに
対して始まる。予測されるその後のリクエストに基づく
プリフェッチ及びプリプロセスのポリシは、エンド・ユ
ーザが受けた配送遅延を減少させ、配送前にイメージを
検索及び処理するために遂行されるステップをエンド・
ユーザに知らせる必要をなくする。

【００７１】所望のオブジェクトを識別してキャッシュ
からの又は（必要な場合には）外部リホジトリからの自
動化されたデータ検索をトリガするというウェブ・ブラ
ウザ・リクエストの自動発生と共に、前述のように得ら
れる遅延の減少は、イメージ検索、処理、及び配送とい
う段階づけられた性質を透明なものにする。エンド・ユ
ーザは、オブジェクトが分散データ検索システムにおけ
る何処に記憶されるか、或いは既に検索されている多数
の可能なオブジェクトのコピーが種々の場所から検索可
能であるかどうかを知る必要はない。

【００７２】たとえ、ほとんどのリクエストが満たされ
る前にそれらリクエストがデータ・ライブラリへのアク
セスを必要としても、すべてのイメージがデータ検索シ
ステムのキャッシュからローカル的に得られるという印
象をエンド・ユーザに与えることが可能である。

【００７３】エンド・ユーザの待ち時間を更に減少させ
るそのシステムの更なる機能拡張は、特定のフル・イメ
ージに対する検索後処理のジョブがどのリングにあるか
決定すること、そのリングにおいてユーザのエントリを
位置指定すること、及び処理ジョブが依然としてユーザ
のキュー待ちの処理状態にある場合にユーザのキューの
先頭にそのジョブを進めさせることによって、関連のア
ネックスのプリフェッチ処理が開始された後であるが透
かし入れが終了する前に、その特定のフル・イメージの
配送を求めるリクエストに応答するようにキュー・マネ
ージャを適応させることである。

【００７４】透かし入れタスクは、使用されるプロセッ
サの数が特定のサーバ・システム１０に依存する場合、
使用可能なプロセッサ当たり単一の透かし入れプロセス
に制限される。従って、単一のプロセッサが使用可能な
すべてである場合、第１項目の処理が完了した後でし
か、第２項目が透かし入れ入力リストから検索されるこ
とはない。単一のプロセッサ上で並列に複数のそのよう
なスレッドを走らせることによって、全体的なスループ
ットは減少するであろう。

【００７５】検索スレッドはプロセッサ・インテンシブ
ではない。それらはディスク・インテンシブである。プ
ロセッサへのそれらの割り振りはシステムに依存するも
のであり、特定のイメージ（大きなデータ・オブジェク
ト）記憶装置及び検索機構の特性によって強く影響され
る。

【００７６】前述のように、検索、可能なディジタル・
シグニチャ・チェック、及び可能なフォーマット変換に
しか関与しないオペレーションが、更に透かし入れを必
要とするオペレーションに対する１つの別個の処理スレ
ッド（又は複数のスレッド）によって処理される。１つ
のそのような処理スレッドがキャッシュにデータを書き
出してそれの現在のワークを終了する時、それはスケジ
ューラからの更なるワークをリクエストする。適正なリ
ングにおける次のユーザが選択され、そのユーザが持つ
「ポイント」と同じだけ多くのワークがそのリングから
検索機構又は透かし入れ機構に割り当てられる。

【００７７】検索及び透かしから検索を分離することに
よって、透かし入れを必要としないユーザは、このプロ
セスを必要とするデータ・オブジェクトをリクエストす
るユーザの資源要求によって過度に強く影響されるわけ
ではない。透かし入れスレッドをプロセッサ当たり１つ
に制限することによって、透かし入れのスループットが
最大にされる。検索、シグニチャ・チェック、及び透か
し入れ機能のキューイング及びコスト算定は、複数のユ
ーザの同時リクエストという状況において公平な資源割
り振りを得ることができることを保証する。

【００７８】本発明の上記の好適な実施例では、検索後
処置のために、ジョブが１つの循環的にリンクされたリ
ストに置かれるべきかどうか及び複数のリンクされたリ
ストのうちのどれに置かれるべきかはオブジェクト・タ
イプ、並びにリクエスタのＩＤと同様にそのタイプのオ
ブジェクトにとって必要であると事前定義された処理タ
スクから決定される。ユーザの或る信任されたグループ
は如何なるオブジェクトの透かし入れも必要ない。それ
とは別に、どのキューにタスクを置くべきかは単にその
オブジェクト・タイプに関して決定されてもよい。シグ
ニチャ・チェックは重要な処理資源に関与しないので、
シグニチャ・チェックがすべてのリクエスト（プロセス
が切り替えられる時のシステム・テスト又は構成時を除
いて）に対して行われることが望ましい。

【００７９】本発明の別の実施例によれば、資源マネー
ジャによって区別されたオブジェクト「タイプ」はフル
・イメージ及びサムネールに限定されない。その代わ
り、キュー・マネージャがリクエストされたオブジェク
ト名と透かし入れを必要とする名前を付けられたオブジ
ェクト・タイプのルックアップ・テーブルとを比較す
る。オブジェクト名がリストにおけるエントリと一致す
る場合、キュー・マネージャは、透かし入れの遂行を必
要とするものとして検索オペレーションをフラッグす
る。複数のリポジトリをアクセスし得る分散データ検索
システムでは、或るリポジトリから検索されたオブジェ
クトだけ、又はリポジトリ内の或るカテゴリのオブジェ
クトだけが動的透かし入れを必要とするということであ
ってもよい。

【００８０】当業者には明らかであるように、本発明の
技術的範囲内にありながら、実質的に、上記のように方
法又はシステムに対するその他の修正を行うことが可能
である。例えば、データ・ライブラリ接続コンポーネン
トのような上記のメイン・データ検索システムのコンポ
ーネントはローカルであってもよく、或いは、コンポー
ネントが分散している場合、それらのコンポーネントの
上記のメイン・データ検索システムから遠く離れていて
もよい。それがローカルである場合、データ・ライブラ
リ接続コンポーネントはその結果を、上記のようにキュ
ー・マネージャを介するのではなく、キャッシュに直接
に転送してもよい。

【００８１】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００８２】（１）データ検索システムを使用し、デー
タ検索リクエストに応答してデータを検索するための方
法にして、前記データ検索システムによるデータ検索リ
クエストの受信に応答して、第１所定タスクが遂行され
ることを必要とするリクエストされたデータ検索オペレ
ーションを識別するステップと、前記第１所定タスクが
遂行されることを必要とするデータ検索オペレーション
だけを第１処理キューに入力するステップと、前記第１
所定タスクが遂行されることを必要としないデータ検索
オペレーションを、前記第１所定タスクを遂行すること
なく処理するステップと、前記第１処理タスクの遂行を
含む、前記第１処理キューにおけるデータ検索オペレー
ションを処理するステップと、処理されたデータをリク
エスタに配送するステップと、を含むデータ検索方法。 （２）前記第１所定タスクは透かし入れタスクであるこ
とを特徴とする上記（１）に記載のデータ検索方法。 （３）第２所定タスクの遂行を必要とするが前記第１所
定タスクの遂行を必要としないデータ検索オペレーショ
ンを前記第１処理キューとは別個の第２処理キューに入
力するステップと、前記第１処理キュー及び第２処理キ
ューを独立して処理するステップと、を含むことを特徴
とする上記（１）又は上記（２）に記載のデータ検索方
法。 （４）前記第２所定タスクはデータ・フォーマット変換
タスクであることを特徴とする上記（３）に記載のデー
タ検索方法。 （５）前記識別するステップはデータ検索リクエストか
ら得られたデータ・オブジェクト・メタデータと、必要
とされる処理タスクにデータ・オブジェクトを関連付け
るルックアップ・テーブルとの間の比較を含むことを特
徴とする上記（１）乃至上記（４）のうちの何れか１つ
に記載のデータ検索方法。 （６）前記第１処理キューは複数のキューを含み、デー
タ検索オペレーションはリクエストされたデータ・オブ
ジェクトのサイズに従って前記複数のキューの間で割り
振られることを特徴とする上記（１）乃至上記（５）の
うちの何れか１つに記載のデータ検索方法。 （７）前記第１処理キューはリクエストされたデータ検
索オペレーションが加えられる循環的にリンクされたリ
ストであり、前記オペレーションはそれらのエンド・ユ
ーザ・リクエストのＩＤに従ってインデックスされ、前
記循環的にリンクされたリストにおけるデータ検索オペ
レーションは事前定義された処理単位が各エンド・ユー
ザ・リクエスタに対して順次遂行されるように循環シー
ケンスで処理されることを特徴とする上記（１）乃至上
記（６）のうちの何れか１つに記載のデータ検索方法。 （８）前記事前定義された処理単位は事前定義された数
の処理タスクを完了するために必要とされる処理の量に
対応することを特徴とする上記（７）に記載のデータ検
索方法。 （９）前記事前定義された処理単位は事前定義されたプ
ロセッサ・オペレーション・タイムであることを特徴と
する上記（７）に記載のデータ検索方法。 （１０）データ検索システムのユーザの間でデータ処理
資源を割り当てるための方法にして、前記データ検索シ
ステムにおけるスケジューラにデータ検索リクエストを
入力するステップと、第１所定プロセッサ・インテンシ
ブ・タスクの遂行を必要とするリクエストされたデータ
検索オペレーションを識別するステップと、リクエスト
されたデータ・オブジェクトをリポジトリから検索する
ステップと、前記所定のタスクの遂行を必要とし、エン
ド・ユーザ・リクエスタに従ってインデックスされるデ
ータ検索オペレーションを第１の循環的にリンクされた
リストに入力するステップと、前記所定のタスクの遂行
を必要としないデータ検索オペレーションを、前記所定
のタスクを遂行することなく処理するステップと、事前
定義された処理単位が各エンド・ユーザ・リクエスタの
ために順次遂行されるように、前記所定のタスクの遂行
を含む前記第１の循環的にリンクされたリストにおける
データ検索オペレーションを循環シーケンスで処理する
ステップと、を含む方法。 （１１）第１所定タスクの遂行を必要としないが前記第
２所定タスクの遂行を必要とするデータ検索オペレーシ
ョンを、前記第１の循環的にリンクされたリストとは別
個の第２の循環的にリンクされたリストに入力するステ
ップと、各リストに対して事前定義された処理単位が各
エンド・ユーザのために順次遂行されるように前記第１
のリストの処理とは独立した第２のリストを循環シーケ
ンスで処理するステップと、を含み、前記第２のリスト
におけるオペレーションはそれらのエンド・ユーザ・リ
クエスタに従ってインデックスされることを特徴とする
上記（１０）に記載の方法。 （１２）前記事前定義された処理単位は事前定義された
数の処理タスクを完了するために必要とされる処理の量
に対応することを特徴とする上記（１０）又は上記（１
１）に記載の方法。 （１３）前記事前定義された処理単位は事前定義された
プロセッサ・オペレーション・タイムであることを特徴
とする上記（１０）又は上記（１１）に記載の方法。 （１４）リクエストされたデータをデータ検索システム
を介して検索する方法にして、前記システムは必要なデ
ータ・オブジェクト・コンテナを識別する受信されたリ
クエストに応答して前記データ・オブジェクト・コンテ
ナの内容をデータ・リポジトリから検索し、前記コンテ
ナにおけるどのデータ・オブジェクトがリクエスタへの
配送の前に検索後処理を必要とするかを決定し、前記コ
ンテナにおけるデータ・オブジェクトに対して必要な前
記検索後処理の遂行を開始し、前記検索後処理に起因す
る処理されたデータ・オブジェクトをシステム・キャッ
シュに転送することを特徴とし、更に、前記システムは
前記コンテナのデータ・オブジェクトのうちの必要な１
つ又は複数のデータ・オブジェクトを識別するその後の
リクエストに応答して前記１つ又は複数のデータ・オブ
ジェクト得るためにキャッシュをアクセスすることを特
徴とする方法。 （１５）前記システムは、前記コンテナのデータ・オブ
ジェクトのうちの必要な１つ又は複数のデータ・オブジ
ェクトを識別するリクエストであって検索後処理の遂行
の開始後且つそれの完了前に受信されたリクエストの受
信に応答して、前記データ・オブジェクトを次の処理さ
れるべきデータ・オブジェクトとしてプロモートするこ
とを特徴とする上記（１４）に記載の方法。 （１６）記憶されたデータ・オブジェクトをリポジトリ
から検索するためのデータ検索システムにして、データ
検索リクエストを受信するための手段と、１つ又は複数
の記憶されたデータ・オブジェクトを検索するために前
記リポジトリへの接続を確立するための手段と、第１所
定タスクが遂行されることを必要とするデータ検索オペ
レーションを前記リクエストから識別するように適応
し、前記リポジトリからの前記１つ又は複数のデータ・
オブジェクトの検索の次に、他のデータ検索オペレーシ
ョンとは別個に処理するための前記第１所定タスクの遂
行を必要とする前記識別されたデータ検索オペレーショ
ンを待ち行列化するように適応する資源マネージャと、
前記キューにおけるオペレーションに関して前記第１所
定タスクを遂行するためのプロセスと、検索及び処理さ
れた前記データ・オブジェクトをリクエスタに配送する
ための手段と、を含むシステム。 （１７）記憶されたイメージ・オブジェクトがコンテナ
内に配列され、各コンテナが複数のサムネール・イメー
ジ及びフル・イメージを含み、前記資源マネージャはコ
ンテナを識別するデータ検索リクエストに応答して、識
別されたコンテナの内容を検索し、前記コンテナにおけ
るサムネール・イメージをリクエスタに配送し、前記フ
ル・イメージのうちの特定のフル・イメージを配送する
ためのリクエストを前記システムが受信する前に、前記
第１所定タスクを遂行するために前記コンテナにおける
前記フル・イメージを待ち行列化することを特徴とし、
更に前記フル・イメージを求めるリクエストは前記コン
テナを識別するリクエストとは別個であることを特徴と
する上記（１６）に記載のシステム。

【図面の簡単な説明】

【図１】クライアント／サーバ分散データ検索システム
及び関連のディジタル・イメージ・ライブラリの概略的
表示である。

【図２】図２乃至図１３は、本発明の実施例に従って、
リポジトリからのデータ・オブジェクトの検索及びリク
エスタへの配送前の選択されたタスクの遂行におけるシ
ステムの種々のコンポーネントにより実施されるステッ
プのシーケンスを示し、特に、図２はクライアント・ア
センブリ・アプリケーション、クライアント・ブラウ
ザ、及びレンダラ・アプレットによって遂行されるステ
ップを示す。

【図３】データ検索サーブレットによって遂行されるス
テップを示す。

【図４】データ配送サーブレットによって遂行されるス
テップを示す。

【図５】名前変換システムによって遂行されるステップ
を示す。

【図６】キャッシュ・マネージャによって遂行されるス
テップを示す。

【図７】キュー・マネージャによって遂行されるステッ
プを示す。

【図８】キュー・マネージャによって遂行される更なる
ステップを示す。

【図９】データ・ライブラリ接続コンポーネント によ
って遂行される更なるステップを示す。

【図１０】ワーク・スケジューラによって遂行される更
なるステップを示す。

【図１１】透かし入れプロセスによって遂行される更な
るステップを示す。

【図１２】ワーカ・プロセス・マネージャによって遂行
される更なるステップを示す。

【図１３】透かし入れプロセスの一部を形成する透かし
イメージ・クリーナによって遂行される更なるステップ
を示す。

【図１４】複数のユーザに対するジョブ・キューを有す
る循環的にリンクされたリストの概略表示である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジョン・ブライアン・アイボットソン イギリス国ウィルトシャー州、サリズベリ ー、ブロードチョーク、ブルズ・レーン、 ダウンズ・ハウス（番地なし) (72)発明者 マーク・パトリック・ナットール イギリス国ハンプシャー州、イーストレ イ、チャンドラーズ・フォード、ウェスト ウッド・ガーデンズ 16

Claims (17)

【特許請求の範囲】
1. 【請求項１】データ検索システムを使用し、データ検索
   リクエストに応答してデータを検索するための方法にし
   て、 前記データ検索システムによるデータ検索リクエストの
   受信に応答して、第１所定タスクが遂行されることを必
   要とするリクエストされたデータ検索オペレーションを
   識別するステップと、 前記第１所定タスクが遂行されることを必要とするデー
   タ検索オペレーションだけを第１処理キューに入力する
   ステップと、 前記第１所定タスクが遂行されることを必要としないデ
   ータ検索オペレーションを、前記第１所定タスクを遂行
   することなく処理するステップと、 前記第１処理タスクの遂行を含む、前記第１処理キュー
   におけるデータ検索オペレーションを処理するステップ
   と、 処理されたデータをリクエスタに配送するステップと、 を含むデータ検索方法。
2. 【請求項２】前記第１所定タスクは透かし入れタスクで
   あることを特徴とする請求項１に記載のデータ検索方
   法。
3. 【請求項３】第２所定タスクの遂行を必要とするが前記
   第１所定タスクの遂行を必要としないデータ検索オペレ
   ーションを前記第１処理キューとは別個の第２処理キュ
   ーに入力するステップと、 前記第１処理キュー及び第２処理キューを独立して処理
   するステップと、 を含むことを特徴とする請求項１又は請求項２に記載の
   データ検索方法。
4. 【請求項４】前記第２所定タスクはデータ・フォーマッ
   ト変換タスクであることを特徴とする請求項３に記載の
   データ検索方法。
5. 【請求項５】前記識別するステップはデータ検索リクエ
   ストから得られたデータ・オブジェクト・メタデータ
   と、必要とされる処理タスクにデータ・オブジェクトを
   関連付けるルックアップ・テーブルとの間の比較を含む
   ことを特徴とする請求項１乃至請求項４のうちの何れか
   １つに記載のデータ検索方法。
6. 【請求項６】前記第１処理キューは複数のキューを含
   み、データ検索オペレーションはリクエストされたデー
   タ・オブジェクトのサイズに従って前記複数のキューの
   間で割り振られることを特徴とする請求項１乃至請求項
   ５のうちの何れか１つに記載のデータ検索方法。
7. 【請求項７】前記第１処理キューはリクエストされたデ
   ータ検索オペレーションが加えられる循環的にリンクさ
   れたリストであり、前記オペレーションはそれらのエン
   ド・ユーザ・リクエストのＩＤに従ってインデックスさ
   れ、 前記循環的にリンクされたリストにおけるデータ検索オ
   ペレーションは事前定義された処理単位が各エンド・ユ
   ーザ・リクエスタに対して順次遂行されるように循環シ
   ーケンスで処理されることを特徴とする請求項１乃至請
   求項６のうちの何れか１つに記載のデータ検索方法。
8. 【請求項８】前記事前定義された処理単位は事前定義さ
   れた数の処理タスクを完了するために必要とされる処理
   の量に対応することを特徴とする請求項７に記載のデー
   タ検索方法。
9. 【請求項９】前記事前定義された処理単位は事前定義さ
   れたプロセッサ・オペレーション・タイムであることを
   特徴とする請求項７に記載のデータ検索方法。
10. 【請求項１０】データ検索システムのユーザの間でデー
    タ処理資源を割り当てるための方法にして、 前記データ検索システムにおけるスケジューラにデータ
    検索リクエストを入力するステップと、 第１所定プロセッサ・インテンシブ・タスクの遂行を必
    要とするリクエストされたデータ検索オペレーションを
    識別するステップと、 リクエストされたデータ・オブジェクトをリポジトリか
    ら検索するステップと、 前記所定のタスクの遂行を必要とし、エンド・ユーザ・
    リクエスタに従ってインデックスされるデータ検索オペ
    レーションを第１の循環的にリンクされたリストに入力
    するステップと、 前記所定のタスクの遂行を必要としないデータ検索オペ
    レーションを、前記所定のタスクを遂行することなく処
    理するステップと、 事前定義された処理単位が各エンド・ユーザ・リクエス
    タのために順次遂行されるように、前記所定のタスクの
    遂行を含む前記第１の循環的にリンクされたリストにお
    けるデータ検索オペレーションを循環シーケンスで処理
    するステップと、 を含む方法。
11. 【請求項１１】第１所定タスクの遂行を必要としないが
    前記第２所定タスクの遂行を必要とするデータ検索オペ
    レーションを、前記第１の循環的にリンクされたリスト
    とは別個の第２の循環的にリンクされたリストに入力す
    るステップと、 各リストに対して事前定義された処理単位が各エンド・
    ユーザのために順次遂行されるように前記第１のリスト
    の処理とは独立した第２のリストを循環シーケンスで処
    理するステップと、 を含み、前記第２のリストにおけるオペレーションはそ
    れらのエンド・ユーザ・リクエスタに従ってインデック
    スされることを特徴とする請求項１０に記載の方法。
12. 【請求項１２】前記事前定義された処理単位は事前定義
    された数の処理タスクを完了するために必要とされる処
    理の量に対応することを特徴とする請求項１０又は請求
    項１１に記載の方法。
13. 【請求項１３】前記事前定義された処理単位は事前定義
    されたプロセッサ・オペレーション・タイムであること
    を特徴とする請求項１０又は請求項１１に記載の方法。
14. 【請求項１４】リクエストされたデータをデータ検索シ
    ステムを介して検索する方法にして、前記システムは必
    要なデータ・オブジェクト・コンテナを識別する受信さ
    れたリクエストに応答して前記データ・オブジェクト・
    コンテナの内容をデータ・リポジトリから検索し、 前記コンテナにおけるどのデータ・オブジェクトがリク
    エスタへの配送の前に検索後処理を必要とするかを決定
    し、 前記コンテナにおけるデータ・オブジェクトに対して必
    要な前記検索後処理の遂行を開始し、 前記検索後処理に起因する処理されたデータ・オブジェ
    クトをシステム・キャッシュに転送することを特徴と
    し、更に、 前記システムは前記コンテナのデータ・オブジェクトの
    うちの必要な１つ又は複数のデータ・オブジェクトを識
    別するその後のリクエストに応答して前記１つ又は複数
    のデータ・オブジェクト得るためにキャッシュをアクセ
    スすることを特徴とする方法。
15. 【請求項１５】前記システムは、前記コンテナのデータ
    ・オブジェクトのうちの必要な１つ又は複数のデータ・
    オブジェクトを識別するリクエストであって検索後処理
    の遂行の開始後且つそれの完了前に受信されたリクエス
    トの受信に応答して、前記データ・オブジェクトを次の
    処理されるべきデータ・オブジェクトとしてプロモート
    することを特徴とする請求項１４に記載の方法。
16. 【請求項１６】記憶されたデータ・オブジェクトをリポ
    ジトリから検索するためのデータ検索システムにして、 データ検索リクエストを受信するための手段と、 １つ又は複数の記憶されたデータ・オブジェクトを検索
    するために前記リポジトリへの接続を確立するための手
    段と、 第１所定タスクが遂行されることを必要とするデータ検
    索オペレーションを前記リクエストから識別するように
    適応し、前記リポジトリからの前記１つ又は複数のデー
    タ・オブジェクトの検索の次に、他のデータ検索オペレ
    ーションとは別個に処理するための前記第１所定タスク
    の遂行を必要とする前記識別されたデータ検索オペレー
    ションを待ち行列化するように適応する資源マネージャ
    と、 前記キューにおけるオペレーションに関して前記第１所
    定タスクを遂行するためのプロセスと、 検索及び処理された前記データ・オブジェクトをリクエ
    スタに配送するための手段と、 を含むシステム。
17. 【請求項１７】記憶されたイメージ・オブジェクトがコ
    ンテナ内に配列され、各コンテナが複数のサムネール・
    イメージ及びフル・イメージを含み、前記資源マネージ
    ャはコンテナを識別するデータ検索リクエストに応答し
    て、 識別されたコンテナの内容を検索し、 前記コンテナにおけるサムネール・イメージをリクエス
    タに配送し、 前記フル・イメージのうちの特定のフル・イメージを配
    送するためのリクエストを前記システムが受信する前
    に、前記第１所定タスクを遂行するために前記コンテナ
    における前記フル・イメージを待ち行列化することを特
    徴とし、更に前記フル・イメージを求めるリクエストは
    前記コンテナを識別するリクエストとは別個であること
    を特徴とする請求項１６に記載のシステム。