(57)【要約】【課題】  情報処理サービスが他の情報処理サービスから入力されるデータに対し、それぞれの情報処理サービスが個別の処理要求に従って情報処理してそのログを記録する場合、それらのログを関連付けて監査させることができなかった。【解決手段】  情報処理サービスは、他の情報処理サービスから入力データを受け取る際に、当該入力データを識別する入力識別情報を発行して他の情報処理サービスに送信し、当該入力データに対する情報処理のログにその入力識別情報を関連付けて保存する。さらに、情報処理サービスは、他の情報処理サービスから、入力識別情報を含む監査要求を受け付け、その入力識別情報と関連付いた情報処理のログを他の情報処理サービスに監査させる。【選択図】  図３
2013218474.tif 000002
【特許請求の範囲】
【請求項１】
情報処理を行う際にログを記録し、他の情報処理サービスから入力データを受け付ける情報処理サービスであって、
他の情報処理サービスから受信する入力データを識別する入力識別情報を生成して、該入力識別情報を該他の情報処理サービスに送信し、該入力識別情報と該入力データとを関連付けて記録する入力データ記録手段（３０２、Ｓ６０６、Ｓ６０７）と、
前記入力データに対する情報処理のログを生成して、前記入力識別情報と関連付けて記録するログ記録手段（３０４、Ｓ６０９）と、
前記他の情報処理サービスから前記入力識別情報を受信して、受信した該入力識別情報と関連付いた前記情報処理のログの少なくとも一部を、該他の情報処理サービスに送信するログ送信手段（３０５、Ｓ６１２）と、
を備えることを特徴とする情報処理サービス（３００）。
【請求項２】
記録する項目やデータ形式を定めた複数のログ規格のうち、どのログ規格に従ってログを記録するかを、前記他の情報処理サービスとの間で決定し、決定したログ規格を、該他の情報処理サービスの識別情報と関連付けて記録するログ規格決定手段（３０６）とをさらに備え、
前記ログ記録手段（３０４、Ｓ１００３、Ｓ１００４）は、前記ログ規格決定手段が記録したログ規格に基づいてログを記録すること、
を特徴とする請求項１に記載の情報処理サービス（３００）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理を行う際にログを記録する情報処理サービスに関し、詳しくは、他の情報処理サービスと連携して、他の情報処理サービスが持つログに関連するログを、他の情報処理サービスに監査させることを可能にする情報処理サービスに関する。
【背景技術】
【０００２】
近年、インターネット上で、様々な機能を実現する情報処理サービスが提供されている。そのようなサービスの中には、サービス同士が連携するものや、社内ＬＡＮ等のネットワークにあるディジタル複合機（Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｅｒｉｐｈｅｒａｌ、以下ＭＦＰとする。）などと連携するサービスもある。一例として、プリントサービスからの文書取得要求に応じて文書を入稿する文書管理サービスと、入稿された文書をＭＦＰからの要求に応じて印刷するプリントサービスとが連携するといった形態が挙げられる。
【０００３】
しかし、サービス同士またはサービスと機器とが連携した場合、連携する処理に関する操作のログが、それぞれのサービスや機器で別々に記録されることになる。このため、情報漏洩や不正操作がないかを確認する目的で、操作のログを監査しようとした場合、各サービスや機器で別々にログを監査する必要があった。さらに、監査の際、それぞれで管理されているログ同士を関連付けて、一元的に監査するということができなかった。
【０００４】
これに対し、ＭＦＰで行われた処理のログと、ウェブアプリケーションサーバで行われた処理のログを関連付ける方法が発明されている（例えば、特許文献１参照）。特許文献１に記載の方法では、ＭＦＰから処理要求を受け付けたサーバにおいて、その処理要求に対するセッションの識別情報を発行する。そして、サーバ装置は、その処理要求に応じて実行した処理のログとその識別情報を関連付けて管理する。さらに、ＭＦＰはその識別情報をサーバから取得し、処理要求に応じてＭＦＰが実行した処理のログとその識別情報を関連付けて管理する。監査の際は、関連付いている識別情報を元に、それぞれのログを対応付けるというものであった。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−１３０３４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
前述のプリントサービスと文書管理サービスとの連携形態では、文書管理サービスがプリントサービスからの要求に応じて行う入稿のログと、プリントサービスがＭＦＰからの要求に応じて行う印刷のログとは、各サービスで別々に記録されることになる。このとき、これら入稿と印刷といった処理は、一度の処理要求でなされる処理ではないため、特許文献１の方法では、それらの処理のログを関連付けることができなかった。すなわち、情報処理サービスが他の情報処理サービスから入力されるデータに対し、それぞれの情報処理サービスが個別の処理要求に従って情報処理してそのログを記録する場合、それらのログを関連付けることができなかった。このため、情報処理サービスが、他の情報処理サービスが持つログと関連するログを、他の情報処理サービスに監査させるということはできなかった。
【０００７】
本発明は、上記の課題を解決するためになされたもので、本発明の目的は、情報処理サービスが、他の情報処理サービスから入力されたデータに対する情報処理のログを、他の情報処理サービスが持つログと関連付けて監査させる仕組みを提供することである。
【課題を解決するための手段】
【０００８】
上述した課題を解決するために、本発明は、情報処理を行う際にログを記録し、他の情報処理サービスから入力データを受け付ける情報処理サービスであって、他の情報処理サービスから受信する入力データを識別する入力識別情報を生成して、該入力識別情報を該他の情報処理サービスに送信し、該入力識別情報と該入力データとを関連付けて記録する入力データ記録手段（３０２、Ｓ６０６、Ｓ６０７）と、前記入力データに対する情報処理のログを生成して、前記入力識別情報と関連付けて記録するログ記録手段（３０４、Ｓ６０９）と、前記他の情報処理サービスから前記入力識別情報を受信して、受信した該入力識別情報と関連付いた前記情報処理のログの少なくとも一部を、該他の情報処理サービスに送信するログ送信手段（３０５、Ｓ６１２）とを備えることを特徴とする情報処理サービス（３００）とした。
【発明の効果】
【０００９】
本発明により、情報処理サービスが、他の情報処理サービスから入力されたデータに対する情報処理のログを、他の情報処理サービスが持つログと関連付けて、他の情報処理サービスに監査させることが可能となる。したがって、他の情報処理サービスが、当該データに関する情報処理のログを一元的に監査することができるようになる。
【図面の簡単な説明】
【００１０】
【図１】本発明の情報処理サービスを提供するサーバ群を含むシステムの全体図である。
【図２】サーバ群の各サーバの内部構成を示すブロック図である。
【図３】システム全体のソフトウェア構成を示す図である。
【図４】入稿データ記憶部に保存される入稿データの例である。
【図５】ジョブログ記憶部に保存されるジョブログデータの例である。
【図６】プリントサービスが処理要求を受信した際の動作を示すフローチャートである。
【図７】実施例２におけるプリントサービスのソフトウェア構成を示す図である。
【図８】連携情報記憶部に保存される連携情報の例である。
【図９】サービス連携受付部の動作を示すフローチャートである。
【図１０】実施例２におけるジョブログ生成・保存処理の詳細ステップを示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１２】
（実施例１）
まず、本発明の第１の実施形態について説明する。
【００１３】
図１は、本発明に関わるシステム全体のネットワーク構成図である。図１において、１０１はプリントサービス、１０２は文書管理サービスを提供するサーバ群である。１１０はＭＦＰ、１２０はＰＣである。また、１５０はインターネットであり、１６０は企業内ネットワーク等のＬＡＮである。なお、ＭＦＰ１１０やＰＣ１２０は複数あっても良い。
【００１４】
図２は、サーバ群１０１や１０２を形成している各サーバの内部構成を示すブロック図である。
【００１５】
ＣＰＵ２１１を含む制御部２１０は、サーバ群１０１の各サーバの動作を制御する。ＣＰＵ２１１は、ＲＯＭ２１２やＨＤＤ２１４に記憶された制御プログラムを読み出して読取制御や送信制御などの各種制御処理を実行する。ＲＡＭ２１３は、ＣＰＵ２１１の主メモリ、ワークエリアなどの一時記憶領域として用いられる。ＨＤＤ２１４は、各種プログラムやデータを記憶する。
【００１６】
ネットワークＩ／Ｆ２１５は、制御部２１０をネットワークに接続し、ネットワーク上の別の装置との情報の送受信を行う。
【００１７】
なお、２１６は、制御部２１０内の各ブロックを接続するバスである。
【００１８】
図３は、本発明に関わるシステム全体のソフトウェア構成例を示す図である。
【００１９】
３００は、サーバ群１０１によって提供されるプリントサービスである。プリントサービス３００の内部の詳細なソフトウェア構成例については後述する。
【００２０】
３２０は、サーバ群１０２によって提供される文書管理サービスである。文書管理サービス３２０は、文書ファイルを保存・管理する機能を持ち、主にウェブブラウザ３３０を介して、ユーザから文書取得や文書登録の要求を受け付ける。また、文書に対して行われた操作を操作ログとして記録する機能を備え、特に、プリントサービス３００からの文書取得要求に対する処理をした際には、プリントサービス３００から渡される入稿ＩＤ（後述する）を、その処理のログに関連付けて保存する。さらに、文書管理サービス３２０は、ウェブブラウザ３３０を介してユーザからの監査要求を受け付け、指定された文書に関して記録している操作ログをユーザに提示する機能も備えるものとする。なお、監査対象の文書の操作ログに、プリントサービス３００からの文書取得要求の操作ログがある場合、文書管理サービス３２０は、そのログに関連付く入稿ＩＤを用いて、プリントサービス３００に監査要求を行い、関連する操作ログを取得する。そして、文書管理サービス３２０は、プリントサービス３００から取得した操作ログと自身が持つ操作ログとを一元的にユーザに提示する。
【００２１】
３３０は、ＰＣ１２０上で動作するウェブブラウザである。ウェブブラウザ３３０は、プリントサービス３００や文書管理サービス３２０にアクセスして、各サービスによって提供されるＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を表示する。表示されたＧＵＩをユーザが操作することにより、ウェブブラウザ３３０は、各サービスに処理要求を行う。
【００２２】
３４０は、ＭＦＰ１１０上で動作するプリントアプリケーションである。プリントアプリケーション３４０は、ユーザの操作に応じてプリントサービス３００にアクセスして、ユーザが印刷可能な入稿文書の一覧を取得し、ＭＦＰ１１０の操作パネル上に表示する。そして、その操作パネル上でユーザが印刷したい文書を選択することにより、プリントアプリケーション３４０は、選択された文書の印刷要求をプリントサービス３００に行って印刷データを取得し、その印刷データをＭＦＰ１１０で印刷する。
【００２３】
次に、文書管理サービス３２０と連携するプリントサービス３００のソフトウェア構成について説明する。
【００２４】
プリントサービス３００のリクエスト処理部３０１は、文書管理サービス３２０やＰＣ１２０上のウェブブラウザ３３０やＭＦＰ１１０上のプリントアプリケーション３４０などからの要求を受信する。リクエスト処理部３０１は、認証要求を受け取った場合には、要求に含まれるユーザを識別するためのユーザＩＤおよびパスワードを解釈し、顧客情報記憶部３１１内の情報と照合を行い、プリントサービス３００の正規な利用者であるかの確認を行う。また、リクエスト処理部３０１は、必要に応じて入稿処理部３０２やプリント処理部３０３に、受信した処理要求を渡す。
【００２５】
入稿処理部３０２は、リクエスト処理部３０１が、ウェブブラウザ３３０などから、文書管理サービス３２０が持つ文書を入稿するための入稿要求を受信した場合に、文書管理サービス３２０に対して文書取得要求を行い、文書を取得する。取得した文書は、入稿文書として入稿データに含められ、入稿データ記憶部３１２に保存される。入稿データの例を図４に示す。図４において、入稿ＩＤは、入稿データを識別するために、入稿処理部３０２が発行する識別情報である。なお、この入稿ＩＤは、文書取得要求を行う際に発行され、文書取得要求に含められて文書管理サービス３２０に渡される。入稿元識別情報は、入稿元の文書管理サービスを識別するための情報であり、本実施例においては、完全修飾ドメイン名（Ｆｕｌｌｙ  Ｑｕａｌｉｆｉｅｄ  Ｄｏｍａｉｎ  Ｎａｍｅ、以下ＦＱＤＮとする。）を用いるものとする。ただし、ＩＰアドレスやＵＲＬなど、入稿元の文書管理サービスを識別することができるものであれば、特にこれに限定するものではない。文書データは、入稿文書のバイナリデータである。
【００２６】
プリント処理部３０３は、リクエスト処理部３０１がプリントアプリケーション３４０から印刷要求を受信した場合に動作し、印刷要求で指定された入稿データを入稿データ記憶部３１２から読み出す。そして、プリント処理部３０３は、読み出した入稿データに含まれる文書データから印刷データを生成し、プリントアプリケーション３４０に送信する。
【００２７】
ジョブログ生成部３０４は、印刷要求に対するプリントのジョブログを生成し、ジョブログ記憶部３１３に保存する。ジョブログの例を図５に示す。図５において、ジョブログＩＤは、ジョブログを識別するための識別情報であり、ジョブログ生成部３０４が発行する。印刷者、印刷デバイス、印刷日時は、それぞれ、印刷を行ったユーザ名、印刷デバイス名、印刷要求が行われた日時であり、これらの情報は、ジョブログ生成部３０４が、プリント処理部３０３から受け取る。画像データは、ジョブログ生成部３０４が、プリント処理部３０３から印刷データを受け取り、それを後で監査しやすい画像形式に変換したバイナリデータである。入稿ＩＤは、印刷対象の入稿データの入稿ＩＤであり、これもジョブログ生成部３０４がプリント処理部３０３から受け取る。
【００２８】
ジョブログ監査部３０５は、リクエスト処理部３０１が文書管理サービス３２０から監査要求を受信した場合に動作し、指定された入稿ＩＤと関連付いているジョブログをジョブログ記憶部３１３から検索して、文書管理サービス３２０に送信する。
【００２９】
顧客情報記憶部３１１は、プリントサービス３００が管理するユーザの情報を格納しており、ユーザＩＤと認証用のパスワードなどの情報を持つ。
【００３０】
次に、プリントサービス３００が処理要求を受け付けた際の動作について、図６のフローチャートを用いて説明する。図６のフローチャートに示す各ステップは、サーバ群１０１のＣＰＵ２１１が制御プログラムを実行することで、図３に示したプリントサービス３００の各処理部が動作することにより実現される。
【００３１】
ステップＳ６０１では、リクエスト処理部３０１が、文書管理サービス１０２やＭＦＰ１１０、ＰＣ１０２から処理要求を受信し、その内容を判定する。
【００３２】
処理要求が、ユーザＩＤ、パスワードからなるプリントサービス３００に対する認証情報を含む認証要求である場合には、処理はステップＳ６０２へ遷移する。処理要求が、プリントサービス３００への認証情報と、文書管理サービス３２０への認証情報と、文書管理サービス３２０のＵＲＬと、文書管理サービス３２０上の文書の文書ＩＤを含む入稿要求である場合には、処理はステップＳ６０５へ遷移する。処理要求が、プリントサービス３００への認証情報と、入稿ＩＤを含む監査要求である場合には、処理はステップＳ６１１へ遷移する。なお、処理要求が上記以外の場合には、リクエスト処理部３０１は、処理要求に含まれるセッション識別情報を、認証済みセッションとして一時的に保存しているセッション識別情報に一致するかを判定する。一致している場合には、要求元に応じたＧＵＩ情報を応答する。このとき、要求元がプリントアプリケーション３４０である場合には、リクエスト処理部３０１は、認証されているユーザが入稿した文書の一覧をプリントアプリケーション３４０に表示させる。そして、ユーザにその一覧の中から印刷したい文書を選択させることによって、リクエスト処理部３０１は、選択された文書の入稿ＩＤを含む印刷要求を受信する。このとき、処理はステップＳ６０８に遷移する。
【００３３】
処理要求の中にセッション識別情報がないか、一時的に保存しているセッション識別情報に一致しない場合には、リクエスト処理部３０１は、認証用のログイン画面を要求元に一旦返し、ユーザの操作を受け付けて送られてくる認証要求を受信する。
【００３４】
［認証要求に対する処理］
ステップＳ６０２では、リクエスト処理部３０１が、受信した認証要求に含まれるユーザＩＤとパスワードを、顧客情報記憶部３１１内の情報と照合し、一致するものがあるかどうかを判定する。一致するものがある場合には、処理はステップＳ６０４へ遷移する。一致するものがない場合には、処理はステップＳ６０３へ遷移する。
【００３５】
ステップＳ６０３では、リクエスト処理部３０１が認証ＮＧの結果を要求元に応答し、認証要求に対する処理を終了する。
【００３６】
ステップＳ６０４では、リクエスト処理部３０１が認証ＯＫの結果と、以後の通信で用いるセッション識別情報とを要求元に応答し、認証要求に対する処理を終了する。このセッション識別情報は、リクエスト処理部３０１が、以後の処理要求が認証済みであるかを識別するために、一時的に記憶しておくものとする。また、要求元は、以後の処理要求にこのセッション識別情報を含めるものとする。
【００３７】
［入稿要求に対する処理］
ステップＳ６０５では、入稿処理部３０２が、受信した入稿要求に含まれる文書管理サービス１０２の文書取得用アドレスからＦＱＤＮを抽出すると共に、入稿ＩＤを発行し、それらの情報で初期化された入稿データを生成する。
【００３８】
ステップＳ６０６では、入稿処理部３０２が、受信した入稿要求に含まれる文書管理サービス１０２への認証情報と、取得対象の文書ＩＤと、発行した入稿ＩＤとを用いて、文書管理サービス１０２へ文書取得要求を行う。このとき、入稿ＩＤを文書管理サービス１０２に送信する目的は、文書管理サービス１０２の文書取得要求のログに、この入稿ＩＤを関連付けさせ、プリントサービス１０１への監査時に入稿ＩＤを指定させるためである。
【００３９】
ステップＳ６０７では、入稿処理部３０２が、文書管理サービス１０２から取得した文書データを入稿文書として、ステップＳ６０５で初期化した入稿データに含めて入稿データ記憶部３１２に保存し、入稿要求に対する処理を終了する。
【００４０】
［印刷要求に対する処理］
ステップＳ６０８では、プリント処理部３０３が、印刷要求で指定された入稿ＩＤを持つ入稿データを入稿データ記憶部３１２から読み出し、その入稿データに含まれる文書データから印刷データを生成する。印刷要求には、入稿ＩＤの他に、プリントアプリケーション３４０が動作しているＭＦＰの設定情報や、印刷設定情報なども含まれるものとし、それらの少なくとも一部は、ジョブログ生成部３０４によって、ジョブログに記録される。
【００４１】
ステップＳ６０９では、ジョブログ生成部３０４が、印刷要求に含まれる情報と印刷データと入稿ＩＤを、プリント処理部３０３から受け取り、ジョブログを生成する。生成したジョブログは、入稿ＩＤと関連付けられてジョブログ記憶部３１３に保存される。
【００４２】
ステップＳ６１０では、プリント処理部３０３が、ステップＳ６０８で生成した印刷データを、要求元であるＭＦＰ１１０に送信し、印刷要求に対する処理を終了する。
【００４３】
［監査要求に対する処理］
ステップＳ６１１では、ジョブログ監査部３０５が、監査要求で指定された入稿ＩＤを持つ入稿データを入稿データ記憶部３１２から検索する。
【００４４】
ステップＳ６１２では、ジョブログ監査部３０５が、ステップＳ６１１で検索されたジョブログを、要求元である文書管理サービス１０２に送信し、監査要求に対する処理を終了する。
【００４５】
以上のように、本実施例では、プリントサービスが文書管理サービスから入稿文書を取得する際、入稿ＩＤを文書管理サービスに渡し、さらに、その入稿文書の印刷のログにその入稿ＩＤを関連付けるようにした。そして、文書管理サービスから入稿ＩＤを受け取って、その入稿ＩＤと関連付いた印刷のログを文書管理サービスに監査させるようにした。これにより、文書管理サービスが記録している入稿文書に対する処理のログと、プリントサービスが記録している入稿文書に対する処理のログとを関連付けて、文書管理サービスに一元的に監査させることが可能となる。
【００４６】
（実施例２）
次に、本発明の第２の実施形態について説明する。第２の実施形態は、プリントサービスが、記録するログの規格について文書管理サービスと事前に取り決めを行い、それに従ってログを記録し、そのログを文書管理サービスに監査させるものである。
【００４７】
なお、実施例２では、実施例１の図３に示すプリントサービス３００のソフトウェア構成とジョブログ生成部３０４の動作以外については、実施例１と共通であるため、それらの説明は省略し、差異のある部分についてのみ説明する。
【００４８】
図７は、実施例２におけるプリントサービス３００のソフトウェア構成例を示す図である。図７において、実施例１の図３と一致する部分は同一の符号を用い、その説明は省略する。
【００４９】
サービス連携受付部３０６は、リクエスト処理部３０１が、文書管理サービス３２０から、サービス識別情報とログ規格情報とを含むサービス連携要求を受信した場合に、その要求を受諾するか否かを判断する。判断は、サービス連携要求に含まれるログ規格情報で指定されるログ規格が、プリントサービス３００が取得可能なログ規格であるかどうかに基づいて行われる。要求を受諾する場合、サービス連携受付部３０６は、連携を受諾する文書管理サービス３２０の情報を、サービス連携情報として、連携情報記憶部３１４に保存する。サービス連携情報の例を図８に示す。図８において、サービス識別情報は、連携する文書管理サービスを識別するための情報であり、実施例１における入稿元識別情報と同等であるため、説明は省略する。ログ規格は、ログとして記録する属性の種類や、属性の表現形式などに応じて、複数のパターンがあるものとし、各パターンに応じて固有の識別情報を持つものとする。本実施例では、この識別情報をログ規格情報とする。
【００５０】
サービス連携受付部３０６の動作について、図９のフローチャートを用いて説明する。図９のフローチャートに示す各ステップは、サーバ群１０１のＣＰＵ２１１が制御プログラムを実行することで実現される。
【００５１】
ステップＳ９０１では、サービス連携要求に含まれるログ規格情報で指定されたログ規格が、プリントサービス３００で取得可能なログ規格か否かを、サービス連携受付部３０６が判断する。取得可能なログ規格である場合、処理はステップＳ９０３へ遷移する。取得不可能なログである場合、処理はステップＳ９０２へ遷移する。
【００５２】
ステップＳ９０２では、サービス連携受付部３０６が、ログ連携不成立の応答を文書管理サービス３２０に返し、サービス連携要求に対する処理を終了する。
【００５３】
ステップＳ９０３では、サービス連携受付部３０６が、サービス連携要求に含まれるサービス識別情報とログ規格情報とを関連付けて、連携情報記憶部３１４に保存する。
【００５４】
ステップＳ９０４では、サービス連携受付部３０６が、ログ連携成立の応答を文書管理サービス３２０に返し、サービス連携要求に対する処理を終了する。
【００５５】
次に、実施例２におけるジョブログ生成部３０４の動作（図６のステップＳ６０９に相当する処理）の詳細について、図１０のフローチャートを用いて説明する。
【００５６】
ステップＳ１００１では、ジョブログ生成部３０４が、プリント処理部３０３から渡される入稿ＩＤを元に、入稿データ記憶部３１２に保存されている入稿データの入稿元識別情報を取得する。
【００５７】
ステップＳ１００２では、ステップＳ１００１で取得した入稿元識別情報と一致するサービス識別情報を持つサービス連携情報が、連携情報記憶部３１４にあるかどうかを、ジョブログ生成部３０４が判定する。一致するサービス連携情報がある場合には、処理はステップＳ１００３へ遷移する。一致するサービス連携情報がない場合には、ジョブログ生成部３０４での処理は終了する。
【００５８】
ステップＳ１００３では、ジョブログ生成部３０４が、ステップＳ１００１で取得した入稿元識別情報と一致するサービス識別情報を持つサービス連携情報のログ規格情報を、連携情報記憶部３１４から取得する。そして、ジョブログ生成部３０４は、取得したログ規格情報のログ規格に基づいて、ジョブログを生成する。
【００５９】
ステップＳ１００４では、ジョブログ生成部３０４が、ステップＳ１００１で生成したジョブログを、プリント処理部３０３から渡される入稿ＩＤと関連付けて、ジョブログ記憶部３１３に保存し、ジョブログ生成部３０４の処理は終了する。
【００６０】
以上のように、本実施例では、プリントサービスは、文書管理サービスとの間で事前に記録するログの規格を決定しておき、それに基づいて印刷のログを記録するようにした。また、プリントサービスは、文書管理サービスからの監査要求に対して、事前に決定したログ規格に基づいて記録したログの情報を応答するようにした。これにより、プリントサービスは、監査可能なログの仕様が異なる様々な文書管理サービスと連携できるようになる。
【００６１】
なお、実施例２では、プリントサービスは、文書管理サービスからログ規格を指定した要求を受信するように記載したが、初めに、プリントサービスで対応可能なログ規格の一覧を応答しておき、その中から文書管理サービスに選択させる方法でも良い。
【００６２】
また、実施例１および実施例２では、情報処理サービスとして、プリントサービスと文書管理サービスを例に用いたが、スキャンサービスや帳票サービスなど、他の機能を提供するサービスであっても良い。
【符号の説明】
【００６３】
３００  プリントサービス
３０２  入稿処理部
３０４  ジョブログ生成部
３０５  ジョブログ監査部
３０６  サービス連携受付部
【図１】
2013218474.tif 000003
【図２】
2013218474.tif 000004
【図３】
2013218474.tif 000005
【図４】
2013218474.tif 000006
【図５】
2013218474.tif 000007
【図６】
2013218474.tif 000008
【図７】
2013218474.tif 000009
【図８】
2013218474.tif 000010
【図９】
2013218474.tif 000011
【図１０】
2013218474.tif 000012