JP2007265014A - 人材検索システム - Google Patents

Abstract

【課題】利用者の持つ人脈を利用し、或る利用者が特定のスキルを有する人材を検索し、検索結果として見つかった人物までの知人パス（知人をたどった、その人物までの道のり）を提示する人材検索システムを提供する。
【解決手段】或る特定のスキルを持つ人材を検索するサービスを行う人材検索システムＡにおいて、検索処理を実行する人材検索サーバー装置１と、この人材検索サーバー装置１に接続され、利用者が書いた文書を登録する文書データベース装置２と、前記人材検索サーバー装置１に接続され、利用者の持っている他人の名刺情報が登録される名刺管理データベース装置３と、前記人材検索サーバー装置１に接続され、利用者のスキルを紹介した文を登録する紹介文データベース装置４と、同様の構成を有する人材検索サーバー１ａ、１ｂと同じネットワーク上にて互いに通信を可能とする通信装置１４を含む。
【選択図】図１

Description

本発明は、コンピュータ、又はコンピュータネットワーク環境において特定の技能を持つ人材を検索する人材検索システムに関する。

従来、名刺情報は名刺を受け取った本人が管理、活用するものであって、他人に公開、活用されるものではなかった。さらにその名刺情報の人物が、名刺を受け取った後もどのような業務を行っているかを自動的に知る術は無かった。しかし、或る人物が仕事を依頼するために特定のスキル（技能）を有する人材を探している場合、名刺情報と業務情報を知る術がないため損失に繋がることがあった。
かかる状況を考慮して、名刺情報と業務情報を管理かつ活用するための技術も、従来、幾つか提案されている（例えば、特許文献１乃至３参照）。
特許文献１では、名刺を管理し、付加情報を付けた状態で情報を保存し、必要に応じて検索可能にしている。また、特許文献２では、利用者が人材情報を登録するようにしており、さらに、特許文献３では、人物のプロファイル情報を自動で作成している。
特開平６−２７４５５０号公報 特開２００３−１４１３８１公報 特開２００５−１１５６５１公報

しかしながら、特許文献１では、利用者が情報を管理して更新しなければならず、メンテナンスのコストが掛かり、また、特許文献２では、人材情報を登録する際、紹介する人材を登録しなければならず、利用者が使用する際の導入コスト、及びメンテナンスのコストが掛かり、さらに、特許文献３では、誰と誰が知り合いかは管理しておらず、人材検索の結果から紹介ルートが探せないという問題が残っている。
そこで、本発明の目的は、上述した実情を考慮して、利用者の持つ人脈を利用し、或る利用者が特定のスキルを有する人材を検索し、検索結果として見つかった人物までの知人パス（知人をたどった、その人物までの道のり）を提示する人材検索システムを提供することにある。

上記の課題を解決するために、請求項１に記載の発明は、或る特定のスキルを持つ人材を検索するサービスを行う人材検索システムにおいて、検索処理を実行する人材検索サーバー装置と、該人材検索サーバー装置に接続され、利用者が書いた文書を登録する文書データベース装置と、前記人材検索サーバー装置に接続され、利用者の持っている他人の名刺情報が登録される名刺管理データベース装置と、前記人材検索サーバー装置に接続され、利用者のスキルを紹介した文を登録する紹介文データベース装置と、ネットワークを介して通信可能に構成された通信装置と、を備える人材検索システムを特徴とする。
また、請求項２に記載の発明は、前記名刺管理データベース装置は、登録されている人物情報を他のデータベース装置の情報形式に変換するためのデータ交換装置が接続される請求項１記載の人材検索システムを特徴とする。
また、請求項３に記載の発明は、前記紹介文データベース装置に登録される文書が、前記文書データベース装置に登録されている文書から自動的に生成される請求項１記載の人材検索システムを特徴とする。

