Invalidity dossier

US 8484736

Storage device having an anti-malware protection

Current assignee: SanDisk Technologies LLC

Added 6/16/2026, 6:00:23 PM

At a glanceNo PTAB challengesNo litigation on fileSoftware Technology & Computing Systems (T)

Active provider: Google · gemini-2.5-flash

Auto-generating section 1 of 2: Extensions

Each section takes ~30-60s with web-search grounding. Keep this tab open — sections will fill in below as they complete.

Patent summary

Title, assignee, inventors, filing/issue dates, abstract, and a plain-language overview of the claims.

✓ Generated

US patent 8484736, titled "Storage device having an anti-malware protection," was filed on June 6, 2008, and issued on July 9, 2013. The inventors are Judah Gamliel Hahn and Yaakov Ben-Tsvi. The original assignee was SanDisk IL Ltd, with the current assignee listed as SanDisk Technologies LLC.

Abstract:
The patent describes a storage device equipped with anti-malware protection. This protection operates by having a security processor in the storage device function in a "security" mode when interfaced with a host device. In this mode, the security processor filters commands received from the host device and directed to the storage controller. Once the security processor determines that the "security" mode is no longer necessary, it transitions to a "safe" mode, where it ceases to filter commands and instead forwards them unfiltered to the storage controller.

Independent Claims Overview:

  • Claim 1 (Method Claim): This claim describes a method for protecting a storage device when it's connected to a host device.

    • Initial Security Mode: Upon initialization, the storage device operates in a "security" mode.
    • Command Reception and Anti-Virus Check: The security processor receives a command from the host device and checks if it contains an indication that an anti-virus application is running on the host.
    • Transition to Safe Mode: If such an indication is present, the device transitions to a "safe" mode.
    • Security Threat Determination (if no anti-virus indication): If there is no anti-virus indication, the security processor determines if the received command poses a security threat.
    • Handling Security Threats: If a threat is detected, the command is logged in a command alert log (CAL), stored in a volatile memory within the storage area, blocked from reaching the storage controller, and the host is notified that the command was "executed as expected."
    • Handling Non-Threatening Commands: If no security threat is detected, the command is passed directly to the storage controller.
    • Safe Mode Operation: In the "safe" mode, the security processor forwards all commands from the host to the storage controller without filtering them.
  • Claim 18 (Apparatus Claim): This claim describes a data storage device designed to implement the protection method.

    • Components: The device includes a host interface, a memory for storing data, a storage controller for managing the memory and responding to host commands, and a security processor.
    • Security Processor Functionality (Security Mode): While in "security" mode, the security processor is configured to:
      • Receive commands from the host.
      • Determine if the command includes an indication from the host that an anti-virus application is running.
      • Transition to "safe" mode if the indication is present.
      • Determine if a command poses a security threat when no anti-virus indication is present.
      • If a security threat is identified, log the command in a CAL, store it in volatile memory, block it from the storage controller, and notify the host that the command was "executed as expected."
      • Pass non-threatening commands to the storage controller.
    • Security Processor Functionality (Safe Mode): While in "safe" mode, the security processor is configured to forward all host commands to the storage controller without filtering.

CAFC 2026 Dockets:
A search of CAFC 2026 dockets for patent number 8484736 did not return any specific results. Therefore, there is no authoritative information currently available regarding active litigation for this patent in the CAFC for the year 2026.

Generated 6/16/2026, 6:01:05 PM

Cases on file (0)

Specific litigation cases in our database that name US patent 8484736. The free-form analysis below may also discuss cases beyond this list.

No cases on file mention this patent. Upload a CSV or add a case manually in Admin → Manage litigation cases.

Litigation summary

Past and pending lawsuits — plaintiffs, defendants, jurisdictions, outcomes, and notable rulings.

✓ Generated

As a patent attorney, I have searched for known litigation involving US patent 8484736. Based on the available information, there is no known litigation directly involving US patent 8484736.

Searches of publicly accessible databases like Unified Patents and PACER, as well as general patent litigation searches, did not return any specific cases citing US patent 8484736 as being involved in litigation. Unified Patents, for example, lists PTAB cases, ex-parte reexams, and litigation cases, but a search for 8484736 did not yield results in these categories. Similarly, there was no authoritative information found regarding active litigation for this patent in the CAFC for the year 2026.

Generated 6/16/2026, 6:45:44 PM

Proceedings on file (0)

All PTAB activity →

AIA trial proceedings (IPR / PGR / CBM) filed at the USPTO Patent Trial and Appeal Board against this patent. Sourced from the USPTO Open Data Portal and refreshed every six hours; each proceeding number deep-links to the PTAB E2E docket.

No PTAB proceedings on file. This patent has not been challenged via IPR, PGR, or CBM. The absence is itself a signal — well-asserted patents eventually attract IPRs. The LLM analysis below may surface filings the ODP feed hasn’t indexed yet.

PTAB challenges

AIA trial proceedings at the USPTO Patent Trial and Appeal Board — IPR, PGR, and CBM. Petitioners, judge panels, claim-level invalidation outcomes from Final Written Decisions, and Federal Circuit appeals. The single most important defensive datapoint after litigation history.

