2022-012959

第１ 手続の経緯

本願は、令和２年１１月１９日の出願であって、令和４年１月１７日付けの拒絶理由通知に対し、同年２月１５日に意見書が提出されるとともに手続補正がされたが、同年７月５日付けで拒絶査定（以下、「原査定」という。）がされ、これに対して同年８月１８日に審判請求がされると同時に手続補正（以下、「本件補正」という。）がされたものである。

第２ 原査定の概要

原査定の概要は次のとおりである。

本願請求項１～１０に係る発明は、以下の引用文献１～７に記載された発明に基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

第３ 本願発明

本願請求項１～１０に係る発明（以下、それぞれ「本願発明１」～「本願発明１０」という。）は、本件補正により補正された特許請求の範囲の請求項１～１０に記載された事項により特定される以下のとおりのものである。

「【請求項１】

ユーザ端末から保険の種目及び証券番号を示す保険情報を取得する保険情報取得部と、

前記保険情報取得部によって取得された前記保険情報が示す種目に応じた情報入力画面を前記ユーザ端末に表示して、前記種目の保険について保険金の支払請求を保険会社に対してするための情報を入力させる画面表示部と、

前記保険情報が示す証券番号と、前記画面表示部によって表示された前記情報入力画面に入力された入力情報とを保険会社装置に送信して、前記保険金の支払請求を行う支払請求部と

続きを表示（全50行）

を備え、

前記画面表示部は、前記情報入力画面に入力された前記入力情報を示した同意画面を前記ユーザ端末に表示して、前記入力情報によって特定される前記支払請求に限定した診断書の前記保険会社による取得に同意するか否かを示す同意情報の入力をさせ、

前記支払請求部は、前記入力情報とともに、前記同意情報を前記保険会社装置に送信する保険仲介装置。

【請求項２】

前記画面表示部は、診断書の取得に同意することを示す同意情報が入力された場合に、認証処理の実行を促す認証通知画面を前記ユーザ端末に表示して、前記証券番号から特定される保険契約者であることを認証する本人認証を行う

請求項１に記載の保険仲介装置。

【請求項３】

前記支払請求部は、前記証券番号から特定される保険契約者の本人認証が成功した場合に、前記入力情報を前記保険会社装置に送信する

請求項１又は２に記載の保険仲介装置。

【請求項４】

前記支払請求部は、前記証券番号から特定される保険会社に応じた認証強度の認証方式による前記本人認証が成功した場合に、前記入力情報を前記保険会社装置に送信する

請求項３に記載の保険仲介装置。

【請求項５】

前記保険仲介装置は、さらに、

前記保険情報が示す証券番号を保険会社装置に送信して、前記証券番号から特定される保険の保険金の支払請求を実行可能か否かを示す請求可否情報を前記保険会社装置から取得する事前判定部

を備え、

前記画面表示部は、前記事前判定部によって取得された前記請求可否情報が支払請求が実行可能であることを示す場合に、前記情報入力画面を表示する

請求項１から４までのいずれか１項に記載の保険仲介装置。

【請求項６】

前記保険会社装置は、保険会社毎に対応して設けられ、

前記支払請求部は、前記証券番号から特定される保険会社に対応した保険会社装置に前記証券番号と前記入力情報を送信する

請求項１から５までのいずれか１項に記載の保険仲介装置。

【請求項７】

前記支払請求部は、前記保険会社装置に送信する前記保険情報が示す証券番号と、前記画面表示部によって表示された前記情報入力画面に入力された入力情報とを認証履歴記憶部に記憶する

請求項１から６までのいずれか１項に記載の保険仲介装置。

【請求項８】

保険仲介装置の保険情報取得部が、ユーザ端末から保険の種目及び証券番号を示す保険情報を取得し、

前記保険仲介装置の画面表示部が、前記保険情報が示す種目に応じた情報入力画面を前記ユーザ端末に表示して、前記種目の保険について保険金の支払請求を保険会社に対してするための情報を入力させ、

前記保険仲介装置の前記画面表示部が、前記情報入力画面に入力された入力情報を示した同意画面を前記ユーザ端末に表示して、前記入力情報によって特定される前記支払請求に限定した診断書の前記保険会社による取得に同意するか否かを示す同意情報の入力をさせ、

前記保険仲介装置の支払請求部が、前記保険情報が示す証券番号と、前記情報入力画面に入力された入力情報とともに、前記同意情報を保険会社装置に送信して、前記保険金の支払請求を行う保険仲介方法。

【請求項９】

ユーザ端末から保険の種目及び証券番号を示す保険情報を取得する保険情報取得処理と、

前記保険情報取得処理によって取得された前記保険情報が示す種目に応じた情報入力画面を前記ユーザ端末に表示して、前記種目の保険について保険金の支払請求を保険会社に対してするための情報を入力させる画面表示処理と、

前記保険情報が示す証券番号と、前記画面表示処理によって表示された前記情報入力画面に入力された入力情報とを保険会社装置に送信して、前記保険金の支払請求を行う支払請求処理と

を行う保険仲介装置としてコンピュータを機能させ、

前記画面表示処理では、前記情報入力画面に入力された前記入力情報を示した同意画面を前記ユーザ端末に表示して、前記入力情報によって特定される前記支払請求に限定した診断書の前記保険会社による取得に同意するか否かを示す同意情報の入力をさせ、

前記支払請求処理では、前記入力情報とともに、前記同意情報を前記保険会社装置に送信する保険仲介プログラム。

【請求項１０】

保険契約者によって使用されるユーザ端末と、保険会社によって使用される保険会社装置と、保険仲介装置とを備える保険仲介システムであり、

前記保険仲介装置は、

前記ユーザ端末から保険の種目及び証券番号を示す保険情報を取得する保険情報取得部と、

前記保険情報取得部によって取得された前記保険情報が示す種目に応じた情報入力画面を前記ユーザ端末に表示して、前記種目の保険について保険金の支払請求を保険会社に対してするための情報を入力させる画面表示部と、

前記保険情報が示す証券番号と、前記画面表示部によって表示された前記情報入力画面に入力された入力情報とを前記保険会社装置に送信して、前記保険金の支払請求を行う支払請求部と

を備え、

前記画面表示部は、前記情報入力画面に入力された前記入力情報を示した同意画面を前記ユーザ端末に表示して、前記入力情報によって特定される前記支払請求に限定した診断書の前記保険会社による取得に同意するか否かを示す同意情報の入力をさせ、

前記支払請求部は、前記入力情報とともに、前記同意情報を前記保険会社装置に送信する保険仲介システム。」

第４ 引用文献、引用発明等

１ 引用文献１について

（２） 引用発明

上記（１）によれば、引用文献１には、次の発明（以下、「引用発明」という。）が記載されている。

［引用発明］

