JP2010520549A - データの記憶および管理の方法 - Google Patents

データの記憶および管理の方法 Download PDF

Info

Publication number
JP2010520549A
JP2010520549A JP2009552611A JP2009552611A JP2010520549A JP 2010520549 A JP2010520549 A JP 2010520549A JP 2009552611 A JP2009552611 A JP 2009552611A JP 2009552611 A JP2009552611 A JP 2009552611A JP 2010520549 A JP2010520549 A JP 2010520549A
Authority
JP
Japan
Prior art keywords
electronic
data
storing
document
computer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2009552611A
Other languages
English (en)
Inventor
キム, セン キー,
チー, ホー, ステファン ペー,
ハリム, ハイルル, ニザム アブドル
ウィン, セオン ウォン,
チー, ヨン チョー,
スー, ホエ ナ,
ユアン, カイ チョー,
ケット, ヨン イー,
タック, プーイ ヤップ,
Original Assignee
イーマニュアル システム エスディーエヌ. ビーエイチディー.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by イーマニュアル システム エスディーエヌ. ビーエイチディー. filed Critical イーマニュアル システム エスディーエヌ. ビーエイチディー.
Publication of JP2010520549A publication Critical patent/JP2010520549A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2457Query processing with adaptation to user needs
    • G06F16/24575Query processing with adaptation to user needs using context
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/93Document management systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/40Data acquisition and logging

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】 本発明は、アカウント中心でテーブル無しの駆動方式を使用することにより、物理的ファイリングシステムを模倣する、電子データの記憶、統合、管理、検索、および編成の方法に関する。
【解決手段】 本発明の方法は、アカウント中心の台帳ファイルにおける同じアカウントに関するデータを記憶する。そのような台帳は、ファイリング装置としてDBMSを使って実現される仮想フォルダである。台帳に記憶されるデータは、必要に応じてまとめて検索できる。本発明の他の実施例は、モジュールの実行によって、本発明による記憶、統合、管理、検索、および編成の方法がもたらされるようなモジュールを有するコンピュータプログラムに関する。
【選択図】 図1

Description