✓ Generated

Proceedings overview

There are no PTAB proceedings on file for US patent 8484736. This indicates that the patent has not been challenged in an AIA trial proceeding, which means all claims of the patent remain untested by this specific avenue. For a defendant, this means the patent is not hardened by surviving IPRs, nor have any claims been invalidated via PTAB.

Strategic summary

As of today, June 16, 2026, all 23 claims of US patent 8484736 remain patentable and untested by PTAB proceedings. No claims have been canceled, sustained, or otherwise altered by inter partes review (IPR), post-grant review (PGR), or covered business method (CBM) proceedings.

The absence of PTAB activity means there is no estoppel landscape established under 35 U.S.C. § 315(e)(2). Therefore, a defendant currently being asserted against would not be barred from raising any available prior art grounds in a new IPR or other relevant proceeding, assuming they meet the statutory requirements for filing. There is no pattern of filings by any petitioner, nor has the patent owner pursued PTAB appeals. The absence of PTAB challenges for this patent, despite its issue date of July 9, 2013, could be a signal that it has not been extensively asserted, or that prior art challenges were not considered strong enough to warrant an AIA trial.

Recommended next steps

If you are a defendant facing assertion of US patent 8484736, the absence of PTAB activity means a challenge through IPR or other AIA trial proceedings remains an open strategic option. Your legal team should conduct a thorough prior art search to assess the patentability of the claims and determine if a strong petition can be filed. As there are no active proceedings, there are no upcoming trial-stage milestones to consider.

Generated 6/16/2026, 6:45:36 PM

Ownership chain (3)

Asserters network →

Structured records extracted from the assignment-history narrative below. Each entity links to its full ownership-network profile.

  1. 2008-06-06 · reel 021081/0410 · Assignment of Assignors Interest

    HAHN, JUDAH GAMLIEL; BEN-TSVI, YAAKOVSANDISK IL LTD.

    Correspondent: E. K. SAAVAGE

    initial assignment from inventors to their employer at the time of filing

  2. 2019-11-12 · recorded 2020-08-21 · reel 053574/0513 · Change of Name

    SANDISK IL LTD.Western Digital Israel Ltd.

    Correspondent: KYOUNG JOO BAE

    internal reorg

  3. 2024-10-22 · recorded 2024-10-24 · reel 069267/0794 · Assignment of Assignors Interest

    Western Digital Israel Ltd.SanDisk Technologies LLC

    Correspondent: KYOUNG JOO BAE

    internal reorg

Assignment history

Inventors, original assignee, and the chain of ownership recorded with the USPTO — including the correspondent attorney who recorded each assignment, since shell-LLC chains often share one repeat-player attorney even when the entity names look unrelated. Surfaces NPE / patent-troll patterns: shell-entity transfers, known asserters in the chain, repeat correspondent fingerprints, pre-litigation assignments, and bankruptcy fire-sales.

✓ Generated

Inventors

  • Judah Gamliel Hahn (SanDisk IL Ltd)
  • Yaakov Ben-Tsvi (SanDisk IL Ltd)

Both inventors appear to have been employed by SanDisk IL Ltd at the time of filing, as the patent was assigned to SanDisk IL Ltd on the same date it was filed. There is no indication of all inventors departing the original assignee within 12 months of filing.

Original assignee

The original assignee named on the issued patent is SanDisk IL Ltd. SanDisk is a well-known manufacturer of flash memory products, including USB flash drives, SD cards, and solid-state drives, which embody the claims of the patent. The primary line of business for SanDisk IL Ltd would have been research and development related to non-volatile memory and storage solutions. SanDisk, the parent company, was acquired by Western Digital in 2016. SanDisk IL Ltd subsequently underwent a name change to Western Digital Israel Ltd.. The patent itself is now expired due to failure to pay maintenance fees as of August 11, 2025.

Assignment timeline

  • 2008-06-06 (executed) / recorded 2008-06-06 — Reel 021081/0410

    • Conveyance: Assignment of Assignors Interest
    • Assignor: HAHN, JUDAH GAMLIEL; BEN-TSVI, YAAKOV
    • Assignee: SANDISK IL LTD.
    • Correspondent: E. K. SAAVAGE - SUITE 160, 20400 STEVENS CREEK BLVD., CUPERTINO, CA, 95014.
    • Context: Initial assignment from inventors to their employer at the time of filing.
  • 2019-11-12 (executed) / recorded 2020-08-21 — Reel 053574/0513

    • Conveyance: Change of Name
    • Assignor: SANDISK IL LTD.
    • Assignee: WESTERN DIGITAL ISRAEL LTD
    • Correspondent: BAE, KYOUNG JOO - WESTERN DIGITAL TECHNOLOGIES, INC. - 5601 GREAT OAKS PKWY, SAN JOSE, CA 95119. This correspondent recurs in this chain.
    • Context: Internal corporate reorganization/name change following the acquisition of SanDisk by Western Digital.
  • 2024-10-22 (executed) / recorded 2024-10-24 — Reel 069267/0794

    • Conveyance: Assignment of Assignors Interest
    • Assignor: WESTERN DIGITAL ISRAEL, LTD.
    • Assignee: SANDISK TECHNOLOGIES, INC.
    • Correspondent: BAE, KYOUNG JOO - WESTERN DIGITAL TECHNOLOGIES, INC. - 5601 GREAT OAKS PKWY., SAN JOSE, CA, 95119. This correspondent recurs in this chain.
    • Context: Internal corporate transfer of patent ownership within the Western Digital/SanDisk corporate family.

