JP6439370B2 - 情報処理システム、情報処理方法、情報処理装置及びプログラム - Google Patents

Description

本発明は、情報処理システム、情報処理方法、情報処理装置及びプログラムに関する。

近年、クラウドコンピューティング等により多種多様な外部サービスが提供されるようになった。例えば画像形成装置で原稿をスキャンして取得した画像データについて、異なるデータ形式に変換するサービスや電子データを外部ストレージに保管するサービス等が知られている。

このような外部サービスの普及に伴い、複合機等の画像形成装置上で動作するアプリケーションが外部サービスと連携して処理を行う技術が知られている（例えば特許文献１参照）。

しかしながら、上記の従来技術においては、連携して処理を行う外部サービスを追加・変更等する場合、追加・変更等に係る外部サービスとの認証手段を提供するためのモジュールやデータ連携手段を提供するためのモジュール等を作成する必要があった。また、これらの各手段は、システム全体に点在する場合が多い。したがって、連携して処理を行う外部サービスが追加・変更等する度に、システム全体を変更しなければならなかった。

本発明の実施の形態は、上記の点に鑑みてなされたもので、連携して処理を行う外部サービスの追加を容易にすることを目的とする。

上記目的を達成するため、本発明の実施の形態は、１以上の情報処理装置を含む情報処理システムであって、前記情報処理装置の上で動作する第１のプログラムがＷｅｂＡＰＩを介して第１の処理要求を受け付けると、該第１のプログラムが前記第１の処理要求に対応する第２の処理要求を、前記第１のプログラムと連携して処理を行う１以上の外部サービス間で共通に利用され、かつ、前記１以上の外部サービスにそれぞれ対応する１以上の第２のプログラムが含まれるフレームワークに対して行う要求手段と、前記要求手段による前記第２の処理要求を受け付けると、前記フレームワーク内に定義された複数のインタフェース手段のうち、前記第２の処理要求に含まれるアプリケーションＩＤ及び該アプリケーションのバージョンに対応する外部サービスの識別情報により識別される外部サービスとの間で利用されるインタフェース手段を介して、前記アプリケーションＩＤ及び前記バージョンに対応する第２のプログラムが、前記識別情報により識別される外部サービスに対して前記第２の処理要求に基づく第３の処理要求を行う処理要求手段と、を有することを特徴とする。

本発明の実施の形態によれば、連携して処理を行う外部サービスの追加を容易にすることができる。

第１の実施形態に係る情報処理システムの一例の構成図である。 コンピュータの一例のハードウェア構成図である。 第１の実施形態に係る画像形成装置の一例のハードウェア構成図である。 第１の実施形態に係る情報処理システムの一例の処理ブロック図である。 第１の実施形態に係る認証情報設定処理の一例のシーケンス図である。 サービス情報テーブルの一例の構成図である。 プロキシ変換情報テーブルの一例の構成図である。 外部ストレージ連携ＡＰＩの一例を説明するための図である。 設定情報の一例を示す図である。 認証情報設定画面の一例のイメージ図である。 ユーザ情報テーブルの一例の構成図である。 第１の実施形態に係るデータ保存先情報設定処理の一例のシーケンス図である。 保存先フォルダ設定画面の一例のイメージ図である。 データ保存先情報テーブルの一例の構成図である。 第１の実施形態に係るデータアップロード処理の一例のシーケンス図である。 第２の実施形態に係る情報処理システムの一例の処理ブロック図である。 第２の実施形態に係る認証情報設定処理の一例のシーケンス図である。 設定情報の他の例を示す図である。 認可設定情報テーブルの一例の構成図である。 ＯＡｕｔｈ登録情報テーブルの一例の構成図である。 ユーザ情報テーブルの他の例の構成図である。 第２の実施形態に係るデータ保存先情報設定処理の一例のシーケンス図である。 第２の実施形態に係るデータアップロード処理の一例のシーケンス図である。 第２の実施形態に係るＯＡｕｔｈによる認可処理の一例のシーケンス図である。

以下、本発明の実施形態について図面を参照しながら説明する。

［第１の実施形態］

＜システム構成＞
図１は、第１の実施形態に係る情報処理システムの一例の構成図である。図１に示される情報処理システム１において、サービス提供環境Ｅ２、ユーザ環境Ｅ１及び外部ストレージシステム４０等は、インターネット等の広域的なネットワークＮ１を介して通信可能に接続されている。

サービス提供環境Ｅ２は、ネットワークを介してクラウドサービス等の外部サービスを提供するシステム環境である。なお、本実施の形態では、外部サービスの具体例としてクラウドサービスを採用して説明するが、ＡＳＰ（Application Service Provider）によって提供されるサービスやＷｅｂサービス等、ネットワークを介して提供されるサービスに関して本実施の形態が適用されてもよい。

サービス提供環境Ｅ２は、一台以上の情報処理装置で実現されるサービス提供システム２０を有する。サービス提供システム２０は、ネットワークを介して所定のサービスを提供する。例えば、サービス提供システム２０は、ユーザ環境Ｅ１の画像形成装置１０においてスキャンされた画像データを、予め設定された保存先に保存するサービスを提供する。本実施形態では、サービス提供環境Ｅ２は、クラウドサービスの一例として、外部ストレージシステム４０と連携してクラウドストレージサービス（以降、単に「ストレージサービス」という）を提供するものとして説明する。なお、サービス提供システム２０の全部又は一部は、ユーザ環境Ｅ１に設置されていてもよい。すなわち、サービス提供システム２０を構成する情報処理装置の全部又は一部は、ユーザ環境Ｅ１に包含されていてもよい。

ユーザ環境Ｅ１は、例えば画像形成装置１０を使用するユーザである企業等におけるシステム環境である。ユーザ環境Ｅ１において、一台以上の画像形成装置１０と一台以上のＰＣ端末３０とはＬＡＮ（Local Area Network）等のネットワークを介して接続されている。

本実施形態に係る画像形成装置１０は、スキャン機能を有する画像形成装置である。スキャン機能以外に、印刷、コピー、又はファックス（ＦＡＸ）通信等の機能を有する複合機が画像形成装置１０として用いられてもよい。

ＰＣ端末３０は、ユーザ環境Ｅ１における画像形成装置１０の利用者が使用する端末である。ＰＣ端末３０は、ＰＣ（Personal Computer）の他、ＰＤＡ（Personal Digital Assistance）、タブレット型端末、スマートフォン、携帯電話等が用いられてもよい。

外部ストレージシステム４０は、ネットワークを介してストレージサービス（又はオンラインストレージ）と呼ばれるクラウドサービスを提供するコンピュータシステムである。ストレージサービスとは、外部ストレージシステム４０のストレージの記憶領域を貸し出すサービスである。本実施形態では、外部ストレージシステム４０によって貸し出される記憶領域は、サービス提供システム２０によって提供されるストレージサービスにおいて、画像データの保存先の候補である。以降では、複数の外部ストレージシステム４０について、各々を区別するときは、外部ストレージシステム４０_１、外部ストレージシステム４０_２、・・・と記載する。また、外部ストレージシステム４０_１によって提供されるサービスの名称（サービス名）を「ストレージサービスＡ」、ストレージシステム４０_２によって提供されるサービス名を「ストレージサービスＢ」、・・・とする。

なお、外部ストレージシステム４０は、複数台の情報処理装置によって実現されるシステムであってもよい。また、図１に示される情報処理システム１の構成は一例であって、他の構成であってもよい。

＜ハードウェア構成＞
図１に示されるサービス提供システム２０及びＰＣ端末３０は、例えば図２に示されるようなハードウェア構成のコンピュータにより実現される。

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

入力装置１０１はキーボードやマウス、タッチパネル等を含み、ユーザが各操作信号を入力するのに用いられる。表示装置１０２はディスプレイ等を含み、コンピュータ１００による処理結果を表示する。なお、入力装置１０１及び表示装置１０２は必要なときに接続して利用する形態であってもよい。

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

また、ＨＤＤ１０８は、プログラムやデータを格納している不揮発性の記憶装置の一例である。格納されるプログラムやデータには、コンピュータ１００全体を制御する基本ソフトウェアであるＯＳ（Operating System）、及びＯＳ上において各種機能を提供するアプリケーションソフトウェア等がある。なお、コンピュータ１００はＨＤＤ１０８に替え、記憶媒体としてフラッシュメモリを用いるドライブ装置（例えばソリッドステートドライブ：ＳＳＤ）を利用するものであってもよい。

ＨＤＤ１０８は格納しているプログラムやデータを所定のファイルシステム及び／又はＤＢにより管理している。外部Ｉ／Ｆ１０３は、外部装置とのインタフェースである。外部装置には、記録媒体１０３ａ等がある。

これにより、コンピュータ１００は外部Ｉ／Ｆ１０３を介して記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１０３ａにはフレキシブルディスク、ＣＤ、ＤＶＤ、ＳＤメモリカード、ＵＳＢメモリ等がある。

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

ＣＰＵ１０６は、ＲＯＭ１０５やＨＤＤ１０８等の記憶装置からプログラムやデータをＲＡＭ１０４上に読み出し、処理を実行することで、コンピュータ１００全体の制御や機能を実現する演算装置である。サービス提供システム２０及びＰＣ端末３０はコンピュータ１００のハードウェア構成により、後述する各種処理を実現できる。

図１に示される画像形成装置１０は、例えば図３に示されるようなハードウェア構成により実現される。図３は、第１の実施形態に係る画像形成装置の一例のハードウェア構成図である。図３に示される画像形成装置１０は、コントローラ２０１と、操作パネル２０２と、外部Ｉ／Ｆ２０３と、通信Ｉ／Ｆ２０４と、スキャナ２０５とを備える。

