JP6695842B2 - 情報管理装置、情報管理方法および情報管理プログラム - Google Patents

Description

本発明は、情報管理装置、情報管理方法および情報管理プログラムに関する。

近年、インターネットの飛躍的な普及に伴い、かかるインターネットを介した広告配信が盛んに行われている。かかる広告配信には、例えば、ウェブページなどの広告媒体に設定された広告枠に企業や商品等の広告コンテンツを表示し、かかる広告コンテンツがユーザによりクリックされた場合に、ブラウザの表示を広告主のウェブページへ遷移させるものなどがある。

こうした広告配信を実現する広告配信システムは元々、広告主から媒体社の各々が個別に広告の入稿を受け付け、各媒体社が管理および運用する広告媒体へ個別に配信するものであった。しかしながら、広告配信の飛躍的な需要の高まりとともに、媒体社ごとの入稿や広告効果の測定の煩雑さも急激に増してきた。

このため、昨今の広告配信システムは、いわゆるＤＳＰ（Demand-Side Platform）やＳＳＰ（Supply-Side Platform）、アドネットワークなどといった、広告主側や広告媒体側を多数束ねるシステム間の取引によって、広告配信の効率化および収益の最大化を図る大規模なネットワークシステムへと変化してきている。

かかるネットワークシステムに含まれるものとしては、例えばリッチメディア配信や、メディアを横断した効果測定などのための一元管理システムである第三者配信アドサーバ（３ＰＡＳ：3rd Party AdServer）なども知られている（例えば、特許文献１参照）。

特開２０１６−０９９８８６号公報

しかしながら、上記の従来技術は、大規模なネットワークシステムへと変化してきているがゆえに、外部との情報の整合性を保つことが難しいという問題があった。例えば、ある媒体社が管理および運用する広告情報管理装置に対し、外部の業者の管理する前述の第三者配信アドサーバをデータ連携させようとしても、通常は外部の情報に対してはそのアクセス手順はＡＰＩ（Application Programming Interface）等で制限され、データ処理の自由度が効かないためである。

本願は、上記に鑑みてなされたものであって、外部との情報の整合性を保つことができる情報管理装置、情報管理方法および情報管理プログラムを提供することを目的とする。

本願に係る情報管理装置は、一の事業者が運用する情報管理装置であって、受付部と、保存部と、実行部と、復元部とを備える。前記受付部は、データ処理に関する処理要求を受け付ける。前記保存部は、前記処理要求に対応する前記データ処理の内容が、前記一の事業者以外の他の事業者が運用する外部装置によって管理され、アクセス手順が制限された外部データへのアクセスを含む場合に、前記外部装置から前記アクセス手順に沿って前記外部データを取得して保存する。前記実行部は、前記処理要求に基づいて前記データ処理を実行する。前記復元部は、前記実行部による前記データ処理の処理結果が異常である場合に、前記アクセス手順に沿いつつ、前記保存部によって保存された保存データに基づいて前記外部装置に前記外部データを前記データ処理の実行前の状態に復元させる。

実施形態の一態様によれば、外部との情報の整合性を保つことができる情報管理装置、情報管理方法および情報管理プログラムを提供することができる。

図１は、実施形態に係る広告情報管理処理の一例を示す図である。 図２は、実施形態に係る広告情報管理システムの構成例を示す図である。 図３は、実施形態に係る広告情報管理装置の構成例を示すブロック図である。 図４は、ライブラリ管理情報テーブルの一例を示す図である。 図５Ａは、登録処理の一例を示す処理シーケンス図である。 図５Ｂは、更新処理の一例を示す処理シーケンス図である。 図５Ｃは、削除処理の一例を示す処理シーケンス図である。 図６は、実施形態に係る広告情報管理装置が実行する処理手順を示すフローチャートである。 図７は、広告情報管理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願に係る情報管理装置、情報管理方法および情報管理プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報管理装置、情報管理方法および情報管理プログラムが限定されるものではない。また、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．広告情報管理処理の一例〕
まず、図１を用いて、実施形態に係る広告情報管理処理の一例について説明する。図１は、実施形態に係る広告情報管理処理の一例を示す図である。図１では、実施形態に係る広告情報管理装置１００（「情報管理装置」の一例に相当）が、データ処理に関する処理要求を受け付け、かかる処理要求に対応するデータ処理の内容が管理外の外部データへのアクセスを含む場合に、少なくとも外部データを管理する外部装置からかかる外部データを取得して保存し、上記処理要求に基づいてデータ処理を実行し、データ処理の処理結果が異常である場合に、保存した保存データに基づいて外部装置に外部データをデータ処理の実行前の状態に復元させる処理を実行するべくデータ連携する例を示す。

なお、以下においては、広告媒体の一例としてウェブページを説明するが、広告媒体は、ウェブページ以外の広告媒体であってもよい。例えば広告媒体は、ゲームアプリケーション、書籍閲覧アプリケーション、音楽配信アプリケーション、動画配信アプリケーションによって表示される媒体などであってもよい。

図１に示す実施形態に係る広告情報管理システム１に含まれる広告情報管理装置１００は、例えば媒体社Ａが管理および運用する広告情報に関する内部データのデータベース（以下、「ＤＢ」と記載する）群である内部ＤＢ群４１を管理するサーバ装置である。

また、広告情報管理装置１００は、ユーザＵからの広告コンテンツの配信要求である広告リクエストを受け付けた場合に、かかる広告リクエストに対する広告コンテンツの配信要求を「配信要求先」である広告配信装置３０−１，３０−２へ送信する広告配信に係るサーバ装置を兼ねることができる。

まず、本実施形態の説明を分かりやすくするために、かかる広告配信に係る面から、より具体的に、広告情報管理装置１００を含む広告情報管理システム１によって実行される処理の一例を流れに沿って説明する。

図１に示すように、まずウェブサーバ２０が、ユーザＵの利用する端末装置１０から送信されたページ要求（ステップＳ１）を受け付けると、ページ要求に応じたウェブページＷＰを端末装置１０へ送信する（ステップＳ２）。

端末装置１０は、ウェブサーバ２０から広告枠ＡＦを含むウェブページＷＰを受信した場合、広告リクエストを広告情報管理装置１００へ送信する（ステップＳ３）。広告リクエストは、例えば、ウェブページＷＰに設定された広告枠ＡＦに表示する広告コンテンツの配信要求である。

