DETAILED ACTION
Remarks
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is responsive to the preliminary amendment field on 12/27/2023. Claims 1-10 and 13, of which claims 1, 7-10, and 13 are independent, were pending in this application and have been considered below.
Priority
Acknowledgment is made of the Applicant's claim for foreign priority filed in FRANCE on 06/29/2021 under 35 U.S.C. 119(a)-(d).
Acknowledgment is made of the Applicant's indication of National Stage entry from the International Application No. PCT/FR2022/051285 field on 06/28/2022.
Information Disclosure Statement
The references cited on the information disclosure statement (IDS) submitted on 12/27/2023 and 03/06/2024 have been considered and made of record by the examiner.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant's cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Rejections - 35 USC § 112(b) or pre-AIA 35 USC § 35 USC § 112, second paragraph
Examiner Note: The Leahy-Smith America Invents Act (AIA ) made technical changes to 35 U.S.C. § 112 that only apply to patent applications filed on or after on September 16, 2012.
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 pre-AIA 35 U.S.C. 112, 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-10 and 13 are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, 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 pre-AIA the applicant regards as the invention
Regarding claims 1, 7-9, and 13, claims recite the limitation “at least one user terminal” (line 5 of claims 1 and 7; line 7 of claim 8; line 8 of claims 9 and 13), which is vague because it is not clear whether it is the same as or different from already recited limitation “at least one user terminal” (line 2 of claims 1 and 8-9; line 3 of claim 7; line 6 of claim 13). It is recommended to replace the limitation with phrase --the at least one user terminal--.
Regarding claims 1, 8 and 13, claim recites the limitation “at least one identified user terminal” (line 7 of claim 1; line 8 of claim 8; line 9 of claim 13), which is vague and indefinite, because the claim already recites “identify at least one user terminal” (line 5 of claim 1; line 7 of claim 8; line 8 of claim 13). It is recommended to replace the limitation with phrase --the at least one identified user terminal--.
Regarding claim 7, claim recites the language “transmitting a request to identify at least one user terminal to a server, with said transmission of the identification request being implemented in response to an interaction of a user with said electronic device.” (line 6 of claim 7), which term “transmitting … with …” makes it vague and indefinite. It is not clear what term “transmitting … with …” is referring to which leaves the reader in doubt as to the meaning of the technical feature to which it refers to, thereby rendering the definition of the subject matter of the claim indefinite. It is recommended to replace the language with -- transmitting a request to identify at least one user terminal to a server, wherein said transmission of the identification request being implemented in response to an interaction of a user with said electronic device.--.
Regarding claim 9, claim recites the limitation “a server” (line 9 of claim 9), which is vague because it is not clear whether it is the same as or different from already recited limitation “a server” (line 1 of claim 9). It is recommended to replace the limitation with phrase --the server--.
Claim 9 also recites “interact with a user configured to receive an action of the user” (line 10 of claim 9), which term “a user configured to receive an action of the user” makes it vague and indefinite. It is not clear what term “a user … receive an action of the user” is referring to, which leaves the reader in doubt as to the meaning of the technical feature to which it refers to, thereby rendering the definition of the subject matter of the claim indefinite.
Claim 9 further recites “in response to said action, implement the transmission of the request to identify said at least one user terminal.” (line 11 of claim 9), which is vague and indefinite, because claim already recites “transmit a request to identify at least one user terminal to a server”, which means “the transmission of the request to identify said at least one user terminal” has already been done. This aforesaid issue leaves the reader in doubt as to the meaning of the technical feature to which it refers to, thereby rendering the definition of the subject matter of the claim indefinite.
Regarding claim 10, claim recites the imitation “A user terminal” (line 1 of claim 10). However, claim later recites limitations “at least one user terminal” (line 12 of claim 10), which makes it vague and indefinite, because it is not clear what the difference is between aforesaid two limitation, which leaves the reader in doubt as to the meaning of the technical feature to which it refers to, thereby rendering the definition of the subject matter of the claim indefinite. It is recommended to replace the limitation “at least one user terminal” (line 12 of claim 10) with phrase --the user terminal--.
Claim 10 also recites the language “receive, from a server, a notification request allowing said management application to be activated, with said notification request being transmitted by the server following identification of said user terminal in response to reception, from said at least one electronic device, of a request to identify at least one user terminal.” (line 9 of claim 10), which term “receive … with …” makes it vague and indefinite. It is not clear what term “receive … with …” is referring to which leaves the reader in doubt as to the meaning of the technical feature to which it refers to, thereby rendering the definition of the subject matter of the claim indefinite. It is recommended to replace the language with -- transmitting a request to identify at least one user terminal to a server, wherein said transmission of the identification request being implemented in response to an interaction of a user with said electronic device.--.
Regarding claims 2-6, claims are rejected due to their dependency to the rejected claim 1.
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 of this title, 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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1,148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
The foregoing obviousness inquiry requires an expansive and flexible approach, not a rigid approach demanding express teachings, suggestions and motivations to combine prior art teachings. KSR International Co. v. Teleflex, Inc., 82 USPQ2d 1385, 1395, 97 (US 2007). The rationale supporting a conclusion of obviousness should be made explicit for review, but the rationale does not require precise teachings directed to the specific subject matter of the claim. Id. at 1396. A rejection can rely on inferences and creative steps that a person of ordinary skill in the art would employ. Id. Obviousness rejections are not limited to showing the obviousness of solutions to the problems Applicant was trying to solve. Id. at 1397. Rather, one can show obviousness of a claim by establishing the obviousness of any solution to any known problem in the field of endeavor and addressed by a patent application's subject matter. Id. Moreover, one of ordinary skill in the art is not an automaton, but is possessed of ordinary creativity. Id. One of ordinary skill could find alternative uses for prior art elements beyond the elements' primary purposes and fit prior art teachings together like a puzzle. Id. A combination of prior art teachings does not require absolute predictability. Eli Lilly and Co. v. Zenith Goldline Pharmaceuticals Inc., 81 USPQ2d 1324, 1329 (Fed. Cir. 2006). All that is required is a reasonable expectation of success. Id.
Claims 1-10 and 13 are rejected under 35 U.S.C. 103(a) as being unpatentable over U.S. Patent Application Publication No. US 2011/0273625 Al to Mcmahon et al.
Regarding claim 1, Mcmahon et al. disclose a management method comprising:
managing an electronic device configured to communicate with at least one user terminal and at least one server, said management method managing being implemented by said server and comprising (¶[0005]: “In some embodiments, a user may use a networked remote device, such as an Internet Protocol-enabled mobile device, to interact with a web server that offers control options for a user's controlled device, such as a set-top box (STB), digital video recorder (DVR), display device, television, or any other computing device used by the user to consume content.”) {which means controlling devices by means of terminals using a server};
receiving, from the electronic device, a request to identify at least one user terminal (¶[0042]: “The controlled device may then transmit, in step 304, a pairing request 55 message to the application server 10”) {which disclose that a device to be controlled sends to the server a request for authorization of the connection of a user terminal}; (¶[0037]: “that cause the controlled device to provide the application server 107 with identification information for a user's remote control device (e.g., a personal computer 114, laptop 115, mobile device 116, external mobile device 117, etc.) that will be permitted to control the operation of the controlled device. This identification information can be a unique address of the remote control device or user”) {which means the transmission of information for identifying the control device to the server from the controlled device}; (¶[0045: “In some embodiments, a pairing may require authentication of the user and/or remote control device.”) {which means that the identification of the user terminal might be required in order to validate the connection request}; and
(¶[0039]: “The remote control application may contain program instructions for generating a user interface that the user can use to control the remote control device”) {which disclose an application on the terminal to control the device}. Mcmahon et al. disclose as stated above except for transmitting notification to said at least on user terminal to be activated. Activation of the user terminal is a task which could be done manually but it is automated to be done remotely by a notification from server. However, official notice is taken that the aforesaid automation and remote activation is common general knowledge in the art, which comes within the scope of the customary practice followed by persons skilled in the art. Considering the absence of textual disclosure by Mcmahon et al., any general argument that there is no suggestion of remote activation or the use of a server notification is too absolute, because it is common to automate a previously manual action (e.g., opening the app) by sending a server notification to a pre-selected terminal. This is based on general knowledge in the art (e.g., Mobile Device Management (MDM) and Enterprise Mobility Management (EMM) solutions establish trust between a management server and the endpoint device, often using certificates, to securely enforce policies, configure settings, and deploy applications. These solutions relies on push notification services such as Apple Push Notification service (APNs) for Apple devices and Firebase Cloud Messaging (FCM) for Android devices to "wake up" devices and notify them of pending actions or updates from the management server. Deep-links and Intents mechanism used to reference specific content or functionality within a mobile application, enabling direct navigation or activation). Claim 1 does not specify a particular protocol or specific technical measures exceeding this. Therefore, it would have been obvious to one ordinary skill in the art, before the effective filing date of the claimed invention, to use the well-known remote activation with the system of Mcmahon et al. to reach at the claimed invention with a reasonable expectation of success, because such a combination would have represented the combination of known techniques through conventional manners to provide predictable and expected results.
Regarding claim 2, Mcmahon et al. disclose as stated above. Mcmahon et al. also disclose wherein the receiving of the identification request is implemented in response to an interaction on said electronic device by a user (¶[0040]: "The request may be received, for example, when the user presses a "Pairing" button on the gateway/STB/DVR 111, choosing a "Pairing" option in an on-screen program guide, or otherwise signals to 45 it that pairing is requested.").
Regarding claim 3, Mcmahon et al. disclose as stated above, except for expressly teaching receiving, from the electronic device, a list of user terminals connected to said electronic device, with said at least one user terminal being identified from the received list of user terminals. However, the additional features merely define one of several straightforward possibilities which the skilled person would pursue, depending on the circumstances, to use the electronic device capabilities in order to solve the problem posed. Under KSR the known work in one field of endeavor may prompt variations of it for use in either the same field or a different one based on design incentives and is considered obvious. Therefore, it would be obvious to one of the ordinary skill, before the effective filing date of the claimed invention (at the time the invention was made), to try to choose from a finites number of ways to obtain the position location information of the vehicle, to reach at the claimed invention with a reasonable expectation of success.
Regarding claim 4, Mcmahon et al. disclose as stated above, except for expressly teaching wherein the list of user terminals is generated by said electronic device from a preliminary list comprising identifiers of user terminals connected to the electronic device, with each terminal identifier being associated with information representing a level of a signal received by the electronic device from said user terminal. However, the additional features merely define one of several straightforward possibilities which the skilled person would pursue, depending on the circumstances, to use the electronic device capabilities in order to solve the problem posed. Under KSR the known work in one field of endeavor may prompt variations of it for use in either the same field or a different one based on design incentives and is considered obvious. Therefore, it would be obvious to one of the ordinary skill, before the effective filing date of the claimed invention (at the time the invention was made), to try to choose from a finites number of ways to obtain the position location information of the vehicle, to reach at the claimed invention with a reasonable expectation of success.
Regarding claim 5, Mcmahon et al. disclose as stated above. Mcmahon et al. also disclose wherein transmitting said notification request is preceded by verifying an authorization of said at least one identified user terminal for managing an operation of the electronic device (¶[0044]: "Having the controlled device generate the passphrase may help minimize the chance of an unauthorized pairing.").
Regarding claim 6, Mcmahon et al. disclose as stated above, except for expressly teaching wherein verifying the authorization comprises polling a data table from an identifier of said at least one identified user terminal in order to verify presence of said identifier in said data table. However, using a data “lookup table” to compare data, including but not limited to the authorization data, is a general knowledge and common practice in the art, which comes within the scope of the customary practice followed by persons skilled in the art. Therefore, it would have been obvious to one ordinary skill in the art , before the effective filing date of the claimed invention, to use such known technique to arrive at the claimed invention with a reasonable expectation of success based on the common general knowledge.
Regarding claim 7, Mcmahon et al. disclose a method comprising:
activating an application for managing an electronic device, said application being installed on at least one user terminal (¶[0039]: “The remote control application may contain program instructions for generating a user interface that the user can use to control the remote control device”) {which disclose an application on the terminal to control the device}, said activating comprising:
transmitting a request to identify at least one user terminal to a server (¶[0042]: “The controlled device may then transmit, in step 304, a pairing request 55 message to the application server 10”) {which disclose that a device to be controlled sends to the server a request for authorization of the connection of a user terminal}, (¶[0037]: “that cause the controlled device to provide the application server 107 with identification information for a user's remote control device (e.g., a personal computer 114, laptop 115, mobile device 116, external mobile device 117, etc.) that will be permitted to control the operation of the controlled device. This identification information can be a unique address of the remote control device or user”) {which means the transmission of information for identifying the control device to the server from the controlled device}; (¶[0045: “In some embodiments, a pairing may require authentication of the user and/or remote control device.”) {which means that the identification of the user terminal might be required in order to validate the connection request}, with said transmission of the identification request being implemented in response to an interaction of a user (¶[00340]: "The request may be received, for example, when the user presses a "Pairing" button on the gateway/STB/DVR 111, choosing a "Pairing" option in an on-screen program guide, or otherwise signals to 45 it that pairing is requested."; ¶[0039]: “The remote control application may contain program instructions for generating a user interface that the user can use to control the remote control device”) {which disclose user interaction through user interface generated by the application control (i.e., interact with) the device.}. Mcmahon et al. disclose as stated above except for aforesaid interaction with electronic device, e.g., remote activation of the user terminal. However, aforesaid remote activation is common general knowledge in the art, which comes within the scope of the customary practice followed by persons skilled in the art. Considering the absence of textual disclosure by Mcmahon et al., any general argument that there is no suggestion of remote activation or the use of a server notification is too absolute, because it is common to automate a previously manual action (e.g., opening the app) by sending a server notification to a pre-selected terminal. This is based on general knowledge in the art (e.g., Mobile Device Management (MDM) and Enterprise Mobility Management (EMM) solutions establish trust between a management server and the endpoint device, often using certificates, to securely enforce policies, configure settings, and deploy applications. These solutions relies on push notification services such as Apple Push Notification service (APNs) for Apple devices and Firebase Cloud Messaging (FCM) for Android devices to "wake up" devices and notify them of pending actions or updates from the management server. Deep-links and Intents mechanism used to reference specific content or functionality within a mobile application, enabling direct navigation or activation). Therefore, it would have been obvious to one ordinary skill in the art, before the effective filing date of the claimed invention, to use the well-known remote activation with the system of Mcmahon et al. to reach at the claimed invention with a reasonable expectation of success, because such a combination would have represented the combination of known techniques through conventional manners to provide predictable and expected results.
Regarding claim 8, Mcmahon et al. disclose a server configured to communicate with at least one electronic device and at least one user terminal, the server comprising:
at least one processor (¶[0025]: "The computing device 200 may include one or more processors 201); and
at least one non-transitory computer readable medium comprising instructions stored thereon which when executed by the at least one processor configure the server to (¶[0025]: "The computing device 200 may include one or more processors 201, which may execute instructions of a computer program to perform any of the features described herein. The instructions may be stored in any type of computer-readable medium or memory, to configure the operation of the processor 201”):
receive, from said electronic device, a request to identify at least one user terminal (¶[0042]: “The controlled device may then transmit, in step 304, a pairing request 55 message to the application server 10”) {which disclose that a device to be controlled sends to the server a request for authorization of the connection of a user terminal}; (¶[0037]: “that cause the controlled device to provide the application server 107 with identification information for a user's remote control device (e.g., a personal computer 114, laptop 115, mobile device 116, external mobile device 117, etc.) that will be permitted to control the operation of the controlled device. This identification information can be a unique address of the remote control device or user”) {which means the transmission of information for identifying the control device to the server from the controlled device}; (¶[0045: “In some embodiments, a pairing may require authentication of the user and/or remote control device.”) {which means that the identification of the user terminal might be required in order to validate the connection request; and
(¶[0039]: “The remote control application may contain program instructions for generating a user interface that the user can use to control the remote control device”) {which disclose an application on the terminal to control the device}. Mcmahon et al. disclose as stated above except for transmitting notification to said at least on user terminal to be activated. Activation of the user terminal is a task which could be done manually but it is automated to be done remotely by a notification from server. However, aforesaid automation and remote activation is common general knowledge in the art, which comes within the scope of the customary practice followed by persons skilled in the art. Considering the absence of textual disclosure by Mcmahon et al., any general argument that there is no suggestion of remote activation or the use of a server notification is too absolute, because it is common to automate a previously manual action (e.g., opening the app) by sending a server notification to a pre-selected terminal. This is based on general knowledge in the art (e.g., Mobile Device Management (MDM) and Enterprise Mobility Management (EMM) solutions establish trust between a management server and the endpoint device, often using certificates, to securely enforce policies, configure settings, and deploy applications. These solutions relies on push notification services such as Apple Push Notification service (APNs) for Apple devices and Firebase Cloud Messaging (FCM) for Android devices to "wake up" devices and notify them of pending actions or updates from the management server. Deep-links and Intents mechanism used to reference specific content or functionality within a mobile application, enabling direct navigation or activation). Claim 8 does not specify a particular protocol or specific technical measures exceeding this. Therefore, it would have been obvious to one ordinary skill in the art, before the effective filing date of the claimed invention, to use the well-known remote activation with the system of Mcmahon et al. to reach at the claimed invention with a reasonable expectation of success, because such a combination would have represented the combination of known techniques through conventional manners to provide predictable and expected results..
Regarding claim 9, Mcmahon et al. disclose an electronic device configured to communicate with a server and with at least one user terminal comprising an application for managing said electronic device, said electronic device comprising:
at least one processor (¶[0025]: "The computing device 200 may include one or more processors 201), and
at least one non-transitory computer readable medium comprising instructions stored thereon which when executed by the at least one processor configure the electronic device to (¶[0025]: "The computing device 200 may include one or more processors 201, which may execute instructions of a computer program to perform any of the features described herein. The instructions may be stored in any type of computer-readable medium or memory, to configure the operation of the processor 201”):
transmit a request to identify at least one user terminal to a server (¶[0042]: “The controlled device may then transmit, in step 304, a pairing request 55 message to the application server 10”) {which disclose that a device to be controlled sends to the server a request for authorization of the connection of a user terminal}, (¶[0037]: “that cause the controlled device to provide the application server 107 with identification information for a user's remote control device (e.g., a personal computer 114, laptop 115, mobile device 116, external mobile device 117, etc.) that will be permitted to control the operation of the controlled device. This identification information can be a unique address of the remote control device or user”) {which means the transmission of information for identifying the control device to the server from the controlled device}; (¶[0045: “In some embodiments, a pairing may require authentication of the user and/or remote control device.”) {which means that the identification of the user terminal might be required in order to validate the connection request}; and
“The remote control application may contain program instructions for generating a user interface that the user can use to control the remote control device”) {which disclose user through user interface generated by the application control (i.e., interact) the device.}. transmitting a request to identify at least one user terminal to a server (¶[0042]: “The controlled device may then transmit, in step 304, a pairing request 55 message to the application server 10”) {which disclose that a device to be controlled sends to the server a request for authorization of the connection of a user terminal}, with said transmission of the identification request being implemented in response to an interaction of a user (¶[00340]: "The request may be received, for example, when the user presses a "Pairing" button on the gateway/STB/DVR 111, choosing a "Pairing" option in an on-screen program guide, or otherwise signals to 45 it that pairing is requested."; ¶[0039]: “The remote control application may contain program instructions for generating a user interface that the user can use to control the remote control device”) {which disclose user interaction through user interface generated by the application control (i.e., interact with) the device.}. Mcmahon et al. disclose as stated above except for aforesaid interaction with electronic device, e.g., remote activation of the user terminal. However, aforesaid remote activation is common general knowledge in the art, which comes within the scope of the customary practice followed by persons skilled in the art. Considering the absence of textual disclosure by Mcmahon et al., any general argument that there is no suggestion of remote activation or the use of a server notification is too absolute, because it is common to automate a previously manual action (e.g., opening the app) by sending a server notification to a pre-selected terminal. This is based on general knowledge in the art (e.g., Mobile Device Management (MDM) and Enterprise Mobility Management (EMM) solutions establish trust between a management server and the endpoint device, often using certificates, to securely enforce policies, configure settings, and deploy applications. These solutions relies on push notification services such as Apple Push Notification service (APNs) for Apple devices and Firebase Cloud Messaging (FCM) for Android devices to "wake up" devices and notify them of pending actions or updates from the management server. Deep-links and Intents mechanism used to reference specific content or functionality within a mobile application, enabling direct navigation or activation). Therefore, it would have been obvious to one ordinary skill in the art, before the effective filing date of the claimed invention, to use the well-known remote activation with the system of Mcmahon et al. to reach at the claimed invention with a reasonable expectation of success, because such a combination would have represented the combination of known techniques through conventional manners to provide predictable and expected results.
Regarding claim 10, Mcmahon et al. disclose a user terminal:
at least one processor r (¶[0025]: "The computing device 200 may include one or more processors 201);
and at least one non-transitory computer readable medium comprising instruction stored thereon which when executed by the al least one processor configure the user terminal to (¶[0025]: "The computing device 200 may include one or more processors 201, which may execute instructions of a computer program to perform any of the features described herein. The instructions may be stored in any type of computer-readable medium or memory, to configure the operation of the processor 201”):
store an application for managing at least one electronic device on the al least one non-transitory computer readable medium (¶[0023]: “An application server 107 may be a computing device”; ¶[0025]: "The computing device 200 may include one or more processors 201, which may execute instructions of a computer program to perform any of the features described herein. The instructions may be stored in any type of computer-readable medium or memory, to configure the operation of the processor 201”; ¶[0027]: application loaded on the application server 107”);
(¶[0039]: “The remote control application may contain program instructions for generating a user interface that the user can use to control the remote control device”) {which disclose an application on the terminal to control the device}, with said notification request being transmitted by the server following identification of said user terminal in response to reception, from said at least one electronic device, of a request to identify at least one user terminal (¶[0042]: “The controlled device may then transmit, in step 304, a pairing request 55 message to the application server 10”) {which disclose that a device to be controlled sends to the server a request for authorization of the connection of a user terminal}; (¶[0037]: “that cause the controlled device to provide the application server 107 with identification information for a user's remote control device (e.g., a personal computer 114, laptop 115, mobile device 116, external mobile device 117, etc.) that will be permitted to control the operation of the controlled device. This identification information can be a unique address of the remote control device or user”) {which means the transmission of information for identifying the control device to the server from the controlled device}; (¶[0045: “In some embodiments, a pairing may require authentication of the user and/or remote control device.”) {which means that the identification of the user terminal might be required in order to validate the connection request}. Mcmahon et al. disclose as stated above except for receiving notification at said at least on user terminal to be activated. Activation of the user terminal is a task which could be done manually but it is automated to be done remotely by a notification from server. However, aforesaid automation and remote activation is common general knowledge in the art, which comes within the scope of the customary practice followed by persons skilled in the art. Considering the absence of textual disclosure by Mcmahon et al., any general argument that there is no suggestion of remote activation or the use of a server notification is too absolute, because it is common to automate a previously manual action (e.g., opening the app) by sending a server notification to a pre-selected terminal. This is based on general knowledge in the art (e.g., Mobile Device Management (MDM) and Enterprise Mobility Management (EMM) solutions establish trust between a management server and the endpoint device, often using certificates, to securely enforce policies, configure settings, and deploy applications. These solutions relies on push notification services such as Apple Push Notification service (APNs) for Apple devices and Firebase Cloud Messaging (FCM) for Android devices to "wake up" devices and notify them of pending actions or updates from the management server. Deep-links and Intents mechanism used to reference specific content or functionality within a mobile application, enabling direct navigation or activation). Claim 10 does not specify a particular protocol or specific technical measures exceeding this. Therefore, it would have been obvious to one ordinary skill in the art, before the effective filing date of the claimed invention, to use the well-known remote activation with the system of Mcmahon et al. to reach at the claimed invention with a reasonable expectation of success, because such a combination would have represented the combination of known techniques through conventional manners to provide predictable and expected results
Regarding claim 13, Mcmahon et al. disclose a non-transitory processor-readable information medium, on which a computer program is stored comprising code instructions for implementing a management method, when the program is executed by a processor of a server (¶[0025]: "The computing device 200 may include one or more processors 201, which may execute instructions of a computer program to perform any of the features described herein. The instructions may be stored in any type of computer-readable medium or memory, to configure the operation of the processor 201”), wherein the management method comprises:
managing an electronic device configured to communicate with at least one user terminal and the server (¶[0005]: “In some embodiments, a user may use a networked remote device, such as an Internet Protocol-enabled mobile device, to interact with a web server that offers control options for a user's controlled device, such as a set-top box (STB), digital video recorder (DVR), display device, television, or any other computing device used by the user to consume content.”) {which means controlling devices by means of terminals using a server}, said managing comprising:
receiving, from the electronic device, a request to identify at least one user terminal (¶[0042]: “The controlled device may then transmit, in step 304, a pairing request 55 message to the application server 10”) {which disclose that a device to be controlled sends to the server a request for authorization of the connection of a user terminal}; (¶[0037]: “that cause the controlled device to provide the application server 107 with identification information for a user's remote control device (e.g., a personal computer 114, laptop 115, mobile device 116, external mobile device 117, etc.) that will be permitted to control the operation of the controlled device. This identification information can be a unique address of the remote control device or user”) {which means the transmission of information for identifying the control device to the server from the controlled device}; (¶[0045: “In some embodiments, a pairing may require authentication of the user and/or remote control device.”) {which means that the identification of the user terminal might be required in order to validate the connection request}; and
(¶[0039]: “The remote control application may contain program instructions for generating a user interface that the user can use to control the remote control device”) {which disclose an application on the terminal to control the device}. Mcmahon et al. disclose as stated above except for transmitting notification to said at least on user terminal to be activated. Activation of the user terminal is a task which could be done manually but it is automated to be done remotely by a notification from server. However, aforesaid automation and remote activation is common general knowledge in the art, which comes within the scope of the customary practice followed by persons skilled in the art. Considering the absence of textual disclosure by Mcmahon et al., any general argument that there is no suggestion of remote activation or the use of a server notification is too absolute, because it is common to automate a previously manual action (e.g., opening the app) by sending a server notification to a pre-selected terminal. This is based on general knowledge in the art (e.g., Mobile Device Management (MDM) and Enterprise Mobility Management (EMM) solutions establish trust between a management server and the endpoint device, often using certificates, to securely enforce policies, configure settings, and deploy applications. These solutions relies on push notification services such as Apple Push Notification service (APNs) for Apple devices and Firebase Cloud Messaging (FCM) for Android devices to "wake up" devices and notify them of pending actions or updates from the management server. Deep-links and Intents mechanism used to reference specific content or functionality within a mobile application, enabling direct navigation or activation). Claim 13 does not specify a particular protocol or specific technical measures exceeding this. Therefore, it would have been obvious to one ordinary skill in the art, before the effective filing date of the claimed invention, to use the well-known remote activation with the system of Mcmahon et al. to reach at the claimed invention with a reasonable expectation of success, because such a combination would have represented the combination of known techniques through conventional manners to provide predictable and expected results.
Conclusion
Examiner's note: As applied to the claims above, the specific columns, line numbers, and figures in the references has been cited for the Applicant’s convenience. Although the specified citations are representative of the teachings of the art and are applied to the particular limitations within the individual claims, other passages and figures may apply as well. The Applicant is respectfully requested to fully consider the references, in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage taught by the prior art or disclosed by the Examiner, in preparing responses. Applicant(s) are reminded that MPEP 2123 I. states: “The use of patents as references is not limited to what the patentees describe as their own inventions or to the problems with which they are concerned. They are part of the literature of the art, relevant for all they contain.” In re Heck, 699 F.2d 1331, 1332-33, 216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275, 277 (CCPA 1968)). A reference may be relied upon for all that it would have reasonably suggested to one having ordinary skill the art, including nonpreferred embodiments. Merck & Co. v. Biocraft Laboratories, 874 F.2d 804, 10 USPQ2d 1843 (Fed. Cir.), cert. denied, 493 U.S. 975 (1989).
Reliance on the US Pre-Grant Publication (PG PUB) of this application, which is not part of the image file wrapper of the patent application, in the prosecution is improper. All references in the reply to the office action are to be made to the latest version on record of the patent application as filed not as published. The latest version on record of the patent application means the patent application as originally filed and modified by previously entered amendment(s).
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Kwon et al. (US 2019/0259374 A1) is equivalent and trustworthy translation of the IDS cited foreign application No. WO 2019/160265 A1.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Nader Bolourchi whose telephone number is (571) 272-8064. The examiner can normally be reached on M-F 8:30 to 4:30.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hannah S. Wang, SPE can be reached on (571) 272-9018. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Interviews are available via telephone and video conferencing using a USPTO web-based Video Conferencing and Collaboration Tool. To schedule an interview, Applicants are encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
Communications via Internet e-mail are at the discretion of the applicant. See MPEP § 502.03. Without a written authorization by applicant in place, the USPTO will not respond via Internet e-mail to any Internet correspondence which contains information subject to the confidentiality requirement as set forth in 35 U.S.C. 122 and will not initiate communications with applicants via Internet e-mail. The internet authorization must be submitted on a separate paper to be entitled to acceptance in accordance with 37 CFR 1.4(c). The separate paper will facilitate processing and avoid confusion. The written authorization may be submitted via EFS-Web, mail, or fax. It cannot be submitted by email.
The following is a sample authorization form, which may be used by applicant:
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
A written authorization may be withdrawn by filing a signed paper clearly identifying the original authorization. The following is a sample form which may be used by applicant to withdraw the authorization:
“The authorization given on______, to the USPTO to communicate with any practitioner of record or acting in a representative capacity in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application via video conferencing, instant messaging, or electronic mail is hereby withdrawn.”
To facilitate processing of the internet communication authorization or withdraw of authorization, the Office strongly encourages use of Form PTO/SB/439, filed via EFS-Web. The Form is available at:
https://www.uspto.gov/sites/default/files/documents/sb0439.pdf.
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.
/Nader Bolourchi/
Primary Examiner, Art Unit 2631