コントローラ２０１はＣＰＵ２１１と、ＲＡＭ２１２と、ＲＯＭ２１３と、ＮＶＲＡＭ２１４と、ＨＤＤ２１５とを備える。ＲＯＭ２１３は、各種プログラムやデータが格納されている。ＲＡＭ２１２はプログラムやデータを一時保持する。ＮＶＲＡＭ２１４は、例えば設定情報等が格納されている。また、ＨＤＤ２１５は各種プログラムやデータが格納されている。

ＣＰＵ２１１は、ＲＯＭ２１３やＮＶＲＡＭ２１４、ＨＤＤ２１５等からプログラムやデータ、設定情報等をＲＡＭ２１２上に読み出し、処理を実行することで、画像形成装置１０全体の制御や機能を実現する。

操作パネル２０２はユーザからの入力を受け付ける入力部と、表示を行う表示部とを備えている。外部Ｉ／Ｆ２０３は外部装置とのインタフェースである。外部装置には、記録媒体２０３ａ等がある。これにより、画像形成装置１０は外部Ｉ／Ｆ２０３を介して記録媒体２０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体２０３ａにはＩＣカード、フレキシブルディスク、ＣＤ、ＤＶＤ、ＳＤメモリカード、ＵＳＢメモリ等がある。

通信Ｉ／Ｆ２０４は、画像形成装置１０をネットワークＮ１に接続するインタフェースである。これにより、画像形成装置１０は通信Ｉ／Ｆ２０４を介してデータ通信を行うことができる。スキャナ２０５は原稿から画像データ（電子データ）を読み取るための読取装置である。

＜ソフトウェア構成＞
本実施形態に係る情報処理システム１は、例えば図４に示されるような処理ブロックにより実現することができる。図４は、第１の実施形態に係る情報処理システムの一例の処理ブロック図である。なお、図４の情報処理システム１において、本実施形態の説明に不要な処理ブロックについては図示を省略している。

画像形成装置１０は、１つ以上のクライアントアプリ１１を有する。クライアントアプリ１１は、サービス提供システム２０と連携させるために、画像形成装置１０にインストールされる必要のあるアプリケーションプログラムである。クライアントアプリ１１は、後述するサーバアプリ２２と連携し、利用できるストレージサービスの表示やストレージサービスへのデータの保存要求等を行う。なお、「クライアントアプリ」という用語は、サービス提供システム２０側にインストールされる必要のあるアプリケーションプログラム（後述する「サーバアプリ２２」）と区別するために便宜上用いた用語である。

なお、クライアントアプリ１１とサーバアプリ２２とが同一のプログラムであってもよい。また、クライアントアプリ１１は、ＳＤＫ（Software Development Kit）を利用して開発されたアプリケーションであるＳＤＫアプリケーションを利用できる。

サービス提供システム２０は、ＷｅｂＡＰＩ２１と、サーバアプリ２２と、ポータルアプリ２３と、サービス情報部２４と、外部ストレージ配信部２５と、認証部２６と、プロキシ部２７と、外部ストレージ共通フレームワーク２８とを有する。これらは、サービス提供システム２０にインストールされる一以上のプログラムによって構成され、ＣＰＵ１０６等に所定の処理を実行させる。

また、サービス提供システム２０は、サービス情報記憶部５１と、ユーザ情報記憶部５２と、データ保存先情報記憶部５３と、プロキシ変換情報記憶部５４とを利用する。これら各記憶部は、ＨＤＤ１０８、又はサービス提供システム２０とネットワークを介して接続される記憶装置等を用いて実現可能である。

ＷｅｂＡＰＩ２１は、画像形成装置１０やＰＣ端末３０がサービス提供システム２０を利用するためのインタフェースである。ＷｅｂＡＰＩ２１は、画像形成装置１０やＰＣ端末３０からの各種要求をサーバアプリ２２やポータルアプリ２３等が受け付けるために設けられた予め定義されたインタフェースであり、例えば、関数やクラス等により構成される。

サーバアプリ２２は、クライアントアプリ１１と連携してサービス提供システム２０が提供するストレージサービスを実現するアプリケーションプログラムである。サーバアプリ２２は、外部ストレージ連携部２２１を有しており、クライアントアプリ１１から所定の要求を受け付けると、外部ストレージ連携部２２１は、プロキシ部２７を介して、ストレージサービスのディレクトリ情報取得ＡＰＩ（Application Programming Interface）の呼び出し要求を外部ストレージ共通フレームワーク２８に対して行う。なお、サーバアプリ２２は、ＳＤＫを利用して開発されたアプリケーションであるＳＤＫアプリケーションを利用できる。

ポータルアプリ２３は、ＰＣ端末３０に対して、外部ストレージシステム４０におけるデータの保存先フォルダの設定や認証情報設定等を提供する。ポータルアプリ２３は、ＵＩ生成部２３１を有しており、ＰＣ端末３０からの要求を受け付けると、ＵＩ生成部２３１は、受け付けた要求に応じたＵＩ（ユーザインタフェース）画面の生成を行う。

サービス情報部２４は、利用できるストレージサービスの管理を行う。また、サービス情報部２４は、他の各部からの依頼に応じて、サービス情報記憶部５１から利用できるストレージサービスに関する情報（以降、「サービス情報」という）を取得する。

外部ストレージ配信部２５は、サーバアプリ２２からの所定の要求に応じて、外部ストレージシステム４０にデータを保存するための処理を行う。外部ストレージ配信部２５は、外部ストレージ連携部２５１を有しており、サーバアプリ２２から所定の要求を受け付けると、外部ストレージ連携部２５１は、プロキシ部２７を介して、データのアップロードＡＰＩの呼び出し要求を外部ストレージ共通フレームワーク２８に対して行う。

認証部２６は、ユーザ毎の認証情報（以降、「ユーザ情報」という）の管理を行う。また、認証部２６は、他の各部からの依頼に応じて、ユーザ情報記憶部５２からユーザ情報を取得する。認証部２６は、外部ストレージ共通認証部２６１を有し、外部ストレージ共通認証部２６１は、プロキシ部２７を介して、外部ストレージシステム４０へのログインＡＰＩの呼び出し要求を外部ストレージ共通フレームワーク２８に対して行う。

外部ストレージ共通フレームワーク２８は、外部ストレージ連携ＡＰＩ６１と、ストレージサービス用アプリ６２とを有する。また、外部ストレージ共通フレームワーク２８は、外部ストレージサービスの設定情報記憶部６３を利用する。

外部ストレージ連携ＡＰＩ６１は、ストレージサービス用アプリ６２を利用するための共通のインタフェースである。外部ストレージ連携ＡＰＩ６１は、サービス提供システム２０の各部からのＡＰＩの呼び出し要求をストレージサービス用アプリ６２が受け付けるために設けられた予め定義されたインタフェースであり、例えば、関数やクラス等により構成される。

ストレージサービス用アプリ６２は、外部ストレージシステム４０に対して、ディレクトリ情報の取得、データのアップロード、データのダウンロード等の各種処理を行うことができるプログラムである。ストレージサービス用アプリ６２は、利用できるストレージサービス毎に存在する。例えば、ストレージサービスＡを利用するためのストレージサービスＡ用アプリ６２_１、ストレージサービスＢを利用するためのストレージサービスＢ用アプリ６２_２、・・・が存在する。なお、各ストレージサービス用アプリ６２には、「アプリＩＤ」と「バージョン」とが対応付けられており、これらの情報は、ストレージサービスの名称とともに、サービス情報記憶部５１においてサービス情報として管理される。

また、ストレージサービス用アプリ６２は、それぞれ対応する設定情報記憶部６３を利用する。設定情報記憶部６３には、対応する外部ストレージサービスの設定情報が記憶されている。設定情報は、ＵＩ生成部２３１がユーザインタフェースを生成するために必要な情報が指定されている。

プロキシ部２７は、他の各部から外部ストレージシステム４０に対する各種要求を受け付けると、プロキシ変換情報記憶部５４のプロキシ変換情報テーブルを参照し、対応するホスト情報（アドレス情報）に要求を転送する。例えば、プロキシ部２７は、外部ストレージシステム４０_１（ストレージサービスＡ）に対する要求を受け取った場合、プロキシ変換情報テーブルを参照し、ストレージサービスＡ用アプリ６２_１が動作するホストに、この要求を転送する。

より具体的に説明すると、ストレージサービスＡ用アプリ６２_１（アプリＩＤ「ａｐｐＡ」）がホスト情報「ａａａ．ｘｘｘ．ｃｏ．ｊｐ」の装置に存在し、ストレージサービスＢ用アプリ６２_２（アプリＩＤ「ａｐｐＢ」）がホスト情報「ｂｂｂ．ｘｘｘ．ｃｏ．ｊｐ」の装置に存在するとする。このとき、プロキシ部２７は、プロキシ変換情報テーブルを参照し、受け取った要求に含まれるアプリＩＤが「ａｐｐＡ」である場合、この要求を「ａａａ．ｘｘｘ．ｃｏ．ｊｐ」に転送し、他方、受け取った要求に含まれるアプリＩＤが「ａｐｐＢ」である場合、この要求を「ｂｂｂ．ｘｘｘ．ｃｏ．ｊｐ」に転送する。換言すれば、プロキシ部２７は、所望のストレージサービス用アプリ６２が搭載されている（動作している）ホスト情報の装置に対して、受け取った要求を転送する。

なお、異なるホスト情報が同一の装置で実現されてもよいし、複数台の装置で実現されていてもよい。他方、例えば外部ストレージ共通フレームワーク２８が一台の情報処理装置で実現されており、かつ、一つのホスト情報のみを有する場合等は、サービス提供システム２０は、プロキシ部２７を有していなくてもよい。

また、サービス情報記憶部５１は、サービス情報を記憶する。ユーザ情報記憶部５２は、ユーザ情報を記憶する。データ保存先情報記憶部５３は、データ保存先情報を記憶する。プロキシ変換情報記憶部５４は、プロキシ変換情報を記憶する。外部ストレージサービスの設定情報記憶部６３は、設定情報を記憶する。

