2024-700755

特許第７４３０９１２号発明「リハビリテーション支援システム、リハビリテーション支援サーバ、医療端末装置の制御方法および患者端末装置の制御方法」の特許異議申立事件について、次のとおり決定する。

結 論 特許第７４３０９１２号の請求項１～２１に係る特許を維持する。

理 由 第１ 手続の経緯 特許第７４３０９１２号（以下、「本件特許」という。）の請求項１～２１に係る特許についての出願は、令和２年１２月３日に出願され、令和６年２月５日にその特許権の設定登録がされ、同年２月１４日に特許掲載公報が発行された。その後、本件特許に対し、令和６年８月９日に特許異議申立人 中村 哲平（以下「異議申立人」という。）は、特許異議の申立てを行った。 第２ 本件発明 特許第７４３０９１２号の請求項１～２１に係る発明（以下、それぞれ「本件発明１」～「本件発明２１」という。）は、特許請求の範囲の請求項１～２１に記載された事項により特定される次のとおりのものである（なお、請求項１におけるA、B等の符号は合議体が付した。）。 「【請求項１】 A 遠隔心臓リハビリテーションを支援するリハビリテーション支援システムであって、 B 前記遠隔心臓リハビリテーションの支援業務を行うためのサーバ装置と、 C 医療関係者が使用し、第１通信ネットワークを介して前記サーバ装置と通信する医療端末装置と、 D 前記医療関係者の監視対象者であって前記遠隔心臓リハビリテーションを受ける患者が使用し、前記第１通信ネットワークと異なる第２通信ネットワークを介して前記サーバ装置と通信し、前記患者に負荷を提供するエルゴメータと接続される患者端末装置とを備え、 E 前記遠隔心臓リハビリテーションの実施中、前記サーバ装置を介した前記患者端末装置から前記医療端末装置への送信はリアルタイムで実行され、 F 前記サーバ装置は、前記遠隔心臓リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備える、リハビリテーション支援システム。 【請求項２】 リハビリテーションを支援するリハビリテーション支援システムであって、 前記リハビリテーションの支援業務を行うためのサーバ装置と、 医療関係者が使用し、第１通信ネットワークを介して前記サーバ装置と通信する医療端末装置と、 前記医療関係者の監視対象者であって前記リハビリテーションを受ける患者が使用し、前記第１通信ネットワークと異なる第２通信ネットワークを介して前記サーバ装置と通信し、前記患者に負荷を提供する機器と接続される患者端末装置とを備え、 前記サーバ装置は、前記リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備え、 前記患者端末装置は、 前記キープアライブ信号送受信部から前記応答信号を受信する患者側応答受信部と、 前記患者側応答受信部が前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記機器による負荷提供の中止を指示する端末側中止指示部とを備える、リハビリテーション支援システム。 【請求項３】 リハビリテーションを支援するリハビリテーション支援システムであって、 前記リハビリテーションの支援業務を行うためのサーバ装置と、 医療関係者が使用し、第１通信ネットワークを介して前記サーバ装置と通信する医療端末装置と、 前記医療関係者の監視対象者であって前記リハビリテーションを受ける患者が使用し、前記第１通信ネットワークと異なる第２通信ネットワークを介して前記サーバ装置と通信し、前記患者に負荷を提供する機器と接続される患者端末装置とを備え、 前記サーバ装置は、前記リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備え、 前記医療端末装置は、 前記キープアライブ信号送受信部から前記応答信号を受信する医療側応答受信部と、 前記医療側応答受信部が前記応答信号を最後に受信してから前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力する出力部とを備え、 前記サーバ装置は、さらに、 前記キープアライブ信号送受信部が前記医療端末装置から前記キープアライブ信号を最後に受信してから前記キープアライブ信号を前記第１所定期間より長い第２所定期間受信しないとき、前記患者端末装置の各々に対して前記機器による負荷提供の中止を指示するサーバ側中止指示部を備える、リハビリテーション支援システム。 【請求項４】 前記医療端末装置は、 前記キープアライブ信号送受信部から前記応答信号を受信する医療側応答受信部と、 前記医療側応答受信部が前記応答信号を最後に受信してから前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力する出力部とを備える、請求項１に記載のリハビリテーション支援システム。 【請求項５】 前記医療端末装置は、 前記キープアライブ信号送受信部から前記応答信号を受信する医療側応答受信部と、 前記医療側応答受信部が前記応答信号を最後に受信してから前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力する出力部とを備える、請求項２に記載のリハビリテーション支援システム。 【請求項６】 前記サーバ装置は、 前記キープアライブ信号送受信部が前記医療端末装置から前記キープアライブ信号を最後に受信してから前記キープアライブ信号を前記第１所定期間より長い第２所定期間受信しないとき、前記患者端末装置の各々に対して前記エルゴメータによる負荷提供の中止を指示するサーバ側中止指示部を備える、請求項４に記載のリハビリテーション支援システム。 【請求項７】 前記サーバ装置は、 前記キープアライブ信号送受信部が前記医療端末装置から前記キープアライブ信号を最後に受信してから前記キープアライブ信号を前記第１所定期間より長い第２所定期間受信しないとき、前記患者端末装置の各々に対して前記機器による負荷提供の中止を指示するサーバ側中止指示部を備える、請求項５に記載のリハビリテーション支援システム。 【請求項８】 前記患者端末装置は、 前記キープアライブ信号送受信部から前記応答信号を受信する患者側応答受信部と、 前記患者側応答受信部が前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記エルゴメータによる負荷提供の中止を指示する端末側中止指示部を備える、請求項１、４、および６の何れか１項に記載のリハビリテーション支援システム。 【請求項９】 前記患者端末装置は、 前記キープアライブ信号送受信部から前記応答信号を受信する患者側応答受信部と、 前記患者側応答受信部が前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記機器による負荷提供の中止を指示する端末側中止指示部を備える、請求項３、５、および７の何れか１項に記載のリハビリテーション支援システム。 【請求項１０】 前記患者端末装置は、 前記第１通信ネットワークおよび前記第２通信ネットワークと異なる第３通信ネットワークを介して前記サーバ装置と通信可能であり、 前記患者側応答受信部が前記応答信号を受信しない期間が前記上限期間に到達する前に、前記患者側応答受信部が前記応答信号を最後に受信してから前記応答信号を第３所定期間受信しないとき、前記サーバ装置と通信するための通信ネットワークを、前記第２通信ネットワークから前記第３通信ネットワークに切り替える通信切替部を備える、請求項２、８、および９の何れか１項に記載のリハビリテーション支援システム。 【請求項１１】 前記患者端末装置は、 前記患者側応答受信部が前記応答信号を受信しない期間が前記上限期間に到達する前に、前記患者側応答受信部が前記応答信号を最後に受信してから前記応答信号を第４所定期間受信しないとき、前記第２通信ネットワークを用いて通信を行うための機能を再起動させる通信再起動部を備える、請求項２、および８～１０の何れか１項に記載のリハビリテーション支援システム。 【請求項１２】 前記サーバ装置は、 前記キープアライブ信号送受信部が前記患者端末装置から前記キープアライブ信号を最後に受信してから前記キープアライブ信号を第５所定期間受信しないとき、前記医療端末装置に対して第２所定メッセージを送信する送信部を備える、請求項１から１１の何れか１項に記載のリハビリテーション支援システム。 【請求項１３】 遠隔心臓リハビリテーションの支援業務を行うためのリハビリテーション支援サーバであって、 医療関係者が使用する医療端末装置と第１通信ネットワークを介して通信する第１通信制御部と、 前記医療関係者の監視対象者であって前記遠隔心臓リハビリテーションを受ける患者が使用し、前記患者に負荷を提供するエルゴメータと接続される患者端末装置と前記第１通信ネットワークと異なる第２通信ネットワークを介して通信する第２通信制御部と、 前記遠隔心臓リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備え、 前記遠隔心臓リハビリテーションの実施中、前記患者端末装置から前記医療端末装置への送信をリアルタイムで実行する、リハビリテーション支援サーバ。 【請求項１４】 リハビリテーションの支援業務を行うためのリハビリテーション支援サーバであって、 医療関係者が使用する医療端末装置と第１通信ネットワークを介して通信する第１通信制御部と、 前記医療関係者の監視対象者であって前記リハビリテーションを受ける患者が使用し、前記患者に負荷を提供する機器と接続される患者端末装置と前記第１通信ネットワークと異なる第２通信ネットワークを介して通信する第２通信制御部と、 前記リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備え、 前記患者端末装置は、 前記キープアライブ信号送受信部から前記応答信号を受信する患者側応答受信部と、 前記患者側応答受信部が前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記機器による負荷提供の中止を指示する端末側中止指示部とを備える、リハビリテーション支援サーバ。 【請求項１５】 リハビリテーションの支援業務を行うためのリハビリテーション支援サーバであって、 医療関係者が使用する医療端末装置と第１通信ネットワークを介して通信する第１通信制御部と、 前記医療関係者の監視対象者であって前記リハビリテーションを受ける患者が使用し、前記患者に負荷を提供する機器と接続される患者端末装置と前記第１通信ネットワークと異なる第２通信ネットワークを介して通信する第２通信制御部と、 前記リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部と、 前記キープアライブ信号送受信部が前記医療端末装置から前記キープアライブ信号を最後に受信してから前記キープアライブ信号を前記第１所定期間より長い第２所定期間受信しないとき、前記患者端末装置の各々に対して前記機器による負荷提供の中止を指示するサーバ側中止指示部とを備え、 前記医療端末装置は、 前記キープアライブ信号送受信部から前記応答信号を受信する医療側応答受信部と、 前記医療側応答受信部が前記応答信号を最後に受信してから前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力する出力部とを備える、リハビリテーション支援サーバ。 【請求項１６】 医療関係者が使用する医療端末装置の制御方法であって、 前記医療端末装置は、第１通信ネットワークを介して、遠隔心臓リハビリテーションの支援業務を行うためのサーバ装置と通信するものであり、 前記サーバ装置は、前記遠隔心臓リハビリテーションの実施中、前記医療関係者の監視対象者であって前記遠隔心臓リハビリテーションを受ける患者が使用する患者端末装置、および、前記医療端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備えるものであり、 前記患者端末装置は、前記第１通信ネットワークと異なる第２通信ネットワークを介して前記サーバ装置と通信し、前記患者に負荷を提供するエルゴメータと接続されるものであり、 前記遠隔心臓リハビリテーションの実施中、前記サーバ装置を介した前記患者端末装置から前記医療端末装置への送信はリアルタイムで実行され、 前記医療端末装置が、 前記キープアライブ信号送受信部から前記応答信号を受信すること、および、 前記応答信号を最後に受信してから前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力することを含む、 医療端末装置の制御方法。 【請求項１７】 医療関係者が使用する医療端末装置の制御方法であって、 前記医療端末装置は、第１通信ネットワークを介して、リハビリテーションの支援業務を行うためのサーバ装置と通信するものであり、 前記サーバ装置は、前記リハビリテーションの実施中、前記医療関係者の監視対象者であって前記リハビリテーションを受ける患者が使用する患者端末装置、および、前記医療端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備えるものであり、 前記患者端末装置は、 前記第１通信ネットワークと異なる第２通信ネットワークを介して前記サーバ装置と通信し、前記患者に負荷を提供する機器と接続されるものであり、 前記キープアライブ信号送受信部から前記応答信号を受信する患者側応答受信部と、 前記患者側応答受信部が前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記機器による負荷提供の中止を指示する端末側中止指示部とを備えるものであり、 前記医療端末装置が、 前記キープアライブ信号送受信部から前記応答信号を受信すること、および、 前記応答信号を最後に受信してから前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力することを含む、 医療端末装置の制御方法。 【請求項１８】 医療関係者が使用する医療端末装置の制御方法であって、 前記医療端末装置は、第１通信ネットワークを介して、リハビリテーションの支援業務を行うためのサーバ装置と通信するものであり、 前記サーバ装置は、前記リハビリテーションの実施中、前記医療関係者の監視対象者であって前記リハビリテーションを受ける患者が使用する患者端末装置、および、前記医療端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備えるものであり、 前記医療端末装置は、 前記キープアライブ信号送受信部から前記応答信号を受信する医療側応答受信部と、 前記医療側応答受信部が前記応答信号を最後に受信してから前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力する出力部とを備えるものであり、 前記サーバ装置は、さらに、 前記キープアライブ信号送受信部が前記医療端末装置から前記キープアライブ信号を最後に受信してから前記キープアライブ信号を前記第１所定期間より長い第２所定期間受信しないとき、前記患者端末装置の各々に対して前記患者に負荷を提供する機器による負荷提供の中止を指示するサーバ側中止指示部を備えるものであり、 前記患者端末装置は、 前記第１通信ネットワークと異なる第２通信ネットワークを介して前記サーバ装置と通信し、前記機器と接続されるものであり、 前記医療端末装置が、 前記キープアライブ信号送受信部から前記応答信号を受信すること、および、 前記応答信号を最後に受信してから前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力することを含む、 医療端末装置の制御方法。 【請求項１９】 医療関係者の監視対象者であって遠隔心臓リハビリテーションを受ける患者が使用する患者端末装置の制御方法であって、 前記患者端末装置は、前記遠隔心臓リハビリテーションの支援業務を行うためのサーバ装置と医療関係者が使用する医療端末装置とが通信するための第１通信ネットワークと異なる第２通信ネットワークを介して前記サーバ装置と通信し、前記患者に負荷を提供するエルゴメータと接続されるものであり、 前記サーバ装置は、前記遠隔心臓リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備えるものであり、 前記遠隔心臓リハビリテーションの実施中、前記サーバ装置を介した前記患者端末装置から前記医療端末装置への送信はリアルタイムで実行され、 前記患者端末装置が、 前記キープアライブ信号送受信部から前記応答信号を受信すること、および、 前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記エルゴメータによる負荷提供の中止を指示することを含む、 患者端末装置の制御方法。 【請求項２０】 医療関係者の監視対象者であってリハビリテーションを受ける患者が使用する患者端末装置の制御方法であって、 前記患者端末装置は、リハビリテーションの支援業務を行うためのサーバ装置と医療関係者が使用する医療端末装置とが通信するための第１通信ネットワークと異なる第２通信ネットワークを介して前記サーバ装置と通信し、前記患者に負荷を提供する機器と接続されるものであり、 前記サーバ装置は、前記リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備えるものであり、 前記患者端末装置は、 前記キープアライブ信号送受信部から前記応答信号を受信する患者側応答受信部と、 前記患者側応答受信部が前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記機器による負荷提供の中止を指示する端末側中止指示部とを備えるものであり、 前記患者端末装置が、 前記キープアライブ信号送受信部から前記応答信号を受信すること、および、 前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記機器による負荷提供の中止を指示することを含む、 患者端末装置の制御方法。 【請求項２１】 医療関係者の監視対象者であってリハビリテーションを受ける患者が使用する患者端末装置の制御方法であって、 前記患者端末装置は、リハビリテーションの支援業務を行うためのサーバ装置と医療関係者が使用する医療端末装置とが通信するための第１通信ネットワークと異なる第２通信ネットワークを介して前記サーバ装置と通信し、前記患者に負荷を提供する機器と接続されるものであり、 前記サーバ装置は、前記リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備えるものであり、 前記医療端末装置は、 前記キープアライブ信号送受信部から前記応答信号を受信する医療側応答受信部と、 前記医療側応答受信部が前記応答信号を最後に受信してから前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力する出力部とを備え、 前記サーバ装置は、さらに、 前記キープアライブ信号送受信部が前記医療端末装置から前記キープアライブ信号を最後に受信してから前記キープアライブ信号を前記第１所定期間より長い第２所定期間受信しないとき、前記患者端末装置の各々に対して前記機器による負荷提供の中止を指示するサーバ側中止指示部を備えるものであり、 前記患者端末装置が、 前記キープアライブ信号送受信部から前記応答信号を受信すること、および、 前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記機器による負荷提供の中止を指示することを含む、 患者端末装置の制御方法。」 第３ 申立理由の概要 １ 異議申立人の提出した証拠 異議申立人は、次の甲第１号証～甲第１２号証（以下、それぞれ「甲１」～「甲１２」という。）を証拠として提出している。 甲第１号証（甲１）： Lecture Notes in Computer Science, in book Virtual Reality and Augmented Reality, “A Low-Cost Virtual Reality Bike for Remote Cardiac Rehabilitation" Boulanger P., Pournajib A., Mott W., Schaeffer S., 07 December 2017, p.155-166, <URL https://doi.org/10.1007/978-3-319-72323-5_10> 甲第２号証（甲２）：特表２０１５－５０２６７９号公報 甲第３号証（甲３）：特表２０１３－５３７６７５号公報 甲第４号証（甲４）：特開２０１５－１８０１０１号公報 甲第５号証（甲５）：特表２０１４－５０８４４２号公報 甲第６号証（甲６）：特表２００８－５３８０２８号公報 甲第７号証（甲７）：特開２０１８－１６６９３５号公報 甲第８号証（甲８）：特開２０２０－０５７０８２号公報 甲第９号証（甲９）：特開２００６－２７７５８５号公報 甲第１０号証（甲１０）：特許第４２８２２８３号公報 甲第１１号証（甲１１）：特開２００６－２６８５４２号公報 甲第１２号証（甲１２）：特許第４６６５０４０号公報 ２ 特許異議の申立理由 異議申立人の主張は、概略、以下のとおりである。 （１）本件発明１、１３は、甲１に記載された発明、及び周知技術（甲２～甲６。以下「周知技術１」という。）に基づいて、当業者が容易に想到し得るものであるから、本件特許は、特許法第２９条第２項の規定に違反してされたものである。 （２）本件発明２、８～１１、１４、１９、２０は、甲１に記載された発明、周知技術１（甲２～甲６）、甲７、甲８に記載の周知技術（以下「周知技術２」という。）、及び甲９に記載の技術に基づいて、当業者が容易に想到し得るものであるから、本件特許は、特許法第２９条第２項の規定に違反してされたものである。 （３）本件発明３～７、１２、１５～１８、２１は、甲１に記載された発明、周知技術１（甲２～甲６）、甲７～甲９に記載の技術、及び周知技術（甲１０～甲１２。以下「周知技術３」という。）に基づいて、当業者が容易に想到し得るものであるから、本件特許は、特許法第２９条第２項の規定に違反してされたものである。 第４ 異議申立人の提出した証拠の記載 １ 甲１について （１）甲１の記載 甲１には、以下の記載がある（下記イの訳は異議申立人が提出したものによる。下線は当審において付加した。以下同じ。） ア 「A Low-Cost Virtual Reality Bike for Remote Cardiac Rehabilitation」 （訳：遠隔心臓リハビリテーションのための低コストのバーチャルリアリティバイク） イ 「3 Proposed Method In this section, we present the proposed VR system for retrofitting the low cost stationary bike, the software for MedBike system and the data flows between patient, bike, server, and clinicians. At the end of this section, the process VR rendering by updating camera is explained. Furthermore, the resistance computation method in the proposed VR system is described. 3.1 Patient’s VR System The Figure 1 presents the patient’s MedBike hardware configuration. The system consists of a stationary bike from Sunny Inc which has been retrofitted with stepper motor to control the bike resistance according to the VR terrain. The stepper motor is controlled by an Arduino board where a linear potentiometer connects the brake pads and interprets the movement of the brake pads to the control board. For sensing the bike rotation speed, a rotary encoder is mounted on the front wheel of the stationary bike. Since stationary bike have no steering capabilities, two force sensors have been mounted beneath the handle bar where the force difference between the two-hand steer the bike from left to right or right to left. All sensors are digitized by an Arduino board. In addition, a FAN which is controlled by an Arduino board according to a wind rendering algorithm. All communications between the control board and graphic rendering PC is performed using of WiFi which is embedded in the control board. The bike is also instrumented with a professional wireless (ANT+) cadence sensor and an Android tabletmounted on the handle bar which is responsible for collecting the vital sign sensors (ECG, Oximeter, Blood Pressure meter) using Bluetooth. The tablet is also used as the main interface for the patient initiating authentication, selecting menu items, and controlling the bike configurations. The tablet communicates with the graphic PC using WiFi. The rendering PC is a high-end graphic computer which is responsible for running Unity 3D in synchronization with bike sensors and instructions from the clinician. This PC is the HUB of the system (See Figure 3) and is responsible for: ・ Rendering the virtual world based on bike sensor data (see Figure 2); ・ Controlling the programmable resistance machine based on the virtual world terrain and the specifications from the clinician; ・ Establishing secure audio/video connection with the clinician using WebRTC; ・ Performing data encryption; ・ Logging patient information to a MedBike server using Django application with MySQL database; ・ Receiving clinician information to specify minimum and maximum cadence and power ranges the patient should achieve during his/her training; ・ Updating and animating other cyclist avatar locations when the system is in multi-player mode. ［図：0001416530000001.jpg］ Figure 1: MedBike Patient Hardware Flowchart 3.2 Clinician’s Tele-Monitoring System On the clinician side, the system is based on a high-end PC where all the information from up to four patients can be displayed and analyzed. The session starts by first establishing patient and clinician authentication credentials with the MedBike server. Once established, each patient is attributed an encryption key to encode the information transmitted during the session. The system allows the clinician access to past session reports from the server which includes: ・ Date and time of the session ・ Mode (clinical or single player) ・ Duration of the session ・ Session Biodata Summary o Min/Avg/Max of heart rate and % oxygen saturation (if selected in exercise prescription) o Peak RPE value o Resting, exercising, and post-session blood pressure ・ Session Bike Summary o Min/Avg/Max power and cadence o Total distance ・ ECG data, including: o The complete ECG for the session, viewable on a mm-calibrated grid; o Highlights of the ECG with notes made by the clinician; ［図：0001416530000002.jpg］ Figure 2: Med Bike Patient GUI Display 3.3 Data Integrity One of the key requirements of the MedBike system is its ability to preserve patient’s privacy and to guaranty data integrity. Since the application must run on public networks this privacy requirement is truly critical. As illustrated in Figure 3, privacy is preserved in two ways. All communication with the MedBike server, located in a secure location near the hospital where the clinician resides, is encrypted using HTTPS. This secure connection is leveraged to allow the clinician and patient to exchange a new encryption key every session, and used to encrypt biodata as it is streamed from each patient to the clinician. Communication between MedBike and the data center is hidden to port scanning using a VPN. Once the encrypted connections are established the clinician can then monitor each patient. Because the clinician operates the system from within the hospital, he can also access the patient medical records inside the protection of the Alberta Health Services network which is separate from the public internet. This electronic access to the patient medical records is critical to the rehabilitation process and this information must never be transmitted on the public internet. As for data integrity, the clinician can observe the readings of the bio sensors and determine if they are in the acceptable range. In addition, transmission errors in data sent from patient to clinician can be detected by the integrity mechanisms built into the AES-GCM cipher used for encryption, while data uploaded to the server relies on the integrity mechanisms inherent to HTTPS (TCP checksums, as well as HMACs used in the selected cipher suite). ［図：0001416530000003.jpg］ Figure 3: MedBike Dataflow Flowchart」 「（訳） 3 提案される方法 本節では、低価格の固定式自転車に後付けするVRシステムの提案、MedBikeシステムのソフトウェア、患者、自転車、サーバ、臨床医間のデータの流れを紹介する。本節の最後では、カメラ更新によるVRレンダリング処理について説明する。さらに、提案するVRシステムにおける抵抗計算方法について述べる。 3.1 患者のVRシステム 図１に患者のMedBikeのハードウェア構成を示す。このシステムは、VRの地形に応じて自転車の抵抗を制御するためにステッピングモーターを後付けしたサニー社のステーショナリーバイクで構成されている。ステッピングモーターはArduinoボードで制御され、リニアポテンショメーターがブレーキパッドを接続し、ブレーキバッドの動きを制御ボードに伝える。自転車の回転速度を検知するために、ロータリーエンコーダが固定自転車の前輪に取り付けられている。ステーショナリーバイクにはステアリング機能がないため、2つのカセンサーがハンドルバーの下に取り付けられており、両手の力の差でバイクを左から右、または右から左にステアリングする。すべてのセンサーはArduinoボードでデジタル化されている。さらに、風カレンダリングアルゴリズムに従ってArduinoボードによって制御されるFANも搭載されている。制御ボードとグラフィックレンダリングPC間の通信はすべて、制御ボードに内蔵されたWiFiを使って行われる。 自転車には、プロ仕様のワイヤレス(ANT+) ケイデンスセンサーと、ハンドルバーに取り付けられたアンドロイドタブレットが搭載されており、ブルートゥースを使用してバイタルサインセンサー(ECG、オキシメーター、血圧計）の収集を行う。タブレットは、患者が認証を開始し、メニュー項目を選択し、バイクの設定を制御するためのメインインターフェイスとしても使用される。タブレットはWiFiを使用してグラフィックPCと通信する。レンダリングPCはハイエンドのグラフィックコンピューターで、自転車センサーや臨床医からの指示と同期してUnity3Dを実行する。このPCはシステムのHUBであり（図３参照）、以下の役割を果たす： ・ 自転車のセンサーデータに基づいて仮想世界をレンダリング（図２参照）； ・ 仮想世界の地形と臨床医からの仕様に基づいて、プログラマブル・レジスタンス・マシンを制御する； ・ WebRTCを使用して臨床医との安全な音声／ビデオ接続を確立する； データ暗号化の実行； ・ MySQLデータベースとDjangoアプリケーションを使用して、MedBikeサーバに患者情報を記録； ・ 患者がトレーニング中に達成すべき最小・最大ケイデンスとパワー範囲を指定するための臨床医の情報を受け取る； ・ システムがマルチプレーヤーモードにあるとき、他のサイクリストのアバターの位置を更新し、アニメーション化する。 3.2 医師による遠隔監視システム 臨床医側では、システムはハイエンドのPCをベースにしており、最大4人の患者のすべての情報を表示し、分析することができる。セッションは、まず患者と臨床医の認証情報をMedBikeサーバと確立することから始まる。認証が確立されると、各患者にはセッション中に送信される情報を暗号化するための暗号キーが割り当てられる。このシステムにより、臨床医はサーバから過去のセッションレポートにアクセスできる： ・ セッション日時 ・ モード（臨床またはシングルプレーヤー） ・ セッション時間 ・ セッション・バイオデータ・サマリー o 心拍数と酸素飽和度の最小／最大／最小値（運動処方で選択した場合） o ピークRPE値 o 安静時、運動時、セッション後の血圧 ・ セッションバイクまとめ o 最小／平均／最大パワーとケイデンス o 総距離 ・ ECGデータ： o セッションの完全なECGを、mm単位で較正されたグリッド上に表示可能； o 心電図のハイライトと臨床医によるメモ； 3.3 データの完全性 MedBike システムの重要な要件の一つは、患者のプライバシーを守り、データの完全性を保証する能力である。アプリケーションは公共ネットワーク上で実行されなければならないので、このプライバシー要件は本当に重要である。図３に示すように、プライバシーは2つの方法で保護される。臨床医が居住する病院の近くの安全な場所に設置されたMedBikeサーバとの通信はすべてHTTPSを使用して暗号化される。この安全な接続を利用して、臨床医と患者はセッションごとに新しい暗号鍵を交換し、各患者から臨床医にストリーミングされるバイオデータを暗号化する。MedBike とデータセンター間の通信は、VPNを使用してポートスキャンに隠蔽される。暗号化された接続が確立されると、臨床医は各患者をモニターすることができる。臨床医は病院内からシステムを操作するため、公衆インターネットとは別のアルバータ保健サービスネットワークの保護内で患者の医療記録にアクセスすることもできる。患者の医療記録への電子的なアクセスは、リハビリテーション・プロセスにとって非常に重要であり、この情報は決して公共のインターネット上で送信されてはならない。データの完全性に関しては、臨床医は生体センサーの測定値を観察し、許容範囲内かどうかを判断することができる。さらに、患者から臨床医に送信されるデータの送信エラーは、暗号化に使用されるAES-GCM暗号に組み込まれた完全性メカニズムによって検出することができ、サーバにアップロードされるデータは、HTTPSに固有の完全性メカニズム(TCPチェックサム、および選択された暗号スイート で使用されるHMAC) に依存する。」 ウ 甲１の図１を参照すると、図１には、患者のMedBikeのハードウェア構成が図示されており、アンドロイドタブレット（Android Tablet）と静的バイク（Static Bike）が、WiFiルータ（WiFi Router）にWiFi接続されており、WiFiルータが患者PC（PC With MedBIKE Patient Application）にWiFi接続されている構成が見て取れる。 エ 甲１の図３を参照すると、図３には、MedBikeシステムにおけるデータフローのフローチャートが図示されており、患者PC（Patient PC）とアンドロイドタブレットとは互いにデータの送受信を行うものであり、患者PCとアンドロイドタブレットはそれぞれMedBikeサーバ（MedBike Server）とデータの送受信を行うものであり、MedBikeサーバは、臨床医PC（Clinician PC）とデータの送受信を行うことが見て取れる。 （２）甲１発明 ア 上記（１）アによれば、甲１は、遠隔心臓リハビリテーションのための低コストのバーチャルリアリティバイクに関するものであって、かつ、上記（１）イによれば、低価格の固定式自転車に後付けするVRシステムの提案、MedBikeシステムのソフトウェア、患者、自転車、サーバ、臨床医間のデータの流れを紹介するとしているので、甲１には、「遠隔心臓リハビリテーションのためのMedBikeシステム」が開示されているといえる。 イ 上記（１）ウによれば、MedBikeシステムにおける患者側のハードウェア構成は、アンドロイドタブレット（Android Tablet）と静的バイク（Static Bike）が、WiFiルータ（WiFi Router）にWiFi接続されており、WiFiルータが患者PC（PC With MedBIKE Patient Application）にWiFi接続されていることから、患者PCはWiFiルータを介して静的バイク（Static Bike）に接続されているものである。 ウ 上記（１）エによれば、MedBikeシステムでは、患者PC（Patient PC）とアンドロイドタブレットとは互いにデータの送受信を行うものであり、患者PCと前記アンドロイドタブレットはそれぞれMedBikeサーバ（MedBike Server）とデータの送受信を行うものであり、MedBikeサーバは、臨床医PC（Clinician PC）とデータの送受信を行うものである。 よって、「MedBikeシステムは、MedBikeサーバ、患者PC、アンドロイドタブレット、及び臨床医PCとを備え」ており、「患者PCとアンドロイドタブレットとは互いにデータの送受信を行う」ものであって、患者PC、アンドロイドタブレット、及び臨床医PCは、それぞれMedBikeサーバとデータの送受信を行うものであるから、「患者PC、アンドロイドタブレット、臨床医PCは、それぞれネットワークを介してMedBikeサーバと接続されている」といえる。 そして、上記アを踏まえると、「MedBikeサーバ」は、患者が「遠隔心臓リハビリテーション」の実施中、「患者PC」と「アンドロイドタブレット」のそれぞれとデータの送受信を行うとともに、「臨床医PC」ともデータの送受信を行うものであることは明らかである。 エ 上記（１）イによれば、「アンドロイドタブレット」は、「バイタルサインセンサー(ECG、オキシメーター、血圧計）の収集を行」い、「WebRTCを使用して臨床医との安全な音声／ビデオ接続を確立」し、「患者がトレーニング中に達成すべき最小・最大ケイデンスとパワー範囲を指定するための臨床医の情報を受け取る」ものであり、「臨床医側では、」「患者のすべての情報を表示し、分析することができ」、「セッションは、患者と臨床医の認証情報をMedBikeサーバと確立することから始まる」ものである。 オ 上記ア～エを踏まえると、甲１には、「MedBikeシステム」に関する次の発明（以下、「甲１発明１」という。）が記載されている。 「遠隔心臓リハビリテーションのためのMedBikeシステムであって、 MedBikeサーバ、患者PC、アンドロイドタブレット、及び臨床医PCとを備え、 患者PCとアンドロイドタブレットとは互いにデータの送受信を行うものであり、 患者PC、アンドロイドタブレット、臨床医PCは、それぞれネットワークを介してMedBikeサーバと接続されており、 患者PCは、WiFiルータを介してMedBikeに含まれる静的バイクと接続されており、 アンドロイドタブレットはバイタルサインセンサー(ECG、オキシメーター、血圧計）の収集を行い、 WebRTCを使用して臨床医との安全な音声／ビデオ接続を確立し、 患者がトレーニング中に達成すべき最小・最大ケイデンスとパワー範囲を指定するための臨床医の情報を受け取るものであり、 臨床医側では、患者のすべての情報を表示し、分析することができ、セッションは、患者と臨床医の認証情報をMedBikeサーバと確立することから始まり、 患者が遠隔心臓リハビリテーションの実施中、MedBikeサーバは、前記患者PCと前記アンドロイドタブレットのそれぞれとデータの送受信を行うとともに、前記臨床医PCともデータの送受信を行う、 遠隔心臓リハビリテーションのためのMedBikeシステム。」 カ また、上記ア～エを踏まえると、甲１には、「MedBikeサーバ」に関する次の発明（以下、「甲１発明２」という。）が記載されている。 「MedBikeサーバ、患者PC、アンドロイドタブレット、及び臨床医PCとを備えた遠隔心臓リハビリテーションのためのMedBikeシステムにおけるMedBikeサーバであって、 MedBikeサーバは、 ネットワークを介して、前記患者PC、前記アンドロイドタブレット、前記臨床医PCと接続されており、 患者が遠隔心臓リハビリテーションの実施中、前記患者PCと前記アンドロイドタブレットのそれぞれとデータの送受信を行うとともに、前記臨床医PCともデータの送受信を行う、 MedBikeサーバ。」 キ 甲１に記載の「臨床医PC」は制御されて動作するものであることは明らかであり、上記ア～エを踏まえると、甲１には、「臨床医PCの制御方法」に関する次の発明（以下、「甲１発明３」という。）が記載されている。 「MedBikeサーバ、患者PC、アンドロイドタブレット、及び臨床医PCとを備えた遠隔心臓リハビリテーションのためのMedBikeシステムにおける、臨床医PCの制御方法であって、 臨床医PCは、ネットワークを介してMedBikeサーバと接続し、 患者が心臓疾患のためのリハビリテーションを行っている実施中、MedBikeサーバとデータの送受信を行う、 臨床医PCの制御方法。」 ク 甲１に記載の「患者PC」及び「アンドロイドタブレット」は、いずれも制御されて動作するものであることは明らかであり、上記ア～エを踏まえると、甲１には、「患者PC及びアンドロイドタブレットの制御方法」に関する次の発明（以下、「甲１発明４」という。）が記載されている。 「MedBikeサーバ、患者PC、アンドロイドタブレット、及び臨床医PCとを備えた遠隔心臓リハビリテーションのためのMedBikeシステムにおける、患者PC及びアンドロイドタブレットの制御方法であって、 患者PC及びアンドロイドタブレットは、ネットワークを介してMedBikeサーバと接続し、 患者PCは、WiFiルータを介してMedBikeに含まれる静的バイクと接続されており、 患者PC及びアンドロイドタブレットは、患者が心臓疾患のためのリハビリテーションを行っている実施中、MedBikeサーバとデータの送受信を行う、 患者PC及びアンドロイドタブレットの制御方法。」 ２ 甲２について 甲２（特表２０１５－５０２６７９号公報）には、以下の記載がある。 「【０００２】 本開示のいくつかの態様は、一般にワイヤレス通信に関し、より詳細には、干渉を受けにくいワイヤレス技術を使用してデバイス間で重要な情報を送信することに関する。」 「【００１５】 例示的な通信システム 図1に、コントローラ/ハブ102と1つまたは複数のワイヤレスデバイス104をもつ例示的な分散通信システム100を示す。コントローラ/ハブ102は、1つまたは複数のアンテナを使用して1つまたは複数のワイヤレスチャネルを介して、および/または1つまたは複数のワイヤード接続を介してワイヤレスデバイス104と通信し得る。本コントローラ/ハブ102は、IEEE802.11ネットワークではアクセスポイント(AP)またはWi-Fiホットスポットと同様に機能し得る。 【００１６】 通信システム100は、病院、クリニック、ホスピス、またはホームなど、ヘルスケア環境で使用され得る。そのような場合、ワイヤレスデバイス104は、薬物注入ポンプ、血圧計、パルスオキシメータ、心電図(ECG)など、様々な好適なワイヤレス医療デバイスのうちのいずれかを含み得る。コントローラ/ハブ102は単一の患者に関連し得、コントローラ/ハブ102およびそれに関連するワイヤレスデバイスは室内ネットワーク110を形成し得る。室内ネットワーク110は、ローカルエリアネットワーク(LAN)またはホームネットワークと同様に機能し得る。いくつかのワイヤレスデバイス104は、患者に装着され(たとえば、指に装着または手首に装着するユニット)、患者の体に挿入または移植され、あるいは患者のベッド、車輪付き担架(gurney)、衣類、または概して物理的に患者の近くにある他のデバイス(たとえば、歩行器、つえ、腕時計、または眼鏡)に取り付けられるかまたは埋め込まれ得る。」 「【００１９】 サーバ108は、コントローラ/ハブ102とヘルスケア施設のイントラネットとの間のインターフェースを提供し得る。ヘルスケア情報システム(HIS)の一部として、サーバ108は、患者の電子医療記録(EMR)を記憶し、この記録へのアクセスを提供し得るので、療法を患者のアレルギーと照合するためのインテリジェンスを提供し、矛盾する投薬などを防止し得る。いくつかの態様では、コントローラ/ハブ102は、室内ネットワーク110と施設のイントラネットとの間の唯一のインターフェースを提供し得る。コントローラ/ハブ102は、ワイヤード技術(たとえば、イーサネット（登録商標）)を介して直接、ワイヤード技術によってサーバ108に接続されたワイヤレスルータを介して間接的に、あるいはパブリックまたはプライベートの、ワイヤード、ワイヤレス、またはハイブリッドのネットワーク技術によって間接的に、施設のイントラネットに接続され得る。」 「【００２９】 デバイス104が動作すると、複数のデバイスを効率的に管理するために、これらのデバイスは、コントローラ/ハブ102が監視することができるビーコンを繰り返し(たとえば、断続的、周期的、または間欠的に)送信し得る。ビーコンは、「ハートビート」またはキープアライブメッセージとも呼ばれることもある。いくつかの態様では、複数のデバイスからのビーコンの衝突確率が低くなるように、ビーコンは、時間、周波数、および/またはコード空間においてランダム化され、離間され得る。ビーコンは、他のデバイスのチャネルの利用可能性を高めるために小さいペイロードを有し得る。そのようなペイロードは、少量のパフォーマンスデータと、コントローラ/ハブ102とデバイス104との間の双方向通信を必要とする障害(すなわち、エラー)または他のイベントが発生したかどうかを示すコードとを含み得る。コントローラ/ハブ102は、進行中の様々な治療または動作の経過を追跡するため、ならびに様々なデバイス104が依然としてレンジ内にあり、動作していると判断するために、ビーコンを監視し得る。1つまたは複数のデバイス104が誤動作を示し始めると、コントローラ/ハブ102は患者のための最良の治療を行うためにデバイス間の優先順位を決定し得る。」 「【００３６】 第2の情報は、ビーコンメッセージ(たとえば、ハートビートまたはキープアライブメッセージ)を含み得、第2の装置が機能しており、第1の装置のレンジ内にあることを示し得る。第2の情報は、第2の装置からのデータ、またはエラーなどのイベントが、第2の装置において発生したかどうかの指示のうちの少なくとも1つを含み得る。イベントの指示は、障害コードを含み得る。いくつかの態様では、第2の装置は、ポンプで注入する液体の量、心拍数、血圧、ブドウ糖レベルなどのパラメータを判断し得る。第2の装置からのデータは、判断されたパラメータの指示のうちの少なくとも1つを含み得る。」 「【図１】 ［図：0001416530000004.jpg］ 」 ３ 甲３について 甲３（特表２０１３－５３７６７５号公報）には、以下の記載がある。 「【０００１】 この発明は、医療装置間での確実な相互運用のための方法およびシステムに関する。」 「【００１８】 図2は、ファーストパーティ製造業者が、いかにして自社の装置を、サードパーティハードウェアを用いて動作させることが可能となるかを例示する図である。この例では、インターフェイス装置122が、装置104～118と、サードパーティ制御器120との間のブリッジとなるように設けられている。インターフェイス装置122は、リンク126、128、130、および132をそれぞれ介して装置106、110、112、および118の対応するデータインターフェイスに接続するように構成された複数の第1のハードウェア接続ポート124を特徴とする。インターフェイス装置122はまた、サードパーティ制御器120へのリンク136を実現する第2のハードウェア接続ポート134を特徴とする。この例では、装置104、108、114、および116は、それぞれのベースユニットに連結され、インターフェイス装置122に独立に連結されてはいないが、特定の装置群、および装置間のデータ流れの構成が、単なる例示の目的で示されていることが理解されよう。諸実施形態には、この例で示す個数よりも多数の、または少数のハードウェア接続ポート124の使用が含まれる。」 「【００３０】 いくつかの実施形態では、インターフェイス装置は、ブロック306でコマンドを受信し、そのコマンドを適切なファーストパーティプロトコルに変換し、次いでブロック308で、そのコマンドをファーストパーティ装置に中継し、その後ファーストパーティ装置は、それに応答してデータを返送する。次いで、ブロック310で、返送されたデータを変換し、サードパーティ装置に送信することができる。しかし、以下で説明するように、いくつかの実施形態では、インターフェイス装置は、「アスクミー(ask-me)」ベースで動作し、パラレルプロセスを用いてファーストパーティおよびサードパーティ装置と通信するものであり、すなわち、インターフェイス装置は、ファーストパーティ装置を周期的にポーリングし、サードパーティ装置から要求を受信したときのために、各装置からのキャッシュデータを準備している。」 「【００３２】 図4は、ファーストパーティ医療装置(106、110、および118)、インターフェイス装置122、およびサードパーティ装置120の三者間でのデータ交換を示すデータ流れ図400である。本明細書では、説明しやすいようにファーストパーティ装置を3台示しているが、当然ながら、その原理は、装置の台数に関わらず適用可能である。」 「【００４３】 図4の一例として、サードパーティ装置120は、418および420で示すデータを、それぞれのポートを介して同時に受信することができる。この期間中、ハートビートポートを介して、通信412および414を行って、接続の成立を確保することができる。また、この期間中、インターフェイス装置122は、418および420で示すデータとは無関係のデータを供給および/または受信することができ、例えば、インターフェイス装置は、データ418および420を供給している間も、そのデータを供給したそれぞれのファーストパーティ装置からさらに新しいデータが送られている途中であることがあり、また、それぞれの接続を介して、さらなるコマンドを他のファーストパーティ装置に供給することができる。」 「【００４５】 図5A～5Bは、インターフェイス装置によって実行することができる例示的な処理方法500を示す流れ図である。概括的な原理については図3を参照しながら上記で論じたが、図5A～5Bは、医療事例で求められる、堅牢な接続性を実現し、数多くの更新を行うために使用できる、より詳細な例を示す。この例では、方法500は、502から開始し、並列した2つの分岐504(図5Aに示す)および506(図5Bに示す)を含む。インターフェイス装置のプロセッサによって並列スレッドを実行することができる場合、各分岐は、それ自体のスレッドを備えることができ、またはこれらの分岐を、マルチタスキング可能なプロセッサを用いて実施することができる。さらに、プロセッサは、各ファーストパーティ装置について、分岐504の事例を実現することができ、分岐504の様々な事例を用いて、接続されている装置を同時に接続することができる。」 「【００４８】 一実施形態では、各ファーストパーティ装置は、250ミリ秒ごとにポーリングされるが、当然ながら他の時間間隔も使用することができ、数回の再試行を試みることができる。したがって図5Aは、再試行が必要であるかを判定する段階を表す再試行ブロックを含む。再試行が必要である場合、流れはブロック512に戻る。そうでない場合、すなわち再試行が必要でない場合、流れはブロック514に進み、このブロックは、装置タイムアウトがあるか、または装置が予期せぬ応答、もしくは不明朗な応答を供給しているかを判定する段階を表す。そうである場合、適切なエラー処理ルーチンをトリガすることができ、例えば、エラー状態を提示する前に、全体的なポーリングシーケンスを限定された回数で再試行するよう試みることができる。次いで、流れは、分岐504が、ブロック512まで1レベル後戻りして、ポーリングを再試行している間、「キープアライブ」コマンドを供給する段階に進む。一実施形態では、ポーリングシーケンスを4回試みた(各試みにおいて、再試行回数を使い果たし、また、その結果タイムアウトになった)後、本方法は、ブロック510に戻って、装置を再度識別しようと試みる。 【００４９】 しかし、ブロック512で、ポーリングした装置がそのポーリングに応答した場合(すなわち、ブロック514でタイムアウトしない)、ブロック516に達する。ブロック516は、ファーストパーティ装置から返送されたデータに基づいて、インターフェイス装置のメモリ内の現在のデータを更新する段階を表す。インターフェイス装置は、各ファーストパーティ装置のデータフォーマットおよび通信プロトコルを認識し、返送されたデータをメモリ内に記憶するように構成されている。データは、インターフェイス装置に固有のフォーマットを用いて記憶する、ファーストパーティプロトコルに従って供給されたフォーマットで記憶する、または第2の通信プロトコルに従って変換し記憶することができる。適切なエラー処理ルーチンを用いて、上記のように応答を検証することができ、例えば、チェックサムデータまたは他のコーディングが問題を示す場合、エラー状態を示すことができる。この場合もやはり「キープアライブ」要求が供給され、流れはブロック511～512に戻り、データがあるか再度確認し、必要であれば装置をポーリングする。 【００５０】 いくつかの実施形態では、接続されているファーストパーティ装置の全てを、分岐504に従って接続し通信させることができる。しかし、他の実施形態では、装置を順次ポーリングすることもできる。さらに、このルーチンには、装置を接続/切断する際の適切な操作を含めることができ、すなわち新しい装置が接続されると、ポーリングシーケンスを開始することができ、ある装置が切断されると、適切な段階を踏んでポーリング工程を終えることができる。実際には、接続が確立された後、ハンドシェイキング要求、およびキープアライブ要求を、状態更新およびサービス更新でインターリーブすることができる。」 「【図２】 ［図：0001416530000005.jpg］ 」 「【図４】 ［図：0001416530000006.jpg］ 」 「【図５Ａ】 ［図：0001416530000007.jpg］ 」 ４ 甲４について 甲４（特開２０１５－１８０１０１号公報）には、以下の記載がある。 「【０００２】 本発明は、概して、コンピュータネットワークに関し、より具体的には、中間サーバによって医療デバイスを遠隔医療サービスおよびサポート提供者につなぐための、ワイヤレス通信ハブに関する。」 「【００２４】 図1Aは、様々な実施形態によって可能にされる通信システムに含まれ得る、システムコンポーネントを示す。図1Aに示されるように、種々の電子医療またはフィットネスデバイス102、104、108(たとえば、血圧計、血糖測定器、および体重計)は、ローカルネットワーク105(ローカルエリアワイヤレスネットワーク(たとえば、WiFi、Bluetooth(登録商標)、Zigbee(登録商標)、およびANT+)または有線ネットワーク(たとえば、USB)のような)を介して、データをワイヤレス通信ハブデバイス112へ送信することができ、通信ハブデバイス112は、暗号化されたデータをパッケージ化し、ワイヤレスワイドエリアネットワーク130(たとえば、3Gセルラーワイヤレスネットワーク)のようなワイヤレス通信リンクを介してデータをサービスプラットフォームサーバ140へ送信し、サービスプラットフォームサーバ140において、データは、データベース内でアンパックされ記憶され、または、データが記憶され処理され得る他のシステムへ転送され得る。図1Aはまた、3つの短距離無線プロトコルを通じた、ハブを通る、様々な電子医療およびフィットネスデバイスからのデータの流れの高レベルの図を提供する。様々な実施形態では、各データセットが、デバイスおよび技術によって、固有の、場合によってはプロプライエタリなフォーマットで記憶されるように、各デバイスから収集されるデータは、端から端まで暗号化され安全に管理され得る。このように、ワイヤレス通信ハブデバイスは、様々な電子医療およびフィットネスデバイスからのデータまたは情報の、サービスプラットフォームサーバを通じた、インターネットクラウドに配置される介護者または提供者のサーバおよびデータベースへのワイヤレスな伝送を安全に可能にする、ゲートウェイとして動作する。」 「【００５８】 図3Eは、様々な実施形態のワイヤレス通信ハブデバイス112の中に存在するメモリ302に記憶され得る、構成可能な可能性のある機能およびパラメータを示す、データ構造図である。メモリ302は、トランザクションデータがオフピークにアップロードされるべきかそうではないかを示すフラグのようなトランザクションデータアップロードフラグ352、データを送信する前に必要な最小のサービス品質(QoS)レベルのようなQoSパラメータ、ワイヤレス通信ハブデバイスがサービスプラットフォームサーバとのデータ呼を一日に何回確立すべきかを示すパラメータ、および/または、所与の通信リンクを開放したままにする(すなわち生きたままにする)ために、キープアライブpingがどの程度頻繁にサービスプラットフォームサーバへ送信されるべきかを示すパラメータのような、データ呼周期パラメータ356、サービスプラットフォームサーバのDNS解決のためのURLおよびポート(たとえば、www.2net.com/data:56)ならびに/またはバックアップURLのような、URLおよびDNSポート情報358、サービスプラットフォームサーバにデータをアップロードする前にワイヤレス通信ハブデバイスに記憶されるべき、顧客当たりのトランザクションの最大の閾値のような、トランザクション記憶制限パラメータ360、記憶すべきトランザクションデータの量(すなわち、データサイズまたはトランザクションの総数)および/または最大の記憶容量のような、記憶制限362、セキュリティ/暗号化機構363(たとえば、advanced encryption standard (AES)暗号化)、タイムアウトするまでに、電子医療およびフィットネスデバイスのデータの受信をどの程度長く待機するかを示すパラメータのような、タイムアウトパラメータ364、電子医療およびフィットネスデバイスの発見、ペアリング、および認証を支援するためのアプリケーションまたはソフトウェアのような、構成ファイル366、ならびに、ワイヤレス通信ハブデバイスの認証コード(たとえば、筐体上に印刷された6桁の番号)のような、ハブID 368を格納し得る。様々な実施形態では、メモリ302は、本明細書で論じられる方法および機能を実行するために、必要に応じて、追加のパラメータ、機能、アルゴリズム、ソフトウェア、および/または制御手段を格納し得る。」 「【図１Ａ】 ［図：0001416530000008.jpg］ 」 「【図３Ｅ】 ［図：0001416530000009.jpg］ 」 ５ 甲５について 甲５（特表２０１４－５０８４４２号公報）には、以下の記載がある。 「【０００２】 本発明は、概して、コンピュータネットワークに関し、より具体的には、中間サーバによって医療デバイスを遠隔医療サービスおよびサポート提供者につなぐための、ワイヤレス通信ハブに関する。」 「【００２４】 図1Aは、様々な実施形態によって可能にされる通信システムに含まれ得る、システムコンポーネントを示す。図1Aに示されるように、種々の電子医療またはフィットネスデバイス102、104、108(たとえば、血圧計、血糖測定器、および体重計)は、ローカルネットワーク105(ローカルエリアワイヤレスネットワーク(たとえば、WiFi、Bluetooth(登録商標)、Zigbee(登録商標)、およびANT+)または有線ネットワーク(たとえば、USB)のような)を介して、データをワイヤレス通信ハブデバイス112へ送信することができ、通信ハブデバイス112は、暗号化されたデータをパッケージ化し、ワイヤレスワイドエリアネットワーク130(たとえば、3Gセルラーワイヤレスネットワーク)のようなワイヤレス通信リンクを介してデータをサービスプラットフォームサーバ140へ送信し、サービスプラットフォームサーバ140において、データは、データベース内でアンパックされ記憶され、または、データが記憶され処理され得る他のシステムへ転送され得る。図1Aはまた、3つの短距離無線プロトコルを通じた、ハブを通る、様々な電子医療およびフィットネスデバイスからのデータの流れの高レベルの図を提供する。様々な実施形態では、各データセットが、デバイスおよび技術によって、固有の、場合によってはプロプライエタリなフォーマットで記憶されるように、各デバイスから収集されるデータは、端から端まで暗号化され安全に管理され得る。このように、ワイヤレス通信ハブデバイスは、様々な電子医療およびフィットネスデバイスからのデータまたは情報の、サービスプラットフォームサーバを通じた、インターネットクラウドに配置される介護者または提供者のサーバおよびデータベースへのワイヤレスな伝送を安全に可能にする、ゲートウェイとして動作する。」 「【００５８】 図3Eは、様々な実施形態のワイヤレス通信ハブデバイス112の中に存在するメモリ302に記憶され得る、構成可能な可能性のある機能およびパラメータを示す、データ構造図である。メモリ302は、トランザクションデータがオフピークにアップロードされるべきかそうではないかを示すフラグのようなトランザクションデータアップロードフラグ352、データを送信する前に必要な最小のサービス品質(QoS)レベルのようなQoSパラメータ、ワイヤレス通信ハブデバイスがサービスプラットフォームサーバとのデータ呼を一日に何回確立すべきかを示すパラメータ、および/または、所与の通信リンクを開放したままにする(すなわち生きたままにする)ために、キープアライブpingがどの程度頻繁にサービスプラットフォームサーバへ送信されるべきかを示すパラメータのような、データ呼周期パラメータ356、サービスプラットフォームサーバのDNS解決のためのURLおよびポート(たとえば、www.2net.com/data:56)ならびに/またはバックアップURLのような、URLおよびDNSポート情報358、サービスプラットフォームサーバにデータをアップロードする前にワイヤレス通信ハブデバイスに記憶されるべき、顧客当たりのトランザクションの最大の閾値のような、トランザクション記憶制限パラメータ360、記憶すべきトランザクションデータの量(すなわち、データサイズまたはトランザクションの総数)および/または最大の記憶容量のような、記憶制限362、セキュリティ/暗号化機構363(たとえば、advanced encryption standard (AES)暗号化)、タイムアウトするまでに、電子医療およびフィットネスデバイスのデータの受信をどの程度長く待機するかを示すパラメータのような、タイムアウトパラメータ364、電子医療およびフィットネスデバイスの発見、ペアリング、および認証を支援するためのアプリケーションまたはソフトウェアのような、構成ファイル366、ならびに、ワイヤレス通信ハブデバイスの認証コード(たとえば、筐体上に印刷された6桁の番号)のような、ハブID 368を格納し得る。様々な実施形態では、メモリ302は、本明細書で論じられる方法および機能を実行するために、必要に応じて、追加のパラメータ、機能、アルゴリズム、ソフトウェア、および/または制御手段を格納し得る。」 「【図１Ａ】 ［図：0001416530000010.jpg］ 」 「【図３Ｅ】 ［図：0001416530000011.jpg］ 」 ６ 甲６について 甲６（特表２００８－５３８０２８号公報）には、以下の記載がある。 「【０００２】 （発明の分野） 本発明は概して、複数のネットワーク構成要素間の情報の通信のための方法、装置およびシステムに関し、具体的には、生理学および医療に関するデータを含め、潜在的に大きく多様なセットの定義されたデータを通信するよう構成された、コアおよび拡張可能なセットの機能性を有する、通信プロトコルのインターフェースおよび装置に関する。通信プロトコルのインターフェースを実装するソフトウェアは、拡張マークアップ言語（ＸＭＬ）の命令のセットから構成可能であり、また命令に応えてソフトウェア生成プログラムから生成される。」 「【００９８】 図３Ｆは、ネットワーク構成要素１１０ｃ、１４０ｎ間で伝送されるキープアライブ通信３９２、３９４を示すブロック図である。キープアライブ通信３９２、３９４は、受信するネットワーク構成要素に、送信するネットワーク構成要素１１０ｃ、１４０ｎがネットワーク構成要素１１０ｃ、１４０ｎとの間の特定の接続上の通信に対して動作中（活動中）であることを表示する。キープアライブ通信を受信することが予期されている受信するネットワーク構成要素が、所定の期間にわたりキープアライブ通信を受信しない場合、その結果、送信するネットワーク構成要素１１０ｃ、１４０ｎは通信するのにもはや利用できないことを推論することができる。 【００９９】 キープアライブ通信３９２、３０４は、キープアライブメッセージ３９０とも称される、キープアライブタイプのＭＯＭＰメッセージ３９０を含む。通常のＭＯＭＰメッセージ３００と同様に、キープアライブメッセージ３９０は、識別子フィールド３０２、メッセージサイズフィールド３０４、メッセージ暗号化フィールド３０６および巡回冗長チェック（ＣＲＣ）フィールド３１０を含む。普通のＭＯＭＰメッセージ３００と異なり、キープアライブメッセージ３９０は、オブジェクトバッファフィールド３０８を除外する。 【０１００】 キープアライブメッセージ３９０は、第１の分類テキスト文字列識別子「ＦｍＣＯＮＮＥＣＴＩＯＮ」；「ＧｎＲＥＱＵＥＳＴ」、「ＧｎＲＥＳＰＯＮＳＥ」、「ＧｎＣＯＭＭＡＮＤ」、「ＧｎＣＯＮＦＩＧ」のいずれかに相当する第２の分類テキスト文字列識別子；および「ＳｐＫＥＥＰＡＬＩＶＥ」、「ＳｐＳＨＵＴＤＯＷＮ」、「ＳｐＫＥＥＰＡＬＩＶＥＯＮ」または「ＳｐＫＥＥＰＡＬＩＶＥＯＦＦ」のいずれかに相当する第３の分類テキスト文字列識別子によって表されるサブフィールド値を含むメッセージ識別子フィールド３０２を有する。 【０１０１】 第１の分類識別子ＦｍＣＯＮＮＥＣＴＩＯＮは、ネットワーク構成要素間の接続に関連した特定のモジュールを識別する。第２の分類識別子は、メッセージの関連したＭＯＭＰタイプを識別する。第３の分類識別子値は、キープアライブメッセージ３９０の特定の機能を表示する。 【０１０２】 第３の分類が、「ＳｐＫＥＥＰＡＬＩＶＥ」に相当する場合、それは、受信するネットワーク構成要素１４０ｎ、１１０ｃに対して、送信するネットワーク構成要素１１０ｃ、１４０ｎは、ネットワーク構成要素１１０ｃ、１４０ｎ間の特定の接続上の通信に対して動作中（活動中）であることを表示する。第３の分類識別子が「ＳｐＳＨＵＴＤＯＷＮ」に相当する場合、それは、受信するネットワーク構成要素１４０ｎ、１１０ｃに対して、送信するネットワーク構成要素１１０ｃ、１４０ｎがネットワーク構成要素１１０ｃ、１４０ｎ間の接続のシャットダウンを開始していることを表示する。 【０１０３】 第３の分類が「ＳｐＫＥＥＰＡＬＩＶＥＯＮ」に相当する場合、それは、受信するネットワーク構成要素１４０ｎ、１１０ｃに対して、送信するネットワーク構成要素１１０ｃ、１４０ｎが、受信するネットワーク構成要素が周期的にキープアライブメッセージ３９０に伝送することをリクエストしていることを表示する。第３の分類が「ＳｐＫＥＥＰＡＬＩＶＥＯＦＦ」に相当する場合、それは、受信するネットワーク構成要素１４０ｎ、１１０ｃに対して、送信するネットワーク構成要素１１０ｃ、１４０ｎが、受信するネットワーク構成要素が、キープアライブメッセージ３９０を周期的に伝送しないことをリクエストしていることを表示する。」 「【図３Ｆ】 ［図：0001416530000012.jpg］ 」 ７ 甲７について 甲７（特開２０１８－１６６９３５号公報）には、以下の記載がある。 「【０００１】 本発明は、対象の運動を効果的に管理するシステムに関し、特に心臓リハビリテーション用システムに関する。」 「【００６２】 運動開始前の安静時にノーマルパターン（洞調律）が認識された場合、運動を開始する。本発明のシステムでは、パターン認識部が、負荷中の心電図パターンをさらに認識する。本発明のシステムの好ましい実施形態において、負荷中の心電図波形において、パターン１～１１の１つまたは複数が認識された場合、制御部が負荷装置の負荷を低減し、より好ましい実施形態においては制御部が負荷装置の負荷を停止する（すなわち、無負荷にする）。例えば、医療機関では心疾患入院患者の心電図波形にパターン７が出現しても、緊急対応を要さないため、アラームを鳴らさないことが多い。しかしながら、本発明の本実施形態、および以下に記載する負荷中にパターン７の出現によって負荷を低減または停止する実施形態においては、安全性の観点から、安静時に出現しなかったパターン７の負荷中の出現により、制御部が負荷装置の負荷を低減または停止する。 【００６３】 運動開始前の安静時にパターン１が認識された場合、運動を開始する。本発明のシステムの好ましい実施形態において、負荷中の心電図波形において、安静時に認識されたパターン１と比較して頻度の増加したパターン１が認識された場合、および／またはパターン２～１１の１つまたは複数が認識された場合、制御部が負荷装置の負荷を低減し、より好ましい実施形態においては制御部が負荷装置の負荷を停止する。パターン１の心室性期外収縮において、幅広のＱＲＳ波が出現する頻度が増加することは、パターン５の心室頻拍につながるリスクを示唆しているからである。安全性に配慮すると、負荷中にパターン１が認識された場合にはアラームを鳴らしたり、負荷を低減または停止しようと考えるのが一般的であり、当該分野の常識である。しかしながら、それでは適切な負荷をかけることができず、結局のところ効果的な運動（例えば、リハビリテーション）を実施することができなくなってしまう。本発明の本実施形態では、負荷中にパターン１が認識されたとしても、安静時にもパターン１が認識されている場合には負荷を継続し、それによって過度に負荷を低減または停止することがない点に留意されたい。 【００６４】 運動開始前の安静時にパターン７が認識された場合、運動を開始する。本発明のシステムの好ましい実施形態において、負荷中の心電図波形において、パターン１～６、パターン８～１１の１つまたは複数が認識された場合、制御部が負荷装置の負荷を低減し、より好ましい実施形態においては制御部が負荷装置の負荷を停止する。 【００６５】 以下に、本発明における、心電図波形パターンのパターン認識と制御部による負荷の制御との関係を表に示す。各数字は波形パターンの種類を示す。なお、本発明のシステムは、以下の表１に示されるパターンに基づく負荷調整の全てを備えている必要はない。好ましい実施形態において、本発明のシステムは、以下の表１に示されるパターンに基づく負荷調整の１つまたは任意の組み合わせを含む。特に好ましい実施形態においては、本発明のシステムは、以下の表１に示されるパターンに基づく負荷調整の全てを制御部が行う。 【００６６】 【表1】 ［図：0001416530000013.jpg］ 【００６７】 表１における「安静時」とは、心臓に負荷がかかっていない任意の時点をいうが、運動（例えば、リハビリテーション）における負荷運動の開始前の安静時であることが好ましい。好ましい実施形態においては、表１の「安静時」は、負荷運動の開始前（例えば、負荷運動の開始前約２０分以内、負荷運動の開始前約１０分以内、または負荷運動の開始前約５分以内）であり得る。負荷運動の開始前の安静時心電図データを使用することによって、リハビリテーション開始前ではない時点（例えば、１日以上前）での安静時心電図データを安静時心電図データとして使用する場合と比較して、リハビリテーションでの負荷の心臓への影響をより直接的に検出し、それに基づいて負荷の制御を行うことができる。このことは、本発明の目的である安全性の向上と効果的な負荷の両立にさらに有利であり得る。好ましい実施形態において、本発明における「安静時」は、運動開始前約２０分以内であり、より好ましくは運動開始前約１０分以内であり、さらに好ましくは運動開始前約５分以内である。」 ８ 甲８について 甲８（特開２０２０－０５７０８２号公報）には、以下の記載がある。 「【０００１】 本発明は、リハビリテーション特に遠隔心臓リハビリテーションを支援するリハビリ支援システム、ユーザ機器および情報端末装置に関する。」 「【０１３８】 具体的には、システム管理サーバ１００のプロセッサ部１０１は、上述した表に示される判断基準に従って、認識したパターンに基づいてリハビリ運動の続行が可能であるか否かの判定を行い、その判定結果に基づいて、通信制御部１０３によりユーザ機器３００の負荷停止を行う（ステップＳ８０１）。同時に、その判定結果は、通信制御部１０３により情報端末装置２００に送信される。」 ９ 甲９について 甲９（特開２００６－２７７５８５号公報）には、以下の記載がある。 「【請求項１】 サーバ装置と該サーバ装置の特定のモードにログイン可能な端末装置とを備えたサーバシステムであって、 前記端末装置は、前記サーバ装置の特定のモードにログインしている状態で、サーバ装置に向けて定期的に接続確認信号を発信する発信手段を備え、 前記サーバ装置は、前記端末装置から発信される前記接続確認信号の有無を監視する監視手段と、前記監視手段により、前記接続確認信号が一定時間検出されなかった場合には、強制ログアウト処理を行う制御手段と、 を備えたことを特徴とするサーバシステム。」 「【請求項６】 特定のモードにログインしている端末装置から定期的に発信される接続確認信号の有無を監視する監視手段と、 前記監視手段により、前記接続確認信号が一定時間検出されなかった場合には、強制ログアウト処理を行う制御手段と、 を備えたことを特徴とするサーバ装置。」 「【００１０】 上記目的は、下記の手段によって達成される。 （１）サーバ装置と該サーバ装置の特定のモードにログイン可能な端末装置とを備えたサーバシステムであって、前記端末装置は、前記サーバ装置の特定のモードにログインしている状態で、サーバ装置に向けて定期的に接続確認信号を発信する発信手段を備え、前記サーバ装置は、前記端末装置から発信される前記接続確認信号の有無を監視する監視手段と、前記監視手段により、前記接続確認信号が一定時間検出されなかった場合には、強制ログアウト処理を行う制御手段と、を備えたことを特徴とするサーバシステム。 （２）サーバ装置は画像形成装置であり、端末装置は前記画像形成装置の情報を表示する表示手段を備えている前項１に記載のサーバシステム。 （３）サーバ装置は、前記接続確認信号発信用の制御プログラムを、ログインした端末装置に送信するプログラム送信手段を備え、前記端末装置は、前記制御プログラムを実行することにより前記接続確認信号を発信する前項１または２に記載のサーバシステム。 （４）サーバ装置は、サーバ装置側の状況に応じて、端末装置から発信される接続確認信号の発信周期を変更させる前項３に記載のサーバシステム。 （５）サーバ装置は、端末装置がログインしたモードに応じて、端末装置から発信される接続確認信号の発信周期を変更させる前項３に記載のサーバシステム。 （６）特定のモードにログインしている端末装置から定期的に発信される接続確認信号の有無を監視する監視手段と、前記監視手段により、前記接続確認信号が一定時間検出されなかった場合には、強制ログアウト処理を行う制御手段と、を備えたことを特徴とするサーバ装置。 （７）画像形成装置からなり、ログインしてきた端末装置に装置情報を提供可能な前項６に記載のサーバ装置。 （８）前記接続確認信号発信用の制御プログラムを、ログインした端末装置に送信するプログラム送信手段を備えている前項６または７に記載のサーバ装置。 （９）自装置の状況に応じて、端末装置から発信される接続確認信号の発信周期を変更させる前項８に記載のサーバ装置。 （１０）端末装置がログインしたモードに応じて、端末装置から発信される接続確認信号の発信周期を変更させる前項８に記載のサーバ装置。 （１１）サーバ装置の特定のモードにログイン可能な端末装置であって、前記サーバ装置の特定のモードにログインしている状態で、サーバ装置に向けて定期的に接続確認信号を発信する発信手段を備えていることを特徴とする端末装置。 （１２）サーバ装置の特定のモードにログインしている状態で、サーバ装置から送信される前記接続確認信号発信用の制御プログラムを受信する受信手段を備え、前記発信手段は、前記制御プログラムを実行することにより前記接続確認信号を発信する前項１１に記載の端末装置。 （１３）発信手段は、サーバ装置側の状況に応じて接続確認信号の発信周期を変更する前項１２に記載の端末装置。 （１４）発信手段は、サーバ装置にログインしたモードに応じて接続確認信号の発信周期を変更する前項１２に記載の端末装置」 １０ 甲１０について 甲１０（特許第４２８２２８３号公報）には、以下の記載がある。 「【請求項１】 機能キーを操作して画像形成するための各種設定を行うときに、該機能キーに割り当てられた機能の説明を音声ガイダンスする画像形成装置において、前記機能キーが第１の所定時間押下された時点で、該機能キーに割り当てられた機能の説明の音声ガイダンスを行い、該機能キーが押されたまま前記第１の所定時間より長い第２の所定時間を超えると該機能キーの選択を確定することを特徴とする画像形成装置。」 「【請求項３】 画像形成装置の機能キーを操作して画像形成するための各種設定を行うときに、該機能キーに割り当てられた機能の説明を音声ガイダンスする処理をコンピュータ上で実行させるプログラムであって、前記機能キーが第１の所定時間押下された時点で、該機能キーに割り当てられた機能の説明の音声ガイダンスを行い、該機能キーが押されたまま前記第１の所定時間より長い第２の所定時間を超えると該機能キーの選択を確定する処理をコンピュータ上で実行させることを特徴とするプログラム。」 「【００５０】 Ｅ．ＭＦＰの動作 このように構成された本ＭＦＰにおける動作を、コピー機能の操作を例にして説明する。 図８は、コピー機能の操作に対する処理手順を示すフローチャートである。 まず、モード切り替えキーが長時間（３秒以上）押された場合（ステップＳ１のＹＥＳ）、現在の設定モードを切り替え（ステップＳ２）、次の操作指示を処理するためにステップＳ１へ戻る。 「通常の操作モード」から「学習モード」へ切り替える場合、モード切り替えキーを押し、ヘッドフォンとマイクロフォンを備えたヘッドセットをＭＦＰへ接続すると、ヘッドフォンから「学習モードに入りました。・・・・」という音声ガイドがなされる。 一方、現在のモードが「学習モード」であれば、「通常の操作モード」へ切り替える。 【００５１】 次に、方向移動キー（上下左右）が押された場合（ステップＳ３のＹＥＳ）、キーの押された状態が短時間であればキーの音声ガイドを行って（ステップＳ４）、次の操作指示を処理するためにステップＳ１へ戻る。 一方、キーが長時間（２秒以上）押された状態であれば、階層メニューの上下移動や同階層の隣接項目へ移動し、その移動先を音声ガイドし（ステップＳ４）、次の操作指示を処理するためにステップＳ１へ戻る。 操作制御部３２０は、階層メニュー上の移動先を現在位置として記録することにより、階層メニューのどこにいるかを管理する。 【００５２】 次に、「トップへ戻る（「１」）」キーが押された場合（ステップＳ５のＹＥＳ）、キーの押された状態が短時間であればキーの音声ガイドを行って（ステップＳ６）、次の操作指示を処理するためにステップＳ１へ戻る。 一方、キーが長時間（２秒以上）押された状態であれば、最上位階層の１番目のメニューにある操作項目（「部数」）に移動して、その移動先を音声ガイドし（ステップＳ６）、次の操作指示を処理するためにステップＳ１へ戻る。 操作制御部３２０は、最上位階層の１番目のメニューにある操作項目になるように現在位置を管理する。 【００５３】 次に、「設定（「＃」）」キーが押された場合（ステップＳ７のＹＥＳ）、キーの押された状態が短時間であればキーの音声ガイドを行って（ステップＳ８）、次の操作指示を処理するためにステップＳ１へ戻る。 一方、キーが長時間（２秒以上）押された状態であれば、設定キーが押される前に選択された現在位置の設定項目の選択を確定し、その状況を音声ガイドにてヘッドフォンへ出力し（ステップＳ８）、次の操作指示を処理するためにステップＳ１へ戻る。 【００５４】 次に、各設定項目に設定が完了して「スタート」キーが押下された場合（ステップＳ９のＹＥＳ）、キーの押された状態が短時間であれば、実際のコピーは行わず、それまでに設定された項目の内容が音声ガイダンスされ（ステップＳ１０）、次の操作指示を処理するためにステップＳ１へ戻る。 一方、キーが長時間（２秒以上）押された状態であれば、コピーのために設定された内容を音声ガイドにてヘッドフォンへ出力し、設定内容をＭＦＰへ設定するとともに実際のコピーを実行し（ステップＳ１０）、次の操作指示を処理するためにステップＳ１へ戻る。 【００５５】 一方、上述のキー（モード切り替え、方向移動、トップへ戻る、設定、スタート）以外であれば（ステップＳ９のＮＯ）、そのキーに対応する機能を実行させて（ステップＳ１１）、次の操作指示を処理するためにステップＳ１へ戻る。」 １１ 甲１１について 甲１１（特開２００６－２６８５４２号公報）には、以下の記載がある。 「【請求項５】 ネットワークに接続された１または複数の印刷装置に対応して該印刷装置における印刷許可の認証を行う認証装置を設け、クライアント装置からの印刷指示に係わる印刷ジョブをサーバ装置に蓄積し、前記認証装置の認証に基づき前記サーバ装置に蓄積された印刷ジョブを対応する印刷装置で実行する印刷システムにおいて、 前記サーバ装置に蓄積された印刷ジョブを監視する印刷ジョブ監視手段と、 前記印刷ジョブ監視手段による監視に基づき前記サーバ装置に蓄積された印刷ジョブの中に予め設定された第１の時間以上実行されない印刷ジョブがある場合は、その旨を報知する報知手段と、 前記印刷ジョブ監視手段による監視に基づき前記サーバに蓄積された印刷ジョブの中に予め設定された前記第１の時間より長い第２の時間以上実行されない印刷ジョブがある場合は、該印刷ジョブを自動削除する削除手段と を具備することを特徴とする印刷システム。」 「【請求項９】 ネットワークに接続された１または複数の印刷装置に対応して該印刷装置における印刷許可の認証を行う認証装置を設け、クライアント装置からの印刷指示に係わる印刷ジョブをサーバ装置に蓄積し、前記認証装置の認証に基づき前記サーバ装置に蓄積された印刷ジョブを対応する印刷装置で実行する印刷システムの制御方法において、 前記サーバ装置に蓄積された印刷ジョブを印刷ジョブ監視手段により監視し、 前記印刷ジョブ監視手段による監視に基づき前記サーバ装置に蓄積された印刷ジョブの中に予め設定された第１の時間以上実行されない印刷ジョブがある場合は、その旨を報知手段により報知し、 前記印刷ジョブ監視手段による監視に基づき前記サーバ装置に蓄積された印刷ジョブの中に予め設定された前記第１の時間より長い第２の時間以上実行されない印刷ジョブがある場合は、該印刷ジョブを削除手段により自動削除する ことを特徴とする印刷システムの制御方法。」 「【００１７】 また、請求項５の発明は、ネットワークに接続された１または複数の印刷装置に対応して該印刷装置における印刷許可の認証を行う認証装置を設け、クライアント装置からの印刷指示に係わる印刷ジョブをサーバ装置に蓄積し、前記認証装置の認証に基づき前記サーバ装置に蓄積された印刷ジョブを対応する印刷装置で実行する印刷システムにおいて、前記サーバ装置に蓄積された印刷ジョブを監視する印刷ジョブ監視手段と、前記印刷ジョブ監視手段による監視に基づき前記サーバ装置に蓄積された印刷ジョブの中に予め設定された第１の時間以上実行されない印刷ジョブがある場合は、その旨を報知する報知手段と、前記印刷ジョブ監視手段による監視に基づき前記サーバ装置に蓄積された印刷ジョブの中に予め設定された前記第１の時間より長い第２の時間以上実行されない印刷ジョブがある場合は、該印刷ジョブを自動削除する削除手段とを具備することを特徴とする。」 １２ 甲１２について 甲１２（特許第４６６５０４０号公報）には、以下の記載がある。 「【請求項１】 計算機であって、 ローカルディスクと、 メモリと、 前記計算機内で動作する仮想マシンモニタと、 仮想マシンモニタ上で稼働し、クライアント用仮想マシンと前記クライアント用仮想マシンからアクセス可能な内部ファイルサーバが稼働するファイルサーバ仮想マシンとを含む複数の仮想マシンと、 前記ローカルディスクの一部と前記メモリの一部とを管理し、前記複数の仮想マシンの起動を制御する仮想マシンマネージャと、 ネットワークを介して外部ファイルサーバが稼働する外部サーバと通信ができるか否かを監視する監視手段と、 前記監視手段が通信できないと判断するまでは前記クライアント用仮想マシンからのファイルのアクセスを前記外部サーバまたは前記内部ファイルサーバに対して行い、前記監視手段が通信できると判断してから第１の時間の間に通信できないと判断した場合に、前記仮想マシンマネージャが管理する前記ローカルディスクの一部またはメモリの一部に対して前記クライアント用仮想マシンからのファイルのライトアクセスを行うアクセス制御手段と、 前記監視手段が前記監視手段が通信できると判断してから前記外部サーバと前記第１の時間より長い第２の時間の間に通信できないと判断した場合に、前記ローカルディスクの一部またはメモリの一部にライトアクセスされたファイルを削除するファイル削除手段と を具備することを特徴とする計算機。」 「【請求項６】 ローカルディスクと、メモリと、仮想マシンモニタ上で稼働する、ユーザ用仮想マシンおよび前記クライアント用仮想マシンからアクセス可能な内部ファイルサーバが稼働するファイルサーバ仮想マシンを含む複数の仮想マシンと、前記ローカルディスクの一部と前記メモリの一部とを管理し、前記複数の仮想マシンの起動を制御する仮想マシンマネージャとを有する計算機のアクセス制御方法であって、 前記複数の仮想マシンの一つはクライアント用仮想マシンであり、 前記複数の仮想マシンの一つは前記クライアント用仮想マシンからアクセス可能な内部ファイルサーバが稼働するファイルサーバ仮想マシンであって、 前記アクセス制御方法は、 ネットワークを介して外部ファイルサーバが稼働する外部サーバと通信ができるか否かを監視し、 前記外部サーバと通信できないと判断するまでは前記外部ファイルサーバまたは前記内部ファイルサーバ内のファイルにアクセスし、 前記外部サーバと通信できると判断してから第１の時間の間に通信できないと判断した場合に前記仮想マシンマネージャが管理する前記ローカルディスクの一部または前記メモリの一部に対して前記クライアント用仮想マシンからのファイルのライトアクセスを行い、 前記外部サーバと通信できると判断してから前記第１の時間より長い第２の時間の間に通信できないと判断した場合に、前記ローカルディスクの一部または前記メモリの一部にライトアクセスされたファイルを削除する ことを特徴とするアクセス制御方法。」 「【００２５】 動作モード設定が管理モードの場合、監視モニタ３０１はアクティブ状態に遷移する。アクティブ状態では、監視モニタ３０１は、時間Ｔ１でタイムアウトするタイマを設定する。 【００２６】 アクティブ状態において、監視モニタ３０１は、外部ファイルサーバとの間で定期的にキープアライブ（KeepAlive）を送受信する。外部サーバからの応答が、ある時間Ｔ１の間の存在しない場合は、監視モニタ３０１は、ウエイト（WAIT）状態に遷移する。 【００２７】 ウエイト状態の場合、外部サーバとの通信が一時的にできないことを考慮し、監視モニタ３０１は、ブロックデータリマッピング２４２による書き込み先をローカルディスクに変更する。また、時間Ｔ２×Ｎ１でタイムアウトし、時間Ｔ２毎に時間の経過を監視モニタ３０１に通知するタイマを設定する。 【００２８】 ウエイト状態において、外部サーバからの応答が有ると、監視モニタ３０１は、時間Ｔ２×Ｎ１でタイムアウトするタイマをリセットし、アクティブ状態に遷移する。 【００２９】 ウエイト状態の間は、コンピュータ１０での作業を中断することなく使用は可能である。ただし、設定された時間Ｔ２毎にクライアント用仮想マシン２００Ａ上のユーザインタフェースに警告表示またはコンピュータ１０に設けられているＬＥＤを点滅させて警告表示する。 【００３０】 警告しても外部サーバからの応答がなく、最後に外部ファイルサーバの応答を受けてから時間Ｔ２×Ｎ１時間が経過すると、監視モニタ３０１は仮想マシンモニタ２３０に対してクライアント用仮想マシン２００Ａのロックを指示する。仮想マシンモニタ２３０は、ＣＰＵスケジューリング、メモリアロケート、Ｉ／Ｏ制御を一時的に停止し、クライアント用仮想マシン２００Ａに対してサスペンド（SuspendtoRAM）を要求する。また、監視モニタ３０１は、時間Ｔ３でタイムアウトするタイマを設定する。 【００３１】 監視モニタ３０１はロック（LOCK）状態に遷移する。ロック状態では、システム全体の電源はオン状態であり、仮想マシンモニタ２３０および、仮想サーバ３００は動作している。クライアント用仮想マシン２００Ａは休止状態であり、クライアント用仮想マシン２００Ａが使用しているメモリ内容をローカルディスクの仮想マシンモニタ２３０が管理する領域に保存する。 【００３２】 ロック状態において、ユーザがコンピュータのレジューム処理の要求を行ったら、クライアント用仮想マシン２００Ａは先ほど保存したメモリ内容をロードし、クライアント用仮想マシン２００Ａをレジュームする。そして、監視モニタ３０１はウエイト状態に戻る。また、ウエイト状態に戻る際、監視モニタ３０１は時間Ｔ２×Ｎ１でタイムアウトするタイマをリセットし、時間Ｔ１でタイムアウトするタイマを設定する。 【００３３】 サスペンドした状態のロック状態からアクティブ状態にならない場合、時間Ｔ３が経過すると、監視モニタ３０１は、先ほどローカルディスクに保存したメモリ内容とブロックデータリマッピング２４２によって保存されたブロックデータを削除するよう、ブロックデータリマッピング２４２に指示する。ブロックデータリマッピング２４２がメモリ内容とブロックデータを削除する間、監視モニタ３０１はパージ（PURGE）状態に遷移する。ブロックデータリマッピング２４２がメモリ内容およびブロックデータを削除すると、監視モニタ３０１は、次回起動時にモバイルモードでクライアント用仮想マシン２００Ａを起動することを示す起動モード設定を監視モニタ３０１内に記録してからシステム全体をシャットダウンして、イニシャル（INIT）状態に遷移する。」 第５ 当審の判断 １ 本件発明１について （１）対比 本件発明１と甲１発明１とを対比する。 ア 「A 遠隔心臓リハビリテーションを支援するリハビリテーション支援システム」、「B 前記遠隔心臓リハビリテーションの支援業務を行うためのサーバ装置」について 甲１発明１の「遠隔心臓リハビリテーションのためMedBikeシステム」は、「MedBikeサーバ、患者PC、アンドロイドタブレット、及び臨床医PCとを備え、患者PC、アンドロイドタブレット、臨床医PCは、それぞれネットワークを介してMedBikeサーバと接続されており、患者PCは、WiFiルータを介してMedBikeに含まれる静的バイクと接続されており」、「アンドロイドタブレットは、バイタルサインセンサー(ECG、オキシメーター、血圧計）の収集を行い、患者がトレーニング中に達成すべき最小・最大ケイデンスとパワー範囲を指定するための臨床医の情報を受け取るものであり、臨床医側では、患者のすべての情報を表示し、分析することができ」るものである。 してみると、甲１発明１の「遠隔心臓リハビリテーションのためMedBikeシステム」は、患者がMedBikeを用いてトレーニングしている際に、臨床医が、「MedBikeサーバ」を介して、達成すべき最小・最大ケイデンスとパワー範囲を指示したり、バイタルセンサーによって収集された患者の状態を監視することができるものであるから、これらの指示や監視を行うことによって患者の遠隔心臓リハビリテーションを支援しているといえる。 よって、甲１発明１の「遠隔心臓リハビリテーションのためMedBikeシステム」は、本件発明１の「遠隔心臓リハビリテーションを支援するリハビリテーション支援システム」に相当し、甲１発明１の「MedBikeサーバ」は、臨床医と患者の間のデータの送受信を行うものであってリハビリテーションの実施を支援しているといえるから、本件発明１の「前記遠隔心臓リハビリテーションの支援業務を行うためのサーバ装置」に相当する。 イ 「C 医療関係者が使用し、第１通信ネットワークを介して前記サーバ装置と通信する医療端末装置」について 甲１発明１の「臨床医PC」は、医療関係者である臨床医が使用する医療端末装置であり、「ネットワークを介してMedBikeサーバと接続されて」いるところ、この「臨床医PC」と「MedBikeサーバ」との間のネットワークは「第１通信ネットワーク」といえる。 よって、上記アの検討も踏まえると、甲１発明１の「臨床医PC」は、本件発明１の「医療関係者が使用し、第１通信ネットワークを介して前記サーバ装置と通信する医療端末装置」に相当する。 ウ 「D 前記医療関係者の監視対象者であって前記遠隔心臓リハビリテーションを受ける患者が使用し、前記第１通信ネットワークと異なる第２通信ネットワークを介して前記サーバ装置と通信し、前記患者に負荷を提供するエルゴメータと接続される患者端末装置」について 甲１発明１の「患者PC」及び「アンドロイドタブレット」は「互いにデータの送受信を行う」ものであって、医療関係者である臨床医の監視対象者であって遠隔心臓リハビリテーションを受ける患者が使用するものであるから、甲１発明１の「患者PC」及び「アンドロイドタブレット」は、併せて、「前記医療関係者の監視対象者であって前記遠隔心臓リハビリテーションを受ける患者が使用」する「患者端末装置」であるといえる。 そして、「患者PC」及び「アンドロイドタブレット」は、「ネットワークを介してMedBikeサーバと接続されて」いるところ、この「患者PC」及び「アンドロイドタブレット」と、「MedBikeサーバ」との間のネットワークは、上記イで検討した「臨床医PC」と「MedBikeサーバ」との間の「第１通信ネットワーク」とは、その接続関係からして異なるネットワークであるから、「第１通信ネットワークと異なる第２通信ネットワーク」であるといえる。 さらに、甲１発明１では、患者がMedBikeを用いてトレーニングしている際に、臨床医が、「MedBikeサーバ」を介して、達成すべき最小・最大ケイデンスとパワー範囲を指示したり、バイタルセンサー(ECG、オキシメーター、血圧計）によって収集された患者の状態を監視することができるものであるから、甲１発明１の「MedBike」は、本件発明１の「患者に負荷を提供するエルゴメータ」に相当する。 そして、甲１発明１では、「患者PCは、WiFiルータを介してMedBikeに含まれる静的バイクと接続されて」いるから、「患者PCは、患者に負荷を提供するエルゴメータと接続され」ているといえる。 よって、上記ア、イの検討も踏まえると、甲１発明１の「患者PC」、及び「アンドロイドタブレット」からなる構成は、本件発明１の「前記医療関係者の監視対象者であって前記遠隔心臓リハビリテーションを受ける患者が使用し、前記第１通信ネットワークと異なる第２通信ネットワークを介して前記サーバ装置と通信し、前記患者に負荷を提供するエルゴメータと接続される患者端末装置」に相当するといえる。 エ 「E 前記遠隔心臓リハビリテーションの実施中、前記サーバ装置を介した前記患者端末装置から前記医療端末装置への送信はリアルタイムで実行され」について 甲１発明１は、「患者PC、アンドロイドタブレット、臨床医PCは、それぞれネットワークを介してMedBikeサーバと接続されて」いるものであって、「WebRTCを使用して臨床医との安全な音声／ビデオ接続を確立し」、「患者がトレーニング中に達成すべき最小・最大ケイデンスとパワー範囲を指定するための臨床医の情報を受け取るものであり、臨床医側では、患者のすべての情報を表示し、分析することができ、セッションは、患者と臨床医の認証情報をMedBikeサーバと確立することから始まる」ものである。ここで、甲１発明１は、「患者が遠隔心臓リハビリテーションの実施中、MedBikeサーバは、前記患者PCと前記アンドロイドタブレットのそれぞれとデータの送受信を行うとともに、前記臨床医PCともデータの送受信を行う」ものであり、これらの「データの送受信」は当該セッションにおいて行われることは明らかである。 そして、甲１発明１において、MedBikeサーバを介した患者PC、及びアンドロイドタブレットと、臨床医PCとの間の通信は、WebRTCを使用して安全な音声／ビデオ接続を確立するものであって、セッションは患者と臨床医の認証情報をMedBikeサーバと確立することから始まるものであるから、リアルタイムで行われていることは明らかである。 してみると、甲１発明１は、本件発明１と同様に「前記遠隔心臓リハビリテーションの実施中、前記サーバ装置を介した前記患者端末装置から前記医療端末装置への送信はリアルタイムで実行される」ものである。 オ 一致点及び相違点 上記ア～エを踏まえると、本件発明１と甲１発明１とは、以下の一致点、及び相違点を有する。 ［一致点］ 遠隔心臓リハビリテーションを支援するリハビリテーション支援システムであって、 前記遠隔心臓リハビリテーションの支援業務を行うためのサーバ装置と、 医療関係者が使用し、第１通信ネットワークを介して前記サーバ装置と通信する医療端末装置と、 前記医療関係者の監視対象者であって前記遠隔心臓リハビリテーションを受ける患者が使用し、前記第１通信ネットワークと異なる第２通信ネットワークを介して前記サーバ装置と通信し、前記患者に負荷を提供するエルゴメータと接続される患者端末装置とを備え、 前記遠隔心臓リハビリテーションの実施中、前記サーバ装置を介した前記患者端末装置から前記医療端末装置への送信はリアルタイムで実行される、 リハビリテーション支援システム。 ［相違点１］ 本件発明１は、「前記サーバ装置は、前記遠隔心臓リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備える」のに対して、甲１発明１のサーバ装置は、そのような「キープアライブ信号送受信部」を備えていない点。 （２）相違点１についての検討 ア 判断 上記第４の２～６によれば、甲２～甲６には、いずれも医療分野において装置間でキープアライブ信号を送受信することが開示されており、医療分野において装置間でキープアライブ信号を送受信することは、本願出願時における周知技術（周知技術１）であったと認められる。 しかしながら、甲２には、デバイス104が動作すると、コントローラ/ハブ102が監視することができるビーコンを繰り返し送信することが記載されているが（【００２９】）、それに対する応答信号をコントローラ/ハブ102が送信することは記載されておらず、また、コントローラ/ハブ102とは別にサーバ108が存在するのであるから（【００１９】、【図１】）、そもそもコントローラ/ハブ102はサーバ装置ではない。 また、甲３には、インターフェイス装置122がファーストパーティ医療装置(106、110、および118)を周期的にポーリングすること（【００３０】、【００３２】、【００４８】、【図４】）、サードパーティ装置120が、ハートビートポートを介して、通信412および414を行って、接続の成立を確保することが記載されているが（【００４３】、【図４】）、ファーストパーティ医療装置(106、110、および118)及びサードパーティ装置120がインターフェイス装置122にポーリングし、それに対する応答信号をインターフェイス装置122が送信することは記載されていない。 また、甲４、甲５には、種々の電子医療またはフィットネスデバイス102、104、108からサービスプラットフォームサーバにデータ送信する際のゲートウェイとして動作するワイヤレス通信ハブデバイス112において、ワイヤレス通信ハブデバイス112の中に存在するメモリ302に、キープアライブpingがどの程度頻繁にサービスプラットフォームサーバへ送信されるべきかを示すデータ呼周期パラメータ356を記憶することが記載されているが（【００２４】、【００５８】、【図１Ａ】、【図３Ｅ】）、電子医療またはフィットネスデバイス102、104、108からからキープアライブpingを送信し、それに対する応答信号をサービスプラットフォームサーバが送信することは記載されていない。 また、甲６には、ネットワーク構成要素１１０ｃ、１４０ｎ間でキープアライブ通信３９２、３９４を送信することが記載されているが（【００９８】、【００９９】、【図３F】）、医療端末装置と患者端末装置からサーバ装置にキープアライブ信号を送信し、それに対する応答信号をサーバ装置が送信することは記載されていない。 すなわち、甲２～甲６には、医療分野において装置間でキープアライブ信号を送受信するという周知技術１は開示されているものの、医療端末装置と患者端末装置からサーバ装置にキープアライブ信号を送信し、それに対する応答信号をサーバが送信する技術は開示されていない。また、甲７～甲１２にも、そのような技術は開示されていない。 よって、甲１発明１に周知技術１（甲２～甲６）を適用しても、さらに甲７～甲１２に開示される技術を鑑みても、「前記サーバ装置は、前記遠隔心臓リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備える」という上記相違点１に係る構成に到達しないから、本件発明１は当業者が容易に想到し得たものとはいえない。 イ 異議申立人の主張について 異議申立人は、キープアライブ技術そのものは本件特許出願時に周知の技術であり、また、本件特許発明のような医療分野においても、サーバと医療デバイスや患者のフィットネスデバイスとの間でキープアライブ信号を送受信することは、本件特許出願時における周知技術１（甲２～甲６）であるから、当業者であれば、甲１発明に周知技術１（甲２～甲６）を適用して、サーバ装置が、遠隔心臓リハビリテーションの実施中、医療端末装置および患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信にする応答信号を送信元のすべてに対して送信するキープアライブ信号送受信部を備えるように構成することは容易になし得たものである旨主張する。 しかしながら、上記アで検討したとおり、甲２～甲６は、医療端末装置と患者端末装置からサーバ装置にキープアライブ信号を送信し、それに対する応答信号をサーバ装置が送信する技術を開示するものではないから、甲１発明１に周知技術１（甲２～甲６）を適用しても、上記相違点１に係る構成に到達するものではなく、本件発明１は当業者が容易になし得たものであるとはいえない。 よって、異議申立人の上記主張は採用できない。 （３）まとめ 以上のとおりであるから、本件発明１は、甲１発明１、及び甲２～甲６に記載の周知技術に基づいて、当業者が容易に発明をすることができたものとはいえない。 ２ 本件発明２、３について （１）対比と判断 本件発明２、３は、「前記サーバ装置は、前記リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備え」るものであり、これは、本件発明１の構成要件Fにおける「遠隔心臓リハビリーテーションの実施中」との記載から「遠隔心臓」なる限定を外して、「リハビリテーションの実施中」と上位概念化したものである。 してみると、本件発明２、３と甲１発明１との間には、少なくとも、本件発明２、３は「前記サーバ装置は、前記リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備え」るのに対して、甲１発明１はそのような構成を備えていないという上記相違点１と同様な相違点（以下「相違点１’」という。）を有するものであり、かかる相違点１’は、上記１で示した理由と同様の理由により、当業者が容易に想到し得たものではない。 よって、本件発明２、３についても、本件発明１と同様な理由により、当業者が容易に発明をすることができたものとはいえない。 （２）異議申立人の主張について ア 本件発明２について 異議申立人は、甲１発明１は、本件発明２の「前記患者端末装置は、前記キープアライブ信号送受信部から前記応答信号を受信する患者側応答受信部と、前記患者側応答受信部が前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記機器による負荷提供の中止を指示する端末側中止指示部とを備える」構成を備えていない点で相違するところ、遠隔心臓リハビリテーションシステムにおいて、検出した心電図波形データのパターンに応じて運動負荷を停止することは本件特許出願時における周知技術２（甲７、甲８）であり、本件特許の明細書の【０００５】、【０００６】には、通信状態が悪化すると医療関係者が患者を監視できない状況に陥るため、通信状態の常時監視が課題となる旨が記載されており、そのような課題は本件特許出願前から知られていたといえるのであって、甲９に、端末装置から接続確認信号（キープアライブ信号）が一定時間検出されなかった場合に端末装置を強制ログアウトさせる（ログインを中止する）ことが記載されているように、キープアライブ信号を一定時間受信しない場合に処理（負荷提供）を中止することは、当業者が適宜設計できる程度のことである旨主張する。 しかしながら、上記（１）で検討したとおり、本件発明２と甲１発明とを対比すると上記相違点１’が存在するのであって、かかる相違点１’は周知技術１を適用しても容易に想到し得たものではないから、本件発明２は、当業者が容易に発明をすることができたものとはいえない。 さらに、異議申立人が本件発明２と甲１発明１との相違点として認定する「・・・前記応答信号を予め定められた上限期間受信しない時点で前記機器による負荷提供の中止を指示する端末側中止指示部とを備える」点について検討しても、異議申立人が主張するように、遠隔心臓リハビリテーションシステムにおいて、検出した心電図波形データのパターンに応じて運動負荷を停止することは本件特許出願時における周知技術２（甲７、甲８）であって、甲９に、端末装置から接続確認信号（キープアライブ信号）が一定時間検出されなかった場合に端末装置を強制ログアウトさせることが記載されているとしても、甲７～甲９には、キープアライブ信号に対する応答信号を予め定められた上限期間受信しない時点で機器による負荷提供の中止を指示するという上記相違点に係る構成は記載されておらず、甲２～甲６にもかかる構成は記載されていない。 してみると、甲１発明１に、甲２～甲９に開示される技術を如何に組み合わせても、異議申立人が認定する上記相違点に係る構成には到達しないものである。 加えて、キープアライブ技術を用いていない甲１発明に周知技術１（甲２～甲６）を適用することは容易であるとした上で、さらに、サーバ装置からキープアライブ信号に対する応答信号を送信するものとし、「・・・前記応答信号を予め定められた上限期間受信しない時点で前記機器による負荷提供の中止を指示する」ことは適宜設計できることであるとすることは、いわば容易の容易と判断することになるのであって、このような容易想到性の判断は許されるものではない。 よって、異議申立人の上記主張は採用できない。 イ 本件発明３について 異議申立人は、甲１発明１には、本件発明３の「前記医療端末装置は、前記キープアライブ信号送受信部から前記応答信号を受信する医療側応答受信部と、前記医療側応答受信部が前記応答信号を最後に受信してから前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力する出力部とを備え、前記サーバ装置は、さらに、前記キープアライブ信号送受信部が前記医療端末装置から前記キープアライブ信号を最後に受信してから前記キープアライブ信号を前記第１所定期間より長い第２所定期間受信しないとき、前記患者端末装置の各々に対して前記機器による負荷提供の中止を指示するサーバ側中止指示部を備える」構成を備えていない点で相違するところ、ある状態が第１所定期間継続した場合に報知（注意喚起）処理を行い、当該状態が第１所定期間よりも長い第２所定期間継続した場合に処理を確定または中止することは本件特許出願時における周知技術３（甲１０～甲１２）であるから、上記相違点に係る構成は、甲７～甲９に記載の技術並びに周知技術３（甲１０～甲１２）に基づいて、当業者が適宜設計変更できることである旨主張する。 しかしながら、上記（１）で検討したとおり、本件発明３と甲１発明１とを対比すると上記相違点１’が存在するのであって、かかる相違点１’は周知技術１を適用しても容易に想到し得たものではないから、本件発明３は、当業者が容易に発明をすることができたものとはいえない。 さらに、異議申立人が本件発明３と甲１発明１との相違点として認定する「・・・前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力する出力部とを備え、前記サーバ装置は、さらに、・・・前記キープアライブ信号を前記第１所定期間より長い第２所定期間受信しないとき、前記患者端末装置の各々に対して前記機器による負荷提供の中止を指示するサーバ側中止指示部を備える」点について検討しても、出願人が主張するように、ある状態が第１所定期間継続した場合に報知（注意喚起）処理を行い、当該状態が第１所定期間よりも長い第２所定期間継続した場合に処理を確定または中止することが本件特許出願時における周知技術３（甲１０～甲１２）であるとしても、当該周知技術３（甲１０～甲１２）は、キープアライブ信号に対する応答信号を第１所定期間受信しないとき第１所定メッセージを出力することや、キープアライブ信号を第１所定期間より長い第２所定期間受信しないとき、患者端末装置の各々に対して機器による負荷提供の中止を指示する技術を示すものではなく、このような技術は甲２～甲９にも開示されていない。 してみると、甲１発明１に、甲２～甲１２に開示される技術を如何に組み合わせても、異議申立人が認定する上記相違点にかかる構成に到達するものではない。 加えて、キープアライブ技術を用いていない甲１発明に周知技術１（甲２～甲６）を適用することは容易であるとした上で、さらに、サーバ装置からキープアライブ信号に対する応答信号を送信するものとし、「・・・前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力する出力部とを備え、前記サーバ装置は、さらに、・・・前記キープアライブ信号を前記第１所定期間より長い第２所定期間受信しないとき、前記患者端末装置の各々に対して前記機器による負荷提供の中止を指示するサーバ側中止指示部を備える」ことは当業者が適宜設計変更できることであるとすることは、いわば容易の容易と判断することになるのであって、このような容易想到性の判断は許されるものではない。 よって、異議申立人の上記主張は採用できない。 （３）まとめ 以上のとおりであるから、本件発明２は、甲１発明１、及び甲２～甲８に記載の周知技術、並びに甲９に記載された事項に基づいて、当業者が容易に発明をすることができたものとはいえないし、本件発明３は、甲１発明１、及び甲２～甲８、甲１０～甲１２に記載の周知技術、並びに甲９に記載された事項に基づいて、当業者が容易に発明をすることができたものとはいえない。 ３ 本件発明４～１２について 請求項４～１２は、請求項１、２、又は３を直接的又は間接的に引用する請求項であり、本件発明４～１２と甲１発明１とを対比すると、少なくとも上記相違点１、又は相違点１’を有するものである。 よって、本件発明４～１２は、上記１、２で示した理由と同様の理由により、甲１発明１、及び甲２～甲８、甲１０～甲１２に記載の周知技術、並びに甲９に記載された事項に基づいて、当業者が容易に発明をすることができたものとはいえない。 ４ 本件発明１３について 上記１（１）の検討も踏まえて、本件発明１３と甲１発明２とを対比すると、甲１発明２の「MedBikeサーバ」は、本件発明１３の「リハビリテーション支援サーバ」に相当するところ、本件発明１３は、「前記遠隔心臓リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部」を備えているのに対して、甲１発明２は、そのような「キープアライブ信号送受信部」を備えていないという上記相違点１に相当する相違点を少なくとも有するものである。 よって、本件発明１３は、上記１で示した理由と同様の理由により、甲１発明２、及び甲２～甲６に記載の周知技術に基づいて、当業者が容易に発明をすることができたものとはいえない。 ５ 本件発明１４、１５について 本件発明１４、１５の「リハビリテーション支援サーバ」は、「前記リハビリテーションの実施中、前記医療端末装置および前記患者端末装置を送信元とするキープアライブ信号の各々を受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部」を備えるものであり、これは、本件発明１３の「遠隔心臓リハビリーテーションの実施中」との記載から、上記２で検討した本件発明２、３と同様に、「遠隔心臓」なる限定を外して、「リハビリテーションの実施中」と上位概念化したものである。 してみると、本件発明１４、１５と甲１発明２との間には、上記２（１）で示した相違点１’に相当する相違点を少なくとも有するものである。 よって、上記２で示した理由と同様の理由により、本件発明１４は、甲１発明２、及び甲２～甲８に記載の周知技術、並びに甲９に記載された事項に基づいて、当業者が容易に発明をすることができたものとはいえないし、本件発明１５は、甲１発明２、及び甲２～甲８、甲１０～甲１２に記載の周知技術、並びに甲９に記載された事項に基づいて、当業者が容易に発明をすることができたものとはいえない。 ６ 本件発明１６について （１）対比 本件発明１６と甲１発明３とを対比すると、甲１発明３の「臨床医PC」は、本件発明１６の「医療端末装置」に相当するところ、本件発明１６と甲１発明３との間には、少なくとも以下の相違点２を有する。 ［相違点２］ 本件発明１６は、「前記サーバ装置」が「前記医療端末装置を送信元とするキープアライブ信号」を「受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備え」、「前記医療端末装置が、前記キープアライブ信号送受信部から前記応答信号を受信する」とあるように、医療端末装置が、サーバ装置にキープアライブ信号を送信し、サーバ装置から応答信号を受信するものであって、「前記応答信号を最後に受信してから前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力することを含む」ものであるのに対して、甲１発明３はそのような構成を有していない点。 （２）相違点２についての検討 ア 判断 上記１（２）アで検討したとおり、医療分野において装置間でキープアライブ信号を送受信することは周知技術１（甲２～甲６）であったと認められる。 また、上記第４の７及び８によれば、甲７及び甲８には、遠隔心臓リハビリテーションシステムにおいて、検出した心電図波形データのパターンに応じて運動負荷を停止することが記載されている。 また、上記第４の９によれば、甲９には、サーバシステムにおいて、端末装置から接続確認信号が一定時間検出されなかった場合に端末装置を強制ログアウトさせることが記載されている。 また、上記第４の１０によれば、甲１０には、画像形成装置において、機能キーが第１の所定時間押下された時点で、該機能キーに割り当てられた機能の説明の音声ガイダンスを行い、該機能キーが押されたまま前記第１の所定時間より長い第２の所定時間を超えると該機能キーの選択を確定することが記載されている。 また、上記第４の１１によれば、甲１１には、印刷システムにおいて、サーバ装置に蓄積された印刷ジョブの中に予め設定された第１の時間以上実行されない印刷ジョブがある場合は、その旨を報知し、前記第１の時間より長い第２の時間以上実行されない印刷ジョブがある場合は、該印刷ジョブを自動削除することが記載されている。 また、上記第４の１２によれば、甲１２には、計算機において、監視手段が通信できると判断してから第１の時間の間に通信できない場合には、ローカルディスクの一部またはメモリの一部に対してクライアント用仮想マシンからのファイルのライトアクセスを行い、前記第１の時間より長い第２の時間の間に通信できないと判断した場合には、前記ローカルディスクの一部またはメモリの一部にライトアクセスされたファイルを削除することが記載されている。 しかしながら、甲２～甲１２のいずれにも、キープアライブ信号に対する応答信号を所定期間受信しない場合には所定のメッセージを出力するという上記相違点２に係る構成は開示されていないから、甲１発明３に周知技術１（甲２～甲６）、さらに甲７～甲１２に示されるいずれの技術を適用しても、上記相違点２に係る構成に到達するものではない よって、本件発明１６は、甲１発明３、及び甲２～甲１２に記載された事項に基づいて、当業者が容易に発明をすることができたものとはいえない。 イ 異議申立人の主張について 異議申立人は、本件発明１６に関して、本件発明１及び本件発明３と同様に当業者が容易になし得たものである旨主張する。 しかしながら、上記アで検討したとおり、甲２～甲１２のいずれにも、キープアライブ信号に対する応答信号を所定期間受信しない場合に、所定のメッセージを出力する構成は開示されていないから、甲１発明３に甲２～１２に開示されるいずれの技術を適用しても、上記相違点２に係る構成に到達するものではない。 加えて、キープアライブ技術を用いていない甲１発明３に周知技術１（甲２～甲６）を適用することは容易であるとした上で、さらに、医療端末装置が応答信号を受信するものとし、「医療端末装置が」「前記応答信号を最後に受信してから前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力することを含む」ことは当業者が適宜設計できることであるとすることは、いわば容易の容易と判断することになるのであって、このような容易想到性の判断は許されるものではない。 よって、異議申立人の上記主張は採用できない。 （３）まとめ 以上のとおりであるから、本件発明１６は、甲１発明３、及び甲２～甲８、甲１０～甲１２に記載の周知技術、並びに甲９に記載された事項に基づいて、当業者が容易に発明をすることができたものとはいえない。 ７ 本件発明１７、１８について 本件発明１７、１８は、本件発明１６と同様に「医療端末装置の制御方法」に係る発明であって、医療端末装置が、サーバ装置にキープアライブ信号を送信し、サーバ装置から応答信号を受信するものであり、「前記応答信号を最後に受信してから前記応答信号を第１所定期間受信しないとき、第１所定メッセージを出力することを含む」ものである。 よって、本件発明１７、１８と甲１発明３との間には、少なくとも上記相違点２を有するものであるから、上記６で示した理由と同様の理由により、甲１発明３、及び甲２～甲８、甲１０～甲１２に記載の周知技術、並びに甲９に記載された事項に基づいて、当業者が容易に発明をすることができたものとはいえない。 ８ 本件発明１９について （１）対比 上記１（１）の検討も踏まえて、本件発明１９と甲１発明４とを対比すると、甲１発明４の「患者PC」及び「アンドロイドタブレット」は、いずれも本件発明１９の「患者端末装置」に相当するところ、本件発明１９と甲１発明４との間には、少なくとも以下の相違点３を有する。 ［相違点３］ 本件発明１９は、「前記サーバ装置」が「前記患者端末装置を送信元とするキープアライブ信号」を「受信し、当該受信に対する応答信号を前記送信元のすべてに対して送信するキープアライブ信号送受信部を備え」、「前記患者端末装置が、前記キープアライブ信号送受信部から前記応答信号を受信する」とあるように、患者端末装置が、サーバ装置にキープアライブ信号を送信し、サーバ装置から応答信号を受信するものであって、「前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記エルゴメータによる負荷提供の中止を指示することを含む」ものであるのに対して、甲１発明４はそのような構成を有していない点。 （２）相違点３についての検討 ア 判断 上記１（２）アで検討したとおり、医療分野において装置間でキープアライブ信号を送受信することは周知技術１（甲２～甲６）であったと認められる。 一方、甲７～甲１２に記載されている技術は、上記６（２）アで検討したとおりであって、甲７～甲１２のいずれにも、応答信号を予め定められた上限期間受信しない時点でエルゴメータによる負荷提供の中止を指示するという上記相違点３に係る構成は開示されていないから、甲１発明４に周知技術１（甲２～甲６）、さらに甲７～甲１２に示されるいずれの技術を適用しても、上記相違点３に係る構成に到達するものではない。 よって、本件発明１９は、甲１発明４、及び甲２～甲１２に記載された事項に基づいて、当業者が容易に発明をすることができたものとはいえない。 イ 異議申立人の主張について 異議申立人は、本件発明１９に関して、本件発明１及び本件発明２と同様に当業者が容易になし得たものである旨主張する。 しかしながら、上記アで検討したとおり、甲２～甲１２のいずれにも、応答信号を予め定められた上限期間受信しない時点でエルゴメータによる負荷提供の中止を指示するという上記相違点３に係る構成は開示されていないから、甲１発明４に甲２～１２に開示されるいずれの技術を適用しても、上記相違点３に係る構成に到達するものではない。 加えて、そもそもキープアライブ技術を用いていない甲１発明４に周知技術１（甲２～甲６）を適用することは容易であるとした上で、さらに、サーバ装置からキープアライブ信号に対する応答信号を送信するものとし、「患者端末装置が」「前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記エルゴメータによる負荷提供の中止を指示する」ことは当業者が適宜設計できることであるとすることは、いわば容易の容易と判断することになるのであって、このような容易想到性の判断は許されるものではない。 よって、異議申立人の上記主張は採用できない。 （３）まとめ 以上のとおりであるから、本件発明１９は、甲１発明４、及び甲２～甲８に記載の周知技術、並びに甲９に記載された事項に基づいて、当業者が容易に発明をすることができたものとはいえない。 ９ 本件発明２０、２１について 本件発明２０、２１は、本件発明１９と同様に「患者端末装置の制御方法」に係る発明であって、患者端末装置が、サーバ装置にキープアライブ信号を送信し、サーバ装置から応答信号を受信するものであり、「前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記機器による負荷提供の中止を指示することを含む」ものであり、これは、本件発明１９において「患者に負荷を提供する」構成を「エルゴメータ」から「機器」に上位概念化したものである。 してみると、本件発明２０、２１と甲１発明４との間には、少なくとも、本件発明２０、２１は「前記応答信号を最後に受信してから前記応答信号を予め定められた上限期間受信しない時点で前記機器による負荷提供の中止を指示することを含む」のに対して、甲１発明４はそのような構成を備えていないという、上記相違点３と同様な相違点を有するものである。 よって、上記８で示した理由と同様の理由により、本件発明２０は、甲１発明４、及び甲２～甲８に記載の周知技術、並びに甲９に記載された事項に基づいて、当業者が容易に発明をすることができたものとはいえないし、本件発明２１は、甲１発明４、及び甲２～甲８、甲１０～甲１２に記載の周知技術、並びに甲９に記載された事項に基づいて、当業者が容易に発明をすることができたものとはいえない。 第６ むすび 以上の次第であるから、特許異議の申立ての理由及び異議申立人の提出した証拠によっては、本件特許の請求項１～２１に係る特許を取り消すことはできない。 また、他に本件特許の請求項１～２１に係る特許を取り消すべき理由を発見しない。 よって、結論のとおり決定する。