保険加入者が請求事務代行サービス機関（サービス機関）に保険金の請求依頼を行う保険加入者端末１１、保険加入者の代わりに保険事業者との間でデータの送受信や事務手続き等を行う、サービス機関が保有する請求事務代行端末１２、保険加入者が保険契約を結んでいる保険事業者の保有する保険事業者端末１３、保険加入者が傷害、疾病などの理由で診療を受ける医療機関に配設されている医療機関端末１４がインターネット１５を介して相互に通信可能に接続されている保険金請求事務代行システムであって、

上記請求事務代行端末１２は、

保険事故が発生して保険金を受け取ることができるとサービス登録者（保険金請求事務代行システムにおけるサービスを利用して保険金請求を行う保険加入者）が判断した場合に、保険加入者端末１１の入力画面３９において入力された保険金請求の事由、その原因、保険事故が発生した日といった保険金の請求依頼に関する情報を受信し、

保険契約情報データベース２０をサービス登録者の識別ＩＤで検索するとともに、サービス登録者がどの保険事業者に加入しているかについて判断し、

個人情報データベース１９をサービス登録者の識別ＩＤで検索するとともに、サービス登録者の個人情報を取得し、

保険金の請求依頼に関する情報とサービス登録者の個人情報を送信することにより、サービス登録者の契約している全ての保険事業者端末１３に審査を依頼し、

各保険事業者端末１３において、審査の結果、保険金が支払われると判定された場合、保険金給付手続きに必要な事故証明書、診断書等の必要書類の提出依頼に関する情報を受信し、

診断書や入院状況報告書など医療機関で必要書類を発行してもらう必要がある場合には、医療機関端末１４に書類提出の依頼に関する情報を送信し、発行された書類に関するデータを受信する、

請求事務代行端末１２。

２ 引用文献２について

原査定の拒絶の理由に引用された引用文献２（特開２００２－１７５４９３号公報）には、以下の記載がある。

「【０００２】

【従来の技術】従来は、省庁や企業への種々の申請・届出手続などを紙面による申請書を用いて行っていた。近年の電子技術の進歩により、それら申請書などをディジタルデータ化し、申請者と申請先とを相互接続するネットワークなどを利用して電子申請を行うことができれば便利である。

【０００３】

【発明が解決しようとする課題】しかし、ユーザにある事例（イベント）が発生した時に、複数の申請先に別々に申請手続きを行う必要が生じうる。例えば、ある企業に新入社員が入社した際には、その企業は公共職業安定所と社会保険事務所の両方にそれぞれ別個の申請書類を提出する必要がある。その際、企業の総務課では個別に申請処理を作成するという手間が生じ、非効率的となる。

続きを表示（全14行）

【０００４】また、申請書類の提出先は申請者の属性、例えば住所などにより変わってくる場合がある。上記の新入社員の例では、その企業が属する区や市町村の職業安定所に書類を提出する必要がある。従って、電子的に作成された書類を、個々の書類毎に正しい申請先、提出先に提出する必要がある。

【０００５】本発明は、以上の点に鑑みてなされたものであり、ある特定のイベントに関連して、効率的に電子書類を作成し、書類毎に正しい提出先へ電子書類を提出することが可能な電子書類提出システムを提供することを目的とする。

【０００６】

【課題を解決するための手段】請求項１に記載の発明は、ネットワークを介してユーザ端末と接続された電子手続システムのサーバ装置において、複数の手続に対応する個別電子フォームと、所定のイベントに関連する複数の手続に対応する複数の個別電子フォーム中の項目を含む一括入力フォームと、を記憶したデータベースと、イベント名と一括入力フォームとの対応関係を記憶した記憶手段と、ユーザ端末からイベント名の指定を受け取る手段と、前記記憶手段を参照して、指定されたイベント名に対応する一括入力フォームを特定する手段と、特定した一括入力フォームを前記データベースから取得してユーザ端末へ送信する手段と、を備える。

【０００７】上記のように構成されたサーバ装置によれば、ユーザがイベント名を指定すると、そのイベント名に対応する一括入力フォームがユーザ端末へ送信される。一括入力フォームは、そのイベントに関連する複数の手続において必要となる複数の電子フォームの中の項目を含んでいるので、ユーザは複数の電子フォーム毎に繰り返し入力を行う必要がなくなり、効率的に必要な電子書類を作成することができる。

【０００８】請求項２に記載の発明は、請求項１に記載のサーバ装置において、ユーザが必要事項を入力した後の前記一括入力フォームをユーザ端末から受信し、当該一括入力フォームに対してユーザが入力した事項を利用して、対応する複数の手続の個別電子書類を作成する手段を備える。こうして、サーバ装置は一括入力フォームに対してユーザが入力した事項から個別の電子書類を作成する。

【０００９】請求項３に記載の発明は、請求項２に記載のサーバ装置において、前記データベースは各個別電子フォーム毎の提出先情報を記憶しており、前記記憶手段を参照して、作成された個別電子フォームを対応する提出先へ送信する手段を備える。よって、個別電子書類は対応する提出先へ正しく送信される。

【００１０】請求項４に記載の発明は、請求項１乃至３のいずれかに記載のサーバ装置において、ユーザが複数のイベント名及び／又は電子フォームを指定した場合に、対応する電子フォーム及び一括入力フォームに含まれる入力項目を含む新たな一括入力フォームを作成する手段を備える。こうして、予めサーバ装置に用意された一括入力フォームと他の電子書類、又は、複数の一括入力フォームからさらに新たな一括入力フォームを作成することにより、ユーザは必要な全ての電子書類を効率的に作成することができる。

【００１１】請求項５に記載の発明は、ネットワークを介してユーザ端末と接続された電子手続システムのサーバ装置において、複数の手続に対応する電子フォームを記憶したデータベースと、ユーザ端末からの指定に基づいて、前記データベースから電子フォームを取得してユーザ端末へ送信する手段と、ユーザが必要事項を入力した後の前記電子フォームをユーザ端末から受信し、入力された事項に基づいて当該電子フォームの提出先を決定する提出先決定手段と、決定した提出先へ前記電子フォームを送信する手段と、を備える。

【００１２】上記のように構成されたサーバ装置によれば、ユーザが必要事項を入力した後の電子フォームを受信し、その入力事項に基づいて適正な提出先に電子書類が送信される。」

「【００２２】ユーザは、例えば個人的な申請、届出などの手続を行う個人ユーザや、業務上必要な申請、届出などの手続を行う企業ユーザを含む。個人ユーザの場合、端末２は家庭に配置されたパーソナルコンピュータや勤務先に設置された端末装置とすることができる。また、企業ユーザの場合、端末２は一般的にその企業に設置された端末装置となる。

