FORM 2
THE PATENT ACT 1970
(39 of 1970)
&
The Patents Rules, 2003
PROVISIONAL/COMPLETE SPECIFICATION
(See section 10 and rule)13)
1. TITLE OF THE INVENTION
DATA CLEAN UP
2. APPLICANT (S)
(a) NAME: Morinea Techsolv Private Limited
(b)NATIONALITY : Flat No 5/6' 3'd Floor' HoshbanoO Mansion Near Old Ice Factory Naupada (c) ADDRESS: Thane 400602 email: santosh.kamane@,email.com T: 9637267360
3. PREAMBLE TO THE DESCRIPTION
PROVISIONAL
The following specification describes the invention. COMPLETE
The following specification particularly describes The invention and the manner in which it is to be performed.
The present invention relates to scheme for elimination of unwanted data
4. DESCRIPTION (Description shall start from next page.)
5. CLAIMS (not applicable for provisional specification. Claims should start with (he preamble — "l/we claim" on separate page)
6. DATE AND SIGNATURE (to be given at the end of last page of specification)
7. ABSTRACT OF THE INVENTION (to be given along with complete specification on separate page)
Note: •
*Repeat boxes In case of mors than one entry.
•To bo signed by the applicant(s) or by authorized registered patent agent
*Name of the applicant should be given In full, family name In the beginning .
'Con.piete address of the applicant should be given stating the postal Index no./code, state and
country.
'Strike out the column which is/are not applicable

II. FIELD OF INVENTION
A scheme and system for deleting data in a database is disclosed. The scheme and system is configurable, extensible and adaptable to the changing structure of a database to provide a desired deletion. The scheme and system includes identifying data associated with a criterion and identifying tables in a family of tables having said data associated with said criteria
Over the past several years, there has been an increase in the use of databases. A large part of the increase is due to the increased development and use of electronic commerce services.
E-commerce has developed tremendously during the past few years due to the explosive and widespread use of the Internet and, in particular, the World Wide Web. Due to the relatively low costs of developing web sites with E-commerce features, many new companies have been created to exploit the features and capabilities of the "new economy".. Older, more traditional companies are also expanding to the World Wide Web to provide E-commerce services. As a consequence, the use and requirements of databases by web service providers is increasing and continually evolving.
This rapid rate of use and evolution of databases has resulted in many databases undergoing continual modification as a company's business model changes, new E-commerce features are developed, customer needs change, or the focus of the business using the database changes. Additionally, many businesses, while developing their E-commerce applications, are continually refining, re-defining and generally changing the services that will need to be supported by their databases. Consequently, the applications and the underlying database tables that are being developed by these companies to support their E-commerce needs are in a constant state of flux. As a result, databases are constantly in need of maintenance. This maintenance may require the removal or deletion of unwanted data. However, the tools available to support the maintenance and clean-up of databases have been less than satisfactory.
Many of the maintenance tools available today must be specifically designed for each table that forms part of a larger database. Since commercial databases may literally comprise, and require the development, of hundreds and sometimes thousands of custom tables, the effort required to support maintenance in such a custom configuration and/or development is extremely onerous. With many present database maintenance tools, specific routines are often coded or written for each table that is to be maintained, such as, deletion of data that is older than a specified period and deletion of

particular customers, for example. The source code for these specific routines is difficult to maintain. Additionally, when a table in a database is modified such as, for example, a change in the name of a table or column, a change in a referential integrity (RI) relationship, or a change in data deletion rules (e.g., delete rules) when an RI constraint is changed, the source code for a maintenance tool affected by the change will also need to be modified and re¬compiled. Additionally, as the number of tables in a database increases, the complexity and maintainability of database maintenance tools also increases. Thus, the task of developing a custom data maintenance tool for frequently changing database tables can be overwhelming, time consuming and costly. The maintenance tool is configurable in the way data is deleted, extensible to new tables and adaptable to changes in the database as the database develops.
Accordingly, it would be desirable to provide database maintenance tool which is easily customized and which can adapt to constantly changing database tables.
Deleting large numbers of records could be handled by making a large request to delete the large number of records all from one request. However, performing a large delete would require a significant number of resources to implement the delete operation. For example, there may be a significant burden on the database system to make available the network bandwidth, processing resources, process threads, database connections, or other resources necessary to implement the delete request.
Another approach to deleting a large number of records would be by generating many requests. However, dealing with generating numerous requests is time consuming both to generate, as well as to perform. There is also not generally a good way of knowing when would be a good time to issue requests or not, and thus the issues of resource consumption made above would still be a problem with generating multiple requests instead of a single large request
Keeping the above in mind, it is thus an object of the present invention to provide an approach for efficiently and reliably erasing the content stored in a data storage

III. SUMMARY OF INVENTION
A scheme and system for deleting data in a database is disclosed. The scheme and system is configurable, extensible and adaptable to the changing structure of a database to provide a desired deletion. The scheme and system includes identifying data associated with a criterion and identifying tables in a family of tables having said data associated with said criteria. The scheme and system further includes performing a delete function on said data associated with the criteria, in said tables in said family of tables, according to delete rules of said table with which said data is associated.
Advantageously, embodiments of the present invention provide a database maintenance tool that is configurable, extensible and adaptable to the (sometimes) rapidly changing structure of a database, because it has the ability to identify tables affected and apply delete rules specific to certain data. The maintenance tool is configurable in the way data is deleted, extensible to new tables and adaptable to changes in the database as the database develops, and is adaptable to changes to the database structure without any need for custom programming.
Thus, the present invention relates to the maintenance of databases and, more particularly, to schemes and techniques for deleting data in a given database
In one embodiment, the present invention encapsulates a the data deletion scheme includes initiating a command to delete a file, finding storage resources associated with the file, overwriting the storage resources associated with the file with a first data value, returning a first completion indication to an application, overwriting the storage resources associated with the file with a second data value, overwriting the storage resources associated with the file with a third data value, returning the storage resources associated with the file to a free pool of storage resources, removing a file entry associated with the file from a file directory, and returning a second completion indication to the application.
In yet another embodiment, the first completion indication can include reporting to the application that the file is deleted, but that the data in the file is unrecoverable using conventional commands or operations. The data deletion method of the present invention can include initiating an action in conjunction with the first completion indication. The second completion indication can include reporting to the application that the file is deleted, but that the data in the file is not recoverable. The data deletion method of the

present invention can also include initiating an action in conjunction with the second completion indication
In a further embodiment, the invention highlights that Deleting the data in the file can be accomplished by overwriting the storage resources with a fixed data pattern, a random data pattern, or a pattern that is dependent upon the physical characteristics of the storage resource, or a combination of some or all of the three patterns. If desired, the data deletion method of the present invention can include returning an indication from the storage resource that multiple overwriting of the file has been physically completed, and/or instructing the storage resource to perform a physical data destruction operation
In a further embodiment, the present invention highlights the schemes for deleting data in a database comprising a plurality of families of tables, the schemes comprising of the following the steps which may not necessarily be in the following order.
The steps are highlighted as under: -
a) identifying data associated with a criteria;
b) identifying tables in a family of tables having the data associated with the criteria;
c) performing a delete function on the data associated with the criteria in the tables in the family of tables, according to delete rules of the tables with which data is associated.
Importantly keeping aside the details mentioned herein above, the schemes shall also involve the steps of identifying a hierarchical referential relationship amongst the tables under consideration from the tables under examination. In yet a further embodiment as the invention holds, the schemes as depicted in the invention under concern, also include a step wherein, the delete function involves performing steps that include deleting data from a table lower in position as per hierarchy before deleting data from a table in a higher hierarchical referential relation.
One embodiment of the present invention involves, having a computer readable medium containing program instructions for deleting data in a database, the program instructions for the following purposes such as, identifying data associated with a criteria; identifying tables in a family of tables having the data associated with the criteria; and performing a delete

