JP2020204795A - 画像処理装置、画像処理装置の制御方法、及びプログラム - Google Patents

Abstract

【課題】 デバイスに搭載されているＷｅｂブラウザーは、一般的なＰＣやスマートフォンと違って、古い世代のものが使われていたり、適切にバージョンアップがされていなかったりすることが多い。そのような場合、デバイス搭載のＷｅｂブラウザーでユーザー認可を行おうとしても、Ｗｅｂページにアクセスできない事態が生じ得る。サーバー上にインストールされたＷｅｂブラウザーを遠隔操作することでデバイス上からの操作を実現する手段が提案されているが、Ｗｅｂブラウザーを動作させるためのサーバーを用意する必要があり、調達及び運用にコストがかかる。【解決手段】 デバイス上に、認可コードを受け取るためのサーバー機能及び、認可を行うためのＵＲＬ生成機能を有することにより、モバイル端末を経由したユーザー認可を可能とする。そのため、デバイスに搭載されたＷｅｂブラウザーを更新したり、リモート操作するためのサーバーを用意したりする必要がなく、コストを低減できる。【選択図】 図３

Description

本発明は、ユーザー認可の取得を行う画像処理装置の制御方法、プログラムに関する。

ＰＣなどの情報処理装置がネットワーク上のＷｅｂサーバーに接続され、Ｗｅｂサーバー上のＷｅｂアプリケーションにより提供される操作画面を、情報処理装置が備えるＷｅｂブラウザー上に表示することが知られている。

この場合、まず情報処理装置のＷｅｂブラウザーが、Ｗｅｂサーバー上のＷｅｂアプリケーションに対して操作画面を要求（リクエスト）する。そして、Ｗｅｂアプリケーションが情報処理装置からの要求に応えて、Ｗｅｂブラウザーに操作画面を表示させるためのＨＴＭＬデータを情報処理装置に応答（レスポンス）する。情報処理装置のＷｅｂブラウザーは、受信したＨＴＭＬデータを解析し、ＨＴＭＬデータの記述に基づいた操作画面を表示する。

更に、Ｗｅｂブラウザーに表示された操作画面を介してユーザーが指示を入力すると、入力された指示をＷｅｂブラウザーがＷｅｂサーバーに対して通知する。そして、この通知を受けたＷｅｂサーバー上のＷｅｂアプリケーションは、入力された指示に従って処理を実行する。

近年、スキャナやプリンタを備えたＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）と呼ばれる画像処理装置の中にも、上述したようなＷｅｂブラウザーを備えているものがある。そういったＭＦＰでは、ＭＦＰ上のアプリケーションが外部サービスのユーザー認可を取得したい場合に、Ｗｅｂブラウザーを起動して利用を行うことが多い。たとえばスキャンした結果をクラウドのストレージサービスにアップロードするアプリケーションであれば、そのクラウドストレージサービスの認可画面をＷｅｂブラウザーで表示し、ユーザーが認可することでストレージサービスにスキャンデータを保存することができる。しかしながら、デバイスに搭載されているＷｅｂブラウザーは、一般的なＰＣやスマートフォンと違い、古い世代のものが使われていたり、適切にバージョンアップがされていなかったりする。そのような場合、デバイス搭載のＷｅｂブラウザーでユーザー認可を行おうとしても、Ｗｅｂページにアクセスできない事態が生じ得る。

特許文献１には、デバイスにインストールされているＷｅｂブラウザーが古くＷｅｂページが表示できない場合においても、デバイスでＷｅｂページを表示する手段が開示されている。

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

しかしながら、上記の特許文献１の方法では、サーバー上にインストールされたＷｅｂブラウザーを遠隔操作することでデバイス上からの操作を実現するため、Ｗｅｂブラウザーを動作させるためのサーバーを用意する必要があり、調達及び運用にコストがかかる。

上記の課題を解決するために、本発明に係る情報処理装置は、
Ｗｅｂブラウザー機能（３０１）と、Ｗｅｂブラウザー機能を操作するＷｅｂブラウザーサービス（３０２）と、を有する情報処理装置であって、前記Ｗｅｂブラウザーサービス（３０２）は、情報処理装置上のローカルアプリケーション（３０３）からの認可処理依頼を受け付けて認可処理に必要となるＵＲＬを生成するＵＲＬ生成機能（Ｓ４０２）と、ＵＲＬを生成すると前記Ｗｅｂブラウザー機能（３０１）を起動して生成したＵＲＬをモバイル端末（１０３）に提示するＵＲＬ提示機能（Ｓ４０４）と、モバイル端末から認可コードを受け付ける認可コード受付機能（Ｓ４１１）と、認可コードを受け付けると認可コードを前記ローカルアプリケーションに渡して、ローカルアプリケーションを最前面に表示する画面遷移機能（Ｓ４１２、Ｓ４１３）とを有し、前記ＵＲＬ生成機能（Ｓ４０４）は、認可サーバー（１０２）のアドレスと、認可コードの通知先として前記認可コード受付機能（Ｓ４１１）のアドレスを含むＵＲＬを生成することを特徴とする。

