(57)【要約】【課題】  紙の名刺とのデータの連動性を担保しつつ個人の所有する複数の種類の名刺を簡便に管理でき、また名刺情報の変更の際、その変更を反映させる対象相手を適切に管理でき、管理主体の異なる名刺情報と個人アドレス帳に対しても対応可能なこと。【解決手段】  名刺交換をした相手の名刺情報とその名刺と交換のために相手に差し出された自己の名刺IDとが互いに関連付けられて保存されているアドレス帳データ保存エリアと、自己の名刺情報とその名刺との交換のために差し出された相手の名刺IDとが互いに関連付けられて保存されているキャリアレコード保存エリアとを有するユーザデータ保存領域132と、自己の名刺情報の更新時に、ユーザデータ保存領域の自己の名刺情報を更新すると共に更新対象ユーザのユーザデータ保存領域中の自己の名刺情報の更新を実行するアドレス帳保守手段127と、ユーザデータ保存領域の名刺情報を出力する出力手段128とを備える。【選択図】      図１
2005107877.tif 000002
【特許請求の範囲】
【請求項１】
名刺情報を入力してアドレス帳の情報として保存する名刺情報管理システムであって、
名刺交換をした相手の名刺情報とその名刺と交換のために相手に差し出された自己の名刺IDとが互いに関連付けられて保存されているアドレス帳データ保存エリアと、自己の名刺情報とその名刺との交換のために差し出された相手の名刺IDとが互いに関連付けられて保存されているキャリアレコード保存エリアと、を有するユーザデータ保存領域と、
自己の名刺情報の更新時に、前記ユーザデータ保存領域の自己の名刺情報を更新すると共に、更新対象ユーザのユーザデータ保存領域中の自己の名刺情報の更新を実行するアドレス帳保守手段と、
前記ユーザデータ保存領域の名刺情報を出力する出力手段と、
を備えたことを特徴とする名刺情報管理システム。
【請求項２】
前記アドレス帳データ保存エリアと前記キャリアレコード保存エリアは、それぞれ異なるアクセス権限を設定可能に構成されていることを特徴とする請求項１記載の名刺情報管理システム。
【請求項３】
前記アドレス帳データ保存エリアは、相手の差し出した名刺を受領したことを表す受領ステータスと、自己の差し出した名刺が受領されたことを表す受領通知受信ステータスと、を備え、
前記アドレス帳データ保存エリアおよび前記キャリアレコード保存エリアは、前記両ステータスに基づいて設定され名刺交換成立状態であることを表す交換ステータスをそれぞれ備えていることを特徴とする請求項１または２記載の名刺情報管理システム。
【請求項４】
名刺に記載される情報コード化された名刺IDは、前記名刺情報管理システムの動作を変更可能な動作制御情報を含み、
名刺情報の要求元ユーザが前記動作制御情報を含む名刺IDに基づいて名刺情報の取得要求を行ったときは、該名刺IDに含まれる前記動作制御情報に従って動作することを特徴とする請求項３記載の名刺情報管理システム。
【請求項５】
名刺情報の授受に関し要求元ユーザと要求先ユーザとの間の交換状態の管理を行うための要求元処理部と要求先処理部とを有し、
前記要求元処理部は、要求元ユーザの名刺情報と、要求先ユーザの名刺IDとを含む名刺情報取得要求を前記要求先処理部へ送り、
前記要求先処理部は、前記名刺情報取得要求を受け取ると、要求元ユーザの名刺情報を要求先ユーザのユーザデータ保存領域に保存し、該ユーザデータ保存領域に保存されている前記名刺IDに対応する名刺情報を抽出して前記要求元処理部へ送り、
前記要求元処理部は、要求先ユーザの名刺情報を受け取ると、要求元ユーザのユーザデータ保存領域に保存すると共に名刺情報の受領ステータスフラグをセットして、受領通知を前記要求先処理部へ送り、
前記要求先処理部では、該受領通知を受け取ると要求先ユーザのユーザデータ保存領域の受領通知受信ステータスフラグをセットし、
その後、要求先ユーザ端末から要求元ユーザの名刺情報取得要求の送信があったときは、前記要求先処理部は、要求先ユーザのユーザデータ保存領域に既に要求元ユーザの名刺情報が存在することを条件に要求先ユーザの受領ステータスフラグをセットすると共に交換ステータスフラグをセットして、前記要求元処理部へ受領通知を送り、
前記要求元処理部は、該受領通知を受け取ると、受領通知受信ステータスフラグをセットすると共に、交換ステータスフラグをセットする名刺情報交換管理手段を備えたことを特徴とする請求項３記載の名刺情報管理システム。
【請求項６】
名刺作成業者ごとに、該名刺作成業者の名刺形式を統一形式に変換するための一または二以上の名刺情報変換アルゴリズムと、
名刺作成業者のサーバから送られてくる名刺情報および名刺IDを受信する名刺情報取得手段と、
名刺IDに含まれる情報を用いて、利用する名刺情報変換アルゴリズムを選択する手段と、
この選択された名刺情報変換アルゴリズムを用いて、前記名刺情報取得手段によって受信された名刺情報を統一形式に変換して前記名刺IDに対応するユーザデータ保存領域のキャリアレコード保存エリアに保存する名刺情報変換手段と、
を備えたことを特徴とする請求項１ないし５のいずれか一に記載の名刺情報管理システム。
【請求項７】
前記ユーザデータ保存領域は、アドレス帳データ保存エリアおよび／またはキャリアレコード保存エリアに格納されている名刺情報の転送元および転送先のユーザデータ保存領域識別情報と、転送許容回数と、を含み、
前記ユーザデータ保存領域識別情報に基づいて前記転送許容回数の範囲内で名刺情報を転送し、前記転送回数はアドレス帳データおよび／またはキャリアレコードの原所有者のみが制御可能に構成された名刺情報転送手段を備えたことを特徴とする請求項１ないし６のいずれか一に記載の名刺情報管理システム。
【請求項８】
前記名刺情報転送手段は、転送先ユーザの属性情報によって、転送実行の可否を判定することを特徴とする請求項７記載の名刺情報管理システム。
【請求項９】
端末の機種と当該端末のアドレス帳データ形式とを関連付けて保存する手段と、
ユーザ端末の識別情報を入力する手段と、
前記入力されたユーザ端末の識別情報をもとに端末の機種を抽出して該ユーザのアドレス帳データをユーザ端末のアドレス帳データ形式に変換して前記ユーザ端末へ送信する手段と、
を備えたことを特徴とする請求項１ないし８のいずれか一に記載の名刺情報管理システム。
【請求項１０】
一または二以上の名刺作成業者のサーバから送られてくる名刺情報を電子名刺管理業者のサーバに入力して、アドレス帳の情報として保存すると共にユーザ端末に該アドレス帳の情報を送信する名刺情報管理方法であって、
名刺作成業者ごとに、該名刺作成業者の名刺形式を統一形式に変換するための一または二以上の名刺情報変換アルゴリズムを保存するステップと、
名刺IDに含まれる情報を用いて、利用する名刺情報変換アルゴリズムを選択するステップと、
名刺作成業者のサーバから送られてくる名刺情報を受信し、この受信した名刺情報を前記選択された名刺情報変換アルゴリズムを用いて統一形式に変換して前記名刺IDに対応するユーザデータ保存領域に保存するステップと、
ユーザ端末から送られてくる名刺から読み取られた名刺IDを入力するステップと、
該名刺IDに対応するユーザデータ保存領域から該当する名刺情報を抽出して、前記ユーザ端末に関連付けられたユーザデータ保存領域のアドレス帳データ保存エリアに保存するステップと、
該アドレス帳データ保存エリアに保存されている情報を前記ユーザ端末へ送信するステップと、
を含むことを特徴とする名刺情報管理方法。
【請求項１１】
名刺作成業者のサーバでの名刺情報更新情報を取得するステップと、
名刺情報の更新があったときに、更新に係る名刺IDと名刺情報を取得するステップと、
名刺情報を統一形式に変換して、前記名刺IDに関連付けされているユーザデータ保存領域のキャリアレコード保存エリアに保存するステップと、
前記キャリアレコード保存エリアに当該名刺IDと関連付けされている名刺交換状態にある名刺IDを抽出するステップと、
該交換状態にある名刺IDのアドレス帳データ保存エリアの名刺情報を更新するステップと、
を含むことを特徴とする請求項１０記載の名刺情報管理方法。
【請求項１２】
前記名刺情報は、この名刺情報を所有するユーザの名刺IDまたはこれと関連付けられた情報を用いて暗号化されて保存されており、名刺情報読み出しの際、ユーザ端末との通信接続が確立した段階で、端末識別情報による認証を行い、その後この端末識別情報に対応するユーザのアドレス帳保存エリアに保存されている名刺情報の復号化処理を開始し、ユーザからの名刺情報読み出し要求によって、復号化処理の完了した名刺情報を前記ユーザ端末へ送信することを特徴とする請求項１０または１１記載の名刺情報管理方法。
【請求項１３】
請求項１０ないし１２のいずれか一に記載の名刺情報管理方法に用いられる名刺であって、少なくとも名刺作成業者識別情報、ユーザ識別情報および名刺作成業者における名刺情報を識別可能な情報を含む名刺IDの情報コードを記載されていることを特徴とする名刺。
【請求項１４】
前記情報コードには、暗号化された名刺IDと暗号化されない名刺情報管理サービス情報が含まれていることを特徴とする請求項１３記載の名刺。
【請求項１５】
一または二以上の名刺作成業者のサーバから送られてくる名刺データを入力して、アドレス帳の情報として保存すると共にユーザ端末に該アドレス帳の情報を送信する名刺情報管理用プログラムであって、
名刺作成業者ごとに、該名刺作成業者の名刺形式を名刺情報管理システムの統一形式に変換するための一または二以上の名刺情報変換アルゴリズムを保存する処理と、
名刺IDに含まれる情報を用いて、利用する名刺情報変換アルゴリズムを選択する処理と、
名刺作成業者のサーバから送られてくる名刺情報を受信し、この受信した名刺情報を前記選択された名刺情報変換アルゴリズムを用いて統一形式に変換して前記名刺IDに対応するユーザデータ保存領域に保存する処理と、
ユーザ端末から送られてくる名刺から読み取られた名刺IDを入力する処理と、
該名刺IDに対応するユーザデータ保存領域から該当する名刺情報を抽出して、前記ユーザ端末に関連付けられたユーザデータ保存領域のアドレス帳データ保存エリアに保存する処理と、
前記アドレス帳データ保存エリアに保存されている名刺情報を前記ユーザ端末へ送信する処理と、
をコンピュータに実行させるためのプログラム。
【請求項１６】
請求項１４記載の名刺に記載されている情報コードを読み取り、電子名刺管理業者のサーバへ名刺情報の取得要求を送信するユーザ端末用プログラムであって、
前記情報コードの中から名刺IDを抽出する処理と、
抽出された名刺IDに該サーバへ送信するためのアドレス情報を付加する処理と、
該アドレス情報および名刺IDを前記ユーザ端末の画面へ表示する処理と、
確認入力によって前記名刺IDを含む名刺情報の取得要求を該サーバへ送信する処理と、をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、紙の名刺とネットワーク上のアドレス帳を連携させる技術に係り、特に名刺作成サービスを提供する他のプロバイダとの間でもその名刺情報からアドレス帳の作成・更新が可能な名刺、名刺情報管理システム、名刺情報管理方法、および、プログラムに関する。
【背景技術】
【０００２】
一般に、世の中では、紙の名刺（これをPaper Business Card、略称PBCと呼ぶ）が広く用いられている。
従来、PBCの利用モデルにおいては、企業や各種の団体（これらを総称して組織と呼ぶ）が信頼して選択した名刺サービスプロバイダ（名刺の印刷業者や企業内の名刺印刷部門をいう。以下Service Provider、略称SPと呼ぶ）が、組織の許諾を得て組織メンバのPBCに記載されているデータ（組織の名称、組織メンバの氏名と役職、組織の所在地、連絡先など）の原本（これをマスターデータと呼ぶ）を保管する。SPは、組織からの情報提供と許諾を得てPBCデータの生成（入力）及び更新を行う。この仕組みにより、PBCデータの信憑性、信頼性は組織により担保されている。
【０００３】
PBCのマスターデータがSPにより保管されている一方で、組織メンバは一定数のPBCを常時手元に保管することが組織により許諾されている。すなわち、組織メンバは手持ちの名刺が少なくなると、組織の許諾を得た上で、名刺サービスプロバイダに対して一定数の名刺を発注することができる（一般に1箱100枚入りで、箱単位で注文できる）。この仕組みにより、組織メンバは、組織メンバとしての日常の様々な業務活動（これをアクティビティと呼ぶ）においてPBCを必要とした際に、その都度SPに依頼することなく、手持ちの名刺箱からPBCを取り出して交換相手に渡すことが可能になる。
【０００４】
組織メンバはPBCを常時携帯し、アクティビティ中に出会った様々な人に対してPBCを渡すことができる。すなわち、組織メンバはアクティビティ中に新たな人達と出会うことで、PBCの交換相手を拡大して行くことができる。
【０００５】
近年、企業の事業活動が高度化・複雑化しており、既存の組織体制とは別に組織横断的なプロジェクトチームを組成するケースが増えている。また、複数の企業に勤務する人や、複数の団体に所属して多様なアクティビティに従事する人も多い。こうした個人は複数のPBCを携帯し、状況に応じて異なるPBCを使い分けている。すなわちPBCは、複数の組織に所属し複数のアクティビティに従事する個人が新たな人と出会った際に、出会いの文脈に応じて異なるPBCを相手に差し出し、自己のアイデンティティ（社会における位置付け）を使い分けることを可能とする。
【０００６】
しかしながら、PBCは、以下に掲げる短所を有している。
すなわち、PBCは、交換相手の数が増えて保管するPBCの数が増大すると、見たいPBCの検索に手間取ったり検索できなくなるなど管理がしだいに難しくなる。
PBCに記載されている情報に加えて、PBC交換時の状況や相手に関する付加的な情報（風貌、担当業務の詳細、性格など）を記述しようとすると、PBCの余白部分に書き込むこととなり記述できる情報の量が限られる。
PBCに記載されている情報を、PBCの受け取り手がパソコン、PDA、携帯電話（これらを総称して情報機器と呼ぶ）などに入力して管理したいと思ったとき、PBCの受け取り手は手入力により記載情報を情報機器に入力する必要がある。
PBCに記載されている情報は、名刺提供者の組織の中での位置付け（役職、役割）が変わったり、組織の事務所が移転したりすると陳腐化する。最新情報に更新するためには、相手に電話やメールなどでコンタクトして最新情報を教えてもらう必要がある。
複数のPBCを携帯し、アクティビティの文脈に応じて異なるPBCを使い分けている人にとっては、どのPBCをどの相手に渡したかを管理しておくことが難しい。
複数の組織に所属する人は、アクティビティに応じて複数の事務所で執務することが多い。事務所ごとにそれぞれ名刺フォルダがあり、どのアクティビティの文脈で出会った人かによって対応する名刺フォルダに仕分けしてPBCを管理している。こうした場合、自分が保管する全ての名刺を一元的に閲覧することが難しいという問題がある。
【０００７】
上述のPBCの短所を解決あるいは補完するために、情報技術を活用したいくつかのシステムが考案され実用化されている。
まず、PBCの記載情報を情報機器に取り込む際の手入力の煩わしさを解決する方法として、PBCに印刷されている全文字列をOCRおよび文字認識ソフトウェアで直接情報機器に取り込むシステム、PBCの記載情報をバーコードや二次元コードにコード化してPBC上に印刷しておき、それをコードリーダで情報機器に取り込むシステムなどが考案されている。（例えば、特許文献１を参照）。
【０００８】
いずれの方式も、データのマスターがPBCに印刷されたものであるために、相手の組織や役割が変わるとPBCと同じく取得情報が陳腐化してしまうという問題がある。
また、情報の陳腐化の問題を解決するシステムとして、情報機器やサーバ上に個人の"オンラインアドレス帳"を開設しておき、自分の名刺情報が変わった際にはネットワークを通じて相手のオンラインアドレス帳の情報を自動的に書き換えるシステム（これを電子名刺と呼ぶ）が考案されている。（例えば、特許文献２ないし３を参照）。この電子名刺のシステムには以下の問題点がある。
【０００９】
１）電子名刺では自分の名刺情報を自分で生成・管理するモデルになっている。すなわち情報機器やサーバ上に自分の名刺情報を保持しておく領域が用意されており、自分の名刺情報を自分でその領域に入力し、また名刺情報が変わった場合も変更を自分で入力する。このためPBCが長所として持っている、「名刺情報が組織によって担保されるメリット」を喪失している。
【００１０】
２）電子名刺ではオンラインアドレス帳間での名刺情報のやり取りが、PBCのやりとりと関連づけられていない。すなわち、日常のアクティビティの中で人と出会った際にはPBCを交換し、情報ネットワークを介して人と出会った際には電子名刺を交換するという分断された状況を生んでしまっている。電子名刺の世界で新たな人と名刺交換しようとすると、何らかの方法で他人の名刺情報を検索した上で相手に自分の電子名刺を送付することになる。つまり他人が名刺情報をネットワーク上で公開することが名刺交換の前提になる。  しかし実際には多くの人はネットワーク上で自分の名刺情報を公開し検索されることを望まないため、結果として電子名刺の交換は活性化されない。一方PBCの世界では、既に述べたように日常の様々なアクティビティの中で人と人との新たな出会いが発生し、その都度新たな名刺交換の機会が生まれるので、名刺交換が活性化される仕組みが備わっている。電子名刺を如何にPBCの仕組みと連動させて、ネットワーク上での名刺交換を促進するかという問題がある。
【００１１】
３）従来の電子名刺システムでは、1個人は単一の名刺情報（個人のプロフィール情報）を保有することが前提されている。システムは、「だれがだれと名刺を交換したのか」を管理しており、ある個人が名刺情報を更新すると、その個人が電子名刺を渡した相手全員のオンラインアドレス帳に対してシステムが更新された情報を書き込みにいく。しかし既に述べたように昨今では複数の名刺情報を保有し、出会いの文脈に応じて異なる名刺情報（＝異なるアイデンティティ）を使い分ける個人が増えている。こうした今日的環境において人と人との名刺交換関係を正確に把握するには、「だれがだれと名刺交換したのか」を管理するだけでは不十分であり、「だれがだれとどの名刺を交換したのか」を管理する必要がある。
【特許文献１】特開２００１−２６０５７５号公報
【特許文献２】特開２００３−６７３９２号公報
【特許文献３】特開２００３−１０８４７９号公報
【特許文献４】特開２００３−１２２７６２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明はかかる従来の事情に対処してなされたものであり、紙の名刺とのデータの連動性を担保しつつ個人の所有する複数の種類の名刺を簡便に管理でき、また名刺情報の変更の際、その変更を反映させる対象相手（更新対象者）を適切に管理でき、管理主体の異なる名刺情報と個人アドレス帳に対しても対応することのできる名刺、名刺情報管理システム、名刺情報管理方法、および、プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記目的を達成するため、本発明に係わる名刺情報管理システムは、名刺情報を入力して、アドレス帳の情報として保存する名刺情報管理システムであって、名刺交換をした相手の名刺情報とその名刺と交換のために相手に差し出された自己の名刺IDとが互いに関連付けられて保存されているアドレス帳データ保存エリアと、自己の名刺情報とその名刺との交換のために差し出された相手の名刺IDとが互いに関連付けられて保存されているキャリアレコード保存エリアと、を有するユーザデータ保存領域と、自己の名刺情報の更新時に、ユーザデータ保存領域の自己の名刺情報を更新すると共に、更新対象ユーザのユーザデータ保存領域中の自己の名刺情報の更新を実行するアドレス帳保守手段と、ユーザデータ保存領域の名刺情報を出力する出力手段とを備えたことを特徴とする。
【００１４】
ここで、「更新」とは、旧情報に対して新情報を上書きする場合のほか、旧情報はそのまま残しておき、新情報を順次追加していく場合も含む趣旨である。なお、後者の場合、所定期間以前の情報あるいは所定の更新回数を超えた場合については古い情報から削除するようにしてもよい。
【００１５】
好ましくは、アドレス帳データ保存エリアとキャリアレコード保存エリアは、それぞれ異なるアクセス権限を設定可能に構成するとよい。
名刺情報をアドレス帳データ保存エリアとキャリアレコード保存エリアに分けて管理することによって、たとえばキャリアレコード保存エリアに保存されている自己の名刺情報を活用できると共に、秘密性の高いアドレス帳データのセキュリティを担保することができる。また、逆に、キャリアレコード保存エリアのデータは自己の履歴情報として使用できるため、セキュリティを高くして運用することも可能である。
【００１６】
なお、アドレス帳データ保存エリアとキャリアレコード保存エリアは物理的に同じ記憶領域に格納する必要はなく、ユーザ識別情報など名刺IDの一部または全部をインデックスとしてリンクできるようにしておいてもよい。
【００１７】
また、両保存エリアは、それぞれ異なるデータベースに保存するようにして、そのデータベースはセキュリティレベルを変更可能にしておくことも効果的である。特に、アドレス帳データ保存エリアの情報は、個人の活動に伴って蓄積される秘密性の高い情報が保存されことになるため、セキュリティレベルを高くして構築するとよい。このようにすれば、アドレス帳データの重要な情報のみを特別に管理でき、全ての情報を同じセキュリティレベルで管理することに比べて、高セキュリティのシステムを低コストで実現することができる。
【００１８】
ここで、セキュリティレベルを変えるとは、たとえば、データベースにアクセスするときに、特別な認証を必要とするとか、ファイアウォールによって、外部の脅威から保護するなどの対応などのことである。また、名刺IDとは、名刺作成業者、ユーザ、役割（ロール）、あるいは、版（バージョン）など名刺を識別可能な情報を意味する。また、名刺IDは、コード化、暗号化されているものも含む。なお、名刺IDに含める情報として、名刺作成業者の識別情報の代わりに、名刺作成業者の所有するデータベースもしくは名刺管理単位に識別情報を設けるようにしてもよい。
【００１９】
本発明に係わる名刺情報管理システムでは、さらに、アドレス帳データ保存エリアは、相手の差し出した名刺を受領したことを表す受領ステータスと、自己の差し出した名刺が受領されたことを表す受領通知受信ステータスと、を備え、アドレス帳データ保存エリアおよびキャリアレコード保存エリアは、両ステータスに基づいて設定され、名刺交換成立状態であることを表す交換ステータスをそれぞれ備えていることを特徴とする。
受領ステータス、受領通知受信ステータス、および、交換ステータスを用いることによって名刺の交換状態を適切に管理することが可能となる。
特にアドレス帳データ保存エリアとキャリアレコード保存エリアで管理権限が異なる場合は、独立して運用されることになるため、それぞれに交換ステータスを備えておくと有効である。
【００２０】
好ましくは、名刺に記載される情報コード化された名刺IDは、名刺情報管理システムの動作を変更可能な動作制御情報を含み、名刺情報の要求元ユーザが動作制御情報を含む名刺IDに基づいて名刺情報の取得要求を行ったときは、該名刺IDに含まれる動作制御情報に従って動作するようにするとよい。
【００２１】
動作制御情報は、たとえば、名刺交換の許諾を自動的に行うか否かを決定する情報であり、この情報が名刺IDに含まれているときは、名刺情報の要求先ユーザの許諾入力を必要とせず、直ちに交換成立状態にするなどである。なお、この場合、通常は自動的に交換成立状態にして、動作制御情報によっては、許諾入力を必要とするというような運用にしてもよい。名刺配布時に、相手が名刺情報を要求したときに自動的に交換成立状態すなわち更新対象にするか、許諾入力（自分が取得した名刺のスキャンをするなど）を必要とするかによって配布する名刺を変えるようにすれば、都度、交換成立のために許諾入力をする必要がなくなるので利便性が向上する。
【００２２】
なお、動作制御情報によって、情報コードの印刷位置あるいは色彩など、名刺のデザインを変えるようにするとよい。名刺に記載されている情報は変更せず、デザインのみ多少変更することによって、社会活動には影響を与えず動作制御情報の識別が可能となるからである。
【００２３】
動作制御情報としては、上記の他、確認画面で更新対象か否かの入力を促すようにする、あるいは、自己情報の開示レベルなどがある。自己情報の開示レベルとは、アドレス帳データ保存エリアには名刺情報以外の個人情報も保存しておき、名刺交換の相手方から名刺情報の取得要求があったときに、開示レベルに応じて、所定範囲の個人情報を提供するものである。
【００２４】
また、本発明に係わる名刺情報管理システムは、さらに、名刺情報の授受に関し要求元ユーザと要求先ユーザとの間の交換状態の管理を行うための要求元処理部と要求先処理部とを有し、要求元処理部は、要求元ユーザの名刺情報と、要求先ユーザの名刺IDとを含む名刺情報取得要求を要求先処理部へ送り、要求先処理部は、名刺情報取得要求を受け取ると、要求元ユーザの名刺情報を要求先ユーザのユーザデータ保存領域に保存し、該ユーザデータ保存領域に保存されている名刺IDに対応する名刺情報を抽出して要求元処理部へ送り、要求元処理部は、要求先ユーザの名刺情報を受け取ると、要求元ユーザのユーザデータ保存領域に保存すると共に名刺情報の受領ステータスフラグをセットして、受領通知を要求先処理部へ送り、要求先処理部では、該受領通知を受け取ると要求先ユーザのユーザデータ保存領域の受領通知受信ステータスフラグをセットし、その後、要求先ユーザ端末から要求元ユーザの名刺情報取得要求の送信があったときは、要求先処理部は、要求先ユーザのユーザデータ保存領域に既に要求元ユーザの名刺情報が存在することを条件に要求先ユーザの受領ステータスフラグをセットすると共に交換ステータスフラグをセットして、要求元ユーザへ受領通知を送り、要求元処理部は、該受領通知を受け取ると、受領通知受信ステータスフラグをセットすると共に、交換ステータスフラグをセットする名刺情報交換管理手段を備えたことを特徴とする。
【００２５】
受領ステータス、受領通知受信ステータス、および、交換ステータスを上記のように動作させることによって、通常、非同期で行われるネットワーク上の名刺交換を適切に管理することが可能となる。
ここで、名刺を交換した二者において、先に名刺情報の取得要求をした方を「要求元」、後から名刺情報の取得要求をしたものを「要求先」という。
【００２６】
また、本発明に係わる名刺情報管理システムは、さらに、名刺作成業者ごとに、該名刺作成業者の名刺形式を統一形式に変換するための一または二以上の名刺情報変換アルゴリズムと、名刺作成業者のサーバから送られてくる名刺情報および名刺IDを受信する名刺情報取得手段と、名刺IDに含まれる情報を用いて、利用する名刺情報変換アルゴリズムを選択する手段と、選択された名刺情報変換アルゴリズムを用いて、名刺情報取得手段によって受信された名刺情報を統一形式に変換して名刺IDに対応するユーザデータ保存領域のキャリアレコード保存エリアに保存する名刺情報変換手段とを備えたことを特徴とする。
【００２７】
名刺作成業者ごとに変換アルゴリズムを備えることによって、名刺作成業者によって異なる名刺形式を一括して統一形式に変換することができる。「名刺IDに含まれる情報」としては、名刺作成業者ごとに割り付けられたデータベース識別情報（D-ID）などがある。また、「名刺情報変換アルゴリズム」とは、特定の規則に従って名刺情報の形式を変換する手段を意味し、データ項目対応テーブルとそのテーブルを参照して変換を実行するロジックを含む趣旨である。
【００２８】
なお、名刺作成業者ごとにその変換アルゴリズムを保存する代わりに、変換アルゴリズムをパターン化しておき、名刺作成業者と該パターンとの対応テーブルを保存するようにしてもよい。
ここで、統一形式とは、名刺情報管理システムで管理するための形式を意味する。一般的には、vCard形式などの汎用的な形式が採用される。
【００２９】
また、本発明に係わる名刺情報管理システムでは、さらに、ユーザデータ保存領域は、アドレス帳データ保存エリアおよび／またはキャリアレコード保存エリアに格納されている名刺情報の転送元および転送先のユーザデータ保存領域識別情報と、転送許容回数と、を含み、ユーザデータ保存領域識別情報に基づいて転送許容回数の範囲内で名刺情報を転送し、転送回数はアドレス帳データおよび／またはキャリアレコードの原所有者のみが制御可能に構成された名刺情報転送手段を備えたことを特徴とする。
転送回数を制御可能にすることによって無制限な転送を防止することができる。
【００３０】
好ましくは、名刺情報転送手段は、転送先ユーザの属性情報によって、転送実行の可否を判定するようにするとよい。
たとえば、転送条件テーブルを設けて、転送先のユーザの属性がその条件に該当しなければ転送をしないようにする。これによって、原則として指定回数分の転送は許容しつつも、名刺情報のオーナーの意向に沿わないユーザへの転送をしないようにすることができる。
【００３１】
また、本発明に係わる名刺情報管理システムは、さらに、端末の機種と当該端末のアドレス帳データ形式とを関連付けて保存する手段と、ユーザ端末の識別情報を入力する手段と、入力されたユーザ端末の識別情報をもとに端末の機種を抽出して該ユーザのアドレス帳データをユーザ端末のアドレス帳データ形式に変換してユーザ端末へ送信する手段と、を備えたことを特徴とする。
ユーザ端末に合わせた形式でアドレス帳データを送信することによって、端末にダウンロードして見ることができるため利便性が向上する。
ここで、端末の機種とは、端末を機能に応じてグループ化したものを意味し、たとえば、携帯電話の場合は、キャリア会社あるいは型式などを含む。
【００３２】
また、本発明に係わる名刺情報管理方法は、一または二以上の名刺作成業者のサーバから送られてくる名刺情報を電子名刺管理業者のサーバに入力して、アドレス帳の情報として保存すると共にユーザ端末に該アドレス帳の情報を送信する名刺情報管理方法であって、名刺作成業者ごとに、該名刺作成業者の名刺形式を統一形式に変換するための一または二以上の名刺情報変換アルゴリズムを保存するステップと、名刺IDに含まれる情報を用いて、利用する名刺情報変換アルゴリズムを選択するステップと、名刺作成業者のサーバから送られてくる名刺情報を受信し、この受信した名刺情報を選択された名刺情報変換アルゴリズムを用いて統一形式に変換して名刺IDに対応するユーザデータ保存領域に保存するステップと、ユーザ端末から送られてくる名刺から読み取られた名刺IDを入力するステップと、該名刺IDに対応するユーザデータ保存領域から該当する名刺情報を抽出して、ユーザ端末に関連付けられたユーザデータ保存領域のアドレス帳データ保存エリアに保存するステップと、該アドレス帳データ保存エリアに保存されている情報をユーザ端末へ送信するステップと、を含むことを特徴とする。
【００３３】
好ましくは、名刺IDをもとにコード化された情報コードを名刺に記載しておき、ユーザ端末の入力手段（たとえばＱＲコードリーダ）でこの情報コードを読み取って名刺IDを復元し、電子名刺管理業者のサーバへ送信するようにするとよい。
名刺作成業者から名刺情報を取得する方法としては、たとえば、名刺作成業者のサーバへ該名刺作成業者におけるユーザを識別可能な名刺IDと共に名刺情報を要求し、名刺作成業者のサーバはこれに応答して名刺情報を送信するというやり方がある。
ここで、「名刺作成業者におけるユーザを識別可能」とは、ユーザ識別情報から直接名刺作成業者のユーザを識別可能であることの他、名刺作成業者のサーバまたは名刺情報管理システムにおいて、該システムと名刺作成業者のユーザの識別情報との対応テーブルをもたせて、名刺作成業者におけるユーザを特定するなど、間接的に識別可能である場合も含む趣旨である。
【００３４】
名刺作成業者のサーバから変化のあった名刺情報を自発的に送信するようにしてもよいが、複数のサーバから同時に大量の名刺情報が送られてくるとシステムの負荷が集中する可能性があるので、たとえば、名刺作成業者のサーバから送信する名刺情報の件数を予め名刺情報管理システムへ通知し、当該システムからの送信要求に基づいて送るようにすると負荷の分散を図ることができる。
【００３５】
なお、名刺情報変換アルゴリズムの保存、および、該アルゴリズムによる統一形式への変換は、名刺作成業者のサーバで行うようにしてもよい。
この場合は、名刺作成業者のサーバは、当該名刺作成業者の名刺情報形式を統一形式であるアドレス帳データ形式に変換するデータ形式変換手段および名刺IDをもとに該名刺作成業者の保存する名刺情報を特定する名刺情報特定手段を保存するステップと、電子名刺管理業者から名刺IDと共に名刺情報送信要求があったときに、名刺情報特定手段によって送信すべき名刺情報を抽出するステップと、抽出した名刺情報をデータ形式変換手段によって、アドレス帳データ形式に変換するステップと、アドレス帳データ形式の名刺情報を電子名刺管理業者のサーバへ送信するステップとを備えることになる。なお、名刺作成業者のサーバにおいて名刺情報に変化があったときに統一形式に変換して、電子名刺管理業者のサーバへ名刺IDと名刺情報を送信するようにしてもよい。
【００３６】
また、本発明に係わる名刺情報管理方法は、さらに、名刺作成業者のサーバでの名刺情報更新情報を取得するステップと、名刺情報の更新があったときに、更新に係る名刺IDと名刺情報を取得するステップと、名刺情報を統一形式に変換して、名刺IDに関連付けされているユーザデータ保存領域のキャリアレコード保存エリアに保存するステップと、キャリアレコード保存エリアに当該名刺IDと関連付けされている名刺交換状態にある名刺IDを抽出するステップと、該交換状態にある名刺IDのアドレス帳データ保存エリアの名刺情報を更新するステップと、を含むことを特徴とする。
名刺作成業者側でユーザの名刺情報の更新があったときは、その名刺情報を取得して、当該ユーザ用のキャリアレコード保存エリアに保存すると共に交換状態にあるユーザのアドレス帳データ保存エリアの名刺情報を更新する。
【００３７】
本発明では、キャリアレコード保存エリアに自分以外の者（たとえば自己の所属する会社など名刺情報を管理する者）に名刺情報の書き込み権限を与えることによって、名刺情報の更新の有無をユーザが意識しなくても自動的に自己の名刺情報が更新され、さらに、名刺交換成立状態にある相手方のアドレス帳の自己の名刺情報を更新することができる。
【００３８】
一方、ユーザにキャリアレコード保存エリアの書き込み権限を与えないことによって、会社は名刺情報の改竄を防止することができる。この他、アドレス帳データ保存エリアやキャリアレコード保存エリア内のデータ項目、たとえば、名刺情報部分とメモ、メッセージ部分の書き込み権限を分けるようにしてもよい。
【００３９】
また、本発明に係わる名刺情報管理方法では、名刺情報は、この名刺情報を所有するユーザの名刺IDまたはこれと関連付けられた情報を用いて暗号化されて保存されており、名刺情報読み出しの際、ユーザ端末との通信接続が確立した段階で、端末識別情報による認証を行い、その後この端末識別情報に対応するユーザのアドレス帳保存エリアに保存されている名刺情報の復号化処理を開始し、ユーザからの名刺情報読み出し要求によって、復号化処理の完了した名刺情報をユーザ端末へ送信することを特徴とする。
【００４０】
本発明では、端末識別情報と暗号化された名刺情報とが関連付けられて保存されており、ユーザ端末と通信（セッション）が確立した時点で、端末識別情報の入力および当該情報による認証を行って対応する名刺情報を復号化処理する。これによって、ユーザがユーザIDやパスワードを入力して名刺情報の送信要求処理を行っている間に復号化処理を実行できるため、システムの応答性能を向上させることができ、かつ、データ保存中のセキュリティを高めることができる。さらに、端末識別情報による認証とユーザID等によるユーザ認証とが一致しないと名刺情報が正常に取得できないので端末またはユーザIDが盗難にあってもデータの漏洩を防ぐことができる。
【００４１】
なお、暗号化は上記の他、名刺作成業者と名刺情報管理システムとの間を暗号化するようにしてもよい。この場合、やり取りするデータごとに名刺情報の管理主体（たとえば会社）のID（識別情報）によって暗号化するようにすると名刺情報更新時のセキュリティを担保することができる。
【００４２】
また、本発明に係わる名刺は、上記の名刺情報管理方法に用いられる名刺であって、少なくとも名刺作成業者識別情報、ユーザ識別情報および名刺作成業者における名刺情報を識別可能な情報を含む名刺IDの情報コードを記載されていることを特徴とする。
名刺IDは、コード化された状態で名刺に記載されているため、他人の名刺IDを入手するためには、基本的に名刺を取り交わすことが必要となるため、自己の名刺情報の不慮の流出を防ぐことができる。また、名刺を交換した相手に対しては、サーバ上で名刺情報の提供に対して許諾を不要にすれば、ユーザの負担を軽減することができる。
【００４３】
本発明による名刺は、名刺IDに名刺作成業者の識別情報を含めるので、異なる複数の名刺作成業者で名刺の作成を行っている各ユーザの名刺情報を取得でき、アドレス帳の情報として一元管理できる。また、本発明では、情報コードで記載するため、名刺交換後にサーバ上で名刺情報を交換する際に円滑かつ簡便に行うことができる。また、名刺に記載されている個人情報（氏名、勤務先、住所など）自体をコード化するのではないため、情報コードのサイズは小さくて済み、名刺の限られた紙面が情報コードで占有されることを避けることができる。
【００４４】
なお、ユーザの社会活動の範囲の拡大に伴い、会社用や個人用など、状況によって名刺を使い分けることを可能にするため、上記情報コードに役割識別情報（ロールID）や名刺の版（バージョン）情報などを含めるようにしてもよい。
ここで、情報コードは、一次元情報コードのバーコードやニ次元情報コードのＱＲコードのようにコード化された情報を意味する。特に紙媒体の名刺のように破損しやすいものについては、ＱＲコードのように一部の情報が欠けても全体を復元可能なコードを用いるようにすると有効である。
【００４５】
なお、好ましくは、情報コードには、暗号化された名刺IDと暗号化されない名刺情報管理サービス情報が含まれているようにするとよい。
これにより、復号化機能のない端末で情報コードを読み込んだ場合でも、サービス業者のアドレスやサービス内容が分かるので、本サービスへの加入の促進を図ることができる。また、名刺上の情報コードの付近にコード化されていない名刺IDを記載するようにして、端末から手入力によって名刺情報の取得要求ができるようにしてもよい。この手入力の場合にもサービス紹介画面へリンクするようにしてもよい。
ここで、名刺情報管理サービス情報とは、名刺情報管理サービス業者のＵＲＬや、サービスの内容に関する情報を意味する。
【００４６】
本発明に係わるプログラムは、一または二以上の名刺作成業者のサーバから送られてくる名刺データを入力して、アドレス帳の情報として保存すると共にユーザ端末に該アドレス帳の情報を送信する名刺情報管理用プログラムであって、名刺作成業者ごとに、該名刺作成業者の名刺形式を名刺情報管理システムの統一形式に変換するための一または二以上の名刺情報変換アルゴリズムを保存する処理と、名刺IDに含まれる情報を用いて、利用する名刺情報変換アルゴリズムを選択する処理と、名刺作成業者のサーバから送られてくる名刺情報を受信し、この受信した名刺情報を選択された名刺情報変換アルゴリズムを用いて統一形式に変換して名刺IDに対応するユーザデータ保存領域に保存する処理と、ユーザ端末から送られてくる名刺から読み取られた名刺IDを入力する処理と、該名刺IDに対応するユーザデータ保存領域から該当する名刺情報を抽出して、ユーザ端末に関連付けられたユーザデータ保存領域のアドレス帳データ保存エリアに保存する処理と、アドレス帳データ保存エリアに保存されている名刺情報をユーザ端末へ送信する処理と、をコンピュータに実行させることを特徴とする。
【００４７】
また、本発明に係わるユーザ端末用プログラムは、名刺に記載されている情報コードを読み取り、電子名刺管理業者のサーバへ名刺情報の取得要求を送信するユーザ端末用プログラムであって、情報コードの中から名刺IDを抽出する処理と、抽出された名刺IDにサーバへ送信するためのアドレス情報を付加する処理と、該アドレス情報および名刺IDをユーザ端末の画面へ表示する処理と、確認入力によって名刺IDを含む名刺情報の取得要求をサーバへ送信する処理とを、コンピュータに実行させることを特徴とする。
暗号化されていない名刺情報管理サービス情報など、名刺情報の取得に必要な名刺ID以外の情報をマスクすることによって、確認処理を迅速・円滑に行うことができる。
【発明の効果】
【００４８】
本発明においては、名刺に記載された情報コードを用いて名刺情報を効率的に取得でき、また、ユーザ本人の名刺情報を保存するキャリアレコード保存エリアと取得した名刺情報を保存するアドレス帳データ保存エリアとに分けてアドレス帳の情報あるいは名刺交換成立状態を管理するので、名刺情報の幅広い活用が可能となり、また名刺情報の変更時には更新対象者を適切に選択でき、さらに、名刺情報を管理するためのデータベースまたは名刺作成業者の識別情報と個人のアドレス帳データを管理するためのユーザ（メンバ）識別情報を個別に設けて名刺識別情報として名刺に記載または貼付するようにしたので、それぞれ管理主体の異なる名刺情報と個人アドレス帳データに対しても対応することが可能となる。
【発明を実施するための最良の形態】
【００４９】
以下に本発明の実施の形態を説明する。図１は、本実施の形態に係わる名刺情報管理システム、このシステムと通信ネットワークを介して繋がるユーザ端末、および、名刺作成業者（以下、名刺作成サービスプロバイダまたはSPという）のサーバの機能ブロック図である。
【００５０】
この図において、名刺情報管理システム１は、通信ネットワーク４を通してデータの送受信を行う送受信部１１、送受信部１１から受け取ったデータの処理を行う中央演算処理部１２、および、データを保存する記憶部１３から構成されている。
【００５１】
また、中央演算処理部１２は、ユーザの個人情報などを登録する基本情報登録手段（機能）１２２、ユーザ端末２との通信の確立処理を行う端末通信手段（機能）１２３、SPサーバ３に対して名刺情報を要求する名刺情報要求手段（機能）１２４、SPサーバ３から送られてくる名刺情報を受信処理する名刺情報取得手段（機能）１２５、名刺情報の交換処理を実行しアドレス帳に反映させる名刺情報交換管理手段（機能）１２６、名刺情報の変更があったときに更新対象者のアドレス帳の名刺情報を更新するアドレス帳保守手段（機能）１２７、アドレス帳などのユーザデータの転送を行う名刺情報転送手段（機能）１２８、および、アドレス帳の情報をユーザ端末２に送信する出力手段（機能）１２９を備えている。
【００５２】
記憶部１３は、ユーザの識別情報や氏名等の個人情報を保存するユーザ情報データベース（DB）１３１、ユーザごとにそのユーザの名刺情報や名刺交換相手の名刺情報などを保存するユーザデータテーブル（ユーザデータ保存領域）１３２、名刺作成サービスプロバイダに関する情報を保存するSPデータベース（DB）１３３を有している。
【００５３】
この名刺情報管理システム１は、電子名刺管理業者（以下、DBCサービス業者という）が運営するサーバとして機能している。
【００５４】
ユーザ端末２は、情報コードの読み取りやデータの入力などを行う入力部２４、名刺情報管理システム１から送られてくるデータを表示する表示部２５、通信ネットワーク４を通してデータの送受信を行う送受信部２１、および、データ処理を行う中央演算処理部２２から構成されている。
【００５５】
またSPサーバ３は、通信ネットワーク４を通してデータの送受信を行う送受信部３１、データ処理を行う中央演算処理部３２、および、名刺情報等のデータを保存する記憶部３３から構成されている。
【００５６】
図２にSPサーバの詳細な機能ブロック図を示す。ここで、中央演算処理部３２は、名刺情報管理システム１からの名刺情報要求を受信する要求情報入力手段（機能）３３２、名刺情報管理システム１から送られてくる名刺ID（名刺識別情報）をSPサーバの識別情報に変換して送信すべき名刺情報を抽出する名刺情報特定手段（機能）３２３、抽出した名刺情報を統一フォーマットに変換するデータ形式変換手段（機能）３２４、および、データ形式変換後の名刺情報を名刺情報管理システムへ送信する名刺情報送信手段（機能）３２５を有している。また、記憶部３３には、名刺情報管理システムとSPサーバ間の識別情報の対応関係を記憶したID管理データベース（DB）３３２とこのSPサービスのユーザの名刺情報を記憶した名刺情報データベース（DB）３３１が保存されている。
【００５７】
なおSPサーバ３は、名刺を作成する者のサーバであればよく、名刺作成業者のサーバの他、企業内の名刺プリント部門のサーバであってもよい。また、名刺情報特定手段３２３および／またはデータ形式変換手段３２４は、名刺情報管理システム１側に備えるようにしてもよい。
【００５８】
［１．DBCサービスの概要］
次に、本システム１を用いて行うDBC（Digital Business Card）サービスについて説明する。
DBCサービスとは、図３７に示すように、紙の名刺５に、それに対応した既存の名刺作成サービスプロバイダ（以下、SPと略記する）のデータベース上の名刺情報（名刺作成のための情報）に繋がるためのインデックスである情報コード６が記載されており、このサービスの提供を受けるユーザは、その情報コードを入力するだけで、その情報コードに対応する名刺情報を入手でき、また、個人のアドレス帳としてその名刺情報を管理でき、さらに、ユーザの名刺情報が変更になった場合は、更新対象者のアドレス帳を自動的に更新するというサービスである。
【００５９】
この情報コードは、図３に示すように、たとえば、２次元コード（ＱＲコード）で名刺上に記載されており、携帯電話（ユーザ端末）等のコードリーダ機能を有する手段でスキャンすることによって入力され、通信ネットワークを介して、DBCサービス業者のサーバである名刺情報管理システム１に送られる。
【００６０】
一方、コードリーダ機能付き携帯電話を所持していないユーザは、名刺情報管理システムに接続してから情報コードの下に記載された文字列を手入力することで同様のサービスが受けられる。
なお、通常の名刺情報が拡張され、名刺画像イメージ、メモ領域（名刺の渡し手、受け手双方のメモ）、その他その名刺の管理情報が付加されたものをDBCデータと呼ぶものとする。
【００６１】
DBCサービスでは、各ユーザ・アカウントごとに専用のユーザデータ保存領域（以下、DBCフレームともいう）を提供する。DBCフレームでは、各ユーザが名刺交換相手のDBCデータの保存と管理を行うアドレス帳データ保存エリア（以下、Address Bookともいう）、ユーザ本人がこれまでに作成した名刺のDBCデータの保存と管理を行うキャリアレコード保存エリア（以下、Career Recordともいう）、および、その他の管理データなどで構成される。
ユーザは、携帯電話やパソコンからインターネット経由で自分のDBCフレームに接続してサービスの提供を受ける。
【００６２】
名刺情報管理システム１は、DBC対応の名刺作成サービスプロバイダ（SP）のデータベース３３と連携することで、常に最新の名刺情報を取得する。これにより、各ユーザのアドレス帳データ保存エリア及びキャリアレコード保存エリア上では常に最新の情報を利用することができる。
【００６３】
名刺に記載される情報コードは、名刺IDを２次元のＱＲコードのようにコード化したものである。また、名刺IDは、図４に示すようにユーザ（名刺所有者）の識別情報（以下、メンバIDまたはM-IDという）、このユーザが加入しているサービスプロバイダの識別情報（以下、データベースIDまたはDB-IDという）、役割識別情報（以下、ロールIDまたはR-IDという）、および、名刺の版識別情報（以下、バージョン番号またはV-IDという）で構成されている。
【００６４】
［２．名刺IDの構成］
次に、図４を用いて、名刺ID（以下、DMRV-IDともいう）の構成について詳述する。名刺IDは、大きくユーザを識別するための情報と名刺を識別するための情報から成り立っている。
【００６５】
（２．１ ユーザの識別のための情報）
DBCサービスではSP側の名刺情報が格納されているデータベースとそのデータベースにおけるユーザアカウント（ここではメンバと表現）の管理という２階層の仕組みにより、各メンバの識別を実現する。DBCサービスからはSP側の名刺情報が格納されているデータベースに対してIDを発行し、各SPがそのサービスの利用者（ユーザ）に対してメンバIDを発行する。
【００６６】
このようにデータベースIDとメンバIDを組み合わせることでDBCサービスのユーザが一意に識別できるようになる。
ここで、D-ID（データベースID）は、名刺情報が格納されているデータベースの識別番号である。データベースは通常各SPが管理する。一般的には一つのSPは一つのデータベースを保有している。企業ユーザの場合にはその企業がDBを保有している。なお、一つのSPが複数のデータベースを所有する場合は、このD−IDによって識別可能にする。
【００６７】
M-IDは、DB内の各メンバの識別番号である。また、DM-ID（ユーザ識別ID）は、DBCサービスでのサービス利用アカウントの付与単位である。DM-ID一つにつき、DBCフレーム一つが割り当てられる。一人のユーザがDBCサービスに複数のアカウントを持ち、複数のDM-IDを所有することもある。DM-IDは以下により表現される。
<DM-ID> ＝ <D-ID>＋<M-ID>
【００６８】
上式は、D-IDとM-IDを合わせたものをDM-IDと定義することを意味している。ただし、単にIDを並べるのみでなく、所定のアルゴリズムによって、D-IDとM-IDからDM-IDを生成でき、逆にDM-IDからD-IDとM-IDを抽出可能な場合も含む。
【００６９】
（２．２ 名刺識別のための情報）
DBCサービスでは、１ユーザアカウントで同時に複数（たとえば１０個）のロール（役割または種別）を持ち、ロールごとに名刺を持つことができるようにしたものである。（例えば、営業としての名刺と技術者としての名刺、キャンペーン用の名刺など）
各ロールは各ユーザの識別番号（DM-ID）とその中での役割番号（以下、枝番またはR-IDという）によって識別される。
R-IDはユーザの要求により、各SP側で付番される。
ここで、DMR-IDは以下により表現される。
<DMR-ID> ＝ <DM-ID> ＋ <R-ID>
【００７０】
また、V-ID（版数またはバージョンIDという）は、名刺（DMR-ID）ごとに情報更新が発生することに対応して、版数番号単位で名刺の識別を可能にしたものである。
版数番号はユーザの要求（名刺情報の変更）により、SP側で付番される。
以上より、個々の名刺の識別番号（DMRV-IDと略記）は以下のように表現される。
<DMRV-ID> ＝ <DMR-ID> ＋ <V-ID>
M-ID、R-ID、または、V-IDを管理していないSPがDBCサービスに参加する場合には、これらの管理が可能なようにシステムのカスタマイズを行うものとする。
【００７１】
［３．ユーザデータ保存領域の構成］
次に、名刺情報管理システム１で保存するユーザデータ保存領域（DBCフレーム）の構成を詳述する。
DBCフレームとは、DBCサービス側に確保される各ユーザ用のデータ領域である。一つのDM-IDに一つのDBCフレームが確保される。
【００７２】
図５にDBCフレームの概念図を示す。この図において、DBCフレームには、名刺交換相手の情報を格納するためのアドレス帳データ保存エリアとDBCフレームオーナーの名刺作成履歴の情報を格納するためのキャリアレコード保存エリアという２種類の保存エリア（いわゆるキャビネット）があり、その中にユーザが利用するデータ本体（DBCデータ）がDM-IDごとに格納されるようになっている。    
【００７３】
次に、図６にDBCフレーム内で管理されるデータ領域の項目を示す。
ここで、DBCフレーム番号は、DBCサービス側でDBCフレームを管理するために利用する番号である。
DM-IDは、当該DBCフレームの所有者（オーナー）のDM-IDの登録領域である。
デフォルト値（Default Value）は、後述する名刺情報転送手段１２８によって、当該DBCフレーム内のアドレス帳データ保存エリアおよびキャリアレコード保存エリアに格納された各エントリデータ（DBCデータ）を、他のDM-IDのDBCフレームに転送しようとする場合などの初期値となる。
【００７４】
デフォルト値欄のアドレス帳転送情報（Address Book Forward Info）とは、アドレス帳データ保存エリア内のエントリを他のDM-IDのDBCフレームに転送しようとする際の初期値を設定する。転送先は、当該DBCフレームのオーナーが設定でき、複数の転送先を設定することも可能である。
【００７５】
具体的なデータ項目として、AB-F CNTは、デフォルト転送回数であり、アドレス帳データ保存エリア内のエントリが無限に転送され続け、システムに負荷を与えることや、不注意な設定により意図せぬ転送先に転送が行われてしまうことを防止するため、転送回数の規定値を設定するものである。初期値は1である。
【００７６】
AB-F To LSTは、デフォルトの転送先であり、オーナーの転送設定により、当領域に記録される転送先DBCフレームのDM-IDのリストである。
AB-F From LSTは、いずれかのDM-IDのDBCフレームから当該DBCフレームへ転送設定がなされた際に記録されるDM-IDのリストである。当DBCフレームのDM-IDが変更または削除されたときに、その情報を転送元のDBCフレームに伝えるために記録するものである。
デフォルト値欄のキャリアレコード転送情報（Career Record Forward Info）とは、当該DBCフレームのキャリアレコード保存エリアに格納されたDBCデータ、即ち、オーナーの名刺作成履歴を、他のDM-IDに転送する場合に利用するものである。
【００７７】
具体的なデータ項目として、CR-F CNTは、デフォルト転送回数であり、転送回数の規定値を設定するものである。初期値は1である。
CR-F To LSTは、デフォルトの転送先であり、オーナーの転送設定により、当領域に記録される転送先DBCフレームのDM-IDのリストである。
CR-F From LSTは、いずれかのDM-IDのDBCフレームから当該DBCフレームへ転送設定がなされた際に記録されるDM-IDのリストである。
【００７８】
アドレス帳データ保存エリアは、名刺交換相手などの情報を保存する領域である。各エントリとして登録されるのは、DBCコード（情報コード）をスキャンすることによって取得された相手の名刺IDの入力により取得された相手のDBCデータ、および、キーボード等から手動により登録された連絡先情報であり、DBCデータの集合である。
キャリアレコード保存エリアは、オーナーに関するDBCデータを保存する領域である。当該DM-ID配下の全てのDMR-IDの、全ての版数（DMRV-ID）のDBCデータを保管する、DBCデータの集合である。
【００７９】
上記各データ領域のアクセス権限は、DBCフレーム番号（管理番号）については、DBCフレームが初めて生成される際に記録され、当該DBCフレームが破棄されるまで変更されることはない。
DM-IDについては、ユーザからのサービス申込により、DBCフレームが生成される際に基本情報登録手段１２２により登録され、オーナーからのDM-ID変更申請により変更される。
【００８０】
アドレス帳データ保存エリアについては、当該DBCフレームのオーナーが、他のユーザのDBCカードに印刷されたDBCコードをスキャンしたり、名刺IDの手動入力検索を行うなどしたときに登録される。また、手動登録で登録することも可能である。各エントリはオーナーが参照やメモの入力、および、変更、削除をすることができる。
キャリアレコード保存エリアについては、当該DBCフレームのオーナーが利用している名刺作成業者（名刺作成サービスプロバイダ）側のマスターデータが更新されると、DBCサービス側に更新が通知され、そのデータが本領域に格納される。また、オーナーから参照・メモの入力と変更・削除が可能である。
【００８１】
なお、図７に示すように、アドレス帳データ保存エリアは、名刺交換をした相手の名刺情報（AB-YC：Your Card）がその名刺と交換のために相手に差し出した自分（オーナー）の名刺ID（MCIE : My Cards In Exchange）が互いに関連付けられて保存されている。また、キャリアレコード保存エリアには、自分の名刺情報（CR-MC : My Card）とその名刺との交換のために自分に差し出された相手の名刺ID（YCIE : Your Cards In Exchange）が互いに関連付けられて保存されている。
【００８２】
（３．１ アドレス帳データ保存エリアの各データエントリの構造）
次に、図８を用いて、アドレス帳データ保存エリアの各データ項目について説明する。
【００８３】
この図において、アドレス帳データ保存エリアは、DM-IDごとに生成されるフォルダ管理データ、DMR-IDごとに生成されるファイル管理データ、DMRV-IDごとに生成されるカード管理データ、および、名刺情報等のカードデータから構成されている。カードデータとしては、名刺交換をした相手の名刺情報が保存されている。以下、各項目名について説明する。
【００８４】
<フォルダ管理データ>
フォルダ番号は、DM-IDごとに付番される。新規のDM-IDのDMRV-IDのDBCデータを受信する都度、フォルダエントリ追加が行われる。
DM-IDは、当該フォルダエントリに格納されているDBCデータのDM-IDである。
フォルダエントリ生成日時は、当該フォルダエントリを生成した日時である。
DM-IDステータスは、当該フォルダエントリに格納されているDBCデータのDM-IDの有効／無効を記録する。
【００８５】
<ファイル管理データ>
ファイル管理番号は、当該DM-ID配下の各DMR-IDごとに付番する。新規のDMR-IDのDMRV-IDのDBCデータを受信する都度、ファイルエントリの追加が行われる。
DMR-IDは、当該ファイルエントリに格納されているDBCデータのDMR-IDである。
ファイルエントリ生成日時は、当該ファイルエントリを生成した日時である。
有効期限は、当該ファイルエントリに格納されているDBCデータのDMR-IDの、有効期限である。有効期限は、そのDM-IDの本人ユーザが各ロール（DMR-ID）に対して設定する。
引継DMR-IDは、当該ファイルエントリに格納されているDBCデータのDMR-IDが無効となった場合にその情報を引き継ぐDMR-IDである。引継DMR-IDは、そのDM-IDの本人ユーザが各ロール（DMR-ID）に対して有効期限と共に設定する。
【００８６】
AB-F Fromは、当該ファイルエントリが別のDBCフレームから転送されてきたものである場合に、転送元DBCフレームのDM-IDを記録する。同一のDMRV-IDのファイルエントリが複数のDBCフレームから転送されてきている場合には、一つのファイルエントリとなるが、本領域に複数の転送元DM-IDが記録される。
AB-F Toは、当該ファイルエントリを別のDBCフレームへ転送する場合に、転送先DBCフレームのDM-IDを記録する。初期値は当該DBCフレームのデフォルト転送先（すなわちDefault Value の AB-F To LSTの値）である。
AB-F Countは、当該エントリのDBCデータを取得した側で、他のDBCフレームへ転送する回数を制限できる。本領域への回数設定は、AB-F From領域がNULLの時のみ設定できる。転送されると、実行される度にデクリメントされる。本領域の値が0の場合には、それ以上転送しない。初期値は当該DBCフレームのデフォルト転送回数（すなわち、Default Value の AB-F CNTの値）である。
【００８７】
プライオリティは、同一DM-ID内で複数のDMR-IDを持つ場合にそのDM-IDの本人ユーザ側で設定する優先順位である。
表示順は、DBCフレームオーナー（Address Bookオーナー）側で、同一のDM-IDの相手から複数のDMR-IDのDBCデータを受取った場合にオーナー側（受取った側）で設定できる表示の優先順位である。初期値は前述のプライオリティと同一である。
DMR交換ステータスは、当該DMR-IDのDBCデータとの間で交換が成立している状態、すなわち、DMRV-IDレベル（カードレベル）で交換が成立している場合に、ロールレベルでも交換が成立しているとみなす。
【００８８】
<カード管理データ>
カード管理番号は、当該DMR-ID配下のDMRV-IDごとに付番する。新規のDMRV-IDのDBCデータを受信する都度、カードの追加が行われる。
DMRV-IDは、当該カードのDBCデータのDMRV-IDである。
カード受信日時は、当該カードのDBCデータを受信した日時である。
受領ステータスは、当該カードのDBCデータを、オーナーが受領した（受取を承認した）か否かの識別子である。
受領日時は、当該カードのDBCデータを、オーナーが受領した日時である。
【００８９】
MCIE DMRV-ID（MCIE : My Cards In Exchange）は、交換相手側（＝当該カードのDBCデータの渡し元側）のDBCフレームに対し、交換の為に差し出した自分の名刺データのDMRV-IDである。
受領通知受信ステータスは、交換相手側からの受領通知を受け取ると「Ｙ」にセットされる。
受領通知受信日時は、交換相手側（＝当該カードのDBCデータの渡し元側）で上記のMCIEが受領されて、送られてきた受領通知を当方側のDBCフレームで受け取った日時である。
交換ステータスは、受領ステータスが「Ｙ」で、かつ、受領通知受信ステータスが「Ｙ」であると、「Ｙ」にセットされ交換成立とみなされる。
【００９０】
<カードデータ本体（DBCデータ）>
名刺情報は、統一形式であるvCardの項目に従って記録する。SP側のDBがvCard方式でない場合には、SPのサービス参加時に設置するデータ形式変換手段３２４（DBC-SP Translator）で、データ項目変換TBLをカスタマイズして作成し、対応する。
【００９１】
名刺画像イメージは、名刺情報の他に、名刺印刷時にデザインされた名刺画像ファイルを保持できるようにしたものである。
【００９２】
本人メッセージ番号は、名刺交換相手側で入力されたメッセージなどを格納する際に付番する、管理番号である。同一DMRV-IDの名刺情報で複数回メッセージを受けた場合には、その履歴をすべて登録する為、複数の管理番号とメッセージが保持されることとなる。
メッセージ受信日時は、当該メッセージを受信した日時である。
メッセージ内容は、名刺交換相手側のキャリアレコード保存エリアの当該名刺情報に対して入力されたメッセージ本体が格納される。
【００９３】
オーナーメモ番号は、DBCフレームのオーナー側で、面会履歴、その他の情報をメモとして記録する際に付番する管理番号である。同一DMRV-IDの名刺で複数回のメモの記録が可能である。
オーナーメモ記録日時は、当該メモを記録した日時である。
オーナーメモ内容は、DBCフレームオーナーが記録したメモの内容である。
【００９４】
（３．２ キャリアレコード保存エリアの各データエントリの構造）
次に、図９を用いて、キャリアレコード保存エリアの各データ項目について説明をする。キャリアレコード保存エリアもアドレス帳データ保存エリアと同様にDM-IDごとに生成されるフォルダ管理データ、DMR-IDごとに生成されるファイル管理データ、DMRV-IDごとに生成されるカード管理データ、および、名刺情報等のカードデータから構成されている。なお、カードデータとしては、自己の名刺情報が保存されている。以下、各項目名について説明する。
【００９５】
<フォルダ管理データ>
アドレス帳データ保存エリアの対応する各項目の意味と同様である。
【００９６】
<ファイル管理データ>
CR-F Fromは、当該ファイルエントリが別のDBCフレームから転送されてきたものである場合に、転送元DBCフレームのDM-IDを記録する。同一のDMRV-IDのファイルエントリが複数のDBCフレームから転送されてきている場合には、一つのファイルエントリとなるが、本領域に複数の転送元DM-IDが記録される。
CR-F Toは、当該ファイルエントリを別のDBCフレームへ転送する場合に、転送先DBCフレームのDM-IDを記録する。初期値は当該DBCフレームのデフォルト転送先（すなわち、Default Value の CR-F To LSTの値）である。
CR-F Countは、当該エントリのDBCデータを取得した側で、他のDBCフレームへ転送する回数を制限できる。本領域への回数設定は、CR-F From領域がNULLの時のみ設定できる。転送されると、実行される度にデクリメントされる。本領域の値が0の場合にはそれ以上転送しない。初期値は当該DBCフレームのデフォルト転送回数（すなわち、Default ValueのCR-F CNTの値）である。
ファイル管理データのその他の項目は、アドレス帳データ保存エリアの対応する項目の意味と同様である。
【００９７】
<カード管理データ>
YCIE DMRV-ID（YCIE : Your Cards In Exchange）は、交換相手側（＝当該カードのDBCデータの渡し先側）のDBCフレームから、交換のために差し出された相手の名刺データのDMRV-IDである。
カード管理データのその他の項目は、アドレス帳データ保存エリアの対応する項目の意味と同様である
【００９８】
<カードデータ本体（DBCデータ）>
ユーザ本人（オーナー）の名刺情報が保存される。各項目の意味は、アドレス帳データ保存エリアの対応する項目と同様である。
【００９９】
［４．DBCデータの受領ステータスと交換ステータスの管理］
以上のように、DBCフレームをアドレス帳データ保存エリアとキャリアレコード保存エリアに分けた構成において、名刺交換からアドレス帳の更新へ繋げるために必要となるステータスの概要について図７を用いて説明する。
アドレス帳データ保存エリアのAB-YC領域（交換した相手の名刺情報の保存領域）には、受領ステータスが設けられ、MCIE領域（名刺交換相手に差し出した自己の名刺のIDの保存領域）には、受領通知受信ステータスと、交換ステータスが設けられている。また、キャリアレコード保存エリアのCR-MC領域（自己の名刺情報の保存領域）と関連するYCIE領域（自己の名刺と交換に差し出された相手の名刺のIDの保存領域）には、交換ステータスが設けられている。
【０１００】
この構成において、AB-YCの受領ステータスが、「Ｎ」のときは「仮受」、「Ｙ」のときは「本受」の状態であることを意味する。ここで、仮受とは、オーナーが意識しているか否かに関わらず、名刺の交換相手のDBCデータがそのDBCフレームに置かれている状態を意味する。また、本受とは、仮受されているDBCデータがオーナーに格納の承認をされ正式に受領された状態をいう。
【０１０１】
また、MCIEの受領通知受信ステータスが「Ｎ」のときは、交換相手側に送付した自分の名刺データが仮受、「Ｙ」のときは、交換相手側に送付した自分の名刺データが本受状態にあることを意味する。
【０１０２】
MCIEの交換ステータスが、「Ｎ」のときは、上記受領ステータスまたは受領通知受信ステータスの両方または片方が「Ｎ」の状態であり、「Ｙ」のときは、受領ステータスと受領通知受信ステータスの両方が「Ｙ」の状態であることを意味する。
【０１０３】
また、キャリアレコード保存エリアのYCIEの交換ステータスが「Ｎ」のときは、アドレス帳データ保存エリアの交換ステータスが「Ｎ」であり、「Ｙ」のときは、アドレス帳データ保存エリアの交換ステータスが「Ｙ」であることを意味する。
一連のフラグ制御動作としては、受領ステータスが「Ｙ」（本受）で、受領通知受信ステータスが「Ｙ」になると、MCIEの交換ステータスが「Ｙ」になり、さらに、キャリアレコード保存エリアのYCIEの交換ステータスが「Ｙ」になる。
【０１０４】
［５．名刺作成業者（SP）と名刺情報管理システムとのデータの受け渡し］
次に、図１０を用いて名刺情報管理システム（DBCサービス）側の名刺情報を最新状態に保つための手順について説明する。
【０１０５】
（５．１名刺識別情報および名刺情報の変換処理）
この図において、まず、サービスプロバイダ側のデータベース（SP側DB）から、サービスプロバイダネットワーク内に設置された名刺情報特定手段３２３（DBCSP ID Manager）に、当該ユーザの名刺情報をSP側DBでのユーザ管理用ID番号と共に渡す。
【０１０６】
次に、DBCSP ID Managerでは、ユーザ管理用ID番号をもとにDMRV-IDを生成し、ヘッダ情報を変換する。続いて、データ形式変換手段３２４（DBCSP Translator）では、SPごとの独自フォーマットで記録されているユーザ名刺情報を、DBCサービス対応フォーマット（vCard方式）に変換し、DBCサービス側DB１３に送付する。
そして、DBCサービス側DBでは、受け取った名刺情報を当該ユーザの本人情報領域に格納する。
【０１０７】
このように、DBCSP ID Managerで、まず、ヘッダ情報、即ち、SP側の管理用識別番号から、名刺情報管理システム側の管理用識別番号であるDMRV-IDへ変換し、次に、DBCSP Translator名刺情報のフォーマットを名刺情報管理システムでの統一フォーマットであるvCard形式に変換する。
なおDBC-SP ID ManagerとDBCSP Translatorは、SP側、名刺情報管理システム側のいずれに備えることも可能である。
【０１０８】
DBCSP Translatorを名刺情報管理システム側に備える場合は、SPごとに名刺情報のフォーマットが異なる可能性があるため、予め、SPごとにSP側のフォーマットからDBCサービス対応の統一フォーマットへの変換アルゴリズム（たとえば、フォーマット変換のためのデータ項目対応テーブルとそのテーブルを参照して変換を行うロジック）を名刺情報管理システム１の記憶部１３に保存しておき、名刺IDのD-IDをもとにそのSPの変換アルゴリズムを抽出して、そのアルゴリズムに従ってフォーマットを変換するようにするとよい。
【０１０９】
（５．２名刺情報の受け渡し処理）
次に、SPサーバ３と名刺情報管理システム１との間の名刺情報の受け渡しのタイミングについて詳述する。
【０１１０】
名刺情報管理システム１は、ユーザデータテーブル（ユーザデータ保存領域）１３２に名刺情報を蓄積する場合は、名刺情報要求手段１２４によって、そのユーザに対応するDM-IDから名刺情報を保存しているデータベースすなわちSPサーバ３を特定し、そのSPサーバ３へユーザ識別情報と共に名刺情報の送信要求を送る。SPサーバ３は、この要求を受信すると、上記の処理によって生成されたDMRV-IDと名刺情報を名刺情報管理システム１へ送信する。
【０１１１】
名刺情報管理システム１の名刺情報取得手段１２５は、SPサーバ３から送られてくるDMRV-IDと名刺情報を受け取ると、該当するユーザのキャリアレコード保存エリアにDMRV-IDのカードエントリを作成して名刺情報を保存する。
【０１１２】
一方、SPサーバ３側で、名刺情報に変更があった場合は、変更に係る名刺情報とバージョン（V-ID）をインクリメントしたDMRV-IDとを名刺情報管理システム１へ送る。この情報は、名刺情報取得手段１２５で受信されて、上記と同様に該当するユーザのキャリアレコード保存エリアに保存される。R-IDが追加になったような場合も同様である。
【０１１３】
以上の説明では、名刺情報に変更があった場合、SPサーバから自発的に名刺情報を送ることとしたが、名刺情報管理システム１側から定期的にSPサーバの名刺情報を吸い上げるようにしてもよい。このようにすれば、SPサーバと名刺情報管理システムの間のデータの不一致を避けることができる。
【０１１４】
このとき、SPサーバは、名刺情報管理システム１からの問合せに応じて最新のDMRV-ID情報のみを送るようにし、名刺情報管理システム１は、送られてきたDMRV-ID情報と保存している最新のDMRV-ID情報とを比較して、不一致の場合は、そのDMRV-IDを指定して名刺情報を要求するようにしてもよい。このようにすれば、多くのSPサーバと通信を行う場合でも伝送負荷を軽減することができる。
【０１１５】
さらに、名刺情報に変更があった場合の他の受け渡し方法として、問合せの間に生じた変更件数を通知するようにしてもよい。各SPサーバでの変更件数を名刺情報管理システム１で集計して、たとえば変更の頻度が高いSPサーバには問合せ周期を短くするなど、変更件数に従って問い合わせ間隔を調整すれば、負荷の分散を図ることができる。
【０１１６】
［６．名刺情報交換処理］
次に、図１１〜図１５を用いて、名刺情報交換管理手段１２６の動作を説明する。
【０１１７】
（６．１ユーザＡからの名刺情報要求）
図１１は、ユーザＡが、名刺交換で入手したユーザＢの名刺に付されたDBCコード（情報コード）をスキャンして、ユーザＢの名刺情報を取得する際の一連の処理を表したフローチャートである。
【０１１８】
まず、ユーザＡは、自己の携帯電話（ユーザ端末）２でユーザＢの名刺に記載されているDBCコードをスキャンする（Ｓ１０１）。このときのユーザ端末の画面の遷移例を図２９（１）〜（４）に示す。図２９（４）において、交換する自己の名刺情報を指定して実行キーを選択して相手の名刺情報の要求を行う。
【０１１９】
次にユーザＡは、ユーザ端末２を通して名刺情報管理システム１との接続要求と名刺情報の取得要求をかける（Ｓ１０２）。
この接続要求によって、名刺情報管理システム１の端末通信手段は、端末識別IDと情報取得要求コマンドを切り分けて（Ｓ１０３）、事前に名刺情報管理システム１のユーザ情報DB１３１に登録されている携帯識別ID一覧（携帯識別IDとDM-ID、パスワードの対応テーブル等）を参照して、取得した携帯識別IDが存在するか否かを判定する（Ｓ１０４）。そして、取得した携帯識別IDがこの一覧の中に存在すれば、ログイン処理を実行する（Ｓ１０６）。一方、取得した携帯識別IDがこの一覧の中に存在しなければ、不特定ユーザを対象としたAnonymous処理を実行する（Ｓ１０５）。なお、ステップＳ１０３において、受信メッセージ中に情報取得要求コマンドが含まれていると、名刺情報交換管理手段１２６が起動され、以降の処理が実行される。
【０１２０】
まず、DM-IDとDBCフレームの対応テーブルを参照して、DM-IDをもとにDBCフレーム番号を取得して（Ｓ１０７）、要求元処理部であるユーザＡのDBCフレームに接続する（Ｓ１０８）。
そして、ユーザＡのアドレス帳データ保存エリアにユーザＢのDM-IDのフォルダエントリ（データ格納領域）が存在するか否かを判定して（Ｓ１０９）、フォルダエントリが無ければ、ユーザＢのDM-IDのフォルダエントリを作成する（Ｓ１１０）。なお、図中、ユーザＢのDM-IDをDM-ID（b）と表示している。以下、同様にIDの主体を括弧書きで表示する。
【０１２１】
ステップＳ１０９で「ＹＥＳ」の場合は、次にアドレス帳データ保存エリアにユーザＢのDMR-IDのファイルエントリがあるか否かを判定して（Ｓ１１１）、ファイルエントリが無ければ、ユーザＢのDMR-IDのファイルエントリを作成する（Ｓ１１２）。そして、ステップＳ１１１で「ＹＥＳ」の場合は、アドレス帳データ保存エリアにユーザＢのDMRV-IDのカードエントリがあるか否かを判定して（Ｓ１１３）、カードエントリが無ければ、ユーザＢのDMRV-IDのカードエントリを作成する（Ｓ１１４）。そして、作成したカードエントリのMCIEとしてユーザＡのDMRV-IDを追加する（Ｓ１１５）。また、キャリアレコード保存エリアのユーザＡのDMRV-IDのYCIEとして、ユーザＢのDMRV-IDを追加する（Ｓ１１６）。その後、ユーザＢへ名刺情報の要求メッセージを送る（Ｓ１１７）。この要求メッセージには、ユーザＡのDMRV-IDと当該IDの名刺情報が含まれている。ステップＳ１１３で「ＹＥＳ」の場合は、図１４のステップＳ３１５以降を実行する。
【０１２２】
一方、図１２に示す要求先処理部であるユーザＢのDBCフレーム側の処理としては、ユーザＡからユーザＢの名刺情報の要求メッセージを受け取ると、まず、メッセージ情報の切り分けを行う（Ｓ２０１）。そして、Ｓ１０９〜ステップＳ１１４と同様に、ユーザＢのアドレス帳データ保存エリアにユーザＡのフォルダ、ファイル、カードの各エントリ（データ格納領域）があるか否かを判定して、エントリが無ければ、それらのエントリを作成する（Ｓ２０２〜Ｓ２０７）。
次に、ユーザＡのDMRV-IDのカードエントリの名刺情報格納領域に受信したユーザＡの名刺情報を格納して（Ｓ２０８）、受信時刻を記録する（Ｓ２０９）。そして、ユーザＡのDMRV-IDのカードエントリのMCIEにユーザＢのDMRV-IDを追加し（Ｓ２１０）、キャリアレコード保存エリア側のユーザＢのDMRV-IDのYCIEにユーザＡのDMRV-IDを追加する（Ｓ２１１）。その後、ユーザＢのDMRV-IDと共に当該IDの名刺情報をユーザＡへ送信する（Ｓ２１２）。
【０１２３】
一方、図１３に示すユーザＡのDBCフレーム側の処理として、ユーザＢのDMRV-IDのカードエントリの名刺情報格納領域に受信したユーザＢの名刺情報を格納して（Ｓ２１３）、カード受信日時に現在時刻を記録する（Ｓ２１４）。
【０１２４】
そして、ユーザＢのDMRV-IDのカードエントリの受領ステータスを「Ｙ」に設定して（Ｓ２１５）、カードエントリの受領日時に現在時刻を記録する（Ｓ２１６）。
次に、ユーザＢへ受領通知を送付すると共に（Ｓ２１７）、ユーザＡの端末へ名刺情報を送信する（Ｓ２１８）。
ユーザＡの端末では、名刺情報を受信して（Ｓ２１９）、端末のディスプレイに表示する（Ｓ２２０）。図２９（５）は、取得した名刺情報の表示例である。この後、図２９（６）に示すようにアドレス帳データ保存エリアへの登録を行うことができる。
【０１２５】
他方、ユーザＢのDBCフレーム側の処理として、ユーザＡから受領通知を受信すると（Ｓ２２１）、ユーザＡのDMRV-IDのカードエントリのMCIEにあるユーザＢのDMRV-IDの受領通知受信ステータスを「Ｙ」に設定し（Ｓ２２２）、ユーザＡのDMRV-IDのカードエントリのMCIEにあるユーザＢのDMRV-IDの受領通知受信日時に現在時刻を記録する（Ｓ２２３）。
以上のように、名刺情報の受け渡しや受領通知のやり取りが行われる。
【０１２６】
（６．２ユーザＢからの名刺情報要求）
次に、図１４および図１５を用いて、ユーザＡからユーザＢの名刺情報要求後に、ユーザＢがユーザＡの名刺上のDBCコードをスキャンして、名刺情報要求を行った場合の処理について説明する。
【０１２７】
まず、図１４において、ユーザＢの端末でユーザＡのDBCコードが読み取られ（Ｓ３０１）、端末接続要求と情報取得要求が送られてくる（Ｓ３０２）。
ユーザＢのDBCフレーム側処理では、この要求情報を受信すると、まずメッセージを切り分け。（Ｓ３０３）、端末識別IDによる認証を行う（Ｓ３０４）。
以降、ステップＳ３０５からステップＳ３１４までの処理は、図１１のステップＳ１０５からステップＳ１１４までの処理と同様なので説明を省略する。
【０１２８】
ステップＳ３１３で「ＹＥＳ」の場合は、ユーザＡのDMRV-IDのカードエントリの受領ステータスを「Ｙ」に設定して（Ｓ３１５）、受領日時に現在時刻を記録する（Ｓ３１６）。
【０１２９】
次に、ユーザＡのDMRV-IDカードエントリのMCIEにあるユーザＢのDMRV-IDの交換ステータスを「Ｙ」に設定して（Ｓ３１７）、キャリアレコード保存エリア側のユーザＢのDMRV-IDのYCIEにあるユーザＡのDMRV-IDの交換ステータスを「Ｙ」に設定する（Ｓ３１８）。
そして、ユーザＡへ受領通知を送ると共に（Ｓ３１９）、ユーザＢの端末へユーザＡの名刺情報を送信する（Ｓ３２０）。この名刺情報は、ユーザＢの端末で受信され（Ｓ３２１）、ディスプレイに表示される（Ｓ３２２）。
【０１３０】
一方、図１５に示すユーザＡのDBCフレーム側の処理では、ユーザＢからの受領通知を受信すると（Ｓ３２３）、ユーザＢのDMRV-IDのカードエントリのMCIEにあるユーザＡのDMRV-IDの受領通知受信ステータスを「Ｙ」に設定し（Ｓ３２４）、受領通知受信日時に現在時刻を記録する（Ｓ３２５）。そしてユーザＢのDMRV-IDのカードエントリのMCIEにあるユーザＡのDMRV-IDの交換ステータスを「Ｙ」に設定する（Ｓ３２６）。また、キャリアレコード保存エリア側のユーザＡのDMRV-IDのYCIEにあるユーザＢのDMRV-IDの交換ステータスを「Ｙ」に設定する（Ｓ３２７）。
【０１３１】
以上のように名刺交換処理が行われ、交換ステータスの管理がなされる。なお、交換ステータスが「Ｙ」になると、アドレス帳保守手段１２７によって、一方の名刺情報の更新が相手方のアドレス帳に反映されるようになる。
【０１３２】
また、交換ステータスは、オーナーが任意にリセットできる。このリセットにより、相手方の交換ステータスもリセットされ、以降、名刺情報の更新に伴う相手方アドレス帳の更新はなされなくなる。
【０１３３】
なお、ステップＳ１０１において、名刺情報要求時に名刺に記載されている名刺IDを手入力するときの画面例を図３０（１）〜（３）に示す。これにより、２次元コードリーダ機能を持たないユーザ端末でも本サービスの提供を受けることが可能となる。
【０１３４】
また、アドレス帳データ保存エリアには、ユーザ端末から手入力によって、名刺情報を登録できるようにしておくとよい。このときの画面遷移例を図３１（１）〜（７）に示す。これにより、本サービスに加入していないユーザの名刺情報も含めて登録できるためアドレス帳として広く活用可能となる。
【０１３５】
なお、ステップＳ３０１〜Ｓ３０２では、相手側も名刺をスキャンすることによって、名刺情報の取得要求をすることとしたが、既に名刺情報の要求を受けた相手側に対しては、ログイン時に名刺情報の要求を受けた旨のメッセージを出力するようにしてもよい。本サービスでは、名刺情報の要求を行うときには、自己の名刺情報を差し出すことにしているため、相手側ユーザ端末には、新しいDBCデータが届いている旨のメッセージを表示する。このときのユーザ端末の画面表示例を図３４（１）〜（３）に示す。ユーザは、このメッセージを確認して、承認キーを選択することにより、直ちに交換成立状態にすることも可能である（図３４（４）（５）の画面表示例参照）。
【０１３６】
［７．名刺情報更新処理］
次に、アドレス帳保守手段１２７の動作を説明する。図１６〜図１９は、ユーザＡの名刺情報が更新されたときに、交換成立状態にあるユーザＢのアドレス帳が更新される際の一連の処理を表したフローチャートである。
【０１３７】
まず、ユーザＡの名刺作成業者（SP）側の処理として、SPシステムは、名刺情報の更新を受け付けると（Ｓ４０１）、当該DMR-IDのＶ−IDを加算する（Ｓ４０２）。即ち、それまでのDMRV-IDのバージョン識別番号であるＶ−IDをインクリメントする。そして、更新された名刺情報（以下、更新名刺情報）とDMRV-IDとを対応付けて保存する（Ｓ４０３）。その後、名刺情報管理システムへ接続要求と更新名刺情報およびDMRV-IDを送信する‘（Ｓ４０４）。この送信メッセージには、SP−ID、ログインパスワード、更新名刺情報通知コマンド、各種パラメータ（更新に係るDMRV-ID、名刺情報）などが含まれている。
【０１３８】
次に、名刺情報管理システムのユーザＡのDBCフレーム側の処理として、受信メッセージを切り分けて（Ｓ４０５）、SP−IDによる認証を行う（Ｓ４０６）。この認証は、SP−IDとパスワードからなるSPログインデータとＤ−IDの対応テーブルを参照して行われる。そして、ステップＳ４０６で「ＮＯ」の場合は、終了処理を実行する（Ｓ４０７）。一方、ステップＳ４０６で「ＹＥＳ」の場合は、ログイン処理を実行する（Ｓ４０８）。なお、ステップＳ４０５において、切り分けた受信メッセージに更新名刺情報通知コマンドが含まれていると、アドレス帳保守手段１２７が起動され、以降の処理が実行される。
【０１３９】
まず、DM-IDとDBCフレームの対応テーブルを参照して、DM-IDからDBCフレーム番号を取得し（Ｓ４０９）、ユーザＡのDBCフレームに接続する（Ｓ４１０）。
【０１４０】
そして、キャリアレコード保存エリア内のユーザＡのDM-IDのフォルダエントリの有無（Ｓ４１１）、DMR-IDのファイルエントリの有無（Ｓ４１３）、DMRV-IDのカードエントリの有無（Ｓ４１５）をそれぞれ判定して、対応するエントリが無ければ作成する（Ｓ４１２、Ｓ４１４、Ｓ４１７）。ステップＳ４１５で「ＹＥＳ」の場合は、例外処理を実行する（Ｓ４１６）。
【０１４１】
ステップＳ４１７の後、ユーザＡのDMRV-IDのカードエントリの名刺情報部分に受信した更新名刺情報を格納して（Ｓ４１８）、受信日時に現在時刻を記憶する（Ｓ４１９）。
そして、一つ前のバージョンのカードエントリのYCIEにあるDMRV-IDで交換ステータスが「Ｙ」となっているものを、最新のDMRV-IDのYCIEに複写して（Ｓ４２０）、その複写したDMRV-IDの交換ステータスを「Ｙ」に設定する（Ｓ４２１）。
【０１４２】
次に、キャリアレコード保存エリアのYCIEに格納されている各DMRV-IDに対応するアドレス帳データ保存エリアのカードエントリのMCIEにユーザＡの最新のDMRV-IDを追加する（Ｓ４２２）。そして、キャリアレコード保存エリアのYCIEに格納されている全DMRV-IDの各ユーザに名刺情報更新メッセージを送付する（Ｓ４２３）。
この名刺情報更新メッセージには、更新に係るユーザＡのDMRV-IDとその名刺情報が含まれている。
【０１４３】
ユーザＢのDBCフレーム側の処理としては、ユーザＡからの名刺情報更新メッセージを受け取ると、そのメッセージを切り分ける（Ｓ５０１）。
そして、アドレス帳データ保存エリア内のユーザＡのDM-IDのフォルダエントリの有無（Ｓ５０２）、DMR-IDのファイルエントリの有無（Ｓ５０４）、DMRV-IDのカードエントリの有無（Ｓ５０６）をそれぞれ判定して、対応するエントリが無ければ作成する（Ｓ５０３、Ｓ５０５、Ｓ５０８）。ステップＳ５０６で「ＹＥＳ」の場合は、例外処理を実行する（Ｓ５０７）。
【０１４４】
ステップＳ５０８の後、ユーザＡのカードエントリの名刺情報部分に受信した名刺情報を格納して（Ｓ５０９）、カード受信日時に現在時刻を記録する（Ｓ５１０）。
そして、一つ前のバージョンのカードエントリのMCIEにあるDMRV-IDで交換ステータスが「Ｙ」となっているものを、最新のDMRV-IDのMCIEに複写して（Ｓ５１１）、その複写したDMRV-IDの受領通知受信ステータスを「Ｙ」に設定し（Ｓ５１２）、受領通知受信日時に現在時刻を記録する（Ｓ５１３）。
【０１４５】
次に、キャリアレコード保存エリアのユーザＢのDMRV-IDのYCIEにユーザＡのDMRV-IDを追加して（Ｓ５１４）、そのDMRV-IDのカードエントリの受領ステータスを「Ｙ」に設定して（Ｓ５１５）、カードエントリの受領日時に現在時刻を記録する（Ｓ５１６））。
そして、ユーザＡのDMRV-IDのカードエントリのMCIEにあるDMRV-IDの交換ステータスを「Ｙ」に設定して（Ｓ５１７）、ユーザＡに受領通知を送付する（Ｓ５１８）。
【０１４６】
一方、ユーザＡのDBCフレーム側の処理としては、ユーザＢからの受領通知を受信すると（Ｓ５１９）、ユーザＢのDMRV-IDのカードエントリのMCIEにあるユーザＡのDMRV-IDの受領通知受信ステータスを「Ｙ」に設定して（Ｓ５２０）、受領通知受信日時に現在時刻を記録し（Ｓ５２１）、交換ステータスを「Ｙ」に設定する（Ｓ５２２）。
【０１４７】
以上のように、名刺情報更新時に相手方の名刺情報の更新および交換ステータスの管理が行われる。なお、ユーザＢに相当する名刺交換相手が複数存在する場合は、交換相手ごとにステップＳ４２３以降の処理が行われる。
【０１４８】
［８．アドレス帳データ保存エリアの転送処理］
個人の社会活動の多様化に伴い、一人のユーザが複数のDM-IDとDBCフレームを所有する場合や、企業ユーザがプロジェクト単位、部門単位、会社全体などでメンバのアドレス帳を共有利用したい場合などがある。このような場合に対処するため、名刺情報管理システム１の名刺情報転送手段１２８によって、アドレス帳データ保存エリアやキャリアレコード保存エリアのデータを一元管理できるようにする。
【０１４９】
以下、アドレス帳を例にとって、その転送機能の概要を説明する。
アドレス帳の転送は、アドレス帳データ保存エリアの中のDMR-ID単位で、転送元のDBCフレームのアドレス帳データ保存エリアから、転送先のDBCフレームのアドレス帳データ保存エリアにフォルダ、ファイル、カードの各エントリデータの複写を行う。
【０１５０】
このとき、転送が無限に繰り返されることによるリスクやシステム負荷への対応のため、転送元側で転送回数を設定する。
【０１５１】
なお、他のアドレス帳データ保存エリアから転送設定されているDBCフレームが、DM-IDを変更した場合に、転送元のDBCフレームに転送先のDM-IDに変更があったことを通知できるように、転送元のDM-IDのリストであるAB-F From Listを保持するようにする。
【０１５２】
（転送元による設定と転送先の承認）
転送元では、DBCフレームに対し一括でデフォルト転送先を指定する。転送元からの指定後、「転送先のDM-IDとパスワードを入力する」 または 「転送先のユーザの承認を得る（＝転送先ユーザの次回ログイン時にアラート表示などで通知し、OKを得ることで設定する）」ことで設定完了する。
【０１５３】
指定されたDM-IDは、転送元のDBCフレームのDefault Value の Address Book Forward Info の、AB-F To LST と、転送先のDBCフレームの Default Value の Address Book Forward Info の、AB-F From LST に登録される。
【０１５４】
（転送先による設定と転送元の承認）
特定のDM-IDに対し、当該 Address Bookデータの転送を要求するものである。
転送先から転送元への指定後、「転送元のDM-IDとパスワードを入力する」または「転送元のユーザの承認を得る（＝転送元ユーザの次回ログイン時にアラート表示などで通知し、OKを得て設定する）」ことで設定完了する。
【０１５５】
指定されたDM-IDは、転送先のDBCフレームのDefault Value の Address Book Forward Info のAB-F Forward From LSTと、転送元のDBCフレームのDefault Value の Address Book Forward Info のAB-F Forward To LSTに記録される。
【０１５６】
（例外設定）
Address Book 内の各DMR-ID単位で、デフォルト設定で設定された転送先への転送設定の変更を行うことができる。
具体的には、各ファイルエントリ内にある、AB-F To領域の書き換えを行うことで実現できる。例外として設定されると、指定されたDM-IDのDBCフレームへの転送対象から外される。また、個別のファイルエントリ内のAB-F To領域に指定することで、個別のファイルエントリごとに転送先を設定することも可能である。
【０１５７】
（起動タイミング）
本機能は、転送先の新規登録時、アドレス帳データ保存エリア内に新規のDMR-IDのデータを取得したとき、または、いずれかのDMR-IDのフォルダ内に新規のDMRV-IDデータが格納されたときに起動される。
【０１５８】
図２０にフォルダ、ファイル、カードの各エントリ更新時の転送動作の概念図を示す。
この図において、まず、（1）交換相手側の情報更新などが当人のDBCフレームに通知され、（2）当人DBCフレーム側のAddress Bookの情報が更新されると、（3）転送先のAddress Bookにそのエントリのデータを複写する。AB-F CNTの値はデクリメントして登録される。
【０１５９】
次に、図２１を用いて転送先Address Bookへの反映の手順を説明する。この図において、まず、（1）Address Book内の各エントリ情報が更新されると、（2）当該エントリのAB-Fフィールドに登録されている、転送先を参照して、（3）転送先のDBCフレームに更新データを追加する。（4）転送先Address Book側では、当該DMR-IDに対応するエントリに、受信した新規DMRV-IDの名刺データを格納する。
【０１６０】
次に、図２２〜図２７を参照して、名刺情報転送手段１２８の転送設定処理について説明する。
【０１６１】
（アドレス帳データ保存エリアの転送設定処理）
最初に、図２２、２３を用いて、ユーザＡからユーザＢにユーザＢの名刺情報の転送の承認依頼を行い、ユーザＢで転送受け入れの承認を行う際の処理を説明する。
【０１６２】
まず、ユーザＡの端末から名刺情報管理システムとの接続要求を行い（Ｓ６０１、Ｓ６０２）、ユーザＡのDBCフレーム側の処理としては、受信メッセージを切り分け（Ｓ６０３）、携帯識別IDとDM-ID、パスワードの対応テーブル、および、ユーザログインデータを参照して端末識別IDによる認証を行う（Ｓ６０４）。認証後は、ログイン処理（Ｓ６０６）を経て、DM-IDとDBCフレームの対応テーブルを参照して、DM-IDからフレーム番号を取得する（Ｓ６０７）。
【０１６３】
そして、ユーザＡのDBCフレームに接続して（Ｓ６０８）、転送先のDM-IDを指定して（Ｓ６０９）、転送の承認先であるユーザＢへ転送受け入れ承認依頼メッセージを送信する（Ｓ６１０）。この依頼メッセージは、ユーザＢのDBCフレーム側にて受信され記憶される（Ｓ６１１）。
【０１６４】
一方、ユーザＢのDBCフレーム側の処理としては、ユーザＢが端末から接続要求・情報取得要求を送信すると（Ｓ７０１）、その要求メッセージは、名刺情報管理システムに送られ、メッセージの切り分けが行われ（Ｓ７０２）、端末識別IDによる認証（Ｓ７０３）、ログイン処理が行われ（Ｓ７０５）、DM-IDからフレーム番号が取得され（Ｓ７０６）、ユーザＢのDBCフレームに接続される。（Ｓ７０７）。このとき、ステップＳ６１１で記憶されたユーザＡからの転送承認依頼メッセージが表示される（Ｓ７０８）。このときのユーザＢの端末の画面例を図３６（ａ）（ｂ）に示す。
【０１６５】
ユーザＢの端末から承認入力が行われると（Ｓ７０９）、ユーザＢのDBCフレーム側処理では、ユーザＢのDBCフレームのDefault ValueのAddress Book Forward InfoのAB-F From LSTにユーザＡのDM-IDを追加して（Ｓ７１０）、転送受け入れ承認メッセージを送信する（Ｓ７１１）。
【０１６６】
このメッセージは、ユーザＡのDBCフレーム処理ルーチンによって受信され（Ｓ７１２）、ユーザＡのDBCフレームのDefault ValueのAddress Book Forward InfoのAB-F To LSTにユーザＢのDM-IDを追加する（Ｓ７１３）。そして、現在アドレス帳データ保存エリアにある全ファイルエントリのAB-F Toに、ユーザＢのDM-IDを追加して（Ｓ７１４）、ユーザＢにアドレス帳データ保存エリアにあるフォルダ、ファイル、カードのエントリを送付する（Ｓ７１５）。そして、設定完了メッセージを送信して（Ｓ７１６）、ユーザＡの端末では設定完了のメッセージが表示される（Ｓ７１７）。
【０１６７】
一方、ユーザＢのDBCフレーム側処理では、後述の転送受信時の処理が実行される（Ｓ７１８）。
【０１６８】
（アドレス帳データ保存エリアの転送処理）
上記のように転送設定された後のアドレス帳データ保存エリアの転送処理について図２４を用いて説明する。
【０１６９】
まず、転送元であるユーザＡのDBCフレーム処理において、名刺情報の取得または情報更新処理が行われ、新しいカードエントリを取得すると（Ｓ８０１）、AB-F ToフィールドにDM-IDが存在する全DBCフレームに取得したカードエントリを送付する（Ｓ８０２）。この際、転送するカードエントリが新規ファイルエントリである場合はAB-F CNTの値をデクリメントしたうえで送付する。この名刺情報更新メッセージには、転送するカードエントリ本人であるユーザＢのDMRV-IDやそのカードエントリデータ、ファイルの送付の場合にはデクリメントされたAB-F CNTの値などが含まれている。
【０１７０】
一方、転送先であるユーザＢのDBCフレーム処理において、このメッセージを受信するとメッセージの切り分けを行い（Ｓ８０３）、アドレス帳データ保存エリアにユーザＢのDM-IDのフォルダエントリが存在するか否かを判定して（Ｓ８０４）、存在しない場合は、フォルダエントリを作成する（Ｓ８０５）。次に、ユーザＢのDMR-IDのファイルエントリが存在するか否かを判定して（Ｓ８０６）、存在しない場合は、ユーザＢのファイルエントリを作成して（Ｓ８０７）、AB-F From フィールドに転送元のDMRV-IDを記録する（Ｓ８０８）。
【０１７１】
また、アドレス帳データ保存エリア内にユーザＢのカードエントリが存在するか否かを判定し（Ｓ８０９）、存在しない場合は、そのカードエントリを作成する（Ｓ８１０）。そして、ユーザＢのカードエントリの名刺情報部分に受信したユーザＢのDMRV-IDの名刺情報を格納して（Ｓ８１１）、カード受信日時に現在時刻を記録する（Ｓ８１２）。なお、ステップＳ８０９において、「ＹＥＳ」の場合は、例外処理を実行する（Ｓ８１３）。
以上のように、転送処理が行われる。
【０１７２】
（キャリアレコード保存エリアの転送設定処理と転送処理）
キャリアレコード保存エリアの転送設定処理のフローチャートを図２５および図２６に、また、転送処理のフローチャートを図２７に示す。
【０１７３】
転送の対象がキャリアレコード保存エリアのデータになることを除いては、基本的には、図２２〜図２４の処理と同様であるため説明を省略する。
上記の転送処理の説明では、転送先へ承認依頼を送付するようにしたが、転送先で転送を受け入れたいDM-IDを入力して、転送元の承認を得るようにすることもできる。このときの転送先のユーザ端末の画面表示例を図３５（ａ）〜（ｃ）に示す。
【０１７４】
また、転送承認の際に、個々のエントリごとに転送対象から除外できるようにしてもよい。このときのユーザ端末の画面例を図３６（ｃ）〜（ｆ）に示す。
【０１７５】
［９．ローカルアドレス帳連携機能］
DBCデータとパーソナルコンピュータや携帯電話のローカルアドレス帳との連携機能を持たせるようにしてもよい。
この機能の実現のためには、まず、名刺情報管理ステム１にユーザ端末２の機種と当該端末のアドレス帳データ形式とを関連付けて保存しておく。
そして、ユーザ端末２からアドレス帳データの連携要求を入力する。このときのユーザ端末上での画面表示例を図３２（ａ）〜（ｄ）に示す。
【０１７６】
名刺情報管理システム１は、端末識別情報から、機種を判定して、その機種に対応するアドレス帳データ形式に変換して、出力手段１２９を通してユーザ端末２へ送信する。なお、端末識別情報は、機種を判定できれば十分で、たとえば、端末から送られてくる製造番号をもとに機種を判定するようにしてもよい。
このようにすれば、ユーザは、たとえば、携帯電話のアドレス帳など、そのデータ形式を認識する必要がなく、また、携帯電話の機種を都度入力する必要も無いので利便性が向上する。
【０１７７】
［１０．名刺作成機能］
図３３に端末に表示される名刺発注画面の例を示す。この図において、まず、名刺のパターンを選択して、次に入力データの確認、修正を行い、その後、発注情報を入力して、で発注依頼を送信する。
【０１７８】
このとき、図３３（２）の画面で、名刺情報の他に、名刺交換相手から名刺情報の要求があったときに、無条件で交換を成立させるか否か等の動作制御情報も表示するようにして、その情報によって、名刺のデザインを変更可能にするようにしてもよい。
名刺IDに動作制御情報も含め、それを名刺に記載するようにすれば、名刺の所有者は、名刺のデザインからどのような動作制御が行われるか把握できるため、活用の幅が広がる。
【０１７９】
なお、動作制御情報としては上記の他、名刺情報以外に個人情報も保存可能にしておき、その個人情報を相手方に提供するか否かを動作制御情報としてもよい。
【０１８０】
また、動作パターンテーブルを設けて上述の動作制御情報の項目を選択可能にしておいてもよい。たとえば、パターン１を選択したときは、名刺交換をした相手からDBCコードと共に名刺情報の取得要求があったときは、無条件で名刺交換を受け入れる。パターン２を選択したときは、図２８に示すようなアラート画面を表示して受け入れの確認をする、などである。なお、DBCコードをスキャンしていない場合の名刺画像イメージの提供の可否についても動作パターンとして設定可能にすると効果的である。
【０１８１】
名刺画像全体を印刷するのに代えて、情報コードのシールを印刷するようにしてもよい。基本的に名刺IDのみで情報コードの出力が可能なため、情報コードのシールを印刷して既存の名刺に貼付して使用することもできる。
【０１８２】
本実施の形態によれば、情報コードを記載された名刺を用いるため、名刺交換後にサーバ上で名刺情報を交換する際に簡単な手順・操作で行うことができ、アドレス帳の更新処理を円滑に行うことができる。また、名刺に記載されている個人情報（氏名、勤務先、住所など）自体をコード化するものではないため、情報コードのサイズは小さくて済み、名刺の限られた紙面が情報コードで占有されることを避けることができる。
【０１８３】
さらに、名刺IDに名刺作成業者の識別情報を含めるので、異なる複数の名刺作成業者で名刺の作成を行っている各ユーザの名刺情報を取得でき、アドレス帳の情報として一元管理できる。また、名刺IDは、コード化された状態で名刺に記載されているため、他人の名刺IDを入手するためには、基本的に名刺を取り交わすことが必要となるため、自己の名刺情報の不慮の流出を防ぐことができる。なお、名刺を交換した相手に対しては、名刺情報の提供に関して許諾を不要とすることも可能であり、ユーザの負担を軽減することができる。
【０１８４】
名刺情報管理システムのユーザデータ保存領域では、キャリアレコード保存エリアとアドレス帳データ保存エリアとに分けて名刺情報を管理するため、セキュリティを担保しつつ簡便にアドレス帳データの管理が可能となる。なお、アドレス帳データを名刺IDやユーザの端末識別情報によって暗号化して保存しておくようにすれば、データ保存中のセキュリティを高めることができる。また、端末とシステムの通信確立時に自動的に端末認証をしておき、認証ＯＫのときに、その端末識別情報に対応するアドレス帳データを復号化処理を開始するようにすれば、ユーザがユーザIDやパスワードを入力して名刺情報の送信要求処理を行っている間に復号化処理を実行できるため、システムの応答性能を向上させることができる。
【０１８５】
さらに、本実施の形態では、キャリアレコード保存エリアの構成を、ユーザごとに、名刺作成のためのデータベースとユーザ識別情報であるDM-ID単位でフォルダに区分し、そのフォルダの中にロール単位でファイルを作成して、そのファイルの中に、名刺のバージョンごとにカード（名刺情報）を入れるようにしたので、名刺の更新管理が容易となる。
【０１８６】
また、本実施の形態によれば、ネットワーク上での非同期の名刺交換を円滑に実行することができる。交換ステータスのフラグ処理によって、更新対象の相手を適切に管理でき、自己の名刺情報が更新されたときに、確実に相手側のアドレス帳の更新を行うことができる。さらに、アドレス帳データとキャリアレコードの保存エリアを分けることによって、高いセキュリティを持って、アドレス帳データ保存エリアに保存されているデータからなる個人アドレス帳を管理することができる。
【０１８７】
特にアドレス帳データ保存エリアは、ユーザ管理用のデータ、キャリアレコード保存エリアは、名刺情報を管理する者（会社等）の管理用のデータとしての性格を持たせることができるため、夫々のエリアに異なる管理権限を与えることによって管理権限の無いものによるデータの改竄を防止することができる。また、企業の承認プロセスを経た名刺情報のみをキャリアレコード保存エリアに保存するという管理も可能となる。
【０１８８】
さらに、管理権限に加え、アクセスレベルを設定可能にしてもよい。たとえば、レベル１は、書き込み、読み出しが可能、レベル２は、読み出しのみ可能などである。これにより、アドレス帳データ保存エリアは、管理者に読み出しのみ許可するなどの柔軟な運用が可能となる。たとえば、営業担当は、会った人の名刺をスキャンして、訪問実績（＝商談開始）として相手の名刺情報を記録しておき、管理者は、アドレス帳データ保存エリアにある名刺情報およびその名刺情報の受領日時を閲覧することによって営業担当の活動を管理することも可能である。
【０１８９】
また、本実施の形態によれば、名刺情報は自動的に更新されるため、交換成立状態にある顧客リストが常に最新に保たれるので、ＣＲＭ（顧客に関する情報連携基盤）としても活用できる。この他、人事異動などがあったときに新聞などを検索しなくても、情報が更新された人を速やかに特定して、お祝い状を送るなどの速やかな対応も可能となる。
【０１９０】
なお、名刺に記載する２次元のDBCコードに関する他の実施例として、名刺に付されたDBCコードとその下に記載されるDMRV-IDを単にコード化あるいは暗号化のしかたを変えるのみでなく、情報自体を変えるようにしてもよい。たとえば、DBCコードについては、DMRV-IDの情報に加え、ユーザが設定したキーワード等の情報を付加する。これによって、名刺からスキャンされたものか、あるいは、手入力によるものかの判別が可能となる。さらに、不正にDMRV-IDが取得されたような場合にも、２次元のDBCコードと動作を変えることによってセキュリティが保たれる。なお、スキャナ機能でDBCコードを読み込んだときに、スキャナで読込んだことを示す情報を同時に保存するようにしておき、名刺情報を要求するときに、その情報も一緒に送るようにすれば、スキャンによるものか手入力によるものかを容易に区別することができる。
【０１９１】
また、D−IDを名刺作成業者のデータベースではなく、その名刺情報を管理する管理者単位で設けるようにしてもよい。そして、管理者は、そのD−ID内のキャリアレコード保存エリアの名刺情報にアクセスすることができるようにする。たとえば、同じD−ID内のフォルダにある相手方DMRV-IDを入手可能にすれば、そのDMRV-IDをたよりに、管理者も相手方の名刺情報を取得することができ、これにより、企業の従業員が業務で知り合った相手方の情報をその従業員の上位管理者が知ることができる。
【０１９２】
これは、業務関連の名刺を渡した相手方がその名刺に付された名刺ID（DMRV-ID）を指定して名刺情報の取得要求をしてくるため、キャリアレコード保存エリアの情報のみを管理者に公開することによって、管理者は従業員の業務活動状況を知ることができ、一方、アドレス帳データ保存エリアには、また別のアクセス権限によって管理することによって、いわゆる個人の活動情報の秘密性を担保することができる。
【０１９３】
また、本実施の形態の応用例として、名刺交換履歴（または転送情報）を用いてユーザ間の繋がりを検索することも可能である。たとえば、個人情報として特定の技術を有する者、あるいは、有名人などとの繋がりを検索できる。分類情報を選択可能にしておき、名刺情報を保存するときに、その分類情報と関連付けて保存するようにすれば、どの分類の繋がりが自己の活動にとって有効かを知ることができ、特定の方向への人間関係の形成に役立たせることができる。
【０１９４】
なお、本実施の形態では、名刺にDBCコードを記載するとしたが、名刺以外のもの、たとえば一般的な文書、電話帳、広告などにDBCコードを記載するようにしてもよい。これにより、その読者は、簡単に名刺情報を取得できるので、ネットワーク上での人間関係の繋がりの促進を図ることができる。
また、キャリアレコード保存エリア内の自己の名刺情報の蓄積は、自己の経歴情報となるため、履歴書としても利用できる。
【０１９５】
さらに、繋がり機能を利用して、ビズコネクト（人を紹介しあう仕組み）に活用することも可能である。特に、本実施の形態によれば、最新の情報でご紹介でき、また、メッセージ発信の仕組みで関係をメンテナンスできる。また、繋がり（総理大臣、社長など）を辿って、その回数を見て楽しむことも可能である。この辿り方としては、転送機能から辿る方法や名刺交換実績・履歴から辿る方法などがある。これにより、人間関係の形成のモチベーションを高めることができる。
また、複数の言語での名刺情報をキャリアレコード保存エリアに登録しておくことで、名刺には掲載しきれない種類の言語の名刺情報を配布することができる。
【０１９６】
なお、本実施の形態は、他の用途、たとえば年賀状などの宛名情報として活用することもできる。このとき、宛名書きソフトと連携させ、年賀状に宛名の2次元コードを記載しておき、それを読み取って登録するようにすれば、情報更新が容易となる。
また、電子認証、暗号通信で公開鍵を配布する仕組みとして使うことができる（LDAPなどに比べて利用しやすい）。
【図面の簡単な説明】
【０１９７】
【図１】本実施の形態に係わる名刺情報管理システム、このシステムと通信ネットワークを介して繋がるユーザ端末、および、名刺作成業者のサーバの機能ブロック図である。
【図２】図１のSPサーバの機能ブロック図である。
【図３】本発明の実施の形態に係わるDBCサービスの説明図である。
【図４】本発明の実施の形態に係わる名刺IDの構成図である。
【図５】DBCフレームの概念図である。
【図６】図１のユーザデータ保存領域の構成の説明図である。
【図７】アドレス帳データ保存エリアとキャリアレコード保存エリアに格納されるデータの説明図である。
【図８】アドレス帳データ保存エリアの各データ項目の説明図である。
【図９】キャリアレコード保存エリアの各データ項目の説明図である。
【図１０】図２の名刺情報特定手段およびデータ形式変換手段の動作の説明図である。
【図１１】図１の名刺情報交換管理手段の要求先ユーザのエントリが存在しない場合の要求元（ユーザＡ）のDBCフレーム側の処理手順を説明するためのフローチャートである。
【図１２】図１の名刺情報交換管理手段の要求先ユーザのエントリが存在しない場合の要求先（ユーザＢ）のDBCフレーム側の処理手順を説明するためのフローチャートである。
【図１３】図１の名刺情報交換管理手段の要求先ユーザのエントリが存在しない場合のユーザＢの名刺情報が送られてきたときのユーザＡのDBCフレーム側の処理手順を説明するためのフローチャートである。
【図１４】図１の名刺情報交換管理手段の要求先ユーザのエントリが存在する場合のユーザＢのDBCフレーム側の処理手順を説明するためのフローチャートである。
【図１５】図１の名刺情報交換管理手段の要求先ユーザのエントリが存在する場合のユーザＡのDBCフレーム側の処理手順を説明するためのフローチャートである。
【図１６】図１のアドレス帳保守手段の名刺情報の更新元（ユーザＡ）のDBCフレーム側の処理手順を説明するためのフローチャートである。
【図１７】図１のアドレス帳保守手段の名刺情報の更新元（ユーザＡ）のDBCフレーム側の処理手順を説明するための図１６の続きのフローチャートである。
【図１８】図１のアドレス帳保守手段の更新対象（ユーザＢ）のDBCフレーム側の処理手順を説明するためのフローチャートである。
【図１９】図１のアドレス帳保守手段の更新対象（ユーザＢ）のDBCフレーム側の処理手順を説明するための図１８の続きのフローチャートである。
【図２０】本発明の実施の形態によるデータエントリ更新時の転送動作の概念図である。
【図２１】本発明の実施の形態によるデータエントリ更新時の転送先Address Bookへの反映の手順の説明図である。
【図２２】本発明の実施の形態によるアドレス帳データ保存エリアの転送設定処理手順を説明するためのフローチャートである。
【図２３】本発明の実施の形態によるアドレス帳データ保存エリアの転送設定処理手順を説明するための図２２の続きのフローチャートである。
【図２４】本発明の実施の形態によるアドレス帳データ保存エリアの転送処理手順を説明するためのフローチャートである。
【図２５】本発明の実施の形態によるキャリアレコード保存エリアの転送設定処理手順を説明するためのフローチャートである。
【図２６】本発明の実施の形態によるキャリアレコード保存エリアの転送設定処理手順を説明するための図２５の続きのフローチャートである。
【図２７】本発明の実施の形態によるキャリアレコード保存エリアの転送処理手順を説明するためのフローチャートである。
【図２８】本発明の実施の形態に係わる名刺交換要求を受けたときの注意メッセージの表示画面例である。
【図２９】情報コードをスキャンして名刺情報を要求するときのユーザ端末の画面遷移図である。
【図３０】名刺IDを手入力して名刺情報を要求するときのユーザ端末の画面遷移図である。
【図３１】名刺情報を手入力するときのユーザ端末の画面遷移図である。
【図３２】携帯電話のローカルアドレス帳と連携するときのユーザ端末の画面遷移図である。
【図３３】名刺を発注する際のユーザ端末の画面遷移図である。
【図３４】名刺情報交換処理において、名刺情報の要求を受けている場合のユーザ端末の画面遷移図である。
【図３５】本発明の実施の形態による転送処理において、転送受け入れ指定時のユーザ端末の画面遷移図である。
【図３６】本発明の実施の形態による転送処理において、転送要求の承認をおこなうときのユーザ端末の画面遷移図である。
【図３７】本発明の実施の形態による情報コードの記載された名刺の説明図である。
【符号の説明】
【０１９８】
１  名刺情報管理システム
２、２Ａ、２Ｂ  ユーザ端末
３  SPサーバ
４  通信ネットワーク
５  名刺
６  情報コード
１１、２１、３１  送受信部
１２、２２、３２  中央演算処理部
１３、３３  記憶部
２４  入力部
２５  表示部
１２１、３２１  送受信処理手段
１２２  基本情報登録手段
１２３  端末通信手段
１２４  名刺情報要求手段
１２５  名刺情報取得手段
１２６  名刺情報交換管理手段
１２７  アドレス帳保守手段
１２８  名刺情報転送手段
１２９  出力手段
１３１  ユーザ情報DB
１３２  ユーザデータ保存領域（DB）
１３３  SP DB
３２２  要求情報入力手段
３２３  名刺情報特定手段
３２４  データ形式変換手段
３２５  名刺情報送信手段
３３１  名刺情報DB
３３２  ID管理DB
【図１】
2005107877.tif 000003
【図２】
2005107877.tif 000004
【図４】
2005107877.tif 000005
【図６】
2005107877.tif 000006
【図７】
2005107877.tif 000007
【図８】
2005107877.tif 000008
【図９】
2005107877.tif 000009
【図１１】
2005107877.tif 000010
【図１２】
2005107877.tif 000011
【図１３】
2005107877.tif 000012
【図１４】
2005107877.tif 000013
【図１５】
2005107877.tif 000014
【図１６】
2005107877.tif 000015
【図１７】
2005107877.tif 000016
【図１８】
2005107877.tif 000017
【図１９】
2005107877.tif 000018
【図２０】
2005107877.tif 000019
【図２１】
2005107877.tif 000020
【図２２】
2005107877.tif 000021
【図２３】
2005107877.tif 000022
【図２４】
2005107877.tif 000023
【図２５】
2005107877.tif 000024
【図２６】
2005107877.tif 000025
【図２７】
2005107877.tif 000026
【図３７】
2005107877.tif 000027
【図３】
2005107877.tif 000028
【図５】
2005107877.tif 000029
【図１０】
2005107877.tif 000030
【図２８】
2005107877.tif 000031
【図２９】
2005107877.tif 000032
【図３０】
2005107877.tif 000033
【図３１】
2005107877.tif 000034
【図３２】
2005107877.tif 000035
【図３３】
2005107877.tif 000036
【図３４】
2005107877.tif 000037
【図３５】
2005107877.tif 000038
【図３６】
2005107877.tif 000039