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 with respect to claim(s) 1-7 and 10-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-7, 11-13, and 15-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu et al. (US 2022/0197589 A1, previously cited in an IDS received 04/25/2025 and hereafter Liu) in view of Winiarczyk et al. (US 2023/0051075 A1, previously cited and hereafter Winiarczyk) and further in view of “The Bluetooth Low Energy Primer” by Martin Woolley (hereafter Woolley).
Regarding claim 1, first Liu teaches:
“A method for controlling one or more audio devices” by teaching a BLUETOOTH audio broadcasting method (see Liu, abstract and figures 2 and 4-5),
“comprising:
transmitting, from a first audio device, a broadcast stream” by teaching that an audio broadcasting device (first audio device) broadcasts (transmits) audio packets (a broadcast stream) containing audio data through a Broadcast Isochronous Stream (BIS) logical transport (see Liu, ¶ 0046, 0063, and 0103, figures 1 and 3, unit 150, and figure 2, step 210).
Herein, Liu teaches a step for “receiving input data from a second audio device, wherein the input data is related to adjusting playback of the broadcast stream” by teaching that an audio source device (second audio device) receives an input to adjust the volume of the broadcast stream (see Liu, ¶ 0103 and 0107, and figure 3, unit 370 and signal VAS). However, Liu does not appear to teach the features “wherein the input data is transmitted from the second audio device to the first audio device via a mesh protocol data unit, and wherein the mesh protocol data unit is time synchronized with the broadcast stream to prevent temporal overlap with the broadcast stream”.
Winiarczyk discloses a method of processing mesh network data packets that have invalid cyclic redundancy check (CRC) values to improve a packet processing rate (see Winiarczyk, abstract and ¶ 0005-0008). Winiarczyk teaches the BLUETOOTH Mesh networking protocol for a “many-to-many” communication over BLUETOOTH radio for a more efficient way to route data as compared to other types of networks (see Winiarczyk, ¶ 0005-0006). Winiarczyk further teaches that the mesh network nodes (i.e., devices) receive and/or transmit one or more packets each comprising a protocol data unit (PDU) (see Winiarczyk, ¶ 0013). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to modify Liu with the teachings of Winiarczyk for the purpose of improving the efficiency of the network (see Liu, ¶ 0046-0047, 0055, and 0122, in view of Winiarczyk, ¶ 0005, 0008, and 0013).
Next, Woolley teaches features of Bluetooth Low Energy (LE) as known prior to the effective filing date of the instant application (see Woolley, pp. 1-2 and 8-9). Specifically, Woolley teaches features of the BIS logical transport that Lie discloses (see Liu, ¶ 0046 and 0062-0063 and see Woolley, p. 5 and pp. 40-48). Herein, Woolley provides evidence that the BIS or BIG PDUs taught by Liu (see Liu, ¶ 0062) comprise events and sub-events that are time synchronized in the broadcast stream to prevent temporal overlap, because the events and sub-events are evenly spaced events defined by transmitted parameters, such as ISO_Interval, BIS_Spacing, and/or Sub_Interval parameters (see Woolley, p. 40, first paragraph of section “7.7.4.1 Basics”, p. 42, section “7.7.4.2.3 Scheduling” and figure 25, and p. 46, section “7.7.4.3.3 Scheduling” and figure 29). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to modify the combination of Liu and Winiarczyk with the teachings of Woolley for the purpose of using the known features of BLE Audio technology specified in the Bluetooth Core Specification (see Liu, ¶ 0046 in view of Woolley, pp. 8-9).
Therefore the combination of Liu, Winiarczyk, and Woolley makes obvious the features for:
“receiving input data from a second audio device, wherein the input data is related to adjusting playback of the broadcast stream, wherein the input data is transmitted from the second audio device to the first audio device via a mesh protocol data unit” because Winiarczyk makes obvious to send the control data in a mesh network, such as sending one or more packets each comprising a protocol data unit (PDU) in a mesh network (see Liu, ¶ 0046-0047, 0055, and 0122, in view of Winiarczyk, ¶ 0005, 0008, and 0013), “and wherein the mesh protocol data unit is time synchronized with the broadcast stream to prevent temporal overlap with the broadcast stream” because PDUs taught by Liu (see Liu, ¶ 0046, 0062-0063, and 0122) comprise events and sub-events that are time synchronized in the broadcast stream to prevent temporal overlap by showing that the events and sub-events are evenly spaced events defined by transmitted parameters, such as ISO_Interval, BIS_Spacing, and/or Sub_Interval parameters (see Woolley, p. 40, first paragraph of section “7.7.4.1 Basics”, p. 42, section “7.7.4.2.3 Scheduling” and figure 25, and p. 46, section “7.7.4.3.3 Scheduling” and figure 29); and
“transmitting command data from the first audio device to one or more other audio devices, wherein the command data is based on the input data, and wherein the command data is time synchronized with the broadcast stream to prevent overlap with the broadcast stream” by teaching that the volume adjusting signal (VAS) is received at the first audio device and the first audio device transmits to multiple other devices a predetermined volume instruction for the first and other multiple devices to begin playback audio at the same volume (see Liu, ¶ 0096-0098 and 0101-0102), and teaching that volume adjustments are performed synchronously at the first and other multiple devices according to transmitted volume adjusting instructions (command data) (see Liu, ¶ 0141-0143, figure 4, steps 222-234, and figure 5, steps 506-514).
Regarding claim 2, see the preceding rejection with respect to claim 1 above. The combination makes obvious the “method of claim 1, wherein a broadcast protocol data unit of the broadcast stream includes the command data” by teaching the method using the BLUETOOTH protocol and the first audio device inserts the volume adjusting instructions (command data) into BIS protocol data units (PDUs) (see Liu, ¶ 0046, 0055, 0062, and 0122).
Regarding claim 3, see the preceding rejection with respect to claim 2 above. The combination makes obvious the “method of claim 2, wherein the broadcast protocol data unit comprises sequence data, source data, and/or destination data” by teaching that the BIS PDUs include the address of the audio broadcasting device (first device) (see Liu, ¶ 0062).
Regarding claim 4, see the preceding rejection with respect to claim 3 above. The combination makes obvious the method of claim 3, wherein the one or more other audio devices implement the command data by teaching the insertion of the volume adjusting instructions (command data) into BIS PDUs or Broadcast Isochronous Group (BIG) PDUs (see Liu, ¶ 0055 and 0122). Liu teaches that the command data is inserted into one or more specific fields of the PDUs, such as an Event Counter field, Sub-Event Counter field, Payload Counter field, etc. (see Liu, ¶ 0122). However, Liu does not explicitly teach the feature where “one or more other audio devices implement the command data based on the sequence data, the source data, and/or the destination data” (italics for emphasis).
As stated above, Liu teaches that the command data is inserted into one or more specific fields of the PDUs, such as an Event Counter field, Sub-Event Counter field, Payload Counter field, etc. (see Liu, ¶ 0122), and teaches that the volume adjusting is synchronous among the other devices playing the audio data (see Liu, ¶ 0162-0163). One of ordinary skill at the time of the effective filing date would have found it obvious that one or more of the various counter fields are analogous to sequence data, because counters provide an easy method to order the data such that the volume adjustments are synchronous among the devices.
Therefore, The combination makes obvious the “method of claim 3, wherein the one or more other audio devices implement the command data based on the sequence data, the source data, and/or the destination data” by teaching the insertion of the volume adjusting instructions (command data) into BIS PDUs or Broadcast Isochronous Group (BIG) PDUs, where the command data is inserted into one or more specific fields of the PDUs, such as an Event Counter field, Sub-Event Counter field, Payload Counter field, etc. (see Liu, ¶ 0055 and 0122); where it is obvious that the audio devices implement the command data based on sequence data, or counters, to synchronously adjust the volume (see Liu, ¶ 0162-0163 in view of ¶ 0122).
Regarding claim 5, see the preceding rejection with respect to claim 2 above. The combination makes obvious the “method of claim 2, wherein the broadcast protocol data unit further includes an audio payload” by teaching that audio data is broadcast in audio packets (i.e., audio payload in multiple packets) through the BIS logical transport to multiple other devices (see Liu, ¶ 0046 and 0106).
Regarding claim 6, see the preceding rejection with respect to claim 5 above. The combination makes obvious the “method of claim 5, wherein the audio payload corresponds to an audio stream transmitted by an external audio device” by teaching that the audio payload (audio data) is streamed from an external audio device (i.e., the audio source device, 370) (see Liu, ¶ 0109, 0155, 0166-0167, 0181, 0183, 0193, and 0197, figure 6, units 150 and 370, and signal AS).
Regarding claim 7, see the preceding rejection with respect to claim 1 above. The combination makes obvious the “method of claim 1, wherein the command data is a relay of the input data” by teaching that the VAS instruction is relayed based on the user’s manipulation, or input, of the first BLUETOOTH member device (110), such that the input data is a volume adjustment request (VAR) according to the user’s manipulation, and the VAR signal is received by the second audio device (the host device, 660) in order to relay the command data as the VAS instruction (see Liu, ¶ 0005, 0032, 0157, 0183, 0187, and 0192-0193, and figure 8, units 110, 660-661, and 815-816, and signals VAR and VAS).
Regarding claim 11, see the preceding rejection with respect to claim 1 above. The combination makes obvious the method of claim 1, wherein the command data is the inserted volume adjusting instructions, which is inserted into the BIS PDUs or BIG PDUs (see Liu, ¶ 0055 and 0122). However, Liu does not explicitly teach the feature where “the command data comprises timing information”.
Liu teaches that the volume adjusting is synchronous among the other devices playing the audio data (see Liu, ¶ 0162-0163), and teaches that the command data is inserted into one or more specific fields of the PDUs, such as an Event Counter field, Sub-Event Counter field, Payload Counter field, etc. (see Liu, ¶ 0122). One of ordinary skill at the time of the effective filing date would have found it obvious that one or more of the various counter fields are analogous to timing information, because counters provide an easy method to order the data such that the volume adjustments are synchronous among the devices.
Therefore, the combination makes obvious the “method of claim 1, wherein the command data comprises timing information, and wherein the one or more other audio devices execute the adjusting of the playback of the broadcast stream according to the timing information” because the one or more specific fields of the PDUs, such as an Event Counter field, Sub-Event Counter field, Payload Counter field, etc., into which the command data has been inserted makes obvious timing information in order to synchronously adjust the volume (see Liu, ¶ 0162-0163 in view of ¶ 0122).
Regarding claim 12, see the preceding rejection with respect to claim 11 above. The combination makes obvious the “method of claim 11, wherein the timing information is related to the broadcast stream” because the one or more specific fields of the PDUs, which make obvious the timing information for synchronous volume adjustment, are part of the broadcast stream (i.e., the Broadcast Isochronous Stream containing the audio packets and command information) (see Liu, ¶ 0046 and 0122).
Regarding claim 13, see the preceding rejection with respect to claim 1 above. The combination makes obvious the “method of claim 1, wherein the input data corresponds to a volume control command or a status check command” by teaching the volume instruction (VAS) corresponding to an input (see Liu, ¶ 0103, 0107, 0155, and 0160, and figure 6, units 660-661, 663, and 665).
Regarding claim 15, see the preceding rejection with respect to claim 1 above. The combination makes obvious the “method of claim 1, wherein the second audio device is configured to receive the broadcast stream from the first audio device” by teaching that the second audio device (the first BLUETOOTH member device 110) is configured to receive the broadcast stream from the first audio device (the audio broadcasting device 150), such that the first audio device receives the input data from the second audio device to adjust the volume (see Liu, ¶ 0201-0202, 0206, and 0208, and figure 9, units 110 and 150, and signal VAS).
Regarding claim 16, see the preceding rejection with respect to claim 1 above. Liu teaches various features as detailed above with respect to claim 1, however Liu does not appear to teach the features “wherein the input data is transmitted from the second audio device to the first audio device via a mesh protocol data unit, and wherein the mesh protocol data unit is time synchronized with the broadcast stream to prevent temporal overlap with the broadcast stream”.
Winiarczyk teaches the BLUETOOTH Mesh networking protocol for a “many-to-many” communication over BLUETOOTH radio for a more efficient way to route data as compared to other types of networks (see Winiarczyk, ¶ 0005-0006), and further teaches that the mesh network nodes (i.e., devices) receive and/or transmit one or more packets each comprising a protocol data unit (PDU) (see Winiarczyk, ¶ 0013). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to modify Liu with the teachings of Winiarczyk for the purpose of improving the efficiency of the network (see Liu, ¶ 0046-0047, 0055, and 0122, in view of Winiarczyk, ¶ 0005, 0008, and 0013).
Woolley provides evidence that the BIS or BIG PDUs taught by Liu (see Liu, ¶ 0062) comprise events and sub-events that are time synchronized in the broadcast stream to prevent temporal overlap, because the events and sub-events are evenly spaced events defined by transmitted parameters, such as ISO_Interval, BIS_Spacing, and/or Sub_Interval parameters (see Woolley, p. 40, first paragraph of section “7.7.4.1 Basics”, p. 42, section “7.7.4.2.3 Scheduling” and figure 25, and p. 46, section “7.7.4.3.3 Scheduling” and figure 29). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to modify the combination of Liu and Winiarczyk with the teachings of Woolley for the purpose of using the known features of BLE Audio technology specified in the Bluetooth Core Specification (see Liu, ¶ 0046 in view of Woolley, pp. 8-9).
Therefore the combination of Liu, Winiarczyk, and Woolley makes obvious:
“A system for controlling one or more audio devices” by teaching a BLUETOOTH audio broadcasting system (see Liu, abstract and figures 1 and 3),
“comprising:
a first audio device configured to:
transmit a broadcast stream” by teaching a first audio device that transmits a broadcast stream containing audio data through a BIS logical transport from (see Liu, ¶ 0046, 0063, and 0103, figures 1 and 3, unit 150, and figure 2, step 210);
“receive input data from a second audio device, wherein the input data is related to adjusting playback of the broadcast stream, wherein the input data is transmitted from the second audio device to the first audio device via a mesh protocol data unit” because Winiarczyk makes obvious to send the control data in a mesh network, such as sending one or more packets each comprising a protocol data unit (PDU) in a mesh network (see Liu, ¶ 0046-0047, 0055, and 0122, in view of Winiarczyk, ¶ 0005, 0008, and 0013), “and wherein the mesh protocol data unit is time synchronized with the broadcast stream to prevent temporal overlap with the broadcast stream” because PDUs taught by Liu (see Liu, ¶ 0046, 0062-0063, and 0122) comprise events and sub-events that are time synchronized in the broadcast stream to prevent temporal overlap by showing that the events and sub-events are evenly spaced events defined by transmitted parameters, such as ISO_Interval, BIS_Spacing, and/or Sub_Interval parameters (see Woolley, p. 40, first paragraph of section “7.7.4.1 Basics”, p. 42, section “7.7.4.2.3 Scheduling” and figure 25, and p. 46, section “7.7.4.3.3 Scheduling” and figure 29); and
“transmit command data to one or more other audio devices, wherein the command data is based on the input data, and wherein the command data is time synchronized with the broadcast stream to prevent overlap with the broadcast stream” by teaching that the volume adjusting signal (VAS) is received at the first audio device and the first audio device transmits to multiple other devices a predetermined volume instruction for the first and other multiple devices to begin playback audio at the same volume (see Liu, ¶ 0096-0098 and 0101-0102), and teaching that volume adjustments are performed synchronously at the first and other multiple devices according to transmitted volume adjusting instructions (command data) (see Liu, ¶ 0141-0143, figure 4, steps 222-234, and figure 5, steps 506-514).
Regarding claim 17, see the preceding rejection with respect to claim 16 above. The combination makes obvious the “system of claim 16, wherein the first audio device, the second audio device, and each of the one or more other audio devices are speakers” by teaching that the different devices are speakers, such as BLUETOOTH SPEAKERS, a BLUETOOTH smart speaker, and/or a smart speaker (see Liu, ¶ 0031, 0047, 0157, and figure 6, units 110, 120, 150, and 660).
Regarding claim 18, see the preceding rejection with respect to claim 16 above. The combination makes obvious the “system of claim 16, wherein the second audio device comprises a user interface configured to receive the input data” by teaching the second audio device, or host device, with an input circuit to receive input data corresponding to the volume instruction (VAS) (see Liu, ¶ 0103, 0107, 0155, and 0160, and figure 6, units 660-661, 663, and 665).
Regarding claim 19, see the preceding rejection with respect to claim 16 above. The combination makes obvious the “system of claim 16, wherein the second audio device receives the input data via an external audio device” by teaching that an external audio device (the first BLUETOOTH member device, 110) generates a volume adjustment request (VAR) according to the user’s manipulation, and the VAR signal is received by the second audio device (the host device, 660) (see Liu, ¶ 0005, 0032, 0157, 0183, 0187, and 0192-0193, and figure 8, units 110, 660-661, and 815-816, and signals VAR and VAS).
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Liu, Winiarczyk, and Woolley as applied to claim 1 above, and further in view of Millington (US 2015/0039109 A1, previously cited).
Regarding claim 10, see the preceding rejection with respect to claim 1 above. The combination of Liu, Winiarczyk, and Woolley makes obvious the method of claim 1, but does not appear to teach that “the input data is a request to change transmission of the broadcast stream from the first audio device to the second audio device”.
Millington discloses a method for synchronizing operations, such as audio playback, among a number of digital data processing devices in a network (see Millington, ¶ 0004, 0007, and 0009). Herein, Millington teaches multiple zone players 11(n) (see Millington, ¶ 0016, and figure 1, units 11(1) and 11(N)), where any zone player is able to be connected to one or more audio information sources 14(n)(s) (see Millington, ¶ 0016 and figure 1, units 14(1)(1), 14(1)(S1), 14(N)(1), and 14(N)(SN)). Millington teaches that the audio information sources comprise any number of conventional sources of audio, such as CD players, AM/FM radios, analog or digital cassette players, turntables, devices storing digital audio including personal computers, and the like (see Millington, ¶ 0018), and teaches that one or more zone players have integrated audio information sources therein(see Millington, ¶ 0195 and 0201).
Importantly, Millington also teaches that that one or more user interfaces control the configuration and playback of the zone players and audio information sources, such that a number of zone players form a synchrony group to playback the same audio information in synchrony (see Millington, ¶ 0021, 0027, and 0196). The method allows the system to be configured so that any zone player receives user designated audio information, provides playback of the designated audio information, and/or forwards the designated audio information to another zone player according to the formed synchrony groups (see Millington, ¶ 0019 and 0022-0023).
Millington also teaches that when a zone player acts as a master device, it provides broadcast audio information to one or more slave devices in a synchrony group (see Millington, ¶ 0028-0029, 0076, and 0195). Next, Millington teaches that a user requests the master device to disengage from the synchrony group, such that a zone player acting as a slave becomes the master and then the new master zone player provides the broadcast stream to the other remaining slave devices in the synchrony group (see Millington, ¶ 0022-0023, 0028-0030, 0051, 0076, and 0195).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to modify the combination of Liu, Winiarczyk, and Woolley with the teachings of Millington in order to allow continued synchronous playback when a user reconfigures an audio broadcast (see Liu, ¶ 0005 and 0031 in view of Millington, ¶ 0004-0009 and 0022).
Therefore, the combination of Liu, Winiarczyk, Woolley, and Millington makes obvious the “method of claim 1, wherein the input data is a request to change transmission of the broadcast stream from the first audio device to the second audio device, and wherein the command data is configured to enable the second audio device to transmit the broadcast stream and to enable the one or more other audio devices to receive the broadcast stream from the second audio device” by making it obvious to dynamically configure audio devices into synchrony groups for synchronous playback of the same broadcast audio stream, such that when a master device disengages from a synchrony group, a zone player acting as a slave becomes the master, and the new master zone player provides the broadcast stream to the other remaining slave devices in the synchrony group (see Millington, ¶ 0022-0023, 0028-0030, 0051, 0076, and 0195).
Claim(s) 14 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Liu, Winiarczyk, and Woolley as applied to claim 1 above, and further in view of Haggai et al. (US 2022/0116711 A1, previously cited in an IDS received 04/25/2025 and hereafter Haggai).
Regarding claim 14, see the preceding rejection with respect to claim 1 above. The combination of Liu, Winiarczyk, and Woolley makes obvious the method of claim 1, but does not appear to teach that “the one or more other audio devices transmit feedback data corresponding to the adjusting of the playback of the broadcast stream”.
Haggai teaches methods for establishing a feedback channel, such as a BLUETOOTH broadcast audio feedback channel (see Haggai, abstract and ¶ 0001). Herein, Haggai teaches that the feedback channel is used to determine power levels for broadcasting audio, which RF channels to use, report issues related to the broadcast audio, and/or the like (see Haggai, ¶ 0018-0019, 0036-0038, 0100, and 0102). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to modify the combination of Liu, Winiarczyk, and Woolley with the teachings of Haggai for the purpose of adjusting the broadcast audio according to feedback to improve the performance of the audio broadcast (see Haggai, ¶ 0038).
Therefore, the combination of Liu, Winiarczyk, Woolley, and Haggai makes obvious the “method of claim 1, wherein the one or more other audio devices transmit feedback data corresponding to the adjusting of the playback of the broadcast stream, and wherein the feedback data is transmitted via a mesh protocol data unit” because Haggai makes obvious the use of a BLUETOOTH broadcast audio feedback channel to allow the other audio devices to report metrics and/or issues related to the broadcast audio in order to adjust the broadcast parameters to improve the performance of the audio broadcast (see Haggai, ¶ 0018-0019, 0036-0038, 0100, and 0102).
Regarding claim 20, see the preceding rejection with respect to claim 16 above. The combination of Liu, Winiarczyk, and Woolley makes obvious the system of claim 16, but does not appear to teach that “the one or more other audio devices are positioned outside of a transmission range of the second audio device”. For the same reasons as stated above with respect to claim 14, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date to modify the combination of Liu, Winiarczyk, and Woolley with the teachings of Haggai for the purpose of adjusting the broadcast audio according to feedback to improve the performance of the audio broadcast (see Haggai, ¶ 0038). Furthermore, Haggai teaches a BLUETOOTH access point (AP) that streams audio to a small area or group of users (see Haggai, ¶ 0028-0030 and 0034-0035, and figure 1).
The combination of Liu, Winiarczyk, Woolley, and Haggai makes obvious the “system of claim 16, wherein the one or more other audio devices are positioned outside of a transmission range of the second audio device” because Haggai makes obvious different devices, such as the access points and user devices, where one or more devices are out of range from other devices receive an audio broadcast relayed from an AP (see Haggai, ¶ 0028-0030 and 0035-0036).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Xu (US 2024/0056207 A1, previously cited) discloses audio broadcasting methods and devices using BLUETOOTH Low Energy (BLE) audio technology using a BIS link (see Xu, abstract and ¶ 0003-0004), where data on the BIS link is made to be bi-directional between master and slave devices using a reverse link with one or more time slots (see Xu, abstract, ¶ 0005-0006 and figures 1-5); and
Ferrari et al. (US 2024/0305927 A1, previously cited and hereafter Ferrari) discloses a method and system for transmitting audio signals using BLE audio between an audio signal transmitting unit and an audio signal receiving unit, where BIS and BIG PDUs are utilized (see Ferrari, abstract and figures 1-4 and 7-8).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Daniel R Sellers whose telephone number is (571)272-7528. The examiner can normally be reached Mon - Fri 10:00-4:00.
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, Fan S Tsang can be reached at (571)272-7547. 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.
/Daniel R Sellers/Primary Examiner, Art Unit 2694
Prosecution Insights