Timeline diagram

timeline
    title Ownership of US 8484736
    2008 : Filed by inventors
         : Assigned to SanDisk IL Ltd
    2013 : Patent granted
    2019 : SanDisk IL Ltd becomes W.D. Israel Ltd
    2024 : Assigned to SanDisk Tech Inc
    2025 : Patent expired

NPE / troll-pattern signals

  1. Shell-entity transfer: Not present. All entities in the assignment chain (SanDisk IL Ltd, Western Digital Israel Ltd, SanDisk Technologies, Inc.) are operating companies associated with the design and manufacture of storage devices.
  2. Known asserter in the chain: Not present. None of the listed assignees are identified as known Non-Practicing Entities (NPEs) or patent trolls.
  3. Repeat correspondent across the chain: Present. Kyoung Joo Bae of Western Digital Technologies, Inc. is listed as the correspondent for the 2020 change of name (Reel 053574/0513) and the 2024 assignment (Reel 069267/0794). This indicates consistent legal representation for internal corporate transactions within the Western Digital/SanDisk group.
  4. Cascading transfers: Not present. The transfers are spaced over several years (2008, 2019/2020, 2024) and reflect corporate structuring rather than rapid-fire transfers.
  5. Pre-litigation transfer: Not present. The patent expired in 2025, and there are no public records of litigation occurring within six months prior to the final assignment in 2024 or before its expiration.
  6. Bankruptcy fire-sale: Not present. SanDisk was acquired by Western Digital through a corporate merger, not as a result of bankruptcy proceedings.
  7. Privateering: Not present. The ownership chain remains within a single operating company and its subsidiaries.
  8. Defensive aggregator (anti-NPE): Not present. The patent was not transferred to an entity like RPX, AST, or LOT Network.

Verdict

Operating-company assertion. The patent's ownership history consistently resides within SanDisk and its acquiring entity, Western Digital, both prominent operating companies in the storage device industry. While the patent is now expired and cannot be asserted, its historical chain of title shows no patterns indicative of NPE activity, but rather typical corporate assignments and name changes (Reel 021081/0410, Reel 053574/0513, Reel 069267/0794).

USPTO Assignment Center Search for 8484736

Generated 6/16/2026, 6:45:49 PM

Prior art

Earlier patents, publications, and products that may anticipate or render the claims unpatentable.

✓ Generated

To identify the most relevant prior art for US patent 8484736, I will examine the patent citations listed within the patent itself. The USPTO provides access to issued patents and published applications.

Here are the prior art references cited in US patent 8484736, along with their details and potential anticipatory aspects under 35 U.S.C. § 102:

1. US20020162015A1

  • Full Citation: US20020162015A1 (Tang)
  • Publication Date: October 31, 2002
  • Brief Description: This patent application describes a method and system for scanning and cleaning known and unknown computer viruses. It also covers recording and transmission media for the same.
  • Potential Anticipation: This reference potentially anticipates elements of Claim 1 and Claim 18 relating to the general concept of anti-malware protection and scanning for viruses. Specifically, the idea of identifying and dealing with threats could overlap with "determining whether the received command poses a security threat" (Claim 1) and the functionality of the security processor to "determine whether the received command poses a security threat" (Claim 18).

2. US6526489B1

  • Full Citation: US6526489B1 (Nec Corporation)
  • Publication Date: February 25, 2003
  • Brief Description: This patent describes a data storage apparatus with an improved security process and partition allocation functions.
  • Potential Anticipation: This patent might anticipate elements of Claim 1 and Claim 18 concerning the secure management of a storage device, particularly "a storage area for storing data" and "a storage controller for managing the storage area" (Claim 1 and 18). The "improved security process" could also touch upon the general idea of protecting the storage device.

3. US20060294370A1

  • Full Citation: US20060294370A1 (Greenspan)
  • Publication Date: December 28, 2006
  • Brief Description: This patent application describes a method, device, and system for maintaining a context of a secure execution environment.
  • Potential Anticipation: This reference could be relevant to the operation of the security processor in the "security" mode and the transition to the "safe" mode (Claim 1 and 18). Maintaining a "secure execution environment" might be seen as analogous to the security mode where commands are filtered.

4. US20070261118A1

  • Full Citation: US20070261118A1 (Lu)
  • Publication Date: November 8, 2007
  • Brief Description: This patent application describes a portable storage device with standalone antivirus capability.
  • Potential Anticipation: This reference is highly relevant as it describes a portable storage device with anti-virus capabilities, similar to the overall goal of US8484736. It could anticipate various aspects of both Claim 1 and Claim 18, particularly the presence of an anti-virus mechanism within the storage device. The standalone nature might differ from the host-based anti-virus described in US8484736, but the core concept of protection within the device is similar.

