JP5617434B2 - 情報処理装置及び方法、並びにプログラム - Google Patents

Description

本発明は、情報処理装置及び方法、並びにプログラムに関し、特に、端末情報により特定される端末と、当該端末情報を登録している情報処理装置とを含む情報処理システムにおいて、情報処理装置側でデータロストが発生した場合であっても、情報処理装置と端末との間で端末情報の整合性を保つことを可能にする技術に関する。

近年、デジタルフォトフレーム（Ｄｉｇｉｔａｌ Ｐｈｏｔｏ Ｆｒａｍｅ）として機能する端末（以下、「ＤＰＦ端末」と呼ぶ）の中には、インターネット等を介して他の装置と通信する通信機能を有しているものが多い。このため、サーバからインターネット等を介してＤＰＦ端末に対して、ＤＰＦ端末で表示対象となる写真のデータを提供する情報処理システムが、近年登場してきている（特許文献１参照）。このような情報処理システムを、以下、「写真提供システム」と呼ぶ。

図１６は、従来の写真提供システムの構成例を示している。
従来の写真提供システムにおいては、ＤＰＦ端末３１０とサーバ３３０とは、インターネット等のネットワーク３２０を介して相互に接続されている。サーバ３３０にはまた、ＤＢ（Ｄａｔａｂａｓｅ）３４０も接続されている。

図１７は、サーバ３３０からＤＰＦ端末３１０に対して写真のデータを提供する従来の手法を説明する図である。
サーバ３３０は、写真のデータをＤＰＦ端末３１０に対して安全かつ確実に送信するために、ＤＰＦ端末３１０の端末固有ＩＤ（Ｉｄｅｎｔｉｆｙ）を登録した後、ＤＰＦ端末３１０に対してメールアドレスを付与する。
この場合、図１７には図示はしないが、サーバ３３０は、ＤＰＦ端末３１０の端末固有ＩＤ及びメールアドレスを対応付けて、ＤＰＦ端末３１０の端末情報としてＤＢ３４０に記憶する。

その後、ＤＰＦ端末３１０が、写真のデータの提供を要求する場合、先ず、自機の端末固有ＩＤ及びメールアドレスを対応付けて、端末情報としてネットワーク３２０を介してサーバ３３０に送信する。
サーバ３３０は、送信されてきた端末情報と、ＤＢ３４０に記憶されている端末情報とが一致していることを確認すると、端末情報に含まれるメールアドレスを宛先として、写真のデータを送信する。
これにより、サーバ３３０から送信された写真のデータは、ネットワーク３２０を介して、メールアドレスが付与されたＤＰＦ端末３１０に提供される。

特開２００９−１９９１４９号公報

しかしながら、サーバ３３０のＤＢ３４０に障害が発生して、ＤＢ３４０に記憶された情報の消失（以下、「データロスト」と呼ぶ）が発生する場合がある。このような場合には、ＤＰＦ端末３１０の端末情報について、ＤＰＦ端末３１０側と、ＤＢ３４０によって管理されているサーバ３３０側とで整合性を保つことができない。
即ち、データロストが発生した後に、ＤＰＦ端末３１０が端末情報を送信してきても、サーバ３３０は、送信されてきた端末情報と同一情報がＤＢ３４０に記憶されていることを確認できない場合がある。このような場合、ＤＰＦ端末３１０は、写真のデータをＤＰＦ端末３１０に送信することが不可能になる。

さらに、以下、サーバ３３０側のＤＢ３４０においてデータロストが発生した場合について具体的に説明する。

例えば、ＡＭ６：００の時点において、ＤＢ３４０は、ＤＰＦ端末３１０の端末情報が記憶されていない状態であったものとする。サーバ３３０は、このような状態のＤＢ３４０の記憶内容のバックアップ（Ｂａｃｋｕｐ）を行ったものとする。即ち、バックアップされた内容には、端末情報が含まれていないものとする。

そして、ＡＭ１０：００の時点において、サーバ３３０は、ＤＰＦ端末３１０の端末固有ＩＤを登録して、ＤＰＦ端末３１０に対してメールアドレスを付与したものとする。
即ち、サーバ３３０は、ＤＰＦ端末３１０の端末固有ＩＤ及びメールアドレスを、端末情報としてＤＢ３４０に記憶したものとする。

さらに、その後のＡＭ１１：００の時点においてＤＢ３４０にデータロストが発生したため、サーバ３３０は、ＤＢ３４０の記憶内容を、ＡＭ６：００の時点においてバックアップした内容にリストア（Ｒｅｓｔｏｒｅ）し、復旧を行ったものとする。

さらにその後のＡＭ１１：３０の時点において、ＤＰＦ端末３１０が、写真のデータの提供を要求するために、端末情報をネットワーク３２０を介してサーバ３３０に送信したものとする。
この場合、サーバ３３０は、送信されてきた端末情報が、ＤＢ３４０に記憶されているか否かを判定する。しかしながら、この時点のＤＢ３４０には、ＡＭ１１：００の時点の復旧後の記憶内容、即ち、ＡＭ６：００の時点の記憶内容が含まれているため、ＡＭ１０：００の時点で記憶された端末情報は含まれていない。従って、サーバ３３０は、送信されてきた端末情報がＤＢ３４０に記憶されていないと判定し、写真のデータの送信を禁止する。
即ち、ＤＰＦ端末３１０にとっては、ＡＭ１０：００の時点で端末情報がサーバ３３０側に登録されたため、その後のＡＭ１１：３０の時点では、写真のデータが送信されてくるはずが、送信されてこないという問題が生じる。

このような問題は、ＤＰＦ端末３１０とサーバ３３０とを含む写真提供システムのみならず、端末情報により特定される端末と、当該端末情報を登録している情報処理装置とを含む情報処理システムにおいても生ずることになる。

従って、ＤＰＦ端末３１０等の端末と、当該端末の端末情報を登録しているサーバ３３０等の情報処理装置とを含む情報処理システムにおいて、情報処理装置側でデータロストが発生した場合であっても、情報処理装置と端末との間で端末情報の整合性を保つことが可能な手法の実現が求められている。

本発明は、このような状況に鑑みてなされたものであり、端末情報により特定される端末と、当該端末情報を登録している情報処理装置とを含むシステムにおいて、情報処理装置側でデータロストが発生した場合であっても、情報処理装置と端末との間で端末情報の整合性を保つことを目的とする。

本発明の一態様によると、
複数の情報からなる端末情報により特定される端末と通信をする情報処理装置であって、
前記端末から前記端末情報の少なくとも一部が送信されてきた場合、前記端末情報の少なくとも一部を受信する端末情報受信手段と、
前記端末情報受信手段により少なくとも一部が取得された前記端末情報の登録の有無を検出する登録有無検出手段と、
前記情報処理装置と前記端末との間の前記端末情報の整合性を保って、前記端末情報を登録する端末情報整合手段と、を備え、
前記端末情報整合手段による前記端末情報の登録先は、所定のタイミング毎にバックアップされるデータベースであって、前記端末情報を一時的に記憶する一次領域と、前記端末情報を登録するために記憶する二次領域とを含むデータベースであり、
前記端末情報整合手段は、
前記登録有無検出手段により前記端末情報の未登録が検出された場合、前記端末情報受信手段により取得された前記端末情報を前記一次領域に一時的に記憶する一次登録手段と、
前記一次領域に記憶した前記端末情報のバックアップが行われた場合に、前記一次領域に記憶された前記端末情報を前記二次領域に登録するために記憶する二次登録手段と、
を備えることを特徴とする情報処理装置を提供する。

本発明の他の態様によると、上述した本発明の一態様に係る情報処理装置に対応する方法及びプログラムの各々を提供する。

本発明によれば、情報処理装置側でデータロストが発生した場合であっても、情報処理装置と端末との間で端末情報の整合性を保つことができる。

本発明の第１実施形態に係る情報処理装置としてのサーバから、ＤＰＦ端末に対して写真のデータを提供する写真提供システムの構成例である。 ＤＰＦ端末で行われるＤＰＦ端末側連携処理とサーバで行われるサーバ側連携処理との関係の一例を説明するフローチャートである。 Ａｃｔｉｖａｔｅ状態の問い合わせのメッセージフォーマットの記述例である。 ＤＢの構造例を説明する図である。 メールアドレス配信部により配信されたメールアドレスを含む端末情報のメッセージフォーマットの記述例である。 本発明の第２実施形態に係る情報処理装置としてのサーバから、ＤＰＦ端末に対して写真のデータを提供する写真提供システムの構成例である。 ＤＰＦ端末及びサーバに登録されているメールアドレスの変更を行う画面の一例である。 ＤＰＦ端末で行われるＤＰＦ端末側連携処理とサーバで行われるサーバ側連携処理の流れの一例を説明するフローチャートである。 Ａｃｔｉｖａｔｅ状態の問い合わせのメッセージフォーマットの記述例である。 ＤＰＦ端末１０で行われるＤＰＦ端末側連携処理とサーバ３０で行われるサーバ側連携処理との関係の一例を説明するフローチャートである。 本発明の第４実施形態に係る情報処理装置としてのサーバから、ＤＰＦ端末に対して写真のデータを提供する写真提供システムの構成例である。 ＤＰＦ端末１０で行われるＤＰＦ端末側連携処理とサーバ３０で行われるサーバ側連携処理との関係の一例を説明するフローチャートである。 一次記憶処理の詳細な流れの一例を説明するフローチャートである。 二次記憶処理の詳細な流れの一例を説明するフローチャートである。 図１のサーバのハードウェアの構成を示すブロック図である。 従来の写真提供システムの構成例である。 サーバからＤＰＦ端末に対して写真のデータを提供する従来の手法を説明する図である。

以下、本発明の一実施形態を図面に基づいて説明する。

［第１実施形態］
図１は、本発明の第１実施形態に係る情報処理装置としてのサーバから、ＤＰＦ端末に対して写真のデータを提供する写真提供システムの構成例を示している。
図１に示す写真提供システムにおいては、ＤＰＦ端末１０とサーバ３０とは、インターネット等のネットワーク２０を介して相互に接続されている。サーバ３０にはまた、ＤＢ４０も接続されている。

サーバ３０は、写真のデータをＤＰＦ端末１０に対して安全かつ確実に送信するために、ＤＰＦ端末１０の端末固有ＩＤを登録した後、ＤＰＦ端末１０に対してメールアドレスを付与する。
この場合、サーバ３０は、ＤＰＦ端末１０の端末固有ＩＤ及びメールアドレスを、端末情報としてＤＢ４０に記憶する。
その後、ＤＰＦ端末１０が、写真のデータの提供を要求する場合、先ず、自機の端末固有ＩＤ及びメールアドレスを、端末情報としてネットワーク２０を介してサーバ３０に送信する。
サーバ３０は、送信されてきた端末情報と、ＤＢ４０に記憶されている端末情報とが一致していることを確認すると、端末情報に含まれるメールアドレスを宛先として、写真のデータを送信する。
これにより、サーバ３０から送信された写真のデータは、ネットワーク２０を介して、メールアドレスが付与されたＤＰＦ端末１０まで送信される。
さらに、ＤＰＦ端末１０は、ＤＰＦ端末側連携処理を実行することができる。
ＤＰＦ端末側連携処理とは、後述のサーバ３０において実行されるサーバ側連携処理に対応して、サーバ３０側のＤＢ４０においてデータロストが発生しても、端末情報（端末固有ＩＤ及びメールアドレス）をＤＰＦ端末１０とサーバ３０との間において同期させるために、ＤＰＦ端末１０において実行される処理をいう。
ＤＰＦ端末１０は、このようなＤＰＦ側連携処理を実行すべく、端末情報記憶部１１と、端末情報送信部１２と、通信制御部１３と、端末情報受信部１４と、端末情報登録部１５と、を備えている。

端末情報記憶部１１は、端末固有ＩＤと、後述のサーバ３０のメールアドレス発行部６０で発行されたメールアドレスとを対応付けて、端末情報として記憶する。

端末情報送信部１２は、例えば写真のデータの提供を要求するタイミングで、端末情報の少なくとも一部（少なくとも端末固有ＩＤ）を端末情報記憶部１１から読み出す。そして、端末情報送信部１２は、通信制御部１３の制御の下、端末情報の少なくとも一部（少なくとも端末固有ＩＤ）をサーバ３０に送信する。