また、請求項４に記載の発明は、前記人材検索サーバー装置が、検索結果を生成した後、メールにて検索要求者に検索結果を通知する請求項１記載の人材検索システムを特徴とする。
また、請求項５に記載の発明は、前記人材検索サーバー装置には、検索結果対象となる人物と検索要求者間の知人を知人パスとして保存する知人パスデータベース装置が接続される請求項１記載の人材検索システムを特徴とする。
また、請求項６に記載の発明は、検索要求者から要求された検索結果の前記知人パスの人物に対して、紹介の承認を確認するための確認メールを送信する確認メール送信装置が接続される請求項５記載の人材検索システムを特徴とする。
また、請求項７に記載の発明は、前記確認メール送信装置には、メール中の、送信者の知人でない人物の人名を別の文字で置き換える人名マスク装置が接続される請求項５記載の人材検索システムを特徴とする。
また、請求項８に記載の発明は、前記紹介文データベース装置に登録される文の内容から特定の文字列を削除または別の文字列に置き換えるための文書フィルタ装置が接続される請求項５記載の人材検索システムを特徴とする。

本発明によれば、名刺情報、文書情報、紹介文を利用することで、離れた組織内の特定のスキルを有する人材を検索することができる。

以下、図面を参照して、本発明の実施形態を詳細に説明する。
図１は本発明による人材検索システムのシステム構成の第１の実施形態を示す概略図である。図１の人材検索システムＡにおいて、人材検索サーバー装置１は利用者から検索要求を受け、また、検索結果を出力するためのサービスの本システムの基幹となる構成要素である。
文書ＤＢ（データベース）装置２は利用者の作成した文書を登録するためのデータベースである。名刺管理ＤＢ装置３は利用者の名刺情報を登録するためのデータベースである。紹介文ＤＢ装置４は利用者のスキル（技能）や業務内容に関する文を登録するためのデータベースである。
メール送信装置５は検索結果を検索要求者に送信するための装置である。人脈ＤＢ装置６は利用者の知人を登録するためのデータベースである。データ交換装置７は人脈ＤＢ装置６に格納されているデータを他の形式のＤＢのデータと交換するための装置である。
検索結果出力装置８は検索結果を表示するための装置である。文書フィルタＤＢ装置９は紹介文ＤＢ装置４に登録する文書にフィルタを掛けるための文字列が登録されているデータベースである。検索条件入力装置１０は人材検索の条件を入力する装置である。
通信装置１４は人材検索サーバー１、１ａ、１ｂそれぞれと互いに通信するのに使用する。人材検索サーバー１ａ、１ｂは人材検索サーバー１と同じ構成になっており、説明は省略する。

図２は知人関係を説明する概略図である。ここで知人関係とは名刺を交換したことがある人物同士を示す。図中の人のアイコン同士を結んでいる実線が知人関係である。また、破線で囲んでいるのはそれぞれ別の組織であることを意味している。
ここではＳｖ１、Ｓｖ２及びＳｖ３があり、これらは、図１の人材検索サーバー１をＳｖ１、人材検索サーバー１ａをＳｖ２、そして人材検索サーバー１ｂをＳｖ３とする。
図３は紹介文データ特性処理の流れを示すフローチャートである。図４は名刺データベース更新処理の流れを示すフローチャートである。図５は問い合わせ処理の流れを示すフローチャートである。
次に、処理全体の流れを説明する。処理には大きく分けて３つの処理がある。紹介文ＤＢ登録処理、名刺ＤＢ登録処理及び人材（人物）検索処理である。図３に示すように、紹介ＤＢ登録処理は利用者が通常の業務で日常的に文章を作成し、情報共有のためにアクセス制限の掛けられたＤＢに文書を登録する際、自動で紹介文ＤＢ装置４（図１）の情報を更新するものである。この場合に、利用者は文書ＤＢ装置２（図１）に文章を登録し（Ｓ１）、登録文から紹介文を作成し（Ｓ２）、紹介文ＤＢ装置４に登録する（Ｓ３）。

