2020-017533

特願２０１９－１８１１２０「情報処理システムおよびプログラム」拒絶査定不服審判事件〔令和 ３年 ４月 ８日出願公開、特開２０２１－ ５６９１２、請求項の数（１２）〕について、次のとおり審決する。

結 論 原査定を取り消す。 本願の発明は、特許すべきものとする。

理 由 第１ 手続の経緯 本願は、令和元年１０月１日の出願であって、令和２年３月１３日付けで拒絶理由が通知され、同年７月１日に手続補正書が提出され、同年９月２８日付けで拒絶査定（原査定）がされ、これに対し、同年１２月２２日に拒絶査定不服審判の請求がされたものである。 第２ 原査定の概要 原査定（令和２年９月２８日付け拒絶査定）の概要は次のとおりである。 本願請求項１－１２に係る発明は、以下の引用文献１－３に記載された発明に基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 引用文献等一覧 １．特開２０１９－１０１８３４号公報 ２．特開２０１１－１０７７７９号公報 ３．特開２０１５－９７０６６号公報 第３ 本願発明 本願請求項１－１２に係る発明（以下、それぞれ「本願発明１」－「本願発明１２」という。）は、令和２年７月１日にされた手続補正による補正後の特許請求の範囲の請求項１－１２に記載された事項により特定される発明であり、本願発明１は以下のとおりの発明である。 「【請求項１】 サービスの利用者が使用する利用者端末、または、前記利用者が利用している医療機関の医療従事者が使用する医療機関端末から、前記利用者の医療情報を受信し、受信した前記医療情報を記録する医療情報記録部と、 前記利用者端末からのアクセスキー発行要求に応答して、前記医療情報を閲覧するためのアクセスキーを、前記医療機関に紐付けて発行し、発行した前記アクセスキーを前記利用者端末に送信するアクセスキー発行部と、 前記医療機関端末からの前記アクセスキーを伴う閲覧要求に応答して、前記医療情報に含まれる情報項目のうち開示が許可に設定されている情報項目に係る情報を前記医療情報記録部から抽出し、抽出した前記情報項目に係る情報を前記医療機関端末に送信する医療情報抽出部と、 を有し、 前記アクセスキーの有効期限を設けない、 情報処理システム。」 なお、本願発明２－１２の概要は以下のとおりである。 本願発明２－１１は、本願発明１を減縮した発明である。 本願発明１２は、システムの発明である本願発明１に対応するプログラムの発明である。 第４ 引用文献、引用発明等 １．引用文献１について 原査定の拒絶の理由に引用された上記引用文献１には、図面とともに次の事項が記載されている。（下線は当審で付した。） 「【００５９】 図１に示すように、この医療支援サービスは、その利用を希望する患者Ｐ、患者関係者Ｒ又は医療従事者Ｍが、所定の方法でユーザー登録をした後、患者Ｐが所有する患者端末１０や、医療従事者Ｍが操作する医療従事者端末１１、あるいは、患者関係者Ｒが所有する患者関係者端末１２（以下、これらの端末をまとめて「ユーザー端末」ということがある）から、通信ネットワークであるインターネット２０を介して利用するようになっている。 【００６０】 ユーザー登録をした患者Ｐ、患者関係者Ｒ又は医療従事者Ｍは、この医療支援サービスの「ユーザー」となる。この医療支援サービスは、医療支援システム３０によって実現されているから、この医療支援サービスの「ユーザー」は医療支援システム３０の「ユーザー」と言うこともできる。ユーザー登録をしていない患者Ｐ、患者関係者Ｒ又は医療従事者Ｍは、この医療支援サービスを利用できない。 【００６１】 いずれかのユーザー端末１０、１１又は１２からインターネット２０を介して医療支援システム３０に指示を送ると、医療支援システム３０内に設置されたハードウェアとソフトウェアの動作により、後述する「ユーザー登録」や「グループの生成」、「グループへの招待」、「メッセージの送受信（コミュニケーション）」、「かかりつけ登録」、「医療情報の閲覧」といった種々の動作や機能が実行される。また、そうすることで、患者一人ひとりの医療情報や交換されたメッセージを、患者Ｐのプライバシーを守りながら、複数の医療従事者Ｍの間で、もしくは患者Ｐと医療従事者Ｍの間で、又は患者Ｐと医療従事者Ｍと患者関係者Ｒの間で共有することが可能となり、その共有された医療情報やメッセージに基づいて個々の患者Ｐに、より良質の医療サービスを提供できるようになる。 【００６２】 患者端末１０と患者関係者端末１２は、通常、携帯電話やスマートフォンのような携帯端末とされ、個々の患者Ｐや患者関係者Ｒが自分専用の端末を所有するが、デスクトップ型あるいはノート型のパーソナル・コンピューター（パソコン）や、タッチパネル型の端末も使用可能である。医療従事者端末１１は、医療関連施設に設置されることが多いので、通常はデスクトップ型あるいはノート型のパソコンとされるが、タッチパネル型の端末や携帯端末も使用可能であることは言うまでもない。要するに、これらの端末１０、１１及び１２は、インターネット２０を介して医療支援システム３０との間で情報の送信、受信及び表示ができる端末装置であればよく、その形態や構成は問わない。」 「【０１２６】 （医療支援システムの動作） 以上の構成を持つ医療支援システム３０では、医療情報とメッセージの共有のために、個々の患者Ｐの疾患毎にグループＧが登録・生成される。グループＧの作成は、上述したように、医療従事者Ｍによる患者グループ登録、又は、患者Ｐによるかかりつけ登録によって行われる。また、グループＧのグループ・メンバーは、デフォルトメンバーを除き、必要に応じて患者Ｐや医療従事者Ｍ、患者関係者Ｒを招待することで追加され、また、必要に応じてグループＧから削除される。医療支援システム３０のこれら動作の詳細は特許文献１に記載されているが、これらは本実施形態に係るサービス構築支援システム１００とは関係がないため、それらの説明は省略する。」 「【０１４５】 ヒアリング・モジュール２１３は、所定の対象者への一連の質疑応答（例えば患者に対する問診）を行うための機能を開発者Ｄに提供するためのモジュールである。この機能は、所望のタイミングで医療支援システム３０のユーザー（例えば医療従事者Ｍ）が所定の対象者（例えば患者Ｐ）に一連の質問を行うことで、それら質問に対応する所望の情報（例えば、患者Ｐの最近の体調や症状に関する情報）を回答として入手し記録するという動作を可能とする。そのために、ヒアリング・モジュール２１３には、一連の質問の見本（質問テンプレート群）と回答の見本（回答テンプレート群）とが用意されており、それらのテンプレート群を利用すれば、所望の質問文とそれに適した回答様式を簡単に作ることができるようになっている。具体例を挙げると、ヒアリング・モジュール２１３の機能をアプリケーション２２０内に記述すれば、その実行時に、例えば、図２５に示した「気になる症状の確認」、「食生活の確認」等の機能設定で、それらのタイトルに対応して予め用意された質問群（質問テンプレート群）に基づいて、所望の質問文が自動作成され、それらの質問文（質問情報）を、医療支援システム３０が持つメッセージ投稿機能を用いて、所望のタイミングで、対象者である患者Ｐの所属するグループＧのタイムライン（患者側）に投稿して回答するように促す、という動作を容易に実現することができる。そして、該当する患者Ｐから回答が入力されると、医療支援システム３０の機能を使って、その回答の内容（回答情報）をアプリケーション保存部３３２に自動記憶する、という動作を容易に実現することができる。前記質問情報の指定と前記回答情報用の回答様式の指定は、後述する「ユーザー設定プロセス」において実行される。 【０１４６】 アプリケーション２２０に組み込まれたヒアリング・モジュール２１３の機能を使用するには、ノート・モジュール２１１及びレコード・モジュール２１２の場合と同様に、初期設定が必要であるため、使用開始時にシステム管理者Ａによる「管理者設定プロセス」において所定の初期設定が実行される。また、当該機能の使用開始後に行われる設定変更も、必要に応じて、同管理者Ａによる「管理者設定プロセス」において実行される。 【０１４７】 ブック・モジュール２１４は、種々の情報をファイル形式で「コンテンツ」として所定の記憶手段（具体的にはアプリケーション保存部３３２）に記憶する機能を開発者Ｄに提供するためのモジュールである。この機能は、医療支援システム３０の特定のユーザー（例えば患者Ｐ、医療従事者Ｍ又は患者関係者Ｒ）に役立つ情報（有益情報）を「コンテンツ」としてまとめた種々の形式のファイル（例えばｐｄｆ、ｘｌｓ、ｄｏｃ、ｊｐｇ、ｍｐ４等）を予め記憶しておき、医療支援システム３０が持つメッセージ投稿機能を用いることで、所望のタイミングで、指定されたコンテンツを特定のグループＧのタイムライン（患者側）に投稿して表示させる、という動作を、容易に実現することができる。具体例を挙げると、この機能をアプリケーション２２０内に記述すれば、その実行時に、例えば、図２５に示した「糖尿病アドバイス（食事）」、「糖尿病アドバイス（運動）」等の機能設定で、それらのタイトルに対応して予め用意されたコンテンツ（ファイル）を、医療支援システム３０が持つメッセージ投稿機能を用いて、所望のタイミングで、対象者である患者Ｐの所属するグループＧのタイムライン（患者側）に投稿して表示するという動作を、容易に実現することができる。これにより、例えば該当する患者Ｐまたは患者関係者Ｒは最適なタイミングで容易に有益な情報を入手することが可能となる。前記コンテンツ（ファイル）の用意・記憶と指定は、後述する「ユーザー設定プロセス」において実行される。」 「【０１８５】 具体的に言うと、前記新アプリケーション２２０では、（ａ）その目的（例えば糖尿病服薬支援）を達成するために、４つのモジュール２１１、２１２、２１３及び２１４の特定機能をどのような順序でどのように組み合わせて所望の質問情報や提示情報を作成するか、そして、（ｂ）それらモジュール２１１、２１２、２１３及び２１４の特定機能を実施する際に、どのような情報を指定・追加するか（例えば質問に使用する薬品名とその摂取量や、収集・記録する検査項目、各項目に付けるタイトル等）、前記の情報の指定・追加を誰に依頼するか（例えばシステム管理者Ａか特定のユーザーか）、こうして作成した質問情報や提示情報をどのタイムラインにどのような順序・タイミングで投稿（表示）するか、といった点について記述することで、前記新アプリケーション２２０においてプログラミング言語を使って記述する箇所を大幅に減少させることができるのである。ここで、「質問情報」とは、特定のユーザーに対する何らかの質問を含む情報であり、「提示情報」とは、特定のユーザーに提示する何らかのメッセージ等の情報を含み、且つ質問を含まない情報である。」 「【０１９０】 こうして前記新アプリケーション２２０の実行（前記新サービスの提供）が開始されると、例えば、前記新サービスについての利用要求を送ったユーザーが所属するグループＧのタイムラインに、所定の質問情報や提示情報を投稿・表示したり、同タイムライン上で同グループＧの指定ユーザーにより投稿された回答情報を保存したり、といった一連の処理が、実行中の前記新アプリケーション２２０の指示するところに沿って順次、実行される。こうしてすべての処理が実行されると、前記新アプリケーション２２０は動作を終了する（ステップＳ１８）。以上のようにして、前記新サービス（付加サービス）は、前記新アプリケーション２２０の実行中に前記グループＧに属する指定ユーザーに対して提供される。 【０１９１】 例えば、前記新アプリケーション２２０により、前記グループＧのタイムラインに、所定の質問情報や提示情報が所定のスケジュールにしたがって順次投稿・表示され、指定されたユーザーとしての患者Ｐと患者関係者Ｒに所定の情報（例えば起こりうる合併症やその他症状、検査結果）を所望のタイミングで通知することができる。また、同タイムラインに投稿された質問情報（例えば気になる症状や食生活や残薬の確認）に対して、前記グループに係る患者Ｐ又は患者関係者Ｒが回答情報を提供すると、その回答情報は同タイムラインに投稿・表示されると同時に自動的に記憶されるので、同グループＧの医療従事者Ｍがその回答情報を確認することが可能となる。その結果、医療支援システム３０が提供している既存の医療サービスに対して、容易に種々の新サービス（例えば服薬支援サービス）を構築して付加的に提供することができ、しかも、それら新サービスにおいても同システム３０の特徴、すなわち、「医療サービスの対象者（患者）毎に生成されたグループに、前記医療サービスの１又は複数のユーザー（患者だけでなく医療従事者を含む）を選択的にグループ・メンバーとして所属させると共に、前記グループに係る前記対象者の医療情報を前記グループ・メンバーに限定して閲覧可能とすることで、前記対象者のプライバシーを確保しながら前記対象者に係る医療情報を前記グループ・メンバー間で共有できる」という特徴を活かすことが可能となる。 【０１９２】 （アプリケーションにより提供される新サービスの利用形態） 次に、以上のようにして新アプリケーション２２０により提供される付加サービスの具体的な利用形態の一例について、図１７?図４７を参照しながら説明する。 【０１９３】 図１７は、サービス構築支援システム１００に新アプリケーション２２０を開発者端末１３からアップロードしてインストールし、使用可能となった状態で、医療支援システム３０が提示する「ホーム画面」のタイムラインの例を示す。この「ホーム画面」に表示されている複数のメッセージの中から、特定の患者Ｐ３（ここでは山本ＸＸさんで、糖尿病の治療を受けている）に対するメッセージを、患者Ｐ３（山本ＸＸさん）の主治医である医療従事者Ｍがクリックすると、患者Ｐ３の糖尿病治療グループＧ３１が選択され、その医療従事者Ｍの医療従事者端末１１に図１８に示すようなグループＧ３１Ｇのタイムライン（医療従事者側）が表示される。このタイムライン（医療従事者側）は、図９のグループＧ１１のタイムラインの医療従事者共有エリア５１ｂに対応し、患者Ｐ３の糖尿病治療グループＧ３１のグループ・メンバーである医療従事者Ｍだけが閲覧可能であり、患者Ｐ３やその患者関係者Ｒは閲覧できない。図１８の表示画面には、「オプション」ボタン（オプション起動ボタン）が表示されている。そこで、前記医療従事者Ｍが「オプション」ボタンをクリックすると、図１９に示すアプリケーション選択用のオプション選択画面（医療従事者側）か、図２０に示すリクエスト選択用のオプション選択画面（医療従事者側）が、同医療従事者端末１１に表示される。図１９のオプション選択画面は、同画面で「アプリ」タブを選択した場合に表示され、図２０のオプション選択画面は、「リクエスト」タブを選択することで表示される。 【０１９４】 患者Ｐ３の糖尿病治療グループＧ３１のグループ・メンバーである医療従事者Ｍは、図１９のオプション選択画面（医療従事者側）から、同画面に表示されている「生活習慣改善」、「服薬管理」、「糖尿病服薬支援」という３つの付加サービス（これらは該当するアプリケーション２２０が提供する）のうちの１つ又はそれ以上を選択して利用することができる。また、図２０のオプション選択画面（医療従事者側）から、同画面に表示されている「入院」、「退院」、「往診」、「連携」という４つの付加サービス（これらも該当するアプリケーション２２０が提供する）のうちの１つ又はそれ以上を選択して利用することができる。 【０１９５】 他方、図１７の「ホーム画面」で、患者Ｐ３に対するメッセージを、患者Ｐ３自身がクリックすると、患者Ｐ３の糖尿病治療グループＧ３１が選択され、山本さんの患者端末１０に図２１に示すような同グループＧ３１のタイムライン（患者側）が表示される。このタイムライン（患者側）は、図９のグループＧ１１のタイムラインの全員共有エリア５１ａに対応し、患者Ｐ３のグループＧ３１のグループ・メンバー全員（患者Ｐ３、患者関係者Ｒ及び医療従事者Ｍ）が閲覧可能である。この画面には、「アプリ」ボタン（アプリ起動ボタン）が表示されている。そこで、「アプリ」ボタンをクリックすると図２２に示すアプリケーション選択用のオプション選択画面（患者側）が、患者Ｐ３の患者端末１０に表示される。 【０１９６】 患者Ｐ３は、図２２のアプリケーション選択画面（患者側）から、同画面に表示されている「生活習慣改善」、「服薬管理」、「糖尿病服薬支援」という３つの付加サービス（これらは該当するアプリケーション２２０が提供する）のうちの１つ又はそれ以上を選択して利用することができる。なお、この画面は患者側に表示されたものであるから、医療従事者側の画面に表示されていた「入院」、「退院」、「往診」、「連携」という４つの付加サービスは表示されず、したがって、当然のことであるが、患者Ｐ３はこれらの付加サービスは利用することができない。 【０１９７】 患者Ｐ３のグループＧ３１のグループ・メンバーである患者関係者Ｒも、図２２のアプリケーション選択画面（患者側）から、同画面に表示されている「生活習慣改善」、「服薬管理」、「糖尿病服薬支援」という３つの付加サービスのうちの１つまたはそれ以上を選択して利用することができる。」 「【０２１９】 図３７－図４５は、上述した糖尿病服薬支援アプリケーション２２０が提供する糖尿病服薬支援サービスを受ける際に、患者Ｐ３の糖尿病治療グループＧ３１のタイムライン（患者側）に表示される画面の例を示す。 【０２２０】 図３７は、上述した糖尿病服薬支援サービスの利用開始を伝えるメッセージ（提示情報）が、患者Ｐ３の糖尿病治療グループＧ３１のタイムライン（患者側）に投稿（表示）された状態を示す画面である。このメッセージは、医療支援システム３０のメッセージ投稿機能を利用して実現されている。図３７から分かるように、このグループＧ３１に属するグループ・メンバーは、患者Ｐ３本人、患者Ｐ３の主治医（医療従事者Ｍ）、そして、患者Ｐ３の家族（患者関係者Ｒ）の合計３名であり、全員がそのメッセージを閲覧可能となっている。これは、図１６（ｄ）に示すアプリケーションテーブルに示すように、上述した糖尿病服薬支援アプリケーション２２０（アプリケーションＩＤ＝１）が、患者Ｐ３の糖尿病治療グループＧ（グループＩＤ＝１０００３）と関連付けられているからであり、また、図２３の「システム管理者用のアプリケーション管理画面」に示すように、「利用範囲設定」の項目で「患者側タイムライン」が選択されているからである。 【０２２１】 図３７の糖尿病服薬支援サービス利用開始メッセージには、「患者ノート」の項目に「合併症、その他症状」の文字と「確認する。」の文字が表示されており、「確認する。」の文字をクリックすると、「合併症、その他症状」の内容が別ウィンドウで表示されるので、患者Ｐ３本人と患者Ｐ３の家族（患者関係者Ｒ）は、それを読み取ることによって容易に合併症やその他症状を確認できるようになっている。図３８は、その「合併症、その他症状」の内容が、患者Ｐ３のグループＧ３１のタイムラインに投稿された状態を示す。このようにタイムライン上でも読むことができる。これらは、「合併症、その他症状」というタイトルの上記ノート機能（図２５参照）を用いて実現されている。該当する症状がある場合は、図３８の画面から担当の医療従事者Ｍに返信（回答）することができる。その返信に使用される回答画面の例を図４２に示す。この回答画面において、２つのラジオボタンのいずれか一方を選択し、メッセージ入力欄に適当なメッセージを記入すればよい。 【０２２２】 図３７のサービス利用開始メッセージの「お薬の用法・用量」の項目には、図２４の「システム管理者用のアプリケーション管理画面」で指定した医薬品とその用法が反映されている。 【０２２３】 図３７のサービス利用開始メッセージの「検査値」の項目には、図３１の「システム管理者用のアプリケーション管理画面」で指定した検査の記録項目が反映されている。 【０２２４】 図３９は、上述した糖尿病服薬支援サービスにおいて、「気になる症状の確認」及び「食生活の確認」という２つの質問メッセージが、患者Ｐ３のグループＧ３１のタイムライン（患者側）に投稿された状態を示す。これらの質問メッセージは、上述した「気になる症状の確認」及び「食生活の確認」という２つのヒアリング機能と、医療支援システム３０のメッセージ投稿機能を利用して実現されている。同図から分かるように、各々の質問メッセージ上に表示された「回答する」ボタンをクリックすることで、患者Ｐ３又はその家族（患者関係者Ｒ）がそれらの質問に回答することができる。「気になる症状の確認」という質問に対する回答に使用される回答画面の例を図４３に示す。この回答画面は記述式になっており、メッセージ入力欄に適当なメッセージを記入でき、ファイルのアップロードも可能である。また、「食生活の確認」という質問に対する回答に使用される回答画面の例を図４４に示す。この回答画面は４個の選択肢から１個を選ぶ多肢選択式になっている。 【０２２５】 図４０は、上述した糖尿病服薬支援サービスにおいて、「残薬の確認」及び「運動週間の確認」という２つの質問メッセージが、患者Ｐ３のグループＧ３１のタイムライン（患者側）に投稿された状態を示す画面である。これらの質問メッセージは、上述した「残薬の確認」及び「運動週間の確認」という２つのヒアリング機能と、医療支援システム３０のメッセージ投稿機能を利用して実現されている。同図から分かるように、各々の質問メッセージ上に表示された「回答する」ボタンをクリックすることで、患者Ｐ３又はその家族（患者関係者Ｒ）がそれらの質問に回答することができる。「残薬の確認」という質問に対する回答に使用される回答画面の例を図４５に示す。この回答画面は記述式になっており、メッセージ入力欄に適当なメッセージを記入でき、ファイルのアップロードも可能である。 【０２２６】 図４１は、上述した糖尿病服薬支援サービスにおいて、「食事上の注意」という提示メッセージと、「服薬確認」という質問メッセージが、患者Ｐ３のグループＧ３１のタイムライン（患者側）に投稿された状態を示す画面である。「食事上の注意」のメッセージは、上述した「糖尿病アドバイス（食事）」というブック機能と、医療支援システム３０のメッセージ投稿機能を利用して実現されている。「服薬確認」という質問メッセージは、上述した「服薬確認」というヒアリング機能と、医療支援システム３０のメッセージ投稿機能を利用して実現されている。同図から分かるように、「服薬確認」の質問メッセージ上に表示された「回答する」ボタンをクリックすることで、患者Ｐ３又はその家族（患者関係者Ｒ）がその質問に回答することができる。」 したがって、上記引用文献１には次の発明（以下、「引用発明」という。）が記載されていると認められる。 「患者が所有するスマートフォンのような患者端末や医療関係施設に設置されて医療従事者が操作する医療従事者端末等のユーザ端末からインターネットを介して指示を送られて医療情報の閲覧等の機能が実行される医療支援システムであって、 医療情報とメッセージの共有のために、個々の患者の疾患毎に患者や医療従事者等からなるグループが登録・生成され、 ヒアリング・モジュールにより、医療従事者が患者質問を行うことで、それら質問に対応する、患者の最近の体調や症状に関する情報を回答として入手し、患者からの回答の内容（回答情報）を自動記録する機能が実現されており、当該機能を実施する際に、どのような情報を指定・追加するかといった点が記述されており、 患者毎に生成されたグループに係る患者の医療情報をこのグループのメンバーに限定して閲覧可能とすることで、患者のプライバシーを確保しながら患者に係る医療情報をグループのメンバー間で共有できるものであり、 例えば、「気になる症状の確認」及び「食生活の確認」という２つの質問メッセージを用いたヒアリング機能が実現されて、患者はメッセージの記入やファイルのアップロードによってこれらの質問に回答することができる、 医療支援システム。」 ２．引用文献２について 原査定の拒絶の理由に引用された上記引用文献２には、図面とともに次の事項が記載されている。（下線は当審で付した。） 「【００３８】 ＴＵＳ発行モジュール２６は、ユーザ端末からの発行要求をユーザインタフェース２１が受信した場合に、他のサーバに問い合わせ等を行うことなくＷｅｂ連携サーバＷＦＳ１－ＷＦＳｍ内で一時ユーザ指定子（以下、ＴＵＳ：Ｔｅｍｐｏｒａｒｙ Ｕｓｅｒ Ｓｐｅｃｉｆｉｅｒと呼称する）を発行するもので、図４に示すようにＴＵＳ文字列生成処理部２６１と、暗号化処理部２６２とからなる。 【００３９】 ＴＵＳ文字列生成処理部２６１は、ＴＵＳの発行を要求したユーザを識別するための情報と、ＴＵＳの有効期間を表す情報と、乱数を含むＴＵＳ文字列を生成する。またＴＵＳ文字列には、ユーザ属性と、発行元となるＷｅｂ連携サーバＷＦＳ１－ＷＦＳｍのプロバイダＩＤと、表示名を含めることも可能である。 【００４０】 図２にＴＵＳの構成要素を示す。発行要求元ユーザを識別するための情報としては、システムユーザＩＤ、仮名等が用いられる。乱数は８桁のランダムな数値からなる。有効期間は有効期限開始日時とその終了日時とにより表される。ユーザ属性は、ログインユーザの所属組織情報とロール情報からなる。所属組織情報には、ログインユーザが所属する機関（病院、診療所、自治体等）を表す情報が含まれる。ロール情報には、ログインユーザが保有するロール（医療従事者資格など）が含まれる。 【００４１】 ＴＵＳにユーザ属性を埋め込むことは、特に医療従事者資格を有するプロユーザがＴＵＳを発行する場合において有用である。例えば、一般ユーザが自らのアクセス制御ルールに「Ａ病院の医師には自分の情報を開示する」というルールを記述したい場合、ＴＵＳに組織やロールを含めることによって、ユーザＩＤの設定と同様に所属組織とロール情報を設定することが可能となる。すなわち、ＴＵＳはその目的により使い分けることができる。図３はその目的別のＴＵＳの種類を示すものである。また、ＴＵＳにプロバイダＩＤを埋め込むことで、ＴＵＳ発行元のＷｅｂ連携サーバＷＦＳ１－ＷＦＳｍ以外でもＴＵＳ解決を受け付けることが可能となる。 【００４２】 さらに、ＴＵＳにニックネームや質問／回答等の表示名を埋め込むと、後述するＴＵＳの解決処理時に、ＴＵＳに埋め込んだニックネームを解決要求元のユーザ端末に表示して発行元のユーザを確認させることができる。また、質問に対する回答を要求することにより、発行要求元のユーザが、本当に自分が意図する相手のＴＵＳであることを解決要求元のユーザ端末に確認させることができる。すなわち、ＴＵＳに埋め込まれたユーザ識別情報が本当にＴＵＳを渡された実在の人物を指しているのかを解決要求元のユーザ端末が確認することができる。 【００４３】 暗号化処理部２６２は、上記生成されたＴＵＳ文字列を認証サーバＩＤＰの公開鍵を用いて暗号化する。またその際、セキュリティをさらに強化するため、Ｗｅｂ連携サーバＷＦＳ１－ＷＦＳｍの秘密鍵を用いてＴＵＳ文字列に署名を付与する。この暗号化処理がなされたＴＵＳは、ユーザインタフェース２１から発行要求元のユーザ端末へ返送される。 【００４４】 ＴＵＳ解決要求モジュール２７は、ユーザ端末から送信された暗号化ＴＵＳの解決要求をユーザインタフェース２１が受信した場合に、このユーザから受け取った暗号化ＴＵＳを認証サーバＩＤＰへ転送してＴＵＳの解決を要求する。そして、解決処理により変換されたＴＵＳを認証サーバＩＤＰから受信し、ユーザインタフェース２１から要求元のユーザ端末へ返送する。」 「【００８３】 （２）他者によるユーザの医療関係情報の取得（利用シーンＢ） ここでは、例えばデータプロバイドサーバＤＰＳ１で管理されているユーザＡの医療関係情報を、例えばその家族或いは担当医師であるユーザＢが取得する場合を例にとって説明する。図９乃至図１１はそのシーケンスを示す図である。 【００８４】 （２－１）ＴＵＳの発行 医療関連情報を取得させようとするユーザＡは、自身のユーザ端末において、図９に示すように先ずシステムに対しログインする（ステップＳ９１）。そうすると認証サーバＩＤＰにおいて上記ログインユーザの認証処理が行われ（ステップＳ９２）、ログインユーザの正当性が認められるとその応答がログイン元のユーザ端末に返送される。 【００８５】 この状態で、ユーザＡがユーザ端末においてＴＵＳの発行を要求するための操作を行ったとする（ステップＳ９３）。この要求操作も、先に（１）で述べたアクセス制御ルールへのユーザ情報の登録の場合と同様に、ユーザ端末には操作画面が表示され、ユーザＡは表示されたメニューの中で「ＴＵＳ発行」を選択する。そして、ＴＵＳに含めるための図２に示した各構成要素（パラメータ）を任意に入力する。そうすると、ユーザ端末ではＴＵＳ発行要求が生成され、このＴＵＳ発行要求はＷｅｂ連携サーバＷＦＳ２へ送信される。 【００８６】 Ｗｅｂ連携サーバＷＦＳ２は、上記ＴＵＳ発行要求を受信するとステップＳ９４においてＴＵＳを発行して要求元のユーザ端末へ返送する。このＴＵＳの発行処理は以下のように行われる。 すなわち、Ｗｅｂ連携サーバＷＦＳ２は、ユーザ端末から送信されたＴＵＳ発行要求をユーザインタフェース２１で受信すると、ＴＵＳ発行モジュール２６により、先ず受信されたＴＵＳ発行要求に含まれる入力パラメータ（図２の項番３－７）をチェックする。そして、情報流通モジュール２３を呼び出し、情報流通モジュール２３が管理する要求元ユーザの認証結果情報を取得する。 【００８７】 例えば、先ず入力パラメータにてロール情報（ロールＩＤ）又は所属組織情報（所属組織コード）が指定されている場合には、これらが上記認証結果情報の中に存在するか否かを判定する。この判定の結果、認証結果情報に含まれていれば、Ｗｅｂ連携サーバＷＦＳ２のローカルユーザＩＤと認証サーバＩＤＰのプロバイダＩＤを検索キーとしてローカルユーザデータベース２８に対しアクセスし、ローカルユーザＩＤに相当する仮名を読み出す。続いて、情報流通モジュール２３を呼び出し、この情報流通モジュール２３が管理するＷｅｂ連携サーバ（自プロバイダ）ＷＦＳ２のプロバイダＩＤを取得する。そして、ＴＵＳを生成する各構成要素、つまり上記ユーザ端末から受信した入力パラメータ、上記取得された仮名及び乱数を連結する。 【００８８】 次に、上記連結されたＴＵＳの構成要素を認証サーバＩＤＰの公開鍵で暗号化する。そして、この生成された暗号化文字列に認証サーバＩＤＰのプロバイダＩＤと、上記取得た自己のＷｅｂ連携サーバＷＦＳ２のプロバイダＩＤを連結してＴＵＳとする。なお、暗号化にはＲＳＡ暗号などを使用する。最後に、上記生成された暗号化ＴＵＳを、ユーザインタフェース２１から要求元のユーザ端末へ返送する。 なお、上記ＴＵＳの受信後にユーザＢがログアウト操作を行うと（ステップＳ９５）、認証サーバＩＤＰにおいてログアウトが受け付けられて、ログアウト処理される（ステップＳ９６）。 【００８９】 （２－２）発行されたＴＵＳの受け渡し Ｗｅｂ連携サーバＷＦＳ２から送られたＴＵＳは、図１２に示すようにユーザＡのユーザ端末からユーザＢのユーザ端末へ例えば電子メールにより送信される（ステップＳ１０１，Ｓ１０２）。なお、上記ＴＵＳの受け渡しは、ＴＵＳをＦＤやＵＳＢメモリ等の記憶媒体に保存し、この記憶媒体をユーザＡからユーザＢに手渡しすることで行ってもよい。このＴＵＳの受け渡しの具体例としては、発行されたＴＵＳのみ又はＴＵＳを発行したＷｅｂ連携サーバＷＦＳ２のＵＲＬと発行されたＴＵＳを埋め込んだＵＲＬを作成し、このＵＲＬを記述した電子メールをユーザＡの端末からユーザＢの端末へ送信する。 【００９０】 （２－３）ＴＵＳの解決とその利用 ユーザＡの医療関連情報を取得しようとするユーザＢは、自身のユーザ端末において、図１１に示すように先ずシステムに対しログインする（ステップＳ１１１）。そうすると認証サーバＩＤＰにおいて上記ログインユーザの認証処理が行われ（ステップＳ１１２）、ログインユーザの正当性が認められるとその応答がログイン元のユーザ端末に返送される。 【００９１】 この状態で、ユーザＢがユーザ端末において、ユーザＡから渡されたＴＵＳの解決を要求するための操作を行ったとする（ステップＳ１１３）。そうすると、ユーザ端末ではＴＵＳ解決要求が生成され、このＴＵＳ解決要求はＷｅｂ連携サーバＷＦＳ１へ送信される。Ｗｅｂ連携サーバＷＦＳ１は、上記ＴＵＳ解決要求を受信するとステップＳ１１４によりこのＴＵＳ解決要求を認証サーバＩＤＰへ転送する。認証サーバＩＤＰは、転送されたＴＵＳを解決し（ステップＳ１１５）、その結果を要求元のユーザＢのユーザ端末へ返送する。 【００９２】 Ｗｅｂ連携サーバＷＦＳ１は、ユーザ端末から送信されたＴＵＳ解決要求をユーザインタフェース２１により受信すると、ＴＵＳ解決要求モジュール２７が要求されたＴＵＳに含まれる入力パラメータをチェックする。そして、情報流通モジュール２３を呼び出し、情報流通モジュール２３が管理する要求元ユーザの認証結果情報を取得する。続いて、認証サーバＩＤＰに送付するＴＵＳ解決要求電文を作成し、上記取得した要求元ユーザの認証結果と、上記作成されたＴＵＳ解決要求電文とを引数として情報流通モジュール２３を呼び出し、認証サーバＩＤＰへＴＵＳ解決要求電文を送信する。 【００９３】 認証サーバＩＤＰは、Ｗｅｂ連携サーバＷＦＳ１から送信されたＴＵＳ解決要求電文を情報流通モジュール３３により受信すると、ＴＵＳ解決モジュール３５が上記受信されたＴＵＳ解決要求電文をチェックする。そして、ＴＵＳ解決要求電文よりＴＵＳを取得し、認証サーバＩＤＰの秘密鍵で復号する。 【００９４】 次に、ＴＵＳ解決モジュール３５は、上記復号されたＴＵＳの有効期限をチェックする。このチェックの結果、有効期限開始日時が設定されない場合には、すでに解決処理が開始されているものとして扱う。また、有効期限終了日時が設定されない場合には無期限として扱う。 【００９５】 続いて、ＴＵＳ解決モジュール３５は、上記復号されたＴＵＳがＴＵＳ失効リストデータベース３８に記憶されていないか否かを判定する。つまり、上記復号されたＴＵＳが失効していないかどうかを確認する。この判定の結果、解決を要求されたＴＵＳが失効していなければ、上記復号されたＴＵＳの仮名と、ＴＵＳ解決要求電文に含まれるＴＵＳ発行元のＷｅｂ連携サーバＷＦＳ２のプロバイダＩＤを検索キーとして、情報流通モジュール３３を介してシステムユーザデータベース３７に対しアクセスし、仮名及びプロバイダＩＤに対応するシステムユーザＩＤを取得する。 【００９６】 続いて、ＴＵＳ解決モジュール３５は、上記取得されたシステムユーザＩＤと、ＴＵＳ解決要求電文にＴＵＳ解決要求元のＷｅｂ連携サーバＷＦＳ１のプロバイダＩＤを検索キーとして、情報流通モジュール３３を介してシステムユーザデータベース３７に対しアクセスし、これによりシステムユーザＩＤに該当する仮名を取得する。この処理により、ＴＵＳ発行元のＷｅｂ連携サーバＷＦＳ２とは異なるＷｅｂ連携サーバＷＦＳ１でも、ＴＵＳ解決要求を行うことができる。 【００９７】 続いて、ＴＵＳ解決モジュール３５は、上記取得された仮名と、ＴＵＳから抽出したロール情報（ロールＩＤ）、所属組織情報（所属組織コード）および表示名とを含む応答電文を作成する。そして、この作成された応答電文を情報流通モジュール３３から要求元のＷｅｂ連携サーバＷＦＳ１へ返送する。 【００９８】 認証サーバＩＤＰから応答電文を受け取ると、Ｗｅｂ連携サーバＷＦＳ１のＴＵＳ解決要求モジュール２７は、上記受け取ったＴＵＳ解決応答電文からＴＵＳの構成要素である仮名、所属組織情報、ロール情報、表示名を取得し、ＴＵＳの発行元ユーザのユーザ識別子を生成する。そして、この生成されたＴＵＳの発行元ユーザのユーザ識別子をユーザインタフェース２１から解決要求元のユーザ端末へ返送する。 【００９９】 上記ＴＵＳの発行元ユーザのユーザ識別子を受信すると、ユーザＢはこの受信したユーザ識別子をもとにユーザＡの医療関連情報を取得するための操作を行う（ステップＳ１１６）。例えば、このときユーザ端末には操作画面が表示され、ユーザＢは表示されたメニューの中で「情報取得」を選択する。そうすると、ユーザ端末では情報取得要求が生成され、この情報取得要求はＷｅｂ連携サーバＷＦＳ１へ送信される。 【０１００】 Ｗｅｂ連携サーバＷＦＳ１は、上記ユーザ端末から送信された情報取得要求をユーザインタフェース２１により受信すると、情報取得要求モジュール２５が、ユーザＢの認証結果情報と、上記受信された情報取得要求に含まれるユーザＡのユーザ識別子を引数として、情報流通モジュール２３を介して認証サーバＩＤＰからデータプロバイドサーバ向けのユーザＡ及びユーザＢの識別子を取得する。そして、この取得したデータプロバイドサーバ向けのユーザＢ及びユーザＡの識別子をもとに、アクセス先のデータプロバイドサーバＤＰＳ１へ情報流通モジュール２３から情報取得要求を送信する（ステップＳ１１７）。 【０１０１】 データプロバイドサーバＤＰＳ１は、Ｗｅｂ連携サーバＷＦＳ１から送信された情報取得要求を情報流通モジュール１２により受信すると、情報提供モジュール１３が、上記要求に応じてローカルユーザデータベース１７から該当するユーザＡのローカルユーザＩＤを読み出す。そして、この読み出されたローカルユーザＩＤをもとに医療関連情報データベース１５に対しアクセスし、上記ユーザＡの該当する医療関連情報を読み出す。そして、この読み出された医療関連情報を、情報流通モジュール１２から要求元のＷｅｂ連携サーバＷＦＳ１へ送信する（ステップＳ１１８）。 【０１０２】 Ｗｅｂ連携サーバＷＦＳ１は、上記データプロバイドサーバＤＰＳ１から送信された医療関連情報を情報流通モジュール２３で受信すると、情報取得要求モジュール２５の制御の下で、この受信された医療関連情報をユーザインタフェース２１からユーザＢのユーザ端末へ転送する。」 したがって、上記引用文献２には、 「ユーザＡの医療関係情報を担当医師であるユーザＢが取得するにあたって、 ユーザＡは、自身のユーザ端末において、システムにログインして、一時ユーザ指定子（ＴＵＳ）の発行を要求するための操作を行って、Ｗｅｂ連携サーバから送信されたＴＵＳをユーザＢのユーザ端末へ送信し、 ユーザＢは、自身のユーザ端末において、システムにログインして、ユーザＡから渡されたＴＵＳの解決を要求するための操作を行い、Ｗｅｂ連携サーバから発行元ユーザ（ユーザＡ）のユーザ識別子を受信して、ユーザＡの医療関連情報を取得するための操作を行い、 ＴＵＳは、ＴＵＳの発行を要求したユーザを識別するための情報と、ＴＵＳの有効期間を表す情報と、乱数を含むＴＵＳ文字列を認証サーバの公開鍵を用いた暗号化処理と、Ｗｅｂ連携サーバの秘密鍵を用いて署名が付与されることを含む暗号化処理がなされたものが発行要求元のユーザ端末に返送されるものであり、ＴＵＳ文字列には、さらに、ユーザ属性と、発行元となるＷｅｂ連携サーバのプロバイダＩＤと、表示名を含めることも可能であり、 Ｗｅｂ連携サーバは、 ユーザＡのユーザ端末からのＴＵＳ発行要求を受信して、ＴＵＳを発行して要求元のユーザ端末へ返送し、 ユーザＢのユーザ端末からのＴＵＳ解決要求を受信して、このＴＵＳ解決要求を認証サーバへ転送し、認証サーバから応答電文を受け取ると、応答電文からＴＵＳの発行元ユーザ（ユーザＡ）のユーザ識別子を生成して解決要求元（ユーザＢ）のユーザ端末へ返送し、ユーザＢのユーザ端末から情報取得要求を受信してデータプロバイドサーバからユーザＡの該当する医療関連情報を受信してユーザＢのユーザ端末に転送し、 認証サーバは、ＴＵＳ解決要求電文よりＴＵＳを取得して、認証サーバの秘密鍵で復号し、復号されたＴＵＳの有効期限をチェックし、その際、有効期限開始日時が設定されない場合には、すでに解決処理が開始されているものと扱い、有効期限終了日時が設定されない場合は無期限として扱い、上記応答電文を要求元のＷｅｂ連携サーバに返送する、 システム」 の技術的事項が記載されていると認められる。 ３．引用文献３について 引用文献３には、病院利用支援システムにおいて、患者タブレット端末１の操作に応じて患者情報の閲覧を医師タブレット端末２を操作する医師に許可すること、医師は医師タブレット端末２から患者の患者情報を閲覧して、患者に対して診察の推奨や診察予約を行うこと（段落［００１２］－［００４０］、［００７６］－［００８５］、図１等）が記載されている。 第５ 対比・判断 １．本願発明１について （１）対比 本願発明１と引用発明とを対比すると、次のことがいえる。 ア 引用発明における「患者」、「患者端末」、「医療従事者」、「医療関係施設」及び「医療従事者端末」は、本願発明１における「サービスの利用者」、「利用者端末」、「医療従事者」、「医療機関」及び「医療機関端末」にそれぞれ相当する。 イ 引用発明における「患者の最近の体調や症状に関する情報」である「回答情報」は、記録されるサービスの利用者の医療情報である点で、本願発明１の「利用者の医療情報」に相当しており、両者は利用者の医療情報を受信し、受信した医療情報を記録する医療情報記録部を有する点で一致する。 ウ 引用発明における「指示」のうち、グループのメンバーである医療従事者の医療機関端末からの利用者の医療情報の共有を求めるための「指示」と本願発明１の「閲覧要求」とは、利用者の医療情報を医療機関端末に送信するための医療機関端末からの閲覧要求である点で共通しており、両者は、医療機関端末からの閲覧要求に応答して医療情報記録部から抽出された情報を当該医療機関端末に送信する医療情報抽出部を有する点で共通するといえる。 エ 引用発明の「医療支援システム」と本願発明１の「情報処理システム」とは、下記の相違点を除いて、共通しているといえる。してみると、両者は、次の一致点で一致するといえる。 （一致点） 「サービスの利用者が使用する利用者端末、または、前記利用者が利用している医療機関の医療従事者が使用する医療機関端末から、前記利用者の医療情報を受信し、受信した前記医療情報を記録する医療情報記録部と、 前記医療機関端末からの閲覧要求に応答して、情報を前記医療情報記録部から抽出し、抽出した情報を前記医療機関端末に送信する医療情報抽出部と、 を有する、 情報処理システム。」 オ そして、両者は、次の相違点１～相違点３で相違している。 （相違点） （相違点１） 本願発明１は「 前記利用者端末からのアクセスキー発行要求に応答して、前記医療情報を閲覧するためのアクセスキーを、前記医療機関に紐付けて発行し、発行した前記アクセスキーを前記利用者端末に送信するアクセスキー発行部」を有し、「アクセスキーの有効期限を設けない」のに対し、引用発明はアクセスキー発行部を有しない点。 （相違点２） 本願発明１の医療期間端末からの閲覧要求は「医療機関端末からのアクセスキーを伴う」ものであるのに対し、引用発明の閲覧要求は有効期限を設けないアクセスキーを伴うものでなく、患者毎に生成されたグループに係る患者の医療情報をこのグループのメンバーに限定して閲覧可能としている点。 （相違点３） 本願発明１の閲覧要求に応答して抽出されて医療期間端末に送信される情報は、「医療情報に含まれる情報項目のうち開示が許可に設定されている情報項目に係る情報」であるのに対し、引用発明では、そうではない点。 （２）相違点についての判断 ア 上記相違点１、２は、関連しているので、まとめて検討する。 原査定における副引例である引用文献２の記載事項は、「第４ 引用文献、引用発明等」の「２．引用文献２について」に記載のとおりであり、要するに、引用文献２には、ユーザＡの医療関係情報を担当医師であるユーザＢが取得するにあたってユーザＡの要求により発行された「一時ユーザ指定子（ＴＵＳ）」をユーザＢが解決要求することによって、取得が可能となる技術が記載されている。ここで、引用文献２の「一時ユーザ指定子（ＴＵＳ）」は、「ＴＵＳの発行を要求したユーザを識別するための情報」、「ＴＵＳの有効期間を表す情報」、「乱数」を含むものであり、さらに、「ユーザ属性」、「発行元Ｗｅｂ連携サーバのプロバイダＩＤ」、「表示名」を含むことが可能であり、「認証サーバの公開鍵を用いて暗号化」されるとともに「Ｗｅｂ連携サーバの秘密鍵を用いて署名が付与」されているものである。 しかしながら、相違点１、２に係る本願発明１の「アクセスキー」は、「医療機関に紐付けて」発行されるとともに「有効期限を設けない」ものであり、これにより本願発明１は、「医師にとってはアクセスキーが患者に固有のものとして管理することが可能となり使い勝手が向上する。また、利用者（患者）にとっても、診察に度に新しいアクセスキーを医師に提示する必要が無く、一度提示するだけで、以降の自己の医療情報を医師が任意に閲覧可能となり、使い勝手の向上とともに、何時でも医師により見守られている安心感を得ることができ」（明細書段落【００４２】）るという効果を奏するものであるのに対し、引用文献２には、「一時ユーザ指定子（ＴＵＳ）」について、医療機関に紐付けて発行されることは記載されておらず、さらに、有効期限とともに暗号化され署名が付与されているものであるから、両者は、異なる機能を有するものである。 イ また、請求項１０、１１（補正前の請求項９、１０）について引用された文献である引用文献３の記載事項は、「第４ 引用文献、引用発明等」の「３．引用文献３について」に記載のとおりであり、引用文献３にも、相違点１、２に係る「アクセスキー」に係る技術的事項の記載はない。 よって、当業者といえども、引用発明並びに引用文献２及び引用文献３に記載された技術的事項から、相違点１、２に係る本願発明１の構成を容易に想到することはできない。 ウ なお、原査定では、引用文献２において「一時ユーザ指定子（ＴＵＳ）」について、有効期限終了日時が設定されない場合には無期限と扱うことが記載されていること、医療関係情報の利用形態は医療業務の実態に応じて様々なものが想定され、必要に応じて医療関係情報へのアクセスを複数の医師に対して無期限に許容する必要性が発生することも想定されることを示して、引用発明と引用文献２に記載された技術的事項から容易想到である旨を説示している。 しかしながら、引用文献２には、「一時ユーザ指定子（ＴＵＳ）」について、有効期限終了日時が設定されない場合には無期限と扱うことが記載されているものの、この記載は、何らかの原因で有効期限終了日時が設定されていない場合にＴＵＳの解決ができなくなることを避ける旨を示すにとどまり、有効期限をあえて設定しない趣旨を示す記載ではない。また、本願発明１の「アクセスキー」は「医療機関に紐付け」されているものであるのに対して引用文献２の「一時ユーザ指定子（ＴＵＳ）」がそのようなものでないことに照らせば、必要に応じて医療関係情報へのアクセスを複数の医師に対して無期限に許容する必要性があることは、相違点１、２についての容易想到性判断と無関係である。 エ したがって、上記相違点３について判断するまでもなく、本願発明１は、当業者であっても、引用発明並びに引用文献２及び引用文献３に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。 ２．本願発明２－１１について 本願発明２－１１は、本願発明１を減縮した発明であり、上記相違点１、２に係る本願発明１の構成と同一の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明並びに引用文献２及び引用文献３に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。 ３．本願発明１２について 本願発明１２は、システムの発明である本願発明１に対応するプログラムの発明であるり、上記相違点１、２に係る本願発明１の構成に対応する構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明並びに引用文献２及び引用文献３に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。 第６ むすび 以上のとおり、本願発明１－１２は、当業者が引用発明並びに引用文献２及び引用文献３に記載された技術的事項に基づいて容易に発明をすることができたものではない。したがって、原査定の理由によっては、本願を拒絶することはできない。 また、他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。