広告情報管理装置１００は、端末装置１０から広告リクエストを受け付けた場合に、広告リクエストに対応する広告コンテンツの抽出元となる配信要求先を選択し、配信要求を送信する（ステップＳ４）。なお、配信要求先は、図１の例において、広告配信装置３０−１，３０−２のいずれか一方または双方から選択される。また、図１の例において、広告配信装置３０−１は媒体社Ａによって運用および管理され、広告配信装置３０−２は広告配信業者Ｂによって運用および管理される。

配信要求先、すなわち広告枠ＡＦへ配信する広告コンテンツの抽出元となる広告配信装置３０−１，３０−２は、かかる配信要求に応じた広告コンテンツを広告情報管理装置１００へ送信する（ステップＳ５）。

そして、広告情報管理装置１００は、広告配信装置３０−１，３０−２から受け付けた広告コンテンツを端末装置１０へ送信する（ステップＳ６）。その後、端末装置１０は、広告情報管理装置１００から送信された例えば広告コンテンツＡ０１を広告枠ＡＦに表示する（ステップＳ７）。なお、広告配信装置３０−１，３０−２は、広告情報管理装置１００を経由せずに、端末装置１０へ直接広告コンテンツを送信するようにしてもよい。

ところで、近年、更なる拡がりを見せている広告配信に係るネットワークシステムであるが、例えばリッチメディア配信や、メディアを横断した効果測定などのために第三者配信アドサーバ（以下、「第三者サーバ７０」と記載する）が利用される場合がある。なお、ここに言う「第三者」は、いわゆる「サードパーティ」を指す。

例えば、第三者サーバ７０は、媒体社Ａの広告配信装置３０−１のバックエンドサーバとして機能し、例えば広告配信装置３０−１からの配信要求（ステップＳ４−１）に対し、第三者配信業者Ｃが管理および運用する外部データの外部ＤＢ群７１を抽出元とする広告コンテンツ群から広告コンテンツを送信する（ステップＳ４−２）。

ただし、図１の例において、第三者配信業者Ｃ側では、データ固有の識別情報である「固有ＩＤ」を用いて各外部データを管理している。一方、媒体社Ａ側では、広告配信に関する内部データを図中に示すように「広告配信タグ」によって管理している。

「広告配信タグ」は、配信要求に際して含ませる各種パラメータを含む情報であり、第三者サーバ７０に対しては該当データごとの「固有ＩＤ」を指定する必要がある。したがって、例えば、「広告配信タグ」の設定内容に変更などが生じた場合には、「広告配信タグ」に紐づく「固有ＩＤ」を指定して、第三者配信業者Ｃ側にもかかる変更の内容を反映させなければならない。

すなわち、図１に示すように、媒体社Ａ側の内部ＤＢ群４１と第三者配信業者Ｃ側の外部ＤＢ群７１とは、常に「データ連携」して整合性を保つ必要がある。外部ＤＢ群７１の外部データへのアクセスには、通常、第三者配信業者Ｃ側から提供されるＡＰＩを利用する。ただし、これは反面、ＡＰＩによって外部ＤＢ群７１の外部データへのアクセスが制限されていることを意味する。

そこで、実施形態に係る広告情報管理装置１００は、かかるＡＰＩによる制限下でも、外部との情報の整合性を保つことができるように、データ処理に関する処理要求を受け付け、かかる処理要求に対応するデータ処理の内容が管理外の外部データへのアクセスを含む場合に、少なくとも外部データを管理する外部装置からかかる外部データを取得して保存し、上記処理要求に基づいてデータ処理を実行し、データ処理の処理結果が異常である場合に、保存した保存データに基づいて外部装置に外部データをデータ処理の実行前の状態に復元させることとした。

例えば、広告情報管理装置１００は、データ処理の内容が、広告配信タグに対応する内部データおよび固有ＩＤに対応する外部データの双方を更新する「更新処理」や、双方を削除する「削除処理」などである場合に、少なくとも既存の外部データの状態が、データ処理が失敗しても戻すことができるように、予めＡＰＩを用いて外部データを取得して保存しておく。そして、広告情報管理装置１００は、データ処理の処理結果が異常である場合に、保存した保存データに基づいてＡＰＩを介して第三者サーバ７０へ復元させる。

これにより、広告情報管理装置１００は、内部ＤＢ群４１と、外部ＤＢ群７１との間で情報の整合性を保つことができる。なお、本実施形態の説明では、データ処理の具体例としては、上述の「更新処理」や「削除処理」のほか、内部データおよび外部データの双方を新規に登録する「登録処理」を例に挙げる。これら具体例は、図５Ａ〜図５Ｃを用いて後述する。

以下、このような処理を行う広告情報管理装置１００および広告情報管理装置１００を含む広告情報管理システム１の構成等について、詳細に説明する。

〔２．広告情報管理システム１の構成〕
次に、図２を用いて、実施形態に係る広告情報管理装置１００が含まれる広告情報管理システム１の構成について説明する。図２は、実施形態に係る広告情報管理システム１の構成例を示す図である。図２に示すように、実施形態に係る広告情報管理システム１には、端末装置１０と、ウェブサーバ２０と、複数の広告配信装置３０−１，３０−２と、ＤＢサーバ４０と、ＡＰＩサーバ５０と、第三者サーバ７０と、広告情報管理装置１００と、内部ＤＢ群４１と、外部ＤＢ群７１とが含まれる。

これらの各種装置は、図２に示すように、通信ネットワークＮを介して、有線または無線により通信可能に接続される。なお、広告情報管理システム１には、複数の端末装置１０、複数の広告情報管理装置１００、また、例えば３つ以上の広告配信装置３０−１，３０−２，３０−３，…が含まれてもよい。また、広告情報管理システム１には、ＡＰＩサーバ５０、第三者サーバ７０、内部ＤＢ群４１、外部ＤＢ群７１がそれぞれ複数含まれてもよい。

