JP2015079405A - 情報処理装置、情報処理装置の制御方法およびプログラム - Google Patents

Abstract

【課題】文書の生成前に、連携するサービスにふさわしい方法でユーザの利用権限を確認し、生成した文書を権限不足によって送信できない状況の発生を回避する。
【解決手段】文書生成サービスは、文書生成リクエストに応じ、文書を生成する前に、生成した文書の送信先となるサービスに応じた確認方法で、文書生成リクエストに対応するユーザが前記送信先となるサービスを利用する権限を有するか否かを確認する（Ｓ７０４、Ｓ７０９）。例えば、送信先が文書生成サービスと同じドメインのサービスなら認証サービスで権限を確認し（Ｓ７０４）、外部サービスなら外部サービスで権限を確認する（Ｓ７０９）。そして、権限を有することが確認された場合に、文書を生成し（Ｓ７１１）、該生成した文書を前記送信先となるサービスに送信する（Ｓ７１２）。
【選択図】図９

Description

本発明は、例えばクラウド上に保存されたデータをフォームオーバレイして文書を生成する情報処理装置の制御に関するものである。

近年、サーバコンピュータ側で業務データの管理や各種処理を行う形態として、クラウドコンピューティングシステムが普及し始めている。ユーザは、クライアントコンピュータ上のウェブブラウザ（以下、ブラウザ）からインターネットを介してクラウドサーバコンピュータのＷｅｂページにアクセスし、そのＷｅｂページ上で閲覧したい業務データを表示する。また、その画面からユーザが文書生成指示を行うと、文書生成サービスにリダイレクトされ、文書生成サービスから返される画面にてフォームオーバレイに使用するフォームをユーザが選択する。そして、文書生成サービスがクラウドサーバ上にあるデータを取得して文書を生成し、ユーザが指定した操作に従って、連携するクラウドサービスに送信する。また、文書生成サービスには、アプリケーションからＡＰＩを利用して文書の生成と送信を行う機能がある。

文書生成サービスとクラウドプラットフォームサービス（以下ＣＰＳ）は連携しており、文書生成サービスで生成した文書をＣＰＳ上のページへ添付することができる。文書生成サービスの属するドメインのユーザ情報は、該ドメインの認証サービスが管理しており、文書生成サービスは該認証サービスを利用することでユーザ情報の確認を行うことができる。また、ＣＰＳがシングルサインオン（以下ＳＳＯ）可能なクラウドサービスであれば認証サーバから文書生成サービスのユーザと紐付いたクラウドサービスのユーザ情報を取得し、認証を行うことができる。

ブラウザを経由して又はアプリケーションからＡＰＩを利用して、文書生成サービスに文書生成リクエストが渡されると、文書生成サービスはその文書生成リクエストに含まれる情報を用いて文書を生成する。文書生成サービスは、文書生成リクエストに含まれる文書生成後の操作（印刷、添付）に従い、生成した文書を他のクラウドサービスへ送信する。

特許文献１には、クラウドサービスから外部クラウドサービスにリダイレクトする場合、ブラウザに返すリダイレクト先が認証テーブルにあるか判定し、認証テーブルから取得した認証情報をリダイレクト先に送信し、サインオン処理する技術が提案されている。

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

文書生成サービスが文書を送信する他のクラウドサービスには様々なものがある。例えば、文書生成サービスと同じドメインに属するクラウドサービスもあれば、別のドメインに属する外部クラウドサービスもがある。また、文書生成サービスに渡される文書生成リクエストも、ウェブブラウザを経由して渡される場合もあれば、アプリケーションからＡＰＩを利用して渡される場合もある。

文書生成サービスから他のクラウドサービスを利用するためには、文書生成サービスを利用しているユーザが、連携するクラウドサービスの利用権限を有している必要がある。しかし、クラウドサービスごとに権限の確認方法と確認する権限の種類が異なる。このため、文書生成サービスは、連携するクラウドサービスごとにふさわしい権限確認方法で権限の確認を行う必要がある。

従来の文書生成サービスでは、文書の生成後に実際にクラウドサービスに文書を送信するまで、そのユーザに利用権限があるのか確認されていなかった。このため、生成した文書を権限不足によって送信できない状況が発生する可能性があった。この結果、送信権限がないにも関わらず文書を生成し、無駄にコンピュータ資源を浪費してしまう可能性があった。また、文書生成サービスが文書の生成に応じて課金するような構成の場合、文書生成されて課金されたが権限不足で送信できないといった事態が発生する可能性もあった。

本発明は、上記の問題点を解決するためになされたもので有る。本発明の目的は、データ生成前に、連携するサービスにふさわしい方法でユーザの利用権限を確認でき、生成したデータを権限不足によって送信できない状況の発生を回避することができる仕組みを提供することである。

本発明は、受信したリクエストに応じたデータを生成する生成手段と、前記生成手段が生成したデータを前記リクエストに応じたサービスへ送信する送信手段と、前記生成手段によるデータの生成前に、前記送信手段の送信先となるサービスに応じた確認方法で、前記リクエストに対応するユーザが前記送信先となるサービスを利用する権限を有するか否かを確認する確認手段と、を有し、前記生成手段は、前記確認手段により前記権限を有することが確認された場合に、前記データを生成することを特徴とする。

本発明によれば、データ生成前に、連携するサービスにふさわしい方法でユーザの利用権限を確認でき、生成したデータを権限不足によって送信できない状況の発生を回避することができる。この結果、送信権限がないのにデータを作成してしまい、無駄にコンピュータ資源を浪費してしまうといった事態の発生を防止できる。

