JP5648833B2 - 個人ｉｄ統合サーバシステム及び個人ｉｄ統合サーバ及びハードウェアｉｄ登録サーバ - Google Patents

Description

本発明は、個人ＩＤの利用に関する。特に、インターネット上でサービスを利用する場合に、複数のサービスに共通に使用できる統合した個人ＩＤの利用技術に関する。

従来のＩＤ登録及びその問題点
（問題１）近年、インターネットビジネスの普及に伴って、インターネット上におけるショッピングや流通サービスになどが広く利用されている。ユーザがこれらのサービスに参加するためには、そのユーザの個人情報の登録が必須となる。

しかし、ユーザにとってみれば、新たなサービスに登録参加する場合には、ほぼ同じような個人情報を入力する必要が発生し、その度にＩＤとパスワードを申請しサービス参加することになるため、非常に煩雑な作業が要求されていることになる。

しかもユーザが新規登録の際に申請するユーザＩＤについては、必ずしもそのままサービスで利用可能なわけでなく、既に他人によって使われていた場合は、全く新規なユーザＩＤを登録する必要が生じる。そのため、個人が上記サービスを利用する際には、複数サービスそれぞれ毎のユーザＩＤ（個人ＩＤ）を用いざるをえない場合もあった。その結果、上記各種サービスを利用する個人は、複数サービス毎の複数ユーザＩＤという煩わしい使い分けを余儀なくされている場合もあった。

このような問題に対して、本発明の個人ＩＤ統合サーバを用いれば、次のような対応が可能である。

例えば、自治体においては、地域ＩＣＴ（Information Communication Technology）対応の個人ＩＤ統合サーバの設置が進められているので、個人ＩＤをこの個人ＩＤ統合サーバで統合管理することが好ましい。そして、地域ＩＣＴで利用する個人情報は、このＩＤ統合サーバを用いて一元管理を行うことが好適であると考えられる。

そして、ユーザが個人情報を初期登録する際は、サービスが利用するユニークなデバイスＩＤ（タグや端末等に割り振られたＩＤ）と、このデバイスＩＤにアサインされたＰａｓｓコードを入力することでサービスサーバ経由で個人情報を個人ＩＤ統合サーバに登録することが可能になる。それ以降、同じデバイスを利用して、他のサービスサーバの提供するサービスに登録する場合は、既に個人ＩＤ統合サーバ登録している情報をサービスサーバが取得するので、ユーザ側で煩わしい個人情報の再登録を再び行う必要がなくなる。

（問題２）サービスの提供側においても、ユーザ登録管理という煩わしいデータベース運用が必ず発生し、個人情報保護の観点からも保守運用におけるコストは今後も増え続けると予測される。
このような問題に対しても、本発明の個人ＩＤ統合サーバを用いれば、サービスサーバで顧客情報を常に管理する必要がなくなる。すなわち、必要に応じて個人ＩＤ統合サーバにアクセスすることで顧客情報を取得してサービスを効率的に提供することが可能となる。

（問題３）また、もしユーザの電話番号や住所、メールアドレスが変更された場合、従来は、ユーザはサービス毎に情報更新を行う必要が発生していた。

このような問題に対しても、本発明の個人ＩＤ統合サーバを用いれば、ユーザ情報に変更があった場合に、個人ＩＤ統合サーバの情報を変更するだけでよい。すなわち、従来のように、個別にサービスサーバにアクセスして個人の登録情報を変更するという作業の必要がなくなる。

今後のＩＣＴ社会におけるＩＤ運用の問題点
（問題点１）タグや端末などの機器に対応したＩＤを利用したサービスが、ＩＣＴの利活用に伴い増えつつある。しかし、その機器ＩＤは従来は、システム側で管理されてきた背景がある。例えば、携帯電話やＩＳＰが配布するルータなどは、サービス提供者専用機器として、機器ＩＤが既にサービス提供者側に登録されてサービス運用可能になっている。従って、ＩＣＴの利活用が今後ますます進んでいくと仮定した場合、サービス毎に端末やタグが配布され、個人が従来のクレジットカード同様、複数ＩＤの使い分けを行わなければならなくなり、非常に煩雑な運用がなされてしまう可能性がある。

しかも、無線によるインターフェースが搭載された機器の場合、利用シーンによっては他の装置と混線するような事態も想定され、使用方法にも問題が発生することが考えられる。

これに対して、本発明の個人ＩＤ統合サーバを利用すれば、１つの機器（デバイス）ＩＤに対して、複数のサービスを紐付けることが出来るので、ユーザがサービス毎に個別の機器を持つ必要がなくなると考えられる。

（問題点２）今後のＩＣＴ社会を発展させるためには、複数プレーヤー（事業者）が様々なビジネスで参入できることが必要であるが個人登録情報と機器情報とそれを利用したサービス情報を複数のサービス運用プレーヤーたちにどのように関連付けて統合的に管理していくかについてはほとんど考えられていないのが現状である。従って、現状は個人情報／機器情報／サービス情報を一元的に管理できる事業者のみがサービスを行うことになるため、インターネットマーケットのようなオープン化が困難な状況下にある。

これに対して、本発明の個人ＩＤ統合サーバを利用すれば、サービス／機器（デバイス）／個人情報管理を分散して管理し、ユーザに対しては、サービスの窓口を通じて情報連携させるため、個々の事業自体の規模が小さくてもオープン化することで、様々なサービス参入が可能なオープンシステムを構築することが可能であると考えられる。

先行特許文献
例えば、下記特許文献１には、入退室管理システムにおいて、共通ＩＤに重複が生じないような共通ＩＤの割り当て管理技術が開示されている。

また、下記特許文献２には、組織の構成員が共通ＩＤを用いて複数のＤＢにアクセスした場合、その内容を確認するための技術が開示されている。

特開２００７−１４６５９９号公報 特開２００３−０５０７７９号公報

このように、従来は、各種サービス毎に個人情報の登録を行い、また各種サービス毎にＩＤの設定を行う必要があった。

これに対して、複数のサービスに共通に用いられるＩＤを統合・管理する仕組みを構築すれば、従来の煩雑な処理は必要なくなり、より効率的な処理が可能となると考えられる。しかし、ＩＤを統合・管理する技術で好ましいものは従来知られていなかった。

本発明は、かかる課題に鑑みなされたものであり、その目的は、個人ＩＤを統合・管理する仕組みを実現し、各種サービスをより便利に利用することができる仕組みを提供することである。

（１）本発明は、上記課題を解決するために、ネットワークと、前記ネットワークに接続する個人ＩＤ統合サーバと、前記ネットワークに接続するサービスサーバと、前記ネットワークに接続するハードウェアＩＤ登録サーバと、を含み、前記個人ＩＤ統合サーバは、利用者の個人情報と、前記個人情報毎に設けられた認証コードと、を格納した個人情報データベースと、個人情報の開示要求メッセージを外部から受信し、前記開示要求メッセージ中のパスワードと、ハードウェアＩＤとを、前記ハードウェアＩＤ登録サーバに送信する手段と、前記ハードウェアＩＤ登録サーバから、認証コードを含む認証成功のメッセージが返信されてきた場合に、前記返信された認証コードを、前記個人情報データベース中の個人情報に設けられた認証コードと、を比較し、一致している場合は、前記開示要求メッセージに係る個人情報を外部に送信する手段と、を含み、前記サービスサーバは、サービスを要求する利用者から送られてきたハードウェアＩＤと前記パスワードとを含む個人情報の開示要求メッセージを、前記個人ＩＤ統合サーバに送信する手段、を含み、前記サービスサーバは、前記個人ＩＤ統合サーバから送信されてきた前記個人情報を利用してサービスを提供し、前記ハードウェアＩＤ登録サーバは、各ハードウェアにそれぞれ付され、各ハードウェアを識別するハードウェアＩＤと、前記各ハードウェア毎に設けられ、前記ハードウェアの利用者であることを表す前記パスワードと、前記各ハードウェア毎に設けられ、個人情報を開示するためのコードである認証コードと、を格納しているハードウェアデータベースを備え、前記ハードウェアＩＤ登録サーバは、外部から送信されてきた前記ハードウェアＩＤ及び前記パスワードと、を受信し、前記ハードウェアデータベース中で前記ハードウェアＩＤに設けられた前記パスワードと、前記外部から送信されてきたパスワードと、を比較し、一致している場合は、前記ハードウェアＩＤで識別されるハードウェアに設けられた前記認証コードを外部に送信する手段、を備えていることを特徴とする個人ＩＤ統合サーバシステムである。

