US 6108329

Summary of U.S. Patent 6,108,329

A review of U.S. Patent 6,108,329 reveals the following details regarding the invention and its legal status.

Title: Telephone apparatus used for computer network telephone system

Assignee: The patent was originally assigned to Sony Corp. As of the latest assignment recorded on March 27, 2017, the current assignee is Ironworks Patents LLC.

Inventors:

• Akimasa Oyama
• Hidekazu Watanabe
• Masahiro Asai
• Kazunori Ozawa
• Nobuhiro Tone

Filing Date: December 6, 1996

Issue Date: August 22, 2000

Abstract:
The patent describes a telephone system where terminals within computer networks are connected via servers to transmit data, including audio, over the Internet. A key feature is that when a call is initiated, the destination terminal receives information about the source terminal from a server. Based on this information, the destination terminal can perform specific actions, such as judging whether the source terminal is a pre-approved caller and consequently deciding whether to connect the call.

Plain-Language Overview of Independent Claims:

This patent has one independent claim.

• Claim 1: This claim outlines a telephone apparatus that connects to the internet through a telephone network and a server. This server holds a database with information about multiple telephone apparatuses, including their public phone numbers for Point-to-Point Protocol (PPP) connections and their Internet Protocol (IP) addresses. When a call is made from another telephone, the server sends the caller's information to the receiving telephone. The receiving apparatus can then:
  • Store a list of approved callers.
  • Determine if an incoming call is from the internet (via a modem) or a standard telephone line.
  • If the call is from the internet, it establishes a data connection (PPP).
  • If it's a standard call, it establishes a normal voice connection.
  • Compare the caller's information with its stored list of approved callers to decide whether to connect or disconnect the call.
  • Receive and store an email message from the caller if the user does not answer the call.

A search of the dockets for the Court of Appeals for the Federal Circuit (CAFC) for the year 2026 did not reveal any cases involving U.S. Patent 6,108,329.

No Known Litigation Involving US Patent 6,108,329

As of April 26, 2026, a comprehensive search of publicly available litigation records reveals no known instances of US Patent 6,108,329 being asserted in litigation.

Subsequent targeted searches for litigation involving the current assignee, Ironworks Patents LLC, and this specific patent number in various legal databases, including the Unified Patents portal and PACER, also yielded no results. While Ironworks Patents LLC is known to be an active plaintiff in patent litigation, there is no indication that US Patent 6,108,329 has been among the patents they have enforced.

Therefore, based on the available information, there are no records of any lawsuits where US Patent 6,108,329 has been the subject of an infringement claim.

As a senior PTAB practitioner analyzing US Patent 6,108,329, here is a report on its AIA trial history for a defendant considering their options.

Proceedings overview

There have been zero AIA trial proceedings filed against US patent 6,108,329. This defensive posture means that all claims of the patent remain untested before the PTAB, and a defendant would be the first to challenge its validity in this forum.

Strategic summary

The complete absence of PTAB challenges against US patent 6,108,329 is a significant finding. Here is a breakdown of the strategic landscape for a potential defendant:

• Claim Status: All claims of US patent 6,108,329 (including independent claim 1 and dependent claim 2) are legally intact and have not been canceled or amended through any PTAB trial. They are presumed valid.

• Estoppel Landscape: Because no inter partes review (IPR) or other AIA trial has ever been instituted, the estoppel provisions of 35 U.S.C. § 315(e) do not apply to any potential petitioner. A defendant is free to file an IPR petition on any ground that could be raised under § 102 (anticipation) or § 103 (obviousness) based on prior art consisting of patents or printed publications.

• Pattern Signals: The patent was filed in 1996, issued in 2000, and has been expired since 2016. Its current assignee, Ironworks Patents LLC, is a known patent assertion entity that has engaged in litigation concerning other patents. The lack of PTAB proceedings against this specific patent, especially given its age and the assignee's litigation history with other assets, is unusual. It could suggest that it has not been a central asset in past assertion campaigns, or that past licenses were taken before a PTAB challenge was contemplated.

Recommended next steps

For a defendant facing an assertion of US patent 6,108,329, the path is clear from a PTAB perspective.

• No PTAB Activity Exists: A thorough search of the USPTO's PTAB dockets confirms that no IPR, Post-Grant Review (PGR), or Covered Business Method (CBM) proceedings have ever been filed against this patent. A defendant would be writing on a blank slate.

• Defensive IPR is an Option: Given that no prior challenges have been filed, a defendant has the full range of prior art patents and printed publications available to construct an IPR petition. The primary focus would be on demonstrating that the limitations of claim 1 were anticipated or would have been obvious at the time of the invention.

• Expiration Status: It is crucial to note that this patent expired on December 6, 2016. Any alleged infringement must have occurred before this date. This significantly limits the damages period and may be a primary reason for the lack of recent challenges at the PTAB. Any demand letter citing infringement after this date would be baseless.

Inventors

Based on the patent documentation, the inventors were all likely employees of the original assignee, Sony Corporation, at the time of the 1996 filing.

• Akimasa Oyama

• Hidekazu Watanabe

• Masahiro Asai

• Kazunori Ozawa

• Nobuhiro Tone

There are no unusual patterns, such as mass departures from the assignee, noted in the record.

Original assignee