通信制御部１３は、ネットワーク２０と接続された他の機器との通信、図１の例ではサーバ３０との通信を制御する。
具体的には、通信制御部１３は、端末情報送信部１２から送信された端末情報の少なくとも一部（少なくとも端末固有ＩＤ）を、ネットワーク２０を介してサーバ３０に送信する制御を実行する。
詳細については後述するが、当該端末情報の少なくとも一部（少なくとも端末固有ＩＤ）がサーバ３０に送信される前に、サーバ３０側のＤＢ４０においてデータロストが発生していた場合、サーバ３０は、当該端末固有ＩＤはＤＢ４０に登録（記憶）されていないと検出することになる。このような場合、サーバ３０は、端末固有ＩＤがＤＢ４０に登録されていない旨を示す情報（以下、「端末固有ＩＤの未登録情報」）を、ネットワーク２０を介してＤＰＦ端末１０に送信する。
そこで、通信制御部１３は、サーバ３０から送信された端末固有ＩＤの未登録情報を受信する。
この場合、端末情報送信部１２は、再度、通信制御部１３の制御の下、端末情報の少なくとも一部（少なくとも端末固有ＩＤ）をサーバ３０に送信する。
通信制御部１３は、端末情報送信部１２から再送信された端末情報の少なくとも一部（少なくとも端末固有ＩＤ）を、ネットワーク２０を介してサーバ３０に送信する制御を実行する。
詳細については後述するが、サーバ３０は、当該端末情報の少なくとも一部（少なくとも端末固有ＩＤ）を受信すると、新たなメールアドレスを発行する。サーバ３０は、少なくとも新たなメールアドレス（端末情報の少なくとも一部）を、ネットワーク２０を介してＤＰＦ端末１０に送信する。
通信制御部１３は、当該端末情報の少なくとも一部（少なくともメールアドレス）を、ネットワーク２０を介して受信する制御を実行する。

端末情報受信部１４は、通信制御部１３の制御の下、サーバ３０から送信された端末情報の少なくとも一部（少なくともメールアドレス）を受信して、端末情報登録部１５に供給する。

端末情報登録部１５は、端末情報受信部１４に受信された端末情報の少なくとも一部（少なくともメールアドレス）を含む、端末情報を端末情報記憶部１１に登録（記録）する。

このような端末側連携処理を実行するＤＰＦ端末１０に対して、サーバ３０は、サーバ側連携処理を実行することができる。
サーバ側連携処理とは、ＤＰＦ端末１０において実行されるＤＰＦ側連携処理に対応して、サーバ３０側のＤＢ４０においてデータロストが発生しても、端末情報（端末固有ＩＤ及びメールアドレス）をＤＰＦ端末１０とサーバ３０との間において同期させるために、サーバ３０において実行される処理をいう。
このようなサーバ３０は、サーバ側連携処理を実行すべく、通信制御部３１と、端末情報受信部３２と、登録有無検出部３３と、端末情報整合部３４と、を備えている。

通信制御部３１は、ネットワーク２０と接続された他の機器との通信、図１の例ではＤＰＦ端末１０との通信を制御する。
具体的には例えば、通信制御部３１は、ＤＰＦ端末１０からネットワーク２０を介して送信された端末情報の少なくとも一部（少なくとも端末固有ＩＤ）を受信する制御を実行する。

端末情報受信部３２は、通信制御部３１の制御の下、ＤＰＦ端末１０から送信された端末情報の少なくとも一部（少なくとも端末固有ＩＤ）を受信する。

登録有無検出部３３は、端末情報受信部３２に受信された端末情報の少なくとも一部から端末固有ＩＤを認識し、端末固有ＩＤがＤＢ４０に登録されているか否かを検出する。登録有無検出部３３は、その検出結果に基づいて、ＤＢ４０にデータロストが発生しているか否かを検出する。即ち、登録有無検出部３３は、端末固有ＩＤがＤＢ４０に登録されていないことを検出することによって、ＤＢ４０におけるデータロストの発生を検出する。登録有無検出部３３は、ＤＢ４０におけるデータロストの発生を検出した場合、通信制御部３１の制御の下、端末固有ＩＤがＤＢ４０に登録されていない旨を示す情報、即ち端末固有ＩＤの未登録情報をＤＰＦ端末１０に送信する。
すると、上述したように、ＤＰＦ端末１０からは、端末情報の一部（少なくとも端末固有ＩＤ）がネットワーク２０を介して送信されてくる。そこで、登録有無検出部３３は、当該端末情報の一部（少なくとも端末固有ＩＤ）を、通信制御部３１及び端末情報受信部３２を介して取得して、端末情報整合部３４に供給する。

端末情報整合部３４は、メールアドレス発行部６０と、メールアドレス配信部６１と、を備えている。

メールアドレス発行部６０は、登録有無検出部３３によってデータロストの発生後に取得された端末情報の一部（少なくとも端末固有ＩＤ）が供給されてきた場合、新たなメールアドレスを発行する。
メールアドレス発行部６０により発行されたメールアドレスは、メールアドレス配信部６１に供給されると共に、端末情報受信部３２に受信された端末固有ＩＤと対応付けられて、端末情報としてＤＢ４０に記憶される。

メールアドレス配信部６１は、通信制御部３１の制御の下、メールアドレス発行部６０が発行したメールアドレスをＤＰＦ端末１０に配信する。
すると、ＤＰＦ端末１０側では、上述したように、メールアドレス発行部６０が発行したメールアドレスと、端末固有ＩＤとを対応付けて、端末情報として、内部の端末情報記憶部１１に記憶させる。
これにより、端末情報について、ＤＰＦ端末１０側の端末情報記憶部１１と、サーバ３０側のＤＢ４０との間で整合性が保たれることになる。

以上、図１を参照して、本発明の第１実施形態に係る写真提供システムの構成例について説明した。
次に、図２を参照して、本発明の第１実施形態に係る写真提供システムで実行される処理のうち、ＤＰＦ端末１０で行われるＤＰＦ端末側連携処理と、サーバ３０で行われるサーバ側連携処理の流れの一例について説明する。

図２は、ＤＰＦ端末１０で行われるＤＰＦ端末側連携処理とサーバ３０で行われるサーバ側連携処理との関係の一例を説明するフローチャートである。

図２において、実線の矢印は、ＤＰＦ端末１０又はサーバ３０内で実行される処理の流れを示している。一方、点線の矢印は、ＤＰＦ端末１０とサーバ３０との一方から他方へ伝達される情報の流れを示している。
なお、点線の矢印で示す情報の伝達は、実際には、プロトコルにＨＴＴＰ（ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）を用い、メッセージフォーマットにＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いたＸＭＬ ｏｖｅｒ ＨＴＴＰにより行われるものとする。
なお、この段落の記載事項は、他のフローチャートにおいても同様にあてはまるものとする。

例えば、ＤＰＦ端末側連携処理とサーバ側連携処理は、ＤＰＦ端末１０がサーバ３０に初期登録を要求する場合又は写真のデータの提供を要求する場合に開始する。
この場合、ＤＰＦ端末１０が写真のデータの提供を要求する場合には、サーバ３０により既に付されたメールアドレスが、端末固有ＩＤと対応付けられて、端末情報として端末情報記憶部１１に記憶されている。これに対して、ＤＰＦ端末１０がサーバ３０に初期登録を要求する場合には、サーバ３０によりメールアドレスは未だ付されていないので、端末固有ＩＤのみが、端末情報として端末情報記憶部１１に記憶されている。

ステップＳ１１において、ＤＰＦ端末１０の端末情報送信部１２は、通信制御部１３の制御の下、端末情報記憶部１１に記憶されている端末情報のうち、端末固有ＩＤをネットワーク２０を介してサーバ３０に送信する。

ステップＳ３１において、サーバ３０の端末情報受信部３２は、通信制御部３１の制御の下、ステップＳ１１の処理でＤＰＦ端末１０から送信された端末固有ＩＤを、ネットワーク２０を介して受信する。

ここで、ＤＰＦ端末１０のステップＳ１１の処理の趣旨は、ＤＰＦ端末１０の端末固有ＩＤ及びメールアドレスを含む端末情報がサーバ３０において登録されている状態（以下、「Ａｃｔｉｖａｔｅ状態」と呼ぶ）の問い合わせを行うことである。
このため、本実施形態では、ステップＳ１１とステップＳ３１の各処理で送受信される端末固有ＩＤは、図３に示すようなＡｃｔｉｖａｔｅ状態の問い合わせのメッセージフォーマットに従って記述される。

図３は、Ａｃｔｉｖａｔｅ状態の問い合わせのメッセージフォーマットの記述例である。
図３において、♯Ｋ（Ｋは整数値）は、行番号Ｋを示している。そこで、行番号Ｋを適宜用いて、端末情報のメッセージフォーマットについて説明する。
１行目のタグ＜ｄｐｆ＞は、５行目のタグ＜／ｄｐｆ＞と組になって用いられる。即ち、タグ＜ｄｐｆ＞とタグ＜／ｄｐｆ＞の間に囲まれている情報は、ＤＰＦ端末１０の情報であることを示す。
２行目のタグ＜ａｃｔｉｖａｔｅ＞は、４行目のタグ＜／ａｃｔｉｖａｔｅ＞と組になって用いられる。即ち、タグ＜ａｃｔｉｖａｔｅ＞とタグ＜／ａｃｔｉｖａｔｅ＞との間に囲まれている情報は、Ａｃｔｉｖａｔｅ状態の問い合わせの対象であることを示す。
３行目のタグ＜ｓｅｒｉａｌ−ｉｄ＞は、同３行目のタグ＜／ｓｅｒｉａｌ−ｉｄ＞と組になって用いられる。即ち、タグ＜ｓｅｒｉａｌ−ｉｄ＞とタグ＜／ｓｅｒｉａｌ−ｉｄ＞との間に囲まれている情報は、ＤＰＦ端末１０の端末固有ＩＤであることを示している。図３の例では、ＤＰＦ端末１０の端末固有ＩＤは、“０１２３４５６７８９ａｂｃｄｅ”とされている。

サーバ３０は、図２のステップＳ３１の処理で、このようなＡｃｔｉｖａｔｅ状態の問い合わせを受信すると、当該問い合わせに応答すべく、次のようなステップＳ３２以降の処理を実行する。

ステップＳ３２において、サーバ３０の登録有無検出部３３は、ステップＳ３１の処理で受信された端末固有ＩＤが、ＤＢ４０に登録されているか否かを判定する。
即ち、ステップＳ３１の処理で、図３に示すＡｃｔｉｖａｔｅ状態の問い合わせが受信された場合には、端末固有ＩＤとして“０１２３４５６７８９ａｂｃｄｅ”が受信されたことになる。そこで、ステップＳ３２の処理では、“０１２３４５６７８９ａｂｃｄｅ”がＤＢ４０に登録されているか否かが判定される。

例えば、ＤＰＦ端末１０が写真のデータの提供を要求する場合であって、ＤＢ４０にデータロストが発生していなければ、“０１２３４５６７８９ａｂｃｄｅ”はＤＢ４０に既に登録（記憶）されているはずである。
このような場合、ステップＳ３２においてＹＥＳであると判定されて、処理はステップＳ３３に進む。

ステップＳ３３において、サーバ３０の登録有無検出部３３は、通信制御部３１の制御の下、端末固有ＩＤがＤＢ４０に登録されていることを示す情報（以下、「端末固有ＩＤの登録情報」と呼ぶ）を、ネットワーク２０を介してＤＰＦ端末１０に送信する。
これにより、サーバ側連携処理は終了する。
この場合、サーバ３０は、ＤＰＦ端末１０から送信されてきた端末固有ＩＤがＤＢ４０に登録されているという状況から、ＤＢ４０に障害は生じておらずデータロストは発生していないことを検出することができる。

一方、ＤＰＦ端末側連携処理としては、ステップＳ１２において、ＤＰＦ端末１０の端末情報受信部１４は、通信制御部１３の制御の下、サーバ３０から送信されてきた端末固有ＩＤの登録情報を受信する。

ステップＳ１３において、端末情報受信部１４は、端末固有ＩＤの未登録情報を受信したか否かを判定する。
ここでは、ステップＳ１２の処理で端末固有ＩＤの登録情報が受信されたので、ステップＳ１３においてＮＯであると判定されて、ＤＰＦ端末側連携処理は終了する。
即ち、ＤＰＦ端末１０は、端末固有ＩＤの登録情報を受信したという状況から、サーバ３０のＤＢ４０に障害は生じておらずデータロストが発生していないということを検出することができる。

