Techniques for efficient loading of binary xml data
Claim Score by NHIP
Abstract
Various techniques are described hereafter for improving the efficiency of binary XML encoding and loading operations. In particular, techniques are described for incrementally encoding XML in response to amount-based requests. After encoding enough binary XML to satisfy an amount-based request, the encoder stops encoding the XML until a subsequent request is received. The incremental encoding may take place on the client-side or the server-side. Techniques are also described for reducing the character set conversion operations by having a parser convert tokens in text XML into one character set while converting non-token text in the text XML into another character set. Techniques are also described for generating self-contained binary XML documents, and for improving remap operations by providing a binary XML document on a chunk-by-chunk basis.
Term
3 yearsto projected expiry
Projected expiry 30 September 2029, counted from filing; an application has no term until it is granted.
- Priority
- Filed
- Published
- Today
- Projected expiry
46 claims: 5 independent, 41 dependent
- 1A method for encoding XML, comprising the computer-implemented steps of:receiving a request for a specified amount of binary encoded XML;in response to the request, encoding text XML on a per-node basis until sufficient binary XML has been generated to satisfy the request;responding to the request with said amount of binary XML;and once the request has been satisfied, ceasing to encode the text XML until receiving a subsequent request for binary encoded XML.
- 7Broadest claimClaim Score 78, broad(NHIP)A method for encoding binary XML, comprising:detecting, by a parser that is parsing text XML, a node that qualifies as a simple property;sending to an encoder an indication that the node is a simple property;and in response to receiving the indication from the parser, the encoder encoding the node by generating a simple property opcode and a set of one or more operands associated with the simple property opcode.
- 10A method for encoding XML, comprising:receiving, at a parser, text XML to be converted to binary XML;wherein the text XML includes (a) character strings that correspond to tokens, and (b) character strings that do not correspond to tokens;wherein characters of the text XML are from a first character set;the parser converting the character strings that correspond to tokens into characters of a second character set;and the parser converting the character strings that do not correspond to tokens into characters of a third character set;wherein the first, second and third character sets are three different character sets.
- 13A method of converting an XML document to a binary XML document, comprising:converting information from the text XML document to binary XML, wherein the binary XML includes a series of opcodes and operands associated with the opcodes;in the binary XML generated from the text XML document, representing tokens from the text XML with identifiers;and including in the binary XML document, (a) the binary XML generated from the text XML document, and (b) an identifier-to-token mapping that allows a recipient of the binary XML document to reproduce the text XML document from the binary XML without resort to translation information separate from the binary XML document.
- 20A method of storing an XML document in a repository, the method comprising:on a client, receiving the XML document as text XML;at the client, converting the text XML to binary XML based, at least in part, on a set of one or more client-created token-to-identifier mappings;after converting the text XML to binary XML, providing the XML document to a server in a series of chunks;and including with each chunk only those client-created token-to-identifier mappings that (a) were used to generate identifiers that are contained in the chunk, and (b) were not included in any chunks that preceded the chunk in the series of chunks.
Independent claims5
121 paragraphs in 4 sections, as filed
0001This application is related to and claims the benefit of priority from provisional Application No. 60/853,236 filed Oct. 20, 2006, entitled “Handling Binary Xml”, the entire content of which is incorporated by this reference for all purposes as if fully disclosed herein.
0002This application is also related to the following applications, the content of which is incorporated by this reference for all purposes as if fully disclosed herein:
0003U.S. patent application Ser. No. 11/182,997, filed Jul. 14, 2005, entitled “Encoding Of Hierarchically Organized Data For Efficient Storage And Processing” (hereinafter the “Binary XML Application”);
0004U.S. patent application Ser. No. 10/884,311, filed Jul. 2, 2004, entitled “Index For Accessing XML Data”;
0005U.S. patent application Ser. No. 11/437,512, filed May 18, 2006, entitled “Efficient Piece-Wise Updates Of Binary Encoded Xml Data”;
0006U.S. patent application Ser. No. 11/401,613, filed Apr. 10, 2006, entitled “A Mechanism For Improving Performance On Xml Over Xml Data Using Path Subsetting”;
0007U.S. patent application Ser. No. 11/601,118, filed Nov. 16, 2006, entitled “CLIENT PROCESSING FOR BINARY XML IN A DATABASE SYSTEM” (hereinafter the “Client-side Processing Application);
0008U.S. patent application Ser. No. 11/707,730 filed Feb. 16, 2007, entitled “ENCODING INSIGNIFICANT WHITESPACE OF XML DATA”; and
0009U.S. patent application Ser. No. 11/715,603 filed Mar. 7, 2007, entitled “INCREMENTAL MAINTENANCE OF AN XML INDEX ON BINARY XML DATA”.
FIELD OF THE INVENTION
0010The present invention relates to encoding XML in a binary format and, more specifically, to techniques for efficiently encoding binary XML and loading the binary XML into a repository.
BACKGROUND
0011The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Binary XML
0012Binary XML is one format in which XML data can be stored in a database. Binary XML is a compact binary representation of XML that was designed to reduce the size of XML documents. One of the ways binary XML compresses data is by representing strings (“tokens”) with fixed values.
0013In one implementation of binary XML, a mapping is established between character strings and replacement values, where the character strings are tag names, and the replacement values are numbers. Such mappings are referred to herein as “translation information”.
0014For example, consider an XML document PO<b>1</b> that contains the following content:
0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><Purchase Order></entry></row><row><entry /><entry> <body></entry></row><row><entry /><entry> Important Data</entry></row><row><entry /><entry> </body></entry></row><row><entry /><entry></Purchase Order></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0015PO<b>1</b> includes the tokens “Purchase Order” and “body”. To store PO<b>1</b> in binary XML format, the token “Purchase Order” may be mapped to 1, and the token “body” may be mapped to 2. Typically, the replacement values consume much less space than the corresponding tokens. For example, the token “Purchase Order”, which contains fourteen characters, may be assigned a binary replacement value that takes less space to store than a single text character.
0016Once translation information has been created, XML documents may be stored in binary XML based on the translation information. For example, PO<b>1</b> may be stored as <1><2>Important Data</2></1>. In typical implementations of binary XML, even the symbols (e.g. “<”, “>”, and “/”) may be represented by binary replacement values.
Translating Between Binary XML and TEXT
0017When stored in binary XML, an XML document consumes much less space than is required by other formats of XML storage. However, the space savings is achieved at the cost of additional overhead required to convert textual XML to binary XML, and to convert binary XML to textual XML. For example, to be meaningful to an application that requests PO<b>1</b>, <1><2>Important Data</2></1> would have to be translated back into:
0000<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><Purchase Order></entry></row><row><entry /><entry> <body></entry></row><row><entry /><entry> Important Data</entry></row><row><entry /><entry> </body></entry></row><row><entry /><entry></Purchase Order></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0018In order to reconstruct the text of an XML document that has been stored in binary format, the translation information that was used to encode the XML document must be available. The translation information that is used to store XML data within a database are typically stored separate from the binary XML data itself.
Translation Information
0019How database system stores translation information may hinge on whether the translation information is for known-schema XML or for unknown-schema XML. XML data is “known-schema” XML if the database server knows the XML schema to which the XML data conforms. The database server may “know” the schema, for example, if the schema has been registered with the database server.
0020On the other hand, XML data is “unknown-schema” XML if the database server does not know the schema to which the XML data conforms. Thus, unknown-schema XML includes both (a) XML documents that do not conform to any schema, and (b) XML documents that conform to an XML schema, but the XML schema is not known to the database server.
0021In some database systems, the translation information for known-schema binary XML is stored on a per-schema basis. Thus, since all documents that conform to a given schema will typically contain the same tag strings, the same translation information is used to encode all of the documents that conform to the given schema.
0022According to one embodiment, the translation information for known-schema binary XML is stored, in the database, as part of the definition of the schema. Schema definitions, in turn, are stored in a schema table.
0023In some database systems, the translation information for all unknown-schema binary XML are stored in tables referred to herein as “token tables”. In one embodiment, three token tables are used to store the translation information for unknown-schema XML: a Qname token table, a namespace token table, and a path-id token table. The three token tables are collectively referred to as a “token table set”.
0024The Qname token table for an XML schema contains the Qname-to-replacement-value mappings used to encode the Qnames contained in unknown-schema XML. The namespace token table for an XML schema contains the namespace-to-replacement-value mappings used to encode the namespaces contained in unknown-schema XML. The path_id token table for an XML schema contains the path_id-to-replacement-value mappings used to encode the path_ids contained in unknown-schema XML.
Server-Side Translation
0025Currently, client programs do not understand Binary XML data. Consequently, data is sent from client programs to the database as XML text. Within the database server, the XML text is parsed and encoded to the Binary format. Similarly, when client programs need to read XML data which has been stored in the Binary format, the data is converted to the text on the server and sent over to the client as XML text where it needs to be parsed to be operated upon.
0026<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of a system that uses server-side translation of binary XML. Referring to <figref idref="DRAWINGS">FIG. 1</figref>, a client <b>102</b> sends text formatted XML <b>104</b> to a database server <b>106</b> for storage in a database <b>110</b>. Upon receiving the textual XML <b>104</b> from the client <b>102</b>, an encoder/decoder <b>108</b> within the database server <b>106</b> encodes the XML into binary XML <b>112</b> based on translation information <b>116</b> retrieved from the database <b>110</b>. Once encoded, the binary XML <b>112</b> may be stored in a binary XML repository <b>114</b> within the database <b>110</b>.
0027The retrieval of binary XML from database <b>110</b> works in a similar manner. Specifically, the binary XML is retrieved from the database <b>110</b>, decoded by the database server <b>106</b> using encoder/decoder <b>108</b> and translation information <b>116</b>, and the textual version of the XML is sent back to the client <b>102</b>.
0028Unfortunately, sending uncompressed data across the wire from client to server and server to client in this manner requires a significant amount of network bandwidth, which is expensive. In addition, the database server CPU has to spend extra cycles trying to parse the XML text coming from clients, and to print the encoded text to the text format that is sent to clients. The server-side operations adversely affect the scalability of the database server.
Client-Side Translation
0029The Client-side Processing Application describes a system in which the translation is performed on the client-side. Performing the translation on the client-side increases scalability by reducing the amount of work the server must perform as XML data is stored into and retrieved from binary XML repository <b>114</b>. As also described in the Client-side Processing Application, a client-side cache of translation information may be used to further improve the performance of operations that load binary XML into XML documents within binary XML repository <b>114</b>. It is clearly desirable to provide further techniques to improve the speed, increase the scalability, and reduce the memory consumption, of binary XML loading operations.
BRIEF DESCRIPTION OF THE DRAWINGS
0030The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
0031<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of a system that uses server-side translation of binary XML;
0032<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of a system that uses client-side translation of binary XML, according to an embodiment of the invention;
0033<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram of a system that includes an encoder configured to incrementally encode XML in response to amount-based requests, according to an embodiment of the invention;
0034<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram that illustrates chunks formed by a chunking technique to improve the efficiency of remap operations, according to an embodiment of the invention; and
0035<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram of a computer system that may be used to implement embodiments of the invention.
DETAILED DESCRIPTION
0036In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
Overview
0037Various techniques are described hereafter for improving the efficiency of binary XML encoding and loading operations. Specifically, techniques are described for incrementally encoding XML in response to amount-based requests. After encoding enough binary XML to satisfy an amount-based request, the encoder stops encoding the XML until a subsequent request is received. The incremental encoding may take place on the client-side or the server-side.
0038In one embodiment, the encoding requests are generated by a process responsible for storing the encoded binary XML (an “XML-storing process”). In such an embodiment, the XML storing process may determine how much data to request in the amount-based requests based on how much data the XML-storing process can directly store into the appropriate storage within the XML repository. Consequently, the XML-storing process need not buffer a copy of the binary XML prior to storing the binary XML into the repository.
Client-Side Translation Example
0039<figref idref="DRAWINGS">FIG. 2</figref> illustrates a system that uses client-side translation of binary XML. In the illustrated system, an encoder/decoder <b>208</b> within a client <b>202</b> encodes textual XML <b>204</b> into binary XML <b>212</b> based on translation information <b>216</b> retrieved from the database <b>210</b>. Once encoded, the client <b>202</b> sends the binary XML <b>212</b> to a database server <b>206</b> for storage in the database <b>210</b>.
0040The retrieval of binary XML from database <b>210</b> works in a similar manner. Specifically, the database server <b>206</b> retrieves the binary XML <b>212</b> from binary XML repository <b>214</b> within the database <b>210</b>, and sends the binary XML <b>212</b> to the client <b>202</b>. Within the client <b>202</b>, the binary XML is decoded using encoder/decoder <b>208</b> and translation information <b>216</b>, to reconstruct the textual version of the XML inside client <b>202</b>. In the illustrated embodiment, the client <b>202</b> maintains the translation information <b>216</b> within a client-side translation information cache <b>220</b>.
Client-Side Cache of Translation Information
0041Using client-side translation, less bandwidth is used in the client/server communications, and fewer server-side computational resources are required to support the storage of binary XML. However, to do the encoding or decoding of the data efficiently on the client side, the client has to have the appropriate translation information. Such translation information includes the token-to-replacement-value mappings that are stored in the schema table and/or token tables within the database.
0042When the client needs to encode or decode an XML document, the client <b>202</b> obtains the translation information <b>216</b> required for the operation from the database <b>210</b> by sending a request for the translation information to the database server <b>206</b>. However, to avoid the need to query the database server <b>206</b> every time an XML document needs to be encoded/decoded, the client <b>202</b> may maintain a cache <b>220</b> of the translation information. By maintaining a client-side cache <b>220</b> of translation information, the client <b>202</b> need only query the database server <b>206</b> for translation information <b>216</b> if the translation information <b>216</b> does not already reside in the cache <b>220</b>.
On-Demand XML Encoding
0043As mentioned above, techniques are described herein for incrementally encoding XML in response to amount-based requests. <figref idref="DRAWINGS">FIG. 3</figref> is a block diagram of a system that includes an encoder <b>304</b> configured to incrementally encode XML in response to amount-based requests <b>308</b>. Encoder <b>304</b> may be part of encoder/decoder <b>208</b>, illustrated in <figref idref="DRAWINGS">FIG. 2</figref>.
0044While on-demand binary XML encoding is described herein with reference to an embodiment in which the encoding is performed on the client-side, on-demand binary XML encoding may also be performed by embodiments that employ server-side encoding.
0045In one embodiment, the XML-storing process, which is responsible for storing the encoded binary XML in the binary XML repository <b>214</b>, determines how much data to request in the amount-based requests based on how much data the XML-storing process can directly store into the appropriate storage within the XML repository. Consequently, the XML-storing process need not buffer a copy of the binary XML prior to storing the binary XML into the repository. Thus, in the system illustrated in <figref idref="DRAWINGS">FIG. 3</figref>, database server <b>206</b> determines how much space is available within binary XML repository <b>214</b> for storing binary XML <b>212</b>. Database server <b>206</b> then sends an amount-based request <b>308</b> to encoder <b>304</b> for that amount.
0046In response to an amount-based request, encoder <b>304</b> decodes a sufficient amount of text XML <b>204</b> to produce the requested amount of binary XML data. Encoder <b>304</b> then provides the requested amount of binary XML data to database server <b>206</b>, which is able to immediately store the binary XML into binary XML repository <b>214</b>. By incrementally encoding the XML in response to amount-based requests, and generating amount-based requests based on how much binary XML data can be directly stored into the binary XML repository <b>214</b>, the need for the database server <b>206</b> to buffer a copy of the binary XML is avoided.
0047<figref idref="DRAWINGS">FIG. 3</figref> illustrates on-demand encoding of XML in a system that uses a client-side encoder. However, as mentioned above, the on-demand encoding techniques described herein may be used with server-side translation systems also. In both cases, on-demand encoding may be used to avoid the need of the XML-storing process to buffer a copy of the encoded binary XML, which would subsequently have to be loaded into the appropriate structure (e.g. a BLOB) within the binary XML repository <b>214</b>.
The Carry-Over Buffer
0048Even though the requests are amount-based, the encoding of binary XML is performed on a per-node basis. Consequently, the encoding performed in response to an amount-based request may produce more binary XML than the requested amount. For example, assume that text XML <b>204</b> includes three nodes A, B and C, in that order. Assume further that nodes A, B, and C respectively translate into 10, 5, and 10 bytes of binary XML. Under these circumstances, encoder <b>304</b> would respond to an amount-based request for 12 bytes by encoding both nodes A and B. However, encoding A and B produces 15 bytes, which is 3 bytes more than the requested 12 bytes.
0049According to one embodiment, encoder <b>304</b> is configured to handle such overflow conditions by storing the binary XML data that exceeds the requested amount in a carry-over buffer <b>306</b>. The binary XML in the carry-over buffer <b>306</b> is then used to satisfy the next amount-based request. If the amount in the carry-over buffer <b>306</b> is not sufficient to satisfy the next amount-based request, then encoder <b>304</b> encodes one or more additional nodes until enough binary XML has been produced to satisfy the amount-based request.
0050For example, after encoding nodes A and B, encoder <b>304</b> would provide the first 12 bytes to database server <b>206</b> in response to the request, and store the remaining 3 bytes in carry-over buffer <b>306</b>. Those 3 bytes would remain in carry-over buffer <b>306</b> until the next amount-based request <b>308</b> from database server <b>206</b>. For the purpose of explanation, assume that the next amount-based request <b>308</b> from database server <b>206</b> was for another 12 bytes of binary XML data. The 3 bytes of node B that currently reside in the carry-over buffer <b>306</b> are not sufficient to satisfy the 12 byte request, so encoder <b>304</b> encodes node C. Encoding node C produces 10 bytes. The 10 bytes from node C, combined with the three remaining bytes of node B, are sufficient to satisfy the 12 byte request. Therefore, the 3 bytes of node B, and the first 9 bytes of node C, are used to satisfy the 12 byte request. The remaining byte of node C is stored in the carry-over buffer <b>306</b> until the next amount-based request <b>308</b>.
Parser-Indicated Use of Simple Property Opcodes
0051A simple property is a property, within XML data, that either has no children, or has only a text child. Thus, in the following XML snippet:
0000<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="133pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><a></entry></row><row><entry /><entry> <b>text</b></entry></row><row><entry /><entry> <c>text</c></entry></row><row><entry /><entry></a></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0052node <a> is not a simple property, but nodes <b> and <c> are simple properties.
0053According to one embodiment, encoder <b>304</b> uses a simple property optimized opcode (referred to hereafter as “SPOO”) to better compress the binary XML. A SPOO is an opcode that represents an entire simple property. In one embodiment, the SPOO is followed by several operands, including (a) an operand indicating the token id of the node, (b) an operand that indicates the length of the data associated with the simple property, and (c) the actual data itself.
0054Unfortunately, encoding simple properties using a SPOO is complicated by the fact that encoder <b>304</b> generally does not know that a node that is being parsed is going to be a simple property until encoder <b>304</b> has received a certain pattern of events from parser <b>302</b>. Specifically, in response to parsing a simple property, parser <b>302</b> would typically generate three separate events: a start-of-element event indicating the start of an element, a characters event indicating the start of text, and an end-of-element event. Until encoder <b>304</b> receives all three of these events, the encoder <b>304</b> will not know that the property that is being encoded is a simple property.
0055If XML data conforms to a known XML schema, the XML schema may indicate which properties are simple properties and which properties are not. However, even when the schema indicates that a particular node is a simple property, the actual XML for the node may include comments or other information that may prevent the node from being encoded as a simple property.
0056To encode simple properties using a SPOO, encoder <b>304</b> may be configured to buffer the data provided by parser <b>302</b> until encoder <b>304</b> has received enough information to tell whether the current node is a simple property. However, to do so may involve having the encoder <b>304</b> separately buffer a large amount of data. Therefore, according to one embodiment, encoder <b>304</b> is configured to receive, from parser <b>302</b>, simple property indications <b>310</b>. By sending encoder <b>304</b> a simple property indication, parser <b>302</b> indicates that the current node is a simple property. In response, encoder <b>304</b> may immediately generate a SPOO and begin encoding the simple property accordingly. If encoder <b>304</b> does not receive a simple property indication <b>310</b>, then encoder <b>304</b> may proceed with normal opcode encoding, without having to buffer a large amount of output from parser <b>302</b>.
0057According to one embodiment, the simple property indication produced by the parser <b>302</b> is in the form of a compound event, where the compound event is a single event that represents the three events (start-of-element, characters, end-of-element) that the parser <b>302</b> would normally produce for a simple property. In one embodiment, the compound event includes the element name, the text name and length, and the namespace of the element. In response to receiving the compound event, the encoder <b>304</b> generates a SPOO and proceeds to encode the simple property by generating the operands associated with the SPOO.
0058In many cases, the parser <b>302</b> will have sufficient information to identify simple properties with relative ease. In some cases, however, parser <b>302</b> may not be able to easily determine whether an element is a simple property. According to one embodiment, if the amount of resources required for the parser <b>302</b> to determine whether a node is a simple property exceeds a certain threshold, the parser <b>302</b> simply assumes that the node is not a simple property. Thus, instead of sending a compound event, parser <b>302</b> generates three events. In response to these events, encoder <b>304</b> will generate binary XML without using the SPOO opcode.
0059Because parser <b>302</b> sends simple property indications <b>310</b> to encoder <b>304</b>, a SPOO can be used to encode simple properties without excessive buffering by the encoder <b>304</b>. Further, excessive buffering by the parser <b>302</b> may be avoided by assuming that a node is not a simple property if the simple property determination would require too much overhead. Thus, the benefit of increased compression that results from using a SPOO may be obtained without introducing a significant amount of additional overhead into the parsing and encoding operations.
Character-Set Conversions
0060During the encoding process, tokens (which typically take the form of character strings that represent tags) are replaced with identifiers, as explained above. The component of the database server responsible for maintaining the mapping between tokens and their corresponding identifiers is referred to as a token manager.
0061In one embodiment, the token manager stores the token-to-identifier mapping information in database tables within the database. Typically, the tokens stored in database tables will be encoded in a particular character set, referred to herein as the “stored-token character set”. In one embodiment, the stored token character set is UTF8.
0062The character set of the text XML <b>204</b> that is encoded by encoder <b>304</b> is referred to herein as the “input character set”. The input character set may vary from document to document. When the input character set is not the same as the stored token character set, the parser <b>302</b> converts the tokens within the text XML from the input character set to the token character set.
0063Specifically, a token is converted from the input character set to the database character set to produce a token-character-set token. When the encoder <b>304</b> needs to encode a token, the token-character-set token is used by the token manager to look up the identifier for the token. The token manager returns the retrieved identifier to the encoder <b>304</b>, which replaces the token with the identifier to generate the binary XML representation of the token.
0064In addition to tokens, the text XML <b>204</b> will typically include other text, which is also in the input character set. Prior to being storing in the database as part of the binary XML stream, that other text needs to be converted from the input character set to the default character set for the database (the “database character set”). Frequently, the database character set is different from both the input character set and the token character set.
0065If parser <b>302</b> converts all of the text XML <b>204</b> into the same character set, then a second character set conversion must be performed on some of the text. Specifically, if all of the text XML <b>204</b> is converted to the database character set, then the tokens have to be converted again from the database character set to the token character set. On the other hand, if all of the text XML <b>204</b> is converted to the token character set, then the non-token text in the input stream must be converted again from the token-character-set to the database character set.
0066According to one embodiment, this second round of character set conversions is avoided by adapting the parser to directly convert the token text into one character set, while at the same time converting the non-token text into different character set. Specifically, the parser receives one input parameter value that indicates the token-character-set, and a separate input parameter value that indicates the database character set. During the parsing process, the parser identifies which text are tokens, and which text are not tokens. Text that represents tokens is converted directly to the token character set, and text that does not represent tokens is converted directly to the database character set. By having the parser convert text in this manner, neither the tokens nor non-token text need to be subjected to a subsequent round of character set conversion.
Self-Contained Mode
0067According to one embodiment, encoder <b>304</b> has a mode of operation referred to herein as “self-contained mode”. When operating in self-contained mode, all the generated token_id mappings are in-lined into the encoded document. Thus, the binary XML stream <b>212</b> generated by encoder <b>304</b> includes both the encoded binary XML, and the translation information necessary to translate the encoded binary XML back into text XML.
0068The self-contained encoded data can then be transferred across several tiers. At each tier the data can be efficiently decoded without needing any separate token-id mapping information. Thus, the need of costly parsing at each tier is avoided. In addition, network bandwidth usage is reduced because the encoded data is compressed.
0069When self-contained mode is used, the token-id mappings may vary from document to document, even for documents that belong to the same schema. Such variance is permissible because the documents are decoded using the token-id mappings that are contained in the documents, rather than using any schema-wide token-id mappings.
0070When the encoding is performed on the client-side, self-contained mode allows efficient encoding of data on the client side without any server round trips. Specifically, the encoder <b>304</b> can generate its own token-id mapping without regard to any translation information from the database <b>210</b>.
0071According to one embodiment, the token-id mapping for each self-contained binary-encoded XML document is stored at the beginning of the binary encoded XML document. In an alternate embodiment, the token-id mapping information is spread throughout the document. For example, in one embodiment, each token-id mapping is located, within the document, immediately before the first portion of the document that needs to be decoded using the token-id mapping.
0072Self-contained mode may be particularly useful in situations in which the encoder <b>304</b> is on a machine that does not currently have a good connection with the database server <b>206</b>. Encoder <b>304</b> may proceed with encoding a known-schema document without obtaining the translation information for the known-schema from the database server <b>206</b>. Once the connection has been established, the self-contained binary encoded document may be stored in the database <b>210</b> without further translation, even though the token-id mapping used by the document is inconsistent with the translation information <b>216</b> for that know schema. In an alternative embodiment, prior to storing a self-contained binary encoded document, the database server <b>206</b> remaps the binary encoded XML so that the XML is consistent with the stored translation information <b>216</b> for the corresponding XML schema. After the remapping, the binary XML data may be stored without the token-id mappings, as non-self-contained binary XML.
0073In one embodiment, binary XML repository <b>214</b> may contain, for the same schema, both self-contained binary XML documents, and binary XML documents that are not self-contained. In such an embodiment, the encoder <b>304</b> encodes each binary XML document with a flag to indicate whether the binary XML document is self-contained. Therefore, when decoding a binary XML document, the decoder first inspects the self-contained flag. If the self-contained flag indicates that the binary XML document is self-contained, then the decoder retrieves the token-id mappings from the document itself. On the other hand, if the self-contained flag indicates that the binary XML document is not self-contained, then the decoder retrieves the translation information <b>216</b> that is associated with the XML schema with which the XML document is associated.
Chunk-Based Provision of Client-Generated Token Mappings
0074As mentioned above, there are various circumstances in which it may be desirable to remap binary encoded XML data. In particular, remapping may be desirable in any circumstance in which binary XML was encoded based on mappings that differ from the mappings represented in the translation information <b>216</b> stored in the database <b>210</b>. For example, remapping may be performed to convert a self-contained binary XML document into a binary XML document that is not self-contained.
0075During a remap operation, binary XML that conforms to a first set of token-id mappings (the “initial mappings”) is modified to conform to a second set of token-id mappings (the “target mappings”). Thus, if a token X maps to an identifier Y in the initial mappings, and token X maps to an identifier Z in the target mappings, then identifier Y is replaced with identifier Z in the remap operation.
0076One way to perform remap operations is to provide to the process that is performing the remap operations (the “remap process”) the entire set of initial mappings. Once the remap process has the entire set of initial mappings, the remap process may analyzing the binary XML to detect any identifiers that belong to initial mappings. When any such identifier is found, the remap process replaces it with the corresponding identifier from the target mappings.
0077According to one embodiment, a technique referred to herein as “chunking” is used to improve the efficiency of remap operations. Chunking involves splitting the encoded data into chunks. In one embodiment, the chunks are of a fixed size. Each chunk maintains token-id mappings that (1) were generated for encoding data within that chunk, and (2) which have not occurred in any previous chunk.
0078For example, assume that the original XML text includes tokens A, B, C, B, and D, in that order. Assume further that the XML text is encoded into three chunks of binary XML (chunk<b>1</b>, chunk<b>2</b> and chunk<b>3</b>) based on the following initial mapping:
0079A->id<b>1</b>
0080B->id<b>2</b>
0081C->id<b>3</b>
0082D->id<b>4</b>
0083Finally, assume that, within the encoded binary XML, id<b>1</b> appears in chunk<b>1</b>, id<b>2</b> and id<b>3</b> appear in chunk<b>2</b>, and id<b>2</b> and id<b>4</b> appear in chunk<b>3</b>. This scenario is illustrated in <figref idref="DRAWINGS">FIG. 4</figref>.
0084Under these circumstances, the start-chunk opcode for chunk<b>1</b> will be followed by the A->id<b>1</b> mapping. The start-chunk opcode for chunk<b>2</b> will be followed by the B->id<b>2</b> and C->id<b>3</b> mappings. The start-chuck opcode for chunk<b>3</b> will be followed by the D->id<b>4</b> mapping. Even though chunk<b>3</b> includes id<b>2</b>, chunk<b>3</b> does not include the B->id<b>2</b> mapping because the B->id<b>2</b> mapping was included in a preceding chunk (chunk<b>2</b>). Consequently, the process performing the re-mapping will already have knowledge of the B->id<b>2</b> mapping by the time that chunk<b>3</b> is being remapped.
0085By providing the initial mapping function on a chunk-by-chunk basis, as illustrated in <figref idref="DRAWINGS">FIG. 4</figref>, the efficiency of remap operations is significantly increased. Specifically, when the remap process is remapping chunk<b>1</b>, the remap process need only look for id<b>1</b> within chunk <b>1</b>, since A->id<b>1</b> is the only mapping that the remap process is aware of. Looking for id<b>1</b> may involve, for example, doing hash table lookups in a hash table that has an entry for id<b>1</b>.
0086When remapping chunk <b>2</b>, the remap process is aware of A->id<b>1</b>, B->id<b>2</b> and C->id<b>3</b>. Therefore, the remap process only needs to search for id<b>1</b>, id<b>2</b> and id<b>3</b> within chunk <b>2</b>. In an embodiment that uses a hash table, the remap process may add to the hash table (which already contains an entry for id<b>1</b>) entries for id<b>2</b> and id<b>3</b>. Once populated with entries for id<b>2</b> and id<b>3</b>, the remap process may used the hash table to process chunk<b>2</b>.
0087Finally, when processing chunk<b>3</b>, the remap process becomes aware of D->id<b>4</b>. Therefore, the remap process adds a hash table entry for id<b>4</b> to the hash table, and uses the hash table when processing chunk<b>3</b> to search for id<b>1</b>, id<b>2</b>, id<b>3</b> and id<b>4</b>.
0088As is illustrated by this example, chunking increases efficiency of remap operations by reducing the number of identifiers for which the remap process is searching. Specifically, when processing chunk<b>1</b>, the remap process did not need to look for id<b>2</b>, id<b>3</b> and id<b>4</b>. Similarly, when processing chunk<b>2</b>, the remap process did not need to look for id<b>4</b>. Only when the last chunk, chunk<b>3</b>, was being processed, did the remap process have to search for all of the identifiers from the initial mapping. In an implementation that uses a hash table to locate identifiers that need to be remapped, the hash table is gradually populated as chunks are processed, thereby deferring the resource usage of a fully populated hash table.
The Remap Flag
0089In one embodiment, the chunks are generated by an encoder <b>304</b> that uses server-provided mapping information to encode some tokens, and client-generated mapping information to encode other tokens. During remap operations, only the identifiers that were generated based on client-generating mappings need to be remapped. Identifiers that were generated based on server-provided mappings are already consistent with the translation information <b>216</b> contained in the database <b>210</b>.
0090According to one embodiment, when generating a chunk, the encoder <b>304</b> keeps track of whether client-generated mappings were used to encode anything represented by the chunk. If any client-generated mappings were used to encode anything within a chunk, then encoder <b>304</b> sets a “remap flag” within the chunk to indicate that something within the chunk needs to be remapped. If no client-generated mappings were used to encode a chunk, then encoder <b>304</b> sets the remap flag to indicate that the chunk does not to be remapped.
0091When the remap process receives a chunk, the remap process inspects the remap flag. If the remap flag indicates that chunk does not need to be remapped, then the remap process does not analyze the chunk. Rather, the encoded binary XML contained within the chunk is stored into binary XML repository <b>214</b> without any identifier conversions. If the remap flag indicates that the chunk needs to be remapped, then the remap process processes the chunk as described above.
Hardware Overview
0092<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram that illustrates a computer system <b>500</b> upon which an embodiment of the invention may be implemented. Computer system <b>500</b> includes a bus <b>502</b> or other communication mechanism for communicating information, and a processor <b>504</b> coupled with bus <b>502</b> for processing information. Computer system <b>500</b> also includes a main memory <b>506</b>, such as a random access memory (RAM) or other dynamic storage device, coupled to bus <b>502</b> for storing information and instructions to be executed by processor <b>504</b>. Main memory <b>506</b> also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor <b>504</b>. Computer system <b>500</b> further includes a read only memory (ROM) <b>508</b> or other static storage device coupled to bus <b>502</b> for storing static information and instructions for processor <b>504</b>. A storage device <b>510</b>, such as a magnetic disk or optical disk, is provided and coupled to bus <b>502</b> for storing information and instructions.
0093Computer system <b>500</b> may be coupled via bus <b>502</b> to a display <b>512</b>, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device <b>514</b>, including alphanumeric and other keys, is coupled to bus <b>502</b> for communicating information and command selections to processor <b>504</b>. Another type of user input device is cursor control <b>516</b>, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor <b>504</b> and for controlling cursor movement on display <b>512</b>. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
0094The invention is related to the use of computer system <b>500</b> for implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed by computer system <b>500</b> in response to processor <b>504</b> executing one or more sequences of one or more instructions contained in main memory <b>506</b>. Such instructions may be read into main memory <b>506</b> from another machine-readable medium, such as storage device <b>510</b>. Execution of the sequences of instructions contained in main memory <b>506</b> causes processor <b>504</b> to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
0095The term “machine-readable medium” as used herein refers to any medium that participates in providing data that causes a machine to operation in a specific fashion. In an embodiment implemented using computer system <b>500</b>, various machine-readable media are involved, for example, in providing instructions to processor <b>504</b> for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device <b>510</b>. Volatile media includes dynamic memory, such as main memory <b>506</b>. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus <b>502</b>. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications. All such media must be tangible to enable the instructions carried by the media to be detected by a physical mechanism that reads the instructions into a machine.
0096Common forms of machine-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
0097Various forms of machine-readable media may be involved in carrying one or more sequences of one or more instructions to processor <b>504</b> for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system <b>500</b> can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus <b>502</b>. Bus <b>502</b> carries the data to main memory <b>506</b>, from which processor <b>504</b> retrieves and executes the instructions. The instructions received by main memory <b>506</b> may optionally be stored on storage device <b>510</b> either before or after execution by processor <b>504</b>.
0098Computer system <b>500</b> also includes a communication interface <b>518</b> coupled to bus <b>502</b>. Communication interface <b>518</b> provides a two-way data communication coupling to a network link <b>520</b> that is connected to a local network <b>522</b>. For example, communication interface <b>518</b> may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface <b>518</b> may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface <b>518</b> sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
0099Network link <b>520</b> typically provides data communication through one or more networks to other data devices. For example, network link <b>520</b> may provide a connection through local network <b>522</b> to a host computer <b>524</b> or to data equipment operated by an Internet Service Provider (ISP) <b>526</b>. ISP <b>526</b> in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” <b>528</b>. Local network <b>522</b> and Internet <b>528</b> both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link <b>520</b> and through communication interface <b>518</b>, which carry the digital data to and from computer system <b>500</b>, are exemplary forms of carrier waves transporting the information.
0100Computer system <b>500</b> can send messages and receive data, including program code, through the network(s), network link <b>520</b> and communication interface <b>518</b>. In the Internet example, a server <b>530</b> might transmit a requested code for an application program through Internet <b>528</b>, ISP <b>526</b>, local network <b>522</b> and communication interface <b>518</b>.
0101The received code may be executed by processor <b>504</b> as it is received, and/or stored in storage device <b>510</b>, or other non-volatile storage for later execution. In this manner, computer system <b>500</b> may obtain application code in the form of a carrier wave.
0102In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention, and is intended by the applicants to be the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
Contents4
6 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US8533172B2 | Cited by | United States of America | Search report |
| US2009138529A1 | Cited by | United States of America | Pre-grant |
| US8341129B2 | Cited by | United States of America | Search report |
| US2008098019A1 | Cited by | United States of America | Pre-grant |
| US8812523B2 | Cited by | United States of America | Applicant |
| US2011154466A1 | Cited by | United States of America | Pre-grant |
| US2009037368A1 | Cited by | United States of America | Pre-grant |
| US2007208752A1 | Cited by | United States of America | Pre-grant |
| US8429196B2 | Cited by | United States of America | Search report |
| US8291310B2 | Cited by | United States of America | Applicant |
| US2006184551A1 | Cited by | United States of America | Pre-grant |
| US2008098020A1 | Cited by | United States of America | Pre-grant |
| US8739262B2 | Cited by | United States of America | Applicant |
| US2007150432A1 | Cited by | United States of America | Pre-grant |
| US2009125693A1 | Cited by | United States of America | Pre-grant |
| US2007271305A1 | Cited by | United States of America | Pre-grant |
| US8595812B2 | Cited by | United States of America | Search report |
| US2009150412A1 | Cited by | United States of America | Pre-grant |
| US8185565B2 | Cited by | United States of America | Search report |
| US8010889B2 | Cited by | United States of America | Applicant |
| US9460064B2 | Cited by | United States of America | Applicant |
| US2009125495A1 | Cited by | United States of America | Pre-grant |
| US2011154467A1 | Cited by | United States of America | Pre-grant |
| US9842090B2 | Cited by | United States of America | Applicant |
| US2009271695A1 | Cited by | United States of America | Pre-grant |
| US7933933B2 | Cited by | United States of America | Search report |
| US10756759B2 | Cited by | United States of America | Applicant |
| US8805672B2 | Cited by | United States of America | Applicant |
| US9684639B2 | Cited by | United States of America | Applicant |
| US8346737B2 | Cited by | United States of America | Applicant |
| US9953103B2 | Cited by | United States of America | Applicant |
| US2010083101A1 | Cited by | United States of America | Pre-grant |
| US2009063949A1 | Cited by | United States of America | Pre-grant |
| US10262128B2 | Cited by | United States of America | Applicant |
| US2006212467A1 | Cited by | United States of America | Pre-grant |
| US7627566B2 | Cited by | United States of America | Applicant |
| US7739251B2 | Cited by | United States of America | Applicant |
| US2009307239A1 | Cited by | United States of America | Pre-grant |
| US2009132564A1 | Cited by | United States of America | Pre-grant |
| US2001049675A1 | Cites | United States of America | Pre-grant |
| US2002050054A1 | Cites | United States of America | Pre-grant |
| US2002152267A1 | Cites | United States of America | Pre-grant |
| US2002188613A1 | Cites | United States of America | Pre-grant |
| US2003093626A1 | Cites | United States of America | Pre-grant |
| US2003131051A1 | Cites | United States of America | Pre-grant |
| US2003140308A1 | Cites | United States of America | Pre-grant |
| US2003177341A1 | Cites | United States of America | Pre-grant |
| US2003212664A1 | Cites | United States of America | Pre-grant |
| US2003236903A1 | Cites | United States of America | Pre-grant |
| US2004010752A1 | Cites | United States of America | Pre-grant |
| US2004044659A1 | Cites | United States of America | Pre-grant |
| US2004132465A1 | Cites | United States of America | Pre-grant |
| US2004143791A1 | Cites | United States of America | Pre-grant |
| US2004167864A1 | Cites | United States of America | Pre-grant |
| US2004205551A1 | Cites | United States of America | Pre-grant |
| US2004260691A1 | Cites | United States of America | Pre-grant |
| US2004261019A1 | Cites | United States of America | Pre-grant |
| US2005033733A1 | Cites | United States of America | Pre-grant |
| US2005038688A1 | Cites | United States of America | Pre-grant |
| US2005050016A1 | Cites | United States of America | Pre-grant |
| US2005091188A1 | Cites | United States of America | Pre-grant |
| US2005091588A1 | Cites | United States of America | Pre-grant |
| US2005102256A1 | Cites | United States of America | Pre-grant |
| US2005120031A1 | Cites | United States of America | Pre-grant |
| US2005203957A1 | Cites | United States of America | Pre-grant |
| US2005228792A1 | Cites | United States of America | Pre-grant |
| US2005229158A1 | Cites | United States of America | Pre-grant |
| US2005257201A1 | Cites | United States of America | Pre-grant |
| US2005278289A1 | Cites | United States of America | Pre-grant |
| US2005278616A1 | Cites | United States of America | Pre-grant |
| US2005278919A1 | Cites | United States of America | Pre-grant |
| US2006005122A1 | Cites | United States of America | Pre-grant |
| US2006021246A1 | Cites | United States of America | Pre-grant |
| US2006047717A1 | Cites | United States of America | Pre-grant |
| US2006200439A1 | Cites | United States of America | Pre-grant |
| US2006212467A1 | Cites | United States of America | Pre-grant |
| US2006277179A1 | Cites | United States of America | Pre-grant |
| US2007043751A1 | Cites | United States of America | Pre-grant |
| US2007050704A1 | Cites | United States of America | Pre-grant |
| US2007113221A1 | Cites | United States of America | Pre-grant |
| US2007208752A1 | Cites | United States of America | Pre-grant |
| US2007271305A1 | Cites | United States of America | Pre-grant |
| US2008082484A1 | Cites | United States of America | Pre-grant |
| US2008091623A1 | Cites | United States of America | Pre-grant |
| US2008098019A1 | Cites | United States of America | Pre-grant |
| US2008098020A1 | Cites | United States of America | Pre-grant |
| US2009059165A1 | Cites | United States of America | Pre-grant |
| US2009112890A1 | Cites | United States of America | Pre-grant |
| US2009150412A1 | Cites | United States of America | Pre-grant |
| US2009307239A1 | Cites | United States of America | Pre-grant |
| US5643633A | Cites | United States of America | Pre-grant |
| US5870590A | Cites | United States of America | Pre-grant |
| US6018747A | Cites | United States of America | Pre-grant |
| US6330573B1 | Cites | United States of America | Pre-grant |
| US6414610B1 | Cites | United States of America | Pre-grant |
| US6427123B1 | Cites | United States of America | Pre-grant |
| US6519597B1 | Cites | United States of America | Pre-grant |
| US6523062B1 | Cites | United States of America | Pre-grant |
| US6598055B1 | Cites | United States of America | Pre-grant |
| US6635088B1 | Cites | United States of America | Pre-grant |
6 members in 1 office
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 85323606 | United States of America | P | |
| 74356307 | United States of America | A | |
| 60853236 | – | – | – |
| US20060853236P | – | – | – |
| US20070743563 | – | – | – |
Members6
| Document | Office | Kind | |
|---|---|---|---|
| US2008098001A1 | United States of America | A1 | |
| US2008098019A1 | United States of America | A1 | |
| US2008098020A1 | United States of America | A1 | |
| US7627566B2 | United States of America | B2 | |
| US7739251B2 | United States of America | B2 | |
| US8010889B2 | United States of America | B2 |
105 transactions on the USPTO file
Allowed after 1 non-final rejection, 1 final rejection and 1 RCE.
- Non-final rejections
- 1
- Final rejections
- 1
- RCEs
- 1
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Post Issue Communication - Certificate of CorrectionN423 | N423 | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Mailing Corrected Notice of AllowabilityMCNOA | MCNOA | |
| Corrected Notice of AllowabilityCNOA | CNOA | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Mail Miscellaneous Communication to ApplicantMM327 | MM327 | |
| Miscellaneous Communication to Applicant - No Action CountM327 | M327 | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Examiner Interview Summary Record (PTOL - 413)EXIN | EXIN | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Examiner Interview Summary Record (PTOL - 413)EXIN | EXIN | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response to Election / Restriction FiledELC. | ELC. | |
| Mail Restriction RequirementMCTRS | MCTRS | |
| Restriction/Election RequirementCTRS | CTRS | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Transfer Inquiry to GAUTI1050 | TI1050 | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| IFW TSS Processing by Tech Center CompleteTSSCOMP | TSSCOMP | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS |
7 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| Maintenance fee paymentMAFP | MAFP | |
| Fee paymentFPAY | FPAY | |
| Certificate of correctionCC | CC | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| AssignmentAS | AS | |
| AssignmentAS | AS |
Numbers
- Publication
- 20080098001
- Publication, DOCDB
- 2008098001
- Publication, EPODOC
- US2008098001
- Application
- 11743563
- Application, DOCDB
- 74356307
- Application, EPODOC
- US20070743563
Titles
- English
- TECHNIQUES FOR EFFICIENT LOADING OF BINARY XML DATA
Classification
- CPC, 3
- H03M7/30
- G06F16/258
- G06F16/80
- IPC, 1
- G06F17 30
- USPC, 4
- 001001000
- 707999010
- 707E17006
- 707E17122