The original assignee of the patent was Sony Corp. Sony is a major multinational conglomerate corporation headquartered in Tokyo, Japan. In the late 1990s and early 2000s, when this patent was filed and issued, Sony was a global leader in consumer electronics, entertainment, and communication products. While it is unclear if they shipped a specific product that perfectly embodies every limitation of the claims, the invention relates directly to internet telephony, a field in which Sony was an active participant through its computer and electronics divisions. Sony remains a major operating company today.

Assignment timeline

The ownership of this patent has been transferred four times since its filing, moving from the original inventors to the operating company, and subsequently through a series of non-practicing entities.

• 1997-02-21 (executed) / recorded 1997-03-31 — Reel 008459/0764

  • Conveyance: Assignment of Assignors Interest
  • Assignor: Akimasa Oyama, Hidekazu Watanabe, Masahiro Asai, Kazunori Ozawa, Nobuhiro Tone
  • Assignee: Sony Corporation
  • Correspondent: Peter D. Kendall, Oblon Spivak McClelland Maier & Neustadt PC, Arlington, VA
  • Context: Standard initial assignment from inventors to their employer.

• 2010-01-08 (executed) / recorded 2010-01-21 — Reel 023828/0473

  • Conveyance: Assignment of Assignors Interest
  • Assignor: Sony Corporation
  • Assignee: SCA IPLA Holdings Inc.
  • Correspondent: David L. Barnhill, Sony Corporation of America, New York, NY
  • Context: Internal transfer from the parent operating company to a holding company, often as a prelude to a sale of IP assets.

• 2010-01-11 (executed) / recorded 2010-01-21 — Reel 023828/0504

  • Conveyance: Assignment of Assignors Interest
  • Assignor: SCA IPLA Holdings Inc.
  • Assignee: Mobilemedia Ideas LLC
  • Correspondent: Mobilemedia Ideas LLC, Chevy Chase, MD
  • Context: Transfer to a known patent assertion entity just three days after the previous internal transfer, signaling a sale for monetization.

• 2017-03-27 (executed) / recorded 2017-03-28 — Reel 042107/0440

  • Conveyance: Assignment of Assignors Interest
  • Assignor: Mobilemedia Ideas LLC
  • Assignee: Ironworks Patents LLC
  • Correspondent: Ironworks Patents LLC, Chicago, IL
  • Context: Transfer from one patent assertion entity to another, occurring after the patent had already expired.

Timeline diagram

timeline
    title Ownership of US 6108329
    1996 : Filed by Sony inventors
    1997 : Assigned to Sony Corporation
    2000 : Patent Issued
    2010 : Assigned to SCA IPLA Holdings
         : Assigned to Mobilemedia Ideas LLC
    2016 : Patent Expired
    2017 : Assigned to Ironworks Patents LLC

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The patent was moved from an operating company (Sony) to a series of LLCs with names indicating a focus on intellectual property and no evidence of shipping products. The initial transfer to SCA IPLA Holdings followed immediately by a transfer to Mobilemedia Ideas LLC is a clear signal (Reels 023828/0473 & 023828/0504). The final transfer to Ironworks Patents LLC continues this pattern (Reel 042107/0440).

2. Known asserter in the chain — Present. Both Mobilemedia Ideas LLC and the current assignee, Ironworks Patents LLC, are widely recognized as patent assertion entities (NPEs). Public sources from RPX and Unified Patents confirm their history of patent monetization and litigation.

3. Repeat correspondent across the chain — Not present. The correspondent of record changes with each distinct phase of ownership (inventor assignment, Sony internal transfer, transfer to Mobilemedia, transfer to Ironworks). No single attorney or firm appears on multiple, unrelated transfers in this chain.

4. Cascading transfers — Present. The assignment from Sony to SCA IPLA Holdings Inc. was executed on January 8, 2010, and the subsequent assignment from SCA IPLA to Mobilemedia Ideas LLC was executed just three days later on January 11, 2010. Both were recorded on the same day, January 21, 2010 (Reels 023828/0473 & 023828/0504), which is a classic indicator of a structured, rapid transfer to a monetization entity.

5. Pre-litigation transfer — Unclear. While the transfers to known asserters strongly suggest an intent to monetize, which often involves litigation, the previous litigation summary indicates no lawsuits have been filed asserting this specific patent. Therefore, a transfer preceding litigation cannot be confirmed.

6. Bankruptcy fire-sale — Not present. Sony has not undergone bankruptcy proceedings.

7. Privateering — Unclear. Mobilemedia Ideas LLC was a joint venture that included Sony as a founding member. This structure is sometimes used for privateering, where an operating company outsources patent assertion against its competitors. However, without evidence of this patent being used in litigation against a Sony competitor, this cannot be confirmed.

8. Defensive aggregator (anti-NPE) — Not present. The chain of title ends with Ironworks Patents LLC, a known assertion entity, not a defensive aggregator.

Verdict

NPE — high confidence

The ownership history of US Patent 6,108,329 shows multiple, strong signals of non-practicing entity activity. The patent was transferred from its original operating company assignee, Sony, through a rapid, cascading series of assignments to two well-known patent assertion entities, Mobilemedia Ideas LLC and Ironworks Patents LLC (Reels 023828/0473, 023828/0504, and 042107/0440). This clear pattern of transferring an asset from a product-shipping company to entities whose business model is patent monetization confirms its status as an NPE-held patent.

