【事件の表示】
　平成　６年特許願第１４８６４５号「デジタル式カオス信号による情報の隠蔽・復号化方法および装置」拒絶査定に対する審判事件［平成　７年１２月２２日出願公開、特開平　７−３３４０８１］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯および本願発明
　
　本願発明は平成６年６月７日の出願であって、「デジタル式カオス信号による情報の隠蔽・復号化方法」に関するものと認める。
　
　
２．原査定の理由
　
　一方、原査定の拒絶の理由の概要は、次のとおりである。
　
「２、この出願は、明細書及び図面の記載が下記の点で、特許法第３６条第４項又は５項又は第６項に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　　記
　
　請求項の記載は暗号化及び復号化が初期値とカオス関数の他に遅れも基づいているがこれらに基づいてどのように行われるのか不明瞭である(特に「遅れ」がどのようなもので、そして、この「遅れ」に基づいてどのように行われるのか不明瞭である)。
　発明の詳細な説明及び図面を見ても暗号化復号化の仕方が不明瞭である。
(例えば、鍵、遅れ、カオス信号ベクトル、初期値の生成、カオス関数間の関係、これらのシーケンス等が不明瞭である。また遅れの定義が不明である。図面との関係が不明瞭である。
さらに、初期値を生成する関数f(K)のなかでwを生成するstrtoul(K(j))なる関数の説明が不明瞭である。また、第３図、第４図のシーケンスが不明瞭である(特にカオス関数Ｃｈ（ｉ），Ｃｈ（ｉ＋delay)について特に不明瞭である)。)」
　
　
３．原査定の拒絶の理由に応答した審判請求人の意見書および手続補正書
　
　これに対して、審判請求人は平成８年６月５日付けで意見書および手続補正書を提出し、その意見書において、原査定の拒絶の理由に対して、
　
「本発明の方法では　暗号化するとき、平文信号P(i)に同期なカオス関数の信号Ch(i)を付加するわけではなく、d期後のカオス信号、即ちCh(i+d)を使う。このｄは「遅れ（delay）」と言う。本発明でこの遅れ（delay）はユーザが指定されたキーによって決められるものである。この遅れ（delay）を導入することで、たとえ解読者が暗号文からカオス信号値Ch()が分かってもその中の遅れ（delay）を推測できないので暗号文から使った暗号キーを割り出すことを有効に防止することができる。これは本発明の安全強度を保証できる理由の１つである。」および
　
「特許法第３６条第４項又は５項又は６項に規定する要件を満たしていないとされた点については、「遅れ」と「delay」の２種類の言葉が使用されていたが、
　これは審査官殿のご認定どおり同一のことがらを指しているので、用語を「遅れ（delay）」に統一してこの点を明確にする補正を行った。さらに数１で用いられている関数「strtoul」については、Ｃ言語の標準として準備されている関数であり、その説明を補充した。また、図３と図４のシーケンスが不明瞭であるとの点については、表現を一部変更することで明らかにした。」旨の主張をしている。
　
　
４．当審の判断
　
　そこで、平成８年６月５日付けで提出された意見書および手続補正書によって、記載不備が解消されたか否かを検討するに、
　
イ）審判請求人は、出願当初明細書の請求項１乃至４に記載された「遅れ」を、「遅れ（ｄｅｌａｙ）」と補正すると共に、この「遅れ（ｄｅｌａｙ）」に対して、
　「本発明でこの遅れ（ｄｅｌａｙ）はユーザが指定されたキーによって決められるものである」と主張し、更に、本願明細書の第【００１２】段落および【図３】を、該主張に合わせる形で補正している。
　
　次に、上記「遅れ（ｄｅｌａｙ）」に関連して補正された本願明細書請求項１乃至４（以下、「本願明細書請求項」及び「請求項」と言った場合、補正後のものを指す）を参照すると、該請求項１乃至４には、
　「指定された文字列により構成された鍵によって決められたカオス関数、該カオス関数の初期値および遅れ（ｄｅｌａｙ）に基づいて生成されたカオス信号と演算処理する」
と記載されている。
　
　しかしながら、この記載は係り受け関係が不明瞭であり、上記指摘の記載中の「と演算処理」の前段の記載において、少なくとも以下の５通りの場合に解釈でき、
イ）の１“「指定された文字列により構成された鍵によって決められたカオス関数」、「カオス関数の初期値」および「遅れ（ｄｅｌａｙ）に基づいて生成されたカオス信号」（即ち、「カオス関数」と「カオス関数の初期値」と「遅れ（ｄｅｌａｙ）に基づいて生成されたカオス信号」）”の３つが存在する場合、
　
イ）の２“「指定された文字列により構成された鍵によって決められたカオス関数」、「カオス関数の初期値」、「遅れ（ｄｅｌａｙ）」とに基づいて生成された「カオス信号」である場合（即ち、「カオス関数」、「初期値」、「遅れ（ｄｅｌａｙ）」から「カオス信号」を生成する場合）”、
　
イ）の３“「指定された文字列により構成された鍵によって決められた」、「カオス関数」、「初期値」および「遅れ（ｄｅｌａｙ）」（即ち、「指定された文字列により構成された鍵によって決められたカオス関数」、「指定された文字列により構成された鍵によって決められた初期値」および「指定された文字列により構成された鍵によって決められた遅れ（ｄｅｌａｙ）」）に基づいて生成された「カオス信号」”である場合、
　
イ）の４“「指定された文字列により構成された鍵によって決められた」、「カオス関数」、「初期値」および「遅れ（ｄｅｌａｙ）に基づいて生成されたカオス信号」（即ち、「指定された文字列により構成された鍵によって決められたカオス関数」、「指定された文字列により構成された鍵によって決められた初期値」および「指定された文字列により構成された鍵によって決められた遅れ（ｄｅｌａｙ）に基づいて生成されたカオス信号」）”である場合、
　
　さらにイ）の１に関しては、「カオス関数」と「遅れ」及び「カオス関数」、「初期値」及び「遅れ」と「カオス信号」との係り受け関係を考慮すると、
　
イ）の５ “「指定された文字列により構成された鍵によって決められたカオス関数」、「カオス関数の初期値および遅れ（ｄｅｌａｙ）」に基づいて生成された「カオス信号」が（「カオス関数」と「カオス関数の初期値」と「カオス関数の遅れ」に基づいて生成された「カオス信号」）”の関係であると解釈される場合、
　
その何れの場合であるか、特定することができず、特許法第３６条第５項第２号に規定された要件を満たしていない。
　
　次に、上記何れかの場合であったとして、請求項１乃至４の記載内容が明瞭であるかについて、更に検討するに、
　
　
ａ）イ）の１の場合
　
　この場合、請求項各項において、「鍵」によって決められるのは「カオス関数」である。
　
　しかしながら、本願の明細書発明の詳細な説明の欄及び図面を参照すると、明細書第【００１７】段落に、
「カオス発生関数Ｃｈ（）については、各種のカオス関数を入れ換えることが可能である。例えば、ロジステック写像と呼ばれるｃｈａｏｓを次のように示す
Ｃｈ（ｎ）
　ｂｉｇｉｎ
　　　Ｘｎ＋１＝ａ＊Ｘｎ（１．０−Ｘｎ）　（２．５＜ａ＜４．０）
　　　ｒｅｔｕｒｎ　Ｘｎ＋１
　ｅｎｄ
また、繰り返し公式によるカオス関数ならば次のように示す
Ｃｈ（ｎ）
　ｂｉｇｉｎ
　　　Ｘｎ＋１＝Ｘｎ２−ａ
　　　ｒｅｔｕｒｎ（（Ｘｎ＋１＋２）／４）　（１．５＜ａ＜２）
　ｅｎｄ」
と記載されていて、この記載内容から読み取れることは、単に、「カオス関数」には複数あり、その何れを用いても構わない程度のものであって、「鍵」よって、「カオス関数」を選択する構成を示唆しているとは認められない。
　また、第【００１７】段落の上記指摘箇所に引き続いて、
「初期値関数ｆ（）は鍵Ｋからカオス関数の初期値を生成する関数である。使われるカオス関数の要求に合わせなければならない。例えば０．０〜１．０のダブル・ロート型初期値を生成する関数を次のように示す」と記載されていて、
　この記載によれば、使われる「カオス関数」の要求に合わせるのは、「鍵」から「初期値」を生成する方であり、「鍵」によって「カオス関数」を決めている訳ではない。
　そして、「鍵」による「カオス関数」の決める点に関しては、請求項各項と補正された明細書第【００１２】段落に請求項と同一の記載があるのみで、その他の明細書の記載内容及び図面を参照しても、「鍵」から「カオス関数」を決めている点が記載されているとは認められない。
　一方、補正された明細書の発明の詳細な説明の欄および図面においては、その第【００１２】段落に、「本発明でこの遅れ（ｄｅｌａｙ）はユーザが指定されたキーによって決められる」と記載され、また、【図３】には「キーから　カオス関数の初期値ｉｎｔ、遅れ　ｄｅｌａｙ、を生成する」と記載されていて、本願明細書において、「鍵」と「キー」が同一のものであるとすれば、本願明細書発明の詳細な説明の欄及び図面において、「鍵」によって決められるのは「遅れ（ｄｅｌａｙ）」或いは「初期値」であって、「カオス関数」ではない。
　
　したがって、イ）の１の場合、本願明細書の請求項の記載内容と、発明の詳細な説明の欄及び図面との記載に内容が対応しておらず、特許法第３６条第５項第１号に規定された要件を満たしていない。
　
　また、請求項１乃至４に記載された「鍵によって決められたカオス関数」がどのように行われているか、本願明細書発明の詳細な説明の欄および図面を参照しても不明であるから、結果として、「初期値」と「カオス関数」と「遅れ（ｄｅｌａｙ）」からどのようにして「平文情報」の「隠蔽化」が行われているか不明である。
　したがって、請求項１乃至４に記載された上記指摘箇所の記載内容をイ）の１の如く解釈した場合は、該請求項１乃至４の記載内容は、本願明細書発明の詳細な説明の欄および図面の記載内容と対応しておらず、かつ記載された内容自体も不明瞭であって、特許法第３６条第５項第１号および同第２号に規定された要件を満たしていない。
　
　
ｂ）イ）の２の場合
　
　この場合も、請求項各項において、「鍵」によって決められるのは「カオス関数」である。
　よって、上記項目ａ）で指摘したとおり、本願明細書の請求項の記載内容と、発明の詳細な説明の欄及び図面の記載内容とが対応しない。
　また、上記項目ａ）示したように、どのように「鍵」によって「カオス関数」を決定しているか不明であり、結果として、「初期値」、「カオス関数」および「遅れ（ｄｅｌａｙ）」からどのようにして「平文情報」の「隠蔽化」が行われているか不明である。
　したがって、請求項１乃至４に記載された上記指摘箇所の記載内容をイ）の２の如く解釈した場合は、該請求項１乃至４の記載内容が不明瞭であり、かつ、本願明細書発明の詳細な説明の欄および図面の記載内容と対応していないので、特許法第３６条第５項第１号および同第２号に規定された要件を満たしていない。
　
　
ｃ）イ）の３の場合
　
　この場合は、「鍵」によって決められるのは「カオス関数」、「初期値」、「遅れ（ｄｅｌａｙ）」であり、この３つの要素を用いて「カオス信号」を生成していると読み取れる。
　そして、上記項目ａ）で指摘したように、本願明細書発明の詳細な説明の欄および図面には、「鍵」によって「初期値」および「遅れ（ｄｅｌａｙ）」を決める点は記載されている。
　しかしながら、同じく上記項目ａ）で指摘したようのに、「鍵」によって「カオス関数」を決める点は、どのように実現しているか不明である。
　加えて、本願明細書第【００１７】段落乃至第【００２０】段落に「鍵Ｋからカオス関数の初期値を生成する」「初期値関数ｆ（）」が記載されていて、特に【００２０】段落に「このようにして、ｗ／Ｌの整数部を遅れ（ｄｅｌａｙ）に、ｗ／Ｌの小数部をカオス信号の初期値にする」と記載されているが、上記指摘の本願明細書第【００１８】段落乃至第【００２０】段落の「初期値関数ｆ（）」の処理過程からは、「遅れ（ｄｅｌａｙ）」を求める点は、「ｄｅｌａｙ＝ｉｎｔ（ｗ／Ｌ）」より読み取れるものの、「初期値」を求める点については、該処理過程中には、初期値を指し示す箇所が見当たらず、また、該「ｆ（）」からどのようにして第【００２０】段落でいう「ｗ／Ｌの小数部をカオス信号の初期値」として取り出しているのか不明であり、結局のところ、該「ｆ（）」の式からどのようにして「初期値」を決定しているか不明瞭である。
　また、ここで求めた、「初期値」および「遅れ（ｄｅｌａｙ）」から「カオス信号」を生成する点に関しては、本願明細書第【００１２】段落並びに【図３】に記載されているが、これらの記載をみても、「鍵」によって「カオス関数」を決める処理と、「鍵」から「初期値」および「遅れ（ｄｅｌａｙ）」を決める処理がどのように関連し、それによって最終的に、これら３つの要素からどのようにして「カオス信号」を生成しているか不明である。
　そして、この点は本願明細書の上記指摘箇所以外の記載及び図面を併せて参照しても解消しない。
　したがって、請求項１乃至４に記載された上記指摘箇所の記載内容をイ）の３の如く解釈した場合は、該請求項１乃至４の記載内容が不明瞭であって、特許法第３６条第５項第２号に規定された要件を満たしていない。
　
　
ｄ）イ）の４の場合
　
　この場合は、「鍵」によって決められるのは「カオス関数」、「初期値」および「遅れ（ｄｅｌａｙ）」であり、また、「カオス信号」は「遅れ（ｄｅｌａｙ）に基づいて生成される」と読み取れる。
　しかしながら、上記項目ａ）で指摘したように、どのように「鍵」から「カオス関数」を決定しているか、本願明細書発明の詳細な説明の欄および図面の記載を参照しても不明である。
　また、上記項目ｃ）で指摘したように、本願明細書発明の詳細な説明の欄および図面の記載においては、「カオス信号」は「初期値」と「遅れ（ｄｅｌａｙ）」に基づいて生成されるものであり、「遅れ（ｄｅｌａｙ）」のみによって「初期値」が生成されている訳ではない。
　したがって、請求項１乃至４に記載された上記指摘箇所の記載内容をイ）の４の如く解釈した場合は、該請求項１乃至４の記載内容が不明瞭であり、かつ、本願明細書発明の詳細な説明の欄および図面の記載内容と対応しておらず、特許法第３６条第５項第１号および同第２号に規定された要件を満たしていない。
　
ｅ）イ）の５の場合
　
　この場合も、請求項各項において、「鍵」によって決められるのは「カオス関数」である。
　よって、上記項目ａ）で指摘したとおり、本願明細書の請求項の記載内容と、発明の詳細な説明の欄及び図面の記載内容とが対応しない。
　また、上記項目ａ）示したように、どのように「鍵」によって「カオス関数」を決定しているか不明であり、結果として、「初期値」、「カオス関数」および「遅れ（ｄｅｌａｙ）」からどのようにして「平文情報」の「隠蔽化」が行われているか不明である。
　したがって、請求項１乃至４に記載された上記指摘箇所の記載内容をイ）の２の如く解釈した場合は、該請求項１乃至４の記載内容が不明瞭であり、かつ、本願明細書発明の詳細な説明の欄および図面の記載内容と対応していないので、特許法第３６条第５項第１号および同第２号に規定された要件を満たしていない。
　
　
　上記項目イ）および項目ａ）乃至ｅ）に示したように、補正された請求項１乃至４に記載された内容では、その構成に関して複数の場合が読み取れ、一意に特定することができず、また、複数解釈できるうちの、何れか一つであるとして、検討しても、そのどの場合においても、請求項各項の記載内容が、発明の詳細な説明と対応しないか、或いは、請求項各項の記載内容から、当該請求項の記載内容によって示そうとしている発明の構成が明瞭であるとは認められず、本願明細書の請求項の記載内容は補正後も依然として不明瞭であって、特許法第３６条第５項第１号および第２項または同第２号に規定された要件を満たしていない。
　
　
ロ）審判請求人は、出願当初明細書の第【００１９】段落以降に記載された【数１】における「ｓｔｒｔｏｕｌ」に対して、
「数１におけるｓｔｒｔｏｕｌ（）はＣ言語に準備されている標準関数であり、「文字列をｕｎｓｉｇｎｅｄ　ｌｏｎｇ型の数値に変換する」という意味をもつ」と説明を付加する形で補正を行うと共に、
　「さらに数１で用いられる「ｓｔｒｔｏｕｌ」については、「Ｃ言語の標準として準備されている関数であり、その説明を補充した」ので不明瞭は解消した」旨主張している。
　
　そこで、上記補正および主張の内容に沿って検討するに、
　「ｓｔｒｔｏｕｌ」がＣ言語における標準関数のひとつであることは、審判請求人の主張を待つまでもなく自明の事項である。
　
　この上記「ｓｔｒｔｏｕｌ」を含む【数１】に記載された関数ｆ（）について、これが数式、即ち“数学の式”であるとして記載内容が明瞭であるか否かを検討すると、
　当該式中に含まれる「Σ」に関して、数学上において「Σ」の意味するところは、「Σｑ（ｉ）（ｉ＝１〜ｎ）であれば、数学にける関数ｑ（ｉ）の変数ｉに１からｎまでの数字を代入し、得られた結果の総和を取る」というものである。
　しかしながら、これはあくまで、数学上の話であって、「Σ」が数学における関数ｑ（ｉ）と組み合わされた場合に成り立つ事項である。
　ところが、本願明細書では、「Σ」とともに用いられているのは、Ｃ言語の関数の「ｓｔｒｔｏｕｌ」である。
　ここで、Ｃ言語における関数とは、Ｃ言語を用いてプログラムを構築した際に、そのプログラムを実行することによって実現される“機能”を指すものであって、数学上の関数とは全く異なるものである。
　そして、この数式ｆ（）において、Ｃ言語における標準関数の一つである「ｓｔｒｔｏｕｌ」を何らかの数学上の関数として用いるための定義は、本願明細書および図面中に何ら記載されていない。
　また、Ｃ言語において、プログラムで実現すべき特定の“機能”を表す「ｓｔｒｔｏｕｌ」と、数学の記号である「Σ」とを、組み合わせたところで、何らかの意味のある“数学の式”を表現できないことは、当業者にとっては自明の事項である。
　よって、【数１】に記載された事項を“数学の式”と解釈した場合、該【数１】は“数学の式”としての要件を満たしておらず、どのような処理を行う“数学の式”が記載されているか不明である。
　
　次に、【数１】がプログラム様に記載され、審判請求人が「「ｓｔｒｔｏｕｌ」については、Ｃ言語の標準として準備されている関数であり」と主張していることから、この【数１】に記載された事項が、明細書中では参考情報として扱われるプログラムリストであると解釈して、記載内容が明瞭であるかについても検討すると、
　「ｓｔｒｔｏｕｌ」は、Ｃ言語における標準関数ではあるが、Ｃ言語で記載されたプログラムはｍａｉｎ（）という関数（Ｃ言語における）で始まり、「ｂｅｇｉｎ」、「ｅｎｄ」という表記は用いない。
　また、Ｃ言語といわず、数学における「Σ」が示す演算を、コンピュータで実現するためにプログラムにする場合、単純に「Σ」と書いただけで実現できる訳ではなく、特にＣ言語の場合、もし、表記として使用可能であるとしても、「Σ」がＣ言語の標準関数でない以上、数学上の「Σ」の処理を単純にＣ言語のプログラムで表現した場合、
　例えば「椋田實著　＜初めての“Ｃ”＞技術評論社　昭和６１年５月１０日初版第９刷発行」の第２０頁などにも記載されているように、
「main()
  { 
     }
  ｝
 
  sigma(i)
  {
      }
  }」と、「Σ」の処理だけで複数行に渡る。
