【事件の表示】
　特願２０１０−５０４３４７「サービス提供システム」拒絶査定不服審判事件〔平成２２年　５月　６日国際公開，ＷＯ２０１０／０５０４０６〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１　手続の経緯
　本願は，２００９年（平成２１年）１０月２３日（優先権主張２００８年（平成２０年）１０月２９日）を国際出願日とする出願であって，平成２２年４月８日付けの拒絶理由の通知に対し，平成２２年６月１８日付けで意見書が提出されるとともに手続補正がなされ，平成２２年７月８日付けの拒絶理由の通知（最後の拒絶理由通知）に対し，平成２２年９月１７日付けで意見書が提出されるとともに手続補正がなされたが，平成２２年１０月８日付けで拒絶査定がなされ，これに対して平成２３年１月１８日付けで審判請求がなされるとともに手続補正がなされ，平成２３年８月２９日付けで審尋がなされ，平成２３年１０月２８日付けで回答書が提出され，平成２４年２月２９日付けの拒絶理由の通知に対し，平成２４年４月２７日付けで意見書が提出されるとともに手続補正がなされたものである。
　
２　本願発明
　本願の請求項１に係る発明（以下「本願発明」という。）は，平成２４年４月２７日付けの手続補正書によって補正された明細書，特許請求の範囲及び図面の記載からみて，特許請求の範囲の請求項１に記載された事項により特定される，次のとおりのものである。
「利用者の端末と，利用者にサービスの提供を行う第１及び第２の提供者の端末とを電子通信回線網で接続し，利用者からの要求に応じて第１又は第２の提供者がサービスの提供を行うサービス提供システムにおいて，
　第１の提供者の端末が利用者の識別記号及び個人情報からなるデータベースを構築し，
　利用者の端末が第１の提供者の端末に利用者の識別記号を用いてログインし，
　利用者の端末が第１の提供者の端末にログイン中に第２の提供者の端末にアクセスし，
　利用者の端末が第２の提供者の端末にアクセスした場合に，第１の提供者の端末から第２の提供者の端末に利用者の識別記号を通知し，
　第２の提供者の端末が第１の提供者の端末から利用者の識別記号の通知を受けた場合に，利用者が第２の提供者に登録しているか否かを問わず，利用者の端末に対してアクセスを許可するとともに，サービスの提供にあたり利用者の個人情報を必要とする場合には，第１の提供者の端末がデータベースから取得した利用者の個人情報の通知を受け，第１の提供者の端末から通知を受けた利用者の個人情報を用いてサービスの提供を行い，
　第１の提供者の端末は，データベースから利用者の個人情報を入手して利用者に対して実際にサービスの提供を行った後であれば，第２の提供者の端末からの要求に応じ，第２の提供者の端末に利用者の個人情報を通知し，第２の提供者の端末は，第１の提供者の端末から利用者の個人情報の通知を受けた場合に利用者が第２の提供者に登録しているか否かを問わず第１の提供者に登録しておいた個人情報を使用し，
　これにより，シングルサインオンの機能に加えて第２の提供者が利用者の個人情報を必要とする場合には，第２の提供者は，第１の提供者が実際にサービスの提供を行った後の利用者の個人情報を使用し，
　一方，直接第２の提供者のサービスを利用した場合には，第２の提供者に登録した個人情報を使用することを特徴とするサービス提供システム。」
　
３　引用例
（１）本願出願前に頒布された，平成１６年度経済産業省受託事業　ＥＣ技術基盤の相互運用性に関する調査研究（取引相手先の属性認証技術等の調査）の報告書である「属性情報プロバイダーの検討　〜個人情報保護に配慮した属性情報活用基盤〜」（財団法人日本情報処理開発協会　電子商取引推進センター，平成１７年（２００５年）２月発行。以下，「引用例」という。）には，次の事項が記載されている。
　なお，以下の記載において，「ＡＰ」，「ＩｄＰ」，「ＤＳ」は，それぞれ「属性情報プロバイダ(Attribute Provider)」，「アイデンティティプロバイダ（Identitiy Provider）」，「ディスカバリサービス（Discovery Service）」の略である（３４頁，表５−１参照）。
　
ａ　「【目的】インターネット上で個人情報を安全・安心・便利に管理し活用するための社会基盤となる属性情報プロバイダーを定義し，サービスを行うにあたり，知っておくべき事柄を総括し，サービスの提供者はもちろんの事，利用者においてもその遵守すべき注意事項を示すことを目的とする。」（２頁１０行〜１４行。空白行を除く。以下同様。）
　
ｂ　「サービスの利用者は属性情報プロバイダーに情報を預け，サービス提供側は必要な属性情報のみを属性情報プロバイダーに要求する。サービス提供者側は一時的に必要なだけの属性情報を預かってサービスを提供するのみであり，個人情報管理の義務の大部分をアウトソースすることができる。」（２頁１６行〜１９行）
　
ｃ　「属性情報プロバイダーの基本的な概念は，利用者とＥビジネスサービスサイトが直接利用者に関する属性を送受信することなく，Ｅビジネスサービスサイトは属性情報プロバイダーを通じて利用者の属性に関する情報を得るというものである。」（４頁６行〜８行）
　
ｄ　「属性情報プロバイダーはオンライン上で他の事業者へ利用者の属性情報を提供する事業者であるが，提供先となる事業者は必ずしも同じグループに属するわけではなく，そのため従来型の事業者とは異なる特徴をもつ。以下に属性情報プロバイダーのモデルを示し，従来型の事業者との相違点について述べる。
　属性情報プロバイダーは大別して２種類の事業モデルが考えられる。
　一つ目のモデルは属性情報プロバイダーが自身で管理している利用者の属性情報を利用してサービスを提供する一方で，利用者の属性情報を他の事業者へ提供するものである（図２−４）。このような属性情報プロバイダーとしては，サービス事業のために既に利用者の属性情報を管理しており，その属性情報自体を提供する新たな事業を行う事業者が考えられる。」（７頁１行〜９行）
　
ｅ　「５．　Liberty Alliance Project
　本章は属性情報プロバイダーを実現する技術の一つとしてLibertyを取り上げ，その属性情報交換の仕組みについて説明する。
　Libertyは利用者のプライバシー保護を重視したアイデンティティ（利用者の識別情報以下，ＩＤと記述）連携，属性情報の連携を可能とする仕組みであり・・・」（３０頁１行〜５行）
　
ｆ　「・・・Libertyの仕様では，これまで２つの開発フエーズを経て，以下のような事項を規定している。
　Phase1では，サービス提供者間で認証結果を流通することにより，顧客アイデンティティの連携とシングルサインオンを実現する，アイデンティティ連携フレームワーク（ＩＤ−ＦＦ）仕様を定めている。・・・
　Phase2では，まず，アイデンティティに基づくＷｅｂサービスの構築／管理のためのプラットフォームとして，サービス提供者間でリソース（例えば消費者の属性情報など）を可能にする枠組みであるＩＤ−ＷＳＦ（Identity Web Service Framework）仕様を定めている。・・・ＩＤ−ＦＦと，ＩＤ−ＷＳＦおよびＩＤ−ＳＩＳの２つは独立した仕様であり，それぞれ単独で実装することも可能である。」（３１頁１６行〜３３行）
　
ｇ　「５．２　Libertyサービスモデル
５．２．１　Libertyのサービス要素
　Libertyは機能毎に分かれた複数のサービス要素が互いに協調することでＩＤ連携や属性情報の提供／取得の機構を実現している。Liberty ＩＤ−ＦＦ，ＩＤ−ＷＳＦで登場するサービス要素のイメージを図５−２に，各サービス要素の役割を表５−１に示す。
　ＩＤ−ＦＦの解説でサービスプロバイダ（ＳＰ）という用語がよく使われるが，本報告書では混乱を避けるためにこの用語を使用せず，代わりにＩＤ連携クライアントと呼ぶことにする。また，ＩＤ−ＷＳＦではＷＳＰ(Web Service Provider）やＷＳＣ（Web Service Consumer）という用語が登場する。これらはＷｅｂサービス上の役割を表すもので，サービスを提供する側をＷＳＰ，サービスを受ける側をＷＳＣと呼ぶものである。ＩＤ−ＷＳＦは利用者の属性情報やサービスに関するフレームワークであり，具体的なサービスを定義しているものではない。・・・本報告書ではＩＤ−ＷＳＦに合わせて利用者の属性情報に関するＩＤ−ＳＩＳ（例えばＩＤ−５１５−ＰＰ）を実装したＷＳＰを属性情報プロバイダ（ＡＰ）と呼び，そのＡＰを利用するクライアントを属性利用クライアントと呼ぶことにする。」（３３頁１行〜３５頁３行）
　
ｈ　「５．２．２　ＩＤ−ＦＦを用いたＩＤ連携・シングルサインオン
　本節ではＩＤ−ＦＦによるＩＤ連携およびシングルサインオンのシーケンスの概要を述べる。
　ＩｄＰとＩＤ連携クライアントによるＩＤ連携の手続きのイメージを図５−４に示す。図５−４の各シーケンスの説明を以下に示す。
●　利用者はＩＤ連携クライアントで認証を受ける。認証はＩＤ連携クライアントが管理する利用者のアカウントにより行う。
●　利用者はＩＤ連携を要求し，ＩＤ連携クライアントはＩｄＰに対しＩＤ連携のリクエストを送信する。
●　利用者はＩｄＰで認証を受ける。認証はＩｄＰが持つ利用者のアカウントにより行う。
●　ＩｄＰは利用者を認証した後，利用者にＩＤ連携クライアントとの間で使用される仮名（ランダムの文字列）を付け，ＩＤ連携クライアントへ認証アサーション（認証したことの証）と共に送信する。
●　ＩＤ連携クライアントはＩｄＰが発行した認証アサーションを受け，自身が持つ利用者のアカウントとＩｄＰが生成した仮名の対応付けを行う。」（３６頁１行〜３７頁１０行）
　
ｉ　「ＩＤ連携の手続きを行った後，利用者はシングルサインオンが可能となる。シングルサインオンのイメージを図５−５に示し，図５−５の各シーケンスを以下に述べる。
●　利用者はＩＤ連携クライアントへ接続する。
●　利用者はまだ認証を受けていないため，ＩＤ連携クライアントはＩｄＰへ利用者をリダイレクションし，認証を要求する。
●　利用者はＩｄＰで認証を受ける。認証はＩｄＰが持つ利用者のアカウントにより行う。
●　ＩｄＰはＩＤ連携のプロセスで決定された利用者の仮名を含めた認証アサーションを発行しＩＤ運携クライアントへ送信する。・・・
●　ＩＤ連携クライアントはＩｄＰより発行された認証アサーションを得て，自身が持つ利用者のアカウントとして認証されたものと判断する。」（３８頁１行〜１１行）
　
ｊ　「５．２．３　ＩＤ−ＷＳＦ／ＩＤ−ＳＩＳを用いた属性連携
　ＩＤ−ＷＳＦは利用者のリソース情報を扱うためのフレームワークであり，サービス仕様であるＩＤ−ＳＩＳと共に実装することで，属性情報連携等を実現することができる。本節ではＩＤ−ＷＳＦ／ＩＤ−ＳＩＳのメカニズムの概要を説明する。ＩＤ−ＳＩＳとしては利用者の属性情報の提供・取得を行うサービスを実現するものとする。
　属性情報を実際に利用する場面を想定した場合，以下の動作シーケンスに分けることができる。
●　ＡＰへの利用者の属性登録
●　ＤＳへのＡＰ登録
●　属性利用クライアントによるＡＰの発見
●　属性利用クライアントによる属性要求とＡＰによる属性提供（利用者の同意確認）
●　属性情報を利用したサービス提供
　各シーケンスを図５−６に示している。図５−６の点線で囲んだ部分がLibertyで規定されているものである。各シーケンスの動作は次のようになる。
●　１．ＡＰへの利用者の属性登録
　利用者の属性登録の方法についてはLibertyでは規定していない。それぞれ独自の方法で実装する必要がある。ＡＰとなる属性情報プロバイダーはその業務の形態により属性登録方法は異なるだろう。例えば，利用者の対面により登録したり，あるいは，Ｗｅｂの入力フオームなどのオンライン上で行うことが考えられる。
●　２．ＤＳへのＡＰ登録
　多数のＡＰが存在するとき，属性利用クライアントが問い合わせるペきＡＰを知ることができるようにＤＳを置くことができる。ＡＰは属性利用クライアントがＤＳから発見できるように，事前にＤＳへ必要な情報を登録しなければならない。
　ＤＳへ登録する情報は属性問い合わせのための接続先（サービスのエンドポイント）や利用者のＩＤが含まれている。利用者のＩＤはプライバシーを保護するため，ＡＰを行う事業者が事業に用いている利用者のＩＤを直接用いるのではなく，属性問い合わせのために使用される仮名が用いられる。
●　３．属性利用クライアントによるＡＰの発見
　属性利用クライアントが必要とする利用者の属性情報について，どのＡＰへ問い合わせるべきか知らない場合には，ＤＳへＡＰ検索の要求を行う。
　ＤＳは検索結果として，ＡＰのエンドポイントなど属性要求に必要な情報を返却する。
●　４．属性利用クライアントによる属性要求とＡＰによる属性提供
　属性利用クライアントはＤＳから得られた情報を元にＡＰへ利用者の属性情報を要求する。
　ＡＰはこの要求に対して利用者へ属性提供に対する意思を確認する。
　利用者の意思確認については，大きく分けて次の２種類が考えられる。
　・属性利用クライアントへの属性提供に対して事前同意を得る
　・属性利用クライアントへの属性要求の度に同意を得る
　前者のケースは，利用者は属性利用クライアントへの属性提供に対し全面的な同意を行う場合で，ＡＰは主にその同意確認を「２．ＤＳへのＡＰ登録」の段階で行う。
　後者のケースでは，このリソース提供の段階において利用者の同意確認を行う。
　どのように同意確認するかについてはLibertyでは規定していない。それぞれ独自に実装する必要がある。
　また，ＡＰ自身が同意確認を行う場合以外にも，属性利用クライアントが行うケースや同意確認を代行する外部サービスであるＩＳを利用するケースもありえる。これらの同意確認のモデルについては５．２．４節で述べている。
　ＡＰは利用者からの同意が得られていることが確認した後，属性利用クライアントへ要求されたリソースを返却する。
●　５．属性情報を利用したサービス提供
　属性利用クライアントとなる事業者はＡＰより取得した属性情報を元にサービスを提供する。」（３８頁１６行〜４０頁３０行）
　
ｋ　「ＩｄＰは属性情報プロバイダーやサービス事業者にＩＤ連携の機能を提供する。またシングルサインオンを行う際，利用者はＩｄＰの認証を受ける。」（４８頁２７行〜２９行）
　
ｌ　「６．３　ユースケース
　本節では，Libertyを用いた属性情報プロバイダーのユースケースについて述べる。このユースケースでは利用者の認証にＩＤ−ＦＦによるＩＤ連携を行うものとする。
６．３．１　登場するサイト
　ユースケースでは以下の３つのサイト（表６−１の事業者）登場する。
　（１）ポータルサイト（本人認証代行事業者に相当）
　（２）旅行代理店サイト（サービス事業者かつ属性情報プロバイダー）
　（３）レンタカーサービスサイト（サービス事業者）
　上記３つのサイトでトラストサークルを形成している。（１）のポータルサイトは，ユーザの認証を行うＩｄＰとして振る舞う。またＤＳもホストする。（２）の旅行代理店サイトは，ユーザが出張する際の宿泊及び航空券等の手配を行う。またユーザの同意に基づき，他のサイトへ属性情報を提供するＡＰとして振る舞う。そして（３）のレンタカーサービスサイトは，出張先でのレンタカーの手配をする。手配に必要な情報は，ユーザの属性情報として旅行代理店サイトから取得する。
・・・
６．３．２　トラストサークルへのシングルサインオン
　ユーザはトラストサークルにシングルサインオンするために，ＩｄＰであるポータルサイトに認証される必要がある。・・・
　一度ＩｄＰに認証されると，ＩｄＰは要求に基づき，他のサイト（本ユースケースでは旅行代理店サイトとレンタカーサービスサイト）に対して，ユーザが認証済みであることを示す認証アサーションを発行する。他のサイトは認証アサーションを検証することにより，ユーザが認証済みであることを確かめる。従ってユーザは，認証情報を各サイトに提出する必要はない。
６．３．３　旅行代理店サイトへのアクセス
　ユーザはトラストサークルにシングルサインオンしているため，旅行代理店サイトには認証情報を送信する必要はない。旅行代理店サイトにおいてユーザは，出張の日程や出張先の情報を提出し，宿泊先，航空券等の手配を行う。いつも利用する旅行代理店サイトであるため，ユーザの氏名，支払いのための情報，そして好みの航空会社といった情報は，ユーザの属性情報として，本サイトに既に登録されている。
・・・
６．３．４　レンタカーサービスサイトへのアクセス
　ユーザはトラストサークルにシングルサインオンしているため，レンタカーサービスサイトには認証情報を送信する必要はない。レンタカーサービスサイトにおいてユーザは，出張先で借りるレンタカーを予約しようとしている。・・・
・・・　
（２）の「トラストサークル内の他のサイトから，必要な情報の取得を許可する」をユーザが選択した場合，レンタカーサービスサイトはトラストサークル内の他のサイトから，予約のために必要な出張に関する属性情報を取得しようと試みる。この場合レンタカーサービスサイトは，・・・トラストサークル内で関連する属性情報を提供できる属性情報プロバイダーを検索し，検索結果に基づき，属性情報プロバイダーに属性情報を要求する。
・・・
６．３．５　属性情報提供のためのユーザとのインタラクション
　レンタカーサービスサイトから属性情報の要求を受け付けた旅行代理店サイトは，属性情報をレンタカーサービスサイトへ提供していいかどうかについて，ユーザが設定しているプライバシーポリシーを確認する。・・・
（１）の「提供を許可する」をユーザが選択した場合，旅行代理店サイトはレンタカーサービスサイトに対して，要求された属性情報を提供する。・・・
・・・
６．３．６　属性情報の受け取りとサービス提供
　レンタカーサービスサイトは，旅行代理店サイトから属性情報を取得し，その情報に基づき，レンタカーの予約手続きを行う。・・・
　ユーザは予約のために必要な，詳細な情報をレンタカーサービスサイトへ，直接入力することなく，レンタカーの予約ができたことになる。」（５２頁２３行〜５７頁２行）
　
ｍ　「ＩＤ−ＦＦ
　Identity Federation Frameworkの略。ＷｅｂシングルサインオンおよびＩＤ連携のためのＨＴＴＰべースのプロトコルを定義するLiberty仕様セットの一部。
ＩＤ−ＷＳＦ
　Liberty Identity Webサービスフレームワーク仕様セット
ＩＤ連携
　トラストサークル内のさまざまなLibertyAllianceエンティティにおいて，主体者の複数アカウントを関連付けたり，バインドすること
ＩｄＰ
　Identitiy Providerの略。主体者のアイデンティティ情報を生成，保管，管理し，主体者の認証をトラストサークル内の他のサービスプロバイダーに提供するLiberty対応のエンティティ。」（６４頁５行〜１６行）
　「シングルサインオン
　アイデンティティプロバイダＡとの間に存在する認証セッションの証明を使用して，アイデンティティプロバイダＢとの新たな認証セッションを作成できること。」（６５頁１８行〜２０行）
　
ｎ　表５−１（３４頁）には，
「アイデンティティプロバイダ（ＩｄＰ：Identity Provider)」の役割として「利用者のアイデンティティ情報を管理し，利用者の認証を行う。認証を行った結果を示す認証アサーションをＳＰに与え，ＩＤ連携を実現する。」，
「ＩＤ連携クライアント」の役割として「ＩｄＰや他のＩＤ連携クライアントとＩＤ連携を行いシングルサインオン等を実現する。」，
「属性利用クライアント」の役割として「ＡＰより利用者の属性情報を取得するクライアント。」，
「属性情報プロバイダー（ＡＰ：Attribute Provider）」の役割として「利用者の属性情報を管理し，利用者の合意の下で属性情報を属性利用クライアントへ提供する。・・・」
と記載されている。
　
（２）上記記載及び図面から，引用例には，次の技術的事項が記載されているということができる。
ア　引用例に記載された技術は，インターネット上で個人情報を安全・安心・便利に管理し活用するための社会基盤となる属性情報プロバイダーを定義することを目的としたものである（記載事項ａ）。
　
イ　引用例には，「属性情報プロバイダー」に関し，「属性情報プロバイダーの基本的な概念は，利用者とＥビジネスサービスサイトが直接利用者に係る属性を送受信することなく，Ｅビジネスサービスサイトは属性情報プロバイダーを通じて利用者の属性に関する情報を得るというものである。」（記載事項ｃ），及び「一つ目のモデルは属性情報プロバイダーが自身で管理している利用者の属性情報を利用してサービスを提供する一方で，利用者の属性情報を他の事業者へ提供するものである（図２−４）。このような属性情報プロバイダーとしては，サービス事業のために既に利用者の属性情報を管理しており，その属性情報自体を提供する新たな事業を行う事業者が考えられる。」（記載事項ｄ）と記載されていること，及び図２−４に示された事項から，「一つ目のモデル」に着目すれば，「利用者の端末と，利用者にサービスの提供を行う属性情報プロバイダーと他のサービス事業者とがインターネット上で接続され，属性情報プロバイダーは，自身で管理している利用者の属性情報に基づいて利用者にサービスを提供するとともに，利用者の属性情報を他のサービス事業者へ提供し，一方，他のサービス事業者は，属性情報プロバイダーから提供された利用者の属性情報に基づいて利用者にサービスを提供するシステム」が記載されている。
　
ウ　「Liberty」は，属性情報プロバイダーを実現する技術であって（記載事項ｅ），シングルサインオンを可能としたこと，及びサービス提供者間，すなわち属性情報プロバイダと属性情報を利用する属性利用クライアントとの間で利用者の属性情報等のリソースの提供・取得が可能であることが記載されている（記載事項ｆ，ｇ）。
　シングルサインオンにおけるシーケンスは，次のとおりである。
　まず，利用者は，ＩｄＰにおいて認証を受けた上で，クライアント（ＩＤ連携クライアント）を連携させるＩＤ連携の手続を行う（記載事項ｈ，図５−４）。
　この後，利用者がＩＤ連携クライアントに接続した場合，利用者がまだ認証を受けていなければ，ＩＤ連携クライアントは利用者をＩｄＰへリダイレクションして認証を要求し，利用者がＩｄＰで認証を受けると，ＩｄＰは認証アサーションを発行してＩＤ運携クライアントへ送信し，ＩＤ連携クライアントはＩｄＰが発行した認証アサーションにより，自身が管理する利用者のアカウントとして認証されたものと判断することにより，シングルサインオンが可能となる（記載事項ｉ，図５−５）。
　なお，「ＩＤ連携クライアント」は，ＩｄＰや他のＩＤ連携クライアントとＩＤ連携を行いシングルサインオンを実現するクライアントであり，「ＩｄＰ」は，利用者のアイデンティティ情報を生成，保管，管理し，利用者の認証を行い，認証結果（認証アサーション）を他のサービスプロバイダーに提供するエンティティである（記載事項ｍ，表５−１）。
　すなわち，「利用者がＩＤ連携クライアントにサービスを要求する場合，ＩｄＰにおいて認証を受けると，ＩＤ連携されたＩＤ連携クライアントは，ＩｄＰが発行した認証アサーションにより自身が管理する利用者のアカウントとして認証されたものと判断し，アクセスを許可することにより，シングルサインオンを可能となる」ことが記載されている。
　ここで，ＩｄＰは属性情報プロバイダーやサービス事業者にＩＤ連携の機能を提供することが記載されていることから（記載事項ｋ），「属性情報プロバイダーと属性利用クライアントは，それぞれＩＤ連携されたＩＤ連携クライアントである」ということができる。
　
エ　利用者の属性情報の提供・取得におけるシーケンスは，次のとおりである。
　利用者は，ＡＰ（属性情報プロバイダー）に，利用者のＩＤや仮名と共に属性情報を登録し，ＡＰは，属性利用クライアントから利用者の属性情報について要求があった場合，利用者に属性提供に対する意思を確認した上で，要求された利用者の属性情報を属性利用クライアントに提供し，属性利用クライアントはＡＰから取得した利用者の属性情報を用いてサービスを提供する（記載事項ｊ，図５−６）。ここで，「ＡＰ」は，「属性情報プロバイダ」であり，利用者の属性情報を管理し，利用者の合意のもとで属性情報を属性利用クライアントへ提供するものである（表５−１）。
　すなわち，「利用者は，属性情報プロバイダーに利用者を特定するための情報と共に属性情報を登録し，属性情報プロバイダーは，属性利用クライアントから利用者の属性情報について要求があった場合，利用者の属性情報を属性利用クライアントへ提供し，属性利用クライアントは属性情報プロバイダーから取得した利用者の属性情報に基づいてサービスを提供すること」が記載されている。
　
オ　引用例の記載事項ｌには，ポータルサイト（本人認証代行事業者），旅行代理店サイト（サービス事業者かつ属性情報プロバイダー）及びレンタカーサービスサイト（サービス事業者）からなるトラストサークルにおいて，上記アないしエに係る構成を適用した，属性情報プロバイダーのユースケースが記載されている。
　
（３）以上のことから，利用者の属性情報を利用する「他のサービス事業者」は，「属性利用クライアント」にほかならないことを考慮すれば，引用例には，次の発明（以下，「引用発明」という。）が記載されていると認められる。
「利用者の端末と，利用者にサービスの提供を行う属性情報プロバイダーと属性利用クライアントとがインターネット上で接続され，属性情報プロバイダーは，自身で管理している利用者の属性情報に基づいて利用者にサービスを提供するとともに，利用者の属性情報を属性利用クライアントへ提供し，一方，属性利用クライアントは，属性情報プロバイダーから提供された利用者の属性情報に基づいて利用者にサービスを提供するシステムであって，
　利用者がＩＤ連携クライアントにサービスを要求する場合，ＩｄＰにおいて認証を受けると，ＩＤ連携されたＩＤ連携クライアントは，ＩｄＰが発行した認証アサーションにより自身が管理する利用者のアカウントとして認証されたものと判断し，アクセスを許可することにより，シングルサインオンを可能となり，
　ここで，属性情報プロバイダーと属性利用クライアントは，それぞれＩＤ連携されたＩＤ連携クライアントであり，
　利用者は，属性情報プロバイダーに利用者を特定するための情報と共に属性情報を登録し，属性情報プロバイダーは，属性利用クライアントから利用者の属性情報について要求があった場合，利用者の属性情報を属性利用クライアントへ提供し，属性利用クライアントは属性情報プロバイダーから取得した利用者の属性情報に基づいてサービスを提供する，
　システム。」
の発明が記載されていると認められる。
　
４　対比
（１）本願発明と引用発明とを対比する。
ア　引用発明は，「利用者の端末と，利用者にサービスの提供を行う属性情報プロバイダーと属性利用クライアントとがインターネット上で接続」されていることから，利用者，属性情報プロバイダー及び属性利用クライアントの端末は，「電子通信回線網で接続」されているということができる。また，「属性情報プロバイダー」及び「属性利用クライアント」は，利用者にサービスを提供するサイトであることから，本願発明の「第１又は第２の提供者」に相当する。
　したがって，本願発明と引用発明とは，「利用者の端末と，利用者にサービスの提供を行う第１及び第２の提供者の端末とを電子通信回線網で接続し，利用者からの要求に応じて第１又は第２の提供者がサービスの提供を行うサービス提供システム」である点で共通する。
　
イ　引用発明における「利用者の属性情報」は，利用者にサービスを提供するための情報であって，利用者の属性情報と利用者を特定するための情報と共に属性情報プロバイダーに登録された情報であるから，本願発明の「個人情報」に相当する。引用発明において，「利用者を特定するための情報」は，利用者と「利用者の属性情報」とを関連づける情報であるから，本願発明の「利用者の識別記号」に相当する。引用発明における「利用者の属性情報」と「利用者を特定するための情報」は，属性情報プロバイダーに登録されていることから，「データベースを構築」していると表現することができ，これらの情報が登録された属性情報プロバイダーは，本願発明の「第１の提供者」に相当する。
　したがって，本願発明と引用発明とは，「第１の提供者の端末が利用者の識別記号及び個人情報からなるデータベースを構築」している点で共通する。
　
ウ　引用発明は，「利用者がＩＤ連携クライアントにサービスを要求する場合，ＩｄＰにおいて認証を受けると，ＩＤ連携されたＩＤ連携クライアントは，ＩｄＰが発行した認証アサーションにより自身が管理する利用者のアカウントとして認証されたものと判断し，アクセスを許可することにより，シングルサインオンを可能」となるものであり，一方，「属性情報プロバイダーと属性利用クライアントは，それぞれＩＤ連携されたＩＤ連携クライアント」であることから，利用者が，ＩＤ連携クライアントである属性情報プロバイダー（本願発明における「第１の提供者」に相当。以下，同様。）に接続し，ＩｄＰにおいて認証を受ければ，利用者は，同じくＩＤ連携クライアントである属性利用クライアント（第２の提供者）において，認証情報を送信することなくアクセスを許可するシングルサインオンが可能となるものである。
　他方，本願発明は，「利用者の端末が第１の提供者の端末に利用者の識別記号を用いてログインし，利用者の端末が第１の提供者の端末にログイン中に第２の提供者の端末にアクセスし，利用者の端末が第２の提供者の端末にアクセスした場合に，第１の提供者の端末から第２の提供者の端末に利用者の識別記号を通知し，第２の提供者の端末が第１の提供者の端末から利用者の識別記号の通知を受けた場合に，利用者が第２の提供者に登録しているか否かを問わず，利用者の端末に対してアクセスを許可する」ものであり，これは「シングルサインオン」にほかならない。
　そうすると，本願発明と引用発明とは，シングルサインオンにおける認証方法は異なるものの，「利用者の端末が第１の提供者の端末からアクセスし，認証を受ければ，利用者の端末が第２の提供者の端末にアクセスした場合に，利用者の端末に対してアクセスを許可する」シングルサインオンの機能を備える点で共通する。
　
エ　引用発明は，「属性情報プロバイダーは，自身で管理している利用者の属性情報に基づいて利用者にサービスを提供するとともに，利用者の属性情報を属性利用クライアントへ提供し，一方，属性利用クライアントは，属性情報プロバイダーから提供された利用者の属性情報に基づいて利用者にサービスを提供するシステム」であって，「利用者は，属性情報プロバイダーに利用者を特定するための情報と共に属性情報を登録し，属性情報プロバイダーは，属性利用クライアントから利用者の属性情報について要求があった場合，利用者の属性情報を属性利用クライアントへ提供し，属性利用クライアントは属性情報プロバイダーから取得した利用者の属性情報に基づいてサービスを提供する」ことから，利用者にサービスを提供するにあたり利用者の属性情報（個人情報）を必要とする場合には，属性情報プロバイダー（第１の提供者）は，属性情報プロバイダーに登録された利用者の属性情報に基づいて利用者にサービスを提供するとともに，属性利用クライアント（第２の提供者）の要求に応じて，属性利用クライアントに利用者の個人情報を提供し，属性利用クライアントは，属性情報プロバイダーから利用者の属性情報の提供を受けた場合に，利用者が属性情報プロバイダーに登録された利用者の属性情報を使用するものであり，ここで，利用者の属性情報（個人情報）は，上記イのとおり，「データベース」に登録されているということができる。
　他方，本願発明は，「サービスの提供にあたり利用者の個人情報を必要とする場合には，第１の提供者の端末がデータベースから取得した利用者の個人情報の通知を受け，第１の提供者の端末から通知を受けた利用者の個人情報を用いてサービスの提供を行い，第１の提供者の端末は，データベースから利用者の個人情報を入手して利用者に対して実際にサービスの提供を行った後であれば，第２の提供者の端末からの要求に応じ，第２の提供者の端末に利用者の個人情報を通知し，第２の提供者の端末は，第１の提供者の端末から利用者の個人情報の通知を受けた場合に利用者が第２の提供者に登録しているか否かを問わず第１の提供者に登録しておいた個人情報を使用」するものである。
　そうすると，本願発明と引用発明とは，「サービスの提供にあたり利用者の個人情報を必要とする場合には，第１の提供者の端末がデータベースから取得した利用者の個人情報の通知を受け，第１の提供者の端末から通知を受けた利用者の個人情報を用いてサービスの提供を行い，第１の提供者の端末は，第２の提供者の端末からの要求に応じ，第２の提供者の端末に利用者の個人情報を通知し，第２の提供者の端末は，第１の提供者の端末から利用者の個人情報の通知を受けた場合に第１の提供者に登録しておいた個人情報を使用」するものである点で共通する。
　
（２）以上のことから，本願発明と引用発明との一致点及び相違点は，次のとおりである。
【一致点】
　利用者の端末と，利用者にサービスの提供を行う第１及び第２の提供者の端末とを電子通信回線網で接続し，利用者からの要求に応じて第１又は第２の提供者がサービスの提供を行うサービス提供システムにおいて，
　第１の提供者の端末が利用者の識別記号及び個人情報からなるデータベースを構築し，
　利用者の端末が第１の提供者の端末からアクセスし，認証を受ければ，利用者の端末が第２の提供者の端末にアクセスした場合に，利用者の端末に対してアクセスを許可するとともに，サービスの提供にあたり利用者の個人情報を必要とする場合には，第１の提供者の端末がデータベースから取得した利用者の個人情報の通知を受け，第１の提供者の端末から通知を受けた利用者の個人情報を用いてサービスの提供を行い，
　第１の提供者の端末は，第２の提供者の端末からの要求に応じ，第２の提供者の端末に利用者の個人情報を通知し，第２の提供者の端末は，第１の提供者の端末から利用者の個人情報の通知を受けた場合に第１の提供者に登録しておいた個人情報を使用する，
シングルサインオンの機能を備えたサービス提供システム。
【相違点１】
　シングルサインオンにおける認証方法が，本願発明は，「利用者の端末が第１の提供者の端末に利用者の識別記号を用いてログインし，利用者の端末が第１の提供者の端末にログイン中に第２の提供者の端末にアクセスし，利用者の端末が第２の提供者の端末にアクセスした場合に，第１の提供者の端末から第２の提供者の端末に利用者の識別記号を通知し，第２の提供者の端末が第１の提供者の端末から利用者の識別記号の通知を受けた場合に，利用者の端末に対してアクセスを許可する」ものであるのに対し，引用発明は，「利用者がＩＤ連携クライアントにサービスを要求する場合，ＩｄＰにおいて認証を受けると，ＩＤ連携されたＩＤ連携クライアントは，ＩｄＰが発行した認証アサーションにより自身が管理する利用者のアカウントとして認証されたものと判断し，アクセスを許可する」ものである点。
【相違点２】
　第１の提供者の端末による，第２の提供者の端末からの要求に応じた，第２の提供者の端末への利用者の個人情報の通知が，本願発明は，「データベースから利用者の個人情報を入手して利用者に対して実際にサービスの提供を行った後」であることを条件としているのに対し，引用発明は，条件が特定されていない点。
【相違点３】
　本願発明は，第２の提供者の端末において，「利用者が第２の提供者に登録しているか否かを問わず」シングルサインオンが行われ，また，第２の提供者の端末において，第１の提供者の端末から利用者の個人情報の通知を受けた場合に，「利用者が第２の提供者に登録しているか否かを問わず」，第１の提供者に登録しておいた個人情報を使用するのに対し，引用発明は，属性利用クライアント（第２の提供者）におけるシングルサインオン，及び属性利用クライアント（第２の提供者）における第１の提供者に登録された個人情報の使用と，利用者が属性利用クライアント（第２の提供者）に登録しているか否かとの関連性について特定されていない点。
【相違点４】
　本願発明は，「シングルサインオンの機能に加えて第２の提供者が利用者の個人情報を必要とする場合には，第２の提供者は，第１の提供者に登録された利用者の個人情報を使用し，一方，直接第２の提供者のサービスを利用した場合には，第２の提供者に登録した個人情報を使用する」のに対し，引用発明は，そのような使用方法について特定されていない点。
　
５　判断
（１）相違点１について
　シングルサインオンに係る技術常識を考慮すれば，相違点１は，実質的には，シングルサインオンにおける認証方法において，本願発明は，第１の提供者の端末，すなわち利用者が最初にアクセスした端末，が利用者を認証し，第２の提供者の端末は，第１の提供者の端末から通知された認証結果に基づいて利用者のアクセスを許可するものであるのに対し，引用発明は，第１の提供者の端末とは別に設けられた認証手段であるＩｄＰが利用者を認証し，第１，第２の提供者の端末は，ＩｄＰから通知された認証結果に基づいて利用者のアクセスを許可するものである点での相違ということができる。
　一方，シングルサインオンにおいて，第１の提供者の端末が利用者を認証し，第２の提供者の端末は，第１の提供者の端末から通知された認証結果に基づいて利用者のアクセスを許可する構成は，例えば，特開２００４−３０２８６９号公報に記載されているように，提供者の端末とは別の認証手段により利用者を認証する構成とともに，周知の技術手段であり，いずれの構成を採用するかは，当業者が適宜選択できる事項である。
　上記特開２００４−３０２８６９号公報には，次の記載がある。
「本発明は、クライアントが複数のサービスを利用する際のアクセス管理技術に関するものであり、特に、一度認証するだけで認証が必要な複数のサービスを利用可能とするシングルサインオン（以下ＳＳＯ）機能に適用可能なアクセス管理技術に関するものである。」（段落【０００１】）
「別の方法として、例えば特許文献２に記載されているように、複数の認証が必要なＷＷＷサーバのうち、一つのＷＷＷサーバにおいて認証を行えば、そのＷＷＷサーバから他のサーバへ認証済み情報が通知される技術がある。この技術では、認証が行われたときに、その旨を他のすべてのＷＷＷサーバへ通知する。」（段落【０００６】。なお，段落【０００９】を参照すれば，「特許文献２」は特開２００２−２８８１３８号公報である。）
「さらに別の方法として、特願２００２−９５７５５号公報に記載されている技術においても、ＳＳＯサーバにおいてクライアント識別情報とそのクライアントの認証情報を一元管理し、ＳＳＯを実現している。」（段落【０００７】。なお，「特願２００２−９５７５５号」は，「特開２００３−２９６２７７号公報」として公開されている。）
　そうすると，引用発明におけるシングルサインオンの認証方法において，ＩｄＰが利用者を認証し，属性利用クライアント（第２の提供者）の端末は，ＩｄＰから通知された認証結果に基づいて利用者のアクセスを許可する構成に換えて，上記周知の技術手段を採用し，属性情報プロバイダー（第１の提供者）の端末が利用者を認証し，属性利用クライアント（第２の提供者）の端末は，前記認証結果に基づいて利用者のアクセスを許可する構成とすることは，当業者が容易に想到し得たことである。
　
（２）相違点２について
　本願発明において，第２の提供者からの要求に応じた，第１の提供者から第２の提供者への利用者の個人情報の通知を，データベースに登録された個人情報を利用して，実際に利用者にサービスの提供を行った後とした点は，当業者が任意に決定できる取り決めであり，当業者が適宜なし得る設計事項にすぎない。なお，利用実績に応じて提供する情報やサービス内容を変更することは，常とう手段である。
　相違点２は，格別のことではない。
　
（３）相違点３，４について
　ネットワークを用いた電子商取引において，利用者がサービス提供者である特定サイトに登録する方法として，特定サイトに直接登録する方法と，引用例に記載されたユースケース（記載事項ｌ参照）のように他のサービス提供者であるポータルサイトを介して登録する方法があること，及び特定の利用者が，特定サイトに，電子商取引上の独立したユーザとして複数の登録を行うことができることは，当業者の技術常識である。
　そうすると，引用発明においても，特段の事情がない限り，利用者が属性利用クライアント（第２の提供者）に登録しているか否かを問わず，シングルサインオンが行われ，また，属性利用クライアント（第２の提供者）の端末において，属性情報プロバイダー（第１の提供者）の端末から利用者の属性情報（個人情報）が提供された場合に，利用者が属性利用クライアント（第２の提供者）に登録しているか否かを問わず，属性情報プロバイダー（第１の提供者）に登録された利用者の属性情報（個人情報）を使用する構成となることは，自明である。
　また，上記のとおり，利用者が，特定サイトに，電子商取引上の独立したユーザとして複数の登録を行った場合，それぞれの登録は独立しているのであるから，登録ごとに利用者の属性情報（個人情報）を登録することができ，サービス提供者は，特段の事情がない限り，利用者が選択した登録方法に応じた属性情報（個人情報）を使用すると考えるのが自然である。
　したがって，引用発明において，ＩＤ連携されたＩＤ連携クライアントとして，シングルサインオンによる認証方法により属性利用クライアント（第２の提供者）にアクセスした場合に，属性利用クライアント（第２の提供者）は，属性情報プロバイダー（第１の提供者）に登録された利用者の属性情報（個人情報）を使用することとなり，一方，利用者が直接属性利用クライアント（第２の提供者）に登録している場合において，利用者が属性利用クライアント（第２の提供者）に直接アクセスした場合には，特段の事情がない限り，第２の提供者に登録された利用者の属性情報（個人情報）を使用することとなることは，当業者にとって自明のことである。
　したがって，相違点３，４は，格別のことではない。
　
（４）そして，これらの相違点を総合的に勘案しても，本願発明の奏する作用効果は，引用発明及び周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本願発明は，引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものである。
　
６　むすび
　以上のとおり，本願の特許請求の範囲の請求項１に記載された発明は，引用例１に記載された発明及び周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法２９条２項の規定により特許を受けることができないから，本願は，拒絶すべきものである。
　よって，結論のとおり審決する。