DETAILED ACTION
This office action is in response to claims and remarks filed 12 February 2026.
Claims 1-20 are pending.
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, see remarks filed 12 February 2026, with respect to the rejection(s) of claim(s) 1-20 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “configurable logic element” in claims 1-2, 5, 6-7, and 12.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof, described as an FPGA.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-6 and 16-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1,
In Line 11, there is a lack of antecedent basis for the term “the aggregated data transmission.” For examination purposes, the examiner interprets this as the number of signals transmitted via the communication pathway.
Regarding claim 16,
a. In line 1, the claim fails to particularly point out and distinctly claim what is meant by the term “the native protocol”. Claim 1 recites a “different native protocol relative to another peripheral electronic device.” The claim is not clear on wither the “native protocol” refers to the native protocol of the first peripheral device, the second “another” peripheral device, or some other native protocol of some other device. For examination purposes, the examiner interprets this as either of the first or second native protocols.
Regarding claims 2-6, and 16-20, they comprise limitations that are dependent upon a rejected base claim, and fail to resolve the deficiencies thereof. They are therefore rejected as well.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 4, 6-10, 12-14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over FINNEGAN et al. Pub. No.: US 2019/0132396 A1 (hereafter FINNEGAN), in view of LANGGUTH et al. Pub. No.: US 2021/0329103 A1 (hereafter LANGGUTH).
Regarding claim 1, FINNEGAN teaches invention substantially as claimed, including:
A computing device, comprising:
a…logic element to:
connect to a number of peripheral electronic devices ([0045] A dispatch unit 275 (i.e., “logic element”) may be situated at any convenient location within the home environment within Wi-Fi range of the Internet access point and within BLE range of any smart home peripheral device(s) 281 (i.e., “electronic devices”) desired to be included within the smart home system), at least one peripheral electronic device having a different native protocol relative to another peripheral electronic device ([0046] The dispatch unit, which may perform any processing required to produce from the incoming Wi-Fi communication an outgoing wireless communication 277 via a BLE protocol, which may be received by a smart home peripheral device to which the communication is addressed. A wireless communication 279 originating from a smart home peripheral device 281, which could include a communication produced in response to a communication 277 received by the smart home peripheral device, may be transmitted according to a BLE protocol, received by the dispatch unit, processed to produce an outgoing wireless communication 271 according to a Wi-Fi protocol, which may be received at the wireless Internet access point and relayed back to the cloud server and/or the user control device. [0053] Various wireless communications have been described as communications according to a Wi-Fi protocol or according to a BLE protocol. In embodiments, there may be substituted any other protocols and/or communications modalities operative to enable the indicated communications under whatever constraints may be present in the implementation context of interest. In general, in many embodiments wherein a Wi-Fi protocol or modality is described, there could be substituted any high-performance protocol or modality…Examples of high-performance protocols or modalities could include Wi-Fi, WiMAX, and IEEE 802.11 protocols. Similarly, in many embodiments wherein a BLE protocol or modality is described, there could be substituted any reduced energy protocol. Reduced energy protocols could include…for example, Bluetooth, Bluetooth Low Energy (BLE), Zigbee, Z-wave, Ant, and passive Wi-Fi. [0054]. It may be found useful in a home automation system architecture to employ a device-agnostic messaging architecture for communication to, from, and/or with one or more devices with which the system is desired to interact, and/or between devices. A device-agnostic messaging architecture may include any communication modality and/or protocol employing a message packet whereby the messaging is not device-specific, and/or is operable to communicate to and/or from and/or between two or more devices manufactured by different manufacturers, belonging to different home automation device families, representing different brands, and/or having different functionality…a device-agnostic messaging architecture may be adapted and configured for compatibility with more than one wireless communication protocol (i.e., home automation system supports communication between devices of different manufacturers that support different communication protocols)); and
prepare and package a number of signals to be transmitted across a uniform transmission protocol ([0059] The general status packet is packaged into a communication suitable for transmission 1087 by BLE to a device such as, for example, a dispatch unit 1059 adapted and configured to repackage (i.e., repackaging a packet represents “preparing and packaging” an already packaged signal) and transmit 1085 the general status packet by Wi-Fi whereby the packet 1069 is received by a Wi-Fi enabled wireless access point 105 (i.e., Wi-Fi represents a “uniform transmission protocol”));
a communication pathway to transmit packaged signals to a driver using the uniform transmission protocol; and the driver to: unpack the number of signals from the aggregated data transmission; and represent the number of peripheral electronic devices to an operating system of the computing device ([0059] From the wireless access point the general status packet 1067 is packaged and relayed to a remote server 1055 such as, for example, a cloud server running a smart home management application. After the packaging and optionally performing processing on or in response to the general status packet, the remote server application may optionally issue instructions and/or transmit other data to any devices of the smart home system, and may repackage the general status packet 1065 into a communication suitable for transmission 1081, which may be via Wi-Fi, Bluetooth, a cellular telephone network, or any other operable communication modality, for receipt and decoding or interpretation of the general status packet 1063 by the user's smart phone or other user control device and/or an application running thereon. In some embodiments, once the payload field is encoded by the originating device (here, the smart home light controller peripheral device 1089), the payload field need not be accessed or interpreted or decoded by any of the intermediate devices, but instead may be relayed intact and without change to the ultimate receiving device(s) (in this example, the remote server application 1055, the smart phone application 1053, or both) (i.e., phone screen application 1053 represents an “operating system of the computing device” having drivers that receives and decodes, or “unpacks” representations of the status of smart home devices via a pathway that transmits packaged packets from a smart home peripheral to the smart phone application)).
While FINNEGAN discusses a logic element used to convert between different communication protocols, FINNEGAN does not explicitly teach implementing protocol conversion using:
a configurable logic element
However, in analogous art that similarly discusses protocol conversion, LANGGUTH teaches implementing protocol conversion using:
a configurable logic element ([0096] Analog as well as digital data may be received by the first protocol converter 18 for transmission purposes. In addition, the first protocol converter 18 comprises a first processing module 40 comprising one or more circuits. In an embodiment, the first protocol converter 18 may be established, for example, by a field programmable gate array (FPGA) (i.e., an FPGA represents a programmable logic element used to perform protocol conversion)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined LANGGUTH’s teaching of using an FPGA to convert between protocols, with FINNEGAN’s teaching of converting between different native protocols and a uniform protocol, to realize, with a reasonable expectation of success, a system that converts between different native protocols and a uniform protocol, as in FINNEGAN, using an FPGA, as in LANGGUTH. A person having ordinary skill would have been motivated to make this combination to enable low cost, highly adaptable FPGAs to implement protocol conversion.
Regarding claim 2, FINNEGAN further teaches:
the configurable logic element comprises multiple devices; and each device is to execute a sub-operation of preparing and packaging of the number of signals ([0045] A dispatch unit may include at least a wireless receiver compatible for wireless communication with a home router or wireless internet access point…and an interface for operatively connecting the wireless receiver and the dispatch transmitter. An interface of a dispatch unit may include any device and/or component, implemented in hardware, software, firmware, or any combination thereof, for processing and/or relaying a communication received by the wireless receiver to the dispatch transmitter in a form compatible for transmission by the dispatch transmitter in accordance with the protocol under which the dispatch transmitter is configured to operate (i.e., wireless receiver, interface, and dispatch transmitter comprise “devices” of the dispatch unit representing the configurable logic element, and which perform at least some sub operations involved in the repackaging of the packets received at, and transmitted from the dispatch unit)).
Regarding claim 4, FINNEGAN further teaches:
the peripheral electronic device comprises: a sensor; and a supplemental integrated circuit to execute an operation on a sensor output ([0041] A control or user interface device, such as a smart phone or tablet having the capability to present a suitable user interface and to communicate wirelessly via a suitable protocol such as Bluetooth or Wi-Fi, may be configured to communicate instructions and/or receive data such as, for example, device status information and/or sensor data, directly with other devices of the system, or by relaying instructions and/or data through the dispatch device (i.e., control or user interface devices comprise “supplemental integrated circuitry” that perform display operations on sensor output data)).
Regarding claim 6, FINNEGAN further teaches:
the configurable logic element is to: unpackage an incoming command from the driver; and transmit the incoming command to a corresponding peripheral electronic device ([0046] Communications originating from a user control device may be passed 283 to an Internet cloud device such as a server and/or application running thereon, thence 285 to the wireless Internet access point, then wirelessly communicated 273 via a Wi-Fi protocol to the dispatch unit, which may perform any processing required to produce from the incoming Wi-Fi communication an outgoing wireless communication 277 via a BLE protocol, which may be received by a smart home peripheral device to which the communication is addressed. [0045] in some embodiments, a dispatch unit could be adapted and configured to receive a Wi-Fi communication, and the interface could be adapted and configured to extract a message or data there from and repackage all or part of the message or data in a form suitable for BLE transmission and pass the repackaged communication to the dispatch transmitter for transmission as a BLE communication (i.e., communication from user device drivers are extracted, or unpackaged, and transmitted to the peripheral device)).
Regarding claim 7, it comprises limitations similar to claim 1, and is therefore rejected for similar rationale.
Regarding claim 8, FINNEGAN further teaches:
encapsulating the number of signals in their native protocol within the uniform transmission protocol; and translating the number of signals from their native protocol into the uniform transmission protocol ([0059] The general status packet is packaged into a communication suitable for transmission 1087 by BLE to a device such as, for example, a dispatch unit 1059 adapted and configured to repackage and transmit 1085 the general status packet by Wi-Fi whereby the packet 1069 is received by a Wi-Fi enabled wireless access point 1057 present in the smart home environment. From the wireless access point the general status packet 1067 is packaged and relayed to a remote server 1055 such as, for example, a cloud server running a smart home management application…In some embodiments, once the payload field is encoded by the originating device (here, the smart home light controller peripheral device 1089), the payload field need not be accessed or interpreted or decoded by any of the intermediate devices, but instead may be relayed intact and without change to the ultimate receiving device(s) (in this example, the remote server application 1055, the smart phone application 1053, or both (i.e., signals from peripherals are packaged into a native Bluetooth protocol, and then repackaged, or “encapsulated” without being accessed, interpreted, or decoded into a Wi-Fi protocol for transmission to the wireless access point))).
Regarding claim 9, FINNEGAN further teaches:
receiving an aggregated command transmission; and unpackaging the aggregated command transmission ([0062] A smart home peripheral device 303 may be adapted and configured to continuously broadcast in a connectionless manner, at predetermined intervals, augmented BLE advertising communications in which is encoded information regarding the status and/or conditions relating to the smart home peripheral device and/or the context in which it is deployed. The augmented BLE advertising communications could be received 329 by a smart phone, and decoded (i.e., decoding the communication “unpackages” the received transmission aggregated at the dispatch unit)).
Regarding claim 10, FINNEGAN further teaches:
transmitting configuration information between the configurable logic element and the driver ([0055] FIG. 7 depicts schematically an exemplary embodiment of a general form of control command packet 700 useful for wireless communication to and from various devices of a smart home system. The packet includes two top-level fields as shown: a routing header field 701 and a command payload field 703…The command payload field may contain a message identifier 707, a command identifier 709, and may include command data 711. A message identifier may include and/or encode any information found useful for identifying the message being transmitted. A command identifier may include and/or encode data such as, for example, a binary or hexadecimal string, uniquely identifying the command, function, or operation to which the message pertains. The command data field may contain any data found useful in connection with the command. [0056] A communication of a control command packet originating from a mobile application running on a smart phone and relayed to a smart home wireless camera peripheral device via a communications architecture as disclosed herein (i.e., command data represents “configuration information” transmitted between smart phone driver and peripheral device via dispatch unit)).
Regarding claim 12, FINNEGAN further teaches:
reconfiguring the…logic element responsive to a change to at least one peripheral electronic device ([0061] A smart home peripheral device may be adapted and configured to transmit, and other devices in the system may be adapted and configured to receive, advertising packets, including, for example, augmented BLE advertising packets, whose augmented and/or encoded content may be altered over time to reflect any events, changes in condition, or other information, and in any manner found useful for an application of interest (i.e., as a smart home peripheral changes, the other devices that receive the packets, including the dispatch unit, are adapted/reconfigured to reflect the change in the peripheral)).
(Claims 13-14 are rejected below)
Regarding claim 16, FINNEGAN further teaches:
the native protocol is at least one of an inter-integrated circuit (I2C) protocol, a common programming interface (CPI) protocol, a Wi- Fi protocol, or a Bluetooth protocol ([0053] In many embodiments wherein a BLE protocol or modality is described, there could be substituted any reduced energy protocol. Reduced energy protocols could include…for example, Bluetooth, Bluetooth Low Energy (BLE), Zigbee, Z-wave, Ant, and passive Wi-Fi).
Regarding claim 17, FINNEGAN further teaches:
the driver is an operating system (OS) driver of the computing device ([0059] The payload field need not be accessed or interpreted or decoded by any of the intermediate devices, but instead may be relayed intact and without change to the ultimate receiving device(s) (in this example, the remote server application 1055, the smart phone application 1053, or both (i.e., smart phone application runs on the operating system of a smart phone and communicates via an OS “driver”))).
Regarding claim 18, FINNEGAN further teaches:
the communication pathway is a communication bus of the computing device ([0046] The dispatch unit, which may perform any processing required to produce from the incoming Wi-Fi communication an outgoing wireless communication 277 via a BLE protocol, which may be received by a smart home peripheral device to which the communication is addressed. A wireless communication 279 originating from a smart home peripheral device 281, which could include a communication produced in response to a communication 277 received by the smart home peripheral device, may be transmitted according to a BLE protocol, received by the dispatch unit, processed to produce an outgoing wireless communication 271 according to a Wi-Fi protocol, which may be received at the wireless Internet access point and relayed back to the cloud server and/or the user control device (i.e., dispatch unit acts as a “communication bus” by being part of a shared communication pathway enabling transfer of data between multiple system peripherals and components)).
Regarding claim 19, LANGGUTH further teaches:
the configurable logic element is a field programmable gate array (FPGA) ([0096] Analog as well as digital data may be received by the first protocol converter 18 for transmission purposes. In addition, the first protocol converter 18 comprises a first processing module 40 comprising one or more circuits. In an embodiment, the first protocol converter 18 may be established, for example, by a field programmable gate array (FPGA) (i.e., an FPGA represents a programmable logic element used to perform protocol conversion)).
Regarding claim 20, FINNEGAN further teaches:
the sensor is at least one of a visible spectrum camera, an infrared camera, a thermal imager, a temperature sensor, a motion sensor, an acoustic sensor, a moisture sensor, a gyroscope, or an accelerometer ([0039] Smart home peripheral device, such as, for example, any one or more of a camera 109, switch automation device 107, or other output device, a motion sensor, proximity sensor, intrusion sensor 111, doorbell or other alert device 113, or other input device. [0065] the user controllable fixtures may include any of the many components and/or fixtures commonly found in a home, office, or other environment, such as, for example, light switches, light dimmers, rheostats, electrical receptacles, motor controls, thermostats, heating, cooling, and/or ventilation controls, intrusion, fire and/or other alarm controls, irrigation and/or sprinkler controls, drape, window, and/or shutter controls, door and window locks, and appliance controls).
Regarding claim 13, it comprises limitations similar to claims 1, and 19, and is therefore rejected for similar rationale:
Regarding claim 14, FINNEGAN further teaches:
packaging a signal comprises passing through a signal which has a native protocol to match the uniform transmission protocol ([0050] The smart home peripheral device may perform a function and/or otherwise respond to the communication and thereupon transmit 515 a communication according to a Wi-Fi protocol, which is received 517 by the dispatch unit, optionally processed, and relayed via the Wi-Fi connection 509 with the Internet access point to an ultimate destination such as an application running on a cloud server, and/or a user control device. (i.e., when transmission protocol from the peripheral device is Wi-Fi (matching the protocol of the internet access point), the dispatch unit may not perform processing on the communication and may simply relay it to the internet access point, thereby “passing through” the dispatch unit)).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over FINNEGAN, in view of LANGGUTH, as applied to claim 1, and in further view of MCALISTER et al. Pub. No.: US 2021/0134256 A1 (hereafter MCALISTER).
Regarding claim 3, FINNEGAN further teaches:
the uniform transmission protocol is selected ([0053] In general, in many embodiments wherein a Wi-Fi protocol or modality is described, there could be substituted any high-performance protocol or modality…Examples of high-performance protocols or modalities could include Wi-Fi, WiMAX, and IEEE 802.11 protocols (i.e., communication protocol selected by the dispatch unit is selected from a plurality of different high performance protocol))...
While FINNEGAN discusses selection of a wireless uniform transmission protocol to handle communication of a status packet, FINNEGAN does not explicitly teach that the uniform transmission protocol:
is selected from the group consisting of: a peripheral component interconnect express (PCIe) protocol; and a universal serial bus (USB) protocol.
However, in analogous art that similarly teaches selection of a uniform transmission protocol to enable data transmission, MCALISTER teaches that the uniform transmission protocol:
is selected from the group consisting of: a peripheral component interconnect express (PCIe) protocol; and a universal serial bus (USB) protocol ([0024] In one embodiment of the first aspect, the data transmission interface is selected from a USB interface, a Network interface, a Bluetooth interface, a PCIE interface or a Thunderbolt interface).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have simply substituted MCALISTER’s teaching of selecting a uniform transmission protocol from a list comprising wireless, USB, or PCIE protocols, with the selection of a uniform transmission protocol of FINNEGAN, since 1) FINNEGAN teaches selecting a uniform transmission protocol that differs from the claimed device in that the selection is made from a group of different WI-FI protocols and does not include USB and PCIE protocols, 2) a selection of a uniform transmission protocol from a group of protocols including WI-FI, USB, and PCIE protocols, and 3) one of ordinary skill in the art could have substituted any of the USB, or PCIE protocols, either wireless or with the accompanying requisite physical connection, in MCALISTER for the WI-FI protocols of FINNEGAN, to achieve the predictable result of enabling data communication between FINNEGAN’s dispatch unit and wireless access point via a selected uniform transmission protocol.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over FINNEGAN, in view of LANGGUTH, as applied to claim 1, and in further view of NORE et al. Pub. No.: US 2021/0271307 A1 (hereafter NORE).
Regarding claim 5, FINNEGAN further teaches:
responsive to accessing and processing the configuration information, the configurable logic element is to wake the at least one peripheral electronic device for data transmission ([0049] The Wi-Fi transmitter and/or related circuitry of the smart home peripheral device may be maintained in a default power-off state except when activated by an instruction received via a BLE protocol (i.e., accessing and processing of the BLE protocol received from the dispatch unit causes at least a portion of the peripheral device (the Wi-Fi transmitter) to wake), thereby substantially reducing power consumption, as may be particularly desirable for battery-powered smart home peripheral devices, while maintaining the ability to communicate over the longer ranges and/or higher bandwidth provided by Wi-Fi when such capabilities are needed (i.e., awakening the Wi-Fi transmitter of a peripheral enables the peripheral to perform data transmission over Wi-Fi)).
While FINNEGAN and LANGGUTH discuss waking peripherals in response to configuration information, FINNEGAN and LANGGUTH does not explicitly teach:
the configurable logic element comprises, for at least one peripheral electronic device, at least one proxy register to mirror peripheral electronic device configuration information which is found on a register of the at least one peripheral electronic device; the configurable logic element is to access the peripheral electronic device configuration information from the proxy register while the at least one peripheral electronic device is asleep;
However, in analogous art that similarly discusses waking peripherals, NORE teaches:
the configurable logic element comprises, for at least one peripheral electronic device, at least one proxy register to mirror peripheral electronic device configuration information which is found on a register of the at least one peripheral electronic device; the configurable logic element is to access the peripheral electronic device configuration information from the proxy register while the at least one peripheral electronic device is asleep ([0109] The wake-up logic has access to the SUBSCRIBE registers of each peripheral. By monitoring the traffic on the DPPI matrix 160, the wake-up logic 150 is capable of detecting when an event has been published onto a channel to which a particular sleeping peripheral subscribes. Upon detecting this event, the wake-up logic 150 sends a signal to the power controller 106 to power-up this peripheral. The power controller 106 subsequently wakes up the sleeping peripheral (i.e., logic element accesses registers of peripheral devices while they sleep to determine whether to wake them up)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined NORE’s teaching of reading a register to determine whether to wake a peripheral, with FINNEGAN and LANGGUTH’s teaching of waking peripherals, to realize, with a reasonable expectation of success, a system that wakes peripherals, as in FINNEGAN and LANGGUTH, based on reading a register to determine whether to wake a peripheral, as in NORE. A person having ordinary skill would have been motivated to make this combination to improve logic that determines when to wake peripherals thereby resulting in power savings and faster, more accurate device timers (NORE [0005]).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over FINNEGAN, in view of LANGGUTH, as applied to claim 7, and in further view of PUDIPEDDI et al. Pub. No.: US 2019/0129882 A1 (hereafter PUDIPEDDI).
Regarding claim 11, while FINNEGAN and LANGGUTH discusses execution of multiple peripheral devices, FINNEGAN and LANGGUTH discuss:
selectively powering down at least one of the communication pathway and peripheral electronic devices when inactive.
However, in analogous art that similarly discusses execution of multiple peripheral devices, PUDIPEDDI teaches:
selectively powering down at least one of the communication pathway and peripheral electronic devices when inactive ([0030] The flow 100 includes enabling reduced functionality 150. Functionality can be reduced to decrease power consumption or thermal dissipation, to allow other modules to operate, to enable communication between modules, etc. The flow 100 includes enabling reduced functionality 150. The reduced functionality can be desirable to reduce power consumption or thermal dissipation; to power down, to put into a “sleep” mode peripheral elements that are unused or are awaiting data; and so on).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined PUDPEDDI’s teaching of powering down unused peripherals, with FINNEGAN’s teaching of executing multiple peripherals, to realize, with a reasonable expectation of success, a system executing a multiple peripherals, as in FINNEGAN, that powers down unused peripherals, as in PUDPEDDI. A person having ordinary skill would have been motivated to make this combination to improve power consumption and thermal dissipation (PUDIPEDDI [0030]).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over FINNEGAN, in view of LANGGUTH, as applied to claim 13, and in further view of SCHNEIDER et al. Pub. No.: US 2022/0006836 A1 (hereafter SCHNEIDER).
Regarding claim 15, while FINNEGAN and LANGGUTH discuss converting between protocols when transmitting data, FINNEGAN and LANGGUTH do not explicitly teach:
the aggregated data transmission comprises both: a translated signal; and an encapsulated signal.
However, in analogous art that similarly discloses converting between protocols when transmitting data, SCHNEIDER teaches:
the aggregated data transmission comprises both: a translated signal; and an encapsulated signal ([0034] Once a communication having an outdated protocol is identified, the system of the present disclosure may update the at-risk communication (e.g., communications 228 and 230). For example, the communications hardener 210 may include a protocol converter 254 having a translator 256 and/or an encapsulator 258. [0035] The protocol converter 254 is depicted in FIG. 2 as including both the translator 256 and the encapsulator 258, and in some embodiments, the protocol converter 254 may include both components. In other aspects, the protocol converter 254 may include one of the translator 256 or the encapsulator 258 (i.e., communications having outdated protocols are transmitted either by both translating the communication into a newer protocol, or encapsulating the communication within the newer protocol)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined SCHNEIDER’s teaching of transmitting signals by both translating protocols and encapsulating protocols, with the combination of FINNEGAN and LANGGUTH’s teaching of converting between protocols when transmitting data, to realize, with a reasonable expectation of success, a system that converts between protocols when transmitting data, as in FINNEGAN and LANGGUTH, by both encapsulating or translating the signals, as in SCHNEIDER. A person having ordinary skill would have been motivated to make this combination to allow older products having older communication protocols to still function in newer ecosystems (SCHNEIDER [0002-0003]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
CHANG et al. Pub. No.: US 2021/0400232 A1 discloses a data converter that receives multimedia data in a first transmission protocol, packs the data into data conforming to a second transmission protocol, and transmits the data to another data converter which unpacks the data back into the first transmission protocol before reaching the destination.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached at (571) 272-4169. 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.
/MICHAEL W AYERS/Primary Examiner, Art Unit 2195
Prosecution Insights