Granted Claim 19 · Software element H
Instructions automatically disabling and enabling communication
Strong potential correspondence — deployment dependent
Granted claim language
Verbatim · US12039568B2 · Claim 19such that the communication between the one or more secondary user devices and the primary user device is,
automatically disabled when the one or more secondary user devices are not located at the particular location, or located outside the specified region or distance in relation to the geographical location, and outside the specified time or period of time, to thereby prevent sending of notifications to the one or more secondary user devices, and
automatically enabled when the one or more secondary user devices are located at the particular location, or within the specified region or distance in relation to the geographical location, and at the specified time, or within the specified period of time, to thereby allow sending of notifications to the one or more secondary user devices.
Claim requirement
Technical interpretation — not claim languageThis is the decisive software limitation. The instructions must implement a two-state communication gate whose transitions are automatic and determined by the conjunction of the geographic and temporal conditions: disabled — and therefore preventing sending — outside those conditions, and enabled when both are satisfied.
Publicly disclosed Woosmap functionality
Woosmap documents automatic event generation on geographic and ETA conditions, and integration instructions transmitting those events into engagement platforms where they act as triggers. The Marketing Cloud integration documents Entry Event triggering; Braze receives custom events tied to messaging campaigns; Batch expressly documents the events as Custom Event triggers in the Automation and Journey composers. In each case entry into the communication workflow is automatic on receipt of the event.
- Automatic event generation
- Entry Event triggering
- Custom-event triggers
- Automation and journey composers
- Campaign execution on trigger
Granted claim architecture
- 01Location condition
- 02Time condition
- 03Software decision
- 04Communication disabled / enabled
Publicly documented Woosmap pathway
- 01Geofence / ETA condition
- 02SDK event
- 03Integration event
- 04Engagement journey
- 05Communication action
Execution environment and component attribution
- Woosmap SDK
Event generation and connector transmission are documented SDK operations.
- Customer-engagement platform
Trigger-based journey entry and communication execution are documented platform behaviour.
- NOT ESTABLISHED FROM PUBLIC EVIDENCE
No public material establishes instructions implementing the recited automatic disabling state in a deployment.
Public evidence
Woosmap (developers.woosmap.com)
Woosmap Geofencing SDK — Salesforce Marketing Cloud integration
Transmission of Woosmap Geofencing SDK events to Salesforce Marketing Cloud from four context types — Geofences, POI, Visits and ZOI — to trigger an Entry Event; connector initialisation with EventDefinitionKeys for woos_geofence_entered_event, woos_geofence_exited_event, woos_POI_event, woos_Visit_event, woos_zoi_classified_entered_event and woos_zoi_classified_exited_event; and event data fields including user_properties.[field_name].
View original source ↗Woosmap (developers.woosmap.com)
Woosmap Geofencing SDK — Braze integration
Transmission of Woosmap Geofencing SDK events from Geofences, POI, Visits and ZOI contexts to Braze as custom events with associated properties, tied back to push messaging campaigns.
View original source ↗Woosmap (developers.woosmap.com)
Woosmap Geofencing SDK — Batch integration
Transmission of Woosmap Geofencing SDK events from Geofences, POI, Visits and ZOI contexts to Batch as custom events, expressly usable as a Custom Event trigger in the Automation and Journey composers.
View original source ↗Technical correspondence
A trigger-based architecture in which no event means no communication, and an event automatically initiates communication, is technically analogous to the claimed enable/disable gate. Analogy is not identity: the claim requires the conjunction of location and time, and requires the disabling state as an express software condition.
Evidentiary status and matters for further review
Claim-element correspondence
Deployment confirmation required
Matters for further review
Do the executable instructions in a specific deployment implement the precise claimed condition whereby communication is disabled until the required conditions are satisfied and automatically enabled when they are satisfied?
The key question
Do the executable instructions in a specific deployment implement the precise claimed condition whereby communication is disabled until the required conditions are satisfied and automatically enabled when they are satisfied?