• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 G16H
管理番号 1375419
審判番号 不服2020-12771  
総通号数 260 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-08-27 
種別 拒絶査定不服の審決 
審判請求日 2020-09-11 
確定日 2021-07-06 
事件の表示 特願2019- 1290「連絡先情報共有用のコミュニケーションシステム、方法、およびコンピュータプログラム」拒絶査定不服審判事件〔令和 2年 7月27日出願公開、特開2020-112871、請求項の数(4)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、平成31年1月8日の特許出願であって、その手続の経緯は以下のとおりである。
令和 元年11月29日付け:拒絶理由通知書
令和 2年 2月20日 :意見書、手続補正書の提出
令和 2年 6月 5日付け:拒絶査定
令和 2年 9月11日 :審判請求書、手続補正書の提出


第2 原査定の概要
原査定(令和2年6月5日付け拒絶査定)の概要は次のとおりである。
本願請求項1?4に係る発明は、以下の引用文献1?5に基づいて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
1.特開2017-228099号公報
2.特開2017-84048号公報
3.特開2009-175898号公報
4.特開2014-63459号公報
5.中村勇介,”ビジネスに使えるLINEのマーケティング”,LINE ビジネス活用の極意100,日経BP社,2017年8月10日,ｐ.10-11,38


第3 審判請求時の補正について
審判請求時(令和2年9月11日)の補正によって請求項1?4に「出勤日当日に担当する」という事項を追加する補正は、当初明細書の段落【0045】の「第一生成部22は、患者情報テーブル24aに記憶されている各患者に対する当日の担当看護師の情報(関連付け情報)に基づいて、特定の患者を担当している全ての看護師を一覧的に表示するための担当一覧画面データを生成する(ステップS16)。生成された担当一覧画面データは、記憶部24に記憶される。」との記載に基づいた事項であり、特許請求の範囲の減縮を目的とするものであるから、当該事項を追加する補正は、新規事項を追加するものではないとともに、特許請求の範囲の減縮を目的とするものである。
そして、「第4 本願発明」から「第6 対比・判断」までに示すように、補正後の請求項1?4に係る発明は、独立特許要件を満たすものである。
よって、審判請求時の補正は、特許法第17条の2第3項から第6項までの要件に違反しているものとはいえない。


第4 本願発明
本願の請求項1?4に係る発明(以下、それぞれ「本願発明1」…「本願発明4」という。)は、令和2年9月11日の手続補正で補正された特許請求の範囲の請求項1?4に記載された事項により特定される発明であって、本願発明1は以下のとおりの発明である。

「【請求項1】
ケア担当者が携帯するための複数の携帯端末と、
前記複数の携帯端末と通信可能なサーバと、
を備え、
前記サーバは、
前記ケア担当者が出勤日当日に担当するケア対象者を選択するための選択画面データを生成する第一生成部と、
前記選択画面データに基づいて前記携帯端末の表示部に表示された選択画面を介して選択された前記ケア対象者の関係者の連絡先情報を記憶する記憶部と、
前記連絡先情報に基づいて、複数の前記関係者を参加メンバとするチャットルームを生成する第二生成部と、
前記連絡先情報に基づいて、関係者の各々が有する通信端末にメッセージを一斉に投稿することが可能な投稿部と、
を備え、
前記連絡先情報は、前記携帯端末を介して、編集可能であり、
さらに、
前記投稿部は、前記ケア担当者が属している組織の代表アカウントを用いて、前記チャットルームを介して当該チャットルームの参加メンバに、メッセージを一斉に投稿することが可能である、
連絡先情報共有用のコミュニケーションシステム。」

なお、本願発明2及び3は、本願発明1を減縮した発明である。
また、本願発明4は、本願発明の「ケア担当者」及び「ケア対象者」を「担当者」及び「対象タスク」にした発明である。


第5 引用文献、引用発明等
1 引用文献1
原査定の拒絶の理由で引用された引用文献1(特開2017-228099号公報)には、次の事項が記載されている。(下線は、当審が付与した。以下同じ。)

「【技術分野】
【0001】
本発明は、患者情報表示システム及び患者情報表示方法に関する。」

「【発明が解決しようとする課題】
【0005】
ところで、在宅患者のケアを向上するには、患者が在宅療養を開始した時点における患者の状態を示す基準情報(ベースライン情報)と、在宅療養を開始した後に生成された時系列情報(タイムライン情報)の両方を確認する必要がある。在宅療養では、患者に対して医師、看護師、訪問介護員、患者の家族等、属性毎に、患者に対する関わり方が異なる複数のメンバーが存在するため、各情報がどの属性のメンバーから得られたものであるかという点も重要である。
従来は、患者に関する患者情報を基準情報と時系列情報とに分類し、さらに各情報の出所を明らかにしたうえで、1画面内に表示する画面構成は存在しなかった。
【0006】
本発明は、上記の従来技術における問題に鑑みてなされたものであって、患者情報を認識しやすいように表示することを課題とする。」

