US 9979826

US Patent 9,979,826: Connection Specific Selection of Automated Response Messages

Title: Connection specific selection of automated response messages
Assignee: Cedarwood Ventures Inc.
Inventors: Loralee Hajdu, Oliver Hajdu
Filing Date: March 19, 2017
Issue Date: May 22, 2018
Abstract: The patent describes a software and computer processor implemented system and method for providing customized automated responses to different types of incoming electronic messages from various contact sources. It is particularly useful for preventing distracted driving or distractions at work or during rest. The invention's software, often an app on a smartphone or other computerized device, automatically connects to devices like automobile-associated Bluetooth peripherals or Wi-Fi access points. When active, these connections trigger an auto-response mode to incoming messages. The system allows different automated responses to be assigned to specific connected device identification codes or incoming message originators. Various prioritization schemes, such as "last active connection dominates," and how contact-specific responses interact with device-specific responses are also discussed.

---

Plain-Language Overview of Independent Claims:

• Independent Claim 1: This claim describes a method for a handheld computerized device to automatically respond to incoming messages based on its connection to a Bluetooth peripheral. The method involves:

  1. Having a handheld computerized device (like a smartphone) with a processor, Bluetooth, graphical user interface, memory, cellular network, and specialized "reply software."
  2. Having at least one Bluetooth peripheral device that can wirelessly connect to the handheld device, each with a unique Bluetooth identification code (not a phone number).
  3. Using the reply software and user interface to link specific automatic replies to these Bluetooth peripheral identification codes and storing these links in the device's memory.
  4. When the handheld device connects to a Bluetooth peripheral, the reply software detects its identification code, selects the corresponding automatic reply from memory, and then uses that selected reply to automatically respond to any incoming messages received via the cellular network.

• Independent Claim 6: This claim describes a handheld computerized device itself, comprising:

  1. At least one processor, Bluetooth transceiver, graphical user interface, handheld computerized device memory, at least one wireless cellular network transceiver, and reply software.
  2. The device being a smartphone or tablet computer.
  3. The device is set up to identify Bluetooth peripheral devices by their unique identification codes when connected.
  4. The reply software, graphical user interface, and processor are configured to assign and store automatic replies linked to specific Bluetooth peripheral identification codes in the device's memory.
  5. When a Bluetooth peripheral connects, the device and its software are configured to determine the peripheral's identification code (not a telephone number), select and retrieve the associated automatic reply from memory.
  6. The device and software are also configured to use this selected automatic reply to automatically respond to incoming messages received through the cellular network.

---

CAFC 2026 Dockets:
A search of the CAFC 2026 dockets for patent number 9979826 reveals no specific entries within the provided live web search results. However, the Google Patents page for US9979826B1 indicates that the "Family has litigation" and lists several US cases filed in the Texas Western District Court (e.g., 7:26-cv-00152, 1:26-cv-01204, 1:26-cv-01202). These district court cases are from 2026, suggesting ongoing litigation related to the patent, which could potentially lead to appeals at the CAFC in the future, but no direct CAFC dockets for 2026 for this specific patent number were found in the search results provided.US Patent 9,979,826, titled "Connection specific selection of automated response messages", was issued on May 22, 2018, from an application filed on March 19, 2017. The patent is currently assigned to Cedarwood Ventures Inc., and the inventors are Loralee Hajdu and Oliver Hajdu.

Abstract:
The patent describes a software and computer processor implemented system and method for providing customized automated responses to different types of incoming electronic messages from various contact sources. This system is particularly useful for preventing distracted driving or distractions in other contexts (e.g., at work or during rest and relaxation). The core of the invention is an app running on a smartphone or other computerized device that automatically connects to other devices, such as Bluetooth peripherals in a car or Wi-Fi access points. These active connections then automatically trigger an auto-response mode for incoming messages. The system allows for assigning different automated responses based on the connected device's identification code or the originator of the incoming message. The patent also details various prioritization schemes, such as the "last active connection dominates," and how contact-specific automated responses interact with device-specific automated responses.

Plain-Language Overview of Independent Claims:

• Independent Claim 1 (Method Claim): This claim describes a method where a handheld computerized device (like a smartphone) uses its connection status to a Bluetooth peripheral to select and send automatic replies to incoming messages. The method involves:

  1. Having a handheld device equipped with a processor, Bluetooth, graphical user interface (GUI), memory, cellular network capabilities, and specific "reply software."
  2. Having one or more Bluetooth peripheral devices, each with a unique identification code (not a telephone number), capable of wirelessly connecting to the handheld device.
  3. Using the reply software, GUI, and processor to link specific automatic reply messages to these unique Bluetooth peripheral identification codes, storing these associations in the handheld device's memory.
  4. When the handheld device connects via Bluetooth to one of these peripheral devices, the reply software identifies the peripheral's code. This code is then used to retrieve the corresponding automatic reply message from memory.
  5. Finally, when an incoming message is received via the cellular network, the selected automatic reply is used to automatically respond to that message.

• Independent Claim 6 (Device Claim): This claim describes a handheld computerized device designed to perform the functions outlined in Claim 1. The device includes:

  1. A processor, Bluetooth transceiver, graphical user interface, memory, at least one wireless cellular network transceiver, and reply software.
  2. The device itself is a smartphone or tablet.
  3. It is configured to uniquely identify connected Bluetooth peripheral devices by their identification codes.
  4. The reply software, GUI, and processor are set up to assign and store automatic replies linked to specific Bluetooth peripheral identification codes in the device's memory.
  5. When a Bluetooth peripheral connects, the device and its software determine the peripheral's identification code (which is not a telephone number) and use it to select and retrieve the appropriate automatic reply from memory.
  6. The device and software are then configured to use this retrieved automatic reply to respond automatically to incoming messages received through the cellular network.

CAFC 2026 Dockets:
As of April 26, 2026, a direct search of CAFC 2026 dockets for patent number 9979826 did not return specific results. However, information from Google Patents indicates that the patent family is involved in litigation, with several cases filed in the Texas Western District Court in 2026 (e.g., 7:26-cv-00152, 1:26-cv-01204, 1:26-cv-01202). While these are district court cases, they suggest ongoing legal activity that could potentially lead to appeals at the CAFC.

Known litigation involving US patent 9979826 includes the following cases, all filed in the Texas Western District Court:

• Case Number: 7:26-cv-00152

  • Jurisdiction: Texas Western District Court
  • Filing Date: Not explicitly stated in the provided snippet, but implied to be in 2026 given the case number.
  • Plaintiff(s): Not explicitly stated in the provided snippet.
  • Defendant(s): Not explicitly stated in the provided snippet.
  • Outcome or Current Status: Active

• Case Number: 1:26-cv-01204

  • Jurisdiction: Texas Western District Court
  • Filing Date: Not explicitly stated in the provided snippet, but implied to be in 2026 given the case number.
  • Plaintiff(s): Not explicitly stated in the provided snippet.
  • Defendant(s): Not explicitly stated in the provided snippet.
  • Outcome or Current Status: Active

• Case Number: 1:26-cv-01202

  • Jurisdiction: Texas Western District Court
  • Filing Date: Not explicitly stated in the provided snippet, but implied to be in 2026 given the case number.
  • Plaintiff(s): Not explicitly stated in the provided snippet.
  • Defendant(s): Not explicitly stated in the provided snippet.
  • Outcome or Current Status: Active