本発明の一実施例を示すシステム構成を例示する図。 本システムを構成する各装置のハードウェア構成を例示する図。 文書生成サービスの属するドメインのソフトウェア構成を例示する図。 ＣＰＳのソフトウェア構成を例示する図。 文書生成リクエストの構造を例示する図。 認証サービスが保持するユーザ情報のテーブル構造を例示する図。 文書生成サービスが保持する送信先情報テーブルの構造を例示する図。 本システムにおける処理の流れを例示するシーケンス図。 実施例１における文書生成サービスの処理を例示するフローチャート。 外部サービス権限確認処理を例示するフローチャート。 ダウンロード画面を例示する図。 実施例２における文書生成サービスの処理を例示するフローチャート。 実施例３における文書生成サービスの処理を例示するフローチャート。 実施例３における権限不足の通知処理を例示するフローチャート。

以下、本発明を実施するための形態について図面を用いて説明する。なお、以下の実施の形態は特許請求の範囲に係る発明を以下の実施形態のみに限定するものではない。また、実施の形態で説明されている特徴の組み合わせの全てが発明に必須のものとは限らない。

図１は、本発明の一実施例を示すシステム構成の一例を示すブロック図である。
図１において、１０１はクライアント端末である。クライアント端末１０１は、文書生成サービス１０３、及び、クラウドプラットフォームサービス（以下ＣＰＳ）に対してリクエストを発行する。ここで、情報処理装置である文書生成サービス１０３から見ると、ＣＰＳ１０２及びプリントサービス１０５は外部情報処理装置である。

ＣＰＳ１０２は、クライアント端末１０１や文書生成サービス１０３からのリクエストに応じて、保持するデータに対し更新等を行う。文書生成サービス１０３は、クライアント端末１０１からリクエストを受信して文書生成を行う。認証サービス１０４は、文書生成サービス１０３からのリクエストに応じてユーザの認証と権限の確認を行う。プリントサービス１０５は、文書生成サービス１０３からのリクエストを受信して文書の印刷・認証印刷を行う。

また、上記クライアント端末１０１、文書生成サービス１０３、認証サービス１０４、プリントサービス１０５及びＣＰＳ１０２は、ネットワーク１００により通信可能に接続されている。ネットワークは、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれかである。また、これらの組み合わせにより実現される、いわゆる通信ネットワークである。なお、ネットワークはデータの送受信が可能であればどのようなネットワークであってもよい。また、各装置間の通信方法はそれぞれ異なっていても構わない。本実施例では、文書生成サービス１０３、認証サービス１０４、プリントサービス１０５は、同一のドメインに属しているものとする。また、ＣＰＳ１０２は、文書生成サービス１０３の属するドメインと異なるドメインに属しているものとする。

図２は、図１のクライアント端末１０１、ＣＰＳ１０２、文書生成サービス１０３、認証サービス１０４、プリントサービス１０５のハードウェア構成の一例を示すブロック図である。

図２において、２０１はＣＰＵで、内部バスで接続される各デバイス（後述のＲＯＭ、ＲＡＭ他）を直接或いは間接的に制御し、本発明を実現するためのプログラムを実行する。２０２はＲＯＭで、ＢＩＯＳ等が格納してある。２０３はＲＡＭ（直接記憶装置）で、ＣＰＵ２０１のワーク領域として利用されたり、本発明を実現するためのソフトウェアモジュールをロードするための一時記憶として利用されたりする。

２０４はＨＤＤ（ハードディスクドライブ）もしくはＳＳＤ（ソリッドステートドライブ）などの補助記憶装置で、基本ソフトウェアであるＯＳやソフトウェアモジュールが記憶されている。なお、ここでは、ＨＤＤと記載するが、ＨＤＤに限定されるものではない。

２０５は入力装置で、キーボードやポインティングデバイスなどである。２０６は出力装置で、ディスプレイが接続される。２０７はネットワーク１００に接続するためのＩ／Ｆである。

これらハードウェアでは、起動後に、ＣＰＵ２０１によりＢＩＯＳが実行されオペレーティングシステム（ＯＳ）がＨＤＤ２０４からＲＡＭ２０３に実行可能にロードされる。ＣＰＵ２０１は、ＯＳの動作に従って後述する各種ソフトウェアモジュールをＨＤＤ２０４からＲＡＭ２０３に随時、実行可能にロードする。各種ソフトウェアモジュールは、上記各デバイスの協調により、ＣＰＵ２０１によって実行され動作する。これにより、後述する図４〜図１０に示すソフトウェア構成及び後述するフローチャートの各ステップの処理が実現される。また、Ｉ／Ｆ２０７はネットワーク１００に接続されており、ＯＳの動作に従ってＣＰＵ２０１により制御され、上述したような通信を実現している。

以下、図３を用いて、文書生成サービスの属するドメインのソフトウェアモジュール構成を例示する。
図３は、文書生成サービス１０３、認証サービス１０４及びプリントサービス１０５上で動作するソフトウェアモジュールの構成の一例を示す図である。

文書生成サービス１０３は、送受信部３０１、制御部３０２、ページ生成部３０３、フォーム管理部３０４、文書生成部３０５、認証部３０６、ＤＢ３０７を有する。これらソフトウェアモジュール３０１〜３０６は、文書生成サービス１０３のＨＤＤ２０４にプログラムとして記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行されることにより機能する。また、ＤＢ３０７は、文書生成サービス１０３のＨＤＤ２０４内の記憶領域として実現される。

送受信部３０１は、クライアント端末１０１や、認証サービス１０４、プリントサービス１０５との通信を処理する。制御部３０２は、送受信部３０１が受け付けたリクエストに従って処理を実行する。ページ生成部３０３は、ウェブブラウザ（以下ブラウザ）にレスポンスを返すためのＷｅｂページを生成する。フォーム管理部３０４は、制御部３０２からの要求に応じてフォームデータの登録、取得、更新、削除を行う。文書生成部３０５は、制御部３０２からの要求に応じてフォームデータと業務データから文書の生成を行う。認証部３０６は、制御部３０２からの要求に応じて送受信部３０１とＤＢ３０７に保存された送信先情報を用いてユーザの認証等を行う。

