• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 全部申し立て 2項進歩性  G06F
管理番号 1388406
総通号数
発行国 JP 
公報種別 特許決定公報 
発行日 2022-09-30 
種別 異議の決定 
異議申立日 2022-02-03 
確定日 2022-08-18 
異議申立件数
事件の表示 特許第6971016号発明「制御装置、制御方法およびプログラム」の特許異議申立事件について、次のとおり決定する。 
結論 特許第6971016号の請求項1ないし8に係る特許を維持する。 
理由 1 手続の経緯
特許第6971016号の請求項1〜8に係る特許についての出願は、平成28年4月7日に出願され、令和3年11月4日にその特許権の設定登録がされ、令和3年11月24日に特許掲載公報が発行された。その後、その特許に対し、令和4年2月3日に特許異議申立人伊藤裕美は、特許異議の申立てを行った。

2 本件特許発明
特許第6971016号の請求項1〜8の特許に係る発明(以下、「本件特許発明1」〜「本件特許発明8」という。)は、それぞれ、その特許請求の範囲の請求項1〜8に記載された事項により特定される次のとおりのものである。(なお、各請求項に付した分説は、当審によるもの。)

【請求項1】
《1A》設備または機械を制御する制御装置であって、
《1B》1または複数のプロセッサを含むハードウェアリソースと、
《1C》前記ハードウェアリソースを管理するハイパーバイザと、
《1D》前記ハイパーバイザによって割り当てられるそれぞれの仮想的なハードウェアリソースを利用して並列的に実行される、汎用オペレーティングシステム(OS)と、前記設備または機械の制御を実現するためのユーザプログラムの実行環境を提供するリアルタイムOSと、
《1E》外部からの遮断事象を受信する入力インターフェイスとを備え、
《1F》前記リアルタイムOSは、
《1Fa》前記遮断事象に応答して、前記ユーザプログラムに対してシャットダウンを指示するとともに、前記ユーザプログラムがシャットダウンされたことを示す条件が成立すると、前記リアルタイムOSのシャットダウンに必要なシャットダウン準備処理を開始する機能と、
《1Fb》前記シャットダウン準備処理の開始後に、前記ハイパーバイザを介して構成される論理的なネットワークを通じて、前記汎用OSに対してシャットダウンを指示する機能と、
《1Fc》前記汎用OSからのシャットダウン完了の通知の受信を含む、予め定められた条件が満たされると、前記ハイパーバイザを介して前記制御装置に対する電源供給が停止されても問題ないことを通知する信号を出力した後に、前記リアルタイムOSのシャットダウンを完了して前記制御装置の電源を遮断する機能とを備える、
《1G》制御装置。
【請求項2】
《2A》前記リアルタイムOSは、前記汎用OSに対してシャットダウンを指示してから予め定められた期間が経過すると、前記汎用OSからのシャットダウン完了の通知を受信しなくとも、前記制御装置の電源を遮断する、請求項1に記載の制御装置。
【請求項3】
《3A》前記入力インターフェイスは、前記制御装置に電源を供給する無停電電源装置が、当該無停電電源装置へ供給される外部電源が喪失したときに発する前記遮断事象を受信するように構成されており、
《3B》前記リアルタイムOSは、前記論理的なネットワークを通じて、前記リアルタイムOSのシャットダウンが完了したことを前記無停電電源装置へ通知する機能をさらに備える、請求項1または2に記載の制御装置。
【請求項4】
《4A》前記リアルタイムOSは、前記ユーザプログラムに対して、前記遮断事象を受信したか否かを示す情報を参照可能にする機能をさらに備える、請求項1〜3のいずれか1項に記載の制御装置。
【請求項5】
《5A》前記リアルタイムOSは、前記遮断事象を受信した後、前記ユーザプログラムからの所定の通知を受信したことを含む、予め定められた条件が満たされると、前記シャットダウン準備処理を開始する、請求項1〜4のいずれか1項に記載の制御装置。
【請求項6】
《6A》前記ユーザプログラムがシャットダウンされたことを示す条件は、前記ユーザプログラムに対してシャットダウンを指示してから予め定められた期間が経過したことを含む、請求項1〜5のいずれか1項に記載の制御装置。
【請求項7】
《7A》設備または機械を制御する制御装置での制御方法であって、
《7B》1または複数のプロセッサを含むハードウェアリソースを管理するハイパーバイザによって割り当てられるそれぞれの仮想的なハードウェアリソースを利用して、汎用オペレーティングシステム(OS)と、前記設備または機械の制御を実現するためのユーザプログラムの実行環境を提供するリアルタイムOSとを並列的に実行するステップと、
《7C》前記リアルタイムOSが、入力インターフェイスを介して受信した遮断事象に応答して、前記ユーザプログラムに対してシャットダウンを指示するとともに、前記ユーザプログラムがシャットダウンされたことを示す条件が成立すると、前記リアルタイムOSのシャットダウンに必要なシャットダウン準備処理を開始するステップと、
《7D》前記リアルタイムOSが、前記シャットダウン準備処理の開始後に、前記ハイパーバイザを介して構成される論理的なネットワークを通じて、前記汎用OSに対してシャットダウンを指示するステップと、
《7E》前記リアルタイムOSが、前記汎用OSからのシャットダウン完了の通知の受信を含む、予め定められた条件が満たされると、前記ハイパーバイザを介して前記制御装置に対する電源供給が停止されても問題ないことを通知する信号を出力した後に、前記リアルタイムOSのシャットダウンを完了して前記制御装置の電源を遮断するステップとを備える、
《7F》制御方法。
【請求項8】
《8A》予め用意されたユーザプログラムに従って設備または機械を制御するための環境を構築するリアルタイムオペレーティングシステム(OS)を含むプログラムであって、
《8B》前記リアルタイムOSは、汎用OSとともに1または複数のプロセッサを含むハードウェアリソースを管理するハイパーバイザによって割り当てられるそれぞれの仮想的なハードウェアリソースを利用して並列的に実行され、
《8C》前記プログラムはコンピュータに
《8Ca》入力インターフェイスを介して受信した遮断事象に応答して、前記ユーザプログラムに対してシャットダウンを指示するとともに、前記ユーザプログラムがシャットダウンされたことを示す条件が成立すると、前記リアルタイムOSのシャットダウンに必要なシャットダウン準備処理を開始するステップと、
《8Cb》前記シャットダウン準備処理の開始後に、前記ハイパーバイザを介して構成される論理的なネットワークを通じて、前記汎用OSに対してシャットダウンを指示するステップと、
《8Cc》前記汎用OSからのシャットダウン完了の通知の受信を含む、予め定められた条件が満たされると、前記ハイパーバイザを介して前記制御装置に対する電源供給が停止されても問題ないことを通知する信号を出力した後に、前記リアルタイムOSのシャットダウンを完了して電源を遮断するステップとを実行させる、
《8D》プログラム。