The patent was assigned to Cedarwood Ventures Inc. on June 19, 2025. Given the filing dates in 2026, it is highly probable that Cedarwood Ventures Inc. is the plaintiff in these cases, but this is not explicitly confirmed by the provided snippets.

Proceedings overview

There is no PTAB activity on file for US9979826B1.

Strategic summary

As there are no PTAB proceedings on file, all claims of US9979826B1 are currently untested by AIA trial proceedings. This means there is no estoppel landscape established by the PTAB regarding this patent. The absence of PTAB activity could indicate that the patent has not yet been asserted aggressively enough to provoke an IPR, or that potential petitioners have not yet identified strong prior art challenges.

Recommended next steps

If you are a defendant facing assertion of US9979826B1, the absence of PTAB activity suggests that all claims remain in their original form. A thorough prior art search would be a critical first step to evaluate potential invalidity grounds if an IPR defense is being considered.

Inventors

• Loralee Hajdu (Individual)
• Oliver Hajdu (Individual)

Original assignee

The original assignee is listed as "Individual" on the Google Patents page at the time of filing. However, a reassignment event on 2025-06-19 indicates that the patent was assigned to Cedarwood Ventures Inc.. It is unclear from the provided information whether the individual inventors shipped a product embodying the claims prior to the assignment to Cedarwood Ventures Inc., or what their primary line of business was. Cedarwood Ventures Inc. is the current assignee and its current status (operating, acquired, dissolved, in bankruptcy) is not explicitly stated, though the patent is marked as "Active".

Assignment timeline

• 2025-06-19 (executed) / recorded 2025-06-19 — Reel 071457/0512
  • Conveyance: Assignment of Assignors Interest
  • Assignor: Hajdu, Loralee; Hajdu, Oliver
  • Assignee: Cedarwood Ventures, Inc.
  • Correspondent: Not specified in the provided patent text for this entry.
  • Context: Transfer to new assignee.

Timeline diagram

timeline
    title Ownership of US 9979826
    2017 : Filed by Individual inventors
    2018 : Issued
    2025 : Assigned to Cedarwood Ventures Inc.

NPE / troll-pattern signals

1. Shell-entity transfer — unclear. The initial assignment is from individuals (the inventors) to Cedarwood Ventures, Inc.. Without further information on Cedarwood Ventures, Inc.'s operations, products, or corporate structure, it's not possible to definitively determine if it's a shell entity.
2. Known asserter in the chain — not present. Cedarwood Ventures, Inc. is not a commonly listed known NPE.
3. Repeat correspondent across the chain — unclear. The provided information for the assignment on reel 071457/0512 does not specify a correspondent name or firm.
4. Cascading transfers — not present. Only one assignment is recorded, from the individual inventors to Cedarwood Ventures, Inc., on 2025-06-19.
5. Pre-litigation transfer — unclear. The patent family has litigation filed in the Texas Western District Court in 2026. The assignment to Cedarwood Ventures, Inc. was on 2025-06-19. This is within 6 months of the 2026 litigation filing, which could suggest a pre-litigation transfer; however, the exact date of the first suit is not specified, only the year.
6. Bankruptcy fire-sale — not present. There is no indication of bankruptcy proceedings for the original inventors or Cedarwood Ventures Inc.
7. Privateering — not present. There is no information to suggest privateering.
8. Defensive aggregator (anti-NPE) — not present. The patent is not assigned to a defensive aggregator.

Verdict

NPE — moderate confidence

The assignment from individual inventors to Cedarwood Ventures, Inc. occurred on 2025-06-19 (Reel 071457/0512), which is within a year before litigation related to the patent family began in the Texas Western District Court in 2026. This proximity in dates between the assignment and the initiation of litigation suggests a potential pre-litigation transfer to an entity that may be engaged in patent assertion. Further investigation into Cedarwood Ventures, Inc. would be needed to confirm its operating status and business model.

USPTO Assignment Center Search for US9979826: https://assignmentcenter.uspto.gov/

To identify the most relevant prior art for US patent 9979826, I will examine the patent citations listed within the patent itself. The patent lists six "Patent Citations" and four "Non-Patent Citations." The USPTO's definition of prior art includes information known publicly before the effective filing date of a U.S. patent application, which can include both patents and non-patent literature.

Here are the patent citations, along with their details and potential anticipation of claims from US9979826:

Patent Citations:

1. US20020065657A1

   • Full Citation: US20020065657A1, "Methods and apparatus for performing speech recognition and using speech recognition results," Telesector Resources Group, Inc., Publication date: 2002-05-30, Priority date: 2000-11-30.
   • Brief Description: This patent application describes methods and apparatus for performing speech recognition and using the results. While not directly focused on automated message responses based on peripheral connections, it broadly covers systems that process incoming communications and take action based on their content, which could be a foundational element for automated response systems.
   • Potential Anticipation (35 U.S.C. § 102): This reference might generally anticipate the concept of a computerized device processing incoming data for some form of automated action, as broadly described in the background of US9979826. However, it does not appear to specifically anticipate the "peripheral connection status" as a trigger for selecting automated responses, which is central to claims 1 and 6 of US9979826.

2. US20120117169A1

   • Full Citation: US20120117169A1, "Time-Based Computer Control," Robert Plotkin, Publication date: 2012-05-10, Priority date: 2010-11-08.
   • Brief Description: This patent application discloses systems and methods for controlling computer functions based on time or schedules. This focuses on a different contextual trigger (time) than the peripheral connection status emphasized in US9979826.
   • Potential Anticipation (35 U.S.C. § 102): This reference does not appear to directly anticipate the core elements of claims 1 and 6, which rely on peripheral connection status, but rather on time-based triggers.

3. US20130097270A1

   • Full Citation: US20130097270A1, "Conditional Auto-Responder," Yagi Corp., Publication date: 2013-04-18, Priority date: 2010-09-24.
   • Brief Description: This patent application describes a conditional auto-responder system. The term "conditional" suggests that responses are sent based on certain criteria. While it is an auto-responder, the specific conditions (e.g., peripheral connection status) are key to distinguishing US9979826.
   • Potential Anticipation (35 U.S.C. § 102): This reference could potentially anticipate the general concept of an auto-responder to incoming messages. However, without knowing the specific "conditions" described, it's difficult to assess if it anticipates the unique peripheral-based selection method of claims 1 and 6 of US9979826. It might anticipate aspects of claim 2 regarding assigning automated replies and priorities to items on a dataset if "conditions" include contact information.

4. US20130097269A1

   • Full Citation: US20130097269A1, "Context-Sensitive Auto-Responder," Yagi Corp., Publication date: 2013-04-18, Priority date: 2010-09-24.
   • Brief Description: This patent application, also by Yagi Corp., describes a "context-sensitive" auto-responder. "Context-sensitive" implies that the system adapts its responses based on the current situation. This is closer to the spirit of US9979826, which uses peripheral connection as a form of context.
   • Potential Anticipation (35 U.S.C. § 102): This reference is highly relevant. Depending on what "context" is defined to include, it could potentially anticipate aspects of claims 1 and 6, especially if "context" encompasses the detection of connected peripheral devices. Claim 4, which relates to preventing distracted driving by using an "equipment associated Bluetooth peripheral device," could also be anticipated if the context-sensitive nature of this prior art includes such device connections. Further analysis of the detailed description of US20130097269A1 would be needed to determine if the specific mechanism of using peripheral identification codes for selecting responses is disclosed, which is a key distinguishing feature of US9979826.

