【事件の表示】
　平成　５年特許願第１６４８２５号「計算機システム」拒絶査定に対する審判事件〔平成　７年　１月２４日出願公開、特開平　７−　２１０４０、請求項の数（４）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
１．手続の経緯・本願発明
　本願は、平成５年７月２日の出願であって、その請求項１乃至４に係る発明は、手続補正により補正された明細書および図面の記載からみて、特許請求の範囲の請求項１乃至４に記載された以下のとおりのものである。
「【請求項１】複数のタスクを備え、中央演算処理装置が前記各タスクそれぞれの優先度に応じて時分割に共用されるように、前記各タスクのスケジューリングを行う計算機システムにおいて、前記複数タスクのうちの、前記中央演算処理装置の割り当て待ちの状態にあるものの待ち時間を監視する待ち時間監視部と、前記待ち時間監視部によって前記待ち時間が所定の上限値を超えたタスクが検出された場合に、タスクのスケジューリングを長待ち時間順に行う待ち時間制御部と、前記待ち状態にある全てのタスクの待ち時間が前記上限値よりも短い場合に、タスクのスケジューリングを高優先度順に行う優先度制御部とを備えたことを特徴とする計算機システム。
【請求項２】複数のタスクを備え、中央演算処理装置が前記各タスクそれぞれの優先度に応じて時分割に共用されるように、前記各タスクのスケジューリングを行う計算機システムにおいて、前記複数のタスクのうちの、前記中央演算処理装置の割り当て待ちの状態にあるものの待ち時間を監視する待ち時間監視部と、前記待ち時間監視部によって前記待ち時間が所定の上限値を超えたタスクが検出された場合に、タスクのスケジューリングを長待ち時間順と高優先度順とで交互に行う待ち時間優先度制御部と、前記待ち状態にある全てのタスクの待ち時間が前記上限値よりも短い場合に、タスクのスケジューリングを高優先度順に行う優先度制御部とを備えたことを特徴とする計算機システム。
【請求項３】前記上限値を、指定されたモードに応じて設定する上限値設定部を設けたことを特徴とする請求項１または２に記載の計算機システム。
【請求項４】前記上限値を前記各タスク毎に、当該タスクの優先度と所定の計算式を用いて決定する上限値決定部を設けたことを特徴とする請求項１または２に記載の計算機システム。」
　
１． 原査定の拒絶の理由
　原査定の拒絶の理由は、
「この出願は、明細書及び図面の記載が下記の点で、特許法第３６条第４項、第５項及び第６項に規定する要件を満たしていない。
　　　　　　　　　　記
１．発明の詳細な説明には、下記の記載不備がある。
（１）明細書第３０コラムの「監視優先度順」という記載の意味するところが不明である（長待ち時間順のことか？）。
（２）明細書第３０コラムの「監視優先度順」という記載を、「長待ち時間順」という意味であると解釈すると、待ち時間が基準値を越えるタスクが複数あった場合には、「長待ち時間順」のスケジューリング手法が連続して採用されることもある（第６図のフローチャートのＳＴ４０→ＳＴ４３→ＳＴ４５→ＳＴ４６→ＳＴ４７→ＳＴ４９という経路が連続して辿られることにより）から、必ずしも明細書第２５コラムにあるような「交互に」という動作はせず、したがって、明細書第２５コラムの「交互に」という記載は、第６図のフローチャートと矛盾している。
（３）明細書第３３コラムの「タスク毎設定が・・・最低優先度のタスクに指定された最大の待ち時間」という記載において、「最大の」という記載の意味するところが不明である（何の中で最大か？）。
２．特許請求の範囲には、下記の記載不備がある。
（１）請求項２の「交互に行う」という記載は、発明の詳細な説明と対応が取れていない（詳細については、上記１．の（２）で述べたことと同様）。
（２）請求項３、４は請求項２を引用して記載されているので、上記２．の（１）と同様の記載不備がある。」
というものであり、
　また、拒絶の査定の備考欄には、
「・１．（２）について
　出願人は意見書において「キューイングされたタスクの実行時間」という意味不明の用語を用いているが、これは「キューイングされたタスクの待ち時間」の意味であるものと解釈する。
　キューイングされたタスクの待ち時間が待ち上限値よりも小さい場合には、第５図の待ち時間監視部２の動作は第３図のＳＴ２０→ＳＴ２１→ＳＴ２２→ＳＴ２３→ＳＴ２５→ＳＴ２０というループをたどるので、制御状態フラグは優先度順を示す値のままであり、したがって第６図のフローチャートではＳＴ４０の判定でＹＥＳになるから、キューイングされたタスクの待ち時間が待ち上限値よりも小さい場合には常に高優先度順のスケジューリングが行われることとなり、出願人が意見書でいうような「交互に動作」などということは、おこらない（そもそも、待ち時間が上限値を越えた場合でも交互に動作しないのではないかという拒絶理由の指摘に対し、待ち時間が上限を越えていない場合を例にとって意見書で説明しようとする（しかも、その説明が誤っているのは上述のとおり）のは、回答になっていないのではないのか？）。
　したがって、１．（２）で指摘した記載不備は、依然として解消されていない。
・１．（３）について
　補正後の第３３コラムの「最低優先度のタスクが複数あった場合に、その中で設定された待ち時間の最大」という記載は、出願当初の明細書及び図面の具体的にどの箇所の記載に基づいて自明であるといえるのか、根拠が不明である（次回、根拠の説明がなされなければ補正却下するので、注意されたし）。
・２．（１）、（２）についても、上述したことと同様であり、記載不備は依然として解消されていない。
　なお、明細書第２６コラムの「監視高優先度順」という記載（同様の記載は、第６図のＳＴ４７にもある）の意味するところも不明であるから、注意されたし。」と指摘している。
　
３．当審の判断
　上記の各点について審理すると、
（１） 理由の１．（１）について
　【００２６】には、「この実施例２における…制御状態フラグ１１は、スケジューリング状態の識別情報として前記優先度制御部１による高優先度順、あるいは前記待ち時間優先度制御部６による長待ち時間順もしくは監視高優先度順のいずれかを識別する情報を持つ。」と記載されており、実施例２における制御状態フラグ１１には、「優先度制御部１による高優先度順」、「待ち時間優先度制御部６による長持ち時間順」及び「待ち時間優先度制御部６による監視高優先度順」の３つの識別情報があることが明らかである。
　実施例２について説明された【００３０】及び図６では、これら３つの制御状態フラグを用いて制御を行うことが記載されていると認められ、この「監視優先度順」は、制御状態フラグが識別する「高優先度順」、「長持ち時間順」及び「監視高優先度順」の３つの識別情報のうちの第３のものである「待ち時間優先度制御部６による監視高優先度順」に対応していることは、発明の詳細な説明及び図面の記載から明らかであると認められる。
　また、発明の詳細な説明及び図面の記載において、「優先度順」という用語と「高優先度順」という用語は、区別無く、混同して使用され、「高」という表現に特別の意味は無いように使われており、「優先度順」は、正確には「高優先度順」の誤記であることが明らかであり、同様に「監視優先度順」が、正確には「監視高優先度順」の誤記であることも明らかであると認められる。
　したがって、発明の詳細な説明には、「明細書第３０コラムの「監視優先度順」という記載の意味するところが不明である（長待ち時間順のことか？）。」という記載不備はないものと認められる。　
　
（２）理由の１．（２）について
　発明の詳細な説明及び図面の記載において、
　【００２２】には、「この発明の実施例２を図に基づいて説明する。図５は請求項２に記載された発明の一実施例による計算機システムのスケジューリング機能に関する部分を示すブロック図であり、相当部分には図１と同一の符号を付してその説明を省略する。図５において、６は長待ち時間順と高優先度順とで交互にスケジューリングする待ち時間優先制御部である。」と記載されているから、
　請求項２に係る発明が、実施例２に対応すること、及び、この実施例が、長待ち時間順と高優先順とで交互にスケジューリングする待ち時間優先制御部６を備えていることが記載されている。
　
　また、【００２７】において、「次に動作について説明する。なお、この実施例２における待ち時間監視部２の処理は、実施例１のそれと同一であるため詳細な説明は省略するが、図３におけるステップＳＴ２４は制御状態フラグ１１を待ち時間優先度制御部６による長待ち時間順を示す値に更新することに相当する。」と記載があり、
　実施例１の対応する箇所【００２２】には、
「待ち時間監視部２は、一定周期毎に起動されて、…レディ状態にある全タスクの中で最も長い待ち時間が、前記待ち上限時間基準値１９を越えている場合には、ステップ２４で制御状態フラグ１１を待ち時間制御部５の長待ち時間順を示す値に更新した後、ステップＳＴ２５に進む。」と記載されているから、
　実施例２においても、待ち時間監視部２は、最も長い待ち時間が、上限値を超えているときには、３つのフラグのうち、長待ち時間順を示す値にフラグを更新するように構成されていると認められる。
　
　そして、【００２９】には、「また、前記ステップＳＴ４０による判定の結果、制御状態フラグ１１が優先度順（高優先度順の誤記と認める。）を示す値でなければ、待ち時間優先度制御部６が機能し、ステップＳＴ４３で制御状態フラグ１１が長待ち時間順を示す値であるか否かの判定が行われる。その結果、長待ち時間時間順を示す値でなければ、ステップＳＴ４４において、それを次回のスケジューリング状態である長待ち時間順を示す値に更新してステップ４１へ進み、優先度制御部１による優先度順（高優先度順の誤記と認める。）の場合と同様のスケジューリングが行われる。」と記載されているから、
　高優先度順でもなく、長待ち時間順でもない、監視高優先度順の場合には、ステップＳＴ４４で、次回のスケジューリングを、長待ち時間順にセットして、ステップＳＴ４１で、高優先度順の処理を行うことが記載されていると認められる。
　
　また、【００３０】には「一方、…ステップＳＴ４４（ＳＴ４６の誤記と認める。）では、…今回スケジューリングするタスク以外で待ち上限時間基準値１９を越えたタスクが更に存在するか否かを判断する。その結果、存在する場合には、ステップＳＴ４７で次回のスケジューリング状態である監視優先度順（監視高優先度順の誤記と認める。）を示す値で制御状態フラグ１１を更新して、また存在しない場合には、ステップＳＴ４８で次回のスケジューリング状態を優先度順（高優先度順の誤記と認める。）へ復帰させるために、制御状態フラグ１１を優先度順（高優先度順の誤記と認める。）を示す値に変更してステップＳＴ４９に進む。」と記載されているから、
　ステップＳＴ４６において、待ち上限時間基準値１９を越えたタスクが更に存在するか否かを判断して、無くなれば、制御状態フラグを高優先度順に更新して、通常の高優先度順の制御に戻るが、待ち上限時間基準値を超えたタスクが更に存在する場合には、次回のスケジューリング用に、制御状態フラグを監視高優先度順に更新して、長待ち時間順の処理を実行することが記載されていると認められる。
　以上の記載と図６及び図２を参照して、手順を確認すると、
　制御状態フラグが、通常の高優先度順にセットされている場合には、図６の、ＳＴ４０→ＳＴ４１（及びＳＴ４２）→ＳＴ４９を経由して、高優先度順の処理を繰り返すが、待ち時間監視部２が、図２に示すＳＴ２２→ＳＴ２３→ＳＴ２４を経由して、制御状態フラグを長待ち時間順にセットすると、その後は、図６のＳＴ４０→ＳＴ４３→ＳＴ４５を経由して、長待ち時間順の処理の準備を行い、ＳＴ４６で、更に、待ち上限基準値を超えたタスクがある場合には、ＳＴ４７で、次回のスケジュールのために、制御状態フラグを監視高優先度順に更新し、ＳＴ４９で、準備した長待ち時間順の処理を行う。
　続いて、次回のスケジュールのときは、制御状態フラグが監視高優先度順になっているから、ＳＴ４０→ＳＴ４３→ＳＴ４４の経路を進み、次回のスケジュールのために、時間状態フラグを長待ち時間順に更新し、ＳＴ４４→ＳＴ４１（ＳＴ４２）→ＳＴ４９の経路で、高優先度順の処理を行う。
　更に、続いて、次回のスケジュールのときは、図６のＳＴ４０→ＳＴ４３→ＳＴ４５を経由して、長待ち時間順の処理の準備を行い、ＳＴ４６で、更に、待ち上限基準値を超えたタスクがある場合には、ＳＴ４７で、次回のスケジュールのために、制御状態フラグを監視高優先度順に更新し、ＳＴ４９で、準備した長待ち時間順の処理を行う。
　このように、待ち時間優先度制御６のもとで、待ち上限基準値を超えたタスクがある間は、ＳＴ４７とＳＴ４４で制御状態フラグを監視高優先度順と長待ち時間順に切換ながら、長待ち時間順の処理と高優先度順の処理を交互に行うことが開示されていると認められる。
　待ち上限基準値を超えたタスクがなくなれば、ＳＴ４６→ＳＴ４８の経路により、制御状態フラグを高優先度順に更新して、最初の通常の高優先度順の処理に戻るものであり、
請求項２に記載された「待ち時間監視部によって待ち時間が所定の上限値を越えたタスクが検出された場合に、タスクのスケジューリングを長待ち時間順と高優先度順とで交互に行う待ち時間優先度制御部」という構成は、発明の詳細な説明及び図面に記載されていると認められる。
　したがって、発明の詳細な説明には、その一部には誤記があるものの、それは誤記であることが明らかなものであり、また、待ち時間監視部によって待ち時間が所定の上限値を越えたタスクが検出された場合に、タスクのスケジューリングを長待ち時間順と高優先度順とで交互に行う待ち時間優先度制御部の構成が記載されていることは明らかであって、本願の発明の詳細な説明には、「「交互に」という動作はせず、したがって、明細書第２５コラムの「交互に」という記載は、第６図のフローチャートと矛盾している。」という記載不備はないものと認められる。
　　
（３）理由の１．（３）について
　【００３３】の「最低優先度に指定された最大の待ち時間を待ち上限時間基準値１９に設定する」という記載のうちの「最大の」という用語の一般的な意味は、複数のものを比較した場合の最大のものであることは明らかであり、上記の記載が、上限値の設定モードとしてタスク毎設定が指定された場合の説明の記述であるから、「最大の待ち時間」とは、タスク毎設定モードにおいて、最低優先度のタスクが複数あった場合に、その中で設定された待ち時間のうちの最大の待ち時間」を意味することは明らかであると認められる。
　したがって、発明の詳細な説明の記載には、「「最大の」という記載の意味するところが不明である（何の中で最大か？）。」という記載不備はないと認められる。
　
（４）理由の２．（１）及び（２）について
　発明の詳細な説明には、請求項２に係る発明が、実施例２に対応すること、及び、この実施例２が、長待ち時間順と高優先順とでタスクを交互にスケジューリングする待ち時間優先制御部６を備えていることが記載されており、また、発明の詳細な説明及び図面には、請求項２に記載された「待ち時間監視部によって待ち時間が所定の上限値を越えたタスクが検出された場合に、タスクのスケジューリングを長待ち時間順と高優先度順とで交互に行う待ち時間優先度制御部」という記載に対応した具体的な構成が開示されていることは、前記（２）に説示したとおりである。
　したがって、特許請求の範囲には、「（１）請求項２の「交互に行う」という記載は、発明の詳細な説明と対応が取れていない（詳細については、上記１．の（２）で述べたことと同様）。」及び「（２）請求項３、４は請求項２を引用して記載されているので、上記２．の（１）と同様。」という各記載不備はないと認められる。
　
４．むすび
　したがって、この出願は、明細書及び図面の記載が特許法第３６条第４項、第５項及び第６項に規定する要件を満たしていないとした原査定は妥当とはいえない。
  また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。