Verification Link: USPTO Assignment Search for Pat. 6,108,329

As a senior technical patent analyst, I have examined the prior art references cited during the prosecution of U.S. Patent 6,108,329. Below is an analysis of each reference and its potential to anticipate the claims of the '329 patent under 35 U.S.C. § 102.

The analysis focuses on the independent claim, Claim 1, as the validity of dependent claim 2 relies upon it. For a reference to anticipate a claim, it must disclose, either expressly or inherently, every limitation of that claim.

Analysis of Cited Prior Art

Based on the file wrapper, the following references were cited by the USPTO examiner.

1. U.S. Patent 5,062,133A: Multi-function telephone call management system

• Publication Date: October 29, 1991
• Filing Date: July 7, 1989
• Brief Description: This patent describes a telephone call management system that can screen incoming calls based on a stored list of telephone numbers. It can automatically answer calls, play customized greetings based on the caller's identity (determined via Caller ID), and record messages. The system can connect to a telephone line and includes features for blocking or selectively accepting calls.
• Potential Anticipation of Claim 1:
  • Elements Disclosed: The '133 patent discloses a system that connects to a telephone network, stores a list of callers in memory, compares incoming caller information (Caller ID) to this list, and takes action (connecting, disconnecting, playing a specific message) based on the comparison. This aligns with elements E(i), E(vi), and E(vii) of claim 1.
  • Elements Not Disclosed: The '133 patent operates entirely within the context of the conventional Public Switched Telephone Network (PSTN) using standard analog signaling and Caller ID. It does not disclose or suggest connecting to a packet-switched network like the internet, the use of a server with a database of IP addresses and PPP phone numbers, establishing a PPP connection, or distinguishing between an internet-based call and a standard telephone call. It also does not mention receiving or storing e-mail messages. Therefore, it fails to disclose key limitations of claim 1, including A, B, C, D, E(iii), E(iv), and E(viii).
  • Conclusion: The '133 patent does not anticipate claim 1.

2. U.S. Patent 5,341,411A: Caller ID blocking method and processing system

• Publication Date: August 23, 1994
• Filing Date: September 21, 1990
• Brief Description: This patent details a system for managing Caller ID information, specifically allowing a subscriber to block their number from being displayed on certain calls. It also describes screening incoming calls based on whether the Caller ID is present or blocked, allowing a user to reject anonymous calls.
• Potential Anticipation of Claim 1:
  • Elements Disclosed: The '411 patent discloses comparing incoming call information against a set of rules (e.g., whether the call is from a blocked number). This relates to the concept of judging a caller found in element E(vi).
  • Elements Not Disclosed: Like the '133 patent, the '411 patent is confined to the PSTN. It does not teach the core concepts of the '329 patent's claim 1, such as the use of an internet network, a server database for PPP/IP information, establishing PPP connections, or handling internet-specific data like e-mail.
  • Conclusion: The '411 patent does not anticipate claim 1.

3. U.S. Patent 5,546,448A: Apparatus and method for a caller ID modem interface

• Publication Date: August 13, 1996
• Filing Date: November 10, 1994
• Brief Description: This patent discloses a modem capable of receiving and interpreting Caller ID information from a telephone line. The modem can pass this information to a connected computer, allowing software on the computer to use the caller's number for various functions, such as database lookups or call logging.
• Potential Anticipation of Claim 1:
  • Elements Disclosed: The '448 patent discloses a modulator/demodulator circuit (modem) connected to a telephone line (related to E(ii)) that processes incoming call data (Caller ID).
  • Elements Not Disclosed: The system in the '448 patent uses the modem to receive Caller ID, not to establish an internet (PPP) connection for a voice call. It does not disclose a server that resolves a terminal's public phone number for a PPP connection, nor does it distinguish between an internet call and a standard PSTN call to route it differently. The fundamental architecture of an internet telephone system as claimed is absent.
  • Conclusion: The '448 patent does not anticipate claim 1.

4. U.S. Patent 5,675,507A: Message storage and delivery system

• Publication Date: October 7, 1997
• Filing Date: April 28, 1995
• Brief Description: This patent describes a unified messaging system where users can access different types of messages (voice, fax, email) from a single mailbox. The system can be accessed over a network. It focuses on the integration of various message formats and providing a unified interface for retrieval.
• Potential Anticipation of Claim 1:
  • Elements Disclosed: The '507 patent discloses a system involving a server and a network that can store different message types, including email (E(viii)). This shows the convergence of telephony and data networks.
  • Elements Not Disclosed: The '507 patent is focused on message storage and retrieval, not the real-time setup of a voice call over the internet as described in claim 1. It does not disclose the critical steps of a server looking up a PPP-dialup number from a database to initiate a connection with a terminal that is currently offline from the internet. The screening of live calls based on an approved list is also not a central feature.
  • Conclusion: The '507 patent does not anticipate claim 1.

5. WO 1996/020553 A2: Unified messaging and long distance communication system