3 申立理由の概要
特許異議申立人伊藤裕美は、主たる証拠として特開平11−134073号公報(平成11年5月21日出願公開。以下、「甲1号証」という。)及び従たる証拠として特開平5−19899号公報(平成5年1月29日出願公開。以下、「甲2号証」という。)、特開平8−137765号公報(平成8年5月31日出願公開。以下、「甲3号証」という。)、国際公開第2013/065115号(2013年(平成25年)5月10日国際公開。以下、「甲4号証」という。)、白山貴之 外3名著、「VMware自動化ガイド スクリプティングとワークフローによる管理テクニック」、株式会社翔泳社、2014年11月13日、p.10、52−54(以下、「甲5号証」という。)を提出し、請求項1〜8に係る特許は、特許法第29条第2項の規定に違反してされたものであるから、請求項1〜8に係る特許を取り消すべきものである旨主張する。

4 甲1号証〜甲5号証の記載
(1)甲第1号証
ア 甲第1号証(特開平11−134073号公報)には、図面とともに次の事項が記載されている。(当審注:下線は、参考のために当審で付与したものである。以下、同様。)

「【0001】
【発明の属する技術分野】この発明は、産業用のマルチCPU装置に関し、特に、汎用OSを搭載したマスタCPUブロックと、リアルタイムOSを搭載したスレーブCPUブロックとを備える場合に適したマルチCPU装置である。
【0002】
【従来の技術】 マルチCPU装置を図5、6に示す。図5に示すマルチCPU装置30内には、電源18を設けている。この電源18は、外部の給電回路21からUPS22を介して供給したAC電流を、必要なDC電流に変換して出力する。そして、この電源18には、マスタ側1とスレーブ側19とを接続している。
【0003】上記マスタ側1は、ユーザーが操作する部分で、ユーザーインターフェイスに適した汎用OSを搭載したマスタCPUブロック2を備えている。このマスタCPUブロック2は、CPU3と、ROM4と、RAM5とからなり、記憶手段6と、キーボードやマウス等の入力装置7と、モニター8とを接続している。また、上記マスタ側1には、上記マスタCPUブロック2に接続したバス9を備えている。このバス9は、その一端に共有メモリ20を接続し、マスタCPUブロック2と共有メモリ20との間で信号を伝達できるようにしている。
【0004】一方、スレーブ側19は、生産装置などの制御対象機器50を制御する部分で、スレーブCPUブロック12を備えている。このスレーブCPUブロック12には、制御系に適したリアルタイム性のあるリアルタイムOSを搭載している。また、スレーブCPUブロック12は、CPU13とROM14とRAM15とからなり、バス11に接続している。このバス11には、制御機能ブロック16、17を接続している。このようにしたバス11の一端を上記共有メモリ20に接続している。この共有メモリ20とは、マスタ側1、スレーブ側19のそれぞれのCPUブロック2、12がバス9、11を介してアクセスできるメモリのことである。したがって、この共有メモリ20を介して、マスタ側1のマスタCPUブロック2とスレーブ側19のスレーブCPUブロック12間で、信号の伝達ができるようにしてる。
【0005】上記制御機能ブロック16、17は、例えば、接点入出力や、アナログデジタルコンバータ(以下ADCという)、デジタルアナログコンバータ(以下DACという)等の機能を備えている。この制御機能ブロック16、17には、直接上記制御対象機器50を接続している。そして、上記制御機能ブロック16、17は、スレーブCPUブロック12の信号に基づいて制御対象機器50を制御する。なお、図中二重線の矢印は電流供給配線を表わし、他の矢印は信号線を表わしている。
【0006】次に、このマルチCPU装置30によって、制御対象機器50を制御する方法を説明する。まず、マルチCPU装置30を立ち上げると、ROM14にあらかじめ格納した起動プログラムによって、マスタ側1の記憶手段6に記憶した制御プログラムが、CPUブロック2、バス9、共有メモリ20、バス11を介して、スレーブCPUブロック12のRAM15にダウンロードされる。ダウンロードされる上記制御プログラムは、制御機能ブロック16、17の機能および動作タイミングを制御するプログラムである。このように上記制御プログラムをRAM15にダウンロードすると、CPU13が、ダウンロードした制御プログラムに基づいて、制御機能ブロック16、17を制御する。」