図４の名刺ＤＢ登録処理は名刺を新たに受け取った際、利用者がＯＣＲのような自動認識処理、又は利用者自身の入力によって名刺管理ＤＢ装置３（図１）を更新するものである。利用者は名刺情報を入力する（Ｓ４）。次いで、名刺情報ＤＢと人脈ＤＢを更新する（Ｓ５）。
人材検索処理は利用者がある特定のスキル（技能）を有している人材を探したい時、人材検索サーバー１（図１）に対して問い合せ処理を行い、その結果を受け取るものである。
図５において、利用者が問い合わせを行う（Ｓ６）。次いで、問い合わせを受けたサーバーが他のサーバーに問い合わせをする（Ｓ７）。続いて、各サーバーの検索結果を問い合わせたサーバーが受け取る（Ｓ８）。問い合わせた利用者に結果を送る（Ｓ９）。
図６は図２のＳｖ１の名刺及び人脈データベースに格納されているデータを示す概略図である。図７は図２のＳｖ２の名刺及び人脈データベースに格納されているデータを示す概略図である。図８は図２のＳｖ３の名刺及び人脈データベースに格納されているデータを示す概略図である。
図６乃至図８において、データは、それぞれ、Ｓｖ１〜Ｓｖ３の名刺管理ＤＢ装置３（図１）及び人脈ＤＢ装置６（図１）に格納されている。

図９は図２のＳｖ１の文書データベースに格納されているデータを示す概略図である。図１０は図２のＳｖ２の文書データベースに格納されているデータを示す概略図である。図１１は図２のＳｖ３の文書データベースに格納されているデータを示す概略図である。図９乃至図１１において、データは、それぞれ、Ｓｖ１〜Ｓｖ３の文書ＤＢ（データベース）に格納されている。
図１２は図２のＳｖ１の紹介文データベースに格納されているデータを示す概略図である。図１３は図２のＳｖ２の紹介文データベースに格納されているデータを示す概略図である。図１４は図２のＳｖ３の紹介文データベースに格納されているデータを示す概略図である。
図１２乃至図１４において、これらのＤＢ装置に格納されるデータは文書ＤＢ装置２（図１）から自動で生成される。それぞれ、Ｓｖ１〜Ｓｖ３（図２）の文書ＤＢ装置に格納されている。
図１５は図２のＳｖ１の文書フィルタデータベースに格納されているデータを示す概略図である。図１６は図２のＳｖ２の文書フィルタデータベースに格納されているデータを示す概略図である。図１７は図２のＳｖ３の文書フィルタデータベースに格納されているデータを示す概略図である。図１５乃至図１７において、それらの文書フィルタＤＢには、削除文字列、作成、考察、システム等のデータが格納される。

図１８は文書ＤＢから自動で生成されるデータの生成処理のフローを示すフローチャートである。検索要求者が人材を検索する際の処理は検索要求側のサーバーと検索要求受信側のサーバーで異なる。
先ず、文書の登録を行う。この文章を形態素に分割する（Ｓ１１）。次に、形態素列から名詞句部分を抽出する（Ｓ１２）。文書フィルタＤＢ装置９に登録されている文字列を削除する（Ｓ１３）。紹介文ＤＢ装置４に登録する（Ｓ１４）。
図１９はフロー中に作成される図２のＳｖ１からの検索パケットを示す概略図である。図２０は検索結果メールを示す概略図である。図２１は検索条件入力装置の検索要求画面を示す概略図である。図２２は検索要求フローを説明するフローチャートである。
以下に各サーバーの動作を説明する。検索要求側サーバーの処理は、検索要求者が人材を検索したい場合、人材検索サーバー１（図１）に接続されている検索条件入力装置１０の検索要求画面にて検索条件を入力する。条件が入力され、決定ボタン１１が押されると人材検索サーバー１は検索要求フロー（図２２）に従って処理を行う。
図２２を参照して、検索語を入力し、検索パケットを作成する（Ｓ１５）。検索サーバーリストに登録されているサーバーに対して検索パケットを送信する（Ｓ１６）。検索結果パケットを受信する（Ｓ１７）。検索結果パケットから検索結果を取り出し（Ｓ１８）、受け取った検索結果である検索結果メールを送信する（Ｓ１９）。