• Publication Date: July 4, 1996
• Priority Date: December 23, 1994
• Brief Description: This international application describes a system that integrates messaging (voice, email, fax) with a communication system that can route long-distance calls over a data network (like the internet) to save costs. It describes using the network to connect two PSTN-connected users.
• Potential Anticipation of Claim 1:
  • Elements Disclosed: This reference discloses the use of a data network for voice calls, involving servers, and the integration of email. This touches on elements A, B, and E(viii).
  • Elements Not Disclosed: The key limitation of claim 1 is the specific mechanism for contacting a terminal that is not persistently connected to the internet. Claim 1 requires a server that stores a public phone number for a PPP connection, dials that number to bring the destination terminal online, and then establishes the internet call. The '553 application does not appear to disclose this specific "dial-out" initiation process based on a stored PPP number. Furthermore, the client-side screening against a user-designated list of approved callers is not described.
  • Conclusion: The '553 application does not anticipate claim 1.

6. WO 1996/038018 A1: Method and system for setting up a speech connection in different networks

• Publication Date: November 28, 1996
• Priority Date: May 24, 1995
• Brief Description: This application from Ericsson describes a method for setting up a voice call between a user on a data network (e.g., Internet) and a user on a traditional telephone network (PSTN/ISDN). It involves a gateway that translates between the packet-switched and circuit-switched networks.
• Potential Anticipation of Claim 1:
  • Elements Disclosed: This reference shows a system with a server/gateway connecting an internet network to a telephone network for voice calls, thus disclosing elements A and B.
  • Elements Not Disclosed: The focus of the '018 application is on interconnecting two different types of networks. It does not describe the specific scenario of two PPP-based terminals where one must be dialed up by the server using a stored telephone number. The claimed client-side apparatus with its specific features—distinguishing call types, screening against an approved caller list, and storing emails on unanswered calls—is not disclosed in this reference.
  • Conclusion: The '018 application does not anticipate claim 1.

Based on this analysis, none of the cited prior art references appear to anticipate claim 1 of US Patent 6,108,329. While the references collectively show a trend towards integrating voice and data networks, none of them disclose the complete combination of limitations recited in the claim, particularly the server-initiated PPP dial-up to an offline terminal combined with the specific call-screening and message-handling features of the destination telephone apparatus.

An analysis of the obviousness of U.S. Patent 6,108,329 ("the '329 patent") under 35 U.S.C. § 103 is provided below, based on the prior art cited by the patent examiner during prosecution. The analysis concludes that the claims of the '329 patent would have been obvious to a person of ordinary skill in the art (PHOSITA) as of the priority date of December 18, 1995.

Deconstruction of Independent Claim 1

Independent claim 1 of the '329 patent can be broken down into the following key limitations for analysis:

a) System Architecture: A telephone apparatus connected via a telephone network to an internet network, which uses a server for transmitting audio data.
b) Server Database: The server maintains a database with user information, including a public phone number for Point-to-Point Protocol (PPP) and an IP address.
c) Caller Information Forwarding: The server sends information identifying the calling party to the destination apparatus.
d) Local Caller List: The destination apparatus stores a list of approved callers in a local memory.
e) Call-Type Determination: The apparatus can determine whether an incoming call is a data call via its modulator/demodulator (modem) or a standard voice call over the telephone network.
f) Data Connection Handling: If the call is a data call, the apparatus establishes a PPP connection.
g) Voice Connection Handling: If the call is not a data call, it establishes a standard telephone connection.
h) Caller Screening: The apparatus compares the received caller information against its stored list of approved callers.
i) Connection Control: The apparatus connects or disconnects the call based on the result of the caller screening.
j) E-mail Storage: The apparatus can receive and store an e-mail message if the user does not answer the call.

Obviousness Combination and Motivation to Combine

The limitations of claim 1 would have been obvious to a PHOSITA by combining the teachings of prior art references that addressed known problems in both the telephony and data networking fields. A particularly strong combination exists in WO 1996/038018 A1 (Ericsson), hereinafter "WO '018", in view of U.S. Patent 5,062,133 (Logotronix) and U.S. Patent 5,546,448 (Multi-Tech Systems).

1. Primary Reference: WO '018 (System for Hybrid Network Voice Calls)

WO '018, with a priority date of May 24, 1995, discloses the core architecture of the '329 patent. It teaches a system for setting up a voice call that travels partially over the traditional Public Switched Telephone Network (PSTN) and partially over a data network like the Internet. The express motivation is to reduce costs for long-distance calls.

• Teaches Limitations (a), (b), (c): The system in WO '018 uses servers (gateways) on a data network. A user connects to a local server via the telephone network. This server looks up information about the destination and routes the call over the data network to a server near the recipient, which then completes the call. This inherently requires the server to maintain and use a database of user/routing information (similar to a phone number and network address) and to handle caller information to establish the end-to-end connection. Therefore, WO '018 discloses the fundamental system of using a server on a data network to facilitate a voice call initiated from a telephone apparatus.

2. Secondary Reference: U.S. Patent 5,062,133 (Call Management and Screening)

U.S. Patent 5,062,133 to Logotronix, filed in 1989, teaches a sophisticated telephone call management system that addresses the problem of unwanted calls.

• Teaches Limitations (d), (h), (i): Logotronix explicitly discloses a system that uses incoming Caller ID information to screen calls. The system stores lists of telephone numbers designated by the user and compares the incoming caller's number to these lists. Based on the comparison, the system can take various actions, including connecting the call, blocking it, or routing it to an answering machine.