本発明は、電子データの記憶および管理の方法に関する。
多くの業界や団体等では、データやドキュメントを必要な時にすぐに見つけることができるように、多量のデータやドキュメントを体系的に記憶する必要がある。
従来の紙ベースのファイリングシステムでは、顧客、製品、トランザクションに関する情報、およびその他のビジネス関連情報は、ドキュメントに記録され、一般的に台帳ファイル(フォルダ)に分類される。紙ベースのファイリングシステムの主な利点は、変化に対する柔軟性、および関連ドキュメントを一か所に分類することによって、データを体系化する方法である。そのようなシステムは一般的であり、現在稼働中であるが、そのような多量のドキュメントの管理は、かなり面倒であり、かさばって扱いにくいものである。例えば、かさばるドキュメントから、必要な情報を探し出すためには、一度に1ページずつを物理的に読む必要がある。そのようなドキュメントの読み出しは、多大な時間を要する上に、必要な情報の多くはあっさりと見落される恐れがあるので、通常は全く実用的ではない。
コンピュータおよびソフトウェア技術の進歩によって、多くのデータベースが生成された。そのデータベースは、多量のデータとドキュメントを記憶・管理するために、様々な異なるコンピュータシステムにおいて使用されている。しかし、技術が進歩するにつれて、システムはますます複雑になってきた。初期に開発されたデータベース技術は、広く行き渡ったソフトウェアとハードウェアの制約によって限定されていた。1970年台におけるIBMによる関連データベース管理システム(RDBMS:Relational Database Management System)技術の最終的な導入によって、データベースデザインにおける、基本的な問題の大部分が解決され始めた。
RDBMSは、データを記憶し、検索するための関連技術を利用するデータベース管理システム(DBMS:Database Management System)である。RDBMSは、行と列からなるテーブルに、データを体系化して記憶する。RDBMSは、通常は多数のテーブルからなり、それぞれのテーブルは、通常は複数の行と列を有する。RDBMSにおいて、情報は、関連する主キー(principal)によって結合し、テーブルにおいて関係データを一緒に分類することによって体系化される。例えば、連絡先情報のテーブルは、顧客の住所と電話番号の情報を記憶し、クレームのテーブルは、顧客からのすべてのクレームを記憶する。
RDBMSでは、特に複雑なシステムが伴う場合は、ユーザが容易にすべての関連ファイルを効率的に検索することができない場合がある。また、既存のデータ管理システムにおいても、特定の取引、製品、またはプロジェクトのアカウントの全履歴を、ユーザが効率的かつ容易に検索することができない。以上の点は、顧客からの問い合わせやクレームを知るために時々アカウントの履歴が必要になるので、問題である。
RDBMSでは、データ正規化と呼ばれる重要なアクティビティが必要である。データ正規化は、それによってビジネスデータが構築されるプロセスであり、冗長性を除去し、データの完全性を維持することができる。データはテーブルにおいて体系化され、それによって、データの操作中において異常が発生する可能性を減少できる。データの正規化は、ひとつの関係を、オリジナルの関係の制限事項を満足するようなさらに小さな関係のセットに分解するためのプロセスである。ビジネスデータは、複数のテーブルにまたがって展開しており、純粋に一部のデータまたは情報を表す。データベースから情報を得るためには、データマイニング技術をプログラミングする必要がある。
しかし、RDBMSの実装では、データを正規化して異なるテーブルに記憶するので、顧客のために同様な記録を構築することは、いくつかのテーブルから個別のデータを検索するために、相当な符号化を必要とする。異なるやり方でデータを保持するいくつかの異なるシステムを使うような、より複雑なアプリケーションを伴うときは、すべてRDBMSを使用するものの、特にテーブルのデザインは各システムによって異なるので、上記の状況はさらに悪くなる。これはRDBMSのデザインにおける最大の問題点の一つを示している。すなわち、同じ要件のセットであっても、異なる人々がシステムをデザインするか、または同じ人であっても違う時にシステムをデザインするか、によって生じる異なるテーブルのデザインを有することができる。
市販の製品のいくつかは、RDBMSにおけるデータ正規化の問題点の解決を試みている。例えば、インターシステムズ(InterSystems)社のCACHEプログラムは、“クラスオブジェクト”を使ったオブジェクト指向の方法においてドキュメントを表すことによって、問題点の解決を試みている。“クラスオブジェクト”とは、プログラムの基本構成要素として使われるランタイムデータ記憶の個別の単位である。CACHEプログラムは、多次元配列におけるデータを記憶する。この方法によって、オブジェクトおよびテーブルとして、データにアクセスできる。それにより、CACHEプログラムの下に記憶されるオブジェクトが、ドキュメントとしてビジュアル化されるようになる。
XML(Extensible Markup Language:拡張可能なマークアップ言語)ドキュメントを記憶することは、RDBMSのもう一つの課題である。XMLはその基準面において、すべての情報を、文字データ、コンテナ状の要素、およびそれらの要素の属性、の階層への前記情報の分類を示すマークアップまたはタグが組み入れられているテキストとして明示する。XML構造は、ドキュメントを表すために使用され、XMLデータベースに記憶される。XMLは、ビジネスドキュメントを表すために使われる情報に対して、ツリーベース構造を記述して適用するためのテキストベース手段を提供する。
しかし、上記の両方の例は、ビジネスユーザが、表わされたドキュメントをビジネスドキュメントとして見るためには役立たない。プログラマにとっては、それらは単にビジネスオブジェクトとしてより、ビジネスのプログラミングアスペクトを達成するときに使うオブジェクトの表現である。それは、古い改訂版のドキュメントが共に記憶されて管理される必要がある時には、さらに難しくなる。
既存の方式のさらなる問題点は、システムが完成する前にビジネス要件が変わるように、アプリケーションの構築とプログラミングには多数の工数がかかるということである。それによって、費用が無駄になり、システムが使用できなくなることもある。
現在、ビジネス要件における変化においては、システムがそれほど効率的にはならない既存のアプリケーションを修正して再プログラミングする必要があり、あるいは、新しいテーブルセット全体をもう一度やり直してデザインしなければならなくなる。
従って、情報が容易に検索できて必要な時にすぐに見つかるような、簡単で効率的な方法で、コンピュータの電子情報を記憶して管理する方法を提供する必要がある。
本発明の目的は、物理的ドキュメントの記憶・管理システムをシミュレートするような、電子データの記憶および管理の方法を提供することによって、上述する制約と欠点に対処してそれを克服することである。
本発明の他の目的は、ビジネスデータをフィールドのグループに分解して、ビジネスデータまたは情報の密接した分類をなくさせるような、データ正規化を伴うRDBMSを使って、ビジネスデータの記憶の複雑性を解決することである。
本発明の態様によって、ユーザは、物理的ファイリングシステムを模倣するやり方で、電子データを記憶、検索、およびルーティングすることができる。
本発明の別の態様は、台帳ファイル(フォルダ)、ドキュメント、および紙を使う物理的ファイリングシステムをシミュレートする、電子データの記憶および管理の方法を提供することである。本発明の方法は物理的ファイリングシステムをシミュレートする。そこでは、情報がドキュメント形式で記録され、仮想台帳ファイルに記憶される。さらに、ドキュメントを台帳ファイルに登録することによって、登録が影響を受ける。
本発明の別の態様は、アカウント中心または顧客中心のファイリングシステムを提供する。そこでは、同じ顧客の情報が、多数のテーブルにまたがって展開するのではなく、同じ場所に記憶される。
本発明のさらに別の態様は、アカウントの細目を記憶するセクションと、アカウントの少なくとも一つのアクティビティ要約を記憶する領域と、アカウントに関連する情報を記憶する少なくとも一つの電子ページと、を備えた仮想台帳フォルダを有する記憶手段を提供する。
本発明の別の態様は、紙のドキュメントから得たデータが、コンピュータが読み取れる所定の構造に変換されるような、電子データの記憶・管理システムの方法を提供する。
本発明のさらに別の態様は、完全に追跡可能なアカウントの事象配列を形成するために、所定の構造に変換されたデータが、年代順に電子ページ上に付加されるような、電子データの記憶および管理の方法を提供する。
本発明の別の態様では、データの検索、およびアカウントに関するアクティビティ要約の生成が可能である。
本発明のさらに別の態様は、従来のRDBMSテーブル駆動手法に比べて、システムのバックエンドデザインを容易にするような、電子データの記憶および管理の方法を提供する。本発明の別の態様は、台帳ファイリングシステムに記憶されるドキュメントの全面追跡記録を有する能力を提供する。
本発明のさらに別の態様は、前記の方法を実施するために、コンピュータによって実行可能な命令のプログラムを明白に具体化する、コンピュータが使用できる媒体を提供する。
本発明の電子台帳ファイリングシステムは、ドキュメントとしてデータあるいは情報を記憶する台帳ファイリングシステムをシミュレートすることを目的とする。この台帳ファイリングシステムは、実業界における情報とデータを取り扱う際の、最良の実証済みの手法の一つである。本発明のドキュメントベースの台帳ファイリングシステムは、データの記憶と検索のより良い方法を提供するのみでなく、データの登録または更新に対して取られる各アクションの追跡記録をユーザに提供する。明らかに、人間がデータを扱うやり方と同様な方法でユーザが使うことができる技術は、非常に効果的である。電子データの記憶、統合、管理、検索、および編成の方法に関する本発明の一実施例は、
(a)データを取得し;
(b)取得した前記データを、コンピュータが読み取れる所定の構造を有する電子ドキュメントに変換し;
(c)すべての変換データが記憶される一時的な記憶手段に、前記電子ドキュメントを記憶し;
(d)前記電子ドキュメントを記憶するために、目的ファイルを識別し;
(e)もっとも最近の電子ドキュメントが記録される、前記目的ファイルの所定の電子ページを検索し;
(f)検索した前記ページに、前記電子ドキュメントを年代順に付加し;
(g)付加した前記電子ドキュメントのデータに従って、前記目的ファイルを更新し;
(h)特定の記憶手段に、前記目的ファイルを記憶する、
工程からなることを特徴とする。
上記の方法はアカウント中心でテーブル無しの駆動方法であり、同じアカウントの電子ドキュメントが同じ場所に分類されて記憶される。
本発明の他の実施例は、
i) アカウントの細目を記憶するためのセクションと;
ii) アカウントのアクティビティ要約を記憶するための少なくとも一つの電子ページと;
iii) 所定の構造に配列された複数のデータを、少なくとも一つの電子ドキュメントに記憶するための少なくとも一つの電子ページと、
を備えた、少なくとも一つの仮想フォルダを備えた少なくとも一つの記憶手段を有する、テーブル無しの駆動手法を利用する関連データベースにおいて使用するための、コンピュータベースのファイリングシステムを提供する。
本発明の方法またはシステムは、アカウント中心でテーブル無しの駆動方法であり、同じアカウントの電子ドキュメントが同じ場所に分類されて記憶される。
本発明のさらに他の実施例は、紙の資源から得たデータを記憶、統合、管理、検索、および編成するためのモジュールを有するコンピュータプログラムを提供する。前記モジュールの実行によって、データを記憶して管理するための前記方法がもたらされる。
本発明のさらに他の実施例は、
i) プロセッサと;
ii) 前記プロセッサに動作可能なように接続されたメモリ装置と;
iii) 前記プロセッサに動作可能なように接続された記憶媒体と、
を少なくとも備えたコンピュータシステムに関し、プロセッサによるモジュールの実行によって、データを記憶して管理するための前記方法がもたらされるようなモジュールを、前記メモリ装置が記憶することを特徴とする。
図1は、電子データを記憶し、管理するための本発明の一実施例による方法の工程系統図である。 図2は、本発明の一実施例による発明の詳細な説明に記載されたライン0、ドキュメント0、およびePagesからなるe−Ledgerの概念を説明するための図である。 図3は、本発明の台帳ファイリングシステム、および発明の詳細な説明に記載されたラインゼロ、ドキュメントゼロ、およびドキュメントXが物理的ファイリングシステムに関係するやり方を説明するための図である。 図4は、本発明による多値階層化構造データフォーマットの例を示す図である。 図5は、従来の請求書が、発明の詳細な説明に記載されたD−S−R−Cのフォーマットに構成されるやり方に関する例を示す図である。 図6は、発明の詳細な説明に記載されたePageが10個の列からなり、それぞれの列は128バイトのサイズを有し、1280バイトのePage(10×128)を形成するという例を示す図である。 図7は、従来のテーブルベースのDBMSを使ったePageインプリメンテーションの例を示す図である。 図8は、発明の詳細な説明に記載されたトランザクションeLedgerとドキュメントプロセッサ(eDP)が相互作用して、登録と更新の工程を実行するやり方を示す図である。 図9は、通常のDBMSテーブルを使って実現される、発明の詳細な説明に記載されたライブラリeLedgerの例を示す図である。
以下、本発明の好ましい実施例を詳細に説明し、添付した図にその例を示す。本発明は、好ましい実施例に関連して記載するが、それらは本発明がその実施例に限定されることを意図するものではない。
本発明は、情報をドキュメントとして記憶して管理するためのシステムと方法に関する。本発明は、あらゆる関連データが適切なアカウント中心の台帳にファイリングされ、そのような台帳が、ファイリング装置としてDBMSを使って実現される仮想フォルダであるような、電子台帳ファイリングシステムを開示するものである。
本発明による方法は、アカウント中心でテーブル無しの駆動方式を使用することにより、ドキュメントの物理的な記憶、統合、管理、検索、および編成を模倣するような、電子データの記憶、統合、管理、検索、および編成の方法に関する。
本発明の電子台帳ファイリングシステムは、1つ以上のDBMSデータベースと、例えば顧客情報管理システム、人的資源管理システム、およびオンライン仕事登録管理システムのようなシステムまたはアプリケーションを表す各データベースと、を備えている。本発明の電子台帳ファイリングシステムは、そのようなシステムの生成、修正、および維持を管理するためのソフトウェアも含む。以下の記述で説明するように、本システムによって、ユーザはそれぞれのシステムを生成およびカスタマイズできる。生成した各システムが、異なるビジネスルールとフローによって、実質的には同じテーブルデザインセットを有することを指摘するのは重要なことである。
図1は、本発明の方法による好ましい実施例のプロセスフローを示す。本発明の一実施例において、電子データの記憶、統合、管理、検索、および編成の方法は、
(a)紙のドキュメントからデータを取得し(100);
(b)取得した前記データを、以下の記述で定義される所定の構造を有する電子ドキュメントに変換し(101);
(c)すべての変換データが記憶される一時的な記憶手段に、前記電子ドキュメントを記憶し(102);
(d)前記電子ドキュメントを記憶するために、目的ファイルを識別し(103);
(e)もっとも最近の電子ドキュメントが記録される、前記目的ファイルの所定の電子ページを検索し(104);
(f)検索した前記ページに、前記電子ドキュメントを年代順に付加し(105);
(g)付加した前記電子ドキュメントのデータに従って、前記目的ファイルを更新し(106);
(h)特定の記憶手段に、前記目的ファイルを記憶する(107)、
工程からなる。
従来のRDBMSを使って実現される本発明のファイリングシステムは、複合データオブジェクトをドキュメントとして記憶し検索するために、RDBMSの使用を効果的に拡張することによって、RDBMSとSQLの問い合わせ言語を補強する。本発明の台帳ファイリングシステムは、RDBMSの固定長列が拡張されることによって、可変長データとそれによるドキュメントオブジェクトの記憶が可能でありながら、SQLの問い合わせの容易さと速度が維持されるような方法によって実現される。要するに、本発明は、検索と報告のためのSQL言語の強力な特質を保ちながら、アカウント、ドキュメント、またはオブジェクトのデータを検索する際に、煩わしい結合構文の多くを削除する。
コンピュータ環境において、データの基準に従って、ドキュメントからのデータは分解され、いくつかのテーブルに記憶される。例えば、請求書のドキュメントは、会社の詳細、合計金額、会計基準などを含み、その他のドキュメントへの添付書類や参考資料も含む。従来のRDBMSシステムは、そのようなデータを分解し、データをいくつかのテーブルに記憶する。それによって、再検討のためにそのドキュメントを検索し再構築する時、非常に複雑になってしまう。しかし、物理的ファイリングシステムでは、ドキュメントはオブジェクトとして扱われるので、ドキュメント中のデータはいくつかの記憶装置に分解されず、一つの完全なドキュメントとして記憶される。従って、本発明の台帳ファイリングシステムは、データと情報が記憶され、物理フォルダにファイリングされ、データが必要な時はドキュメントとして検索される方法を描写することを試みる。
本発明の他の実施例は、
i) アカウント(18)の細目を記憶するためのセクションと;
ii)アカウント(16)のアクティビティ要約を記憶するための少なくとも一つの電子ページと;
iii) 所定の構造に配列された複数のデータを有する、少なくとも一つの電子ドキュメント(14)を記憶するための少なくとも一つの電子ページ(12)と、
を備えた、少なくとも一つの仮想フォルダを備えた少なくとも一つの記憶手段を有する、テーブル無しの駆動手法を利用する関連データベースにおいて使用するための、コンピュータベースのファイリングシステムを提供する。
図2は、本発明によるファイリングシステムの総括図である。図2に示すように、アカウントの細目を記憶するためのセクションは、ラインゼロ(18)によって表わされ、アカウントのアクティビティ要約を記憶するための電子ページは、ドキュメントゼロ(16)によって表わされ、少なくとも一つの電子ドキュメントに記憶するための電子ページは、ePage(12)によって表わされ、電子ドキュメントは、ドキュメントX(14)によって表わされる。図2に示す用語のラインゼロ(18)、ドキュメントゼロ(16)、ePage(12)、ドキュメントX(14)は、以下の記述において定義される。
以下に、本発明において使用される用語をより詳細に説明する。
・eLedger
ここで使われる用語eLedgerは、本発明によるファイリングシステムの仮想キャビネットを表す記憶手段である。それぞれのeLedger(10)は、ドキュメントX(14)からなるラインゼロ(18)、ドキュメントゼロ(16)、および電子ページ(12)の集まりを有する少なくとも一つの仮想フォルダを備えている。ドキュメントX(14)からなるラインゼロ(18)、ドキュメントゼロ(16)、および電子ページ(12)の集まりは、図2に示すアカウント中心の方法によって編成される。
それぞれの仮想フォルダは、多数の電子ドキュメント(14)を保有している、少なくとも一つのラインゼロ(18)、ドキュメントゼロ(18)、および電子ページ(12)を備えている。本発明のeLedger(10)は、通常のDBMSをテーブルとして使うことによって実現される。
・電子ドキュメント(eDocument)
ここで、電子ドキュメントの用語は、紙のドキュメントから得られ、本発明による所定の構造に変換されるデータを定義する用語として使われる。
所定の構造は、符号化システムを備えた階層化ドキュメント構造である。本発明による階層化ドキュメント構造は、図5に示す文字列(20)を形成する行に配列される複数の要素によって形成される。複数の要素は、少なくとも一つの固有の要素コード(22)と少なくとも一つの要素データセット(26)からなる。複数の要素は、少なくとも一つのマーカー(24)によって表示される。
図4は、多値階層化構造データ形式の例を示す。この例は、データが本発明の構造に従って、例えばD−S−R−C形式に編成されるやり方を示す。ここで、Dはドキュメントコードを表し、Sはセクションコードを表し、Rは行コードを表し、Cはフィールドの位置を表す。従来の請求書からのデータが本発明のD−S−R−Cの形式に構築されるやり方の例を、図5に示す。eDocumentは実際には、D−S−R−Cのセクションを表すための若干のマーカー(24)を有する文字列(20)であるということは記す必要がある。この形式は、XML形式と同様であるが、本発明は、タグの代わりに要素を表すマーカーとコードを使用する。それによって、XMLの柔軟性と構造を保ちながら、ドキュメントの記憶要件を最適化できる。
・電子ページ(ePage)
ここで使われる電子ページは、少なくとも一つの電子ドキュメントを記憶する仮想ページを参照する。本発明の電子ページは、可変長データの記憶のために、少なくとも一つの固定長の列を備えている。電子ページは、多数の列ブロックを備えており、それぞれの列は実質的に等しい長さを有する。ePageの列は、例えば図6において1から10行で示される。本発明の好ましい実施例では、列のそれぞれは、好ましくは128バイトのサイズである。
必要に応じて、ePageのサイズは、最適性能を達成するために、カスタマイズされる。図6は、それぞれの列が128バイトであるような、10個の列ブロックを有するePageの例(1,280バイトのePage(10×128))を示す。
前記電子ページ(12)に付加される電子ドキュメント(14)のそれぞれは、新しい列ブロックで始まり、既存の列が満杯の場合、次の新しい列ブロックまで続き、もし既存の電子ページが満杯ならば、電子ページは次の電子ページまで続く。この特徴によって、記憶性能と、その後の検索の速度が向上する。図6の例に示すように、第1の電子ドキュメント(14a)が、電子ページ(12a)の第1の列(例えばライン1)に、第1の列が満杯になるまで、付加される。電子ドキュメント(14a)の残りの部分は、第2の列(例えばライン2)に付加される。この工程は、全電子ドキュメントが電子ページ(12a)に完全に付加されるまで継続する。第2の電子ドキュメント(14b)が、同じ電子ページ(12a)に付加されるときは、第2の電子ドキュメント(14b)が、図6に示す新しい列(例えばライン5)から始まる。同様に、文字列全体が電子ページ(12a)に完全に付加されるまで、第2の電子ドキュメント(14b)は次の新しい列まで続く。図6では、第3の電子ドキュメント(14c)の一部が電子ページ(12a)(例えばライン9と10)に付加されるときに、電子ページ(12a)は満杯になる。次に、新しい電子ページ(12b)が、第3の電子ページ(14c)の残りの部分のために生成され、新しい電子ページ(12b)の新しい列に付加される。
電子ドキュメントがアカウントに登録されるときは常に、所定の電子ページが検索され、電子ドキュメントが所定の電子ページに付加される。所定の電子ページは、もっとも最近の電子ドキュメントが記録されるページである。そのページは常にもっとも最近のページとして認識され、関連電子ドキュメントがアカウントに登録されるときは常に検索されるように、そのページには特定の識別が与えられる。好ましくは、所定の電子ページの識別は、ページNの形式である(ここで、Nは固定した順番のシンボルのセットにおける第一の要素である)。所定の電子ページが電子ドキュメントによって完全に付加されるときは常に、ページの識別はページNに変化する(ここで、Nは前記シンボルセットにおける要素であり、新しいページが生成され、ページNの識別を与えられる)。本発明の好ましい実施例では、ページNは好ましくはページ0であり、Nは好ましくは正の整数である。
例えば、複数の電子ドキュメント(ドキュメントX)がアカウントに登録およびファイリングされるときは常に、それは電子ページ0(ePage 0)に付加される。そして、ePage 0に電子ドキュメントが完全に付加されるときは常に、それは電子ページ1に改名される。図6に示すように、新しい電子ドキュメントがこのアカウントに登録されるときは、それはePage 0(12b)に付加される。ePage 0(12b)が満杯のときは、それはePage N(この場合は1)(12a)に改名され、それに続く電子ドキュメントが新しいePage 0に付加される。
本発明のePageは、それぞれのePageが実際にはテーブルの中のデータの行であるような、通常のDBMSを使って実現される。列(128バイト長の文字データタイプ)は、ePageのラインを表す。従って、10ラインのePageは、DBMSに実現されるときは、それぞれ128バイト長の文字データタイプを含む10個の列を有するテーブルである。キーを形成するために、数個の列が各ePageに付加される。そして、さらに数個の列がePageのインデックスと要約情報を形成するために付加される。図7は、従来のテーブルベースのDBMSを使ったePage実行の例を示す。
・ドキュメントゼロ(Document−0)
ここで使われる用語のドキュメントゼロは、アカウントのアクティビティ要約を記憶する領域を参照する。それは、物理フォルダのインデックスページと同じである。本発明のドキュメントゼロは、可変長データを記憶する。ドキュメントゼロは、電子ドキュメントがシステムに付加されるときに従って更新される。
ドキュメントゼロは、ePage番号が負の1(−1)から始まり、最後のページが負のN(−N)ページとなることを除いて、ドキュメントXと同じやり方で記憶される。関連のドキュメントゼロが検索されるように、それぞれのドキュメントゼロが固有の識別を含む限りは、アカウントのために記憶できるドキュメントゼロのユニット数に制限はない。
ドキュメントゼロ(16)は、図3に示すフロントページの横で切り取られる複数の要約のページを有する物理ファイリングフォルダを実際に模倣する。それはドキュメントXから派生したドキュメントである。アカウントに登録され付加されるそれぞれのドキュメントXは、ドキュメントゼロとライン0の特定の情報を更新し、ドキュメントゼロでの情報変化に対する支持ドキュメントとして機能する。ドキュメントゼロは、アカウントの最新および既存の情報を常に保持する。
・ラインゼロ(Line−0)
本明細書で使われる用語のラインゼロは、関連するアカウントの細目を記憶するセクションを参照する。それは、物理フォルダの要約注記と同じである。このセクションは、データ記憶のための複数の列、検索キーワードを含む列、を有する固定長領域を備えている。
データの報告、検索、およびソートのほとんどは、このラインゼロ(18)上で直接SQL言語を使うことによって達成される。問い合わせキーワードがシステムに入力される場合、キーワードと、データ検索目的のための前記セクションの検索キーワードとのクロスマッチ試験が行われる。本発明による問い合わせキーワードは、データベース問い合わせ言語、好ましくは構造化問い合わせ言語(SQL)である。
・ドキュメントプロセッサ(eDP)
本発明の固有の特長の一つは、その更新プログラムである。システムに登録されるデータはドキュメントベースである。各eLedgerは、例えばePage(12)にeDocument(14)を付加すること、およびドキュメントゼロ(16)とラインゼロ(18)に対してデータを更新することなどの、ある更新プロセスを必要とする。従って、たとえ長さは異なっても、それぞれのドキュメントを処理するために標準ドキュメントプロセッサを採用することが可能である。それは、各Ledger−code-Document Xのペアに更新ルールのセットを含むこと、および、R000がledger、lgcode、accidのフィールドからなるように、各eDocument(14)に対する標準命令行(R000)に付加することによって、達成される。R000フィールドを参照することによって、ドキュメントプロセッサは、辞書(Lxxx−Dxxx)中の更新ルールを相互参照させ、ドキュメントゼロ (16)とラインゼロ(18)を更新する。
本発明は、ドキュメント構造を保存し、そのそれぞれのアカウント(例えば、受取アカウント)にデータをまとめて記憶する。それによって、その後の検索がより洗練され、容易になる。SQL問い合わせを容易にするために、ドキュメントがアカウントに付加されるときに、ユーザインタフェースで選択した特定のデータが、ラインゼロ(16)に投入され、あるいは更新される。さらに検索を向上するために、ユーザインタフェースで選択した特定のデータが、ドキュメントゼロ(16)に更新され、アカウントの要約ドキュメントを形成する。すべての電子ドキュメント(ドキュメントX)(14)は、最も早いものから最も遅いものまで年代順に付加され、完全に追跡可能なアカウントの事象配列を形成する。
より良い記憶性能を達成するために、ドキュメントX(14)は、電子ページ(ePage)と呼ばれる1つまたは複数のセグメントに付加されて記憶される。ePage(12)に記憶されるドキュメントX(14)の量は、ePage(12)のサイズに依存し、ドキュメントX(14)のサイズに依存する。好ましくは、ePage(12)は、前述のように128バイトの倍数に完全にカスタマイズ可能であり、通常のDBMSインプリメンテーションにおいて、128バイト長のデータがハードディスクに順に記憶されるので、その後の検索性能が向上する。
本発明の他の実施例において、電子データの記憶、統合、管理、検索、および編成の方法は、さらに、各ドキュメントに優先順位を割り当てる工程、および、割り当てられた優先順位に従って各ドキュメントを処理する工程を備えている。複数の電子ドキュメント(14)に同じ優先順位が割り当てられると、電子ドキュメント(14)は、システムに提出された日時に従って順に処理される。システムに提出されたそれぞれの電子ドキュメント(14)は、処理されてそれぞれの宛先に登録される前に、最初に一時的な記憶手段に記憶される。この一時的な記憶手段において、電子ドキュメント(14)は、(i)緊急:即時のファイリングが必要;(ii)通常:ドキュメントが順に処理される;または(iii)非緊急:オフピークの期間またはCPUの利用が少ないときにドキュメントが何回かに分けて処理される、に分類される。
目的ファイルに関連電子ドキュメントを付加して更新するときに、一時的な記憶手段に記憶される電子ドキュメントの処理ステータスが更新される。処理ステータスは、付加処理と更新処理が成功であるかまたは失敗であるかを表す指示である。
すべての更新処理を一つのプログラムに簡略化および統一することによって、本発明の方法は、各データ更新のための更新プログラムを符号化するために要する手作業を減らすだけでなく、人為的ミスをなくすために必要な保守作業を減らすことができる。
本発明の他の実施例は、資源から得たデータを記憶、統合、管理、検索、および編成するためのモジュールを有するコンピュータプログラムを開示する。前記モジュールの実行によって、データを記憶して管理するための前記方法がもたらされる。
物理的ファイリングシステムでは、異なるフォルダを記憶するために異なるキャビネットが使われる。それらのキャビネットのそれぞれは、フォルダの異なるタイプを保つために、サイズが変化する。それらのキャビネットは、本発明のeLedgerに等しい。我々は、既存のITシステムのほとんどが、約10個の異なるタイプのeLedgerを利用することによって実現されることに気付いた。そのeLedgerを以下に示す。
1. トランザクションeLedger
2. ライブラリeLedger
3. 辞書eLedger
4. グループeLedger
5. マスタeLedger
6. オペレーションeLedger
7. インデックスeLedger
8. 要約eLedger
9. 監査eLedger
10. 大容量記憶eLedger
物理的ファイリングシステムでは、ユーザは、同じ情報を記憶するために、同じタイプのキャビネットにもかかわらず複数のキャビネットを使用する。同様に、本発明のeLedgerは、同じデータが複数のテーブル(eLedger)に記憶されるが、地域や郵便番号のようなアカウント特性によって分離されるような分散環境で実現される。
従来のRDBMSセグメンテーションと比較した本発明の主な違いは、列の代わりにアカウントに従ってデータが区分されることである。例えば、テーブルは通常のRDBMSとして、縦にではなく横に分割される。これは、縦に分割されるデータは非常に複雑な“結合”SQL文を必要とするので、データ検索とデータベース維持の性能にとって重要なことである。
物理的ファイリングシステムでは、さらに仕切りとラベルを使ってキャビネット内のフォルダが分類される。これは、キーとして台帳コード列をeLedger(テーブル)に付加できる既存のインプリメンテーションにおいて、容易に行うことができる。同じカテゴリーに属するすべてのフォルダは、同じ台帳コードを有し、それ故にフォルダに仮想仕切りを提供する。以下の例では、本概念が通常のDBMSを使って実現されるやり方を説明する。
・トランザクションeLedger
トランザクションeLedgerは、受信箱トレイと同じである。eDocumentの各提出は、それが処理されてそれぞれの宛先に登録される前に、eLedgerを通過する。システムの性能を最適化するために、トランザクションeLedgerに提出されるeDocumentは、緊急(即時のファイリングが必要)、通常(システムに提出された日時に従って、ドキュメントが順に処理される)、または非緊急(オフピークの期間またはCPUの利用が少ないときにドキュメントが何回かに分けて処理される)に分類される。
図8は、トランザクションeLedgerとドキュメントプロセッサ(eDP)が相互作用して、登録と更新の工程を実行するやり方を示す図である。eDocumentがeDPに提示されると、eDPはドキュメント情報を処理し、目的eLedgerやターゲットアカウントのような更新命令を含むシステムデータを抽出する(好ましくは、そのようなデータは行コードR000という固有の行に記憶される)。目的キャビネット(eLedger)が識別されると、対応するアカウントのフォルダが検索される(1)。eDPは、実際には全フォルダは検索せず、電子ページ0とドキュメントゼロだけを検索する。電子ページ0の利用可能なスペースに応じて、前記のようにドキュメントXは電子ページに付加される(2)。そして、更新された電子ページ0(および、ePage 0が充分なスペースを持たない場合、ePage n)は、適切なeLedger(テーブル)に記憶される(5)。ドキュメントXのための更新ルールに基づき、特定の行(R)がドキュメントゼロとラインゼロに更新される(3および4)。
eDocumentが無事にアカウントに登録されてファイリングされると、eDPは、“受信箱トレイ”(トランザクションeLedger)の中のeDocumentのステータスを更新する。そしてそのように処理されたeDocumentは集められ、後でアーカイブeLedgerに移動する。これは、DBMSテーブルのリード/ライト速度がテーブルのサイズに直接影響されるので、システムの性能を向上させるためにある。
失敗した更新はすべて記録されて調査されるので、トランザクションeLedgerは、台帳ファイリングシステムにおいて重要な役割を果たす。これは、更新プロセスにおいて発生した問題に対して、より良いトレーサビリティを提供するだけでなく、問題発生のシステムに対して即時のフィードバックを提供する。
・ライブラリeLedger
各システムは、トラックを維持し、システムで使われる用語を標準化し、さらに一貫した参照を達成するために、ライブラリを必要とする。一般に、標準ライブラリと特定ライブラリの、2種類のライブラリがある。標準ライブラリは、世界中の人々に広く使われ、めったに変わらない用語とコードを含む。標準ライブラリ用語の例として、国名、性別、サルート、郵便番号などがある。特定ライブラリは、限定されたアプリケーションで使われ、組織の部門やジョブタイトルのような、ある組織から別の組織まで通常は異なるコードまたは用語を含む。特定ライブラリは、教育産業の講座コードやストックコードのような、ある産業に特有のコードまたは用語も含む。
ITシステムにおいて、ライブラリの用語とコードは、通常はプルダウンまたは選択のラジオ/チェックマーク・ボックスボタンの形で使われる。代表的なRDBMSインプリメンテーションにおける従来のライブラリテーブルは、最小のオーディット・トレールを有し、ライブラリコード変化の完全な監査履歴は通常維持されない。
前述のように、すべてのeLedger更新は、同じフローと同じ経路を使用する。従って、すべてのライブラリコードの生成または修正には、トランザクションeLedgerにドキュメントを提出することが必要である。
図9は、通常のDBMSテーブルを使って実現されるライブラリeLedgerの例を示す図である。ドキュメントX(14y)は、コードに対する変化の監査履歴としての役目を果たすのであるが、ライブラリeLedgerのドキュメントゼロ(16y)は、システムのライブラリコードの最新のコピーに等しい。
・辞書eLedger
ある意味での辞書eLedgerは、それが、ドキュメントの更新ルール、ビジネスルール、ドキュメントのワークフロー、および検証ルールを含む、すべてのシステム関連のコードとパラメータを記憶するのに使われる点を除いては、ライブラリeLedgerと非常に似ている。辞書eLedgerの記憶と検索のメカニズムは、ライブラリeLedgerと全く同じであり、辞書eLedgerは同じ更新プログラム(eDP)を使用する。
・グループeLedger
グループeLedgerは、基準に基づくアカウントを分類するのに使われる。ユーザは、領域、アカウントコード、またはその他の基準によってアカウントを分類ために選択する。さらに、記憶メカニズムと更新方法は、その他のeLedgerと全く同じである。
・マスタeLedger
マスタeLedgerの機能は、従来のRDBMSシステムに見られるマスタ記録テーブルと同じである。しかし、本発明のeLedgerは、アカウント中心の記憶と検索の方法を提供するので、マスタeLedgerからのデータの記憶と検索は、従来のシステムに比べて非常に簡単である。
本発明の台帳ファイリングシステムによって、ユーザは、複数のマスタeLedgerを定義できる。マスタeLedgerのそれぞれは、固有のラインゼロとドキュメントゼロのデザインを有する。例えば、ユーザは、顧客マスタeLedgerを定義できる。そこでは、ラインゼロは、顧客名、住所、前金、未払金からなり、ドキュメントゼロは、請求書送付先、言及者、および最新の6つのトランザクション履歴などの、より詳細な情報からなる。ユーザは、設備マスタeLedgerも定義できる。そこでは、ラインゼロは、設備ID、名前、日付などの製造者情報、サービスの期日、サービスに費やされる累積アカウントなどからなり、ドキュメントゼロは、最近のいくつかのサービス履歴、仕入先情報などの設備に関するさらに詳細な情報からなる。
ラインゼロとドキュメントゼロのデザインは、検索要件の機能である。特定のデータの検索とソートが必要な場合、ユーザは、ラインゼロフィールドにそれを含んでいる。しかし、ドキュメントゼロは、アカウントに関連し、またときにはビジネスインテリジェンスとアカウントの解析に関連する質問に答えるような、より大規模な情報を含んでいる。
さらに、マスタeLedgerにおける情報の登録と更新は、その他のeLedgersと全く同じである。
・オペレーションeLedger
オペレーションeLedgerは、スケジューリングされたドキュメントおよび時間依存のドキュメントを記憶するために本発明で使われる。本発明の台帳ファイリングシステムは、(1日1回、週に1回、各月の始めの日、または各月曜と金曜日などに)ルーティンの提出を要求したドキュメントにおいて、ドキュメント(eDocument)のもとですべてをカプセル化することによって機能するので、定期的に取られるべきアクションは、オペレーションeLedgerに提出される。
本発明のオペレーションeLedgerは、オペレーションeLedger要件を容易にするためのアカウント中心の記憶システムなので、オペレーションeLedgerのアカウントIDは日付時刻ベースである。ドキュメントXは、そのそれぞれの日付時刻アカウントに登録され、そのドキュメントゼロに対して更新される。スケジューラプログラムは、背後で絶え間なく実行され、現在の日付時刻と一致するすべてのドキュメントゼロを検索し、それらのドキュメントを処理のためにトランザクションeLedgerに提出する。
さらに、オペレーションeLedgerにおける情報の登録と更新は、上記のその他のeLedgersと全く同じである。
・インデックスeLedger
本発明による台帳ファイリングシステムは、情報が各eLedger内に含んでいる各アカウントとインデックスの情報を収集する(クローリングする)ためのプログラムを提供する。索引を付けられた情報は、インデックスeLedger内にeDocumentとして記憶される。インデックスeLedgerの唯一の目的は、より良い検索性能を促進することである。このインデックスeDocumentが記憶され検索されるメカニズムは、その他のeLedgersと全く同じである。
・要約eLedger
本発明が要約eLedgerを使うのは、ユーザ指定の基準に基づいてデータを集約するためである。ユーザは、異なる基準でデータを集約する多数の要約eLedgerを生成でき、情報の異なる“表示”を生成できる。要約eLedgerの例は、領域によって、月によって、アカウントによって、受領された支払い(eDocument)を含む。通常、要約eLedgerはドキュメントゼロを利用しないが、ラインゼロは特に報告と問い合わせのために頻繁に使用される。
要約アカウントが更新されるときは、追跡記録を保つため、および要約が最後にコンパイルされて更新されたのはいつであるかを追跡記録し続けるために、ドキュメントXがアカウントに付加される。さらに、要約eLedgerにおける情報の登録と更新は、その他のeLedgersと全く同じである。
・監査eLedger
本発明は、誤ったトランザクションまたは“不安定な”トランザクションを検出するために、各eLedgerにおいて自己監査を行うための、特別なプログラムを採用する。監査報告が生成され、記録目的のための監査eLedgerに提出される。ユーザは、監査の頻度を指定でき、監査アクティビティのそれぞれにおいて、照合パラメータを設定できる。さらに、監査eLedgerにおける情報の登録と更新は、その他のeLedgersと全く同じである。
・大容量記憶eLedger
従来のファイリングシステムでは、我々は、キャビネットにファイリングできない大きなアイテムを保存するには、保存室を使う。我々は、通常、このかさばるアイテムにラベルを貼って編成し、その後で検索できるようにする。同様に、本発明の台帳ファイリングシステムは、記憶と検索の両方のために性能が最適化されるように、ビデオ、画像、オーディオやその他のマルチメディアのような大きなファイルまたはバイナリデータファイルを記憶可能にする特別なeLedgerからなる。
大容量記憶eLedgerは、1行だけからなるePageを除いては、仮想的にはその他のeLedgersと同じであり、一般的にはラインサイズは128バイトよりも大きいキロ/メガバイト単位である。ファイリングと更新のプロセスは、その他のeLedgersと全く同じである。従って、登録とファイリングのプロセスには、同じ更新プログラムが使われる。
大容量記憶eLedgerのDBMSインプリメンテーションでは、1MBラインサイズの大型の列が、BLOBデータタイプを使用する。バイナリファイルが1MBよりも大きい場合、それは分割されて多数のセグメントに分けられ、多数のePage(テーブルの行)に記憶される。
ePageのラインサイズはカスタマイズ可能であり、記憶と検索の用語における性能にとって、非常に重要である。データを多数のePageに分割することによって、大きなバイナリファイルが検索でき、ユーザにePageを一度に送ることができ、大きなファイル検索の応答時間を途方もなく増やすことができる。それは、ビデオやオーディオストリーミングのような、大きなファイルサイズを転送するためのストリーミング方式を得るアプリケーションにおいては特に当てはまる。
本発明の他の実施例において、資源から得たデータを記憶、統合、管理、検索、および編成するためのモジュールを有するコンピュータプログラムは以下の工程を備えており、前記モジュールの実行は、前記のデータを記憶し、管理するための方法をもたらす:
(a)取得した前記データを、コンピュータが読み取れる所定の構造を有する電子ドキュメントに変換し(101);
(b)すべての変換データが記憶される一時的な記憶手段に、前記電子ドキュメントを記憶し(102);
(c)前記電子ドキュメントを記憶するために、目的ファイルを識別し(103);
(d)もっとも最近の電子ドキュメントが記録される、前記目的ファイルの所定の電子ページを検索し(104);
(e)検索した前記ページに、前記電子ドキュメントを年代順に付加し(105);
(f)付加した前記電子ドキュメントのデータに従って、前記目的ファイルを更新し(106);
(g)特定の記憶手段に、前記更新した目的ファイルを記憶する(107)。
本発明によれば、記憶手段は、データを記憶する少なくとも1つの仮想フォルダを備え、記憶手段は、記憶のニーズに従って、実質的に同じデザインを有する多数の仮想フォルダを備えている。
コンピュータプログラムは、さらに、各電子ドキュメント(14)に優先順位を割り当て、割り当てられた優先順位に従って各電子ドキュメントを処理するモジュールを備えている。複数の電子ドキュメント(14)に同じ優先順位が割り当てられると、電子ドキュメント(14)は、システムに入力された日時に従って順に処理される。
本発明の好ましい実施例では、コンピュータプログラムは、さらに、電子ドキュメント(14)が前記メモリ装置によって受信される場合、プロセッサが電子ドキュメント(14)を更新ルールと相互参照させ、それにより目的ファイルを更新するような、更新ルールのセットからなる更新モジュールを備えている。さらに好ましくは、更新ルールは、以下の工程を備えている:
(i)前記一時的な記憶手段に前記変換された電子ドキュメント(14)を読み出す;
(ii)前記電子ドキュメント(14)を記憶するために、目的ファイルを識別する;
(iii)もっとも最近の電子ドキュメントが記録される、前記目的ファイルの所定の電子ページ(12)を検索する;
(iv)検索した前記ページに、前記電子ドキュメント(14)を年代順に付加する;
(v)付加した前記電子ドキュメント(14)のデータに従って、前記目的ファイルを更新する;
(vi)目的ファイルに関連電子ドキュメント(14)を付加して更新するときに、前記一時的な記憶手段に記憶される電子ドキュメント(14)の処理ステータスを更新する。
処理ステータスは、目的ファイルへの電子ドキュメント(14)の付加処理と更新処理が、成功であるか失敗であるかを表す指示である。
本発明のさらに他の実施例は、
i) プロセッサと;
ii) 前記プロセッサに動作可能なように接続されたメモリ装置と;
iii) 前記プロセッサに動作可能なように接続された記憶媒体と、
を少なくとも備えたコンピュータシステムに関し、プロセッサによるモジュールの実行によって、データを記憶し、管理するための前記方法をもたらすようなモジュールを、前記メモリ装置が記憶することを特徴とする。このデータの記憶、管理方法は、
(a)データを取得し(100);
(b)取得した前記データを、コンピュータが読み取れる所定の構造を有する電子ドキュメントに変換し(101);
(c)すべての変換データが記憶される一時的な記憶手段に、前記電子ドキュメントを記憶し(102);
(d)前記電子ドキュメントを記憶するために、目的ファイルを識別し(103);
(e)もっとも最近の電子ドキュメントが記録される、前記目的ファイルの所定の電子ページを検索し(104);
(f)検索した前記ページに、前記電子ドキュメントを年代順に付加し(105);
(g)付加した前記電子ドキュメントのデータに従って、前記目的ファイルを更新し(106);
(h)特定の記憶手段に、前記目的ファイルを記憶する(107)、
工程からなることを特徴とする。
本発明の特定の実施例に関する前記記述を、説明と記述のために示してきた。しかし、それらは、発明を余すところなく網羅し、または開示した明確な形態に限定するものではなく、当然のことながら変更や修正は可能である。本実施例は、本発明の原理とその実際の応用を最良に説明するために選択され記述されたものであり、それによって他の当業者が本発明と、意図した事項に適するように様々に変更した実施例とを最良に利用することができる。本発明の範囲は、添付した特許請求の範囲とその等価物によって定義されるものである。