「【0018】
【発明の実施の形態】図1〜図3に示すこの実施例は、マルチCPU装置10の内部に、UPS24を備えている。図1に示すように、このUPS24は、マスタ側1のマスタCPUブロック2とスレーブ側19のスレーブCPUブロック12とに接続している。このUPS24は、図示しない、バッテリと、停電感知回路と、リアルタイムOSインターフェイスとを備えている。そして、このUPS24は、通常、外部の給電回路21から入力されたAC電流をDC電流に変換して、マスタCPUブロック2とスレーブCPUブロック12へ供給している。また、停電になってAC電流の供給がなくなった場合には、UPS24内のバッテリが、マスタCPUブロック2とスレーブCPUブロック12へDC電流の供給を行なうようにしている。
【0019】さらに、このようなUPS24は、リアルタイムOSインターフェイスによって、UPS24とスレーブCPUブロック12に搭載したリアルタイムOSとの間で、信号のやり取りをできるようにしている。また、マルチCPU装置10内には電源23を備えている。この電源23は、AC電流の給電回路21に接続し、従来例の電源18と同様に、AC電流をDC電流に変換して、制御機能ブロック16、17に供給する。スレーブ側19には、上記制御機能ブロック16、17とスレーブCPUブロック12とを接続するバス11を備え、このバス11には、スイッチSを設けている。このスイッチSによって、上記制御機能ブロック16、17とマスタCPUブロック2およびスレーブCPUブロック12との間を、接続したり、遮断したりする。
【0020】また、スレーブCPUブロック12には、リアルタイムOSを搭載し、このリアルタイムOSには、停電時に、マスタCPUブロック2に搭載された汎用OSをシャットダウンするプログラムを付加している。さらに、リアルタイムOSには、停電時に、バス11上のスイッチSを切って、制御機能ブロック16、17をCPUブロック1、12から切り離すようにするプログラムも備えている。
【0021】一方、マスタCPUブロック2には、汎用OSを搭載している。そして、この汎用OSは、シャットダウンが終了すると、終了信号を出力するようにしている。また、上記汎用OSには、この汎用OSの健全性チェックプログラムを付加している。この健全性チェックプログラムは、汎用OSが作動すると作動するものである。そして、上記健全性チェックプログラムは、汎用OSが動作している間には、例えば、定期的に発生するパルス信号のような健全性確認信号を、リアルタイムOSに対して出力する。このようにすれば、リアルタイムOSは、健全性確認信号の入力があるかどうかによって、汎用OSが健全であるかどうかを検出できる。もし、汎用OSが不安定になり、それがロックしたような場合には、健全性チェックプログラムが健全性確認信号を出力しなくなるので、リアルタイムOSは、汎用OSの不安定状態を検出することができる。そして、不安定状態を検出した時、リアルタイムOSは、不安定検知信号を出力する。
【0022】また、上記マルチCPU装置10を複数用いて、生産ラインなどを構成する場合を図3に示す。この場合、マルチCPU装置10内意の電源23とUPS24には、給電回路21を直接接続している。このように接続した各マルチCPU装置10が、正常に作動して、制御対象機器50を制御する動作は従来のマルチCPU装置30と同様であるので、ここではその詳細は省略する。
【0023】一方、停電時など、給電回路21からの電流が供給されない場合には、マルチCPU装置10は、図2のフローチャートにしたがって動作し、リアルタイムOSが汎用OSをシャットダウンする。次に、図2に示すフローチャートにしたがって、停電時に汎用OSのシャットダウンを行なうフローを説明する。なお、図中「RTOS」は、リアルタイムOSのことを表わしている。ステップ1は、停電になり、給電回路21からの電流供給が止まった状態である。ステップ2では、UPS24の停電感知回路が、AC電流の入力がないことから、停電を感知する。ステップ3で、UPS24は、マスタCPUブロック2とスレーブCPUブロック12へバッテリ電流を供給する。
【0024】ステップ4では、UPS24が、リアルタイムOSインターフェイスを介して、停電感知信号をリアルタイムOSへ出力する。ステップ5では、リアルタイムOSが停電を検出する。ステップ6では、停電を検出したリアルタイムOSが、バス11上のスイッチSを切る。この時点で、制御機能ブロック16、17は、マスタCPUブロック2およびスレーブCPUブロック12から遮断される。バッテリの電流が、上記マスタCPUブロック2およびスレーブCPUブロック12から、バス9、11を介して制御機能ブロック16、17へ供給されず、CPUブロック2、12だけに供給されるようになる。このように、汎用OSをシャットダウンするのに関係のない部分に電流を供給しないので、電流の節約ができる。
【0025】ステップ7では、リアルタイムOSが、汎用OSをシャットダウンするプログラムを起動して、汎用OSにシャットダウン指令を出力する。ステップ8では、上記指令にもとづいて汎用OSがシャットダウンを実行する。ステップ9で、リアルタイムOSは、汎用OSがシャットダウンを終了したかどうかを判断する。汎用OSのシャットダウン動作中、汎用OSからリアルタイムOSへ、シャットダウン動作が継続中であるという信号が出力される。この場合に、リアルタイムOSは、シャットダウンが終了するのを待機している。
【0026】シャットダウンが終了して、シャットダウン終了信号が出力されると、ステップ10へ進み、リアルタイムOSは、その終了を検出する。そして、ステップ11では、リアルタイムOSが、UPS24にバッテリからの電流供給を停止するように信号を出力し、リアルタイムOS自身もシャットダウンする。これにより、ステップ12で、システム全体が、パワーオフ状態となる。
【0027】このように、マルチCPU装置10内部に備えたUPS24が、停電を感知すると、リアルタイムOSが、自動的に、汎用OSをシャットダウンする。したがって、オペレータがマルチCPU装置10を操作する必要がない。このように、リアルタイムOSが汎用OSを自動的にシャットダウンするので、汎用OSのデータを確実に保存できる。図3のように、たくさんのマルチCPU装置10を並べた場合にも、各マルチCPU装置10が、上記フローチャートにしたがって動作し、各リアルタイムOSが各汎用OSを、自動的にシャットダウンする。」

「【0034】なお、上記実施例では、バス9と共有メモリ20とバス11とを介して、スレーブ側19のRAM15に制御プログラムをマスタ側1からダウンロードするようにしている。このようにすると、制御プログラムを変更する場合にも、マスタ側1から新しい制御プログラムをダウンロードして、RAM15に設定できる。このため、制御プログラムの変更が容易である。ただし、制御プログラムをマスタ側1からダウンロードするのではなく、スレーブ側19のROMに設定しておくようにしてもかまわない。この場合には、制御プログラムの変更は、ROMの交換により行なう。」

【図1】


【図2】


【図5】


イ 上記記載事項、特に下線部によれば、甲1号証には、次の技術的事項が記載されているものと認められる。

(a1)従来のマルチCPU装置30内には、電源18を設け、この電源18には、マスタ側1とスレーブ側19とを接続している(【0002】)
(a2)上記マスタ側1は、ユーザーが操作する部分で、ユーザーインターフェイスに適した汎用OSを搭載したマスタCPUブロック2を備え、このマスタCPUブロック2は、CPU3と、ROM4と、RAM5とからなり、記憶手段6と、キーボードやマウス等の入力装置7と、モニター8とを接続し、また、上記マスタ側1には、上記マスタCPUブロック2に接続したバス9を備えており、このバス9は、その一端に共有メモリ20を接続し、マスタCPUブロック2と共有メモリ20との間で信号を伝達できるようにしている(【0003】)
(a3)一方、スレーブ側19は、生産装置などの制御対象機器50を制御する部分で、スレーブCPUブロック12を備え、このスレーブCPUブロック12には、制御系に適したリアルタイム性のあるリアルタイムOSを搭載し、また、スレーブCPUブロック12は、CPU13とROM14とRAM15とからなり、バス11に接続し、このバス11には、制御機能ブロック16、17を接続し、このようにしたバス11の一端を上記共有メモリ20に接続し、この共有メモリ20とは、マスタ側1、スレーブ側19のそれぞれのCPUブロック2、12がバス9、11を介してアクセスできるメモリのことであり、したがって、この共有メモリ20を介して、マスタ側1のマスタCPUブロック2とスレーブ側19のスレーブCPUブロック12間で、信号の伝達ができるようにしている(【0004】)
(a4)上記制御機能ブロック16、17は、例えば、接点入出力や、アナログデジタルコンバータ(以下ADCという)、デジタルアナログコンバータ(以下DACという)等の機能を備え、この制御機能ブロック16、17には、直接上記制御対象機器50を接続し、そして、上記制御機能ブロック16、17は、スレーブCPUブロック12の信号に基づいて制御対象機器50を制御する(【0005】)
(a5)マスタ側1の記憶手段6に記憶した制御プログラムが、スレーブCPUブロック12のRAM15にダウンロードされ、ダウンロードされる上記制御プログラムは、制御機能ブロック16、17の機能および動作タイミングを制御するプログラムであり、このように上記制御プログラムをRAM15にダウンロードすると、CPU13が、ダウンロードした制御プログラムに基づいて、制御機能ブロック16、17を制御する(【0006】)