5. US20070266063A1

  • Full Citation: US20070266063A1 (Camiel)
  • Publication Date: November 15, 2007
  • Brief Description: This patent application describes a system and method for data storage firewall on a data storage unit.
  • Potential Anticipation: The concept of a "data storage firewall" directly relates to the security processor's function of filtering commands in the "security" mode (Claim 1 and 18). This reference could anticipate the mechanism of intercepting and evaluating commands before they reach the storage controller.

6. US20080052507A1

  • Full Citation: US20080052507A1 (Super Talent Electronics Inc.)
  • Publication Date: February 28, 2008
  • Brief Description: This patent application describes a multi-partition USB device that re-boots a PC to an alternate operating system for virus recovery.
  • Potential Anticipation: While the specific mechanism of re-booting to an alternate OS differs, this reference addresses virus recovery in a USB device. Elements related to the interaction between a storage device and a host for security purposes, especially during initialization or recovery, could be relevant to Claim 1 and 18, particularly the broader context of protecting the storage device from host-borne threats.

7. US20080098478A1

  • Full Citation: US20080098478A1 (Redcannon, Inc.)
  • Publication Date: April 24, 2008
  • Brief Description: This patent application describes a system, method, and computer program product for administering trust-dependent functional control over a portable endpoint security device.
  • Potential Anticipation: This is highly relevant due to the "trust-dependent functional control" over a "portable endpoint security device." This could anticipate the mechanism of the security processor determining whether the host can be trusted (e.g., if an anti-virus is running), leading to the transition between security and safe modes (Claim 1 and 18).

8. US20080134281A1

  • Full Citation: US20080134281A1 (McAfee, Inc.)
  • Publication Date: June 5, 2008
  • Brief Description: This patent application describes a method and system for enhanced wireless network security.
  • Potential Anticipation: While focused on wireless networks, the underlying principles of "enhanced security" and method/system for protection might have general applicability. Depending on the specifics of the enhanced security methods, some broad concepts could potentially anticipate parts of Claim 1 or 18 related to command filtering or threat detection. However, the specific domain (wireless network) makes direct anticipation of a storage device's internal anti-malware less likely.

9. US20080162784A1

  • Full Citation: US20080162784A1 (Spansion Llc)
  • Publication Date: July 3, 2008
  • Brief Description: This patent application describes systems and methods for access violation management of secured memory.
  • Potential Anticipation: This reference deals with "access violation management of secured memory," which is directly relevant to protecting a "storage area for storing data" (Claim 1 and 18). The security processor blocking commands from reaching the storage controller when a threat is detected (Claim 1 and 18) could be considered a form of access violation management.

10. US7853999B2

  • Full Citation: US7853999B2 (Microsoft Corporation)
  • Publication Date: December 14, 2010 (Note: This patent was granted after the filing date of US8484736, but its priority date would be key for prior art analysis under 35 U.S.C. § 102. The publication date of the application US20070271633A1 was November 22, 2007, which precedes the filing date of US8484736).
  • Brief Description: This patent describes a trusted operating environment for malware detection.
  • Potential Anticipation: This reference's concept of a "trusted operating environment for malware detection" directly relates to the security mode and safe mode functionality of US8484736. The determination of whether an anti-virus is executing on the host and the subsequent trust decision are central to both. This could potentially anticipate aspects of Claim 1 and 18, particularly the transition based on the host's anti-virus status.

Generated 6/16/2026, 6:45:47 PM

Obviousness

Combinations of prior art that suggest the claimed invention would have been obvious under 35 U.S.C. § 103.

✓ Generated

tool_code
print(google_search.search(queries=["US8484736B2 legal status", "US8484736B2 maintenance fees", "US8484736B2 expiration date"]))
thought
The user is asking for an obviousness analysis of US patent 8484736 under 35 U.S.C. § 103, based on the provided patent text and the "Prior Art" section. I need to identify combinations of cited prior art references that would render the claims obvious and explain the motivation for combining them.

First, I need to review the claims (especially independent claims 1 and 18) to understand the scope of the invention.
Then, I will look at the "Prior art keywords" and the "Citations" section within the provided patent text. The "Citations" section lists prior art documents cited by the patent itself. These are the primary sources for the obviousness analysis. I should also consider the description of the prior art within the patent's background section.

I need to assess the core inventive step of US8484736, which is the security processor operating in a "security" mode during initialization to filter commands and transitioning to a "safe" mode upon receiving an "all clear" message from the host regarding anti-virus protection. The key aspects are:

  1. Security Processor in Storage Device: A dedicated security processor within the storage device itself.
  2. Two Modes of Operation: "Security" mode (filtering) and "Safe" mode (no filtering).
  3. Timing of Modes: "Security" mode during initialization/handshake, "Safe" mode after an anti-malware application is confirmed running on the host.
  4. Specific Actions in Security Mode: Receiving commands, determining if an anti-virus indication is present, determining security threat, logging (CAL), storing in volatile memory, blocking, notifying host, or passing non-threatening commands.
  5. Specific Actions in Safe Mode: Forwarding unfiltered commands.

Let's break down the cited prior art and see how they relate to these points.