　これをＣ言語上の関数として「Σ」のみで示すためには、その旨をプログラムリスト上の何れかで定義しなければならない。
　しかしながら、そのような定義は本願明細書発明の詳細な説明の欄および図面の何れを参照しても記載されていない。
　よって、【数１】をＣ言語によるプログラムリストと解釈した場合、該【数１】はＣ言語のプログラムリストとしての要件を満たしておらず、どのような処理を実現するプログラムが記載されているか不明である。
　したがって、審判請求人の主張どおり、「ｓｔｒｔｏｕｌ」をＣ言語における標準関数とした場合、【数１】に記載された内容は、“数学の式”と解釈した場合および“Ｃ言語によるプログラムリスト”と解釈した場合の何れの場合においても記載された内容が不明であるから、
　本願明細書の発明の詳細な説明の欄が、その発明の属する技術の分野における通常の知識を有する者が容易にその実施が出来る程度に記載されているとは認めらず、特許法第３６条第４項に規定された要件を満たしていない。
　
　
（なお、平成８年６月５日付け手続補正書で補正された以下に指摘の事項は、出願当初の明細書および図面の記載から直接且つ一義に導き出せない事項である。
　＜ｉ＞補正された請求項各項および第【００１２】段落に記載された「指定された文字列により構成された鍵によって決めされたカオス関数」：
“カオス関数”を“鍵”によって決める点は出願当初の明細書および図面には何ら記載されておらず、また、当業者が自明の事項でもない。
＜ii＞補正された第【００１２】段落に記載された「即ちＣｈ（ｉ＋ｄ）を使う。このｄを「遅れ（ｄｅｌａｙ）とよぶ。本発明でこの遅れ（ｄｅｌａｙ）はユーザが指定されたキーによって決められる」：
“ｄｅｌａｙ”および“遅れ”はそれぞれ別個に出願当初の明細書中に記載されているが、これらを結びつける記載は出願当初の明細書にはない。また、“ｄ”に関しては記載すらない。また、本願明細書中における“遅れ”或いは“ｄｅｌａｙ”は一般的な意味での“遅れ”とは異なる。したがって、このような補正を行うことが当業者自明の事項とは認められない。）
　
　
５．むすび
　
　以上のとおりであるから、本願明細書は請求項及び発明の詳細な説明の欄の記載内容が依然として不明瞭であり、また、本願明細書請求項の記載内容と、同発明の詳細な説明の欄および図面の記載とが対応していないので、特許法第３６条第４項もしくは第５項および第６項の規定に違反するものであって、特許を受けることができない。
　
　よって、結論のとおり審決する。
　なお、平成１０年６月１日付手続補正書は当該審決と同日付で補正却下の決定がなされた。