(57)【要約】      （修正有）【課題】自動ワークフロー処理においてサーバ同士の連携を実現し、ユーザが履歴へのアクセス権がない場合に履歴にエラー終了を記録可能なシステムを提供する。【解決手段】サービス提供サーバＢ５５０は、サービス提供サーバＡ５００からダイジェスト認証のチャレンジを受信しＳ１５０６、チャレンジ、秘密鍵、テナントＩＤからダイジェスト認証のレスポンスを作成しＳ１５０９、サービス提供サーバＡ５００へ送信するＳ１５１０。また、サービス提供サーバＡ５００からユーザＩＤを取得しＳ１５１５、ユーザに履歴への書き込み権限があるか否かを判定しＳ１５１６、サービス提供サーバＢ５５０がエラー終了したことを履歴に書き込むＳ１５１７。サービス提供サーバＡ５００は、レスポンスからテナントＩＤを特定して秘密鍵を取得しレスポンスの検証を行いＳ１５１３、さらにテナントＩＤに紐付くユーザＩＤをサービス提供サーバＢ５５０へ返すＳ１５１４。【選択図】図１５Ａ
2016053858.tif 000002
【特許請求の範囲】
【請求項１】
クライアントＰＣ２００、および認証サービスを提供する少なくとも１つ以上のアイデンティティプロバイダ装置と通信可能なサービス提供サーバＡ５００、サービス提供サーバＢ５５０およびサービス提供サーバＣ５６６０が連携するシステムであって、
サービス提供サーバＢ５５０がスケジュールジョブを登録する手段５５３１，５５４１と、サービス提供サーバＡ５００へのアクセス検証に使用される秘密鍵をテナントＩＤに紐付けて保存する秘密鍵保存ステップ１４１２と、サービス提供サーバＡ５００へのアクセスを行うアクセスステップ１５０２と、前記テナントＩＤおよび前記秘密鍵を用いてサービス提供サーバＡ５００へのアクセス検証に必要な検証情報を作成する検証情報作成ステップ１５０８と、
サービス提供サーバＡ５００がサービス提供サーバＡのアクセストークンをテナントＩＤに紐付けて保存するアクセストークン保存ステップ１１０８と、サービス提供サーバＢへのアクセストークンおよび前記サービス提供サーバＢへのアクセストークンのオーナーであるユーザＩＤをテナントＩＤに紐付けて保存するアクセストークン保存ステップ１３１７と、サービス提供サーバＢ５５０からのアクセスの検証を行うための秘密鍵を発行する秘密鍵発行ステップ１４０３と、前記発行した秘密鍵をテナントＩＤに紐付けて保存する秘密鍵保存ステップ１４０４と、サービス提供サーバＢ５５０からのアクセスがどのテナントからのものか特定するテナント特定ステップ１５１１と、前記テナントＩＤおよび秘密鍵を用いてサービス提供サーバＢ５５０からのアクセスの検証を行う検証ステップ１５１３と、前記特定したテナントのテナントＩＤに紐付く前記ユーザＩＤをサービス提供サーバＢ５５０のレスポンスに含めて返すステップ１５１４と、サービス提供サーバＢ５５０がユーザＩＤを取得して該ユーザＩＤのユーザに処理履歴テーブルに対する書き込み権限があるかを判定する権限判定ステップ１５１６と、サービス提供サーバＢ５５０がエラー終了であることを処理履歴テーブルに書き込む処理履歴出力ステップ１５１７と、前記特定したテナントのテナントＩＤに紐付くサービス提供サーバＢのアクセストークンを取得するアクセストークン取得ステップ１５１５と、前記取得したサービス提供サーバＢのアクセストークンを用いてサービス提供サーバＢからデータの取得を行うデータ取得ステップ１５１７と、サービス提供サーバＣへ文書の送信を行う文書送信ステップ１５２２と、を有することを特徴とするシステム。
【請求項２】
処理履歴出力ステップ１５１７は、権限判定ステップ１５１６が書き込み権限がないと判定した場合に権限不足を示すメッセージとともに処理歴テーブルに書き込むことを特徴とする請求項１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザが介在しない自動ワークフロー処理を提供するサービスプロバイダ装置、サービスプロバイダ装置を制御するための制御方法、およびプログラムに関する。
【背景技術】
【０００２】
クラウドプラットフォーム上で業務データの管理や各種処理を行う形態が普及し始めている。ユーザは、クライアントＰＣのブラウザからインターネットを介してクラウドプラットフォームのＷｅｂページにアクセスし、そのＷｅｂページ上で閲覧したい業務データを表示する。例えば、その画面から文書作成指示を行うと、文書生成サーバにリダイレクトされ、文書生成サーバがクラウドプラットフォームにある業務データを取得して文書を生成し、文書をクライアントＰＣ２００やクラウドプラットフォームに送信する。クラウドプラットフォームの代表例として、例えば、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ社のＳａｌｅｓｆｏｒｃｅ  ＣＲＭ（登録商標）がある。
【０００３】
クラウドプラットフォームや文書生成サーバはマルチテナントで動作する。テナントとは、クラウドプラットフォームや文書生成サーバを使用する契約を締結した企業や組織の単位である。マルチテナントで動作するサービスは、１つのシステムで複数のテナントのデータを管理し、あるテナントのデータが別のテナントから参照できないよう各テナントのデータを分離して管理する。自身のテナントのデータのみを参照させるため、クラウドプラットフォームや文書生成サーバはユーザ認証を行う。
【０００４】
クラウドプラットフォームと文書生成サーバが連携を行う場合、ユーザがそれぞれのサーバで認証を行うことなくサーバ間で認証を連携させることが可能である。従来複数のサーバ間で認証を連携させる技術として、ＳＡＭＬ（Ｓｅｃｕｒｉｔｙ  Ａｓｓｅｒｔｉｏｎ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）によるシングルサインオン    （以下ＳＳＯ）  の仕組みがある。ＳＡＭＬのＳＳＯにおいて、ユーザは、認証サービスを提供する側（ＩｄｅｎｔｉｔｙＰｒｏｖｉｄｅｒ、以下ＩｄＰ）、および認証サービスの認証結果を信頼してサービスを提供する側（ＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ、以下ＳＰ）の両方のユーザＩＤを保有している。ユーザがＩｄＰで認証を受けると、ＳＰはその認証結果を信頼して、そのアクセスをＳＰ内で管理するＩＤとして認証する（ＩｄＰ先行）。また、ＩｄＰで認証を受けていない未認証のユーザがＳＰにアクセスしてきた場合、ＳＰは、未認証のユーザを適切なＩｄＰへと誘導し、ＩｄＰで認証させる（ＳＰ先行）。
【０００５】
ＳＡＭＬによるＳＳＯを行う場合、ＩｄＰが保有するＩＤとＳＰが保有するＩＤを対応付け（以下、ユーザマッピングと称する）を行って管理する。特に、ユーザを識別することが不可欠なサービスと文書生成サーバを連携させる場合、ユーザマッピングによるＩＤ管理が必要となる。ユーザを識別することが不可欠なサービスには、文書をＩＤ毎に管理・印刷を行う印刷サービスがある。
【０００６】
従来、複数のサービスがそれぞれ保有するＩＤを連携させる方法が開示されている。特許文献１には、サービス提供サーバがユーザのアクセスを認証サーバへ誘導し、認証サーバとユーザ間で認証情報の登録、認証処理を実行する方法が開示されている。特許文献２には、連携するサービス提供サーバのそれぞれでユーザ識別情報を管理する方法が開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１１−２２１７２９号公報
【特許文献２】特開２０１０−１１３４６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、従来の方法には以下の問題があった。複数のサービス提供サーバの連携によって成立つ自動ワークフローシステム（夜間バッチ印刷など）をクラウド環境で実現する場合、ユーザが介在しないため、通常のユーザを基準とした認証の仕組みを用いることが出来ない。特許文献２のように、連携するサービス提供サーバ間の両方にユーザ名やパスワード等のアカウント情報を保持した場合、他のサービスのアカウント情報を管理しなければならないことになり、不正な成り済ましや情報漏洩等のセキュリティリスクが増大する。
【０００９】
さらに、一方のサービス提供サーバに保持したユーザが他方のサービス提供サーバの処理履歴を記録するテーブルにアクセスする権限がない場合、エラー終了したことを処理履歴に書き込むことができない。
【００１０】
本発明の目的は、夜間バッチ印刷等ユーザが介在することなくサービス提供サーバ同士が連携してスケジュールジョブを実行するシステムにおいて、両サーバにユーザ名やパスワードを保持することなく連携を実現し、さらに、処理履歴を記録するテーブルへのアクセス権がないユーザ権限でスケジュールジョブを実行する場合に、処理履歴にエラー終了を記録可能なシステムを提供することにある。
【課題を解決するための手段】
【００１１】
上記の目的を達成するために、本発明は、
クライアントＰＣ２００、および認証サービスを提供する少なくとも１つ以上のアイデンティティプロバイダ装置と通信可能なサービス提供サーバＡ５００、サービス提供サーバＢ５５０およびサービス提供サーバＣ５６６０が連携するシステムであって、
サービス提供サーバＢ５５０がスケジュールジョブを登録する手段５５３１，５５４１と、サービス提供サーバＡ５００へのアクセス検証に使用される秘密鍵をテナントＩＤに紐付けて保存する秘密鍵保存ステップ１４１２と、サービス提供サーバＡ５００へのアクセスを行うアクセスステップ１５０２と、前記テナントＩＤおよび前記秘密鍵を用いてサービス提供サーバＡ５００へのアクセス検証に必要な検証情報を作成する検証情報作成ステップ１５０８と、
サービス提供サーバＡ５００がサービス提供サーバＡのアクセストークンをテナントＩＤに紐付けて保存するアクセストークン保存ステップ１１０８と、サービス提供サーバＢへのアクセストークンおよび前記サービス提供サーバＢへのアクセストークンのオーナーであるユーザＩＤをテナントＩＤに紐付けて保存するアクセストークン保存ステップ１３１７と、サービス提供サーバＢ５５０からのアクセスの検証を行うための秘密鍵を発行する秘密鍵発行ステップ１４０３と、前記発行した秘密鍵をテナントＩＤに紐付けて保存する秘密鍵保存ステップ１４０４と、サービス提供サーバＢ５５０からのアクセスがどのテナントからのものか特定するテナント特定ステップ１５１１と、前記テナントＩＤおよび秘密鍵を用いてサービス提供サーバＢ５５０からのアクセスの検証を行う検証ステップ１５１３と、前記特定したテナントのテナントＩＤに紐付く前記ユーザＩＤをサービス提供サーバＢ５５０のレスポンスに含めて返すステップ１５１４と、サービス提供サーバＢ５５０がユーザＩＤを取得して該ユーザＩＤのユーザに処理履歴テーブルに対する書き込み権限があるかを判定する権限判定ステップ１５１６と、サービス提供サーバＢ５５０がエラー終了であることを処理履歴テーブルに書き込む処理履歴出力ステップ１５１７と、前記特定したテナントのテナントＩＤに紐付くサービス提供サーバＢのアクセストークンを取得するアクセストークン取得ステップ１５１５と、前記取得したサービス提供サーバＢのアクセストークンを用いてサービス提供サーバＢからデータの取得を行うデータ取得ステップ１５１７と、サービス提供サーバＣへ文書の送信を行う文書送信ステップ１５２２と、を有することを特徴とする。
【発明の効果】
【００１２】
本発明によれば、夜間バッチ印刷等ユーザが介在することなくサービス提供サーバ同士が連携してスケジュールジョブを実行するシステムにおいて、両サーバにユーザ名やパスワードを保持することなく連携を実現し、さらに、処理履歴を記録するテーブルへのアクセス権がないユーザ権限でスケジュールジョブを実行する場合に、処理履歴にエラー終了を記録することが可能となる。
【図面の簡単な説明】
【００１３】
【図１】ネットワーク構成を示す図である。
【図２】本発明の実施の形態に係るハードウェア構成図である。
【図３】本発明の実施の形態に係るサービス提供サーバＡ５００のモジュール構成図である。
【図４】本発明の実施の形態に係るサービス提供サーバＣ５６０のモジュール構成図である。
【図５】本発明の実施の形態に係るサービス提供サーバＢ５５０のモジュール構成図である。
【図６】本発明の実施の形態に係るサービス提供サーバＢ５５０のスケジュールジョブ登録画面の例である。
【図７】本発明の実施の形態に係るサービス提供サーバＢ５５０の登録済みスケジュールジョブ一覧画面の例である。
【図８】本発明の実施の形態に係るサービス提供サーバＡ５００のバッチ印刷情報の設定画面の例である。
【図９】本発明の実施の形態に係るサービス提供サーバＢ５５０の秘密鍵登録画面の例である。
【図１０】本発明の実施の形態に係るサービス提供サーバＡ５００のバッチ印刷情報の例である。
【図１１】本発明の実施の形態に係るクライアントＰＣ２００のブラウザ、サービス提供サーバＡ５００、認証サーバＡ４００が実行するフローである。
【図１２】本発明の実施の形態に係るダイジェスト認証のレスポンスの例である。
【図１３】本発明の実施の形態に係るクライアントＰＣ２００のブラウザ、サービス提供サーバＡ５００、認証サーバＢ４５０が実行するフローである。
【図１４】本発明の実施の形態に係るクライアントＰＣ２００のブラウザ、サービス提供サーバＡ５００、サービス提供サーバＢ５５０が実行するフローである。
【図１５Ａ】本発明の実施の形態に係るサービス提供サーバＡ５００、サービス提供サーバＢ５５０、サービス提供サーバＣ５６０、認証サーバＡ４００が実行するフローである。
【図１５Ｂ】本発明の実施の形態に係るサービス提供サーバＡ５００、サービス提供サーバＢ５５０、サービス提供サーバＣ５６０、認証サーバＡ４００が実行するフローである。
【図１６】本発明の実施の形態に係るダイジェスト認証のチャレンジの例である。
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１５】
図１は、本発明の実施例のシステム構成を示すブロック図である。１００は、Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＬＡＮ１０１）である。複数のＬＡＮ１０１は、ＷＡＮ１００を介することで互いの装置が通信可能になる。
【００１６】
２００はユーザが操作するクライアントＰＣ２００であり、後述するサービス提供サーバＡ５００やサービス提供サーバＢ５５０に対してブラウザ２２０を用いてリクエストを発行する。３００はユーザのアクセスを適切なＩｄＰへと誘導する認証サービス決定サーバである。
【００１７】
４００および４５０はそれぞれ認証を行う認証サーバＡ，Ｂであり、ともにＩｄＰ（アイデンティティプロバイダ装置）として動作する。なお認証サービスは２つに限定されるものではない。どのＩｄＰが実際の認証を行うかはアクセスしてきたユーザによって異なる。
【００１８】
５００や５５０や５６０はそれぞれサービスを提供するサービス提供サーバＡ５００，Ｂ５５０、Ｃ５６０であり、認証されたユーザに対してサービスを提供する。サービス提供サーバＡ５００はクライアントＰＣ２００やサービス提供サーバＢ５５０からのリクエストを受信して文書生成を行う。サービス提供サーバＢ５５０はクライアントＰＣ２００やサービス提供サーバＡ５００からのリクエストに応じて保持するデータの表示・更新等を行う。サービス提供サーバＣ５６０はクライアントＰＣ２００やサービス提供サーバＡ５００からのリクエストを受信して文書印刷を行う。
【００１９】
なお、サービス提供サーバＡ５００，サービス提供サーバＢ５５０，サービス提供サーバＣ５６０は文書生成サービスやクラウドプラットフォーム、文書印刷サービスに限定されるものではなく、別のサービスであってもよい。またクライアントＰＣ２００、認証サービス決定サーバ３００、認証サーバＡ４００、認証サーバＢ４５０、サービス提供サーバＡ５００、サービス提供サーバＢ５５０、サービス提供サーバＣ５６０はそれぞれＷＡＮネットワーク１００およびＬＡＮ１０１を介して接続されている。なおクライアントＰＣ２００およびそれぞれのサーバはそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また同一のＰＣ上に構成されていてもよい。
【００２０】
認証サービス決定サーバ３００、認証サーバＡ４００、サービス提供サーバＡ５００、サービス提供サーバＣ５６０は同じネットワーク内（イントラネット内）に構築されたサーバ群であり、認証サーバＢ４５０、サービス提供サーバＢ５５０は同じネットワーク内（イントラネット内）に構築されたサーバ群となる。
【００２１】
クライアントＰＣ２００はまず、バッチ印刷用のスケジュールジョブを登録するためサービス提供サーバＢ５５０にアクセスする。サービス提供サーバＢ５５０は未認証のユーザアクセスを受け付けると、不図示の認証画面を表示し、ユーザ認証を行う。ユーザを認証すると、バッチ印刷用のスケジュールジョブ登録画面の表示を行う。
【００２２】
図６は、本実施の形態に係るサービス提供サーバＢ５５０がブラウザ２２０に提供するバッチ印刷用のスケジュールジョブ登録画面６０１の例である。スケジュールジョブ登録画面６０１は、スケジュールジョブの名前を設定するジョブ情報設定領域６０２、スケジュールジョブを開始する時刻を設定するジョブ開始時刻設定領域６０３、スケジュールジョブで実行されるバッチ印刷の印刷パラメータを設定する印刷パラメータ設定領域６０４、およびこれらの設定を登録する登録ボタン６０５から成る。
【００２３】
ユーザ（管理者）は、スケジュールジョブ登録画面６０１を操作し、スケジュールジョブを実行したい時刻および印刷パラメータ等を入力して登録ボタン６０５を押す。登録ボタン６０５が押下されると、サービス提供サーバＢ５５０は、指示された設定をテナントごとの管理領域に保存する。保存されたスケジュールジョブに関する各種設定は、サービス提供サーバＢ５５０がブラウザ２２０に提供するスケジュールジョブ一覧画面でいつでも確認可能である。
【００２４】
図７は、本実施の形態に係るサービス提供サーバＢ５５０がブラウザ２２０に提供するスケジュールジョブ一覧画面７０１の例である。一覧表示により、スケジュールジョブの名前７０２やジョブの開始時刻７０３を確認することが出来る。
【００２５】
次にクライアントＰＣ２００は、バッチ印刷用の事前設定を行うためにサービス提供サーバＡ５００にアクセスする。サービス提供サーバＡ５００は未認証のユーザアクセスを受け付けると、不図示の認証画面を表示し、ユーザ認証を行う。ユーザを認証すると、バッチ印刷用の設定画面の表示を行う。
【００２６】
図８は、本実施の形態に係るサービス提供サーバＡ５００がブラウザ２２０に提供するバッチ印刷用の設定画面８０１の例である。バッチ印刷用の設定画面８０１には、サービス提供サーバＡ５００のアクセストークン（以降、サーバＡアクセストークン）をサービス提供サーバＡ５００の管理領域に保存するためのボタン８０２、サービス提供サーバＢ５５０のアクセストークン（以降、サーバＢアクセストークン）をサービス提供サーバＡ５００の管理領域に保存するためのボタン８０３、バッチ印刷要求の検証を行う際に使用する秘密鍵８０４が表示されている。
【００２７】
アクセストークンは、各サービス提供サーバの機能へのアクセスを許可するトークンで、通常、ユーザによる認可操作を経て認証サーバから発行される。ユーザ（管理者）によりボタン８０２、８０３が押下されると、サービス提供サーバＡ５００は、それぞれのサーバから取得したアクセストークンをテナントの識別番号（テナントＩＤ）に紐付けて管理領域へ保存する。なお、秘密鍵８０４については、テナントＩＤ発行時（新規にテナントを登録した時）に生成され、その際テナントＩＤに紐付けて管理済みとする。
【００２８】
さらにクライアントＰＣ２００は、バッチ印刷用の事前設定を行うためにサービス提供サーバＢ５５０にアクセスする。サービス提供サーバＢ５５０における認証手続きは前記と同様である。ユーザ認証済みであれば、秘密鍵登録画面の表示を行う。
【００２９】
図９は、本実施の形態に係るサービス提供サーバＢ５５０がブラウザ２２０に提供する秘密鍵登録画面９０１の例である。ユーザ（管理者）は、秘密鍵入力エリア９０２に対して、前記バッチ印刷用の設定画面８０１に表示された秘密鍵を入力し、登録ボタン９０３を押す。登録ボタン９０３が押下されると、サービス提供サーバＢ５５０は、秘密鍵をテナントごとの管理領域に保存する。
【００３０】
サービス提供サーバＢ５５０はスケジュールジョブの開始時刻になると、スケジュールジョブを開始し、サービス提供サーバＡ５００にバッチ印刷を要求する。サービス提供サーバＡ５００はバッチ印刷の要求を受け付けると、その要求が妥当であるかを検証し、妥当であればサーバＢアクセストークンを使ってサービス提供サーバＢ５５０からデータを取得する。そして生成した文書をサービス提供サーバＣ５６０に送信する。
【００３１】
図２は本実施の形態に係るクライアントＰＣ２００の構成を示す図である。また認証サービス決定サーバ３００、認証サーバＡ４００、認証サーバＢ４５０、サービス提供サーバＡ５００、サービス提供サーバＢ５５０、サービス提供サーバＣ５６０を提供するサーバコンピューターの構成も同様である。このように、本実施形態のクライアントＰＣ２００およびサーバには一般的な情報処理装置のハードウェア構成を適用できる。
【００３２】
図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。
【００３３】
ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。
【００３４】
尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１にインストールされたアプリケーションプログラムである。
【００３５】
図５は、本実施の形態に係るサービス提供サーバＢ５５０のモジュール構成図である。サービス提供サーバＢ５５０は、アクセス制御モジュール５５１、ページ生成モジュール５５２、スケジュールジョブ登録モジュール５５３１，５５４１、スケジュールジョブ情報管理モジュール５５３２，５５４２、スケジュールジョブ実行モジュール５５３３，５５４３、バッチ印刷要求モジュール５５３４，５５４４、秘密鍵管理モジュール５５３５，５５４５、認証情報付加モジュール５５３６，５５４６、業務データ管理モジュール５５３７，５５４７、処理履歴管理モジュール５５３８，５５４８を備える。
【００３６】
サービス提供サーバＢ５５０がアクセスを受け付けると、ユーザのアクセスが認証済みであるか否かをアクセス制御モジュール５５１が判断し、未認証であればページ生成モジュール５５２が認証画面をブラウザ２２０に提供する。認証済みであればサービス提供サーバＢ５５０はサービスを提供する。
【００３７】
スケジュールジョブ登録モジュール５５３１，５５４１はスケジュールジョブを登録する。ジョブ開始時間等のスケジュールジョブ関連情報は、スケジュールジョブ情報管理モジュール５５３２，５５４２によって管理される。
【００３８】
スケジュールジョブの開始時刻になると、スケジュールジョブ実行モジュール５５３３，５５４３がスケジュールジョブを実行する。バッチ印刷要求モジュール５５３４，５５４４はスケジュールジョブ実行モジュール５５３３，５５４３から呼び出され、サービス提供サーバＡ５００に対してバッチ印刷の要求リクエストを行う。サービス提供サーバＡ５００にて前記バッチ印刷リクエストの妥当性検証を行うため、秘密鍵管理モジュール５５３５，５５４５が秘密鍵の保存および取得を行う。そして認証情報付加モジュール５５３６，５５４６が妥当性検証に必要な情報を生成してリクエストに付加する。
【００３９】
サービス提供サーバＢ５５０が業務データ取得のリクエストを受け付けると、業務データ管理モジュール５５３７，５５４７が業務データを取得し、リクエストの発行元に返却する。処理履歴管理モジュール５５３８，５５４８は、処理履歴レコードの挿入あるいは更新要求を受け付けると、処理履歴テーブルにレコードを書き込み、または、レコードを更新する。
【００４０】
また、サービス提供サーバＢ５５０は、スケジュールジョブ登録モジュール５５３１，５５４１、スケジュールジョブ情報管理モジュール５５３２，５５４２、スケジュールジョブ実行モジュール５５３３，５５４３、バッチ印刷要求モジュール５５３４，５５４４、秘密鍵管理モジュール５５３５，５５４５、認証情報付加モジュール５５３６，５５４６、業務データ管理モジュール５５３７，５５４７、処理履歴管理モジュール５５３８，５５４８をテナント毎に管理する。
【００４１】
なお、これらテナント毎に管理されるモジュールは同一のハードディスク（ＨＤ）２１１に記憶されてテナント毎のデータを論理的に分離して管理するようにしてもよいし、ハードディスク（ＨＤ）２１１を分けて物理的に分離して管理するようにしてもよい。また、これらのモジュールは実体としては１つである。サービス提供サーバＢ５５０がテナントＩＤを各モジュールに渡すことで、各モジュールはそのテナント専用の動作を行う。例えば、そのテナント固有のデータ領域のみアクセスが制限される。図５ではこのような意図をふまえてテナント毎にモジュールを記載している。
【００４２】
図３は、本実施の形態に係るサービス提供サーバＡ５００のモジュール構成図である。サービス提供サーバＡ５００は、アクセス制御モジュール５０１、データ取得モジュール５０２、文書生成モジュール５０３、ページ生成モジュール５０４、アクセストークン取得モジュール５０５、バッチ印刷情報管理モジュール５０６、秘密鍵生成モジュール５０７、文書送信モジュール５０８、認証情報検証モジュール５０９、アクセストークン検証モジュール５１０、処理履歴出力モジュール５１１を備える。
【００４３】
サービス提供サーバＡ５００がアクセスを受け付けると、アクセス制御モジュール５０１はアクセスが認証済みかどうかを判断する。アクセスが認証済みであればサービス提供サーバＡ５００はサービスを提供する。サービス提供サーバＡ５００は、サービス提供サーバＢ５５０からのバッチ印刷リクエストに応じてバッチ印刷を行う。バッチ印刷リクエストを受けると、認証情報検証モジュール５０９は、受理したバッチ印刷リクエストを検証する。検証に必要な情報は、あらかじめＨＤ２１１に保存されており、バッチ印刷情報管理モジュール５０６によって管理される。
【００４４】
図１０はＨＤ２１１に保存されたバッチ印刷情報の一例である。後述する秘密鍵およびサーバＢのアクセストークン、リフレッシュトークン、およびトークンのオーナーであるユーザのユーザＩＤが、サービス提供サーバＡ５００のテナントＩＤに紐付けられて保存されている。なお、リフレッシュトークンとは、アクセストークンの期限が切れた際に、再発行を行う際必要になる無期限のトークンである。例では、テナントＩＤ「１０００ＡＡ」と「１００１ＡＡ」の２つのテナントに関するバッチ印刷情報が保存されている。バッチ印刷情報として保存されている秘密鍵は、バッチ印刷リクエストの検証に使用される。具体的な検証方法については後述する。
【００４５】
あらかじめＨＤ２１１に保存されるバッチ印刷情報のうち、秘密鍵については、秘密鍵生成モジュール５０７が生成したものであり、サービス提供サーバＡ５００のテナントＩＤに紐付けて管理されている。また、バッチ印刷情報のうち、サーバＢアクセストークンについては、アクセストークン取得モジュール５０５によりサービス提供サーバＢ５５０から取得される。そしてこちらもサービス提供サーバＡ５００のテナントＩＤに紐付けて管理されている。
【００４６】
データ取得モジュール５０２は、サーバＢアクセストークンを使用してサービス提供サーバＢ５５０から業務データを取得する。文書生成モジュール５０３は、不図示のフォーム管理モジュールが管理するフォームを取得して、データ取得モジュール５０２が取得した業務データとフォームから文書データを生成する。文書送信モジュール５０８は、文書生成モジュール５０３が生成した文書データを、サービス提供サーバＣ５６０に送信する。アクセストークン検証モジュール５１０は、サーバＢアクセストークンの有効期限が切れていないかを判断し、切れている場合にトークンの再取得を行う。処理履歴出力モジュール５１１は、サーバＢアクセストークンを使用してサービス提供サーバＢ５５０に処理履歴を書き込む。
【００４７】
図１１は本実施の形態に係る、ブラウザ２２０、サービス提供サーバＡ５００および認証サーバＡ４００が実行するフローである。本フローは、ブラウザ２２０に表示されるバッチ印刷用の設定画面８０１において、ユーザがサーバＡアクセストークンの設定ボタン８０２を押下することによって始まる（ステップ１１０１）。ステップ１１０２でサービス提供サーバＡ５００は、サーバＡアクセストークンの設定要求を受け付ける。本フロー開始前に、ブラウザ２２０は、ログイン操作によりサービス提供サーバＡ５００へのユーザ認証を済ませており、サービス提供サーバＡ５００の認証セッションＩＤは認証サーバＡ４００により発行済みである。
【００４８】
ステップ１１０３でサービス提供サーバＡ５００は、前記設定要求リクエストからサービス提供サーバＡ５００の認証セッションＩＤを取得する。ステップ１１０４でサービス提供サーバＡ５００は、前記ステップ１１０２で取得した認証セッションＩＤをパラメータに指定して認証サーバＡ４００のアクセストークン取得ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を呼び出す。ステップ１１０５で認証サーバＡ４００は、サービス提供サーバＡ５００からのアクセストークン取得ＡＰＩ呼び出しを受け付け、ステップ１１０６でアクセストークンおよびリフレッシュトークンを発行する。そして、発行したアクセストークンおよびリフレッシュトークンをサービス提供サーバＡ５００に返す。
【００４９】
ステップ１１０７でサービス提供サーバＡ５００は、アクセストークンおよびリフレッシュトークンをＡＰＩの戻り値として受理する。ステップ１１０８でサービス提供サーバＡ５００は、ステップ１１０７で受理したアクセストークンおよびリフレッシュトークンを、ユーザのテナントＩＤに紐付けてＨＤ２１１に保存する。なお、テナントＩＤは、本フロー開始前のログイン完了時に既に特定され、サービス提供サーバＡ５００が識別済みとする。ステップ１１０９でサービス提供サーバＡ５００は、アクセストークンおよびリフレッシュトークンの保存が完了したことを示す保存完了画面を、ブラウザ２２０に返す。ステップ１１１０でブラウザ２２０は、ステップ１１０９にて返された保存完了画面を表示する。以上でブラウザ２２０、サービス提供サーバＡ５００および認証サーバＡ４００が実行するフローが終了する。
【００５０】
図１３は本実施の形態に係る、ブラウザ２２０、サービス提供サーバＡ５００および認証サーバＢ４５０が実行するフローである。本フローは、ブラウザ２２０に表示されるバッチ印刷用の設定画面８０１において、ユーザがサーバＢアクセストークンの設定ボタン８０３を押下することによって始まる（ステップ１３０１）。ステップ１３０２でサービス提供サーバＡ５００は、サービス提供サーバＢ５５０のアクセストークン設定要求を受け付ける。ステップ１３０３でサービス提供サーバＡ５００は、認証サーバＢ４５０へリダイレクトを行う。その際、認証サーバＢ４５０が認可設定要求アプリケーションおよび認可完了後のリダイレクト先を識別できるように、リダイレクトパラメータとして、ＵＲＬにアプリケーションのクライアント識別子およびリダイレクトＵＲＬを付与する。クライアント識別子は認証サーバＢ４５０へのアクセス元がサービス提供サーバＡ５００であることを示す識別ＩＤである。
【００５１】
ステップ１３０４で認証サーバＢ４５０は、不図示の認可画面の表示をブラウザ２２０に返す。ステップ１３０５でブラウザ２２０は、ステップ１３０４にて返された認可画面を表示する。ユーザは、ブラウザ２２０に表示された認可画面に対して、サービス提供サーバＢ５５０のユーザＩＤおよびパスワードを入力し、認可の許可ボタンを押下する。ユーザによる認可ボタン押下を受けて、ステップ１３０６でブラウザ２２０は、認証サーバＢ４５０に対して、サービス提供サーバＡ５００からサービス提供サーバＢ５５０へのアクセス許可要求を行う。
【００５２】
ステップ１３０７で認証サーバＢ４５０は、ブラウザ２２０からの認可要求を受け付ける。ステップ１３０８で認証サーバＢ４５０は、サービス提供サーバＡ５００へリダイレクトを行う。リダイレクト先は、ステップ１３０３でサービス提供サーバＡ５００が認証サーバＢ４５０へのリダイレクトパラメータとして、ＵＲＬに付与したものである。サービス提供サーバＡ５００へのリダイレクトＵＲＬパラメータには認可コードが含まれる。認可コードは、アクセストークンを取得するために使用される、ユーザのアクセス許可を表す短期間のみ有効なトークンである。リダイレクトされたアクセスを受け付けると、ステップ１３０９でサービス提供サーバＡ５００は、認証サーバＢ４５０に対して、サーバＢアクセストークンの取得リクエストを行う。この際サービス提供サーバＡ５００は、リクエストのＵＲＬパラメータとして、リダイレクトのＵＲＬパラメータに含まれていた認可コードを含める。
【００５３】
ステップ１３１０で認証サーバＢ４５０は、サービス提供サーバＡ５００からのサーバＢアクセストークン取得リクエストを受理する。ステップ１３１１で認証サーバＢ４５０は、サーバＢアクセストークンおよびサーバＢリフレッシュトークンを発行する。そして、それらのトークンをサービス提供サーバＡ５００にレスポンスとして返却する。ステップ１３１２でサービス提供サーバＡ５００は、サーバＢアクセストークンおよびサーバＢリフレッシュトークンをレスポンスとして受理する。
【００５４】
ステップ１３１３でサービス提供サーバＡ５００は、認証サーバＢ４５０のＩＤサービスＵＲＬに対してリクエストを送信する。この際サービス提供サーバＡ５００は、リクエストヘッダに、ステップ１３１２で受理したサーバＢアクセストークンを含める。ＩＤサービスＵＲＬとは、認可されたユーザを表すＵＲＬであり、有効なアクセストークンを指定してＩＤサービスＵＲＬにリクエストを送信するとユーザとテナントの情報を取得可能である。ステップ１３１４で認証サーバＢ４５０は、ＩＤサービスＵＲＬに対するリクエストを受理する。ステップ１３１５で認証サーバＢ４５０は、リクエストヘッダに指定されたサーバＢアクセストークンを取得および検証し、サーバＢアクセストークンが有効である場合にサーバＢアクセストークンのオーナーであるユーザのユーザＩＤをレスポンスとして返却する。
【００５５】
ステップ１３１６でサービス提供サーバＡ５００は、ユーザＩＤをレスポンスとして受理する。ステップ１３１７でサービス提供サーバＡ５００は、ステップ１３１２で受理したサーバＢアクセストークン、サーバＢリフレッシュトークン、および、ステップ１３１５で取得したユーザＩＤをサービス提供サーバＡ５００のテナントＩＤに紐付けてＨＤ２１１に保存する。なお、テナントＩＤは、本フロー開始前のログイン完了時に既に特定され、サービス提供サーバＡ５００が識別済みとする。
【００５６】
ステップ１３１８でサービス提供サーバＡ５００は、サーバＢアクセストークンおよびサーバＢリフレッシュトークンの保存が完了したことを示す保存完了画面を、ブラウザ２２０に返す。ステップ１３１９でブラウザ２２０は、ステップ１３１４にて返された保存完了画面を表示する。以上でブラウザ２２０、サービス提供サーバＡ５００および認証サーバＢ４５０が実行するフローが終了する。なお、上記フローはＯａｕｔｈによるアクセストークン取得のフローだが、サービス提供サーバＡ５００がサービス提供サーバＢ５５０にアクセスするために必要な情報が取得できるのであれば他の方法でも構わない。
【００５７】
図１４は本実施の形態に係る、ブラウザ２２０、サービス提供サーバＡ５００およびサービス提供サーバＢ５５０が実行するフローである。本フローは、ブラウザ２２０に表示される不図示の秘密鍵発行画面において、ユーザが秘密鍵発行ボタンを押下することによって始まる（ステップ１４０１）。ステップ１４０２でサービス提供サーバＡ５００は、秘密鍵発行要求を受け付ける。ステップ１４０３でサービス提供サーバＡ５００は、秘密鍵の発行を行う。本実施例における秘密鍵は、ＵＵＩＤとサービス提供サーバＡ５００のテナントＩＤを組み合わせたものとするが、別な内容でも構わない。
【００５８】
ステップ１４０４でサービス提供サーバＡ５００は、ステップ１４０３で発行した秘密鍵を、サービス提供サーバＡ５００のテナントＩＤに紐付けてＨＤ２１１に保存する。なお、テナントＩＤは、本フロー開始前のログイン完了時に既に特定され、サービス提供サーバＡ５００が識別済みとする。ステップ１４０５でサービス提供サーバＡ５００は、ユーザが、ステップ１４０３で発行された秘密鍵を確認するための秘密鍵確認画面８０１を、ブラウザ２２０に返す。ステップ１４０６でブラウザ２２０は、ステップ１４０５にて返された秘密鍵確認画面８０１を表示する。ユーザは、後述する秘密鍵登録画面９０１にて秘密鍵の指定を行うために、表示された秘密鍵をメモもしくはコピーする。
【００５９】
ステップ１４０７でブラウザ２２０は、サービス提供サーバＢが提供する秘密鍵登録画面９０１にアクセスする。必要に応じてユーザ認証を行う。ステップ１４０８でサービス提供サーバＢ５５０は、秘密鍵の登録操作を行うための秘密鍵登録画面９０１を、ブラウザ２２０に返す。ステップ１４０９でブラウザ２２０は、ステップ１４０８にて返された秘密鍵登録画面９０１を表示する。ステップ１４１０でブラウザ２２０は、サービス提供サーバＢ５５０に対して、秘密鍵登録リクエストを発行する。リクエストのＵＲＬパラメータとして秘密鍵が含まれるため、クライアントＰＣ２００とサービス提供サーバＢ５５０間の通信は暗号化されることが望ましい。ステップ１４１１でサービス提供サーバＢ５５０は、ブラウザ２２０からの秘密鍵登録リクエストを受理する。
【００６０】
ステップ１４１２でサービス提供サーバＢ５５０は、ステップ１４１１で受理したリクエストに含まれる秘密鍵を、サービス提供サーバＡ５００のテナントＩＤに紐付けてＨＤ２１１に保存する。なお、テナントＩＤは、あらかじめ不図示の保存画面によりサービス提供サーバＢ５５０に保存済みである。サービス提供サーバＡ５００とサービス提供サーバＢ５５０のテナントＩＤは１対１に紐付いているものとする。また、秘密鍵およびサービス提供サーバＡ５００のテナントＩＤは、サービス提供サーバＢ５５０のテナントごとに別な領域に保存され、別のテナントからはアクセスできないよう管理されていることが望ましい。また、秘密鍵はサービス提供サーバＢ５５０のテナントＩＤが同一であれば、スケジュールジョブが別であっても同じものが使用される。以上でブラウザ２２０、サービス提供サーバＡ５００およびサービス提供サーバＢ５５０が実行するフローが終了する。
【００６１】
図１５Ａおよび図１５Ｂは本実施の形態に係る、サービス提供サーバＡ５００、サービス提供サーバＣ５６０、サービス提供サーバＢ５５０および認証サーバＡ４００が実行するフローである。本フローは、サービス提供サーバＢ５５０のスケジュールジョブ情報管理モジュール５５３２、５５４２が管理するスケジュールジョブの実行開始時間に従って、スケジュールジョブ実行モジュール５５３３、５５４３によりスケジュールジョブが開始されることによって始まる。
【００６２】
ステップ１５０１でサービス提供サーバＢ５５０のスケジュールジョブ実行モジュール５５３３、５５４３は、スケジュールジョブの実行を開始する。スケジュールジョブ実行モジュール５５３３、５５４３は、スケジュールジョブ情報管理モジュール５５３２、５５４２が管理するすべてのスケジュールジョブの実行開始時間を確認し、実行開始時間となったスケジュールジョブの実行を開始する。スケジュールジョブ実行モジュール５５３３、５５４３は、スケジュールジョブの実行を開始すると、バッチ印刷要求モジュール５５３４、５５４４を呼び出し、その後の処理を任せる。
【００６３】
ステップ１５０２でサービス提供サーバＢ５５０のバッチ印刷要求モジュール５５３４、５５４４は、処理履歴管理モジュール５５３８，５５４８にステータス「処理開始」を指定して履歴レコードを書き込むよう要求する。処理履歴管理モジュール５５３８，５５４８は処理履歴テーブルに処理履歴レコードを新規作成し、前記作成した処理履歴レコードのレコードＩＤを返す。
【００６４】
ステップ１５０３でサービス提供サーバＢ５５０のバッチ印刷要求モジュール５５３４、５５４４は、前記処理履歴レコードＩＤをパラメータに指定してサービス提供サーバＡ５００に対してバッチ印刷の要求を行う。バッチ印刷要求はユーザログインを必要としないスケジュールジョブとして実行されるため、通常のログインを経た印刷要求とは異なり、実行の主体はある特定のユーザではなくサービス提供サーバＢ５５０のシステム権限となる。このため、要求を受けるサービス提供サーバＡ５００は、バッチ印刷要求の妥当性をユーザやテナントＩＤから判断することが出来ない。
【００６５】
ステップ１５０４でサービス提供サーバＡ５００のアクセス制御モジュール５０１は、バッチ印刷要求を受け付ける。前述の通り、バッチ印刷要求には認証セッションＩＤ等のユーザを識別するための情報が含まれていないため、後述するステップ１５０５〜１５１３にてバッチ印刷要求を受け付けてよいかどうかの検証を行う。ステップ１５０５でサービス提供サーバＡ５００の認証情報検証モジュール５０９は、サービス提供サーバＢ５５０に対して、ダイジェスト認証のチャレンジを送信する。
【００６６】
図１６は、本実施の形態に係る認証情報検証モジュール５０９が送信するダイジェスト認証のチャレンジの例（ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅレスポンスヘッダの一部）である。ｒｅａｌｍ１７０２にはサービス提供サーバＡ５００のサービス名がセットされている。ａｌｇｏｒｉｔｈｍ１７０３はダイジェスト認証アルゴリズムで「ＳＨＡ−２５６」がセットされている。ｎｏｎｃｅ１７０４には認証情報検証モジュール５０９が生成するワンタイムトークンがセットされている。
【００６７】
ステップ１５０６でサービス提供サーバＢ５５０のアクセス制御モジュール５５１は、ダイジェスト認証のチャレンジを受信し、それを認証情報付加モジュール５５３６、５５４６に渡す。ステップ１５０７でサービス提供サーバＢ５５０の秘密鍵管理モジュール５５３５、５５４５は、ステップ１４１２でＨＤ２１１に保存された秘密鍵を取得する。秘密鍵管理モジュール５５３５、５５４５は、当該のスケジュールジョブを実行しているテナントＩＤを特定し、そのテナントＩＤに紐付けられた秘密鍵を取得する。秘密鍵管理モジュール５５３５、５５４５は、取得した秘密鍵を認証情報付加モジュール５５３６、５５４６に渡す。
【００６８】
ステップ１５０８でサービス提供サーバＢ５５０の認証情報付加モジュール５５３６、５５４６は、あらかじめ不図示の保存画面によりサービス提供サーバＢ５５０のＨＤ２１１に保存されたサービス提供サーバＡ５００のテナントＩＤを取得する。ステップ１５０９でサービス提供サーバＢ５５０の認証情報付加モジュール５５３６、５５４６は、ステップ１５０６でアクセス制御モジュール５５１から渡されたダイジェスト認証のチャレンジ、ステップ１５０７で秘密鍵管理モジュール５５３５、５５４５から渡された秘密鍵、ステップ１５０８で取得したサービス提供サーバＡ５００のテナントＩＤ、等からダイジェスト認証のレスポンスを作成する。
【００６９】
図１２は、本実施の形態に係る認証情報付加モジュール５５３６、５５４６が作成するダイジェスト認証のチャレンジ（Ａｕｔｈｏｒｉｚａｔｉｏｎリクエストヘッダの一部）の例である。ｕｓｅｒｎａｍｅ１２０２にはステップ１５０８で取得したサービス提供サーバＡ５００のテナントＩＤをセットする。ｒｅａｌｍ１２０３およびｎｏｎｃｅ１２０４には、前記ダイジェスト認証のチャレンジに含まれる同項目の値をセットする。ｃｎｏｎｃｅ１８０２には認証情報付加モジュール５５３６、５５４６が生成するワンタイムトークンをセットする。そして、ｒｅｓｐｏｎｓｅ１８０２には、ｕｓｅｒｎａｍｅ１２０２、ｒｅａｌｍ１２０３、ｎｏｎｃｅ１２０４、ｃｎｏｎｃｅ１２０６およびステップ１５０７で秘密鍵管理モジュール５５３５、５５４５から渡された秘密鍵を連結したものをさらにａｌｇｏｒｉｔｈｍ１２０５に指定の「ＳＨＡ−２５６」でダイジェスト化した値をセットする。
【００７０】
ステップ１５１０でサービス提供サーバＢ５５０の認証情報付加モジュール５５３６、５５４６は、サービス提供サーバＡ５００に対して、ステップ１５０９で作成したダイジェスト認証のレスポンスを送信する。この際、認証情報付加モジュール５５３６、５５４６は、ダイジェスト認証のレスポンスとは別に、ステップ１５０８で取得したサービス提供サーバＡ５００のテナントＩＤをＵＲＬパラメータ「ｔｅｎａｎｔ＿ＩＤ」に設定する。ステップ１５１１でサービス提供サーバＡ５００のアクセス制御モジュール５５１は、サービス提供サーバＢ５５０から送信されたダイジェスト認証のレスポンスおよびＵＲＬパラメータを受信する。アクセス制御モジュール５５１は、本ステップ１５１１にて、ＵＲＬパラメータ「ｔｅｎａｎｔ＿ＩＤ」の値を取得し、アクセスがどのテナントからのものかを判定する。
【００７１】
ステップ１５１２でサービス提供サーバＡ５００のバッチ印刷情報管理モジュール５０６は、ステップ１５１１で受信したＵＲＬパラメータ「ｔｅｎａｎｔ＿ＩＤ」の値をキーとして、ＨＤ２１１に保存されたバッチ印刷情報内を検索する。そして、該当のテナントＩＤに紐づく秘密鍵およびユーザＩＤを特定し取得する。そして、バッチ印刷情報管理モジュール５０６は、取得した秘密鍵およびテナントＩＤを認証情報検証モジュール５０９に渡す。
【００７２】
ステップ１５１３でサービス提供サーバＡ５００の認証情報検証モジュール５０９は、ステップ１５１１で受信したダイジェスト認証のレスポンスの妥当性を検証する。認証情報検証モジュール５０９は、ステップ１５１１で受信したダイジェスト認証のレスポンス（Ａｕｔｈｏｒｉｚａｔｉｏｎリクエストヘッダ）のｕｓｅｒｎａｍｅ１８０２、ｒｅａｌｍ１８０３、ｎｏｎｃｅ１８０４、ｃｎｏｎｃｅ１８０６およびステップ１５１２で渡された秘密鍵を、認証情報付加モジュール５５３６、５５４６でのレスポンス生成時と同じ方法で結合し、ａｌｇｏｒｉｔｈｍ１８０５に指定された「ＳＨＡ−２５６」でダイジェスト化する。認証情報検証モジュール５０９は、そのダイジェストかされた値と、ダイジェスト認証のレスポンスのｒｅｓｐｏｎｓｅ１８０７の値とを比較して、一致するかで妥当性を検証する。一致すれば妥当であるとみなす。ダイジェスト認証のレスポンスが妥当と判断された場合、ステップ１５１４に遷移する。レスポンスが不正と判断された場合、サービス提供サーバＡ５００のページ生成モジュール５０４はエラーレスポンスを生成し、サービス提供サーバＢ５５０へ送信する。この場合、バッチ印刷のスケジュールジョブはエラー終了する。
【００７３】
ステップ１５１４でサービス提供サーバＡ５００のページ生成モジュール５０４は、バッチ印刷の実行依頼を受け付けたことを示すレスポンスをサービス提供サーバＢ５５０へ返す。このとき、ページ生成モジュール５０４は、ステップ１５１１で取得したユーザＩＤをレスポンスに含める。ステップ１５１５でサービス提供サーバＢ５５０のバッチ印刷要求モジュール５５３４、５５４４は、ステップ１５１４のレスポンスに含まれるユーザＩＤを取得する。
【００７４】
次に、ステップ１５１６でサービス提供サーバＢ５５０のバッチ印刷要求モジュール５５３４、５５４４は、ステップ１５１５で取得したユーザＩＤのユーザに処理履歴テーブルに対する書き込み権限があるかを判断する。ステップ１５１６で処理履歴テーブルに対する書き込み権限がないと判断した場合、ステップ１５１７でサービス提供サーバＢ５５０のバッチ印刷要求モジュール５５３４、５５４４は、処理履歴管理モジュール５５３８，５５４８に対して、ステップ１５０２で返された処理履歴レコードのレコードＩＤ、ステータス「エラー終了」、および、エラーメッセージにアクセス権限不足を指定して履歴レコードを更新するよう要求する。処理履歴管理モジュール５５３８，５５４８は処理履歴テーブルの処理履歴レコードを更新する。この場合、バッチ印刷のスケジュールジョブはエラー終了する。以上のステップで、サービス提供サーバＡ５００でのバッチ印刷の受付が完了する。以降のステップでは、非同期でサービス提供サーバＡ５００が受け付けたバッチ印刷の実行を行う。
【００７５】
ステップ１５１８でサービス提供サーバＡ５００のバッチ印刷情報管理モジュール５０６は、ステップ１５１１で受信したＵＲＬパラメータ「ｔｅｎａｎｔ＿ＩＤ」の値をキーとして、ＨＤ２１１に保存されたバッチ印刷情報内を検索する。そして、該当のテナントＩＤに紐づくサーバＢアクセストークンを特定し取得する。ステップ１５１９でサービス提供サーバＡ５００のバッチ印刷情報管理モジュール５０６は、ステップ１５１１で受信したＵＲＬパラメータ「ｔｅｎａｎｔ＿ＩＤ」の値をキーとして、ＨＤ２１１に保存されたバッチ印刷情報内を検索する。そして、該当のテナントＩＤに紐づくサーバＡアクセストークンを特定し取得する。
【００７６】
ステップ１５２０で、サービス提供サーバＡ５００の処理履歴出力モジュール５１１は、サービス提供サーバＢ５５０に対して、ステップ１５０３で指定されたレコードＩＤおよびステータス「処理受付」を指定して履歴レコードを更新するよう要求する。サービス提供サーバＢ５５０が公開するＷｅｂサービスＡＰＩのパラメータに対して、ステップ１５１８で取得したサーバＢアクセストークンを指定することで履歴レコードを更新することが可能となる。
【００７７】
ステップ１５２１で、サービス提供サーバＢ５５０の処理履歴管理モジュール５５３８，５５４８は処理履歴テーブルの処理履歴レコードを更新する。ステップ１５２２で、サービス提供サーバＡ５００のデータ取得モジュール５０２は、サービス提供サーバＢ５５０に対して業務データの取得要求（クエリ）を行う。サービス提供サーバＢ５５０が公開するＷｅｂサービスＡＰＩのパラメータに対して、ステップ１５１８で取得したサーバＢアクセストークンを指定することで業務データの取得が可能となる。ステップ１５２３でサービス提供サーバＢ５５０は、業務データ取得のＡＰＩ要求を受けて、サービス提供サーバＡ５００へ業務データを送信する。
【００７８】
ステップ１５２４で、サービス提供サーバＡ５００の文書生成モジュール５０３は、不図示のフォーム管理モジュールが管理するフォームを取得して、前記取得した業務データと前記取得したフォームから文書データを生成する。文書データ生成処理は公知のため説明は割愛する。ステップ１５２５で、サービス提供サーバＡ５００のアクセストークン検証モジュール５１０は、ステップ１５１９で取得したサーバＡアクセストークンを指定して認証サーバＡ４００のアクセストークン妥当性検証ＡＰＩを呼び出し、妥当であるかを検証する。前記ステップ１５２４の文書データ生成は、取得した業務データが大量にある場合などに時間がかかる。このため、ステップ１５２５にてサーバＡアクセストークンの有効性を事前に検証する。
【００７９】
ステップ１５２６で認証サーバＡ４００は、アクセストークン妥当性検証ＡＰＩが呼び出されると、指定されたアクセストークンが妥当かどうかを検証して、結果をサービス提供サーバＡ５００に返す。前記取得したサーバＡアクセストークンが妥当である場合、ステップ１５２７に遷移する。ステップ１５２７でサービス提供サーバＡ５００の文書送信モジュール５０８は、サービス提供サーバＣ５６０に対して、ステップ１５２４で生成した文書データを送信する。ステップ１５２８でサービス提供サーバＣ５６０は、文書データを受信し、ステップ１５２９で文書印刷モジュール５６３がその文書データを印刷する。
【００８０】
ステップ１５３０でサービス提供サーバＡ５００の処理履歴出力モジュール５１１は、サービス提供サーバＢ５５０に対して、ステップ１５０３で指定されたレコードＩＤおよびステータス「処理完了」を指定して履歴レコードを更新するよう要求する。ステップ１５３１で、サービス提供サーバＢ５５０の処理履歴管理モジュール５５３８，５５４８は処理履歴テーブルの処理履歴レコードを更新する。なお、本フローでは、サービス提供サーバＣ５６０での文書データ印刷の完了を待たずに処理履歴の更新を行っているが、文書データ印刷の完了を待って処理履歴を更新するようにしてもよい。以上でサービス提供サーバＡ５００、サービス提供サーバＣ５６０、サービス提供サーバＢ５５０および認証サーバＡ４００が実行するフローが終了する。
【符号の説明】
【００８１】
１００  ＷＡＮ、１０１  ＬＡＮ、２００  クライアントＰＣ、
３００  認証サービス決定サービス、４００  認証サーバＡ、４５０  認証サーバＢ、
５００  サービス提供サービス
【図１５Ａ】
2016053858.tif 000003
【図１】
2016053858.tif 000004
【図２】
2016053858.tif 000005
【図３】
2016053858.tif 000006
【図４】
2016053858.tif 000007
【図５】
2016053858.tif 000008
【図６】
2016053858.tif 000009
【図７】
2016053858.tif 000010
【図８】
2016053858.tif 000011
【図９】
2016053858.tif 000012
【図１０】
2016053858.tif 000013
【図１１】
2016053858.tif 000014
【図１２】
2016053858.tif 000015
【図１３】
2016053858.tif 000016
【図１４】
2016053858.tif 000017
【図１５Ｂ】
2016053858.tif 000018
【図１６】
2016053858.tif 000019