JP2017084378A - クラウドサービス提供システム及びクラウドサービス提供方法 - Google Patents

Abstract

【課題】サービス利用のためのユーザによる認可手続きの回数を減らすことができるシステム及びサービス提供装置を提供することを課題とする。
【解決手段】第一のサービス提供システムと、第二のサービス提供システムとを有するシステムであって、第一のユーザが操作する機器から、第二のユーザが第二のサービス提供システムを利用するための認可要求を受け付け、機器の接続先を第二のサービス提供システムに変更して、第二のユーザの認可処理を行わせる手段と、認可要求が認められたことを示す認可情報を受信し、認可情報を用いて第二のサービス提供システムを利用するための認可後の権限情報を第二のサービス提供システムから取得する手段と、第二のユーザが操作する機器から受け付けた第二のサービス提供システムを利用する処理の要求に基づき、第二のユーザに紐付く認可後の権限情報を提供する手段と、を有することにより、上記課題を解決する。
【選択図】 図１

Description

本発明は、システム及びサービス提供装置に関する。

或る装置がユーザから委譲された権限で他の装置を代理アクセスする場合に、装置間で交換される情報を減らすことを目的とし、アクセス制御や権限委譲に関する設定を一箇所で集中管理するアクセス権限管理システムは、従来から知られている（例えば特許文献１参照）。

従来のアクセス権限管理システムは、権限を委譲する条件を管理する認証装置と、サービス要求に応じてサービスを提供するサービス提供装置と、サービス提供装置へのアクセスを代行するサービス代理アクセス装置とを備えていた。

近年、クラウドサービスに代表されるようなＷｅｂアプリケーションやサーバ側のアプリケーションの機能をサービスとして提供する利用形態が注目されている。このような利用形態において、ユーザは自身の権限に応じたサービスの提供を受ける為に、認証が必要となる。

また、マッシュアップに代表されるような複数のサービスを連携させる利用形態も注目されている。このような利用形態においては、一のサービスがユーザから委譲された権限に応じて他のサービスの提供を受ける際に、認可が必要となる。

このような、複数のサービスを連携させる利用形態において、ユーザは一のサービスがユーザから委譲された権限に応じて他のサービスの提供を受ける際に、他のサービスそれぞれについて認可手続きを行わなければならなかった。

本発明の実施の形態は、上記の点に鑑みなされたもので、サービス利用のためのユーザによる認可手続きの回数を減らすことができるシステム及びサービス提供装置を提供することを目的とする。

上記目的を達成するため、本願請求項１は、機器にサービスを提供する第一のサービス提供システムと、前記第一のサービス提供システムと認証基盤が異なる第二のサービス提供システムと、を有するシステムであって、第一のユーザが操作する機器から、第二のユーザが前記第二のサービス提供システムを利用するための認可要求を受け付け、前記機器の接続先を前記第二のサービス提供システムに変更して、前記第二のサービス提供システムにおける第二のユーザの認可処理を行わせる接続先変更手段と、前記機器から前記認可要求が認められたことを示す認可情報を受信し、前記認可情報を用いて、前記第二のサービス提供システムを利用するための認可後の権限情報を前記第二のサービス提供システムから取得する権限情報取得手段と、前記第二のユーザが操作する機器から受け付けた前記第二のサービス提供システムを利用する処理の要求に基づき、前記第二のユーザに紐付く前記認可後の権限情報を提供する権限情報提供手段と、を有することを特徴とする。

本発明の実施の形態によれば、サービス利用のためのユーザによる認可手続きの回数を減らすことができる。

本実施形態に係るシステムの一例の構成図である。 本実施形態に係るコンピュータシステムの一例のハードウェア構成図である。 本実施形態に係るサービス提供システムの一例の処理ブロック図である。 本実施形態に係る管理設定サービスアプリの一例の処理ブロック図である。 本実施形態に係る認証処理部の一例の処理ブロック図である。 本実施形態に係るサービスアプリの一例の処理ブロック図である。 本実施形態に係るデータ処理部の一例の処理ブロック図である。 組織管理情報の一例の構成図である。 ユーザ管理情報の一例の構成図である。 機器管理情報の一例の構成図である。 認可設定情報の一例の構成図である。 外部サービス情報の一例の構成図である。 認可トークン情報の一例の構成図である。 認可設定情報の登録及び認可トークン情報の保存の処理手順の一例を表したシーケンス図である。 ログイン画面の一例のイメージ図である。 認可画面の一例のイメージ図である。 外部サービスを利用する処理手順の一例を表したシーケンス図である。 外部サービス連携要求画面の一例のイメージ図である。 非同期処理と外部サービスシステムとが連携する処理手順の一例を表したシーケンス図である。

次に、本発明の実施の形態について、詳細に説明する。
［第１の実施形態］
＜システム構成＞
図１は本実施形態に係るシステムの一例の構成図である。図１のシステム１は、例えばオフィス内ネットワーク等のネットワークＮ１と、クラウドサービスに代表されるようなサービス提供システムのネットワークＮ２と、クラウドサービスに代表されるような外部サービスのネットワークＮ３と、インターネットなどのネットワークＮ４とを有する。

ネットワークＮ１は、ファイアウォールＦＷの内側にあるプライベートなネットワークである。ファイアウォールＦＷはネットワークＮ１とネットワークＮ４との接点に設置され、不正なアクセスを検出及び遮断する。ネットワークＮ１にはクライアント端末１１、携帯端末１２、複合機などの画像形成装置１４、プロジェクタ１５、電子黒板等のその他の機器１６が接続されている。

クライアント端末１１は端末装置の一例である。クライアント端末１１は一般的なＯＳなどが搭載された情報処理装置（コンピュータシステム）によって実現できる。クライアント端末１１は無線による通信の手段または有線による通信の手段を有する。クライアント端末１１は、タブレットＰＣ、ノートＰＣなど、ユーザが操作可能な端末である。

携帯端末１２は端末装置の一例である。携帯端末１２は、無線による通信の手段または有線による通信の手段を有している。携帯端末１２は、スマートフォンや携帯電話、タブレットＰＣ、ノートＰＣなど、ユーザが携帯可能な端末である。

画像形成装置１４は複合機などの画像形成機能を有する装置である。画像形成装置１４は無線による通信の手段または有線による通信の手段を有する。画像形成装置１４は複合機、コピー機、スキャナ、プリンタ、レーザプリンタなど、画像形成に係る処理を行う装置である。プロジェクタ１５は画像を投影する装置である。プロジェクタ１５は無線による通信の手段または有線による通信の手段を有する。

図１では、一例としてクライアント端末１１、携帯端末１２、画像形成装置１４、プロジェクタ１５、その他の機器１６がそれぞれ一台である例を示しているが複数台であってもよい。

ネットワークＮ２はアクセス制御装置２１によってインターネット等のネットワークＮ４に接続されている。ネットワークＮ２はアクセス制御装置２１によってセキュリティが保護されている。ネットワークＮ２にはプリントサービス提供装置２２、スキャンサービス提供装置２３、管理設定サービス提供装置２４、他サービス提供装置２５が接続されている。図１のシステム１は、アクセス制御装置２１、プリントサービス提供装置２２、スキャンサービス提供装置２３、管理設定サービス提供装置２４、他サービス提供装置２５がサービス提供システムを実現している。