function on the data associated with the criteria, in the tables in the family of tables, according to delete rules of the tables with which the data is associated
Yet another embodiment of the invention involves having a computer data signal, the computer data signal comprising a first code segment for deleting data in a database, the first code segment for: identifying data associated with a condition; identifying tables in a family of tables having the data associated with the condition; and performing a delete function on the data associated with the condition in the tables in the family of tables, according to delete rules of the tables with which the data is association
In a further embodiment, the invention is an apparatus for removing unwanted data from a database comprising: means for identifying data associated with a criteria; and means for performing a delete function on data associated with the criteria in tables in a family of tables, according to delete rules of the tables with which the data is associated.
Thus in yet another embodiment, the invention is a computer system comprising: a processor circuit operable to access a database for storing a plurality of families of tables of data and operable to access delete rules associated with respective tables in the family of tables; and a database maintenance tool which causes the processor circuit to identify data associated with a criteria; identify tables in a family of tables having the data associated with the criteria, and perform a delete function on the data associated with the criteria in the tables in the family of tables, according to delete rules of the tables with which the data is associated
In a further embodiment the user defines the business transaction definition. The definition will consist of tables involved, fields involved, relationship between different tables, key fields, non-key fields and exact sequence for deletion instructions. This will allow deletion routine to update non-key fields with "repeat pattern" to be overwritten followed by record deletes "from leaf to root" style. Ensure entire business transaction gets deleted properly.
In another embodiment, the User specifies the key-value for the business transaction that needs to be eliminated. Following this command, the program loads the database navigation map for the business transaction. This is followed by the program trying to pull all the records from the database for the provided key-value. Thus for each of the pulled records, program loads the key values of all other related tables at subsequent levels, tracing all the defined sequences for the business transaction data pull. Starting from the leaf to the root, program starts deleting records in tables. Finally the program reports statistics of deletion activity for the provided business transaction key.

