US 6553221

I'll search for docket/litigation information on this specific patent number, then summarize based on the authoritative patent text provided.

Let me run a couple more targeted searches to confirm the litigation/status picture.

Search results for "6553221"

I ran targeted searches combining the number with "CAFC docket," "Federal Circuit," "appeal," and "2026 dockets." Findings:

• No Federal Circuit (CAFC) appeal or 2026 docket involving U.S. Patent No. 6,553,221 appeared in any search result. Hits for "6553221" returned only patent-citation cross-references (e.g., Google Patents citing US6553221B2 as prior art in other patents) — no litigation, no PTAB/IPR, no appeal. I could not verify a live USPTO PatentCenter record via direct API access in this session; my status information below comes from the patent record itself and secondary sources.
• Important caution: I did not find any CAFC 2026 case naming this patent, so I am not asserting one exists. If you have a specific docket number, that would need to be confirmed against the Federal Circuit's own docket (which I could not query directly here).

Legal-status note (from the patent record's own legal-events section): maintenance-fee reminder mailed 2006-11-08; lapsed for failure to pay maintenance fees, effective 2007-04-22; patent discontinued 2007-05-23 (37 CFR 1.362). Google Patents lists the status as "Expired – Fee Related." One search snippet mentioning a "20190705" expiration date traces to a different patent's page (US7974398B2) that merely cites US6553221B2, so I do not treat that as this patent's date. The "anticipated expiration 2018-11-17" figure is only a projected date and is superseded by the earlier 2007 lapse.

Concise summary of US 6,553,221 B2

Abstract (as issued): An incoming call notification apparatus which is capable of notifying an operator of a called terminal of an incoming call received when the terminal was not capable of answering an incoming call. When a terminal calls another terminal which is in use or in communication with still another terminal, an incoming call information storage apparatus stores incoming call information of the incoming call. When the called terminal becomes capable of accepting a call, a call setup message transmission apparatus reads out the stored incoming call information, produces a call setup message containing the incoming call information, and then transmits the call setup message to the called terminal. A disconnect apparatus executes incoming call abortion processing after completion of a calling (ALERT) sequence carried out in response to the call setup message during the incoming call processing.

Plain-language overview of the independent claims

Claim 1 — Apparatus. An incoming-call notification apparatus in a telephone system has three cooperating parts:

1. Incoming-call-information storage — stores information about an incoming call that arrived while the called terminal could not accept calls (busy, powered off, or out of service area). This stored info is meant to notify the called terminal of a call that never reached it.
2. Call-setup-message transmission — when the called terminal transitions from call-not-acceptable to call-acceptable, it reads the stored info out, builds a normal call-setup message containing that info, and sends it to the terminal through the ordinary incoming-call sequence. In other words, the exchange fakes a normal incoming call so the terminal's stock firmware displays/stores the missed-call data.
3. Disconnect — after the "calling" (ALERT) step is performed, it tears down the call without ever establishing a call connection, deliberately leaving the incoming-call information resident in the terminal's memory so the user can see/callback the number.

Notably, all three elements are framed in means-plus-function style ("storage means," "transmission means," "disconnect means").

Claim 9 — Method. The method counterpart of claim 1: store incoming-call info for a call received while the terminal was call-not-acceptable; read it out; build a call-setup message containing it; transmit that message within the incoming-call sequence once the terminal becomes call-acceptable; then abort the incoming call without call establishment, again leaving the info in the terminal's memory.

Key dependent claims worth noting (all depend on claim 1 or 9):

• Claim 2/10: defines the call-not-acceptable state as in-use, power-off, or out-of-service-area.
• Claim 3/11: incoming-call info contains at least the caller's subscriber number.
• Claim 4/12: the call-setup message carries a ring/vibration-inhibit signal (embodiment writes value "1001111" into the SET UP "signal information element").
• Claim 5/13: the call-setup message instead carries a ring/vibration-on signal, with disconnect occurring after a predetermined time period (e.g., one second) following the ALERT (value "1000001").
• Claim 7/15: adds a "pseudo incoming call mark" (e.g., "*" prefixed to the number, yielding "*2000") so the exchange can distinguish a pseudo/replayed notification from a real number, and strip the mark before actually dialing back.
• Claim 8/16: adds storage of the call receipt date/time correlated to the incoming-call info, with voice notification of that time when the user initiates the callback.
• Claim 6/14: the system is a mobile telephone system.

Uncertainty / caveats

• I have high confidence in the bibliographic data, abstract, and claim overview above, because they come from the full authoritative patent text supplied.
• I have not verified a current USPTO PatentCenter status or any CAFC/PTAB activity by direct database query; my searches returned no evidence of litigation or appeal for this patent number. Treat the legal-status line as based on the patent's own recorded events, not a live docket check.
• The priority/JP family member is JP10-155493 (published JPH11355439A). I did not confirm the JP application's own grant/abandonment status beyond the record note that it is "not_active / Withdrawn."