このようにして、サーバ３０のＤＢ４０に障害は生じておらずデータロストが発生していない状態で、ＤＰＦ端末側連携処理及びサーバ端末側連携処理が終了すると、図示はしないが、サーバ３０は、ＤＢ４０に登録されていたメールアドレスを宛先として、写真のデータを送信する。
これにより、サーバ３０から送信された写真のデータは、ネットワーク２０を介して、メールアドレスが付与されたＤＰＦ端末１０まで送信される。

これに対して、ＤＰＦ端末１０が写真のデータの提供を要求したところ、ＤＢ４０にデータロストが発生している場合、又は、ＤＰＦ端末１０がサーバ３０に初期登録を要求する場合には、端末固有ＩＤはＤＢ４０に登録（記憶）されていない。上述の図３の例であれば、“０１２３４５６７８９ａｂｃｄｅ”はＤＢ４０に登録（記憶）されていない。
このような場合、サーバ側連携処理では、ステップＳ３２においてＮＯであると判定されて、処理はステップＳ３４に進む。

ステップＳ３４において、サーバ３０の登録有無検出部３３は、データロストを検出する。
即ち、サーバ３０は、ＤＰＦ端末１０から端末固有ＩＤが送信されているにも関わらず、当該端末固有ＩＤがＤＢ４０に登録（記憶）されていないという状態から、サーバ３０のＤＢ４０に障害が発生しデータロストが発生した状態であることを検出できる。なお、ここでいうデータロストが発生した状態とは、データロストが発生した直後の状態のみならず、データロスト後にＤＢ４０がリストアした状態も含む。

ステップＳ３５において、サーバ３０の登録有無検出部３３は、通信制御部３１の制御の下、端末固有ＩＤがＤＢ４０に登録されていないことを示す情報、即ち端末固有ＩＤの未登録情報を、ネットワーク２０を介してＤＰＦ端末１０に送信する。

すると、ＤＰＦ端末側連携処理のステップＳ１２において、ＤＰＦ端末１０の端末情報受信部１４は、通信制御部１３の制御の下、サーバ３０から送信されてきた端末固有ＩＤの未登録情報を受信する。

ステップＳ１３において、端末情報受信部１４は、端末固有ＩＤの未登録情報を受信したか否かを判定する。
ここでは、ステップＳ１２の処理で端末固有ＩＤの未登録情報が受信されたので、ステップＳ１３においてＹＥＳであると判定されて、処理はステップＳ１４に進む。

ステップＳ１４において、ＤＰＦ端末１０の端末情報登録部１５は、データロストを検出する。
即ち、ＤＰＦ端末１０は、以前に、サーバ３０に対し端末固有ＩＤを登録してメールアドレスを付与されたにも関わらず、端末固有ＩＤの未登録情報を受信したという状況から、サーバ３０のＤＢ４０に障害が発生しデータロストが発生した状態であることを検出できる。なお、ここでいうデータロストが発生した状態とは、データロストが発生した直後の状態のみならず、データロスト後にＤＢ４０がリストアした状態も含む。

ステップＳ１５において、ＤＰＦ端末１０の端末情報送信部１２は、通信制御部１３の制御の下、端末情報記憶部１１に記憶されている端末情報のうち、端末固有ＩＤをネットワーク２０を介してサーバ３０に再送信する。

ステップＳ３６において、サーバ３０の端末情報受信部３２は、通信制御部３１の制御の下、ステップＳ１５の処理でＤＰＦ端末１０から再送信された端末固有ＩＤを、ネットワーク２０を介して再受信する。
再受信された取得された端末固有ＩＤは、登録有無検出部３３を介して端末情報整合部３４に供給される。

ステップＳ３７において、端末情報整合部３４のメールアドレス発行部６０は、ステップＳ３６の処理で受信された端末固有ＩＤに基づいて、メールアドレスを発行する。

ステップＳ３８において、メールアドレス発行部６０は、ステップＳ３６の処理で受信された端末固有ＩＤと、ステップＳ３７の処理で発行されたメールアドレスとを対応付けて、端末情報としてＤＢ４０に登録（記憶）する。

図４は、ＤＢ４０のうち、端末固有ＩＤとメールアドレスとを含む端末情報を登録（記憶）するテーブル（領域）の構造例を示している。
図４の例では、テーブルは行列構造を有しているため、以下、図４中横方向の項目の集合体を「行」と呼び、同図中縦方向の項目の集合体を「列」と呼ぶ。図４において、♯Ｋ（Ｋは整数値）は、行番号Ｋを示している。そこで、以下、行番号Ｋを用いて説明する。
図４の例では、Ｋ行には、所定の１つのＤＰＦ端末１０が対応している。
Ｋ行目の第１列目の「端末固有ＩＤ」の項目には、当該Ｋ行に対応するＤＰＦ端末１０の端末固有ＩＤが登録（記憶）される。
Ｋ行目の第２列目の「メールアドレス」の項目には、当該Ｋ行に対応するＤＰＦ端末１０のメールアドレス、即ち、当該Ｋ行目の第１列目に登録（記憶）された端末固有ＩＤに対して付されたメールアドレスが登録（記憶）される。
具体的には、１行目の第１列目には“０１２３４５６７８９ａｂｃｄｅ”が記憶され、当該１行目の第２列目には、“ｊ８ｇｔ９２ｍｎ＠ａ．ａｆ．ｊｐ”が記憶されている。従って、１行目に対応するＤＰＦ端末１０の端末固有ＩＤは、“０１２３４５６７８９ａｂｃｄｅ”であり、当該ＤＰＦ端末１０のメールアドレスは、“ｊ８ｇｔ９２ｍｎ＠ａ．ａｆ．ｊｐ”であることがわかる。

図２のステップＳ３９において、サーバ３０のメールアドレス配信部６１は、通信制御部３１の制御の下、ステップＳ３７の処理で発行されたメールアドレス、即ちステップＳ３８の処理でＤＢ４０に登録（記憶）されたメールアドレスをＤＰＦ端末１０に配信する。
この場合のメールアドレスの配信形態は、特に限定されないが、本実施形態では、図５に示すようなメッセージフォーマットが採用されている。

図５は、ステップＳ３９の処理で配信されるメールアドレスのメッセージフォーマットの記述例である。
図５において、♯Ｋ（Ｋは整数値）は、行番号Ｋを示している。そこで、行番号Ｋを適宜用いて、端末情報のメッセージフォーマットについて説明する。
１行目のタグ＜ｄｐｆ＞は、５行目のタグ＜／ｄｐｆ＞と組になって用いられる。即ち、タグ＜ｄｐｆ＞とタグ＜／ｄｐｆ＞の間に囲まれている情報は、ＤＰＦ端末１０の情報であることを示す。
２行目のタグ＜ａｕｔｈｅｎｔｉｃａｔｉｏｎ＞は、４行目のタグ＜／ａｕｔｈｅｎｔｉｃａｔｉｏｎ＞と組になって用いられる。即ち、タグ＜ａｕｔｈｅｎｔｉｃａｔｉｏｎ＞とタグ＜／ａｕｔｈｅｎｔｉｃａｔｉｏｎ＞との間に囲まれている情報は、認証の対象であることを示す。
３行目のタグ＜ｅｍａｉｌ＞は、同３行目のタグ＜／ｅｍａｉｌ＞と組になって用いられる。即ち、タグ＜ｅｍａｉｌ＞とタグ＜／ｅｍａｉｌ＞との間に囲まれている情報は、ＤＰＦ端末１０に新たに付されたメールアドレスであることを示している。図３の例では、ＤＰＦ端末１０に新たに付されたメールアドレスは、“ｊ８ｇｔ９２ｍｎ＠ａ．ａｆ．ｊｐ”とされている。

図２のステップＳ３９の処理で、このようなメッセージフォーマットを用いてメールアドレスがサーバ３０からＤＰＦ端末１０に配信されると、サーバ側連携処理は終了となる。

一方、ＤＰＦ端末側連携処理では、ステップＳ１６において、ＤＰＦ端末１０の端末情報受信部１４は、通信制御部１３の制御の下、ステップＳ３９の処理でサーバ３０から送信されたメールアドレスを受信して、端末情報登録部１５に供給する。例えば図５の例では、“ｊ８ｇｔ９２ｍｎ＠ａ．ａｆ．ｊｐ”が受信されて、端末情報登録部１５に供給される。

ステップＳ１７において、端末情報登録部１５は、ステップＳ１６の処理で受信されたメールアドレスを、既に記憶されている端末固有ＩＤと対応付けて、端末情報として登録（記憶）する。
これにより、ＤＰＦ端末側連携処理は終了となる。

ここで、例えばステップＳ１１の処理で、図３の例の“０１２３４５６７８９ａｂｃｄｅ”が端末固有ＩＤとして送信され、図５の例の“ｊ８ｇｔ９２ｍｎ＠ａ．ａｆ．ｊｐ”が受信された場合には、“０１２３４５６７８９ａｂｃｄｅ”と“ｊ８ｇｔ９２ｍｎ＠ａ．ａｆ．ｊｐ”との組が、端末情報として端末情報登録部１５に登録（記憶）される。
当該端末情報は、図４の例のＤＢ４０のテーブルの１行目に登録（記憶）された端末情報と一致する。
このようにして、ＤＰＦ端末１０が写真のデータの提供を要求したところ、ＤＢ４０にデータロストが発生している場合、又は、ＤＰＦ端末１０がサーバ３０に初期登録を要求する場合であっても、端末情報について、ＤＰＦ端末１０とサーバ３０側のＤＢ４０との間で整合性が保たれる。
換言すると、ＤＰＦ端末１０がＤＰＦ端末側連携処理を実行し、サーバ３０がサーバ側連携処理を実行することで、サーバ３０で発行しＤＢ４０に登録したメールアドレスを含む端末情報と、ＤＰＦ端末１０で登録されている端末情報とを連携して一致させることができる。

以上説明したように、本実施形態のサーバ３０は、端末情報受信部３２と、登録有無検出部３３と、端末情報整合部３４と、を備えている。
端末情報受信部３２は、ＤＰＦ端末１０から送信される端末固有ＩＤと、端末固有ＩＤに対応するメールアドレスとを含む端末情報の少なくとも一部、具体的には端末固有ＩＤを受信する。
登録有無検出部３３は、端末情報受信部３２により少なくとも一部取得された端末情報が、ＤＢ４０に登録されているか否かを判定する。
端末情報整合部３４は、登録有無検出部３３により端末情報が登録されていない場合、新たなメールアドレスを発行し、端末情報受信部３２に受信された端末固有ＩＤと対応付けて、新たな端末情報としてＤＢ４０に登録すると共に、新たなメールアドレスをＤＰＦ端末１０に送信する。
これにより、ＤＰＦ端末１０側でも、先に送信した端末固有ＩＤと、新たなメールアドレスとを対応付けて、新たな端末情報として登録することができる。
従って、サーバ３０側のＤＢ４０に障害が発生しデータロストが発生した場合であっても、ＤＰＦ端末１０側と、ＤＢ４０により管理されているサーバ３０側との間で、端末情報の整合性を保つことが可能になる。

以上、本発明の第１実施形態に係るサーバについて説明した。
次に、本発明の第２実施形態に係るサーバについて説明する。

［第２実施形態］
図６は、本発明の第２実施形態に係る情報処理装置としてのサーバから、ＤＰＦ端末に対して写真のデータを提供する写真提供システムの構成例を示している。
図６において、図１の第１実施形態に係る写真提供システムと同様の箇所には同一の符号が付してある。これらの箇所については、その説明は適宜省略する。

図６に示すように、第２実施形態に係るサーバ３０は、第１実施形態と同様に、サーバ側連携処理を実行すべく、通信制御部３１と、端末情報受信部３２と、登録有無検出部３３と、端末情報整合部３４と、を備えている。

ここで、第２実施形態では、ＤＰＦ端末１０のユーザは、一度登録されたメールアドレスが所望のものでない場合等には、所望のメールアドレスを設定し直すことができる。即ち、端末情報に含まれる端末固有ＩＤは固定のものであるが、端末情報に含まれるメールアドレスは、第２実施形態では、ユーザの意思に基づいても変更可能なものである。

この場合、仮に第１実施形態のサーバ３０をそのまま適用すると、ＤＢ４０においてデータロストが発生したときには、サーバ３０は、新たなメールアドレスを強制的にＤＰＦ端末１０に対して設定してしまう。
しかしながら、このことは、ユーザの観点からすると、自己が所望してわざわざ変更したメールアドレスとは全く別のメールアドレスが勝手に（知らないうちに）設定されてしまう、という問題も生ずる。