図２に示すように、ウェブサーバ２０、広告情報管理装置１００、広告配信装置３０−１およびＤＢサーバ４０は、例えば媒体社Ａにより管理および運用される。また、内部ＤＢ群４１は、例えばＤＢサーバ４０に接続される。なお、ＤＢサーバ４０および広告情報管理装置１００は、シームレスに連携されており、広告情報管理装置１００は、ＡＰＩ等を用いることなく自装置のデータにアクセスするのと同様に、内部ＤＢ群４１の内部データを取り扱うことができる。

また、広告配信装置３０−２は、例えば広告配信業者Ｂにより管理および運用される。また、ＡＰＩサーバ５０および第三者サーバ７０は、例えば第三者配信業者Ｃにより管理および運用される。また、外部ＤＢ群７１は、例えば第三者サーバ７０に接続される。

端末装置１０は、ユーザＵによって利用される情報処理装置である。端末装置１０は、例えば、ブラウザがインストールされている。図２においては、端末装置１０がノート型ＰＣである場合を例示している。なお、端末装置１０は、例えば、タブレット型端末や、デスクトップ型ＰＣ（Personal Computer）、ノート型ＰＣ、スマートフォン、スマートフォン以外の携帯電話機や、ＰＤＡ（Personal Digital Assistant）などであってもよい。

ウェブサーバ２０は、広告枠が設定された各種ウェブページを記憶している。ウェブサーバ２０は、端末装置１０のブラウザからのアクセスがあると、端末装置１０によって指定されたＵＲＬ（Uniform Resource Locator）に対応する各種ウェブページ、例えば、ポータルサイト、ニュースサイト、天気予報サイト、ショッピングサイト、ファイナンス（株価）サイト、路線検索サイト、地図提供サイト、旅行サイト、飲食店紹介サイト、ウェブブログなどに関する各種ウェブページを提供する。

端末装置１０のブラウザは、ウェブサーバ２０からウェブページを受信すると、ウェブページに設定された広告枠に対応する広告リクエスト（以下、単に「リクエスト」と記載する場合がある）を広告情報管理装置１００へ送信する。リクエストは、広告枠に表示する広告コンテンツの配信要求であり、例えば、端末装置１０のユーザＵの識別情報（以下、「ユーザＩＤ」と記載する）や広告枠の識別情報（以下、「広告枠ＩＤ」と記載する）を含む。ユーザＩＤは、例えば、ＨＴＴＰクッキー（HyperText Transfer Protocol Cookie：以下、「クッキー」と記載する）である。かかるクッキーには、ユーザＵの年齢、性別などのユーザ情報は含まれないため、各サーバ側が保持するユーザ情報と端末装置１０側からのクッキーのＩＤが対応付けられ、ターゲティングなどに利用される。

広告配信装置３０−１，３０−２は、広告コンテンツの「抽出元」であり、例えば所定のアドネットワークである。広告配信装置３０−１，３０−２は、広告情報管理装置１００から広告コンテンツの配信要求があった場合に、かかる広告配信装置３０−１，３０−２に在庫する広告コンテンツ群から、広告コンテンツを配信要求の内容に沿って配信する。

ＤＢサーバ４０は、内部ＤＢ群４１を管理および運用するサーバ装置である。ＡＰＩサーバ５０は、外部ＤＢ群７１に対するデータ処理の処理要求をＡＰＩによって受け付け、かかる処理要求を解釈して外部ＤＢ群７１に対するデータ処理を実行し、その結果を処理要求の送信元へ返すサーバ装置である。第三者サーバ７０は、外部ＤＢ群７１を管理および運用するサーバ装置であり、例えば３ＰＡＳである。

広告情報管理装置１００は、既に述べたが、広告配信のデータ処理に関する処理要求を受け付け、かかる処理要求に対応するデータ処理の内容が管理外の外部データへのアクセスを含む場合に、少なくとも外部データを管理する外部装置からかかる外部データを取得して保存し、上記処理要求に基づいてデータ処理を実行し、データ処理の処理結果が異常である場合に、保存した保存データに基づいて外部装置に外部データをデータ処理の実行前の状態に復元させるサーバ装置である。

〔３．広告情報管理装置１００〕
次に、図３を用いて、広告情報管理装置１００の構成について説明する。図３は、実施形態に係る広告情報管理装置１００の構成例を示すブロック図である。なお、図３では、広告情報管理装置１００の説明に必要となる構成要素のみを示しており、一般的な構成要素についての記載を省略している。

図３に示すように、広告情報管理装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、広告情報管理装置１００は、広告情報管理装置１００を利用するオペレータ等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。

（通信部１１０について）
通信部１１０は、例えばＮＩＣ（Network Interface Card）等によって実現される。通信部１１０は、通信ネットワークＮと有線または無線で接続され、通信ネットワークＮを介して、端末装置１０や、広告配信装置３０−１，３０−２、ＤＢサーバ４０、ＡＰＩサーバ５０、第三者サーバ７０との間で情報の送受信を行う。

（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現され、図３に示すように、記憶部１２０は、ライブラリ管理情報１２１と、保存情報１２２とを記憶する。

（ライブラリ管理情報１２１について）
ライブラリ管理情報１２１は、広告情報管理装置１００に対して処理要求される各データ処理に対し、それぞれ処理対象となるＤＢサーバ４０の内部ＤＢ群４１に格納された内部データ、および、第三者サーバ７０の外部ＤＢ群７１に格納された外部データが関連付けられたライブラリ情報である。

ここで、図４にライブラリ管理情報１２１に含まれるライブラリ管理情報テーブルの一例を示す。図４は、ライブラリ管理情報テーブルの一例を示す図である。

図４に示した例では、ライブラリ管理情報テーブルは、「トランザクションＩＤ」、「対象エンティティＩＤ」、「対象ＤＢＩＤ」、「管理区分」といった項目を有する。

「トランザクションＩＤ」は、広告情報管理装置１００が内部ＤＢ群４１および外部ＤＢ群７１のいずれか一方または双方に対して実行するデータ処理それぞれの識別情報を示す。「対象エンティティ」は、各データ処理において処理対象となるエンティティ（例えば、データ項目等）の識別情報を示す。

「対象ＤＢＩＤ」は、処理対象となるエンティティに関連する対象ＤＢの識別情報を示す。「管理区分」は、各対象ＤＢが、広告情報管理装置１００側から見て「内部」であるのか「外部」であるのかを示す。すなわち、「内部」か「外部」を示すキー情報である。本実施形態では、「内部」は、内部ＤＢ群４１の内部データに対応し、「外部」は、外部ＤＢ群７１の外部データに対応する。

