ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 G06F |
|---|---|
| 管理番号 | 1200259 |
| 審判番号 | 不服2006-17057 |
| 総通号数 | 116 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2009-08-28 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2006-08-07 |
| 確定日 | 2009-07-06 |
| 事件の表示 | 特願2002-553666「大きな文字セットに対応する方法及びシステム」拒絶査定不服審判事件〔平成14年 7月 4日国際公開、WO02/52435、平成17年 1月13日国内公表、特表2005-501303〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
1.手続の経緯 ・本願発明 本願は、2001年10月31日(パリ条約による優先権主張外国庁受理2000年12月27日、米国)を国際出願日とする出願であって、その請求項1に係る発明は、平成18年9月6日付けの手続補正書によって補正された明細書及び図面の記載からみて、本特許請求の範囲の請求項1に記載された次のとおりのものと認める。(以下「本願発明」という。) 「文字を含むファイルを受信するステップと、 該文字が第1のタイプである場合には、前記ファイルを2バイト長の第1のコード形式に変換するステップと、 該文字が第2のタイプである場合には、前記ファイルを2バイト長を2つ用いる第2のコード形式に変換するステップと、 前記第1のコード形式または前記第2のコード形式を用いて、前記ファイルの前記文字を表示するステップと、 文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップと、 文字セットのプレーンが変更されたかどうかを決定するためにチェックするステップと を含んでなる方法。」 なお、上記記載では、その記載中の「文字を含むファイル」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページ」の関係が不明であり、それに伴い、「文字を含むファイルを受信するステップ」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」の関係が不明確となっているが、本審決では、下記(2)の理由で、それらの関係を下記(1)のようなものと解釈した。 (1) 本審決における「文字を含むファイル」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページ」の関係、及び「文字を含むファイルを受信するステップ」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」の関係についての解釈: 「文字を含むファイル」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページ」は、同じものであっても差し支えなく、「文字を含むファイルを受信するステップ」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」も、同じステップであって差し支えない。すなわち、「『文字を含むファイルであって文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページでもあるもの』を受信する単一のステップ」を具備していれば、請求項1でいう「文字を含むファイルを受信するステップ」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」の両方を具備していることになる。 (2)上記(1)の解釈が成り立つ理由 ア.請求項1に「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」なる記載を追加する補正の根拠(平成18年9月6日付けの審判請求書についての手続補正書の「(3)本願発明が特許されるべき理由」の「(C)手続補正書の補正の根拠」の欄の記載参照。)とされている出願当初の請求項2(請求の範囲の翻訳文の請求項2の記載参照。)には、「プレーンと行と列との形式のウェブページを受信するステップを含む請求項1記載の方法。」と記載されているだけであり、該「プレーンと行と列との形式のウェブページを受信するステップ」が請求項1の「文字を含むファイルを受信するステップ」と独立した別のステップであることは記載されていない。 イ.本願発明の実施形態を示す図1(特にブロック10の記載参照)や図3(特にブロック62の記載参照)は、「受信するステップ」としては「『文字を含むファイルであって文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページでもあるもの』を受信する単一のステップ」のみを具備するものと理解される。 ウ.出願当初の明細書及び図面の記載全体を精査しても、「文字を含むファイルを受信するステップ」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」を独立した別のステップとして具備していると解される発明の記載は見当たらない。 2.引用刊行物記載の発明 これに対して、原査定の拒絶の理由に引用された、本願の出願の日前である平成11年10月26日に頒布された「特表平11-512543号公報 」(以下「引用例」という。)には、次の事項が記載されている。 (1) 「技術分野 本発明は記述または表示されるテキストの文字コード間で変換を行うシステムに関し、さらに具体的には、ある文字セットと別の文字セット間で変換を行うコード・コンバータに関する。 背景技術 コンピュータや他のエレクトロニック・デバイスはテキストを使用してユーザと対話するのが一般的である。テキストはモニタや他のタイプの表示デバイスから表示されるのが普通である。テキストはコンピュータや他のエレクトロニック・デバイスの内部ではディジタル形式で表現しなければならないので、文字セット・コード化を使用しなければならない。一般的には、文字セット・コード化は文字セットの各文字を固有のディジタル表現でコード化するように働く。文字(コード化される)は文字、数字および種々のテキスト・シンボルに対応し、コンピュータや他のエレクトロニック・デバイスで使用される数値コードが割り当てられている。」(第23頁第4?14行) (2) 「ソース文字列をターゲット文字列に変換する方法において、 (a)第1の文字コード化を有する前記ソース文字列を受け取り、 (b)前記ソース文字列をテキスト要素に順次分割し、各前記テキスト要素は、前記ソース文字列の文字を1または複数含み、 (c)各前記テキスト要素の第2の文字コード化に関する変換コードをマッピング・テーブルでルックアップし、 (d)前記第2の文字コード化の前記ターゲット文字列を形成するように前記テキスト要素の前記変換コードを結合する ことを特徴とする方法。」(特許請求の範囲1) (3) 「請求項1に記載の方法において、前記マッピング・テーブルは、レギュラ・マッピングとフォールバック・マッピングを含み、 前記ルックアップ(c)は、前記マッピング・テーブルが、前記テキスト要素についての前記レギュラ・マッピングを使用した変換コードを含まない場合は、前記フォールバック・マッピングを使用して各前記テキスト要素の前記変換コードを決定することを特徴とする方法。」(特許請求の範囲4) (4) 「I.定義 1.コード・ポイント:コード・ポイントとは、特定のコード化におけるビット・パターンである。通常、ビット・パターンは1または2バイト以上の長さになっている。ユニコードのコード・ポイントは常に16ビットまたは2バイトである。 2.コード化:コード化とは、文字セットとコード・ポイントのセットとを1対1で対応づけたもの(マッピング)である。例えば、ASCIIコード化はa-ｚ、A-Z、および0-9を含むセットをコード・ポイントｘ00-ｘ7Fに対応づけている。 3.テキスト要素:テキスト要素は特定のオペレーションで1つの単位として扱われる1つまたは2つ以上のコード・ポイントのシーケンスである。例えば、LATIN CAPITAL LETTER Uとその後に続くNON-SPACING DIAERESISは本発明によるコード変換オペレーションの対象となるテキスト要素である(例えば、この例では、2つの隣り合う文字)。 ・・・ 6.フォールバック:フォールバックはソース・コードに正確に等価ではないが、オリジナルの情報の一部を残しているターゲット・コード化内の1つまたは2つ以上のコード・ポイントのシーケンスである。例えば、(C)は、Cを表す可能なフォールバックである。」(第44頁第12行?第45頁第9行)」 ここで、上記記載事項(1)、(2)を技術常識の下に併せ読めば、引用例には、「テキスト要素からなり第1の文字コード化を有するソース文字列を、マッピング・テーブルを用いてターゲット文字列に変換し、該ターゲット文字列を表示デバイスへの表示に用いる」ことが実質的に記載されているといえる。 また、上記記載事項(3)の文脈や技術常識に照らせば、引用例記載のものにおいては、マッピング・テーブルがテキスト要素についてのレギュラ・マッピングを使用した変換コードを含む場合には、当然に、レギュラ・マッピングを使用して各テキスト要素の変換コードを決定するものと考えられる。 以上によれば、引用例には、「テキスト要素からなり第1の文字コード化を有するソース文字列を受け取るステップと、第2の文字コード化に関する変換コードを含むマッピング・テーブルが前記テキスト要素についてのレギュラ・マッピングを使用した変換コードを含む場合には、前記レギュラ・マッピングを使用して各前記テキスト要素の変換コードを決定するステップと、前記マッピング・テーブルが、前記テキスト要素についての前記レギュラ・マッピングを使用した変換コードを含まない場合は、フォールバック・マッピングを使用して前記テキスト要素の変換コードを決定するステップと、前記決定された変換コードによって前記ソース文字列を第2の文字コード化のターゲット文字列に変換し、前記変換されたターゲット文字列を用いて、前記テキスト要素の文字を表示するステップ、を含む方法」の発明(以下、「引用発明」という。)が記載されていると認められる。 3.対比 本願発明と引用発明を対比すると、以下のことがいえる。 (1)引用発明の「テキスト要素からなり第1の文字コード化を有するソース文字列を受け取るステップ」と本願発明の「文字を含むファイルを受信するステップ」は、「文字を含む情報を受信するステップ」である点で共通する。 (2)引用発明の「マッピング・テーブルが前記テキスト要素についてのレギュラ・マッピングを使用した変換コードを含む場合」は、「ソース文字列中のテキスト要素が、レギュラ・マッピング中に存在する場合」に他ならず、「マッピング・テーブルが前記テキスト要素についてのレギュラ・マッピングを使用した変換コードを含まない場合」は、「ソース文字列中のテキスト要素が、レギュラ・マッピング中に存在しない場合」に他ならないから、上記それぞれの場合は、「テキスト要素が第1のタイプである場合」、「テキスト要素が第2のタイプである場合」と呼ぶことができる。また、引用発明において「レギュラ・マッピングを使用して決定される変換コード」は、当然に「フォールバック・マッピングを使用して決定される変換コード」とは異なると考えられるから、該「レギュラ・マッピングを使用して決定される変換コード」により変換されたターゲット文字列を「第1のコード形式」、「フォールバック・マッピングを使用して決定される変換コード」により変換されたターゲット文字列を「第2のコード形式」と呼ぶことができる。 したがって、引用発明の「第2の文字コード化に関する変換コードを含むマッピング・テーブルが前記テキスト要素についてのレギュラ・マッピングを使用した変換コードを含む場合には、前記レギュラ・マッピングを使用して各前記テキスト要素の変換コードを決定するステップ」と本願発明の「該文字が第1のタイプである場合には、前記ファイルを2バイト長の第1のコード形式に変換するステップ」は、「受信したテキスト要素が第1のタイプである場合には、前記受信した情報を第1のコード形式に変換するステップ」である点で共通し、引用発明の「第2の文字コード化に関する変換コードを含むマッピング・テーブルが前記テキスト要素についてのレギュラ・マッピングを使用した変換コードを含まない場合は、フォールバック・マッピングを使用して各前記テキスト要素の変換コードを決定するステップ」と本願発明の「該文字が第2のタイプである場合には、前記ファイルを2バイト長を2つ用いる第2のコード形式に変換するステップ」は、「受信したテキスト要素が第2のタイプである場合には、前記受信した情報を第2のコード形式に変換するステップ」である点で共通する。 以上によれば、本願発明と引用発明との間には、以下の一致点、相違点があるということができる。 (一致点) 文字を含む情報を受信するステップと、 該文字を含むテキスト要素が第1のタイプである場合には、前記ファイルを第1のコード形式に変換するステップと、 該文字を含むテキスト要素が第2のタイプである場合には、前記ファイルを第2のコード形式に変換するステップと、 前記第1のコード形式または前記第2のコード形式を用いて、前記ファイルの前記文字を表示するステップと、 を含んでなる方法。 (相違点1) 受信する「文字を含む情報」が、本願発明では「文字を含むファイル」であるのに対し、引用発明では、該「文字を含む情報」が「文字を含むファイル」かどうか定かでない。 (相違点2) 本願発明では、「文字」が第1のタイプである場合に、文字を含む情報を第1のコード形式に変換し、該「文字」が第2のタイプである場合に、前記文字を含む情報を第2のコード形式に変換するのに対し、引用発明では、「テキスト要素」が第1のタイプである場合に、文字を含む情報を第1のコード形式に変換し、該「テキスト要素」が第2のタイプである場合に、前記文字を含む情報を第2のコード形式に変換する。 (相違点3) 本願発明では、「第1のコード形式」が「2バイト長」であり、「第2のコード形式」が「2バイト長を2つ用いる」ものであるのに対し、引用発明では「第1のコード形式」と「第2のコード形式」にそのような限定がない。 (相違点4) 本願発明は、「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」と、「文字セットのプレーンが変更されたかどうかを決定するためにチェックするステップ」を含むのに対し、引用発明は、それらのステップを有していない。 4.当審の判断 (1)上記相違点について ア.(相違点1)について 情報をファイルの形式で授受することは例示するまでもなく周知であるし、引用発明に、該周知のファイル形式で情報の授受を行う技術を採用出来ない事情も認められないから、引用発明の「ソース文字列」(文字を含む情報)を「文字を含むファイル」とすることは、当業者が容易に推考し得たことである。 したがって、上記相違点1によっては本願発明の進歩性は肯定されない。 イ.(相違点2)について 引用例の上記2.の(2)、(4)の摘記箇所に記載されているように、引用発明でいう「テキスト要素」は、「ソース文字列の文字を1または複数含」むものであり、また、「特定のオペレーションで1つの単位として扱われる1つまたは2つ以上のコード・ポイントのシーケンス」である。そして、該「テキスト要素」を「複数の文字を含むもの」とするか、「単一の文字を含むもの」、すなわち「文字」とするかは、扱うソース文字列の種類によって、当業者が適宜決定すべき事項と考えられるから、引用発明において、該「テキスト要素」を「単一の文字を含むもの」すなわち「文字」とし、「文字」が第1のタイプである場合に、文字を含む情報を第1のコード形式に変換し、該「文字」が第2のタイプである場合に、前記文字を含む情報を第2のコード形式に変換するようにすることも、当業者が容易に推考し得たことである。 したがって、上記相違点2によっても本願発明の進歩性は肯定されない。 ウ.(相違点3について) 拒絶査定の備考欄に「引用文献A」として例示された「P. Hoffman et al., "UTF-16, an encoding of ISO 10646", [online], 2000.02,RFC 2781, [検索日 2006.05.01],インターネット＜URL:http://www.ietf.org/rfc/rfc2781.txt＞」(以下、本件審決においても「引用文献A」と呼ぶ。)の「2. UTF-16 definition」の欄には、以下の記載がある。 「UTF-16 is described in the Unicode Standard, version 3.0 [UNICODE]. ・・・ The rules for how characters are encoded in UTF-16 are: - Characters with values less than 0x10000 are represented as a single 16-bit integer with a value equal to that of the character number. - Characters with values between 0x10000 and 0x10FFFF are represented by a 16-bit integer with a value between 0xD800 and 0xDBFF (within the so-called high-half zone or high surrogate area) followed by a 16-bit integer with a value between 0xDC00 and 0xDFFF (within the so-called low-half zone or low surrogate area).」 上記記載を翻訳すれば、以下のとおりである。 「UTF-16はユニコード標準のバージョン3.0に述べられている。 ・・・ UTF-16における文字のコード化の規則は以下のとおりである。 -0x10000より小さい値を有する文字は、その文字の文字番号と等しい値を有する単一の16ビットの整数値として表現される。 -0x10000と0x10FFFFの間の値を有する文字は、0xDC00と0xDFFFの間(「low-half zone」あるいは「low surrogate area」と呼ばれる範囲内)の値が後続する、0xD800と0xDBFFの間(「high-half zone」あるいは「high surrogate area」と呼ばれる範囲内)の値を有する16ビットの整数値によって表現される。 以上によれば、次のことがいえる。 (ア)「UTF-16」の内容は、相当多数の当業者が参照すると考えられるユニコード標準のバージョン3.0に記載されている上に、やはり相当多数の当業者が参照すると考えられるRequest For Comment(インターネットに関する技術の標準を定める団体であるIETFが正式に発行する文書。)である引用文献Aにも記載されているのであるから、当業者には周知であった。 (イ)「UTF-16」は、文字によって、「2バイト長」のコード形式に変換される場合と、「2バイト長を2つ用いる」コード形式に変換される場合があることを規定している。 そして、上記「UTF-16」に規定される周知の規則を引用発明の「レギュラ・マッピングを使用して各前記テキスト要素の変換コードを決定するステップ」と「フォールバック・マッピングを使用して前記テキスト要素の変換コードを決定するステップ」の部分に採用できない事情は認められない。 また、上記「UTF-16」に規定される周知の規則を引用発明の「レギュラ・マッピングを使用して各前記テキスト要素の変換コードを決定するステップ」と「フォールバック・マッピングを使用して前記テキスト要素の変換コードを決定するステップ」の部分に採用する場合、より単純なコード形式である「2バイト長」のコード形式を「レギュラ・マッピングを使用して各前記テキスト要素の変換コードを決定するステップ」の方に採用し、複雑なコード形式である「2バイト長を2つ用いる」コード形式を「フォールバック・マッピングを使用して前記テキスト要素の変換コードを決定するステップ」の方に採用することは、当業者が当然に考慮することである。 してみれば、引用発明において、上記相違点3に係る本願発明の構成を採用することも、当業者が容易に推考し得たことである。 したがって、上記相違点3によっても本願発明の進歩性は肯定されない。 エ.(相違点4について) 平成20年7月10日の審尋書に添付した前置報告書に「引用文献B」として例示された「”7ビット及び8ビットの2バイト情報交換用符号化拡張漢字集合”,JIS X 0213:2000,財団法人日本規格協会,2000年1月20日,ｐ.50-52,60-64」には、以下の記載がある。 (ア)「e)ビット組合わせ1Bで始まる次の3バイト又は4バイトの列は,制御文字の領域及び図形文字の領域の使用方法の切替えに用いる。」(第60頁下から2行目?下から1行目) (イ)「b)情報交換の途中にこの附属書の4.1e)のバイト列が現れた場合は,4.1e)に示す利用状態の遷移が起こる(附属書2図5参照)」(第62頁第13?14行) (ウ)「1B 24 28 4F以後,制御文字の領域は使用せず,図形文字の領域は,本体6.5.1で規定する漢字集合の1面を表す。」(第62頁第3?4行) (エ)「1B 24 28 50以後,制御文字の領域は使用せず,図形文字の領域は,本体6.5.1で規定する漢字集合の2面を表す。」(第62頁第5?6行) また、同引用文献Bの第61頁の附属書2図1?附属書2図4及び第63頁の附属書2図5には、「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式」が記載されている。 ここで、上記引用文献Bが、所謂JIS規格であり、当然に相当多数の当業者が参照するものであるという事実と、それに上記の事項が記載されているという事実に照らせば、「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式」、及び「該形式を採用するものにおいて、文字セットのプレーンを情報交換の途中で切替えること」は、当業者に周知であったと認められる。また、「ウェブページ」自体は、例示するまでもなく周知であったと認められる。 そして、上記周知の「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式」、「該形式を採用するものにおいて、文字セットのプレーンを情報交換の途中で切替えること」、「ウェブページ」の各事項を、引用発明の「ソース文字列」の部分に採用できない事情も見当たらない。 また、引用発明に上記「該形式を採用するものにおいて、文字セットのプレーンを情報交換の途中で切替えること」なる事項を採用する場合、「文字セットのプレーンが変更されたかどうかを決定するためにチェックするステップ」を設けるべきことは、当業者に自明である。 してみれば、引用発明において、上記相違点4に係る本願発明の構成を採用することも、当業者が容易に推考し得たことである。 したがって、上記相違点4によっても本願発明の進歩性は肯定されない。 (2)本願発明の効果について 本願発明の構成によってもたらされる効果は、引用発明及び上記各周知技術から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。 なお、審判請求人は、平成18年9月6日付けの審判請求書についての手続補正書において、「本願の補正後の請求項1に係る発明は、『文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ』および『文字セットのプレーンが変更されたかどうかを決定するためにチェックするステップ』という発明特定事項を含む点で引用文献1に記載された発明とは相違する。このような『文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ』や『文字セットのプレーンが変更されたかどうかを決定するためにチェックするステップ』という発明特定事項を有するので、本願の請求項1に係る発明は、本願の出願当初の段落0043に記載されているように、『特定の文字に対するフォントは、簡単な計算により、その(プレーン、行、列の)値から又はその代理のユニコード値から直接に配置することができる』ので、段落0032に記載されているマッピングテーブルの巨大化を回避して『メモリのためにプロセッサの速度を犠牲にする』ことを防止できるという、引用文献1では得ることのできない格別な作用効果を奏する。ここでの『簡単な計算』による変換・逆変換の一例が、本願の出願当初の段落0038?0039に記載されている。また、本願の請求項1に記載されているように『文字セットのプレーンが変更されたかどうかを決定するためにチェックする』ことによって、本願の出願当初の段落0050に記載されているように、『新しい文字セットの指定子(以下、「CSG」とよぶ)がMODの変化を示すように挿入され』、『・・・ISO-2022-CN及び拡張版ISO-2022-CN拡張版により定義された文字については、・・・マッピングテーブルを使用してその16ビットのユニコード値をマップする』ことができる。従って、本願の請求項1は、引用文献1に基づいて当業者が容易に想到することができないものと思料する。」旨主張すると共に、平成10年10月28日付けの回答書においても、同旨の主張を行っているが、以下の理由で採用できない。 すなわち、上記請求人が主張する「特定の文字に対するフォントは、簡単な計算により、その(プレーン、行、列の)値から又はその代理のユニコード値から直接に配置することができる」、「マッピングテーブルの巨大化を回避して『メモリのためにプロセッサの速度を犠牲にする』ことを防止できる」、「『新しい文字セットの指定子(以下、「CSG」とよぶ)がMODの変化を示すように挿入され』、『・・・ISO-2022-CN及び拡張版ISO-2022-CN拡張版により定義された文字については、・・・マッピングテーブルを使用してその16ビットのユニコード値をマップする』ことができる」、といった効果は、いずれも、受信した「文字を含むファイル」から「第1のコード形式」や「第2のコード形式」への具体的変換内容がなんら特定されない本願発明によってもたらされる効果とは認められないから、上記請求人が主張する効果をもって本願発明の進歩性を肯定することはできない。 5 むすび したがって、本願発明は、引用例に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法29条2項の規定により特許を受けることができない。 よって、結論のとおり審決する。 |
| 審理終結日 | 2009-02-06 |
| 結審通知日 | 2009-02-10 |
| 審決日 | 2009-02-23 |
| 出願番号 | 特願2002-553666(P2002-553666) |
| 審決分類 |
P
1
8・
121-
Z
(G06F)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 今村 剛、岩間 直純、浜岸 広明 |
| 特許庁審判長 |
小曳 満昭 |
| 特許庁審判官 |
菅原 浩二 立川 功 |
| 発明の名称 | 大きな文字セットに対応する方法及びシステム |
| 代理人 | 松島 鉄男 |
| 代理人 | 奥山 尚一 |
| 代理人 | 有原 幸一 |