図２３は検索要求を人材検索サーバーが受け取った場合の処理フローを示すフローチャートである。図２４は図２のＳｖ２でフロー中に作成される検索パケットを示す概略図である。図２５は図２のＳｖ３でフロー中に作成される検索パケットを示す概略図である。
検索要求を人材検索サーバーが受け取った場合に、図２３のフローに従って処理される。図２３において、検索パケットの受信後、検索語から文書ＤＢ装置２を検索する（Ｓ２０）。検索にヒットした文書の登録ユーザーＩＤを取得する（Ｓ２１）。
次に、検索ユーザーＩＤを基点として文書の登録ユーザーＩＤまでの知人パスを取得する（Ｓ２２）。知人パスに含まれる対象となる人物の紹介文を取得する（Ｓ２３）。検索結果パケットを作成し（Ｓ２４）、これを発信サーバーに送信する（Ｓ２５）。
ここで、Ｓｖ１に所属している利用者“ｙａｍａｄａ”が“Ｊａｖａ（登録商標）”（ジャバ）に詳しい人材を探している場合を想定して動作を説明する。先ず、検索条件入力装置１０（図１）に検索条件を入力し（図２１）、実行する。人材検索サーバー１は検索要求パケット（図１９）を作成し、Ｓｖ２及びＳｖ３（図２）に送信する。
検索要求パケットを受け取ったＳｖ２の人材検索サーバーは検索語である“Ｊａｖａ（登録商標）”で文書ＤＢ（図１０）を検索する。この検索結果は見つからない。よって、Ｓｖ２である人材検索サーバー１ａは検索結果が０件であることを意味するｎｏｎｅを検索結果として検索結果パケット（図２４）を作成し、Ｓｖ１（図２）に送信する。
一方、検索要求パケット（図１９）を受け取ったＳｖ３も同様に検索後“Ｊａｖａ（登録商標）”で文書ＤＢ（図１１）を検索する。この検索結果として、ユーザーＩＤ、“ｕｃｈｉｄａ”と“ｓａｔｏｈ”が発見する。
次に、“ｕｃｈｉｄａ”及び“ｓａｔｏｈ”を基点として、Ｓｖ１の“ｙａｍａｄａ”までのルートを探索する。この探索は重み無しの無効グラフとして既存の手法で求まる。

図２６は知人パスの第１のルートを示す概略図である。図２７は知人パスの第２のルートを示す概略図である。探索の結果、以下のルートが求まる。これを知人パスとする。これらは全てユーザーＩＤで表現されている。
・Ｓｖ１：ｙａｍａｄａ−Ｓｖ３：ｋｉｍｕｒａ−Ｓｖ３：ｕｃｈｉｄａ−Ｓｖ：ｓａｔｏｈ（図２６）
・Ｓｖ１：ｙａｍａｄａ−Ｓｖ３：ｋｉｍｕｒａ−Ｓｖ３：ｕｃｈｉｄａ（図２７）
次に、知人パスで見つかった“Ｊａｖａ（登録商標）”のスキルを有する４人物のＩＤを基に紹介文ＤＢ装置４（図１）より対象人物の紹介文を求める。これからＳｖ３の検索サーバーは検索結果パケット（図２５）を作成し、Ｓｖ１に送信する。
検索結果パケット（図２５）の内容は、発信元である発信サーバー名、検索元ユーザーＩＤ、及び検索結果である知人パス、対象となる人材の紹介文が格納されている。
Ｓｖ２及びＳｖ３からの検索結果パケットを受け取ったＳｖ１の検索サーバーは検索結果パケットより知人パスと人材の紹介文を取り出し、メール送信装置５（図１）を通じて検索要求者にメール（図２０）を送信する。
上述した第１の実施形態によれば、名刺情報、文書情報、紹介文を利用することで、離れた組織内の特定のスキルを有する人材を検索することができ、データ変換装置７により、名刺情報と別の人材情報ＤＢとの情報をやり取りすることできる。
また、文書情報から紹介文を自動で生成することができ、検索結果をメールで送信することにより、検索結果をメールで知ることができる。さらに、文書フィルタ装置９により、紹介文の中から自動で予め登録した文字列を削除することができる。