なお、上述したように、サービス提供システム２０の処理ブロックは、複数台の情報処理装置により構成されていてもよい。例えば、プロキシ部２７とプロキシ変換情報記憶部５４とを一台の情報処理装置で構成し、外部ストレージ共通フレームワーク２８を複数台の情報処理装置で構成して運用してもよい。

以上のように本実施形態に係るサービス提供システム２０は、各ストレージサービスを利用するための外部ストレージ共通フレームワーク２８を有する。また、外部ストレージ共通フレームワーク２８は、各ストレージサービス用アプリ６２を利用するための共通に定義されたＡＰＩである外部ストレージ連携ＡＰＩ６１を有する。したがって、利用できるストレージサービスを追加・変更等する場合、外部ストレージ連携ＡＰＩ６１を利用することにより、システム全体に影響を与えることなくストレージサービス用アプリ６２を追加・変更等を行うことができる。換言すれば、ストレージサービスの追加・変更等に伴うサービス提供システム２０への影響を、外部ストレージ共通フレームワーク２８の中だけに限定させることができる。なお、外部ストレージ連携ＡＰＩ６１は、例えばサードベンダー等に公開してもよい。

＜処理の詳細＞
次に、本実施形態に係る情報処理システムの処理の詳細について説明する。

《認証情報設定処理》
まず、情報処理システム１のユーザが利用することができるストレージサービスの認証情報を設定する処理について説明する。図５は、第１の実施形態に係る認証情報設定処理の一例のシーケンス図である。

ステップＳ５０１において、ユーザがＰＣ端末３０を操作してユーザ情報編集画面へ遷移させる。これは、例えば、ＰＣ端末３０のＷｅｂブラウザ（不図示）等を用いて、ＷｅｂＡＰＩ２１を介して、サービス提供システム２０のポータルアプリ２３が提供するポータルサイトにログインし、このポータルサイトで所定のボタンを押下することでユーザ情報編集画面に遷移させることができる。なお、ユーザがポータルサイトにログインする際には、ユーザＩＤ、パスワード等を入力する。ここで、後述する外部ストレージシステム４０にログインするためのユーザＩＤ及びパスワードと区別するため、サービス提供システム２０にログインするためのユーザＩＤ及びパスワードを、以降では便宜的に、利用者ＩＤ及び利用者パスワードと呼ぶ。

ステップＳ５０２において、ポータルアプリ２３は、サービス情報部２４に対してサービス情報の取得を依頼する。サービス情報部２４は、ポータルアプリ２３からサービス情報の取得依頼を受け付けると、サービス情報記憶部５１に記憶されている図６に示すようなサービス情報テーブルを取得し、ポータルアプリ２３に送信する。

図６は、サービス情報テーブルの一例の構成図である。サービス情報テーブルは、ストレージサービスを利用するためのストレージサービス用アプリ６２の情報を管理している。サービス情報テーブルは、「アプリＩＤ」、「外部ストレージサービス名」及び「バージョン」等のデータ項目を有する。「アプリＩＤ」は、利用可能な外部ストレージシステム４０に対して各種処理を要求するためのストレージサービス用アプリ６２の識別情報である。「外部ストレージサービス名」は、外部ストレージシステム４０が提供するサービスの名称である。「バージョン」は、ストレージサービス用アプリ６２のバージョン情報である。

例えば、図６に示すサービス情報テーブルの１レコード目には、ストレージサービスＡ用アプリ６２_１のアプリＩＤ「ａｐｐ００１」、外部ストレージシステム４０_１が提供するサービス名「ストレージサービスＡ」、ストレージサービスＡ用アプリ６２_１のバージョン情報「ｖ１」が記憶されている。

なお、図６に示されるサービス情報テーブルでは、同一のアプリＩＤであっても異なるバージョンのストレージサービス用アプリ６２は別々に管理しているが、バージョンに関わらず同一のアプリＩＤを１レコードで管理してもよい。

次に、ステップＳ５０３及びステップＳ５０４の処理を、ステップＳ５０２に取得したサービス情報テーブルに含まれるレコード数の回数繰り返し行う。

ステップＳ５０３において、ポータルアプリ２３は、ステップＳ５０２で取得したサービス情報テーブルからレコードを１件取得し、このレコードのアプリＩＤ及びバージョンを含む設定情報取得ＡＰＩの呼び出し要求をプロキシ部２７に送信する。

ステップＳ５０４において、プロキシ部２７は、アプリＩＤ及びバージョンを含む設定情報取得ＡＰＩの呼び出し要求を受け取ると、図７に示すようなプロキシ変換情報テーブルを参照し、該当のホスト名に対して設定情報取得ＡＰＩの呼び出し要求を転送する。

図７は、プロキシ変換情報テーブルの一例の構成図である。プロキシ変換情報テーブルは、アプリＩＤに対応した転送先のホスト名を管理している。プロキシ変換情報テーブルは、「アプリＩＤ」、「転送先ホスト情報」等のデータ項目を有する。「アプリＩＤ」は、上述したようにストレージサービス用アプリ６２の識別情報である。「転送先ホスト名」は、プロキシ部２７が受け付けた各種要求を転送する転送先のホスト名である。

例えば、プロキシ部２７が受け取った設定情報取得ＡＰＩの呼び出し要求に含まれるアプリＩＤ及びバージョンがそれぞれ「ａｐｐ００１」及び「ｖ２」である場合、プロキシ部２７は、図７に示すプロキシ変換情報テーブルを参照し、この設定情報取得ＡＰＩの呼び出し要求を「ａａａ．ｘｘｘ．ｃｏ．ｊｐ」に転送する。一方、プロキシ部２７が受け取った要求に含まれるアプリＩＤ及びバージョンがそれぞれ「ａｐｐ００２」及び「ｖ１」である場合、プロキシ部２７は、この要求を「ｂｂｂ．ｘｘｘ．ｃｏ．ｊｐ」に転送する。このように、プロキシ部２７は、受け取った要求に含まれるアプリＩＤに応じて、この要求を転送先ホスト情報に指定されたホストに転送する。なお、転送先ホスト情報に代えて、転送先を示すＩＰアドレス等を用いてもよい。これら転送先ホスト情報、ＩＰアドレス等は、アドレス情報の一例である。

そして、プロキシ部２７が転送した設定情報取得ＡＰＩの呼び出し要求より、外部ストレージ連携ＡＰＩ６１の設定情報取得ＡＰＩが呼び出され、該当の外部ストレージ用アプリ６２は設定情報の取得を行う。より具体的には、外部ストレージ連携ＡＰＩ６１は、アプリＩＤ及びバージョンを含む設定情報取得ＡＰＩの呼び出し要求を受け取ると、設定情報取得ＡＰＩを呼び出し、この呼び出し要求に含まれるアプリＩＤ及びバージョンに対応する外部ストレージ用アプリ６２に対して設定情報の取得を依頼する。外部ストレージ用アプリ６２は、設定情報記憶部６３から設定情報を取得し、プロキシ部２７を介して、設定情報をポータルアプリ２３に送信する。

なお、サービス提供システム２０がプロキシ部２７を有さない構成である場合、上記のステップＳ５０３において、ポータルアプリ２３は、外部ストレージ連携ＡＰＩ６１に対して直接、設定情報取得ＡＰＩの呼び出し要求を行う。

ここで、外部ストレージ連携ＡＰＩ６１について、図８を用いて説明する。図８は、外部ストレージ連携ＡＰＩの一例を説明するための図である。外部ストレージ連携ＡＰＩ６１は、外部ストレージシステム４０に対して各種処理要求を行うためのＡＰＩを定義している。図８において、外部ストレージシステム４０の設定情報を取得するためのＡＰＩは、エンドポイント「／アプリＩＤ／バージョン／ｉｎｆｏ」で定義されている。したがって、外部ストレージシステム４０_１（ストレージサービスＡ）の設定情報を取得するためには、例えばアプリＩＤ「ａｐｐ００１」、バージョン「ｖ２」を指定した設定情報取得ＡＰＩの呼び出し要求を外部ストレージ連携ＡＰＩ６１に送信すればよい。これにより、ストレージサービスＡ用アプリ６２_１によりストレージサービスＡの設定情報記憶部６３_１から設定情報が取得される。このように、外部ストレージ連携ＡＰＩ６１は、エンドポイントのうち「アプリＩＤ」及び「バージョン」が可変部分として定義されており、「アプリＩＤ」及び「バージョン」が指定されることにより、この「アプリＩＤ」及び「バージョン」に対応するストレージサービス用アプリ６２に処理を依頼する。これにより、サービス提供システム２０に対してストレージサービス用アプリ６２を追加・変更等する場合においても、外部ストレージ連携ＡＰＩ６１の修正等を行う必要がない。

ここで、設定情報記憶部６３に記憶されている設定情報は、例えば図９に示すような情報である。図９は、設定情報の一例を示す図である。図９では、一例として、設定情報記憶部６３_１に記憶されているストレージサービスＡの設定情報１０００を示している。後述するステップＳ５０５の画面生成処理において、この設定情報１０００に基づき、ストレージサービスＡの認証情報を設定するためのＵＩ画面（認証情報設定画面）が生成される。図９の各情報１１００〜１２００は、ＵＩ画面を生成するための情報である。

次に、ステップＳ５０５において、上記のステップＳ５０３及びステップＳ５０４の処理において取得した各ストレージサービスの設定情報に基づいて、ポータルアプリ２３は、認証情報を設定するためのＵＩ画面（認証情報設定画面）を生成する。

