DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 1/12/2026 have been fully considered but they are not persuasive.
Regarding claim 1, 13, 22 and 30, the applicant argued that, “…Balasayagun at least fails to disclose "display, at the first UE, a second indication of the decreased network condition at the second UE based on the first indication received from the second UE, wherein the second indication indicates one of the first UE or the second UE that is experiencing the decreased network condition, and wherein another one of the first UE or the second UE is not experiencing the decreased network condition." as recited in claim 1...Applicant respectfully submits that Balasayagun merely discloses that its call quality indication 606 can display call quality information, such as "a list of call quality measurements/scores, a report of the call quality, a summary of the call quality, a graphical representation of the call and the call quality, a chart of the call quality, an alert of the call quality, a log of call quality statistics, a video representation of the call quality, an object in a graphical user interface." [0081]. However, Balasayagun fails to disclose that its "call quality indication 606" indicates "one of the first UE or the second UE that is experiencing the decreased network condition, and wherein another one of the first UE or the second UE is not experiencing the decreased network condition," as recited in claim 1....” in page 11. [Emphasis added]
In response to applicant's argument, the examiner respectfully disagrees.
(I) Balasaygun discloses, display, at the first UE, (see FIG. 1, Display 170 or any visual screen of User’s Network component 210, User’s terminal 206, or Node 304/404 of one side of network region/segment) a second indication of the decreased network condition at the second UE (see FIG. 3-4, image of a broken link (i.e. second indication), next to User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment, with a quality and/or performance level below a specific threshold; see ¶¶ 47, 57, 58, 62; also see Fig 6: presentation 600 of quality indication and/or call quality indication 606 of changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate) at User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment; see ¶¶62-64, 81-83; also see FIG. 7, presentation 700, see ¶¶84-89) based on the first indication received from the second UE (see FIG. 3-4, based on indication/instruction for RTCP information received from User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment automatically or in respond to triggering event/request; ¶¶31, 33, 34, 42, 47, 48,48, 54, 57, 64; also see FIG. 6-7), wherein the second indication indicates one of the first or the second UE that is experiencing the decreased network condition (see FIG. 3-4, image of a broken link (i.e. second indication for decrease condition), next to User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side of network region/segment, indicates quality and/or performance level below a specific threshold; see ¶¶ 47, 57, 58, 62-64, 81-83; also see Fig 6: presentation 600 of quality indication and/or call quality indication 606 indicate factors with changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate) by blinking icon at User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side of network region/segment; also see FIG. 7, presentation 700, see ¶¶ 84-89), and wherein another one of the first UE or the second UE is not experiencing the deceased network condition (see FIG. 3-4, visual indication of normal condition status (i.e. second indication without decrease condition), next to User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side of network region/segment, indicates quality and/or performance level above a specific threshold; see ¶¶ 47, 57, 58, 62-64, 81-83; also see Fig 6: presentation 600 of quality indication and/or call quality indication 606 indicate that factors with normal status (i.e. jitter=0, packet loss=0, delay=0, ..) by non-blinking icon at User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side network region/segment; also see FIG. 7, presentation 700, see ¶¶ 84-89).
(II) The claim is constructed based on broadly recited limitation, in light of the specification, such as “wherein the second indication indicates one of the first or the second UE that is experiencing the decreased network condition … wherein the second indication indicates one of the first or the second UE that is not experiencing the decreased network condition…” [Emphasis added] The claim provides no detail as to what/how these conditions are indicated, or what/how specific indication show/display the specific decreased network condition experiencing or not experiencing by first UE or second UE. The claim also recites the negative limitation “not experiencing the decreased network condition” which can be broadly and/or implicitly construed as absence of decrease network condition. The prior art is applied in view of the construction set forth above accordingly1.
(III) In this case, Balasaygun clearly anticipate the broadly recited claims in view of the following paragraph.
[0047] In one embodiment, the end-to-end RTCP analysis is used to generate an alert, a message, and/or an image that identifies a communication problem. For example, the end-to-end RTCP analysis can be used by a phone to display a list/map of devices participating in the communication session, with a visual indication of the status of each device and/or the overall communication session. To illustrate, the phone in this example can display an image of a broken link next to any device with a quality and/or performance level below a specific threshold. The phone can also use colors, numbers, symbols, etc., to indicate a status associated with a device and/or communication session.
[0048] In another embodiment, the end-to-end RTCP analysis is used to display a visual representation of the communication session on a touch screen. Here, a user can interact with the communication session through the display. For example, the user can select a node to view additional details about the node. The display can include controls to allow the user to actively control the experience. For example, the user can control the type/amount of information that is collected/analyzed, the type/amount of information that is displayed, the method/format for displaying such information. Through the display, the user can also perform many other functions, such as transmitting an alert/indication for other devices in the communication session, displaying information at another location, forwarding information to another device, etc.
[0057] In one embodiment, the end-to-end RTCP analysis is used to generate an indication when a change in the network is detected. For example, the end-to-end RTCP analysis can be used to generate an audible alert when a node joins the communication session. As another example, the end-to-end RTCP analysis can be used by a node, such as a phone, to display a representation of the devices participating in the communication session, with a visual indication of the status of each device and/or the overall communication session. To illustrate, the phone in this example can display an image of a broken link next to a device when a quality and/or performance level associated with the device drops below a specific threshold. The phone can also use colors, numbers, symbols, etc., to indicate a status associated with a device and/or communication session.
[0081] The presentation 600 also displays a call quality indication 606. The call quality indication 606 can be displayed as a list of call quality measurements/scores, a report of the call quality, a summary of the call quality, a graphical representation of the call and the call quality, a chart of the call quality, an alert of the call quality, a log of call quality statistics, a video representation of the call quality, an object in a graphical user interface, and so forth. The call quality indication 606 can also be displayed using gestures. For example, the call quality indication 606 can be displayed using icons representing the call and/or various aspects of the call, such as call interruptions, where the icons can be animated to indicate a status, a change in status, a problem, an error, a score, a quality, a disruption, etc. For example, the call quality indication 606 can display a blinking icon to indicate a problem with the item or attribute represented by the icon.
[Emphasis added]
(IV) In view of the above, Display 170 or any visual screen of User’s Network component 210, User’s terminal 206, or Node 304/404 of one side of network region/segment (i.e. first UE) display status of all nodes/devices participation in the network with a visual indication of each devices/nodes.
(V) Regarding experiencing the decrease network condition scenario, User’s Network component 210, User’s terminal 206, or Node 304/404 of one side of network region/segment (i.e. first UE) indicates image of a broken link (i.e. second indication) next to said User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment, with a quality and/or performance level below a specific threshold. Moreover, presentation 600 of quality indication and/or call quality indication 606 indicate factors with changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate) by blinking icon at User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side of network region/segment (i.e. first UE or second UE).
(VI) Regarding non-experiencing the decrease network condition scenario (i.e., normal or overall quality=10), User’s Network component 210, User’s terminal 206, or Node 304/404 of one side of network region/segment (i.e. first UE) indicates visual indication of normal condition status2 (i.e. second indication without decrease condition), next to User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side of network region/segment, indicates quality and/or performance level above a specific threshold. Moreover, presentation 600 of quality indication and/or call quality indication 606 indicate that factors with normal status (i.e. jitter=0, packet loss=0, delay=0, ..) by non-blinking icon at User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side network region/segment (i.e. first UE or second UE).
Regarding claim 4, the applicant argued that, “…Claim 4 is patentable over the cited references (Balasayagun, Qiu, Mulvey, Payette, Sakai, Singer, and Yao) also because none of them, individually or in any combination, discloses or reasonable suggests "wherein the second indication displayed at the first UE indicates at least one of the decreased network condition at the second UE, or a non-decreased network condition at the first UE," as recited in claim 4. The Office Action alleged that "Balasayagun discloses 'the second indication displayed at the first UE indicates the condition of the second UE," citing FIG. 6, paragraphs [0080]-[0083] of Balasayagun. Office Action, p. 8. Applicant respectfully submits that, in Balasayagun, the presentation 600 of quality indication merely shows "call quality indication 606 representing the call and/or various aspects of the call, such as call interruptions, change in status, a problem, an error, a score, a quality, a disruption, etc." [0081]. However, Balasayagun fails to disclose an indication that "indicates at least one of the decreased network condition at the second UE, or a non-decreased network condition at the first UE," as recited in claim 4 (emphasis added). Hence, claim 4 and similarly amended independent claim 25 are allowable over the references (Balasayagun, Qiu, Mulvey, Payette, Sakai, Singer, and Yao), as cited. …” in page 11-12.
In response to applicant's argument, the examiner respectfully disagrees since the context of the argument are the same as claim 1, Supra, accordingly, response are hereby incorporated. Moreover, the amended claim 4 has been constructed based on optional limitations the second indication displayed at the first UE indicates at least one of the decreased network condition at the second UE, or a non-decreased network condition at the first UE.
In conclusion, Balasaygun clearly anticipates amended claims 1, 4, 13, 22, 25 and 30 as the rejections are hereby sustained.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 4, 8, 9, 11, 12, 22, 25, and 29 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Balasaygun (US 2013 0250786).
Regarding claims 1 and 22, Balasaygun discloses an apparatus and method for wireless communication at a first user equipment (UE) (see FIG. 1-4, User’s Network component 210, User’s terminal 206, or Node 304/404 of one side of network region/segment) , comprising:
Memory (see FIG. 1, Memory 130); and
at least one processor coupled to the memory (see FIG. 1, processor 120 connecting with memory 130 ) and, based at least in part on information stored in the memory (see ¶¶22,23), the at least one processor is configured to:
receive, from a second UE, (see FIG. 2-4, receive from User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment) a first indication of a decreased network condition at the second UE (see FIG. 2-4, indication/instruction for RTCP information (from triggering event/request) of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,…, at User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment; see ¶¶31, 33, 34, 54, 57, 64), the first indication associated with at least one of a decreased bit rate (see FIG. 1, indication/instruction for RTCP information (based on triggering event/request) associated with changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate); see ¶¶31, 33, 34, 38, 54, 62, 64 ); and
display, at the first UE, (see FIG. 1, Display 170 or any visual screen of User’s Network component 210, User’s terminal 206, or Node 304/404 of one side of network region/segment) a second indication of the decreased network condition at the second UE (see FIG. 3-4, image of a broken link (i.e. second indication), next to User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment, with a quality and/or performance level below a specific threshold; see ¶¶ 47, 57, 58, 62; also see Fig 6: presentation 600 of quality indication and/or call quality indication 606 of changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate) at User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment; see ¶¶62-64, 81-83; also see FIG. 7, presentation 700, see ¶¶84-89) based on the first indication received from the second UE (see FIG. 3-4, based on indication/instruction for RTCP information received from User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment automatically or in respond to triggering event/request; ¶¶31, 33, 34, 42, 47, 48,48, 54, 57, 64; also see FIG. 6-7),
wherein the second indication indicates one of the first or the second UE that is experiencing the decreased network condition (see FIG. 3-4, image of a broken link (i.e. second indication for decrease condition), next to User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side of network region/segment, indicates quality and/or performance level below a specific threshold; see ¶¶ 47, 57, 58, 62-64, 81-83; also see Fig 6: presentation 600 of quality indication and/or call quality indication 606 indicate factors with changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate) by blinking icon at User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side of network region/segment; also see FIG. 7, presentation 700, see ¶¶ 84-89), and
wherein another one of the first UE or the second UE is not experiencing the deceased network condition (see FIG. 3-4, visual indication of normal condition status3 (i.e. second indication without decrease condition), next to User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side of network region/segment, indicates quality and/or performance level above a specific threshold; see ¶¶ 47, 57, 58, 62-64, 81-83; also see Fig 6: presentation 600 of quality indication and/or call quality indication 606 indicate that factors with normal status (i.e. jitter=0, packet loss=0, delay=0, ..) by non-blinking icon at User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side network region/segment; also see FIG. 7, presentation 700, see ¶¶ 84-89).
Regarding claims 4, 25, Balasaygun discloses the second indication displayed at the first UE (see FIG. 3-4: User’s Network component 210, User’s terminal 206, or Node 304/404 of one side of network region/segment (i.e. first UE) ) indicates at least one of
the decreased network condition at the second UE (see FIG. 3-4: displays image of a broken link (i.e. second indication for decrease condition), next to User’s Network component 210, User’s terminal 206, or Node 304/404 of the other side of network region/segment (i.e. second UE), indicates quality and/or performance level below a specific threshold; see ¶¶ 47, 57, 58, 62-64, 81-83; also see Fig 6: User’s Network component 210, User’s terminal 206, or Node 304/404 of one side of network region/segment (i.e. first UE) displays presentation 600 of quality indication and/or call quality indication 606 indicate factors with changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate) by blinking icon at User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment (i.e. second UE); also see FIG. 7, presentation 700, see ¶¶ 84-89), or
non-decreased network condition at the first UE (see FIG. 3-4, display visual indication of status4 (i.e. second indication without decrease condition), next to User’s Network component 210, User’s terminal 206, or Node 304/404 of one side of network region/segment (i.e. First UE), indicates quality and/or performance level above a specific threshold; see ¶¶ 47, 57, 58, 62-64, 81-83; also see Fig 6: presentation 600 of quality indication and/or call quality indication 606 indicate that factors with normal status (i.e. jitter=0, packet loss=0, delay=0, ..) by non-blinking icon at User’s Network component 210, User’s terminal 206, or Node 304/404 of one side network region/segment (i.e. first UE); also see FIG. 7, presentation 700, see ¶¶ 84-89).
Regarding claims 8, 29, Balasaygun discloses wherein the first indication of the decreased network condition at the second UE corresponds to at least one of in-band signaling from the second UE (see ¶¶37, 40, 62, indication/instruction of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,… at User’s Terminal 206/ User’s Network component 210 correspond to any multimedia signaling (i.e. in-band signaling) from User’s Terminal 206/ User’s Network component 210), or
a real-time transport protocol (RTP) packet indicative of the decreased network condition at the second UE (see ¶¶7, 35, 54, indication/instruction at User’s Terminal 206/ User’s Network component 210 corresponds to Real time transport protocol (RTP) stream/packet/flow indication/instruction of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,… at User’s Terminal 206/ User’s Network component 210; also see ¶¶31, 33, 34, 54, 57, 64).
Regarding claims 9, Balasaygun discloses wherein the at least one of the in-band signaling or the RTP packet is indicative of at least one of an RTP extension header identifier (ID) (see ¶¶ 28,31, 32, 37, 49,50, 54; RTP stream/packet/flow is indicates extension which include number/ID in RTP header), a reference signal received quality (RSRQ) (see ¶¶ 10, 21, 33, 34, 38, 39, 62-66, 74-77, 81-83; received media/signal quality indication), or a received signal strength indicator (RSSI) (see ¶¶10, 33, 38, 62, 63; received signal strength indication).
Regarding claim 11, Balasaygun discloses wherein the second indication is displayed at the first UE (see Fig 6-7: presentation 600/700 of quality indication is displayed at User’s Network component 210/User’s Terminal 206) based on the first indication corresponding to the RTP packet (see ¶¶7, 35, 54; based on indication/instruction for Real time transport protocol (RTP) stream/packet/flow; also see ¶¶ 31, 33, 34, 54, 57, 64), the second indication indicating a reason for the decreased network condition at the second UE (see FIG. 6-7, presentation 600/700 of quality indication or call quality indication 606/706 indicate the reasons for reduced/changed/decrease network condition (i.e. jitter, delay, delay, , packet loss,…) for User’s Network component 210/User’s Terminal 206; see ¶¶62-64, 80-83, 88).
Regarding claim 12, Balasaygun discloses at least one of a transceiver (see FIG. 2, transmitter and receiver (i.e. transceiver) of user terminal Network component 210 or User’s Terminal 206; see ¶¶31,32, 34, 37, 43, 45 ; also see FIG. 1, handheld computing device 100’s input-output-communication interface 170-180-190; see ¶¶23, 40, 94) or an antenna (see FIG. 2, handheld computing device’s antenna, see ¶¶43, 40, 94) coupled to the at least one processor (see FIG. 2, CPU/processor of user terminal Network component 210 or User’s Terminal 206; also see FIG. 1, processor 120 of handheld computing device 100; see ¶¶22, 23, 92-94).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2, 3, 23 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Balasaygun in view of Qiu (US 20170187774 A1).
Regarding Claims 2 and 23, Balasaygun discloses wherein the at least one processor is further configured to adjust a communication with the second UE based on the first indication received from the second UE of the decreased network condition at the second UE (see FIG. 2, a processor 120 or User’s Network component 210 or User’s Terminal 206 adjust/change a communication with User’s Terminal 206 based on indication/instruction for RTCP information (from triggering event/request) of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,…, at User’s Terminal 206/ User’s Network component 210; see ¶¶31, 33, 34, 35, 40, 50, 54, 57, 62).
Although Balasaygun discloses at least one processor is further configured to adjust a communication with the second UE set forth above, Balasaygun does not explicitly disclose “adjust a bit rate”.
However, Qiu teaches wherein the at least one processor is further configured to adjust a bit rate for a communication with the second UE based on the first indication received from the second UE of the decreased network condition at the second UE (see Fig. 3 S308-S310: data transmitter obtains requested bit rate information from TMMBR/first indication, calculates coding bit rate to be configured; see ¶¶8, 13, 16, 21, 23-24, 67-72).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide “adjust a bit rate” as taught by Qiu in the system of Balasaygun, so that it would improve the quality of quality of video call; see Qiu, ¶25.
Regarding claim 3 and 24, wherein the at least one processor is further configured to transmit the respond to the first indication, (see ¶¶11, 31, 33, 34, 45, 53, 54, 57, 62, 64; transmitting acknowledgement/respond to indication/instruction for RTCP information (from triggering event/request) of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,… at User’s Terminal 206/User’s Network component 210, where indication/instruction) the bit rate for the communication with the second UE being adjusted based on the reply being transmitted to the first indication (see ¶¶31, 33, 34, 38, 45, 46, 53, 54, 62, 64 ; a bit rate for the communication User’s Terminal 206/ Network component 210 being changed/adjusted based on the acknowledge/respond being transmitted to the indication/instruction).
Balasaygun does not explicitly disclose “the TMMBn as an acknowledgment, wherein the first indication corresponds to the TMMBr, the bit rate for the communication with the second UE being adjusted based on the TMMBn.”
However, Qiu discloses transmitting the TMMBn as an acknowledgment to the first indication, wherein the first indication corresponds to the TMMBr (see ¶ 49: after receiving TMMBR, data transmitter sends TMMBN as a response), the bit rate for the communication with the second UE being adjusted based on the TMMBn being transmitted as the acknowledgment to the first indication (see Fig. 3 S307-S310: data transmitter sends TMMBN to data receiver, obtains bit rate information, calculates coding bit rate to be configured, and performs coding bit rate configuration; see ¶¶64-69).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide “the TMMBn as an acknowledgment, wherein the first indication corresponds to the TMMBr, the bit rate for the communication with the second UE being adjusted based on the TMMBn” as taught by Qiu in the system of Balasaygun, so that it would improve the quality of quality of video call; see Qiu, ¶25.
Claims 5 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Balasaygun in view of Mulvey et. al. (US 20100054519 A1).
Regarding claim 5 and 26, Balasaygun discloses further configured to receive one or more subsequent indications of the decreased network condition at the second UE (see ¶¶31, 33, 34, 54, 57, 64; receive plurality of RTCP reports/messages with plurality of indication/instruction (i.e. subsequence indications) at User’s Network component 210/ Network component 210), the one or more subsequent indications associated with one or more requests for the decreased bit rate (see ¶¶31, 33, 34, 38, 54, 62, 64,; such plurality of indication/instruction (i.e. subsequence indications) associated with request for changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate));
wherein the second indication is displayed at the first UE based on at least one of the one or more subsequent indications being received over a predefined time duration or the decreased bit rate (see¶¶62-64, 81-83): presentation 600 of quality indication and/or call quality indication 606 display at User’s Network component 210/User’s Terminal 206 based on such plurality of indication/instruction (i.e. subsequence indications) being received over time during a communication session while media path quality is changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate)).
Although Balasaygun discloses wherein the second indication is displayed at the first UE based on at least one of the one or more subsequent indications being received over a predefined time duration or the decreased bit rate being reduced as set forth above Balasaygun does not explicitly disclose the decreased bit rate being reduced “to a minimum threshold”.
However, Mulvey discloses providing an indication to a user of a bit rate being reduced to a minimum threshold (see ¶ 23: device determines whether the bitrate is above or below a threshold, when data rate is less than the threshold a visual indicator provides an indication of the lowered bitrate).
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the decreased bit rate being reduced “to a minimum threshold” as taught by Mulvey in the system of Balasaygun to enable the user to take corrective action (see Mulvey ¶23).
Claim(s) 6, 13, 17, 19, 20, 27 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Balasaygun in view of Payette et. al. (US 20130042275 A1).
Regarding claims 6 and 27, Balasaygun discloses wherein the decreased network condition at the second UE corresponds to at least one of network congestion or a decreased condition associated with the second UE (see ¶¶31, 33, 34, 54, 57, 64; indication/instruction for RTCP information (from triggering event/request) of network congestion OR change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem, ) at User’s Terminal 206/ Network component 210).
Although Balasaygun discloses wherein the decreased network condition at the second UE corresponds to at least one of network congestion as set forth above, Balasaygun does not explicitly disclose “increased” network congestion.
However, Payette discloses a decreased network condition at a UE corresponding to increased congestion (see ¶ 96: a reduction in the maximum available resources of the cellular sector is due to change in conditions such as change in load/congestion of the cellular sector).
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide a decreased network condition corresponding to increased network congestion as taught by Payette in the system of Balasaygun to improve reliability (see Payette ¶ 60).
Regarding claim 13 and 30, Balasaygun discloses an apparatus and method for wireless communication at a second user equipment (UE) ((see FIG. 1-4, User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment)), comprising:
memory (see FIG. 1, Memory 130); and
at least one processor coupled to the memory (see FIG. 1, processor 120 connecting with memory 130) and, based at least in part on information stored in the memory (see ¶¶22,23), the at least one processor is configured to:
receive a local indication at the second UE (see FIG. 2-4, receive data at User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment; see ¶¶ 43, 60);
transmit, to a first UE, (see FIG. 2-4, transmit to User’s Network component 210, User’s terminal 206, or Node 304/404 of one side of network region/segment) a first indication of the decreased network condition at the second UE (see FIG. 2, indication/instruction for RTCP information (from triggering event/request) of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,… at User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment ; see ¶¶31, 33, 34, 54, 57, 64), the first indication associated with at least one of a decreased bit rate (see FIG. 2, indication/instruction for RTCP information (from triggering event/request) of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,…; see ¶¶31, 33, 34, 38, 54, 57, 62, 64),
wherein the first indication is associated with a second indication of the decreased network condition displayed on the first UE (see Fig 6: indication/instruction for RTCP information from triggering event/request (i.e. first indication) is associated with an image of a broken link (i.e. second indication), next to User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment, with a quality and/or performance level below a specific threshold, is displayed at Display 170 or any visual screen of User’s Network component 210, User’s terminal 206, or Node 304/404 of one side of network region/segment (i.e. first UE); see ¶¶ 47, 57, 58, 62; also see Fig 6: presentation 600 of quality indication and/or call quality indication 606 of changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate) at User’s Network component 210, User’s terminal 206, or Node 304/404 of other side of network region/segment, is displayed at Display 170 or any visual screen of User’s Network component 210, User’s terminal 206, or Node 304/404 of one side of network region/segment (i.e. first UE); see ¶¶62-64, 81-83; also see FIG. 7, presentation 700, see ¶¶84-89)
wherein the second indication indicates one of the first or the second UE that is experiencing the decreased network condition (see FIG. 3-4, image of a broken link (i.e. second indication for decrease condition), next to User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side of network region/segment, indicates quality and/or performance level below a specific threshold; see ¶¶ 47, 57, 58, 62-64, 81-83; also see Fig 6: presentation 600 of quality indication and/or call quality indication 606 indicate factors with changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate) by blinking icon at User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side of network region/segment; also see FIG. 7, presentation 700, see ¶¶ 84-89), and
wherein another one of the first UE or the second UE is not experiencing the deceased network condition (see FIG. 3-4, visual indication of normal condition status5 (i.e. second indication without decrease condition), next to User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side of network region/segment, indicates quality and/or performance level above a specific threshold; see ¶¶ 47, 57, 58, 62-64, 81-83; also see Fig 6: presentation 600 of quality indication and/or call quality indication 606 indicate that factors with normal status (i.e. jitter=0, packet loss=0, delay=0, ..) by non-blinking icon at User’s Network component 210, User’s terminal 206, or Node 304/404 of one side or other side network region/segment; also see FIG. 7, presentation 700, see ¶ 84-89).
Although Balasaygun discloses a second user equipment receive a local indication at the second UE and communicating a decreased network condition to the first UE as set forth above, Balasaygun does not explicitly disclose receive a local indication of “a decreased network condition” at the second UE. [Emphasis added]
However, Payette discloses receiving a local indication of a decreased network condition at a second UE (see Fig. 1: Cellular sector 123, mobile device (MD) 110; see Fig. 5 step 520: Receive a cellular sector/local indication of a condition; see ¶ 155: MD 110 receives an indication of a condition associated with a cellular sector, the condition includes a congestion condition in the cellular sector).
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide receive a local indication of “a decreased network condition” at the second UE as taught by Payette in the system of Balasaygun to improve reliability (see Payette ¶ 60).
Regarding claim 17, Balasaygun discloses wherein the decreased network condition at the second UE (see FIG. 2, change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,… at User’s Terminal 206/User’s Network component 210 ; see ¶¶31, 33, 34, 54, 57, 64) corresponds to at least one of a decreased channel condition associated with the second UE (see ¶¶31, 35, 36, 38, 39, 45, 56, 60); corresponds with change/reduce/decrease media path/channel state/conditional with User’s Terminal 206/ User’s Network component 21).
Payette also discloses wherein the decreased network condition at the second UE corresponds to at least one of increased network congestion (see ¶ 96: a reduction in the maximum available resources of the cellular sector is due to change in conditions such as change in load/congestion of the cellular sector).
Regarding claim 19, Balasaygun discloses wherein the first indication of the decreased network condition at the second UE corresponds to at least one of in-band signaling to the first UE (see ¶¶37, 40, 62, indication/instruction of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,… at User’s Terminal 206/ User’s Network component 210 correspond to any multimedia signaling (i.e. in-band signaling) to User’s Terminal 206/ User’s Network component 210), or
a real-time transport protocol (RTP) packet indicative of the decreased network condition at the second UE (see ¶¶7, 35, 54, indication/instruction at User’s Terminal 206/ User’s Network component 210 corresponds to Real time transport protocol (RTP) stream/packet/flow indication/instruction of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,… at User’s Terminal 206/ User’s Network component 210; also see ¶¶31, 33, 34, 54, 57, 64).
Regarding claim 20, Balasaygun discloses wherein the at least one of the in-band signaling or the RTP packet is indicative of at least one of an RTP extension header identifier (ID) (see ¶¶ 28,31, 32, 37, 49,50, 54; RTP stream/packet/flow is indicates extension which include number/ID in RTP header), a reference signal received quality (RSRQ) (see ¶¶ 10, 21, 33, 34, 38, 39, 62-66, 74-77, 81-83; received media/signal quality indication), or a received signal strength indicator (RSSI) (see ¶¶10, 33, 38, 62, 63; received signal strength indication).
Claims 7 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Balasaygun in view of Sakai et. al. (US 20170366362 A1).
Regarding claims 7 and 28, Balasaygun discloses wherein the at least one processor is further configured to transmit a request for at least one of information associated with the second UE (see ¶¶31, 45, 46, 56, 60, 64, transmitting triggering event request for the network information associated with User’s Terminal 206/ Network component 210) or information associated with the second UE based on the first indication received from the second UE of the decreased network condition at the second UE (see ¶¶31, 33, 34, 38, 54, 62, 64, Or, network information associated with User’s Terminal 206/ Network component 210 based on indication/instruction for RTCP information (from triggering event/request) of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,…, received from User’s Terminal 206/ Network component 210).
Although Balasaygun discloses transmit a request for information associated with the second UE as set for the above, Balasaygun does not explicitly disclose a request for “block error rate information (BLER)” information.
However, Sakai discloses transmit a request for at least one of block error rate (BLER) information associated with the second UE (see ¶¶ 54, 59-61: wireless communication unit transmits reception state information request message to terminal regarding packet/block lost/error rate).
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide a “block error rate information (BLER)” as taught by Sakai in the system of Balasaygun in order to reduce overhead (see Sakai ¶ 76).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Balasaygun in view of Singer et. al. (“A General Mechanism for RTP Header Extensions”, Network Working Group – Request for Comments: RFC 8285).
Regarding claim 10, Balasaygun discloses wherein a first number associated with the first indication received from the second UE (see ¶¶37, 40, 62, a first indication/instruction of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,… received from User’s Terminal 206/ User’s Network component 210 c) is indicative of the RTP extension header ID (see ¶¶ 28,31, 32, 37, 49,50, 54; is RTP stream/packet/flow which indicates extension with number/ID in RTP header ) and
the second number associated with the first indication received from the second UE is indicative of one or more of the, RSRQ (see ¶¶ 10, 21, 33, 34, 38, 39, 62-66, 74-77, 81-83; second indication/instruction received from User’s Terminal 206/ User’s Network component 210 is the received media/signal quality indication), or RSSI (see ¶¶10, 33, 38, 62, 63; received signal strength indication).
Although Balasaygun discloses wherein a first number associated with the first indication received from the second UE is indicative of the RTP extension header ID and the second number associated with the first indication received from the second UE is indicative of one or more of the RSRQ, or the RSSI as set for the above, Balasaygun does not explicitly disclose “number of bits”.
However, Singer discloses wherein a first number of bits associated with the first indication and second number of bits associated with the first indication (see § 4.3; two-byte header: Each extension element starts with a byte containing an ID and a byte containing a length; note that extension header data follows after the 8 bit identifier and the length field (which indicates the length in bytes of the extension header data) which associated with first indication of RTCP header).
Thus, Singer demonstrates that the use and structure of RTP header extensions is a known technique in the art, and one of ordinary skill in the art could have recognized that applying the standard RTP header structure to the header extension of the system of Balasaygun, would produce predictable results and resulted in a TCP header with a first number of bits being indicative of an RTP header extension ID, and a second number of bits (containing the header extension data) being indicative of RSRQ or RSSI.
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide “number of bits” as taught by Singer in the system of Balasaygun, because it is the standard configuration of RTP header extensions (see Singer ¶¶ 4.2-4.3).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Balasaygun in view of Payette et. al. (US 20130042275 A1), as applied to claim 13 above, and further in view of Yao (US 20190394534 A1).
Regarding claim 14, Balasaygun discloses wherein the at least one processor is further configured to receive a communication from the first UE based on a bit rate associated with the first indication transmitted to the first UE of the decreased network condition at the second UE (see FIG. 2, User’s Network component 210/ User’s Terminal 206 (i.e. second UE) receives plurality of RTCP reports/messages with plurality of indication/instruction (i.e. communication) from Network component 210/ User’s Network component 210 (i.e. first UE) based on changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate) associated with indication/instruction for RTCP information (from triggering event/request) of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,… at User’s Network component 210/ User’s Terminal 206 (i.e. second UE) ; see ¶¶31, 33, 34, 38, 54, 57, 62, 64).
Payette also discloses transmitting a communication from the first UE associated with the first indication transmitted to the first UE of the decreased network condition at the second UE (see Fig. 1: Cellular sector 123, mobile device (MD) 110; see Fig. 5 step 520: Receive a cellular sector/local indication of a condition; see ¶ 155: MD 110 receives an indication of a condition associated with a cellular sector, the condition includes a congestion condition in the cellular sector).
While the combined system of Balasaygun and Payette discloses transmitting a communication from the first UE based on a bit rate associated with the indication, the combined system does not explicitly disclose an “adjusted” bit rate.
However, Yao discloses receiving a communication from a first UE based on an adjusted rate (see ¶ 66: user device receives program content at a bitrate adjusted according to a request from the device).
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide an “adjusted” bit rate in the combined system of Balasaygun and Payette as taught by Yao in order to improve reliability of video transmission (see Yao ¶ 60).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Balasaygun in view of Payette et. al. (US 20130042275 A1) and Yao (US 20190394534 A1), as applied to claims 13 and 14 above, further in view of Qiu.
Regarding claim 15, Balasaygun discloses herein the at least one processor is further configured to receive an acknowledgment to the first indication transmitted to the first UE (see ¶¶11, 31, 33, 34, 45, 53, 54, 57, 62, 64; receiving acknowledgement/respond to indication/instruction for RTCP information (from triggering event/request) of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,…, to the indication/instruction transmitted to User’s Terminal 206/User’s Network component 210), the bit rate for the communication from the first UE being adjusted based on the acknowledgement to the first indication transmitted to the first UE (see ¶¶31, 33, 34, 38, 45, 46, 53, 54, 62, 64 ; a bit rate for the communication User’s Terminal 206/ Network component 210 being changed/adjusted based on the acknowledge/respond being transmitted to the indication/instruction to Network component 210/ User’s Network component 210 (i.e. first UE)).
While the combined system of Balasaygun, Payette and Yao discloses receive an acknowledgment to the first indication transmitted to the first UE, and, the bit rate for the communication from the first UE being adjusted based acknowledgment, the combined system does not explicitly disclose “the TMMBn as an acknowledgment, wherein the first indication corresponds to the TMMBr, the bit rate for the communication with the second UE being adjusted based on the TMMBn.”
However, Qiu discloses receiving the TMMBn as an acknowledgment to the indication transmitted to the first UE (see ¶ 49: after receiving TMMBR, data transmitter sends TMMBN as a response), wherein the indication corresponds to the TMMBr, the adjusted bit rate for the communication from the first UE being adjusted based on the TMMBn being received as the acknowledgement to the indication transmitted to the first UE (see Fig. 3 S307-S310: data transmitter sends TMMBN to data receiver, obtains bit rate information, calculates coding bit rate to be configured, and performs coding bit rate configuration; see ¶¶62-69).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide ““the TMMBn as an acknowledgment, wherein the first indication corresponds to the TMMBr, the bit rate for the communication with the second UE being adjusted based on the TMMBn.” as taught by Qiu in the combined system of Balasaygun, Payette and Yao, so that it would improve the quality of quality of video call; see Qiu, ¶25.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Balasaygun in view of Payette et. al. (US 20130042275 A1), as applied to claim 13 above, further in view of Mulvey et. al. (US 20100054519 A1).
Regarding claim 16, Balasaygun discloses wherein the at least one processor is further configured to transmit one or more subsequent indications of the decreased network condition at the second UE (see ¶¶31, 33, 34, 54, 57, 64; transmit plurality of RTCP reports/messages with plurality of indication/instruction (i.e. subsequence indications) at User’s Network component 210/ User’s Terminal 206 (i.e. second UE)), based on one or more requests for the decreased bit rate, (see ¶¶31, 33, 34, 38, 54, 62, 64,; in respond/reply to such plurality of indication/instruction (i.e. subsequence indications) associated with request for changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate)
wherein the one or more requests for the decreased bit rate are at least one of transmitted to the first UE over a predefined time duration or associated with a reduction of the decreased bit rate (see¶¶62-64, 81-83): respond/reply for changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate) are transmitted to Network component 210/ User’s Network component 210 (i.e. first UE) over time during a communication session while media path quality is changed/reduced/decreased bit rate (i.e. packet loss, delay, jitter, network congestion cause change/reduce/decrease bit rate)).
Although the combined system of Balasaygun and Payette discloses wherein the second indication is displayed at the first UE based on at least one of the one or more subsequent indications being received over a predefined time duration or the decreased bit rate being reduced as set forth above, the combined system of Balasaygun and Payette does not explicitly disclose the decreased bit rate being reduced “to a minimum threshold”.
However, Mulvey discloses providing an indication to a user of a bit rate being reduced to a minimum threshold (see ¶ 23: device determines whether the bitrate is above or below a threshold, when data rate is less than the threshold a visual indicator provides an indication of the lowered bitrate).
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the decreased bit rate being reduced “to a minimum threshold” as taught by Mulvey in the combined system of Balasaygun and Payette to enable the user to take corrective action (see Mulvey ¶23).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Balasaygun in view of Payette, as applied to claim 13 above, further in view of Sakai et. al. (US 20170366362 A1).
Regarding claim 18, Balasaygun discloses wherein the at least one processor is further configured to receive a request for at least one of information associated with the second UE (see ¶¶31, 45, 46, 56, 60, 64, receiving triggering event request for the network information associated with User’s Network component 210/ User’s Terminal 206 (i.e. second UE) or information associated with the second UE based on the first indication transmit to the first UE of the decreased network condition at the second UE (see ¶¶31, 33, 34, 38, 54, 62, 64, Or, network information associated with User’s Terminal 206/ Network component 210 based on indication/instruction for RTCP information (from triggering event/request) of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,…, associated with User’s Network component 210/ User’s Terminal 206 (i.e. second UE) based on information/indication transmit to Network component 210/ User’s Network component 210 (i.e. first UE) of change/reduce/decrease network state/conditional at User’s Network component 210/ User’s Terminal 206 (i.e. second UE))
Although the combined system of Balasaygun and Payette discloses transmit a request for information associated with the second UE as set for the above, Balasaygun does not explicitly disclose a request for “block error rate information (BLER)” information.
However, Sakai discloses receive a request for at least one of block error rate (BLER) information associated with the second UE (see ¶¶ 54, 59-61: wireless communication unit receive reception state information request message to terminal regarding packet/block lost/error rate).
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide a “block error rate information (BLER)” as taught by Sakai in the system of Balasaygun in order to reduce overhead (see Sakai ¶ 76).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Balasaygun in view Payette, as applied to claims 13 and 20 above, further in view of Singer et. al. (“A General Mechanism for RTP Header Extensions”, Network Working Group – Request for Comments: RFC 8285).
Regarding claim 21, Balasaygun discloses wherein a first number associated with the first indication transmitted to the first UE (see ¶¶37, 40, 62, a first indication/instruction of change/reduce/decrease network state/conditional due to network change, delay, error, communication problem, a media problem,… transmitted to Network component 210/ User’s Network component 210 (i.e. first UE) ) is indicative of the RTP extension header ID (see ¶¶ 28,31, 32, 37, 49,50, 54; is RTP stream/packet/flow which indicates extension with number/ID in RTP header ) and
the second number associated with the first indication transmitted to the first UE is indicative of one or more of the, RSRQ (see ¶¶ 10, 21, 33, 34, 38, 39, 62-66, 74-77, 81-83; second indication/instruction received to Network component 210/ User’s Network component 210 (i.e. first UE) is the received media/signal quality indication), or RSSI (see ¶¶10, 33, 38, 62, 63; received signal strength indication).
Although Balasaygun discloses wherein a first number associated with the first indication transmitted to the first UE is indicative of the RTP extension header ID and the second number associated with the first indication transmitted to the first UE is indicative of one or more of the RSRQ, or the RSSI as set for the above, Balasaygun does not explicitly disclose “number of bits”.
However, Singer discloses wherein a first number of bits associated with the first indication and second number of bits associated with the first indication (see § 4.3; two-byte header: Each extension element starts with a byte containing an ID and a byte containing a length; note that extension header data follows after the 8 bit identifier and the length field (which indicates the length in bytes of the extension header data) which associated with first indication of RTCP header).
Thus, Singer demonstrates that the use and structure of RTP header extensions is a known technique in the art, and one of ordinary skill in the art could have recognized that applying the standard RTP header structure to the header extension of the system of Balasaygun, would produce predictable results and resulted in a TCP header with a first number of bits being indicative of an RTP header extension ID, and a second number of bits (containing the header extension data) being indicative of RSRQ or RSSI.
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide “number of bits” as taught by Singer in the system of Balasaygun, because it is the standard configuration of RTP header extensions (see Singer ¶¶ 4.2-4.3).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ian N Moore whose telephone number is (571)272-3085. The examiner can normally be reached M-F: 9 AM - 5:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Deborah J Reynolds can be reached at 571-272-0734. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
IAN N. MOORE
Supervisory Patent Examiner
Art Unit 2469
/Ian N Moore/Supervisory Patent Examiner, Art Unit 2469
1 See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
2 Normal condition status= Displaying image WITHOUT a broken link next to any device where quality and/or performance level is not below (i.e. above) a specific threshold; see ¶¶47,57, 58
3 Normal condition status= Displaying image WITHOUT a broken link next to any device where quality and/or performance level is not below (i.e. above) a specific threshold; see ¶¶47,57, 58
4 Displaying image WITHOUT a broken link next to any device; see ¶¶47,57, 58
5 Normal condition status= Displaying image WITHOUT a broken link next to any device where quality and/or performance level is not below (i.e. above) a specific threshold; see ¶¶47,57, 58