（２）また、本発明は、上記課題を解決するために、ネットワークと、前記ネットワークに接続する個人ＩＤ統合サーバと、前記ネットワークに接続するサービスサーバと、前記ネットワークに接続するハードウェアＩＤ登録サーバと、を含み、前記個人ＩＤ統合サーバは、利用者の個人情報と、前記個人情報毎に設けられた認証コードと、を格納した個人情報データベースと、個人情報の開示要求メッセージを外部から受信し、前記開示要求メッセージ中の認証コードと、前記個人情報データベース中の個人情報に設けられた認証コードとを、比較し、一致している場合は、前記開示要求メッセージに係る個人情報を外部に返信する手段と、を含み、前記サービスサーバは、サービスを要求する利用者から送られてきたハードウェアＩＤと前記パスワードとを含む個人情報の認証要求メッセージを、前記ハードウェアＩＤ登録サーバに送信する第１手段と、前記ハードウェアＩＤ登録サーバから認証コードを含む認証成功のメッセージが返信されてきた場合に、前記認証コードを含む個人情報の開示要求メッセージを、前記個人ＩＤ統合サーバに送信する第２手段と、を含み、前記サービスサーバは、前記個人ＩＤ統合サーバから返信されてきた前記個人情報を利用してサービスを提供し、前記ハードウェアＩＤ登録サーバは、各ハードウェアにそれぞれ付され、各ハードウェアを識別するハードウェアＩＤと、前記各ハードウェア毎に設けられ、前記ハードウェアの利用者であることを表す前記パスワードと、前記各ハードウェア毎に設けられ、個人情報を開示するためのコードである認証コードと、を格納しているハードウェアデータベースを備え、前記ハードウェアＩＤ登録サーバは、外部から送信されてきた前記ハードウェアＩＤ及び前記パスワードと、を受信し、前記ハードウェアデータベース中で前記ハードウェアＩＤに設けられた前記パスワードと、前記外部から送信されてきたパスワードと、を比較し、一致している場合は、前記ハードウェアＩＤで識別されるハードウェアに設けられた前記認証コードを外部に送信する手段、を備えていることを特徴とする個人ＩＤ統合サーバシステムである。

（３）また、本発明は、上記（１）記載の個人ＩＤ統合サーバシステムに用いられる前記個人ＩＤ統合サーバにおいて、利用者の個人情報と、前記個人情報毎に設けられた認証コードと、を格納した個人情報データベースと、個人情報の開示要求メッセージを外部から受信し、前記開示要求メッセージ中のパスワードと、ハードウェアＩＤとを、前記ハードウェアＩＤ登録サーバに送信する手段と、前記ハードウェアＩＤ登録サーバから、認証コードを含む認証成功のメッセージが返信されてきた場合に、前記返信された認証コードを、前記個人情報データベース中の個人情報に設けられた認証コードと、を比較し、一致している場合は、前記開示要求メッセージに係る個人情報を外部に送信する手段と、を含むことを特徴とする個人ＩＤ統合サーバである。

（４）また、本発明は、上記（２）記載の個人ＩＤ統合サーバシステムに用いられる前記個人ＩＤ統合サーバにおいて、利用者の個人情報と、前記個人情報毎に設けられた認証コードと、を格納した個人情報データベースと、個人情報の開示要求メッセージを外部から受信し、前記開示要求メッセージ中の認証コードと、前記個人情報データベース中の個人情報に設けられた認証コードとを、比較し、一致している場合は、前記開示要求メッセージに係る個人情報を外部に返信する手段と、を含むことを特徴とする個人ＩＤ統合サーバである。

（５）また、本発明は、上記（１）又は（２）に記載の個人ＩＤ統合サーバシステムに用いられる前記ハードウェアＩＤ登録サーバにおいて、前記各ハードウェアにそれぞれ付され、各ハードウェアを識別する前記ハードウェアＩＤと、前記各ハードウェア毎に設けられ、前記ハードウェアの利用者であることを表す前記パスワードと、前記各ハードウェア毎に設けられ、個人情報を開示するためのコードである前記認証コードと、を格納している前記ハードウェアデータベースを備え、前記ハードウェアＩＤ登録サーバは、外部から送信されてきた前記ハードウェアＩＤ及び前記パスワードと、を受信し、前記ハードウェアデータベース中で前記ハードウェアＩＤに設けられた前記パスワードと、前記外部から送信されてきたパスワードと、を比較し、一致している場合は、前記ハードウェアＩＤで識別されるハードウェアに設けられた前記認証コードを外部に送信する前記手段、を備えていることを特徴とするハードウェアＩＤ登録サーバである。

（６）また、本発明は、上記（５）記載のハードウェアＩＤ登録サーバにおいて、前記ハードウェアは、通信端末、タグ、ＩＣカード、通信インターフェース、のいずれかであることを特徴とするハードウェアＩＤ登録サーバである。

以上述べたように、本発明によれば、個人ＩＤを個人ＩＤ統合サーバで一元管理しているので、サービス提供側が個人情報の管理を行う必要がなくなる。

また、本発明によれば、１つのデバイスＩＤ（機器ＩＤ）に対して、複数のサービスをひも付けることができるので、ユーザがサービス毎に個別の機器を持つ必要がなくなり、より便利なサービスを受けることが可能である。

本実施の形態で提案するシステムの構成を示す構成図である。

本実施の形態で提案するシステムにおけるユーザのシステム操作動作の例を説明する説明図である。

利用者の操作の例を示す説明図である。

図３の場合のデータの流れを示すデータフロー図である。

図３の場合のデータの流れの他の例を示すデータフロー図である。

個人情報が未登録だった場合の利用者の操作の例を示す説明図である。

図６の場合のデータの流れを示すデータフロー図である。

図６の場合のデータの流れの他の例を示すデータフロー図である。

来店によるサービス提供の例を示す説明図である。

以下、本発明の好適な実施の形態を図面に基づき説明する。

第１ 構成
システム構成
本実施の形態で提案するシステムの構成が、図１に示されている。

この図に示すように、本システムは、機器を製造配給する機器配給側が管理するサーバＤＢ１０と、サービス提供側が管理するサーバＤＢ１２と、地方自治体側が管理するサーバＤＢ１４と、の３種のサーバ群と、それらを結ぶネットワーク１６とから構成されている。

なお、各種サーバＤＢについては、「ＤＢ（データベース）」を省略し、単に「サーバ」と呼ぶ場合もある。なお、ＤＢは、データベースの意である。