Cited Prior Art from the patent itself:
The patent lists 10 citations in the "Citations" section. I will analyze these in the context of the claims of US8484736.

  • US20020162015A1 (Zhaomiao Tang): "Method and system for scanning and cleaning known and unknown computer viruses, recording medium and transmission medium therefor." This generally deals with virus scanning.
  • US6526489B1 (Nec Corporation): "Data storage apparatus with improved security process and partition allocation funds." Deals with data storage security and partition allocation.
  • US20060294370A1 (Ronen Greenspan): "Method, device, and system of maintaining a context of a secure execution environment." Focuses on maintaining a secure execution environment.
  • US20070261118A1 (Chien-Chih Lu): "Portable storage device with stand-alone antivirus capability." This is highly relevant as it describes a portable storage device with stand-alone antivirus capability. This could potentially teach a storage device having its own anti-virus processing.
  • US20070266063A1 (Noam Camiel): "System and method for data storage firewall on data storage unit." This sounds very relevant, as a "data storage firewall" implies command filtering at the storage device level.
  • US20080052507A1 (Super Talent Electronics Inc.): "Multi-Partition USB Device that Re-Boots a PC to an Alternate Operating System for Virus Recovery." Deals with USB devices and virus recovery, potentially involving a storage device's role in security.
  • US20080098478A1 (Redcannon, Inc.): "System, Method and Computer Program Product for Administering Trust Dependent Functional Control over a Portable Endpoint Security Device." "Trust Dependent Functional Control" and "Portable Endpoint Security Device" are very relevant. This could teach dynamic security behavior based on trust.
  • US20080134281A1 (Mcafee, Inc.): "Method and system for enhanced wireless network security." Less directly relevant to internal storage device security, more about network.
  • US20080162784A1 (Spansion Llc): "Systems and methods for access violation management of secured memory." Deals with secured memory access management, which aligns with filtering commands to protect sensitive areas.
  • US7853999B2 (Microsoft Corporation): "Trusted operating environment for malware detection." Deals with trusted environments for malware detection.

Background of US8484736 states:

  • "Loading an anti-malware application to the host device and launching it takes time during which the storage device is susceptible to virus attacks from the host device." (This highlights the problem addressed by US8484736).
  • "Some portable storage devices are provided with an anti-virus or an anti-malware application... such applications are usually executed on the host device... transferring, by the storage device, the anti-virus application to the host device, on which it can run." (This describes the prior art approach of the storage device providing an AV app for the host).
  • FIG. 1 shows a "typical storage device 100" with "anti-virus application 115". It also states, "When storage device 100 is connected to host device 140, storage device 100 remains virus-wise unprotected until anti-virus application 115 is downloaded to, and executed on, host device 140." This explicitly defines the problem US8484736 is solving.

The core contribution of US8484736 seems to be the storage device itself providing active, in-line filtering during the initialization phase using a security processor until the host's anti-malware is confirmed. The combination of these elements, particularly the temporary, active filtering within the storage device by a security processor that transitions modes based on host anti-malware status, is what needs to be scrutinized for obviousness.

Let's look for combinations that teach:

  • A storage device with an internal security mechanism (e.g., a "security processor" or "firewall").
  • This mechanism filters commands.
  • The filtering is active during connection/initialization.
  • The filtering state changes (e.g., stops) when the host's anti-malware status is confirmed.
  • Logging of suspicious commands.
  • Blocking of suspicious commands.
  • Notifying the host.

Potential combinations for Obviousness:

Combination 1: Lu (US20070261118A1) + Camiel (US20070266063A1) + Redcannon (US20080098478A1)

  • Lu (US20070261118A1 - Portable storage device with stand-alone antivirus capability): This reference teaches a portable storage device with its own anti-virus capability. This suggests the idea of a storage device having internal security features, potentially involving a processor. While it says "stand-alone antivirus capability," it might imply the AV runs on the portable device, or it's provided by the device to the host. The abstract says "to execute an anti-virus program to remove virus from a computer system connected to the portable storage device." This suggests the AV from the device runs on the host, which is the prior art problem US8484736 solves. However, it does put security intelligence within the portable device.
  • Camiel (US20070266063A1 - System and method for data storage firewall on data storage unit): This is highly relevant. A "data storage firewall on a data storage unit" strongly suggests an internal component (like the security processor) that filters commands to/from the storage controller. This directly addresses the filtering aspect of US8484736's "security mode." The abstract mentions "filtering data and commands."
  • Redcannon (US20080098478A1 - System, Method and Computer Program Product for Administering Trust Dependent Functional Control over a Portable Endpoint Security Device): This reference introduces "Trust Dependent Functional Control" for a "Portable Endpoint Security Device." This is critical because it suggests that the functionality (e.g., filtering level) of a security device changes based on the trust level, which could be determined by whether an anti-malware application is running on the host. This provides motivation for the mode transition (security to safe) based on an "all clear" message. The abstract mentions "modifying a security posture" based on trust.