認証サービス１０４は、送受信部３１０、制御部３０８、ユーザ管理部３０９、ＤＢ３１１を有する。これらソフトウェアモジュール３０８〜３１０は、認証サービス１０４のＨＤＤ２０４にプログラムとして記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行されることにより機能する。また、ＤＢ３１１は、認証サービス１０４のＨＤＤ２０４内の記憶領域として実現される。

送受信部３１０は、文書生成サービス１０３、プリントサービス１０５との通信を処理する。制御部３０８は、送受信部３１０が受け付けたリクエストに従って処理を実行する。ユーザ管理部３０９は、制御部３０８からの要求に応じてＤＢ３１１に保存されたユーザデータの登録、取得、更新、削除を行う。

プリントサービス１０５は、送受信部３１３、制御部３１４、ページ生成部３１５、プリンタ管理部３１６、ＰＤＬ生成部３１７、認証部３１８を有する。これらソフトウェアモジュール３１３〜３１８は、プリントサービス１０５のＨＤＤ２０４にプログラムとして記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行されることにより機能する。

送受信部３１３は、クライアント端末１０１や、文書生成サービス１０３との通信を処理する。制御部３１４は、送受信部３１３が受け付けたリクエストに従って処理を実行する。ページ生成部３１５は、ブラウザにレスポンスを返すためのＷｅｂページを生成する。プリンタ管理部３１６は、制御部３１４からの要求に応じてプリンタデータの登録、取得、更新、削除を行う。ＰＤＬ生成部３１７は、制御部３１４からの要求に応じて文書からＰＤＬ（Page Description Language）データの生成を行う。認証部３１８は、制御部３１４からの要求に応じて送受信部３１３を用いてユーザの認証を行う。

図４は、ＣＰＳ１０２上で動作するソフトウェアモジュールの構成の一例を示す図である。

ＣＰＳ１０２は、送受信部４０１、制御部４０２、ページ生成部４０３、セッション管理部４０４、認証部４０５、データ管理部４０６、設定管理部４０７、ＤＢ４０８を有する。これらソフトウェアモジュール４０１〜４０７は、ＣＰＳ１０２のＨＤＤ２０４にプログラムとして記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行されることにより機能する。また、ＤＢ４０８は、ＣＰＳ１０２のＨＤＤ２０４内の記憶領域として実現される。

送受信部４０１は、クライアント端末１０１や文書生成サービス１０３との通信を処理する。制御部４０２は、送受信部４０１が受け付けたリクエストに従って処理を実行する。ページ生成部４０３は、クライアント端末１０１にレスポンスを返すためのＷｅｂページを生成する。認証部４０５は、ログイン要求してきたユーザを認証する。セッション管理部４０４は、認証部４０５にて認証に成功したユーザのセッション情報を管理する。

データ管理部４０６は、業務データをＤＢ４０８に保持し、要求に応じてＤＢ４０８から業務データの取得又は業務データの更新を行う。設定管理部４０７は、文書生成サービス１０３へのリダイレクトを行うための設定を保持する。ＤＢ４０８は、管理ユーザデータや業務データを格納する。ＣＰＳ１０２は、これら各構成要素の協調により、後述する処理を実行する。

以下、ＤＢ４０８に格納される管理ユーザデータや業務データについて説明する。
管理ユーザデータや業務データは、企業・組織（以降、組織と表記）毎に管理される。各組織には、組織ＩＤが自動的に割り当てられ、組織ＩＤとともに各データが管理される。ユーザ認証時、認証部４０５は、ユーザが所属する組織の組織ＩＤを取得し、セッション管理部４０４に保存する。以降のデータ取得等の処理は、組織ＩＤをもとに行われ、組織ＩＤの一致するデータのみを参照することが可能となっている。

また、ＤＢ４０８には、文書生成サービス１０３へのリダイレクトを行うための設定も格納される。ＤＢ４０８に格納された業務データや文書生成サービス１０３へリダイレクトを行うための設定は、クライアント端末１０１を介して、ユーザ（管理者）により任意のタイミングで設定更新が行われる。

図５は、クライアント端末１０１上で動作するブラウザまたはアプリケーションが文書生成サービス１０３に送信する文書生成リクエストの構造の一例を示す図である。
文書生成リクエストは、フォームデータＩＤ９０１、業務データ９０６、操作９０２、ユーザＩＤ９０３、組織ＩＤ９０７、文書名９０４を含み、外部サービスへ送信する場合にはさらにアクセストークン９０５を含む。

フォームデータＩＤ９０１は、文書を生成する為に必要なフォームデータを指定するためのものである。操作９０２は、生成した文書に対する操作名を指定するためのものであり、この操作９０２に応じて、生成した文書の送信先が特定される。ユーザＩＤ９０３と組織ＩＤ９０７は、文書生成サービス１０３で認証するためのものである。文書名９０４は、生成した文書に付ける文書名を示す。アクセストークン９０５は、外部サービスに対するアクセス用のトークンである。業務データ９０６は、文書を生成する為に必要なデータを指定するためのものである。なお、業務データ９０６は、ＣＰＳ１０２が管理するデータを指定してもよいし、他のデータを指定してもよい。

図６は、認証サービス１０４のユーザ管理部３０９が保持するユーザに関するデータ（ユーザ情報）のテーブル構造の一例を示す図である。
図６に示すように、ユーザ情報は、ユーザ情報テーブル１０００で管理される。ユーザ情報テーブル１０００は、ユーザ情報レコード１００１等によって構成されている。

ユーザ情報レコード１００１（１１００）は、レコードの識別子であるユーザＩＤ１１０１、ＳＳＯ情報１１０２、ロール１１０３、ユーザに通知するためのメールアドレス１１０４、組織ＩＤ１１０５等で構成される。ロール１１０３は、ユーザの使用することが出来る範囲を示すものであり、例えば、ロールに文書生成権限や生成後に送信するサービスの権限等が設定されている。