図２８は本発明による人材検索システムのシステム構成の第２の実施形態を示す概略図である。図２８の人材検索システムＡにおいて、人材検索サーバー装置１は利用者から検索要求を受け、また、検索結果を出力するためのサービスの本システムの基幹となる構成要素である。
文書ＤＢ装置２は利用者の作成した文書を登録するためのデータベースである。名刺管理ＤＢ装置３は利用者の名刺情報を登録するためのデータベースである。紹介文ＤＢ装置４は利用者のスキル（技能）や業務内容に関する文を登録するためのデータベースである。
確認メール送信装置５ａは検索結果を検索要求者に送信するための装置である。人脈ＤＢ装置６は利用者の知人を登録するためのデータベースである。データ交換装置７は人脈ＤＢ装置６に格納されているデータを他の形式のＤＢのデータと交換するための装置である。
検索結果出力装置８は検索結果を表示するための装置である。文書フィルタＤＢ装置９は紹介文ＤＢ装置４に登録する文書にフィルタを掛けるための文字列が登録されているデータベースである。検索条件入力装置１０は人材検索の条件を入力する装置である。
通信装置１４は人材検索サーバー１、１ａ、１ｂそれぞれと互いに通信するのに使用する。人材検索サーバー１ａ、１ｂは人材検索サーバー１と同じ構成になっており、説明は省略する。
また、以下の説明では、上記と同様に、Ｓｖ１、Ｓｖ２及びＳｖ３を使用し、これらは、図２８の人材検索サーバー１をＳｖ１、人材検索サーバー１ａをＳｖ２、そして人材検索サーバー１ｂをＳｖ３としている。
人名マスク装置１２はメール中に含まれる人名をマスクするための装置でありそして知人パスＤＢ装置１３は検索された知人パスを保存するためのデータベースである。知人関係、処理全体の流れ、及びＤＢに格納されているデータも第１の実施形態で示した通りである。

以下に検索サーバーの動作を説明する。検索要求者が人材を検索する際の処理は検索要求側のサーバーと検索用要求受信側のサーバーで異なる。各サーバーの動作は以下の通りである。
検索要求側サーバーの処理について、検索要求者が人材を検索したい場合、人材検索サーバー１（図１）に接続されている検索要求画面（検索条件入力装置）１０にて検索条件を入力する（図２１）。
図２９は検索要求フローを示すフローチャートである。上記で条件が入力され、決定ボタン１１が押されると検索サーバー１は検索要求フロー（図２９）に従って処理を行う。
図２９の検索要求フローでは、先ず、検索語を入力し（Ｓ２６）、検索パケットを作成し（Ｓ２７）、次いで、検索サーバーリストに登録されているサーバーに対して検索パケットを送信する（Ｓ２８）。
図３０は検索要求フロー中で作成される検索パケットを示す図である。図３１はＳｖ２の検索サーバーによる検索パケットを示す図である。上記ステップ（Ｓ２８）で作成される検索パケットは図３０の検索パケットである。ここでは検索要求サーバーは検索要求パケットを送信した後、一度処理は終了する。
図２９において、サーバーが検索要求パケットを受信する（Ｓ２８−１）と、検索要求パケットから検索結果を取り出し（Ｓ２８−２）、そして検索結果を問い合わせユーザーにメールで送信する（Ｓ２８−３）。

図３２は検索結果を送信する検索結果メールを示す図である。図３３は検索結果を送信する検索結果メールを示す図である。検索結果パケット（後述）を受け取った際に、検索結果パケット毎に検索要求者に対して検索結果のメールを送信する。図３２はＳｖ２からの検索結果なしを示している。図３３はＳｖ３からの検索結果を示している。
図３４は検索要求パケットを受信したサーバーのフローを説明するフローチャートである。図３５は検索要求パケットを受信したサーバーのフローを説明するフローチャートである。

次に、検索要求受信側サーバーの処理について説明する。検索要求パケットを受信したサーバーはフローチャート（図３４）及び（図３５）に従って処理を行う。図３４のフローチャートでは、検索パケットの受信後、検索語より文書ＤＢ装置２を検索し（Ｓ２９）、検索にヒットした文書の登録ユーザーのユーザーＩＤを求める（Ｓ３０）。
次に、検索ユーザーＩＤを基点として文書の登録ユーザーのユーザーＩＤまでの知人パスを得る（Ｓ３１）。検索要求を受信した人材検索サーバーは、自サーバー内のユーザーに対して知人パスの先頭から紹介確認のための紹介確認メールを送信する（Ｓ３２）。
図３５のフローチャートにおいて、紹介承認メールを受け取ったユーザーはそれに対して返答をし、知人パスの全員に了承を貰っているかどうか判断し（Ｓ３３）、了承を貰っていないならば、その返答を受け取ったサーバーは知人パスの次に登場するユーザー対してさらに確認メールを出し（Ｓ３４）、誰かが断るか、知人パスの全てのユーザーが承認するまで続ける。
上述の人材検索サーバーは知人パスの全てのユーザーが承認したルートに対して検索結果パケットを作成し（Ｓ３５）、検索結果パケットを検索要求元サーバー（発信サーバー）に送信する（Ｓ３６）。
ここで、Ｓｖ１（図２）に所属している利用者“ｙａｍａｄａ”が“Ｊａｖａ（登録商標）”に詳しい人材を探している場合を想定して動作を説明する。先ず、検索条件入力装置１０（図２８）に検索条件を入力（図２１）し、実行する。

