Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
  • G06F12/16—Protection against loss of memory contents
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/14—Error detection or correction of the data by redundancy in operation
  • G06F11/1402—Saving, restoring, recovering or retrying
  • G06F11/1446—Point-in-time backing up or restoration of persistent data
  • G06F11/1458—Management of the backup or restore process
  • G06F11/1464—Management of the backup or restore process for networked environments
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/14—Error detection or correction of the data by redundancy in operation
  • G06F11/1402—Saving, restoring, recovering or retrying
  • G06F11/1446—Point-in-time backing up or restoration of persistent data
  • G06F11/1448—Management of the data involved in backup or backup restore
  • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/14—Error detection or correction of the data by redundancy in operation
  • G06F11/1402—Saving, restoring, recovering or retrying
  • G06F11/1446—Point-in-time backing up or restoration of persistent data
  • G06F11/1458—Management of the backup or restore process
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F15/00—Digital computers in general; Data processing equipment in general
  • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/14—Error detection or correction of the data by redundancy in operation
  • G06F11/1402—Saving, restoring, recovering or retrying
  • G06F11/1446—Point-in-time backing up or restoration of persistent data
  • G06F11/1458—Management of the backup or restore process
  • G06F11/1469—Backup restoration techniques
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/14—Error detection or correction of the data by redundancy in operation
  • G06F11/1402—Saving, restoring, recovering or retrying
  • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
  • G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99951—File or database maintenance
  • Y10S707/99952—Coherency, e.g. same view to multiple users
  • Y10S707/99955—Archiving or backup

Definitions