(b1)マルチCPU装置10の内部に、UPS24を備え、このUPS24は、マスタ側1のマスタCPUブロック2とスレーブ側19のスレーブCPUブロック12とに接続し、このUPS24は、バッテリと、停電感知回路と、リアルタイムOSインターフェイスとを備え、そして、このUPS24は、通常、外部の給電回路21から入力されたAC電流をDC電流に変換して、マスタCPUブロック2とスレーブCPUブロック12へ供給し、また、停電になってAC電流の供給がなくなった場合には、UPS24内のバッテリが、マスタCPUブロック2とスレーブCPUブロック12へDC電流の供給を行なうようにしている(【0018】)
(b2)UPS24は、リアルタイムOSインターフェイスによって、UPS24とスレーブCPUブロック12に搭載したリアルタイムOSとの間で、信号のやり取りをできるようにしている(【0019】)
(b3)スレーブ側19には、制御機能ブロック16、17とスレーブCPUブロック12とを接続するバス11を備え、このバス11には、スイッチSを設け、このスイッチSによって、上記制御機能ブロック16、17とマスタCPUブロック2およびスレーブCPUブロック12との間を、接続したり、遮断したりする(【0019】)
(b4)スレーブCPUブロック12には、リアルタイムOSを搭載し、このリアルタイムOSには、停電時に、マスタCPUブロック2に搭載された汎用OSをシャットダウンするプログラムを付加し、さらに、リアルタイムOSには、停電時に、バス11上のスイッチSを切って、制御機能ブロック16、17をCPUブロック1、12から切り離すようにするプログラムも備えている(【0020】)
(b5)マスタCPUブロック2には、汎用OSを搭載し、この汎用OSは、シャットダウンが終了すると、終了信号を出力するようにしている(【0021】)
(b6)各マルチCPU装置10が、正常に作動して、制御対象機器50を制御する動作は従来のマルチCPU装置30と同様である(【0022】)

(c)停電時に汎用OSのシャットダウンを行なうフローは、次のとおり
(c1)ステップ1は、停電になり、給電回路21からの電流供給が止まった状態である(【0023】)
(c2)ステップ2では、UPS24の停電感知回路が、AC電流の入力がないことから、停電を感知する(【0023】)
(c3)ステップ3で、UPS24は、マスタCPUブロック2とスレーブCPUブロック12へバッテリ電流を供給する(【0023】)
(c4)ステップ4では、UPS24が、リアルタイムOSインターフェイスを介して、停電感知信号をリアルタイムOSへ出力する(【0024】)
(c5)ステップ5では、リアルタイムOSが停電を検出する(【0024】)
(c6)ステップ6では、停電を検出したリアルタイムOSが、バス11上のスイッチSを切り、この時点で、制御機能ブロック16、17は、マスタCPUブロック2およびスレーブCPUブロック12から遮断される(【0024】)
(c7)ステップ7では、リアルタイムOSが、汎用OSをシャットダウンするプログラムを起動して、汎用OSにシャットダウン指令を出力する(【0025】)
(c8)ステップ8では、上記指令にもとづいて汎用OSがシャットダウンを実行する(【0025】)
(c9)ステップ9で、リアルタイムOSは、汎用OSがシャットダウンを終了したかどうかを判断する、汎用OSのシャットダウン動作中、汎用OSからリアルタイムOSへ、シャットダウン動作が継続中であるという信号が出力され、この場合に、リアルタイムOSは、シャットダウンが終了するのを待機している(【0025】)
(c10)シャットダウンが終了して、シャットダウン終了信号が出力されると、ステップ10へ進み、リアルタイムOSは、その終了を検出する(【0026】)
(c11)そして、ステップ11では、リアルタイムOSが、UPS24にバッテリからの電流供給を停止するように信号を出力し、リアルタイムOS自身もシャットダウンする(【0026】)
(c12)これにより、ステップ12で、システム全体が、パワーオフ状態となる(【0026】)
(c13)このように、マルチCPU装置10内部に備えたUPS24が、停電を感知すると、リアルタイムOSが、自動的に、汎用OSをシャットダウンし、したがって、オペレータがマルチCPU装置10を操作する必要がなく、このように、リアルタイムOSが汎用OSを自動的にシャットダウンするので、汎用OSのデータを確実に保存できる(【0027】)

(d)制御プログラムをマスタ側1からダウンロードするのではなく、スレーブ側19のROMに設定しておくようにしてもかまわない(【0034】)

ウ 上記ア、イから、甲1号証には、次の発明(以下、「甲1発明」という。)が記載されていると認められる。

〈甲1発明〉
「UPS24、マスタ側1とスレーブ側19とを備えたマルチCPU装置であって、
マスタ側1は、CPU3とROM4とRAM5とからなるマスタCPUブロック2とバス9を備え、マスタCPUブロック2には、ユーザーインターフェイスに適した汎用OSが搭載され、
スレーブ側19は、生産装置などの制御対象機器50を制御する部分で、CPU13とROM14とRAM15とからなるスレーブCPUブロック12、バス11、制御機能ブロック16、17を備え、スレーブCPUブロック12には、制御系に適したリアルタイム性のあるリアルタイムOSが搭載され、CPU13が、RAM15にダウンロードした制御プログラムに基づいて、制御対象機器50を制御する制御機能ブロック16、17を制御し、
マスタ側1、スレーブ側19のそれぞれのCPUブロック2、12がバス9、11を介してアクセスできる共有メモリ20を介して、マスタCPUブロック2とスレーブCPUブロック12間で、信号の伝達ができるようにしており、
UPS24は、リアルタイムOSインターフェイスによって、リアルタイムOSとの間で、信号のやり取りをできるようになっており、
リアルタイムOSは、バス11上のスイッチSを切って、制御機能ブロック16、17をCPUブロック1、12から切り離すようにするプログラム及び汎用OSをシャットダウンするプログラムを備え、
UPS24の停電感知回路が停電を感知した場合には、UPS24内のバッテリからDC電流をマスタCPUブロック2およびスレーブCPUブロック12へ出力するとともに、リアルタイムOSインターフェイスがリアルタイムOSに停電感知信号を出力し、
停電を検出したリアルタイムOSが、バス11上のスイッチSを切り、制御機能ブロック16、17は、マスタCPUブロック2およびスレーブCPUブロック12から遮断され、リアルタイムOSが、汎用OSをシャットダウンするプログラムを起動して、汎用OSにシャットダウン指令を出力し、上記指令にもとづいて汎用OSがシャットダウンを実行し、
汎用OSのシャットダウン動作中、汎用OSからリアルタイムOSへ、シャットダウン動作が継続中であるという信号が出力され、リアルタイムOSは、シャットダウンが終了するのを待機し、
汎用OSのシャットダウンが終了して、シャットダウン終了信号が出力されると、リアルタイムOSは、その終了を検出し、UPS24にバッテリからの電流供給を停止するように信号を出力し、リアルタイムOS自身もシャットダウンし、システム全体が、パワーオフ状態となることを特徴とするマルチCPU装置。」

(2)甲第2号証
甲第2号証(特開平5−19899号公報)には、図面とともに次の事項が記載されている。

「【0010】この実施例のコンピュータシステムにおいて、停電が発生した場合の処理は、図3のフローチャートに示すように、停電が発生すると、無停電電源装置18は、バッテリー給電を行ない、コンピュータ装置10および制御装置22をバックアップする。そして、無停電電源装置18は、電源が切れたことを制御装置22に信号ライン24を介して知らせる。そして、制御装置22は、信号ライン26により停電をコンピュータ装置10に知らせる。すると、コンピュータ装置10では、内蔵された停電処理用のデータ退避プログラムが作動し、現在処理中のデータを磁気記憶装置16に格納し、コンピュータ装置10のシステムを立ち下げる。この処理が終了すると、コンピュータ装置10から、信号ライン27を通して制御装置22に、処理中のデータを退避する停電処理が終了したことを知らせる。この後、制御装置22から上記無停電電源装置18へ、信号ライン25を介して、給電停止信号が送られ、この無停電電源装置18内のバッテリーからコンピュータ装置10および制御装置22への給電が停止し、停電時の処理が終了する。
【0011】また、上記処理に際して、制御装置22がコンピュータ装置10からのデータ退避処理終了通知が確認できない場合に備え、一定時間を経ても上記終了信号がこない場合は、制御装置22は自動的に無停電電源装置18へ、給電停止信号を送るようにしても良い。」

