US 8327051

Here's a concise summary of US Patent 8327051:

US Patent Number: US8327051B2

Title: Portable handheld memory card and methods for use therewith

Current Assignee: Palisade Technologies LLP (as of August 15, 2024)

Original Assignee: SanDisk Technologies LLC

Inventor: Myeong Joon Kang

Filing Date: November 20, 2007

Issue Date: December 04, 2012

Abstract:
A portable handheld memory card is described, featuring a Universal Serial Bus (USB) port, USB controller circuitry, an input/output (I/O) port, memory, and decompression circuitry for compressed data. The card's housing exposes both the USB and I/O ports, which are positioned to allow insertion in the same direction regardless of whether the host device uses a USB or I/O port. The patent also describes embodiments with decryption circuitry for encrypted data, a power management unit, a host interface module, and circuitry to manage memory read/write operations. The I/O port may be a Secure Digital (SD) port, and the memory can be Flash memory.

Plain-Language Overview of Independent Claims:

• Independent Claim 1 (Portable Handheld Memory Card):
  This claim describes a portable memory card that has two distinct sets of electrical contacts on the same end: one for a Universal Serial Bus (USB) connection and another for a general Input/Output (I/O) connection. The card contains USB control circuitry connected to its USB pins, and I/O control circuitry connected to its I/O pins. It also has internal memory accessible via both ports, all housed within a casing that exposes these ports. A key feature is that the USB and I/O ports are arranged such that the card can be inserted into a host device in the same orientation, whether the host supports the USB port or the I/O port. Furthermore, if the I/O port is connected to a host, at least one pin of the USB port is not connected, and vice versa.

• Independent Claim 9 (Method for Data Handling with Memory Card - Type 1):
  This claim outlines a method performed by a portable memory card (as described in Claim 1) that involves managing compressed data. The method includes reading compressed data from the card's memory, decompressing it into uncompressed data, and then transmitting this decompressed data through the I/O port. Separately, the method also covers taking the original compressed data, converting it into a format suitable for the USB port, and transmitting that converted data through the USB port.

• Independent Claim 16 (Method for Data Handling with Memory Card - Type 2):
  This claim describes another method for a portable memory card (as described in Claim 1), focusing on flexible data transmission. The method involves reading data from the memory, then determining whether this data should be sent out through the USB port or the I/O port. Finally, the data is transmitted to a host device through the chosen port.

Uncertainty Regarding CAFC Dockets:
As of April 26, 2026, searches of CAFC 2026 dockets did not return any specific cases directly involving US8327051B2. The provided patent information indicates an Inter Partes Review (IPR) case (IPR2025-01008) was filed but "Not Instituted - Procedural," and a US case was filed in the Texas Western District Court, but these are not CAFC proceedings.

US Patent 8327051 has been involved in at least one litigation case.

Here is the known litigation involving US Patent 8327051:

• Plaintiff(s): Palisade Technologies, LLP
• Defendant(s): Micron Technology, Inc., Micron Semiconductor Products, Inc., and Micron Technology Texas LLC
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 7:24-cv-00262 (based on the format provided in other search results, this is a likely case number, although not explicitly stated as such for this specific patent in all snippets, it's consistent with "US case filed in Texas Western District Court") - Self-correction: The Google Patents link lists "US case filed in Texas Western District Court" and the Unified Patents link for the IPR states "IPR2025-01008 filed (Not Instituted - Procedural)". The Bloomberg Law article and the unifiedpatents.com link provide the case number 7:24-cv-00262.
• Filing Date: October 16, 2024
• Outcome/Current Status: Dismissed with prejudice on January 26, 2026. This means Palisade Technologies, LLP is permanently barred from re-filing the same infringement claims against Micron Technology, Inc. in any forum. Micron's counterclaims and defenses were dismissed without prejudice. No damages or injunctive relief were reported.

It is also worth noting that an Inter Partes Review (IPR) case, IPR2025-01008, was filed against US8327051, but it was "Not Instituted - Procedural".US Patent 8327051 has been involved in the following litigation:

Case 1:

• Plaintiff(s): Palisade Technologies, LLP
• Defendant(s): Micron Technology, Inc., Micron Semiconductor Products, Inc., and Micron Technology Texas LLC
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 7:24-cv-00262
• Filing Date: October 16, 2024
• Outcome/Current Status: The case was dismissed with prejudice on January 26, 2026. This means Palisade Technologies, LLP is permanently barred from re-filing the same infringement claims against Micron Technology, Inc., and its units in any forum. Micron's counterclaims and defenses were dismissed without prejudice. No damages or injunctive relief were reported.

Additionally, an Inter Partes Review (IPR) case, IPR2025-01008, was filed against US8327051 but was "Not Instituted - Procedural."

Proceedings overview

There is one AIA trial proceeding on file for US patent 8327051, with a status of "Discretionary Denial". This means the patent has not been challenged on the merits at the PTAB, leaving all claims untested and potentially susceptible to future challenges.

IPR2025-01008 — Micron Technology Inc. et al. v. Myeong Joon Kang

• Type: Inter Partes Review
• Filed: 2025-05-30
• Status: Discretionary Denial - The PTAB declined to institute the IPR.
• Judge panel: Not publicly available yet for this procedural stage.
• Petition grounds: Not publicly available due to discretionary denial.
• Institution decision: Denied (Date not specified in the provided data). The PTAB exercised its discretion to deny institution, meaning the merits of the challenge were not fully considered.
• Final Written Decision (if issued): Not applicable, as institution was denied.
• Settlement / termination: Not applicable, as institution was denied.
• Appeal: No Federal Circuit appeal as there was no Final Written Decision.
• Defensive value: The patent owner prevailed at the institution stage, meaning an IPR-based defense will be harder for the petitioner (Micron Technology Inc. et al.) and any parties in privity with them, as they are estopped from raising the same or reasonably could have raised grounds in future PTAB proceedings or district court litigation. For other potential defendants, all claims remain untested by the PTAB.

Strategic summary

All claims of US8327051 are currently UNTESTED by the PTAB. The single IPR filed, IPR2025-01008, was denied institution on discretionary grounds, meaning the PTAB did not reach the merits of the validity challenge.

The estoppel landscape is limited to the petitioner, Micron Technology Inc. et al., and their privies. Under 35 U.S.C. § 315(e)(2), they are barred from asserting in any other PTAB proceeding or civil action any ground that they raised or reasonably could have raised in IPR2025-01008. For other potential defendants, all prior-art grounds remain available for challenge, either through new IPR petitions or in district court. There is no pattern of aggressive PTAB appeals by the patent owner, as no Final Written Decision has been issued.

Recommended next steps

Since IPR2025-01008 was denied institution on discretionary grounds, no claims were invalidated. As a defendant facing assertion of this patent, it is important to understand that the patent's validity has not been substantively tested at the PTAB. Therefore, a thorough prior art search and analysis would be a crucial next step to identify potential grounds for a new IPR petition or for use in district court litigation.

The current status for IPR2025-01008 is "Discretionary Denial" and was last modified on 2026-02-20, which suggests the institution decision has already been made. No further trial-stage milestones are pending for this specific proceeding.

Inventors

• Myeong Joon Kang (SanDisk Technologies LLC at the time of filing)

Original assignee

The original assignee was SanDisk Technologies LLC. SanDisk was a prominent manufacturer of flash memory products, including a wide range of memory cards (SD, microSD, CompactFlash, etc.), USB flash drives, and solid-state drives. They shipped numerous products embodying memory card technologies. SanDisk Technologies LLC is currently an operating subsidiary of Western Digital Corporation, having been acquired in 2016.

Assignment timeline

• 2007-11-16 (executed) / recorded 2007-11-20 — Reel 020176/0369

  • Conveyance: Assignment
  • Assignor: KANG, MYEONG JOON
  • Assignee: SANDISK CORPORATION
  • Correspondent: BEYER WEAVER & THOMAS, LLP, P. O. BOX 70250, OAKLAND, CA 94612-0250
  • Context: Transfer from inventor to original assignee.

• 2011-04-04 (executed) / recorded 2011-05-13 — Reel 026276/0538

  • Conveyance: Assignment
  • Assignor: SANDISK CORPORATION
  • Assignee: SANDISK TECHNOLOGIES INC.
  • Correspondent: SANDISK CORPORATION, 601 MCCARTHY BOULEVARD, MILPITAS, CA 95035
  • Context: Internal reorganization / transfer between related corporate entities.

• 2016-05-16 (executed) / recorded 2016-05-25 — Reel 038809/0600

  • Conveyance: Change of Name
  • Assignor: SANDISK TECHNOLOGIES INC
  • Assignee: SANDISK TECHNOLOGIES LLC
  • Correspondent: SANDISK TECHNOLOGIES LLC, 601 MCCARTHY BLVD., MILPITAS, CA 95035
  • Context: Change of name for an existing assignee.

• 2024-08-12 (executed) / recorded 2024-08-15 — Reel 068301/0100

  • Conveyance: Assignment
  • Assignor: SANDISK TECHNOLOGIES LLC
  • Assignee: PALISADE TECHNOLOGIES, LLP
  • Correspondent: THE SMALL PATENT LAW GROUP LLP, 225 S. MERAMEC AVE., SUITE 725, ST. LOUIS, MO 63105. This correspondent has appeared on other patent assignment records for NPEs.
  • Context: Transfer to an asserting entity.

Timeline diagram

timeline
    title Ownership of US 8327051
    2007 : Filed by SanDisk Technologies LLC
    2011 : Assigned to SanDisk Technologies Inc
    2012 : Issued
    2016 : Name changed to SanDisk Technologies LLC
    2024 : Assigned to Palisade Technologies LLP
         : First infringement suit filed

NPE / troll-pattern signals

1. Shell-entity transfer — present. The transfer from SanDisk Technologies LLC to Palisade Technologies, LLP on 2024-08-12 (recorded 2024-08-15, Reel 068301/0100) indicates a shell entity. Palisade Technologies, LLP's business is understood to be patent assertion, and no products in commerce under this name are known.
2. Known asserter in the chain — present. Palisade Technologies, LLP is a known patent asserter (NPE). They are listed by Unified Patents as a high-frequency plaintiff.
3. Repeat correspondent across the chain — present. The correspondent "THE SMALL PATENT LAW GROUP LLP" (Reel 068301/0100) is a firm frequently associated with patent assertion entities. While they may represent operating companies as well, their appearance here in connection with a known NPE is a signal.
4. Cascading transfers — not present. There are no multiple consecutive assignments through chained LLCs within a short period.
5. Pre-litigation transfer — present. The assignment to Palisade Technologies, LLP was executed on 2024-08-12 and recorded on 2024-08-15 (Reel 068301/0100). The first infringement suit against Micron Technology, Inc. was filed by Palisade Technologies, LLP on October 16, 2024, which is approximately two months after the assignment. This falls within the 6-month window indicating a pre-litigation transfer.
6. Bankruptcy fire-sale — not present. SanDisk Technologies LLC (and its parent Western Digital) are active operating companies and there is no indication of a bankruptcy fire-sale.
7. Privateering — unclear. While the patent was transferred from an operating company (SanDisk/Western Digital) to an NPE, there's no explicit public information to confirm whether SanDisk/Western Digital is benefitting from the assertion against their competitors, which would classify it as privateering.
8. Defensive aggregator (anti-NPE) — not present. The chain ends with Palisade Technologies, LLP, which is an asserting entity, not a defensive aggregator.

Verdict

NPE — high confidence. The presence of multiple strong signals, including the transfer to a known patent asserter (Palisade Technologies, LLP on Reel 068301/0100), the pre-litigation timing of this transfer (approximately two months before the first suit), and the use of a correspondent firm known for NPE representation (THE SMALL PATENT LAW GROUP LLP, Reel 068301/0100), strongly indicates an NPE pattern.

USPTO Assignment Center Search for US8327051

To identify the most relevant prior art for US Patent 8327051, I will examine each patent citation listed in the patent document. For each, I will provide the full citation, publication/filing date, a brief description, and which claim(s) it potentially anticipates under 35 U.S.C. § 102.

Based on the provided patent text, here are the cited prior art patents:

Cited Patent References:

1. US20020186842A1

   • Full Citation: US20020186842A1 - System, method, and device for playing back recorded audio, video or other content from non-volatile memory cards, compact disks, or other media.
   • Priority Date: 2000-12-07
   • Publication Date: 2002-12-12
   • Brief Description: This patent application describes a system, method, and device for playing back recorded audio, video, or other content from non-volatile memory cards, compact disks, or other media. It focuses on the ability to play content directly from such storage, potentially involving decompression and decryption on the playback device.
   • Potential Anticipated Claims: This reference might anticipate claims related to reading data from memory, decrypting encrypted data, and decompressing compressed data for playback, particularly within a memory device context. Therefore, it could potentially anticipate aspects of claims 9, 10, 16, 17, and 18, especially concerning the processing of encrypted or compressed data within a memory card system for playback.

2. US20030212848A1

   • Full Citation: US20030212848A1 - Double interface CF card.
   • Priority Date: 2002-05-09
   • Publication Date: 2003-11-13
   • Brief Description: This patent application describes a CompactFlash (CF) card with a "double interface," suggesting the integration of multiple connectivity options on a single memory card.
   • Potential Anticipated Claims: This reference directly addresses memory cards with multiple interfaces. It could potentially anticipate Claim 1, particularly regarding a memory card having both a USB port and an I/O port, and their arrangement.

3. US20040083378A1

   • Full Citation: US20040083378A1 - Method, systems and devices for handling files while operated on in physically different computer devices.
   • Priority Date: 2002-10-29
   • Publication Date: 2004-04-29
   • Brief Description: This patent application describes methods, systems, and devices for handling files, allowing them to be operated on in physically different computer devices. This implies portability and potentially adaptive interfacing.
   • Potential Anticipated Claims: This reference might broadly anticipate the concept of a portable memory card interacting with different host devices, which is a core idea behind Claim 1 and the methods of Claims 9 and 16. The specific "handling files" might touch upon data transfer and management, relevant to Claims 9 and 16.

4. US7376773B2

   • Full Citation: US7376773B2 - Multi-standard protocol storage devices and methods of operating the same.
   • Priority Date: 2003-07-04
   • Publication Date: 2008-05-20
   • Brief Description: This patent describes multi-standard protocol storage devices and methods for operating them, indicating a device capable of communicating using various protocols.
   • Potential Anticipated Claims: This reference is highly relevant to Claim 1 due to its focus on multi-standard protocol storage devices. It could anticipate the presence of both USB and I/O ports with their respective controllers, and the ability of a memory card to interface using different protocols as described in Claims 9 and 16.

5. US20050063540A1

   • Full Citation: US20050063540A1 - Digital media cartridge system and method.
   • Priority Date: 2003-07-23
   • Publication Date: 2005-03-24
   • Brief Description: This patent application describes a digital media cartridge system and method, which suggests a portable storage device for media content.
   • Potential Anticipated Claims: Similar to US20020186842A1 and US20040083378A1, this could broadly anticipate the memory card's function as a portable media storage device, touching upon the scope of Claims 1, 9, and 16, especially concerning the handling of data (audio/video).

6. US7287703B2

   • Full Citation: US7287703B2 - Removable memory cards including USB and other controllers, connectors, and methods of operating same.
   • Priority Date: 2003-07-23
   • Publication Date: 2007-10-30
   • Brief Description: This patent describes removable memory cards that include USB and other controllers, connectors, and associated methods of operation.
   • Potential Anticipated Claims: This is highly relevant to Claim 1, as it explicitly mentions removable memory cards with both USB and "other" (I/O) controllers and connectors. It directly addresses the core hardware components of Claim 1, and the methods of operation would cover the data handling aspects of Claims 9 and 16.

7. US20060084287A1

   • Full Citation: US20060084287A1 - Memory card with two standard sets of contacts and a contact covering mechanism.
   • Priority Date: 2004-04-16
   • Publication Date: 2006-04-20
   • Brief Description: This patent application describes a memory card featuring two standard sets of contacts and a mechanism for covering these contacts.
   • Potential Anticipated Claims: This reference directly anticipates aspects of Claim 1 related to a memory card having two distinct sets of pins (e.g., USB and I/O) and how they are exposed or protected. The "same card-insertion direction" feature of Claim 1 might distinguish it, but the fundamental idea of dual-interface contacts is present.

8. US7433994B2

   • Full Citation: US7433994B2 - On-device data compression to increase speed and capacity of flash memory-based mass storage devices.
   • Priority Date: 2004-12-07
   • Publication Date: 2008-10-07
   • Brief Description: This patent describes on-device data compression to enhance the speed and capacity of flash memory-based mass storage devices.
   • Potential Anticipated Claims: This reference is highly relevant to Claim 3, which claims decompression circuitry, and to Claim 9 and Claim 18, which involve decompressing data on the memory card. The focus on "on-device data compression" directly relates to the concept of the memory card itself performing compression/decompression.

9. US20060177064A1

   • Full Citation: US20060177064A1 - Secure memory card with life cycle phases.
   • Priority Date: 2005-02-07
   • Publication Date: 2006-08-10
   • Brief Description: This patent application describes a secure memory card that incorporates life cycle phases, likely implying features for managing encrypted or protected data.
   • Potential Anticipated Claims: This reference could potentially anticipate Claim 2 (decryption circuitry) and Claim 10 (decrypting encrypted data), as "secure memory card" and "life cycle phases" often involve encryption and decryption mechanisms to protect data access and usage.

10. US7491076B2

    • Full Citation: US7491076B2 - Rotatable memory card with improved locking mechanism.
    • Priority Date: 2006-04-18
    • Publication Date: 2009-02-17
    • Brief Description: This patent describes a rotatable memory card with an improved locking mechanism.
    • Potential Anticipated Claims: This patent seems to focus on the mechanical aspects of a memory card's physical form factor and locking mechanism. It does not appear to directly anticipate the electrical or functional claims of US8327051, particularly Claim 1, 9, or 16, beyond the general concept of a "memory card."

11. US20080071940A1

    • Full Citation: US20080071940A1 - Device of identifying host protocol and smart card including the same.
    • Priority Date: 2006-07-21
    • Publication Date: 2008-03-20
    • Brief Description: This patent application describes a device for identifying a host protocol, and a smart card incorporating such a device. This implies a memory card capable of recognizing and adapting to different host interfaces.
    • Potential Anticipated Claims: This reference is highly relevant to the concept of a memory card interfacing with different host devices using different protocols, as described in Claim 1 and implied in the methods of Claims 9 and 16. The "identifying host protocol" directly relates to the card's ability to determine which port to use for communication.

Obviousness Analysis of US Patent 8327051 under 35 U.S.C. § 103

This analysis identifies combinations of prior art references that would render the independent claims of US Patent 8327051 obvious to a person having ordinary skill in the art (PHOSITA) at the time of the invention (priority date: November 20, 2007). The motivation to combine these references generally stems from well-known design objectives such as improving user convenience, enhancing device versatility, offloading processing from host devices, and addressing known limitations in handling protected or compressed media.

Obviousness of Independent Claim 1: Portable Handheld Memory Card

Claim 1: A portable handheld memory card comprising a Universal Serial Bus (USB) port, USB controller circuitry, an input/output (I/O) port, I/O controller circuitry, a memory, and a housing exposing the ports; wherein the USB port and the I/O port are positioned on a same end to allow a same card-insertion direction irrespective of whether a host device comprises a mating USB port or a mating I/O port; and wherein the USB port and the I/O port are positioned such that when the I/O port is electrically connected with the host device, at least one of the first set of pins of the USB port is not electrically connected to the host device, and when the USB port is electrically connected to the host device, at least one of the second set of pins of the I/O port is not electrically connected to the host device.

Combination of Prior Art References:

1. "SanDisk Ultra II SD Plus Cards" (Non-Patent Citation, NPL): This non-patent literature describes existing Secure Digital (SD) Plus cards. The US8327051 patent specification explicitly acknowledges this prior art, stating, "The USB port 102... may include a USB connector such as on a Secure Digital Plus memory card." This reference would disclose a portable handheld memory card comprising:

   • A USB port (with a first set of pins).
   • An I/O port (specifically, an SD port with a second set of pins).
   • A memory in communication with both ports.
   • A housing storing the memory and exposing both the USB and I/O ports.
   • The inherent ability of such a card to interface with either an SD host device or a USB host device.

2. US7287703B2 ([[Samsung Electronics Co.](/litigations/by-defendant/Samsung%20Electronics%20Co.), Ltd.](/litigations/by-plaintiff/Samsung%20Electronics%20Co.%2C%20Ltd.)) and/or US7376773B2 (Samsung Electronics Co., Ltd.): These patents disclose removable memory cards that include both USB and "other" (I/O) controllers, connectors, and methods for operating them. US7287703B2, for example, describes "removable memory cards including USB and other controllers".

   • A PHOSITA would find it obvious to integrate into the SanDisk SD Plus card the necessary on-board controller circuitry for each interface: USB controller circuitry electrically connected with the USB port's pins, and I/O (SD) controller circuitry electrically connected with the SD port's pins. This is a standard design choice for multi-interface storage devices to manage data transfer protocols internally, as taught by these Samsung patents.

Motivation to Combine and Obviousness Reasoning:

A PHOSITA, aiming to create a highly versatile and user-friendly memory card, would be motivated to combine the dual-interface capability of known SD Plus cards with integrated controllers as taught by the Samsung references.

Regarding the specific physical arrangement limitations in Claim 1:

• "positioned on a same end to allow a same card-insertion direction irrespective of whether a host device comprises a mating USB port or a mating I/O port": Given the existence of dual-interface cards, a PHOSITA would be motivated to improve user convenience. While existing SD Plus cards may have implemented USB connectors via different mechanisms (e.g., side-mounted or flip-out), the design goal of simplifying insertion is obvious. Arranging the contacts for both the USB and I/O ports on the same physical end of the card, such that the card can be inserted with a consistent orientation into either a dedicated USB slot or a dedicated I/O (SD) slot (where the slot itself is configured to engage only the relevant contacts), would be an obvious engineering optimization for user experience. This design choice avoids the need for users to reorient the card or use external adapters.
• "when the I/O port is electrically connected with the host device, at least one of the first set of pins of the USB port is not electrically connected to the host device, and when the USB port is electrically connected to the host device, at least one of the second set of pins of the I/O port is not electrically connected to the host device": This condition is an inherent and obvious consequence of designing two distinct physical interfaces (USB and SD) into a single card. If a card with separate physical contact sets for USB and SD is inserted into an SD-only host port, only the SD pins will make electrical contact, leaving the USB pins disengaged from the host. The same applies in reverse for insertion into a USB-only host port. This is a natural result of mating connectors and distinct pin layouts, not an inventive step.

Therefore, the combination of "SanDisk Ultra II SD Plus Cards" and US7287703B2 (or US7376773B2), driven by the obvious desire for improved user convenience and efficient on-card protocol handling, would render Claim 1 obvious.

Obviousness of Independent Claim 9: Method for Data Handling with Memory Card - Type 1

Claim 9: A method performed by a portable handheld card (as described in Claim 1) comprising reading compressed data from the memory; decompressing the compressed data to decompressed data; transmitting the decompressed data on the I/O port; converting the compressed data to first converted data for transmission on the USB port; and transmitting the first converted data on the USB port.

Combination of Prior Art References:

1. The Memory Card of Obvious Claim 1: Provides the base hardware platform with dual interfaces, on-card USB and I/O controllers, and memory.
2. US7433994B2 (Ocz Technology Group, Inc.): This patent describes "On-device data compression to increase speed and capacity of flash memory-based mass storage devices". While focused on compression, the concept of on-device processing of data for storage efficiency and offloading host tasks is clearly taught. For multimedia content, on-device decompression is the complementary function to enable playback on simpler host devices. The US8327051 patent itself states a problem in the background: "accessing compressed data stored on existing memory cards may require that the connected electronic device include decompression capability. For example, playing back a song compressed in the MP3 format that is stored on an existing memory card may require an audio player with MP3 decompression circuitry. Such a player may be expensive and complex."

Motivation to Combine and Obviousness Reasoning:

A PHOSITA would be motivated to integrate data decompression capabilities (as broadly taught by references like US7433994B2 concerning on-device data processing, or general knowledge in multimedia playback) into the versatile dual-interface memory card of Claim 1. This integration directly addresses the known problem of requiring expensive and complex decompression circuitry in host devices, as described in the '051 patent's own background. By performing decompression on the card, the memory card enhances its utility and compatibility with a wider range of simpler playback devices.

• "reading compressed data from the memory": A standard operation for any memory card.
• "decompressing the compressed data to decompressed data": This step, performed on the card, would be an obvious application of known decompression techniques by a PHOSITA, motivated by the desire to alleviate processing burdens on host devices, as highlighted in the background of US8327051.
• "transmitting the decompressed data on the I/O port": This is a standard function of the card's I/O controller once data is prepared.
• "converting the compressed data to first converted data for transmission on the USB port" and "transmitting the first converted data on the USB port": These are standard functions of the card's USB controller and USB port for data transfer, which would be present in the card of Claim 1.

Thus, performing on-card decompression and routing the decompressed data through the I/O port, or routing the original compressed data (or converted version) through the USB port, would be obvious to a PHOSITA combining the multi-interface card with known on-device data processing techniques to enhance device functionality and user experience.

Obviousness of Independent Claim 16: Method for Data Handling with Memory Card - Type 2

Claim 16: A method performed by a portable handheld card (as described in Claim 1) comprising reading data from the memory; determining whether the data is to be transmitted via the USB port or I/O port; and transmitting the data to the host device via the determined port.

Combination of Prior Art References:

1. The Memory Card of Obvious Claim 1: Provides the base hardware platform with dual interfaces, on-card USB and I/O controllers, and memory.
2. US20080071940A1 (Samsung Electronics Co., Ltd.): This patent discloses a "Device of identifying host protocol and smart card including the same". This reference explicitly teaches methods for a card to determine the protocol of a connected host.

Motivation to Combine and Obviousness Reasoning:

A PHOSITA would be motivated to incorporate intelligent port selection logic (as taught by US20080071940A1) into the dual-interface memory card derived from Claim 1. For a device designed to connect to different host interfaces, the ability to automatically detect which interface the host is expecting and route data accordingly is a fundamental and obvious requirement for proper operation and user convenience.

• "reading data from the memory": A standard operation for any memory card.
• "determining whether the data is to be transmitted via the USB port or I/O port": This step is directly taught by US20080071940A1, which describes a mechanism for a card to identify the host protocol. This identification process inherently leads to the determination of which port (USB or I/O) should be used for transmission.
• "transmitting the data to the host device via the determined port": This is a standard function of the selected port's controller, which would be present in the card of Claim 1.

Therefore, the method of reading data, determining the appropriate transmission port based on host detection (as in US20080071940A1), and then transmitting data through that port would be obvious to a PHOSITA when applied to a dual-interface memory card as derived from Claim 1.

Additional Considerations for Dependent Claims:

• Decryption (Claim 2, 10, 17): US20060177064A1 (Micky Holtzman) describes a "Secure memory card with life cycle phases" that can handle secure or DRM-protected content. The '051 patent's background discusses the limitations of DRM-protected content on existing cards. A PHOSITA would be motivated to integrate on-card decryption capabilities into the memory card to enable playback of DRM-protected content independently of the host device, addressing a clear market need and a problem identified in the patent itself.
• Power Management (Claim 4, 11): The inclusion of a power management unit or converting voltage (e.g., from USB Vbus) is a standard engineering practice for any electronic device that receives power from an external source and needs to regulate it for internal components.
• Host Interface Module (Claim 5, 12): The host interface module (or I/O controller circuitry) is explicitly part of Claim 1 and necessary for communicating with the I/O port.
• Control Read/Write Operations (Claim 6, 13): Circuitry configured to control read and write operations to memory is fundamental to any memory device and is universally known.
• Secure Digital (SD) Port (Claim 7, 14, 20): The SD Plus card (NPL) clearly specifies an SD port, which is a common I/O port.
• Flash Memory (Claim 8, 15, 21): The use of Flash memory as the storage medium is a ubiquitous and obvious choice for portable memory cards.
• Parallel Pins, Different Layout (Claim 23, 24, 25): These describe design choices for the physical arrangement of the pins, which would be routine design optimizations for a PHOSITA trying to implement a compact dual-interface card on a single end, as previously discussed for Claim 1.
• Separation of USB and I/O Controller Circuitry/Pins (Claim 26, 27): The non-connection between the specific pins/data lines of one port and the controller of the other port is inherent to having distinct, independently controlled interfaces, as taught by the Samsung multi-controller patents.

To accurately detail patent term adjustments (PTA), patent term extensions (PTE), continuation/divisional applications, and the projected expiration date for US patent 8327051, I would typically need to directly access the patent's file history in the USPTO's Patent Center or Public Search tools. However, as an AI, I cannot directly interact with these live databases.

Based on the provided patent text and general knowledge of patent law, here's what can be inferred and what would require direct USPTO record access:

For US Patent 8327051:

• Patent Term Adjustments (PTA):
  PTA is granted to compensate for delays caused by the USPTO during the prosecution of a patent application. The patent document itself does not explicitly state any PTA awarded. To determine if any PTA was granted, and the duration of such adjustment, the patent's prosecution history on USPTO Patent Center would need to be reviewed.

• Patent Term Extensions (PTE):
  PTE is awarded to compensate for delays incurred in obtaining regulatory approval on a patented product, typically for pharmaceutical products. The patent's subject matter ("Portable handheld memory card and methods for use therewith") does not suggest it would be eligible for PTE, as it's unlikely to require regulatory approval under 35 U.S.C. § 156. However, a definitive answer would require examining the patent's official file for any PTE requests or grants.

• Continuation Applications, Divisional Applications, and Related Family Members:
  The patent lists "US11/986,389" as its application number and "US20090132739A1" as an "Other version," which is a publication of the patent application. This indicates that US8327051B2 is likely a direct grant from application US11/986,389.

  • Continuation Application: A continuation application allows an applicant to pursue broader, narrower, or differently structured claims from a parent application, using the same specification, as long as the parent application has not issued or been abandoned.
  • Divisional Application: A divisional application is filed when the USPTO issues a "restriction requirement," meaning the original application contained multiple distinct inventions. The applicant can then pursue the non-elected inventions in a divisional application.
  • The provided information does not explicitly state that US8327051B2 is a continuation or divisional of an earlier application, other than referring to its own application number US11/986,389. To definitively identify any continuation or divisional applications, or other related family members (beyond the published application), a detailed search of the patent family in the USPTO database would be necessary. The "Applications Claiming Priority" section lists only US11/986,389, suggesting it's the direct progeny of this application.

• Projected Expiration Date:
  For U.S. patents (other than design patents) issued from applications filed on or after June 8, 1995, the term generally ends 20 years from the earliest filing date of the application or a prior U.S. non-provisional or PCT application from which it claims priority.

  • Filing Date: November 20, 2007
  • Standard 20-year term calculation: November 20, 2007 + 20 years = November 20, 2027.
  • Anticipated expiration listed in Google Patents: The Google Patents page for US8327051B2 explicitly states an "Anticipated expiration" date of 2027-11-20. This aligns perfectly with the 20-year term from the filing date. This date would be further adjusted by any PTA or PTE, but the Google Patents entry does not indicate such adjustments.

Therefore, without access to the full prosecution history from the USPTO Patent Center, the projected expiration date is November 20, 2027, based on the 20-year term from the filing date, and assuming no PTA or PTE has been granted that would alter this date.

Here is a comprehensive "Defensive Disclosure" document analyzing US Patent 8327051 and generating derivative variations to create prior art.

Defensive Disclosure for US Patent 8327051

Patent Under Review: US8327051B2
Title: Portable handheld memory card and methods for use therewith
Current Assignee: Palisade Technologies LLP
Prior Art Creation Date: 2026-05-16

Introduction

This document details derivative works and extensions of the technologies described in US Patent 8327051B2, aimed at generating prior art that could render future incremental improvements or variations by competitors as obvious or non-novel. The derivations are based on the independent claims of the patent and explore various axes of innovation, including material and component substitution, operational parameter expansion, cross-domain application, integration with emerging technologies, and inverse/failure modes.

---

Derivative Variations for Independent Claim 1: Portable Handheld Memory Card

Claim 1: A portable handheld memory card comprising: a Universal Serial Bus (USB) port comprising a first set of pins; USB controller circuitry electrically connected with the first set of pins of the USB port; an input/output (I/O) port comprising a second set of pins; I/O controller circuitry electrically connected with the second set of pins of the I/O port; a memory in communication with the USB port and the I/O port; and a housing storing the memory and exposing the USB port and the I/O port; wherein the USB port and the I/O port are positioned on a same end to allow a same card-insertion direction irrespective of whether a host device comprises a mating USB port or a mating I/O port; and wherein the USB port and the I/O port are positioned such that when the I/O port is electrically connected with the host device, at least one of the first set of pins of the USB port is not electrically connected to the host device, and when the USB port is electrically connected to the host device, at least one of the second set of pins of the I/O port is not electrically connected to the host device.

1. Material & Component Substitution

• Derivative 1.1: High-Durability Housing with Advanced Memory

  • Enabling Description: The housing of the portable handheld memory card is constructed from a carbon-fiber reinforced polymer (CFRP) composite, providing enhanced impact resistance and rigidity while reducing overall weight. The non-volatile memory utilizes 3D NAND Flash technology with an embedded phase-change memory (PCM) cache layer for improved write endurance and read/write speeds, replacing conventional planar NAND. The USB port is implemented with a USB Type-C connector, and the I/O port is a UFS (Universal Flash Storage) port, both fabricated with gold-plated beryllium copper contacts for superior corrosion resistance and signal integrity over extended operational cycles. The USB controller circuitry and UFS controller circuitry are integrated into a single system-on-chip (SoC) using 7nm process technology, reducing power consumption and latency. The power management unit (PMU) incorporates gallium nitride (GaN) power transistors for higher efficiency power conversion.

  • classDiagram
        class MemoryCard {
            +CarbonFiberHousing
            +USB_TypeC_Port
            +UFS_Port
            +3D_NAND_PCM_Memory
            +Integrated_SoC_Controller
            +GaN_PMU
        }
        class USB_TypeC_Port {
            +BerylliumCopperContacts
        }
        class UFS_Port {
            +BerylliumCopperContacts
        }
        class Integrated_SoC_Controller {
            -USB_Controller_Logic
            -UFS_Controller_Logic
            -ReadWrite_Controller
        }
        class 3D_NAND_PCM_Memory {
            -3D_NAND_Array
            -PCM_Cache
        }
        MemoryCard "1" *-- "1" USB_TypeC_Port
        MemoryCard "1" *-- "1" UFS_Port
        MemoryCard "1" *-- "1" 3D_NAND_PCM_Memory
        MemoryCard "1" *-- "1" Integrated_SoC_Controller
        MemoryCard "1" *-- "1" GaN_PMU
        Integrated_SoC_Controller -- USB_TypeC_Port : controls
        Integrated_SoC_Controller -- UFS_Port : controls
        Integrated_SoC_Controller -- 3D_NAND_PCM_Memory : access
    

• Derivative 1.2: Optoelectronic Interface Card

  • Enabling Description: The memory card's I/O port uses a high-speed optical interface, such as a miniature optical transceiver employing VCSEL (Vertical-Cavity Surface-Emitting Laser) arrays for data transmission, instead of traditional electrical pins. The USB port is a standard USB 3.2 Gen 2 (10 Gbps) Type-A connector. The I/O controller circuitry includes optoelectronic conversion components (e.g., photodiodes, laser drivers) and a dedicated optical serializer/deserializer (SerDes). The memory is a hybrid storage module combining DRAM and non-volatile resistive RAM (ReRAM) for ultra-fast access and persistence. The housing includes a transparent polymer window over the optical port to protect the optical components while allowing light transmission. The host device would interface with either the electrical USB or the optical I/O, maintaining the same insertion direction principle.

  • flowchart TD
        A[Memory Card] --> B(Housing)
        B --> C{USB 3.2 Gen2 Type-A Port}
        B --> D{Optical I/O Port}
        C -- Electrical Signals --> E[USB Controller Circuitry]
        D -- Optical Signals --> F[Optoelectronic I/O Controller Circuitry]
        E -- Data Access --> G[Hybrid DRAM/ReRAM Memory]
        F -- Data Access --> G
        G -- Control & Power --> H[Power Management Unit]
        E -- Control & Power --> H
        F -- Control & Power --> H
        style C fill:#f9f,stroke:#333,stroke-width:2px
        style D fill:#9cf,stroke:#333,stroke-width:2px
    

• Derivative 1.3: Biometric-Secured Memory Card

  • Enabling Description: The memory card integrates a capacitive fingerprint sensor on its housing and a secure element (SE) within the USB controller circuitry. Access to encrypted data stored in the memory (e.g., eUFS or NVMe over PCIe) is gated by successful biometric authentication processed by the secure element. The USB port remains a standard Type-C, but with additional power delivery (PD) capabilities. The I/O port is a secure digital (SD) Express port. The power management unit includes a dedicated low-power microcontroller for biometric data processing and secure key management, ensuring cryptographic operations are performed within a trusted execution environment (TEE).

  • graph TD
        A[Memory Card Housing] --> B(Capacitive Fingerprint Sensor)
        A --> C(USB Type-C Port)
        A --> D(SD Express Port)
        C -- USB Protocol --> E[USB Controller w/ Secure Element]
        D -- SD Express Protocol --> F[I/O Controller Circuitry]
        B -- Biometric Data --> E
        E -- Authenticated Access --> G[eUFS/NVMe Memory]
        F -- Data Access --> G
        G -- Power --> H[Power Management Unit w/ TPM]
        E -- Power --> H
        F -- Power --> H
        subgraph Secure Processing
            E
            H
        end
    

2. Operational Parameter Expansion

• Derivative 1.4: Cryogenic Data Logger Card

  • Enabling Description: This memory card is designed for operation in extreme low-temperature environments, specifically for data logging in cryogenic systems (e.g., superconducting quantum computers, deep space probes). The housing is made of a specialized ceramic-matrix composite with a low coefficient of thermal expansion (CTE) and hermetic sealing. All electronic components, including the USB controller, I/O controller (e.g., specialized serial peripheral interface (SPI) for low-temperature sensor arrays), and the memory (radiation-hardened Flash or MRAM), are commercial-off-the-shelf (COTS) components rated for extended operation down to 4K (-269°C). The electrical contacts are made from niobium-titanium alloy for superconductivity at operational temperatures, minimizing power loss. The power management unit employs cryogenic-compatible DC-DC converters.

  • stateDiagram-v2
        [*] --> Idle
        Idle --> Initializing : Power On (Cryo-rated PMU)
        Initializing --> SelfTest : Components Check
        SelfTest --> Operational : Pass
        SelfTest --> Error : Fail
        Operational --> DataLogging : I/O Port Active (Cryo-SPI)
        Operational --> DataTransfer : USB Port Active (Cryo-USB)
        DataLogging --> Operational : Data Written to MRAM
        DataTransfer --> Operational : Data Read/Write
        Error --> [*] : System Halt
        note right of Operational
            Housing: Ceramic-Matrix Composite
            Contacts: Niobium-Titanium Alloy
            Memory: Rad-Hard MRAM
        end
    

• Derivative 1.5: High-Frequency Telemetry Card

  • Enabling Description: The memory card is optimized for high-frequency data capture and transmission, typical in RF/microwave telemetry or high-speed sensor applications. The USB port is upgraded to USB4 with Thunderbolt 4 capabilities, offering up to 40 Gbps bandwidth. The I/O port is a custom high-speed serial interface (HSSI) utilizing differential signaling and impedance-matched contacts for frequencies up to 20 GHz. The I/O controller circuitry includes dedicated high-speed ADCs (Analog-to-Digital Converters) and DACs (Digital-to-Analog Converters) for direct interfacing with RF signals, along with an FPGA (Field-Programmable Gate Array) for real-time signal processing and modulation. The memory consists of multiple parallel high-bandwidth memory (HBM) stacks for instantaneous data capture, backed by a large capacity NVMe SSD. The housing features RF shielding and thermal dissipation elements to manage high-frequency electromagnetic interference and heat generated by the high-speed components.

  • sequenceDiagram
        participant MC as Memory Card
        participant HS as Host System (High-Freq)
        participant HSS as Host System (Standard)
    
        HS->>MC: Send High-Freq Data (HSSI)
        MC->>MC: HSSI Controller (ADC/DAC, FPGA) processes
        MC->>MC: Store in HBM/NVMe
        MC-->>HS: Acknowledge (HSSI)
    
        HSS->>MC: Request Data (USB4/Thunderbolt)
        MC->>MC: USB4 Controller processes
        MC->>MC: Retrieve from HBM/NVMe
        MC-->>HSS: Transmit Data (USB4/Thunderbolt)
        MC->>MC: Power Management actively regulates for high-frequency ops
    

3. Cross-Domain Application

• Derivative 1.6: Medical Diagnostic Cartridge

  • Enabling Description: This memory card acts as a portable diagnostic cartridge for point-of-care medical devices. The I/O port is a proprietary multi-pin connector for interfacing with bio-sensors (e.g., glucose meters, DNA sequencers), transferring raw measurement data. The I/O controller processes this data, optionally performing initial analysis or encryption. The USB port (USB Type-C with Power Delivery) allows for secure data upload to a hospital information system (HIS) or for firmware updates. The memory stores patient-specific diagnostic profiles and results, along with device calibration data. The housing is made of biocompatible, autoclavable polymer (e.g., medical-grade PEEK) and is hermetically sealed to prevent contamination. The decryption circuitry handles patient data according to HIPAA standards.

  • flowchart LR
        MD[Medical Device Host] -- Proprietary I/O --> MC[Medical Diagnostic Cartridge]
        MC -- USB-C (Data/Power) --> HIS[Hospital Information System]
        MC --> M[Memory (Patient Profiles, Results)]
        MC --> IOC[I/O Controller (Sensor Interface, Data Pre-processing, Encryption)]
        MC --> USDC[USB-C Controller (Secure Upload, Firmware Update)]
        M <--> IOC
        M <--> USDC
        IOC -- Encrypt/Process --> M
        USDC -- Decrypt/Transmit --> HIS
        MC --- H(Biocompatible, Autoclavable Housing)
        subgraph Security
            IOC
            USDC
            M
        end
    

• Derivative 1.7: Agricultural Sensor Data Unit

  • Enabling Description: Designed for harsh outdoor environments, this memory card collects data from agricultural sensors (soil moisture, nutrient levels, weather). The I/O port is a ruggedized M12 connector, supporting Modbus RTU or CAN bus for interfacing with sensor networks. The USB port is a sealed USB Type-B for field programming and data offload to a portable agricultural management device. The housing is IP68-rated and constructed from UV-stabilized ABS plastic. The memory stores time-series sensor data and geo-location tags. The embedded decompression circuitry processes data compressed using specialized agricultural data compression algorithms (e.g., for spectral imaging data), making it ready for analysis by farm management software.

  • graph TD
        AS[Agricultural Sensors] -->|Modbus/CAN| MC[Agricultural Sensor Data Unit]
        MC -->|Sealed USB-B| AMD[Agricultural Management Device]
        MC --> M[Memory (Sensor Data, Geo-tags)]
        MC --> IOC[I/O Controller (Modbus/CAN Interface, Data Acquisition)]
        MC --> USDC[USB-B Controller (Data Offload, Field Programming)]
        MC --> DCC[Decompression Circuitry (Ag-specific algorithms)]
        IOC -- Acquire & Store --> M
        M -- Compressed Data --> DCC
        DCC -- Decompressed Data --> USDC
        MC --- H(IP68 UV-stabilized ABS Housing)
    

• Derivative 1.8: Industrial Control Module

  • Enabling Description: This memory card functions as a configurable industrial control module for Programmable Logic Controllers (PLCs) or distributed control systems (DCS). The I/O port is a DIN rail-mountable industrial-grade terminal block, supporting EtherCAT or PROFINET protocols for real-time control data exchange. The USB port (USB Type-B) is used for configuration, diagnostics, and firmware updates. The memory stores PLC ladder logic, configuration parameters, and historical event logs. The decompression and decryption circuitry enable secure, efficient storage and retrieval of control programs and sensitive operational data, ensuring integrity and preventing unauthorized modification. The housing is designed for electromagnetic compatibility (EMC) and vibration resistance.

  • classDiagram
        class IndustrialControlModule {
            +EMC_Vibration_Housing
            +DIN_Terminal_Block_IOPort
            +USB_TypeB_Port
            +Memory_PLC_Logic_Config
            +I_O_Controller_EtherCAT_PROFINET
            +USB_Controller
            +Decryption_Circuitry
            +Decompression_Circuitry
        }
        class I_O_Controller_EtherCAT_PROFINET {
            +RealTimeControl
        }
        class Decryption_Circuitry {
            +SecureProgramLoad
        }
        class Decompression_Circuitry {
            +EfficientStorage
        }
        IndustrialControlModule "1" *-- "1" I_O_Controller_EtherCAT_PROFINET
        IndustrialControlModule "1" *-- "1" USB_TypeB_Port
        IndustrialControlModule "1" *-- "1" Memory_PLC_Logic_Config
        IndustrialControlModule "1" *-- "1" Decryption_Circuitry
        IndustrialControlModule "1" *-- "1" Decompression_Circuitry
        I_O_Controller_EtherCAT_PROFINET -- Memory_PLC_Logic_Config : read/write
        USB_TypeB_Port -- Memory_PLC_Logic_Config : read/write
        Decryption_Circuitry -- Memory_PLC_Logic_Config : decrypt
        Decompression_Circuitry -- Memory_PLC_Logic_Config : decompress
    

4. Integration with Emerging Tech

• Derivative 1.9: AI-Optimized Edge Storage Card

  • Enabling Description: This memory card integrates a dedicated AI accelerator (e.g., a tinyML inference engine or a neuromorphic chip) within its USB controller circuitry. The card stores pre-trained machine learning models alongside data. When data is accessed via either the USB port (USB 3.1 Gen 1) or the I/O port (e.g., an enhanced SPI interface for IoT sensors), the AI accelerator performs real-time inference at the edge, optimizing data filtering, anomaly detection, or predictive analytics before transmission or storage. The power management unit dynamically adjusts power to the AI accelerator based on inference load. The memory is optimized for high-throughput sequential reads and writes, suitable for large datasets generated by edge devices.

  • graph LR
        IoT[IoT Sensors] -- Enhanced SPI --> MC[AI-Optimized Edge Storage Card]
        Host[Host Device] -- USB 3.1 Gen1 --> MC
        MC --> M[High-Throughput Memory]
        MC --> IOC[I/O Controller]
        MC --> USBC[USB Controller w/ AI Accelerator]
        USBC -- Inference --> DataProcessing[Data Filtering/Anomaly Detection]
        IOC -- Data Flow --> DataProcessing
        DataProcessing -- Store/Transmit --> M
        DataProcessing -- Transmit --> Host
        DataProcessing -- Transmit --> IoT
        MC --> PMU[Power Management Unit (Dynamic)]
        USBC -- Power Control --> PMU
        IOC -- Power Control --> PMU
    

• Derivative 1.10: Blockchain-Enabled Secure Asset Card

  • Enabling Description: This memory card includes a hardware security module (HSM) integrated into the I/O controller, capable of cryptographic signing and verification of data transactions. The USB port (USB Type-C) facilitates connection to a host for typical data transfer, while the I/O port (e.g., NFC or a specialized contact interface) enables direct interaction with blockchain network nodes or decentralized applications (dApps). Each data block written to the memory (e.g., persistent memory like NVRAM) is timestamped and cryptographically hashed by the HSM, with the hash committed to a private blockchain ledger. This ensures immutable proof of data origin and integrity, suitable for intellectual property management or secure supply chain tracking. The decryption circuitry works in conjunction with the HSM for robust key management.

  • flowchart TB
        A[Host Device] -- USB-C --> B(Memory Card)
        C[Blockchain Node/dApp] -- NFC/Special I/O --> B
        B --> D{USB Controller}
        B --> E{I/O Controller w/ HSM}
        E --> F[Cryptographic Hashing/Signing]
        F --> G[NVRAM Memory (Data/Hashes)]
        G -- Hashed Data --> C
        D -- Data Access --> G
        E -- Decryption --> G
        F -- Timestamp/Ledger Update --> C
    

• Derivative 1.11: IoT Sensor Integration with Real-Time Monitoring

  • Enabling Description: The memory card integrates low-power IoT sensor interfaces (e.g., Bluetooth Low Energy 5.0, Zigbee) directly within its I/O controller circuitry, allowing it to act as a standalone data logger and gateway for nearby IoT devices. The USB port (USB 2.0 micro-B) is used primarily for power and occasional data offload. The memory (e.g., low-power NOR Flash) stores aggregated sensor data. The embedded decompression circuitry optimizes storage space for long-term data collection, while a small, dedicated microcontroller within the I/O controller performs real-time data aggregation and health monitoring of connected IoT sensors, transmitting alerts via its integrated wireless modules.

  • graph LR
        Sensor_A[IoT Sensor A] -- BLE --> MC[Memory Card]
        Sensor_B[IoT Sensor B] -- Zigbee --> MC
        MC -- Micro-USB 2.0 --> Host[Host Device / Power Source]
        MC --> M[NOR Flash Memory]
        MC --> IOTC[IoT Controller (BLE, Zigbee, µC)]
        MC --> DCC[Decompression Circuitry]
        IOTC -- Aggregate Data --> M
        IOTC -- Alerts/Health --> Host
        M -- Compressed Data --> DCC
        DCC -- Decompressed Data --> IOTC
        IOTC -- Power --> PMU[Power Management Unit]
    

5. The "Inverse" or Failure Mode

• Derivative 1.12: Read-Only Forensic Mode Card

  • Enabling Description: This memory card includes a physical "forensic mode" switch or a software-triggerable flag that, when activated, places the card into a permanent read-only state. In this mode, the write functionality of the read/write controller is entirely disabled, preventing any modification or accidental erasure of data. The USB port and I/O port (e.g., standard SD card pins) remain operational for data extraction. The power management unit incorporates a hardened, non-resettable fuse or e-fuse that irreversibly locks the write circuitry upon activation, ensuring data integrity for forensic analysis. This mode prevents any decryption or decompression functionality to ensure raw data access as originally stored.

  • stateDiagram-v2
        [*] --> Normal_Operation
        Normal_Operation --> Forensic_Mode : Activate Forensic Switch/Flag
        Forensic_Mode --> Read_Only_Data_Access : Write Circuitry Disabled (e-fuse)
        Read_Only_Data_Access --> Data_Extraction_USB : USB Port Active
        Read_Only_Data_Access --> Data_Extraction_IO : I/O Port Active
        Data_Extraction_USB --> [*] : Data Extracted
        Data_Extraction_IO --> [*] : Data Extracted
        note right of Forensic_Mode
            Decryption/Decompression
            circuitry bypassed.
            Raw data only.
        end
    

• Derivative 1.13: Limited-Functionality "Safe-Mode" Card

  • Enabling Description: The memory card features an internal diagnostic circuit that monitors key operational parameters (e.g., temperature, voltage, memory error rates). If a parameter exceeds predefined thresholds, the card automatically enters a "safe mode" by signaling the power management unit to reduce clock frequencies and voltages to critical components (memory, controllers). In safe mode, only essential data (e.g., diagnostic logs, critical system files) is accessible via a low-speed USB 1.1 interface, while the primary I/O port (e.g., high-speed SD) and data-intensive functions like decompression/decryption are temporarily disabled or operate at significantly reduced performance. This allows for safe data recovery or troubleshooting without full system failure.

  • flowchart TD
        Start[Power On] --> Normal[Normal Operation]
        Normal --> Monitor[Monitor Diagnostics]
        Monitor -- Threshold Exceeded --> SafeMode[Safe Mode Activated]
        SafeMode --> LowPower[Reduced Clock/Voltage (PMU)]
        LowPower --> USB1_1[USB 1.1 Interface Active]
        LowPower --> SD_Disabled[High-Speed I/O (SD) Disabled]
        LowPower --> LimitedData[Access Critical Data/Logs]
        LimitedData --> Recovery[Data Recovery/Troubleshooting]
        Recovery --> Normal[Return to Normal (if stable)]
        Recovery --> Fail[System Failure]
        Normal -- No Issues --> Monitor
    

---

Derivative Variations for Independent Claim 9: Method for Data Handling with Memory Card - Type 1

Claim 9: A method comprising: with a portable handheld card comprising a Universal Serial Bus (USB) port comprising a first set of pins; USB controller circuitry electrically connected with the first set of pins of the USB port; an input/output (I/O) port comprising a second set of pins; I/O controller circuitry electrically connected with the second set of pins of the I/O port; a memory in communication with the USB port and the I/O port; and a housing storing the memory and exposing the USB port and the I/O port, wherein the USB port and the I/O port are positioned to allow a same card-insertion direction irrespective of whether a host device comprises a mating USB port or a mating I/O port and wherein the USB port and the I/O port are positioned such that when the I/O port is electrically connected with the host device, at least one of the first set of pins of the USB port is not electrically connected to the host device, and when the USB port is electrically connected to the host device, at least one of the second set of pins of the I/O port is not electrically connected to the host device: reading compressed data from the memory decompressing the compressed data to decompressed data; transmitting the decompressed data on the I/O port; converting the compressed data to first converted data for transmission on the USB port; and transmitting the first converted data on the USB port.

1. Material & Component Substitution (Methodological Perspective)

• Derivative 9.1: On-Chip Lossless/Lossy Adaptive Compression/Decompression

  • Enabling Description: The method employs an adaptive compression engine within the memory card's read/write controller, which dynamically selects between multiple lossless (e.g., LZ4, Zstd) and lossy (e.g., JPEG 2000 for images, Opus for audio) compression algorithms based on data type metadata and available memory bandwidth/latency. When compressed data is read from 3D NAND memory, a corresponding adaptive decompression unit (ASIC-based) identifies the algorithm used and decompresses the data. For I/O port transmission (e.g., via a PCIe-based SD Express port), the decompressed data is streamed. For USB port transmission (e.g., USB 4.0), the original compressed data can be re-compressed with a different algorithm, if advantageous for the USB host, or converted to a USB-compatible stream directly.

  • flowchart TD
        A[Start] --> B{Read Compressed Data from 3D NAND}
        B --> C{Determine Compression Algorithm (Metadata)}
        C --> D{Adaptive Decompression Unit (ASIC)}
        D -- Decompressed Data --> E{Transmit via PCIe SD Express I/O}
        C -- Original Compressed Data --> F{Re-compress? (USB Host Preference)}
        F -- No / Original Compressed Data --> G{Convert to USB 4.0 Protocol}
        F -- Yes / Re-compressed Data --> G
        G -- Converted Data --> H{Transmit via USB 4.0 Port}
        E & H --> I[End]
    

• Derivative 9.2: Quantum-Resistant Encrypted and Compressed Data Handling

  • Enabling Description: Data stored in persistent memory (e.g., MRAM or RRAM) on the card is initially encrypted using quantum-resistant cryptographic algorithms (e.g., lattice-based cryptography) and then compressed (e.g., Brotli algorithm). The method involves reading this quantum-resistant encrypted and compressed data. Before decompression, a dedicated hardware security module (HSM) performs quantum-resistant decryption. The decrypted compressed data is then passed to a hardware decompression circuit. The decompressed data is transmitted via a secure I/O port (e.g., an authenticated Ethernet-over-SPI interface). Alternatively, for USB port transmission (e.g., USB 3.2 Gen 2x2 Type-C), the decrypted compressed data is converted to a USB-compliant signal, allowing the host to perform its own decompression or storage.

  • sequenceDiagram
        participant MC as Memory Card (HSM, Decomp. HW)
        participant PM as Persistent Memory (MRAM/RRAM)
        participant Host as Host Device (USB/Secure I/O)
    
        PM->>MC: Read QR-Encrypted, Compressed Data
        MC->>MC: HSM performs QR-Decryption
        MC->>MC: If I/O Transmit: Decomp HW decompresses
        MC->>Host: Transmit Decompressed Data (Secure I/O Port)
        MC->>MC: If USB Transmit: Decrypted Compressed Data
        MC->>Host: Convert & Transmit Decrypted Compressed Data (USB Port)
    

2. Operational Parameter Expansion (Methodological Perspective)

• Derivative 9.3: Real-time Multi-Stream 8K Video Processing

  • Enabling Description: This method focuses on handling multiple streams of highly compressed (e.g., HEVC or AV1) 8K video data in real-time. The memory card's Flash memory (e.g., UFS 4.0) stores these streams. The decompression circuitry includes multiple hardware video decoders (e.g., dedicated ASICs) operating in parallel. When video streams are requested for playback, the card reads compressed data for each stream, rapidly decompresses them, and simultaneously transmits multiple decompressed PCM video frames over a high-bandwidth I/O port (e.g., DisplayPort over USB-C alternate mode, or a proprietary multi-lane serial interface) to a display host. Concurrently, for archival or further processing, the original compressed 8K video data can be converted to a USB-compliant stream (e.g., USB 4.0) and transmitted to a computing host. The power management unit prioritizes power delivery to the active decoder units.

  • graph TD
        A[Start] --> B{Read Multi-Stream 8K Compressed Video from UFS 4.0}
        B --> C1[Hardware Video Decoder 1 (Stream 1)]
        B --> C2[Hardware Video Decoder 2 (Stream 2)]
        C1 -- Decompressed Frame 1 --> D[High-Bandwidth I/O Port Transmit]
        C2 -- Decompressed Frame 2 --> D
        D -- Multi-stream PCM --> E[Display Host]
        B -- Original Compressed Data --> F[USB 4.0 Controller]
        F -- USB-Compliant Stream --> G[Computing Host]
        E & G --> H[End]
        subgraph Parallel Decompression
            C1
            C2
        end
    

• Derivative 9.4: Ultra-Low Latency Audio Transcoding

  • Enabling Description: The method processes compressed audio data (e.g., FLAC, Ogg Vorbis) with ultra-low latency requirements, suitable for professional audio applications. The memory (e.g., high-speed LPDDR5 acting as a buffer backed by a NVMe SSD) stores the compressed audio. The decompression circuitry is a dedicated low-latency audio DSP (Digital Signal Processor). When requested, compressed audio is read, decompressed by the DSP, and transmitted as a high-resolution, uncompressed audio stream (e.g., 24-bit/192kHz PCM or DSD) over a specialized audio I/O port (e.g., I2S via a custom pinout, or AES/EBU digital audio). For general data transfer, the original compressed audio can be converted to a USB 3.0 stream and sent via the USB port.

  • sequenceDiagram
        participant AudioSource as Host (Audio Player)
        participant MC as Memory Card (DSP)
        participant PM as NVMe SSD/LPDDR5
        participant USBHost as Host (Data Archival)
    
        AudioSource->>MC: Request High-Res Audio
        MC->>PM: Read Compressed Audio Data
        MC->>MC: DSP Decompresses (Ultra-low latency)
        MC->>AudioSource: Transmit High-Res PCM/DSD (Specialized Audio I/O)
        USBHost->>MC: Request Compressed Audio
        MC->>PM: Read Compressed Audio Data
        MC->>USBHost: Convert & Transmit Compressed Data (USB 3.0)
    

3. Cross-Domain Application (Methodological Perspective)

• Derivative 9.5: Predictive Maintenance Data Analysis

  • Enabling Description: This method applies the patent's core function to predictive maintenance in industrial machinery. Sensor data (vibration, temperature, current) from machinery is continuously collected and stored in compressed format (e.g., time-series compression algorithms like Gorilla, Delta-encoding) in the memory. When a host (e.g., a field diagnostic tool) connects via the I/O port (e.g., a ruggedized industrial Ethernet connector), the method decompresses the relevant time-series data locally on the card and transmits it for immediate analysis. Concurrently, for central analysis or long-term storage, the raw compressed sensor data can be transmitted via the USB port (e.g., USB-C) to a cloud gateway or central data repository. This allows for both on-site immediate troubleshooting and broader trend analysis.

  • flowchart LR
        Start[Begin Data Logging] --> A[Collect Sensor Data]
        A --> B{Compress & Store in Memory}
        B --> C{Determine Output Path}
        C -- I/O Port Request --> D[Decompress Data (On-Card)]
        D --> E[Transmit Decompressed Data via Industrial Ethernet I/O]
        C -- USB Port Request --> F[Convert Compressed Data to USB Protocol]
        F --> G[Transmit Compressed Data via USB-C]
        E & G --> End[End Session]
    

• Derivative 9.6: Drone Payload Data Processing

  • Enabling Description: The method enables efficient handling of data from drone payloads (e.g., high-resolution imagery, LiDAR scans). During flight, the drone's memory card continuously captures and stores payload data in a compressed format (e.g., JPEG XL for imagery, specific LiDAR point cloud compression). Upon landing, for rapid field assessment, the card is inserted into a rugged tablet via its I/O port (e.g., a high-speed proprietary connector optimized for drone communication). The card decompresses a subset of the data (e.g., low-resolution thumbnails or critical anomaly points) and transmits it for immediate review. For detailed post-mission analysis, the entire compressed dataset is converted to a USB-compliant stream (e.g., USB 3.2) and offloaded via the USB port to a ground station processing unit.

  • sequenceDiagram
        participant Drone as Drone (Payload, MC)
        participant MC as Memory Card (On-card Decomp.)
        participant Tablet as Rugged Tablet (I/O Host)
        participant GroundStation as Ground Station (USB Host)
    
        Drone->>MC: Store Compressed Payload Data
        MC->>Tablet: Insert Card (I/O Connect)
        Tablet->>MC: Request Subset for Field Assessment
        MC->>MC: Decompress Subset (On-card)
        MC->>Tablet: Transmit Decompressed Subset
        MC->>GroundStation: Connect USB
        GroundStation->>MC: Request Full Compressed Dataset
        MC->>GroundStation: Convert & Transmit Full Compressed Data
    

4. Integration with Emerging Tech (Methodological Perspective)

• Derivative 9.7: Federated Learning Data Preprocessing

  • Enabling Description: This method supports federated learning by performing on-device data preprocessing on the memory card. Raw sensor data from edge devices (e.g., smart home sensors, wearables) is stored compressed in the card's memory. When a federated learning coordinator requests data for model training, the card first reads the compressed data. Instead of full decompression, it utilizes its decompression circuitry to decompress only features relevant to the current ML model (e.g., specific parameters from environmental sensor readings), then performs lightweight feature extraction (e.g., normalization, aggregation) using an embedded microcontroller. This processed, potentially re-compressed, data (e.g., smaller feature vectors) is then transmitted over a secure I/O port (e.g., authenticated Wi-Fi direct interface) to the coordinator. The full original compressed data can be offloaded via the USB port for auditing or model re-training.

  • graph TD
        Edge[Edge Devices] --> MC[Memory Card (uC, Decomp.)]
        MC --> M[Compressed Raw Sensor Data]
        FLC[Federated Learning Coordinator] -- Request Data --> MC
        MC -- Read --> M
        M -- Compressed Data --> D[Decompression Circuitry]
        D -- Partial Decomp. --> E[Embedded Microcontroller (Feature Extraction)]
        E -- Processed, Re-compressed Features --> F[Secure Wi-Fi Direct I/O Transmit]
        F --> FLC
        MC -- USB Request --> G[USB Controller]
        G -- Full Compressed Data --> H[Audit/Retrain Host]
    

• Derivative 9.8: IoT Device Firmware-over-Blockchain Update & Validation

  • Enabling Description: The method facilitates secure and validated firmware updates for IoT devices using blockchain. New firmware is downloaded to the memory card in an encrypted and compressed format. The compressed firmware is read from memory. For validation, the decompression circuitry decompresses the firmware, and a hash of the decompressed firmware is calculated by a hardware security module (HSM) on the card. This hash is then compared against a hash stored on a blockchain, accessible via a specialized I/O port (e.g., a secure element with a cryptographic interface). If validated, the decompressed firmware is transmitted to the IoT device via the I/O port (e.g., a trusted serial interface). For debugging or direct update, the compressed firmware can be converted and transmitted via the USB port.

  • sequenceDiagram
        participant MC as Memory Card (HSM, Decomp. HW)
        participant IoT as IoT Device
        participant BC as Blockchain Network
    
        Host->>MC: Download Encrypted, Compressed FW (USB)
        MC->>MC: Store in Memory
        IoT->>MC: Request FW Update (Trusted I/O)
        MC->>MC: Read Compressed FW
        MC->>MC: Decompression HW decompresses FW
        MC->>MC: HSM calculates Hash(FW)
        MC->>BC: Query Blockchain for Valid Hash (via I/O)
        BC-->>MC: Return Valid Hash
        MC->>MC: Compare Hashes
        alt Hashes Match (Valid)
            MC->>IoT: Transmit Decompressed FW (Trusted I/O)
        else Hashes Mismatch (Invalid)
            MC->>IoT: Reject Update
        end
        Host->>MC: Request Compressed FW (USB, for debugging)
        MC->>Host: Transmit Compressed FW
    

5. The "Inverse" or Failure Mode (Methodological Perspective)

• Derivative 9.9: Safe Decompression & Streaming for Corrupt Data
  • Enabling Description: This method provides graceful degradation when encountering corrupt compressed data in memory. When compressed data is read, a dedicated error detection and correction (ECC) engine, integrated with the decompression circuitry, first scans for integrity issues. If corruption is detected, the decompression circuitry attempts to decompress the data in a "safe mode," either by skipping corrupt blocks, interpolating missing data, or outputting a placeholder (e.g., silent audio, black frames for video). The partially decompressed data is then transmitted on the I/O port, possibly with an error flag. Concurrently, the original corrupt compressed data can be transmitted via the USB port for external diagnostic tools to analyze the corruption without attempting on-card repair.

  • flowchart TD
        A[Start] --> B{Read Compressed Data from Memory}
        B --> C{ECC Scan for Corruption}
        C -- No Corruption --> D[Decompress (Normal)]
        C -- Corruption Detected --> E[Decompress (Safe Mode)]
        D --> F[Transmit Decompressed Data (I/O)]
        E --> G[Transmit Partially Decompressed Data w/ Error Flag (I/O)]
        B -- Original Compressed Data (Corrupt) --> H[Convert to USB Protocol]
        H --> I[Transmit Compressed Data (USB) for Diagnostics]
        F & G & I --> J[End]
    

---

Derivative Variations for Independent Claim 16: Method for Data Handling with Memory Card - Type 2

Claim 16: A method comprising: with a portable handheld card comprising a Universal Serial Bus (USB) port comprising a first set of pins; USB controller circuitry electrically connected with the first set of pins of the USB port; an input/output (I/O) port comprising a second set of pins; I/O controller circuitry electrically connected with the second set of pins of the I/O port; a memory in communication with the USB port and the I/O port; and a housing storing the memory and exposing the USB port and the I/O port, wherein the USB port and the I/O port are positioned to allow a same card-insertion direction irrespective of whether a host device comprises a mating USB port or a mating I/O port and wherein the USB port and the I/O port are positioned such that when the I/O port is electrically connected with the host device, at least one of the first set of pins of the USB port is not electrically connected to the host device, and when the USB port is electrically connected to the host device, at least one of the second set of pins of the I/O port is not electrically connected to the host device: reading data from the memory; determining whether the data is to be transmitted via the USB port or I/O port; and transmitting the data to the host device via the determined port.

1. Material & Component Substitution (Methodological Perspective)

• Derivative 16.1: Dynamic Protocol Negotiation and Data Routing

  • Enabling Description: The method utilizes a sophisticated protocol negotiation engine, implemented as an FPGA or a dedicated ASIC, within the memory card's I/O and USB controller circuitry. When a host device connects, this engine automatically identifies the host's supported interface protocol (e.g., USB 3.2, SD Express, UFS, NVMe-oF via a custom I/O port). Based on this identification, and potentially metadata associated with the data (e.g., "high-priority," "real-time," "bulk storage"), the method dynamically selects the optimal port and protocol for data transmission. The memory consists of a tiered storage architecture (e.g., fast SLC NAND for hot data, slower TLC NAND for cold data), and the read operation is optimized based on the determined port's bandwidth requirements.

  • flowchart TD
        A[Start] --> B{Host Connects}
        B --> C{Detect Host Interface Protocol (FPGA/ASIC)}
        C --> D{Read Data from Tiered Memory}
        D --> E{Evaluate Data Metadata & Host Protocol}
        E -- Optimal: USB Port --> F[Convert Data to USB Protocol]
        F --> G[Transmit Data via USB Port]
        E -- Optimal: I/O Port --> H[Convert Data to I/O Protocol]
        H --> I[Transmit Data via I/O Port]
        G & I --> J[End]
    

• Derivative 16.2: Low-Power Sensor Hub with Adaptive Reporting

  • Enabling Description: The memory card functions as a low-power sensor hub, integrating various sensor interfaces (e.g., I2C, SPI, UART) into its I/O controller, which comprises a low-power microcontroller (LPMCU). The memory (e.g., eMMC or NOR Flash) stores aggregated sensor readings. The method periodically reads sensor data. A decision-making algorithm within the LPMCU determines if the data should be immediately transmitted via a low-power wireless I/O (e.g., Bluetooth LE, LoRaWAN) to a nearby gateway, or buffered in memory for later bulk offload via a USB-C port. This determination is based on data criticality thresholds, available power, and network connectivity. The power management unit (PMU) dynamically adjusts sensor polling rates and wireless transmit power.

  • graph TD
        Sensors[External Sensors] -- I2C/SPI/UART --> MC[Low-Power Sensor Hub Card]
        MC --> M[eMMC/NOR Flash Memory]
        MC --> IOTC[I/O Controller (LPMCU, Wireless Tx)]
        MC --> USBC[USB-C Controller]
        MC --> PMU[Power Management Unit]
        IOTC -- Read & Aggregate --> M
        IOTC -- Determine Reporting --> Decision{Criticality, Power, Connectivity?}
        Decision -- Immediate (Wireless) --> WirelessTx[Transmit via BLE/LoRaWAN I/O]
        Decision -- Buffered (USB) --> Buffer[Buffer in Memory]
        Buffer --> USBC[USB-C Offload]
        WirelessTx --> Gateway[Wireless Gateway]
        USBC --> Host[Host Device]
        PMU -- Power Control --> IOTC
    

2. Operational Parameter Expansion (Methodological Perspective)

• Derivative 16.3: High-Throughput Scientific Instrument Data Streamer

  • Enabling Description: This method is tailored for scientific instruments generating massive datasets (e.g., electron microscopy, high-speed spectroscopy). The memory card (e.g., with a large NVMe SSD) continuously receives high-bandwidth data. The method reads data from memory, and a high-performance data router (e.g., an FPGA-based switch) determines the transmission path based on destination and urgency. Real-time data streams (e.g., raw spectral outputs) are transmitted with minimal latency via a dedicated high-speed optical I/O port (e.g., 100GbE optical transceiver). Bulk processed data or experimental results are transmitted via a high-speed electrical USB port (e.g., USB4 with optical extension). The determination logic prioritizes real-time streams and manages buffer utilization.

  • flowchart TD
        A[Start] --> B{High-Bandwidth Data from Instrument}
        B --> C{Store in NVMe SSD Memory}
        C --> D{Read Data (High-Performance Data Router)}
        D --> E{Determine Destination & Urgency}
        E -- Real-time / Optical I/O --> F[Transmit via 100GbE Optical I/O]
        E -- Bulk / USB --> G[Transmit via USB4 (Optical Ext.)]
        F --> H[Scientific Workstation]
        G --> I[Data Archival Server]
        H & I --> J[End]
        subgraph Data Routing & Prioritization
            D
            E
        end
    

• Derivative 16.4: Extreme Temperature Data Logging and Adaptive Interface Selection

  • Enabling Description: The method enables data logging in environments with extreme temperature fluctuations (e.g., industrial furnaces, arctic research). The memory card uses industrial-grade, wide-temperature-range components (e.g., e.g., automotive-grade Flash memory, silicon-carbide (SiC) based power management). The method reads logged data from memory. A thermal management unit, integrated with the I/O controller, dynamically assesses the card's operating temperature. If within optimal range, a high-speed I/O (e.g., PCIe-based custom connector) is used for rapid data offload. If approaching temperature limits (hot or cold), a reduced-speed, robust USB 2.0 interface is selected for transmission to prevent thermal stress on high-speed transceivers, ensuring data integrity over performance.

  • stateDiagram-v2
        [*] --> Idle
        Idle --> Logging_Data : Start Logging
        Logging_Data --> Read_Memory : Data Available
        Read_Memory --> Assess_Temp : Thermal Management Unit
        Assess_Temp -- Optimal Temp --> Select_HighSpeed_IO : PCIe Custom I/O
        Assess_Temp -- Extreme Temp --> Select_Robust_USB : USB 2.0
        Select_HighSpeed_IO --> Transmit_HighSpeed : Fast Data Offload
        Select_Robust_USB --> Transmit_Robust : Safe Data Offload
        Transmit_HighSpeed --> Logging_Data
        Transmit_Robust --> Logging_Data
        note right of Assess_Temp
            Uses Automotive-grade Flash & SiC PMU
        end
    

3. Cross-Domain Application (Methodological Perspective)

• Derivative 16.5: Smart City Infrastructure Monitoring Node

  • Enabling Description: This method is used in a memory card acting as a data aggregation and forwarding node in smart city infrastructure (e.g., traffic sensors, environmental monitors). The memory stores collected city data. The method reads this data. An intelligent routing algorithm, resident in the I/O controller, determines whether to transmit data locally to nearby maintenance crews via a short-range wireless I/O (e.g., Wi-Fi Direct, NFC) for immediate action (e.g., traffic light recalibration), or to securely push data to a central cloud server via a long-range cellular USB module (e.g., embedded 5G modem) for city-wide analytics and policy adjustments. This determination considers data type, urgency, and network availability/cost.

  • flowchart LR
        Sensors_SC[Smart City Sensors] --> MC[Smart City Monitoring Card]
        MC --> M[City Data Memory]
        MC --> IOTC[I/O Controller (Intelligent Router, Wi-Fi/NFC)]
        MC --> USBC[USB Controller (Embedded 5G Modem)]
        IOTC -- Read & Analyze --> M
        IOTC -- Determine Route --> Decision{Local Action vs. Cloud Analytics?}
        Decision -- Local --> Transmit_Local[Wi-Fi Direct/NFC I/O]
        Decision -- Cloud --> Transmit_Cloud[5G Cellular USB]
        Transmit_Local --> Maintenance[Maintenance Crew]
        Transmit_Cloud --> CloudServer[Central Cloud Server]
        M -- Data --> IOTC
        M -- Data --> USBC
    

• Derivative 16.6: Avionic Flight Data Recorder with Selective Download

  • Enabling Description: This method is implemented in a solid-state flight data recorder (FDR) memory card, designed for aircraft. The memory (e.g., radiation-hardened NVRAM) stores critical flight parameters (altitude, speed, engine status, control inputs) in raw and compressed formats. After a flight, the method reads data from the memory. A diagnostic system, integrated within the card's controller, determines whether to transmit a high-level summary/diagnostic log via a standard USB 2.0 port to ground crew for quick turnaround, or to provide a full raw flight data download via a proprietary high-speed MIL-STD I/O port for in-depth accident investigation. The determination is often triggered by flight event flags (e.g., hard landing, emergency procedures).

  • graph TD
        FDR_Sensor[Avionic Sensors] --> MC[Flight Data Recorder Card]
        MC --> M[Rad-Hard NVRAM Memory]
        MC --> Controller[Controller (Diagnostic System)]
        MC --> USB_Port[USB 2.0 Port]
        MC --> MIL_IO_Port[MIL-STD I/O Port]
    
        Controller -- Read Data --> M
        Controller -- Determine Output --> Decision{Summary/Full Data?}
        Decision -- Summary/Diagnostic --> Convert_USB[Convert to USB Format]
        Convert_USB --> USB_Port[Transmit Summary]
        USB_Port --> GroundCrew[Ground Crew (Quick Look)]
    
        Decision -- Full Raw Data --> Convert_MIL[Convert to MIL-STD Format]
        Convert_MIL --> MIL_IO_Port[Transmit Full Data]
        MIL_IO_Port --> InvestigationUnit[Investigation Unit (Detailed Analysis)]
    

4. Integration with Emerging Tech (Methodological Perspective)

• Derivative 16.7: Distributed Ledger Technology (DLT) Data Synchronization

  • Enabling Description: This method applies to memory cards used in decentralized networks, acting as DLT nodes. The memory stores a portion of a distributed ledger and transaction data. The method reads this data. A DLT-aware controller within the card determines if outgoing transactions or ledger updates should be broadcast immediately to peer nodes via a specialized P2P I/O (e.g., low-power Wi-Fi mesh) or batched and uploaded via a secure USB 3.0 port to a central DLT gateway for broader synchronization. This decision is based on network topology, transaction finality requirements, and local resource availability. The data is cryptographically signed by the card's embedded secure element before transmission.

  • sequenceDiagram
        participant MC as Memory Card (DLT Node, SE)
        participant Peers as DLT Peer Nodes
        participant DLT_Gateway as Central DLT Gateway
        participant Network as Network (Wi-Fi Mesh / USB 3.0)
    
        MC->>MC: Read DLT Data/Transactions from Memory
        MC->>MC: DLT Controller determines synchronization strategy
        alt Immediate Broadcast (P2P I/O)
            MC->>MC: Cryptographically Sign Data (Secure Element)
            MC->>Peers: Broadcast Signed Data (Wi-Fi Mesh I/O)
        else Batched Upload (USB)
            MC->>MC: Cryptographically Sign Data (Secure Element)
            MC->>DLT_Gateway: Upload Batched Signed Data (USB 3.0)
        end
    

• Derivative 16.8: AI-Driven Context-Aware Data Offloading

  • Enabling Description: The memory card integrates an AI inference engine within its I/O controller, capable of analyzing data context. The method reads data (e.g., sensor readings, user activity logs) from memory. The AI engine processes this data to determine its context (e.g., "urgent anomaly," "routine log," "personal media"). Based on this context, it dynamically chooses the transmission method. Urgent anomaly data might be immediately pushed via a secure, prioritized I/O channel (e.g., dedicated secure wireless link) to a monitoring system. Routine logs are offloaded via a standard USB 3.0 port when connected to a PC. Personal media data might only be accessible via a specific I/O port upon biometric authentication. This enables intelligent and secure data handling.

  • graph TD
        Source[Data Source] --> MC[Memory Card (AI Engine)]
        MC --> M[Memory (Sensor, Logs, Media)]
        MC --> IOTC[I/O Controller (AI Engine)]
        MC --> USBC[USB Controller]
        IOTC -- Read Data --> M
        IOTC -- Analyze Context (AI) --> Decision{Urgent, Routine, Private?}
        Decision -- Urgent --> Transmit_SecureIO[Secure Prioritized I/O Link]
        Decision -- Routine --> Transmit_USB[USB 3.0 Offload]
        Decision -- Private --> Transmit_AuthIO[Auth. I/O (Biometric)]
        Transmit_SecureIO --> Monitoring[Monitoring System]
        Transmit_USB --> PC[PC / Cloud]
        Transmit_AuthIO --> UserDevice[User Device]
        M -- Data --> IOTC
    

5. The "Inverse" or Failure Mode (Methodological Perspective)

• Derivative 16.9: Emergency Data Beacon Mode

  • Enabling Description: This method focuses on emergency data transmission in adverse conditions (e.g., power loss, environmental damage). The memory card includes a dedicated low-power emergency mode processor and a small, independent battery (supercapacitor). If primary power fails or critical system integrity is compromised, the method automatically transitions to an emergency data beacon mode. It reads a predefined subset of critical data (e.g., last known location, system fault codes) from a hardened, non-volatile portion of memory. This critical data is then transmitted repeatedly, possibly with error correction codes, via a very low-power, robust I/O channel (e.g., a simple UART or an intermittent RF beacon) that can operate on minimal power. The high-speed USB port is entirely disabled.

  • stateDiagram-v2
        [*] --> Normal_Operation
        Normal_Operation --> Emergency_Triggered : Power Fail OR System Damage
        Emergency_Triggered --> Emergency_Mode : Activate Low-Power Processor (Supercapacitor)
        Emergency_Mode --> Read_Critical_Data : From Hardened Memory
        Read_Critical_Data --> Transmit_Beacon : Low-Power Robust I/O (UART/RF)
        Transmit_Beacon --> Transmit_Beacon : (Repeatedly)
        note right of Transmit_Beacon
            High-speed USB Disabled.
            Error Correction Codes (ECC) applied.
        end
    

• Derivative 16.10: Data Quarantine and Selective Access on Malfunction

  • Enabling Description: The method implements a data quarantine mechanism when a malfunction (e.g., detected memory errors, abnormal controller behavior) is identified by the card's internal diagnostics. When a malfunction occurs, the read/write controller marks suspicious data blocks as "quarantined." Any attempt to read data from quarantined blocks via the I/O port (e.g., an SPI port for embedded systems) will be blocked or return an error, preventing propagation of potentially corrupt data to critical systems. However, for diagnostic purposes, the original raw data, including quarantined blocks, can be accessed and transmitted via the USB port (e.g., USB 2.0) to a specialized debugging tool, along with error metadata. This allows for forensic analysis without risking system instability from the I/O connection.

  • flowchart TD
        Start[Start] --> A[Normal Operation]
        A --> B{Internal Diagnostics}
        B -- Malfunction Detected --> C[Data Quarantine Activated]
        C --> D{Mark Suspicious Blocks in Memory}
        D --> E{Read Request from I/O Port}
        E -- Quarantined Block? --> F{Block Read OR Return Error}
        F --> End[End]
        D --> G{Read Request from USB Port}
        G -- All Blocks (including Quarantined) --> H[Transmit Raw Data + Error Metadata via USB]
        H --> End
    

---

Combination Prior Art Scenarios

These scenarios describe combinations of US Patent 8327051's core teachings with existing open-source standards, demonstrating how such integrations would be obvious to a person skilled in the art.

1. US8327051 + Open-Source SD Card Specification (e.g., SD Specifications Part 1 Physical Layer, Part 2 File System Specification):

   • Scenario: A portable handheld memory card embodying the dual-interface (USB and I/O) design, the "same card-insertion direction" and "mutually exclusive pin connection" features of US8327051, but where the I/O port is a Secure Digital (SD) port fully compliant with an open-source SD Card specification (e.g., SDIO or SDXC). The card's internal decompression and decryption circuitry are configured to support widely used open-source audio/video codecs (e.g., Opus, VP9, or H.264 profiles supported by FFmpeg) and potentially open-source digital rights management (DRM) frameworks. Upon insertion into an SD host, the card would output raw audio/video streams (e.g., PCM, uncompressed YUV) directly compatible with open-source embedded media players (e.g., VLC on a Raspberry Pi). Simultaneously, the USB port would allow direct transfer of the original encrypted/compressed files as mass storage.
   • Obviousness/Non-Novelty: Given the long history of SD cards and their public specifications, and the existing "SD Plus" cards that combine SD and USB functionality (as mentioned in the patent's background), it would be an obvious engineering step to integrate the on-card processing (decompression/decryption) described in US8327051 to generate decoded content directly consumable by devices supporting standard open-source SD protocols and media formats. The core contribution of US8327051, intelligent data routing and on-card processing, is applied to widely known and freely available interface specifications and software components.

2. US8327051 + Open-Source USB Mass Storage Class (UMS) Specification (e.g., USB.org UMS Device Class Specification):

   • Scenario: A portable handheld memory card, as generally described in US8327051, where its USB port functions as a standard USB Mass Storage Class (UMS) device adhering to the official USB.org UMS Device Class Specification. The card's USB controller circuitry is further configured to dynamically present multiple "logical units" or file system views to the host device. For instance, if the memory contains encrypted and compressed media, one logical unit might present the decrypted and decompressed versions of these media files (generated on-card using open-source codecs like Vorbis or WebP). Another logical unit could expose the raw, encrypted, and compressed data files for backup or external processing. The I/O port (e.g., a standard Secure Digital port) would operate independently for direct device interfacing.
   • Obviousness/Non-Novelty: The concept of presenting multiple logical units from a single USB mass storage device is a well-established practice (e.g., for devices with read-only firmware partitions and user-writable data partitions). Combining this with the on-card decryption and decompression capabilities detailed in US8327051 to provide both raw and processed versions of the same data via a standard, open-source UMS interface would be an obvious extension for enhancing data accessibility and compatibility. The patent's inventive step of on-card processing is applied to a standard, broadly adopted open-source protocol for flexible data presentation.

3. US8327051 + FreeRTOS/Linux Kernel for Embedded Systems + open-source DRM like Marlin DRM:

   • Scenario: A memory card comprising a low-power embedded processor (e.g., an ARM Cortex-M or MIPS core) capable of running a compact open-source real-time operating system (RTOS) like FreeRTOS, or a minimalist Linux kernel. This embedded OS manages the USB controller circuitry, the I/O controller circuitry (e.g., SPI, I2C), and the on-card decryption and decompression circuits. The memory stores content protected by an open-source DRM scheme (e.g., Marlin DRM, Open IPTV Forum DRM) and compressed using open-source codecs (e.g., LAME for MP3, x264 for H.264 video). The methods of data handling (Claims 9 and 16) would be implemented as software routines within the RTOS. When data is requested, the OS orchestrates the reading, decryption (using open-source crypto libraries), decompression (using open-source codec libraries), and routing to either the USB or I/O port, ensuring adherence to DRM policies defined within the open-source framework.
   • Obviousness/Non-Novelty: The use of embedded operating systems to manage complex hardware interactions and software functions, including cryptographic and decompression operations, is fundamental to modern embedded systems design. Integrating the dual-interface and on-card processing capabilities of US8327051 with an open-source OS, open-source DRM, and open-source codecs would represent a standard software/hardware co-design approach. The patent's core ideas, when implemented using widely available and documented open-source components, become a matter of engineering integration rather than novel invention for a skilled embedded systems developer.