「【0019】
〔在宅療養連携システムの構成〕
図1に、本実施の形態における患者情報表示システムとしての在宅療養連携システム100のシステム構成を示す。
図1に示すように、在宅療養連携システム100は、地域のデータセンターに設置されたデータ管理装置10と、在宅療養中の患者やその家族、在宅療養に携わる医療、看護、介護の各施設に属する医師、看護師、訪問介護員等の使用者が使用可能な使用者端末20と、を備えて構成されている。データ管理装置10と使用者端末20とは、通信ネットワークNを介して接続可能となっている。
【0020】
データ管理装置10は、医療情報DB(Data Base)161、ファイル格納部162等を備え、各使用者により使用者端末20から登録された医療情報を蓄積し管理する。データ管理装置10は、クラウド環境に設けられたクラウドサーバーであってもよい。
【0021】
使用者端末20は、各施設内又は在宅療養中の患者宅で使用されるPC(Personal Computer)、タブレット端末、スマートフォン等である。施設としては、主治医が所属する病院や診療所、在宅患者の訪問看護を行う看護師が所属する訪問看護ステーション、在宅患者のケアプランを作成するケアマネージャーや、在宅患者の訪問介護を行う訪問介護員が所属する訪問介護事業所等が挙げられる。」

「【0023】
〔データ管理装置の構成〕
図2に、データ管理装置10の機能的構成を示す。
図2に示すように、データ管理装置10は、制御部11、操作部12、表示部13、通信部14、RAM15、記憶部16等を備えて構成されており、各部はバス17により接続されている。
(中略)
【0030】
記憶部16には、患者に関する患者情報が、所定の時点における患者の状態を示す基準情報(ベースライン情報)と、所定の時点より後に生成され時間の経過とともに蓄積されていく時系列情報(タイムライン情報)と、に分類されて記憶されている。本実施の形態では、所定の時点として、患者が在宅療養を開始した時点を用いる。患者が在宅療養を開始するタイミングとしては、例えば、入院していた患者が退院して在宅患者となった場合や、通院していた患者が在宅患者となった場合等が挙げられる。」

「【0071】
次に、使用者端末20において、操作部22からの操作により、患者の選択が指示されると、患者選択指示が通信部24によりデータ管理装置10に送信される(ステップS13)。
データ管理装置10では、通信部14により使用者端末20から患者選択指示が受信されると、使用者端末20に対し、患者リスト画面を表示するための表示用データが送信される。
(中略)
【0075】
次に、使用者端末20において、操作部22からの操作により、患者情報のアップロードが指示されると、患者情報のアップロード指示が通信部24によりデータ管理装置10に送信される(ステップS15)。
データ管理装置10では、通信部14により使用者端末20から患者情報のアップロード指示が受信されると、使用者端末20に対し、アップロード用画面を表示するための表示用データが送信される。
【0076】
使用者端末20では、通信部24によりアップロード用画面の表示用データが受信されると、表示部23にアップロード用画面が表示される(ステップS16)。
【0077】
ファイル情報を登録する際には、アップロード用画面として、図15に示すファイル管理画面232が表示される。ファイル管理画面232には、フォルダー表示欄41、ファイル指定欄42が含まれる。
フォルダー表示欄41には、ファイル格納部162における対象患者の患者専用フォルダーの下位階層のフォルダー構成が表示される。操作部22からの操作により、フォルダー上にマウスポインターを合わせて、マウスの左ボタンをクリックすると、フォルダーが選択された状態となる。また、操作部22からの操作により、フォルダー上にマウスポインターを合わせて、マウスの右ボタンをクリックすると、メニューが表示される。ベースラインフォルダー、タイムラインフォルダー上でマウスの右ボタンをクリックし、表示されるメニューから新しいフォルダーの作成が可能となっている。
操作部22からの操作により、表示部23において、別画面に表示されているファイルの中からアップロード対象のファイルをドラッグし、ファイル指定欄42にドロップすることで、フォルダー表示欄41で選択されているフォルダー内に、ドロップされたファイルがアップロードされる。フォルダー表示欄41で選択されたフォルダーに応じて、アップロード対象のファイルが基準情報又は時系列情報のいずれに分類される情報であるかが区別される。
【0078】
文字・数字情報を登録する際には、アップロード用画面として、図16に示す編集画面233が表示される。編集画面233には、患者情報の各項目の入力欄が含まれる。編集画面233は、ベースライン入力欄51、タイムライン入力欄52を有し、入力欄に応じて、基準情報又は時系列情報のいずれに分類される情報であるかが区別される。各項目に対応する入力欄に情報を入力し、保存ボタン53を押下することで、入力された情報がデータ管理装置10にアップロードされる。
【0079】
使用者端末20において、操作部22からの操作により、アップロード用画面上でアップロード操作が行われると(ステップS17)、アップロード対象の患者情報が通信部24によりデータ管理装置10に送信される。患者情報がファイル情報の場合には、ファイル管理画面232におけるファイルドロップ操作がアップロード操作となる。一方、患者情報が文字・数字情報の場合には、編集画面233における各入力欄への情報入力及び保存ボタン53の押下がアップロード操作となる。
【0080】
データ管理装置10では、通信部14によりアップロード対象の患者情報が取得されると(ステップS18)、制御部11により、アップロード対象の患者情報が、基準情報又は時系列情報に分類されて、登録者の属性、登録日時と対応付けられて保存される(ステップS19)。具体的には、医療情報DB161の患者情報テーブルT2において、アップロードされた患者情報の分類に応じて、対象患者の患者IDに対応付けられたベースラインテーブルT22又はタイムラインテーブルT23が特定され、特定されたベースラインテーブルT22又はタイムラインテーブルT23に患者情報(項目名と内容、又は、項目名とファイルパス)が格納されるとともに、登録者の使用者ID、登録日時が格納される。また、医療情報DB161の使用者管理テーブルT1から、在宅療養連携システム100を使用中(ログイン中)の使用者の使用者IDに対応する属性が取得され、ベースラインテーブルT22又はタイムラインテーブルT23に対して、登録者の属性が格納される。
なお、ファイル情報については、ファイル格納部162の、ファイル管理画面232で選択されたフォルダー内(「ファイルパス」が示すファイルの格納先)に保存される。」

