|Publication number||US7120862 B1|
|Application number||US 09/342,408|
|Publication date||Oct 10, 2006|
|Filing date||Jun 28, 1999|
|Priority date||Dec 1, 1998|
|Also published as||EP1006466A2, EP1006466A3, US7562291, US20020156800, US20060282763|
|Publication number||09342408, 342408, US 7120862 B1, US 7120862B1, US-B1-7120862, US7120862 B1, US7120862B1|
|Original Assignee||Lucent Technologies Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (20), Non-Patent Citations (15), Referenced by (16), Classifications (18), Legal Events (5)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a continuation-in-part of U.S. patent application Ser. No. 09/201,750, filed Dec. 1, 1998, now abandoned which is assigned to the assignee of the present invention and incorporated by reference herein.
The present invention relates to Internet resource access techniques, and more particularly, to a method and apparatus for ensuring persistent access to Internet resources.
The World Wide Web (the “Web”) provides a dynamic way to present and distribute a vast amount of information. Anyone who is connected to the Internet and has a browser, such as Netscape Navigator Communicator™, commercially available from Netscape Communications Corporation of Mountain View, Calif., can access information on the Web. The Web provides users with many media options and is becoming ubiquitously available in an expanding variety of personal electronic devices, far beyond its initial limited availability to users via computer terminals. In addition, as display technologies continue to improve, the Web may ultimately replace traditional paper-based media altogether.
Paper-based media generally have an associated time stamp, and permit an easy determination of the information that was available at a given time. For example, a newspaper article can be cited as an authoritative reference, provided that the particular date of the newspaper publication is specified. Due to the dynamic nature of Web content, however, a Web document is generally not a reliable reference source. Currently, Web content cannot reliably be expected to be available in the same form and addressed by the same Uniform Resource Locator (“URL”) at a future time. While some Web sites may provide access to some archived Web documents, the historical Web documents may not be accessed by users in a consistent and predictable manner, if at all.
The Online Computer Library Center, Inc. (“OCLC”), a nonprofit computer library service and research organization, provides a software tool, referred to as OCLC PURL (“Persistent Uniform Resource Locator”), for managing Internet addresses and aliases for general Internet resources. A Persistent Uniform Resource Locator provides flexible naming and name resolution services for Internet resources to ensure reliable, long-term access to Internet resources with minimal maintenance. Generally, OCLC PURL assists Internet users in locating Web resources. As previously indicated, the Internet is constantly expanding and changing. Once a Uniform Resource Locator changes, all previous references to that URL become invalid, thereby preventing users from accessing the Internet resource. The management of these changes often becomes burdensome.
While a URL points directly to the location of an Internet resource, a PURL points to an intermediate resolution service, which translates the PURL into the actual URL. Once a Web resource has been registered with the OCLC and assigned a PURL, the Web resource may be accessed by means of the PURL. A PURL assigns a persistent name to a resource even if the location of the resource changes. In this manner, PURLs referenced in Web documents and other resources can remain viable over time without having to update the references each time the Web resource is moved. The PURL “forwarding” address maintained by OCLC, however, must be kept up-to-date. In other words, each time the document is moved, OCLC must be notified of the new address for the document.
Generally, a method and apparatus are disclosed for providing persistent access to Web resources. According to an aspect of the invention, the Uniform Resource Locators that identify Web resources are optionally augmented to include a time stamp. The time stamp can be specified in the Uniform Resource Locator in any suitable format. In addition, variable time stamps can be utilized in accordance with the present invention to indicate a number of different dates, such as a date range or a recurring period of time. According to one aspect of the invention, wildcard characters and date ranges can be used in the variable time-stamp to implement a variable time stamp when a user is not sure of the date for a specific web resource or wishes to specify more than one precise date and time. The present invention allows the Web to be an organized and reliable reference source, much like paper-based media.
A web browser and a web server are disclosed that accommodate a time stamp parameter and allow a user to refer to any Web address with a precise target time. The disclosed Web browser can optionally include a mechanism to facilitate the specification of the desired date and time, or the user can manually append the time stamp to the URL indicated in the “Location” window of the browser. The persistent Web server (i) receives URLs containing a time stamp, a relative time-stamp or a variable time-stamp, (ii) retrieves the correct Web page(s) from an archive, and (iii) returns the desired page(s) or links to the client. In one embodiment, the persistent Web server (i) receives URLs containing a time stamp, (ii) retrieves a base Web page corresponding to the requested page from the archive, (iii) modifies the base Web page to update embedded hyperlinks to incorporate the same time stamp as the requested Web page and (iv) returns the updated page as the requested page to the client. The persistent Web server interprets the extracted URL in accordance with the selected time stamp format. In addition, the persistent Web server includes a persistent archive for storing all of the versions of Web resources that will be persistently available to Web users. The present invention ensures that a time-stamped reference to any Web resource refers to the desired material. In this manner, anyone doing historical research on the Web can retrieve any information that is valid in any period of time.
The time stamp can be included in the Uniform Resource Locator (“URL”) in any suitable format, as would be apparent to a person of ordinary skill. For example, to refer to the web page, www.Lucent.com, as it existed on Feb. 2, 1998, the URL can be represented as:
In a further variation, additional time granularity can be indicated by including the time-of-day in the URL. For example, the web page, www.Lucent.com, as it existed at 1:23 p.m. on Feb. 2, 1998, the URL can be represented as:
Unless otherwise specified, the time zone is assumed to be the user's default time zone. The illustrative time stamp format described above is a Common Gateway Interface (CGI) search argument. Of course, the month, day and year (or other time units) can be expressed in any order. For a URL without a time stamp, the default value will be the most recent version.
In addition, relative time stamps can be utilized. For example, to refer to the web page, www.Lucent.com, as it existed yesterday, the URL can be represented as:
Furthermore, if an embedded hyperlink contains a relative time stamp, the relative time stamp is based on the current web page. Thus, if a current web page has a URL in the form:
and this page contains an embedded hyperlink in the form:
The browser and server will interpret and translate the URL as
Other relative time stamps can include time offsets from the time of the current web page, such as plus or minus a specified period of time. For example, “+10D” can indicate plus ten days to the time of the currently viewed web page.
In order to refer to the previous or subsequent archived version of a document (relative to the time stamp of the current document), the URL can be represented using the labels “next_archive,” or “previous_archive.” In another variation, the first or most recent archived version of a document can be represented using the labels “first_archive,” or “final_archive,” respectively. The server will search through the archive to find the required document. For example, if a currently viewed document has a URL in the form:
and there are different versions of the same document archived on 7/2/97, 6/1/97, 4/1/97 and 3/1/97. The following link can be used in the current document to refer to one of these archives:
These relative archive time stamps make moving between different version of the same documents more efficient.
A time base parameter can be used to specify the reference date for the relative timestamp. For example,
indicates the date that is 100 days after Jun. 11, 1998. Similarly,
indicates the date that is the Monday after Jun. 11, 1998.
According to another feature of the present invention, wildcard characters and date ranges in the time stamp can be used to implement a variable time stamp in a URL when a user is not sure of the date for a specific web resource. In this manner, the server can display a list of the specific web resources that match the time stamp pattern. In the illustrative implementation, the following time stamp patterns are used:
TIME STAMP PATTERN
wildcard character matching 0 or more digits
wildcard character matching one digit
from m to n
date range specifier to specify a range
between two dates (either absolute or
The above time stamp patterns can be used in the time= or rtime= (relative time stamp) fields of the URL to specify, for example, an unknown year, month, day, hour, minute or second. For example,
1991 or 1992
1990 through 1999
1924, 1925, 1934, or 1935
19(20–30, 88, 90)
1920 to 1930, 1988, or 1990
1900 to 1909
1900 to 1999
19, 190 to 199, 1900 to 1999, . . .
Thus, the time stamp patterns can be used to request a list of resources having a matching time stamp. For example
all res.html pages in
all res.html pages in
all archived res.html
all res.html pages on
Oct. 2 and 3, 1998
When a server receives a URL request containing a variable time stamp, the server recognizes that the client is requesting a list of different versions of the same resource. The server will search through all the archives to identify all matched resources and return an HTML page with hyperlinks pointing to all matched resources. Since some web resources might have many versions archived, the user can optionally specify how to present the links. Thus, according to a further feature of the invention, a “timeorder” parameter allows the user to specify how to display the links corresponding to the matched resources. For example, timeorder=increase will present the links in increasing time order.
In addition, the links can be presented in a calendar-like format for easy navigation and selection. For example, if the links for the matching resources expand through several years, the links can be displayed in the following manner, with the month number underlined to indicate existing versions of the matching resources:
1996 1 2 3 4 5 6 7 8 9 10 11 12 1997 1 2 3 4 5 6 7 8 9 10 11 12 1998 1 2 3 4 5 6 7 8 9 10 11 12
The URL corresponding to the link for March, 1998 would have the form http://www.a.com/res.html?rtime=1998—3_*&timeorder=calendar. The time order can also be specified in terms of units of time. For example, timeorder=+D means to list the links of the matching resources in increasing day order, with the links corresponding to the first day of each month first, followed by links corresponding to the second day of each month and so on. Likewise, timeorder=+DY means to list the links of the matching resources in increasing day order, then in increasing year order.
Relative time stamps can be extended using the “*” wildcard at the end of the time value. For example, if the current day is Dec. 9, 1998, rtime=next_month* means rtime=1999—1_* (any day in January, 1999). Similarly, if the current day is Dec. 9, 1998, rtime=+1y* means rtime=1999—12—9_* (any time on Dec. 9, 1999).
In an alternate implementation, referred to herein as the “request-header scheme,” the time stamp can be indicated as one of the HTTP request headers, such as:
Time-Stamp: Jun. 9, 1998.
In another embodiment, referred to herein as the “special character scheme,” special characters can be utilized to indicate the inclusion of a time stamp in the URL, such as:
The Web browser 100 may be embodied as a conventional browser, such as Microsoft Internet Explorer™ or Netscape Navigator™, as modified herein to incorporate the features and functions of the present invention. As discussed further below, the Web browser 100 only needs to incorporate a new options selection panel to permit the user to specify the desired date and time. In fact, a conventional Web browser 100 can be utilized, with the user manually appending the time stamp to the URL indicated in the “Location” window of the browser 100.
In one implementation, the user has the option to turn the time stamp on or off. If the time stamp is activated, the browser 100 will change the URL accordingly before sending the URL out to the Web 130. Since there is no guarantee that the corresponding web server 140, 150 recognizes a time stamp, the document returned by the server 140, 150 might contain embedded hyperlinks that do not contain time stamps. Thus, in this situation, the web browser 100 can automatically convert the URL associated with an embedded hyperlink to add an appropriate time stamp when the user clicks on the hyperlink if the time stamp option is activated. The Web browser 100 should convert the URL in accordance with the selected time stamp format. In a request-header-scheme implementation, the browser 100 should be modified to send the special request header (“Time-Stamp: Jun. 9, 1998”). In addition, the HTML should be modified to include a new time stamp tag for any embedded hyberlink with a specific time stamp. For example, for a hyperlink such as:
<A HREF=“www.lucent.com”>Lucent Web Site</A>
the HTML should be modified to indicate the time stamp of Feb. 2, 1998 as follows:
The persistent Web servers 140, 150 may be embodied as conventional hardware and software, as modified herein to carry out the functions and operations described below. Specifically, the persistent Web servers 140, 150 need to know how to (i) receive URLs containing a time stamp or relative time-stamp, (ii) extract the time stamp, (iii) retrieve the Web page corresponding to the appropriate time-stamp, and (iv) return the requested page to the client. The persistent Web servers 140, 150 should interpret the extracted URL in accordance with the selected time stamp format.
If a version of the Web resource corresponding to the requested time does not exist, the present invention provides a version of the document stored time-wise in the vicinity of the requested target time. For example, the present invention may assume the Web resource has not changed from the previous archived version, and the version of the Web resource with the most recent time-stamp preceding the requested time is provided. Alternatively, the version of the Web resource with the next immediate time-stamp after the requested time is provided.
In addition, the persistent Web servers 140, 150 need to preserve all the information in their history of serving the Web. Thus, as shown in
For the persistent Web servers 140, 150 to support dated URLs, the persistent Web servers 140, 150 need to store all of their contents in a chronicle fashion to enable the retrieval of timely information. In one implementation, shown in
is conceptually equivalent to:
Of course, storing the entire web site contents is inefficient in terms of storage usage. Many Web pages exhibit few, if any, changes from day to day. Thus, significant storage efficiencies can be achieved by simply removing redundancy in the archive. Once the redundancy is removed, the storage requirement in addition to the regular web site storage is usually not very large.
If, however, it is determined during step 310 that there exists a subdirectory B that is created earlier and has identical contents as subdirectory A, then subdirectory A becomes an alias during step 320 pointing to subdirectory B. For example, as shown in
Thereafter, a test is performed during step 330 for each file, such as file A, to determine whether there exists a file B that is created earlier and has identical contents as file A. If it is determined during step 330 that there is no file B created earlier and having identical contents as file A, then it is not possible to reduce the redundancy of the persistent archive 145, 155 on the file level. Thus, program control terminates during step 350.
If, however, it is determined during step 330 that there exists a file B that is created earlier and has identical contents as file A, then file A becomes an alias during step 340 pointing to file B. Thereafter, program control terminates during step 350.
The archival process 300 may be impractical, since it needs to search for match files or directories. The run time increases exponentially with the number of entities in the archive. Many sub-optimal solutions are possible, as would be apparent to a person of ordinary skill in the art. A very simple solution is just checking what you want to archive today against the most recently added archive (like yesterday's contents). Since most of the web sites only differ from their previous archived ones slightly, this approach is quite reasonable. This approach is similar to the well-known incremental backup of a file system.
If a Web server is not persistent, it should only have minimal impact. In one embodiment, if a request includes a time stamp that is not recognized by a Web server, the server should deliver the most recent version of the requested Web resource.
Another way to reduce storage requirements of the persistent archive is to make the Web server smarter in terms of searching the correct archived data. For example, persistent storage of a web resource can be limited to versions that have some difference relative to previously saved versions of the web resource. For example, if an illustrative archive contains the following five different versions of a web resource: 6/4/1996, 6/12/1996, 3/23/1997, 2/1/1998 and 2/3/1998, the web server assumes that if the requested date does not equal any of the archived versions, then the requested date is identical to the version with the closest earlier date. In addition, a special symbolic link (or alias on MacOS, short cut on MS Windows) can be used in a directory to represent where to looks for files or directories that are not found under the current directory. In this manner, only the changed parts are stored under appropriate directories. All the unchanged data can be referred through a chain of such special links.
The domain name server (DNS) may be embodied as conventional hardware and software, as modified herein to carry out the functions and operations described below. Conventional DNS servers will reject any domain name reference which is not in the DNS database. One benefit of dated URL in accordance with the present invention is that it can be used to refer to historical Web resources. For example, if company A is merged into company B, all the web pages referred through “www.A.com” may no longer be valid. For users who want to access some documents from company A, they need to change all the reference to some place in company B's web site.
The historical information of company A can still be accessed if the DNS server does not reject the name reference, but instead consults an archive service company that knows where the historical information of company A is located. The DNS server itself can also store some historical data to resolve the name to IP address process faster.
If, however, it is determined during step 620 that the domain name request is dated, the DNS server process 600 searches the DNS database for the domain name with the date constraint during step 640. A further test is performed during step 650 to determine if the dated domain name is found. If it is determined during step 650 that the dated domain name is not found, then the DNS server consults with an archive service company during step 660 for further searching before program control proceeds to step 670.
If, however, it is determined during step 650 that the dated domain name is not found, then the searching result and indication, if redirect, are returned during step 670, before program control terminates.
After the domain name is resolved by the DNS server, the Web browser 100 needs to send the request to the web server 140, 150 according to what is returned from the DNS server. For example, a request from the user for the following URL, “http://www.A.com?time=2+2+1992,” will cause the browser 100 to send a domain name resolving request to the DNS server in a format such as “www.A.com 2/2/1992.” Since company A is now part of company B, the results will look like “22.214.171.124 redirect.” The Web browser 100 now has the IP address of the server and also knows it is a redirect one. Thus, the Web browser 100 will effectively send a request to the Web server 140, 150 of Company B in a form such as “http://126.96.36.199?http://www.A.com&time=2+2+1992.” The Web server 140, 150 of Company B will know how to map this old address of company A's to the appropriate place and get the correct information.
One side benefit of this new DNS server is that some names can be reused once they are history. For example, another company named Company A can utilize the www.A.com domain name after a predefined period, by updating the DNS database with the following entries:
In this manner, domain names can be reused without wasting them forever.
For chronological data, such as bank or stock broker transactions, it is easy to extract part of the record for a given time stamp restriction. For example, to check the account balance of a give date, the browser 100 can send a request in the form:
The server 140, 150 only needs to retrieve or recalculate the data up to Mar. 2, 1998 and return the results. Since all the transactions in such application environments have time stamps anyway, it is straightforward to add this function to the service.
For real time contents, the only restriction in appending a time stamp is the storage requirement. If a lot of storage space is available compared to the amount of information to be archived, the Web site administrator can choose to archive the real time contents or to archive some of them such as one day, one week or one year's worth of data.
For dynamically created advertisements, the Web site administrator must decide whether it is reasonable to ‘reshow’ the old advertisement (for some special reason) or whether the old advertisement can be replaced with a new, up-to-date commercial which is not relevant to the ‘real’ archived web contents.
It is to be understood that the embodiments and variations shown and described herein are merely illustrative of the principles of this invention and that various modifications may be implemented by those skilled in the art without departing from the scope and spirit of the invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5559991 *||Jun 27, 1995||Sep 24, 1996||Lucent Technologies Inc.||Incremental computer file backup using check words|
|US5819273 *||Apr 30, 1997||Oct 6, 1998||Apple Computer, Inc.||Method and apparatus for searching for information in a network and for controlling the display of searchable information on display devices in the network|
|US5832224 *||Jun 14, 1996||Nov 3, 1998||Digital Equipment Corporation||Entity management system|
|US5832478 *||Mar 13, 1997||Nov 3, 1998||The United States Of America As Represented By The National Security Agency||Method of searching an on-line dictionary using syllables and syllable count|
|US5907837 *||Nov 17, 1995||May 25, 1999||Microsoft Corporation||Information retrieval system in an on-line network including separate content and layout of published titles|
|US5943678 *||Dec 3, 1996||Aug 24, 1999||International Business Machines Corporation||Temporal displacement icon in a graphical user interface|
|US5946699 *||Aug 4, 1997||Aug 31, 1999||Kabushiki Kaisha Toshiba||Version management apparatus and method for data having link structure|
|US5978847 *||Dec 26, 1996||Nov 2, 1999||Intel Corporation||Attribute pre-fetch of web pages|
|US5991773 *||Apr 29, 1997||Nov 23, 1999||Brother Kogyo Kabushiki Kaisha||Information terminal unit with history management functions|
|US5991802 *||Nov 27, 1996||Nov 23, 1999||Microsoft Corporation||Method and system for invoking methods of objects over the internet|
|US6006227||Jun 28, 1996||Dec 21, 1999||Yale University||Document stream operating system|
|US6125371 *||Aug 19, 1997||Sep 26, 2000||Lucent Technologies, Inc.||System and method for aging versions of data in a main memory database|
|US6138141 *||Oct 18, 1996||Oct 24, 2000||At&T Corp||Server to client cache protocol for improved web performance|
|US6163778 *||Feb 6, 1998||Dec 19, 2000||Sun Microsystems, Inc.||Probabilistic web link viability marker and web page ratings|
|US6199107 *||Jul 22, 1998||Mar 6, 2001||Microsoft Corporation||Partial file caching and read range resume system and method|
|US6249795 *||Nov 5, 1997||Jun 19, 2001||At&T Corp.||Personalizing the display of changes to records in an on-line repository|
|US6256668 *||Oct 9, 1998||Jul 3, 2001||Microsoft Corporation||Method for identifying and obtaining computer software from a network computer using a tag|
|US6366933 *||Oct 27, 1995||Apr 2, 2002||At&T Corp.||Method and apparatus for tracking and viewing changes on the web|
|US6578078 *||Apr 2, 1999||Jun 10, 2003||Microsoft Corporation||Method for preserving referential integrity within web sites|
|US6606653 *||Oct 7, 1999||Aug 12, 2003||International Business Machines Corporation||Updating of embedded links in World Wide Web source pages to have the new URLs of their linked target Web pages after such target Web pages have been moved|
|1||*||"Building a digital library for the future" print out (hereinafter Archive97) is surfed using http://www.archive.org, published Jan. 26, 1997, pp. 1-21.|
|2||*||"How to Compose a Search" (herein after Compose Search), copyright 1997, pp. 1-2.|
|3||*||"Search the Kolb-Proust Archive Documents" (herein after Kolb-Proust Archive, http://gateway.library.uiuc.edu/kolbp/Search1.html, copyright 1997, pp. 1-16.|
|4||"Uniform Resource Names: A progress Report," D-Lib Magazine (Feb. 1996).|
|5||*||"Welcome to The Libertarian Web!" print out (hereinafter Libertarian) is surfed using http://www.archive.org, published Nov. 9, 1996, pp. 1-11.|
|6||Archive97, "Building a Digital Library for the Future" downloaded from http://www.archive.org, 1-21 (Jan. 26. 1997).|
|7||Brewster Kahle, "Archiving the Internet" Scientific American, 1-8 (Nov. 4, 1996).|
|8||K. Sollins and L. Masinter, "Functional Requirements for Uniform Resource Names," RFC1737, downloaded from http://www.cis.ohio-state.edu/htbin/rfc/rfc1737.html (Dec. 1994).|
|9||K. Sollins, "Architectural Principles of Uniform Resource Name Resolution," RFC2276, downloaded from http://www.cis.ohio-state.edu/htbin/rfc/rfc2276.html (Jan. 1998).|
|10||Keith Shafer et al., "Introduction to Persistent Uniform Resource Locators," downloaded from http://purl.oclc.org/OCLC/PURL/INET96 (1996).|
|11||Plan 9 FAQ, Bell Labs and Toronto University, downloaded from http://www.ecf.toronto.edu/plan9/plan9faq.html (1995).|
|12||Plan 9, Bell Labs, Lucent Technologies, Inc., downloaded from http://cm.bell-labs.com/plan9 (1998).|
|13||Simonson et al., "Version Augmented URIs for Reference Permanence via an Apache Module Design," Computer Networks and ISDN Systems, vol. 30, No. 1-7, 337-345 (Apr. 1998).|
|14||Stuart Weibel et al., "PURLs: Persistent Uniform Resource Locators," downloaded from http://purl.oclc.org/OCLC/OURL/SUMMARY(not date).|
|15||Uniform Resource Names, Los Alamos National Laboratory, downloaded from http://www.acl.lanl.gov/URN (Aug. 1996).|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7418655 *||Dec 16, 2004||Aug 26, 2008||Lucent Technologies Inc.||Method and apparatus for persistent storage of web resources|
|US7424471 *||Jan 8, 2007||Sep 9, 2008||Lsr Technologies||System for searching network accessible data sets|
|US7783780 *||Apr 18, 2006||Aug 24, 2010||Demand Media, Inc.||Method and system for mapping a domain name with no associated address to an address|
|US7845003||Oct 31, 2006||Nov 30, 2010||Novell, Inc.||Techniques for variable security access information|
|US8161064||Nov 24, 2009||Apr 17, 2012||Lsr Technologies||System for searching network accessible data sets|
|US9361188 *||Jul 7, 2014||Jun 7, 2016||Delphix Corp.||Virtual database rewind|
|US9396074 *||Jul 7, 2014||Jul 19, 2016||Delphix Corp.||Virtual database rewind|
|US20050108626 *||Dec 16, 2004||May 19, 2005||Lucent Technologies Inc.||Method and apparatus for persistent storage of Web resources|
|US20060015578 *||Jul 13, 2004||Jan 19, 2006||International Business Machines Corporation||Retrieving dated content from a website|
|US20060190623 *||Apr 18, 2006||Aug 24, 2006||Paul Stahura||Method and system for providing static addresses for Internet connected devices even if the underlying address is dynamic|
|US20080115223 *||Oct 31, 2006||May 15, 2008||Novell, Inc.||Techniques for variable security access information|
|US20080168035 *||Jan 8, 2007||Jul 10, 2008||Lsr Technologies||System for searching network accessible data sets|
|US20100070493 *||Nov 24, 2009||Mar 18, 2010||Lsr Technologies||System for searching network accessible data sets|
|US20140173417 *||Nov 6, 2013||Jun 19, 2014||Xiaopeng He||Method and Apparatus for Archiving and Displaying historical Web Contents|
|US20140289616 *||Mar 20, 2013||Sep 25, 2014||Microsoft Corporation||Flexible pluralization of localized text|
|US20150019496 *||Jul 7, 2014||Jan 15, 2015||Delphix Corp.||Virtual database rewind|
|U.S. Classification||715/234, 707/E17.108, 707/E17.115, 707/999.003, 707/999.202|
|International Classification||G06F12/00, G06F13/00, G06F17/30, G06F15/00|
|Cooperative Classification||Y10S707/99933, Y10S707/99953, Y10S707/99954, G06F17/30884, G06F17/30864, G06F17/30887|
|European Classification||G06F17/30W5K, G06F17/30W1, G06F17/30W5L|
|Jun 28, 1999||AS||Assignment|
Owner name: LUCENT TECHNOLOGIES INC., NEW JERSEY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ONG, PING-WEN;REEL/FRAME:010075/0950
Effective date: 19990625
|Apr 6, 2010||FPAY||Fee payment|
Year of fee payment: 4
|Mar 7, 2013||AS||Assignment|
Owner name: CREDIT SUISSE AG, NEW YORK
Free format text: SECURITY INTEREST;ASSIGNOR:ALCATEL-LUCENT USA INC.;REEL/FRAME:030510/0627
Effective date: 20130130
|Apr 4, 2014||FPAY||Fee payment|
Year of fee payment: 8
|Oct 9, 2014||AS||Assignment|
Owner name: ALCATEL-LUCENT USA INC., NEW JERSEY
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:033950/0261
Effective date: 20140819