5. US20130157629A1

   • Full Citation: US20130157629A1, "Customizable media auto-reply systems and methods," Realnetworks, Inc., Publication date: 2013-06-20, Priority date: 2011-12-14.
   • Brief Description: This patent application describes systems and methods for customizable media auto-reply. The "customizable" aspect aligns with US9979826's ability to program different messages.
   • Potential Anticipation (35 U.S.C. § 102): This reference could potentially anticipate the "customized automated responses" aspect of US9979826. However, it's unclear if the customization is triggered by "peripheral connection status" as in claims 1 and 6. If the customization is solely based on content or sender, it may not directly anticipate the core invention of US9979826.

6. US20130165171A1

   • Full Citation: US20130165171A1, "Method and apparatus for providing session initiator privilege, priority and presence notification for push-to-talk chat group communications," Motorola Solutions, Inc., Publication date: 2013-06-27, Priority date: 2011-12-21.
   • Brief Description: This patent application pertains to communication management in push-to-talk (PTT) chat groups, focusing on privileges, priority, and presence. While it deals with managing communications and priorities, it is specific to PTT and does not appear to involve peripheral connection status for selecting automated responses to general incoming messages.
   • Potential Anticipation (35 U.S.C. § 102): This reference is unlikely to anticipate claims 1 or 6 of US9979826, as its focus is on PTT communication management rather than peripheral-triggered auto-responses to general incoming messages. It might, however, be considered relevant to claim 2 concerning "reply priority" if the PTT system had analogous priority schemes.

Non-Patent Citations:

The non-patent citations indicate the existence of similar features in operating systems and apps prior to the priority date of US9979826 (May 18, 2013):

1. "Android's Do Not Disturb driving mode is going big in 2018": Dated Nov. 10, 2017. This post-dates the priority date of US9979826 (May 18, 2013) and therefore is not prior art.
2. "Iphone User Guide for iOS 11": Dated Sep. 19, 2017. This post-dates the priority date of US9979826 (May 18, 2013) and therefore is not prior art.
3. "Windows Phone 8 Update 3 (GDR3)": Dated Oct. 25, 2013. This post-dates the priority date of US9979826 (May 18, 2013) and therefore is not prior art.
4. "Windows Phone 8 Update 3: Driving Mode": Dated Oct. 15, 2013. This post-dates the priority date of US9979826 (May 18, 2013) and therefore is not prior art.

Therefore, the non-patent citations provided do not serve as prior art for US9979826 as they all post-date the patent's priority date.

Most Relevant Prior Art:

Based on the brief descriptions, US20130097269A1 ("Context-Sensitive Auto-Responder" by Yagi Corp.) appears to be the most relevant patent citation. Its focus on "context-sensitive" auto-responding suggests it might come closest to anticipating the core invention of using external conditions (which could include peripheral connections) to trigger specific automated responses, as claimed in US9979826. Further investigation into the specifics of what "context" entails in US20130097269A1 would be crucial for a definitive determination of anticipation under 35 U.S.C. § 102 for claims 1 and 6, particularly the use of "peripheral device identification code" to select and retrieve specific replies.

The other auto-responder patents (US20130097270A1 and US20130157629A1) are also relevant to the broader concept of automated replies but lack the specific emphasis on peripheral connection as a trigger described in US9979826.

Obviousness Analysis under 35 U.S.C. § 103 for US Patent 9,979,826

A person having ordinary skill in the art (PHOSITA) in May 2013, when the earliest priority application for US Patent 9,979,826 was filed, would have found the claimed invention obvious in light of combinations of the identified prior art references and general knowledge in the field of mobile computing and communication.

The patent US9979826 describes a system and method where a handheld computerized device (e.g., a smartphone) uses its connection to a Bluetooth peripheral to select and send automated responses to incoming messages. Key aspects include associating specific replies with peripheral identification codes, retrieving these replies upon connection, and using them to automatically respond to messages, often in contexts like preventing distracted driving.

Combination of Prior Art References

The following prior art references, all predating the May 18, 2013 priority date of US9979826, are highly relevant:

1. US20130097269A1 (Yagi Corp.) - "Context-Sensitive Auto-Responder" (Publication Date: April 18, 2013)

   • Disclosure: This patent application teaches systems and methods for context-sensitive auto-response to incoming communications. It describes defining one or more contexts, each including context parameters. Rules are defined with triggers (e.g., detection of an incoming communication and satisfaction of context parameters) and actions (e.g., sending an auto-response).

2. US20130157629A1 (Realnetworks, Inc.) - "Customizable media auto-reply systems and methods" (Priority Date: December 14, 2011; Publication Date: June 20, 2013)

   • Disclosure: This patent application describes systems and methods that allow for customizable auto-reply messages.

Obviousness of Independent Claims 1 and 6

Independent claims 1 (method) and 6 (device) form the core of the invention. Their obviousness can be established by combining Yagi '269, Realnetworks '629, and the general knowledge of a PHOSITA regarding smartphone capabilities and Bluetooth technology by May 2013.

Analysis of Claim Elements:

• Handheld computerized device (smartphone) with processor, Bluetooth transceiver, GUI, memory, cellular network transceiver, and reply software: Yagi '269 describes a "system" for context-sensitive auto-response that would inherently run on a computerized device. By 2013, smartphones were ubiquitous, possessing all these hardware and software components. The "reply software" in US9979826 is embodied by Yagi's auto-response system.
• At least one Bluetooth peripheral device with an individually identifiable Bluetooth peripheral device identification code: Bluetooth technology, including devices with unique identification codes (e.g., MAC addresses or device names), was well-established and widely used in conjunction with smartphones by 2013. A PHOSITA would be fully aware of how to identify connected Bluetooth devices.
• Using reply software, GUI, processor to assign Bluetooth peripheral device linked automatic replies to Bluetooth peripheral device identification code, and storing in memory: Yagi '269 teaches that triggers can include the "satisfaction of one or more context parameters." A PHOSITA would readily recognize that the connection status or identification code of a Bluetooth peripheral device is a direct and easily detectable "context parameter" on a smartphone. Realnetworks '629 teaches that auto-reply messages should be "customizable." Therefore, it would be an obvious design choice for a PHOSITA to allow users to assign specific, customized auto-reply messages (as taught by Realnetworks '629) to these Bluetooth peripheral connection contexts (as context parameters in Yagi '269) and store these associations in the device's memory.
• When Bluetooth connecting to peripheral, reply software determines ID code, uses ID code to select and retrieve linked automatic reply: If a Bluetooth connection is established as a "context parameter" within Yagi's system, then the detection of this connection and the determination of its unique ID (an inherent part of Bluetooth pairing/connection) would naturally trigger the selection and retrieval of the associated custom reply from memory.
• In response to an incoming message from cellular network transceiver, using selected/retrieved reply to automatically respond: Yagi '269 explicitly teaches "sending an auto-response to the incoming communication." On a smartphone, "incoming communication" would typically be received via the wireless cellular network transceiver.