図16として以下の図が記載され、ベースラインテーブルには、患者基礎情報として、氏名、続柄、電話番号からなる連絡先が複数記憶されることが見て取れる。


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

「地域のデータセンターに設置されたデータ管理装置と、在宅療養に携わる医療、看護、介護の各施設に属する医師、看護師、訪問介護員等の使用者が使用可能な、PC(Personal Computer)、タブレット端末、スマートフォン等の使用者端末と、を備えて構成され、データ管理装置と使用者端末とは、通信ネットワークNを介して接続可能となっており(【0019】、【0021】)、
データ管理装置は通信部、記憶部等を備え(【0023】)、記憶部には、所定の時点における患者の状態を示す基準情報(ベースライン情報)が記憶され(【0030】)、ベースラインテーブルには、患者基礎情報として、氏名、続柄、電話番号からなる連絡先が複数記憶され(図16)、
使用者端末において、操作部からの操作により、患者の選択が指示され、患者情報のアップロードが指示されると、表示部に患者情報の各項目の入力欄が含まれる編集画面が表示されるアップロード用画面が表示され、各項目に対応する入力欄に情報を入力し、保存ボタンを押下することで、入力された情報がデータ管理装置にアップロードされる(【0071】?【0080】)
在宅療養連携システム」

2 引用文献2
原査定の拒絶の理由で引用された引用文献2(特開2017-84048号公報)には、次の事項が記載されている。

「【発明が解決しようとする課題】
【0007】
前記従来のメッセージ交換装置や携帯情報端末機は、当該装置や端末機のユーザ同士が円滑にコミュニケーションを図るための手段であって、例えば、当該手段を用いて前記被介護者に関する情報についてその関係者間で連絡を取り合った場合、全ての関係者間で知ってもよい情報について容易に共有できる利点はある。
【0008】
また従来、複数のSNS(Social Networking Service)が一般に利用されており、できるだけ多くの利用者間でのコミュニケーションの向上を目的として、直線的な繋がりを含めた多数の利用者間で各利用者からの投稿を共有するサービスがある他、予め設定したグループ内の関係者間だけでメッセージを共有するサービス、特定の相手とだけメッセージを交換するサービスがある。
【0009】
しかしながら、例えば、ある被介護者の関係者のうち介護施設の職員等、他の被介護者の関係者ともなっている共通関係者が含まれている場合に、当該共通関係者が別々の被介護者それぞれの関係者を簡単な操作で選びつつ、選んだ被介護者の関係者間でだけで共有になる情報を投稿や閲覧したり、同関係者間でだけで伝えたいメッセージをやり取りしたりするのを、容易且つ円滑に行うことはできない。
【0010】
本発明は、このような課題に鑑みなされたもので、複数の高齢者や子供の世話など、複数の世話の対象のそれぞれに複数の人物が関わって行なう世話を容易且つ円滑に行なうことが可能になるサーバ装置およびその制御プログラムを提供することを目的とする。」

「【0026】
前記サークルサーバ10に対して、例えば、被介護者Aの世話を行なう管理者・介護職員Aと訪問介護職員AとケアマネージャAと家族Aとの各ユーザ端末20ｓｔA/B,20hｓｔA,20cmA,20fmAによるサークルAを作成することにより、図3に示すように、被介護者Aの日々の生活の様子を管理者・介護職員A/Bの端末20ｓｔA/Bから写真と文章で投稿(フィード)してサークルA内で共有し家族Aに伝えたり、逆に家族Aの様子をその端末20fmAから投稿してサークルA内で共有し管理者・介護職員A/Bの端末20ｓｔA/Bで被介護者Aに伝えたりすることができる。」