ここで、図９に示す設定情報１０００に基づき、例えば図１０に示すようなＵＩ画面が生成される。図１０は、認証情報設定画面の一例のイメージ図である。例えば、図９の情報１１００からタイトル部２１００が生成される。また、図９の情報１２００からユーザＩＤ入力部２２００が、図９の情報１３００からパスワード入力部２３００が生成される。このように、ポータルアプリ２３は、取得した設定情報からストレージサービスの認証情報を設定するための画面を生成する。図９及び図１０では、認証情報としてユーザＩＤとパスワードとが設定される場合を一例として示したが、これに限られず、例えば、ユーザＩＤとパスワードに加えて、企業名等を認証情報として設定することができてもよい。なお、どのような項目を認証情報として設定することができるかは、ストレージサービス毎に予め決定されている。なお、図９に示す設定情報１０００は、ＪＳＯＮ（JavaScript Object Notation）で記述されているが、これに限られず、例えばＸＭＬ（Extensible Markup Language）等で記述されていてもよい。

また、このとき、ポータルアプリ２３は、認証情報の設定を行うことができるストレージサービスの一覧を表示するための画面を生成し、ＰＣ端末３０の表示装置１０２に表示させる。ユーザがこのストレージサービスの一覧から所望のストレージサービスを選択すると、上記のステップＳ５０５において生成した認証情報設定画面に遷移することができる。

ステップＳ５０６において、ユーザはＰＣ端末３０を操作して、ストレージサービス一覧から所望のストレージサービスを選択すると、選択したストレージサービスの認証情報設定画面に遷移する。

ステップＳ５０７において、ユーザはＰＣ端末３０を操作して、認証情報設定画面から認証情報（例えば、ユーザＩＤとパスワード）を入力して認証情報を設定する。例えば、ユーザがストレージサービスＡの認証情報を設定する場合、図１０に示す認証情報設定画面２０００においてユーザＩＤとパスワードを入力し、設定ボタン２４００を押下する。すると、ＰＣ端末３０は、ユーザＩＤとパスワードとを含む認証情報の保存要求をポータルアプリ２３に送信する。なお、ここで入力するユーザＩＤ及びパスワードは、ユーザが所望のストレージサービスにログインするためのユーザＩＤ及びパスワードである。したがって、ユーザは、予め利用するストレージサービスのユーザＩＤ及びパスワードを入手しておく必要がある。

ステップＳ５０８において、ポータルアプリ２３は、ＰＣ端末３０から受け取った認証情報の保存要求を認証部２６に送信する。そして、認証部２６は、認証情報の保存要求に含まれる認証情報（ストレージサービスのユーザＩＤ及びパスワード等）を、利用者ＩＤとアプリＩＤと関連付けてユーザ情報記憶部５２の例えば図１１に示すようなユーザ情報テーブルに保存する。

図１１は、ユーザ情報テーブルの一例の構成図である。ユーザ情報管理テーブルは、「利用者ＩＤ」、「アプリＩＤ」、「認証情報」等のデータ項目を有する。「利用者ＩＤ」は、サービス提供システム２０を利用するための利用者ＩＤである。「認証情報」は、アプリＩＤに対応するストレージサービスに対する認証情報である。「認証情報」は、複数のデータ項目を有している。例えば「Ｋｅｙ１」はストレージサービスの認証に用いるユーザＩＤ、「Ｋｅｙ２」は認証に用いるパスワード、「Ｋｅｙ３」は認証に用いる企業名等である。例えば、図１４の示すユーザ情報テーブルの１レコード目は、上記のステップＳ５０７において、利用者ＩＤ「Ｔｏｎｙ」のユーザが、ストレージサービスＡのユーザＩＤを「ｕｓｅｒ００１」、パスワードを「ｐａｓｓ００１」と設定した場合に保存されるレコードである。

以上により、本実施形態に係るサービス提供システム２０では、ユーザは、ＰＣ端末３０から所望のストレージサービスの認証情報を設定することができる。また、認証情報設定画面を生成するための設定情報は、外部ストレージ共通フレームワーク２８を用いて取得することができる。したがって、サービス提供システム２０が提供するストレージサービスを追加する場合、又はサービス提供システム２０が提供しているストレージサービスの設定情報を変更する場合においても、外部ストレージ共通フレームワーク２８内だけに追加・変更に伴う影響を限定させることができる。

《データ保存先情報設定処理》
次に、情報処理システム１のユーザが利用することができるストレージサービスについて、データの保存先情報を設定する処理について説明する。図１２は、第１の実施形態に係るデータ保存先情報設定処理の一例のシーケンス図である。

ステップＳ１２０１において、ユーザがＰＣ端末３０を操作して、データの保存先情報を設定する所望のストレージサービスを選択する。すると、ＰＣ端末３０は、選択したストレージサービスのディレクトリ情報取得要求を、ＷｅｂＡＰＩ２１を介して、ポータルアプリ２３に送信する。ディレクトリ情報取得要求には、利用者ＩＤと、選択したストレージサービスに対応するストレージサービス用アプリ６２のアプリＩＤとが含まれる。

なお、上記のステップＳ１２０１において、ユーザは、例えばＰＣ端末３０のＷｅｂブラウザ（不図示）等を用いて、予めポータルアプリ２３が提供するポータルサイトにログインしているものとする。

ステップＳ１２０２において、ポータルアプリ２３は、ディレクトリ情報取得要求をサーバアプリ２２に転送する。

ステップＳ１２０３において、サーバアプリ２２は、ディレクトリ情報を取得するため、認証部２６に対して、ステップＳ１２０１で選択したストレージサービスに対するログイン要求を送信する。

ステップＳ１２０４において、認証部２６の外部ストレージ共通認証部２６１は、ログイン要求に含まれる利用者ＩＤとアプリＩＤとに基づいてユーザ情報記憶部５２のユーザ情報テーブルから認証情報を取得し、アプリＩＤと、バージョンと、取得した認証情報とを含むログインＡＰＩの呼び出し要求をプロキシ部２７に対して送信する。このように、プロキシ部２７（又は外部ストレージ共通フレームワーク２８）との通信は外部ストレージ共通認証部２６１が行う。換言すれば、認証部２６が外部ストレージ連携ＡＰＩ６１を利用するためには、外部ストレージ共通認証部２６１を介して行う。

ここで、取得する認証情報は、例えば、利用者ＩＤが「Ｔｏｎｙ」、アプリＩＤが「ａｐｐ００１」である場合、認証部２６は、図１１に示すユーザ情報管理テーブルから認証情報としてＫｅｙ１「ｕｓｅｒ００１」及びＫｅｙ２「ｐａｓｓ００１」を取得する。ここで取得したＫｅｙ１及びＫｅｙ２が、外部ストレージシステム４０_１が提供するストレージサービスＡにログインするためのユーザＩＤ及びパスワードである。

ステップＳ１２０５において、プロキシ部２７は、アプリＩＤ及びバージョンを含むログインＡＰＩの呼び出し要求を受け取ると、図７に示すようなプロキシ変換情報テーブルを参照し、該当のホスト名に対してログインＡＰＩの呼び出し要求を転送する。そして、プロキシ部２７が転送したログインＡＰＩの呼び出し要求により、外部ストレージ連携ＡＰＩ６１のログインＡＰＩが呼び出される。より具体的には、外部ストレージ連携ＡＰＩ６１は、アプリＩＤとバージョンと認証情報とを含むログインＡＰＩの呼び出し要求を受け取ると、ログインＡＰＩを呼び出し、この呼び出し要求に含まれるアプリＩＤ及びバージョンに対応するストレージ用アプリ６２に対してログイン要求を依頼する。例えば、ログイン要求に含まれるアプリＩＤが「ａｐｐ０１」、バージョンが「ｖ２」である場合、外部ストレージ連携ＡＰＩ６１は、ストレージサービスＡ用アプリ６２_１に対してログイン要求を依頼する。

ステップＳ１２０６において、ストレージサービス用アプリ６２は、外部ストレージシステム４０に対してログイン要求を行う。そして、外部ストレージシステム４０は、受け取ったログイン要求に含まれる認証情報に基づき、認証を行い、ストレージサービス用アプリ６２を介して認証結果を示す情報をサーバアプリ２２に送信する。このとき、認証結果を示す情報には、例えば、ＰＣ端末３０と外部ストレージシステム４０とのセッションを管理するためのトークン（例えばＣｏｏｋｉｅ）を含めてもよい。なお、以降では、外部ストレージシステム４０に対するログインが成功したものとして説明を続ける。

ステップＳ１２０７において、サーバアプリ２２の外部ストレージ連携部２２１は、ディレクトリ情報取得ＡＰＩの呼び出し要求をプロキシ部２７に対して送信する。このように、プロキシ部２７（又は外部ストレージ共通フレームワーク２８）との通信は外部ストレージ連携部２２１が行う。換言すれば、サーバアプリ２２が外部ストレージ連携ＡＰＩ６１を利用するためには、外部ストレージ連携部２２１を介して行う。これにより、例えば、サードベンダがＳＤＫによりサーバアプリ２２を開発する場合等において、外部ストレージ連携部２２１として機能するモジュール等を用いることにより容易に外部ストレージ連携ＡＰＩ６１を利用することができる。なお、ポータルアプリ２３についても外部ストレージ連携部を有していてもよい。

ステップＳ１２０８において、プロキシ部２７は、アプリＩＤ及びバージョンを含むディレクトリ情報取得ＡＰＩの呼び出し要求を受け取ると、図７に示すようなプロキシ変換情報テーブルを参照し、該当のホスト名に対してディレクトリ情報取得ＡＰＩの呼び出し要求を転送する。そして、プロキシ部２７が転送したディレクトリ情報取得ＡＰＩの呼び出し要求により、外部ストレージ連携ＡＰＩ６１のディレクトリ情報取得ＡＰＩが呼び出される。より具体的には、外部ストレージ連携ＡＰＩ６１は、アプリＩＤとバージョンとを含むディレクトリ情報取得ＡＰＩの呼び出し要求を受け取ると、ディレクトリ情報取得ＡＰＩを呼び出し、この呼び出し要求に含まれるアプリＩＤ及びバージョンに対応する外部ストレージ用アプリ６２に対してディレクトリ情報取得要求を依頼する。例えば、ディレクトリ情報取得要求に含まれるアプリＩＤが「ａｐｐ０１」、バージョンが「ｖ２」である場合、外部ストレージ連携ＡＰＩ６１は、ストレージサービスＡ用アプリ６２_１に対してディレクトリ情報取得を依頼する。