図４に示したデータの一例は、トランザクションＩＤ「ＴＲ００１」は、対象エンティティＩＤ「Ｅ００１」，「Ｅ００２」，…のエンティティが処理対象であって、対象エンティティＩＤ「Ｅ００１」は、対象ＤＢＩＤ「ＤＢ００１」のＤＢに格納され、管理区分「内部」、すなわち内部ＤＢ群４１の内部データであることを示している。一方、対象エンティティＩＤ「Ｅ００２」は、対象ＤＢＩＤ「ＤＢ００２」のＤＢに格納され、管理区分「外部」、すなわち外部ＤＢ群７１の外部データであることを示している。

（保存情報１２２について）
図３の説明に戻る。保存情報１２２は、広告情報管理装置１００に対して処理要求されるデータ処理の内容が管理外である外部ＤＢ群７１に格納された外部データへのアクセスを含む場合に、データ処理に先立ち、少なくともかかる外部データを管理する第三者サーバ７０から取得されて保存された情報である。保存情報１２２は、後述する保存部１３４によって保存される。

（制御部１３０について）
制御部１３０は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、広告情報管理装置１００内部の記憶装置に記憶されている各種プログラム（広告情報管理プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、コントローラであり、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

図３に示すように、制御部１３０は、収集部１３１と、受付部１３２と、判別部１３３と、保存部１３４と、実行部１３５と、復元部１３６とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図３に示した構成に限られず、後述する情報処理を行うことができる構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図３に示した接続関係に限られず、他の接続関係であってもよい。

（収集部１３１について）
収集部１３１は、通信部１１０および通信ネットワークＮを介し、予め設定した内部ＤＢ群４１および外部ＤＢ群７１の各ＤＢに対してアクセスし、定期的に内部構造情報を収集する。また、収集部１３１は、収集した内容をライブラリ管理情報１２１へ反映する。

（受付部１３２について）
受付部１３２は、例えば通信部１１０および通信ネットワークＮを介し、内部データおよび外部データの「登録処理」、「更新処理」、「削除処理」といったデータ処理に関する処理要求を受け付ける。かかる処理要求には、例えば前述の「トランザクションＩＤ」が含まれる。なお、図示略のキーボード等の入力部を介した操作によって処理要求を受け付けてもよい。

（判別部１３３について）
判別部１３３は、受付部１３２によって受け付けられた処理要求に含まれるデータ処理の内容、例えば「トランザクションＩＤ」をライブラリ管理情報１２１に照らし、要求されたデータ処理が、管理外の第三者サーバ７０の管理する外部データへのアクセスを含むか否かを判別する。外部データへのアクセスを含む場合、判別部１３３は、保存部１３４に該当の外部データを保存させた後で、実行部１３５に処理要求に対応するデータ処理を実行させる。一方、外部データへのアクセスを含まない場合、判別部１３３は、実行部１３５にそのまま処理要求に対応するデータ処理を実行させる。

（保存部１３４について）
保存部１３４は、判別部１３３によって、要求されたデータ処理が管理外の第三者サーバ７０の管理する外部データへのアクセスを含むと判別された場合に、ライブラリ情報１２１に基づき、ＡＰＩ（すなわち、ＡＰＩサーバ５０）を介して第三者サーバ７０から該当する外部データを取得して、保存情報１２２へ保存する。

（実行部１３５について）
実行部１３５は、通信部１１０および通信ネットワークＮを介し、データ処理の処理内容に応じて適宜内部ＤＢ群４１および外部ＤＢ群７１へアクセスしつつ、処理要求に対応するデータ処理を実行する。なお、既に述べたが、実行部１３５は、通信ネットワークＮを介しつつも内部ＤＢ群４１に対してはシームレスにアクセスすることができる。一方、実行部１３５は、外部ＤＢ群７１に対してはＡＰＩサーバ５０を介した所定のアクセス手順によりアクセスする。これらの点は後述する復元部１３６についても同様である。

また、実行部１３５は、実行したデータ処理の処理結果が正常である場合に、保存情報１２２を自動的に削除する。また、実行部１３５は、実行したデータ処理の処理結果が異常である場合に、復元部１３６に復元処理を実行させる。

（復元部１３６について）
復元部１３６は、実行部１３５によるデータ処理の処理結果が異常である場合に、保存部１３４によって保存された保存情報１２２に基づいて、第三者サーバ７０に外部ＤＢ群７１の該当する外部データをデータ処理の実行前の状態に復元させる。

また、復元部１３６は、実行した復元処理の処理結果が正常である場合に、保存情報１２２を自動的に削除する。なお、実行部１３５によるデータ処理の処理結果が異常となった原因特定などのために、復元部１３６は、保存情報１２２を削除しなくともよい。

（登録処理の具体例について）
次に、実施形態に係る広告情報管理システム１が実行する登録処理の具体例について、図５Ａを用いて説明する。図５Ａは、登録処理の一例を示す処理シーケンス図である。なお、本処理シーケンス図では、内部ＤＢ群４１の内部データ、および、外部ＤＢ群７１の外部データの双方が処理対象であるものとする。また、この点は、後述する図５Ｂおよび図５Ｃを用いた説明でも同様とする。

「正常時」から説明する。図５Ａに示すように、「登録処理」ではまず、広告情報管理装置１００の実行部１３５が、データ処理の処理要求に含まれる内容に基づく登録データを、シームレスにＤＢサーバ４０の内部ＤＢ群４１に登録する（ステップＳ１０１）。

そして、広告情報管理装置１００の実行部１３５は、ＡＰＩを呼び出して同じ登録データの登録要求を送信する（ステップＳ１０２）。かかる登録要求は、ＡＰＩサーバ５０を介して第三者サーバ７０へ送信され（ステップＳ１０３）、第三者サーバ７０はかかる登録要求に応じてデータを登録する。このとき、新規の登録データに対し、固有ＩＤが発行される。ここでは固有ＩＤ_Ａが発行されたものとする。

そして、第三者サーバ７０は、かかる固有ＩＤ_Ａを、ＡＰＩサーバ５０へ送信し（ステップＳ１０４）、ＡＰＩサーバ５０はこれをさらに広告情報管理装置１００へ送信する（ステップＳ１０５）。

