【事件の表示】
　特願２０１９−　　１２９０「連絡先情報共有用のコミュニケーションシステム、方法、およびコンピュータプログラム」拒絶査定不服審判事件〔令和　２年　７月２７日出願公開、特開２０２０−１１２８７１、請求項の数（４）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、平成３１年１月８日の特許出願であって、その手続の経緯は以下のとおりである。
　　令和　元年１１月２９日付け：拒絶理由通知書
　　令和　２年　２月２０日　　：意見書、手続補正書の提出
　　令和　２年　６月　５日付け：拒絶査定
　　令和　２年　９月１１日　　：審判請求書、手続補正書の提出
第２　原査定の概要
　原査定（令和２年６月５日付け拒絶査定）の概要は次のとおりである。
　本願請求項１〜４に係る発明は、以下の引用文献１〜５に基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
引用文献等一覧
　１.特開２０１７−２２８０９９号公報
　２.特開２０１７−８４０４８号公報
　３.特開２００９−１７５８９８号公報
　４.特開２０１４−６３４５９号公報
　５.中村勇介，”ビジネスに使えるＬＩＮＥのマーケティング”，ＬＩＮＥ　ビジネス活用の極意１００，日経ＢＰ社，２０１７年８月１０日，ｐ．１０−１１，３８
第３　審判請求時の補正について
　審判請求時（令和２年９月１１日）の補正によって請求項１〜４に「出勤日当日に担当する」という事項を追加する補正は、当初明細書の段落【００４５】の「第一生成部２２は、患者情報テーブル２４ａに記憶されている各患者に対する
当日の担当看護師の情報（関連付け情報）に基づいて
　そして、「第４　本願発明」から「第６　対比・判断」までに示すように、補正後の請求項１〜４に係る発明は、独立特許要件を満たすものである。
　よって、審判請求時の補正は、特許法第１７条の２第３項から第６項までの要件に違反しているものとはいえない。
第４　本願発明
　本願の請求項１〜４に係る発明（以下、それぞれ「本願発明１」…「本願発明４」という。）は、令和２年９月１１日の手続補正で補正された特許請求の範囲の請求項１〜４に記載された事項により特定される発明であって、本願発明１は以下のとおりの発明である。
「【請求項１】
　ケア担当者が携帯するための複数の携帯端末と、
　前記複数の携帯端末と通信可能なサーバと、
を備え、
　前記サーバは、
　　前記ケア担当者が出勤日当日に担当するケア対象者を選択するための選択画面データを生成する第一生成部と、
　　前記選択画面データに基づいて前記携帯端末の表示部に表示された選択画面を介して選択された前記ケア対象者の関係者の連絡先情報を記憶する記憶部と、
　　前記連絡先情報に基づいて、複数の前記関係者を参加メンバとするチャットルームを生成する第二生成部と、
　　前記連絡先情報に基づいて、関係者の各々が有する通信端末にメッセージを一斉に投稿することが可能な投稿部と、
　を備え、
　前記連絡先情報は、前記携帯端末を介して、編集可能であり、
　さらに、
　前記投稿部は、前記ケア担当者が属している組織の代表アカウントを用いて、前記チャットルームを介して当該チャットルームの参加メンバに、メッセージを一斉に投稿することが可能である、
　連絡先情報共有用のコミュニケーションシステム。」
　なお、本願発明２及び３は、本願発明１を減縮した発明である。
　また、本願発明４は、本願発明の「ケア担当者」及び「ケア対象者」を「担当者」及び「対象タスク」にした発明である。
第５　引用文献、引用発明等
１　引用文献１
　原査定の拒絶の理由で引用された引用文献１（特開２０１７−２２８０９９号公報）には、次の事項が記載されている。（下線は、当審が付与した。以下同じ。）
　「【技術分野】
【０００１】
　本発明は、患者情報表示システム及び患者情報表示方法に関する。」
　「【発明が解決しようとする課題】
【０００５】
　ところで、在宅患者のケアを向上するには、患者が在宅療養を開始した時点における患者の状態を示す基準情報（ベースライン情報）と、在宅療養を開始した後に生成された時系列情報（タイムライン情報）の両方を確認する必要がある。在宅療養では、患者に対して医師、看護師、訪問介護員、患者の家族等、属性毎に、患者に対する関わり方が異なる複数のメンバーが存在するため、各情報がどの属性のメンバーから得られたものであるかという点も重要である。
　従来は、患者に関する患者情報を基準情報と時系列情報とに分類し、さらに各情報の出所を明らかにしたうえで、１画面内に表示する画面構成は存在しなかった。
【０００６】
　本発明は、上記の従来技術における問題に鑑みてなされたものであって、患者情報を認識しやすいように表示することを課題とする。」
　「【００１９】
〔在宅療養連携システムの構成〕
　図１に、本実施の形態における患者情報表示システムとしての在宅療養連携システム１００のシステム構成を示す。
　図１に示すように、
在宅療養連携システム１００は、地域のデータセンターに設置されたデータ管理装置１０と、在宅療養中の患者やその家族、在宅療養に携わる医療、看護、介護の各施設に属する医師、看護師、訪問介護員等の使用者が使用可能な使用者端末２０と、を備えて構成されている。データ管理装置１０と使用者端末２０とは、通信ネットワークＮを介して接続可能となっている。
【００２０】
　データ管理装置１０は、医療情報ＤＢ（Data Base）１６１、ファイル格納部１６２等を備え、各使用者により使用者端末２０から登録された医療情報を蓄積し管理する。データ管理装置１０は、クラウド環境に設けられたクラウドサーバーであってもよい。
【００２１】
　
使用者端末２０は、各施設内又は在宅療養中の患者宅で使用されるＰＣ（Personal Computer）、タブレット端末、スマートフォン等である。
　「【００２３】
〔データ管理装置の構成〕
　図２に、データ管理装置１０の機能的構成を示す。
　図２に示すように、
データ管理装置１０は、制御部１１、操作部１２、表示部１３、通信部１４、ＲＡＭ１５、記憶部１６等を備え
　（中略）
【００３０】
　
記憶部１６には、患者に関する患者情報が、所定の時点における患者の状態を示す基準情報（ベースライン情報）と、所定の時点より後に生成され時間の経過とともに蓄積されていく時系列情報（タイムライン情報）と、に分類されて記憶されている。
　「【００７１】
　次に、
使用者端末２０において、操作部２２からの操作により、患者の選択が指示される
　データ管理装置１０では、通信部１４により使用者端末２０から患者選択指示が受信されると、使用者端末２０に対し、患者リスト画面を表示するための表示用データが送信される。
　（中略）
【００７５】
　次に、
使用者端末２０において、操作部２２からの操作により、患者情報のアップロードが指示されると
　データ管理装置１０では、通信部１４により使用者端末２０から患者情報のアップロード指示が受信されると、使用者端末２０に対し、アップロード用画面を表示するための表示用データが送信される。
【００７６】
　使用者端末２０では、通信部２４によりアップロード用画面の表示用データが受信されると、
表示部２３にアップロード用画面が表示され
【００７７】
　ファイル情報を登録する際には、アップロード用画面として、図１５に示すファイル管理画面２３２が表示される。ファイル管理画面２３２には、フォルダー表示欄４１、ファイル指定欄４２が含まれる。
　フォルダー表示欄４１には、ファイル格納部１６２における対象患者の患者専用フォルダーの下位階層のフォルダー構成が表示される。操作部２２からの操作により、フォルダー上にマウスポインターを合わせて、マウスの左ボタンをクリックすると、フォルダーが選択された状態となる。また、操作部２２からの操作により、フォルダー上にマウスポインターを合わせて、マウスの右ボタンをクリックすると、メニューが表示される。ベースラインフォルダー、タイムラインフォルダー上でマウスの右ボタンをクリックし、表示されるメニューから新しいフォルダーの作成が可能となっている。
　操作部２２からの操作により、表示部２３において、別画面に表示されているファイルの中からアップロード対象のファイルをドラッグし、ファイル指定欄４２にドロップすることで、フォルダー表示欄４１で選択されているフォルダー内に、ドロップされたファイルがアップロードされる。フォルダー表示欄４１で選択されたフォルダーに応じて、アップロード対象のファイルが基準情報又は時系列情報のいずれに分類される情報であるかが区別される。
【００７８】
　文字・数字情報を登録する際には、
アップロード用画面として、図１６に示す編集画面２３３が表示される。編集画面２３３には、患者情報の各項目の入力欄が含まれる。編集画面２３３は、ベースライン入力欄５１、タイムライン入力欄５２を有し、入力欄に応じて、基準情報又は時系列情報のいずれに分類される情報であるかが区別される。各項目に対応する入力欄に情報を入力し、保存ボタン５３を押下することで、入力された情報がデータ管理装置１０にアップロードされる。
【００７９】
　使用者端末２０において、操作部２２からの操作により、アップロード用画面上でアップロード操作が行われると（ステップＳ１７）、アップロード対象の患者情報が通信部２４によりデータ管理装置１０に送信される。患者情報がファイル情報の場合には、ファイル管理画面２３２におけるファイルドロップ操作がアップロード操作となる。一方、患者情報が文字・数字情報の場合には、編集画面２３３における各入力欄への情報入力及び保存ボタン５３の押下がアップロード操作となる。
【００８０】
　データ管理装置１０では、通信部１４によりアップロード対象の患者情報が取得されると（ステップＳ１８）、制御部１１により、アップロード対象の患者情報が、基準情報又は時系列情報に分類されて、登録者の属性、登録日時と対応付けられて保存される（ステップＳ１９）。具体的には、医療情報ＤＢ１６１の患者情報テーブルＴ２において、アップロードされた患者情報の分類に応じて、対象患者の患者ＩＤに対応付けられたベースラインテーブルＴ２２又はタイムラインテーブルＴ２３が特定され、特定されたベースラインテーブルＴ２２又はタイムラインテーブルＴ２３に患者情報（項目名と内容、又は、項目名とファイルパス）が格納されるとともに、登録者の使用者ＩＤ、登録日時が格納される。また、医療情報ＤＢ１６１の使用者管理テーブルＴ１から、在宅療養連携システム１００を使用中（ログイン中）の使用者の使用者ＩＤに対応する属性が取得され、ベースラインテーブルＴ２２又はタイムラインテーブルＴ２３に対して、登録者の属性が格納される。
　なお、ファイル情報については、ファイル格納部１６２の、ファイル管理画面２３２で選択されたフォルダー内（「ファイルパス」が示すファイルの格納先）に保存される。」
　図１６として以下の図が記載され、
ベースラインテーブルには、患者基礎情報として、氏名、続柄、電話番号からなる連絡先が複数記憶される
　以上の記載によれば、引用文献１には、次の発明（以下、「引用発明」という。）が記載されている。
　「地域のデータセンターに設置されたデータ管理装置と、在宅療養に携わる医療、看護、介護の各施設に属する医師、看護師、訪問介護員等の使用者が使用可能な、ＰＣ（Personal Computer）、タブレット端末、スマートフォン等の使用者端末と、を備えて構成され、データ管理装置と使用者端末とは、通信ネットワークＮを介して接続可能となっており（【００１９】、【００２１】）、
　データ管理装置は通信部、記憶部等を備え（【００２３】）、記憶部には、所定の時点における患者の状態を示す基準情報（ベースライン情報）が記憶され（【００３０】）、ベースラインテーブルには、患者基礎情報として、氏名、続柄、電話番号からなる連絡先が複数記憶され（図１６）、
　使用者端末において、操作部からの操作により、患者の選択が指示され、患者情報のアップロードが指示されると、表示部に患者情報の各項目の入力欄が含まれる編集画面が表示されるアップロード用画面が表示され、各項目に対応する入力欄に情報を入力し、保存ボタンを押下することで、入力された情報がデータ管理装置にアップロードされる（【００７１】〜【００８０】）
在宅療養連携システム」
２　引用文献２
　原査定の拒絶の理由で引用された引用文献２（特開２０１７−８４０４８号公報）には、次の事項が記載されている。
　「【発明が解決しようとする課題】
【０００７】
　前記従来のメッセージ交換装置や携帯情報端末機は、当該装置や端末機のユーザ同士が円滑にコミュニケーションを図るための手段であって、例えば、当該手段を用いて前記被介護者に関する情報についてその関係者間で連絡を取り合った場合、全ての関係者間で知ってもよい情報について容易に共有できる利点はある。
【０００８】
　また従来、複数のＳＮＳ(Social Networking Service)が一般に利用されており、できるだけ多くの利用者間でのコミュニケーションの向上を目的として、直線的な繋がりを含めた多数の利用者間で各利用者からの投稿を共有するサービスがある他、予め設定したグループ内の関係者間だけでメッセージを共有するサービス、特定の相手とだけメッセージを交換するサービスがある。
【０００９】
　しかしながら、例えば、ある被介護者の関係者のうち介護施設の職員等、他の被介護者の関係者ともなっている共通関係者が含まれている場合に、当該共通関係者が別々の被介護者それぞれの関係者を簡単な操作で選びつつ、選んだ被介護者の関係者間でだけで共有になる情報を投稿や閲覧したり、同関係者間でだけで伝えたいメッセージをやり取りしたりするのを、容易且つ円滑に行うことはできない。
【００１０】
　
本発明は、このような課題に鑑みなされたもので、複数の高齢者や子供の世話など、複数の世話の対象のそれぞれに複数の人物が関わって行なう世話を容易且つ円滑に行なうことが可能になるサーバ装置およびその制御プログラムを提供することを目的とする
　「【００２６】
　
前記サークルサーバ１０に対して、例えば、被介護者Ａの世話を行なう管理者・介護職員Ａと訪問介護職員ＡとケアマネージャＡと家族Ａとの各ユーザ端末２０ｓｔＡ／Ｂ，２０ｈｓｔＡ，２０ｃｍＡ，２０ｆｍＡによるサークルＡを作成することにより、図３に示すように、被介護者Ａの日々の生活の様子を管理者・介護職員Ａ／Ｂの端末２０ｓｔＡ／Ｂから写真と文章で投稿（フィード）してサークルＡ内で共有し家族Ａに伝えたり、逆に家族Ａの様子をその端末２０ｆｍＡから投稿してサークルＡ内で共有し管理者・介護職員Ａ／Ｂの端末２０ｓｔＡ／Ｂで被介護者Ａに伝えたりすることができる。
　「【００７６】
　図１４は、前記サークルサーバ１０のフィード処理に従った管理者・介護職員Ａ／Ｂのユーザ端末２０ｓｔＡ／Ｂの表示動作を示す図である。
【００７７】
　前述したように、前記管理者・介護職員Ａ／Ｂが前記被介護者ＡのサークルＡと前記被介護者ＢのサークルＢに共通のメンバとして登録された状態で、当該管理者・介護職員Ａ／Ｂのユーザ端末２０ｓｔＡ／Ｂから前記サークルサーバ１０に対して、サークル一覧の要求が受信されると（ステップＳ４０１（Ｙｅｓ））、図１４（Ａ）に示すように、同管理者・介護職員Ａ／Ｂがメンバとして登録されているサークルＡの項目ＳＡとサークルＢの項目ＳＢとを一覧にしたサークル一覧画面Ｇｃｌが生成され、前記ユーザ端末２０ｓｔＡ／Ｂへ送信されて表示される（ステップＳ４０２）。
【００７８】
　ここで、前記サークル一覧画面Ｇｃｌには、そのサークルＡ／Ｂの項目ＳＡ／ＳＢ毎に、フィード画面へのリンクとなるフィードリンクアイコンＲＦａ／ＲＦｂと、メッセージ画面へのリンクとなるメッセージリンクアイコンＲＭａ／ＲＭｂとが設けられる。
【００７９】
　そして、前記サークル一覧画面Ｇｃｌの各サークル項目ＳＡ／ＳＢ毎のフィードリンクアイコンＲＦａ／ＲＦｂには、該当メンバ（サークル一覧要求元）である管理者・介護職員Ａ／Ｂの新着（未読）フィード数が、サークルＡ／Ｂの各サークルメンバ記憶エリア１２Ａ３／１２Ｂ３から読み出されて丸数字で付加される。また、各サークル項目ＳＡ／ＳＢ毎のメッセージリンクアイコンＲＭａ／ＲＭｂには、同該当メンバの新着（未読）メッセージ数が同該当メンバの属するサブグループでの新着メッセージ数の合計の数として同サークルＡ／Ｂの各サークルメンバ記憶エリア１２Ａ３／１２Ｂ３から読み出されて丸数字で付加される（ステップＳ４０３）。
【００８０】
　さらに、前記サークル一覧画面Ｇｃｌの上部に設けられたお知らせアイコンＰには、前記該当メンバの新着（未読）フィード数と新着（未読）メッセージ数の総合計が丸数字で付加される（ステップＳ４０４）。
【００８１】
　ここで、前記図１４（Ａ）で示している前記管理者・介護職員Ａ／Ｂのユーザ端末２０ｓｔＡ／Ｂに表示されたサークル一覧画面Ｇｃｌの場合では、当該管理者・介護職員Ａ／Ｂが未読であるフィードとメッセージの総合計が“４”で、その内訳として、サークルＡのフィードの未読数が“２”、メッセージの未読数が“１”、サークルＢのメッセージの未読数が“１”あることを容易に確認することができる。
【００８２】
　そして、前記サークル一覧画面Ｇｃｌによれば、各サークル項目Ａ／Ｂ毎にフィードリンクアイコンＲＦａ／ＲＦｂとメッセージリンクアイコンＲＭａ／ＲＭｂとを並べて設けているので、ユーザが属しているサークルＡまたはＢのフィード画面表示かまたはメッセージ画面表示かを容易に選択して当該画面表示に素早く遷移させることができる。
【００８３】
　なお、前記サークル一覧要求元（該当メンバ）がサークルＡのみのメンバとして登録されている家族Ａのユーザ端末２０ｆｍＡ、訪問介護職員Ａのユーザ端末２０ｈｓｔＡ、ケアマネージャ２０ｃｍＡである場合は、当該サークルＡの項目ＳＡだけのサークル一覧画面Ｇｃｌが生成され、該当メンバのユーザ端末２０ｆｍＡ／２０ｈｓｔＡ／２０ｃｍＡへ送信されて表示される（ステップＳ４０１〜Ｓ４０４）。
【００８４】
　そして、前記
サークル一覧画面Ｇｃｌが表示された管理者・介護職員Ａ／Ｂのユーザ端末２０ｓｔＡ／Ｂにおいて
【００８５】
　例えば、前記図１４（Ａ）で示したサークル一覧画面Ｇｃｌにおいて、サークルＡの項目ＳＡのフィードリンクアイコンＲＦａが選択されて操作された場合に、前記サークルサーバ１０において、前記サークルＡの「フィード」が選択されたと判断されると（ステップＳ４０６「フィード」）、前記サークルデータ記憶エリア１２Ａのフィード記憶エリア１２Ａ４に記憶されているフィードデータ１．２．…が読み出され、図１４（Ｂ）に示すように、サークルＡのフィードＦ１，Ｆ２，…を一覧にしたフィード一覧画面ＧＦｃａとして前記管理者・介護職員Ａ／Ｂのユーザ端末２０ｓｔＡ／Ｂに送信されて表示される（ステップＳ４０７）。
【００８６】
　ここで、前記ユーザ端末２０ｓｔＡ／Ｂに送信されて表示されるサークルＡのフィード一覧画面ＧＦｃａには、その上部に［投稿する］アイコンとメッセージ画面に遷移させるメッセージリンクアイコンＲＭａが付加され、さらに当該メッセージリンクアイコンＲＭａには、前記サークルメンバ記憶エリア１２Ａ３から読み出された該当メンバ（ここでは管理者・介護職員Ａ／Ｂ）の新着メッセージ数（サブグループ合計）が丸数字で付加されて表示される。
【００８７】
　こうして、前記管理者・介護職員Ａ／Ｂのユーザ端末２０ｓｔＡ／Ｂに対してサークルＡのフィード一覧画面ＧＦｃａが送信されて表示されると、前記サークルメンバ記憶エリア１２Ａ３の当該管理者・介護職員Ａ／Ｂに対応付けて記憶されている新着フィード数がリセットされる（ステップＳ４０８）。
【００８８】
　そして、前記ユーザ端末２０ｓｔＡ／Ｂのフィード一覧画面ＧＦｃａに付加されている［投稿する］アイコンが操作されることにより、当該ユーザ端末２０ｓｔＡ／Ｂから前記サークルサーバ１０に対して投稿要求が受信されると（ステップＳ４０９（Ｙｅｓ））、当該サークルサーバ１０において、図１４（Ｃ）に示すように、前記サークルＡに対する新規投稿画面ＧＦｉが生成され、前記ユーザ端末２０ｓｔＡ／Ｂに送信されて表示される（ステップＳ４１０）。
【００８９】
　
前記ユーザ端末２０ｓｔＡ／Ｂに表示された新規投稿画面ＧＦｉにおいて、当該端末ユーザにより任意の写真や文字による情報が入力され、［投稿］アイコンが操作されると、当該入力された情報が、前記サークルサーバ１０に新規投稿データとして受信され、前記サークルデータ記憶エリア１２Ａのフィード記憶エリア１２Ａ４に最新のフィード１．として書き込まれる
　以上の記載によれば、引用文献２には、次の技術事項が記載されている。
　「複数の高齢者や子供の世話など、複数の世話の対象のそれぞれに複数の人物が関わって行なう世話を容易且つ円滑に行なうことが可能にするために（【００１０】）、
　被介護者Ａの世話を行なう管理者・介護職員Ａと訪問介護職員ＡとケアマネージャＡと家族Ａとの各ユーザ端末２０ｓｔＡ／Ｂ，２０ｈｓｔＡ，２０ｃｍＡ，２０ｆｍＡによるサークルＡが作成され（【００２６】）、
　管理者・介護職員Ａ／Ｂのユーザ端末２０ｓｔＡ／Ｂに表示された新規投稿画面ＧＦｉにおいて、当該端末ユーザにより任意の写真や文字による情報が入力され、［投稿］アイコンが操作されると、当該入力された情報が、前記サークルサーバに新規投稿データとして受信される（【００７６】〜【００８９】）こと」
３　引用文献３
　原査定の拒絶の理由で引用された引用文献３（特開２００９−１７５８９８号公報）には、次の事項が記載されている。
　「【００８７】
　次に、本実施の形態のメールシステムにおける処理の手順について説明する。まず、本実施の形態のメールサーバ１００において、ユーザが受信メールを確認するときに実行されるメールボックス処理について説明する。
【００８８】
　図９は、メールボックス処理の手順を示すフローチャートである。
　本実施の形態のメールサーバ１００は、組織３０に属するユーザが使用する端末装置３１，３２，・・・（例えば、端末装置３１）から送信された電子メールの閲覧要求を受信すると、これに応じて、メールボックス処理により、そのユーザ宛の電子メールの情報をその端末装置に提供し、その端末装置上のブラウザによって表示させる。
【００８９】
　［ステップＳ１１］メールサーバ１００のＣＰＵ１０１は、端末装置３１からのユーザによる電子メールの閲覧要求を受信すると、端末装置３１，３２，・・・に対してＬＡＮ１０を介してそのユーザのユーザＩＤについてアカウント認証を行う。アカウント認証に成功すると、ユーザは認証されたアカウントでメールシステムにログインされる。
【００９０】
　［ステップＳ１２］ＣＰＵ１０１は、
端末装置３１から送信される、ユーザによる電子メールを閲覧するアカウントの選択指示を受け付ける。これにより、個人アドレスまたは代表アドレスのうち、ユーザが閲覧を希望する電子メールのアカウントが、端末装置３１，３２，・・・からメールサーバ１００に通知される。
【００９１】
　［ステップＳ１３］ＣＰＵ１０１は、端末装置３１，３２，・・・から送信される閲覧終了指示を受け付けたか否かを判定する。ＣＰＵ１０１は、閲覧終了指示を受け付けていなければ、ステップＳ１４に処理を進める一方、閲覧終了指示を受け付けていれば、処理を終了する。
【００９２】
　［ステップＳ１４］ＣＰＵ１０１は、ステップＳ１２で受け付けた選択指示に基づいて、ユーザが選択した電子メールのアカウントに対応するアカウントＩＤ（図７参照）を取得する。これにより、
端末装置３１，３２，・・・のブラウザ上で、ユーザが個人アドレスの電子メールの閲覧を選択した場合には、個人アドレスに対応するアカウントＩＤが取得される一方、ユーザが代表アドレスの電子メールの閲覧を選択した場合には、代表アドレスに対応するアカウントＩＤが取得される。
【００９３】
　［ステップＳ１５］ＣＰＵ１０１は、ステップＳ１４で取得したアカウントＩＤのメール情報を取得する。
　［ステップＳ１６］ＣＰＵ１０１は、ユーザからの閲覧要求が送信された端末装置３１，３２，・・・に対して、ステップＳ１５で取得したメール情報を送信する。
【００９４】
　［ステップＳ１７］ＣＰＵ１０１は、ユーザが端末装置３１，３２，・・・によって、ステップＳ１２で選択を受け付けたアカウントにおいて返信メールの作成が行われたか否かを判定する。ユーザが返信メールの作成を行っていれば、ステップＳ１８に処理を進める一方、ユーザが返信メールの作成を行っていなければ、ステップＳ１２に処理を進める。
【００９５】
　［ステップＳ１８］ＣＰＵ１０１は、
ユーザが作成する返信メールの送信元（返信元）となる返信アドレスとして、ステップＳ１２で選択したアカウントのアドレスである、取得したアカウントＩＤのメールアドレスを設定する。
　以上の記載によれば、引用文献３には、次の技術事項が記載されている。
　「閲覧を希望する電子メールのアカウントを個人アドレスまたは代表アドレスのうちから選択し、選択したアカウントに送信された電子メールを閲覧するとともに、返信メールの送信元（返信元）となる返信アドレスとして選択されたアカウントを設定すること」
４　引用文献４
　原査定の拒絶の理由で引用された引用文献４（特開２０１４−６３４５９号公報）には、次の事項が記載されている。
　「【００３７】
　インタフェース部２１０は、個人アカウントを用いるユーザに対して、友だち管理などのためのインタフェースを提供し、公式アカウントを用いるイベント生成者に対して、イベント生成及びイベント管理のためのインタフェースを提供する。本実施形態において、公式アカウントのイベント進行時に該当のアカウントを友だちと設定したユーザごとに、独立的なイベントチャットルームが生成及び保持されることに伴う複数のチャットルームを管理するために、イベント生成者に対して全般的な管理サービスを提供してもよい。すなわち、イベント生成者は、メッセンジャーオンエアーサービスシステム２００のインタフェース環境で提供される管理サービスによって、イベント特定及びユーザとの送受信メッセージに対する確認などが、可能である。」
　「【００４７】
　図１３を参照すると、送信用アカウント画面１３００では、イベント生成者がイベントメッセージを発送するとき用いる公式アカウントを管理してもよい。イベント生成者は、送信用アカウント画面１３００によって、公式アカウントをコード形式で示したＱＲコード（登録商標）１３０１を確認することができる。ここで、イベント生成者は、送信を希望しているユーザに対してＱＲコード（登録商標）を送信してもよい。当該ユーザは、受信したＱＲコード（登録商標）を用いて、公式アカウントを友だち目録に追加してもよい。また、イベント生成者は、送信用アカウント画面１３００によって公式アカウントに設定されたパスワード１３０２を確認してもよい。ここで、パスワード１３０２は、イベント生成者が端末上のメッセンジャープラットフォームでイベントメッセージを発送しようとするときに、イベント生成者の認証のために使用されてもよい。また、送信用アカウント画面１３００では、パスワード１３０２を修正可能とする機能が提供されてもよい。すなわち、パスワード１３０２は、端末上のメッセンジャープラットフォームでイベントメッセージを発送するとき使用されることによって、管理サービスのウェブサイト接続時に用いられるログインパスワードと同一に用いられたり、ログインパスワードとは区分して別途に設定されてもよい。そして、送信用アカウント画面１３００では、イベント生成者がユーザにイベントメッセージを発送するとき、予めメッセージ発送の意思を確認するか否かを設定するメッセージ送信前確認機能１３０３が提供されてもよい。」
　「【００５６】
　したがって、メッセンジャーオンエアーサービスシステムは、メッセンジャーで公式アカウントの参加型イベントのためのチャットルームを生成してイベントメッセージを複数のユーザに一括発送するが、イベント生成者とユーザとの間に共通する１つのチャットルームでチャット可能とするのではなく、ユーザごとに個別的な空間でチャットできるように、独立的なチャットルームを生成及び保持してもよい。さらに、メッセンジャーオンエアーサービスシステムは、イベントに参加するユーザごとに生成された複数のチャットルーム管理のための管理サービスを提供することにおいて、図９から図１６を参照して説明したインタフェース環境をイベント生成者に提供してもよい。」
　以上の記載によれば、引用文献４には、次の技術事項が記載されている。
　「個人アカウントを用いるユーザに対して、友だち管理などのためのインタフェースを提供するとともに、公式アカウントを用いるイベント生成者に対して、イベント生成及びイベント管理のためのインタフェースを提供し、公式アカウントの参加型イベントのためのチャットルームを生成してイベントメッセージを複数のユーザに一括発送すること」
５　引用文献５
　原査定の拒絶の理由で引用された引用文献５（中村勇介，”ビジネスに使えるＬＩＮＥのマーケティング”，ＬＩＮＥ　ビジネス活用の極意１００，日経ＢＰ社，２０１７年　８月１０日，p.10-11,38，ISBN:978-4-8222-5908-2）には、次の事項が記載されている。
　「０１　マーケティング　ＬＩＮＥ公式アカウント
「ＬＩＮＥ」利用者に企業から直接情報を発信できる。企業向けの公式アカウントサービス。この「ＬＩＮＥ公式アカウント」を解説すると、ＬＩＮＥ上の公式アカウント一覧に掲載される。この一覧から、企業やブランドのアカウントに「友だち」登録した人に対して、情報を発信できる。
　ＬＩＮＥ公式アカウントを活用して、情報を発信する方法は、大きく２つある。１つは、「メッセージ」機能だ。メールマガジンのような感覚で一括して情報を配信できる。テキスト以外のコンテンツを配信できる機能も用意されている。「リッチビデオメッセージ」は、自動再生される動画をメッセージとして送れる。「クーポン・イベント作成」を使えば割引クーポンやアンケートページを作成して配信できる。
　もう１つは、「タイムライン」機能だ。ＬＩＮＥには直接、友人に連絡できる機能の他、Ｆａｃｅｂｏｏｋなどのように、近況を投稿できるタイムライン機能がある。ＬＩＮＥ公式アカウントを利用する企業は、このタイムラインにキャンペーン情報や新商品の情報などを、写真付きで投稿できる。
　利用者は企業から受け取ったメッセージに対して返信はできないが、タイムラインでは投稿に「いいね！」やコメントを付けられる。」（第１０頁）
　「０２　ＣＲＭ　ＬＩＮＥビジネスコネクト
　企業が「ＬＩＮＥ」に開設したアカウントと、企業が持つ顧客データベースや基幹システムなどを接続して、連携可能にする仕組み。最も基本的な活用方法は、顧客データなどに基づくメッセージの出し分けだ。
　従来のＬＩＮＥの企業アカウントは、登録された「友だち」に対して一律のメッセージ配信しかできなかった。そのため、登録者の性別や居住地といった属性情報に基づいて、登録者に合わせた情報発信を可能にするサービスが求められていた。「ＬＩＮＥビジネスコネクト」（ＢＣ）を使って自社の顧客データベースなどと接続すると、蓄積している性別、年齢、居住地、過去の購入履歴といった企業が持つ顧客情報に基づいてメッセージを出し分けることができる。例えば、旅行会社のエイチ・アイ・エスは、公式アカウントで友だち登録者が「ツアー」とメッセージを送った後に、行き先を送信すると、お薦めのツアーを紹介する仕組みを実現している。これはあくまで活用事例の１つにすぎない。ＬＩＮＥ上級執行役員の田端信太郎氏は、「ＬＩＮＥ公式アカウント宛てにメッセージを送るだけで、ピザを注文できる、銀行口座の残高照会ができる、宅配便の再配達を依頼できる、ＬＩＮＥビジネスコネクトを使えばそんな活用法も可能にある」とサービスの持つ可能性を説明する。
　ＬＩＮＥとの密な連携によって注文や取引の利便性を高め、それで売り上げが増えれば、企業にとって確かに魅力的である。一方でＬＩＮＥは活用企業の基幹システムと接続することで、キャンペーン的な利用のみではなく、永続的に利用してもらえるマーケティングプラットフォームとなることを狙う。」（第１１頁）
　「０４　社内連絡　トークルーム＆グループ　急用と情報共有、目的で使い分け
　ＬＩＮＥには、複数人で会話をする方法が主に２つある。１つ目は「グループ」だ。これはグループに招待した人から承諾を得なければメッセージを配信できないが、「ノート」機能が使えるため、「週次の数値共有などをノートに残しておく」（ＬＩＮＥの営業担当者）など、さまざまな情報の共有に向く。もう１つは「トークルーム」だ。トークルームは作った瞬間に連絡を取れるため、グループに参加していない社員や外部の取引先などに緊急の連絡をする際に利用できる。「突発的な飲み会への誘いに使える」（同）。」（第３８頁）
　以上の記載によれば、引用文献５には、次の技術事項が記載されている。
　「ＬＩＮＥには、利用者に企業から直接情報を発信できる企業向けの公式アカウントサービスがあり、公式アカウントサービスには、「メッセージ」機能と「タイムライン」機能がある。
　また、「ＬＩＮＥ」に開設したアカウントと、企業が持つ顧客データベースや基幹システムなどを接続して連携することで、顧客データなどに基づくメッセージの出し分けを可能とするＬＩＮＥビジネスコネクトのサービスがある。
　さらに、ＬＩＮＥには、複数人で会話をする方法として、「グループ」機能と「トークルーム」機能とがあり、「トークルーム」機能を用いることにより、グループに参加していない社員や外部の取引先などに緊急の連絡をすることが可能となる。」
第６　対比・判断
１　本願発明１について
（１）対比
　本願発明１と引用発明とを対比すると、次のことがいえる。
ア　「携帯端末」について
　引用発明の「在宅療養に携わる医療、看護、介護の各施設に属する医師、看護師、訪問介護員等の使用者が使用可能な使用者端末」は、「在宅療養に携わる医療、看護、介護の各施設に属する医師、看護師、訪問介護員」はケア担当者といえるから、本願発明１の「ケア担当者が携帯するための複数の携帯端末」に相当する。
イ　「サーバ」について
　引用発明では「データ管理装置と使用者端末とは、通信ネットワークＮを介して接続可能となって」いることから、引用発明の「データ管理装置」は、本願発明１の「前記複数の携帯端末と通信可能なサーバ」に相当する。
　また、引用発明では、「データ管理装置は通信部、記憶部等を備え、記憶部には、所定の時点における患者の状態を示す基準情報（ベースライン情報）が記憶され、ベースラインテーブルには、患者基礎情報として、氏名、続柄、電話番号からなる連絡先が複数記憶され」ているから、データ管理装置は、ケア対象者である患者の関係者の連絡先情報を記憶する記憶部を有しているといえる。
　このため、「関係者の連絡先情報」が「前記選択画面データに基づいて前記携帯端末の表示部に表示された選択画面を介して選択された前記ケア対象者の関係者の連絡先情報」である点を除き、本願発明１と引用発明とは、「前記サーバは」「ケア対象者の関係者の連絡先情報を記憶する記憶部」を備えている点で共通する。
ウ　「連絡先情報」が編集可能であることについて
　引用発明では、「使用者端末において、操作部からの操作により、患者の選択が指示され、患者情報のアップロードが指示されると、表示部に患者情報の各項目の入力欄が含まれる編集画面が表示されるアップロード用画面が表示され、各項目に対応する入力欄に情報を入力し、保存ボタンを押下することで、入力された情報がデータ管理装置にアップロードされる」ところ、入力された情報のアップロードは情報の編集に他ならないことから、引用発明は、本願発明１と同様に、「前記連絡先情報は、前記携帯端末を介して、編集可能であ」るといえる。
エ　「連絡先情報共有用のコミュニケーションシステム」
　引用発明は、「使用者端末において、操作部からの操作により、患者の選択が指示され、患者情報のアップロードが指示される…入力された情報がデータ管理装置にアップロードされる」ことから、使用者端末間で連絡先情報は共有されているといえ、また、引用発明の「データ管理装置」は通信部を有するとともに、「使用者端末」は「ＰＣ（Personal Computer）、タブレット端末、スマートフォン等」であり、「データ管理装置」及び「使用者端末」はシステム内又はシステム外とコミュニケーション可能であると考えるのが妥当であるから、コミュニケーション可能な装置を備える「在宅療養連携システム」は「コミュニケーションシステム」であるといえる。
　このため、引用発明は、本願発明１と同様に、「連絡先情報共有用のコミュニケーションシステム」であるといえる。
　したがって、本願発明１と引用発明とは、次の点で一致及び相違する。
＜一致点＞
　ケア担当者が携帯するための複数の携帯端末と、
　前記複数の携帯端末と通信可能なサーバと、
を備え、
　前記サーバは、
　　ケア対象者の関係者の連絡先情報を記憶する記憶部と、
　を備え、
　前記連絡先情報は、前記携帯端末を介して、編集可能である、
　連絡先情報共有用のコミュニケーションシステム。
＜相違点＞
（相違点１）
　本願発明１は、「サーバ」が「前記ケア担当者が出勤日当日に担当するケア対象者を選択するための選択画面データを生成する第一生成部と、前記連絡先情報に基づいて、複数の前記関係者を参加メンバとするチャットルームを生成する第二生成部と」を備えているのに対して、引用発明は、「サーバ」がこれらを備えていない点。
（相違点２）
　本願発明１の「記憶部」が記憶する「関係者の連絡先情報」は、「選択画面データに基づいて前記携帯端末の表示部に表示された選択画面を介して選択された前記ケア対象者の関係者の連絡先情報」であるのに対して、引用発明における「関係者の連絡先情報」はこのような情報ではない点。
（相違点３）
　本願発明１では、「サーバ」が「前記連絡先情報に基づいて、関係者の各々が有する通信端末にメッセージを一斉に投稿することが可能な投稿部」を備え、「前記投稿部は、前記ケア担当者が属している組織の代表アカウントを用いて、前記チャットルームを介して当該チャットルームの参加メンバに、メッセージを一斉に投稿することが可能である」のに対して、引用発明では、このような「投稿部」を備えていない点。
（２）相違点の判断
　事案に鑑み、上記相違点３について検討する。
　引用文献２〜５には、上記「第４」「２」〜同「５」に記載した事項が記載されているところ、いずれの文献にも、「前記連絡先情報に基づいて、関係者の各々が有する通信端末にメッセージを一斉に投稿することが可能な投稿部」を備え、「前記投稿部は、前記ケア担当者が属している組織の代表アカウントを用いて、前記チャットルームを介して当該チャットルームの参加メンバに、メッセージを一斉に投稿することが可能である」ことは記載されていない。
　また、技術常識を参酌しても、引用発明において、「前記ケア担当者が属している組織の代表アカウントを用いて、前記チャットルームを介して当該チャットルームの参加メンバに、メッセージを一斉に投稿することが可能である」「投稿部」を設ける動機付けを引用発明から見いだすことはできない。
　そして、当該事項を記載する他の引用文献も発見されない。
　したがって、本願発明１は、当業者であっても引用発明、及び、引用文献２〜５の記載に基づいて容易に発明できたものではない。
２　本願発明２及び３について
　本願発明２及び３は、少なくとも、上記１で検討した相違点３に係る本願発明１の構成と同一の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明及び引用文献２〜５に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
３　本願発明４について
　本願発明４は、本願発明の「ケア担当者」及び「ケア対象者」を「担当者」及び「対象タスク」にした発明であるから、少なくとも、上記１で検討した相違点３に係る本願発明１の構成と同様な構成を備えるものであり、本願発明１と同じ理由により、当業者であっても、引用発明及び引用文献２〜５に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
第７　むすび
　以上のとおり、本願発明１〜４は、当業者が引用発明及び引用文献２〜５の記載事項に基づいて容易に発明をすることができたものではない。
　したがって、原査定の理由によって、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。