• a method from the perspective of a production server of replicating production server data in a virtually continuous, consistent fashion can involve sending a copy of volume data from one or more volumes of a production server to a backup server.
• the sent copy of data for the volume(s) will generally be consistent (i.e., application-consistent or file system-consistent) for a first instance of time.
• the method can involve identifying one or more changes to the volume data via one or more volume log files.
• the method can further involve, upon identifying a replication cycle event, saving the one or more data changes in the one or more volume log files.
• the one or more data changes will also be consistent for a second (i.e., subsequent) instance of time.
• the method can involve sending to the backup server a copy of the one or more changes.
• the backup server will have a copy of data of the one or more volumes, where the data are valid for a first instance of time and a second instance of time.
• a method from the perspective of a backup server of replicating production server data in a virtually continuous, consistent fashion can involve receiving one or more volume backups from a production server. In such a case, the one or more volume backups are consistent for an initial instance of time.
• the method can also involve receiving one or more application-consistent backup updates, at least one of which is a consistent update to at least one of the one or more volume backups for a subsequent instance of time.
• the method can involve receiving a recovery request for data that are valid in accordance with the subsequent instance of time.
• the method can also involve identifying the requested data for the subsequent instance of time at one or more backup server volumes.
• the requested data include at least a portion of the at least one application-consistent backup update.
• the method can involve sending the requested data that is valid for the subsequent instance of time to the production server.
• Figure 2 illustrates flowcharts of methods comprising a sequence of acts performed from the perspective of a production server and a backup server in accordance with implementations of the present invention.
• implementations of the present invention can meet a wide range of "recovery time objectives" by refreshing the backup server with a "full snapshot" of production server data.
• implementations of the present invention include a volume filter driver that can be implemented at the production server.
• the volume filter driver can be configured to monitor changes to bytes (and or byte blocks) on production server volume(s).
• the production server can then be configured to send an entire snapshot (or backup copy) by sending only those changed bytes (or byte blocks) to the backup server.
• use of a volume filter driver can mitigate the burden on resources that might otherwise be consumed when moving a full snapshot of production server data to a backup server.
• implementations of the present invention provide a user with the ability to recover a wide range of application-consistent data (e.g., from the file level, database level, and even entire production server level) with fairly high granularity (e.g., only a few minutes old) with much less burden than otherwise might be needed.
• application-consistent data e.g., from the file level, database level, and even entire production server level
• fairly high granularity e.g., only a few minutes old
• creating a consistent backup includes creating a baseline copy (e.g., 145) of one or more volumes (e.g., 175), and then supplementing that baseline copy with incremental, consistent updates (e.g., 150, 155) to the one or more volumes.
• the replica agent may also provide instructions to each application writer to perform certain functions on their data of interest, to thereby ensure that all data and metadata are consistent for the point-in-time of the replication cycle. For more simple applications that may not have an application writer or corresponding plug-in associated therewith, the replica agent might be configured to simply instruct those applications to freeze or shut down during the replication cycle.
• the aforementioned agents, components, and functions for creating consistent backups can be provided in at least one implementation in the MICROSOFT environment, for example, with a Volume Shadow Copy Service ("VSS").
• VSS Volume Shadow Copy Service
• production server 105 can then make and send a copy of the volume(s) (or alternatively only those selected folders, files, or file types) of interest.
• Figure IA shows production server 105 can provide this initial baseline copy 145 to backup server 110.
• production server 105 can provide the baseline copy 145 any number of ways. In one implementation, for example, production server 105 simply sends copy 145 over a network connection. In other implementations, such as where network bandwidth may be more limited, a backup administrator can transfer the volume copy to tape (or another intermediate storage node - not shown) and later connect that tape to backup server 110.
• a volume filter driver 115 can be used to monitor iterative changes to any of the one or more volumes (e.g., 175) at production server 105, with either in-memory bitmaps, or by marking particular changed bytes (or byte blocks) in a volume log file on disk.
• a volume filter driver e.g., 115
• a volume filter driver 115 will be independent of how hardware or software-based "snapshots" are implemented on production server 105.
• production server 105 can also monitor changes to the volume (e.g., .
• a volume log file (e.g., 135) can comprise all of the changes to a volume during a specific replication cycle (e.g., volume offset, length of data change) for each write to the volume, and/or in-memory bitmap of changes.
• a specific replication cycle occurs, an existing volume log file (e.g., 135) is frozen, and a new volume log file (not shown) can be created to gather changes for the next replication cycle.
• volume level changes can be sent directly to backup server 110, without any additional correlating information. Corresponding updates sent to backup server 110 might then be applied into the replica as "byte n" (or "byte block n changed to n-H").
• USN journal 140 can also be used in conjunction with volume log file 135 to correlate such things as the address of a particular byte or "byte block" change (as well as corresponding files for the change).
• each file on a volume can be thought of as an open set of addressable bytes, as well as an open set of addressable fixed-length byte blocks.
• monitoring and transferring byte blocks can be a more efficient way to monitor and transfer changes, as well as determine how much space may be needed for backup purposes.
• byte blocks represent a level of granularity that is usually somewhat less than that of an entire file, but greater than that of a single byte.
• Figure IA shows that production server 105 logs the various byte or byte block changes to its files to be protected.
• Figure IA shows that production server 105 logs that bytes (or "byte blocks") 121, 122, and 123 of file 120 have changed (e.g., 120 is a new file) since the last replication cycle (e.g., last 5, 10, 15, 20, 25, or 30 minutes, etc.).
• file 125 comprises bytes (or byte blocks) 127, 128, and 129, only bytes 128 and 129 have changed; and where file 130 comprises bytes 131, 132, and 133, only byte 133 has changed since the last replication cycle.
• production server 105 can log these changed bytes in a read-only shadow copy of the volume, folder, or relevant files.
• production server 105 can also store these changed bytes for a volume log file as in-memory bitmaps (e.g., using a bit per block of data on the volume) that are later passed to physical disk during replication. However logged or monitored, and at an appropriate time (i.e., the next replication cycle), production server 105 can then prepare only these file changes (i.e., 121, 122, 123, 128, 129, 133, etc.) to be sent to backup server 110.
• in-memory bitmaps e.g., using a bit per block of data on the volume
• production server 105 can then prepare only these file changes (i.e., 121, 122, 123, 128, 129, 133, etc.) to be sent to backup server 110.
• the changes are each valid for the most recent point-in-time (i.e., "V), and thus consistent (i.e., application-consistent or file system-consistent).
• V point-in-time
• the application of these bytes (or byte blocks) at backup server 110 can also be consistent.
• production server 105 can send these changes as updates 150 (for time ti) to backup server 110.
• production server 105 can identify and send each next set of incremental data changes (i.e., data changes logged for one or more volumes) in a next incremental update for the next replication cycle.
• Figure IA also shows that production server 105 prepares and sends update 155 (for time t 2 ) to backup server 110, and so on.
• volume shadow copy service (or other VSS-like mechanism) can be used in at least one implementation to read data only for the frozen, particular instance in time, and not any changes subsequent thereto. This can help ensure that snapshot updates 150 (as well as 155, etc.) are consistent up to the indicated instance of time at which snapshot (also referred to as backup update or update) operations commenced.
• backup server 110 can store each backup and corresponding update(s) in a particular replica volume.
• backup server 110 stores the backups and updates in the same volume allocation of the same storage medium.
• backup server 110 (and/or additional backup servers or storage nodes) can store the backups and corresponding updates on separate volumes,. and even on separate storage media, however desired by the backup administrator.
• a backup administrator may need to synchronize a number of aspects of the data with production server 105 data. For example, there may be cases of failure during a replication cycle, and/or over several replication cycles, such as may be due to network outage, log overflows (e.g., USN journal wrap, etc.). hi one implementation, therefore, a backup administrator can perform a validation or correction by creating a new baseline full snapshot (e.g., similar to 145) of production server 105.
• the backup administrator can then perform (e.g., via production server 105) a checksum comparison (or other validation) between the a snapshot of the data on production server 105, and the data on backup server 110. Any errant data on backup server 110 can then be fixed, if necessary.
• this checksum can be performed in at least one implementation using Remote Differential Compression ("RDC") used in WINDOWS SERVER 2003.
• RDC Remote Differential Compression
• WAN Wide Area Network
• LAN Local Area Network
• the backup administrator can divide each file in a snapshot into sets of "chunks" (e.g., byte blocks) and then compute checksums for each chunk.
• a user requests a particular version of a file (or other data representation) that is only a few minutes old (e.g., needed from a recent personal computer crash)
• the user can send a request to backup server 110 for that particular version of a file.
• a user might request a particular copy of file 120 that was valid as of 5 minutes ago (e.g., "to," or before updates 121, 122, 123).
• an administrator might request (not shown) an entire reproduction of volume or volumes 175.
• backup server 110 can then find the requested data as appropriate. For example, with respect to basic file-system data, each update of volume 175 could contain a full copy of requested data. Thus, backup server 110 might only need to identify the time requested by the user, identify the data within the corresponding update for that time, and then provide a copy of that data back to the user (e.g., recovery message 160).
• each incremental update (e.g., 150, 155) received by backup server 110 might only contain an incremental update for the requested data.
• backup server 110 could be configured to play back each incremental update from the requested recovery point back to the last baseline full.
• Backup server 110 can then combine the requested data identified during playback (e.g., 145, 150, 155, or to. n ), until reaching the time specified in the request.
• backup server 110 can then send the recovery response (e.g., 160), which is valid pursuant to the requested time.
• Figure IA shows that backup server 110 sends response 160, which indicates that the recovered data are valid for time "ti.”
• the backup server 110 may therefore need application support to playback the incremental updates.
• the baseline full copy and any corresponding incremental updates between the baseline full and the requested point in time can simply be copied back to production server 105.
• a corresponding application writer e.g., an application writer within a shadow copy service framework
• the time that elapses between the request for particular data and the corresponding response can be a function of at least two parts:
• the time to transfer data from target to source is generally a function of the network bandwidth available, as well as disk speeds and resource usage at backup server 110 and production server 105.
• the time to create a particular recovery is typically a function of the time required to recover a full copy of the production server data from a given baseline, and the time required to identify and play hack accumulated updates (e.g., "t ⁇ - i") accumulated from the baseline in order to recovery a specific point in time.
• recovery time can be greatly enhanced by limiting the amount of updates backup server 110 (or production server 105) has to play back for any given recovery request, such as by creating periodic baseline full copies (e.g., 145).
• one way of limiting the amount of incremental updates that backup server 110 might need to replay can involve creating a new "full" baseline snapshot periodically. Since creating and sending a new, full snapshot to backup server 110 can be resource-expensive (e.g., network bandwidth, production server 105 resources, and the amount of backup server 110 disk space needed) in some cases, implementations of the present invention also provide for the creation of "intelligent full snapshots.” These intelligent, full snapshots are effectively a baseline demarcation of a predetermined point in time.
• backup server 110 can roll two weeks worth of incremental updates (e.g., 150, 155, etc.) together with the last baseline copy of data (e.g., 145, or newer), and thus create essentially a new 'V copy of production server 105 data.
• backup server 110 can be configured to monitor all writes to production server 105 volume since the last full snapshot.
• backup server 110 implements volume filter driver 115 at production server 105 to monitor changes to the volume (i.e., one or more volumes), and store those writes in production server 105 memory 170 during each replication cycle.
• Figure IA shows that volume filter driver 115 interfaces between volume 175 and memory 170 on production server 105.
• volume filter driver 115 can record that change (or set of changes) in a volume log file 135. In at least one implementation, these changes are recorded in system memory 170 as an in-memory bitmap (e.g., 117a) for each of the one or more volumes.
• in-memory bitmap e.g., 117a
• Figure IB shows that memory 170 has been used to gather snapshot data corresponding to various in-memory bitmaps.
• volume filter driver 115 identifies certain file changes (i.e., file changes 121, 122, 123, etc.), and subsequently stores these changes as corresponding in-memory bitmaps 193, 195, etc. in memory allocation 190a.
• volume filter driver 115 stores all changes to the corresponding one or more volumes since the last replication cycle (i.e., snapshot 185a - "t 2 "), and, as such, each bitmap 193, 195, etc.
• volume filter driver 115 transfers all bitmaps for snapshot 190a (i.e., bitmaps 193, 195, etc.) to the appropriate volume 175 allocation 190b.
• bitmaps 193, 195, etc. For example, Figure IB shows that memory snapshot portions 180a and 185a have been emptied since the replication cycle for which they were generated has already passed. Furthermore, the corresponding volume 175 allocations 180b, 185b, etc. now contain "all bitmaps" 183, 187 that were previously stored in memory portions 180a, 185a, respectively.
• bitmaps e.g., 183, 187) can remain on the volume (e.g., 175).
• These in-memory bitmaps e.g., 193, 195) can be created and implemented a number of different ways.
• backup server 110 takes a shadow copy snapshot (e.g., snapshot 150) of the production server 105 volume, an Input/Output Control ("IOCTL") can be sent to the shadow copy provider (software or hardware) . This IOCTL can be intercepted by volume filter driver 115 to split the active bitmap.
• IOCTL Input/Output Control
• volume filter driver 115 synchronizes the split by creating a frozen set of bitmaps (e.g., 180a/189b, 185a/185b) and a new active set of bitmaps (e.g., 190a/190b).
• a frozen set of bitmaps e.g., 180a/189b, 185a/185b
• a new active set of bitmaps e.g., 190a/190b.
• an entity that is capable of harvesting the shadow copy diff area e.g., VSS diff area
• this entity could provide an abstraction that would give the set of changed files and the set of changes in the files.
• An appropriate replication or backup application can then use this infrastructure for achieving replication.
• volume filter driver 115 passes the frozen bitmaps to disk in order to reduce memory 170 usage.
• Volume filter driver 115 can also expose one or more IOCTLs that can be queried for all the changes that occurred since the most recent snapshot (e.g., "t n -i"). In one implementation, querying these IOCTLs returns all the bitmaps that have been accumulated since the most recent snapshot.
• backup server 110 can also identify the set of files that are changed using, for example USN journal 140 (or using other monitored file metadata).
• Backup server 110 (or relevant component) can then query the production server 105 file system for the file extents that each changed file occupies.
• An intersection between the file extents queried from the file system and the file extents that volume filter driver 115 reports can provide the extents of the file that have changed since the last replication cycle, and thus allow certain files (e.g., database files) to be excluded from certain replication processes.
• Backup server 110 (or relevant component) can then repeat this process for each changed file (either as reported by a USN journal or by a similarly-configured metadata document).
• a File Reference Number (FRN) at production server 105 might not match with the FRN for the same file stored at backup server 110.
• FRN File Reference Number
• a volume might have the following changes, which involve modifying a path at production server 105 for file "y-txt": 1) Modify C: ⁇ a ⁇ b ⁇ c ⁇ y.txt 2) Rename C: ⁇ a ⁇ b to C: ⁇ p ⁇ q ⁇ r
• original path "a ⁇ b" at production server 105 is renamed as path “p ⁇ q ⁇ r,” and directory “ ⁇ a” of the original path is deleted. This leaves the path at production server 105 for file “y.txt” to be "C: ⁇ p ⁇ q ⁇ p ⁇ r ⁇ b ⁇ c ⁇ y.txt.” Nevertheless, these path changes for "y-txt" at production server 105 may not automatically result in changes to the path at backup server 110.
• production server 105 needs to retrieve the file path for "y.txt” from backup server 110.
• the path for "y.txt” at production server 105 in the snapshot for "c-FRN” is C: ⁇ p ⁇ q ⁇ r ⁇ b ⁇ c ⁇ y.txt, which is different from its path at backup server 110 (i.e., C: ⁇ a ⁇ b ⁇ c ⁇ y.txt).
• Implementations of the present invention can solve this issue with at least two alternative approaches.
• the USN journal can simply retrieve and store path metadata from backup server 110 in a relational database, and thus continually correlate file paths at production server 105 and backup server 110.
• production server 105 can scan the USN journal twice. In the first pass, production server 105 can correlate this information through iterative scans (or "passes") of USN journal 140. In one scan, for example, production server 105 caches each folder rename. In a second pass, production server 105 can compute the corresponding path at backup server 11.0 based on the cached renames and current paths. For example, at the end of a first pass, production server 105 might cache the following information about deleted and/or renamed directories:
• production server 105 To compute the file path for y ; txt, production server 105 first identifies that the parent FRN (i.e., "File Reference Number") for y.txt in record "1" is cFRN. In a next step, production server 105 computes the file name for cFRN, as well as the file name of the parent FRN. Production server 105 then looks in cache before querying the file system. Since, in this example, the cache has no file name entry for the parent cFRN, production server 105 queries the file system, and determines that the file name is c, and that the parent is bFRN.
• FRN i.e., "File Reference Number”
• Production server 105 then computes the file name of bFRN, as well as bFRN's corresponding parent file name. As before, production server 105 first looks before querying the file system. Since the cache has an entry for bFRN in this example, production server 105 determines that the file name is b, and that the parent is aFRN. Production server then computes the file name of aFRN and the parent file name of aFRN. Again, production server 105 first looks at the cache before querying the file system, and since the cache has an entry for aFRN in this example, production server 105 determines that the file name of aFRN is "a,” and the parent FRN is "root.”
• production server 105 computes the final path as "c: ⁇ a ⁇ b ⁇ c ⁇ y.txt.”
• the cache is updated for the new parent file name as follows.
• ⁇ FRN bFRN
• replicajparent rFRN
• replica_parent root
• replicajname a ⁇
• the foregoing text illustrates how the two-pass algorithm can help optimize the amount of data that production server 105 transfers to backup server 110.
• the foregoing text describes multiple ways in which production server 105 can identify at the time of the second pass any created files* as well as any files that are modified and then deleted, and thus properly correlate file paths with backup server 110.
• Figures 1A-1B and the corresponding text provide a number of systems, components, and mechanisms for efficiently backing up a production server's data in a virtually continuous fashion.
• implementations of the present invention can also be described in terms of flowcharts of methods having a sequence of acts for accomplishing a particular results.
• Figure 2 illustrates flowcharts of from the perspective of production server 105 and backup server 110 in accordance with implementations of the present invention for backing up and recovering data. The acts illustrated in Figure 2 are described below with respect to the components and diagrams illustrated in Figures 1 A-IB.
• Figure 2 shows that the method from the perspective of backup server 110 comprises an act 250 of receiving one or more consistent updates.
• Act 250 includes receiving one or more consistent backup updates, at least one of which is a consistent update to at least one of the one or more volume backups for a subsequent instance of time.
• backup server 110 might roll together copies of the file at each preceding and current point in time that is valid for the request; that is, backup server 110 combines copies of the file from times "to," and "ti.”
• each subsequent update e.g., 150, 155
• backup server 110 may only need to identify the requested data in the most recent update (or some other subsequent update) for the requested point-in-time.
• backup server 110 may need to identify each incremental update from the point requested going back to the latest baseline full, or may need to simply identify the requested data in the latest point-in-time update.
• Implementations of the present invention also provide a number of ways for tracking data changes (e.g., byte or byte block level) with low performance overhead, and tracking data changes in a manner that is independent of the file system and hardware/software snapshots. Furthermore, implementations of the present invention also provide one or more ways to reconstruct path information (such as with USN-based replication) without necessarily requiring persistent state on the relevant production servers.
• the embodiments of the present invention may comprise a special purpose or general-purpose computer including various computer hardware, as discussed in greater detail below.
• Embodiments within the scope of the present invention also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer.
• such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
• a network or another communications connection either hardwired, wireless, or a combination of hardwired or wireless
• the computer properly views the connection as a computer- readable medium.
• any such connection is properly termed a computer-readable medium.
• Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Quality & Reliability (AREA)
• Computer Hardware Design (AREA)
• Software Systems (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Priority Applications (8)

Applications Claiming Priority (4)

Publications (1)

Family

ID=38750771

Family Applications (1)

Country Status (11)

Cited By (3)

Families Citing this family (137)

Citations (6)

Family Cites Families (30)

• 2006
  • 2006-08-02 US US11/461,846 patent/US7613750B2/en active Active
• 2007
  • 2007-04-26 MX MX2008014538A patent/MX2008014538A/es active IP Right Grant
  • 2007-04-26 CN CN2007800203131A patent/CN101460934B/zh not_active Expired - Fee Related
  • 2007-04-26 KR KR1020087028816A patent/KR101322991B1/ko not_active Expired - Fee Related
  • 2007-04-26 BR BRPI0711335A patent/BRPI0711335B1/pt not_active IP Right Cessation
  • 2007-04-26 JP JP2009513156A patent/JP5028482B2/ja not_active Expired - Fee Related
  • 2007-04-26 EP EP07776394.4A patent/EP2033100B1/en not_active Not-in-force
  • 2007-04-26 CA CA2649404A patent/CA2649404C/en not_active Expired - Fee Related
  • 2007-04-26 AU AU2007268226A patent/AU2007268226B2/en not_active Ceased
  • 2007-04-26 RU RU2008147124/08A patent/RU2433457C2/ru not_active IP Right Cessation
  • 2007-04-26 WO PCT/US2007/010304 patent/WO2007139647A1/en not_active Ceased

Patent Citations (6)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events