アクセス制御装置２１はプリントサービス提供装置２２が提供するプリントサービスやスキャンサービス提供装置２３が提供するスキャンサービス、管理設定サービス提供装置２４が提供する管理設定サービスなど、各サービスへのログインを制御する。

アクセス制御装置２１、プリントサービス提供装置２２、スキャンサービス提供装置２３、管理設定サービス提供装置２４、他サービス提供装置２５は、一台以上の情報処理装置（コンピュータシステム）によって実現される。

なお、図１のシステム１のプリントサービス提供装置２２、スキャンサービス提供装置２３、管理設定サービス提供装置２４、他サービス提供装置２５は一台のコンピュータに統合して実現してもよいし、複数のコンピュータに分散して実現してもよい。

ネットワークＮ３はアクセス制御装置３１によってインターネット等のネットワークＮ４に接続されている。ネットワークＮ３はアクセス制御装置３１によってセキュリティが保護されている。ネットワークＮ３には１つ以上の外部サービス提供装置３２が接続されている。図１のシステム１は、アクセス制御装置３１、外部サービス提供装置３２が外部サービスシステムを実現している。

アクセス制御装置３１は、外部サービス提供装置３２が提供する外部サービスへのログインを制御する。アクセス制御装置３１、外部サービス提供装置３２は、一台以上の情報処理装置（コンピュータシステム）によって実現される。なお、図１のシステム１の外部サービス提供装置３２は、一台のコンピュータに統合して実現してもよいし、複数のコンピュータに分散して実現してもよい。

ネットワークＮ２側のサービスの一部はネットワークＮ２以外にあってもよい。携帯端末１２は、オフィス内ネットワーク等のネットワークＮ１以外にあってもよい。図１のシステム１では携帯端末１２がネットワークＮ１と、インターネットなどのネットワークＮ４とにある例を示している。また、図１のシステム１では外部サービスシステムが１つの例を示しているが複数であってもよい。

図１のシステム１では、ＯＡｕｔｈと呼ばれるＡＰＩ認可の標準的技術を利用しているものとする。サービス提供システムはＯＡｕｔｈのコンシューマ（Consumer）に相当する。外部サービスシステムはＯＡｕｔｈのサービスプロバイダ（Service Provider :SP）に相当する。

外部サービスシステムがＷｅｂＡＰＩ（Application Programming Interface）を公開しているものとする。ユーザはＷｅｂＡＰＩを通じて自身の権限の範囲内で、外部サービスシステムに保存されているリソースや、そのリソースを扱うサービスへのアクセスが可能である。

また、サービス提供システムのプリントサービス提供装置２２などは、ユーザから委譲された権限に基づく認可トークンを利用することで、ユーザから委譲された権限の範囲内で外部サービスシステムに保存されているリソースや、そのリソースを扱うサービスへのアクセスが可能となる。

＜ハードウェア構成＞
クライアント端末１１、携帯端末１２、アクセス制御装置２１、プリントサービス提供装置２２、スキャンサービス提供装置２３、管理設定サービス提供装置２４、他サービス提供装置２５は、例えば図２に示すハードウェア構成のコンピュータシステムにより実現される。また、アクセス制御装置３１、外部サービス提供装置３２も、例えば図２に示すハードウェア構成のコンピュータシステムにより実現される。

図２は本実施形態に係るコンピュータシステムの一例のハードウェア構成図である。図２に示したコンピュータシステム５００は、入力装置５０１、表示装置５０２、外部Ｉ／Ｆ５０３、ＲＡＭ（Random Access Memory）５０４、ＲＯＭ（Read Only Memory）５０５、ＣＰＵ（Central Processing Unit）５０６、通信Ｉ／Ｆ５０７、及びＨＤＤ（Hard Disk Drive）５０８などを備え、それぞれがバスＢで相互に接続されている。

入力装置５０１はキーボードやマウス、タッチパネルなどを含み、ユーザが各操作信号を入力するのに用いられる。表示装置５０２はディスプレイなどを含み、コンピュータシステム５００による処理結果を表示する。

通信Ｉ／Ｆ５０７はコンピュータシステム５００をネットワークＮ１〜Ｎ４に接続するインタフェースである。これにより、コンピュータシステム５００は通信Ｉ／Ｆ５０７を介してデータ通信を行うことができる。

ＨＤＤ５０８はプログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、例えばコンピュータシステム５００全体を制御する基本ソフトウェアであるＯＳ（Operating System）や、ＯＳ上において各種機能を提供するアプリケーションソフトウェアなどがある。ＨＤＤ５０８は格納しているプログラムやデータを所定のファイルシステム及び／又はＤＢ（データベース）により管理している。

外部Ｉ／Ｆ５０３は、外部装置とのインタフェースである。外部装置には、記録媒体５０３ａなどがある。これにより、コンピュータシステム５００は外部Ｉ／Ｆ５０３を介して記録媒体５０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体５０３ａにはフレキシブルディスク、ＣＤ（Compact Disk）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（SD Memory card）、ＵＳＢメモリ（Universal Serial Bus memory）などがある。

ＲＯＭ５０５は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ５０５には、コンピュータシステム５００の起動時に実行されるＢＩＯＳ（Basic Input/Output System）、ＯＳ設定、及びネットワーク設定などのプログラムやデータが格納されている。ＲＡＭ５０４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。

ＣＰＵ５０６は、ＲＯＭ５０５やＨＤＤ５０８などの記憶装置からプログラムやデータをＲＡＭ５０４上に読み出し、処理を実行することで、コンピュータシステム５００全体の制御や機能を実現する演算装置である。

クライアント端末１１、携帯端末１２、アクセス制御装置２１、プリントサービス提供装置２２、スキャンサービス提供装置２３、管理設定サービス提供装置２４、他サービス提供装置２５は、コンピュータシステム５００のハードウェア構成により、後述するような各種処理を実現できる。また、アクセス制御装置３１、外部サービス提供装置３２も、コンピュータシステム５００のハードウェア構成により、後述するような各種処理を実現できる。

＜ソフトウェア構成＞
《サービス提供システム》
本実施形態に係るサービス提供システムは例えば図３に示す処理ブロックにより実現される。図３は本実施形態に係るサービス提供システムの一例の処理ブロック図である。図３のサービス提供システム５０は、プログラムを実行することにより、サービスアプリ５１、プラットフォーム５２、管理データ記憶部５３及びプラットフォームＡＰＩ（Application Programming Interface）５４を実現している。

図３のサービスアプリ５１は、プリントサービスアプリ６１、スキャンサービスアプリ６２、管理設定サービスアプリ６３、１つ以上のその他のサービスアプリ６４を一例として有する。プリントサービスアプリ６１はプリントサービスを提供するアプリケーションである。スキャンサービスアプリ６２はスキャンサービスを提供するアプリケーションである。管理設定サービスアプリ６３は管理設定サービスを提供するアプリケーションである。また、その他のサービスアプリ６４は何らかのサービスを提供するアプリケーションである。

プラットフォームＡＰＩ５４はプリントサービスアプリ６１、スキャンサービスアプリ６２、管理設定サービスアプリ６３、その他のサービスアプリ６４などのサービスアプリ５１が、プラットフォーム５２を利用するためのインタフェースである。プラットフォームＡＰＩ５４はサービスアプリ５１からの要求をプラットフォーム５２が受信するために設けられた予め定義されたインタフェースであり、例えば関数やクラス等により構成される。なお、サービス提供システム５０を複数の情報処理装置に分散して構成する場合、プラットフォームＡＰＩ５４にはネットワーク経由で利用可能な例えばＷｅｂ ＡＰＩを利用できる。