「【0076】
図14は、前記サークルサーバ10のフィード処理に従った管理者・介護職員A/Bのユーザ端末20ｓｔA/Bの表示動作を示す図である。
【0077】
前述したように、前記管理者・介護職員A/Bが前記被介護者AのサークルAと前記被介護者BのサークルBに共通のメンバとして登録された状態で、当該管理者・介護職員A/Bのユーザ端末20ｓｔA/Bから前記サークルサーバ10に対して、サークル一覧の要求が受信されると(ステップS401(Yeｓ))、図14(A)に示すように、同管理者・介護職員A/Bがメンバとして登録されているサークルAの項目SAとサークルBの項目SBとを一覧にしたサークル一覧画面Gclが生成され、前記ユーザ端末20ｓｔA/Bへ送信されて表示される(ステップS402)。
【0078】
ここで、前記サークル一覧画面Gclには、そのサークルA/Bの項目SA/SB毎に、フィード画面へのリンクとなるフィードリンクアイコンRFa/RFbと、メッセージ画面へのリンクとなるメッセージリンクアイコンRMa/RMbとが設けられる。
【0079】
そして、前記サークル一覧画面Gclの各サークル項目SA/SB毎のフィードリンクアイコンRFa/RFbには、該当メンバ(サークル一覧要求元)である管理者・介護職員A/Bの新着(未読)フィード数が、サークルA/Bの各サークルメンバ記憶エリア12A3/12B3から読み出されて丸数字で付加される。また、各サークル項目SA/SB毎のメッセージリンクアイコンRMa/RMbには、同該当メンバの新着(未読)メッセージ数が同該当メンバの属するサブグループでの新着メッセージ数の合計の数として同サークルA/Bの各サークルメンバ記憶エリア12A3/12B3から読み出されて丸数字で付加される(ステップS403)。
【0080】
さらに、前記サークル一覧画面Gclの上部に設けられたお知らせアイコンPには、前記該当メンバの新着(未読)フィード数と新着(未読)メッセージ数の総合計が丸数字で付加される(ステップS404)。
【0081】
ここで、前記図14(A)で示している前記管理者・介護職員A/Bのユーザ端末20ｓｔA/Bに表示されたサークル一覧画面Gclの場合では、当該管理者・介護職員A/Bが未読であるフィードとメッセージの総合計が“4”で、その内訳として、サークルAのフィードの未読数が“2”、メッセージの未読数が“1”、サークルBのメッセージの未読数が“1”あることを容易に確認することができる。
【0082】
そして、前記サークル一覧画面Gclによれば、各サークル項目A/B毎にフィードリンクアイコンRFa/RFbとメッセージリンクアイコンRMa/RMbとを並べて設けているので、ユーザが属しているサークルAまたはBのフィード画面表示かまたはメッセージ画面表示かを容易に選択して当該画面表示に素早く遷移させることができる。
【0083】
なお、前記サークル一覧要求元(該当メンバ)がサークルAのみのメンバとして登録されている家族Aのユーザ端末20fmA、訪問介護職員Aのユーザ端末20hｓｔA、ケアマネージャ20cmAである場合は、当該サークルAの項目SAだけのサークル一覧画面Gclが生成され、該当メンバのユーザ端末20fmA/20hｓｔA/20cmAへ送信されて表示される(ステップS401?S404)。
【0084】
そして、前記サークル一覧画面Gclが表示された管理者・介護職員A/Bのユーザ端末20ｓｔA/Bにおいて、サークルA/B何れかの項目SA/SBのフィードリンクアイコンRFa/RFbまたはメッセージリンクアイコンRMa/RMbが選択されて操作されると、当該ユーザ端末20ｓｔA/Bから前記サークルサーバ10に対して、前記選択されたサークル項目SA(又はSB)のサークル名A(又はB)と「フィード」又は「メッセージ」の要求が受信される(ステップS405)。
【0085】
例えば、前記図14(A)で示したサークル一覧画面Gclにおいて、サークルAの項目SAのフィードリンクアイコンRFaが選択されて操作された場合に、前記サークルサーバ10において、前記サークルAの「フィード」が選択されたと判断されると(ステップS406「フィード」)、前記サークルデータ記憶エリア12Aのフィード記憶エリア12A4に記憶されているフィードデータ1.2.…が読み出され、図14(B)に示すように、サークルAのフィードF1,F2,…を一覧にしたフィード一覧画面GFcaとして前記管理者・介護職員A/Bのユーザ端末20ｓｔA/Bに送信されて表示される(ステップS407)。
【0086】
ここで、前記ユーザ端末20ｓｔA/Bに送信されて表示されるサークルAのフィード一覧画面GFcaには、その上部に[投稿する]アイコンとメッセージ画面に遷移させるメッセージリンクアイコンRMaが付加され、さらに当該メッセージリンクアイコンRMaには、前記サークルメンバ記憶エリア12A3から読み出された該当メンバ(ここでは管理者・介護職員A/B)の新着メッセージ数(サブグループ合計)が丸数字で付加されて表示される。
【0087】
こうして、前記管理者・介護職員A/Bのユーザ端末20ｓｔA/Bに対してサークルAのフィード一覧画面GFcaが送信されて表示されると、前記サークルメンバ記憶エリア12A3の当該管理者・介護職員A/Bに対応付けて記憶されている新着フィード数がリセットされる(ステップS408)。
【0088】
そして、前記ユーザ端末20ｓｔA/Bのフィード一覧画面GFcaに付加されている[投稿する]アイコンが操作されることにより、当該ユーザ端末20ｓｔA/Bから前記サークルサーバ10に対して投稿要求が受信されると(ステップS409(Yeｓ))、当該サークルサーバ10において、図14(C)に示すように、前記サークルAに対する新規投稿画面GFiが生成され、前記ユーザ端末20ｓｔA/Bに送信されて表示される(ステップS410)。
【0089】
前記ユーザ端末20ｓｔA/Bに表示された新規投稿画面GFiにおいて、当該端末ユーザにより任意の写真や文字による情報が入力され、[投稿]アイコンが操作されると、当該入力された情報が、前記サークルサーバ10に新規投稿データとして受信され、前記サークルデータ記憶エリア12Aのフィード記憶エリア12A4に最新のフィード1.として書き込まれる(ステップS411)。」