そこで、このような問題を解決すべく、第２実施形態の端末情報整合部３４においては、第１実施形態のメールアドレス発行部６０の代わりに、メールアドレス発行／更新部７０が設けられている。
また、第２実施形態に係るＤＰＦ端末１０は、ユーザが変更したいメールアドレスを入力するための入力部１６と、入力されたメールアドレスを表示してユーザに提示するための表示部１７と、がさらに設けられている。

先ず、ＤＰＦ端末１０について、ＤＰＦ端末１０がサーバ３０にメールアドレスの更新を要求する場合を例に説明する。
入力部１６は、ユーザの操作を受け付け、ユーザの操作に対応した情報、例えば、ＤＰＦ端末１０及びサーバ３０に登録可能なメールアドレスの情報を入力する。入力部１６により入力される情報の具体例については、図７を参照して後述する。

表示部１７は、入力部１６により入力された情報、例えばメールアドレスを含む画面を表示する。
ここで、「画面」とは、装置が有する表示部（第２実施形態では表示部１７）又は表示装置の表示領域全体に表示される画像をいう。
また、本実施の形態においては、入力部１６の一部は、タッチパネルとして構成されているものとする。タッチパネルは、表示部１７の画面全体の上又は下に配置され、任意の位置に指が触れる等して接触されると、つまりユーザにより所定の押下操作がなされると、接触された位置（押下操作された位置）の座標を検出する。入力部１６は、検出した座標に対応付けられた所定の情報を入力する。

図７は、ＤＰＦ端末１０及びサーバ３０に登録されているメールアドレスの変更を行う画面の一例を示している。

画面１０１には、下方から順に、ソフトウェアキーボード１０２と、ソフトウェアキーボード１０２により入力された情報を表示する入力欄１０３と、が配置されている。
ここで、本実施形態では、画面１０１のうち、少なくともソフトウェアキーボード１０２を含む領域内の上又は下に、入力部１６の一部を構成するタッチパネルが配置されているものとする。
これにより、ユーザは、ソフトウェアキーボード１０２を構成する各種ソフトウェアのキーのうち、入力を所望する文字や記号が割り当てられたソフトウェアキーを押下操作することができる。即ち、ユーザは、画面１０１のうち、当該ソフトウェアキーが表示された領域に、自己の指等を接触させることができる。
この場合、タッチパネルを含む入力部１６は、指等が接触された領域、即ち、押下操作された領域の座標を認識し、当該座標に配置されたソフトウェアキーに割り当てられた文字や記号等を入力する。
すると、画面１０１の入力欄１０３内には、入力された文字や記号等が表示される。
ここで、図７に示すように、画面１０１の入力欄１０３内に表示可能な文字や記号等は、１つではなく、複数である。従って、ユーザは、ソフトウェアキーボード１０２を１回以上押下操作することによって、１以上の文字や記号等からなるメールアドレスを入力欄１０３に表示させることができる。
そして、ユーザは、ソフトウェアキーボード１０２のうち、「決定」が割り当てられたソフトウェアキーを押下操作することで、入力欄１０３に表示されたメールアドレスを、変更後のメールアドレスとして決定することができる。
すると、タッチパネルを含む入力部１６は、押下操作された領域の座標を認識し、当該座標に配置されたソフトウェアキーに割り当てられた「決定」の指示を入力する。
端末情報登録部１５は、「決定」の指示に従って、変更後のメールアドレスを端末情報記憶部１１に仮登録する。ここで、仮登録とは、変更後のメールアドレスを端末固有ＩＤと対応付けて端末情報として端末情報記憶部１１に記憶するのではなく、端末情報とは別に端末情報記憶部１１に記憶させることをいう。即ち、変更後のメールアドレスが仮登録された状態では、端末情報に含まれるメールアドレスは、変更前のメールアドレスになっている。

端末情報送信部１２は、「決定」の指示が入力されると、通信制御部１３の制御の下、端末情報記憶部１１に記憶されている端末固有ＩＤを読み出し、当該端末固有ＩＤと、変更後のメールアドレス（入力欄１０３に表示されたメールアドレス）とを対応付けて、端末情報としてサーバ３０に送信する。
すると、サーバ３０において、変更後のメールアドレスが、端末固有ＩＤと対応付けられて、端末情報としてＤＢ４０に登録されると共に、その旨を示す情報（以下、「登録情報」と呼ぶ）がＤＰＦ端末１０に送信されてくる。

そこで、端末情報受信部１４は、通信制御部１３の制御の下、更新後のメールアドレスについての登録情報を、ネットワーク２０を介して受信し、端末情報登録部１５に供給する。

端末情報登録部１５は、端末情報受信部１４に受信された登録情報に基づいて、更新後のメールアドレスを端末情報記憶部１１に登録する。ここで、登録とは、仮登録されている変更後のメールアドレスを、端末固有ＩＤと対応付けて、端末情報として端末情報記憶部１１に記憶することをいう。即ち、変更後のメールアドレスが登録されてはじめて、端末情報に含まれるメールアドレスが、変更後のメールアドレスに更新される。

以上、ＤＰＦ端末１０がサーバ３０にメールアドレスの更新を要求する場合について説明したが、メールアドレスの更新後、ＤＰＦ端末１０が写真のデータの提供を要求する場合も、上述した一連の処理が実行される。
即ち、第２実施形態では、ＤＰＦ端末１０が写真のデータの提供を要求する場合においても、端末情報送信部１２は、通信制御部１３の制御の下、端末固有ＩＤと、登録された変更後のメールアドレスとを対応付けて、端末情報としてサーバ３０に送信する。
すると、サーバ３０において、後述するように、ＤＢ４０においてデータロストが発生していない場合には、端末固有ＩＤの登録情報がＤＰＦ端末１０に送信されてくる。これに対して、ＤＢ４０においてデータロストが発生した場合には、ＤＰＦ端末１０から送信された変更後のメールアドレスが、端末固有ＩＤと対応付けられて、端末情報としてＤＢ４０に登録されると共に、その旨を示す登録情報がＤＰＦ端末１０に送信されてくる。
ＤＰＦ端末１０は、何れの場合であっても登録情報を受信するので、変更後のメールアドレスと、端末固有ＩＤとを対応付けて再登録する。
これにより、ＤＢ４０においてデータロストが発生した場合であっても、ＤＰＦ端末１０側とサーバ３０側との間で、変更後のメールアドレスと端末固有ＩＤを含む登録情報が登録されるので、変更後のメールアドレスで整合性を保つことが可能になる。

次に、サーバ３０について説明すると、端末情報受信部３２は、変更後のメールアドレス及び端末固有ＩＤを含む端末情報がＤＰＦ端末１０からネットワーク２０を介して送信されてくると、通信制御部３１の制御の下、当該端末情報を受信し、登録有無検出部３３に供給する。

登録有無検出部３３は、端末情報受信部３２に受信された端末情報から端末固有ＩＤを認識し、当該端末固有ＩＤがＤＢ４０に登録されているか否かを検出する。
登録有無検出部３３は、その検出結果に基づいて、ＤＢ４０にデータロストが発生しているか否かを検出する。即ち、登録有無検出部３３は、端末固有ＩＤがＤＢ４０に登録されていないことを検出することによって、ＤＢ４０におけるデータロストの発生を検出する。
登録有無検出部３３は、ＤＢ４０におけるデータロストの発生を検出しなかった場合、通信制御部１３の制御の下、端末固有ＩＤがＤＢ４０に登録されている旨を示す情報、即ち端末固有ＩＤの登録情報をＤＰＦ端末１０に送信する。
これに対して、登録有無検出部３３は、ＤＢ４０におけるデータロストの発生を検出した場合、この段階ではＤＰＦ端末１０には何ら通知することなく、端末情報受信部３２に受信された端末情報を端末情報整合部３４に供給する。

端末情報整合部３４は、メールアドレス発行／更新部７０と、メールアドレス配信部６１と、を備えている。

メールアドレス発行／更新部７０は、登録有無検出部３３によりデータロストが発生していることが検出された場合には、端末情報受信部３２に受信された端末情報を、ＤＢ４０に再登録する。即ち、更新後のメールアドレスが、端末固有ＩＤと対応付けられてＤＢ４０に記憶される。

メールアドレス配信部６１は、メールアドレス発行／更新部７０によりＤＢ４０のメールアドレスが変更後のメールアドレスに更新登録された旨の登録情報を生成して、通信制御部３１の制御の下、ネットワーク２０を介してＤＰＦ端末１０に送信する。

なお、メールアドレス変更前の場合、例えば、ＤＰＦ端末１０がサーバ３０に初期登録を要求する場合等においては、端末情報受信部３２が取得した端末情報にメールアドレスが含まれていない場合がある。このようなときには、第１実施形態同様、メールアドレス発行／更新部７０は、新たなメールアドレスを発行する。そして、メールアドレス配信部６１は、通信制御部３１の制御の下、当該新たなメールアドレスをネットワーク２０を介してＤＰＦ端末１０に配信する。

以上、図６を参照して、本発明の第２実施形態に係る写真提供システムの構成例について説明した。
次に、図８を参照して、本発明の第２実施形態に係る写真提供システムで実行される処理のうち、ＤＰＦ端末１０で行われるＤＰＦ端末側連携処理と、サーバ３０で行われるサーバ側連携処理の流れの一例について説明する。

図８は、ＤＰＦ端末１０で行われるＤＰＦ端末側連携処理とサーバ３０で行われるサーバ側連携処理との関係の一例を説明するフローチャートである。

例えば、ＤＰＦ端末側連携処理とサーバ側連携処理は、ＤＰＦ端末１０がサーバ３０に初期登録を要求する場合又は写真のデータの提供を要求する場合に開始する。

ステップＳ５１において、ＤＰＦ端末１０の端末情報送信部１２は、通信制御部１３の制御の下、端末情報記憶部１１に記憶されている端末情報のうち、端末固有ＩＤとメールアドレスをネットワークを介してサーバ３０に送信する。

ステップＳ７１において、サーバ３０の端末情報受信部３２は、通信制御部３１の制御の下、ステップＳ５１の処理でＤＰＦ端末１０から送信された端末固有ＩＤとメールアドレスを、ネットワーク２０を介して受信する。

ここで、ＤＰＦ端末１０のステップＳ５１の処理の趣旨は、ＤＰＦ端末１０の端末固有ＩＤ及びメールアドレスを含む端末情報がサーバ３０において登録されている状態、即ちＡｃｔｉｖａｔｅ状態の問い合わせを行うことである。
このため、本実施形態では、ステップＳ５１とステップＳ７１の各処理で送受信される端末固有ＩＤをＨＴＴＰのリクエストヘッダに、変更後のメールアドレスを図９に示すようなＡｃｔｉｖａｔｅ状態の問い合わせのメッセージフォーマットに従って記述される。

図９は、Ａｃｔｉｖａｔｅ状態の問い合わせのメッセージフォーマットの記述例である。
図９において、♯Ｋ（Ｋは整数値）は、行番号Ｋを示している。そこで、行番号Ｋを適宜用いて、端末情報のメッセージフォーマットについて説明する。
１行目のタグ＜ｄｐｆ＞は、５行目のタグ＜／ｄｐｆ＞と組になって用いられる。即ち、タグ＜ｄｐｆ＞とタグ＜／ｄｐｆ＞の間に囲まれている情報は、ＤＰＦ端末１０の情報であることを示す。
２行目のタグ＜ｅｍａｉｌ＞は、４行目のタグ＜／ｅｍａｉｌ＞と組になって用いられる。即ち、タグ＜ｅｍａｉｌ＞とタグ＜／ｅｍａｉｌ＞との間に囲まれている情報は、変更後のメールアドレスであることを示す。
３行目のタグ＜ａｄｄｒ＞は、同３行目のタグ＜／ａｄｄｒ＞と組になって用いられる。即ち、タグ＜ａｄｄｒ＞とタグ＜／ａｄｄｒ＞との間に囲まれている情報は、更新すべき対象を示している。図３の例では、ＤＰＦ端末１０の変更後のメールアドレスは、“ｈｉｒｏｋｕｎ＠ａｒｔｆｒａｍｅ．ｊｐ”とされている。

サーバ３０は、図８のステップＳ７１の処理で、このようなＡｃｔｉｖａｔｅ状態の問い合わせを受信すると、当該問い合わせに応答すべく、次のようなステップＳ７２以降の処理を実行する。