In yet another embodiment, The invention summarizes a scheme for deleting data in a database, the database comprising tables, the apparatus comprising: means for identifying data associated with a condition; means for identifying a sub-set of tables having the data associated with the condition; means for identifying delete rules associated with corresponding sub-sets of tables; and means for performing a delete function on the data associated with the condition from the sub-set of tables according to delete rules of the table with which the data is associated.
Thus, the invention is a data deletion method comprising of providing a first monitoring/reporting threshold associated with a file to be deleted for reporting that the information in the file is deleted, but is unrecoverable using conventional commands or operations; and providing a second monitoring/reporting threshold associated with the file to be deleted for reporting that the information in the file is deleted, and is not recoverable
Description of drawings
The following description includes discussion of figures having illustrations given by way of example of implementations of embodiments described. The drawings should be understood by way of example, and not by way of limitation. As used herein, references to one or more "embodiments" are to be understood as describing a particular feature, structure, or characteristic included in at least one implementation. Thus, phrases such as "in one embodiment" or "in an alternate embodiment" appearing herein describe various embodiments and implementations, and do not necessarily all refer to the same embodiment. However, they are also not necessarily mutually exclusive.
a. Figure 1, is a diagram depicting the wipe out process. This is
depicted as per an exemplary embodiment of the present disclosure
b. Figure 2 is a database relationship diagram
Summary of description
With reference to Figure 1, is a computer system according to a first embodiment of the invention which is configured as a database server . The computer system comprises a processor circuit which is operable to access a database for storing data in a family of tables. The processor circuit is also operable to perform a delete function on data associated with criteria in tables in the family of tables, according to delete rules of a table with which the data is associated. The processor circuit may include, for example, a central processing unit (CPU) of the computer system, which interacts and interfaces with memory , input/output (I/O) peripheral support card and a network