機器配給側が管理するＩＤ登録サーバＤＢ
本実施の形態においては、サービスの提供は、ユーザが利用するハードウェアのＩＤと関連づけて行われる。そのために、ユーザが利用するハードウェアのＩＤとパスワードとの組み合わせを提供するＩＤ登録サーバＤＢ１０が、ハードウェア配給側によって設けられている。

このＩＤ登録サーバＤＢ１０は、請求の範囲のハードウェアＩＤ登録サーバの好適な一例に相当する。

例えば、そのハードウェアがタグ（例えばＲＦＩＤタグ）である場合、ユーザに配布するそのタグについて、タグ配給元が事前にタグＩＤ登録サーバ１０ａに、タグＩＤとＰａｓｓワードと、を事前設定しておく。なお、タグＩＤとＰａｓｓワードとを、特に、「タグＩＤ／Ｐａｓｓ」と記載する場合がある。また、Ｐａｓｓワードは、「パスワード」と記す場合もある。

また、ユーザが使用するそのハードウェアがパソコンであった場合、そのパソコンに使用するネットワークインターフェースカードの配給元が事前に、そのネットワークインターフェースカードのデバイスＩＤについて、デバイスＩＤ登録サーバ１０ｂを設けておく。そして、ネットワークインターフェースカードの配給元が、そのデバイスＩＤ登録サーバ１０ｂに、予めデバイスＩＤ／Ｐａｓｓを事前に設定しておく。

また、ユーザが使用するそのハードウェアが携帯電話であった場合、その携帯電話の配給元が事前に、その携帯電話の端末ＩＤについて、端末ＩＤ登録サーバ１０ｃを設けておく。そして、携帯電話の配給元が、その端末ＩＤ登録サーバ１０ｃに、予め端末ＩＤ／Ｐａｓｓを事前に設定しておく（図１参照）。

ここで言うＩＤは、各ハードウェア毎に付されているものであり、たとえば、各装置毎にシリアルナンバー等が好適に用いられる。また、ネットワーク機器であればＭＡＣアドレス等を利用することも好適である。その他、各種の製造番号や、ロット番号も含めた商品番号その他の番号が好適である。パスワードは、そのハードウェアの利用者であることを表す（証明）するものであり、利用者が設定する。

このタグＩＤ登録サーバ１０ａや、デバイスＩＤ登録サーバ１０ｂ、端末ＩＤ登録サーバ１０ｃ等は、請求の範囲のハードウェアＩＤ登録サーバの好適な一例に相当する。

サービス提供側が管理するサービス提供サーバＤＢ
サービス提供側が管理するサービス提供サーバＤＢ１４は、例えばサービス提供サーバ１４ａとして実現されている。これは例えば、「ＣＣ商店サーバ」等であり、その「ＣＣ商店」のサービスを提供するサーバである。このサービス提供サーバ１０ａは、サービスを提供しようとするユーザから、タグＩＤ、パスワード（Ｐａｓｓ）を取得する。そして、これらのタグＩＤと、パスワードを用いて、例えばタグＩＤ登録サーバ１０ａに対して、このユーザのタグＩＤ／Ｐａｓｓの認証要求を行う。なお、この場合、タグＩＤとしては、例えばＹＹ社のタグである旨の情報が含まれていることが好ましい。これによって、サービス提供サーバ１４ａは、ＹＹ社のタグＩＤ登録サーバ１０ａに対してアクセスし、認証要求すればいいことを知ることができる。また、ＹＹ社のタグであることを、タグＩＤとは別の情報としてユーザから別途取得することももちろん好ましい。

なお、その認証要求の結果、タグＩＤ登録サーバ１０ａが認証ＯＫと判断した場合、タグＩＤ登録サーバ１０ａは、個人情報登録サーバＤＢ１２にアクセス可能な認証コードを生成してサービス提供サーバＤＢ１４に返信する。

サービス提供サーバＤＢ１４は、認証ＯＫの場合、タグＩＤ登録サーバＤＢ１０から受け取った上記認証コードを利用して、個人情報登録サーバＤＢ１２にアクセスし、ユーザの個人情報を取得することができる。サービス提供サーバＤＢ１４は、取得した個人情報に基づき、ユーザに対してサービスを提供することができる。個人情報の利用法は様々である。個人会員に対するポイントサービスでも良いし、購入商品の送付先を個人情報中の住所から取り出して発送に利用することも好適である。

なお、一般的には、サービス提供サーバＤＢ１４は、サービスに必要な１種又は複数種のＩＤ登録サーバＤＢ１０にアクセスし、個人情報とマッピングすることによって、サービス登録情報を生成することになる。また、利用者毎に利用するハードウェアが異なる場合もあるので、各利用者毎に、利用するＩＤ登録サーバＤＢ１０が異なる場合もある。

なお、このサービス提供サーバＤＢ１４は、請求の範囲（本発明）の「サービスサーバ」の好適な一例に相当する。

地方自治体（地域自体体）側が管理する個人情報登録サーバＤＢ
本実施の形態において、特徴的なことは、個人情報登録サーバＤＢ１２において、個人情報が一元的に管理されていることである。これによって、ユーザはサービス毎に個人情報を登録する必要がなくなり、利便性が向上する。また、個人情報に修正が生じた場合も、個人情報登録サーバＤＢ１２内の個人情報を修正するだけですむので、従来と比べて繁雑な作業をする必要がない。

本実施の形態では、個人情報というデータの性格上、個人情報登録サーバＤＢ１２は地方自治体（地域自治体）が管理する構成としたが、他の公的な機関が管理する構成としても好適である。

個人情報登録サーバＤＢ１２が管理する個人情報は、氏名、住所、年齢、性別、等であるが、一般的な個人情報であれば、どのような情報を管理しても良い。また、地域自治体の場合、サービス提供サーバＤＢ１４に対して公開される個人情報に制限を設けることも考えられる。例えば、住所、氏名、年齢、は公開されるが、家族構成等の情報は公開されない等の扱いをすることも好適である。

これら個人情報とともに、その個人情報を開示するための認証コードが、所定のテーブル（データベース）に格納されている。このテーブル（データベース）、請求の範囲の個人情報データベースの好適な一例に相当する。

また、この個人情報登録サーバＤＢ１２は、請求の範囲（本発明）の「個人ＩＤ統合サーバ」の好適な一例に相当する。

ハードウェアの種類
あるユーザはＩＣカードでサービスを受ける場合もあり、この場合は、上述のようにタグＩＤ登録サーバ１０ａにアクセスが行われる。一方、ユーザが携帯電話でサービスを受ける場合は、端末ＩＤ登録サーバＤＢ１０ｃにアクセスが行われる。また、ユーザがパソコン経由でサービスを受ける場合もあり、この場合は、ネットワークインターフェースカードのデバイスＩＤを用いて、デバイスＩＤ登録サーバ１０ｂにアクセスが行われる。ユーザの用いるハードウェアに応じて、アクセスするサーバ１０は異なる。

なお、同一人が、異なるハードウェアを用いていても良い。この場合でも、そのユーザの個人情報は、個人情報登録サーバＤＢ１２において、一元的に管理されており、同一人であることが容易に確認できる。例えば、あるユーザがパソコンでサービスを申し込み、その後、店頭で携帯電話を利用してサービスを受ける等の連携が柔軟に可能である。

システムの拡張
以上述べたようなシステムにおいては、新しいサービスの提供を開始することが極めて容易である。つまり、サービスを提供しようとするハードウェアの製造番号等のＩＤがあれば、容易に、既存の上記システム上で新しいサービスを乗せることができる。