広告情報管理装置１００の実行部１３５は、受け取った固有ＩＤ_ＡをＤＢサーバ４０の内部ＤＢ群４１のステップＳ１０１で登録した内部データに追記する（ステップＳ１０６）。これにより、今回登録した内部データおよび外部データを紐付けて、実行部１３５は、登録処理を終了する。

つづいて「異常時」について説明する。ここではステップＳ１０６の「追記」が異常終了したものとする（ステップＳ１０７）。かかる場合、広告情報管理装置１００の復元部１３６が、ＡＰＩを呼び出して固有ＩＤ_Ａに対応する外部データの削除要求を送信する（ステップＳ１０８）。かかる削除要求は、ＡＰＩサーバ５０を介して第三者サーバ７０へ送信され（ステップＳ１０９）、第三者サーバ７０はかかる削除要求に応じて該当するデータを削除する。

そして、第三者サーバ７０は、かかる固有ＩＤ_Ａに対応する外部データを削除したことを示す削除応答をＡＰＩサーバ５０へ送信し（ステップＳ１１０）、ＡＰＩサーバ５０はこれをさらに広告情報管理装置１００へ送信する（ステップＳ１１１）。これにより、復元部１３６による、登録処理の異常時の復元処理が終了する。

このように、復元部１３６は、実行部１３５がデータ処理として内部データおよび外部データを新規に登録する登録処理を実行し、かかる登録処理の処理結果が異常である場合に、新規の外部データを識別する固有ＩＤを第三者サーバ７０から取得済みであるならば、かかる第三者サーバ７０に対して固有ＩＤおよび固有ＩＤに対応する外部データを削除させる削除要求を送信する。

これにより、登録処理が異常終了した場合であっても、内部データおよび外部データの間で整合性を保つことができる。

（更新処理の具体例について）
次に、実施形態に係る広告情報管理システム１が実行する更新処理の具体例について、図５Ｂを用いて説明する。図５Ｂは、更新処理の一例を示す処理シーケンス図である。

「正常時」から説明する。図５Ｂに示すように、「更新処理」ではまず、広告情報管理装置１００の保存部１３４が、処理対象となる外部データの取得要求を、ＡＰＩを呼び出してＡＰＩサーバ５０へ送信する（ステップＳ２０１）。

かかる取得要求は、ＡＰＩサーバ５０を介して第三者サーバ７０へ送信され（ステップＳ２０２）、第三者サーバ７０はかかる取得要求に応じて外部データを外部ＤＢ群７１から抽出して取得する。

そして、第三者サーバ７０は、取得した取得データをＡＰＩサーバ５０へ送信し（ステップＳ２０３）、ＡＰＩサーバ５０はこれをさらに広告情報管理装置１００へ送信する（ステップＳ２０４）。

広告情報管理装置１００の保存部１３４は、受け取った取得データを保存情報１２２として保存する（ステップＳ２０５）。そして、実行部１３５が、データ処理の処理要求に含まれる内容に基づく更新データをセットし（ステップＳ２０６）、かかる更新データを含む更新要求を、ＡＰＩを呼び出してＡＰＩサーバ５０へ送信する（ステップＳ２０７）。

かかる更新要求は、ＡＰＩサーバ５０を介して第三者サーバ７０へ送信され（ステップＳ２０８）、第三者サーバ７０はかかる更新要求に応じて外部ＤＢ群７１の該当する外部データを更新する。

そして、第三者サーバ７０は、該当の外部データを更新したことを示す更新応答をＡＰＩサーバ５０へ送信し（ステップＳ２０９）、ＡＰＩサーバ５０はこれをさらに広告情報管理装置１００へ送信する（ステップＳ２１０）。

広告情報管理装置１００の実行部１３５は、かかる更新応答を受信した後、同じ更新データの内容をＤＢサーバ４０の内部ＤＢ群４１の該当する内部データに反映して更新する（ステップＳ２１１）。そして、実行部１３５は、保存分である保存情報１２２を削除した後（ステップＳ２１２）、更新処理を終了する。

つづいて「異常時」について説明する。ここではステップＳ２１１の「更新」が異常終了したものとする（ステップＳ２１３）。かかる場合、広告情報管理装置１００の復元部１３６が、保存分である保存情報１２２を読み出して取得し（ステップＳ２１４）、ＡＰＩを呼び出してかかる保存分での更新要求を送信する（ステップＳ２１５）。

かかる更新要求は、ＡＰＩサーバ５０を介して第三者サーバ７０へ送信され（ステップＳ２１６）、第三者サーバ７０はかかる更新要求に応じて該当する外部データを更新する。

そして、第三者サーバ７０は、該当する外部データを更新したことを示す更新応答をＡＰＩサーバ５０へ送信し（ステップＳ２１７）、ＡＰＩサーバ５０はこれをさらに広告情報管理装置１００へ送信する（ステップＳ２１８）。そして、復元部１３６は、保存分の保存情報１２２を削除する（ステップＳ２１９）。これにより、復元部１３６による、更新処理の異常時の復元処理が終了する。

このように、保存部１３４は、実行部１３５がデータ処理として内部データおよび外部データを更新する更新処理を実行する場合に、処理対象となる外部データを更新処理が実行される前に第三者サーバ７０から取得して保存する。また、復元部１３６は、実行部１３５によって実行された更新処理の処理結果が異常である場合に、外部データは第三者サーバ７０によって更新済みであるならば、かかる第三者サーバ７０に対し、保存部１３４によって保存された保存情報１２２の内容で外部ＤＢ群７１の外部データを更新させる更新要求を送信する。

これにより、更新処理が異常終了した場合であっても、内部データおよび外部データの間で整合性を保つことができる。

（削除処理の具体例について）
次に、実施形態に係る広告情報管理システム１が実行する削除処理の具体例について、図５Ｃを用いて説明する。図５Ｃは、削除処理の一例を示す処理シーケンス図である。

「正常時」から説明する。図５Ｃに示すように、「削除処理」ではまず、広告情報管理装置１００の保存部１３４が、処理対象となる外部データの取得要求を、ＡＰＩを呼び出してＡＰＩサーバ５０へ送信する（ステップＳ３０１）。なお、このとき、例えば広告配信タグに紐付いている固有ＩＤを指定する。ここでは、例えば固有ＩＤ_Ａであるものとする。