interface card of the computer system. The peripheral support provision interfaces with conventional devices such as a keyboard, mouse and/or display which act as user interface devices. Other devices which are not shown may also be supported as is known by those of ordinary skill in the art.
The DB server may also receive or load instructions from processor readable media such as portable storage media. Storage media may be, for example, a CD-ROM, magnetic or optical carrier, a remote device (such as a networked data storage device) or the like.
DB server may be a standalone device interacting with only one user or, alternatively, may be network enabled. A network enabled DB server may be accessed by many users and be used to support many applications such as E-commerce applications, web sites, corporate data, etc. The DB server may include several network enabled computing devices interacting to support one or more databases
A User defines the business transaction definition. The definition will consist of tables involved, fields involved, relationship between different tables, key fields, non-key fields and exact sequence for deletion instructions. This will allow WipeOut routine to update non-key fields with "repeat pattern" to be overwritten followed by record deletes "from leaf to root" style. Ensure entire business transaction gets deleted properly.
Stages involved include
1. User specifies the key-value for the business transaction that needs to be wiped out
2. Program loads the database navigation map for the business transaction
3. Program tries to pull all the records from the database for the provided key-value
4. For each of the pulled records, program loads the key values of all other related tables at subsequent levels, tracing all the defined sequences for the business transaction data pull
5. Starting from the leaf to the root, program starts wiping out records in tables (WipeOut involves updating current value with a set of predefined permissible values according to data types for each data field)
6. Program reports statistics of WipeOut activity for the provided business transaction key.

Example #1: "Patient visit to Doctor" in Healthcare Software as a business transaction.
Typically, a patient visit to doctor as a business transaction may have following information
associated with in the database:

Information Possible Tables Possible Key Fields Possible Non-key fields
Appointment Appointment-tbl Patient-id Date-of-appt
Appt-id Time-of-appt
Dr-id Reason-for-appt
User-id Appt-status
Date_Create_Stamp
Last_update_stamp
Vitals taken during visit Patient-vitals Patient-id Notes
Appt-id Blood-pressure

" Entry-id Temperature
User-id Physical-signs
■. Ac live:medication
Chief-complaint
Date-creale-stamp
Last-update-stamp
Lab Reports Lab-works Patient-id Sugar-level
Lab-id Other data information
Dr-id Date-create-stamp
User-id Last-update-stamp
Notes Visit-notes Patient-id Note-text
Note-id Supporting-doc
User-id Alert-flag
Date-create-stamp
Billing Billing-table Inv-id Bill-dt
Patient-id Service-cd
Appt-id Bill-amt
Insurer-id Group-cd
Acct-cd Notes
Status-flag
Date-create-stamp
Last-update-stamp
It is to be further understood that, because and method steps depicted in the accompanying figures may be implemented in software, the actual connections between the system components (or the process steps) may differ depending upon the manner in which the present invention is programmed. Given the teachings of the present invention provided herein, one of ordinary

skill in the related art will be able to contemplate these and similar implementations or configurations of the present invention.
Having described embodiments for a mechanism and method for creating a common framework, and a structured approach for GRC management, comprising technological and non-technological assets and contexts, it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. It is therefore to be understood that changes may be made in the particular embodiments of the invention disclosed which are within the scope and spirit of the disclosure
SEQ#;
Sequences are to help plan the database reading and writing operation in most optimal way. Configuration of these sequences is done at the first implementation and it is specific to the database and business transactions. It is important to have exact sequence from root table to leaves table covering all the branches in between.
Sequence #1: Name the root table for the business transaction. Once a record is deleted from this table, all the following tables will become inaccessible. Record in this table must be deleted as the last step of the deletion process. Sequence#l table must be at Level 0 (to indicate the root level). There must be only one Level 0 entry per Business Transaction.
Sequence #2: From this sequence onward, one will require key information from the level 0 (Seq #1) to pull the data from the child /dependable tables of root table records. If this is parent to another table then all the key values from this table must be used to WipeOut all the leaves/dependable records before WipeOut record in this table.
Sequence #N: All the "Scan" sequences must be defined first (as all scan sequences are pulling the key values from the records that are essential to the next level for WipeOut informational records). It is very much possible to have multiple sequences at the same level except Level 0. Different sequences at the same level indicate siblings of a parent at previous level.
SEQUENCE LEVEL:
Level 0 - indicates current table is the root table for the Business Transaction definition.
Level 1 - indicates all the children of table of Level 0
KEY FIELD TYPE: While pulling records using the key field, we will need
knowledge about the data type for the key field. This will enable to properly