これに対して、既存の技術によれば、新しいサービスを提供しようとすれば、その「サービス」だけでなく、ハードウェア・ソフトウェアの認証の仕組みを構築しなければ成らず、また、個人情報の管理のためのサーバも構築する必要があり、極めて繁雑な作業が必要であった。

本実施の形態によれば、いわば、サービスそのもの以外の、認証システムや、個人情報の管理システムが独立して存在しているので、いわゆる「新規参入」が容易となる効果を奏する。

第２ 動作例
以下、ＩＣＴ上で稼働している本実施の形態の動作例（利用者の操作・サーバの処理動作等）について説明する。

図２〜図５には、本実施の形態のシステムを利用して、使用者がサービスの提供を受ける場合の動作の例を表す説明図が示されている。

図２には、利用者が操作するパソコン上の画面の例が示されている。まず図２に示すように、利用者は、まず、ＩＣＴ情報を閲覧するために、地域自治体のタウンガイドサーバに接続する。図２の画面はそのタウンガイドサーバの画面の模式図である。この図２の例では、ＸＸＸ市のタウンガイドの画面であり、特に地域広告が掲載されているページが表示されている。タウンガイドには、それぞれのジャンルに該当した地域のリアルタイム情報が表示される。これはいわば小さな広告であり、特売情報、割引情報、等が記載されている。このようなタウンガイドサーバ自体は、従来からよく知られているものであり、従来の技術で十分に実施されうるものである。

利用者はこのページ中からサービスを受けたい商店を選択してその「行」をクリックする（図２参照）。このクリックした行には、その商店のホームページへのリンクが設けられており、商店のホームページにリダイレクトされる。その様子が図２（２）に示されている。図２（２）は、その個別の業者のホームページである。

この図２（２）の画面は、サービス提供サーバＤＢ１４中のＷＥＢサーバが作成し、外部に表示している。利用者はパソコンを利用してサービス提供サーバＤＢ１４にアクセスしており、サービス提供サーバＤＢ１４が提供するＨＴＭＬ等のデータをＷＥＢブラウザで閲覧する。その結果、図２（２）で示すような画面が利用者のパソコンの画面上に表示される。

サービスを提供するに当たって、ＷＥＢを利用することは一般的な事項であり、サービス提供サーバＤＢ１４が、このようなＷＥＢページを表示するためのＷＥＢサーバを含むように構成することは当業者にとって容易である。また、ＷＥＢサーバに接続して、提供されたＨＴＭＬ等をＷＥＢブラウザ等を利用して解釈し、その結果を画面に表示することは従来から一般のコンピュータにおいてよく知られている技術であり、当業者であれば実施することは容易である。

図２（２）で示す画面上で、利用者は割引サービスを受けるには、サービスタグを持参することが必要なことを知る。これは図２（２）の画面上で、「サービスタグを持参された方対象に売り切れ次第終了！」と記載されているからである。

そこで、利用者はサービスを受けるために、「サービスタグＩＤ情報を登録してください。」の部分をクリックして、登録を受けようとする。すると、サービス提供サーバＤＢ１４のＷＥＢサーバは、タグ情報入力画面を表示する。この様子が図３（１）に示されている。

個人情報が既に登録されている場合
個人情報登録サーバＤＢ１２にユーザが個人情報を登録済みの場合の動作が図３に示されている。

図３（１）に示すように、利用者はこの画面で自己が持つＩＣ カード等のタグＩＤ「１０２０１１３３」と、パスワード（ｐａｓｓ）を入力する。タグＩＤは、そのＩＣカード等をパソコンを挿入して自動的に入力するようにしても好適である。入力が終了すると画面は図３（２）に示すように、「この情報で登録してよろしいでしょうか？ 変更 登録」のメッセージが表示される。利用者はサービスを受けるために、この「登録」の部分をクリックしてサービスタグＩＤの登録を行う。すると、画面は図３（３）に示すように変化し、サービスタグが「登録」されたことを利用者に知らせる。

データのフロー
このような画面変化の際のデータの送受信の様子を示すフロー図が図４に示されている。

まず、図３（１）で示したように、利用者がタグＩＤとパスワード（図中、Ｐａｓｓで示される）を入力すると、サービス提供サーバＤＢ１４は、これらをタグＩＤ登録サーバ１０ａに送信し、認証を受ける（図４中、（ａ）で示される）。具体的には、サービス提供サーバＤＢ１４は、タグＩＤとパスワードを含む個人情報の認証要求メッセージを作成して、この個人情報の認証要求メッセージを、対応するタグＩＤ登録サーバ１０ａに送信する。サービス提供サーバＤＢ１４は、基本的にコンピュータで構成され、プログラムを格納した記憶手段と、このプログラムを実行するプロセッサを備えている。上記タグＩＤとパスワードを含む個人情報の認証要求メッセージを作成することは、このプログラムに記述されており、上記プロセッサがこれを実行することによって、個人情報の認証要求メッセージが作成され、タグＩＤ登録サーバ１０ａに送信するのである。したがって、請求の範囲（請求項２）において、サービスサーバ中に記載されている「第１手段」は、このプログラムとプロセッサから構成される。
特に、本実施の形態においては、このプログラムとプロセッサから構成される「第１手段」は、タグＩＤを検査し、そのタグの配給元を検査する。そして、この配給元が設けているタグＩＤ登録サーバ１０ａに個人情報の認証要求メッセージを送信するのである。
タグＩＤ登録サーバ１０ａは、これらの情報を受け取ると、認証を行い。その結果がＯＫであれば、認証コードを返信する（図４中、（ｂ）で示される）。

この動作を実現するために、本実施の形態におけるタグＩＤ登録サーバ１０ａは、タグＩＤと、パスワードと、認証コードと、のテーブルを内部に格納している。

このようなテーブルは、請求の範囲のハードウェアデータベースの好適な一例に相当する。

また、タグＩＤ登録サーバ１０ａは、基本的にコンピュータとして構成されており、内部にプロセッサと、プログラムを登録した記憶手段を有しており、このプログラムをプロセッサが実行することによって、タグＩＤ登録サーバ１０ａの動作が実現されている。

すなわち、
・外部から提供されたパスワードと、上記内部のテーブル中のパスワードを比較して、一致していれば認証コードを返信する
という動作は、上記プログラムによって記述されており、プロセッサがこのプログラムを実行することによって上記動作が実現される。このプロセッサとプログラムは、請求の範囲中のハードウェアＩＤ登録サーバ中に記述される「手段」の好適な一実施例に相当する。

また、タグＩＤは、そのＩＤカードの製造番号等であり、配給業者が付与するものである。一方、パスワードや認証コードは、利用者が、あらかじめタグＩＤ登録サーバ１０ａに対して登録しておくものである。

なお、認証コードは利用者が設定・登録することも好適であるが、システム側、すなわちタグＩＤ登録サーバ１０ａが認証コードを設定することも好適である。認証コードは、タグＩＤや個人のＩＤ等の情報から、タグＩＤ登録サーバ１０ａが所定の方法で設定するように構成しても良い。また、個人のＩＤ等の情報から、ランダムに認証コードを生成するように構成しても良い。そのような動作は、タグＩＤ登録サーバ１０ａ中のプロセッサが、タグＩＤ登録サーバ１０ａ中に格納されているプログラムを実行することによって、実現される。
ここでは、利用者が、既にタグＩＤ登録サーバ１０ａにパスワードや、認証コードの登録を行っているものとして動作の説明を行っている。この登録は、利用者がそのＩＣカードの使用を開始する際に、予めタグＩＤ登録サーバ１０ａにアクセスし、登録を行う。

