(57)【要約】      （修正有）【課題】ネットワーク上に接続された複数のＷｅｂサーバがそれぞれ提供する機能を利用するためにＷｅｂサーバと通信する手段を備えた情報処理装置、制御方法、プログラムを提供する。【解決手段】情報処理装置は、ユーザごとに、複数のサーバが提供するサービスのサービス情報と通信認可の認可情報を管理し、ユーザに応じてサービスと認可情報を特定する手段と、サーバへ処理を依頼するコマンドのサーバごとに異なる形式に関する差異情報を管理し、特定されたサービスに基づいて当該サービスに対するコマンドの差異情報を抽出する手段と、共通形式の処理依頼コマンドを受信し、差異情報と認可情報に基づいて１つのサーバへ処理を依頼する送信コマンドを生成する手段と、送信コマンドを該サーバへ送信して応答コマンドを受信する手段と、応答コマンドと差異情報に基づいて処理依頼コマンドに対応する共通形式の共通応答コマンドを生成し返信する手段とを有する。【選択図】図４
2015052826.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバと通信する情報処理装置であって、
情報処理装置のユーザごとに、前記複数のサーバが提供するサービスに関するサービス情報と、前記複数のサーバとの通信の認可に利用する認可情報を管理し、ユーザに応じてサービスと認可情報を特定する認可情報管理手段と、
前記複数のサーバへ処理を依頼するコマンドのサーバごとに異なる形式に関する差異情報を管理し、前記認可情報管理手段によって特定されたサービスに基づいて、当該サービスに対するコマンドの差異情報を抽出する差異情報管理手段と、 
共通形式の処理依頼コマンドを受信し、前記差異情報管理手段により抽出された差異情報と前記認可情報管理手段により特定された認可情報に基づいて、前記複数のサーバの１つへ処理を依頼する送信コマンドを生成する生成手段と、
前記生成手段により生成された送信コマンドを前記１つのサーバへ送信し、それに対する応答コマンドを受信する受信手段と、
前記受信手段により受信された応答コマンドと前記差異情報管理手段により抽出された差異情報に基づいて、前記処理依頼コマンドに対応する共通形式の共通応答コマンドを生成し、前記処理依頼コマンドに応答する応答手段とを有することを特徴とする情報処理装置。
【請求項２】
前記応答手段により共通応答コマンドを生成した後に、生成した共通応答コマンドに対応する前記認可情報の期限が切れたと判断された場合、前記認可情報を更新し、前記１つのサーバへ再送信する手段をさらに有することを特徴とする、請求項１に記載の情報処理装置。
【請求項３】
前記情報処理装置はＰＣから成ること特徴とする、請求項１または２に記載の情報処理装置。
【請求項４】
前記情報処理装置はＭＦＰから成ること特徴とする、請求項１または２に記載の情報処理装置。
【請求項５】
複数のサーバと通信する情報処理装置の制御方法であって、
情報処理装置のユーザごとに、前記複数のサーバが提供するサービスに関するサービス情報と、前記複数のサーバとの通信の認可に利用する認可情報を管理し、ユーザに応じてサービスと認可情報を特定する認可情報管理工程と、
前記複数のサーバへ処理を依頼するコマンドのサーバごとに異なる形式に関する差異情報を管理し、前記認可情報管理工程によって特定されたサービスに基づいて、当該サービスに対するコマンドの差異情報を抽出する差異情報管理工程と、 
共通形式の処理依頼コマンドを受信し、前記差異情報管理工程により抽出された差異情報と前記認可情報管理工程により特定された認可情報に基づいて、前記複数のサーバの１つへ処理を依頼する送信コマンドを生成する生成工程と、
前記生成工程により生成された送信コマンドを前記１つのサーバへ送信し、それに対する応答コマンドを受信する受信工程と、
前記受信工程により受信された応答コマンドと前記差異情報管理工程により抽出された差異情報に基づいて、前記処理依頼コマンドに対応する共通形式の共通応答コマンドを生成し、前記処理依頼コマンドに応答する応答工程とを有することを特徴とする、プロセッサにより実行される制御方法。
【請求項６】
前記応答工程により共通応答コマンドを生成した後に、生成した共通応答コマンドに対応する前記認可情報の期限が切れたと判断された場合、前記認可情報を更新し、前記１つのサーバへ再送信する工程をさらに有することを特徴とする、請求項５に記載の制御方法。
【請求項７】
請求項５または請求項６に記載の制御方法をコンピュータに実行させるためのプログラム。
【請求項８】
請求項７に記載のプログラムを記憶する記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上に接続された複数のＷｅｂサーバがそれぞれ提供する機能を利用するためにＷｅｂサーバと通信する手段を備えた情報処理装置、情報処理装置の制御方法、プログラムに関する。
【背景技術】
【０００２】
ＰＣなどの情報処理装置がネットワーク上のＷｅｂサーバに接続され、Ｗｅｂサーバにより提供されるコンテンツまたは機能を、情報処理装置が備えるＷｅｂブラウザまたは専用のアプリケーションを介して利用することが知られている。最近ではスキャナやプリンタを備えたＭＦＰ（Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｅｒｉｐｈｅｒａｌ）の中にも、上述したようなＷｅｂブラウザまたは専用のアプリケーションを備えているものがある。そして、ＭＦＰは、Ｗｅｂサーバにより提供されるコンテンツをＭＦＰの操作画面に表示し、ユーザからの各種指示を受け付ける。
【０００３】
一方、情報処理装置を取り巻くネットワーク環境に関しては、近年、インターネット上では、様々なＷｅｂサービス提供者による様々なサービスが提供されている。その中、コミュニケーション手段を提供するソーシャル・ネットワーキング・サービス（ＳＮＳ）がその一つである。ＳＮＳとは、社会的ネットワークをインターネット上で構築するサービスの事であって、主目的は人と人のコミュニケーション手段を提供することである。ＳＮＳの基本的な機能とは、プロフィール機能、日記（ブログ）機能、メッセージ送受信機能、コミュニティ機能、ユーザ検索機能である。また、ＳＮＳ提供者は、他のアプリケーションからＳＮＳの機能を利用できるようにするためのインタフェースＡＰＩ（アプリケーション・プログラミング・インタフェース）を提供することが多い。ＰＣ、ＭＦＰなどの情報処理装置が専用のアプリケーションを介して直接ＳＮＳサイトにアクセスせずＳＮＳが提供するコンテンツを利用することができる。
【０００４】
また、ＳＮＳサービスの普及により、インターネット上では様々なＳＮＳが存在する。例えば、Ｔｗｉｔｔｅｒ（商標）という一般的なユーザの間のコミュニケーションを促進するＳＮＳがあり、Ｃｈａｔｔｅｒ（商標）という企業内の社員同士の間のコミュニケーションを促進するＳＮＳがある。ユーザは各自の利用形態に合わせてサービスを選択することが可能となっている。したがって、情報処理装置においても、様々なＷｅｂサービス提供者による様々なＷｅｂサービスと連携してユーザのニーズに応じるソリューションを提供することが重要となっている。
【０００５】
特許文献１における複数のＷｅｂサービス提供サーバ（以下、「Ｗｅｂサーバ」と記載する）と通信を行う手段について説明する。Ｗｅｂサーバに処理を依頼する処理依頼コマンドを送信する際、Ｗｅｂサーバに対応する専用の外部装置がその共通の処理依頼コマンドを受け取り、該対応するＷｅｂサーバが処理可能なコマンドに変換してＷｅｂサーバに送信する。また、Ｗｅｂサーバから処理依頼コマンドに対する応答コマンドを受信する際、前記Ｗｅｂサーバに対応する専用の外部装置がその応答コマンドを受け取り、共通形式の応答コマンドに変換して処理要求元に返す。以上のような通信手段により情報処理装置が、複数のＷｅｂサーバと通信する際、所定の共通処理依頼コマンドを利用することが可能となり、複数のＷｅｂサーバから同じ形式の応答を受信することも可能となる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１２−６３９７２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１の方法では、一つのＷｅｂサーバに対して専用の外部装置を用意する必要がある。その専用の外部装置には、少なくとも処理依頼コマンドを変換する処理部、応答を変換する処理部およびＷｅｂサーバと通信する処理部を具備する必要がある。なお、前記変換及び通信処理は専用のプログラムにより実現されている。そして、新しいＷｅｂサーバと通信する機能を追加する際、前記専用の外部装置の中に新規で変換及び通信処理を行う専用プログラムを作成する必要がある。そのため、新しいＷｅｂサーバと通信する機能が出来上がるまでの時間および専用プログラムを作成するためのコストがかかる、という課題がある。
【０００８】
また、Ｗｅｂサーバの通信コマンドの仕様が変更された場合、前記専用の外部装置の中のプログラムを変更する必要があるため、変更する時間およびコストがかかる。同時に、すでにその専用外部装置を導入した情報処理装置には、変更したプログラムを更新する必要があるため、更新する手間およびコストもかかる、という課題もある。
【０００９】
また、ＷｅｂサーバはＳＮＳを提供するサーバの場合、前記専用の外部装置は、Ｗｅｂサーバと通信するために利用者の認可情報が必要である。しかし、前記専用の外部装置は認可情報を管理していないため、異なるＷｅｂサービスアカウントを持つ利用者が特許文献１の通信方法を利用する情報処理装置を介して複数のアカウントを切り替えて利用することが困難になる。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本発明は、情報処理装置のユーザごとに、複数のサーバが提供するサービスに関するサービス情報と、サーバとの通信の認可に利用する認可情報を管理し、ユーザに応じてサービスと認可情報を特定する認可情報管理手段と、複数のサーバへ処理を依頼するコマンドのサーバごとに異なる形式に関する差異情報を管理し、認可情報管理手段によって特定されたサービスに基づいて、当該サービスに対するコマンドの差異情報を抽出する差異情報管理手段と、共通形式の処理依頼コマンドを受信し、差異情報管理手段により抽出された差異情報と認可情報管理手段により特定された認可情報に基づいて、複数のサーバの１つへ処理を依頼する送信コマンドを生成する生成手段と、生成手段により生成された送信コマンドを前記１つのサーバへ送信し、それに対する応答コマンドを受信する受信手段と、受信手段により受信された応答コマンドと差異情報管理手段により抽出された差異情報に基づいて、処理依頼コマンドに対応する共通形式の共通応答コマンドを生成し、処理依頼コマンドに応答する応答手段とを有する情報処理装置を提供する。
【発明の効果】
【００１１】
本発明によれば、特許文献１のように共通のコマンドを利用して複数Ｗｅｂサーバと通信することができる上、新しい通信先サービスを追加する際、そのＷｅｂサーバと通信するための通信コマンドの差異情報を追加するだけで対応できる。そのため、プログラム修正が不要であり、追加作業が容易になる。さらに、Ｗｅｂサーバの通信コマンドの仕様が変更された場合、前記通信コマンドの差異情報を変更するだけで対応できるため、変更の対応も容易になる。さらに、Ｗｅｂサーバと通信する際の利用者認可情報を管理するため、ＳＮＳのような認可情報が必要なＷｅｂサーバと通信することも可能になる。
【図面の簡単な説明】
【００１２】
【図１】実施例１における情報処理システムの全体図である。
【図２】実施例１における情報処理装置の構成を示すブロック図である。
【図３】実施例１におけるＷｅｂサーバの構成を示すブロック図である。
【図４】実施例１における情報処理装置のソフトウェア構成を示す図である。
【図５】実施例１におけるアプリケーションのログイン画面の例を示す図である。
【図６】実施例１におけるアプリケーションのサービス選択画面の例を示す図である。
【図７】実施例１におけるアプリケーションのＷｅｂサービス連携画面の例を示す図である。
【図８】実施例１における認可情報管理部が管理する認可情報の構成を示す図である。
【図９】実施例１におけるユーザがログインおよびサービスを選択する時の処理を示すシーケンス図である。
【図１０】実施例１における差異情報管理部が管理する差異情報の構成を示す図である。
【図１１】実施例１におけるＷｅｂサーバに処理を依頼する時の動作を示すシーケンス図である。
【図１２】実施例１における共通処理依頼コマンドの構成を示す図である。
【図１３】（ａ）及び（ｂ）は、実施例１における送信コマンドの構成の例を示す図である。
【図１４】実施例１におけるＷｅｂサーバから応答コマンドを受信する時の動作を示すシーケンス図である。
【図１５】実施例１における、（ａ）は応答コマンドの構成の例を示す図であり、（ｂ）は応答差異情報の構成の例を示す図であり、（ｃ）は共通応答コマンドの構成の例を示す図である。
【図１６】実施例１における認可情報を更新する時の動作を示すシーケンス図である。
【図１７】実施例２における情報処理システムの全体図である。
【図１８】実施例２における通信サービス提供サーバおよび情報処理装置のソフトウェア構成を示す図である。
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための最良の形態について図面を用いて説明する。なお、以下の実施の形態は特許請求の範囲に係る発明を限定するものでなく、また実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。
【００１４】
＜実施例１（ＭＦＰ）＞
実施例１では、本発明の情報処理装置の一例であるＭＦＰと複数Ｗｅｂサーバを含むシステムを用いた、ＭＦＰと複数Ｗｅｂサーバ間の通信処理の例を説明する。なお、本実施例においてのＷｅｂサーバはＳＮＳ提供サーバに該当する。
【００１５】
＜システム構成＞
図１は、実施例１における情報処理システムの全体図である。ＬＡＮ１１０には、ＭＦＰ１００、ＷｅｂサーバＡ１０１およびＷｅｂサーバＢ１０２が互いに通信可能に接続されている。以下、ＷｅｂサーバＡ１０１またはＷｅｂサーバＢ１０２の片方を表す際、Ｗｅｂサーバ１０Ｘと記述する。
【００１６】
＜ＭＦＰ構成＞
図２は、実施例１におけるＭＦＰ１００の構成を示すブロック図である。制御部２００は、ＭＦＰ１００全体の動作を制御する。ＣＰＵ（プロセッサ）２０１は、ＲＯＭ２０２に記憶された制御プログラムを読み出して読取制御や送信制御などの各種制御を行う。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ２０４は、画像データや各種プログラム、或いは各種情報テーブルを記憶する。
【００１７】
操作部Ｉ／Ｆ２０５は、操作部２０９と制御部２００とを接続する。操作部２０９には、タッチパネル機能を有する液晶表示部やキーボードなどが備えられている。プリンタＩ／Ｆ２０６は、プリンタ２１０と制御部２００とを接続する。プリンタ２１０で印刷すべき画像データはプリンタＩ／Ｆ２０６を介して制御部２００から転送され、プリンタ２１０において記録媒体上に印刷される。スキャナＩ／Ｆ２０７は、スキャナ２１１と制御部２００とを接続する。スキャナ２１１は、原稿上の画像を読み取って画像データを生成し、スキャナＩ／Ｆ２０７を介して制御部２００に入力する。ネットワークＩ／Ｆ２０８は、制御部２００（ＭＦＰ１００）をＬＡＮ１１０に接続する。ネットワークＩ／Ｆ２０８は、ＬＡＮ１１０上の外部装置（例えば、ＷｅｂサーバＡ１０１）に画像データや情報を送信したり、ＬＡＮ１１０上の外部装置から各種情報を受信したりする。
【００１８】
＜Ｗｅｂサーバ構成＞
図３は、実施例１におけるＷｅｂサーバＡ１０１の構成を示すブロック図である。制御部３００は、ＷｅｂサーバＡ１０１全体の動作を制御する。ＣＰＵ３０１は、ＲＯＭ３０２に記憶された制御プログラムを読み出して各種制御処理を実行する。ＲＡＭ３０３は、ＣＰＵ３０１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ３０４は、画像データや各種プログラム、或いは後述する各種情報を記憶する。ネットワークＩ／Ｆ３０５は、制御部３００（ＷｅｂサーバＡ１０１）をＬＡＮ１１０に接続する。ネットワークＩ／Ｆ３０５は、ＬＡＮ１１０上の他の装置との間で各種情報を送受信する。なお、ＷｅｂサーバＢ１０２はＷｅｂサーバＡ１０１と同じ構成である。
【００１９】
＜ＭＦＰソフトウェア構成＞
図４は、図１に示したＭＦＰ１００のソフトウェア構成を示すブロック図である。図４に示す各機能部は、ＭＦＰ１００のＣＰＵ２０１が制御プログラムを実行することにより実現される。
【００２０】
４００は、ＭＦＰ１００上で動作するアプリケーション（アプリケーションＡ）である。本実施例においては、アプリケーションＡ４００はＭＦＰ１００のＯＳ上で動作することを想定して説明する。なお、アプリケーションＡ４００は直接ＭＦＰ１００のＯＳ上で動作するのではなく、ＭＦＰ１００内の仮想マシン上で動作するアプリケーションであっても構わない。例えば、Ｊａｖａ（登録商標）の仮想マシン上で動作するアプリケーションでも良い。
【００２１】
４０１は、ＵＩ制御部であって、操作部２０９に操作画面を表示するための制御処理を行うソフトウェアモジュールである。ＵＩ制御部４０１はアプリケーションＡ４００が起動された際、図５のようなログイン画面５００を表示する。また、ＵＩ制御部４０１は操作部２０９から受け取ったユーザの操作に応じて画面の遷移、コマンド変換通信モジュール４１０に処理依頼コマンドを送信するなどの処理を行う。ここの処理依頼コマンドは、共通形式の共通処理依頼コマンド１１２０であって、その詳細は図１１の説明で後述する。
【００２２】
４０２は、通信部であって、ＭＦＰ１００のネットワークＩ／Ｆ２０８を介してＷｅｂサーバ１０Ｘと通信を行うソフトウェアモジュールである。通信部４０２は、送信コマンド生成部４１２が生成した送信コマンド１１２３を受け取った際、ネットワークＩ／Ｆ２０８にＷｅｂサーバ１０Ｘへコマンドを送信する依頼を発行する。送信コマンド１１２３の詳細は図１１の説明で後述する。また、通信部４０２は、Ｗｅｂサーバ１０Ｘが返す応答コマンド１４２０をネットワークＩ／Ｆ２０８から受信し、応答コマンド生成部４１３に提供する処理を行う。応答コマンド１４２０の詳細は図１４の説明で後述する。
【００２３】
４１０は、コマンド変換通信モジュールである。コマンド変換通信モジュール４１０は、ＵＩ制御部４０１から受信した共通処理依頼コマンド１１２０を送信先Ｗｅｂサーバ１０Ｘに適した送信コマンド１１２３に変換する処理を行う。また、コマンド変換通信モジュール４１０は、変換した送信コマンド１１２３を通信部４０２に通知し、Ｗｅｂサーバ１０Ｘに送信する要求を行う。さらに、コマンド変換通信モジュール４１０は、通信部４０２を介してＷｅｂサーバ１０Ｘから受け取った応答コマンド１４２０に基づく共通フォーマットの共通応答コマンド１４２２を生成し、生成したコマンドをＵＩ制御部４０１に返信する処理を行う。共通応答コマンド１４２２の詳細は図１４の説明で後述する。
【００２４】
４１１は、外部モジュールとコマンド変換通信モジュールとを接続するためのインタフェース部である。Ｉ／Ｆ部４１１は、ＵＩ制御部４０１から共通処理依頼コマンド１１２０を受け取り、送信コマンド生成部４１２にＷｅｂサーバ１０Ｘに送信する送信コマンド１１２３を生成する処理を依頼する。また、Ｉ／Ｆ部４１１は応答コマンド生成部４１３から共通応答コマンド１４２２を受け取り、ＵＩ制御部４０１に返信する処理を行う。
【００２５】
４１２は、送信コマンド生成部であって、Ｉ／Ｆ部４１１から受け取った共通処理依頼コマンド１１２０に従って、Ｗｅｂサーバ１０Ｘに適した送信コマンド１１２３を生成する処理を行うソフトウェアモジュールである。なお、送信コマンド１１２３を生成する際、必要な情報は、差異情報管理部４１４および認可情報管理部４１６から取得する。
【００２６】
４１３は、応答コマンド生成部であって、通信部４０２から受け取った応答コマンド１４２０に従って、共通フォーマットの共通応答コマンド１４２２を生成する処理を行うソフトウェアモジュールである。なお、共通コマンドに変換する際必要な情報は、差異情報管理部４１４から取得する。
【００２７】
４１４は、差異情報管理部であって、それぞれのＷｅｂサーバ１０Ｘに処理を依頼する際のコマンドおよびＷｅｂサーバ１０Ｘが返す応答コマンド１４２０の差異情報を管理するソフトウェアモジュールである。差異情報管理部４１４は、送信コマンド生成部４１２および応答コマンド生成部４１３の要求に従い、差異情報格納部４１５で格納されている差異情報から適切な差異情報を抽出する処理を行う。
【００２８】
４１５は、差異情報格納部である。差異情報格納部４１５は、Ｗｅｂサーバ１０Ｘに処理を依頼する際の送信コマンド１１２３の差異情報、Ｗｅｂサーバ１０Ｘが返す応答コマンド１４２０の差異情報およびＷｅｂサーバ１０Ｘの認可処理を行う際の差異情報を格納する部分である。本実施例におけるＷｅｂサーバ１０ＸはＳＮＳ提供サーバである。ＳＮＳ提供サーバと通信を行う際、ＨＴＴＰ／ＨＴＴＰＳプロトコールが利用されるため、本実施例における差異情報は、ＳＮＳ提供サーバと通信を行なう際のＨＴＴＰ送信メッセージまたはＨＴＴＰ応答メッセージの差異情報となる。本実施例における差異情報の詳細は図１０の説明で後述する。
【００２９】
４１６は、認可情報管理部であって、それぞれのユーザが利用しているそれぞれのＷｅｂサーバ１０Ｘに処理を依頼する際の認可情報を管理するソフトウェアモジュールである。認可情報管理部４１６は、送信コマンド生成部４１２の要求に従い、認可情報格納部４１７で格納されている認可情報からユーザに適した認可情報を特定する処理を行う。また、ユーザはアプリケーションＡ４００にログインする際、認可情報格納部４１７で格納されているユーザの認可情報から、ユーザがアプリケーションＡ４００を利用できるかどうかを判断する処理を行う。
【００３０】
４１７は、認可情報格納部であって、アプリケーションＡ４００を利用できるユーザのログイン情報（ユーザ名、パスワード）、ユーザが利用できるＷｅｂサービスの情報（サービス情報）およびそのＷｅｂサービスにアクセスするための認可情報を格納する。本実施例における認可情報の詳細は図８の説明で後述する。
【００３１】
＜アプリケーション画面構成＞
図５は、アプリケーションＡ４００のログイン画面の例を示す図である。図５に示す画面はＭＦＰ１００のＣＰＵ２０１が制御プログラムを実行することにより、操作部２０９に表示される。なお、下記図６および図７も同様となる。
【００３２】
５００は、アプリケーションＡ４００のログイン画面であって、アプリケーションＡ４００が起動された時、ＵＩ制御部４０１により操作部２０９の液晶画面に表示される画面である。５０１は、アプリケーション終了ボタンである。ユーザが終了ボタン５０１を押下するとアプリケーションＡ４００が終了する。５０２は、ユーザ名入力エリアであって、ユーザがユーザ名を入力するエリアである。５０３は、パスワード入力エリアであって、ユーザがパスワードを入力するエリアである。入力されたパスワードは自動的に内容が判別できない文字（例えば「＊」マーク）に変換される。
【００３３】
５０４は、ログインボタンである。ユーザがログインボタン５０４を押下すると、ＵＩ制御部４０１はその押下イベントを受け付け、ユーザ名入力エリア５０２とパスワード入力エリア５０３内の内容に基づいて認可情報管理部４１６にユーザの確認を依頼する。ユーザがアプリケーションＡ４００を利用できると判断された場合、アプリケーションＡ４００はログイン画面５００からサービス選択画面６００に遷移する。５０５は、メッセージ表示エリアであって、ユーザを指示するメッセージおよび前記入力されたユーザ名とパスワードの確認結果を示すメッセージを表示するエリアである。前記ログインボタン５０４が押下された時、もし入力されているユーザ名とパスワードが有効でない場合、その旨を表すメッセージがメッセージ表示エリア５０５に表示される。
【００３４】
図６は、アプリケーションのサービス選択画面の例を示す図である。６００は、サービス選択画面であって、ログイン画面５００のログインボタン５０４が押下され、且つユーザ名入力エリア５０２とパスワード入力エリア５０３に有効な値が入力された際に表示される画面である。６０１は、アプリケーション終了ボタンであって、ログイン画面５００の終了ボタン５０１と同じ動作となる。
【００３５】
６０２は、サービス選択エリアであって、ユーザが利用したいサービスを選択するエリアである。サービス選択画面６００が最初に表示される時、認可情報格納部４１７で格納された該当ユーザが利用できるサービスの中の一つがデフォルトの値としてサービス選択エリア６０２に表示される。サービス選択エリア６０２の右端の下矢印ボタンを押下すると、利用可能サービス一覧６０３が表示される。サービス一覧６０３中の内容は認可情報格納部４１７で格納された該当ユーザが利用できるサービスである。ユーザがサービス一覧６０３の中のいずれのサービス名を押下すると、押下されたサービス名がサービス選択エリア６０２に表示される。６０４は、サービス選択確認ボタンである。ユーザがサービス選択確認ボタン６０４を押下すると、アプリケーションＡ４００はサービス選択画面６００からＷｅｂサービス連携画面７００に遷移する。
【００３６】
図７は、アプリケーションのＷｅｂサービス連携画面の例を示す図である。７００は、Ｗｅｂサービス連携画面であって、サービス選択画面６００のサービス選択確認ボタンが押下された際に表示される画面である。７０１は、アプリケーション終了ボタンであって、前記ログイン画面５００の終了ボタン５０１と同じ動作となる。
【００３７】
７１０は、プロファイル表示エリアであって、ログインしたユーザが選択したＷｅｂサービスサイトに登録したプロファイル情報（ユーザ名、Eメールアドレス、自己紹介など）を表示するエリアである。７１１、７１２、７１３は、ユーザ名、Ｅメールアドレス、自己紹介を表示するエリアである。それらのエリアに表示される内容は、ＵＩ制御部４０１がコマンド変換通信モジュール４１０にプロファイル取得の共通処理依頼コマンド１１２０を送信し、その応答となる共通応答コマンド１４２２から抽出した内容である。
【００３８】
７２０は、投稿リスト表示エリアであって、ログインしたユーザが選択したＷｅｂサービスサイトの中で自分の一番新しい投稿を表示するエリアである。７２１は、一つの投稿を表示する投稿表示エリアであって、ユーザが選択したＷｅｂサービスに登録したプロファイル画像（左端）、該当投稿の投稿内容（中央）および投稿の時刻（右下）を表示するエリアである。それらの表示内容は、ユーザ名７１１などの表示内容と同じく、Ｗｅｂサービス連携画面７００が表示される前にＵＩ制御部４０１がコマンド変換通信モジュール４１０に経由して選択されたＷｅｂサービスから取得した内容である。なお、投稿リスト表示エリア７２０内のすべての投稿表示エリアは７２１と同じ動作となる。７２２は、投稿リスト更新ボタンである。投稿リスト更新ボタンが押下されると、ＵＩ制御部４０１はそのイベントを受け付け、コマンド変換通信モジュール４１０に新しい投稿リストを取得する共通依頼コマンド１１２０を送信する。そして、ＵＩ制御部４０１は、共通依頼コマンド１１２０の応答となる共通応答コマンド１４２２の内容に従い、投稿リスト表示エリア７２０内のすべての投稿表示エリア７２１の内容を更新する。
【００３９】
７３０は、スキャン連携機能エリアであって、ＭＦＰ１００のスキャン機能とＷｅｂサービスとを連携する機能を表示するエリアである。７３１は、投稿内容入力エリアであって、ユーザが選択したＷｅｂサービスに投稿したい内容を入力するエリアである。７３２は、スキャン投稿ボタンである。スキャン投稿ボタン７３２が押下すると、アプリケーション４００は、スキャナＩ／Ｆ２０７に介してスキャナ２１１に設置された原稿の画像を読み取ってＲＯＭ２０２、ＲＡＭ２０３またはＨＤＤ２０４のいずれに保存する。同時に、ＵＩ制御部４０１は投稿内容入力エリア７３１に書かれた内容をＷｅｂサービスに投稿する共通処理依頼コマンド１１２０をコマンド変換通信モジュール４１０に送信する。そして、ＵＩ制御部４０１は、コマンド変換通信モジュール４１０が返す共通応答コマンド１４２２の内容に従い、投稿処理の結果を投稿メッセージエリア７３３に表示する。７３３は、投稿メッセージ表示エリアであって、スキャン投稿の結果を示すメッセージを表示するエリアである。
【００４０】
＜ユーザログイン処理・サービス選択処理＞
次に、ユーザがアプリケーションＡ４００にログインする時の処理及びユーザがＷｅｂサービスを選択する処理について説明する。まず、ユーザログイン処理を行う際に必要である認可情報を格納する認可情報格納部４１７の構成について説明する。
【００４１】
図８は、認可情報管理部４１６が管理する認可情報の構成を示す図である。８００は、認可情報管理テーブルであって、ユーザが利用するＷｅｂサービスの認可情報を管理するテーブルである。
【００４２】
８０１は、アプリケーションＡ４００を利用できるユーザのユーザ名を保持する列である。８０２は、ユーザを識別するためのパスワードを保持する列である。８０３は、ユーザが利用できるＷｅｂサービスの名前を保持する列である。８０４は、ユーザが利用するＷｅｂサービスにアクセスする際に必要であるアクセストークンを保持する列である。アクセストークンは、ユーザがＷｅｂサービスにアクセスする際、Ｗｅｂサービスがユーザを識別するための情報およびＷｅｂサービスがユーザに与える権限を記述するためのデータ構造である。本実施例のアクセストークンは、ＯＡｕｔｈというＳＮＳ提供サーバで広く使われている認可方式のアクセストークン構造をもつものとする。
【００４３】
８０５は、アクセストークンを更新する時に使用されるリフレッシュトークンを保持する列である。リフレッシュトークンは、アクセストークンの使用期限が切れた場合、Ｗｅｂサーバ１０Ｘに新しいアクセストークンの発行を要求する際に使用するデータ構造である。本実施例のリフレッシュトークンは、アクセストークンと同様に、ＯＡｕｔｈという認可方式のリフレッシュトークン構造をもつものとする。８１０は、一つのユーザ認可情報を示す行である。同じユーザ名に対して８１０のような認可情報の行が複数存在することが可能である。しかし、この場合、パスワード列８０２の内容も同じ内容になる必要があって、利用サービス名列８０３、アクセストークン列８０４およびリフレッシュトークン列８０５の内容が重複することはできない。
【００４４】
以上が認可情報格納部４１７の構成となる。ＵＩ制御部４０１が、認可情報格納部４１７に保持されている情報を利用することにより、ユーザログイン処理およびサービス選択処理を行える。
【００４５】
図９は、ユーザがアプリケーションＡ４００にログインする際およびサービスを選択する際の処理を示すシーケンス図である。初めに、ログイン画面５００での処理を説明する。
【００４６】
まず、ステップＳ９０１で、ユーザが操作部２０９に表示されているログイン画面５００の中のユーザ名入力エリア５０２およびパスワード入力エリア５０３にユーザ名およびパスワードを入力する。ステップＳ９０２で、ユーザがログイン画面５００のログインボタン５０４を押下し、その押下イベントをＵＩ制御部４０１に通知する。ステップＳ９０３で、ＵＩ制御部４０１が、認可情報管理部４１６にユーザの確認処理を要求する。ＵＩ制御部４０１が認可情報管理部４１６にユーザの確認処理を要求する際、入力エリア５０２およびパスワード入力エリア５０３の内容を認可情報管理部４１６に通知する。
【００４７】
ステップＳ９０４で、認可情報管理部４１６がステップＳ９０３でユーザの確認要求が来た際、ユーザを確認する処理Ｓ９０６を行うために認可情報格納部４１７から入力エリアで記録されているユーザ名に該当するユーザ情報を取得する。ステップＳ９０５で、認可情報格納部４１７がステップＳ９０４の要求に適した応答を認可情報管理部４１６に通知する。なお、ここで提供する情報は、前記ユーザ名に該当するパスワードおよび利用サービス名を含む。
【００４８】
ステップＳ９０６で、認可情報管理部４１６がステップＳ９０５で提供されたユーザ名、パスワード情報とステップＳ９０３で提供されたユーザ名入力エリア５０２、パスワード入力エリア５０３の内容に基づいてユーザの確認を行う。ステップＳ９０７で、認可情報管理部４１６がステップＳ９０６での確認結果をＵＩ制御部４０１に通知する。その確認結果は、ユーザがアプリケーションを利用できるかどうかということと、利用できない場合にはその原因を示す内容を含む。
【００４９】
ステップＳ９０８で、ＵＩ制御部４０１がステップＳ９０７で提供された結果に従い、ユーザが次のサービス選択画面６００に進むことが可能かどうか判断する。ステップＳ９０８の判断の結果が「可能」の場合、ＵＩ制御部４０１がステップＳ９０９を行い、操作部２０９にサービス選択画面６００を表示する。ステップＳ９０８の判断の結果が「不可」の場合、その原因を示すメッセージをログイン画面５００のメッセージ表示エリア５０５に表示する。
【００５０】
次にサービス選択画面６００での処理を説明する。まず、ステップＳ９１１で、ユーザがサービス選択画面６００上のサービス選択エリア６０２を介して、利用するサービスを選択する。ステップＳ９１２で、ユーザが確定ボタン６０４を押下し、その押下イベントをＵＩ制御部４０１に通知する。
【００５１】
ステップＳ９１３で、ＵＩ制御部４０１がサービス選択エリア６０２内のサービス名とログインしたユーザのユーザ名に基づく、「ユーザプロファイル取得」の共通処理依頼コマンド１１２０をコマンド変換通信モジュール４１０に送信する。コマンド変換通信モジュール４１０は共通処理依頼コマンド１１２０を受け取り、ユーザプロファイルを取得するための一連の処理を行う。その処理の詳細は図１１及び図１４の説明で後述する。ステップＳ９１４で、コマンド変換通信モジュール４１０がユーザプロファイル取得の処理依頼に対する共通応答コマンド１４２２をＵＩ制御部４０１に返信する。
【００５２】
ステップＳ９１５で、ＵＩ制御部４０１がサービス選択エリア６０２内のサービス名とログインしたユーザのユーザ名を基づく、「投稿リスト取得」の共通処理依頼コマンド１１２０をコマンド変換通信モジュール４１０に送信する。ステップＳ９１６で、コマンド変換通信モジュール４１０が投稿リスト取得の処理依頼に対する共通応答コマンド１４２２をＵＩ制御部４０１に返信する。
【００５３】
ステップＳ９１７で、ＵＩ制御部４０１がステップＳ９１４およびステップＳ９１６で受け取った共通応答コマンド１４２２から連携画面７００を表示するための情報（図７の説明を参照）を抽出して、連携画面７００を生成し、操作部２０９に表示する。
【００５４】
＜送信コマンド生成・送信処理＞
次に、Ｗｅｂサーバ１０Ｘに送信する送信コマンド１１２３を生成する処理および生成した送信コマンド１１２３を送信する処理について説明する。以下、コマンド変換送信モジュール４１０がＵＩ制御部４０１から受け取った共通処理依頼コマンド１１２０に基づいて、ユーザが選択したＷｅｂサーバ１０Ｘに適した送信コマンド１１２３を生成する処理を中心に説明する。まず、送信コマンド１１２３生成処理を行う際に必要である差異情報を格納する差異情報格納部４１５の構成について説明する。
【００５５】
図１０は、差異情報管理部４１４が管理する差異情報の構成を示す図である。１０００は、差異情報管理テーブルであって、ユーザが利用するＷｅｂサービスの差異情報を管理するテーブルである。本実施例における差異情報は、それぞれのＷｅｂサーバ１０Ｘに認可処理を依頼する際の差異を示す情報と、それぞれのＷｅｂサーバ１０Ｘが提供する機能を利用する際の送信コマンド１１２３・応答コマンド１４２０の差異を示す情報である。
【００５６】
１００１は、ＷｅｂサービスＡの差異情報を保持する列である。１００２は、ＷｅｂサービスＢの差異情報を保持する列である。１０１０は認可処理差異情報を保持する行であって、Ｗｅｂサーバ１０Ｘに認可処理を依頼する際の差異情報を保持する行である。本実施例における認可処理は、ＯＡｕｔｈという認可方式の認可処理に従い、主にＨＴＴＰメッセージを利用して行う認可処理である。例えば、図８で説明したリフレッシュトークンを利用してアクセストークンを更新する処理を依頼するＨＴＴＰメッセージは、１０１０の認証Ｕｒｌ、Ｃｌｉｅｎｔ＿Ｉｄ、Ｃｌｉｅｎｔ＿Ｓｅｃｒｅｃｔなどの情報を含む。ＯＡｕｔｈ認証は一般に知られているので、これに関する詳しい説明は省略する。
【００５７】
１０２０、１０３０および１０４０は差異情報を保持する行であって、それぞれのＷｅｂサーバ１０Ｘが提供する機能を利用する際のＨＴＴＰ送信メッセージおよびＨＴＴＰ応答メッセージの差異を示す情報を保持する行である。１０２０は共通差異情報を保持する行であって、それぞれのＷｅｂサーバ１０Ｘの機能を利用する際のＨＴＴＰ送信メッセージの差異情報の共通部分を保持する行である。例えば、ＨＴＴＰメッセージのヘッドフィールド内のＡｕｔｈｏｒｉｚａｔｉｏｎフィールド、Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールドの値が共通差異情報エリア１０２０に保持されている。
【００５８】
１０３０は、それぞれのＷｅｂサーバ１０Ｘにプロファイル取得処理を依頼する際のＨＴＴＰ送信・応答メッセージの前記共通差異情報１０２０以外の差異情報を保持する行である。１０３１は、１０３０のエリアでの処理内容を表す依頼処理名である。１０３２は、プロファイル取得処理を依頼する際のＨＴＴＰ送信メッセージのＨＴＴＰメソッドを保持する行である。１０３３は、プロファイル取得処理を依頼する際のＨＴＴＰ送信メッセージのリクエストＵｒｌを保持する行である。１０３４は、Ｗｅｂサーバ１０Ｘからプロファイル取得処理の依頼に対するＨＴＴＰ応答メッソージを共通のフォーマットに変換する際に必要である情報を保持する行である。
【００５９】
１０４０は、それぞれのＷｅｂサーバ１０Ｘに投稿処理を依頼する際のＨＴＴＰ送信・応答メッセージの前記共通差異情報１０２０以外の差異情報を保持する行である。１０４０エリア内の内容の詳細は１０３０エリアと同様である。
【００６０】
図１１は、Ｗｅｂサーバ１０Ｘに処理依頼コマンドを送信する時の動作を示すシーケンス図であり、図９のＳ９１３、Ｓ９１５の詳細処理を記載したものである。まず、ステップＳ１１０１で、ＵＩ制御部４０１がコマンド変換通信モジュール４１０のＩ／Ｆ部４１１に共通処理依頼コマンド１１２０を送信する。共通処理依頼コマンド１１２０は、Ｉ／Ｆ部４１１で決めている処理を依頼する際の共通フォーマットのコマンドである。
【００６１】
図１２は、共通処理依頼コマンド１１２０の構成を示す図である。共通処理依頼コマンド１１２０は、以下の４つの情報を含む。１２０１はユーザ名であって、認可情報格納部４１７に保持されている同じユーザ名の行を特定するための情報である。１２０２は利用サービス名であって、認可情報格納部４１７に保持されている同じ利用サービス名の行を特定するための情報である。１２０３は依頼処理名であって、差異情報格納部４１５に保持されている同じ依頼処理名の差異情報エリアを抽出するための情報である。１２０４はパラメータ配列であって、差異情報格納部４１６に保持されているリクエストＵｒｌ行の内容から実際送信するＨＴＴＰメッセージのリクエストＵｒｌに変換する時に利用する情報配列である。変換する方法に関してはステップＳ１１０９の説明で後述する。以上１２０１から１２０４の情報はＷｅｂサーバ１０Ｘに送信する送信コマンド１１２３を生成する際に必要となる。本実施例における送信コマンド１１２３はＨＴＴＰ送信メッセージであって、その構成は図１３の説明で後述する。
【００６２】
図１１の説明に戻る。ステップＳ１１０２で、Ｉ／Ｆ部４１１がステップＳ１１０１で受信した共通処理依頼コマンド１１２０の内容に従い、送信コマンド生成部４１２に送信コマンド１１２３の生成を依頼する。依頼する際、共通処理依頼コマンド１１２０で記載された情報を送信コマンド生成部４１２に通知する必要がある。
【００６３】
ステップＳ１１０３で、送信コマンド生成部４１２が共通処理依頼コマンド１１２０の内容に従い、差異情報管理部４１４に差異情報を抽出する処理を依頼する。差異情報抽出を依頼する際、共通処理依頼コマンド１１２０内の利用サービス名１２０２および依頼処理名１２０３を差異情報管理部に通知する必要がある。ステップＳ１１０４で、差異情報管理部４１４がステップＳ１１０３で提供された情報に基づいて、差異情報格納部４１５から送信コマンド１１２３を生成するための情報を抽出する。例えば、依頼処理名１２０３が差異情報格納部４１５内の「プロファイル取得」１０３１に一致し、利用サービス名１２０２が「サービスＡ」に一致する場合、１００１の列の中の１０３２、１０３３、および共通差異情報エリア１０２０の内容が抽出される。ステップＳ１１０５で、差異情報管理部４１４がステップＳ１１０４で抽出した内容を差異情報１１２１として送信コマンド生成部４１２に返信する。
【００６４】
ステップＳ１１０６で、送信コマンド生成部４１２が前共通処理依頼コマンド１１２０の内容に従い、認可情報管理部４１６に認可情報を特定する処理を依頼する。認可情報を特定する際、共通処理依頼コマンド１１２０内のユーザ名１２０１および利用サービス名１２０２を認可情報管理部に通知する必要がある。ステップＳ１１０７で、認可情報管理部４１６がステップＳ１１０６で提供された情報に基づいて、認可情報格納部４１７から送信コマンド１１２３を生成するための情報を特定する。例えば、ユーザ名１２０１が「ＵｓｅｒＡ」、および利用サービス名１２０２が「サービスＡ」に一致する場合、認可情報格納部４１７から行８１０の中のアクセストークン列８０４に該当する内容が特定される。
【００６５】
ステップＳ１１０８で、認可情報管理部４１６がステップＳ１１０７で特定した内容を認可情報１１２２（本実施例ではＯＡｔｕｈ認証を行うためのアクセストークンである）として送信コマンド生成部４１２に返信する。なお、認可情報１１２２が一度特定されると、認可情報の期限が切れてない限り変更することがないので、毎回認可情報管理部４１６に依頼するではなく、送信コマンド生成部４１２がアクセスできるメモリなどに一時保存する方が良い。認可情報の期限が切れた時の処理に関して、図１４の説明で後述する。
【００６６】
ステップＳ１１０９で、送信コマンド生成部４１２がステップＳ１１０５およびステップＳ１１０８で返信された差異情報１１２１および認可情報１１２２に基づいて、送信コマンド１１２３を生成する。図１３は、送信コマンド１１２３の構成の例を示す図である。
【００６７】
図１３（ａ）の１３００は、本例の送信コマンドＡ１３１０に対応する共通処理依頼コマンドＡであって、以下の情報を含む。ユーザ名が「ＵｓｅｒＡ」、利用サービス名が「サービスＡ」、依頼処理名が「プロファイル取得」、パラメータ配列が一つの要素「ＵｓｅｒＡ」を含む配列である。１３１０は、共通処理依頼コマンドＡ１３００に基づいて生成した送信コマンドであって、本実施例ではＨＴＴＰ送信メッセージである。このメッセージは、ＨＴＴＰ送信メッセージの構成に従い、リクエスト行１３１１、ヘッダフィールド１３１２、空行１３１３およびメッセージボディ１３１４の４つの部分から構成される。
【００６８】
送信コマンドＡ１３１０を生成する際、固定となる部分はデフォルトの値として予め設定されている。それ以外に図１３（ａ）に太字で表示する部分はステップＳ１１０９で送信コマンド生成部４１２が差異情報１１２１および認可情報１１２２に基づいて生成したものである。
【００６９】
１３２１は、ＨＴＴＰメソッドであって、その値は、本例の場合、差異情報管理テーブル１０００の中の「プロファイル取得」差異情報エリア１０３０の中のＨＴＴＰメソッドの行１０３２の「サービスＡ」に該当する部分である。１３２２は、ＨＴＴＰリクエストＵｒｌであって、その値は、本例の場合、差異情報管理テーブル１０００の中の「プロファイル取得」差異情報エリア１０３０の中のリクエストＵｒｌの行１０３３の「サービスＡ」に該当する部分から生成したＵｒｌである。これを生成するには、差異情報テーブル１０００から抽出したリクエストＵｒｌの中の「Ｐａｒａｍ」の文字列を共通処理依頼コマンドＡ１３００のパラメータ配列の内容「ＵｓｅｒＡ」に置き換える。差異情報テーブル１０００から抽出したリクエストＵｒｌの中の「Ｐａｒａｍ」文字列が複数ある場合、パラメータ配列内の内容を順次入れ替えることになる。
【００７０】
１３２３は、Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールドであって、その値は、本例の場合、差異情報管理テーブル１０００の中の共通差異情報エリア１０２０の中のＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドの行の「サービスＡ」に該当する部分である。１３２４は、Ａｕｔｈｏｒｉｚａｔｉｏｎフィールドである。その値は、本例の場合「ＵｓｅｒＡ」「サービスＡ」に対して、差異情報管理テーブル１０００の中のＡｕｔｈｏｒｉｚａｔｉｏｎフィールドの内容に、認可情報管理テーブル８００の中のアクセストークンを加えた内容となる。１３１４は、メッセージボディであって、本例の場合は空である。
【００７１】
図１３（ｂ）は、同じプロファイル取得に対してサービスＢを利用するＵｓｅｒＢが処理を依頼する時の共通処理依頼コマンドＢ１３２０および送信コマンドＢ１３３０を示す図である。１３２０は共通処理依頼コマンドＢであって、送信コマンドＢ１３３０はそれに対して生成した送信コマンドである。送信コマンドＢの生成の仕方は送信コマンドＡ１３１０を生成する際と同じになるので、詳細説明を省略する。
【００７２】
再び図１１の説明に戻る。ステップＳ１１１０で、送信コマンド生成部４１２が上述のようにして生成した送信コマンド１１２３を通信部４０２に通知し、Ｗｅｂサーバ１０Ｘに送信する処理を依頼する。ステップＳ１１１１で、通信部４０２がステップＳ１１１０で受け取った送信コマンド１１２３をＷｅｂサーバ１０Ｘに送信する。ここで、送信先などの情報をすでに送信コマンド１１２３の中に記載しているため、通信部４０２は送信先を意識する必要がなく、送信コマンド１１２３であるＨＴＴＰ送信メッセージを送信するだけで良い。
【００７３】
＜応答コマンド受信、生成処理＞
次に、アプリケーションＡ４００がＷｅｂサーバ１０Ｘから応答コマンド１４２０を受信する処理及びＵＩ制御部に返信する共通応答コマンド１４２２を生成する処理について説明する。以下、コマンド変換送信モジュール４１０が、通信部４０２から受け取った応答コマンド１４２０から共通形式の共通応答コマンド１４２２を生成する処理を中心に説明する。
【００７４】
図１４は、Ｗｅｂサーバ１０Ｘから応答コマンドを受信する時の動作を示すシーケンス図である。まず、ステップＳ１４０１で、通信部４０２がＷｅｂサーバ１０Ｘから応答コマンド１４２０を受信する。本実施例における応答コマンド１４２０は、ＨＴＴＰ応答メッセージであって、その構成はＨＴＴＰ応答メッセージの構成に従う。
【００７５】
図１５（ａ）は、応答コマンド１４２０の構成の例を示す図である。１５０１は、Ｗｅｂサーバ１０Ｘが前記送信コマンドＡ１３１０に対する応答の応答コマンドＡである。ＨＴＴＰ応答メッセージは、レスポンス行１５０３、ヘッダフィールド１５０４、空行１５０５およびメッセージボディ１５０６の４つの部分を含む。メッセージボディ１５０６は、送信コマンド１１２３のリクエストに対する応答のデータを格納する部分である。ＷｅｂサーバがＳＮＳサービスを提供する場合、ＪＳＯＮという軽量のデータ交換フォーマットを応答データのフォーマットとして一般的に使用するので、本実施例の場合は、ＪＳＯＮフォーマットのデータに基づいて説明する。ＪＳＯＮデータフォーマットの構造は名前と値のペアのレコードの集まりである。例えば、名前「ａｂｏｕｔＭｅ」１５０７と値「Ｉ  ａｍ  ＵｓｅｒＡ…」１５０８は一つのレコードとなる。
【００７６】
しかし、それぞれのＷｅｂサーバ１０Ｘが策定した応答データのネーミング方式、順序、階層構造は異なるため、同じ方法でそれぞれの応答データからほしいデータを抽出するのは困難になる。例えば、同じく自己紹介を格納するレコードについて、応答コマンドＡ１５０１は「ａｂｏｕｔＭｅ」１５０７という名前であって、応答コマンドＢ１５０２は「ＩｎｔｒｏｄｕｃｅＯｆＭｅ」１５０８という名前になる。また、同じく苗字を格納するレコードについて、応答コマンドＡ１５０１は「ｆｉｒｓｔＮａｍｅ」１５０９という名前であって、応答コマンドＢ１５０２は「ＦａｍｉｌｙＮａｍｅ」１５１０という名前になり、しかも１５０９とは所在する階層も異なる。「ＦａｍｉｌｙＮａｍｅ」１５１０が所在するレコードは、「Ｎａｍｅ」というレコードの中にある。さらに、同じく更新日を格納するレコードについて、応答コマンドＡ１５０１の値は「２０１２−０６−１５Ｔ０１：２６：２８」１５１１であって、応答コマンドＢ１５０２の値は「２０１２−０６−１５Ｔ０１：２６：２８＋０００」１５１２となる。１５１１と１５１２は異なるフォーマットである。前記のようなネーミング、階層および値フォーマットを統一するため、応答コマンド１４２０を統一された形式の共通応答コマンド１４２２に変換する必要がある。次にその変換処理について説明する。
【００７７】
図１４に戻る。ステップＳ１４０２で、通信部４０２が応答コマンド生成部４１３に共通応答コマンド１４２２を生成する処理を依頼する。ステップ１４０３で、応答コマンド生成部４１３が差異情報管理部４１４に共通応答コマンド１４２２を生成する時に必要となる応答差異情報１４２１の抽出要求を依頼する。ステップ１４０４で、差異情報管理部４１４が、応答差異情報１４２１を差異情報格納部４１５から抽出して、応答コマンド生成部に通知する。応答差異情報１４２１の抽出方法については、送信コマンド１１２３を生成するための差異情報１１２１を抽出する方法（Ｓ１１０４）と類似するため、詳細説明を省略する。例えば、共通処理依頼コマンドＡ１３００に対して抽出する応答差異情報Ａ１５１１は差異情報管理テーブル１０００の中の行１０３４の「サービスＡ」の列１００１に該当する内容である。
【００７８】
図１５（ｂ）は共通処理依頼コマンドＡ１３００および共通処理依頼コマンドＢ１３２０に対応する応答差異情報Ａ１５２１および応答差異情報Ｂ１５２２の構成を示す図である。本実施例における応答差異情報１４２１は、生成後の共通応答コマンド１４２２の構造を分かりやすく表現するために、応答コマンド１４２０のメッセージボディ部分および共通応答コマンド１４２２と同じデータフォーマットＪＳＯＮを採用する。例として、１５２３と１５２４は応答差異情報Ａ１５２１内の自己紹介を生成するためのレコードの名前と値である。１５２３は、生成後の共通応答コマンドＡ１５３１の自己紹介レコードの名前を表す内容であって、１５２４は、生成後の自己紹介レコードの値が応答コマンドＡ１５０１のメッセージボディ部分内のどのレコードかを特定するための値である。
【００７９】
応答差異情報１４２１を利用することにより、ステップＳ１４０５で応答コマンド１４２０から共通応答コマンド１４２２を生成する処理を行う。生成する方法について図１５の応答コマンドＡ１５０１の例を用いて説明する。図１５（ｃ）に示すように、共通応答コマンドＡ１５３１の自己紹介レコードの名前１５３３は応答差異情報Ａ１５２１の自己紹介レコードの名前と同じ値になる。その自己紹介レコードの値１５３４は、応答コマンドＡ１５０１のメッセージボディ１５０５の中に、応答差異情報Ａ１５２１の１５２４の値に一致するレコードの値になる。また生成した共通コマンドＡ１５３１の自己紹介レコードが所在する階層も応答差異情報Ａ１５２１の該当レコード（１５２３のレコード）と同じ階層になる。
【００８０】
また、上述した１５０９、１５１０のように所在する階層が異なる場合、１５２５のようなレコードを利用することにより、生成後のレコードの階層を統一することができる。さらに、上述した１５１１、１５１２のように値のフォーマットが異なる場合、１５２６のようなフォーマットのレコードを利用することにより、生成後のレコードの値のフォーマットを統一することができる。レコード１５２６の値の前半「Ｄａｔｅ」部分は応答コマンド１４２０のメッセージボディ内のレコードを特定する部分である。後半の角括弧内の「（＾．｛１９｝）」部分は正規表現式であって、前半部分により特定した値を修正するための記述である。正規表現式は、文字列のような記述により、値の特定、置き換えが可能な記述式である。正規表現を利用することにより、前記の例のように、プログラムを追加せず特定した値を修正することができる。
【００８１】
図１５（ｃ）に、生成した共通応答コマンドの共通応答コマンドＡ１５３１および共通応答コマンドＢ１５３２を示す。
【００８２】
ここで、図１４の説明に戻る。ステップＳ１４０６で、応答コマンド生成部４１３がステップＳ１４０５で生成した共通応答コマンド１４２２の正確性を判断する。１４２３は、応答が空の場合の分岐条件である。もし生成した共通応答コマンド１４２２が空の場合、認可情報の期限が切れた可能性があると判断し、ステップＳ１４０７で認可情報の更新処理を送信コマンド生成部４１２に依頼する。更新処理の詳細は図１６の説明で後述する。
【００８３】
そして、ステップＳ１４０８で、ステップＳ１４０７で認可情報を更新した後応答コマンド生成部４１３が送信コマンド生成部４１２に更新した認可情報が加えた送信コマンド１１２３の生成およびＷｅｂサーバ１０Ｘに再送信することを依頼する。認可情報を加えた送信コマンド１１２３の生成方法およびＷｅｂサーバ１０Ｘに送信する処理のシーケンスは図１１のシーケンスと同様なため詳細説明を省略する。再送信を依頼した後、ステップＳ１４０１に戻り、通信部４０２が再送信したコマンドに対する応答コマンド１４２０を受信する。
【００８４】
１４２４は、正常の場合の分岐条件である。正常の場合、応答コマンド生成部４１３がステップＳ１４０９を行い、生成した共通応答コマンド１４２２をＩ／Ｆ部４１１に通知し、ＵＩ制御部４０１に返信する処理を依頼する。そして、ステップＳ１４１０で、Ｉ／Ｆ部４１１がＵＩ制御部４０１にステップＳ１４０９で受け取った共通応答コマンド１４２２を返信する。
【００８５】
なお、応答が空の場合（１４２３）が一定回数以上連続で発生する場合、Ｗｅｂサーバ１０Ｘとの通信障害が発生していると判断し、操作部２０９にＷｅｂサーバとの通信エラーが発生した旨を表示しユーザに通知する。
【００８６】
＜認可情報更新処理＞
以下、ステップＳ１４０７で依頼する認可情報を更新する処理について説明する。図１６は、認可情報を更新する時の動作を示すシーケンス図である。まず、ステップＳ１４０７で、応答コマンド生成部４１３が送信コマンド生成部４１２に認可情報の更新を依頼する。
【００８７】
ステップＳ１６０１で、送信コマンド生成部４１２が、差異情報管理部４１４に更新するための更新用送信コマンド１６２３を生成する際に必要な認可処理差異情報１６２１の抽出を依頼する。ステップＳ１６０２で、差異情報管理部４１４が差異情報格納部４１５から認可処理差異情報１６２１を抽出する。ここで抽出した認可処理差異情報１６２１は、認可情報管理テーブル１０００内の認可処理差異情報エリア１０１０内の情報である。抽出方法は前記ステップＳ１１０４の差異情報を抽出する方法と同様なため詳細説明を省略する。ステップＳ１６０３で、差異情報管理部４１４が、ステップＳ１６０２で抽出した認可処理差異情報１６２１を送信コマンド生成部４１２に通知する。
【００８８】
ステップＳ１６０４で、送信コマンド生成部４１２が認可情報管理部４１６に更新用送信コマンド１６２３を生成する際に必要な認可情報更新情報１６２３の特定を依頼する。
【００８９】
ステップＳ１６０５で、認可情報管理部４１６が認可情報格納部４１７において認可情報更新情報１６２２を特定する。ここで特定した認可情報更新情報１６２２は、認可情報管理テーブル８００内の該当のリフレッシュトークンである。特定方法はステップＳ１１０７の認可情報を特定する方法と同様なため詳細説明を省略する。ステップＳ１６０６で、認可情報管理部４１６が、ステップＳ１６０５で抽出した認可情報更新情報１６２２を送信コマンド生成部４１２に通知する。
【００９０】
ステップＳ１６０７で、送信コマンド生成部４１２が、認可処理差異情報１６２１および認可情報更新情報１６２２に基づいて、更新用送信コマンド１６２３を生成する。更新用送信コマンド１６２３は、ＯＡｕｔｈの仕様に従い、ステップＳ１１０９の送信コマンドを生成する方法と類似するので、詳細説明を省略する。ステップＳ１６０８で、送信コマンド生成部４１２がステップＳ１６０７で生成した更新用送信コマンド１６２３を通信部４０２に通知し、更新用送信コマンド１６２３の送信を依頼する。ステップＳ１６０９、ステップＳ１６１０、ステップ１６１１では、通信部４０２がＷｅｂサーバ１０Ｘに更新用送信コマンド１６２３を送信し、その応答コマンド１４２０を受信して応答コマンド生成部４１３に通知する。
【００９１】
ステップＳ１６１２では、応答コマンド生成部４１３がステップＳ１６１１で受け取った応答コマンドから認可情報を抽出する。それぞれＷｅｂサーバ１０Ｘから受け取った応答コマンドの中の認可情報の記述方法が異なるため、共通応答コマンド１４２２の生成と同様に、予めその応答差異情報を差異情報格納部４１５に保存して、その応答差異情報を利用して共通の応答コマンドを生成する。そして、生成した共通の応答コマンドから同じ方法で更新した認可情報を抽出することができる。
【００９２】
以上説明したように、本実施例により、ネットワークで接続された複数のＷｅｂサーバと連携する情報処理装置において、同じ操作画面で複数のＷｅｂサービスと連携することが可能となる。また、連携するＷｅｂサーバが増加してもそのＷｅｂサービス専用のコンピュータプログラムを追加する必要は無く、プログラムレスで対応可能となる。具体的には、追加するＷｅｂサービスに応じた差異情報および認可情報を差異情報格納部４１５および認可情報格納部４１７に追加することで情報処理装置が新しいＷｅｂサービスに対応することが可能となる。さらに、連携するＷｅｂサーバの通信仕様が変更された場合にも、差異情報を変更するだけで対応可能となるため、プログラムを変更する必要がない。
【００９３】
＜実施例２（Ｗｅｂサーバ）＞
実施例１においては、情報処理装置であるＭＦＰが複数のＷｅｂサーバと連携する場合を説明した。しかし、この場合情報処理装置自身が複数Ｗｅｂサーバと通信するプログラム（送信コマンド・応答コマンド生成処理を含むプログラム）を所有する必要がある。そこで、実施例２では、複数Ｗｅｂサーバと通信するプログラムをＷｅｂサービスとして独立させ、情報処理装置自身はその通信プログラムを所有しなくても複数Ｗｅｂサービスと連携可能とする。
【００９４】
図１７は、実施例２における情報処理システムの全体図である。１７００は、通信サービス提供サーバであって、複数Ｗｅｂサーバと通信する際の通信処理を集約するためのサーバである。１７０１は、通信サービス提供サーバ１７００を利用して複数Ｗｅｂサービスと連携する情報処理装置（ＭＦＰ）である。１７０２は、同じく通信サービス提供サーバ１７００を利用して複数Ｗｅｂサービスと連携する情報処理装置（ＰＣ）である。なお、ＷｅｂサーバＡ１０１、ＷｅｂサーバＢ１０２およびＬＡＮ１１０は、実施例１で説明したものと同様である。
【００９５】
図１８は、本実施例における通信サービス提供サーバ１７００および情報処理装置１７０２のソフトウェア構成を示す図である。１８００は、情報処理装置１７０２内の複数Ｗｅｂサーバと連携するアプリケーションＢである。１８０１は、アプリケーションＢ１８００のＵＩ制御部であって、実施例１のＵＩ制御部４０１と同じ役割を果たす。１８０２は、アプリケーションＢ１８００の通信部であって、通信サービス提供サーバ１７００が提供するＩ／Ｆを介して、それぞれのＷｅｂサーバと通信するソフトウェアモジュールである。１８１０は、通信サービス提供サーバ１７００のサービスＩ／Ｆ部であって、複数のＷｅｂサービスと連携する際の共通通信Ｉ／Ｆを提供するインタフェースである。コマンド変換通信モジュール４１０のＩ／Ｆ部４１１が提供するＩ／Ｆ以外、ユーザログイン際の認証処理のＩ／Ｆも提供する。なお、サービスＩ／Ｆ部１８１０とコマンド変換通信モジュール４１０のＩ／Ｆ部４１１と一緒にしても良い。その他の部分は、すべて図４に示す実施例１のＭＦＰ１００のソフトウェア構成の部分と同じ役割を果たす。
【００９６】
以上の構成により、情報処理装置（ＰＣ）１７０２がコマンド変換通信モジュール４１０を所有することなく複数のＷｅｂサーバと通信することが可能となる。
【００９７】
＜その他の実施例＞
また、本発明の目的は、以下によっても達成できる。まず、前述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給する。次に、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行すればよい。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現されるだけではない。例えば、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。
【図１】
2015052826.tif 000003
【図２】
2015052826.tif 000004
【図３】
2015052826.tif 000005
【図４】
2015052826.tif 000006
【図５】
2015052826.tif 000007
【図６】
2015052826.tif 000008
【図７】
2015052826.tif 000009
【図８】
2015052826.tif 000010
【図９】
2015052826.tif 000011
【図１０】
2015052826.tif 000012
【図１１】
2015052826.tif 000013
【図１２】
2015052826.tif 000014
【図１３】
2015052826.tif 000015
【図１４】
2015052826.tif 000016
【図１５】
2015052826.tif 000017
【図１６】
2015052826.tif 000018
【図１７】
2015052826.tif 000019
【図１８】
2015052826.tif 000020