以上の記載によれば、引用文献2には、次の技術事項が記載されている。

「複数の高齢者や子供の世話など、複数の世話の対象のそれぞれに複数の人物が関わって行なう世話を容易且つ円滑に行なうことが可能にするために(【0010】)、
被介護者Aの世話を行なう管理者・介護職員Aと訪問介護職員AとケアマネージャAと家族Aとの各ユーザ端末20ｓｔA/B,20hｓｔA,20cmA,20fmAによるサークルAが作成され(【0026】)、
管理者・介護職員A/Bのユーザ端末20ｓｔA/Bに表示された新規投稿画面GFiにおいて、当該端末ユーザにより任意の写真や文字による情報が入力され、[投稿]アイコンが操作されると、当該入力された情報が、前記サークルサーバに新規投稿データとして受信される(【0076】?【0089】)こと」

3 引用文献3
原査定の拒絶の理由で引用された引用文献3(特開2009-175898号公報)には、次の事項が記載されている。

「【0087】
次に、本実施の形態のメールシステムにおける処理の手順について説明する。まず、本実施の形態のメールサーバ100において、ユーザが受信メールを確認するときに実行されるメールボックス処理について説明する。
【0088】
図9は、メールボックス処理の手順を示すフローチャートである。
本実施の形態のメールサーバ100は、組織30に属するユーザが使用する端末装置31,32,・・・(例えば、端末装置31)から送信された電子メールの閲覧要求を受信すると、これに応じて、メールボックス処理により、そのユーザ宛の電子メールの情報をその端末装置に提供し、その端末装置上のブラウザによって表示させる。
【0089】
[ステップS11]メールサーバ100のCPU101は、端末装置31からのユーザによる電子メールの閲覧要求を受信すると、端末装置31,32,・・・に対してLAN10を介してそのユーザのユーザIDについてアカウント認証を行う。アカウント認証に成功すると、ユーザは認証されたアカウントでメールシステムにログインされる。
【0090】
[ステップS12]CPU101は、端末装置31から送信される、ユーザによる電子メールを閲覧するアカウントの選択指示を受け付ける。これにより、個人アドレスまたは代表アドレスのうち、ユーザが閲覧を希望する電子メールのアカウントが、端末装置31,32,・・・からメールサーバ100に通知される。
【0091】
[ステップS13]CPU101は、端末装置31,32,・・・から送信される閲覧終了指示を受け付けたか否かを判定する。CPU101は、閲覧終了指示を受け付けていなければ、ステップS14に処理を進める一方、閲覧終了指示を受け付けていれば、処理を終了する。
【0092】
[ステップS14]CPU101は、ステップS12で受け付けた選択指示に基づいて、ユーザが選択した電子メールのアカウントに対応するアカウントID(図7参照)を取得する。これにより、端末装置31,32,・・・のブラウザ上で、ユーザが個人アドレスの電子メールの閲覧を選択した場合には、個人アドレスに対応するアカウントIDが取得される一方、ユーザが代表アドレスの電子メールの閲覧を選択した場合には、代表アドレスに対応するアカウントIDが取得される。
【0093】
[ステップS15]CPU101は、ステップS14で取得したアカウントIDのメール情報を取得する。
[ステップS16]CPU101は、ユーザからの閲覧要求が送信された端末装置31,32,・・・に対して、ステップS15で取得したメール情報を送信する。
【0094】
[ステップS17]CPU101は、ユーザが端末装置31,32,・・・によって、ステップS12で選択を受け付けたアカウントにおいて返信メールの作成が行われたか否かを判定する。ユーザが返信メールの作成を行っていれば、ステップS18に処理を進める一方、ユーザが返信メールの作成を行っていなければ、ステップS12に処理を進める。
【0095】
[ステップS18]CPU101は、ユーザが作成する返信メールの送信元(返信元)となる返信アドレスとして、ステップS12で選択したアカウントのアドレスである、取得したアカウントIDのメールアドレスを設定する。詳しくは図15において後述する。ユーザは、これに基づいて、個人アドレスの電子メールに返信する場合には、返信アドレスとして個人アドレスが設定された電子メールを作成することとなる一方、代表アドレスの電子メールに返信する場合には、返信アドレスとして代表アドレスが設定された電子メールを作成することとなる。」

