Broadcast remote firmware update
US-2019058630-A1 · Feb 21, 2019 · US
US10560968B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-10560968-B2 |
| Application number | US-201715621619-A |
| Country | US |
| Kind code | B2 |
| Filing date | Jun 13, 2017 |
| Priority date | Jun 13, 2017 |
| Publication date | Feb 11, 2020 |
| Grant date | Feb 11, 2020 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
A method of avoiding response signal collisions includes broadcasting a message from a broadcasting device to a plurality of downstream devices, the message containing timing instructions specifying a time at which each downstream device should send its response to the message after successfully receiving the message, and determining whether every downstream device targeted in the message successfully received the message. A method of processing a message includes analyzing, by a downstream device in a communication network, filtering information in a received message to determine whether the filtering information targets the downstream device, and responsive to determining that the filtering information targets the downstream device, determining, by the downstream device, whether the message requires a response, and responsive to a determination that the message requires a response, analyzing timing information in the received message to determine response timing, and scheduling a response as defined in the timing information.
Opening claim text (preview).
That which is claimed is: 1. A method of avoiding response signal collisions, comprising the steps of: broadcasting a message from a broadcasting device to a plurality of downstream devices, the message containing response window information dictating whether each downstream device targeted in the message must respond to the message, and if so, when each targeted downstream device should send its response to the message after successfully receiving the message; receiving a response from at least one downstream device in the plurality of downstream devices that was commanded to respond and that successfully received the message, each such downstream device comprising a responding device, wherein each responding device sends its response when performing an upload of data collected by the responding device; and determining whether every targeted downstream device successfully received the message, wherein, for required responses, the response window information is selected from at least one of the group comprising an instruction that each responding device commence its upload at a predefined recurring time, an instruction that each responding device perform its upload immediately following expiration of a predefined delay period commencing at a time of sending of the message, and an instruction that each responding device pick a random time within a predefined time window in which to perform its upload, wherein the broadcasting device receives the message from a server, and wherein the server has a memory containing a first list, the first list reciting identifications of all downstream devices from which a response to the message is expected, and containing a second list, the second list reciting identifications of all responding devices, and wherein the step of determining whether every downstream device targeted in the message successfully received the message further comprises the steps of comparing the first list to the second list, ascertaining whether the server failed to receive a response to the message from any downstream device identified in the first list, and re-broadcasting the message to each downstream device from which the server failed to receive a response, wherein the step of determining whether every downstream device targeted in the message successfully received the message further comprises the steps of: receiving, from each downstream device successfully receiving a re-broadcast message, each such device comprising a re-broadcast responding device, a response when each re-broadcast responding device performs an upload of data collected by each re-broadcast responding device, a time of each upload dictated by the response window information, producing an updated second list by adding, to the second list, identifications of each re-broadcast responding device, comparing the first list to the updated second list, ascertaining whether the server failed to receive a response to the re-broadcast message from any downstream device identified in the first list, determining whether a pre-defined limit on a number of broadcasts has been reached, and responsive to determining that the pre-defined limit on the number of broadcasts has not been reached, again re-broadcasting the message to all downstream devices from which the server has still failed to receive a response. 2. The method of claim 1 , wherein the group further comprises identification of a quiet period within the predefined time window during which time a response may not be sent by the responding device. 3. The method of claim 1 , further comprising sequentially repeating the steps of receiving, producing an updated second list, comparing, ascertaining, determining, and again re-broadcasting until occurrence of an event selected from one of receipt of responses from all downstream devices identified in the first list, a reaching of the pre-defined limit on the number of broadcasts, and a falling of a value below a predetermined threshold, the value indicating a number of downstream devices from which the server has still failed to receive a response. 4. The method of claim 3 , further comprising the step of, responsive to the falling of the value below the predetermined threshold, sending a direct message individually to each downstream device from which the server has still failed to receive a response. 5. The method of claim 1 , wherein the message contains filtering information targeting only a subset of the plurality of downstream devices, the filtering information comprising at least one of hardware type, hardware sub-type, and operational mode. 6. The method of claim 5 , wherein the filtering information further comprises a message number, such that for downstream devices that already successfully received a message with the message number, any re-broadcasts of messages containing the message number may be disregarded. 7. The method of claim 1 , further comprising the steps of: determining whether a response to the message was received from any downstream device that was not targeted in the message, each such downstream device comprising a responding non-targeted device; and responsive to determining that a response to the message was received from a responding non-targeted device, restoring each responding non-targeted device to a pre-broadcast condition. 8. A method of avoiding response signal collisions, comprising the steps of: broadcasting a message from a broadcasting device to a plurality of downstream devices, the message containing timing instructions specifying a time at which each downstream device should send its response to the message after successfully receiving the message; and determining whether every downstream device targeted in the message successfully received the message by receiving a response from each downstream device successfully receiving the message, each such downstream device comprising a responding device, wherein each responding device sends its response when performing an upload of data collected by the responding device, a time of each upload dictated by the timing instructions, wherein the broadcasting device receives the message from a server, the server having a memory containing a first list, the first list reciting identifications of all downstream devices from which a response to the message is expected, and containing a second list, the second list reciting identifications of all responding devices, wherein the step of determining whether every downstream device targeted in the message successfully received the message further comprises the steps of comparing the first list to the second list, ascertaining whether the server failed to receive a response to the message from any downstream device identified in the first list, re-broadcasting the message to each downstream device from which the server failed to receive a response, receiving, from each downstream device successfully receiving a re-broadcast message, each such device comprising a re-broadcast responding device, a response when each re-broadcast responding device performs an upload of data collected by each re-broadcast responding device, a time of each upload dictated by the timing instructions, producing an updated second list by adding, to the second list, identifications of each re-broadcast responding device, comparing the first list to the updated second list, ascertaining whether the server failed to receive a response to the re-broadcast message from any downstream device identified in the first list, determining whether a pre-defined limit on a number of broadcasts has been reached, and responsive to determining that the pre-defined limit on the number of broadcasts has not been reached, again re-broadcasting the message to all downstream de
Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services · CPC title
collision avoidance · CPC title
Scheduled access (hybrid access H04W74/02) · CPC title
Establishing a time schedule for servicing the requests · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.