【００２３】Ａ社はユーザによる電子書類の作成・提出の支援業務を行う企業である。Ａ社のサーバ３は電子フォームデータベース４を有し、その中には各種申請、届出などの書類の電子フォームが蓄積されている。電子フォームは、従来の紙の書面を電子化したデータであり、電子データの形態で提出先へ提出することにより従来の書類の提出と同様に申請などの手続を行うことができる。サーバ３は、ユーザからの要求に応じて、必要な電子フォームをデータベース４から取り出してユーザ端末２へ提供する。ユーザは必要事項を入力し、さらに必要であれば添付書類（例えば証明書など）のデータを添付して提出書類データを作成する。提出書類データは、ユーザが直接提出先へ送信することにより提出することもできるし、Ａ社が提出を代行することもできる。

【００２４】提出先は、例えば省庁や私企業などであり、端末５、６を利用して所定の申請、届出、申込など各種の手続を電子書類の形態で受け付ける。

【００２５】次に、本発明による電子書類作成処理について図１乃至３を参照して説明する。本発明では、複数の提出先に電子書類の提出を行う場合に、一括入力フォームを利用して入力を簡略化、効率化することを１つの特徴とする。

【００２６】Ａ社内のデータベース４には各種手続のための電子フォームが記憶されている。これは、まず各書類毎に用意されている。即ち、例えば住所変更届、名称変更届、何らかの申込書など、各書類に対応して１つの電子フォームが用意されている。各電子フォームについては、例えば識別番号などが付されてデータベース４内で管理されている。

【００２７】これに加えて、データベース４には、ある特定のイベント毎に一括入力用電子フォーム（以下、「一括入力フォーム」と呼ぶ）が用意されている。例えば、引っ越し、就職、結婚など、社会において比較的頻繁に発生するイベントであって、その際に複数の届出や申請を必要とするものがある。この場合、必要な届出の電子書類を別個に作成するのは非効率的である。また、そのような頻繁に発生するイベントについては、それに伴って必要となる届出などの手続はどの人の場合でもおよそ共通している場合が多い。そこで、本発明では、そのような特定のイベントが発生した時に必要となる手続の電子フォームを効率的に作成するために一括入力フォームを予め用意し、データベース４内に蓄積しておく。なお、以下の説明では、一括入力フォームと区別する意味で、通常の電子フォームを「個別電子フォーム」と呼ぶこともある。

【００２８】一括入力フォームの例を図３に示す。図３において、例えば、新入社員の入社手続というイベントに伴って、ユーザ（この場合は、その社員が入社した企業の総務部など）が書類Ａと書類Ｂを作成し、それぞれ所定の提出先に提出すると仮定する。この場合、「新入社員の入社手続」というイベントに対しては、データベース４内に予め一括入力フォームNo.001が用意されている。一括入力フォームNo.001は、具体的には書類Ａと書類Ｂに含まれる項目の全てを含む１つの電子フォームとして作成されており、ユーザが一括入力フォームの全ての項目に必要事項を入力すれば、書類Ａ及びＢの全ての項目に対するユーザの入力が得られる。」

「【００４１】また、上記の例では、サーバ３が図２に示すような提出先決定情報テーブルを有しているが、その代わりに提出先決定情報を予め各電子フォームに含めておくことができる。例えば、サーバ３は、書類Ａの電子フォームに、図２（Ｂ）に示す提出先決定情報、及び提出先決定機能（例えば、ユーザ端末上で動作するプログラムなどの形態とすることができる）を含めてユーザ端末２へ送信する。ユーザ端末２では、ユーザが必要事項を入力した時に、提出先決定プログラムが動作して提出先決定情報に従ってその電子書類Ａの提出先を決定する。なお、これは個別の電子フォーム単位でも、一括入力フォーム単位でも適用することができる。

【００４２】なお、上述した一括入力フォームを含むシステムは、提出先である官公庁や企業に設置して利用することもできる。

【００４３】また、上記の一連の手続において、Ａ社サーバはその手続の実行中にユーザ及び関連する機関（提出先など）との間で行われた処理のログ記録をとり、保存しておくことができる。また、ユーザや関連機関からの要求に応じて、そのログ記録を提示することができる。これにより、手続の途中において進捗状況を確認したり、手続の完了後にその履歴などを確認することができる。

【００４４】また、上記一連の手続の実行のために、ユーザの本人認証など、何らかの認証が必要な場合にはＡ社サーバはその認証を得ることを条件に手続を進めることができる。また、手続の実行に関して何らかの証明データなどが必要な場合は、そのデータを一括電子フォームに添付することにより個別電子フォームへの証明データの添付処理を実行することができる。」

３ 引用文献３について

原査定の拒絶の理由に引用された引用文献３（特開２００３－２４８６６１号公報）には、以下の記載がある。

「【０００２】

【従来の技術】従来、個人認証などを行うために個人を識別する方法として、サインや、パスワード入力などが広く用いられてきた。

【０００３】しかしながら、サインは、簡単に模倣することが可能であり、パスワードも、一度漏洩してしまうと、他人であっても簡単に入力することができるため、成りすました他人が、キャッシュカードやクレジットカードを利用することが可能になってしまう。

【０００４】このような成りすましを防ぐため、例えば、指紋などの生体情報を利用して、個人を識別する技術が発達してきている。

【０００５】

【発明が解決しようとする課題】個人を識別（あるいは、識別結果を用いて認証）する場合、その識別の安全性と、利便性（例えば、利用する装置は普及しているか、ユーザに求められる操作が簡単であるか、あるいは、識別処理にかかる時間が短いかなど）は、識別に用いる方法に依存して決まってしまう。例えば、サインやパスワードは、非常に簡単に個人識別を行えるものであるが、安全性が高いとはいえない。また、指紋を用いて個人を識別するための装置は普及し始めているが、より模倣され難い網膜情報を読み取るための装置はあまり普及していない。

【０００６】また、個人認証が行われる状況により、求められる認証の安全性は異なる。例えば、商品を購入する場合、商品単価と比較して、個人認証にかかるコストが高くなってしまうような、高度の認証精度を有する認証処理は必ずしも必要ではないが、高額の商品を購入する場合は、第三者の成りすましを防ぐため、高度の認証精度を有する認証処理が必要となる。

【０００７】このような多様な要求にこたえるために、それぞれ異なる方法で認証処理を行おうとした場合、認証に必要な装置を多種類用意し、認証のための個人情報をそれぞれの認証方法に合わせて全て取得して記憶しなければならないため、費用も時間も非常にかかってしまう。

【０００８】更に、認証処理を行うユーザが個人認証装置を携帯するようになされている場合、ユーザが複数の個人認証処理装置を持ち歩かなければならない。また、認証処理を行うユーザが個人認証装置を携帯しないような場合でも、認証処理を行う状況によってはユーザが操作しなければならない個人認証処理装置が異なってしまうため、ユーザは複数の個人認証処理装置を扱うことになり、利便性が悪くなる。