• Motivation to Combine WO '018 with Logotronix: A PHOSITA in 1995 would have been motivated to combine the call-screening features of Logotronix with the Internet telephony system of WO '018 for a clear and compelling reason: to solve a known problem. The '329 patent itself notes the desire to "avoid or reject mischievous or misdirected telephone calls" (Col. 4, ll. 5-7). This was a well-understood issue in traditional telephony, and Logotronix provided a well-understood solution. As voice communications moved to a new medium (the Internet), it would have been entirely predictable and obvious to implement the same proven screening features in the new system. The server in WO '018 already processes caller information for routing; it would have been a simple design choice to forward this information to the end user's device to allow it to perform the screening functions already common in advanced telephones, as taught by Logotronix.

3. Secondary Reference: U.S. Patent 5,546,448 (Caller ID Modem Interface)

U.S. Patent 5,546,448 to Multi-Tech Systems, filed in 1994, is directed to the specific technical problem of creating a device that must handle both incoming voice calls and incoming data calls on the same line.

• Teaches Limitations (e), (f), (g): Multi-Tech discloses a modem interface that can intelligently distinguish between different types of incoming calls before answering. It describes a method for detecting the presence of a Caller ID signal (indicating a voice call) versus a modem carrier tone (indicating a data call). This allows the device to respond appropriately—by handling a voice call or establishing a data connection.

• Motivation to Combine with WO '018 and Logotronix: The '329 patent claims a single "telephone apparatus" that performs both as a standard telephone and an Internet telephone. A PHOSITA tasked with building such a device would immediately confront the need for it to differentiate between incoming call types. Multi-Tech provides a direct and explicit solution to this exact implementation challenge. The motivation to incorporate the teachings of Multi-Tech is one of practical necessity; without a mechanism to distinguish call types, a dual-function device would be inoperable. Therefore, adding the call-type determination logic of Multi-Tech to the Internet-capable, call-screening telephone derived from WO '018 and Logotronix would have been an obvious step to make the product functional.

4. The E-mail Limitation (j)

The final limitation, receiving and storing an e-mail if a call is unanswered, would have been obvious in light of the art related to unified messaging, such as WO 1996/020553 A2 (Alphanet). Alphanet, with a 1994 priority date, teaches a unified messaging system that combines voice mail, fax, and e-mail into a single user mailbox. The motivation was user convenience. A PHOSITA developing an Internet-based communication device would naturally look to integrate various Internet-based services. If a user is unavailable for a real-time voice call over the Internet, allowing the caller to send an e-mail—another native Internet data type—is a logical and predictable extension, consistent with the known trend toward unified communications.

Conclusion

The independent claim of the '329 patent represents a combination of known elements from the prior art, with each element performing its expected function. A PHOSITA would have been motivated to combine the Internet telephony architecture of WO '018 with the established call-screening features of Logotronix to provide a desired feature (security/privacy) in a new environment. To make such a dual-use device functional, it would have been necessary and therefore obvious to incorporate a call-type-detection mechanism as taught by Multi-Tech. The result of this combination would be a telephone apparatus possessing all the key features of claim 1 of the '329 patent.

Analysis of Patent Term and Related Applications for U.S. Patent 6,108,329

As of April 26, 2026, the following is a detailed analysis of the patent term, related applications, and expiration date for U.S. Patent 6,108,329.

Patent Term Adjustments (PTA) and Extensions (PTE)

A review of the prosecution history for U.S. Patent 6,108,329 indicates that no Patent Term Adjustment (PTA) or Patent Term Extension (PTE) was granted. The application was filed on December 6, 1996, and issued on August 22, 2000. The provisions for automatic PTA calculations were established for patents filed on or after May 29, 2000, and therefore do not apply to this patent.

Continuity Data: Continuation and Divisional Applications

There are no continuation or divisional applications associated with U.S. Patent 6,108,329. The patent originated from a single non-provisional application, serial number 08/761,612, and does not claim priority to any earlier-filed U.S. applications.

Patent Family Members

U.S. Patent 6,108,329 is part of a larger patent family, with corresponding applications filed in several other countries, all claiming priority to the original Japanese patent application (JP 7-348400) filed on December 18, 1995. The key members of this family include:

• Japan: JP3777638B2
• Europe: EP0781016B1
• Canada: CA2192740C
• Korea: KR100466644B1
• Germany: DE69632383T2

This international filing indicates an initial intent to secure patent rights in major global markets.

Projected Expiration Date

For utility patents filed before June 8, 1995, the term was 17 years from the issue date. For patents filed on or after June 8, 1995, the term is 20 years from the earliest non-provisional U.S. filing date.

U.S. Patent 6,108,329 was filed on December 6, 1996. Therefore, its term is calculated as 20 years from this filing date.

• Filing Date: December 6, 1996
• 20-Year Term End: December 6, 2016

The patent's maintenance fees were paid through the 11.5-year mark, keeping it in force for its full term.

Based on this calculation, U.S. Patent 6,108,329 expired on December 6, 2016. The patent is no longer in force, and its claimed inventions are now in the public domain.

Defensive Disclosure of Derivative Inventions

Reference Patent: U.S. Patent 6,108,329
Title: Telephone apparatus used for computer network telephone system
Purpose: To create prior art that renders incremental improvements obvious or non-novel, this document discloses a series of derivative works based on the core claims of the '329 patent.

---

Derivative Set 1: Based on Material & Component Substitution

Variation 1.1: System-on-a-Chip (SoC) with Integrated Digital Signal Processor (DSP)

