【事件の表示】
　特願２０１０−　３３５５０「情報処理装置、情報処理方法およびプログラム」拒絶査定不服審判事件〔平成２３年　９月　１日出願公開、特開２０１１−１７１９８３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯及び本願発明
　本願は，平成２２年２月１８日の出願であって，平成２６年３月５日付けで拒絶査定がなされたところ，同年６月３日付けで拒絶査定に対する審判請求がなされるとともに手続補正がなされ，その後，当審において，平成２７年４月７日付けで当該手続補正が却下されるとともに拒絶理由が通知されたところ，同年６月１２日付けで手続補正がなされ，さらに，当審において同年７月１３日付けで拒絶理由が通知されたところ，同年８月２５日付けで手続補正がなされたものである。
　本願の請求項１に係る発明（以下「本願発明」という。）は，上記平成２７年８月２５日付けの手続補正により補正された明細書，特許請求の範囲及び図面の記載からみて，その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
「ネットワークを介してデータを保持するサーバと通信する通信部と，
　前記サーバにアクセスするためのユーザの認証情報を記憶する認証情報記憶部と，
　前記認証情報記憶部を一元管理し，前記通信部を制御して，アプリケーションからのリクエストに基づいて，前記リクエストに前記認証情報を付加して前記サーバへ送信させ，
前記サーバ上のユーザ領域へのログインおよびログアウトを制御する制御部と，
を備える，情報処理装置。」
２．引用発明
　当審の拒絶の理由に引用された特開２００５−１１０９８号公報（以下「引用例」という。）には，図面とともに以下の事項が記載されている。
ア．「【００３６】
図２は，本実施の形態を提供するネットワークシステムの構成例を示す図である。図２に示すように，複数のクライアント１１，１２，１３，・・・，複数のサーバ３１，３２，３３，・・・およびプロキシサーバ１００でシステムが構成されている。
【００３７】
クライアント１１，１２，１３，・・・は，ユーザが使用するコンピュータである。クライアント１１，１２，１３，・・・とプロキシサーバ１００との間は，たとえば，ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）で接続される。ユーザは，クライアント１１，１２，１３，・・・を用いて，プロキシサーバ１００に対してログイン（ベーシック（Ｂａｓｉｃ）認証ログイン）を行うことができる。本実施の形態では，各クライアント１１，１２，１３，・・・には，クライアント機能としてＷｅｂブラウザが実装されており，Ｗｅｂブラウザによってサーバ３１，３２，３３，・・・にアクセスするものとする。
【００３８】
サーバ３１，３２，３３，・・・は，クライアント１１，１２，１３，・・・からの要求に応じて所定のサービスを提供するサーバコンピュータである。サーバ３１，３２，３３，・・・とプロキシサーバ１００との間は，ＬＡＮ，高速専用回線，インターネット等で接続される。サーバ３１，３２，３３，・・・には，サーバ機能等が実装され，サーバ機能毎にユーザ認証機能を有している。本実施の形態では，各サーバ３１，３２，３３，・・・には，サーバ機能としてＷｅｂサーバが実装され，ＷｅｂサーバによってクライアントのＷｅｂブラウザに対するコンテンツの提供サービス等を行う。
【００３９】
プロキシサーバ１００は，クライアント１１，１２，１３，・・・の代理でサーバ３１，３２，３３，・・・にアクセスするコンピュータである。プロキシサーバ１００には，複数のログインアルゴリズム（ベーシック認証やフレーム認証）が定義されている。サーバ３１，３２，３３，・・・からユーザ認証が要求された場合，プロキシサーバ１００は要求されたユーザ認証用のログインアルゴリズムを識別し，該当するアルゴリズムでログイン手続きを行うことができる。たとえば，プロキシサーバ１００は，サーバ３１，３２，３３，・・・にアクセスする際，ユーザ認証を要求されると，クライアント１１，１２，１３，・・・に代わってユーザ認証手続きを行い，サーバ３１，３２，３３，・・・にログインする。
【００４０】
このようなシステムにより，ユーザはクライアント（たとえば，クライアント１１）を利用してサーバ３１，３２，３３，・・・にアクセスできる。そして，１つのＷｅｂサーバ（たとえば，サーバ３１）からユーザ認証が要求されると，プロキシサーバ１００からクライアント１１にユーザ認証が要求される。すると，ユーザがクライアント１１を操作し，プロキシサーバ１００に対してベーシック認証ログインを行う。
【００４１】
プロキシサーバ１００は，クライアント１１から送られるユーザ認証情報を，内部に保持するユーザ情報テーブルと照合することでベーシック認証ログインを認め，サーバ３１に対してログインする。その際，プロキシサーバ１００は，サーバ３１の認証方式に合ったアルゴリズムでログイン手続きを行う。
【００４２】
その後，クライアント１１から他のＷｅｂサーバ３２，３３，・・・へのアクセスの際にユーザ認証が要求されると，そのＷｅｂサーバの認証方式に合ったアルゴリズムで，プロキシサーバ１００がログイン手続きを行う。ログイン手続き完了後は，クライアント１１が要求するサービスがＷｅｂサーバにおいて提供され，結果がクライアント１１に渡される。」（７〜８頁）
イ．「【００４３】
図３は，プロキシサーバのハードウェア構成例を示す図である。プロキシサーバ１００は，ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１０１によって装置全体が制御されている。ＣＰＵ１０１には，バス１０７を介してＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１０２，ハードディスクドライブ（ＨＤＤ：Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）１０３，グラフィック処理装置１０４，入力インタフェース１０５，および通信インタフェース１０６が接続されている。
【００４４】
ＲＡＭ１０２には，ＣＰＵ１０１に実行させるＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また，ＲＡＭ１０２には，ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には，ＯＳやアプリケーションプログラムが格納される。
【００４５】
グラフィック処理装置１０４には，モニタ１１が接続されている。グラフィック処理装置１０４は，ＣＰＵ１０１からの命令に従って，画像をモニタ１１の画面に表示させる。入力インタフェース１０５には，キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は，キーボード１２やマウス１３から送られてくる信号を，バス１０７を介してＣＰＵ１０１に送信する。
【００４６】
通信インタフェース１０６は，ネットワーク１０に接続されている。通信インタフェース１０６は，ネットワーク１０を介して，他のコンピュータ（クライアント１１，１２，１３，・・・やサーバ３１，３２，３３，・・・）との間でデータの送受信を行う。
【００４７】
以上のようなハードウェア構成によって，本実施の形態の処理機能を実現することができる。なお，図３には，プロキシサーバ１００のハードウェア構成を示したが，クライアント１１，１２，１３，・・・やサーバ３１，３２，３３，・・・も同様のハードウェア構成で実現することができる。」（８頁）
ウ．「【００４８】
次に，プロキシサーバ１００の機能について具体的に説明する。なお，以下の説明では，クライアント１１からサーバ３１やサーバ３２に対してアクセスする場合を例に採る。
【００４９】
図４は，プロキシサーバの機能を示すブロック図である。なお，図４に示すように，プロキシサーバ１００には，クライアント１１に実装されたＷｅｂブラウザ１１ａとサーバ３１，３２に実装されたＷｅｂサーバ３１ａ，３２ａとの間で通信を行うことができる。
【００５０】
プロキシサーバ１００は，データベース１１０，セッション情報テーブル１２１，タイマ１２２，タイムアウト駆動部１２３，ブラウザ入力受付部１３１，プロキシサーバ認証部１３２，プロキシサーバ認証要求部１３３，通信状態保持部１３４，Ｗｅｂサーバ識別部１３５，Ｗｅｂサーバ要求生成部１３６，Ｗｅｂサーバ通信部１３７，レスポンス分析部１３８，認証処理判定部１３９，ログイン処理命令生成部１４０，コンテンツ変換部１４１，およびブラウザ応答生成部１４２を有している。
【００５１】
データベース１１０には，代理認証に必要なデータが格納されている。データベース１１０の内容は，ユーザ情報テーブル１１１とＷｅｂサーバ情報１１２とに分かれる。
【００５２】
ユーザ情報テーブル１１１は，クライアント１１，１２，１３，・・・を使用するユーザに関する情報が登録されたデータベースである。たとえば，ユーザ情報テーブル１１１には，各ユーザがプロキシサーバ１００にベーシックログインするためのユーザ認証情報や，ユーザがサーバ３１，３２，３３，・・・にログインするためのユーザ認証情報が，ユーザ毎に格納されている。本実施の形態では，ユーザ情報テーブル１１１の内容は，システムの管理者によって予め設定されるものとする。
【００５３】
Ｗｅｂサーバ情報１１２は，代理認証の対象とするＷｅｂサーバに関する情報である。Ｗｅｂサーバ情報１１２は，システムテーブル１１２ａとレスポンス分析・ログイン命令テーブル１１２ｂとに別れている。本実施の形態では，Ｗｅｂサーバ情報１１２の内容は，システムの管理者によって予め設定されるものとする。
【００５４】
システムテーブル１１２ａは，サーバ機能毎にＷｅｂサーバのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）や認証方式が管理されている。
レスポンス分析・ログイン命令テーブル１１２ｂには，Ｗｅｂサーバへのログインに必要な情報が格納されている。
【００５５】
セッション情報テーブル１２１には，クライアントとの間で確立したセッションに関する情報が登録されている。セッションに関する情報には，タイムアウト時刻も含まれる。セッション情報テーブル１２１の内容は，システムの運用中に動的に追加や削除される。」（８〜９頁）
エ．「【０１１７】
図１１は，代理認証処理の手順を示す第３のフローチャートである。以下，図１１に示す処理をステップ番号に沿って説明する。
［ステップＳ４１］プロキシサーバ１００は，Ｗｅｂサーバ３１ａへのアクセスが拒否された場合，セッション情報テーブル１２１を参照し，Ｗｅｂブラウザ１１ａを介してアクセス要求を出したユーザのユーザ名に対応するセッションの有無を判断する。セッションがない場合，処理がステップＳ４２に進められる。セッションがある場合，処理がステップＳ４４に進められる。
【０１１８】
［ステップＳ４２］セッションがない場合，プロキシサーバ認証要求部１３３が，Ｗｅｂサーバ３１ａから受信したクッキーをＷｅｂブラウザ１１ａのプロキシ認証レスポンス（応答内容）に設定する。
【０１１９】
［ステップＳ４３］プロキシサーバ１００は，プロキシ認証レスポンスを生成し，Ｗｅｂブラウザ１１ａに返信する。その後，処理が終了する。
［ステップＳ４４］セッションがある場合，プロキシサーバ１００へのユーザ認証が完了しているため，プロキシサーバ１００は，セッション情報テーブル１２１からユーザ情報（ユーザ名等）を取得する。
【０１２０】
［ステップＳ４５］プロキシサーバ１００は，ユーザ情報テーブル１１１からＷｅｂサーバ３１ａにログインするためのユーザ認証情報を取得する。具体的には，プロキシサーバ１００は，ステップＳ４４で取得したユーザ名に対応付けて設定されているＷｅｂブラウザ３１ａ（システムＩＤで判別する）のユーザ名とパスワードとを取得する。
【０１２１】
［ステップＳ４６］プロキシサーバ１００は，ログインリクエストを生成する。
［ステップＳ４７］プロキシサーバ１００は，システムテーブル１１２ａを参照し，ベーシック認証か否かを判断する。ベーシック認証の場合，処理がステップＳ４８に進められる。ベーシック認証ではない場合，処理がステップＳ４９に進められる。
【０１２２】
［ステップＳ４８］プロキシサーバ１００は，保存してあるブラウザ要求を取り出し  ，ログインリクエストに組み合わせる。
［ステップＳ４９］プロキシサーバ１００は，Ｗｅｂサーバ３１ａへ要求（ログインリクエスト）を送信する。
【０１２３】
［ステップＳ５０］プロキシサーバ１００は，Ｗｅｂサーバ３１ａから応答された処理結果を受信する。
［ステップＳ５１］プロキシサーバ１００は，処理結果の内容を解析し，ログインに成功したか否かを判断する。ログインに成功した場合には，処理がステップＳ５４に進められる。ログインに失敗した場合には，処理がステップＳ５２に進められる。
【０１２４】
［ステップＳ５２］ログインに失敗した場合，プロキシサーバ１００は，エラーメッセージを生成する。
［ステップＳ５３］プロキシサーバ１００は，エラーメッセージを含む例外を発生させ，処理を終了する。
【０１２５】
［ステップＳ５４］プロキシサーバ１００は，成功したログイン処理がベーシック認証か否かを判断する。ベーシック認証の場合，処理がステップＳ３１（図１０参照）に進められる。ベーシック認証では無い場合，処理がステップＳ５５に進められる。
【０１２６】
［ステップＳ５５］プロキシサーバ１００は，通信状態保持部１３４から保存済のブラウザからの要求を取り出す。その後，処理がステップＳ３１（図１０参照）に進められる。」（１６〜１７頁）
オ．「次に，Ｗｅｂブラウザ１１ａによりプロキシサーバ１００にログインし，Ｗｅｂサーバ３１ａ等にアクセスする際の流れを具体的に説明する。以下の例では，Ｗｅｂサーバでベーシック認証を行う場合と，フォーム認証を行う場合とについて説明する。また，Ｗｅｂサーバ３１ａの名称を「ＷｅｂサーバＡ」，Ｗｅｂサーバ３２ａの名称を「ＷｅｂサーバＢ」とする。
【０１３３】
図１３は，Ｗｅｂサーバでベーシック認証を行う場合の処理手順を示す第１のシーケンス図である。図１３は，プロキシサーバ１００にログインしていないＷｅｂブラウザ１１ａからの要求に対して，プロキシ認証レスポンスを返すまでの処理である。以下，図１３に示す処理をステップ番号に沿って説明する。
【０１３４】
［ステップＳ７１］Ｗｅｂブラウザ１１ａは，プロキシサーバ１００に対する最初の要求を送信する。この例では，ＧＥＴ要求「ＧＥＴ（ＵＲＬ＿Ｘ）」を送信している。
【０１３５】
［ステップＳ７２］プロキシサーバ１００では，Ａｕｔｈｏｒｉｚａｔｉｏｎ（Ａｕｔｈｏｒｉｚｅｄヘッダ）の確認が行われる。最初の要求では，Ａｕｔｈｏｒｉｚｅｄヘッダは含まれていない。Ａｕｔｈｏｒｉｚｅｄヘッダが無い場合，認証不要のリクエストであると仮定して処理が進められる。
【０１３６】
［ステップＳ７３］プロキシサーバ１００は，Ｗｅｂサーバ３１ａに要求を送信する。この例では，ＧＥＴ要求「ＧＥＴ（ＵＲＬ＿Ｘ）」を送信している。
［ステップＳ７４］Ｗｅｂサーバ３１ａは，プロキシサーバに対して応答「４０１（Ｕｎａｕｔｈｏｒｉｚｅｄ，ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ）」を返す。この例では，レスポンスコードが４０１の応答が返されている。この応答は，ベーシック認証が未完了であるためにアクセスを拒否したことを示している。
【０１３７】
［ステップＳ７５］プロキシサーバ１００は，レスポンスを解析する。
［ステップＳ７６］プロキシサーバ１００は，セッションの有無を確認する（ここで，プロキシサーバ１００とＷｅｂブラウザ１１ａとの間のセッションをＰＰＳセッションとする）。この段階では，Ｗｅｂブラウザ１１ａからプロキシサーバ１００にログインされていないため，セッションも存在していない。
【０１３８】
この例では，レスポンスコードが４０１であり（ログインを要求するレスポンス），かつＰＰＳセッションが存在しない場合，プロキシサーバ１００へログイン処理が開始される。
【０１３９】
［ステップＳ７７］プロキシサーバ１００は，プロキシ認証レスポンス「Ｕｎａｕｔｈｏｒｉｚｅｄ，ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ」をＷｅｂブラウザ１１ａに送信する。
図１４は，Ｗｅｂサーバでベーシック認証を行う場合の処理手順を示す第２のシーケンス図である。図１４は，Ｗｅｂブラウザ１１ａからプロキシサーバ１００にログインし，Ｗｅｂページを取得するまでの処理である。以下，図１４に示す処理をステップ番号に沿って説明する。
【０１４０】
［ステップＳ８１］Ｗｅｂブラウザ１１ａは，ユーザからのユーザ名とパスワードとの入力を受け付ける。
［ステップＳ８２］Ｗｅｂブラウザ１１ａは，Ａｕｔｈｏｒｉｚｅｄヘッダにユーザ認証情報を含めた要求「ＧＥＴ（ＵＲＬ＿Ｘ，  Ａｕｔｈｏｒｉｚａｔｉｏｎ／ＰＰＳ）」を，プロキシサーバ１００に送信する。
【０１４１】
［ステップＳ８３］プロキシサーバ１００では，Ａｕｔｈｏｒｉｚａｔｉｏｎ（Ａｕｔｈｏｒｉｚｅｄヘッダ）の確認が行われる。このとき，Ａｕｔｈｏｒｉｚｅｄヘッダありと判断される。
［ステップＳ８４］プロキシサーバ１００は，セッション（ＰＰＳセッション）の有無を確認する。この時点では，セッションは存在しない。Ａｕｔｈｏｒｉｚｅｄヘッダがあってもセッションが存在しない場合，未認証であると判断される。
【０１４２】
なお，ステップＳ８３とステップＳ８４との処理は，順番が逆であってもよい。図９に示すフローチャートでは，セッションの確認（ステップＳ１５）の後，Ａｕｔｈｏｒｉｚｅｄヘッダを確認（ステップＳ１６）している。
【０１４３】
［ステップＳ８５］プロキシサーバ１００は，ユーザ名とパスワードとの組を照合（マッチング）する。照合が成功した場合，以下の処理が行われる。
［ステップＳ８６］プロキシサーバ１００は，セッションを生成する。
【０１４４】
［ステップＳ８７］プロキシサーバ１００は，Ｗｅｂサーバ３１ａ（ＳｕｂＳｙｓｔｅｍ）用のユーザ認証情報（認証キー）を取得する。
［ステップＳ８８］プロキシサーバ１００は，Ｗｅｂサーバ３１ａ用のＡｕｔｈｏｒｉｚｅｄヘッダを生成する。
【０１４５】
［ステップＳ８９］プロキシサーバ１００は，Ｗｅｂブラウザ１１ａから送られた要求からクッキー（ＰＰＳＣｏｏｋｉｅ）やプロキシサーバ１００へ認証するためのユーザ認証情報を取り除き，Ｗｅｂサーバ３１ａ用のユーザ認証情報を追加した要求「ＧＥＴ（ＵＲＬ＿Ｘ，Ａｕｔｈｏｒｉｚａｔｉｏｎ／Ｓｕｂ）」を，Ｗｅｂサーバ３１ａに送信する。
【０１４６】
［ステップＳ９０］Ｗｅｂサーバ３１ａは，ユーザ認証情報に基づいてユーザ認証を行う。Ｗｅｂサーバ３１ａは，認証に成功すると，指定されたＷｅｂページ（ＵＲＬ＿Ｘのページ）をプロキシサーバ１００に送信する。なお，この送信のパケットのレスポンスコードは「２００」である。
【０１４７】
［ステップＳ９１］プロキシサーバ１００は，Ｗｅｂサーバ３１ａからの応答（レスポンス）を解析する。
［ステップＳ９２］プロキシサーバ１００は，Ｗｅｂサーバ３１ａから送られたＷｅｂページにプロキシサーバ１００用のクッキー（ＰＰＳＳＣｏｏｋｉｅ）を追加してＷｅｂブラウザ１１ａに送信する。このクッキーでは，プロキシサーバ１００のドメイン名と後方一致するＵＲＬへのアクセスの際に有効となるように設定されている。
【０１４８】
［ステップＳ９３］Ｗｅｂブラウザ１１ａは，受け取ったＷｅｂページを表示すると共に，プロキシサーバ１００から送られたクッキーを保存する。
以上のようにして，Ｗｅｂブラウザ１１ａを使用するユーザは，プロキシサーバ１００へログインするだけで，Ｗｅｂサーバ３１ａへのアクセスが可能となる。」（１８〜１９頁）
カ．「【０２１７】
なお，上記の例では，プロキシサーバが代理認証を行っているが，この機能をクライアントに実装することもできる。
図２３は，代理認証機能を実装したクライアントの概念図である。図２３に示すように，クライアント２００にはブラウザプログラム２１０とプロキシプログラム２２０とが実装される。ブラウザプログラム２１０は，Ｗｅｂブラウザとしてクライアント２００を機能させるためのプログラムである。また，プロキシプログラム２２０は，プロキシサーバ１００の機能をクライアント２００で実現するためのプログラムである。プロキシプログラム２２０は，ユーザ情報テーブル２２１を有している。ユーザ情報テーブル２２１，各サーバ３１，３２，３３に実装されたＷｅｂサーバにログインするためのユーザ認証情報（ユーザ名とパスワード）が登録されている。」（２６頁）
　上記ア．の段落【００３８】等の記載によれば，Ｗｅｂサーバが実装されたサーバ３１は，コンテンツを保持するものであることが理解される。
　上記ア．の段落【００３９】の「プロキシサーバ１００は，サーバ３１，３２，３３，・・・にアクセスする際，ユーザ認証を要求されると，クライアント１１，１２，１３，・・・に代わってユーザ認証手続きを行い，サーバ３１，３２，３３，・・・にログインする。」との記載は，プロキシサーバ１００がサーバ３１へのログインを制御した状態を示すものと解されるところ，プロキシサーバ１００はその制御を行う制御部を備えることが明らかであり，ログインの制御が行われる以上，ログアウトの制御も行われることが明らかである。
　上記イ．の段落【００４６】等の記載及び図３によれば，プロキシサーバ１００は，上記制御部のほか，ネットワーク１０を介してサーバ３１と通信する通信インタフェース１０６を備え，また，上記ウ．の段落【００４８】〜【００５１】等の記載及び図４によれば，プロキシサーバ１００はサーバ３１にアクセスするためのユーザ認証情報を格納するユーザ情報テーブル１１１を備えているところ，上記カ．の，プロキシサーバが代理認証を行う機能をクライアントに実装する旨の記載及び図２３において，そのような実装形態では，制御部，通信インタフェース及びユーザ情報テーブルは，クライアントが備えるものとなることが明らかである。
　上記イ．の段落【００４６】の通信インタフェース１０６が他のコンピュータとの間でデータの送受信を行う旨の記載に関し，データの送受信の際，通信インタフェース１０６の制御が行われること，及び，当該制御等の主体が上記制御部であることが明らかである。そして，この点は，上記オ．の段落【０１４５】の，プロキシサーバ１００がＷｅｂブラウザ１１ａから送られた要求からクッキー等を取り除き，Ｗｅｂサーバ３１ａ用のユーザ認証情報を追加した要求をＷｅｂサーバ３１ａに送信する旨の記載に関しても同様である。また，ここで，Ｗｅｂサーバ３１ａ用のユーザ認証情報を追加した要求の送信は，Ｗｅｂブラウザ１１ａから送られた要求に基づいているということができ，さらに，当該ユーザ認証情報は，上記エ．の段落【０１２０】の記載によれば，ユーザ情報テーブル１１１に格納されたものであることが理解される。
　したがって，上記引用例の記載及び図面並びにこの分野における技術常識を考慮すると，引用例には，
「ネットワークを介してコンテンツを保持するサーバと通信する通信インタフェースと，
　前記サーバにアクセスするためのユーザ認証情報を格納するユーザ情報テーブルと，
　前記通信インタフェースを制御して，Ｗｅｂブラウザからの要求に基づいて，前記要求に前記ユーザ認証情報を追加して前記サーバへ送信させ，前記サーバへのログインおよびログアウトを制御する制御部と，
を備える，クライアント。」
の発明（以下「引用発明」という。）が記載されていると認められる。
３．対比・判断
　本願発明と引用発明とを対比する。
　引用発明の「コンテンツ」，「通信インタフェース」，「ユーザ認証情報」，「格納する」こと，「ユーザ情報テーブル」，「Ｗｅｂブラウザ」，「要求」，「追加」すること，「クライアント」は，それぞれ，本願発明の「データ」，「通信部」，「ユーザの認証情報」，「記憶する」こと，「認証情報記憶部」，「アプリケーション」，「リクエスト」，「付加」すること，「情報処理装置」に相当するといえる。
　また，引用発明の「制御部」と，本願発明の「制御部」とは，下記の相違点１を除き，「前記通信部を制御して，アプリケーションからのリクエストに基づいて，前記リクエストに前記認証情報を付加して前記サーバへ送信させ」るものである点で共通する。
　また，引用発明の「サーバへのログインおよびログアウト」と，本願発明の「サーバ上のユーザ領域へのログインおよびログアウト」とは，下記の相違点２を除き，「サーバへのログインおよびログアウト」という点で一致する。
　したがって，両者は以下の点で一致し，また，相違する。
（一致点）
「ネットワークを介してデータを保持するサーバと通信する通信部と，
　前記サーバにアクセスするためのユーザの認証情報を記憶する認証情報記憶部と，
　前記通信部を制御して，アプリケーションからのリクエストに基づいて，前記リクエストに前記認証情報を付加して前記サーバへ送信させ，
前記サーバへのログインおよびログアウトを制御する制御部と，
を備える，情報処理装置。」
（相違点１）
　本願発明の「制御部」は，「認証情報記憶部を一元管理」するものであるのに対して，引用発明の「制御部」はそれを行うものではない点。
（相違点２）
　「サーバへのログインおよびログアウト」が，本願発明では「サーバ上のユーザ領域への」ものであるのに対し，引用発明ではそのような限定がない点。
　そこで，まず上記相違点１について検討する。
　相違点１に係る「認証情報記憶部を一元管理」するとの記載の技術的意味を，本願明細書の記載を参酌して検討すれば，段落【００４８】に「認証情報ＤＢ１４６に格納された情報は、ＧＷアプリ１００によって一元管理され、ＧＷアプリ以外のクライアント端末１の各アプリケーションからは参照できない形式で保持されている。」との記載があることから，「認証情報記憶部を一元管理」するとは，特定のアプリケーション以外のアプリケーションからは参照できない形式で保持することを意味するものと認められる。
　一方，端末の記憶部において，セキュリティ向上のため，情報を特定のアプリケーション以外のアプリケーションからは参照できない形式で保持することは，例えば，特開２００８−２６３５４８号公報（段落【００５９】−【００６２】，図２等参照。携帯電話機１１のＩＣカードＣにおける耐タンパー性のメモリＣａに復号化鍵２０４を記憶すること，ＩＣカードＣのメモリＣａが特定のアプリケーションでなければアクセスできないことが記載されている。），特開２００７−２７２６１８号公報（段落【００１３】−【００１６】，図１，２等参照。通信端末１１０の固有情報であり，認証用の「鍵１」として使用される電話番号を，記憶部１１２において専用アプリケーションによってのみアクセスできる特定のアドレスに保存することが記載されている。）に示されているように周知技術である。すなわち，上記の技術的意味の解釈を前提とすると，情報の記憶部を一元管理することは周知技術（以下「周知技術１」という。）である。
　そして，引用発明において，セキュリティが向上するように，上記周知技術１を適用して認証情報記憶部を一元管理するものとすることは，当業者が容易に想到し得ることであり，その際，一元管理の動作（認証情報を保持する動作）の主体が「制御部」であることは当然である。
　次に，上記相違点２について検討する。
　ネットワークを介してデータを保持するサーバと通信する通信部を備える情報処理装置において，サーバ上のユーザ領域へのログインおよびログアウトを制御することは，例えば，当審の拒絶の理由に引用された特開２００４−１２６９０８号公報（段落【００２２】−【００４５】，図１−５等参照。ファイル管理サーバ１４上のユーザ領域１８へのログインおよびログアウトを制御することが読み取れる。），特開２００３−２８３４９０号公報（段落【００２４】−【００４０】，図１等参照。サーバ１０４上の個人データ領域へのログインおよびログアウトを制御することが読み取れる。）に示されているように周知技術（以下「周知技術２」という。）であり，引用発明のサーバへのログインおよびログアウトの具体的な態様として当該周知技術２を適用することは，当業者が容易に想到し得ることである。
　そして，本願発明の作用効果も，引用発明及び周知技術１並びに周知技術２から当業者が予測できる程度のものである。
４．結語
　以上のとおり，本願発明は，引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　よって，結論のとおり審決する。