Motivation to Combine:
A PHOSITA in 2013, faced with the desire to create a more intelligent and flexible auto-responder for smartphones, would be motivated to combine the teachings of Yagi '269 and Realnetworks '629. Yagi '269 provided the foundational framework for context-sensitive auto-responses. Realnetworks '629 highlighted the importance of message customizability. It would be an obvious step to integrate these concepts by using readily available contextual information from smartphones, such as connections to Bluetooth peripherals. Bluetooth connections are a natural indicator of a user's current environment or activity (e.g., driving with a car's hands-free system, exercising with a headset). Leveraging the unique identification codes of these peripherals to trigger specific, customizable auto-replies would provide the desired flexibility and responsiveness in a technically straightforward manner.

Obviousness of Dependent Claims

The additional features described in the dependent claims would also have been obvious to a PHOSITA when building upon the combined teachings of Yagi '269 and Realnetworks '629, along with general knowledge:

• Claim 2 (Dataset/Contact specific, reply priority): Yagi '269's framework of "rules" and "context parameters" readily extends to including the sender's identity (a "contact" from a "dataset") as a context parameter. Assigning specific messages to contacts was a known feature in various communication management systems. Implementing a prioritization scheme between different types of rules (e.g., peripheral-specific vs. contact-specific) is a routine engineering task to manage conflicting conditions in a rule-based system.

  • Motivation: To provide a more granular and personalized auto-response experience, a PHOSITA would be motivated to allow message customization based on the sender and to implement logical rules for resolving conflicts, thereby enhancing user control and system utility.

• Claim 3 (Reply differs by dataset item and last connected peripheral): The "reply differs according to an item in a dataset" is covered by the reasoning for Claim 2. The concept of using the "peripheral connection ID of a Bluetooth peripheral device last connected" as a prioritization scheme when multiple peripherals are connected is a simple and intuitive heuristic. It's a common design choice to infer the user's current primary context from the most recent interaction. The patent itself notes this as a common default priority.

  • Motivation: To effectively manage scenarios where multiple contextual triggers (peripherals) might be simultaneously active, a PHOSITA would implement a straightforward prioritization logic like "last connected" to ensure a predictable and user-friendly behavior.