ステップＳ７２において、サーバ３０の登録有無検出部３３は、ステップＳ７１の処理で受信された端末固有ＩＤが、ＤＢ４０に登録されているか否かを判定する。
例えば、ＤＰＦ端末１０が写真のデータの提供を要求する場合であって、ＤＢ４０にデータロストが発生していなければ、端末固有ＩＤはＤＢ４０に既に登録（記憶）されているはずである。
このような場合、ステップＳ７２においてＹＥＳであると判定されて、処理はステップＳ７３に進む。

ステップＳ７３において、サーバ３０の登録有無検出部３３は、通信制御部３１の制御の下、端末固有ＩＤがＤＢ４０に登録されていることを示す情報、即ち、端末固有ＩＤの登録情報を、ネットワーク２０を介してＤＰＦ端末１０に送信する。
これにより、サーバ側連携処理は終了する。
この場合、サーバ３０は、ＤＰＦ端末１０から送信されてきた端末固有ＩＤがＤＢ４０に登録されているという状況から、ＤＢ４０に障害は生じておらずデータロストは発生していないことを検出することができる。

一方、ＤＰＦ端末側連携処理としては、ステップＳ５２において、ＤＰＦ端末１０の端末情報受信部１４は、通信制御部１３の制御の下、サーバ３０から送信されてきた端末固有ＩＤの登録情報を受信する。

ステップＳ５３において、端末情報登録部１５は、ステップＳ５２で受信した登録情報に基づいて、更新後のメールアドレスを端末情報記憶部１１に登録する。これにより、変更後のメールアドレスが登録されてはじめて、端末情報に含まれるメールアドレスが、変更後のメールアドレスに更新される。

これに対して、ＤＰＦ端末１０が写真のデータの提供を要求したところ、ＤＢ４０にデータロストが発生している場合、又は、ＤＰＦ端末１０がサーバ３０に初期登録を要求する場合には、端末固有ＩＤはＤＢ４０に登録（記憶）されていない。
このような場合、サーバ側連帯処理では、ステップＳ７２においてＮＯであると判定されて、処理はステップＳ７４に進む。

ステップＳ７４において、サーバ３０の登録有無検出部３３は、データロストを検出する。
即ち、サーバ３０は、ＤＰＦ端末１０から端末固有ＩＤが送信されているにも関わらず、当該端末固有ＩＤがＤＢ４０に登録（記憶）されていないという状態から、サーバ３０のＤＢ４０に障害が発生しデータロストが発生した状態であることを検出できる。なお、ここでいうデータロストが発生した状態とは、データロストが発生した直後の状態のみならず、データロスト後にＤＢ４０がリストアした状態も含む。

ステップＳ７５において、サーバ３０のメールアドレス発行／更新部７０は、通信制御部３１の制御の下、ステップＳ７１で受信したメールアドレスに基づいて、対応するＤＢ４０上のメールアドレスを更新する。

ステップＳ７６において、サーバ３０のメールアドレス配信部６１は、通信制御部３１の制御の下、更新後のメールアドレスについての登録情報を、ネットワーク２０を介してＤＰＦ端末１０に送信する。

図８のステップＳ７６の処理で、更新後のメールアドレスについての登録情報がサーバ３０からＤＰＦ端末１０に送信されると、サーバ側連帯処理は終了となる。

一方、ＤＰＦ端末側連携処理では、ステップＳ５２において、ＤＰＦ端末１０の端末情報受信部１４は、通信制御部１３の制御の下、ステップＳ７６の処理でサーバ３０から送信された更新後のメールアドレスについての登録情報を受信して、登録情報を受信した情報を端末情報登録部１５に供給する。

ステップＳ５３において、端末情報登録部１５は、ステップＳ５２の処理で受信された登録情報に基づいて、更新後のメールアドレスを端末情報記憶部１１に登録する。この登録により仮登録されていた変更後のメールアドレスを、端末固有ＩＤと対応付けて、端末情報として端末情報記憶部１１に記憶（登録）する。即ち、この変更後のメールアドレスの登録により、端末情報に含まれるメールアドレスが、変更後のメールアドレスに更新される。
これにより、ＤＰＦ端末側連携処理は終了となる。

以上説明したように、本実施形態のサーバ３０は、端末情報受信部３２と、登録有無検出部３３と、端末情報整合部３４と、を備え、端末情報整合部３４は、メールアドレス発行／更新部７０を備えている。
端末情報受信部３２は、ＤＰＦ端末１０から送信される端末固有ＩＤと、端末固有ＩＤに対応するメールアドレスと、を含む端末情報を受信する。
登録有無検出部３３は、端末情報受信部３２に受信された端末情報が、ＤＢ４０に登録されているか否かを判定する。
そして、メールアドレス発行／更新部７０は、登録有無検出部３３により端末情報が登録されていない場合、端末情報受信部３２に受信されたメールアドレスと端末固有ＩＤと対応付けて、新たな端末情報としてＤＢ４０に登録すると共に、登録情報をＤＰＦ端末１０に送信する。
これにより、ＤＰＦ端末１０側でも、先に送信した端末固有ＩＤとメールアドレスとを対応付けて、新たな端末情報として登録することができる。
従って、サーバ３０側のＤＢ４０に障害が発生しデータロストが発生した場合であっても、ＤＰＦ端末１０側と、ＤＢ４０により管理されているサーバ３０側との間で、端末情報の整合性を保つことが可能になる。
この場合、端末情報に含まれるメールアドレスは、ＤＰＦ端末１０から送信されたもの、例えば、ユーザの意図に基づいて変更された後のメールアドレスである。これにより、ユーザの観点からすると、自己が所望してわざわざ変更したメールアドレスとは全く別のメールアドレスが勝手に（知らないうちに）設定されてしまう、ということを防止することが可能になる。

以上、本発明の第２実施形態に係るサーバについて説明した。
次に、本発明の第３実施形態に係るサーバについて説明する。

［第３実施形態］
本発明の第３実施形態に係る情報処理装置としてのサーバから、ＤＰＦ端末に対して写真のデータを提供する写真提供システムは、図６の第２実施形態に係る写真提供システムと基本的に同様の構成を有している。
そこで、以下、第３実施形態に係る写真提供システムについては、図６の符号を用いて説明する。

ここで、第２実施形態では、ＤＢ４０のデータロストは、端末固有ＩＤ及びメールアドレスの両方が消失してしまうことを前提とした。
しかしながら、例えば、端末固有ＩＤとメールアドレスとを含む端末情報が登録されたＤＢ４０がバックアップされた状態で、ＤＰＦ端末１０から送信された変更後のメールアドレスがＤＢ４０に上書き登録（更新）された後に、ＤＢ４０のデータロストが発生する場合がある。このような場合には、ＤＢ４０の記憶内容は、バックアップ前の状態にリストアされる。すると、端末情報について、ＤＰＦ端末１０側と、ＤＢ４０により管理されるサーバ３０側との間では、端末固有ＩＤは一致するものの、メールアドレスが異なってしまうという状態が生じる。このような状態を生じさせるデータロストは、メールアドレスのみのデータロストであると把握することができる。
このようなメールアドレスのみのデータロストが発生しても、第２実施形態では、端末固有ＩＤが一致しているため、データロストが発生していることを検出できない。
そこで、第３実施形態に係るサーバ３０は、端末固有ＩＤとメールアドレスの両方のデータロストと、メールアドレスのみのデータロストとをそれぞれ検出できるようにしている。

具体的には、登録有無検出部３３は、端末情報受信部３２に受信された端末情報から端末固有ＩＤを認識し、当該端末固有ＩＤがＤＢ４０に登録されているか否かを検出する。登録有無検出部３３は、その検出結果に基づき、データロストの発生を検出する。

より具体的には、登録有無検出部３３は、以前Ａｃｔｉｖａｔｅ状態だったが、端末固有ＩＤがＤＢ４０に登録されていないと判定した場合には、端末固有ＩＤがデータロストにより消失したと判定する。

これに対して、登録有無検出部３３は、端末情報受信部３２に受信された端末固有ＩＤはＤＢ４０に登録されているが、端末情報受信部３２に受信されたメールアドレス（主に、ユーザによる変更後のメールアドレス）と、ＤＢ４０に登録されているメールアドレスと異なる場合には、変更後のメールアドレスのみがデータロストにより消失したと判定する。

また、登録有無検出部３３は、データロストを検出した場合、その判定結果、即ち、端末固有ＩＤとメールアドレスの両方のデータロストを検出したのか、それとも、メールアドレスのみのデータロストを検出したのかを、端末情報整合部３４に通知する。

端末情報整合部３４は、メールアドレス発行／更新部７０と、メールアドレス配信部６１と、を備えている。

メールアドレス発行／更新部７０は、端末固有ＩＤとメールアドレスの両方のデータロストを検出したことが登録有無検出部３３から通知された場合、Ａｃｔｉｖａｔｅ状態を再確立するために、端末情報受信部３２に端末情報として受信された端末固有ＩＤとメールアドレス（主に、ユーザによる変更後のメールアドレス）とを、新たな端末情報としてＤＢ４０に登録する。
そして、メールアドレス配信部６１は、通信制御部３１の制御の下、第２実施形態と同様に、メールアドレスについての登録情報をネットワーク２０を介してＤＰＦ端末１０に送信する。

これに対して、メールアドレス発行／更新部７０は、メールアドレスのみのデータロストを検出したことが登録有無検出部３３から通知された場合、ＤＢ４０上のメールアドレスを、端末情報受信部３２に受信されたメールアドレス（主に、ユーザによる変更後のメールアドレス）に更新する。
そして、メールアドレス配信部６１は、通信制御部３１の制御の下、端末固有ＩＤがＤＢ４０に登録されていることを示す情報、即ち端末固有ＩＤの登録情報をネットワーク２０を介してＤＰＦ端末１０に送信する。

以上、図６を参照して、本発明の第３実施形態に係る写真提供システムの構成例について説明した。
次に、図１０を参照して、本発明の第３実施形態に係る写真提供システムで実行される処理のうち、ＤＰＦ端末１０で行われるＤＰＦ端末側連携処理と、サーバ３０で行われるサーバ側連携処理の流れの一例について説明する。

図１０は、ＤＰＦ端末１０で行われるＤＰＦ端末側連携処理とサーバ３０で行われるサーバ側連携処理との関係の一例を説明するフローチャートである。

例えば、ＤＰＦ端末側連携処理とサーバ側連携処理は、ＤＰＦ端末１０がサーバ３０に初期登録を要求する場合又は写真のデータの提供を要求する場合に開始する。

ステップＳ９１において、ＤＰＦ端末１０の端末情報送信部１２は、通信制御部１３の制御の下、端末情報記憶部１１に記憶されている端末情報のうち、端末固有ＩＤとメールアドレスをネットワークを介してサーバ３０に送信する。

ステップＳ１０１において、サーバ３０の端末情報受信部３２は、通信制御部３１の制御の下、ステップＳ９１の処理でＤＰＦ端末１０から送信された端末固有ＩＤとメールアドレスを、ネットワーク２０を介して受信する。

ここで、ＤＰＦ端末１０のステップＳ９１の処理の趣旨は、ＤＰＦ端末１０の端末固有ＩＤ及びメールアドレスを含む端末情報がサーバ３０において登録されている状態、即ちＡｃｔｉｖａｔｅ状態の問い合わせを行うことである。
このため、本実施形態では、ステップＳ９１とステップＳ１０１の各処理で送受信される端末固有ＩＤをＨＴＴＰのリクエストヘッダに、変更後のメールアドレスを図９に示すようなＡｃｔｉｖａｔｅ状態の問い合わせのメッセージフォーマットに従って記述される。メッセージフォーマットの記述例については、第２実施形態と同様であるため説明を省略する。

サーバ３０は、図１０のステップＳ１０１の処理で、このようなＡｃｔｉｖａｔｅ状態の問い合わせを受信すると、当該問い合わせに応答すべく、次のようなステップＳ１０２以降の処理を実行する。

ステップＳ１０２において、サーバ３０の登録有無検出部３３は、ステップＳ１０１の処理で受信された端末固有ＩＤが、ＤＢ４０に登録されているか否かを判定する。
例えば、ＤＰＦ端末１０が写真のデータの提供を要求する場合であって、ＤＢ４０に端末固有ＩＤに関しデータロストが発生していなければ、少なくとも端末固有ＩＤはＤＢ４０に既に登録（記憶）されているはずである。
このような場合、ステップＳ１０２においてＹＥＳであると判定されて、処理はステップＳ１０３に進む。