図３のプラットフォーム５２は、認証処理部７１、機器通信部７２、セッション管理部７３、データ処理部７４を一例として有する。認証処理部７１はクライアント端末１１や画像形成装置１４などのオフィス機器からのログイン要求に基づいて認証を実行する。オフィス機器は、クライアント端末１１、携帯端末１２、画像形成装置１４、プロジェクタ１５、その他の機器１６などの総称である。機器通信部７２はオフィス機器や外部サービスシステムとの通信を実行する。セッション管理部７３は、オフィス機器や外部サービスシステムとのセッションを管理する。データ処理部７４はサービスアプリ５１からの要求に基づいてデータ処理を実行する。

管理データ記憶部５３は組織管理情報記憶部８１、ユーザ管理情報記憶部８２、機器管理情報記憶部８３、認可設定情報記憶部８４、外部サービス情報記憶部８５、認可トークン情報記憶部８６、データ管理情報記憶部８７、データストレージ８８を一例として有する。

組織管理情報記憶部８１は、後述の組織管理情報を記憶する。ユーザ管理情報記憶部８２は後述のユーザ管理情報を記憶する。機器管理情報記憶部８３は後述の機器管理情報を記憶する。認可設定情報記憶部８４は後述の認可設定情報を記憶する。外部サービス情報記憶部８５は後述の外部サービス情報を記憶する。認可トークン情報記憶部８６は後述の認可トークン情報を記憶する。データ管理情報記憶部８７はデータ管理情報を記憶する。データストレージ８８はその他のデータ等を記憶する。

サービス提供システム５０は、例えば認証や非同期変換といった機能を有するクラウド基盤と、クラウド基盤の機能を利用してプリントサービス等のサービス提供を行うサービス群と、各サービスの管理設定を行う管理設定サービスとして機能する。

クラウド基盤は、例えばプラットフォーム５２、管理データ記憶部５３、プラットフォームＡＰＩ５４によって構成される。サービス群は例えばサービスアプリ５１によって構成される。管理設定サービスは例えば管理設定サービスアプリ６３によって構成される。

サービス提供システム５０のクラウド基盤が有する認証の機能は、例えば認証処理部７１と、認証用データベースにより構成される。認証用データベースは組織管理情報記憶部８１、ユーザ管理情報記憶部８２、機器管理情報記憶部８３、認可設定情報記憶部８４、外部サービス情報記憶部８５、認可トークン情報記憶部８６などにより構成される。

また、サービス提供システム５０のクラウド基盤が有する非同期変換の機能は、例えばデータ処理部７４と、データ管理情報記憶部８７と、データストレージ８８により構成される。

サービスアプリ５１などのサービス群はサービス提供システム５０のクラウド基盤が有する認証や非同期変換といった機能を利用し、サービスの提供を行う。また、サービス群は外部サービスシステムの機能と連携してサービスを提供する場合、クラウド基盤が有する認証の機能を介して、外部サービスシステムにアクセスするための認可トークンを取得する。

管理設定サービスアプリ６３が行う管理設定には認可処理の管理設定が含まれる。管理設定サービスアプリ６３は認可手続きを行う為のＵＩを備える。管理設定サービスアプリ６３は認証処理部７１と連携し、後述の認可設定情報を登録する。

なお、外部サービスシステムはサービス提供システム５０以外のシステムであり、クラウドサービスなどのサービスを提供する。本実施例では外部サービスシステムが提供するサービス（機能）を外部サービスと呼んでいる。外部サービスにはクラウドサービスとして提供されているオンラインストレージサービス、スキャン文書の保管・管理サービスなどが含まれる。

外部サービスシステムはサービス提供システム５０の認証処理部７１からの要求に応じて認可トークンを発行する認可サーバとしての機能を有する。また、外部サービスシステムはＷｅｂＡＰＩが整備されている。外部サービスシステムのＷｅｂＡＰＩは認可トークンを利用した処理の要求を受け付け、サービス提供システム５０のサービスアプリ５１にサービスを提供するために利用される。

図３のサービス提供システム５０は認可クライアントとしての機能を認証処理部７１が有することで、複数のサービスアプリ５１が共通に利用する組織管理情報、ユーザ管理情報、機器管理情報、認可設定情報、外部サービス情報、認可トークン情報を一元管理することができ、セキュリティ性の向上と共に管理コストを低減できる。

また、サービス提供システム５０は認可設定情報、外部サービス情報、認可トークンなどの認可情報の管理処理と、認可処理とを認証処理部７１に一元化することで、ユーザによる一度の認可手続きにより、サービスアプリ５１によらず、複数のサービスを連携させる様々なマッシュアップサービスを提供できる。

なお、図３のサービス提供システム５０は組織管理情報、ユーザ管理情報、機器管理情報、認可設定情報、外部サービス情報など、永続的に保存が必要となる情報を例えばＨＤＤ５０８に保存する。また、図３のサービス提供システム５０は認可トークン情報など有効期限が決まっており、組織管理情報、ユーザ管理情報、機器管理情報、認可設定情報、外部サービス情報などの他の情報よりライフサイクルが短い情報を、ＨＤＤ５０８に替えて例えばＲＡＭ５０４に（オンメモリ上に）保存してもよい。オンメモリ上に保存することで、認可トークン情報の読み出し／書き込みは高速になり、レスポンスが高速化する。

《管理設定サービスアプリ６３》
管理設定サービスアプリ６３は、例えば図４に示す処理ブロックにより実現される。図４は本実施形態に係る管理設定サービスアプリの一例の処理ブロック図である。管理設定サービスアプリ６３はコンピュータシステム５００を、画面処理部１０１、情報登録要求部１０２として機能させる。

画面処理部１０１は管理設定情報を設定させる管理者向けの設定画面の生成など、画面に関する処理を行う。情報登録要求部１０２は画面処理部１０１が生成した設定画面などの画面に入力された情報の登録を認証処理部７１に要求する。

《認証処理部７１》
認証処理部７１は例えば図５に示す処理ブロックにより実現される。図５は本実施形態に係る認証処理部の一例の処理ブロック図である。認証処理部７１は、認証部１１１、情報登録部１１２、リダイレクト要求部１１３、認可トークン取得部１１４、認可トークン保存部１１５、認可トークン提供部１１６を有する。

認証部１１１は認証の要求を受け付け、認証チケットを発行する。情報登録部１１２は情報登録の要求を受け付け、情報を登録する。リダイレクト要求部１１３は管理者が操作するクライアント端末１１などのオフィス機器に所定の画面に対するリダイレクトを要求する。認可トークン取得部１１４は認可設定情報記憶部８４に記憶されている認可設定情報及び外部サービス情報記憶部８５に記憶されている外部サービス情報を利用して、外部サービスシステムから認可トークンを取得する。認証トークン保存部１１５は外部サービスシステムから取得した認可トークンを、認可トークン情報記憶部８６に保存する。

認可トークン提供部１１６は認可トークン取得の要求を受け付け、認可トークン情報記憶部８６に提供できる認可トークンがあれば提供する。なお、認可トークン提供部１１６は提供できる認可トークンが無ければ、認可トークンの取得を認可トークン取得部１１４に要求し、取得した認可トークンを提供する。