ＳＳＯ情報１１０２は、ＳＳＯ情報テーブル１２００等によって構成される。ＳＳＯ情報テーブル１２００は、ＳＳＯ情報レコード１２０１等によって構成される。ＳＳＯ情報レコード１２０１は、ＳＳＯレコード１３００等によって構成され、文書生成サービスのユーザと紐付いたＣＰＳ１０２等の外部サービスのユーザ情報（認証情報）を管理する。ＳＳＯレコード１３００は、外部サービス名１３０１、ＡＰＩを使用するためのエンドポイントＵＲＬ１３０２、外部サービスユーザＩＤ１３０３、外部サービスパスワード１３０４等によって構成される。

図７は、文書生成サービス１０３の保持する送信先情報テーブル１７００と送信先レコード１８００の構造の一例を示す図である。

送信先情報テーブル１７００は、文書生成サービス１０３の保持する文書生成後の操作に関するデータを管理する。送信先情報テーブル１７００は、操作レコード１７０１等によって構成される。操作レコード１７０１は、送信先レコード１８００等により構成される。送信先レコード１８００は、文書生成サービス１０３の保持する文書の操作名に対応する送信先を管理する。送信先レコード１８００は、操作名１８０１、エンドポイントＵＲＬ１８０２等から構成される。

以上のような構成で、文書生成サービス１０３がクラウドサービスとして提供されている。文書生成サービス１０３から他のクラウドサービスを利用するためには、文書生成サービスを利用しているユーザが、連携するクラウドサービスの利用権限を有している必要がある。しかし、ユーザが文書生成リクエストで指定した操作に応じて特定される連携するクラウドサービスによって、ふさわしい権限確認方法が異なる。本実施例では、文書の送信先となるクラウドサービスが文書生成サービス１０３と同じドメインに属しているか否かにより、前記権限の確認方法を変更制御する。

文書の送信先が文書生成サービス１０３と同じドメインのクラウドサービスの場合には、文書を生成する前に該ドメインの認証サービス１０４に文書生成リクエストから取得したユーザ情報に権限が付いているか確認する。また、文書の送信先が該ドメインの外部のクラウドサービス（外部サービス）の場合には、文書を生成する前に認証サービス１０４に前記外部サービスがＳＳＯ可能か問い合わせる。そして、ＳＳＯ可能だった場合、認証サービス１０４から受け取ったユーザ情報を用いて前記外部サービスにユーザの権限確認を行う。また、ＳＳＯ不可能な外部サービスだった場合、文書生成リクエストに指定された外部サービスのアクセストークン等を用いて前記外部サービスにユーザの権限確認を行う。以下、詳細に説明する。

以下、図８を用いて、本システムにおける処理の流れを説明する。
図８は、文書生成サービス１０３が文書生成リクエスト受信時に行う処理の流れを例示するシーケンス図である。ここでは、例えば、クライアント端末１０１において、ユーザがウェブブラウザ経由で文書生成リクエストを送信する場合、不図示のログイン画面にてＣＰＳ１０２にログイン済みとする。また、クライアント端末１０１がアプリケーションを利用して文書生成リクエストを送信する場合も、該アプリケーションからＣＰＳ１０２にログイン済みとする。また、このシーケンス図の各サービス（１０１〜１０５）の処理は、各サービスを提供する各装置のＣＰＵ２０１がＨＤＤ２０４等に格納されたプログラムをＲＡＭ２０３にロードして実行することにより実現される。

クライアント端末１０１から文書生成リクエスト９００が送信され（Ｓ６０１）、文書生成サービス１０３が該文書生成リクエスト９００を受信すると、該文書生成リクエスト９００から操作９０２（印刷、添付）を取得する（Ｓ６０２）。

次に、文書生成サービス１０３は、上記Ｓ６０２で取得した操作９０２に対応するリクエストの送信先が文書生成サービス１０３と同じドメインか外部のドメインかを判定する（Ｓ６０３）。詳細には、文書生成サービス１０３は、上記Ｓ６０２で取得した操作９０２の示す操作名からエンドポイントＵＲＬ１８０２を取得し、エンドポイントＵＲＬ中のドメイン部分と文書生成サービス１０３のドメインを比較して、ドメインの判定を行う。

次に、文書生成サービス１０３は、文書生成リクエスト９００で指定されたユーザＩＤ９０３の権限を確認するために、ユーザＩＤ９０３を含む権限確認リクエストを認証サービス１０４に送信する（Ｓ６０４）。認証サービス１０４は、権限確認リクエストを受信すると、ユーザ管理部３０９でユーザの権限を確認する（Ｓ６１１）。認証サービス１０４は、例えば、権限確認リクエストに含まれるユーザＩＤに対応するロール１１０３に文書生成権限や生成後に送信するサービスの権限が設定されているかどうかにより、ユーザの権限を確認する。権限確認後、認証サービス１０４は、送受信部３１０を用いて権限確認結果を文書生成サービス１０３へ送信する（Ｓ６１２）。

文書生成サービス１０３は、権限確認結果を受信すると、上記Ｓ６０３のドメイン判定結果に応じた分岐処理を行う。
文書生成サービス１０３は、上記Ｓ６０３のドメイン判定で操作に対応するリクエストの送信先が外部サービスと判断した場合（［ドメイン：外部］の場合）、ＣＰＳ１０２でユーザの権限を確認する（Ｓ６１３）。権限確認リクエストを受信したＣＰＳ１０２は、権限の判定結果（Ｓ６１４）を文書生成サービス１０３に送信する（Ｓ６１５）。権限の判定結果を受信すると、文書生成サービス１０３は、Ｓ６０５に処理を移行する。

一方、上記Ｓ６０３のドメイン判定で操作に対応するリクエストの送信先が文書生成サービス１０３と同ドメインと判断した場合（［ドメイン：同じ］の場合）、文書生成サービス１０３は、そのままＳ６０５に処理を移行する。この場合、Ｓ６１１において認証サービス１０４で権限確認済みであるため、Ｓ６１３、Ｓ６１４、Ｓ６１５に示したような処理は実行されない。