ステップＳ１２０９において、ストレージサービス用アプリ６２は、外部ストレージシステム４０に対してディレクトリ情報の取得要求を行う。そして、外部ストレージシステム４０は、ディレクトリ情報をストレージサービス用アプリ６２を介してＰＣ端末３０に送信する。なお、ここで取得されるディレクトリ情報は、ステップＳ１２０６でログインしたユーザの外部ストレージシステム４０のディレクトリ情報である。換言すれば、ステップＳ１２０１でユーザが選択したストレージサービスのディレクトリ情報である。ここで、ディレクトリ情報は、例えば、ディレクトリを構成するフォルダＩＤと親フォルダＩＤとの組である。

ステップＳ１２１０において、ＰＣ端末３０は、受け取ったディレクトリ情報に基づき、外部ストレージシステム４０におけるデータの保存先を設定するための例えば図１３に示すような保存先フォルダの設定画面３０００を表示装置１０２等に表示させる。図１３は、保存先フォルダ設定画面の一例のイメージ図である。図１３は、外部ストレージシステム４０_１が提供するストレージサービスＡにおける保存先フォルダの設定画面３０００を一例として示している。この保存先フォルダの設定画面３０００において、例えば、ユーザがデータの保存先として「保存先フォルダ１」を選択し、設定ボタン３１００を押下すると、このユーザのストレージサービスＡにおけるデータの保存先として「保存先フォルダ１」が設定される。

ステップＳ１２１１において、ＰＣ端末３０は、ステップＳ１２１０で設定したデータ保存先情報の保存要求をポータルアプリ２３に対して送信する。

ステップＳ１２１２において、ポータルアプリ２３は、受け取ったデータ保存先情報の保存要求をサーバアプリ２２に送信する。そして、サーバアプリ２２は、受け取ったデータ保存先情報をデータ保存先情報記憶部５３の図１４に示すようなデータ保存先情報テーブルに保存する。

図１４は、データ保存先情報テーブルの一例の構成図である。図１４に示されるデータ保存先情報テーブルは、「利用者ＩＤ」、「アプリＩＤ」、「保存先」等のデータ項目を有する。「保存先」は、アプリＩＤに対応するストレージサービスにおける、利用者ＩＤに対応するユーザのデータの保存先情報である。例えば、図１４において、利用者ＩＤ「Ｔｏｎｙ」のストレージサービスＡ（アプリＩＤ「ａｐｐ００１」）におけるデータの保存先は「ストレージサービスＡ／画像データ／保存先フォルダ１」に設定されていることを示している。後述するデータアップロード処理において、データを外部ストレージシステム４０に保存する場合、「保存先」のデータ項目に設定されている保存先フォルダにデータが保存される。

以上により、本実施形態に係るサービス提供システム２０では、ユーザは、ＰＣ端末３０から所望のストレージサービスのデータ保存先情報を設定することができる。保存先フォルダ設定画面を生成するためのディレクトリ情報は、外部ストレージ共通フレームワーク２８を用いて取得することができる。したがって、サービス提供システム２０が提供するストレージサービスを追加する場合においても、外部ストレージ共通フレームワーク２８内だけに追加に伴う影響を限定させることができる。

《データアップロード処理》
次に、情報処理システム１のユーザが画像形成装置１０で原稿をスキャンして生成した画像データを、所望の外部ストレージシステム４０に保存（アップロード）する処理について説明する。図１５は、第１の実施形態に係るデータアップロード処理の一例のシーケンス図である。

ステップＳ１５０１において、ユーザは例えば利用者ＩＤ及び利用者パスワードを入力して画像形成装置１０にログインし、画像データの保存（アップロード）先の外部ストレージシステム４０（ストレージサービス）を選択する。そして、ユーザは画像形成装置１０において、原稿をスキャンして画像データを生成する。すると、画像形成装置１０のクライアントアプリ１１は、画像データのアップロード要求をサーバアプリ２２に送信する。このアップロード要求には、利用者ＩＤと、生成した画像データと、選択したストレージサービスに対応するストレージサービス用アプリ６２のアプリＩＤとが含まれる。

ステップＳ１５０２において、サーバアプリ２２は、画像形成装置１０のクライアントアプリ１１から画像データのアップロード要求を受け取ると、この画像データを外部ストレージシステム４０にアップロードするためのジョブを外部ストレージ配信部２５に依頼する。

ステップＳ１５０３において、外部ストレージ配信部２５は、サーバアプリ２２からジョブの依頼を受け付けると、外部ストレージ連携部２２１に画像データのアップロードを依頼する。なお、このときサーバアプリ２２は、データ保存先情報記憶部５３のデータ保存先情報テーブルから保存先情報を取得し、画像データとこの画像データの保存先情報を含むジョブを生成し、外部ストレージ連携部２２１にアップロードを依頼する。例えば、ステップＳ１５０１においてユーザ（利用者ＩＤ「Ｔｏｎｙ」）が画像データのアップロード先としてストレージシステムＡ（アプリＩＤ「ａｐｐ００１」）を選択した場合、サーバアプリ２２は、保存先情報として「ストレージサービスＡ／画像データ／保存先フォルダ１」をデータ保存先情報テーブルから取得する。

ステップＳ１５０４において、外部ストレージ連携部２５１は、画像データをアップロードするため、認証部２６に対して、ステップＳ１５０１で選択したストレージサービスに対するログイン要求を送信する。

ステップＳ１５０５において、認証部２６の外部ストレージ共通認証部２６１は、ログイン要求に含まれる利用者ＩＤとアプリＩＤとに基づいてユーザ情報記憶部５２のユーザ情報テーブルから認証情報を取得し、アプリＩＤとバージョンと取得した認証情報とを含むログインＡＰＩの呼び出し要求をプロキシ部２７に対して送信する。

取得する認証情報は、例えば、利用者ＩＤが「Ｔｏｎｙ」、アプリＩＤが「ａｐｐ００１」である場合、認証部２６は、図１１に示すユーザ情報管理テーブルから認証情報としてＫｅｙ１「ｕｓｅｒ００１」及びＫｅｙ２「ｐａｓｓ００１」を取得する。ここで取得したＫｅｙ１及びＫｅｙ２が、外部ストレージシステム４０_１が提供するストレージサービスＡにログインするためのユーザＩＤ及びパスワードである。

ステップＳ１５０６において、プロキシ部２７は、アプリＩＤ及びバージョンを含むログインＡＰＩの呼び出し要求を受け取ると、図７に示すようなプロキシ変換情報テーブルを参照し、該当のホスト名に対してログインＡＰＩの呼び出し要求を転送する。そして、プロキシ部２７が転送したログインＡＰＩの呼び出し要求により、外部ストレージ連携ＡＰＩ６１のログインＡＰＩが呼び出される。より具体的には、外部ストレージ連携ＡＰＩ６１は、アプリＩＤとバージョンと認証情報を含むログインＡＰＩの呼び出し要求を受け取ると、ログインＡＰＩを呼び出し、この呼び出し要求に含まれるアプリＩＤ及びバージョンに対応する外部ストレージ用アプリ６２に対してログイン要求を依頼する。例えば、ログイン要求に含まれるアプリＩＤが「ａｐｐ０１」、バージョンが「ｖ２」である場合、外部ストレージ連携ＡＰＩ６１は、ストレージサービスＡ用アプリ６２_１に対してログイン要求を依頼する。

ステップＳ１５０７において、ストレージサービス用アプリ６２は、外部ストレージシステム４０に対してログイン要求を行う。そして、外部ストレージシステム４０は、受け取ったログイン要求に含まれる認証情報に基づき、認証を行い、ストレージサービス用アプリ６２を介して認証結果を示す情報をサーバアプリ２２に送信する。このとき、認証結果を示す情報には、例えば、画像形成装置１０と外部ストレージシステム４０とのセッションを管理するためのトークン（例えばＣｏｏｋｉｅ）を含めてもよい。なお、以降では、外部ストレージシステム４０に対するログインが成功したものとして説明を続ける。

ステップＳ１５０８において、外部ストレージ連携部２５１は、データアップロードＡＰＩの呼び出し要求をプロキシ部２７に対して送信する。

ステップＳ１５０９において、プロキシ部２７は、アプリＩＤとバージョンと画像データとを含むデータアップロードＡＰＩの呼び出し要求を受け取ると、図７に示すようなプロキシ変換情報テーブルを参照し、該当のホスト名に対してデータアップロードＡＰＩの呼び出し要求を転送する。そして、プロキシ部２７が転送したデータアップロードＡＰＩの呼び出し要求により、外部ストレージ連携ＡＰＩ６１のデータアップロードＡＰＩが呼び出される。より具体的には、外部ストレージ連携ＡＰＩ６１は、アプリＩＤとバージョンと画像データとを含むデータアップロードＡＰＩの呼び出し要求を受け取ると、データアップロードＡＰＩを呼び出し、この呼び出し要求に含まれるアプリＩＤ及びバージョンに対応する外部ストレージ用アプリ６２に対して画像データのアップロード要求を依頼する。例えば、ディレクトリ情報取得要求に含まれるアプリＩＤが「ａｐｐ０１」、バージョンが「ｖ２」である場合、外部ストレージ連携ＡＰＩ６１は、ストレージサービスＡ用アプリ６２_１に対してデータアップロード要求を依頼する。

ステップＳ１５１０において、ストレージサービス用アプリ６２は、外部ストレージシステム４０に対して、画像データのアップロード要求を行う。そして、外部ストレージシステム４０は、アップロード要求に含まれる保存先情報が示すフォルダに画像データを保存する。