《サービスアプリ５１》
サービスアプリ５１は、例えば図６に示す処理ブロックにより実現される。図６は本実施形態に係るサービスアプリの一例の処理ブロック図である。サービスアプリ５１はコンピュータシステム５００を、認証要求部１２１、画面処理部１２２、認可トークン取得要求部１２３、処理要求部１２４として機能させる。

認証要求部１２１は認証処理部７１に認証を要求する。画面処理部１２２はログイン画面の生成など、画面に関する処理を行う。認可トークン取得要求部１２３は外部サービスシステムのＷｅｂＡＰＩを利用するために必要となる認可トークンの取得を、認証処理部７１に要求する。処理要求部１２４は認可トークンを利用し、外部サービスシステムのＷｅｂＡＰＩに処理を要求する。処理要求部１２４はデータ処理部７４に非同期変換などの非同期処理を要求することもできる。

《データ処理部７４》
データ処理部７４は例えば図７に示す処理ブロックにより実現される。図７は本実施形態に係るデータ処理部の一例の処理ブロック図である。データ処理部７４は、非同期Ｆｒｏｎｔ（フロント）部１３１、非同期Ｗｏｒｋｅｒ（ワーカ）部１３２を有する。

非同期Ｆｒｏｎｔ部１３１はサービスアプリ５１から非同期処理の要求をジョブとして受け付け、データ管理情報記憶部８７にジョブとして保存する。データ管理情報記憶部８７はメッセージキューとして機能する。

非同期Ｗｏｒｋｅｒ部１３２はデータ管理情報記憶部８７から順次、ジョブを取得して非同期処理を実行する。外部サービスシステムを利用する場合、非同期Ｗｏｒｋｅｒ部１３２は認証処理部７１に外部サービスシステムの認可トークンを要求し、認可トークンを取得する。

《管理データ》
図８は組織管理情報の一例の構成図である。図８の組織管理情報はデータ項目としてｉｄ、組織ＩＤ、組織名などを有する。ｉｄは組織管理情報のレコードを一意に特定する情報である。組織ＩＤは、企業、部署などの組織を一意に特定する情報である。組織ＩＤは組織という言語に限定されるものでなく、例えば契約を識別する情報であってもよい。サービス提供システム５０は提供する各種サービスを組織ＩＤ単位で管理する。よって組織が利用する各サービスは組織ＩＤに紐付けて登録され、組織のユーザは組織ＩＤに紐付けて登録されたサービスを利用することが出来る。従って組織ＩＤは、サービス提供システム５０がサービスを提供するサービス提供対象を管理するサービス提供対象管理情報としての役割を持つ。組織名は組織の名称である。

図９はユーザ管理情報の一例の構成図である。図９のユーザ管理情報はデータ項目としてｉｄ、組織ＩＤ、ユーザＩＤ、パスワード、ユーザ名などを有する。ｉｄはユーザ管理情報のレコードを一意に特定する情報である。ユーザＩＤ、パスワードはサービス提供システム５０の認証基盤においてユーザを特定する情報である。ユーザ名はユーザの名前である。パスワードは必須でない。

さらに、ユーザＩＤはユーザが所持する電子媒体（例えばＩＣカード）の識別番号などを代わりに用いてもよい。組織ＩＤと対応付けられたユーザＩＤ、パスワードは一意であるが、組織ＩＤが異なれば重複していてもよい。

図１０は機器管理情報の一例の構成図である。図１０の機器管理情報はデータ項目としてｉｄ、組織ＩＤ、デバイス認証情報、事業所情報、ケーパビリティなどを有する。ｉｄは機器管理情報のレコードを一意に特定する情報である。デバイス認証情報はオフィス機器が特定の条件を備えたものであることを判別するデバイス認証のための情報である。デバイス認証情報は特定のアプリケーションが搭載されていることを示すＩＤや、特定の機器であることを示す機器番号などであってもよい。事業所情報は例えばオフィス機器が設置されている事業所を表している。また、ケーパビリティは例えばオフィス機器の能力を表している。

図１１は認可設定情報の一例の構成図である。図１１の認可設定情報は、データ項目として認可設定情報ＩＤ、外部サービスＩＤ（ＳＰ＿ＩＤ）、スコープ、クライアントＩＤ、リフレッシュトークン、組織ＩＤ、ユーザＩＤなどを有する。

認可設定情報ＩＤは、認可設定情報のレコードを一意に特定する情報である。外部サービスＩＤは外部サービスシステムを一意に特定する情報である。スコープは外部サービスシステムのサービス範囲を特定する情報である。クライアントＩＤはサービス提供システム５０のサービス群を特定する情報である。クライアントＩＤは事前に外部サービスシステムによって発行される。リフレッシュトークンは認可トークンを再発行する為に必要なトークンである。

図１２は外部サービス情報の一例の構成図である。図１２の外部サービス情報は、データ項目として外部サービスＩＤ、クライアントＩＤ、クライアントシークレット、プロダクト名、認可サーバＵＲＬ、リダイレクト先ＵＲＬなどを有する。

クライアントシークレットはクライアントＩＤの本人性を保証する為のパスワード的な存在としての秘密情報である。プロダクト名はクライアントＩＤと紐付ける形で事前に登録された、サービスアプリ５１を特定する情報である。認可サーバＵＲＬは管理者による認可判断前にリダイレクトされる先のＵＲＬ（外部サービスシステムの認可サーバとしての機能のＵＲＬ）である。リダイレクト先ＵＲＬは認可判断後にリダイレクトされる先のＵＲＬ（認証処理部７１の認可クライアントとしての機能のＵＲＬ）である。

図１３は認可トークン情報の一例の構成図である。図１３の認可トークン情報はデータ項目としてｉｄ、組織ＩＤ、ユーザＩＤ、外部サービスＩＤ、スコープ、認可トークン、有効期限などを有する。ｉｄは、認可トークン情報のレコードを一意に特定する情報である。認可トークンは外部サービスシステムから取得したアクセストークンである。有効期限は認可トークンの有効期限である。

＜処理の詳細＞
以下では、本実施形態に係るシステム１の処理の詳細について説明する。

《認可設定情報の登録及び認可トークン情報の保存》
図１４は認可設定情報の登録及び認可トークン情報の保存の処理手順の一例を表したシーケンス図である。ステップＳ１において、認証処理部７１は管理者の操作するクライアント端末１１などのオフィス機器から組織ＩＤ、ユーザＩＤ、パスワードなどのアカウント情報を用いたログイン要求を受け付ける。

認証処理部７１は組織ＩＤ、ユーザＩＤ、パスワードなどのアカウント情報を用いた認証の要求を受け付けると、ユーザ管理情報記憶部８２に記憶されているユーザ管理情報を参照し、そのアカウント情報の認証を行う。アカウント情報の認証に成功すると認証処理部７１は管理者の認証チケット（管理者チケット）を生成する。

ステップＳ２において、認証処理部７１はログイン要求元であるオフィス機器に管理者チケットを返す。以後、オフィス機器は認証チケットを用いることでサービス提供システム５０の機能が利用可能となる。なお、認証処理部７１は管理者チケットとアカウント情報とを紐付けて管理する。