format the dynamically pulled values to pass to the dynamically generated SQL statements.
KEY FIELD NAME:
This is the key field which holds the values that need to be populated in
dynamic array to pull the dependent records on this parent.
ACTION CODES:
Scan - indicates current table holds the key values of the child tables. Make
sure to scan all dependent child tables and WipeOut related records from
child tables before you WipeOut record from this table
WipeOut - indicates the selected records in the current table are ready to be
wiped out as soon as selected. There are no further dependent tables. These
are the end -leaves.
PARENT SEO ID:
Table in current row has a parent table that is inferred from this seq id. Parent table is referred using the parent-seq-id column - parent table name is referred to the table of row "seq-id" matching the parent-seq-id. Blank parent field indicate that there is no known parent for the current table. We will need this value to "go back" to the parent to ensure that all records from the parent sequence are processed. For example, if parents' records are greater than the maximum size of the dynamic key holder array then we will end up processing parent and all its dependent children as many time as needed until all records are WipeOut from parent and its dependent.
RETRIEVAL SOL:
This SQL statement specify exactly how to pull all the records from the current table related to the key value of record from the parent table. Program is expected to pass the key-value from parent record to pull all the associated children related to that parent key. Once pulled, these records will further proceed to scan their children or will activate their WipeOut routine.
WIPEOUT SOL:
This SQL statement specify exactly how to WipeOut data values from all the
non-key fields columns.
DELETE SOL:
This SQL statement specify exactly how to delete the records that just got
wiped out of information.
While there have been described above the principles of the present invention in conjunction with specific components, circuitry and bias techniques, it is

to be clearly understood that the foregoing description is made only by way of example and not as a limitation to the scope of the invention. Particularly, it is recognized that the teachings of the foregoing disclosure will suggest other modifications to those persons skilled in the relevant art. Such modifications may involve other features which are already known per se and which may be used instead of or in addition to features already described herein. Although claims have been formulated in this application to particular combinations of features, it should be understood that the scope of the disclosure herein also includes any novel feature or any novel combination of features disclosed either explicitly or implicitly or any generalization or modification thereof which would be apparent to persons skilled in the relevant art, whether or not such relates to the same invention as presently claimed in any claim and whether or not it mitigates any or all of the same technical problems as confronted by the present invention.
The applicants hereby reserve the right to formulate new claims to such features and/or combinations of such features during the prosecution of the present application or of any further application derived therefrom

IV CLAIMS
We Claim;
1. A method for deleting data in a database comprising a plurality of families of tables, the method comprising the steps of firstly identifying data associated with a criterion; secondly identifying tables in a family of tables having the data associated with the criteria; and thirdly performing a delete function on the data associated with the criteria in the tables in the family of tables, according to delete rules of the tables with which data is associated.
2. The method as in Claim 1, which involves the procedure of ascertaining any hierarchical relationships between any tables
3. The method as in Claim 1, which wherein the delete function involves the deletion of data from a table that stands lower in locus in a given hierarchical relationship before deleting the data from a table that stands higher in locus in the given hierarchical relationship.
4. The method as in Claim 2, wherein the step of ascertaining any
hierarchical relationships, involves firstly identifying data in table
from a family of tables, secondly identifying data in a table from
a family of tables keeping into account the prior mentioned
hierarchy
5. The Method as in Claim 2, that ascertains identifying records that contain data associated with criteria in the family of tables as mentioned
6. The method as in Claim 5, wherein the delete function performing step as in Claim 4 involves the deletion of records from the table family
7. The method as in Claim 1 that also involves the method of deleting any data when any pre-conditions associated with a delete command and an associated data system is satisfied.

8. The method as in Claim 1, which also makes the use of receiving of any data.
9. The method as in Claim 8 that makes the use of providing a user interface for receiving any criterion from any user
10. The method as in Claim 9 that involves making available to any user at least one condition that in some manner defines the criteria and responds to user input for use in synchrony with at least one condition that defines the criteria.