DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 (i.e., changing from AIA to pre-AIA ) 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.
Claim Objections
Claim 20 is objected to because of the following informalities:
In claim 20, lines 7-8, “the one or more processors” should be changed to --the processor-- to match the prior claim language.
Appropriate correction is required.
Response to Arguments
Applicant's arguments filed 11/18/25 have been fully considered but they are not persuasive.
In response to applicant's argument that Stark is nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, Stark discloses a communication device with different possible radios, each capable of communicating with different protocols (paragraph 24), which will receive a signal which indicates potential device connections and triggers the device to switch between first and second modes (enabling/disable different communication radios and associated protocols; see Fig. 3, paragraph 67-73) which is clearly within appellant’s field of endeavor.
The fact that the inventor has recognized another advantage which would flow naturally from following the suggestion of the prior art cannot be the basis for patentability when the differences would otherwise be obvious. See Ex parte Obiaya, 227 USPQ 58, 60 (Bd. Pat. App. & Inter. 1985).
Applicant argues that “Stark's solution, therefore, is to turn off a hardware module completely; the "protocol" (Wi-Fi) being disabled is merely a consequence of the hardware being powered down.”
In response, it is first noted that the claims do not define or require any particular method of “disabling” communications, and powering down the communication modules (each of which have their own associated communication protocols), as disclosed by Stark, would clearly meet the language of “deactivated”.
Further, it is noted that Stark discloses additional power saving modes that do not require turning off the hardware module completely, such as a “listening mode” and power standby mode (paragraph 41-42, 44).
In response to applicant’s arguments regarding Sangvhi, it is noted that Sangvhi was relied upon for disclosing a device detecting and communicating with another device within a first communication mode and then switching to a second communication mode (communicating in first protocol to negotiate service communication in another protocol; Fig. 3, paragraph 67-73), wherein the second communication mode is mDNS (selecting and activating mDNS protocol to communicate desired services; Fig. 3, 314-318; paragraph 69-80, 13, 35, 54, 59).
Stark indicates different possible radios, each capable of communicating with different protocols (paragraph 24), but does not explicitly disclose mDNS protocol.
Sangvhi discloses different communication devices with different communication protocols varying based upon the installed radios (paragraph 45), which includes mDNS protocol (paragraph 34, 54).
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
In this case, the combination of Nijim with Stark and Sangvhi meets the current claim limitations, as activating/deactivating a radio to enable/disable associated mDNS protocol communications meets the current claim limitations.
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-5, 7-13, 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Nijim et al. (Nijim) (US 10,448,080) (of record) in view of Stark et al. (Stark) (US 2014/0192692) (of record) and Sanghvi et al. (Sanghvi) (US 2017/0318098) (of record).
As to claim 1, while Nijim discloses a method (column 3, line 30-48), comprising:
receiving, by a casting module of a set top box (stb receiving content from device, 110; Fig. 1, column 3, line 63-column 4, line 5, column 5, line 5-21), a signal indicating a potential user device connection (column 4, line 6-15);
determining, by the set top box, that a communications module (see Fig. 1, 5; 117; column 3, line 35-48, column 9, line 63-column 10, line 9) is in a first mode (column 4, line 16-58),
causing, by the set top box, the communications module to enter a second mode (column 4, line 16-58),
allowing, by the set top box, the user device to connect to the set top box via the casting module (column 3, line 63-column 4, line 5, column 5, line 5-21);
determining, by the set top box, that the casting module is not connected to the user device (column 5, line 11-15); and
causing, by the set top box, the communication module to enter the first mode (column 5, line 11-15),
Nijim fails to specifically disclose communicating using a multicast domain name system (mDNS) protocol, the first mode characterized by a mDNS protocol being deactivated, the second mode characterized by the mDNS protocol being activated.
In an analogous art, Stark discloses a communication system (Fig. 1) which will detect a potential device connection (Fig. 2, paragraph 35-36, 45-52), determine that a computing device is in a first mode characterized by a protocol being disabled (paragraph 36-37, 52-53) and entering a second mode, characterized by the protocol being enabled (paragraph 37, 53, 57-58) so as to reduce power consumption requirements by not maintaining unneeded communication equipment when not in use (paragraph 25-28).
It would have been obvious to one of ordinary skill in the art to modify Nijim’s system to include a first mode characterized by a protocol being deactivated, the second mode characterized by the protocol being activated, as taught in combination with Stark, for the typical benefit of reducing power usage by switching off unused communication equipment (paragraph 25-28).
Additionally, in an analogous art, Sanghvi discloses a communication system (Fig. 2) which will detect a potential device connection (Fig. 3, paragraph 67-73) and enter a second mode, characterized by a mDNS protocol being enabled (selecting and activating mDNS protocol to communicate desired services; Fig. 3, 314-318; paragraph 69-80, 13, 35, 54, 59) so as to take advantage of an already known communication protocol which is easy to implement or natively supported by widely utilized operating systems (“WINDOWS and iOS® have native support for mDNS/DNS-SD and it is fairly simple to implement on ANDROID or even embedded devices that support IP networks”; paragraph 54).
Additionally, it would have been obvious to one of ordinary skill in the art to modify Nijim and Stark’s system to include mDNS protocol, as taught in combination with Sanghvi, for the typical benefit of utilizing a known communication protocol which is easy to implement or natively supported by widely utilized operating systems (paragraph 54).
As to claim 2, Nijim, Stark and Sangvhi disclose wherein the set top box operates in the second mode according to a default setting (see Stark at paragraph 28, 55), the method further comprising: receiving, by the set top box, instructions that when executed by the computing device, cause the set top box to be reconfigured such that the set top box device operates in the first mode according to the default setting (see Stark at paragraph 55-57).
As to claim 3, Nijim, Stark and Sangvhi disclose wherein the signal indicating the potential device connection is received in response to a user input (Fig. 2, initiated upon selection by a user; see Stark at paragraph 55 and Nijim at column 4, line 16-58).
As to claim 4, Nijim, Stark and Sangvhi disclose wherein the signal indicating the potential device connection is received from the user device (Bluetooth poll detecting nearby Wi-Fi device; see Stark at paragraph 47-50, 55 and Nijim at column 4, line 3, line 49-column 4, line 5).
As to claim 5, Nijim, Stark and Sangvhi disclose wherein determining that the user device is not connected to the set top box comprises at least one of
receiving a second signal that causes the set top box to enter into the first mode, determining that the user device has not connected to set top box, or determining that the user device has disconnected from the set top box device (see Stark at paragraph 54 and Nijim at column 5, line 11-15).
As to claim 7, Nijim, Stark and Sangvhi disclose connecting, by the set top box, to the user device (see Stark at paragraph 44 and Nijim at column 4, line 16-58),
receiving, by the set top box and from the user device, data associated with media to be displayed (mobile device, 110, sharing content with stb; see Nijim at Fig. 1, column 3, line 63-column 4, line 5, column 5, line 5-21),
generating, by the set top box, an image based on the data associated with the media received from the user device (see Nijim at column 7, line 51-67); and
causing, by the set top box, the image to be displayed (see Nijim at column 7, line 51-67).
As to claim 8, Nijim, Stark and Sangvhi disclose wherein the signal is received from a second set top box (signal received from other device indicating Wi-Fi connection is available; see Stark at paragraph 47-51, 56-58 and Nijim at Fig. 1, column 3, line 35-48), and the computing device enters the first mode for a predetermined time period (time based value for Wi-Fi scanning before disabling Wi-Fi radio; see Stark at paragraph 57 and Nijim at Fig. 1, column 3, line 35-48).
As to claim 9, while Nijim discloses a system (Fig. 1, 5; 118; column 3, line 30-48), comprising:
one or more processors (Fig. 3, 304); and
a computer-readable memory comprising instructions that, when executed by the one or more processors (302; column 8, lines 18-41), cause the set top box to perform operations to:
receive, by a casting module of a set top box (stb receiving content from device, 110; Fig. 1, column 3, line 63-column 4, line 5, column 5, line 5-21), a signal indicating a potential user device connection (column 4, line 6-15);
determine, by the set top box, that a communications module (see Fig. 1, 5; 117; column 3, line 35-48, column 9, line 63-column 10, line 9) is in a first mode (column 4, line 16-58),
cause, by the set top box, the communications module to enter a second mode (column 4, line 16-58),
allow, by the set top box, the user device to connect to the set top box via the casting module (column 3, line 63-column 4, line 5, column 5, line 5-21);
determine, by the set top box, that the casting module is not connected to the user device (column 5, line 11-15); and
causing, by the set top box, the communication module to enter the first mode (column 5, line 11-15),
Nijim fails to specifically disclose communicating using a multicast domain name system (mDNS) protocol, the first mode characterized by a mDNS protocol being deactivated, the second mode characterized by the mDNS protocol being activated.
In an analogous art, Stark discloses a communication system (Fig. 1) which will detect a potential device connection (Fig. 2, paragraph 35-36, 45-52), determine that a computing device is in a first mode characterized by a protocol being disabled (paragraph 36-37, 52-53) and entering a second mode, characterized by the protocol being enabled (paragraph 37, 53, 57-58) so as to reduce power consumption requirements by not maintaining unneeded communication equipment when not in use (paragraph 25-28).
It would have been obvious to one of ordinary skill in the art to modify Nijim’s system to include a first mode characterized by a protocol being deactivated, the second mode characterized by the protocol being activated, as taught in combination with Stark, for the typical benefit of reducing power usage by switching off unused communication equipment (paragraph 25-28).
Additionally, in an analogous art, Sanghvi discloses a communication system (Fig. 2) which will detect a potential device connection (Fig. 3, paragraph 67-732) and enter a second mode, characterized by a mDNS protocol being enabled (selecting and activating mDNS protocol to communicate desired services; Fig. 3, 314-318; paragraph 69-80, 13, 35, 54, 59) so as to take advantage of an already known communication protocol which is easy to implement or natively supported by widely utilized operating systems (“WINDOWS and iOS® have native support for mDNS/DNS-SD and it is fairly simple to implement on ANDROID or even embedded devices that support IP networks”; paragraph 54).
Additionally, it would have been obvious to one of ordinary skill in the art to modify Nijim and Stark’s system to include mDNS protocol, as taught in combination with Sanghvi, for the typical benefit of utilizing a known communication protocol which is easy to implement or natively supported by widely utilized operating systems (paragraph 54).
As to claim 10, Nijim, Stark and Sangvhi disclose wherein the system further comprises a display (television 116 connected to stb 118; see Nijim at column 7, line 51-67), and the system further performs operations to:
connect to the user device (see Stark at paragraph 44 and Nijim at column 4, line 16-58),
receive data associated with media to be displayed from the user device (mobile device, 110, sharing content with stb; see Nijim at Fig. 1, column 3, line 63-column 4, line 5, column 5, line 5-21),
generate an image based on the data received from the user device (see Nijim at column 7, line 51-67); and
cause the image to be displayed by the display (see Nijim at column 7, line 51-67).
As to claim 11, Nijim, Stark and Sangvhi disclose wherein the system is connected to one or more other systems via a first network and is connected to a computing device via a second network (Bluetooth and Wi-Fi networks to nearby devices; see Stark at Fig. 1, paragraph 24).
As to claim 12, Nijim, Stark and Sangvhi disclose wherein the system transmits an internet protocol multicast to the one or more other systems via the first network (see Sangvhi at Fig. 3, 314-318; paragraph 69-80, 13, 35, 54, 59)
As to claim 13, Nijim, Stark and Sangvhi disclose wherein the system connects to the user device via a third network (see Stark at paragraph 58).
As to claim 15, while Nijim, Stark and Sangvhi disclose mobile devices with limited battery (see Stark at paragraph 25-27), they fail to specifically disclose wherein the system comprises an internet of things (IoT) device.
The examiner takes Official Notice that it was notoriously well known in the art before the effective filing date of the claimed invention to utilize internet of things (IoT) devices, such as thermostats and worn devices including health trackers, so as to provide convenience to users through the automation of different devices for sensing and monitoring of the environment.
It would have been obvious to one of ordinary skill in the art to modify Nijim, Stark and Sangvhi’s system to include wherein the system comprises an internet of things (IoT) device for the typical benefit of providing devices to automatically sense and report monitored information utilizing a known form of devices.
As to claim 16, Nijim, Stark and Sangvhi disclose wherein the signal is received from a remote control associated with the system (see Nijim at column 4, line 6-15).
As to claim 17, Nijim, Stark and Sangvhi disclose wherein the signal is received from a computing device, and the system enters the first mode for a predetermined time period (see Stark at paragraph 44, 49-54, 57).
As to claim 18, Nijim, Stark and Sangvhi disclose wherein the system comprises a sensor and the signal is received from the sensor (see Stark at paragraph 44, 55, 57 and Nijim at column 2, line 46-59, column 4, line 20-30, sensing signal strength).
As to claim 19, Nijim, Stark and Sanghvi fail to specifically disclose wherein the system is preconfigured to default to the second mode (see Stark at paragraph 28, 55) and includes code that reconfigures the system to default to the first mode (see Stark at paragraph 55-57).
As to claim 20, while Nijim discloses a set top box (Fig. 1, 5; 118; column 3, line 30-48), comprising:
a casting module configured to receive data from a user device (mobile device, 110, sharing content with stb; Fig. 1, column 3, line 63-column 4, line 5, column 5, line 5-21) and display an image on a display connected to the set top box (television 116 connected to stb 118; Fig. 1, column 3, line 63-column 4, line 5, column 5, line 5-21);
a communications module configured to communicate with one or more other set top boxes (see Fig. 1, 5; 117; column 3, line 35-48, column 9, line 63-column 10, line 9),
a processor (Fig. 3, 304); and
a computer-readable memory comprising instructions that, when executed by the one or more processors (302; column 8, lines 18-41), cause the set top box to perform operations to:
receive a signal indicating a potential user device connection (column 4, line 6-15);
determine that the communications module is in a first mode (column 4, line 16-58),
cause the communications module to enter a second mode (column 4, line 16-58),
allow the user device to connect to the set top box via the casting module (column 3, line 63-column 4, line 5, column 5, line 5-21);
determine that the set top box is not connected to the user device (column 5, line 11-15); and
cause the communication module to enter the first mode (column 5, line 11-15),
Nijim fails to specifically disclose communicating using a multicast domain name system (mDNS) protocol, the first mode characterized by a mDNS protocol being deactivated, the second mode characterized by the mDNS protocol being activated.
In an analogous art, Stark discloses a communication system (Fig. 1) which will detect a potential device connection (Fig. 2, paragraph 35-36, 45-52), determine that a computing device is in a first mode characterized by a protocol being disabled (paragraph 36-37, 52-53) and entering a second mode, characterized by the protocol being enabled (paragraph 37, 53, 57-58) so as to reduce power consumption requirements by not maintaining unneeded communication equipment when not in use (paragraph 25-28).
It would have been obvious to one of ordinary skill in the art to modify Nijim’s system to include a first mode characterized by a protocol being deactivated, the second mode characterized by the protocol being activated, as taught in combination with Stark, for the typical benefit of reducing power usage by switching off unused communication equipment (paragraph 25-28).
Additionally, in an analogous art, Sanghvi discloses a communication system (Fig. 2) which will detect a potential device connection (Fig. 3, paragraph 67-732) and enter a second mode, characterized by a mDNS protocol being enabled (selecting and activating mDNS protocol to communicate desired services; Fig. 3, 314-318; paragraph 69-80, 13, 35, 54, 59) so as to take advantage of an already known communication protocol which is easy to implement or natively supported by widely utilized operating systems (“WINDOWS and iOS® have native support for mDNS/DNS-SD and it is fairly simple to implement on ANDROID or even embedded devices that support IP networks”; paragraph 54).
Additionally, it would have been obvious to one of ordinary skill in the art to modify Nijim and Stark’s system to include mDNS protocol, as taught in combination with Sanghvi, for the typical benefit of utilizing a known communication protocol which is easy to implement or natively supported by widely utilized operating systems (paragraph 54).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to James R Sheleheda whose telephone number is (571)272-7357. The examiner can normally be reached M-F 8 am-5 pm CST.
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, Benjamin Bruckart can be reached at (571) 272-3982. 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.
/James R Sheleheda/Primary Examiner, Art Unit 2424