CA2400552C - Localization of generic electronic registration system - Google Patents
Localization of generic electronic registration system Download PDFInfo
- Publication number
- CA2400552C CA2400552C CA2400552A CA2400552A CA2400552C CA 2400552 C CA2400552 C CA 2400552C CA 2400552 A CA2400552 A CA 2400552A CA 2400552 A CA2400552 A CA 2400552A CA 2400552 C CA2400552 C CA 2400552C
- Authority
- CA
- Canada
- Prior art keywords
- defining
- register
- instrument
- geographic
- registration
- 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.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Operations Research (AREA)
- Economics (AREA)
- Marketing (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Document Processing Apparatus (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention provides a method of localizing an electronic registration system provided through a generic registration framework, the method includes using several interfaces (capturing interface, template interface, workflow interface, rules interface) to customize the registration requirements and processing for a particular registration application. The method generates a geographically-meaningful localization of a registration system. The invention protects and respects the history of the data.
Description
LOCALIZATION OF GENERIC ELECTRONIC
REGISTRATION SYSTEM
FIELD OF THE INVENTION
The invention relates to registration methods and systems, and more particularly, to electronic registration methods and systems.
BACKGROUND OF THE INVENTION
Registration systems have existed in some fashion since ancient times. In its most basic form, registration is a process by which individuals, items or transactions are recorded in a list (or register). Registration systems may be in electronic or paper form, or some combination thereof.
Two underlying actions can be said to distinguish a registration transaction from mere record-keeping. Registration includes:
1. Preparation, and lodgement I submission of a thing to be registered; and
REGISTRATION SYSTEM
FIELD OF THE INVENTION
The invention relates to registration methods and systems, and more particularly, to electronic registration methods and systems.
BACKGROUND OF THE INVENTION
Registration systems have existed in some fashion since ancient times. In its most basic form, registration is a process by which individuals, items or transactions are recorded in a list (or register). Registration systems may be in electronic or paper form, or some combination thereof.
Two underlying actions can be said to distinguish a registration transaction from mere record-keeping. Registration includes:
1. Preparation, and lodgement I submission of a thing to be registered; and
2. Committal / acceptance of the thing to be registered (usually, acceptance is done by some type of registration authority).
Some types of registration systems presume official validation or certification of contents (such as, land, passport, guns, automobile registration, patents), while others are mere depository systems, placing the onus for accuracy of contents on the individual user (such as, product registrations, email registration, subscriptions). While registration systems are most common in official or government settings (such as, health care, firearms registration, vehicle registration, real or personal properly), there are also many types of private registration systems (such as, product registrations, domain name registration, educational institution registrations). Perhaps the most common application for registration systems is for ownership tracking of real, personal or intellectual property.
However, there are countless other possible uses.
As registration systems exist in a temporal framework, they must permit not only insertion of new entries into the register, but also amendment or deletion of existing entries. Typically, registration systems also must be organized in some logical sense to permit searching of existing entries according to some criteria. Examples of such searchable criteria include:
a) item description/name, location, price, identifying number/name, time b) model, make, serial number Rules are inherent in the registration system to "process" a submission for registration.
Acceptance criteria may be formal and/or content based. For instance, to accept a passport application, the applicant's photograph must be a certain size and shape (formal criterion). On the other hand, there are acceptance criteria that involve judgement about the content, which processing would ordinarily be carried out by a human checker. For instance, to register as a university student, one needs to have graduated from high school.
Increasingly, registration systems are being provided in some degree in electronic form.
One or more aspects may be electronically provided. Typically, the register itself may be electronic (i.e. in database form). Searchable electronic databases are known in the art.
The submission (or lodgement) process may also be electronic (i.e, e-mail or fomrbased submission).
Some types of registration systems presume official validation or certification of contents (such as, land, passport, guns, automobile registration, patents), while others are mere depository systems, placing the onus for accuracy of contents on the individual user (such as, product registrations, email registration, subscriptions). While registration systems are most common in official or government settings (such as, health care, firearms registration, vehicle registration, real or personal properly), there are also many types of private registration systems (such as, product registrations, domain name registration, educational institution registrations). Perhaps the most common application for registration systems is for ownership tracking of real, personal or intellectual property.
However, there are countless other possible uses.
As registration systems exist in a temporal framework, they must permit not only insertion of new entries into the register, but also amendment or deletion of existing entries. Typically, registration systems also must be organized in some logical sense to permit searching of existing entries according to some criteria. Examples of such searchable criteria include:
a) item description/name, location, price, identifying number/name, time b) model, make, serial number Rules are inherent in the registration system to "process" a submission for registration.
Acceptance criteria may be formal and/or content based. For instance, to accept a passport application, the applicant's photograph must be a certain size and shape (formal criterion). On the other hand, there are acceptance criteria that involve judgement about the content, which processing would ordinarily be carried out by a human checker. For instance, to register as a university student, one needs to have graduated from high school.
Increasingly, registration systems are being provided in some degree in electronic form.
One or more aspects may be electronically provided. Typically, the register itself may be electronic (i.e. in database form). Searchable electronic databases are known in the art.
The submission (or lodgement) process may also be electronic (i.e, e-mail or fomrbased submission).
3 Lodgement processes (that is, the preparation and submission of an instrument for registration) are known in electronic registration systems. For instance, in Teranet's e-reg~ product, lodgement provides users with a virtual work area allowing parties to collaborate amongst themselves prior to submitting the instrument (in this case, a land registration document) for validation and registration.
Gontent-based processing is the most difficult aspect to represent in electronic form, as it requires programming of the checklist of criteria that would be manually completed by a human checker. As these rules and criteria will be particular to each application (and to each registration authority), a significant amount of custom programming is n3quired.
For registration systems where rules are changing on an evolutionary basis (e.g. where regulatory changes are frequent), the task of custom programming is an ongoing one.
It would be advantageous to provide an electronic registration system that allows a registration system provider to configure and reconfigure detailed rules and criteria as necessary for ongoing operation, without significant "hard coding" at the program level.
SUMMARY OF THE INVENTION
It is an object of the invention to provide a middleware framework for developing and providing electronic registration services. Through this framework, it is a further object of the invention to allow localization of generic registration utilizing tools within the framework to allow electronic registration to be customized for particular applications and revised as needed. Finally, it is an object of the invention to provide a geographically-meaningful localization of generic registration framework by the use of a geographic (location) entity in the configuration of the localized registration database.
Gontent-based processing is the most difficult aspect to represent in electronic form, as it requires programming of the checklist of criteria that would be manually completed by a human checker. As these rules and criteria will be particular to each application (and to each registration authority), a significant amount of custom programming is n3quired.
For registration systems where rules are changing on an evolutionary basis (e.g. where regulatory changes are frequent), the task of custom programming is an ongoing one.
It would be advantageous to provide an electronic registration system that allows a registration system provider to configure and reconfigure detailed rules and criteria as necessary for ongoing operation, without significant "hard coding" at the program level.
SUMMARY OF THE INVENTION
It is an object of the invention to provide a middleware framework for developing and providing electronic registration services. Through this framework, it is a further object of the invention to allow localization of generic registration utilizing tools within the framework to allow electronic registration to be customized for particular applications and revised as needed. Finally, it is an object of the invention to provide a geographically-meaningful localization of generic registration framework by the use of a geographic (location) entity in the configuration of the localized registration database.
4 According to a first aspect of the invention, a method is provided for localizing an electronic registration system provided through a generic registration framework. The registration system has register, instrument and geographic entities within a database in a computer memory. The method comprises at least four steps:
~ by means of a capturing intertace, defining register, instrument and geographic entities for defining register, instrument and geographic entities to be stored in the database;
~ by means of a template intertace, defining input parameters for defining input parameters to accept input information through forms;
~ by means of a workflow intertace, selecting an order of registration operations for selecting an order of registration operations to be pertormed on the input information; and by means of a rules intertace, defining rules for processing the input information to be applied against an attribute of any one of the register, instrument and geographic entities.
The step of defining register, instrument and geographic entities may further include defining data fields for the register, instrument and geographic entities. In addition, or in the alternative, data fields may be populated with existing data. The data fields are preferably defined or expressed in XML.
The geographic entity is preferably a hierarchically-expressed geographic indicator.
It may have a dynamically selected number of levels.
The step of defining register, instrument and geographic entities may further include linking existing systems to the register, instrument and geographic entities to provide an ongoing supply of fresh data.
~ by means of a capturing intertace, defining register, instrument and geographic entities for defining register, instrument and geographic entities to be stored in the database;
~ by means of a template intertace, defining input parameters for defining input parameters to accept input information through forms;
~ by means of a workflow intertace, selecting an order of registration operations for selecting an order of registration operations to be pertormed on the input information; and by means of a rules intertace, defining rules for processing the input information to be applied against an attribute of any one of the register, instrument and geographic entities.
The step of defining register, instrument and geographic entities may further include defining data fields for the register, instrument and geographic entities. In addition, or in the alternative, data fields may be populated with existing data. The data fields are preferably defined or expressed in XML.
The geographic entity is preferably a hierarchically-expressed geographic indicator.
It may have a dynamically selected number of levels.
The step of defining register, instrument and geographic entities may further include linking existing systems to the register, instrument and geographic entities to provide an ongoing supply of fresh data.
5 The capturing interface preferably includes a persistence layer for permitting changes to be made to the database dynamically.
The step of defrning input parameters preferably further includes defining the presentation and grouping of the forms.
The step of selecting an order of registration operations preferably further includes selecting from among predetermined business objects.
The step of defining rules preferably further includes defining business objects to serve as arguments for the rules. In addition, or in the alternative, predefined business domain objects may be selected for use in defining rules.
The step of defining rules preferably further includes defining rules with an English grammar. The rules may preferably be defined using an "If...Then..." syntax.
The method preferably further includes setting prices and collecting movies owed for a registration transaction by means of a pricing/billing module.
The method preferably further includes defining and delivering messaging events by means of a subscription module.
The step of defrning input parameters preferably further includes defining the presentation and grouping of the forms.
The step of selecting an order of registration operations preferably further includes selecting from among predetermined business objects.
The step of defining rules preferably further includes defining business objects to serve as arguments for the rules. In addition, or in the alternative, predefined business domain objects may be selected for use in defining rules.
The step of defining rules preferably further includes defining rules with an English grammar. The rules may preferably be defined using an "If...Then..." syntax.
The method preferably further includes setting prices and collecting movies owed for a registration transaction by means of a pricing/billing module.
The method preferably further includes defining and delivering messaging events by means of a subscription module.
6 The method preferably further includes defining security protocols to be applied to input information by means of a security module.
The method preferably further includes authorizing users or groups to input, edit, or delete information by means of a customer care module.
Preferably, each one of the register, instrument and geographic entities includes a component table and an attribute table to be stored in the computer memory.
According to a second aspect of the invention, a generic electronic registration system database is provided including register, instrument and geographic entities, each entity comprising:
~ a component table; and ~ an attribute table.
The database preferably includes XML data.
BRIEF DESCRIPTION OF THE DRAWINGS
In order that the invention may be more clearly understood, the preferred embodiment thereof will now be described by way of example with reference to the accompanying drawings, in which:
FIG. 1 is a diagram of a preferred hardware arrangement used to carry out the invention;
FIG. 2 is a schematic diagram of the middleware architecture of a preferred embodiment of the software used to carry out the invention;
FIG. 3 is a schematic diagram of the modular framework thereof;
The method preferably further includes authorizing users or groups to input, edit, or delete information by means of a customer care module.
Preferably, each one of the register, instrument and geographic entities includes a component table and an attribute table to be stored in the computer memory.
According to a second aspect of the invention, a generic electronic registration system database is provided including register, instrument and geographic entities, each entity comprising:
~ a component table; and ~ an attribute table.
The database preferably includes XML data.
BRIEF DESCRIPTION OF THE DRAWINGS
In order that the invention may be more clearly understood, the preferred embodiment thereof will now be described by way of example with reference to the accompanying drawings, in which:
FIG. 1 is a diagram of a preferred hardware arrangement used to carry out the invention;
FIG. 2 is a schematic diagram of the middleware architecture of a preferred embodiment of the software used to carry out the invention;
FIG. 3 is a schematic diagram of the modular framework thereof;
7 FIG. 4 is a flow diagram of a preferred embodiment of the method;
FIG. 5 is a flow diagram of process A according to the method;
FIG. 6 is a table diagram of a sample Instrument entity modelled within the database;
FIG. 7 is a table diagram of a sample Register entity modelled within the database;
FIG. 8 is a table diagram of a sample Geographic entity modelled within the database;
FIG. 9 is a diagram of a sample hierarchical model of the Geographic entity;
FIG. 10 is an excerpt of a sample form generated from an XML Schema template according to the method;
FIG. 11 is a sample workflow selected according to the method; and FIG. 12 is a sample rule defined according to the method.
DETAILED DESCRIPTION
According to the preferred embodiment, the invention provides a method of providing a localized electronic n~istration system within a generic registration framework that protects and respects the history of the data.
Several key entities form the backbone of the present generic electronic registration framework. Three entities are modelled in the database architecture of the present invention: Register, Instrument and Geographic. These entities are represented in tables in the databases.
Traditionally, a Register is a book where entries for a person, place or thing are listed (usually one abstract per page - each abstract containing multiple entries that represent alterations to the register, such as an addition, deletion, modification, change of state, etc.). In the present sense, a Register is not a physical book, but a virtual book, representing a type of object that is the subject of registration. The system supports a single Register setup, multiple Registers or multiple types of Registers.
The Instrument entity, in the present sense, is not a physical document, but represents an action taken with respect to the object and its corresponding data.
The "register" and "instrument' entities are chosen from the vocabulary of land registration. Likewise, many of the examples used within this description apply to a land registration application of the framework, however, they are meant simply to illustrate one particular complex application of the system. The present framework is generic and is applicable for any type of nrgistration application. Through the localization process described herein, a registration provider specifies the inputs and processing requirements applicable for the particular registration application.
The third entity, a Geographic, does not have an analogous entity in traditional registration systems. A Geographic is a hierarchical description of a location (such as, address or lot, concession, Property Id Number) where any point/level in the hierarchy may be an attribute of a Register or Instrument or may have a Register or attribute as an attribute of itself. (As used herein, an "attribute" can be understood as a conceptual "child" class in relation to a "parent" entity. In the database tables, attribute tables have rows for each child instance of the parent entity. Sub-attributes of attributes may also be provided.) Each level of the hierarchy can be treated as a discrete component representing one or more geographic locations.
A simple Geographic entity 901 is illustrated in Figure 9. At the top of the hierarchy is the "Province" 902, which has "City" attributes 903, which in tum has "Street"
attributes 804. The invention is not limited to the present Geographic illustration however. The framework has no bias as to the components of the Geographic hierarchy. The components are adaptable to the provider's requirements and will represent whatever hierarchy and degree of granularity is meaningful to the subject-matter of the registration system.
Registers, Instruments and Geographics may stand in entity-entity or entity-attribute relation to each other. The relationships between the entities are all potentially n-to-n.
To illustrate how these abstract entities might be represented in real situations, consider the following examples:
a) Gun control:
Register = gun serial number and type;
Instrument = registered owner;
Geographic = residence of owner.
b) Vehicle control:
Register = vehicle VIN, make, model;
Instrument = registered owner;
Geographic = residence of owner OR real time location of vehicle.
The method relates to a method of providing a localized electronic registration system within a generic registration framework. With reference to Figure 2, the generic registration framework is a middleware software framework 203. By implication, there is no programmed front-end application for end-users of the registration system.
Rather, the framework provides generic access for any type of client application to utilize the framework. A provider of electronic registration services will use the present method to create a front-end application (referred to as a "localization" 202) which is then capable of processing registration transactions through the middleware 203.
5 The framework 203 is preferably developed using an object-oriented program architecture. The currently preferred architecture is Sun Corporation's Java 2 Enterprise Edition (J2EET"'), however, it is not intended to limit the architecture to this language, and any modular development platform would be useful.
10 The framework may be run on various types of standard hardware. With reference to Figure 1, a sample topology of the preferred hardware configuration is provided. The registration system is preferably installed in a typical client-server nefinrork. A single server or server duster 104 will run the system components in communication with at least one database 105. Registration services provided through the localized application are preferably accessible to a thick or thin client system 101 over the Internet 102. In this embodiment, a web server 103 mediat~s client requests for registration services to be carried out on the application server 104.
Turning to Figure 3, the preferred framework 301 inGudes at least the following program modules, all of which are in communicative relationship to a core module 318 interfacing with at least one database 312:
~ Template & forms management 302 ~ Flow of execution (workflow) 305 ~ Rules engine 306 The Core module 316, in addition to its root functions 315, contains the components of the persistence layer 308, input forms 308, workflow entities 310 and new listeners 311, all as more particularly described elsewhere in this document.
Further functions or modules may include:
~ Desktop & user presentation (Presentation 8~ grouping) 303 ~ Customer care 304 ~ Subscription 307 ~ Security 314 ~ Billing/pricing (not shown) ~ Data conversion (not shown) The functions or modules may be provided either in the form of a discrete program module, or as an API (application program interface) interfacing with a third party application performing the desired function. For instance, the security module 314 may be provided by means of an API interfacing with a conventionally known encryption and/or digital signature application. The API passes the appropriate information to the third party application and returns appropriate information to the framework core 318 and its database 312.
The modules 301 enable the configuration of the localized registration application according to the custom requirements of the registration service provider.
Once the registration system is localized for the provider's particular application, it may also be amended as necessary to meet changing requin:ments (e.g. regulatory or form changes) or to create new applications.
The method is set out generally in flow charts provided in Figures 4 and 5. To localize a registration system through the generic framework, the provider must first install and configure the framework 402. The registration "system" is the localized application which runs through the "framework." In the installation, the persistence layer 205 within the framework 203 will create the database Instrument, Register and Geographic schema required. The persistence layer 205 will then use the schema for storage and retrieval. These database tables do not change in structure after the installation, however attributes may be added.
The database 312 once configured can be populated with legacy data 313 through a conversion utility (not shown) or left blank until the system is ready to be populated by new entries through the localized front-end system.
Once the framework is installed, templates are used to carry out the process of creating the forms required for registration 403. The templates are preferably defined or developed using XML Schema as prescribed by the W3C. Templates are used to define the forms required to input data into the Instrument, Register and Geographic data entities. Form field validation is defined as part of the template development phase. In the preferred embodiment, XML Schema allows field validation to be written into the form code.
Once a template is submitted, the framework automatically generates a resultant input form 403. Optionally, the form can be visually customized by associating a Presentation & Grouping file with the template 404, which allows the provider to select the precise layout of the form fields and to inGude any creative touches desired (such as custom background appearance, provider logo, etc.). This ~P & G" file is preferably in XSLT.
A sample form is shown at Figures 10A and 10B. According to fields defined in the template 403, the form will allow entry of various descriptive information 1003 in relation to the Instrument (in this case, a property transfer) for the particular Register (in this case, the property) and in relation to the Geographic. In this case, there are Geographic attributes of the property itself, the transferor 1005 and the transfen~e 1006. In this case, the form also permits an attachment file to be added (such as a survey of the property).
Note that the sample screen shot of the form also shows form-related options defined to be available to the user (for saving an unfinished work to come back to, validating the contents, committing the input information for registration, or cancelling the transaction). The localized application also includes user-related options 1001 to engage other processes available to the user (such as, checking the status of other registration transactions, setting subscription preferences, and searching the database).
At the same time 404, the provider can include its own static pages to be called by the application when it is presented to the user. Static pages are not generated by the framework via a template. However, these pages may access and present data stored within the database or from another data source. Static pages may be used to govern any process or information that is domain specific. For instance, logging-in, displaying data, reports, organization of submissions, folders, instruments, or user navigation functions may be provided by static pages.
Once the databases and forms are configured, the provider then configures the workflow module (Flow of Execution module 305) to establish the high-level order of operations for the registration process to be carried out 405. Certain standard registration operations can preferably be selected from among a pre-programmed set (such as, saving data, retrieving data, validating, searching, checking permissions), or the provider can define and include custom operations.
An example flow of execution 1101 is shown in Figure 11. In the example, the selected registration process begins by validating the Instrument fields 1102 (i.e. the fields entered by user through the defined form). Then the targets fields 1103 are validated.
The defined business rules will be executed 1104. Subscription options will be generated 1105. Finally, the information will be sent to be certified in queue order 1106.
At a detail level, each step in the workflow can be configured to apply rules defined by the provider using the Rules Engine 406. In order to set rules, the provider will preferably program Java objects that execute fine grained business logic which support the rules. These Java objects 310 vrrill preferably reside in the Core 316 when defined.
Some predefined objects 310 will preferably be available in the framework as installed.
The objects are included in rules of preferably "If...Then..." syntax.
Preferably, the syntax will be close to English syntax to permit ease of human comprehension.
An example of such a rule is provided in Figure 12. The sample rule 1201 checks for active mortgages on a property title before registering a discharge. If there is an Active Charge in the history (having a value greater than 0), the registration transaction will be refused and the user will be sent a message. A "Subscription Event" is also triggered to notify other °listeners" 311 subscribed to receive messages for this particular Register (as set in the subscription module 30T) that there was an attempted registration against this Register.
Code entities may also be developed to support specific complex operations (such as, pricing or fee calculation, data manipulation, business logic execution). The provider 5 can also specify whether submitted forms are to be processed immediately, or hatched for processing (such as, at the end of each business day).
These are the core requirements for localization of a registration system according to the preferred embodiment of the present method. However, there are several other possible 10 localization steps 407 to generate a more sophisticated application.
Referring now to Figure 5, optional steps 407 in the method are shown (these steps in any order). A subscription module 307 may preferably be employed 502 to define notice events for any person or process that may need to be aware of such events.
System 15 events (such as, start-up, shutdown, exception or any system logged events), or business events (such as, edit of instrument, change to register, payment on bill, execution of specific transaction or business process) may be selected as subscribable.
Various modes of electronic communication are supported for dissemination of such notices. Other modes can also be defined as framework plug-ins.
A customer care module 304 may preferably be employed 503 to define groups and users authorized to transact with given information in the databases.
Definition of groups or users involves setting a customer profile and customer permissions.
"Users"
in the present sense refers to users of the registration system, as opposed to the individuals who may be related to the entities within the databases (e.g.
owners). When configured to permit multi-user access to a lodgement, several users may collaborate on information to be submitted for registration (e.g. lawyers on opposite sides of a transaction). In the lodgement process, information is stored for use in the collaboration without affecting the state of the registration database. One or multiple users may be required to commit the information to be registered. An identifier is preferably associated with the lodgement to allow users to return to unfinished work.
A security module 314 may preferably be provided 504 to provide encryption technology and/or digital signature technology to secure and authenticate communications on the system. The rules engine 306 is preferably employed to define what specific communications are to be encrypted, digitally signed, etc. The workflow module 305 is preferably employed to define at what point in the operations encryption will occur.
Encryption can apply to all communications or specific parts of communications (i.e. one field or the entire document can be encrypted).
Optionally, a pricing/billing interface is provided for setting prices and ~Ilecting movies owed for a registration transaction.
The database of the preferred embodiment is preferably comprised of tables representing each of the Register, Instrument and Geographic entities. It has been found useful to represent each entity with a non-standard recursive table structure having preferably two tables: a component table and an attribute table. As each component is made up of a set of standard columns and rows, the database will contain a set of tables to represent each type of component and a table to represent the attributes. The number of attributes is therefore potentially unlimited, and the level of granularity can be modified to suit the application.
For searchability, there is preferably a join between component table and attribute table, and a recursive join on the attribute table.
Sample tables are shown in Figures 6 through 8 to illustrate a possible schema for a land registration application. With reference to the sample Instrument tables in Figure 6, two tables are provided - a component table 801 and an attribute table 620.
There are multiple entries in each table 602-619, 821-845. The component entries represent actions taken against an object in the Register. As a sample Instrument entry in the component table 601, 802 is identified as a "ChargeorMortgage" type having name "123". This entry relates to a number of entries in the corresponding attribute table 820 identified at entries 621-625. That is, the "ChargeorMortgage" component has five attributes. Among these, for instance, the change has an attribute "principal Amount' 625 which has a value of "645" in this case. The attribute types correspond to standard variable types (e.g. "string" type or "double" numeric type).
Similarly, Fig. 7 shows component 701 and attribute T10 tables for a sample Register.
The Register in this case lists properties 702, 703. "Property B" (ID "102") in the component table 701 has a number of attributes 711-718, including owner's name and spouse's name 712, as well as, address attributes 714-718.
Fig. 8 shows component 801 and attribute 820 tables for a sample Geographic.
The Geographic in this case contains a number of descriptors 802-811. Each descriptor type is defined with a Geotype which represents its level in the hierarchy.
Although five levels are provided in the example, any number of levels may be defined to suit the particular application. Component "street" 805 has four attributes 821-824 relating in this case to the number and location of wells on that street.
Preferably, the database 312 is configured to automatically log and effective date all entries (even where the attributes have changed). This helps to preserve the record-keeping integrity of the system and allows historical querying and reporting.
The foregoing is considered as illustrative only of the principles of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact steps and systems shown and described, and accordingly, all suitable modifications and equivalents may be resorted to, falling within the scope of the invention and the appended claims and their equivalents.
FIG. 5 is a flow diagram of process A according to the method;
FIG. 6 is a table diagram of a sample Instrument entity modelled within the database;
FIG. 7 is a table diagram of a sample Register entity modelled within the database;
FIG. 8 is a table diagram of a sample Geographic entity modelled within the database;
FIG. 9 is a diagram of a sample hierarchical model of the Geographic entity;
FIG. 10 is an excerpt of a sample form generated from an XML Schema template according to the method;
FIG. 11 is a sample workflow selected according to the method; and FIG. 12 is a sample rule defined according to the method.
DETAILED DESCRIPTION
According to the preferred embodiment, the invention provides a method of providing a localized electronic n~istration system within a generic registration framework that protects and respects the history of the data.
Several key entities form the backbone of the present generic electronic registration framework. Three entities are modelled in the database architecture of the present invention: Register, Instrument and Geographic. These entities are represented in tables in the databases.
Traditionally, a Register is a book where entries for a person, place or thing are listed (usually one abstract per page - each abstract containing multiple entries that represent alterations to the register, such as an addition, deletion, modification, change of state, etc.). In the present sense, a Register is not a physical book, but a virtual book, representing a type of object that is the subject of registration. The system supports a single Register setup, multiple Registers or multiple types of Registers.
The Instrument entity, in the present sense, is not a physical document, but represents an action taken with respect to the object and its corresponding data.
The "register" and "instrument' entities are chosen from the vocabulary of land registration. Likewise, many of the examples used within this description apply to a land registration application of the framework, however, they are meant simply to illustrate one particular complex application of the system. The present framework is generic and is applicable for any type of nrgistration application. Through the localization process described herein, a registration provider specifies the inputs and processing requirements applicable for the particular registration application.
The third entity, a Geographic, does not have an analogous entity in traditional registration systems. A Geographic is a hierarchical description of a location (such as, address or lot, concession, Property Id Number) where any point/level in the hierarchy may be an attribute of a Register or Instrument or may have a Register or attribute as an attribute of itself. (As used herein, an "attribute" can be understood as a conceptual "child" class in relation to a "parent" entity. In the database tables, attribute tables have rows for each child instance of the parent entity. Sub-attributes of attributes may also be provided.) Each level of the hierarchy can be treated as a discrete component representing one or more geographic locations.
A simple Geographic entity 901 is illustrated in Figure 9. At the top of the hierarchy is the "Province" 902, which has "City" attributes 903, which in tum has "Street"
attributes 804. The invention is not limited to the present Geographic illustration however. The framework has no bias as to the components of the Geographic hierarchy. The components are adaptable to the provider's requirements and will represent whatever hierarchy and degree of granularity is meaningful to the subject-matter of the registration system.
Registers, Instruments and Geographics may stand in entity-entity or entity-attribute relation to each other. The relationships between the entities are all potentially n-to-n.
To illustrate how these abstract entities might be represented in real situations, consider the following examples:
a) Gun control:
Register = gun serial number and type;
Instrument = registered owner;
Geographic = residence of owner.
b) Vehicle control:
Register = vehicle VIN, make, model;
Instrument = registered owner;
Geographic = residence of owner OR real time location of vehicle.
The method relates to a method of providing a localized electronic registration system within a generic registration framework. With reference to Figure 2, the generic registration framework is a middleware software framework 203. By implication, there is no programmed front-end application for end-users of the registration system.
Rather, the framework provides generic access for any type of client application to utilize the framework. A provider of electronic registration services will use the present method to create a front-end application (referred to as a "localization" 202) which is then capable of processing registration transactions through the middleware 203.
5 The framework 203 is preferably developed using an object-oriented program architecture. The currently preferred architecture is Sun Corporation's Java 2 Enterprise Edition (J2EET"'), however, it is not intended to limit the architecture to this language, and any modular development platform would be useful.
10 The framework may be run on various types of standard hardware. With reference to Figure 1, a sample topology of the preferred hardware configuration is provided. The registration system is preferably installed in a typical client-server nefinrork. A single server or server duster 104 will run the system components in communication with at least one database 105. Registration services provided through the localized application are preferably accessible to a thick or thin client system 101 over the Internet 102. In this embodiment, a web server 103 mediat~s client requests for registration services to be carried out on the application server 104.
Turning to Figure 3, the preferred framework 301 inGudes at least the following program modules, all of which are in communicative relationship to a core module 318 interfacing with at least one database 312:
~ Template & forms management 302 ~ Flow of execution (workflow) 305 ~ Rules engine 306 The Core module 316, in addition to its root functions 315, contains the components of the persistence layer 308, input forms 308, workflow entities 310 and new listeners 311, all as more particularly described elsewhere in this document.
Further functions or modules may include:
~ Desktop & user presentation (Presentation 8~ grouping) 303 ~ Customer care 304 ~ Subscription 307 ~ Security 314 ~ Billing/pricing (not shown) ~ Data conversion (not shown) The functions or modules may be provided either in the form of a discrete program module, or as an API (application program interface) interfacing with a third party application performing the desired function. For instance, the security module 314 may be provided by means of an API interfacing with a conventionally known encryption and/or digital signature application. The API passes the appropriate information to the third party application and returns appropriate information to the framework core 318 and its database 312.
The modules 301 enable the configuration of the localized registration application according to the custom requirements of the registration service provider.
Once the registration system is localized for the provider's particular application, it may also be amended as necessary to meet changing requin:ments (e.g. regulatory or form changes) or to create new applications.
The method is set out generally in flow charts provided in Figures 4 and 5. To localize a registration system through the generic framework, the provider must first install and configure the framework 402. The registration "system" is the localized application which runs through the "framework." In the installation, the persistence layer 205 within the framework 203 will create the database Instrument, Register and Geographic schema required. The persistence layer 205 will then use the schema for storage and retrieval. These database tables do not change in structure after the installation, however attributes may be added.
The database 312 once configured can be populated with legacy data 313 through a conversion utility (not shown) or left blank until the system is ready to be populated by new entries through the localized front-end system.
Once the framework is installed, templates are used to carry out the process of creating the forms required for registration 403. The templates are preferably defined or developed using XML Schema as prescribed by the W3C. Templates are used to define the forms required to input data into the Instrument, Register and Geographic data entities. Form field validation is defined as part of the template development phase. In the preferred embodiment, XML Schema allows field validation to be written into the form code.
Once a template is submitted, the framework automatically generates a resultant input form 403. Optionally, the form can be visually customized by associating a Presentation & Grouping file with the template 404, which allows the provider to select the precise layout of the form fields and to inGude any creative touches desired (such as custom background appearance, provider logo, etc.). This ~P & G" file is preferably in XSLT.
A sample form is shown at Figures 10A and 10B. According to fields defined in the template 403, the form will allow entry of various descriptive information 1003 in relation to the Instrument (in this case, a property transfer) for the particular Register (in this case, the property) and in relation to the Geographic. In this case, there are Geographic attributes of the property itself, the transferor 1005 and the transfen~e 1006. In this case, the form also permits an attachment file to be added (such as a survey of the property).
Note that the sample screen shot of the form also shows form-related options defined to be available to the user (for saving an unfinished work to come back to, validating the contents, committing the input information for registration, or cancelling the transaction). The localized application also includes user-related options 1001 to engage other processes available to the user (such as, checking the status of other registration transactions, setting subscription preferences, and searching the database).
At the same time 404, the provider can include its own static pages to be called by the application when it is presented to the user. Static pages are not generated by the framework via a template. However, these pages may access and present data stored within the database or from another data source. Static pages may be used to govern any process or information that is domain specific. For instance, logging-in, displaying data, reports, organization of submissions, folders, instruments, or user navigation functions may be provided by static pages.
Once the databases and forms are configured, the provider then configures the workflow module (Flow of Execution module 305) to establish the high-level order of operations for the registration process to be carried out 405. Certain standard registration operations can preferably be selected from among a pre-programmed set (such as, saving data, retrieving data, validating, searching, checking permissions), or the provider can define and include custom operations.
An example flow of execution 1101 is shown in Figure 11. In the example, the selected registration process begins by validating the Instrument fields 1102 (i.e. the fields entered by user through the defined form). Then the targets fields 1103 are validated.
The defined business rules will be executed 1104. Subscription options will be generated 1105. Finally, the information will be sent to be certified in queue order 1106.
At a detail level, each step in the workflow can be configured to apply rules defined by the provider using the Rules Engine 406. In order to set rules, the provider will preferably program Java objects that execute fine grained business logic which support the rules. These Java objects 310 vrrill preferably reside in the Core 316 when defined.
Some predefined objects 310 will preferably be available in the framework as installed.
The objects are included in rules of preferably "If...Then..." syntax.
Preferably, the syntax will be close to English syntax to permit ease of human comprehension.
An example of such a rule is provided in Figure 12. The sample rule 1201 checks for active mortgages on a property title before registering a discharge. If there is an Active Charge in the history (having a value greater than 0), the registration transaction will be refused and the user will be sent a message. A "Subscription Event" is also triggered to notify other °listeners" 311 subscribed to receive messages for this particular Register (as set in the subscription module 30T) that there was an attempted registration against this Register.
Code entities may also be developed to support specific complex operations (such as, pricing or fee calculation, data manipulation, business logic execution). The provider 5 can also specify whether submitted forms are to be processed immediately, or hatched for processing (such as, at the end of each business day).
These are the core requirements for localization of a registration system according to the preferred embodiment of the present method. However, there are several other possible 10 localization steps 407 to generate a more sophisticated application.
Referring now to Figure 5, optional steps 407 in the method are shown (these steps in any order). A subscription module 307 may preferably be employed 502 to define notice events for any person or process that may need to be aware of such events.
System 15 events (such as, start-up, shutdown, exception or any system logged events), or business events (such as, edit of instrument, change to register, payment on bill, execution of specific transaction or business process) may be selected as subscribable.
Various modes of electronic communication are supported for dissemination of such notices. Other modes can also be defined as framework plug-ins.
A customer care module 304 may preferably be employed 503 to define groups and users authorized to transact with given information in the databases.
Definition of groups or users involves setting a customer profile and customer permissions.
"Users"
in the present sense refers to users of the registration system, as opposed to the individuals who may be related to the entities within the databases (e.g.
owners). When configured to permit multi-user access to a lodgement, several users may collaborate on information to be submitted for registration (e.g. lawyers on opposite sides of a transaction). In the lodgement process, information is stored for use in the collaboration without affecting the state of the registration database. One or multiple users may be required to commit the information to be registered. An identifier is preferably associated with the lodgement to allow users to return to unfinished work.
A security module 314 may preferably be provided 504 to provide encryption technology and/or digital signature technology to secure and authenticate communications on the system. The rules engine 306 is preferably employed to define what specific communications are to be encrypted, digitally signed, etc. The workflow module 305 is preferably employed to define at what point in the operations encryption will occur.
Encryption can apply to all communications or specific parts of communications (i.e. one field or the entire document can be encrypted).
Optionally, a pricing/billing interface is provided for setting prices and ~Ilecting movies owed for a registration transaction.
The database of the preferred embodiment is preferably comprised of tables representing each of the Register, Instrument and Geographic entities. It has been found useful to represent each entity with a non-standard recursive table structure having preferably two tables: a component table and an attribute table. As each component is made up of a set of standard columns and rows, the database will contain a set of tables to represent each type of component and a table to represent the attributes. The number of attributes is therefore potentially unlimited, and the level of granularity can be modified to suit the application.
For searchability, there is preferably a join between component table and attribute table, and a recursive join on the attribute table.
Sample tables are shown in Figures 6 through 8 to illustrate a possible schema for a land registration application. With reference to the sample Instrument tables in Figure 6, two tables are provided - a component table 801 and an attribute table 620.
There are multiple entries in each table 602-619, 821-845. The component entries represent actions taken against an object in the Register. As a sample Instrument entry in the component table 601, 802 is identified as a "ChargeorMortgage" type having name "123". This entry relates to a number of entries in the corresponding attribute table 820 identified at entries 621-625. That is, the "ChargeorMortgage" component has five attributes. Among these, for instance, the change has an attribute "principal Amount' 625 which has a value of "645" in this case. The attribute types correspond to standard variable types (e.g. "string" type or "double" numeric type).
Similarly, Fig. 7 shows component 701 and attribute T10 tables for a sample Register.
The Register in this case lists properties 702, 703. "Property B" (ID "102") in the component table 701 has a number of attributes 711-718, including owner's name and spouse's name 712, as well as, address attributes 714-718.
Fig. 8 shows component 801 and attribute 820 tables for a sample Geographic.
The Geographic in this case contains a number of descriptors 802-811. Each descriptor type is defined with a Geotype which represents its level in the hierarchy.
Although five levels are provided in the example, any number of levels may be defined to suit the particular application. Component "street" 805 has four attributes 821-824 relating in this case to the number and location of wells on that street.
Preferably, the database 312 is configured to automatically log and effective date all entries (even where the attributes have changed). This helps to preserve the record-keeping integrity of the system and allows historical querying and reporting.
The foregoing is considered as illustrative only of the principles of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact steps and systems shown and described, and accordingly, all suitable modifications and equivalents may be resorted to, falling within the scope of the invention and the appended claims and their equivalents.
Claims (40)
1. A method of localizing an electronic registration system provided through a generic registration framework, the registration system having register, instrument and geographic entities within a database in a computer memory, the method comprising:
.cndot. by means of a capturing interface, defining register, instrument and geographic entities to be stored in the database;
.cndot. by means of a template interface, defining input parameters to accept input information through forms;
.cndot. by means of a workflow interface, selecting an order of registration operations to be performed on the input information; and .cndot. by means of a rules interface, defining rules for processing the input information to be applied against an attribute of any one of the register, instrument and geographic entities.
.cndot. by means of a capturing interface, defining register, instrument and geographic entities to be stored in the database;
.cndot. by means of a template interface, defining input parameters to accept input information through forms;
.cndot. by means of a workflow interface, selecting an order of registration operations to be performed on the input information; and .cndot. by means of a rules interface, defining rules for processing the input information to be applied against an attribute of any one of the register, instrument and geographic entities.
2. The method of claim 1, wherein the step of defining register, instrument and geographic entities further includes defining data fields for the register, instrument and geographic entities.
3. The method of claim 1, wherein the step of defining register, instrument and geographic entities further includes populating data fields for the register, instrument and geographic entities with existing data.
4. The method of claim 2 or claim 3, wherein the data fields are defined or expressed in XML.
5. The method of claim 1, wherein the geographic entity includes a hierarchically-expressed geographic indicator.
6. The method of claim 5, wherein the geographic indicator has a dynamically selected number of levels.
7. The method of claim 1, wherein the step of defining register, instrument and geographic entities further includes linking existing systems to the register, instrument and geographic entities.
8. The method of claim 1, wherein the capturing interface includes a persistence layer for permitting changes to be made to the database dynamically.
9. The method of claim 1, wherein the step of defining input parameters further includes defining the presentation and grouping of the forms.
10. The method of claim 1, wherein the step of selecting an order of registration operations further includes selecting from among predetermined business objects.
11. The method of claim 1, wherein the step of defining rules further includes defining business objects to serve as arguments for the rules.
12. The method of claim 1, wherein the step of defining rules further includes selecting predefined business domain objects for use in defining rules.
13. The method of claim 1, wherein the step of defining rules further includes defining rules with an English grammar.
14. The method of claim 13, wherein the rules are defined using an "If...Then..." syntax.
15. The method of claim 1, wherein the method further includes setting prices and collecting movies owed for a registration transaction by means of a subscription module.
16. The method of claim 1, wherein the method further includes defining and delivering messaging events by means of a subscription module.
17. The method of claim 1, wherein the method further includes defining security protocols to be applied to input information by means of a security module.
18. The method of claim 1, wherein the method further includes authorizing users or groups to input, edit, or delete information by means of a customer care module.
19. The method of claim 1, wherein each one of the register, instrument and geographic entities includes a component table and an attribute table to be stored in the computer memory.
20. A method of localizing an electronic registration system provided through a generic registration framework, the registration system having register, instrument and geographic entities within a database in a computer memory, the method comprising:
.cndot. by means of a capturing interface, defining register, instrument and geographic entities for defining data entities to be stored in the database, the entities including:
~ a register entity for storing registration data relating to an object;
~ an instrument entity for storing registration data relating to an action done with respect to the object; and ~ a geographic entity for storing registration data relating to a geographic attribute of an entity, or a geographic attribute of an attribute of an entity;
.cndot. by means of a template interface, defining input parameters for defining input parameters to accept input information through forms;
.cndot. by means of a workflow interface, selecting an order of registration operations for selecting an order of registration operations to be performed on either the input information or on existing information; and .cndot. by means of a rules interface, defining rules for defining rules for processing the input information to be applied against an attribute of any one of the register, instrument and geographic entities.
.cndot. by means of a capturing interface, defining register, instrument and geographic entities for defining data entities to be stored in the database, the entities including:
~ a register entity for storing registration data relating to an object;
~ an instrument entity for storing registration data relating to an action done with respect to the object; and ~ a geographic entity for storing registration data relating to a geographic attribute of an entity, or a geographic attribute of an attribute of an entity;
.cndot. by means of a template interface, defining input parameters for defining input parameters to accept input information through forms;
.cndot. by means of a workflow interface, selecting an order of registration operations for selecting an order of registration operations to be performed on either the input information or on existing information; and .cndot. by means of a rules interface, defining rules for defining rules for processing the input information to be applied against an attribute of any one of the register, instrument and geographic entities.
21. The method of claim 20, wherein the step of defining register, instrument and geographic entities further includes defining data fields for the register, instrument and geographic entities.
22. The method of claim 20, wherein the step of defining register, instrument and geographic entities further includes populating data fields for the register, instrument and geographic entities with existing data.
23. The method of claim 21 or claim 22, wherein the data fields are defined or expressed in XML.
24. The method of claim 20, wherein the geographic entity includes a hierarchically-expressed geographic indicator.
25. The method of claim 24, wherein the geographic indicator has a dynamically selected number of levels.
26. The method of claim 20, wherein the step of defining register, instrument and geographic entities further includes linking existing systems to the register, instrument and geographic entities.
27. The method of claim 20, wherein the capturing interface includes a persistence layer for permitting changes to be made to the database dynamically.
28. The method of claim 21, wherein the step of defining input parameters further includes defining the presentation and grouping of the forms.
29. The method of claim 20, wherein the step of selecting an order of registration operations further includes selecting from among predetermined business objects.
30. The method of claim 20, wherein the step of defining rules further includes defining business objects to serve as arguments for the rules.
31. The method of claim 20, wherein the step of defining rules further includes selecting predefined business domain objects for use in defining rules.
32. The method of claim 20, wherein the step of defining rules further includes defining rules with an English grammar.
33. The method of claim 32, wherein the means for defining rules allows rules to be defined using an "If...Then..." syntax.
34. The method of claim 20, wherein the method further includes setting prices and collecting monies owed for a registration transaction by means of a pricing/billing module.
35. The method of claim 20, wherein the method further includes defining and delivering messaging events by means of a subscription module.
36. The method of claim 20, wherein the method further includes defining security protocols to be applied to input information by means of a security module.
37. The method of claim 20, wherein the method further includes authorizing users or groups to input, edit, or delete information by means of a customer care module.
38. The method of claim 20, wherein each one of the register, instrument and geographic entities includes a component table and an attribute table to be stored in the computer memory.
39. A generic electronic registration system database including register, instrument and geographic entities, each entity comprising:
.cndot. a component table; and .cndot. an attribute table.
.cndot. a component table; and .cndot. an attribute table.
40. The database of claim 39, wherein the database includes XML data.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2400552A CA2400552C (en) | 2002-08-30 | 2002-08-30 | Localization of generic electronic registration system |
| GB0306960A GB2392519A (en) | 2002-08-30 | 2003-03-26 | Register database system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2400552A CA2400552C (en) | 2002-08-30 | 2002-08-30 | Localization of generic electronic registration system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2400552A1 CA2400552A1 (en) | 2004-02-29 |
| CA2400552C true CA2400552C (en) | 2011-01-25 |
Family
ID=32046505
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2400552A Expired - Lifetime CA2400552C (en) | 2002-08-30 | 2002-08-30 | Localization of generic electronic registration system |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2400552C (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20240070380A1 (en) * | 2022-08-31 | 2024-02-29 | Docusign, Inc. | Dynamic implementation of document management system capabilities in third party integrations |
-
2002
- 2002-08-30 CA CA2400552A patent/CA2400552C/en not_active Expired - Lifetime
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20240070380A1 (en) * | 2022-08-31 | 2024-02-29 | Docusign, Inc. | Dynamic implementation of document management system capabilities in third party integrations |
Also Published As
| Publication number | Publication date |
|---|---|
| CA2400552A1 (en) | 2004-02-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2421798C2 (en) | Data model for object-relation data | |
| US7065515B2 (en) | System and method for electronically managing composite documents | |
| US7873631B2 (en) | Abstractly mapped physical data fields | |
| US8438141B2 (en) | System and method for providing secure access to data with user defined table functions | |
| US20060149739A1 (en) | Data security in a semantic data model | |
| WO2001046825A1 (en) | Information exchange engine providing a critical infrastructure layer and methods of use thereof | |
| WO2004114096A2 (en) | Improved philanthropy management system and method of doing business | |
| JP5873078B2 (en) | System and method for providing multilingual support for data used with a business intelligence server | |
| US7519570B2 (en) | Localization of generic electronic registration system | |
| US20040024763A1 (en) | Method and apparatus for providing selective access to information | |
| US20070192278A1 (en) | Method and apparatus for providing selective access to information | |
| WO2009046389A1 (en) | Composing and enforcing context-aware disclosure rules for preserving privacy and security of information | |
| CA2400552C (en) | Localization of generic electronic registration system | |
| Gladney | A storage subsystem for image and records management | |
| GB2392519A (en) | Register database system | |
| Belic et al. | User‐friendly web application for bibliographic material processing | |
| US10180975B2 (en) | Methods and a computing device for carrying out data collection | |
| US20230281326A1 (en) | Database Integrated Secure View | |
| Schlatter et al. | The business object management system | |
| Belokosztolszki et al. | Policy storage for role-based access control systems | |
| Ray et al. | Verification of data pattern for interactive privacy preservation model | |
| US9639707B1 (en) | Secure data storage and communication for network computing | |
| Perry | An integrated intranet and dynamic database application for the Security Manager at Naval Postgraduate School | |
| Raut | A LITERATURE SURVE ON DATA WAREHOUSE SECURITY ASPECTS | |
| Arige | Databases on the web: Online directory services |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20220830 |