DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis 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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 08/05/2025 has been entered.
Claims 1 and 12 are currently amended.
Claims 1-3, 5-15, and 57 and 58 are pending.
Claims 4, 16-56 are cancelled.
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.
Claim(s) 1-3, 5-15, 17-18, 20 and 57-58 are rejected under 35 U.S.C. 103 as being
unpatentable over Smith et al (U.S. PGPub. No. 2020/0374700 A1) (hereinafter "Smith") in view of WON et al (U. S. PGPub. No. 2018/0183587 A1) (hereinafter “Won”) and Boss et al (U. S. PGPub. No. 2019/0364049 A1) (hereinafter “Boss”); and in further view of NITSCHKE (U. S. PGPub. No. 2017/0054566 A1) (hereinafter “Nitschke”).
Regarding claim 1, Smith teaches,
a method for supporting Internet of Things (IoT) Trustworthiness as a Service (TaaS) related to an IoT device (Smith: [0002], provides for generally relate to data processing and security authentication techniques to techniques for establishing and implementing functionality for data processing and security authentication for internet of things (IoT) devices and device networks),
the IoT device being configured for connection to the Internet via a communication system (Smith: [0133], provides for the mesh transceiver 1462 may communicate using multiple standards or radios for communications at different range. [0134], provides for a wireless network transceiver 1466 may be included to communicate with devices or services in the cloud 1400 via local or wide area network protocol. [0134], provides for The IoT device 1450 may communicate over a wide area using LoRaWAN™ (Long Range Wide Area Network). [0135], provides for Any number of other radio communications and protocols may be used in addition to the systems mentioned for the 15-mesh transceiver 1462 and wireless network transceiver 1466, as described herein. [0137], provides for A network interface controller (NIC) 1468 may be included to provide a wired communication to the cloud 1400 or to other devices, such as the mesh devices 1464. The wired communication may provide an Ethernet connection, or may be based on other types of networks. [0138], provides for Given the variety of types of applicable communications from the device to another component or network, applicable communications circuitry used by the device may 65 include or be embodied by any one or more of components 1462, 1466, 1468, or 1470.),
method is being based on an automated request-response procedure performed by a network entity as TaaS consumer, TaaS receiver or TaaS proxy, to obtain a digital IoT certification proof representative of the trustworthiness of the IoT device from an IoT certification system acting as TaaS provider (Smith: [0063], provides for request process, at 702, an onboarding tool receives a request to be onboarded from a device. The request may be provided by the device directly, such as with a broadcast communication protocol (e.g., Bluetooth), or may be initiated by a user (e.g., administrator) of the device. The request includes a platform certificate of the device. [0065], provides for response process, at 706, if the attributes from the platform certificate match the corresponding attributes in the corresponding approved product list, then the onboarding tool uses a policy data store (or, policy set, policy master profile, including data among one or multipole profiles) to determine whether the device should be allowed on the IoT network)
requesting the digital IoT certification proof from the TaaS provider based on an identifier for locating the digital IoT certification proof for the IoT device (Smith: [0063], provides for the request may be provided by the device directly, such as with a broadcast communication protocol (e.g., Bluetooth), or may be initiated by a user (e.g., administrator) of the device. The request includes a platform certificate of the device),
the identifier for locating the digital IoT certification proof (Smith: [0061] FIG. 6 is a code listing illustrating an example of a certified products listing in XML (=In Fig 6, “CertifiedProductListingInfo xmlns= http://openinterconnect.org/certifiedproductlisting/schemas/” is the identifier for locating the digital IoT certification proof)), according to an example. The CPL includes several pieces of manufacturer-provided information, such as the manufacturer and device name, and OCF authorized data, such as OCF Vertical and Certification ID) being valid for a plurality of devices having a same one or more of: brand, model, version , and type (Smith: Examiner is interpreting that if attributes of the platform certificates are same as or matches with the attributes in “Approved Products List” then the platform certification considered as valid certification having “CertifiedProductListingInfo xmlns= http://openinterconnect.org/certifiedproductlisting/schemas/” as described further in below paragraphs and in the screenshot below. [0068] The method 800 includes an operation 804 to compare elements in the platform certificate with elements from a corresponding approved product list. In an example, the elements in the platform certificate comprise…device attributes (=a vendor, model, version, or the like… [0070] The method 800 includes an operation 810 to onboard the device to the IoT network in response to determining that the attributes from the platform certificate match the corresponding attributes in the corresponding approved product list);
and receiving a response comprising the digital IoT certification proof from the TaaS provider to enable one or both management and (Smith: [0067], provides for the method 800 includes an operation 802 to receive, at an onboarding tool, a request to be onboarded from the device, wherein the request includes a platform certificate of the device (= certification proof.)
Smith does not explicitly disclose:
The automated request-response procedure comprising:
The automated request-response procedure being performed
However, in an analogous art, Won teaches:
The automated request-response procedure comprising Won: [0072] If IoT device 100 passes the challenge-response test, then at step 520, server 100 authenticates the IoT device 100):
The automated request-response procedure being performed (Won: [0072] If IoT device 100 passes the challenge-response test, then at step 520, server 100 authenticates the IoT device 100).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Smith’s method of receiving a request including the platform certificates (=certification proof) from the device by applying Won’s method of performing the challenge-response test, in order to authenticate the IoT device.
The Smith in view of Won does not explicitly teaches:
However, in an analogous art, Boss teaches:
(Boss: :[0099] At decision point 620, the process 600 determines whether the respective trust evaluation (of several different types, as described below) passes. At block 624, the process 600 conveys the (newly) trusted device identity/identifier and the evaluated trust attributes to the credentialing system), the loT device waiting to access an loT application service (Boss: examiner interpreting that in the paragraph [0099], decision point decides based on trust evaluation result whether to grant access or not to the unknown devices. It is obvious to the person in the ordinary skill in the art to understand that IoT device is waiting to get be granted to get access to the resources. [0100] Returning to the description of decision point 620, in response to determining that the respective trust evaluation does not pass, the process 600 issues a response to the requesting unknown device that authorization (trust) is not granted at block 626 (=examiner interpreting that in the paragraph [0099], decision point decides based on trust evaluation result whether to grant access or not to the unknown devices. It is obvious to the person in the ordinary skill in the art to understand that IoT device is waiting to get be granted to get access to the resources)),
(Boss: examiner interpreting that in the paragraph [0099], decision point decides based on trust evaluation result whether to grant access or not to the unknown devices. It is obvious to the person in the ordinary skill in the art to understand that IoT device is waiting to get be granted to get access to the resources. [0087] FIG. 5 is a flow chart of an example of an implementation of a process 500 for automated secure provisioning of unknown devices through trusted third-party devices. The process 500 represents a computer-implemented method of performing the trust authorization processing described herein. At block 502, the process 500 receives trust evaluation rules usable to determine whether to authorize unknown devices to access a resource. At block 504, the process 500 receives a request to access the resource and device evaluation attributes from an unknown device. At block 506, the process 500 evaluates the trustworthiness of the unknown device based upon the device evaluation attributes using the trust evaluation rules).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Smith in view of Won by applying the well-known technique as disclosed by Boss of performing the trust authorization process to evaluate the trust of the unknown device. The motivation is to provide secure provisioning of unknown devices through trusted third-party devices (Boss: [0001]).
Smith in view of Won and Boss does not explicitly disclose:
the digital loT certification proof being digitally signed by a private key of the loT certification system or an associated certification entity, the digital loT certification proof comprising a time stamp when the IoT certification proof was issued and a validity period, the private key being a Public Key Infrastructure X. 509 (PKIX).
However, in an analogous are, Nitschke teaches:
the digital loT certification proof being digitally signed by a private key of the loT certification system or an associated certification entity (Nitschke: US2017/0054566A1): [0035] According to a second variant, the method further comprises to generate a digitally signed timestamp which associates the device certificate with the point in time at which the timestamp is generated. The digitally signed timestamp is preferably generated so that the device certificate or a hash value of the device certificate along with the current time indication, for example in the form of date and time, is digitally signed using a signing key (=private key of the IoT certification system),
the digital loT certification proof comprising a time stamp when the IoT certification proof was issued (Nitschke: [0026], wherein the time of issue of the device certificate is documented by means of a signed electronic timestamp, [0163] 1. The timestamp is generated at the time of creation of the device certificate or shortly thereafter, [0035] According to a second variant, the method further comprises to generate a digitally signed timestamp which associates the device certificate with the point in time at which the timestamp is generated. The digitally signed timestamp is preferably generated so that the device certificate or a hash value of the device certificate along with the current time indication, for example in the form of date and time (=timestamp), is digitally signed using a signing key. [0198] According to the further variant of the invention described below the device certificate is combined with a timestamp to confirm its time of issue, and furthermore the device certificate is checked using a validity model which provides proofs of existence for the certificates) and a validity period (Nitschke: [0179], The validity model described above effectively means that a device certificate will be verified as valid until its validity period 930 or the validity period of the corresponding timestamp has expired, whichever occurs first. These two validity periods should preferably be adjusted, by the device manufacturer, to the expected service life of the device and the expected resilience duration of the algorithms used for the certificates and the timestamp), the private key being a Public Key Infrastructure X. 509 (PKIX) (Nitschke: [0115], the PKIX standard, the invention in particular comprises that status information provide positive evidence and/or that certificates need only have been valid at the issuing time of signatures to be checked thereby).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Smith in view of Won and Boss by applying the well-known technique as disclosed by Nitschke of determining the timestamp when certificate was issues, verifying the validating period of device certificate . The motivation is to perform identity check on the device by checking validity of device certificate (Nitschke: [0001])
Regarding claim 2, Smith in view of Won, Boss and Nitschke teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein one or both of the management and assessment of the trustworthiness of the IoT device is performed by the network entity or by another network entity interconnected to the network (Smith: [0059], provides the CMS generates a test plan based on applicant submitted information. The applicant submitted information may also be sent to an OCF certification body (CB), which may keep the CRSL maintained in the CMS up to date with current status of tests for a device or devices. The CMS may send the device or information about the device to be tested to an authorized test lab which examines the submitted information for completeness. [0060] When the authorized test lab determines the information is complete, an OCF test of the submitted device or device information may occur. [0082], provides for the ecosystem operator may perform onboarding, commissioning, or may act as a verifier. The ecosystem operator may be augmented to include verifying other types of compliance, or evaluation results, such as conformance test labs results).
Regarding claim 3, Smith in view of Won, Boss and Nitschke teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein the network entity is a network node of an enterprise or associated IoT service provider for one or both managing and evaluating the trustworthiness of a number of IoT devices associated with the enterprise (Smith: [0070], provides for the method 800 includes an operation 810 to onboard the device to the IoT network in response to determining that the 40 attributes from the platform certificate match the corresponding attributes in the corresponding approved product list. In an example, onboarding the device includes deter mining that the attributes from the platform certificate match the corresponding attributes in the corresponding approved 45 product list for all platform attributes, container attributes, device attributes, conformance status, security profile attributes, or the like, as identified for the device. [0082], provides for the ecosystem operator may perform onboarding, commissioning, or may act as a verifier. The ecosystem operator may be augmented to include verifying other types of compliance, or evaluation results, such as conformance test labs results. The ecosystem operator may act as an interface or coordinator between a device and a blockchain, in an example, which is described in further detail below with respect to FIG. 10. [0152], provides for, Example 2 is a method, comprising a plurality of operations executed with a processor and memory of a device, to perform operations for using platform certificates to verify compliance and compatibility of a device when onboarding 60 the device into an internet of things (IoT) network, in accordance with the techniques discussed herein. [0163], provides for Example 13 is a method for using platform certificates to verify compliance and compatibility of a device when onboarding the device into an internet of things (IoT) network).
Regarding claim 5, Smith in view of Won, Boss and Nitschke teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein the network entity or another network entity interconnected to the network entity comprises: at least one service provider network node for selectively providing a service to the IoT device in response to a service request from one or both of the IoT device and an enterprise network node (Smith: [0024], provides for The IoT supports deployments in which a large number of computing devices are interconnected to each other (and to the Internet) to provide functionality and data acquisition at very low levels. Thus, as used herein, an IoT device may include a semiautonomous device performing a function, such as sensing or control, among others, in communication with other IoT devices and a wider network, such as the Internet. [0031], provides for an example, communications between IoT devices 104, such as over the backbone links 102, may be protected by a decentralized system for authentication, authorization, and accounting (AAA). In a decentralized AAA system, distributed payment, credit, audit, authorization, and authentication systems may be implemented across interconnected heterogeneous network infrastructure, [0038], provides for the fog network 220 may be considered to be a massively interconnected network wherein a number of IoT devices 202 are in communications with each other).
Regarding claim 6, Smith in view of Won, Boss and Nitschke teaches:
The method of claim 5 (see rejection of claim 5 above),
wherein said at least one service provider network node comprises one or both an application service provider network node for providing one or more IoT application services and or a communication service provider network node for providing one or more IoT connectivity services (Smith: [0020], provides for block technologies such as hardware, firmware, container, operating system. IoT device library, and IoT device application(s). When an IoT device vendor submits a device for conformance testing, the vendor selects a configuration of building blocks upon which the IoT device (library and application) are evaluated. [0022], provides for the use of IoT devices and networks, such as those introduced in FIGS. 1 and 2, present a number of new challenges in a heterogeneous network of connectivity comprising a combination of wired and wireless technologies. [0036], provides for Finally, clusters of IoT devices may be equipped to communicate with other IoT devices as well as with a cloud network. This may allow the IoT devices to form an ad-hoc network between the devices, allowing them to function as a single device, which may be termed a fog device, fog platform, or fog network. This configuration is discussed further with respect to FIG. 2).
Regarding claim 7, Smith in view of Won, Boss and Nitschke teaches:
The method of claim 6 (see rejection of claim 6 above),
wherein the network entity is the application service provider network node which obtains the digital IoT certification proof for the IoT device from the IoT certification system acting as TaaS provider, and takes a decision whether to grant access to an IoT application service for the IoT device based on the digital IoT certification proof (Smith: [0109], provides for orchestration tool (e.g., ecosystem operator) that evaluates whether the product's compliance status is current. Compliance status may relate to individual sub-components of the composite product, and when relevant, the sub-component compliance status may also be checked. When all relevant status checks satisfy an orchestration policy, the product (device) is permitted on the network. [0152], provides for accordance with the techniques discussed herein. Example 2 is a method, comprising a plurality of operations executed with a processor and memory of a device, to perform operations for using platform certificates to verify compliance and compatibility of a device when onboarding the device into an internet of things (IoT) network, in accordance with the techniques discussed herein. [0163], provides for Example 13 is a method for using platform certificates to 35 verify compliance and compatibility of a device when onboarding the device into an internet of things (IoT) network).
Regarding claim 8, Smith in view of Won, Boss and Nitschke teaches:
The method of claim 6 (see rejection of claim 6 above),
wherein the network entity is the communication service provider network node or the enterprise network node or an identity provider network node which obtains the digital IoT certification proof for the IoT device from the IoT certification system acting as TaaS provider, and transfers the digital IoT certification proof to: the application service provider network node to enable the application service provider network node to take a decision whether to grant access to an IoT application service for the IoT device based on one or both of the digital IoT certification proof, and the enterprise network node for one or both managing and evaluating the trustworthiness of the IoT device (Smith: [0063-0068], provides for the verification of IoT device using certificate and decide whether to permit IoT device to access IoT services. [0070], provides for the method 800 includes an operation 810 to onboard the device to the IoT network in response to determining that the attributes from the platform certificate match the corresponding attributes in the corresponding approved product list. In an example, onboarding the device includes deter mining that the attributes from the platform certificate match the corresponding attributes in the corresponding approved product list for all platform attributes, container attributes, device attributes, conformance status, security profile attributes, or the like, as identified for the device. [0082], provides for the ecosystem operator may perform onboarding, commissioning, or may act as a verifier. The ecosystem operator may be augmented to include verifying other types of compliance, or evaluation results, such as conformance test labs results. The ecosystem operator may act as an interface or coordinator between a device and a blockchain, in an example, which is described in further detail below with respect to FIG. 10. [0152], provides for Example 2 is a method, comprising a plurality of operations executed with a processor and memory of a device, to perform operations for using platform certificates to verify compliance and compatibility of a device when onboarding the device into an internet of things (IoT) network, in accordance with the techniques discussed herein. [0163], provides for Example 13 is a method for using platform certificates to verify compliance and compatibility of a device when onboarding the device into an internet of things (IoT) network).
Regarding claim 9 and 10, this claim contains identical limitations found within that of claim 8 above albeit directed to a same statutory category (method claim), and for this reason the same rationale of rejection is used where applicable grounds of rejection are applied to claim 9 and 10.
Regarding claim 11, Smith in view of Won, Boss and Nitschke teaches:
The method of claim 10 (see rejection of claim 10 above),
wherein the identity provider network node provides an identity assertion service for the IoT device (Smith: [0012], provides FIG. 7 is a flowchart illustrating a method for using platform certificates to verify compliance and compatibility of a device at a time of onboarding the device into an internet 10 of things (IoT) network, according to an example)
and transfers the digital IoT certification proof together with an identity assertion proof to the IoT device (Smith: [0063], provides for an onboarding tool receives a request to be onboarded from a device. The request may be provided by the device directly, such as with a broadcast communication protocol (e.g., Bluetooth), or may be initiated by a user (e.g., administrator) of the device. The request includes a platform certificate of the device. [0063-0068], provides for the verification of IoT device using certificate and decide whether to permit IoT device to access IoT services. [0109], provides for orchestration tool (e.g., ecosystem operator) that evaluates whether the product's compliance status is current. Compliance status may relate to individual sub-components of the composite product, and when relevant, the sub-component compliance status may also be checked. When all relevant status checks satisfy an orchestration policy, the product (device) is permitted on the network).
Regarding claim 12, this claim contains identical limitations found within that of claim 1 above albeit directed to a same statutory category (method claim), and for this reason the same rationale of rejection is used where applicable grounds of rejection are applied to claim 12
Regarding claim 13, Smith in view of Won, Boss and Nitschke teaches:
The method of claim 12 (see rejection of claim 12 above),
wherein the network entity is a network node of an enterprise or associated IoT service provider for one or more managing and evaluating the trustworthiness of a number of IoT devices associated with the enterprise (Smith: [0070], provides for the method 800 includes an operation 810 to onboard the device to the IoT network in response to determining that the attributes from the platform certificate match the corresponding attributes in the corresponding approved product list. In an example, onboarding the device includes determining that the attributes from the platform certificate match the corresponding attributes in the corresponding approved product list for all platform attributes, container attributes, device attributes, conformance status, security profile attributes, or the like, as identified for the device. [0082], provides for the ecosystem operator may perform onboarding, commissioning, or may act as a verifier. The ecosystem operator may be augmented to include verifying other types of compliance, or evaluation results, such as conformance test labs results. The ecosystem operator may act as an interface or coordinator between a device and a blockchain, in an example, which is described in further detail below with respect to FIG. 10. [0152], provides for Example 2 is a method, comprising a plurality of operations executed with a processor and memory of a device, to perform operations for using platform certificates to verify compliance and compatibility of a device when onboarding 60 the device into an internet of things (IoT) network, in accordance with the techniques discussed herein. [0163], provides for Example 13 is a method for using platform certificates to 35 verify compliance and compatibility of a device when onboarding the device into an internet of things (IoT) network).
Regarding claim 14, Smith in view of Won, Boss and Nitschke teaches:
The method of claim 12 (see rejection of claim 12 above),
wherein the network entity or another network entity interconnected to the network entity comprises at least one service provider network node for selectively providing a service to the IoT device in response to a service request from one or both of the IoT device and an enterprise network node (Smith: [0084], provides for, in an example, the ecosystem operator of FIG. 9 may be used to identify a device and determine whether the device is compliant with a particular ecosystem or standard (e.g., compliant with an OCF specification). After the ecosystem operator determines a device identity or that a device has a particular certification, the ecosystem operator may allow the device access to a service or network (e.g., access a cloud, join a network, activate actions, etc.). In an example, device identification or end entity certification may include certification of a device's attributes, such as a vendor, model, version, or the like. The ecosystem operator may determine or assign a particular security level to a device based on certifications).
Regarding claim 15, Smith in view of Won, Boss and Nitschke teaches:
The method of claim 12 (see rejection of claim 12 above),
wherein the network entity an identity provider for providing an identity assertion service for the IoT device (Smith: [0086], provides for a self-sovereign identity blockchain is a mechanism for individual assertion of identity (identifiers) that may be published through the blockchain such that blockchain members agree (or vote) regarding which asymmetric key possesses which identifier. A manufacturer of devices or platforms may assert sovereign device identity by using a device asymmetric key to sign a blockchain transaction containing the device identity. [0085], provides for A manufacturer or vendor may add attestation criteria, such as additional consideration/assurances/criteria to ensure that the embedded key is protected or verifiable. [0098], provides for example, the ingredient may be a TCG Trusted Platform Module (TPM) that contains the DeviceID and TCG defined restricted keys that may attest the presence of the DeviceID on the TPM 20 which has known key protection properties).
Regarding Claim 57, Smith in view of Won, Boss and Nitschke teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein the method comprises performing, by the network entity, the automated request-response procedure, and wherein the method further comprises (Smith: [0063], provides for request process, at 702, an onboarding tool receives a request to be onboarded from a device. The request may be provided by the device directly, such as with a broadcast communication protocol (e.g., Bluetooth), or may be initiated by a user (e.g., administrator) of the device. The request includes a platform certificate of the device. [0065], provides for response process, at 706, if the attributes from the platform certificate match the corresponding attributes in the corresponding approved product list, then the onboarding tool uses a policy data store (or, policy set, policy master profile, including data among one or multipole profiles) to determine whether the device should be allowed on the IoT network):
performing, by the network entity, the one or more of the management and assessment of the trustworthiness of the loT device based on the digital loT certification proof from the TaaS provider (Smith: [0059], provides the CMS generates a test plan based on applicant submitted information. The applicant submitted information may also be sent to an OCF certification body (CB), which may keep the CRSL maintained in the CMS up to date with current status of tests for a device or devices. The CMS may send the device or information about the device to be tested to an authorized test lab which examines the submitted information for completeness. [0060] When the authorized test lab determines the information is complete, an OCF test of the submitted device or device information may occur. [0082], provides for the ecosystem operator may perform onboarding, commissioning, or may act as a verifier. The ecosystem operator may be augmented to include verifying other types of compliance, or evaluation results, such as conformance test labs results);
or transferring the digital loT certification proof to another network entity interconnected to the network entity, wherein the another network entity is configured to perform the one or more of the management and assessment of the trustworthiness of the loT device based on the digital loT certification proof from the TaaS provider (Smith: [0063-0068], provides for the verification of IoT device using certificate and decide whether to permit IoT device to access IoT services. [0070], provides for the method 800 includes an operation 810 to onboard the device to the IoT network in response to determining that the attributes from the platform certificate match the corresponding attributes in the corresponding approved product list. In an example, onboarding the device includes deter mining that the attributes from the platform certificate match the corresponding attributes in the corresponding approved product list for all platform attributes, container attributes, device attributes, conformance status, security profile attributes, or the like, as identified for the device. [0082], provides for the ecosystem operator may perform onboarding, commissioning, or may act as a verifier. The ecosystem operator may be augmented to include verifying other types of compliance, or evaluation results, such as conformance test labs results. The ecosystem operator may act as an interface or coordinator between a device and a blockchain, in an example, which is described in further detail below with respect to FIG. 10. [0152], provides for Example 2 is a method, comprising a plurality of operations executed with a processor and memory of a device, to perform operations for using platform certificates to verify compliance and compatibility of a device when onboarding the device into an internet of things (IoT) network, in accordance with the techniques discussed herein. [0163], provides for Example 13 is a method for using platform certificates to verify compliance and compatibility of a device when onboarding the device into an internet of things (IoT) network).
Regarding Claim 58, Smith in view of Won, Boss and Nitschke teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein the digital loT certification proof representative of the trustworthiness of the loT device comprises digital proof that the certification system has certified the trustworthiness of loT devices that have the same brand, model, and version of one or both hardware and software as the loT device, wherein the digital loT certification proof is digitally signed by the certification system (Smith: [0011] FIG. 6 is a code listing illustrating an example of a certified products listing in XML, according to an example; [0046], provides for the Platform Certificate or the APL may be digitally signed. [0072], The approved product list may have a digital signature for verifying. [0085], A SWID tag includes a composite identifier containing “manufacturer”, “model,” and “version” information. [0095], provides for the issuer digitally signs the document that is contributed to the blockchain establishing a binding or association of the ingredient instance to the ingredient model (or class). The DeviceID may be used as an instance identifier. The signed document may be regarded as a Digital Certificate such as is defined by RFC 5280 (X.509) or a signed document as defined by RFC 8152 (COSE)).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Loladia et al. (U. S. Pat. No. 10,447,683 B1): Techniques are disclosed for provisioning device-specific credentials to an Internet of Things device that accesses a cloud-based IoT service. The IoT service receives, from the IoT device, a request for device-specific credentials. The request comprises a provisioning certificate including information identifying a group of devices associated with the IoT device. The provisioning certificate is authenticated by evaluating the information with expected information. The device-specific credentials are generated based, at least in part, on the information provided in the provisioning certificate. The device-specific credentials are sent to the IoT device, and the IoT device installs and activates the device-specific credentials. The device-specific credentials are associated with the IoT device in a registry of the IoT service.
Vegh et al. (U. S. PGPub.No. 2019/0289002A1): Concepts and technologies are disclosed herein for multifactor authentication for Internet-of-things devices. An access request can be received from an Internet-of-things device. The access request can include identifying information associated with the Internet-of-things device and a certificate. The certificate can be validated and a stored version of the identifying information can be obtained. If the stored version of the identifying information is determined to match the identifying information included with the access request, access to a resource can be allowed.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RUPALI DHAKAD whose telephone number is (571)270-3743. The examiner can normally be reached M-F 8:30-5:30.
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 5712705143. 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.
/R.D./Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437