以上の記載によれば、引用文献3には、次の技術事項が記載されている。

「閲覧を希望する電子メールのアカウントを個人アドレスまたは代表アドレスのうちから選択し、選択したアカウントに送信された電子メールを閲覧するとともに、返信メールの送信元(返信元)となる返信アドレスとして選択されたアカウントを設定すること」

4 引用文献4
原査定の拒絶の理由で引用された引用文献4(特開2014-63459号公報)には、次の事項が記載されている。

「【0037】
インタフェース部210は、個人アカウントを用いるユーザに対して、友だち管理などのためのインタフェースを提供し、公式アカウントを用いるイベント生成者に対して、イベント生成及びイベント管理のためのインタフェースを提供する。本実施形態において、公式アカウントのイベント進行時に該当のアカウントを友だちと設定したユーザごとに、独立的なイベントチャットルームが生成及び保持されることに伴う複数のチャットルームを管理するために、イベント生成者に対して全般的な管理サービスを提供してもよい。すなわち、イベント生成者は、メッセンジャーオンエアーサービスシステム200のインタフェース環境で提供される管理サービスによって、イベント特定及びユーザとの送受信メッセージに対する確認などが、可能である。」

「【0047】
図13を参照すると、送信用アカウント画面1300では、イベント生成者がイベントメッセージを発送するとき用いる公式アカウントを管理してもよい。イベント生成者は、送信用アカウント画面1300によって、公式アカウントをコード形式で示したQRコード(登録商標)1301を確認することができる。ここで、イベント生成者は、送信を希望しているユーザに対してQRコード(登録商標)を送信してもよい。当該ユーザは、受信したQRコード(登録商標)を用いて、公式アカウントを友だち目録に追加してもよい。また、イベント生成者は、送信用アカウント画面1300によって公式アカウントに設定されたパスワード1302を確認してもよい。ここで、パスワード1302は、イベント生成者が端末上のメッセンジャープラットフォームでイベントメッセージを発送しようとするときに、イベント生成者の認証のために使用されてもよい。また、送信用アカウント画面1300では、パスワード1302を修正可能とする機能が提供されてもよい。すなわち、パスワード1302は、端末上のメッセンジャープラットフォームでイベントメッセージを発送するとき使用されることによって、管理サービスのウェブサイト接続時に用いられるログインパスワードと同一に用いられたり、ログインパスワードとは区分して別途に設定されてもよい。そして、送信用アカウント画面1300では、イベント生成者がユーザにイベントメッセージを発送するとき、予めメッセージ発送の意思を確認するか否かを設定するメッセージ送信前確認機能1303が提供されてもよい。」

「【0056】
したがって、メッセンジャーオンエアーサービスシステムは、メッセンジャーで公式アカウントの参加型イベントのためのチャットルームを生成してイベントメッセージを複数のユーザに一括発送するが、イベント生成者とユーザとの間に共通する1つのチャットルームでチャット可能とするのではなく、ユーザごとに個別的な空間でチャットできるように、独立的なチャットルームを生成及び保持してもよい。さらに、メッセンジャーオンエアーサービスシステムは、イベントに参加するユーザごとに生成された複数のチャットルーム管理のための管理サービスを提供することにおいて、図9から図16を参照して説明したインタフェース環境をイベント生成者に提供してもよい。」

以上の記載によれば、引用文献4には、次の技術事項が記載されている。

「個人アカウントを用いるユーザに対して、友だち管理などのためのインタフェースを提供するとともに、公式アカウントを用いるイベント生成者に対して、イベント生成及びイベント管理のためのインタフェースを提供し、公式アカウントの参加型イベントのためのチャットルームを生成してイベントメッセージを複数のユーザに一括発送すること」

5 引用文献5
原査定の拒絶の理由で引用された引用文献5(中村勇介,”ビジネスに使えるLINEのマーケティング”,LINE ビジネス活用の極意100,日経BP社,2017年 8月10日,p.10-11,38,ISBN:978-4-8222-5908-2)には、次の事項が記載されている。

「01 マーケティング LINE公式アカウント
「LINE」利用者に企業から直接情報を発信できる。企業向けの公式アカウントサービス。この「LINE公式アカウント」を解説すると、LINE上の公式アカウント一覧に掲載される。この一覧から、企業やブランドのアカウントに「友だち」登録した人に対して、情報を発信できる。
LINE公式アカウントを活用して、情報を発信する方法は、大きく2つある。1つは、「メッセージ」機能だ。メールマガジンのような感覚で一括して情報を配信できる。テキスト以外のコンテンツを配信できる機能も用意されている。「リッチビデオメッセージ」は、自動再生される動画をメッセージとして送れる。「クーポン・イベント作成」を使えば割引クーポンやアンケートページを作成して配信できる。
もう1つは、「タイムライン」機能だ。LINEには直接、友人に連絡できる機能の他、Facebｏｏkなどのように、近況を投稿できるタイムライン機能がある。LINE公式アカウントを利用する企業は、このタイムラインにキャンペーン情報や新商品の情報などを、写真付きで投稿できる。
利用者は企業から受け取ったメッセージに対して返信はできないが、タイムラインでは投稿に「いいね!」やコメントを付けられる。」(第10頁)