• Enabling Description: The telephone apparatus described in claim 1 is implemented using a single Application-Specific Integrated Circuit (ASIC) or System-on-a-Chip (SoC) instead of a general-purpose CPU, ROM, and RAM. This SoC integrates a dedicated Digital Signal Processor (DSP) core for real-time audio compression/decompression (e.g., G.729, Opus codecs) and echo cancellation, offloading these tasks from the main processor. The modem functionality (modulator/demodulator circuit) is also integrated as a software-defined radio (SDR) block within the same silicon, allowing for dynamic updates to support new line modulation standards (e.g., V.92, G.fast) via firmware pushes. The approved caller list is stored in on-chip non-volatile flash memory for faster boot-up and lookup times.
• Diagram:

  graph TD
      subgraph SoC [System-on-a-Chip]
          A[ARM Cortex-M Core] -- Manages OS & Logic --> B{On-Chip Flash};
          A --> C[DSP Core];
          D[SDR Modem Block] -- I/Q Data --> C;
          C -- Audio Codec --> E[Audio I/O];
          B -- Stores --> F[Approved Caller List];
      end
      G[Telephone Network] --> D;
      H[Handset Mic/Speaker] --> E;
      A -- Accesses --> F;
  

Variation 1.2: Field-Programmable Gate Array (FPGA) for Protocol Agnosticism

• Enabling Description: The means for determining call type and establishing a PPP connection is implemented on a Field-Programmable Gate Array (FPGA) rather than a fixed-function CPU. This allows the apparatus to be dynamically reconfigured in the field to support communication protocols beyond PPP, such as SLIP, PPPoE, or proprietary Layer 2 protocols. The FPGA is partitioned into a "modem core" that handles the physical layer signaling and a "protocol core" that manages the data link layer. A small microcontroller supervises the FPGA, loading the appropriate configuration bitstream based on initial handshake tones detected from the server. This provides a hardware-level defense against protocol obsolescence.
• Diagram:

  sequenceDiagram
      participant TN as Telephone Network
      participant FPGA as Reconfigurable Apparatus
      participant Server as Network Server
      TN->>FPGA: Incoming Ring Signal
      FPGA->>Server: Off-hook, Initiate Handshake
      Server-->>FPGA: Transmit Protocol-Specific Tone (e.g., V.8 bis)
      FPGA->>FPGA: Microcontroller selects Bitstream (PPP/SLIP/etc.)
      FPGA->>FPGA: Reconfigure Protocol Core
      FPGA->>Server: Establish Connection (e.g., LCP/IPCP)
      Server-->>FPGA: Send Caller Info Packet
      FPGA->>FPGA: Compare Caller Info to Local List
      FPGA-->>Server: Accept/Reject Connection
  

---

Derivative Set 2: Based on Operational Parameter Expansion

Variation 2.1: High-Latency Satellite Network Adaptation

• Enabling Description: The system is adapted for use over a geostationary satellite link, where round-trip latency can exceed 500 ms. The PPP connection negotiation timers (e.g., LCP Echo-Request timeouts) are expanded to a minimum of 1000 ms to prevent premature disconnection. The server database includes a "Network Type" field (Terrestrial/Satellite) for each user. When the server detects it is calling a satellite-based user, it pre-fetches the caller's information and injects it into the very first data packet following the IPCP address assignment, minimizing the number of round-trips required for the destination apparatus to perform its screening function. Audio data is buffered in a 1-second jitter buffer on the client-side apparatus to compensate for variable latency.
• Diagram:

  stateDiagram-v2
      [*] --> Dialing
      Dialing --> Handshaking: Server Dials User
      Handshaking --> PPP_Negotiation: Line Connected
      state PPP_Negotiation {
          [*] --> LCP
          LCP --> Auth
          Auth --> IPCP
          IPCP --> Done
          note right of LCP
              LCP Echo-Request Timeout > 1000ms
          end note
          note right of IPCP
              Server injects caller info
              with IPCP ACK packet
          end note
      }
      PPP_Negotiation --> Screening: Connection Established
      Screening --> Connected: Caller Approved
      Screening --> Disconnected: Caller Rejected
  

Variation 2.2: Ultra-Low-Power IoT Mesh Network Implementation

• Enabling Description: The invention is scaled down to operate on battery-powered nodes within an 802.15.4 (Zigbee/Thread) mesh network. The "telephone apparatus" is a sensor node. The "server" is a gateway node connecting the mesh to the internet. The "public phone number" is a 64-bit MAC address. To conserve power, nodes remain in a deep sleep state (sub-microamp). A calling node sends a low-frequency radio "wake-up" pattern. Upon waking, the destination node establishes a lightweight CoAP (Constrained Application Protocol) session with the gateway. The gateway sends the source node's MAC address and a security token. The destination node compares this against a micro-list of approved peer addresses stored in its EEPROM. If approved, it opens a full communication channel; otherwise, it immediately returns to sleep.
• Diagram:

  flowchart LR
      subgraph Calling Node
          A[Request to Connect]
      end
      subgraph Gateway
          B[Server Logic]
          C[Peer Address DB]
      end
      subgraph Destination Node (Sleep Mode)
          D{Wake on RF Pattern?}
      end
      A --> B;
      B -- Lookup MAC --> C;
      B -- Send Wake-up + Src MAC --> D;
      D -- Yes --> E{Establish CoAP};
      E --> F[Compare Src MAC];
      F -- Approved --> G[Full Communication];
      F -- Rejected --> H[Return to Sleep];
      D -- No --> H;
  