以上により、本実施形態に係るサービス提供システム２０では、ユーザが画像形成装置１０で原稿をスキャンして生成した画像データを、所望のストレージサービス（外部ストレージシステム４０）の所望のフォルダに保存（アップロード）することができる。また、所望の外部ストレージシステム４０への画像データのアップロードは、外部ストレージ共通フレームワーク２８を用いて行うことができる。したがって、サービス提供システム２０が提供するストレージサービスを追加・削除等する場合においても、外部ストレージ共通フレームワーク２８内だけに追加・削除に伴う影響を限定させることができる。

［第２の実施形態］
次に、第２の実施形態に係る情報処理システム１について説明する。第２の実施形態に係る情報処理システム１では、ＯＡｕｔｈを用いて外部ストレージシステム４０との認証及びＷｅｂＡＰＩの認可を行う点が第１の実施形態と異なる。なお、以降では、第１の実施形態と実質的に同一の機能を有する箇所及び同一の処理を行う箇所については、第１の実施形態と同一の符号を用いて、その説明を省略する。

＜ソフトウェア構成＞
本実施形態に係る情報処理システム１は、例えば図１６に示されるような処理ブロックにより実現することができる。図１６は、第２の実施形態に係る情報処理システムの一例の処理ブロック図である。図１６に示すように、第２の実施形態に係るサービス提供システム２０は、認証部２６Ａの機能が異なる。また、第２の実施形態に係るサービス提供システム２０は、認可設定情報記憶部５５及びＯＡｕｔｈ登録情報記憶部５６を利用する。さらに、第２の実施形態にユーザ情報記憶部５２Ａ及びストレージサービスの設定情報記憶部６３に記憶される情報が異なる。なお、認可設定情報記憶部５５及びＯＡｕｔｈ登録情報記憶部５６は、ＨＤＤ１０８、又はサービス提供システム２０とネットワークを介して接続される記憶装置等を用いて実現可能である。

認証部２６Ａは、ユーザ情報、認可設定情報、及びＯＡｕｔｈ登録情報の管理を行う。また、認証部２６Ａは、他の各部からの依頼に応じて、ユーザ情報、認可設定情報、及びＯＡｕｔｈ登録情報に基づき、認可トークンを取得する。さらに、認証部２６Ａは、例えばサーバアプリ２２からの要求に応じて、認可トークンを返信する。ここで、認可トークンとは、ＯＡｕｔｈにおける外部ストレージシステム４０の認証及びＷｅｂＡＰＩの認可に用いられるセキュリティトークンである。ＯＡｕｔｈでは、この認可トークンを基づき外部ストレージシステム４０のアクセス制御が行われる。認可トークンには、後述するように、スコープが関連付けられており、認可トークンを用いることでスコープに指定されたリソース（ＷｅｂＡＰＩ）に対するアクセスが許可（認可）される。

また、認可設定情報記憶部５５は、認可設定情報を記憶する。ＯＡｕｔｈ登録情報記憶部５６は、ＯＡｕｔｈ登録情報を記憶する。

＜処理の詳細＞
次に、本実施形態に係る情報処理システムの処理の詳細について説明する。

≪認証情報設定処理≫
まず、情報処理システム１のユーザが利用することができるストレージサービスの認証情報を設定する処理について説明する。図１７は、第２の実施形態に係る認証情報設定処理の一例のシーケンス図である。本実施形態では、ＯＡｕｔｈを用いて設定される認証情報（ユーザ情報）には、ストレージサービス毎の認可トークン及びスコープが含まれる。この設定を行うことにより、ユーザは、サービス提供システム２０に対して外部ストレージシステム４０のリソースに対するアクセス権限を委譲することができる。なお、第２の実施形態に係る認証情報設定処理は、ステップＳ１７０１〜Ｓ１７０８の処理が第１の実施形態と異なる。したがって、以降では、これらの処理について説明する。ただし、ステップＳ５０４において取得される設定情報は、例えば図１８に示すような設定情報１０００Ａであるものとする。図１８に示す設定情報１０００Ａは、一例として、設定情報記憶部６３Ａ_１に記憶されているストレージサービスＡの設定情報１０００Ａを示している。第１の実施形態と異なり、設定情報１０００Ａには、ＵＩ画面を生成するための情報１１００〜１２００は含まれておらず、認証にＯＡｕｔｈを用いることを示す情報１３００が含まれている。このように、設定情報１０００Ａに情報１３００が含まれている場合、ＵＩ画面の生成はポータルアプリ２３で行われず、各外部ストレージシステム４０で行われる（すなわち、ＵＩ画面の生成が各外部ストレージシステム４０に委譲される）。

なお、本実施形態では、ステップＳ５０４で取得されるすべてのストレージサービスの設定情報に、認証にＯＡｕｔｈを用いることを示す情報が指定されている場合について説明する。ただし、これに限られず、認証にＯＡｕｔｈを用いないストレージサービスの設定情報が含まれていてもよい。この場合、認証にＯＡｕｔｈを用いないストレージサービスに対する認証情報設定処理については第１の実施形態で説明した通りである。

ステップＳ１７０１において、ユーザはＰＣ端末３０を操作して、ストレージサービス一覧から所望のストレージサービス（例えば、ストレージサービスＡ）を選択して、ＯＡｕｔｈの認可設定を行う。ここで、認可設定とは、例えば、所望のストレージサービスに対する認可トークンのスコープの設定である。ユーザは、スコープを指定することで、サービス提供システム２０がアクセス可能なリソース（ＷｅｂＡＰＩ）を制限することができる。例えば、「ファイルの読み取りのみ許可することを示すスコープ」を指定することで、サービス提供システム２０に対して外部ストレージシステム４０におけるファイルの読み取り権限を委譲することができる。すなわち、サービス提供システム２０は、外部ストレージシステム４０が提供するＷｅｂＡＰＩを用いて、該当のユーザのファイルの読み取りを行うことができる。本実施形態のように、外部ストレージシステム４０に対するデータのアップロード処理を行う場合、ユーザは、少なくとも「ファイルの書き込みを許可することを示すスコープ」を指定する必要がある。なお、スコープは、サービス提供システム２０により指定されるようにしてもよい。

ステップＳ１７０２において、ＰＣ端末３０のＷｅｂブラウザ（不図示）は、認可設定要求をポータルアプリ２３に送信する。ここで、認可設定要求には、ユーザの利用者ＩＤと、上記のステップＳ１７０１で選択されたストレージサービスを示す情報（例えば、アプリＩＤ「ａｐｐ００１」）と、指定されたスコープを示す情報とが含まれる。

ステップＳ１７０３において、ポータルアプリ２３は、ＰＣ端末３０から受け取った認可設定要求を認証部２６Ａに送信する。

ステップＳ１７０４において、認証部２６Ａは、受け取った認可設定要求に含まれるユーザの利用者ＩＤと、ストレージサービスを示す情報（これを以降、「外部ストレージサービスＩＤ」と表す）と、スコープを示す情報とを認可設定情報記憶部５５に記憶されている図１９に示すような認可設定情報テーブルに保存する。また、認証部２６Ａは、ＯＡｕｔｈ登録情報記憶部に記憶されているＯＡｕｔｈ登録情報テーブルから該当のクライアントＩＤを取得して、上記の認可設定情報として保存する。さらに、認証部２６Ａは、このとき保存された認可設定情報に対して、認可設定情報ＩＤを付与する。

したがって、例えば、利用者ＩＤが「Ｔｏｎｙ」、外部ストレージサービスＩＤが「ａｐｐ００１」、スコープが「ａａ」及び「ｂｂ」である場合、ＯＡｕｔｈ登録情報テーブルからクライアントＩＤ「ＡＡＡＡＡＡＡ」が取得されるとともに、情報処理システム１内で一意な認可設定情報ＩＤ「０３ｊｉｇａｗｏｅａ２」が採番され、図１９に示す認可設定情報テーブルの１行目のレコードが認可設定情報記憶部５５に格納される。なお、このとき、「リフレッシュトークン」は未指定（ブランク）である。

そして、認証部２６Ａは、上記の認可設定情報の保存が完了すると、認可設定情報ＩＤと、ＯＡｕｔｈ登録情報テーブルから該当の外部ストレージサービスＩＤのレコードとを、ポータルアプリ２３を介して、ＰＣ端末３０に返信する。例えば、認可設定要求に含まれる外部ストレージサービスＩＤが「ａｐｐ００１」である場合、図２０に示すＯＡｕｔｈ登録情報テーブルの１行目のレコードをＰＣ端末３０に返信する。

ステップＳ１７０５において、ＰＣ端末３０のＷｅｂブラウザ（不図示）は、受け取ったＯＡｕｔｈ登録情報に含まれる認可サーバＵＲＬにアクセス（リダイレクト）する。ここで、認可サーバＵＲＬとは、該当の外部ストレージシステム４０に対する認証を行うための画面（例えばログイン画面）等のＵＲＬである。このような画面において、ユーザは、該当の外部ストレージシステム４０に対して認証を行うための情報（例えば、ユーザＩＤ及びパスワード等）を入力して認証を行う。そして、外部ストレージシステム４０は、認証結果をＰＣ端末３０に返信する。以降では、外部ストレージシステム４０に対する認証が成功したものとして説明を続ける。

ステップＳ１７０６において、ＰＣ端末３０のＷｅｂブラウザ（不図示）は、認証成功を示す認証結果を受け取ると、認可要求を該当の外部ストレージサービス４０に送信する。ここで、認可要求には、ＯＡｕｔｈ登録情報から取得したクライアントＩＤ及びリダイレクト先のＵＲＬ、並びにステップＳ１７０１で指定したスコープ等の情報が含まれる。そして、外部ストレージシステム４０は、認可要求に対する認可応答を示す認可コードを発行し、ＰＣ端末３０のＷｅｂブラウザ（不図示）をリダイレクト先のＵＲＬにリダイレクトさせる。