Claims (84)

  1. アカウント中心でテーブル無しの駆動方式によって、ドキュメントの物理的な記憶、統合、管理、検索、および編成を模倣する、電子データの記憶、統合、管理、検索、および編成の方法。
  2. (a)データを取得し(100);
    (b)取得した前記データを、コンピュータが読み取れる所定の構造を有する電子ドキュメント(14)に変換し(101);
    (c)すべての変換データが記憶される一時的な記憶手段に、前記電子ドキュメントを記憶し(102);
    (d)前記電子ドキュメントを記憶するために、目的ファイルを識別し(103);
    (e)もっとも最近の電子ドキュメントが記録される、前記目的ファイルの所定の電子ページ(12)を検索し(104);
    (f)検索した前記ページに、前記電子ドキュメント(14)を年代順に付加し(105);
    (g)付加した前記電子ドキュメント(14)のデータに従って、前記目的ファイルを更新し(106);
    (h)特定の記憶手段に、前記目的ファイルを記憶する(107)、
    工程を備えた電子データの記憶、統合、管理、検索、および編成の方法であって、前記方法はアカウント中心でテーブル無しの駆動方法であり、同じアカウントの電子ドキュメント(14)が同じ場所に分類されて記憶されることを特徴とする電子データの記憶、統合、管理、検索、および編成の方法。
  3. 前記方法は、前記目的ファイルに関連電子ドキュメント(14)を付加して更新するときに、前記一時的な記憶手段に記憶される前記電子ドキュメント(14)の処理ステータスを更新する工程を備えることを特徴とする請求項2に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  4. 前記処理ステータスは、目的ファイルへの電子ドキュメント(14)の付加処理と更新処理が、成功であるか失敗であるかを表す指示であることを特徴とする請求項3に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  5. 前記電子ドキュメント(14)の所定の構造は、階層化ドキュメント構造であることを特徴とする請求項2に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  6. 前記所定の構造は、前記階層化ドキュメント構造を定義する符号化システムを備えることを特徴とする請求項5に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  7. 前記階層化ドキュメント構造は複数の要素によって形成されることを特徴とする請求項5または6に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  8. 前記複数の要素は、文字列(20)を形成する行に配列されることを特徴とする請求項7に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  9. 前記複数の要素のそれぞれは、少なくとも一つの固有の要素コード(22)と少なくとも一つの要素データセット(26)を備えることを特徴とする請求項7または8に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  10. それぞれの要素は、少なくとも一つのマーカー(24)によって表示されることを特徴とする請求項9に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  11. 前記所定の電子ページ(12)は常にもっとも最近のページとして認識され、関連電子ドキュメント(14)がアカウントに登録されるときは常に検索されるように、前記所定の電子ページ(12)には特定の識別が与えられることを特徴とする請求項2に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  12. 前記所定の電子ページ(12)の前記識別は、好ましくはページNの形式である(Nは固定した順番のシンボルのセットにおける第一の要素である)ことを特徴とする請求項11に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  13. 前記所定の電子ページ(12)が電子ドキュメントによって完全に付加されるときは常に、ページの識別がページNに変化する(Nは前記シンボルのセットにおける要素であり、新しいページが生成され、ページNの識別を与えられる)ことを特徴とする請求項12に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  14. ページNは好ましくはページ0であり、Nは好ましくは正の整数であることを特徴とする請求項12または13に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  15. 前記電子ページ(12)が可変長データの記憶のための固定長領域を備えたことを特徴とする請求項11から14のいずれかに記載の電子データの記憶、統合、管理、検索、および編成の方法。
  16. 前記電子ページ(12)が少なくとも一つの固定長の列のブロックを備えたことを特徴とする請求項11から15のいずれかに記載の電子データの記憶、統合、管理、検索、および編成の方法。
  17. 前記電子ページ(12)が多数の列ブロックを備え、それぞれの列は実質的に等しい長さを有することを特徴とする請求項11から16のいずれかに記載の電子データの記憶、統合、管理、検索、および編成の方法。
  18. 前記電子ページ(12)が前記列に付加された少なくとも一つの電子ドキュメント備えたことを特徴とする請求項11から17のいずれかに記載の電子データの記憶、統合、管理、検索、および編成の方法。
  19. 前記電子ページに付加された前記ドキュメント(14)が新しい列ブロックで始まり、既存の列が満杯の場合、次の新しい列ブロックまで続くことを特徴とする請求項11から18のいずれかに記載の電子データの記憶、統合、管理、検索、および編成の方法。
  20. 前記電子ページに付加された前記ドキュメントが、既存の電子ページが満杯の場合、次の電子ページまで続くことを特徴とする請求項11から19のいずれかに記載の電子データの記憶、統合、管理、検索、および編成の方法。
  21. ユーザインタフェースで選択した要素が、関連するアカウント(18)の細目を記憶するセクションに更新されることを特徴とする請求項2に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  22. 前記セクション(18)は、データ記憶のための複数の列を有する固定長領域を備えることを特徴とする請求項21に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  23. 前記複数の列は検索キーワードを含むことを特徴とする請求項22に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  24. 問い合わせキーワードがシステムに入力される場合、キーワードと、データ検索目的のための前記セクション(18)の検索キーワードとのクロスマッチ試験が行われるように、前記セクション(18)に特定の識別が与えられることを特徴とする請求項21から23のいずれかに記載の電子データの記憶、統合、管理、検索、および編成の方法。
  25. 前記セクションの識別は、好ましくはライン0(18)であることを特徴とする請求項24に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  26. 前記問い合わせキーワードは、データベース問い合わせ言語であることを特徴とする請求項24に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  27. 前記データベース問い合わせ言語は、構造化問い合わせ言語(SQL)であることを特徴とする請求項26に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  28. ユーザインタフェースで選択した要素が、アカウント(16)のアクティビティ要約を記憶する領域に更新されることを特徴とする請求項2に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  29. 前記領域は可変長データを記憶することを特徴とする請求項28に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  30. 電子ドキュメントがシステムに付加される場合に、関連データが前記領域に更新されるように、前記領域には特定の識別が与えられることを特徴とする請求項28または29に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  31. 前記領域の識別は、好ましくはドキュメント0(16)であることを特徴とする請求項30に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  32. 前記領域が、アカウント(16)のアクティビティ要約を記憶する少なくとも1つの電子ドキュメントを備えたことを特徴とする請求項28から31のいずれかに記載の電子データの記憶、統合、管理、検索、および編成の方法。
  33. アカウントの関連アクティビティ要約が要求される場合、関連電子ドキュメントが検索されるように、アクティビティ要約(16)を記憶する電子ドキュメントのそれぞれが、固有の識別を備えたことを特徴とする請求項32に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  34. 前記領域が、アカウントのアクティビティ要約を記憶する電子ドキュメントを記録するための多数のページを備えたことを特徴とする請求項28から33のいずれかに記載の電子データの記憶、統合、管理、検索、および編成の方法。
  35. 前記多数ページに、ページ1から始まるリバースページ付番方式が与えられることを特徴とする請求項34に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  36. 前記記憶手段が、データを記憶する少なくとも1つの仮想フォルダを備えていることを特徴とする請求項2に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  37. 前記記憶手段が、実質的に同じデザインを有する多数の仮想フォルダを備えていることを特徴とする請求項36に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  38. 前記仮想フォルダは、記憶のニーズに従って特定の方法でデザインされることを特徴とする請求項37に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  39. 完全に追跡可能なアカウントの事象配列を形成するために、前記電子ドキュメント(14)が、年代順に前記電子ページ(12)上に付加されることを特徴とする請求項2に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  40. 前記方法は、各電子ドキュメント(14)に優先順位を割り当てる工程、および、割り当てられた優先順位に従って各ドキュメントを処理する工程を備えていることを特徴とする請求項2に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  41. 複数の電子ドキュメントに同じ優先順位が割り当てられた場合、電子ドキュメントは、システムに提出された日時に従って順に処理されることを特徴とする請求項40に記載の電子データの記憶、統合、管理、検索、および編成の方法。
  42. 資源から得たデータを記憶、統合、管理、検索、および編成するためのモジュールを有するコンピュータプログラムであって、
    (a)取得したデータを、コンピュータが読み取れる所定の構造を有する電子ドキュメントに変換し(101);
    (b)すべての変換データが記憶される一時的な記憶手段に、前記電子ドキュメントを記憶し(102);
    (c)前記電子ドキュメントを記憶するために、目的ファイルを識別し(103);
    (d)もっとも最近の電子ドキュメントが記録される、前記目的ファイルの所定の電子ページを検索し(104);
    (e)検索した前記ページに、前記電子ドキュメントを年代順に付加し(105);
    (f)付加した前記電子ドキュメントのデータに従って、前記目的ファイルを更新し(106);
    (g)特定の記憶手段に、前記更新した目的ファイルを記憶する(107)、
    工程を備えた方法を前記モジュールの実行がもたらし、前記方法はアカウント中心でテーブル無しの駆動方法であり、同じアカウントの電子ドキュメント(14)が同じ場所に分類されて記憶されることを特徴とする、資源から得たデータを記憶、統合、管理、検索、および編成するためのモジュールを有するコンピュータプログラム。
  43. 前記プログラムは、各電子ドキュメント(14)に優先順位を割り当てる方法、および、割り当てられた優先順位に従って各ドキュメント(14)を処理する方法を備えていることを特徴とする請求項42に記載のコンピュータプログラム。
  44. 複数の電子ドキュメント(14)に同じ優先順位が割り当てられた場合、電子ドキュメント(14)は、システムに入力された日時に従って順に処理されることを特徴とする請求項43に記載のコンピュータプログラム。
  45. 前記記憶手段が、データを記憶する少なくとも1つの仮想フォルダを備えていることを特徴とする請求項42に記載のコンピュータプログラム。
  46. 前記記憶手段が、実質的に同じデザインを有する多数の仮想フォルダを備えていることを特徴とする請求項45に記載のコンピュータプログラム。
  47. 前記仮想フォルダは、記憶のニーズに従って特定の方法でデザインされることを特徴とする請求項45または46に記載のコンピュータプログラム。
  48. 前記プログラムが更新モジュールを備えていることを特徴とする請求項42に記載のコンピュータプログラム。
  49. 前記更新モジュールが、電子ドキュメント(14)が前記メモリ装置によって受信される場合、プロセッサが電子ドキュメント(14)を更新ルールと相互参照させ、それにより目的ファイルを更新するような、更新ルールのセットを備えていることを特徴とする請求項48に記載のコンピュータプログラム。
  50. 前記更新ルールが、
    (i)前記一時的な記憶手段に前記変換された電子ドキュメント(14)を読み出す;
    (ii)前記電子ドキュメント(14)を記憶するために、目的ファイルを識別する;
    (iii)もっとも最近の電子ドキュメント(14)が記録される、前記目的ファイルの所定の電子ページ(12)を検索する;
    (iv)検索した前記ページに、前記電子ドキュメント(14)を年代順に付加する;
    (v)付加した前記電子ドキュメント(14)のデータに従って、前記目的ファイルを更新する;
    (vi)前記目的ファイルに関連電子ドキュメント(14)を付加して更新するときに、前記一時的な記憶手段に記憶される電子ドキュメント(14)の処理ステータスを更新する、
    工程を備えていることを特徴とする請求項49に記載のコンピュータプログラム。
  51. 前記処理ステータスは、目的ファイルへの電子ドキュメント(14)の付加処理と更新処理が、成功であるか失敗であるかを表す指示であることを特徴とする請求項50に記載のコンピュータプログラム。
  52. i)プロセッサと;
    ii) 前記プロセッサに動作可能なように接続されたメモリ装置と;
    iii) 前記プロセッサに動作可能なように接続された記憶媒体と、
    を少なくとも備えたコンピュータシステムであって、前記メモリ装置はモジュールを記憶し、
    (a)データを取得し(100);
    (b)取得した前記データを、コンピュータが読み取れる所定の構造を有する電子ドキュメントに変換し(101);
    (c)すべての変換データが記憶される一時的な記憶手段に、前記電子ドキュメントを記憶し(102);
    (d)前記電子ドキュメントを記憶するために、目的ファイルを識別し(103);
    (e)もっとも最近の電子ドキュメントが記録される、前記目的ファイルの所定の電子ページを検索し(104);
    (f)検索した前記ページに、前記電子ドキュメントを年代順に付加し(105);
    (g)付加した前記電子ドキュメントのデータに従って、前記目的ファイルを更新し(106);
    (h)特定の記憶手段に、前記目的ファイルを記憶する(107)、
    工程を備えた方法を、前記プロセッサによる前記モジュールの実行がもたらし、
    前記方法はアカウント中心でテーブル無しの駆動方法であり、同じアカウントの電子ドキュメント(14)が同じ場所に分類されて記憶されることを特徴とするコンピュータシステム。
  53. 前記方法は、前記目的ファイルに関連電子ドキュメント(14)を付加して更新するときに、前記一時的な記憶手段に記憶される前記電子ドキュメント(14)の処理ステータスを更新する工程を備えることを特徴とする請求項52に記載のコンピュータシステム。
  54. 前記処理ステータスは、目的ファイルへの電子ドキュメント(14)の付加処理と更新処理が、成功であるか失敗であるかを表す指示であることを特徴とする請求項53に記載のコンピュータシステム。
  55. 前記方法は、各電子ドキュメント(14)に優先順位を割り当てる工程、および、割り当てられた優先順位に従って各ドキュメント(14)を処理する工程を備えていることを特徴とする請求項52に記載のコンピュータシステム。
  56. 複数の電子ドキュメント(14)に同じ優先順位が割り当てられた場合、電子ドキュメント(14)は、システムに入力された日時に従って順に処理されることを特徴とする請求項55に記載のコンピュータシステム。
  57. 前記記憶手段が、データを記憶する少なくとも1つの仮想フォルダを備えていることを特徴とする請求項52に記載のコンピュータシステム。
  58. 前記記憶手段が、実質的に同じデザインを有する多数の仮想フォルダを備えていることを特徴とする請求項52に記載のコンピュータシステム。
  59. 少なくとも一つの仮想フォルダを有する少なくとも一つの記憶手段を備えた、テーブル無しの駆動手法を利用する関連データベースにおいて使用するためのコンピュータベースのファイリングシステムであって、
    i) アカウント(18)の細目を記憶するためのセクション;
    ii)アカウント(16)のアクティビティ要約を記憶するための少なくとも一つの電子ページ;
    iii)所定の構造に配列された複数のデータを有する、少なくとも一つの電子ドキュメント(14)を記憶するための少なくとも一つの電子ページ(12)、
    とを備え、
    前記システムはアカウント中心のシステムであり、同じアカウントの電子ドキュメント(14)が同じ場所に分類されて記憶されることを特徴とするコンピュータベースのファイリングシステム。
  60. 前記セクション(18)は、検索キーワードを含む複数の列を備えた固定長領域であることを特徴とする請求項59に記載の少なくとも一つの仮想フォルダを有する少なくとも一つの記憶手段を備えた、テーブル無しの駆動手法を利用する関連データベースにおいて使用するためのコンピュータベースのファイリングシステム。
  61. 問い合わせキーワードがシステムに入力される場合、キーワードと、データ検索目的のための前記セクション(18)の検索キーワードとのクロスマッチ試験が行われるように、前記セクション(18)に特定の識別が与えられることを特徴とする請求項59に記載の少なくとも一つの仮想フォルダを有する少なくとも一つの記憶手段を備えた、テーブル無しの駆動手法を利用する関連データベースにおいて使用するためのコンピュータベースのファイリングシステム。
  62. 前記セクションの識別は、好ましくはライン0(18)であることを特徴とする請求項61に記載の少なくとも一つの仮想フォルダを有する少なくとも一つの記憶手段を備えた、テーブル無しの駆動手法を利用する関連データベースにおいて使用するためのコンピュータベースのファイリングシステム。
  63. 前記電子ドキュメント(14)の所定の構造は、階層化ドキュメント構造であることを特徴とする請求項59に記載の少なくとも一つの仮想フォルダを有する少なくとも一つの記憶手段を備えた、テーブル無しの駆動手法を利用する関連データベースにおいて使用するためのコンピュータベースのファイリングシステム。
  64. 前記所定の構造は、前記階層化ドキュメント構造を定義する符号化システムを備えることを特徴とする請求項61に記載の少なくとも一つの仮想フォルダを有する少なくとも一つの記憶手段を備えた、テーブル無しの駆動手法を利用する関連データベースにおいて使用するためのコンピュータベースのファイリングシステム。
  65. 前記階層化ドキュメント構造は複数の要素によって形成されることを特徴とする請求項63に記載の少なくとも一つの仮想フォルダを有する少なくとも一つの記憶手段を備えた、テーブル無しの駆動手法を利用する関連データベースにおいて使用するためのコンピュータベースのファイリングシステム。
  66. 前記複数の要素は、文字列(20)を形成する行に配列されることを特徴とする請求項65に記載の少なくとも一つの仮想フォルダを有する少なくとも一つの記憶手段を備えた、テーブル無しの駆動手法を利用する関連データベースにおいて使用するためのコンピュータベースのファイリングシステム。
  67. 前記複数の要素のそれぞれは、少なくとも一つの固有の要素コード(22)と少なくとも一つの要素データセット(26)を備えることを特徴とする請求項65に記載の少なくとも一つの仮想フォルダを有する少なくとも一つの記憶手段を備えた、テーブル無しの駆動手法を利用する関連データベースにおいて使用するためのコンピュータベースのファイリングシステム。
  68. それぞれの要素は、少なくとも一つのマーカー(24)によって表示されることを特徴とする請求項67に記載の少なくとも一つの仮想フォルダを有する少なくとも一つの記憶手段を備えた、テーブル無しの駆動手法を利用する関連データベースにおいて使用するためのコンピュータベースのファイリングシステム。
  69. 前記記憶手段が、実質的に同じデザインを有する多数の仮想フォルダを備えていることを特徴とする請求項59に記載の少なくとも一つの仮想フォルダを有する少なくとも一つの記憶手段を備えた、テーブル無しの駆動手法を利用する関連データベースにおいて使用するためのコンピュータベースのファイリングシステム。
  70. 前記仮想フォルダは、記憶のニーズに従って特定の方法でデザインされることを特徴とする請求項69に記載の少なくとも一つの仮想フォルダを有する少なくとも一つの記憶手段を備えた、テーブル無しの駆動手法を利用する関連データベースにおいて使用するためのコンピュータベースのファイリングシステム。
  71. アカウント(18)の細目を記憶するための前記セクション、および関連アカウント(16)のアクティビティ要約を有する前記ページは、システムに登録された電子ドキュメントのデータに従って更新されることを特徴とする請求項59に記載のテーブル無しの駆動手法を利用する関連データベースにおいて使用するためのコンピュータベースのファイリングシステム。
  72. システムにおいて発生するトランザクションを記憶することを特徴とする請求項59から71のいずれかに記載のコンピュータベースのファイリングシステムの使用。
  73. システムにおいて使用される用語の定義を記憶することを特徴とする請求項59から71のいずれかに記載のコンピュータベースのファイリングシステムの使用。
  74. システムにおいて使用されるコードとパラメータを記憶することを特徴とする請求項59から71のいずれかに記載のコンピュータベースのファイリングシステムの使用。
  75. 特定の基準に従ってアカウントの分類を記憶することを特徴とする請求項59から71のいずれかに記載のコンピュータベースのファイリングシステムの使用。
  76. アカウント情報を記憶することを特徴とする請求項59から71のいずれかに記載のコンピュータベースのファイリングシステムの使用。
  77. スケジューリングされたドキュメントおよび時間依存のドキュメントを記憶することを特徴とする請求項59から71のいずれかに記載のコンピュータベースのファイリングシステムの使用。
  78. 高速検索のためにシステムにおいて使用されるインデックス情報を記憶することを特徴とする請求項59から71のいずれかに記載のコンピュータベースのファイリングシステムの使用。
  79. 報告生成のためのアカウントからの派生情報を記憶することを特徴とする請求項59から71のいずれかに記載のコンピュータベースのファイリングシステムの使用。
  80. 監査報告を記憶することを特徴とする請求項59から71のいずれかに記載のコンピュータベースのファイリングシステムの使用。
  81. マルチメディアやその他のバイナリファイルを記憶することを特徴とする請求項59から71のいずれかに記載のコンピュータベースのファイリングシステムの使用。
  82. 電子データの記憶、統合、管理、検索、および編成のいずれか、あるいはその組み合わせのいずれかにおける請求項2から41のいずれかに記載の方法を利用するコンピュータプログラム。
  83. 電子データの記憶、統合、管理、検索、および編成のいずれか、あるいはその組み合わせのいずれかにおける請求項2から41のいずれかに記載の方法を利用するコンピュータシステム。
  84. 電子データの記憶、統合、管理、検索、および編成のいずれか、あるいはその組み合わせのいずれかにおける請求項2から41のいずれかに記載の方法を利用する関連データベースにおいて使用されるコンピュータベースのファイリングシステム。