(3)甲第3号証
甲第3号証(特開平8−137765号公報)には、図面とともに次の事項が記載されている。

「【0013】オペレーティングシステム4は、コンピュータが動作する場合の基本ソフトウェアであり、電源オン/オフインタフェース部41、シャットダウン処理部42を備えている。電源オン/オフインタフェース部41は、オペレーティングシステム4のカーネルに設けられ、電源のオン/オフ状態を示すためのフラグ41aを備え、電源制御部3からの割込み信号NMIを受けて、そのフラグ41aをオフ状態とする機能を備えている。また、シャットダウン処理部42は、オペレーティングシステム4が有するシャットダウン機能によるシャットダウン処理を実行するものである。
【0014】起動指示部(以下、スイッチオフ検出用アプリケーションという)5は、所定時間間隔で電源オン/オフインタフェース部41のフラグ41aの状態のポーリングを行い、フラグ41aがオフ状態であった場合は、シャットダウン処理部42に対してオフ通知を行う機能を備えている。また、ディスプレイ6、プリンタ7およびイメージスキャナ8は、それぞれ電源線61、71、81を介して外部電源装置1より電源供給され、本体部2からの制御により各種の動作を行う周辺機器である。
【0015】次に、このように構成された電源断処理システムの動作について説明する。先ず、システム起動時、オペレーティングシステム4は、電源制御部3が取り付けられているかを判定し、電源制御部3が取り付けられていた場合は、外部電源装置1に関する機能を有効とする。即ち、電源制御部3から割込み信号NMIが上がってきた場合は電源オン/オフインタフェース部41のフラグ41aをオフ状態とし、このフラグ41aのオフ状態によるスイッチオフ検出用アプリケーション5の通知によってシャットダウン処理を行う処理を行う機能を有効とする。尚、この場合、外部電源装置1では、電源が投入されていない状態では電源スイッチ13が有効となるよう構成され、従って、電源スイッチ13を押下することによって電源供給部11から本体部2に電源が供給されるものである。
【0016】次に、システム停止時の動作について説明する。今、外部電源装置1から本体部2に対して電源供給が行われている状態で、システム停止のために電源スイッチ13が押下されたとする。これにより、制御部12は電源スイッチ押下信号をインタフェースケーブル31を介して電源制御部3に送出する。電源制御部3は、この電源スイッチ押下信号を受けると、それ以降の電源スイッチ13の機能を無効とし、かつ、割込み信号NMIをオペレーティングシステム4に対して上げる。これにより、電源オン/オフインタフェース部41は、そのフラグ41aをオフ状態とする。
【0017】一方、スイッチオフ検出用アプリケーション5は、例えば、2秒間隔といったように所定時間間隔でポーリングを行っており、そのフラグ41aがオフ状態になることによって、シャットダウン処理部42にシャットダウン処理開始指示を行う。シャットダウン処理部42は、これにより、実行中の処理があった場合は、その処理を終了させ、処理が終了すると、シャットダウン処理終了通知を電源制御部3に対して行う。電源制御部3は、このシャットダウン処理終了通知を受けると、電源スイッチ13の機能を有効とするよう制御部12に指示を行う。これにより、制御部12は、電源スイッチ13押下による電源オフを電源供給部11に対して行い、外部電源装置1からの電源供給が停止する。」

(4)甲第4号証
甲第4号証(国際公開第2013/065115号)には、図面とともに次の事項が記載されている。

「 技術分野
[0001] 本発明は、情報処理装置、情報処理装置の制御方法、仮想マシン制御プログラム及び情報処理システムに関する。
背景技術
[0002] 仮想化システムは、1台の物理マシン上に仮想マシンと呼ばれる環境を複数用意することができる。この仮想マシンは、例えばハイパーバイザなど仮想化プログラムにより管理される仮想領域で動作する。
[0003] また、仮想化システムを実行するサーバは、停電に備えてサーバの電源を無停電電源装置(UPS:Uninterruptible Power Supply)に接続する。そして、サーバは、停電時にUPSのバッテリから電力を確保し、仮想化システムをシャットダウンする。
[0004] 図17を用いて、従来技術に係る仮想化システムにおけるシャットダウン処理動作について説明する。図17は、従来技術に係る仮想化システムにおけるシャットダウン処理動作を示す図である。図17に示すように、停電が発生した場合、UPSは、停電を検出し(ステップS901)、バッテリで電力を供給する(ステップS902)。
[0005] また、サーバは、所定の時間待機して、仮想化システムのシャットダウン処理を実行するか否かを判定する(ステップS903)。そして、サーバは、所定の待機時間が経過した場合、仮想化システムのシャットダウン処理を開始する(ステップS904)。ここで、サーバでは、ゲストOSを終了し、アプリケーションを終了してから仮想化プログラムを終了させる。このような処理には、通常数分を要する。UPSは、その間電力を供給し続けた後、出力をオフにする(ステップS905)。
[0006] また、停電から復旧した場合には、UPSは、出力をオンにする(ステップS906)。そして、サーバは、BIOS(Basic Input/Output System)を起動し(ステップS907)、仮想化システムを再起動させる(ステップS908)。
[0007] このように、サーバは、仮想化システムをシャットダウンすることで、仮想マシンの状態を自動的に保存し、仮想マシンの処理を停止する。また、サーバは、仮想化システムを再起動することで、保存されていた仮想マシンの状態が復元され、仮想マシンを自動的に起動する。」