なお、上記のステップＳ１７０５で認証が成功した後、ＰＣ端末３０のＷｅｂブラウザ（不図示）に、サービス提供システム２０に対して該当の外部ストレージシステム４０へのＯＡｕｔｈを用いたアクセスを許可するか否かを選択させるための画面を表示させてもよい。そして、ユーザにより、当該画面において「許可する」ことを示す選択がなされた場合に、ＰＣ端末３０のＷｅｂブラウザ（不図示）は、上記認可要求を該当の外部ストレージシステム４０に送信するようにしてもよい。

ここで、ＯＡｕｔｈ登録情報とは、例えば、情報処理システム１の管理者であるユーザ等により予め登録される情報である。例えば管理者であるユーザは、予め外部ストレージシステム４０に対してリダイレクト先ＵＲＬを登録するとともにクライアントＩＤ及びクライアントシークレットを取得し、認可サーバＵＲＬとともにＯＡｕｔｈ登録情報テーブルに格納させておく。なお、クライアントＩＤ及びクライアントシークレットとは、それぞれ「Consumer key」及び「Consumer secret」とも称され、それぞれ外部ストレージシステム４０がサービス提供システム２０を識別する識別情報及びこの識別情報とともに利用される秘密鍵である。

ステップＳ１７０７において、ＰＣ端末３０のＷｅｂブラウザ（不図示）は、認可設定情報ＩＤと、上記のステップＳ１７０６で取得した認可コードとを認証部２６Ａに送信する。

ステップＳ１７０８において、認証部２６Ａは、認可トークンの取得要求を該当の外部ストレージサービス４０に送信する。すなわち、認証部２６Ａは、受け取った認可設定情報ＩＤから該当の外部ストレージサービス４０を特定するとともに、特定した外部ストレージサービス４０のクライアントＩＤ及びクライアントシークレットをＯＡｕｔｈ登録情報から取得する。そして、クライアントＩＤ、クライアントシークレット、及び認可コードに基づく認可トークンの取得要求を該当の外部ストレージシステム４０に送信する。例えば、認可トークンの取得要求に、クライアントＩＤ、クライアントシークレット、及び認可コードが含まれるようにしてもよいし、クライアントＩＤ及び認可コードが含まれる（クライアントシークレットは含まれない）ようにしてもよい。そして、該当の外部ストレージシステム４０は、認可トークン、この認可トークンの有効期限、及びリフレッシュトークンを認証部２６Ａに送信する。ここで、リフレッシュトークンとは、認可トークンの有効期限が経過した（すなわち、有効期限が切れた）場合に、新たな認可トークンを取得するためのセキュリティトークンである。なお、セキュリティトークンを用いずに、認可トークンの有効期限が切れた場合、再度、上記のステップＳ１７０１〜Ｓ１７０９の処理を行うようにしてもよい。

ステップＳ１７０９において、認証部２６Ａは、取得した認可トークン及び有効期限を、利用者ＩＤ、外部ストレージサービスＩＤ、及び上記のステップＳ１７０１で指定したスコープと関連付けて、例えば図２１に示すようなユーザ情報記憶部５２Ａのユーザ情報テーブルに格納する。例えば、図２１に示す１行目のレコード（ユーザ情報）は、利用者ＩＤが「Ｔｏｎｙ」、外部ストレージサービスＩＤが「ａｐｐ００１」、取得した認可トークンが「ｔｏｋｅｎ：ａａａａａ」、この認可トークンのスコープが「ａａ」及び「ｂｂ」、この認可トークンの有効期限が「２０１４／１０／１５」であることを示している。これにより、ユーザ及び外部ストレージサービス４０毎の認可トークン、認可トークンのスコープ、並びに認可トークンの有効期限が管理される。

また、認証部２６Ａは、受け取ったリフレッシュトークンを、該当の認可設定情報ＩＤの認可設定情報テーブルに格納する。すなわち、上記と同じ利用者ＩＤ及び外部ストレージサービスＩＤである場合、図１９に示す１行目のレコード（認可設定情報）に、取得したリフレッシュトークン「ＸＸＸＸＸＸＸ」が格納される。

以上により、本実施形態に係るサービス提供システム２０では、ユーザは、ＰＣ端末３０から所望のストレージサービスの認証情報を設定することができる。また、本実施形態では、このような認証情報の設定にＯＡｕｔｈを用いることにより、ユーザは、サービス提供システム２０に対して外部ストレージシステム４０のユーザＩＤやパスワード等を保存する必要なく、サービス提供システム２０を利用することができる。

≪データ保存先情報設定処理及びデータアップロード処理≫
次に、第２の実施形態に係るデータ保存先情報設定処理及びデータアップロード処理について説明する。第２の実施形態に係るデータ保存先情報設定処理及びデータアップロード処理は、それぞれ図２２及び図２３に示すステップＳ２２０１及びステップＳ２３０１の処理が第１の実施形態と異なる。これらのステップＳ２２０１及びステップＳ２３０１の処理は、略同様の処理であるため、以降ではステップＳ２２０１におけるＯＡｕｔｈによる認可処理について説明する。

≪ＯＡｕｔｈによる認可処理≫
次に、図２２のステップＳ２２０１におけるＯＡｕｔｈによる認可処理について説明する。図２４は、第２の実施形態に係るＯＡｕｔｈによる認可処理の一例のシーケンス図である。

ステップＳ２４０１において、サーバアプリ２２は、利用者ＩＤ及び外部ストレージサービスＩＤ（例えば、アプリＩＤ）を含む認可トークンの取得要求を認証部２６Ａに送信する。

ステップＳ２４０２において、認証部２６Ａは、ユーザ情報記憶部５２Ａに記憶されているユーザ情報テーブルから該当の認可トークンを取得する。例えば、認可トークンの取得要求に含まれる利用者ＩＤが「Ｔｏｎｙ」、外部ストレージサービスＩＤが「ａｐｐ００１」である場合、認証部２６Ａは、図２１に示すユーザ情報テーブルから認可トークン「ｔｏｋｅｎ：ａａａａａ」を取得する。そして、認証部２６Ａは、取得した認可トークンの有効期限が切れているか否かを判定する。認証部２６は、取得した認可トークンの有効期限が切れていると判定された場合、ステップＳ２４０３及びステップＳ２４０４を行う一方、取得した認可トークンの有効期限が切れていないと判定された場合、取得した認可トークンをサーバアプリ２２に送信する。

なお、認証部２６Ａは、取得した認可トークンの有効期限が切れているか否かに関わらず、ステップＳ２４０３及びステップＳ２４０４の処理を行い、新たな認可トークンを取得してもよい。

ステップＳ２４０３において、認証部２６Ａは、認可設定情報記憶部５５に記憶されている認可設定情報テーブルから該当のリフレッシュトークンを取得する。例えば、認可トークンの取得要求に含まれる利用者ＩＤが「Ｔｏｎｙ」、外部ストレージサービスＩＤが「ａｐｐ００１」である場合、認証部２６は、図１９に示す認可設定情報テーブルからリフレッシュトークン「ＸＸＸＸＸＸＸ」を取得する。そして、認証部２６Ａは、取得したリフレッシュトークンを含む認可トークンの取得要求を該当の外部ストレージシステム４０に送信する。すると、外部ストレージシステム４０は、新たな認可トークン及びこの認可トークンの有効期限を返信する。

ステップＳ２４０４において、認証部２６Ａは、該当の外部ストレージシステム４０から取得した新たな認可トークン及び有効期限を、ユーザ情報記憶部５２Ａに記憶されているユーザ情報テーブルに保存する。すなわち、上記のステップＳ２４０２で取得した認可トークン及びこの認可トークンの有効期限を、新たな認可トークン及びこの認可トークンの有効期限で上書き保存する。これにより、認可トークン及び有効期限が更新される。そして、認証部２６Ａは、新たな認可トークンをサーバアプリ２２に送信する。

以上により、サーバアプリ２２は、認可トークンを取得することができる。サーバアプリ２２は、後述の処理（図２２のステップＳ１２０７以降の処理）において取得した認可トークンを用いて外部ストレージシステム４０のＷｅｂＡＰＩ（ディレクトリ情報取得ＡＰＩ等）を利用することができる。また、サーバアプリ２２が認可トークンを用いて利用することができる外部ストレージシステム４０のＷｅｂＡＰＩは、認可トークンに設定されたスコープで指定されたリソース（ＷｅｂＡＰＩ）である。したがって、ユーザ又はサービス提供システム２０は、必要なリソースに限ってスコープを指定することで、セキュリティの確保を図ることができる。

以上により、本実施形態に係るサービス提供システム２０は、ＯＡｕｔｈに規定される認可トークンを用いて外部ストレージシステム４０のＷｅｂＡＰＩを利用することができる。なお、図２３に示すステップＳ２３０１のＯＡｕｔｈによる認可処理は、上記において「サーバアプリ２２」を、「外部ストレージ連携部２５１」と読み替えればよい。

＜まとめ＞
以上の第１の実施形態に係るサービス提供システム２０によれば、連携して処理を行うストレージサービスの追加・変更等を容易に行うことができる。すなわち、サービス提供システム２０と連携して処理を行うストレージサービスの追加・変更等を行う場合においても、外部ストレージ共通フレームワーク２８内に追加・変更等に伴う影響を限定することができる。例えば、外部ストレージ共通フレームワーク２８のストレージサービス用アプリ６２を追加・変更する場合、サービス提供システム２０の追加・変更手段（不図示）を用いて、サービス提供システム２０全体の稼働は維持したまま、追加・変更を行うことができる。したがって、ストレージサービスの追加・変更等に伴う開発工数や開発期間を削減することができる。

また、第２の実施形態に係るサービス提供システム２０によれば、さらに、ストレージサービスに対する認証及びＷｅｂＡＰＩの利用許可が、ＯＡｕｔｈの仕組みを用いて提供される。したがって、ユーザは、ストレージサービスにおけるユーザＩＤ及びパスワード等をサービス提供システム２０に保存させる必要がなく、セキュリティを確保することができる。また、同時に、ユーザは、ＯＡｕｔｈの仕組みを用いることで、サービス提供システム２０に対して必要な範囲に限り、リソースのアクセスを許可（認可）することができる。