Ｓ６０５において、文書生成サービス１０３は、文書生成リクエストのフォームデータＩＤ９０１、業務データ９０６、文書名９０４を用いて、オーバレイを行い、文書データ（以下、文書）を生成する。

次に、文書生成サービス１０３は、上記Ｓ６０２で取得した操作９０２の内容に応じた分岐処理を行う。
操作９０２が印刷の場合（［操作：印刷］の場合）、文書生成サービス１０３は、生成した文書を印刷リクエストとしてプリントサービス１０５に送信する（Ｓ６０６）。印刷リクエストを受信すると、プリントサービス１０５は、権限を確認し、印刷処理を行う（Ｓ６１５）。さらに、プリントサービス１０５は、印刷処理の結果を、文書生成サービス１０３に送信する（Ｓ６０７）。印刷処理の結果を受信すると、文書生成サービス１０３は、Ｓ６１０に処理を移行する。

一方、操作が添付の場合（［操作：添付］の場合）、文書生成サービス１０３は、生成した文書をＣＰＳ１０２に送信する（Ｓ６０８）。印刷リクエストを受信すると、ＣＰＳ１０２は、権限を確認し添付処理を行う（Ｓ６１６）。そして、ＣＰＳ１０２は、添付処理の結果を文書生成サービス１０３に送信する（Ｓ６０９）。添付処理の結果を受信すると、文書生成サービス１０３は、Ｓ６１０に処理を移行する。

Ｓ６１０において、文書生成サービス１０３は、上記Ｓ６０１で受信した文書生成リクエストの送信元であるクライアント端末１０１に、文書生成リクエストのレスポンスを返信する（Ｓ６１０）。

以下、図９、図１０のフローチャートを参照して、実施例１の文書生成サービス１０３の文書生成リクエストの受信からレスポンス送信までの処理について詳細に説明する。なお、図９、図１０のフローチャートが示す処理は、文書生成サービス１０３の制御部３０２の制御により実行される。即ち、このフローチャートが示す処理は、文書生成サービス１０３のＣＰＵ２０１がＨＤＤ２０４等に格納されたプログラムをＲＡＭ２０３にロードして実行することにより実現される。

図９は、実施例１における文書生成サービス１０３の文書生成リクエストの受信からレスポンス送信までの処理を例示するフローチャートである。

制御部３０２は、クライアント端末１０１からの文書生成リクエスト９００を受信すると（Ｓ７００）、Ｓ７０１において、文書生成リクエスト９００がブラウザ経由のＷｅｂページへのアクセスかＡＰＩを利用しているのかを判定する。次に、Ｓ７０２において、制御部３０２は、文書生成リクエスト９００から操作９０２を取得する。

次に、Ｓ７０３において、制御部３０２は、認証部３０６に指示を出し、文書生成リクエスト９００から取得した操作９０２を用いてＤＢ３０７からエンドポイントＵＲＬ１８０２を取得する。さらに、制御部３０２は、エンドポイントＵＲＬ１８０２中のドメイン部分を文書生成サービス１０３のドメインと比較し、同じドメインか外部のドメインか判定する。

そして、エンドポイントＵＲＬが文書生成サービス１０３と同ドメインと判定した場合（Ｓ７０３で「同ドメイン」の場合）、制御部３０２は、Ｓ７０４に処理を進める。Ｓ７０４において、制御部３０２は、認証部３０６を用いて認証サービス１０４に、文書生成権限と生成後に送信するサービスの権限を確認する。

次に、Ｓ７０５において、上記Ｓ７０４の確認結果を判定する。そして、確認結果が「権限なし」であった場合（Ｓ７０５で「権限なし」の場合）、制御部３０２は、権限エラーをクライアント端末１０１に通知し（Ｓ７０６）、処理を終了する。

一方、確認結果が「権限あり」であった場合（Ｓ７０５で「権限あり」の場合）、制御部３０２は、Ｓ７１１に処理を進める。

また、上記Ｓ７０３において、エンドポイントＵＲＬが文書生成サービス１０３と異なるドメイン（外部サービス）であると判定した場合（Ｓ７０３で「外部サービス」の場合）、制御部３０２は、Ｓ７０７に処理を進める。Ｓ７０７において、制御部３０２は、認証部３０６を用いて認証サービス１０４に、文書生成権限を確認する。

次に、Ｓ７０８において、制御部３０２は、上記Ｓ７０７の文書権限確認結果を判定する。そして、文書権限確認結果が「権限不足」であった場合（Ｓ７０８で「権限不足」の場合）、制御部３０２は、権限エラーをクライアント端末１０１に通知し（Ｓ７０６）、処理を終了する。

一方、文書権限確認結果が「権限あり」であった場合（Ｓ７０５で「権限あり」の場合）、制御部３０２は、Ｓ７０９に処理を進める。Ｓ７０９において、制御部３０２は、外部サービス権限確認処理を実行する。Ｓ７０９の外部サービス権限確認処理の詳細は後述する図１０で示す。

次に、Ｓ７１０において、制御部３０２は、上記Ｓ７０９の外部サービス権限確認結果を判定する。そして、外部サービス権限確認が「権限不足」であった場合（Ｓ７１０で「権限不足」の場合）、制御部３０２は、権限エラーをクライアント端末１０１に通知し（Ｓ７０６）、処理を終了する。

一方、外部サービス権限確認結果が「権限あり」であった場合（Ｓ７１０で「権限あり」の場合）、制御部３０２は、Ｓ７１１に処理を進める。

Ｓ７１１において、制御部３０２は、文書生成リクエスト９００から取得したフォームデータＩＤ９０１、業務データ９０６、文書名９０４を用いて、文書生成部３０５を介してオーバレイを行い、文書を生成する。次に、Ｓ７１２において、制御部３０２は、上記Ｓ７１１のオーバレイで生成した文書を、送受信部３０１から他クラウドサービスに送信する（帳票送信）。ここで、送信先となる他クラウドサービスは、操作９０２に応じたエンドポイントＵＲＬ１８０２が示すものとなる。