【０００９】本発明はこのような状況に鑑みてなされたものであり、認証処理を必要とする場合の状況に応じて、第三者の成りすましなどによる被害の防止と、ユーザの利便性とを両立させた認証処理を実行させることが出来るようにするものである。」

「【０１０９】ステップＳ２４において、認証レベル決定部７４は、認証レベル情報データベース７５から、入力されたサービス内容に対応した認証レベル情報を取得し、ルールデータベース７６から、認証レベルを決定するための各種ルールを取得する。認証レベル決定部７４は、例えば、サービス内容が入室許可のための認証処理であった場合、サービス内容レベル情報、およびアクセス情報レベル情報を認証レベル情報データベース７５から取得し、認証レベルルール、およびアクセスレベルルールなどをルールデータベース７６から取得する。

【０１１０】ステップＳ２５において、認証レベル決定部７４は、図９を用いて後述する認証レベル決定処理を実行する。

【０１１１】図９を用いて後述する認証レベル決定処理において決定される認証レベルは、認証レベル０乃至認証レベル４の５段階に分かれているものとする。例えば、登録されているユーザ全てに同様の内容を通知する場合や、物の売買において、代引きなどの決済方法がとられるため、成りすましによる被害が発生しないような場合などにおいて、最も簡単な認証処理が実行されるのが認証レベル０であり、確実に本人を確認する必要がある場合に、最も厳しい認証処理が実行されるのが認証レベル４である。

【０１１２】認証レベル０の場合は、生体情報を用いた認証処理を行うことなく、例えば、そのユーザだけが知っている情報や、そのユーザだけが保有している所定のものを利用したトークン認証などにより、個人認証を行う。ユーザだけが知っている情報には、例えば、パスワードやパスフレーズ、個人的な識別番号、あるいは母親の旧姓などの本人しか知りえない事実などがある。また、そのユーザだけが所有している所定のものには、鍵や磁気カード、または１回限り使用できるパスワードやサーバからの質問に対して特定の答えを生成する専用の認証デバイス（いわゆるセキュアチップを搭載した端末装置やカードなど）などがある。認証レベル１乃至４においては、図４を用いて説明したように、個人認証端末装置１が実行する認証処理において、認証閾値の値が変更されることにより、認証精度が変更される。

【０１１３】ステップＳ２６において、認証レベル決定部７４は、ステップＳ２５において決定した認証レベルを、通信処理部７１を介して、サービスモジュール１１に供給する。」

４ 引用文献４について

原査定の拒絶の理由に引用された引用文献４（特開２０１５－ ９０６２０号公報）には、以下の記載がある。

「【背景技術】

【０００２】

近年、企業又はプロバイダ等のサービス提供者は、ユーザのＩＤ及びパスワードを認証し、ユーザにサービスを提供している。

【０００３】

続きを表示（全13行）

このため、ユーザは、サービス毎に、ＩＤ及びパスワードを管理する必要がある。また、ユーザは、セキュリティ強化の観点から、パスワードの定期的な更新や、複雑で長いパスワードの使用が各サービス提供者から要求される。

【０００４】

ここで、オンラインで金融機関を利用する場合には、本人確認のために乱数カードの利用やワンタイムパスワードの利用などが推奨されている。この場合、ユーザは、サービス毎に、ワンタイムパスワードのデバイスや乱数表を管理する必要がある。

【０００５】

一方、サービス提供者は、ユーザ毎に、ＩＤ及びパスワードを管理及び認証し、サービスを提供する。また、サービス提供者は、コストや運用面から、ワンタイムパスワードのデバイスや乱数表の利用等により、ユーザ毎のセキュリティ強度を維持している。これらワンタイムパスワードのデバイスや乱数表は、セキュリティ強度を維持するため、他のサービス提供者と共同で利用されることはない。

【０００６】

以上のように、ユーザ及びサービス提供者は、パスワード、ワンタイムパスワードのデバイス又は乱数表などを管理する必要がある。この種の管理は、ユーザとサービスとの組合せ毎に管理対象が増えるため、煩雑になり、利便性を低下させる。このような利便性の低下を阻止する観点から、１回の認証で複数のサービスを利用可能とするシングルサインオン（ＳＳＯ）による認証連携（フェデレーション）が実現されてきている。

【０００７】

このようなシングルサインオンを用いるためには、複数のサービス提供者が互いに信頼関係を結ぶと共に、各サービス提供者のシステム間で認証連携をする必要がある。」

「【００１０】

また、以上のような認証連携は、システム間で認証の強度が異なる場合に、シングルサインオンをユーザが安全に利用することが難しくなり、ユーザの利便性を低下させてしまう。」

「【００３７】

また、第１の実施形態においては、認証代行装置は、認証処理の方式を示す認証クラス、及び当該認証処理のレベルを示す認証レベルを関連付けて記述した認証クラス管理テーブルを記憶した第１テーブル記憶手段を備えている。」

「【００５０】

ユーザＵは、サービスを利用する個人ユーザ又は企業ユーザである。当該図では、ログイン認証することによりサービスを受けるものを前提としている。ユーザＵは、個人／企業／公共等の利用者を表す。」

「【００６４】

ＡＰ連携情報は、連携先の認証代行事業者を示す連携先ＡＰ名と、連携のために認証代行装置４０と共有する識別情報である第２連携ＩＤと、認証代行装置４０による認証処理のレベルを示す認証レベルとを含んでいる。」

「【００７３】

認証クラス管理テーブルＴ１は、認証代行装置４０による認証処理のレベルを示す認証レベルと、認証代行装置４０による認証処理の実行に必要な情報を特定する認証クラスとが関連付けられて記述されている。」

「【０１３２】

このようなステップＳＴ４９～ＳＴ５２，ＳＴ５６～ＳＴ５８においては、認証代行装置４０が、ＩＤａａＳ事業者装置３０から受けた認証要求に基づいて、ユーザ端末１０を操作するユーザの認証処理を実行し、当該認証処理の結果をＩＤａａＳ事業者装置３０に送信するステップを実行している。」

５ 引用文献５について

原査定の拒絶の理由に引用された引用文献５（特開２００５－１００１６５号公報）には、以下の記載がある。

「【００１１】

以下、本発明を実施する場合の一形態を、図面を参照して具体的に説明する。