ステップＳ１０３において、サーバ３０の登録有無検出部３３は、ステップＳ１０１の処理で受信されたメールアドレスが、ＤＢ４０に登録されているか否かを判定する。
例えば、ＤＰＦ端末１０が写真のデータの提供を要求する場合であって、ＤＢ４０にメールアドレスに関しデータロストが発生していなければ、メールアドレスはＤＢ４０に既に登録（記憶）されているはずである。
このような場合、ステップＳ１０３においてＹＥＳであると判定されて、処理はステップＳ１０４に進む。

ステップＳ１０４において、サーバ３０の登録有無検出部３３は、通信制御部３１の制御の下、端末固有ＩＤ及びメールアドレスがＤＢ４０に登録されていることを示す情報、即ち、端末固有ＩＤ及びメールアドレスの登録情報を、ネットワーク２０を介してＤＰＦ端末１０に送信する。
これにより、サーバ側連携処理は終了する。
この場合、サーバ３０は、ＤＰＦ端末１０から送信されてきた端末固有ＩＤ及びメールアドレスがＤＢ４０に登録されているという状況から、ＤＢ４０に障害は生じておらずデータロストは発生していないことを検出することができる。

一方、ＤＰＦ端末側連携処理としては、ステップＳ９２において、ＤＰＦ端末１０の端末情報受信部１４は、通信制御部１３の制御の下、サーバ３０から送信されてきた端末固有ＩＤ及びメールアドレスの登録情報を受信する。

ステップＳ９３において、端末情報登録部１５は、ステップＳ９２で受信した登録情報に基づいて、更新後のメールアドレスを端末情報記憶部１１に登録する。これにより、変更後のメールアドレスが登録されてはじめて、端末情報に含まれるメールアドレスが、変更後のメールアドレスに更新される。

これに対して、ＤＰＦ端末１０が写真のデータの提供を要求したところ、端末固有ＩＤはＤＢ４０に登録されているがメールアドレスがＤＢ４０に登録されていないと判定された場合には、サーバ側連帯処理では、ステップＳ１０３においてＮＯであると判定されて、処理はステップＳ１０５に進む。

ステップＳ１０５において、サーバ３０の登録有無検出部３３は、データロストを検出する。
即ち、サーバ３０は、ＤＰＦ端末１０から端末固有ＩＤが送信されているにも関わらず、メールアドレスがＤＢ４０に登録（記憶）されていないという状態から、サーバ３０のＤＢ４０に障害が発生しデータロストが発生した状態であることを検出できる。なお、ここでいうデータロストが発生した状態とは、データロストが発生した直後の状態のみならず、データロスト後にＤＢ４０がリストアした状態も含む。

ステップＳ１０６において、サーバ３０のメールアドレス発行／更新部７０は、通信制御部３１の制御の下、ステップＳ１０１で受信したメールアドレスに基づいて、対応するＤＢ４０上のメールアドレスを更新し、ステップＳ１０９の処理に進む。

これに対して、ＤＰＦ端末１０が写真のデータの提供を要求したところ、端末固有ＩＤがＤＢ４０に登録されていないと判定された場合には、サーバ側連帯処理では、ステップＳ１０２においてＮＯであると判定されて、処理はステップＳ１０７に進む。

ステップＳ１０７において、サーバ３０の登録有無検出部３３は、データロストを検出する。
即ち、サーバ３０は、ＤＰＦ端末１０から端末固有ＩＤが送信されているにも関わらず、端末固有ＩＤがＤＢ４０に登録（記憶）されていないという状態から、サーバ３０のＤＢ４０に障害が発生しデータロストが発生した状態であることを検出できる。なお、ここでいうデータロストが発生した状態とは、データロストが発生した直後の状態のみならず、データロスト後にＤＢ４０がリストアした状態も含む。

ステップＳ１０８において、サーバ３０のメールアドレス発行／更新部７０は、通信制御部３１の制御の下、ステップＳ１０１で受信した端末固有ＩＤ及びメールアドレスに基づいて、端末情報をＤＢ４０に登録し、ステップＳ１０９の処理に進む。

ステップＳ１０９において、サーバ３０のメールアドレス配信部６１は、通信制御部３１の制御の下、更新後のメールアドレスについての登録情報を、ネットワーク２０を介してＤＰＦ端末１０に送信する。

図１０のステップＳ１０９の処理で、更新後のメールアドレスについての登録情報がサーバ３０からＤＰＦ端末１０に送信されると、サーバ側連帯処理は終了となる。

一方、ＤＰＦ端末側連携処理では、ステップＳ９２において、ＤＰＦ端末１０の端末情報受信部１４は、通信制御部１３の制御の下、ステップＳ１０９の処理でサーバ３０から送信された更新後のメールアドレスについての登録情報を受信して、登録情報を受信した情報を端末情報登録部１５に供給する。

ステップＳ９３において、端末情報登録部１５は、ステップＳ９２の処理で受信された登録情報に基づいて、更新後のメールアドレスを端末情報記憶部１１に登録する。この登録により仮登録されていた変更後のメールアドレスを、端末固有ＩＤと対応付けて、端末情報として端末情報記憶部１１に記憶（登録）する。即ち、この変更後のメールアドレスの登録により、端末情報に含まれるメールアドレスが、変更後のメールアドレスに更新される。
これにより、ＤＰＦ端末側連携処理は終了となる。

以上説明したように、本実施形態のサーバ３０は、端末情報受信部３２と、登録有無検出部３３と、端末情報整合部３４と、を備えている。
端末情報受信部３２は、ＤＰＦ端末１０から送信される端末固有ＩＤと、端末固有ＩＤに対応するメールアドレスとを含む端末情報を受信する。
登録有無検出部３３は、端末情報受信部３２により受信された端末情報のうち、端末固有ＩＤとメールアドレスとのそれぞれが、ＤＢ４０に登録されているか否かを判定する。
端末情報整合部３４は、登録有無検出部３３により端末固有ＩＤが登録されていないと判定された場合、端末情報受信部３２に受信された端末固有ＩＤ及びメールアドレスを対応付けて、新たな端末情報としてＤＢ４０に登録する。そして、端末情報整合部３４は、メールアドレスについての登録情報をＤＰＦ端末１０に送信する。
これに対して、端末情報整合部３４は、登録有無検出部３３により端末固有ＩＤは登録されているが、メールアドレスは登録されていない（別のメールアドレスが登録されている場合含む）と判定された場合、ＤＢ４０上のメールアドレスを、端末情報受信部３２に受信されたメールアドレス（主に、ユーザによる変更後のメールアドレス）に更新する。
そして、端末情報整合部３４は、通信制御部３１の制御の下、端末固有ＩＤがＤＢ４０に登録されていることを示す情報、即ち端末固有ＩＤの登録情報をネットワーク２０を介してＤＰＦ端末１０に送信する。
ＤＰＦ端末１０は、何れの場合であっても登録情報を受信するので、変更後のメールアドレスと、端末固有ＩＤとを対応付けて再登録する。
これにより、ＤＢ４０においてデータロストが発生した場合であっても、ＤＰＦ端末１０側とサーバ３０側との間で、変更後のメールアドレスと端末固有ＩＤを含む登録情報が登録されるので、変更後のメールアドレスで整合性を保つことが可能になる。
特に、端末固有ＩＤとメールアドレスの両方のデータロストが発生した場合は勿論のこと、メールアドレスのみのデータロストを検出した場合にも、整合性を保つことが可能になる。

以上、本発明の第３実施形態に係るサーバについて説明した。
次に、本発明の第４実施形態に係るサーバについて説明する。

［第４実施形態］
図１１は、本発明の第４実施形態に係る情報処理装置としてのサーバから、ＤＰＦ端末に対して写真のデータを提供する写真提供システムの構成例を示している。
図１１において、図６の第２実施形態に係る写真提供システムと同様の箇所には同一の符号が付してある。これらの箇所については、その説明は適宜省略する。

図１１に示すように、第４実施形態に係る写真提供システムでは、第２実施形態の図６の構成に対してさらに、バックアップ部９０が設けられている。
なお、第１乃至第３実施形態では、バックアップ部９０が設けられていないというわけではなく、必要に応じて設けられているが、サーバ３０で行われるサーバ側連携処理とは独立しているため、図示が省略されているだけである。即ち、詳細については後述するが、第４実施形態では、バックアップ部９０は、サーバ３０で行われるサーバ側連携処理に関連しているため、図１１に図示されている。

図１１に示すように、第４実施形態に係るサーバ３０は、第２実施形態と同様に、サーバ側連携処理を実行すべく、通信制御部３１と、端末情報受信部３２と、登録有無検出部３３と、端末情報整合部３４と、を備えている。

ここで、第３実施形態の冒頭の説明で上述したように、メールアドレスのみのデータロストが発生する場合がある。即ち、ＤＰＦ端末１０側で登録（記憶）されているメールアドレス（変更後のメールアドレス）と、データロスト後にバックアップ部９０によりＤＢ４０にバックアップされたメールアドレス（変更前のメールアドレス）と、で不整合が発生する場合がある。
そこで、第４実施形態のサーバ３０は、ＤＰＦ端末１０から送信されたメールアドレスを含む端末情報を、ＤＢ４０にすぐに登録せずに仮に記憶しておく（以下、このような仮の記憶を「Ｐｒｅｐａｒｅ」と呼ぶ）。
そして、サーバ３０は、バックアップ部９０によりＤＢ４０のバックアップが実行された後に、ＰｒｅｐａｒｅされていたメールアドレスをＤＢ４０に登録し、その旨をＤＰＦ端末１０に通知する。

具体的には、第４実施形態に係るＤＢ４０は、一次記憶部４１と、二次記憶部４２と、を備えている。
一次記憶部４１は、端末情報受信部３２に受信された端末情報を一次的に記憶する領域、即ちＰｒｅｐａｒｅする領域であり、二次記憶部４２は、一次記憶部４１に記憶された端末情報を登録（記憶）する領域である。

バックアップ部９０は、ＤＢ４０に記憶されている端末情報を所定のタイミング毎にバックアップする。

次に、第４実施形態に係るサーバ３０について説明すると、端末情報整合部３４は、端末情報登録部８０と、登録情報通知部８１と、を備えている。

端末情報登録部８０は、登録有無検出部３３によりデータロストが発生したことが検出された場合には、端末情報受信部３２に受信された端末情報に含まれるメールアドレス（変更後のメールアドレス）を、ＤＢ４０の一次記憶部４１にＰｒｅｐａｒｅする。
ここで、バックアップ部９０のバックアップがされる前に、データロストが発生した場合、ＤＰＦ端末１０で登録されているメールアドレス（変更後のメールアドレス）とサーバ３０にバックアップされているメールアドレス（変更前のメールアドレス）とで不整合が起こってしまう場合がある。
そこで、端末情報登録部８０は、バックアップ部９０によりＤＢ４０の一次記憶部４１のバックアップが行われたタイミングで、一次記憶部４１にＰｒｅｐａｒｅされているメールアドレス（変更後のメールアドレス）を二次記憶部４２に登録（記憶）する。
これにより、ＤＰＦ端末１０とバックアップ部９０とに記憶される端末情報の整合性を保つことができる。

登録情報通知部８１は、一次記憶部４１にＰｒｅｐａｒｅされていた端末情報が二次記憶部４２に登録された場合、端末固有ＩＤの登録情報をＤＰＦ端末１０に送信する。
これにより、ＤＰＦ端末１０側でも、先に送信した端末固有ＩＤとメールアドレス（変更後のメールアドレス）とを対応付けて、新たな端末情報として登録することができる。
従って、サーバ３０側のＤＢ４０に障害が発生しデータロストが発生した場合であっても、ＤＰＦ端末１０側と、ＤＢ４０により管理されているサーバ３０側との間で、端末情報の整合性を保つことが可能になる。
特に、端末固有ＩＤとメールアドレスの両方のデータロストが発生した場合は勿論のこと、メールアドレスのみのデータロストを検出した場合にも、整合性を保つことが可能になる。

以上、図１１を参照して、本発明の第４実施形態に係る写真提供システムの構成例について説明した。
次に、図１２乃至図１４を参照して、本発明の第４実施形態に係る写真提供システムで実行される処理のうち、ＤＰＦ端末１０で行われるＤＰＦ端末側連携処理と、サーバ３０で行われるサーバ側連携処理の流れの一例について説明する。

図１２は、ＤＰＦ端末１０で行われるＤＰＦ端末側連携処理とサーバ３０で行われるサーバ側連携処理との関係の一例を説明するフローチャートである。