人材検索サーバー１は検索要求パケット（図３１）を作成し、Ｓｖ２及びＳｖ３（図２）に送信する。検索要求パケットを受け取ったＳｖ２の人材検索サーバーは検索語である“Ｊａｖａ（登録商標）”で文書ＤＢ装置２を検索する。
この検索結果は見つからない。よってＳｖ２の人材検索サーバーは検索結果が０件であることを意味するｎｏｎｅを検索結果として検索結果パケット（図３１）を作成し、Ｓｖ１に送信する。一方、検索要求パケット（図３１）を受け取ったＳｖ３も同様に検索後“Ｊａｖａ（登録商標）”で文書ＤＢ装置２を検索する。
この検索結果としてユーザーＩＤ、“ｕｃｈｉｄａ”と“ｓａｔｏｈ”を発見する。次に、“ｕｃｈｉｄａ”及び“ｓａｔｏｈ”を基点としてＳｖ１の“ｙａｍａｄａ”までのルートを探索する。
この検索は重み無しの無効グラフとして既存の手法で求まる。検索の結果、以下のルートが求まる。これを知人パスとする。このとき、人材検索サーバーは知人パスに自サーバー内で固有のＩＤを割り振り、知人パスＤＢ装置１３に登録する。

図３６は知人パスのルートを説明する図である。図３７は知人パスの他のルートを説明する図である。
・Ｓｖ１：ｙａｍａｄａ−Ｓｖ３：ｋｉｍｕｒａ−Ｓｖ３：ｕｃｈｉｄａ−Ｓｖ３：ｓａｔｏｈ（図３６）
・Ｓｖ１：ｙａｍａｄａ−Ｓｖ３：ｋｉｍｕｒａ−Ｓｖ３：ｕｃｈｉｄａ（図３７）（これらは全てユーザーＩＤで表現されている）
図３８は紹介の良否を確認するための確認メールを示す図である。次に、図３６のルートに関して説明する。サーバーは自サーバーユーザーに紹介してよいか確認を取るため、各ユーザーに対して確認のメールを送信する。送信するメールは図３８の確認メールである。
図３９は図３８の確認メールに対する了承メールを示す図である。次に図３８の確認メールを受け取ったＳｖ３サーバー（図２）の“ｋｉｍｕｒａ”は内容を確認し、了承を意味するメール（図３９）を返信する。
図４０は図３８の確認メールに対するＳｖ３サーバーの他のユーザーへの了承メールを示す図である。図４１は図３８の確認メールに対するＳｖ３サーバーの他のユーザーへの了承メールを示す図である。図４２は図３８の確認メールに対するＳｖ３サーバーの他のユーザーへの了承メールを示す図である。図４３は図３８の確認メールに対するＳｖ３サーバーの他のユーザーへの了承メールを示す図である。
次に、図３９の了承メールを受け取った人材検索サーバーは知人パス１３（図２８）の次のユーザー“ｕｃｈｉｄａ”に同様のメール（図４０）を送信する。このように問い合わせと返答が図３８→図３９→図４０→図４１→図４２→図４３のように行なわれる。