「[0018][実施例1に係る情報処理システムの構成]
図1は、実施例1に係る情報処理システムの構成の一例を示す図である。図1に示すように、実施例1に係る情報処理システム1は、ハブ2、UPS(Uninterruptible Power Supply)装置3、共有ストレージ4、サーバ10、サーバ20を有する。なお、後述するように、サーバ10とサーバ20とは、サーバ仮想化技術を適用したサーバである。
[0019] ハブ2は、サーバ10とサーバ20とを互いに通信可能に接続する。UPS装置3は、通常時にはサーバ20、ハブ2、共有ストレージ4に電力を供給するとともに、停電時には内蔵するバッテリからハブ2、共有ストレージ4、サーバ20に予備の電力を供給する。
[0020] サーバ10は、電池付電源11、ハードウェア12を有する。電池付電源11は、通常時にはサーバ10に電力を供給する。また、電池付電源11は、停電検出回路を有しており、停電の発生を検出した場合、内蔵するバッテリから予備の電力をサーバ10に供給する。なお、電池付電源11が有するバッテリ容量は、UPS3が有するバッテリ容量と比較して小さい。
[0021] ハードウェア12は、例えば、CPU(Central Processing Unit)とメインメモリとを含み、複数の仮想マシンを動作させる。図1に示す例では、サーバ10は、ハードウェア12上で機能する仮想化プログラム13により、仮想マシン(VM:Virtual Machine)14とVM15とを動作させている。なお、このVM14は、ゲストOS(Operating System)14aとアプリ14bとを動作させており、VM15は、ゲストOS15aとアプリ15bとを動作させている。
[0022] また、仮想化プログラム13は、退避部13aと停止部13bとを有し、停電時に仮想化システムのシャットダウンを制御する。退避部13aは、停電時に、共有ストレージにゲストOS情報とアプリ情報を退避する。なお、ここで言う退避とは、コピーなどによる移動等を示す。また、退避部13aは、無停電電源装置を有する退避用の他装置に、仮想マシンに割り当てられたメモリが記憶する情報と該仮想マシンに割り当てられたレジスタが記憶する情報とを含む仮想マシン情報を退避させる。停止部13bは、仮想マシン情報の退避が終了した場合に、仮想マシンを停止する。」

(5)甲第5号証
甲第5号証(白山貴之 外3名著、「VMware自動化ガイド スクリプティングとワークフローによる管理テクニック」、株式会社翔泳社、2014年11月13日、p.10、52−54)には、図とともに次の事項が記載されている。

ア 10ページ
「1.6 VMware社が提供する自動化ツール
・・・(中略)・・・・
1.6.1 vSphere CLI(vCLI)
vCLIはコマンドラインイターフェイスからvSphere環境を操作するためのコマンドラインツールです。WindowsおよびLinux向けに提供されています。また、旧来のESX[メモ]で提供されていたサービスコンソールを代替するvCLIの実行環境として、仮想アプライアンスベースのコマンド実行環境であるvSphere Management Assistant(vMA)も提供されています。
メモ VMware社はvSphre 4.XまではESXとESXiの2種類のハイパーバイザーを出荷していました。ESXではLinuxベースのサービスコンソールが提供されており、そこで管理用のスクリプトを実行することが可能でした。vSphere 5からはハイパーバイザーはESXiに一本化されたため、システム管理者はサービスコンソールを利用することができなくなりました。それを代替するためにVMware社が提供したのがvMAです。
・・・(以下、略)・・・」

イ 52ページ下2行−54ページ
「上の図の場合は、offが返されたため仮想マシンは起動していないことがわかります。次に、「 gettoolslastactive」を実行し、仮想マシンを起動してみます。
・・・(中略)・・・・
ゲストOSが正しく起動したかは、VMware Toolsの稼働状況で確認できます。VMware Toolsの稼働状況の確認には、「 gettoolslastactive」を使います。
・・・(中略)・・・・
戻り値の意味は、それぞれ以下のようになります。
・0 :仮想マシンが起動してから、まだVMware Toolsからハートビートが返っていない
・1 :VMware Toolsから正常にハートビートが返っている
・5 :VMware Toolsからのハートビートは返っているが、欠けたり遅延している
・100:VMware Toolsからのハートビートが途絶えている
・・・(中略)・・・・
仮想マシンの停止には「 stop soft」もしくは「 stop hard」を使います。stop softは vSphere Clientでの「ゲストOSのシャットダウン」に相当し、VMware Toolsを使いOSにシャットダウンを掛けてから仮想マシンを停止します。softでの実行は、VMware Toolsがインストールされていて、実行されている必要があります。また、stop hardは「パワーオフ」に相当し、ゲストOSの稼働状況にかかわらず仮想マシンの電源を止めてしまいます。以下のように実行します。
・・・(以下、略)・・・」

5 当審の判断
(1)本件特許発明1について
ア 本件特許発明1と甲1発明とを対比する。
(ア)甲1発明の「UPS24、マスタ側1とスレーブ側19とを備えたマルチCPU装置」において、「スレーブ側19は、生産装置などの制御対象機器50を制御する部分で」あるところ、甲1発明の「生産装置などの制御対象機器50を制御する」ことは、本件特許発明1の「設備または機械を制御する」ことに相当するといえる。
(イ)甲1発明の「マスタ側1は、CPU3とROM4とRAM5とからなるマスタCPUブロック2」を備え、「スレーブ側19は、」「CPU13とROM14とRAM15とからなるスレーブCPUブロック12、バス11、制御ブロック16、17」を備えているところ、甲1発明の「CPU3とROM4とRAM5」および「CPU13とROM14とRAM15」は、本件特許発明1の「1または複数のプロセッサを含むハードウェアリソース」に相当するといえる。
(ウ)甲1発明の「マスタCPUブロック2には、ユーザーインターフェイスに適した汎用OSが搭載され」ているところ、甲1発明の「汎用OS」は、本件特許発明1の「汎用オペレーティングシステム(OS)」に相当するといえる。
また、甲1発明の「スレーブCPUブロック12には、制御系に適したリアルタイム性のあるリアルタイムOSが搭載され、CPU13が、RAM15にダウンロードした制御プログラムに基づいて、制御対象機器50を制御する制御機能ブロック16、17を制御」しているところ、甲1発明の「RAM15にダウンロードした制御プログラム」は、本件特許発明1の「設備または機械の制御を実現するためのユーザプログラム」に相当するといえ、また、甲1発明の「制御系に適したリアルタイム性のあるリアルタイムOS」は、本件特許発明1の「設備または機械の制御を実現するためのユーザプログラムの実行環境を提供するリアルタイムOS」に相当するといえる。
そして、甲1発明では、「マスタ側1、スレーブ側19のそれぞれのCPUブロック2、12がバス9、11を介してアクセスできる共有メモリ20を介して、マスタCPUブロック2とスレーブCPUブロック12間で、信号の伝達ができるようにして」いることから、甲1発明の「汎用OS」と「リアルタイムOS」は、それぞれのハードウェアリソースを利用して並列的に実行されるものと認められる。
そうすると、甲1発明と本件特許発明1は、「それぞれのハードウェアリソースを利用して並列的に実行される、汎用オペレーティングシステム(OS)と、前記設備または機械の制御を実現するためのユーザプログラムの実行環境を提供するリアルタイムOS」を備える点で共通するといえる。
(エ)甲1発明の「UPS24の停電感知回路が停電を感知した場合には、」「リアルタイムOSインターフェイスがリアルタイムOSに停電感知信号を出力」する構成は、本件特許発明1の「外部からの遮断事象を受信する入力インターフェイス」に相当するといえる。
(オ)甲1発明の「リアルタイムOS」が備える「バス11上のスイッチSを切って、制御機能ブロック16、17をCPUブロック1、12から切り離すようにするプログラム」により「停電を検出したリアルタイムOSが、バス11上のスイッチSを切り、制御機能ブロック16、17は、マスタCPUブロック2およびスレーブCPUブロック12から遮断」する構成は、本件特許発明1の「リアルタイムOS」が備える「前記遮断事象に応答して、前記ユーザプログラムに対してシャットダウンを指示するとともに、前記ユーザプログラムがシャットダウンされたことを示す条件が成立すると、前記リアルタイムOSのシャットダウンに必要なシャットダウン準備処理を開始する機能」と、「前記遮断事象に応答して、前記リアルタイムOSのシャットダウンに必要なシャットダウン準備処理を開始する機能」である点で共通するといえる。
(カ)甲1発明の「リアルタイムOSが、汎用OSをシャットダウンするプログラムを起動して、汎用OSにシャットダウン指令を出力」する構成は、本件特許発明1の「前記シャットダウン準備処理の開始後に、前記ハイパーバイザを介して構成される論理的なネットワークを通じて、前記汎用OSに対してシャットダウンを指示する機能」と、「前記シャットダウン準備処理の開始後に、前記汎用OSに対してシャットダウンを指示する機能」である点で共通するといえる。
(キ)甲1発明において、汎用OSの「シャットダウンが終了して、シャットダウン終了信号が出力されると、リアルタイムOSは、その終了を検出し、UPS24にバッテリからの電流供給を停止するように信号を出力し、リアルタイムOS自身もシャットダウンし、システム全体が、パワーオフ状態となる」構成は、本件特許発明1の「前記汎用OSからのシャットダウン完了の通知の受信を含む、予め定められた条件が満たされると、前記ハイパーバイザを介して前記制御装置に対する電源供給が停止されても問題ないことを通知する信号を出力した後に、前記リアルタイムOSのシャットダウンを完了して前記制御装置の電源を遮断する機能」と、「前記汎用OSからのシャットダウン完了の通知の受信を含む、予め定められた条件が満たされると、前記制御装置に対する電源供給が停止されても問題ないことを通知する信号を出力した後に、前記リアルタイムOSのシャットダウンを完了して前記制御装置の電源を遮断する機能」である点で共通するといえる。
(ク)甲1発明の「マルチCPU装置」は、後述する相違点を除き、本件特許発明1の「制御装置」に相当するといえる。

