2023-800079

上記当事者間の特許第７１４４６５９号発明「案内システム、その案内システムの認証装置、案内方法、及び、その認証装置のプログラム」の特許無効審判事件について、次のとおり審決する。

結 論 本件審判の請求は、成り立たない。 審判費用は、請求人の負担とする。

理 由 第１．請求の趣旨及び答弁の趣旨 １．請求の趣旨 特許第７１４４６５９号の特許請求の範囲の請求項１乃至５に係る発明についての特許を無効とする。審判費用は被請求人の負担とする、との審決を求める。 ２．答弁の趣旨 「本件審判の請求は成り立たない。審判費用は請求人の負担とする。」との審決を求める。 第２．手続の経緯 １．本件特許の設定登録までの経緯の概略 特許第７１４４６５９号（以下、「本件特許」という。）についての出願は、平成３０年５月３０日に出願したものであって、令和４年９月２１日に設定登録がなされた。 ２．別件異議申立事件の経緯の概略 令和５年３月１７日に、本件特許の請求項１ないし５に係る発明に対して、特許異議の申立てがなされ（異議２０２３－７００２９６号：特許異議申立人 株式会社リンクス）、令和５年６月６日付けで、請求項１ないし５に係る特許を維持するとの決定がなされた。 ３．本件特許無効審判における手続の経緯の概略 本件無効審判における手続の経緯の概略は、次のとおりである。 令和５年１２月１２日： 審判請求書の提出 （以下、「請求書」という。） 令和６年 ３月 ７日： 審判事件答弁書の提出 令和６年 ４月 ４日付け： 答弁書副本の送付通知（弁駁指令） 令和６年 ５月 ７日： 審判事件弁駁書の提出 令和６年 ６月１３日付け： 審理事項通知 令和６年 ７月１６日： 口頭審理陳述要領書（請求人）の提出 （以下、「請求人陳述要領書」という。） 令和６年 ７月１６日： 口頭審理陳述要領書（被請求人）の提出 （以下、「被請求人陳述要領書」という。） 令和６年 ７月３０日： 口頭審理（第１回口頭審理調書） 令和６年 ７月３１日： 上申書（被請求人）の提出 令和６年 ８月１６日： 上申書（請求人）の提出 （以下、「請求人上申書」という。） 令和６年 ８月２０日： 上申書（被請求人）の提出 （以下、「被請求人上申書」という。） 第３．本件特許発明 本件特許の請求項１ないし５に係る発明（以下、「本件特許発明１」ないし「本件特許発明５」という。）は、本件特許の特許請求の範囲の請求項１ないし５に記載された事項によって特定される次のとおりのものである。 なお、本件特許発明１及び２に係る分説、及び、上記分説に対応するＡないしＧの記号は、請求書第２頁ないし第６頁、第９頁に記載のものを援用する。また、上記分説の構成を、構成要件Ａないし構成要件Ｇという。 「【請求項１】 Ａ ユーザを事業者が提供する前記ユーザのためのユーザ用画面に案内する案内システムであって、 前記案内システムは、 Ｂ 前記ユーザが所持し、ネットワークに接続可能な携帯端末と、 Ｃ 前記ネットワークに接続可能な前記事業者の事業者装置と、 Ｄ 前記事業者装置が提供するユーザ情報に基づいて、本人確認するとともに前記携帯端末を前記ユーザ用画面に誘導する、前記ネットワークに接続可能なサービス事業者の認証装置と、を備え、 Ｅ 前記ユーザ情報は、 前記携帯端末の携帯番号と、 前記ユーザ用画面に誘導するユーザ用画面のＵＲＬと、 前記ユーザ本人であるかを確認する確認情報と、を含み、 Ｆ 前記認証装置は、 Ｆ１ 前記携帯番号の利用履歴が条件をクリアしている場合、前記携帯端末宛に、前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報を付加したＳＭＳメールを送信する処理と、 Ｆ２ 前記サイトにアクセスして入力された入力情報と前記確認情報が一致し、本人確認できた場合、前記ユーザ用画面のＵＲＬに基づいて、前記事業者装置が提供するＷｅｂ画面を携帯端末に表示させる指示を行うことで、前記携帯端末を前記ユーザ用画面に誘導する処理と、 を行うことを特徴とする Ａ 案内システム。 【請求項２】 Ｇ 前記確認情報は、前記ユーザ本人であるかを確認するための情報として複数の認証キーを含むことを特徴とする請求項１に記載の案内システム。 【請求項３】 ユーザを事業者が提供する前記ユーザのためのユーザ用画面に案内する案内システムのサービス事業者の認証装置であって、 前記認証装置は、 前記事業者の事業者装置が提供する前記ユーザの所持する携帯端末の携帯番号の利用履歴が条件をクリアしている場合、前記携帯端末宛に、本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報を付加したＳＭＳメールを送信する処理と、 前記サイトにアクセスして入力された入力情報と前記事業者装置が提供する前記ユーザ本人であるかを確認する確認情報が一致し、本人確認できた場合、前記ユーザ用画面に誘導するために前記事業者装置が提供するユーザ用画面のＵＲＬに基づいて、前記事業者装置が提供するＷｅｂ画面を携帯端末に表示させる指示を行うことで、前記携帯端末を前記ユーザ用画面に誘導する処理と、を行うことを特徴とする認証装置。 【請求項４】 ユーザを事業者が提供する前記ユーザのためのユーザ用画面に案内するサービス事業者の認証装置における案内方法であって、 前記サービス事業者の認証装置が、 前記事業者の事業者装置が提供する前記ユーザの所持する携帯端末の携帯番号の利用履歴が条件をクリアしている場合、前記携帯端末宛に、本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報を付加したＳＭＳメールを送信する手順と、 前記サイトにアクセスして入力された入力情報と前記事業者装置が提供する前記ユーザ本人であるかを確認する確認情報が一致し、本人確認できた場合、前記ユーザ用画面に誘導するために前記事業者装置が提供するユーザ用画面のＵＲＬに基づいて、前記事業者装置が提供するＷｅｂ画面を携帯端末に表示させる指示を行うことで、前記携帯端末を前記ユーザ用画面に誘導する手順と、を含むことを特徴とする案内方法。 【請求項５】 ユーザを事業者が提供する前記ユーザのためのユーザ用画面に案内する案内システムのサービス事業者の認証装置のプログラムであって、 前記認証装置に対して、 前記事業者の事業者装置が提供する前記ユーザの所持する携帯端末の携帯番号の利用履歴が条件をクリアしている場合、前記携帯端末宛に、本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報を付加したＳＭＳメールを送信する処理と、 前記サイトにアクセスして入力された入力情報と前記事業者装置が提供する前記ユーザ本人であるかを確認する確認情報が一致し、本人確認できた場合、前記ユーザ用画面に誘導するために前記事業者装置が提供するユーザ用画面のＵＲＬに基づいて、前記事業者装置が提供するＷｅｂ画面を携帯端末に表示させる指示を行うことで、前記携帯端末を前記ユーザ用画面に誘導する処理と、を少なくとも実行させることを特徴とするプログラム。」 第４．無効理由及び証拠方法 請求人が主張する無効理由及び証拠方法は、概略、以下のとおりである。 １．無効理由 （１）無効理由１ 本件特許発明１ないし５は、甲第１号証に記載された発明、及び、甲第２号証ないし甲第６号証に記載された発明、甲第８号証に記載された発明に基づいて、出願前に当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものであり、同法第１２３条第１項第２号に該当し、無効とすべきである。（請求書第８頁、第９頁、第５２頁） （２）無効理由２ 本件特許発明１ないし５は、甲第５号証に記載された発明、及び、甲第１号証ないし甲第４号証、甲第６号証に記載された発明、甲第８号証に記載された発明に基づいて、出願前に当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものであり、同法第１２３条第１項第２号に該当し、無効とすべきである。（請求書第８頁、第９頁、第５２頁） ２．証拠方法 請求人は、請求書に次の甲第１号証ないし甲第８号証を添付して提出し、また、請求人陳述要領書に次の甲第９号証ないし甲第１３号証を添付して提出した。（以下、甲第１号証ないし甲第１３号証を「甲１」ないし「甲１３」という。） 甲第１号証：特開２０１７－７３６７１号公報 甲第２号証：特開２０１５－６０４９０号公報 甲第３号証：特開２０１３－１０２４１４号公報 甲第４号証：特開２０１２－２１２３６８号公報 甲第５号証：特開２０１８－２６０５７号公報 甲第６号証：〔SMAPS〕 事業者ポータルサイトSMS メニュー操作ガイド 第2.0 版 甲第７号証：証明書 甲第８号証：特開２００５－７８１７９号公報 甲第９号証：甲第６号証のＰＤＦファイルにおける文書のプロパティ概要 甲第１０号証：甲第６号証の元のＰＤＦファイルにおける文書のプロパティ概要 甲第１１号証：特開２００３－５８１９０号公報 甲第１２号証：特開２００４－２６５３９５号公報 甲第１３号証：「産業競争力強化法に基づく新事業活動計画を認定しました（METI_経済産業省）」との、経済産業省のＨＰ記載。 第５．当審の判断 １．甲号証の記載事項 （１）甲第１号証 ア．甲１の記載事項 甲１には、図面とともに次の事項が記載されている。（下線部については当審で付した。以下、同様である。） 「 【０００１】 本発明は、携帯端末のショートメッセージサービス（以下、「ＳＭＳ」という。）を利用した商品の決済方法、携帯端末のショートメッセージサービスを利用した商品の提供方法、及び当該方法に用いられる管理システム及び連絡システムに関する。 …中略… 【０００９】 本発明は、ＳＭＳを利用して、請求書を送付して決済したり、商品を提供したり等を携帯端末で行うことが可能であるとともに、その決済や商品提供の環境を柔軟に変更することが可能な管理システム及び連絡システムを提供することを目的とする。 …中略… 【００２０】 図１は、本発明における管理システム及び連絡システム１を含む全体構成を示す図である。本発明を含む全体構成は、事業者サーバ１０，１１、管理サーバ（管理システム）２０、キャリア３０，３１、携帯端末４０，４１を備える。連絡システム１は、事業者サーバ１０，１１、管理サーバ２０を含んで構成されている。事業者サーバ１０，１１は各事業者のサーバであり、普通は事業者が管理している。管理サーバ２０は、本発明に係る管理システムであって管理者のサーバであり、複数の事業者サーバ１０，１１と接続されている。 【００２１】 管理サーバ２０は、各キャリア３０，３１，・・・を介して携帯端末４０と接続される。また、管理サーバ２０は複数の事業者サーバ１０，１１，・・・に接続されている。事業者サーバ１０，１１，・・・と管理サーバ２０、キャリア３０，３１，・・・の間は専用回線、又はセキュリティを確保したうえで、インターネット回線で接続される。また、キャリア３０と携帯端末４０の間、キャリア３１と携帯端末４１の間は通常の携帯電話回線とネット用回線が用いられる。ネット用回線はキャリア３０，３１を介してインターネットに接続される回線である。 【００２２】 事業者サーバ１０，１１，・・・は、事業者が有するサーバである。事業者はガスや水道、電気等の検針を行って料金を請求する事業者でもよいし、商品の販売等を行う事業者であっても良い。主に想定される事業者としては、携帯端末４０，４１の所有者に請求や決済等を行う事業者であるが、それ以外であってもよい。料金を請求する事業者である場合、管理サーバ２０は、事業者サーバ１０，１１，・・・からの請求データを受けてＳＭＳに変換し、キャリア３０，３１を解して携帯端末４０，４１に送信する。携帯端末４０は、ＳＭＳの受信が可能な機器（携帯電話、スマートフォン等）であり、キャリア３０との間は携帯電話回線とネット用回線で接続される。携帯端末４１も同様にキャリア３１との間を携帯電話回線とネット用回線で接続される。また、キャリア３０とキャリア３１の間には携帯電話回線が設けられ、異なったキャリア３０，３１を利用している携帯端末４０と携帯端末４１の間で通話とＳＭＳが可能であるように構成されている。 【００２３】 以下、ガス事業者がガス料金を請求する実施例を説明する。 図２は、事業者サーバ１０に記憶される請求データを説明する図である。ＳＭＳデータである請求データは、ガス事業者がその顧客に対してＳＭＳを利用して料金を請求するためのデータであり、ガス事業者の事業者サーバ１０から管理サーバ２０に送信される。請求データは、「１．事業者ＩＤ」、「２．携帯番号」、「３．ＳＭＳ本文」、「４．認証情報」、「５．品名」、「６．使用量」、「７．請求金額」、「８．決済手段」、「９．送信日時」、「１０．ＵＲＬアクセス条件」、及び「１１．備考」を有している。「１．事業者ＩＤ」は、各事業者を特定する各事業者に固有のＩＤである。「２．携帯番号」は、ＳＭＳ本文を送付する宛先となる請求先の携帯端末の電話番号（以下、「携帯番号」という。）である。「３．ＳＭＳ本文」は、例えば、「〈○○ガスより使用量等のお知らせ〉ご利用ありがとうございます。下記ＵＲＬにて使用量をご確認ください。」というような、ＳＭＳで送ることができる長さの文章である。「４．認証情報」は、ＳＭＳで送ったＵＲＬに携帯端末から接続した際に暗証番号入力を求める場合の暗証番号であるが、接続の際に自動で認証を行う場合の認証のための情報であってもよい。「５．品名」は、本実施例ではガスの料金請求を目的とした例であるため、ガスである。「６．使用量」は、本実施例では、ガスの使用量である。「７．請求金額」は、事業者が顧客に請求する金額である。「８．決済手段」は、決済に用いることができる決済手段を示し、コンビニの店頭支払い、クレジットカード支払い、銀行振り込みによる支払いを選択可能である等の情報である。「９．送信日時」は、ＳＭＳを送信する日時である。この「９．送信日時」は日時だけでなく、「即時」として、管理サーバ２０での処理が終了次第、携帯端末４０，４１にＳＭＳで送信するように設定することもできる。 …中略… 【００３２】 図４は、固有ＵＲＬの生成処理を示すフローチャートである。本実施例では、まず、ランダム値生成関数により、半角アルファベットの大文字と小文字、半角数字からなるランダムな８桁の文字列を作成する（ステップＳ１）。次に、管理サーバ２０で既に他のシステムＩＤと関連付けられて記憶されている固有文字列が存在しているかを確認し、存在している場合にはもう一度生成し直す（ステップＳ２）。存在していない場合には固有文字列として、システムＩＤに関連付けて管理請求データとして記憶する（ステップＳ３）。 そして、既定ＵＲＬの後ろに固有文字列を付加して固有ＵＲＬを生成し（ステップＳ４）、ＳＭＳで送信する文書に使用する。 …中略… 【００４２】 図６は、本発明に関する全体のフローを示す図である。 事業者は請求データを作成して（ステップＳ１１）、事業者サーバ１０，１１に記憶する。そして、事業者サーバ１０，１１はＳＭＳデータである請求データを管理サーバ２０に送信する（ステップＳ１２）。管理サーバ２０はＳＭＳデータ受信手段で請求データを受信すると、送信する個々のＳＭＳについてシステムＩＤを付与し、受信プルーフとして事業者サーバ１０，１１に返信する（ステップＳ１３）。また管理サーバ２０は、請求データ中の事業者ＩＤから対応する既定ＵＲＬを選択し、システムＩＤと関連付けて管理請求データとして記憶するとともに、前述のように固有文字列を生成し、システムＩＤと関連付けて管理請求データとして記憶する（ステップＳ１４）。 【００４３】 管理サーバ２０は管理請求データの送信日時の情報に従い送信するタイミングになったら、ＳＭＳ本文と固有ＵＲＬからなるＳＭＳ文書をＳＭＳ送信手段により送信する。この送信はＳＭＳによる送信である。その際に、管理サーバ２０は請求データ中の携帯番号に向けて適当なキャリア３０へ呼設定メッセージを送信する、すなわち、発呼し（ステップＳ１５）、切断メッセージ等の返信を受ける（ステップＳ１６）。管理サーバ２０は切断メッセージ等から携帯端末４０が接続されるキャリア３０を特定してキャリア情報とする（ステップＳ１７）。そのキャリア情報に従って携帯端末４０が接続されるキャリア３０に向けてＳＭＳ文書を送信する（ステップＳ１８）。キャリア３０は、携帯端末４０へ携帯電話回線を介してＳＭＳ文書を送信する（ステップＳ１９）。 【００４４】 図７は、ＳＭＳ文書を受信したときの携帯端末４０の表示の例を示す図である。ＳＭＳ文書は、ＳＭＳ本文として、「〈○○ガスより使用量等のお知らせ〉ご利用ありがとうございます。下記ＵＲＬにて使用量をご確認ください。」と表示され、その下に固有ＵＲＬが「https://smss.jp/ag/********」と表示される。 【００４５】 ＳＭＳ文書を見た携帯端末４０の所有者が、確認のために固有ＵＲＬに触れるＵＲＬ選択操作をすると（ステップＳ２０）、携帯端末４０はネット用回線を介して固有ＵＲＬにアクセスしようとする（ステップＳ２１）。キャリア３０から管理サーバ２０へはインターネットを介して固有ＵＲＬが送られる。管理サーバ２０はＵＲＬアクセス条件チェック（ステップＳ２２）を行う。 【００４６】 図８は、ＵＲＬアクセス条件チェック（ステップＳ２２）を示すフローチャートである。管理サーバ２０は、図８に示すように固有ＵＲＬから固有文字列を読み取り、データベース内に紐づいたシステムＩＤが存在するか確認する（ステップＳ２２－１）。紐づいたシステムＩＤが存在する場合は、固有文字列は複数のシステムＩＤには紐づいていることはないため、１つのシステムＩＤが特定される。そして更に図５のＵＲＬアクセス条件格納テーブルによりＵＲＬアクセス条件をチェックする。もしもＵＲＬアクセス条件に設定されている「１．期限日時」を過ぎていたり、「２．決済完了情報」や「３．請求猶予情報」があったりした場合には、ＵＲＬアクセス手段により通常と異なるＵＲＬにアクセスして、携帯端末４０にアクセスできない旨の表示がなされる（ステップＳ２２－２）。 【００４７】 この際の表示は、ＵＲＬアクセス条件を満たさなかった条件によりアクセスするＵＲＬを変えて、表示を変えてもよい。例えば、期限日時を過ぎている場合には「ＵＲＬアクセス期限を過ぎています。○○○までご連絡ください。」と携帯端末４０に表示してもよいし、決済完了情報がある場合には「既にお支払いいただいております。ありがとうございました。」と表示してもよい。また、請求猶予であれば「今回の請求は事情により猶予されています。本件については後日連絡いたします。」と表示してもよい。 【００４８】 ＵＲＬアクセス条件を満たしている場合には、ＵＲＬアクセス手段により通常のＵＲＬにアクセスして、ネット用回線を介して携帯端末４０にログイン画面を表示する（ステップＳ２２－３）。ここで認証コードを入力すると（ステップＳ２３）、ネット用回線を介して管理サーバ２０へ送られ（ステップＳ２４）、管理サーバ２０は管理請求データの認証情報と認証コードを照合して確認する（ステップＳ２５）。認証されると、管理サーバ２０に記憶された管理請求データの「６．使用量」、「７．請求金額」、「８．決済手段」、「１１．備考」等からお知らせ画面の内容を生成し、ネット用回線を介して携帯端末４０に送信して（ステップＳ２６）、携帯端末４０はお知らせ画面表示を行う（ステップＳ２７）。 【００４９】 図９は、携帯端末４０のお知らせ画面表示を示す図である。この例ではガス使用量と請求額等が表示され、決済手段として「コンビニの店頭で支払う」、「クレジットカードで支払う」、「銀行振り込みで支払う」の３つの支払い方法から選択ができるようになっている。支払い手段としてどのようなものを選択可能に表示させるかは「８．決済手段」の設定により変更できる。 【００５０】 上記の実施例では、品名、使用量、請求金額、決済手段等を管理サーバ２０で管理し、これらから、お知らせ画面を生成してＵＲＬを付与し、管理サーバ２０で記憶しているが、お知らせ画面等を事業者サーバ１０で記憶してもよい。その場合には、お知らせ画面等のＵＲＬを管理サーバ２０の管理請求データとして記憶し、固有ＵＲＬへのアクセスから事業者サーバ１０で記憶したお知らせ画面等のＵＲＬへ移送する。」 「【図１】 ［図：0001420007000001.jpg］ 【図６】 ［図：0001420007000002.jpg］ 」 イ．甲１発明 上記アの特に下線部に着目すると、甲１には、次の発明（以下、「甲１発明」という。）が記載されていると認められる。 「連絡システム１および携帯端末４０であって、 連絡システム１は、事業者サーバ１０、１１、管理サーバ２０を含み、事業者サーバ１０、１１は各事業者のサーバであって、普通は事業者が管理しており、 管理サーバ２０は、管理者のサーバであり、 管理サーバ２０は、各キャリア３０、３１、・・・を介して携帯端末４０と接続され、管理サーバ２０は複数の事業者サーバ１０、１１、・・・に接続されており、事業者サーバ１０、１１、・・・と管理サーバ２０、キャリア３０、３１、・・・の間は専用回線、又はセキュリティを確保したうえで、インターネット回線で接続され、キャリア３０と携帯端末４０の間、キャリア３１と携帯端末４１の間は通常の携帯電話回線とネット用回線が用いられ、 携帯端末４０は、ＳＭＳの受信が可能な機器（携帯電話、スマートフォン等）であり、 ガス事業者がガス料金を請求する実施例において、 ＳＭＳデータである請求データは、ガス事業者がその顧客に対してＳＭＳを利用して料金を請求するためのデータであり、ガス事業者の事業者サーバ１０から管理サーバ２０に送信され、 請求データは、「１．事業者ＩＤ」、「２．携帯番号」、「３．ＳＭＳ本文」、「４．認証情報」、「５．品名」、「６．使用量」、「７．請求金額」、「８．決済手段」、「９．送信日時」、「１０．ＵＲＬアクセス条件」、及び「１１．備考」を有し、「２．携帯番号」は、ＳＭＳ本文を送付する宛先となる請求先の携帯端末の電話番号（以下、「携帯番号」という。）であり、「３．ＳＭＳ本文」は、例えば、「＜○○ガスより使用量等のお知らせ＞ご利用ありがとうございます。下記ＵＲＬにて使用量をご確認ください。」というような、ＳＭＳで送ることができる長さの文章であり、「４．認証情報」は、ＳＭＳで送ったＵＲＬに携帯端末から接続した際に暗証番号入力を求める場合の暗証番号であり、 固有ＵＲＬの生成処理は、まず、ランダム値生成関数により、半角アルファベットの大文字と小文字、半角数字からなるランダムな８桁の文字列を作成し固有文字列として、システムＩＤに関連付けて管理請求データとして記憶しそして、既定ＵＲＬの後ろに固有文字列を付加して固有ＵＲＬを生成し、 事業者は請求データを作成して、事業者サーバ１０、１１に記憶し、事業者サーバ１０、１１はＳＭＳデータである請求データを管理サーバ２０に送信し、 管理サーバ２０はＳＭＳデータ受信手段で請求データを受信すると、送信する個々のＳＭＳについてシステムＩＤを付与し、受信プルーフとして事業者サーバ１０、１１に返信し、また、請求データ中の事業者ＩＤから対応する既定ＵＲＬを選択し、システムＩＤと関連付けて管理請求データとして記憶するとともに、前述のように固有文字列を生成し、システムＩＤと関連付けて管理請求データとして記憶し、 管理サーバ２０は管理請求データの送信日時の情報に従い送信するタイミングになったら、ＳＭＳ本文と固有ＵＲＬからなるＳＭＳ文書をＳＭＳ送信手段により送信し、この送信はＳＭＳによる送信であり、その際に、管理サーバ２０は請求データ中の携帯番号に向けて適当なキャリア３０へ呼設定メッセージを送信する、すなわち、発呼し、切断メッセージ等の返信を受け、切断メッセージ等から携帯端末４０が接続されるキャリア３０を特定してキャリア情報とし、そのキャリア情報に従って携帯端末４０が接続されるキャリア３０に向けてＳＭＳ文書を送信し、 キャリア３０は、携帯端末４０へ携帯電話回線を介してＳＭＳ文書を送信し、 ＳＭＳ文書を見た携帯端末４０の所有者が、確認のために固有ＵＲＬに触れるＵＲＬ選択操作をすると、携帯端末４０はネット用回線を介して固有ＵＲＬにアクセスしようとし、キャリア３０から管理サーバ２０へはインターネットを介して固有ＵＲＬが送られ、 管理サーバ２０は、ＵＲＬアクセス条件チェックを行い、ＵＲＬアクセス条件を満たしている場合には、通常のＵＲＬにアクセスして、ネット用回線を介して携帯端末４０にログイン画面を表示し、ここで認証コードを入力すると、ネット用回線を介して管理サーバ２０へ送られ、 管理サーバ２０は管理請求データの認証情報と認証コードを照合して確認し、認証されると、管理サーバ２０に記憶された管理請求データの「６．使用量」、「７．請求金額」、「８．決済手段」、「１１．備考」等からお知らせ画面の内容を生成し、ネット用回線を介して携帯端末４０に送信して、携帯端末４０はお知らせ画面表示を行う、 連絡システム１および携帯端末４０。」 （２）甲第２号証 ア．甲２の記載事項 甲２には、次の事項が記載されている。 「【０００１】 本発明は、利用者にＵＲＬ（Uniform Resource Locator）を含むショートメッセージを配信するＳＭＳ（Short Message Service）配信装置、および方法、ならびにプログラムに関する。 …中略… 【課題を解決するための手段】 【０００６】 上記した課題を解決するために本発明は、自動発呼により得られる応答情報から指定の電話番号の使用状況を判定し、前記判定した使用状況に基づき利用者端末に対し作成したショートメッセージを配信するＳＭＳ配信装置であって、前記ショートメッセージを配信可と判定された前記利用者端末に対し、利用者を特定する識別情報が付加されたＵＲＬを含む前記ショートメッセージを前記指定の電話番号に一括送信し、前記ＵＲＬにリンクしたアンケート回答画面に誘導する制御部、を備えたことを特徴とする。 …中略… 【００１７】 図１に示すように、本実施形態のＳＭＳ配信装置１０には、例えば、ＰＣ（Personal Computer）等からなるメッセージ作成端末７０がＬＡＮ６０（Local Area Network）経由で接続される。本実施形態のＳＭＳ配信装置１０は、自立型電話番号調査装置としての機能も合わせ持ち、例えば、国内に存在する固定電話や携帯電話等、電話機４０の全ての電話番号に対して相手方の電話機を鳴らすことなく発信し、指定の電話番号が、「現在使用されている（有効）、未使用になった（新規無効）、以前から未使用である（無効）、移転先電話番号を案内（移転）、都合取り消し案内中である（都合取り消し）」等を定期的に調査して電話番号履歴情報を生成し、後述するＤＢ（Data Base）上に蓄積する。 …中略… 【００２０】 具体的に、本実施形態のＳＭＳ配信装置１０は、電話番号を発信したときにＩＳＤＮ（Integrated Service Digital Network）網２０に接続される図示省略した交換機から返信される理由識別情報を所定期間だけ収集して上記したＤＢを構築する。ＳＭＳ配信装置１０は、このＤＢを参照することにより、指定の電話番号の使用状況の変化を調べ、ここで判定された使用状況が「有効」と判定された場合、その電話番号を宛先として利用者端末５０に作成したメッセージを送信し、移転案内中であると判定された場合、案内された移転先電話番号を宛先として利用者端末５０に作成したショートメッセージを送信する。 【００２１】 なお、ここで作成されるショートメッセージには、利用者を特定する暗号化された識別情報を含むＵＲＬが埋め込まれており、利用者端末５０側で、受信したショートメッセージに埋め込まれたＵＲＬをクリックすることにより、広告画面、あるいはその広告に対するアンケート回答画面を含む企業のホームページに誘導される。アンケート集計サーバ８０は、ＳＭＳ配信装置１０を介して利用者によりアンケート回答画面に書き込まれた情報を取り込み、当該書き込まれた情報をデータマイニング等により分析して利用者毎の非匿名情報を抽出する。したがって、暗号化された識別情報等の情報識別により利用者端末５０からアクセスされた段階で顧客管理されているユーザを特定できる。もちろん、顧客情報登録時に本人に関する住所、性別、年齢等の属性情報が登録されていることはいうまでもない。したがって、一般的に採用されているアクセス時でのＩＤやパスワードを不要とする仕組み作りが可能である。このように、煩わしく、管理も難しいＩＤやパスワードによらず本人を確認し第三者の妨害を回避できるアンケート収集が可能である。 また、アンケート集計サーバ８０は、回答結果を集計し、確認できる確認画面を提供する。アンケート集計サーバ８０は、アンケートのファイル名、送信件数、エラー件数、アクセス件数、返信件数と各設問に対する評価項目等を確認画面として表示する。」 イ．甲２発明 上記アの特に下線部に着目すると、甲２には、次の発明（以下、「甲２発明」という。）が記載されていると認められる。 「携帯電話の電話番号の使用状況を判定し、判定した使用状況に基づき利用者端末に対しＵＲＬを含むショートメッセージを配信するＳＭＳ配信装置。」 （３）甲第３号証 ア．甲３の記載事項 甲３には、次の事項が記載されている。 「【０００２】 簡易メール（ＳＭＳ：Short Message Service）は、携帯電話やＰＨＳ（Personal Handy Phone）同士で短文を送受信するサービスとして普及している。これまでの簡易メールは、キャリアに依存して送受信が行なわれていたが、平成２３年７月１３日（新聞報道）から異キャリア間でも送受信が可能になった。 【０００３】 簡易メールは、加入者の携帯電話番号を宛先に作成したメッセージを送受信する特徴を有する。このため、相手側の電話番号が変更になり、あるいは解約した場合には送受信ができない。また、相手側が解約して今までに使用していた電話番号を継続して使用しない場合、各キャリアは、６カ月間（固定電話番号は３カ月間）経過すると、今まで使用していた電話番号を第三者に使用させることができる。この場合、送信側で相手側電話番号の変更を知らずに簡易メールを送信した場合、相手側の個人情報にかかわる重要な情報を第三者に誤送信することになる。このため、相手側の電話番号が変更になり、あるいは解約した場合に、上記した誤送信を未然に防止する方法の出現が望まれていた。 …中略… 【発明が解決しようとする課題】 【００１０】 本発明の課題は、上記したＤｏｃ．Ｂｅｌｌ（登録商標）、またはＤｒ．Ｂｅｌｌ（登録商標）、あるいはその両方により提供される電話番号の使用履歴情報を参照し、全てのキャリアを対象に携帯電話番号の使用状況に変化が無いか判定し、その結果を用いて作成したメッセージを送信することにより、誤送信や送信エラーの機会を極力減らし、相手側に正確に簡易メールを含むメッセージ送信が可能な、メッセージ送信装置および方法ならびにプログラムを提供することにある。 …中略… 【００１６】 （５）前記調査判定手段は、前記判定された指定の電話番号の使用状況を所定期間蓄積した電話番号使用履歴情報から順次読み出して前記メッセージ送信制御手段へ出力する第１の判定を行うことを特徴とする上記（１）～（４）のいずれか１つ記載のメッセージ送信装置を提供する。上記（５）のメッセージ送信装置によれば、指定の電話番号の使用状況を所定期間蓄積した電話番号使用履歴情報から使用状況を判定するため、過去において移転案内をしていた無効電話番号を得ることが出来、この場合メッセージ送信制御手段はメッセージ送信を禁止するため、誤送信や送信エラーを極力回避することが出来る。 …中略… 【００３６】 メッセージ組立部１０４は、使用状況判定部１０２により、電話番号情報ＤＢ２０３に格納された指定の電話番号が実在し、「有効」と判定された場合に、その電話番号を宛先として通信ネットワークインタフェース部１０５を介して契約端末５０に作成したメッセージを送信する。また、メッセージ組立部１０４は、使用状況判定部１０２により指定の電話番号が「移転案内中」であると判定された場合、案内された移転先電話番号を宛先とし、通信ネットワークインタフェース部１０５を介して契約端末５０に作成したメッセージを送信する。」 イ．甲３発明 上記アの特に下線部に着目すると、甲３には、次の発明（以下、「甲３発明」という。）が記載されていると認められる。 「携帯電話の電話番号が実在し、「有効」と判定された場合に、ＳＭＳを送信する点。」 （４）甲第４号証 ア．甲４の記載事項 甲４には、図面とともに次の事項が記載されている。 「【発明を実施するための形態】 【００１９】 以下、本発明の一実施形態について、図面を参照して説明する。 図１は、本実施形態による通信システム１の構成を示す図である。通信システム１は、複数の利用者端末１００（利用者端末１００－１、利用者端末１００－２、利用者端末１００－３、利用者端末１００－４、・・・）と、サービス提供事業者サーバ２００と、端末管理装置３００と、複数の認証サーバ４００（認証サーバ４００－１、認証サーバ４００－２、認証サーバ４００－３、・・・）と、認証支援サーバ５００とのコンピュータ装置を備えている。複数の利用者端末１００は同様の構成であるので、特に区別しない場合には「－１」、「－２」、等の表記を省略して利用者端末１００として説明する。同様に、複数の認証サーバ４００は同様の構成であるので、特に区別しない場合には「－１」、「－２」、等の表記を省略して認証サーバ４００として説明する。 【００２０】 利用者側において、複数の利用者端末１００が端末管理装置３００に接続され、ユーザネットワーク（ＮＷ）が構成される。端末管理装置３００に接続された複数の利用者端末１００は、それぞれ複数のユーザに利用される。ユーザＮＷは、例えば家庭内のＬＡＮ（Local Area Network）等である。端末管理装置３００は、外部のネットワーク（ＮＷ）を介して、サービス提供事業者のサービス提供事業者サーバ２００や、認証サービス提供事業者の認証支援サーバ５００や認証サーバ４００に接続される。ＮＷは、例えばインターネット網のような通信ネットワークである。ただし、ＮＷは、コンピュータ装置、コンピュータ端末が通信可能であれば、仮想閉域網、ＬＡＮ、ＷＡＮ（Wide Area Network）、専用回線、公衆回線、無線、有線を問わず、如何なる通信ネットワークでも良い。端末管理装置３００と、サービス提供事業者サーバ２００と、認証支援サーバ５００と、認証サーバ４００とは、ＮＷを介して接続され、互いに通信可能である。 【００２１】 図２は、通信システム１が備える各コンピュータ装置の構成を示すブロック図である。 利用者端末１００は、ユーザに利用されるコンピュータ端末であり、ネットワークを介してサービス提供事業者サーバ２００から提供されるサービスを利用する。ここで、利用者端末１００がサービス提供事業者サーバ２００のサービスを利用する際には、ユーザから入力される認証データを送信してユーザ認証を行い、認証処理が成功した場合に利用が許可される。利用者端末１００には、このような認証処理を行うための認証データの入力を受け付けるキーボード、ＩＣカードリーダ、指紋データの読取装置などのいずれかまたは複数の入力デバイスが備えられる。利用者端末１００としては、例えば、ＰＣ、携帯電話端末（スマートフォン）、タブレットＰＣ、テレビ受信機などが想定される。利用者端末１００は、複数のユーザに共用され、利用されることができる。 …中略… 【００２５】 端末情報記憶部３０１には、ユーザネットワークに接続された利用者端末１００の端末情報が記憶される。図３は、端末情報記憶部３０１に記憶される端末情報のデータ例を示す図である。端末情報には、ＭＡＣ（Media Access Control）アドレス、端末固有番号、端末型番、デバイス名等のデータが含まれる。ＭＡＣアドレスは、通信機器に一意に付与される物理アドレスである。端末固有番号は、端末に一意に付与されるシーケンスの番号である。ＭＡＣアドレスや端末固有番号は、利用者端末１００を識別する識別情報である。端末型番は、端末の機種を示す情報である。デバイス名は、端末の機種の名称である。 …中略… 【００２８】 ユーザ認証情報記憶部４０１には、ユーザを認証するためのユーザ認証情報が予め記憶されている。図４は、ユーザ認証情報記憶部４０１－１に記憶されているユーザ認証情報のデータ例を示す図である。ユーザ認証情報には、回線ＩＤと、端末固有番号と、ユーザＩＤと、パスワードとが対応付けられて記憶される。回線ＩＤは、サービスを利用することが予め定められた利用者端末１００が接続されている回線を識別する識別情報である。端末固有番号は、サービスを利用することが予め定められた利用者端末１００の端末固有番号である。ユーザＩＤは、サービスを利用することが予め定められたユーザを識別する情報である。パスワードは、ユーザＩＤに対応するパスワードであり、利用者端末１００から送信される認証データと照合される。このように、認証方式がＩＤ／ＰＷ認証である場合、回線ＩＤと端末固有番号とにはユーザＩＤとパスワードとの文字列が対応付けられるが、例えば認証方式が指紋認証である場合、予めユーザから採取された指紋パターンを示す情報が対応付けられて記憶される。 【００２９】 認証処理部４０２は、認証支援サーバ５００から送信される認証要求を受信し、サービス毎、ユーザ毎に認証処理を行う。例えば、認証処理部４０２－１は、利用者端末１００から送信されるユーザＩＤとパスワードとが含まれる認証データを受信すると、ユーザ認証情報記憶部４０１に記憶されているユーザ認証情報を読み出して照合する。そして、受信した認証データに一致する情報がユーザ認証情報記憶部４０１に記憶されていると判定すると、認証成功と判定し、受信した認証データに一致する情報がユーザ認証情報記憶部４０１に記憶されていないと判定すると、認証失敗と判定する。 …中略… 【００４０】 次に、本実施形態による通信システム１の動作例を説明する。図９は、通信システム１による認証処理の動作例を示すシーケンス図である。 利用者端末１００が端末管理装置３００に接続すると（ステップＳ１）、端末管理装置３００の端末情報取得部３０２は、利用者端末１００から端末情報を取得し、端末情報記憶部３０１に記憶させる。そして、利用者端末１００は、ユーザからの入力に応じて、サービス提供事業者サーバ２００のＵＲＬを宛先として、サービス提供事業者サーバ２００が提供するサービスの認証要求を送信する（ステップＳ２）。サービス提供事業者サーバ２００は、利用者端末１００から送信された認証要求に基づいて、認証要求に自身を識別するサービス提供事業者ＩＤを付加するとともに、認証支援サーバ５００を宛先としたＨＴＴＰリダイレクトを送信する（ステップＳ３）。利用者端末１００は、サービス提供事業者サーバ２００から送信されるＨＴＴＰリダイレクトに応じて、認証支援サーバ５００を宛先とする認証要求を送信する。この際、端末管理装置３００は、認証要求を送信した利用者端末１００に対応する端末情報を端末情報記憶部３０１から読み出し、読み出した端末情報を、利用者端末１００から送信された認証要求に付加する。さらに、端末管理装置３００は、自身がネットワークに接続する回線を識別する回線ＩＤが含まれる回線情報を認証要求に付加し、認証支援サーバ５００に転送する（ステップＳ４）。 【００４１】 認証支援サーバ５００は、利用者端末１００から送信される認証要求を受信すると、端末情報判定部５０５が、認証方式情報記憶部５０１と端末認証情報記憶部５０２とを参照して、認証要求に含まれる端末情報に応じた認証方式ＩＤを読み出す（ステップＳ５、６）。さらに、ユーザ推定部５０７が、認証要求に含まれる回線情報と端末情報とに対応するユーザＩＤと、サービス提供事業者ＩＤと、認証日時とが含まれる認証履歴情報を、認証履歴情報記憶部５０４から読み出す（ステップＳ７、８）。そして、認証方式選定部５１０は、読み出したユーザＩＤと、端末情報とに対応する認証履歴情報を認証履歴情報記憶部５０４から読み出し、読み出した認証履歴情報に含まれる認証回数や認証成功数に基づいて、認証方式を判定する（ステップＳ９、１０）。 【００４２】 そして、認証支援サーバ５００は、判定した認証方式により認証を行う認証サーバ４００に、回線情報と、端末情報と、ユーザＩＤと、認証方式とが含まれる認証要求を送信する（ステップＳ１１）。認証サーバ４００は、認証支援サーバ５００から送信される認証要求を受信すると、利用者端末１００に対して、認証データ入力画面を送信する。例えば、認証サーバ４００がＩＤ／ＰＷ認証の認証処理を行う場合、ＩＤとパスワードとの入力画面を送信し、認証サーバ４００が指紋認証の認証処理を行う場合、指紋認証の入力画面を送信する（ステップＳ１２）。利用者端末１００は、認証サーバ４００から送信される認証データ入力画面を表示し、認証データの入力を受け付ける。利用者端末１００は、入力された認証データを認証サーバ４００に送信する（ステップＳ１３）。認証サーバ４００は、利用者端末１００から送信された認証データを受信すると、認証処理部４０２が、ユーザ認証情報記憶部４０１に記憶されているユーザ認証情報を読み出し、受信した認証データと照合して認証処理を行う（ステップＳ１４、１５）。そして、認証処理部４０２が認証成功と判定すると、認証結果通知部４０３は、認証結果を認証支援サーバ５００に送信する（ステップＳ１６）。 【００４３】 認証支援サーバ５００の認証支援部５１１は、認証サーバ４００から送信された認証結果を受信すると、認証結果が含まれる認証履歴情報を認証履歴情報記憶部５０４に記憶させる（ステップＳ１７）。認証支援サーバ５００が、認証が成功した場合の宛先であるサービス提供事業者サーバ２００のＵＲＬを利用者端末１００に送信し（ステップＳ１８）、利用者端末１００が、サービス提供事業者サーバ２００にリダイレクトを送信すると、サービス提供事業者サーバ２００は、認証結果画面を利用者端末１００に送信する（ステップＳ２０）。」 「【図１】 ［図：0001420007000003.jpg］ 【図９】 ［図：0001420007000004.jpg］ 」 イ．甲４発明 上記アの特に下線部に着目すると、甲４には、次の発明（以下、「甲４発明」という。）が記載されていると認められる。 「携帯電話端末にリダイレクトによってサービス提供事業者サーバ２００から認証結果画面を送信する通信システムであり、 ユーザに利用され、通信ネットワークに接続される携帯電話端末と、 通信ネットワークに接続するサービス提供事業者のサービス提供事業者端末２００と、 回線ＩＤと、端末固有番号と、ユーザＩＤと、パスワードとが対応付けられて記憶されたユーザ認証情報により認証処理し、認証が成功した場合の宛先であるサービス提供事業者サーバ２００のＵＲＬを携帯電話端末に送信し、携帯電話端末にサービス提供事業者サーバ２００にリダイレクトを送信させ、サービス提供事業者サーバ２００に認証結果画面を携帯電話端末に送信させる、認証サービス提供事業者の認証サーバ４００及び認証支援サーバ５００と、を備えた通信システム。」 （５）甲第５号証 ア．甲５の記載事項 甲５には、図面とともに次の事項が記載されている。 「【００１９】 （１）実施形態の構成 図１は、本実施形態に係る情報管理システム１の概略構成を示す図である。 情報管理システム１は、住宅ローンの事前審査を管理するシステムであり、同図に示すように、事前審査の申込情報を管理する情報管理サーバ１０と、事前審査の紹介を行う不動産会社において使用されるユーザ端末（第１の端末）２０と、不動産会社の顧客であり、事前審査の申込者である顧客が使用するカスタマ端末（第２の端末）３０と、事前審査を行う金融機関において使用される金融機関端末（第３の端末）４０とを備える。これらの情報管理サーバ１０と、ユーザ端末２０と、カスタマ端末３０と、金融機関端末４０とは、通信ネットワークＮを介して接続される。 【００２０】 通信ネットワークＮは、情報管理サーバ１０、ユーザ端末２０、カスタマ端末３０、および金融機関端末４０の間で相互に情報を送受信可能な通信網を含む。通信ネットワークＮは、例えば、インターネット、ＬＡＮ、専用線、電話回線、企業内ネットワーク、移動体通信網、ブルートゥース（登録商標）、ＷｉＦｉ（Wireless Fidelity）、その他の通信回線、それらの組み合わせ等のいずれであってもよく、有線であるか無線であるかを問わない。 …中略… 【００２２】 図１に示すように、情報管理サーバ１０は、通信インタフェース１１と、記憶部１２と、プロセッサ１３とを備える。 …中略… 【００２４】 記憶部１２は、例えば、ディスクドライブまたは半導体メモリ（ＲＯＭ、ＲＡＭなど）等のコンピュータ読み取り可能な記録媒体からなる物理デバイスの記憶領域が提供する論理デバイスである。記憶部１２は、複数の物理デバイスを１つの論理デバイスにマッピングして構築してもよいし、１つの物理デバイスを複数の論理デバイスにマッピングして構築してもよい。記憶部１２は、オペレーティングシステムプログラムやドライバプログラムを含む各種プログラムおよびこれらのプログラムの実行中に使用される各種データを格納する。具体的には、記憶部１２は、プロセッサ１３に実行させる情報管理プログラム１２１と、このプログラムの実行中に使用されるユーザデータベース（ＤＢ）１２２と、会員データベース（ＤＢ）１２３と、金融機関データベース（ＤＢ）１２４と、申込情報データベース（ＤＢ）１２５と、ポイント管理データベース（ＤＢ）１２６とを記憶している。 【００２５】 ユーザデータベース１２２は、不動産会社に関する情報（ユーザ情報）を格納する。ユーザ情報は、不動産会社ごとまたは担当者ごとに発行されるユーザＩＤ、認証用のパスコード（パスワード）、不動産会社の名称、所在地、メールアドレス等の情報を含む。 【００２６】 会員データベース１２３は、情報管理システム１に会員登録した顧客に関する情報（会員情報）を格納する。会員情報は、会員登録した顧客に対して発行される会員ＩＤおよび認証用のパスコード（パスワード）、氏名、住所、連絡先（電話番号）、生年月日、メールアドレス等の情報を含む。 …中略… 【００３２】 詳細には、プロセッサ１３は、認証管理部１３１と、申込情報登録部１３２と、本人確認管理部１３３と、閲覧処理部１３４と、申請確定部１３５と、回答受付部１３６と、ポイント管理部１３７とを有する。 【００３３】 認証管理部１３１は、ユーザ端末２０または金融機関端末４から情報管理サーバ１０へのログイン時における認証を行う。詳細には、認証管理部１３１は、ユーザ端末２０または金融機関端末４０がアクセスしてきた際に、ＩＤ（ユーザＩＤ、金融機関ＩＤ）およびパスワードの入力を要求し、ユーザデータベース１２２または金融機関データベース１２４に格納されている情報に照らして認証を行うと共に、アクセスログを記録する。 【００３４】 申込情報登録部１３２は、ユーザ端末２０から送信された申込情報を申込情報データベース１２５に登録する。詳細には、申込情報登録部１３２は、ユーザ端末２０から送信された申込情報に、顧客の本人確認に使用される氏名、電話番号、および生年月日の３つの情報が申込情報に含まれるか否かを確認し、これらの情報が揃っている場合に申し込み情報を登録する。反対に、３つの情報のいずれか１つでも漏れている場合には、申込情報を登録せず、情報が漏れている旨の警告をユーザ端末２０に送信する。 【００３５】 本人確認管理部１３３は、カスタマ端末３０が情報管理サーバ１０に登録された特定の申込情報にアクセスしてきた際に、カスタマ端末３０を操作する顧客が当該申込情報にかかる顧客本人であるか否かの本人確認を行う。詳細には、本人確認管理部１３３は、カスタマ端末３０に対し、申込情報として登録された顧客の氏名、電話番号、および生年月日の３つの情報の入力を要求し、入力された情報が登録済みの情報と一致するか否かを判定する。さらに、本人確認管理部１３３は、会員ＩＤおよびパスワードの入力を要求し、会員データベース１２３に格納されている情報に照らして認証を行うことにより、本人確認を行う。このように、不動産会社のユーザ端末から登録された氏名等の所定情報が顧客から入力され、さらに、当該顧客から、既存サービス等の会員ＩＤによるログインがなされることを本人確認の要件とすることで、従来の運転免許証等の本人確認書類による本人確認処理と同程度ないしその代替手段になり得る程度のセキュリティを実現している。なお、本実施形態においては、本人確認情報として上記３つの情報を要求することとしているが、これに限る趣旨ではなく、要求されるセキュリティの強度によって、必要な情報をさらに増やしてもよいし、減らしてもよい。 【００３６】 閲覧処理部１３４は、ログイン中のユーザ端末２０、カスタマ端末３０、または金融機関端末４０からの要求に従い、所定の閲覧用画面をこれらの端末に送信して表示させる。本実施形態においては、ユーザ端末２０、カスタマ端末３０、および金融機関端末４０に対してファイルの閲覧のみを許可し、ファイルのダウンロードは不許可とすることにより、情報漏えいのリスクを低減している。 …中略… 【００４１】 ユーザ端末２０およびカスタマ端末３０は、通信ネットワークＮを介して他の通信機器とデータの授受が可能であり、且つ、受信した情報に基づく画面表示が可能な表示部と、入力デバイスとを備えるあらゆる端末装置を利用することができる。具体的には、ユーザ端末２０およびカスタマ端末３０として、タブレット端末、パーソナルコンピュータ（ＰＣ）、ノートＰＣ、スマートフォン、携帯電話機、ＰＤＡ等を用いることができる。 …中略… 【００４４】 まず、ステップＳ１００において、住宅ローンの事前審査の申込情報の登録処理を行う。申込情報の登録処理は、不動産会社の店頭において、不動産会社の担当者が顧客と対話しながら、ユーザ端末２０を操作することにより行われる。図４は、情報管理サーバ１０およびユーザ端末２０において実行される申込情報の登録処理のシーケンス図である。 …中略… 【００４６】 図５は、ユーザ端末２０に表示されるログイン画面を例示する模式図である。図５に示すログイン画面Ａ１には、ＩＤ入力欄ａ１１と、パスワード入力欄ａ１２と、ログインボタンａ１３とが設けられている。不動産会社の担当者は、ＩＤ入力欄ａ１１およびパスワード入力欄ａ１２に、予め設定されたユーザＩＤおよびパスワードを入力し、さらにログインボタンａ１３に対して所定の操作（例えばタップ操作）を行う。ユーザ端末２０は、ＩＤ入力欄ａ１１およびパスワード入力欄ａ１２への入力操作およびログインボタンａ１３への操作を検知すると、入力されたユーザＩＤおよびパスワードを情報管理サーバ１０に送信する（ステップＳ１２２）。情報管理サーバ１０はユーザＩＤおよびパスワードを受信してユーザデータベース１２２に照会することにより認証を行う（ステップＳ１１２）。 【００４７】 ユーザＩＤおよびパスワードの認証に成功すると、情報管理サーバ１０は、図６～図１２に例示する申込情報の入力画面をユーザ端末２０に順次送信する（ステップＳ１１３）。ユーザ端末２０は、情報管理サーバ１０から送信された入力画面を順次表示し（ステップＳ１２３）、入力画面に対してなされる操作に応じて、申込情報を情報管理サーバ１０に順次送信する（ステップＳ１２４）。 …中略… 【００６１】 ユーザ端末２０は、登録完了ボタンａ７４への操作を検知すると、申込情報の入力が完了した旨を示す情報を情報管理サーバ１０に送信する（ステップＳ１２５）。これに応じて、情報管理サーバ１０は、受信した申込情報を申込情報データベース１２５に登録する（ステップＳ１１４）。これにより、当該申込情報のステータスが「登録済み（申請前）」となる。 【００６２】 さらに、情報管理サーバ１０は、申込情報が登録された旨と、当該申込情報による事前審査の申請画面にアクセスするためのＵＲＬとが記載されたメールを、顧客のメールアドレスに送信する（ステップＳ１１５）。 【００６３】 また、情報管理サーバ１０は、さらに、図１２に示す入力完了画面を送信し、ユーザ端末２０に表示させてもよい。図１２に示すように、入力完了画面Ａ８には、メール送信先のアドレスを含むメッセージａ８１が表示されている。この後、ボタンａ８２～ａ８４への操作により、ユーザ端末２０の画面を所定の画面に遷移させることができる。 【００６４】 再び図３を参照すると、ステップＳ１００に続くステップＳ２００において、顧客による事前審査の申請処理を行う。事前審査の申請処理は、顧客自身がカスタマ端末３０を操作することにより行われる。図１３は、情報管理サーバ１０およびカスタマ端末３０において実行される事前審査の申請処理のシーケンス図である。 【００６５】 カスタマ端末３０が、情報管理サーバ１０から送信されたメール（図４のステップＳ１１５参照）に記載されたＵＲＬにアクセスすると（ステップＳ２２１）、情報管理サーバ１０は、本人確認画面を送信してカスタマ端末３０に表示させ、本人確認情報を要求する（ステップＳ２１１）。 【００６６】 図１４は、カスタマ端末３０に表示される本人確認画面を例示する模式図である。図１４に示す本人確認画面Ｂ１には、氏名入力欄ｂ１１と、電話番号入力欄ｂ１２と、生年月日入力欄ｂ１３と、確認ボタンｂ１４とが設けられている。顧客は、氏名入力欄ｂ１１、電話番号入力欄ｂ１２、および生年月日入力欄ｂ１３に対し、不動産会社の店頭でユーザ端末２０に入力したものと同じ情報を入力し、さらに、確認ボタンｂ１４に対して所定の操作（例えばタップ操作）を行う。 【００６７】 カスタマ端末３０は、氏名入力欄ｂ１１、電話番号入力欄ｂ１２、および生年月日入力欄ｂ１３に対する入力操作並びに確認ボタンｂ１４に対するタップ操作を検知すると、これらの入力欄にそれぞれ入力された情報を本人確認情報として情報管理サーバ１０に送信する（ステップＳ２２２）。情報管理サーバ１０は、本人確認情報を受信して申込情報データベース１２５に登録された申込情報に照会することにより本人確認を行う（ステップＳ２１２）。 【００６８】 本人確認に成功すると、情報管理サーバ１０は続いて会員ログイン画面をカスタマ端末３０に送信して表示させ、会員ＩＤおよびパスワードを要求する（ステップＳ２１３）。 【００６９】 図１５は、カスタマ端末３０に表示される会員ログイン画面を例示する模式図である。図１５に示す会員ログイン画面Ｂ２には、ＩＤ入力欄ｂ２１と、パスワード入力欄ｂ２２と、ログインボタンｂ２３と、新規会員登録ボタンｂ２４とが設けられている。顧客は、情報管理システム１に対して会員登録をしている場合、会員登録の際に設定した会員ＩＤおよびパスワードを、ＩＤ入力欄ｂ２１およびパスワード入力欄ｂ２２にそれぞれ入力し、ログインボタンｂ２３をタップする。 【００７０】 カスタマ端末３０は、ＩＤ入力欄ｂ２１およびパスワード入力欄ｂ２２への入力操作およびログインボタンｂ２３へのタップ操作を検知すると、入力された会員ＩＤおよびパスワードを情報管理サーバ１０に送信する（ステップＳ２２３）。情報管理サーバ１０は、会員ＩＤおよびパスワードを受信して会員データベース１２３に照会することにより認証を行う（ステップＳ２１４）。 【００７１】 他方、顧客は、会員登録をしていない場合、新規会員登録ボタンｂ２４をタップする。これに応じて、カスタマ端末３０は、情報管理サーバ１０に対して新規会員登録画面を要求し、情報管理サーバ１０は、当該画面をカスタマ端末３０に送信して表示させる。この際、情報管理サーバ１０は、ステップＳ１００（図３参照）において登録された顧客情報のうちの必要な情報を予め新規会員登録画面にオートフィルインしておいてもよい。会員登録がされた後、情報管理サーバ１０は再度、会員ログイン画面Ｂ２をカスタマ端末３０に表示させる。 【００７２】 会員ＩＤおよびパスワードの認証に成功すると、情報管理サーバ１０は、事前審査の申請画面をカスタマ端末３０に送信して表示させる（ステップＳ２１５、ステップＳ２２４）。 …中略… 【００７５】 顧客は、事前審査を申請する場合、利用規約を確認して同意した上で、申請ボタンｂ３２をタップする。カスタマ端末３０は、申請ボタンｂ３２へのタップ操作を検知すると、申請確定情報を情報管理サーバ１０に送信する（ステップＳ２２６）。これに応じて、情報管理サーバ１０は、当該申込情報による事前審査の申請がなされた旨を示す情報を、申込情報において選択された金融機関にメールにより一斉に送信する（ステップＳ２１７）。このメールには、当該申込情報の閲覧画面にアクセスするためのＵＲＬが記載されている。また、申込情報データベース１２５においては、当該申請情報のステータスが「申請済み（回答待ち）」となる。図１７は、申請ボタンｂ３２がタップされた後、カスタマ端末３０に表示される申請完了画面を例示する画面である。 …中略… 【００７７】 再び図３を参照すると、ステップＳ２００に続くステップＳ３００において、申込情報の閲覧および回答の登録処理を行う。申込情報の閲覧および回答の登録処理は、金融機関端末４０を操作することにより行われる。図１８は、情報管理サーバ１０および金融機関端末４０において実行される申込情報の閲覧および回答の登録処理のシーケンス図である。 …中略… 【００８５】 さらに、情報管理サーバ１０は、審査情報の回答が登録された旨を示す情報を、当該申込情報を作成した不動産会社の担当者および顧客にメールにより送信する（ステップＳ３１６）。 【００８６】 再び図３を参照すると、ステップＳ３００に続くステップＳ４００において、事前審査の回答の閲覧処理を行う。回答の閲覧処理は、ユーザ端末２０またはカスタマ端末３０を操作することにより行われる。 【００８７】 例えばカスタマ端末３０から回答を閲覧する場合、受信したメールに記載されたＵＲＬにアクセスする。これに応じて、情報管理サーバ１０は、図１５に例示する会員ログイン画面Ｂ２をカスタマ端末３０に送信して表示させる。会員ログイン画面Ｂ２から入力された会員ＩＤおよびパスワードによる認証に成功すると、情報管理サーバ１０は、事前審査の回答閲覧画面をカスタマ端末３０に送信して表示させる。」 「【図１】 ［図：0001420007000005.jpg］ 【図２】 ［図：0001420007000006.jpg］ 【図３】 ［図：0001420007000007.jpg］ 【図４】 ［図：0001420007000008.jpg］ 【図１３】 ［図：0001420007000009.jpg］ 【図１８】 ［図：0001420007000010.jpg］ 」 イ．甲５発明 上記アの特に下線部に着目すると、甲５には、次の発明（以下、「甲５発明」という。）が記載されていると認められる。 「情報管理システム１であって、 情報管理システム１は、事前審査の申込情報を管理する情報管理サーバ１０と、事前審査の紹介を行う不動産会社において使用されるユーザ端末２０と、不動産会社の顧客であり、事前審査の申込者である顧客が使用するカスタマ端末３０と、事前審査を行う金融機関において使用される金融機関端末４０とを備え、 情報管理サーバ１０と、ユーザ端末２０と、カスタマ端末３０と、金融機関端末４０とは、通信ネットワークＮを介して接続され、 情報管理サーバ１０は、通信インタフェース１１と、記憶部１２と、プロセッサ１３とを備え、 記憶部１２は、プロセッサ１３に実行させる情報管理プログラム１２１と、このプログラムの実行中に使用されるユーザデータベース（ＤＢ）１２２と、会員データベース（ＤＢ）１２３と、金融機関データベース（ＤＢ）１２４と、申込情報データベース（ＤＢ）１２５とを記憶し、 プロセッサ１３は、認証管理部１３１と、申込情報登録部１３２と、本人確認管理部１３３と、閲覧処理部１３４と、申請確定部１３５と、回答受付部１３６とを有し、 申込情報登録部１３２は、ユーザ端末２０から送信された申込情報を申込情報データベース１２５に登録し、詳細には、ユーザ端末２０から送信された申込情報に、顧客の本人確認に使用される氏名、電話番号、および生年月日の３つの情報が申込情報に含まれるか否かを確認し、これらの情報が揃っている場合に申し込み情報を登録し、 本人確認管理部１３３は、カスタマ端末３０に対し、申込情報として登録された顧客の氏名、電話番号、および生年月日の３つの情報の入力を要求し、入力された情報が登録済みの情報と一致するか否かを判定し、さらに、会員ＩＤおよびパスワードの入力を要求し、会員データベース１２３に格納されている情報に照らして認証を行うことにより、本人確認を行い、 カスタマ端末３０として、タブレット端末、パーソナルコンピュータ（ＰＣ）、ノートＰＣ、スマートフォン、携帯電話機、ＰＤＡ等を用いることができ、 ステップＳ１００において、 ユーザ端末２０は、情報管理サーバ１０から送信された入力画面を順次表示し、入力画面に対してなされる操作に応じて、申込情報を情報管理サーバ１０に順次送信し、 ユーザ端末２０は、申込情報の入力が完了した旨を示す情報を情報管理サーバ１０に送信し、これに応じて、情報管理サーバ１０は、受信した申込情報を申込情報データベース１２５に登録し、 情報管理サーバ１０は、申込情報が登録された旨と、当該申込情報による事前審査の申請画面にアクセスするためのＵＲＬとが記載されたメールを、顧客のメールアドレスに送信し、 ステップＳ１００に続くステップＳ２００において、 カスタマ端末３０が、情報管理サーバ１０から送信されたメールに記載されたＵＲＬにアクセスすると、情報管理サーバ１０は、本人確認画面を送信してカスタマ端末３０に表示させ、本人確認情報を要求し、 本人確認に成功すると、情報管理サーバ１０は続いて会員ログイン画面をカスタマ端末３０に送信して表示させ、会員ＩＤおよびパスワードを要求し、 会員ＩＤおよびパスワードの認証に成功すると、情報管理サーバ１０は、事前審査の申請画面をカスタマ端末３０に送信して表示させ、 顧客は、事前審査を申請する場合、申請ボタンｂ３２をタップし、カスタマ端末３０は、申請確定情報を情報管理サーバ１０に送信し、これに応じて、情報管理サーバ１０は、当該申込情報による事前審査の申請がなされた旨を示す情報を、申込情報において選択された金融機関にメールにより一斉に送信し、 ステップＳ２００に続くステップＳ３００において、 申込情報の閲覧および回答の登録処理を行い、 情報管理サーバ１０は、審査情報の回答が登録された旨を示す情報を、当該申込情報を作成した不動産会社の担当者および顧客にメールにより送信し、 ステップＳ３００に続くステップＳ４００において、 カスタマ端末３０から回答を閲覧する場合、受信したメールに記載されたＵＲＬにアクセスし、これに応じて、情報管理サーバ１０は、会員ログイン画面Ｂ２をカスタマ端末３０に送信して表示させ、会員ＩＤおよびパスワードによる認証に成功すると、情報管理サーバ１０は、事前審査の回答閲覧画面をカスタマ端末３０に送信して表示させる、 情報管理システム１。」 （６）甲第６号証 ア．甲６の記載事項 甲６には、図面とともに次の事項が記載されている。 「（表紙） ［図：0001420007000011.jpg］ （第２ページ） ［図：0001420007000012.jpg］ （第４ページ） ［図：0001420007000013.jpg］ （第１０ページ） ［図：0001420007000014.jpg］ （第１２ページ） ［図：0001420007000015.jpg］ 」 イ．甲６発明 上記アの記載事項を総合すると、甲６には、次の発明（以下、「甲６発明」という。）が記載されていると認められる。 「事業者ポータルサイトに、ＳＭＳを送信する宛先電話番号、認証に使用する項目、認証完了後の遷移先のＵＲＬを設定すること。」 （７）甲第７号証 甲７には、次の事項が記載されている。 「 ［図：0001420007000016.jpg］ 」 （８）甲第８号証 ア．甲８の記載事項 甲８には、次の事項が記載されている。 「【００２２】 そこで、上記した構成の介護支援システム１による「ケアマネージャ」との間の処理手順を図３に示す。ステップＳ１において、ケアマネージャＡがユーザ端末１１からサーバ装置２へのアクセス要求指令を入力する。そして、サーバ装置２の通信回路５がアクセス要求データを受信すると（ステップＳ２）、ＭＰＵ３は認証画面データをケアマネージャＡ側へ送信し（ステップＳ３）、ユーザ端末１１はその表示部に認証画面を表示する（ステップＳ４）。認証画面にはユーザＩＤ、ユーザパスワードなどの入力用カラムが設けられており、ケアマネージャＡはこれらの入力用カラムにユーザＩＤ、ユーザパスワードを入力しサーバ装置２へ送信する（ステップＳ５）。ユーザＩＤおよびユーザパスワードを受信したＭＰＵ３はＷＥＢアプリケーションソフト８における認証処理手段Ｎ１の機能によりマスタデータベースＭＤ３を参照して認証処理を実行する（ステップＳ６）。受信したユーザＩＤおよびユーザパスワードが認証されなければ、ステップＳ３に戻ってステップＳ３～Ｓ６の処理を繰り返す。ユーザＩＤおよびユーザパスワードが認証されれば、ＭＰＵ３は通信回路５により操作メニュー情報をケアマネージャＡ側へ送信し（ステップＳ７）、ケアマネージャＡのユーザ端末１１で操作メニューが表示される（ステップＳ８）。操作メニューの内容は、「被保険者の個人情報リスト（氏名、住所、被保険者番号など）の表示」、「ベッド予約状況確認」、「利用票の登録・確認」などであり、例えばボタン選択形式で表わされる。」 イ．甲８発明 上記アの記載によると、甲８には、「ＷＥＢアプリケーションソフト８により認証処理を実行する点」（以下、「甲８発明」という。）が記載されていると認められる。 （９）甲第９号証 甲９には、次の事項が記載されている。 「 ［図：0001420007000017.jpg］ 」 上記記載によると、甲９には、「甲第６号証.pdf」とのファイルの文書のプロパティにおいて、「作成日」の項目が「２０１７年８月９日」であり、「更新日」の項目が「２０２３年１１月２８日」であることが記載されているといえる。 （１０）甲第１０号証 甲１０には、次の事項が記載されている。 「 ［図：0001420007000018.jpg］ 」 上記記載によると、甲１０には、「〔SMAPS〕操作ガイド_SMSメニュー（第2.0版）20170727」とのファイルの文書のプロパティにおいて、「作成日」の項目が「２０１７年８月９日」であり、「更新日」の項目が「２０１７年８月９日」であることが記載されているといえる。 （１１）甲第１１号証、甲第１２号証 ア．甲１１の記載事項 甲１１には、次の事項が記載されている。 「【００４９】 もしくは、決められた又は任意の言葉を発声することにより、この骨伝導音から特徴量の照合をし被認証者を認識し、その被認証者しか分かり得ないパスワード及び質問を選定して再度認証することもできる。 【００５０】 このように複数の認証を併用して使用することで、認証精度が向上する。 その他、カードや入力、指紋等の公知の方法で認証開始時に必要なＩＤデータを入力することもできる。」 イ．甲１２の記載事項 甲１２には、次の事項が記載されている。 「【０００４】 貨幣価値と等価な機能を有するものには、キャッシュカード、クレジットカード、デビットカードのように、使用者の本人確認を行うようにしたものもある。これらのカードでは、カード側に登録されているパスワード（暗証番号またはカード番号）と自動預払機のような読取装置に入力されたパスワードとを照合することにより、本人確認を行っている。クレジットカードにおいては、サインや写真を併用することにより、物品やサービスを対面で提供する際の本人確認を一層確実にすることも行われている。ここに、キャッシュカードやクレジットカードは、自動預払機（いわゆる、ＡＴＭ）を用いて現金を引き出す場合にも用いられるから、自動預払機には、常に現金を蓄えておかなければならず、またメンテナンス用の人員を必要とするという問題がある。」 ウ．周知技術 上記ア、イによると、「認証の際に複数の内容で確認を行うこと」は、本願出願時における周知技術であったと認められる。 （１２）甲第１３号証 甲１３には、次の事項が記載されている。 「 （第１ページ） ［図：0001420007000019.jpg］ （第２ページ） ［図：0001420007000020.jpg］ 」 上記記載によると、甲１３には、株式会社リンクスは、経済産業省により産業競争力強化法における新事業活動計画の認定を受けたことが記載されていると認められる。 ２．甲６発明の頒布日について 甲７には、ファインテクノロジー株式会社の栗原信一氏が、株式会社リンクスから、甲６の「〔SMAPS〕 事業者ポータルサイトSMSメニュー 操作ガイド 第2.0版」と称するマニュアル（以下、「ＳＭＡＰＳ操作ガイド」という。）を、平成３０年１月１７日に、秘密保持義務なしに受領したことが記載されているといえる。 ここで、平成３０年１月１７日時点の技術常識、及び、一般的な商習慣を考慮すると、上記「秘密保持義務なしに受領した」ことを否定するべき合理的な理由は認められない。また、製品、サービスに関する取扱説明書やマニュアル等に表記される版数は、改訂により付けられる一連の番号であって、当該取扱説明書等の変更が行われる毎に異なる版数が付与されることが、本願出願時の技術常識であるところ、同じサービスに関し、同一タイトルの２つのマニュアルの版数が同じ場合には、当該２つのマニュアルの記載内容は同一のものであると推認できる。そして、甲６と上記「ＳＭＡＰＳ操作ガイド」とは、同一のサービスに関し、同一タイトル、かつ、同一の版数であって、両者の記載内容が異なるものであるというべき合理的な理由も認められないことからすると、両者の記載内容は同一のものであると解するのが相当である。 よって、上記「ＳＭＡＰＳ操作ガイド」は、平成３０年１月１７日に頒布され、公知となったものであること、及び、甲６と上記「ＳＭＡＰＳ操作ガイド」との記載内容は同一のものであると認められる。 以上のとおりであるから、甲６に記載された発明は、本願出願前である平成３０年１月１７日には、公知であったと認められる。 なお、被請求人は、審判事件答弁書、被請求人陳述要領書、及び、被請求人上申書において、甲６と上記「ＳＭＡＰＳ操作ガイド」との同一性が確認できないこと、及び、上記「ＳＭＡＰＳ操作ガイド」の受領日において「秘密保持契約」がなかったことを証明していないことから、甲６の頒布日は不明であって、証拠として採用されるべきではないと主張している。しかしながら、被請求人は、当該主張を推認するに足る合理的な根拠又は具体的な証拠を提示しておらず、単に、上記同一性が確認できない、あるいは、「秘密保持契約」がなかったということの可能性を述べるにとどまるから、被請求人の主張は採用することができない。 ３．無効理由１について （１）本件特許発明１ ア．本件特許発明１と甲１発明との対比 本件特許発明１と甲１発明とを対比すると、以下のとおりである。 （ａ）構成要件Ａについて 甲１発明において、「連絡システム１」は、「事業者サーバ１０、１１、管理サーバ２０」を含むものである。 また、甲１発明の「携帯端末４０の所有者」、「事業者」はそれぞれ、構成要件Ａの「ユーザ」、「事業者」に相当する。 また、甲１発明の「連絡システム１」を構成する「管理サーバ２０」は、「管理サーバ２０に記憶された管理請求データの「６．使用量」、「７．請求金額」、「８．決済手段」、「１１．備考」等からお知らせ画面の内容を生成し、ネット用回線を介して携帯端末４０に送信して、携帯端末４０はお知らせ画面表示を行う」ものであるところ、甲１発明の「お知らせ画面」は、「携帯端末４０の所有者」に見せることを企図したものであることは明らかであるから、構成要件Ａの「前記ユーザのためのユーザ用画面」に相当する。 また、甲１発明において、「管理サーバ２０」は、「お知らせ画面」を「携帯端末４０」に送信して表示させることにより、「携帯端末４０の所有者」を「お知らせ画面」に“案内”しているといえるところ、当該「管理サーバ２０」を含む「連絡システム１」も、“案内”するシステムといい得るものである。 よって、甲１発明の「連絡システム１及び携帯端末４０」と、構成要件Ａの「ユーザを事業者が提供する前記ユーザのためのユーザ用画面に案内する案内システム」とは、後述する相違点を除き、「ユーザを前記ユーザのためのユーザ用画面に案内する案内システム」である点において共通する。 （ｂ）構成要件Ｂについて 甲１発明において、「事業者サーバ１０、１１」と「管理サーバ２０、キャリア３０、３１」との間を接続する「専用回線」又は「インターネット回線」と、「キャリア３０」と「携帯端末４０」との間を接続する「携帯電話回線とネット用回線」とは、全体としてみれば、構成要件Ｂ及びＤの「ネットワーク」に相当し、「事業者サーバ１０、１１」、「管理サーバ２０、キャリア３０、３１」及び「携帯端末４０」はいずれも当該「ネットワーク」に接続可能であることは明らかである。 そして、甲１発明の「携帯端末４０」は、「携帯端末４０の所有者」が所有（所持）するものである。 また、甲１発明において、「携帯端末４０」は、「連絡システム１および携帯端末４０」に含まれる。 したがって、甲１発明の「携帯端末４０」は、構成要件Ｂの「前記ユーザが所持し、ネットワークに接続可能な携帯端末」に相当する。 （ｃ）構成要件Ｃについて 甲１発明の「事業者サーバ１０、１１」は「各事業者のサーバ」であるところ、構成要件Ｃの「事業者の事業者装置」に相当する。 また、前記（ｂ）を参酌すれば、甲１発明の「事業者サーバ１０、１１」は、「専用回線」又は「インターネット回線」（ネットワーク）に接続可能である。 よって、甲１発明において、「連絡システム１および携帯端末４０」を構成する「事業者サーバｌ０、１１」と、構成要件Ｃの「前記ネットワークに接続可能な前記事業者の事業者装置」とは、「前記ネットワークに接続可能な事業者の事業者装置」である点において共通する。 （ｄ）構成要件Ｄについて 甲１発明の「ガス事業者がガス料金を請求する実施例」において、「ＳＭＳデータである請求データ」であって「ガス事業者がその顧客に対してＳＭＳを利用して料金を請求するためのデータ」は、「ガス事業者の事業者サーバ１０」から「管理サーバ２０」に送信されているところ、当該「請求データ」は、「事業者サーバ１０」から「管理サーバ２０」に提供される「顧客」に関する情報といえる。 そして、甲１発明において、「管理サーバ２０」は受信した「請求データ」に、システムＩＤ、事業者ＩＤに対応する既定ＵＲＬを関連付けて「管理請求データ」として記憶するとともに、「携帯端末４０の所有者」から入力された「認証コード」と、「管理請求データ」の「認証情報」とを照合して確認し、認証されると、「管理サーバ２０」に記憶された「管理請求データ」から「お知らせ画面」の内容を生成し、ネット用回線を介して「携帯端末４０」に送信して、「携帯端末４０」は「お知らせ画面」表示を行うものであるところ、前記「顧客」は、「携帯端末４０の所有者」と同一視できる。 よって、甲１発明の「請求データ」（及び、「管理請求データ」）は、構成要件Ｄの「前記事業者装置が提供するユーザ情報」に相当する。 また、甲１発明において、「管理サーバ２０」が、「携帯端末４０の所有者」から入力された「認証コード」と、「管理請求データ」の「認証情報」とを照合して確認し、認証することは、構成要件Ｄの「前記事業者装置が提供するユーザ情報に基づいて、本人確認する」ことに相当する。 さらに、甲１発明において、「管理サーバ２０」が、前記確認、認証により「お知らせ画面」を「携帯端末４０」に送信して表示させることは、構成要件Ｄの「前記事業者装置が提供するユーザ情報に基づいて、本人確認するとともに」「携帯端末を前記ユーザ用画面に誘導する」ことに相当する。 また、前記（ｂ）を参酌すれば、甲１発明の「管理サーバ２０」は、「専用回線」又は「インターネット回線」（ネットワーク）に接続可能である。 また、甲１発明において、「管理サーバ２０」は「管理者のサーバ」であることころ、当該「管理者」は、構成要件Ｄの「サービス事業者」に相当する。 さらに、甲１発明の「管理サーバ２０」は、認証の機能を備えるところ、認証装置といい得るものである。 よって、前記（ｂ）を参酌すれば、甲１発明において、「連絡システム１および携帯端末４０」に含まれる「管理サーバ２０」は、構成要件Ｄの「前記事業者装置が提供するユーザ情報に基づいて、本人確認するとともに前記携帯端末を前記ユーザ用画面に誘導する、前記ネットワークに接続可能なサービス事業者の認証装置」に相当する。 （ｅ）構成要件Ｅについて 甲１発明の「請求データ」（及び、「管理請求データ」）は、「「１．事業者ＩＤ」、「２．携帯番号」、「３．ＳＭＳ本文」、「４．認証情報」、「５．品名」、「６．使用量」、「７．請求金額」、「８．決済手段」、「９．送信日時」、「１０．ＵＲＬアクセス条件」、及び「１１．備考」」を有するところ、このうち、「「２．携帯番号」」、「「４．認証情報」」はそれぞれ、構成要件Ｅの「前記携帯端末の携帯番号」、「前記ユーザ本人であるかを確認する確認情報」に相当する。 また、前記（ａ）を参酌すれば、「請求データ」（及び、「管理請求データ」）の「「６．使用量」、「７．請求金額」、「８．決済手段」、「１１．備考」」等から「お知らせ画面」の内容を生成するものであるところ、「「６．使用量」、「７．請求金額」、「８．決済手段」、「１１．備考」」と、構成要件Ｅの「前記ユーザ用画面に誘導するユーザ用画面のＵＲＬ」とは、“ユーザ用画面に関する情報”である点において共通する。 よって、甲１発明において、「請求データ」（及び、「管理請求データ」）が、「「２．携帯番号」」と「「４．認証情報」」を有することと、構成要件Ｅの「前記ユーザ情報は、前記携帯端末の携帯番号と、前記ユーザ用画面に誘導するユーザ用画面のＵＲＬと、前記ユーザ本人であるかを確認する確認情報と、を含」むこととは、「前記ユーザ情報は、前記携帯端末の携帯番号と、前記ユーザ用画面に関する情報と、前記ユーザ本人であるかを確認する確認情報と、を含」む点において共通する。 （ｆ１）構成要件Ｆ及びＦ１について 甲１発明は、 「管理サーバ２０は管理請求データの送信日時の情報に従い送信するタイミングになったら、ＳＭＳ本文と固有ＵＲＬからなるＳＭＳ文書をＳＭＳ送信手段により送信し、この送信はＳＭＳによる送信であり、その際に、管理サーバ２０は請求データ中の携帯番号に向けて適当なキャリア３０へ呼設定メッセージを送信する、すなわち、発呼し、切断メッセージ等の返信を受け、切断メッセージ等から携帯端末４０が接続されるキャリア３０を特定してキャリア情報とし、そのキャリア情報に従って携帯端末４０が接続されるキャリア３０に向けてＳＭＳ文書を送信し、 キャリア３０は、携帯端末４０へ携帯電話回線を介してＳＭＳ文書を送信し、 ＳＭＳ文書を見た携帯端末４０の所有者が、確認のために固有ＵＲＬに触れるＵＲＬ選択操作をすると、携帯端末４０はネット用回線を介して固有ＵＲＬにアクセスしようとし、キャリア３０から管理サーバ２０へはインターネットを介して固有ＵＲＬが送られ、 管理サーバ２０は、ＵＲＬアクセス条件チェックを行い、ＵＲＬアクセス条件を満たしている場合には、通常のＵＲＬにアクセスして、ネット用回線を介して携帯端末４０にログイン画面を表示し、ここで認証コードを入力すると、ネット用回線を介して管理サーバ２０へ送られ、 管理サーバ２０は管理請求データの認証情報と認証コードを照合して確認し、認証されると、管理サーバ２０に記憶された管理請求データの「６．使用量」、「７．請求金額」、「８．決済手段」、「１１．備考」等からお知らせ画面の内容を生成し、ネット用回線を介して携帯端末４０に送信して、携帯端末４０はお知らせ画面表示を行う、」との構成（以下、「構成Ｘ」という。）を備えるところ、 構成Ｘのうち、「送信するタイミングになったら」と、構成要件Ｆ１の「前記携帯番号の利用履歴が条件をクリアしている場合」とは、「所定の条件をクリアしている場合」である点において共通する。 また、構成Ｘのうち、「管理サーバ２０」が「ＳＭＳによる送信」により「携帯端末４０が接続されるキャリア３０に向けてＳＭＳ文書を送信」することは、「携帯端末４０」の「２．携帯番号」宛てに、「固有ＵＲＬ」を含む（付加した）「ＳＭＳ文書」を送信することに他ならず、また、送信される「ＳＭＳ文書」は、後述する相違点を除いて、構成要件Ｆ１の「ＳＭＳメール」に相当する。 ここで、本件特許発明１の「ＳＭＳメール」に付加した「前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報」は、「アクセスするためのアクセス情報」ではなく、「アクセスするアクセス情報」とされていることからすると、文言上、本件特許発明１の「アクセス情報」とは、「前記携帯端末」がこれを使用することによって、上記「サイト」に「アクセスする」情報であると解される。また、本願明細書の段落００６０等によると、上記「アクセス情報」の例として、「本人確認を行うＷｅｂアプリケーションのサイト」のネットワーク上のアドレスを示す「ＵＲＬ「ｈｔｔｐｓ：//ＸＸＸ．ｊｐ/ＸＸＸ」が記載されているところ、ＵＲＬは、携帯端末がこれを使用することによって当該ＵＲＬの示すサイトに「アクセスするアクセス情報」といえるから、上記解釈は、本願明細書の記載と整合するものである。一方、本願明細書には、「アクセス情報」が、所定のサイトにアクセスすることに関するいかなる情報をも含み得ることを示す事項は記載も示唆もない。 これに対し、甲１発明の「ＳＭＳ文書」に付加した「固有ＵＲＬ」は、「携帯端末４０」が、「固有ＵＲＬ」によって示されるサイトにアクセスして、ＵＲＬアクセス条件をチェックするためものであり、「携帯端末４０」が「固有ＵＲＬ」を使用することによって、当該ＵＲＬアクセス条件をチェックするサイトにアクセスする情報といえるから、「所定の処理を実行するサイトにアクセスするアクセス情報」であるといえる。しかし、ＵＲＬアクセス条件のチェックは、「期限日時」「決済完了」「請求猶予」などの請求に係るチェックを行うものであって、「本人確認」とは異なる技術的意義を有するものであること、及び、上記ＵＲＬアクセス条件を満たす場合には、結果として「通常のＵＲＬ」にアクセスして、「ログイン画面を表示し、認証情報と入力された認証コードを照合して確認」するという本人確認に係る処理を行っているといえるものの、ＵＲＬアクセス条件を満たさない場合には、「通常のＵＲＬ」にアクセスしないから、甲１発明の「固有ＵＲＬ」は、「携帯端末４０」が「本人確認を行うサイトにアクセスするアクセス情報」であるとはいえない。 よって、甲１発明のＳＭＳ文書に付加した「固有ＵＲＬ」と、本件特許発明１のＳＭＳメールに付加した「前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報」とは、「所定の処理を実行するサイトにアクセスする情報」である点において共通するといえる。 以上によると、甲１発明において、「管理サーバ２０」が「携帯端末４０が接続されるキャリア３０に向けてＳＭＳ文書を送信」することと、構成要件Ｆ及びＦ１において、「前記認証装置は、」「前記携帯番号の利用履歴が条件をクリアしている場合、前記携帯端末宛に、前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報を付加したＳＭＳメールを送信する処理」を行うこととは、「前記認証装置は、」「所定の条件をクリアしている場合、前記携帯端末宛に、所定の処理を実行するサイトにアクセスする情報を付加したＳＭＳメールを送信する処理」を行うことである点において共通する。 （ｆ２）構成要件Ｆ及びＦ２について 構成Ｘのうち、「通常のＵＲＬ」にアクセスして、ログイン画面を表示し、認証情報と入力された認証コードを照合して確認し、認証することは、「通常のＵＲＬ」のアクセス先のサイトにアクセスし、当該サイトに入力された入力情報と前記確認情報が一致することで、本人確認を行うものであるから、「通常のＵＲＬ」のアクセス先のサイトは、「本人確認」を行うためのサイトであるといえる。 そして、構成要件Ｆ２の「前記サイトにアクセスして入力された入力情報と前記確認情報が一致し、本人確認できた場合」との事項における「前記サイト」とは、「前記本人確認を行うＷｅｂアプリケーションのサイト」であると解されるところ、甲１発明の「通常のＵＲＬ」にアクセスして、ログイン画面を表示し、認証情報と入力された認証コードを照合して確認し、認証した場合と、構成要件Ｆ２の「前記サイトにアクセスして入力された入力情報と前記確認情報が一致し、本人確認できた場合」とは、「本人確認を行うサイトにアクセスして入力された入力情報と前記確認情報が一致し、本人確認できた場合」である点で共通する。 また、構成Ｘにおいて、「お知らせ画面の内容を生成し、ネット用回線を介して携帯端末４０に送信」することは、「携帯端末４０」に対して、「お知らせ画面」を表示する指示を行っているといえ、また、構成Ｘにおいて、「携帯端末４０はお知らせ画面表示を行う」ことは、「携帯端末４０」に「お知らせ画面」を表示させることにより、当該「携帯端末４０」に誘導しているといえる。 また、構成Ｘにおいて、「お知らせ画面」と、構成要件Ｆ２の「前記事業者装置が提供するＷｅｂ画面」とは、「所定の画面」である点において共通する。 よって、構成Ｘにおいて、「管理サーバ２０」が「管理サーバ２０に記憶された管理請求データの「６．使用量」、「７．請求金額」、「８．決済手段」、「１１．備考」等からお知らせ画面の内容を生成し、ネット用回線を介して携帯端末４０に送信して、携帯端末４０はお知らせ画面表示を行う」ことと、構成要件Ｆ２の「前記事業者装置が提供するＷｅｂ画面を携帯端末に表示させる指示を行うことで、前記携帯端末を前記ユーザ用画面に誘導する」こととは、「前記認証装置は、」「所定の画面を携帯端末に表示させる指示を行うことで、前記携帯端末を前記ユーザ用画面に誘導する」ことである点において共通する。 したがって、構成Ｘにおいて、「管理サーバ２０は、「通常のＵＲＬ」にアクセスして、ログイン画面を表示し、管理請求データの認証情報と認証コードを照合して確認し、認証されると、管理サーバ２０に記憶された管理請求データの「６．使用量」、「７．請求金額」、「８．決済手段」、「１１．備考」等からお知らせ画面の内容を生成し、ネット用回線を介して携帯端末４０に送信して、携帯端末４０はお知らせ画面表示を行う」ことと、構成要件Ｆ及びＦ２の「前記認証装置は、」「前記サイトにアクセスして入力された入力情報と前記確認情報が一致し、本人確認できた場合、前記ユーザ用画面のＵＲＬに基づいて、前記事業者装置が提供するＷｅｂ画面を携帯端末に表示させる指示を行うことで、前記携帯端末を前記ユーザ用画面に誘導する処理」を行うこととは、「前記認証装置は、」「本人確認を行うサイトにアクセスして入力された入力情報と前記確認情報が一致し、本人確認できた場合、所定の画面を携帯端末に表示させる指示を行うことで、前記携帯端末を前記ユーザ用画面に誘導する処理」を行うことである点において共通する。 イ．一致点、相違点 上記アによると、本件特許発明１と甲１発明とは、以下の点において一致し、また、相違する。 （ア）一致点 「ユーザを前記ユーザのためのユーザ用画面に案内する案内システムであって、 前記案内システムは、 ユーザが所持し、ネットワークに接続可能な携帯端末と、 前記ネットワークに接続可能な事業者の事業者装置と、 前記事業者装置が提供するユーザ情報に基づいて、本人確認するとともに前記携帯端末をユーザ用画面に誘導する、前記ネットワークに接続可能なサービス事業者の認証装置と、を備え、 前記ユーザ情報は、 前記携帯端末の携帯番号と、 前記ユーザ用画面に関する情報と、 ユーザ本人であるかを確認する確認情報と、を含み、 前記認証装置は、 所定の条件をクリアしている場合、前記携帯端末宛に、所定の処理を実行するサイトにアクセスするアクセス情報を付加したＳＭＳメールを送信する処理と、 本人確認を行うサイトにアクセスして入力された入力情報と前記確認情報が一致し、本人確認できた場合、所定の画面を携帯端末に表示させる指示を行うことで、前記携帯端末を前記ユーザ用画面に誘導する処理と、 を行うことを特徴とする 案内システム。」 （イ）相違点 ａ．相違点１－１ 本件特許発明１における「ユーザ用画面」は、「事業者が提供する」ものであるのに対し、甲１発明における「お知らせ画面」は、提供する者が特定されていない点。 ｂ．相違点１－２ 本件特許発明１において、「ユーザ情報」が「前記ユーザ用画面に誘導するユーザ用画面のＵＲＬ」を含むのに対し、甲１発明の「請求データ」（及び、「管理請求データ」）は、「お知らせ画面」（ユーザ用画面）に誘導するＵＲＬを含まない点。 ｃ．相違点１－３ 「ＳＭＳメールを送信する」契機となる条件が、本件特許発明１においては、「前記携帯番号の利用履歴が条件をクリアしている場合」であるのに対し、甲１発明においては、「送信するタイミングになったら」である点。 ｄ．相違点１－４ 本件特許発明１での「本人確認を行うためのサイト」は、「前記本人確認を行うＷｅｂアプリケーションのサイト」あるのに対して、甲１発明では、「通常のＵＲＬ」のアクセス先のサイトである点。 ｅ．相違点１－５ 「前記携帯端末を前記ユーザ用画面に誘導する」ために、本件特許発明１においては、「本人確認を行うサイト（前記本人確認を行うＷｅｂアプリケーションのサイト）にアクセスするアクセス情報」を付加したＳＭＳメールを送信し、「本人確認を行うサイトにアクセスして入力された入力情報と前記確認情報が一致し、本人確認できた場合」を条件とするのに対し、甲１発明においては、ＵＲＬアクセス条件をチェックするサイトにアクセスする「固有ＵＲＬ」を付加した「ＳＭＳ文書」(ＳＭＳメール）を送信し、ＵＲＬアクセス条件をチェックするサイトにアクセスして、ＵＲＬアクセス条件をチェックし、当該ＵＲＬ条件を満たす場合に、「本人確認を行うサイト（通常ＵＲＬのアクセス先のサイト）にアクセスして入力された入力情報と前記確認情報が一致し、本人確認できた場合」を条件とする点。 ｆ．相違点１－６ 「本人確認できた場合」に、本件特許発明１においては、「前記ユーザ用画面のＵＲＬに基づいて、前記事業者装置が提供するＷｅｂ画面を携帯端末に表示させる指示を行う」のに対し、甲１発明においては、「お知らせ画面」の内容を生成して「携帯端末４０」に送信し、「お知らせ画面」を表示させる点。 ウ．相違点についての判断 事案に鑑みて、まず、相違点１－５、１－６について検討する。 （ア）相違点１－５ 甲１発明における「固有ＵＲＬ」が示すサイトは、ＵＲＬアクセス条件によって「期限日時」「決済完了」「請求猶予」などの請求に係るチェックを行うためのサイトであって、「本人確認を行う」ことと「請求に係るチェックを行う」こととは、その目的や作用が異なるものであるところ、上記「請求に係るチェックを行う」ことを行うサイトを示す「固有ＵＲＬ」にかえて、目的や作用が異なる「前記本人確認を行うためのＷｅｂアプリケーションのサイト」を示す「アクセス情報」を採用すべき動機付けは認められない。 さらに、ガス料金などの料金の請求を行う際に、「期限日時」「決済完了」「請求猶予」などの請求に係るチェックを行う必要があることは、本願出願時の技術常識であるところ、仮に上記動機付けがあるとしても、上記「固有ＵＲＬ」にかえて、「前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報」を採用した場合には、請求に係るチェックを行うことができないものとなることからすると、当該「…アクセス情報」を採用することには、阻害要因が存在するといえる。 したがって、甲１発明の「ＳＭＳ文書」に付加した、ＵＲＬアクセス条件をチェックするサイトにアクセスする「固有ＵＲＬ」は、本件特許発明１の「ＳＭＳメール」に付加した、「前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報」に相当するものではなく、また、上記「固有ＵＲＬ」にかえて、「前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報」を採用することは、当業者が容易に発明をすることができたものではない。 また、甲２発明ないし甲６発明、甲８発明、甲１１、１２に記載された周知技術には、「ＳＭＳメール」に「前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報」を付加することは記載されておらず、甲１発明、及び、甲２発明ないし甲６発明、甲８発明、甲１１、１２に記載された周知技術に基づいて、上記「固有ＵＲＬ」を、「前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報」とすることは、当業者が容易に発明することができたものとはいえない。 よって、相違点１－５に係る本件特許発明１の構成は、甲１発明、及び、甲２発明ないし甲６発明、甲８発明、甲１１、１２に記載された周知技術に基づいて、当業者が容易に発明することができたものとはいえない。 （イ）相違点１－６ 甲１の段落００５０には、「管理サーバ２０で記憶しているが、お知らせ画面等を事業者サーバ１０で記憶してもよい。その場合には、お知らせ画面等のＵＲＬを管理サーバ２０の管理請求データとして記憶し、固有ＵＲＬへのアクセスから事業者サーバ１０で記憶したお知らせ画面等のＵＲＬへ移送する。」との記載されているところ、甲１発明において、上記段落００５０の構成を適用した場合、「お知らせ画面等を事業者サーバ１０で記憶」し、「管理サーバ２０」が「お知らせ画面等のＵＲＬを管理サーバ２０の管理請求データとして記憶し、固有ＵＲＬへのアクセスから事業者サーバ１０で記憶したお知らせ画面等のＵＲＬへ移送する」ことで、「事業者サーバ」が「お知らせ画面」を提供するようにすること、及び、その際に、事業者サーバ１０で記憶したお知らせ画面等のＵＲＬへ移送するために、事業者サーバ１０で記憶したお知らせ画面等のＵＲＬを、管理サーバ２０がユーザ情報として記憶する、との構成を備えるもの（以下、「甲１適用構成」という。）とすることは、当業者にとって容易に想到できたことであるといえる。 しかしながら、本件特許発明１においては、「認証装置」が、「前記サイトにアクセスして入力された入力情報と前記確認情報が一致し」、「本人確認できた」と判断した場合に、「前記ユーザ用画面に誘導する」処理を行うものであるのに対して、上記甲１適用構成は、「管理サーバ２０」が「固有ＵＲＬへのアクセスから事業者サーバ１０で記憶したお知らせ画面等のＵＲＬへ移送する」ものであって、この処理は、管理サーバ２０（「認証装置」）において、「本人確認できた」と判断した場合になされることが特定されているとはいえない。 ここで、甲４発明は、ユーザ認証を行うために、認証サーバ４００及び認証支援サーバ５００（「前記本人確認を行うＷｅｂアプリケーションのサイト」）が、予め記憶されたユーザ認証情報を用いて認証が成功するとサービス提供事業者サーバ２００のＵＲＬを携帯電話端末に送信するものであるところ、甲１発明に甲１の段落００５０の構成を適用した甲１適用構成に対して、さらに当該甲４発明の構成を適用することは、当業者といえども容易に想到し得ることではない。加えて、仮に上記適用をしたとして、外部の「認証サーバ４００及び認証支援サーバ５００」によって、予め記憶された「確認情報」を用いて既に認証している以上、さらに「管理サーバ２０」において「本人確認できた」ことを判断するべき理由はないから、直接「事業者サーバ１０で記憶したお知らせ画面等のＵＲＬへ移送する」ように構成されるものとするのが相当であり、本件特許発明１に至るとはいえない。 甲１発明に甲６発明を適用する場合についても、甲１発明を甲１適用構成とした上で、さらに甲６発明を適用することは、当業者といえども容易に想到し得ることではない。加えて、甲６発明には、そのシステムを構成するサーバ、及び、各サーバの機能について特定されていないことから、仮に上記適用をしたとしても、「管理サーバ２０」において、「前記サイトにアクセスして入力された入力情報と前記確認情報が一致し」、「本人確認できた」と判断した場合に、「事業者サーバ１０で記憶したお知らせ画面等のＵＲＬへ移送する」ことは、当業者が容易に発明することができたものとはいえない。 そして、その他の甲号証にも、相違点１－６に係る本件特許発明１の構成について開示されているとはいえない。 以上のとおりであるから、上記相違点１－６に係る本件特許発明１の構成は、甲１ないし甲６、甲８に記載された事項、及び、甲１１、１２に記載された周知技術に基づいて、当業者が容易に発明することができたものとはいえない。 なお、仮に、甲１の段落００５０の記載に基づいて、甲１発明の「管理サーバ２０」を、「固有ＵＲＬのアクセス先にアクセスし、ＵＲＬアクセス条件を満たしている場合には、通常のＵＲＬにアクセスして、携帯端末４０にログイン画面を表示する処理を実行し、本人確認できた場合」に、「事業者サーバ１０で記憶したお知らせ画面等のＵＲＬへ移送する」ことが、容易に想到できたことであるとしても、当該仮定した事項に加えて、ＳＭＳメールの「固有ＵＲＬ」を「前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報」とし、「管理サーバ２０」において、上記本人確認できた場合に、「事業者サーバ１０で記憶したお知らせ画面等のＵＲＬへ移送する」ように構成することは、当業者が容易に発明することができたものとはいえない。 （ウ）小括 上記（ア）、（イ）のとおりであるから、相違点１－１ないし１－４については検討するまでもなく、本件特許発明１は、甲１発明、甲１ないし甲６、甲８に記載された事項、及び、甲１１、１２に記載された周知技術に基づいて、当業者が容易に発明することができたものとはいえない。 （２）本件特許発明２ 本件特許発明２は、本件特許発明１の特定事項を全て備えるものであって、さらに「確認情報」について「前記ユーザ本人であるかを確認するための情報として複数の認証キーを含む」点を限定したものであるため、上記（１）と同様の理由により、甲１発明、甲１ないし甲６、甲８に記載された事項、及び、甲１１、１２に記載された周知技術に基づいて、当業者が容易に発明することができたものとはいえない。 （３）本件特許発明３ 本件特許発明３は、上記（１）イで説示した相違点１－１ないし１－６に係る本件特許発明１の特定事項を備える「認証装置」であるから、上記（１）と同様の理由により、甲１発明、甲１ないし甲６、甲８に記載された事項、及び、甲１１、１２に記載された周知技術に基づいて、当業者が容易に発明することができたものとはいえない。 （４）本件特許発明４ないし５ 本件特許発明４及び５は、本件特許発明１の「案内システム」を「方法」及び「プログラム」としたものであって、上記（１）イで説示した相違点１－１ないし１－６に係る本件特許発明１の特定事項を備えるものであるから、上記（１）と同様の理由により、甲１発明、甲１ないし甲６、甲８に記載された事項、及び、甲１１、１２に記載された周知技術に基づいて、当業者が容易に発明することができたものとはいえない。 ４．無効理由２について （１）本件特許発明１ ア．本件特許発明１と甲５発明との対比 本件特許発明１と甲５発明とを対比すると、以下のとおりである。 （ａ）構成要件Ａについて 甲５発明において、「情報管理システム１」は、「情報管理サーバ１０」と「ユーザ端末２０」と「カスタマ端末３０」と「金融機関端末４０」とを備えるものである。 また、甲５発明において、「カスタマ端末３０」を使用する「顧客」は、構成要件Ａの「ユーザ」に相当する。 また、甲５発明において、「情報管理サーバ１０」が「カスタマ端末３０」に送信して表示させる「事前審査の回答閲覧画面」は、前記「顧客」が、自らが申請した「事前審査」についての回答を閲覧する画面であるから、構成要件Ａの「前記ユーザのためのユーザ用画面」に相当する。 また、「情報管理サーバ１０」は、「申請画面」を「カスタマ端末３０」に送信して表示させることにより、「カスタマ端末３０」を使用する「顧客」を「事前審査の回答閲覧画面」に“案内”しているといえ、そのような「情報管理サーバ１０」を含む「情報管理システム１」も、“案内”をするシステムといい得るものである。 よって、甲５発明の「情報管理システム１」と、構成要件Ａの「ユーザを事業者が提供する前記ユーザのためのユーザ用画面に案内する案内システム」とは、後述する相違点を除いて、「ユーザを前記ユーザのためのユーザ用画面に案内する案内システム」である点において共通する。 （ｂ）構成要件Ｂについて 甲５発明において、「情報管理サーバ１０と、ユーザ端末２０と、カスタマ端末３０と、金融機関端末４０とは、通信ネットワークＮを介して接続」されているところ、「カスタマ端末３０」は「通信ネットワークＮ」に接続可能といえる。 また、甲５発明の「通信ネットワークＮ」は、構成要件Ｂの「ネットワーク」に相当する。 また、甲５発明の「カスタマ端末３０」は、「タブレット端末、パーソナルコンピュータ（ＰＣ）、ノートＰＣ、スマートフォン、携帯電話機、ＰＤＡ等」であるところ、「タブレット端末」、「スマートフォン」、「携帯電話機」などの携帯型の端末であってもよいと理解できるから、構成要件Ｂの「携帯端末」に相当する場合を含む。 また、甲５発明において、「カスタマ端末３０」は、「顧客」が所持するものであることは明らかである。 よって、甲５発明において、「情報管理システム１」が備える「カスタマ端末３０」は、構成要件Ｂの「前記ユーザが所持し、ネットワークに接続可能な携帯端末」に相当する。 （ｃ）構成要件Ｃについて 甲５発明において、「ユーザ端末２０」は、「不動産会社」という「事業者」において使用されるものであって、「不動産会社」は、不動産の販売・貸借を仲介等するサービスを提供する事業者であるところ、“サービス事業者の事業者装置”といい得るものである。 また、前記（ｂ）を参酌すれば、「ユーザ端末２０」は、「通信ネットワークＮ」に接続可能といえる。 よって、甲５発明において、「情報管理システム１」が備える「ユーザ端末２０」は、構成要件Ｃの「前記ネットワークに接続可能なサービス事業者の事業者装置」に相当する。 （ｄ）構成要件Ｄについて 甲５発明の「ステップＳ１００」において、「ユーザ端末２０」から「情報管理サーバ１０」に送信される「申込情報」には、「顧客の本人確認」に使用される「氏名、電話番号、および生年月日の３つの情報」すなわち「本人確認情報」が含まれている。 そして、甲５発明の「ステップＳ２００」において、「情報管理サーバｌ０」の「本人確認管理部１３３」は、「カスタマ端末３０」に対し、前記「本人確認情報」の入力を要求し、登録済みの「本人確認情報」と一致するか否かを判定することにより「本人確認」を行うものと認められる。 ここで、甲５発明の「氏名、電話番号、および生年月日の３つの情報」すなわち「本人確認情報」を含む「申込情報」は、構成要件Ｄの「前記事業者装置が提供するユーザ情報」に相当し、甲５発明において、「申込情報」に基づいて「本人確認」をすることは、構成要件Ｄの「前記事業者装置が提供するユーザ情報に基づいて、本人確認する」ことに相当する。 また、前記（ｂ）を参酌すれば、「情報管理サーバ１０」は、「通信ネットワークＮ」に接続可能といえる。 また、甲５発明の「情報管理サーバ１０」は「事前審査の申込情報を管理する」ものであり、その管理・運営を行う者を、“サービス事業者”と称することは任意である。また、甲５発明の「情報管理サーバ１０」は、前記「本人確認」に係る機能を有しているところ、“認証装置”ともいい得るものである。 よって、甲５発明において、「情報管理システム１」が備える「情報管理サーバ１０」と、構成要件Ｄの「前記事業者装置が提供するユーザ情報に基づいて、本人確認するとともに前記携帯端末を前記ユーザ用画面に誘導する、前記ネットワークに接続可能なサービス事業者の認証装置」とは、「前記事業者装置が提供するユーザ情報に基づいて、本人確認する、前記ネットワークに接続可能なサービス事業者の認証装置」である点において共通する。 （ｅ）構成要件Ｅについて 甲５発明において、「ユーザ端末２０」から「情報管理サーバ１０」に送信される「申込情報」に含まれる「氏名、電話番号、および生年月日の３つの情報」すなわち「本人確認情報」は、構成要件Ｅの「前記ユーザ本人であるかを確認する確認情報」に相当する。 よって、甲５発明において、「申込情報」が「氏名、電話番号、および生年月日の３つの情報」すなわち「本人確認情報」を含むことと、構成要件Ｅの「前記ユーザ情報は、前記携帯端末の携帯番号と、前記ユーザ用画面に誘導するユーザ用画面のＵＲＬと、前記ユーザ本人であるかを確認する確認情報と、を含」むこととは、「前記ユーザ情報は、前記ユーザ本人であるかを確認する確認情報、を含」む点において共通する。 （ｆ１）構成要件Ｆ１について 甲５発明において、「情報管理サーバ１０」は、「ステップＳ１００」において、「ユーザ端末２０」から「申込情報」を受信して登録したとの条件を満たした場合に、「申込情報が登録された旨と、当該申込情報による事前審査の申請画面にアクセスするためのＵＲＬとが記載されたメールを、顧客のメールアドレスに送信」するものと認められる。 ここで、甲５発明において、「ユーザ端末２０」から「申込情報」を受信して登録したとの条件を満たした場合と、構成要件Ｆ１の「前記携帯番号の利用履歴が条件をクリアしている場合」とは、「所定の条件をクリアしている場合」である点において共通する。 また、甲５発明の「ステップＳ２００」において、「カスタマ端末３０が、情報管理サーバ１０から送信されたメールに記載されたＵＲＬにアクセスすると、情報管理サーバ１０は、本人確認画面を送信してカスタマ端末３０に表示させ、本人確認情報を要求」するところ、「ステップＳ１００」において「情報管理サーバ１０から送信されたメールに記載されたＵＲＬ」は「本人確認画面」の場所（サイト）にアクセスする“アクセス情報”といい得るものである。 そして、甲５発明の上記「本人確認画面」の場所（サイト）と構成要件Ｆ１の「前記本人確認を行うＷｅｂアプリケーションのサイト」とは、「前記本人確認を行うサイト」である点において共通する。 そうすると、甲５発明の「ステップＳ１００」において送信される、前記「ＵＲＬ」が記載（付加）された「メール」と、「前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報を付加したＳＭＳメール」とは、「前記本人確認を行うサイトにアクセスするアクセス情報を付加したメール」である点において共通する。 加えて、「ステップＳ１００」の後、「ステップＳ２００」において、「カスタマ端末３０が、情報管理サーバ１０から送信されたメールに記載されたＵＲＬにアクセスする」処理を実行しているところ、「ステップＳ１００」において、「情報管理サーバ１０」が「メール」を「顧客のメールアドレス」に送信することは、「カスタマ端末３０」宛に前記「メール」を送信することに他ならない。 よって、甲５発明の「ステップＳ１００」において、「情報管理サーバ１０」が前記「ＵＲＬ」が記載（付加）された「メール」を「顧客のメールアドレス」に送信する処理と、構成要件Ｆ及びＦ１において、「前記認証装置は、」「前記携帯番号の利用履歴が条件をクリアしている場合、前記携帯端末宛に、前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報を付加したＳＭＳメールを送信する処理」を行うこととは、「前記認証装置は、」「所定の条件をクリアしている場合、前記携帯端末宛に、前記本人確認を行うサイトにアクセスするアクセス情報を付加したメールを送信する処理」を行う点において共通する。 （ｆ２）構成要件Ｆ及びＦ２について 甲５発明の「情報管理サーバ１０」は、「ステップＳ２００」において「本人確認画面を送信してカスタマ端末３０に表示させ、本人確認情報を要求し、本人確認」する処理を行うものであるところ、上記処理と、構成要件Ｆ及びＦ２における「前記認証装置は、」「前記サイトにアクセスして入力された入力情報と前記確認情報が一致し、本人確認できた場合、前記ユーザ用画面のＵＲＬに基づいて、前記事業者装置が提供するＷｅｂ画面を携帯端末に表示させる指示を行うことで、前記携帯端末を前記ユーザ用画面に誘導する処理」とは、「前記サイトにアクセスして入力された入力情報と前記確認情報が一致し、本人確認する処理」である点において共通する。 イ．一致点、相違点 上記（１）によると、本件特許発明１と甲５発明とは、以下の点において、一致し、また、相違する。 （ア）一致点 「ユーザを前記ユーザのためのユーザ用画面に案内する案内システムであって、 前記案内システムは、 ユーザが所持し、ネットワークに接続可能な携帯端末と、 前記ネットワークに接続可能なサービス事業者の事業者装置と、 前記事業者装置が提供するユーザ情報に基づいて、本人確認する、前記ネットワークに接続可能なサービス事業者の認証装置とを備え、 前記ユーザ情報は、前記ユーザ本人であるかを確認する確認情報を含み、 前記認証装置は、 所定の条件をクリアしている場合、前記本人確認を行うサイトにアクセスするアクセス情報を付加したメールを送信する処理と、 前記サイトにアクセスして入力された入力情報と前記確認情報が一致し、本人確認する処理と、 を行うことを特徴とする 案内システム。」 （イ）相違点 ａ．相違点２－１ 本件特許発明１では、「ユーザ用画面」が「事業者が提供する」ものであるのに対し、甲５発明ではそのような特定はされていない点。 ｂ．相違点２―２ 本件特許発明１では、「前記ユーザ情報」は、「前記携帯端末の携帯番号と、前記ユーザ用画面に誘導するユーザ用画面のＵＲＬ」を含むのに対し、甲５発明にはそのような特定がない点。 ｃ．相違点２－３ 本件特許発明１では、「前記携帯番号の利用履歴が条件をクリアしている場合」に「ＳＭＳメール」を送信するのに対し、甲５発明においては、「ユーザ端末２０」から「申込情報」を受信して登録したことを条件として、「メール」を送信する点。 ｄ．相違点２－４ 本件特許発明１では、「認証装置」は、「前記事業者装置が提供するユーザ情報に基づいて、本人確認するとともに前記携帯端末を前記ユーザ用画面に誘導する」のに対して、甲５発明では、「前記事業者装置が提供するユーザ情報に基づいて、本人確認する」とともに「申請画面」を「カスタマ端末３０」に送信して表示させるものである点。 ｅ．相違点２－５ 「本人確認を行うサイト」が、本件特許発明１においては、「Ｗｅｂアプリケーションのサイト」であるのに対し、甲５発明においては、「本人確認画面」の場所（サイト）である点。 ｆ．相違点２－６ 「本人確認できた場合」に、本件特許発明１においては、「前記ユーザ用画面のＵＲＬに基づいて、前記事業者装置が提供するＷｅｂ画面を携帯端末に表示させる指示を行う」のに対し、甲５発明においては、「情報管理サーバ１０」が提供する「申請画面」を「カスタマ端末３０」に送信して表示させる点。 ウ．相違点についての判断 事案に鑑みて、まず、相違点２－３、２－６について検討する。 （ア）相違点２－３ 甲２発明及び甲３発明にあるように、携帯端末の携帯番号の利用履歴が所定の条件をクリアしている場合に、前記携帯端末宛にＳＭＳメールを送信するＳＭＳ送信装置は、本件特許出願時における公知技術であると認められる。 ここで、甲２発明及び甲３発明は、所定の電話番号に対して、定期的に発呼してその結果を取得し、所定期間蓄積した使用履歴情報を用いることにより、当該電話番号が有効性を判定するものといえる。 一方で、甲５発明の「カスタマ端末３０」は、「タブレット端末、パーソナルコンピュータ（ＰＣ）、ノートＰＣ、スマートフォン、携帯電話機、ＰＤＡ等」が例示されているに留まり、ＳＭＳメールを送受信可能であることが明らかな端末、すなわち、「スマートフォン」又は「携帯電話機」に限定されていないことからすると、甲５発明から相違点２－３に係る本件特許発明１の構成に到達するためには、まず、甲５発明に係る「カスタマ端末３０」として、「ＳＭＳメール」を送受信可能な「スマートフォン」又は「携帯電話機」に特定し、かつ、「情報管理サーバ１０」が送信する「メール」を「スマートフォン」又は「携帯電話機」が送受信可能なインターネットを介したメールではなく、「ＳＭＳメール」に限定した上で、さらに、「情報管理サーバ１０」について、上記所定の電話番号に対して、定期的に発呼してその結果を取得し、所定期間蓄積した使用履歴情報を用いることにより、当該電話番号が有効性を判定するという公知技術を適用しなければならない。 そうすると、当業者といえども、このような複数段階の変更を想起することが容易であるとはいえない。 そして、その他の甲号証にも、相違点２－３に係る本件特許発明１の構成について開示されているとはいえない。 したがって、当業者といえども、甲５発明から、相違点２－３に係る本件特許発明１の構成に到達することが容易であるとはいえない。 （イ）相違点２－６ 甲１の段落００５０には、「管理サーバ２０で記憶しているが、お知らせ画面等を事業者サーバ１０で記憶してもよい。その場合には、お知らせ画面等のＵＲＬを管理サーバ２０の管理請求データとして記憶し、固有ＵＲＬへのアクセスから事業者サーバ１０で記憶したお知らせ画面等のＵＲＬへ移送する。」と記載されている。また、甲４発明は、認証に成功した場合、事業者装置であるサービス提供事業者サーバ２００にリダイレクトして、所定のサービスを提供する構成を有するものといえる。 これに対し、甲５の段落００４４によると、甲５発明における「事業者装置」である「ユーザ端末２０」は、情報管理サーバに対して申込情報の登録処理を行うために、不動産会社の店頭において操作する端末であって、情報の入出力を行う装置であると解されるところ、ネットワークを介してカスタマ端末３０に申請画面を提供する、あるいは、認証が成功した場合に「ユーザ端末２０」にリダイレクトしてサービスを提供させる等のサーバとしての機能を想定したものとはいえない。 そうすると、甲５発明において、上記甲１に記載された事項、あるいは、甲４発明の構成を採用すべき、動機付けは認められない。 また、仮に上記動機付けがあったとしても、金融機関の金融機関端末４０によって提供される回答に基づく「ユーザ用画面」（「事前審査の回答閲覧画面」）を、異なる事業者である不動産会社の「ユーザ端末２０」が提供するようにすること、及び、「本人確認」を「管理サーバ２０」で行い、「ユーザ用画面」の提供を「ユーザ端末２０」において行うように役割分担することは、当業者といえども容易に発明することができたものとはいえない。 そして、その他の甲号証にも、相違点２－６に係る本件特許発明１の構成について開示されているとはいえない。 なお、本件特許発明１においては、「認証装置」が「本人確認できた」と判断した場合に、「前記ユーザ用画面に誘導する」処理を行うものであるところ、甲５発明における「ユーザ端末３０」によって提供される申請情報に基づく「申請画面」を、本件特許発明１の「ユーザ用画面」に相当するものと仮定して検討しても、上記の説示と同様であるから、上記仮定した構成において、上記甲１に記載された事項、あるいは、甲４発明の構成を採用すべき動機付けはなく、当該動機付けがあったとしても、「本人確認」を「管理サーバ２０」で行い、「ユーザ用画面」の提供を「ユーザ端末２０」において行うように役割分担することは、当業者といえども容易に発明することができたものとはいえない。よって、上記仮定した構成においても、上記相違点２－６に係る本件特許発明１の構成は、甲５発明に基づいて、当業者が容易に想到できたことではない。 したがって、当業者といえども、甲５発明から、相違点２－６に係る本件特許発明１の構成に到達することが容易であるとはいえない。 （ウ）小括 上記（ア）、（イ）のとおりであるから、相違点２－１、２－２、２－４、２－５については検討するまでもなく、本件特許発明１は、甲５発明、甲１ないし甲４、甲６、甲８に記載された事項、及び、甲１１、１２に記載された周知技術に基づいて、当業者が容易に発明することができたものとはいえない。 （２）本件特許発明２ 本件特許発明２は、本件特許発明１の特定事項を全て備えるものであって、さらに「確認情報」について「前記ユーザ本人であるかを確認するための情報として複数の認証キーを含む」点を限定したものであるため、上記（１）と同様の理由により、甲５発明、甲１ないし甲４、甲６、甲８に記載された事項、及び、甲１１、１２に記載された周知技術に基づいて、当業者が容易に発明することができたものとはいえない。 （３）本件特許発明３ 本件特許発明３は、上記（１）イで説示した相違点２－１ないし２－６に係る本件特許発明１の特定事項を備える「認証装置」であるから、上記（１）と同様の理由により、甲５発明、甲１ないし甲４、甲６、甲８に記載された事項、及び、甲１１、１２に記載された周知技術に基づいて、当業者が容易に発明することができたものとはいえない。 （４）本件特許発明４ないし５ 本件特許発明４及び５は、本件特許発明１の「案内システム」を「方法」及び「プログラム」としたものであって、上記（１）イで説示した相違点２－１ないし２－６に係る本件特許発明１の特定事項を備えるものであるから、上記（１）と同様の理由により、甲５発明、甲１ないし甲４、甲６、甲８に記載された事項、及び、甲１１、１２に記載された周知技術に基づいて、当業者が容易に発明することができたものとはいえない。 ５．請求人の主張について （１）請求人の主張 請求人は各無効理由について、以下の主張をしている。 ア．無効理由１について （ア）一致点（「…サイトにアクセスするアクセス情報」）について 「甲１発明は、「固有ＵＲＬ」によって管理サーバ２０にアクセスして、管理サーバ２０は、ＵＲＬアクセス条件をチェックし、ＵＲＬアクセス条件を満たしている場合には、ログイン画面を表示する、すなわち、本人確認します（甲第１号証図６、段落００４８）。そうすると、管理サーバ２０は、本人確認するサイトを提供すると解することができ、「固有ＵＲＬ」は、その本人確認するサイトにアクセスするアクセス情報に相当します。」（弁駁書第３頁、第４頁、上申書第３頁等） （イ）相違点１－５について 「甲１発明では、ＵＲＬアクセス条件を満たすと、ネット用回線を介して携帯端末４０にログイン画面を表示し、ここで認証コードを入力すると、ネット用回線を介して管理サーバ２０へ送られます。ＵＲＬアクセス条件は、段落００２４に記載されているように、所定の日時が過ぎたり、支払いが終了したりする場合に通常とは異なったＵＲＬにアクセスするなど、通常のＵＲＬにアクセスするか否かを決める条件です。そして、甲１発明ではＵＲＬアクセス条件というステップを介しているが、ＳＭＳで送ったＵＲＬは、最終的には暗証番号を求める認証を行うために用いられます。したがって、甲１発明において、ＵＲＬアクセス条件を外して直接的に認証を行うことは、当業者が容易になし得たことです。」（請求人陳述要領書第３頁、請求人上申書第６頁等） （ウ）相違点１－６について 「甲第１号証の００５０段落には、「お知らせ画面等を事業者サーバ１０で記憶してもよい。その場合には、お知らせ画面等のＵＲＬを管理サーバ２０の管理請求データとして記憶し、固有ＵＲＬへのアクセスから事業者サーバ１０で記憶したお知らせ画面等のＵＲＬへ移送する。」と記載されている。甲１発明は、認証後にお知らせ画面を送信するものであるから、「本人確認できた場合」に、本件特許発明１のように、「前記ユーザ用画面のＵＲＬに基づいて、前記事業者装置が提供するＷｅｂ画面を携帯端末に表示させる指示を行う」ことに進歩性はない。」（請求書第４０頁ないし第４１頁） イ．無効理由２について （ア）一致点（「事業者」、「事業者装置」）について 「甲５発明において、「情報管理システム１」が備える「ユーザ端末２０」及び「金融機関端末４０」と、構成要件Ｃの「前記ネットワークに接続可能なサービス事業者の事業者装置」とは、「前記ネットワークに接続可能な事業者の事業者装置」である点において共通する。」（請求書第４４頁ないし第４５頁） （イ）一致点（「本人確認」） 「また、甲５発明の「ステップＳ４００」において、「情報管理サーバ１０」が、「事前審査の回答閲覧画面」を「カスタマ端末３０」に送信して表示させることは、構成要件Ｄの「前記携帯端末を前記ユーザ用画面に誘導する」ことに相当する。」（請求書第４５頁） 「また、構成要件Ｆ２は、「本人確認できた場合」に遅滞なく「前記ユーザ用画面のＵＲＬに基づいて、前記事業者装置が提供するＷｅｂ画面を携帯端末に表示させる指示を行うことで、前記携帯端末を前記ユーザ用画面に誘導する処理」を行うものとは限定しておらず、そのように限定して解釈すべき事情があるとも認められない。 したがって、甲５発明において、…「本人確認に成功」した後、さらに、会員ＩＤおよびパスワードによる認証等の種々の処理を経た「ステップＳ４００」において、「事前審査の回答閲覧画面をカスタマ端末３０に送信して表示させる」処理を実行することと、構成要件Ｆ及びＦ２の「前記認証装置は、」「…本人確認できた場合、…前記携帯端末を前記ユーザ用画面に誘導する処理」を行うこととは、「前記認証装置は、」「前記サイトにアクセスして入力された入力情報と前記確認情報が一致し、本人確認できた場合、所定の画面を携帯端末に表示させる指示を行うことで、前記携帯端末を前記ユーザ用画面に誘導する処理」を行うことである点において共通する。」（請求書第４８頁） （２）請求人の主張に関する検討 上記請求人の主張について検討する。 ア．無効理由１について （ア）一致点（「…サイトにアクセスするアクセス情報」）について 上記（１）ア（ア）によると、請求人は、甲１発明において、「管理サーバ２０」は、「通常のＵＲＬ」によって示されるアクセス先であるから、本人確認するサイトを提供すると解することができ、「固有ＵＲＬ」は、当該「管理サーバ２０」にアクセスするものであるから、本人確認するサイトにアクセスするアクセス情報に相当するものである、と主張していると認められる。 ここで、甲１発明において、「固有ＵＲＬ」によって示されるサイトは、ＵＲＬ条件のチェックに係る機能手段を提供するものであり、また、「通常のＵＲＬ」によって示されるサイトは、本人確認の機能手段を提供するものであるといえる。そして、「サーバ」と「サイト」とは、必ずしも１対１に対応付けられるものではなく、１つのサーバに、それぞれが異なる機能手段を提供する複数のサイトを実装することが、本件出願時の技術常識であることからすると、甲１発明において、「固有ＵＲＬ」によって示されるサイトと「通常のＵＲＬ」によって示されるサイトとが同一の「管理サーバ２０」に実装されているとしても、「固有ＵＲＬ」によって示されるサイトは、本人確認の機能手段を提供するものとはいえない。 よって、「固有ＵＲＬ」は、本人確認するサイトにアクセスするアクセス情報であるとはいえないから、上記一致点に係る請求人の主張は認められない。 （イ）相違点１－５について 上記３．（１）ウ（ア）で説示したとおり、甲１発明の上記「固有ＵＲＬ」を、目的や作用が異なる「前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報」を採用すべき動機付けは認められない。さらに、ガス料金などの料金の請求を行う際に、決済の有無や請求猶予の有無などの請求に係るチェックを行う必要があることは、本願出願時の技術常識であるところ、仮に上記動機付けがあったとしても、上記採用した場合には、請求に係るチェックを行ことができないものとなることからすると、上記「固有ＵＲＬ」を「前記本人確認を行うＷｅｂアプリケーションのサイトにアクセスするアクセス情報」に置き換えることには、阻害要因が存在するといえる。 よって、相違点１－５に係る本件特許発明１の構成は、甲１発明に基づいて、当業者が容易に発明することができたものとはいえないから、上記相違点１－５に係る請求人の主張は認められない。 （ウ）相違点１－６について 上記３．（１）ウ（イ）で説示したとおり、本件特許発明１においては、「認証装置」が、「前記サイトにアクセスして入力された入力情報と前記確認情報が一致し」、「本人確認できた」と判断した場合に、「前記ユーザ用画面に誘導する」処理を行うものであるのに対して、上記甲１適用構成は、「管理サーバ２０」が「固有ＵＲＬへのアクセスから事業者サーバ１０で記憶したお知らせ画面等のＵＲＬへ移送する」ものであって、管理サーバ２０（「認証装置」）が「本人確認できた」と判断した場合に、「前記ユーザ用画面に誘導する」との構成については特定されているとはいえない。そして、甲１適用構成に対して、当該甲４発明の構成、あるいは、甲６発明の構成を適用することは、当業者といえども容易に想到することができたものではなく、仮に適用したとしても、本件特許発明１に至るとはいえない。 よって、上記相違点１－６に係る本件特許発明１の構成は、甲１発明、甲１に記載された事項、甲４発明、及び、甲６発明に基づいて、当業者が容易に発明することができたものとはいえないから、上記相違点１－６に係る請求人の主張は認められない。 イ．無効理由２について （ア）一致点（「事業者」、「事業者装置」）について 上記（１）イ（ア）によると、請求人は、甲５発明の「不動産会社」及び「金融機関」と、「不動産会社のユーザ端末２０」及び「金融機関の金融機関端末４０」とは、それぞれ本件特許発明１の「事業者」と、「事業者装置」とに対応するものと主張していると認められる。 ここで、本件特許発明１の構成要件Ａの「事業者が提供する前記ユーザのためのユーザ用画面」における「事業者」と、構成要件Ｃの「前記事業者の事業者装置」、構成要件Ｄの「前記事業者装置が提供するユーザ情報」、構成要件Ｆ２の「前記事業者装置が提供するＷｅｂ画面」における「前記事業者」とは、同一の事業者であると解される。 これに対して、異なる事業者から提供される情報やサービスは、それぞれに独立して行われることが、商業における常識的事項であるところ、甲５にも、「不動産業者」と「金融業者」とを一体と見なすことができるような記載又は示唆はないため、甲５発明の「不動産業者」と「金融機関」とは、異なる事業者であると解さざるを得ないから、「不動産業者」と「金融機関」とを、本件特許発明１の「事業者」に対応させて、例えば、ユーザ情報を提供する「事業者」を「不動産業者」とし、ユーザ用画面を提供する事業者を「金融機関」とする理由は認められない。 したがって、上記一致点に係る請求人の主張は認められない。 （イ）一致点（「本人確認」） 上記（１）イ（イ）によると、請求人は、甲５発明の「事前審査の申請画面」にアクセスした際に要求される「本人確認」、及び、その後の処理で表示される「事前審査の回答画面」とは、本件特許発明１の「前記ユーザ用画面」を提供する者が本人であることを確認するための「本人確認」、及び、それにより表示される「前記ユーザ用画面」とに相当するものである、と主張していると認められる。 ここで、本件特許発明１における「本人確認」の技術的意義は、「前記ユーザ用画面」にアクセスするためのものであるから、「前記ユーザ用画面」が提供される者を「本人確認」するものであるといえる。 これに対して、甲５発明における、「事前審査の申請画面」のアクセスした際の「本人確認」の技術的意義は、当該「事前審査の申請画面」が提供される者を「本人確認」するものであって、その後の異なるアクセスによって表示される「事前審査の回答画面」が提供される者を本人確認するものとはいえない。 そして、本人確認が必要な情報に対して、異なるタイミングでアクセスされる場合には、それぞれのタイミングにおいて本人確認を行うことが、本件特許出願時の技術常識であるところ、甲５発明における、「事前審査の申請画面」と「事前審査の回答画面」とは異なるタイミングでアクセスされるものであって、「事前審査の申請画面」における上記本人確認を、「事前審査の回答画面」における本人確認とすることは、本件出願時の技術常識であるともいえない。 したがって、上記一致点の認定に関する請求人の主張は認められない。 （ウ）請求人による本件特許発明１ないし５と甲５発明のと対比及び相違点の容易性に係る主張について 請求人の本件特許発明１ないし５と甲５発明との対比及び相違点の容易性に係る主張は、上記（１）イ（ア）及び（イ）に記載した一致点を前提とするものであるところ、上記（ア）（イ）のとおりであるから、請求人の当該主張は採用できない。 ６．小括 上記で検討したとおり、本件特許発明１ないし５に係る特許は、特許法第２９条第２項の規定に違反してされたものではないため、同法第１２３条第１項第２号に該当しない。 したがって、上記無効理由１、２により、無効とすることはできない。 第６ むすび 以上、請求人の主張する無効理由１、２、及び、提出した証拠によっては、本件特許発明１ないし５に係る特許を無効にすることはできない。 そして、審判に関する費用については、特許法第１６９条第２項において準用する民事訴訟法第６１条の規定により、請求人が負担すべきものとする。 よって、結論のとおり審決する。