次に、Ｓ７１３において、制御部３０２は、上記Ｓ７１２の送信結果を判定する。そして、送信成功と判定した場合（Ｓ７１３で「成功」の場合）、制御部３０２は、レスポンスをクライアント端末１０１に送信し（不図示）、処理を終了する。一方、送信失敗と判定した場合（Ｓ７１３で「失敗」の場合）、制御部３０２は、エラーをクライアント端末１０１に送信する（Ｓ７１４）。この際、制御部３０２は、上記Ｓ７０１でブラウザ経由と判定した場合、ページ生成部３０３で生成したダウンロード画面（例えば図１１）をブラウザに返す。一方、制御部３０２は、上記Ｓ７０１でＡＰＩを利用したリクエスト（ＷｅｂＡＰＩ）と判定した場合、エラーのレスポンスをクライアント端末１０１に送信する。

図１１は、文書生成サービス１０３のページ生成部３０３が生成するダウンロード画面の一例を示す図である。
図１１に示すように、ダウンロード画面１４００は、エラーメッセージ１４０２と、ダウンロードリンク１４０１を有する。即ち、ダウンロード画面１４００では、文書生成サービス１０３で生成した文書をダウンロードするための情報を表示する。

図１０は、文書生成サービス１０３の外部サービス権限確認処理（図９のＳ７０９）の一例を示すフローチャートである。
Ｓ８０１において、制御部３０２は、認証サービス１０４に、文書生成リクエスト９００から取得したユーザＩＤ９０３とエンドポイントＵＲＬ１８０２を送信して、認証サービス１０４から返送される確認結果を受信し、ＳＳＯ可能か確認する。認証サービス１０４は、受信したユーザＩＤで特定されるユーザ情報レコード１１００に対応するＳＳＯ情報テーブル１２００に、受信したエンドポイントＵＲＬ１８０２に対応するＳＳＯレコード１３００を特定する。さらに、認証サービス１０４は、特定したＳＳＯレコード１３００に外部サービスユーザＩＤ１３０３と外部サービスパスワード１３０４が格納されている場合にＳＳＯ可能と判断し、それ以外の場合にＳＳＯ不可能と判断し、判断結果を文書生成サービス１０３に返送する。

Ｓ８０２において、制御部３０２は、上記Ｓ８０１のＳＳＯ確認結果を判定する。そして、ＳＳＯ確認結果がＳＳＯ可能であった場合（Ｓ８０２で「ＳＳＯ可能」の場合）、制御部３０２は、Ｓ８０３に処理を進める。Ｓ８０３において、制御部３０２は、認証サービス１０４から、外部サービスユーザＩＤ１３０３と外部サービスパスワード１３０４を取得する。さらに、Ｓ８０４において、制御部３０２は、エンドポイントＵＲＬ１３０２に、権限確認リクエスト（外部サービスユーザＩＤ１３０３と外部サービスパスワード１３０４を含む）を送信し、エンドポイントＵＲＬ１３０２から返送される権限確認結果を受信する。上記Ｓ８０４の処理が終了すると、制御部３０２は、本フローチャートの処理を終了し、図９のＳ７１０に処理を移行する。

一方、ＳＳＯ確認結果がＳＳＯ不可であった場合（Ｓ８０２で「ＳＳＯ不可」の場合）、制御部３０２は、Ｓ８０５に処理を進める。Ｓ８０５において、制御部３０２は、クライアント端末１０１からのリクエストがブラウザ経由かＡＰＩを利用したリクエストか判定する。

そして、ブラウザ経由のリクエストであると判定した場合（Ｓ８０５で「ＵＩ」の場合）、制御部３０２は、Ｓ８０６に処理を進める。Ｓ８０６において、制御部３０２は、ブラウザに外部サービスへのリダイレクトリクエストを送信し、権限確認を行う。権限確認の際、ブラウザのセッションのユーザ情報を用いて認証を行う。ブラウザのセッション情報は、ブラウザからＣＰＳ１０２にログインした際にＣＰＳ１０２から受信したものとする。なお、ブラウザのセッションのユーザ情報が無い場合には、ブラウザにログイン画面を表示してユーザに認証情報の入力を促し、認証権限を確認するようにする。上記Ｓ８０６の処理が終了すると、制御部３０２は、本フローチャートの処理を終了し、図９のＳ７１０に処理を移行する。

一方、ＡＰＩを利用したリクエストであると判定した場合（Ｓ８０５で「ＷｅｂＡＰＩ」の場合）、制御部３０２は、Ｓ８０７に処理を進める。Ｓ８０７において、制御部３０２は、文書生成リクエスト９００から外部サービスのアクセストークン９０５を取得する。さらに、Ｓ８０８において、制御部３０２は、上記Ｓ８０７で取得したアクセストークン９０５を用いて外部サービスへ権限確認を行い、本フローチャートの処理を終了し、図９のＳ７１０に処理を移行する。上記アクセストークンは、クライアント端末１０１のアプリケーションがＣＰＳ１０２にログインした際にＣＰＳ１０２から取得したものとする。

以上の処理により、文書生成サービス１０３は文書生成処理を実行する。なお、文書生成サービス１０３における文書生成処理（フォームを使用したオーバレイ処理）は既知であるため、本実施例では説明を割愛する。

本実施例によれば、文書生成サービスが生成した文書を他クラウドサービスに送信する場合、ユーザの指示内容（操作９０２）から送信先クラウドサービスを判別する。そして、該送信先クラウドサービスに応じて、権限確認方法を決定し、文書の生成前に指示内容（操作９０２）に応じたクラウドサービスの権限を確認することができる。この結果、生成した文書を権限不足によって送信できない状況を回避することができる。よって、送信権限がないのに文書を作成してしまい、無駄にコンピュータ資源を浪費してしまうといったことを防止できる。また、例えば、文書生成サービスが文書の生成に応じて課金するような構成の場合、文書生成されて課金されたが権限不足で送信できなかったといった事態の発生を防止することができる。