JP2009552611A 2007-03-02 2008-03-03 データの記憶および管理の方法 Pending JP2010520549A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
MYPI20070321 MY151687A (en) 2007-03-02 2007-03-02 A method of data storage and management
PCT/MY2008/000017 WO2008108626A1 (en) 2007-03-02 2008-03-03 A method of data storage and management

Publications (1)

Publication Number Publication Date
JP2010520549A true JP2010520549A (ja) 2010-06-10

Family

ID=39738452

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009552611A Pending JP2010520549A (ja) 2007-03-02 2008-03-03 データの記憶および管理の方法

Country Status (9)

Country Link
US (1) US20100198881A1 (ja)
EP (1) EP2132659A4 (ja)
JP (1) JP2010520549A (ja)
KR (1) KR20100015368A (ja)
CN (1) CN101681366A (ja)
CA (1) CA2697785A1 (ja)
MY (1) MY151687A (ja)
TW (1) TW200842630A (ja)
WO (1) WO2008108626A1 (ja)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080320377A1 (en) * 2007-06-25 2008-12-25 France Telecom Document management system
WO2010147454A1 (en) * 2009-06-16 2010-12-23 Emanual System Sdn Bhd System and method of binary data storage and management in database management systems
TWI396987B (zh) * 2009-11-03 2013-05-21 Wistron Corp 儲存檔案於一網路儲存裝置的方法及應用該方法的網路儲存裝置
JPWO2012020456A1 (ja) * 2010-08-11 2013-10-28 株式会社日立製作所 時系列データ処理装置及びその方法
GB2546912A (en) * 2014-10-13 2017-08-02 Seng Kee Kim Emulating manual system of filing using electronic document and electronic file
WO2016060551A1 (en) * 2014-10-13 2016-04-21 Kim Seng Kee A method for mining electronic documents and system thereof
US20170235757A1 (en) * 2014-10-13 2017-08-17 Kim Seng Kee Electronic processing system for electronic document and electronic file
MY172251A (en) * 2014-10-13 2019-11-19 E Manual System Sdn Bhd System generator module for electronic document and electronic filing
CN104966040B (zh) * 2015-05-29 2018-04-17 上海爱数信息技术股份有限公司 一种基于扫码机制的案件文档快速追踪方法
CN105138564A (zh) * 2015-07-23 2015-12-09 小米科技有限责任公司 数据文件的读取方法及装置
SG11201803466QA (en) * 2015-10-30 2018-05-30 Kim Seng Kee A system and method for processing big data using electronic document and electronic file-based system that operates on rdbms
US10339014B2 (en) * 2016-09-28 2019-07-02 Mcafee, Llc Query optimized distributed ledger system
US10614239B2 (en) * 2016-09-30 2020-04-07 Amazon Technologies, Inc. Immutable cryptographically secured ledger-backed databases
GB201703864D0 (en) * 2017-03-10 2017-04-26 Irdeto Bv Secured system operation
CN107656967B (zh) * 2017-08-31 2021-12-24 深圳市盛路物联通讯技术有限公司 一种场景信息处理方法及装置
CN107943661A (zh) * 2017-12-12 2018-04-20 温州市联科科技有限公司 一种数据储存管理系统
CN109918081B (zh) * 2019-03-01 2022-06-03 中安智联未来有限公司 一种编译方法及编译器
CN110443590B (zh) * 2019-08-27 2023-06-30 山东方明药业集团股份有限公司 一种电子人力资源档案管理系统及其管理方法
CN116795296B (zh) * 2023-08-16 2023-11-21 中移(苏州)软件技术有限公司 一种数据存储方法、存储设备及计算机可读存储介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63273947A (ja) * 1987-04-24 1988-11-11 インタ−ナショナル・ビジネス・マシ−ンズ・コ−ポレ−ション デ−タベ−ス・システム
JPH08506911A (ja) * 1992-11-23 1996-07-23 パラゴン、コンセプツ、インコーポレーテッド ファイル・アクセスを行うためにユーザーがカテゴリを選択するコンピュータ・ファイリング・システム
US6009442A (en) * 1997-10-08 1999-12-28 Caere Corporation Computer-based document management system
CA2424487C (en) * 2000-09-28 2012-11-27 Oracle Corporation Enterprise web mining system and method
US7117208B2 (en) * 2000-09-28 2006-10-03 Oracle Corporation Enterprise web mining system and method
US20030220823A1 (en) * 2002-03-27 2003-11-27 Sartorius Peter J. System for providing web-based case management