例えば、ＤＰＦ端末側連携処理とサーバ側連携処理は、ＤＰＦ端末１０がサーバ３０に初期登録を要求する場合又は写真のデータの提供を要求する場合に開始する。

ステップＳ１２１において、ＤＰＦ端末１０の端末情報送信部１２は、通信制御部１３の制御の下、端末情報記憶部１１に記憶されている端末情報のうち、端末固有ＩＤとメールアドレスをネットワークを介してサーバ３０に送信する。

ステップＳ１４１において、サーバ３０の端末情報受信部３２は、通信制御部３１の制御の下、ステップＳ５１の処理でＤＰＦ端末１０から送信された端末固有ＩＤとメールアドレスを、ネットワーク２０を介して受信する。

ここで、ＤＰＦ端末１０のステップＳ１２１の処理の趣旨は、ＤＰＦ端末１０の端末固有ＩＤ及びメールアドレスを含む端末情報がサーバ３０において登録されている状態、即ちＡｃｔｉｖａｔｅ状態の問い合わせを行うことである。
このため、本実施形態では、ステップＳ１２１とステップＳ１４１の各処理で送受信される端末固有ＩＤをＨＴＴＰのリクエストヘッダに、変更後のメールアドレスを図９に示すようなＡｃｔｉｖａｔｅ状態の問い合わせのメッセージフォーマットに従って記述される。メッセージフォーマットの記述例については、第２実施形態と同様であるため説明を省略する。

サーバ３０は、図１２のステップＳ１４１の処理で、このようなＡｃｔｉｖａｔｅ状態の問い合わせを受信すると、当該問い合わせに応答すべく、次のようなステップＳ１４２以降の処理を実行する。

ステップＳ１４２において、サーバ３０の登録有無検出部３３は、ステップＳ１４１の処理で受信された端末固有ＩＤが、ＤＢ４０に登録されているか否かを判定する。
例えば、ＤＰＦ端末１０が写真のデータの提供を要求する場合であって、ＤＢ４０に端末固有ＩＤに関しデータロストが発生していなければ、端末固有ＩＤはＤＢ４０に既に登録（記憶）されているはずである。
このような場合、ステップＳ１４２においてＹＥＳであると判定されて、処理はステップＳ１４３に進む。

ステップＳ１４３において、サーバ３０の登録有無検出部３３は、通信制御部３１の制御の下、端末固有ＩＤがＤＢ４０に登録されていることを示す情報、即ち、端末固有ＩＤの登録情報を、ネットワーク２０を介してＤＰＦ端末１０に送信する。
これにより、サーバ側連携処理は終了する。
この場合、サーバ３０は、ＤＰＦ端末１０から送信されてきた端末固有ＩＤがＤＢ４０に登録されているという状況から、ＤＢ４０に障害は生じておらずデータロストは発生していないことを検出することができる。

一方、ＤＰＦ端末側連携処理としては、ステップＳ１２６において、ＤＰＦ端末１０の端末情報受信部１４は、通信制御部１３の制御の下、サーバ３０から送信されてきた端末固有ＩＤの登録情報を受信する。

ステップＳ１２７において、端末情報登録部１５は、ステップＳ１２６で受信した登録情報に基づいて、更新後のメールアドレスを端末情報記憶部１１に登録する。これにより、変更後のメールアドレスが登録されてはじめて、端末情報に含まれるメールアドレスが、変更後のメールアドレスに更新される。

これに対して、ＤＰＦ端末１０が写真のデータの提供を要求したところ、端末固有ＩＤがＤＢ４０に登録されていないと判定された場合には、サーバ側連帯処理では、ステップＳ１４２においてＮＯであると判定されて、処理はステップＳ１４４に進む。

ステップＳ１４４において、サーバ３０の登録有無検出部３３は、データロストを検出する。
即ち、サーバ３０は、ＤＰＦ端末１０から端末固有ＩＤが送信されているにも関わらず、端末固有ＩＤがＤＢ４０に登録（記憶）されていないという状態から、サーバ３０のＤＢ４０に障害が発生しデータロストが発生した状態であることを検出できる。なお、ここでいうデータロストが発生した状態とは、データロストが発生した直後の状態のみならず、データロスト後にＤＢ４０がリストアした状態も含む。

ステップＳ１４５において、端末情報登録部８０は、一次記憶処理を実行する。一次記憶処理とは、送信されたメールアドレスを一次記憶部４１の一領域に相当する一次テーブルに登録すると共に、一次テーブルに記憶された端末情報と、二次記憶部４２の一領域に相当する二次テーブルに記憶された端末情報とに同じメールアドレスが存在するか否かを検索し、同じメールアドレスが存在する場合には、端末情報の一意性制約を満足することができないとして、エラーのレスポンスを送信し、同じメールアドレスが存在しない場合には、正常のレスンポンスを送信する一連の処理をいう。

ステップＳ１２２において、ＤＰＦ端末１０の端末情報受信部１４は、通信制御部３１の制御の下、ステップＳ１４５の処理でサーバ３０から送信されたレスポンスを、ネットワーク２０を介して受信する。

ステップＳ１２３において、端末情報登録部１５は、ステップＳ１２２で受信したレスポンスは正常であるか否かを判定する。
ここで、エラーのレスポンスは、後述する一次記憶処理において、一次テーブルと二次テーブルとで同じメールアドレスがあった場合に送信される情報である。
即ち、エラーのレスポンスを受信した場合には、一次記憶部４１に記憶されている端末情報に基づいて二次記憶部４２において端末情報の登録を行うまでの間にデータロストが発生したことを把握することができる。この場合であっても、一次記憶部４１と二次記憶部４２との両方の状態において一意性制約を満足させるため、データロストが発生した場合であっても、他のユーザとメールアドレスが重複するという問題を回避することができる。
また、正常のレスポンスは、後述する一次記憶処理において、一次テーブルと二次テーブルとで同じメールアドレスがなかった場合に送信される情報である。即ち、正常のレスポンスを受信した場合には、一次記憶部４１に記憶されている端末情報に基づいて二次記憶部４２において端末情報の登録を行うまでの間にデータロストが発生していないことを把握することができる。

端末情報登録部１５により、受信したレスポンスは正常ではないと判定した場合、ステップＳ１２３においてＮＯであると判定されて、ステップＳ１２４に進む。

ステップＳ１２４において、表示部１７は、エラー表示を行う。具体的には、図示しないが、ディスプレイにおいて、データロストが発生したことを通知する。ユーザがこのエラー表示を見ることにより、データロストをいち早く認識することができる。また、このエラーレスポンスを受信することにより、別のメールアドレスを設定して再びメールアドレスの登録処理を行ってもよい。ステップＳ１２４の処理が終了すると、ＤＰＦ端末側連携処理が終了となる。

これに対して、端末情報登録部１５により、受信したレスポンスは正常であると判定した場合、ステップＳ１２３においてＹＥＳであると判定されて、ステップＳ１２５に進む。

ステップＳ１２５において、端末情報送信部１２は、所定のタイミング毎にメールアドレスの変更の問い合わせをサーバ３０に送信する。この処理では、ＤＰＦ端末１０は、サーバ３０に対し一定間隔でポーリング（Ｐｏｌｌｉｎｇ）を行い、サーバ３０上で端末情報が二次記憶部４２に記憶されたか否かを検出する。

ステップＳ１４６において、サーバ３０の端末情報登録部８０は、ＤＢ４０のバックアップが行われたか否かを判定する。

端末情報登録部８０により、ＤＢ４０のバックアップが行われたと判定された場合、ステップＳ１４６においてＹＥＳであると判定されて、ステップＳ１４７に進む。

これに対して、サーバ３０の端末情報登録部８０により、ＤＢ４０のバックアップが行われたと判定されなかった場合には、ＤＢ４０のバックアップが行われるまで、ステップＳ１４６の判定が繰り返される。

ステップＳ１４７において、サーバ３０の端末情報登録部８０は、後述の二次記憶処理を実行する。二次記憶処理とは、一次テーブルに記憶されている端末情報のデータを、一次テーブルの内容に基づき二次テーブルに書き換える一連の処理をいう。

ステップＳ１４８において、サーバ３０の端末情報受信部３２は、通信制御部３１の制御の下、ステップＳ１２５の処理でＤＰＦ端末１０から送信されたメールアドレスの変更の問い合わせを、ネットワーク２０を介して受信する。

ステップＳ１４９において、サーバ３０の登録情報通知部８１は、ステップＳ１４８にでメールアドレスの変更の問い合わせを受信したことに基づいて端末固有ＩＤの登録情報をＤＰＦ端末１０に送信する。
この処理では、ＤＢ４０に登録したメールアドレスを含む端末情報と、ＤＰＦ端末１０の端末情報記憶部１１に記憶されている端末情報とを連携して一致させる。ステップＳ１４９の処理が終了すると、サーバ側連携処理が終了となる。

ステップＳ１２６において、端末情報受信部１４は、通信制御部１３を介して、サーバ３０から送信された端末固有ＩＤの登録情報を受信する。

ステップＳ１２７において、端末情報登録部１５は、ステップＳ１２６で、サーバ３０から送信された端末固有ＩＤの登録情報を受信したことに伴い、端末情報記憶部１１に記憶されたメールアドレスの登録を行う。

次に、このようなサーバ側連携処理のうち、ステップＳ１４５の一次記憶処理について説明する。
図１３は、一次記憶処理の詳細な流れの一例を説明するフローチャートである。
上述したように、ステップＳ１４４のデータロストの検出が終了すると、ステップＳ１４５の一次記憶処理が開始し、次のようなステップＳ１６１乃至ステップＳ１６６の一連の処理が実行される。

ステップＳ１６１において、端末情報登録部８０は、一次テーブルと二次テーブルとから同じアドレスを検索する。

ステップＳ１６２において、端末情報登録部８０は、ステップＳ１６１の検索の結果同じメールアドレスがあったか否かを判定する。

端末情報登録部８０により、同じメールアドレスがあったと判定された場合、ステップＳ１６２においてＹＥＳであると判定されて、ステップＳ１６３に進む。

ステップＳ１６３において、端末情報登録部８０は、エラーのレスポンスをセットする。

これに対して、端末情報登録部８０により、同じメールアドレスがなかったと判定された場合、ステップＳ１６２においてＮＯであると判定されて、ステップＳ１６４に進む。

ステップＳ１６４において、端末情報登録部８０は、ステップＳ１４１において受信したメールアドレスを一次テーブルに登録する。

ステップＳ１６５において、端末情報登録部８０は、正常のレスポンスをセットする。

ステップＳ１６６において、端末情報登録部８０は、エラーのレスンポンス又は正常のレスポンスの何れかをＤＰＦ端末１０に送信する。ステップＳ１６６の処理が終了すると、一次記憶処理が終了となる。

次に、このようなサーバ側連携処理のうち、ステップＳ１４５の二次記憶処理について説明する。
図１４は、二次記憶処理の詳細な流れの一例を説明するフローチャートである。
上述したように、ステップＳ１４６のＤＢ４０のバックアップが行われたと判定されると、ステップＳ１４７の二次記憶処理が開始し、次のようなステップＳ１８１乃至ステップＳ１８２の一連の処理が実行される。

ステップＳ１８１において、端末情報登録部８０は、一次テーブルに端末情報のデータがあるか否かを判定する。

端末情報登録部８０により、一次テーブルに端末情報のデータがないと判定された場合、ステップＳ１８１においてＮＯであると判定されて、この処理を終了する。

端末情報登録部８０により、一次テーブルに端末情報のデータがあると判定された場合、ステップＳ１８１においてＹＥＳであると判定されて、ステップＳ１８２に進む。

ステップＳ１８２において、端末情報登録部８０は、一次テーブルの端末情報の内容に基づき、二次テーブルを書き換えると共に、一次テーブルの内容を削除する。ステップＳ１８２の処理が終了すると、二次記憶処理が終了となる。

