JP3634681B2 - 検索要求並列処理方法，及びその方法の実現に用いられるプログラム記録媒体 - Google Patents
検索要求並列処理方法，及びその方法の実現に用いられるプログラム記録媒体 Download PDFInfo
- Publication number
- JP3634681B2 JP3634681B2 JP23018799A JP23018799A JP3634681B2 JP 3634681 B2 JP3634681 B2 JP 3634681B2 JP 23018799 A JP23018799 A JP 23018799A JP 23018799 A JP23018799 A JP 23018799A JP 3634681 B2 JP3634681 B2 JP 3634681B2
- Authority
- JP
- Japan
- Prior art keywords
- search
- search request
- processing
- priority
- parallel
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は，各県名が含まれる情報をデータベースから視覚化することなど，多くの検索要求を発行して得られた結果を統合して処理する必要のあるシステムにおいて，個々の検索要求が独立して実行でき，利用できる検索処理部が複数存在する場合に，全ての検索処理部を効率よく利用し，統合処理を実行する際に最も必要となる部分から先に検索を行うことで，システム全体の応答時間を速くし，かつ，利用者から見て必要な部分から先に提示されるシステムを構築するための検索要求並列処理方法と，その方法の実現に用いられるプログラムが記録されるプログラム記録媒体とに関する。
【０００２】
【従来の技術】
従来，各県名が含まれる情報をデータベースから視覚化するなどの処理を実現する場合には，各県名など，個々の検索要求を逐次的に検索処理部に発行し，全ての検索結果がそろった後，得られた結果を統合処理することで，視覚化などの全体としての結果を構成する処理を実現してきた。
【０００３】
このような逐次的に検索する方法を用いることで，個々の検索要求の結果を逐次的に検証し，その結果を逐次的に統合して総合的な検索結果を作成することができ，視覚化などの複雑な処理を要素還元的に矛盾なく実行することが可能となっている。
【０００４】
【発明が解決しようとする課題】
従来の技術を用いた場合，個々の検索要求が各々独立で並列に処理でき，検索処理部が複数存在する場合であっても，検索要求は逐次的にしか発行されないため，複数のハードウェア資源を用いた並列化処理を実現することが困難であった。
【０００５】
また，個々の検索要求は等価なものとして扱われるため，統合処理を実行する際に最も必要となる部分や，利用者が最も必要としている部分から先に検索を行うなどといった処理を実現することも難しかった。
【０００６】
本発明の目的は，問題が並列に検索要求を発行して処理でき，複数の検索処理部が存在する場合に，各検索要求に対して優先順位を付与し，優先順位の高いものから検索処理部の数分の並列度で検索を実行した後に，先に返ってきた結果から順に統合して即座に返答処理を行うことができるようにすることで，従来技術の問題点の解決を図る新たな検索要求並列処理方法の提供と，その方法の実現に用いられる新たなプログラム記録媒体の提供とを目的とする。
【０００７】
【課題を解決するための手段】
この目的を達成するために，本発明では，複数の検索処理部を使って，並列型の検索要求を処理するときにあって，同一検索項目について複数の項目値が指定され，かつ，それらの項目値について利用者により設定された順位情報を持つように構成される並列型検索要求を受け取り，それらの項目値に基づいて，その並列型検索要求を個々の検索要求に分割する第１の処理過程と，並列型検索要求の持つ順位情報による順位に基づいた大きな重みを与えることにより，分割した検索要求について並列型検索要求内での優先順位を示す値を求め，それに並列型検索要求の受け取り順序に基づいた小さな重みを加えることにより，分割した検索要求について最終的な優先順位を示す値を求めて，各検索処理部に対して該優先順位の高い検索要求を要求する第２の処理過程と，検索処理部が検索結果を得るときに，それらの検索結果を受け取り，優先順位の高いものからの順番に従って，それらの検索結果を検索要求発行元に返答する第３の処理過程と，検索処理部が検索結果を得るときに，未要求の検索要求が残されているのかを判断して，残されている場合には，優先順位の高いものからの順番に従って，空いている検索処理部に対して未要求の検索要求を要求する第４の処理過程とを備えるように構成する。
【０００８】
そして，この構成を取るときに，発行された並列型検索要求の処理の完了を正確に判断できるようにするために，検索処理部が検索結果を得るときに，並列型検索要求に対応付けて用意される表に，該検索結果の元となった検索要求の処理終了を示す情報を記録する記録処理過程と，該記録された情報に従って，並列型検索要求の処理の完了を判定する判定処理過程とを備えるように構成する。
【０００９】
このように構成される本発明では，第１の処理過程では，検索要求発行元の発行する並列型の検索要求を受け取ると，その並列型検索要求を，検索処理部において検索を実行できる逐次的な形式に変換する。
【００１０】
この第１の処理過程の処理を受けて，第２の処理過程では，受け取った並列型検索要求に付随する情報と，並列型検索要求の受け取り順序の情報とを用いて，分割された検索要求に優先順位を付与し（１，２，３・・・というような自然数表現の優先順位ではなくて，そのような自然数表現の優先順位を決定可能とする値を持つ優先順位を付与する），その優先順序の高い順に，検索処理部での利用可能なユニット数に応じて，その分割された検索要求を検索処理部に要求する。
【００１１】
この第２の処理過程の処理を受けて，第３の処理過程では，非同期に発生する検索処理部からの検索結果を，それと対応する分割された個々の検索要求の結果として格納し，同時に検索結果が発生するときには優先度の高い検索結果を先に返答する形式に従いつつ，検索要求発行元に順次に返答する。
【００１２】
一方，この第２の処理過程の処理を受けて，第４の処理過程では，検索処理部が検索結果を得ることで検索処理部に空きが生ずることを受けて，未要求の検索要求が残されているのかを判断して，未要求の検索要求が残されている場合には，処理を行っていない検索処理部の各ユニットに対して，それらの未要求の検索要求を優先順位の順に要求する。
【００１３】
そして，記録処理過程／判定処理過程では，検索処理部からの検索結果を受け取ると，並列型検索要求に対応付けて用意される表に，例えば，それと対応する分割された個々の検索要求に対応付けてフラグを記録し，該当する並列型検索要求の持つ全検索要求にフラグが記録されたのか否かを判定することで，該当する並列型検索要求が全て処理されたかどうかを判定して，該当する並列型検索要求が全て処理された場合には，検索要求発行元に検索処理の完了を返答する。
【００１４】
従って，本発明によれば，複数の検索処理部を使って並列型の検索要求を処理する場合に，各検索要求に対して優先順位を付与し，優先順位の高いものから検索処理部の数分の並列度で検索を実行した後に，先に返ってきた結果から順に統合して即座に返答処理を行うことができるようになり，従来の技術では困難であった検索処理を実現できるようになる。
【００１５】
この構成を取るときに，複数の並列型検索要求が発行される場合を考慮して，第２の処理過程では，並列型検索要求の持つ順位情報による順位に基づいた大きな重みを与えることにより，分割した検索要求について並列型検索要求内での優先順位を示す値を求め，それに並列型検索要求の受け取り順序に基づいた小さな重みを加えることにより，分割した検索要求について最終的な優先順位を示す値を求めることで，分割した検索要求に対する優先順位を定めるようにしており，これにより，複数の並列型検索要求に統一的な優先順位を割り付けることで，未要求の検索要求と新たに分割された検索要求とを優先順位で順序付けるとともに，そのとき，空いている検索処理部がある場合には，優先順位の高いものからの順番に従って，その空いている検索処理部に対して該検索要求を要求することを実現している。
【００１６】
先に発行された並列型検索要求の処理が完了する前に，次の並列型検索要求が発行されることが起こる。このような場合，受け取った並列型検索要求に対して識別子が与えられた後，第１の処理過程の処理に従って，後に発行された並列型検索要求から個々の検索要求が分割される。
【００１７】
このようなときには，第２の処理過程で，複数の並列型検索要求に統一的な優先順位を割り付けることで，未要求の検索要求と新たに分割された検索要求とを優先順位で順序付け，これにより，別々の並列型検索要求に対して矛盾なく返答処理を行うことができる。
【００１８】
従って，本発明によれば，複数の並列型検索要求に統一的な優先順位を付与し，優先順位の高いものから検索処理部の数分の並列度で検索を実行した後に，先に返ってきた結果から順に統合して，別々の並列型検索要求に対して矛盾なく即座に返答処理を行うことができるようになり，従来の技術では困難であった検索処理を実現できるようになる。
【００１９】
【発明の実施の形態】
以下，本発明の一実施例について，図面を用いて詳細に説明する。
【００２０】
図１に，本発明の並列型検索要求分散統合処理装置のシステム構成の一実施例を図示する。
【００２１】
図１に示すクライアントシステム１は，例えば，図２に示すような，各県名が含まれる情報をデータベースから視覚化するといった処理を実現するための利用者インタフェースシステムである。この図２の表示では，各県の名前をキーワードとしてデータベースを検索した結果を統合して，その結果が０でない県に対して，その県名が含まれる情報の数を地図上の棒グラフとして表現している。
【００２２】
図２のような表現を生成することで，利用者に対してデータベースの検索結果を視覚的にわかりやすく提供することができる。また，図２のような画面を用いて，利用者が選択を行うことで，その他の表現を行う際の検索条件の設定を視覚的にわかりやすく行うことが可能となる。
【００２３】
図１に示す検索サーバシステム２は，クライアントシステム１からの検索要求を処理する並列型検索要求分散統合処理装置である。
【００２４】
この検索サーバシステム２は，クライアントシステム１からの並列型の検索要求を受け取る検索インタフェース部３と，検索インタフェース部３で受け取った並列型の検索要求を個々の検索要求に分割する検索要求分割部４と，該分割された検索要求に優先順位をつけ，その優先順序の高い順に，検索処理部６の数分の該検索要求（但し，その数分ないときには全部）を該検索処理部６に要求する優先順位付与部５と，該分割され優先順位をつけられた検索要求を実際に処理する複数構成の検索処理部６と，検索処理部６が得た検索結果を統合する検索結果統合部７と，検索インタフェース部３で受け取った並列型の検索要求が全て処理されたかを判定し，全て処理されていない場合には，付与された優先順序に従い，未処理の検索要求を空いている検索処理部６に要求する検索処理完了判定部８と，該分割され優先順位をつけられた検索要求が検索処理部６の数より多い場合に，その検索要求を一時的に保持する検索要求保持部９と，実際に検索すべきデータが格納されたデータベース１０とを備える。
【００２５】
ここで，検索サーバシステム２の持つこれらの機能は具体的にはプログラムで実現されるものであり，このプログラムは，フロッピィディスクなどに格納されたり，サーバなどのディスクなどに格納され，それらから検索サーバシステム２にインストールされてメモリ上で動作することで，本発明を実現することになる。
【００２６】
検索インタフェース部３は，例えば，ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）におけるＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）プログラムなどで構成され，クライアントシステム１からの検索要求を実際に通信プロトコルを用いて受け取り，検索要求のみを切り出したり，クライアントシステム１に対して検索結果を返す通信処理を行う。検索インタフェース部３で切り出された検索要求は，検索要求分割部４に渡される。
【００２７】
図３は，検索要求分割部４に渡される検索要求の一例である。ここで，同図３に示した検索要求では，例として，図２を生成するために必要な検索項目を想定している。
【００２８】
図３の検索要求は，「検索項目」，「付帯条件」，「興味項目」の３つの表からなっている。各表題に続く「＝」以後がそれぞれの内容を表している。つまり，この例では，「検索項目」は「北海道」「岩手」「東京」「大阪」「山口」「愛媛」「熊本」という内容をもっており，「付帯条件」は無し，「興味項目」は「東京，大阪」「北海道」という内容をもっている。
【００２９】
同図３に示した検索要求の意味としては，「検索項目」の内容一つ一つに対して，それをキーワードとした検索を行うことを表している。つまり，それぞれの検索内容は独立していて，一つの検索結果が他の検索に影響を与えない，並列型の検索要求である。
【００３０】
また，検索における検索結果間の論理積演算を記述するには，「付帯条件」にそのキーワードを指定する。例えば，「日本列島における温泉情報の分布」を検索したい場合には，「付帯条件」に「温泉」等のキーワードを指定することで，「検索項目」の各項目の検索結果と「温泉」等の検索結果との論理積が記述される。
【００３１】
「興味項目」は，直接検索には関係しないが，利用者がどの検索結果をもっとも必要としているかを指定する。図３の場合は，「東京」「大阪」の結果をもっとも必要としていて，次に「北海道」，その他は第３位の必要性であることを指定している。すなわち，「東京」「大阪」の結果の必要性が第１位，「北海道」の結果の必要性が第２位，その他の結果の必要性が第３位ということを表している。
【００３２】
検索要求分割部４は，図３のような並列型の検索要求を受け取ると，これを検索要求の記述文法に従って解析し，個々の検索要求に分割し，優先順位付与部５に渡す。
【００３３】
図４は，検索要求分割部４によって，図３の検索要求を分割した結果の一例である。この表は，検索要求保持部９に格納される。
【００３４】
同図４は，図３の検索要求における「検索項目」の内容をそのまま書き下した形になっており，検索Ｎｏ．１は「北海道」，検索Ｎｏ．２は「岩手」，検索Ｎｏ．３は「東京」，検索Ｎｏ．４は「大阪」，検索Ｎｏ．５は「山口」，検索Ｎｏ．６は「愛媛」，検索Ｎｏ．７は「熊本」となる。
【００３５】
もし，「付帯条件」の項目が存在していれば，各検索要求にそれが反映される。例えば，「付帯条件」に「温泉」が指定されていたとすると，検索Ｎｏ．１は「北海道 ＡＮＤ 温泉」，検索Ｎｏ．２は「岩手 ＡＮＤ 温泉」，検索Ｎｏ．３は「東京 ＡＮＤ 温泉」，検索Ｎｏ．４は「大阪 ＡＮＤ 温泉」，検索Ｎｏ．５は「山口 ＡＮＤ 温泉」，検索Ｎｏ．６は「愛媛 ＡＮＤ 温泉」，検索Ｎｏ．７は「熊本 ＡＮＤ 温泉」となる。ここで，キーワードの論理積を検索要求に記述するために，各キーワードを「ＡＮＤ 」で区切って記述するとした。
【００３６】
優先順位付与部５では，図４のように分割された検索要求を受け取ると，図３の「興味項目」などの情報から優先順位を判定し，検索要求保持部９に格納する。その後，優先順位の高い検索要求から，検索処理部６の数分，検索処理部６に検索要求を発行し，残った検索要求のリストを検索処理完了判定部８に渡す。
【００３７】
図５は，優先順位付与部５によって優先順位を判定され，検索要求保持部９に格納された検索要求の一例である。この表（以下，検索要求表と称する）は，図４の表を拡張した形（優先順位が付与される）で検索要求保持部９に格納される。
【００３８】
同図５では，図３の「興味項目」に第１位の必要性と記述されている検索Ｎｏ．３「東京」と検索Ｎｏ．４「大阪」とを優先順位「１」とし，第２位の必要性と記述されている検索Ｎｏ．１「北海道」を優先順位「２」とし，その他を優先順位「３」としている。また，同じ優先順位の項目の順序については，検索要求分割部４によって分割された順としている。
【００３９】
同図５に示した「ポインタ」は，検索要求をどこまで発行したかを表しており，検索処理完了判定部８などから参照される。
【００４０】
検索処理部６は，優先順位付与部５から受け取った検索要求を処理する。ここでは，例えば，データベース１０に投入されたテキスト群から全文検索を行い，検索要求に適合したテキストを返す処理を行うとする。検索処理部６は，このような全文検索処理を独立に実行できるユニットをｎ個持っている。ここで，ｎはｎ≧１を満たす自然数である。
【００４１】
検索処理部６の実現方法としては，例えば，データベース１０のコピーをｎ個用意して，全文検索を実行できる計算機ｎ台をそれにつなぎ，それぞれネットワークを使って，優先順位付与部５や検索処理完了判定部８や検索結果統合部７と結ぶことが挙げられる。
【００４２】
ここで，検索処理部６の各検索処理装置間の性能に差異がある場合は，検索性能の高い順に優先順位の高い検索要求を割り振ることで，システムとして極大の性能を引き出すことができる。
【００４３】
さて，検索処理部６により検索された結果は，検索結果統合部７や検索処理完了判定部８に渡される。この際，検索処理の結果を統合したり，検索処理の終了を判定するために，検索要求保持部９に格納されている検索要求表（図５に示すもの）を拡張する。拡張する項目は，検索結果統合部７において行う統合処理の内容に依存するが，ここでは一例として，全文検索の結果，マッチした文書の数（以下，検索数と呼ぶ）を統合することとし，これに合わせて，検索要求表にこの検索数を拡張していくことを想定する。
【００４４】
図６は，検索要求保持部９に格納されている検索要求表に，検索数を拡張した例である。なお，この検索要求表には，図５に示した優先順位の情報も保持されているが，図６ではそれを省いてある。
【００４５】
同図６の「検索数」の列には，検索処理部６から検索結果統合部７に渡された，全文検索の結果マッチした文書の数が格納されている。検索処理部６からの結果が検索結果統合部７にまだ届いていない場合は，特殊な値「＃＃＃＃＃」が格納されている。検索処理完了判定部８で実行する検索が全て終了したかどうかの判定は，「検索数」の列に，この値「＃＃＃＃＃」が存在するか否かで行うことができる。
【００４６】
検索結果統合部７では，検索処理部６から受け取った検索数を，逐次，該当する検索要求と合わせて，検索インタフェース部３に渡す。
【００４７】
図７は，検索結果統合部７から検索インタフェース部３に渡される検索結果の一例である。同図７の（ａ），（ｂ），（ｃ）は，検索インタフェース部３に渡される結果を時系列的に図示したもので，（ａ）は図６が示すのと同じ状態，（ｂ）はその少し後の状態，（ｃ）は検索が全て終了した状態を示している。
【００４８】
同図７に示した検索結果は，例として，図３の検索要求に対応した表となっている。同図７では，図３で「検索項目」として列記した項目に対応する形で，「東京 １２０」「北海道 ４０」「大阪 ５０」「岩手 ３０」「山口 １１」「愛媛 ９」「熊本 １０」という検索数を返している。
【００４９】
同図７に示した検索結果が並ぶ順序は，検索結果統合部７が検索処理部６から受け取った順である。つまり，個々の検索が先に終了した結果から順次検索インタフェース部３に送られるわけだが，もしも個々の検索が同時に終了した場合には，図５における優先順位が高い方から先に送られることになる。
【００５０】
検索処理完了判定部８は，検索処理部６から受け取った検索数を，検索要求保持部９に格納されている検索要求表の該当する検索要求の欄に代入する。そして，「検索数」の列に値「＃＃＃＃＃」が存在しない場合には，検索結果統合部７に対して，検索終了通知を渡す。反対に，「検索数」の列に値「＃＃＃＃＃」が存在する場合には，前記図５のポインタを用いて，優先順位の高い検索要求から順に検索処理部６に割り振って検索を進める。
【００５１】
ここで，検索処理部６の各検索処理装置間の性能に差異がある場合は，検索性能の高い順に優先順位の高い検索要求を割り振ることで，システムとして極大の性能を引き出すことができる。上述した検索結果統合部７は，検索処理部６から検索数を受け取るのと同時に，検索処理完了判定部８からの検索終了通知を待っている。そして，この検索終了通知を受け取ると，検索処理部６から受け取った検索数の処理の終了を待った後，検索インタフェース部３に対して，通信終了通知を渡す。
【００５２】
これによって，検索が先に終了した結果から順次検索インタフェース部３に送られ，続いてクライアントシステム１に送られる。検索インタフェース部３に，ＷＷＷにおけるＣＧＩプログラムを用いた場合，ＷＷＷの標準プロトコルであるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を使って，検索インタフェース部３とクライアントシステム１との間の通信が行われる。このプロトコルで通信が行われると，検索が終了するまで通信回線が保持されるので，検索インタフェース部３が受け取った検索結果は，即座にクライアントシステム１に伝えられることになる。
【００５３】
クライアントシステム１では，自身が送信した図３の検索要求で指定した順序や，この検索要求で指定した優先順位とは異なる順序で検索結果が返信されることを考慮して実装する必要がある。つまり，図７のような検索結果が返信された場合であっても，検索項目をキーとして検索結果を統合処理し，結果が０でない県に対して地図上の棒グラフとして表現することで，図２のような視覚化結果を得るように処理する。
【００５４】
検索結果統合部７，検索処理完了判定部８，検索インタフェース部３からクライアントシステム１に通ずるシステムの動作をまとめる。ここでは，説明の便宜上，検索処理部６には，能力の等価な３つのユニット（検索処理装置）が存在するものとして説明を行う。
【００５５】
優先順位付与部５から検索処理部６に発行された検索要求「東京」「大阪」「北海道」の処理（優先順位に従ってこの３つの検索要求が３つのユニットに発行される）が終わると，検索結果が検索処理部６から検索結果統合部７，検索処理完了判定部８に送られる。このとき，「大阪」の検索処理が遅れ，「東京」「北海道」の検索結果が得られたとする。
【００５６】
検索結果統合部７では，得られた検索結果「東京 １２０」「北海道 ４０」を検索インタフェース部３に渡す。検索処理完了判定部８では，図６に示す拡張された検索要求表の「検索数」欄の「東京」「北海道」に，それぞれ「 １２０」「４０」を代入し，図５のポインタを用いて，処理の済んでいない検索要求から，「岩手」「山口」の２つを検索処理部６の空いている２つのユニットに対して発行し，ポインタを「愛媛」に移す。
【００５７】
検索インタフェース部３では，「東京 １２０」「北海道 ４０」をクライアントシステム１に対して送信する。クライアントシステム１では，検索結果の統合処理を行うが，以前には何も届いていなかったので，受信した「東京 １２０」「北海道 ４０」を結果として図７（ａ）を得る。この結果を地図上の棒グラフとして表現することで，優先順位第１位の「東京」と第２位の「北海道」とが画面に表示される。
【００５８】
次に，検索処理部６で処理中の検索要求「岩手」「大阪」「山口」の内，「岩手」「大阪」の検索処理が終わり，検索結果が検索結果統合部７，検索処理完了判定部８に送られたとする。
【００５９】
検索結果統合部７では，得られた検索結果「岩手 ３０」「大阪 ５０」を検索インタフェース部３に渡す。このとき，「岩手」と「大阪」では，「大阪」の方が優先順位が高いので，「大阪 ５０」→「岩手 ３０」の順で検索インタフェース部３に渡す。
【００６０】
検索処理完了判定部８では，図６に示す拡張された検索要求表の「検索数」欄の「岩手」「大阪」に，それぞれ「３０」「５０」を代入し，図５のポインタを用いて，処理の済んでいない検索要求から，「愛媛」「熊本」の２つを検索処理部６の空いている２つのユニットに対して発行し，ポインタを「処理対象なし」状態とする。
【００６１】
検索インタフェース部３では，「大阪 ５０」「岩手 ３０」をクライアントシステム１に対して送信する。クライアントシステム１では，検索結果の統合処理を行い，受信した「大阪 ５０」「岩手 ３０」を，以前受信した「東京 １２０」「北海道 ４０」の後に追加して図７（ｂ）を得る。この結果を地図上の棒グラフとして表現することで，優先順位第１位の「大阪」と優先順位なしの「岩手」とが，先に表示されていた「東京」「北海道」に加えて画面に表示される。
【００６２】
次に，検索処理部６で処理中の検索要求「愛媛」「熊本」「山口」の内，「山口」の検索処理が終わり，検索結果が検索結果統合部７，検索処理完了判定部８に送られたとする。
【００６３】
検索結果統合部７では，得られた検索結果「山口 １１」を検索インタフェース部３に渡す。検索処理完了判定部８では，図６に示す拡張された検索要求表の「検索数」欄の「山口」に「１１」を代入する。このとき，図５のポインタは「処理対象なし」状態であるため，新たな検索要求は発行されない。
【００６４】
検索インタフェース部３では，「山口 １１」をクライアントシステム１に対して送信する。クライアントシステム１では，検索結果の統合処理を行い，受信した「山口 １１」を，以前受信した「東京 １２０」「北海道 ４０」「大阪 ５０」「岩手 ３０」の後に追加する。この結果を地図上の棒グラフとして表現することで，優先順位なしの「山口」が，先に表示されていた「東京」「北海道」「大阪」「岩手」に加えて画面に表示される。
【００６５】
最後に，検索処理部６で処理中の検索要求「愛媛」「熊本」の検索処理が終わり，検索結果が検索結果統合部７，検索処理完了判定部８に送られる。
【００６６】
検索結果統合部７では，得られた検索結果「愛媛 ９」「熊本 １０」を検索インタフェース部３に渡す。検索処理完了判定部８では，図６に示す拡張された検索要求表の「検索数」欄の「愛媛」「熊本」に，それぞれ「９」「１０」を代入する。このとき，図５のポインタは「処理対象なし」状態であるため，新たな検索要求は発行されない。
【００６７】
更に，図６に示す拡張された検索要求表の「検索数」列に値「＃＃＃＃＃」が存在しなくなるため，検索処理完了判定部８では，検索結果統合部７に対して検索終了通知を渡す。これ受けて，検索結果統合部７では，得られた検索結果「愛媛 ９」「熊本 １０」を検索インタフェース部３に渡す処理が終了したら，検索インタフェース部３に対して通信終了通知を渡す。
【００６８】
検索インタフェース部３では，「愛媛 ９」「熊本 １０」をクライアントシステム１に対して送信する。その後，即座に検索結果統合部７から通信終了通知を受け取るため，クライアントシステム１の受信を待って通信回線を切断する。
【００６９】
クライアントシステム１では，検索結果の統合処理を行い，受信した「愛媛 ９」「熊本 １０」を，以前受信した「東京 １２０」「北海道 ４０」「大阪 ５０」「岩手 ３０」「山口 １１」の後に追加して図７（ｃ）を得る。この結果を地図上の棒グラフとして表現することで，優先順位なしの「愛媛」「熊本」が，先に表示されていた「東京」「北海道」「大阪」「岩手」「山口」に加えて画面に表示される。これで，前記図２が完成するわけである。
【００７０】
以上のようにして，並列型の検索要求に優先順位を付けて検索を実行し，優先順位の高いものから統合して結果を返すことができる。
【００７１】
この例では，計算機の過負荷等の原因によって，検索処理部６の各ユニットが当初の性能を発揮できないことで，指定した優先順位とは異なった順序で結果が返ることを想定しているが，そのような場合でも，システム全体として最善の性能を得ることができるようになっている。なお，検索処理部６の各ユニットが同性能で性能を十分に発揮できる場合には，指定した優先順位の順序で結果を返すことができる。
【００７２】
ここまでで示したシステムは，一組の並列型検索要求に対する一例であり，二組以上の並列型検索要求に対して，優先順位を付与して検索を実行することには適していない。しかし，二組以上の並列型検索要求を分割した個々の検索要求に対して，全体として矛盾なく一般的な優先順位を付けることで，以上のシステムを，二組以上の並列型検索要求に対するシステムに拡張することができる。
【００７３】
次に，二組以上の並列型検索要求に対して本発明を用いるための拡張について詳細に説明する。
【００７４】
この拡張を行った場合，検索要求保持部９に格納される図４／図６の表と図５の表とは，同一の表の一部を切り出したものではなくなる。この場合には，図４（但し，図６と同様な検索数のエントリーを持つ）／図６の表は，並列型検索要求の処理が完了したのか否かのチェックを可能とするために，一つ一つの並列型検索要求に対応して複数用意されるのに対し，次に発行する検索要求の指定に用いられるポインタを持つ図５の表は，未処理の検索要求を統括的に管理するために，一つのシステムに対して一つ用意されることになる。
【００７５】
すなわち，図８に示すように，図４や図６に示すような検索要求表は，各並列型検索要求に対応付けて用意されるのに対して，図５に示すような表（以下，優先順位表と呼ぶ）は，一つのシステムに対して一つ用意されることになる。
【００７６】
この拡張を実装するためのポイントは，優先順位付与部５である。その他は，そのまま利用できる。以下，拡張された優先順位付与部５を拡張優先順位付与部と呼称する。
【００７７】
図９は，拡張優先順位付与部を説明するための追加の検索要求例として，「検索項目」に「青森」「群馬」「栃木」「静岡」「愛知」「高知」「沖縄」，「付帯条件」に「温泉」，「興味項目」に「青森，沖縄」「静岡」という内容を持った検索要求に対して，検索要求分割部４による処理を経た後の図である。
【００７８】
ここで，個々の検索要求を見分けるために，検索要求の番号として，
「検索要求の先着順」＋「−」＋「番号」
を採用した。但し，「検索要求の先着順」が「１」のときは，特別に「番号」のみとする。この例では，最初に，図３に示す並列型検索要求が発行され，その後，図９に示す並列型検索要求が発行されたことを想定している。
【００７９】
このような番号付与による識別子によって各並列型検索要求が区別され，後述することから分かるように，この識別子を使って，通信接続や，検索処理部から得た結果を統合する処理や，並列型の検索要求が全て処理されたかを判定する処理などが実行されることになる。
【００８０】
拡張優先順位付与部では，図４や図９のように分割された検索要求を受け取ると，図４（図３）や図９の「興味項目」や，検索要求の到着順などの情報から優先順位を判定し，検索要求保持部９に格納する。その後，優先順位の高い検索要求から，検索処理部６の中の処理を実行していないユニットに対して検索要求を発行し，残った検索要求のリストを検索処理完了判定部８に渡す。
ここで，拡張優先順位付与部は，１，２，３・・・というような自然数表現の優先順位を付与するのではなくて，そのような自然数表現の優先順位を決定可能とする値を持つ優先順位を付与することになる。
【００８１】
図１０及び図１１は拡張優先順位付与部によって優先順位を判定され，検索要求保持部９に格納された検索要求の一例である。この表（優先順位表）は，検索要求保持部９に格納される。
【００８２】
同図１０及び図１１における優先順位（１，２，３・・・というような自然数表現の優先順位ではなくて，そのような自然数表現の優先順位を決定可能とする値を持つ優先順位）は，図４（図３）や図９の「興味項目」に記述される必要性の度合いと，検索要求の到着順によって，
「必要性の順位」×１０＋「検索要求の到着順」
の式で計算される。
【００８３】
つまり，最初に到達する，図４に示した第１番目の検索要求の内，第１位の必要性と記述されている検索Ｎｏ．３「東京」と検索Ｎｏ．４「大阪」とを優先順位「１１（＝１＊１０＋１） 」とし，第２位の必要性と記述されている検索Ｎｏ．２「北海道」を優先順位「２１（＝２＊１０＋１） 」とし，その他を優先順位「３１（＝３＊１０＋１） 」としている。
【００８４】
また，その後に到達する，図９に示した第２番目の検索要求の内，第１位の必要性と記述されている検索Ｎｏ．２−１「青森 ＡＮＤ 温泉」と検索Ｎｏ．２−７「沖縄 ＡＮＤ 温泉」とを優先順位「１２（＝１＊１０＋２） 」とし，第２位の必要性と記述されている検索Ｎｏ．２−４「静岡 ＡＮＤ 温泉」を優先順位「２２（＝２＊１０＋２） 」とし，その他を優先順位「３２（＝３＊１０＋２） 」としている。ここで，同じ優先順位の項目の順序については，検索要求分割部４によって分割された順としている。
【００８５】
同図１０及び図１１に示した「ポインタ」は，検索要求をどこまで発行したかを表し，検索処理完了判定部８などから参照される。
【００８６】
図１０と図１１の違いは，図１０では，２つの検索要求がほぼ同時に到着したために，拡張優先順位付与部は，全ての検索要求を優先順位の高い順に整列させた後，優先順位に従って，検索Ｎｏ．３「東京」，検索Ｎｏ．４「大阪」，検索Ｎｏ．２−１「青森 ＡＮＤ 温泉」を検索処理部６（３つのユニットを持つ）に発行し，「ポインタ」を検索Ｎｏ．２−７「沖縄 ＡＮＤ 温泉」の位置に設定している。
【００８７】
これに対して，図１１では，図４に示す検索要求が早く到着したことで，拡張優先順位付与部は，検索Ｎｏ．３「東京」，検索Ｎｏ．４「大阪」，検索Ｎｏ．１「北海道」を検索処理部６に発行し，それらの検索処理中に，図９に示す検索要求が到着したため，既に発行済みの検索要求はそのままにして，「ポインタ」が指し示す以降の検索要求に対して優先順位の高い順に整列させている点である。
【００８８】
このような処理を実装することで，システムに対する検索要求が単一の場合も，複数の場合でも，ある時点で利用可能な検索処理ユニットの全てを有効に活用することができ，極大のパフォーマンスを得ることができる。
【００８９】
図１２に，本発明を実現する上でポイントとなる拡張優先順位付与部（優先順位付与部５）で行われる処理のフローチャートを図示する。次に，このフローチャートに従って，拡張優先順位付与部（優先順位付与部５）で行われる処理について詳細に説明する。
【００９０】
拡張優先順位付与部（優先順位付与部５）は，このフローチャートに示すように，ステップＳ１として，検索要求分割部４から図４や図９のような分割された検索要求が渡されるのを待つ。本ステップは，説明の便宜上，このような実装になっているが，検索要求分割部４とまとめて実装した場合には，このステップＳ１を省略することができる。検索要求分割部４から検索要求が渡されると処理をステップＳ２に移行する。
【００９１】
ステップＳ２では，変数「通し番号（検索要求の到着順を示す）」に対して１を加える。これは，図９の「Ｎｏ．」項目のような番号を一意に決定するためである。変数「通し番号」は，本発明の装置が１つも検索要求を処理していない状況において，リセットしてもよい。
【００９２】
次にステップＳ３として，検索要求分割部４で分割された検索要求を１つ取得する。検索要求は個々に分割されているので，適宜「Ｎｏ．」の項目等を利用して，この取得を行う。
【００９３】
その後，ステップＳ４では，ステップＳ３で取得した検索要求がクライアントシステム１から渡された興味項目の中に存在するか否かをチェックし，存在しない場合はステップＳ５へ，存在する場合はステップＳ６へ制御を移す。
【００９４】
ステップＳ５では，興味項目に現在処理中の検索要求が含まれていないので，その現在処理中の検索要求に対して，最低の優先順位を割り当てる。ここで，最低の優先順位とは，興味項目に記述された最低の順位（優先度）に１を加えたものとする。図４に示す検索要求で説明するならば，例えば「岩手」の検索要求に対して優先順位３を割り当てるのである。その後ステップＳ７へ制御を移す。
【００９５】
逆に，ステップＳ６では，興味項目に現在処理中の検索要求が含まれているので，その現在処理中の検索要求に対して，興味項目に記述された順位（優先度）を割り当てる。興味項目が図４や図９のように与えられる場合，その順位は，「興味項目＝」で開始される行から行毎に，１，２，３，・・と数えることで与えられる。
【００９６】
ここで，もし，クライアントシステム１あるいは利用者として，システム全体の性能を向上させるために，順位を下げてもよい項目があったら，図３のような興味項目の記述を変更して，例えば，１行目「興味項目＝東京，大阪」，２行目「北海道」，３行目「９：愛媛」というように記述するようにする。この場合には，前記の順位の取得法に加えて，「：」の前に記述される数字を順位とする。この例の場合で説明するならば，「東京」「大阪」という検索要求の順位は１，「北海道」の順位は２，「愛媛」の順位は９となる。その後ステップＳ７へ制御を移す。
【００９７】
ステップＳ７では，ステップＳ５，ステップＳ６で取得した興味項目内の順位すなわち優先度を基に優先順位を計算する。優先順位の計算は，例えば，ステップＳ２で設定した「通し番号」を用いて，
「興味項目内の順位」×１０＋「通し番号」
で与える。このような優先順位を用いることによって，先着順で高い興味項目内の順位を持つものを優先して検索を行うことができる。その後ステップＳ８へ制御を移す。
【００９８】
ステップＳ８では，図５や図１０や図１１のような優先順位表（次に要求する検索要求を指定するポインタを持つ表）を更新する。まず，優先順位表が存在しない場合は，新たに作成し，ポインタを「処理対象なし」状態に初期化する。ポインタが「処理対象なし」状態の場合は，現在処理中の検索要求を優先順位表に追加し，ポインタを追加した検索要求に合わせる。ポインタが有効な検索要求を指している場合は，ポインタが指す検索要求から始めて，より優先順位が低い検索要求の方向に，現在処理中の検索要求よりも優先順位の低い検索要求を探し出して，その位置に現在処理中の検索要求を挿入する。
【００９９】
このような処理を行うことで，既に処理を開始してしまった検索要求と矛盾することなく，未処理の検索要求の中で優先順位の高い順に処理が行われるようにすることができる。その後ステップＳ９へ制御を移す。
【０１００】
ステップＳ９では，ステップＳ３で取得される検索要求がまだ残っているかどうかを判定し，残っている場合はステップＳ３へ，残っていない場合はステップＳ１０へ制御を移す。検索要求が残っているかどうかの判定は，ステップＳ３の処理と同時に行ってもよい。
【０１０１】
次に，ステップＳ１０では，検索処理部６に空いているユニットがあるかどうかを調べ，空いていればステップＳ１１へ，全て処理中であればステップＳ１２へ制御を移す。
【０１０２】
ステップＳ１１では，図５や図１０や図１１のような優先順位表のポインタが指している検索要求を検索処理部６の空いているユニットへ送信し，ポインタを次の優先順位を持つ検索要求に進める。空いているユニットを示す情報を更新した後，ステップＳ１０へ制御を戻す。
【０１０３】
ステップＳ１２では，検索処理完了判定部８に対して，優先順位表及びポインタに変更を加えたことを通知して，ステップＳ１へ制御を移す。ステップＳ１では，上述したように，検索要求分割部４から図４や図９のような分割された検索要求が渡されるのを待機する。実装においてステップＳ１を省略した場合，ステップＳ１２からステップＳ１へ制御を移すことはなく，拡張優先順位付与部を終了する。
【０１０４】
以上のようにして，クライアントシステム１からの複数の検索要求に対して，検索サーバシステム２内で実行済みの要求と矛盾しない優先順位を与えることができ，図５や図１０や図１１のような優先順位表を得ることができる。
【０１０５】
図１３及び図１４に，本発明を実現する上でポイントとなる，検索結果統合部７及び検索処理完了判定部８で行われる処理のフローチャートを図示する。次に，このフローチャートに従って，検索結果統合部７及び検索処理完了判定部８で行われる処理について詳細に説明する。
【０１０６】
このフローチャートに示すように，まず，ステップＳ２０として，検索処理部６から検索結果が渡されるのを待機する。本ステップにおける検索処理部６との通信部分の実装は，検索処理部６との通信が複数同時に発生する可能性があることを考慮に入れて実装する。検索処理部６から検索結果が渡されると，処理をステップＳ２１に移行する。
【０１０７】
ステップＳ２１では，検索処理部６から渡された検索結果の中から，図５や図１０や図１１のような優先順位表に照らして，優先順位の最も高いものを選択（取り出し）し，検索結果が格納されているバッファからそれを消去する。その後ステップＳ２２へ制御を移す。
【０１０８】
ステップＳ２２では，ステップＳ２１で選択された検索結果を検索インタフェース部３へ通知する。検索インタフェース部３では，検索要求の「Ｎｏ．」をキーとして返信する通信セッションを判定し，クライアントシステム１との通信を行う。その後ステップＳ２３へ制御を移す。ステップＳ２２の処理を行うことによって，クライアントシステム１は全ての検索結果が出るのを待つ必要がなく，優先順位の高い順に検索結果を得ることができる。
【０１０９】
ステップＳ２３では，図４や図９を拡張した図６のような検索要求表（検索結果の記録域を持つ検索要求表）に対して，ステップＳ２１で選択された検索結果に該当する部分を探索し，そこに検索結果を代入する。ここで，検索結果に該当する部分の探索には検索要求の「Ｎｏ．」をキーとして検索を行う。また，検索要求表が複数存在するときには，検索要求の「Ｎｏ．」から先ず最初に検索要求表を特定することになる。その後ステップＳ２４へ制御を移す。
【０１１０】
ステップＳ２４では，検索処理部６から渡された検索結果で，まだ処理していないものがあるかどうかを判定し，まだ処理していないものがある場合はステップＳ２５へ，渡された検索結果が全て処理済みならステップＳ２６へ制御を移す。本ステップの判定は，検索結果が格納されているバッファに残りがあるのか否かをチェックすることで実現できる。
【０１１１】
ステップＳ２５では，検索処理部６から渡された検索結果で未処理な検索結果の中から，図５や図１０や図１１のような優先順位表に照らして，優先順位の最も高いものを選択（取り出し）し，検索結果が格納されているバッファからそれを消去する。その後ステップＳ２２へ制御を移す。
【０１１２】
ステップＳ２６では，検索要求表の全てに対して，以下のステップＳ２７の処理が実行されたかどうかを判定する。未処理の検索要求表がある場合はステップＳ２７へ，全て処理済みの場合はステップＳ２９へ制御を移す。
【０１１３】
ステップＳ２７では，図４や図９を拡張した図６のような検索要求表の検索数に，「＃＃＃＃＃」が含まれるかどうかの判定を行い，「＃＃＃＃＃」が含まれていない場合はステップＳ２８へ，「＃＃＃＃＃」が含まれている場合はステップＳ２６へ制御を移す。
【０１１４】
ステップＳ２８では，検索インタフェース部３に対して，ステップＳ２７で「＃＃＃＃＃」が含まれていないと判定された検索要求表に対応する通信セッションの切断を指示する通信終了通知を渡す。これを受けて，検索インタフェース部３では，検索要求表の「Ｎｏ．」をキーとして終了する通信セッションを判定し，クライアントシステム１との通信が終了し次第，その通信セッションを切断する。その後ステップＳ２６へ制御を移す。
【０１１５】
ステップＳ２９では，図５や図１０や図１１のような優先順位表に付随するポインタの値を判定して，「処理対象なし」の場合にはステップＳ２０へ，ポインタが次の検索要求を指している場合にはステップＳ３０へ制御を移す。
【０１１６】
ステップＳ３０では，まず検索処理部６中のユニットがいくつ利用可能かを調査し，図５や図１０や図１１のような優先順位表とポインタとを用いて，検索処理部６の利用可能なユニットに対して，未実行の検索要求で優先順位が高い順に検索要求を発行する。その後ステップＳ３１へ制御を移す。なお，利用可能ユニット数の調査は，検索処理部６が本システムのみから用いられている仮定した場合，前記ステップＳ２３で処理した検索結果の数と同じと見ることができる。
【０１１７】
ステップＳ３１では，ステップＳ３０で発行した検索要求の数分，優先順位の低い検索要求へポインタを移す。この際，優先順位表に検索要求が残らない場合は，ポインタを「処理対象なし」状態とする。その後ステップＳ２０へ制御を移す。
【０１１８】
以上のようにして，検索処理部６から渡された検索結果を受け付け，優先順位の高い順に検索インタフェース部３へ渡すことができ，また，まだ処理していない検索要求があった場合，優先順位の高い順に検索処理部６に渡して検索を行うことができる。
【０１１９】
上記したように，本発明の並列型検索要求分散統合処理装置を用いることで，各県名が含まれる情報をデータベースから視覚化するなど，多くの検索要求を発行して得られた結果を統合して処理する必要のあるシステムにおいて，個々の検索要求が独立して実行でき，利用できる検索処理部が複数存在する場合に，全ての検索処理部を効率よく利用し，統合処理を実行する際に最も必要となる部分から先に検索を行うことで，システム全体の応答時間を速くし，かつ，利用者から見て必要な部分から先に提示されるシステムを構築することができる。
【０１２０】
【発明の効果】
以上説明したように，本発明によれば，各々独立で並列に処理できる個々の検索要求に対して，複数の検索処理部が存在する場合に，各検索要求に対して優先順位を付与し，優先順位の高いものから検索処理部の数分の並列度で検索を実行した後に，先に返ってきた結果から順に統合して即座に返答処理を行うことが可能となるという効果がある。
この構成の実現にあたって，本発明では，複数の並列型検索要求に対して統一的な優先順位を付与するということから，複数の並列型検索要求が発行される場合にあっても，優先順位の高いものから検索処理部の数分の並列度で検索を実行した後に，先に返ってきた結果から順に統合して即座に返答処理を行うことが可能となるという効果がある。
【図面の簡単な説明】
【図１】並列型検索要求分散統合処理装置の一実施例である。
【図２】本発明の適用される検索処理の一例である。
【図３】検索要求の一例である。
【図４】分割された検索要求の一例である。
【図５】検索要求表の一例である。
【図６】拡張された検索要求表の一例である。
【図７】検索結果の一例である。
【図８】検索要求表／優先順位表の説明図である。
【図９】分割された検索要求の一例である。
【図１０】優先順位表の一例である。
【図１１】優先順位表の一例である。
【図１２】拡張優先順位付与部の処理フローである。
【図１３】検索結果統合部／検索処理完了判定部の処理フローである。
【図１４】検索結果統合部／検索処理完了判定部の処理フローである。
【符号の説明】
１ クライアントシステム
２ 検索サーバシステム
３ 検索インタフェース部
４ 検索要求分割部
５ 優先順位付与部
６ 検索処理部
７ 検索結果統合部
８ 検索処理完了判定部
９ 検索要求保持部
１０ データベース
【発明の属する技術分野】
本発明は，各県名が含まれる情報をデータベースから視覚化することなど，多くの検索要求を発行して得られた結果を統合して処理する必要のあるシステムにおいて，個々の検索要求が独立して実行でき，利用できる検索処理部が複数存在する場合に，全ての検索処理部を効率よく利用し，統合処理を実行する際に最も必要となる部分から先に検索を行うことで，システム全体の応答時間を速くし，かつ，利用者から見て必要な部分から先に提示されるシステムを構築するための検索要求並列処理方法と，その方法の実現に用いられるプログラムが記録されるプログラム記録媒体とに関する。
【０００２】
【従来の技術】
従来，各県名が含まれる情報をデータベースから視覚化するなどの処理を実現する場合には，各県名など，個々の検索要求を逐次的に検索処理部に発行し，全ての検索結果がそろった後，得られた結果を統合処理することで，視覚化などの全体としての結果を構成する処理を実現してきた。
【０００３】
このような逐次的に検索する方法を用いることで，個々の検索要求の結果を逐次的に検証し，その結果を逐次的に統合して総合的な検索結果を作成することができ，視覚化などの複雑な処理を要素還元的に矛盾なく実行することが可能となっている。
【０００４】
【発明が解決しようとする課題】
従来の技術を用いた場合，個々の検索要求が各々独立で並列に処理でき，検索処理部が複数存在する場合であっても，検索要求は逐次的にしか発行されないため，複数のハードウェア資源を用いた並列化処理を実現することが困難であった。
【０００５】
また，個々の検索要求は等価なものとして扱われるため，統合処理を実行する際に最も必要となる部分や，利用者が最も必要としている部分から先に検索を行うなどといった処理を実現することも難しかった。
【０００６】
本発明の目的は，問題が並列に検索要求を発行して処理でき，複数の検索処理部が存在する場合に，各検索要求に対して優先順位を付与し，優先順位の高いものから検索処理部の数分の並列度で検索を実行した後に，先に返ってきた結果から順に統合して即座に返答処理を行うことができるようにすることで，従来技術の問題点の解決を図る新たな検索要求並列処理方法の提供と，その方法の実現に用いられる新たなプログラム記録媒体の提供とを目的とする。
【０００７】
【課題を解決するための手段】
この目的を達成するために，本発明では，複数の検索処理部を使って，並列型の検索要求を処理するときにあって，同一検索項目について複数の項目値が指定され，かつ，それらの項目値について利用者により設定された順位情報を持つように構成される並列型検索要求を受け取り，それらの項目値に基づいて，その並列型検索要求を個々の検索要求に分割する第１の処理過程と，並列型検索要求の持つ順位情報による順位に基づいた大きな重みを与えることにより，分割した検索要求について並列型検索要求内での優先順位を示す値を求め，それに並列型検索要求の受け取り順序に基づいた小さな重みを加えることにより，分割した検索要求について最終的な優先順位を示す値を求めて，各検索処理部に対して該優先順位の高い検索要求を要求する第２の処理過程と，検索処理部が検索結果を得るときに，それらの検索結果を受け取り，優先順位の高いものからの順番に従って，それらの検索結果を検索要求発行元に返答する第３の処理過程と，検索処理部が検索結果を得るときに，未要求の検索要求が残されているのかを判断して，残されている場合には，優先順位の高いものからの順番に従って，空いている検索処理部に対して未要求の検索要求を要求する第４の処理過程とを備えるように構成する。
【０００８】
そして，この構成を取るときに，発行された並列型検索要求の処理の完了を正確に判断できるようにするために，検索処理部が検索結果を得るときに，並列型検索要求に対応付けて用意される表に，該検索結果の元となった検索要求の処理終了を示す情報を記録する記録処理過程と，該記録された情報に従って，並列型検索要求の処理の完了を判定する判定処理過程とを備えるように構成する。
【０００９】
このように構成される本発明では，第１の処理過程では，検索要求発行元の発行する並列型の検索要求を受け取ると，その並列型検索要求を，検索処理部において検索を実行できる逐次的な形式に変換する。
【００１０】
この第１の処理過程の処理を受けて，第２の処理過程では，受け取った並列型検索要求に付随する情報と，並列型検索要求の受け取り順序の情報とを用いて，分割された検索要求に優先順位を付与し（１，２，３・・・というような自然数表現の優先順位ではなくて，そのような自然数表現の優先順位を決定可能とする値を持つ優先順位を付与する），その優先順序の高い順に，検索処理部での利用可能なユニット数に応じて，その分割された検索要求を検索処理部に要求する。
【００１１】
この第２の処理過程の処理を受けて，第３の処理過程では，非同期に発生する検索処理部からの検索結果を，それと対応する分割された個々の検索要求の結果として格納し，同時に検索結果が発生するときには優先度の高い検索結果を先に返答する形式に従いつつ，検索要求発行元に順次に返答する。
【００１２】
一方，この第２の処理過程の処理を受けて，第４の処理過程では，検索処理部が検索結果を得ることで検索処理部に空きが生ずることを受けて，未要求の検索要求が残されているのかを判断して，未要求の検索要求が残されている場合には，処理を行っていない検索処理部の各ユニットに対して，それらの未要求の検索要求を優先順位の順に要求する。
【００１３】
そして，記録処理過程／判定処理過程では，検索処理部からの検索結果を受け取ると，並列型検索要求に対応付けて用意される表に，例えば，それと対応する分割された個々の検索要求に対応付けてフラグを記録し，該当する並列型検索要求の持つ全検索要求にフラグが記録されたのか否かを判定することで，該当する並列型検索要求が全て処理されたかどうかを判定して，該当する並列型検索要求が全て処理された場合には，検索要求発行元に検索処理の完了を返答する。
【００１４】
従って，本発明によれば，複数の検索処理部を使って並列型の検索要求を処理する場合に，各検索要求に対して優先順位を付与し，優先順位の高いものから検索処理部の数分の並列度で検索を実行した後に，先に返ってきた結果から順に統合して即座に返答処理を行うことができるようになり，従来の技術では困難であった検索処理を実現できるようになる。
【００１５】
この構成を取るときに，複数の並列型検索要求が発行される場合を考慮して，第２の処理過程では，並列型検索要求の持つ順位情報による順位に基づいた大きな重みを与えることにより，分割した検索要求について並列型検索要求内での優先順位を示す値を求め，それに並列型検索要求の受け取り順序に基づいた小さな重みを加えることにより，分割した検索要求について最終的な優先順位を示す値を求めることで，分割した検索要求に対する優先順位を定めるようにしており，これにより，複数の並列型検索要求に統一的な優先順位を割り付けることで，未要求の検索要求と新たに分割された検索要求とを優先順位で順序付けるとともに，そのとき，空いている検索処理部がある場合には，優先順位の高いものからの順番に従って，その空いている検索処理部に対して該検索要求を要求することを実現している。
【００１６】
先に発行された並列型検索要求の処理が完了する前に，次の並列型検索要求が発行されることが起こる。このような場合，受け取った並列型検索要求に対して識別子が与えられた後，第１の処理過程の処理に従って，後に発行された並列型検索要求から個々の検索要求が分割される。
【００１７】
このようなときには，第２の処理過程で，複数の並列型検索要求に統一的な優先順位を割り付けることで，未要求の検索要求と新たに分割された検索要求とを優先順位で順序付け，これにより，別々の並列型検索要求に対して矛盾なく返答処理を行うことができる。
【００１８】
従って，本発明によれば，複数の並列型検索要求に統一的な優先順位を付与し，優先順位の高いものから検索処理部の数分の並列度で検索を実行した後に，先に返ってきた結果から順に統合して，別々の並列型検索要求に対して矛盾なく即座に返答処理を行うことができるようになり，従来の技術では困難であった検索処理を実現できるようになる。
【００１９】
【発明の実施の形態】
以下，本発明の一実施例について，図面を用いて詳細に説明する。
【００２０】
図１に，本発明の並列型検索要求分散統合処理装置のシステム構成の一実施例を図示する。
【００２１】
図１に示すクライアントシステム１は，例えば，図２に示すような，各県名が含まれる情報をデータベースから視覚化するといった処理を実現するための利用者インタフェースシステムである。この図２の表示では，各県の名前をキーワードとしてデータベースを検索した結果を統合して，その結果が０でない県に対して，その県名が含まれる情報の数を地図上の棒グラフとして表現している。
【００２２】
図２のような表現を生成することで，利用者に対してデータベースの検索結果を視覚的にわかりやすく提供することができる。また，図２のような画面を用いて，利用者が選択を行うことで，その他の表現を行う際の検索条件の設定を視覚的にわかりやすく行うことが可能となる。
【００２３】
図１に示す検索サーバシステム２は，クライアントシステム１からの検索要求を処理する並列型検索要求分散統合処理装置である。
【００２４】
この検索サーバシステム２は，クライアントシステム１からの並列型の検索要求を受け取る検索インタフェース部３と，検索インタフェース部３で受け取った並列型の検索要求を個々の検索要求に分割する検索要求分割部４と，該分割された検索要求に優先順位をつけ，その優先順序の高い順に，検索処理部６の数分の該検索要求（但し，その数分ないときには全部）を該検索処理部６に要求する優先順位付与部５と，該分割され優先順位をつけられた検索要求を実際に処理する複数構成の検索処理部６と，検索処理部６が得た検索結果を統合する検索結果統合部７と，検索インタフェース部３で受け取った並列型の検索要求が全て処理されたかを判定し，全て処理されていない場合には，付与された優先順序に従い，未処理の検索要求を空いている検索処理部６に要求する検索処理完了判定部８と，該分割され優先順位をつけられた検索要求が検索処理部６の数より多い場合に，その検索要求を一時的に保持する検索要求保持部９と，実際に検索すべきデータが格納されたデータベース１０とを備える。
【００２５】
ここで，検索サーバシステム２の持つこれらの機能は具体的にはプログラムで実現されるものであり，このプログラムは，フロッピィディスクなどに格納されたり，サーバなどのディスクなどに格納され，それらから検索サーバシステム２にインストールされてメモリ上で動作することで，本発明を実現することになる。
【００２６】
検索インタフェース部３は，例えば，ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）におけるＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）プログラムなどで構成され，クライアントシステム１からの検索要求を実際に通信プロトコルを用いて受け取り，検索要求のみを切り出したり，クライアントシステム１に対して検索結果を返す通信処理を行う。検索インタフェース部３で切り出された検索要求は，検索要求分割部４に渡される。
【００２７】
図３は，検索要求分割部４に渡される検索要求の一例である。ここで，同図３に示した検索要求では，例として，図２を生成するために必要な検索項目を想定している。
【００２８】
図３の検索要求は，「検索項目」，「付帯条件」，「興味項目」の３つの表からなっている。各表題に続く「＝」以後がそれぞれの内容を表している。つまり，この例では，「検索項目」は「北海道」「岩手」「東京」「大阪」「山口」「愛媛」「熊本」という内容をもっており，「付帯条件」は無し，「興味項目」は「東京，大阪」「北海道」という内容をもっている。
【００２９】
同図３に示した検索要求の意味としては，「検索項目」の内容一つ一つに対して，それをキーワードとした検索を行うことを表している。つまり，それぞれの検索内容は独立していて，一つの検索結果が他の検索に影響を与えない，並列型の検索要求である。
【００３０】
また，検索における検索結果間の論理積演算を記述するには，「付帯条件」にそのキーワードを指定する。例えば，「日本列島における温泉情報の分布」を検索したい場合には，「付帯条件」に「温泉」等のキーワードを指定することで，「検索項目」の各項目の検索結果と「温泉」等の検索結果との論理積が記述される。
【００３１】
「興味項目」は，直接検索には関係しないが，利用者がどの検索結果をもっとも必要としているかを指定する。図３の場合は，「東京」「大阪」の結果をもっとも必要としていて，次に「北海道」，その他は第３位の必要性であることを指定している。すなわち，「東京」「大阪」の結果の必要性が第１位，「北海道」の結果の必要性が第２位，その他の結果の必要性が第３位ということを表している。
【００３２】
検索要求分割部４は，図３のような並列型の検索要求を受け取ると，これを検索要求の記述文法に従って解析し，個々の検索要求に分割し，優先順位付与部５に渡す。
【００３３】
図４は，検索要求分割部４によって，図３の検索要求を分割した結果の一例である。この表は，検索要求保持部９に格納される。
【００３４】
同図４は，図３の検索要求における「検索項目」の内容をそのまま書き下した形になっており，検索Ｎｏ．１は「北海道」，検索Ｎｏ．２は「岩手」，検索Ｎｏ．３は「東京」，検索Ｎｏ．４は「大阪」，検索Ｎｏ．５は「山口」，検索Ｎｏ．６は「愛媛」，検索Ｎｏ．７は「熊本」となる。
【００３５】
もし，「付帯条件」の項目が存在していれば，各検索要求にそれが反映される。例えば，「付帯条件」に「温泉」が指定されていたとすると，検索Ｎｏ．１は「北海道 ＡＮＤ 温泉」，検索Ｎｏ．２は「岩手 ＡＮＤ 温泉」，検索Ｎｏ．３は「東京 ＡＮＤ 温泉」，検索Ｎｏ．４は「大阪 ＡＮＤ 温泉」，検索Ｎｏ．５は「山口 ＡＮＤ 温泉」，検索Ｎｏ．６は「愛媛 ＡＮＤ 温泉」，検索Ｎｏ．７は「熊本 ＡＮＤ 温泉」となる。ここで，キーワードの論理積を検索要求に記述するために，各キーワードを「ＡＮＤ 」で区切って記述するとした。
【００３６】
優先順位付与部５では，図４のように分割された検索要求を受け取ると，図３の「興味項目」などの情報から優先順位を判定し，検索要求保持部９に格納する。その後，優先順位の高い検索要求から，検索処理部６の数分，検索処理部６に検索要求を発行し，残った検索要求のリストを検索処理完了判定部８に渡す。
【００３７】
図５は，優先順位付与部５によって優先順位を判定され，検索要求保持部９に格納された検索要求の一例である。この表（以下，検索要求表と称する）は，図４の表を拡張した形（優先順位が付与される）で検索要求保持部９に格納される。
【００３８】
同図５では，図３の「興味項目」に第１位の必要性と記述されている検索Ｎｏ．３「東京」と検索Ｎｏ．４「大阪」とを優先順位「１」とし，第２位の必要性と記述されている検索Ｎｏ．１「北海道」を優先順位「２」とし，その他を優先順位「３」としている。また，同じ優先順位の項目の順序については，検索要求分割部４によって分割された順としている。
【００３９】
同図５に示した「ポインタ」は，検索要求をどこまで発行したかを表しており，検索処理完了判定部８などから参照される。
【００４０】
検索処理部６は，優先順位付与部５から受け取った検索要求を処理する。ここでは，例えば，データベース１０に投入されたテキスト群から全文検索を行い，検索要求に適合したテキストを返す処理を行うとする。検索処理部６は，このような全文検索処理を独立に実行できるユニットをｎ個持っている。ここで，ｎはｎ≧１を満たす自然数である。
【００４１】
検索処理部６の実現方法としては，例えば，データベース１０のコピーをｎ個用意して，全文検索を実行できる計算機ｎ台をそれにつなぎ，それぞれネットワークを使って，優先順位付与部５や検索処理完了判定部８や検索結果統合部７と結ぶことが挙げられる。
【００４２】
ここで，検索処理部６の各検索処理装置間の性能に差異がある場合は，検索性能の高い順に優先順位の高い検索要求を割り振ることで，システムとして極大の性能を引き出すことができる。
【００４３】
さて，検索処理部６により検索された結果は，検索結果統合部７や検索処理完了判定部８に渡される。この際，検索処理の結果を統合したり，検索処理の終了を判定するために，検索要求保持部９に格納されている検索要求表（図５に示すもの）を拡張する。拡張する項目は，検索結果統合部７において行う統合処理の内容に依存するが，ここでは一例として，全文検索の結果，マッチした文書の数（以下，検索数と呼ぶ）を統合することとし，これに合わせて，検索要求表にこの検索数を拡張していくことを想定する。
【００４４】
図６は，検索要求保持部９に格納されている検索要求表に，検索数を拡張した例である。なお，この検索要求表には，図５に示した優先順位の情報も保持されているが，図６ではそれを省いてある。
【００４５】
同図６の「検索数」の列には，検索処理部６から検索結果統合部７に渡された，全文検索の結果マッチした文書の数が格納されている。検索処理部６からの結果が検索結果統合部７にまだ届いていない場合は，特殊な値「＃＃＃＃＃」が格納されている。検索処理完了判定部８で実行する検索が全て終了したかどうかの判定は，「検索数」の列に，この値「＃＃＃＃＃」が存在するか否かで行うことができる。
【００４６】
検索結果統合部７では，検索処理部６から受け取った検索数を，逐次，該当する検索要求と合わせて，検索インタフェース部３に渡す。
【００４７】
図７は，検索結果統合部７から検索インタフェース部３に渡される検索結果の一例である。同図７の（ａ），（ｂ），（ｃ）は，検索インタフェース部３に渡される結果を時系列的に図示したもので，（ａ）は図６が示すのと同じ状態，（ｂ）はその少し後の状態，（ｃ）は検索が全て終了した状態を示している。
【００４８】
同図７に示した検索結果は，例として，図３の検索要求に対応した表となっている。同図７では，図３で「検索項目」として列記した項目に対応する形で，「東京 １２０」「北海道 ４０」「大阪 ５０」「岩手 ３０」「山口 １１」「愛媛 ９」「熊本 １０」という検索数を返している。
【００４９】
同図７に示した検索結果が並ぶ順序は，検索結果統合部７が検索処理部６から受け取った順である。つまり，個々の検索が先に終了した結果から順次検索インタフェース部３に送られるわけだが，もしも個々の検索が同時に終了した場合には，図５における優先順位が高い方から先に送られることになる。
【００５０】
検索処理完了判定部８は，検索処理部６から受け取った検索数を，検索要求保持部９に格納されている検索要求表の該当する検索要求の欄に代入する。そして，「検索数」の列に値「＃＃＃＃＃」が存在しない場合には，検索結果統合部７に対して，検索終了通知を渡す。反対に，「検索数」の列に値「＃＃＃＃＃」が存在する場合には，前記図５のポインタを用いて，優先順位の高い検索要求から順に検索処理部６に割り振って検索を進める。
【００５１】
ここで，検索処理部６の各検索処理装置間の性能に差異がある場合は，検索性能の高い順に優先順位の高い検索要求を割り振ることで，システムとして極大の性能を引き出すことができる。上述した検索結果統合部７は，検索処理部６から検索数を受け取るのと同時に，検索処理完了判定部８からの検索終了通知を待っている。そして，この検索終了通知を受け取ると，検索処理部６から受け取った検索数の処理の終了を待った後，検索インタフェース部３に対して，通信終了通知を渡す。
【００５２】
これによって，検索が先に終了した結果から順次検索インタフェース部３に送られ，続いてクライアントシステム１に送られる。検索インタフェース部３に，ＷＷＷにおけるＣＧＩプログラムを用いた場合，ＷＷＷの標準プロトコルであるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を使って，検索インタフェース部３とクライアントシステム１との間の通信が行われる。このプロトコルで通信が行われると，検索が終了するまで通信回線が保持されるので，検索インタフェース部３が受け取った検索結果は，即座にクライアントシステム１に伝えられることになる。
【００５３】
クライアントシステム１では，自身が送信した図３の検索要求で指定した順序や，この検索要求で指定した優先順位とは異なる順序で検索結果が返信されることを考慮して実装する必要がある。つまり，図７のような検索結果が返信された場合であっても，検索項目をキーとして検索結果を統合処理し，結果が０でない県に対して地図上の棒グラフとして表現することで，図２のような視覚化結果を得るように処理する。
【００５４】
検索結果統合部７，検索処理完了判定部８，検索インタフェース部３からクライアントシステム１に通ずるシステムの動作をまとめる。ここでは，説明の便宜上，検索処理部６には，能力の等価な３つのユニット（検索処理装置）が存在するものとして説明を行う。
【００５５】
優先順位付与部５から検索処理部６に発行された検索要求「東京」「大阪」「北海道」の処理（優先順位に従ってこの３つの検索要求が３つのユニットに発行される）が終わると，検索結果が検索処理部６から検索結果統合部７，検索処理完了判定部８に送られる。このとき，「大阪」の検索処理が遅れ，「東京」「北海道」の検索結果が得られたとする。
【００５６】
検索結果統合部７では，得られた検索結果「東京 １２０」「北海道 ４０」を検索インタフェース部３に渡す。検索処理完了判定部８では，図６に示す拡張された検索要求表の「検索数」欄の「東京」「北海道」に，それぞれ「 １２０」「４０」を代入し，図５のポインタを用いて，処理の済んでいない検索要求から，「岩手」「山口」の２つを検索処理部６の空いている２つのユニットに対して発行し，ポインタを「愛媛」に移す。
【００５７】
検索インタフェース部３では，「東京 １２０」「北海道 ４０」をクライアントシステム１に対して送信する。クライアントシステム１では，検索結果の統合処理を行うが，以前には何も届いていなかったので，受信した「東京 １２０」「北海道 ４０」を結果として図７（ａ）を得る。この結果を地図上の棒グラフとして表現することで，優先順位第１位の「東京」と第２位の「北海道」とが画面に表示される。
【００５８】
次に，検索処理部６で処理中の検索要求「岩手」「大阪」「山口」の内，「岩手」「大阪」の検索処理が終わり，検索結果が検索結果統合部７，検索処理完了判定部８に送られたとする。
【００５９】
検索結果統合部７では，得られた検索結果「岩手 ３０」「大阪 ５０」を検索インタフェース部３に渡す。このとき，「岩手」と「大阪」では，「大阪」の方が優先順位が高いので，「大阪 ５０」→「岩手 ３０」の順で検索インタフェース部３に渡す。
【００６０】
検索処理完了判定部８では，図６に示す拡張された検索要求表の「検索数」欄の「岩手」「大阪」に，それぞれ「３０」「５０」を代入し，図５のポインタを用いて，処理の済んでいない検索要求から，「愛媛」「熊本」の２つを検索処理部６の空いている２つのユニットに対して発行し，ポインタを「処理対象なし」状態とする。
【００６１】
検索インタフェース部３では，「大阪 ５０」「岩手 ３０」をクライアントシステム１に対して送信する。クライアントシステム１では，検索結果の統合処理を行い，受信した「大阪 ５０」「岩手 ３０」を，以前受信した「東京 １２０」「北海道 ４０」の後に追加して図７（ｂ）を得る。この結果を地図上の棒グラフとして表現することで，優先順位第１位の「大阪」と優先順位なしの「岩手」とが，先に表示されていた「東京」「北海道」に加えて画面に表示される。
【００６２】
次に，検索処理部６で処理中の検索要求「愛媛」「熊本」「山口」の内，「山口」の検索処理が終わり，検索結果が検索結果統合部７，検索処理完了判定部８に送られたとする。
【００６３】
検索結果統合部７では，得られた検索結果「山口 １１」を検索インタフェース部３に渡す。検索処理完了判定部８では，図６に示す拡張された検索要求表の「検索数」欄の「山口」に「１１」を代入する。このとき，図５のポインタは「処理対象なし」状態であるため，新たな検索要求は発行されない。
【００６４】
検索インタフェース部３では，「山口 １１」をクライアントシステム１に対して送信する。クライアントシステム１では，検索結果の統合処理を行い，受信した「山口 １１」を，以前受信した「東京 １２０」「北海道 ４０」「大阪 ５０」「岩手 ３０」の後に追加する。この結果を地図上の棒グラフとして表現することで，優先順位なしの「山口」が，先に表示されていた「東京」「北海道」「大阪」「岩手」に加えて画面に表示される。
【００６５】
最後に，検索処理部６で処理中の検索要求「愛媛」「熊本」の検索処理が終わり，検索結果が検索結果統合部７，検索処理完了判定部８に送られる。
【００６６】
検索結果統合部７では，得られた検索結果「愛媛 ９」「熊本 １０」を検索インタフェース部３に渡す。検索処理完了判定部８では，図６に示す拡張された検索要求表の「検索数」欄の「愛媛」「熊本」に，それぞれ「９」「１０」を代入する。このとき，図５のポインタは「処理対象なし」状態であるため，新たな検索要求は発行されない。
【００６７】
更に，図６に示す拡張された検索要求表の「検索数」列に値「＃＃＃＃＃」が存在しなくなるため，検索処理完了判定部８では，検索結果統合部７に対して検索終了通知を渡す。これ受けて，検索結果統合部７では，得られた検索結果「愛媛 ９」「熊本 １０」を検索インタフェース部３に渡す処理が終了したら，検索インタフェース部３に対して通信終了通知を渡す。
【００６８】
検索インタフェース部３では，「愛媛 ９」「熊本 １０」をクライアントシステム１に対して送信する。その後，即座に検索結果統合部７から通信終了通知を受け取るため，クライアントシステム１の受信を待って通信回線を切断する。
【００６９】
クライアントシステム１では，検索結果の統合処理を行い，受信した「愛媛 ９」「熊本 １０」を，以前受信した「東京 １２０」「北海道 ４０」「大阪 ５０」「岩手 ３０」「山口 １１」の後に追加して図７（ｃ）を得る。この結果を地図上の棒グラフとして表現することで，優先順位なしの「愛媛」「熊本」が，先に表示されていた「東京」「北海道」「大阪」「岩手」「山口」に加えて画面に表示される。これで，前記図２が完成するわけである。
【００７０】
以上のようにして，並列型の検索要求に優先順位を付けて検索を実行し，優先順位の高いものから統合して結果を返すことができる。
【００７１】
この例では，計算機の過負荷等の原因によって，検索処理部６の各ユニットが当初の性能を発揮できないことで，指定した優先順位とは異なった順序で結果が返ることを想定しているが，そのような場合でも，システム全体として最善の性能を得ることができるようになっている。なお，検索処理部６の各ユニットが同性能で性能を十分に発揮できる場合には，指定した優先順位の順序で結果を返すことができる。
【００７２】
ここまでで示したシステムは，一組の並列型検索要求に対する一例であり，二組以上の並列型検索要求に対して，優先順位を付与して検索を実行することには適していない。しかし，二組以上の並列型検索要求を分割した個々の検索要求に対して，全体として矛盾なく一般的な優先順位を付けることで，以上のシステムを，二組以上の並列型検索要求に対するシステムに拡張することができる。
【００７３】
次に，二組以上の並列型検索要求に対して本発明を用いるための拡張について詳細に説明する。
【００７４】
この拡張を行った場合，検索要求保持部９に格納される図４／図６の表と図５の表とは，同一の表の一部を切り出したものではなくなる。この場合には，図４（但し，図６と同様な検索数のエントリーを持つ）／図６の表は，並列型検索要求の処理が完了したのか否かのチェックを可能とするために，一つ一つの並列型検索要求に対応して複数用意されるのに対し，次に発行する検索要求の指定に用いられるポインタを持つ図５の表は，未処理の検索要求を統括的に管理するために，一つのシステムに対して一つ用意されることになる。
【００７５】
すなわち，図８に示すように，図４や図６に示すような検索要求表は，各並列型検索要求に対応付けて用意されるのに対して，図５に示すような表（以下，優先順位表と呼ぶ）は，一つのシステムに対して一つ用意されることになる。
【００７６】
この拡張を実装するためのポイントは，優先順位付与部５である。その他は，そのまま利用できる。以下，拡張された優先順位付与部５を拡張優先順位付与部と呼称する。
【００７７】
図９は，拡張優先順位付与部を説明するための追加の検索要求例として，「検索項目」に「青森」「群馬」「栃木」「静岡」「愛知」「高知」「沖縄」，「付帯条件」に「温泉」，「興味項目」に「青森，沖縄」「静岡」という内容を持った検索要求に対して，検索要求分割部４による処理を経た後の図である。
【００７８】
ここで，個々の検索要求を見分けるために，検索要求の番号として，
「検索要求の先着順」＋「−」＋「番号」
を採用した。但し，「検索要求の先着順」が「１」のときは，特別に「番号」のみとする。この例では，最初に，図３に示す並列型検索要求が発行され，その後，図９に示す並列型検索要求が発行されたことを想定している。
【００７９】
このような番号付与による識別子によって各並列型検索要求が区別され，後述することから分かるように，この識別子を使って，通信接続や，検索処理部から得た結果を統合する処理や，並列型の検索要求が全て処理されたかを判定する処理などが実行されることになる。
【００８０】
拡張優先順位付与部では，図４や図９のように分割された検索要求を受け取ると，図４（図３）や図９の「興味項目」や，検索要求の到着順などの情報から優先順位を判定し，検索要求保持部９に格納する。その後，優先順位の高い検索要求から，検索処理部６の中の処理を実行していないユニットに対して検索要求を発行し，残った検索要求のリストを検索処理完了判定部８に渡す。
ここで，拡張優先順位付与部は，１，２，３・・・というような自然数表現の優先順位を付与するのではなくて，そのような自然数表現の優先順位を決定可能とする値を持つ優先順位を付与することになる。
【００８１】
図１０及び図１１は拡張優先順位付与部によって優先順位を判定され，検索要求保持部９に格納された検索要求の一例である。この表（優先順位表）は，検索要求保持部９に格納される。
【００８２】
同図１０及び図１１における優先順位（１，２，３・・・というような自然数表現の優先順位ではなくて，そのような自然数表現の優先順位を決定可能とする値を持つ優先順位）は，図４（図３）や図９の「興味項目」に記述される必要性の度合いと，検索要求の到着順によって，
「必要性の順位」×１０＋「検索要求の到着順」
の式で計算される。
【００８３】
つまり，最初に到達する，図４に示した第１番目の検索要求の内，第１位の必要性と記述されている検索Ｎｏ．３「東京」と検索Ｎｏ．４「大阪」とを優先順位「１１（＝１＊１０＋１） 」とし，第２位の必要性と記述されている検索Ｎｏ．２「北海道」を優先順位「２１（＝２＊１０＋１） 」とし，その他を優先順位「３１（＝３＊１０＋１） 」としている。
【００８４】
また，その後に到達する，図９に示した第２番目の検索要求の内，第１位の必要性と記述されている検索Ｎｏ．２−１「青森 ＡＮＤ 温泉」と検索Ｎｏ．２−７「沖縄 ＡＮＤ 温泉」とを優先順位「１２（＝１＊１０＋２） 」とし，第２位の必要性と記述されている検索Ｎｏ．２−４「静岡 ＡＮＤ 温泉」を優先順位「２２（＝２＊１０＋２） 」とし，その他を優先順位「３２（＝３＊１０＋２） 」としている。ここで，同じ優先順位の項目の順序については，検索要求分割部４によって分割された順としている。
【００８５】
同図１０及び図１１に示した「ポインタ」は，検索要求をどこまで発行したかを表し，検索処理完了判定部８などから参照される。
【００８６】
図１０と図１１の違いは，図１０では，２つの検索要求がほぼ同時に到着したために，拡張優先順位付与部は，全ての検索要求を優先順位の高い順に整列させた後，優先順位に従って，検索Ｎｏ．３「東京」，検索Ｎｏ．４「大阪」，検索Ｎｏ．２−１「青森 ＡＮＤ 温泉」を検索処理部６（３つのユニットを持つ）に発行し，「ポインタ」を検索Ｎｏ．２−７「沖縄 ＡＮＤ 温泉」の位置に設定している。
【００８７】
これに対して，図１１では，図４に示す検索要求が早く到着したことで，拡張優先順位付与部は，検索Ｎｏ．３「東京」，検索Ｎｏ．４「大阪」，検索Ｎｏ．１「北海道」を検索処理部６に発行し，それらの検索処理中に，図９に示す検索要求が到着したため，既に発行済みの検索要求はそのままにして，「ポインタ」が指し示す以降の検索要求に対して優先順位の高い順に整列させている点である。
【００８８】
このような処理を実装することで，システムに対する検索要求が単一の場合も，複数の場合でも，ある時点で利用可能な検索処理ユニットの全てを有効に活用することができ，極大のパフォーマンスを得ることができる。
【００８９】
図１２に，本発明を実現する上でポイントとなる拡張優先順位付与部（優先順位付与部５）で行われる処理のフローチャートを図示する。次に，このフローチャートに従って，拡張優先順位付与部（優先順位付与部５）で行われる処理について詳細に説明する。
【００９０】
拡張優先順位付与部（優先順位付与部５）は，このフローチャートに示すように，ステップＳ１として，検索要求分割部４から図４や図９のような分割された検索要求が渡されるのを待つ。本ステップは，説明の便宜上，このような実装になっているが，検索要求分割部４とまとめて実装した場合には，このステップＳ１を省略することができる。検索要求分割部４から検索要求が渡されると処理をステップＳ２に移行する。
【００９１】
ステップＳ２では，変数「通し番号（検索要求の到着順を示す）」に対して１を加える。これは，図９の「Ｎｏ．」項目のような番号を一意に決定するためである。変数「通し番号」は，本発明の装置が１つも検索要求を処理していない状況において，リセットしてもよい。
【００９２】
次にステップＳ３として，検索要求分割部４で分割された検索要求を１つ取得する。検索要求は個々に分割されているので，適宜「Ｎｏ．」の項目等を利用して，この取得を行う。
【００９３】
その後，ステップＳ４では，ステップＳ３で取得した検索要求がクライアントシステム１から渡された興味項目の中に存在するか否かをチェックし，存在しない場合はステップＳ５へ，存在する場合はステップＳ６へ制御を移す。
【００９４】
ステップＳ５では，興味項目に現在処理中の検索要求が含まれていないので，その現在処理中の検索要求に対して，最低の優先順位を割り当てる。ここで，最低の優先順位とは，興味項目に記述された最低の順位（優先度）に１を加えたものとする。図４に示す検索要求で説明するならば，例えば「岩手」の検索要求に対して優先順位３を割り当てるのである。その後ステップＳ７へ制御を移す。
【００９５】
逆に，ステップＳ６では，興味項目に現在処理中の検索要求が含まれているので，その現在処理中の検索要求に対して，興味項目に記述された順位（優先度）を割り当てる。興味項目が図４や図９のように与えられる場合，その順位は，「興味項目＝」で開始される行から行毎に，１，２，３，・・と数えることで与えられる。
【００９６】
ここで，もし，クライアントシステム１あるいは利用者として，システム全体の性能を向上させるために，順位を下げてもよい項目があったら，図３のような興味項目の記述を変更して，例えば，１行目「興味項目＝東京，大阪」，２行目「北海道」，３行目「９：愛媛」というように記述するようにする。この場合には，前記の順位の取得法に加えて，「：」の前に記述される数字を順位とする。この例の場合で説明するならば，「東京」「大阪」という検索要求の順位は１，「北海道」の順位は２，「愛媛」の順位は９となる。その後ステップＳ７へ制御を移す。
【００９７】
ステップＳ７では，ステップＳ５，ステップＳ６で取得した興味項目内の順位すなわち優先度を基に優先順位を計算する。優先順位の計算は，例えば，ステップＳ２で設定した「通し番号」を用いて，
「興味項目内の順位」×１０＋「通し番号」
で与える。このような優先順位を用いることによって，先着順で高い興味項目内の順位を持つものを優先して検索を行うことができる。その後ステップＳ８へ制御を移す。
【００９８】
ステップＳ８では，図５や図１０や図１１のような優先順位表（次に要求する検索要求を指定するポインタを持つ表）を更新する。まず，優先順位表が存在しない場合は，新たに作成し，ポインタを「処理対象なし」状態に初期化する。ポインタが「処理対象なし」状態の場合は，現在処理中の検索要求を優先順位表に追加し，ポインタを追加した検索要求に合わせる。ポインタが有効な検索要求を指している場合は，ポインタが指す検索要求から始めて，より優先順位が低い検索要求の方向に，現在処理中の検索要求よりも優先順位の低い検索要求を探し出して，その位置に現在処理中の検索要求を挿入する。
【００９９】
このような処理を行うことで，既に処理を開始してしまった検索要求と矛盾することなく，未処理の検索要求の中で優先順位の高い順に処理が行われるようにすることができる。その後ステップＳ９へ制御を移す。
【０１００】
ステップＳ９では，ステップＳ３で取得される検索要求がまだ残っているかどうかを判定し，残っている場合はステップＳ３へ，残っていない場合はステップＳ１０へ制御を移す。検索要求が残っているかどうかの判定は，ステップＳ３の処理と同時に行ってもよい。
【０１０１】
次に，ステップＳ１０では，検索処理部６に空いているユニットがあるかどうかを調べ，空いていればステップＳ１１へ，全て処理中であればステップＳ１２へ制御を移す。
【０１０２】
ステップＳ１１では，図５や図１０や図１１のような優先順位表のポインタが指している検索要求を検索処理部６の空いているユニットへ送信し，ポインタを次の優先順位を持つ検索要求に進める。空いているユニットを示す情報を更新した後，ステップＳ１０へ制御を戻す。
【０１０３】
ステップＳ１２では，検索処理完了判定部８に対して，優先順位表及びポインタに変更を加えたことを通知して，ステップＳ１へ制御を移す。ステップＳ１では，上述したように，検索要求分割部４から図４や図９のような分割された検索要求が渡されるのを待機する。実装においてステップＳ１を省略した場合，ステップＳ１２からステップＳ１へ制御を移すことはなく，拡張優先順位付与部を終了する。
【０１０４】
以上のようにして，クライアントシステム１からの複数の検索要求に対して，検索サーバシステム２内で実行済みの要求と矛盾しない優先順位を与えることができ，図５や図１０や図１１のような優先順位表を得ることができる。
【０１０５】
図１３及び図１４に，本発明を実現する上でポイントとなる，検索結果統合部７及び検索処理完了判定部８で行われる処理のフローチャートを図示する。次に，このフローチャートに従って，検索結果統合部７及び検索処理完了判定部８で行われる処理について詳細に説明する。
【０１０６】
このフローチャートに示すように，まず，ステップＳ２０として，検索処理部６から検索結果が渡されるのを待機する。本ステップにおける検索処理部６との通信部分の実装は，検索処理部６との通信が複数同時に発生する可能性があることを考慮に入れて実装する。検索処理部６から検索結果が渡されると，処理をステップＳ２１に移行する。
【０１０７】
ステップＳ２１では，検索処理部６から渡された検索結果の中から，図５や図１０や図１１のような優先順位表に照らして，優先順位の最も高いものを選択（取り出し）し，検索結果が格納されているバッファからそれを消去する。その後ステップＳ２２へ制御を移す。
【０１０８】
ステップＳ２２では，ステップＳ２１で選択された検索結果を検索インタフェース部３へ通知する。検索インタフェース部３では，検索要求の「Ｎｏ．」をキーとして返信する通信セッションを判定し，クライアントシステム１との通信を行う。その後ステップＳ２３へ制御を移す。ステップＳ２２の処理を行うことによって，クライアントシステム１は全ての検索結果が出るのを待つ必要がなく，優先順位の高い順に検索結果を得ることができる。
【０１０９】
ステップＳ２３では，図４や図９を拡張した図６のような検索要求表（検索結果の記録域を持つ検索要求表）に対して，ステップＳ２１で選択された検索結果に該当する部分を探索し，そこに検索結果を代入する。ここで，検索結果に該当する部分の探索には検索要求の「Ｎｏ．」をキーとして検索を行う。また，検索要求表が複数存在するときには，検索要求の「Ｎｏ．」から先ず最初に検索要求表を特定することになる。その後ステップＳ２４へ制御を移す。
【０１１０】
ステップＳ２４では，検索処理部６から渡された検索結果で，まだ処理していないものがあるかどうかを判定し，まだ処理していないものがある場合はステップＳ２５へ，渡された検索結果が全て処理済みならステップＳ２６へ制御を移す。本ステップの判定は，検索結果が格納されているバッファに残りがあるのか否かをチェックすることで実現できる。
【０１１１】
ステップＳ２５では，検索処理部６から渡された検索結果で未処理な検索結果の中から，図５や図１０や図１１のような優先順位表に照らして，優先順位の最も高いものを選択（取り出し）し，検索結果が格納されているバッファからそれを消去する。その後ステップＳ２２へ制御を移す。
【０１１２】
ステップＳ２６では，検索要求表の全てに対して，以下のステップＳ２７の処理が実行されたかどうかを判定する。未処理の検索要求表がある場合はステップＳ２７へ，全て処理済みの場合はステップＳ２９へ制御を移す。
【０１１３】
ステップＳ２７では，図４や図９を拡張した図６のような検索要求表の検索数に，「＃＃＃＃＃」が含まれるかどうかの判定を行い，「＃＃＃＃＃」が含まれていない場合はステップＳ２８へ，「＃＃＃＃＃」が含まれている場合はステップＳ２６へ制御を移す。
【０１１４】
ステップＳ２８では，検索インタフェース部３に対して，ステップＳ２７で「＃＃＃＃＃」が含まれていないと判定された検索要求表に対応する通信セッションの切断を指示する通信終了通知を渡す。これを受けて，検索インタフェース部３では，検索要求表の「Ｎｏ．」をキーとして終了する通信セッションを判定し，クライアントシステム１との通信が終了し次第，その通信セッションを切断する。その後ステップＳ２６へ制御を移す。
【０１１５】
ステップＳ２９では，図５や図１０や図１１のような優先順位表に付随するポインタの値を判定して，「処理対象なし」の場合にはステップＳ２０へ，ポインタが次の検索要求を指している場合にはステップＳ３０へ制御を移す。
【０１１６】
ステップＳ３０では，まず検索処理部６中のユニットがいくつ利用可能かを調査し，図５や図１０や図１１のような優先順位表とポインタとを用いて，検索処理部６の利用可能なユニットに対して，未実行の検索要求で優先順位が高い順に検索要求を発行する。その後ステップＳ３１へ制御を移す。なお，利用可能ユニット数の調査は，検索処理部６が本システムのみから用いられている仮定した場合，前記ステップＳ２３で処理した検索結果の数と同じと見ることができる。
【０１１７】
ステップＳ３１では，ステップＳ３０で発行した検索要求の数分，優先順位の低い検索要求へポインタを移す。この際，優先順位表に検索要求が残らない場合は，ポインタを「処理対象なし」状態とする。その後ステップＳ２０へ制御を移す。
【０１１８】
以上のようにして，検索処理部６から渡された検索結果を受け付け，優先順位の高い順に検索インタフェース部３へ渡すことができ，また，まだ処理していない検索要求があった場合，優先順位の高い順に検索処理部６に渡して検索を行うことができる。
【０１１９】
上記したように，本発明の並列型検索要求分散統合処理装置を用いることで，各県名が含まれる情報をデータベースから視覚化するなど，多くの検索要求を発行して得られた結果を統合して処理する必要のあるシステムにおいて，個々の検索要求が独立して実行でき，利用できる検索処理部が複数存在する場合に，全ての検索処理部を効率よく利用し，統合処理を実行する際に最も必要となる部分から先に検索を行うことで，システム全体の応答時間を速くし，かつ，利用者から見て必要な部分から先に提示されるシステムを構築することができる。
【０１２０】
【発明の効果】
以上説明したように，本発明によれば，各々独立で並列に処理できる個々の検索要求に対して，複数の検索処理部が存在する場合に，各検索要求に対して優先順位を付与し，優先順位の高いものから検索処理部の数分の並列度で検索を実行した後に，先に返ってきた結果から順に統合して即座に返答処理を行うことが可能となるという効果がある。
この構成の実現にあたって，本発明では，複数の並列型検索要求に対して統一的な優先順位を付与するということから，複数の並列型検索要求が発行される場合にあっても，優先順位の高いものから検索処理部の数分の並列度で検索を実行した後に，先に返ってきた結果から順に統合して即座に返答処理を行うことが可能となるという効果がある。
【図面の簡単な説明】
【図１】並列型検索要求分散統合処理装置の一実施例である。
【図２】本発明の適用される検索処理の一例である。
【図３】検索要求の一例である。
【図４】分割された検索要求の一例である。
【図５】検索要求表の一例である。
【図６】拡張された検索要求表の一例である。
【図７】検索結果の一例である。
【図８】検索要求表／優先順位表の説明図である。
【図９】分割された検索要求の一例である。
【図１０】優先順位表の一例である。
【図１１】優先順位表の一例である。
【図１２】拡張優先順位付与部の処理フローである。
【図１３】検索結果統合部／検索処理完了判定部の処理フローである。
【図１４】検索結果統合部／検索処理完了判定部の処理フローである。
【符号の説明】
１ クライアントシステム
２ 検索サーバシステム
３ 検索インタフェース部
４ 検索要求分割部
５ 優先順位付与部
６ 検索処理部
７ 検索結果統合部
８ 検索処理完了判定部
９ 検索要求保持部
１０ データベース
Claims (3)
- 複数の検索処理部を使って，並列型の検索要求を並列処理する検索要求並列処理方法であって，
同一検索項目について複数の項目値が指定され，かつ，それらの項目値について利用者により設定された順位情報を持つように構成される並列型検索要求を受け取り，それらの項目値に基づいて，その並列型検索要求を個々の検索要求に分割する第１の処理過程と，
上記順位情報による順位に基づいた大きな重みを与えることにより，上記分割した検索要求について並列型検索要求内での優先順位を示す値を求め，それに並列型検索要求の受け取り順序に基づいた小さな重みを加えることにより，上記分割した検索要求について最終的な優先順位を示す値を求めて，各検索処理部に対して該優先順位の高い検索要求を要求する第２の処理過程と，
検索処理部が検索結果を得るときに，それらの検索結果を受け取り，上記優先順位の高いものからの順番に従って，それらの検索結果を検索要求発行元に返答する第３の処理過程と，
検索処理部が検索結果を得るときに，未要求の検索要求が残されているのかを判断して，残されている場合には，上記優先順位の高いものからの順番に従って，空いている検索処理部に対して未要求の検索要求を要求する第４の処理過程とを備える
ことを特徴とする検索要求並列処理方法。 - 請求項１記載の検索要求並列処理方法において，
検索処理部が検索結果を得るときに，並列型検索要求に対応付けて用意される表に，該検索結果の元となった検索要求の処理終了を示す情報を記録する処理過程と，
該記録された情報に従って，並列型検索要求の処理の完了を判定する処理過程とを備える
ことを特徴とする検索要求並列処理方法。 - 複数の検索処理部を使って，並列型の検索要求を並列処理する検索要求並列処理方法の実現に用いられるプログラムが記録されるプログラム記録媒体であって，
同一検索項目について複数の項目値が指定され，かつ，それらの項目値について利用者により設定された順位情報を持つように構成される並列型検索要求を受け取り，それらの項目値に基づいて，その並列型検索要求を個々の検索要求に分割する処理と，
上記順位情報による順位に基づいた大きな重みを与えることにより，上記分割した検索要求について並列型検索要求内での優先順位を示す値を求め，それに並列型検索要求の受け取り順序に基づいた小さな重みを加えることにより，上記分割した検索要求について最終的な優先順位を示す値を求めて，各検索処理部に対して該優先順位の高い検索要求を要求する処理と，
検索処理部が検索結果を得るときに，それらの検索結果を受け取り，上記優先順位の高いものからの順番に従って，それらの検索結果を検索要求発行元に返答する処理と，
検索処理部が検索結果を得るときに，未要求の検索要求が残されているのかを判断して，残されている場合には，上記優先順位の高いものからの順番に従って，空いている検索処理部に対して未要求の検索要求を要求する処理とをコンピュータに実行させるプログラムが記録される
ことを特徴とするプログラム記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP23018799A JP3634681B2 (ja) | 1999-08-17 | 1999-08-17 | 検索要求並列処理方法，及びその方法の実現に用いられるプログラム記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP23018799A JP3634681B2 (ja) | 1999-08-17 | 1999-08-17 | 検索要求並列処理方法，及びその方法の実現に用いられるプログラム記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001052027A JP2001052027A (ja) | 2001-02-23 |
| JP3634681B2 true JP3634681B2 (ja) | 2005-03-30 |
Family
ID=16903965
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP23018799A Expired - Fee Related JP3634681B2 (ja) | 1999-08-17 | 1999-08-17 | 検索要求並列処理方法，及びその方法の実現に用いられるプログラム記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3634681B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090198703A1 (en) * | 2008-01-31 | 2009-08-06 | Hewlett-Packard Development Company, L.P. | Intelligent data storage system |
| JP5620617B1 (ja) * | 2014-05-28 | 2014-11-05 | 楽天株式会社 | 情報処理システム、端末、サーバ、情報処理方法、記録媒体、ならびに、プログラム |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5742806A (en) * | 1994-01-31 | 1998-04-21 | Sun Microsystems, Inc. | Apparatus and method for decomposing database queries for database management system including multiprocessor digital data processing system |
| JPH09305631A (ja) * | 1996-05-15 | 1997-11-28 | Nec Corp | データベース管理装置及びそのサーバプロセスの起動方法 |
| JPH10283371A (ja) * | 1997-04-04 | 1998-10-23 | Nec Corp | データベース装置 |
-
1999
- 1999-08-17 JP JP23018799A patent/JP3634681B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001052027A (ja) | 2001-02-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7644110B2 (en) | Stream data processing system and stream data processing method | |
| JP4792551B2 (ja) | カレントサーチ結果の中のアイテムをランク付ける方法およびシステム | |
| KR101298334B1 (ko) | 검색 결과에 컬렉션 아이템을 포함시키기 위한 기술 | |
| US9824154B1 (en) | Search engine query customization and search site rating system | |
| CN107066529B (zh) | 联合团体搜索 | |
| JP3872432B2 (ja) | 適応カタログ・ページ表示 | |
| US7720843B2 (en) | Real-time end-user aware interactive search utilizing layered approach | |
| KR100885772B1 (ko) | 제품 정보를 등록 및 검색하기 위한 방법 및 시스템 | |
| US7502774B2 (en) | Ring method, apparatus, and computer program product for managing federated search results in a heterogeneous environment | |
| US8155986B2 (en) | Collapsible itineraries | |
| JP5147947B2 (ja) | クエリ別検索コレクション生成方法およびシステム | |
| JP2019537131A (ja) | 情報を提供するための方法及び装置 | |
| JP2006510123A (ja) | キャラクタ・ストリームに関連するホスト・ベースのインテリジェントな結果 | |
| JP2010518526A (ja) | ウェブサービス照会方法および装置 | |
| US20150149449A1 (en) | Location based information display | |
| WO2001016807A1 (en) | An internet search system for tracking and ranking selected records from a previous search | |
| RU2653246C1 (ru) | Усовершенствование запроса для поиска базы данных | |
| US7917495B1 (en) | System and method for processing query requests in a database system | |
| CN109684282A (zh) | 一种构建元数据缓存的方法及装置 | |
| EP1109115A1 (en) | Merging driver for accessing multiple database sources | |
| CN109753504A (zh) | 数据查询方法及装置 | |
| US20170109451A1 (en) | In-view and out-of-view request-related result regions for respective result categories | |
| CN102214182A (zh) | 一种根据ip地址进行精确查询的搜索方法 | |
| US20080319946A1 (en) | Method and system for searching availability of an entity for purchase or reservation | |
| WO2008155212A1 (en) | Improvements in or relating to a method and system for a reservation or a purchase of an entity |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040914 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041115 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20041221 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041224 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D02 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090107 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100107 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110107 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |