【事件の表示】
　平成　８年特許願第３２２６９２号「ＩＣカード」拒絶査定不服審判事件〔平成　９年　９月　５日出願公開、特開平　９−２３１１１１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯  
　
　本願は、平成８年１２月３日の出願（優先権主張平成７年１２月２２日）の出願であって、平成１９年６月２０日付けで拒絶査定がなされ、これに対し、同年７月２５日に拒絶査定不服審判の請求がなされるとともに、同年８月２４日付けで手続補正がなされたものである。  
　  
　  
　
  
第２　本願発明について  
　  
１．本願発明  
　
　本願の請求項１乃至２に係る発明は、平成１９年８月２４日付けの手続補正書によって補正された明細書及び図面の記載からみて、特許請求の範囲の請求項１乃至２に記載されたとおりのものと認められるところ、その請求項１に係る発明（以下、「本願発明」という。）は、次のとおりのものである。  
　　  
「　【請求項１】
　１又は２以上のファイルを格納可能なメモリを有するＩＣカードにおいて、
　外部からの命令により、外部から指定された指定容量だけ選択されているファイルの容量を縮小又は拡大する容量変更手段を有し、
　前記ファイルは、自己の空き容量を記憶する空き容量記憶部を有し、
　前記ファイルには、親ファイルの空き容量を自己の空き容量とする容量親依存ファイルがあり、
　前記容量変更手段は、前記空き容量記憶部の内容を変更しようとするファイルが前記容量親依存ファイルである場合は、前記変更しようとするファイルの上位階層にある前記親ファイルの空き容量記憶部の内容を前記指定容量に基づいて変更すること
　を特徴とするＩＣカード。」 
　 
　 
　  
２．引用例１ 
　　  
　原査定の拒絶の理由に引用文献１として引用された、特開平６−１３１５１７号公報（以下、「引用例１」という。）には、次の事項が記載されている。  
　　  
（ア）  
「【０００１】 
　【産業上の利用分野】 
　本発明は階層化されたディレクトリで管理されるファイルをメモリ上で再配置するＩＣカードに関する。」  
　  
（イ）  
「【０００４】 
　【発明が解決しようとする課題】 
　しかしながら従来のＩＣカードでは、ディレクトリの基にさらにディレクトリを創成する、すなわち階層的なディレクトリ構造が不可能であり、また一度生成されたファイルの削除が不可能である。例えばＩＣカードをある企業が社員のために発行して銀行、医療、その他ＩＣカードシステムで利用する場合、各システム毎にディレクトリが必要となる。また銀行のＩＣカードシステム内で預貯金、クレジット、その他機能が複数ある場合、ひとつのＩＣカードシステムの中で機能毎にさらにディレクトリが必要となってくる。ＩＣカードの多目的な使用を考慮すると、ディレクトリの階層化およびメモリの有効的な利用は不可欠なものとなる。 
【０００５】 
　本発明はかかる点に鑑み、ディレクトリを階層的な構造とし、かつディレクトリで管理されるファイルの削除および該ファイルのメモリ容量の拡張が可能であり、さらにファイルの削除あるいは拡張によって生じたメモリ上の空き領域を無くしてメモリを有効に利用することが可能なＩＣカードを提供することを目的とする。」 
　 
（ウ） 
「【０００７】 
　【作用】 
　この方式により許容されるＩＣカードは、階層化されたディレクトリで管理されるファイルをファイル削除手段により削除し、ファイル拡張手段によりファイルの容量を大きくすることが可能となる。これら処理によって生じたメモリ上の空き領域は、ファイル再配置手段により複数のファイルをメモリ上に密に並び変えることができるため、ＩＣカード内のメモリを有効に活用することが可能となる。」 
　 
（エ） 
「【０００８】 
　【実施例】 
以下、本発明の一実施例について図面を参照しながら説明する。」 
　 
（オ） 
「【０００９】 
図１に示すように本発明のＩＣカード１は、各種処理のためにＲＡＭ３をバッファとして利用する処理制御部２と、外部機器との間でデータを送受信する入出力手段５と、入出力手段５を通して受信したコマンドの解析および処理を行い、且つ受信したコマンドに対する応答の作成を行うコマンド処理手段６と、ファイルを創成するファイル生成手段７と、処理されるデータをファイルとして一元管理し、且つＥＥＰＲＯＭ４におけるディレクトリを通してファイルあるいはファイル内のデータに対してアクセスを行うファイル管理手段８と、ファイルを削除するファイル削除手段９と、コマンドで指定したファイルの容量を拡張するファイル拡張手段１０と、ＥＥＰＲＯＭ４上に格納された複数のファイルを密に並び変えるファイル再配置手段１１とを具備する。ここでファイル作成手段７、ファイル管理手段８、ファイル削除手段９、ファイル拡張手段１０およびファイル再配置手段１１はコマンド処理手段６によって起動する。また本実施例のＩＣカード１のＥＥＰＲＯＭ４の容量は８ｋバイトの情報を格納することができる。」 
　 
（カ） 
「【００１０】 
　図２は本発明のＩＣカード１のディレクトリ構造の例を示しており、ひとつのマスタディレクトリ２０の基にディレクトリ２１、２２が存在している。さらにディレクトリ２１の基にディレクトリ２３、２４、２５が、ディレクトリ２２の基にディレクトリ２６が、ディレクトリ２４の基にディレクトリ２７が存在する。さらに、マスタディレクトリ２０の下にファイル３０、３１、３２が、ディレクトリ２２の下にファイル３５、３６が存在する。このように本発明のＩＣカード１では、マスタディレクトリ２０を含め、全てのディレクトリが階層的に下位方向に複数のディレクトリを管理し、且つ各ディレクトリには複数のファイルを持つことが可能である。以後この上下関係について、親のディレクトリおよび親のディレクトリに対する子のディレクトリと呼ぶ。」 
　 
（キ） 
「【００１１】 
　図３は本発明のＩＣカード１のメモリ上のデータ構成の例である。ＥＥＰＲＯＭ４上に、ディレクトリは上位番地方向から下位番地方向に格納され、ファイルは下位番地方向から上位番地方向に格納される。以後ディレクトリおよびファイルを格納する領域をユーザ領域と呼ぶ。このような構成からファイルを削除すると、ＥＥＰＲＯＭ４上に空き領域が生じて非効率的である。そこでファイルの再配置が必要となってくる。」 
　 
（ク） 
「【００１２】 
　まずマスタディレクトリ、ディレクトリおよびファイルのデータ構成について説明する。図４は本発明のＩＣカード１のマスタディレクトリ２０のデータ構成図である。ＤＦ書き込みポインタ４０は最後に創成されたディレクトリの先頭番地（図３ではディレクトリ２３）、ＥＦ書き込みポインタ４１は次ファイルを創成する番地（図３ではファイル３２の最終番地の次の番地）、Ｃ＿ＤＦ４２はマスタディレクトリ２０が管理する子のディレクトリの中で最初に創成されたディレクトリ（図３ではディレクトリ２１）の先頭番地、およびＣ＿ＥＦ４３はマスタディレクトリ２０が管理するファイルの中で最初に創成されたファイル（図２および図３に示すファイル３０）の先頭番地である。なお、Ｃ＿ＤＦ４２およびＣ＿ＥＦ４３は該当するものが存在しなければ値００００が格納される。」 
　 
（ケ） 
「【００１３】 
　図５は本発明のＩＣカード１のディレクトリ２１のデータ構成図である。Ｐ＿ＤＦ５０はディレクトリ２１を管理する親のディレクトリ（図２ではマスタディレクトリ２０）の先頭番地、Ｎ＿ＤＦ５１はディレクトリ２１を管理する親のディレクトリの基に存在し、ディレクトリ２１の創成の次に創成されたディレクトリ（図２ではディレクトリ２２）の先頭番地、Ｂ＿ＤＦ５２はディレクトリ２１を管理する親のディレクトリの基に存在し、ディレクトリ２１の創成の前に創成されたディレクトリ（図３では存在しない）の先頭番地、Ｃ＿ＤＦ５３はディレクトリ２１が管理する子のディレクトリの中で最初に創成されたディレクトリ（図２および図３よりディレクトリ２３）の先頭番地、およびＣ＿ＥＦ５４はディレクトリ２１が管理するファイルの中で最初に創成されたファイル（図２のファイル３３あるいはファイル３４）の先頭番地である。なお、Ｎ＿ＤＦ５１、Ｂ＿ＤＦ５２、Ｃ＿ＤＦ５３およびＣ＿ＥＦ５４は該当するものが存在しなければ値００００が格納される。また、他のディレクトリについてもデータ値は異なるが同じ構成である。」 
　 
（コ） 
「【００１４】 
　図６は本発明のＩＣカード１のファイル３０のデータ構成図である。フラグ６０はファイル３０が有効か無効を示すフラグ、サイズ６１はファイル３０の容量、Ｐ＿ＤＦ６２はファイル３０を管理する親のディレクトリ（図２のマスタディレクトリ２０）の先頭番地、Ｎ＿ＥＦ６３はファイル３０を管理する親のディレクトリの基に存在し、ファイル３０の創成の次に創成されたファイル（図２、図３のファイル３１）の先頭番地、Ｂ＿ＥＦ６４はファイル３０を管理する親のディレクトリの基に存在し、ファイル３０の創成の前に創成されたファイルの先頭番地（図３では存在しない）および領域６５は情報などのデータが格納される。なお、Ｎ＿ＥＦ６３およびＢ＿ＥＦ６４は該当するものが存在しなければ値００００が格納される。また、他のファイルについてもデータ値は異なるが同じ構成である。」 
　 
（サ） 
「【００１７】 
　このように本発明のＩＣカード１では、階層化されたディレクトリおよびファイルのポインタにより、ディレクトリあるいはファイルの管理が容易となった。次に本発明のＩＣカード１におけるファイルの削除処理、ファイルの再配置処理およびファイルの容量拡張処理について説明する。」 
　 
（シ） 
「【００１８】 
　ファイルの削除処理について図９の流れ図を用いて説明する。削除すべきファイルはコマンドによって指定される（ファイルのことを図中および以下ではＥＦと記述）。まず、ステップ９０１で指定されたＥＦはフラグ６０を利用して無効とされる。ここで指定されたＥＦが削除されることによって、削除された指定ＥＦを示すポインタを有するＥＦあるいはディレクトリ（ディレクトリのことを図中および以下ではＤＦと記述）が存在すれば、そのポインタを更新する必要がある。まず指定ＥＦの次のＥＦを示すＮ＿ＥＦポインタが００００であるかを判断し（ステップ９０２）、００００であれば指定ＥＦの次にＥＦは存在しないため次の処理に移る。００００でなければ指定ＥＦの次にＥＦが存在するため次のＥＦのＢ＿ＥＦポインタに指定ＥＦの前のＥＦを示すＢ＿ＥＦポインタを代入する（ステップ９０３）。ここで指定ＥＦの前にＥＦが無く（値００００）ても良い。次に指定ＥＦの前のＥＦを示すＢ＿ＥＦポインタが００００であるかを判断し（ステップ９０４）、００００であれば指定ＥＦの前にＥＦは存在せず、指定ＥＦは指定ＥＦを管理するディレクトリの中で先頭であるため、該ディレクトリの管理するファイルを示すＣ＿ＥＦポインタに指定ＥＦの次を示すＮ＿ＥＦポインタを代入する（ステップ９０５）。００００でなければ指定ＥＦの前にＥＦが存在するため前のＥＦのＮ＿ＥＦポインタに指定ＥＦの次のＥＦを示すＮ＿ＥＦポインタを代入する（ステップ９０６）。」 
　 
（ス） 
「【００１９】 
　次にファイルを削除することによって生じた空き領域に対する管理情報を更新する必要がある。物理的にメモリ上で指定ＥＦがメモリ上のユーザ領域の先頭でない場合（ステップ９０７）、ユーザ領域の先頭から指定ＥＦが次の領域となるＥＦを検索する（ステップ９０８）。ここで検索されたＥＦが無効ＥＦである場合（ステップ９０９）、すなわち無効ＥＦがメモリ上で連続する場合、２つの連続した無効ＥＦをひとつの無効ＥＦにするため、検索されたＥＦのサイズに指定ＥＦのサイズを加え、検索されたＥＦを指定ＥＦとする（ステップ９１０、９１１）。」 
　 
（セ） 
「【００２０】 
　物理的にメモリ上で指定ＥＦの次の領域がＥＦ書き込みポインタである場合（ステップ９１２）、メモリ上で最後のＥＦが削除されたこととなるため、ＥＦ書き込みポインタを指定ＥＦの先頭番地に更新して処理を終了する（ステップ９１３）。次の領域が有効ＥＦである場合は処理を終了する（ステップ９１４）。次の領域が無効ＥＦである場合、すなわち無効ＥＦがメモリ上で連続する場合、２つの連続した無効ＥＦをひとつの無効ＥＦにするため、指定ＥＦのサイズに無効ＥＦのサイズを加え、再度指定ＥＦの次の領域を確認する（ステップ９１５）。」 
　 
（ソ） 
「【００２４】
　ひとつのファイルを有効に利用するために、前述したファイル構成において以下に示すようなファイルの容量拡張手段でファイルの容量を大きくすると、やはりメモリ上に空き領域が生じてファイルの再配置が必要となってくる。ファイルの容量拡張処理について図１１の流れ図を用いて説明する。
【００２５】
　拡張すべきＥＦおよび拡張サイズはコマンドによって指定される。まず物理的にメモリ上で指定ＥＦの最終番地の次の番地がＥＦ書き込みポインタである場合（ステップ１１０１）、ＥＦ書き込みポインタから拡張サイズ分の空き領域が有るか確認し、無い場合は処理を中断する（ステップ１１０２、１１０３）。有ればＥＦ書き込みポインタに拡張する。すなわち指定ＥＦのサイズに拡張サイズを加えて更新し、ＥＦ書き込みポインタに拡張サイズを加えて更新する（ステップ１１１３、１１１４）。
【００２６】
　物理的にメモリ上で指定ＥＦの最終番地の次の番地が有効ＥＦである場合（ステップ１１０４）、ＥＦ書き込みポインタから指定ＥＦサイズと拡張サイズ分の空き領域が有るか確認し（ステップ１１０９）、無い場合は処理を中断する。有ればＥＦ書き込みポインタで示す番地に指定ＥＦを複写し（ステップ１１１０）、ＥＦ書き込みポインタに指定ＥＦサイズを加えて更新する（ステップ１１１１）。ここで、複写元の有効ＥＦを前述したファイルの削除処理を利用して無効ＥＦとする（ステップ１１１２）。この後ＥＦ書き込みポインタに拡張する。すなわち指定ＥＦのサイズに拡張サイズを加えて更新し、ＥＦ書き込みポインタに拡張サイズを加えて更新して処理を終了する。
【００２７】
　物理的にメモリ上で指定ＥＦの最終番地の次の番地が無効ＥＦである場合、該無効ＥＦのサイズが拡張サイズと同一か、あるいは無効ＥＦのサイズが拡張サイズより３バイト以上大きいかを確認し（ステップ１１０５）、そうであれば次の番地に無効ＥＦのサイズで拡張する（ステップ１１０５）。すなわち指定ＥＦのサイズに無効ＥＦのサイズを加えて更新する。なお無効ＥＦのサイズが拡張サイズより３バイト以上大きい場合は、余りの領域を無効ＥＦとして登録する（ステップ１１０７、１１０８）。サイズが無ければ前述の物理的にメモリ上で指定ＥＦの最終番地の次の番地が有効ＥＦである場合と同様の処理を行う。」
　
（タ）
「【００２８】 
　このように階層的なディレクトリ構成により管理されたファイルに対して、ファイルの削除処理およびファイル容量の拡張処理が可能になることで、ＩＣカードの多目的利用が可能となった。さらにファイルの再配置処理が可能であるため、ファイルの削除あるいは容量の拡張によって生じた空き領域を無くしてメモリ上のファイルを密に並び変えることができ、メモリの有効利用が可能となった。」 
　 
　 
　以上の引用例１の記載によれば、引用例１には以下の事項が開示されていると認められる。  
　 
（ａ） 
　引用例１の上記（ウ）の
「この方式により許容されるＩＣカードは、階層化されたディレクトリで管理されるファイルをファイル削除手段により削除し、ファイル拡張手段によりファイルの容量を大きくすることが可能となる。これら処理によって生じたメモリ上の空き領域は、ファイル再配置手段により複数のファイルをメモリ上に密に並び変えることができるため、ＩＣカード内のメモリを有効に活用することが可能となる。」
　という記載、 
　 
　引用例１の上記（キ）の
「図３は本発明のＩＣカード１のメモリ上のデータ構成の例である。ＥＥＰＲＯＭ４上に、ディレクトリは上位番地方向から下位番地方向に格納され、ファイルは下位番地方向から上位番地方向に格納される。以後ディレクトリおよびファイルを格納する領域をユーザ領域と呼ぶ。このような構成からファイルを削除すると、ＥＥＰＲＯＭ４上に空き領域が生じて非効率的である。そこでファイルの再配置が必要となってくる。」
　という記載から、 
　 
　引用例１には、「１又は２以上のファイルを格納可能なメモリを有するＩＣカード」が開示されていると認められる。 
　 
　 
（ｂ） 
　引用例１の上記（オ）の
「図１に示すように本発明のＩＣカード１は、各種処理のためにＲＡＭ３をバッファとして利用する処理制御部２と、外部機器との間でデータを送受信する入出力手段５と、入出力手段５を通して受信したコマンドの解析および処理を行い、且つ受信したコマンドに対する応答の作成を行うコマンド処理手段６と、ファイルを創成するファイル生成手段７と、処理されるデータをファイルとして一元管理し、且つＥＥＰＲＯＭ４におけるディレクトリを通してファイルあるいはファイル内のデータに対してアクセスを行うファイル管理手段８と、ファイルを削除するファイル削除手段９と、コマンドで指定したファイルの容量を拡張するファイル拡張手段１０と、ＥＥＰＲＯＭ４上に格納された複数のファイルを密に並び変えるファイル再配置手段１１とを具備する。ここでファイル作成手段７、ファイル管理手段８、ファイル削除手段９、ファイル拡張手段１０およびファイル再配置手段１１はコマンド処理手段６によって起動する。」
　という記載、 
　
　引用例１の上記（シ）の
「（ファイルのことを図中および以下ではＥＦと記述）。」
　という記載、 
　
　引用例１の上記（ソ）の
「ひとつのファイルを有効に利用するために、前述したファイル構成において以下に示すようなファイルの容量拡張手段でファイルの容量を大きくすると、やはりメモリ上に空き領域が生じてファイルの再配置が必要となってくる。ファイルの容量拡張処理について図１１の流れ図を用いて説明する。・・・（中略）・・・拡張すべきＥＦおよび拡張サイズはコマンドによって指定される。」
　という記載から、 
　 
　引用例１には、「外部機器からのコマンドにより、外部機器から指定された拡張サイズだけ選択されているファイルの容量を拡張するファイル拡張手段」が開示されていると認められる。 
　
　
（ｃ）
　上記（ａ）の「１又は２以上のファイルを格納可能なメモリを有するＩＣカード」という開示、 
　
　引用例１の上記（コ）の 
「図６は本発明のＩＣカード１のファイル３０のデータ構成図である。フラグ６０はファイル３０が有効か無効を示すフラグ、サイズ６１はファイル３０の容量、Ｐ＿ＤＦ６２はファイル３０を管理する親のディレクトリ（図２のマスタディレクトリ２０）の先頭番地、Ｎ＿ＥＦ６３はファイル３０を管理する親のディレクトリの基に存在し、ファイル３０の創成の次に創成されたファイル（図２、図３のファイル３１）の先頭番地、Ｂ＿ＥＦ６４はファイル３０を管理する親のディレクトリの基に存在し、ファイル３０の創成の前に創成されたファイルの先頭番地（図３では存在しない）および領域６５は情報などのデータが格納される。なお、Ｎ＿ＥＦ６３およびＢ＿ＥＦ６４は該当するものが存在しなければ値００００が格納される。また、他のファイルについてもデータ値は異なるが同じ構成である。」
　という記載から、
　
　引用例１には、「前記ファイルは、自己のファイルの容量を記憶する記憶部」を有することが開示されていると認められる。
　 
　 
　以上の引用例１の記載によれば、引用例１には下記の発明（以下、「引用例１発明」という。）が開示されていると認められる。  
　  
「１又は２以上のファイルを格納可能なメモリを有するＩＣカードにおいて、 
　外部機器からのコマンドにより、外部機器から指定された拡張サイズだけ選択されているファイルの容量を拡張するファイル拡張手段を有し、
　前記ファイルは、自己のファイルの容量を記憶する記憶部を有すること
　を特徴とするＩＣカード。」 
　  
　  
　 
３．引用例２
　 
　原査定の拒絶の理由に引用文献３として引用された、特開平６−２８２４７１号公報（以下、「引用例２」という。）には、次の事項が記載されている。  
　　  
（ア）
「　【０００１】
　　【産業上の利用分野】
　本発明は、たとえば、不揮発性メモリ、および、これらを制御するＣＰＵなどの制御素子を有するＩＣチップを内蔵したＩＣカードにおいて、上記メモリ内に分割設定される複数のファイルのデータ管理を行なうファイル管理方式に関する。」
　
（イ）
「　【０００６】
　　【発明が解決しようとする課題】
　しかし、上記のような方法では、アプリケーションファイルのサイズをあらかじめ設定することになり、以降、サイズの変更ができないため、たとえば、アプリケーションＡで使用するファイルに対して１０００バイト、また、アプリケーションＢで使用するファイルに対して２０００バイトを与えられており、両者の運用の過程において、アプリケーションＡでは与えられた１０００バイトのうち、５００バイトのみを使用し、また、アプリケーションＢでは更に５００バイト要する場合でも、与えられたサイズの範囲以内で運用しなければならない。
　　【０００７】
　これを回避するために、アプリケーションＢにて使用するファイル（５００バイト）をもう１つ作成し、運用時に２つのファイルを参照する方法が考えられるが、これでは運用上の利便性が損なわれる恐れが生ずる。
　　【０００８】
　そこで、本発明は、アプリケーションに対応するデータファイルのサイズの上限を規定する必要がなく、運用時点で必要なエリアを随時追加が可能となり、かつ、ファイルのサイズの上限を規定するアプリケーションとの混用も可能となるファイル管理方式を提供することを目的とする。」
　
（ウ）
「　【００１３】
　　【実施例】
　以下、本発明の一実施例について図面を参照して説明する。
　　【００１４】
　図１は、本実施例に係る携帯可能電子装置としてのＩＣカードが適用される、たとえば、金融システムあるいはショッピングシステムなどの端末装置として用いられるカード取扱装置の構成例を示すものである。すなわちち、この装置は、ＩＣカード１をカードリーダ・ライタ２を介してＣＰＵなどからなる制御部３と接続可能とするとともに、制御部３にキーボード４、ＣＲＴディスプレイ装置５、プリンタ６、および、フロッピーディスク装置７を接続して構成される。
　【００１５】
　図２は、ＩＣカード１の構成例を示すものであり、制御部としての制御素子（たとえば、ＣＰＵ）１１、記憶内容が消去可能な不揮発性のデータメモリ１２、ワーキングメモリ１３、プログラムメモリ１４、および、カードリーダ・ライタ２との電気的接触を得るためのコンタクト部１５によって構成されている。これらのうち、破線内の部分（制御素子１１、データメモリ１２、ワーキングメモリ１３、プログラムメモリ１４）は１つ（あるいは複数）のＩＣチップで構成されてＩＣカード本体内に埋設されている。
　　【００１６】
　データメモリ１２は、各種データの記憶に使用され、たとえば、ＥＥＰＲＯＭなどで構成されている。ワーキングメモリ１３は、制御素子１１が処理を行なう際の処理データを一時的に保持するためのメモリであり、たとえば、ＲＡＭなどで構成される。プログラムメモリ１４は、たとえば、マスクＲＯＭで構成されており、制御素子１１のプログラムなどを記憶するものである。」
　
（エ）
「　【００１７】
　データメモリ１２は、たとえば、図３に示すように、制御領域１２０、ディレクトリ１２１、空き領域１２２、および、エリア群１２３に分割されている。エリア群１２３は、複数のデータエリアおよびキーエリアを有することができ、かつ、データファイル（ＤＦ）と呼ばれる概念でグループ化することができる。なお、後述するＭＦ（マスターファイル）は、データファイルの１つの形態として一括管理される。データファイルは、対応するアプリケーションにて使用されるデータエリア、および、キーエリアを一括して管理するためのファイルである。データエリアは、たとえば、取引データなどのように、必要に応じて読み書きするためのデータを格納するエリアである。キーエリアは、たとえば、暗証番号などの格納に利用されているエリアであり、書込み／書換え／照合の対象になり、読出しはできないようになっている。
　　【００１８】
　なお、これらのエリアは、図３に示すように、エリア群１２３として一括して割当てられている。また、これらのファイルあるいはエリアは、データメモリ１２内のディレクトリ１２１を用いることにより、それぞれの物理的位置などを制御素子１１が認識するようになっている。さらに、図３の制御領域１２０には、エリア群１２３の先頭アドレス情報、および、空き領域１２２の先頭アドレス情報が格納されている。図３のディレクトリ１２１は、図４に示すように、各データファイルおよびエリアに対応する各種定義情報が格納される。」
　
（オ）
「　【００２０】
　図４（ａ2 ）は、データファイルの管理情報を定義する情報である。この定義情報は、ディレクトリ１２１内でデータファイル名定義情報を識別するためのデータＰＴＮ、本データファイルに割当てられたファイル通し番号ＤＦＳＮ、本データファイルの親ファイルの通し番号ＰＦＳＮ、データファイルサイズＤＦＳ、本データファイルの付加情報が格納されるデータエリアを識別するためのＡＡＩＤ、当該付加情報を出力するか否かなどを規定するＴＹＰＥ、データファイルのアクセス条件を示すＤＦＡＣ、本データファイルの状態を保持するためのＤＦＳＴ、本データファイルの配下に位置するデータファイルおよびエリアにより使用されているバイト数ＵＳ、および、これらのデータの正当性をチェックするためのデータＢＣＣからなる。」
　 
（カ）
「　【００２８】
　さて、これらのデータファイルには、それぞれサイズ情報が割当てられており、配下のデータファイルの総サイズの上限値を示すようになっている。このサイズ情報は、２バイトで構成されており、該サイズ情報が‘００００’であった場合には、当該データファイルでは上記上限値を規定しないデータファイルであると認識する。」
　
（キ）
「　【００２９】
　図６に、サイズ管理を行なうデータファイルと行なわないデータファイルとの混在例を示す。図中実線の箱は、サイズ管理を行なうよう指示されたデータファイルであり、それぞれ図示するようなバイト数をサイズとして有している。また破線の箱は、サイズ管理を行なわないよう指示されたデータファイルである。図示するように、サイズ管理を行なうデータファイルに対しては、後述するファイル創成コマンドにてサイズ値を指定するが、サイズ管理を行なわない場合には、この指定サイズ値を‘００００’とする。
　【００３０】
　図６において、マスターファイル（ＭＦ）は、（６０００ｂ：３０００ｂ）となっているが、これは一次発行者に対して解放したＭＦサイズが６０００バイトであり、かつ、ＭＦ直下に属するファイルの総サイズが３０００バイトであることを示している。特に、各ファイル直下のエリアサイズの総数は、（当該ファイルの使用バイト数）−（配下のデータファイルが使用しているバイト数の総数）で与えられる。
　　【００３１】
　たとえば、ＤＦ１で使用されているバイト数が８００バイト、また、ＤＦ２で使用されているバイト数（ＤＦ２は、サイズがあらかじめ割当てられているので、この割当てバイト数が、ＭＦから見た場合の使用バイト数となる）が２０００バイトである。したがって、ＭＦ配下のエリアが使用している総バイト数は２００バイトであると認識する。同様にして、ＤＦ１直下のエリアが使用している総バイト数は１００バイト、また、ＤＦ２のそれは５００バイトと認識する。」
　
（ク）
「　【００３２】
　ファイルのサイズ管理は、その配下にデータファイルあるいはエリアを創成する際に、当該データファイルに割当てられたサイズの範囲以内で創成するように制御を行なうことである。図６の例では、各ファイル内にデータファイルあるいはエリアを創成する場合
に、以下のような対応関係で残りサイズを認識する。
　（１）ＭＦ直下にエリアあるいはＤＦを創成する場合：
　　　　　　　（ＭＦサイズ）−（ＭＦとしての使用サイズ）
　（２）ＤＦ１直下にエリアあるいはＤＦを創成する場合：
　　　　　　　（ＭＦサイズ）−（ＭＦとしての使用サイズ）
　（３）ＤＦ１−１直下にエリアを創成する場合：
　　　　　　　（ＭＦサイズ）−（ＭＦとしての使用サイズ）
　（４）ＤＦ１−２直下にエリアを創成する場合：
　　　　　　　（ＤＦ１−２サイズ）−（ＤＦ１−２としての使用サイズ）
　（５）ＤＦ２直下にエリアあるいはＤＦを創成する場合：
　　　　　　　（ＤＦ２サイズ）−（ＤＦ２としての使用サイズ）
　（６）ＤＦ２−１直下にエリアを創成する場合：
　　　　　　　（ＤＦ２サイズ）−（ＤＦ２としての使用サイズ）
　（７）ＤＦ２−２直下にエリアを創成する場合：
　　　　　　　（ＤＦ２−２サイズ）−（ＤＦ２−２としての使用サイズ）
　　【００３３】
　すなわち、あるファイル内に配下のファイルまたはエリアを創成しようとした場合には、当該ファイルを含めて上位レベルに見つかった、サイズ管理をしているファイルが管理する“割当てサイズ”と“使用サイズ”を元に未使用サイズを算出する。
　　【００３４】
　たとえば、ＤＦ１−１、ＤＦ１、およびＭＦがカレントファイルとなっていればＭＦが、また、ＤＦ１−２、ＤＦ２、およびＤＦ２−２は自身が、また、ＤＦ２−１はＤＦ２がそれぞれ対応する。」
　
（ケ）
「　【００３５】
　次に、図７によりＩＣカード１の動作概念を説明する。図示するように、ＩＣカード１は、電気的活性化後に命令データ待ち状態に移る。この時点で命令データを待ち続け、入力されると、命令データの先頭にある機能コードを抽出し、対応する命令ルーチンに移る。この後、命令ルーチンにて処理を行ない、この処理結果を出力後、命令データ待ち状態に戻る。」
　
（コ）
「　【００３６】
　図９および図１０は、ファイル創成のための動作を説明するフローチヤートを示している。ＩＣカード１が、図８に示すようなコマンド電文を受信すると、これらの機能コードから、ファイル創成コマンドであることを認識し、図９および図１０に示すフローチヤートにしたがって処理が実行される。」
　
（サ）
「　【００４０】
　次に、当該コマンドにて与えられたファイルのサイズが、正当であるか否かをチェックする。このとき、データファイル創成コマンドであり、かつ、指定ファイルサイズが‘００００’であった場合には、当該コマンドにて生成されるデータファイル定義情報が使用するバイト数、それ以外の場合には、指定されたファイルサイズに生成される定義情報が使用するバイト数を合計したバイト数が、チェックの対象になる。
　　【００４１】
　このとき、カレントとなっているデータファイルのファイルサイズを確認し、これが‘００００’以外の場合には、このカレントデータファイル定義情報にて規定されているファイルサイズ、および使用サイズから、未使用サイズを計算する。　
　【００４２】
　また、カレントデータファイルのファイルサイズが‘００００’となっていた場合、該データファイルの親ファイルのファイルサイズを参照し、同様なチェックを行なう。このようにして、最終的にファイルサイズとして‘００００’以外の値を有するファイルの定義情報にて規定されているファイルサイズ、および使用サイズから、未使用サイズを計算する。
　　【００４３】
　たとえば、図６におけるＤＦ１−１の配下にファイルを創成する場合、当該ファイルのサイズが‘００００’なので、その上層に位置するファイルのうち、サイズが‘００００’以外のファイル、すなわち、この例では図中のマスターファイルが対象となり、このマスターファイルが有するファイルサイズ（６０００バイト）と使用サイズ（３０００バイト）とから空きサイズ（３０００バイト）を算出する。
　　【００４４】
　このステップにて算出されたファイルとしての空きサイズと、コマンドにて指定されたファイルサイズを基に創成のために必要なサイズとを比較する。これにより、空きサイズよりも、創成に必要なサイズの方が大きい場合、ファイルサイズ異常を示す応答データを出力し、コマンド待ち状態に戻る。」
　
（シ）
「　【００５３】
　次に、ファイルサイズの更新機能について図１１により説明する。前述したように、各データファイルは、自身に割当てられたファイルサイズを保持するとともに、自身の配下に存在する全ファイルの総サイズを常に認識している。
　【００５４】
　さて、あるファイルのサイズを変更する場合には、対象ファイルの親ファイルが、新規に配下のファイルを創成する際に認識する未使用サイズに、現在対象ファイルに割当てられているサイズを加算したものを上限とし、対象ファイル内で使用されているサイズを下限とする範囲で許容される。
　　【００５５】
　たとえば、図６のＤＦ１−２において、現在の割当てバイト数を変更することを考える。このとき、変更可能なサイズは、親ファイルから見た未使用サイズが３００バイトなので、上限は３５００バイトであり、また、現在使用済みサイズが２００バイトなので、これが下限である。ファイルサイズの変更は、カレントファイル配下のファイルのうち、コマンドにて指定されたものを対象に行なわれる。
　【００５６】
　図１２に示すようなファイルサイズ変更コマンドを受信すると、当該コマンド内の機能コードにより、ファイルサイズ変更コマンドであることを認識し、図１１および図１２に示すフローチヤートにしたがって処理が実行される。」
　
（ス）
「　【００５７】
　まず、コマンド実行条件が整っているかを、照合状態およびカレントファイルに規定されているアクセス条件とにより判断する。この判断でアクセス不可と判断された場合には、アクセス条件不可を示す応答データを出力し、コマンド待ち状態に戻る。
　　【００５８】
　アクセス可能と判断した場合には、次にコマンド中にて指定されている変更対象データファイル名が、ＩＣカード１内に存在するか否かをチェックする。もし、存在しなければ、指定ファイルなしを示す応答データを出力し、コマンド待ち状態に戻る。」
　
（セ）
「　【００５９】
　もし、存在するのであれば、次にコマンドにより指定された変更用サイズが　‘００００’か否かを確認する。このとき、‘００００’以外であれば、先のファイル創成時と同様に、指定ファイルよりも上層に位置するファイルのうち、‘００００’以外の値をファイルサイズとして有するファイルの定義情報（これを参照ファイルと称する）を参照する。
　　【００６０】
　このときの、指定ファイルサイズの変更範囲は、参照ファイルの定義情報から算出された空きサイズに、指定ファイルが使用しているサイズを加算した値を上限とし、さらに指定ファイルサイズが使用しているサイズを下限とする。」
　
（ソ）
「　【００６１】
　次に、このサイズの変更範囲内に、コマンドにより指定された変更サイズが入っているかをチェックする。このとき、範囲外であれば、サイズ異常を示す応答データを出力し、コマンド待ち状態に戻る。範囲内であれば、これを基にして指定ファイル定義情報を再び作成する。また、コマンドにより指定された変更用サイズが‘００００’であった場合には、これを基に指定ファイル定義情報を再び作成する。」
　
（タ）
「　【００６２】
　次に、指定ファイルの定義情報を、再作成された定義情報に書換える。このとき、書込みが終了しなかった場合には、書込み異常を示す応答データを出力し、コマンド待ち状態に戻る。書換えが正常終了した場合には、次に指定ファイルの上層に位置するファイルに規定されている使用サイズを変更する。
　【００６３】
　このとき、コマンドにより指定された変更用サイズが‘００００’以外であった場合には、変更前のサイズと変更後のサイズとの増減値により、使用サイズを変更する。また、‘００００’の場合には、変更前のサイズから指定ファイルにて指定されている使用サイズを差し引いた値を、上位に位置するファイルに規定されている使用サイズから差し引いて、これを変更する。」
　
　
　以上の引用例２の記載によれば、引用例２には以下の事項が開示されていると認められる。  
　 
（ａ） 
　引用例２の上記（ウ）の
「図２は、ＩＣカード１の構成例を示すものであり、制御部としての制御素子（たとえば、ＣＰＵ）１１、記憶内容が消去可能な不揮発性のデータメモリ１２、ワーキングメモリ１３、プログラムメモリ１４、および、カードリーダ・ライタ２との電気的接触を得るためのコンタクト部１５によって構成されている。・・・（中略）・・・データメモリ１２は、各種データの記憶に使用され、たとえば、ＥＥＰＲＯＭなどで構成されている。」
　という記載、
　
　引用例２の上記（エ）の
「データメモリ１２は、たとえば、図３に示すように、制御領域１２０、ディレクトリ１２１、空き領域１２２、および、エリア群１２３に分割されている。エリア群１２３は、複数のデータエリアおよびキーエリアを有することができ、かつ、データファイル（ＤＦ）と呼ばれる概念でグループ化することができる。・・・（中略）・・・なお、これらのエリアは、図３に示すように、エリア群１２３として一括して割当てられている。また、これらのファイルあるいはエリアは、データメモリ１２内のディレクトリ１２１を用いることにより、それぞれの物理的位置などを制御素子１１が認識するようになっている。」
　という記載（なお、データファイルが「１又は２以上」であることは明らかである。）から、
　
　引用例２には、「１又は２以上のデータファイルを格納可能なデータメモリを有するＩＣカード」が開示されていると認められる。
　
　
（ｂ）
　上記（ａ）の「１又は２以上のデータファイルを格納可能なデータメモリを有するＩＣカード」という開示、
　
　引用例２の上記（ケ）の
「次に、図７によりＩＣカード１の動作概念を説明する。図示するように、ＩＣカード１は、電気的活性化後に命令データ待ち状態に移る。この時点で命令データを待ち続け、入力されると、命令データの先頭にある機能コードを抽出し、対応する命令ルーチンに移る。この後、命令ルーチンにて処理を行ない、この処理結果を出力後、命令データ待ち状態に戻る。」
　という記載（なお、命令データがＩＣカードの外部から送られることは明らかである。）、
　
　引用例２の上記（シ）の
「次に、ファイルサイズの更新機能について図１１により説明する。前述したように、各データファイルは、自身に割当てられたファイルサイズを保持するとともに、自身の配下に存在する全ファイルの総サイズを常に認識している。・・・（中略）・・・さて、あるファイルのサイズを変更する場合には、対象ファイルの親ファイルが、新規に配下のファイルを創成する際に認識する未使用サイズに、現在対象ファイルに割当てられているサイズを加算したものを上限とし、対象ファイル内で使用されているサイズを下限とする範囲で許容される。・・・（中略）・・・ファイルサイズの変更は、カレントファイル配下のファイルのうち、コマンドにて指定されたものを対象に行なわれる。・・・（中略）・・・図１２に示すようなファイルサイズ変更コマンドを受信すると、当該コマンド内の機能コードにより、ファイルサイズ変更コマンドであることを認識し、図１１および図１２に示すフローチヤートにしたがって処理が実行される。」
　という記載、
　
　引用例２の上記（ソ）の
「次に、このサイズの変更範囲内に、コマンドにより指定された変更サイズが入っているかをチェックする。」
　という記載、
　
　引用例２の上記（タ）の「このとき、コマンドにより指定された変更用サイズが‘００００’以外であった場合には、変更前のサイズと変更後のサイズとの増減値により、使用サイズを変更する。」
　という記載（なお、「変更前のサイズと変更後のサイズとの増減値」という記載から、ファイルのサイズを縮小又は拡大を意図していることは明らかである。）から、
　
　引用例２には、「外部からのコマンドにより、外部から指定された変更サイズだけ指定されているデータファイルのサイズを縮小又は拡大する制御部」が開示されていると認められる。
　
　
（ｃ）
　上記（ａ）の「１又は２以上のデータファイルを格納可能なデータメモリを有するＩＣカード」という開示、
　
　引用例２の上記（オ）の
「図４（ａ2 ）は、データファイルの管理情報を定義する情報である。この定義情報は、ディレクトリ１２１内でデータファイル名定義情報を識別するためのデータＰＴＮ、本データファイルに割当てられたファイル通し番号ＤＦＳＮ、本データファイルの親ファイルの通し番号ＰＦＳＮ、データファイルサイズＤＦＳ、本データファイルの付加情報が格納されるデータエリアを識別するためのＡＡＩＤ、当該付加情報を出力するか否かなどを規定するＴＹＰＥ、データファイルのアクセス条件を示すＤＦＡＣ、本データファイルの状態を保持するためのＤＦＳＴ、本データファイルの配下に位置するデータファイルおよびエリアにより使用されているバイト数ＵＳ、および、これらのデータの正当性をチェックするためのデータＢＣＣからなる。」
　という記載、
　
　引用例２の上記（ク）の
「ファイルのサイズ管理は、その配下にデータファイルあるいはエリアを創成する際に、当該データファイルに割当てられたサイズの範囲以内で創成するように制御を行なうことである。・・・（中略）・・・すなわち、あるファイル内に配下のファイルまたはエリアを創成しようとした場合には、当該ファイルを含めて上位レベルに見つかった、サイズ管理をしているファイルが管理する“割当てサイズ”と“使用サイズ”を元に未使用サイズを算出する。」
　という記載、
（なお、「・・・、“使用サイズ”を元に・・・」は「・・・、“使用サイズ”を基に・・・」の誤記であると認められる。）
　
　引用例２の上記（シ）の
「次に、ファイルサイズの更新機能について図１１により説明する。前述したように、各データファイルは、自身に割当てられたファイルサイズを保持するとともに、自身の配下に存在する全ファイルの総サイズを常に認識している。・・・（中略）・・・さて、あるファイルのサイズを変更する場合には、対象ファイルの親ファイルが、新規に配下のファイルを創成する際に認識する未使用サイズに、現在対象ファイルに割当てられているサイズを加算したものを上限とし、対象ファイル内で使用されているサイズを下限とする範囲で許容される。・・・（中略）・・・たとえば、図６のＤＦ１−２において、現在の割当てバイト数を変更することを考える。このとき、変更可能なサイズは、親ファイルから見た未使用サイズが３００バイトなので、上限は３５００バイトであり、また、現在使用済みサイズが２００バイトなので、これが下限である。ファイルサイズの変更は、カレントファイル配下のファイルのうち、コマンドにて指定されたものを対象に行なわれる。」
　という記載から、
　
　引用例２には、「前記データファイルは、自身に割当てられた割当てサイズと使用サイズを含む管理情報を保持しており、前記割当てサイズと前記使用サイズを基に未使用サイズを算出可能」であることが開示されていると認められる。
　
　
（ｄ）
　上記（ｃ）の「前記データファイルは、自身に割当てられた割当てサイズと使用サイズを保持しており、前記割当てサイズと前記使用サイズを基に未使用サイズを算出可能」であるという開示、
　
　引用例２の上記（シ）の
「次に、ファイルサイズの更新機能について図１１により説明する。前述したように、各データファイルは、自身に割当てられたファイルサイズを保持するとともに、自身の配下に存在する全ファイルの総サイズを常に認識している。」
　という記載、
　
　引用例２の上記（カ）の
「さて、これらのデータファイルには、それぞれサイズ情報が割当てられており、配下のデータファイルの総サイズの上限値を示すようになっている。このサイズ情報は、２バイトで構成されており、該サイズ情報が‘００００’であった場合には、当該データファイルでは上記上限値を規定しないデータファイルであると認識する。」
　という記載、
　
　引用例２の上記（ク）の
「ファイルのサイズ管理は、その配下にデータファイルあるいはエリアを創成する際に、当該データファイルに割当てられたサイズの範囲以内で創成するように制御を行なうことである。
　・・・（中略）・・・
　（２）ＤＦ１直下にエリアあるいはＤＦを創成する場合：
　　　　　　　（ＭＦサイズ）−（ＭＦとしての使用サイズ）
　（３）ＤＦ１−１直下にエリアを創成する場合：
　　　　　　　（ＭＦサイズ）−（ＭＦとしての使用サイズ）
　・・・（中略）・・・
　（６）ＤＦ２−１直下にエリアを創成する場合：
　　　　　　　（ＤＦ２サイズ）−（ＤＦ２としての使用サイズ）
　・・・（中略）・・・
すなわち、あるファイル内に配下のファイルまたはエリアを創成しようとした場合には、当該ファイルを含めて上位レベルに見つかった、サイズ管理をしているファイルが管理する“割当てサイズ”と“使用サイズ”を基に未使用サイズを算出する。」
　という記載、
（すなわち、ファイルのサイズが‘００００’に設定されたデータファイル（ＤＦ１，ＤＦ１−１，ＤＦ２−１）の未使用サイズは、上位レベルのファイルの未使用サイズに等しい。
　なお、「・・・、“使用サイズ”を元に・・・」は「・・・、“使用サイズ”を基に・・・」の誤記であると認められる。）
　
　引用例２の上記（サ）の
「次に、当該コマンドにて与えられたファイルのサイズが、正当であるか否かをチェックする。このとき、データファイル創成コマンドであり、かつ、指定ファイルサイズが‘００００’であった場合には、当該コマンドにて生成されるデータファイル定義情報が使用するバイト数、それ以外の場合には、指定されたファイルサイズに生成される定義情報が使用するバイト数を合計したバイト数が、チェックの対象になる。・・・（中略）・・・また、カレントデータファイルのファイルサイズが‘００００’となっていた場合、該データファイルの親ファイルのファイルサイズを参照し、同様なチェックを行なう。・・・（中略）・・・たとえば、図６におけるＤＦ１−１の配下にファイルを創成する場合、当該ファイルのサイズが‘００００’なので、その上層に位置するファイルのうち、サイズが‘００００’以外のファイル、すなわち、この例では図中のマスターファイルが対象となり、このマスターファイルが有するファイルサイズ（６０００バイト）と使用サイズ（３０００バイト）とから空きサイズ（３０００バイト）を算出する。」
　という記載（なお、「空きサイズ」が、上記（ｃ）等にある「未使用サイズ」と同じ意味であることは明らかである。）から、
　
　引用例２には、「前記データファイルには、親ファイルの未使用サイズを自身の未使用サイズとする『ファイルのサイズが‘００００’に設定されたデータファイル』」があることが開示されていると認められる。
　
　 
（ｅ）
　上記（ｂ）の「外部からのコマンドにより、外部から指定された変更サイズだけ指定されているデータファイルのサイズを縮小又は拡大する制御部」という開示、
　
　上記（ｃ）の「前記データファイルは、自身に割当てられた割当てサイズと使用サイズを含む管理情報を保持しており、前記割当てサイズと前記使用サイズを元に未使用サイズを算出可能」であることという開示、
　
　上記（ｄ）の「前記データファイルには、親ファイルの未使用サイズを自身の未使用サイズとする『ファイルのサイズが‘００００’に設定されたデータファイル』」があるという開示、
　
　引用例２の上記（タ）の
「次に、指定ファイルの定義情報を、再作成された定義情報に書換える。・・・（中略）・・・書換えが正常終了した場合には、次に指定ファイルの上層に位置するファイルに規定されている使用サイズを変更する。・・・（中略）・・・このとき、コマンドにより指定された変更用サイズが‘００００’以外であった場合には、変更前のサイズと変更後のサイズとの増減値により、使用サイズを変更する。また、‘００００’の場合には、変更前のサイズから指定ファイルにて指定されている使用サイズを差し引いた値を、上位に位置するファイルに規定されている使用サイズから差し引いて、これを変更する。」
　という記載から、
　
　引用例２には、「前記制御部は、前記管理情報に含まれる使用サイズを変更しようとするデータファイルが前記『ファイルのサイズが‘００００’に設定されたデータファイル』である場合は、前記変更しようとするデータファイルの上層に位置する前記親ファイルの管理情報に含まれる使用サイズを前記指定された変更サイズに基づいて変更すること」が開示されていると認められる。
　
　
　以上の引用例２の記載によれば、引用例２には下記の発明（以下、「引用例２発明」という。）が開示されていると認められる。  
　  
「１又は２以上のデータファイルを格納可能なデータメモリを有するＩＣカードにおいて、
　外部からのコマンドにより、外部から指定された変更サイズだけ指定されているデータファイルのサイズを縮小又は拡大する制御部を有し、
　前記データファイルは、自身に割当てられた割当てサイズと使用サイズを含む管理情報を保持しており、前記割当てサイズと前記使用サイズを基に未使用サイズを算出可能であり、
　前記データファイルには、親ファイルの未使用サイズを自身の未使用サイズとする『ファイルのサイズが‘００００’に設定されたデータファイル』があり、
　前記制御部は、前記管理情報に含まれる使用サイズを変更しようとするデータファイルが前記『ファイルのサイズが‘００００’に設定されたデータファイル』である場合は、前記変更しようとするデータファイルの上層に位置する前記親ファイルの管理情報に含まれる使用サイズを前記指定された変更サイズに基づいて変更すること
　を特徴とするＩＣカード。」 
　  
　
　 
４．対比  
　 
　本願発明と引用例１発明とを対比する。  
　 
（１） 
　引用例１発明の「コマンド」及び「拡張」は、それぞれ、
　
本願発明の「命令」及び「拡大」に相当する。 
　 
　  
（２） 
　引用例１発明の「１又は２以上のファイルを格納可能なメモリを有するＩＣカード」は、 
　 
　本願発明の「１又は２以上のファイルを格納可能なメモリを有するＩＣカード」に相当する。 
　 
　 
（３）  
　引用例１発明の「外部機器からのコマンドにより、外部機器から指定された拡張サイズだけ選択されているファイルの容量を拡張するファイル拡張手段」と、 
　 
　本願発明の「外部からの命令により、外部から指定された指定容量だけ選択されているファイルの容量を縮小又は拡大する容量変更手段」とは、 
　 
「外部からの命令により、外部から指定された指定容量だけ選択されているファイルの容量を拡大する容量変更手段」という点で一致し、 
　 
　本願発明では、ファイルの容量の「縮小」もできるのに対し、
引用例１発明では、ファイルの容量の「縮小」もできるのか不明である点、　
　で相違する。 
　 
　
（４）
　引用例１発明の「前記ファイルは、自己のファイルの容量を記憶する記憶部」を有することと、
　
　本願発明の
「前記ファイルは、自己の空き容量を記憶する空き容量記憶部を有し、
　前記ファイルには、親ファイルの空き容量を自己の空き容量とする容量親依存ファイルがあり、
　前記容量変更手段は、前記空き容量記憶部の内容を変更しようとするファイルが前記容量親依存ファイルである場合は、前記変更しようとするファイルの上位階層にある前記親ファイルの空き容量記憶部の内容を前記指定容量に基づいて変更すること」とは、
　
「前記ファイルは、自己の容量を記憶する容量記憶部」 を有することで一致し、
　
　本願発明では、ファイルが記憶する容量はファイルの「空き容量」であるのに対し、
　引用例１発明では、ファイルが記憶する容量は「ファイルの容量」である点、
　
　また、
　
　本願発明は、
「前記ファイルには、親ファイルの空き容量を自己の空き容量とする容量親依存ファイルがあり、
　前記容量変更手段は、前記空き容量記憶部の内容を変更しようとするファイルが前記容量親依存ファイルである場合は、前記変更しようとするファイルの上位階層にある前記親ファイルの空き容量記憶部の内容を前記指定容量に基づいて変更すること」ができるものであるのに対し、
　引用例１発明は、そのことができるものではない点、
　
　で相違する。
　
　
（５） 
　以上のことから、本願発明と引用例１発明とは、  
　  
「１又は２以上のファイルを格納可能なメモリを有するＩＣカードにおいて、 
　外部からの命令により、外部から指定された指定容量だけ選択されているファイルの容量を拡大する容量変更手段を有し、
　前記ファイルは、自己の容量を記憶する容量記憶部を有すること
　を特徴とするＩＣカード。」  
　  
　という点で一致し、 
　  
（相違点１）  
　本願発明では、ファイルの容量の「縮小」もできるのに対し、
　引用例１発明では、ファイルの容量の「縮小」もできるのか不明である点、 
　
　
（相違点２）
　本願発明では、ファイルが記憶する容量はファイルの「空き容量」であるのに対し、
　引用例１発明では、ファイルが記憶する容量は「ファイルの容量」である点、
　
　また、
　
　本願発明は、
「前記ファイルには、親ファイルの空き容量を自己の空き容量とする容量親依存ファイルがあり、
　前記容量変更手段は、前記空き容量記憶部の内容を変更しようとするファイルが前記容量親依存ファイルである場合は、前記変更しようとするファイルの上位階層にある前記親ファイルの空き容量記憶部の内容を前記指定容量に基づいて変更すること」ができるものであるのに対し、
　引用例１発明は、そのことができるものではない点、　 
　
　
　で相違する。 
　 
　 
　 
５．判断  
　
（１）相違点１について  
　
　引用例１発明には、ファイルの容量を縮小することは明記されていないものの、ファイルの容量の変更という処理として、ファイルの容量の拡大以外に、ファイルの容量の縮小という処理があることは、情報処理分野（ＩＣカードの技術分野を含む。）における周知技術である。
　
　
　実際、引用例１発明と同一の技術分野に属する引用例２発明、すなわち、
　
「１又は２以上のデータファイルを格納可能なデータメモリを有するＩＣカードにおいて、
　外部からのコマンドにより、外部から指定された変更サイズだけ指定されているデータファイルの使用サイズを縮小又は拡大する制御部を有し、
・・・（中略）・・・
　を特徴とするＩＣカード。」 
　
　には、ＩＣカード分野において、ファイルの容量を拡張したり、ファイルの容量を「縮小」したりすることが開示されている。
　
　
　したがって、引用例１発明に対して、引用例２発明にも示される周知技術を適用することによって、ファイルの容量の拡大だけでなく、ファイルの容量の「縮小」にも対応することは、当業者が容易に想到し得ることである。
　
　
　
（２）相違点２について
　
　引用例１発明と同一の技術分野に属する引用例２発明は、上述したように、ＩＣカードに対して、
　
　データファイルの一種として、
「親ファイルの未使用サイズを自身の未使用サイズとする『ファイルのサイズが‘００００’に設定されたデータファイル』」
（本願発明の「親ファイルの空き容量を自己の空き容量とする容量親依存ファイル」に相当する。）
　を導入して、
　
「制御部は、前記
管理情報に含まれる使用サイズ
管理情報に含まれる使用サイズ
（変更しようとする対象が「空き容量記憶部の内容」と「管理情報に含まれる使用サイズ」とで異なる点を除き、
　本願発明の「容量変更手段は、前記空き容量記憶部の内容を変更しようとするファイルが前記容量親依存ファイルである場合は、前記変更しようとするファイルの上位階層にある前記親ファイルの空き容量記憶部の内容を前記指定容量に基づいて変更すること」に対応する。）
　
　ファイル管理を行うものである。
　
　
　ここで、引用例２発明と本願発明とは、
　引用例２発明では、変更しようとする対象が「管理情報に含まれる使用サイズ」であるのに対し、
　本願発明では、変更しようとする対象が「空き容量記憶部の内容」（すなわち、「自己の空き容量を記憶する空き容量記憶部」の内容）である点、
　で相違するものの、
　
・引用例２発明では、「前記データファイルは、自身に割当てられた割当てサイズと使用サイズを含む管理情報を保持しており、前記割当てサイズと前記使用サイズを元に未使用サイズを算出可能」であること、
　
・「割当てサイズ」＝「使用サイズ」＋「未使用サイズ」（本願の「空き容量」に相当する。）という関係にあるのであるから、「使用サイズ」と「未使用サイズ」の両方を記憶しておく必要はなく、どちらか片方を記憶しておけばよいことは明らかであること、
　
　の２点を鑑みれば、引用例２発明において、外部から指定された変更サイズだけ指定されているデータファイルのサイズを縮小又は拡大する際、
　
・「管理情報」に「使用サイズ」を含めるか、「管理情報」に「未使用サイズ」を含めるか、という選択、
　
　及び、当該選択に伴う、
　
・変更しようとする対象を「管理情報に含まれる使用サイズ」とするのか、変更しようとする対象を「管理情報に含まれる未使用サイズ」とするのか（すなわち、変更しようとする対象を「空き容量記憶部の内容」とするのか）、という選択、
　
　は当業者が適宜なし得る設計的事項に過ぎない。
　
　
　以上のことから、引用例１発明に対して、引用例２発明のＩＣカードにおけるファイル管理技術を適用できるように、
　
　引用例１発明の「ファイル」が有する「自己のファイルの容量を記憶する記憶部」に、変更しようとする対象である「空き容量」を記憶した上で、
（すなわち、引用例１発明の「前記ファイルは、自己のファイルの容量を記憶する記憶部」を有する構成を、本願発明のような「前記ファイルは、自己の空き容量を記憶する空き容量記憶部」を有する構成にした上で、）
　
　引用例２発明のＩＣカードにおけるファイル管理技術を適用し、本願発明のように
「前記ファイルには、親ファイルの空き容量を自己の空き容量とする容量親依存ファイルがあり、
　前記容量変更手段は、前記空き容量記憶部の内容を変更しようとするファイルが前記容量親依存ファイルである場合は、前記変更しようとするファイルの上位階層にある前記親ファイルの空き容量記憶部の内容を前記指定容量に基づいて変更すること」
　ができるように構成することは、当業者が容易に想到し得ることである。
　
　
　
６．むすび  
　  
　したがって、本願発明は、引用例１発明、引用例２発明、および周知技術に基づいて、当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないから、他の請求項について検討するまでもなく、本願は拒絶されるべきものである。  
　  
　よって、結論のとおり審決する。