【事件の表示】
　特願２００２−５５３６６６「大きな文字セットに対応する方法及びシステム」拒絶査定不服審判事件〔平成１４年　７月　４日国際公開、ＷＯ０２／５２４３５、平成１７年　１月１３日国内公表、特表２００５−５０１３０３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯 ・本願発明
　本願は、２００１年１０月３１日（パリ条約による優先権主張外国庁受理２０００年１２月２７日、米国）を国際出願日とする出願であって、その請求項１に係る発明は、平成１８年９月６日付けの手続補正書によって補正された明細書及び図面の記載からみて、本特許請求の範囲の請求項１に記載された次のとおりのものと認める。（以下「本願発明」という。） 
　「文字を含むファイルを受信するステップと、
　該文字が第１のタイプである場合には、前記ファイルを２バイト長の第１のコード形式に変換するステップと、
　該文字が第２のタイプである場合には、前記ファイルを２バイト長を２つ用いる第２のコード形式に変換するステップと、
　前記第１のコード形式または前記第２のコード形式を用いて、前記ファイルの前記文字を表示するステップと、
　文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップと、
　文字セットのプレーンが変更されたかどうかを決定するためにチェックするステップと
　を含んでなる方法。」
　
　なお、上記記載では、その記載中の「文字を含むファイル」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページ」の関係が不明であり、それに伴い、「文字を含むファイルを受信するステップ」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」の関係が不明確となっているが、本審決では、下記（２）の理由で、それらの関係を下記（１）のようなものと解釈した。
　
（１） 本審決における「文字を含むファイル」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページ」の関係、及び「文字を含むファイルを受信するステップ」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」の関係についての解釈：
　「文字を含むファイル」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページ」は、同じものであっても差し支えなく、「文字を含むファイルを受信するステップ」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」も、同じステップであって差し支えない。すなわち、「『文字を含むファイルであって文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページでもあるもの』を受信する単一のステップ」を具備していれば、請求項１でいう「文字を含むファイルを受信するステップ」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」の両方を具備していることになる。
　
（２）上記（１）の解釈が成り立つ理由
　ア．請求項１に「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」なる記載を追加する補正の根拠（平成１８年９月６日付けの審判請求書についての手続補正書の「（３）本願発明が特許されるべき理由」の「（Ｃ）手続補正書の補正の根拠」の欄の記載参照。）とされている出願当初の請求項２（請求の範囲の翻訳文の請求項２の記載参照。）には、「プレーンと行と列との形式のウェブページを受信するステップを含む請求項１記載の方法。」と記載されているだけであり、該「プレーンと行と列との形式のウェブページを受信するステップ」が請求項１の「文字を含むファイルを受信するステップ」と独立した別のステップであることは記載されていない。
　イ．本願発明の実施形態を示す図１（特にブロック１０の記載参照）や図３（特にブロック６２の記載参照）は、「受信するステップ」としては「『文字を含むファイルであって文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページでもあるもの』を受信する単一のステップ」のみを具備するものと理解される。
　ウ．出願当初の明細書及び図面の記載全体を精査しても、「文字を含むファイルを受信するステップ」と「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」を独立した別のステップとして具備していると解される発明の記載は見当たらない。
　
　
２．引用刊行物記載の発明
　これに対して、原査定の拒絶の理由に引用された、本願の出願の日前である平成１１年１０月２６日に頒布された「特表平１１−５１２５４３号公報 」（以下「引用例」という。）には、次の事項が記載されている。
　
（１）
「技術分野
  本発明は記述または表示されるテキストの文字コード間で変換を行うシステムに関し、さらに具体的には、ある文字セットと別の文字セット間で変換を行うコード・コンバータに関する。
背景技術
  コンピュータや他のエレクトロニック・デバイスはテキストを使用してユーザと対話するのが一般的である。テキストはモニタや他のタイプの表示デバイスから表示されるのが普通である。テキストはコンピュータや他のエレクトロニック・デバイスの内部ではディジタル形式で表現しなければならないので、文字セット・コード化を使用しなければならない。一般的には、文字セット・コード化は文字セットの各文字を固有のディジタル表現でコード化するように働く。文字（コード化される）は文字、数字および種々のテキスト・シンボルに対応し、コンピュータや他のエレクトロニック・デバイスで使用される数値コードが割り当てられている。」（第２３頁第４〜１４行）
　
