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 .
This office action is in response to the amendment filed on 07/01/2025.
Claims 1, 3, 6, 10, 15-16, 18-20 have been amended. Claims 2, 4-5 and 17 have been cancelled. New claims 21-23 have been added. Claims 1, 3, 6-16, and 18-23 have been examined.
Response to Arguments
Applicant’s arguments, see Remarks, filed on 07/01/2025, with respect to the 35 U.S.C. 103 rejections have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of MOMCHILOV et al, (US 2020/0374121).
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, 3, 6-16, and 18-23 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, 15 and 16 recite “verifying, by the electronic device, the connection ticket using the device identifier of the electronic device and the received device identifier” it is unclear how the device verifies the “connection ticket” using the device id of itself and not clear whether “the received device identifier” is the same or different than “the device identifier of the electronic device or not. Examiner suggests further clarifying the claim scope by clearly distinguishing the device identifier and the electronic device identifier and how the electronic device verifies itself. Dependent claims are also rejected for inheriting the deficiencies from the independent claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 3, 6-7, 9, 11-16, 18-19 and 21-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Reunamaki et al. (US-20130326495-A1) in view of Vanderveen et al (US-20130227655-A1) and in view of MOMCHILOV et al, (US 20200374121).
In regards to claim 1, Reunamaki teaches a method performed by an electronic device comprising:
exiting a shelf-life mode and turning on a peer-to-peer wireless protocol in response to detecting a power source (Reunamaki: As non-limiting examples waking-up the devices can be done using low power radio technologies such as BT LE, NFC, or a wireless recharging loop (Paragraph 179) to initiate a wireless flashing, which refers to a wireless interaction between one or more electronic devices that can include remote booting, data transfer, and installation of software or firmware updates (Paragraph 42).);
providing, via the peer-to-peer wireless protocol, a device identifier of the electronic device to a host device (Reunamaki: In response to a wireless flashing event, the device could be prompted to provide an electronic identifier (ID) (Paragraph 43).);
receiving, via the peer-to-peer wireless protocol from the host device, a connection ticket authorizing the electronic device to connect to a wide area network, (Reunamaki: the wireless flashing initiator (WFI) sends relevant settings data to the EDM 200 such as the name of a secure communication network, the service set identifier (SSID) of the access point, security settings, security keys and key indexes (Paragraph 57).);
requesting, responsive to the connection ticket, a connection from an access point identified by the connection ticket to the wide area network using a network wireless protocol (Reunamaki: After receiving connectivity information from the WFI, the device uses the access point to connect with the communication network (Paragraph 57-58).) ; and
performing a software update over the wide area network. (Reunamaki: Additional information can be sent to the EDM 200 to allow access to the electronic device manufacturer's server or an affiliated party to provide firmware and/or software updated via a predetermined WLAN (Paragraph 57).) .
However, Reunamaki does not explicitly teach… receiving, via the peer-to-peer wireless protocol from the host device, a connection ticket authorizing the electronic device to connect to a wide area network, the connection ticket being generated by a server system using a private key of the server system, wherein the connection ticket comprises a received device identifier associated with the electronic device;
Vanderveen, in the same field of endeavor, teaches a ticket-based authentication method that discloses… receiving, via the peer-to-peer wireless protocol from the host device, a connection ticket authorizing the electronic device to connect to a wide area network, the connection ticket being generated by a server system using a private key of the server system, wherein the connection ticket comprises a received device identifier of the electronic device and a network identifier of the wide area network. (Vanderveen: A module for transmits an authorization ticket certified by a trusted party to the device (Paragraph 18), where the authorization ticket can include various information such as a device identifier, a validity period, a cryptographic signature an authorization server, as well as other information (Paragraph 55).) ;
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the connectivity information received from the Wireless Flashing Initiator as taught by Reunamaki with the authorization ticket taught by Vanderveen. The motivation to do so would be to ensure that only authorized devices are allowed to connect to the access point.
Both references do not explicitly teach, however, MOMCHILOV discloses verifying, by the electronic device, the connection ticket using the device identifier of the electronic device and the received device identifier; and connecting, responsive to the verifying the connection ticket to the wide area network identified by the connection ticket using a network wireless protocol. (see para. [0082]-[0083], ] Delivery Services Authentication Token (DSAuthT), CL, Polymorphic AuthT (polymorphic authentication token), mini-CL (validateSessionResult with status Redirect-Target), and gateway 263 connection ticket (GCT)…, Polymorphic AuthT, mini-CL, GCT may be in signed JSON objects of the form: manifest (clear)—includes user-device identity; payload (may be encrypted depending on type); symmetric key encrypted for entity (if payload is encrypted); and signature on manifest plus payload. DSAuthT is a primary token unless otherwise specified as a secondary token providing constrained access to a specific service, e.g., DSAuthT-WS-CLIS, Para [0092]–[0094], [0107]-[0117], The gateway 263 creates a Gateway Connection Ticket (GCT) with info from CL and validateSessionResult mini-CL as follows. A manifest (clear) includes: expiration time—consistent with CL expiration time; user identity—user universal claims (OID, SID, UPN, e-mail); customer ID; and device identity—Device ID, Endpoint Pub Key Thumbprint. The CGT may further include: Payload (clear)—Resource Location, VDA IP and port, etc.; signature—Sign GCT with GW POP Priv Key. The client device 252 uses the GCT and Resource Connection Ticket to authorize the connection at gateway 263 and virtual delivery appliance 253) Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teaching of Ratnamani and Vanderveen with MOMCHILOV in order to provide to enable secure remote connections by creating connection tickets that include device and resource identity information (see para. [0108], MOMCHILOV).
In regards to claim 3, the combination of Reunamaki and Vanderveen and MOMCHILOV teach the method of claim 1, wherein the connection ticket includes a message and a signature of the message, the signature generated using the private key of the server system (Vanderveen: FIG3, the authorization ticket 400 includes a device identifier and cryptographic signature of the authorization server covering the entire ticket data (Paragraph 69).),
wherein verifying the connection ticket comprises: verifying the signature using the message and a public key that corresponds to the private key of the server system (Vanderveen: A part of the authorization ticket creation can include the generation of a cryptographic signature on which the validity of the authorization ticket relies (Paragraph 111). .
In regards to claim 6, the combination of Reunamaki and Vanderveen and MOMCHILOV teach the method of claim 1, wherein the connection to the wide area network is requested in response to receiving the connection ticket (Reunamaki: After receiving connectivity information from the WFI, the device uses the access point to connect with the communication network (Paragraph 57-58).) .
In regards to claim 7 and 21, the combination of Reunamaki and Vanderveen and MOMCHILOV teach the method of claim 1, wherein the device identifier is provisioned to an authentication list of the server system prior to the electronic device exiting the shelf-life mode (Reunamaki: FIG2, The microcontroller 120 derives the electronic device's IMEI and MAC address by accessing memory 130 contained within the wireless flashing initiator 100. Memory 130 contains a list of known accessible Bluetooth low energy (BT LE) devices in a so-called white list 135 as well as their corresponding barcode number (not shown). Alternatively, the microcontroller 120 can access a communication network by way of a broadband radio via a wireless local area network (WLAN) to remotely access an over the air server containing the above described data hosted by the electronic device manufacturer (Paragraph 50).) .
In regards to claim 9 and 23, the combination of Reunamaki and Vanderveen and MOMCHILOV teach the method of claim 1, wherein after performing the software update, the device identifier is removed from an authentication list at the server system (Reunamaki: After the software update is completed the device powers down and the white list can be erased, modified or updated (Paragraph 130).).
In regards to claim 11, the combination of Reunamaki and Vanderveen and MOMCHILOV teach the method of claim 1, wherein the peer-to-peer wireless protocol is near- field communication (NFC) (Reunamaki: Another embodiment of the teachings present an electronic device is configured to include near field communication functionality to receive wireless flashing from a near field interrogator (Paragraph 152).).
In regards to claim 12, the combination of Reunamaki and Vanderveen and MOMCHILOV teach the method of claim 1, wherein the software update is performed while the electronic device is inside of a sealed container (Reunamaki: FIG 5, In FIG. 5 a system, method and a result of execution of computer program instructions for transmitting a wireless flashing event to at least one or more electronic devices and to direct the transfer of firmware/software update on at least one or more devices is illustrated, in accordance with the exemplary embodiments of this invention. As shown in that system, a wireless flashing initiator 100 sends out a flashing event 155 directed at one or more electronic devices contained within sale packing (Paragraph 59).) .
In regards to claim 13, the combination of Reunamaki and Vanderveen and MOMCHILOV teach the method of claim 1, wherein the power source is an inductive power source (Reunamaki: An additional embodiment of the present invention include a wireless charging unit 1522 for receiving a remote energy charge from a wireless charger 1500A, which can be an inductive wireless charger (Paragraph 153).).
In regards to claim 14, the combination of Reunamaki and Vanderveen and MOMCHILOV teach the method of claim 1, wherein the device identifier is provided to the electronic device by a point of manufacture (POM) device (Reunamaki: The device could be prompted to provide an electronic identifier (ID) which would reveal the country of origin of the device so that counterfeit goods can be identified (Paragraph 43), which suggests that the identifier was provided to the device by a point of manufacture device at its country or origin.).
In regards to claim 15, Reunamaki teaches a non-transitory computer-readable medium storing a plurality of instructions that, when executed by one or more processors of an electronic device, cause the one or more processors to perform operations comprising:
exiting a shelf-life mode and turning on a peer-to-peer wireless protocol in response to detecting a power source (Reunamaki: As non-limiting examples waking-up the devices can be done using low power radio technologies such as BT LE, NFC, or a wireless recharging loop (Paragraph 179) to initiate a wireless flashing, which refers to a wireless interaction between one or more electronic devices that can include remote booting, data transfer, and installation of software or firmware updates (Paragraph 42).);
providing, via the peer-to-peer wireless protocol, a device identifier the electronic device to a host device (Reunamaki: In response to a wireless flashing event, the device could be prompted to provide an electronic identifier (ID) (Paragraph 43).);
receiving, via the peer-to-peer wireless protocol from the host device, a connection ticket authorizing the electronic device to connect to a wide area network, (Reunamaki: the wireless flashing initiator (WFI) sends relevant settings data to the EDM 200 such as the name of a secure communication network, the service set identifier (SSID) of the access point, security settings, security keys and key indexes (Paragraph 57).);
requesting, responsive to the connection ticket, a connection from an access point identified by the connection ticket to the wide area network using a network wireless protocol (Reunamaki: After receiving connectivity information from the WFI, the device uses the access point to connect with the communication network (Paragraph 57-58).) ; and
performing a software update over the wide area network via the access point (Reunamaki: Additional information can be sent to the EDM 200 to allow access to the electronic device manufacturer's server or an affiliated party to provide firmware and/or software updated via a predetermined WLAN (Paragraph 57).) .
However, Reunamaki does not explicitly teach… receiving, via the peer-to-peer wireless protocol from the host device, a connection ticket authorizing the electronic device to connect to a wide area network, the connection ticket being generated by a server system using a private key of the server system, wherein the connection ticket comprises a received device identifier associated with the electronic device;
Vanderveen, in the same field of endeavor, teaches a ticket-based authentication method that discloses… receiving, via the peer-to-peer wireless protocol from the host device, a connection ticket authorizing the electronic device to connect to a wide area network, the connection ticket being generated by a server system using a private key of the server system, wherein the connection ticket comprises a received device identifier associated with the electronic device (Vanderveen: A module for transmits an authorization ticket certified by a trusted party to the device (Paragraph 18), where the authorization ticket can include various information such as a device identifier, a validity period, a cryptographic signature an authorization server, as well as other information (Paragraph 55).) ;
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the connectivity information received from the Wireless Flashing Initiator as taught by Reunamaki with the authorization ticket taught by Vanderveen. The motivation to do so would be to ensure that only authorized devices are allowed to connect to the access point.
Both references do not explicitly teach, however, MOMCHILOV discloses verifying, by the electronic device, the connection ticket using the device identifier of the electronic device and the received device identifier; and connecting, responsive to the verifying the connection ticket to the wide area network identified by the connection ticket using a network wireless protocol. (see para. [0082]-[0083], ] Delivery Services Authentication Token (DSAuthT), CL, Polymorphic AuthT (polymorphic authentication token), mini-CL (validateSessionResult with status Redirect-Target), and gateway 263 connection ticket (GCT)…, Polymorphic AuthT, mini-CL, GCT may be in signed JSON objects of the form: manifest (clear)—includes user-device identity; payload (may be encrypted depending on type); symmetric key encrypted for entity (if payload is encrypted); and signature on manifest plus payload. DSAuthT is a primary token unless otherwise specified as a secondary token providing constrained access to a specific service, e.g., DSAuthT-WS-CLIS, Para [0092]–[0094], [0107]-[0117], The gateway 263 creates a Gateway Connection Ticket (GCT) with info from CL and validateSessionResult mini-CL as follows. A manifest (clear) includes: expiration time—consistent with CL expiration time; user identity—user universal claims (OID, SID, UPN, e-mail); customer ID; and device identity—Device ID, Endpoint Pub Key Thumbprint. The CGT may further include: Payload (clear)—Resource Location, VDA IP and port, etc.; signature—Sign GCT with GW POP Priv Key. The client device 252 uses the GCT and Resource Connection Ticket to authorize the connection at gateway 263 and virtual delivery appliance 253) Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teaching of Ratnamani and Vanderveen with MOMCHILOV in order to provide to enable secure remote connections by creating connection tickets that include device and resource identity information (see para. [0108], MOMCHILOV).
In regards to claim 16, the combination of Reunamaki and Vanderveen and MOMCHILOV teach the non-transitory computer-readable medium of claim 15, wherein the device identifier is provisioned to an authentication list of the server system prior to the electronic device exiting the shelf-life mode (Reunamaki: FIG2, The microcontroller 120 derives the electronic device's IMEI and MAC address by accessing memory 130 contained within the wireless flashing initiator 100. Memory 130 contains a list of known accessible Bluetooth low energy (BT LE) devices in a so-called white list 135 as well as their corresponding barcode number (not shown). Alternatively, the microcontroller 120 can access a communication network by way of a broadband radio via a wireless local area network (WLAN) to remotely access an over the air server containing the above described data hosted by the electronic device manufacturer (Paragraph 50).) .
In regards to claim 18, 22, the combination of Reunamaki and Vanderveen and MOMCHILOV teach the limitations recited of claim 15, wherein the connection ticket includes a message and a signature of the message, the signature generated using the private key of the server system (Vanderveen: FIG3, the authorization ticket 400 includes a device identifier and cryptographic signature of the authorization server covering the entire ticket data (Paragraph 69).),
wherein verifying the connection ticket comprises: verifying the signature using the message and a public key that corresponds to the private key of the server system (Vanderveen: A part of the authorization ticket creation can include the generation of a cryptographic signature on which the validity of the authorization ticket relies (Paragraph 111).
In regards to claim 19, Reunamaki teaches a system, comprising: a memory configured to store a plurality of instructions; and one or more processors configured to access the memory, and to execute the plurality of instructions to cause an electronic device to:
exit a shelf-life mode and turning on a peer-to-peer wireless protocol in response to detecting a power source (Reunamaki: As non-limiting examples waking-up the devices can be done using low power radio technologies such as BT LE, NFC, or a wireless recharging loop (Paragraph 179) to initiate a wireless flashing, which refers to a wireless interaction between one or more electronic devices that can include remote booting, data transfer, and installation of software or firmware updates (Paragraph 42).);
provide, via the peer-to-peer wireless protocol, a device identifier the electronic device to a host device (Reunamaki: In response to a wireless flashing event, the device could be prompted to provide an electronic identifier (ID) (Paragraph 43).);
receive, via the peer-to-peer wireless protocol from the host device, a connection ticket authorizing the electronic device to connect to a wide area network, (Reunamaki: the wireless flashing initiator (WFI) sends relevant settings data to the EDM 200 such as the name of a secure communication network, the service set identifier (SSID) of the access point, security settings, security keys and key indexes (Paragraph 57).);
request, responsive to the connection ticket, a connection from an access point identified by the connection ticket to the wide area network using a network wireless protocol (Reunamaki: After receiving connectivity information from the WFI, the device uses the access point to connect with the communication network (Paragraph 57-58).) ; and
perform a software update over the wide area network via the access point (Reunamaki: Additional information can be sent to the EDM 200 to allow access to the electronic device manufacturer's server or an affiliated party to provide firmware and/or software updated via a predetermined WLAN (Paragraph 57).) .
However, Reunamaki does not explicitly teach… receive, via the peer-to-peer wireless protocol from the host device, a connection ticket authorizing the electronic device to connect to a wide area network, the connection ticket being generated by a server system using a private key of the server system, wherein the connection ticket comprises a received device identifier associated with the electronic device;
Vanderveen, in the same field of endeavor, teaches a ticket-based authentication method that discloses… receive, via the peer-to-peer wireless protocol from the host device, a connection ticket authorizing the electronic device to connect to a wide area network, the connection ticket being generated by a server system using a private key of the server system, wherein the connection ticket comprises a received device identifier associated with the electronic device (Vanderveen: A module for transmits an authorization ticket certified by a trusted party to the device (Paragraph 18), where the authorization ticket can include various information such as a device identifier, a validity period, a cryptographic signature an authorization server, as well as other information (Paragraph 55).) ;
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the connectivity information received from the Wireless Flashing Initiator as taught by Reunamaki with the authorization ticket taught by Vanderveen. The motivation to do so would be to ensure that only authorized devices are allowed to connect to the access point.
Both references do not explicitly teach, however, MOMCHILOV discloses verifying, by the electronic device, the connection ticket using the device identifier of the electronic device and the received device identifier; and connecting, responsive to the verifying the connection ticket to the wide area network identified by the connection ticket using a network wireless protocol. (see para. [0082]-[0083], ] Delivery Services Authentication Token (DSAuthT), CL, Polymorphic AuthT (polymorphic authentication token), mini-CL (validateSessionResult with status Redirect-Target), and gateway 263 connection ticket (GCT)…, Polymorphic AuthT, mini-CL, GCT may be in signed JSON objects of the form: manifest (clear)—includes user-device identity; payload (may be encrypted depending on type); symmetric key encrypted for entity (if payload is encrypted); and signature on manifest plus payload. DSAuthT is a primary token unless otherwise specified as a secondary token providing constrained access to a specific service, e.g., DSAuthT-WS-CLIS, Para [0092]–[0094], [0107]-[0117], The gateway 263 creates a Gateway Connection Ticket (GCT) with info from CL and validateSessionResult mini-CL as follows. A manifest (clear) includes: expiration time—consistent with CL expiration time; user identity—user universal claims (OID, SID, UPN, e-mail); customer ID; and device identity—Device ID, Endpoint Pub Key Thumbprint. The CGT may further include: Payload (clear)—Resource Location, VDA IP and port, etc.; signature—Sign GCT with GW POP Priv Key. The client device 252 uses the GCT and Resource Connection Ticket to authorize the connection at gateway 263 and virtual delivery appliance 253) Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teaching of Ratnamani and Vanderveen with MOMCHILOV in order to provide to enable secure remote connections by creating connection tickets that include device and resource identity information (see para. [0108], MOMCHILOV).
Claim(s) 8, 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Reunamaki et al. (US-20130326495-A1) in view of Vanderveen et al (US-20130227655-A1) and in view of MOMCHILOV et al, (US 20200374121).as applied to claim 1 above, and further in view of Truskovsky et al (US-20160285869-A1).
In regards to claim 8, the combination of Reunamaki and Vanderveen and MOMCHILOV teach method of claim 1,
Although, the combination of Reunamaki and Vanderveen and MOMCHILOV teach two devices exchanging digital certificates for identity verification (Vanderveen: Paragraph 78), they do not explicitly teach… wherein the software update is performed after the server system verifies a device certificate, but
However, Truskovsky, in the same field of endeavor, teaches a system and method for secure activation of wireless devices that disclose … wherein the software update is performed after the server system verifies a device certificate (Truskovsky: After the server identity has been verified by the device, the device may carry out the pre-setting instructions (Paragraph 133), where pre-setting instructions may include instructions to cause the device to pre-install one or more applications on the device (e.g., the device may be able to access a corporate website to download and install application(s) and/or may be able to accept application(s) pushed by the server) (Paragraph 81).) .
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to substitute the certificate exchange between the server and device as taught by Truskovsky with the certificate exchange between two devices as taught by the combination of Reunamaki and Vanderveen and MOMCHILOV. The motivation to do so would be to yield the predictable results of achieving identity authentication so that the device can ensure that the software update is coming from a trusted party .
In regards to claim 10 and 20, the combination of Reunamaki and Vanderveen and MOMCHILOV teach method of claim 1, wherein performing the software update further comprises:
performing the software update over the wide area network via wide area network; (Reunamaki : An over the air server maintained by the electronic device manufacturer or an authorized affiliated party provides the firmware or software updates, which can be accessible to at least one of the above described communication networks via an access point (Paragraph 58).).
Although, the combination of Reunamaki and Vanderveen and MOMCHILOV teach two devices exchanging digital certificates for identity verification (Vanderveen: Paragraph 78), they do not explicitly teach… receiving, via the network wireless protocol, a server certificate from the server system, the server certificate received via the access point that is in communication with the server system; verifying the server certificate; providing, via the wide area network, a device certificate to the server system in response to verifying the server certificate.
Truskovsky, in the same field of endeavor, teaches a system and method for secure activation of wireless devices that disclose … receiving, via the network wireless protocol, a server certificate from the server system, the server certificate received via the access point that is in communication with the server system (Truskovsky: The device receives an activation request pushed to the device by the server, which may include a server certificate (Paragraph 130).)
verifying the server certificate (Truskovsky: The device may verify the server certificate, for example to verify the identity of the server requesting activation (Paragraph 132).) ;
providing, via the wide area network, a device certificate to the server system in response to verifying the server certificate (Truskovsky: The device may provide its device certificate to the server, in order to verify its own as part of a mutually exchanging certificates for establishing an authenticated communication session (Paragraph 135).) ;
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to substitute the certificate exchange between the server and device as taught by Truskovsky with the certificate exchange between two devices as taught by the combination of Reunamaki and Vanderveen and MOMCHILOV. The motivation to do so would be to yield the predictable results of achieving identity authentication so that the device can ensure that the software update is coming from a trusted party.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Burd et al. (US 2019/0045021 directed to home and small business security is dominated by technology suppliers who build comprehensive ‘closed’ security systems, where the individual components (sensors, security panels, keypads) operate solely within the confines of a single vendor solution.
Simkhada et al (US 11552803) directed to components that are capable of communicating with a remote system over a network. The component manufacturer may then send the components to one or more device manufacturers, which install the components into various devices. A device may include, but is not limited to, a voice-enabled device, an Internet of Thing (IoT) device, an appliance (e.g., a microwave, a refrigerator, a dishwasher, an oven, etc.), a television, a toy, a game, an object, and/or any other type of product which a component may be installed. After creating the devices, the one or more device manufacturers may provide the devices to businesses, companies, online marketplaces, users, and/or so forth
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Shewaye Gelagay whose telephone number is (571)272-4219. The examiner can normally be reached Monday to Friday 8 A.M. - 4 P.M..
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, Amy C. Johnson can be reached at (571) 272-2238. 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.
/SHEWAYE GELAGAY/ Supervisory Patent Examiner, Art Unit 2436