「02 CRM LINEビジネスコネクト
企業が「LINE」に開設したアカウントと、企業が持つ顧客データベースや基幹システムなどを接続して、連携可能にする仕組み。最も基本的な活用方法は、顧客データなどに基づくメッセージの出し分けだ。
従来のLINEの企業アカウントは、登録された「友だち」に対して一律のメッセージ配信しかできなかった。そのため、登録者の性別や居住地といった属性情報に基づいて、登録者に合わせた情報発信を可能にするサービスが求められていた。「LINEビジネスコネクト」(BC)を使って自社の顧客データベースなどと接続すると、蓄積している性別、年齢、居住地、過去の購入履歴といった企業が持つ顧客情報に基づいてメッセージを出し分けることができる。例えば、旅行会社のエイチ・アイ・エスは、公式アカウントで友だち登録者が「ツアー」とメッセージを送った後に、行き先を送信すると、お薦めのツアーを紹介する仕組みを実現している。これはあくまで活用事例の1つにすぎない。LINE上級執行役員の田端信太郎氏は、「LINE公式アカウント宛てにメッセージを送るだけで、ピザを注文できる、銀行口座の残高照会ができる、宅配便の再配達を依頼できる、LINEビジネスコネクトを使えばそんな活用法も可能にある」とサービスの持つ可能性を説明する。
LINEとの密な連携によって注文や取引の利便性を高め、それで売り上げが増えれば、企業にとって確かに魅力的である。一方でLINEは活用企業の基幹システムと接続することで、キャンペーン的な利用のみではなく、永続的に利用してもらえるマーケティングプラットフォームとなることを狙う。」(第11頁)

「04 社内連絡 トークルーム＆グループ 急用と情報共有、目的で使い分け
LINEには、複数人で会話をする方法が主に2つある。1つ目は「グループ」だ。これはグループに招待した人から承諾を得なければメッセージを配信できないが、「ノート」機能が使えるため、「週次の数値共有などをノートに残しておく」(LINEの営業担当者)など、さまざまな情報の共有に向く。もう1つは「トークルーム」だ。トークルームは作った瞬間に連絡を取れるため、グループに参加していない社員や外部の取引先などに緊急の連絡をする際に利用できる。「突発的な飲み会への誘いに使える」(同)。」(第38頁)

以上の記載によれば、引用文献5には、次の技術事項が記載されている。

「LINEには、利用者に企業から直接情報を発信できる企業向けの公式アカウントサービスがあり、公式アカウントサービスには、「メッセージ」機能と「タイムライン」機能がある。
また、「LINE」に開設したアカウントと、企業が持つ顧客データベースや基幹システムなどを接続して連携することで、顧客データなどに基づくメッセージの出し分けを可能とするLINEビジネスコネクトのサービスがある。
さらに、LINEには、複数人で会話をする方法として、「グループ」機能と「トークルーム」機能とがあり、「トークルーム」機能を用いることにより、グループに参加していない社員や外部の取引先などに緊急の連絡をすることが可能となる。」


第6 対比・判断
1 本願発明1について
(1)対比
本願発明1と引用発明とを対比すると、次のことがいえる。

ア 「携帯端末」について
引用発明の「在宅療養に携わる医療、看護、介護の各施設に属する医師、看護師、訪問介護員等の使用者が使用可能な使用者端末」は、「在宅療養に携わる医療、看護、介護の各施設に属する医師、看護師、訪問介護員」はケア担当者といえるから、本願発明1の「ケア担当者が携帯するための複数の携帯端末」に相当する。

イ 「サーバ」について
引用発明では「データ管理装置と使用者端末とは、通信ネットワークNを介して接続可能となって」いることから、引用発明の「データ管理装置」は、本願発明1の「前記複数の携帯端末と通信可能なサーバ」に相当する。
また、引用発明では、「データ管理装置は通信部、記憶部等を備え、記憶部には、所定の時点における患者の状態を示す基準情報(ベースライン情報)が記憶され、ベースラインテーブルには、患者基礎情報として、氏名、続柄、電話番号からなる連絡先が複数記憶され」ているから、データ管理装置は、ケア対象者である患者の関係者の連絡先情報を記憶する記憶部を有しているといえる。
このため、「関係者の連絡先情報」が「前記選択画面データに基づいて前記携帯端末の表示部に表示された選択画面を介して選択された前記ケア対象者の関係者の連絡先情報」である点を除き、本願発明1と引用発明とは、「前記サーバは」「ケア対象者の関係者の連絡先情報を記憶する記憶部」を備えている点で共通する。

ウ 「連絡先情報」が編集可能であることについて
引用発明では、「使用者端末において、操作部からの操作により、患者の選択が指示され、患者情報のアップロードが指示されると、表示部に患者情報の各項目の入力欄が含まれる編集画面が表示されるアップロード用画面が表示され、各項目に対応する入力欄に情報を入力し、保存ボタンを押下することで、入力された情報がデータ管理装置にアップロードされる」ところ、入力された情報のアップロードは情報の編集に他ならないことから、引用発明は、本願発明1と同様に、「前記連絡先情報は、前記携帯端末を介して、編集可能であ」るといえる。