• Claim 4 (Prevent distracted driving/operation, equipment associated BT peripheral, customized for originator): The problem of distracted driving was a significant societal concern well before 2013, and the use of hands-free Bluetooth devices in vehicles was common. Applying the context-sensitive auto-responder (from Yagi '269 and Realnetworks '629) to automatically respond when a handheld device is connected to an "equipment associated Bluetooth peripheral device" (e.g., a car's hands-free system) for the explicit purpose of preventing distracted driving would be an obvious application driven by the known problem. Customizing responses for the originator is covered by Claim 2.

  • Motivation: Given the well-publicized dangers of distracted driving, a PHOSITA would be strongly motivated to apply existing context-sensitive auto-response technologies to this specific, high-impact use case, using readily available car-related Bluetooth connections as the contextual trigger.

• Claim 5 (Handheld device is any of a smartphone or tablet device): This is a statement of capability for common devices existing prior to 2013 and is inherently obvious.

• Claim 7 (Device claim for distracted driving): This is the device counterpart to method claim 4 and is obvious for the same reasons.

• Claim 8 (Incoming message types): Yagi '269's "incoming communications" is broad enough to encompass various message types. Extending auto-reply functionality from basic text messages (SMS) to multimedia messages (MMS), video content, and other communication types (e.g., social media interactions) is a routine enhancement for a PHOSITA to make a comprehensive auto-responder system, as different communication protocols and formats were well-known by 2013.

  • Motivation: To maximize the utility and applicability of the auto-response system across all prevalent forms of digital communication on a smartphone.

• Claim 9 (Plurality of peripheral device linked automatic replies): This is a direct consequence of combining the context-specificity of Yagi '269 with the customizability of Realnetworks '629. If one can assign a message to a peripheral, one can assign a plurality of distinct messages to a plurality of peripherals, fulfilling a recognized need for flexibility in prior art systems.

  • Motivation: To overcome the limitations of prior art systems that lacked sufficient flexibility for a variety of different automatic response messages, a PHOSITA would logically allow for the assignment of multiple, distinct messages to different peripheral contexts.

• Claim 10 (Reply selected based on the peripheral device identification code of the last connected peripheral device): As discussed for Claim 3, this is a specific, logical, and intuitive prioritization scheme for managing multiple connected peripherals, and its implementation would be a routine design choice. The patent itself identifies this as a potential default.

  • Motivation: To establish a clear and easily understandable default behavior for the auto-response system when multiple peripheral contexts are detected simultaneously.

Conclusion

Based on the combination of US20130097269A1 (Yagi Corp.) and US20130157629A1 (Realnetworks, Inc.), coupled with general knowledge of smartphone capabilities and Bluetooth technology, a PHOSITA would have found the independent claims 1 and 6, and by extension the dependent claims 2-5 and 7-10, of US Patent 9,979,826 obvious by the priority date of May 18, 2013. The motivation would stem from a desire to create a more flexible, context-aware, and user-configurable auto-response system for smartphones, applying known technologies to common user scenarios, including addressing public safety concerns like distracted driving.

To provide a comprehensive overview of US Patent 9,979,826, including patent term adjustments (PTA), patent term extensions (PTE), continuation applications, divisional applications, related family members, and projected expiration date, the following details are gathered:

Patent Term Adjustments (PTA):
Patent Term Adjustment (PTA) is granted to compensate patent holders for delays caused by the USPTO during the prosecution of a utility or plant patent application. It adds additional time to the standard 20-year patent term from the filing date. The calculation of PTA is based on specific timeframes the USPTO must meet, such as issuing an office action within 14 months of filing, responding to replies within four months, and issuing a patent within 36 months of filing. Applicant-caused delays can reduce the calculated PTA.

Without access to the official USPTO patent file wrapper for US9979826, the specific PTA granted for this patent cannot be definitively stated. However, the Google Patents entry for US9979826B1 does not explicitly list any PTA days, which would typically be included in the "Info" section if a significant adjustment was made.

Patent Term Extensions (PTE):
Patent Term Extension (PTE) is available under 35 U.S.C. § 156 for patents claiming certain human drug products, medical device products, animal drug products, veterinary biological products, and food or color additive products. This extension aims to restore time lost due to premarket government approval processes from regulatory agencies like the FDA.

US Patent 9,979,826, titled "Connection specific selection of automated response messages," relates to software and computer-implemented methods for automated message responses, particularly for preventing distracted driving. This subject matter does not fall within the categories eligible for PTE (e.g., drugs, medical devices, food additives). Therefore, it is highly unlikely that US9979826 has received or is eligible for any Patent Term Extension.

Continuation Applications:
A continuation application is a second application for the same invention claimed in a prior nonprovisional application, filed before the original application becomes abandoned or patented. It uses the same specification as the parent but allows for pursuing additional or different claims to the invention. The patent term for a continuation application is generally calculated from the filing date of the earliest application in the chain to which priority is claimed.

US9979826B1 is itself a continuation-in-part of U.S. patent application Ser. No. 15/249,372, filed Aug. 27, 2016, which in turn was a continuation-in-part of application Ser. No. 14/273,748, filed May 9, 2014. Application Ser. No. 14/273,748 claimed the priority benefit of U.S. provisional patent 61/825,017, filed May 18, 2013.

The patent family also includes other applications claiming priority from the May 18, 2013 date:

• US15/950,887 (leading to US10841248B1)
• US16/193,611 (leading to US11297014B2)
• US17/098,354 (leading to US11516643B1)

Divisional Applications:
A divisional application is a type of continuing application that is directed to a different, but related, invention disclosed in the original application. It is filed when an examiner determines that an application contains more than one independent and distinct invention, requiring the applicant to restrict the claims to one invention. There is no explicit mention of divisional applications directly stemming from the prosecution of US9979826 in the provided text. However, a continuation-in-part (CIP) application, which US9979826 is, can itself have continuation or divisional applications.

Related Family Members:
The Google Patents page for US9979826B1 lists several related applications:

• Priority Applications:
  • US15/462,874 (this patent)
  • US15/950,887 (resulted in US10841248B1)
  • US16/193,611 (resulted in US11297014B2)
  • US17/098,354 (resulted in US11516643B1)
• Applications Claiming Priority (from the May 18, 2013 priority date):
  • US201361825017P (provisional application)
  • US14/273,748 (resulted in US9432499B2)
  • US15/249,372 (resulted in US9602988B1)
  • US15/462,874 (this patent)
• Related Parent Applications:
  • US15/249,372 (Continuation-In-Part of which US9979826 is a continuation-in-part)
• Related Child Applications:
  • US15/950,887 (Continuation-In-Part)

Projected Expiration Date:
The term of a U.S. patent generally lasts 20 years from its earliest effective filing date. US9979826 claims priority from US Provisional Patent 61/825,017, filed on May 18, 2013.

Therefore, without any Patent Term Adjustment, the projected expiration date would be 20 years from the earliest priority date.

• Earliest priority date: May 18, 2013
• Standard 20-year term ends: May 18, 2033

However, the Google Patents page explicitly states an "Anticipated expiration" date of 2034-05-09. This indicates that there was likely a Patent Term Adjustment granted, extending the patent term by approximately 11 months and 21 days (from May 18, 2033, to May 9, 2034). The precise calculation of PTA would require reviewing the USPTO's official file for the patent.

Defensive Disclosure for US Patent 9,979,826: Connection Specific Selection of Automated Response Messages

As a Senior Patent Strategist and Research Engineer specializing in Defensive Publishing, this document aims to establish comprehensive prior art for future incremental improvements related to US Patent 9,979,826. By detailing various derivative implementations, we seek to render obvious or non-novel any subsequent attempts by competitors to patent similar enhancements. This disclosure leverages the core inventive concepts of US9979826 (method Claim 1 and device Claim 6) to describe advanced, alternative, and cross-functional embodiments.

---

Derivative Variations for Core Claims (Claim 1 & Claim 6)

The following derivatives expand upon the core claims of US Patent 9,979,826, which describe a handheld computerized device using peripheral connection status to select and send automated responses to incoming messages. Each derivative provides a technical enabling description and a corresponding Mermaid.js diagram.

---

1. Material & Component Substitution Derivatives

Derivative 1.1: Multi-Protocol Wireless Peripheral Interrogation System

Enabling Description:
Instead of solely relying on Bluetooth, the handheld computerized device (e.g., smartphone, industrial tablet) is equipped with an integrated multi-protocol wireless transceiver module comprising components for IEEE 802.11 (Wi-Fi), Near Field Communication (NFC) via ISO/IEC 18092/21481 compliant transceivers, Ultra-Wideband (UWB) radios based on IEEE 802.15.4a, and sub-1 GHz proprietary RF modules. The "reply software" now includes a multi-protocol peripheral management daemon that continuously interrogates the local wireless environment across all active protocols. Each peripheral, irrespective of its communication standard (e.g., Wi-Fi access point, NFC tag, UWB anchor, proprietary RF sensor), broadcasts or is configured with a unique, protocol-specific identification code (e.g., MAC address for Wi-Fi, NDEF message payload for NFC, device ID for UWB, proprietary serial for RF). The system maintains an associative database linking these diverse peripheral identification codes to a plurality of automated response messages. Upon detection of a connection or proximity event (e.g., Wi-Fi association, NFC tag read, UWB ranging within a defined threshold, proprietary RF beacon detection), the daemon triggers the reply software to determine the peripheral's ID, select the associated response, and dispatch it via the cellular network transceiver in response to an incoming message. This extends the "peripheral identification code" beyond Bluetooth to a broader range of wireless connection methods.

graph TD
    A[Handheld Device] --> B{Multi-Protocol Wireless Transceiver}
    B --> C{Wi-Fi Module (802.11)}
    B --> D{NFC Module (ISO/IEC 18092)}
    B --> E{UWB Radio (802.15.4a)}
    B --> F{Sub-1 GHz RF Module}
    C --> G1[Wi-Fi AP ID]
    D --> G2[NFC Tag ID]
    E --> G3[UWB Anchor ID]
    F --> G4[Proprietary RF Sensor ID]
    G1 & G2 & G3 & G4 --> H[Peripheral Management Daemon]
    H --> I{Associative Database: ID -> Auto Reply}
    I --> J[Reply Software]
    K[Incoming Message (Cellular)] --> J
    J --> L[Select & Send Auto Reply]

Derivative 1.2: Hybrid Wired/Wireless Sensor Array for Contextual Response

Enabling Description:
This derivative utilizes a hybrid peripheral connection model where the handheld device integrates an array of ambient and direct-contact sensors, including optical (e.g., LiDAR, IR proximity), acoustic (e.g., ultrasonic ranging, microphone for ambient sound analysis), and galvanic skin response (GSR) sensors, in addition to standard wired (USB-C, audio jack) and wireless (Bluetooth, Wi-Fi) interfaces. Each sensor or wired connection, when active or within a predefined threshold, contributes to a composite "contextual state identifier" for the handheld device. For instance, a wired connection to a diagnostic port combined with an acoustic sensor detecting specific machinery noise could form one context. The "peripheral identification code" is generalized to this "contextual state identifier," which is a dynamically generated hash or concatenation of active sensor inputs and direct peripheral connection IDs. The reply software incorporates a multi-modal sensor fusion engine that processes real-time data from these sensors, identifies the current contextual state, and matches it against a pre-configured database of "contextual state identifiers" linked to specific automated response messages. When an incoming message is detected, the system retrieves the reply corresponding to the current fused contextual state, which implicitly includes or supersedes traditional peripheral connection status.

graph TD
    A[Handheld Device] --> B[Multi-Modal Sensor Array]
    B --> C1(Optical Sensors)
    B --> C2(Acoustic Sensors)
    B --> C3(GSR Sensors)
    B --> C4(Wired Interfaces: USB-C, Audio)
    C1 --> D1[Sensor Data]
    C2 --> D2[Audio Signatures]
    C3 --> D3[Physiological Data]
    C4 --> D4[Wired Peripheral ID]
    D1 & D2 & D3 & D4 --> E{Sensor Fusion Engine}
    E --> F[Generate Composite Contextual State ID]
    F --> G{Associative Database: Context ID -> Auto Reply}
    G --> H[Reply Software]
    I[Incoming Message (Cellular)] --> H
    H --> J[Select & Send Auto Reply]

---

2. Operational Parameter Expansion Derivatives

Derivative 2.1: Industrial-Scale Automated Fleet Communication Management

Enabling Description:
This implementation scales the invention to an industrial fleet management system, where hundreds or thousands of mobile assets (e.g., delivery vans, autonomous agricultural vehicles, mining equipment) are equipped with ruggedized handheld computerized devices. The "handheld computerized device" is a vehicle-mounted industrial tablet. The "Bluetooth peripheral devices" are now industrial-grade, long-range wireless communication modules (e.g., LoRaWAN, Zigbee, custom mesh networks) embedded within specific vehicle components (e.g., engine diagnostics unit, cargo bay sensor, specialized attachments) or fixed infrastructure (e.g., loading dock beacons, field boundary markers). Each module possesses a robust, tamper-resistant digital identification code. The "reply software" is a distributed application, with a local component on each tablet and a central fleet management server. When a tablet connects to or detects these industrial peripherals/beacons (e.g., entering a loading zone, engaging a specific attachment), its local reply software transmits the peripheral ID and current operational status to the central server, which then updates the tablet's local repository of "device linked automatic replies" or dictates an immediate response. Incoming messages (e.g., dispatch orders, critical alerts from IoT sensors) are routed through a dedicated enterprise cellular network. The system automatically responds with contextually appropriate messages (e.g., "Cargo loading in progress, estimated completion 15:30 UTC" or "Engaging autonomous harvesting sequence, unable to respond to voice calls"). The system operates 24/7 across extreme temperatures (-40°C to +85°C) and under heavy electromagnetic interference, requiring industrial-grade transceivers and error correction protocols.

graph TD
    A[Industrial Tablet (Vehicle-Mounted)] --> B{Industrial Wireless Transceivers}
    B --> C1(LoRaWAN Module)
    B --> C2(Zigbee Module)
    B --> C3(Custom Mesh RF)
    C1 & C2 & C3 --> D[Vehicle Component/Infrastructure Peripheral IDs]
    D --> E[Local Reply Software & Status Tx]
    E --> F[Enterprise Cellular Network]
    F --> G[Central Fleet Management Server]
    G --> H{Distributed DB: Peripheral ID & Context -> Auto Reply Rules}
    G --> I[Remote Configuration & Updates]
    I --> J[Local Reply Software & DB (Tablet)]
    K[Incoming Message (Dispatch/IoT Alert)] --> J
    J --> L[Select & Send Auto Reply (Enterprise Network)]

Derivative 2.2: Hyperscale Datacenter Rack Management with Automated Alerts

Enabling Description:
In this scenario, the "handheld computerized device" is a mobile management unit used by technicians within a hyperscale datacenter, which experiences extreme data frequencies (terabit-per-second) and heat loads. The "Bluetooth peripheral devices" are miniaturized, high-frequency (e.g., millimeter-wave, mmWave) wireless transponders integrated into each server rack, individual server blade, power distribution unit (PDU), and cooling apparatus. Each transponder broadcasts a unique hardware serial ID and real-time status (e.g., temperature, power consumption). The mobile management unit's reply software is configured to associate specific mmWave transponder IDs with pre-defined automated response templates relevant to hardware status or maintenance tasks. When a technician brings the mobile unit into proximity with a specific rack, the mmWave connection is established, the transponder ID is acquired, and the unit's reply software activates a context-specific auto-response profile. Incoming messages, often in the form of critical alerts from the datacenter's monitoring system (via an internal, isolated cellular network or Wi-Fi mesh), trigger the automated reply. For instance, if an alert comes for a high-temperature rack (Peripheral ID X), and the mobile unit is connected to it, the reply could be "Technician XX-YY is on-site at Rack X, alert acknowledged, initiating thermal remediation protocol." This system operates under stringent low-latency requirements, with sub-millisecond response times for critical alerts, leveraging mmWave for high-density, localized data transfer.

graph TD
    A[Mobile Management Unit] --> B{mmWave Transceiver}
    B --> C[Server Rack Transponder ID]
    B --> D[Server Blade Transponder ID]
    B --> E[PDU Transponder ID]
    C & D & E --> F[Reply Software (Unit)]
    F --> G{Local DB: Transponder ID -> Auto Reply Template}
    H[Incoming Alert (Datacenter Network)] --> F
    F --> I[Select & Send Auto Reply (Internal Network)]
    subgraph Hyperscale Datacenter
        C,D,E
    end

---

3. Cross-Domain Application Derivatives

Derivative 3.1: Logistics & Supply Chain - Automated Freight Manifest Updates

Enabling Description:
In the logistics and supply chain domain, the "handheld computerized device" is a ruggedized tablet carried by a freight handler. The "Bluetooth peripheral devices" are RFID (Radio-Frequency Identification, e.g., EPCglobal Gen2) readers and Near-Field Communication (NFC) scanners integrated into the tablet, as well as RFID tags attached to individual cargo containers, pallets, or specific warehouse zones (e.g., "Loading Dock 17", "Cold Storage Zone B"). Each RFID tag or NFC beacon carries a unique identifier linked to cargo manifest data or location information. The reply software on the tablet is configured to associate these peripheral (tag/beacon) identification codes with automated response messages related to freight status. When the freight handler scans a cargo container (establishing a "connection" or proximity event with the tag) or enters a tagged zone, the reply software detects the tag ID and activates the corresponding auto-response profile. Incoming messages might be queries from a central logistics hub (via a cellular data network) regarding a specific shipment's status. The system automatically replies with messages like "Container XYZ-456 scanned at Loading Dock 17, awaiting outbound dispatch" or "Pallet ABC-123 moved to Cold Storage Zone B." This automates status updates and reduces manual data entry.

graph TD
    A[Freight Handler's Tablet] --> B{RFID Reader / NFC Scanner}
    B --> C[RFID Tags (Cargo/Zones)]
    C --> D[Reply Software (Tablet)]
    D --> E{DB: RFID Tag ID -> Auto Reply Manifest}
    F[Incoming Query (Logistics Hub)] --> D
    D --> G[Send Automated Freight Update]

Derivative 3.2: Smart Agriculture - Field Equipment Status Reporting

Enabling Description:
For smart agriculture, the "handheld computerized device" is a farmer's or agronomist's field-grade smartphone or tablet. The "Bluetooth peripheral devices" are low-power wireless transponders (e.g., Bluetooth Low Energy, BLE, or custom sub-GHz IoT radios) affixed to various agricultural machinery (e.g., tractor, seeder, drone charging station), irrigation systems, environmental sensors (e.g., soil moisture, weather stations), or even livestock collars. Each transponder has a unique identification code reflecting its asset type and serial number. The reply software on the handheld device associates these transponder IDs with context-specific automated responses concerning equipment status, operational parameters, or environmental conditions. When the farmer approaches a specific piece of machinery or an IoT sensor node, the handheld device establishes a connection, identifies the transponder, and activates the relevant auto-response profile. Incoming messages could be alerts from a central farm management system or requests for manual checks. The system automatically replies with messages such as "Tractor 3 idle for 30 min, low fuel detected," "Irrigation Zone 4 reports optimal soil moisture, no action required," or "Cow #123 entering virtual fence perimeter." This provides real-time, location-based equipment and environmental intelligence.

graph TD
    A[Farmer's Field Device] --> B{BLE / IoT Radio Transceiver}
    B --> C[Machinery Transponder ID]
    B --> D[Irrigation System Transponder ID]
    B --> E[Environmental Sensor Transponder ID]
    C & D & E --> F[Reply Software (Device)]
    F --> G{DB: Transponder ID -> Auto Reply Status}
    H[Incoming Alert/Query (Farm Management)] --> F
    F --> I[Send Automated Field Status]

Derivative 3.3: Healthcare - Patient Contextual Communication for Caregivers

Enabling Description:
In a healthcare setting, the "handheld computerized device" is a medical-grade smartphone or tablet used by a nurse or caregiver. The "Bluetooth peripheral devices" are specialized BLE beacons or NFC tags embedded in patient wristbands, hospital room doors, medical equipment (e.g., IV pumps, patient monitors), or medication dispensers. Each peripheral has a unique, privacy-compliant identification code linked to patient data (e.g., anonymized patient ID, room number, equipment type). The reply software on the caregiver's device associates these peripheral IDs with context-sensitive automated responses related to patient care. When the caregiver enters a patient's room, interacts with specific equipment, or scans a patient's wristband, the connection is detected, the peripheral ID is acquired, and the reply software activates a corresponding auto-response profile. Incoming messages (via a secure hospital Wi-Fi network or internal cellular equivalent) could be urgent alerts from patient monitoring systems, requests from other care staff, or family inquiries. The system automatically replies with messages like "Caregiver XX in Room 301 attending to Patient YZ, alert acknowledged," "Administering medication via IV Pump AB, dosage confirmed," or "Patient YZ stable, no immediate change in condition." This ensures rapid, contextually accurate communication while maintaining focus on patient care.

graph TD
    A[Caregiver's Medical Device] --> B{BLE / NFC Transceiver}
    B --> C[Patient Wristband ID]
    B --> D[Room Beacon ID]
    B --> E[Medical Equipment ID]
    C & D & E --> F[Reply Software (Device)]
    F --> G{DB: Peripheral ID -> Auto Reply Care Status}
    H[Incoming Alert/Query (Hospital Network)] --> F
    F --> I[Send Automated Care Update]

---

4. Integration with Emerging Tech Derivatives

Derivative 4.1: AI-Optimized Adaptive Response Engine

Enabling Description:
The "reply software" in the handheld computerized device is augmented with an embedded Artificial Intelligence (AI) module, specifically a deep learning model trained on extensive conversational data, user behavior patterns, and historical peripheral connection contexts. This AI module dynamically optimizes and generates automatic responses. The "Bluetooth peripheral device linked automatic replies" are no longer static text strings but rather flexible semantic templates and contextual keywords. Upon peripheral connection, the AI module processes the peripheral identification code and current contextual data (e.g., time of day, calendar events, recent communications, biometric data from wearables). When an incoming message is received, the AI analyzes its content (using Natural Language Processing, NLP), the sender's identity, and the current contextual state. It then selects or generates the most appropriate, nuanced automated response in real-time. This can involve sentiment analysis of the incoming message to tailor the tone of the reply, or predictive modeling to anticipate follow-up questions and include relevant information proactively. The AI also learns from user overrides and message effectiveness, continuously refining its response generation algorithms.

graph TD
    A[Handheld Device] --> B{Peripheral Connection Detector}
    B --> C[Peripheral ID]
    D[Incoming Message (Cellular)] --> E{NLP & Sender Analysis}
    F[User Context Data (Time, Calendar, Biometrics)] --> G{AI Response Engine}
    C & E & F --> G
    G --> H[Dynamic Response Generation]
    G --> I{Adaptive Learning Model}
    I --> G
    H --> J[Send Optimized Auto Reply]
    subgraph AI Module
        E,G,I,H
    end

Derivative 4.2: IoT Sensor-Driven Proactive Contextual Awareness

Enabling Description:
This derivative integrates the handheld computerized device with a broader Internet of Things (IoT) ecosystem for hyper-contextual awareness. The "Bluetooth peripheral devices" are extended to include a network of distributed, interconnected IoT sensors (e.g., smart home/office sensors for occupancy, light, temperature, motion; smart vehicle sensors for ignition, speed, passenger count). These sensors continuously stream data to a local IoT gateway that aggregates and pre-processes the information, generating granular "contextual environment states" (e.g., "User in home office, working," "User in vehicle, passenger present, highway speed"). This contextual environment state acts as a dynamic "peripheral identification code." The handheld device's reply software subscribes to this local IoT gateway, receiving real-time updates on the contextual state. The system dynamically loads or adjusts its set of "device linked automatic replies" based on these rich IoT-derived contexts. When an incoming message arrives, the reply software queries the current IoT-derived contextual environment state and selects an appropriate proactive response. For example, if the IoT indicates "User in vehicle, passenger present, highway speed," the auto-reply might state, "Currently driving, passenger onboard, please call if urgent, otherwise will respond upon arrival."

graph TD
    A[Distributed IoT Sensors] --> B[Local IoT Gateway]
    B --> C{Aggregate & Pre-process Sensor Data}
    C --> D[Generate Contextual Environment State]
    D --> E[Handheld Computerized Device]
    E --> F[Reply Software (Device)]
    F --> G{DB: Contextual State -> Proactive Auto Reply}
    H[Incoming Message (Cellular)] --> F
    F --> I[Select & Send Auto Reply]
    subgraph IoT Ecosystem
        A,B,C,D
    end

Derivative 4.3: Blockchain-Secured Reputation-Based Auto-Response

Enabling Description:
In this advanced integration, the "reply software" manages user communication preferences and automatic responses within a decentralized, blockchain-based framework. The "Bluetooth peripheral device identification codes" and their associated automated replies, as well as contact-specific overrides, are encrypted and stored on a distributed ledger (ee.g., Ethereum-based smart contract). Each contact on the user's handheld computerized device is assigned a dynamically updated "reputation score" also managed on the blockchain, reflecting their historical interaction patterns, urgency ratings, and verified identity. When a Bluetooth peripheral connects, the reply software retrieves the corresponding, cryptographically signed auto-response profile from the blockchain. For an incoming message, the system verifies the sender's identity and retrieves their reputation score from the blockchain. The selection of the automatic reply is then a function of (1) the peripheral-linked response, (2) the contact's reputation score, and (3) a dynamic priority rule set encoded in a smart contract. This ensures transparent, immutable, and auditable communication preferences while also prioritizing responses based on a trusted, decentralized reputation system. For example, a low-reputation sender might receive a generic, delayed response, while a high-reputation sender could bypass certain peripheral-based restrictions.

graph TD
    A[Handheld Device] --> B{Peripheral Connection Detector}
    B --> C[Peripheral ID]
    D[Incoming Message (Cellular)] --> E[Sender Identity Verification]
    E --> F[Retrieve Sender Reputation Score (Blockchain)]
    C --> G[Retrieve Peripheral Response Profile (Blockchain)]
    F & G --> H{Smart Contract: Priority & Reputation Rules}
    H --> I[Select & Send Auto Reply]
    subgraph Blockchain Network
        F,G,H
    end

---

5. The "Inverse" or Failure Mode Derivatives

Derivative 5.1: Fail-Safe Emergency Response Mode

Enabling Description:
This derivative implements a fail-safe emergency response mode for the handheld computerized device. In addition to the standard "reply software," there is an "Emergency Override Module" that constantly monitors critical system parameters (e.g., battery level, signal strength, accelerometer data indicating a sudden impact or prolonged immobility, heart rate from a connected health wearable). If a predefined "emergency trigger" is detected (e.g., battery < 5% AND no cellular signal for > 15 minutes, or accelerometer detects high G-force impact followed by zero motion), the system enters a "Fail-Safe Emergency Response Mode." In this mode, all standard "Bluetooth peripheral device linked automatic replies" are temporarily suspended. Instead, the system automatically activates a pre-configured set of emergency-specific replies (e.g., "Emergency: User unreachable, please contact designated emergency contact at [number]") and directs them to a prioritized list of emergency contacts, potentially including pre-programmed emergency services, regardless of the incoming message originator or current peripheral connection. This mode can also trigger a low-power beacon or send GPS coordinates. The "inverse" here is prioritizing safety over context-specific communication, overriding all other logic.

stateDiagram-v2
    [*] --> Normal_Operation
    Normal_Operation --> Emergency_Monitor
    Emergency_Monitor --> Normal_Operation: No Emergency Trigger
    Emergency_Monitor --> Fail_Safe_Mode: Emergency Trigger Detected
    Fail_Safe_Mode --> Send_Emergency_Reply: Incoming Message
    Fail_Safe_Mode --> Send_Emergency_Location: Periodically
    Send_Emergency_Reply --> Fail_Safe_Mode
    Send_Emergency_Location --> Fail_Safe_Mode
    Fail_Safe_Mode --> Normal_Operation: Emergency Resolved / Manual Override

Derivative 5.2: Privacy-Preserving Limited Functionality Mode

Enabling Description:
This derivative introduces a "Privacy-Preserving Limited Functionality Mode" to the handheld computerized device. The "reply software" includes a "Privacy Governance Engine" that, upon detection of specific "peripheral identification codes" associated with sensitive environments (e.g., a "Hospital Waiting Room Wi-Fi" network, a "Therapist's Office Bluetooth Beacon," or a "Legal Consultation Docking Station"), automatically restricts the content of automated responses. In this mode, peripheral-linked automated replies are dynamically sanitized. For instance, a detailed "driving" message might be replaced with a generic "Unavailable" message to avoid disclosing location or activity. If an incoming message originates from a "blacklisted" or non-priority contact (as defined in a privacy-centric dataset), the system defaults to a generic "Do Not Disturb" message, completely masking the user's current context or activity, even if a peripheral connection would normally trigger a more descriptive response. The "inverse" here is the suppression of specific, context-rich replies in favor of generic, privacy-respecting ones, even when the context is known. This mode can also prevent logging of certain events or replies.

graph TD
    A[Handheld Device] --> B{Peripheral Connection Detector}
    B --> C[Peripheral ID]
    C --> D{Privacy Governance Engine}
    D --> E{DB: Peripheral ID -> Privacy Sensitivity}
    D --> F{DB: Contact Blacklist / Priority}
    G[Incoming Message (Cellular)] --> H[Reply Software]
    D & F & G & H --> I[Select / Sanitize Auto Reply]
    I --> J[Send Privacy-Preserving Reply]
    subgraph Privacy Mode
        D,E,F,I
    end

---

Combination Prior Art Scenarios with Open-Source Standards

Here are three scenarios combining US Patent 9,979,826 with existing open-source standards, demonstrating how such combinations would render further incremental improvements obvious.

1. Integration with Android Open Source Project (AOSP) & Bluetooth Stack (BlueZ/Fluoride)

Scenario Description:
The core mechanism of US9979826, involving a handheld device (an Android smartphone running AOSP) detecting a Bluetooth peripheral and triggering an automated response, can be integrated directly into the operating system's Bluetooth stack management and notification framework. The "reply software" functionality could be implemented as a system service leveraging the open-source BlueZ (Linux Bluetooth protocol stack) or Fluoride (Android's current Bluetooth stack) libraries. A module within the AOSP Settings application would provide a user interface to assign custom auto-reply messages to specific Bluetooth device profiles or MAC addresses recognized by the underlying BlueZ/Fluoride stack. The AOSP's existing notification listener service (e.g., NotificationListenerService) and messaging APIs (e.g., SmsManager for sending SMS/MMS) would be utilized to intercept incoming messages and dispatch the selected auto-reply. The "peripheral identification code" would be directly read from the Bluetooth adapter's scan results or connected device list. This integrates the invention's core logic into a fundamental, open-source mobile OS component, making a separate "app" unnecessary for this core functionality.

2. Integration with Eclipse IoT Project (Kura/Mosquitto) for Contextual Auto-Response

Scenario Description:
Extend the invention's contextual awareness by integrating the handheld device (running a Linux-based OS, e.g., embedded Linux on a tablet) with the Eclipse IoT ecosystem. The "Bluetooth peripheral devices" are now diverse IoT sensors (e.g., BLE temperature sensors, Wi-Fi smart plugs, Zigbee presence detectors) that communicate via a local IoT gateway running Eclipse Kura (an open-source framework for IoT gateways) and a Mosquitto MQTT broker (an open-source message broker). The "reply software" on the handheld device subscribes to specific MQTT topics (e.g., sensors/environment/room1/temperature, presence/user/status) published by Kura/Mosquitto, receiving real-time "peripheral identification codes" and associated contextual data (e.g., temperature threshold crossed, presence detected). A new service on the handheld device, built using open-source Python libraries (e.g., paho-mqtt for MQTT client, Flask for local management interface), processes these MQTT messages. It then dynamically updates a local context profile that determines which automated response message should be selected when an incoming communication (e.g., SMS, email via an open-source mail client) is received. This leverages open-source IoT messaging for highly dynamic and granular context-specific auto-replies.

3. Integration with OpenStreetMap (OSM) & Geofencing Libraries for Location-Aware Peripheral Activation

Scenario Description:
Combine the patent's peripheral-triggered auto-response with open-source geospatial data and geofencing capabilities. The "handheld computerized device" uses its GPS and an open-source map client (e.g., leveraging OpenStreetMap data via osmdroid or Leaflet libraries) to define specific "geofenced zones" (e.g., "Home Wi-Fi Zone," "Work Office Zone," "Car Garage Zone"). The "Bluetooth peripheral device identification codes" are linked to these zones. For instance, a car's Bluetooth system is associated with the "Car Garage Zone." The "reply software" integrates an open-source geofencing library (e.g., a custom Android or iOS geofencing implementation based on location APIs) that continuously monitors the device's position against the predefined OSM-based geofences. When the device enters a geofenced zone (triggering a location-based "peripheral connection" event, even if the actual physical peripheral is not yet connected or is merely detected as being within the zone), the system preemptively loads the associated peripheral's auto-reply messages. Upon actual detection of the Bluetooth peripheral (e.g., car's hands-free), the system cross-references the geofence context. If the user is in the "Car Garage Zone" and the car's Bluetooth connects, a "driving" auto-reply is selected. If the Bluetooth peripheral connects outside its usual geofence, a different default or an "unusual context" auto-reply may be chosen. This adds a robust, location-verified layer of context to peripheral-driven responses, all built on open-source mapping and geofencing components.