ステップＳ３において、管理設定サービスアプリ６３は管理者の操作するオフィス機器から管理者チケットを用いた設定画面の表示要求を受け付ける。管理設定サービスアプリ６３は管理者チケットから設定画面の表示要求元が管理者であることを識別する。管理設定サービスアプリ６３はステップＳ４において、管理者向けの設定画面を、管理者の操作するオフィス機器に表示させる。管理者向けの設定画面には、登録が可能な認可設定情報が表示される。

ステップＳ５において、管理者はオフィス機器を操作し、管理者向けの設定画面から認可設定を適用させたいユーザのユーザＩＤ、利用したい外部サービスの外部サービスＩＤ及びスコープを選択する。ステップＳ６において、管理設定サービスアプリ６３は管理者によって選択された認可設定情報の登録要求を認証処理部７１に対して行う。

ステップＳ７において、認証処理部７１は登録要求のあった認可設定情報に認可設定情報ＩＤを採番し、認可設定情報を認可設定情報記憶部８４に登録する。ステップＳ８及びＳ９において、管理者の操作するオフィス機器にはリターンとして認可設定情報ＩＤが返される。なお、管理設定サービスアプリ６３は認証処理部７１に問い合わせることで認可設定情報ＩＤを取得し、オフィス機器に提供するようにしてもよい。

ステップＳ１０において、管理者はオフィス機器を操作し、管理者チケット、対象とするユーザのユーザＩＤ、認可設定情報ＩＤを用いて、認証処理部７１に認可手続きの要求を行う。

ステップＳ１１において、認証処理部７１は認可手続きの要求に含まれるユーザＩＤ及び認可設定情報ＩＤをキーとし、認可設定情報記憶部８４に記憶されている認可設定情報及び外部サービス情報記憶部８５に記憶されている外部サービス情報から認可に必要なパラメータの少なくとも一部を取得する。

認可に必要なパラメータとしては、外部サービスＩＤ、スコープ、サービスアプリ５１を一意に識別するクライアントＩＤ、管理者による認可判断後にリダイレクトされる先のリダイレクト先ＵＲＬ、セッションを維持する為の任意のセッションキーなどがある。ステップＳ１２において、認証処理部７１は外部サービス情報記憶部８５に記憶されている外部サービス情報から認可サーバＵＲＬを取得し、認可に必要なパラメータをＧＥＴリクエストのクエリとして認可サーバＵＲＬにリダイレクトさせる。

なお、セッションを維持する為の任意のセッションキーは以下の理由により必要なものである。管理者が認可を下す認可画面は外部サービスシステムによって表示される。認証処理部７１は管理者による認可判断後にリダイレクトされるため、ＨＴＴＰレベルでのセッションが途切れることになる。認証処理部７１は認可コードを取得するための一連の流れを同一セッション内で実施するため、任意のセッションキーを利用している。

なお、ＯＡｕｔｈは仕組み上、任意のセッションキーを指定可能なプロトコルとなっている。本実施形態のシステム１では、セッションキーに認可設定情報ＩＤを指定することでリダイレクトされた際に認可設定情報ＩＤが渡されるため、管理者が認可したユーザ及び認可内容が分かるようになっている。

リダイレクトされた外部サービスシステムは、要求元の管理者が登録済みのユーザであることを検証するため、ｃｏｏｋｉｅ情報などから管理者チケットを確認する。例えば管理者が既に外部サービスシステムにログイン済みの場合は、ブラウザに管理者チケットがキャッシュされているため、管理者チケットが存在する。一方、管理者が外部サービスシステムに未ログインの場合、管理者チケットは存在しない。この場合、外部サービスシステムは図１５に示すようなログイン画面１０００を、管理者の操作するオフィス機器に表示してログインを促す。

図１５はログイン画面の一例のイメージ図である。図１５のログイン画面１０００は外部サービスのユーザＩＤの一例としてのメールアドレス、外部サービスのパスワードを入力させる欄１００１と、ログインボタン１００２とを有する。管理者はオフィス機器を操作し、ログイン画面１０００の欄１００１を入力した後でログインボタン１００２を押下する。

ログインボタン１００２が押下されると、管理者の操作するオフィス機器はステップＳ１３において、外部サービスのユーザＩＤ、パスワードを用いて外部サービスシステムにログインを要求する。ログインに成功すると、外部サービスシステムはステップＳ１４において、ログイン済みの管理者が操作するオフィス機器に、図１６に示すような認可画面１０１０を表示して認可判断を促す。なお、ステップＳ１３の処理は管理者がログイン済みの場合に省略される。

管理者はクライアントＩＤに紐付ける形で事前に認可設定情報又は外部サービス情報の一部として登録されたプロダクト名及びスコープから、認可する対象が何かを確認し、認可の判定を行う。認可する場合、管理者は認可画面１０１０の認可ボタン１０１１を押下する。

認可ボタン１０１１が押下されると、管理者の操作するオフィス機器はステップＳ１５において、クライアントＩＤ、スコープ、リダイレクト先ＵＲＬ、ユーザＩＤ、認可設定情報ＩＤを用いて外部サービスシステムに認可の決定を通知する。認可の決定が通知されると、外部サービスシステムはステップＳ１６において、認可が認められたことを示す認可コードと、セッションキーの一例としての認可設定情報ＩＤとをクエリに付けてリダイレクト先ＵＲＬにリダイレクトさせる。

ステップＳ１７において、管理者の操作するオフィス機器は認可判断後のリダイレクト先であるリダイレクト先ＵＲＬに対して、管理者チケット、認可コード、認可設定情報ＩＤを送信する。なお、図１４ではリダイレクト先ＵＲＬが認証処理部７１である例を示している。

ステップＳ１８において、認証処理部７１は認可設定情報ＩＤをキーとし、認可設定情報記憶部８４に記憶されている認可設定情報及び外部サービス情報記憶部８５に記憶されている外部サービス情報から認可トークン（図１４中のアクセストークン）の取得に必要なパラメータの少なくとも一部を取得する。例えばステップＳ１８において、認証処理部７１はユーザＩＤ、外部サービスＩＤ、クライアントＩＤ、クライアントシークレットを取得する。なお、認可トークンの取得に必要なパラメータとしては、例えばクライアントＩＤ、クライアントシークレット、認可コードなどがある。

ステップＳ１９において、認証処理部７１は外部サービスシステムのＷｅｂＡＰＩにアクセスする為に必要な認可トークンを外部サービスシステムから取得するため、クライアントＩＤ、クライアントシークレット、クエリとして付与された認可コードを、リクエスト情報として外部サービスシステムに送信する。ステップＳ２０において、外部サービスシステムは認可コードを検証し、認可トークン、リフレッシュトークン、有効期限を認証処理部７１に対して発行し、認証処理部７１に提供する。

なお、認可トークンはＷｅｂＡＰＩにアクセスするために必要なトークンである。一般的に認可トークンは有効期限が設定されており、有効期限が切れるとＷｅｂＡＰＩにアクセスできなくなる。リフレッシュトークンは認可トークンを再発行するために必要なトークンである。