かかる取得要求は、ＡＰＩサーバ５０を介して第三者サーバ７０へ送信され（ステップＳ３０２）、第三者サーバ７０はかかる取得要求に該当する固有ＩＤ_Ａに対応する外部データを外部ＤＢ群７１から抽出して取得する。

そして、第三者サーバ７０は、取得した取得データをＡＰＩサーバ５０へ送信し（ステップＳ３０３）、ＡＰＩサーバ５０はこれをさらに広告情報管理装置１００へ送信する（ステップＳ３０４）。

広告情報管理装置１００の保存部１３４は、受け取った取得データを保存情報１２２として保存する（ステップＳ３０５）。そして、実行部１３５が、ＡＰＩを呼び出して固有ＩＤ_Ａに対応する外部データの削除要求を送信する（ステップＳ３０６）。かかる削除要求は、ＡＰＩサーバ５０を介して第三者サーバ７０へ送信され（ステップＳ３０７）、第三者サーバ７０はかかる削除要求に応じて該当する外部データを削除する。

そして、第三者サーバ７０は、かかる固有ＩＤ_Ａに対応する外部データを削除したことを示す削除応答をＡＰＩサーバ５０へ送信し（ステップＳ３０８）、ＡＰＩサーバ５０はこれをさらに広告情報管理装置１００へ送信する（ステップＳ３０９）。

そして、実行部１３５は、固有ＩＤ_Ａに紐付けられた、ＤＢサーバ４０の内部ＤＢ群４１の該当する内部データを削除する（ステップＳ３１０）。そして、実行部１３５は、保存分である保存情報１２２を削除した後（ステップＳ３１１）、削除処理を終了する。

つづいて「異常時」について説明する。ここではステップＳ３１０の「削除」が異常終了したものとする（ステップＳ３１２）。かかる場合、広告情報管理装置１００の復元部１３６が、保存分である保存情報１２２を読み出して取得し（ステップＳ３１３）、ＡＰＩを呼び出してかかる保存分での登録要求を送信する（ステップＳ３１４）。

かかる登録要求は、ＡＰＩサーバ５０を介して第三者サーバ７０へ送信され（ステップＳ３１５）、第三者サーバ７０はかかる登録要求に応じて新しく外部データを登録する。このとき、新規の登録データに対し、固有ＩＤが発行される。ここでは固有ＩＤ_Ｂが発行されたものとする。

そして、第三者サーバ７０は、かかる固有ＩＤ_Ｂを、ＡＰＩサーバ５０へ送信し（ステップＳ３１６）、ＡＰＩサーバ５０はこれをさらに広告情報管理装置１００へ送信する（ステップＳ３１７）。

広告情報管理装置１００の復元部１３６は、ＤＢサーバ４０の内部ＤＢ群４１の該当する内部データを受け取った固有ＩＤ_Ｂで更新する（ステップＳ３１８）。そして、復元部１３６は、保存分である保存情報１２２を削除する（ステップＳ３１９）。これにより、復元部１３６による、削除処理の異常時の復元処理が終了する。

このように、保存部１３４は、実行部１３５がデータ処理として内部データおよび外部データを削除する削除処理を実行する場合に、処理対象となる外部データを削除処理が実行される前に第三者サーバ７０から取得して保存する。また、復元部１３６は、実行部１３５によって実行された削除処理の処理結果が異常である場合に、外部データは第三者サーバ７０によって削除済みであるならば、かかる第三者サーバ７０に対し、保存部１３４によって保存された保存情報１２２の内容で外部ＤＢ群７１の外部データを新規に登録させる登録要求を送信し、かかる登録要求に対して発行される新規の固有ＩＤを削除処理が実行される前の内部ＤＢ群４１の内部データへ関連付ける。

これにより、削除処理が異常終了した場合であっても、内部データおよび外部データの間で整合性を保つことができる。

〔４．広告情報管理装置１００の処理手順〕
次に、実施形態に係る広告情報管理装置１００が実行する処理手順について説明する。図６は、実施形態に係る広告情報管理装置１００が実行する処理手順を示すフローチャートである。

図６に示すように、まず収集部１３１が、ＤＢに関する情報を随時収集する（ステップＳ１００１）。

そして、受付部１３２は、データ処理に関する処理要求を随時受け付ける。ここで、受付部１３２が処理要求を受け付けた場合（ステップＳ１００２，Ｙｅｓ）、判別部１３３が、処理対象となるデータが外部ＤＢのデータを含むか否かを判定する（ステップＳ１００３）。なお、受付部１３２が処理要求を受け付けない場合（ステップＳ１００２，Ｎｏ）、ステップＳ１００２を繰り返す。

そして、ステップＳ１００３で外部ＤＢのデータを含むと判定された場合（ステップＳ１００３，Ｙｅｓ）、保存部１３４が、処理対象となる対象データを取得して保存する（ステップＳ１００４）。ステップＳ１００３で外部ＤＢのデータを含まないと判定された場合（ステップＳ１００３，Ｎｏ）、ステップＳ１００５へ制御を移す。

つづいて、受け付けられた処理要求に基づいて処理種別が判定される（ステップＳ１００５）。処理種別は、上述したトランザクションＩＤに対応する。処理種別が「登録」である場合（ステップＳ１００５，登録）、実行部１３５が、登録処理を実行する（ステップＳ１００６）。

また、処理種別が「更新」である場合（ステップＳ１００５，更新）、実行部１３５が、更新処理を実行する（ステップＳ１００７）。

また、処理種別が「削除」である場合（ステップＳ１００５，削除）、実行部１３５が、削除処理を実行する（ステップＳ１００８）。

そして、それぞれの処理が異常終了したか否かが判定される（ステップＳ１００９）。ここで、異常終了したと判定された場合（ステップＳ１００９，Ｙｅｓ）、復元部１３６が処理種別に応じた復元処理を実行する（ステップＳ１０１０）。異常終了しなかったと判定された場合（ステップＳ１００９，Ｎｏ）、ステップＳ１０１１へ制御を移す。