---

Derivative Set 3: Based on Cross-Domain Application

Variation 3.1: Aerospace - Secure Flight Control Command Authentication

• Enabling Description: The core mechanism is adapted for authenticating commands sent to an unmanned aerial vehicle (UAV). The "server" is the Ground Control Station (GCS). The "telephone apparatus" is the UAV's flight computer. The "internet network" is the command-and-control datalink (e.g., C-band). The GCS maintains a database of authorized operators, mapping their cryptographic public keys ("internet protocol address") to their unique operator IDs ("public phone number"). Before sending a critical command (e.g., "change flight plan"), the GCS sends the command digitally signed with the operator's private key. The UAV receives this command, extracts the operator ID, and compares it against an onboard list of authorized mission operators. It then uses the corresponding public key from its secure memory to verify the signature. If the ID is on the list and the signature is valid, the command is executed.
• Diagram:

  sequenceDiagram
      participant GCS as Ground Control Station
      participant UAV as Flight Computer
      GCS->>UAV: Signed Command {OperatorID, Command, Signature}
      UAV->>UAV: Is OperatorID in Approved List?
      alt Approved
          UAV->>UAV: Verify Signature with Stored Public Key
          alt Signature Valid
              UAV->>UAV: Execute Command
          else Signature Invalid
              UAV->>UAV: Reject Command, Log Anomaly
          end
      else Not Approved
          UAV->>UAV: Reject Command
      end
  

Variation 3.2: AgTech - Authenticated Irrigation Actuator Control

• Enabling Description: The system is applied to a smart agriculture irrigation network. The "server" is a central farm management server connected to the internet. The "telephone apparatus" is a solenoid valve controller in a field, connected via a LoRaWAN network. The server's database maps specific sensor nodes (e.g., soil moisture sensors) to the valve controllers they are authorized to trigger. When a sensor reading crosses a threshold, it sends a data packet to the server. The server verifies the sensor is authorized for a specific valve, then sends a "request to connect" (an "open valve" command) to the valve controller, including the ID of the triggering sensor. The valve controller checks its internal memory to see if that sensor ID is on its pre-configured "approved list." If it is, the controller opens the valve for a prescribed duration. This prevents rogue sensors or network errors from causing flooding.
• Diagram:

  graph TD
      A[Soil Sensor] -- Moisture Data --> B(Farm Mgmt Server);
      B -- Lookup Auth --> C{Sensor-to-Valve DB};
      B -- "Open Valve (Src: SensorID)" --> D[Valve Controller];
      subgraph Valve Controller
          D --> E{Is SensorID in my approved list?};
          E -- Yes --> F[Activate Solenoid];
          E -- No --> G[Ignore Command];
      end
  

Variation 3.3: Consumer Electronics - Smart Home Device Interaction Permissions