なお、本実施形態においては、入力元として画像形成装置１０においてスキャンした画像データを、出力先として外部ストレージシステム４０に保存する場合について説明したが、これに限られない。例えば、入力元としてはスキャンしたものに限られず、デジタルカメラ、携帯電話等で撮像された画像データであってもよいし、また、画像データに限られずＰＣで作成された文書データ、ＩＣレコーダで作成された音声データ等の種々の電子データであってもよい。また、出力先としては、例えば、プロジェクタのような画像投影装置、プリンタ、会議システム等であってもよい。

その他、電子データの入力元又は出力元としては、電子データの入力手段又は出力手段として機能可能な機器であれば、他の機器を用いて、本実施の形態と同趣旨のサービスが実現されていてもよい。

さらに、入力元から入力した画像データについてサービス提供システム２０において所定の処理を施してから出力先に出力してもよい。例えば、入力元として画像形成装置１０においてスキャンした画像データを、サービス提供システム２０においてＯＣＲ処理を行い、この処理結果であるテキストデータを出力先に出力してもよい。また、例えば、文書データを入力した場合には、サービス提供システム２０において、言語の翻訳処理等を行い、この処理結果を出力先に出力してもよい。

なお、ＷｅｂＡＰＩ２１は、受付手段の一例である。サーバアプリ２２及びポータルアプリ２３は、第１のプログラムの一例である。ストレージサービス用アプリ６２は、第２のプログラムの一例である。外部ストレージ連携ＡＰＩ６１は、インタフェース手段の一例である。外部ストレージ共通フレームワーク２８は、処理要求手段の一例である。プロキシ部２７は、転送手段の一例である。アプリＩＤは、外部サービスの識別情報及び第２のプログラムの識別情報の一例である。転送先ホスト情報は、アドレス情報の一例である。認証部２６Ａは、取得手段の一例である。認可トークンは、認可情報の一例である。

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

１ 情報処理システム
１０ 画像形成装置
１１ クライアントアプリ
２０ サービス提供システム
２１ ＷｅｂＡＰＩ
２２ サーバアプリ
２３ ポータルアプリ
２４ サービス情報部
２５ 外部ストレージ配信部
２６ 認証部
２７ プロキシ部
２８ 外部ストレージ共通フレームワーク
３０ ＰＣ端末
４０ 外部ストレージシステム
５１ サービス情報記憶部
５２ ユーザ情報記憶部
５３ データ保存先情報記憶部
５４ プロキシ変換情報記憶部
６１ 外部ストレージ連携ＡＰＩ
６２ ストレージサービス用アプリ
６３ ストレージサービスの設定情報記憶部

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

Claims (10)

1. １以上の情報処理装置を含む情報処理システムであって、
   前記情報処理装置の上で動作する第１のプログラムがＷｅｂＡＰＩを介して第１の処理要求を受け付けると、該第１のプログラムが前記第１の処理要求に対応する第２の処理要求を、前記第１のプログラムと連携して処理を行う１以上の外部サービス間で共通に利用され、かつ、前記１以上の外部サービスにそれぞれ対応する１以上の第２のプログラムが含まれるフレームワークに対して行う要求手段と、
   前記要求手段による前記第２の処理要求を受け付けると、前記フレームワーク内に定義された複数のインタフェース手段のうち、前記第２の処理要求に含まれるアプリケーションＩＤ及び該アプリケーションのバージョンに対応する外部サービスの識別情報により識別される外部サービスとの間で利用されるインタフェース手段を介して、前記アプリケーションＩＤ及び前記バージョンに対応する第２のプログラムが、前記識別情報により識別される外部サービスに対して前記第２の処理要求に基づく第３の処理要求を行う処理要求手段と、
   を有する情報処理システム。
2. 前記情報処理システムは、
   前記１以上の第２のプログラムのうちの前記第３の処理要求を行う第２のプログラムが搭載されている前記情報処理装置のアドレス情報を取得し、該アドレス情報に基づき該第２のプログラムに前記第２の処理要求を転送する転送手段をさらに有し、
   前記１以上の第２のプログラムのうちの前記転送手段により転送された前記第２の処理要求を受信した第２のプログラムは、前記転送手段により転送された前記第２の処理要求を受け付けると、前記複数のインタフェース手段のうち前記第２の処理要求に含まれる前記アプリケーションＩＤ及び前記バージョンに対応する前記外部サービスの識別情報により識別される外部サービスとの間で利用されるインタフェース手段を介して、該識別情報により識別される外部サービスに対して前記第３の処理要求を行う、請求項１記載の情報処理システム。
3. 前記第２のプログラムが前記第３の処理要求を行うための認可情報を取得する取得手段を有し、
   前記第２のプログラムは、前記識別情報により識別される外部サービスに対して、前記認可情報を含む前記第３の処理要求を行う、請求項１記載の情報処理システム。
4. 前記認可情報は、ＯＡｕｔｈに規定される認可トークンである、請求項３記載の情報処理システム。
5. 前記第１のプログラムは、前記複数のインタフェース手段を利用するためのモジュールを含み、
   該モジュールは、前記第１の処理要求を受け付けると、該第１の処理要求に対応する前記第２の処理要求を前記転送手段に送信し、
   前記転送手段は、前記モジュールから前記第２の処理要求を受け付けると、前記１以上の第２のプログラムのうちの前記第３の処理要求を行う第２のプログラムが搭載されている前記情報処理装置のアドレス情報を取得し、該アドレス情報に基づき該第２のプログラムに前記第２の処理要求を転送する、請求項２記載の情報処理システム。
6. 前記１以上の外部サービスに対応する１以上の第２のプログラムを、前記情報処理装置に追加する追加手段をさらに有する、請求項２ないし５のいずれか１項に記載の情報処理システム。
7. 前記第１のプログラムは、前記複数のインタフェース手段を利用するためのモジュールを含み、
   該モジュールは、前記第１の処理要求を受け付けると、該第１の処理要求に対応する前記第２の処理要求を前記フレームワークに対して行い、
   前記処理要求手段は、前記モジュールから前記第２の処理要求を受け付けると、前記複数のインタフェース手段のうち、前記第２の処理要求に含まれる前記アプリケーションＩＤ及び前記バージョンに対応する外部サービスの識別情報により識別される外部サービスとの間で利用されるインタフェース手段を介して、前記アプリケーションＩＤ及び前記バージョンに対応する第２のプログラムが、前記識別情報により識別される外部サービスに対して前記第２の処理要求に基づく第３の処理要求を行う、請求項１記載の情報処理システム。
8. １以上の情報処理装置を含む情報処理システムに用いられる情報処理方法であって、
   前記情報処理装置の上で動作する第１のプログラムがＷｅｂＡＰＩを介して第１の処理要求を受け付けると、該第１のプログラムが前記第１の処理要求に対応する第２の処理要求を、前記第１のプログラムと連携して処理を行う１以上の外部サービス間で共通に利用され、かつ、前記１以上の外部サービスにそれぞれ対応する１以上の第２のプログラムが含まれるフレームワークに対して行う要求手順と、
   前記要求手順による前記第２の処理要求を受け付けると、前記フレームワーク内に定義された複数のインタフェース手段のうち、前記第２の処理要求に含まれるアプリケーションＩＤ及び該アプリケーションのバージョンに対応する外部サービスの識別情報により識別される外部サービスとの間で利用されるインタフェース手段を介して、前記アプリケーションＩＤ及び前記バージョンに対応する第２のプログラムが、前記識別情報により識別される外部サービスに対して前記第２の処理要求に基づく第３の処理要求を行う処理要求手順と、
   を有する情報処理方法。
9. 情報処理装置であって、
   前記情報処理装置の上で動作する第１のプログラムがＷｅｂＡＰＩを介して第１の処理要求を受け付けると、該第１のプログラムが前記第１の処理要求に対応する第２の処理要求を、前記第１のプログラムと連携して処理を行う１以上の外部サービス間で共通に利用され、かつ、前記１以上の外部サービスにそれぞれ対応する１以上の第２のプログラムが含まれるフレームワークに対して行う要求手段と、
   前記要求手段による前記第２の処理要求を受け付けると、前記フレームワーク内に定義された複数のインタフェース手段のうち、前記第２の処理要求に含まれるアプリケーションＩＤ及び該アプリケーションのバージョンに対応する外部サービスの識別情報により識別される外部サービスとの間で利用されるインタフェース手段を介して、前記アプリケーションＩＤ及び前記バージョンに対応する第２のプログラムが、前記識別情報により識別される外部サービスに対して前記第２の処理要求に基づく第３の処理要求を行う処理要求手段と、
   を有する情報処理装置。
10. 情報処理装置を、
    前記情報処理装置の上で動作する第１のプログラムがＷｅｂＡＰＩを介して第１の処理要求を受け付けると、該第１のプログラムが前記第１の処理要求に対応する第２の処理要求を、前記第１のプログラムと連携して処理を行う１以上の外部サービス間で共通に利用され、かつ、前記１以上の外部サービスにそれぞれ対応する１以上の第２のプログラムが含まれるフレームワークに対して行う要求手段、
    前記要求手段による前記第２の処理要求を受け付けると、前記フレームワーク内に定義された複数のインタフェース手段のうち、前記第２の処理要求に含まれるアプリケーションＩＤ及び該アプリケーションのバージョンに対応する外部サービスの識別情報により識別される外部サービスとの間で利用されるインタフェース手段を介して、前記アプリケーションＩＤ及び前記バージョンに対応する第２のプログラムが、前記識別情報により識別される外部サービスに対して前記第２の処理要求に基づく第３の処理要求を行う処理要求手段、
    として機能させるためのプログラム。

Images