ステップＳ２１において、認証処理部７１は外部サービスシステムから提供された認可トークン及び有効期限をユーザ情報（組織ＩＤ、ユーザＩＤ）及び外部サービスＩＤと紐付ける形で、認可トークン情報記憶部８６に認可トークン情報として保存する。また、認証処理部７１はリフレッシュトークンをユーザ情報及び外部サービスＩＤと紐付ける形で認可設定情報記憶部８４に記憶されている認可設定情報に保存する。そして、ステップＳ２２において、認証処理部７１は管理設定サービスアプリ６３のＵＲＬに対し、ユーザＩＤと認可結果を表す値とをクエリとしてリダイレクトさせる。

ステップＳ２３において、管理者の操作するオフィス機器は管理設定サービスアプリ６３のＵＲＬに対し、管理者チケット、企業ＩＤ、ユーザＩＤ、認可結果を表す値を送信して結果画面の表示を要求する。ステップＳ２４において、管理設定サービスアプリ６３は管理者の操作するオフィス機器に結果画面を表示させる。

《外部サービスの利用》
図１７は外部サービスを利用する処理手順の一例を表したシーケンス図である。図１７のシーケンス図は、サービスアプリ５１が認可トークンを取得して、外部サービスを利用する処理を示している。

サービスアプリ５１はユーザの操作するクライアント端末１１などのオフィス機器から組織ＩＤ、ユーザＩＤ、パスワードなどのアカウント情報を用いたログイン要求を受け付ける。ステップＳ３１において、サービスアプリ５１は受け付けたログイン要求に含まれる組織ＩＤ、ユーザＩＤ、パスワードを用いて認証処理部７１に認証を要求する。

認証処理部７１は組織ＩＤ、ユーザＩＤ、パスワードなどのアカウント情報を用いた認証の要求を受け付けると、ユーザ管理情報記憶部８２に記憶されているユーザ管理情報を参照し、そのアカウント情報の認証を行う。アカウント情報の認証に成功すると認証処理部７１はユーザの認証チケットを生成する。ステップＳ３２において、認証処理部７１はサービスアプリ５１に認証チケットを返す。サービスアプリ５１はログイン要求元のオフィス機器に認証チケットを返す。

以後、オフィス機器は認証チケットを用いることでサービス提供システム５０の機能が利用可能となる。なお、認証処理部７１は認証チケットとユーザ情報とを紐付けて管理する。

ステップＳ３３において、サービスアプリ５１はユーザの操作するオフィス機器から外部サービスとの連携要求を受け付ける。ステップＳ３３において、サービスアプリ５１は例えば図１８に示すような外部サービス連携要求画面を生成し、ユーザの操作するオフィス機器に外部サービス連携要求画面を表示させる。

図１８は外部サービス連携要求画面の一例のイメージ図である。図１８の外部サービス連携要求画面１０３０は、一例としてファイルアップロード連携画面を示している。外部サービス連携要求画面１０３０は、連携する外部サービスをユーザに選択させるラジオボタン１０３１と、アップロードボタン１０３２とを有する。ユーザはオフィス機器を操作して、連携する外部サービスを選択した後でアップロードボタン１０３２を押下する。

図１８の外部サービス連携要求画面１０３０では、ユーザが連携する外部サービスを選択する例を表している。アップロードボタン１０３２が押下されると、サービスアプリ５１は図１７のステップＳ３４以降の処理を開始する。ステップＳ１４において、サービスアプリ５１は外部サービス連携要求画面１０３０から選択された外部サービスの外部サービスＩＤと、ステップＳ３２で取得した認証チケットとを用いて認証処理部７１に認可トークンの取得を要求する。

ステップＳ３５において、認証処理部７１は、認可トークンの取得の要求に含まれる認証チケットを用いて、認証チケットに紐付くユーザ情報を取得する。ステップＳ３６において認証処理部７１は、認証チケットに紐付くユーザ情報と、外部サービス連携要求画面１０３０からユーザにより選択された外部サービスの外部サービスＩＤと、に紐付く認可トークンの取得を認可トークン情報記憶部８６に要求する。

ユーザ情報と外部サービスＩＤとに紐付く認可トークンが認可トークン情報記憶部８６に保存されていれば、ステップＳ３７において、認証処理部７１は認可トークン情報記憶部８６から認可トークン及び有効期限を取得する。

一方、ユーザ情報と外部サービスＩＤとに紐付く認可トークンが認可トークン情報記憶部８６に保存されていなければ、ステップＳ３７において、認証処理部７１は認可トークン情報記憶部８６から該当する認可トークンが無いことを示すｆａｌｓｅを受信する。

認証処理部７１は認可トークン情報記憶部８６から有効期限内の認証トークンを取得すると、ステップＳ４３において、認可トークンの取得の要求元のサービスアプリ５１に認可トークンを提供する。

一方、認証処理部７１は認可トークン情報記憶部８６から有効期限内の認証トークンを取得できなければ、ステップＳ３８において、認可トークンの取得を認可トークン取得部１１４に要求する。

ステップＳ３９において、認可トークン取得部１１４はユーザ情報と外部サービスＩＤとに紐付くリフレッシュトークンを認可設定情報記憶部８４から取得する。認可トークン取得部１１４はリフレッシュトークンを用いて、外部サービスシステムに認可トークンを要求する。

ステップＳ４０において、認可トークン取得部１１４は外部サービスシステムから認可トークンと有効期限とを取得する。ステップＳ４１において、認可トークン取得部１１４は外部サービスシステムから取得した認可トークンと有効期限とを認証処理部７１に提供する。

ステップＳ４２において、認証処理部７１は認可トークン取得部１１４から提供された認可トークンと有効期限とを、ユーザ情報、外部サービスＩＤに紐付けて認可トークン情報記憶部８６に保存する。その後、ステップＳ４３において、認証処理部７１は認可トークンの取得の要求元のサービスアプリ５１に認可トークンを提供する。そして、ステップＳ４４以降において、サービスアプリ５１は提供された認可トークンを用いて外部サービスシステムのＷｅｂＡＰＩに処理を要求できる。

なお、同一のユーザ情報及び外部サービスＩＤに紐付けられた認可トークンは異なるサービスアプリ５１間で共有できるため、外部サービスシステムとのセッション情報を削減することができ、外部サービスシステムに与える負荷も下げることができる。

《非同期処理と外部サービスシステムとの連携》
図１９は非同期処理と外部サービスシステムとが連携する処理手順の一例を表したシーケンス図である。図１９のシーケンス図は、データ処理部７４の非同期Ｗｏｒｋｅｒ部１３２が行う非同期処理の一例としてのＯＣＲ変換処理を行った後、外部サービスシステムにアップロードする処理を示している。

図１９に示すように非同期処理の一例としてのＯＣＲ変換処理を行った後、外部サービスシステムを利用する場合は、非同期Ｗｏｒｋｅｒ部１３２に外部サービスシステムとのやり取りを依存する。通常、サービスアプリ５１が認証処理部７１から外部サービスの認可トークンを取得する場合は、認証処理部７１の認証チケットが必要となる。

しかし、非同期処理の場合は非同期Ｗｏｒｋｅｒ部１３２が認証チケットを用いて認証処理部７１に外部サービスの認可トークンの取得を要求したとき、認証チケットが期限切れの可能性があった。そこで、本実施形態のサービス提供システム５０では非同期Ｗｏｒｋｅｒ部１３２を信頼し、外部サービスの認可トークンの取得の要求の際の認証チケットを不要としている。