そして、終了イベントがあれば（ステップＳ１０１１，Ｙｅｓ）、広告情報管理装置１００は処理を終了する。終了イベントは、例えば電源ＯＦＦ等のイベントである。終了イベントがなければ（ステップＳ１０１１，Ｎｏ）、広告情報管理装置１００は、ステップＳ１００２からの処理を繰り返し実行する。

〔５．ハードウェア構成〕
上述してきた実施形態に係る広告情報管理装置１００や端末装置１０、ウェブサーバ２０、広告配信装置３０−１，３０−２，３０−３、ＤＢサーバ４０等は、例えば図７に示すような構成のコンピュータ６０によって実現される。以下、広告情報管理装置１００を例に挙げて説明する。図６は、広告情報管理装置１００の機能を実現するコンピュータの一例を示すハードウェア構成図である。コンピュータ６０は、ＣＰＵ（Central Processing Unit）６１、ＲＡＭ（Random Access Memory）６２、ＲＯＭ（Read Only Memory）６３、ＨＤＤ（Hard Disk Drive）６４、通信インターフェイス（Ｉ／Ｆ）６５、入出力インターフェイス（Ｉ／Ｆ）６６、およびメディアインターフェイス（Ｉ／Ｆ）６７を備える。

ＣＰＵ６１は、ＲＯＭ６３またはＨＤＤ６４に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ６３は、コンピュータ６０の起動時にＣＰＵ６１によって実行されるブートプログラムや、コンピュータ６０のハードウェアに依存するプログラム等を格納する。

ＨＤＤ６４は、ＣＰＵ６１によって実行されるプログラムおよび当該プログラムによって使用されるデータ等を格納する。通信インターフェイス６５は、通信部１１０に対応し、通信ネットワークＮを介して他の機器からデータを受信してＣＰＵ６１へ送り、ＣＰＵ６１が生成したデータを、通信ネットワークＮを介して他の機器へ送信する。

ＣＰＵ６１は、入出力インターフェイス６６を介して、ディスプレイやプリンタ等の出力装置、および、キーボードやマウス等の入力装置を制御する。ＣＰＵ６１は、入出力インターフェイス６６を介して、入力装置からデータを取得する。また、ＣＰＵ６１は、生成したデータを、入出力インターフェイス６６を介して出力装置へ出力する。

メディアインターフェイス６７は、記録媒体６８に格納されたプログラムまたはデータを読み取り、ＲＡＭ６２を介してＣＰＵ６１に提供する。ＣＰＵ６１は、当該プログラムを、メディアインターフェイス６７を介して記録媒体６８からＲＡＭ６２上にロードし、ロードしたプログラムを実行する。記録媒体６８は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ６０が実施形態に係る広告情報管理装置１００として機能する場合、コンピュータ６０のＣＰＵ６１は、ＲＡＭ６２上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。また、ＨＤＤ６４には、記憶部１２０内のデータが記憶される。

コンピュータ６０のＣＰＵ６１は、これらのプログラムを、記録媒体６８から読み取って実行するが、他の例として、他の装置から、通信ネットワークＮを介してこれらのプログラムを取得してもよい。

〔６．その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

例えば、図３に示した実行部１３５と、復元部１３６とは統合されてもよい。また、例えば、記憶部１２０に記憶される情報は、通信ネットワークＮを介して、外部に備えられた所定の記憶装置に記憶されてもよい。また、逆に、ＤＢサーバ４０が管理する内部ＤＢ群４１が、記憶部１２０に記憶されてもよい。すなわち、広告情報管理装置１００と、ＤＢサーバ４０とが統合されてもよい。

また、上述した実施形態では、取り扱われる情報が主に広告配信に関する情報である場合を例に挙げたが、情報の種別を限定するものではなく、また、広告業界に係るものにも限られない。本願は、例えば金融業界など、多数の事業者が管理する多数のトランザクションＤＢを有するネットワークシステム等にも適用可能である。

また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

〔７．効果〕
実施形態に係る広告情報管理システム１（「情報管理システム」の一例に相当）の広告情報管理装置１００（「情報管理装置」の一例に相当）は、受付部１３２と、保存部１３４と、実行部１３５と、復元部１３６とを備える。受付部１３２は、データ処理に関する処理要求を受け付ける。保存部１３４は、処理要求に対応するデータ処理の内容が管理外の外部データへのアクセスを含む場合に、少なくとも外部データを管理する第三者サーバ７０（「外部装置」の一例に相当）から外部データを取得して保存する。実行部１３５は、処理要求に基づいてデータ処理を実行する。復元部１３６は、実行部１３５によるデータ処理の処理結果が異常である場合に、保存部１３４によって保存された保存データに基づいて第三者サーバ７０に外部データをデータ処理の実行前の状態に復元させる。これにより、外部との情報の整合性を保つことができる。

また、保存部１３４は、処理要求に対応するデータ処理に対し、かかるデータ処理の処理対象となる外部データおよび内部データが関連付けられたライブラリ情報１２１に基づいて第三者サーバ７０から外部データを取得して保存する。これにより、データ処理とその処理対象となる各データおよびＤＢとの関連性を容易に把握することができる。また、処理要求に対応するデータ処理の内容が管理外の外部データへのアクセスを含む場合を瞬時に判定することができる。

また、復元部１３６は、実行部１３５がデータ処理として内部データおよび外部データを新規に登録する登録処理を実行し、かかる登録処理の処理結果が異常である場合に、新規の外部データを識別する固有ＩＤ（「識別情報」の一例に相当）を第三者サーバ７０から取得済みであるならば、かかる第三者サーバ７０に対して固有ＩＤおよびかかる固有ＩＤに対応する外部データを削除させる削除要求を送信する。これにより、登録処理が異常終了した場合であっても、内部データおよび外部データの間で整合性を保つことができる。

また、保存部１３４は、実行部１３５がデータ処理として内部データおよび外部データを更新する更新処理を実行する場合に、処理対象となる外部データを更新処理が実行される前に第三者サーバ７０から取得して保存する。また、復元部１３６は、実行部１３５によって実行された更新処理の処理結果が異常である場合に、外部データは第三者サーバ７０によって更新済みであるならば、かかる第三者サーバ７０に対し、保存部１３４によって保存された外部データの内容で外部データを更新させる更新要求を送信する。これにより、更新処理が異常終了した場合であっても、内部データおよび外部データの間で整合性を保つことができる。

