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 .
Response to Arguments
The present action is responsive communications that was filed on 01/22/2026. Independent claims 1, 10, 15, and 21 have been amended. Dependent claims 2-9, 11-14, 16-20, and 22-29 have also been amended. Claims 1-29 are currently pending.
Applicant’s arguments and amendments, on pages 9-19 , filed on 01/22/2026, with respect to claim 1, 4-5, 10, 12-13, 18-19, 21, and 23-24 in view of Lear et al. (US-20190319953-A1) in view of Sheth et al. (US-20200322356-A1), Tang et al. (US-20180077065-A1), and Rollet et al. (US-20160337333-A1) have been fully considered and are been fully persuasive. Therefore, the rejection have been withdrawn. However, upon further consideration, a new grounds of rejection is made of additional view Ektare et al. (US PGPub No. 20190098028-A1), Oberheide et al. (US PGPub No. 20150046989-A1), Falkenberg et al. (US PGPub No. 20160357537-A1), and Choudhury et al. (US PGPub No. 20120166483-A1).
The office action has been updated reflecting the claims as currently presented.
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.
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.
Claims 1, 8, 10, 15, 17, 19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Lear et al. (US-20190319953-A1) in view of Sheth et al. (US-20200322356-A1), Ektare et al. (US PGPub No. 20190098028-A1), and Oberheide et al. (US PGPub No. 20150046989-A1).
With respect to claim 1, Lear teaches a method for obtaining a manufacturer usage description (MUD) file, (Abstract: Techniques for providing secure modification of manufacturer usage description (MUD) files based on device applications are provided. In one embodiment, a method of secure modification of MUD files may include obtaining a request for one or more applications from a device. The method also includes providing to the device the one or more applications and a certification that includes an updated MUD identifier determined based on the one or more applications requested.) implemented by a MUD controller, comprising: (¶0017: As seen in Figure 1 is a diagram showing an example of a system 100 in which techniques for providing secure modification of MUD files based on device applications may be implemented. In this embodiment, system 100 includes an enterprise 110 that may communicate over communication network 130 with remote devices, including at least manufacturer application service 140 and a MUD file server 150. The enterprise network 110 includes at least network device 112 (also referred to as device 112), an access control device 114, a MUD controller 116, an authentication entity 118, and an authentication, authorization, and accounting (AAA) server 120.);
verifying validity of a first MUD uniform resource locator (URL) based on a certificate from a terminal device; obtaining a first MUD file based on the verified first MUD URL; (¶0041: As illustrated in Figure 1, device 112 may use its initial device identifier (e.g., IDevID or LDevID) with a security authentication protocol, such as Transport Layer Security (TLS), IEEE 802.1X/EAP-TLS, Internet Key Exchange (IKEv2), or other acceptable security protocol, to authenticate itself to network 110 during installation or onboarding. For example, at an operation 502, device 112 may provide its certificate or other initial device identifier to access control device 114. The initial certification for device 112, such as the initial device identifier or certificate (e.g., IDevID or LDevID), may include a MUD identifier. The MUD identifier (e.g., MUD URI) identifies the appropriate MUD file for device 112. At an operation 503, access control device 114 provides the MUD identifier (e.g., MUD URI) associated with the MUD file for the device (e.g., MUD file 152) to MUD controller 116. );
Lear does not disclose:
MUD uniform resource locator (URL)
Although, the prior art of Lear discloses the obtaining MUD files through the verification of MUD URI, but the prior does not explicitly disclose the use of MUD uniform resource locator (URL). However, Sheth teaches MUD uniform resource locator (URL) (¶0104-0105: As seen in Figure 6,at S600, destination node 116 (e.g., a network switch or a router to which an IoT device is attempting a connection) receives a MUD fetch URL from source node 202 (e.g., an IoT device, which can be any known or to be developed IoT device such as a sensor, etc.) through any one or more networking protocols).
Although the prior art of Lear had explicitly suggested employing the method for obtaining MUD files through the verification of a MUD URIs. A second reference of Sheth had described the use of MUD URLs for verification. Thus, it would have been obvious to one of ordinary skill in the art to replace the prior art of using MUD URI with using MUD URL to obtain MUD files, because one of ordinary skill in the art would have carry out such as substitution, and the results were reasonably predicable as seen in In re O’Farrell, 853 F.2d 894, 7 USPQ2d 1673 (Fed. Cir. 1988).
Lear in view of Sheth does not disclose:
receiving, from the terminal device, a message carrying a second MUD URL and not carrying the certificate,
wherein the second MUD URL is used to obtain an updated second MUD file when the terminal device is updated; and
However, Ektare teaches receiving, from the terminal device, a message carrying a second MUD URL and not carrying the certificate, (¶0196: Figure 15 depicts a flowchart 1500 of another example a method for generating device profiles of IoT devices through packet inspection for use in assessing risk levels of the IoT devices. The flowchart 1500 begins at module 1502, where data packets transmitted to and from IoT devices such as the data flow management engine described in this paper, can obtain data packets transmitted to and from IoT devices. ¶0039 Further in Figure 1, the IoT devices 104 are intended to represent devices with or wireless interfaces through which the IoT devices 104 can send and receive data over wired and wireless. The IoT devices 104 can include unique identifiers which can be used in transmission of data through a network. );
wherein the second MUD URL is used to obtain an updated second MUD file when the terminal device is updated; and (¶0199: The flowchart 1500 continues to module 1508, where device profiles of the IoT devices are created or updated based on the event logs. An applicable engine for profiling the IoT devices, such as the IoT device profiling engines described in this paper, can function to create/update device profiles of the IoT devices based on the event logs.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Ektare with regards to the retrieval of a message from the terminal device to the method of Lear in view of Sheth in order to enable the management of access (Ektare: ¶0049).
Lear in view of Sheth and Ektare does not disclose:
in response to the first MUD URL and the second MUD URL meeting a matching rule, determining the second MUD URL is valid and obtaining the second MUD file based on the second MUD URL,
wherein the matching rule derives verification of the second MUD URL based on matching one or more characteristics common to the verified first MUD URL and the second MUD URL, and wherein meeting the matching rule is accomplished without updating or reissuing the certificate.
However, Oberheide teaches in response to the first MUD URL and the second MUD URL meeting a matching rule, (¶0038: When applied to verifying updating of an authentication device instance, the method can include the initial set up of authentication credentials and then the establishment of authentication credentials (first MUD URL and the second URL) with a second authentication device instance if the device profile comparison is confirmed to be successful (i.e., satisfy a condition of the device profiles matching) (meeting matching rule) , which functions to facilitate enrollment of a new authentication device instance. );
determining the second MUD URL is valid and obtaining the second MUD file based on the second MUD URL, (¶0038-0043: If an enrollment request or authentication request is received for a particular account, a corresponding device profile can be identified. In another variation, the mapping is from a particular authentication device identifier and a device profile. The authentication device identifier may additionally be associated with a set of accounts (such that the device profile and the first account are associated through the authentication application identifier));
wherein the matching rule derives verification of the second MUD URL based on matching one or more characteristics common to the verified first MUD URL and the second MUD URL, and wherein meeting the matching rule is accomplished without updating or reissuing the certificate. (¶0035: As seen in Figure 1, the device authentication service 130 can additionally include a device profile comparison module. The device profile comparison module functions as a comparison engine to compare a stored device profile to a new device profile. The comparison module outputs a result that indicates if the device profiles correspond. The criteria for correspondence can include a match percentage, a likelihood of matching. In one variation, an administrator (e.g., a developer in a multitenant platform) using the device authentication service 130 may specify a policy for the matching. The policy may specify a threshold for a match. The policy may specify define a set of conditions that depend on multiple device profile vectors.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Oberheide with regards to the matching rule to the method of Lear in view of Sheth and Ektare in order to increase security (by adding an security check such as a policy) and prevent attackers from tampering (Oberheide: ¶0038).
With respect to claim 8, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 1 (see rejection of claim 1 above) comprising obtaining the matching rule from the certificate or obtaining the matching rule from the first MUD file. (Oberheide ¶0035-0038: The device authentication service 130 can additionally include a device profile comparison module. The device profile comparison module functions as a comparison engine to compare a stored device profile to a new device profile. The comparison module outputs a result that indicates if the device profiles correspond. The criteria for correspondence can include a match percentage, a likelihood of matching. In one variation, an administrator (e.g., a developer in a multitenant platform) using the device authentication service 130 may specify a policy for the matching. The policy may specify a threshold for a match. When applied to verifying updating of an authentication device instance, the method can include the initial set up of authentication credentials and then the establishment of authentication credentials with a second authentication device instance if the device profile comparison is confirmed to be successful (i.e., satisfy a condition of the device profiles matching), which functions to facilitate enrollment of a new authentication device instance.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Oberheide with regards to the matching rule to the method of Lear in view of Sheth, Ektare, and Elhard in order to increase security (by adding an security check such as a policy) and prevent attackers from tampering (Oberheide: ¶0038).
With respect to claim 10, Lear teaches a method for obtaining a manufacturer usage description (MUD) file, (Abstract: Techniques for providing secure modification of manufacturer usage description (MUD) files based on device applications are provided. In one embodiment, a method of secure modification of MUD files may include obtaining a request for one or more applications from a device. The method also includes providing to the device the one or more applications and a certification that includes an updated MUD identifier determined based on the one or more applications requested. )
implemented by a terminal device, comprising: (¶0017: As seen in Figure 1 is a diagram showing an example of a system 100 in which techniques for providing secure modification of MUD files based on device applications may be implemented. In this embodiment, system 100 includes an enterprise 110 that may communicate over communication network 130 with remote devices, including at least manufacturer application service 140 and a MUD file server 150. The enterprise network 110 includes at least network device 112 (also referred to as device 112), an access control device 114, a MUD controller 116, an authentication entity 118, and an authentication, authorization, and accounting (AAA) server 120.);
sending, to a MUD controller, a certificate is for use by the MUD controller to verify validity of a first MUD uniform resource locator (URL) provided by the terminal device, and (¶0014: One way that the URI may be embedded with the device during manufacturing is within an X.509 certificate. An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify public key belongs to the user, computer or service identity contained within the certificate.);
to obtain a first MUD file based on the verified first MUD URL; (¶0041: As illustrated in Figure 1, device 112 may use its initial device identifier (e.g., IDevID or LDevID) with a security authentication protocol, such as Transport Layer Security (TLS), IEEE 802.1X/EAP-TLS, Internet Key Exchange (IKEv2), or other acceptable security protocol, to authenticate itself to network 110 during installation or onboarding. For example, at an operation 502, device 112 may provide its certificate or other initial device identifier to access control device 114. The initial certification for device 112, such as the initial device identifier or certificate (e.g., IDevID or LDevID), may include a MUD identifier. The MUD identifier (e.g., MUD URI) identifies the appropriate MUD file for device 112. At an operation 503, access control device 114 provides the MUD identifier (e.g., MUD URI) associated with the MUD file for the device (e.g., MUD file 152) to MUD controller 116. );
Lear does not disclose:
MUD uniform resource locator (URL)
Although, the prior art of Lear discloses the obtaining MUD files through the verification of MUD URI, but the prior does not explicitly disclose the use of MUD uniform resource locator (URL). However, Sheth teaches MUD uniform resource locator (URL) (¶0104-0105: As seen in Figure 6,at S600, destination node 116 (e.g., a network switch or a router to which an IoT device is attempting a connection) receives a MUD fetch URL from source node 202 (e.g., an IoT device, which can be any known or to be developed IoT device such as a sensor, etc.) through any one or more networking protocols).
Although the prior art of Lear had explicitly suggested employing the method for obtaining MUD files through the verification of a MUD URIs. A second reference of Sheth had described the use of MUD URLs for verification. Thus, it would have been obvious to one of ordinary skill in the art to replace the prior art of using MUD URI with using MUD URL to obtain MUD files, because one of ordinary skill in the art would have carry out such as substitution, and the results were reasonably predicable as seen in In re O’Farrell, 853 F.2d 894, 7 USPQ2d 1673 (Fed. Cir. 1988).
Lear in view of Sheth does not disclose:
obtaining a second MUD URL, based on an updating of the terminal device is for sending to the MUD controller to obtain from the MUD controller an updated second MUD file should meet; and sending, to the MUD controller, a message carrying the second MUD URL and not carrying the certificate
However, Ektare teaches obtaining a second MUD URL, based on an updating of the terminal device is for sending to the MUD controller to obtain from the MUD controller an updated second MUD file should meet; (¶0199: The flowchart 1500 continues to module 1508, where device profiles of the IoT devices are created or updated based on the event logs. An applicable engine for profiling the IoT devices, such as the IoT device profiling engines described in this paper, can function to create/update device profiles of the IoT devices based on the event logs.);
and sending, to the MUD controller, a message carrying the second MUD URL and not carrying the certificate (¶0196: Figure 15 depicts a flowchart 1500 of another example a method for generating device profiles of IoT devices through packet inspection for use in assessing risk levels of the IoT devices. The flowchart 1500 begins at module 1502, where data packets transmitted to and from IoT devices such as the data flow management engine described in this paper, can obtain data packets transmitted to and from IoT devices. ¶0039 Further in Figure 1, the IoT devices 104 are intended to represent devices with or wireless interfaces through which the IoT devices 104 can send and receive data over wired and wireless. The IoT devices 104 can include unique identifiers which can be used in transmission of data through a network. );
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Ektare with regards to the retrieval of a message from the terminal device to the method of Lear in view of Sheth in order to enable the management of access (Ektare: ¶0049).
Lear in view of Sheth and Ektare does not disclose:
receiving, from the MUD controller, the updated second MUD file based on the first MUD URL and the second MUD URL meeting a matching rule at the MUD controller,
wherein the matching rule derives verification of the second MUD URL based on matching one or more characteristics common to the verified first MUD URL and the second MUD URL, and wherein meeting the matching rule is accomplished without updating or reissuing the certificate.
However, Oberheide teaches receiving, from the MUD controller, the updated second MUD file based on the first MUD URL and the second MUD URL meeting a matching rule (¶0038: When applied to verifying updating of an authentication device instance, the method can include the initial set up of authentication credentials and then the establishment of authentication credentials (first MUD URL and the second URL) with a second authentication device instance if the device profile comparison is confirmed to be successful (i.e., satisfy a condition of the device profiles matching) (meeting matching rule) , which functions to facilitate enrollment of a new authentication device instance. ) at the MUD controller, (¶0038-0043: If an enrollment request or authentication request is received for a particular account, a corresponding device profile can be identified. In another variation, the mapping is from a particular authentication device identifier and a device profile. The authentication device identifier may additionally be associated with a set of accounts (such that the device profile and the first account are associated through the authentication application identifier));
wherein the matching rule derives verification of the second MUD URL based on matching one or more characteristics common to the verified first MUD URL and the second MUD URL, and wherein meeting the matching rule is accomplished without updating or reissuing the certificate. (¶0035: As seen in Figure 1, the device authentication service 130 can additionally include a device profile comparison module. The device profile comparison module functions as a comparison engine to compare a stored device profile to a new device profile. The comparison module outputs a result that indicates if the device profiles correspond. The criteria for correspondence can include a match percentage, a likelihood of matching. In one variation, an administrator (e.g., a developer in a multitenant platform) using the device authentication service 130 may specify a policy for the matching. The policy may specify a threshold for a match. The policy may specify define a set of conditions that depend on multiple device profile vectors.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Oberheide with regards to the matching rule to the method of Lear in view of Sheth and Ektare in order to increase security (by adding an security check such as a policy) and prevent attackers from tampering (Oberheide: ¶0038).
With respect to claim 15, Lear teaches a manufacturer usage description (MUD) controller, comprising: (¶0020-0022 : In some cases, MUD controller 116 may receive instructions, or request approval, from a network administrator for enterprise network 110. For example, in some embodiments, AAA server 120 may provide authentication and authorization functions for enterprise network 110. )
one or more processors; and a memory coupled with the one or more processors, wherein the memory stores programming instructions, that when executed by the one or more processors, (¶0079: Furthermore, an apparatus is provided comprising: a communication interface configured to enable network communications; and a processor coupled with the communication interface, and configured to: obtain (receive) a request for one or more applications from a device; provide (transmit) to the device the one or more applications and a certification that includes an updated manufacturer usage description (MUD) identifier determined based on the one or more applications requested; ) cause the MUD controller to: (¶0017: As seen in Figure 1 is a diagram showing an example of a system 100 in which techniques for providing secure modification of MUD files based on device applications may be implemented. In this embodiment, system 100 includes an enterprise 110 that may communicate over communication network 130 with remote devices, including at least manufacturer application service 140 and a MUD file server 150. The enterprise network 110 includes at least network device 112 (also referred to as device 112), an access control device 114, a MUD controller 116, an authentication entity 118, and an authentication, authorization, and accounting (AAA) server 120.);
verify validity of a first MUD uniform resource locator (URL) based on a certificate from a terminal device; obtain a first MUD file based on the verified first MUD URL; (¶0041: As illustrated in Figure 1, device 112 may use its initial device identifier (e.g., IDevID or LDevID) with a security authentication protocol, such as Transport Layer Security (TLS), IEEE 802.1X/EAP-TLS, Internet Key Exchange (IKEv2), or other acceptable security protocol, to authenticate itself to network 110 during installation or onboarding. For example, at an operation 502, device 112 may provide its certificate or other initial device identifier to access control device 114. The initial certification for device 112, such as the initial device identifier or certificate (e.g., IDevID or LDevID), may include a MUD identifier. The MUD identifier (e.g., MUD URI) identifies the appropriate MUD file for device 112. At an operation 503, access control device 114 provides the MUD identifier (e.g., MUD URI) associated with the MUD file for the device (e.g., MUD file 152) to MUD controller 116. );
Lear does not disclose:
MUD uniform resource locator (URL)
Although, the prior art of Lear discloses the obtaining MUD files through the verification of MUD URI, but the prior does not explicitly disclose the use of MUD uniform resource locator (URL). However, Sheth teaches MUD uniform resource locator (URL) (¶0104-0105: As seen in Figure 6,at S600, destination node 116 (e.g., a network switch or a router to which an IoT device is attempting a connection) receives a MUD fetch URL from source node 202 (e.g., an IoT device, which can be any known or to be developed IoT device such as a sensor, etc.) through any one or more networking protocols).
Although the prior art of Lear had explicitly suggested employing the method for obtaining MUD files through the verification of a MUD URIs. A second reference of Sheth had described the use of MUD URLs for verification. Thus, it would have been obvious to one of ordinary skill in the art to replace the prior art of using MUD URI with using MUD URL to obtain MUD files, because one of ordinary skill in the art would have carry out such as substitution, and the results were reasonably predicable as seen in In re O’Farrell, 853 F.2d 894, 7 USPQ2d 1673 (Fed. Cir. 1988).
Lear in view of Sheth does not disclose:
receive, from the terminal device, a message carrying a second MUD URL and not carrying the certificate, wherein the second MUD URL is used to obtain an updated second MUD file when the terminal device is updated; and
However, Ektare teaches receive, from the terminal device, a message carrying a second MUD URL and not carrying the certificate, (¶0196: Figure 15 depicts a flowchart 1500 of another example a method for generating device profiles of IoT devices through packet inspection for use in assessing risk levels of the IoT devices. The flowchart 1500 begins at module 1502, where data packets transmitted to and from IoT devices such as the data flow management engine described in this paper, can obtain data packets transmitted to and from IoT devices. ¶0039 Further in Figure 1, the IoT devices 104 are intended to represent devices with or wireless interfaces through which the IoT devices 104 can send and receive data over wired and wireless. The IoT devices 104 can include unique identifiers which can be used in transmission of data through a network. ) wherein the second MUD URL is used to obtain an updated second MUD file when the terminal device is updated; and (¶0199: The flowchart 1500 continues to module 1508, where device profiles of the IoT devices are created or updated based on the event logs. An applicable engine for profiling the IoT devices, such as the IoT device profiling engines described in this paper, can function to create/update device profiles of the IoT devices based on the event logs.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Ektare with regards to the retrieval of a message from the terminal device to the method of Lear in view of Sheth in order to enable the management of access (Ektare: ¶0049).
Lear in view of Sheth and Ektare does not disclose:
in response to the first MUD URL and the second MUD URL meeting a matching rule, determine the second MUD URL is valid and obtain the second MUD file based on the second MUD URL, wherein the matching rule derives verification of the second MUD URL based on matching one or more characteristics common to the verified first MUD URL and the second MUD URL, and wherein meeting the matching rule is accomplished without updating or reissuing the certificate.
However, Oberheide teaches in response to the first MUD URL and the second MUD URL meeting a matching rule, (¶0038: When applied to verifying updating of an authentication device instance, the method can include the initial set up of authentication credentials and then the establishment of authentication credentials (first MUD URL and the second URL) with a second authentication device instance if the device profile comparison is confirmed to be successful (i.e., satisfy a condition of the device profiles matching) (meeting matching rule) , which functions to facilitate enrollment of a new authentication device instance. );
determine the second MUD URL is valid and obtain the second MUD file based on the second MUD URL, (¶0038-0043: If an enrollment request or authentication request is received for a particular account, a corresponding device profile can be identified. In another variation, the mapping is from a particular authentication device identifier and a device profile. The authentication device identifier may additionally be associated with a set of accounts (such that the device profile and the first account are associated through the authentication application identifier));
wherein the matching rule derives verification of the second MUD URL based on matching one or more characteristics common to the verified first MUD URL and the second MUD URL, and wherein meeting the matching rule is accomplished without updating or reissuing the certificate. (¶0035: As seen in Figure 1, the device authentication service 130 can additionally include a device profile comparison module. The device profile comparison module functions as a comparison engine to compare a stored device profile to a new device profile. The comparison module outputs a result that indicates if the device profiles correspond. The criteria for correspondence can include a match percentage, a likelihood of matching. In one variation, an administrator (e.g., a developer in a multitenant platform) using the device authentication service 130 may specify a policy for the matching. The policy may specify a threshold for a match. The policy may specify define a set of conditions that depend on multiple device profile vectors.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Oberheide with regards to the matching rule to the method of Lear in view of Sheth and Ektare in order to increase security (by adding an security check such as a policy) and prevent attackers from tampering (Oberheide: ¶0038).
With respect to claim 19, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 15 (see rejection of claim 15 above) wherein the instructions, when further executed by the one or more processors, cause the MUD controller to verify the second MUD URL and the first MUD URL carried in the message have matching one or more characteristics.(Oberheide ¶0026 In many cases, a device profile is not a single identifying mechanism, but can be compared and correlated to other substantially similar device profiles. For example, a particular device profile may depend on when and what specific data is collected, but it may fulfill a device profile match when substantial overlap or matching conditions are satisfied.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Oberheide with regards to the matching rule to the method of Lear in view of Sheth, Ektare, and Elhard in order to increase security (by adding an security check such as a policy) and prevent attackers from tampering (Oberheide: ¶0038).
With respect to claim 21, Lear teaches a terminal device comprising: (¶0021: Enterprise network 110 can be configured to communicate with one or more remote computers and/or devices (terminal device) over communication network 130. Communication network 130 may be, for example, a local access network (LAN) or wide area network (WAN). Also, communication network 130 may be either wired, wireless, or a combination of wired and wireless. In an example embodiment, communication network 130 may be the Internet.).
one or more processors; and a memory coupled with the one or more processors, wherein the memory stores programming instructions, that when executed by the one or more processors, (¶0068: Manufacturer application service 140 includes an application storage device or server 720 that stores applications and other programs that may be requested by devices for downloading and/or installation to enable new, different, and/or additional functionality to the device. Manufacturer application service 140 also includes a main memory 730, such as a random access memory (RAM) or other dynamic storage device (e.g., dynamic RAM (DRAM), static RAM (SRAM), and synchronous DRAM (SD RAM)), coupled to the bus for storing information and instructions to be executed by processor 710.) cause the terminal device to: (¶0022: MUD controller 116 may be configured to implement one or more policies that provide rules regarding communication over communication network 130 by computers and/or devices on enterprise network 110. For example, a policy implemented by MUD controller 116 may provide rules that restrict access to or from device 112 outside of enterprise network 110. In some cases, access may also be restricted between various network devices within enterprise network 110.).
send a certificate to a manufacturer usage description (MUD) controller, (¶0041-0042 For example, at an operation 502, device 112 may provide its certificate or other initial device identifier to access control device 114. The initial certification for device 112, such as the initial device identifier or certificate (e.g., IDevID or LDevID), may include a MUD identifier. At an operation 504, MUD controller 116 may use the MUD identifier (e.g., MUD URI) provided by device 112 to request the associated MUD file (e.g., MUD file 152) from MUD file server 150.).
wherein the certificate is used by the MUD controller to verify validity of a first MUD uniform resource locator (URL) provided by the terminal device, (¶0014: One way that the URI may be embedded with the device during manufacturing is within an X.509 certificate. An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify public key belongs to the user, computer or service identity contained within the certificate.);
and to obtain a first MUD file based on the verified first MUD URL; (¶0038-0041: In this embodiment, device 112 may use its initial device identifier (e.g., IDevID or LDevID) with a security authentication protocol, such as Transport Layer Security (TLS), IEEE 802.1X/EAP-TLS, Internet Key Exchange (IKEv2), or other acceptable security protocol, to authenticate itself to network 110 during installation or onboarding. For example, at an operation 502, device 112 may provide its certificate or other initial device identifier to access control device 114. The initial certification for device 112, such as the initial device identifier or certificate (e.g., IDevID or LDevID), may include a MUD identifier. The MUD identifier (e.g., MUD URI) identifies the appropriate MUD file for device 112. At an operation 503, access control device 114 provides the MUD identifier (e.g., MUD URI) associated with the MUD file for the device (e.g., MUD file 152) to MUD controller 116.);
Lear does not disclose:
obtain a second MUD URL, based on an updating of the terminal device, for sending to the MUD controller to obtain from the MUD controller an updated second MUD file; send, to the MUD controller, a message carrying the second MUD URL and not carrying the certificates receiving, from the MUD controller,
However, Ektare teaches obtain a second MUD URL, based on an updating of the terminal device, for sending to the MUD controller to obtain from the MUD controller an updated second MUD file; (¶0199: The flowchart 1500 continues to module 1508, where device profiles of the IoT devices are created or updated based on the event logs. An applicable engine for profiling the IoT devices, such as the IoT device profiling engines described in this paper, can function to create/update device profiles of the IoT devices based on the event logs.);
send, to the MUD controller, a message carrying the second MUD URL and not carrying the certificates receiving, from the MUD controller, (¶0196: Figure 15 depicts a flowchart 1500 of another example a method for generating device profiles of IoT devices through packet inspection for use in assessing risk levels of the IoT devices. The flowchart 1500 begins at module 1502, where data packets transmitted to and from IoT devices such as the data flow management engine described in this paper, can obtain data packets transmitted to and from IoT devices. ¶0039 Further in Figure 1, the IoT devices 104 are intended to represent devices with or wireless interfaces through which the IoT devices 104 can send and receive data over wired and wireless. The IoT devices 104 can include unique identifiers which can be used in transmission of data through a network. );
Lear in view of Sheth and Ektare does not disclose:
the updated second MUD file based on the first MUD URL and the second MUD URL meeting a matching rule at the MUD controller,
wherein the matching rule derives verification of the second MUD URL based on matching one or more characteristics common to the verified first MUD URL and the second MUD URL, and wherein meeting the matching rule is accomplished without updating or reissuing the certificate.
However, Oberheide teaches the updated second MUD file based on the first MUD URL and the second MUD URL meeting a matching rule at the MUD controller, (¶0038-0043: If an enrollment request or authentication request is received for a particular account, a corresponding device profile can be identified. In another variation, the mapping is from a particular authentication device identifier and a device profile. The authentication device identifier may additionally be associated with a set of accounts (such that the device profile and the first account are associated through the authentication application identifier));
wherein the matching rule derives verification of the second MUD URL based on matching one or more characteristics common to the verified first MUD URL and the second MUD URL, and wherein meeting the matching rule is accomplished without updating or reissuing the certificate. (¶0035: As seen in Figure 1, the device authentication service 130 can additionally include a device profile comparison module. The device profile comparison module functions as a comparison engine to compare a stored device profile to a new device profile. The comparison module outputs a result that indicates if the device profiles correspond. The criteria for correspondence can include a match percentage, a likelihood of matching. In one variation, an administrator (e.g., a developer in a multitenant platform) using the device authentication service 130 may specify a policy for the matching. The policy may specify a threshold for a match. The policy may specify define a set of conditions that depend on multiple device profile vectors.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Oberheide with regards to the matching rule to the method of Lear in view of Sheth and Ektare in order to increase security (by adding an security check such as a policy) and prevent attackers from tampering (Oberheide: ¶0038).
Claims 2, 3, 11, 16, 17, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Lear et al. (US-20190319953-A1) in view of Sheth et al. (US-20200322356-A1), Ektare et al. (US PGPub No. 20190098028-A1), Oberheide et al. (US PGPub No. 20150046989-A1), and Polk et al. (US-20080065775-A1).
With respect to claim 2, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 1 (see rejection of claim 1 above), but does not disclose wherein the message further carries the digital signature of the second MUD URL, and the method further comprises verifying the second MUD URL based on the digital signature.
However, Polk teaches wherein the message further carries a digital signature of the second MUD URL, and (¶0033: For example, a SIP user agent (UA) can be a DHCP client receiving its location in the form of location data-URL, with a validated source included (via the digital signature). The SIP UA can then include its location-by-reference as a data-URL (including the digital signature) in a SIP message.);
the method further comprises verifying the second MUD URL based on the digital signature. (¶0037-0039: As further seen in Figure 3, if the location data-URL in the location data DHCP Option is digitally signed, the location server 22 is the creator of the location information, and the signer of the location data-URL (therefore it can be queried to verify the location data-URL is valid). The digital signature appended to the location data-URL can be verified by one or more applications or remote hosts.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Polk with regards to digital signature the method of Lear in view of Sheth, Ektare, and Oberheide in order to verify the source and the integrity (Polk: ¶0033).
With respect to claim 3, the combination of Lear in view of Sheth, Ektare, Oberheide, and Polk teaches the method of claim 2 (see rejection of claim 2 above), wherein verifying the second MUD URL based on the digital signature comprises: verifying the digital signature based on a public key carried in a manufacturer certificate corresponding to the terminal device. (Lear: ¶0014 & 0038- 0041 In such circumstances, the device, for example, device 112, may include a certificate or other device identifier that includes a MUD identifier (e.g., a MUD URI) associated with a modified initial MUD file for the device that includes one or more MUD file portions associated with each pre-loaded or pre-installed application on the device before it is on-boarded to the network and in ¶0014 further discloses an X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user).
With respect to claim 11, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 10 (see rejection of claim 10 above), but does not disclose wherein the message further carries a digital signature of the second MUD URL.
However, Polk teaches wherein the message further carries a digital signature of the second MUD URL. (¶0033: For example, a SIP user agent (UA) can be a DHCP client receiving its location in the form of location data-URL, with a validated source included (via the digital signature). The SIP UA can then include its location-by-reference as a data-URL (including the digital signature) in a SIP message.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Polk with regards to digital signature the method of Lear in view of Sheth, Ektare, and Oberheide in order to verify the source and the integrity (Polk: ¶0033).
With respect to claim 16, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 15 (see rejection of claim 15 above) but does not disclose wherein the message further carries the digital signature of the second MUD URL, and wherein the instructions, when further executed by the one or more processors, cause the MUD controller to verify the second MUD URL based on the digital signature.
However, Polk teaches wherein the message further carries the digital signature of the second MUD URL, and (¶0033: For example, a SIP user agent (UA) can be a DHCP client receiving its location in the form of location data-URL, with a validated source included (via the digital signature). The SIP UA can then include its location-by-reference as a data-URL (including the digital signature) in a SIP message.);
wherein the instructions, when further executed by the one or more processors, cause the MUD controller to verify the second MUD URL based on the digital signature.(¶0037-0039: As further seen in Figure 3, if the location data-URL in the location data DHCP Option is digitally signed, the location server 22 is the creator of the location information, and the signer of the location data-URL (therefore it can be queried to verify the location data-URL is valid). The digital signature appended to the location data-URL can be verified by one or more applications or remote hosts.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Polk with regards to digital signature the method of Lear in view of Sheth, Ektare, and Oberheide in order to verify the source and the integrity . (Polk: ¶0033).
With respect to claim 17, the combination of Lear in view of Sheth, Ektare, Oberheide, and Polk teaches the method of claim 16 (see rejection of claim 16 above) wherein the instructions that when further executed by the one or more processors to processor further cause the MUD controller to: verify the digital signature based on a public key carried in a manufacturer certificate corresponding to the terminal device. (Lear: ¶0014 & 0038- 0041 In such circumstances, the device, for example, device 112, may include a certificate or other device identifier that includes a MUD identifier (e.g., a MUD URI) associated with a modified initial MUD file for the device that includes one or more MUD file portions associated with each pre-loaded or pre-installed application on the device before it is on-boarded to the network and in ¶0014 further discloses an X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user).
With respect to claim 22, the combination of Lear in view of Sheth , Ektare, and Oberheide teaches the method of claim 21 (see rejection of claim 21 above) but does not disclose wherein the message further carries a digital signature of the second MUD URL.
However, Polk teaches wherein the message further carries a digital signature of the second MUD URL. ¶0033: For example, a SIP user agent (UA) can be a DHCP client receiving its location in the form of location data-URL, with a validated source included (via the digital signature). The SIP UA can then include its location-by-reference as a data-URL (including the digital signature) in a SIP message.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Polk with regards to digital signature the method of Lear in view of Sheth, Ektare, and Oberheide in order to verify the source and the integrity . (Polk: ¶0033).
Claims 4, 5, 12, 13, 18, 23, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Lear et al. (US-20190319953-A1) in view of Lear et al. (US-20190319953-A1) in view of Sheth et al. (US-20200322356-A1), Ektare et al. (US PGPub No. 20190098028-A1), Oberheide et al. (US PGPub No. 20150046989-A1), and Elhard et al. (US-9985947-B1).
With respect to claim 4, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 1 (see rejection of claim 1 above), does not disclose wherein the message carries the first MUD URL.
However, Elhard teaches wherein the message carries the first MUD URL. (¶0031: In step 408, the relay server authenticates the primary device connecting via the primary URL. The primary device may be authenticated by one or more means, including, but not limited to: pre-configuring device-specific access permissions within the relay server (e.g. a local access control list), pre-configuring device-specific access permissions through a common intermediary device (e.g. via a Mac-address access control list on a router), preconfiguring network-specific access permissions through a common intermediary device (e.g. via an IP-based policy on a firewall); and/or dynamic verification of the primary token upon receipt of a connection request (e.g. via static, synchronous dynamic, asynchronous or challenge-response password implementations). In step 410, the relay server stands by for an incoming connection request from the secondary device, in accordance with one or more embodiments of the invention. The relay server uses the mapping in the data structure to match the secondary URL with the corresponding primary URL, upon receipt of the connection request from the secondary device, in accordance with Figure 2.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Elhard with regards to the first MUD URL to the method of Lear in view of Sheth, Ektare, and Oberheide in order to prevent exposure to security vulnerabilities and offer a secure approach to give user/device access to an network (Elhard: ¶0002).
With respect to claim 5, the combination of Lear in view of Sheth, Ektare, Oberheide, and Elhard teaches the method of claim 4 (see rejection of claim 4 above), the method further comprises: obtaining the certificate from the first message; and (Lear ¶0014-0015: One way that the URI may be embedded with the device during manufacturing is within an X.509 certificate. An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate. The standard is defined in Section 10 of The Internet Engineering Task Force (IETF) publication draft-ietf-opsawg-mud-11, which publication is hereby incorporated by reference in its entirety. When a device emits an X.509 certificate containing a MUD URI, the network infrastructure can resolve the MUD URI, and, if acceptable to the network, install the defined access control policy on a switch access port connected to the device before the port is opened to the network.);
verifying that the second MUD URL and the first MUD URL carried in the message certificate ( Lear ¶0052: An example of a request from device 112 for an updated device identifier from authentication entity 118 may be shown in the table below the paragraph where the authentication entity uses the certificate from the first MUD URL for verification) meet the matching rule have matching one or more characteristics. (Oberheide ¶0026 In many cases, a device profile is not a single identifying mechanism, but can be compared and correlated to other substantially similar device profiles. For example, a particular device profile may depend on when and what specific data is collected, but it may fulfill a device profile match when substantial overlap or matching conditions are satisfied.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Oberheide with regards to the matching rule to the method of Lear in view of Sheth, Ektare, and Elhard in order to increase security (by adding an security check such as a policy) and prevent attackers from tampering (Oberheide: ¶0038).
With respect to claim 12, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 10 (see rejection of claim 10 above), but does not disclose wherein the message carries the first MUD URL
However, Elhard teaches wherein the message carries the first MUD URL.(¶0031: In step 408, the relay server authenticates the primary device connecting via the primary URL. The primary device may be authenticated by one or more means, including, but not limited to: pre-configuring device-specific access permissions within the relay server (e.g. a local access control list), pre-configuring device-specific access permissions through a common intermediary device (e.g. via a Mac-address access control list on a router), preconfiguring network-specific access permissions through a common intermediary device (e.g. via an IP-based policy on a firewall); and/or dynamic verification of the primary token upon receipt of a connection request (e.g. via static, synchronous dynamic, asynchronous or challenge-response password implementations). In step 410, the relay server stands by for an incoming connection request from the secondary device, in accordance with one or more embodiments of the invention. The relay server uses the mapping in the data structure to match the secondary URL with the corresponding primary URL, upon receipt of the connection request from the secondary device, in accordance with Figure 2.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Elhard with regards to the first MUD URL to the method of Lear in view of Sheth, Ektare, and Oberheide in order to prevent exposure to security vulnerabilities and offer a secure approach to give user/device access to an network (Elhard: ¶0002).
With respect to claim 13, the combination of Lear in view of Sheth, Ektare, Oberheide, and Elhard does teaches the method of claim 12 (see rejection of claim 12 above) wherein the first MUD URL in the message is used by the MUD controller to verify that the first MUD URL and the second MUD URL meet the matching rule. (Oberheide ¶0026 In many cases, a device profile is not a single identifying mechanism, but can be compared and correlated to other substantially similar device profiles. For example, a particular device profile may depend on when and what specific data is collected, but it may fulfill a device profile match when substantial overlap or matching conditions are satisfied.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Oberheide with regards to the matching rule to the method of Lear in view of Sheth, Ektare, and Elhard in order to increase security (by adding an security check such as a policy) and prevent attackers from tampering (Oberheide: ¶0038).
With respect to claim 18, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 15 (see rejection of claim 15 above) but does not disclose wherein the first message further carries the first MUD URL, and wherein the instructions when further executed by the one or more processors to processor further cause the MUD controller to obtain the first MUD URL from the first message and verify the second MUD URL and the first MUD URL meet the matching rule.
However, Elhard teaches wherein the first message further carries the first MUD URL, and wherein the instructions when further executed by the one or more processors to processor further cause the MUD controller to obtain the first MUD URL from the first message and verify the second MUD URL and the first MUD URL meet the matching rule. (¶0031: In step 408, the relay server authenticates the primary device connecting via the primary URL. The primary device may be authenticated by one or more means, including, but not limited to: pre-configuring device-specific access permissions within the relay server (e.g. a local access control list), pre-configuring device-specific access permissions through a common intermediary device (e.g. via a Mac-address access control list on a router), preconfiguring network-specific access permissions through a common intermediary device (e.g. via an IP-based policy on a firewall); and/or dynamic verification of the primary token upon receipt of a connection request (e.g. via static, synchronous dynamic, asynchronous or challenge-response password implementations). In step 410, the relay server stands by for an incoming connection request from the secondary device, in accordance with one or more embodiments of the invention. The relay server uses the mapping in the data structure to match the secondary URL with the corresponding primary URL, upon receipt of the connection request from the secondary device, in accordance with Figure 2.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Elhard with regards to the first MUD URL to the method of Lear in view of Sheth, Ektare, and Oberheide in order to prevent exposure to security vulnerabilities and offer a secure approach to give user/device access to an network (Elhard: ¶0002).
With respect to claim 23, the combination of Lear in view of Sheth , Rollet, and Tang teaches the method of claim 21 (see rejection of claim 21 above) but does not disclose wherein the message further carries the first MUD URL.
However, Elhard teaches wherein the message further carries the first MUD URL. (¶0031: In step 408, the relay server authenticates the primary device connecting via the primary URL. The primary device may be authenticated by one or more means, including, but not limited to: pre-configuring device-specific access permissions within the relay server (e.g. a local access control list), pre-configuring device-specific access permissions through a common intermediary device (e.g. via a Mac-address access control list on a router), preconfiguring network-specific access permissions through a common intermediary device (e.g. via an IP-based policy on a firewall); and/or dynamic verification of the primary token upon receipt of a connection request (e.g. via static, synchronous dynamic, asynchronous or challenge-response password implementations). In step 410, the relay server stands by for an incoming connection request from the secondary device, in accordance with one or more embodiments of the invention. The relay server uses the mapping in the data structure to match the secondary URL with the corresponding primary URL, upon receipt of the connection request from the secondary device, in accordance with Figure 2.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Elhard with regards to the first MUD URL to the method of Lear in view of Sheth, Ektare, and Oberheide in order to prevent exposure to security vulnerabilities and offer a secure approach to give user/device access to an network (Elhard: ¶0002).
With respect to claim 24, the combination of Lear in view of Sheth, Ektare, Oberheide, and Elhard teaches the method of claim 21 (see rejection of claim 23 above) wherein the first MUD URL in the message is used by the MUD controller to verify that the first MUD URL and the second MUD URL meet the matching rule. (Oberheide ¶0026 In many cases, a device profile is not a single identifying mechanism, but can be compared and correlated to other substantially similar device profiles. For example, a particular device profile may depend on when and what specific data is collected, but it may fulfill a device profile match when substantial overlap or matching conditions are satisfied.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Oberheide with regards to the matching rule to the method of Lear in view of Sheth, Ektare, and Elhard in order to increase security (by adding an security check such as a policy) and prevent attackers from tampering (Oberheide: ¶0038).
Claims 6, 14, 20, and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Lear et al. (US-20190319953-A1) in view of Lear et al. (US-20190319953-A1) in view of Sheth et al. (US-20200322356-A1), Ektare et al. (US PGPub No. 20190098028-A1), Oberheide et al. (US PGPub No. 20150046989-A1) , and Deriso et al. (US-20180007021-A1).
With respect to claim 6, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 1 (see rejection of claim 1 above) wherein the message further carries a URL of the certificate ( Lear ¶0014 & 0028: When a device emits an X.509 certificate containing a MUD URI, the network infrastructure can resolve the MUD URI, and, if acceptable to the network, install the defined access control policy on a switch access port connected to the device before the port is opened to the network. Wherein the authentication entity 118 may be a server or other device that is configured to issue certificates to devices on enterprise network 110. For example, in one embodiment, authentication entity 118 may be a Bootstrapping Remote Secure Key Infrastructures (BRSKI) registrar that is configured to issue X.509 certificates or provide other identity certification.);
Lear in view of Sheth, Ektare, and Oberheide does not disclose:
that indicates a location of the certificate in a network, and the method further comprises: obtaining the URL of the certificate from the message; obtaining the certificate based on the URL; and verifying that the second MUD URL and the first MUD URL carried in the obtained certificate have matching one or more characteristics.
However, Deriso teaches that indicates a location of the certificate in a network, and the method further comprises: (¶0042-0043: As seen in Figure 1, after verifying that the trust service 126 is using a server key 139 that has been signed by the preinstalled certificate 156, the management agent 149 can then query the trust service 126 for the SSL or TLS pinning settings for the private network 113. For example, the trust service 126 could provide the management agent 149 with the network location for the private SSL pinning service 129. The network location could correspond to an IP address or a pinning service URL 131.);
obtaining the URL of the certificate from the message; (¶0038-0041: As part of the connection process, the management service 119 can provide an SSL or TLS certificate to the management agent 149 to use to encrypt communications with management service 119. The certificate can include a server key 139. The management service 119 can also provide the network location of a trust service 126 that the management agent 149 can use to validate the public key provided by the management service 119.)
obtaining the certificate based on the URL; and verifying that the second MUD URL and the first MUD URL carried in the obtained certificate have matching one or more characteristics. (¶0038-0041: For example, the trust service 126 and management agent 149 could have been developed or deployed by the same entity (matching rule) . Accordingly, that entity would have the ability to cryptographically sign the certificate or server key 139 used by the trust service 126 with the preinstalled certificate 156 to generate a corresponding cryptographic signature.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Deriso regarding the certificate to the method of Lear in view of Sheth, Ektare, and Oberheide in order to mitigate man-in-the-middle attacks on communications between computing devices (Deriso ¶0008-00010).
With respect to claim 14, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 10 (see rejection of claim 10 above), wherein the message further carries a URL of the certificate used by the MUD controller to obtain the certificate, (Lear ¶0014 & 0028: When a device emits an X.509 certificate containing a MUD URI, the network infrastructure can resolve the MUD URI, and, if acceptable to the network, install the defined access control policy on a switch access port connected to the device before the port is opened to the network. Wherein the authentication entity 118 may be a server or other device that is configured to issue certificates to devices on enterprise network 110. For example, in one embodiment, authentication entity 118 may be a Bootstrapping Remote Secure Key Infrastructures (BRSKI) registrar that is configured to issue X.509 certificates or provide other identity certification.);
Lear in view of Sheth, Ektare, and Oberheide does not disclose:
wherein the obtained certificate carries the first MUD URL, and wherein the first MUD URL in the obtained certificate is used by the MUD controller to verify the first MUD URL and the second MUD URL meet the matching rule.
However, Deriso teaches wherein the obtained certificate carries the first MUD URL, and (¶0038-0041: As part of the connection process, the management service 119 can provide an SSL or TLS certificate to the management agent 149 to use to encrypt communications with management service 119. The certificate can include a server key 139. The management service 119 can also provide the network location of a trust service 126 that the management agent 149 can use to validate the public key provided by the management service 119.)
wherein the first MUD URL in the obtained certificate (¶0038-0041: The management agent 149 can first verify the identity of the trust service 126 by checking to see if the public key or SSL/TLS certificate provided by the trust service 126 has been previously signed with a copy of the preinstalled certificate 156.) is used by the MUD controller to verify the first MUD URL and the second MUD URL meet the matching rule. (¶0038-0041: As part of the connection process, the management service 119 can provide an SSL or TLS certificate to the management agent 149 to use to encrypt communications with management service 119. The certificate can include a server key 139. The management service 119 can also provide the network location of a trust service 126 that the management agent 149 can use to validate the public key provided by the management service 119.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Deriso regarding the certificate to the method of Lear in view of Sheth, Ektare, and Oberheide in order to mitigate man-in-the-middle attacks on communications between computing devices (Deriso ¶0008-00010).
With respect to claim 20, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 15 (see rejection of claim 15 above) wherein the message further carries a URL of the certificate ( Lear ¶0014 & 0028: When a device emits an X.509 certificate containing a MUD URI, the network infrastructure can resolve the MUD URI, and, if acceptable to the network, install the defined access control policy on a switch access port connected to the device before the port is opened to the network. Wherein the authentication entity 118 may be a server or other device that is configured to issue certificates to devices on enterprise network 110. For example, in one embodiment, authentication entity 118 may be a Bootstrapping Remote Secure Key Infrastructures (BRSKI) registrar that is configured to issue X.509 certificates or provide other identity certification.);
Lear in view of Sheth, Ektare, and Oberheide does not disclose:
that indicates a location of the certificate in a network, and wherein the instructions, when further executed by the one or more processors cause the MUD controller to: obtain the URL of the certificate from the message; obtain the certificate based on the URL; and verify that the second MUD URL and the first MUD URL carried in the obtained certificate have matching one or more characteristics.
However, Deriso teaches that indicates a location of the certificate in a network, and wherein the instructions, (¶0042-0043: As seen in Figure 1, after verifying that the trust service 126 is using a server key 139 that has been signed by the preinstalled certificate 156, the management agent 149 can then query the trust service 126 for the SSL or TLS pinning settings for the private network 113. For example, the trust service 126 could provide the management agent 149 with the network location for the private SSL pinning service 129. The network location could correspond to an IP address or a pinning service URL 131.)
when further executed by the one or more processors cause the MUD controller to: obtain the URL of the certificate from the message; (¶0038-0041: As part of the connection process, the management service 119 can provide an SSL or TLS certificate to the management agent 149 to use to encrypt communications with management service 119. The certificate can include a server key 139. The management service 119 can also provide the network location of a trust service 126 that the management agent 149 can use to validate the public key provided by the management service 119.)
obtain the certificate based on the URL; and (¶0038-0041: The management agent 149 can first verify the identity of the trust service 126 by checking to see if the public key or SSL/TLS certificate provided by the trust service 126 has been previously signed with a copy of the preinstalled certificate 156.) verify that the second MUD URL and the first MUD URL carried in the obtained certificate have matching one or more characteristics. (¶0038-0041: For example, the trust service 126 and management agent 149 could have been developed or deployed by the same entity (matching rule) . Accordingly, that entity would have the ability to cryptographically sign the certificate or server key 139 used by the trust service 126 with the preinstalled certificate 156 to generate a corresponding cryptographic signature.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Deriso regarding the certificate to the method of Lear in view of Sheth, Ektare, and Oberheide in order to mitigate man-in-the-middle attacks on communications between computing devices (Deriso ¶0008-00010).
With respect to claim 25, the combination of Lear in view of Sheth , Ektare, and Oberheide teaches the method of claim 21 (see rejection of claim 21 above) wherein the message further carries a URL of the certificate( Lear ¶0014 & 0028: When a device emits an X.509 certificate containing a MUD URI, the network infrastructure can resolve the MUD URI, and, if acceptable to the network, install the defined access control policy on a switch access port connected to the device before the port is opened to the network. Wherein the authentication entity 118 may be a server or other device that is configured to issue certificates to devices on enterprise network 110. For example, in one embodiment, authentication entity 118 may be a Bootstrapping Remote Secure Key Infrastructures (BRSKI) registrar that is configured to issue X.509 certificates or provide other identity certification.);
used by the MUD controller to obtain the certificate, wherein the certificate carries the first MUD URL, and wherein the first MUD URL in the certificate is used by the MUD controller to verify the first MUD URL and the second MUD URL meet the matching rule. (Oberheide ¶0026 In many cases, a device profile is not a single identifying mechanism, but can be compared and correlated to other substantially similar device profiles. For example, a particular device profile may depend on when and what specific data is collected, but it may fulfill a device profile match when substantial overlap or matching conditions are satisfied.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Oberheide with regards to the matching rule to the method of Lear in view of Sheth and Ektare in order to increase security (by adding an security check such as a policy) and prevent attackers from tampering (Oberheide: ¶0038).
Lear in view of Sheth, Ektare, and Oberheide does not disclose:
used by the MUD controller to obtain the certificate, wherein the certificate carries the first MUD URL, and wherein the first MUD URL in the certificate is used by the MUD controller to verify the first MUD URL and the second MUD URL meet the matching rule.
However, Deriso teaches used by the MUD controller to obtain the certificate, wherein the certificate carries the first MUD URL, and (¶0038-0041: The management agent 149 can first verify the identity of the trust service 126 by checking to see if the public key or SSL/TLS certificate provided by the trust service 126 has been previously signed with a copy of the preinstalled certificate 156.);
wherein the first MUD URL in the certificate is used by the MUD controller to verify the first MUD URL and the second MUD URL meet the matching rule. (¶0038-0041: For example, the trust service 126 and management agent 149 could have been developed or deployed by the same entity (matching rule) . Accordingly, that entity would have the ability to cryptographically sign the certificate or server key 139 used by the trust service 126 with the preinstalled certificate 156 to generate a corresponding cryptographic signature.)
It is noted that Oberheide does disclose the matching rule, but Oberheide does not have the inclusion of the certificate of the first MUD URL. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Deriso regarding the certificate to the method of Lear in view of Sheth, Ektare, and Oberheide in order to mitigate man-in-the-middle attacks on communications between computing devices (Deriso ¶0008-00010).
Claims 7 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Lear et al. (US-20190319953-A1) in view of Lear et al. (US-20190319953-A1) in view of Sheth et al. (US-20200322356-A1), Ektare et al. (US PGPub No. 20190098028-A1), Oberheide et al. (US PGPub No. 20150046989-A1), Elhard et al. (US-9985947-B1), and Pao et al. (US-20130061281-A1).
With respect to claim 7, the combination of Lear in view of Sheth, Ektare, Oberheide, and Elhard teaches the method of claim 5 (see rejection of claim 5 above) wherein the message further carries the first MUD URL, (Lear ¶0014: When a device emits an X.509 certificate containing a MUD URI, the network infrastructure can resolve the MUD URI, and, if acceptable to the network, install the defined access control policy on a switch access port connected to the device before the port is opened to the network).
and the method further comprises verifying the first MUD URL carried in the message is the same as the first MUD URL carried in the certificate.
Lear in view of Sheth, Ektare, Oberheide, and Elhard does not disclose:
verifying the first MUD URL carried in the first message is the same as the first MUD URL carried in the certificate.
However, Pao teaches verifying the first MUD URL carried in the first message (¶0006: The server certificate binds the server's public-key to the server name. For example, when accessing the URL http://www.xyz.com/first.html, the server sends a certificate that identifies the server as www.xyz.com.) is the same as the first MUD URL carried in the certificate (¶0026: When the client receives the server certificate it verifies (using a trusted root certificate store of the operating system or of the browser) that: the certificate is properly signed by a known Certificate Authority (such as VeriSign); and, the common name inside the certificate matches the domain name in the URL requested by the client.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Pao regarding the certificate to the method of Lear in view of Sheth, Ektare, Oberheide, and Elhard in order to guarantees and authenticity of information exchanged (Pao ¶0002-0010).
With respect to claim 26, the combination of Lear in view of Sheth , Ektare, Oberheide, and Elhard teaches the method of claim 24 (see rejection of claim 24 above) wherein the first MUD URL carried in the message (Lear ¶0014: When a device emits an X.509 certificate containing a MUD URI, the network infrastructure can resolve the MUD URI, and, if acceptable to the network, install the defined access control policy on a switch access port connected to the device before the port is opened to the network) is used by the MUD controller to verify the first MUD URL carried in the first message is the same as the first MUD URL carried in the certificate.
Lear in view of Sheth , Ektare, Oberheide, and Elhard but does not disclose:
is used by the MUD controller to verify the first MUD URL carried in the first message is the same as the first MUD URL carried in the certificate.
However, Pao teaches is used by the MUD controller (¶0006: The server certificate binds the server's public-key to the server name. For example, when accessing the URL http://www.xyz.com/first.html, the server sends a certificate that identifies the server as www.xyz.com.) to verify the first MUD URL carried in the first message is the same as the first MUD URL carried in the certificate. (¶0026: When the client receives the server certificate it verifies (using a trusted root certificate store of the operating system or of the browser) that: the certificate is properly signed by a known Certificate Authority (such as VeriSign); and, the common name inside the certificate matches the domain name in the URL requested by the client.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Pao regarding the certificate to the method of Lear in view of Sheth, Ektare, Oberheide, and Elhard in order to guarantees and authenticity of information exchanged (Pao ¶0002-0010).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Lear et al. (US-20190319953-A1) in view of Lear et al. (US-20190319953-A1) in view of Lear et al. (US-20190319953-A1) in view of Sheth et al. (US-20200322356-A1), Ektare et al. (US PGPub No. 20190098028-A1), Oberheide et al. (US PGPub No. 20150046989-A1), and Falkenberg et al. (US PGPub No. 20160357537-A1).
With respect to claim 9, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose wherein the matching rule is a URL prefix matching rule requiring the second MUD URL and the first MUD URL have a same prefix.
However, Falkenberg teaches wherein the matching rule is a URL prefix matching rule requiring the second MUD URL and the first MUD URL have a same prefix. (¶0018 If the prefix of the selected URL or URI matches a prefix in the validated list and the associated app is installed (as it should be) then the associated app is opened or launched/opened and the content of the URL or URI is displayed in the second app. The signed list is a cryptographically signed data structure which authenticates the list of URLs or URIs (in the signed list) as being authentic and authorized by the domain of the website. In one embodiment, a trusted system software component can validate the signed list before storing the URLs or URIs in an association with one or more applications including the first application such that the data structure can be considered to include only validated associations. )
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Falkenberg regarding the matching rules to the method of Lear in view of Sheth, Ektare, and Oberheide in order to prevent unauthorized access by enabling secure and trusted validation (Falkenberg ¶0018).
Claim 27 is rejected under 35 U.S.C. 103 as being unpatentable over Lear et al. (US-20190319953-A1) in view of Lear et al. (US-20190319953-A1) in view of Sheth et al. (US-20200322356-A1), Ektare et al. (US PGPub No. 20190098028-A1), Oberheide et al. (US PGPub No. 20150046989-A1), and Choudhury et al. (US PGPub No. 20120166483-A1).
With respect to claim 27, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose wherein the matching rule is a URL suffix matching rule requiring a to-be-verified MUD URL and a verified MUD URL have a same suffix.
However, Choudhury teaches wherein the matching rule is a URL suffix matching rule requiring a to-be-verified MUD URL and a verified MUD URL have a same suffix. (¶0142: In other embodiments, the application firewall 290 protects against forceful browsing by enforcing legal URLs. As further illustrated ¶0342-0342: In some embodiments, the appliance may then perform the getSuffix( )method referenced in FIG. 7A, which identifies a file type suffix of the requested URL. This method may also comprise determining a starting and ending point of the suffix in relation to the starting and ending point of the URL. The appliance may then use the starting and ending points of the suffix to perform any evaluations of the file suffix, such as comparing it to the string ".jsp" to determine if the requested URL corresponds to a Java Server Page.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Choudhury regarding the matching rule is URL suffix matching rule requirement to the method of Lear in view of Sheth, Ektare, and Oberheide in order to protect from illegitimate requests and denial of service attacks (Choudhury ¶0142).
Claim 28 is rejected under 35 U.S.C. 103 as being unpatentable over Lear et al. (US-20190319953-A1) in view of Sheth et al. (US-20200322356-A1), Ektare et al. (US PGPub No. 20190098028-A1), Oberheide et al. (US PGPub No. 20150046989-A1), and Tyler et al. (US-20170195310-A1).
With respect to claim 28, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose wherein the matching rule is a URL key information matching rule requiring a to-be-verified MUD URL and a verified MUD URL have same specific key information.
However, Tyler teaches wherein the matching rule is a URL key information matching rule requiring a to-be-verified MUD URL and (¶0069 Figure 7 illustrates an embodiment of the system that uses a blacklist and a whitelist to determine whether to allow access to a link. The Secure Resource Access Subsystem 460 contains a Blacklist 701 of domain names that are known or suspected to be malicious, and a Whitelist 702 of domain names that are known or presumed to be safe. An illustrative checking method is to allow access to all links with domains in the Whitelist, and block access to all links with domains in the Blacklist. One or more embodiments may have only one of a Whitelist or a Blacklist. One or more embodiments may use any form of identity for a web page instead of or in addition to a domain name. A web page identity may include for example, without limitation, a domain name for the associated website, a complete URLs for the web page, an IP address for the website, or information associated with or derived from a certificate associated with the website. ) a verified MUD URL have same specific key information. (¶0122: The system 3100 can use other identifiers include for example, without limitation, a domain name for the associated website, a complete URL for the web page, an IP address for the website, or information associated with or derived from a certificate associated with the website. The system 3100 can also use a combination of identifiers. For example, the browser plugin 3125 can compare the domain name and IP address associated with the website under question with the domain name and IP address associated with a trusted site.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Tyler regarding the matching rule to the method of Lear in view of Sheth, Ektare, and Oberheide in order to prevent malicious activity and confirm that a URL is trusted (Tyler ¶0016).
Claim 29 is rejected under 35 U.S.C. 103 as being unpatentable over Lear et al. (US-20190319953-A1) in view of Sheth et al. (US-20200322356-A1), Ektare et al. (US PGPub No. 20190098028-A1), Oberheide et al. (US PGPub No. 20150046989-A1), and Gilley et al. (US-20170195310-A1).
With respect to claim 29, the combination of Lear in view of Sheth, Ektare, and Oberheide teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose wherein the matching rule is a URL pattern matching rule requiring a to-be-verified MUD URL and a verified MUD URL have a same or similar segment of content.
However, Gilley teaches wherein the matching rule is a URL pattern matching rule requiring a to-be-verified MUD URL and (¶0146: A resource authorization rule is typically a regular expression—a sequence of characters that define a search pattern—that matches against a single resource URI or a related family of resource URLs to provide access for a single operation on the resource. An authorization rule may also include meta-data and/or software procedures used for authorization by/with authentication service 31. The token was provisioned previously via DSE interface 110 as a shared secret. At step 674, auth service 144 checks whether any authorization rules were retrieved. If not, at step 688, auth service 144 determines that the operation is not authorized, and the authentication process fails.) a verified MUD URL have a same or similar segment of content. (¶0176-0183:A routing rule can be based on metadata, on pattern matching, or on a script.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Gilley regarding the matching rule to the method of Lear in view of Sheth, Ektare, and Oberheide in order to control access and to identify fake segments (Gilley ¶0019).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAYLOR P VU whose telephone number is (703)756-1218. The examiner can normally be reached MON - FRI (7:30 - 5:00).
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, Alexander Lagor can be reached at (571) 270-5143. 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.
/T.P.V./Examiner, Art Unit 2437 /MENG LI/Primary Examiner, Art Unit 2437
Prosecution Insights