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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. TW112143598, filed on November 13, 2023.
Information Disclosure Statement
The Information Disclosure Statement (IDS) filed on October 22, 2024 and January 03, 2025 have been considered by Examiner.
Drawings
The drawings are objected to under 37 CFR 1.83(a). In Figure 1B, reference numeral 100 is incorrectly labeled “display devic.” The specification identifies reference numeral 100 as the “display device.” Figure 1B should be corrected to label reference numeral 100 as “display device.”
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-12 and 14 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter regarded as the invention.
Claim 1 recites, in relevant part: “by the display device, in response to pairing request information being transmitted, waiting to receive pairing information”
The claim does not positively recite the transmission of the pairing request information, nor does it identify the entity transmitting the pairing request information or the recipient of that information. Instead, the claim merely states that the display device waits to receive pairing information “in response to paring request information being transmitted”
Accordingly, it is unclear which transmission event causes the display device to enter the waiting state. Because the triggering transmission is not affirmatively recited or otherwise identified, the metes and bounds of the claimed operation are uncertain.
Claim 1 further recites: “by the display device, in response to determining the pairing information, generating first information;” And “by the server, in response to determining the first information, generating second information.”
However, the claim does not previously recite any operation of determining either the pairing information or the first information. Furthermore, the claim does not specify what is being determined with respect to the respective information, such as whether the information is correct, valid, authentic, matches predetermined information, or satisfies another condition. Because the claim fails to define the determination that triggers the subsequent generation of the first information and second information, the scope of these operations is uncertain.
Claim 2-12 depend from Claim 1 and do not remedy either of the foregoing deficiencies. Accordingly, Claim 2-12 are likewise indefinite
Claim 14 recites, in relevant part: “wherein the display device, in response to determining that the pairing information is correct …”, And “wherein the server, in response to determining that the first information is valid …”
The claim fails to recite how, by whom, or according to what criterion the pairing information is determined to be correct or the first information is determined to be valid. Consequently, the conditions that trigger the subsequent operations are not sufficiently defined, rendering the scope of the claim uncertain.
Claims 1-12 and 14 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. Claims 1-3, 6, 9, and 14 include the phrase “so as to” followed by further steps and functions. It is unclear whether the language following the “so as to” is an intended result, not given patentable weight, or functions and elements that are required to be performed by the devices. For these reasons, the phrase “so as to” renders the scope of the claim indefinite.
Claims 4-5, 7-8, and 10-12 are rejected for the same reasons by virtue of their dependency on Claim 1, respectively.
Claim 13 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential elements, such omission amounting to a gap between the elements. See MPEP § 2172.01. Claim 13 recites “when the processing apparatus receives a pairing activation command, the communication circuit is configured to send first information and receive second information, at least one of the input/output device and the lighting device is configured to display an indication of completed pairing.” The omitted elements are: what entity is the first information sent to? What is the first information? What is the second information? How does this first information and second information actually produce a completed pairing? Simply stating send and receive information and a pairing was complete is incommensurate with the scope of the specification when that information is given absolutely zero metes and bounds. For these reasons, the claimed invention is indefinite.
Claim Rejections - 35 USC § 102
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 8, 10-11, and 13-14 are rejected under 35 U.S.C. 102(a)(1) & 102(a)(2) as being anticipated by Fenton et al (US 2013/0198516).
Regarding Claim 1, Fenton teaches a display device pairing method, adapted for a display device management system, wherein the display device management system comprises a display device and a server ([0150], FIG. 9A illustrates a flowchart 900 a for a method of pairing an unregistered device for use with a virtual identity. The method of flowchart 900 a may be carried out by a pairing repository), the method comprising:
by the display device, executing a pairing activation command ([0150], The method may include receiving a request from the unregistered device (910));
by the display device, in response to pairing request information being transmitted, waiting to receive pairing information ([0151], The method may also include sending a pairing code and an identifier to the unregistered device (912). In one embodiment, the pairing repository may create a pairing code comprising an n-digit pseudorandom number with a check digit);
by the display device, receiving the pairing information provided by the server ([0152], The pairing repository may also select an identifier to be sent to the unregistered device. In one embodiment, the identifier may comprise the pairing nonce (PNONCE) described above);
by the display device, in response to determining the pairing information, generating first information, and transmitting the first information to the server ([0157], In order to retrieve the identity repository locator, some embodiments may have the unregistered device send the pairing nonce and/or the pairing code to the pairing repository as an identifier. If the pairing repository determines that the pairing nonce and/or pairing code is a valid and currently active value, the pairing repository may send the identity repository locator in response. In another embodiment, the pairing repository may redirect the request to the identity repository, without explicitly sending the identity repository identifier to the unregistered device. The redirect may also include the pairing code);
by the server, in response to determining the first information, generating second information, and transmitting the second information to the display device ([0156], The method may also optionally include sending the identity repository locator to the unregistered device (918). In one embodiment, a virtual identity may be stored on various different identity repositories, and the identity repository locator may be used to select among the available identity repositories, [0160], the additional information may be sent in order to verify the identity of a user. Steps involving such additional information will be described in further detail below. The method may also include associating the unregistered device with the virtual identity using the pairing code (924). In one embodiment, the identity repository may use the pairing code to index a table containing identifying information for the virtual identity, as well as the secret information); and
by the display device, according to the second information, establishing a dedicated communication channel between the display device and the server, so as to allow data or commands to be transmitted via the dedicated communication channel ([0195], Each user device may use software modules that may be associated with the identity repository 1402. For example, access device 1419 may include software module 1409 operating thereon. Software module 1409 may comprise a web browser, JavaScript, a webpage, a dedicated application, a background process, and/or the like. Similarly, control device 1418 may include software module 1408 operating thereon. If control device 1418 comprises a smart phone, software module 1408 may comprise an a mobile application (“app”) made available by the identity repository 1402 or by an entity associated with the identity repository 1402, [0051], the systems described herein can work with an open identity federation where the members of the federation support an API. Users can choose their repository operator and transfer their credentials between repositories securely); thereby completing the operation of pairing the display device with the server ([0161-0162], The method may also include sending the secret information to the unregistered device (926). In one embodiment, the secret information may comprise the encrypted SDK and salt values. In another embodiment, additional information may be provided to the unregistered device with the secret information, After receiving the encrypted secret information, along with any additional information that may be provided by the identity repository, the unregistered device may decrypt the encrypted secret information for use in future transactions).
Regarding Claim 2, Fenton teaches the display device pairing method according to claim 1, further comprising: by the display device, providing management account information to the server by executing an activation interface; by the server, in response to determining that the management account information passes authentication ([0150], If the device being added is an access device, the user may navigate to a webpage operated by the pairing repository that contains JavaScript and prompts the user for a device name (DEVNAME) by which the access device should be known, as well as a passcode for the user's account with the identity repository. Alternatively, if the device being added is a control device, the user may interact with an identity repository software module operating on the control device, such as an app on a smart phone. The software module may prompt the user for a DEVNAME and a passcode, such as a PIN), sending a login success notification to the display device, so as to cause the display device to execute the pairing activation command ([0151], method may also include sending a pairing code and an identifier to the unregistered device (912) (triggers device pairing and indicates login success)); and
by the display device, in response to executing the pairing activation command, executing a pairing interface, and displaying the pairing prompt via the pairing interface ([0153], next steps in the registration process may take place remotely from the pairing repository. In one embodiment, the pairing code may be displayed to the user of the control device. The user of the control device may then enter the pairing code into a registered device, such as an access device, [0157], In order to retrieve the identity repository locator, some embodiments may have the unregistered device send the pairing nonce and/or the pairing code to the pairing repository as an identifier. If the pairing repository determines that the pairing nonce and/or pairing code is a valid and currently active value, the pairing repository may send the identity repository locator in response. In another embodiment, the pairing repository may redirect the request to the identity repository, without explicitly sending the identity repository identifier to the unregistered device. The redirect may also include the pairing code).
Regarding Claim 8, Fenton teaches the display device pairing method according to claim 1, wherein the second information comprises a connection string ([0154], Consequently, the method may also include receiving the pairing code and optionally an identity repository locator from a registered device (914). In one embodiment, the identity repository locator may comprise the name of the user's home repository for identity management. The identity repository locator may comprise a URL or a domain name. If the pairing repository determines that the pairing code matches a valid and currently active pairing code, the pairing repository may send the identifier to the registered device (916). In one embodiment, this may comprise sending the pairing nonce to the registered device. In another embodiment, additional information may also be provided to the registered device including, a pairing type that indicates whether the unregistered device is a control device or an access device, and a device name (DEVNAME) provided by the unregistered device).
Regarding Claim 10, Fenton teaches the display device pairing method according to claim 1, wherein the pairing information comprises management account information ([0150], user may interact with an identity repository software module operating on the control device, such as an app on a smart phone. The software module may prompt the user for a DEVNAME and a passcode, such as a PIN) and a pairing server identifier ([0154], Consequently, the method may also include receiving the pairing code and optionally an identity repository locator from a registered device (914). In one embodiment, the identity repository locator may comprise the name of the user's home repository for identity management. The identity repository locator may comprise a URL or a domain name. If the pairing repository determines that the pairing code matches a valid and currently active pairing code, the pairing repository may send the identifier to the registered device (916). In one embodiment, this may comprise sending the pairing nonce to the registered device. In another embodiment, additional information may also be provided to the registered device including, a pairing type that indicates whether the unregistered device is a control device or an access device, and a device name (DEVNAME) provided by the unregistered device).
Regarding Claim 11, Fenton teaches the display device pairing method according to claim 10, wherein the method further comprises: after receiving the pairing information, by the display device, determining whether the pairing information meets the following conditions: whether the format of the pairing information is a predetermined format; and whether the pairing server identifier matches the server ([0152], The pairing repository may also select an identifier to be sent to the unregistered device. In one embodiment, the identifier may comprise the pairing nonce (PNONCE) described above. Although any format or transmission method may be used to send the identifier and the pairing code to the unregistered device, one specific embodiment returns a JSON object containing the pairing code in decimal format (e.g., {“PAIRING”, “55580”}) and the identifier in base-64 format, [0157], In order to retrieve the identity repository locator, some embodiments may have the unregistered device send the pairing nonce and/or the pairing code to the pairing repository as an identifier. If the pairing repository determines that the pairing nonce and/or pairing code is a valid and currently active value, the pairing repository may send the identity repository locator in response).
Regarding Claim 13, Fenton teaches a display device management system ([0223], FIG. 18 is a block diagram illustrating components of an exemplary operating environment in which various embodiments of the present invention may be implemented. The system 1800 can include one or more user computers 1805, 1810, which may be used to operate a client, whether a dedicated application, web browser, etc.), comprising: a display device (Fig. 19), communicatively connected to a network ([0224], In some embodiments, the system 1800 may also include a network 1815), the display device comprising;
a communication circuit, communicatively connected to the network; a storage device illustrates an exemplary computer system 1900, in which various embodiments of the present invention may be implemented. The system 1900 may be used to implement any of the computer systems described above. The computer system 1900 is shown comprising hardware elements that may be electrically coupled via a bus 1955. The hardware elements may include one or more central processing units (CPUs) 1905, one or more input devices 1910 (e.g., a mouse, a keyboard, etc.), and one or more output devices 1915 (e.g., a display device, a printer, etc.)),
for storing a serial number of the display device and a pairing module ([0229], The computer system 1900 may also include one or more storage device 1920. By way of example, storage device(s) 1920 may be disk drives, optical storage devices, solid-state storage device such as a random access memory (“RAM”) and/or a read-only memory (“ROM”), which can be programmable, flash-updateable and/or the like, [0232] software elements within working memory);
a processing apparatus, electrically connected to the communication circuit and the storage device ([0230], The computer system 1900 may additionally include a computer-readable storage media reader 1925 a, a communications system 1930 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.), and working memory 1940, which may include RAM and ROM devices as described above. In some embodiments, the computer system 1900 may also include a processing acceleration unit 1935, which can include a DSP, a special-purpose processor and/or the like); and
at least one of an input/output device and a lighting device, electrically connected to the processing apparatus ([0229], FIG. 19 one or more input devices 1910 (e.g., a mouse, a keyboard, etc.), and one or more output devices 1915 (e.g., a display device, a printer, etc.)),
wherein when the processing apparatus receives a pairing activation command ([0150], The method may include receiving a request from the unregistered device (910)), the
communication circuit is configured to send first information and receive second information ([0180], During the beginning stages of the pairing process, a passcode may be received by the unregistered device (1312). The unregistered device may then compute the X2 value. In one embodiment, the X2 value may be generated by hashing the passcode to an elliptic curve and shifting the hashed passcode according to a randomly generated value R. The X2 value can then be sent to the pairing repository (1314). The pairing repository can then create a pairing code and a pairing nonce that can be sent to the unregistered device (1316)), at
least one of the input/output device and the lighting device is configured to display an indication of completed pairing ([0181], the unregistered device can provide the pairing code to a user of the unregistered device, for example, by displaying the pairing code on a display screen (1317). The user can then transfer the pairing code to a registered device as part of the pairing process (1318), [0183], Turning back to the unregistered device, the user may provide an input indicating that the pairing code has been entered into the registered device).
Regarding Claim 14, Fenton teaches the display device management system according to claim 13, further comprising: a server, communicatively connected to the display device via a network connection ([0150], FIG. 9A illustrates a flowchart 900 a for a method of pairing an unregistered device for use with a virtual identity. The method of flowchart 900 a may be carried out by a pairing repository),
wherein the display device is configured to execute the pairing activation command ([0150], The method may include receiving a request from the unregistered device (910)),
the display device waits to receive pairing information in response to pairing request information being transmitted ([0151], The method may also include sending a pairing code and an identifier to the unregistered device (912). In one embodiment, the pairing repository may create a pairing code comprising an n-digit pseudorandom number with a check digit),
wherein the display device is configured to receive the pairing information provided by the server ([0152], The pairing repository may also select an identifier to be sent to the unregistered device. In one embodiment, the identifier may comprise the pairing nonce (PNONCE) described above),
wherein the display device, in response to determining that the pairing information is correct, is configured to generate the first information and transmit the first information to the server corresponding to the pairing information ([0157], In order to retrieve the identity repository locator, some embodiments may have the unregistered device send the pairing nonce and/or the pairing code to the pairing repository as an identifier. If the pairing repository determines that the pairing nonce and/or pairing code is a valid and currently active value, the pairing repository may send the identity repository locator in response. In another embodiment, the pairing repository may redirect the request to the identity repository, without explicitly sending the identity repository identifier to the unregistered device. The redirect may also include the pairing code),
wherein the server, in response to determining that the first information is valid, is configured to generate the second information and transmit the second information to the display device ([0156], The method may also optionally include sending the identity repository locator to the unregistered device (918). In one embodiment, a virtual identity may be stored on various different identity repositories, and the identity repository locator may be used to select among the available identity repositories, [0160], the additional information may be sent in order to verify the identity of a user. Steps involving such additional information will be described in further detail below. The method may also include associating the unregistered device with the virtual identity using the pairing code (924). In one embodiment, the identity repository may use the pairing code to index a table containing identifying information for the virtual identity, as well as the secret information),
wherein the display device, according to the second information, establishes a dedicated communication channel between the display device and the server, so as to allow data or commands to be transmitted via the dedicated communication channel ([0195], Each user device may use software modules that may be associated with the identity repository 1402. For example, access device 1419 may include software module 1409 operating thereon. Software module 1409 may comprise a web browser, JavaScript, a webpage, a dedicated application, a background process, and/or the like. Similarly, control device 1418 may include software module 1408 operating thereon. If control device 1418 comprises a smart phone, software module 1408 may comprise an a mobile application (“app”) made available by the identity repository 1402 or by an entity associated with the identity repository 1402, [0051], the systems described herein can work with an open identity federation where the members of the federation support an API. Users can choose their repository operator and transfer their credentials between repositories securely), thereby completing the operation of pairing the display device to the server ([0161-0162], The method may also include sending the secret information to the unregistered device (926). In one embodiment, the secret information may comprise the encrypted SDK and salt values. In another embodiment, additional information may be provided to the unregistered device with the secret information, After receiving the encrypted secret information, along with any additional information that may be provided by the identity repository, the unregistered device may decrypt the encrypted secret information for use in future transactions).
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 (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.
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 3-6 are rejected under 35 U.S.C. 103 as being unpatentable over Fenton et al (US 2013/0198516), in view of Koo et al (US 2017/0127276).
Regarding Claim 3, Fenton teaches display device pairing method according to claim 1, wherein the display device management system further comprises a smart electronic device, wherein the method further comprises: by the smart electronic device, providing management account information to the server through an activation interface ([0150], user may interact with an identity repository software module operating on the control device, such as an app on a smart phone. The software module may prompt the user for a DEVNAME and a passcode, such as a PIN);
by the smart electronic device, providing the pairing request information to the server ([0157], In order to retrieve the identity repository locator, some embodiments may have the unregistered device send the pairing nonce and/or the pairing code to the pairing repository as an identifier. If the pairing repository determines that the pairing nonce and/or pairing code is a valid and currently active value, the pairing repository may send the identity repository locator in response. In another embodiment, the pairing repository may redirect the request to the identity repository, without explicitly sending the identity repository identifier to the unregistered device. The redirect may also include the pairing code);
by the server, generating the pairing information according to the received pairing request information, and transmitting the pairing information to the smart electronic device ([0156], The method may also optionally include sending the identity repository locator to the unregistered device (918). In one embodiment, a virtual identity may be stored on various different identity repositories, and the identity repository locator may be used to select among the available identity repositories, [0160], the additional information may be sent in order to verify the identity of a user. Steps involving such additional information will be described in further detail below. The method may also include associating the unregistered device with the virtual identity using the pairing code (924). In one embodiment, the identity repository may use the pairing code to index a table containing identifying information for the virtual identity, as well as the secret information); and
by the smart electronic device, establishing a communication connection to the display device, so as to transmit the pairing information to the display device via the communication connection ([0161-0162], The method may also include sending the secret information to the unregistered device (926). In one embodiment, the secret information may comprise the encrypted SDK and salt values. In another embodiment, additional information may be provided to the unregistered device with the secret information, After receiving the encrypted secret information, along with any additional information that may be provided by the identity repository, the unregistered device may decrypt the encrypted secret information for use in future transactions).
Fenton fails to teach the following, which in the same field of endeavor, Koo teaches by the server, in response to determining that the management account information passes authentication, sending a login success notification to the smart electronic device; by the smart electronic device, in response to receiving the login success notification, selecting the display device through the activation interface ([0034], In step 106, the authentication server 130 transmits an authentication code to the mobile terminal 120 on the basis of the result of the login. The authentication code is used to acquire an access token. Accordingly, in step 108, in order to receive the access token, the mobile terminal 120 transmits the received authentication code to the authentication server 130. Here, the mobile terminal 120 may display, on a screen thereof, the authentication code received from the authentication server 130, and may receive an authentication code as input from the user and may transmit the received authentication code to the authentication server 130).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate display of authentication tokens indicating success, as taught in Koo, in the system of Fenton, in order to enable the execution of an authentication operation even by a device that does not include an input/output interface and needs to perform an authentication operation through another device and the like. (See Koo [0007])
Regarding Claim 4, Fenton teaches the display device pairing method according to claim 1, wherein the display device management system further comprises a smart electronic device and a storage device ([0232]) for electrically connecting the smart electronic device ([0150], FIG. 9A illustrates a flowchart 900 a for a method of pairing an unregistered device for use with a virtual identity. The method of flowchart 900 a may be carried out by a pairing repository), wherein the method further comprises:
by the smart electronic device, providing management account information to the server through an activation interface ([0150], user may interact with an identity repository software module operating on the control device, such as an app on a smart phone. The software module may prompt the user for a DEVNAME and a passcode, such as a PIN);
by the smart electronic device, providing the pairing request information to the server through the activation interface ([0157], In order to retrieve the identity repository locator, some embodiments may have the unregistered device send the pairing nonce and/or the pairing code to the pairing repository as an identifier. If the pairing repository determines that the pairing nonce and/or pairing code is a valid and currently active value, the pairing repository may send the identity repository locator in response. In another embodiment, the pairing repository may redirect the request to the identity repository, without explicitly sending the identity repository identifier to the unregistered device. The redirect may also include the pairing code);
by the server, generating the pairing information according to the received pairing request information, and transmitting the pairing information to the smart electronic device ([0156], The method may also optionally include sending the identity repository locator to the unregistered device (918). In one embodiment, a virtual identity may be stored on various different identity repositories, and the identity repository locator may be used to select among the available identity repositories, [0160], the additional information may be sent in order to verify the identity of a user. Steps involving such additional information will be described in further detail below. The method may also include associating the unregistered device with the virtual identity using the pairing code (924). In one embodiment, the identity repository may use the pairing code to index a table containing identifying information for the virtual identity, as well as the secret information);
by the smart electronic device, in response to receiving the pairing information, generating the pairing activation command through the activation interface ([0195], Each user device may use software modules that may be associated with the identity repository 1402. For example, access device 1419 may include software module 1409 operating thereon. Software module 1409 may comprise a web browser, JavaScript, a webpage, a dedicated application, a background process, and/or the like. Similarly, control device 1418 may include software module 1408 operating thereon. If control device 1418 comprises a smart phone, software module 1408 may comprise an a mobile application (“app”) made available by the identity repository 1402 or by an entity associated with the identity repository 1402, [0051], the systems described herein can work with an open identity federation where the members of the federation support an API. Users can choose their repository operator and transfer their credentials between repositories securely); and
by the smart electronic device, storing the pairing activation command and the pairing information in the storage device ([0161-0162], The method may also include sending the secret information to the unregistered device (926). In one embodiment, the secret information may comprise the encrypted SDK and salt values. In another embodiment, additional information may be provided to the unregistered device with the secret information, After receiving the encrypted secret information, along with any additional information that may be provided by the identity repository, the unregistered device may decrypt the encrypted secret information for use in future transactions).
Fenton fails to teach the following, which in the same field of endeavor, Koo teaches by the server, in response to determining that the management account information passes authentication, sending a login success notification to the activation interface of the smart electronic device ([0034], In step 106, the authentication server 130 transmits an authentication code to the mobile terminal 120 on the basis of the result of the login. The authentication code is used to acquire an access token. Accordingly, in step 108, in order to receive the access token, the mobile terminal 120 transmits the received authentication code to the authentication server 130. Here, the mobile terminal 120 may display, on a screen thereof, the authentication code received from the authentication server 130, and may receive an authentication code as input from the user and may transmit the received authentication code to the authentication server 130).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate display of authentication tokens indicating success, as taught in Koo, in the system of Fenton, in order to enable the execution of an authentication operation even by a device that does not include an input/output interface and needs to perform an authentication operation through another device and the like. (See Koo [0007])
Regarding Claim 5, Fenton, modified by Koo, teaches the display device pairing method according to claim 4, Fenton further teaches wherein the method further comprises: by the storage device electrically connected to the display device ([0232]), executing the pairing activation command on the display device ([0150], The method may include receiving a request from the unregistered device (910));
by the display device, in response to executing the pairing activation command, executing a pairing interface, and displaying the pairing prompt via the pairing interface ([0150], user may interact with an identity repository software module operating on the control device, such as an app on a smart phone. The software module may prompt the user for a DEVNAME and a passcode, such as a PIN); and
by the display device, in response to the pairing prompt being confirmed, reading the pairing information from the storage device ([0157], In order to retrieve the identity repository locator, some embodiments may have the unregistered device send the pairing nonce and/or the pairing code to the pairing repository as an identifier. If the pairing repository determines that the pairing nonce and/or pairing code is a valid and currently active value, the pairing repository may send the identity repository locator in response. In another embodiment, the pairing repository may redirect the request to the identity repository, without explicitly sending the identity repository identifier to the unregistered device. The redirect may also include the pairing code).
Regarding Claim 6, Fenton, modified by Koo, teaches the display device pairing method according to claim 4, Koo further teaches wherein the display device further comprises a pairing button, wherein the method further comprises: by the display device, in response to the pairing button being triggered, executing the pairing activation command to execute a pairing interface, and reading the storage device electrically connected via the connection interface of the display device, so as to obtain the pairing information ([0118], The pairing start menu may be selected in the electronic device 950 in order to prepare for a direct pairing of the electronic device 950 with the mobile terminal 930. The pairing start menu and the device registration menu may be selected by a physical button, a software button, a button of a remote control, or the like. When the user selects the pairing start menu, a Wi-Fi Direct mode, which enables the electronic device 950 to be directly connected to the mobile terminal 930 through Wi-Fi communication, is executed in the electronic device 950).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate display of authentication tokens indicating success, as taught in Koo, in the system of Fenton, in order to enable the execution of an authentication operation even by a device that does not include an input/output interface and needs to perform an authentication operation through another device and the like. (See Koo [0007])
Claims 7 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Fenton et al (US 2013/0198516), in view of Molettiere et al (US 2014/02351680.
Regarding Claim 7, Fenton teaches the display device pairing method according to claim 1, wherein the first information comprises the pairing information ([0145], Generally, the pairing code may be a short combination of letters and/or numbers that may be easily read from a screen and entered into the registered device 806. For example, the pairing code may comprise a string of digits such as “5178”, or may comprise a string of mixed numbers and characters such as “5OP81Z”. The user may read this pairing code from the unregistered device 802 and enter the pairing code into the registered device 806 (814)).
Fenton fails to teach the following, which in the same field of endeavor, Molettiere teaches wherein the first information comprises a serial number of the display device ([0032], Information associated with the user's account may be used to determine which devices are eligible to be paired. This information may also be used in determining a device class. Information entered into the client, server, or a third entity in communication with either the client or server, such as a web site may also be used to determine eligibility or device class. This information includes, but is not limited to information regarding a purchased device such as model number or other model identification, color, device serial number, unique device identifier, battery level of the device, whether the device is already paired, and the type or level of the user's account (such as a “normal” account, or a premium account that includes more features, typically for a fee)).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the inclusion of device serial number with pairing information, as taught in Molettiere, in the system of Fenton, in order to enhance the accuracy with which external devices are identified for pairing and activation.
Regarding Claim 12, Fenton teaches the display device pairing method according to claim 10, wherein the first information comprises the pairing information ([0145], Generally, the pairing code may be a short combination of letters and/or numbers that may be easily read from a screen and entered into the registered device 806. For example, the pairing code may comprise a string of digits such as “5178”, or may comprise a string of mixed numbers and characters such as “5OP81Z”. The user may read this pairing code from the unregistered device 802 and enter the pairing code into the registered device 806 (814)), the method further comprising: after receiving the first information, by the server, determining whether the first information meets: whether the time of receiving the first information exceeds the pairing time limit in the pairing information ([0158], the pairing code and/or the secret information may expire after a predetermined time interval, after which these values may be securely deleted from the identity repository).
Fenton fails to teach the following, which in the same field of endeavor, Molettiere teaches wherein the first information comprises a serial number of the display device ([0032], Information associated with the user's account may be used to determine which devices are eligible to be paired. This information may also be used in determining a device class. Information entered into the client, server, or a third entity in communication with either the client or server, such as a web site may also be used to determine eligibility or device class. This information includes, but is not limited to information regarding a purchased device such as model number or other model identification, color, device serial number, unique device identifier, battery level of the device, whether the device is already paired, and the type or level of the user's account (such as a “normal” account, or a premium account that includes more features, typically for a fee)).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the inclusion of device serial number with pairing information, as taught in Molettiere, in the system of Fenton, in order to enhance the accuracy with which external devices are identified for pairing and activation.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Fenton et al (US 2013/0198516), in view of Silver (US 2014/0195675).
Regarding Claim 9, Fenton teaches the display device pairing method according to claim 8, wherein a terminal electronic device is communicatively connected to the server, and logs into the server via the management account information ([0150], user may interact with an identity repository software module operating on the control device, such as an app on a smart phone. The software module may prompt the user for a DEVNAME and a passcode, such as a PIN), the method further comprising:
the terminal electronic device transmitting a control command to the server ([0154], Consequently, the method may also include receiving the pairing code and optionally an identity repository locator from a registered device (914). In one embodiment, the identity repository locator may comprise the name of the user's home repository for identity management. The identity repository locator may comprise a URL or a domain name. If the pairing repository determines that the pairing code matches a valid and currently active pairing code, the pairing repository may send the identifier to the registered device. In one embodiment, this may comprise sending the pairing nonce to the registered device. In another embodiment, additional information may also be provided to the registered device including, a pairing type that indicates whether the unregistered device is a control device or an access device, and a device name (DEVNAME) provided by the unregistered device)
cause the server to transmit the control command to the display device via the dedicated communication channel, thereby controlling the display device ([0153], The next steps in the registration process may take place remotely from the pairing repository. In one embodiment, the pairing code may be displayed to the user of the control device. The user of the control device may then enter the pairing code into a registered device, such as an access device. Like the control device, the access device may run a software module provided by the pairing repository or the identity repository when entering the pairing code. In another embodiment, the user of the access device may navigate to a website operated by the identity repository or the pairing repository. In response to receiving the pairing code, the registered device may send a transmission to the pairing repository)
Fenton fails to teach the following, which in the same field of endeavor, Silver teaches the terminal electronic device transmitting display data to the server, so as to cause the server to transmit the display data to the display device via the dedicated communication channel, thereby causing the display device to display an image according to the received display data ([0080], From the content delivery network (CDN) 208 or the broadcast nodes, the content data streams 207 are selectively sent to remote client computing devices 209 for display by an instance of a player. The player is obtained by registering with the interactive content distribution platform which then provides for subsequent login as exemplarily illustrated in FIGS. 4-5. The peer computing devices 308 access the content data streams 207 via the client computing devices 209, for example, through a real time media flow protocol, [0097], The player 607 is configured to deliver multiple content data streams 207 simultaneously to the display screen 209 a connected to the authenticated client computing device 209, for example, a computer, a tablet, a smart phone, a TV, etc).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the control of data displayed on the device by a terminal, as taught in Silver, in the system of Fenton, in order to enhance the representation and/or reproduction of content across devices with different access capabilities. (See Silver [0014])
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARGARET G WEBB whose telephone number is (571)270-7803. The examiner can normally be reached M-F 9:00-6:00 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, Charles Appiah can be reached at (571) 272-7904. 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.
/MARGARET G WEBB/ Primary Examiner, Art Unit 2641
Prosecution Insights