例えば認証処理部７１と非同期Ｗｏｒｋｅｒ部１３２とを同一ネットワークに配置することで、非同期Ｗｏｒｋｅｒ部１３２を信頼する。同一ネットワークに配置された非同期Ｗｏｒｋｅｒ部１３２であるか否かは例えばＩＰアドレスによって判断できる。また、認証処理部７１と非同期Ｗｏｒｋｅｒ部１３２との信頼関係の構築にはネットワーク制御の他に、ベーシック認証などの認証機能の導入も考えられる。

例えばＯＣＲ変換処理後に外部サービスシステムへアップロードする処理をユーザから要求されると、サービスアプリ５１はステップＳ５１において、ユーザ情報、外部サービスＩＤ、ジョブ情報を用いてＯＣＲ変換処理後に外部サービスシステムへアップロードする処理を非同期Ｆｒｏｎｔ部１３１に要求する。

ステップＳ５２において、非同期Ｆｒｏｎｔ部１３１はサービスアプリ５１から要求のあったＯＣＲ変換処理後に外部サービスシステムへアップロードする処理をジョブとしてデータ管理情報記憶部８７に登録する。

非同期処理を行う非同期Ｗｏｒｋｅｒ部１３２はデータ管理情報記憶部８７に登録されたジョブを順次取得して処理する。ステップＳ５３において、非同期Ｗｏｒｋｅｒ部１３２はデータ管理情報記憶部８７に登録されていたＯＣＲ変換処理後に外部サービスシステムへアップロードする処理のジョブを取得する。

ステップＳ５５において、非同期Ｗｏｒｋｅｒ部１３２はジョブ情報により指定されているデータをデータストレージ８８から読み出し、ＯＣＲ変換処理を行う。ステップＳ５６において、非同期Ｗｏｒｋｅｒ部１３２はユーザ情報、外部サービスＩＤを用いて、認証処理部７１に認可トークンの取得を要求する。

ステップＳ５７において、認証処理部７１はユーザ情報、外部サービスＩＤに紐付く認可トークンの取得を認可トークン情報記憶部８６に要求する。ステップＳ５８において、認証処理部７１はユーザ情報、外部サービスＩＤに紐付く認可トークンを取得する。ステップＳ５９において、認証処理部７１はユーザ情報、外部サービスＩＤに紐付く認可トークンを非同期Ｗｏｒｋｅｒ部１３２に提供する。

そして、ステップＳ６０において、非同期Ｗｏｒｋｅｒ部１３２は認証処理部７１から提供された認可トークンを用いて、外部サービスシステムにＯＣＲ変換処理後のデータをアップロードできる。

＜まとめ＞
本実施形態に係るシステム１は、例えば以下の４つの問題点を解決できる。

第一の問題点として、従来は外部サービスシステム側が認可画面１０１０を表示するために、ＵＩを有するサービスアプリ５１それぞれがＯＡｕｔｈ認証のクライアント機能を持つことが多かった。よって、従来はサービスアプリ５１毎にＯＡｕｔｈ認証の認証処理を行う必要があり、サービスアプリ５１が個別にセキュリティデータを管理していた。

このため、従来はＯＡｕｔｈ認証に対応したサービスアプリ５１の増加によりセキュリティデータが分散し、セキュリティが低下するという問題があった。また、従来はサービスアプリ５１が個別にセキュリティ対策を行わなければならず、管理コストが増大する問題があった。

本実施形態に係るシステム１は一箇所にＯＡｕｔｈ認証のクライアント機能を集約させることで、セキュリティデータを一元管理でき、セキュリティ性の向上と共に管理コストを低減できる。

第二の問題点として、従来はスコープがサービスアプリ５１毎に異なるため、サービスアプリ５１毎にＯＡｕｔｈ認証の認可処理を行わなければならず、ユーザビリティが低下する問題があった。

本実施形態に係るシステム１は認可設定情報、外部サービス情報、認可トークンなどの認可情報の管理処理と、認可処理とを認証処理部７１に一元化することで、管理者による一度の認可手続きによりサービスアプリ５１の種別に依らず様々なマッシュアップサービスを利用できる。

第三の問題点として、従来はＯＡｕｔｈ認証のプロトコル上、ＨＴＭＬのＵＩを表示できないオフィス機器（デバイス）から認可処理が行えず、ＨＴＭＬのＵＩが無いデバイスからマッシュアップサービスを利用できなかった。

本実施形態に係るシステム１は認可処理と、外部サービスを利用する処理とを分離したことで、ＨＴＭＬのＵＩが無いデバイスからも利用できる。

第四の問題点として、従来は、企業の管理者が企業のユーザに指定の外部サービスシステムの共有リソースにアクセスさせたい場合、ユーザ本人が指定の外部サービスシステムのアカウントを持ち、ユーザ本人によって認可手続きを行わなければならなかった。

本実施形態に係るシステム１は管理者がユーザの認可手続きを代行できるので、指定の外部サービスシステムのみへアクセスを許すような管理が可能となる。例えば本実施形態に係るシステム１は管理ポリシーに沿った認可トークンをユーザに使わせることが可能になる。

このように、本実施形態に係るシステム１は、マルチテナント型アプリケーションにおいてもＯＡｕｔｈ認証のクライアント機能を集約することで、システムとしての複雑さを軽減することができ、管理コストを抑えることができる。また、本実施形態に係るシステム１はセキュリティデータの一元管理がし易く、セキュリティ性を向上できる。

また、本実施形態に係るシステム１は、ユーザによる認可手続きの回数を減らすことによりユーザビリティを向上できる。また、本実施形態に係るシステム１はＵＩが無いデバイスからもマッシュアップサービスを容易に利用できる。さらに、本実施形態に係るシステム１は管理者がユーザの認可手続きを代行することができるので、ユーザに予め決められたリソースのみへのアクセスを許すような管理も可能となる。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

なお、特許請求の範囲に記載した第一のサービス提供システムはサービス提供システム５０に相当し、第二のサービス提供システムは外部サービスシステムに相当する。サービス提供装置はサービス提供システム５０に相当する。認可後の権限情報は認可トークンに相当する。認可後の権限情報を再発行する為に必要な情報はリフレッシュトークンに相当する。

接続先変更手段はリダイレクト要求部１１３に相当し、権限情報取得手段は認可トークン取得部１１４に相当し、権限情報提供手段は認可トークン提供部１１６に相当し、権限情報保存手段は認証トークン保存部１１５に相当する。第一の記憶手段は認可設定情報記憶部８４、外部サービス情報記憶部８５、認可トークン情報記憶部８６に相当する。

権限情報取得要求手段は認可トークン取得要求部１２３に相当し、処理要求手段は処理要求部１２４に相当する。連携処理受付手段は非同期Ｆｒｏｎｔ部１３１に相当し、連携処理実行手段は非同期Ｗｏｒｋｅｒ部１３２に相当する。