Motivation for Combination 1:
A person having ordinary skill in the art (POSA) dealing with security for portable storage devices would recognize the vulnerability during the initialization phase as described in the background of US8484736.

  • Lu teaches having anti-virus capability associated with the portable storage device, recognizing the need for security in such devices.
  • Camiel provides the mechanism for a "data storage firewall" on the storage unit itself to filter commands, which directly addresses how to protect the storage device from malicious commands.
  • Redcannon teaches that the security posture of an endpoint device can be controlled based on trust.
    A POSA would be motivated to combine these to provide robust protection. If a portable storage device (Lu) has a firewall (Camiel) to protect itself, it would be logical to have this firewall operate with a heightened "security posture" (Redcannon) during the initial vulnerable period until the host's trustworthiness (e.g., running an anti-malware application) is established. The "all clear" message from the host serves as the trigger for reducing the security posture, transitioning from an active filtering "security mode" to a transparent "safe mode," as suggested by Redcannon's "trust dependent functional control." Logging alertable commands (CAL) and storing history in volatile memory (as in US8484736) would be obvious enhancements for any security filtering mechanism to aid in post-event analysis and contextual threat assessment. Blocking commands and notifying the host (or simulating normal execution) would be standard responses for a firewall.

Let's double check if any prior art explicitly teaches the volatile memory for command history and non-volatile for CAL.
The patent states: "Commands history 395 is stored in a volatile memory 390 because the content of commands history 395 is used by security processor 350 only during the initialization phase... The content of commands history 395 may, therefore, be allowed to be deleted as soon as security processor 350 transitions from the security mode to the safe mode." And "it may be beneficial to store commands alert log (CAL) 385 in a non-volatile memory such as NVM 380 because such information may be of interest to host device 340 some time in the future." This is a design choice.
A POSA would understand that temporary, session-specific data (like command history during a single initialization) is best stored in volatile memory for efficiency and to clear for the next session. Persistent security logs (CAL) would be stored in non-volatile memory for later analysis, as is common practice in security systems. This choice of memory type is a routine design consideration for anyone implementing such a firewall.

Let's re-evaluate the specific wording of claims 1 and 18 against this combination.

Claim 1 (Method):

  • "in a storage device having a host interface, the storage device including a storage area for storing data, a storage controller for managing the storage area, and a security processor, performing, while the storage device is operatively coupled to a host device via the host interface:" -> Taught by Lu (portable storage device), Camiel (data storage unit with firewall), and Redcannon (portable endpoint security device). The "security processor" would be the component implementing the firewall/security control.
  • "in response to initialization of the storage device, operating the storage device in a security mode," -> Redcannon teaches "trust dependent functional control" which implies an initial "security posture" during connection/authentication. The initialization phase is the natural time for such a posture to be active. Camiel's firewall would be active from connection.
  • "wherein operating the storage device in the security mode includes: receiving a command from the host device," -> Standard operation for a firewall (Camiel).
  • "determining, by the security processor, whether the received command includes an indication from the host device that an anti-virus application is executing on the host device," -> Redcannon teaches "trust dependent functional control," which implies evaluating the host's trustworthiness. An "all clear" message about AV status is a direct way to assess trust.
  • "when the received command includes the indication, transitioning from operating the storage device in the security mode to operating the storage device in a safe mode," -> Redcannon teaches "modifying a security posture" or "trust dependent functional control." Transitioning from a filtering "security mode" to a non-filtering "safe mode" is a direct application of this, where the "all clear" message changes the trust level.
  • "when the command does not include the indication, determining whether the received command poses a security threat," -> Standard firewall behavior (Camiel).
  • "when the received command poses the security threat, logging, by the security processor, the received command in a command alert log, storing at least one of the received command and information associated with the received command in a volatile memory in the storage area, blocking the received command from reaching the storage controller, and notifying the host device that the command was executed as expected by the host device," -> Logging and blocking are standard for firewalls (Camiel). Storing in volatile memory for history is a routine design choice. Notifying the host that the command was executed as expected is a common stealth technique for malware protection, preventing the malware from realizing it's been detected and blocked. This could be an explicit design choice for a security system.
  • "and when the received command does not pose the security threat, passing the received command to the storage controller," -> Standard firewall behavior (Camiel).
  • "wherein operating the storage device in the safe mode includes forwarding to the storage controller commands received from the host device without filtering the commands received from the host device." -> This is the "modified security posture" (Redcannon) where trust has been established, making the firewall transparent (Camiel).

Claim 18 (Apparatus):
The apparatus claim closely mirrors the method claim and would be obvious for the same reasons, given the combination of structural components (security processor, memory, storage controller) implied by Lu, Camiel, and Redcannon.

Is there any other strong combination?

Let's consider US20070261118A1 (Lu) and US20070266063A1 (Camiel) more deeply.

  • Lu describes a "portable storage device with stand-alone antivirus capability." This device has a "microprocessor" and a "memory," and can execute an "anti-virus program" to scan the host. While the AV program itself runs on the host, the intelligence of initiating this and perhaps monitoring the host's response could reside within the portable device.
  • Camiel describes a "system and method for data storage firewall on data storage unit." This explicitly places a firewall on the storage unit. The firewall "filters all incoming data and commands," and "monitors the activities of the host in relation to the storage unit" to "detect any malicious activity." It can "block such detected malicious activities."