また、保存部１３４は、実行部１３５がデータ処理として内部データおよび外部データを削除する削除処理を実行する場合に、処理対象となる外部データを削除処理が実行される前に第三者サーバ７０から取得して保存する。また、復元部１３６は、実行部１３５によって実行された削除処理の処理結果が異常である場合に、外部データは第三者サーバ７０によって削除済みであるならば、かかる第三者サーバ７０に対し、保存部１３４によって保存された外部データの内容で外部データを新規に登録させる登録要求を送信し、かかる登録要求に対して発行される新規の外部データの固有ＩＤを削除処理が実行される前の内部データへ関連付ける。これにより、削除処理が異常終了した場合であっても、内部データおよび外部データの間で整合性を保つことができる。

また、実行部１３５は、実行したデータ処理の処理結果が正常である場合に、保存部１３４による保存データを削除する。これにより、記憶領域資源などのシステムリソースを浪費することなく繰り返し利用することができる。したがって、可用性の高いシステムを提供することができる。

以上、本願の実施形態を図面に基づいて詳細に説明したが、これは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

１ 広告情報管理システム
１０ 端末装置
２０ ウェブサーバ
３０−１，３０−２ 広告配信装置
４０ ＤＢサーバ
４１ 内部ＤＢ群
５０ ＡＰＩサーバ
７０ 第三者サーバ
７１ 外部ＤＢ群
１００ 広告情報管理装置
１１０ 通信部
１２０ 記憶部
１２１ ライブラリ管理情報
１２２ 保存情報
１３０ 制御部
１３１ 収集部
１３２ 受付部
１３３ 判別部
１３４ 保存部
１３５ 実行部
１３６ 復元部

Claims (8)

1. 一の事業者が運用する情報管理装置であって、
   データ処理に関する処理要求を受け付ける受付部と、
   前記処理要求に対応する前記データ処理の内容が、前記一の事業者以外の他の事業者が運用する外部装置によって管理され、アクセス手順が制限された外部データへのアクセスを含む場合に、前記外部装置から前記アクセス手順に沿って前記外部データを取得して保存する保存部と、
   前記処理要求に基づいて前記データ処理を実行する実行部と、
   前記実行部による前記データ処理の処理結果が異常である場合に、前記アクセス手順に沿いつつ、前記保存部によって保存された保存データに基づいて前記外部装置に前記外部データを前記データ処理の実行前の状態に復元させる復元部と
   を備えることを特徴とする情報管理装置。
2. 前記保存部は、
   前記処理要求に対応する前記データ処理に対し、該データ処理の処理対象となる前記外部データおよび内部データが関連付けられたライブラリ情報に基づいて前記外部装置から前記外部データを取得して保存する
   ことを特徴とする請求項１に記載の情報管理装置。
3. 前記復元部は、
   前記実行部が前記データ処理として前記内部データおよび前記外部データを新規に登録する登録処理を実行し、該登録処理の処理結果が異常である場合に、新規の前記外部データを識別する識別情報を前記外部装置から取得済みであるならば、該外部装置に対して前記識別情報および該識別情報に対応する前記外部データを削除させる削除要求を送信する
   ことを特徴とする請求項２に記載の情報管理装置。
4. 前記保存部は、
   前記実行部が前記データ処理として前記内部データおよび前記外部データを更新する更新処理を実行する場合に、処理対象となる前記外部データを前記更新処理が実行される前に前記外部装置から取得して保存し、
   前記復元部は、
   前記実行部によって実行された前記更新処理の処理結果が異常である場合に、前記外部データは前記外部装置によって更新済みであるならば、該外部装置に対し、前記保存部によって保存された前記外部データの内容で前記外部データを更新させる更新要求を送信する
   ことを特徴とする請求項２または３に記載の情報管理装置。
5. 前記保存部は、
   前記実行部が前記データ処理として前記内部データおよび前記外部データを削除する削除処理を実行する場合に、処理対象となる前記外部データを前記削除処理が実行される前に前記外部装置から取得して保存し、
   前記復元部は、
   前記実行部によって実行された前記削除処理の処理結果が異常である場合に、前記外部データは前記外部装置によって削除済みであるならば、該外部装置に対し、前記保存部によって保存された前記外部データの内容で前記外部データを新規に登録させる登録要求を送信し、該登録要求に対して発行される新規の前記外部データの識別情報を前記削除処理が実行される前の前記内部データへ関連付ける
   ことを特徴とする請求項２、３または４に記載の情報管理装置。
6. 前記実行部は、
   実行した前記データ処理の処理結果が正常である場合に、前記保存部による保存データを削除する
   ことを特徴とする請求項１〜５のいずれか一つに記載の情報管理装置。
7. 一の事業者が運用する情報管理装置を用いた情報管理方法であって、
   データ処理に関する処理要求を受け付ける受付工程と、
   前記処理要求に対応する前記データ処理の内容が、前記一の事業者以外の他の事業者が運用する外部装置によって管理され、アクセス手順が制限された外部データへのアクセスを含む場合に、前記外部装置から前記アクセス手順に沿って前記外部データを取得して保存する保存工程と、
   前記処理要求に基づいて前記データ処理を実行する実行工程と、
   前記実行工程による前記データ処理の処理結果が異常である場合に、前記アクセス手順に沿いつつ、前記保存工程によって保存された保存データに基づいて前記外部装置に前記外部データを前記データ処理の実行前の状態に復元させる復元工程と
   を含むことを特徴とする情報管理方法。
8. 一の事業者が運用する情報管理装置であるコンピュータに、
   データ処理に関する処理要求を受け付ける受付手順と、
   前記処理要求に対応する前記データ処理の内容が、前記一の事業者以外の他の事業者が運用する外部装置によって管理され、アクセス手順が制限された外部データへのアクセスを含む場合に、前記外部装置から前記アクセス手順に沿って前記外部データを取得して保存する保存手順と、
   前記処理要求に基づいて前記データ処理を実行する実行手順と、
   前記実行手順による前記データ処理の処理結果が異常である場合に、前記アクセス手順に沿いつつ、前記保存手順によって保存された保存データに基づいて前記外部装置に前記外部データを前記データ処理の実行前の状態に復元させる復元手順と
   を実行させることを特徴とする情報管理プログラム。

Images