本発明に係る情報処理装置によれば、デバイスに搭載された古いＷｅｂブラウザーでユーザー認可を行おうとしてもＷｅｂページにアクセスできない場合においても、モバイル端末を経由してユーザー認可を行うことができる。そのため、デバイスに搭載されたＷｅｂブラウザーを更新したり、リモート操作するためのサーバーを用意したりする必要がなく、コストを低減できる。

本発明の実施形態におけるＭＦＰの接続されるシステムの全体図である。 本発明の実施形態におけるハードウェア構成を示すブロック図である。 本発明の実施形態におけるシステムのソフトウェア構成を示す図である。 本発明の実施形態における処理シーケンスを示す図である。 本発明の実施形態におけるローカルアプリケーションの画面の例を示す図である。 本発明の実施形態におけるＭＦＰ上のＷｅｂブラウザー画面の例を示す図である。 本発明の実施形態におけるモバイル端末上のＷｅｂブラウザー画面の例を示す図である。 本発明の実施形態におけるＷｅｂブラウザーサービスの処理フローを示す図である。 本発明の実施形態におけるＷｅｂブラウザーサービスが生成するＵＲＬの例を示す図である。

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

図１は、本発明の画像処理装置を用いたシステムの構成例である。

本システムはネットワーク１００を介して接続される画像処理装置であるＭＦＰ１０１と、Ｗｅｂサーバー１０２と、モバイル端末１０３から構成される。

ネットワーク１００は各装置間で通信を行うための基盤であって、インターネットに接続されていても良い。ＭＦＰ１０１はＷｅｂブラウザー機能を有すれば、ＭＦＰ（Ｍｕｌｔｉｐｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）に限定されるものではない。Ｗｅｂサーバー１０２は、ネットワーク経由でＭＦＰ１０１と接続されており、Ｗｅｂコンテンツを、ネットワークを介して配信する機能を持っており、ＭＦＰ１０１からのリクエストに応じてＷｅｂコンテンツを提供する。モバイル端末１０３は、スマートフォンに代表される携帯電話や、タブレット、ノートＰＣなど持ち運びができる情報処理端末であって、Ｗｅｂブラウザー機能を有する。

各装置はローカルネットワーク上に存在しても良いし、インターネットを越えて接続されていても良い。

図２は本実施例のＭＦＰ１０１、Ｗｅｂサーバー１０２、モバイル端末１０３のハードウェア構成の一例である。

本発明を制御するＣＰＵ２０１、ＣＰＵ２０１のワークエリアを提供するＲＡＭ２０２、本発明のプログラムや様々な設定を記憶する記憶装置２０３（ＨＤＤやＮＶＲＡＭ等でもよい）が存在する。さらに、ユーザーがコマンドの入力を行うユーザー入力装置２０４、画面表示を行うＵＩ表示装置２０５、他機器とネットワークによる通信を行うネットワーク装置２０６、メインバス２００により構成されている。

尚、本実施例は特に断らない限り、ＭＦＰ１０１、Ｗｅｂサーバー１０２は、ＣＰＵ２０１がメインバス２００を介してＲＡＭ２０２、記憶装置２０３、ユーザー入力装置２０４、ＵＩ表示装置２０５、ネットワーク装置２０６を制御する。また、タッチパネルディスプレイのようにＵＩ表示装置２０５がユーザー入力装置２０４を兼ねても良い。ＭＦＰ１０１はその他にも画像読取装置や画像印刷装置がメインバス２００に接続されていても良い。

図３は本実施例におけるシステムのソフトウェア構成を説明するための図である。図３に示す各機能部は、それぞれのデバイスが有しているＣＰＵ２０１が制御プログラムを実行することにより実現される。ＭＦＰ１０１は、Ｗｅｂブラウザー３０１、Ｗｅｂブラウザーサービス３０２、ローカルアプリ３０３を有する。