イ したがって、本件特許発明1と甲1発明との間には、次の一致点、相違点があるといえる。

(一致点)
《1A》設備または機械を制御する制御装置であって、
《1B》1または複数のプロセッサを含むハードウェアリソースと、
《1D’》それぞれのハードウェアリソースを利用して並列的に実行される、汎用オペレーティングシステム(OS)と、前記設備または機械の制御を実現するためのユーザプログラムの実行環境を提供するリアルタイムOSと、
《1E》外部からの遮断事象を受信する入力インターフェイスとを備え、
《1F》前記リアルタイムOSは、
《1Fa’》前記遮断事象に応答して、前記リアルタイムOSのシャットダウンに必要なシャットダウン準備処理を開始する機能と、
《1Fb’》前記シャットダウン準備処理の開始後に、前記汎用OSに対してシャットダウンを指示する機能と、
《1Fc’》前記汎用OSからのシャットダウン完了の通知の受信を含む、予め定められた条件が満たされると、前記制御装置に対する電源供給が停止されても問題ないことを通知する信号を出力した後に、前記リアルタイムOSのシャットダウンを完了して前記制御装置の電源を遮断する機能とを備える、
《1G》制御装置。

(相違点1)《1C》
本件特許発明1は、「ハードウェアリソースを管理するハイパーバイザ」を備えるのに対し、
甲1発明は、「ハードウェアリソースを管理するハイパーバイザ」を備えていない点。

(相違点2)《1D》
本件特許発明1では、「前記ハイパーバイザによって割り当てられるそれぞれの仮想的なハードウェアリソースを利用して並列的に実行される、汎用オペレーティングシステム(OS)と、前記設備または機械の制御を実現するためのユーザプログラムの実行環境を提供するリアルタイムOS」を備えるのに対し、
甲1発明では、汎用OSとリアルタイムOSは、「ハイパーバイザによって割り当てられる」「仮想的な」ハードウェアリソースを利用して実行されるものではない点。

(相違点3)《1Fa》
本件特許発明1のリアルタイムOSは、「前記遮断事象に応答して、前記ユーザプログラムに対してシャットダウンを指示するとともに、前記ユーザプログラムがシャットダウンされたことを示す条件が成立すると、前記リアルタイムOSのシャットダウンに必要なシャットダウン準備処理を開始する機能」を備えるのに対し、
甲1発明では、「停電を検出したリアルタイムOSが、バス11上のスイッチSを切り、制御機能ブロック16、17は、マスタCPUブロック2およびスレーブCPUブロック12から遮断され」るものではあるものの、リアルタイムOSが、停電の検出に応答して、「制御プログラムに対してシャットダウンを指示する」ことについて特定されていない点。

(相違点4)《1Fb》
本件特許発明1のリアルタイムOSは、「前記シャットダウン準備処理の開始後に、前記ハイパーバイザを介して構成される論理的なネットワークを通じて、前記汎用OSに対してシャットダウンを指示する機能」を備えるのに対し、
甲1発明のリアルタイムOSは、「ハイパーバイザを介して構成される論理的なネットワークを通じて」、汎用OSに対してシャットダウンを指示することについて特定されていない点。

(相違点5)《1Fc》
本件特許発明1のリアルタイムOSは、「前記汎用OSからのシャットダウン完了の通知の受信を含む、予め定められた条件が満たされると、前記ハイパーバイザを介して前記制御装置に対する電源供給が停止されても問題ないことを通知する信号を出力した後に、前記リアルタイムOSのシャットダウンを完了して前記制御装置の電源を遮断する機能」を備えるのに対し、
甲1発明のリアルタイムOSは、「ハイパーバイザを介して」前記制御装置に対する電源供給が停止されても問題ないことを通知する信号を出力することについて特定されていない点。