次に、サービス提供サーバＤＢ１４は、得られた認証コードを用いて、個人情報登録サーバＤＢ１２に対して、個人情報の開示要求メッセージを送信する（図４中、（ｃ）で示される）。この動作も、サービス提供サーバDB１４は中のプロセッサが、サービス提供サーバDB１４中に格納されているプログラムを実行することにより実現している。したがって、この格納されているプログラムとそれを実行するプロセッサとは、請求の範囲（請求項２）中の第２手段の好適な一例に相当する。
個人情報登録サーバＤＢ１２は、このメッセージに対して、その要求の可否を判断した後、ＯＫであれば、個人情報をサービス提供サーバＤＢ１４に対して返信する（図４中、（ｄ）で示される）。

このような動作を実現するためには、個人情報登録サーバＤＢ１２には、個人情報と、認証コードとを、格納しておくテーブル（データベース）を備えている。そして、サービス提供サーバＤＢ１４は、この認証コードを用いて、利用者の個人情報を個人情報登録サーバＤＢ１２に要求する（図４中、（ｃ）で示される）。要求は、個人情報を得たい個人を特定して行う必要があるが、一般的には、「氏名」等が用いられ、その氏名と、認証コードとの一致から、氏名以外の残りの個人情報を開示して良いかを判断する。場合によっては、住所等その他の情報を用いることも好適である。

個人情報登録サーバDB１２は、基本的にコンピュータで構成されており、プロセッサと、個人情報登録サーバDB１２の動作を記述したプログラムを記憶した記憶手段（ハードディスク等）を備えている。そのプログラムにおいて、上記のような外部からの認証コードと、指定された個人情報とともに格納されている認証コードとを比較し、一致していれば、個人情報を外部に開示するという動作を実行する。

このようなプロセッサと、プログラムを格納した記憶手段は、請求の範囲の手段の好適な一例に相当する。

また、利用者が用いているタグＩＤ等のハードウェアの情報を個人情報登録サーバＤＢ１２中の上記テーブルに格納しておくことも好ましい。そして、氏名だけでなく、このタグＩＤの一致等も見て、個人情報を開示して良いか否かを判断することも個人情報保護の観点からは好適である。その他、従来から知られている種々の個人情報保護の仕組みを利用することが可能である。

このようにして、個人情報登録サーバＤＢ１２から返信されてきた個人情報は、サービス提供サーバＤＢ１４によって、受信されてサービスの提供に用いられる。図３、図４で説明した例では、この個人情報が、サービス提供サーバＤＢ１４中の、データベース中に格納されて、かつ、「サービスタグを登録してある」とのフラグが立てられる。これによって、その利用者がサービスタグを登録していることを、その商店は記憶しておくことができるのである。なお、本実施の形態では、ハードウェアとしてＲＦＩＤタグを利用する例を中心として説明しているので、「サービスタグ」と称しているが、携帯電話等の端末の場合は、「サービス端末」と呼ぶことが妥当な場合もあろう。

データのフローの変形例
上の図４で示したデータの流れでサービスの提供を円滑に行うことができるが、サービス提供サーバＤＢ１４が、個人情報登録サーバＤＢ１２と、タグＩＤ登録サーバ１０ａとに対してそれぞれデータの送受信をする必要があり、サービス提供サーバＤＢ１４側の負担が増える可能性もある。また、上で述べた認証コードのセキュリティ性をより向上させることが好ましい場合もある。

そこで、タグＩＤ登録サーバＤＢ１０ａに対するアクセスを行い、認証コードを取得する作業は、個人情報登録サーバＤＢ１２に任せる構成としても好適である。そのようなデータの流れが図５に示されている。

まず、図３（１）で示したように、利用者がタグＩＤとパスワード（Ｐａｓｓ）を入力すると、サービス提供サーバＤＢ１４は、これらを用いて、個人情報登録サーバＤＢ１２に対して個人情報の要求を送信する（図５中、（ｅ）で示される）。
この動作は、図４においてした説明と同様に、サービス提供サーバＤＢ１４中のプログラムとこのプログラムを実行するプロセッサとによって実現されている。そして、このプログラムとプロセッサとは、請求の範囲（請求項１）中の手段の好適な一例に相当する。

個人情報登録サーバＤＢ１２は、この要求を受信すると、タグＩＤとパスワード（Ｐａｓｓ）をタグＩＤ登録サーバ１０ａに送信し、認証を受ける（図５中、（ｇ）で示される）。タグＩＤ登録サーバ１０ａは、これらの情報を受け取ると、認証を行い。その結果がＯＫであれば、認証コードを返信する（図５中、（ｈ）で示される）。

本変形例（図５）においては、個人情報登録サーバＤＢ１２は、タグＩＤとパスワード（Ｐａｓｓ）をタグＩＤ登録サーバ１０ａに送信し、認証を受けるという動作が、図４と異なる点である。そして、この動作を行うために、個人情報登録サーバＤＢ１２中の記憶手段に格納されたプログラムにこのような動作を記述しておき、個人情報登録サーバＤＢ１２中のプロセッサがこれを実行する。

つまり、このような動作が記述されたプログラムが格納された記憶手段と、上記プロセッサとが、請求の範囲（請求項１）中における、個人ＩＤ統合サーバ中の、ＩＤとパスワードとを送信する手段の好適な一例に相当するのである。

個人情報登録サーバＤＢ１２は、認証コードを用いて、個人情報の要求の可否を判断する。その判断の結果、ＯＫであれば、個人情報をサービス提供サーバＤＢ１４に対して返信する（図５中、（ｆ）で示される）。

このような認証の動作は、認証コードの入手先が異なるだけで図４と基本的には同様の動作であり、図４と同様に、このような認証コードの一致を検査し、一致していれば個人情報を開示するという動作をプログラムで記述し、そのプログラムが個人情報登録サーバＤＢ１２内の記憶手段中に格納され、プロセッサがこのプログラムを実行するのである。

したがって、このようなプログラムが格納されたプログラムと、それを実行するプロセッサが、請求の範囲（請求項１）中の、個人ＩＤ統合サーバ中の、認証コードを比較し、一致していれば、個人情報を外部に送信するという手段の好適な一例に相当する。

このような流れによれば、サービス提供サーバＤＢ１４の処理量が減少するので、新規サービス業者の参入が容易となるという効果を奏する。

なお、動作の「主体」が異なっているため、データの流れは異なるものの図５の動作の趣旨は、図４の動作の趣旨と同様であり、等しく本件発明の効果を奏するものである。また、利用者側から見た場合の動作は、図５と図４とは原理的には同様であり、等しく、利用者側から見たネットワーク上のサービスの利便性が向上するものである。

個人情報が個人情報登録サーバＤＢ（個人ＩＤ統合サーバ）に未登録だった場合
個人情報登録サーバＤＢ１２にユーザが未登録の場合の動作が図６に示されている。

まず、図６（１）に示すように、利用者はこの画面で自己が持つＩＣカード等のタグＩＤ「１０２０１１３３」と、パスワード（ｐａｓｓ）を入力する。

入力が終了して登録のボタンをクリックすると、画面は図６（２）に示すように、利用者の個人情報登録の画面に移行する。この点が図３で説明した動作と異なる点である。利用者の個人情報が個人情報登録サーバＤＢに存在しないので、サービス提供サーバＤＢ１４上の画面から、個人情報登録サーバＤＢ１２の画面が新たに読み出され、新しい画面（新しいウィンドウ）上で、個人情報の登録が行われる。