（２）
「ソース文字列をターゲット文字列に変換する方法において、
  （ａ）第１の文字コード化を有する前記ソース文字列を受け取り、
  （ｂ）前記ソース文字列をテキスト要素に順次分割し、各前記テキスト要素は、前記ソース文字列の文字を１または複数含み、
  （ｃ）各前記テキスト要素の第２の文字コード化に関する変換コードをマッピング・テーブルでルックアップし、
  （ｄ）前記第２の文字コード化の前記ターゲット文字列を形成するように前記テキスト要素の前記変換コードを結合する
  ことを特徴とする方法。」（特許請求の範囲１）
　
（３）
「請求項１に記載の方法において、前記マッピング・テーブルは、レギュラ・マッピングとフォールバック・マッピングを含み、
  前記ルックアップ（ｃ）は、前記マッピング・テーブルが、前記テキスト要素についての前記レギュラ・マッピングを使用した変換コードを含まない場合は、前記フォールバック・マッピングを使用して各前記テキスト要素の前記変換コードを決定することを特徴とする方法。」（特許請求の範囲４）
　
（４）
「Ｉ．定義
  １．コード・ポイント：コード・ポイントとは、特定のコード化におけるビット・パターンである。通常、ビット・パターンは１または２バイト以上の長さになっている。ユニコードのコード・ポイントは常に１６ビットまたは２バイトである。
  ２．コード化：コード化とは、文字セットとコード・ポイントのセットとを１対１で対応づけたもの（マッピング）である。例えば、ＡＳＣＩＩコード化はａ−ｚ、Ａ−Ｚ、および０−９を含むセットをコード・ポイントｘ００−ｘ７Ｆに対応づけている。
  ３．テキスト要素：テキスト要素は特定のオペレーションで１つの単位として扱われる１つまたは２つ以上のコード・ポイントのシーケンスである。例えば、ＬＡＴＩＮ  ＣＡＰＩＴＡＬ  ＬＥＴＴＥＲ  Ｕとその後に続くＮＯＮ−ＳＰＡＣＩＮＧ  ＤＩＡＥＲＥＳＩＳは本発明によるコード変換オペレーションの対象となるテキスト要素である（例えば、この例では、２つの隣り合う文字）。
  ・・・
  ６．フォールバック：フォールバックはソース・コードに正確に等価ではないが、オリジナルの情報の一部を残しているターゲット・コード化内の１つまたは２つ以上のコード・ポイントのシーケンスである。例えば、（Ｃ）は、Cを表す可能なフォールバックである。」（第４４頁第１２行〜第４５頁第９行）」
　