１ システム
１１ クライアント端末
１２ 携帯端末
１４ 画像形成装置
１５ プロジェクタ
１６ その他の機器
２１、３１ アクセス制御装置
２２ プリントサービス提供装置
２３ スキャンサービス提供装置
２４ 管理設定サービス提供装置
２５ 他サービス提供装置
３２ 外部サービス提供装置
５０ サービス提供システム
５１ サービスアプリ
５２ プラットフォーム
５３ 管理データ記憶部５３
５４ プラットフォームＡＰＩ（Application Programming Interface）
６１ プリントサービスアプリ
６２ スキャンサービスアプリ
６３ 管理設定サービスアプリ
６４ その他のサービスアプリ
７１ 認証処理部
７２ 機器通信部
７３ セッション管理部
７４ データ処理部
８１ 組織管理情報記憶部
８２ ユーザ管理情報記憶部
８３ 機器管理情報記憶部
８４ 認可設定情報記憶部
８５ 外部サービス情報記憶部
８６ 認可トークン情報記憶部
８７ データ管理情報記憶部
８８ データストレージ
１０１ 画面処理部
１０２ 情報登録要求部
１１１ 認証部
１１２ 情報登録部
１１３ リダイレクト要求部
１１４ 認可トークン取得部
１１５ 認可トークン保存部
１１６ 認可トークン提供部
１２１ 認証要求部
１２２ 画面処理部
１２３ 認可トークン取得要求部
１２４ 処理要求部
１３１ 非同期Ｆｒｏｎｔ（フロント）部
１３２ 非同期Ｗｏｒｋｅｒ（ワーカ）部
５００ コンピュータシステム
５０１ 入力装置
５０２ 表示装置
５０３ 外部Ｉ／Ｆ
５０３ａ 記録媒体
５０４ ＲＡＭ
５０５ ＲＯＭ
５０６ ＣＰＵ
５０７ 通信Ｉ／Ｆ
５０８ ＨＤＤ
Ｂ バス
ＦＷ ファイアウォール
Ｎ１〜Ｎ４ ネットワーク

国際公開第２００９／０８４６０１号

本発明は、クラウドサービス提供システム及びクラウドサービス提供方法に関する。

本発明の実施の形態は、上記の点に鑑みなされたもので、サービス利用のためのユーザによる認可手続きの回数を減らすことができるクラウドサービス提供システム及びクラウドサービス提供方法を提供することを目的とする。

上記目的を達成するため、本願請求項１は、クラウドサービスを提供するアプリケーションを搭載する１以上の情報処理装置を含むクラウドサービス提供システムであって、該クラウドサービス提供システムと認証基盤が異なる外部サービスと接続する前記クラウドサービス提供システムにおいて、第一のユーザが操作する第一の機器から、第二のユーザが前記外部サービスを利用するための認可要求を受け付けると、前記第一の機器の接続先を前記外部サービスに変更させる接続先変更手段と、前記接続先変更手段により接続先が前記外部サービスに変更された前記第一の機器から、前記外部サービスにおける前記第二のユーザの認可が認められたことを示す認可情報を受信すると、該認可情報を前記外部サービスに送信して、前記外部サービスを利用するための認可後の権限情報を前記外部サービスから取得する権限情報取得手段と、前記第二のユーザが操作する第二の機器から前記外部サービスを利用する処理の要求を前記アプリケーションが受信したことに基づいて前記アプリケーションから送信される要求を受信すると、前記第二のユーザに紐付く前記認可後の権限情報を前記アプリケーションに提供する権限情報提供手段と、を有することを特徴とする。

Claims (8)

1. 機器にサービスを提供する第一のサービス提供システムと、前記第一のサービス提供システムと認証基盤が異なる第二のサービス提供システムと、を有するシステムであって、
   第一のユーザが操作する機器から、第二のユーザが前記第二のサービス提供システムを利用するための認可要求を受け付け、前記機器の接続先を前記第二のサービス提供システムに変更して、前記第二のサービス提供システムにおける第二のユーザの認可処理を行わせる接続先変更手段と、
   前記機器から前記認可要求が認められたことを示す認可情報を受信し、前記認可情報を用いて、前記第二のサービス提供システムを利用するための認可後の権限情報を前記第二のサービス提供システムから取得する権限情報取得手段と、
   前記第二のユーザが操作する機器から受け付けた前記第二のサービス提供システムを利用する処理の要求に基づき、前記第二のユーザに紐付く前記認可後の権限情報を提供する権限情報提供手段と、
   を有するシステム。
2. 前記権限情報取得手段が前記第二のサービス提供システムから取得した前記認可後の権限情報を前記第二のユーザのユーザ情報及び前記第二のサービス提供システムの識別情報と紐付けて、第一の記憶手段に保存する権限情報保存手段
   を更に有する請求項１記載のシステム。
3. 前記権限情報取得手段は、前記認可情報を用いて、前記認可後の権限情報、前記認可後の権限情報の有効期限、前記認可後の権限情報を再発行する為に必要な情報を、前記第二のサービス提供システムから取得し、
   前記権限情報保存手段は、前記認可後の権限情報、前記認可後の権限情報の有効期限、前記認可後の権限情報を再発行する為に必要な情報を、前記第二のユーザのユーザ情報及び前記第二のサービス提供システムの識別情報と紐付けて、前記第一の記憶手段に保存する
   ことを特徴とする請求項２記載のシステム。
4. 前記権限情報提供手段は、前記第一の記憶手段に前記第二のユーザのユーザ情報及び前記第二のサービス提供システムの識別情報と紐付く期限切れの前記認可後の権限情報が記憶されていれば前記第一の記憶手段に記憶されている前記認可後の権限情報を再発行する為に必要な情報を用いて、前記権限情報取得手段に前記第二のサービス提供システムから前記認可後の権限情報を取得させる
   ことを特徴とする請求項３記載のシステム。
5. 前記第二のユーザが操作する機器から前記第二のサービス提供システムを利用する処理の要求を受け付け、前記権限情報提供手段に前記第二のユーザに紐付く前記認可後の権限情報の取得を要求する権限情報取得要求手段と、
   取得した前記第二のユーザに紐付く前記認可後の権限情報を用いて、前記第二のサービス提供システムに処理を要求する処理要求手段
   を更に有する請求項１乃至４何れか一項記載のシステム。
6. 前記処理要求手段から非同期処理と前記第二のサービス提供システムとを連携させる連携処理の要求を受け付け、前記連携処理の情報を第二の記憶手段に登録する連携処理受付手段と、
   前記第二の記憶手段から前記連携処理の情報を取得し、前記非同期処理を行ったあとに前記第一の記憶手段から前記第二のユーザと紐付く前記認可後の権限情報を取得し、取得した前記認可後の権限情報を用いて、前記第二のサービス提供システムに処理を要求する連携処理実行手段と
   を更に有する請求項５記載のシステム。
7. 前記第一の記憶手段は、更に、前記第二のユーザのユーザ情報及び前記第二のサービス提供システムの識別情報と紐付けて、前記認可後の権限情報の権限範囲を特定する情報を保存する
   ことを特徴とする請求項２乃至４何れか一項記載のシステム。
8. 機器にサービスを提供するサービス提供装置であって、
   第一のユーザが操作する機器から、第二のユーザが認証基盤の異なるサービス提供システムを利用するための認可要求を受け付け、前記機器の接続先を前記サービス提供システムに変更して、前記サービス提供システムにおける第二のユーザの認可処理を行わせる接続先変更手段と、
   前記機器から前記認可要求が認められたことを示す認可情報を受信し、前記認可情報を用いて、前記サービス提供システムを利用するための認可後の権限情報を前記サービス提供システムから取得する権限情報取得手段と、
   前記第二のユーザが操作する機器から受け付けた前記サービス提供システムを利用する処理の要求に基づき、前記第二のユーザに紐付く前記認可後の権限情報を提供する権限情報提供手段と、
   を有するサービス提供装置。

Images