この図６（２）の画面上で、利用者が個人情報を入力した後、登録をクリックすれば、利用者の個人情報が登録される（図６（２））参照。

個人情報の登録が終了すると、画面は、再びサービス提供サーバDB１４が表示する画面に移行する。その様子が図６(３)に示されている。この画面上で「登録」のボタンをクリックすれば、利用者はサービスを受けるために、サービスタグＩＤの登録を行うことができる。この動作は、図３（２）と基本的に同様である。次に、画面は図６（４）に示すように変化し、サービスタグが「登録」されたことが利用者に知らされる。

データのフロー（利用者の個人情報が未登録の場合）
図６に示されているような画面変化の際のデータの送受信の様子を示すフロー図が図７に示されている。

まず、図６（１）で示したように、利用者がタグＩＤとパスワード（図中、Ｐａｓｓで示される）を入力すると、サービス提供サーバＤＢ１４は、これらをタグＩＤ登録サーバ１０ａに送信し、認証を受ける（図７中、（ｉ）で示される）。タグＩＤ登録サーバ１０ａは、これらの情報を受け取ると、認証を行い。その結果がＯＫであれば、認証コードを返信する（図７中、（ｊ）で示される）。

これらの動作は、図４で説明した動作と同様である。

図７でも、図４と同様に、利用者が、既にタグＩＤ登録サーバ１０ａにパスワードや、認証コードの登録を行っているものとして動作の説明を行っている。

次に、サービス提供サーバＤＢ１４は、得られた認証コードを用いて、個人情報登録サーバＤＢ１２に対して、個人情報の送信を要求する（図７中、（ｋ）で示される）。個人情報登録サーバＤＢ１２は、この要求の可否を判断する。しかし、該当する個人情報は登録されていないことが判明する。したがって、未登録である旨のＡＣＫ（応答：Ａｃｋｎｏｗｌｅｄｇｅ）を、サービス提供サーバＤＢ１４に対して返信する（図７中、（ｌ（エル））で示される）。

この未登録である旨のＡＣＫ（ＡＣＫ（未登録）と呼ぶ場合もある）を受信したサービス提供サーバＤＢ１４は、利用者の個人情報が登録されていないことを知るので、あらたに個人情報を登録させるために、個人情報登録サーバＤＢ１２の個人情報登録ページを読み出す。これが、図６（２）に示されている。

個人情報登録サーバＤＢ１２の個人情報登録ページが表示された後は、利用者が個人情報を登録し、それが個人情報登録サーバＤＢ１２に格納される。格納された後は、図４に示すような動作でサービスタグの登録等の動作が行われて、サービスの提供が実行される。

個人情報が登録された後、個人情報登録サーバＤＢ１２は、改めて利用者の個人情報をサービス提供サーバＤＢ１４に返信する。

このようにして、個人情報登録サーバＤＢ１２から個人情報が返信されてきた場合、サービス提供サーバＤＢ１４は、その情報を表示し（図６（３））、この個人情報を用いてサービスタグを登録すべきか否か利用者に入力を促す。その後の動作は、上で説明した通りである。

このように、個人情報は、その個人がサービスを受けようとする際に、未登録であれば、そのまま個人情報の個人情報登録サーバＤＢ１２への登録処理に移行することが、本実施の形態の特徴の一つである。もちろん、個人情報は、サービスの提供動作とは別個に、利用者が自発的に個人情報登録サーバＤＢ１２に登録することも好適である。

データのフローの変形例（個人情報が未登録の場合）
さて、個人情報が未登録の場合でも、図５でしめすようなデータフローを採用することももちろん好適である。

すなわち、タグＩＤ登録サーバＤＢ１０ａに対するアクセスを行い認証コードを取得する作業は、サービス提供サーバＤＢ１４ではなく、個人情報登録サーバＤＢ１２が行うように構成しても好適である。そのようなデータの流れが図８に示されている。

まず、図６（１）で示したように、利用者がタグＩＤとパスワード（Ｐａｓｓ）を入力すると、サービス提供サーバＤＢ１４は、これらを用いて、個人情報の要求を送信する（図８中、（ｍ）で示される）。

個人情報登録サーバＤＢ１２は、この要求を受信すると、タグＩＤとパスワード（Ｐａｓｓ）をタグＩＤ登録サーバ１０ａに送信し、認証を受ける（図８、（ｏ（オー））で示される）。タグＩＤ登録サーバ１０ａは、これらの情報を受け取ると、認証を行い。その結果がＯＫであれば、認証コードを返信する（図８中、（ｐ）で示される）。

個人情報登録サーバＤＢ１２は、認証コードを用いて、個人情報の要求の可否を判断する。その判断の結果、その利用者の個人情報が登録されていないことが判明する。従って
ＡＣＫ（未登録）をサービス提供サーバＤＢ１４に対して返信する（図８中、（ｎ）で示される。

サービス提供サーバＤＢ１４は、このＡＣＫ（未登録）を受信すると、利用者のパソコンの読み取り先のＷＥＢサイトを、個人情報登録サーバＤＢ１２の個人情報登録ページに誘導する。これは図６（２）で説明した通りである。利用者はこの個人情報登録ページ上で、個人情報の登録を行い、これが完了する。

個人情報登録サーバＤＢ１２は、この個人情報が登録された後、その個人情報を改めてサービス提供サーバＤＢ１４に送信する。

このような動作を実現するためには、例えば、ＡＣＫ（未登録）をサービス提供サーバＤＢ１４に対して返信した個人のリストを記憶手段上に設けておくとともに、このリスト上の個人情報が新たに登録されたか否かを検査するプロセス（プログラム）を起動させておくことが好適である。このプロセスはＡＣＫ（未登録）を返したリストを検査しており、それに該当する個人情報が登録された場合に、その個人情報をサービス提供サーバＤＢ１４に送信するとともに、上記ＡＣＫ（未登録）を返したリストから、該当するエントリー（個人）を削除するのである。

このような動作によって、図６で説明した動作を実現することが可能である。

なお、利用者の操作するパソコンのブラウザの読み出し先を、個人情報登録サーバＤＢ１２に向けさせる動作（リダイレクト）は、一般に行われているので、そのような動作を行うプログラムをサービス提供サーバＤＢ１４上に搭載することは当業者であれば容易である。

このような流れによれば、サービス提供サーバＤＢ１４の処理量が減少するので、新規サービス業者の参入が容易となるという効果を奏する。

なお、データの流れは異なるものの図８の動作内容は、図７と原理的には同様である。

また、本実施の形態における「個人情報登録サーバＤＢ１２」は、「個人ＩＤ統合サーバ」の好適な一態様であり、「個人情報サーバ」等と同様のものである。特に、本実施の形態では、地域自治体によって管理されているものを「個人情報登録サーバＤＢ１２」と呼んでいる。

第３ 来店によるサービスシステム運用
次に、来店によるサービスシステムの運用について、その動作の流れを説明する。来店によるサービスシステムの運用の動作の説明図が図９に示されている。

まず、利用者がタウン情報ページ１００にアクセスする（図９中（１）で示されている）。このタウン情報ページ１００は、市や町単位で設けられているＷＥＢサイトであり、近年、多くの地域自治体（地方公共団体）や関連団体がこのようなタウン情報ページ１００をインターネット上で設けている。図９では、利用者がこのタウン情報ページ１００を閲覧し、様々なリアルタイム情報を自宅のパソコンから閲覧する様子が示されている（図９中（２）で示されている）。