図１及び図２は、本発明の実施の一形態である医療給付金請求手続きサービスの構成を示すブロック図である。まず図１により、診療記録の開示可否指示で、開示を可とした場合のサービスシステムについて説明する。医療保険加入者１０１は自身の会社等の属する健康保険組合に属する。ここで、健康保険組合及び保険事業者は、それぞれデータベースを備える健康保険組合サーバ１０７及び保険事業者サーバ１０３を有し、データの送受信及びデータの処理は各サーバ内で自動的に行われる。医療保険加入者１０１が医療機関１０９で治療を受けた場合、診療記録１１０から診療記録情報が健康保険組合の診療記録情報１０８に送られ、保険金請求に必要な情報に加工して保険事業者サーバ１０３に送信される。ここで、医療機関１０９にも医療機関サーバを設け、医療機関サーバから健康保険組合サーバ１０７に対して診療記録１１０を送信する構成としてもよい。保険事業者サーバ１０３では、個人情報データベースと受信した診療記録（診療記録情報データベース）の保険証ＮＯ．を用いて保険契約（証券番号）を特定し、特定した保険契約の保障内容を加入保険情報データベースから取得し、取得した保障内容と診療記録情報データベースの診療・治療内容を比較することにより保険金支払の対象有無判定を行い、保険金支払の対象有の場合は医療保険加入者１０１、医師１１１双方へ必要書類の提出依頼を行い、書類が揃い次第、保険金を医療保険加入者１０１（または保険金受取人）へ支払うものである。

【００１２】

図２は診療記録の開示可否指示で、開示を不可とした場合である。このシステムは、従来のサービスシステムに相当する。医療保険加入者１０１は保険事業者１０３の提供する医療保険に加入する。医療保険加入者１０１が医療機関１０９で治療を受けた場合、医療保険加入者１０１（または保険金受取人）は自身で保険事業者１０３へ保険金請求事由発生の通知を行う。保険事業者１０３は、通知された内容を元に保険金支払の対象有無判定を行い、医療保険加入者１０１へ必要書類の提出依頼を行う。医療保険加入者１０１は自身で医師１１１より診断書を取得し、その他必要書類を集め保険事業者１０３へ提出する。保険事業者１０３は書類が揃い次第、保険金を医療保険加入者１０１（または保険金受取人）へ支払うものである。」

「【００１７】

Ａさんが診療記録情報の第三者（保険事業者）への開示を可としていた場合、ステップ４０６で診療情報が健康保険組合から保険事業者へ送られる。ステップ４０７で、保険事業者は、健康保険組合からの診療情報よりＡさんの診療内容が契約している保険の保障内容であるかの確認を行う。保障対象でない場合はこのまま終了となる。ステップ４０８では、保険事業者から医師へＡさんの診断書の提出を求める。ステップ４０９では、保険事業者からＡさんへ保険金請求に必要な請求書の提出を求める。ステップ４０８，４０９の処理は、通常は保険事業者のサーバが、医療機関にＡさんの診断書提出を求める書類及びＡさんに保険金請求に必要な請求書の提出を促す書類の打ち出す処理までを自動的に行い、打ち出した書類は郵送にて医療機関あるいはＡさんに送付されるが、Ａさんが所持するＰＣ等の機器または医療機関サーバに対してネットワークを介して書類を送信する構成としてもよい。ステップ４１４で、書類が揃い次第、保険金がＡさんに支払われる。

【００１８】

ステップ４０５で、Ａさんが診療記録情報の第三者（保険事業者）への開示を不可としていた場合、ステップ４１０でＡさん自身（または保険金受取人）から保険事業者へ保険金請求事由発生の通知を行う。ステップ４１１で、保険事業者は、Ａさんからの通知によりＡさんの受けた診療内容が契約している保険の保障内容であるかの確認を行う。保障対象でない場合はこのまま終了となる。ステップ４１２で、保険事業者からＡさんへ医師からの診断書および、保険金請求に必要な請求書の提出を求める。ステップ４１３で、Ａさんから医師へ診断書の提出を求める。ステップ４１４で、書類が揃い次第、保険金がＡさんに支払われる。」

６ 引用文献６について

原査定の拒絶の理由に引用された引用文献６（国際公開第２０１８／０４３５９９号）には、以下の記載がある。

「[0002] 従来、個人が銀行又は証券会社等の金融機関に口座を開設する場合や、インターネットを介してネット業者から物品やサービス等を購入する際には、少なくとも氏名、住所、生年月日等を含む個人情報及びその証明書が要求される。この個人情報が悪用された場合、プライバシー侵害につながるのみならず経済的損失の可能性もあるため、秘密情報として扱っている企業も多い。例えば、個人ＸがＡ銀行に口座を開設するためＡ銀行へ身元確認を示す個人情報及び証明書を提供し、その後にＢ銀行にも口座を開設するときは、同じように個人情報及び証明書を提供する必要がある。したがって、個人は各金融機関に対して本人確認手続きをしなければならないという手間が生じていた。

・・・

[0004] 個人としては面倒な本人確認手続きをその都度行うことなく、上記の例であればＡ銀行での本人確認手続きで提供した個人情報等が、Ｂ銀行に対して活用できれば、１回の手続きで済むため効率がよい。しかしながら、昨今のネットワークインフラが拡充され、日常生活においてネットワーク経由で物やサービスを伝搬させることが広範囲にあたりまえに浸透しているにもかかわらず、この本人確認手続きに伴う個人情報等の取扱いはディジタル社会の進展とは無関係のまま変わらずに行われていた。

[0005] その大きな理由は、金融機関は預金や有価証券などの重要な資産を預かるため個人情報に対しては最大の注意をもって取扱わなければならず、口座開設時にあたり個人に多少の不便さが生じるとしても慎重さを期すには必要不可欠なものであると考えているからである。

また、不正利用を未然に防止する上でも身元確認が厳格になっている。すなわち、金融機関は、実在している個人若しくは会社が口座を開設しようとしているかを確認することによって、犯罪祖域やテロ機関等に関連する正体不明の口座が不正なマネーロンダリングに利用されてしまうことを防止するよう金融庁から通達されている。金融機関が、いわゆるＫＹＣ（Know Your Customer）と称される、新規口座を開く際に必要な書類手続き等を個人に要求しないことによって不正マネーロンダリングによる被害が生じれば、その金融機関は法令違反となって処罰の対象となりかねないからである。ＫＹＣは特に欧米の金融機関では厳格に運用されており、場合によってはサービスが利用できるまでに数週間を要したり、口座開設が拒否されることもある。」

「[0041] ネットワーク３上に出力されたユーザＸの個人情報の取得要求に応答して、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…、及び端末Ｚの少なくとも１つ（ここでは、その１つのコンピュータが端末Ｚであるとする。）は、Ｂ銀行に個人情報を提供してもよいかの同意をユーザＸから得ることを試みる（図４の404，図５のステップS503）。なお、端末Ｚの代りに、端末Ｙ（１）、端末Ｙ（２）、端末Ｙ（３）…の何れかであってもよい。