• Enabling Description: The invention is used to manage permissions between smart home devices. The "server" is the home's local hub (e.g., Home Assistant). The "telephone apparatus" is a device capable of action, such as a smart lock. The hub's database stores a list of which devices (e.g., a specific user's smartphone, a doorbell camera) are authorized to trigger the lock. When the doorbell camera detects a known face via facial recognition, it sends a message to the hub ("request to connect"). The hub forwards this request, including the camera's unique device ID, to the smart lock. The lock checks its internal list of "approved callers" to see if the doorbell camera is authorized to trigger an unlock command. If so, it unlocks. This prevents an unauthorized device that has gained network access from controlling critical infrastructure.
• Diagram:

  sequenceDiagram
      participant Camera as Doorbell Camera
      participant Hub as Smart Home Hub
      participant Lock as Smart Lock
      Camera->>Hub: "Person Detected: [FaceID]"
      Hub->>Hub: Lookup permissions for FaceID & CameraID
      Hub->>Lock: "Unlock Request (Source: CameraID)"
      Lock->>Lock: Check if CameraID is in Approved List
      alt Is Approved
          Lock->>Lock: Execute Unlock Motor
      else Not Approved
          Lock->>Hub: "Request Denied"
      end
  

---

Derivative Set 4: Integration with Emerging Tech

Variation 4.1: AI-Driven Dynamic Caller Approval List

• Enabling Description: The "list of approved user-designated callers" is no longer static. It is managed by a machine learning model running on the telephone apparatus or a local server. The model is trained on the user's communication patterns (call logs, frequency, duration, time of day) and contact lists. It generates a "trust score" for incoming callers. Instead of a binary approved/denied list, the apparatus now compares the incoming caller's info against a trust threshold. The AI can dynamically add a new caller to a temporary approved list if they are, for example, from the same organization as a frequent contact or are calling shortly after an email exchange was initiated. This provides adaptive, context-aware call screening.
• Diagram:

  flowchart TD
      A[Incoming Call Info] --> B{AI Trust Engine};
      C[Historical Call Logs] --> B;
      D[Contact/Email Data] --> B;
      B -- Trust Score --> E{Score > Threshold?};
      E -- Yes --> F[Connect Call];
      E -- No --> G[Divert to Voicemail/Reject];
      F -- Feedback --> C;
  

Variation 4.2: IoT-Enhanced Contextual Call Handling

• Enabling Description: The telephone apparatus is integrated with the user's IoT environment. The means for judging whether a caller is approved now includes contextual data from IoT sensors. For example, if the user's calendar indicates they are in a meeting and their smartphone's GPS shows them in an office building, the system will automatically reject calls from numbers not on the "Family" or "Urgent" lists. If a smoke detector is triggered, the system automatically elevates the priority of incoming calls from known emergency service numbers, bypassing all other screening.
• Diagram:

  graph TD
      A[Call from Other Apparatus] --> B{Screening Logic};
      C[Approved Caller List] --> B;
      D[IoT Sensor Data] -- Context --> B;
      subgraph IoT Sensors
          E[GPS Location]
          F[Calendar State]
          G[Home Smoke Detector]
      end
      E & F & G --> D;
      B -- Decision --> H[Connect / Disconnect];
  

Variation 4.3: Blockchain-Based Decentralized Caller Identity

• Enabling Description: The centralized server database is replaced with a decentralized identity ledger (a permissioned blockchain). Each "telephone apparatus" has a cryptographic key pair, and its public key serves as its identity, registered on the blockchain. The "list of approved user-designated callers" is a smart contract controlled by the user, which lists the public keys of approved contacts. When a call is initiated, the calling apparatus signs the connection request with its private key. The destination apparatus receives the request, looks up the caller's public key on the blockchain, and checks its own smart contract to see if that key is listed as approved. This removes the single point of failure and control of a central server and provides a tamper-proof, user-controlled identity and permissioning system.
• Diagram:

  sequenceDiagram
      participant Alice as Calling Apparatus
      participant Blockchain as Identity Ledger
      participant Bob as Receiving Apparatus
      Alice->>Bob: Connection Request (Signed with Alice's Private Key)
      Bob->>Blockchain: Fetch Public Key for Alice's ID
      Blockchain-->>Bob: Returns Alice's Public Key
      Bob->>Blockchain: Query my Smart Contract: Is Alice's Public Key approved?
      Blockchain-->>Bob: Returns True/False
      alt Is True
          Bob->>Alice: Accept Connection
      else Is False
          Bob->>Alice: Reject Connection
      end
  

---

Derivative Set 5: The "Inverse" or Failure Mode

Variation 5.1: Graceful Degradation with Cached Credentials

• Enabling Description: The invention is designed to fail safely if the connection to the internet network or the primary server is lost. The telephone apparatus maintains a local, encrypted cache of the X most recently approved or frequently contacted callers' information. When an incoming call is detected, the apparatus first attempts to establish a PPP connection and query the server. If this fails due to a network outage (e.g., timeout), it enters a "limited functionality" mode. It falls back to operating as a standard telephone but uses its local cache and standard Caller ID to screen against this high-priority subset of callers. For these cached callers, it can still provide a distinct ringtone or automatically accept the call. All other calls are sent to a local answering machine.
• Diagram:

  flowchart TD
      A[Incoming Call] --> B{Attempt PPP to Server?};
      B -- Success --> C[Normal Screening];
      B -- Failure/Timeout --> D[Enter Limited Mode];
      D --> E{Check Caller ID};
      E --> F{Is Number in Local Cache?};
      F -- Yes --> G[Connect w/ Priority Handling];
      F -- No --> H[Divert to Local Answering Machine];
  

---

Combination Prior Art Scenarios

1. Combination with SIP (Session Initiation Protocol - RFC 3261): The '329 patent's server logic is integrated into a SIP Proxy/Registrar server. A user's telephone apparatus is a SIP User Agent (UA). When a user is offline, the Registrar holds their last known public telephone number for PPP access. When an INVITE request arrives for that offline user, the Proxy server, instead of returning a "404 Not Found," initiates a dial-out via a PSTN gateway using the stored PPP number. Once the user's SIP UA comes online and REGISTERS, the Proxy server then forwards the queued INVITE. The screening logic is implemented on the UA, which compares the P-Asserted-Identity header of the incoming INVITE against a locally stored "buddy list" or contact directory before responding with "200 OK."

2. Combination with WebRTC (Web Real-Time Communication): The apparatus is a web browser. The "server" is a signaling server using WebSockets. A user's identity is tied to a login, and the server's database maps this identity to a public phone number. When a peer wishes to connect to an offline user, the signaling server sends an SMS message containing a unique URL to the stored phone number. Clicking this URL opens the browser (the "apparatus"), which establishes a WebSocket connection to the signaling server. The server then relays the WebRTC offer/answer negotiation. The browser's JavaScript compares the caller's ID (provided by the signaling server) against contact data stored in the browser's localStorage to decide whether to create and return an SDP answer, effectively connecting or rejecting the call.

3. Combination with XMPP (Extensible Messaging and Presence Protocol - RFC 6120): The telephone apparatus is an XMPP client. The server is an XMPP server. A user's presence state is "Offline." The server database contains a custom vCard field mapping the user's JID (Jabber ID) to a PPP phone number. When another user sends a Jingle (XEP-0166) session-initiate IQ stanza to the offline user, the server intercepts it. It uses a server-side component to dial the stored PPP number via a gateway. Once the client apparatus connects and authenticates, its presence becomes "Available," and the server delivers the queued Jingle stanza. The client then checks if the initiating JID is in its roster (the "approved list") before proceeding with the Jingle session.