図４４は検索結果パケットを示す図である。図４５はＳｖ３の知人パスを示す図である。サーバーは最終確認まで取れたので検索の対象となった“ｓａｔｏｈ”と“ｕｃｈｉｄａ”に関して紹介文ＤＢ装置４より照会文を取得し、検索結果パケット（図４４）を作成し、検索要求元の人材検索サーバーＳｖ１に送信する。
Ｓｖ２及びＳｖ３からの検索結果パケットを受け取ったＳｖ１の人材検索サーバー１は検索結果パケットより知人パス（図４５）と人材の紹介文を取り出し、メール送信装置５（図１）を通じて検索要求者にメール（図３２）及び（図３３）を送信する。
上述したように、知人パスＤＢ装置１３により、検索された知人パスを保存し、後で再利用することができる。また、確認メール送信装置５ａにより、自動で知人パスの人材に確認メールを送信することができる。
上述した人材検索システムに関して、検索要求パケットを受け取った人材検索サーバーの処理で紹介の了承を得るためのメールを出す処理において、メール送出前に、紹介ルートの人名に対して人名マスク装置１２（図２８）が以下のフローに従ってマスクする。

図４６は紹介ルートの人名に対する人名マスク装置によるマスクのフローを説明するフローチャートである。図４６に関連して、図３６の知人パスに関して説明する。
メール文字列中に含まれる知人パスＩＤは、“知人パスＩＤ”と書かれている文字列の後ろに書かれていることから、“０１２３ａｂｃ”であることが判る（Ｓ３７）。次に、知人パスＤＢ装置１３（図２８）で“０１２３ａｂｃ”を引くと、知人パス（図３６）が得られる（Ｓ３８）。
次に、送信すべき相手であるＳｖ３（図２）の“ｋｉｍｕｒａ”の知人を名刺ＤＢ装置３（図２８）から取得する（Ｓ３９）。“ｋｉｍｕｒａ”の知人は名刺ＤＢ装置３（図２８）からＳｖ３：“ｕｃｈｉｄａ”，Ｓｖ１：“ｙａｍａｄａ”，Ｓｖ２：“ｙａｍａｎｅ”である。これらを用いて知人パス（図３６）に含まれる知人以外のＩＤの“ｓａｔｏｈ”を“＊＊＊＊”に置き換える（Ｓ４０）（図２６）。
図４７は送信相手に送信する確認メールを示す図である。図４８は送信相手に送信する確認メールを示す図である。同様にして、“ｕｃｈｉｄａ”，“ｓａｔｏｈ”に出すメールの内容も図４７、図４８のように置き換える。
紹介文ＤＢ装置４に登録される文の内容から特定の文字列を削除または別の文字列に置き換えるための文書フィルタＤＢ装置９が接続されるので、人名マスク装置１２によって、確認メール中の送信相手に関係ない人材の名前をマスクする、すなわち、プライバシーを守るために、承認を得るためのメール中に含まれる人名に対してマスクをかけることができる。

本発明による人材検索システムのシステム構成の第１の実施形態を示す概略図。 知人関係を説明する概略図。 紹介文データ特性処理の流れを示すフローチャート。 名刺データベース更新処理の流れを示すフローチャート。 問い合わせ処理の流れを示すフローチャート。 図２のＳｖ１の名刺及び人脈データベースに格納されているデータを示す概略図。 図２のＳｖ２の名刺及び人脈データベースに格納されているデータを示す概略図。 図２のＳｖ３の名刺及び人脈データベースに格納されているデータを示す概略図。 図２のＳｖ１の文書データベースに格納されているデータを示す概略図。 図２のＳｖ２の文書データベースに格納されているデータを示す概略図。 図２のＳｖ３の文書データベースに格納されているデータを示す概略図。 図２のＳｖ１の紹介文データベースに格納されているデータを示す概略図。 図２のＳｖ２の紹介文データベースに格納されているデータを示す概略図。 図２のＳｖ３の紹介文データベースに格納されているデータを示す概略図。 図２のＳｖ１の文書フィルタデータベースに格納されているデータを示す概略図。 図２のＳｖ２の文書フィルタデータベースに格納されているデータを示す概略図。 図２のＳｖ３の文書フィルタデータベースに格納されているデータを示す概略図。 文書ＤＢから自動で生成されるデータの生成処理のフローを示すフローチャート。 フロー中に作成される図２のＳｖ１からの検索パケットを示す概略図。 検索結果メールを示す概略図。 検索条件入力装置の検索要求画面を示す概略図。 検索要求フローを説明するフローチャート。 検索要求を検索サーバーが受け取った場合の処理フローを示すフローチャート。 図２のＳｖ２でフロー中に作成される検索パケットを示す概略図。 図２のＳｖ３でフロー中に作成される検索パケットを示す概略図。 知人パスの第１のルートを示す概略図。 知人パスの第２のルートを示す概略図。 本発明による人材検索システムのシステム構成の第２の実施形態を示す概略図。 検索要求フローを示すフローチャート。 検索要求フロー中で作成される検索パケットを示す図。 Ｓｖ２の検索サーバーによる検索パケットを示す図。 検索結果を送信する検索結果メールを示す図。 検索結果を送信する検索結果メールを示す図。 検索要求パケットを受信したサーバーのフローを説明するフローチャート。 検索要求パケットを受信したサーバーのフローを説明するフローチャート。 知人パスのルートを説明する図。 知人パスの他のルートを説明する図。 紹介の良否を確認するための確認メールを示す図。 図３８の確認メールに対する了承メールを示す図。 図３８の確認メールに対するＳｖ３サーバーの他のユーザーへの了承メールを示す図。 図３８の確認メールに対するＳｖ３サーバーの他のユーザーへの了承メールを示す図。 図３８の確認メールに対するＳｖ３サーバーの他のユーザーへの了承メールを示す図。 図３８の確認メールに対するＳｖ３サーバーの他のユーザーへの了承メールを示す図。 検索結果パケットを示す図。 Ｓｖ３の知人パスを示す図。 紹介ルートの人名に対する人名マスク装置によるマスクのフローを説明するフローチャート。 送信相手に送信する確認メールを示す図。 送信相手に送信する確認メールを示す図。

