特許第6508842号(P6508842)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 藤井 正博の特許一覧

特許6508842情報追跡装置、情報追跡方法および情報追跡プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6508842
(24)【登録日】2019年4月12日
(45)【発行日】2019年5月8日
(54)【発明の名称】情報追跡装置、情報追跡方法および情報追跡プログラム
(51)【国際特許分類】
   G06Q 50/10 20120101AFI20190422BHJP
【FI】
   G06Q50/10
【請求項の数】7
【全頁数】55
(21)【出願番号】特願2017-29039(P2017-29039)
(22)【出願日】2017年2月20日
(65)【公開番号】特開2018-136615(P2018-136615A)
(43)【公開日】2018年8月30日
【審査請求日】2017年10月17日
(73)【特許権者】
【識別番号】517058819
【氏名又は名称】藤井 正博
(74)【代理人】
【識別番号】100181087
【弁理士】
【氏名又は名称】藤松 知久
(72)【発明者】
【氏名】藤井 正博
【審査官】 上田 威
(56)【参考文献】
【文献】 特開2002−007409(JP,A)
【文献】 特開平06−223086(JP,A)
【文献】 特開2013−097432(JP,A)
【文献】 特開2003−122911(JP,A)
【文献】 特開2001−306766(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 − 99/00
(57)【特許請求の範囲】
【請求項1】
通信ネットワークを介して、複数の登録会員に関する登録情報を登録及び検索可能な情報追跡データベースに当該登録会員又は非登録会員からアクセス可能であり、各々の前記登録会員が予め定めた媒体に付与される前記登録会員を特定可能な情報追跡識別符号を情報追跡データベースに登録及び検索可能である情報追跡装置であって、
前記情報追跡識別符号ごとに前記登録会員に関する前記登録情報を紐付けて格納し、前記登録会員に関する前記登録情報に応じて、他の登録会員又は非登録会員が操作する開示請求者端末からの前記登録情報についての開示請求に対して開示者の想定内に属する開示許容される想定内開示請求者への開示の有無を判断するための設問及び当該設問に対する正答と、前記設問の回答に対する開示の有無の前記想定内開示請求者であると判断するための採点判断基準と、当該開示有りの場合の前記登録情報についての前記想定内開示請求者に対する開示制限レベルに応じた開示範囲が予め定められた開示情報とを、前記登録会員の前記情報追跡識別符号又は予め登録されたメールアドレスごとに紐付けて格納する前記情報追跡データベース
前記登録会員が操作する登録会員端末又は前記開示請求者端末である利用者端末から前記登録情報に関する入力又は検索の入力データを受け付け、前記利用者端末へ前記登録情報に関する当該入力又は検索の結果の出力データを出力する情報検索入出力手段と、
前記開示請求に応じて、前記情報追跡データベースから前記開示請求に対応する前記設問を抽出し、当該抽出した前記設問を前記開示請求者端末に提示し、前記開示請求者端末から応答された前記設問の回答を前記採点判断基準に基づいて前記開示情報の提供の有無を決定する設問提示認証手段と、
前記利用者端末へ、少なくとも前記開示情報に関する要求又は応答のメッセージを転送するメッセージ転送手段と、を備え、
前記情報追跡データベースには、前記登録会員ごとに、前記登録会員が利用した又は利用している複数のメールアドレスの使用又は不使用の状態を登録可能であり、
前記情報検索入出力手段は、前記登録会員に対する前記開示請求に対して、
前記情報追跡識別符号を検索指定された場合には、前記情報追跡データベースから当該検索指定された前記情報追跡識別符号を検索した前記検索の結果の出力データを前記開示請求者端末へ出力し、
または、前記メールアドレスが検索指定された際に、当該検索指定された前記メールアドレスが前記予め登録されたメールアドレスのいずれかに一致した場合には前記情報追跡データベースから抽出した当該検索指定された前記メールアドレスの使用又は不使用の状態についての前記検索の結果の出力データを前記開示請求者端末へ出力し、当該検索指定された前記メールアドレスが前記予め登録されたメールアドレスのいずれにも一致しない場合には検索対象が存在しない旨の前記検索の結果の出力データを前記開示請求者端末へ出力し、
前記設問提示認証手段は、当該決定した前記開示情報の提供の有無に応じて前記開示情報を前記情報追跡データベースから抽出し又は抽出せず、前記開示情報を抽出した場合には、前記メッセージ転送手段が、当該抽出した前記開示情報に関する前記メッセージを前記開示請求者端末へ前記通信ネットワークを介して転送する
ことを特徴とする情報追跡装置。
【請求項2】
前記設問提示認証手段は、前記開示請求者端末からの前記開示請求の際に、前記情報検索入出力手段を介して指定された前記情報追跡識別符号又は前記メールアドレスが前記情報追跡データベースに格納された前記登録会員の前記情報追跡識別符号又は前記予め登録されたメールアドレスに一致した場合に、一致した前記登録会員の前記情報追跡識別符号又は前記予め登録されたメールアドレスに対応する前記設問を前記情報追跡データベースから抽出し、当該抽出した設問を前記開示請求者端末へ提示する
ことを特徴とする請求項1に記載の情報追跡装置。
【請求項3】
前記情報追跡データベースは、前記登録会員に紐付けされた前記情報追跡識別符号と関連付けが前記複数の登録会員のいずれかの登録会員により許可された当該登録会員に紐付けされた他の前記情報追跡識別符号を前記登録会員の前記開示情報に関連付けした情報として登録して格納することができ、
前記情報検索入出力手段は、前記登録会員に紐付けされた前記情報追跡識別符号を提示する場合に、前記登録会員に紐付けされた前記情報追跡識別符号と前記登録会員の前記開示情報に関連付けした情報として登録された当該登録会員に紐付けされた他の前記情報追跡識別符号と共に前記利用者端末へ提示可能とする
ことを特徴とする請求項1又は請求項2に記載の情報追跡装置。
【請求項4】
前記登録会員端末から前記入力データのうちの前記設問及び前記正答の作成データを受けて、当該作成データに基づいて前記登録会員の前記情報追跡識別符号又は前記予め登録されたメールアドレスのいずれかに紐付けて前記情報追跡データベースに登録可能とする設問回答作成手段をさらに備える
ことを特徴とする請求項1乃至請求項3のいずれか一項に記載の情報追跡装置。
【請求項5】
前記開示請求者端末により前記設問回答作成手段を用いて前記開示請求対象の前記登録会員宛に設定した開示請求者設問及び正答と、前記開示請求者設問の回答に対する開示の有無の第2の採点判断基準とを作成可能であり、
前記登録会員端末からの前記開示請求者設問の回答の採点結果が前記第2の採点判断基準に基づいて開示有りとした場合に、前記メッセージ転送手段が、前記開示請求者端末により作成された開示請求者の開示する情報を通知するメッセージを前記登録会員端末へ転送し、
前記第2の採点判断基準に基づいて開示無しとした場合に、前記メッセージ転送手段が、前記開示請求者の開示する情報を開示しない通知するメッセージを前記登録会員端末へ転送する
ことを特徴とする請求項4に記載の情報追跡装置。
【請求項6】
通信ネットワークを介して、複数の登録会員に関する登録情報を登録及び検索可能な情報追跡データベースに当該登録会員又は非登録会員からアクセス可能であり、各々の前記登録会員が予め定めた媒体に付与される前記登録会員を特定可能な情報追跡識別符号を情報追跡データベースに登録及び検索可能であり、
前記情報追跡識別符号ごとに前記登録会員に関する前記登録情報を紐付けて格納し、前記登録会員に関する前記登録情報に応じて、他の登録会員又は非登録会員が操作する開示請求者端末からの前記登録情報についての開示請求に対して開示者の想定内に属する開示許容される想定内開示請求者への開示の有無を判断するための設問及び当該設問に対する正答と、前記設問の回答に対する開示の有無の前記想定内開示請求者であると判断するための採点判断基準と、当該開示有りの場合の前記登録情報についての前記想定内開示請求者に対する開示制限レベルに応じた開示範囲が予め定められた開示情報とを、前記登録会員の前記情報追跡識別符号又は予め登録されたメールアドレスごとに紐付けて格納する前記情報追跡データベースにアクセス可能な情報追跡装置に用いられる情報追跡方法であって、
当該情報追跡装置が以下のステップ、すなわち、
前記登録会員が操作する登録会員端末又は前記開示請求者端末である利用者端末から前記登録情報に関する入力又は検索の入力データを受け付けるステップと、
前記利用者端末へ前記登録情報に関する当該入力又は検索の結果の出力データを出力するステップと、
前記開示請求に応じて前記情報追跡データベースから前記開示請求に対応する前記設問を抽出し、当該抽出した前記設問を前記開示請求者端末に提示するステップと、
前記開示請求者端末から応答された前記設問の回答を前記採点判断基準に基づいて前記開示情報の提供の有無を決定するステップと、
前記利用者端末へ少なくとも前記開示情報に関する要求又は応答のメッセージを転送するステップと、を含み、
前記情報追跡データベースには、前記登録会員ごとに、前記登録会員が利用した又は利用している複数のメールアドレスの使用又は不使用の状態を登録可能であり、
前記登録情報に関する当該入力又は検索の結果の出力データを出力するステップにおいて、前記登録会員に対する前記開示請求に対して、
前記情報追跡識別符号を検索指定された場合には、前記情報追跡データベースから当該検索指定された前記情報追跡識別符号を検索した前記検索の結果の出力データを前記開示請求者端末へ出力するステップを、
または、前記メールアドレスが検索指定された際に、当該検索指定された前記メールアドレスが前記予め登録されたメールアドレスのいずれかに一致した場合には前記情報追跡データベースから抽出した当該検索指定された前記メールアドレスの使用又は不使用の状態についての前記検索の結果の出力データを前記開示請求者端末へ出力するステップを、当該検索指定された前記メールアドレスが前記予め登録されたメールアドレスのいずれにも一致しない場合には検索対象が存在しない旨の前記検索の結果の出力データを前記開示請求者端末へ出力するステップを実行し、
前記開示情報の提供の有無を決定するステップにおいて、当該決定した前記開示情報の提供の有無に応じて前記開示情報を前記情報追跡データベースから抽出し又は抽出せず、前記開示情報を抽出した場合には、当該抽出した前記開示情報に関する前記メッセージを前記開示請求者端末へ前記通信ネットワークを介して転送するステップを実行する
ことを特徴とする情報追跡方法。
【請求項7】
通信ネットワークを介して、複数の登録会員に関する登録情報を登録及び検索可能な情報追跡データベースに当該登録会員又は非登録会員からアクセス可能であり、各々の前記登録会員が予め定めた媒体に付与される前記登録会員を特定可能な情報追跡識別符号を情報追跡データベースに登録及び検索可能である情報追跡装置であって、
前記情報追跡識別符号ごとに前記登録会員に関する前記登録情報を紐付けて格納し、前記登録会員に関する前記登録情報に応じて、他の登録会員又は非登録会員が操作する開示請求者端末からの前記登録情報についての開示請求に対して開示者の想定内に属する開示許容される想定内開示請求者への開示の有無を判断するための設問及び当該設問に対する正答と、前記設問の回答に対する開示の有無の前記想定内開示請求者であると判断するための採点判断基準と、当該開示有りの場合の前記登録情報についての前記想定内開示請求者に対する開示制限レベルに応じた開示範囲が予め定められた開示情報とを、前記登録会員の前記情報追跡識別符号又は予め登録されたメールアドレスごとに紐付けて格納する前記情報追跡データベース
前記登録会員が操作する登録会員端末又は前記開示請求者端末である利用者端末から前記登録情報に関する入力又は検索の入力データを受け付け、前記利用者端末へ前記登録情報に関する当該入力又は検索の結果の出力データを出力する情報検索入出力手段と、
前記開示請求に応じて、前記情報追跡データベースから前記開示請求に対応する前記設問を抽出し、当該抽出した前記設問を前記開示請求者端末に提示し、前記開示請求者端末から応答された前記設問の回答を前記採点判断基準に基づいて前記開示情報の提供の有無を決定する設問提示認証手段と、
前記利用者端末へ、少なくとも前記開示情報に関する要求又は応答のメッセージを転送するメッセージ転送手段とを備える情報追跡装置として、
前記情報追跡データベースには、前記登録会員ごとに、前記登録会員が利用した又は利用している複数のメールアドレスの使用又は不使用の状態を登録可能であり、
前記情報検索入出力手段は、前記登録会員に対する前記開示請求に対して、
前記情報追跡識別符号を検索指定された場合には、前記情報追跡データベースから当該検索指定された前記情報追跡識別符号を検索した前記検索の結果の出力データを前記開示請求者端末へ出力し、
または、前記メールアドレスが検索指定された際に、当該検索指定された前記メールアドレスが前記予め登録されたメールアドレスのいずれかに一致した場合には前記情報追跡データベースから抽出した当該検索指定された前記メールアドレスの使用又は不使用の状態についての前記検索の結果の出力データを前記開示請求者端末へ出力し、当該検索指定された前記メールアドレスが前記予め登録されたメールアドレスのいずれにも一致しない場合には検索対象が存在しない旨の前記検索の結果の出力データを前記開示請求者端末へ出力し、
さらに、前記設問提示認証手段が、当該決定した前記開示情報の提供の有無に応じて前記開示情報を前記情報追跡データベースから抽出し又は抽出せず、前記開示情報を抽出した場合には、前記メッセージ転送手段が、当該抽出した前記開示情報に関する前記メッセージを前記開示請求者端末へ前記通信ネットワークを介して転送するように、
コンピュータを機能させるための情報追跡プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報を開示すべき相手を限定した上で当該情報の開示を可能とする情報追跡装置、情報追跡方法および情報追跡プログラムに関する。
【背景技術】
【0002】
連絡先に関する情報は、例えば名刺やショップカード、パンフレット、書簡や電子メール、各種届出のほか、携行可能な所有物などにも記録されるが、これらの情報鮮度は時の経過ともに劣化する。情報の記載者は、本来、記載事実に変更が生じる機会ごとにこれらの情報を更新すべきではあるが、大量に配布された紙片やインターネットを介して送信されたデータなど、そのすべての情報を更新するというのは現実的ではない。
【0003】
よって、従来のシステム等では更新されるべき情報が更新されることなく時間が流れ、ついには最新情報を追跡できなくなるという問題がある。これにより事業者と顧客の関係は絶たれ、知人間の連絡は不能となり、拾得物の返還先も不明となる。この問題を解決するには、過去の時点で記録された情報をもとに最新の情報を抽出・追跡可能とする仕組みが必要となる。
【0004】
なお、名刺フォルダにおいて、名刺情報を管理するサービスに加入している会員が名刺交換をする場合、予め相手に渡す予定の、表記情報と共に一意に識別番号と機密情報を含む第1の名刺を収納してあるポケットを各頁に設定し、各頁のポケット内に収納されている該第1の名刺の識別番号が記されているインデックスが該ポケットに対応して設置されていること等が知られている(例えば、特許文献1を参照)。
【0005】
また、名刺情報提供システムにおいて、名刺型記録媒体(デジタル名刺)を名刺として用いて名刺交換を行う者を対象として構築されたコンピュータシステムであり、最新の名刺情報を一元的に管理している名刺情報管理サーバ、名刺交換者が利用する利用者端末、および名刺情報管理サーバと利用者端末を通信可能とするインターネット網などの通信ネットワークを備え、名刺情報管理サーバは、利用者端末に備えられたデジタル名刺に最新の名刺情報を提供すること等が知られている(例えば、特許文献2を参照)。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開2005−7890号公報
【特許文献2】特開2004−86620号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
例えば、過去に名刺交換した取引先、業務依頼した業者等の相手が、その後、事業所の所在移転、退職等により、過去に受け取った名刺に記載の住所、電話番号、電子メールアドレスのいずれもがその本人とは関係なくなった場合に、他方の側から連絡をとる手段がなくなる。また、携帯電話等の電話番号を知っていた場合でも、こちらの電話番号が相手方で登録されていない電話等の発信である場合に、営業・迷惑電話等を警戒して相手が電話に出ないケースも多々ある。
【0008】
そして、過去に渡した名刺等に記載の住所、電話番号、電子メールアドレスのいずれもが変ってしまう側が、その変更連絡先等をある程度の多くの人数へ通知することは難しく、実際にはその時間の経過と共に過去の人脈の多くが途切れたものとなってしまう。
【0009】
このような場合には、例えば、インターネット上に情報を残しておき、これを一般の検索エンジンで探し当てるような手段も考えられるが、これだけでは発見した情報の信憑性を確かめることができないばかりか、公開すべき相手を限定できないために、個人情報が不特定多数に漏えいする危険性を孕む。一方、ウェブサイトURLを名刺に印刷しておき、ウェブサイトURLを有するウェブサイトに更新情報を記載しておくという手段等も考えられる。
【0010】
しかし、これも検索エンジンで探し当てる場合と同様に、ウェブサイトURLが不特定多数に漏えいしてしまうことにより個人情報も漏えいすることとなり得るうえ、インターネットドメイン名の変更に伴うURLの変化にも対応することができない。
【0011】
また、通信ネットワークを介して情報入力者Aと特定の閲覧者Bとを結び、情報の更新をタイムリーに反映させる仕組みも散見されるが、情報入力者Aと特定の閲覧者Bとが同一システム上のユーザー(会員)でない場合は情報の閲覧自体が不能である。つまり、これは情報入力者Aが閲覧者Bを開示相手として相当であることを確認するステップが欠けているためであり、このステップが欠如していると、開示を要求するあらゆる人物に対して無差別に情報が開示されてしまうこととなる。よって情報の閲覧を要求する閲覧者Bは、情報入力者Aが更新情報を保管しているサービスのユーザーとなることを余儀なくされる。
【0012】
一方、情報入力者Aと閲覧者Bとが同一システム上のユーザーでないことを許可するシステムでは、閲覧者制限を設けることが難しいために、開示される情報は専ら公知を前提とする法人等事業者や商品・サービス等に関わるものに限定される。つまり、情報入力者Aと閲覧者Bとが同一システム上のユーザーでないことを許容しつつ、個人情報が不特定多数に漏えいすることを防止しながらも、閲覧者Bの情報開示請求を受け入れるには、閲覧者Bが情報入力者Aにとって、情報を開示すべき人物であるか否かを特定する新たなステップが別途必要となる。
【0013】
例えば特許文献1では、名刺情報の更新を目的とした発明であるが、名刺の授与者と受領者が、名刺情報を管理する同一サービスの会員でなければならない。また、両者の特定には、被膜手段で隠蔽された一意の識別番号と機密情報を用いるとされる。しかし、手渡したすべての名刺等に皮膜処理が伴うことは費用的観点からも現実的ではない場合があるうえ、名刺等が紙媒体でなければ皮膜処理も困難である。なにより皮膜処理を解かれた暗証番号が通信ネッワークを介して漏洩した時点で閲覧者制限が機能しなくなるというデメリットがあり、これは逆に個人情報の漏洩を引き起こす可能性がある。
【0014】
また、特許文献2では、名刺情報を一意に定める識別情報を利用して、名刺を渡した相手の端末に記録されている当該名刺情報を更新する発明である。しかしこの場合は、各種端末の仕様に合わせた専用のアプリケーション(ソフトウェア)を開発しなければならず、また名刺を渡した相手も自身の端末にそのアプリケーションをインストールしなければならない煩雑さがある。そもそも手持ちの端末に対応する専用アプリケーションが公開されていなければ、その仕組みを使うこと自体が不可能である。また専用アプリケーションをインストールした端末に知人の名刺情報を保存するという仕様上、他人が所有する端末を借用するという利用方法も利便性に欠ける。
【0015】
すなわち、不特定多数の者が情報追跡を試みるためには、誰にでも簡便に入手・利用できるような装置、システム等を利用できるものであることが望ましい。この点、インターネット上に解放されたウェブシステムであれば、パーソナルコンピュータをはじめ携帯電話・スマートフォン、タブレット端末、ゲーム機などでアクセスできるだけでなく、これらの機器は家庭や学校、オフィス、公共施設など、今日では様々な場所にあふれているため非常に利便性が高いといえる。
【0016】
しかしながら、ウェブシステムを用いる場合に、個人情報を開示するに足る相手を特定することは容易でない。例えば、ソーシャル・ネットワーキング・サービス(SNS)などは連絡先情報が常に更新されるという点において、情報追跡機能が提供可能であると言える。SNSもまた、同一サービスのメンバー間の関係性を基準として情報開示を行う仕組となっており、これら従来の方法では、システム上における非ユーザー(非会員)をも対象とする開示制限を設けることができない。
【0017】
つまり、従来のウェブシステム等の手段を用いながら個人情報の開示を行うには、情報開示者(以下、開示者)と情報の追跡者(以下、開示請求者)が同一システムの登録会員同士であることが前提とされる。これは既知の人物、すなわち「情報開示請求が受理されるべき人物(以下、正規請求者)」を特定する方法として有効ではあるものの、同時に、開示請求者も開示者と同一システムの登録会員とならなければ開示不能であることを意味し、非常に利便性が悪い。
【0018】
これでは情報の開示を求めるために同システムの登録会員として登録するステップを要するのみならず、同システムの登録会員に必要な要件を満たすことができない人物にとっては、情報開示の請求手段さえも絶たれることとなる。この問題を解決するには、システムの非会員に対しても情報検索を許可しつつ、開示者の意に沿わない相手、すなわち「情報開示請求が拒否されるべき人物」に対する情報開示制限を行える仕組みが必要となる。
【0019】
本発明はインターネット上に解放されたウェブシステムを用いて、上記の問題を解決するものである。すなわち過去の時点で記載された各種情報の鮮度が劣化した場合に、更新情報を追跡(検索・抽出)できなくなりうる現状を克服する。また同時に、開示請求者が同一システム上の会員となることを必要とせず、かつ両者間で相互に本人確認を行い、開示者が意図しない人物には情報が開示されないよう開示制限機能を設け、情報漏えいの危険性を最小限に抑える技術が必要とされる。
【0020】
本発明は、名刺等の紙媒体はもとより、電磁的記録を含むあらゆる物体に記された、あるいは音声として記録された「過去の情報」をもとに、更新情報を抽出するソフトウェア技術であると同時に、同一システムのメンバー(会員)間でなくとも、更新情報を開示すべき相手を限定した上で当該情報の開示を可能とする情報追跡技術に関するものである。
【0021】
そこで、本発明が解決しようとする課題は、情報を開示すべき相手を限定した上で当該情報の開示を可能とする情報追跡装置、情報追跡方法および情報追跡プログラムを提供することである。
【課題を解決するための手段】
【0022】
上記課題を解決するために、本発明に係る情報追跡装置は、通信ネットワークを介して、複数の登録会員に関する登録情報を登録及び検索可能な情報追跡データベースに当該登録会員又は非登録会員からアクセス可能であり、各々の前記登録会員が予め定めた媒体に付与される前記登録会員を特定可能な情報追跡識別符号を情報追跡データベースに登録及び検索可能である情報追跡装置である。当該情報追跡装置は、前記情報追跡識別符号ごとに前記登録会員に関する前記登録情報を紐付けて格納し、前記登録会員に関する前記登録情報に応じて、他の登録会員又は非登録会員が操作する開示請求者端末からの前記登録情報についての開示請求に対して開示者の想定内に属する開示許容される想定内開示請求者への開示の有無を判断するための設問及び当該設問に対する正答と、前記設問の回答に対する開示の有無の前記想定内開示請求者であると判断するための採点判断基準と、当該開示有りの場合の前記登録情報についての前記想定内開示請求者に対する開示制限レベルに応じた開示範囲が予め定められた開示情報とを、前記登録会員の前記情報追跡識別符号又は予め登録されたメールアドレスごとに紐付けて格納する前記情報追跡データベースと、前記登録会員が操作する登録会員端末又は前記開示請求者端末である利用者端末から前記登録情報に関する入力又は検索の入力データを受け付け、前記利用者端末へ前記登録情報に関する当該入力又は検索の結果の出力データを出力する情報検索入出力手段と、前記開示請求に応じて、前記情報追跡データベースから前記開示請求に対応する前記設問を抽出し、当該抽出した前記設問を前記開示請求者端末に提示し、前記開示請求者端末から応答された前記設問の回答を前記採点判断基準に基づいて前記開示情報の提供の有無を決定する設問提示認証手段と、前記利用者端末へ、少なくとも前記開示情報に関する要求又は応答のメッセージを転送するメッセージ転送手段と、を備えている。前記情報追跡データベースには、前記登録会員ごとに、前記登録会員が利用した又は利用している複数のメールアドレスの使用又は不使用の状態を登録可能であり、前記情報検索入出力手段は、前記登録会員に対する前記開示請求に対して、前記情報追跡識別符号を検索指定された場合には、前記情報追跡データベースから当該検索指定された前記情報追跡識別符号を検索した前記検索の結果の出力データを前記開示請求者端末へ出力し、または、前記メールアドレスが検索指定された際に、当該検索指定された前記メールアドレスが前記予め登録されたメールアドレスのいずれかに一致した場合には前記情報追跡データベースから抽出した当該検索指定された前記メールアドレスの使用又は不使用の状態についての前記検索の結果の出力データを前記開示請求者端末へ出力し、当該検索指定された前記メールアドレスが前記予め登録されたメールアドレスのいずれにも一致しない場合には検索対象が存在しない旨の前記検索の結果の出力データを前記開示請求者端末へ出力し、前記設問提示認証手段は、当該決定した前記開示情報の提供の有無に応じて前記開示情報を前記情報追跡データベースから抽出し又は抽出せず、前記開示情報を抽出した場合には、前記メッセージ転送手段が、当該抽出した前記開示情報に関する前記メッセージを前記開示請求者端末へ前記通信ネットワークを介して転送することを特徴とする。
【発明の効果】
【0023】
本発明に係る情報追跡装置、情報追跡方法および情報追跡プログラムによれば、情報を開示すべき相手を限定した上で当該情報を開示することができる。
【図面の簡単な説明】
【0024】
図1】本発明に係る情報追跡システムの第1の実施形態の構成を示すブロック図である。
図2図1に示す情報追跡データベースのテーブル構成の一例を示す図である。
図3図2に示す情報追跡データベースのデータ要素間の紐付けの例を示す図である。
図4】第1の実施形態の情報追跡装置における開示情報を提示する説明図である。
図5図4に示す認証設問と開示情報との関係を示す図である。
図6】利用者端末に表示されるアルファID及びメールアドレスの検索メニュー表示例を示す図である。
図7】利用者端末に表示される認証設問の表示例を示す図である。
図8】利用者端末に表示される認証設問に関する回答の採点結果表示例を示す図である。
図9】利用者端末に表示される開示者に送信するメッセージ入力表示例を示す図である。
図10】利用者端末に表示される開示請求者に対する送信確認の表示例を示す図である。
図11】利用者端末に送受信される電子メールに含まれるメッセージの転送例を示す図である。
図12】利用者端末に表示されるアルファID検索に関する表示例を示す図である。
図13】利用者端末に表示されるメールアドレス検索に関する表示例を示す図である。
図14】利用者端末に表示される認証設問の作成登録に関する表示例を示す図である。
図15】利用者端末に表示される認証設問の作成登録に関する他の表示例を示す図である。
図16】利用者端末に表示される認証設問の配点編集に関する表示例を示す図である。
図17】情報追跡装置に用いられる情報追跡処理フロー図である。
図18】情報追跡装置に用いられる会員登録処理フロー図である。
図19】情報追跡装置に用いられるアルファID登録処理フロー図である。
図20】情報追跡装置に用いられるメールアドレス登録処理フロー図である。
図21図20に続く情報追跡装置に用いられるメールアドレス登録処理フロー図である。
図22】情報追跡装置に用いられる認証設問作成登録処理フロー図である。
図23図22に続く情報追跡装置に用いられる認証設問作成登録処理フロー図である。
図24】本発明に係る情報追跡装置の第2の実施形態の構成を示すハードウェアブロック図である。
図25】本発明に係る情報追跡装置の第3の実施形態の構成を示すブロック図である。
図26図25に示す情報追跡データベースのテーブル構成の一例を示す図である。
図27】利用者端末に表示されるメールアドレスの新規登録に関する登録画面例を示す図である。
図28】利用者端末に表示されるアルファID登録に関する登録画面例を示す図である。
図29】利用者端末に表示されるアルファID一覧リストに関する表示画面例を示す図である。
図30】利用者端末に表示されるアルファIDフォルダ機能に関する設定画面例を示す図である。
図31】利用者端末に表示されるアルファIDの開示情報に関する表示画面例を示す図である。
図32】利用者端末に表示される私書箱に関する設定画面例を示す図である。
図33】利用者端末に表示される私書箱へのメッセージ入力に関する表示画面例を示す図である。
図34】利用者端末に表示される私書箱に関するメッセージ通知例等を示す図である。
図35】利用者端末に表示される予約メールに関する編集入力画面例を示す図である。
図36】利用者端末に表示される予約メール等に関する経過状態の表示画面例を示す図である。
図37】利用者端末に表示されるメールアドレスの利用状態の管理画面例を示す図である。
図38】利用者端末に表示される著作権に関する開示情報の表示例を示す図である。
図39】非可逆圧縮モード特性の例を示す図である。
【発明を実施するための形態】
【0025】
以下、本発明に係る情報追跡システムの実施形態について、図面を参照して具体的に説明する。ここで、互いに同一または類似の部分には共通の符号を付して、重複説明は省略する。ここで説明する実施形態は、情報追跡システムの一例をとりあげて説明する。
【0026】
[第1の実施形態]
以下、本発明に係る情報追跡システムの第1の実施形態の構成について、図1乃至図23を用いて説明する。図1は、本発明に係る情報追跡システムおよび情報追跡装置1Aの第1の実施形態の構成を示すブロック図である。図2図1に示す情報追跡データベース2Aのテーブル構成の一例を示す図であり、図3図2に示す情報追跡データベース2Aのデータ要素間の紐付けの例を示す図である。なお、その他の図については、以降において適宜説明する。
【0027】
はじめに、図1を参照しながら、情報追跡システムにおける、1以上のクライアント4(例えば登録会員端末41、他の登録会員の開示請求者端末42および非登録会員の開示請求者端末43等の利用者端末4とも称す)と、サーバ3および情報追跡装置1Aとの間におけるデータ通信による各々の要求・応答動作処理等について説明する。
【0028】
本実施形態における情報追跡システムは、情報追跡装置1A、サーバ3、利用者端末4、通信ネットワーク9等を含む構成である。本情報追跡システムにおいて、例えば図1に示すように、登録会員端末41、他の登録会員の開示請求者端末42および非登録会員の開示請求者端末43等のクライアント(利用者端末)4とサーバ3は、通信ネットワーク(例えばインターネット)9にアクセス可能である。また、情報追跡装置1Aは、サーバ3と通信可能に接続されている。なお、情報追跡装置1Aが通信ネットワーク9にアクセス可能であってもよい。
【0029】
情報追跡装置1Aは、サーバ3を介してクライアント4の要求に応じて、後述するような情報追跡処理を実行する。はじめに、サーバ3とクライアント4のインターネット9を介しての応答処理等について説明する。なお、図1のシステム構成の一例では、サーバ3がウェブサーバとして動作し、情報追跡装置1Aがアプリケーションサーバとして動作する例である。すなわち、情報追跡装置1Aは、図1に示す構成例において、情報追跡アプリケーションのアプリケーションサーバとしての機能を有する。
【0030】
サーバ3およびクライアント4は、各々、例えば無線通信(無線LAN、携帯電話等)や有線通信(有線LAN、ADSL等)、または、それらの組み合せなどの通信インタフェースを介して、通信ネットワーク9にアクセス可能である。
【0031】
サーバ3は、クライアント(利用者端末)4から要求を受信し、HTTP(Hypertext Transfer Protocol)を用いてクライアント4に要求されたデータを送信する機能を有する。サーバ3は、例えばHTML(Hyper Text Markup Language)などで記述されるWWW(World Wide Web)ドキュメントをクライアント4に送信する。
【0032】
クライアント4では、ブラウザソフトなどを用いて、送信されたWWWドキュメントを受信して画面上に表示する。ブラウザソフトは、HTMLを解析し、表示する。また、ブラウザソフトは、例えばJava(登録商標)、JavaScript(登録商標)、XMLなどのプログラム言語や、音声や動画などを処理する他のソフトウェアと連携する。
【0033】
クライアント4では、URL(Uniform Resource Locator)などで指定されたリンク先に必要なデータを要求し、例えばサーバ3から応答されたデータをブラウザソフトで処理する。クライアント4(利用者)における端末は、例えばパーソナルコンピュータや、携帯端末、携帯電話などである。また、端末には、OS(オペレーティングシステム)がインストールされており、このOSによりブラウザソフトや、表計算ソフト、文書作成ソフト等のアプリケーションソフトに関する起動・終了、タスクなどが管理される。
【0034】
なお、図1に示すインターネット9を介し、開示情報における開示者や開示請求者等の利用者端末4と相互に通信可能な環境を必要とする一例を示している。開示者は、情報追跡システムの登録会員でなければならないが、開示請求者は必ずしも情報追跡システムの登録会員である必要はない。また、開示者と開示請求者が、同時に通信可能である必要もない。
【0035】
開示者の登録会員端末41、もしくは他の登録会員の開示請求者端末42および非登録会員の開示請求者端末43等の利用者端末4には、ウェブサイトを閲覧するためのウェブブラウザが搭載されている必要があるが、これは一般的なブラウザに限らず最低限、ウェブページを閲覧できるものであればよい。
【0036】
情報追跡システムにおいて、検索対象主情報に関する開示情報を検索するには、原本情報に含まれる検索対象主情報がシステム上、一意でなければならない。よって、開示者は情報追跡システムに対して、開示情報の公開に必要な検索対象主情報を新規発行するよう依頼する(この検索対象主情報となる一意に定める情報追跡識別符号として文字列IDを「アルファID」または「αID」と称す)。一方、電子メールアドレス(以下メールアドレスと称す)もまた、インターネット9上において一意の文字列である性格を有するため、アルファIDに代え、この文字列をそのまま検索対象主情報として流用することも可能である。
【0037】
なお、検索対象主情報を基に抽出される開示情報に、必ずしも個人情報を含める必要はない。例えば、開示者と情報追跡システムとの間の連絡先として、別途登録された開示者のメッセージ転送先となるメールアドレスに対して、メッセージを転送できるようにしつつ、この連絡先を開示請求者からは隠蔽(確認できない状態に)しておけば、情報漏えいの可能性はさらに激減する。
【0038】
そして、このメーセージ転送先はメールアドレスに限らず、電話をはじめ各種個人・特定の者(法人・団体の代表、各部門の担当者等を含む)宛メッセージをインターネット9上から送り付けることが可能なあらゆる手段(インターネット9上のいわゆるメッセンジャーサービスやSNSのプライベートメッセージ機能等を含む)を用いることが可能であり、以降ではこれらを称してメッセージ転送機能と呼ぶ。
【0039】
情報追跡システム上で検索対象主情報を設定する方法は、それがアルファIDである場合又はメールアドレスである場合を可能とする。最初に、登録会員である開示者が自身の登録会員端末41を用いてログインし、会員情報を操作するメニュー画面(「マイページ」と称する)を開く。なお、検索対象主情報を検索する例として、後述する図6(a)にアルファIDを検索する場合、図6(b)にメールアドレスを検索する場合の表示画面例を示す。ここで、図6等において、アルファIDを「ACID」と表記している。
【0040】
アルファIDを用いて開示情報を公開するには、開示者がマイページ上でアルファIDを生成するように(例えば図28)、情報追跡装置1Aへ要求する。情報追跡装置1Aは、開示者からアルファIDの生成要求を受けると、情報追跡データベース2AのアルファIDテーブル22上において一意となるアルファIDを生成し、図3に示すように、追跡情報システム上で会員を特定するユーザーIDとアルファIDとを紐付け(結合)して、アルファIDテーブル22に保存する。なお、一つのユーザーIDに、複数のアルファIDを紐付けることができる。
【0041】
これにより、当該開示者が媒体(名刺・カタログなどの紙媒体、商品・製品、個人・企業等の所持品などの物品、電子データ等)などに付与して利用するためのアルファIDを確定することができる(図3)。情報追跡装置1Aでは、開示情報を開示するにはさらに当該アルファIDに付随する開示情報を入力して、アルファIDテーブル22に保存する。
【0042】
さらにメッセージ転送機能を利用する場合は、メッセージを受け付けるための連絡先をアルファIDテーブル22へ追加登録される。また当該情報を特定の時点において「公開/非公開」を選択できるようにする際に、公開可否属性を開示者が選択・登録する。
【0043】
一方、メールアドレスは情報追跡システムが発行したものではないため(本実施形態では情報追跡装置1Aとする)、開示者がこれを検索対象主情報として使用する場合に、適当であるか否かは情報追跡システム上で確認されなければならない。すなわち、情報追跡システムの登録会員である開示者が自身の登録会員端末41を用いてシステムにログインし、会員情報を操作する「マイページ」を開いたあと、検索対象主情報として利用したいメールアドレスを情報追跡システムに入力する。
【0044】
当該メールアドレスが、情報追跡装置1Aにより情報追跡データベース2A上で未だ検索対象主情報として登録されていないことが確認されると、当該メールアドレスが開示者の管理下にあることを確認するため、情報追跡装置1Aが当該メールアドレス宛に確認メールを送信する。
【0045】
当該メールアドレスに送信されたメールを開示者が受信したことを確認するため、当該メール内で指定されたウェブページが開かれると、当該ウェブページを開示者が閲覧した事実を情報追跡装置1Aが認識して、当該メールアドレスが開示者の管理下にあることが情報追跡装置1Aで確認される。
【0046】
情報追跡装置1Aは、当該メールアドレスとユーザーIDとを紐付けて、メールアドレステーブル23に保存する。これにより、当該メールアドレスは、当該ユーザー(開示者)が利用可能な検索対象主情報となることが確定される。開示者が開示情報を開示するには、さらに検索対象主情報に付随する開示情報を入力して、情報追跡データベース2Aに保存する。
【0047】
さらに、開示者がメッセージ転送機能を利用する場合は、メッセージを受け付けるための連絡先を登録する。また当該情報を特定の時点において「公開/非公開」を選択する場合には、この公開可否属性を開示者が選択・登録する。
【0048】
開示請求者が、利用者端末4を介して検索対象主情報を基に開示情報の開示請求を行うには、情報追跡システムの登録会員である必要はない。開示請求者が、利用者端末4を介して、例えば図6に示すようなシステム上の検索ページを開いて検索対象主情報(アルファID又はメールアドレス)を入力し、情報追跡装置1Aは情報追跡データベース2Aから当該検索対象主情報を検索及び抽出する。
【0049】
情報追跡装置1Aは、当該検索対象主情報に付随する開示情報を確認し、公開可否属性が設定されている場合に、これが公開可の状態であると、例えば図8(c)に示すような開示情報を開示請求者の利用者端末4に出力する。また、メッセージ転送機能が有効な場合には、開示請求者が開示者に対して、例えば図9及び図10に示すようなメッセージを送信できる旨が表示される。
【0050】
次に、図1に示す実施形態の情報追跡装置1Aの詳細な構成例について説明する。図1に示す情報追跡装置1Aは、情報追跡データベース2Aを検索・登録・更新等のアクセス処理可能に管理する。情報追跡データベース2Aは、図1及び図2に示すように、その中に会員情報テーブル21と、検索対象主情報を含むアルファIDテーブル22及びメールアドレステーブル23と、認証設問データテーブル24とを有する。
【0051】
情報追跡装置1Aは、通信ネットワーク9を介して、複数の登録会員に関する登録情報を登録及び検索可能な情報追跡データベース2Aに当該登録会員又は非登録会員からアクセス可能である。また、情報追跡装置1Aは、各々の登録会員が予め定めた媒体に付与される登録会員を特定可能な情報追跡識別符号(以下、アルファID又はαIDと称す)を情報追跡データベース2Aに登録及び検索可能である。
【0052】
情報追跡装置1Aは、アルファIDごとに、登録会員に関する登録情報(開示情報を含む)をアルファIDテーブル22に紐付けて格納する。
【0053】
情報追跡データベース2Aは、さらに、登録会員に関する登録情報に応じて、他の登録会員又は非登録会員が操作する開示請求者端末42又は43からの登録情報についての開示請求に対して開示の有無を判断するための一又は複数の設問及び当該設問に対する正答と、設問の回答に対する開示の有無の採点判断基準と、当該開示有りの場合の登録情報についての開示範囲が予め定められた開示情報とを、登録会員のアルファID又は予め登録されたメールアドレスごとに紐付けて格納する。
【0054】
情報追跡装置1Aは、情報追跡データベース2Aに基づいて、登録会員に関するアルファID又はメールアドレスに紐付けられた登録情報を管理する。このために、情報追跡装置1Aは、図1に示すように、情報検索入出力手段11と、設問提示認証手段12と、メッセージ転送手段13と、設問回答作成手段14とを備える。
【0055】
ここで、図4及び図5も参照しながら、第1の実施形態の情報追跡装置1Aの構成および動作を説明する。ここで、図4は、第1の実施形態の情報追跡装置1Aにおける開示情報を提示する説明図であり、図5は、図4に示す認証設問と開示情報との関係を示す図である。
【0056】
情報検索入出力手段11は、利用者端末4から開示情報の検索、開示請求・登録、各種登録の要求処理および応答処理を実現するために、以降の他の手段(設問提示認証手段12と、メッセージ転送手段13と、設問回答作成手段14等)とのデータ入出力、情報追跡データベース2Aとのアクセスを行う。
【0057】
このために、情報検索入出力手段11は、図1に示すように、検索情報受信部111、検索情報解析部112および開示情報出力部113を有する。
【0058】
検索情報受信部111は、登録会員が操作する登録会員端末41、又は、他の登録会員の開示請求者端末42若しくは非登録会員の開示請求者端末43の利用者端末4から登録情報に関する入力又は検索の入力データを受け付ける。
【0059】
検索情報解析部112は、利用者端末4から登録情報に関する入力又は検索の入力データについて、情報追跡データベース2Aに基づき、データベース上のデータについて検索、抽出、登録、更新等のアクセス処理を行う。
【0060】
開示情報出力部113は、登録会員端末41又は開示請求者端末42若しくは43へ登録情報に関する当該入力又は検索の結果の出力データを、サーバ3を介して出力する。すなわち、サーバ3は、情報検索入出力手段11の開示情報出力部113から出力データを受けて、クライアント(利用者端末)4の要求に対するレスポンス処理を実行する。
【0061】
設問提示認証手段12は、図4及び図5に示すように、例えば他の登録会員の開示請求者端末42又は非登録会員の開示者請求者端末43の開示請求に応じて、情報追跡データベース2Aから開示請求に対応する設問を抽出し、当該抽出した設問を当該開示者請求者端末42又は43に提示する。設問提示認証手段12は、当該開示者請求者端末42又は43から応答された設問の回答に基づいて、開示情報の提供の有無を決定する。
【0062】
設問提示認証手段12は、当該決定した開示情報の提供の有無に応じて開示情報を情報追跡データベース2Aから抽出し又は抽出せず、開示情報を抽出した場合には、メッセージ転送手段13が、当該抽出した開示情報に関するメッセージを開示請求者端末42又は43へ通信ネットワーク9を介して転送する。
【0063】
このために、設問提示認証手段12は、図1に示すように、設問抽出部121、設問出力部122、回答受信部123、回答採点部124および採点結果出力部125を有する。
【0064】
設問抽出部121は、図4及び図5に示すように、利用者端末4(例えば非登録会員の開示者請求者端末43)の開示請求に応じて、情報追跡データベース2Aの認証設問データテーブル24から検索対象主情報に対応する設問を抽出する。
【0065】
設問出力部122は、情報検索入出力手段11を介して、抽出された設問を利用者端末4へ提示(出力)する。
【0066】
回答受信部123は、情報検索入出力手段11を介し、設問出力部122から出力されて利用者端末4から応答された設問に対する回答を受信する。
【0067】
回答採点部124は、認証設問データテーブル24から設問に対応する正答を抽出し、抽出した正答に基づいて受信した回答を採点する。
【0068】
採点結果出力部125は、認証設問データテーブル24から設問に対応する第1の採点基準判断を抽出し、当該第1の採点基準判断に基づいて採点した回答の採点結果を判定する。採点結果出力部125は、情報検索入出力手段11を介して、採点結果を利用者端末4へ出力する。これにより、採点結果は、例えば図8(a)又は(b)のように利用者端末4に表示される。
【0069】
メッセージ転送手段13は、登録会員端末41、開示請求者端末42又は43へ、少なくとも開示情報に関する要求又は応答のメッセージを転送する。メッセージの転送とは、例えば情報追跡システム側の所定のメールアドレスから開示請求者又は開示者の指定したメールアドレスへメッセージを含むメールを送信、または、指定URL先へ記載されたメッセージの当該指定URLを通知するメールを送信する等である。
【0070】
例えば、利用者端末4の表示画面には、図8(c)に示す認証設問の合格後に、メッセージ送信のボタンをクリックすると、続けて開示請求者が図9に示すようなメッセージ編集を行い、図10に示すようなメッセージ確認表示と共に当該メッセージを送信する。開示請求者による利用者端末4から送信されたメッセージは、メッセージ転送手段13を介して、図11に示すように、情報追跡システムの所定のメールアドレスから開示請求者の指定した返信先メールアドレスおよび開示者の登録メールアドレスへ転送される。
【0071】
設問提示認証手段12は、例えば他の登録会員の開示請求者端末42又は非登録会員の開示者請求者端末43からの開示請求の際に、情報検索入出力手段11を介して指定されたアルファID又はメールアドレスが情報追跡データベース2Aに格納された登録会員のアルファID又は予め登録されたメールアドレスに一致した場合に、一致した登録会員のアルファID又は予め登録されたメールアドレスに対応する設問を情報追跡データベース2Aから抽出する。設問提示認証手段12は、情報検索入出力手段11を介して、当該抽出した設問を開示請求者端末42又は43へ出力する。
【0072】
設問を提示後に回答を受けた場合に、設問提示認証手段12は、開示請求者端末42又は43による設問に対する回答の正答を判定し、当該判定した回答の採点結果を採点判断基準に基づいて開示情報の提供の有無を決定する。
【0073】
情報追跡データベース2Aには、関連付けが許可された異なる他の情報追跡識別符号と、開示情報に関連付けの情報として登録することができる。
【0074】
情報検索入出力手段11は、関連付けが許可された異なる他の情報追跡識別符号と、開示情報に関連付けした情報を提示可能とする。なお、関連付けが許可された異なる他の情報追跡識別符号との実施例等は、後述する第3の実施形態の例で説明する。
【0075】
次に、図2に示す情報追跡データベース2Aの構成の一例を説明する。情報追跡データベース2Aは、図2に示すように、会員情報テーブル21と、アルファIDテーブル22と、メールアドレステーブル23と、認証設問データテーブル24とからなるデータテーブルを有する。
【0076】
会員情報テーブル21は、情報追跡システムにログインするためのログイン名、ログインパスワード、連絡先のメールアドレスを格納するテーブルである。例えば、会員情報テーブル21は、図2に示すように、登録会員を特定するためのユーザーIDごとに、管理者名、ログイン名、ログインパスワード、連絡先メールアドレスおよび登録状態を示すステータスなどを含む。
【0077】
アルファIDテーブル22は、情報追跡の対象となる対象媒体ごとに、一に定められるアルファIDと、登録会員の開示情報などを紐付けるテーブルである。例えば、アルファIDテーブル22は、図2に示すように、アルファIDごとに、登録する登録会員の登録会員ID、開示の有無の設定状態を示すフラグ(公開可否属性状態)、認証設問データテーブル24と紐付けられるデータ、メーセージ転送先、開示される開示情報などを含む。アルファIDテーブル22に格納されるデータは、登録会員ごとに、かつ、アルファIDごとに、アルファIDの新規作成および登録ごとに、生成されて格納される。
【0078】
これで当該ユーザー(登録会員端末41)からアルファIDの登録要求を受けて、情報追跡装置1Aにより一意に定められるアルファIDが確定する。ユーザーが更新情報を開示する場合には、さらに当該アルファIDに付随する情報が入力されて、情報追跡データベース2Aに保存される。さらに、ユーザーがメッセージ転送機能を利用する場合には、メッセージを受け付けるための連絡先を追加登録する。また、当該情報を特定の時点において「公開/非公開」が選択された場合は、この公開可否属性状態が選択・登録される。
【0079】
例えば、メールアドレステーブル23は、図2に示すように、ユーザーID及びメールアドレスごとに、公開可否属性、設問ID(quiz_ID)、メッセージ転送先、更新情報を格納する。
【0080】
メールアドレスは、情報追跡システムが発行したものではないため、開示者がこれを検索対象主情報として使用するに適当であるか否かは情報追跡システム上で確認されなければならない(図3)。すなわち、情報追跡システムの会員である開示者が自身の端末を用いて、情報追跡システムにログインし会員情報を操作する「マイページ」を開いたあと、検索対象主情報として利用したいメールアドレスを情報追跡システムに入力する(後述する図27に示す)。
【0081】
当該メールアドレスが、情報追跡システム上で未だ検索対象主情報として登録されていないことが確認されると、当該メールアドレスが開示者の管理下にあることを確認するため、情報追跡装置1Aが当該メールアドレスに対して確認メールを送信する。
【0082】
当該メールアドレスに送信されたメールを開示者が受信したことを確認するため、当該メール内で指定されたウェブページが開かれると、当該ウェブページを開示者が閲覧した事実を情報追跡装置1Aが認識する。情報追跡装置1Aの認識後、当該メールアドレスが開示者の管理下にあることを、情報追跡装置1Aが認証する。
【0083】
認証設問データテーブル24は、開示者の開示情報を開示請求者へ開示してよい相手かを判断するための認証設問を格納する。認証設問データテーブル24に格納されるデータは、登録会員ごとに、予め作成又は設定される。
【0084】
例えば、認証設問データテーブル24は、図2に示すように、ユーザーID及び設問IDごとに、設問IDのタイトル、最高点、認証点、一つの設問ごとの配点、各々の設問及び正答を格納する。認証設問は、設問IDによって開示情報に紐付けられ、開示情報を開示請求者に対して、認証設問データテーブル24の設問IDに紐付けられた設問タイトル、設問などが抽出されたものである。
【0085】
認証設問は、開示者が情報検索者(開示請求者)に提示する、例えば図7に示すようなクイズ・設問形式等の設問群であり、開示者との関係において開示者の想定内に属する開示許容される開示請求者(想定内開示請求者)であれば、正答可能である1つ以上の設問から構成される。各正答は既定の文字列に頼らず、回答者自身の知識・記憶から導き出すことが可能であるため、設問内容が変化したとしても想定内開示請求者には対応が可能となる。
【0086】
一方、既定の文字列ではないために、正規請求者であっても確実に正答を導き出すことができるとは限らない。しかしこの問題は、認証設問の設問を複数にし、採点結果が一定以上の得点(認証点とする)に達したことをもって、例えば図4に示すような回答者を想定内グループに属する開示請求者と推定するという手法によって解決することができる。
【0087】
つまり、認証設問はその特性上、複数の設問から構成され、例えば図16に示すように、論理的最高点(全問正解時の合計点)対して、設問の回答に対する開示の有無の採点判断基準とする認証境界点(想定内開示請求者と判断できるボーダーライン)を自由に設定できる。アルファIDが検索され、認証設問を経て推測された正規請求者の信憑性は、開示者が設定した設問内容によって定まることとなる。
【0088】
また、設問ごとの配点として、例えば図16に示すように+1点、+10点、0点、−1点等の配点が可能である。例えば、開示したくない想定グループに属する対象者に対して、該当する設問を作成して、その設問に正答した場合に、−10点を加算(正負可能な重み付け)する等である。これにより、開示者が情報開示を好まないグループに情報を開示しないようにすることもできる。
【0089】
また、一つの検索対象主情報によって抽出される更新情報と結合する認証設問数は、複数設定できることが望ましい。認証設問において、例えば図14乃至図16に示すように、設問の回答においても、文字列の入力形式、回答の複数選択形式等の組み合せを任意にできるようにしてもよい。
【0090】
例えば原本情報が名刺であり、検索対象主情報が当該名刺の表面に書かれたアルファIDであることを想定すれば、開示者がこの名刺を手渡す相手は千差万別である。図4に示す例では、一人の登録会員が配布した複数種類の名刺の各々に、複数のアルファID(αID#1、αID#2、・・・、αID#m)が付与されている場合を示す。例えば、これらの名刺の各々が、その登録会員の学生時代、社会人時代、その他の趣味のサークル活動等により、使い別けられて配布されていた場合に、開示情報を開示請求する想定対象グループも想像がつきやすい。
【0091】
登録会員は、それらの想定対象グループのαIDごとに、それぞれの想定対象グループに対応する認証設問を作成しやすくなる。また、それらの想定対象グループごとに、図4に示すように、開示情報の開示範囲を設定しやすくなる。
【0092】
相手は業務上の関係者であるばかりでなく、プライベートな友人の場合もある。そこで相手との関係性を鑑みた内容の認証設問を表示させるためには、図5に示すように、一つのアルファID#1に対して複数種の認証設問群(例えば会社時代に関する設問群A、高校時代に関する設問群Bなど)を登録することもできる。
【0093】
図2及び図3に示す情報追跡データベース2Aのテーブル構成例のように、更新情報の公開には検索対象主情報と認証設問データとが紐付けされて、データベースに保存される。また、後述する図17に示すように、検索対象主情報を基に開示情報が開示される処理フローでは、情報追跡装置1Aが認証設問を表示して開示請求者に回答を求めて、その回答を採点し、開示すべき相手であるか否かを判断する。
【0094】
さらに、本実施形態の情報追跡システムでは、情報追跡データベース2Aには、登録会員ごとに、登録会員が利用した又は利用している複数のメールアドレスについて登録可能である。
【0095】
情報検索入出力手段11は、登録会員に対する開示請求に対して、検索指定されたメールアドレスと予め登録されたメールアドレスのいずれかに一致した場合には、情報追跡データベース2Aから抽出した当該メールアドレスの使用又は不使用の状態を提示し、登録されたメールアドレスに一致しない場合には検索対象が存在しないことを提示(出力)する。
【0096】
設問回答作成手段14は、登録会員端末41から入力データのうちの設問及び正答の作成データを受けて、当該作成データに基づいて登録会員のアルファID又は予め登録されたメールアドレスのいずれかに紐付けて情報追跡データベース2Aに登録可能とする。
【0097】
このために、設問回答作成手段14は、図1に示すように、設問記録部141、正答記録部142および認証基準記録部143を有する。
【0098】
設問記録部141は、登録会員端末41から入力データのうちの設問を受けて、検索情報解析部112を介して、当該作成データに基づいて登録会員のアルファID又は予め登録されたメールアドレスのいずれかに紐付けて情報追跡データベース2Aに登録可能とする。
【0099】
正答記録部142は、登録会員端末41から入力データのうちの設問データに対応する正答の作成データを受けて、当該作成データに基づいて所定の設問に対する正答として紐付けられて情報追跡データベース2Aに登録可能とする。
【0100】
認証基準記録部143は、各々の設問群ごとに、採点の点数又は正答率などにより正規の請求者として認証判定する採点判断基準を情報追跡データベース2Aへ記録する。
【0101】
認証基準記録部143は、各々の設問群ごとに、異なる他の判断基準を設定してもよい。これにより、開示情報の開示範囲によって、より登録会員をよく知る人物しかわからないような設問とする等により設問の正答する難易度を高めることができ、容易に開示情報を、他の開示グループ対象と想定する者に突破されないようにすることができる。
【0102】
例えば、図14乃至図16に示す表示画面は、登録会員が設問を作成する際に、登録会員端末41を介して、情報追跡装置1Aの設問回答作成手段14の処理により認証設問を作成する一例である。
・設問の回答に対する開示の有無の採点判断基準
登録会員は、回答の正答に対して+1点、誤答に対して−1点等の配点をする場合や、+10点、0点等の配点が可能である。また、例えば、開示したくないグループに続する対象者に対して、該当する設問を作成して、その設問に正答(該当する場合も含む)した場合に、−10点を加算する等である。これにより、開示者が情報開示を好まないグループに情報を開示しないようにすることができる。
【0103】
なお、例えば図5に示すような開示対象グループの設問群ごとに、一の採点判断基準と異なる他の判断基準を設定してもよい。これにより、開示情報の開示範囲によって、より登録会員をよく知る人物しかわからないような設問とする等により設問の正答する難易度を高めることができ、容易に開示情報を、他の開示グループ対象と想定する者に突破されないようにすることができる。
【0104】
開示情報に含まれる開示される更新情報等には、個人情報が含まれることも想定される。開示請求フローとして、開示すべき相手を特定する方法がないと、不特定多数への個人情報の漏えいが懸念される。そこで、開示請求者が「開示者が本来想定する開示すべき相手」(正規請求者とする)であることを、システムが自動的に確認する仕組みを実装する必要がある。
【0105】
正規請求者を特定するには、例えば検索対象主情報を名刺等に記載する際に認証パスワードを併記するといった方法も考えられる。しかしこれでは当該パスワードが公知となった時点で、その意味は失われる。つまり認証パスワードは可変である必要があると同時に、当該パスワードが変化後にも正規請求者が自ら認識して入力できるものでなければならないということになる。
【0106】
このような条件を満たす手段が、認証設問である。認証設問は、例えば開示者が情報検索者に提示するQA形式の設問群からなり、開示者との関係で対応する正規請求者であれば回答可能であるはずの1つ以上の設問から構成される。設問群の各正答は、認証パスワードとは異なり既定の文字列に頼らず、回答者自身の知識・記憶から導き出すことが可能であるため、設問内容が変化したとしても正規請求者には対応が可能となる。
【0107】
他方、開示者と何ら関係のない非正規請求者に対しては、回答者自身の知識では想像がつきにくい設問の回答、又は、回答の組み合わせが相当数の可能性があるだけで、認証設問を容易に突破することが困難となる。
【0108】
一方、正答は既定の文字列だけではないため、正規請求者であっても確実に正答を導き出すことができるとは限らない。しかし、この問題は認証設問に関する設問を複数にし、採点結果が一定以上の得点に達したことをもって、回答者を正規請求者と推定するという手法によって解決できる。つまり、認証設問はその特性上、複数の設問から構成され、論理的最高点(全問正解時の合計点)対して、採点判断基準とする認証境界点(正規要求者と判断できるボーダーライン)を自由に設定できる特徴がある。
【0109】
よって、アルファIDが検索され、認証設問を経て推測された正規請求者の信憑性は、開示者が設定又は作成した設問内容によって定まることとなるが、複数の設問から構成されれば、正規請求者にとっては、自身の知識・記憶から導き出すことにより、例えば採点判断基準とする認証境界点以上の点数を獲得することはより確実性が高くなる。一方、非正規請求者にとっては、認証設問を突破することが容易になるわけではない。
【0110】
また、一つの検索対象主情報によって抽出される開示情報と対応付ける認証設問数は、複数設定できることが望ましい。例えば、開示者の原本情報が名刺であり、検索対象主情報が当該名刺の表面に書かれたアルファIDであることを想定すれば、開示者がこの名刺を手渡す相手は千差万別である。相手は業務上の関係者であるばかりでなく、プライベートな友人の場合もある。
【0111】
そこで、相手との関係性を鑑みた内容の認証設問を表示させるためには、図5に示すように、一つのアルファIDに対して複数種の認証設問を紐付けることも可能である。また、一人の開示者が複数の名刺を原本情報として、図4に示すように、各々に異なる複数のアルファIDを付与した場合にも、各々のアルファIDに対して複数の設問も紐付けることも可能である。
【0112】
以上のような認証設問等の手段では、図3に示すフローのように、開示情報の公開には検索対象主情報と認証設問データを紐付けしてデータベースに記録するステップが必要となり、また図4及び図5に示すように、検索対象主情報を基に開示情報が開示されるフローには、認証設問を表示して開示請求者に回答を求め採点し、開示すべき相手であるか否かを判断するステップが必要となる。なお、これらのフロー等については、詳しくは図17乃至図23の説明にて後述する。
【0113】
一方の開示請求者側から見た開示者の本人確認は、開示者本人からすでに提示されたアルファIDとの照合によって明確であるものの、検索対象主情報としてメールアドレスを用いた場合にはこの限りでない。メールアドレスはその性格上ほとんどの場合、サービス運営者(例えば携帯電話キャリアやインターネット・サービスプロバイダ)や所属組織(学校や勤務先)が個人に対し授与(一定期間貸与)するものであるため、サービスへの加入時期や組織での所属時期によっては、同一のメールアドレスを使い回される可能性を否定できない。
【0114】
すなわち、一つのメールアドレスの利用者(管理者)が時期により異なるために、メールアドレスを検索対象主情報として情報を抽出しようとすると、開示請求者にとって想定外の開示者の情報を取得したり、あるいは想定しない相手に対してメッセージを転送してしまうなどといった不都合が発生しうる。
【0115】
検索対象主情報の違いにより発生するこの種の問題には開示者、すなわち開示請求者から見た相手の本人確認も必要となるが、この確認もまた認証設問を用いることで解決できる。先述のメッセージ転送機能を用いてメッセージを送信した際、これを受け取った人物(開示者)もまた、送信者(開示請求者)が指定した認証設問に挑戦し、認証境界点以上の採点結果を提示しなければメッセージ内容を閲覧することができない手段(開示請求者側の認証設問)を実装する。ただしこの場合は、開示者に対してメッセージを送信する開示請求者自身も、後述するような認証設問を作成する必要がある。なお、開示請求者は、認証設問に代わる他の手段を用いることも可能ではあるが、本情報追跡システムの認証設問を併用する場合には、開示請求者もまた情報追跡システムの会員となる必要がある。
【0116】
例えば、本情報追跡システムにおいて、以下のように、開示請求者から開示者に対する開示請求者の個人情報等を含む情報を秘匿化して、開示者側に認証設問を行うことも可能である。具体的には、開示請求者端末42により設問回答作成手段14を用いて、開示者(開示請求対象の登録会員宛)に設定した開示請求者設問を、設問提示認証手段12が登録会員端末41へ提示する。
【0117】
設問提示認証手段12が、開示請求者設問に対する登録会員端末41からの回答の採点結果が開示請求者端末42により予め定められた開示請求者設問の当該回答に対する開示の有無の第2の採点判断基準に基づいて開示有りとした場合に、メッセージ転送手段13が、開示請求者端末42により作成された開示請求者の開示する情報を含むメッセージを登録会員端末41へ転送する。
【0118】
一方、設問提示認証手段12が、開示請求者設問の当該回答に対する開示の有無の第2の採点判断基準に基づいて開示無しとした場合に、メッセージ転送手段13が、開示請求者の開示する情報を開示しない旨を含むメッセージを登録会員端末41へ転送する。
【0119】
このように開示者(メッセージの受信者)及び開示請求者(メッセージの送信者)が互いに認証設問を用いることによって、ウェブシステム上であっても精度の高い相互認証確認が可能となる。
【0120】
前述したようなメッセージ転送機能を主に実現する手段が、以降で説明する図1に示すメッセージ転送手段13である。メッセージ転送手段13は、各個人・特定の者(法人・団体の代表、各部門の担当者等を含む)宛にメッセージを転送することができる。例えばメーセージ転送先への転送方法は、メールアドレスに限らず、電話をはじめ各種個人宛メッセージをインターネット9上から送り付けることが可能なあらゆる方法(インターネット9上のいわゆるメッセンジャーサービスやSNSのプライベートメッセージ機能等を含む)等を用いることが可能である。
【0121】
このために、メッセージ転送手段13は、図1に示すように、フォーム出力部131、メッセージ受信部132、入力データ検査部133、メッセージ送信部134および処理結果出力部135を有する。
【0122】
フォーム出力部131、開示請求者から開示者、又は、開示者から開示請求者へのメッセージを転送するための利用者端末4へ表示されるフォームを出力する。例えば、フォーム出力部131は、図9に示すようなメッセージ編集フォームに関する表示データ等を、情報検索入出力手段11を介して、利用者端末4に出力する(表示させる)。
【0123】
メッセージ受信部132は、システムが管理する所定のメールアドレス宛に送信された開示請求者又は開示者からの電子メールを受信する。
【0124】
入力データ検査部133は、フォーム出力部131から出力するフォームへ入力されたデータについて、当該入力項目ごとに、データの整合性をチェックする。例えば、入力データ検査部133は、図9に示すメールアドレスの返信先、送信者名等に、不適当な文字、数値等、また、所定の文字数制限を越えていないか検査する。
【0125】
メッセージ送信部134は、システムが管理する所定のメールアドレスから開示請求者又は開示者のメールアドレス宛にメッセージを送信する。例えば、メッセージ送信部134は、図11に示すようなメッセージを送信(転送)する。
【0126】
処理結果出力部135は、メッセージを転送完了した旨等の処理結果について、情報検索入出力手段11を介して、利用者端末4へ送信する。例えば、処理結果出力部135は、情報検索入出力手段11を介して、図10に示すように、開示請求者の利用者端末4に出力する。
【0127】
ここで、図9に、利用者端末4に表示される開示者に送信するメッセージ入力表示例を示す。また、図10に利用者端末4に表示される開示請求者に対する送信確認の表示例、図11に利用者端末4に送受信される電子メールに含まれるメッセージの転送例を示す。図12に、利用者端末に表示されるアルファID検索に関する表示例を示す。図13に、利用者端末に表示されるメールアドレス検索に関する表示例を示す。
【0128】
・アルファIDフォルダ設定されたαIDへのメッセージ転送機能
なお、検索対象主情報を基に抽出される更新情報を含む開示情報に、必ずしも個人情報を含める必要はない。例えば、図9に示すように、開示者と情報追跡装置1Aとの間の連絡先として、登録された開示者のメールアドレス(以下、メッセージ転送先)に対してメッセージを転送できるようにしつつ、この連絡先を開示請求者からは隠蔽(確認できない状態に)しておけば、情報漏えいの可能性はさらに激減する。
【0129】
そして、この転送先はメールアドレスに限らず、電話をはじめ各種個人宛メッセージをインターネット上から送り付けることが可能なあらゆる手段(インターネット上のいわゆるメッセンジャーサービスやSNSのプライベートメッセージ機能等を含む)を用いることができる(以下、メッセージ転送機能と称す)。
【0130】
本情報追跡システムによれば、
・開示制限なしと、開示制限付の開示情報の設定可能である
・αIDごとに、上記が可能である
・迷惑メール対策となる
・人脈の繋がりを保つことが可能である
・所有物、権利等の所有者・権利者等の管理が可能である
・本人からの第三者に対するアクセスでなく、第三者からのアクセスにより本人の更新情報を開示することができる。通常は、本人からは連絡がとれない・不明となったこれらの関係した人物等に、アクセスする必要はない
・ブログや、ホームページ等のように、不特定多数に対して情報を開示する必要がなく、また、特定の第三者に対して、情報を開示することが可能である。
【0131】
本情報追跡システムでは、各種サービスの会員情報や名刺、公的に処理されるような単に個人情報のみを扱うものではなく、例えば店舗や商品・サービスの情報、パンフレット内容といった一般に紙媒体で授受される情報はもちろん、インターネット上を流れる電磁情報のほか、さまざまな携行品に記載される所有者情報、映像・動画情報、芸術作品情報、音声情報をも含め、[過去の情報」を更新し、かつ、開示可能とする有効な技術である。
【0132】
例えば、このうち映像・動画情報、物理的な芸術作品情報、及び音声情報の「追跡」とは、主に著作権者を追跡することを想定するものである。このうち映像・動画情報、物理的な芸術作品については、その作品中に検索対象主情報を極小文字で混入するといった手法を用いることができる。
【0133】
次に、図17乃至図23を参照しながら、情報追跡装置1Aに用いられる情報追跡処理等に関するフローについて説明する。はじめに、図17を参照しながら、図1の情報追跡装置1Aに用いられる情報追跡処理フローについて説明する。
【0134】
情報追跡装置1Aの主電源パワーオン後、起動処理などを経た後、利用者端末4からの情報追跡処理の要求を受けて、本情報追跡処理を開始する。
【0135】
情報追跡装置1Aの情報検索入出力手段11は、利用者端末4から検索ページオープンの要求処理を受けて、検索ページメニュー(画面表示等)に関する表示データ等を利用者端末4へ送信する(ステップS1)。なお、図1の構成例では、サーバ3が、情報追跡装置1Aから処理データ受けて、インターネット9を介して、要求処理された利用者端末4へ応答処理データを送信する。
【0136】
利用者端末4から、検索対象主情報であるアルファID又はメールアドレスが入力される(ステップS2)。
【0137】
情報検索入出力手段11は、インターネット9を介して、利用者端末4から検索対象主情報の検索要求を受けると、該当する検索対象主情報について情報追跡データベース2Aを検索する(ステップS3)。
【0138】
情報検索入出力手段11は、該当する検索対象主情報を検索によりヒットしなかった場合には、ステップS5へ処理を進める(ステップS4 No)。
【0139】
情報検索入出力手段11は、該当する利用者端末4へ検索対象が存在しない旨の応答を送信し(ステップS5)、本検索処理を終了する。
【0140】
一方、情報検索入出力手段11は、該当する検索対象主情報を検索によりヒットした場合にはステップS6へ処理を進める(ステップS4 Yes)。
【0141】
情報検索入出力手段11は、検索ヒットした検索対象主情報に関するテーブルデータを情報追跡データベース2Aから抽出する(ステップS6)。例えば、情報検索入出力手段11は、検索対象主情報がアルファIDである場合にはアルファIDテーブル22から該当するテーブルデータを抽出し、検索対象主情報がメールアドレスである場合にはメールアドレステーブル23から該当するテーブルデータを抽出する。
【0142】
情報検索入出力手段11は、抽出したテーブルデータから公開可否属性状態をチェックし、公開可否属性状態が非公開である場合には(ステップS6 No)、ステップS10へ処理を進める。一方、公開可否属性状態が公開である場合には(ステップS6 Yes)、情報検索入出力手段11は、ステップS7へ処理を進める。
【0143】
情報検索入出力手段11は、設問ID(quiz_ID)登録されていなければ(ステップS7 No)、開示制限のない開示情報と判断し、該当する開示情報をアルファIDテーブル22又はメールアドレステーブル23(該当テーブルデータとする)から抽出する。抽出後、情報検索入出力手段11は、処理をステップS11へ進める。
【0144】
一方、情報検索入出力手段11は、設問ID(quiz_ID)登録されていれば(ステップS7 Yes)、該当する設問IDの設問を認証設問データテーブル24から抽出する。情報検索入出力手段11は、処理をステップS8へ進める。
【0145】
情報検索入出力手段11は、設問提示認証手段12により抽出された設問を利用者端末4へ送信し、設問提示認証手段12は、情報検索入出力手段11を介して利用者端末4から設問に対する回答を受けた場合に、設問ごとの正答に基づいて当該回答に対して採点する(ステップS8)。
【0146】
設問提示認証手段12は、設問ごとの正答に基づいて当該回答に対して採点し、当該採点結果が、予め定められた認証点を以上か否かを判断する(ステップS9)。認証点未満の場合には(ステップS9 No)、設問提示認証手段12は情報開示不可と判定し、ステップS10へ処理を進める。
【0147】
情報検索入出力手段11は、設問提示認証手段12から情報開示不可との判定を受けて、情報開示不可である応答を利用者端末4へ送信する(ステップS10)。応答後、検索ページメニュー処理を終了する。
【0148】
一方、認証点以上の場合には(ステップS9 Yes)、設問提示認証手段12は情報開示可と判定し、ステップS11へ処理を進める。
【0149】
情報検索入出力手段11は、開示情報を利用者端末4へ送信する(ステップS11)。
【0150】
情報検索入出力手段11は、該当テーブルデータにメッセージ転送先が登録されていない場合には(ステップS12 No)、開示情報を利用者端末4へ送信後、検索ページメニュー処理を終了する。
【0151】
一方、情報検索入出力手段11は、該当テーブルデータにメッセージ転送先が登録されていた場合には(ステップS12 Yes)、メッセージ転送手段13により開示者へ開示請求者に対して開示情報を開示した旨のメーセージをメッセージ転送先に登録されたメールアドレスに対して送信させる。
【0152】
メッセージ転送手段13は、該当テーブルデータに送信メッセージについての更新情報がない場合には(ステップS13 No)、情報検索入出力手段11は、検索ページメニュー処理を終了する。
【0153】
一方、メッセージ転送手段13は、該当テーブルデータに送信メッセージについての更新情報がある場合には(ステップS13 Yes)、抽出された更新情報を含むメッセージを指定先のメールアドレスへ送信する(ステップS14)。本処理終了後、情報検索入出力手段11は、検索ページメニュー処理を終了する。
【0154】
次に、図18を参照しながら、情報追跡装置1Aに用いられる会員登録処理フローについて説明する。
【0155】
情報追跡装置1Aの情報検索入出力手段11は、利用者端末4から会員登録ページオープンの要求処理を受けて、会員登録ページメニューに関する表示データ等を利用者端末4へ送信する(ステップS21)。
【0156】
情報検索入出力手段11は、他のSNS等のアカウントを用いて登録するか否かの回答入力を待つ(ステップS22)。
【0157】
他のSNS等のアカウントを用いて登録する場合には(ステップS22 Yes)、ステップS23へ処理を進める。
【0158】
メッセージ転送手段13は、他のSNS等に接続し、連絡先メールアドレス等のアカウント情報を取得する(ステップS23)。アカウント情報を取得後、ステップS28へ処理を進める。
【0159】
一方、他のSNS等のアカウントを用いて登録しない場合には(ステップS22 No)、情報検索入出力手段11は、規定フォームでのメールアドレスを含む連絡先情報の入力を受けて、情報追跡データベース2Aの会員情報テーブル21へ当該連絡先情報を仮登録する(ステップS24)。
【0160】
メッセージ転送手段13は、仮登録のメールアドレスへ確認用メールを送信する(ステップS25)。
【0161】
メッセージ転送手段13は、確認用メールで通知した指定URLへのアクセスを確認する(ステップS26)。
【0162】
メッセージ転送手段13は、アクセスされた指定URLへ対応させたメールアドレスを確認する(ステップS27)。
【0163】
メッセージ転送手段13が会員登録要求者の該当メールアドレスを確認後、情報検索入出力手段11は、仮登録のメールアドレスを連絡先として認証して、ユーザーIDを会員登録要求者へ付与する(ステップS28)。これにより、情報検索入出力手段11は、会員情報テーブル21へ会員登録要求者のユーザーIDを登録し、当該ユーザーIDと連絡先情報とを紐付けて、情報追跡データベース2Aに格納する。本処理終了後、会員登録処理を終了する。
【0164】
次に、図19を参照しながら、情報追跡装置1Aに用いられるアルファID登録処理フローについて説明する。
【0165】
情報検索入出力手段11は、利用者端末4からアルファID登録ページオープンの要求処理を受けて、アルファID登録ページメニューに関する表示データ等を送信する(ステップS31)。
【0166】
続けて、情報検索入出力手段11は、アルファIDを登録するか否かの要求を待つ(ステップS32)。
【0167】
アルファIDを登録する要求の場合には(ステップS32 Yes)、情報検索入出力手段11は、アルファIDテーブル22に基づいて、新規のアルファIDを付与する(ステップS33)。
【0168】
情報検索入出力手段11は、新規のアルファIDと対応付ける登録対象となる媒体、物等の項目内容を含む開示情報の入力を受ける(ステップS34)。なお、この他にも、開示情報として、自宅電話番号、携帯番号、住所等の個人情報を開示するための入力を受け付けてもよく、後の処理(変更・修正メニュー等)で、入力を受け付けてもよい。
【0169】
情報検索入出力手段11は、入力された内容を登録するか否かの要求を待つ(ステップS35)。入力内容を登録しない場合には(ステップS35 No)、本アルファID登録処理を終了する。
【0170】
一方、入力内容を登録する場合には(ステップS35 Yes)、情報検索入出力手段11は、新規のアルファIDと対応付ける登録対象となる媒体、物等の項目内容を含む開示情報を登録する(ステップS36)。
【0171】
続けて、情報検索入出力手段11は、他のアルファIDを登録するか否かの要求を待ち、他のアルファIDを登録する要求の場合には(ステップS37 Yes)、ステップS33の処理へ戻す。一方、他のアルファIDを登録しない場合には(ステップS37 No)、本アルファID登録処理を終了する。
【0172】
アルファIDを登録しない要求の場合には(ステップS32 No)、情報検索入出力手段11は、アルファIDテーブル22に基づいて、登録会員のユーザーIDに紐付けられた既登録のアルファIDを選択する(ステップS38)。
【0173】
情報検索入出力手段11は、選択されたアルファIDと対応付けられた項目内容を含む開示情報の変更等を受け付ける(ステップS39)。
【0174】
アルファIDと対応付けられた項目内容の変更を要求しない場合には(ステップS310 No)、情報検索入出力手段11は、本アルファID登録処理を終了する。
【0175】
アルファIDと対応付けられた項目内容の変更を要求された場合には(ステップS310 Yes)、情報検索入出力手段11は、選択されたアルファIDと対応付けられた項目内容を含む開示情報を変更して、登録する(ステップS311)。
【0176】
続けて、情報検索入出力手段11は、他の既登録アルファIDと対応付けられた項目内容を変更するか否かの要求を待ち、他の既登録アルファIDと対応付けられた項目内容を変更する要求の場合には(ステップS312 Yes)、ステップS38の処理へ戻す。一方、他の既登録アルファIDを変更しない場合には(ステップS312 No)、本アルファID登録処理を終了する。
【0177】
次に、図20及び図21を参照しながら、情報追跡装置1Aに用いられるメールアドレス登録処理フローについて説明する。
【0178】
情報検索入出力手段11は、利用者端末4からメールアドレス登録ページオープンの要求処理を受けて、メールアドレス登録メニューに関する表示データ等を利用者端末4へ送信する(ステップS41)。
【0179】
情報検索入出力手段11は、利用者端末4からのメールアドレス登録実行を受けて、メールアドレス入力又は選択を促す表示データ等を送信する(ステップS42)。
【0180】
情報検索入出力手段11は、利用者端末4から通知されたメールアドレスの入力データ又は選択されたメールアドレスの選択データを受信する(ステップS43)。
【0181】
情報検索入出力手段11は、入力データ又は選択データに関するメールアドレスが情報追跡データベース2Aのメールアドレステーブル23に登録されているか確認する(ステップS44)。
【0182】
メールアドレスが登録されている場合には(ステップS44 Yes)、情報検索入出力手段11は、登録されたメールアドレスが仮登録中であるかをメールアドレステーブル23で確認する(ステップS45)。
【0183】
登録されたメールアドレスが仮登録中である場合には(ステップS45 Yes)、ステップS47へ処理を進める。一方、登録されたメールアドレスが仮登録中でない場合には(ステップS45 No)、情報検索入出力手段11は、先に登録した人物から登録許可を受けたか確認する(ステップS46)。なお、本フロー処理例では、「登録許可」は、例えば後述する図26に示すメールアドレステーブル23cの「重複登録」フラグにより判断可能である。また、本フロー処理例では、例えば複数の登録会員のグループ共有、法人の部署等の共有メールアドレスを複数人で共同管理する場合の例であり、その各々が共同管理者となる場合である(図37に示すような管理権の変更など)。
【0184】
先に登録した人物から登録許可を受けた場合には(ステップS46 Yes)、ステップS48へ処理を移す。一方、先に登録した人物から登録許可を受けていない場合には(ステップS46 No)、ステップS47へ処理を進める。
【0185】
情報検索入出力手段11は、当該メールアドレスを登録不可として利用者端末4へ通知する(ステップS47)。登録不可を通知後、本メールアドレス登録処理を終了する。
【0186】
一方、メールアドレスが登録されていない場合には(ステップS44 No)、情報検索入出力手段11は、当該メールアドレスをメールアドレステーブル23へ仮登録中として記録する(ステップS48)。
【0187】
メッセージ転送手段13は、当該メールアドレス宛に仮登録された旨のメーセージ及びその確認を促すためのアクセス先である指定URLを含んだメールを送信する(ステップS49)。
【0188】
メッセージ転送手段13は、指定URLへのアクセスを確認した後、会員登録要求者の当該メールアドレスを正規のメールアドレスであると確認する(ステップS410)。
【0189】
メッセージ転送手段13による確認を受けて、情報検索入出力手段11は、登録者がメールアドレスの所有者であると判断する(ステップS411)。
【0190】
情報検索入出力手段11は、当該メールアドレスを仮登録から本登録へとメールアドレステーブル23の登録状態に関する項目を書き換える(ステップS412)。
【0191】
さらに、情報検索入出力手段11は、当該メールアドレスに関する登録情報に付随する情報の入力を受けて、メールアドレステーブル23を更新する(ステップS413)。
【0192】
続いて、当該登録情報に関する開示情報について開示請求があった場合に設問を提示する設定でないとき(ステップS414 No)、ステップS416へ処理を進める。
【0193】
一方、開示請求があった場合に設問を提示する設定であるとき(ステップS414 Yes)、情報検索入出力手段11は、当該メールアドレスの開示情報に該当する認証設問データを紐付けるために、メールアドレステーブル23へ紐付ける設問IDを保存する(ステップS415)。
【0194】
続いて、開示請求者からメッセージを受け取る設定でない場合に(ステップS416 No)、ステップS418へ処理を進める。。
【0195】
一方、開示請求者からメッセージを受け取る設定である場合に(ステップS416 Yes)、情報検索入出力手段11は、入力されたメッセージ転送先をメールアドレステーブル23へ保存する(ステップS417)。
【0196】
続けて、当該メールアドレスの開示情報を現時点で公開する場合に(ステップS418 Yes)、情報検索入出力手段11は、公開可否属性を「公開」としてメールアドレステーブル23へ保存する(ステップS419)。本処理終了後、メールアドレス登録処理を終了する。
【0197】
一方、当該メールアドレスの開示情報を現時点で公開しない場合に(ステップS418 No)、情報検索入出力手段11は、公開可否属性を「非公開」としてメールアドレステーブル23へ保存する(ステップS420)。本処理終了後、メールアドレス登録処理を終了する。
【0198】
次に、図22及び図23を参照しながら、情報追跡装置1Aに用いられる認証設問作成登録処理フローについて説明する。
【0199】
情報検索入出力手段11は、利用者端末4から登録会員ページオープンの要求処理を受けて、登録会員ページに関する表示データ等を利用者端末4へ送信する(ステップS51)。
【0200】
さらに、情報検索入出力手段11は、利用者端末4から認証設問管理ページの要求処理を受けて、認証設問管理ページに関する表示データ等を利用者端末4へ送信する(ステップS52)。
【0201】
情報検索入出力手段11は、利用者端末4から認証設問管理ページメニューにある認証設問タイプの選択を受けると、選択された各々の処理へ進める(ステップS53)。
【0202】
一問複答型設問が選択された場合、設問回答作成手段14は、一問複答型設問メニューの表示データ等を利用者端末4へ送信する(ステップS541)。
【0203】
設問回答作成手段14は、情報検索入出力手段11を介して、利用者端末4から設問文の入力データを受ける(ステップS542)。
【0204】
次に、設問回答作成手段14は、利用者端末4から正答とする文字列の入力データを受ける(ステップS543)。
【0205】
次に、設問回答作成手段14は、利用者端末4から正答の配点の入力データを受ける(ステップS544)。
【0206】
択一型設問が選択された場合、設問回答作成手段14は、択一型設問メニューの表示データ等を利用者端末4へ送信する(ステップS551)。
【0207】
設問回答作成手段14は、利用者端末4から設問文の入力データを受ける(ステップS552)。
【0208】
次に、設問回答作成手段14は、利用者端末4から正答とする文字列の入力データを受ける(ステップS553)。
【0209】
次に、設問回答作成手段14は、利用者端末4から誤答とする文字列の入力データを受ける(ステップS554)。
【0210】
次に、設問回答作成手段14は、利用者端末4から正答及び誤答の配点の入力データを受ける(ステップS555)。
【0211】
複数選択型設問が選択された場合、設問回答作成手段14は、複数選択型設問メニューの表示データ等を利用者端末4へ送信する(ステップS561)。
【0212】
設問回答作成手段14は、利用者端末4から設問文の入力データを受ける(ステップS562)。
【0213】
次に、設問回答作成手段14は、利用者端末4から正答とする文字列の入力データを受ける(ステップS563)。
【0214】
次に、設問回答作成手段14は、利用者端末4から誤答とする文字列の入力データを受ける(ステップS564)。
【0215】
次に、設問回答作成手段14は、利用者端末4から正答及び誤答の配点の入力データを受ける(ステップS565)。
【0216】
設問回答作成手段14は、引き続き、利用者端末4から認証設問作成の要求があると(ステップS57 Yes)、処理をステップS53へ戻す。一方、利用者端末4から認証設問作成が終了すると(ステップS57 No)、処理をステップS58へ進める。
【0217】
設問の順序を入れ替え要求があると(ステップS58 Yes)、設問回答作成手段14は、設問の入れ替えの選択を受け付ける(ステップS59)。一方、設問の順序を入れ替え要求がないと(ステップS58 No)、処理をステップS510へ進める。
【0218】
設問回答作成手段14は、開示情報に設定された設問の全問正解時の得点を算出し、表示データとして利用者端末4へ送信する(ステップS510)。
【0219】
次に、設問回答作成手段14は、利用者端末4から認証基準点の点数設定を受け付ける(ステップS511)。
【0220】
次に、設問回答作成手段14は、利用者端末4から作成した設問に対するタイトル・名称等の入力データを受け付ける(ステップS512)。
【0221】
設問作成の登録要求後に、情報検索入出力手段11は、設問回答作成手段14により作成された設問について設問IDを付与し、ユーザーID共に紐付けて、これらの設問に関するデータを認証設問データテーブル24へ保存する(ステップS513)。本処理終了後、認証設問作成登録処理を終了する。
【0222】
以上のような処理フローは、図1のシステム構成の一例において、情報追跡装置1Aがアプリケーションサーバとして動作する場合における処理ステップにも対応するものである。
【0223】
以上説明したように、本発明によれば、過去の時点で記載された各種情報の鮮度が劣化した場合に、更新情報を追跡(検索・抽出)できなくなることを防ぐことができる。また、情報の開示請求者が同一システム上の会員となることを必要とせず、かつ両者間で相互に本人確認を行い、開示者が意図しない人物には情報が開示されないよう開示制限機能を設けることができ、情報漏えいの危険性を最小限に抑えることができる。
【0224】
また、例えば名刺等の紙媒体はもとより、電磁的記録を含むあらゆる物体に記された、あるいは音声として記録された「過去の情報」をもとに、更新情報を抽出するソフトウェア技術であると同時に、同一システムのメンバー(会員)間でなくとも、更新情報を開示すべき相手を限定した上で当該情報の開示を可能とすることができる。
【0225】
以上説明したように、本実施形態の情報追跡装置、情報追跡方法および情報追跡プログラムによれば、情報を開示すべき相手を限定した上で当該情報を開示することができる。
[第2の実施形態]
以下、本発明に係る情報追跡装置の第2の実施形態の構成について、図24を用いて説明する。ここで、図24に示す情報追跡装置1Bは、図1に示す情報追跡装置1Aのハードウェア構成の一例を示すブロック図である。
【0226】
図24に示すように、情報追跡装置1Bは、例えばCPU(Central Processing Unit)101、ROM(Read Only Memory)102、RAM(Random Access Memory)103、HDD(Hard Disk Drive)104、CD/DVD−ROM(Compact Disk/Digital Versatile Disk ROM)105、キーボード106、マウス107、モニタ108、インタフェース109、情報追跡データベース2Bを備えるコンピュータである。
【0227】
CPU101は、情報追跡装置1Bに備えられた電源の投入後等の起動時に、ROM102に記憶された起動プログラムに基づいて、ブート処理を開始する。ROM102は、CPU101の起動用プログラム等を記憶(格納)するメモリである。
【0228】
CPU101は、起動後、HDD104又はCD−ROM105等から情報追跡装置1Bのアプリケーション(情報追跡装置プログラム)を読み込み、読み込んだアプリケーションをRAM103等へ記憶する。RAM103は、CPU101の主メモリ(記憶装置)であり、CPU101がアプリケーションを実行する際に、主メモリの他、ワークエリア等として用いる。一つのアプリケーションは、CPU101、RAM103等を情報追跡装置1Bとして動作させるプログラムである。
【0229】
CPU101、RAM103等は、このアプリケーションに従い、図1に示した各々の手段の処理を実行する。このコンピュータにインストールされ実行されるアプリケーションにより、図1に示す情報追跡装置1Aの各手段の処理が実現されて、コンピュータが備えるハードウェアと協働することによって、情報追跡装置1Bとして動作する。
【0230】
HDD104は、例えばハードディスク装置である。HDD104は、例えばオペレーティングシステム(OS)ソフト、ブラウザソフトなどの基本ソフトウェアや、情報追跡処理プログラム、履歴データなどの各種データを記憶する。なお、HDD104は、例えば不揮発性のシリコンディスク等の他の記憶装置であっても良い。
【0231】
CD/DVD−ROM105は、CD−ROM、DVD−ROM/RAM等の媒体に記録されたアプリケーション、各種データ等を読込むためのドライブ装置である。なお、CD/DVD−ROM105は、DVDやUSBメモリ(Universal Serial Busflash drive)等の他の記録媒体を読込むためのドライブ装置であっても良い。
【0232】
インタフェース109は、コンピュータとインターネット9とのアクセスや、サーバ3などとのアクセスを仲介する。すなわち、インタフェース109は、コンピュータと外部装置等との入出力のデータ転送を実現する。
【0233】
キーボード106、マウス107は、必要に応じて、情報追跡システムのオペレータが情報追跡装置1Bに入力操作、起動操作などを行う際に用いられる。モニタ108は、情報追跡装置1Bの運用状態を確認、運用・保守などのためのデータ入力・設定などの際に用いられる表示装置である。
【0234】
なお、情報追跡データベース2Bは、サーバ3、他の記憶装置等に備えられたデータベースであっても良く、また、情報追跡装置1Bがネットワーク(LAN)を介して、情報追跡データベース2Bにアクセスする構成であっても良い。
【0235】
以上説明したように、本実施形態の情報追跡装置、情報追跡方法および情報追跡プログラムによれば、情報を開示すべき相手を限定した上で当該情報を開示することができる。
【0236】
[第3の実施形態]
本発明に係る情報追跡システムの第3の実施形態について、図25乃至図39を用いて説明する。ここで、図25は、本発明に係る情報追跡装置の第3の実施形態の構成を示すブロック図である。図26は、図25に示す情報追跡データベース2Cのテーブル構成の一例を示す図である。また、図27乃至図38は、図1に示す利用者端末4の表示画面に表示されるメニュー画面等の一例である。なお、図39は、音声データ等の非可逆圧縮モード特性の例を示す図である。
【0237】
第3の実施形態の情報追跡装置1Cは、情報追跡データベース2Cを検索・登録・更新等のアクセス処理可能に管理する。情報追跡装置1Cは、図25に示すように、情報検索入出力手段11cと、設問提示認証手段12cと、メッセージ転送手段13cと、設問回答作成手段14cと、私書箱管理手段15cとを備えている。また、情報追跡データベース2Cは、図25及び図26に示すように、その中に会員情報テーブル21cと、検索対象主情報を含むアルファIDテーブル22cと、メールアドレステーブル23cと、認証設問データテーブル24cと、アルファフォルダテーブル25cとを有する。
【0238】
なお、以降では、第3の実施形態の情報追跡装置1Cについて、第1の実施形態の情報追跡装置1Aと相違する点を主に説明する。具体的には、メッセージ転送手段13c、私書箱管理手段15c及び情報追跡データベース2Cに関する相違点の構成と、それらの機能について説明する。
【0239】
本実施形態の情報追跡システムでは、情報追跡データベース2Cには、登録会員ごとに、登録会員が利用した又は利用している複数のメールアドレスの使用又は不使用の状態を登録可能である。具体的には、図26に示すメールアドレステーブル23cに格納される「Type」に、登録会員が利用した又は利用している複数のメールアドレスの使用又は不使用の状態について登録可能とされる。以降では、主に図27(b)に示すメールアドレスの使用状態による登録タイプ「TypeA」、「TypeB」及び「TypeC」について説明する。
【0240】
以下、はじめに、図27に示す「検索対象主情報:メールアドレス」の新規登録に関する利用者端末4の表示画面に表示されるメニュー画面等の一例を参照しながら説明する。例えば、登録会員端末41において、「検索対象主情報:メールアドレス」の新規登録として、以下のような操作を行う。
【0241】
1.情報追跡システムのマイページ(http://**略**/mypage/mailpot/mmail_list)にて、例えば図27(a)に示すような表示画面において、ログイン操作が実行される。
【0242】
2.登録会員は、図27(b)に示すように、登録会員端末41を介してメールアドレスの新規登録を行う。
【0243】
3.登録会員は、図27(b)に示すようなメールタイプから、追加したいメールアドレスを入力する。例えば、以下のようなメールタイプの登録が可能である。
(1)TypeAメールアドレス
情報追跡システムに登録した時点で利用しており、システム側からメールの受信を確認できたメールアドレスである。本アドレスタイプの登録は、システム側からの指定メールアドレスへ確認メールを送信して、その確認メール中の所定のリンク先へアクセスされた場合に登録される。
(2)TypeBメールアドレス
情報追跡システムに登録した時点で利用権を有しておらず、新たなメールの受信を確認できないメールアドレスである。過去に利用していたことを自ら宣言しつつも、その事実を証明できない場合である。
(3)TypeCメールアドレス
メールの送受信を行うことができない仮想のメールアドレスである。情報追跡システム内では、TypeAと同様に、システム内では所定の機能のために活用することができる。
【0244】
4.登録会員は、マイページにて、登録済みメールアドレス一覧にて登録したメールアドレスがリストにあるかを確認できる。
【0245】
また、登録会員は、情報追跡システムに登録した後で、登録したメールアドレスを「検索対象主情報:メールアドレス」から削除したい場合には、以下のような作業により、削除することができる。
1.登録済みメールアドレス一覧(TypeA)
http://**略**/mypage/mailpot/mmail_list
2.削除したいメールアドレスの設定画面を開く
3.設定画面の最下段「管理権の変更」で、「管理権の放棄」ボタンを押下
4.設定画面で「放棄する」ボタンを押下
これにより、情報追跡システムに「検索対象主情報:メールアドレス」として、当該メールアドレスを削除することができる。すなわち、図26に示す情報追跡データベース2Cのうちのメールアドレステーブル23cから当該メールアドレスを削除することができる。
【0246】
メールアドレステーブル23cには、図26に示すように、メールアドレスごとに、前述した所定の使用状態によるタイプの属性(TypeA、TypeB及びTypeC)に区分可能に格納される。αID登録前の時点での情報追跡としては、メールアドレスによる情報追跡を可能とするためである。これにより、登録会員は、αID登録前での情報追跡をメールアドレスにより可能として、αID登録後では、少なくともαID及びメールアドレスのいずれか一方で、情報追跡を可能とすることができる。
【0247】
(メールタイプの仕様)
各個人が過去に使用していたメールアドレス情報を収集する。メールアドレスの使用権が消滅したのち、あるいは個人的な事情で利用を中止したのちも、その事情を他者が確認できるようにするための仕組みである。
【0248】
情報追跡システムへのメールアドレスの登録に際しては、当該メールアドレスの使用権がユーザー自身にあると証明する必要がある。しかしこの場合には、逆説的に、情報追跡システムへの登録以前に使用権を失ったメールアドレスについては情報を登録できないことになる。
【0249】
そこで、本情報追跡システムへの登録時点において利用中であることを証明できるメールアドレスを「TypeA」とし、また証明できないものの、過去に使用していたことをユーザー自身が宣言するメールアドレスを「TypeB」と呼称して管理する。
【0250】
メールを送った相手から返信がない。このような場合、そのアドレスを相手が既に使用していない可能性がある。しかしこの事情は現状、電話など電子メール以外の方法を使わなければ確認できない。ところが当該アドレスを情報追跡システム上で検索し、何らかの情報を抽出できれば事情の把握が可能となる。さらにこの情報に転送先が設定されていれば、相手の新しいアドレスを知ることなく、メッセージを送信することが可能となる。
【0251】
情報追跡システムで検索・抽出できたメールアドレス情報が、「TypeB」であった場合、その情報の信憑性には疑問符が付くことになる。なぜなら「TypeB」は、当該アドレスの使用事実を証明することなく情報追跡システムに登録できるものであるためである。よって、抽出した情報が「TypeB」由来のものであれば、表示される情報にはその旨が明記される。
【0252】
「TypeB」由来の情報を基に、送信者の個人情報を含むメッセージを送ることにはリスクが生じる。そこで送信者はメッセージを暗号化し、相手の素性が確認されなければ内容を開示しないという手段を用いることができる。この手段が秘匿メッセージ機能である。
【0253】
例えば、昨今では個人情報保護の観点から、卒業名簿に卒業者の個人情報が記載されない。これが同窓会の開催をも困難にしている。この問題は卒業生が現在使用中のメールアドレスを情報追跡システムに登録し、これを名簿に記載すれば解決できる。
【0254】
ところが学生によっては、現在使用中の個人のメールアドレスを名簿作成のためだけに情報追跡システムへ登録したくない場合もある。このような事情を鑑みれば学校側は、学校が各生徒・学生に与えている公式のメールアドレスを登録させるのが相当である。
【0255】
しかし、一方で、学生にメールアドレスを与えていない学校の場合は、名簿作りのためだけにメールアドレスを発行しなければならないことになる。しかもメールアドレスを発行しても当該の学生が卒業すると同時に、その利用権ははく奪せざるを得ない。つまり、この作業は煩雑であるばかりで、大きな意味をなさない。そもそも情報追跡システムへの登録は一意の文字列を必要とするためであるから、メールボックス機能の存在が重要なわけではない。ならばメールボックスを有しない、つまりメールアドレスとしては機能しない、文字列のみのメールアドレスを情報追跡システムが生成すれば解決する。
【0256】
例えば、学生が情報追跡システム上のマイページで仮想のメールアドレス「TypeC」の発行手続きを行い、ここで生成されたメールアドレスを名簿に掲載する。この仮想アドレスはメールボックスを有しないためユーザー本人による利用の確認ができない。
【0257】
しかしながら、ユーザー本人のマイページ上で発行されたものであるため、情報追跡システム上においては、本人確認が完了したものと判断できる。これにより、「TypeB」と「TypeC」は、同様にメールを受信できないものであるが、本人確認が完了しているという点で似て非なるものと言える。「TypeC」のアドレスは「TypeA」と同様に管理できるが、「TypeA」とは異なり権利譲渡ができないなどの制限がある。
【0258】
(メリット)
<現状の確認>
メールアドレスの変更に際しては、知人に宛て「メールアドレス変更のお知らせ」などといった案内を送信するのが一般的であるが、当該アドレスを知るすべての人物に伝えるのは困難である。
【0259】
メールアドレスの変更・消滅事実を知らない人物が当該アドレスにメールを送信した際、メールアドレスが存在しないことを示す「MAILER−DAEMON」、または「Mail Delivery Subsystem」といった返信が自動的になされれば状況を理解しやすい。しかしメールアドレスが消滅しない無料のメールサービスなどの場合には、このようなメッセージすら返信されない。結果的に、メールを送っても返信されない状況は「無視」と同義であり、人間関係に亀裂が入りかねない。業務用のメールアドレスであれば顧客の信頼を失いかねない。情報追跡システムのメールアドレス登録機能は、このような問題を回避するものである。
【0260】
<メールアドレス使用権者の特定>
多くの場合、メールアドレスは事業者から貸与されるものである。そしてその事業者とのサービス契約が解除される、あるいは組織から離脱すれば、そのメールアドレスの使用権を失う。ここで問題となるのは、使用権を失ったメールアドレスの「その後」である。場合によっては他の人物が引き続き利用することもある。
【0261】
携帯電話会社がサービス利用者に提供するメールアドレスにも、使い回しされるものが多い。例えば、2010年から2年間、携帯電話契約者Aによって利用されたメールアドレス「aaa@bbb.ne.jp」を想定する。携帯電話契約者Aが電話契約を他のキャリアに乗り換えると当然、当該アドレスも消滅する。この一度消滅したアドレスは他の使用者がいない限りにおいて、他のユーザーが使用可能となる。つまり、2010年〜2012年までは「aaa@bbb.ne.jp」を携帯電話契約者Aが、2014年からは異なる携帯電話契約者Bが使用するといった状況が発生しうる。
【0262】
この事実から、携帯電話契約者Aの知人Xが携帯電話契約者Aに宛てて送ったメッセージを、携帯電話契約者Bが受け取る状況は十分に発生しうる。携帯電話契約者Bに悪意がある場合に、携帯電話契約者Aとして「成りすまし」を行えば、知人Xと携帯電話契約者Aの利益を損ないかねない。よってメールアドレスは、その使用者が知人であることを常に判断できる状態であるべきである。
【0263】
これは携帯メールにとどまらない。企業のメールアドレスも同様である。従業員が退職すると、そのメールアドレスを他の社員、あるいはシステム管理者がこれを引き継ぐ。この事実を知らない顧客が個人情報を記載したメッセージを送信すると、意図しない担当者がこれを読んでしまう可能性を否定できない。特定の担当者を信頼して明かした個人情報が、信頼度不明の人物にわたることは当然にも危険性を孕む。情報追跡システムのメールアドレス登録機能は、このような問題を回避するものである。
【0264】
前述のように、メールアドレスの新ユーザーが旧ユーザーに成りすます危険もさることながら、新ユーザーが旧ユーザーの存在を意図することなく、利用を開始する可能性もある。新たなメールアドレスを利用し始めたユーザーCは、この事実を知人らに連絡してコミュニケーションを再開する。しかし利用し始めると、旧ユーザーに関連したスパムメールを大量に受け取る可能性を否定できない。これにより当該メールアドレスの利用を断念することになれば、改めて知人への案内が必要となってしまう。
【0265】
利用しようとしたメールアドレスについて、過去に誰かが使っていたのか否かを確認する手段は、現状で存在しない。送信したメールが意図しない人物に届くこと、また意図しない人物からメールが届くことは種々のトラブルを招きかねない。本情報追跡システムのメールアドレス登録機能は、このような問題を回避するものである。なお、同様の問題は電話番号を登録機能に加えた場合にも同様なことが言える。情報追跡システムにおいて、例えば電話番号の登録機能の際に、発信と着信側が「#」等の複数の特定キーを押下することにより、電場番号の登録認証も可能となる。
【0266】
(アルファIDの基本仕様)
図28及び図29に、アルファIDの設定機能等に関する利用者端末4に表示される表示画面例を示す。例えば、図28は、利用者端末4に表示されるアルファID登録に関する登録画面例を示す図である。また、図29は、利用者端末4に表示されるアルファID一覧リストに関する表示画面例を示す図である。
【0267】
本情報追跡システムにおいて、登録会員として会社等の法人や、その他の団体などの組織の場合に、そのなかの部署、課、グループ等の代表者をアルファIDにより特定することも可能である。また、グループは複数のメンバーで構成されるものであるが、状況によってはメンバーが変更されることもある。例えばバンドAAAのファンが、「2015年のギタリストにアクセスしたい」というような場合、その追跡はさらに難しい。
【0268】
ところが、αIDにリスト機能が存在することにより、全メンバーの追跡情報(αID)を、グループの情報(αID)に紐付けすることができる。つまりチーム・グループの情報追跡でありながら、同時にグループを構成する個人をも追跡できる機能を有する(追跡情報の連鎖)。もちろん、ショップカードのようなものばかりでなく、作品パッケージやCD・本題などにαIDを刻印するなどの用途が考えられる。
【0269】
<アルファIDのフォルダ機能>
アルファIDのフォルダ機能とは、例えばあることを対象とした場合の関連する複数のアルファIDを集約するための格納機能である。本実施形態の情報追跡システムにおいて、登録会員に対してαIDは一人に一つとの制限はない。用途に合わて一人の人間、一つの企業、一つの組織が、各々複数のαIDを併用することができる。個人の場合では、例えば仕事用、対友人用、子供関連用(保護者として)、ネット上での活動用、所持品への記載用などとして、それぞれのαIDが、異なる情報の追跡の実現を可能とする。
【0270】
図26に、一つのアルファIDに対して異なる他のアルファIDとを紐付ける機能について説明する。図26に示すアルファフォルダテーブル25cには、ユーザーIDと紐付けられる一つのアルファIDについて、他の異なるアルファIDが紐付けられている場合に、リスト項目においてその紐付けられた他のアルファIDが格納される。
【0271】
例えば、図26に示す例では、「ユーザーID=9」の登録会員のアルファID「FFFFFFFFFFFF」について、リスト名称「知人一覧」とされる「AAABBBCCCDDDDDDA」、「AAABBBCCCDDDC」、・・・等のアルファIDがリストとして格納される。このリスト名称「知人一覧」は、公開属性(status)が「公開」であり、設問IDは空であるため認証設問は設定されずに公開される。
【0272】
また、図26に示す例で、「ユーザーID=9」の登録会員のアルファID「HHHHHHHHHHHH」について、リスト名称「取引先」とされる「ZZZZZZZZZZZZ」、「YYYYYYYYYYYY」・・・等のアルファIDがリストとして格納される。このリスト名称「取引先」は、公開属性(status)が「公開」であり、設問ID=3であるため、認証設問データテーブル24cにおける設問ID=3の認証設問において、認証点を75点以上とることが公開される条件とされている。
【0273】
ここで、図30及び図31に、アルファIDのフォルダ機能に関する利用者端末4に表示される表示画面例を示す。例えば、図30に利用者端末4に表示されるアルファIDフォルダ機能に関する設定画面例を示す。また、図31に利用者端末4に表示されるアルファIDの開示情報に関する表示画面例を示す。
【0274】
<アルファIDのジャンプ機能>
大量のαIDを保有すると開示情報を含む大量の登録情報を管理しなければならなくなる。しかし、これでは作業が煩雑すぎるため、更新を怠る原因になりうる。そこで、情報追跡システムのαIDには、後述するような「ジャンプ機能」(図26に示すアルファIDテーブル22cの「ジャンプid」に対応)を実装可能である。
【0275】
例えば、図4に示すような例で、勤め先の仕事用名刺として用いた会社員用αID#1、大学時代の知り合いに配布した個人名刺の大学時代の知り合い用αID#2、趣味のサークル等での知り合いに配布した名刺などの地域のサッカークラブ用αID#3という風に、異なるαIDを用いていると仮定する。本来であれば、これらすべてのαIDに対して更新情報を作成しなければならないが、本実施形態の情報追跡システムにおいて、公開すべき内容に違いがない場合には、どのαIDを検索しても同一の情報を表示させることができる。
【0276】
例えば次のような3種類のαIDの場合、
(a)会社員用αID#1:AAAA−AAAA−AAAA−AAAA
(b)大学時代の知合い用αID#2:BBBB−BBBB−BBBB−BBBB
(c)地域サッカークラブ用αID#3:CCCC−CCCC−CCCC−CCCC
例えば、これらに付随する(データベース上で紐付けられる)開示情報を、情報追跡システム上で、必ずしも各々作成する必要はない。例えば、ジャンプ機能として、ユーザーID及びアルファIDとに対応する、ジャンプ先のアルファIDが「ジャンプid」に格納される。
【0277】
図26に示すアルファIDテーブル22cの「ジャンプid」が設定されると、(a)、(b)、(c)のどれを検索しても、同一の開示情報を表示する。例えば(a)へのジャンプを設定すると、(b)や(c)のαIDを検索しても(a)の開示情報が表示される。これで、更新の手間は3分の1となる。ただし(b)のαIDを検索した人物にはAAAA−AAAA−AAAA−AAAAのαIDは表示されず、あくまでBBBB−BBBB−BBBB−BBBBの情報であると認識される。
【0278】
一方、このような利用方法を続けながらも何らかの理由で、のちに、例えば「IT業の会社員時代で知り合った相手には最新の詳細情報を開示したくない」といった事情が発生する場合もある。この場合には、(b)のジャンプ機能を解除し、(b)固有の開示情報を開示するように変更する。このように、のちの変化する事情により相手に対して異なる情報を開示することができる。
【0279】
<秘匿メッセージ機能>
過去に利用していたメールアドレスの情報を公開する者(情報追跡システムの登録会員)は、公開情報を基に転送メールを受け取ることができる。しかしその転送メールが「誰でも送れる」という状況にあると、これは新手のスパムメールと変わらないことになる。そこで、送信できる者を限定するのが前述した「認証設問」である。
【0280】
認証設問によるセキュリティの強さは、ユーザー自身が作成した設問の精度・練度に依存する。また、模範回答がネット等に漏えいしても、ユーザーは設問内容を随時変更することで対応できる。認証設問の模範回答が公知になった状態で転送メールを受信した場合、その送信者の身元は確かでない。よって、この転送メールに対して、個人情報を含むメッセージを返信することにはリスクを伴う。
【0281】
このような問題に対しては、前述したような認証設問を利用して「秘匿メッセージ」を用いることによって解決できる。返信するメッセージの内容を認証設問により秘匿化し、これを返信する。返信先、すなわち返信の受信者は、改めて送信者の認証設問に挑戦し、合格点(認証境界点)に達しなければメッセージを読むことができない。
【0282】
さらに、「秘匿メッセージ」には有効期限を設けることができ、有効期限が過ぎるとメッセージデータ自体が消去される。何十回、何千回と試せば突破できる設問内容であったとしても、この有効期限により力技での突破は困難となる。さらに、秘匿メッセージは、認証設問が突破され、メッセージ内容が開示される時点で「開示日時」が記録される。また「開示日時」は開示されるごとに記録される。例えば、情報追跡データベース2Cに、これらの秘匿メッセージに関する有効期限、開示日時、開示請求先(メール返信先)等が記録され、更新される。
【0283】
以上説明したように、メッセージ転送手段13cは、以下のような機能を有する。
・メーセージの日時限定機能
・メーセージの秘匿機能(設問の採点結果パス後の本メーセージ提示)
【0284】
情報追跡装置1Cでは、図26に示すように、メールアドレスごとに所定の使用状態により異なるタイプの属性に区分可能である。例えば、登録会員が登録前の場合にはαIDを発行しないため、αID登録前の時点での情報追跡としては、メールアドレスによる情報追跡を可能とするためである。これにより、αID登録前での情報追跡をメールアドレスにより可能として、αID登録後では、少なくともαID及びメールアドレスのいずれか一方で、情報追跡を可能とすることができる。
【0285】
<私書箱機能>
私書箱管理手段15cは、所定の私書箱ごとに、利用者端末4からメッセージを受け付けて、受け付けたメッセージについて、開示の有無、開示期限等を管理する。
【0286】
私書箱管理手段15cは、情報追跡システムの私書箱はメールアドレスを持たない人のための、メールアドレス互換サービスではない。特定の日時等の時間限定で利用するための、メッセージ受信専用の記憶・管理機能である。また、私書箱に投函されたメッセージは、指定されたメールアドレスに自動転送される。
【0287】
ここで、図32に利用者端末4に表示される私書箱に関する設定画面例を示す。また、図33に利用者端末4に表示される私書箱へのメッセージ入力に関する表示画面例を示し、図34に利用者端末4に表示される私書箱に関するメッセージ通知例等を示す。
【0288】
私書箱管理手段15cは、例えば私書箱は「支店(地域センター)名+私書箱No.」で区分する所定の記憶領域を有して、当該私書箱を管理構成する。また、私書箱は国・グループごとに性質が異なるように構成してもよい。例えば、都市別の場合は次の通りである。
アメリカ …… 最大利用期間 9日
ドイツ …… 最大利用期間 15日
日本 …… 最大利用期間 3日
例えば、支店(地域センター)名は国ごとではなく都市ごとに発生する。都市毎に存在できる私書箱数は制限されており、上記の場合、ニューヨーク、ベルリン、秋葉原の各支店には各々、例えば約10万個の私書箱が存在する。
【0289】
新たな私書箱が登録されるごとに残数が減り、残数が0になると新たな都市センターが発生する。例えば、現在設定されている日本の私書箱センターは次の通りで、各々約10万個の私書箱を有する。私書箱を有する登録会員は、最大利用機関の範囲内に限り私書箱を自由に、何回でも公開できる。
【0290】
公開された私書箱は、情報追跡システムトップページの「私書箱」検索ボックスに、私書箱Noを入力することで検索できる。検索の結果、同一のNoを持つ私書箱が複数公開されている場合は、私書箱センターごとに選択肢が表示される。私書箱の公開時にも認証設問を設置できる。認証設問として、例えば「合言葉」を設定して、その「合言葉」を設問として利用することが可能である。
【0291】
私書箱の最大利用期間を終了し利用不能となった後も一定期間、当該私書箱はマイページから消滅しない。マイページから消滅する日を撤去期限と呼ぶ。一人のユーザーが同時に保有できる私書箱数には制限があり、所有数には撤去期限に達していないものも算入される。利用期間終了日から撤去期限までの日数は私書箱センター(仮想設定としての国又は地域)ごとに異なるが、最大利用期間が長いほど撤去期限までの日数も長い。したがって、必要以上に長い利用期間を持つ私書箱を開設すると、長期にわたって私書箱の再開設が制限される。
【0292】
(メリット)
インターネット上にある匿名の公開討論の場では、討論者個々人が個人の連絡先を交換する術がない。匿名討論の場には、匿名性があるからこそ踏み込める議題・領域がある。また匿名であるからこそ同一の悩みを持つ者を、またはそのテーマに関する専門知識を有する者を見出すことが可能な場合もある。しかし、公開・匿名の場であるために、特定の人物同士がプライバシー情報を含む会話を行うことが著しく困難となる。一例をあげれば、特定の趣味・嗜好を持つ者同士のオフ会関連、自殺・いじめ等の救済相談関連、犯罪被害者救済関連等であるが、情報追跡システムの私書箱機能はこれらの問題を解決するものである。
【0293】
また、私書箱は単なるネット上の討論の場のみならず、短期間で終了するイベントの連絡先としても用いることができる。例えば大学サークルの各種募集に関する応募先、あるいはアンケートの送付先など、受信用のウェブサイトを立ち上げるには大掛かり過ぎる場合に有効である。
【0294】
もちろん、従来のように募集要項に送付先としてメールアドレスを記載する運用も可能ではあるが、この場合は募集終了後にもメッセージを受信しかねないし、スパムメールの標的にもなりうる。これに対し、本実施形態の情報追跡システムの私書箱は期間限定であるため、受信者にとっては予期せぬ受信を排除でき、また送信者にとっても応募可能な期間を明確に理解しやすい。
【0295】
<予約メール機能&非常事態設定>
本実施形態の情報追跡装置1Cでは、予約メール機能として未来の日時・時刻等を指定した予約メールを送信することができ、また、非常事態設定機能として緊急事態発生通知メールを送信することができる。図25に示す情報追跡装置1Cにおいて、メッセージ転送手段13cは、図1に示すフォーム出力部131〜処理結果出力部135の機能部に加えて、さらに、予約メール設定部136cと、非常事態設定部137cと、利用状態管理部138cとを有する。
【0296】
上記予約メール機能は予約メール設定部136cにより処理され、また、上記非常事態設定機能は非常事態設定部137cにより処理される。なお、非常事態設定機能とは、予め定めた期間に本情報追跡システムへのアクセス(ログイン)がなければ、緊急事態が発生したとして予め定めた通知先に緊急事態発生した旨のメールを送信する機能である。なお、利用状態管理部138cの機能については、後述する。
【0297】
図35及び図36に、本実施形態の情報追跡システムが備える予約メール機能および非常事態設定の利用者端末4におけるメニュー画面の一例を示す。例えば、図35は、利用者端末4に表示される予約メールに関する編集入力画面例を示す図である。また、図36は、利用者端末4に表示される予約メール等に関する経過状態の表示画面例を示す図である。
【0298】
予約メール設定部136cは、予約メール機能として未来の日時・時刻等を指定した予約メールを送信することができ、また、非常事態設定機能と連携して緊急事態発生した旨の通知メールを送信することができる。
【0299】
非常事態設定部137cは、予め設定された非常事態設定に応じて、予め定めた期間に本情報追跡システムへのアクセス(ログイン)がなければ、登録会員の緊急事態が発生したとして予め定めた通知先に緊急事態発生した旨の通知メールを送信する。
【0300】
例えば、ホームページやブログの更新等では、更新等がしばらくないことが、本人の意思で更新していないのか、または、何らかの不測の事態に陥ったか否かは確認することができない。
【0301】
一方、本情報追跡システムの非常事態設定では、緊急事態発生通知メールを予め設定しておくと、海外旅行・出張等、また事件に巻き込まれた場合等の何らかの不測の事態の際に、スマホや携帯電話等のメールを用いた本人なりすましや、連絡できない等を防ぐことができる。
【0302】
本情報追跡システムの利点として、登録会員の非常事態の設定として、もしもの場合に備える情報伝達を実行できる。登録会員は、予約メールおよび非常事態設定として、以下のような操作を行う。
・予約メール機能は、事前に作成しておいたメールを特定の日に送信する機能である。この「特定の日」は、カレンダー型選択肢の中から選ぶことができる。
・予約メール機能は、単なる日付指定のほか、例えば図36(a)及び(b)に示すような特定の状況が発生したことを条件として、当該予約メールを送信する機能である。
【0303】
なお、例えば以下のような特定の状況を「非常事態」とする。非常事態は、登録会員が情報追跡システムのマイページにログインした最終日時を起点として、どれだけの期間にわたり再ログインしなかったかをもって判断する。基本的な使い方として、最終ログイン日からx日間、x週間、xヵ月間、x年間ログインしなかったことによって、「非常事態」の通知を発動する。「非常事態」の設定に際しては、期間(xの値と日、週などの単位)等を設定する。
【0304】
また、例えば特殊な利用法として、非常事態の発動の起算日を最終ログイン日時ではなく、ユーザー自身が指定する特定の日を設定することができる。例えば「2017年5月1日から18日間」と設定した場合、同日までのログインは不問としつつ、同日以降に18日間以上再ログインしなかった場合に非常事態が発動し、予約メールが送信される。
【0305】
予約メールは未来の時点で送信されるため、予約時点で設定した宛先メールアドレスが、送信実行時点では無効となっている可能性がある。つまり予約を設定する現時点において相手は当該メールアドレスを有しているが、未来の時点では当該メールアドレスの使用権を有しないかもしれない。この場合はいくら送信しても、相手は受け取ることができない。そこで、本情報追跡システムに、予約メール送信先の「自動追跡機能」を実装する。
【0306】
ここで、予約メール送信先の「自動追跡機能」には、後述するような、図25に示す利用状態管理部138cによるメールアドレス管理機能が必要となる。利用状態管理部138cは、図26に示すメールアドレステーブル23cのメールアドレスを管理する。
【0307】
ここで、図37に、利用者端末4に表示されるメールアドレスの利用状態管理画面例を示す。例えば、利用状態管理部138cは、メールアドレステーブル23cのメールアドレスについて、図37に示すように、メールアドレスの利用状態管理画面を利用者端末4に表示させる。図37に示すメールアドレスの利用状態管理画面では、例えば「kosaku@every.jp」というメールアドレスに関する設定ページを表示させている。
【0308】
本情報追跡システムの第一義的な利用目的として、当該メールアドレスを「すでに利用していない」ことを周知することにある。図37に示す「状態」の項目には「利用中」、「非利用」、「所有権消滅」の選択肢があり、それらのいずれかが設定される。これらの設定は、例えば図26に示すメールアドレステーブル23cへ格納される。なお、「非利用」と「所有権消滅」とを区分する理由は、「非利用」と「所有権消滅」では当該メールアドレスにメールを送った際の動きが異なるためである。
【0309】
図37に示す例では、「kosaku@every.jp」というメールアドレスに関する設定が、「状態」が「非利用」であり、「メール転送」を「する」で設定され、「転送先アドレス」が「abcd@tokkyo.jp」で設定されることを示す。また、これらの設定は、図26に示すように、メールアドレステーブル23cの「id=1」かつ「user_id=1」(例では登録会員「特許太郎」)に対応するテーブル上に格納される。
【0310】
(1)非利用アドレス
・メールを送っても返信がない(管理者がメールを開封しないため)。
・システム上は存在しているため、「Mailer Daemon」などのエラーメッセージは返信されない。
・メールアドレスは存在しても、長期間ログインしていないことによって、メールボックスの利用自体が制限されている可能性がある。すなわちエラーメッセージが戻らないのに「届いてもいない」という可能性がある。
・将来的に、相手がメールを読む可能性は残される。
【0311】
(2)所有権消滅アドレス
・メールを送ると、「Mailer Daemon」などのエラーメッセージが返信される可能性がある(アドレスが存在しない場合)。
・当該人物の所有権は消滅。しかし、例えば後任者やシステム管理者がメールアドレスを引き継いでいる可能性がある。なお、この場合、エラーメッセージは返信されない。後任者が管理を怠れば、メッセージも返信されない。
・場合によっては、想定していない人物がメールを開封する可能性がある。
・少なくとも、旧所有者がメールを読む可能性はない。
【0312】
本情報追跡システムでは、現在利用中(=実際に活用中)のメールアドレスを公開することはできず、そもそも公開する意味がない。情報追跡システムにおいて、メールアドレスを公開するということは、ネット上に晒すということである。下手に公開すると、場合によってはスパムメールの攻撃対象にもなり得るためである。
【0313】
よって、公開できるのは現在利用(活用)していないメールアドレス、すなわち「過去に利用していたメールアドレス」ということが安全である。メールアドレスの登録者が「使用を中止した」ということは、当人の『所有権が消滅した』という意味のほか、単純に『利用していない』というだけのアドレスも含まれる。よって、メールアドレスの登録者が「過去に利用していたメールアドレス」として「公開」状態にするには、当該メールアドレスが「非利用」または「所有権消滅」という状態であることを宣言しなければならない。当人がそのメールアドレスを現在も使用中なのか否か、システムからは判断できないためである。
【0314】
すなわち、「当該メールアドレスの使用を中止したことを宣言しなければ当該メールアドレスに関しての情報を公開できない」とは、メールの所有権が本情報追跡システム上で確認されたメールアドレスに関して、その「状態」の設定を「利用中」から、「非利用」または「所有権消滅」に変更することとなる。
【0315】
なお、本情報追跡システムに、前述したTypeA〜TypeCの区分で登録した場合に、すでに所有権が消滅してしまっている、すなわちTypeBとして登録されたメールアドレスの場合、「状態」の設定は「所有権消滅」以外にあり得ないため、その他の選択肢はないことになる。また、仮想メールアドレスであるTypeCもまた、メール受信能力がないため、「状態」の設定選択肢は、「所有権消滅」以外にない。
【0316】
そこで、自動追跡機能では、予約メールの送信を実行する直前に、宛先(送信先)となるメールアドレスが情報追跡システムに登録され、且つ公開されていないかを確認する。登録されたメールアドレスは、使用を中止したことを宣言しなければ情報を公開できない。
【0317】
本情報追跡システムにおいて、検索対象主情報として公開されているということは、すでに検索対象相手が当該メールアドレスを使用していないことを意味する。送信先メールアドレスが情報追跡システム上で公開され、且つ転送先が設定されている場合には、自動的に転送先にもメールを送信する。自動追跡機能により転送先にメールが送信される場合は、たとえ宛先メールアドレスに認証設問が設定されていても、この設問は無効化される。つまり、送信先のメールアドレスに対応した認証設問が設定されていても、これに認証設問を合格することなくメール転送が可能となる。
【0318】
そもそも、メール転送に係る認証設問を設置するには、情報追跡システム上で当該メールアドレスが公開されていなければならず、公開するには当該メールアドレスの使用を中止したことを宣言しなければならない。また、予約メールは宛先として、例えば情報追跡システム上に公開されているメールアドレスを設定することをできないようにする。よって、予約メールの設定時点では、宛先のメールアドレスに認証設問が設定されていないことを意味するため、自動追跡機能においては認証設問を無視してメールを転送することとなる。
【0319】
(メリット)
・暇なときに年賀メールや誕生日メール等の予約メールを作成しておき、忘れることなく自動で送信できる。
・未来の自分に対して、予約メールをリマインド送信できる。
・死亡事故・意識不明など、自分の身が不慮の事態に陥った場合、非常事態設定により家族など関係者にメッセージを送信できる。
・非常事態を段階的に設定することにより、深刻度に合わせて送信メッセージの内容を変化させることができる。
・「自身が死亡した等の場合に限り、10年後の娘に誕生日メールを送信」といった設定も可能(非常事態+日付指定)
・自身の身に事故が発生した場合、クレジットカードや各種契約の停止、貴重品や遺言書の隠匿場所の開示、事後の指示なども、「予約メール+非常事態宣言」によって可能となる。
【0320】
本情報追跡システムは、消息不明となる事態を排除することも目的とすることができる。ユーザー自身の死亡により、直ちに意思の疎通が取れなくなる状況を排除し、またαIDの追跡情報が更新されないという事態をも防ぎたい。この目的を実現するための機能(手段)が、「非常事態設定」である。
【0321】
自身の手で情報追跡システムの追跡情報を更新できなくなった場合には、知人や親族にログインアカウントとパスワードを開示し、操作を引き継がせる必要がある。しかし一方で、引き継ぐ人物(継承者)によって、予約メールの設定が解除されるなどといった事態は避けなければならない。そこで、情報追跡システムには、ログインアカウントに制限を持たせる機能がある。親アカウントは、マイページのすべてを操作する権限を有するが、子アカウントには予約メール関連、送信ボックスの操作する権限がない等である。
【0322】
子アカウントの継承者は、情報追跡システムの公開情報を基に転送されるメールを、継承者自身のメールアドレスに転送されるよう設定でき、またαIDに紐づくアドロカード(電子名刺に相当)の情報を更新できる。ただし、例えば継承者自身にも将来的に送信される可能性がある予約メールを操作すること、あるいは死亡者自身が送信したメールが存在する「送信ボックス」にはアクセスできない等の制限が設けられる。
【0323】
<情報追跡システムの活用例>
従来の名刺やショップカード等は、情報が古くなると価値を失う。カード情報に一意の文字列(αID)を含めて、これをキーとして更新情報を抽出できれば従来の短所を克服できる。この機能は使い方次第で、例えば以下のような様々な用途が考えられる。
(1)プライベートな名刺に活用
・転居・改名・婚姻・転職等に伴う個人情報の変更に対応できる
(2)法人名刺に活用
・移転・改称・統廃合・廃業に伴う法人情報の変更に対応できる
・従業員の配置転換・退職に伴う情報断絶に対応できる
・従業員名簿、あるいはチーム毎にまとめて管理できる
・退職した従業員との連絡手段として残せる
・従業員が独立しやすい環境を整備できる(ベンチャー企業用)
・顧客へのケアが万全となる(信頼性UP)
(3)医者、士業等の専門職の名刺に活用
・事務所の移転・改称・統廃合に伴う変更に対応できる
・専門職としての顧客へのアフターケアが万全となる(信頼性UP)
・独立後も得意客を逃がさない
【0324】
(4)顧客側、取引相手側等のメリット
顧客側、取引相手側等(例えば(2)及び(3)の場合)のメリットとして、以下のようなことが期待できる。
・会社の移転・解消・統廃合にかかわらず担当者に連絡できる
・担当(責任)者の退職後でも、引き継ぎ先を特定できる
・担当者個人を常に特定できるため、秘密情報を明かしても安心
・信頼できる担当者が転職しても、転職先を後追いできる
・担当者個人のαIDを会社側が明示=極めて大きな安心感
【0325】
(5)所持品の所有者情報として活用
・紛失後、記載した個人情報が変わっても返還受領が可能
・拾得物の返却が容易になる
・所持品に直接、個人情報を書く必要がない(盗み見られにくい)
・極小のスペースしかない物品にも所有者情報を詳細に記録可能
【0326】
(6)イベント情報として活用
イベント情報のパンフレット、カタログ等にαIDを記載することにより、以下のようなメリットが期待できる。
・一度きりのイベントの実行組織であっても関係者を特定できる
・イベントや組織委員会の名称が変わっても関係者を特定できる
・単発イベントであっても、関心のある人物を長期的に発掘できる
・他のイベントとも効果的に連携できる(リスト機能)
(7)ショップカードに活用
・店舗が移転・廃店しても、顧客を将来の事業に呼び戻せる
・顧客に対しイベント告知や緊急告知が出せる(リスト機能)
・競合他店に対し差別的サービスを展開しやすい(リスト機能)
・完全廃業した後であっても、技術者等への連絡先を通知する手段として利用できる
【0327】
(8)顧客側のメリット
ショップカードの場合は顧客に「カード」を渡さねばならない。これは逆に言えば、カードを受け取らない客には効果がないことになる。しかし、例えば図3に示すように、αIDの最も実用的な使い方はレシートに記載すればショップカードを渡し忘れた場合にも、10年前に訪れた日本で購入した商品であってもレシートさえ残っていれば購入店舗の最新情報を抽出できることになる。(7)の場合の顧客側等のメリットとして、以下のようなことが期待できる。
・顧客は廃店を知った後でも、店舗関係者を後追いできる
・行きつけの複数の店舗情報を、まとめて管理できる
・行きつけの店舗のお得情報を、タイムリーに得られる
・お気に入りを業種ごと・地域ごとなど、リスト化できる
【0328】
また、特に旅行者などは、数十年前に訪れた店舗の情報を簡単に後追いできる。例えば、2020年の東京で五輪開催時、その後の外国人観光客等による訪日旅行者が増大すると考えられる。日本には魅力ある店舗やサービスがあるものの、栄枯盛衰が激しい。そのため、日本語の店舗名、事業者の所在地などが変わった場合等では、特に外国人等には言語の問題によりその名称変更、所在変更等を把握することが困難であるため、αIDを活用することにより何年後でも情報を後追いできるため、日本に再訪者を呼び込む一助となりえる。
【0329】
(9)商品・アイテム情報
・販売会社や製造メーカの統廃合後も、権利者・責任者・担当部署をαIDにより紐付け可能であるため、特定しやすい。
・極小の商品であっても、個々のアイテムにαIDを付与できるため、アイテムから連絡先を探し出すことができる。
・吸収企業の絶版商品でも、長期にわたって反響を確認できる
・商品アイテムごとのαIDなら、商品情報の後追いが容易である
・個人作家、インディーズ作品などの場合には、その著作物(絵、工芸品、CDの媒体表面やケースに印刷)等にαIDを記載できるため、特に情報発信として威力を発揮することができる。例えば、図38に、利用者端末4に表示される著作権に関する開示情報の表示例を示す。
【0330】
(10)商店街等グループ情報
・チームやグループなど抽象的な主体であっても、明確な連絡先を確保できる
・チーム解散後も、個々のメンバーの連絡先を温存し続けられる(リスト機能)
例えばインディーズの音楽グループなどは、いつ解散しても不思議ではない。そしてCDレーベル等の作品は残っても、その後の消息をつかむのは難しい。
【0331】
(効果)
担当者が退社等などで、それまでの担当者の名刺を持っている取引先が連絡を試みようとしたときに、新たな担当者にたどりつくための労力を軽減し、担当部門等の連絡先の情報追跡が可能となる。これにより、顧客との連絡機会の喪失を回避することができる。
ホームページ、ブログ等での情報発信等では、担当者等の個々人のやる気や、保守側の面の問題もあるが、特に時間月日の経過とともに特定の対象である個々の物に関する情報や担当者の情報を、ホームページ、ブログ等を探し出すことが困難となる。
【0332】
例えば、名刺の記載欄に、部門ごとの情報追跡番号などがあれば、それを手がかりにネット上での担当部門等の連絡先の情報追跡が容易となる。
【0333】
(その他)
本情報追跡システムは、各種民間の会員情報や名刺、公的に処理されるような単に個人情報のみを扱うものではなく、例えば店舗や商品・サービスの情報、パンフレット内容といった一般に紙媒体で授受される情報はもちろん、インターネット上を流れる電磁情報のほか、さまざまな携行品に記載される所有者情報、映像・動画情報、芸術作品情報、音声情報をも含め、あらゆる「過去の情報」を更新するに有効な技術である。
【0334】
このうち映像・動画情報、物理的な芸術作品情報、及び音声情報の「追跡」には、主に著作権者を追跡することに利用することができる。このうち映像・動画情報、物理的な芸術作品については、その作品中に検索対象主情報を極小文字で混入するといった手法を用いることができる。
【0335】
音声情報の情報追跡を行う方法としては、第1に音声情報の中に口頭で検索対象主情報を読み上げるといった手段が考えられる。しかし、この場合は主要な音声情報部分(以下、音源データ)と、これに追加された検索対象主情報部分とが切り離され、個別に流通してしまう可能性を否定できない。
【0336】
そこで、印刷以外の方法としては、例えば検索対象主情報を一定音域(周波数帯)の音声に変換(エンコード)して主音源部分に混入させる手段を用いる。この検索対象主情報の音声エンコード手法としては、例えばモールス符号化したものを特定の周波数で再生するといった手段が含まれる。
【0337】
符号化された検索対象主情報を主音源に混入させるには様々な手法が想定されるが、例えばモールス符号を用いる場合には、モールス符号化済みの検索対象主情報を一定周波数の音声として生成して、これを音源データに混入させる。この「一定周波数の音声」とは、人間には聞き取り難い帯域周波数を指す。
【0338】
例えば、一般的な人間の可聴周波数(可聴帯域)は20Hzから20KHzであるため、この域外、すなわち20Hz未満、または20KHz以上の周波数でモールス信号を書き込めば、耳に伝わる音源データを損傷することなく検索対象主情報を混入させることができる。しかし昨今の音声の非可逆圧縮技術では、非可聴帯域の周波数を排除して保存するため、この帯域の周波数を用いることにより圧縮時に検索対象主情報が失われる恐れがある。したがって現実的に考えれば、例えば図39に示すような非可逆圧縮技術によって排除されない周波数の信号を用いて検索対象主情報を元データに追記する(付加データとする)必要がある。
【0339】
広く普及するMPEG−1 Audio Layer−3(MP3)形式データ、Ogg形式データ(RFC3533資料によるマルチメディアコンテナフォーマットの例)、AAC形式データ(ISO/IEC 14496−3による動画・音声デジタルデータのフォーマットの例)などにより音声情報を圧縮する際にも非可聴帯域、すなわち人間の耳で比較的聞き取り難い周波数のデータ部分が排除される。
【0340】
例えば、MP3形式データでは、一般に録音・圧縮モードが用いられるが、どのモードであっても40Hz未満の周波数音声は排除される。よって、モールス信号を低周波数で混入させる場合には40Hz以上、且つより低い周波数の音声を用いこととなる。ただし、この低周波数帯が多く用いられる種の音源データの場合に低周波数のモールス院号を混入させると、むしろこの信号が雑音となってしまう。
【0341】
そこで、このような場合には逆に、音源データ内でほとんど使われていない高周波数の音声でモールス信号を混入させる必要がある。そもそもMP3のような非可逆圧縮技術では、音源データの内容を鑑みて最適な録音・圧縮モードを選択するものであるから、モールス信号も同様に音源データの特性を鑑みて、想定されうる録音・圧縮モードでの周波数特性の最低・最高周波数を基に設定することとなる。
【0342】
なお、検索対象主情報を音声符号化する際には、検索対象主情報に不変のフラグ情報を付加することが望ましい。これはエンコードされた符号を音声情報の中から抽出する際の目安とするためである。仮に検索対象主情報を「ABCDEFGHIJKLMNOP」とした場合には、それが検索対象主情報であることを示す、例えば「SR」というフラグ文字列を接頭辞として追加して「SRABCDEFGHIJKLMNOP」という文字列を生成し、これをモールス符号化してからエンコードする等の方法である。
【0343】
音声情報の中から検索対象主情報を抽出する際には、音声中の周波数成分を一般的なスペクトラムアナライザや高速フーリエ変換(FFT)を用いて信号周波数のピーク(山)を検出したのち、前述した例では「SR」をモールス符号化した信号、すなわち「 ・・・ ・−・ 」部分を捜索することで、検索対象主情報の先頭部分を効率的に割り出すことができる。これにより得られたモールス符号を文字列情報に変換したうえで、フラグ情報(前述の例の場合は「SR」)を除くことにより、検索対象主情報を復元することが可能である。さらにこの検索対象主情報を情報追跡システムで検索することによって、主音源に関する最新の情報(例えば著作権情報など)を確認することができる。
【0344】
以上のように、本発明は検索対象主情報を用いることにより、過去に記載・保存された情報に関する更新情報の取得を可能とする技術である。これは単に連絡先といった個人情報に限らず、取扱説明書や遺言書に代表されるような各種文書情報、映像・画像・音声の更新をも可能とする技術である。これにより、従来の状況下では容易に失われうる、「物」や人間の関係性を復活させ、時間の経過により不明となりがちな著作者の権利を明確にするものであり、ひいては未来社会の文化的発展に寄与するものである。
【0345】
以上説明したように、本発明によれば、過去の時点で記載された各種情報の鮮度が劣化した場合に、更新情報を追跡(検索・抽出)できなくなることを防ぐことができる。また、情報の開示請求者が同一システム上の会員となることを必要とせず、かつ両者間で相互に本人確認を行い、開示者が意図しない人物には情報が開示されないよう開示制限機能を設けることができ、情報漏えいの危険性を最小限に抑えることができる。
【0346】
また、例えば名刺等の紙媒体はもとより、電磁的記録を含むあらゆる物体に記された、あるいは音声として記録された「過去の情報」をもとに、更新情報を抽出するソフトウェア技術であると同時に、同一システムのメンバー(会員)間でなくとも、更新情報を開示すべき相手を限定した上で当該情報の開示を可能とすることができる。
【0347】
以上説明したように、本実施形態の情報追跡装置、情報追跡方法および情報追跡プログラムによれば、情報を開示すべき相手を限定した上で当該情報を開示することができる。
【0348】
[他の実施形態]
以上、本発明の実施形態を説明したが、この実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。また、この実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。この実施形態やその変形には、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【0349】
1A、1B、1C…情報追跡装置、2A、2B、2C…情報追跡追跡データベース、3…サーバ、4…クライアント(利用者端末)、9…インターネット(通信ネットワーク)、11、11c…情報検索入出力手段、12、12c…設問提示認証手段、13、13c…メッセージ転送手段、14、14c…設問回答作成手段、15c…私書箱管理手段、21、21c…会員情報テーブル、22、22c…アルファIDテーブル、23、23c…メールアドレステーブル、24、24c…認証設問データテーブル、25c…アルファフォルダテーブル、41…登録会員端末、42…他の登録会員の開示請求者端末、43…非登録会員の開示請求者端末、111…検索情報受信部、112…検索情報解析部、113…開示情報出力部、121…設問抽出部、122…設問出力部、123…回答受信部、124…回答採点部、125…採点結果出力部、131…フォーム出力部、132…メッセージ受信部、133…入力データ検査部、134…メッセージ送信部、135…処理結果出力部、136c…予約メール設定部、137c…非常事態設定部、138c…利用状態管理部、141…設問記録部、142…正答記録部、143…認証基準記録部
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30
図31
図32
図33
図34
図35
図36
図37
図38
図39