以上説明したように、本実施形態のサーバ３０は、端末情報受信部３２と、登録有無検出部３３と、端末情報整合部３４と、を備えている。
端末情報受信部３２は、ＤＰＦ端末１０から送信される端末固有ＩＤと、端末固有ＩＤに対応するメールアドレスとを含む端末情報を受信する。
登録有無検出部３３は、端末情報受信部３２により受信された端末情報のうち、端末固有ＩＤとメールアドレスとのそれぞれが、ＤＢ４０に登録されているか否かを判定する。
端末情報整合部３４は、登録有無検出部３３により端末固有ＩＤが登録されていないと判定された場合、端末情報受信部３２に受信されたメールアドレスを、ＤＢ４０の一次記憶部４１にＰｒｅｐａｒｅする。
その後、バックアップ部９０によりＤＢ４０の一次記憶部４１の内容がバックアップされた後、端末情報整合部３４は、ＤＢ４０の一次記憶部４１にＰｅｒｐａｒｅされたメールアドレス（変更後のメールアドレス）を、二次記憶部４２に記憶された端末情報のメールアドレスとして登録する。そして、端末情報整合部３４は、メールアドレスについての登録情報をＤＰＦ端末１０に送信する。
これに対して、端末情報整合部３４は、登録有無検出部３３により端末固有ＩＤは登録されているが、メールアドレスは登録されていない（別のメールアドレスが登録されている場合含む）と判定された場合、ＤＢ４０上のメールアドレスを、端末情報受信部３２に受信されたメールアドレス（主に、ユーザによる変更後のメールアドレス）に更新する。
そして、端末情報整合部３４は、通信制御部３１の制御の下、端末固有ＩＤの登録情報をネットワーク２０を介してＤＰＦ端末１０に送信する。
これにより、ＤＰＦ端末１０側でも、先に送信した端末固有ＩＤとメールアドレス（変更後のメールアドレス）とを対応付けて、新たな端末情報として登録することができる。
従って、サーバ３０側のＤＢ４０に障害が発生しデータロストが発生した場合であっても、ＤＰＦ端末１０側と、ＤＢ４０により管理されているサーバ３０側との間で、端末情報の整合性を保つことが可能になる。
特に、端末固有ＩＤとメールアドレスの両方のデータロストが発生した場合は勿論のこと、メールアドレスのみのデータロストを検出した場合にも、整合性を保つことが可能になる。
また、バックアップ部９０によりＤＢ４０のバックアップを行った場合であっても、バックアップ部９０にバックアップされている端末情報の内容と、ＤＰＦ端末１０に登録されている端末情報の内容との間で整合性を保つことができる。

また例えば、上述した実施形態では、本発明が適用されるＤＰＦ端末１０は、デジタルフォトフレーム端末として構成される例として説明した。
しかしながら、本発明は、特にこれに限定されず、表示機能を有する電子機器一般に適用することができ、例えば、本発明は、パーソナルコンピュータ、携帯型ナビゲーション装置、ポータブルゲーム機等に幅広く適用可能である。

上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。

図１５は、上述した一連の処理をソフトウェアにより実行させる場合の、サーバ３０のハードウェア構成を示すブロック図である。

サーバ３０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３と、バス２０４と、入出力インターフェース２０５と、入力部２０６と、出力部２０７と、記憶部２０８と、通信部２０９と、ドライブ２１０と、を備えている。

ＣＰＵ２０１は、ＲＯＭ２０２に記録されているプログラムに従って各種の処理を実行する。又は、ＣＰＵ２０１は、記憶部２０８からＲＡＭ２０３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ２０３にはまた、ＣＰＵ２０１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

例えば本実施形態では、通信制御部３１乃至端末情報整合部３４の各機能を実現するプログラムが、ＲＯＭ２０２や記憶部２０８に記憶されている。従って、ＣＰＵ２０１が、これらのプログラムに従った処理を実行することで、通信制御部３１乃至端末情報整合部３４の各機能を実現することができる。

ＣＰＵ２０１、ＲＯＭ２０２、及びＲＡＭ２０３は、バス２０４を介して相互に接続されている。このバス２０４にはまた、入出力インターフェース２０５も接続されている。入出力インターフェース２０５には、入力部２０６、出力部２０７、記憶部２０８、及び通信部２０９が接続されている。

入力部２０６は、各種釦等の操作部で構成され、ユーザの指示操作を受け付ける他、各種情報を入力する。
出力部２０７は、各種情報を出力する。例えば、出力部２０７には、上述した表示部２２１が設けられており、画像情報が出力される。入力部２０６により入力されたメールアドレスの内容が表示部２２１に表示される。
記憶部２０８は、ハードディスクやＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。例えば記憶部２０８には、上述した図１のＤＢ４０が設けられ、処理データや、端末情報のデータが記憶される。
通信部２０９は、インターネットを含むネットワークを介して他の装置（図示せず）との間で行う通信を制御する。

入出力インターフェース２０５にはまた、必要に応じてドライブ２１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなるリムーバブルメディア２１１が適宜装着される。ドライブ２１０によってリムーバブルメディア２１１から読み出されたプログラムは、必要に応じて記憶部２０８にインストールされる。また、リムーバブルメディア２１１は、記憶部２０８に記憶されている画像データ等の各種データも、記憶部２０８と同様に記憶することができる。

一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えば汎用のパーソナルコンピュータであってもよい。

このようなプログラムを含む記録媒体は、ユーザにプログラムを提供するために装置本体とは別に配布されるリムーバブルメディア３１１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される記録媒体等で構成される。リムーバブルメディア３１１は、例えば、磁気ディスク（フロッピディスクを含む）、光ディスク、又は光磁気ディスク等により構成される。光ディスクは、例えば、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等により構成される。光磁気ディスクは、ＭＤ（Ｍｉｎｉ−Ｄｉｓｋ）等により構成される。また、装置本体に予め組み込まれた状態でユーザに提供される記録媒体は、例えば、プログラムが記録されているＲＯＭ２０２や記憶部２０８に含まれるハードディスク等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。

１０・・・ＤＰＦ端末、１１・・・端末情報記憶部、１２・・・端末情報送信部、１３・・・通信制御部、１４・・・端末情報受信部、１５・・・端末情報登録部、１６・・・入力部、１７・・・表示部、２０・・・ネットワーク、３０・・・サーバ、３１・・・通信制御部、３２・・・端末情報受信部、３３・・・登録有無検出部、３４・・・端末情報整合部、４０・・・ＤＢ、４１・・・一次記憶部、４２・・・二次記憶部、６０・・・メールアドレス発行部、６１・・・メールアドレス配信部、７０・・・メールアドレス発行／更新部、８０・・・端末情報登録部、８１・・・登録情報通知部、９０・・・バックアップ部、２０１・・・ＣＰＵ、２０２・・・ＲＯＭ、２０３・・・ＲＡＭ、２０６・・・入力部、２０７・・・出力部、２０８・・・記憶部、２０９・・・通信部、２１０・・・ドライブ、２１１・・・リムーバブルメディア

Claims (9)

1. 複数の情報からなる端末情報により特定される端末と通信をする情報処理装置であって、
   前記端末から前記端末情報の少なくとも一部が送信されてきた場合、前記端末情報の少なくとも一部を受信する端末情報受信手段と、
   前記端末情報受信手段により少なくとも一部が取得された前記端末情報の登録の有無を検出する登録有無検出手段と、
   前記情報処理装置と前記端末との間の前記端末情報の整合性を保って、前記端末情報を登録する端末情報整合手段と、を備え、
   前記端末情報整合手段による前記端末情報の登録先は、所定のタイミング毎にバックアップされるデータベースであって、前記端末情報を一時的に記憶する一次領域と、前記端末情報を登録するために記憶する二次領域とを含むデータベースであり、
   前記端末情報整合手段は、
   前記登録有無検出手段により前記端末情報の未登録が検出された場合、前記端末情報受信手段により取得された前記端末情報を前記一次領域に一時的に記憶する一次登録手段と、
   前記一次領域に記憶した前記端末情報のバックアップが行われた場合に、前記一次領域に記憶された前記端末情報を前記二次領域に登録するために記憶する二次登録手段と、
   を備えることを特徴とする情報処理装置。
2. 前記端末情報は、少なくとも端末固有ＩＤと、前記端末固有ＩＤに対応するメールアドレスを含むことを特徴とする請求項１に記載の情報処理装置。
3. 前記端末情報整合手段は、
   前記登録有無検出手段により前記端末情報の未登録が検出された場合、新たなメールアドレスを前記端末に対して発行し、前記新たなメールアドレスを登録する発行手段と、
   前記発行手段により発行されたメールアドレスを含む情報を、前記端末情報を登録したことを示す前記情報として前記端末に配信する配信手段と、
   を備える請求項２に記載の情報処理装置。
4. 前記端末情報整合手段は、
   前記登録有無検出手段により前記端末情報の未登録が検出された場合、前記端末情報受信手段に受信された前記端末情報に含まれる前記メールアドレスを更新登録する更新手段と、
   前記更新手段によりメールアドレスが更新登録されたことを示す登録情報を、前記端末情報を登録したことを示す前記情報として前記端末に配信する配信手段と、
   を備える請求項２に記載の情報処理装置。
5. 前記登録有無検出手段は、前記端末情報受信手段により取得された前記端末情報に含まれる前記端末固有ＩＤ及び前記メールアドレスのそれぞれについて、登録の有無を検出し、
   前記端末情報整合手段は、
   前記登録有無検出手段により前記端末固有ＩＤの未登録が検出された場合、前記端末情報受信手段により取得された前記端末情報を新たに登録すると共に、前記端末情報を登録したことを示す情報を前記端末に送信し、
   前記登録有無検出手段により前記端末固有ＩＤの登録が検出されたが、前記メールアドレスの未登録が検出された場合、前記端末情報受信手段により取得された前記端末情報のうち、前記メールアドレスを更新登録し、前記メールアドレスが更新登録されたことを示す登録情報を、前記端末情報を登録したことを示す前記情報として前記端末に配信する、
   請求項２に記載の情報処理装置。
6. 前記一次登録手段は、前記端末情報受信手段により取得された前記端末固有ＩＤに対応するメールアドレスと同じメールアドレスが、前記二次領域にない場合に、前記端末情報受信手段により取得された前記端末情報を前記一次領域に一時的に記憶することを特徴とする請求項２に記載の情報処理装置。
7. 前記二次登録手段は、前記一次領域に記憶された前記端末情報を前記二次領域に登録するとともに、前記一次領域の内容を削除することを特徴とする請求項６に記載の情報処理装置。
8. 情報処理装置が、複数の情報からなる端末情報により特定される端末と通信をする処理を実行する情報処理方法であって、
   前記端末から前記端末情報の少なくとも一部が送信されてきた場合、前記端末情報の少なくとも一部を受信する端末情報受信ステップと、
   前記端末情報受信ステップにより少なくとも一部が取得された前記端末情報の登録の有無を検出する登録有無検出ステップと、
   前記情報処理装置と前記端末との間の前記端末情報の整合性を保って、前記端末情報を登録する端末情報整合ステップと、を含み、
   前記端末情報整合ステップによる前記端末情報の登録先は、所定のタイミング毎にバックアップされるデータベースであって、前記端末情報を一時的に記憶する一次領域と、前記端末情報を登録するために記憶する二次領域とを含むデータベースであり、
   前記端末情報整合ステップは、
   前記登録有無検出ステップにより前記端末固有ＩＤの未登録が検出された場合、前記端末情報受信ステップにより取得された前記端末情報を前記一次領域に一時的に記憶する一次登録ステップと、
   前記一次領域に記憶した前記端末情報のバックアップが行われた場合に、前記一次領域に記憶された前記端末情報を前記二次領域に登録するために記憶する二次登録ステップと、
   を含むことを特徴とする情報処理方法。
9. 情報処理装置に対して、複数の情報からなる端末情報により特定される端末と通信をする情報処理の実行を制御するコンピュータに、
   前記端末から前記端末情報の少なくとも一部が送信されてきた場合、前記端末情報の少なくとも一部を受信する端末情報受信機能と、
   前記端末情報受信機能により少なくとも一部が取得された前記端末情報の登録の有無を検出する登録有無検出機能と、
   前記情報処理装置と前記端末との間の前記端末情報の整合性を保って、前記端末情報を登録する端末情報整合機能と、を実現し、
   前記端末情報整合機能による前記端末情報の登録先は、所定のタイミング毎にバックアップされるデータベースであって、前記端末情報を一時的に記憶する一次領域と、前記端末情報を登録するために記憶する二次領域とを含むデータベースであり、
   前記端末情報整合機能は、
   前記登録有無検出機能により前記端末固有ＩＤの未登録が検出された場合、前記端末情報受信機能により取得された前記端末情報を前記一次領域に一時的に記憶する一次登録機能と、
   前記一次領域に記憶した前記端末情報のバックアップが行われた場合に、前記一次領域に記憶された前記端末情報を前記二次領域に登録するために記憶する二次登録機能と、
   を実現させることを特徴とするプログラム。

Images