　ここで、上記記載事項（１）、（２）を技術常識の下に併せ読めば、引用例には、「テキスト要素からなり第１の文字コード化を有するソース文字列を、マッピング・テーブルを用いてターゲット文字列に変換し、該ターゲット文字列を表示デバイスへの表示に用いる」ことが実質的に記載されているといえる。
　また、上記記載事項（３）の文脈や技術常識に照らせば、引用例記載のものにおいては、マッピング・テーブルがテキスト要素についてのレギュラ・マッピングを使用した変換コードを含む場合には、当然に、レギュラ・マッピングを使用して各テキスト要素の変換コードを決定するものと考えられる。
　
　以上によれば、引用例には、「テキスト要素からなり第１の文字コード化を有するソース文字列を受け取るステップと、第２の文字コード化に関する変換コードを含むマッピング・テーブルが前記テキスト要素についてのレギュラ・マッピングを使用した変換コードを含む場合には、前記レギュラ・マッピングを使用して各前記テキスト要素の変換コードを決定するステップと、前記マッピング・テーブルが、前記テキスト要素についての前記レギュラ・マッピングを使用した変換コードを含まない場合は、フォールバック・マッピングを使用して前記テキスト要素の変換コードを決定するステップと、前記決定された変換コードによって前記ソース文字列を第２の文字コード化のターゲット文字列に変換し、前記変換されたターゲット文字列を用いて、前記テキスト要素の文字を表示するステップ、を含む方法」の発明（以下、「引用発明」という。）が記載されていると認められる。
　
　
３．対比
　本願発明と引用発明を対比すると、以下のことがいえる。
　
（１）引用発明の「テキスト要素からなり第１の文字コード化を有するソース文字列を受け取るステップ」と本願発明の「文字を含むファイルを受信するステップ」は、「文字を含む情報を受信するステップ」である点で共通する。
　
（２）引用発明の「マッピング・テーブルが前記テキスト要素についてのレギュラ・マッピングを使用した変換コードを含む場合」は、「ソース文字列中のテキスト要素が、レギュラ・マッピング中に存在する場合」に他ならず、「マッピング・テーブルが前記テキスト要素についてのレギュラ・マッピングを使用した変換コードを含まない場合」は、「ソース文字列中のテキスト要素が、レギュラ・マッピング中に存在しない場合」に他ならないから、上記それぞれの場合は、「テキスト要素が第１のタイプである場合」、「テキスト要素が第２のタイプである場合」と呼ぶことができる。また、引用発明において「レギュラ・マッピングを使用して決定される変換コード」は、当然に「フォールバック・マッピングを使用して決定される変換コード」とは異なると考えられるから、該「レギュラ・マッピングを使用して決定される変換コード」により変換されたターゲット文字列を「第１のコード形式」、「フォールバック・マッピングを使用して決定される変換コード」により変換されたターゲット文字列を「第２のコード形式」と呼ぶことができる。
　したがって、引用発明の「第２の文字コード化に関する変換コードを含むマッピング・テーブルが前記テキスト要素についてのレギュラ・マッピングを使用した変換コードを含む場合には、前記レギュラ・マッピングを使用して各前記テキスト要素の変換コードを決定するステップ」と本願発明の「該文字が第１のタイプである場合には、前記ファイルを２バイト長の第１のコード形式に変換するステップ」は、「受信したテキスト要素が第１のタイプである場合には、前記受信した情報を第１のコード形式に変換するステップ」である点で共通し、引用発明の「第２の文字コード化に関する変換コードを含むマッピング・テーブルが前記テキスト要素についてのレギュラ・マッピングを使用した変換コードを含まない場合は、フォールバック・マッピングを使用して各前記テキスト要素の変換コードを決定するステップ」と本願発明の「該文字が第２のタイプである場合には、前記ファイルを２バイト長を２つ用いる第２のコード形式に変換するステップ」は、「受信したテキスト要素が第２のタイプである場合には、前記受信した情報を第２のコード形式に変換するステップ」である点で共通する。
　
　以上によれば、本願発明と引用発明との間には、以下の一致点、相違点があるということができる。
　
（一致点）
　文字を含む情報を受信するステップと、
　該文字を含むテキスト要素が第１のタイプである場合には、前記ファイルを第１のコード形式に変換するステップと、
　該文字を含むテキスト要素が第２のタイプである場合には、前記ファイルを第２のコード形式に変換するステップと、
　前記第１のコード形式または前記第２のコード形式を用いて、前記ファイルの前記文字を表示するステップと、
　を含んでなる方法。
　
（相違点１）
　受信する「文字を含む情報」が、本願発明では「文字を含むファイル」であるのに対し、引用発明では、該「文字を含む情報」が「文字を含むファイル」かどうか定かでない。
　
（相違点２）
　本願発明では、「文字」が第１のタイプである場合に、文字を含む情報を第１のコード形式に変換し、該「文字」が第２のタイプである場合に、前記文字を含む情報を第２のコード形式に変換するのに対し、引用発明では、「テキスト要素」が第１のタイプである場合に、文字を含む情報を第１のコード形式に変換し、該「テキスト要素」が第２のタイプである場合に、前記文字を含む情報を第２のコード形式に変換する。
　
（相違点３）
　本願発明では、「第１のコード形式」が「２バイト長」であり、「第２のコード形式」が「２バイト長を２つ用いる」ものであるのに対し、引用発明では「第１のコード形式」と「第２のコード形式」にそのような限定がない。
　
（相違点４）
　本願発明は、「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ」と、「文字セットのプレーンが変更されたかどうかを決定するためにチェックするステップ」を含むのに対し、引用発明は、それらのステップを有していない。
　
　
４．当審の判断
　
（１）上記相違点について
　
ア．（相違点１）について
　情報をファイルの形式で授受することは例示するまでもなく周知であるし、引用発明に、該周知のファイル形式で情報の授受を行う技術を採用出来ない事情も認められないから、引用発明の「ソース文字列」（文字を含む情報）を「文字を含むファイル」とすることは、当業者が容易に推考し得たことである。
　したがって、上記相違点１によっては本願発明の進歩性は肯定されない。
　
イ．（相違点２）について
　引用例の上記２．の（２）、（４）の摘記箇所に記載されているように、引用発明でいう「テキスト要素」は、「ソース文字列の文字を１または複数含」むものであり、また、「特定のオペレーションで１つの単位として扱われる１つまたは２つ以上のコード・ポイントのシーケンス」である。そして、該「テキスト要素」を「複数の文字を含むもの」とするか、「単一の文字を含むもの」、すなわち「文字」とするかは、扱うソース文字列の種類によって、当業者が適宜決定すべき事項と考えられるから、引用発明において、該「テキスト要素」を「単一の文字を含むもの」すなわち「文字」とし、「文字」が第１のタイプである場合に、文字を含む情報を第１のコード形式に変換し、該「文字」が第２のタイプである場合に、前記文字を含む情報を第２のコード形式に変換するようにすることも、当業者が容易に推考し得たことである。
　したがって、上記相違点２によっても本願発明の進歩性は肯定されない。
　
ウ．（相違点３について）
　拒絶査定の備考欄に「引用文献Ａ」として例示された「P. Hoffman et al., UTF-16, an encoding of ISO 10646, [online], ２０００．０２，RFC 2781, ［検索日　２００６．０５．０１］，インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc2781.txt＞」（以下、本件審決においても「引用文献Ａ」と呼ぶ。）の「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が正式に発行する文書。）である引用文献Ａにも記載されているのであるから、当業者には周知であった。
（イ）「UTF-16」は、文字によって、「２バイト長」のコード形式に変換される場合と、「２バイト長を２つ用いる」コード形式に変換される場合があることを規定している。
　
　そして、上記「UTF-16」に規定される周知の規則を引用発明の「レギュラ・マッピングを使用して各前記テキスト要素の変換コードを決定するステップ」と「フォールバック・マッピングを使用して前記テキスト要素の変換コードを決定するステップ」の部分に採用できない事情は認められない。
　また、上記「UTF-16」に規定される周知の規則を引用発明の「レギュラ・マッピングを使用して各前記テキスト要素の変換コードを決定するステップ」と「フォールバック・マッピングを使用して前記テキスト要素の変換コードを決定するステップ」の部分に採用する場合、より単純なコード形式である「２バイト長」のコード形式を「レギュラ・マッピングを使用して各前記テキスト要素の変換コードを決定するステップ」の方に採用し、複雑なコード形式である「２バイト長を２つ用いる」コード形式を「フォールバック・マッピングを使用して前記テキスト要素の変換コードを決定するステップ」の方に採用することは、当業者が当然に考慮することである。
　してみれば、引用発明において、上記相違点３に係る本願発明の構成を採用することも、当業者が容易に推考し得たことである。
　したがって、上記相違点３によっても本願発明の進歩性は肯定されない。
　
エ．（相違点４について）
　平成２０年７月１０日の審尋書に添付した前置報告書に「引用文献Ｂ」として例示された「”７ビット及び８ビットの２バイト情報交換用符号化拡張漢字集合”，ＪＩＳ　Ｘ　０２１３：２０００，財団法人日本規格協会，２０００年１月２０日，ｐ．５０−５２，６０−６４」には、以下の記載がある。
（ア）「ｅ）ビット組合わせ１Ｂで始まる次の３バイト又は４バイトの列は，制御文字の領域及び図形文字の領域の使用方法の切替えに用いる。」（第６０頁下から２行目〜下から１行目）
（イ）「ｂ）情報交換の途中にこの附属書の４．１ｅ）のバイト列が現れた場合は，４．１ｅ）に示す利用状態の遷移が起こる（附属書２図５参照）」（第６２頁第１３〜１４行）
（ウ）「1B 24 28 4F以後，制御文字の領域は使用せず，図形文字の領域は，本体6.5.1で規定する漢字集合の１面を表す。」（第６２頁第３〜４行）
（エ）「1B 24 28 50以後，制御文字の領域は使用せず，図形文字の領域は，本体6.5.1で規定する漢字集合の２面を表す。」（第６２頁第５〜６行）
　また、同引用文献Ｂの第６１頁の附属書２図１〜附属書２図４及び第６３頁の附属書２図５には、「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式」が記載されている。
　
　ここで、上記引用文献Ｂが、所謂ＪＩＳ規格であり、当然に相当多数の当業者が参照するものであるという事実と、それに上記の事項が記載されているという事実に照らせば、「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式」、及び「該形式を採用するものにおいて、文字セットのプレーンを情報交換の途中で切替えること」は、当業者に周知であったと認められる。また、「ウェブページ」自体は、例示するまでもなく周知であったと認められる。
　
　そして、上記周知の「文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式」、「該形式を採用するものにおいて、文字セットのプレーンを情報交換の途中で切替えること」、「ウェブページ」の各事項を、引用発明の「ソース文字列」の部分に採用できない事情も見当たらない。
　また、引用発明に上記「該形式を採用するものにおいて、文字セットのプレーンを情報交換の途中で切替えること」なる事項を採用する場合、「文字セットのプレーンが変更されたかどうかを決定するためにチェックするステップ」を設けるべきことは、当業者に自明である。
　
　してみれば、引用発明において、上記相違点４に係る本願発明の構成を採用することも、当業者が容易に推考し得たことである。
　したがって、上記相違点４によっても本願発明の進歩性は肯定されない。
　
（２）本願発明の効果について
　本願発明の構成によってもたらされる効果は、引用発明及び上記各周知技術から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。　
　
　なお、審判請求人は、平成１８年９月６日付けの審判請求書についての手続補正書において、「本願の補正後の請求項１に係る発明は、『文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ』および『文字セットのプレーンが変更されたかどうかを決定するためにチェックするステップ』という発明特定事項を含む点で引用文献１に記載された発明とは相違する。このような『文字セットのプレーンの番号とその中の行と列との番号を含んでなる形式のウェブページを受信するステップ』や『文字セットのプレーンが変更されたかどうかを決定するためにチェックするステップ』という発明特定事項を有するので、本願の請求項１に係る発明は、本願の出願当初の段落００４３に記載されているように、『特定の文字に対するフォントは、簡単な計算により、その（プレーン、行、列の）値から又はその代理のユニコード値から直接に配置することができる』ので、段落００３２に記載されているマッピングテーブルの巨大化を回避して『メモリのためにプロセッサの速度を犠牲にする』ことを防止できるという、引用文献１では得ることのできない格別な作用効果を奏する。ここでの『簡単な計算』による変換・逆変換の一例が、本願の出願当初の段落００３８〜００３９に記載されている。また、本願の請求項１に記載されているように『文字セットのプレーンが変更されたかどうかを決定するためにチェックする』ことによって、本願の出願当初の段落００５０に記載されているように、『新しい文字セットの指定子（以下、「ＣＳＧ」とよぶ）がＭＯＤの変化を示すように挿入され』、『・・・ＩＳＯ−２０２２−ＣＮ及び拡張版ＩＳＯ−２０２２−ＣＮ拡張版により定義された文字については、・・・マッピングテーブルを使用してその１６ビットのユニコード値をマップする』ことができる。従って、本願の請求項１は、引用文献１に基づいて当業者が容易に想到することができないものと思料する。」旨主張すると共に、平成１０年１０月２８日付けの回答書においても、同旨の主張を行っているが、以下の理由で採用できない。
　すなわち、上記請求人が主張する「特定の文字に対するフォントは、簡単な計算により、その（プレーン、行、列の）値から又はその代理のユニコード値から直接に配置することができる」、「マッピングテーブルの巨大化を回避して『メモリのためにプロセッサの速度を犠牲にする』ことを防止できる」、「『新しい文字セットの指定子（以下、「ＣＳＧ」とよぶ）がＭＯＤの変化を示すように挿入され』、『・・・ＩＳＯ−２０２２−ＣＮ及び拡張版ＩＳＯ−２０２２−ＣＮ拡張版により定義された文字については、・・・マッピングテーブルを使用してその１６ビットのユニコード値をマップする』ことができる」、といった効果は、いずれも、受信した「文字を含むファイル」から「第１のコード形式」や「第２のコード形式」への具体的変換内容がなんら特定されない本願発明によってもたらされる効果とは認められないから、上記請求人が主張する効果をもって本願発明の進歩性を肯定することはできない。
　
５　むすび
　したがって、本願発明は、引用例に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。