符号の説明

１ 人材検索サーバー装置（Ｓｖ１）、１ａ 人材検索サーバー装置（Ｓｖ２）、１ｂ 人材検索サーバー装置（Ｓｖ３）、２ 文書ＤＢ装置、３ 名刺管理ＤＢ装置、４ 紹介文ＤＢ装置、５ メール送信装置、５ａ 確認メール送信装置、６ 人脈ＤＢ装置、７ データ交換装置、８ 検索結果出力装置、９ 文書フィルタＤＢ装置、１０ 検索条件入力装置、１２ 人名マスク装置、１３ 知人パスＤＢ装置、１４ 通信装置

Claims (8)

1. 或る特定のスキルを持つ人材を検索するサービスを行う人材検索システムにおいて、検索処理を実行する人材検索サーバー装置と、該人材検索サーバー装置に接続され、利用者が書いた文書を登録する文書データベース装置と、前記人材検索サーバー装置に接続され、利用者の持っている他人の名刺情報が登録される名刺管理データベース装置と、前記人材検索サーバー装置に接続され、利用者のスキルを紹介した文を登録する紹介文データベース装置と、ネットワークを介して通信可能に構成された通信装置と、を備えることを特徴とする人材検索システム。
2. 前記名刺管理データベース装置は、登録されている人物情報を他のデータベース装置の情報形式に変換するためのデータ交換装置が接続されることを特徴とする請求項１記載の人材検索システム。
3. 前記紹介文データベース装置に登録される文書は、前記文書データベース装置に登録されている文書から自動的に生成されることを特徴とする請求項１記載の人材検索システム。
4. 前記人材検索サーバー装置は、検索結果を生成した後、メールにて検索要求者に検索結果を通知することを特徴とする請求項１記載の人材検索システム。
5. 前記人材検索サーバー装置には、検索結果対象となる人物と検索要求者間の知人を知人パスとして保存する知人パスデータベース装置が接続されることを特徴とする請求項１記載の人材検索システム。
6. 検索要求者から要求された検索結果の前記知人パスの人物に対して、紹介の承認を確認するための確認メールを送信する確認メール送信装置が接続されることを特徴とする請求項５記載の人材検索システム。
7. 前記確認メール送信装置には、メール中の、送信者の知人でない人物の人名を別の文字で置き換える人名マスク装置が接続されることを特徴とする請求項５記載の人材検索システム。
8. 前記紹介文データベース装置に登録される文の内容から特定の文字列を削除または別の文字列に置き換えるための文書フィルタ装置が接続されることを特徴とする請求項５記載の人材検索システム。
   

Images