Ｗｅｂブラウザー３０１は、任意のサーバーと通信を行うことによってＷｅｂコンテンツを取得、画面に表示するといった機能を有する。本実施例では、Ｗｅｂブラウザーサービス３０２が生成するＱＲコード（登録商標）の画像を表示するために利用する。

Ｗｅｂブラウザーサービス３０２は、ローカルアプリ３０３からの依頼を受けて認可処理に必要となるＵＲＬを生成する。これはＷｅｂサーバー１０２のＷｅｂアプリケーション４０１に対して認可処理を依頼するためのＵＲＬである。このＵＲＬには、Ｗｅｂアプリケーション３１１のＯＡｕｔｈ認可のエンドポイントのアドレスと、結果を通知する宛先としてＷｅｂブラウザーサービス３０２のサーバー機能のアドレスを含む。詳細は図９を用いて後述する。また、Ｗｅｂブラウザーサービス３０２は、ＵＲＬを生成すると、Ｗｅｂブラウザー３０２を起動し、生成したＵＲＬをモバイル端末１０３で読み取れるようにＷｅｂブラウザー３０２上に提示する。具体的にはＵＲＬをＱＲコードに変換して表示することが考えられるが、モバイル端末１０３で読み取ることができれば方法はなんでも良い。

ローカルアプリ３０３は、ＭＦＰ１０１にインストールされた、Ｗｅｂアプリケーション４０１と連携して動作するアプリケーションである。具体的には、ＭＦＰ３０３でスキャンを行い、得られたドキュメントをＷｅｂアプリケーション３１１に保存する、または、Ｗｅｂアプリケーション３１１に保存されているドキュメントを印刷する機能を有する。このときＷｅｂアプリケーション３１１で管理するドキュメントにアクセス（参照、保存）するには、Ｗｅｂアプリケーション３１１におけるユーザー認証を必要とする。そのため、ローカルアプリ３０３は、Ｗｅｂブラウザーサービス３０２を通して、Ｗｅｂブラウザー３０１を起動し、Ｗｅｂアプリケーション３１１に対してユーザー認可のリクエストを行う。このとき前記Ｗｅｂブラウザーサービス３０２は、前述の仕組みに従ってモバイル端末１０３に認可処理を行うためのＵＲＬを提供する。その後、ユーザーがモバイル端末１０３を操作して認可を行うことで、認可コードがＷｅｂブラウザーサービス３０２に通知される。そして、ローカルアプリ３０３は、Ｗｅｂブラウザーサービス３０２を通して認可コードを受け取り、認可コードを用いて、Ｗｅｂサーバー１０２のＯＡｕｔｈ制御部３１２からＯＡｕｔｈで利用するアクセストークンを取得する。ローカルアプリ３０３は、このアクセストークンを用いることでＷｅｂアプリケーション３１１のドキュメントにアクセスすることができる。

Ｗｅｂサーバー１０２は、Ｗｅｂアプリケーション３１１と、ＯＡｕｔｈ制御部３１２を有する。

Ｗｅｂアプリケーション３１１はドキュメントを管理するアプリケーションであり、ＭＦＰ１０１からの要求に従って、ドキュメントを保存したり参照したりする。また、Ｗｅｂアプリケーション３１１はユーザーごとにアクセス制御がされており、利用するには認証を行う必要がある。特に、ローカルアプリ３０３のような外部アプリケーションから利用する場合、ＯＡｕｔｈと呼ばれる権限認可の標準仕様に従って動作することができるようになっている。

ＯＡｕｔｈ制御部３１２は、ＯＡｕｔｈによる権限認可を制御するモジュールであり、Ｗｅｂアプリケーション３１１で管理されているユーザーによる認可により、Ｗｅｂアプリケーション３１１の機能を外部アプリケーションに提供可能とする。

モバイル端末１０３は、Ｗｅｂブラウザー３２１とＵＲＬ読み取り機能３２２を有する。

Ｗｅｂブラウザー３２１は、Ｗｅｂアプリケーション３１１を表示、実行できれば何でも良い。ＵＲＬ読み取り機能３２２は、前記Ｗｅｂブラウザーサービス３０２で提示したＵＲＬを読み取って、Ｗｅｂブラウザー３２１に渡す機能を有する。具体的にはＵＲＬがＱＲコードで提示される場合には、ＱＲコードを読み取って復号し、得られたＵＲＬをＷｅｂブラウザー３２１に渡す。

図４は、本実施例におけるＯＡｕｔｈのアクセストークン取得要求までのシーケンスを示す図である。