[0042] ユーザＸへの連絡は、携帯端末Ｘ（１）に電話をして直接ユーザＸに確認したり、携帯端末Ｘ（１）に確認メールを送信する。あるいは、ユーザＸが端末Ｙ（２）上で口座開設要求した際、申込み画面のＱＲコード（登録商標）等を携帯端末Ｘ（１）のアプリで読み込み送信させることで確認をとる方法でもよい。

[0043] ユーザＸが同意するときは秘密鍵（Ｓ2）を用いた電子認証によって知らせる。具体的には例えば、端末Ｚは任意の長さのランダム数値をユーザＸの携帯端末Ｘ（１）に送信し、これを受けてユーザＸはランダム数値を秘密鍵（Ｓ2）に用いて電子署名を作成する。端末Ｚは秘密鍵（Ｓ2）と鍵ペアをなす公開鍵（Ｐ2）を登録しているので、この公開鍵（Ｐ2）を使って電子署名を復号する。元のランダム数値に一致すれば、ユーザＸの公開鍵（Ｐ2）で復号できる暗号文（電子署名）を作成できるのは秘密鍵（Ｓ2）をもつユーザＸしかいないことから、ユーザＸ本人の同意であることが証明される。このように、電子署名を利用して不正な者がユーザＸになりすまして同意がなされることを排除する。」

「[0083] なお、上述した実施形態では、金融機関に口座を開設するときの個人情報の共有について説明してきたが、必ずしも金融機関同士の情報共有に限定されるものではない。例えば、医療、通信、不動産、教育、行政、物流、保険、任意の契約、インターネットサービス、シェアリングエコノミーサービスなど様々な分野についても本発明の範疇に含まれる。したがって、本発明が適用する分野に応じて、ユーザＸから同意を得ることなく情報の共有が行う場合は、情報共有の確認処理（図４の404，405及び図５のステップS503，S504）は省略され得る。また、集団的コンセンサス（合意）に代わりビットコインで行われるようなブロックチェーン・ベースのProof of Work(POW)の計算でブロックを生成することが適することもある。分散型台帳技術のいずれのタイプであっても、本発明による技術の適用が可能である。」

７ 引用文献７について

原査定の拒絶の理由に引用された引用文献７（特許第６３６２７１５号公報）には、以下の記載がある。

「【０００４】

患者の個人情報を共有する場合、病院などの医療機関、保険会社などの民間企業、消防などの行政などが共有対象として考えられる。患者に緊急性を要する症状が認められた場合、共有対象に対して患者の健康状態に関する情報を送信することが好ましい場合があるが、この場合、情報の送信可否について事前に患者の同意を得ておく必要があった。しかしながら、従来の技術では、患者の健康状態に関する情報を送信先へ送信することの有用性があると判定された送信先に対して、ユーザによる情報送信に対する同意の有無を確認してから、同意がある送信先に対してユーザの健康状態に関する情報を送信する技術については、何ら検討されていなかった。」

「【００３２】

本実施の形態では、ユーザに関する情報には、ユーザを特定するための個人特定用情報と、ユーザの属性を示す属性情報などのユーザの個人情報が含まれる。個人特定用情報には、ユーザを一意に特定するための利用者ＩＤと、ユーザの氏名、住所、電話番号、生年月日を含む名寄せ情報と、ユーザの指紋、網膜、声紋、顔面などを用いた生体認証情報が含まれる。属性情報には、ユーザ個人を分類するための個人分類情報とユーザの医療情報とユーザの活動や契約に関する活動・契約情報が含まれる。個人分類情報には、ユーザの性別、年齢、住所、身長、体重、血液型などの情報が含まれる。医療情報には、ユーザの症状、医師による所見、検査結果、ユーザのバイタルデータ（血圧、脈波、脳波、心電図、血糖値、心拍数等）、ユーザの処方歴、既往歴、常用薬、かかりつけ病院などの情報が含まれる。活動・契約情報には、ユーザの購買に関する情報、ユーザの運動量に関する情報、ユーザが加入している保険に関する情報などが含まれる。なお、本実施の形態では、医療情報に含まれるユーザのバイタルデータには、ユーザ端末１００から解析用情報を受信したときに、解析用情報に含まれるバイタルデータの測定結果が履歴データとして記録されていく。」

「【００４２】

記憶媒体２０３には、ユーザの健康状態に関する情報の送信先として、少なくとも１つの情報提供先が登録されている。ユーザの健康状態に関する情報の送信先としては、例えば、消防などの行政、病院などの医療機関、保険会社などの民間企業を想定する。制御装置２０２は、登録されている送信先ごとに、ユーザの健康状態に関する情報を提供することの有用性の有無を判定する。有用性を判定するためのスコアリング処理は、例えば、以下のようになる。」

「【００４７】

送信先が保険会社などの民間企業である場合には、制御装置２０２は、記憶媒体２０３に記録されているユーザに関する情報にバイタル情報が含まれているか否かを判定する。その結果、ユーザに関する情報にバイタル情報が含まれている場合には、制御装置２０２は、有用性を示す指標値に１を加算する。また、制御装置２０２は、記憶媒体２０３に記録されているユーザに関する情報にバイタル情報以外の医療情報が含まれているか否かを判定する。その結果、ユーザに関する情報にバイタル情報以外の医療情報が含まれている場合には、制御装置２０２は、有用性を示す指標値に１を加算する。また、制御装置２０２は、記憶媒体２０３に記録されているユーザに関する情報に活動・契約情報が含まれているか否かを判定する。その結果、ユーザに関する情報に活動・契約情報が含まれている場合には、制御装置２０２は、有用性を示す指標値に１を加算する。また、制御装置２０２は、上述した処理で、ユーザに緊急を要する症状が発生していない、すなわちユーザは正常状態であると判定した場合には、有用性を示す指標値に１を加算する。また、制御装置２０２は、記憶媒体２０３に記録されているユーザに関する情報に活動・契約情報に基づいて、ユーザが送信先のサービスに対する契約者であるか否かを判定し、契約者である場合には、有用性を示す指標値に１を加算する。制御装置２０２は、このスコアリング処理の結果、有用性を示す指標値が３以上の場合には、ユーザの健康状態に関する情報を送信先、すなわち民間企業に送信することは有用性があると判定する。

【００４８】

これによって、民間企業にとっては、ユーザに緊急を要する症状が発生していない正常状態において、ユーザが自社のサービスの契約者であり、ユーザの医療情報と活動・契約情報が把握できる場合には、ユーザの健康状態に関する情報を入手することが有用であることを加味して、民間企業にとってユーザの健康状態に関する情報を受信することの有用性の有無を判定することができる。

続きを表示（全15行）

【００４９】