上記実施例１では、文書の送信先クラウドサービスの権限確認が同ドメインのクラウドサービスと外部クラウドサービスの場合の二種類で可能であり、送信先に応じて、文書生成の事前の権限の確認方法を切り替え制御する構成について説明した。実施例２では、文書生成サービス１０３が同ドメインのクラウドサービスの権限のみ確認可能な場合に、文書生成処理の事前に送信先クラウドサービスの権限を確認する方法について説明する。以下、実施例１で記載済みの内容については説明を省略する。

図１２は、実施例２における文書生成サービス１０３の文書生成リクエストの受信からレスポンス送信までの処理を例示するフローチャートである。なお、図１２のフローチャートが示す処理は、文書生成サービス１０３の制御部３０２の制御により実行される。即ち、このフローチャートが示す処理は、文書生成サービス１０３のＣＰＵ２０１がＨＤＤ２０４等に格納されたプログラムをＲＡＭ２０３にロードして実行することにより実現される。なお、図１２のＳ１９０１、Ｓ１９０１〜Ｓ１９０３は、図９のＳ７００、Ｓ７０２〜Ｓ７０４と同様の為、説明を割愛する。また、Ｓ１９０４〜Ｓ１９０６についてもＳ７１１〜Ｓ７１３と同様の為、説明を割愛する。ただし、実施例２では、エンドポイントＵＲＬが文書生成サービス１０３と異なるドメイン（外部サービス）であると判定した場合（Ｓ１９０２で「外部サービス」の場合）、制御部３０２は、Ｓ１９０４に処理を進め、オーバレイを行う。

制御部３０２は、帳票の送信失敗と判定した場合（Ｓ１９０６で「失敗」の場合）、ダウンロード画面（例えば図１１の１４００）の生成をページ生成部３０３に指示し、送受信部３０１を用いてクライアント端末１０１（ブラウザ）に送信する（Ｓ１９０７）。

本実施例によれば、ユーザの指示内容（操作９０２）から判別された送信先クラウドサービスが文書生成サービスと同ドメインの場合、文書の生成前に、指示内容（操作９０２）に応じたクラウドサービスの権限を認証サーバに確認することができる。この結果、生成した文書を権限不足によって同ドメイン内のクラウドサービスに送信できない状況を回避することができる。

上記実施例１では、文書の送信先クラウドサービスに応じて、文書生成の事前の権限の確認方法を切り替える構成について説明した。実施例１では、権限不足と判定された場合、権限が追加されるまでユーザの指定した操作は実行されない。実施例２では、ユーザの権限が不足していた場合に管理者に権限不足のエラーを通知する方法を説明する。以下、実施例１で記載済みの内容については説明を省略する。

以下、図１３、図１４のフローチャートを参照して、実施例３の文書生成サービス１０３の文書生成リクエストの受信からレスポンス送信までの処理について詳細に説明する。なお、図１３、図１４のフローチャートが示す処理は、文書生成サービス１０３の制御部３０２の制御により実行される。即ち、このフローチャートが示す処理は、文書生成サービス１０３のＣＰＵ２０１がＨＤＤ２０４等に格納されたプログラムをＲＡＭ２０３にロードして実行することにより実現される。

図１３は、実施例３における文書生成サービス１０３の文書生成リクエストの受信からレスポンス送信までの処理を例示するフローチャートである。なお、図１２のＳ１５００〜Ｓ１５０４は、図９のＳ７００〜Ｓ７０４と同様の為、説明を割愛する。また、Ｓ１５０８についてもＳ７０７と同様の為、説明を割愛する。

文書生成サービス１０３の制御部３０２は、Ｓ１５０４又はＳ１５０８の権限確認処理を終えると、Ｓ１５０５において、該権限確認の結果が権限不足の場合に管理者に通知する処理を実行する。Ｓ１５０５の処理の詳細は図１４で説明する。

図１４は、実施例３における権限不足の場合に管理者に通知する処理（図１３のＳ１５０５）の一例を示すフローチャートである。

Ｓ１６０１において、制御部３０２は、図１３のＳ１５０４、Ｓ１５０８またはＳ１５０９の権限確認結果を判定する。そして、権限ありと判定した場合（Ｓ１６０１で「権限あり」の場合）、制御部３０２は、本フローチャートの処理を終了し、図１３のＳ１５１０に処理を移行する。これにより、オーバレイ、帳票送信が行われる。

一方、権限不足だったと判定した場合（Ｓ１６０１で「権限なし」の場合）、制御部３０２は、Ｓ１６０２に処理を移行する。Ｓ１６０２において、制御部３０２は、認証部３０６を用い認証サービス１０４から、管理者ロールを持つ（ロール１１０３に管理者権限が設定されている）ユーザのユーザ情報レコード１１００を取得する。

次に、Ｓ１６０３において、制御部３０２は、上記Ｓ１６０２で取得したユーザ情報からユーザＩＤ１１０１、メールアドレス１１０４、組織ＩＤ１１０５を取得し、メールを生成する。なお、ここで生成するメールは、文書生成サービス１０３がクライアント端末１０１から受信した文書生成リクエスト９００内の情報と、権限不足となったこと、および、権限不足の種別（文書生成権限不足か送信権限不足か）を示す情報等を含むものとする。

次に、Ｓ１６０４において、制御部３０２は、送受信部３０１を用いて、上記Ｓ１６０３で生成したメールを送信する。即ち、ユーザＩＤ９０３に対応するユーザがフォームデータＩＤ９０１に対応するデータに対して、操作９０２に対応する操作を実行しようとして、権限不足（文書生成権限不足、又は、送信権限不足）となったことを示すメールを、管理者に送信する。

次に、Ｓ１６０５において、制御部３０２は、権限不足エラーをクライアント端末１０１に送信する。この際、制御部３０２は、図１３のＳ１５０１でブラウザ経由と判定した場合、ページ生成部３０３で生成した権限不足エラーページをブラウザに返す。