ステップＳ４０１では、ローカルアプリ３０３は、Ｗｅｂブラウザーサービス３０２に対して認可処理を依頼する。このとき、Ｗｅｂアプリケーション３１１のＯＡｕｔｈ認可のエンドポイントのアドレスと、ＯＡｕｔｈにおけるＣｌｉｅｎｔＩＤを渡す。

ステップＳ４０２では、Ｗｅｂブラウザーサービス３０２は、前述の通り認可処理のＵＲＬを生成する。このＵＲＬには、前記ステップＳ４０１で受け取ったＷｅｂアプリケーション３１１のＯＡｕｔｈ認可のエンドポイントのアドレスと、結果を通知する宛先としてＷｅｂブラウザーサービス３０２自身のサーバー機能のアドレスを含む。

ステップＳ４０３では、Ｗｅｂブラウザーサービス３０２は、Ｗｅｂブラウザー３０１を起動し、ＭＦＰ１０１のＵＩ表示装置２０５に表示させる。

ステップＳ４０４では、Ｗｅｂブラウザーサービス３０２は、前記ステップＳ４０２で生成したＵＲＬをＱＲコードの画像に変換し、Ｗｅｂブラウザー３０１に表示する。このとき、Ｗｅｂブラウザー３０１にＱＲコードだけではなく、生成したＵＲＬのＷｅｂコンテンツも表示させても良い。

ステップＳ４０５では、ユーザーがモバイル端末１０３を操作することで、モバイル端末１０３は、ＱＲコード読み取り機能３２２を通して前記ステップＳ４０４でＷｅｂブラウザー３０１上に表示されたＱＲコードを読み取る。そしてモバイル端末１０３のＷｅｂブラウザー３２１を起動し、ＱＲコードから復号したＵＲＬを渡す。

ステップＳ４０６では、モバイル端末１０３のＷｅｂブラウザー３２１は、前記ステップＳ４０５で渡されたＵＲＬにリクエストを送信する。

ステップＳ４０７では、Ｗｅｂサーバー１０２のＷｅｂアプリケーション３１１は認可画面を返す。

ステップＳ４０８では、ユーザーが認可画面においてユーザーＩＤとパスワードを入力する。

ステップＳ４０９では、Ｗｅｂブラウザー３２１は、決定ボタン押下、または送信ボタン押下などのユーザー操作に従って、前記ステップＳ４０８で入力された内容をＷｅｂアプリケーション３１１に送信する。

ステップＳ４１０では、Ｗｅｂアプリケーション３１１は、認証が成功すると前記ステップＳ４０６のリクエストに含まれるリダイレクトＵＲＩへのリダイレクト指示と、認可コードを返す。

ステップＳ４１１では、モバイル端末１０２のＷｅｂブラウザー３２１は、前記ステップＳ４１０で受信したリダイレクト指示にしたがって、認可コードをパラメータに含むリクエストをＷｅｂブラウザーサービス３０２に送信する。

ステップＳ４１２では、Ｗｅｂブラウザーサービス３０２は、前記ステップＳ４１１で受け取った認可コードをローカルアプリ３０３に渡す。

ステップＳ４１３では、Ｗｅｂブラウザーサービス３０２は、ローカルアプリ３０３をＭＦＰ１０１のＵＩ表示装置の最前面に表示する。

ステップＳ４１４では、ローカルアプリ３０３は、前記ステップＳ４１２で得られた認可コードを元に、Ｗｅｂサーバー１０２のＯＡｕｔｈ制御部３１２に対してアクセストークンを要求する。

図５は、本実施例におけるローカルアプリ３０３によって表示される画面の例である。この画面にはスキャンデータの送信先を選択するための複数の送信先選択ボタン５０１が含まれている。ユーザーがこのボタンを押下することで、対象となるクラウドストレージが決定し、対象への認可処理の依頼（前記ステップＳ４０１）が開始される。

図６は、本実施例におけるＷｅｂブラウザー３０１によって表示される画面の例である。この画面には前記ステップＳ４０４でＷｅｂブラウザーサービス３０２から表示を指示されたコンテンツとして、ＱＲコード提示部６０１が表示されている。ユーザーがモバイル端末からこのＱＲコードを読み取ることで、モバイルによる認可処理を実現する。

図７は、本実施例におけるモバイル端末１０３のＷｅｂブラウザー３２１に表示される前記ステップＳ４０７で受信した認可画面の例である。この認可画面にはＷｅｂアプリケーション４０１で管理されているユーザーのユーザーＩＤとパスワードを用いて認可を行うための入力フォーム７０１が含まれる。

図８は、本実施例におけるＷｅｂブラウザーサービス３０２の処理フローである。