Also Published As

Publication number Publication date
MY151687A (en) 2014-06-30
EP2132659A4 (en) 2011-03-30
EP2132659A1 (en) 2009-12-16
TW200842630A (en) 2008-11-01
WO2008108626A1 (en) 2008-09-12
KR20100015368A (ko) 2010-02-12
CN101681366A (zh) 2010-03-24
CA2697785A1 (en) 2008-09-12
US20100198881A1 (en) 2010-08-05

Similar Documents

Publication Publication Date Title
JP2010520549A (ja) データの記憶および管理の方法
Chowdhury Introduction to modern information retrieval
US8386435B2 (en) Searchable archive
Lightstone et al. Physical Database Design: the database professional's guide to exploiting indexes, views, storage, and more
US7689574B2 (en) Index and method for extending and querying index
US7720837B2 (en) System and method for multi-dimensional aggregation over large text corpora
US20060173906A1 (en) Model repository
Hobbs et al. Oracle 10g data warehousing
US20040002983A1 (en) Method and system for detecting tables to be modified
Abramowicz et al. Filtering the Web to feed data warehouses
Cecelja Manufacturing Information and Data Systems: Analysis, Design and Practice
US7039648B2 (en) Method and software system for creating customized computerized libraries
US8250024B2 (en) Search relevance in business intelligence systems through networked ranking
US8504552B2 (en) Query based paging through a collection of values
Strate et al. Expert performance indexing for SQL server 2012
EP1116137B1 (en) Database, and methods of data storage and retrieval
US20020178140A1 (en) Method for characterizing and storing data analyses in an analysis database
CN114238241B (zh) 财务数据的元数据处理方法和计算机系统
Strate et al. Expert Performance Indexing in SQL Server
JPH0934906A (ja) 図書管理装置
JP2003058559A (ja) 文書分類方法、検索方法、分類システム及び検索システム
Kashyap Classified Catalogue Code of Ranganathan: A proposal to make it compatible for developing compute based library information systems
Al-Ashwal Accelerating Data Retrieval Using Index Prioritization Approach
Chinchilla et al. MCSA SQL 2016 BI Development Exam Ref 2-pack
Jain Database Management Systems