The present invention relates to a method and system for processing and uploading files using a print driver architecture, and in particular to a print driver architecture that allows a user to determine a location on a destination computer system and identify the files to be processed and uploaded, whereby the processing and uploading are spooled and performed automatically without further interaction with the user.
In today's computerized world, many different types of electronic documents are being created and stored. With increasing frequency, there is a need to collect various electronic documents together in a centralized storage location. For instance, an enterprise with distributed offices or work sites may want to collect all electronic documents on a single server, so that all of the distributed offices can share the documents. As another example, two or more separate enterprises may work together on a joint undertaking and want to have a single server to store and manage the electronic documents needed for the task.
Typically, the centralized storage location used to store the various electronic documents in a document collection is a server or set of servers organized in a manner to facilitate retrieval and management of the electronic documents. For instance, the centralized storage server may use a standard tree structure similar to that used in most file systems to organize the documents in a document collection. Typically, the electronic documents are transmitted over a network, such as the Internet, to the centralized storage server, and stored at an appropriate location, such as a specified node within a tree structure.
One example of a document collection created through collaboration is an electronic Request for Quotations (RFQ) used in an online auction. An RFQ is typically a complete set of documentation that communicates the intent of the party sponsoring the auction to buy or sell goods and services. An RFQ provides information to prospective bidders before the auctioning event that describes the individual items or services up for bid, and other specifications that may affect bidding.
With the advent of computerized systems and the Internet, it is now possible, and desirable, to publish an RFQ electronically. An electronic RFQ is a collection of electronic documents that are presented to a user through a software interface. For example, one method of publishing an electronic RFQ is to gather electronic documents on a central server, store the electronic documents at appropriate locations within a tree structure on the server, and provide an application to allow an end user to find and display desired documents.
A typical RFQ will contain many different types of information, such as engineering specifications, quality specifications, delivery requirements and contractual information. Much of the information may originate with the auction sponsor, as it is the auction sponsor who defines the parts or services that are being bought or sold. However, some of the information needed for an RFQ may be supplied by an auction coordinator or other third party.
Frequently, documents containing much of the information needed for an RFQ will have already been created before an RFQ is even needed. For example, large manufacturing enterprises typically have drawing vaults for storing engineering drawings. Therefore, when the manufacturer desires to use an online auction to procure parts, it would be beneficial to be able to use the part drawings already in existence.
These existing documents may be stored as many different types of electronic files. For example, text documents may be created and stored in Microsoft Word, Corel WordPerfect or ASCII text, to name just a few. Electronic images may be stored in JPEG format, for example. Compound documents containing both text and images may be created in Adobe PDF, for example. In addition, engineering drawings may exist as paper drawings, image files created by scanning paper drawings, or as Computer-Aided Design (CAD) files.
In addition to existing documents, other electronic documents may be created for the RFQ for an online auction. For instance, an auction coordinator may create a text document outlining the auction's bidding rules and schedule of events. This document may be created in Microsoft Word, for example.
The electronic documents in a document collection may come from several sources. As previously discussed, documents in an electronic RFQ may come from different parties, such as an auction sponsor and an auction coordinator. In addition, documents from a single party may originate at different locations. For instance, a manufacturer sponsoring an auction may have multiple drawing vaults, each containing documents of different types.
Collecting documents in their native formats causes many problems. Many electronic files are very large, and uploading the electronic files to the centralized storage location is very time-consuming, and the amount of storage space required is expensive. Since an electronic RFQ may contain thousands of documents, this is a significant problem. In addition, if the electronic files are stored in their native format, many different types of applications are needed to view the electronic documents. Many different versions of the same application may even be needed, especially if files are coming from multiple sources, as each source may use different versions of an application.
Co-pending U.S. application Ser. No. 09/782,620, which is hereby incorporated by reference, describes a method and system developed by the current assignee to take numerous types of electronic documents and convert all documents into a common compressed file type, whereby a single viewing application can be used to view all of the documents that have been converted to the common compressed file type in the document collection.
However, it is still necessary that the auction coordinator, or other party creating the electronic RFQ, acquire all of the files in the common compressed format, or convert the files to the common compressed format after receiving them.
If the auction coordinator were to convert the files after acquiring them, it would require a large amount of electronic storage space and computer processing capability. Just one RFQ may contain thousands of documents, and the auction coordinator may be actively involved in setting up and managing hundreds of auctions at once. To require the auction coordinator to have this type of storage space and processor capabilities would raise the cost of managing the auctions significantly.
However, requiring the auction sponsor to convert all the RFQ files to the common compressed format before sending them to the auction coordinator would unduly burden the sponsor as the auction sponsor would have to identify the documents, convert the documents and send the converted documents to the auction coordinator using separate applications for each step. This type of multi-step process is prone to error and would discourage the auction sponsors from using online auctions due to this added burden.
This problem of acquiring and processing electronic files from multiple sources exists outside the area of generating and publishing electronic RFQs. There are many different types of distributed systems that require files to be identified and processed before being transmitted to a server or other computer system. The present invention is intended to cover any such document collection system, and is not limited to electronic RFQs.
Thus, what is needed is a method and system to manage multi-source document collection and/or collaboration. What is needed is a method that allows a user to identify files and a destination location in a single application interface, whereby the system will perform any necessary processing and transmit the processed files to the proper location through the single interface.
In accordance with one form of the present invention, there is provided a method and system of identifying files for processing and transmission that processes and transmits the files in a single application. The method for processing and transmitting and electronic file to a document management system on a remote computer system also includes selecting the electronic file; initiating a print driver; viewing the document management system on the remote computer system through the print driver; and providing metadata; wherein the print driver queues the files with a spooler for processing; and the spooler transmits the processed file and the metadata to the document management system on the remote computer system.
A method and system for processing and transmitting an electronic file is also disclosed. The method includes initiating a processing print driver; logging onto a destination system; and selecting a destination location on the destination system; whereby the processing print driver queues the electronic file and selected destination location with a processing spooler, and the processing spooler processes the electronic file and transmits the processed electronic file to the destination system upon completion of the processing, whereby the destination system stores the processed file at the destination location.
A system for processing and transmitting an electronic file is also disclosed. The system includes a processing print driver; a processing spooler; and a communication component; whereby the processing print driver converts the electronic file from a first type to at least one raster image, the processing spooler converts the at least one raster image to a second type of electronic file; and the communication component transmits the converted electronic file to a destination system.
Accordingly, the present invention provides solutions to the shortcomings of prior file acquisition and processing techniques. Those of ordinary skill in the art will readily appreciate, therefore, that those and other details, features, and advantages will become apparent in the following detailed description of the preferred embodiments.
The accompanying drawings, wherein like references numerals are employed to designate like parts or steps, are included to provide a further understanding of the invention, are incorporated in and constitute a part of this specification, and illustrate embodiments of the invention that together with the description serve to explain the principles of the invention.
In the Figures:
Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. It is to be understood that the Figures and the description of the present invention included herein illustrate and describe elements that are of particular relevance to the present invention, while eliminating, for purposes of clarity, other elements that may be found in typical auction systems and computer networks.
It is worthy to note that any reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
The present invention is directed to a method for performing file conversion or other processing using a print driver architecture. The invention is described using the file conversion process described in co-pending U.S. application Ser. No. 09/782,620 as an example. The disclosed method compresses a file such that all critical information is preserved in the conversion process and a single viewing application can be used to view the compressed file no matter what type of file the compressed file was originally. However, other types of file processing besides converting files into the disclosed format may be performed by the method and system of the present invention, and are intended to come within the scope of the present invention.
The method and system of co-pending U.S. application Ser. No. 09/782,620 will be briefly described so that it can be used by way of example herein. In brief, this method extracts important information from documents stored in files of any type of native format, and converts the documents into raster images, compresses the raster images and then stores the images with the extracted information in an “RFQ compressed format” file. Although the term “RFQ compressed format” is used herein, it will be obvious to those skilled in the art that the disclosed compressed file format could be used in many applications other than the publication of electronic RFQs.
In the disclosed method, the electronic files (which may be of differing file formats) are first optionally converted to an intermediate file format, such as PDF (Portable Document Format from Adobe Acrobat). In one embodiment, hyperlink information may be extracted from documents containing such information and saved. In another embodiment, symbol information in CAD files may be extracted and saved. All documents are converted into a common raster image format, such as TIFF (Tag Image File Format). Other formats may be used. Once the documents have been converted into the common raster format, the raster images are compressed preferably using a wavelet compression scheme. This creates a highly compressed file format suitable for transmitting over low bandwidth connections. Any information that may have been extracted may be re-inserted into the compressed file, and a “RFQ compressed format” file is created.
Both text-based documents and engineering drawings are converted to one common format. By compressing all of the files into a common format, only one viewing application is needed, and the viewing time is minimized. No matter what file type a document in an RFQ started as, when it is delivered as part of the RFQ generated by the disclosed system, the same viewing application can be used to decode and view the document. The RFQ compressed format therefore provides for the consolidation of all data across a common format, while preserving valuable information from the RFQ input files.
It is therefore advantageous to “publish” an electronic RFQ such that all of the files that comprise the RFQ are in the RFQ compressed format. By using a single file format, a reader of the RFQ need only have one viewing application to view every document in the RFQ. However, to publish the RFQ using a single file format, it is still necessary that the auction coordinator, or other party creating and publishing the electronic RFQ, acquire all of the files in the RFQ compressed format, or convert files to the RFQ compressed format after receiving them.
For an auction coordinator to take responsibility for converting thousands of files to the RFQ compressed format would require that the auction coordinator maintain a complete set of translators or copies of all applications used by any auction sponsors. As an auction coordinator may coordinate auctions for thousands of auction sponsors, and each auction sponsor may use many different applications, and versions of applications, requiring the auction coordinator to perform the conversion is not practical. In addition, the RFQ compressed format preferably uses a wavelet-based compression scheme, which is a very CPU-intensive method of compression. If an auction coordinator were to take responsibility for converting all files from auction sponsors into the RFQ compressed format, it would be necessary for the auction coordinator to have much greater processing capability than is currently required. In addition, as an auction coordinator may be managing auctions and generating electronic RFQs for many auctions sponsors simultaneously, if many auction sponsors uploaded files needing conversion at once, a large conversion backlog may result. Auction sponsors do not want to wait hours or even days for their files to be converted and the electronic RFQs to be generated.
Alternatively, the auction sponsors could be required to submit the needed files to a coordinator in a standard intermediate format. For example, auction sponsors could be required to submit all text-based documents as PDF files. However, this places a large burden on auction sponsors while still requiring an auction coordinator to perform additional processing on the submitted files to convert them into the final RFQ compressed format.
The most efficient method of converting the various electronic files to the RFQ compressed format is to provide a tool to the auction sponsors that will convert the various electronic files into the RFQ compressed format. However, as each auction sponsor uses different applications and operates in different environments, the tool should be able to interface with many different systems and applications without requiring a custom interface for each environment. The present invention provides such a tool.
The present invention uses a print driver architecture to provide for easy installation, application integration and end-user use. The driver is preferably a Microsoft Windows compatible print driver that integrates with all compatible Windows applications and can be installed on any system running in a Microsoft Windows environment. This mitigates the requirement of developing interfaces to many different applications. A Windows compatible print driver can be used with any Windows application that supports the standard Windows printing interface. Once the inventive system has been installed, a user using any Windows application can simply select the print driver of the present invention within the application's printing interface to convert files. The same print driver interface is presented to the user no matter what application they are currently using. Another advantage of using a print driver architecture is that the driver can integrate with a spooler to facilitate offloading CPU-intensive processing, as is described below. Using the inventive system and method, a user uses a single interface to select, process and transmit a file to its proper destination.
Once a file has been opened in a Windows application, the user can select to “print” the opened document using the print driver of the present invention. For example, the user can open a Microsoft Word file in the Microsoft Word application, or a CAD file in a Windows CAD application, and select to print the document.
Using the present example of converting files to the RFQ compressed format, the print driver may first extract information from the document and save the extracted information for later re-insertion into the RFQ compressed file, and then convert the pages of the opened document to raster images. In one embodiment, each page is converted to a separate raster image and stored on the client computer, using, for example, the method described in co-pending U.S. application Ser. No. 09/782,620. In this embodiment, the separate raster images may be linked through use of an index file. Alternatively, all of the converted images and the associated extracted information may be stored in a single bundled file.
Once all of the pages of a document have been converted to raster images, the print driver queues the raster images to the processing spooler of the present invention and returns control of the client computer to the user. The processing spooler functions much like a Windows print spooler, and performs processing in the background so that the user may continue with other tasks on the computer. However, instead of generating a print image and the necessary print commands and passing the results to a printing device, the processing spooler is configured to perform the task of wavelet compression and creating RFQ compressed format files. The spooler compresses the raster images, re-inserts any needed information and creates the RFQ compressed file. In an alternative embodiment, the print driver may pass the files to the processing spooler in their native format, and the processing spooler will generate the raster images as well as convert the raster images to RFQ compressed format.
As with most spoolers, this process is performed in the background, so that users can continue with other tasks. The processing spooler functions much like a standard Windows print spooler. As with most spoolers, jobs are listed and users may view the queue and status of the jobs. The spooler preferably maintains the current jobs between system restarts.
Although the invention is described in terms of converting documents to the RFQ compressed format, it will be obvious to those skilled in the art that the present architecture could be used to perform many different types of file conversion or processing, and it is intended that other types of processing come within the scope of the present invention. For example, the print driver architecture of the present invention could be used to extract certain graphical or textual information from a large number of PDF files. In this example, the user would likewise select to print to the print driver of the present invention, and the print driver would queue the extraction process to the spooler.
In the electronic RFQ example, by using the print driver of the present invention, the auction sponsor can easily convert any desired file to the RFQ compressed format. However, the converted files still need to be sent to the computer system collecting all of the converted files for electronic publication of the electronic RFQ. Therefore, in one embodiment of the present invention, the print driver architecture converts files to the RFQ compressed format and then automatically transmits the converted files to the appropriate location on a destination computer system. The present invention provides for a single interface for converting and transmitting the files.
The print driver of the present invention interfaces with a destination document management system residing on a remote computer system from within a Windows application. In the electronic RFQ example, the document management system is typically a file system on a server operated by an auction coordinator. The user is not required to use one application to identify RFQ files, and a separate application to convert the identified files to the RFQ compressed format, and yet another to identify a location on the document management system and upload the RFQ compressed files. The present invention provides a method for performing all of these tasks through a single integrated user interface.
The overall process that occurs in this embodiment of the method and system of the present invention is shown in
The destination computer system, is typically a server, however, the destination computer system, could be a “peer” computer in a peer-to-peer environment. The print driver accesses the document management system on the destination computer system at step 415, and presents a view of the document management system to the user. The user may then use this view to select the appropriate location within the document management system for the document being processed by the print driver. For example, the user may be presented with a navigation interface similar to Windows Explorer that allows the user to navigate to the location within the destination file structure (such as an RFQ file structure) that the current document should be placed after conversion. An example of a view of a document management system is shown in
The basic components of the software operating on the user's computer in this embodiment of the present invention are shown in
In this embodiment, the print driver has additional interfacing with the user. In the electronic RFQ example, the print driver will need to access the destination computer system and acquire a current view of the RFQ file structure to present to the user, so that the user can select an appropriate node within the RFQ file structure as a destination location for the document being processed. The print driver interface in this embodiment may look much like the previous embodiment shown in
As shown in
As shown in
The interface preferably supports user placement of new documents within the tree structure. For example, the user may select to create a new “node” or “leaf” within the tree for placing the current or selected document after conversion. Users may also update documents by selecting an existing document within the tree structure for updating or replacement.
The interface may provide for entering additional information about the current document, as shown in
A more detailed view of the components of this embodiment of the inventive system as used in the RFQ example is shown in
Once the conversion is completed, the processing spooler component uses the associated metadata 352 to upload the resulting RFQ compressed format files to the document management system on the destination computer system. The processing spooler component preferably uses Extensible Markup Language (XML) to pass instructions as to user, file information and location. XML is a common interface format used to share formatting information, commands and data. Of course, other formats may be used, and are intended to come within the scope of the present invention.
The Web connection and communications component 270 in
The Web connection and communication component preferably performs document management and version control on the document management system on the destination computer system. It may do this by managing checkin/checkout of nodes in the document management system in order to lock down a node that is to receive a new or updated document. In one embodiment, the Web-based Distributed Authoring and Versioning (WebDAV) protocol, which is a set of extensions to the HTTP protocol that allows users to collaboratively edit and manage files on remote web servers, may be used to perform this function. WebDAV allows for versioning, configuration management and concurrency control through locking. Shared write locks prevent the problem of two or more collaborators writing to the same resource without first merging changes. WebDAV versioning support operations such as checkout, check-in, and retrieval of the history list. Other methods of performing document version control may be used.
In order to integrate with the print driver Web interfaces 340 and 342, the destination computer system may provide an Active Server Page (ASP) connection 360 to support the special login and communication required by the inventive system. The computer system authenticates the user, builds and transmits an XML representation of the document management system and receives XML instructions and the files processed by the inventive print driver and spooler. In the RFQ example, the document management system is the auction sponsor's RFQ file structure, and the processed files are the converted RFQ compressed format files that will be used in the auction sponsor's electronic RFQ. Once the processed files and associated metadata are received, the computer system updates the user's document management system and unlocks the node upon successful completion of the transaction, if a locking system is being used.
The user selects this “print” option in step 508, and the print driver interface is shown to the user at step 510. As previously discussed, the user may use an alternative method to initiate the print driver, such as selecting the “File/Send To” menu option from a customized Windows Explorer. In the print driver interface, the user may connect to the destination computer system by logging into the destination computer system at step 515. The user is then presented with a navigation interface that allows the user to navigate to the location within the auction sponsor's RFQ file structure that the current document should be placed after conversion. In one embodiment, a standard tree browser is used as the interface through which the user selects the location where the current document will be added or replace the current document. Once the user selects the appropriate location in the RFQ file structure on the destination computer system at step 520 and enters any related metadata about the document, the Windows application through GDI creates a bitmap for each page of the current document and the print driver converts the bitmaps to raster images, using a raster format such as TIFF, at step 525. These TIFF images are then passed to the processing spooler along with the login, security and metadata information at step 530. The processing spooler performs the wavelet compression (or other processing) at step 540. In one embodiment, a RFQ compressed file is created for each page of the document. In addition, an index file tying the pages together in a document may be created. Alternatively, a single bundled file may be created that contains all of the information. The spooler then sends the resulting RFQ compressed format files and associated metadata to the destination computer system at 550.
The destination computer system processes the uploaded information and stores it in the appropriate location within the destination file structure. As discussed above, a configuration manager, such as WebDAV, may be used to lock the appropriate location within the document management system when the user initially selects the destination location at step 520, and once the files are inserted at step 560, the location is unlocked.
In the above-described embodiment, the processing is performed “online.”That is, the entire process takes place in one session after the user logs in at step 515. In this embodiment, some form of session management functionality is used to prevent and/or account for dropped connections, timeouts and other networking problems.
In an alternative embodiment, the processing is performed “offline”. In this embodiment, the files are converted or processed in the same manner, but instead of being directly uploaded after processing, they are stored on the user's local system with the associated metadata until the user next connects with the destination computer system. In the offline embodiment, the print driver saves a view of the most recently downloaded document management system information. This “view” can be stored in XML format, for example. This locally saved view of the document management system is used to perform the local processing. Once the local computer next connects to the destination server, the processed files and their associated metadata are automatically transmitted. Alternatively, the user may schedule a time to automatically connect and transmit the files.
In the offline embodiment, the appropriate nodes in the document management system on the destination computer system may be locked when the file structure is downloaded so that another user will not overwrite it. In this embodiment, when the user reconnects and uploads the processed files, the destination computer system updates the document management system and unlocks the node upon successful completion of the transaction. Alternative methods of managing the structure of the document management system are known to those skilled in the art, and are intended to come within the scope of the present invention.
While the invention has been described in detail and with reference to specific embodiments thereof, it will be apparent to one skilled in the art that various changes and modifications can be made therein without departing from the spirit and scope thereof. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.
This application is a continuation-in-part of co-pending U.S. application Ser. No. 09/782,620, entitled “Method And Apparatus For Extracting Information From RFQ Documents And Compressing RFQ Files Into A Common RFQ File Type”, filed Feb. 13, 2001, previously assigned to the assignee of the present application, FreeMarkets, Inc. The entirety of the earlier filed co-pending patent application is hereby expressly incorporated herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
3581072 | Nymeyer | May 1971 | A |
3863060 | Rode et al. | Jan 1975 | A |
4597045 | Kiuchi | Jun 1986 | A |
4674044 | Kalmus et al. | Jun 1987 | A |
4789928 | Fujisaki | Dec 1988 | A |
4799156 | Shavit et al. | Jan 1989 | A |
4845625 | Stannard | Jul 1989 | A |
4992940 | Dworkin | Feb 1991 | A |
5136501 | Silverman et al. | Aug 1992 | A |
5193056 | Boes | Mar 1993 | A |
5243515 | Lee | Sep 1993 | A |
5297032 | Trojan et al. | Mar 1994 | A |
5375055 | Togher et al. | Dec 1994 | A |
5394324 | Clearwater | Feb 1995 | A |
5402336 | Spiegelhoff et al. | Mar 1995 | A |
5606602 | Johnson et al. | Feb 1997 | A |
5629982 | Micali | May 1997 | A |
5640569 | Miller et al. | Jun 1997 | A |
5664115 | Fraser | Sep 1997 | A |
5684963 | Clement | Nov 1997 | A |
5689652 | Lupien et al. | Nov 1997 | A |
5715402 | Popolo | Feb 1998 | A |
5727165 | Ordish et al. | Mar 1998 | A |
5758327 | Gardner et al. | May 1998 | A |
5758328 | Giovannoli | May 1998 | A |
5765138 | Aycock et al. | Jun 1998 | A |
5774873 | Berent et al. | Jun 1998 | A |
5794207 | Walker et al. | Aug 1998 | A |
5794219 | Brown | Aug 1998 | A |
5797127 | Walker et al. | Aug 1998 | A |
5799151 | Hoffer | Aug 1998 | A |
5799285 | Klingman | Aug 1998 | A |
5802502 | Gell et al. | Sep 1998 | A |
5803500 | Mossberg | Sep 1998 | A |
5809483 | Broka et al. | Sep 1998 | A |
5826244 | Huberman | Oct 1998 | A |
5832496 | Anand et al. | Nov 1998 | A |
5835896 | Fisher et al. | Nov 1998 | A |
5862223 | Walker et al. | Jan 1999 | A |
5881213 | Shaw et al. | Mar 1999 | A |
5890138 | Godin et al. | Mar 1999 | A |
5897621 | Boesch et al. | Apr 1999 | A |
5905974 | Fraser et al. | May 1999 | A |
5905975 | Ausubel | May 1999 | A |
5915209 | Lawrence | Jun 1999 | A |
5966699 | Zandi | Oct 1999 | A |
5978476 | Redman et al. | Nov 1999 | A |
6014627 | Togher et al. | Jan 2000 | A |
6021398 | Ausubel | Feb 2000 | A |
6055543 | Christensen et al. | Apr 2000 | A |
6085198 | Skinner et al. | Jul 2000 | A |
6229566 | Matsumoto et al. | May 2001 | B1 |
6266126 | Haneda | Jul 2001 | B1 |
6272636 | Neville et al. | Aug 2001 | B1 |
6366891 | Feinberg | Apr 2002 | B1 |
6560621 | Barile | May 2003 | B1 |
6623527 | Hamzy | Sep 2003 | B1 |
6628415 | Lawrence et al. | Sep 2003 | B1 |
6757070 | Lin et al. | Jun 2004 | B1 |
6832264 | Sheinwald et al. | Dec 2004 | B1 |
6834312 | Edwards et al. | Dec 2004 | B1 |
6928396 | Thackston et al. | Aug 2005 | B1 |
20010028394 | Matsumoto et al. | Oct 2001 | A1 |
20020001396 | Rhoads | Jan 2002 | A1 |
20020016725 | Eichstaedt et al. | Feb 2002 | A1 |
20020069295 | Edwards et al. | Jun 2002 | A1 |
20020113989 | Ferlitsch et al. | Aug 2002 | A1 |
20030208365 | Avery et al. | Nov 2003 | A1 |
20040215467 | Coffman et al. | Oct 2004 | A1 |
Number | Date | Country |
---|---|---|
WO 0163387 | Aug 2001 | WO |
WO 0163485 | Aug 2001 | WO |
WO 0176128 | Oct 2001 | WO |
Number | Date | Country | |
---|---|---|---|
20020120792 A1 | Aug 2002 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 09782620 | Feb 2001 | US |
Child | 09952197 | US |