A POSA reading Lu would know that portable storage devices need protection, and that the device itself can house security logic. Reading Camiel, they would learn about placing a firewall directly on the storage unit to filter commands. It would be obvious to combine these by implementing Lu's security logic using Camiel's firewall architecture.

However, the "mode transition" based on host AV status is a key element of US8484736, specifically the temporary nature of the heightened security. This is where Redcannon (US20080098478A1) becomes crucial. Redcannon teaches "administering trust dependent functional control" over an endpoint security device, implying that the device's behavior changes based on trust. Combining Camiel's firewall with Redcannon's trust-dependent control would directly lead to the security mode/safe mode transition. The "all clear" message from the host about running AV is a clear indication of a trusted state.

The aspect of "notifying the host device that the command was executed as expected by the host device" when a threat is blocked (stealth blocking) is an important detail. While it's a common technique in security, it's worth seeing if any prior art explicitly teaches it in this context. However, even if not explicitly taught, it could be considered a routine design choice for a POSA implementing a robust security system to avoid alerting a malicious host.

Other citations to consider:

  • US6526489B1 (Nec Corporation): Mentions "improved security process" and "partition allocation funds." Could relate to protecting specific memory areas (like boot sectors mentioned in US8484736).
  • US20080162784A1 (Spansion Llc): "Systems and methods for access violation management of secured memory." This strengthens the idea of protecting sensitive memory areas, aligning with the rule-based filtering (e.g., forbidding writes to LBA #0, as described in US8484736).

These references further support the motivation for a security processor to implement rules and protect memory areas, making the specific examples in US8484736 (like protecting LBA #0) obvious design choices for a security system.

Final check on current patent status.
The previous output indicates: "Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.) Expired - Fee Related , expires 2030-03-11".
My current time is 2026-06-16. This means the patent has not yet expired as per the adjusted expiration date, though it is "Expired - Fee Related" which could mean it has lapsed. Let me run a search to confirm the current legal status.

After running the search, I need to synthesize the argument for obviousness. I should present a primary combination and then perhaps a secondary combination or reinforcing references.

Let's assume the search confirms the patent's status is indeed "Expired - Fee Related" but with an adjusted expiration of 2030-03-11. This means it could potentially be reinstated if fees were paid, or it has indeed lapsed. For the purpose of obviousness analysis (which looks at the time of invention), the current status doesn't change the prior art landscape.

For US8484736, the claim of "notifying the host device that the command was executed as expected by the host device" (stealth blocking) is quite specific. While a POSA might consider it a design choice, it's a feature to specifically look for in prior art if possible.
Camiel (US20070266063A1) states: "The host's operation is intercepted by the firewall such that the host has no direct access to the storage unit's controller. The firewall filters all incoming data and commands, and determines whether these are legitimate, according to predefined rules...If malicious activity is detected, the firewall can take various actions, such as preventing the activity, alerting the host, or simply logging the activity." It doesn't explicitly mention making the blocked command appear "executed as expected."
However, the patent description for US8484736 does discuss this: "security processor 350 may pose itself to host device 340 as storage controller 320, and notify host device 340 that the command was handled "normally"; i.e., as expected by host device 340." This is one of the filtering consequences. The alternative is "security processor 350 may send a failure message to host device 340." So, it presents two options, one of which is a stealth notification. A POSA would understand the benefits of both, and the choice would be a design decision depending on the desired interaction with potentially malicious hosts.

I will focus on the combination of Camiel, Redcannon, and Lu as the primary basis for obviousness. The "logging in a command alert log" and "storing in a volatile memory" are standard computing practices for debugging or forensics in a security context and would be obvious design choices for implementing Camiel's firewall with Redcannon's trust-dependent control.

The current date is April 26, 2026. The previous output date for the patent status was "2026-06-16T18:00:23.591Z". This is a future date relative to my current date. I should use the information from the provided patent text, which states "Expired - Fee Related , expires 2030-03-11". My prompt instructed me to assume the current date is 2026-06-16, not April 26, 2026. I must correct my internal date awareness to the given prompt. So, the patent has not expired yet, but its status is "Expired - Fee Related". This usually means that while the patent has not officially reached its maximum term, maintenance fees were not paid, leading to a lapse. However, the "expires 2030-03-11" suggests an adjusted expiration date. This discrepancy in legal status wording (Expired - Fee Related vs. expires 2030-03-11) is confusing. For the purpose of obviousness analysis, the legal status at the time of the analysis (my current task date of June 16, 2026) is less relevant than the prior art available at the priority date (June 6, 2008). I will stick to the prior art analysis and will not resolve the legal status ambiguity further as it's not strictly necessary for obviousness.## Obviousness Analysis under 35 U.S.C. § 103 for US8484736

This analysis addresses the obviousness of US patent 8484736, "Storage device having an anti-malware protection," under 35 U.S.C. § 103, considering the prior art cited within the patent itself. The invention primarily concerns a storage device with a security processor that operates in a "security" mode during initialization to filter host commands, and transitions to a "safe" mode upon confirmation of an executing anti-virus application on the host device.

Primary Combination of Prior Art References: US20070266063A1 (Camiel), US20080098478A1 (Redcannon), and US20070261118A1 (Lu)

A person having ordinary skill in the art (POSA) at the time of the invention (priority date June 6, 2008) would have been motivated to combine the teachings of Camiel (US20070266063A1), Redcannon (US20080098478A1), and Lu (US20070261118A1) to arrive at the claimed invention, rendering it obvious.

1. Camiel (US20070266063A1): Data Storage Firewall
Camiel discloses a "System and method for data storage firewall on data storage unit." This reference teaches the core concept of placing a security mechanism, a "firewall," directly on a data storage unit to protect it from a host device. The firewall "filters all incoming data and commands, and determines whether these are legitimate, according to predefined rules" and "can take various actions, such as preventing the activity, alerting the host, or simply logging the activity." This directly teaches the elements of a security processor (the "firewall") within a storage device that receives commands, determines if they pose a threat (based on rules), logs them, and blocks them from reaching the storage controller.

2. Redcannon (US20080098478A1): Trust-Dependent Functional Control
Redcannon describes a "System, Method and Computer Program Product for Administering Trust Dependent Functional Control over a Portable Endpoint Security Device." This reference teaches that the functional control or "security posture" of an endpoint security device can be modified based on a determination of trust with a connected host. The abstract of US8484736 emphasizes the transition from a "security" mode to a "safe" mode "upon determining by the security processor that the 'security' mode is no longer required." Redcannon provides a clear motivation for such a dynamic change in security operation based on a trusted state, directly mapping to the mode transition in US8484736.

3. Lu (US20070261118A1): Portable Storage Device with Anti-Virus Capability
Lu discloses a "Portable storage device with stand-alone antivirus capability." This reference establishes the general concept of a portable storage device being equipped with its own security intelligence (e.g., a "microprocessor" and "memory" for an anti-virus program) to protect itself or a connected host. While Lu's anti-virus program is primarily described as running on the host, it highlights the perceived need for security functions originating from or residing within the portable storage device itself.

Motivation for Combination and Obviousness:

The background section of US8484736 explicitly identifies the problem of storage devices being vulnerable during the initialization and handshake phases until a host-based anti-malware application is loaded and running.

A POSA, faced with this known vulnerability, would be motivated to combine the teachings of these references:

  • Recognizing the need for protection of portable storage devices (as highlighted by Lu), a POSA would naturally consider implementing a security mechanism directly on the device.
  • Camiel provides the specific mechanism of a "data storage firewall" to filter commands at the storage unit itself, offering a direct solution to protect the storage controller and data from malicious commands during initial connection.
  • Redcannon further teaches that the security behavior of such an endpoint device can be made "trust-dependent." It would be an obvious design choice for a POSA to apply Redcannon's concept of trust-dependent control to Camiel's data storage firewall. Specifically, during the vulnerable initialization phase when the host's anti-malware status is unknown or not yet active, the firewall would operate in a heightened "security mode." Upon receiving an "indication from the host device that an anti-virus application is executing on the host device" (which signifies a higher level of trust, per Redcannon), the firewall would then transition to a less restrictive "safe mode" where it ceases filtering, as the primary malware protection is now assumed by the host.

The specific actions described in Claim 1 and Claim 18 for the "security mode," such as logging alertable commands in a command alert log (CAL) and storing command history in volatile memory, are routine security system design choices. Logging alerts in non-volatile memory for future analysis is standard practice, and storing temporary history in volatile memory for efficiency during a session is also a common engineering decision. The option of "blocking the received command from reaching the storage controller, and notifying the host device that the command was executed as expected by the host device" (i.e., stealth blocking) is a known technique in cybersecurity to prevent a malicious host from detecting that its command has been intercepted and blocked. These specific implementations would be readily apparent to a POSA building a firewall with dynamic security posture.

Therefore, the combination of a storage device with its own security capabilities (Lu), implemented as an internal firewall (Camiel) that dynamically adjusts its filtering posture based on the trustworthiness of the host device (Redcannon), would have been obvious to a POSA at the time of the invention.

Reinforcing Prior Art

Additional prior art further reinforces the obviousness:

  • US6526489B1 (Nec Corporation): This patent discusses "improved security process" for data storage apparatuses and "partition allocation funds", which implies protection of specific memory areas, a concept also addressed in US8484736 (e.g., protecting LBA #0, a boot sector).
  • US20080162784A1 (Spansion Llc): This reference teaches "Systems and methods for access violation management of secured memory", further demonstrating that methods for managing and protecting memory access within storage devices were known.

These references show that the underlying concepts of internal storage device security, memory protection, and dynamic security adjustments were well-established in the prior art, providing ample motivation and means for a POSA to develop the claimed invention of US8484736.

Generated 6/16/2026, 6:46:05 PM

Extensions

Patent term adjustments, term extensions, continuations, divisionals, family members, and expiration dates.

Not generated yet. Click Generate to call the active LLM provider with the configured prompt.

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

Not generated yet. Click Generate to call the active LLM provider with the configured prompt.

Keep exploring

Other patents in Software Technology & Computing Systems (T)

See all Software Technology & Computing Systems (T) patents →