制御装置２０２は、上述した処理によって情報を送信することに有用性があると判定した送信先に対してユーザの健康状態に関する情報を送信するに当たり、該送信先へ情報を提供することに対して、ユーザの同意が取れているか否かを判定する。本実施の形態では、事前に各送信先へ情報を提供することに同意するか否かをユーザに確認しておき、確認がとれたものについては、送信先ごとの同意の有無を示す同意情報が記憶媒体２０２に記録されているものとする。

【００５０】

制御装置２０２は、情報を送信することに有用性があると判定した送信先に対する同意の有無を同意情報を参照して確認した結果、ユーザの同意が得られていると判定した場合には、その送信先の送信先端末３００へユーザの健康状態に関する情報を送信する。ユー

ザの健康状態に関する情報としては、例えば、「○時〇分にＡ氏に高血圧１４０ｍｍＨＧ／９０ｍｍＨＧが測定された。位置情報は、経度○○．○○、緯度: ○○○．○○（〇〇県〇〇市○○町〇丁目）、管轄内、既往歴に脳内出血・心筋梗塞あり」のような情報を送信する。

【００５１】

一方、制御装置２０２は、情報を送信することに有用性があると判定した送信先に対する同意の有無を同意情報を参照して確認した結果、ユーザの同意が得られていないと判定した場合には、ユーザにその送信先へ情報を提供することに対する追加同意を得るために、ユーザ端末１００に追加同意を取り付けるためのメッセージを送信する。

【００５２】

ユーザ端末１００では、制御装置１０５は、情報提供装置２００から追加同意を取り付けるためのメッセージを受信した場合には、メッセージ内容をタッチパネル１０１に表示し、同意するか否かについて、ユーザからの回答を待つ。本実施の形態では、例えば、「あなたのバイタルデータ（血圧）を行政（消防）に提供することに同意しますか？」のメッセージとともに、「ＹＥＳ」と「ＮＯ」のボタンを表示し、ユーザからの指示を待つ。制御装置１０５は、ユーザによって「ＹＥＳ」のボタンがタッチされることにより、追加同意が得られた場合には、追加同意が得られたことを示す情報を追加同意結果として情報提供装置２００へ送信する。一方、制御装置１０５は、ユーザによって「ＮＯ」のボタンがタッチされることにより、追加同意が得られなかった場合には、追加同意が得られなかったことを示す情報を追加同意結果として情報提供装置２００へ送信する。

【００５３】

情報提供装置２００では、制御装置２０２は、ユーザから追加同意が得られた場合には、その送信先の送信先端末３００に宛てて、上記と同様のユーザの健康状態に関する情報を送信する。これによって、事前にユーザの同意が得られていない場合であっても、追加で同意を取り付けて有用性のある情報を送信先へ送信することができる。」

「【００７５】

以上説明した本実施の形態によれば、以下のような作用効果を得ることができる。

（１）ユーザ端末１００の制御装置１０５は、ユーザのバイタルデータを取得し、取得したバイタルデータを含んだ解析用情報を情報提供装置２００へ送信するようにした。情報提供装置２００では、制御装置２０２は、ユーザ端末から受信した解析用情報に基づいて、ユーザに緊急を要する症状が発生したか否かを判定し、緊急性の判定結果を加味して、ユーザの健康状態に関する情報を送信先へ送信することの有用性の有無を送信先ごとに判定し、有用性があると判定した送信先に対して、ユーザが自身の健康状態に関する情報を送信することに同意しているか否かを判定し、同意があると判定した送信先に対してユーザの健康状態に関する情報を送信するようにした。これによって、ユーザが情報送信に同意している場合には、ユーザの健康状態に関する情報を送信することに有用性が認められる送信先に宛てて、ユーザの健康状態に関する情報を提供することができる。

【００７６】

（２）情報提供装置２００では、制御装置２０２は、ユーザからの同意が得られていない送信先に対して、ユーザの健康状態に関する情報を送信することの同意をユーザに要求し、この要求に応じてユーザの同意が得られた場合には、ユーザの同意が得られた送信先へ、ユーザの健康状態に関する情報を送信するようにした。これによって、事前にユーザの同意が得られていない送信先に対しても、ユーザからの追加同意を得て、ユーザの健康状態に関する情報を提供することができる。」

第５ 対比・判断

１ 本願発明１について

（１） 対比

ア 引用発明の「保険加入者端末１１」、「請求事務代行端末１２」、「保険事業者」及び「保険事業者端末１３」は、本願発明１の「ユーザ端末」、「保険仲介装置」、「保険会社」及び「保険会社装置」に相当する。

イ 引用発明の「請求事務代行端末１２」は、「保険加入者端末１１の入力画面３９において入力された保険金請求の事由、その原因、保険事故が発生した日といった保険金の請求依頼に関する情報」を受信しているところ、「保険金請求の事由、その原因、保険事故が発生した日といった保険金の請求依頼に関する情報」は「保険情報」といえるから、「保険情報」を受信（取得）する手段である「保険情報取得部」を備えているといえる。

したがって、引用発明の「保険加入者端末１１の入力画面３９において入力された保険金請求の事由、その原因、保険事故が発生した日といった保険金の請求依頼に関する情報」を受信する手段と、本願発明１の「ユーザ端末から保険の種目及び証券番号を示す保険情報を取得する保険情報取得部」は、「ユーザ端末から保険情報を取得する保険情報取得部」である点で共通する。

ウ 引用発明の「保険加入者端末１１」は「入力画面３９」において「保険金請求の事由、その原因、保険事故が発生した日といった保険金の請求依頼に関する情報」を入力しているところ、当該情報は「保険金の支払請求を保険会社に対してするための情報」であるといえる。

そして、「保険加入者端末１１」は「請求事務代行端末１２」と「インターネット１５を介して相互に通信可能に接続されている」ところ、上記第４の１（１）の引用文献１の【００２８】の記載及び保険金請求受付画面の一例を示す図である【図６】によれば、「請求事務代行端末１２」は「入力画面３９」を「保険加入者端末１１」に表示して、上記情報を入力させる手段である「画面表示部」を備えているといえる。

したがって、引用発明の「保険加入者端末１１の入力画面３９において入力された保険金請求の事由、その原因、保険事故が発生した日といった保険金の請求依頼に関する情報」を入力させる手段と、本願発明１の「前記保険情報取得部によって取得された前記保険情報が示す種目に応じた情報入力画面を前記ユーザ端末に表示して、前記種目の保険について保険金の支払請求を保険会社に対してするための情報を入力させる画面表示部」は、「情報入力画面を前記ユーザ端末に表示して、保険金の支払請求を保険会社に対してするための情報を入力させる画面表示部」である点で共通する。

エ 引用発明は「保険金の請求依頼に関する情報とサービス登録者の個人情報を送信することにより、サービス登録者の契約している全ての保険事業者端末１３に審査を依頼する」ところ、「保険金の請求依頼に関する情報」は、上記ウのとおり、「入力画面３９」において入力した「保険金請求の事由、その原因、保険事故が発生した日といった保険金の請求依頼に関する情報」であり、当該情報を「保険事業者端末１３」に送信して、保険金が支払われるか否かの審査を依頼している。

