ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 取り消して特許、登録 H04L |
|---|---|
| 管理番号 | 1395109 |
| 総通号数 | 15 |
| 発行国 | JP |
| 公報種別 | 特許審決公報 |
| 発行日 | 2023-03-31 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2022-08-16 |
| 確定日 | 2023-03-14 |
| 事件の表示 | 特願２０２１− ７８１３３「シリアル化方法、逆シリアル化方法、情報処理プログラム、情報処理装置及び通信システム」拒絶査定不服審判事件〔令和 ４年１１月１１日出願公開、特開２０２２−１７１４６４、請求項の数（１１）〕について、次のとおり審決する。 |
| 結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
| 理由 |
第１ 手続の経緯 本願は、令和３年４月３０日の出願であって、令和３年８月１８日付けで拒絶理由が通知され、令和３年１０月１９日に意見書が提出されるとともに手続補正がされ、令和４年１月１２日付けで拒絶理由（最後）が通知され、令和４年２月２４日に意見書が提出されるとともに手続補正がされ、令和４年５月１１日付けで令和４年２月２４日付けの手続補正が却下されるとともに拒絶査定（原査定）がされ、これに対し、令和４年８月１６日に拒絶査定不服審判の請求がされると同時に手続補正がされたものである。 第２ 令和４年５月１１日付けの補正の却下の決定及び原査定の概要 １ 令和４年５月１１日付けの補正の却下の決定の概要は以下のとおりである。 令和４年２月２４日付けの補正は、特許請求の範囲の限定的減縮を目的とするものであるが、当該補正後の本願請求項１、３−１０に係る発明は、以下の引用文献１−２、４に基づいて、本願請求項１１に係る発明は、以下の引用文献１−４に基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであり、独立特許要件を満たさないから、令和４年２月２４日付けの補正は却下すべきものである。 引用文献等一覧 １．米国特許第５９４４７８１号明細書 ２．特開２００７−２１３５５１号公報 ３．特開２００８−２０３９５９号公報 ４．米国特許第６８６２６８６号明細書 ２ 原査定（令和４年５月１１日付け拒絶査定）の概要は次のとおりである。 理由１（進歩性） 本願請求項１、３−１０に係る発明は、上記引用文献１−２、４に基づいて、本願請求項１１に係る発明は、上記引用文献１−４に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 第３ 本願発明 本願請求項１−１１に係る発明（以下、それぞれ「本願発明１」−「本願発明１１」という。）は、令和４年８月１６日提出の手続補正で補正された特許請求の範囲の請求項１−１１に記載された事項により特定される発明であって、本願発明１、５は以下のとおりの発明である。 「【請求項１】 情報を処理するコンピュータにおいて、 オブジェクトのクラスに関連付けられた情報を記載するステップと、 前記オブジェクトのフィールド名を予め定めた順番に従って並べ替えて、当該フィールド名を削除して、当該フィールド名に対応するフィールド値を並べ替えたフィールド名の順に記載するステップと、 前記記載されたクラスに関連付けられた情報と、前記並べ替えられたフィールド値をシリアル化されたデータとして出力するステップとを有するシリアル化方法。」 「【請求項５】 情報を処理するコンピュータにおいて、 オブジェクトのフィールド名を予め定めた順番に従って並べ替えて、当該フィールド名を削除して、当該フィールド名に対応するフィールド値を並べ替えたフィールド名の順に記載して、当該オブジェクトのクラスに関連付けられた情報とともにシリアル化されたデータからクラスに関連付けられた情報を取得するステップと、 前記クラスのフィールド情報を取得するステップと、 前記シリアル化されたオブジェクトのデータのフィールド値に対応する値が、前記取得したフィールド名を予め定めた順番で並べ替えたものに対応して並んでいるものとして取得して、前記取得したフィールド名とともに復元するステップと、 前記取得されたクラスに関連付けられた情報、前記フィールド情報、前記フィールド値を復元されたオブジェクトとして出力するステップとを有する逆シリアル化方法。」 なお、本願発明２−４、６−１１の概要は以下のとおりである。 本願発明２−４は、本願発明１を減縮した発明である。 本願発明６は、本願発明５を減縮した発明である。 本願発明７、９は、それぞれ、本願発明１に対応する「情報処理プログラム」、「情報処理装置」の発明であり、本願発明１とカテゴリ表現が異なるだけの発明である。 本願発明８、１０は、それぞれ、本願発明５に対応する「情報処理プログラム」、「情報処理装置」の発明であり、本願発明５とカテゴリ表現が異なるだけの発明である。 本願発明１１は、本願発明９及び本願発明１０を引用する通信システムの発明である。 第４ 引用文献、引用発明等 １ 引用文献１及び引用発明１−２ （１） 引用文献１ 原査定の拒絶の理由に引用された上記引用文献１には、次の事項が記載されている（下線は、特に着目した箇所を示す。以下同様。）。 ア ２欄１６−２４行 「Method and apparatus for making applets persistent are provided by virtue of the present invention. According to one embodiment of the present invention, a persistent applet operating on a client system may be saved along with its complete state to a remote server. When desired, the client system may retrieve the persistent applet with its previous state.」 （当審訳： アプレットを持続的にさせるための方法および装置が、本発明によって提供される。本発明の一実施形態によれば、クライアントシステム上で動作している持続性アプレットは、その完全な状態を遠隔サーバに保存することができる。所望の場合、クライアントシステムは持続性アプレットを以前の状態とともに取り出すことができる。） イ ６欄５５行−７欄９行 「The serialized encoding of an object consists of the object's class followed by the fields of each class starting with the highest superclass and ending with the actual class. For an object to handle its own serialization it must implement the “writeobject” method. To maintain the integrity of the class, this method is private to the class and can only be called by the serialization at runtime. This method is invoked when the fields of its class are to be written; it should write the information needed to reinitialize the object when it is deserialized. The default mechanism writes each non-static and non-transient field to the stream. Each field is written appropriately depending on its type. The fields are put in a canonical order so as to be insensitive to the order of declaration. Objects of class “Class” are serialized as the name of the class and the fingerprint or hash of the interfaces, methods, and fields of the class. The name allows the class to be identified during deserialization and the hash of the class allows it to be verified against the class of the serialized object. All other normal Java classes are serialized by writing the encoding of its Class followed by its fields.」 （当審訳： オブジェクトがシリアル化される符号化は、最も高いスーパークラスから開始されて現在のクラスで終わる、各クラスのオブジェクトのクラスとそれに続くフィールドによって構成される。オブジェクトは自身のシリアル化を取り扱うために、「ｗｒｉｔｅｏｂｊｅｃｔ」メソッドをインプリメントしなければならない。クラスの整合性を維持するために、このメソッドは、クラスでプライベートとされており、実行時にシリアル化のみによって、呼び出すことができる。このメソッドは、そのクラスのフィールドが書き込まれるときに呼び出される。そして、オブジェクトが逆シリアル化される際に、オブジェクトを再初期化するのに必要な情報を書き込まねばならない。デフォルトのメカニズムによれば、非スタティック、かつ、非過渡的なフィールドを、ストリームに書き込む。各フィールドは、その型に応じて、適切に書き込まれる。宣言の順序に影響されないために、各フィールドは、標準的な順序で（in a canonical order）配置される。 「クラス」というクラスのオブジェクトは、クラス名、及び、インターフェース、メソッド、及び、各フィールドのフィンガープリント又はハッシュ値として、シリアル化される。クラス名によって、逆シリアル化の際にクラスを特定することができ、クラスのハッシュ値によって、シリアル化されたオブジェクトのクラスを確認できる。他の全ての通常のＪａｖａのクラスは、クラスとそれに続くフィールドの符号化を書き込むことによってシリアル化される。） ウ ７欄４８−６２行 「The default mechanism reads each non-static and non-transient field from the stream. Each field is read appropriately depending on its type. The fields are read in the same canonical order as when written so as to be insensitive to the order of declaration. Objects of class “Class” are deserialized as the name of the class and fingerprint. A fingerprint is a hash of the interfaces, methods, and fields of the class. The “resolveClass” method is called to find the class by name and return its “Class” object. The hash is computed for the returned class and compared with the hash of the class serialized. Deserialization proceeds only if the class matches. This ensures that the structure of the stream matches the structure of the class. All other normal Java classes are deserialized by reading the encoding of its Class followed by its fields.」 （当審訳： デフォルトのメカニズムによれば、非スタティック、かつ、非過渡的な各フィールドを、ストリームから読み取る。各フィールドは、その型に応じて、適切に読み出される。各フィールドは、宣言の順序に影響されないために、書き込みと同じ標準的な順序で（in the same canonical order）読み出される。 「クラス」というクラスのオブジェクトは、クラス名とフィンガープリントとして、逆シリアル化される。フィンガープリントは、クラスのインターフェース、メソッド、及び、各フィールドのハッシュ値である。「ｒｅｓｏｌｖｅＣｌａｓｓ」メソッドは、クラス名からクラスを探し出し、そのクラスのオブジェクトを返すために、呼び出される。ハッシュ値が、返されたクラスに対して計算されて、シリアル化されたクラスのハッシュ値と比較される。逆シリアル化は、クラスが一致した場合にのみ続行される。これによって、ストリームの構造が、クラスの構造と一致することが保証される。他の全ての通常のＪａｖａのクラスは、そのクラスとそれに続く各フィールドの符号化を読み取ることによって逆シリアル化される。） （２） 引用発明１、引用発明２ よって、引用文献１には、特に上記「ア」の「シリアル化」に関する記載に着目すると、次の発明（以下、「引用発明１」という。）が開示されているものと認められる。 「クライアントシステム上で動作している持続性アプレットは、その完全な状態を遠隔サーバに保存することができ、所望の場合、クライアントシステムは持続性アプレットを以前の状態とともに取り出すことができ、 オブジェクトがシリアル化される符号化は、最も高いスーパークラスから開始されて現在のクラスで終わる、各クラスのオブジェクトのクラスとそれに続くフィールドによって構成され、宣言の順序に影響されないために、各フィールドは、標準的な順序で（in a canonical order）配置され、 通常のＪａｖａのクラスは、クラスとそれに続くフィールドの符号化を書き込むことによってシリアル化される、 シリアル化の方法。」 また，引用文献１には、特に上記「イ」の「逆シリアル化」に関する記載に着目すると、次の発明（以下，「引用発明２」という。）も開示されているものと認められる。 「クライアントシステム上で動作している持続性アプレットは、その完全な状態を遠隔サーバに保存することができ、所望の場合、クライアントシステムは持続性アプレットを以前の状態とともに取り出すことができ、 オブジェクトがシリアル化される符号化は、最も高いスーパークラスから開始されて現在のクラスで終わる、各クラスのオブジェクトのクラスとそれに続くフィールドによって構成され、宣言の順序に影響されないために、各フィールドは、標準的な順序で（in a canonical order）配置され、 通常のＪａｖａのクラスは、クラスとそれに続くフィールドの符号化を書き込むことによってシリアル化され、 スタティック、かつ、非過渡的な各フィールドを、ストリームから読み取り、各フィールドは、宣言の順序に影響されないために、書き込みと同じ標準的な順序で（in the same canonical order）読み出され、 通常のＪａｖａのクラスは、そのクラスとそれに続く各フィールドの符号化を読み取ることによって逆シリアル化される、 逆シリアル化の方法。」 ２ 引用文献２ 原査定の拒絶の理由に引用された上記引用文献２には、次の事項が記載されている。 （１） 段落【００２８】 「【００２８】 本発明を適用した場合の売上管理システム このように、従来のデータ管理システムでは、異なるデータ定義のデータごとに別個の格納領域及び表示プログラムを用意する必要があり、システムが使用するテーブルが増えるほど、データベースが大規模化し、プログラム開発に多大な労力を必要とする。そこで、本発明者は、鋭意研究を重ねた結果、かかる課題を解決する発明としてのデータ管理システムを発明した。本発明に係るデータ管理システムは、例えば、図１に示すように、実施の形態１の売上管理システム１０に具体化することができる。詳細には、実施の形態１の売上管理システム１０は、従来の売上管理システムで取り扱う全てのデータ（異なるフォーマット乃至データ定義のデータ）を取り扱うことができる一方、従来のように、データのフォーマット乃至定義ごとに別個のデータ定義（スキーマ定義）を作成して別個のテーブルを用意するのではなく、各データの定義情報を格納及び管理する列管理テーブル（データ項目乃至カラムを管理するマスタ系テーブル）１１をマスタテーブルとして用意して、異なる全てのデータフォーマット乃至データ定義に対応するようにしている。また、売上管理システム１０は、各データに含まれるデータ項目値のうち、識別子や検索キーとなる項目値（インデックスデータ）を順次格納する行管理テーブル（インデックスデータを管理するトランザクション系テーブル）１２と、前記列管理テーブル１１の定義情報の値と、行管理テーブル１２の識別子の値とを組み合わせることで、各データに含まれる全ての項目値を一意に特定できるように順次格納する値管理テーブル（項目値を格納するトランザクション系テーブル）１３とを備えている。更に、売上管理システム１０は、列管理テーブル１１の定義情報に基づき、行管理テーブル１２に格納した識別子を使用して、値管理テーブル１３に格納したデータ項目値のうちの必要な項目値を抽出し、所定のフォーマットでモニタ画面１に表示する表示（出力）プログラム（ＰＧ）１４を備えている。これにより、売上管理システム１０は、列管理テーブル１１、行管理テーブル１２及び値管理テーブル１３の３つのテーブルを用意するだけで、多種多様なデータ定義のデータを格納して管理することができ、各データ定義に対応して別個のテーブルを用意する必要がない。また、売上管理システム１０は、単一の表示（出力）プログラム１４により、多種多様なデータ定義のデータの任意の値を所定の形式でモニタ画面１に表示することができ、各データ定義に対応した別個のプログラムを用意する必要がない。即ち、本売上管理システム１０では、単一の表示プログラム１４を使用しながら、図１に示すように、モニタ画面１の表示上は、図７７の固有のデータ定義を有する各種テーブル（店舗テーブル、売上管理テーブル等）に対応する内容で同様のデータ（店舗データ、売上管理データ等）の表示が行われる。」 （２） 段落【００３０】 「【００３０】 また、データ管理システムでは、行管理テーブルは、前記管理対象データ（甲、乙、丙、丁）の各レコード（テーブルの各行）を読込むごとに自動的に付与される「行ＩＤ」と、各読込レコードを一意に示す「識別子」とからなるスキーマ（データ定義）を有する。そして、データ管理システムは、管理対象のレコードを読込むごとに、各読込レコードに対して行ＩＤを発番すると共に、当該読込レコード中の特定のデータ項目値を識別子として抽出し、行ＩＤに対応付けて格納する。例えば、行管理テーブルは、甲、乙、丙、丁の各テーブルについて、識別子として、属性Ｘの列のデータ項目値（ｘ１，ｘ２，ｘ３，ｘ４，ｘ５，ｘ６）、属性Ｙの列のデータ項目値（ｙ１，ｙ２，ｙ３，ｙ４，ｙ５，ｙ６）、属性Ｚの列のデータ項目値（ｚ１，ｚ２，ｚ３，ｚ４，ｚ５，ｚ６）を格納する。具体的には、データ管理システムは、甲データについては、各行のレコードを読み込むごとに、各レコードのＩＤでもある属性Ｘの項目値（ｘ１，ｘ２，ｘ３，ｘ４，ｘ５，ｘ６）を、順次、識別子の列に格納すると共に、各読込レコードの識別子に対応付けて行ＩＤを自動発番して格納する（乙データ、丙データ、丁データについても同様）。これにより、行管理テーブルの行ＩＤを参照することで、各読込レコード（及びその識別子）を一意に特定することができる。このように、行管理テーブルは、管理対象の全てのデータの読込レコードを一意に特定できるよう、それらのレコードに一意の行ＩＤを割り当てて格納するトランザクション系テーブルである。」 （３） 【図３】 「  」 （４） 段落【０１１２】−【０１１６】 「【０１１２】 図４７は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する行管理（ＲＯＷ）テーブルを示す説明図である。 図４７に示すように、行管理（ＲＯＷ）テーブルは、そのデータ項目（カラム）として、「行グループ」、「連番（＝シーケンスＮｏ」、「行タイトル」、「企業（版）（＝企業コード＋版情報）」、「種類（＝データ種類）」、「枝番（＝レコード関連情報」、「親Ｓ（＝親レコードシーケンスＮｏ）」、「ＦＳ（＝同一レコード内シーケンスＮｏ）」、「識別子（＝識別子値）」、「突合値１（＝突合項目値１）」（〜「突合項目値ｎ（たとえば突合項目値１０」）、「基本値１（＝基本項目値１）」（〜「基本項目値ｎ（たとえば突合項目値５」）等を定義している。なお、図４７の行管理テーブルは、図４７に図示のデータ項目以外にも、図示はしないが、図２９の表の項で説明したようにその他のデータ項目（「識別子ＩＤ」、「識別子名称」、「関連メソッド」、「関連情報」、「備考」、「参照フラグ」、その他、「有効日時（自）」、「有効日時（至）」等の日時情報等）を定義している。そして、行管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「１１１１１０１−９９９９９９−５０−０５１２０７−２０１９１４」、「１」・・・等）。なお、行管理テーブルのデータ項目中、「行グループ」は、所定の作成基準にしたがって、データ管理システムが一レコードを読込むごとに自動生成（発番）されるコードであり、格納データの管理グループを示す。行グループは、例えば、発注企業コード（＋版）の８桁＋受注企業コードの６桁＋データ種別の２桁＋データ読込日の６桁＋データ読込時刻（時分秒）の６桁から一意のコードとして自動生成することができる。そして、１回に読込んだデータ（発注データ等）の全てのレコードについて同一の行グループが付与される。なお、同一行グループを有するレコードが、本データ管理システムが格納データとして管理すべき１単位の管理グループとなる。次に、「連番」は、前記同一行グループ内での当該レコードの連番（レコードシーケンス）を示す。例えば、読込データが１００レコードからなる場合、「１」〜「１００」の連番が読込レコードの順番で「連番（シーケンスＮｏ）」の項目値として付与される。前記行グループ及び連番（シーケンスＮｏ）により行ＩＤが構成され、当該行ＩＤが、当該レコードが入力データ（読込データ）の何番目のデータであるかを示す。即ち、行ＩＤにより、各読込レコードに１対１で対応するコードが構成される。なお、「企業（版）」は、前記データ交換管理テーブル及びテーブル管理テーブルの企業コード（企業コード６桁＋バージョンコード２桁）に対応する。また、「種類」は、データ種類テーブル及び列管理テーブルのデータ種類に対応する。また、「枝番」は、テーブル管理テーブル及び列管理テーブルの「枝番」に対応する。テーブル管理テーブルについて述べたように、前記「企業（版）」、「種類」、「枝番」により、テーブルＩＤが構成されている。行管理テーブルでは、データ読込時にテーブル管理テーブルを参照したときに、「レコード制御情報」の値に基づき、特定のテーブルＩＤのカラム定義とマッチ（照合）したレコードに対して、当該テーブルＩＤが自動的に付与される。また、このとき、当該テーブルＩＤに割り当てた「レコード名称」（テーブル管理テーブル参照）の項目値が、行管理テーブルの「行タイトル」の項目値として複写される。 ・・・（中略）・・・ 【０１１４】 次に、「識別子（識別子値）」は、当該格納レコードの識別子の値を示す。そして、データ管理システムは、行管理テーブルの作成時（データの各レコード読込時）に、列管理テーブルの「識別子作成順序」を参照し、テーブル管理テーブルの「レコード制御情報」を参照して判断した当該読込レコード（管理対象レコード）のテーブルＩＤに対応して、列管理テーブルの当該テーブルＩＤの「識別子作成順序」で指定した順序にしたがって、指定されたテーブルＩＤのデータ項目の値を順番に組み合わせて、行管理テーブルの「識別子」の値を自動生成する。例えば、列管理テーブルでは、ファイルヘッダレコード（テーブルＩＤ「９９９９９０１５０１」）については、「識別子作成順序」において「発注企業コード」、「データ種別」、「データ作成日」が、それぞれ、「１」、「２」、「３」の順序で指定されているため、これらのデータ項目の値（「１１１１１１」、「５０」、「２００５０８１７」）を順に組み合わせて、行管理テーブルの識別子の値を生成し、当該テーブルＩＤの行（レコード）の「識別子ＩＤ」に「０」（システム対象オブジェクトテーブルの「オブジェクトＩＤ」）を、「識別子名称」に「発注企業コード−データ種別−データ作成日」を、「識別値」に「１１１１１１−５０−２００５０８１７」をそれぞれ格納する（行管理テーブルの１行目のレコード参照）。同様に、列管理テーブルでは、伝票ヘッダレコード（テーブルＩＤ「９９９９９０１５０１１）については、「識別子作成順序」において「伝票番号」が「１」として指定されているため、このデータ項目の値（「４９２１８３８９」）を前記ファイルヘッダレコードの識別値に追加して、行管理テーブルの識別子の値を生成し、当該テーブルＩＤの行（レコード）の「識別子ＩＤ」に「２０２０」（システム対象オブジェクトテーブルの「オブジェクトＩＤ」）を、「識別子名称」に「発注企業コード−データ種別−データ作成日−伝票番号」を、「識別値」に「１１１１１１−５０−２００５０８１７−４９２１８３８９」」をそれぞれ格納する（行管理テーブルの２行目のレコード参照）。同様に、列管理テーブルでは、伝票明細行レコード（テーブルＩＤ「９９９９９０１５０１１１）については、「識別子作成順序」において「行番号」及び「ＧＴＩＮ］が「１」としてそれぞれ指定されているため、このデータ項目の値（「０２」及び「０４９３６０６８９２７２１７」）を前記伝票ヘッダレコードの識別値に追加して、行管理テーブルの識別子の値を生成し、当該テーブルＩＤの行（レコード）の「識別子ＩＤ」に「２０３０」（システム対象オブジェクトテーブルの「オブジェクトＩＤ」）を、「識別子名称」に「発注企業コード−データ種別−データ作成日−伝票番号−行番号−ＧＴＩＮ」を、「識別値」に「１１１１１１−５０−２００５０８１７−４９２１８３８９−０２−０４９３６０６８９２７２１７」をそれぞれ格納する（なお、図６６では、行番号については省略）。このように行管理テーブルの各レコードに付与した識別値は、例えば、発注データと入荷予定データの所定の項目値（発注数量と検収数量乃至納品予定数量等）同士を突合する際に、当該レコードの検索キーとして使用される。 【０１１５】 次に、「突合値１（突合項目値１）」〜「突合項目値ｎ（例えば、突合項目値１０）」は、各行のレコードを上記のように突合する際に使用する突合項目値を格納する。即ち、データ管理システムは、行管理テーブルの作成時（データの各レコード読込時）に、テーブル管理テーブルの「レコード制御情報」を参照して判断した当該読込レコード（管理対象レコード）の列ＩＤに対応して、列管理テーブルにおいて当該列ＩＤのデータ項目について「カラムサブＩＤ」に格納したオブジェクトＩＤの値を参照し、当該オブジェクトＩＤについて対象管理テーブルの対応する「オブジェクトＩＤ」の「位置（ポジション）」を参照して、当該位置（ポジション）にある行管理テーブルの対応レコードの「突合値１」〜「突合値ｎ」のいずれかに、当該オブジェクトＩＤに対応するオブジェクトの値を格納する。このとき、列管理テーブルにおいて当該オブジェクトに対応する前記列ＩＤの値を、上記データ解析・読込時に読込レコードから取得（当該レコードの対応する項目値を取得）して、当該オブジェクトＩＤに対応するオブジェクトの値を行管理テーブルの「突合項目値」に格納する。例えば、列管理テーブルでは、伝票ヘッダレコード（テーブルＩＤ「９９９９９０１５０１１）については、「カラムサブＩＤ」において発注店舗コード（店コード）のオブジェクトＩＤ「１１」が指定されているため、このデータ項目の値であるオブジェクトＩＤ「１１」についてシステム対象管理テーブルを参照し、当該オブジェクトＩＤ「１１」についての行管理テーブルの突合項目値としての「位置（ポジジョン）」を判断すると共に、当該オブジェクト（店コード）の列ＩＤの値（「１００」）を読込レコードから取得して、その値「１００」を行管理テーブルの１番目の突合値として「突合項目値１」に格納する（行管理テーブルの２行目のレコード参照）。また、「基本値１（基本項目値１）」〜「基本項目値ｎ（例えば、突合項目値５）」は、列管理テーブルの「基本項目指定順序」に指定した順序にしたがって、読込レコードから基本項目値を抽出して格納するものである。 【０１１６】 次に、「基本項目指定順序」は、当該列ＩＤのデータ項目の項目値を行管理テーブルの何番目の基本情報（基本項目値）に複写するかを示すものである。即ち、行管理テーブルは、インデックスとしての行ＩＤ以外にも、各読込レコードの基本情報（例えば、伝票ヘッダレコードの伝票番号、発注日、納品日、検収日等、伝票明細行レコードの商品コード、商品名、発注数量、検収数量等）を所定数の「基本項目値」（＝データ項目）の値として格納するが、かかる基本項目値に特定の列ＩＤのデータ項目の値を複写して格納する場合に、当該列ＩＤのデータ項目の値を、「基本項目指定順序」に指定した順番で行管理テーブルの基本項目値に複写する。また、「列サブＩＤ」は、当該列ＩＤのデータ項目の項目値を行管理テーブルの「突合項目」（＝データ項目）の値として格納する場合に、当該列ＩＤの「対象オブジェクト」のオブジェクトＩＤの値を指定する。即ち、行管理テーブルは、インデックスとしての行ＩＤ以外にも、各読込レコードについて、例えば、発注データと入荷予定データとの間での数量の相違（数量不足）を判断して納品書等に訂正情報を記載するために、発注データ及び入荷予定データの対応レコードを突合する際の検索キーとなる「突合項目」の値を格納するが、かかる場合に、当該列ＩＤの対象オブジェクトのオブジェ宇土ＩＤ（当審注：「オブジェクトＩＤ」の誤記と認める。）の値を、行管理テーブルの「突合項目」の値として格納する。例えば、列管理テーブルでは、ファイルヘッダレコード（テーブルＩＤ「９９９９９０１５０１」）については、「基本情報作成順序」において「発注企業コード」、「受注企業コード」、「データ種別」、「データ作成日」、「レコード件数」が、それぞれ、「１」、「２」、「３」、「４」、「５」の順序で指定されているため、これらのデータ項目の値（「１１１１１１」、「９９９９９９」、「５０」、「２００５０８１７」、「６１」）を、その順番で、行管理テーブルの当該レコードの「基本項目値１」〜「基本項目値５」にそれぞれ格納する。同様に、列管理テーブルでは、伝票ヘッダレコード（テーブルＩＤ「９９９９９０１５０１１」）については、「基本情報作成順序」において「伝票番号」、「発注日」、「納品日」、「検収日」が、それぞれ、「１」、「２」、「３」、「４」の順序で指定されているため、これらのデータ項目の値（「４９２１８３３９」、「２００５０１１３」、「２００５０１１９」、「２００５０１１９」）を、その順番で、行管理テーブルの当該レコードの「基本項目値１」〜「基本項目値４」にそれぞれ格納する。同様に、列管理テーブルでは、伝票明細行レコード（テーブルＩＤ「９９９９９０１５０１１１」）については、「基本情報作成順序」において「ＧＴＩＮ」、「規格カナ」、「品名カナ」、「発注数量」、「検収数量」が、それぞれ、「１」、「２」、「３」、「４」、「５」の順序で指定されているため、これらのデータ項目の値（「０４９３６０６８９２７２１７」、「＊＊＊（規格名）」、「＊＊＊（品名」、「３０」、「３０」）を、その順番で、行管理テーブルの当該レコードの「基本項目値１」〜「基本項目値５」にそれぞれ格納する。」 （５） 【図４７】 「  」 ３ 引用文献３ 原査定の拒絶の理由に引用された上記引用文献３には、次の事項が記載されている。 （１） 【図１】 「  」 （２） 段落【００１５】−【００２２】 「【発明を実施するための最良の形態】 【００１５】 以下、本発明を実施するための最良の形態として、データ転送におけるシリアライズ方法、データフォーマット及びデータ転送装置の実施の形態を図面に従って説明する。 【００１６】 図１は、本発明の実施の形態であって、データ転送装置の全体構成を示し、図２はその場合におけるシリアライズ方法のデータフォーマットの例を示す。 【００１７】 データ転送装置は、送信側装置１と受信側装置５とを備え、送信側装置１のデータ送信部４と、受信側装置５のデータ受信部８はデジタル通信が可能な通信路（ネットワーク）を介して接続されている。データ送信部４とデータ受信部８の間の通信は、ＴＣＰ／ＩＰ等の信頼性のあるプロトコルを用いて通信内容にエラーが生じないものとする。 【００１８】 送信側装置１は、データの集合体であるデータオブジェクトをソフトウエアで処理可能なデータ形式で記憶した送信側記憶部２と、送信側記憶部２のデータオブジェクトの各データを、通信路で送受信可能なデータ形式にシリアライズするシリアライズ部３と、シリアライズ部３で作成された通信データを送信するデータ送信部４とを有している。 ・・・（中略）・・・ 【００２１】 受信側装置５は、通信路を介してデータ送信部４から送信された通信データを受信するデータ受信部８と、データ受信部８で受信された通信データ１５をストラクチャ（デシリアライズ）して通信データ１５をソフトウエアで処理可能なデータ形式にする処理するストラクチャ部７と、ストラクチャ部７でスクラクチャ（復元）されたデータオブジェクトを記憶する受信側記憶部６とを有している。 【００２２】 受信側記憶部６はストラクチャ部７に総データリスト１６（総データリスト１１と同じものを受信側でも共有している）を送り、ストラクチャ部７にストラクチャ処理を依頼する。ストラクチャ部７は、受信した通信データ１５を先頭から読み取り、対応する省略フラグビットが１であればそのデータのストラクチャを行わず（省略フラグビットが１のデータは送信側で省略されているのでストラクチャされない）、対応する省略フラグビットが０であればそのデータのストラクチャを行い、各データ１７を総データリスト１６のデータ項目と関連付けてストラクチャして受信側記憶部６にソフトウエアで処理可能なデータ形式のデータオブジェクトとして格納する。その省略フラグビットの判断方法は図４のフローチャートに従うものとする。但し、図４のＭは自然数であって、総データのうちの何番目であるかを示す。また、Ｎは自然数であって、８個のデータからなる通信データ列の何番目のデータであるかを示す。」 ４ 引用文献４ 原査定の拒絶の理由に引用された上記引用文献４には、次の事項が記載されている。 （１） ５９欄２０−４７行 「The default serialization provided by Java writes the class name of the data element then the attribute name and the value for each attribute of the data element. The size benefit provided by the present invention comes from writing a code representing the element type instead of the type name and the attributes that are required to recreate the data objects without writing the names of the attributes. For example, an integer is written as follows: The class name [java.lang.Inter], the attribute name [value java.lang.Number], the attribute value [00 00 00 08] size: 81 bytes. Alternatively enhanced serialization: the code [01], the value [00 00 00 08] size: 11 bytes. With reference now to FIGS. 107A-107C, a diagram illustrating an object array is depicted in accordance with a preferred embodiment of the present invention. Typically user defined data classes extend a class similar to that shown in FIGS. 107A-107C. Specifically, FIGS. 107A-107C illustrates an object array that contains all the attributes of the user-defined data. The subclasses just provide getter/setter methods (i.e. getXXX( ) and setXXX( ) methods where XXX is a particular attribute name). These getter and setter methods just access the object array in FIG. 107 using getData and setData methods based on an index for the attribute. This is a common extension of using an indexed-array data model combined with an attribute-based object model. The advantage of this model is to reduce the serialization size by removing the attribute names that are typically outputted in the default Java serialization mechanism.」 （当審訳： （Ｊａｖａ（登録商標）で提供されるデフォルトのシリアル化では、データ要素のクラス名、そして、項目の名前及び値を書き込む。本発明で提供されるサイズ上の利点は、項目の名前を書き込むことなく、データオブジェクトを再び生成するのに必要とされる型の名前と項目に替えて、要素の型を表す符号を書き込むことによって得られる。例えば、ある整数は以下のように書き込まれる： クラス名[java.lang.Inter]、項目の名前[value java.lang.Number]、項目の値[00 00 00 08]、サイズは８１バイトである。別法として、改良シリアル化では： 符号[01]、値[00 00 00 08]、サイズは１１バイトである。 図１０７Ａ−図１０７Ｃを参照すると、本発明の好適な実施例によるオブジェクトの配列を表すダイアグラムが示される。通常、ユーザ定義データのクラスは、図１０７Ａ−図１０７Ｃに示したものと同様のクラスを継承する。具体的には、図１０７Ａ−図１０７Ｃは、ユーザ定義データの全ての属性を含むオブジェクトの配列を図示する。サブクラスは、単に、getter／setterメソッド（すなわち、getXXX()と、setXXX()メソッド。ここで、XXXは、特定の項目の名前である。）を提供する。これらのgetter及びsetterメソッドは、単に、その項目に対するインデックスに基づき、getDataと、setDataメソッドとを用いて、図１０７のオブジェクトの配列にアクセスする。これは、項目をベースとするオブジェクトモデルと組み合わせて、インデックス付き配列のデータ・モデルを利用する、通常の継承である。このモデルの利点は、通常、デフォルトのＪａｖａ（登録商標）シリアル化のメカニズムにおいて出力される項目の名前を除去する（removing）ことによって、シリアル化のサイズを削減することである。） 第５ 対比・判断 １ 本願発明１について （１） 対比 本願発明１と、引用発明１とを対比すると、以下のことがいえる。 ア 引用発明１の「クライアントシステム」は、本願発明１の「情報を処理するコンピュータ」に相当する。 イ 引用発明１の「オブジェクトがシリアル化される符号化は、最も高いスーパークラスから開始されて現在のクラスで終わる、各クラスのオブジェクトのクラスとそれに続くフィールドによって構成され」ているものであって、「通常のＪａｖａのクラスは、クラスとそれに続くフィールドの符号化を書き込むことによってシリアル化され」ることは、本願発明１の「オブジェクトのクラスに関連付けられた情報を記載するステップ」に相当する。 ウ 引用発明１の「オブジェクトがシリアル化される符号化は、最も高いスーパークラスから開始されて現在のクラスで終わる、各クラスのオブジェクトのクラスとそれに続くフィールドによって構成され、宣言の順序に影響されないために、各フィールドは、標準的な順序で（in a canonical order）配置され、 通常のＪａｖａのクラスは、クラスとそれに続くフィールドの符号化を書き込むことによってシリアル化される」ことは、本願発明１の「前記オブジェクトのフィールド名を予め定めた順番に従って並べ替えて、当該フィールド名を削除して、当該フィールド名に対応するフィールド値を並べ替えたフィールド名の順に記載するステップ」と、「前記オブジェクトを予め定めた順番に従って並べ替えて、当該フィールド名に対応するフィールド値を並べ替えた順に記載するステップ」である点で共通するといえる。 エ 引用発明１の「通常のＪａｖａのクラスは、クラスとそれに続くフィールドの符号化を書き込むことによってシリアル化される」ことは、本願発明１の「前記記載されたクラスに関連付けられた情報と、前記並べ替えられたフィールド値をシリアル化されたデータとして出力するステップ」に相当する。 オ 引用発明１の「シリアル化の方法」は、本願発明１の「シリアル化方法」に相当する。 カ よって、本願発明１と引用発明１との一致点・相違点は次のとおりであるといえる。 ［一致点］ 「情報を処理するコンピュータにおいて、 オブジェクトのクラスに関連付けられた情報を記載するステップと、 前記オブジェクトを予め定めた順番に従って並べ替えて、フィールド値を並べ替えた順に記載するステップと、 前記記載されたクラスに関連付けられた情報と、前記並べ替えられたフィールド値をシリアル化されたデータとして出力するステップとを有するシリアル化方法。」 ［相違点１］ 本願発明１では、オブジェクトの「フィールド値」を記載するステップは、「前記オブジェクトのフィールド名を予め定めた順番に従って並べ替えて、当該フィールド名を削除して、当該フィールド名に対応するフィールド値を並べ替えたフィールド名の順に記載するステップ」であるのに対して、引用発明１では、「各フィールドは、標準的な順序で（in a canonical order）配置され」るものであって、オブジェクトの「フィールド名」を並べ替えてから、オブジェクトの「当該フィールド名を削除して」、フィールド値を「フィールド名」の順に記載することが特定されていない点。 （２） 当審の判断 本願発明１の上記［相違点１］に係る、「前記オブジェクトのフィールド名を予め定めた順番に従って並べ替えて、当該フィールド名を削除して、当該フィールド名に対応するフィールド値を並べ替えたフィールド名の順に記載するステップ」を有するという構成は、上記引用文献１−４には記載されておらず、周知技術であるともいえない。 引用文献２には、データ管理システム（例えば、売上管理システム）における各種「テーブル」の項目と値を、３つの物理テーブル（列管理テーブル、行管理テーブル、値管理テーブル）で格納・管理することが記載され、「行管理テーブル」には「行ＩＤ」と「識別子」を格納することが記載され、さらに、「行管理テーブル」の作成時に、「行管理テーブル」の「識別子」を構成するデータ項目を、「識別子作成順序」によって予め指定された順序で組み合わせること、「行管理テーブル」の「基本項目」を、「基本項目指定順序」（「基本項目作成順序」）によって予め指定された順番で複写することは開示されている。 しかしながら、引用文献２は、データ管理システム（例えば、売上管理システム）における各種「テーブル」の項目と値を、行管理テーブルなど３つの物理テーブルで格納・管理するためのものであって、オブジェクトの「シリアル化」、「逆シリアル化」に関する引用発明１に対して、引用文献２に記載される、各種「テーブル」の項目と値を、行管理テーブルなど３つの物理テーブルで格納・管理するという技術的事項を組み合わせるべき起因、動機付けは見い出せない。 また、引用文献２には、本願発明１の上記［相違点１］のように、オブジェクトをシリアル化する際に、オブジェクトの「フィールド名」を並べ替え、「当該フィールド名を削除して」、フィールド値を「フィールド名」の順に記載する処理を行うことは開示されていない。 引用文献３には、オブジェクトのシリアル化を行う装置と逆シリアル化を行う装置とを組み合わせて、通信システムを形成する周知技術は開示されているものの、本願発明１の上記［相違点１］のように、オブジェクトをシリアル化する際に、オブジェクトの「フィールド名」を並べ替え、「当該フィールド名を削除して」、フィールド値を「フィールド名」の順に記載する処理を行うことは開示されていない。 引用文献４には、通常、オブジェクトをシリアル化する場合に出力される「項目の名前」を除去する（removing）ことによって、シリアル化のサイズを削減することが開示されているものの、本願発明１の上記［相違点１］のように、オブジェクトをシリアル化する際に、オブジェクトの「フィールド名」を並べ替え、「当該フィールド名を削除して」から、フィールド値を「フィールド名」の順に記載する処理を行うことは開示されていない。 したがって、本願発明１は、当業者であっても引用文献１−４に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 ２ 本願発明２−４について 本願発明２−４も、本願発明１の上記［相違点１］に係る、「前記オブジェクトのフィールド名を予め定めた順番に従って並べ替えて、当該フィールド名を削除して、当該フィールド名に対応するフィールド値を並べ替えたフィールド名の順に記載するステップ」を有するという構成と、同一の構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用文献１−４に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。 ３ 本願発明５について （１） 対比 本願発明５と、引用発明２とを対比すると、以下のことがいえる。 ア 引用発明２の「クライアントシステム」は、本願発明５の「情報を処理するコンピュータ」に相当する。 イ 引用発明２の「オブジェクトがシリアル化される符号化は、最も高いスーパークラスから開始されて現在のクラスで終わる、各クラスのオブジェクトのクラスとそれに続くフィールドによって構成され、宣言の順序に影響されないために、各フィールドは、標準的な順序で（in a canonical order）配置され、 通常のＪａｖａのクラスは、クラスとそれに続くフィールドの符号化を書き込むことによってシリアル化される」ことによって作成されるデータは、本願発明５の「オブジェクトのフィールド名を予め定めた順番に従って並べ替えて、当該フィールド名を削除して、当該フィールド名に対応するフィールド値を並べ替えたフィールド名の順に記載して、当該オブジェクトのクラスに関連付けられた情報とともにシリアル化されたデータ」と、「オブジェクトを予め定めた順番に従って並べ替えて、フィールド値を並べ替えた順に記載して、当該オブジェクトのクラスに関連付けられた情報とともにシリアル化されたデータ」である点で共通するといえる。 上記の点を踏まえると、引用発明２において「通常のＪａｖａのクラスは、そのクラスとそれに続く各フィールドの符号化を読み取ることによって逆シリアル化される」ことは、本願発明５の「オブジェクトのフィールド名を予め定めた順番に従って並べ替えて、当該フィールド名を削除して、当該フィールド名に対応するフィールド値を並べ替えたフィールド名の順に記載して、当該オブジェクトのクラスに関連付けられた情報とともにシリアル化されたデータからクラスに関連付けられた情報を取得するステップ」と、「オブジェクトを予め定めた順番に従って並べ替えて、フィールド値を並べ替えた順に記載して、当該オブジェクトのクラスに関連付けられた情報とともにシリアル化されたデータからクラスに関連付けられた情報を取得するステップ」である点で共通するといえる。 ウ 引用発明２において「スタティック、かつ、非過渡的な各フィールドを、ストリームから読み取」ることは、オブジェクトの各「フィールド」には、フィールドの名前（本願発明５の「フィールド情報」及び「フィールド名」に対応する。）と、フィールドの値とを有することが技術常識といえるから、本願発明５の「前記クラスのフィールド情報を取得するステップ」に相当する。 エ 引用発明２において「スタティック、かつ、非過渡的な各フィールドを、ストリームから読み取り、各フィールドは、宣言の順序に影響されないために、書き込みと同じ標準的な順序で（in the same canonical order）読み出され」ることは、本願発明５の「前記シリアル化されたオブジェクトのデータのフィールド値に対応する値が、前記取得したフィールド名を予め定めた順番で並べ替えたものに対応して並んでいるものとして取得して、前記取得したフィールド名とともに復元するステップ」と、「前記シリアル化されたオブジェクトのデータのフィールド値に対応する値が、予め定めた順番で並べ替えたものに対応して並んでいるものとして取得して、前記取得したフィールド名とともに復元するステップ」である点で共通するといえる。 オ 引用発明２において「通常のＪａｖａのクラスは、そのクラスとそれに続く各フィールドの符号化を読み取ることによって逆シリアル化される」ことは、本願発明５の「前記取得されたクラスに関連付けられた情報、前記フィールド情報、前記フィールド値を復元されたオブジェクトとして出力するステップ」に相当する。 カ 引用発明２の「逆シリアル化の方法」は、本願発明５の「逆シリアル化方法」に相当する。 キ よって、本願発明５と引用発明２との一致点・相違点は次のとおりであるといえる。 ［一致点］ 「情報を処理するコンピュータにおいて、 オブジェクトを予め定めた順番に従って並べ替えて、フィールド値を並べ替えた順に記載して、当該オブジェクトのクラスに関連付けられた情報とともにシリアル化されたデータからクラスに関連付けられた情報を取得するステップと、 前記クラスのフィールド情報を取得するステップと、 前記シリアル化されたオブジェクトのデータのフィールド値に対応する値が、予め定めた順番で並べ替えたものに対応して並んでいるものとして取得して、前記取得したフィールド名とともに復元するステップと、 前記取得されたクラスに関連付けられた情報、前記フィールド情報、前記フィールド値を復元されたオブジェクトとして出力するステップとを有する逆シリアル化方法。」 ［相違点２］ 本願発明５では、「オブジェクトのフィールド名を予め定めた順番に従って並べ替えて、当該フィールド名を削除して、当該フィールド名に対応するフィールド値を並べ替えたフィールド名の順に記載して、当該オブジェクトのクラスに関連付けられた情報とともにシリアル化されたデータからクラスに関連付けられた情報を取得するステップ」を有するのに対して、引用発明２では、「各フィールドは、標準的な順序で（in a canonical order）配置され」るものであって、オブジェクトの「フィールド名」を並べ替えてから、オブジェクトの「当該フィールド名を削除して」、フィールド値を「フィールド名」の順に記載することが特定されていない点。 ［相違点３］ 本願発明５では、「前記シリアル化されたオブジェクトのデータのフィールド値に対応する値が、前記取得したフィールド名を予め定めた順番で並べ替えたものに対応して並んでいるものとして取得して、前記取得したフィールド名とともに復元するステップ」を有しているのに対して、引用発明２では、「各フィールドは、宣言の順序に影響されないために、書き込みと同じ標準的な順序で（in the same canonical order）読み出され」るものであって、オブジェクトのフィールド値を「前記取得したフィールド名を」並べ替えた順番で並べ替えたものとして取得することが特定されていない点。 （２） 当審の判断 「フィールド名」について互いに関連する、上記［相違点２］、［相違点３］について、まとめて検討する。 上記１「（２） 当審の判断」のとおり、オブジェクトの「シリアル化」のための、上記［相違点１］に係る、「前記オブジェクトのフィールド名を予め定めた順番に従って並べ替えて、当該フィールド名を削除して、当該フィールド名に対応するフィールド値を並べ替えたフィールド名の順に記載するステップ」を有するという構成が、上記引用文献１−４には記載されておらず、周知技術であるともいえない以上、当然に、オブジェクトの「シリアル化」に対応した「逆シリアル化」に関する、上記［相違点２］、［相違点３］に係る、「オブジェクトのフィールド名を予め定めた順番に従って並べ替えて、当該フィールド名を削除して、当該フィールド名に対応するフィールド値を並べ替えたフィールド名の順に記載して、当該オブジェクトのクラスに関連付けられた情報とともにシリアル化されたデータからクラスに関連付けられた情報を取得するステップ」、及び、「前記シリアル化されたオブジェクトのデータのフィールド値に対応する値が、前記取得したフィールド名を予め定めた順番で並べ替えたものに対応して並んでいるものとして取得して、前記取得したフィールド名とともに復元するステップ」を有するという構成についても、上記引用文献１−４には記載されておらず、周知技術であるともいえない。 ４ 本願発明６−１１について 本願発明６−１１も、本願発明１の上記［相違点１］の構成と、あるいは、本願発明５の上記［相違点２］、［相違点３］の構成と、（実質的に）同一の構成を備えるものであるから、本願発明１または５と同様の理由により、当業者であっても、引用文献１−４に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。 第６ 原査定について 審判請求時の補正により、本願発明１−１１は、本願発明１の上記［相違点１］に係る、「前記オブジェクトのフィールド名を予め定めた順番に従って並べ替えて、当該フィールド名を削除して、当該フィールド名に対応するフィールド値を並べ替えたフィールド名の順に記載するステップ」を有するという技術的事項と、あるいは、本願発明５の上記［相違点２］、［相違点３］に係る、「オブジェクトのフィールド名を予め定めた順番に従って並べ替えて、当該フィールド名を削除して、当該フィールド名に対応するフィールド値を並べ替えたフィールド名の順に記載して、当該オブジェクトのクラスに関連付けられた情報とともにシリアル化されたデータからクラスに関連付けられた情報を取得するステップ」、及び、「前記シリアル化されたオブジェクトのデータのフィールド値に対応する値が、前記取得したフィールド名を予め定めた順番で並べ替えたものに対応して並んでいるものとして取得して、前記取得したフィールド名とともに復元するステップ」を有するという技術的事項と、（実質的に）同一の事項を備えるものとなっており、当業者であっても、拒絶査定において引用された引用文献１−４に基づいて、容易に発明できたものとはいえない。したがって、原査定を維持することはできない。 第７ むすび 以上のとおり、原査定の理由によっては、本願を拒絶することはできない。 また、他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。 |
| 審決日 | 2023-02-28 |
| 出願番号 | P2021-078133 |
| 審決分類 |
P
1
8・
121-
WY
(H04L)
|
| 最終処分 | 01 成立 |
| 特許庁審判長 |
中野 裕二 |
| 特許庁審判官 |
石井 則之 稲葉 和生 |
| 発明の名称 | シリアル化方法、逆シリアル化方法、情報処理プログラム、情報処理装置及び通信システム |
| 代理人 | 荒木 利之 |