一方、制御部３０２は、図１３のＳ１５０１でＡＰＩを利用したリクエスト（ＷｅｂＡＰＩ）と判定した場合、権限不足エラーのレスポンスをクライアント端末１０１に送信する。そして、Ｓ１６０５の処理を終了すると、制御部３０２は、本フローチャートの処理を終了し、図１３のフローチャートの処理も終了する。これにより、権限不足の場合には、オーバレイも帳票送信も行われることなく、処理が終了することとなる。

本実施例によれば、実施例１の効果に加え、文書生成権限不足または送信権限不足によってユーザの指示内容（操作９０２）を実行できなかった場合に、その時点で、その旨を管理者に自動で通知することができる。これにより、管理者は、ユーザに権限を付与する等の適切な措置を速やかに実施することができる。

なお、図９のＳ７０６の権限エラー通知も、図１４のＳ１６０５と同様に、ブラウザ経由とＷｅｂＡＰＩを利用した文書生成リクエストとで、通知方法を切り替えるようにしてもよい。

また、本実施例では、文書生成サービス１０３が、オーバレイ処理により文書生成を行う場合を説明したが、文書生成方法はオーバレイ処理に限定されるものではなく、どのような方法の文書生成であっても本発明を適用可能である。また、文書生成サービス１０３が生成するデータは文書に限定されるものではなく、文書以外のデータを生成する場合にも本発明を適用可能である。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

１００ ネットワーク
１０１ クライアント端末
１０２ クラウドプラットフォームサービス（ＣＰＳ）
１０３ 文書生成サービス
１０４ 認証サービス
１０５ プリントサービス

Claims (14)

1. 受信したリクエストに応じたデータを生成する生成手段と、
   前記生成手段が生成したデータを前記リクエストに応じたサービスへ送信する送信手段と、
   前記生成手段によるデータの生成前に、前記送信手段の送信先となるサービスに応じた確認方法で、前記リクエストに対応するユーザが前記送信先となるサービスを利用する権限を有するか否かを確認する確認手段と、を有し、
   前記生成手段は、前記確認手段により前記権限を有することが確認された場合に、前記データを生成することを特徴とする情報処理装置。
2. 前記確認手段は、前記送信先となるサービスが前記情報処理装置と同じドメインに属しているか否かにより、前記権限の確認方法を変更することを特徴とする請求項１に記載の情報処理装置。
3. 前記確認手段は、前記送信先となるサービスが前記情報処理装置と同じドメインに属している場合、該ドメインの認証サービスで前記権限の確認を行い、前記送信先となるサービスが該ドメインに属していない場合、前記送信先となるサービスで前記権限の確認を行うことを特徴とする請求項２に記載の情報処理装置。
4. 前記確認手段は、前記送信先となるサービスで前記権限の確認を行う場合、前記送信先となるサービスにおける前記ユーザの認証情報が前記認証サービスで管理されている場合には、前記認証サービスで管理されている前記ユーザの認証情報を用いて、前記送信先となるサービスで前記権限の確認を行うことを特徴とする請求項３に記載の情報処理装置。
5. 前記確認手段は、前記送信先となるサービスで前記権限の確認を行う場合、前記送信先となるサービスにおける前記ユーザの認証情報が前記認証サービスで管理されていない場合には、前記リクエストがウェブブラウザ経由で受信されたものかどうかどうかに応じて、前記権限の確認方法を変更することを特徴とする請求項３又は４に記載の情報処理装置。
6. 前記確認手段は、前記リクエストがウェブブラウザ経由で受信されたものである場合には、該ウェブブラウザに前記送信先となるサービスへリダイレクトする指示を送信して前記送信先となるサービスで前記権限の確認を行うことを特徴とする請求項５に記載の情報処理装置。
7. 前記確認手段は、前記リクエストがウェブブラウザ経由で受信されたものでない場合、前記リクエストに含まれるアクセス用のトークンを用いて前記送信先となるサービスで前記権限の確認を行うことを特徴とする請求項５又は６に記載の情報処理装置。
8. 前記確認手段により前記権限を有することが確認できなかった場合、その旨を管理者に通知する通知手段を有することを特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
9. 前記送信手段によるデータの送信が失敗した場合、その旨を前記リクエストの送信元に返信する返信手段を有し、
   前記返信手段は、前記リクエストがウェブブラウザ経由で受信されたものである場合、該ウェブブラウザに前記データをダウンロードするための情報を返信することを特徴とする請求項１乃至８のいずれか１項に記載の情報処理装置。
10. 前記サービスは、前記データを利用する機能を提供するサービスであることを特徴とする請求項１乃至９のいずれか１項に記載の情報処理装置。
11. 前記サービスは、前記データを印刷するサービス、又は、前記データをそのサービスが提供するページに添付するサービスであることを特徴とする請求項１０に記載の情報処理装置。
12. 前記生成手段は、前記リクエストで指定された情報及びフォームを用いて文書データを生成することを特徴とする請求項１乃至１１のいずれか１項に記載の情報処理装置。
13. 受信したリクエストに応じたデータを生成する生成手段と、前記生成手段が生成したデータを前記リクエストに応じたサービスへ送信する送信手段とを有する情報処理装置の制御方法であって、
    前記生成手段によるデータの生成前に、前記送信手段の送信先となるサービスに応じた確認方法で、前記リクエストに対応するユーザが前記送信先となるサービスを利用する権限を有するか否かを確認する確認ステップと、
    前記確認ステップにより前記権限を有することが確認された場合に、前記生成手段が前記データを生成する生成ステップと、
    前記生成ステップで生成されたデータを前記送信手段が前記送信先となるサービスに送信する送信ステップと、
    を有することを特徴とする情報処理装置の制御方法。
14. コンピュータを、請求項１乃至１２のいずれか１項に記載された手段として機能させるためのプログラム。

Images