次に、利用者は、様々な利用可能なサービスのうち、自己が望むサービスを行っている店舗を見つけ出し、それを利用するために、店舗のサーバにアクセスしてサービス情報を閲覧し、利用する。具体的には、上述したように、タグＩＤやパスワードの入力を行う（図９中、（３）で示されている）。なお、上述したように、利用者の個人情報は、予めＩＣＴ用個人登録情報サーバ１１２に登録しておくか、登録されていない場合はまずＩＣＴ個人情報サーバ１１２にリダイレクトされて、個人情報の登録が行われる（図９の（３）’で示されている）このような登録の動作は、これまで図４、図５、図７、図８等で説明したきたとおりである。

ここでは、ＩＣＴ用個人情報サーバ１１２が用いられているが、これは請求の範囲の「個人ＩＤ統合サーバ」の好適な一例に相当するものであり、個人情報登録サーバＤＢ１２と同様のサーバである。特に、ＩＣＴ用個人情報サーバ１１２は、Information Communication Technology向けのシステムにおいて用いられることを念頭にしたものであるが、機能的には、これまで説明してきた個人情報登録サーバＤＢ１２と同様のものである（図９参照）。このＩＣＴ用個人情報サーバ１１２は、例えば地域ＩＣＴ対応の個人ＩＤ統合サーバとして利用されるものを使用することも好適である。

図９に示すように、ＩＣＴ用個人情報サーバ１１２は、個人情報ＤＢ１１２ａが備えられており、ＩＣＴ用個人情報サーバ１１２が行うサービス情報が格納されている。図９に示されるように、この個人情報ＤＢ１１２ａには、個人情報として、住所、氏名、ユビ端ＩＤ、電話番号、Ｆａｘ番号、生年月日等が格納されている。さらに、この個人情報ＤＢ１１２ａには、利用者が利用するハードウェアの情報が格納されている。利用者が使用するハードウェアがＲＦＩＤタグの場合は、そのＲＦＩＤタグのタグＩＤと、パスワードが登録される。

さて、利用者は、図９の（３）において、店舗サーバ１１４にアクセスし、サービス提供の登録を行う。店舗サーバ１１４は、サービス提供サーバＤＢ１４と同様の機能を有するサーバである。店舗サーバ１１４は、利用者から提供されたタグＩＤと、パスワード（Ｐａｓｓ）を利用して、ＩＣＴ用個人情報サーバ１１２にアクセスし、個人情報を取得することは、これまで述べたとおりである。

このように、図９等の本実施の形態においては、利用者認証許可において、店舗サーバ１１４に個人情報の登録を簡単に行うことができる。従って、従来のＷＥＢサービスのように、店舗サービス毎に個人情報を登録する必要がなくなり、サービスの提供を容易に受けることが可能となる。

なお、図９においては、データのフローは図５、図８に示されたフローの例を示している。つまり、図９の例では、利用者から提供されたタグＩＤ、パスワード（ｐａｓｓ）は、ＩＣＴ用個人情報サーバ１１２に転送されて、個人情報の認証に利用される。すなわち、ＩＣＴ用個人情報サーバ１１２が、タグＩＤと、パスワードと、を用いて、タグ配給元が設けている機器管理サーバ１１０にアクセスして認証を行うのである。その認証が成功すれば、機器管理サーバ１１０から「成功」である旨のメッセージと認証コードが送信され、それに基づき、ＩＣＴ用個人情報サーバ１１２が、個人情報を店舗サーバ１１４に送信する。このようにして、店舗サーバ１１４はサービス登録利用者の承諾によって、個人情報を取得する（図９中、（４）で示されている）。

さて、その後、利用者はＲＦＩＤタグを持参して来店した場合、店主／店員はＲＦＩＤタグの読み取り機を組み込んだネットワーク情報端末を使用して、その場で利用者の個人情報を個人情報登録サーバから取得して、ネットワーク情報端末で確認することが可能になる。ホテルのチェックイン、レストラン予約確認などに幅広くサービス利用可能であり、その場で来店ポイントや提供サービスを受けることも可能になる。

このように、図９の本実施の形態によれば、店舗サーバ１１４側が顧客の情報を常に管理しなくても、個人ＩＤ統合サーバとしてのＩＣＴ用個人情報サーバ１１２にアクセスして個人情報を得ることができる。これは、新規サービス業者の参入が容易となるという効果ももたらす。もちろん、個人情報に変更が生じた場合も、ＩＣＴ用個人情報サーバ１１２が、これまで述べた個人情報登録サーバＤＢ１２と同様にその変更も管理するので、店舗サーバ１１４の管理負担が減少する。

また、図９の本実施の形態においては、利用者がタグＩＤを自宅のパソコンでも店舗でも利用したが、別のハードウェアを用いてもかまわない。

また、これまで、本実施の形態では、主にタグＩＤを中心に動作の説明をしてきたが、ＩＤを付すことができるハードウェアであって利用者が利用できるものであればどのようなものでもかまわない。携帯電話や、ＩＣカード、各種無線機器、スマートフォン等、個人が利用できてＩＤが付されればどのようなハードウェアでも良い。その配給元がＩＤ登録サーバＤＢ１０を設けてさえいればよい。

さらに、１個の機器（デバイス、ハードウェア）ＩＤに対して、複数のサービスを紐付けることができる。従って、利用者がサービス毎に個別の機器（ハードウェア）を持つ必要がなくなり、単一のハードウェアで複数種類のサービスの提供を受けることができる。

逆に、１個のサービスを受けることができるハードウェアも１個に限定する必要はなく、複数のハードウェアでサービスを同様に受けることも当然可能である。自宅でパソコンから（映画サービス等）を予約・申し込み、店舗で携帯電話で本人確認を受けて（映画）サービスを受ける等の使用法も可能であり、利便性に富むサービスを利用者は受けることが可能である。

以上述べたように、図１〜図９に示した本実施の形態によれば、サービス／機器（デバイス）／個人情報管理、を分散して管理している点に特徴がある。また、利用者に対しては、サービスの窓口（例えば店舗サーバ１１４、サービス提供サーバＤＢ１４等）を通じて情報連携させている。さらに、個々の事業自体の規模が小さくても、オープン化によって、新規参入が容易なオープンシステムを実現することができる。

１０ ＩＤ登録サーバＤＢ
１０ａ タグＩＤ登録サーバＤＢ
１０ｂ デバイスＩＤ登録サーバＤＢ
１０ｃ 端末ＩＤ登録サーバＤＢ
１２ 個人情報登録サーバＤＢ
１４ サービス提供サーバＤＢ
１６ ネットワーク
１００ タウン情報ページ
１１０ 機器管理サーバ
１１２ ＩＣＴ用個人情報サーバ
１１４ 店舗サーバ

Claims (7)