イ 相違点についての判断
(ア)事案に鑑み、ハイパーバイザに関して相互に関連する上記相違点1、2、4、5について、まとめて検討する。
(イ)甲4号証には、「仮想化システムは、1台の物理マシン上に仮想マシンと呼ばれる環境を複数用意することができる。この仮想マシンは、例えばハイパーバイザなど仮想化プログラムにより管理される仮想化領域で動作する。」([0002])、「ハードウェア12上で機能する仮想化プログラム13により、仮想マシン(VM:Virtual Machine)14とVM15とを動作させている。なお、このVM14は、ゲストOS(Operating System)14aとアプリ14bとを動作させており、VM15は、ゲストOS15aとアプリ15bとを動作させている。」([0021])、「仮想化プログラム13は、退避部13aと停止部13bとを有し、停電時に仮想化システムのシャットダウンを制御する。」([0022])と記載されている。
甲4号証に開示されるように、一般的な仮想環境においては、ハイパーバイザ(仮想化プログラム)がリソースの管理を含めて主導的な役割を果たすものと認められるところ、甲4号証には、ハイパーバイザにより管理される仮想化領域で動作する各仮想マシンで実行するいずれかのOSが、ハイパーバイザを介して他のOSに対して何らかの指示などを行うような構成について記載も示唆もされていない。
(ウ)また、甲5号証には、「仮想マシンの停止には「 stop soft」もしくは「 stop hard」を使います。stop softは vSphere Clientでの「ゲストOSのシャットダウン」に相当し、VMware Toolsを使いOSにシャットダウンを掛けてから仮想マシンを停止します。」(54ページ)と記載されている。
しかしながら、甲5号証は、VMwareのvSphere(ハイパーバイザ)において、Linuxベースのサービスコンソールに代替するコマンド実行環境として提供されるvSphere Management Assistant (vMA)について開示するものであり、「stop soft」は、ハイパーバイザがゲストOSのシャットダウンを指示しているのであって、各仮想マシンで実行するいずれかのゲストOSが、ハイパーバイザを介して他のゲストOSに対してシャットダウンを指示する構成について記載するものではなく、そのことを示唆するものでもない。
(エ)そうしてみると、甲1発明に引用文献4、5に記載されるような仮想環境を適用した場合であっても、ハイパーバイザがリソースを管理する仮想環境においては、甲1発明のシャットダウン処理を実現するためのリアルタイムOSが担っていた処理をハイパーバイザが担うように実装するものと認められ、停電時におけるマルチCPU装置のシャットダウン処理のみを「リアルタイムOS」が主体となって制御するようにするとは想定し難い。
(オ)また、ハイパーバイザにより管理される仮想化領域で動作する各仮想マシンで実行するいずれかのOSが、ハイパーバイザを介して他のOSに対して何らかの指示などを行うような構成は、他の引用文献に記載も示唆もなく、このことが、本願の出願前に当該技術分野における周知技術であったともいえない。
(カ)してみれば、甲1発明において、「ハードウェアリソースを管理するハイパーバイザ」を備え、汎用OSとリアルタイムOSが「ハイパーバイザによって割り当てられるそれぞれの仮想的なハードウェアリソースを利用して」動作するように構成した上で、リアルタイムOSは、「ハイパーバイザを介して構成される論理的なネットワークを通じて」、汎用OSに対してシャットダウンを指示するとともに、リアルタイムOSは、「ハイパーバイザを介して」前記制御装置に対する電源供給が停止されても問題ないことを通知する信号を出力するようにすること、すなわち、本件特許発明1の相違点1、2、4、5に係る構成とすることは、当業者が容易に想到し得たことであるとはいえない。
(キ)したがって、他の相違点を検討するまでもなく、本件特許発明1は、当業者であっても甲1発明、甲2号証〜甲5号証に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

ウ 特許異議申立人伊藤裕美は、異議申立書において以下の点を主張する。
「甲5発明の事項(ネ)で示したように、vSphere Management Assistant(vMA)は、仮想アプライアンスベースのコマンド実行環境である。仮想アプライアンスとは、仮想化技術を用いて、特定用途のアプリケーションソフトが稼働する環境を即座に構成できるようにしたものであり、仮想マシンのイメージファイルなどとして提供される。つまり、vMAは、ハイパーバイザ上で動作するOSのアプリケーションに相当する。
甲5発明の事項(ヒ)には、vMAが、ゲストOSをシャットダウンして、仮想マシンを停止できることが記載されている。つまり、甲1発明の事項(ト)は、本件特許発明(1G)の「前記リアルタイムOSは、…中略…、前記ユーザプログラムに対してシャットダウンを指示するとともに、」に相当する。
甲5発明の事項(ハ)には、vMAが、仮想マシン上のゲストOSが正しく起動できたか否かをハートビートで確認できることが記載されている。仮想マシン上のゲストOSが正しく起動できたか否かの確認は、裏返すと、仮想マシン上のゲストOSがシャットダウンされたか否かの確認でもある。つまり、甲5発明の事項(ハ)は、本件特許発明(1G)の「前記リアルタイムOSは、…中略…、前記ユーザプログラムがシャットダウンされたことを示す条件が成立すると、」に相当する。」(異議申立書第23/31ページ)
しかしながら、「vSphere Management Assistant (vMA)」は、VMwareのvSphere(ハイパーバイザ)において、Linuxベースのサービスコンソールに代替して提供されるコマンド実行環境であって、ハイパーバイザ上で動作するOSのアプリケーションではなく、異議申立人の上記主張は、vMAがハイパーバイザ上で動作するOSであることを前提として、vMAを「リアルタイムOS」に対応させて対比していることから、その前提において誤りがあり、かかる主張には理由がない。

(2)本件特許発明2〜6について
本件特許発明2〜6は、本件特許発明1に対して、さらに請求項2〜6に記載された技術的事項を追加したものであるから、本件特許発明2〜6と甲1発明を対比すると、少なくとも上記相違点1〜5が認められる。
よって、上記(1)に示した理由と同様の理由により、本件特許発明2〜6は、甲1発明及び甲2号証〜甲5号証に記載された技術的事項に基づいて当業者が容易になし得るものではない。

(3)本件特許発明7について
本件特許発明7は、本件特許発明1に対応する制御方法の発明であり、本件特許発明7の《7B》は、本件特許発明1の《1C》及び《1D》に対応し、本件特許発明7の《7C》、《7D》、《7E》は、それぞれ本件特許発明1の《1Fa》、《1Fb》,《1Fc》に対応する構成である。
してみれば、本件特許発明7と甲1発明とを対比すると、上記相違点1〜5と同様の相違点が認められる。
よって、上記(1)に示した理由と同様の理由により、本件特許発明7は、当業者であっても甲1発明、甲2号証〜甲5号証に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

(4)本件特許発明8について
本件特許発明8は、本件特許発明1におけるリアルタイムOSに対応するプログラムの発明であり、本件特許発明8の《8B》は、本件特許発明1の《1C》及び《1D》に対応し、本件特許発明7の《8Ca》、《8Cb》、《8Cc》は、それぞれ本件特許発明1の《1Fa》、《1Fb》,《1Fc》に対応する構成である。
してみれば、本件特許発明7と甲1発明とを対比すると、上記相違点1〜5と同様の相違点が認められる。
よって、上記(1)に示した理由と同様の理由により、本件特許発明8は、当業者であっても甲1発明、甲2号証〜甲5号証に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

(5)以上のとおり、本件特許発明1〜8は、甲1発明及び甲2号証〜甲5号証に記載された技術的事項に基いて当業者が容易に発明をすることができたものではない。

6 むすび
したがって、特許異議の申立ての理由及び証拠によっては、請求項1〜8に係る特許を取り消すことはできない。
また、他に請求項1〜8に係る特許を取り消すべき理由を発見しない。
よって、結論のとおり決定する。
 
異議決定日 2022-07-26 
出願番号 P2016-077606
審決分類 P 1 651・ 121- Y (G06F)
最終処分 07   維持
特許庁審判長 稲葉 和生
特許庁審判官 野崎 大進
▲吉▼田 耕一
登録日 2021-11-04 
登録番号 6971016
権利者 オムロン株式会社
発明の名称 制御装置、制御方法およびプログラム  
代理人 特許業務法人深見特許事務所  
  • この表をプリントする

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