エ 「連絡先情報共有用のコミュニケーションシステム」
引用発明は、「使用者端末において、操作部からの操作により、患者の選択が指示され、患者情報のアップロードが指示される…入力された情報がデータ管理装置にアップロードされる」ことから、使用者端末間で連絡先情報は共有されているといえ、また、引用発明の「データ管理装置」は通信部を有するとともに、「使用者端末」は「PC(Personal Computer)、タブレット端末、スマートフォン等」であり、「データ管理装置」及び「使用者端末」はシステム内又はシステム外とコミュニケーション可能であると考えるのが妥当であるから、コミュニケーション可能な装置を備える「在宅療養連携システム」は「コミュニケーションシステム」であるといえる。
このため、引用発明は、本願発明1と同様に、「連絡先情報共有用のコミュニケーションシステム」であるといえる。

したがって、本願発明1と引用発明とは、次の点で一致及び相違する。

＜一致点＞
ケア担当者が携帯するための複数の携帯端末と、
前記複数の携帯端末と通信可能なサーバと、
を備え、
前記サーバは、
ケア対象者の関係者の連絡先情報を記憶する記憶部と、
を備え、
前記連絡先情報は、前記携帯端末を介して、編集可能である、
連絡先情報共有用のコミュニケーションシステム。

＜相違点＞
(相違点1)
本願発明1は、「サーバ」が「前記ケア担当者が出勤日当日に担当するケア対象者を選択するための選択画面データを生成する第一生成部と、前記連絡先情報に基づいて、複数の前記関係者を参加メンバとするチャットルームを生成する第二生成部と」を備えているのに対して、引用発明は、「サーバ」がこれらを備えていない点。

(相違点2)
本願発明1の「記憶部」が記憶する「関係者の連絡先情報」は、「選択画面データに基づいて前記携帯端末の表示部に表示された選択画面を介して選択された前記ケア対象者の関係者の連絡先情報」であるのに対して、引用発明における「関係者の連絡先情報」はこのような情報ではない点。

(相違点3)
本願発明1では、「サーバ」が「前記連絡先情報に基づいて、関係者の各々が有する通信端末にメッセージを一斉に投稿することが可能な投稿部」を備え、「前記投稿部は、前記ケア担当者が属している組織の代表アカウントを用いて、前記チャットルームを介して当該チャットルームの参加メンバに、メッセージを一斉に投稿することが可能である」のに対して、引用発明では、このような「投稿部」を備えていない点。

(2)相違点の判断
事案に鑑み、上記相違点3について検討する。
引用文献2?5には、上記「第4」「2」?同「5」に記載した事項が記載されているところ、いずれの文献にも、「前記連絡先情報に基づいて、関係者の各々が有する通信端末にメッセージを一斉に投稿することが可能な投稿部」を備え、「前記投稿部は、前記ケア担当者が属している組織の代表アカウントを用いて、前記チャットルームを介して当該チャットルームの参加メンバに、メッセージを一斉に投稿することが可能である」ことは記載されていない。
また、技術常識を参酌しても、引用発明において、「前記ケア担当者が属している組織の代表アカウントを用いて、前記チャットルームを介して当該チャットルームの参加メンバに、メッセージを一斉に投稿することが可能である」「投稿部」を設ける動機付けを引用発明から見いだすことはできない。
そして、当該事項を記載する他の引用文献も発見されない。
したがって、本願発明1は、当業者であっても引用発明、及び、引用文献2?5の記載に基づいて容易に発明できたものではない。

2 本願発明2及び3について
本願発明2及び3は、少なくとも、上記1で検討した相違点3に係る本願発明1の構成と同一の構成を備えるものであるから、本願発明1と同じ理由により、当業者であっても、引用発明及び引用文献2?5に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

3 本願発明4について
本願発明4は、本願発明の「ケア担当者」及び「ケア対象者」を「担当者」及び「対象タスク」にした発明であるから、少なくとも、上記1で検討した相違点3に係る本願発明1の構成と同様な構成を備えるものであり、本願発明1と同じ理由により、当業者であっても、引用発明及び引用文献2?5に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。


第7 むすび
以上のとおり、本願発明1?4は、当業者が引用発明及び引用文献2?5の記載事項に基づいて容易に発明をすることができたものではない。
したがって、原査定の理由によって、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。

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

 
審決日 2021-06-17 
出願番号 特願2019-1290(P2019-1290)
審決分類 P 1 8・ 121- WY (G16H)
最終処分 成立  
前審関与審査官 渡邉 加寿磨  
特許庁審判長 渡邊 聡
特許庁審判官 相崎 裕恒
佐藤 聡史
発明の名称 連絡先情報共有用のコミュニケーションシステム、方法、およびコンピュータプログラム  
代理人 特許業務法人 信栄特許事務所  
代理人 特許業務法人 信栄特許事務所  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