1. ネットワークと、
   前記ネットワークに接続する個人ＩＤ統合サーバと、
   前記ネットワークに接続するサービスサーバと、
   前記ネットワークに接続するハードウェアＩＤ登録サーバと、
   を含み、
   前記個人ＩＤ統合サーバは、
   利用者の個人情報と、前記個人情報を開示するための認証コードと、を格納した個人情報データベースと、
   個人情報の開示要求メッセージを前記サービスサーバから受信し、前記開示要求メッセージ中のパスワードと、ハードウェアＩＤとを、前記ハードウェアＩＤ登録サーバに送信する手段と、
   前記ハードウェアＩＤ登録サーバから、認証コードを含む認証成功のメッセージが返信されてきた場合に、前記返信された認証コードを、前記個人情報データベース中の個人情報に設けられた認証コードと、を比較し、一致している場合は、前記開示要求メッセージに係る個人情報を前記サービスサーバに送信する手段と、
   を含み、
   前記サービスサーバは、
   サービスを要求する利用者から送られてきたハードウェアＩＤと前記パスワードとを含む個人情報の開示要求メッセージを、前記個人ＩＤ統合サーバに送信する手段、
   を含み、前記サービスサーバは、前記個人ＩＤ統合サーバから送信されてきた前記個人情報を利用してサービスを提供し、
   前記ハードウェアＩＤ登録サーバは、
   各ハードウェアにそれぞれ付され、各ハードウェアを識別するハードウェアＩＤと、
   前記各ハードウェアに対応づけられ、前記ハードウェアの利用者であることを表す前記パスワードと、
   前記各ハードウェアに対応づけられ、個人情報を開示するためのコードである認証コードと、
   を格納しているハードウェアデータベースを備え、
   前記ハードウェアＩＤ登録サーバは、
   前記個人ＩＤ統合サーバから送信されてきた前記ハードウェアＩＤ及び前記パスワードと、を受信し、前記ハードウェアデータベース中で前記ハードウェアＩＤに対応づけられている前記パスワードと、前記個人ＩＤ統合サーバから送信されてきたパスワードと、を比較し、一致している場合は、前記ハードウェアＩＤで識別されるハードウェアに対応づけられている前記認証コードを個人ＩＤ統合サーバに送信する手段、
   を備えていることを特徴とする個人ＩＤ統合サーバシステム。
2. ネットワークと、
   前記ネットワークに接続する個人ＩＤ統合サーバと、
   前記ネットワークに接続するサービスサーバと、
   前記ネットワークに接続するハードウェアＩＤ登録サーバと、
   を含み、
   前記個人ＩＤ統合サーバは、
   利用者の個人情報と、前記個人情報を開示するための認証コードと、を格納した個人情報データベースと、
   個人情報の開示要求メッセージを前記サービスサーバから受信し、前記開示要求メッセージ中の認証コードと、前記個人情報データベース中の個人情報に設けられた認証コードとを、比較し、一致している場合は、前記開示要求メッセージに係る個人情報を前記サービスサーバに返信する手段と、
   を含み、
   前記サービスサーバは、
   サービスを要求する利用者から送られてきたハードウェアＩＤとパスワードとを含む個人情報の認証要求メッセージを、前記ハードウェアＩＤ登録サーバに送信する第１手段と、
   前記ハードウェアＩＤ登録サーバから前記認証コードを含む認証成功のメッセージが返信されてきた場合に、前記認証コードを含む個人情報の開示要求メッセージを、前記個人ＩＤ統合サーバに送信する第２手段と、
   を含み、前記サービスサーバは、前記個人ＩＤ統合サーバから返信されてきた前記個人情報を利用してサービスを提供し、
   前記ハードウェアＩＤ登録サーバは、
   各ハードウェアにそれぞれ付され、各ハードウェアを識別するハードウェアＩＤと、
   前記各ハードウェアに対応づけられ、前記ハードウェアの利用者であることを表す前記パスワードと、
   前記各ハードウェアに対応づけられ、個人情報を開示するためのコードである認証コードと、
   を格納しているハードウェアデータベースを備え、
   前記ハードウェアＩＤ登録サーバは、
   前記サービスサーバから送信されてきた前記ハードウェアＩＤ及び前記パスワードと、を受信し、前記ハードウェアデータベース中で前記ハードウェアＩＤに対応づけられている前記パスワードと、前記サービスサーバから送信されてきたパスワードと、を比較し、一致している場合は、前記ハードウェアＩＤで識別されるハードウェアに対応づけられている前記認証コードを前記サービスサーバに送信する手段、
   を備えていることを特徴とする個人ＩＤ統合サーバシステム。
3. 請求項１記載の個人ＩＤ統合サーバシステムに用いられる前記個人ＩＤ統合サーバにおいて、
   利用者の個人情報と、前記個人情報を開示するための認証コードと、を格納した個人情報データベースと、
   個人情報の開示要求メッセージを前記サービスサーバから受信し、前記開示要求メッセージ中のパスワードと、ハードウェアＩＤとを、前記ハードウェアＩＤ登録サーバに送信する手段と、
   前記ハードウェアＩＤ登録サーバから、認証コードを含む認証成功のメッセージが返信されてきた場合に、前記返信された認証コードを、前記個人情報データベース中の個人情報に設けられた認証コードと、を比較し、一致している場合は、前記開示要求メッセージに係る個人情報を前記サービスサーバに送信する手段と、
   を含むことを特徴とする個人ＩＤ統合サーバ。
4. 請求項２記載の個人ＩＤ統合サーバシステムに用いられる前記個人ＩＤ統合サーバにおいて、
   利用者の個人情報と、前記個人情報を開示するための認証コードと、を格納した個人情報データベースと、
   個人情報の開示要求メッセージを前記サービスサーバから受信し、前記開示要求メッセージ中の認証コードと、前記個人情報データベース中の個人情報に設けられた認証コードとを、比較し、一致している場合は、前記開示要求メッセージに係る個人情報を前記サービスサーバに返信する手段と、
   を含むことを特徴とする個人ＩＤ統合サーバ。
5. 請求項１に記載の個人ＩＤ統合サーバシステムに用いられる前記ハードウェアＩＤ登録サーバにおいて、
   前記各ハードウェアにそれぞれ付され、各ハードウェアを識別する前記ハードウェアＩＤと、
   前記各ハードウェアに対応づけられ、前記ハードウェアの利用者であることを表す前記パスワードと、
   前記各ハードウェアに対応づけられ、個人情報を開示するためのコードである前記認証コードと、
   を格納している前記ハードウェアデータベースを備え、
   前記ハードウェアＩＤ登録サーバは、
   前記個人ＩＤ統合サーバから送信されてきた前記ハードウェアＩＤ及び前記パスワードと、を受信し、前記ハードウェアデータベース中で前記ハードウェアＩＤに設けられた前記パスワードと、前記個人ＩＤ統合サーバから送信されてきたパスワードと、を比較し、一致している場合は、前記ハードウェアＩＤで識別されるハードウェアに設けられた前記認証コードを前記個人ＩＤ統合サーバに送信する前記手段、
   を備えていることを特徴とするハードウェアＩＤ登録サーバ。
6. 請求項２に記載の個人ＩＤ統合サーバシステムに用いられる前記ハードウェアＩＤ登録サーバにおいて、
   前記各ハードウェアにそれぞれ付され、各ハードウェアを識別する前記ハードウェアＩＤと、
   前記各ハードウェアに対応づけられ、前記ハードウェアの利用者であることを表す前記パスワードと、
   前記各ハードウェアに対応づけられ、個人情報を開示するためのコードである前記認証コードと、
   を格納している前記ハードウェアデータベースを備え、
   前記ハードウェアＩＤ登録サーバは、
   前記サービスサーバから送信されてきた前記ハードウェアＩＤ及び前記パスワードと、を受信し、前記ハードウェアデータベース中で前記ハードウェアＩＤに設けられた前記パスワードと、前記サービスサーバから送信されてきたパスワードと、を比較し、一致している場合は、前記ハードウェアＩＤで識別されるハードウェアに設けられた前記認証コードを前記サービスサーバに送信する前記手段、
   を備えていることを特徴とするハードウェアＩＤ登録サーバ。
7. 請求項５又は６記載のハードウェアＩＤ登録サーバにおいて、
   前記ハードウェアは、通信端末、タグ、ＩＣカード、通信インターフェース、のいずれかであることを特徴とするハードウェアＩＤ登録サーバ。

Images