Source: http://www.google.com/patents/US20080021916?dq=oakley+D523,461&ei=qiI4T-CjGqXf0QHz_PSUCA
Timestamp: 2013-12-05 02:02:59
Document Index: 490989045

Matched Legal Cases: ['arts 1001', 'arts 1001', 'art 1001', 'art 1002', 'art 1003', 'art 1004', 'art 1006', 'art 1002', 'art 1004', 'art 1004', 'art 1007', 'art 1002', 'art 1006', 'art 1004', 'art 1003', 'art 1007']

Patent US20080021916 - Maintenance of a markup language document in a database - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Advanced Patent Search | Sign inAdvanced Patent SearchPatentsA method, an apparatus and a computer program product for converting an XML encoded document into an equivalent SQL table are provided. An arbitrary XML DTD may be converted into an equivalent form by means of which individual node documents stored in the SQL table may be directly accessed. The SQL table...http://www.google.com/patents/US20080021916?utm_source=gb-gplus-sharePatent US20080021916 - Maintenance of a markup language document in a databasePublication numberUS20080021916 A1Publication typeApplicationApplication numberUS 11/892,907Publication dateJan 24, 2008Filing dateAug 28, 2007Priority dateNov 16, 2001Also published asUS7281206, US20030177443Publication number11892907, 892907, US 2008/0021916 A1, US 2008/021916 A1, US 20080021916 A1, US 20080021916A1, US 2008021916 A1, US 2008021916A1, US-A1-20080021916, US-A1-2008021916, US2008/0021916A1, US2008/021916A1, US20080021916 A1, US20080021916A1, US2008021916 A1, US2008021916A1InventorsChristoph Schnelle, Geoffrey NolanOriginal AssigneeTimebase Pty LimitedReferenced by (10), Classifications (11), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetMaintenance of a markup language document in a databaseUS 20080021916 A1Abstract A method, an apparatus and a computer program product for converting an XML encoded document into an equivalent SQL table are provided. An arbitrary XML DTD may be converted into an equivalent form by means of which individual node documents stored in the SQL table may be directly accessed. The SQL table is able to be converted back into an XML document of similar structure to the original document from which the table was derived. A set of operations which can be performed on the SQL table is also disclosed. An arbitrarily complex XML document may be broken into suitably sized portions, each of which can be managed independently as a standalone XML document without compromising the validity of the document as a whole. The management of these portions takes advantage of the speed, robustness and maturity of RDBMS systems, while maintaining the hierarchical structure inherent in all XML documents. Images(17) Claims(57)
during the initial conversion and using these embedded codes to redirect the reconstructed nodes to the appropriate output file. SQL Document Access/Maintenance The decomposition of a large XML document into independent, smaller sub-documents is simply a means to an end. It is important to be able to access and modify the information in these sub-documents. A method, an apparatus and a computer program product for maintaining an XML document in MALTbase SQL form, without the need for reconverting the document to XML, are described. A primary use of MALTbase is to store complex XML documents within SQL databases. In general, the node element set is chosen so that each node represents a reasonable portion of the data to retrieve or maintain. Since the converted node content is already in the form of a standalone XML document, any standard XML author/editing tool can be used to examine or modify the content. MALTbase allows five basic node operations: modify an existing node insert a new node (or sub-tree) delete an existing node (or sub-tree) copy an existing node (or sub-tree) to a new location relocate placeholders within a node In particular, if this standard XML author/editing tool supports an interface with an SQL Application Programming Interface (API), an editing session consists of the following steps: locate the node to be edited (all editing is on a per node basis); activate an edit function which: locks the node for writing, and establishes an edit session in which the editing tool manages the node content; and when the edit session is finished, the updated content is written back into the node record. Modify an Existing Node Simple modification involves a change to a node which does not affect: the node's DOCTYPE, element any element in the node element set any placeholder This operation is the most straightforward. Simply open the node, update the content, and save. The modify operation is the only operation performed on the target node itself. All other operations are performed on the parent of the node being inserted, deleted, etc. Insert a New Node To insert a new node, first open the parent of the node to be created. The parent node will have to contain a placeholder for the new node. However, a placeholder cannot be created directly, as placeholder management is a MALTbase system function. Further, there is no current node to which a placeholder can point. A solution is to enter the new material in situ, just as if editing the original document. For example, to create a new section in an act, open the act and simply key in the new section in the desired location. Use <section> elements and not <MALTbase:section/> in this procedure. Inside the section element, key the content normally. Node elements may be included in this content, where permitted by the DTD. When all the new material has been keyed, save the edited node. At this point, the MALTbase system takes over. MALTbase routinely examines all updated nodes before saving the updated nodes. If MALTbase detects any node elements within a node, MALTbase will automatically decompose the node elements into as many new sub-nodes as are required, and replace the outermost sub-node with a placeholder. In effect, this is exactly the same process as was used to convert the original document, only limited to the content of a single node. This process cannot affect the validity of the master document, as the editing application will have validated the modified node prior to saving. Delete an Existing Node To delete a node, edit the node's parent and delete the appropriate placeholder. The editing application will ensure that such a deletion is valid. When saving the edited parent, the MALTbase system compares the list of child IDs with a list prepared by the system when the parent node was opened. If any placeholders are missing then the corresponding nodes (and any descendants) are deleted from the system. In this way, the validity of the whole document is maintained provided the validity of each individual node is preserved. Copy an Existing Node To copy a node, the node ID of the node to be copied must be known. Edit the node that will be the parent of the new copy, and insert a placeholder with an element name and child-id set to the ID of the node to be copied. If the node to be copied is not already a child of the parent, the full child ID is used, rather than just the final segment. The editing application will ensue that such an insertion is valid. When saving the edited parent, the MALTbase system will locate the nodes which have been amended in this way. A duplicate node will be created with identical content to the original, but with a parent ID set to the parent node that was edited. Any descendants will also be copied and be assigned new Ids, as appropriate, based on the parent ID and order amongst the node's existing child nodes. Note that the child-id entered on the new placeholder must be a valid ID for an existing node somewhere in the master document. It is not possible to create new nodes using this technique. Either an absolute or relative ID may be used. An absolute ID) begins with �/� and gives a full path down from the root node, whereas a relative ID begins with �./� and relates the child to the current parent. Absolute IDs are typically used except where the node to be copied is already a child of the new parent. The presence of the slash character in the child-id tells the system that an existing child node is not simply being relocated. Whatever form of child-id is used, the copy will be assigned a new regular child ID and the placeholders will be altered to reflect this. Relocate Child Nodes within a Parent It is possible to move existing placeholders to any valid location within a node being edited. This is a simple modification (see above) provided that the placeholders remain in the same order with respect to each other. However, if editing does affect the order of the placeholders, then a relocation operation will be triggered when saving the node. As is the case for deletions, the system detects relocations by comparing a list of placeholders with a list of placeholders constructed before the editing session. The system assigns new child IDs to as many sub-nodes as necessary to ensure that the IDs once again correctly reflect the order of the child nodes within the parent node. These new IDs will also be applied to all descendants of affected nodes. Database Operation Examples FIGS. 9 a to 9 d illustrate the results of various database operations. FIG. 9 a shows the result of a simple modifier operation, in which text is inserted into the level-2 �mama� node. As the modification only affects the content of the node and no placeholders are affected, the new text is simply inserted. FIG. 9 b shows the result of a delete database operation. In this particular example, the level-3 child node is deleted and the �mama� node is now childless. The MALTbase system will automatically remove the deleted node when this �mama� node is saved. FIG. 9 c shows the result of an insertion of a new level-2 node. The new level-2 node is inserted directly into the perspective parent node, in this case the level-1 �papa� node shown in FIG. 9 c(1). When the level-1 �papa� node is saved, a new node having an id of �/1/1.5� is created, as shown in FIG. 9 c(2). The text inserted into the level-2 �papa� node is replaced by a placeholder, as shown in FIG. 9 c(3). FIG. 9 d illustrates the relocation of existing placeholders. FIG. 9 d(1) shows that the �mama� node has been moved and now appears after the �goldilocks� node. On being saved, the MALTbase system modifies the child ids of the sub-nodes of the level-1 �papa� node so that the child ids stay in ascending order. Accordingly, FIG. 9 d(2) shows that the child-id of the �mama� node has been modified and is now �3�. Document Integrity The chief value of the MALTbase system is that MALTbase guarantees that the whole master document will remain valid throughout any amount of editing and updating of the node sub-documents. In practice, this guarantee rests on three fundamental principles: 1. Each node document must at all times remain valid against the modified DTD; 2. The integrity of the interrelationships between the nodes, embodied in the database, must be preserved; and 3. The constraints which ensure the successful reassembly of the nodes into a master document must be honoured. The following sections explain these principles in greater detail. Node Validity Clearly, if the individual node documents are compromised, there is no way that the integrity of the master document can be maintained, let alone guaranteed. Fortunately, any validating XML editor will take care of this, and the MALTbase system will immediately reject any attempt to save an invalid node document. Database Integrity This is a much more subtle requirement, and correspondingly harder to police. Part of the requirement is handled by the MALTbase system when it analyses the placeholders of incoming nodes. The system will reject any node which: has a placeholder referring to a nonexistent node; has a placeholder whose element type does not match the corresponding node; or has duplicate placeholders, except for those with child IDs beginning with �/� or �_/� (which imply a copy operation). It should be noted that all of the above constraints can be violated by a �valid� node document. Since MALTbase allows many nodes to be edited simultaneously, it must also prevent inadvertent conflicts between these operations. This is done via the database locking mechanism. A modern database will typically support both read and write locks at the record (i.e. node) level. A read lock prevents a node from being updated for the duration of the lock, but allows any number of simultaneous read operations. A write lock prevents any access to the locked record for the duration of the lock. Thus, whenever a first user wishes to edit a node, the system attempts to obtain a write lock on that node. If another user is accessing the node, the attempt to lock will fail and the system will advise the first user that: The node is currently locked by another user, please try again later. If the lock succeeds, the first user has exclusive access to the node during the editing session. If a user aborts an editing session without saving, the system releases the lock and frees the node. However, if a user attempts to save the node, and assuming all placeholders are valid, the following actions occur: Simple Modify�the node content field is locked and the lock is released. Insertion�new nodes are created, and the parent node saved, in a single indivisible transaction after which all locks are released. If any part of the operation fails then the state of the database reverts back to what it was immediately prior to the edit session (a process known as rollback). Deletion�write locks are obtained on the node to be deleted, and all descendants of that node. The mass deletion and write-back of the original parent node form a single transaction. Copy�read locks are obtained on the node to be copied, and all descendants of that node. The mass copy, assignment of new IDs, and write-back of the target parent node form a single transaction. Relocation�write locks are obtained on all affected child nodes, and all descendants of that node. Assignment of new IDs, and write-back of the original parent node form a single transaction. The important thins that exclusive access to all the nodes being updated must be obtained before any part of the update can proceed. In this way, the linkage between placeholders and the corresponding node content is maintained and complex operations can proceed in parallel without threatening the integrity of the database. The successful implementation of the method described above depends on two factors: the XML validity of the whole �document� must be maintained; and the integrity of the database itself must be preserved, so that the various operations (modify, delete, move etc.) must be correctly interlocked with each other by means of suitable database locks and transactions. The XML validity of the whole document is guaranteed because of the DTD transform through which individual node documents are created. Since each occurrence of a sub-node placeholder in a content model is paired precisely with an occurrence of the original element in that model, it follows that substituting a placeholder for a sub-node (or vice versa) has no effect on the validity of the whole. Thus, provided that a node document remains always valid and every sub-node marker corresponds to a real node document before saving the text in the database, a back conversion into XML always yields a valid document. The second criterion, preserving database integrity, is a more complex matter and must be enforced by the use of appropriate relational database management system (RDBMS) mechanisms during the implementation. The first precaution is that a write (exclusive) lock must be obtained on a node record before an edit session may commence. This prevents any other user editing the node at the same time, but may leave both descendants and ancestor nodes free for editing (except if someone tries to delete a sub-tree which includes the node of interest). Such considerations, however, we standard RDBMS practice and familiar to persons skilled in the art. The additional processes accompanying the write-back of a node into the database are of greater interest. To avoid potential confusion, the term principal node denotes the node that was modified and is being saved, and sub-node denotes one of the new or existing sub-nodes of the principal node. A placeholder is an empty MALTbase element that marks the location of a sub-node within the text of the principal node. The main steps involved in saving a modified principal node are as follows. Generate a list of placeholders (if any) in the principal node. If any placeholder a does not correspond with an actual database node, an error arises. Generate a list of existing sub-nodes from the database, and pair off placeholders and sub-nodes. If any sub-node is not matched against a placeholder, that sub-node and all the descendants of that sub-node are deleted from the database; If any placeholder is not matched against a sub-node, either an existing sub-node is being duplicated, or a node elsewhere in the database is being copied. Create the duplicate nodes (including descendants if any) and assign a provisional ID to each duplicate node. The ID consists of: the ID of the principal node, a provisional child ID within the principal node, and the trailing portion of the ID, if is the new node is a descendant of the node being copied. Scan the list of matched placeholders in document order. If any such placeholder has a lower child ID than one or more of its siblings already processed, assign a provisional child ID. If there are any sub-node elements (as opposed to placeholders) present, perform a standard MALTbase XML-to-SQL conversion on each such element and create new SQL records for each. Assign a provisional ID to each new node, assigning a provisional child ID within the principal node. Replace the text of each sub-node element in the principal node with a new placeholder. A principal node now exists in which each placeholder corresponds to a unique new or existing sub-node, and all with provisional child IDs (except for existing sub-nodes which retain the previous ordering). The final step is to assign permanent child IDs to the placeholders, replacing the provisional segment in the ID of each corresponding sub-node (or descendant). The new IDs are normally chosen to evenly fill the range between the previous existing child ID (or �0� if none) and the following existing child ID (or �ffff . . . �), using as few hex digits as possible. Additional Constraints There are a few additional constraints required by a MALTbase system that are not directly related either to database integrity or sub-document validity. These constraints are required to ensure that the reverse transform (node set to single XML document) works properly. The first requirement is that the DTD cannot be freely altered while the document is stored as a node set. If the DTD is to be changed, one of two things must happen: 1. The master document is reassembled prior to the change and the MALTbase version reconstructed after the change; and 2. The whole database is locked for the duration of the change, and every sub-document successfully revalidated before the locks are released. The second requirement is that the DOCTYPE element of a sub-document cannot be freely altered. This is because, while the sub-document itself is validated by the XML editor, the new element type (and hence the new element type's matching placeholder) may not be valid within the parent node's content. If such a change is required, it must be performed as follows: 1. Copy the content of the node to be modified to a temporary holding area; 2. Edit the parent, delete the corresponding placeholder, and insert the stored content in its place; 3. Modify the content to change the element type; 4. If the content contains placeholders of its own, the child-id attributes must be modified from CCC to ./NNN/CCC, where CCC is the current value of the attribute, and NNN is the child-id of the content being edited (i.e. the child-id of the placeholder removed in step 2); and 5. When the parent node is caved, the original child and, the original child's descendants will be deleted. Before this happens, any sub-nodes specified in step 4 (and such sub-nodes' descendants) will be copied. So in effect, an insert is performed, followed by a copy, followed by a delete. The above technique will work even in the unlikely event that the new element type is not itself a node element. Any attempt to alter a node simply by changing the node's DOCTYPE element will be blocked by the system which stores the DOCTYPE of each node before the node is edited. The final constraint is that the node element set cannot be altered for a MALTbase document. If the node elements do need to be adjusted, then the master document must be reassembled. The master document can tend be decomposed back into MALTbase form using the new node element set. FIGS. 10 a-10 f show a graphical representation of a SQL node write back. FIG. 10 a shows an exemplary principal node 1000 relating to a chapter 7 that has first, second, third and fourth parts 1001, 1002, 1003 and 1004, respectively, and a note 1005. Each of the first, second, third and fourth parts 1001, 1002, 1003 and 1004 and the note 1005 has an associated child-id. The first part 1001 has a child-id �1�, the second part 1002 has a child-id �4�, the third part 1003 has a child-id �7�, the fourth part 1004 has a child-id �a�, and the note 1005 has a child-id �d�. The additional processes accompanying the write-back procedure of a node into the database are now illustrated using the principal node 1000 of FIG. 10 a. The write-back procedure is considered in an example in which: (i) a part of the principal node 1000 of FIG. 10 a is replaced with a part from another location; (ii) a part of the principal node 1000 of 10 a is duplicated (perhaps as a preliminary to splitting the material into two new parts); and (iii) a completely new part is inserted into the principal node 1000 of FIG. 10 a. FIG. 10 b shows the editing of the principal node 1000 to create a modified node 1000 a by moving, inserting and deleting placeholders corresponding to existing nodes. New sub-node elements are inserted to create new nodes. A fifth part 1006 from another location replaces the second part 1002 of FIG. 10 a. The fourth part 1004 of FIG. 10 a is duplicated and the duplicate appears as a new sixth part 1004 a. Further, a completely new part 1007 is inserted into the modified node 1000 a. The XML editing application being used (for example, XMetal, Epic, XML Spy) ensures that the new modified node 1000 a is valid and the MALTbase strategy ensures that the wider document is also valid. When saving the modified node 1000 a shown in FIG. 10 b, the following steps occur: 1. Generate a list of placeholders: 1, /8/C/3b/2, a, 7, a, d These placeholders are the child-ids of the parts and the note of the modified node 1000 a; 2. Generate a list of existing sub-nodes: 1, 4, 7, a, d. These are the child-ids associated with the parts and the note of the node 1000 of FIG. 10 a; 3. Generate a list of unmatched sub-nodes: 4. Any such sub-node and each such sub-node's associated descendants are deleted. In this case, the second part 1002 of FIG. 10 a, having a child-id of �4�, is deleted, along with any of the second part's descendants; and 4. Generate a list of unmatched placeholders: /8/c/3b/2, a. Any such nodes having unmatched placeholders are duplicated, along with any associated descendants, and provisional IDs are assigned to the duplicated nodes. FIG. 10 c shows the further modified node 1000 b in which provisional IDs have been assigned to each of the new fifth part 1006 and fourth part 1004. FIG. 10 d shows the allocation of provisional IDs to any placeholder that is out of order. In this instance, the third part 1003 having a child-id of �7� is deemed to be out of order and a new provisional id of �x3� is assigned. FIG. 10 e shows the conversion of any sub-node elements and the replacement of placeholders. The new fifth part 1007 is assigned an id of �x4�. FIG. 10 f shows the next stage in the write-back process, in which new child IDs are allocated to placeholders and corresponding nodes and any descendants. If all steps are successful, all such modified nodes are saved. If any step fails, the procedure rolls back to the previous state. An analysis of the above process confirms that, provided all the steps are carried out as a single database transaction, the integrity of the database is retained. If any step fails, the whole operation has to be rolled back and the user prompted to abort or try again. Examples of potential failure include child-id attributes that do not correspond to an existing node, failure to obtain read locks on sub-trees being copied etc. However, since the time that any node (other than the principal node) is locked is only a fraction of a second, deadlocks should be rare given the normal access patterns of users within XML text files. Various techniques (such as analyzing child IDs to minimize node ID modifications) can of course be used to increase efficiency. General A strategy and software, to be known as �MALTbase�, have been described for converting arbitrary XML data into SQL tables. Unlike conventional object-relational mapping techniques, MALTbase is designed to produce an optimal SQL table set with a minimum of tables and records, but which contains sufficient information for the original XML to be reconstructed on demand. In this way, the performance and management benefits of using SQL are maximized. MALTbase is a technology which facilitates the storage and maintenance of very large XML documents. It does this by breaking the original (master) document into a large number of nodes, each of which resides in its own sub-document. A MALTbase node is defined to be the content of any of a set of nominated elements (the node element set). The important distinction between a node and an element is that a node does not explicitly contain the content of any sub-node. Instead, the sub-nodes within a node are represented by placeholders, which are empty tags marking the position of a sub-node, and pointing to the relevant sub-node document. One of the greatest benefits of this system is that the nodes are created in such a way that: if you ensure the validity of each node, then the validity of the entire document is guaranteed. It is difficult to overstate the importance of this point, since this feature allows a user to update a single node in isolation. Provided a user's updates leave the node valid against the DTD (as all good XML editors should), then the user can be confident that the larger document as a whole will also be valid, without having to examine anything outside the scope of the node's being modified. The method of converting XML data into SQL tables is preferably practised using a general-purpose computer system 1100, such as that shown in FIG. 11 wherein the processes of FIGS. 3 to 10 may be implemented as software, such as an application program executing within the computer system 1100. In particular, the steps of a method of converting XML data into SQL tables are effected by instructions in the software that are carried out by the computer. The instructions may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part performs one or more methods of FIGS. 3 to 10 and a second part manages a user interface between the first part and the user. The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer from the computer readable medium, and then executed by the computer. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the computer preferably effects an advantageous apparatus for FIGS. 3 to 10. The computer system 1100 comprises a computer module 1101, input devices such as a keyboard 1102 and mouse 1103, output devices including a printer 1115 and a display device 1114. A Modulator-Demodulator (Modem) transceiver device 1116 is used by the computer module 1101 for communicating to and from a communications network 1120, for example connectable via a telephone line 1121 or other functional medium. The modem 1116 can be used to obtain access to the Internet, and other network systems, such as a Local Area Network (LAN) or a Wide Area Network (WAN). The computer module 1101 typically includes at least one processor unit 1105, a memory unit 1106, for example formed from semiconductor random access memory (RAM) and read only memory (ROM), input/output (I/O) interfaces including a video interface 1107, and an I/O interface 1113 for the keyboard 1102 and mouse 1103 and optionally a joystick (not illustrated), and an interface 1108 for the modem 1116. A storage device 1109 is provided and typically includes a hard disk drive 1110 and a floppy disk drive 1111. A magnetic tape drive (not illustrated) may also be used. A CD-ROM drive 1112 is typically provided as a non-volatile source of data. The components 1105 to 1113 of the computer module 1101 typically communicate via an interconnected bus 1104 and in a manner which results in a conventional mode of operation of the computer system 1100 known to those in the relevant art. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations or alike computer systems evolved therefrom. Typically, the application program is resident on the hard disk drive 1110 and read and controlled in its execution by the processor 1105. Intermediate storage of the program and any data fetched from the network 1120 may be accomplished using the semiconductor memory 1106, possibly in concert with the hard disk drive 1110. In some instances, the application program may be supplied to the user encoded on a CD-ROM or floppy disk and read via the corresponding drive 1112 or 1111, or alternatively may be read by the user from the network 1120 via the modem device 1116. Still further, the software can also be loaded into the computer system 1100 from other computer readable media. The term �computer readable medium� as used herein refers to any storage or transmission medium that participates in providing instructions and/or data to the computer system 1100 for execution and/or processing. Examples of storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1101. Examples of transmission media include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including email transmissions and information recorded on websites and the like. The method of converting XML data into SQL tables may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing the functions or sub functions of FIGS. 3 to 10. Such dedicated hardware may include one or more microprocessors and associated memories. INDUSTRIAL APPLICABILITY It is apparent from the above that the arrangements described are applicable to any industry that has a need to efficiently access and/or modify XML encoded text-based data, also referred to as document-centric XML. Examples are the electronic publishing industry, document management, publishers and service providers dealing with requirements engineering documents, journal articles, manuals, software and other online help, etc. The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7827177 *May 29, 2007Nov 2, 2010Oracle International CorporationManaging compound XML documents in a repositoryUS7865477 *Oct 15, 2007Jan 4, 2011Microsoft CorporationSystem and method for real-time validation of structured data filesUS8090839 *Jun 21, 2006Jan 3, 2012Cisco Technology, Inc.XML message validation in a network infrastructure elementUS8418053 *Mar 31, 2006Apr 9, 2013Fujitsu LimitedDivision program, combination program and information processing methodUS20070150809 *Mar 31, 2006Jun 28, 2007Fujitsu LimitedDivision program, combination program and information processing methodUS20080033967 *Jul 18, 2006Feb 7, 2008Ravi MurthySemantic aware processing of XML documentsUS20100241949 *Mar 18, 2010Sep 23, 2010Canon Kabushiki KaishaMethod of coding or decoding a structured document by means of an xml schema, and the associated device and data structureUS20110093486 *Mar 3, 2010Apr 21, 2011Institute For Information IndustryData query method, data query system and computer readable and writable recording mediumUS20120066577 *Sep 9, 2010Mar 15, 2012Microsoft CorporationConcurrent Editing of Online DrawingsWO2011146220A2 *Apr 29, 2011Nov 24, 2011Microsoft CorporationMapping documents to a relational database table with a document position column* Cited by examinerClassifications U.S. Classification1/1, 715/239, 715/234, 707/999.101, 707/999.104, 707/999.1International ClassificationG06F7/00, G06F17/00, G06F15/00Cooperative ClassificationG06F17/30917European ClassificationG06F17/30X3DLegal EventsDateCodeEventDescriptionAug 29, 2007ASAssignmentOwner name: TIMEBASE PTY LIMITED, AUSTRALIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SCHNELLE, CHRISTOPH;NOLAN, GEOFFREY JOHN;REEL/FRAME:019796/0880Effective date: 20011123RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google