そうすると、引用発明の「請求事務代行端末１２」は、「入力画面３９」において入力した「保険金請求の事由、その原因、保険事故が発生した日といった保険金の請求依頼に関する情報」を「保険事業者端末１３」に送信して、保険金が支払われるか否かの審査を依頼する、すなわち、保険金の支払請求を行う手段である「支払請求部」を備えているといえる。

したがって、引用発明の「入力画面３９」において入力した「保険金請求の事由、その原因、保険事故が発生した日といった保険金の請求依頼に関する情報」を「保険事業者端末１３」に送信して、保険金が支払われるか否かの審査を依頼する手段と、本願発明１の「前記保険情報が示す証券番号と、前記画面表示部によって表示された前記情報入力画面に入力された入力情報とを保険会社装置に送信して、前記保険金の支払請求を行う支払請求部」とは、「前記画面表示部によって表示された前記情報入力画面に入力された入力情報を保険会社装置に送信して、前記保険金の支払請求を行う支払請求部」である点で共通する。

以上によれば、本願発明１と引用発明とは、次の一致点及び相違点を有する。

［一致点］

ユーザ端末から保険情報を取得する保険情報取得部と、

情報入力画面を前記ユーザ端末に表示して、保険金の支払請求を保険会社に対してするための情報を入力させる画面表示部と、

前記画面表示部によって表示された前記情報入力画面に入力された入力情報を保険会社装置に送信して、前記保険金の支払請求を行う支払請求部と

を備える保険仲介装置。

［相違点］

［相違点１］

本願発明１は、「保険情報取得部」が取得する「保険情報」が「保険の種目及び証券番号を示す」ものであり、「画面表示部」が表示する「情報入力画面」が「前記保険情報取得部によって取得された前記保険情報が示す種目に応じた」ものであって、「保険金の支払請求を保険会社に対してするための情報を入力させる」のが「前記種目の保険について」であり、「支払請求部」が支払請求を行う際に、「入力情報」に加えて「前記保険情報が示す証券番号」を送信しているのに対し、引用発明では、「保険情報」が「保険金請求の事由、その原因、保険事故が発生した日といった保険金の請求依頼に関する情報」であって、「保険の種目及び証券番号を示す」ものではないから、本願発明１の上記「画面表示部」及び上記「支払請求部」のように特定されるものではない点。

［相違点２］

本願発明１は、「画面表示部」が「前記情報入力画面に入力された前記入力情報を示した同意画面を前記ユーザ端末に表示して、前記入力情報によって特定される前記支払請求に限定した診断書の前記保険会社による取得に同意するか否かを示す同意情報の入力をさせ」、「支払請求部」が「前記入力情報とともに、前記同意情報を前記保険会社装置に送信」するのに対し、引用発明は、「診断書や入院状況報告書など医療機関で必要書類を発行してもらう必要がある場合には、医療機関端末１４に書類提出の依頼に関する情報を送信し、発行された書類に関するデータを受信する」ものであって、「診断書」を「保険事業者」が取得するものではないから、「画面表示部」が「前記入力情報によって特定される前記支払請求に限定した診断書の前記保険会社による取得に同意するか否かを示す同意情報」をユーザ端末に表示するものではなく、本願発明１の上記「画面表示部」及び上記「支払請求部」のように特定されるものでもない点。

（２） 判断

事案に鑑み、相違点２について検討する。

引用発明の「請求事務代行端末１２」（保険仲介装置）は、「診断書や入院状況報告書など医療機関で必要書類を発行してもらう必要がある場合には、医療機関端末１４に書類提出の依頼に関する情報を送信し、発行された書類に関するデータを受信する」ものであるところ、「診断書」は「医療機関」の「医療機関端末１４」が発行し、「請求事務代行端末１２」が受信するものである。

そうすると、引用発明では、「保険事業者」が自ら「診断書」を取得することはなく、そのため「請求事務代行端末１２」は「保険事業者」が「診断書」を取得するための同意情報を「保険加入者」に入力させる必要はないから、引用発明において、相違点２に係る構成のように「画面表示部」が「前記情報入力画面に入力された前記入力情報を示した同意画面を前記ユーザ端末に表示して、前記入力情報によって特定される前記支払請求に限定した診断書の前記保険会社による取得に同意するか否かを示す同意情報の入力をさせ」るように構成したり、「支払請求部」が「前記入力情報とともに、前記同意情報を前記保険会社装置に送信」するように構成する動機付けはない。

そして、引用文献２～７（上記第４の２～７）をみても、相違点２に係る構成は記載されておらず、周知技術であるということもできない。

したがって、引用発明において、相違点２に係る構成を採用することは、当業者であっても、容易に想到し得るものではない。

以上によれば、相違点１について検討するまでもなく、本願発明１は、当業者であっても、引用文献１～７に記載された発明に基づいて容易に発明をすることができたものであるとはいえない。

２ 本願発明２～７について

本願発明２～７は、本願発明１の「保険仲介装置」について、さらに限定する構成を付加し、本願発明１を減縮する発明であるから、上記１の［相違点］に係る構成を有する。

そうすると、本願発明２～７は、上記１と同様、当業者であっても、引用文献１～７に記載された発明に基づいて容易に発明をすることができたものであるとはいえない。

３ 本願発明８及び９について

本願発明８及び９は、それぞれ、本願発明１の「保険仲介装置」に対応する「保険仲介方法」及び「保険仲介プログラム」の発明であって、発明のカテゴリーが相違するのみであるから、上記１の［相違点］に係る構成に対応する構成を有する。

そうすると、本願発明８及び９は、上記１の本願発明１についての対比・判断と同様、当業者であっても、引用文献１～７に記載された発明に基づいて容易に発明をすることができたものであるとはいえない。

４ 本願発明１０について

本願発明１０は「保険契約者によって使用されるユーザ端末と、保険会社によって使用される保険会社装置と、保険仲介装置とを備える保険仲介システム」であるところ、当該「保険仲介装置」は、本願発明１の「保険仲介装置」と同じ特定がされているから、上記１の［相違点］に係る構成を有する。

そうすると、本願発明１０は、上記１と同様、当業者であっても、引用文献１～７に記載された発明に基づいて容易に発明をすることができたものであるとはいえない。

第６ むすび

以上のとおり、本願請求項１～１０に係る発明は、当業者であっても、引用文献１～７に記載された発明に基づいて容易に発明をすることができたものであるとはいえない。

したがって、原査定の理由によっては、本願を拒絶することはできない。

また、他に本願を拒絶すべき理由を発見しない。

よって、結論のとおり審決する。