File System Filter Scanning for Transactional Antivirus Protection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Computer security threats, particularly viruses, often cause unwanted file modifications that can lead to significant damage due to their ability to exploit vulnerabilities in file systems, especially within transactions where antivirus software may fail to detect changes until they are committed, leading to potential system harm.

Innovation Solution

Implementing a file system filter that scans files participating in transactions for viruses and updates cache entries to indicate cleanliness, allowing for efficient detection and prevention of unwanted changes, thereby ensuring files are scanned within their transactional context or outside it to prevent damage.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If antivirus software scans files only after transactions are committed, then system performance is maintained, but security detection capability deteriorates as viruses can modify files undetected during transactions

Engineering Contradiction:
Improvesecurity detection capabilityVSAvoidsystem performance
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent applies preliminary action by scanning files at the beginning of transactions before any modifications occur. The system identifies files that will be modified during upcoming transactions and performs antivirus scans on them in advance, ensuring that potential viruses are detected before they can execute harmful operations. This approach maintains security detection capability while minimizing impact on system performance by performing scans proactively rather than reactively after damage occurs.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements feedback mechanisms by monitoring transaction states and file modification patterns. The system tracks which files are being modified during transactions and uses this information to dynamically adjust scanning behavior. When a transaction is detected involving previously scanned files, the system receives feedback and determines whether additional scanning is necessary, creating a closed-loop security system that adapts to actual system conditions.

Inventive Principle:
Principle #23Feedback

2Reliability

If antivirus software scans all files in every transaction, then security detection capability is improved, but system performance deteriorates due to excessive scanning operations

Engineering Contradiction:
Improvesecurity detection capabilityVSAvoidsystem performance
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent applies local quality by differentiating scanning behavior based on specific file characteristics and transaction contexts. Instead of uniformly scanning all files, the system identifies and applies scanning only to files that exhibit risk characteristics - such as files being modified during transactions, files with suspicious metadata, or files in critical system directories. This localized approach concentrates security resources on high-risk areas while avoiding unnecessary scanning of low-risk files, thereby maintaining detection capability while preserving system performance.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent utilizes parameter changes by dynamically adjusting scanning parameters based on transaction properties and file states. The system modifies scanning intensity, timing, and target selection based on detected parameters such as transaction type, file access patterns, and system load conditions. When system performance is degraded, the system can adjust parameters to reduce scanning frequency or defer non-critical scans, allowing flexible optimization of the security-performance balance.

Inventive Principle:
Principle #35Parameter changes

3Productivity

If cache entries are used to track file cleanliness, then system performance is improved by reducing scans, but security reliability deteriorates if cache entries become invalid or outdated

Engineering Contradiction:
Improvesystem performanceVSAvoidsecurity reliability
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent implements feedback mechanisms for cache validation by continuously monitoring file system events that could invalidate cache entries. When transactions modify files or when file attributes change, the system receives feedback and automatically invalidates corresponding cache entries. This ensures that cache entries remain accurate reflections of actual file states, maintaining security reliability while preserving the performance benefits of caching.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The patent applies preliminary action by proactively invalidating cache entries before they could become outdated. The system anticipates potential cache invalidation scenarios by monitoring transaction states and file modification events, invalidating cache entries in advance of when they would become inaccurate. This preventive approach ensures that the system never relies on stale cache data for security decisions, maintaining reliability while allowing extensive use of caching for performance.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS7636946B2Unwanted file modification and transactions
Publication Date: 2009.12.22 MICROSOFT TECHNOLOGY LICENSING LLC
  • US7636946B2 patent drawing
  • US7636946B2 patent drawing
  • US7636946B2 patent drawing

AI summary

Aspects of the subject matter described herein relate to antivirus protection and transactions. In aspects, a filter detects that a file is participating in a transaction and then may cause the file to be scanned together with any changes that have made to the file during the transaction. After a file is scanned, a cache entry may be updated to indicate that the file is clean. The cache entry may be used subsequently for like-type states. For example, if the file was scanned inside a transaction, the cache entry may be used later in the transaction. If the file was scanned outside a transaction, the cache entry may be used later for requests pertaining to files not in a transaction. Cache entries may be discarded when they are invalid or no longer useful.