ステップＳ８０１では、Ｗｅｂブラウザーサービス３０２は、ローカルアプリから認可処理の依頼を受け付ける。このとき、Ｗｅｂアプリケーション３１１のＯＡｕｔｈ認可のエンドポイントのアドレスと、ＯＡｕｔｈにおけるＣｌｉｅｎｔＩＤが渡される。

ステップＳ８０２では、Ｗｅｂブラウザーサービス３０２は、認可処理のためのＵＲＬを生成する。ＵＲＬには、前記ステップＳ８０１で受け取ったＷｅｂアプリケーション３１１のＯＡｕｔｈ認可のエンドポイントのアドレスと、結果を通知する宛先としてＷｅｂブラウザーサービス３０２自身のサーバー機能のアドレスを含む。

ステップＳ８０３では、Ｗｅｂブラウザーサービス３０２は、Ｗｅｂブラウザー３０１を起動し、さらに、前記ステップＳ８０２で生成したＵＲＬからＱＲコードの画像を生成し、Ｗｅｂブラウザー３０１に表示させる。

ステップＳ８０４では、Ｗｅｂブラウザーサービス３０２は、モバイル端末１０３から認可コードを受け付ける。

ステップＳ８０５では、Ｗｅｂブラウザーサービス３０２は、Ｗｅｂブラウザー３０１が前面に表示されているかどうかを確認する。前面に表示されている場合は、ステップＳ８０６に進む。前面に表示されていない場合は、ステップＳ８０７に進む。

ステップＳ８０６では、Ｗｅｂブラウザーサービス３０２は、ローカルアプリ３０３に認可コードを渡し、ローカルアプリを最前面に表示させる。

ステップＳ８０７では、Ｗｅｂブラウザーサービス３０２は、ローカルアプリ３０３にエラーを通知する。これは、処置途中でＷｅｂブラウザー３０１の画面を閉じた場合や、ユーザー操作の間違いやプログラムの間違いから連続で処理された場合にエラーとするためである。

図９は、Ｗｅｂブラウザーサービス３０２が生成するＵＲＬの例である。このＵＲＬには、Ｗｅｂアプリケーション３１１のＯＡｕｔｈ認可のエンドポイントのアドレス９０１と、レスポンスタイプ９０２と、クライアントＩＤ９０３と、リダイレクトＵＲＩ９０４が含まれる。これらはＯＡｕｔｈに必要となるパラメータであり、リダイレクトＵＲＩ以外のパラメータについて何を指定するかは、ローカルアプリ３０３によって予め決められている。リダイレクトＵＲＩ９０４は、認可コードを取得できた場合に認可コードが通知されるＵＲＩであり、Ｗｅｂブラウザーサービス３０２自身のサーバー機能のＵＲＬを指定する。

以上に示す構成により、デバイス搭載の古いＷｅｂブラウザーでユーザー認可を行おうとしても、Ｗｅｂページにアクセスできない場合においても、スマートフォンなどのモバイル端末を経由してユーザー認可を行うことができる。そのため、デバイスに搭載されたＷｅｂブラウザーを更新したり、リモート操作するためのサーバーを用意したりする必要がなく、コストを低減できる。

１００ ネットワーク、１０１ ＭＦＰ、１０２ Ｗｅｂサーバー、
１０３ モバイル端末

Claims (1)

1. Ｗｅｂブラウザー機能（３０１）と、Ｗｅｂブラウザー機能を操作するＷｅｂブラウザーサービス（３０２）と、を有する情報処理装置であって、前記Ｗｅｂブラウザーサービス（３０２）は、情報処理装置上のローカルアプリケーション（３０３）からの認可処理依頼を受け付けて認可処理に必要となるＵＲＬを生成するＵＲＬ生成機能（Ｓ４０２）と、ＵＲＬを生成すると前記Ｗｅｂブラウザー機能（３０１）を起動して生成したＵＲＬをモバイル端末（１０３）に提示するＵＲＬ提示機能（Ｓ４０４）と、モバイル端末から認可コードを受け付ける認可コード受付機能（Ｓ４１１）と、認可コードを受け付けると認可コードを前記ローカルアプリケーションに渡して、ローカルアプリケーションを最前面に表示する画面遷移機能（Ｓ４１２、Ｓ４１３）とを有し、前記ＵＲＬ生成機能（Ｓ４０４）は、認可サーバー（１０２）のアドレスと、認可コードの通知先として前記認可コード受付機能（Ｓ４１１）のアドレスを含むＵＲＬを生成することを特徴とする情報処理装置。