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 .
DETAILED ACTION
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1 – 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement for the reasons set forth below.
Claim 1 recites "transmit data using a modified protocol stack that includes a modified data link control layer and an unmodified media access layer"; Claim 7 recites "configuring a transmission protocol comprising a modified data link control layer and an unmodified media access control layer"; and Claim 17 recites "configure a transmission protocol including a modified logical link control (LLC) layer and an unmodified media access control (MAC) layer".
Under the contextual broadest reasonable interpretation, the data link control and media-access limitations in claims 1 and 7 encompass the disclosed modified LLC and preserved conventional MAC processing (para 0048; para 0067; para 0082).
The modified-layer limitations are not restricted to the single-protocol audio-packet modification or audio frame-buffer configuration disclosed in the specification, and encompass other changes to conventional LLC processing consistent with the remaining claim limitations (claims 1, 7, and 17; para 0069; para 0081).
Claim 1 recites no data type, format, or locality restriction and applies that genus to data without those restrictions.
A genus is adequately described by a representative number of species or structural features common to its members that enable a person of ordinary skill to visualize or recognize the members, with sufficient variety where variation within the genus is substantial; MPEP 2163(II)(A)(3)(a)(ii); Ariad, 598 F.3d at 1349-51. Describing one way of achieving a result does not describe every way within a functionally defined genus, and generic language in an original claim does not itself establish possession of that genus; LizardTech, Inc. v. Earth Res. Mapping, Inc., 424 F.3d 1336, 1346 (Fed. Cir. 2005); MPEP 2161.01(I) and 2163.03(V).
The specification does not describe the claimed genus; but rather, it states that "The modification of the LLC sublayer will now be described in the following sections" (para 0067). The next paragraph describes conventional LLC processing, not a modification: "The LLC also provides flow control and automatic repeat request (ARQ) error management mechanisms." (para 0068). The described protocol restriction is audio-specific: "only a specific network protocol may be supported for sending audio packets of known type and size across the wireless network" (para 0069). Separately, "certain implementations of the disclosed technology may augment the synchronization functionality" by "configuring the audio frame buffer size" in the LLC (para 0081). These passages describe species or partial species of modification, not a representative variety of changes beyond single-protocol audio packets of known type and size or audio frame-buffer configuration (para 0069; para 0081). Other language states purposes rather than the LLC operations that achieve them: modifications "to implement a custom security methodology, to select which wireless audio devices are allowed to join the network, and to enable more than one Hub to operate in the same physical space" (para 0070). Although identifier filtering and buffer configuration are described, the specification does not describe the LLC operations implementing each of those stated purposes or identify structure common to the full claimed class of modifications (para 0077-0081).
The described changes are tied to "(1) transmission of only one type of data in a known format, and (2) no transmission of the data outside of the local wireless physical space (contiguous space)" (para 0050).
Claims 1, 7, and 17 do not limit the modified layer to modifications of that disclosed type (claims 1, 7, and 17).
The single-protocol audio disclosure and audio frame-buffer configuration do not supply a representative number of species of the claimed modified-layer genus, and the specification discloses no structural feature common to that genus sufficient to show possession of its full scope; Ariad, 598 F.3d at 1349-51; MPEP 2163(II)(A)(3)(a)(ii).
Accordingly, the specification does not reasonably convey possession of the full scope of the modified layer recited in claims 1, 7, and 17.
Dependent claims 2, 3, 4, 5, and 6 are rejected under 35 U.S.C. 112(a) because they retain the modified-layer genus of claim 1.
Dependent claims 8, 9, 10, 11, 12, 13, 14, 15, and 16 are rejected under 35 U.S.C. 112(a) because they retain the modified-layer genus of claim 7, directly or through claims 10, 14, and 15.
Dependent claims 18, 19, and 20 are rejected under 35 U.S.C. 112(a) because they retain the modified-layer genus of claim 17.
None of these dependent claims confines the modified layer to a described species; claim 2 specifies Inter-IC Sound data format, and claim 14 adds frame-buffer configuration, but neither replaces or confines the inherited modified-layer genus to the single-protocol audio-packet modification of para 0069 or the audio frame-buffer modification of para 0081. The video-data limitation of claim 3, the SDR-unit limitation of claim 4, and the further limitations of claims 5, 6, 8-13, 15, 16, and 18-20 likewise leave the modified-layer genus in place.
In addition, claim 4 recites "wherein the central device and the peripheral device are configurable software-defined radio (SDR) units". The rejection is not based on absence of identical terminology in the specification; the claimed subject matter need not be described in the same words; MPEP 2163.02.
The original-claim presumption is overcome because the ordinary meaning of the SDR limitation requires software-defined physical-layer functionality, while the closest substantive disclosure describes link-layer configuration and an unmodified physical layer without identifying any physical-layer function as software defined.
The Wireless Innovation Forum, Document WINNF-12-R-0006, Version Vl.0.0, dated 1 November 2012, defines Software Defined Radio as "Radio in which some or all of the physical layer functions are software defined" (section 2, p. 5)
Under that ordinary meaning, claim 4 requires the central device and the peripheral device to be radios in which some or all physical-layer functions are software defined.
The specification describes "a configurable software-defined hub", "one or more configurable software-defined nodes", and "a software-defined transceiver chain comprising a configurable hub transmitter and authorized node receiver" (para 0020).
It describes "configuring a software-defined transceiver chain comprising a configurable hub transmitter and an authorized node receiver with a modified Logical Link Control (LLC) layer and an unmodified Media Access Control (MAC) layer" (para 0084).
Those passages describe software configuration of hub and node roles and the LLC/MAC arrangement; they do not describe modulation, demodulation, filtering, or intermediate-frequency or baseband processing as software defined (para 0020; para 0084).
Instead, the specification states that implementations "take advantage of the robust functionality of the Physical Layer (Layer 1) without any modification" and that "The modulations used with 802.11 are (DSSS, OFDM, MIMO-ODFM)." (para 0083).
It also describes a manufacturer identifier that a manufacturer may "program into a wireless chip" (para 0077).
In light of that disclosure, the software-defined hub, nodes, and transceiver chain do not describe the software-defined physical-layer functionality required by claim 4; possession of software-configurable link-layer devices does not reasonably convey possession of the SDR units claimed; Ariad, 598 F.3d at 1351; MPEP 2163.02 and 2163(1)(A).
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1, 6, 7, 9, 10, 12, 13, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Davidson (US 2014/0351445 Al) in view of Phillips (EP 1635508 Al) in view of Barrett (US 2016/0057055).
Per claim 1, Davidson (US 2014/0351445 Al) is relied upon to teach a wireless communication system (reads on "Wireless communication channel 130 may comprise any channel capable of propagating wireless communication signals between wireless service seeker 110 and wireless service advertiser 120", see Davidson para 0017. Channel 130 is the wireless medium joining the advertiser and the seeker, so Davidson describes a wireless communication system of at least two devices.), comprising: a central device (reads on "wireless service advertiser 120 may comprise a WFD group owner (GO), and wireless service seeker 110 may comprise a WFD client", see Davidson para 0052; "the GO configures itself into an access point, and sends an SSID (service set identification) and a Wi-Fi direct identifier to other devices that wish to connect with the GO", see Davidson para 0020. The group owner sets itself up as the access point that other devices join, which is the coordinating role of the claimed central device.); and one or more peripheral devices (reads on "Other devices, referred to as P2P clients, which do not serve as the GO then connect to the SSID of the GO to establish a secure communication channel", see Davidson para 0021. The P2P clients (plural) are the devices that join the group owner, matching peripheral devices served by the central device.); wherein the central device is configured to: establish a secure communication link with at least one peripheral device of the one or more peripheral devices (reads on "ASP P2P communications allow wireless service advertiser 120 and wireless service seeker 110 to setup a secure communication channel when wireless service advertiser 120 and wireless service seeker 110 come within operative communication range of each other", see Davidson para 0019; "Other devices, referred to as P2P clients, which do not serve as the GO then connect to the SSID of the GO to establish a secure communication channel", see Davidson para 0021. Davidson uses nearly the claim words ("setup a secure communication channel") for the link between the group owner and each client that connects to it.) and transmit data (reads on "Responsive to establishing the ASP session, wireless service advertiser 120 may communicate to wireless service seeker 110 using the ASP session", see Davidson para 0049. The group owner (advertiser 120) transmits to the client over the established session). The prior art of record is silent on explicitly stating based on device-specific information; and transmit data using a modified protocol stack that includes a modified data link control layer and an unmodified media access layer.
Phillips (EP 1635508 Al) is relied upon to teach based on device-specific information (reads on "The host device 20 receives the peripheral device identification in step P2 of the process in Figure 3, and then passes to step P3, in which a mutual authentication procedure is performed", see Phillips para 0031; "the peripheral device 10 associates its printed serial number 19 to its public key when authenticating with the host device 20", see Phillips para 0035; "As a by-product of the authentication procedure, the host device 20 and peripheral device 10 generate a common secret key, that is used to secure all subsequent message interchanges between them", see Phillips para 0037. In Phillips the host receives the peripheral's identification, the peripheral binds that identification to its public key during authentication, and the authentication yields the key that secures all later traffic; the link security is therefore derived from authenticating device-specific information, not merely preceded by its receipt. In the combination the group owner of Davidson performs the host role, and the identity it authenticates is a device-level identity of the kind the devices of Davidson already use ("may identify a second, different wireless computing device based on the data link layer MAC address of the second wireless computing device", see Davidson para 0025)).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the secure P2P channel set-up of Davidson, in which the group owner and its P2P clients set up a secure communication channel (see Davidson para 0019) and identify one another by their data link layer MAC addresses (see Davidson para 0025), by integrating the identity-bound mutual authentication of Phillips, in which a host device receives the peripheral device's identification, authenticates the peripheral by a public-key challenge-response in which that identification is bound to the peripheral's public key, and thereby derives the key that secures the link (see Phillips para 0034: "One possibility is to use certificates issued by a trusted authority that binds these two values together (e.g. X509)") to realize the instant limitations. One or more of the underpinning rationale(s), as discussed in KSR, also see MPEP 2141 {A, C}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have had the group owner of Davidson (central device) authenticate each P2P client (peripheral device) by verifying the client's device identification bound to its public key (see Phillips para 0035; see Phillips para 0032) and to secure the P2P channel with the resulting common secret key, so that the secure link is established on the basis of device-specific information, as recited in the instant claims, by applying the identity-bound pairing protocol of Phillips to the existing secure-channel establishment of Davidson. As Phillips itself states: "As a by-product of the authentication procedure, the host device 20 and peripheral device 10 generate a common secret key, that is used to secure all subsequent message interchanges between them" (see Phillips para 0037), which addresses the well-recognized problem of ensuring that devices communicate only with peers the user designates as trusted (see Phillips para 0003). One of ordinary skill in the art in short-range wireless networking would have recognized that Davidson calls for a secure channel between the group owner and its clients but does not detail how a peer's identity is authenticated before the channel is secured, and that Phillips's protocol, which expressly applies to IEEE 802.11 wireless protocols (see Phillips para 0017), was a known, predictable solution to exactly that gap, requiring no change to the underlying Wi-fi Direct group formation, MAC-address-based data link layer communications, or ASP session handling of Davidson. The combination is further supported by MPEP 2141 Rationale A (combining prior art elements according to known methods to yield predictable results) and Rationale C (use of a known technique to improve similar devices in the same way). The motivation to combine these references applies to all claims under this heading.
Barrett (US 2016/0057055) is relied upon to teach using a modified protocol stack (reads on ''The protocol stack 240 includes the IEEE 802.11 PHY layer 212 and an IEEE 802.11 MAC layer 242 to facilitate WLAN communications. The protocol stack 240 further includes a modified IEEE 802.2 LLC layer 244", see Barrett para 0052. Barrett calls the entire stack containing modified LLC 244 "protocol stack 240"; in the combination the transmissions of Davidson pass through that stack.) that includes a modified data link control layer (reads on "According to a second aspect, a modified IEEE 802.2 LLC layer is positioned between the IEEE 802.11 MAC layer and the RLC layer", see Barrett para 0051; "In the second variant, the Protocol Type field is repurposed to indicate to which RLC entity the traffic belongs", see Barrett para 0068; "a component implementing the modified IEEE 802.2. LLC layer 244 generates the SNAP PDU that includes a new our value assigned by the IEEE Registration Authority for 3GPP use", see Barrett para 0069. Barrett expressly calls the layer a "modified IEEE 802.2 LLC layer" and shows the non-standard aspect: the SNAP Protocol Type field, conventionally used to distinguish higher-layer protocols ("Conventionally, the Protocol Type field is used to distinguish between different higher-layer protocols from the organization identified in the OUI field", see Barrett para 0067), is "repurposed" to identify a radio-bearer context; the channel-selector semantics, not obtaining a new registered OUI by itself, supplies the nonstandard modification. In the combination the field selects an ASP service-session context rather than only identifying ASP as a higher-layer protocol. The combined LLC implements the proposed session-selector semantics instead of treating ordinary ASP OUI use alone as a modification; Davidson supplies the baseline LLC envelope ("LLC header 404 may further include a destination service access point (DSAP) field having value 0xAA, a source service access point (SSAP) header having value 0xAA, and a UI or control byte having value 0x03", see Davidson para 0046).) and an unmodified media access layer (reads on "The protocol stack 250 includes the modified IEEE 802.2 LLC layer 244 above the IEEE 802.11 MAC layer 242", see Barrett para 0055; "The protocol stack 240 includes the IEEE 802.11 PHY layer 212 and an IEEE 802.11 MAC layer 242 to facilitate WLAN communications. The protocol stack 240 further includes a modified IEEE 802.2 LLC layer 244", see Barrett para 0052. In the same sentence, Barrett qualifies only the LLC as "modified" and places it above the plain "IEEE 802.11 MAC layer 242"; by contrast, its first aspect expressly modifies the MAC ("The protocol stack 200 includes an IEEE 802.11 PHY layer 212 and a modified IEEE 802.11 MAC layer 214 to facilitate WLAN communications", see Barrett para 0033). All repurposing and inspection in the second aspect is done by LLC 244 ("the component implementing the modified IEEE 802.2 LLC layer 244 in the receiver apparatus inspects the values in the DSAP and SSAP fields of the IEEE 802.2 LLC header", see Barrett para 0063), so MAC 242 performs standard IEEE 802.11 operation. Davidson supplies the standard MAC header and frame check sequence that this layer produces ("FIG. 4 includes a packet 400, which includes an IEEE 802.11 MAC header 402, a logical link control (LLC) header 404, a subnetwork access protocol (SNAP) header 406, protocol data 408, and a frame check sequence (FCS) 410", see Davidson para 0045; "The data link layer connection may support transmission of packets in accordance with the IEEE 802.llx wireless data link layer standards", see Davidson para 0034).)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the IP-less Wi-Fi Direct ASP transport of Davidson by integrating the second-aspect modified LLC of Barrett above the standard IEEE 802.11 MAC (see Barrett para 0055: "The protocol stack 250 includes the modified IEEE 802.2 LLC layer 244 above the IEEE 802.11 MAC layer 242") to realize the instant limitations. KSR International Co. v. Teleflex Inc., 550 U.S. 398 (2007), and MPEP 2141 Rationales A and C support combining known elements and applying a known technique to similar devices. Accordingly, the combination repurposes an LLC/SNAP field to select a particular ASP service-session channel, rather than merely identifying ASP as a higher-layer protocol: peer-agreed selector values designate the session context to which the receiving modified LLC delivers the[AltContent: ] payload; Davidson supplies the existing ASP session creation and management (see Davidson para 0022-0023, para 0038), while Barrett supplies channel-specific field encoding and receiver-side dispatch (see Barrett para 0068, para 0070). As Barrett itself states: "In the second variant, the Protocol Type field is repurposed to indicate to which RLC entity the traffic belongs" (see Barrett para 0068), which provides the channel-demultiplexing technique for traffic that otherwise cannot be distinguished by conventional protocol identification alone (see Barrett para 0016, para 0067). One of ordinary skill in data-link protocol design would have recognized that the service-session channels already created by Davidson can be selected at the LLC in the same way that Barrett selects radio-bearer contexts, with the selector agreed during the existing ASP provisioning exchange instead of LTE RRC signaling; this is the proposed adaptation, not a disclosure that Davidson already has nonstandard LLC semantics. The combination is supported by Rationale A, known field encoding and dispatch yielding predictable per-session delivery, and Rationale C, applying the same channel-selection technique to an IP-less service link. Motivation arises from moving service-session demultiplexing to the existing LLC/SNAP boundary while retaining Davidson's secure peer relationship and standard MAC framing, addressing, FCS, and retransmission; only the second-aspect LLC technique is transferred, not LTE/RLC protocols or any MAC-forwarding architecture, and this rationale applies to this claim.
Per claim 6, the prior art of record further suggests wherein the secure communication link is established without using internet-based routing (reads on "ASP P2P communications allow wireless service advertiser 120 and wireless service seeker 110 to setup a secure communication channel when wireless service advertiser 120 and wireless service seeker 110 come within operative communication range of each other", see Davidson para 0019; "The P2P communications may comprise data link layer-based (e.g. MAC address-based) communications in some examples", see Davidson para 0021; "The ASP session uses data link layer communications based on media access control (MAC) addresses via the WFDS connection, and does not use internet protocol (IP) communications", see Davidson para 0004. The secure channel is set up directly when the devices come within range, through data link layer (MAC address) communications, and the session "does not use internet protocol (IP) communications"; no internet routing is involved in setting up the link).
Claim 7 is analyzed with respect to claim 1. The prior art of record further suggests device-identifying information (reads on "The host device 20 receives the peripheral device identification in step P2 of the process in Figure 3, and then passes to step P3, in which a mutual authentication procedure is performed", see Phillips para 0031; "One possibility is to use certificates issued by a trusted authority that binds these two values together (e.g. X509)", see Phillips para 0034; "As a by-product of the authentication procedure, the host device 20 and peripheral device 10 generate a common secret key, that is used to secure all subsequent message interchanges between them", see Phillips para 0037. Phillips binds the peripheral's identification to its public key by certificate, authenticates the peripheral against it, and derives from that authentication the key securing the link; the secure link is therefore established based on device-identifying information. In the combination the group owner of Davidson performs this authentication of the client.); configuring a transmission protocol (reads on "if the value of the coordination protocol transport bitmask in the ASP Provision Discovery Response is equal to 0x02, wireless service advertiser 120 and wireless service seeker 110 may communicate directly over a data link layer based on the MAC addresses of wireless service advertiser 120 and wireless service seeker 110, i.e. without using IP communications", see Davidson para 0041; "wireless service advertiser 120 may transmit an ASP message that includes an attribute that indicates the ASP session uses data link layer communications based on MAC addresses, and receive an ASP message that includes the attribute indicating the ASP session uses data link layer communications based on MAC addresses", see Davidson para 0051. The coordination protocol transport bitmask value 0x02, exchanged in ASP messages, selects direct data link layer transport for the session; that exchange configures the transmission protocol.) comprising a modified data link control layer (reads on "According to a second aspect, a modified IEEE 802.2 LLC layer is positioned between the IEEE 802.11 MAC layer and the RLC layer", see Barrett para 0051; "the LLC SAP fields of an IEEE 802.2 LLC header are repurposed to indicate to which RLC entity the traffic belongs", see Barrett para 0061; "In the second variant, the Protocol Type field is repurposed to indicate to which RLC entity the traffic belongs", see Barrett para 0068. Barrett names the layer "modified IEEE 802.2 LLC layer" and identifies the non-standard aspect: the LLC SAP fields and SNAP Protocol Type field are "repurposed". In the combination this is the LLC through which Davidson transmits ("LLC header 404 may further include a destination service access point (DSAP) field having value 0xAA, a source service access point (SSAP) header having value 0xAA, and a UI or control byte having value 0x03", see Davidson para 0046).) and an unmodified media access control layer (reads on "The protocol stack 250 includes the modified IEEE 802.2 LLC layer 244 above the IEEE 802.11 MAC layer 242", see Barrett para 0055; "The WLAN station 42 may implement a typical WLAN protocol stack that includes the IEEE 802.11 MAC/PHY layers under an IEEE 802.2 Logical Link Control (LLC) layer", see Barrett para 0016. Barrett places the modified LLC above the IEEE 802.11 MAC layer 242 of the ordinary WLAN stack and reserves the label "modified" for the LLC (in contrast to modified MAC layer 214 of its first aspect, "The protocol stack 200 includes an IEEE 802.11 PHY layer 212 and a modified IEEE 802.11 MAC layer 214 to facilitate WLAN communications", see Barrett para 0033). Davidson transmits standard IEEE 802.11 MAC headers and FCS ("FIG. 4 includes a packet 400, which includes an IEEE 802.11 MAC header 402, a logical link control (LLC) header 404, a subnetwork access protocol (SNAP) header 406, protocol data 408, and a frame check sequence (FCS) 410", see Davidson para 0045).); and transmitting data over the wireless link in a predetermined format (reads on "Wireless service seeker 110 and wireless service advertiser 120 may transmit packets that have the format of FIG. 4 to perform ASP communications based on MAC addresses, and without using IP communications", see Davidson para 0045; "FIG. 4 includes a packet 400, which includes an IEEE 802.11 MAC header 402, a logical link control (LLC) header 404, a subnetwork access protocol (SNAP) header 406, protocol data 408, and a frame check sequence (FCS) 410", see Davidson para 0045. The devices transmit packets "that have the format of FIG. 4" (MAC header, LLC header, SNAP header, protocol data, FCS), a format fixed in advance for both ends).
Per claim 9, the prior art of record further suggests receiving data at the central communication device from the peripheral communication device (reads on "wireless service advertiser 120 may transmit an ASP message that includes an attribute that indicates the ASP session uses data link layer communications based on MAC addresses, and receive an ASP message that includes the attribute indicating the ASP session uses data link layer communications based on MAC addresses", see Davidson para 0051; "wireless service advertiser 120 may comprise a WFD group owner (GO), and wireless service seeker 110 may comprise a WFD client", see Davidson para 0052. The advertiser, which may be the group owner (central device), both transmits and receives ASP messages exchanged with the seeker/client, which is receiving data at the central device from the peripheral).
Per claim 10, the prior art of record further suggests wherein configuring the transmission protocol comprises bypassing or eliminating one or more layer[AltContent: ] of an Open Systems Interconnection (OSI) protocol (reads on "Data link layer communications (also referred to as "link layer communications") comprise a layer of the open systems interconnection (OSI) model", see Davidson para 0024; "Some communication protocols, such as internet protocol (IP) for example, may utilize additional addresses at the so-called \\network layer" to identify computing devices", see Davidson para 0026; "if the value of the coordination protocol transport bitmask in the ASP Provision Discovery Response is equal to 0x02, wireless service advertiser 120 and wireless service seeker 110 may communicate directly over a data link layer based on the MAC addresses of wireless service advertiser 120 and wireless service seeker 110, i.e. without using IP communications", see Davidson para 0041. Davidson places its transport in the OSI data link layer, identifies IP with the OSI network layer, and configures the session to communicate directly over the data link layer without IP; the network layer (OSI layer 3) is therefore bypassed).
Per claim 12, the prior art of record further suggests that transmitting the data does not require routing over a wide-area network (reads on "may communicate by sending packets that include source and destination MAC addresses that identify wireless adapters of wireless service advertiser 120 and wireless service seeker 110, and that do not use IP communications", see Davidson para 0034; "Some communication protocols, such as internet protocol (IP) for example, may utilize additional addresses at the so-called "network layer" to identify computing devices", see Davidson para 0026. Packets are addressed only by source and destination MAC addresses and do not use IP, the network-layer addressing that routing relies on; delivery is therefore within the local link and does not require WAN routing).
Per claim 13, the prior art of record further suggests wherein the secure wireless link is established without using internet-based routing (reads on "ASP P2P communications allow wireless service advertiser 120 and wireless service seeker 110 to setup a secure communication channel when wireless service advertiser 120 and wireless service seeker 110 come within operative communication range of each other", see Davidson para 0019; "The P2P communications may comprise data link layer-based (e.g. MAC address-based) communications in some examples", see Davidson para 0021; "The ASP session uses data link layer communications based on media access control (MAC) addresses via the WFDS connection, and does not use internet protocol (IP) communications", see Davidson para 0004. The secure channel is set up directly between devices within range, by MAC-address-based communications, and the session does not use IP; no internet routing is used to establish the link).
Per claim 17, the non-transitory computer-readable medium (reads on "a non-transitory computer-readable storage medium includes instructions stored thereon that, when executed, cause at least one processor of a first wireless computing device to establish a Wi-Fi Direct Services (WFDS) connection to a second wireless computing device via a wireless communication channel", see Davidson para 0006. Davidson recites the same medium form with instructions executed by a processor to set up the WFDS connection and session.) is analyzed with respect to claim 7
Per claim 20, the prior art of record further suggests wherein communicating the data comprises local transmission (reads on "ASP P2P communications allow wireless service advertiser 120 and wireless service seeker 110 to setup a secure communication channel when wireless service advertiser 120 and wireless service seeker 110 come within operative communication range of each other", see Davidson para 0019. The channel is formed when the devices are within operative range of each other, i.e., local transmission.) among recognized devices (reads on "the first and second devices 10, 20 check in their respective paired device databases 15, 25 whether they are in fact already paired with the respective other device", see Phillips para 0038. In the combination, the paired-device database check of Phillips makes the communicating devices recognized devices; recognition comes from that check, not merely from reading an address.) without requiring Internet connectivity (reads on "Wireless service seeker 110 and wireless service advertiser 120 may transmit packets that have the format of FIG. 4 to perform ASP communications based on MAC addresses, and without using IP communications", see Davidson para 0045. ASP communications are performed "without using IP communications", so no Internet connectivity is required).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Davidson in view of Phillips in view of Barrett in view of Meandzija (US 2005/0086468).
Per claim 5, the prior art of record suggests the system of claim 1. The prior art of record is silent on explicitly stating the device-specific information comprises at least one identifier selected from the group consisting of: a hardware address; a network address.
Meandzija (US 2005/0086468) is relied upon to teach the device-specific information comprises at least one identifier selected from the group consisting of: a hardware address (reads on "the CA signature assures that this UT public key is assigned to a UT having the identifier, e.g., MAC address, also included in the UT certificate", see Meandzija para 0041; "the hardware of a UT 108 is uniquely identified by its Ethernet address, or its hardware identity according to some other global addressing system", see Meandzija para 0049. Meandzija binds the terminal's MAC address to its public key in the certificate and describes the hardware as "uniquely identified by its Ethernet address"; in the combination the identification authenticated under Phillips ("One possibility is to use certificates issued by a trusted authority that binds these two values together (e.g. X509)", see Phillips para 0034) is therefore a hardware address.); a network address (reads on "MAC addresses are a type of network address", see Davidson para 0024; "may identify a second, different wireless computing device based on the data link layer MAC address of the second wireless computing device", see Davidson para 0025. The same MAC address is, per Davidson, "a type of network address" and is how its devices identify one another, so the bound identifier is also a network address).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the identity-bound authentication of Davidson as modified by Phillips, in which the peripheral's device identification is bound to its public key by a certificate issued by a trusted authority (see Phillips para 0034), by integrating the hardware-address certificate binding of Meandzija, in which the identifier that the certificate binds to a wireless terminal's public key is the terminal's MAC address (see Meandzija para 0041: "the CA signature assures that this UT public key is assigned to a UT having the identifier, e.g., MAC address, also included in the UT certificate") to realize the instant limitations. One or more of the underpinning rationale(s), as discussed in KSR, also see MPEP 2141 {A, B, G}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have used, as the device identification that Phillips binds to the P2P client's public key, the client's MAC address, which is the very identifier by which the devices of Davidson already identify one another (see Davidson para 0025) and which Davidson describes as a manufacturer-assigned hardware value and as a network address (see Davidson para 0024), as recited in the instant claims, by applying the MAC-address certificate binding of Meandzija to the existing identity-bound pairing of the Davidson/Phillips combination. As Meandzija itself states: "a hardware authentication can verify that a terminal claiming to have a certain MAC address really has the claimed MAC address" (see Meandzija para 0004), which addresses the well-recognized problem of unauthorized terminals using a wireless network and intercepting legitimate traffic (see Meandzija para 0004). One of ordinary skill in the art in wireless device authentication would have recognized that Phillips leaves open which identifier is bound to the public key (a printed serial number in one embodiment, para 0035), and that binding the MAC address, as Meandzija does, was a known, predictable choice that makes the authenticated identity the same identity used to address the peer at the data link layer, requiring no change to the challenge-response and key generation of Phillips or to the MAC-address-based communications of Davidson. The combination is further supported by MPEP 2141 Rationale A (combining prior art elements according to known methods to yield predictable results) and Rationale B (simple substitution of one known device identifier, a MAC address, for another, a serial number, to obtain predictable results). The motivation to combine these references applies to all claims under this heading.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Davidson in view of Phillips in view of Barrett in view of Nordic (Nordic Semiconductor ASA, Nordic 2.4GHz Wireless Audio Streamer, Preliminary Product Specification, Rev. 3.1 (June 2006; saved Wayback copy dated Oct. 2, 2006)).
Per claim 2, the prior art of record is silent on explicitly stating the data transmitted from the central device to the one or more peripheral devices is in a predefined format comprising Inter-IC Sound (I2S).
Nordic (Nordic Semiconductor ASA, Nordic 2.4GHz Wireless Audio Streamer, Preliminary Product Specification, Rev. 3.1 (June 2006; saved Wayback copy dated Oct. 2, 2006)) is relied upon to teach the data transmitted from the central device to the one or more peripheral devices is in a predefined format comprising Inter-IC Sound (I2S) (reads on "In this system a DSP or micro controller feeds data from a storage device to an nRF24Z1 using standard audio format (I2S). An nRF24Z1 pair transfers audio data from the source and presents it to a stereo DAC on the receiving side", see Nordic, p. 9, §4; "For seamless input from audio sources physically close to nRF24Z1, I2S is the preferred interface", see Nordic, p. 16, §4.4.1; "Audio output to devices physically close to nRF24Z1 (typically a stereo DAC) are normally driven by the I2S output (pins CLK, DATA and WS)", see Nordic, p. 19, §4.5.1. nRF24Z1 receives the audio at the transmitter over I2S, sends it over the wireless link in packets ("The stereo samples are in turn organized in data packets consisting of 16 stereo samples", see Nordic, p. 12, §4.2.2), and drives the receiving DAC through the I2S output; that is the I2S -in/ I2S -out arrangement of the binding construction. In the combination the I2S audio is carried in the secured data link layer frames of Davidson).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the data link layer transport of the prior art of record by integrating the digital-audio endpoint interfaces of Nordic, in which the transmitting unit receives audio from the source in I2S format, carries it over a wireless link in packets, and presents it in I2S format to the receiving-side DAC (see Nordic, p. 9, §4: "In this system a DSP or micro controller feeds data from a storage device to an nRF24Z1 using standard audio format (I2S). An nRF24Z1 pair transfers audio data from the source and presents it to a stereo DAC on the receiving side") to realize the instant limitations. One or more of the underpinning rationale(s), as discussed in KSR, also see MPEP 2141 {A, D}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have provided the group owner of Davidson with an I2S input for audio from a local source and the P2P client with an I2S output to its DAC, carrying the audio samples between them in the secured data link layer frames of the combination, as recited in the instant claims, by applying the I2S -in/ I2S -out wireless audio streaming arrangement of Nordic to the existing secured IEEE 802.11 data link of the combination. As Nordic itself states: "For seamless input from audio sources physically close to Nordic, I2S is the preferred interface" (see Nordic, p. 16, §4.4.1), which addresses the well-recognized problem of interfacing locally connected digital audio sources and DACs to a wireless audio link. One of ordinary skill in the art in wireless audio streaming would have recognized that Davidson is a general-purpose data link layer transport that does not specify the source or sink format of the data, and that Nordic's standard I2S endpoint interfaces were a known, predictable solution to exactly that gap; only the endpoint audio interfaces are taken from Nordic, not its proprietary radio, requiring no change to the underlying IEEE 802.11 framing, modified LLC, or identity-bound secure link of the combination. The combination is further supported by MPEP 2141 Rationale A (combining prior art elements according to known methods to yield predictable results) and Rationale D (applying a known technique to a known device ready for improvement to yield predictable results). The motivation to combine these references applies to all claims under this heading.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Davidson in view of Phillips in view of Barrett in view of Bhalla.
Per claim 3, the prior art of record is silent on explicitly stating wherein the data transmitted from the central device to the one or more peripheral devices comprises video data.
Bhalla (US 2018/0091576) is relied upon to teach wherein the data transmitted from the central device to the one or more peripheral devices comprises video data (reads on "The stream includes a MAC header 400, an RTP header 401, and a payload portion 403 that comprises a plurality of packetized video and audio data", see Bhalla para 0053; "Thus, in the illustrated embodiment, the audio/video payload interfaces directly with the MAC layer 313 and the IP layer is not present", see Bhalla para 0042. Bhalla transmits a payload of "packetized video and audio data" directly over the Wi-Fi MAC without an IP layer; in the combination that video payload is sent from the group owner over the secure link of Davidson).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the data link layer transport of the prior art of record by integrating the video payload technique of Bhalla, in which packetized video and audio data are carried in Wi-Fi MAC frames without an IP layer (see Bhalla para 0053: "The stream includes a MAC header 400, an RTP header 401, and a payload portion 403 that comprises a plurality of packetized video and audio data") to realize the instant limitations. One or more of the underpinning rationale(s), as discussed in KSR, also see MPEP 2141 {A, D}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have transmitted packetized video data from the group owner of Davidson to its P2P clients over the secured, IP-less data link layer path of the combination, as recited in the instant claims, by applying the MAC-direct video payload technique of Bhalla to the existing secured data link layer transport of the combination. As Bhalla itself states: "Thus, in the illustrated embodiment, the audio/video payload interfaces directly with the MAC layer 313 and the IP layer is not present" (see Bhalla para 0042), which addresses the well-recognized bandwidth inefficiency of IP-based streaming within a confined space (see Bhalla para 0003). One of ordinary skill in the art in local wireless media distribution, would have recognized that Davidson provides an IP-less data link layer transport without identifying video as a payload, and that Bhalla's carriage of packetized video directly over the MAC was a known, predictable use of exactly such a transport; only the video payload technique is taken from Bhalla, not its connectionless set-up, requiring no change to the underlying secure link, modified LLC, or unmodified MAC of the combination. The combination is further supported by MPEP 2141 Rationale A (combining prior art elements according to known methods to yield predictable results) and Rationale D (applying a known technique to a known device ready for improvement to yield predictable results). The motivation to combine these references applies to all claims under this heading.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Davidson in view of Phillips in view of Barrett in view of Gutierrez-Aguila (J. R. Gutierrez-Agullo, 8. Coll-Perales, and J. Gozalvez, "An IEEE 802.11 MAC Software Defined Radio Implementation for Experimental Wireless Communications and Networking Research," 2010 IFIP Wireless Days, Venice, Italy, Oct. 20-22, 2010 (IEEE Xplore, added Dec. 3, 2010, DOI 10.1109/WD.2010.5657724))
Per claim 4, the prior art of record does not explicitly state wherein the central device and the peripheral device are configurable software-defined radio (SOR) units.
Gutierrez-Aguila (J. R. Gutierrez-Agullo, 8. Coll-Perales, and J. Gozalvez, "An IEEE 802.11 MAC Software Defined Radio Implementation for Experimental Wireless Communications and Networking Research," 2010 IFIP Wireless Days, Venice, Italy, Oct. 20-22, 2010 (IEEE Xplore, added Dec. 3, 2010, DOI 10.1109/WD.2010.5657724)) is relied upon to teach wherein the central device and the peripheral device are configurable software-defined radio (SDR) units (reads on "IEEE 802.11 MAC that can be used, configured and fully modified, to develop advanced cross-layer communications and networking techniques", see Gutierrez-Aguila, Abstract; "this section compares the sequence of messages exchanged between two commercial wireless cards, and the messages handshake between two USRP2s configured with the implemented SDR MAC", see Gutierrez-Agullo, §IV.B. Gutierrez-Aguila implements the IEEE 802.11 MAC as a configurable SDR and runs it on two USRP2s, i.e., both endpoints of the link are configurable SDR units; it confirms that the SDR MAC generates the same packets as commercial cards ("implemented MAC generates the same packets as the commercial cards", see Gutierrez-Aguila, §IV.B), so selecting standard MAC behavior is consistent with the unmodified MAC of the combination).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the group owner and P2P client of the prior art of record by integrating the software-defined radio implementation of Gutierrez-Agullo, in which both endpoints of an IEEE 802.11 link are USRP2 software-defined radios running a configurable IEEE 802.11 MAC (see Gutierrez-Agullo, §IV.B: "this section compares the sequence of messages exchanged between two commercial wireless cards, and the messages handshake between two USRP2s configured with the implemented SDR MAC') to realize the instant limitations. One or more of the underpinning rationale(s), as discussed in KSR, also see MPEP 2141 {A, B}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have implemented the central and peripheral devices of the combination as configurable SDR units of the kind taught by Gutierrez-Agullo, configured to generate the standard IEEE 802.11 frames that the combination's unmodified MAC requires, as recited in the instant claims, by applying the SDR platform of Gutierrez-Agullo to the existing IEEE 802.11 endpoints of the combination. As Gutierrez-Agullo itself states: "IEEE 802.11 MAC that can be used, configured and fully modified, to develop advanced cross-layer communications and networking techniques" (see Gutierrez-Agullo, Abstract), which addresses the well-recognized lack of flexibility of commercial fixed-function wireless hardware ( see Gutierrez-Aguila, Abstract). One of ordinary skill in the art in wireless protocol implementation would have recognized that the combination requires a non-standard LLC above a standard MAC, which commercial fixed-function cards make hard to customize, and that Gutierrez-Agullo's SDR implementation, shown to reproduce standard behavior (see Gutierrez-Agullo, §IV.B), was a known, predictable platform for exactly that need, requiring no change to the standard MAC operation relied on in the combination. The combination is further supported by MPEP 2141 Rationale A (combining prior art elements according to known methods to yield predictable results) and Rationale B (simple substitution of one known radio platform for another to obtain predictable results). The motivation to combine these references applies to all claims under this heading.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Davidson in view of Phillips in view of Barrett in view of Ikemoto (US 2006/0143716)
Per claim 8, the prior art of record does not explicitly state wherein establishing the secure wireless link comprises comparing a plurality of device identifiers with authorized identifiers stored at the central communication device.
Ikemoto (US 2006/0143716) is relied upon to teach establishing the secure wireless link comprises comparing a plurality of device identifiers with authorized identifiers (reads on "The vendor ID, product ID and serial number of the target are collated with those of the permitted devices 1 through n registered in the connection permission list", see Ikemoto para 0070. Ikemoto collates three identifiers of the connecting device (vendor ID, product ID, serial number) against registered permitted devices.) stored at the central communication device (reads on "The connection device restriction device 1 includes a list memory 1b for storing a connection permission list 1a defining connection-permitted devices", see Ikemoto para 0032. The permission list is held in list memory 1b of the host-side restriction device; in the combination it is held at the group owner that performs the Phillips authentication).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the identity-bound authorization performed by the group owner of Davidson as modified by Barrett and Phillips by integrating the connection-permission policy of Ikemoto, in which the host stores a permission list and collates a connecting peripheral's vendor ID, product ID, and serial number against it before permitting use (see Ikemoto para 0070: "The vendor ID, product ID and serial number of the target are collated with those of the permitted devices 1 through n registered in the connection permission list") to realize the instant limitations. One or more of the underpinning rationale(s), as discussed in KSR, also see MPEP 2141 {A, C}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have stored a list of authorized device identifiers at the group owner of the combination and to have admitted a P2P client only when two or more of its identifiers match the list, as recited in the instant claims, by applying the permission-list software policy of Ikemoto to the existing host-side authorization step of the combination. As Ikemoto itself states, its object is "thereby preventing the use of uncalled-for connection devices and enhancing security" (see Ikemoto para 0015), which addresses the well-recognized problem of controlling which peripheral devices may connect to and be used with a host. One of ordinary skill in the art in device admission control would have recognized that Phillips authenticates a peripheral's identity but does not restrict admission to a configured set of permitted devices, and that Ikemoto's identifier collation was a known, predictable admission policy for exactly that gap; only the permission-list policy is moved to the wireless host, not Ikemoto's USB ports or descriptors, requiring no change to the secure link, modified LLC, or unmodified MAC of the combination. The combination is further supported by MPEP 2141 Rationale A (combining prior art elements according to known methods to yield predictable results) and Rationale C (use of a known technique to improve similar devices in the same way). Ikemoto is analogous art. Although its embodiment uses USB ports, it is reasonably pertinent to the particular problem with which the inventor was concerned, namely selecting which peripheral devices are allowed to join and communicate with a central device (see Spec para 0070); Ikemoto addresses that problem (see Ikemoto para 0015; see Ikemoto para 0032) and expressly is not limited to one connection type (see Ikemoto para 0075). The motivation to combine these references applies to all claims under this heading.
Per claim 18, the prior art of record further suggests authorizing the peripheral device based on at least two device identifiers (reads on "the vendor ID and the product ID are collated if the strength level is "2", see Ikemoto para 0070; "If the target is found to be a permitted device, the process proceeds to Step S18", see Ikemoto para 0070. At strength level 2 both vendor ID and product ID are collated, and the device is permitted only if found in the list, which is authorization based on two identifiers).
Claims 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Davidson in view of Phillips in view of Barrett in view of AES TD1003 (AES Technical Committee on Network Audio Systems, "AES White Paper: Best Practices in Network Audio," AESTD1003V1 (June 4, 2009), J. Audio Eng. Soc., Vol. 57, No. 9, pp. 729-741 (Sept. 2009) (archived at web.archive.org Nov. 23, 2009))
Per claim 11, the prior art of record does not explicitly state layers 3-7 of the OSI protocol are eliminated or bypassed.
AES TD1003 (AES Technical Committee on Network Audio Systems, "AES White Paper: Best Practices in Network Audio," AESTD1003V1 (June 4, 2009), J. Audio Eng. Soc., Vol. 57, No. 9, pp. 729-741 (Sept. 2009) (archived at web.archive.org Nov. 23, 2009)) is relied upon to teach layers 3-7 of the OSI protocol are eliminated or bypassed (reads on "Many popular professional Ethernet-based audio networks only use the Physical and Data Link Layers (layers one and two) of the model", see AES TD1003, p. 730, §2.1; "For uncompressed audio transmission, the IEEE 802.11 WLAN specification represents one of the most promising networking formats", see AES TD1003, p. 733, §2.7. AES TD1003 describes Ethernet audio networks that use only OSI layers one and two, i.e., layers 3-7 are not used for the audio, and identifies IEEE 802.11 as a promising format for uncompressed audio. In the combination the audio is the protocol data placed directly after the LLC/SNAP header of the IP-less data link layer frame of Davidson ("Wireless service seeker 110 and wireless service advertiser 120 may transmit packets that have the format of FIG. 4 to perform ASP communications based on MAC addresses, and without using IP communications", see Davidson para 0045), so layers 3-7 are bypassed on the data path, while ASP retains session setup, management, and teardown for control traffic (see Davidson para 0022-0023). The bypass is the proposed direct sample-data path, not an inherent property of the ASP session).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the IP-less data link layer transport of the prior art of record by integrating the layer-two-only audio transport of AES TD1003, in which audio networks carry audio using only the physical and data link layers (see AES TD1003, p. 730, §2.1: "Many popular professional Ethernet-based audio networks only use the Physical and Data Link Layers (layers one and two) of the model") to realize the instant limitations. One or more of the underpinning rationale(s), as discussed in KSR, also see MPEP 2141 {A, C, G}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have carried the audio data of the combination as the protocol data of the IEEE 802.11 data link layer frame directly after the (modified) LLC/SNAP header, with no network, transport, session, presentation, or application layer headers or processing on the data path, while the ASP messages of Davidson continue to set up the session as control traffic that is itself carried directly in data link layer frames (see Davidson para 0045), as recited in the instant claims, by applying the layer-two-only audio transport of AES TD1003 to the existing IP-less data link layer path of the combination. AES TD1003 §2.1 concerns Ethernet audio; §2.7 recommends WLAN for audio but does not state that IEEE 802.11 implements the §2.1 two-layer arrangement. The ground therefore relies on adapting the demonstrated two-layer audio data path, not on a direct wireless disclosure. Davidson para 0022-0023 retains an ASP session service, and placing its primitives in MAC frames does not eliminate that service. In the proposed combination, ASP provisioning/authentication remains control-plane processing; a distinct sample-data path passes source samples directly to the modified LLC and receives them directly from that LLC at the sink, without invoking ASP service, session, presentation, transport, or network processing for those samples. AES supplies the two-layer audio technique, Davidson supplies the secured local MAC link, and Barrett supplies LLC session-channel dispatch. The expected result is the same payload transmission with fewer per-sample protocol-processing stages, not elimination of every higher-layer function everywhere in the device. As AES TD1003 itself states: "For uncompressed audio transmission, the IEEE 802.11 WLAN specification represents one of the most promising networking formats" (see AES TD1003, p. 733, §2.7), which establishes relevance to wireless audio; the separate low-latency motivation is the AES discussion of latency as a key network-audio attribute (see AES TD1003, p. 730, §1.2). One of ordinary skill in the art in networked audio would have recognized that Davidson already removes the IP network layer from its data link layer transport but does not state that the transported data bypasses all layers above layer two, and that the layer-two-only audio transport described by AES TD1003 was a known, predictable way to minimize per-layer processing for audio, requiring no change to the secure link, the modified LLC, or the unmodified IEEE 802.11 MAC of the combination. The combination is further supported by MPEP 2141 Rationale A (combining prior art elements according to known methods to yield predictable results) and Rationale C (use of a known technique to improve similar devices in the same way). The motivation to combine these references applies to all claims under this heading.
Per claim 19, the prior art of record further suggests wherein the system further bypasses layers 3 through 7 of an Open Systems Interconnection (OSI) protocol (reads on "Many popular professional Ethernet-based audio networks only use the Physical and Data Link Layers (layers one and two) of the model", see AES TD1003, p. 730, §2.1; "For uncompressed audio transmission, the IEEE 802.11 WLAN specification 13 represents one of the most promising networking formats", see AES TD1003, p. 733, §2.7. AES TD1003 teaches audio transport using only layers one and two, in an Ethernet embodiment, and separately identifies IEEE 802.11 as promising for audio. By adapting the Ethernet two-layer sample-data path to the IP-less data link layer frames of Davidson ("if the value of the coordination protocol transport bitmask in the ASP Provision Discovery Response is equal to 0x02, wireless service advertiser 120 and wireless service seeker 110 may communicate directly over a data link layer based on the MAC addresses of wireless service advertiser 120 and wireless service seeker 110, i.e. without using IP communications", see Davidson para 0041), the proposed sample-data path bypasses layers 3 through 7; this is a combination-level implementation inference, not an assertion that an IP-less ASP session inherently bypasses layers 5 through 7).
Claims 14 – 15 are rejected under 35 U.S.C. 103 as being unpatentable over Davidson in view of Phillips in view of Barrett in view of Elliot (US 2019/0130923)
Per claim 14, the prior art of record does not explicitly state configuring the transmission protocol comprises manually or automatically selectively configuring a frame buffer size to control delay or synchronization.
Elliot (US 2019/0130923) is relied upon to teach configuring the transmission protocol comprises manually or automatically selectively configuring a frame buffer size (reads on "A latency negotiation may include agreement as to block sizes, jitter buffer sizes, or other parameters", see Elliot para 0047; "Some examples may provide a user selectable or configurable balance between higher robustness (e.g., fewer skips by providing larger block sizes and larger jitter buffers) and, better synchronization (e.g., lower latency by providing smaller block sizes and smaller jitter buffers)", see Elliot para 0047. Block size (samples per transmitted block) is set automatically by latency negotiation between devices or manually by a user-selectable setting; either alternative meets the claim.) to control delay or synchronization (reads on "Some examples may provide a user selectable or configurable balance between higher robustness (e.g., fewer skips by providing larger block sizes and larger jitter buffers) and better synchronization (e.g., lower latency by providing smaller block sizes and smaller jitter buffers)", see Elliot para 0047; "the received audio samples are re-concentrated into blocks of fewer audio samples to decrease the latency associated with processing and delivery of the audio samples to an audio rendering device", see Elliot para 0040. Smaller blocks are selected for better synchronization and lower latency, and larger blocks for robustness, while received samples are re-concentrated into smaller blocks to reduce latency; the block-size configuration therefore controls delay and synchronization).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the transmission protocol configuration of Davidson as modified by Barrett and Phillips by integrating the configurable audio block sizing of Elliot, in which the number of audio samples assembled into each transmitted block is negotiated between devices or user-selected to trade latency against robustness ( see Elliot para 0047: "Some examples may provide a user selectable or configurable balance between higher robustness (e.g., fewer skips by providing larger block sizes and larger jitter buffers) and better synchronization (e.g., lower latency by providing smaller block sizes and smaller jitter buffers)") to realize the instant limitations. One or more of the underpinning rationale(s), as discussed in KSR, also see MPEP 2141 {A, C, D}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have configured, manually or by negotiation, the number of audio samples carried in each transmission of the combination in order to control delay and synchronization, as recited in the instant claims, by applying the configurable transmitted-block sizing of Elliot to the existing data link layer audio transport of the combination. As Elliot itself states: "It is therefore desirable to process and distribute audio content in a manner with reduced latency and/or reduced jitter" (see Elliot para 0002), which addresses the well-recognized problem of latency and jitter that cause rendered audio to be perceived as unsynchronized with associated video. One of ordinary skill in the art in wireless audio distribution would have recognized that the combination provides a low-overhead link but no mechanism for tuning delay, and that Elliot's block-size configuration was a known, predictable mechanism for exactly that purpose, requiring no change to the secure link, modified LLC, or unmodified MAC of the combination. The combination is further supported by MPEP 2141 Rationale A (combining prior art elements according to known methods to yield predictable results) and Rationale D (applying a known technique to a known device ready for improvement to yield predictable results). The motivation to combine these references applies to all claims under this heading.
Per claim 15, the prior art of record further suggests wherein configuring the frame buffer size comprises configuring one or more of a number of samples sent per transmission (reads on "The SBC blocks are transmitted on the interface 132 once assembled", see Elliot para 0045; "Encoding and block sizes may be selected in part on the basis of number of channels, sampling rate, sample resolution, and/or other factors", see Elliot para 0046. Blocks of a selected number of samples (e.g., 120) are transmitted once assembled, and block sizes are selected; configuring the block size is configuring the number of samples sent per transmission).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Davidson in view of Phillips in view of Barrett in view of Elliot in view of RME (RME, DIGI96/8 PRO User's Guide, Version 1. 9 ( © Matthias Carstens, 5/2002; Wayback capture dated Dec. 31, 2003))
Per claim 16, the prior art of record is relied upon to teach is relied upon to teach wherein the number of bits per sample is configured to be 16 bits or 24 bits (reads on "the audio content may be received as 16-bit samples per channel", see Elliot para 0024. Elliot expressly uses 16-bit samples per channel), and the data rate is configured to be one of 48 kHz (reads on "Common sampling rates include 48,000 samples/sec (48 K)", see Elliot para 0024. Elliot uses a 48,000 samples/sec rate, which is 48 kHz), 96 kHz, or 192 KHz. The prior art of record does not explicitly state the frame buffer size is configured from 500 samples to 5,000 samples.
RME (RME, DIGI96/8 PRO User's Guide, Version 1. 9 ( © Matthias Carstens, 5/2002; Wayback capture dated Dec. 31, 2003)) is relied upon to teach the frame buffer size is configured from 500 samples to 5,000 samples (reads on "4 different buffer sizes are available: 256 (6 ms), 512 (11 ms), 1024 (23 ms), 2048 (46 ms)", see RME, p. 15, §9.4; "The higher the value, the more tracks can be recorded and played back simultaneously, and the longer the system takes to react", see RME, p. 15, §9.4. RME offers 512-, 1024-, and 2048-sample buffers, all within the claimed range, and explains that larger buffers give more stability at the cost of latency. Elliot establishes that samples per transmitted block is a result-effective variable governing latency against underflow robustness ("Blocks containing relatively fewer audio samples may reduce latency but may also increase risk of an underflow occurrence", see Elliot para 0047) and that larger blocks are chosen for robustness ("Some examples may provide a user selectable or configurable balance between higher robustness (e.g., fewer skips by providing larger block sizes and larger jitter buffers) and better synchronization (e.g., lower latency by providing smaller block sizes and smaller jitter buffers)", see Elliot para 0047). RME's DMA/ASIO buffer is not the wireless transmission-block buffer, and no direct range overlap of identical structures is asserted. The claimed variable is established instead by Elliot: the number of samples assembled and sent per block, expressly varied to control latency and underflow. RME supplies known audio-buffer sample-count candidates, not identity of the buffers. Applying the known 512-sample candidate to that adjustable transmitted-block count yields a collection interval of approximately 10.67 ms at the 48 kHz rate of Elliot para 0024; this is a calculation of sample accumulation time, not a claim that total link latency equals 10.67 ms. Because Elliot expressly invites a configurable latency/robustness balance, evaluating the small set of known sample-count candidates against its existing delay and underflow criteria is routine experimentation, with 512 lying within the claimed range. This combination-level selection, rather than a presumed direct RME wireless-buffer disclosure, supports the range under MPEP 2144.05(II)(A)-(B) (In re Aller, 220 F.2d 454 (CCPA 1955); In re Applied Materials, Inc., 692 F.3d 1289 (Fed. Cir. 2012))).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the configurable block sizing of the prior art of record by integrating the audio buffer settings of RME, in which the number of samples transferred per buffer between the audio application and the audio interface is selected from fixed values, including 512 samples at 16-bit resolution and 48 kHz, each with a stated latency (see RME, p. 15, §9.4: "4 different buffer sizes are available: 256 (6 ms), 512 (11 ms), 1024 (23 ms), 2048 (46 ms)") to realize the instant limitations. One or more of the underpinning rationale(s), as discussed in KSR, also see MPEP 2141 {A, D} and MPEP 2144.0S(II), support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have set the samples-per-transmission block size of the combination to a value such as 512 samples, with 16-bit samples at a 48 kHz data rate, when favoring robustness over minimum latency, as recited in the instant claims, by applying the known latency-versus-stability buffer setting of RME to the existing configurable block size of the combination. As RME itself states: "This setting determines the latency (the delay) between the audio application and the DIGI96 series, as well as general system stability" (see RME, p. 15, §9.4), which addresses the well-recognized trade-off between latency and stability in digital audio transfer. One of ordinary skill in the art in digital audio transport would have recognized that Elliot identifies samples per transmitted block as the variable controlling latency and underflow robustness but describes small blocks, and that RME shows a conventional, workable operating point within the claimed range for the same latency-versus-stability variable, requiring no change to the transport of the combination. The combination is further supported by MPEP 2141 Rationale A (combining prior art elements according to known methods to yield predictable results) and Rationale D (applying a known technique to a known device ready for improvement to yield predictable results). The motivation to combine these references applies to all claims under this heading.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is (571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432
